<strong>+</strong> matched alle angegebenen Flags plus beliebige andere.
<strong>*</strong> matched mindestens eines der definierten Flags.
<strong>!</strong> ist der schon bekannte Negationsoperator und matched,
wenn die spezifizierten Flags <em>nicht</em> gesetzt sind.

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.

6.2Weiterführende Konfiguration

Regeln sind allerdings nicht die einzigen Hilfsmittel, auf die Snort und der Netzwerkadministrator zurückgreifen können, um einem Eindringling auf die Spur zu kommen.

6.2.1Preprocessors

Neben diesen umfangreichen Möglichkeiten zur Angriffserkennung stehen Snort noch weitere Konfigurationsoptionen zur Verfügung, die eine Anpassung an die eigenen Bedürfnisse erleichtern. Eines der wohl besten Features ist die Plugin-Schnittstelle (siehe Abschnitt 3.1), die Snort bietet. Dies ist User-Code, der von Snort zwar nach der Paketdekodierung, jedoch vor dem rule matching ausgeführt wird. Es sind schon einige sogenannte Präprozessoren geschrieben worden, unter anderem Spade, welches in Abschnitt ?? etwas näher beschrieben wurde, und die Liste der erhältlichen Plugins verlängert sich ständig. Einige der im Moment zur Verfügung stehenden preprocessors sollen im folgenden erläutert werden:

minfrag <Threshold>

untersucht fragmentierte Pakete auf einen Schwellwert; kein Rechner sollte Pakete kleiner als 512 Bytes erzeugen, das heißt, wenn wir kleinere Pakete in unserem Netz vorfinden, könnte dies ein Indiz für einen Angriffsversuch sein, der mittels Miniaturpaketen versteckt werden soll.

defrag

ist eine Weiterentwicklung von minfrag und erlaubt Snort eine vollständige Defragmentierung von IP.

stream: timeout <Timeout>, ports <Ports>, maxbytes <Number>

erlaubt Snort die Reassemblierung von TCP-Streams, die jeweiligen Parameter legen den Timeout in Sekunden, die Ports, auf denen die Stream-Reassembly vorgenommen werden soll, und die maximale Größe der von Snort rekonstruierten Pakete fest.

http_decode <Port_numbers>

dekodiert den URL-encodierten Datenstrom in einen reinen ASCII-Datenstrom auf den angegebenen Ports. Dies ist für die Erkennung von CGI-Attacken sehr hilfreich.

portscan: <Network> <Number_of_Ports> <Detection_Period> <Logdir/Filename>

überwacht das definierte Netzwerk auf Portscans, wobei mit <Number_of_Ports> angegeben wird, wieviele Ports in welcher Zeit 'gescannt' werden müssen, bevor dieses Plugin seine Daten in das angegebene Logfile schreibt.

portscan-ignorehosts: <Host_List>

Die Liste der hier angegebenen Host-IP-Adressen läßt Portscans von diesen Hosts zu, es ist eventuell erwünscht, die Rechner im eigenen Netz von Zeit zu Zeit einem Portscan zu unterziehen, da sich so eventuell ein Port entdecken läßt, der von einem bisher unbemerkten Angreifer für seine Zwecke geöffnet wurde. Ursprünglich wurde dieser Präprozessor geschrieben, weil Snort den DNS-Traffic von BIND 8 als Portscan interpretierte.

spade

erweitert die Fähigkeiten von Snort um eine statistische Analyse, mit der Snort nicht mehr allein von den Signaturen abhängig ist. Da sich der Code noch im Betastadium befindet, ist von einer Benutzung in sicherheitskritischen Netzwerken abzuraten. Eine ausführliche Dokumentation ist in der Sourcecode-Distribution von Snort enthalten.