Snort ist ein sehr populäres Intrusion-Detection-System für Windows- und Linux-Systeme. Das Tool ist vielfältig und bietet nahezu alle Funktionen, die der Nutzer zum Aufspüren von Einbrechern benötigt.
Der in
Wie bereits erwähnt, ist ein wesentliches Feature von Snort der integrierte Sniffer. Diese Komponente ist ausgezeichnet zur Analyse des Traffics geeignet und stellt auch eine große Hilfe bei der Netzwerkprogrammierung dar. Unter Linux- und BSD-Systemen ebenfalls sehr gut geeignet sind TCPDump und
Interessant am Snort-Sniffer ist, dass das Tool mittels des Parameters "-v" dazu gebracht werden kann, die im Linklayer empfangenen Pakete auszugeben. Mit dem Parameter "–i" geben Sie die Schnittstelle an, auf der gesnifft werden soll. Zum Beispiel
linux# snort -v -i lo
Die Snort-Variablen
Die Hauptaufgabe von Snort ist aber die Intrusion Detection. Legen Sie zunächst das Logverzeichnis "/var/log/snort" an, und verschieben Sie dann die im Unterverzeichnis "etc/" mitgelieferte Konfigurationsdatei nach "/etc/snort.conf".
# mkdir /var/log/snort
# cp etc/snort.conf /etc/
Ratsam ist es, zunächst einmal einen Blick auf den Aufbau der Konfigurationsdatei zu werfen, um sich mit der grundlegenden Syntax vertraut zu machen. Kommentare werden – wie auch in Shell-Scripts – mit einer Raute eingeleitet.
Zudem können, ähnlich wie in C, C++ oder Makefiles, weitere Dateien eingebunden, also »inkludiert« werden. Bei Snort wird das Schlüsselwort "include:" plus der entsprechenden Pfadangabe verwendet. Auch das Erstellen von Variablen ist möglich. Dazu verwenden Sie das var, etwa
var ROUTER 192.168.0.2
In den Regeldateien sprechen Sie Variablen mittels "$<Variable>", also etwa mit "$ROUTER", an. Die Variable "HOME_NET" wird zur Angabe des Inhouse-Netzes verwendet, wogegen "EXTERNAL_NET" für die Gegenseite steht. Dies stellt sicher, dass sich die Konfiguration problemlos auf einem Gateway nutzen lässt.
Es folgen die Variablen zur Angabe der Dienste des Netzwerkes, also beispielsweise die Variable "SMTP_SERVERS" für die Liste der Mailserver im Netz oder "TELNET_SERVERS" für die Telnet-Server. Darauf folgen Portangaben und spezielle Variablen, etwa "AIM_SERVERS" zur Angabe der Server für den Instant-Messenger.
An diesem Beispiel ist sehr gut zu erkennen, dass die Separierung von Werten mittels Kommata erfolgt und die Verwendung von Netzklassen durch Angabe der Net-ID-Bits hinter einem Slash festgelegt wird:
var AIM_SERVERS [64.12.24.0/24,
64.12.25.0/24,64.12.26.14/24,
64.12.28.0/24,64.12.29.0/24,
64.12.161.0/24,64.12.163.0/24,
205.188.5.0/24,205.188.9.0/24]
Wie der Kommentar zur Angabe des Pfades der Regeldateien verrät, ist es möglich, diesen als relativen Pfad anzugeben. Doch auch eine absolute Pfadangabe ist hierbei problemlos möglich:
var RULE_PATH /etc/snort/rules
Hinweis: Dieser Artikel bezieht sich auf eine etwas ältere Version von Snort.
Das Schlüsselwort config
Das config-Schlüsselwort erlaubt es Ihnen, das Verhalten von Snort zu konfigurieren. Um sich selbst ein Bild davon zu machen, sollten Sie die Konfigurationsdatei analysieren. Als Erstes werden Sie mit dem "decoder"-Bereich des NIDS (Network Intrusion Detection System) konfrontiert. Sie sehen, dass das config-Schlüsselwort stets an erster Stelle steht. Anschließend wird ein Parameter übergeben, mit dem die eigentliche Aktion bestimmt wird. Optional können auch Parameter übergeben werden. Beim Listing ist zu beachten, dass zur Aktivierung der beschriebenen config-Operationen die Auskommentierung erfolgen muss.
# Stop generic decode events:
#
# config disable_decode_alerts
#
# Stop Alerts on experimental TCP options
#
# config disable_tcpopt_experimental_alerts
#
# Stop Alerts on obsolete TCP options
#
# config disable_tcpopt_obsolete_alerts
#
# Stop Alerts on T/TCP alerts
#
# config disable_tcpopt_ttcp_alerts
#
# Stop Alerts on all other TCPOption type events:
#
# config disable_tcpopt_alerts
#
# Stop Alerts on invalid ip options
#
# config disable_ipopt_alerts
Nachfolgend sollen die oben aufgelisteten sowie die wichtigsten nicht aufgelisteten Parameter besprochen werden:
– "disable_decode_alerts" stellt die Meldungen des Decoders ab.
– "disable_tcpopt_experimental_alerts" gibt keine Warnungen beim Eintreffen von TCP-Paketen mit experimentellen Optionen aus.
– "disable_tcpopt_obsolete_alerts" gibt keine Warnungen beim Eintreffen von TCP-Paketen mit veralteten Optionen aus.
– "disable_tcpopt_ttcp_alerts" warnt beim Eintreffen von TCP-Paketen.
– "disable_tcpopt_alerts" stellt generell alle Warnungen ab, die durch TCP-Optionen hervorgerufen werden.
– "disable_ipopt_alerts" gibt keine Warnungen aus, wenn IP-Pakete mit abnormalen Optionen gefunden werden.
– "set_gid" ändert die Gruppen-ID, unter der Snort läuft, auf die angegebene. "set_uid" erfüllt die gleiche Funktionalität bezüglich der User-ID.
– "daemon" versetzt Snort in den Daemon-Modus, womit das Programm als Hintergrundprozess läuft.
– "interface" legt das Interface fest, etwa "config interface:eth1".
– "logdir" spezifiziert das Verzeichnis, in dem die Logdateien gespeichert werden. Dieses Verzeichnis kann sehr groß werden. In der Regel wird der Ordner "/var/log/snort" verwendet, daher sollten Sie immer darauf achten, dass der "/var"-Partition genügend Speicherplatz zur Verfügung steht.
– "umask" legt unter Unix die umask-Werte zur Erstellung neuer Dateien fest.
– "no_promisc" setzt das Netzwerk-Interface, auf dem Snort agiert, nicht in den Promiscuous-Modus. In der Regel ist diese Option nicht von Bedeutung.
– "chroot" funktioniert zumindest unter Unix und legt mit Hilfe des chroot(2)-Syscalls ein neues Wurzelverzeichnis für Snort fest. Dies erschwert Angriffe auf Snort und findet auch bei anderen Diensten, etwa dem Apache-Webserver und Bind unter OpenBSD, Verwendung.
– "checksum_mode" legt die Überprüfung der Prüfsummen fest. Mit notcp können beispielsweise die Berechnungen der Prüfsummen von TCP-Paketen unterbunden werden. Auf langsamen Maschinen kann das Abstellen der Checksum-Prüfung ("none") eine kleine Steigerung der Performance mit sich bringen.
Das Schlüsselwort preprocessor
Die Einführung der preprocessor-Extensions ermöglichte es Entwicklern, Snort um zusätzliche Module zu erweitern. So wurde beispielsweise ein Portscan-Detection-Modul entwickelt, das über die Anweisung "preprocessor" in Snort Verwendung findet. Mith Hilfe der Funktion "Portscan Detection" lässt sich bestimmen, wie viele TCP- und UDP-Ports eine Quelle innerhalb welcher Zeit anfragen muss, um als Portscan erkannt zu werden. Dabei erkennt die Routine auch spezielle Techniken wie X-Mas-, NULL-, FIN- und Stealth-Scan. Die preprocessor-Anweisung aktiviert diese Funktionalität folgendermaßen:
Das erste Argument ist die Angabe des zu überwachenden Netzwerks. Danach folgt die Anzahl der Ports, die in der an der dritten Stelle festgelegten Zeit vom Angreifer gescannt werden müssen. Die Zeitspanne wird dabei in Sekunden angegeben. Der letzte Parameter legt die Logdatei fest, in der die Protokollierung Portscans ablegen soll. Diese Informationen werden auch in die alert-Datei von snort geschrieben:
# Form
preprocessor portscan: <Netzwerk> <Anzahl der Ports> <Zeitlimit> <Logdatei>
# Beispielsweise
preprocessor portscan: 10.34.53.0/24 5 10 /var/log/snort/scans
In diesem Beispiel muss ein Angreifer innerhalb von 10 Sekunden einen Bereich von mindestens fünf Ports scannen, bevor die Aktivität als Portscan eingestuft wird. Problematisch ist im Zusammenhang mit der Zeit, dass einige Tools Portbereiche absichtlich äußerst langsam scannen. Dies dauert zwar länger, ist aber auf obige Art und Weise sehr schwer zu entdecken.
Mit der Anweisung »portscan-ignorehosts« lassen sich aus einer Portscan-Liste Hosts gezielt austragen, so dass keine Benachrichtigung bei TCP-SYN- oder UDP-Portscans erfolgt.
preprocessor portscan-ignorehosts: 192.168.0.3
Dem interessierten Administrator bietet Snort noch einige weitere Module für die preprocessor-Anweisung, etwa stream4, flow (flow-port-scan), telnet_decode, rpc_decode, den Performance-Monitor oder auch http_inspect.
Das Schlüsselwort output
Mittels des Schlüsselwortes output ist es möglich, die von Snort protokollierten Meldungen weiterzuverarbeiten. Beispielsweise lassen sie sich via syslog oder in Form einer binären Datei im tcpdump-Format aufzeichnen. Zudem können die Meldungen in Datenbanken geschrieben werden.
output database: log, mysql, user=admin password=pass dbname=snort host=eygosun
Wie der im Listing enthaltene Ausdruck mysql zeigt, ist es möglich, Snort auf verschiedenste Datenbanken zugreifen zu lassen. Derzeit werden unter anderem Oracle, MySQL und PostgreSQL unterstützt.
Weitere Infos zur Nutzung dieser Datenbankanbindung finden Sie in der im Snort-tarball enthaltenen Dokumentationsdatei README.database im Verzeichnis "doc".
Aufbau der Snort-Regeln
Sehr wichtig ist natürlich die Erstellung von Snort-Regeln. Ein Blick in die mitgelieferte Konfiguration verrät, wo die Regeldateien liegen und wie diese übersichtlich und komfortabel in die snort.conf eingebunden werden können. Die entsprechenden Dateien finden sich im Unterverzeichnis rules. Jeder Administrator sollte diese Regeldateien analysieren, um sich mit den grundlegenden Techniken vertraut zu machen. Ideal ist es, wenn Sie sich die Inhalte anhand von Beispielen verdeutlichen.
In der Datei shellcode.rules finden Sie beispielsweise die Regeln zur Erkennung von im Netzwerk übertragenen Shellcodes für verschiedenste Plattformen. Solche Shellcodes dienen dem Angreifer zum Starten von Programmen über Netzwerkverbindungen. Jedoch ist es entgegen der weit verbreiteten Meinung nicht notwendig, eine Shell zu starten. Dem Angreifer ist es im Prinzip selbst überlassen, welchen Code er ausführen möchte.
alert ip $EXTERNAL_NET $SHELLCODE
PORTS ->
$HOME_NET any (msg:"SHELLCODE sparc
setuid 0";
content:"|82 10| |17 91 D0| |08|";
reference:arachnids,282;
classtype:system-call-detect;
sid:647; rev:6
alert ip $EXTERNAL_NET $SHELLCODE
PORTS ->
$HOME_NET any (msg:"SHELLCODE x86
setgid 0";
content:"|B0 B5 CD 80|"; reference
arachnids,284;
classtype:system-call-detect;
sid:649; rev:8
alert ip $EXTERNAL_NET $SHELLCODE
PORTS ->
$HOME_NET any (msg:"SHELLCODE x86
setuid 0";
content:"|B0 17 CD 80|"; reference
arachnids,436;
classtype:system-call-detect;
sid:650; rev:8
Wie das Listing zeigt, steht am Anfang stets ein Regelwort. Mit dem Kommando "alert" lassen sich Warnungen ausgeben und Pakete loggen. Der Befehl "log" ist für die Protokollierung der jeweiligen Pakete zuständig, mit "pass" weisen Sie das Tool an, bestimmte Pakete zu ignorieren. Der Befehl "activate" bewirkt im Grunde das Gleiche wie "alert", es kommt zusätzlich aber eine dynamische Regel zur Verwendung.
All diese Schlüsselwörter haben verschiedene Verhaltensweisen. Zudem können eigene Regelwörter in der Konfigurationsdatei spezifiziert werden.
In der mitgelieferten Konfigurationsdatei ist folgendes Beispiel zu finden, das die Arbeitsweise erklären hilft:
ruletype redalert
{
type alert
output alert_syslog: LOG_AUTH LOG_ALERT
output database: log, mysql,
user=snort
dbname=snort
host=localhost
}
Der Regeltyp redalert verhält sich in diesem Fall wie alert und loggt mit Hilfe des syslog-Daemons und der MySQL-Datenbank die mit ihm konfigurierten Meldungen.
Darauf folgt das Protokoll, im obigen Fall ist dies ip. Shellcodes können sowohl über TCP als auch über andere Protokolle übermittelt werden. Durch Angabe von ip spielt dies keine Rolle, da jedes IP-Paket auf einen bestimmten Content untersucht werden kann. Selbstverständlich können Sie an dieser Stelle auch andere Protokolle, beispielsweise tcp, angeben
. Angabe von Quelle und Ziel
Die Angabe einer Netzwerkadresse und eines Ports in Bezug auf die Quelle des Paketes mit anschließender Angabe der Destination erfolgt vor beziehungsweise nach dem Pfeil. Dabei steht "any" immer für einen beliebigen Wert.
msge, content und reference:
– "msg" gibt die Logmeldung aus, "content" legt die Werte, die im Paket enthalten sein müssen, fest, wobei entweder auf in Pipes gestellte Hex-Werte oder auch direkt auf ASCII-Zeichen, also beispielsweise "HEAD / HTTP/1.0", zurückgegriffen werden kann.
Referenzen bieten Ihnen die Möglichkeit, sich über eine Angriffsform zu informieren. Diese Referenzen werden explizit in den Logmeldungen, in der Regel durch Links zu den Problembeschreibungen in Bugtraq ausgegeben.
– "classtype" spezifiziert die Priorität der Regel, wobei zahlreiche Angaben mit verschiedenen Zwecken und der Priorität "high", "medium" oder "low" existieren. Diese Angaben sind in einer recht langen Tabelle im Snort-Manual zu finden.
– "sid" spezifiziert einen Eintrag in der so genannten Snort Signature Database (SID), die im Internet auf
Es gelten auch hier wieder einige Besonderheiten bei der Erstellung der Regeln. Die wichtigsten sind: Ausrufezeichen haben eine logische Verneinung zur Folge. Wenn also alle Pakete mit einer IP-Adressangabe außer "192.168.0.1" auf eine Regel zutreffen sollen, können Sie Folgendes schreiben:
!192.168.0.1.
Gruppierungen werden durch eckige Klammern gebildet. Die Separierung von Werten erfolgt durch Kommata. Strings werden in Anführungszeichen eingeschlossen. Zeilenumbrüche können über einen Backslash ("\") realisiert werden. Weitere ausführliche Informationen zu diesem Thema finden Sie in der Datei README.alert_order.
[FONT="]Dieser Artikel stammt auszugsweise aus Linux – Das distributionsunabhängige Handbuch[/FONT]
Der in
Du musst dich
Anmelden
oder
Registrieren
um diesen link zusehen!
integrierte Sniffer-Code ermöglicht Fehlerdiagnose und Überwachung des Netzwerkes bei der Netzwerkprogrammierung und Netzwerkadministration. Der Netzwerk-Traffic lässt sich auf der Basis von Regelwerken überwachen. Die integrierte Logging-Funktion sorgt dafür, dass keine Informationen verlorengehen. Da das Snort-Paket Bestandteil fast aller gängigen Distributionen und Derivate ist, gehen wir an dieser Stelle nicht näher auf manuelle Installation ein. Wie bereits erwähnt, ist ein wesentliches Feature von Snort der integrierte Sniffer. Diese Komponente ist ausgezeichnet zur Analyse des Traffics geeignet und stellt auch eine große Hilfe bei der Netzwerkprogrammierung dar. Unter Linux- und BSD-Systemen ebenfalls sehr gut geeignet sind TCPDump und
Du musst dich
Anmelden
oder
Registrieren
um diesen link zusehen!
(ehemals Ethereal).Interessant am Snort-Sniffer ist, dass das Tool mittels des Parameters "-v" dazu gebracht werden kann, die im Linklayer empfangenen Pakete auszugeben. Mit dem Parameter "–i" geben Sie die Schnittstelle an, auf der gesnifft werden soll. Zum Beispiel
linux# snort -v -i lo
Die Snort-Variablen
Die Hauptaufgabe von Snort ist aber die Intrusion Detection. Legen Sie zunächst das Logverzeichnis "/var/log/snort" an, und verschieben Sie dann die im Unterverzeichnis "etc/" mitgelieferte Konfigurationsdatei nach "/etc/snort.conf".
# mkdir /var/log/snort
# cp etc/snort.conf /etc/
Ratsam ist es, zunächst einmal einen Blick auf den Aufbau der Konfigurationsdatei zu werfen, um sich mit der grundlegenden Syntax vertraut zu machen. Kommentare werden – wie auch in Shell-Scripts – mit einer Raute eingeleitet.
Zudem können, ähnlich wie in C, C++ oder Makefiles, weitere Dateien eingebunden, also »inkludiert« werden. Bei Snort wird das Schlüsselwort "include:" plus der entsprechenden Pfadangabe verwendet. Auch das Erstellen von Variablen ist möglich. Dazu verwenden Sie das var, etwa
var ROUTER 192.168.0.2
In den Regeldateien sprechen Sie Variablen mittels "$<Variable>", also etwa mit "$ROUTER", an. Die Variable "HOME_NET" wird zur Angabe des Inhouse-Netzes verwendet, wogegen "EXTERNAL_NET" für die Gegenseite steht. Dies stellt sicher, dass sich die Konfiguration problemlos auf einem Gateway nutzen lässt.
Es folgen die Variablen zur Angabe der Dienste des Netzwerkes, also beispielsweise die Variable "SMTP_SERVERS" für die Liste der Mailserver im Netz oder "TELNET_SERVERS" für die Telnet-Server. Darauf folgen Portangaben und spezielle Variablen, etwa "AIM_SERVERS" zur Angabe der Server für den Instant-Messenger.
An diesem Beispiel ist sehr gut zu erkennen, dass die Separierung von Werten mittels Kommata erfolgt und die Verwendung von Netzklassen durch Angabe der Net-ID-Bits hinter einem Slash festgelegt wird:
var AIM_SERVERS [64.12.24.0/24,
64.12.25.0/24,64.12.26.14/24,
64.12.28.0/24,64.12.29.0/24,
64.12.161.0/24,64.12.163.0/24,
205.188.5.0/24,205.188.9.0/24]
Wie der Kommentar zur Angabe des Pfades der Regeldateien verrät, ist es möglich, diesen als relativen Pfad anzugeben. Doch auch eine absolute Pfadangabe ist hierbei problemlos möglich:
var RULE_PATH /etc/snort/rules
Hinweis: Dieser Artikel bezieht sich auf eine etwas ältere Version von Snort.
Das Schlüsselwort config
Das config-Schlüsselwort erlaubt es Ihnen, das Verhalten von Snort zu konfigurieren. Um sich selbst ein Bild davon zu machen, sollten Sie die Konfigurationsdatei analysieren. Als Erstes werden Sie mit dem "decoder"-Bereich des NIDS (Network Intrusion Detection System) konfrontiert. Sie sehen, dass das config-Schlüsselwort stets an erster Stelle steht. Anschließend wird ein Parameter übergeben, mit dem die eigentliche Aktion bestimmt wird. Optional können auch Parameter übergeben werden. Beim Listing ist zu beachten, dass zur Aktivierung der beschriebenen config-Operationen die Auskommentierung erfolgen muss.
# Stop generic decode events:
#
# config disable_decode_alerts
#
# Stop Alerts on experimental TCP options
#
# config disable_tcpopt_experimental_alerts
#
# Stop Alerts on obsolete TCP options
#
# config disable_tcpopt_obsolete_alerts
#
# Stop Alerts on T/TCP alerts
#
# config disable_tcpopt_ttcp_alerts
#
# Stop Alerts on all other TCPOption type events:
#
# config disable_tcpopt_alerts
#
# Stop Alerts on invalid ip options
#
# config disable_ipopt_alerts
Nachfolgend sollen die oben aufgelisteten sowie die wichtigsten nicht aufgelisteten Parameter besprochen werden:
– "disable_decode_alerts" stellt die Meldungen des Decoders ab.
– "disable_tcpopt_experimental_alerts" gibt keine Warnungen beim Eintreffen von TCP-Paketen mit experimentellen Optionen aus.
– "disable_tcpopt_obsolete_alerts" gibt keine Warnungen beim Eintreffen von TCP-Paketen mit veralteten Optionen aus.
– "disable_tcpopt_ttcp_alerts" warnt beim Eintreffen von TCP-Paketen.
– "disable_tcpopt_alerts" stellt generell alle Warnungen ab, die durch TCP-Optionen hervorgerufen werden.
– "disable_ipopt_alerts" gibt keine Warnungen aus, wenn IP-Pakete mit abnormalen Optionen gefunden werden.
– "set_gid" ändert die Gruppen-ID, unter der Snort läuft, auf die angegebene. "set_uid" erfüllt die gleiche Funktionalität bezüglich der User-ID.
– "daemon" versetzt Snort in den Daemon-Modus, womit das Programm als Hintergrundprozess läuft.
– "interface" legt das Interface fest, etwa "config interface:eth1".
– "logdir" spezifiziert das Verzeichnis, in dem die Logdateien gespeichert werden. Dieses Verzeichnis kann sehr groß werden. In der Regel wird der Ordner "/var/log/snort" verwendet, daher sollten Sie immer darauf achten, dass der "/var"-Partition genügend Speicherplatz zur Verfügung steht.
– "umask" legt unter Unix die umask-Werte zur Erstellung neuer Dateien fest.
– "no_promisc" setzt das Netzwerk-Interface, auf dem Snort agiert, nicht in den Promiscuous-Modus. In der Regel ist diese Option nicht von Bedeutung.
– "chroot" funktioniert zumindest unter Unix und legt mit Hilfe des chroot(2)-Syscalls ein neues Wurzelverzeichnis für Snort fest. Dies erschwert Angriffe auf Snort und findet auch bei anderen Diensten, etwa dem Apache-Webserver und Bind unter OpenBSD, Verwendung.
– "checksum_mode" legt die Überprüfung der Prüfsummen fest. Mit notcp können beispielsweise die Berechnungen der Prüfsummen von TCP-Paketen unterbunden werden. Auf langsamen Maschinen kann das Abstellen der Checksum-Prüfung ("none") eine kleine Steigerung der Performance mit sich bringen.
Das Schlüsselwort preprocessor
Die Einführung der preprocessor-Extensions ermöglichte es Entwicklern, Snort um zusätzliche Module zu erweitern. So wurde beispielsweise ein Portscan-Detection-Modul entwickelt, das über die Anweisung "preprocessor" in Snort Verwendung findet. Mith Hilfe der Funktion "Portscan Detection" lässt sich bestimmen, wie viele TCP- und UDP-Ports eine Quelle innerhalb welcher Zeit anfragen muss, um als Portscan erkannt zu werden. Dabei erkennt die Routine auch spezielle Techniken wie X-Mas-, NULL-, FIN- und Stealth-Scan. Die preprocessor-Anweisung aktiviert diese Funktionalität folgendermaßen:
Das erste Argument ist die Angabe des zu überwachenden Netzwerks. Danach folgt die Anzahl der Ports, die in der an der dritten Stelle festgelegten Zeit vom Angreifer gescannt werden müssen. Die Zeitspanne wird dabei in Sekunden angegeben. Der letzte Parameter legt die Logdatei fest, in der die Protokollierung Portscans ablegen soll. Diese Informationen werden auch in die alert-Datei von snort geschrieben:
# Form
preprocessor portscan: <Netzwerk> <Anzahl der Ports> <Zeitlimit> <Logdatei>
# Beispielsweise
preprocessor portscan: 10.34.53.0/24 5 10 /var/log/snort/scans
In diesem Beispiel muss ein Angreifer innerhalb von 10 Sekunden einen Bereich von mindestens fünf Ports scannen, bevor die Aktivität als Portscan eingestuft wird. Problematisch ist im Zusammenhang mit der Zeit, dass einige Tools Portbereiche absichtlich äußerst langsam scannen. Dies dauert zwar länger, ist aber auf obige Art und Weise sehr schwer zu entdecken.
Mit der Anweisung »portscan-ignorehosts« lassen sich aus einer Portscan-Liste Hosts gezielt austragen, so dass keine Benachrichtigung bei TCP-SYN- oder UDP-Portscans erfolgt.
preprocessor portscan-ignorehosts: 192.168.0.3
Dem interessierten Administrator bietet Snort noch einige weitere Module für die preprocessor-Anweisung, etwa stream4, flow (flow-port-scan), telnet_decode, rpc_decode, den Performance-Monitor oder auch http_inspect.
Das Schlüsselwort output
Mittels des Schlüsselwortes output ist es möglich, die von Snort protokollierten Meldungen weiterzuverarbeiten. Beispielsweise lassen sie sich via syslog oder in Form einer binären Datei im tcpdump-Format aufzeichnen. Zudem können die Meldungen in Datenbanken geschrieben werden.
output database: log, mysql, user=admin password=pass dbname=snort host=eygosun
Wie der im Listing enthaltene Ausdruck mysql zeigt, ist es möglich, Snort auf verschiedenste Datenbanken zugreifen zu lassen. Derzeit werden unter anderem Oracle, MySQL und PostgreSQL unterstützt.
Weitere Infos zur Nutzung dieser Datenbankanbindung finden Sie in der im Snort-tarball enthaltenen Dokumentationsdatei README.database im Verzeichnis "doc".
Aufbau der Snort-Regeln
Sehr wichtig ist natürlich die Erstellung von Snort-Regeln. Ein Blick in die mitgelieferte Konfiguration verrät, wo die Regeldateien liegen und wie diese übersichtlich und komfortabel in die snort.conf eingebunden werden können. Die entsprechenden Dateien finden sich im Unterverzeichnis rules. Jeder Administrator sollte diese Regeldateien analysieren, um sich mit den grundlegenden Techniken vertraut zu machen. Ideal ist es, wenn Sie sich die Inhalte anhand von Beispielen verdeutlichen.
In der Datei shellcode.rules finden Sie beispielsweise die Regeln zur Erkennung von im Netzwerk übertragenen Shellcodes für verschiedenste Plattformen. Solche Shellcodes dienen dem Angreifer zum Starten von Programmen über Netzwerkverbindungen. Jedoch ist es entgegen der weit verbreiteten Meinung nicht notwendig, eine Shell zu starten. Dem Angreifer ist es im Prinzip selbst überlassen, welchen Code er ausführen möchte.
alert ip $EXTERNAL_NET $SHELLCODE
PORTS ->
$HOME_NET any (msg:"SHELLCODE sparc
setuid 0";
content:"|82 10| |17 91 D0| |08|";
reference:arachnids,282;
classtype:system-call-detect;
sid:647; rev:6
alert ip $EXTERNAL_NET $SHELLCODE
PORTS ->
$HOME_NET any (msg:"SHELLCODE x86
setgid 0";
content:"|B0 B5 CD 80|"; reference
arachnids,284;
classtype:system-call-detect;
sid:649; rev:8
alert ip $EXTERNAL_NET $SHELLCODE
PORTS ->
$HOME_NET any (msg:"SHELLCODE x86
setuid 0";
content:"|B0 17 CD 80|"; reference
arachnids,436;
classtype:system-call-detect;
sid:650; rev:8
Wie das Listing zeigt, steht am Anfang stets ein Regelwort. Mit dem Kommando "alert" lassen sich Warnungen ausgeben und Pakete loggen. Der Befehl "log" ist für die Protokollierung der jeweiligen Pakete zuständig, mit "pass" weisen Sie das Tool an, bestimmte Pakete zu ignorieren. Der Befehl "activate" bewirkt im Grunde das Gleiche wie "alert", es kommt zusätzlich aber eine dynamische Regel zur Verwendung.
All diese Schlüsselwörter haben verschiedene Verhaltensweisen. Zudem können eigene Regelwörter in der Konfigurationsdatei spezifiziert werden.
In der mitgelieferten Konfigurationsdatei ist folgendes Beispiel zu finden, das die Arbeitsweise erklären hilft:
ruletype redalert
{
type alert
output alert_syslog: LOG_AUTH LOG_ALERT
output database: log, mysql,
user=snort
dbname=snort
host=localhost
}
Der Regeltyp redalert verhält sich in diesem Fall wie alert und loggt mit Hilfe des syslog-Daemons und der MySQL-Datenbank die mit ihm konfigurierten Meldungen.
Darauf folgt das Protokoll, im obigen Fall ist dies ip. Shellcodes können sowohl über TCP als auch über andere Protokolle übermittelt werden. Durch Angabe von ip spielt dies keine Rolle, da jedes IP-Paket auf einen bestimmten Content untersucht werden kann. Selbstverständlich können Sie an dieser Stelle auch andere Protokolle, beispielsweise tcp, angeben
. Angabe von Quelle und Ziel
Die Angabe einer Netzwerkadresse und eines Ports in Bezug auf die Quelle des Paketes mit anschließender Angabe der Destination erfolgt vor beziehungsweise nach dem Pfeil. Dabei steht "any" immer für einen beliebigen Wert.
msge, content und reference:
– "msg" gibt die Logmeldung aus, "content" legt die Werte, die im Paket enthalten sein müssen, fest, wobei entweder auf in Pipes gestellte Hex-Werte oder auch direkt auf ASCII-Zeichen, also beispielsweise "HEAD / HTTP/1.0", zurückgegriffen werden kann.
Referenzen bieten Ihnen die Möglichkeit, sich über eine Angriffsform zu informieren. Diese Referenzen werden explizit in den Logmeldungen, in der Regel durch Links zu den Problembeschreibungen in Bugtraq ausgegeben.
– "classtype" spezifiziert die Priorität der Regel, wobei zahlreiche Angaben mit verschiedenen Zwecken und der Priorität "high", "medium" oder "low" existieren. Diese Angaben sind in einer recht langen Tabelle im Snort-Manual zu finden.
– "sid" spezifiziert einen Eintrag in der so genannten Snort Signature Database (SID), die im Internet auf
Du musst dich
Anmelden
oder
Registrieren
um diesen link zusehen!
zu finden ist. "rev" legt die zugehörige Version dieser SID fest. Es gelten auch hier wieder einige Besonderheiten bei der Erstellung der Regeln. Die wichtigsten sind: Ausrufezeichen haben eine logische Verneinung zur Folge. Wenn also alle Pakete mit einer IP-Adressangabe außer "192.168.0.1" auf eine Regel zutreffen sollen, können Sie Folgendes schreiben:
!192.168.0.1.
Gruppierungen werden durch eckige Klammern gebildet. Die Separierung von Werten erfolgt durch Kommata. Strings werden in Anführungszeichen eingeschlossen. Zeilenumbrüche können über einen Backslash ("\") realisiert werden. Weitere ausführliche Informationen zu diesem Thema finden Sie in der Datei README.alert_order.
[FONT="]Dieser Artikel stammt auszugsweise aus Linux – Das distributionsunabhängige Handbuch[/FONT]
