judgedredd
Goto Top

PfSense Monitoring Firewall Rules

Hallo Zusammen,

im Einsatz ist eine pfSense (Version 2.4.0), auf der diverse FW-Regeln angelegt sind.
Es kommt ja immer mal wieder vor, das man zum testen oder Einführung einer neuen Software auch neue FW-Regeln benötigt werden.

Sollten die Tests abgeschlossen sein, oder eine Software wird nicht mehr benötigt, könnte man ja auch die FW-Regel entfernen.

So und hier kommt nun mein Beitrag ins Spiel.
Ich bin auf der Suche nach einer Möglichkeit, alle nicht benötigten FW-Regeln reglemäßig zu überprüfen.

Ich habe mir dazu auch schon die Funktion "Diagnostics / States" angesehen. Allerdings komme ich da nicht so recht weiter.
Mag sein, das es an mir liegt, mag aber auch sein, das die gewünschte Funktionalität nicht zur Verfügung steht.

Es soll also ein Report erzeugt werden, der mir alle FW-Regeln mit 0 (Null) States auflistet.

Gruß,
JudgeDredd

Content-ID: 353237

Url: https://administrator.de/contentid/353237

Ausgedruckt am: 25.11.2024 um 08:11 Uhr

aqui
aqui 30.10.2017 aktualisiert um 12:51:35 Uhr
Goto Top
zum testen oder Einführung einer neuen Software auch neue FW-Regeln benötigt werden.
Das ist zweifelsohne richtig wenn man ein wasserdichtes Umfeld hat.
...könnte man ja auch die FW-Regel entfernen.
Logische Konsequenz daraus und eine simple Binsenweisheit für einen Admin. face-wink
So und hier kommt nun mein Beitrag ins Spiel.
Oha...nun wirds spannend !
Ich bin auf der Suche nach einer Möglichkeit, alle nicht benötigten FW-Regeln reglemäßig zu überprüfen.
Ein toughes Unterfangen....!

Die Firewall kann ja logischerweise nicht von selber raten wann eine Regel mal wieder gebraucht wird oder nicht gebraucht wird. Da kann sie sich nur auf den Netzwerk Admin verlassen der ihr das beibringt. Kann ja sein das doch alle halbe Jahre mal ein Paket vorbeikommt...
Deshalb nutzt Admin ja auch immer Whitelists und keine Blacklists. OK...wieder Binsenweisheit.
Dein Ansatz ist aber richtig.
Du willst checken welche Regel über einen längeren Zeitraum einen 0 (Null) State aufweist. Hier musst du allerdings aufpassen, denn nach einem gewissen Idle Timeout setzt die Firewall den State immer auf 0. Geht z.B. ein User nach Hause der einen State getriggert hat geht der irgendwann nach Ablauf des Idle Timers auf 0. Ohne das würde der State Counter ins Unendliche gehen und die FW schlicht kein freies RAM mehr haben.
Du musst hier also zyklisch prüfen ob der 0er State kontinuierlich über einen längeren Zeitraum besteht um solche ungenutzen Regeln zu identifizieren.
Es gibt sowas aber in der pfSense, quasi sowas wie einen "Hit Counter". Guckst du hier:
https://forum.pfsense.org/index.php?topic=58803.0
bzw. etwas detailierter mit Lösung hier:
https://forum.pfsense.org/index.php?topic=97925.msg545345#msg545345
pfctl -vvsr ist also das was dich zum Ziel bringen sollte.
JudgeDredd
JudgeDredd 30.10.2017 um 13:54:09 Uhr
Goto Top
pfctl -vvsr ist also das was dich zum Ziel bringen sollte.
Ja, bis dahin bin ich auch gekommen. So habe ich mir die Rule-Number für den Syslog-Server Filter rausgesucht und soweit hat das auch funktioniert.

Deshalb nutzt Admin ja auch immer Whitelists und keine Blacklists. OK...wieder Binsenweisheit.
Jo, bei Blacklists kann ich mir das Blech für die pfSense auch gleich sparen face-wink

... denn nach einem gewissen Idle Timeout setzt die Firewall den State immer auf 0...
Dieser Absatz war aber bislang nicht Teil meines Wissens, für den Hinweis schonmal meinen Dank.

Mit dieser Info komme ich bestimmt wieder etwas weiter.
Heisst aber das ich den State Wert immer VOR Ablauf des Idle-Timeouts irgendwo zwischenspeichere und damit dann rechnen muss, wenn ich das Monitoring über einen längeren Zeitraum als der Idle definiert ist haben möchte (z.B. 1 Monat).

evtl. hast Du ja noch einen kleinen Tip, wo dieser "gewisse" Timeout in der pfSense definiert ist. Vielleicht lässt sich dieser ja sogar anpassen.
108012
108012 30.10.2017 um 23:30:00 Uhr
Goto Top
Hallo zusammen,

es wäre eventuell auch ganz nett wenn man sich einmal eine Probeumgebung, also ein Testnetzwerk
oder Netzwerklabor aufbaut und dies dann zum testen nimmt, das kann in einer DMZ oder einem
gesonderten Netzwerk sein, was völlig autark vom richtigen Produktivnetzwerk oder gar dem Firmen
LAN läuft und dort kann man dann sicherlich mittels VMs oder einem Testserver und PCs auch solche
Sachen und Versuche nachstellen. Nur ewig an den Firewallregeln für das LAN herum schrauben halte
ich für sagen wir einmal unproduktiv. Was kann schon groß passieren wenn man den Server und die
PCs aus dem Testnetzwerk kapert, man setzt sie wieder neu auf und gut ist es. Bei den Firewallregeln
für das LAN sieht es schon wieder anders aus.

Gruß
Dobby