Intrusion Detection am Beispiel von Snort (Teil 3)
6.1.2 Die 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:
|
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:
| ||
| dsize | Number | Testet die Größe des Datensegments in einem Paket, damit lassen sich Buffer Overflows leichter identifizieren. Bereiche werden mit < und > definiert. |
| content | "|0f430a|" | Mit dieser Option wird ein Pattern Matching nach dem Boyer-Moore-Algorithmus im Datensegment durchgeführt. Der Match-String muß in " stehen. Es ist neben normalen Strings auch möglich, Bytecode anzugeben, dieser muß durch ein | am Anfang und Ende gekennzeichnet werden. |
| nocase | - | schaltet die Unterscheidung zwischen Groß- und Kleinschreibung beim Pattern Matching ab. |
| depth | Number | Gibt die Tiefe an, mit der die einzelnen Pakete beim Pattern Matching durchsucht werden sollen. |
| offset | Number | Definiert den Startpunkt des Pattern Matching. |
| seq | Number | Testet die Sequenznummer des Pakets. |
| ack | Number | Testet die Acknowledge-Nummer. |
| itype | Type | Testet das ICMP Type Field, wobei Type ein String ist. |
| icode | Number | Testet den numerischen Wert des ICMP Type Fields. |
| icmp_id | Number | Testet das ID Field in ICMP ECHO-Paketen. Diese Option wurde speziell für Stacheldraht-DDoS Attacken entwickelt. |
| icmp_seq | Number | Testet die Sequenznummer in ICMP ECHO-Paketen. |
| session | Extrahiert USER Data aus TCP-Sessions. | |
| all | Schreibt alle Zeichen | |
| printable | Schreibt nur druckbare Zeichen | |
| rcp | Number | Dekodiert Applikation, Prozedur und Version von Remote Procedure Calls. |
| resp | Flexible Responses erlauben Snort, die Verbindung zwischen den jeweiligen Systemen auf unterschiedliche Art zu beenden. | |
| rst_snd | Sendet TCP_RST zum sendenden Host. | |
| rst_rcv | Sendet TCP_RST zum empfangenden Host. | |
| rst_all | Sendet TCP_RST zu allen involvierten Hosts. | |
| icmp_net | Sendet ICMP_NET_UNREACH zum sendenden Host. | |
| icmp_host | Sendet ICMP_HOST_UNREACH zum sendenden Host. | |
| icmp_port | Sendet ICMP_PORT_UNREACH zum sendenden Host. | |
| icmp_all | Sendet alle der obigen ICMP_*_UNREACH zum sendenden Host. | |
Es ist einleuchtend, dass die Reihenfolge, in der die Regeln abgearbeitet werden, die Effizienz des IDS ungemein beeinflussen, sowohl positiv als auch negativ. Die Regeln werden nicht in der Reihenfolge verarbeitet, in der sie in der Wissensbasis aufgeführt sind, stattdessen werden generell Content Matching-Regeln zuletzt ausgeführt, da sie am rechenintensivsten sind. Durch geschicktes Schreiben der Regeln, in etwa das Überprüfen der Flags oder Paketgröße, lassen sich die Regeln, mit denen für ein Paket wirklich ein Content Matching durchgeführt wird, minimieren. Alle Regeln in einer Wissensbasis werden disjunktiv und die einzelnen Elemente einer Rule konjunktiv verknüpft und müssen sich als wahr erweisen, so dass diese Regel greift bzw. die angegebene Action ausgeführt wird.
