Firewall Audit mit über 200 Regeln

Moin,

egal wie du die Aufgabe bekommen hast, du musst wohl oder Übel einmal die Regeln Stück für Stück durchgehen und analysieren was da genau passiert. Meiner Erfahrung nach sind bei den gewachsenen Regeln häufig Regeln dabei, die du auflösen könntest, wenn du einen Host in eine andere Regel verschiebst. Ein Automatismus wird dir die Arbeit nicht abnehmen können. Am Ende musst du entscheiden was du willst und nicht.

Da kommt jetzt halt die ganze Zeit auf dich zu, die vorher vernachlässigt wurde. Mach es einmal, dokumentiere es ordentlich und aktualisiere deine Dokumentation. Dann musst du nur alle 6 Monate deine Dokumentation aus der Schublade holen.

Gruß
Doskias

Genau so.

Ich schau auch regelmäßig drüber. Gibt es dort Regeln die ich nicht kenne und meine Kollegen davon auch nix wissen, deaktiviere ich sie und warte 2-3 Monate ab. Kommt kein Feedback, kann se gellöscht werden.

Gruss

Servus!
Der Audit macht auf jeden Fall Sinn - auch Regelmäßig...

Wir haben hier Barracuda - dort gibt es einen Rule Usage Report.
Sophos kenn ich nicht - aber evtl. gibt's da auch so was.

Dann kannst hier evtl. schon mal ausdünnen

Grüße

Moin,

ich kann @126231 nur zustimmen.
Ich verwaltet mittlerweile ein Barracuda System mit 50 Firewalls und gut 2k Regeln.

Unter Sophos würde ich aus eigener Erfahrung auch vor einem riesen Haufen Arbeit stehen.

Gruß
Spirit

Das komtm immer drauf an, wie granular man die regeln macht. Ob man für jedes Objekt eigen Regeln definiert oder ob man "allgemeine" Regeln für viele Objekte gleichzeitig definiert. Es gibt auch kleine Firmen mit einem "großen" Regelsatz und große Firmen mit einem kleine Regelsatz.

Man könten das natürölich auf die harte Tour konsolidieren, indem man alle Regeln erstmal inaktiv schaltet und einen deny-all-Standard scharfschlltet. Dann solten alle aufschreiben, bei denen etwas ncht geht und dann kann man schauen, welche regeln überhaupt noch gebraucht werden.

Es passiert nämlich auch oft, daß temporäre Regeln definiert werden und derjenige dann vergißt, die wieder rauszunehmen. So sammelt sich dann irgendwann ein grißer Wust an überflüssigen regeln an, wei ljeder neue regeln dazupackt, statt die alten ggf. wieder rauszunehmen.

lks

hi

ich mache auch alle 6 Monate einen Audit, lasse den allerdings durch einen Dienstleister durchführen, weil der mit anderen Augen drauf schaut.
Wichtigstes Instrument ist IMHO erst mal der HitCount und LastHit einer Regel. Viele existieren, werden aber nicht mehr benötigt oder ziehen nicht weil eine andere Regel davor das schon abfrühstückt bzw zu weit gesetzt wurde.

Er schaut sich das dann an und macht einerseits Empfehlungen bei dingen die ihm auffallen, andererseits Stellt er mir einfach Fragen dazu. Dadurch spült sich schon immer wieder was hoch, weil man selbst hier einfach einen anderen Blick auf die Dinge hat und eine andere\neutrale Betrachtung hier eine weitere Perspektive auf die Dinge gibt.

Jede Regel die irgendwo ein ALL in SRC, DST oder PORT\SERVICE stehen hat ist besonders zu betrachten, alles was in oder aus "roten" Netze geht ebenfalls.
Jede Regel muss kommentiert sein. Datum Erstellung, letzte Änderung und Ticketnummer dazu muss vorhanden sein. Kein Ticket? Deaktivieren.
So kann man sicher sein das die temporären Regeln wieder rausfliegen . Ausserdem kann man dann alle Regeln seit dem letzten Audit betrachten.

Was IMHO auch sehr hilft, ist die Regeln thematisch zu Gruppieren. Wir haben in der Netzwerksegmentierung alle Regeln IN ein VLAN gruppiert. Also alles was IN das Servernetz geht ist in der Gruppe Servernetz.
Dann fällt beim durchschauen recht gut auf ob irgendwas redundant ist oder z.B eine Konsolidierung von ein paar Regeln erfolgen kann.
In der Firewall die ins Internet geht ist hingegen erst mal alles nach Abteilungen Gruppiert.
Dinge die die HR braucht, die Produktion usw.
Darunter kommen dann "allgemeine Regeln" die erst mal für alle gelten, wie z.B die generelle HTTP/HTTPS Out Regel, allgemein erlaubte Applikationen\Services usw.

Allerdings macht ein Audit auch nur Sinn wenn jemand dabei ist der das Konstrukt kennt und im Zweifelsfall auch sagen kann "Die Regel hatte zwar seit 4 Monaten keinen Hit, wird aber nur 1x im Jahr gebraucht beim Jahresabschluss" oder ähnliches.

Hallo,
wenn du etwas auditieren sollst/mußt, sollte es eine Dokumentation und Regeln geben nach denen du auditierst bzw. prüfst.

So wie es für mich klingt existiert beides nicht.
Auch enthält das Audit keine "Reperatur".

Also bleibt meines Erachtens nur der "lange" Weg:
1. Dokumentation des Istzustandes, d.h. fange mit den Netzwerkobjekten an, dann kommen die Regeln dran.
2. Welche Policies müssen auf der Firewall umgesetzt werden, dies muß auch schriftlich fixiert sein.
Jetzt beginnt das eigentliche Audit:
Fehler und unnötige und/oder unverständliche Einstellungen finden.
dem Auftraggeber Lösungen zur Fehlerbehebung/Verbesserung anbieten.

Gruß
CH

Hi,

200 Regeln sind nicht unbedingt viel bzw. es kann je nach Umgebung erforderlich sein, erheblich mehr zu verwalten.
Das Problem mit historisch gewachsenen Regelwerken ist meist, dass die einzelnen Regeln unterschiedliche Konzepte ohne Abstraktion verwirklichen und dadurch chaotisch und fehleranfällig sind.

Gerade wenn mehrere Firewall-Instanzen im Spiel sind, hat es sich für mich bewährt, das Regelwerk mithilfe von Aliasen und Aliasgruppen zu schematisieren. Die eigentlichen Regeln spiegeln dann nur technische Erfordernisse wider und sind entsprechend trivial auditierbar. Zugriffsrechte hingegen hingegen werden durch die Gruppierung der Aliase gewährt, was ebenfalls recht leicht auditierbar ist.

Beispiel: Es existiert ein Subnetz 1 mit Servern, die per SSH verwaltet werden müssen. Entsprechend gibt es zumindest auf der Firewall, an der das Netz anliegt (ggf. aber auch auf anderen relevanten), eine Regel, die der Aliasgruppe "Subnetz-1-SSH" Zugriff in dieses Netz auf Port 22 gewährt (Granularität und Namensschema natürlich nur beispielhaft). Diese und weitere Regeln ergeben sich also unmittelbar daraus, dass in bestimmten Netzen bestimmte Dienste bereitgestellt werden und erschließen sich daher intuitiv. Der Alias eines zugreifenden Netzbereiches, z.B. "Admin-VPN", wird dann der Aliasgruppe "Subnetz-1-SSH" zugeordnet. Die Mitgliedschaften von "Admin-VPN" und die Mitglieder von "Subnetz-1-SSH" sind nachträglich gleichermaßen leicht zu ermitteln.

Grüße
Richard