IT-Academy Logo
Sign Up Login Help
Home - Betriebssysteme - Unix - Server/Internet/Netzwerk - IDS - aber wie?



IDS - aber wie?

Installation und Konfiguration eines einfachen IDS unter Unix und wie man NICHT auf Einbruchsversuche reagieren sollte (mit Beispielskripten).


Autor: Jochen Berner (jberner)
Datum: 07-06-2002, 21:54:50
Referenzen: http://www.enteract.com/~lspitz/ids.html (der englische Originalartikel)
Schwierigkeit: Fortgeschrittene
Ansichten: 3264x
Rating: Bisher keine Bewertung.

Hinweis:

Für den hier dargestellte Inhalt ist nicht der Betreiber der Plattform, sondern der jeweilige Autor verantwortlich.
Falls Sie Missbrauch vermuten, bitten wir Sie, uns unter missbrauch@it-academy.cc zu kontaktieren.

[Druckansicht] [Als E-Mail senden] [Kommentar verfassen]



Einbruchserkennung

Ihr Netzwerk wird auf Schwachstellen untersucht. Ob nun einmal monatlich oder zweimal am Tag spielt keine Rolle, es gibt Leute da draußen, die Ihr Netz und Ihre Systeme auf Schwachstellen untersuchen. Ich kann dies mit Sicherheit behaupten, da ich noch kein Netzwerk kennengelernt habe, das nicht ausgetestet wurde. Mein eigenes Netzwerk zu Hause mit sechs Rechnern hängt an einer eigenen ISDN-Leitung. Es enthält weder wichtige Daten noch repräsentiert es eine Organisation und wird trotzdem zwei- bis viermal die Woche untersucht. Sobald man ein System oder Netzwerk mit dem Internet verbindet wird man zum Ziel. Dieser Artikel will erklären, wie man sich dagegen schützen kann, indem man diese Einbruchsversuche erkennt. Anschließend werde ich erläutern, was man tun kann, wenn man einen solchen Versuch erkannt hat.

Einrichten einer Einbruchserkennung

Die Methoden die hier behandelt werden sind einfach zu implementieren und zu nutzen. Für größere oder sicherheitsbewusstere Organisationen sollte man über Produkte von Drittanbietern wie den Network Flight Recorder (http://www.nfr.net/nfr) nachdenken. Diese fortgeschritteneren IDS-Systeme (IDS=Intrusion Detection System) nutzen eine Netzwerkverkehrsanalyse und moderne Algorithmen um festzustellen, ob eine Untersuchung stattgefunden hat. Unser Ansatz wird etwas einfacher sein.

Es gibt eine Vielzahl von verschiedenen Untersuchungsmethoden die Hacker ausprobieren werden. Die erste auf die wir uns vorbereiten ist am meisten verbreitet: Port Scans. Bei einem Port Scan versucht jemand sich mit einer Menge unterschiedlicher Ports zu verbinden. Die Abfrage kann entweder auf ein einzelnes System oder einen, oft zufällig ausgewählten, IP-Adressbereich gerichtet sein. Es handelt sich um eine der populärsten Methoden bei Hackern, um Informationen zu sammeln, da man hiermit feststellen kann, welche Ports und Dienste offen sind.

Um diese Abfragen festzustellen, werden wir ein System aufbauen, das uns per e-mail Alarmmeldungen schickt sobald jemand versucht, sich mit einem vorgegebenen Port zu verbinden. Zuerst legen wir drei bis fünf der am häufigsten getesteten Ports fest. Dann bestimmen wir zwei oder drei Systeme die auf diesen Ports lauschen. Untersucht ein
Eindringling unser Netzwerk wird er sehr wahrscheinlich auf eines unserer Systeme treffen. Wird dieses System auf einem seiner Ports untersucht, wird es diesen Versuch protokollieren, verschiedene, vorher festgelegte, Aktionen ausführen und abschließend eine Alarmmeldung an eine Kontaktperson senden.

Das Endergebnis besteht aus einer e-mail für jeden untersuchten Port. Bei drei Systemen die jeweils auf vier Ports lauschen macht das zwölf e-mails bei einem einzelnen Netzwerk-Scan. Normalerweise ist dies aber nicht der Fall. Wenn Hacker ein ganzes Netzwerk untersuchen, suchen sie normalerweise nach einer einzelnen Schwachstelle, wie z.B. imap (Port 143). In so einem Fall hätten wir lediglich drei e-mails bekommen, eine von jedem System. Wenn Hacker ein einzelnes System testen, so untersuchen sie einen ganzen Bereich von Ports, wie z.B. 1-1024. In diesem Fall hätten wir vier e-mails bekommen, für jeden Port eine. Auf der Basis der empfangenen e-mails kann man schnell feststellen, woran der Hacker interessiert war. (siehe Anhang 1)

Um diese Methodik einzusetzen legen wir zuerst zwei bis drei zu überwachende Systeme fest. Ich nehme oft DNS-Server für diese primären Ziele, da viele Scanningtools mit dem Scan von DNS-Servern beginnen, um eine Datenbank mit IP-Adressen aufzubauen. Dann wählen wir drei bis fünf der meistuntersuchten Ports. Stellen Sie sicher, dass Sie diese Ports nicht verwenden, da Sie sonst jedesmal, wenn sich jemand mit diesem Port verbindet, alarmiert werden. Um diese geläufigen Ports herauszufiltern sind die CERTS Alarme ein sehr guter Einstieg. Zu finden sind sie hier: www.cert.org. Die Ports, die wir hier benutzen werden sind:

imap (port 143)
SMB (port 139)
login (port 513)
http (port 80)

Ich bevorzuge diese Ports, da Hacker sie gewöhnlich testen, die meisten unserer Systeme sie aber nicht nutzen. Stellen sie sicher, dass diese Ports nicht durch einen Router oder eine Firewall geblockt werden. Wir werden dann einige Systeme bestimmen, die auf diesen Ports lauschen und uns alarmieren wenn eine Verbindung aufgebaut wird

Unser Lösungsansatz nutzt TCP Wrapper. Die von Wietse Venema erfundenen TCP Wrapper erlauben uns, jeden damit geschützten Dienst zu kontrollieren, protokollieren und, als wichtigstes, auf Ereignisse dieses Dienstes zu reagieren. Verbindet sich jemand mit den oben definierten Ports, so protokolliert der TCP Wrapper diese Verbindung (per syslog) und verzweigt dann in unseren Alarmmechanismus.

Diejenigen Leser, die noch keine TCP Wrapper installiert haben, empfehle ich dringend, dies nachzuholen. Sie sind sehr einfach zu kompilieren, konfigurieren und implementieren. Man findet sie in vielen Softwarebibliotheken, wie ftp://ftp.cerias/purdue.edu/pub/tools/unix. Bevor sie kompilieren sollten Sie die Spracherweiterungen im Makefile aktivieren (das verbessert die Konfigurierbarkeit erheblich). Wir werden diese Fähigkeit zur Einbruchserkennung verwenden. Mehr Informationen über die Installation von TCP Wrappern finden Sie in dem Artikel "Solaris Härten".

Nachdem wir die TCP Wrapper kompiliert und installiert haben, möchten wir sie auf die vier oben definierten Ports anwenden. Diese Ports werden erst in /etc/services definiert und dann in der Datei /etc/inetd.conf hinzugefügt. Hier ist ein Beispiel für imap in der Datei /etc/inetd.conf

imap stream tcp nowait root /usr/local/bin/tcpd imap.trap

Wenn sich jemand mit Port 143 verbindet, akzeptiert tcpd die Verbindung von inetd. Dann schaut es in die Datei /etc/hosts.allow für die Zugriffskontrolle. Hier können wir festlegen, welche Verbindungen den Alarm auslösen dürfen. Abschließend wird imap.trap gestartet. Den Namen imap.trap muss man an jeden überwachten Dienst anpassen, z.B. http.trap für http oder smb.trap für smb. Unten finden Sie ein Beispiel für einen Eintrag in /etc/hosts.allow der uns vor einer möglichen Überprüfung warnt

imap.trap: ALL: spawn (/var/adm/ids.sh %d %h %H)

Dies weist tcpd an, alle Verbindungen zu Port 143 unabhängig von der IP-Adresse zuzulassen und dann per "spawn" unser Warnskript zu starten. Wir verwenden "spawn" statt "twist" da "twist" den entfernten Computer für alle stdout und stderr Ausgaben verwendet. Die drei Parameter nach dem ids.sh Aufruf werden zu übergebenen Variablen.

In dem Skript /var/adm/ids.sh findet alles wichtige statt. Man kann es aber an die eigenen Bedürfnisse anpassen. Ich habe im Anhang 2 ein Beispiel angefügt, das die Daten auswertet, ein safe_finger für den Client durchführt, eine Warnmeldung an eine Kontaktstelle schickt und optional noch snoop startet um zusätzliche Aktionen zu verfolgen.

Jetzt bekommen wir, wann immer jemand versucht sich mit den festgelegten Ports zu verbinden, eine formatierte e-mail mit allen wichtigen Daten. Nehmen wir an, ein Nutzer untersucht das Netz auf Port 143 um imap-Schwachpunkte zu finden. Drei unserer Systeme lauschen auf diesem Port. Die Verbindung wird hergestellt und tcpd gestartet. Er schaut in die Datei /etc/hosts.allow und findet einen Eintrag für imap.trap. Er startet unser Skript /var/adm/ids.sh, das die Daten auswertet, ein finger auf den anfragenden Computer ausführt und uns dann per e-mail informiert. Wir hätten auch die Möglichkeit andere Programme auszuführen, in diesem Beispiel snoop. Das letzte was passiert ist der Versuch von tcpd /usr/sbin/imap.trap zu starten, das er aber nicht findet. tcpd beendet sich, schreibt aber vorher eine Fehlermeldung in das syslog. Um das zu verhindern könnte man ein Shellskript /usr/sbin/imap.trap erstellen, das nichts tut außer sich zu beenden.

Eine Sache, die man beachten sollte sind Denial-of-Service Angriffe. Je mehr man sein Skript ausführen lässt, desto mehr Systemlast erzeugt man. Ein Angreifer könnte das System außer Gefecht setzen, indem er mehrfach Verbindungen zu den überwachten Ports aufbaut und dadurch mehrere Instanzen des Skripts startet. Ich empfehle, die Zahl der Prozesse pro IP-Adresse zu beschränken, wenn man sehr umfangreiche Skripte verwendet. Eine einfache Methode dies zu erreichen, wäre per "grep" in tcpdlog nach der Quelladresse zu suchen. Findet man sie nicht, so ist dies der erste Versuch dieses Systems und man kann sein Überwachungsskript starten. Anderenfalls wurde man von dieser Adresse bereits überprüft und es reicht, den Versuch zu protokollieren.

Eine Alternative zu TCP Wrappern sind Routerprotokolle. Viele von uns haben nicht die Möglichkeit, drei Systeme zur Einbruchsüberwachung einzusetzen. Man kann die oben beschriebene Methode auch mit Hilfe des Internetrouters einsetzen. Suchen Sie sich wieder zwei oder drei Maschinen, sowie drei bis fünf zu überwachende Ports. Erzeugen sie im Router eine ACL (Access Control List=Zugriffskontrollliste), die den Zugang zu den gewählten Maschinen und Ports sperrt. Weisen Sie diese ACL an, sämtliche Verbindungsversuche zu einem syslog-Server zu protokollieren. So können Sie jeglichen abgelehnten Verkehr überwachen und schnell feststellen, ob Ihr Netzwerk gerade überprüft wurde. Ich habe große Erfolge mit dieser Methode zusammen mit "Swatch", das den Filter- und Alarmierungsprozeß automatisiert, erzielt.

Diese Lösungen sind nicht narrensicher. Viele moderne Portscanner führen keine vollständige TCP SYN/ACK Sequenz durch. Tatsächlich verwenden viele Scans ungültige Pakete (wie die FIN oder Xmas Scans). Die vorgestellten Methoden entdecken einige dieser Scans NICHT. Für eine stabilere Einbruchserkennung braucht man fortgeschrittenere Werkzeuge wie tcplogd (http://www.kalug.lug.net/tcplogd), das diese getarnten Versuche erkennen kann.

Es gibt noch andere Arten und Weisen, die man verwenden kann um Eindringlinge zu erkennen. Aber auch hier muss man zuerst die Methodik herausfinden um dann eine angepasste Überwachungs- und Alarmierungsprozedur einzusetzen. Ein Beispiel wären Brute-Force-Angriffe um sich anzumelden. Fünf aufeinanderfolgende fehlgeschlagene Anmeldeversuche werden in /var/adm/loginlog festgehalten. Dies passiert zum Beispiel wenn ein Hacker Ihr System auf schwache Kombinationen von Anmeldenamen und Paßwörtern überprüft. Ich habe alle meine Systeme so eingestellt, daß ein täglich laufender cronjob prüft, ob Einträge in dieser Datei vorhanden sind. Wenn ja, heißt das entweder, dass jemand sein Passwort vergessen hat und nun versucht es zu erraten oder ein möglicher Hacker hat versucht, sich per Brute-Force Attacke anzumelden. Der cronjob schickt mir die Einträge per e-mail, kopiert sie in ein Archiv und löscht das alte Protokoll. Ein anderes Beispiel ist die verbreitete /cgi-bin/test-cgi Attacke bei Webservern. Anstatt das cgi-Skript zu deaktivieren kann man es so ändern, das es eine e-mail schickt, sobald jemand versucht diese Sicherheitslücke auszunutzen. Dazu braucht es normalerweise nicht mehr als eine Anpassung des Shellskripts test-cgi (testen Sie ausgiebig, bevor Sie es auf Ihrem System einsetzen).

Auf einen Einbruchsversuch reagieren

Der erste Schritt besteht darin, sich zu vergewissern, das die eigenen Systeme tatsächlich geprüft werden. Nur weil man eine e-mail von unserem TCP Wrapper bekommen hat, heißt das noch NICHT, dass man gerade gescannt wird. Ein verirrter Nutzer könnte versuchen, sich mit dem falschen System zu verbinden, oder jemand hat schlicht eine falsche Taste gedrückt. Nichts ist peinlicher, als jemanden wegen etwas zu beschuldigen, dass er nicht getan hat. Wenn jedoch gleichzeitig drei Systeme auf dem gleichen Port überprüft wurden, könnte das darauf hindeuten, das man gescannt wurde. Und jetzt?

Das letzte was Sie tun sollten ist ein Gegenangriff auf das andere System um den Gegner abzuschießen. Wenn das eigene Netzwerk gescannt wird ist man frustriert und möchte diesen Frust an dem anderen System auslassen. Da sich jemand anscheinend darauf vorbereitet, Sie zu hacken, sollten Sie nicht etwas unternehmen? Sie sollten allerdings sehr vorsichtig sein, wie Sie reagieren.

1. Ihre Systeme wurden tatsächlich gescannt, aber nur zufällig. Große Organisationen scannen oft ihre internen Netzwerke und Außenstellen. Jemand könnte das falsche Netzwerk überprüft haben (ich selbst weiß von einer Organisation, bei der das vorgekommen ist)
2. Oft wissen die Leute die verantwortlich für die Systeme sind, von denen Sie gescannt wurden gar nichts davon. Große Netzwerke mit hunderten Nutzern und Systemen könnten einen böswilligen Nutzer haben, der illegal seine Netzanmeldung nutzt um andere Netzwerke zu scannen. Oder das System wurde gehackt und dient jetzt als Startpunkt. Egal wie, der Admin des Systems wird es wissen wollen um das Problem lösen zu können.
3. Die Quell IP-Adresse, die in Ihren Protokollen auftaucht könnte nicht zu einem echten System gehören, sondern nur als Köder dienen. Viele Scanprogramme erlauben es dem Nutzer, die eigene IP-Adresse auf beliebige Werte zu setzen. In den Protokolldateien könnte stehen, das man von fünf verschiedenen Quellen gescannt wurde, wobei es sich tatsächlich um das gleiche System handelt. Der Nutzer versucht die wahre Quelle des Scans zu verschleiern, indem er falsche IP-Adressen verwendet. Dadurch wird es extem schwer, die tatsächliche Quelle zu identifizieren. Außerdem könnte er seine IP-Adresse gefälscht haben, um jemand anderen die Schuld zuzuschieben.

Selbst mit den besten Absichten kann man mehr Unheil anrichten als Gutes tun. Nehmen wir an, Sie finden heraus, das das System das Sie gescannt hat gehackt war und nur als Startpunkt diente. Sie entdecken eine Hintertür, die der Hacker gelassen hat, verschaffen sich Zugang, sammeln alle Protokolle und Tools und informieren dann den Systemadministrator und verschiedene Organisationen, die sich mit Sicherheitsbefragen befassen. Auch wenn Sie glauben, alles richtig gemacht zu haben, so haben Sie doch mehr Schaden als Nutzen bereitet.

1. Der Hacker hat sehr wahrscheinlich verschiedene Protokolle und Überwachungsfunktionen durch eigene Versionen ersetzt. Er könnte feststellen, dass Sie da waren und, um seine Spuren zu verwischen, das System komplett löschen.
2. Der Systemadministrator wusste vielleicht von dem Hacker und hat bereits mit den Ermittlungsbehörden zusammengearbeitet. Sie haben also gerade die Ermittlungen schwer gestört oder unmöglich gemacht.
3. Sie könnten selbst für den Hack verantwortlich gemacht werden. Der Systemadministrator kennt Sie nicht und könnte Sie beschuldigen der echte Hacker zu sein, der, um sich selbst zu schützen, die Schuld auf jemand anderen schieben will.

Grundlegend gilt: es kann jede Menge schief und nur weniges glatt gehen, wenn man auf eigene Faust handelt. Das beste was man tun kann ist zuerst soviel Informationen wie möglich zu sammeln. Suchen Sie alle Protokolldateien, die Einträge über Einbruchsversuche von dieser Quelladresse enthalten. Identifizieren Sie dann die Person und/oder die Organisation die für den Zwischenfall verantwortlich ist. Die whois-Datenbank, dig und nslookup sind exzellente Werkzeuge um herauszufinden, wer für das System verantwortlich ist. Schicken Sie den Verantwortlichen e-mails mit Details darüber, was wann passiert ist, inklusive der Protokolldateien als Beweis. Vielleicht möchten Sie auch den vorgeschalteten Internetprovider dieser Organisation in Kopie setzen, damit auch er auf dem aktuellen Stand ist. Wenn die Einbruchsersuche zu ernst werden, setzen Sie sich mit professionellen Organisationen wie CERT (http://www.cert.org) oder CIAC (http://www.ciac.org) in Verbindung. Gehen die Einbruchsversuche weiter und der Systemadministrator regiert nicht, rufen Sie direkt in der Firma an. Das Telefon kann ein sehr mächtiges Werkzeug sein.

Schlussfolgerung

Früher oder später werden ihre Systeme und Netzwerke auf verschiedene Schwachstellen untersucht werden. Indem Sie einige der hier vorgestellten grundlegenden Maßnahmen ergreifen, sind Sie besser darauf vorbereitet, diese Vorfälle zu bemerken und zu protokollieren. Einmal identifiziert kann man diese Versuche verfolgen und sich so ein besseres Bild über die Bedrohungen für das Netzwerk machen und auch auf diese Bedrohungen reagieren. Nachdem man sie identifiziert hat, ist es das Beste, soviele Informationen wie möglich zu sammeln und dann die Person und/oder Firma zu benachrichtigen, denen das System gehört. Auf eigene Faust zu handeln geht oft daneben und verursacht mehr Schaden als Nutzen. Durch Zusammenarbeit mit anderen kommt man zu einer besseren Lösung.

Anhang 1:

Subject: ### Intrusion Detection Alert ###
You have received this alert because the network
is potentially being scanned. The information below
is the packet that was logged and dropped.
Date: Sat Jan 24
Time: 18:47:46
Source: ICARUS.CC.UIC.EDU
Destination: lisa
Service: imap
--- Finger Results ---
[ICARUS.CC.UIC.EDU]
Login Name TTY Idle When Where
Spitzner Lance Everett Spitzn pts/72 Sun 18:42 lspitz-4.soho.entera


Anhang 2:

#!/bin/ksh
#
# Script launched by tcpd for intrusion detection purposes
#
USER=lance@honeynet.org
SRV=`echo $1 | cut -f1 -d.`
DATE=`date "+%a %b %e"`
TIME=`date "+%T"`
FINGER=`/usr/local/bin/safe_finger @$2`
MAIL=/usr/bin/mail
$MAIL $USER < Subject: ### Intrusion Detection Alert ###
You have received this alert because the network
is potentially being scanned. The information below
is the packet that was logged and dropped.
Date: $DATE
Time: $TIME
Source: $2
Destination: $3
Service: $SRV
--- Finger Results ---
$FINGER
EOF
##### If the service is imap, lets go ahead and snoop the session.
if [ $SRV=imap ]; then
snoop -v -c 5000 -o /var/adm/$2_snoop.$$ $2 &
fi

Anm. d. Übers.

Ich bin kein professioneller Übersetzer, deswegen ist es sehr wahrscheinlich, das man vieles besser hätte formulieren können. Trotzdem hoffe ich, dass sich nirgendwo grobe Sinnentstellungen oder gar Fehler eingeschlichen haben. Wenn doch, oder auch bei sonstiger Kritik oder gar Lob, kurze e-mail reicht und dann wird korrigiert.
Der Originalartikel ist hier zu finden: http://www.enteract.com/~lspitz/ids.html



[back to top]



Userdaten
User nicht eingeloggt

Gesamtranking
Werbung
Datenbankstand
Autoren:04508
Artikel:00815
Glossar:04116
News:13565
Userbeiträge:16552
Queueeinträge:06243
News Umfrage
Ihre Anforderungen an ein Online-Zeiterfassungs-Produkt?
Mobile Nutzung möglich (Ipone, Android)
Externe API Schnittstelle/Plugins dritter
Zeiterfassung meiner Mitarbeiter
Exportieren in CSV/XLS
Siehe Kommentar



[Results] | [Archiv] Votes: 1144
Comments: 0