ASA Konfigs auf Konsistenz prüfen
Wir haben eine Reihe von ASAs im Einsatz, die auf Kundenwunsch gepflegt werden. Wie immer betreffen Änderungswünsche nur die Einrichtung von Freischaltungen, aber nie das Wegräumen von Altlasten. Für diesen Fall gibt es zwei Tools, die ich vorstellen möchte.
Information des Kunden
Zunächst ist es wichtig, den Kunden regelmäßig über die aktuelle Konfiguration zu informieren. Trivialerweise würde man ihm die Konfiguration zugänglich machen.
Aber das ist eine schlechte Idee, da die ASAs einiges an Konfiguration enthalten, die man nicht ständig durch die Gegend reichen möchte. Es gibt auch genug Fälle, wo eine ASA mehrere Kunden bedient (z.B. mehrere Hosting-VLANs). Dann darf natürlich keine Information über die Konfiguration für andere Kunden leaken.
Es ist also notwendig, sich auf die wesentlichen und interessanten Teile zu beschränken. In diesem Fall interessiert den Kunden, welche ACLs und welche NAT Regeln für ihn aktiv sind. Was den Kunden interessiert, hängt von den Interfaces ab, die ihm zugeordnet sind.
Das Script mkacl-from-asaconfig.pl liest auf Standardeingabe eine komplette abgespeicherte ASA-Konfig ein, erwartet als Argument die Liste der interessanten Interfaces (nameif) und gibt aus:
- die den Interfaces zugeordneten access-groupKommandos
- die den access-group zugeordneten access-list Einträge
- die den Interfaces zugeordneten nat Kommandos
- die dabei referenzierten object-group Definitionen
- die dabei referenzierten object Definitionen
Ganz praktisch sieht das dann so aus:
$ zcat /archiv/cf.asa.20180111.gz | mkacl-from-asaconfig.pl iks-lab : Written by enable_15 at 11:13:55.766 CET Thu Jan 11 2018 ! !!!!!! ! active ACLs at interfaces !!!!! access-group to_lab out interface iks-lab !!!!! ! ACLs !!!!! access-list to_lab extended permit ip object-group iks any access-list to_lab extended permit tcp any object obj-lab1 object-group http_s access-list to_lab extended permit tcp any object obj-lab2 object-group http_s ! !!!!!! ! extra NATs !!!!! !!!!! ! Object groups !!!!! object-group network iks network-object object o4-iks network-object object o6-iks ! object-group service http_s tcp port-object eq www port-object eq https ! !!!!! ! Objects !!!!! object network obj-lab1 host 192.168.91.10 nat (iks-lab,outside) static o4-lab1-public ! object network obj-lab2 host 192.168.91.11 nat (iks-lab,outside) static o4-lab2-public ! ... ! !!!!! ! Generated at Thu, 11 Jan 2018 13:35:03 +0100
Diese Auszüge können dem Kunden auf definiertem Wege (z.B. Kundenportal) zur Verfügung gestellt werden.
Es gestattet dem Kunden, sich selbst die aktuelle Konfiguration anzusehen und entlastet die Hotline bei uns.
Inkonsistenzen
Ein ganz anderer Teil des Problem sind Inkonsistenzen und Altlasten. Die Definition eines Objektes, das nicht verwendet wird, ist eine Inkonsistenz. Die Verwendung einer IP Adresse, die nicht mehr in Benutzung ist, ist eine Altlast. Beides soll gefunden werden.
Wie eine Konfiguration auszusehen hat, ist selbstverständlich Ansichtssache. Bei uns hat es sich als günstig herausgestellt, sämtliche IP Adressen in Objekten und Objektgruppen zu sammeln, damit diese schon allein anhand ihrer Benennung oder description auch noch Jahre später zugeordnet werden können. Nur mit klarer Zuordnung ist ein späterer Rückbau überhaupt möglich.
Das Script clean-asa-config.pl liest von der Standardeingabe eine komplette Konfigurationsdatei und listet auf, was unstimmig erscheint:
- Nicht mehr benutzte access-list, object, object-group. name, tunnel-group, class-map, transform-set, crypto map, ...
- Elemente, die verwendet werden, aber nicht definiert wurden, werden aufgelistet.
- Es wird das Anlegen von object oder name Definitionen empfohlen, wenn IPs direkt in der Konfiguration stehen.
- Ist bei Objekten ein DNS-Name zur IP hinterlegt, so wird geprüft, ob der Name noch zu dieser IP auflöst. Es ist nicht empfehlenswert, direkt mit fqdn statt host zu arbeiten, wenn man feststellen will, ob die intendierte Eintragung noch korrekt ist. fqdn sollte man nur bei dynamischen IPs benutzen.
- Bei name Definitionen wird geprüft, oben IP und Name noch per DNS zusammen passen.
- Da name Definitionen agnostisch gegenüber der Protokollfamilie sind, wird für IPv4 ein trailing dot am Namen empfohlen, bei IPv6 nicht.
- Ausgelaufene Zertifikate führen zur Empfehlung, den trust-point zu löschen.
- Ebenso soll man unvollständige crypto map Einträge löschen.
Die Ausgabe enthält:
- die Empfehlung incl, Begründung
- die direkt ausführbaren Kommandos, um die Empfehlung umzusetzen, ohne den Betrieb zu gefährden
- alle anderen Verwendungen des Namens oder der IP in der Konfiguration
Wenn Euch etwas auffällt, was man noch testen sollte oder könnte ...