© Allan Swart, 123RF

Wer sich zur Einhaltung von rigiden Compliance-Regeln verpflichtet, steht vor der Herausforderung, sie auch durchzusetzen. Inspec hilft dabei mit automatisierten Tests.

Zertifikate und Gütesiegel sind allgegenwärtig, diverse Bio-Bescheinigungen dominieren den Einkaufsalltag. Auch in der IT gilt: Je mehr Zertifizierungen ein Unternehmen für seine Dienste hat, als desto sicherer gilt seine Dienstleistung. Dabei ist diese Aussage so gar nicht haltbar, weil sie die Begriffe Sicherheit und Compliance gleichsetzt. Compliance und Security sind aber nicht dasselbe.

Es leuchtet ein, dass ein ausgedrucktes ISO-27001-Zertifikat, das an einer Wand in irgendeinem Büro hängt, nicht automatisch die Server der Firma sicherer macht, die das Zertifikat ausgestellt bekommen hat. Es bestätigt dem Unternehmen jedoch, dass es bestimmte Regeln und Standards implementiert hat, die Fehler und besonders Securityprobleme von vornherein verhindern sollen – etwa indem sie ihre Entstehung unmöglich machen.

Compliance ist also ein valides Werkzeug, um den sicheren Betrieb von jeder Art von IT strukturell zu ermöglichen oder zu erleichtern. Genau das ist es auch, was ISO 27001, BSI Grundschutz und die diversen anderen Zertifizierungsstellen der eigenen Klientel bescheinigen.

Mühsame Umsetzung

Wer schon mal daran beteiligt war, ein historisch gewachsenes System vom Kraut-und-Rüben-Betrieb auf strikte Compliance-Regeln umzustellen, kennt den damit einhergehenden Schmerz. Wo vorher Laisser-faire an der Tagesordnung war, entsteht anschließend ein starres Korsett aus vielen Anforderungen und Bedingungen, die die Arbeit des Admins – oft empfindlich – einschränken. Nicht jedem Serveradministrator gefällt das. Oft macht es schon die schiere Menge an Vorgaben schwierig. Wenn in einem Notfall ein Quick-Fix nötig ist, sehen genug Compliance-Regeln Ausnahmen vor, die später durch richtige Lösungen zu ersetzen wären. Jedoch: Nichts hält bekanntlich länger als ein Provisorium.

Regelmäßige Tests

Für Unternehmen ergibt sich daraus ein handfestes Problem. Wer nicht gerade ein neues Setup auf der grünen Wiese plant, muss für eine Zertifizierung oft Compliance-Regeln implementieren, die den bestehenden Gepflogenheiten komplett zuwiderlaufen. Und um die Versprechungen einzuhalten, die man gegenüber der Zertifizierungsstelle gemacht hat, wären eigentlich auch regelmäßige Checks der Systeme nötig. Damit muss ein Unternehmen überprüfen, ob die in seinen Statuten festgelegten Regeln auf allen relevanten Systemen tatsächlich so umgesetzt sind, wie die Vorgaben es verlangen. Wie lässt sich diese Überprüfung aber umsetzen?

Ein Weg wäre, eigene Admins zu beschäftigen, die sich nur dieser Aufgabe widmen. Doch das wäre wenig effizient – und würde obendrein zu der problematischen Situation führen, dass die normalen Admins sich ständig beobachtet fühlen. Besser ist es, Compliance-Tests automatisch und maschinell durchzuführen. Hier kommt Inspec zur Hilfe.

Das von der Firma Chef entwickelte Werkzeug verspricht, dass es Compliance-Tests auf Zielsystemen automatisch und regelmäßig durchführt. Zudem will es mit einer einfachen Syntax punkten: Admins definieren die Tests laut Hersteller in einer von Menschen lesbaren Sprache, ohne eine übermäßig aufwändige Syntax zu lernen. Das Linux-Magazin stellt Inspec vor und erklärt an Beispielen, wie die Compliance-Überwachung mit dem Programm funktioniert.

Audits und Tests

Inspec bezeichnet sich selbst als Framework für Auditing und Testing. Es geht in erster Linie also darum, bestehende Systeme automatisiert auf Herz und Nieren zu prüfen. Dabei steht die Frage im Mittelpunkt, ob das System und die auf ihm laufenden Dienste gemäß den Vorgaben konfiguriert sind. “Compliance as Code” ist der Slogan.

Angeboten wird die Lösung von derselben Firma, die den Automatisierer Chef im Sortiment hat. Das ist logisch: Wer Konfiguratonsmanagement betreibt, tut das meist, weil er den gleichen Stand auf allen verwalteten Systemen will. Werkzeuge wie Chef überschreiben im Zweifelsfall mit ihrer Konfiguration einfach vorhandene Änderungen und erzwingen so Uniformität. Doch was ist mit den Systemkomponenten, die Chef gar nicht anfasst? Und wodurch merkt ein Unternehmen, wenn einzelne Systeme – mutwillig – händisch geändert worden sind, also nicht mehr dem Standard entsprechen? Die Antwort von Chef auf diese Fragen heißt Inspec.

Inspec steht unter einer freien Lizenz und ist im Github-Verzeichnis von Chef frei zu beziehen [1]. Es deckt eine Vielzahl von Zielsystemen ab: Linux ist in Form von Centos, RHEL, SLES, Debian und Ubuntu sowie weiteren Systemen vertreten. Auch Windows kommt nicht zu kurz – Inspec verspricht auf allen relevanten Windows-Versionen der Gegenwart zu funktionieren. Die BSDs sind mit Free BSD vertreten und auch Exoten wie AIX, HP-UX oder Solaris lassen sich mit Inspec testen. Obendrein funktioniert Inspec auch auf Mac OS X. Die unterstützten Systeme sind also vielfältig, für fast alle Anwendungen im Serverraum dürfte in der aktuellen Version gesorgt sein.

Hallo Welt!

Im Folgenden geht der Artikel auf ein erstes Beispiel genauer ein, nämlich das bekannte “Hallo Welt!”-Programm. Damit Inspec sich nutzen lässt, muss es der Admin freilich zunächst installieren. Für RHEL, Ubuntu sowie Mac OS und Windows bieten die Autoren ein Installationsskript an, das Inspec in Form von fertigen Paketen aufs System holt. Der notwendige Befehl unter Ubuntu lautet:

curl https://omnitruck.chef.io/install.sh | sudo bash -s -- -P inspec

Wer auf einem anderen System unterwegs ist, installiert Inspec entweder via Rubygems.org [2] oder lädt sich einen Docker-Container herunter, in dem Inspec schon läuft.

Theoretisch funktioniert der oben genannte Befehl übrigens auch in Mac OS, doch hier ist Vorsicht geboten: Inspec setzt wie Chef auf Ruby, aber die in Mac OS mitgelieferte Ruby-Version ist prähistorisch. Abhilfe schafft der Admin, indem er Homebrew [3] installiert und sich von dort ein aktuelles Ruby für sein System besorgt. Wenn die Installation geklappt hat, fördert der einfache Aufruf von »inspec« auf der Kommandozeile den Hilfetext des Programms zutage.

Der erste Test

Ähnlich wie Chef-Cookbooks auch folgen Inspec-Tests einer strengen Syntax. Es empfiehlt sich daher, zunächst einen Ordner anzulegen, im Beispiel heißt er »helloworld«. Darin legt der Admin im nächsten Schritt eine Datei namens »helloworld.txt« an, indem er sie im Editor öffnet. Die Datei soll für den Augenblick aus einer einzelnen Zeile Text bestehen, die “Helo World!” lautet.

Dann folgt der eigentliche Inspec-Test oder wie es im Inspec-Sprech auch heißt: die Spezifikation. Dazu öffnet der Admin im Texteditor die Datei »helloworld_spec.rb«. Es empfiehlt sich, hier auf einen Editor zurückzugreifen, der Syntax Highlighting für Ruby beherrscht. Der erste Test sieht aus wie in Listing 1. Wer mit Ruby-Syntax nicht vertraut ist, versteht hier vermutlich nicht jede Zeile auf Anhieb. Das Gros der Anweisungen lässt sich jedoch mit dem Grundwissen eines Admin bereits entschlüsseln.

01 control "hello-world-1" do
02   impact 1.0
03   title "Hello World"
04   desc "Text should include the words 'hello world'."
05   describe file('helloworld.txt') do
06    its('content') { should match 'Hello World' }
07   end
08 end

Die Zeile mit »control« leitet die Spezifikation ein; die Zeichenkette in den Anführungszeichen ist eine maschinell verarbeitbare, eindeutige Bezeichnung des Tests. Die Zeile mit »impact« legt über ein Punktesystem fest, wie schlimm es ist, wenn der genannte Test fehlschlägt. Die Punktelevel und die sich daraus ergebenden Aktionen lassen sich für Inspec separat konfigurieren, »1.0« ist in diesem Beispiel eine beliebige Zahl.

Die Strings »title« und »desc« verpassen dem Test einen Titel und eine Beschreibung. Beide Werte sollen auch für Menschen ohne Ruby-Kenntnisse verständlich sein. »describe« schließlich leitet die eigentliche Bedingung ein: Im konkreten Beispiel öffnet Inspec die Datei »helloworld.txt« und überprüft, ob deren Inhalt die Zeichenkette »Hello World« enthält.

Aufruf mit “inspec”

Die auf diese Weise erstellte Datei lässt sich anschließend an »inspec« direkt als Parameter übergeben. Um den Test dann zu starten, genügt also der Befehl:

inspec exec helloworld_spec.rb

Erwartungsgemäß schlägt der Test fehl: Schließlich steht in »helloworld.txt« ja »Helo World!«. Inspec gibt sich gesprächig: Es merkt nicht nur an, dass der Test fehlgeschlagen ist, sondern schlägt gleich auch die per »diff« generierte Änderung vor, die notwendig ist, damit der Test erfolgreich verläuft. Nach der entsprechenden Änderung verschwindet das Problem und der erneute Aufruf von »inspec« meldet keine Fehler mehr.

Die Command-Ressource

Zugegeben: Das genannte Beispiel ist nicht besonders praxisnah. Denn es prüft lediglich den Inhalt einer einzelnen Datei und sieht nach, ob in dieser eine bestimmte Zeichenkette vorkommt. Im Alltag wird der Admin jedoch auf den Systemen unter seinen Fittichen oft bestimmte Kommandos ausführen müssen, um Compliance-Werte zu testen. Die Ausgabe der Befehle ist dabei ebenso spannend wie der eventuell gelieferte Rückgabewert.

Abbildung 1: Der Test prüft, ob die Ausgabe von »apt-key list« auch »Ubuntu Archive Automatic Signing Key« enthält.

Für diese Art von Aufgabe bietet Inspec die Command-Ressource an: Die führt beliebige CLI-Befehle aus und erlaubt es danach, die Ausgabe der Befehle zu untersuchen.

Das Beispiel in Listing 2 lässt Inspec prüfen, ob auf einem Ubuntu-System der offizielle GPG-Schlüssel des Ubuntu-FTP-Teams installiert ist (Abbildung 1): Die Direktiven »control«, »impact«, »title« und »desc« funktionieren dabei genauso wie im vorangegangenen Beispiel.

01 control "apt-key-1" do
02   impact 1.0
03   title "Is the Ubuntu FTP archive key installed?"
04   desc "Ubuntu cryptographically signs its package lists to verify they are
05   valid."
06   describe command('apt-key list') do
07    its('stdout') { should match /Ubuntu Archive Automatic Signing Key/ }
08   end
09 end

Interessant ist erneut jener Teil, der auf »describe« folgt: Per »command« ruft Inspec »apt-key list« auf, um im Anschluss die Ausgabe auf dem Standard-Ausgabekanal des Programms auf eine spezifische Zeichenkette hin zu untersuchen. Innerhalb der Slashes befindet sich ein regulärer Ausdruck, der auch deutlich komplexer sein könnte. Alles, was in regulären Ausdrücken erlaubt ist, ist hier ebenfalls möglich.

Noch mehr Ressourcen

Die gute Nachricht nach den beiden ersten Beispielen ist: Die Syntax eines einzelnen Tests ändert sich nicht, egal welche Bedingung der Admin mit dem jeweiligen Test verknüpft. Die noch bessere Nachricht: Inspec bietet eine große Menge fertiger Ressourcen, die sich nutzen lassen und jeweils mit eigenen Parametern kommen. Innerhalb des Describe-Blocks sind Ressourcen nach Belieben einsetzbar. Das Inspec-Referenz-Handbuch bietet eine Liste [4].

Besonders interessant auf Ubuntu-Systemen ist die Apt-Ressource: Sie hilft prüfen, ob bestimmte Repositories in der Apt-Konfiguration in »/etc/apt/sources.list.d« aktiviert sind. Die »iptables«-Ressource dagegen guckt in die lokalen IPtables-Regeln und schlägt Alarm, falls die im Test angegebene Regel nicht vorhanden ist.

Eine »parse_config«-Ressource erlaubt es, Konfigurationsformate zu interpretieren und nach bestimmten Werten darin zu suchen. Und falls es für das jeweilige Programm nicht ohnehin eine eigene Parser-Ressource gibt: Mit Hilfe von »mysql_conf«, »postgresql_conf« oder auch »inetd_conf« lassen sich die Konfigurationsdateien der jeweiligen Dienste direkt durchsuchen.

Auch die »package«-Ressource ist spannend: Sie schaut nach, ob ein bestimmtes Paket installiert ist und falls ja, in welcher Version. Je nach gewünschtem Resultat schlägt Inspec Alarm. Mit »user« und »group« prüfen Admins in Inspec, ob Dateien die gewünschten Zugriffsrechte haben. Per »kernel_module« lässt sich sogar checken, ob ein bestimmtes Kernel-Modul zur Zeit geladen ist.

Übrigens: Die Syntax einzelner Tests innerhalb des Describe-Blocks ist sehr flexibel. Der Admin ist nicht auf einen einzelnen Test beschränkt, er kann auch mehrere »its«-Zeilen pro Describe-Block angeben. Zudem lässt sich die Should-Logik auch invertieren: Nutzt der Admin anstelle von »should« ein »should_not«, stellt er fest, dass das aufgerufene Kriterium gerade nicht zutreffen soll.

Wer etwa Alarm schlagen will, falls ein bestimmtes Paket auf dem Zielsystem installiert ist, könnte das so tun:

describe package('tcpwrapper') do
  it { should_not be_installed }
end

Wäre das genannte Paket »tcpwrapper« installiert, schlüge der Test fehl und eine Fehlermeldung würde sichtbar.

Wenn der Admin sich an die Arbeit macht und verschiedene Parameter in Form von Inspec-Tests überprüft, wird er früher oder später eine größere Menge von Test-Dateien zusammengetragen haben. Es wäre jedoch mühselig, jeden Test einzeln per »inspec exec« aufzurufen.

Mehr Profil

Inspec schafft Abhilfe und bietet eine »profile«-Funktion an: Als Profil lassen sich beliebig viele Inspec-Tests zusammenfassen und dann gemeinsam ausführen. Der Clou: Es ist einfach, aus einer Sammlung von Inspec-Tests ein Inspec-Profil (Abbildung 2) zu bauen. Wenn Inspec installiert ist, genügt dazu zunächst der Befehl:

inspec init profile lm-example --overwrite

Das Kommando legt ein neues Profil im Ordner »lm-example« an. Der genutzte Parameter »–overwrite« sorgt dafür, dass Inspec eventuell schon vorhandene Dateien überschreibt. Er ist also mit Bedacht zu nutzen.

Danach finden sich im Ordner zwei Unterordner namens »controls« und »libraries« sowie die Dateien »README.md« und »inspec.yml«. Seine Tests verschiebt der Admin zunächst in den Ordner »controls«. Dabei achtet er darauf, dass der Name der Datei auf ».rb« endet. Die Zeichenkette »_spec« muss im Dateinamen dagegen nicht mehr vorkommen, Inspec erkennt die Tests auch ohne sie.

Abbildung 2: Das Beispiel zeigt eine simple Profil-Beschreibung für ein Profil in Inspec, das sich im Block auf Servern durchführen lässt.

Dann geht es ans Bearbeiten der »inspec.yml«. Die Felder in der Datei haben selbsterklärende Namen; hier hinterlässt der Admin den Namen sowie eine Beschreibung des Profils und eine Lizenzangabe. Ist das geschehen, lässt sich – von der jeweils nächsthöheren Verzeichnisebene aus – der Befehl »inspec check lm-example« nutzen, um die Syntax des Profils und der Tests zu verifizieren. Falls dabei kein Fehler auftaucht, ist das Profil danach ausführbar (»inspec exec lm-profile«, Abbildung 3).

Abbildung 3: Führt der Admin auf einem System ein »exec« auf ein Inspec-Profil aus, werden dort alle Tests einmal durchgeführt.

Übrigens: Es empfiehlt sich, das Inspec-Profil in einem Git-Verzeichnis zu verwalten. Denn so lässt es sich einerseits elegant in Jenkins einbauen (siehe Abschnitt), andererseits ist es so einer sinnvollen Revisionsverwaltung unterworfen.

Die Verbindung zu anderen Servern

Das fertige Inspec-Profil wirft eine weitere Frage auf: Wie gelingt es, die im Profil enthaltenen Tests auf anderen Rechnern auszuführen – idealerweise per SSH-Protokoll? Inspec selbst bietet eine Lösung an. Der Parameter »-t« bringt Inspec bei, dass es die Tests auf einem anderen Host ausführen soll.

Als Parameter erwartet das Tool in diesem Fall die Angabe der vollständigen Login-Parameter der Gegenseite, also bei einer SSH-Verbindung beispielhaft »ssh://mloschwitz@server2«. Wer stattdessen lieber als Root unterwegs ist, darf das mit Inspec natürlich weiterhin tun. Wichtig ist nur, dass der gewählte Nutzer sich auf dem anderen Host per SSH einloggen kann und dass er auf dem Zielsystem die Rechte von »root« bekommt.

Wer aus Sicherheitsgründen nicht direkt als Root arbeiten möchte, der greift auf Inspecs Option zurück, »sudo« zu benutzen: Die Parameter »–sudo« und »–sudo-password= geheim« sorgen nämlich dafür, dass der Inspec-Nutzer erst per »sudo«-Befehl zum User Root wird, bevor er auf dem anderen, entfernten System seine Tests durchführt.

Testen nach Vorgabe

Bis hierhin hat der Artikel beschrieben, dass Inspec ein mächtiges Werkzeug ist, dessen Direktiven sich für beinahe jede Art von Tests eignen. Wer Inspec und seine grundlegende Funktionalität einmal verstanden hat, stellt sich aber schnell eine andere Frage: Auf welche Parameter soll man als Admin ein bestehendes System denn nun eigentlich testen? Gibt es Vorgaben in Sachen Compliance, die ein sinnvoll konfiguriertes Ubuntu beschreiben? Ja und nein. Compliance ist einerseits eine spezifische Angelegenheit, für die es andererseits aber einen gewissen Grundschatz an Best Practices gibt.

Grundsätzlich gilt zunächst: Hat ein Unternehmen Compliance-Zertifikate wie das bereits erwähnte ISO 27001 oder das BSI-Grundschutz-Zertifikat, geben jene Regelwerke die Marschrichtung vor. Darin definierte Anforderungen an Systeme sollten Admins zuerst ins Auge fassen, wenn sie ihre Compliance mit Inspec automatisiert testen wollen.

Wer solche Anforderungen nicht hat oder immer an zusätzlichen Wissensquellen interessiert ist, findet beim CIS, also dem Center for Internet Security, diverse “Benchmarks”. Darin stellen die Experten, etwa am Beispiel von Ubuntu 16.04 [5], Regeln auf, die das System härten. Anders als es der Name vermuten lässt, haben die Autoren der Dokumente aber nicht Ubuntu oder andere Distributionen auf ihre implizite Sicherheit getestet. “Benchmark” bedeutet in diesem Fall stattdessen, dass Admins die im Dokument beschriebenen Regeln implementieren können und sich aus der Gesamtzahl der Kriterien am Ende eine Punktzahl für das jeweilige System ergibt. Nicht alle Kriterien im Buch wirken sich allerdings auf die Punktzahl aus.

Schade: Für Inspec finden sich im Netz nur wenige fertige Sammlungen von Compliance-Tests, die etwa die CIS-Empfehlungen umsetzen. Wer also sein Ubuntu auf Basis der CIS-Empfehlungen auf Compliance hin abklopfen möchte, muss die für ihn relevanten Tests aus dem CIS-Benchmark selbst in Inspec-Tests packen.

Hat der Admin gerade nicht viel Zeit, wird sich das kaum für das gesamte CIS-Dokument für Ubuntu (Abbildung 4) realisieren lassen: Es liefert auf über 300 Seiten diverse Tests und dokumentiert erwartete Ergebnisse sowie die Begründung für das jeweilige Resultat.

Abbildung 4: Das Center for Internet Security (CIS) bietet Benchmarks an, die erläutern, wie sich Linux-Systeme abhärten lassen.

Die Kombination mit Jenkins

Compliance-Tests sind schön und gut, doch wirklich effizient wird Inspec erst dann, wenn der Admin seine Systeme regelmäßig automatisch prüfen lässt. Inspec bietet den Vorteil, dass es von jedem beliebigen Host aufrufbar ist und sich per SSH mit anderen Hosts verbindet, um dort seine Tests durchzuführen. Diese Eigenschaft macht sich eine vielleicht schon vorhandene Jenkins-Instanz zunutze: Ein entsprechend konfiguriertes Inspec lässt sich mit Jenkins nämlich automatisch starten. Dazu genügt es, in Jenkins eine Task anzulegen, die aus dem zentralen Git-Verzeichnis zunächst das jeweilige Inspec-Profil auscheckt und danach Inspec aufruft, sodass es seine Tests abspult.

Hinzu kommt noch, dass Inspec über den Parameter »–format« das Format einer Ausgabe ändern kann. Das Kommando »–format junit« bringt Inspec dazu, seine Testergebnisse im Junit-Format auszugeben. Das ist genau jenes Format, in dem Jenkins seine Testergebnisse erwartet, um sie zu verarbeiten und zu analysieren (Abbildung 5).

Abbildung 5: Mit dem Junit-Format lässt sich Inspec in Jenkins problemlos einbinden.

Ein auf diese Weise konstruierter Workflow startet Inspec auf den Zielsystemen und legt die Resultate der Tests so ab, dass Jenkins sie weiterverarbeiten kann. Per Webinterface informiert Jenkins den Admin dann über fehlgeschlagene Tests. Wer möchte, kombiniert das Gespann aus Jenkins und Inspec zudem mit dem Monitoring und erhält von diesem automatisch Warnungen, wenn Compliance-Tests von Inspec fehlschlagen.

Ein Fazit

Inspec überzeugt gleich auf mehreren Ebenen. Die Installation sowie die Handhabung des Werkzeugs sind sehr einfach. Seinem Versprechen, dass auch Admins ohne größere Programmiererfahrung Inspec nutzen können, kommt Chef nach. Obwohl es sich um Ruby-Code handelt, ist das Erstellen von Tests nicht schwierig und erfordert auch keine tiefen Ruby-Kenntnisse. Vorteilhaft ist obendrein, dass tatsächlich eine leicht verständliche Sprache zur Anwendung kommt: Sprechende Funktionssnamen helfen dem Admin dabei, den Überblick zu behalten.

Wer sich als Verantwortlicher in einem Unternehmen mit dem meist ohnehin nicht sonderlich beliebten Thema Compliance auseinandersetzen muss, liegt bei Inspec goldrichtig: Weil es sich um ein eigenständiges Programm handelt, lässt es sich auch ohne das Automatisierungstool Chef betreiben, also etwa auch dort, wo bereits die Konkurrenz in Gestalt von Ansible oder Puppet zum Einsatz kommt. Die Option, Inspec mit Automatisierungs-Frameworks wie Jenkins zu verheiraten, ist ein weiterer, großer Pluspunkt. Wer auf Compliance automatisiert testen will, sollte sich Inspec deshalb sehr genau anschauen.

Wer bereits das Werkzeug Chef benutzt, kann Inspec zum Beispiel als Teil eines Audit-Cookbook einsetzen. Über Attribute und Parameter lassen sich zudem zusätzliche Werte an Inspec übergeben, die es dann bei seiner Arbeit beachtet. Mehr Details zu diesem Thema enthält die lesenswerte Inspec-Dokumentation, zu finden unter [6].