Channel Security

In dieser Folge wird die Umsetzung der Beispiele aus About Security #47 mit dem Intrusion-Detection-System Snort beschrieben. Snort ist ein netzwerkbasiertes Open-Source-Intrusion-Detection-System, das auch das Packet-Sniffing und Packet-Logging (Paketprotokollierung) beherrscht. Während beim Packet-Sniffing empfangene Pakete auf dem Bildschirm ausgegeben werden, werden sie beim Packet-Logging auf einem Laufwerk protokolliert. Beim Betrieb als Intrusion-Detection-System werden die empfangenen Pakete anhand vorgegebener Signaturen (bei Snort Regeln genannt) sortiert, bewertet und weiterverarbeitet. Ab Version 2.3.0 RC1 kann Snort im Inline-Modus betrieben werden. Dabei werden die Pakete von iptables übernommen und iptables durch Snort-Regeln unterstützt.

Snort-Regeln

Snort-Regeln sind textbasiert und werden, in Gruppen zusammengefasst, in einem Unterverzeichnis von Snort gespeichert. Zum Beispiel enthält die Datei web-php.rules die Regeln für Angriffe und Exploits für PHP-Anwendungen.

Eine Regel besteht aus zwei Teilen: dem Regel-Header und den Regel-Optionen. Ihr Aufbau soll an folgender Regel zur Erkennung des Heraufladens von PHP-Dateien (zweites Beispiel in About Security #47) erklärt werden:

Regel-Header:

 alert tcp  any ->  

Regel-Optionen:

 (msg:"WEB-PHP Forum upload.php Heraufladen einer PHP-Datei"; 
 flow:to_server,established; 
 uricontent:"/forum/upload.php"; content:"bild="; content:".php";
 reference:AboutSecurity47; 
 classtype:web-application-attack; 
 sid:1234567890; 
 rev:1;)

Bedeutung der Felder

Regel-Header:

alert

definiert das zu verwendende Ausgabeformat. Weitere Optionen sind z.B. log und pass.

tcp

definiert das zu verwendende Protokoll, in diesem Fall also TCP. Weitere Optionen sind IP, UDP und ICMP.

definiert die Quelladresse. wird in der Snort-Konfiguration definiert und standardmäßig auf any gesetzt.

any

definiert den Quell-Port, der in diesem Fall beliebig ist.

->

zeigt die Richtung der Kommunikation an, in diesem Fall von einem beliebigen Port eines Rechners aus dem externen Netz zu einem HTTP-Port eines lokalen HTTP-Servers.

definiert die Zieladresse(n), in diesem Fall die der HTTP-Server. Ebenso wie werden und in der Snort-Konfiguration definiert.

definiert den Ziel-Port, in diesem Fall die für HTTP genutzten Ports.

Regel-Optionen:

msg:

ist die durch den Alarm ausgegebene Meldung.

flow:to_server,established

definiert die Richtung der Kommunikation, und ob es sich um eine bestehende Verbindung handelt oder nicht.

uricontent:"/forum/upload.php"; content:"bild="; content:".php";

definiert, nach was Snort in den Paketen suchen soll:

• Nach der Zeichenkette /forum/upload.php wird nur im URI-Abschnitt gesucht, dies erspart die Suche in der Nutzlast der Pakete.
• Nach bild= und .php wird im gesamten Paket gesucht.

reference:AboutSecurity47;

verweist auf die für die Regel verwendeten Informationen.

classtype:web-application-attack;

Der classtype enthält eine Klassifizierung, um die Bedeutung des Angriffs einzuschätzen. Jeder Klassifizierung ist eine Standardpriorität zugeordnet: hoch, mittel oder niedrig.

sid:1234567890;

sid enthält die eindeutige Snort-Regel-ID zur Identifikation der Regel

rev:1;

rev enthält die Versionsnummer der Regel

Zur Erkennung des Pufferüberlaufs im POP3-Server (drittes Beispiel in About Security #47) muss nach dem Befehl USER gesucht werden, gefolgt von einem Parameter, der länger als 50 Zeichen ist. Dies übernimmt folgende Regel:

alert tcp  any ->  110 

(msg:"POP3 USER Pufferueberlauf"; 
flow:to_server,established; 
content:"USER"; nocase; isdataat:50,relative; 
reference:AboutSecurity,47;
classtype:attempted-admin;
sid:1234567891;
rev:1;)

Die bisher nicht beschriebenen Felder haben folgende Bedeutung:

sind die lokalen POP3-Server.

nocase;

weist Snort an, auf Groß- und Kleinschreibung nicht zu achten.

isdataat:50,relative;

prüft, ob Daten an einer bestimmten Stelle stehen. In diesem Fall (relative) relativ zum Ende des vorhergehenden Matches (d.h. hier: 50 Bytes nach dem Auftreten von USER). Zusätzlich kann über einen regulären Ausdruck (Schlüsselwort pcre:) die Art der gefundenen Daten geprüft werden.

Die Regel zur Erkennung des Diretory-Traversal-Angriffs (erstes Beispiel aus About Security #47) wird entsprechend gebildet. Wie genau, überlasse ich jedem Leser als kleine "Hausaufgabe". Die Lösung gibt es im Security-Forum.

Bei Bedarf kann in einer späteren Folge ausführlicher auf Snort und seine Regeln eingegangen werden. In der nächsten Folge geht es um eine Erweiterung der Intrusion-Detection-Systeme: Intrusion-Prevention-Systeme.

Carsten Eilers

About Security – Übersicht zum aktuellen Thema "Intrusion Detection und Prevention Systeme"

• About Security #42: Intrusion-Detection-Systeme – Grundlagen
• About Security #43: Intrusion-Detection-Systeme – Positionierung
• About Security #44: IDS-Kommunikation
• About Security #45: IDS in hochverfügbaren Netzen
• About Security #46: Angriffe auf IDS
• About Security #47: Beispiele für IDS-Regeln
• About Security #48: Umsetzung der IDS-Beispiele mit Snort
• About Security #49: Intrusion Prevention