Hilfe bei Interpretation Firewall Logfile
Hallo zusammen! Ich bin neu hier ;)
Kurz vorweg: ich bin Laie, versuche aber mich in Themen einzuarbeiten und selbständig Lösungen zu finden. Jetzt stehe ich aber vor einem Problem, dass ich auch nach längerer Suche nicht alleine lösen kann und würde mich über Hilfe freuen.
Ich beobachte *für mich* seltsamen Traffic in meinem Firewall-logfile (Sophos UTM). Komisch deshalb, weil 1. die Quell-IP mein Rechner ist ich aber im parallel geöffneten netstat nicht die entsprechenden Netzwerkverbindungen boebachte 2. weil die Ziel-IPs teils real in meinem Netzwerk existierende IPs sind, teils IPs und Netze die in meinem Netzwerk gar nicht vorkommen.
Mal als Beispiel:
21:40:53 Default DROP UDP 192.168.3.22 : 57477→192.168.178.25 : 161
21:40:53 Default DROP UDP 192.168.3.22 : 57477→192.168.2.210 : 161
21:41:03 Default DROP UDP 192.168.3.22 : 57477→192.168.42.239 : 161
Im Sekundentakt werden immer wieder die gleichen 4 Adressen kontaktiert, ohne dass ich es in Netstat sehen kann. Ist das harmlos, oder sollte ich mir Sorgen machen?
Danke schon mal für Eure Hilfe!
Kurz vorweg: ich bin Laie, versuche aber mich in Themen einzuarbeiten und selbständig Lösungen zu finden. Jetzt stehe ich aber vor einem Problem, dass ich auch nach längerer Suche nicht alleine lösen kann und würde mich über Hilfe freuen.
Ich beobachte *für mich* seltsamen Traffic in meinem Firewall-logfile (Sophos UTM). Komisch deshalb, weil 1. die Quell-IP mein Rechner ist ich aber im parallel geöffneten netstat nicht die entsprechenden Netzwerkverbindungen boebachte 2. weil die Ziel-IPs teils real in meinem Netzwerk existierende IPs sind, teils IPs und Netze die in meinem Netzwerk gar nicht vorkommen.
Mal als Beispiel:
21:40:53 Default DROP UDP 192.168.3.22 : 57477→192.168.178.25 : 161
21:40:53 Default DROP UDP 192.168.3.22 : 57477→192.168.2.210 : 161
21:41:03 Default DROP UDP 192.168.3.22 : 57477→192.168.42.239 : 161
Im Sekundentakt werden immer wieder die gleichen 4 Adressen kontaktiert, ohne dass ich es in Netstat sehen kann. Ist das harmlos, oder sollte ich mir Sorgen machen?
Danke schon mal für Eure Hilfe!
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 340532
Url: https://administrator.de/forum/hilfe-bei-interpretation-firewall-logfile-340532.html
Ausgedruckt am: 02.04.2025 um 16:04 Uhr
9 Kommentare
Neuester Kommentar
Hallo
UDP Port 161 ist SNMP (Simple Network Management Protocol)
https://de.wikipedia.org/wiki/Simple_Network_Management_Protocol
Hast du zufälligerweise ein Netzwerk-Überwachungstool auf deinem Rechner?
Auch deine sekündlichen Einträge deuten sehr darauf hin.
Gruss Philippe
UDP Port 161 ist SNMP (Simple Network Management Protocol)
https://de.wikipedia.org/wiki/Simple_Network_Management_Protocol
Hast du zufälligerweise ein Netzwerk-Überwachungstool auf deinem Rechner?
Auch deine sekündlichen Einträge deuten sehr darauf hin.
Gruss Philippe
Wobei mich die Paketherkunft wundert - mehrere Netze?
Die Herkunft ist ja nicht unterschiedlich sondern das Ziel der SNMP Abfrage.Es ist immer ein Rechner mit der Hostadresse (Absender IP) 192.168.3.22 der die 3 Ziel IPs per SNMP abfragen will.
Das schmeisst dann die Firewall weg (Drop).
Wenn der TO mal einen Wireshark ins Netz gehangen hätte, oder ggf. supportet die Sophos Gurke einen Paket Capture wie z.B. die pfSense, dann hätte man sich die abgefragte OID im SNMP Paket mal ansehen können um rauszufinden WAS dieser Rechner denn von den anderen Komponenten in den unterschiedlichen IP Netzen will...??
Ganz besonders auch der dazu benutzte SNMP Community String !
So oder so ist es aber recht ungewöhnlich das in einem Heimnetzwerk irgendwie SNMP gemacht wird. Von sich aus machen die Komponenten das nicht und ne kleine rote Lampe sollte da dann schon angehen...
Wo finde ich denn die OID? Danke!
Die steht im Datenfeld des UDP get Requests. das ist so ein Lindwirm mit vielen Zahlen und Punkten wie z.B. 1.3.6.1.2.1.31.1.1.1.18Falls das zur Lösung beiträgt:
Nöö, nix. Was hat eine Netzwerk Infrastruktur mit einem SNMP Ethernet Paket und dessen Inhalt zu tun ???Zeigt aber nun die verwendete Infrastruktur und erklärt die unterschiedlichen IP Netze die du uns oben unterschlagen hast...
Hallo,
Dann kannste eher nicht Drucken
Falls du kein Monitoring nutzt oder gar für die Kommunikation mit deinen Druckern benötigst, am Drucker sowie in den Druckeinstellungen SNMP deaktivieren. Manche Drucker brauchen es aber um dir sagen zu können "Papier ist alle". Ansonsten in deiner Sophos UTM diese Pakete dann zulassen und SNMP überall aktiviert haben - auch wenns nicht gebraucht wird. Lieber einen Bus kaufen da man ja nie weiß mit wie vielen Mitreisende man ja täglich rechnen muss.

Gruß,
Peter
Dann kannste eher nicht Drucken
und alle Dateien in c:\windows\system32\spool\PRINTERS - gelöscht und dann neugestartet. Hilft aber auch nichts...
Ausstehende Druckaufträge. Sollte eher leer sein.Falls du kein Monitoring nutzt oder gar für die Kommunikation mit deinen Druckern benötigst, am Drucker sowie in den Druckeinstellungen SNMP deaktivieren. Manche Drucker brauchen es aber um dir sagen zu können "Papier ist alle". Ansonsten in deiner Sophos UTM diese Pakete dann zulassen und SNMP überall aktiviert haben - auch wenns nicht gebraucht wird. Lieber einen Bus kaufen da man ja nie weiß mit wie vielen Mitreisende man ja täglich rechnen muss.
Wireshark habe ich gestern abend kurz laufen lassen. Wo finde ich denn die OID? Danke!
In den Nutzdaten. Auch ein Wireshark erfordert etwas wissen und auch einarbeitung Der Drucker ist via Wifi in LAN1 eingebunden und mein Rechner steht in LAN3
Wenn also die Anfragen per SNMP von dein Rechner auch die Drucker erreichen sollen (und wieder zurück) wirst du dir Regeln bauen müssen.Gruß,
Peter
Auch ein Wireshark erfordert etwas wissen und auch einarbeitung
Dazu auch:https://www.heise.de/ct/ausgabe/2017-11-Wireshark-und-Protokoll-Know-how ...
Quiz:
https://www.heise.de/ct/artikel/Admin-Parcours-Was-geht-ab-im-LAN-369583 ...
Lösung zum Quiz: (aber erst das Quiz machen !!!!)
https://blog.webernetz.net/2017/05/18/wireshark-layer-2-3-pcap-challenge ...