"Die sich selbst pflegende Firewall"

Christian hatte gestern noch eine Idee, wie man dem bekannten Regelwerkwachstumsphänomen ein wenig Einhalt gebieten könnte:

Jede Paketfilterregel die etwas erlaubt, merkt sich, wie häufig es tatsächlich benutzt wird. Wird es für sagen wir mal zwei Wochen nicht benutzt, wird die Regel inaktiv geschaltet und zur Löschung vorgemerkt. Wird das Fehlen für einen Monat nicht bemerkt, wird die Regel komplett aus der laufenden Konfiguration genommen und abschliessend dem Admin zwecks Archivierung per Email zugesandt.

Diese Idee hat natürlich einen gewissen Reiz. Mit frei konfigurierbaren Timern für "inaktiv schalten" und "endgültig entfernen" würde das ein bekanntes Problem relativ zuverlässig lösen. Andererseits erhöht so ein Mechanismus wiederum die Komplexität des Subsystems "Firewall", wenn auch nur wenig.


Nach dem Lesen von Christians Beitrag fiel mir ein, wie man das mit - zum Beispiel - einer Cisco PIX oder ASA und unter Verwendung eines Unix- oder Linux-Servers (den man ja für den Betrieb zum Beispiel eines Nagios sowieso braucht) schon heute zumindest teilweise realisieren könnte. Man bräuchte im Grunde nur ein Login-Skript verfassen, welches eben jene Schritte ausführt, und zwar mittels eines einfachen regelmäßigen

show access-list | include (hitcnt=0)
clear access-list NAME counters

Auf dem das Skript ausführenden Server ließe sich eine Datenbank (oder auch eine einfache Textdatei; die heutzutage überhand nehmende Vorliebe, auf jedes Problem ohne Rücksicht auf Verluste mit einer relationalen Datenbank zu schießen, teile ich nicht) führen, welche die Veränderung dieser Ausgabe über die letzten n Male dokumentiert und vergleicht - kommt ein Eintrag dann zu oft und ununterbrochen in der Liste vor, erfolgt ein Hinweis an die Administratoren, sowie das Setzen eines Flags. Ändert sich dann nichts, wird die betreffende Regel schließlich entfernt, wie von Christian vorgeschlagen.

Oder zumindest wäre das so einfach, wenn nicht, seufz, die Ausgabe von "show access-list" sich von der Ausgabe eines "show running-config | include access-list" so nervtötend unterscheiden würde, sobald man Gruppen auf seiner Pix oder ASA benutzt (also praktisch immer)... unter Berücksichtigung dieser Tatsache müsste man das Skript schon um die vollständigen Ausgaben von "show access-list" und "show running-config | include access-list" erweitern und es diese Daten umständlich vergleichen lassen. Was wiederum genug Arbeit wäre, um die Realisierung des Ganzen in weitere Ferne rücken zu lassen. Erstmal.