Galileo Computing < openbook > Galileo Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Vorwort
1 Einleitung
2 Die Installation
3 Erste Schritte
4 Linux als Workstation für Einsteiger
5 Der Kernel
6 Die Grundlagen aus Anwendersicht
7 Die Shell
8 Reguläre Ausdrücke
9 Konsolentools
10 Die Editoren
11 Shellskriptprogrammierung mit der bash
12 Die C-Shell
13 Benutzerverwaltung
14 Grundlegende Verwaltungsaufgaben
15 Netzwerkgrundlagen
16 Anwendersoftware für das Netzwerk
17 Netzwerkdienste
18 Mailserver unter Linux
19 LAMP
20 DNS-Server
21 Secure Shell
22 Die grafische Oberfläche
23 Window-Manager und Desktops
24 X11-Programme
25 Multimedia und Spiele
26 Prozesse und IPC
27 Bootstrap und Shutdown
28 Dateisysteme
29 Virtualisierung und Emulatoren
30 Softwareentwicklung
31 Crashkurs in C und Perl
32 Einführung in die Sicherheit
33 Netzwerksicherheit überwachen
A Lösungen zu den einzelnen Aufgaben
B Kommandoreferenz
C X11-InputDevices
D MBR
E Die Buch-DVDs
F Glossar
G Literatur
Stichwort

Download:
- ZIP, ca. 15,7 MB
Buch bestellen
Ihre Meinung?

Spacer
 <<   zurück
Linux von Johannes Pl&ouml;tner, Steffen Wendzel
Das umfassende Handbuch
Buch: Linux

Linux
geb., mit 2 DVDs
1302 S., 39,90 Euro
Galileo Computing
ISBN 978-3-8362-1704-0
Pfeil 33 Netzwerksicherheit überwachen
  Pfeil 33.1 Snort
    Pfeil 33.1.1 Aufbau der Intrusion Detection
    Pfeil 33.1.2 snort.conf
  Pfeil 33.2 Netzwerkmonitoring mit Nagios
    Pfeil 33.2.1 Die Installation
    Pfeil 33.2.2 Die Konfiguration
    Pfeil 33.2.3 Die Plugins
  Pfeil 33.3 Nmap: Der wichtigste Portscanner
    Pfeil 33.3.1 Prinzip eines Portscanners
    Pfeil 33.3.2 Techniken des Scannens
    Pfeil 33.3.3 Weiterer Informationsgewinn
    Pfeil 33.3.4 Nmap in der Praxis
  Pfeil 33.4 Nessus: Ein Security-Scanner
    Pfeil 33.4.1 Die Installation
    Pfeil 33.4.2 Die Konfiguration
    Pfeil 33.4.3 Nessus benutzen
  Pfeil 33.5 Sniffer
    Pfeil 33.5.1 tcpdump
    Pfeil 33.5.2 Wireshark (ehemals ethereal)
    Pfeil 33.5.3 dsniff
  Pfeil 33.6 Zusammenfassung

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


Galileo Computing - Zum Seitenanfang

33.1 Snort  Zur nächsten ÜberschriftZur vorigen Überschrift

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.


Galileo Computing - Zum Seitenanfang

33.1.1 Aufbau der Intrusion Detection  Zur nächsten ÜberschriftZur vorigen Überschrift

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


Galileo Computing - Zum Seitenanfang

33.1.2 snort.conf  topZur vorigen Überschrift

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.



Ihr Kommentar

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






 <<   zurück
  Zum Katalog
Zum Katalog: Linux, Ausgabe 2011






Linux, Ausgabe 2011
Jetzt bestellen


 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Katalog: Linux-Server






 Linux-Server


Zum Katalog: Linux Hochverfügbarkeit






 Linux Hoch-
 verfügbarkeit


Zum Katalog: LPIC-1






 LPIC-1


Zum Katalog: Debian GNU/Linux






 Debian GNU/Linux


Zum Katalog: openSUSE 11.2






 openSUSE 11.2


Zum Katalog: Shell-Programmierung






 Shell-Programmierung


Zum Katalog: Ubuntu GNU/Linux






 Ubuntu GNU/Linux


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo




Copyright © Galileo Press 2011
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


[Galileo Computing]

Galileo Press, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, info@galileo-press.de