»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 von 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 die folgenden Systeme:

Intrusion-Detection-Systeme
Netzwerkmonitoring-Systeme
Portscanner
Vulnerability-Scanner

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 es bestimmte Aktivitäten und versucht, in ihnen vordefinierte Angriffsmuster zu erkennen. Wird ein solches Muster gefunden, 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 von 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, so dass 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 eine solche Ü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) für Windows-, Linux- und Unix-Systeme. Es verfügt über eine ganze Reihe von Features und kann eigentlich alles, was man von einem solchen 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 Wireshark 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.

Listing 33.1 Snort-sniff

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

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.

Listing 33.2 Snort-sniff mit Package-Dump

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

Wie Sie sehen, lässt sich (sofern es nicht im Dämon-Modus betrieben wird) durch die Tastenkombination Strg + C abbrechen.

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. [Fn. Wurde Snort als Paket installiert, so wird dies in den meisten Fällen bereits erledigt sein.]

Listing 33.3 Erste Post-Installationsschritte für Snort

# mkdir /var/log/snort
# cp etc/snort.conf /etc/

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 »inkludiert« 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.:

Listing 33.4

var ROUTER 192.168.0.2

[»]Variablen können in den Regeldateien durch $<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. 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 die Trennung von Werten (nämlich durch Kommata) und die Verwendung von Netzklassen (nämlich durch Angabe der Net-ID-Bits hinter einem Slash) auszusehen hat.

Listing 33.4 Wert-Separierung für Snort-Variablen

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]

Variablen können auch Pfade enthalten. Die Angabe von Pfaden zu Regeldateien ist übrigens auch in relativer Form möglich (doch eine absolute Pfadangabe hat noch niemandem geschadet).

Listing 33.5 RULE_PATH

# 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

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.

Listing 33.6 Snort-Decoder

# 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
...

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 stellt Warnungen beim Eintreffen von TCP-Paketen mit experimentellen Optionen ab.
disable_tcpopt_obsolete_alerts stellt Warnungen beim Eintreffen von TCP-Paketen mit veralteten Optionen ab.
disable_tcpopt_ttcp_alerts stellt Warnungen beim Eintreffen von TCP-Paketen ab.
disable_tcpopt_alerts stellt generell alle Warnungen ab, die durch TCP-Optionen hervorgerufen werden.
disable_ipopt_alerts unterdrückt Warnungen, 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 Funktion bezüglich der User-ID.
daemon versetzt Snort in den Dämon-Modus, so dass es als Hintergrundprozess sein Dasein fristet.
interface legt das Interface fest, auf dem snort agieren soll, etwa config interface:eth1.
logdir gibt das Verzeichnis an, in dem die Logdateien untergebracht werden.

[»]Dieses Verzeichnis kann sehr groß werden. In der Regel wird hierzu /var/log/snort verwendet; es sollte immer darauf geachtet werden, 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 deaktiviert für das Netzwerk-Interface, auf dem Snort agiert, den Promiscuous-Modus. [Fn. 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.]
chroot funktioniert unter Unix und legt mithilfe des chroot(2)-Syscalls ein neues Wurzelverzeichnis für Snort fest. Dies erschwert Angriffe auf das IDS und findet auch bei anderen Diensten Verwendung, etwa bei Apache und bei BIND unter OpenBSD.
checksum_mode legt die Überprüfung der Prüfsummen fest. Mit notcp können beispielsweise die Prüfsummenberechnungen für TCP-Pakete unterbunden werden. Auf langsamen Maschinen kann durch das Abstellen der Prüfsummenverifizierung (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

Wenden wir uns zunächst 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 müssen. 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):

Listing 33.7 preprocessor portscan

# Form:
preprocessor portscan: <Netzwerk>
                       <Anzahl der Ports>
                       <Zeitlimit>
                       <Logdatei>

# Beispielsweise:
preprocessor portscan: 10.34.53.0/24
                       5
                       10
                       /var/log/snort/scans

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.

Listing 33.8 portscan-ignorehosts

preprocessor portscan-ignorehosts: 192.168.0.3

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.

Listing 33.9 Nutzung von frag2

preprocessor 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 über syslog oder in Form einer binären Datei im tcpdump-Format protokolliert werden. Zudem können die Meldungen in Datenbanken geschrieben werden.

Listing 33.10 Datenbank mit »output« verwenden

output database: log, mysql,user=admin password=pass \
                 dbname=snort host=eygo.sun

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
Microsoft SQL Server

[»]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 sie übersichtlich und komfortabel in die snort.conf eingebunden werden können.

Listing 33.11 Einbinden der Regeldateien in snort.conf

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
....

[»]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. [Fn. 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.]

Listing 33.12 Auszug aus shellcode.rules

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;)

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:

Listing 33.13 Auszug aus snort.conf

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 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 [Fn. 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. Sie 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 Trennung von Werten erfolgt durch Kommata.
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.

Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.

Name
E-Mail
Ihr Kommentar