22
Broadcast Datenverkehr .255 unterbinden
Moin Admins,
ganz naiv gefragt: Wie geht mir mit dem Broadcast Datenverkehr um?
Beispiel
Ich habe eine OPNsense einfach mal zwischen div. Systeme gesetzt, auffällig ist dabei immer, dass der Datenverkehr .255 im Standard geblockt wird. Für mich bisher ganz normal, absolut nicht außergewöhnlich, und auch die OPNsense blockt es im Standard.
Frage
Wie bewertet ihr die Aussage, dass dieser Broadcast Traffic eine Belastung für die Firewall sei und man den Broadcast unterbinden müsse, sonst leidet die Performance der Firewall darunter?
Ok, ich kann mir vorstellen das die Logs/Protokolle länger werden.
Danke für konstruktives Feedback.
ganz naiv gefragt: Wie geht mir mit dem Broadcast Datenverkehr um?
Beispiel
Ich habe eine OPNsense einfach mal zwischen div. Systeme gesetzt, auffällig ist dabei immer, dass der Datenverkehr .255 im Standard geblockt wird. Für mich bisher ganz normal, absolut nicht außergewöhnlich, und auch die OPNsense blockt es im Standard.
Frage
Wie bewertet ihr die Aussage, dass dieser Broadcast Traffic eine Belastung für die Firewall sei und man den Broadcast unterbinden müsse, sonst leidet die Performance der Firewall darunter?
Ok, ich kann mir vorstellen das die Logs/Protokolle länger werden.
Danke für konstruktives Feedback.
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: 668401
Url: https://administrator.de/contentid/668401
Ausgedruckt am: 23.11.2024 um 08:11 Uhr
22 Kommentare
Neuester Kommentar
Moin,
Broadcasts sind essentiell für die Funktionalität in Netzwerken (z.B. ARP, DHCP etc.).
Die Firewall als Netzteilnehmer muss daher auch diese Broadcasts empfangen.
Wie willst du den Traffic denn überhaupt unterbinden? Broadcasts werden so oder so nicht geroutet.
Gruß,
Avoton
Wie bewertet ihr die Aussage, dass dieser Broatcast Traffic eine Belastung für die Firewall sei und man den Broadcast unterbinden müsse, sonst leidet die Performance der Firewall darunter.
Broadcasts sind essentiell für die Funktionalität in Netzwerken (z.B. ARP, DHCP etc.).
Die Firewall als Netzteilnehmer muss daher auch diese Broadcasts empfangen.
Wie willst du den Traffic denn überhaupt unterbinden? Broadcasts werden so oder so nicht geroutet.
Gruß,
Avoton
5
Wie geht mir mit dem Broatcast
Bahnhof?! Wie geht mir (oder doch "ihr") mit dem Brotkasten...? (Der "Bearbeiten" Knopf ist dein bester Freund bei solchem 3fachen "Broadcast" Fauxpas! Korrekturlesen vorher hilft wirklich... 
)auffällig ist dabei immer, dass der Datenverkehr .255 im Standard geblockt wird
In einem gerouteten Umfeld ist das doch eine bekannte Binsenweisheit. Broad- und Multicasts werden bei Routing nicht geforwardet wie du als Administrator ja auch selber weisst. Wäre ja auch völlig sinnfrei bei 2 oder mehr verschiedenen IP Netzen die z.B. durch Routing (Segmentierung) gewollt getrennt werden.Der Denkfehler den du begehst ist das du annimmst das Blocking käme von der Firewall, was aber natürlich unsinnig ist, denn es ist im Routing systembedingt wie auch oben schon richtig gesagt wurde. Ein einfacher Router ganz ohne Firewall macht es ebenso. Zudem siehst du diesbezüglich auch nix im Log.
Mit "Belastung" oder Performance hat das also beim Routing rein gar nichts zu tun!
In einem Bridging, also Layer 2, Design einer Firewall sähe das natürlich anders aus. Zu deinem o.a. verwendeten Firewall Design machst du ja leider keinerlei hilfreiche Angaben.
P.S.:
".255" ist nur ein kleiner Ausschnitt von Broadcast Adressen die sich nur auf das letzte Oktet einzig bei einem /24er Prefix beziehen! Andere Masken haben bekanntlich völlig andere Broadcast IPs. Insofern ist diese dedizierte Angabe zum Thema des Threads etwas sinnfrei, aber egal.
Broadcast Adressen sind also immer abhängig von der verwendeten Subnetzmaske. Desweiteren gibt es noch einen All Net Broadcast mit 4mal .255 wie ihn z.B. DHCP verwendet. Wenn schon denn schon...
https://de.wikipedia.org/wiki/Broadcast
Hättest du einfach nur einmal einen Wireshark oder die Packet Capture Funktion auf deiner Firewall angeschmissen siehst du sowas alles selber in deinem Netzwerk.
1
Ich schließe mich dem an, die Aussage ist so erstmal Schwachsinn. Einzig übermäßige Broadcasts, Broadcaststürme bzw. DDoS-Attacken könnte man dabei im Blick haben.
2
Hallo.
ich stimme @Avoton voll zu.
Ohne Broadcast funktioniert ein Netzwerk nicht. Und er ist auf der "Broadcast-Domäne" begrenzt. Er verlässt also das Subnetz nicht.
Im Normalfall empfängt die FW die Broadcast-Daten, wertet sie wie jeder andere Netzwerk-Teilnehmer aus und macht sonst nichts weiter damit.
Ohne Broadcast ist die FW blind im Netzwerk.
Jürgen
ich stimme @Avoton voll zu.
Ohne Broadcast funktioniert ein Netzwerk nicht. Und er ist auf der "Broadcast-Domäne" begrenzt. Er verlässt also das Subnetz nicht.
Im Normalfall empfängt die FW die Broadcast-Daten, wertet sie wie jeder andere Netzwerk-Teilnehmer aus und macht sonst nichts weiter damit.
Ohne Broadcast ist die FW blind im Netzwerk.
Jürgen
3
Erstmal Danke für das Feedback.
Ich wollte der Aussage erstmal offen gegenüberstehen und habe das Szenario in OPNsense nachgestellt. In dem Log werden eben auch .255er Paket per "Default deny / state violation rule" verworfen, was ich nie wirklich in Frage gestellt hatte, läuft ja alles.
Nur fand ich die Aussage, die Performance der Firewall würde darunter leiden, als fragwürdig.
Ich wollte der Aussage erstmal offen gegenüberstehen und habe das Szenario in OPNsense nachgestellt. In dem Log werden eben auch .255er Paket per "Default deny / state violation rule" verworfen, was ich nie wirklich in Frage gestellt hatte, läuft ja alles.
Nur fand ich die Aussage, die Performance der Firewall würde darunter leiden, als fragwürdig.
Moin,
Deine Frage zeigt, daß Du nochmal an deinem verständnis für IP-Netzwerke arbeiten solltest. Wie die Kollegen schon sagten:
Man braucht daher i.d.R keine extra Regel, um das propagieren von Brodcasts zu reglementieren, weil die Firewall, die i.d.R. auch routet diese Brodcasts normalerweise nicht auf die andere Seite läßt.
Was anderes ist es, wenn die Firewall innerhalb eines IP-Netzes filtert, d.h. sie auf beiden Seiten dasselbe IP-netz hat, muß man natürlich Broadcasts druchlassen oder filtern, je nachdem was Ziel dieser netzwerkinternen trennung ist. Alelrdings werden Firewall selten in so eine Konstallation als Filter innerhalb des gleichen IP-netzes eingesetzt.
Broadcaststürme, wie es einige Kollegen erwähnt haben sind nur eine Folge einer Fehlkonfiguration des Netzwerks (Switche, Leitungen, VLANS, etc.). Diese tangieren i.d.R. die Firewall nur insofern, als daß sie nicht mit anderen Netzwerkteilnehmern nciht mehr oder nru eingeschränkt kommunizieren kann. Die funktion als Firewall wird dadruch kaum tangiert.
lks
PS: Ich mache für Broacast i.d.R keine Spezialbehandlung.
Deine Frage zeigt, daß Du nochmal an deinem verständnis für IP-Netzwerke arbeiten solltest. Wie die Kollegen schon sagten:
- Broadcasts sind essentiell für das korrekte Funktionieren von IP-Netzwerken.
- Broadcasts werden i.d.R. nicht über Routergrenzen hinweg propagiert.
- Und die .255 korreliert nur dann mit einem Broadcast, wenn man auch ein /24-Netz hat (Manche sagen auch Class_C dazu).
Man braucht daher i.d.R keine extra Regel, um das propagieren von Brodcasts zu reglementieren, weil die Firewall, die i.d.R. auch routet diese Brodcasts normalerweise nicht auf die andere Seite läßt.
Was anderes ist es, wenn die Firewall innerhalb eines IP-Netzes filtert, d.h. sie auf beiden Seiten dasselbe IP-netz hat, muß man natürlich Broadcasts druchlassen oder filtern, je nachdem was Ziel dieser netzwerkinternen trennung ist. Alelrdings werden Firewall selten in so eine Konstallation als Filter innerhalb des gleichen IP-netzes eingesetzt.
Broadcaststürme, wie es einige Kollegen erwähnt haben sind nur eine Folge einer Fehlkonfiguration des Netzwerks (Switche, Leitungen, VLANS, etc.). Diese tangieren i.d.R. die Firewall nur insofern, als daß sie nicht mit anderen Netzwerkteilnehmern nciht mehr oder nru eingeschränkt kommunizieren kann. Die funktion als Firewall wird dadruch kaum tangiert.
lks
PS: Ich mache für Broacast i.d.R keine Spezialbehandlung.
2
@Lochkartenstanzer
Ich lerne gern dazu.
Die Frage ist nun, was mache ich mit dem, der die Aussage tätigte?
Ich lerne gern dazu.
Die Frage ist nun, was mache ich mit dem, der die Aussage tätigte?
Ignorieren oder seine Aussage korrigieren, weil die Aussage sachlich ja nachweislich per se falsch ist!
Ab in die Kadaveranstalt, Seife draus machen.
4
1Zitat von @nachgefragt:
@Lochkartenstanzer
Ich lerne gern dazu.
Die Frage ist nun, was mache ich mit dem, der die Aussage tätigte?
@Lochkartenstanzer
Ich lerne gern dazu.
Die Frage ist nun, was mache ich mit dem, der die Aussage tätigte?
Nachschulen.
lks
1
Ich komme nicht umhin, in einer Hinsicht für den TO "eine Lanze zu brechen", weil er sich völlig zu Recht an etwas stößt.
Richtig ist zunächst das, was alle Vorkommentatoren bereits umfassend dargestellt haben: In einem lokalen Netzwerk sind Broadcast für dessen reibungslose Funktion absolut richtig, wichtig, und auch nötig. Diese Broadcasts als solche unterbinden zu wollen, wäre daher völlig sinnfrei.
Obschon das alles stimmt, ist das eigentliche (praktische) Problem, an dem sich der TO stört, bisher übergangen und / oder ignoriert worden. Das hat nämlich nichts mit den Broadcasts an sich, sondern damit zu tun, wie die OPNsense mit einem regulären grundsatzkonformen Verhalten umgeht.
Grundsatzkonform ist, wenn das Gateway die Broadcast seines lokalen Netzwerks verwirft und nicht weiterleitet (Sonderkonfigurationen wie bei Bridging, DHCP-Helper etc. außer Acht gelassen). Das Verwerfen ist somit eine Verhaltensweise, die keiner erst zu konfigurierenden Routing-/Firewall-Regel bedarf und somit auch keines weiteren Aufhebens. Denn alle "Wissenden" wissen, dass das bei einem grundsatzkonformen Verhalten so ist.
Hingegen hat die OPNsense die wunderschöne Eigenheit, dieses eigentlich nicht weiter erwähnenswerte Verwerfen dennoch mit einem Log-Eintrag der Welt kundzutun. Hierdurch wird, insbesondere einem Neuling im Thema, suggeriert, hier müsse irgendwie gehandelt werden, wenngleich einfach nur das Log "zuge..." wird - um es einmal höchst vornehm auszudrückken. Das kann einerseits eben irritieren, aber andererseits vor allem ziemlich nerven. Und das größte Problem dabei ist, dass dies mit der letzten, festeingebauten Routingregel (= Generalverwerfungsregel) propagiert wird. Und gerade, weil Broadcasts so essentiell in einem Netzwerk sind, kann bereits ein Gerät ganz, ganz viele solche Log-Einträge ohne jeden Erkenntniswert produzieren.
Es mag ja richtig sein, dass das Verwerfen der Broadcasts am Gateway technisch und sachlich dem entspricht, wenn alles, was zuvor nicht erlaubt oder besonders verworfen worden ist, spätestens an dieser Stelle sein jehes Ende findet. Deshalb wird es ja spätestens auch im Zuständigkeitsbereich der Generalverwerfungsregel abgearbeitet. Aber muss das im Falle der Broadcasts wirklich propagiert werden? Ich tendiere hier ganz klar zu einem Nein!
Um die "lästige Plage" dieser überflüssigen Propagierungen im Log zu unterbinden, gibt es nur eine vernünftige Lösung auf der OPNsense: Eine Regel konfigurieren, die diese Broadcasts ausdrücklich blockt und bei der die Protokollierung deaktiviert wird. Ist diese Regel die allerletzte aller abzuarbeitenden Regeln vor der festeingebauten Generalverwerfungsregel, dann wird lediglich eine logische Sekunde vor der Generalverwerfungsregel eingegriffen und die sinnlose Befüllung des Logs effektiv unterbunden.
In dieser Hinsicht macht es sehr wohl einen Sinn, eine solche Regel gegen Broadcasts einzufügen, die einzig und allein dem Zweck der Bekämpfung eines überflüssigen Protokollierens dient.
Viele Grüße
HansDampf06
PS1: Ich hatte erst dieser Tage diese Situation, dass nach Einrichtung eines neuen VLAN's für isoliert zu benutzenden Arbeitsrechner einer dieser Arbeitsrechner mit lauter solchen Broadcast-Verwerfungsinfos das Log aufblähte. Diese Infoüberflutung versperrt zugleich - gerade in der Liveansicht - den Blick auf das Wesentliche, nämlich die eigentlich interessierenden Log-Einträge, weil diese in der Flut der Broadcast-Verwerfungsinfos untergehen. Zusammenhänge werden durch das räumliche Auseinanderreißen schwerer erkennbar. Zudem werden die Log-Einträge zentral aufgezeichnet, so das diese überflüssigen Infos die Log-Dateien unnötig aufblähen. Mit der beschriebenen Verwerfungsregel ist jetzt "angenehme Ruhe".
PS2: In taktischer Hinsicht ist es ausgesprochen hilfreich, sich von Fall zu Fall zu überlegen, eine bestimmte Regel auf mehrere aufzusplitten. Dadurch kann das Protokollierungsverhalten feingranular gesteuert werden, was insbesondere bei einer Log-Aufzeichnung die betreffenden Log-Dateien auf das begrenzt, was als wichtig erachtet wird. Freilich hängt das davon ab, welchen Aufgaben / Zielen die Log-Aufzeichnung dienen soll. Geht es um forensische Aspekte, wird wohl tendenziell ein größerer Protokollierungsumfang benötigt werden, als wenn es nur um das Aufspüren von Anpassungsbedürfnissen für die konfigurierten Regeln geht.
Richtig ist zunächst das, was alle Vorkommentatoren bereits umfassend dargestellt haben: In einem lokalen Netzwerk sind Broadcast für dessen reibungslose Funktion absolut richtig, wichtig, und auch nötig. Diese Broadcasts als solche unterbinden zu wollen, wäre daher völlig sinnfrei.
Obschon das alles stimmt, ist das eigentliche (praktische) Problem, an dem sich der TO stört, bisher übergangen und / oder ignoriert worden. Das hat nämlich nichts mit den Broadcasts an sich, sondern damit zu tun, wie die OPNsense mit einem regulären grundsatzkonformen Verhalten umgeht.
Grundsatzkonform ist, wenn das Gateway die Broadcast seines lokalen Netzwerks verwirft und nicht weiterleitet (Sonderkonfigurationen wie bei Bridging, DHCP-Helper etc. außer Acht gelassen). Das Verwerfen ist somit eine Verhaltensweise, die keiner erst zu konfigurierenden Routing-/Firewall-Regel bedarf und somit auch keines weiteren Aufhebens. Denn alle "Wissenden" wissen, dass das bei einem grundsatzkonformen Verhalten so ist.
Hingegen hat die OPNsense die wunderschöne Eigenheit, dieses eigentlich nicht weiter erwähnenswerte Verwerfen dennoch mit einem Log-Eintrag der Welt kundzutun. Hierdurch wird, insbesondere einem Neuling im Thema, suggeriert, hier müsse irgendwie gehandelt werden, wenngleich einfach nur das Log "zuge..." wird - um es einmal höchst vornehm auszudrückken. Das kann einerseits eben irritieren, aber andererseits vor allem ziemlich nerven. Und das größte Problem dabei ist, dass dies mit der letzten, festeingebauten Routingregel (= Generalverwerfungsregel) propagiert wird. Und gerade, weil Broadcasts so essentiell in einem Netzwerk sind, kann bereits ein Gerät ganz, ganz viele solche Log-Einträge ohne jeden Erkenntniswert produzieren.
Es mag ja richtig sein, dass das Verwerfen der Broadcasts am Gateway technisch und sachlich dem entspricht, wenn alles, was zuvor nicht erlaubt oder besonders verworfen worden ist, spätestens an dieser Stelle sein jehes Ende findet. Deshalb wird es ja spätestens auch im Zuständigkeitsbereich der Generalverwerfungsregel abgearbeitet. Aber muss das im Falle der Broadcasts wirklich propagiert werden? Ich tendiere hier ganz klar zu einem Nein!
Um die "lästige Plage" dieser überflüssigen Propagierungen im Log zu unterbinden, gibt es nur eine vernünftige Lösung auf der OPNsense: Eine Regel konfigurieren, die diese Broadcasts ausdrücklich blockt und bei der die Protokollierung deaktiviert wird. Ist diese Regel die allerletzte aller abzuarbeitenden Regeln vor der festeingebauten Generalverwerfungsregel, dann wird lediglich eine logische Sekunde vor der Generalverwerfungsregel eingegriffen und die sinnlose Befüllung des Logs effektiv unterbunden.
In dieser Hinsicht macht es sehr wohl einen Sinn, eine solche Regel gegen Broadcasts einzufügen, die einzig und allein dem Zweck der Bekämpfung eines überflüssigen Protokollierens dient.
Viele Grüße
HansDampf06
PS1: Ich hatte erst dieser Tage diese Situation, dass nach Einrichtung eines neuen VLAN's für isoliert zu benutzenden Arbeitsrechner einer dieser Arbeitsrechner mit lauter solchen Broadcast-Verwerfungsinfos das Log aufblähte. Diese Infoüberflutung versperrt zugleich - gerade in der Liveansicht - den Blick auf das Wesentliche, nämlich die eigentlich interessierenden Log-Einträge, weil diese in der Flut der Broadcast-Verwerfungsinfos untergehen. Zusammenhänge werden durch das räumliche Auseinanderreißen schwerer erkennbar. Zudem werden die Log-Einträge zentral aufgezeichnet, so das diese überflüssigen Infos die Log-Dateien unnötig aufblähen. Mit der beschriebenen Verwerfungsregel ist jetzt "angenehme Ruhe".
PS2: In taktischer Hinsicht ist es ausgesprochen hilfreich, sich von Fall zu Fall zu überlegen, eine bestimmte Regel auf mehrere aufzusplitten. Dadurch kann das Protokollierungsverhalten feingranular gesteuert werden, was insbesondere bei einer Log-Aufzeichnung die betreffenden Log-Dateien auf das begrenzt, was als wichtig erachtet wird. Freilich hängt das davon ab, welchen Aufgaben / Zielen die Log-Aufzeichnung dienen soll. Geht es um forensische Aspekte, wird wohl tendenziell ein größerer Protokollierungsumfang benötigt werden, als wenn es nur um das Aufspüren von Anpassungsbedürfnissen für die konfigurierten Regeln geht.
2
https://www.duden.de/rechtschreibung/jaeh
Wenn man das Logging der Default Blocking Rules im Setup abschaltet ist das Logging dieser Broadcasts ausgeschaltet und damit das o.a. "Problem" gelöst. (Beispiel pfSense)
Wenn man das Logging der Default Blocking Rules im Setup abschaltet ist das Logging dieser Broadcasts ausgeschaltet und damit das o.a. "Problem" gelöst.
(Beispiel pfSense)
@HansDampf06
Vielen Dank für die Antwort, auch für deine Sichtweise zu der du Stellung beziehst. Ich hatte die Frage bewusst so eingestellt, zumal auch ich mich immer wieder neu bemühe andere Sichtweisen zuzulassen und offen zu bleiben.
Jedenfalls kann mich mir jetzt eine unabhängige Meinung bilden.
In dem Fall unterstütze ich Kollegen in ein paar Themen, welche meine Aufmerksamkeit geweckt hatten. Was da vom Herstellersupport für Antworten und Aufforderungen kommen, kann ich nicht mehr in Worte fassen.
Broadcast
Die Kommentare zum Broadcast sind eindeutig und unabhängig.
Von Firewallexperten würde ich mir also ähnliche Antworten erwarten, wenn man vorhat, den Broadcast zu unterbinden.
Broadcast Logging
Das Thema betrifft nicht nur OPNsense, auch andere Firewalls loggen 255er Pakete. Das dies aber der Grund sei, dass die Firewall ihrer Funktion nicht mehr nachkommt, stelle ich in Frage.
PS1
Den Log Filter der OPNsense gut finde, ich komme gut klar damit.
PS2
Das sehe ich auch so, daher, solange ich keinen Anlass sehe den Log einzuschränken, nehme ich eher alles was mir für eine Analyse weiterhelfen kann.
@alle
Danke für euer Feedback und ein schönes Wochenende!
Vielen Dank für die Antwort, auch für deine Sichtweise zu der du Stellung beziehst. Ich hatte die Frage bewusst so eingestellt, zumal auch ich mich immer wieder neu bemühe andere Sichtweisen zuzulassen und offen zu bleiben.
Jedenfalls kann mich mir jetzt eine unabhängige Meinung bilden.
In dem Fall unterstütze ich Kollegen in ein paar Themen, welche meine Aufmerksamkeit geweckt hatten. Was da vom Herstellersupport für Antworten und Aufforderungen kommen, kann ich nicht mehr in Worte fassen.
Broadcast
Die Kommentare zum Broadcast sind eindeutig und unabhängig.
Von Firewallexperten würde ich mir also ähnliche Antworten erwarten, wenn man vorhat, den Broadcast zu unterbinden.
Broadcast Logging
Das Thema betrifft nicht nur OPNsense, auch andere Firewalls loggen 255er Pakete. Das dies aber der Grund sei, dass die Firewall ihrer Funktion nicht mehr nachkommt, stelle ich in Frage.
PS1
Den Log Filter der OPNsense gut finde, ich komme gut klar damit.
PS2
Das sehe ich auch so, daher, solange ich keinen Anlass sehe den Log einzuschränken, nehme ich eher alles was mir für eine Analyse weiterhelfen kann.
@alle
Danke für euer Feedback und ein schönes Wochenende!
Also meine Sophos listet Broadcasts ebenfalls als Verworfen auf, das hätte ich jetzt nicht als außergewöhnlich empfunden. Ist das eher die Ausnahme als die Regel?
Die Log von solchen Dingen zu befreien kann sinnvoll sein, z.B. wenn ich, ohne konkretes Ziel, die Logs wirklich komplett sichte. Das würde ich aber eher als Ausnahme sehen, wenn ich nur nach spezifischen Dingen suche oder ein Auswertungssystem habe dann denke ich, sollte man das nicht unmittelbar filtern. Ich würde erwarten, das die Firewall-Logs hauptsächlich dieses "Hintergrundrauschen" beinhalten und ich würde die Ausgabe filtern wollen, wenn ich etwas suche.
Und überhaupt: Früher waren das schließlich alles erfolgreich abgewehrte Hacker-Angriffe laut Norton
Die Log von solchen Dingen zu befreien kann sinnvoll sein, z.B. wenn ich, ohne konkretes Ziel, die Logs wirklich komplett sichte. Das würde ich aber eher als Ausnahme sehen, wenn ich nur nach spezifischen Dingen suche oder ein Auswertungssystem habe dann denke ich, sollte man das nicht unmittelbar filtern. Ich würde erwarten, das die Firewall-Logs hauptsächlich dieses "Hintergrundrauschen" beinhalten und ich würde die Ausgabe filtern wollen, wenn ich etwas suche.
Und überhaupt: Früher waren das schließlich alles erfolgreich abgewehrte Hacker-Angriffe laut Norton
2Zitat von @HansDampf06:
Ich komme nicht umhin, in einer Hinsicht für den TO "eine Lanze zu brechen", weil er sich völlig zu Recht an etwas stößt.
Ich komme nicht umhin, in einer Hinsicht für den TO "eine Lanze zu brechen", weil er sich völlig zu Recht an etwas stößt.
Ich glaube, wir haben den TO anders verstanden als Du.
ich mente zu verstehen, daß er gefagt, hat, ob er an den Broadcasts der Stationen im netz etwas drehen muß, damit nicht so viele bei der Firewall ankommen und diese "stören". Da ist ist die Antwort indeutig nein. Firewall müssen das abhandeln können und wenn das Logging nicht paßt, muß man das halt anpassen.
Broadcasts selbst sind essentiell für das funktionieren eines CSMA-Netzes wie Ethernet, was heutzutage Standard ist (CA oder CD is egal), auch wenn manche Sationen manchmal der meinung sind, allen im netz ihre Geschichten zu erzählen.
Von daher waren die o.g. Antworten eigentlich schon korrekt. Das Behandeln und Logging in der Firewall ist eine ganz andere Baustelle.
lks
2Zitat von @ukulele-7:
Also meine Sophos listet Broadcasts ebenfalls als Verworfen auf, das hätte ich jetzt nicht als außergewöhnlich empfunden. Ist das eher die Ausnahme als die Regel?
Ich kann dir als langjähriger Sophos Nutzer sagen, dass es nie anders war, in einer Umgebung welche relativ gleich geblieben ist. Logs exportiere ich i.d.R., da die Bortmittel unübersichtlich sind.Also meine Sophos listet Broadcasts ebenfalls als Verworfen auf, das hätte ich jetzt nicht als außergewöhnlich empfunden. Ist das eher die Ausnahme als die Regel?
Das Verhalten kann ich auch in OPNsense nachstellen, daher halte ich es nach wie vor für gewöhnlich die Pakete im Log zu sehen.
Doch als ich lesen musste was mein Kollege vom Support geantwortet bekam, war ich erstmal "überrascht", hielt inne und verfasste aus Neugier diese Frage hier.
Jetzt fehlen mir noch mehr die Worte, dass sowas von Firewall-Experten als Antwort kommt. Dein Vorschlag Seife aus diesen Leuten machen kann ich vielleicht nur so umsetzten, mit Gewissheit beurteilen zu können wer uns da gegenübersitzt und den Schwamm drüber zu ziehen.
Zitat von @aqui:
Wenn man das Logging der Default Blocking Rules im Setup abschaltet ist das Logging dieser Broadcasts ausgeschaltet und damit das o.a. "Problem" gelöst. (Beispiel pfSense)
Wenn man das Logging der Default Blocking Rules im Setup abschaltet ist das Logging dieser Broadcasts ausgeschaltet und damit das o.a. "Problem" gelöst.
(Beispiel pfSense)Dann kippt man aber sprichwörtlich das Kinde mit dem Bade aus, weil diese Regel gar nichts mehr ins Log schreibt. Das erachte ich als kontraproduktiv, wenn es nur um eine bestimmte nicht benötigte Log-Info geht. Selektives Handeln ist da das Gebot der Stunde.
Viele Grüße
HansDampf06
PS: Ein Dreiphasenkasper
kennt die Bedeutung einer "sichtbaren Trennstrecke", und das ganz ohne Duden ... 
Zitat von @nachgefragt:
Wie bewertet ihr die Aussage, dass dieser Broadcast Traffic eine Belastung für die Firewall sei und man den Broadcast unterbinden müsse, sonst leidet die Performance der Firewall darunter?
Wie bewertet ihr die Aussage, dass dieser Broadcast Traffic eine Belastung für die Firewall sei und man den Broadcast unterbinden müsse, sonst leidet die Performance der Firewall darunter?
Moin,
wenn man nur ein Bauchgefühl hat, kann man auch nachmessen. Häng' ein Gerät mit wireshark ins Netzwerksegment, filter nach Broadcast und rufe dann die Statistik auf:
- wireshark starten
- Displayfilter auf eth.dst == ff:ff:ff:ff:ff:ff setzen
- Menü Statistiken -> I/O Graph
- nicht benötigte Graphen löschen, die y-Achse auf bit setzen
- der Display-Filter sollte aus der Aufzeichnung gesetzt sein, sonst nachtragen
- voilà
Falls der Graph sehr große Ausreißer nach oben hat und die gedachte Grundlinie schwer erkennbar sein sollte, kann die Ansicht auf Logarithmische Skala gestellt werden.
Die MAC-Adresse ff:ff:ff:ff:ff:ff ist die Layer2-Entsprechung für Broadcast für die .255-IP-Adressen. Vorteil bei Layer2: die Netzmaske ist uninteressant.
So weißt du, mit welchem Broadcast-Traffic deine Firewall konfrontiert wird und ob das die Firewall wirklich tangieren sollte (wenn 2 kb/s wie im Beispiel auf ein 1Gb/s-Interface trifft - so what?).
Viele Grüße
TA
P.S. "Performance der Firewall" kann natürlich auch bedeuten, wie schnell Logs geschrieben, gefiltert und ausgewertet werden können - das hat dann nur indirekt mit dem einstürmenden BC-Traffic zu tun. Dass die FW den Traffic auswerten und ggf. routen kann, dafür sollte sie ausgelegt sein.
1Dann kippt man aber sprichwörtlich das Kinde mit dem Bade aus, weil diese Regel gar nichts mehr ins Log schreibt.
Das ist natürlich Unsinn, denn das Setting betrifft ausschliesslich nur die Default Blocking Regeln was die "Broadcast Anzeige" inkludiert! Es unterdrückt nicht die die im Regelwerk der Firewall erstellt wurden! Einfach mal ausprobieren. Ztat von @TwistedAir
So weißt du, mit welchem Broadcast-Traffic deine Firewall konfrontiert wird und ob das die Firewall wirklich tangieren sollte (wenn 2 kb/s wie im Beispiel auf ein 1Gb/s-Interface trifft - so what?).
So weißt du, mit welchem Broadcast-Traffic deine Firewall konfrontiert wird und ob das die Firewall wirklich tangieren sollte (wenn 2 kb/s wie im Beispiel auf ein 1Gb/s-Interface trifft - so what?).
Naja, wenn der broadcast-traffice anfängt die Firewall zu beeinträchtigen, sind vorher schon viele andere Systeme "umgefallen" im Netz. Da bekommt man dann nicht mehr mit, daß die Firewall "weg" ist.
lks
1Zitat von @aqui:
Ich bin mir an einem Freitag nicht sicher, ob Du mich nur aus Spaß nicht verstehen willst ...Dann kippt man aber sprichwörtlich das Kinde mit dem Bade aus, weil diese Regel gar nichts mehr ins Log schreibt.
Das ist natürlich Unsinn, denn das Setting betrifft ausschliesslich nur die Default Blocking Regeln aber eben nicht die die im Regelwerk der Firewall erstellt wurden! Einfach mal ausprobieren. Vorsorglich zitiere ich eine Standardempfehlung von Dir: "lesen und verstehen" meines Kommentars von gestern!
Viele Grüße
HansDampf06
