IDS - Intrusion Detection System, part II

ArticleCategory: [Choose a category, translators: do not translate this, see list below for available categories]

SystemAdministration

AuthorImage:[Here we need a little image from you]

[Photo of the Author]

TranslationInfo:[Author + translation history. mailto: or http://homepage]

original in de Klaus M�ller

AboutTheAuthor:[A small biography about the author]

Klaus M�ller a.k.a. 'Socma' ist momentan noch Sch�ler und besch�ftigt sich v.a. mit Linux Programmierung und sicherheitsrelevanten Themen.

Abstract:[Here you write a little summary]

W�hrend sich der erste Teil v.a. auf die typischen Angriffe gegen Intrusion Detection Systeme konzentrierte, wird dieser zweite Teil Methoden vorstellen, mit denen ihr diese Angriffe entdecken und wie ihr darauf reagieren k�nnt. Dazu z�hlen z.B. die Verwendung von Signaturen und Filtern. Abschlie�end wird noch Snort und LIDS vorgestellt.

ArticleIllustration:[One image that will end up at the top of the article]

[Illustration]

ArticleBody:[The main part of the article]

Analysem�glichkeiten

Es wurde bereits besprochen, gegen welche Attacken sich IDSs sch�tzen sollten und welche verschiedenen Systeme man unterscheidet. Jetzt aber zur Art und Weise der Analyse, also wie ein IDS bestimmt, ob ein Angriff vorlag oder nicht, bzw. ob der Angriff erfolgreich war oder nicht.

Grunds�tzlich unterscheidet man hier Misuse Detection und Anomaly Detection. Bei der Misuse Detection werden bestimmte Muster definiert, die einen Angriff als solchen enttarnen. Diese Muster werden auch Signaturen genannt, und werden in einem extra Teil noch intensiver besprochen. F�r jetzt reicht es zu wissen, dass man z.B. Signaturen definieren kann, die im Netzwerk-Verkehr nach bestimmten Strings suchen (z.B. /etc/passwd) und gegebenfalls die "Anfrage" nach dieser Datei verbieten und Alarm ausl�sen. Der Vorteil der Misuse Detection besteht darin, dass die Wahrscheinlichkeit von false alarms relativ gering ist, da man anhand von Signaturen recht genau einstellen kann, nach welchen Dingen gesucht werden soll.... Der Nachteil ist allerdings auch recht offensichtlich, denn neue Attacken werden nicht sehr h�ufig erkannt, da sie nicht definiert sind (siehe Kapitel �ber Signaturen). Die andere M�glichkeit stellt die sogenannte Anomaly Detection dar. Das bedeutet einfach nur, dass ein Profil von normalen Useraktivit�ten erzeugt wurde und wenn das Verhalten des Users zu sehr von diesem Profil abweicht, ein Alarm ausgel�st wird.

Erster Schritt bei dieser Analyse stellt also das Erstellen eines Profils (einer Datenbank) "normaler" Useraktivit�ten dar. Hierbei k�nnen die verschiedensten Dinge protokolliert werden : Wie oft f�hrt er bestimmte Kommandos aus ? Wann f�hrt er bestimmte Kommandos aus ? Wie oft �ffnet er bestimmte Dateien ? .... Hier ein kleines Beispiel : - User 'beispiel' f�hrt durchschnittlich 3 mal t�glich /bin/su aus (dieser Wert st�nde im Profil) Nun kommt der User 'beispiel' und f�hrt an einem Tag auf einmal 7 mal su aus, also mehr als doppelt so oft wie sonst. Anomaly Detection w�rde dieses "anormale" Verhalten enttarnen und den Admin warnen, dass User 'beispiel' pl�tzlich 7 mal su ausgef�hrt hat, dabei ist der protokollierte , "normale" Durchschnitt bei 3. Die Nachteile dieses Verfahrens wurde mir v.a. klar, als ich selber mit der Umsetzung (siehe Beispiele am Ende - COLOID) begann, denn die Methode, um eine Datenbank normaler Useraktivit�ten zu erzeugen, ist recht rechenintensiv. Beobachtet man z.B., wie oft der User 10 Dateien ge�ffnet hat, so m�sste bei jedem open() �berpr�ft werden, ob es sich um eine der 10 Dateien handelt, und falls ja der entsprechende Counter hochgez�hlt werden. Dennoch stellt es eine sehr gute M�glichkeit dar, auch neue Angriffstechniken aufzudecken, da diese wahrscheinlich als "anormal" gelten werden. Au�erdem kann der Admin schlie�lich auch selbst definieren, welche Abweichung als "anormal" gelten soll, z.B. eine Abweichung von 10% oder erst eine Abweichung von 75%.... Bei der Verwendung dieser Methode m�sst ihr allerdings aufpassen, dass die Erstellung des Userprofils in einem "sicheren" Netzwerk abl�uft, da sonst das Verhalten des Angreifers als normal gilt und das Verhalten des richtigen Users als anormal.

Allgemein umfasst die Anomaly Detection folgende Dinge:
Heuristische Schwellenwertanalyse heisst hier, dass der Counter (wie oft etwas ausgef�hrt werden darf) nicht von Anfang an statisch festgelegt wird, sondern dynamisch. F�hrt ein User normalerweise /bin/login 4 mal aus, so w�rde der Counter evtl. auf 5 gesetzt....
Eine Untergruppe der Anomaly Detection stellt die Protocol Anomaly Detection dar, eine relativ neue Technik, die vom Prinzip her genauso funktioniert wie die Anomaly Detection. Jedes Protokoll hat ein "vordefiniertes" Verhalten (siehe entsprechende) RFC's , Ziel der Protocol Anomaly Detection ist es, festzustellen, ob das Verhalten des Protokolls wie vordefiniert ist oder nicht. Es basieren mehr Angriffe auf Protocol Misuse als man vielleicht denken mag, daher ist diese Untergruppe durchaus wichtig f�r IDSs. Bei einem Blick zur�ck in den Teil �ber Scanning, lassen sich sicherlich einige
Ans�tze zur Protocol Anomaly Detection finden.
In den entsprechenden rfc's findet ihr die richtigen Spezifizierungen, auch welches Verhalten nicht eintreten sollte, bzw. welches Verhaltenn bei einem bestimmten Ereignis auftreten sollte. Desweiteren gibt es noch die Application Anomaly Detection (eigentlich kommt es Application Based IDSs nahe ). In einigen Texten las ich Ans�tze in diese Richtung, so dass ich mich auch damit besch�ftigt habe. Nat�rlich hat auch ein Programm ein "normales" Verhalten, d.h. wie reagiert es auf Ereignis X .. Y , was macht es wenn der User eine fehlerhafte Eingabe macht, .... Oft werden bestehende Binaries (v.a. ps, netstat...) durch eigene ersetzt, um (im Falle von ps) bestimmte Prozesse zu verstecken. Mittels Application Anomaly Detection k�nnte man nun evtl. "anormales" Verhalten des Programms erkennen. Einige Application Based IDSs funktionieren sicherlich in diese Richtung, doch mit dieser Art der IDSs habe ich am wenigsten Erfahrung .

Abschlie�end noch zu einer neuen Methode der ID-Systeme:Intrusion Prevention. Intrusion Prevention wird von einigen neuen ID-Systemen eingesetzt und unterscheidet sich von den bisher besprochenen Methoden der Intrusion Detection. Anstatt durch die Analyse von Logfiles / des Traffics.... Angriffe sp�ter zu entdecken, wird versucht, Angriffe gar nicht erst zuzulassen.

Im Gegensatz zu klassischen IDSs werden hier keine Signaturen benutzt, um Angriffe zu erkennen. Im folgenden wird kurz erl�utert, was IPSs machen, die Funktionsweise sollte anhand von kleinen Beispielen verst�ndlich sein:



'Monitor application behavior' kommt den Application-Based-IDSs nahe,d.h. das Verhalten einer Applikation wird untersucht (und protokolliert), so z.B. auf welche Dateien es normalerweise zugreift, mit welchen Programmen es interagiert, auf welche Ressourcen es zur�ckgreift....�hnlich wie bei der Anomaly Detection wird also erst einmal versucht herauszufinden, was ein Programm normalerweise macht, bzw. was es machen darf.

Der dritte Punkt ('Alert on violations') sollte eigentlich keiner Erkl�rung bed�rfen, es heisst n�mlich nur, dass bei Abweichungen (sprich bei Erkennung einer Attacke) ein Alert ausgel�st werden kann. Dies kann bedeuten, dass einfach "nur" geloggt wird oder aber das Resourcen gesperrt werden....

Im zweiten Schritt ('Create application rules') wird auf den Informationen, die auf den Recherchen in Teil 1 ( 'Monitor application behavior') beruhen, ein sogenanntes Application Ruleset aufgestellt. Dieses Ruleset gibt Auskunft dar�ber, was eine Applikation machen darf (auf welche Ressourcen es zur�ckgreifen darf...) und daraus folgt dann auch, was eine Applikation nicht machen darf.

'Correlate with other events' bedeutet, dass man andere Sensoren....�ber die Vorg�nge informiert, durch das Zusammenarbeiten der Sensoren...kann so besser sichergestellt werden, dass Angriffe nicht zugelassen werden. 
       Application
        |
        V
       Action
        |
        V
    ---------------------
    | Realtime decision |
    ---------------------
       /       \
      Deny     Allow
       /           \
   Alert         execute Action


Dieses vereinfachte Schema soll lediglich noch einmal die Vorg�nge verdeutlichen. Bevor eine Aktion durchgef�hrt wird, wird erst einmal eine 'Realtime decision' durchgef�hrt (d.h. die Aktion mit dem Application Ruleset verglichen). Sollte die Aktion nicht gestattet sein (z.B. weil das Programm auf Dateien zugreifen will / �ndern will, obwohl es eigentlich gar nicht auf diese Systemdateien zugreifen darf), wird ein Alert erzeugt. In den meisten F�llen werden die anderen Sensoren (oder eine zentrale Konsole) davon auch noch informiert. Dadurch soll verhindert werden, dass andere Rechner im Netzwerk bestimmte Dateien ausf�hren/�ffnen... Sollte die Aktion allerdings dem Ruleset entsprechen, wird es genehmigt und die entsprechende Aktion letztendlich ausgef�hrt...

Nun aber zum vorerst letzten Punkt, der 'System call interception'. Manipulierte Systemaufrufe (durch z.B. sog. Rootkits) sind heutzutage immer �fter vorzufinden. Der Ansatz bei der Interception der Systemaufrufe ist recht einfach : Bevor ein Systemaufruf "zugelassen" wird, wird er erst einmal genauer �berpr�ft. �berpr�fung heisst z.B., dass man folgende Fragen checkt (siehe auch [5]):



Somit kann auch hier kontrolliert werden, ob versucht wird wichtige Konfig/Systemdateien zu �ndern, da man "lediglich" �berpr�fen muss, ob der Systemcall dem vordefinierten Ruleset entspricht oder nicht. 

               Program
                   |
                   V
             System call
                   |
                   V
            System call Interception
                 /          \
             Deny           Allow
               |               |
            do not call     Kernel
            System call


Intrusion Prevention ist verglichen mit anderen Methoden eine recht neue Methode, so dass es in Zukunft sicherlich auch noch mehr Informationsmaterial zum Thema geben wird.

Zum Abschluss sei v.a. noch auf OKENA verwiesen, ein sehr leistungsf�higes IPS. In der Whitepapers Sektion unter www.okena.com findet ihr zus�tzliches Material zu StormWatch... Wer sich f�r die Schw�chen von StormWatch interessiert, sollte [6] lesen.

Signaturen



Hier werden nun die Signaturen der IDSs behandelt, im zweiten Unterteil dann noch deren Schw�chen...

Konzept

Anhand von Signaturen k�nnen bekannte Angriffe erkannt werden, eine Signatur guckt also nach einem bestimmten Muster im Verkehr. Dieses Muster k�nnen verschiedenste Dinge sein, z.B. Strings oder auff�llige Header (mit anormalen Flagkombinationen), Ports die daf�r bekannt sind, dass sie von Trojanern benutzt werden.... Die meisten Angriffe haben gewisse Merkmale, z.B. dass eben bestimmte Flags gesetzt sind oder dass bestimmte Strings im Payload enthalten sind, durch Signaturen wird nun versucht, anhand von diesen Merkmalen einen Angriff zu entdecken.

Beginnen m�chte ich mit den sog. Payload Signaturen. Hier zur Anschauung einmal ein Teil des Payloads eines Pakets: 
00 00 00 00 E9 FE FE FF FF E8 E9 FF FF FF E8 4F    ...............
0 FE FF FF 2F 62 69 6E 2F 73  68 00 2D 63 00 FF FF .../bin/sh.-c...


Wie ihr sp�ter in der Beschreibung zu den Snort-Rules sehen werdet, bestehen hier einige M�glichkeiten, was man machen kann. H�ufig wird der Inhalt des Payloads nach bestimmten Strings durchsucht (in Snort mit 'content' oder 'content-list'), m�chte jemand z.B. eine Passwortdatei (z.B. /etc/passwd) ziehen, so besteht die M�glichkeit, den Payload zu durchsuchen (nach /etc/passwd) und falls das Paket diesen String enth�lt, Ma�nahmen dagegen einzuleiten, z.B. so : 

 alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS 80        \
 (msg:"WEB-MISC/etc/passwd";flags: A+; content:"/etc/passwd"; \
 nocase;classtype:attempted-recon; sid:1122; rev:1;)


Eine etwas andere M�glichkeit besteht darin, alle Pakete zu melden, die nicht einen bestimmten String enthalten.

Ein weiterer Ansatz besteht darin, die Gr��e der Pakete (an bestimmte Ports) zu �berwachen, um vor m�glichen Buffer Overflows zu sch�tzen. Allgemein betrachtet besteht also die M�glichkeit, den Source Port und Destination Port zu bestimmen und Zugriffe von bestimmten Ports, bzw. auf bestimmte Ports ganz zu unterbinden. Allgemein betrachtet, geh�ren string signatures zu den payload signatures. Bei den Payload Signatures handelt es sich um Signaturen, die den Payload eines Pakets untersuchen, wie z.B. bei den string signatures der Payload nach einem bestimmten String durchsucht wird.
Doch was kann man noch anhand von Signaturen entdecken ? Nur den Payload nach bestimmten Strings durchsuchen, ist sicherlich nicht immer das "berauschenste". Eine andere M�glichkeit besteht darin, die Signatur nach den Flagkombinationen des TCP Headers gucken zu lassen. Sollte in einem Paket sowohl das SYN als auch das FIN Bit gesetzt sein, so liegt hier eine Anormalit�t vor, die vom Angreifer dazu genutzt werden k�nnte, bestimmte Eigenschaften des Betriebssystems herauszufinden (oder das Betriebssystem selbst herauszufinden). Wie anfangs bereits erw�hnt, gibt es auch bestimmte Ports, die daf�r ber�hmt sind, dass sie von Trojanern genutzt werden. Beispiele f�r solche Ports w�ren 31337 oder 27374.

Vielleicht wird es verst�ndlicher, wenn ich das ganze an einem Beispiel erkl�re. F�r dieses Beispiel schauen wir uns einmal typische Merkmale eines synscan-Angriffs an:



Ziel einer Signatur sollte es in einem solchen Falle sein, "normale" Merkmale einer Verbindung von "annormalen" zu unterscheiden. Manche IDSs besitzen auch extra Datenbanken, die eben solche Informationen wie oben gegeben enthalten, dann wird auf �bereinstimmung �berpr�ft.
Prinzipiell kann man f�r das synscan-Beispiel schon Anormalit�ten feststellen, die sich per Signatur �berpr�fen lassen:


Bei der Entwicklung einer Signatur, zum Erkennen eines synscan-Angriffs, muss man nicht nur die oben genannten Merkmale des Angriffs beachten. Ziel der Signatur sollte es sein, sowohl alte Versionen als auch zuk�nftige Versionen dieses Angriffs zu erkennen. Deshalb sollte man sowohl m�glichst allgemeine Merkmale mit speziellen Merkmalen des Angriffs verbinden, so dass die Wahrscheinlichkeit einer Erkennung steigt. Zwar k�nnt ihr f�r jede neue Version eines Angriffs eine neue Signatur schreiben, allerdings w�re man dann wohl den ganzen Tag damit besch�ftigt, neue Signaturen zu schreiben, anstatt sich mit anderen, wichtigeren Dingen zu besch�ftigen. Darum solltet ihr darauf achten, dass man mit der Signatur m�glichst viele Angriffe (und Versionen) erkennt, ohne jedes Mal die Signatur �ndern zu m�ssen.

Grunds�tzlich sollte man sowohl Signaturen zur Erkennung von bestimmten Attacken als auch allgemeine Signaturen (z.B. zur Erkennung von Anormalit�ten) schreiben. Ein Beispiel f�r eine m�gliche Signatur, die einen speziellen Angriff entdeckt, k�nnt ihr oben sehen (oben war es der Angriff von synscan). Eine m�gliche allgemeine Signatur k�nnte z.B. nach folgenden Dingen gucken:



Signaturen, die allgemein nach Anormalit�ten von Protokollen suchen, werden im allgemeinen als Protocol analysis based signatures bezeichnet, w�hrend die andere Gruppe als "Packet Grepping" bekannt ist.

Schw�chen


Zwar scheint die Methode der Payload Signatures (also auch die der string signatures) recht "sicher", allerdings gibt es M�glichkeiten, diese zu umgehen. Evtl. schreibe ich mal ein Paper dazu, wie man Snort Rules umgehen kann, daher beschr�nke ich mich hier auf das Wesentliche. Eine Signatur, wie die, die ihr dort oben sehen k�nnt, guckt nach "/etc/passwd", durch nocase wird Gro�/Kleinschreibung nicht beachtet. Doch was ist, wenn wir nicht auf direktem Wege die /etc/passwd saugen, sondern �ber einen Umweg ? W�rde der Angreifer stattdessen '/etc/blabla/shit/../.././\passwd ' nehmen, w�rde die Signatur dann immer noch Alarm schlagen ? Nein, denn sie sucht, wie oben bereits erw�hnt, nur nach /etc/passwd (und anderen Gro�/Klein geschriebenen Varianten). Ein weiteres Problem bei diesen Signaturen ist, dass sie meist nur bekannte Angriffe entdecken, nach bekannten Viren suchen. Neuere Versionen bestimmter Attacken werden meistens nicht entdeckt.... Die anderen Signaturen, die sich auf spezielle Angriffe spezialisieren oder allgemeine Signaturen haben zwar den Vorteil, dass sie neue Angriffe eher entdecken, allerdings muss man bei der Formulierung seiner Signatur-Regeln "aufpassen". Eine Signatur, die sich auf einen bestimmten Angriff spezialisiert (auf dessen Entdeckung), wird fehlschlagen bei der Entdeckung einer etwas ver�nderten Variante (anstatt einen konstanten IP ID Wert von 39426 zu haben, hat die neue Attacke einen variablen Wert). Bei der Formulierung von allgemeinen (protocol analysis based signatures) Signaturen, muss man darauf achten, dass man die Regeln auch wirklich allgemein formuliert, d.h. die Regeln m�ssen auf Anormalit�ten hinweisen, die so nicht auftreten k�nnen bzw. d�rfen .

Eine weitere Schw�che offenbart sich bei n�herer Betrachtung der Unicode Attacke (siehe [4]). Beispielhaft hier die Beschreibung einer Sicherheitsl�cke im MS IIS,die durch die Unicode Attacke erm�glicht wird/wurde:

"Synopsis:
A flaw exists in Microsoft Internet Information Server (IIS) that may allow remote users to list directory contents, view files, delete files, and execute arbitrary commands. Attackers may use the Unicode character set to craft URLs to access resources via IIS that would normally be inaccessible. All recent versions of IIS are affected by this vulnerability. Exploitation of this vulnerability is trivial. ISS X-Force is aware of widespread exploitation of this vulnerability. "

Das Problem f�r IDSs besteht darin, dass die Zeichen in UTF-8 verschiedene Codes haben, die doch im gleichen Zeichen resultieren. Z.B. "A": U+0041, U+0100,

U+0102, U+0104, U+01CD, U+01DE, U+8721. Da MS ISS nicht auf Gro�/Klein - schreibung achtet(e) , waren wiederum mehrere M�glichkeiten vorhanden, verschiedene Zeichen darzustellen (es existieren z.B. 83,060,640 verschiedene M�glichkeiten AEIOU darzustellen..).

Ruft ein Angreifer nun z.B. "http://victim/../../winnt/system32/cmd.exe" w�rde IIS noch einen Fehler erzeugen, wenn man allerdings die Stelle "../.." durch ein UTF-8 �quivalent ersetzt, wird kein Fehler erzeugt : "http://victim/..%C1%9C../winnt/system32 /cmd.exe". Au�erdem k�nnen sog. unescape UTF-8 Codes dazu f�hren, dass man Seiten aufrufen kann, die man eigentlich nicht aufrufen darf. Ein NIDS hat es schwer, diese Angriffe zu erkennen, da sich das ganze auf dem Application Layer abspielt, in einem solchen Fall w�re der Einsatz eines HIDSs sinnvoller. Verschl�sselung stellt im allgemeinen ein Problem f�r Sensoren da, diese Tatsache wird mittlerweile auch immer �fter ausgenutzt. Das Vorgehen einiger "IDS-Hersteller" zeigte auch deutlich die Grenzen der Signaturen, die verf�gbaren Signaturen erkannten zwar einige bekannte Unicode-Attacken, bei kleinen Ver�nderungen des Angriffs wurde die Signatur allerdings wieder wertlos. Lediglich NetworkICE hat zur damaligen Zeit erfolgreich die Signaturen entwickelt, die diese Attacken entdeckten (Snort und ISS RealSecure entwickelten auch Signaturen, allerdings entdeckten diese -wie gesagt- nur die bekannten Unicode-Attacken).

Response


Wie bereits im Verlauf des Textes erw�hnt wurde, untersuchen IDSs die Vorg�nge auf dem PC / im Netzwerk, doch was w�re ein IDS, wenn es nichts machen w�rde, um darauf aufmerksam zu machen / darauf zu reagieren ? Dann w�re ein IDS wohl nicht viel Wert, bzw. nur Verschwendung von Rechenperformance. Grunds�tzlich unterscheidet man bei 'Response' einerseits Active Response und andererseits Passive Response. Im jeweiligen Abschnitt sollten die Unterschiede eigentlich deutlich werden.
Dem interessierten Leser sei auf OPSEC (http://www.opsec.com) verwiesen. 
Secured by Check Point' appliances are security solutions that integrate
Check Point VPN-1/FireWall-1 technology onto our partners' hardware
platforms.


Dieses System erlaubt es also bestehende Sicherheits-Systeme in die FireWall-1 zu integrieren. Ein zus�tzlicher Vorteil liegt darin, dass es weltweit anerkannt wird (und ca. 300 Partner hat ). Wenn ihr einen Angriff entdeckt, k�nntet ihr die IP Adresse des Angreifers durch die Firewall "sperren" (nur als eine m�gliche Response Option). Solltet ihr an OPSEC interessiert sein, so solltet ihr euch "Deployment Platforms" durchlesen, dort stehen auch die Voraussetzungen, um dem System "beizutreten" (Partner zu werden).

Active Response

Active Response bedeutet, dass automatisch darauf reagiert wird, wenn das IDS einen Einbruch(sversuch) meldet. Je nachdem, was f�r ein Angriff gemeldet wird (also auch abh�ngig davon, wie schwerwiegend der Angriff war) bieten die meisten IDSs verschiedene Optionen, um darauf zu reagieren:
1) Aktionen gegen den potentiellen Einbrecher einleiten 2) "Lediglich" zus�tzliche Informationen sammeln (�ber den Angreifer und dessen Attacke, bzw. deren Auswirkungen) 3) Konfiguration �ndern
Die erste m�gliche Reaktion w�re hier Aktionen gegen den Einbrecher einzuleiten. Diese Aktionen k�nnen nat�rlich alles m�gliche bedeuten, Zugriff f�r diese Person sperren oder gar Attacken gegen diesen Einbrecher einzuleiten. Wie allerdings schon bei Honeypots erw�hnt, ist es oft nicht nur schwierig, seinerseits Attacken gegen den Angreifer zu steuern, sondern oft auch illegal. In diesem Zusammenhang taucht �fter der sog. "Third Party Effect" auf. Was ist dieser Effekt eigentlich? Anschaulich erkl�rt, ist ein Third Party Effect nichts anderes als z.B. so was : 
 ------------               ------------              -------
 | Intruder | ------------> | Innocent  | ----------> | YOU |
 ------------               ------------              -------

Der Third Party Effect heisst also einfach, dass eine unschuldige Person (ein unschuldiges Netzwerk) von dem Angreifer erfolgreich attackiert wurde, danach nutzt er dieses Netzwerk, um von dort aus unser Netzwerk (und vielleicht auch andere) anzugreifen. Doch wo liegt hier das Problem? Das Problem besteht nun darin, dass unser Netzwerk 'Innocent' als Angreifer enttarnen w�rde, anschlie�end w�rde es Attacken gegen 'Innocent' einleiten, obwohl 'Intruder' dieses Netzwerk attackiert hat, um gegen uns Attacken einzuleiten, und nicht 'Innocent', der der eigentliche T�ter war. Als Folge unseres Angriffs (mit der falschen Gewissheit, wir w�rden "nur" den Angreifer attackieren) w�rde sicherlich nicht zu untersch�tzender Schaden bei 'Innocent' entstehen. Wenn 'Intruder' noch geschickt genug war, seine Spuren (also die Spuren seines eigentlichen Angriffs) zu verwischen, werden wir f�r diesen Schaden verantwortlich gemacht, nicht 'Intruder'.

Die zweite M�glichkeit (also zus�tzliche Informationen zu sammeln) ist da schon unproblematischer. Sollte ein m�glicher Angriff/Einbruch festgestellt werden, werden nun "lediglich" zus�tzliche Informationen �ber den User und dessen Attacke eingeholt. Wenn ein IDS feststellt, dass ein bestimmter User erfolgreich seine Rechte erweitert hat (oder sonst ein "Angriff" vorliegt) k�nnte dieser User in Folge dessen genauer observiert werden, z.B. Protokollieren der eingegebenen Kommandos (falls nicht eingestellt), von wo aus hat sich der User eingeloggt, wie lange bleibt er angemeldet, wann hat er sich eingeloggt, wie oft (und wann) loggt er sich die n�chsten Tage ein, probiert er irgendwelche bestimmten Binaries zu ftp'en ... , es wird so gesehen also ein Profil des Angreifers erstellt. Dies hat den Vorteil, dass man sp�ter die ausf�hrlichen Logs genau analysieren kann, um m�gliche Schwachstellen in der Konfiguration zu schlie�en, au�erdem ist es eher m�glich, gerichtliche Schritte gegen den Angreifer einzuleiten. Als dritte M�glichkeit sehe ich die m�gliche �nderung der bestehenden Konfigurationen des Systems, der Firewall etc. Wenn der Angreifer bestimmte IP Adressen benutzen sollte, so k�nnte man verbieten, dass sich ein User mit dieser IP mit dem Netzwerk connecten darf. Nat�rlich k�nnte man auch sonstige Zugriffe, die vom (vermuteten) Ort aus kommen, blocken (und auch protokollieren). In Ausnahmef�llen k�nnte man vorerst auch einfach mal jeglichen Zugriff auf das eigene Netzwerk unterbinden (oder jeglichen Zugriff auf bestimmte Ports, von bestimmten Netzwerk Interfaces ....) Eine weitere M�glichkeit der Active Response stellt das Beenden einer TCP-Connection dar (TCP-Kill genannt). Um eine Verbindung zu einem anderen Rechner zu beenden, schickt man ihm ein RST (Reset-Flag), so dass die Session "gekillt wird". Normalerweise wird RST nur gesendet, wenn ein Fehler in der Verbindung aufgetreten ist, in diesem Fall kann es aber von einem IDS (wie z.B. ISS RealSecure) dazu "gebraucht" werden Sessions mit einem anderen Rechner zu schlie�en (es existiert auch ein gleichnamiges Tool , f�r Win-NT). 

 " tcpkill - kill TCP connections on a LAN
   .......
   tcpkill  kills specified in-progress TCP connections (use-
   ful for libnids-based applications which  require  a  full
   TCP 3-whs for TCB creation). "

Dies ist ein Ausschnitt aus 'man tcpkill' ....
Wie ihr seht, besteht hier eine recht umfassende M�glichkeit, auf Angriffe zu reagieren. Gegenattacken einzuleiten scheint zwar auf den ersten Blick verf�hrerisch, sollte allerdings m�glichst nicht angewandt werden.

Passive Response


Im Unterschied zur Active Response, werden hier meist nur Warnungen... geloggt , die dann der Admin/User...kontrollieren muss. Hier bestehen folgende M�glichkeiten zu reagieren:

1) Warnungen , Hinweise ... loggen
2) Erzeugen von sog. Reports, die den Zustand des Systems �ber gewisse Zeit beobachten und so einen Bericht anfertigen.

Nahezu jedes IDS besitzt die M�glichkeit Warnungen zu generieren oder Hinweise an User/Browser...zu verschicken. Wenn z.B. versucht wird eine wichtige Systemdatei zu l�schen, bestimmte Services zu starten (deren Benutzung verboten sein sollte),...k�nnte eine Warnung erzeugt werden, die �ber den Vorfall informiert, wer daran beteiligt war und auch den Zeitpunkt. Mittlerweile besitzen auch immer mehr IDSs die M�glichkeit sog. Reports zu erzeugen. Der Zustand des Systems wird hier �ber einen l�ngeren Zeitraum hin �berwacht, Vorg�nge protokolliert und dann ein Statusreport erzeugt. Die M�glichkeit der Passive Response bieten eigentliche alle IDSs...

Filter

Ein Filter wird dazu benutzt einen Angriff anhand seiner Signatur zu erkennen. Diese Signatur hat indirekt etwas mit den bereits besprochenen Signaturen zu tun , da auch hier typische Merkmale eines Angriffs (wie Dest/Src Ports, Dest/Src IPs...) untersucht werden. Im weiteren Teil dieses Kapitels , werde ich anhand von N-Code einige Beispiele f�r Filter gegen bekannte Attacken vorstellen und erkl�ren, sollte euch N-Code unbekannt sein, so k�nnt ihr am Ende dieses Teils eine Seite finden (advanced users guide - nfr) die eine �bersicht �ber N-Code liefert.
land: 
# Dies ist ein Beispiel, wie man in N-Code
# eine land Attacke erkennen kann
 filter pptp ip () {
        if(ip.src == ip.dest)
        {
                record system.time,
                        eth.src, ip.src, eth.dst, ip.dest
                to land_recdr;
        }
 }
Da hier unbekannte Variablen verwendet wurden, hier kurz eine Erkl�rung :


Wie ihr seht, kennt auch N-Code den Operator ==, wenn ihr euch den Advanced User's Guide durchlest, werdet ihr feststellen das auch andere Gemeinsamkeiten (mit Hochsprachen...) bestehen, z.B. kennt auch N-Code die Operatoren + , - , *... oder zusammengesetzte Operatoren wie >=, != .... oder wie oben ==. Xmas Scan: Wie ihr aus "Angriffsarten" wissen solltet, sind bei einem Xmas Scan alle Flags gesetzt. Daher scheint es plausibel zu �berpr�fen, ob denn nun alle gesetzt sind oder nicht. Daf�r ben�tigt man allerdings noch die Werte der einzelnen, gesetzten Bits : 
 Bit                    Wert
 --------------------------------------
 F-FIN                  1
 S-SYN                  2
 R-RST                  4
 P-PSH                  8
 A-ACK                  16
 U-URG                  32
---------------------------------------
filter xmas ip() { if(tcp.hdr) { $dabyte = byte(ip.blob,13); if(!($dabyte ^ 63)) { record system.time, ip.src,tcp.sport,ip.dest, \ tcp.dport, "UAPRSF" to xmas_recorder; return; } } }
Auch hier kommen einige unbekannte Variablen vor, die ich erstmal erkl�ren werde:

Bei $dabyte handelt es sich um eine lokale Variable, der byte(ip.blob,13) zugewiesen wird. Zur Erkl�rung des "byte-Ausdrucks" hier eine kleine Darstellung der TCP Code Bits: 
| Src Port | Dest Port | Seq Number | ACK Number | HDR Length | Flags |\
URG | ACK | PSH | RST | SYN | FIN | Win Size | Chksum | Urg Off | Opt |
Nun erkennt man auch warum man hier 13 Bytes in byte() spezifiziert, denn 13 Bytes reichen aus, um die Flags zu erhalten. Bevor man verstehen kann, wie byte arbeitet, erst mal eine Anmerkung zu blobs. Wie ihr im Chapter 3 des Advanced User Guides nachlesen k�nnt ist ein blob eine "an arbitrarily sized sequence of bytes". 'byte' gibt ein Byte vom spezifierten Offset eines Blobs zur�ck, die allgemeine Syntax sieht so aus: byte (str blob_to_search, int offset); Durch das erste Argument wird der Blob spezifiert , der durchsucht werden soll (oben ip.blob) und das zweite Argument gibt den Offset (in 'blob_to_search') des gesuchten Bytes an. Durch 'if(!($dabyte ^ 63))' wird nun noch �berpr�ft ob alle Flags gesetzt sind, man erh�lt 63 wenn man die Werte der Flags (32+16+8+4+2+1) addiert (sollte es jemanden interessieren, durch ^ wird ein bitweises XOR durchgef�hrt)

Insgesamt bietet N-Code wirklich viele und umfassende M�glichkeiten, neben den bereits genannten. Z.B. ist auch noch m�glich:


Weitere Informationen zu N-Code k�nnt ihr im Advanced User's Guide einholen: http://www.cs.columbia.edu/ids/HAUNT/doc/nfr-4.0/advanced/ advanced-htmlTOC.html

In zuk�nftigen Versionen dieses Papers, werden wohl wesentlich mehr Filter beschrieben werden, also checkt mal regelm��ig nach neuen Releases dieses Papers ;)

Standards


In diesem Abschnitt werde ich euch verschiedene "Standards" vorstellen, also Listen/Vereinbarungen....die von vielen ools/"Experten".... gemeinsam verwendet werden.

CVE

CVE steht f�r Common Vulnerabilities and Exposures und ist eigentlich nichts anderes als eine Liste , die Namen f�r vulnerabilites/exposures vorsieht. Dies mag sich zwar auf den ersten Blick komisch anh�ren, kann allerdings sp�ter wichtig werden. Verschiedene Tools benutzen meist verschiedene Ausdr�cke f�r die gefundenen Vulnerabilites...., durch die Verwendung von CVE kann man so eine einheitliche Beschreibung verschiedenster Vulnerabilites/Exposures verwenden, die jeder versteht. Man ist also nicht mehr davon abh�ngig, dass der andere auch dieses Tool verwendet....

CVE stellt also einen Namen f�r eine bestimmte Vuln/Exposure bereit, zus�tzlich aber auch noch eine Beschreibung, durch die einheitliche (und standardisierte) Beschreibung, tauchen weniger Missverst�ndnisse zwischen Usern verschiedener Systeme auf. CVE definiert hierbei vulnerability als : "those problems that are normally regarded as vulnerabilities within the contect of all reasonable security policies" und exposures als "problems that are only violations of some reasonable security policies". Die Unterscheidung zwischen vulnerability und exposures ist elementar in CVE. Als Beispiel f�r eine vulnerability , lassen sich z.B. phf, world-writeable password files.... nennen, w�hrend ein Beispiel f�r exposures z.B. die Verwendung von Programmen (die man bekannterweise per Bruteforce angreifen kann) w�re, oder auch die Verwendung von Services , die im allgemeinen auch oft angegriffen werden. Durch die Defintion und diese Beispiele sollte es eigentlich m�glich sein, zwischen vulnerabilites und exposures (in CVE) zu unterscheiden. Der grunds�tzliche Unterschied besteht v.a. darin , dass vulnerabilites beinhalten das ein Angreifer M�glichkeiten besitzt Kommandos als anderer User auszuf�hren oder gar Dateien zu lesen/beschreiben, obwohl dies (aufgrund der file-permissions) nicht m�glich sein sollte. Exposures hingegen beinhalten, dass ein User weitere Informationen �ber das System (und dessen Zustand) herausfinden kann, seine Aktivit�ten dabei versteckt ablaufen.....Exposures entstehen also aufgrund von falschen Sicherheitseinstellungen, die man allerdings "beheben" kann. Als Vulnerability wird hingegen eher eine Sicherheitsl�cke verstanden, die unter den "gew�hnlichen" Sicherheitssystemen auftritt. Au�erdem soll hier normalerweise auch die M�glichkeit gegeben sein, die Bedrohung durch potentielle Angreifer minimieren zu k�nnen (in dem man Permissions checkt....). Doch irgendwie muss die "Liste" auch aktuell bleiben, allerdings wird nicht jede vulnerability oder exposure sofort "aufgenommen". Wenn eine vulnerability / exposure gefunden wird, wird ihr zuerst eine "candidate number" zugewiesen (dies geschieht durch die CNA - Candidate Numbering Authority). Au�erdem wird sie auf dem Board vorgeschlagen (vom CVE Editor) und danach dr�ber geredet ob man die vulnerability /exposure aufnehmen will. Sollte das Board zum Schluss kommen, dass man den Kandidaten (vorerst) nicht aufnehmen will, so wird auf ihrer Website noch der Grund angegeben. Sollte der Kandidat allerdings akkzeptiert werden, wird er in die Liste aufgenommen (und ist somit nun offiziell Teil von CVE). Nun sollte es auch verst�ndlicher sein, das jeder (potentiellen) vulnerability.... erstmal ne "candidate number" zugewiesen wird, da erst danach dar�ber diskuttiert werden muss, ob der Kandidat aufgenommen werden soll oder nicht. Der vulnerability... wird hier erstmal eine 'candidate number' zugewiesen, damit man zwischen Kandidaten und offiziellen Eintr�gen in der Liste unterscheiden kann. Jeder Kandidat besitzt 3 grundlegende Felder (die ihn "identifizieren"):


Die Nummer ist sogesehen der eigentliche Name des Kandidaten, wobei sich diese Nummer aus "Erscheinungsjahr" und einer weiteren Zahl zusammensetzt , die angibt der wievielte Kandidat es dieses Jahr war: 
        CAN-JAHR-wievielter Kandidat des Jahres

Wenn nun ein Kandidat vom Board akkzeptiert wird, wird er wie bereits gesagt in die Liste aufgenommen. Damit ist auch verbunden , dass aus 'CAN-YEAR-Candite number' ein 'CVE-YEAR-Candidate number' wird. D.h. an einem Beispiel: Existiert ein Kandidat mit 'CAN-2001-0078' und wird dieser Kandidat akkzeptiert, wird er in die Liste aufgenommen als 'CVE-2001-0078'.

Soviel dazu, die offizielle Seite zu CVE ist http://cve.mitre.org/ , dort k�nnt ihr nat�rlich zus�tzliche Informationen finden...

Beispiele


In diesem letzten Teil werden einige IDSs vorgestellt :

Snort

Da Snort sehr weit verbreitet ist und viele Optionen bietet, werde ich es etwas ausf�hrlicher als die anderen Beispiele beschreiben. Grunds�tzlich kann sich Snort in drei Modes befinden : Sniffer, Packet Logger und Network Intrusion Detection System. Im Sniffer Modus gibt Snort Pakete auf der Konsole aus, im Packet Logger Modus loggt es sie auf der Festplatte... und im Network Intrusion Detection Modus k�nnen Pakete analysiert werden. Zwar gehe ich haupts�chlich auf den letzten Modus ein, aber dennoch hier kurz eine kleine Einf�hrung in Sniffer u. Packet Logger Mode: Sniffer Mode:
Im Sniffer Modus k�nnt ihr euch verschiedene Paketinformationen ausgeben lassen, z.B. TCP/IP Paket Header: 
 [Socma]$ ./snort -v

Als Ausgabe werdet ihr lediglich die IP/TCP/ICMP/UDP Headers ausgegeben bekommen. Es gibt eine Vielzahl von Optionen, von denen hier einige aufgez�hlt werden. 
 -d = gibt auch noch die Paket-Daten aus
 -e = zeigt auch noch den Data Link Layer

Packet Logger Mode:
Im Unterschied zum Sniffer Mode, k�nnt ihr im Packet Logger Mode die Pakete auch auf der Festplatte protokollieren. Ihr m�sst lediglich ein Verzeichnis angeben, in das Snort loggen soll und schon schaltet es automatisch in Paket Logger Modus: 
 #loggingdirectory muss existieren:
 [Socma]$ ./snort -dev -l ./loggingdirectory
Bei Angabe von "-l" kann es manchmal passieren das Snort die Adresse des Remote-Computers als Verzeichnis holt (in das geloggt wird) und manchmal nimmt es die lokale Host Adresse. Um relativ zum Heimnetzwerk loggen zu k�nnen, m�sst ihr auf der Kommandozeile spezifizieren, welches das Heimnetzwerk ist: 
[Socma]$ ./snort -dev -l ./loggingdirectory -h 192.168.1.0./24
Eine weitere M�glichkeit besteht darin, das ganze im TCP-DUMP Format zu loggen: 
 [Socma]$ ./snort -l ./loggingdirectory -b
Nun wird auch das gesamte Paket geloggt, nicht nur bestimmte Sektionen, dadurch f�llt die Angabe von weiteren Optionen weg. Zwar kann man Programme wie tcpdump benutzen um die File wieder in ASCII -Text zu "�bersetzen" , allerdings kann Snort dies auch erledigen: 
 [Socma]$ ./snort -dv -r packetzumuntersuchen.log
Network Intrusion Detection Mode: Um in den NIDS Modus zu schalten , k�nnt ihr ein Kommando wie das folgende verwenden: 
 [Socma]$ ./snort -dev -l ./log -h 192.168.1.0/24 -c snort.conf
In diesem Fall ist snort.conf die Konfigurationsdatei. Diese wird ben�tigt damit Snort weiss woher es seine "Regeln" herbekommt, also wann ein Angriff vorliegt oder nicht, ob eine Anfrage gestattet werden soll.... Die in snort.conf festgelegten Regeln werden dann auf die Pakete angewandt und analysiert. Wird kein Output-Verzeichnis festgelegt, wird standardm��ig /var/log/snort dazu verwendet. Die Ausgabe von Snort h�ngt auch von den Alert-Modes ab, je nachdem welchen Alert-Modus man verwendet bekommt man mehr oder schneller seine Informationen: 
 ----------------------------------------------------------------
 |      Modus   |  wie/was wird ausgegeben                      |
 ----------------------------------------------------------------
 | -A fast      |  Zeitpunkt, Source u. Destination IPs/ports,  |
 |              |  die eigentliche Alert Nachricht              |
-----------------------------------------------------------------
 | -A full      |  Standardeinstellung                          |
-----------------------------------------------------------------
 | -A unsock    |  sendet die Warnungen an einen UNIX           |
 |              |  socket                                       |
-----------------------------------------------------------------
 | -A none      |  stellt die Alerts ab                         |
-----------------------------------------------------------------

Wie wir wissen kann durch -b im Binary Mode geloggt werden, durch -N wird Paket Logging ganz abgeschaltet. Doch das ist noch l�ngst nicht alles, z.B. kann Snort auch Nachrichten an Syslog schicken. Standardeinstellung ist hier LOG_AUTHPRIV und LOG_ALERT. Zum Senden von Nachrichten an Syslog m�sst ihr lediglich "-s" angeben, Beispiele dazu gleich. Des weiteren besteht die M�glichkeit auch Nachrichten an den smbclient oder WinPopUp Warnungen an einen Windows Rechner zu schicken. Um dieses "Feature" nutzen zu k�nnen m�sst ihr bei der Konfiguration von Snort "-enable-smbalerts" angeben. 
 [Socma]$ ./snort -c snort.conf -b -M MYWINWORKSTATION
Oder hier ein Beispiel , das die Anwendung der Alert Modes zeigt: 
 [Socma]$ ./snort -b -A fast -c snort.conf
Neben den bereits gesagten Optionen gibt es noch einige, wie die folgenden: 
 -D = starte Snort im Daemon Mode
 -u usersnort= starte Snort mit der UID 'usersnort'
 -g groupsnort = starte Snort mit der GID 'groupsnort'
 -d = protokolliere auch die Daten aus der Applikationsschicht mit


Snort bietet viele Optionen, bei Problemen k�nnt ihr einfach mal "snort -h" eintippen oder in Mailinglisten danach gucken ob euer Problem nicht schon mal aufgetaucht ist. Der folgende Abschnitt handelt von den Snort-Rules, solltet ihr kein Interesse daran haben die bestehenden Rules zu verstehen oder gar eigene zu schreiben, so k�nnt ihr diesen Abschnitt �berspringen. Wie ich am Ende (des Teils �ber Snort) nochmals erw�hnen werde, k�nnt ihr das SnortUsersManual unter www.snort.org downloaden, dieses dient hier als eigentliche Quelle.

Snort Rules:
Zum besseren Verst�ndnis von Snort ist auch ein Verst�ndnis der Snort Rules notwendig. Snort benutzt manchmal bestimmte Variablen, die ihr durch Verwendung von 'var' definieren k�nnt: 
   var: <name> <wert>      var

   MY_NET [192.168.1.0/24,10.1.1.0/24]
   alert tcp any any -> $MY_NET any (flags:S;msg: "SYN packet";)
Es gibt allerdings mehrere M�glichkeiten den Variablennamen anzugeben: 
$variable = definiert die Meta Variable
$(variable) = hier wird der Wert der Variable "variable" eingesetzt
$(variable:-default) = wenn 'variable' definiert ist, wird hier der
 wert von 'variable' eingesetzt, ist 'variable' nicht definiert wird
 hier der Wert von 'default' eingesetzt
$(variable:?msg) = setzte den Wert der Variable 'variable' ein
 oder (wenn nicht definiert) gib die Nachricht 'msg' aus

Solltet ihr euch schon mal etwas mit Shellprogrammierung befasst haben, kommen euch diese Dinge sicherlich nicht fremd vor: 
 [Socma]$ shelltest=we
 [Socma]$ echo hallo $shelltestlt
 hallo
 [Socma]$ echo hallo ${shelltest}lt
 hallo welt
Hier ist also die Verwendung von $(variable) in Snort und ${variable} in der Shell gleichbedeutend. Auch f�r die anderen gibt es �quivalente (oder �hnliche Ausdr�cke) in der Shellprogrammierung: 
 [Socma]$ shelltest = bash
 [Socma]$ echo ${shelltest:-nobash}
 bash
 [Socma]$ echo ${notdefined:-nobash}
 nobash
Also auch die Verwendung des Ausdrucks $(variable:-default)' unterscheidet sich nur in der Tatsache das auf der Shell { und } anstatt ( und ) benutzt werden. Der letzte Ausdruck existiert auch auf der Shell: 
 [Socma]$ shelltest = bash
 [Socma]$ echo ${shelltest:?"dann eben csh"}
 bash
 [Socma]$ echo ${nichtdefiniertevariable:?"nicht definiert oder null"}
 nicht definiert oder null

Dieser kleine Exkurs sollte lediglich "Wissen verkn�pfen", zumindest ich konnte mir die Schreibweisen in Snort so schneller einpr�gen, da ich einfach an die (mir bekannten) Dinge auf der Shell gedacht habe.
Viele Kommandozeilenoptionen...k�nnen in der Konfigurationsdatei eingestellt werden. Hierzu wird 'config' verwendet : 
        config <directive> [: <value> ]

Die wichtigsten 'directiven' w�ren :
alertfile = �ndert die Datei in die Alerts gespeichert werden
daemon = Prozess als Daemon starten ( -D)
reference_net = setzt das Heimnetzwerk (-h)
logdir = setzt das Logging Verzeichnis (-l)
nolog = Logging wird ausgeschaltet
set_gid = �ndert die GID (-g)
chroot = chroot'ed in das angegebene Verzeichnis (-t)
set_uid = setzt die UID (-U)


Wenn ihr z.B. die alertfile �ndert wollt in z.B. "mylogs", macht ihr das so: 
        config alertfile : mylogs

Nun aber zur�ck zu den eigentlichen Regeln (hier eine beispielhafte ftp.rules (Ausschnitt)): 
alert tcp $EXTERNAL_NET any -> $HOME_NET 21 (msg:"FTP EXPLOIT overflow";\
flags: A+; content:"|5057 440A 2F69|";\
classtype:attempted-admin; sid:340;rev:1;)

Grunds�tzlich bestehen Snort-Rules aus zwei Teilen : dem rule header und den rule options. Hierbei gibt der rule header Auskunft �ber folgende Dinge:

In der obigen ftp-rule w�re der rule header der folgende Teil: 
 Aktion       source ip         destination ip
    |              |                |
 alert tcp $EXTERNAL_NET any -> $HOME_NET 21
         |                |               |
        Protokoll       From any port   Port

Hier ran sieht man , dass der rule header bis zur ersten ( geht und danach die rule options beginnen. Es gibt mehrere m�gliche Aktionen (in diesem Falle alert) die eingeleitet werden k�nnen, sollte die Snort-Rule etwas auff�lliges feststellen:

Das zweite Feld (Protokoll - hier tcp) spezifiziet welches Protokoll "beobachtet" (analysiert) werden soll. M�glich sind hier : tcp ,udp , icmp und ip (allerdings ist es nicht unwahrscheinlich das in Zukunft auch andere wie ARP,GRE....verf�gbar sind).
Im Zusammenhang mit dem n�chsten Feld (source ip) trifft man �fters auch auf den ! - Operator (Negationsoperator). 
 alert tcp !$EXTERNAL_NET any -> $HOME_NET 21

Als Folge der Verwendung des Negationsoperators wird nun mehr jedes Paket das nicht von $EXTERNAL_NET kommt geloggt. Des weiteren besteht die M�glichkeiten mehrere IP Adressen anzugeben, also Listen von IP Adressen. Daf�r m�sst ihr lediglich die entsprechenden Adressen mit Komma voneinander trennen und mit [ ] umklammern. 
        alert tcp ![ip adresse,ip adresse] any -> ....

Eine weitere Alternative stellt die Verwendung von "any" dar, womit jede IP Adresse einbezogen ist. 
        log tcp any any -> ...

Der letzte Teil des rule headers ist die Spezifikation des Ports, im obigen Beispiel also ftp. Man kann nicht nur einen bestimmten Port ueberwachen, sondern auch bestimmte Bereiche (also auch mehrere Ports). Hier die verschiedenen M�glichkeiten: 
 :portnumber                     -> alle ports kleiner gleich
                                 portnumber
 portnumber:                     -> alle ports gr��er gleich
                                 portnumber
 fromportnumber:toportnumber     -> alle ports zwischen fromportnumber
                                 und toportnumber (und diese mit
                                 einbezogen)
Nat�rlich l�sst sich auch hier wieder der Negationsoperator angeben, was zur Folge h�tte das alle au�er die angegebenen Ports "�berwacht" werden w�rden, z.B. 
       !:21            -> alle ports die nicht kleiner gleich 21 sind
Etwas was noch nicht direkt erl�utert, die ganze Zeit aber verwendet wird, ist der Direktionsoperator "->". 
                "Source" -> "Destination"
Doch es gibt auch eine andere Variante, <> : 
                 "Source" <> "Destination"
Dies f�hrt dazu das Snort sowohl Source als auch Destination nach der Adresse.... durchsucht.
Wie ich bereits eben gesagt habe, gibt es die Aktion 'activate' , die dazu f�hrt das ein Alert erzeugt wird und dann zu einer anderen dynamischen Snort-Regel zur�ckkehrt.
Sollte eine bestimmte Regel die jeweiligen Aktionen durchgef�hrt haben kann es eine andere aktivieren. Grunds�tzlich unterscheiden sich normale Regeln und "activate rules" nur in der Tatsache das ein bestimmtes Feld bei activate rules angegeben werden muss : "activates". Dynamische Regeln hingegen arbeiten wie log (s.o.) nur das hier "activated_by" angegeben wird. Des weiteren existiert ein weiteres Feld, dass angegeben werden muss :"count". Wenn die "activate rule" ihre Arbeit getan hat, wird die dynamische regel "aufgerufen", allerdings nur f�r "count" Pakete (also wenn count = 40, dann f�r 40 Pakete). 
activate tcp !$HOME_NET any -> $HOME_NET 143 (flags : PA;  \
  content : "|E8C0FFFFFF|\bin|;activates : 1; msg : "IMAP buf!";)
dynamic tcp !$HOME_NET any -> $HOME_NET 143 (activated_by : 1; \
  count : 50;)

Einige Optionen (also die rule options) sind noch nicht bekannt, daher werde ich jetzt auf diese eingehen, sp�ter erscheint euch diese Regel dann auch sinnvoller. Beachtet im obigen Beispiel bitte die Felder activates und bei der dynamischen Regel activated_by (und count). Die erste Regel ruft nach erledigter Arbeit die dynamische Regel auf , dies sieht man auch daran das in der dynamischen Regel activated_by : 1 steht.

Nun aber zum zweiten Teil der Snort-Rules, den rule options. Nimmt man nochmals die erste ftp.rule: 

alert tcp $EXTERNAL_NET any -> $HOME_NET 21 (msg:"FTP EXPLOIT
overflow"; flags: A+;\
content:"|5057 440A 2F69|";classtype:attempted-admin;\
sid:340; rev:1;)


In diesem Falle w�re die rule option (der rule header geht wie gesagt nur bis zur ersten ")" ) : 

 (msg:"FTP EXPLOIT overflow";\
flags: A+; content:"|5057 440A 2F69|";\
classtype:attempted-admin; sid:340; rev:1;)


Zwar gibt es 34 Keywords, allerdings werde ich nur die (wichtigsten und/oder gebr�uchlichsteen) erl�utern. Derjenige der eine �bersicht �ber alle m�glichen Keywords haben m�chte, sollte ins SnortUsersManual schauen, dort stehen alle erkl�rt.

msg - gibt die alert-messages aus und loggt die Meldungen im Paket Logger Modus
logto - loggt die Pakete in einer bestimmten Datei
dsize - vergleicht die Paketgr��e mit einem anderen Wert
flags - �berpr�ft die TCP Flags nach bestimmten Werten
content - sucht nach nem bestimmten Muster/String in einem Paket
content-list - sucht nach mehreren Mustern/Strings in einem Paket
nocase - Gro�-Kleinschreibung des gesuchten Strings werden nicht beachtet
react - aktive Response (blockt Webseiten)
sid - Snort rule id
classtype - teilt die potentiellen Angriff in bestimmte Gruppen von Angriffen ein
priority - regelt die "Strenge"
So weit so gut, doch was genau machen die einzelnen rule options ? msg:
Auf 'msg' trifft man sehr h�ufig beim Durchst�bern der rules, da diese Option daf�r verantwortlich ist, dass Alerts ausgegeben werden (oder auch das geloggt wird). 
   msg:"<text>";
Hierbei ist "<text>" die jeweilige Nachricht die in die alertfile geschrieben wird/ausgegeben wird.....
logto:
Jedes Paket, auf das die Rule zutrifft, wird in einer speziellen File geloggt. 
    logto: "<filename>";
In diesem Falle ist "<filename>" die Datei, in die diese Paket geloggt werden.
dsize:
Hiermit wird die Gr��e des Pakets bestimmt. Wenn man weiss das ein bestimmter Service einen Buffer (einer bestimmten Gr��e) kann man diese Option verwenden, um m�glichen Bufferoverflows entgegen zu wirken. Verglichen mit 'content' ... ist es um einiges schneller, daher wirds zum Testen von BufferOverflows auch eher benutzt. 
        dsize: [>|<] <gr��e>;
Die beiden optionalen Operatoren > und < dr�cken aus, dass die Gr��e des Pakets kleiner,bzw. gr��er als dieser Wert sein sollte.. flags:
Hiermit wird getestet welche Flags gesetzt sind. Momentan sind 9 Flags in Snort verf�gbar: 
 F      FIN
 S      SYN
 R      RST
 P      PSH
 A      ACK
 U      URG
 2      Bit 2 reserviert
 1      Bit 1 reserviert
 0      keine TCP Flags gesetzt

Daneben gibt es auch noch logische Operatoren, die zus�tzliche Kriterien zum Testen der Flags spezifieren k�nnen: 
 + ALL flag     = Treffer bei allen spezifierten (und auch anderen)
                Flags
 * ANY flag     = Treffer bei allen spezifierten Flags
 ! NOT flag     = wenn die spezifierten Flags nicht  gesetzt sind

Allgemein wird das 'flags' Keyword so verwendet: 
        flags: <Flag Wert>;

Die reservierten Bits k�nnen verwendet werden um ungew�hnliches Verhalten, wie z.B. IP stack fingerprinting Versuche zu erkennen.
content:
Einer der wohl (neben msg) am h�ufigsten gebrauchten Keywords ist 'content'. Hiermit kann der Payload Pakete nach bestimmten Inhalt durchsucht werden. Sollte der spezifiezierte Inhalt gefunden werden, werden bestimmte Aktionen gegen den User eingeleitet. Wenn der Inhalt (der nach content spezifiert wird) in dem Payload des Pakets vorkommt, wird der Rest der jeweiligen Snort-Rule ausgef�hrt. Ohne Angabe von nocase (s.u.) wird auch Gro�/Kleinschreibung beachtet. Der Inhalt , nach dem der Payload durchsucht werden soll, kann sowohl bin�re daten, als auch text enthalten. Bin�re Daten werden durch | | eingeschlossen und als Bytecode dargestellt. Der Bytecode stellt die bin�ren Informationen als hexadezimale Zahlen dar... Auch im Zusammenhang mit diesem Keyword kann man den Negationsoperator (!) geschickt anwenden, so dass man z.B. einen alert... ausgibt wenn ein Paket nicht einen bestimmten Text...enth�lt. 
        content: [!] "<inhalt>";

Die Angabe von ! ist wie gesagt optional, also nicht zwingend. 
 alert tcp any any -> 192.168.1.0/24 143 \
(content: "|90C8 C0FF FFFF|/bin/sh";\
msg: "IMAP buffer overflow";)

Wie in dieser Regel zu sehen ist, werden die bin�ren Daten durch die | | umschlossen (wie oben bereits erw�hnt), danach l�sst sich normaler Text spezifieren. Ihr solltet euch auch einmal die Beschreibung von 'offset' und 'depth' im SnortUsersManual anschauen, da diese auch �fters in Verbindung mit 'content' gebraucht werden.

content-list:

Dieses Keyword arbeitet so �hnlich wie 'content' mit dem Unterschied das man mehrere Strings.... angeben kann, nach denen das Paket durchsucht werden soll. Man schreibt die entsprechenden Hexazahlen,Strings.... in eine Datei und spezifiziert dann bei Verwendung von 'content-list' die Datei in der die W�rter stehen. Zu beachten ist hier, das die Strings ... untereinander (jeder String in einer Zeile) stehen muss, z.B. 

        "kinderporno"
        "warez"
        .....

Danach kann man durch z.B. 'content-list: [!] "<dateiname>";' diese Datei "durchsuchen". Auch hier kann man nat�rlich optional ! angeben, hat aber auch die gleiche Wirkung wie bei 'content'.

nocase:
Diese rule option spielt eine wichtige Rolle im Zusammenhang mit 'content' keywords. Diese achten normalerweise auf Gro�/Kleinschreibung, durch Verwendung von 'nocase' wird aber nicht mehr explizit auf Gro�/Kleinschreibung kontrolliert: 

 alert tcp any any -> 192.168.1.0/24 21 (content: "USER root";\
  nocase; msg: "FTP root user access attempt";)


Ohne Verwendung von 'nocase' w�rde nur nach 'USER root' durchsucht, da aber 'nocase' angegeben wurde z�hlt die Gro�/Kleinschreibung nicht mehr... react:
Wenn man ein Paket nach einem bestimmten Inhalt durchsucht (durch 'content' oder 'content_list') und einen Treffer feststellt, kann 'react' dazu verwendet werden darauf zu reagieren. Normalerweise werden z.B. bestimmte Seiten die ein User besuchen will geblockt (Pornoseiten...). Durch Flex Resp ist es m�glich Verbindungen zu beenden oder Warnungen an den Browser zu schicken. Folgende Optionen sind m�glich/g�ltig:

block - schlie�t die Verbindung und sendet einen Hinweis raus
warn - sendet eine sichtbare Warnung (bald verf�gbar)
Diese sog. 'basic arguments' k�nnen dann noch durch weitere Argumente (sog. 'additional modifiers') erg�nzt werden:

msg - der text der durch das Keyword 'msg' gesendet wird, wird in den Hinweis an den User einbezogen
proxy : <portnummer> - hier wird der proxy port dazu verwendet den Hinweis zu versenden (auch bald verf�gbar) 
        react : <basic argument [, additional modifier ]>;

Das 'react' Keyword wird am Ende der rule options eingef�gt, und kann z.B. so verwendet werden: 
 alert tcp any any <> 192.168.1.0/24 80 (content-list: "adults"; \
   msg:"Diese Seite ist nicht f�r Kinder gedacht !"; react: block, msg;)
sid:
'sid' oder ausformuliert Snort rules IDentification wird benutzt um "einzigartige" Snort rules zu identifizieren. Dadurch ist es "output plugins" erlaubt/m�glich jede Regel leicht zu identifizieren. Allerdings gibt es verschiedene Bereiche von Sid's: 
 < 100 = f�r die Zukunft reserviert
 100-1 000 000 = Regeln die zusammen mit Snort "kommen"
 > 1 000 000 = wird f�r lokale Regeln verwendet

 sid-msg.map enth�lt ein mapping der msg tags zu sid's. Diese wird von
 post-processing benutzt um einer id eine Warnung zuzuordnen.

 sid:  <snort rules id>;

 alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS 80  \
  (msg: "WEB-IIS file permission canonicalization"; uricontent:\
  "/scripts"..%c1%9c../"; flags: A+;nocase;sid: 983;rev:1;)
classtype:
Durch 'classtype' k�nnt ihr die Attacken in diverse Gruppen von Attacken unterteilen. In den Regeln k�nnt ihr dann selbst bestimmen welche Priorit�t ein potientieller Angriff haben soll, bzw. zu welcher Gruppe der Attacken er geh�rt .Regeln die in der Konfigurationsfile eine Einstufung "haben", bekommen dort automatisch auch eine Standard-Priorit�t zugewiesen. 

 classtype: <class name>;

Die Einstufungen der Regeln werden in der classification.config definiert. Dort gilt folgende Syntax: 
 config classification: <class name>,<class beschreibung>,\
       <standard priorit�t>

Welche Gruppen von Attacken es gibt, k�nnt ihr im n�chsten Teil sehen, der Beschreibung von 'priority'.
priority:
Durch dieses Keyword k�nnt ihr euren Regeln eine "Security-Stufe" zuweisen, wie schwer also ein potentieller Angriff sein w�rde. Je h�her die Priorit�t der Regel, desto gr��er das potentielle Sicherheitsrisiko. Verbunden mit den bereits besprochenen 'class types' lassen sich die Priorit�ten besser verstehen: 
Class type                    Beschreibung                 Priorit�t
---------------------------------------------------------------------
 not-suspicious                Jeglicher "unauff�lliger" Verkehr    0
 unknown                       Unbekannter Verkehr                  1
 bad-unknown                   Potentiell "schlechter" Verkehr      2
 attempted-recon              Attempted Information Leak            3
 successful-recon-limited     Information Leak                      4
 successful-recon-largescale  Large Scale Information Leak          5
 attempted-dos                Versuchte DoS-Attacke                 6
 successful-dos               Erfolgreiche DoS-Attacke              7
 attempted-user               Versuch User-Privilegien zu erhalten  8
 unsuccessful-user            Nicht erfolgreicher Versuch           7
                                 User-Privilegien zu erhalten
 successful-user              Erfolgreicher Versuch                 9
                                 User-Privilegien zu erhalten
 attempted-admin              Versuch Admin Rechte zu bekommen     10
 successful-admin             Erfolgreicher Versuch Admin          11
                                 Rechte zu bekommen
---------------------------------------------------------------------

Wie bereits erw�hnt bedeuten h�here Priorit�ten auch h�here Sicherheitsrisiken, sollte es einem User gelingen Admin Rechte zu bekommen ist dies die schwerwiegenste Attacke. 
 alert tcp any any -> any 80 (msg: "WEB-MISC phf Versuch";\
        flags: A+;content: "/cgi-bin/bash";priority:10;)

Das ganze Thema 'Rules' ist zugegebenerma�en sehr umfassend, doch nicht soo schwer. Schaut euch einfach diverse rules an, guckt im Manual oder hier nach was die einzelnen bedeuten und nach ner gewissen Zeit erscheinen euch auch die "Rulemonster" verst�ndlich ;) Bezugsquelle f�r Snort und Dokumentationen findet ihr unter http://www.snort.org . Dort findet ihr einige interessante .pdfs , z.B. das Snort Users Manual, die Hauptquelle f�r diese Beschreibung von Snort.

LIDS


Sp�testens seit stealth's Paper (und Sources) und dem LIDS-Hacking-HOWTO wissen wir , dass LIDS nicht wirklich die Sicherheit auf dem Rechner erh�ht, sondern in manchen Situationen eher ein Rootkit ist ;)

Aber erst einmal zum Konzept und anschlie�end zu den (scheinbaren) St�rken und Schw�chen von LIDS. Urspr�nglich wurde es entwickelt um z.B. wichtige Systemdateien zu sch�tzen und bestimmte Prozesse f�r die User unsichtbar zu machen. Au�erdem sollte es nicht gestattet sein einfach so Module einzubinden, die notwendigen Module werden beim Starten des Systems eingebunden... Da es (wie schon gesagt) ein LIDS-Hacking-HOWTO u. Stealth's Paper gibt , die die Arbeitsweise und Schw�chen von LIDS erl�utern, werde ich hier nur kurz die wichtigsten Dinge erw�hnen. Den Link zu den beiden Texten findet ihr am Ende dieses Abschnitts.

Eine Hauptaufgabe von LIDS ist es, das Dateisystem zu sch�tzen. Um (wichtige) Dateien sch�tzen zu k�nnen, werden die entsprechenden Dateien / Verzeichnisse erst einmal in Gruppen unterteilt:


Um "wirklichen" Schutz bieten zu k�nnen, werden einige Systemaufrufe manipuliert, die sicherstellen das die Protections eingehalten werden. (z.B. sys_open(), sys_mknod(), ...)
Desweiteren verhindert LIDS , dass bestimmte Prozesse gekillt werden k�nnen (oder sichtbar sind). Sinn u. Zweck des ganzen ist es zu verhindern, dass der Angreifer gewisse Prozesse sieht, die ihn m�glicherweise beobachten k�nnten. Ein 'ps -ax..' Aufruf sollte also unsere Prozesse nicht anzeigen. Damit man den Prozess auch wirklich verstecken kann, wird er als 'PF_HIDDEN' markiert, wenn ps dabei ist die Informationen �ber die Prozesse auszugeben und sieht das ein Prozess mit 'PF_HIDDEN' markiert ist, wird es diesen Prozess nicht anzeigen. Doch das alleine gen�gt noch nicht um den Prozess wirklich zu verstecken, denn momentan h�tte er immer noch einen Eintrag im Proc-Filesystem (/proc), also manipuliert LIDS auch diese "Funktion", damit der Prozess nicht im /proc Verzeichnis erscheint. Daneben besteht noch die M�glichkeit die Rechte eines Prozesses zu beschr�nken, anhand von Capatibilites. Wenn z.B. CAP_CHROOT auf 0 gesetzt ist, hat der Prozess nicht mehr die M�glichkeit chroot anzuwenden (siehe auch /usr/src/linux/include/linux/capatibilites.h).
Au�erdem besitzt LIDS die M�glichkeit in 2 Sicherheitsstufen zu laufen, 'security' und 'none_security'. Um zwischen 'security' und 'none_security' zu unterscheiden, gibt es die globale Variable 'lids_load'. Standardm��ig ist diese auf '1' voreingestellt, dies bedeutet das standardm��ig LIDS im 'security' Modus l�uft, d.h. die Einschr�nkungen...gelten. Wenn man beim Start 'security=0' angibt (LILO-Prompt) so wird auf 'none_security' geschaltet, was bedeutet das jegliche Sicherheits�berpr�fungen, Einschr�nkungen....abgeschaltet sind. Mit lids_load == 0, l�uft der Rechner also so, als w�re LIDS gar nicht installiert. Des weiteren besteht die M�glichkeit die Sicherheitsstufe durch 'lidsadm -S' online zu �ndern , dann muss allerdings ein Passwort spezifiert werden.

Doch LIDS bietet auch die M�glichkeit die Firewall Regeln zu sch�tzen, man sollte daf�r aber CONFIG_LIDS_ALLOW_CHANGE_ROUTES anschalten und CAP_NET_ADMIN "ausschalten". M�chte jemand die Firewall Regeln �ndern, muss er zuerst CAP_NET_ADMIN wieder anschalten, dadurch wird verhindert das jeder die Regeln �ndern kann. Zus�tzlich besteht noch die M�glichkeit Sniffer "abzuschalten" und einen Port Scan detector im Kernel einzubauen.


Auch LIDS bietet diverse "Response-Options" (siehe Kapitel �ber Response), z.B. die Benachrichtigung �ber den Pager, per SMS an den Administrator zu verschicken.

Alles in allem sehr viele M�glichkeiten, doch Stealth hat in seinem Paper auch gezeigt wie man LIDS missbrauchen kann um es zu einem verf�gbar: http://www.securitybugware.org/Linux/4997.html Das LIDS Howto k�nnt ihr hier runterladen : http://www.lids.org/lids-howto/lids-hacking-howto.html

COLOID


COLOID ist die Abk�rzung f�r Collection of LKMs for Intrusion Detection und wurde vor einiger Zeit von mir ins Leben gerufen.
Da sich herausgestellt hat, das Teile des Projekts uneffektiv und nicht "zeitgem��" arbeiteten, wurde das Projekt vor�bergehend beendet. Nichtsdestotrotz m�chte ich kurz auf urspr�nglich geplante Features eingehen : Das erste Modul (prev_exec) sollte u.a. die Ausf�hrung bestimmter Binaries (in meinem Source habe ich den Gnu C Compiler - GCC - genommen) zu bestimmten Zeiten verhindern. Es wird also im Source definiert wann die Ausf�hrung verboten sein soll, wobei m�glich ist auf Minuten genau den Zeitabschnitt anzugeben. F�hrt jetzt ein User GCC zu dieser Zeit aus, wird lediglich die Ausf�hrung 'geblockt', d.h. GCC wird nicht ausgef�hrt. Sollte der User GCC zur "erlaubten" Zeit ausf�hren werden die Argumente �berpr�ft und nach .c - Files durchsucht. Sinn u. Zweck des Ganzen ist es, den Source (den jemand kompilieren m�chte) nach "gef�hrlichen Funktionen" zu durchsuchen. Voreingestellt waren hierbei 'scanf' und 'strcpy' .... etc ..... , allerdings ist es auch m�glich weitere Funktionen...hinzuzuf�gen. Wie bereits gesagt durchsuchte nun das LKM den jeweiligen Source und sollte es auf eine der Funktionen treffen wurde die Ausf�hrung von GCC verhindert. Zus�tzlich wird in eine Logfile geschrieben und ein 'beep' erzeugt .


Das Modul funktionierte zwar soweit, allerdings war der Ansatz nicht umfassend genug und konnte leicht umgangen werden.

Das zweite Modul war 'anom_detection' , das die bereits erl�uterte Anomaly Detection verwendete. Eigentlich waren es zwei LKMs die zu diesem Bereich geh�ren :
1) Anomaly_Detection.c das die Datenbank normaler Useraktivit�ten erzeugt
und
2) Misuse_Detect.c das sp�ter (mit der Datenbank als "Fundament") kontrolliert ob das Verhalten der User von dem normalen (in der Datenbank protokollierten) Verhalten abweicht.

Geplant war, dass dieses LKM folgende Dinge "�berpr�ft":

Wie oft hat der User die folgenden Programme/Kommandos ausgef�hrt :

Wann hat er die folgenden Programme/Kommandos gestartet:

Bzw. wann hat er normalerweise den PC gestartet u. shutdown ausgef�hrt....
Sonstiges:
Wie oft hat er (versucht) die folgenden Dateien zu �ffnen:


Wie oft hat er Programme ausgef�hrt, bei denen das SUID-Bit gesetzt war ? ....
Aufpassen muss man hier nur bei der Spezifizierung welche Dateien man beobachten m�chte (wie oft er sie ge�ffnet hat). W�hlt man hier zu viele Dateien, so leidet die Rechnerperformance zu sehr, als dass ansatzweise vern�nftiges arbeiten am PC kaum m�glich w�re.

Es gab noch andere kleinere LKM's bei den noch kein kompletter Source verf�gbar war, der Source der beiden oben erw�hnten Module ist auf meiner Seite verf�gbar, vielleicht kann der ein oder andere ja noch was mit anfangen....


Abschlie�ende Worte

Solltet ihr noch irgendwelche Ideen zum Inhalt des Papers ... haben, schreibt mir bitte ne Mail: Socma(Q)gmx.net . F�r weitere Anregungen, Lob, Kritik.... k�nnt ihr mich nat�rlich auch anschreiben. Referenzen (neben denen, die bereits im Text erw�hnt wurden):
  1. http://online.securityfocus.com/infocus/1524
  2. http://online.securityfocus.com/infocus/1534
  3. http://online.securityfocus.com/infocus/1544
  4. http://online.securityfocus.com/infocus/1232
  5. http://www.entercept.com/products/entercept/whitepapers/ downloads/systemcall.pdf
  6. http://www.computec.ch/dokumente/intrusion_detection/ angriffsmoeglichkeiten_auf_okenas_stormwatch/ angriffsmoeglichkeiten_auf_okenas_stormwatch.doc