© Knud Nielsen, 123RF

Wer hat von meinem Tellerchen gegessen? – fragten die sieben Zwerge einst. Das moderne IT-Schneewittchen ist nicht auf Mundraub spezialisiert, sondern stiehlt und sabotiert auf tückischste Art. Host-based Intrusion Detection Systems setzen kleine und große Admins wenigsten darüber in Kenntnis, was los war.

Wenn es existenziell auf die Sicherheit ankommt, dann stehen Computer in einem Bunker und haben keine Netzverbindung nach draußen. Wer mit weniger wichtigen Dingen als Atomraketen befasst ist, muss IT-Security kompromissbereiter angehen – und bezahlt mit der Ungewissheit, ob Angreifer ins Innerste durchgedrungen sind.

Doch der Hüter eines Host ist nicht schutzlos. Neben den üblichen Vorsichtsregeln (Dienste-Minimalismus, Updaten, Härten, Firewalls, Dokumentieren, …) bieten sich Einbruchserkennungssysteme an (siehe Kasten “NIDS, IPS, HIDS”). Ein Host-based Intrusion Detection System (HIDS) automatisiert ein überschaubares Bündel von manuellen Verfahren, die einen Einbruch helfen zu erkennen:

• Veränderungen im Dateisystem,
• Analyse von Logfiles,
• Suche nach Schadsoftware.

Grundlage ist die Annahme, dass jeder Angreifer Spuren hinterlässt. Die Forensik spricht hierbei vom Locard’schen Prinzip: Durch eine Interaktion entsteht immer eine Veränderung. Die Kunst ist, diese Veränderung zu erkennen und die richtigen Schlüsse aus ihr zu ziehen. [1]

Änderungen im Dateisystem

Vermutlich ist es ein orgiastischer Erfolgsmoment für einen Cracker, wenn er zum Beispiel über einen Buffer-Overflow in ein fremdes System eindringt. Nun beginnt für ihn aber die dröge Arbeit: Da er nicht weiß, ob und wann ihn ein Update aussperren wird, muss er ein Rootkit als komfortablen Zugang installieren.

Dabei bringt er zusätzliche Software in das System und führt sie aus, was dem Systemverwalter per »ps« auffallen kann. Die geöffneten Netzwerkports, über die eine Fernsteuerung läuft, zeigt »netstat« an. Ein Angreifer muss also verhindern, dass sein Programm in den Ausgaben gängiger Admintools auftaucht.

Dafür existieren Strategien, die traditionelle tauscht einfach die Programmdateien von »ps« , »netstat« und Co. aus. Modernere, so genannte Kernelrootkits, installieren ein eigenes Kernelmodul, dass die Sichtbarkeit der Rootkit-Prozesse bereits im Kernel blockiert.

Frech vom Eindringling ersetzte Linux-Tools könnte der Admin an den veränderten Modification- und Creation-Zeiten, den Dateigrößen oder anderen Inodes der Binaries erkennen. In der Praxis wird ihm dies nie auffallen, weil die manuelle Kontrolle viel zu aufwändig wäre. Genau dafür bieten die klassischen HIDS Tripwire ([2], das Linux-Magazin hatte 2001 dazu einen erschöpfenden Fünfteiler veröffentlicht), Aide [3] oder das neuere Afick [4],[5] ihre Dienste an.

Die Syntax der Konfigurationsdateien der drei Tools ähnelt sich. Das in Perl geschriebene Afick wirbt sogar mit seiner Tripwire-Kompatibilität. Alle drei Tools legen bei ihrem ersten Durchlauf eine Liste über relevante Dateien und deren Modification- und Creation-Zeiten, Größe, Inode-Nummer, Berechtigungen und so weiter an. Der Vergleich mit späteren Läufen soll zwischenzeitlich stattgefundene Hacks aufdecken.

Hash mich

Fähige Angreifer konstruieren ihr Schadprogramm aber so, dass die Dateigröße identisch ist, setzen Zugriffszeiten mit »touch« identisch, erhalten Dateirechte und packen geänderte Datei in denselben Inode (»cat newps > ps« ). Daher merken sich Dateisystem-HIDS neben den sichtbaren Daten auch den Hashwert der Datei (siehe Hashfunktionen-Artikel in dieser Ausgabe).

Aide erlaubt sogar mehrere Hashverfahren parallel anzuwenden, um Kollisionen noch weniger wahrscheinlich zu machen: Für MD5 beträgt sie rechnerisch unter 2-64, für SHA-256 unter 2-128, die Wahrscheinlichkeit für eine Kollision in beiden Verfahren gleichzeitig damit unter 2-192, also rund 1,5*10-58. Zum Vergleich: Bei Lotto 6 aus 49 den Jackpot zu gewinnen hat eine Wahrscheinlichkeit von 7*10-9.

Dateiscans in der Praxis

Am Beispiel Aide sei gezeigt, wie’s geht. Nach der Installation, die wahlweise mit

apt-get install aide

oder aus den Sourcen erfolgt, macht der Admin die Konfiguration passend. Das geschieht in »/etc/aide/aide.conf« und für Sonderfälle in »/etc/aide/aide.conf.d« . Ziel sollte sein, dass Aide ein Auge auf alle relevanten Programm- und Konfigurationsdateien hat. Ob dabei die Standardeinstellung hilfreich ist, sieben verschiedene Hashes pro Datei zur Kollisionsvermeidung zu berechnen (siehe oben), möge jeder selbst entscheiden.

In der »aide.conf« liegen auch einige Makro-Definitionen, die später viel Arbeit beim Schreiben von Regeln ersparen. Aide erkennt auch, wenn Dateien dazugekommen sind – zum Beispiel als Folge eines Coredump, wie er bei versuchten Buffer Overflows schnell entsteht. Allerdings ist auf den meisten aktuellen Linuxen das Coredumping deaktiviert.

Auch für Logfiles und zum Ermitteln des Systemstatus’ bietet die Standardkonfiguration vernünftige Regelsätze an. Das Configfile erklärt sogar gut, wie die sich herleiten.

Durch »update-aide.conf« aktualisiert Aide seine Konfiguration, die der Admin mit »aide -D« auf syntaktische Korrektheit prüfen darf. Ein

aideinit -y -f

initialisiert die Datenbank. Jetzt berechnet Aide die Hashes, was auf einer virtuellen Maschine des Autors gute zehn Minuten dauerte. Dank eines mitinstallierten Cronjob prüft Aide auf Änderungen und mailt sie an Root. Neben der Mail kann Aide die Ergebnisse über eine beliebige URL ausgeben (»aide.conf« -Eintrag »report_url« ).

Dank des Umstandes, dass Aide sich so eng an sein Vorbild hält, ist das eben beschriebene Setup problemlos auf Tripwire (und teilweise auf Afick) übertragbar.

Logs, Logs, Logs

Eigentlich gehört es zu den täglichen Aufgaben eines Admins, die Logfiles seiner Rechner durchzuschauen: Hat sich ein Prozess unerwartet verabschiedet? Wurde er neu gestartet, sei es durch einen Watchdog oder einen Angreifer, der so seine Spuren verwischen wollte? Gibt es andere Hinweise auf Angriffsversuche?

Für einen (gestressten) Menschen ist es nicht immer einfach, zuverlässig echte Angreifer von dumpfem Probieren zu unterscheiden. Nicht mit jeder versuchten Nutzernamen-Passwort-Login-Kombination »admin« -»admin« , die für einen Angriff auf vernünftig administrierten Systemen sowieso untauglich ist, lohnt es sich zu beschäftigen. Dennoch hilft das regelmäßige Studium der diversen Logs, Probleme zu erkennen. Um der menschlichen Faulheit Herr zu werden, gibt es zu Admins Glück Tools, die die Logfiles analysieren, potenziell kritische Meldungen heraussortieren und den Admin per Mail informieren.

Ein Beispiel dafür ist Logsentry [6]: Das einfache, fertig entwickelte HIDS besteht nur aus Shellskripten und Configfiles. Es spart dem Admin die Arbeit, sich die richtigen Grep-Befehle selbst zu überlegen, die Angriffe anhand der Logfiles detektieren. Die Installation erledigt Root nach dem Download mit:

tar -xzf logcheck-1.3.17.tar.gz
cd logcheck-1.3.17
make linux

Danach ruft am besten ein Cronjob regelmäßig Logcheck auf. Root öffnet mit

crontab -e

die Crontab zum Editieren, und die Zeile

0 * * * * /usr/local/etc/logcheck.sh

sorgt dafür, dass das Prüfskript stündlich läuft. Wer mehr als die drei voreingestellten Standardlogfiles prüfen will, ergänzt »logcheck.sh« ab Zeile 172 nach dem Vorbild der vorangehenden Zeilen. Seine Regeln definiert Logcheck in mehreren Konfigdateien in »/etc/logcheck« .

Logchecks Prinzip ist simpel: Was in »logcheck.hacking« steht, erscheint in der Infomail an Root weit oben, Die »logcheck.violations« -Sachen folgen etwas weiter unten. Alles, was »ignore« nicht aussondert, gelangt in die Mail, darunter die »Unusual system events« . Wichtig ist nur, die »logcheck.ignore« nicht leer zu lassen, das wäre eine Wildcard, die alle Einträge ausblendet. Und damit wäre das Tool nutzlos.

Bedingt einsatzbereit

Zwar nehmen Logsentry und Verwandte dem Admin Arbeit ab, mehr aber nicht. Wer regelmäßig in seine Logs schaut, hat sich längst ein einfaches Suchskript gestrickt, das unkritische Meldungen aussortiert. Logsentry arbeitet genau umgekehrt: Der Admin muss beim Einrichten schon wissen, wie gefährliche Meldungen aussehen. Er filtert nur auf bekannt Verdächtiges, nicht auf vermeintlich Unverdächtiges.

Außerdem vertraut der Ansatz, in Logfiles zu schauen, auf das Unvermögen des Angreifers. Jeder fähige Täter wird die Logfiles auf seinem “Gastsystem” gesäubert zurücklassen, und Logsentry findet nichts Verdächtiges. Und genug Zeit zum Aufräumen bleibt dem Angreifer auch – je nachdem, wie oft Cron Logsentry aufruft.

Zwischenfazit: Solche Tools sind nur nützlich und reduzieren die Arbeit des Admin, wenn andere Systemen mitlaufen.

Nach Schadsoftware suchen

Wenn die Loganalyse und der Dateiencheck die Folgen einer Infektion aufzeigen, liegt es nahe, auch nach hinterlegten Schadcode zu suchen. Das erledigen Malware-Scanner, die es auch für Linux gibt. Clam AV [7] wäre ein Beispiel, das Linux-Magazin 11/2015 wird weitere vorstellen. Hier ist die Grenze zum Host-based Intrusion Detection System fließend, denn die meisten Virenscanner nutzen neben Signaturen auch Heuristiken, um Angriffe zu detektieren.

Spezieller arbeiten Programme wie Chkrootkit [8] und der in Perl geschriebene Rkhunter [9], die beide im Jahr 2014 ihre letzte Aktualisierung erhalten haben. Beide installiert Root unter Ubuntu mit:

apt-get install chkrootkit
apt-get install rkhunter

Chkrootkit lässt sich ohne weitere Parameter ausführen. Es ist letztlich ein Shellskript, das anhand verschiedener Parameter versucht, Rootkits zu erkennen. Unter anderem nutzt es dazu »strings« , um verdächtige Zeichenketten zu identifizieren, prüft das »lastlog« , ob jemand Einträge entfernt hat oder ob »ps« Process-IDs nicht anzeigt oder ob etwas in »/proc/« fehlt (Abbildung 1).

Rkhunter arbeitet mit mehr Anspruch, Das Configfile des Jägers heißt »/etc/rkhunter.conf« . Im Ubuntu-System des Autors war dort »lwp-request« eingetragen, aber nicht installiert, was

cpan Mock::LWP::Request

nachholt. Allerdings legt Perl das Tool zu Rkhunters Verblüffung nach »/usr/local/bin/lwp-request« – der Admin muss den »/usr/bin/« -Pfad im Configfile händisch ändern. Nun lässt sich Rkhunter initialisieren und das System auf Rootkits und Hinweise auf auffällige Dateien checken:

rkhunter --propupd
rkhunter --check

Abbildungen 2 gibt einen Eindruck, was Rkhunter als Einbruchsversuch wertet. Beide Tools lassen sich auch per Cronjob zum Beispiel täglich starten und werden so zum Bestandteil eines HIDS.

Abbildung 1: Chkrootkit unternimmt diverse Anstrengungen, um Rootkit-typische Anzeichen zu entdecken.

Abbildung 2: Ein kleiner Teil von Rkhunters Arbeit im Ausguck nach Illegalem.

All-in-one

Statt drei Tools, die sich ergänzen, gibt es auch Lösungen, die alle drei Funktionen vereinen. Ob das besser ist, gleicht der 80er-Jahre-Frage, ob eine Kompaktstereoanlage oder eine modulare die sinnvollere Hifi-Lösung ist – ein reiner Glaubenskrieg. Bei den All-in-one-Lösungen sind Samhain [10] und Ossec [11] zu nennen. Beide haben außerdem einen Agentenmodus implementiert, bei dem die Sensoren auf einem entfernten System laufen und ihre Daten einem zentralen Rechner zur Auswertung übermitteln.

Wer paranoid ist und sehr viel Zeit zum Lesen von E-Mails hat, den wird freuen zu hören, dass sich parallel agierende HIDSs sich gegenseitig nicht stören. Man darf also Tripwire, Aide, Afick, Samhain und Ossec auf einem Rechner kombiniert einsetzen, und die Systeme überwachen sich dann sogar gegenseitig. Trotzdem ist etwas Vorsicht angebracht: Gleichzeitig eintreffene Updates führen bei einem solchen Setup leicht zu einer Endlosschleife.

Wer Samhain ausprobieren möchte, findet eine ausführliche und detaillierte Anleitung [12], genauso für Ossec [13]. Beide Tools zu benutzen ist kein Hexenwerk, wenn man weiß, wie die Komponenten funktionieren.

Aber: Jede zusätzliche Codezeile birgt das Risiko von Programmierfehlern, auch von sicherheitsrelevanten. So hatte es Ossec 2.7 bis 2.8.1. im Juni 2015 übel erwischt: CVS-2015-3222, eine Privilege Escalation im Rahmen eines Dateichecks [14]. Erst mit Version 2.8.2 gibt es einen heilenden Patch. Das belegt, dass neben der Auswertung der Mails der diversen HIDS auch deren Pflege zu den Aufgaben des Admins zählt. Merke: Sicherheitstools sollten selbst keine neue Lücken reißen.

Dem Dieb auf der Spur

Host-basierte Einbruchs-Erkennungssysteme kommen in vielerlei Gestalt, deren Funktionalität sich oft ergänzt. Als Alternative gibt es fertig geschnürte Pakete, die alle Funktionen vereinen. Durch HIDS-Logs bekommen Admins, die Opfer eines erfolgreichen Einbruchs geworden sind, wichtige Informationen in die Hand, um die Tat nachzuvollziehen, Löcher zu stopfen und möglicherweise sogar den Täter zu überführen.

Die Leistungsgrenze vieler Tools ist erreicht, wenn der Angreifer als Root unterwegs ist und genügend Zeit zum Lahmlegen der Sicherheitsmechanismen und zum Säubern seiner Spuren hatte. Weil HIDS systembedingt nur die Folgen von (versuchten) Einbrüchen erkennen, bilden sie nur einen Baustein einer Sicherheitsarchitektur. Ein Network Intrusion Detection System, Firewalls, restriktive Nutzerrechte, regelmäßige Sicherheitsaudits der Systeme und das Schulen der Nutzer auf Risiken sind andere.