Login


 
Newsletter
Werbung

Fr, 14. Dezember 2001, 00:00

Intrusion Detection am Beispiel von Snort (Teil 3)

Da Snort in erster Linie ein regelbasiertes IDS ist, benötigt es eine Art Wissensbasis, eine »Datenbank«, in der die sogenannten Signaturen definiert sind. Als Signaturen werden in diesem Kontext die Charakteristika eines Pakets bezeichnet, die dieses Paket und seine Eigenschaften (z.B. Flags, Source- und Destination-Port und/oder -IP-Adresse) oder 'bösartig' definieren. Ohne eine solche Wissensbasis ist Snort quasi blind, es kann zwar die Pakete von der Netzwerkkarte dekodieren, weiß aber nicht, welche dieser Pakete erwünscht sind und welche nicht.

6Die Konfiguration von Snort

Wie sieht nun eine solche Wissensbasis aus? Die Wissensbasis ist eine einfache Textdatei, das sich aus Regeln19 (im folgenden auch rules genannt) zusammensetzt, anhand derer Snort weiß, wie es mit den einzelnen Paketen zu verfahren hat. Wie wir sehen, dreht sich bei der Konfiguration von Snort alles um solche Regeln. Betrachten wir nun den Aufbau und die Funktionsweise solcher rules.

6.1Aufbau einer Rule

Eine Regel setzt sich aus zwei Teilen zusammen, dem sogenannten rule header und den rule options. Da Snort nicht mit Zeilenumbrüchen innerhalb der rules umgehen kann, ist es enorm wichtig, folgendes zu beachten:

Regeln müssen immer in einer Zeile stehen!

Snort beendet sich andernfalls mit einer entsprechenden Fehlermeldung und verweigert die Arbeit.

6.1.1Der Rule Header

Der Rule Header definiert, was geschehen soll, wenn eine bestimmte Signatur in einem Paket gefunden wird und trifft eine grobe Vorauswahl über Protokoll, IP-Adresse und Portnummer:

alert
action


TCP

protocol


any any

Source IP-AddressPort


->

direction

!192.168.0.0/24 :1024

Destination IP-Address Port
action
hier stehen folgende Optionen zur Verfügung: Alarmieren (alert), Protokollieren (log) und Ignorieren (pass). Es können auch eigene actions definiert werden (siehe 6.2.2).
protocol
definiert, welches Protokoll beobachtet werden soll; zur Zeit werden die 3 gängigsten Protokolle TCP, UDP und ICMP unterstützt.
Portnumber & IP-Address
Zuerst wird die Source IP-Adresse in CIDR20-Notation angegeben, das (!) dient hier als Negationsoperator und definiert so alle IP-Adressen, die nicht 192.168.0.0/24 entsprechen. Als Portnummer kann jede Zahl zwischen 1 und 65535 gewählt werden, Bereiche werden mit dem (:)-Operator gekennzeichnet (hier alle Ports über 1024).(any) definiert alle gültigen Werte für Port und/oder IP-Adresse. Nach dem direction-Operator wird noch die Destination IP-Adresse und Portnummer angegeben.
direction
Der direction-Operator legt die Richtung des Traffics fest; unidirektional (->) oder bidirektional (<>)

Sicherlich läßt sich über den Sinn und Unsinn des oben aufgeführten rule headers streiten, doch er soll hier nur als Beispiel und Veranschaulichung der diversen Operatoren dienen. Mit dem rule header bekommt Snort schon einen guten Einblick in die Wünsche des Netzwerkadministrators, doch die eigentlichen Gefahren entgehen Snort, hierfür ist ein Blick in die jeweils spezifischen Details der einzelnen Pakete notwendig (Data Segment, Flags).

6.1.2Die Rule Options

Die rule options lassen feinere Abstufungen bei der Überwachung des Netzwerks und bei der Angriffserkennung zu. Mit ihnen wird definiert, was genau in einem Paket als verdächtig gilt, abgesehen von seinem Ursprungs- und Zielort. Die rule options schließen sich dem rule header an und werden durch (() und ()) zusammengefasst. Die einzelnen Optionen bestehen immer aus Schlüsselwort und Wertepaaren, die voneinander mit (;) getrennt sind. Die verschiedenen Optionen hängen stark von dem zuvor im rule header spezifizierten Protokoll ab, hier ein Beispiel:

(

msg

keyword


:

separator


Log Message

value


;

separator
...

flags: SA+;

optionn
)

keyword Das Schlüsselwort beschreibt, nach welchem Kriterium gesucht werden soll.

(:) Trennt Schlüsselwort und Wert.

value definiert den Wert, den ein mit keyword angegebenes Kriterium aufweisen muss.

(;) Trennt die einzelnen Schlüsselwort-Wertepaare voneinander.

Die rule options funktionieren alle nach demselben oben gezeigten Prinzip. Alle Optionen detailliert zu erklären würde den Rahmen diese Dokuments sprengen, deshalb soll hier lediglich eine kurze Übersicht die grundlegende Bedeutung jeder einzelnen erklären. Für eine ausführliche Beschreibung sei auf [12] und [22] verwiesen.

Keyword Value Beschreibung
msg "Log Message" schreibt den in Anführungszeichen angegebenen String in die Logs
logto FileName definiert eine Datei, in die Pakete, die diese rule matchen, geloggt werden sollen.
ttl 0 - 255 testet den Wert des Time To Live Fields im IP-Header
tos Number testet den Wert des Type Of Service Fields
id Number überprüft das ID field eines IP-Pakets
ipopts es ist nur eine der Optionen pro Regel erlaubt!
rr Record Route
eol End Of List
nop No Operation
ts Time Stamp
sec IP Security Option
lsrr Loose Source Code Routing
ssrr Strict Source Code Routing
satid Stream Identifier
eol End Of List
fragbits RB Reserved Bit
DF Don't Fragment
MF More Fragments
flags FB FIN
S SYN
R RST
P PSH
A ACK
1 Reserved Bit 1
2 Reserved Bit 2

Um fragbits & flags besser matchen zu können, stehen folgende Operatoren bereit:

Kommentare (Insgesamt: 0 || Kommentieren )
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung