erschienen in LinuxEnterprise 9/2001, Software & Support Verlag, Frankfurt a.M.
In diesem dritten und letzten Teil der Serie "Harte Zeiten" werden Methoden und Open-Souce-Werkzeuge zur Aufdeckung von Angriffen aus dem Internet vorgestellt.
Jeden Tag gibt es neue Meldungen über "vulnerabilities" und "exploits", die insbesondere Administratoren von umfangreichen Unternehmensnetzen (heraus)fordern. Mithalten kann nur noch, wer die einschlägigen Quellen wie Bugtraq [1]permanent verfolgt, selber experimentiert und sein Wissen ständig erweitert. Kommerziellen Herstellern ist diese Problematik natürlich bekannt und es gibt deshalb eine ganze Reihe mehr oder weniger leistungsfähiger Produkte. Besonders kleine und mittlere Unternehmen verzichten häufig auf einen ausreichenden Schutz. Meist wird der Aufwand für die Installation und Wartung gescheut oder die Bedrohung falsch eingeschätzt. Es gibt jedoch freie Software, die zwar nicht in einem schönen GUI-Gewand daher kommt, aber in technischer Hinsicht manchem kommerziellen Produkt in nichts nachstehen. Auch Unternehmen ohne ein sechstelliges IT-Budget bauen damit ein professionelles, mehrstufiges Firewall-System auf.
Zwar verfügen die meisten KMUs über Firewalls, jedoch werden hauptsächlich Network Appliances oder Router mit einem integrierten, statischen Paketfilter eingesetzt. Sie überwachen nicht die Zugehörigkeit eines Datenpakets zu einer bestehenden, regulären Verbindung. Ein technisch versierter Angreifer kann deshalb in eine Verbindung seine Datenpakete einschleusen und die Firewall durchlaufen. Diesem Angriff geht meist ein gezieltes Auskundschaften des zukünftigen Opfers voraus. Auch diese Schnüffeleien bleiben ohne die regelmäßige Analyse der Firewall-Logdateien durch einen Kundigen unbemerkt. Ist die Firewall erst einmal überwunden, werden vorsichtige Angreifer nur noch durch einen Zufall entdeckt. Die Notwendigkeit einer weitere Sicherheitsstufe wird offensichtlich.
Diese Aufgabe übernehmen Intrusion Detection Systems. Man unterscheidet host- und netzwerkorientierte Systeme, kurz als IDS bzw. NIDS bezeichnet. Hostbasierte IDS überwachen die Integrität von Dateien eines Rechners, während NIDS den Datenverkehr regelbasiert analysieren. Im Gegensatz zu einem einfachen Paketfilter arbeiten sie auf der Netzwerk- und der Anwendungsebene und erkennen so auch Trojaner und Viren.
Werden im Netzwerk die beliebten Layer-2-Switches eingesetzt, kann ein NIDS nur noch den Netzwerkverkehr zwischen zwei Hosts überwachen, da die Verbindung zwischen ihnen für den Bruchteil einer Sekunde exklusiv ist. Eine Ausnahme sind Switches der gehobenen Preisklasse, die über einen Monitor-Port verfügen, an dem der gesamte Netzwerkverkehr anliegt.
Es gibt mehrere Möglichkeiten für die Platzierung eines NIDS, die jeweils ihre Vor- und Nachteile haben. Befindet es sich wie in Abb. 1 Pos. 1 gezeigt zwischen Internet und Firewall, liefert das System eher quantitative und qualitative Informationen über Angriffe auf die DMZ. Die Zahl der Fehlalarme ist entsprechend hoch. Auf der Pos. 2 hingegen erfasst das NIDS nur Angriffe, die die erste Stufe der Firewall bereits überwunden haben. Besonders sensible Subnetze lassen sich durch ein NIDS an der Pos. 3 wirksam schützen. Die genaueren Informationen, weniger "false positives" und die verbesserte Performance lohnen den Mehraufwand für die Administration verteilter NIDS.
NIDS können nur das Auftreten einer Anomalie melden und müssen dem Administrator die Entscheidung überlassen, ob der Angriff überhaupt erfolgreich war. Angreifer installieren in der Regel ein aus zahlreichen Dateien bestehendes Rootkit [2] , das einige Systemdateien durch Trojaner ersetzt und neue Dateien hinzufügt. Damit der ungebetene Gast später einfacheren Zugang zum System bekommt, installiert er eine "Hintertür" ins Netzwerk. Schließlich wird er versuchen, seine Spuren durch Veränderungen an den Logdateien zu verwischen. Jeder dieser drei Schritte ist nicht ohne Veränderungen am Dateisystem erreichbar.
Diese Veränderungen registrieren hostbasierte IDS. Sie erzeugen für ausgewählte Dateien kryptografische Prüfsummen, die zusammen mit weiteren Informationen über die Datei in einer Datenbank abgelegt werden. Diese Daten werden mit dem aktuellen Zustand der Dateien verglichen. Eine wirklich zuverlässige Datenbasis erhält man nur auf einem neu installierten System, da ein Produktionssystem bereits kompromittiert sein kann. Ein hostbasiertes IDS wie tripwire [3] befindet sich unmittelbar auf dem zu schützenden Rechner. Dort ist es dem Angreifer unmittelbar ausgesetzt und kann manipuliert oder abgeschaltet werden, wenn es nicht auf einem Read-Only-Medium installiert ist. Der Aufwand für die Administration des Systems ist recht hoch, da die Konfiguration jedes Hosts individuell angepasst werden muß. Sie erzeugen ansonsten eine lange Liste von möglichen Veränderungen an Dateien, in der eine wirkliche Manipulation leicht übersehen werden kann. Nach der Gefährdung des Systems richtet sich die Häufigkeit der Überprüfung, die von cron gesteuert in stündlichen Abständen stattfinden kann. Die Berechnung der Datei-Prüfsummen und das Durchlaufen des Dateisystems nimmt die Ressourcen des Systems erheblich in Anspruch, was bei seiner Dimensionierung beachtet werden muss.
Sie sind eine weitere Stufe in unserer mehrschichtigen Verteidigungsstrategie. Scanner simulieren die von Hackern angewandten Techniken, um bereits bekannte Sicherheitsprobleme aufzudecken. Die dazu notwendigen Informationen beziehen sie aus Datenbanken, die ständig aktualisiert werden müssen. Einige Produkte geben sogar Hinweise für die Behebung. Bekannt wurden Security Scanner durch Satan, der inzwischen nicht mehr auf dem neuesten Stand der Technik ist.
Der Autor Martin Rösch bezeichnet das Open-Source-NIDS Snort [4] als den kleineren Bruder des kommerziellen Marktführers. Zwar betont Rösch, dassSnort nur für den Einsatz in verhältnismäßig kleinen Netzwerken geeignet sei. In der Mailingliste finden sich trotzdem zahlreiche Hinweise auf einen erfolgreichen Einsatz an "dicken" Leitungen. Wie bereits eingangs gezeigt, hängt die Leistung eines NIDS massgeblich von seiner Platzierung ab. Jeder Host innerhalb der DMZ kann einzeln überwacht und mit der Snort-Filterfunktion auch noch auf einen einzigen Port beschränkt werden. Würde beispielsweise nur der Port 25 SMTP überwacht, sind deutlich weniger Regeln notwendig. Jedes an diesen Rechner adressierte und einen anderen als den Port 25 geschickte Paket wäre verdächtig und würde erfasst. Diese Vorgehensweise wird als Strategie der "passive trap" [5]bezeichnet. Als Wachhund für einen "Honeypot" istSnort die Software der Wahl und wird vom HoneyNet-Team [6] empfohlen.
| Honeypots |
|---|
|
Honeypots sind Systeme, die allein dem Zweck dienen, Angreifer anzulocken. Er wird vor einer Firewall oder in einer DMZ platziert und mit einem hostbasierten IDS wie tripwire ausgestattet. Die Weiterentwicklung sind HoneyNets, die ein ganzes Netzwerk simulieren. Tatsächlich existiert aber nur ein Rechner, auf dem in virtuellen Maschinen mehrere Instanzen ein Betriebssystems über virtuelle Netzwerkverbindungen kommunizieren. Das Ziel ist nicht nur Angreifer von den Produktions-Systemen abzulenken, sondern möglichst viel über ihre Techniken zu erfahren. Häufig wird geraten, den Honeypot mit einer oder mehreren altbekannten Schwäche auszustatten, was aber meist nur ScriptKiddies anzieht. Außer einem Mehraufwand für die Administration dieses Systems wird man kaum neue Erkenntnisse gewinnen. Deshalb kann es sinnvoller sein, einen Honeypot dem Stand der Technik und dem eigenen Wissen entsprechend vollständig zu schützen und durch den Hostnamen test, besondere Dienste oder Dummy-Daten interessanter zu machen. |
Snort entdeckt nahezu alle möglichen Angriffstechniken:
Die folgende Regel löst einen Alarm aus, wenn in Paketen an den Port 143 die Signatur E8C0 ... gefunden wird:
alert tcp any any -> 192.168.1.0/24 143 (content:"|E8C0 FFFF FF|/bin/sh";
msg:"New IMAP Buffer Overflow detected!";)
Um in einem solchen Fall den Systemadministrator auf sich aufmerksam zu machen, schreibt Snort mit Hilfe des syslogdMeldungen in Logdateien oder lässt per SMB-Protokoll Popup-Nachrichten auf einem Windows-Client erscheinen. Wird eine Netzwerkmanagement-Software eingesetzt, erscheint dank der SNMP-Unterstützung der neuen Version 1.81 nun eine Warnmeldung auf dem Bildschirm. Für die spätere Analyse erzeugtSnort Berichte als ASCII-Datei oder im tcpdump-Binärformat. Einige Addons wie ACID [7] und SnortReport [8] erleichtern die Interpretation und Auswertung der Reports.
Snort wird sehr intensiv weiterentwickelt. Auf der Website findet man eine umfangreiche Bibliothek von ca. 1000 Signaturen. Bei einem kürzlich bekannt gewordenen Buffer-Overflow war die entsprechende Regel mit der Signatur des Expoits noch am selben Tag von der Snort-Website abrufbar. Dort findet man auch die sehr gute, ausführliche Dokumentation sowie zahlreiche Whitepapers zum Thema NIDS.
tripwire [3] ist ein hostbasiertes IDS. Seine prinzipielle Arbeitsweise wurde bereits weiter oben beschrieben. Um die Datenbasis vor Manipulationen zu schützen, brennt man den vollständigen Verzeichnisbaum /var/adm/tripwire sofort nach der Konfiguration und Erzeugung der Datenbank auf eine CD. Derart schreibgeschützt mountet man tripwire auch an dieses Verzeichnis.
Jeder Angreifer ist natürlich bestrebt, seine Spuren zu verwischen. In erster Linie finden sich diese im Verzeichnis/var/log, in dem auch der syslogd neben der Dateimessages noch eine Reihe anderer Dateien anlegt. Auch die Programme tripwire [3] und snort [4] benutzen den sylogd. Er kann Systemnachrichten lokal und auf entfernten Rechnern speichern. Auf dem lokalen Rechner wird dazu einfach diese Zeile in die Konfigurationsdatei /etc/syslog.conf eingefügt:
*.* @loghost
Die Systemnachrichten werden weiterhin lokal gespeichert. Zusätzlich empfängt der syslogd des entfernten Rechners loghost diese Nachrichten, wenn er darauf vorbereitet wird:
# /sbin/syslogd -r -s ihre_domain
Bei der SuSE-Distribution können die erforderlichen Anpassungen in der Datei /etc/rc.config vorgenommen werden. Bei anderen Distributionen sind gegebenfalls die init-Skripten anzupassen. Ein Angreifer muss zusätzlichen Aufwand betreiben und sich auch des Loghosts bemächtigen, wenn er alle Spuren beseitigen will. Dies macht ihm syslogdnicht allzu schwer, weil er weder über Verschlüsselungs- noch Authentifizierungsmechanismen verfügt. Alle Nachrichten werden per UDP am Port 514 im Klartext über das Netz geschickt und können leicht gefiltert werden. Hat der Angreifer noch keine Superuser-Rechte für den Loghost, kann er mit Programmen wieloggerTausende sinnloser Logbucheinträge erzeugen. Zur lokalen Spurenbeseitigung braucht der Cracker nicht einmal einen Editor, weil es eine ganze Reihe von Werkzeugen gibt, die ihm diese Arbeit abnehmen.
Oft wird empfohlen, Systemnachrichten sofort auszudrucken. Leider interpretieren einige syslogd die Druckersteuerzeichen, mit denen die Druckausgabe unleserlich gemacht werden kann. Gleiches gilt für Terminalemulationen, die bei Systemkonsolen mit serieller Verbindung zum Host benötigt werden. Auch die Kommandos less undcat interpretieren Steuerzeichen wie den Backspace \0x08.
Die zahlreichen Möglichkeiten zur Manipulation der Logdateien machen die Notwendigkeit einer Alarmierung in Echtzeit deutlich. Dies kann per Email oder SMS geschehen. Diese Aufgabe übernimmt das Programm logsurfer [9], das von Mitarbeitern des DFN-CERT entwickelt wurde. Es durchsucht mittels Pattern-Matching eine Logdatei nach Schlüsselworten wie failed oder error. Diese Eigenschaft allein würde logsurfer nicht von logcheck [10] oder swatch [11] unterscheiden, wenn das Programm nicht in der Lage wäre, durch dynamische Regeln ereignisabhängig zu reagieren und externe Programme zu starten. Auf diese Weise kannlogsurferbeispielsweise Firewall-Regeln dynamisch anpassen. Das Programm arbeitet darüber hinaus kontextabhängig, d.h. es speichert Daten aus Logdateien in Abhängigkeit von vordefinierten Regeln und setzt sie bei Eintreten eines neuen Ereignisses zueinander in Beziehung. Für die Regeln und das Pattern-Matching inlogsurfer verwenden die Autoren Wolfgang Ley und Uwe Ellermann die allgegenwärtigen, regulären Ausdrücke in ihrer erweiterten Form, wie sie auch egrep benutzt. Eine weitere besondere Eigenschaft ist die Echtzeitfähigkeit vonlogsurfer. Es wird im Gegensatz zulogcheck nicht von cron aufgerufen und kann ohne jede Verzögerung reagieren. Die Anpassung an die eigene Erfordernisse wird durch die Beispielkonfiguration und die sehr gute Dokumentation erleichtert.
Nessus [12] ist ein Security Scanner und besteht aus einem Server- und einem Client-Programm. Der Server führt als Backend die Tests aus und wird vom GUI-Frontend des Client gesteuert. Beide können sich auf verschiedenen Rechnern befinden. Ist der Server entsprechend dimensioniert, kann er eine große Zahl von Hosts mit den unterschiedlichsten Betriebssystemen gleichzeitig testen. Dabei ist Nessusnicht leicht hinter das Licht zu führen. Er testet das Vorhandensein eines Dienstes auf dem Standard- als auch auf allen anderen Ports. Ein Webserver auf dem Port 81 bliebe ihm nicht verborgen. Die neuesten Sicherheitsprobleme oder "Vulnerabilities" integriertNessusals Plugins. Sie werden in C oder in der eigenen Programmiersprache "Nessus Attack Scripting Language " NASL entwickelt. Das Update der Plugins ist einfach: Mit dem Befehlnessus-update-pluginserhält man die aktuellsten Versionen direkt aus dem Internet. Die Plugins werden sehr gut gepflegt und sind stets auf dem neuesten Stand.
Beeindruckend sind die Berichtsfunktionen. Nessusbeschränkt sich nicht nur auf die bloße Aufzählung der gefundenen Sicherheitsmängel, sondern klassifiziert sie nach Schwere und gibt zusätzlich Hinweise für ihre Behebung. Als Ausgabeformate stehen ASCII-, LaTeX-, HTML- und eine managementfähige Version mit Torten- und Balkengrafiken zur Verfügung.
Diese Software hat auch die Tester der amerikanischen Zeitschrift Network Computing [13]beeindruckt, die Nessus den "Well Connected Award" verliehen haben.
"Das Firewall Buch", Wolfgang Barth, SuSE Press, 2001
"Building Internet Firewalls 2nd Edition", Zwickey-Cooper-Chapman, O'Reilly
[1] Bugtraq, http://www.securityfocus.com/forums/bugtraq/intro.html
[2] Understanding the Attackers toolkit,http://www.sans.org/infosecFAQ/linux/toolkit.htm
[3] Tripwire, http://www.tripwire.org
[4] Snort, http://www.snort.org
[5] Burglar Alarms for Detecting Intrusions, Marcus Ranum, NFR Inc, 1999, http://www.blackhat.com/html/bh-usa-99/bh2-speakers.html
[6] Honeynet Project, http://www.honeynet.org
[7] Acid, http://www.cert.org/kb/acid/
[8] SnortReport, http://www.circuitsmaximus.com
[9] logsurfer, http://www.cert.dfn.de/eng/logsurf/
[10] logcheck, http://www.psionic.com/abacus/logcheck/
[11] swatch, ftp://ftp.stanford.edu/general/security-tools/swatch
[12] Nessus, http://www.nessus.de
[13] Network Computing, http://www.nwc.com/1210/1210f111.html#vulnassess