Hackerangriffe unter Linux entdecken

Ein modernes Server-Betriebssystem, eine gut konfigurierte Firewall und ein Administrator, der regelmäßig die Log-Files durchforstet - sie gelten als Garanten für ein sicheres lokales Netzwerk.

Um es jedoch gleich vorweg zu sagen: Ein absolut sicheres System befände sich in einem verschlossenen Raum von Fort Knox und hätte keinen Zugang zum Internet. Mit anderen Worten: Kein System oder Netzwerk ist absolut sicher. Daher ist Paranoia die beste Strategie:

• Zunächst machen Sie ein System so sicher wie möglich.

• Trauen Sie Ihren Sicherheitsmaßnahmen dennoch nicht, sondern gehen Sie stattdessen weiterhin vom "worst case" aus - dem erfolgreichen Hacker-Einbruch.

Warum diese Paranoia? Ganz einfach: Nicht alles liegt in Ihrem Einflussbereich. Durch Schwächen oder Bugs der eingesetzten Software und durch den Einfallsreichtum von Hackern kann es, selbst bei noch so guter Sicherheitsstrategie und perfekter Konfiguration, zu einem Einbruch kommen.

Wenn die Gefahr besteht, dass Hacker-Angriffe erfolgreich sein können, sollte man sich Gedanken über deren Erkennung machen. Nichts ist schlimmer, als ein erfolgreicher Angriff, der zu spät oder gar nicht bemerkt wird. Der Angreifer kann Änderungen an Dateien und Konfigurationen vornehmen und diese anschließend verwischen. Solche Änderungen zu finden gleicht der sprichwörtlichen Suche nach der Stecknadel im Heuhaufen.

Davon ganz abgesehen, wird ein Hacker das geenterte System als Plattform für Angriffe auf weitere Systeme verwenden. Als "angreifender" Host fungiert dann der "erbeutete" Server. Image-Schaden und die Abmahnkosten sind oft um einiges höher als der direkte Schaden auf dem Server. Ein Administrator gerät dann schnell in Erklärungsnotstand, wenn er keinen plausiblen Grund für den mehrwöchigen Aufenthalt eines Hackers im System liefern kann.

Spuren im Logfile

Hacker können Sie im Wesentlichen auf zwei Arten entdecken:

• In flagranti zum Zeitpunkt des Einbruchs, sei es durch ein Intrusion Detection System (IDS) oder manuell.

• Durch Spuren in den Log-Files. Letzteres ist jedoch nicht mehr ganz so glücklich, da der Hacker dann in den meisten Fällen bereits aus dem System geflüchtet ist.

Die Protokollierungen in den Log-Files sollten Sie immer lesen. Selbst wenn Sie ein noch so ausgereiftes IDS installiert haben, sollten Sie diese Aufgabe nicht vernachlässigen. Die Log-Files können Sie wie die Spuren am Tatort eines Verbrechens auffassen. Anhand dieser Dateien ist es möglich, den Hacker-Angriff zu rekonstruieren und gegebenenfalls den Täter zu überführen.

Wie im wirklichen Leben wird der Eindringling versuchen, seine Spuren zu verwischen. Die erste Hacker-Regel nach dem Einbruch in ein System ist das Bereinigen der Log-Files. Wenn Sie einen Hacker also dingfest machen und wissen wollen, was er überhaupt auf Ihrem System angestellt hat, müssen Sie auf Ihrem System für die Sicherung der Hinweise sorgen.

Konkret heißt das, dass Sie sich überlegen müssen, wie Sie die Log-Files gegen Änderungen absichern, respektive Modifikationen innerhalb kürzester Zeit erkennen. Sie können die Log-Files hierzu auf einem anderen Host unterbringen oder durch kryptographische Methoden schützen. Ein Hacker wird sich an diesen Maßnahmen in aller Regel die Zähne ausbeißen, so dass Sie ihn entdecken können.

Log-Files auf Remote-Host

Auf einem Linux-Rechner protokolliert der syslogd-Daemon alle Meldungen in den Log-Files. Diese liegen in der Regel im Verzeichnis "/var/log" auf dem System selbst. Ein Angreifer muss sich also in der Regel nur um die Dateien in diesem Verzeichnis kümmern.

Der Hacker steht jedoch vor einem Problem, wenn die Log-Files nicht mehr lokal auf dem System liegen. Die aufgezeichneten Informationen lassen sich nur mit großem Aufwand oder gar nicht mehr modifizieren, wenn sie auf einem anderen Rechner liegen. Der Eindringling müsste dann erst noch diesen anderen Host kapern.

In der Konfigurationsdatei "/etc/syslog.conf" steht, wo syslogd die Meldungen speichert. Normalerweise sind für die entsprechenden Meldungsarten Dateien angegeben, in denen die Protokollierung erfolgen soll. So bewirkt beispielsweise das Kommando kern.* -/var/log/kern.log, dass alle Kernelmeldungen in der Datei "/var/log/kern.log" landen.

Um alle Meldungen auf einem anderen Host zu protokollieren, geben Sie in dieser Datei die Zeile *.* @host an. "host" steht hierbei für den Netzwerknamen des Computers, auf dem die Meldungen protokolliert werden sollen. Auf diesem Host muss allerdings ebenfalls ein syslogd laufen.

Der Remote-Host protokolliert die Meldungen nun in seinen Log-Files mit. Bedenken Sie, dass es sinnvoll ist, die Log-Files durch die standardmäßig angegeben Aktionszeilen in "/etc/syslog.conf" zusätzlich auch lokal zu halten. Damit hat der Hacker dann immerhin eine Spielwiese und er merkt vielleicht nicht sofort, dass die Aufzeichnung seiner Aktivitäten auch remote erfolgt.

Außerdem bietet dieses redundante Führen von Log-Files einen weiteren Vorteil: Programme können die Meldungen vergleichen und somit Modifikationen erkennen. Allerdings benötigt man hierfür ein relativ intelligentes Programm, da die Zeiteinträge zwischen den jeweiligen Log-Files zumindest im Sekundenbereich differieren können.

Leider hat die Remote-Protokollierung einen kleinen Haken: Kommt beim syslogd eine wahre Flut von Meldungen an, findet die Protokollierung nicht mehr korrekt statt.

Log-Files schützen

Sehr interessant ist es, die Log-Files durch kryptographische Methoden (PEO-1) zu schützen. Der Schutz funktioniert dabei ähnlich wie beim digitalen Signieren. Über diese Signatur lässt sich zweifelsfrei feststellen, ob ein Unberechtigter die Dateien geändert hat.

Linux unterstützt dieses Vorgehen ohne Probleme und Zusatzkosten. Allerdings muss man dazu den alten syslogd über Bord werfen. Und auch den Secure Syslog (ssyslogd) sollten Sie nach Möglichkeit nicht mehr verwenden. Dieser enthält zwar bereits PEO-1, wird aber nicht mehr weiter gepflegt, was im Sicherheitsbereich ein potenzielles Risiko bedeutet.

Setzen Sie stattdessen von Anfang an auf den Nachfolger Modular Syslog (msyslogd). Er ist weitestgehend zu syslogd kompatibel. So unterstützt mysyslogd das gleiche Format in "/etc/syslog.conf", erweitert dieses aber für seine zusätzlichen Features.

Modular Syslog

msyslogd arbeitet nach einem recht intelligenten und erweiterbaren Prinzip. Bei jeder Aktion (=Ort der Protokollierung, z. B. Datei oder Host) in der syslog-Konfiguration lässt sich angeben, welches Modul von msyslogd die Protokollierung übernehmen soll. Für die herkömmliche, nicht geschützte "Buchführung", kommt das Modul "classic" zum Einsatz, bei PEO-1 ist "peo" einzutragen. Standardmäßig verwendet msyslog das klassische, ungeschützte Log-Format.

Um PEO-1 zu verwenden, ändern Sie beispielsweise den Befehl kern.* /var/log/kern.log in kern.* %peo /var/log/kern.log. Diese neue Zeile gibt an, dass zur Protokollierung der Kernel-Meldungen in die Datei "/var/log/kern.log" das PEO-Modul verwendet werden soll. Dieses Log-File ist damit über PEO-1 geschützt. Das mitgelieferte Programm "peochk" testet Log-Files auf widerrechtliche Änderungen.

Selbstverständlich kann msyslogd auch remote protokollieren und zusätzlich schützen, zum Beispiel:

*.* %peo @host

Derzeit bietet msyslogd außerdem noch die Module "mysql" und "pgsql" zum Protokollieren in eine MySQL- oder PostgreSQL-Datenbank. Das Modul "regex" dient zum Analysieren von Log-Einträgen und zum gezielten Protokollieren.

Msyslogd hat allerdings auch seine Schwächen. Wenn ein Modul die Ein-/Ausgabe blockiert, kann es zum Verlust von Log-Informationen kommen. Dieser Bug ist jedoch bekannt und wird in den nächsten Versionen wahrscheinlich nicht mehr existieren.

Der Protokollierung letzter Schliff

Mithilfe der Informationen in den Log-Files können Sie einen Eindringling nachträglich überführen. Deshalb sollten Sie alles zu deren Schutz unternehmen. "logrotate" ist in diesem Zusammenhang ein nützliches Tool.

logrotate rotiert und komprimiert die Log-Files automatisch. Außerdem kann es Log-Files an eine E-Mail-Adresse schicken. Machen Sie von diesem Feature Gebrauch, stehen Ihnen die Logs auch dann noch zur Verfügung, wenn Sie im System bereits überschrieben wurden.

Weitere verbesserte Protokollierungsfunktionen bietet der Daemon "xinetd", der eine sichere Alternative zu inetd darstellt. Seine Features umfassen:

• erweiterte Zugriffskontrolle

• Schutz vor DoS-Attacken

• Beenden von Verbindungen, die nicht mehr den Sicherheitskriterien entsprechen

• Benutzerinteraktion sowie

• erweiterte Protokollierungsfunktionen

Das einzige Hindernis liegt im gänzlich anderen Format der Konfigurationsdatei. Deren Aufbau ist jedoch nicht sehr kompliziert, so dass der Umstieg inklusive Einarbeitung in xinetd keine allzu große Hürde darstellen dürfte.

Simple Intrusion Detection

Ein Eindringling lässt sich durch seine Änderungen im System aufspüren. Doch nicht nur die Protokolldateien stehen auf der Modifikationsliste eines Hackers ganz oben. Einmal im System angelangt wird er sich die Konfiguration des Hosts vornehmen. Will er den Rechner als Plattform für Attacken auf weitere Systeme verwenden, wird er sich zudem Hintertürchen und sonstige ungewollte Dienstleistungen einrichten.

Diese Änderungen hinterlassen natürlich auch unvermeidliche Spuren im Dateisystem. Wird eine Konfigurationsdatei bearbeitet, ändert sich ihr Zeiteintrag und meist auch ihre Größe. Richtet jemand Hintertüren oder Trojaner ein, lässt sich das häufig anhand von Änderungen in den S-Bits oder auch der Größe von Binaries, wie Systemprogrammen und Daemons, erkennen. Solche Modifikationen kann ein Angreifer nur durch sehr großen Aufwand verbergen.

Das Aufspüren dieser Änderungen ist recht einfach. Sie müssen sich nur einmal eine (gesicherte) Vergleichsgrundlage schaffen. Nachdem das System aufgesetzt, vollständig konfiguriert und als definitiv "untermieterfrei" bestätigt ist, kann sich so schnell nichts mehr ändern. Was liegt also näher, als diesen Zustand durch einen "Schnappschuss" festzuhalten. In regelmäßigen Abständen vergleicht ein cron-Job diesen Soll-Zustand mit dem Ist-Zustand des Systems. Bei Änderungen sollten dann die Alarmglocken klingen.

Baselines

Einen solchen "Schnappschuss" - im Fachjargon "Baseline" genannt - können Sie mittels der Befehle "ls" und "find" auf der Shell anlegen. Als erstes erstellen Sie eine Baseline für die Dateien mit gesetztem S-Bit. Hier ist es sinnvoll, nur alle Verzeichnisse in PATH durchzuarbeiten und nicht alle Unterverzeichnisse von "/". Sollten die einzelnen User nämlich in Ihren eigenen ~/bin-Verzeichnissen selbst Programme anlegen und diese mit S-Bits versehen, würde Ihr Baseline-Audit jedes Mal Alarm schlagen, wenn ein User damit experimentiert.

Gewisse S-Bit-Änderungen bleiben dabei unerkannt. Diesen Kompromiss gilt es jedoch einzugehen. Außerdem nisten sich Trojaner, Viren und Hintertüren ohnehin meist in den PATH-Binaries ein.

Um die Baseline für die S-Bits festzulegen, verwenden Sie ls in Zusammenspiel mit find. Mit

find Verzeichnis -perm +6000

erhalten Sie eine Liste aller Dateien in "Verzeichnis", bei denen entweder das SUID (4000) oder GUID (2000) gesetzt ist. Um die kompletten Verzeichnisinformationen zu den Dateien zu erhalten, übergeben Sie diese Ergebnisliste an den ls-Befehl:

ls -lad --full-time `find Verzeichnis -perm +6000`

Damit erhalten Sie pro Datei mit einem gesetzten S-Bit eine Zeile im ls-Long-Format, die auch den ausführlichen Zeiteintrag (--full-time) enthält.

Statt Verzeichnis sollen nacheinander die Einträge aus der Shell-Variablen PATH eingesetzt werden. Um die durch Doppelpunkte separierten Einträge aus PATH zu erhalten, verwenden Sie am besten ein AWK-Programm. Dort können Sie als Record-Separator (RS) den Doppelpunkt eintragen und so die PATH-Einträge in Zeilen aufsplitten:

echo $PATH | awk 'BEGIN { RS=":" } { print }'

Baseline-Check

Wenn Sie dies alles nun in eine for-Schleife packen und die Ausgabe in eine Datei umleiten, erhalten Sie Ihre S-Bit-Baseline:

(for f in `echo $PATH | awk 'BEGIN { RS=":" } { print }'`;
do ls -lad --full-time `find $f -perm +6000` ;
done) > ~/s-bits.baseline

Die Datei "~/s-bits.baseline" enthält nun den "Schnappschuss" Ihrer S-Bits.

Achten Sie bitte darauf, dass Sie die Baseline als "root" anlegen. Schließlich sind es die über "root" erreichbaren Binaries, die gefährdet sind. Außerdem sind in der Regel im PATH eines normalen Users die sbin-Verzeichnisse mit den Daemons nicht eingetragen.

Ob Ihr System noch in dem Zustand ist, in dem es beim Anlegen der Baseline war, können Sie durch ein diff feststellen:

(for f in `echo $PATH | awk 'BEGIN { RS=":" } { print }'`;
do ls -lad --full-time `find $f -perm +6000` ;
done) | diff - ~/s-bits.baseline

Diesen Test können Sie durch einen cron-Job regelmäßig durchführen lassen. Der Vorteil von diff ist, dass es dem alten Unix-Grundsatz "no news are good news" folgt. Es liefert also nur eine Ausgabe, wenn wirklich eine Differenz beim Vergleich festgestellt wurde. Tritt dieser Fall ein, können Sie das diff-Protokoll direkt an "root" per E-Mail senden. Auf diese Weise ist die Alarmierung per E-Mail auch schon automatisiert.

Weitere Baselines

Die S-Bits sind nur eine sinnvolle Variante für Baselines. Sie sollten außerdem auch die restlichen Executables in PATH und die Konfigurationen in Baselines festhalten.

Die Executables können Sie in dieselbe Baseline wie die S-Bits aufnehmen. Tragen Sie hierzu einfach statt -perm +6000 die Option -perm +6111 ein. Sie können hier aber auch eine Trennung vornehmen und eine separate Baseline anlegen. Verwenden Sie in diesem Fall die Option -perm +0111. Diese Baseline erfasst allerdings auch nochmals die S-Bit-Dateien, da S-Bit-Files in der Regel immer ausführbar sind. Sie erhalten bei einer Änderung also zwei Alarmierungen für die S-Bit-Datei.

Die meisten und wichtigsten Konfigurationen liegen unter Linux im Verzeichnis "/etc". Hierfür sollten Sie auf jeden Fall eine Baseline anlegen. Sie können hierfür das Kommando

ls -lRa --full-time /etc > ~/etc.baseline

verwenden. Zum Test der Integrität dient dieses diff-Kommando:

ls -lRa --full-time /etc | diff - ~/etc.baseline

Legen Sie auch hierfür einen cron-Job an.

Wichtige Hinweise zu Baselines

Wann immer Sie neue Software installieren oder die Konfiguration ändern, müssen Sie die Baselines neu anlegen. Bevor Sie das jedoch machen, sollten Sie die Integritätstests durchführen. Ansonsten übersehen Sie eventuell einen Einbruch und nehmen ihn als gültig in das System auf!

Beachten Sie auch, dass Baselines nicht die schnellste Methode sind, um einen Eindringling aufzuspüren. Die Reaktionszeit hängt direkt davon ab, wie oft der cron-Job ausgeführt wird. Starten Sie den Test beispielsweise alle zehn Minuten, kann ein Hacker im schlimmsten Fall innerhalb dieser zehn Minuten Schaden anrichten.

Noch abschließend ein Hinweis zur Sicherung der Baselines selbst. Zunächst einmal sollten Sie Baselines nur für "root" lesbar machen und grundsätzlich schreibschützen:

chmod 0400 <Baseline>

Statt "Baseline" setzen Sie die einzelnen Dateien ein.

Sinnvoll ist es auch, die Baselines auf einen anderen Host zu legen und per Netzwerk verfügbar zu machen. Dieser Baseline-Host sollte möglichst hinter einer weiteren Firewall liegen und nicht per Internet erreichbar sein.

Auch sollte das Mounten des Baseline-Hosts über ein Netzwerk-Dateisystem wie NFS oder SMB nur schreibgeschützt erfolgen. Neue Baselines sollten Sie nur per Diskette oder CD-ROM auf den Baseline-Server übertragen können.

Aktive Audits

Die bisher vorgestellten Methoden zur Intrusion Detection sind passiver Natur. Sie konnten einen Eindringling nur anhand seiner Auswirkungen erkennen. Es gibt allerdings auch aktivere Methoden.

Einen noch nicht eingedrungenen Hacker können Sie in den Protokollen Ihrer Firewall erkennen. Wenn ständig ein Verbindungsaufbau über die Firewall nach dem selben Schema abgelehnt wird, liegt der Verdacht nahe, dass ein Hacker direkt an Ihrem System klebt, oder ein Sniffer auf Ihren Server angesetzt wurde. Doch dies hat nichts mit Intrusion Detection im eigentlichen Sinne zu tun. Schließlich ist der Hacker noch nicht im System, und es liegt somit noch keine "Intrusion" vor, die erkannt werden könnte. Allerdings sollten Sie hier hellhörig werden und selbstverständlich den Webmaster des angreifenden Systems verständigen.

Der erste Weg, einen aktiven Hacker im System zu erkennen, ist eine offene Internet-Verbindung zu ihm. Wenn er in ihrem System gelandet ist, muss ja eine Connection zu seinem eigenen System bestehen. Ideal zum Darstellen der offenen Verbindungen ist das Tool lsof. Es bietet wesentlich mehr Informationen als "netstat" und ist deshalb für die Intrusion Detection besser geeignet.

Überwachung mit lsof

Eine Liste, welche Internet-Verbindungen bestehen, erhalten Sie über lsof -i.

Das Beispielbild zeigt Ihnen, dass eine Telnet-Verbindung besteht. Ein User auf dem Host "leibniz" hat sich auf "kernighan" (Ihrem System) eingeloggt. Ideal ist, dass Sie hier sofort sehen, von wo aus die Verbindung herstellt wurde. Die Host-Angaben bestehen aus "Computer:Port". "Computer" kann hierbei ein per DNS oder "/etc/hosts" aufgelöster Netzwerkname sein, oder die IP-Adresse. "Port" gibt den TCP/IP-Port an.

Sie können damit feststellen von wo der Angriff erfolgt. Im obigen Fall müsste der Webmaster von "leibniz" kontaktiert werden, um dem Hacker auf die Spur zu kommen.

Über die Angabe "PID" erhalten Sie die ID des Prozesses, der auf Ihrem eigenen System für die Verbindung zuständig ist. Hier ist es der Wert "1114". Sie sehen auch im Klartext, welches Programm (hier in.telnet) die Verbindung abwickelt und unter welchem User (telnetd) der Prozess läuft.

Wollen Sie den Hacker unsanft aus dem System werfen, verwenden Sie einfach einen kill-Aufruf mit der PID als Argument. Zum Beispiel beenden Sie die obige TELNET-Verbindung unsanft per kill -s SIGKILL 1114.

Bestehende Netzwerkverbindungen lassen sich per grep auflisten:

lsof -i | grep '\\>->'

Über das Umleiten in Dateien und diff über diesen Dateien können Sie in cron-Jobs die Verbindungen mitprotokollieren.

Gelöscht und doch offen?

Sabotage-Programme müssen sich etwas einfallen lassen, um sich selbst Daten merken zu können. In Dateien mitzuprotokollieren ist eine einfache und effiziente Methode. Doch Dateien, die urplötzlich im System auftauchen, entgehen selbst einem durchschnittlichen Administrator nicht. Trotzdem müssen die digitalen Schädlinge nicht auf den Dateikomfort verzichten.

Unter Linux/Unix ist es auf Grund des Mehrbenutzer-Konzepts durchaus möglich, offene Dateien zu löschen, ohne dass Sie ad hoc aus dem System verschwinden. Die Prozesse, die die Dateien noch geöffnet haben, können damit ungehindert weiterarbeiten, obwohl die Datei aus dem Dateisystem verschwunden ist. Dieses Phänomen machen sich ungebetene Gäste häufig zu Nutze.

Hier ein kleines Beispiel: Legen Sie zuerst einen Prozess an, der eine Datei öffnet:

cat > ~/intrusion

Alle Eingaben von der Tastatur landen jetzt in der Datei "~/intrusion". Schieben Sie diesen Prozess jetzt mittels "Strg+Z" in den Hintergrund. Ein

ls ~/intrusion

beweist Ihnen, dass die Datei tatsächlich existiert.

Wenn Sie per rm -f ~/intrusion die Datei löschen, taucht sie im Verzeichnis nicht mehr auf. Holen Sie allerdings den Prozess wieder in den Vordergrund (Befehl fg), können Sie weiterhin Zeichen eingeben, ohne dass es einen Fehler gibt.

Versteckte Dateien anzeigen

Sie können jetzt spekulieren, dass die Eingaben des cat-Prozesses ins Leere gehen. Das ist jedoch nicht der Fall, wie die Befehlszeile lsof +L1 zeigt. Dieser Befehl listet alle offenen Dateien mit einem Link-Counter kleiner als 1 auf. Mit anderen Worten: Die gelöschten Dateien.

Wie Sie sehen, ist die Datei zwar gelöscht (deleted) aber noch geöffnet. Wenn Sie jetzt noch ein paar Mal den cat-Prozess in den Vordergrund holen und fleißig Zeichen eintippen und wieder nach hinten schieben, werden Sie bei "lsof +L1" feststellen, dass sich die Größe der Datei ändert. Die Daten werden also noch darin gespeichert. Für ein Sabotage-Programm ist es ein Einfaches, die in dieser Datei gespeicherten Daten wieder herauszulesen und weiter auch hineinzuschreiben. Solange die Datei geöffnet ist, kann der Schädling damit schalten und walten wie er will. Sowie Sie jedoch den cat-Prozess in den Vordergrund holen und über Strg+D oder Strg+C beenden, verschwindet auch die Datei.

Auf offene, aber gelöschte Dateien sollten Sie ein Auge haben. Zwar verwenden auch einige Daemons dieses Prinzip, wenn jedoch plötzlich ein neuer Prozess auftaucht, sollten Sie aufhorchen. Für diesen Fall gelten die gleichen Regeln wie für die Angaben von lsof -i.

Über Scripts und cron-Jobs können Sie solche offenen, gelöschten Dateien auch protokollieren und so Unstimmigkeiten schnell erkennen.

Fazit

Wer sein System mit einer Firewall abschottet und dann glaubt, sein System sei sicher, begeht einen fatalen Fehler. Administratoren mit dieser Einstellung werden sich früher oder später unangenehme Fragen anhören müssen, denn mit der einmaligen Absicherung ist die Arbeit noch lange nicht getan.

Die ständige Überwachung des Systems und das Erkennen von ungebetenen Gästen im System ist eine zentrale und wichtige Aufgabe des Administrators. Glücklicherweise muss er die Arbeit nicht komplett von Hand erledigen, denn die meisten Audits lassen sich gut automatisieren.

Zusätzliche Sicherheit bieten fertige Intrusion Detection Systems (IDS), die die Überwachung auf Angriffe in unterschiedlich tiefen Niveaus vornehmen. Die für Linux frei verfügbaren Systeme sollten Sie auch nutzen. Im Anhang finden Sie eine Liste der gebräuchlichsten Intrusion Detection Systeme. (mha)

Intrusion Detection Systeme

Die folgende Tabelle gibt Ihnen einen Überblick zu einigen IDS. Sie sind in steigender Komplexität angeordnet.

Frei verfügbare IDS

	IDS	Beschreibung
	chkwtmp	chkwtmp analysiert wtmp und meldet gelöschte Einträge. Damit lassen sich Änderungen in Log-Files entdecken.
	tcplogd	tcplogd erkennt Stealth-Scans, die mit "halb-offenen" Verbindungen arbeiten.
	Snort	Snort ist ein Packet-Filter, Sniffer und Logger, der Intrusion Detection via Baselines ermöglicht.
	HostSentry	HostSentry erkennt Login-Anomalien und meldet diese.
	Shadow	Shadow ist ein freies IDS, dass auf einer Reihe von freien Tools, wie tcpdump, aufbaut. Es ist auf ca. 14.000 Hosts im militärischen und kommerziellen Bereich installiert.
	MOM	MOM ist ein leistungsfähiges, komplexes IDS. Es arbeitet verteilt über das Netzwerk und ist nicht als 1-Host-Lösung gedacht.
	HummingBird System (Hummer)	Hummer ist ein IDS für große Netzwerke. Die einzelnen Teilsysteme können Sicherheitsinformationen austauschen und übers Netz verteilen.
	AAFID	AAFID ist ein relativ neueres Monitoring System und IDS, das sich noch im Alpha-Stadium befindet. Es arbeitet verteilt über das Netzwerk. Die einzelnen Infomationen tragen relativ kleine Agenten zusammen, die auf den Hosts im Netzwerk verteilt werden.