Snort Ausarbeitung

Snort
Vortrag im Fach
Anwendung Rechnernetze
Jan-Peter Hashagen
Wintersemester 2007/08
Hochschule Merseburg
1
Inhaltsverzeichnis
Einführung in Intrusion Detection Systeme.........................................................................................3
Arten von IDS.......................................................................................................................................4
Netzwerkbasierte IDS......................................................................................................................4
Hostbasierte IDS..............................................................................................................................5
Verteilte IDS....................................................................................................................................6
Weitere IDS-Arten...........................................................................................................................6
Funktionsweise von IDS.......................................................................................................................7
Probleme von IDS................................................................................................................................7
False positives..................................................................................................................................8
False negatives.................................................................................................................................8
Paketmodifikationen........................................................................................................................8
Insertion Attacks..............................................................................................................................8
Evasion Attacks..............................................................................................................................10
Ressourcenüberlastung..................................................................................................................10
Warum sind IDS wichtig?...................................................................................................................11
Snort...................................................................................................................................................12
Beispiele für Bedrohungen............................................................................................................12
Wurm.........................................................................................................................................12
Server Exploit...........................................................................................................................12
Snort Architektur............................................................................................................................13
Sniffer............................................................................................................................................14
Präprozessoren...............................................................................................................................14
Erkennung......................................................................................................................................15
Regeln............................................................................................................................................16
Alarme...........................................................................................................................................19
Barnyard.........................................................................................................................................20
Neu in Snort 2.8.............................................................................................................................20
Portlisten...................................................................................................................................20
IPv6...........................................................................................................................................21
Quellen...............................................................................................................................................21
2
Einführung in Intrusion Detection Systeme
Ein Intrusion Detection System (frei übersetzt: Einbruchserkennungssystem) dient der Erkennung
nichtautorisierter Zugangsversuche oder Angriffe auf ein System oder Netzwerk. Das Prinzip von
IDS ist dabei nicht neu. Die Funktionsweise von Autoalarmanlagen, Videoüberwachungen oder der
Analyse von Protokollen ist der von IDS sehr ähnlich.
Intrusion Detection Systeme benachrichtigen den Administrator über Angriffe. In eingeschränktem
Maß ist auch eine Vereitelung laufender Angriffe möglich. IDS sind hierauf jedoch nicht
spezialisiert, und die diesbezüglichen Möglichkeiten werden in diesem Dokument auch nicht näher
beschrieben.
Von IDS lässt sich eine Analogie zu Anti-Viren Software ziehen. Ein IDS macht im Netzwerk das, was
die Anti-Viren Software auf der Festplatte tut. Sie inspiziert den Traffic, sucht nach Angriffen und
versucht diese abzuwehren.
Intrusion Detection Systeme können sowohl rein softwarebasiert sein als auch als Kombinationen
aus Hardware und Software in Form vorinstallierter und vorkonfigurierter Stand-Alone IDS Geräte
existieren. Die IDS Software kann problemlos auf Rechnern gemeinsam mit anderen Diensten
laufen, aber separate IDS Sensoren und Manager sind die beliebtere Variante.
Mittels IDS lässt sich sehr gut die Einhaltung von Firmen-Sicherheitsrichtlinien überwachen.
Beispielsweise könnte leicht festgestellt werden, ob Mitarbeiter unerwünschte Chat-Programme
oder Filesharing-Dienste nutzen.
Als ein sehr wichtiger Aspekt ist festzuhalten, dass ein Intrusion Detection System nur ein Baustein
im Sicherheitskonzept eines Netzwerkes ist. Weitere Elemente wie Firewalls, Anti-Viren Software,
Proxys und ähnliches mehr sind elementare Bestandteile und keinesfalls zu vernachlässigen.
3
Arten von IDS
Intrusion Detection Systeme werden nach der Art der überwachten Aktivitäten, des Traffics oder
der Systeme unterschieden.
Netzwerkbasierte IDS
Abbildung 1: Netzwerkbasierte IDS
Netzwerkbasierte Intrusion Detection Systeme überwachen Teilnetze und Backbones und suchen
dort nach Angriffssignaturen.
4
Hostbasierte IDS
Abbildung 2: Hostbasierte IDS
Hostbasierte Intrusion Detection Systeme laufen auf einzelnen Hosts und überwachen das
Betriebs- und das Dateisystem auf Zeichen für Eindringlinge.
5
Verteilte IDS
Abbildung 3: Verteiltes IDS
Verteilte Intrusion Detection Systeme sind Gruppen von IDS, die als entfernte Sensoren fungieren
und ihre Daten an eine zentrale Managementstation schicken.
Weitere IDS-Arten
Gateway IDS
Ein Gateway IDS ist ein netzwerkbasiertes IDS, das am Gateway zwischen dem eigenen und einem
anderen Netzwerk eingesetzt wird. Es überwacht den Traffic in und aus dem Netzwerk am
Übergangspunkt.
Anwendungs-IDS
Anwendungs-IDS sind auf das Verstehen und Parsen von anwendungsspezifischem Traffic
6
fokussiert. Sie berücksichtigen dabei den Fluss der Anwendungslogik und der darunter liegenden
Protokolle.
In der Praxis werden meist Kombinationen aus netzwerk- und hostbasierten IDS eingesetzt. Die
signaturbasierte Erkennung von Angriffen arbeitet in der Kombination sehr effektiv.
Funktionsweise von IDS
IDS können nach der Art der überwachten Informationen unterschieden werden. Diese können
●
netzwerkspezifisch
●
hostspezifisch oder
●
anwendungsspezifisch
sein. Bei netzwerkspezifischen Informationen handelt es sich um den Inhalt der Pakete oder um
Hosts, die als Angreifer bekannt sind. Hostspezifische Informationen beziehen sich auf verwendete
Systemaufrufe, den Inhalt lokaler Protokolldateien und Dateisystemberechtigungen.
Anwendungsspezifische Informationen meinen den korrekten Fluss der Anwendungsdaten.
IDS werden ebenfalls nach der Art der Ereignisanalyse unterschieden:
●
Signaturerkennung
●
Anomalieerkennung
Die Signaturerkennung entspricht der Technik von Anti-Viren Software. Der Traffic wird mit
Aktivitätsmustern und Angriffssignaturen verglichen. Dies ist die verbreitetste Art der
Trafficbehandlung. Bei der Anomalieerkennung werden Heuristiken (Regeln oder vordefinierte
Konzepte) verwendet. Mittels dieser Heuristiken wird bestimmt, was das System unter „normaler“
und „unnormaler“ Aktivität versteht. Dadurch können Anomalien von normalem Systemverhalten
unterschieden, und es kann gegebenenfalls eingegriffen werden. Für die Bestimmung der
Heuristiken können Benutzerprofile verwendet werden. Die Benutzerprofile werden durch Analyse
des Traffics erstellt, etwa mittels statistischer Proben, regelbasierter Verfahren oder neuraler
Netzwerke.
Wird ein Angriff von einem IDS festgestellt, gibt es zwei Möglichkeiten der Reaktion:
●
Passive Reaktion
●
Aktive Reaktion
Die passive Reaktion beschränkt sich auf das Erzeugen von Alarmen und/oder Protokolleinträgen.
Bei der aktiven Reaktion versucht das IDS, aktiv in den Traffic einzugreifen. Dies kann durch das
Senden von TCP-Resetpaketen geschehen, mittels derer versucht wird, TCP-Verbindungen zu
unterbrechen. Problematisch dabei kann das Auftreten von Race Conditions sein, da nicht
garantiert werden kann, dass das Resetpaket den Zielrechner schneller erreicht als das Paket des
Angreifers. Weitere Möglichkeiten der aktiven Reaktion stellen das direkte Verwerfen von Traffic
(wenn das IDS inline betrieben wird) oder das Eintragen angreifender Hosts in Blocklisten dar.
Probleme von IDS
Probleme von IDS, auf die hier eingegangen werden soll, sind false positives, false negatives,
Paketmodifikationen sowie Insertion und Evasion Attacks.
7
False positives
Jedes IDS produziert false positives und false negatives. Unter einem false positve versteht man
das Auslösen eines Alarms bei normalem Traffic, wenn kein Einbruch oder Angriff erfolgt.
In der Standardkonfiguration produzieren die meisten IDS viele false positives. Um sie zu
reduzieren, muss das IDS an das Netz angepasst werden. Der Administrator muss dafür möglichst
genaue Kenntnis darüber haben, was im Netz passiert und was die Geräte tun sollten.
Zu false positives ist anzumerken, dass viele Hersteller und sogar manche erfahrene
Sicherheitsexperten behaupten, dass auch Ereignisse false positives seien, die dem Administrator
egal sind. Das ist falsch! Tatsächlich handelt es sich um echte positives, die lediglich in der
konkreten Umgebung oder zum aktuellen Zeitpunkt unwichtig sind.
False negatives
Unter einem false negative versteht man das Gegenteil eines false positives, nämlich das
Nichtauslösen eines Alarms, wenn ein Angriff stattfindet. Dies wird als viel schlimmer als ein false
positive angesehen, und man ist bestrebt, false negatives unbedingt zu vermeiden.
Paketmodifikationen
Die Sicherheitsexperten Tim Newsham und Tom Ptacek machten der Sicherheitscommunity einige
Defizite von IDS bekannt.
Durch kreative Fragmentierung von Paketen oder das Schreiben mit Überlappungen, die anders
wieder zusammengesetzt würden, als man dies aufgrund der individuellen Fragmente vermutete,
war es möglich, Angriffe direkt unter der Nase der meisten IDS durchzuführen.
Als Gegenmaßnahme wurden Präprozessoren entwickelt, die den Datenstrom genauer verstehen,
sowie Werkzeuge zur Wiederzusammensetzung von Fragmenten.
Insertion Attacks
Unter einer Insertion Attack versteht man das Einfügen nicht gültiger Pakete in die Leitung.
Ungültig kann hierbei bedeuten, dass das Paket vom Zielrechner verworfen wird, weil es
●
eine ungültige Struktur besitzt oder
●
den Zielrechner gar nicht erreicht.
Liest das IDS das ungültige Paket, kann es die Bedeutung des restlichen Traffics gegebenenfalls
nicht mehr erkennen. Dieser Zustand ist in Abbildung 4 dargestellt:
8
Abbildung 4: Erfolgreiche Insertion Attack
Ein Beispiel für eine Insertion Attack wird im Folgenden am im Februar 1996 bekannt gewordenen
phf.cgi Angriff gezeigt. Durch Anhängen des Newline-Characters an die GET-Anfrage lassen sich
beliebige Befehle auf dem angegriffenen Rechner ausführen. Das Auslesen der UNIX-Passwortdatei
würde etwa so funktionieren:
GET /cgi-bin/phf?\n/bin/cat\n/etc/passwd
Um einen solchen Angriff zu erkennen, führen IDS in GET-Anfragen eine Substring-Suche nach der
Zeichenfolge „phf“ durch. Eine erfolgreiche Insertion Attack lässt diese Suche ins Leere laufen,
indem die GET-Anfrage durch den Angreifer so modifiziert wird, dass die Zeichenfolge „phf“ nicht
mehr vorhanden ist:
GET /cgi-bin/phunhackf?\n/bin/cat\n/etc/passwd
Aus „phf“ wurde „phunhackf“. Nun muss der Angreifer nur noch dafür sorgen, dass der Zielrechner
die GET-Anfrage mit „phf“ erhält, während das IDS die harmlose, modifizierte GET-Anfrage
untersucht. Dies lässt sich durch beabsichtigtes Verfälschen der IP Checksumme des modifizierten
Pakets erreichen. Der Zielrechner wird dieses Paket verwerfen. Das IDS kann, abhängig von seiner
Konfiguration, dennoch einen Blick in das Paket werfen und so erfolgreich in die Irre geführt
werden.
Insertion Attacks funktionieren immer dann, wenn das IDS mehr Pakete akzeptiert als das
beschützte System. Daraus kann die Folgerung gezogen werden, dass IDS so strikt wie möglich bei
der Annahme von Paketen sein sollten. Damit kann man sich jedoch ein schwerwiegenderes
Problem einhandeln, die Evasion Attack.
9
Evasion Attacks
Bei der Evasion Attack verwirft das IDS ein Paket, das vom Zielrechner angenommen wird.
Abbildung 5: Evasion Attack
Ein Beispiel für eine Evasion Attack ist das Beginnen einer TCP-Verbindung mit Daten, etwa eine
GET-Anfrage, im Handshake-Paket. Der TCP/IP-Standard sieht dies zwar nicht vor, verbietet es aber
nicht. Wertet der Zielrechner die Daten aus, das IDS dagegen nicht, ist der Angreifer dem IDS
erfolgreich „ausgewichen“.
Ressourcenüberlastung
Eine weitere Angriffsart auf IDS stellt das Überlasten der Systemressourcen
●
CPU,
●
Arbeitsspeicher,
●
Festplattenkapazität und
●
Netzwerkbandbreite
dar. Die CPU ist mit dem Lesen von Paketen, der Bestimmung ihrer Art und Zuordnung zu einem
bestimmten, gespeicherten Netzwerkstatus beschäftigt. Ein IP Fragment muss etwa den anderen
Fragmenten zugeordnet werden, die zum entsprechenden Datagramm gehören. Im
Arbeitsspeicher erfolgt die Speicherung des TCP-Verbindungsstatus, die Verwaltung von Speichern
zur Zusammensetzung von Fragmenten sowie die Verwaltung von Datenpuffern zur Überprüfung
auf bekannte Muster. Ein Angreifer versucht möglichst viele, bedeutungslose Pakete zu senden,
damit das überlastete IDS die tatsächlich gefährlichen Pakete verpasst.
Auf der Festplatte des IDS werden Aktivitätsprotokolle gespeichert. Jedes Ereignis verbraucht
Speicherplatz. Da nur endlich viel Speicher vorhanden ist, versucht der Angreifer auch hier wieder,
mittels einer Flut bedeutungsloser Ereignisse die Festplatte zu füllen, damit sein Angriff unbemerkt
erfolgen kann.
IDS verfolgen die Aktivität in den überwachten Netzwerken, die allerdings nur sehr selten voll
ausgelastet sind. Wenige Überwachungssysteme können ein stark ausgelastetes Netz zuverlässig
überwachen, da das IDS im Gegensatz zu den Zielrechnern alle Pakete lesen muss. Der Angreifer
10
versucht nun, die Netzwerkbandbreite zu überlasten, indem er den Durchsatz soweit wie möglich
durch das Senden bedeutungsloser Informationen erhöht. Damit wird eine korrekte Analyse des
Traffics verhindert, da am IDS nur noch ein Teil der Pakete ankommt.
Warum sind IDS wichtig?
Jeder kennt das geflügelte Wort „Was ich nicht weiß, macht mich nicht heiß“, doch jeder, der schon
mal ein gebrauchtes Auto gekauft hat, weiß, wie absurd diese Aussage sein kann.
Es ist von größter Wichtigkeit, Kenntnis über laufende Angriffe zu haben. Werden die Systeme
gerade untersucht? Läuft ein Einbruchsversuch? Gibt es andere böswillige Aktivitäten? Das zu
wissen, kann den Unterschied zwischen einer erfolgreichen und einer fehlgeschlagenen
Kompromittierung ausmachen.
Genauso wichtig ist es, Detailinformationen über frühere Angriffe zu haben, um eine
größtmögliche Genauigkeit bei der Analyse zu gewährleisten. Es muss exakt festgestellt werden
können, welche Systeme und Daten kompromittiert wurden.
In manchen US-Bundesstaaten wie Washington und Kalifornien gibt es eine Veröffentlichungspflicht für Unternehmen. Datendiebstähle und Kompromittierungen müssen den betroffenen
Kunden gemeldet werden. Die Unternehmen sind natürlich bestrebt, dies zu vermeiden, da solche
Meldungen zu schlechter Presse, zu Verlust an Kundenvertrauen und eventuell zu fallenden
Aktienkursen führen.
Botnets sind ein Thema, da Hacker versuchen, die Kontrolle über möglichst viele Einzelrechner zu
erlangen. Dabei ist es ihnen egal, ob es sich um Computer von Privatpersonen oder um
Workstations in Unternehmen handelt. Ein von Hackern ferngesteuerter Rechner wird als Zombie
bezeichnet. Botnets werden von Hackern gerne für verteilte Denial-of-service (DDoS) Angriffe
benutzt, wobei Tausende oder Hunderttausende von Zombies einen oder wenige Server angreifen,
um sie lahmzulegen. Im Februar 2000 gab es einen solchen Angriff auf zahlreiche große Webseiten
wie eBay, Amazon.com, AOL Time Warner, CNN, Dell, Excite und Yahoo. Mitte 2004 gab es einen
weiteren großen Angriff auf das DNS System des Providers Akamai, wodurch sehr gut
angebundene Seiten wie Microsoft, Google und Yahoo nicht mehr erreichbar waren.
Natürlich ist jedes Unternehmen bestrebt, dass das eigene Netz nicht Teil solcher Angriffe ist. Aus
dem Ausmaß der Angriffe lässt sich die Lehre ziehen, dass kein Netz klein genug ist, um
ungeschützt zu bleiben. Wenn ein Hacker einen fremden Computer benutzen kann, wird er es tun.
Botnets bergen nicht nur die Gefahr der Teilnahme an DDoS-Angriffen. Es ist ebenfalls gängige
Praxis, dass Zombies für den Versand von Spammails missbraucht werden. Bei Privatcomputern
mag dies noch kein so schwerwiegendes Problem sein. Gehen aber über die Maildomain eines
Unternehmens Millionen von Spammails raus, droht dieser Domain schnell ein Blacklisting durch
große Provider. Das führt dazu, dass Mails des Unternehmens von diesen Servern nicht mehr
angenommen werden, was sich als sehr geschäftsschädigend erweisen kann.
Gerne werden gehackte Computer auch als Warez-Server missbraucht. Auf dem gehackten
Rechner wird etwa ein FTP-Server installiert und darüber dann alle erdenklichen illegalen Daten
ausgetauscht, von Programmen über Filme, Musik, Pornographie und ähnliches mehr. Unter
Umständen kann es einem Unternehmen also passieren, dass es eine Klage wegen CopyrightVerletzungen erhält, ohne überhaupt gewusst zu haben, dass die fraglichen Daten über
Workstations im Unternehmen liefen.
11
Als weiterer Punkt ist die Industriespionage zu nennen, denn ein gehackter Rechner eröffnet
natürlich auch die Möglichkeit, beliebige Daten zu stehlen.
Snort
Snort ist ein Open Source Netzwerk-IDS, das erstmals Ende 1998 verfügbar war, damals noch mit
sehr rudimentärer Funktionalität. Ende 1999 wurde Version 1.5 freigegeben, die bereits
Unterstützung für Plug-Ins enthielt.
Snort ist mehr als ein netzwerkbasiertes IDS. Es kann auch als Sniffer und Packet logger eingesetzt
werden. Dies sind die Kernfunktionalitäten von Snort. Im Wesentlichen funktioniert Snort wie ein
großer Staubsauger, der alle Objekte eines bestimmten Typs, in diesem Fall Pakete, aufsaugt und
zur Weiterverarbeitung bereitstellt.
Snort steht für eine Vielzahl verschiedener Plattformen zur Verfügung, darunter Linux,
verschiedene BSD-Varianten, Solaris, Mac OS X, HP-Unix, IRIX und Windows.
Snort arbeitet mit signaturbasierter Erkennung. Es werden Regeln verwendet, um gefährliche
Pakete im Netzwerk zu finden. Beispielsweise fahndet Snort nach Peer-to-peer File-Sharing
Diensten, indem nach GET-Anfragen auf anderen Ports als Port 80 gesucht wird.
Beispiele für Bedrohungen
Im Folgenden werden zwei typische Bedrohungen gezeigt, mit denen IDS umgehen müssen und
wie Snort darauf reagiert.
Wurm
Der Dabber Wurm zielt auf Rechner ab, die bereits mit dem äußerst schädlichen Sasser Wurm
infiziert sind.
Sasser nutzt einen Fehler im Local Security Authority Subsystem Service (LSASS) von Windows.
Findet er einen verwundbaren Rechner, infiziert er ihn mit einem Code, der den eigentlichen
Wurm von bereits infizierten Rechnern kopiert. Dazu startet er auf Port 5554 einen FTP-Server. Der
befallene Rechner wird von dem Wurm in unregelmäßigen Abständen ein- und ausgeschaltet.
Dadurch entstehen massive Produktivitätsverluste in Unternehmen bzw. Mängel in der
Erreichbarkeit und Nutzbarkeit von Internetseiten durch die Kunden.
Die entsprechende Snort Regel sucht nach TCP-Paketen, die an Rechner im internen Netz auf Port
5554 adressiert sind und das Wort „PORT“ im Nutzdatenteil enthalten. Bei einem Treffer wird die
Meldung „COMMUNITY VIRUS Dabber PORT overflow attempt port 5554“ ausgegeben.
alert tcp $EXTERNAL_NET any -> $HOME_NET 5554
(msg:"COMMUNITY VIRUS Dabber PORT overflow attempt port 5554";
flow:to_server,established,no_stream;
content:"PORT"; nocase; isdataat:100,relative;
pcre:"/^PORT\s[^\n]{100}/smi"; reference:MCAFEE,125300;
classtype:attemptedadmin; sid:100000110; rev:1;)
Server Exploit
Der Oracle TNS Listener ist ein zentraler Dienst für Oracle Datenbanken. Standardmäßig ist dieser
Dienst nicht passwortgeschützt. Anfang 2005 wurde bekannt, dass iSQL Plus (ein Webinterface für
SQL Plus) dazu missbraucht werden kann, den TNS Listener abzuschalten. Im Juli 2005 stellte
12
Oracle hierfür einen Bugfix bereit. Aufgrund der hohen Uptime Anforderungen kommerzieller
Datenbanken sind immer noch (Stand: 02/2007) viele ungepatchte Server in Betrieb. Es klingt
verrückt, dass die kritischsten Server für den Betrieb des Unternehmens als „zu wichtig zum
Patchen“ angesehen werden. Manche Administratoren denken aber tatsächlich so, andere wissen
nichts von der Lücke oder verstehen nicht die Wichtigkeit schneller und regelmäßiger Updates.
Ein IDS kann diese Lücke schließen. Wenn der Datenbanklistener allzu häufig abstürzt, könnte ein
Blick in die IDS Alarmprotokolle nützlich sein.
Die entsprechende Snort Regel sucht nach TCP-Paketen, die an SQL Server auf Port 3339 adressiert
sind und die Worte „isqlplus“, „COMMAND“, „STOP“, und „LISTENER“ im Nutzdatenteil enthalten.
Bei einem Treffer wird die Meldung „COMMUNITY ORACLE TNS Listener shutdown via iSQLPlus
attempt“ ausgegeben.
alert tcp $EXTERNAL_NET any -> $SQL_SERVERS 3339
(msg:"COMMUNITY ORACLE TNS Listener shutdown via iSQLPlus attempt";
flow:to_server,established;
content:"isqlplus"; nocase;
content:"COMMAND"; nocase; distance:0;
content:"STOP"; nocase; distance:0;
content:"LISTENER"; nocase; distance:0;
pcre:"/isqlplus\x2F[^\r\n]*COMMAND\s*\x3D\s*STOP[^\r\n\x26]*LISTENER/si";
reference:bugtraq,15032; reference:url,www.red-databasesecurity.
com/advisory/oracle_isqlplus_shutdown.html; classtype:attempteduser;
sid:100000166; rev:1;)
Snort Architektur
Snort besteht aus den Komponenten
●
Sniffer,
●
Präprozessor,
●
Erkennung und
●
Alarmmodul.
Zusätzlich werden die Ereignisse in Dateien oder Datenbanken protokolliert.
Abbildung 6: Snort Architektur
13
Der Sniffer sammelt alle Pakete vom Netzwerkbackbone auf. Dann schickt er die Pakete durch den
Präprozessor, um festzustellen, um was für Pakete es sich genau handelt. Die Pakete werden nach
ihrem Typ sortiert und in der Erkennungsengine mittels der Regelsätze untersucht. Abschließend
erfolgt abhängig von den Wünschen des Administrators eine Protokollierung und Speicherung in
einer Datenbank.
Nur noch der Sniffer ist Teil des Snort-Kerncodes. Der Präprozessor, die Erkennungsengine und das
Alarmmodul wurden zu Plug-Ins verändert.
Sniffer
Ein Sniffer ist ein Gerät (Hardware oder Software), das zum Abhören von Netzwerken benutzt wird.
Im Internet ist dies meistens IP Traffic, aber in LANs können auch andere Protokolle wie IPX und
AppleTalk vorkommen.
Da der IP Traffic aus vielen verschiedenen übergeordneten Protokollen besteht (TCP, UDP, ICMP,
Routingprotokolle, IPSec), analysieren Sniffer die verschiedenen Netzwerkprotokolle, um die
Pakete in menschenlesbare Form zu bringen.
Sniffer werden eingesetzt für
●
Netzwerkanalyse und Problembehebung,
●
Leistungsanalyse und Benchmarks,
●
Auslesen von Klartext-Passworten und andere interessanten Daten.
Abbildung 7: Sniffer
Der Sniffer empfängt die Pakete über ein promiscous interface. Die IDS Management Funktionen
laufen aus Sicherheitsgründen über eine andere Netzwerkschnittstelle.
Präprozessoren
Ein Präprozessor nimmt die Rohdaten und prüft sie mittels spezieller Plug-Ins (RPC, HTTP, Port
Scanner, Fragmentierung). Diese Plug-Ins prüfen die Pakete auf einen bestimmten Verhaltenstyp
genauer, als dies mit Regeln möglich wäre. Wenn der Typ bestimmt wurde, werden die Pakete an
die Erkennungsengine weitergeleitet.
14
Abbildung 8: Präprozessor
Präprozessoren sind äußerst nützlich, da die Plug-Ins nach Belieben aktiviert
oder deaktiviert werden können. Damit lässt sich die Genauigkeit der Analyse
exakt steuern.
Ein Beispiel: Wir erhalten in unserem Netz eine Menge Portscans, die sich aber
nicht als relevante Bedrohung erweisen. Daher entscheiden wir uns dafür, dass
wir keine Portscan-Alarme mehr vom IDS erhalten möchten. Um dies zu
erreichen, muss lediglich der Portscan-Präprozessor deaktiviert werden.
Bevor die Präprozessoren den Traffic erhalten, muss er durch die
Protokolldecoder. Die Präprozessoren zur Defragmentierung setzen
fragmentierte Pakete neu zusammen, unabhängig davon, ob die
Fragmentierung böswillig oder durch natürliche Vorgänge im Netzwerk erfolgte.
Der stream4 Präprozessor überprüft, ob die Pakete Teil einer aufgebauten
Sitzung sind oder nicht. Der stream4_reassemble Präprozessor setzt TCPStreams zu einem „Pseudo-Paket“ zusammen, um sie im Kontext analysieren zu
können. Die Präprozessoren der Anwendungsebene bestehen aus einer
Sammlung von Präprozessoren (die ständig mehr werden), die komplexe
Protokolle normalisieren können. Es werden gegebenenfalls Ereignisse erzeugt,
wenn die Protokolle fehlerhaft implementiert sind oder ein versuchter
Missbrauch des Protokolls festgestellt wird.
Wenn die Präprozessoren ihre Arbeit beendet haben, werden die Pakete an die Erkennungsengine
weitergeleitet.
Erkennung
Die Erkennungsengine ist der wichtigste Teil der signaturbasierten Intrusion Detection von Snort.
Die Daten werden vom Präprozessor entgegengenommen und gegen einen Satz von Regeln
15
geprüft. Wenn die Regeln mit Daten in den Paketen übereinstimmen, werden sie an das
Alarmmodul weitergeleitet
Abbildung 9: Erkennung
Regeln
Eine Snort Regel besteht aus dem Header und Optionen. Der Header besteht aus
●
Aktion
●
Protokoll
●
IP/Port
Die Optionen bestehen aus
●
Meldung
●
Fluß
●
Inhalt
●
Metadaten
16
Mögliche Werte für Aktion sind:
Aktion
Beschreibung
alert
Alarm erzeugen
pass
Paket durchlassen
drop
Paket verwerfen
reject
Paket ablehnen
sdrop
Paket verwerfen ohne Meldung
Die Werte drop, reject und sdrop stehen nur zur Verfügung, wenn das IDS inline betrieben wird.
Inline bedeutet, dass der gesamte Traffic in beiden Richtungen durch das IDS hindurchgeschleust
wird.
Als Protokoll sind tcp, udp, icmp oder ip (als Obermenge der anderen drei) die gängigsten Werte.
Hier lässt sich aber auch jedes andere Ethernet-Protokoll angeben.
Hinter dem Protokoll folgen IP-Adresse und Port des Quellrechners, dahinter die des Zielrechners.
Hier können Werte sowohl als Klartext als auch in Form vordefinierter Variablen, wie etwa
$SQL_SERVERS, verwendet werden. Ebenfalls ist es hier möglich, IP- und Port-Ranges anzugeben.
Der erste Wert in den Optionen, die Meldung, stellt lediglich eine Klartext-Meldung für das
Protokoll dar. Hier soll möglichst kurz und eindeutig beschrieben sein, was die Regel macht.
Der Fluß gibt die Richtung an, in die das Paket fließt. Mögliche Werte sind hier
●
to_server
●
from_server
●
to_client
●
from_client
●
established
●
stateless
Bei der Angabe von established werden nur Pakete untersucht, die zu Streams gehören, die mit
einem vollständigen 3-Wege Handshake begonnen haben. Die Angabe stateless untersucht
dagegen einzelne Pakete ohne Zugehörigkeit.
Im Inhalt wird als Klartext angegeben, wonach Snort im Nutzdatenteil suchen soll. Alternativ ist die
Verwendung von Hexcode möglich, der von Pipe-Symbolen umschlossen sein muss. Zusätzlich
können verschiedene Optionen angegeben werden:
Option
Beschreibung
depth
Suchtiefe (bis zu welchem Byte)
offset
Suche ab Byte x
within
Finde x innerhalb der nächsten y Bytes nach z
distance
Nächster Treffer mindestens x Bytes nach y
Die Inhaltsoption pcre erlaubt die Untersuchung des Inhalts mittels Perl-kompatibler regulärer
Ausdrücke.
17
In den Metadaten stehen die folgenden Angaben:
●
Referenz
●
Classtype
●
Security ID
●
Revision
Die Referenz verweist auf Informationen über die Art des Exploits oder Fehlers, den die Regel
überwacht. Hier kann auch eine URL mit weiterführenden Informationen angegeben werden. Der
Classtype erlaubt eine Einstufung der Wichtigkeit der Regel, ob es sich etwa um unbedeutenden
Chat Traffic, Portscans oder schwerwiegende Server Exploits handelt. Die Security ID (sid) weist der
Regel einen eindeutigen Wert zu. Dieser ist für die Arbeit mit Datenbanken unabdingbar. Die
Revision (rev) gibt die Version der Regel an.
18
Alarme
Abbildung 10: Alarmmodul
Nachdem die Behandlung durch die Regeln beendet ist, muss das Ergebnis der Prüfung irgendwo
ausgegeben oder gespeichert werden. Trifft eine Regel auf ein Datenpaket zu, wird ein Alarm
ausgelöst. Alarme können in eine Protokolldatei geschrieben oder über eine Netzwerkverbindung
oder durch UNIX Sockets an den Windows Nachrichtendienst oder an SNMP Traps gesendet
werden. Die Alarme können auch in SQL Datenbanken wie MySQL und PostgreSQL gespeichert
werden.
Dafür verwendet die Alarmkomponente eine Vielzahl verschiedener Plug-Ins. Ein paar Beispiele:
Plug-In
Beschreibung
SnortSnarf
Snort Analyzer mit HTML Ausgabe
Snortplot
Perl Skript für graphische Darstellung der Angriffe
Swatch
Echtzeit Syslog-Überwachung mit Unterstützung für E-Mail Benachrichtigung
ACID
Analysekonsole für Intrusiondatenbanken
BASE
ACID-Nachfolger; empfohlen für Abfrage und Analyse von Snort Alarmen
19
Barnyard
Snort war ursprünglich nicht für viele der heutigen Aufgaben konzipiert wie Erkennung von
Portscans, Zusammensetzen von TCP-Datenströmen, HTTP URI Normalisierung und Protokollierung
in Datenbanken. Viele der Ausgabe Plug-Ins waren zu langsam, weil die Netze zu schnell oder die
Plug-Ins zu anspruchsvoll waren. Das war problematisch, da der Sniffer solange blockiert war, bis
das Ausgabe Plug-In seine Arbeit beendet hatte.
Daher war man bestrebt, die Ausgabe von der Überwachung zu trennen und eine asynchrone
Ereignisverarbeitung zu ermöglichen. Das hat zudem den Vorteil, dass die Ausgabe ohne RootRechte laufen kann, da nur der Sniffer direkten Zugriff auf das promiscous interface benötigt.
Aus diesen Überlegungen heraus entstanden die Snort Unified Files. Sie gewährleisten eine
einheitliche Abspeicherung der wichtigen Informationen:
●
Alarme
●
Protokolle
●
Stream-stat
Die Alarmdateien enthalten alle essentiellen Informationen über einen Snort Alarm, aber nicht
mehr. Dadurch werden sie äußert klein, nämlich gerade 56 Byte.
Die Protokolldateien enthalten alle Informationen über die Regel, die zum Ereignis führte.
Weiterhin enthalten sie das komplette Paket.
Die Stream-stat Dateien werden nicht aufgrund von Alarmen erzeugt. Der stream4 Präprozessor
schreibt Informationen über jede beobachtete TCP-Sitzung in eine Stream-stat Datei. Diese Dateien
werden bislang jedoch noch von keinen Ausgabe Plug-Ins verwendet.
Neu in Snort 2.8
Die wichtigsten Neuerungen in Snort 2.8 sind Portlisten sowie Unterstützung für IPv6.
Portlisten
Beispiele für die Angabe von Portvariablen in der Snort-Konfigurationsdatei:
Beispiel
Beschreibung
portvar EXAMPLE1 80
Port 80
var EXAMPLE2_PORT [80:90]
Ports 80 bis 90 inklusive
var PORT_EXAMPLE2 [1]
Port 1
portvar EXAMPLE3 any
jeder beliebige Port
portvar EXAMPLE4 [!70:90]
alle Ports außer 70 bis 90 inklusive
portvar EXAMPLE5 [80,91:95,100:200]
Ports 80, 91 bis 95 inklusive sowie 100 bis 200
inklusive
Die Verwendung von „var“ wird in Zukunft veraltet sein. Wird sie benutzt, muss der Variablenname
mit PORT_ beginnen oder mit _PORT enden. Die Portlisten-Neuerung ist in EXAMPLE5 dargestellt.
20
IPv6
Ein Beispiel für die Verwendung von IPv6 Adressen:
alert ip\
fe80::20c:29ff:fe00:c6c2 any -> fe80::20c:29ff:fe60:232a any\
(msg:"LOCAL IPv6 Link Local test"; sid:2000001;)
Quellen
Snort – IDS and IPS Toolkit (Beale, Baker, Esler)
http://www.snort.org/docs/idspaper/ (11/2007)
http://searchsecurity.techtarget.com.au/topics/article.asp?DocID=1278254 (11/2007)
21