Broadcast Datenverkehr .255 unterbinden

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.