Im Rahmen verschiedener Sicherheitsüberprüfungen führen wir ebenfalls sogenannte Configuration Reviews durch. Bei diesen wird die Konfiguration einer Komponente auf ihre Sicherheit hin untersucht. Das Prinzip einer solchen Analyse sowie die einhergehenden Schwierigkeiten sollen in diesem Beitrag illustriert werden.

Gehen wir davon aus, dass ein nicht näher bestimmtes Router-Produkt untersucht werden soll. Dieses pflegt Konfigurationseinstellungen auf der Kommandozeile entgegenzunehmen. Beispielsweise wird folgendes Kommando verwendet, um eine Netzwerkschnittstelle zu konfigurieren:

In gleicher Weise wird die persistente Konfiguration einer Konfigurationsdatei abgelegt, die auf die gleiche sequentielle Eingabe der unterschiedlichen Einstellungen zurückgreift. Dabei entspricht jede Zeile in der Konfiguration einer einzelnen Eingabe. Eine einzelne Eingabe weist dabei beispielsweise die folgende Struktur auf (die einzelnen Objekte werden zur Vereinfachung der Illustration voneinander getrennt dargestellt):

Solche Konfigurationseinstellungen sind bei verschiedenen Netzwerkprodukten im professionellen Sektor zu sehen. Bei add handelt es sich um ein Kommando, das verschiedene Argumente erwartet. Durch interface wird die neue Netzwerkschnittstelle hinzugefügt.

Dabei kommen nun verschiedene Parameter zum Tragen, welche eine Attributisierung des neu hinzuzufügenden Objekts zulassen. So wird mit dem Attribut -name der Name und mit -state=[ENABLED|DISABLED] der Status definiert. Zusätzlich wird mit -icmp=[ENABLED|DISABLED] die Unterstützung von ICMP-Kommunikationen und mit -mgmtAccess=[ENABLED|DISABLED] die Aktivierung des Zugriffs auf die Management-Schnittstelle spezifiziert.

• add
  • interface
    • name=<name>
    • state=[ENABLED|DISABLED]
    • icmp=[ENABLED|DISABLED]
    • mgmtAccess=[ENABLED|DISABLED]

Sicherheitstechnisch gesehen ist hierbei die Definition von -icmp bedenklich. Denn durch das Aktivieren dessen Unterstützung mit dem Wert ENABLED werden entsprechende protokollabhängige Angriffe möglich. Im Rahmen einer Config Review würde hier also besagte Einstellung beanstandet werden:

Um dieser Schwachstelle zu entgegnen, sollte ICMP deaktiviert werden, indem die Direktive -icmp=DISABLED zum Tragen kommt.

Viele Administratoren haben die Angewohnheit, in der Konfiguration nur jene Einstellung vorzunehmen, die sie explizit definieren wollen. Alle Einstellungen, die nicht zwingend beeinflusst werden sollen, werden ignoriert. Viele Produkte erfordern aber eine explizite Definition einer Einstellung und verwenden beim Ausbleiben einer solchen die durch den Hersteller vordefinierte Standardeinstellung. Diese sähe in diesem Fall wie folgt aus (der Standard ist durch geschweifte Klammern dargestellt):

Dies bedeutet, dass wenn also eine der Parameter -state, -icmp oder -mgmtAccess nicht definiert ist, die Vorauswahl genutzt wird. In diesem Fall werden damit aber entsprechende Sicherheitsrisiken aufgetan, wenn auf die explizite Deaktivierung von ICMP verzichtet wird. Denn ohne eine Definition wird das Protokoll standardmässig unterstützt. (In diesem Beispiel weist -name keine Standardeinstellung auf. Die Angabe ist entsprechend nicht optional. Sie hat jedoch keinen Einfluss auf die sicherheitsbezogene Analyse. Wir würden ein Ausbleiben jedoch aus betrieblichen Gründen dokumentieren.)

Standardeinstellungen erschweren Config Reviews entsprechend ungemein. Denn man muss nicht nur um alle möglichen Einstellungen und die definierten Einstellungen wissen, sondern es müssen ebenfalls die abwesenden Einstellungen und ihre Standardwerte bekannt sein. Jenachdem ist es jedoch besonders aufwendig, diese Standardwerte ausfindig zu machen. Sollte der Hersteller keine Dokumentation diesbezüglich vorweisen können, muss durch eine praktische Analyse des Produkts der aktuelle Stand determiniert werden.

Der generische Ablauf einer umfassenden Config Review gestaltet sich entsprechend wie folgt (unabhängig von Produkt und Format der Konfigurationsdateien):

1. Vorbereitungen
   1. Dokumentation aller Einstellungsmöglichkeiten
   2. Vermerk aller sicherheitsrelevanten Sicherheitseinstellungen
   3. Identifikation aller Standardeinstellungen bei optionalen/abwesenden Einstellungen
2. Analyse
   1. Identifikation aller expliziten Einstellungen
   2. Identifikation aller abwesenden Einstellungen
   3. Ableitung der abwesenden Einstellungen zu ihren Standardeinstellungen
3. Dokumentation
   1. Beschreibung aller gegebenen Fehleinstellungen (explizit definiert)
   2. Beschreibung aller fehlenden Fehleinstellungen (implizit abgeleitet)

Das Resultat einer Configuration Review eines Routing-Produkts könnte also folgendes Resultat zur Folge haben (Wir versuchen nach Möglichkeiten eine optische Darstellung von Fehleinstellungen bereitzustellen):

Oftmals umfassen die zu untersuchenden Konfigurationsdateien mehrere hundert Zeilen mit einer Vielzahl an Anweisungen und expliziten bzw. impliziten Argumenten. Diese zu analysieren ist sodann mit einem sehr hohen Aufwand verbunden. Um die Effizienz sowie die Genauigkeit der Untersuchung zu verbessern, verwenden wir je nach Möglichkeit auf die zu untersuchenden Produkte zugeschnittene Parser (z.B. Cisco IOS/PIX/ASA, Nortel Alteon OS, Citrix Netscaler, etc.). Diese analysieren die Anweisungen und helfen entsprechend bei der Umsetzung der Schritte 2.1 bis 2.3.

Sicherheitsrelevante bzw. sicherheitskritische Objekte werden sodann gemeldet und einer manuellen Untersuchung durch den Fachspezialisten unterzogen. Dadurch kann einerseits eine hohe Verarbeitungsgeschwindigkeit (durch Automatisierung) aber auch eine umfassende Genauigkeit (durch manuelle Nachprüfung) gewährleistet werden.

Über den Autor

Marc Ruef ist seit Ende der 1990er Jahre im Cybersecurity-Bereich aktiv. Er hat vor allem im deutschsprachigen Raum aufgrund der Vielzahl durch ihn veröffentlichten Fachpublikationen und Bücher – dazu gehört besonders Die Kunst des Penetration Testing – Bekanntheit erlangt. Er ist Dozent an verschiedenen Fakultäten, darunter ETH, HWZ, HSLU und IKF. (ORCID 0000-0002-1328-6357)