»Für einen Politiker ist es gefährlich, die Wahrheit zu sagen. Die Leute könnten sich daran gewöhnen, die Wahrheit hören zu wollen.«
– George Bernard Shaw
33 Netzwerksicherheit überwachen
In diesem Kapitel wollen wir uns mit der Überwachung (engl. monitoring) des Netzwerks respektive dessen Sicherheit beschäftigen. Dazu gehören natürlich mehrere Komponenten, die erst im Zusammenspiel das Ziel erreichen.
In Bezug auf IT-Sicherheit wären das vor allem folgende Systeme:
- Intrusion-Detection-Systeme
- Netzwerkmonitoring-Systeme
- Portscanner
- Vulnerabilityscanner
Wir werden uns all diese Sicherheitskomponenten im Folgenden ansehen.
Intrusion Detection Systeme
Ein Intrusion Detection System (kurz IDS) überwacht einen Host oder ein Netzwerk. Im Normallfall prüft das Intrusion Detection System bestimmte Aktivitäten und versucht, in diesen Aktivitäten vordefinierte Angriffsmuster zu erkennen. Trifft ein solches Angriffsmuster zu, meldet das Intrusion Detection System diesen Vorfall. Unterschieden wird hierbei zwischen host- und netzwerkbasierten IDS (HIDS bzw. NIDS).
Monitoringsysteme
Am besten beginnen wir dazu mit der Definition von Monitoring beziehungsweise Monitoringsystemen, wie man sie in einer Enzyklopädie finden könnte:
Unter Monitoring versteht man im Allgemeinen das »Überwachen« eines Vorgangs oder Prozesses mittels eines technischen Hilfsmittels oder anderer Beobachtungssysteme. Ein Monitoringsystem ermöglicht Interventionen in die betreffenden Prozesse, sofern sich abzeichnet, dass der Prozess nicht den gewünschten Verlauf nimmt. |
Zweckerfüllung
Diese Definition kann man wunderbar auf die anfänglich im Buch gegebene Definition der Sicherheit beziehen, die besagt, dass die technische Infrastruktur nur einen genau definierten Zweck erfüllt. Das Monitoring – realisiert durch Monitoringsysteme – würde also sicherstellen, dass gewisse Systeme oder Dienste nicht ausfallen und diesen Zweck überhaupt erfüllen können. Kommt es dann zu einem Problem, sollte der Administrator entsprechend informiert werden, sodass er Maßnahmen zur Behebung des Problems treffen kann.
Scanner
Zu Monitoringsystemen komplementär sind Scanner, die – vom Admin aktiv gestartet – entweder als Portscanner einen Rechner nach offenen Diensten absuchen oder als Vulnerabilityscanner gleich noch nach entsprechenden Lücken Ausschau halten.
Aktive Überwachung
Da so eine Überwachung im Gegensatz zu Monitoringsystemen aktiv geschieht und nicht die korrekte Funktion (etwa eines Dienstes) sichergestellt, sondern eher Lücken gefunden werden sollen, sind entsprechende Tools natürlich auch bei Hackern beliebt. Daher ist es umso wichtiger, dass man sein eigenes Netzwerk damit ausführlich testet, um entsprechende Lücken erkennen und schließen zu können.
Und so deckt der Einsatz von Port- oder Vulnerabilityscannern auch einen anderen Aspekt der Sicherheitsdefinition ab: Es soll nicht festgestellt werden, ob die Systeme (immer noch) ihre Dienste anbieten, sondern vielmehr, ob sie sich nicht im weitesten Sinne für andere Zwecke missbrauchen lassen.
33.1 Snort 

Snort ist ein sehr populäres Intrusion-Detection-System (IDS) (also ein Programm, das Angriffe erkennt) für Windows-, Linux- und Unix-Systeme.
Dieses System verfügt über eine ganze Reihe von Features und kann eigentlich alles, was man von einem Intrusion-Detection-System erwarten kann:
- Die Fehlerdiagnose und Überwachung des Netzwerks bei der Netzwerkprogrammierung und Netzwerkadministration ist durch den integrierten Sniffer-Code möglich.
- Der Netzwerk-Traffic kann auf der Basis von Regelwerken überwacht werden.
- Snort verfügt über eine Logging-Funktionalität.
- Das System ist unter Linux, Unix und Windows einsetzbar.
Installation
Im Folgenden beziehen wir uns auf die Snort-Version 2.7.0. Sie war aktuell, als wir dieses Kapitel 2009 geschrieben haben. Da das Snort-Paket Bestandteil aller gängigen Distributionen und Derivate ist, werden wir hier nicht näher auf die Installation von Hand eingehen. Sie können den Quellcode von Snort von der Seite snort.org beziehen.
Traffic-Analyse mit Snort
Integrierter Sniffer
Ein wesentliches Feature von Snort ist der integrierte Sniffer. Dieser kann gut zur Analyse des Traffics und als Hilfe bei der Netzwerkprogrammierung genutzt werden. Etwas überflüssig erscheint das Feature trotzdem, wenn man bedenkt, dass die meisten Systeme ihre eigenen Programme für diesen Zweck mitbringen. Unter Linux- und BSD-Systemen ist dies beispielsweise das Tool tcpdump. Außerdem können wir das Tool ethereal empfehlen.
Ein Blick in die Manpage verrät uns, dass Snort mithilfe des Verbose-Modus (also des Parameters -v) dazu gebracht werden kann, die im Linklayer empfangenen Pakete auszugeben. Mittels des Parameters -i wird die Schnittstelle angegeben, auf der »gesnifft« werden soll.
linux# snort -v -i wlan0 Running in packet dump mode --== Initializing Snort ==-- Initializing Output Plugins! Var 'any_ADDRESS' defined, value len = 15 chars, value = 0.0.0.0/0.0.0.0 Var 'lo_ADDRESS' defined, value len = 19 chars, value = 127.0.0.0/255.0.0.0 Verifying Preprocessor Configurations! Initializing Network Interface wlan0 Decoding Ethernet on interface wlan0 Preprocessor/Decoder Rule Count: 0 --== Initialization Complete ==-- ,,_ -*> Snort! <*- o" )~ Version 2.7.0 (Build 35) '''' By Martin Roesch & The Snort Team: http://www. snort.org/team.html (C) Copyright 1998-2007 Sourcefire Inc., et al. Not Using PCAP_FRAMES 08/10-18:23:42.976418 192.168.2.27:38848 -> 68.177.102.20:80 TCP TTL:64 TOS:0x0 ID:36890 IpLen:20 DgmLen:40 DF ***A***F Seq: 0xFB9DDC32 Ack: 0x1F310A2D Win: 0x8160 TcpLen: 20 =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= 08/10-18:23:42.976514 192.168.2.27:38849 -> 68.177.102.20:80 TCP TTL:64 TOS:0x0 ID:16099 IpLen:20 DgmLen:40 DF ***A***F Seq: 0xFC3582E9 Ack: 0x673FE725 Win: 0x1D50 TcpLen: 20 =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= 08/10-18:23:42.976560 192.168.2.27:38850 -> 68.177.102.20:80 TCP TTL:64 TOS:0x0 ID:21711 IpLen:20 DgmLen:40 DF ***A***F Seq: 0xFCE118E8 Ack: 0xD83462D9 Win: 0x1D50 TcpLen: 20 =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= 08/10-18:23:42.976603 192.168.2.27:47913 -> 92.122.24.100:80 TCP TTL:64 TOS:0x0 ID:48727 IpLen:20 DgmLen:52 DF ***A***F Seq: 0xDF9EA459 Ack: 0x60BBC28E Win: 0xB6 TcpLen: 32 TCP Options (3) => NOP NOP TS: 7098059 3491008595 =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= 08/10-18:23:43.055421 92.122.24.100:80 -> 192.168.2.27:47913 TCP TTL:60 TOS:0x0 ID:11233 IpLen:20 DgmLen:52 DF ***A***F Seq: 0x60BBC28E Ack: 0xDF9EA45A Win: 0xC90 TcpLen: 32 TCP Options (3) => NOP NOP TS: 3491322582 7098059 =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= 08/10-18:23:43.055485 192.168.2.27:47913 -> 92.122.24.100:80 TCP TTL:64 TOS:0x0 ID:48728 IpLen:20 DgmLen:52 DF ***A**** Seq: 0xDF9EA45A Ack: 0x60BBC28F Win: 0xB6 TcpLen: 32 TCP Options (3) => NOP NOP TS: 7098078 3491322582 =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= ... ... ... ... ^C*** Caught Int-Signal Run time prior to being shutdown was 6.860948 seconds ============================================================= Snort received 17 packets Analyzed: 17(100.000%) Dropped: 0(0.000%) Outstanding: 0(0.000%) ============================================================= Breakdown by protocol: TCP: 17 (100.000%) UDP: 0 (0.000%) ICMP: 0 (0.000%) ARP: 0 (0.000%) EAPOL: 0 (0.000%) IPv6: 0 (0.000%) ETHLOOP: 0 (0.000%) IPX: 0 (0.000%) FRAG: 0 (0.000%) OTHER: 0 (0.000%) DISCARD: 0 (0.000%) InvChkSum: 0 (0.000%) ============================================================= Action Stats: ALERTS: 0 LOGGED: 0 PASSED: 0 ============================================================= Snort exiting
Listing 33.1 Snort-sniff
Mittels des Parameters -d kann zusätzlich ein Dump der Pakete erreicht werden. Der bereits durch das obige Listing bekannte Initialisierungs-Output wurde zugunsten einer besseren Übersichtlichkeit entfernt.
linux# snort -v -d -i lo
....
08/12-15:14:07.944698 127.0.0.1:32772 -> 127.0.0.1:22
TCP TTL:64 TOS:0x10 ID:27392 IpLen:20 DgmLen:52 DF
***A**** Seq: 0xBEFA5959 Ack: 0xBF6138FF Win: 0x7FFF
TcpLen: 32
TCP Options (3) => NOP NOP TS: 144295 144295
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
08/12-15:14:07.945803 127.0.0.1:22 -> 127.0.0.1:32772
TCP TTL:64 TOS:0x0 ID:2904 IpLen:20 DgmLen:77 DF
***AP*** Seq: 0xBF6138FF Ack: 0xBEFA5959 Win: 0x7FFF
TcpLen: 32
TCP Options (3) => NOP NOP TS: 144295 144295
53 53 48 2D 31 2E 39 39 2D 4F 70 65 6E 53 53 48
SSH-1.99-OpenSSH
5F 33 2E 37 2E 31 70 32 0A
_3.7.1p2.
^C
======================================================
Snort received 24 packets
Analyzed: 24(100.000%)
Dropped: 0(0.000%)
======================================================
Breakdown by protocol:
TCP: 12 (50.000%)
UDP: 0 (0.000%)
ICMP: 0 (0.000%)
ARP: 0 (0.000%)
EAPOL: 0 (0.000%)
IPv6: 0 (0.000%)
IPX: 0 (0.000%)
OTHER: 0 (0.000%)
DISCARD: 0 (0.000%)
======================================================
Action Stats:
ALERTS: 0
LOGGED: 0
PASSED: 0
======================================================
Snort exiting
Listing 33.2 Snort-sniff mit Package-Dump
Wie Sie sehen, wird Snort (sofern es nicht im Dämon-Modus betrieben wird) durch die Tastenkombination Strg + C abgebrochen.
33.1.1 Aufbau der Intrusion Detection 

Kommen wir nach dieser kleinen Exkursion nun zur Hauptaufgabe von Snort, der Intrusion Detection. Legen Sie zunächst das Logverzeichnis /var/log/snort an, falls dieses nicht bereits durch Ihr Paketsystem automatisch geschehen ist.
Vorgefertigte Konfiguration
Anschließend können Sie die im Subverzeichnis etc/ mitgelieferte Konfigurationsdatei nach /etc/snort.conf verschieben. [Wurde Snort als Paket installiert, so wird dies in den meisten Fällen bereits erledigt sein.]
# mkdir /var/log/snort # cp etc/snort.conf /etc/
Listing 33.3 Erste Post-Installationsschritte für Snort
33.1.2 snort.conf 

Sehen wir uns den Aufbau der Konfigurationsdatei einmal an. Kommentare werden – wie auch in Shellskripten – mit einer Raute eingeleitet.
Zudem können, ähnlich wie in C, C++ oder in Makefiles, weitere Dateien eingebunden, also »includiert« werden. Hier wird das Schlüsselwort include: in Verbindung mit einer entsprechenden Pfadangabe verwendet.
Variablen
Zur Erzeugung einer Variablen verwendet man das Schlüsselwort var, also z. B.:
var ROUTER 192.168.0.2
Variablen können in den Regeldateien via $<Variable>, also z. B. mit $ROUTER, angesprochen werden. |
Die Variable HOME_NET wird zur Angabe des Inhouse-Netzes verwendet, wohingegen EXTERNAL_NET für eine externe Gegenstelle steht (die Konfiguration kann folglich problemlos auf einem Gateway eingesetzt werden).
Variablen nutzen
Es folgen die Variablen zur Angabe der Dienste des Netzwerks, also z. B. die Variable SMTP_SERVERS für die Liste der Mailserver im Netz oder TELNET_SERVERS für die Telnet-Server und so weiter. Darauf folgen Port-Angaben und spezielle Variablen, z. B. AIM_SERVERS zur Angabe der Server für den Instant Messenger. An diesem Beispiel ist sehr gut zu sehen, wie eine Separierung von Werten (nämlich durch Kommas) und die Verwendung von Netzklassen (nämlich durch Angabe der Net-ID-Bits hinter einem Slash) auszusehen hat.
var AIM_SERVERS [64.12.24.0/23, 64.12.28.0/23, 64.12.161.0/24, 64.12.163.0/24, 64.12.200.0/24, 205.188.3.0/24, 205.188.5.0/24, 205.188.7.0/24, 205.188.9.0/24, 205.188.153.0/24, 205.188.179.0/24, 205.188.248.0/24]
Listing 33.4 Wert-Separierung für Snort-Variablen
Variablen können auch Pfade enthalten. Die Angabe von Pfaden zu Regeldateien ist übrigens auch in relativer Form möglich (doch auch eine absolute Pfadangabe hat noch niemandem geschadet).
# Path to your rules files (this can be a relative path) # Note for Windows users: You are advised to make this # an absolute path, such as: c:\snort\rules var RULE_PATH /etc/snort/rules
Listing 33.5 RULE_PATH
Das Schlüsselwort »config«
Mit dem config-Schlüsselwort können Sie das Verhalten von Snort, z. B. in bestimmten Situationen, konfigurieren. Da man aus der Praxis bekanntlich am einfachsten lernt, werden wir uns nun weiter der Analyse der Konfigurationsdatei widmen.
Analyse
Als Erstes werden Sie mit dem decoder-Bereich des NIDS (Network Intrusion Detection System) konfrontiert. Wir sehen, dass das config-Schlüsselwort immer an erster Stelle steht. Anschließend wird ein Parameter übergeben, mit dem die eigentliche Aktion bestimmt wird.
Beim Listing ist zu beachten, dass Sie die beschriebenen config-Operationen auskommentieren müssen, um sie zu aktivieren.
# 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 # # In snort 2.0.1 and above, this only alerts when a TCP # option is detected that shows T/TCP being actively used # on the network. If this is normal behavior for your # network, disable the next option. # # 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 ...
Listing 33.6 Snort-Decoder
Nachfolgend sollen die oben aufgelisteten sowie die wichtigsten nicht aufgelisteten Parameter besprochen werden.
- Der Parameter disable_decode_alerts stellt die Meldungen des Decoders ab.
- Der Parameter disable_tcpopt_experimental_alerts gibt keine Warnungen beim Eintreffen von TCP-Paketen mit experimentellen Optionen aus.
- Der Parameter disable_tcpopt_obsolete_alerts gibt keine Warnungen beim Eintreffen von TCP-Paketen mit veralteten Optionen aus.
- Der Parameter disable_tcpopt_ttcp_alerts stellt Warnungen beim Eintreffen von TCP-Paketen aus.
- Der Parameter disable_tcpopt_alerts stellt generell alle Warnungen ab, die durch TCP-Optionen hervorgerufen werden.
- Der Parameter disable_ipopt_alerts unterdrückt Warnungen, wenn IP-Pakete mit abnormalen Optionen gefunden werden.
- Der Parameter set_gid ändert die Gruppen-ID, unter der snort läuft, auf die angegebene. Der Parameter set_uid erfüllt die gleiche Funktion bezüglich der User-ID.
- Der Parameter daemon versetzt snort in den Dämon-Modus, sodass es als Hintergrundprozess sein Dasein fristet.
- Der Parameter interface legt das Interface fest, auf dem snort agieren soll, etwa config interface:eth1.
- Der Parameter logdir spezifiziert das Verzeichnis, in dem die Logdateien untergebracht werden.
Dieses Verzeichnis kann sehr groß werden. In der Regel wird hierzu das Verzeichnis /var/log/snort verwendet, daher sollte immer darauf geachtet werden, dass der /var-Partition genügend Speicherplatz zur Verfügung steht. |
- Der Parameter umask legt unter Unix die umask-Werte zur Erstellung neuer Dateien fest.
- Der Parameter no_promisc setzt das Netzwerk-Interface, auf dem snort agiert, nicht in den Promiscuous-Modus. [Im Promiscuous-Modus nehmen Netzwerkkarten auch Pakete an, die sie zwar erhalten, aber nicht für sie bestimmt sind. Snort untersucht in diesem Fall also auch solche Pakete.]
- Der Parameter chroot funktioniert zumindest unter Unix und legt mithilfe des chroot(2)-Syscalls ein neues Wurzelverzeichnis für snort fest. Dies erschwert Angriffe auf snort und findet auch bei anderen Diensten Verwendung, etwa bei dem Apache-Webserver und bei BIND unter OpenBSD.
- Der Parameter checksum_mode legt die Überprüfung der Prüfsummen fest. Mit notcp können beispielsweise die Prüfsummenberechnungen von TCP-Paketen unterbunden werden. Auf langsamen Maschinen kann durch das Abstellen der Verifizierung der Checksum (none) die Performance etwas steigern.
Das Schlüsselwort »preprocessor«
Mit der Einführung von preprocessor-Extensions erhielt snort die Möglichkeit der modularen Weiterentwicklung. So wurde beispielsweise ein Portscan-Detection-Modul entwickelt, das über die Anweisung preprocessor in snort Verwendung findet.
Portscan- Detection
Zunächst wenden wir uns der Portscan-Detection zu. Mit ihr kann bestimmt werden, wie viele TCP- und UDP-Ports eine Quelle innerhalb welcher Zeit anfragen muss, um als Portscan erkannt zu werden.
Es werden hierbei auch spezielle Techniken wie der Stealth-, XMAS-, NULL- und FIN-Scan erkannt. |
Die preprocessor-Anweisung schaltet diese Funktionalität folgendermaßen ein: Das erste Argument ist die Angabe des Netzwerks, das überwacht werden soll. An zweiter Stelle wird die Anzahl der Ports angegeben, die in der an dritter Stelle festgelegten Zeit vom Angreifer gescannt werden sollen. Die Zeitspanne wird dabei in Einheiten von jeweils einer Sekunde angegeben. Der letzte Parameter legt die Logdatei fest, in der die Protokollierung Portscans ablegen soll (wobei diese zusätzlich in die alert-Datei von snort geschrieben werden):
# Form: preprocessor portscan: <Netzwerk> <Anzahl der Ports> <Zeitlimit> <Logdatei> # Beispielsweise: preprocessor portscan: 10.34.53.0/24 5 10 /var/log/snort/scans
Listing 33.7 preprocessor portscan
Regel überlisten
Gemäß dem obigen Listing muss also innerhalb von 10 Sekunden ein Bereich von mindestens 5 Ports abgescannt werden, bevor ein Portscan erkannt wird, was uns zu einem anderen Problem führt: Einige Tools scannen absichtlich Port-Bereiche äußerst langsam ab. Zwar dauert dies länger, es ist aber auf obige Art und Weise sehr schwer zu entdecken. Für den Angreifer bedeutet diese Scan-Technik nicht einmal eine zu große Wartezeit, denn ein auf wenige ausgesuchte Ports ausgerichteter Scan reicht oftmals aus, um eine Sicherheitslücke zu erkennen.
ignorehosts
Mit der Anweisung portscan-ignorehosts können aus einer Portscan-Liste gezielt Hosts ausgetragen werden, bei denen keine Benachrichtigung bei TCP-SYN- oder UDP-Portscans erfolgen soll.
preprocessor portscan-ignorehosts: 192.168.0.3
Listing 33.8 portscan-ignorehosts
frag2
Es gibt noch weitere Preprocessor-Module wie z. B. frag2, das einige Features bezüglich der Fragmentierung von IP-Paketen bietet. Lädt man dieses Modul ohne weitere Angabe von Parametern (etwa der seiner Speicherbegrenzung (memcap) oder der minimalen TTL eines Pakets (min_ttl)), so werden maximal 4 Megabyte Hauptspeicher für diese Funktionalität verschlungen; Pakete, deren Fragmente nicht innerhalb von 60 Sekunden eintreffen, werden verworfen. In der Default-Konfiguration ist frag2 ohne weitere Parameter eingebunden.
preprocessor frag2
Listing 33.9 Nutzung von frag2
arpspoof
Die zum Zeitpunkt des Schreibens noch experimentelle Erkennung von ARP- Spoofing könnte so einige Administratoren erfreuen.
Weitere Möglichkeiten
Dem interessierten Administrator bietet snort noch einige weitere Module für die preprocessor-Anweisung, wie z. B. stream4, flow (flow-port-scan), telnet_decode, rpc_decode, den Performancemonitor oder auch http_inspect. Diese Module können im Rahmen dieses Buches jedoch nicht näher erläutert werden.
Das Schlüsselwort »output«
Mittels des Schlüsselworts output ist es möglich, das Logging der Meldungen von snort auf verschiedenen Wegen geschehen zu lassen. Beispielsweise kann via syslog oder in Form einer binären Datei im tcpdump-Format protokolliert werden. Zudem können die Meldungen in Datenbanken geschrieben werden.
output database: log, mysql,user=admin password=pass dbname=snort host=eygo.sun
Listing 33.10 Datenbank mit »output« verwenden
Nicht nur MySQL!
Wie der Ausdruck MySQL vermuten lässt, ist es möglich, snort auf verschiedenste Datenbanken zugreifen zu lassen. In der aktuellen Version 2.8.x sind dies:
- Oracle
- MySQL
- PostgreSQL
- unixODBC
- MS SQL
Weitere Informationen zu dieser Datenbank-Anbindung finden Sie in der bei Snort enthaltenen Dokumentationsdatei README.database im Verzeichnis doc des Programms und auf cvs.snort.org/viewcvs.cgi/snort/doc/README.database. |
Aufbau der Snort-Regeln
Sehr wichtig ist die Erstellung von snort-Regeln. Ein Blick in die mitgelieferte Konfiguration verrät uns, wo die Regeldateien liegen und wie diese übersichtlich und komfortabel in die snort.conf eingebunden werden können.
include $RULE_PATH/local.rules include $RULE_PATH/bad-traffic.rules include $RULE_PATH/exploit.rules include $RULE_PATH/scan.rules include $RULE_PATH/finger.rules include $RULE_PATH/ftp.rules include $RULE_PATH/telnet.rules include $RULE_PATH/rpc.rules include $RULE_PATH/rservices.rules include $RULE_PATH/dos.rules ....
Listing 33.11 Einbinden der Regeldateien in snort.conf
Im Unterverzeichnis rules/ finden sich dann auch schließlich diese Dateien. Wir empfehlen Ihnen, sich diese Dateien anzusehen, da sie wunderbare Beispiele für Snort-Regeln enthalten, aus denen Sie Wissen ziehen können. |
Am besten erlernt man diese in der Regel sehr einfach zu verstehenden Inhalte anhand von Beispielen. In der Datei shellcode.rules finden Sie beispielsweise die Regeln zur Erkennung von im Netzwerk übertragenen Shellcodes für verschiedenste Plattformen. [Shellcodes dienen dem Angreifer zum Starten von Programmen (meist einer Shell) ü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;)
Listing 33.12 Auszug aus shellcode.rules
Regelwörter
Regeln beginnen mit einem Regelwort, wie z. B. alert oder log. Diese Schlüsselwörter haben verschiedene Verhaltensweisen, zudem können eigene Regelwörter in der Konfigurationsdatei spezifiziert werden. In der mitgelieferten Konfigurationsdatei wird (auskommentiert) folgendes Beispiel mitgeliefert:
ruletype redalert { type alert output alert_syslog: LOG_AUTH LOG_ALERT output database: log, mysql, user=snort dbname=snort host=localhost }
Listing 33.13 Auszug aus snort.conf
Der Regeltyp redalert verhält sich in diesem Fall wie alert und loggt mithilfe des syslog-Dämons und der MySQL-Datenbank die mit ihm konfigurierten Meldungen.
Gehen wir nun zurück zu den eigentlichen Regelwörtern und ihrer Bedeutung:
- alert
Warnung ausgeben und Paket loggen
- log
Paket loggen
- pass
Paket nicht weiter beachten
- activate
wie alert verhalten, jedoch zusätzlich eine dynamische Regel verwenden
- dynamic
wie log verhalten; wird von activate aktiviert [Exzellente weiterführende Hinweise finden Sie im Snort-Manual.]
Protokoll
Daraufhin 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, einem cleveren Schachzug, spielt dies keine Rolle mehr, da jedes IP-Paket auf einen bestimmten Content untersucht werden kann. Selbstverständlich können auch andere Protokolle, etwa tcp, angegeben werden.
Quelle und Ziel
Die Angabe einer Netzwerkadresse und eines Ports in Bezug auf die Quelle des Pakets mit anschließender Angabe der Destination erfolgt vor oder nach dem Pfeil. Dabei steht any für einen beliebigen Wert.
msg, content und reference
msg gibt die Logmeldung aus, und content legt die Werte fest, die im Paket enthalten sein müssen, wobei entweder auf in Pipes gestellte Hexwerte (wie oben zu sehen) oder auch direkt auf ASCII-Zeichen, also etwa "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 ausgegeben, in der Regel durch Links zu den Problembeschreibungen in der Sicherheits-Mailingliste Bugtraq (siehe www.securityfocus.com).
classtype
classtype spezifiziert die Priorität der Regel, wobei eine ganze Menge von möglichen Angaben mit verschiedenen Zwecken und den Prioritäten high, medium oder low existieren. Diese Angaben sind in einer recht langen Tabelle im Snort-Manual zu finden.
sid und rev
sid spezifiziert einen Eintrag in der Snort Signature Database (SID), die auf snort.org 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 (wie bereits oben erwähnt) durch eckige Klammern gebildet. Die Separierung von Werten erfolgt durch Kommas.
- Strings werden in Anführungszeichen eingeschlossen.
- Zeilenumbrüche können über einen Backslash (\) realisiert werden.
Weitere Informationen zu diesem Thema finden Sie in der Datei README.alert_order.