Intrusion Detection mit Linux


von Ralf Spenneberg
 

Intrusion Detection bietet keinen Schutz vor Angriffen. Besonders die zu Beginn des Jahres aufgetretenen DenialofService Angriffe können mittels der Intrusion Detection nicht abgewendet werden. Jedoch erlaubt sie die Erkennung eines Angriffes beim Versagen aller anderen Sicherheitssysteme. Der Administrator kann den Angriff und häufig auch die Methode und Vorgehensweise des Angreifers erkennen und aus ihr lernen. Das ermöglicht die Verbesserung der Sicherheitsmechanismen und in Zukunft den Schutz vor einer Wiederholung des Angriffes. Eine schnelle Reaktion ist häufig essentiell bei der Schadensbegrenzung.
 

Einführung: Warum, Was, Wie?
Stufe 1: Der einfache Audit
Stufe 2: Protokollierung
Stufe 3: Automatische Audits
Stufe 4: Überwachung des Netzes
Implementierung im Kernel: LIDS
Fazit

 

Einführung: Warum, Was, Wie?

Einer der schlimmsten Alpträume für jeden Systemadministrator stellt ein Einbruch in sein Netzwerk oder einen seiner Rechner durch dritte Personen dar. Viele Administratoren entgegnen dieser Gefahr mit Sicherheitslösungen wie zum Beispiel Firewalls und wiegen sich dann in Sicherheit. Warum benötigen wir dennoch in der heutigen EDV-Umgebung Intrusion Detection?

Intrusion detection is needed in today's computing environment because it is impossible to keep pace with the current and potential threats and vulnerabilities in our computing systems.

(Sans Institute ID FAQ: http://www.sans.org/newlook/resources/IDFAQ/ID_required.htm)

Wahrscheinlich ist es unmöglich, einen im Netzwerk kommunizierenden Rechner mit heutigem Betriebsystem 100% sicher zu konfigurieren. Daher besteht immer die Gefahr eines möglichen Einbruches durch Dritte auf diesem Rechner.

Ist man sich dieser Tatsache bewußt, so stellt sich die Frage, wie ein Einbruch, der mangels Kenntnis nicht abgewehrt werden konnte, zumindest erkannt, verstanden und in Zukunft abgewendet werden kann.

Mit der Erkennung dieser Einbrüche beschäfigt sich die Intrusion Detection. Zum Erreichen dieses Ziels genügen in den meisten Fällen relativ einfache Mittel der Überwachung, die im Rahmen dieses Artikels vorgestellt werden. Jedoch existieren auch komplette Softwarepakete, die für diese Zwecke eingesetzt werden können. Einige dieser Pakete werden ich im Rahmen dieses Artikels vorstellen.

 

Stufe 1: Der einfache Audit

Grundvoraussetzung für die Erkennung eines Einbruches ist eine gute Kenntnis des Systems, seiner Dateien, Rechtestrukturen und Dienste. Besitzt der Administrator diese Kenntnisse, so kann er recht einfach Änderungen, wie erweiterte Rechte einzelner Dateien, hinzugekommene Dateien oder neue offene Netzwerkports, die neue Dienste anzeigen, erkennen. Die hierfür erforderlichen Werkzeuge befinden sich meist bereits auf einem Linux System oder können einfachst installiert werden. Der find-Befehl bietet zum Beispiel die Möglichkeit sämtliche Befehle mit gesetzten S-Rechten auf dem System aufzuspüren. Ist das SetUID oder das SetGID Recht einer ausführbaren Datei gesetzt, so erhält der Prozeß, der durch Aufruf des Befehls gestartet wird, die effektiven Rechte des Besitzers des Befehls:

[root]# chmod u+s /bin/bash
[root]# ls -al /bin/bash
-rwsr-xr-x 1 root root        373176 Apr  6  1999  /bin/bash
[root]# su benutzer
[benutzer]$bash
[benutzer]#

Der find / -type f -perm +6000 findet alle Dateien auf dem Rechner, die das SetUID oder SetGID Recht gesetzt haben. Durch die Umleitung in eine Datei kann diese Liste als Baseline gesichert werden. Das Ergebnis eines späteren erneuten Aufrufes des Befehls kann mit Hilfe des diff-Befehls sehr komfortabel mit der Baseline verglichen werden. Der Befehl ls /etc -alR --full-time zeigt alle Dateien des /etc Verzeichnisses mit Ihrer letzten Änderung an. Auch hier kann eine Baseline aufgenommen und mit einem späteren Ergebnis mittels diff recht einfach verglichen werden. Dabei fallen hier Änderungen der Rechte, hinzugekommene Dateien und Veränderungen des Zeitstempels der letzten Änderung der Dateien auf. Auch die Dateigrößen werden verglichen. Ein Austausch des ps-Befehls kann entdeckt werden, wenn zuvor das /bin Verzeichnis aufgenommen wurde.

Diese Verfahren erkennen jedoch nur dem System bekannte Dateien. Sollte der Angreifer für die Protokollierung eine geöffnete Datei verwenden, die nicht mehr im Dateisystem referenziert wird, so wird diese nicht gefunden. Dieses Verhalten kann durch das Öffnen einer Datei und anschließende Löschung der Referenz auf den Datei-Inode erzeugt werden. Da dieses Verfahren häufig in Kombination mit Netzwerk- und Kennwortsniffern zur unbeobachteten Protokollierung genutzt wird, sollte das System regelmäßig auf derartige Dateien untersucht werden. Hierzu kann der Befehl lsof eingesetzt werden: $ lsof +L1 sucht nach offenen Dateien mit einem LinkCount kleiner 1.

Genauso wichtig wie die Kenntnis der auf dem System vorhandenen Dateien ist die Kenntnis der auf dem Rechner installierten Dienste und der von diesen Diensten geöffneten Netzwerkverbindungen. Auch hier kann der lsof-Befehl dem Linux-Administrator unter die Arme greifen: lsof -i zeigt alle geöffneten Internetports auf dem Rechner:

COMMAND	PID	USER	FD	TYPE	DEVICE		SIZE/OFF	INODE	NAME
rlogin	25023	abe	3u	inet	0x10144168 	0t184           TCP	vic.cc.purdue

Im Gegensatz zu netstat -a zeigt lsof -i bei jedem Port auch den ensprechenden Prozeß und Benutzer an.

Sinnvollerweise automatisiert man den gesamten Prozeß mittels crontab. Des weiteren sollten die entsprechenden Dateien und Befehle auf einer Diskette gesichert werden, so daß ein Einbrecher nicht diese Dateien und Befehle verändern kann.

 

 

Stufe 2: Protokollierung

In diesem Abschnitt wird ein anderer Ansatz verfolgt. Ein Einbrecher wird versuchen, grundsätzlich die Spuren seines Einbruchs zu entfernen, um so seiner Entdeckung zu entgehen und die Analyse des Einbruchs zu erschweren. Häufig erlaubt die Analyse der Protokolldateien einen Rückschluß auf die Methode, die für den Einbruch genutzt wurde.

Für die Protokollierung auf einem UNIX-Rechner wird üblicherweise der syslogd eingesetzt. Dieser erlaubt unter anderem die Protokollierung über das Netzwerk. Damit erlaubt es der syslogd, die Protokolldateien auf einem weiteren Rechner abzuspeichern und so dem Einbrecher zu entziehen.

Dazu ist in der syslogd.conf ein Eintrag in der Form

*.*		@hostname

einzutragen. Dieser protokolliert nun alle Meldungen zusätzlich auf dem Rechner hostname. Dies stellt jedoch ein Problem dar, wenn der syslogd mit Meldungen überschwemmt wird. Dann kann die Protokollierung nicht mehr korrekt stattfinden. Daher wird von einer Protokollierung über das Netzwerk häufig abgesehen. Dann hat jedoch der Einbrecher die Möglichkeit, die Protokolldateien frei zu editieren, ohne daß diese Veränderungen entdeckt werden können.

 

Abhilfe schafft hier ssyslogd, eine Implementierung des syslogd, welcher die Meldungen in den Dateien mittels PEO-1 verschlüsselt in den Protokolldateien abspeichert. Der ssyslogd verwendet kompatibel zu syslogd die syslogd.conf Datei für seine Konfiguration. Um nun die Meldungen in einer Datei unter Verwendung dieses Protokolls zu schreiben wird folgender Eintrag vorgenommen:

*.info		[peo]		/var/log/messages

 

Weiterhin wichtig ist die automatische Rotation der Protokolldateien und die Sicherung der alten Protokolle z.B. per Email. Für diese Aufgabe läßt sich sehr gut logrotate einsetzen.

Beschäftigte sich der vorherige Abschnitt mit dem Sichern der protokollierten Daten, kann der xinetd wesentlich aufschlußreichere zu protokollierende Daten produzieren. Der xinetd ist ein Ersatz für den inetd, der unter anderem folgende Vorzüge bietet:

Problematisch bei der Einführung des xinetd ist das inkompatible Format der Konfigurationsdatei. Hier ein abgewandelter Auszug aus der xinetd-faq, der die Verwendung des xinetd erläutert:

service telnet
{
	log_on_success  = HOST PID DURATION USERID #bei erfolgreicher Anmeldung
	log_on_failure  = HOST PID USERID #bei nicht erfolgreicher Anmeldung
	no_access       = 152.30.11.93 #wer hat keinen Zugriff
	socket_type     = stream
	protocol        = tcp
	port		= 23
        log_type        = SYSLOG daemon #Art der Protokollierung
	max_load	= 2.5 #max. Load des Servers
	access_times	= 8:00-20:00 #erlaubte Uhrzeiten für den Zugriff
	instances	= 20 #maximale Anzahl an Dienstprozessen
}

Um die Umwandlung der alten inetd.conf in das neue Format zu erleichtern, dient der Befehl itox < /etc/inetd.conf > /etc/xinetd.conf

 

 

Stufe 3: Automatische Audits

Die bisher vorgestellten Methoden insbesondere des ersten Abschnittes verlangen die regelmäßige Durchführung des Audits. Hierzu sollten Richtlinien erstellt werden, die diese Überprüfungen in definierten Zeitabständen und einer definierten Reihenfolge durchführen.

Da diese Richtlinien stets nur so gut sein können, wie die Personen, die diese Richtlinien entwerfen und einsetzen, bietet sich die Automatisierung dieser Verfahren an. Dabei lassen sich dann meist auch noch mehr Informationen verarbeiten und vergleichen, als wenn die entsprechende Arbeit von Hand durchgeführt werden würde.

Für die Automatisierung des rechnerbasierten Audits bieten sich eine Reihe von Werkzeugen an, von denen eine nicht repräsentative Auswahl hier aufgeführt ist:

Diese Werkzeuge arbeiten alle ähnlich und kopieren dabei meist die Vorgehensweise des Programmes Tripwire. Dabei handelt es sich um ein komerzielles Programm, welches seit einiger Zeit für Linux als OpenSource angekündigt ist. Das Programm erzeugt eine Momentaufnahme des gesamten Dateisystems oder einzelner Verzeichnisse und speichert diese als MD5-Hash. Eine spätere Momentaufnahme kann mit diesem Hash verglichen werden. So können veränderte Dateien entdeckt werden. Da es sich um einen MD5-Hash handelt, kann diese Datei nur gelöscht, jedoch nicht verändert werden. Der Einbruch wird also in jedem Fall bemerkt.

 

Weiterhin ist eine regelmäßige Untersuchung der Protokolldateien zwingend erforderlich, denn nur dort können versuchte Einbrüche detektiert werden. Häufig geht einem erfolgreichen Einbruch eine Serie erfolgloser Versuche voraus, in denen das System ausgekundschaftet wird. Auch diese Untersuchung läßt sich automatisieren. Die bekanntesten Werkzeuge hierzu sind unter anderem:

Diese Werkzeuge verfolgen die Protokolldateien und untersuchen die Einträge auf verdächtiges Verhalten. Sie lassen sich dabei umfangreich konfigurieren und ermöglichen die spezifische Suche nach bestimmten Aktivitäten.

 

 

Stufe 4: Überwachung des Netzes

Der Einsatz des xinetd ermöglicht bereits die Reaktion auf Angriffe über das Netzwerk. Die meisten Angriffe erfolgen wahrscheinlich über das Netzwerk, obwohl man die Angriffe, die durch lokal angemeldete Benutzer erfolgen, nicht vernachlässigen darf. Die genaue Bewertung hängt immer vom Einsatz des Linuxrechners ab.

Es gibt einige Werkzeuge, die dem Administrator bei dieser Aufgabe behilflich sein können. Arpwatch überwacht die in dem Netzsegment verwendeten MAC-Adressen und meldet neue Adressen. Es kann benutzt werden, um neu zu dem Netz hinzugekommene Rechner zu entdecken. Wird die Anwesenheit eines Netzwerksniffers vermutet, so kann neped möglicherweise diesen erkennen.

Sollen Portscans detektiert werden, mit denen Angreifer üblicherweise versuchen, das Betriebssystem und die verfügbaren Dienste auf dem Rechner zu erkennen, so kann unter anderem PortSentry eingesetzt werden. Portsentry detektiert eine Reihe von Portscans und reagiert in Echtzeit zum Beispiel mit einer Sperrung des Hosts mittels ipchains und Protokollierung des Angriffes durch den SysLog.

Sollen alle Pakete, die in dem Netz transportiert werden, auf mögliche Einbruchsversuche und Einbrüche untersucht werden, bieten sich netzwerkbasierte Intrusion Detection Systeme an. Die beiden wahrscheinlich bekanntesten freien Werkzeuge sind:

Diese Werkzeuge verfügen über eine Bibliothek von Fingerabdrücken bekannter Einbrüche und können so Pakete auf diese Fingerabdrücke untersuchen. Die Reaktion dieser Programme läßt sich flexibel konfigurieren; so können sie Protokolldateien schreiben, Emails versenden und Pager aktivieren.

 

 

Implementierung im Kernel: LIDS

Waren die bisher vorgestellten Werkzeuge eigenständige Programme, die auf dem Linux-Betriebsystem aufsetzten, so gibt es seit einigen Monaten einen weiteren Ansatz, der versucht die Intrusion Detection in den Kernel zu verlegen: LIDS - Das Linux Intrusion Detection System.

LIDS ist ein Patch für den Linux Kernel und implementiert eine Reihe von zusätzlichen Funktionen.

The Linux Intrusion Detection System is a patch which enhances the kernel's security. When it is in effect, chosen files access, every system/network administration operations, any capability use, raw device, mem and I/O access can be made impossible even for root. It uses and extends the system capabilities bounding set to control the whole system and adds some network and filesystem security features in kernel to enhance the security. You can finely tune the security protections online, hide sensitive processes, receive security alerts through the network, and more.

http://www.lids.org/lids-howto/build_lids.html LIDS bietet so die Kontrolle über alle sensitiven Bereiche des Linux Betriebssystems und verweigert sogar root den Zugriff auf diese Bereiche. Zu diesen geschützten sensitiven Bereichen zählen

Desweiteren bietet LIDS die Erkennung eines Zugriffes auf diese Bereiche und eines Scans des Rechners über das Netzwerk. Schließlich bietet LIDS die Möglichkeit der Reaktion auf derartige Vorgänge. Diese Reaktionen können in der Protokollierung bestehen als auch in der Abmeldung des Benutzers, der versucht, die von LIDS gesetzten Regeln zu verletzen.

 

Nach dem Patchen, der Kompilierung und Installation des neuen Kernels kann LIDS konfiguriert werden. LIDS bietet hierzu einige Optionen bei der Konfiguration des Kernels, als auch den Befehl lidsadm. Für den Schutz von Dateien kennt LIDS zwei Varianten:

Für Prozesse bietet LIDS zwei Arten des Schutzes:

Zusätzlich bietet LIDS die Unterstützung der Capabilities. Hier können verschiedene Capabilities online an- oder abgeschaltet werden. Dazu gehört zum Beispiel die CAP_NET_ADMIN die erforderlich ist für die Konfiguration von:

Um nun die gewünschten Capabilities zu entfernen und das System zu versiegeln, wird der Befehl lidsadm -I -- -CAP_SYS_MODULE -CAP_SYS_RAWIO -CAP_SYS_ADMIN -CAP_SYS_PTRACE -CAP_NET_ADMIN aufgerufen.

 

Ist LIDS installiert, konfiguriert und das System versiegelt, so bietet LIDS drei verschiedene Möglichkeiten der Antwort auf einen Angriff auf das System:

LIDS befindet sich noch in der Entwicklung und sollte daher mit Vorsicht auf Produktionsgeräten eingesetzt werden. Jedoch hat es sich im täglichen Gebrauch als stabil erwiesen. Die bisher implementierten Eigenschaften und die rasche Weiterentwicklung lassen hier ein für die Zukunft stabiles System erwarten, das ein Großteil der in diesem Artikel angesprochenen Probleme im Kernel lösen kann.

 

 

Fazit

Intrusion Detection bietet keinen Schutz vor Angriffen. Besonders die zu Beginn des Jahres aufgetretenen DenialofService Angriffe können mittels der Intrusion Detection nicht abgewendet werden. Jedoch erlaubt sie die Erkennung eines Angriffes beim Versagen aller anderen Sicherheitssysteme. Der Administrator kann den Angriff und häufig auch die Methode und Vorgehensweise des Angreifers erkennen und aus ihr lernen. Das ermöglicht die Verbesserung der Sicherheitsmechanismen und in Zukunft den Schutz vor einer Wiederholung des Angriffes. Eine schnelle Reaktion ist häufig essentiell bei der Schadensbegrenzung. Der genaue Bedarf muß im Einzelfall entschieden werden. Jedoch sollte auf einem Rechner ein systembezogenes Auditing als auch eine Überwachung des umgebenden Netzwerkes in Betracht gezogen werden. Selbst bei Einsatz einer Firewall sollte der Überwachung des internen Netzwerkes einige Aufmerksamkeit gewidmet werden. Es kann zum einen ein Benutzer eines Rechners im Intranet versuchen, Zugang zu einem weiteren Rechner im Intranet zu erlangen. Darüberhinaus kann die Firewall versagen oder Lücken aufweisen, die es einem Dritten erlauben, über die Firewall in das interne Netz zu gelangen. Die Intrusion Detection ist ein dauernder Wettlauf mit den Einbrechern, die immer neue Methoden entwickeln um in fremde Rechner und Netze einzubrechen. Copyright 2000 Ralf Spenneberg. Dieses Dokument darf entsprechend der OPL verbreitet werden.