8
Firewall-Log ist fragwürdig
Hallo,
ich wurde heute beim durcharbeiten der Logfiles von unserer Firewall etwas überrascht.
Das beigefügte Bild ist ein Ausschnitt von den Ereignissen der Firewall, der Hersteller gibt hier leider keine Aussage zu der Deutung des Log-Files.
Die SCR-Adressen sind immer unterschiedliche aus unserem Netz und die DST Adressen sind meist unsere Router.
Hat jemand von euch eine Ahnung, was hier gerade läuft? Ich wäre euch echt dankbar.
ich wurde heute beim durcharbeiten der Logfiles von unserer Firewall etwas überrascht.
Das beigefügte Bild ist ein Ausschnitt von den Ereignissen der Firewall, der Hersteller gibt hier leider keine Aussage zu der Deutung des Log-Files.
Die SCR-Adressen sind immer unterschiedliche aus unserem Netz und die DST Adressen sind meist unsere Router.
Hat jemand von euch eine Ahnung, was hier gerade läuft? Ich wäre euch echt dankbar.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 93989014916
Url: https://administrator.de/forum/firewall-log-ist-fragwuerdig-93989014916.html
Ausgedruckt am: 22.12.2024 um 10:12 Uhr
8 Kommentare
Neuester Kommentar
Port 67 und 137 sollten dir jedoch bekannt sein. Die oberen Ports sind frei definierbar.
Hallo,
ich sehe da nichts Fragwürdiges drin:
UDP Broadcasts halt.
ohne jetzt genau nachzuschauen:
UDP 137 = NetBIOS
UDP 1947 = Sentinel HASP Dongle.
Warum das deine (uns unbekannte) Firewall das so logged kann ich dir nicht beantworten.
Gruß
CH
ich sehe da nichts Fragwürdiges drin:
UDP Broadcasts halt.
ohne jetzt genau nachzuschauen:
UDP 137 = NetBIOS
UDP 1947 = Sentinel HASP Dongle.
Warum das deine (uns unbekannte) Firewall das so logged kann ich dir nicht beantworten.
Gruß
CH
1
Die (unbekannte) Firewall ist eine Collax Business Server V. 7.2.18.
Das ist so selten, da wurde hier im Forum das letzte mal 2009 drüber geschrieben.
Was mich so irritiert ist, dass es im Millisekunden-Takt diese Einträge gibt mit dem Verweis auf "bad service" die Rede ist hier binnen 24h von ca. 234.000 Einträgen in der Log-Datei
Das ist so selten, da wurde hier im Forum das letzte mal 2009 drüber geschrieben.
Was mich so irritiert ist, dass es im Millisekunden-Takt diese Einträge gibt mit dem Verweis auf "bad service" die Rede ist hier binnen 24h von ca. 234.000 Einträgen in der Log-Datei
Zitat von @an-x-ur:
Was mich so irritiert ist, dass es im Millisekunden-Takt diese Einträge gibt mit dem Verweis auf "bad service" die Rede ist hier binnen 24h von ca. 234.000 Einträgen in der Log-Datei
Was mich so irritiert ist, dass es im Millisekunden-Takt diese Einträge gibt mit dem Verweis auf "bad service" die Rede ist hier binnen 24h von ca. 234.000 Einträgen in der Log-Datei
Moin,
daß das UDP-Broadcasts sind, haben die Kollegen ja schon gesagt, teilweise mit bekannten und teilweise mit unbekannten Ports..
Ich würde Mal prüfen, wann das angefangen hat oder ob das schon immer so war und nur jetzt aufgefallen ist.
Des weiteren würde ich Mal die Liste nach den lokalen Hosts sortieren und schauen, ob da auffälligkeiten sind
Aber anso Sten sieht da nicht so aus, als ob man da in Panik verfallen müßte.
lks
Port 67/68 ist DHCP das ist harmlos, Port 137/445 der Windows-Dateifreigabe-Dienst.
Wenn da einzelne Clients wirklich plötzlich die Routeradresse mit beharken, ist das zumindest einen zweiten Blick auf die Clients wert, warum sie das tun.
Der Broadcast-Traffic kann alles sein, da müsste man mit Wireshark mitlesen um genauer sehen zu können was da passiert.
Das Logformat ist aber 1:1 das von iptables unter Linux oder BSD (vermutlich weil genau das verwendet wird), das ist also nicht spezifisch für diesen Hersteller. Du kannst also im Internet einfach damit recherchieren.
Wenn da einzelne Clients wirklich plötzlich die Routeradresse mit beharken, ist das zumindest einen zweiten Blick auf die Clients wert, warum sie das tun.
Der Broadcast-Traffic kann alles sein, da müsste man mit Wireshark mitlesen um genauer sehen zu können was da passiert.
Das Logformat ist aber 1:1 das von iptables unter Linux oder BSD (vermutlich weil genau das verwendet wird), das ist also nicht spezifisch für diesen Hersteller. Du kannst also im Internet einfach damit recherchieren.
1
Das Verhalten kann IMO auf einer Fehlkonfiguration des Netzes/der Firewall beruhen, zumindest des Loggings. Kollege @aqui oder ein anderer Berufener möge mich korrigieren, wo ich falsch liege:
Broadcasts bleiben im selben Netz. Wenn sie Netzgrenzen zu überschreiten versuchen, handelt es sich entweder um globale (limited) Broadcasts oder um eine fehlerhafte Einstellung der Netzmaske in den (direct) broadcastenden Geräten (zB Clients). Wenn in der Firewall zB die Netze mit /24er Maske angelegt sind, der Client aber mit einer /16er Maske broadcastet, versucht der Broadcast aus Sicht der Firewall in ein anderes Netz zu gelangen und wird geblockt (forward chain).
Soweit die Log-Einträge sich auf Broadcasts im selben Netz beziehen, ist die Firewall so eingestellt, dass sie die an sie selbst gerichteten Broadcasts filtert (input chain). Dafür kann man das Logging deaktivieren. Genau genommen ist es IMO Schlamperei des FW-Herstellers, dieses generelle Blocken ins Logging aufzunehmen.
All das ist aber "ungefährlich"
und auch die Zahl der Einträge wäre bei einem nicht ganz kleinen Netz IMO normal.
Viele Grüße, commodity
Broadcasts bleiben im selben Netz. Wenn sie Netzgrenzen zu überschreiten versuchen, handelt es sich entweder um globale (limited) Broadcasts oder um eine fehlerhafte Einstellung der Netzmaske in den (direct) broadcastenden Geräten (zB Clients). Wenn in der Firewall zB die Netze mit /24er Maske angelegt sind, der Client aber mit einer /16er Maske broadcastet, versucht der Broadcast aus Sicht der Firewall in ein anderes Netz zu gelangen und wird geblockt (forward chain).
Soweit die Log-Einträge sich auf Broadcasts im selben Netz beziehen, ist die Firewall so eingestellt, dass sie die an sie selbst gerichteten Broadcasts filtert (input chain). Dafür kann man das Logging deaktivieren. Genau genommen ist es IMO Schlamperei des FW-Herstellers, dieses generelle Blocken ins Logging aufzunehmen.
All das ist aber "ungefährlich"
und auch die Zahl der Einträge wäre bei einem nicht ganz kleinen Netz IMO normal.Viele Grüße, commodity
@commodity vielen Dank für die Ausführung.
Ich habe jetzt in der FW das Logging für unbekannte Dienste so angepasst, dass es zwar aufgezeichnet wird aber Broadcast ignoriert wird. Ich denke, damit sollte sich das zukünftig im Zaum halten und man hat den Blick wieder für das Wesentliche. Bei so eine schieren Menge erkennt man ja den wichtigen Eintrag vor lauter Logging nicht.
Ich habe jetzt in der FW das Logging für unbekannte Dienste so angepasst, dass es zwar aufgezeichnet wird aber Broadcast ignoriert wird. Ich denke, damit sollte sich das zukünftig im Zaum halten und man hat den Blick wieder für das Wesentliche. Bei so eine schieren Menge erkennt man ja den wichtigen Eintrag vor lauter Logging nicht.
+1
Viele Grüße, commodity
Viele Grüße, commodity
