Alle
Phasen des
Network Security
Monitoring erklärt:
Erfassung,
Erkennung und
Analyse
Chris Sanders/Jason Smith
Hacking
mit Security Onion
Sicherheit im Netzwerk überwachen: Daten erfassen und
sammeln, analysieren und Angriffe rechtzeitig erkennen
• Network Security Monitoring im Detail verstehen und selbst durchführen
• Linux-Distribution für Netzwerksicherheitsanalysen:
Security Onion installieren und nutzen
• Open-Source-Tools im Praxiseinsatz: Bro, Daemonlogger, Dumpcap,
Justniffer, Honeyd, Httpry, Netsniff-NG, Sguil, SiLK, Snorby Snort,
Squert, Suricata, TShark, Wireshark und mehr
Chris Sanders/Jason Smith
Hacking mit Security Onion
Chris Sanders/Jason Smith
Hacking
mit Security Onion
Sicherheit im Netzwerk überwachen: Daten erfassen und
sammeln, analysieren und Angriffe rechtzeitig erkennen
• Network Security Monitoring im Detail verstehen und selbst durchführen
• Linux-Distribution für Netzwerksicherheitsanalysen: Security Onion
installieren und nutzen
• Open-Source-Tools im Praxiseinsatz: Bro, Daemonlogger, Dumpcap, Justniffer,
Honeyd, Httpry, Netsniff-NG, Sguil, SiLK, Snorby Snort, Squert, Suricata,
TShark, Wireshark und mehr
Bibliografische Information der Deutschen Bibliothek
Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie;
detaillierte Daten sind im Internet über http://dnb.ddb.de abrufbar.
Alle Angaben in diesem Buch wurden vom Autor mit größter Sorgfalt erarbeitet bzw. zusammengestellt und unter
Einschaltung wirksamer Kontrollmaßnahmen reproduziert. Trotzdem sind Fehler nicht ganz auszuschließen. Der
Verlag und der Autor sehen sich deshalb gezwungen, darauf hinzuweisen, dass sie weder eine Garantie noch die juristische Verantwortung oder irgendeine Haftung für Folgen, die auf fehlerhafte Angaben zurückgehen, übernehmen können. Für die Mitteilung etwaiger Fehler sind Verlag und Autor jederzeit dankbar. Internetadressen oder
Versionsnummern stellen den bei Redaktionsschluss verfügbaren Informationsstand dar. Verlag und Autor übernehmen keinerlei Verantwortung oder Haftung für Veränderungen, die sich aus nicht von ihnen zu vertretenden
Umständen ergeben. Evtl. beigefügte oder zum Download angebotene Dateien und Informationen dienen ausschließlich der nicht gewerblichen Nutzung. Eine gewerbliche Nutzung ist nur mit Zustimmung des Lizenzinhabers möglich.
This edition of Applied Network Security Monitoring by Chris Sanders and Jason Smith is published by
arrangement with ELSEVIER INC., a Delaware corporation having its principal place of business at
360 Park Avenue South, New York, NY 10010, USA
ISBN der englischen Originalausgabe: 978-0124172081
© 2016 Franzis Verlag GmbH, 85540 Haar bei München
Alle Rechte vorbehalten, auch die der fotomechanischen Wiedergabe und der Speicherung in elektronischen Medien. Das Erstellen und Verbreiten von Kopien auf Papier, auf Datenträgern oder im Internet, insbesondere als PDF,
ist nur mit ausdrücklicher Genehmigung des Verlags gestattet und wird widrigenfalls strafrechtlich verfolgt.
Die meisten Produktbezeichnungen von Hard- und Software sowie Firmennamen und Firmenlogos, die in diesem
Werk genannt werden, sind in der Regel gleichzeitig auch eingetragene Warenzeichen und sollten als solche
betrachtet werden. Der Verlag folgt bei den Produktbezeichnungen im Wesentlichen den Schreibweisen der
Hersteller.
Autor: Chris Sanders und Jason Smith
Programmleitung: Dr. Markus Stäuble
Satz: G&U Language & Publishing Services GmbH, Flensburg
ISBN 978-3-645-20496-5
Dieses Buch ist ein Produkt der Stärke, die ich durch Liebe gewonnen habe. Ich widme
es Gott, meiner Frau Ellen und allen, die mich weiterhin lieben und unterstützen.
»Aber die auf den HERRN harren, kriegen neue Kraft, dass sie auffahren mit Flügeln
wie Adler, dass sie laufen und nicht matt werden, dass sie wandeln und nicht müde
werden.«
Jesaja 40:31 (Luther)
7
Inhaltsverzeichnis
Danksagung........................................................................................19
Die Autoren.........................................................................................21
Geleitwort.......................................................................................... 25
Vorwort.............................................................................................. 27
Zielpublikum.......................................................................................................28
Voraussetzungen................................................................................................29
Der Aufbau dieses Buches..................................................................................30
Hinweis zu IP-Adressen......................................................................................32
Begleitwebsite....................................................................................................33
Unterstützung für wohltätige Organisationen.....................................................33
Rural Technology Fund........................................................................................33
Hackers for Charity.............................................................................................33
Kiva ......................................................................................................................................34
Hope for the Warriors®...............................................................................................34
Autism Speaks....................................................................................................34
Kontakt...............................................................................................................35
1. Network Security Monitoring in der Praxis................................... 37
1.1
Kernbegriffe des Network Security Monitoring........................................39
1.1.1
Schützenswerte Güter.............................................................................39
1.1.2
Angreifer.................................................................................................39
1.1.3
Schwachstelle.........................................................................................40
1.1.4
Exploit.....................................................................................................40
1.1.5
Risiko......................................................................................................40
8 Inhaltsverzeichnis
1.1.6
Anomalie.................................................................................................40
1.1.7
Zwischenfall............................................................................................ 41
1.2
Intrusion Detection................................................................................. 41
1.3
Network Security Monitoring..................................................................42
1.4
Schwachstellen- und bedrohungsorientierte Verteidigung im Vergleich...45
1.5
Der NSM-Zyklus: Erfassung, Erkennung und Analyse..............................46
1.5.1
Erfassung................................................................................................47
1.5.2
Erkennung..............................................................................................47
1.5.3
Analyse...................................................................................................48
1.6
Kritik an NSM..........................................................................................48
1.7
Die Analytiker.........................................................................................49
1.7.1
Wichtige Fähigkeiten...............................................................................50
1.7.2
Einteilung von Analytikern......................................................................52
1.7.3
Messen des Erfolgs.................................................................................53
1.8
Security Onion........................................................................................57
1.8.1
Installation..............................................................................................57
1.8.2
Security Onion aktualisieren...................................................................59
1.8.3
NSM-Dienste einrichten..........................................................................59
1.8.4
Security Onion testen.............................................................................60
1.9
Zusammenfassung..................................................................................62
Teil 1:
Erfassung
63
2. Die Datenerfassung planen.......................................................... 65
2.1
Applied Collection Framework (ACF).......................................................66
2.1.1
Bedrohungen identifizieren.....................................................................67
2.1.2
Das Risiko quantifizieren........................................................................69
2.1.3
Datenquellen identifizieren.....................................................................70
2.1.4
Die Erfassung eingrenzen.......................................................................70
Inhaltsverzeichnis 9
2.2
Fallstudie: Onlinehändler........................................................................73
2.2.1
Bedrohungen der Organisation identifizieren.........................................74
2.2.2 Das Risiko quantifizieren........................................................................75
2.2.3 Datenquellen identifizieren.....................................................................77
2.2.4 Die Erfassung eingrenzen....................................................................... 81
2.3
Zusammenfassung..................................................................................83
3. Sensoren...................................................................................... 85
3.1
NSM-Datentypen....................................................................................86
3.1.1
Paketdaten (FPC)....................................................................................86
3.1.2
Sitzungsdaten.........................................................................................86
3.1.3
Statistische Daten...................................................................................87
3.1.4
Paketstringdaten (PSTR).........................................................................87
3.1.5
Protokolldaten........................................................................................87
3.1.6
Alarmdaten.............................................................................................87
3.2
Sensortypen...........................................................................................89
3.2.1
Nur Erfassung.........................................................................................89
3.2.2 Halbzyklus..............................................................................................89
3.2.3 Vollzyklus................................................................................................89
3.3
Sensorhardware......................................................................................90
3.3.1
CPU......................................................................................................... 91
3.3.2 Arbeitsspeicher.......................................................................................92
3.3.3 Festplattenplatz......................................................................................93
3.3.4 Netzwerkschnittstellen...........................................................................96
3.3.5 Lastenausgleich: Anforderungen für Socketpuffer..................................98
3.3.6 SPAN-Ports und Netzwerk-Taps im Vergleich...........................................99
3.4
Das Betriebssystem des Sensors.......................................................... 104
10 Inhaltsverzeichnis
3.5
Platzierung von Sensoren..................................................................... 104
3.5.1
Die richtigen Ressourcen nutzen........................................................... 105
3.5.2 Ein- und Austrittspunkte....................................................................... 105
3.5.3 Sichtbarkeit interner IP-Adressen......................................................... 107
3.5.4 Nähe zu kritischen Elementen................................................................110
3.5.5 Sichtfelddiagramme der Sensoren aufstellen........................................ 111
3.6
Den Sensor absichern............................................................................113
3.6.1
Betriebssystem- und Softwareaktualisierungen....................................114
3.6.2 Das Betriebssystem absichern...............................................................114
3.6.3 Eingeschränkter Internetzugriff..............................................................115
3.6.4 Minimale Softwareinstallation...............................................................115
3.6.5 VLAN-Segmentierung.............................................................................115
3.6.6 Host-IDS................................................................................................116
3.6.7 Zwei-Faktor-Authentifizierung................................................................116
3.6.8 Netzwerk-IDS.........................................................................................116
3.7
Zusammenfassung.................................................................................117
4. Sitzungsdaten............................................................................. 119
4.1
Flussdatensätze.................................................................................... 120
4.1.1
NetFlow................................................................................................. 124
4.1.2
IPFIX..................................................................................................... 125
4.1.3
Andere Flusstypen................................................................................ 125
4.2
Sitzungsdaten erfassen........................................................................ 126
4.2.1
Hardwareseitige Generierung............................................................... 126
4.2.2 Softwareseitige Generierung................................................................ 127
4.3
Flussdaten mit SiLK erfassen und analysieren...................................... 128
4.3.1
Das Packsystem von SiLK...................................................................... 129
4.3.2 Flusstypen in SiLK................................................................................. 130
4.3.3 Die Analysesuite von SiLK......................................................................131
Inhaltsverzeichnis 11
4.3.4 SiLK in Security Onion installieren........................................................ 132
4.3.5 Flussdaten mit Rwfilter filtern............................................................... 132
4.3.6 Verketten von Analysetools................................................................... 134
4.3.7 Zusätzliche Werkzeuge und Dokumentation......................................... 138
4.4
Flussdaten mit Argus erfassen und analysieren.................................... 138
4.4.1
Architektur............................................................................................ 139
4.4.2 Merkmale.............................................................................................. 139
4.4.3 Grundlegender Datenabruf................................................................... 140
4.4.4 Weitere Informationen über Argus........................................................ 142
4.5
Überlegungen zur Speicherung von Sitzungsdaten............................... 142
4.6
Zusammenfassung................................................................................ 144
5. FPC-Daten....................................................................................145
5.1
Dumpcap.............................................................................................. 147
5.2
Daemonlogger...................................................................................... 149
5.3
Netsniff-NG........................................................................................... 150
5.4
Das passende FPC-Erfassungswerkzeug auswählen............................. 152
5.5
Die FPC-Datenerfassung planen............................................................ 153
5.5.1
Speicherplatz........................................................................................ 153
5.5.2 Den Durchsatz an der Sensorschnittstelle mit Netsniff-NG und
Ifpps berechnen.................................................................................... 155
5.5.3 Den Durchsatz an der Sensorschnittstelle mithilfe von
Sitzungsdaten berechnen..................................................................... 156
5.6
Den Speicherbedarf für FPC-Daten senken........................................... 159
5.6.1
Dienste ausschließen............................................................................ 159
5.6.2 Kommunikation zwischen bestimmten Hosts ausschließen...................161
5.7
Die Aufbewahrung der FPC-Daten verwalten......................................... 163
5.7.1
Aufbewahrung nach Zeit....................................................................... 164
5.7.2 Aufbewahrung nach Umfang................................................................. 164
5.8
Zusammenfassung................................................................................ 169
12 Inhaltsverzeichnis
6. Paketstringdaten......................................................................... 171
6.1
Was sind Paketstringdaten?.................................................................. 172
6.2
PSTR-Datenerfassung........................................................................... 174
6.2.1
PSTR-Daten manuell generieren........................................................... 176
6.2.2 URLsnarf............................................................................................... 177
6.2.3 Httpry.................................................................................................... 178
6.2.4 Justniffer................................................................................................181
6.3
PSTR-Daten anzeigen............................................................................ 186
6.3.1
Logstash............................................................................................... 186
6.3.2 Rohtextzerlegung mit BASH-Tools......................................................... 195
6.4
Teil 2:
Zusammenfassung................................................................................ 198
Erkennung
199
7. Erkennungsmechanismen, Einbruchs­indikatoren und
Signaturen...................................................................................201
7.1
Erkennungsmechanismen..................................................................... 201
7.2
Einbruchsindikatoren und Signaturen...................................................203
7.2.1
Host- und Netzwerkindikatoren............................................................204
7.2.2 Statische Indikatoren............................................................................205
7.2.3 Variable Indikatoren..............................................................................208
7.2.4 Evolution von Indikatoren und Signaturen............................................ 210
7.2.5 Signaturen optimieren.......................................................................... 212
7.2.6 Entscheidende Kontextinformationen für Indikatoren und Signaturen... 214
7.3
Indikatoren und Signaturen verwalten.................................................. 216
7.3.1
Einfache Verwaltung von Indikatoren und Signaturen mit CSV-Dateien... 217
7.3.2 Masterliste der Indikatoren und Signaturen.......................................... 218
7.3.3 Revisionstabelle für Indikatoren und Signaturen.................................. 221
Inhaltsverzeichnis 13
7.4
Frameworks für Indikatoren und Signaturen.........................................223
7.4.1
OpenIOC...............................................................................................223
7.4.2 STIX......................................................................................................226
7.5
Zusammenfassung................................................................................228
8. Reputationsgestützte Erkennung............................................... 229
8.1
Öffentliche Reputationslisten...............................................................230
8.1.1
Gängige öffentliche Reputationslisten.................................................. 231
8.1.2
Häufig auftretende Probleme bei der Verwendung öffentlicher
Reputationslisten..................................................................................236
8.2
Automatisieren der reputationsgestützten Erkennung..........................239
8.2.1
Manuelles Abrufen und Erkennen mit BASH-Skripten...........................239
8.2.2 Collective Intelligence Framework (CIF).................................................245
8.2.3 Reputationsgestützte IP-Adressenerkennung mit Snort.......................249
8.2.4 Reputationsgestützte IP-Adressenerkennung mit Suricata................... 251
8.2.5 Reputationserkennung mit Bro.............................................................254
8.3
Zusammenfassung................................................................................258
9. Signaturgestützte Erkennung mit Snort und Suricata.................261
9.1
Snort.....................................................................................................262
9.1.1
Die Architektur von Snort......................................................................263
9.2
Suricata................................................................................................265
9.2.1
Die Architektur von Suricata.................................................................266
9.3
IDS-Engines in Security Onion austauschen.........................................268
9.4
Snort und Suricata initialisieren............................................................269
9.5
Snort und Suricata konfigurieren..........................................................272
9.5.1
Variablen...............................................................................................273
9.5.2 Regelsätze definieren...........................................................................277
9.5.3 Alarmausgabe.......................................................................................284
14 Inhaltsverzeichnis
9.5.4 Snort-Präprozessoren...........................................................................287
9.5.5 Zusätzliche Befehlszeilenargumente für den NIDS-Modus....................288
9.6
IDS-Regeln............................................................................................290
9.6.1
Aufbau von Regeln................................................................................290
9.6.2 Optimierung von Regeln.......................................................................308
9.7
Snort- und Suricata-Alarme anzeigen................................................... 316
9.7.1
Snorby.................................................................................................. 317
9.7.2 Sguil..................................................................................................... 318
9.8
Zusammenfassung................................................................................ 318
10. Bro...............................................................................................319
10.1
Grundprinzipien von Bro.......................................................................320
10.2
# ausführen..........................................................................................322
10.3
Bro-Protokolle.......................................................................................322
10.4
Eigene Erkennungswerkzeuge mit Bro erstellen...................................327
10.4.1 Dateien extrahieren..............................................................................328
10.4.2 Selektive Dateiextraktion......................................................................330
10.4.3 Dateien aus laufendem Netzwerkverkehr entnehmen...........................332
10.4.4 Bro-Code verpacken..............................................................................335
10.4.5 Konfigurationsoptionen hinzufügen......................................................335
10.4.6 Darknet-Überwachung mit Bro..............................................................338
10.4.7 Das Darknet-Skript erweitern................................................................346
10.4.8 Die Standardverarbeitung von Benachrichtigungen aufheben..............346
10.4.9 Benachrichtigungen unterbinden, E-Mails senden und
Alarme auslösen – auf die einfache Weise............................................ 351
10.4.10 Den Bro-Protokollen neue Felder hinzufügen........................................352
10.5
Zuammenfassung.................................................................................356
Inhaltsverzeichnis 15
11. Anomaliegestützte Erkennung anhand von
statistischen Daten.................................................................... 357
11.1
Kommunikationsintensive Hosts mit SiLK finden..................................358
11.2
Diensterkennung mit SiLK.....................................................................362
11.3
Weitere Erkennungsmöglichkeiten mithilfe von Statistiken..................368
11.4
Statistiken mit Gnuplot grafisch darstellen........................................... 371
11.5
Statistiken mit Google Charts grafisch darstellen.................................375
11.6
Statistiken mit Afterglow grafisch darstellen.........................................380
11.7
Zusammenfassung................................................................................386
12. Frühwarn-Honeypots zur Erkennung.......................................... 387
12.1
Frühwarn-Honeypots............................................................................388
12.2
Arten von Honeypots............................................................................389
12.3
Architektur von Frühwarn-Honeypots....................................................390
12.3.1 Phase 1: Die zu simulierenden Geräte und Dienste bestimmen............. 391
12.3.2 Phase 2: Die Platzierung der Honeypots bestimmen............................. 391
12.3.3 Phase 3: Alarmierung und Protokollierung entwickeln..........................393
12.4
Honeypotplattformen...........................................................................394
12.4.1 Honeyd.................................................................................................395
12.4.2 Der SSH-Honeypot Kippo......................................................................399
12.4.3 Tom’s Honeypot....................................................................................404
12.4.4 Honeydocs............................................................................................407
12.5
Zusammenfassung................................................................................ 410
16 Inhaltsverzeichnis
Teil 3:
Analyse
411
13. Paketanalyse...............................................................................413
13.1
Gestatten: das Paket!............................................................................ 414
13.2
Paketmathematik.................................................................................. 416
13.2.1 Hexdarstellung von Bytes..................................................................... 416
13.2.2 Hexwerte ins Binär- und Dezimalformat umwandeln............................. 418
13.2.3 Bytes zählen......................................................................................... 419
13.3
Pakete zerlegen....................................................................................422
13.4
Tcpdump für die NSM-Analyse..............................................................428
13.5
Tshark für die Paketanalyse..................................................................432
13.6
Wireshark für die NSM-Analyse.............................................................437
13.6.1 Pakete erfassen....................................................................................437
13.6.2 Das Format der Zeitanzeige ändern.......................................................439
13.6.3 Übersicht über die Paketerfassung.......................................................440
13.6.4 Protokollhierarchie............................................................................... 441
13.6.5 Endpunkte und Konversationen............................................................442
13.6.6 Streams verfolgen.................................................................................443
13.6.7 E/A-Diagramm......................................................................................444
13.6.8 Objekte exportieren..............................................................................446
13.6.9 Benutzerdefinierte Spalten hinzufügen................................................447
13.6.10 Zerlegungsoptionen für Protokolle einrichten.......................................449
13.6.11 Erfassungs- und Anzeigefilter...............................................................450
13.7
Paketfilter............................................................................................. 451
13.7.1 Berkeley-Paketfilter (BPF)..................................................................... 451
13.7.2 Anzeigefilter von Wireshark..................................................................456
13.8
Zusammenfassung................................................................................ 461
Inhaltsverzeichnis 17
14. Aufklärung über Freund und Feind............................................. 463
14.1
Der Aufklärungszyklus für NSM............................................................463
14.1.1 Definition der Anforderungen...............................................................464
14.1.2 Planung.................................................................................................465
14.1.3 Erfassung..............................................................................................466
14.1.4 Verarbeitung.........................................................................................466
14.1.5 Analyse.................................................................................................467
14.1.6 Weitergabe...........................................................................................467
14.2
Aufklärung über eigene Elemente.........................................................467
14.2.1 Anamnese und physische Untersuchung von Netzwerkelementen.......468
14.2.2 Ein Bestandsmodell des Netzwerks aufstellen......................................469
14.2.3 PRADS (Passive Real-Time Asset Detection System).............................473
14.3
Aufklärung über Bedrohungen..............................................................480
14.3.1 Recherche über gegnerische Hosts.......................................................482
14.3.2 Recherche über schädliche Dateien......................................................492
14.4
Zusammenfassung................................................................................500
15. Der Analysevorgang....................................................................501
15.1
Analysemethoden.................................................................................502
15.1.1 Relationale Untersuchung.....................................................................502
15.1.2 Differenzielle Diagnose.........................................................................509
15.1.3 Umsetzen der Analysemethoden.......................................................... 517
15.2
Empfohlene Vorgehensweisen für die Analyse...................................... 518
15.2.1 Bei Paketen können Sie sich auf nichts verlassen................................. 518
15.2.2 Machen Sie sich klar, wie die Daten abstrahiert werden....................... 518
15.2.3 Vier Augen sehen mehr als zwei............................................................ 519
15.2.4 Laden Sie einen Angreifer niemals zum Tanz ein................................... 519
15.2.5 Pakete sind von Natur aus gut..............................................................520
18 Inhaltsverzeichnis
15.2.6 Wireshark macht so wenig einen Analytiker wie ein Teleskop
einen Astronomen.................................................................................520
15.2.7 Klassifizierung hilft............................................................................... 521
15.2.8 Die Zehnerregel.....................................................................................522
15.2.9 Wenn Sie Hufe klappern hören, halten Sie nach
Pferden Ausschau – nicht nach Zebras..................................................523
15.3
Morbidität und Mortalität von Zwischenfällen......................................523
15.3.1 M&M in der Medizin..............................................................................524
15.3.2 M&M in der Informationssicherheit......................................................524
15.4
Zusammenfassung................................................................................530
A. Steuerskripte für Security Onion.................................................531
A.1
Befehle auf oberster Ebene................................................................... 531
A.2
Befehle zur Serversteuerung................................................................532
A.3
Befehle zur Sensorsteuerung................................................................535
B. Wichtige Dateien und Verzeichnisse von Security Onion............ 539
B.1
Anwendungsverzeichnisse und Konfigurationsdateien.........................539
B.2
Verzeichnisse für Sensordaten.............................................................. 541
C. Paketheader............................................................................... 543
D. Umrechnungstabelle
Dezimalzahlen/Hex/ASCII......................................................... 549
Stichwortverzeichnis........................................................................551
19
Danksagung
In 2. Korinther 12, 9 heißt es: »Und er hat zu mir gesagt: Lass dir an meiner Gnade
genügen; denn meine Kraft ist in den Schwachen mächtig. Darum will ich mich am
allerliebsten rühmen meiner Schwachheit, auf dass die Kraft Christi bei mir wohne.«
Dass ich in der Lage war, dieses Buch zu schreiben, legt Zeugnis davon ab, dass Gottes
Kraft in den Schwachen mächtig ist. Es war das schwierigste Projekt, das ich jemals in Angriff genommen habe, und es war mein Glaube an Gott, der mich durchhalten ließ. Seine
Hilfe hat dieses Buch und alle meine anderen Projekte möglich gemacht. Ich hoffe sehr,
dass mein Werk Zeugnis von seiner großartigen Macht ablegen kann.
Dieses Buch war nur dank der direkten und indirekten Beiträge vieler Menschen möglich.
Ich möchte diese Gelegenheit nutzen, ihnen zu danken.
Ellen, du bist meine Liebe, meine Stütze, meine Stärke und mein größter Fan. Nichts von
alldem wäre ohne dich möglich gewesen. Ich möchte dir dafür danken, dass du den Stress,
die Verzweiflung, die hektischen Stunden und den allgemeinen Wahnsinn ertragen hast,
die mit dem Schreiben eines Buches verbunden sind. Ich möchte dir für die Hilfe danken,
das Buch Korrektur zu lesen. Da konntest du endlich deinen Abschluss in Anglistik nutzen. Ich liebe dich und bin so stolz, dein Mann zu sein.
Mama und Papa, wegen eures Einflusses bin ich der Mensch geworden, der ich bin. Alles,
was ich tue, ist und bleibt eine Ehrung eures Charakters und eurer Liebe. Ich liebe dich,
Papa. Ruhe in Frieden, Mama.
Familie Sanders, wir sind zwar nicht viele, aber unsere gegenseitige Liebe ist enorm und
für mich so wichtig. Auch wenn wir weit voneinander entfernt leben, weiß ich, dass ihr
mich liebt und mich unterstützt, und dafür danke ich euch.
Familie Perkins, es war wirklich erstaunlich, wie ihr mich in eurem Leben willkommen
geheißen habt, und ich fühle mich gesegnet, dass ich eure Liebe und Unterstützung
genieße.
Jason Smith, du bist buchstäblich der klügste Mensch, dem ich je begegnet bin. Du bist
nicht nur ein großartiger Mitarbeiter und Co-Autor, sondern hast dich auch als großartiger Freund erweisen. Ich scheue mich nicht zu sagen, dass du für mich wie ein Bruder bist.
Ich bin ewig dankbar für alles.
David Bianco und Liam Randall, ich kann euch nicht genug für eure Beiträge zu diesem
Buch danken. Ich schätze sie weit mehr, als ihr euch vorstellen könnt.
20 Danksagung
Was meine (ehemaligen und jetzigen) Mitarbeiter betrifft, war ich immer der Überzeugung, dass man selbst zu einer besseren Person wird, wenn man sich mit guten Menschen
umgibt. Ich habe das Glück, mit den hervorragenden Menschen zusammenzuarbeiten,
die zu den Besten und Brillantesten in der Branche gehören. Mein besonderer Dank gilt
Jimmy, Jay, Suzanne, Teresa, John, Tom, Don, Rad, Larry, Jaime, James, Bob und Alec
von der InGuardians-Familie. Ich möchte auch meine besondere Anerkennung für Mike
Poor ausdrücken, der das Geleitwort zu diesem Buch geschrieben hat und zu meinen
Paketninja-Idolen gehört.
Den Mitarbeitern bei Syngress möchte ich dafür danken, dass sie mir die Gelegenheit geboten haben, dieses Buch zu schreiben und meinen Traum wahr werden zu lassen.
Der technische Inhalt und die Richtung, die dieses Buches genommen hat, sind das
Produkt von mehr Personen, als ich hier nennen kann, aber ich werde es wenigstens
versuchen. Neben den bereits genannten möchte ich auch den folgenden Personen für
ihre Beiträge danken, sei es die Begutachtung eines Kapitels oder die Besprechung einer
Idee. Ohne euch wäre dies nicht möglich gewesen:
Alexi Valencia, Ryan Clark, Joe Kadar, Stephen Reese, Tara Wink, Doug Burks, Richard
Bejtlich, George Jones, Richard Friedberg, Geoffrey Sanders, Emily Sarneso, Mark Thomas,
Daniel Ruef, der Rest des CERT-NetSA-Teams, Joel Esler, das Bro-Team, Mila Parkour,
Dustin Weber und Daniel Borkmann.
Chris Sanders
21
Die Autoren
Chris Sanders (Hauptautor)
Chris Sanders ist Berater, Autor und Forscher auf dem Gebiet der Informationssicherheit. Ursprünglich stammt er aus Mayfield in Kentucky, das 30 Meilen südwestlich
einer Kleinstadt namens Possum Trot liegt, 40 Meilen südöstlich der Gehöftansammlung Monkey's Eyebrow und knapp nördlich einer Kurve, die allen Ernstes den Namen
Podunk trägt.
Chris ist leitender Sicherheitsanalytiker bei InGuardins. Er hat umfassende Erfahrung in
der Unterstützung von Behörden und militärischen Dienststellen sowie mehrerer Fortune500-Unternehmen. In mehreren Positionen beim US-Verteidigungsministerium hat Chris
erheblich dabei geholfen, die Rolle des CNDSP-Modells (Computer Network Defense Service Provider) zu fördern und verschiedene NSM- und Aufklärungswerkzeuge zu erstellen,
die zurzeit zur Verteidigung der Nation eingesetzt werden.
Chris hat mehrere Bücher und Artikel geschrieben, darunter den internationalen Bestseller Practical Packet Analysis von No Starch Press, der zurzeit seine zweite Auflage erlebt. Außerdem ist er mit mehreren Branchenzertifizierungen ausgezeichnet worden,
darunter SANS GSE und CISSP.
Im Jahr 2008 hat Chris den Rural Technology Fund gegründet. Dabei handelt es sich
um eine nicht kommerzielle Organisation nach Artikel 501(c)(3), die Studenten aus
länd­lichen Gegenden Stipendien auf dem Gebiet der Computertechnologie verleiht. Die
­Organisation fördert durch verschiedene Programme auch die technologische Entwicklung in ländlichen Gegenden. Sie hat bereits Tausende von Dollar an Stipendien und
Unterstützung für Studenten aus dem ländlichen Raum bereitgestellt.
Wenn Chris nicht gerade bis zu den Knien in Paketen steckt, besucht er die Spiele der
Basketballmannschaft Wildcats der University of Kentucky, betätigt sich als Grillmeister
und Hobby-Drohnenkonstrukteur und verbringt viel Zeit am Strand. Zurzeit lebt er mit
seiner Frau Ellen in Charleston, South Carolina.
Chris unterhält Blogs auf http://www.appliednsm.com und http://www.chrissanders.org.
Auf Twitter finden Sie ihn als @chrissanders88.
22 Die Autoren
Jason Smith (Co-Autor)
Jason Smith arbeitet tagsüber als Intrusion-Detection-Analytiker und betätigt sich in seiner Freizeit als Schrottingenieur. Er stammt ursprünglich aus Bowling Green in Kentucky
und hat seine Karriere mit Data Mining in umfangreichen Datenmengen und der FiniteElement-Methode als aufstrebender Physiker begonnen. Durch schieren Zufall brachte
ihn sein Faible für Data Mining zu Informationssicherheit und Network Security Monitoring, wo er der Faszination der Datenbearbeitung und Automatisierung erlag.
Jason blickt auf eine lange Tätigkeit zurück, bei der er Staats- und Bundesbehörden beim
Schutz ihres Perimeternetzwerks geholfen hat. Zurzeit arbeitet er als Sicherheitsingenieur
bei Mandiant. Im Rahmen seiner Entwicklungsarbeit hat er mehrere Open-Source-Projekte
aufgebaut, die zu den empfohlenen Werkzeugen für das DISA-CNDSP-Programm gehören.
Seine Wochenenden verbringt er regelmäßig in der Garage, um dort alles mögliche zu
bauen, von Arcade-Spielautomaten bis zu Monoposto-Rennwagen. Zu seinen anderen
Hobbys gehören Hausautomatisierungstechnik, Schusswaffen, Monopoly, Gitarrespielen und Essen. Jason liebt das ländliche Amerika, ist ein passionierter Autofahrer und
wird von einem rücksichtslosen Lernwillen angetrieben. Zurzeit wohnt er in Frankfort,
Kentucky.
Sein Blog finden Sie auf http://www.appliednsm.com, und er twittert als @automayt.
David J. Bianco (Mitwirkender)
Bevor er Leiter des Hunt Teams bei Mandiant wurde, hat David fünf Jahre damit
verbracht, ein aufklärungsgestütztes Erkennungs- und Reaktionsprogramm für ein
Fortune-5-Unternehmen aufzubauen. Dabei hat er die Erkennungsstrategien für ein
Netzwerk aus fast 600 NSM-Sensoren in mehr als 160 Ländern festgelegt und die Krisenreaktion auf die schwersten Zwischenfälle geleitet hat, die es in dem Unternehmen
gegeben hat, hauptsächlich gezielte Angriffe. Als Blogger, Redner und Autor ist er in der
Gemeinschaft der Sicherheitsexperten aktiv.
Sie können David häufig zu Hause antreffen, wo er Doctor Who schaut, einen seiner vier
Dudelsäcke spielt oder einfach mit seinen Kindern herumalbert. Er liebt lange Spaziergänge fast überall, nur nicht am Strand.
David führt ein Blog auf http://detect-respond.blogspot.com und ist als @DavidJBianco auf
Twitter unterwegs.
Die Autoren 23
Liam Randall (Mitwirkender)
Liam Randall geschäftsführender Teilhaber bei der Broala LLC in San Francisco, der Beratungsgruppe von Bro Core Teams. Er stammt ursprünglich aus Louisville in Kentucky, wo
er als Systemadministrator arbeitete, während er bei der Xavier University seinen Bachelor
in Informatik machte. Seine erste Arbeit auf dem Gebiet der Sicherung bestand darin,
Gerätetreiber und XFS-Software für Geldautomaten zu schreiben.
Zurzeit ist er als Berater für hochvolumige Sicherheitslösungen für Fortune 50, Research
and Education Networks, verschiedene Teile der Streitkräfte und andere Organisationen
tätig, die sehr auf Sicherheit achten müssen. Er ist als Redner beim Shmoocon, beim
Darbycon und eim MIRcon aufgetreten und gibt regelmäßig Bro-Kurse bei Veranstaltungen zum Thema Sicherheit.
Liam ist Ehemann und Vater und verbringt seine Wochenenden damit, Wein und Käse zu
machen, im Garten zu arbeiten und technische Spielereien zu reparieren. Als Liebhaber
von Freiluftaktivitäten nehmen seine Frau und er an Triatholons teil, schwimmen lange
Strecken und genießen die örtliche Gemeinschaft.
Liam führt ein Blog auf http://liamrandall.com und ist twittert als @Hectaman.
25
Geleitwort
Eine Infrastruktur für Network Security Monitoring aufzubauen und zu betreiben ist ein
anspruchsvolles Unterfangen. Chris Sanders und sein Autorenteam haben ein Grundgerüst für NSM geschaffen und geben dem Leser einen formalen Plan an die Hand, um
Network Security Monitoring in die Praxis umzusetzen.
Mittlere und große Organisationen stöhnen unter der Menge der Daten, die sie erfassen.
Bei mehr als 100 Millionen Ereignissen in einigen Fällen ist es unverzichtbar, eine Überwachungsinfrastruktur und standardisierte Verfahren zur Hand zu haben, die sich an diese
Größenordnung anpassen lassen.
Wer suchet, der findet, heißt es, aber auch der Umkehrschluss ist wahr. Ohne Analyse hat
es keinen Sinn, Daten zu erfassen, und manchmal nicht einmal, sich um eine Erkennung
zu bemühen. Dieses Buch gibt Ihnen die Schlüssel für die einzelnen Schritte des NSMZyklus an die Hand: Erfassung, Erkennung und Analyse.
In den 1930er Jahren kämpften viele Piloten aus der zivilen Luftfahrt darum, ihre Fähigkeiten für die Verteidigung des Landes einsetzen zu dürfen. Heute ist es wieder an der Zeit,
dass Zivilisten eine aktivere Rolle in der Landesverteidigung übernehmen. Machen Sie
sich nichts vor: Wir werden angegriffen. Produzierendes Gewerbe, Chemie, Öl und Gas,
Energie und viele kritische Sektoren unserer Gesellschaft leiden unter einer Serie koordinierter und systematischer Angriffe. Während die Theoretiker über die Möglichkeiten zukünftiger kybernetischer Kriegführung philosophieren, stecken die Praktiker an der Front
schon bis zum Hals darin.
Ich rufe nicht zu den Waffen, sondern zur Analyse. Haben Sie einen Zwischenfall auf
Root-Ebene erlebt? Dann müssen Sie Ihre Protokolle analysieren. Die meisten Netzwerkangriffe hinterlassen Spuren, und es ist Aufgabe der Systemadministratoren, die Protokolle auf Spuren von Einbrüchen zu untersuchen. Allerdings muss auch der Betreiber die
Protokolle überprüfen, um die Systemleistung zu verbessern und um eine Analyse für
Geschäftszwecke durchzuführen. Schon die Steigerung der Leistung kann den Ertrag steigern, ganz zu schweigen davon, was sich mit einer geschäftlichen Analyse erreichen lässt.
Wir bei InGuardians werden zu Hilfe gerufen, wenn es darum geht, auf umfangreiche Einbrüchen zu reagieren. Die meisten Organisationen protokollieren die relevanten Daten von
wichtigen Netzwerkgeräten, Proxys, Firewalls, Systemen und Anwendungen. Diese Daten
werden längere Zeit gespeichert, ohne dass das direkt zum geschäftlichen Ertrag beiträgt. In
vielen Fällen können wir allein durch die Analyse der Protokolle gegenwärtige und frühere
Einbrüche erkennen.
26 Geleitwort
Wenn Sie das nächste Mal an Ihrer Konsole sitzen, untersuchen Sie einige Protokolle. Vielleicht denken Sie jetzt: »Ich weiß nicht, wonach ich suchen soll.« Fangen Sie mit dem an,
was Sie wissen, was Sie verstehen und was Ihnen gleichgültig ist, und verwerfen Sie es.
Alles andere ist von Interesse.
Semper vigilans,
Mike Poor
27
Vorwort
Ich liebe es, Schurken zu fangen. Schon als Kind wollte ich das tun, auf welche Weise auch
immer. Ob ich mir das nächstbeste Handtuch als Superheldencape umlegte oder ob ich
mit meinen Freunden Räuber und Gendarm spielte, ich genoss die Aufregung, Bösewichter aller Arten der Gerechtigkeit zu übergeben. So sehr ich mich auch bemühte, es gelang
mir niemals, meine Wut so zu steigern, dass ich mich in ein riesiges, grünes Monster verwandelte, und von wie vielen Spinnen ich auch gebissen wurde, entwickelte ich doch nie
die Fähigkeit, Spinnweben aus meinen Handgelenken zu verschießen. Ich erkannte auch
ziemlich schnell, das ich nicht aus dem Holz war, aus dem Gesetzeshüter geschnitzt sind.
Als mir all dies bewusst wurde und ich auch erkannte, dass ich nicht reich genug war, um
mir eine Reihe extravaganter technischer Spielereien zu bauen und in einem Fledermauskostüm durch die Nacht zu schwirren, wandte ich mein Interesse Computern zu. Mehrere
Jahre später hatte ich eine Position erreicht, in der ich meinem Kindheitstraum nachgehen
konnte, Schurken zu fangen, wenn auch nicht auf die Weise, die ich mir ursprünglich
vorgestellt hatte.
Ich fange Schurken durch angewandtes Network Security Monitoring (NSM). Das ist,
worum es in diesem Buch geht. Der Grundsatz von NSM lautet, dass jegliche Vorbeugung
irgendwann versagen wird. Wie viel Zeit Sie auch immer darin investieren, Ihr Netzwerk
abzusichern, die Schurken werden eines Tages die Oberhand gewinnen. Wenn das geschieht, müssen Sie sowohl technisch als auch organisatorisch so aufgestellt sein, dass Sie
die Gegenwart eines Eindringlings erkennen und darauf reagieren können. Sie müssen in
der Lage sein, einen Zwischenfall zu deklarieren und die Angreifer aus Ihrem Netzwerk zu
vertreiben, bevor sie erheblichen Schaden anrichten können.
»Aber wie kann ich schädliche Dinge erkennen?«
Der Erkenntnisweg des NSM beginnt gewöhnlich mit dieser Frage. Wissenschaftliche Erkenntnisse entwickeln sich weiter. Noch bis in die 1980er glaubten Mediziner, dass Milch
eine Behandlungsform für Magengeschwüre sei. Mit der Zeit fanden Wissenschaftler jedoch heraus, dass Magengeschwüre von dem Bakterium Helicobacter pyroli hervorgerufen
werden und dass Milchprodukte ihr Wachstum sogar fördern können.1 Angebliche Fakten
ändern sich, und obwohl wir gern glauben wollen, dass die meisten Naturwissenschaften exakte Wissenschaften sind, ist das nicht der Fall. Jegliches wissenschaftliches Wissen
beruht auf begründeten Vermutungen, für die die zum jeweiligen Zeitpunkt bestmögli1 Jay, C. (3. November 2008). »Why it’s called the practice of medicine«. Abgerufen von http://www.wellsphere.com/chronic-pain-article/why-it-s-called-the-practice-of-medicine/466361
28 Vorwort
chen Daten herangezogen wurden. Wenn im Laufe der Zeit mehr Daten verfügbar werden,
können sich Antworten auf alte Fragen ändern und vermeintliche Tatsachen neu definiert
werden. Das gilt sowohl für die Medizin als auch für NSM.
Als ich mit der Anwendung von NSM begann, gab es leider noch nicht viele Quellen zu
diesem Thema. Ehrlich gesagt, gibt es bis heute nicht viele. Abgesehen von gelegentlichen
Blogs von Pionieren der Branche und wenigen ausgewählten Büchern scheinen diejenigen, die etwas darüber lernen wollen, sich selbst überlassen zu sein. Verstehen Sie mich
nicht falsch: Es gibt massenhaft Bücher über TCP/IP, Paketanalyse und die verschiedenen
Intrusion-Detection-Systeme. Das sind zwar alles wichtige Facetten des NSM, aber diese
Bücher beschreiben nicht das Prinzip des Network Security Monitoring im Ganzen, ebenso wenig wie Sie aus einem Buch über Schraubenschlüssel herauszufinden lernen, warum
ein Auto nicht anspringt.
Dieses Buch ist der Anwendung des NSM gewidmet. Es gibt nicht einfach einen Überblick
über die Werkzeuge oder die einzelnen Aspekte des NSM, sondern es beschreibt den Vorgang und zeigt, wie diese Werkzeuge und Aspekte in der Praxis helfen.
Zielpublikum
Letzten Endes ist dieses Buch als Leitfaden dafür gedacht, wie man ein praktizierender
NSM-Analytiker werden kann. Zu meinen Aufgaben in meiner Arbeitsstelle gehört auch
die Ausbildung neuer Analytiker. Dieses Buch ist nicht nur als Fachbuch für die Öffentlichkeit gedacht, sondern auch als Lehrbuch für eine solche Ausbildung. Daher bestand
mein Ziel darin, dass Sie dieses Buch von vorn bis hinten lesen können, um ein grundlegendes Verständnis der Kernprinzipien zu gewinnen.
Wenn Sie bereits als Analytiker tätig sind, hoffe ich, dass Ihnen dieses Buch eine Grundlage bietet, Ihre Analysetechniken zu erweitern, sodass Sie noch wirkungsvoller arbeiten
können, als Sie es jetzt schon tun. Ich habe mit mehreren guten Analytikern gearbeitet, die
zu großartigen Analytikern werden konnten, weil sie in der Lage waren, ihre Effektivität
durch einige der hier vorgestellten Techniken und Informationen zu steigern.
Die wirkungsvolle Ausübung von NSM erfordert eine gewisse Gewandtheit im Umgang
mit den verschiedenen Tools. Daher werden in diesem Buch auch einige dieser Werkzeuge
besprochen, z. B. das IDS Snort oder die Analysesuite SiLK, allerdings vom Standpunkt
der Analytiker aus. Diejenigen, die mit der Installation und Wartung solcher Programme
befasst sind, werden feststellen, dass ich dieses Thema nur streife. Stattdessen gebe ich bei
Gelegenheit andere Quellen an, in denen die entsprechenden Informationen zu finden
sind.
Außerdem konzentriere ich mich in diesem Buch auf kostenlose und Open-Source-Tools.
Damit will ich nicht nur denen entgegenkommen, die nicht das Budget für kommerzielle
Analysewerkzeuge wie NetWitness oder Arcsight haben, sondern auch die Vorteile der
Verwendung von Open-Source-Tools vorführen, die von Analytikern entworfen wurden
und mehr Einblicke darin geben, wie diese mit den Daten umgehen.
Vorwort 29
Voraussetzungen
Die erfolgreichsten NSM-Analytiker sind diejenigen, die bereits Erfahrungen in anderen
Gebieten der Informationstechnologie gesammelt haben, bevor sie beginnen, auf dem
Feld der Sicherheit zu arbeiten. Das liegt daran, dass sie sich dadurch schon einige Fähigkeiten angeeignet haben, die für Analytiker wichtig sind, z. B. ein Verständnis von Systemen oder der Verwaltung von Netzwerken. Als Ersatz für solche Erfahrung habe ich
eine kurze Liste von Büchern aufgestellt, die ich sehr gern gelesen habe und die meiner
Meinung nach Einsichten in einige wichtige Fertigkeiten für Analytiker geben. Ich habe
mich bemüht, dieses Buch so zu schreiben, dass nicht allzu viel Vorwissen erforderlich ist,
aber empfehle Ihnen trotzdem, einige der folgenden Bücher als Ergänzung zu dem Stoff
in diesem Buch zu lesen.
•• TCP/IP Illustrated, Vol. 1, Second Edition: The Protocols von Kevin Fall und Dr. Richard
Stevens (Addison-Wesley 2011)
Grundkenntnisse in TCP/IP gehören zu den unverzichtbaren Voraussetzungen, um
NSM wirkungsvoll betreiben zu können. Dieses klassische Lehrbuch von Dr. Richard
Stevens wurde von Kevil Fall um die neuesten Protokolle, Standards und empfohlenen
Vorgehensweisen sowie um IPv6, Sicherheitsfibeln für die einzelnen Protokolle usw.
ergänzt.
•• The Tao of Network Security Monitoring von Richard Bejtlich (Addison-Wesley, 2004).
Richard Bejtlich hat viele der Grundprinzipien von NSM festgelegt, weshalb ich das
vorgenannte Werk und seinen Blog in diesem Buch häufig zitieren werden. Sein Buch
ist zwar fast zehn Jahre alt, aber ein Großteil des Stoffes ist im Rahmen des NSM nach
wie vor gültig.
•• Practical Packet Analysis von Chris Sanders (No Starch Press, 2010)
Ich bin nicht über schamlose Eigenwerbung erhaben! Während das Buch von Dr.
Stevens ein gründliches Nachschlagewerk zu TCP/IP darstellt, geht Practical Packet
Analysis die Paketanalyse aus praktischer Sicht an, wobei Wireshark als Werkzeug der
Wahl verwendet wird. Hier geht es darum, Pakete zu untersuchen, und wenn Sie sich
Pakete noch nie zuvor genauer angesehen habe, empfehle ich es Ihnen als Grundlehrbuch.
•• Counter Hack Reloaded von Ed Skoudis und Tom Liston (Prentice Hall, 2006)
Dieses Buch ist eines der besten allgemeinen Sicherheitsbücher, die Sie kriegen können.
Es behandelt Aspekte von praktisch allem, und ich kann es jedem ganz unabhängig
von seiner Erfahrung nur empfehlen. Wenn Sie noch nie auf dem Gebiet der Sicherheit
gearbeitet haben, ist Counter Hack Reloaded Pflichtlektüre für Sie.
30 Vorwort
Der Aufbau dieses Buches
Dieses Buch ist in die drei Hauptteile Erfassung, Erkennung und Analyse für die drei Kerngebiete des NSM gegliedert. In den einzelnen Kapiteln gehe ich auf die Werkzeuge, Techniken und Prozeduren des entsprechenden Gebiets ein. Als einfacher Junge vom Land aus
Kentucky habe ich mich bemüht, in möglichst einfacher Sprache ohne viele Ausschmückungen zu schreiben. Ich habe auch versucht, kompliziertere Vorgänge nach Möglichkeit in eine Folge nachvollziehbarer Schritte zu zerlegen. Wie bei jedem Buch, in dem es
um allgemeine Prinzipien geht, werden auch hier nicht sämtliche möglichen Situationen
und Grenzfälle abgedeckt. Letzten Endes besteht dieses Buch aus Theorien, die auf den
Forschungsarbeiten, Erfahrungen und Meinungen der Autoren beruhen. Wenn ich daher
etwas als bewährte oder empfohlene Vorgehensweise bezeichne, kann es durchaus sein,
dass Ihre eigenen Forschungen, Erfahrungen und Meinungen Sie zu anderen Schlussfolgerungen führen. Das sollte Sie nicht beunruhigen, denn schließlich ist NSM angewandte
Wissenschaft.
Kapitel 1: Network Security Monitoring in der Praxis
Das erste Kapitel erklärt, was Netword Security Monitoring ist und welche Bedeutung
es für die Sicherheit in der modernen Welt spielt. Hierin lernen Sie viele Kernbegriffe
und Voraussetzungen kennen, die in diesem Buch verwendet werden.
Teil 1: Erfassung
Kapitel 2: Die Datenerfassung planen
Das erste Kapitel im Teil über die Erfassung gibt eine Einführung in die Datenerfassung und einen Überblick über ihre Wichtigkeit. Hier wird auch das Applied
Collection Framework eingeführt, das dazu dient, anhand einer Risikobewertung
Entscheidungen darüber zu treffen, welche Daten erfasst werden sollen.
Kapitel 3: Sensoren
In diesem Kapitel wird die entscheidende Hardware für das NSM vorgestellt: die
Sensoren. Als Erstes erhalten Sie hier einen kurzen Überblick über die verschiedenen
NSM-Datentypen und die Arten von NSM-Sensoren. Dies führt uns zu wichtigen
Überlegungen für den Erwerb und die Bereitstellung der Sensoren. Am Ende besprechen wir die Platzierung der NSM-Sensoren im Netzwerk. Sie erfahren auch, wie Sie
Sichtfelddiagramme für die Analytiker aufstellen.
Kapitel 4: Sitzungsdaten
In diesem Kapitel geht es um die Wichtigkeit von Sitzungsdaten. Außerdem erhalten
Sie eine ausführliche Beschreibung der SiLK-Suite zur Erfassung von NetFlow-Daten.
Außerdem sehen wir uns kurz die Argus-Suite zur Erfassung und Untersuchung von
Sitzungsdaten an.
Kapitel 5: FPC-Daten
Am Anfang dieses Kapitels steht ein Überblick über FPC-Daten. Mit Netsniff-NG,
Daemonlogger und Dumpcap lernen Sie verschiedene Tools kennen, um PCAP-Daten
Vorwort 31
zu erfassen. Anschließend wird erörtert, wie Sie die Speicherung und Pflege von FPCDaten planen und wie Sie die Menge der zu speichernden Daten einschränken können.
Kapitel 6: Paketstringdaten
Dieses Kapitel gibt eine Einführung in PSTR-Daten (Paketstring) und ihren WErt für
die NSM-Analyse. Wir sehen uns verschiedene Methoden an, um mit Werkzeugen wie
Httpry und Justniffer PSTR-Daten zu generieren. Außerdem sehen wir uns die Werkzeuge Logstash und Kibana zur Zerlegung und Anzeige dieser Daten an.
Teil 2: Erkennung
Kapitel 7: Erkennungsmechanismen, Einbruchsindikatoren und Signaturen
In diesem Kapitel geht es um die Beziehung zwischen Erkennungsmechanismen und
Einbruchsindikatoren. Wir sehen uns an, wie Indikatoren logisch gegliedert und wie
sie zur Einbeziehung in ein NSM-Programm effizient verwaltet werden können. Dazu
gehören ein System zur Klassifizierung von Indikatoren sowie Messgrößen, um die
Genauigkeit der Indikatoren, die in verschiedenen Erkennungsmechanismen bereitgestellt wurden, zu berechnen und zu verfolgen. Außerdem sehen wir uns die beiden
Formate OpenIOC und STIX für Einbruchsindikatoren an.
Kapitel 8: Reputationsgestützte Erkennung
Der erste Typ von Erkennung, den wir in diesem Teil besprechen, ist die reputationsgestützte. Dabei sehen wir uns das Grundprinzip sowie verschiedene Quellen an,
mit deren Hilfe Sie herausfinden können, welche Reputation ein Gerät genießt. Sie
werden auch erfahren, wie Sie diesen Vorgang mit einfachen BASH-Skripten, mit
Snort, Suricata, CIF und Bro automatisieren können.
Kapitel 9: Signaturgestützte Erkennung mit Snort und Suricata
Die signaturgestützte Erkennung ist die herkömmliche Vorgehensweise. Dieses Kapitel
gibt eine Einführung darin und beschreibt die Verwendung der Intrusion-DetectionSysteme Snort und Suricata einschließlich einer ausführlichen Erklärung, wie Sie für
diese beiden Plattformen IDS-Signaturen anlegen.
Kapitel 10: Bro
Dieses Kapitel beschreibt Bro, eine weit verbreitete anomaliegestützte Erkennungslösung. Wir sehen uns die Architektur und die Sprache von Bro sowie mehrere praktische
Fälle an, die die Leistungsfähigkeit von Bro als IDS und als Protokollierungs-Engine
veranschaulichen.
Kapitel 11: Anomaliegestützte Erkennung anhand von statistischen Daten
In diesem Kapitel besprechen wir die Verwendung von Statistiken, um Anomlien im
Netzwerk zu erkennen. Dabei konzentrieren wir uns auf verschiedene NetFlow-Tools
wie Rwstats und Rwcount. Außerdem sehen wir uns an, wie Sie Statistiken mithilfe
von Gnuplot und der API von Google Charts grafisch darstellen können. Das Kapitel
enthält auch mehrere praktische Beispiele für Statistiken, die sich aus NSM-Daten generieren lassen.
32 Vorwort
Kapitel 12: Frühwarn-Honeypots zur Erkennung
Honeypots wurden ursprünglich nur zu Forschungszwecken verwendet, doch Frühwarn-Honeypots können auch als wirkungsvolles Erkennungswerkzeug dienen. Dieses Kapitel gibt einen Überblick über die verschiedenen Arten von Honeypots und
zeigt, wie Sie sie in einer NSM-Umgebung einsetzen können. Außerdem sehen wir uns
mit Honeyd, Kippo und Tom’s Honeypot einige beliebte Honeypot-Anwendungen an,
die sich für diesen Zweck eignen. Auch Honeydocs werden kurz angesprochen.
Teil 3: Analyse
Kapitel 13: Paketanalyse
Die wichtigste Fähigkeit eines NSM-Analytikers besteht darin, Paketdaten zu deuten
und zu entziffern. Um das wirkungsvoll tun zu können, sind Grundkenntnisse über
den Aufbau von Paketen erforderlich. Diese vermittelt Ihnen dieses Kapitel und stellt
Byte für Byte die Felder vor, aus denen ein Paket besteht. Zur Veranschaulichung verwenden wir Tcpdump und Wireshark. Des Weiteren beschäftigen wir uns mit Paketfiltertechniken mithilfe von Berkeley-Paketfiltern und Wireshark-Anzeigefiltern.
Kapitel 14: Aufklärung über Freund und Feind
Die Fähigkeit, Informationen über eigene und über gegnerische Systeme einzuholen,
kann bei einer Untersuchung den Ausschlag geben. Am Anfang dieses Kapitels steht
eine Einführung in den klassischen Aufklärungszyklus und seine Bedeutung für NSM.
Danach sehen wir uns Methoden an, um Informationen über eigene Systeme zu gewinnen, z. B. über Netzwerkscans oder mithilfe von PRADS-Daten. Danach geht es
um die verschiedenen Arten der Aufklärung über Bedrohungen und einige der grundlegenden Möglichkeiten der taktischen Aufklärung über gegnerische Hosts.
Kapitel 15: Der Analysevorgang
Im letzten Kapitel geht es um den Analysevorgang als Ganzes. Wir beginnen mit einer Besprechung von zwei Analysemethoden, der relationalen Untersuchung und der
differenziellen Diagnose, und geben Beispiele für beide Vorgehensweisen an. Danach
geht es darum, wie Sie mithilfe von Morbiditäts- und Mortalitätsbesprechungen Erkenntnisse aus Zwischenfällen ziehen können. Den Abschluss bildet eine Aufstellung
von bewährten Vorgehensweisen für die Analyse.
Hinweis zu IP-Adressen
In den Beispielen in diesem Buch werden IP-Adressen angegeben, sowohl im Text und in
den Listings als auch in den Screenshots. Sofern nicht anderes angegeben, wurden diese
Adressen zufällig bestimmt. Jegliche Übereinstimmung mit tatsächlichen öffentlichen IPAdressen ist rein zufällig und steht in keinerlei Zusammenhang mit dem Datenverkehr der
Organisationen, denen diese Adressen gehören.
Vorwort 33
Begleitwebsite
Für einige der Dinge, die wir gern noch in dieses Buch aufgenommen hätten, konnten wir
leider keinen Platz mehr finden. Daher haben wir eine Begleitwebsite angelegt, auf der
Sie weitere Überlegungen zu den verschiedenen NSM-Themen, Beispielcode und Tipps
und Tricks finden. Diese Website finden Sie unter der Adresse http://www.appliednsm.com.
Während der Produktion dieses Buches haben wir die Website nicht sehr oft aktualisiert,
aber wir haben vor, nach der Veröffentlichung regelmäßig Beiträge zu dem Blog zu leisten.
Auch Errata (zur englischen Originalausgabe dieses Buchs) werden Sie dort finden.
Unterstützung für wohltätige Organisationen
Wir sind sehr stolz darauf, dass wir unsere Autorenhonorare aus diesem Buch zu 100 %
den folgenden fünf Wohltätigkeitsorganisationen spenden.
Rural Technology Fund
Schüler aus ländlichen Gebieten, selbst diejenigen mit hervorragenden Abschlüssen,
haben weniger Gelegenheit, sich mit Technologie beschäftigen, als ihre Kommilitonen
aus den Städten und Vorstädten. 2008 hat Chris Sanders den Rural Technology Fund
gegründet, der versucht, die digitale Lücke zu verkleinern, die zwischen ländlichen Gemeinden und Städten klafft. Das wird durch ein Stipendiatsprogramm, Gemeindearbeit
und die allgemeine Förderung und Befürwortung von Technologie in ländlichen Gegenden angefast.
Unsere Stipendien sind für Schüler da, die in ländlichen Gemeinden leben, sich für Informatik interessieren und eine Ausbildung auf diesem Gebiet anstreben. Ein Teil der Tantiemen
aus diesem Buch wird für diese Stipendien und für die Bereitstellung von Raspberry-PiComputern in Landschulen aufgewendet.
Weitere Informationen: http://www.ruraltechnfund.org
Hackers for Charity
HFC wurde von Johnny Long gegründet und beschäftigt freiwillige Hacker (es werden keine Fragen gestellt), um ihre Fähigkeiten in kurzen »Mikroprojekten« zu nutzen, mit denen
Wohltätigkeitsorganisationen geholfen werden soll, die sich keine traditionellen technischen
Ressourcen leisten können. Daneben ist HFC auch in Uganda präsent, um Hilfsorganisationen zu unterstützen, die sich für die ärmsten Menschen der Welt einsetzen. Die Gruppe
bietet kostenlose Computerkurse, technische Unterstützung, Netzwerkdienste usw. an. Sie
hat bereits viele örtliche Schulen mit Computern und Schulungssoftware unterstützt. Über
34 Vorwort
ihr Lebensmittelprogramm hat die HFC auch Nahrung für ostafrikanische Kinder bereitgestellt.
Weitere Informationen: http://www.hackersforcharity.org
Kiva
Kiva ist die erste Online-Darlehensorganisation, die es ermöglicht, direkt Geld an Menschen in Entwicklungsländern zu spenden. Die Vermittlung übernehmen dabei ortsansässige Institutionen. Kiva stellt die einzelnen Personen, die ein Darlehen anfordern, mit
ihrer Geschichte vor, sodass die Spender wissen, mit wem sie es zu tun haben. Einfach
gesagt, ermöglicht Kiva Darlehen, die Leben ändern helfen. Gelder aus dem Verkauf dieses
Buches gehen ebenfalls in diese Darlehen ein.
Weitere Informationen: http://www.kiva.org
Hope for the Warriors®
Der Zweck von Hope for the Warriors® besteht darin, die Lebensqualität von 9/11-Veteranen, ihrer Familien und der Hinterbliebenen derjenigen zu heben, die in der Erfüllung ihrer
Pflicht ums Leben gekommen sind oder dabei schwere körperliche oder seelische Schäden
davongetragen haben. Hope for the Warriors® will das Selbstwertgefühl heben, die familiären Bande wiederherstellen und den Mitgliedern der öffentlichen Dienste und des Militärs
sowie ihren Familien Hoffnung geben.
Weitere Informationen: http://www.hopeforthewarriors.org
Autism Speaks
Autismus ist eine sehr vielschichtige Störung, die sich in verschiedenen Graden durch
Schwierigkeiten in sozialen Beziehungen und der Kommunikation sowie in repetitivem
Verhalten zeigt. Die US-Gesundheitsbehörde schätzt, das 1 von 88 amerikanischen Kindern eine Form von Autismus aufweist. Die Organisation Autism Speaks setzt sich für die
Zukunft all derer ein, die mit einer der Störungen aus dem breiten Spektrum des Autismus
zu kämpfen haben. Dazu finanziert sie biomedizinische Forschungen über die Ursachen,
die Verhinderung, die Behandlung und Heilung vom Autismus. Außerdem bietet sie eine
Interessenvertretung und Unterstützung für Familien mit autistischen Mitgliedern.
Weitere Informationen: http://autismspeaks.org
Vorwort 35
Kontakt
Meine mitwirkenden Autoren und ich haben viel Zeit und Mühe in dieses Werk investiert,
weshalb wir daran interessiert sind, von den Menschen zu hören, die es gelesen haben
und ihre Gedanken darüber mitteilen möchten. Sie können all Ihre Fragen, Kommentare,
Beschimpfungen und Heiratsanträge direkt an die folgenden Adressen senden:
Chris Sanders, Hauptautor
E-Mail: chris@chrissanders.org
Blog: http://www.chrissanders.org; http://www.appliednsm.com
Twitter: @chrissanders88
Jason Smith, Co-Autor
E-Mail: jason.smith.webmail@gmail.com
Blog: http://www.appliednsm.com
Twitter: @automayt
David J. Bianco, mitwirkender Autor und Fachgutachter
E-Mail: davidjbianco@gmail.com
Blog: http://detect-respond.blogspot.com/; http://www.appliednsm.com
Twitter: @davidjbianco
Liam Randall, fachlicher Mitarbeiter
E-Mail: liam@bro.org
Blog: http://liamrandall.com; http://www.appliednsm.com
Twitter: @liamrandall
1
Network Security Monitoring in der
Praxis
Wenn ich mir den derzeitigen Zustand der Sicherheit von Systemen anschaue, die mit dem
Internet verbunden sind, fühle ich mich an den Wilden Westen erinnert. Für die Amerikaner der damaligen Zeit war der Westen eine brachliegende Ressource, ein unermessliches
unentdecktes Land, in dem zahllose Gelegenheiten warteten. Als immer mehr Menschen
in den Westen zogen, entstanden kleine Gemeinden, und sowohl Einzelpersonen als auch
Familien konnten zu Wohlstand gelangen. Mit dem Wohlstand und dem Erfolg kam aber
auch unvermeidlich das Verbrechen. Die Städte lagen weit verstreut, aber es gab keine
übergreifende Durchsetzung von Recht und Ordnung. Das ermöglichte es Banden von
Desperados, von Stadt zu Stadt zu ziehen und dort zu rauben und die örtlichen Ressourcen zu plündern. Wenn es nicht gerade dem örtlichen Sheriff gelang, sie zu erschießen,
wurden diese Kriminellen aufgrund der mangelnden Koordination und Kommunikation
zwischen den Vertretern des Gesetzes in den einzelnen Städten nur selten gefasst.
In unserer heutigen Zeit sind wir mit einer ähnlichen Situation konfrontiert. Das Internet stellt ebenso ein brachliegendes Land voller Gelegenheiten dar, in dem man mit einem
Domänennamen und etwas Knochenfett den amerikanischen Traum verwirklichen kann.
Ebenso wie der Westen hat jedoch auch das Internet seine Banden von Desperados. Statt
mit Bankräubern und Entführern haben wir es heute mit Botnetbetreibern und Browser-
38 1 Network Security Monitoring in der Praxis
hijackern zu tun. Außerdem haben wir ebenfalls mit dem Problem zu kämpfen, dass die
Durchsetzung von Recht und Ordnung örtlich beschränkt ist. Wir sehen einer weltweiten
Bedrohung entgegen, doch jedes Land – und in manchen Fällen sogar einzelne Bundesstaaten – wendet seine eigenen, nicht miteinander zu vereinbarenden Gesetze an.
Das Problem im Westen bestand darin, dass die Kriminellen organisiert waren, die Ordnungshüter dagegen nicht. Während der letzten zehn Jahre hat es auf dem Gebiet der
Computersicherheit zwar erhebliche Verbesserungen gegeben, doch die Verteidiger sind
immer noch dabei, den Vorsprung der Gruppen aufzuholen, die weltweite kriminelle
Netzwerke betreiben. Leider lässt sich dieses Problem nicht über Nacht lösen; falls überhaupt.
Diese Tatsache erlegt die Verantwortung dafür, die Computernetzwerke und die darin enthaltenen Daten vor Kriminellen zu verteidigen, den Einzelpersonen an der Front auf. Die
wirksamste Möglichkeit dazu besteht meiner Ansicht nach in der Anwendung von Network Security Monitoring (»Netzwerksicherheitsüberwachung«) oder kurz NSM.
Bei dieser Methode handelt es sich um die Erfassung und Analyse von Netzwerksicherheitsdaten. Die Informationssicherheit wird traditionell in viele verschiedene Teilgebiete
aufgeteilt, aber ich persönlich bevorzuge die Kategorien, die das US-Verteidigungsministerium in seiner Anweisung 8500.21 für die Verteidigung von Computernetzwerken
aufgestellt hat:
Schützen. Der Schwerpunkt dieses Gebiets liegt darauf, Systeme gegen Ausnutzung
und Eindringen abzusichern. Zu den typischen Aufgaben in diesem Bereich gehören
Schwachstelleneinschätzung, Risikobewertung, Vorgehen gegen Malware, Schulung des
Gefahrenbewusstseins der Benutzer und andere allgemeine Maßnahmen zur Informationssicherheit.
Erkennen. Hier geht es darum, laufende und frühere Sicherheitsverletzungen zu erkennen.
Dazu gehören die Sicherheitsüberwachung des Netzwerks, das Aufspüren von Angriffen
und das Ausgeben von Warnungen.
Reagieren. Der dritte Bereich betrifft die Reaktion auf das Auftreten einer Sicherheitsverletzung. Diese umfasst die Eindämmung des Zwischenfalls, Netzwerk- und Hostforensik,
Malwareanalyse und Berichterstattung über den Zwischenfall.
Erhalten. Im letzten Bereich geht es um die Menschen, Prozesse und Technologien im
Zusammenhang mit der Verteidigung von Computernetzwerken. Hierzu zählen Verträge,
Stellenbesetzung, Schulung, Entwicklung und Umsetzung von Technologien und Verwaltung von unterstützenden Systemen.
Wie Sie sich wahrscheinlich schon gedacht haben, geht es in diesem Buch hauptsächlich
um die Erkennung. Eine korrekt durchgeführte Netzwerksicherheitsüberwachung kann
sich jedoch positiv auf alle Gebiete der Verteidigung von Computernetzwerken auswirken.
1 Anweisung 8500.2 des US-Verteidigungsministeriums, Umsetzung der Informationssicherheit (6. Februar
2003) – http://www.dtic.mil/whs/directives/corres/pdf/850002p.pdf
1.1 Kernbegriffe des Network Security Monitoring 39
1.1
Kernbegriffe des Network Security Monitoring
Bevor wir in die Tiefe gehen, müssen wir zunächst verschiedene Begriffe klären, die in
diesem Buch ausgiebig verwendet werden. Da es sich bei Network Security Monitoring
und Netzwerksicherheit um relativ neue Zweige handelt, ist es bei vielen dieser Begriffe
schwierig, allgemein gültige und präzise Definitionen zu finden. Ich habe mich an der Dokumentation des US-Verteidigungsministeriums, der Literatur zur CISSP-Zertifizierung
und anderen Texten zum Network Security Monitoring orientiert. Die Definitionen habe
ich größtenteils umformuliert.
1.1.1
Schützenswerte Güter
Schützenswerte Güter sind alles in Ihrer Organisation, was für diese einen Wert hat. Das
können Wertgegenstände wie Computer, Server und Netzwerkgeräte sein, aber auch Daten, Menschen, Prozesse, geistiges Eigentum und der Ruf der Organisation.
In diesem Buch beschäftige ich mich meistens mit den schützenswerten Gütern im Bereich Ihres vertrauenswürdigen Netzwerks. Das kann auch Netzwerke außerhalb Ihres
eigenen einschließen, die Sie als vertrauenswürdig einschätzen (z. B. von befreundeten
Staaten, Tochtergesellschaften oder Partnern in der Lieferantenkette).
1.1.2
Angreifer
Ein Angreifer ist eine Partei mit den Fähigkeiten und der Absicht, Schwachstellen in einem
Wert auszunutzen. Dabei sehen sich Einzelpersonen ganz anderen Angreifern ausgesetzt
als große Unternehmen, und Kleinstaaten ganz anderen als Supermächten.
Angreifer lassen sich grob in zwei Kategorien einteilen, nämlich strukturierte und nicht
strukturierte.
Strukturierte Angreifer nutzen formale Taktiken und Vorgehensweisen, und haben klar
definierte Ziele. Dazu gehören unter anderem kriminelle Organisationen, Hacktivisten,
Spionagedienste und das Militär. Gewöhnlich handelt es sich um Gruppen, wobei es jedoch durchaus vorkommen kann, dass Einzelpersonen als strukturierte Angreifer auftreten. Ein strukturierter Angreifer verfolgt fast immer ein bestimmtes Ziel, das aus ganz
bestimmten Gründen ausgewählt wurde.
Unstrukturierten Angreifern mangelt es an der Motivation, den Fähigkeiten, den strategischen Kenntnissen oder der Erfahrung strukturierter Angreifer. Die typischen Vertreter
dieser Kategorie sind Einzelpersonen und kleine, nur locker organisierte Gruppen. Die
Ziele werden meistens nur aufgrund der Gelegenheiten ausgewählt, also weil sie leicht
angreifbar erscheinen.
Unabhängig von ihrem Umfang oder ihrer Natur haben alle Angriffe eines gemeinsam: Sie
wollen etwas von Ihnen stehlen. Das kann Geld sein, aber auch geistiges Eigentum, Ihr Ruf
oder auch einfach nur Ihre Zeit.
40 1 Network Security Monitoring in der Praxis
1.1.3
Schwachstelle
Eine Schwachstelle ist ein Mangel in einer Software, einer Hardware oder einem Verfahren, der einem Angreifer die Möglichkeit gibt, nicht autorisierten Zugang zu einem Wert
im Netzwerk zu erhalten.
Das kann beispielsweise nicht ordnungsgemäß geschriebener Code sein, der eine Ausnutzung durch einen Pufferüberlauf ermöglicht, ein aktiver Netzwerkport in einem öffentlichen Bereich, der Zugriff auf ein Netzwerk bietet, oder ein schlecht konstruiertes
Authentifizierungssystem, in dem ein Angreifer den Nachnamen seines Opfers erraten
kann. Denken Sie daran, dass auch Menschen Schwachstellen darstellen können.
1.1.4
Exploit
Ein Exploit ist die Methode, mit der eine Schwachstelle ausgenutzt wird. Bei einer Softwareschwachstelle kann es sich um Exploitcode mit einer Schadroutine handeln, durch die
der Angreifer über das Netzwerk Aktionen auf dem Zielsystem ausführen kann, z. B. das
Öffnen einer Befehlsshell. Wenn eine Webanwendung eine Schwachstelle bei der Verarbeitung von Ein- und Ausgaben aufweist, können Angreifer dies mithilfe von SQL-Injektion
ausnutzen. Wenn sich ein Angreifer Zutritt zu einem Bürogebäude verschafft, indem er
hinter einem legitimen Mitarbeiter durch die Tür schlüpft, nachdem dieser sie mit seiner
ID-Karte geöffnet hat, kann man das auch als eine Art Exploit betrachten.
1.1.5
Risiko
Risikomanagement ist ein sehr weites Feld, weshalb es auch mehrere verschiedene Definitionen von »Risiko« gibt. Die treffendste Definition im Zusammenhang mit Network Security Monitoring besagt, dass es sich beim Risiko um das Maß für die Wahrscheinlichkeit
handelt, mit der ein Angreifer eine Schwachstelle ausnutzen wird. Die meisten Manager
bevorzugen zwar eine quantifizierbare Größe, doch meistens ist die Quantifizierung von
Risiken vergebliche Liebesmüh, da es sehr schwer ist, den Stellenwert von Netzwerken und
Daten zu bestimmen.
Ich werde zwar häufig über Maßnahmen sprechen, die das Risiko für einen bestimmten
Wert erhöhen oder verringern, aber nur so weit auf Berechnungen zur Quantifizierung von
Risiken eingehen, wie nötig ist, um eine Strategie zur Erfassung von Risiken aufzustellen.
1.1.6
Anomalie
Eine Anomalie ist ein beobachtetes Geschehen in einem System oder Netzwerk, das außerhalb des Üblichen liegt. Erkennungswerkzeuge wie Intrusion-Detection-Systeme oder
Anwendungen zur Protokolluntersuchung lösen bei Anomalien Alarm aus. Anomalien
können Systemabstürze, nicht wohlgeformte Pakete, unübliche Kontakte mit unbekann-
1.2 Intrusion Detection 41
ten Hostcomputern oder große Datenmengen sein, die in einem kurzen Zeitraum übertragen werden.
1.1.7
Zwischenfall
Wenn ein Ereignis untersucht wird, kann es als Teil eines Zwischenfalls klassifiziert werden. Ein Zwischenfall ist eine Verletzung der Computersicherheitsrichtlinien, der Richtlinien zur akzeptablen Benutzung oder der Standardsicherheitspraktiken oder eine unmittelbar bevorstehende Verletzung dieser Art. Einfacher gesagt: Ein Zwischenfall bedeutet,
dass in Ihrem Netzwerk etwas Schlimmes passiert ist oder gerade passiert. Das kann die
Übernahme eines Computers auf Root-Ebene, die Installation von Malware, ein Denialof-service-Angriff oder die Ausführung von Schadcode aus einer Phishing-E-Mail sein.
Bei Zwischenfällen treten ein oder mehrere Ereignisse auf, aber die meisten Ereignisse
stehen nicht in direktem Zusammenhang zu einem Zwischenfall.
1.2
Intrusion Detection
Bevor der Begriff »Network Security Monitoring« geprägt wurde, wurde das Gebiet
»Erkennen« einfach als »Intrusion Detection« beschrieben, also als das »Aufspüren von
Eindringlingen«. Obwohl inzwischen schon seit zehn Jahren von Network Security Monitoring die Rede ist, werden diese beiden Begriffe häufig noch synonym verwendet. In
Wirklichkeit aber sind sie nicht gleichbedeutend; Intrusion Detection ist nur ein Teil des
modernen Network Security Monitoring.
Als das Gebiet des »Erkennens« noch ganz nach dem alten Modell der Intrusion Detection
geformt war, wies es folgende Merkmale auf:
Schwachstellenorientierte Verteidigung. In dem am weitesten verbreiteten Bedrohungsmodell nutzen Angreifer, die in ein Netzwerk einbrechen, eine Schwachstelle in der Software
aus. Da dieses Modell so einfach und klar umrissen ist, bauten die ersten Intrusion-Detection-Programme darauf auf: Sie dienten dazu, die Ausnutzung solcher Schwachstellen
zu erkennen.
Bevorzugung der Erkennung gegenüber der Erfassung. Der Schwerpunkt in diesem Gebiet lag
auf der Erkennung. Es wurde zwar auch eine Datenerfassung durchgeführt, allerdings war
sie häufig ungerichtet, und die Erfassungsstrategien waren nicht an den Zielen der Erkennung ausgerichtet. Diese planlose Datenerfassung zeigte sich in Haltungen wie: »Lieber zu
viele Daten als zu wenige!« und: »Erstmal alles erfassen, sortieren kann man es später.«
Größtenteils signaturgestützt. Die Ausnutzung einer Softwareschwachstelle ist oftmals eine
ziemlich gleichbleibende Vorgehensweise, die sich sehr leicht in eine Signatur für ein IDS
umsetzen lässt. Daher waren herkömmliche Intrusion-Detection-Systeme darauf angewiesen, dass die Schwachstellen bekannt waren und Signaturen für die entsprechenden
Exploits entwickelt wurden.
42 1 Network Security Monitoring in der Praxis
Versuche zur Automatisierung der Analyse. Das stark vereinfachende, auf Schwachstellen
gestützte Modell zum Erkennen von Eindringversuchen führte zu der Vorstellung, dass
man dem von einem IDS hervorgerufenen Alarm mit guter Wahrscheinlichkeit vertrauen
konnte. Daher verließ man sich kaum auf menschliche Analytiker, sondern versuchte, die
Analyse nach der Erkennung so weit wie möglich zu automatisieren.
Die herkömmliche Intrusion Detection war zu ihrer Zeit mäßig erfolgreich, doch bei der
jetzigen Sicherheitslage ist sie nicht mehr wirkungsvoll. Der Hauptgrund dafür ist das
Versagen der hauptsächlich auf Schwachstellen ausgerichteten Verteidigung.
Eine der besseren Erklärungen dafür gibt Bejtlich2. Stellen Sie sich vor, dass in mehrere Häuser in einem Stadtviertel eingebrochen wird. Die Polizei könnte darauf reagieren,
indem sie die Häuser in der Nachbarschaft mit Stacheldrahtzäunen umgibt oder dort
Stahltüren und Fensterriegel einbauen lässt. Auch dies stellt eine an den Schwachstellen
orientierte Vorgehensweise dar. Es ist aber kaum verwunderlich, dass man nie von solchen
Maßnahmen der Strafverfolgungsbehörden hört. Der Grund dafür ist, dass entschlossene
Verbrecher, die gezielt dieses Viertel aufs Korn genommen haben, einfach nach anderen
Schwachstellen in den Häusern suchen werden, die sie ausnutzen können.
1.3
Network Security Monitoring
Network Security Monitoring hat vor allem dank des Militärs Fortschritte gemacht, das
nun einmal von Natur aus zu den größten Vorreitern einer verteidigungsbereiten Haltung
zählt. Angesichts der ausgiebigen Nutzung von Informationstechnologie durch das Militär, der Bedeutung militärischer Operationen und der hohen Vertraulichkeit der Daten in
diesem Rahmen ist das auch kein Wunder.
Die IO-Doktrin3 (Information Operations) der Vereinigten Staaten besagt, dass die IOFähigkeiten eines Befehlshabers für folgende Ziele genutzt werden sollten:
•• Zerstören: Ein System oder ein Objekt so beschädigen, dass es keine Funktion mehr
ausführen und ohne komplette Neuerstellung nicht wieder in einen nutzbaren Zustand zurückgeführt werden kann.
•• Stören: Den Informationsfluss unterbinden oder unterbrechen.
•• Schwächen: Die Effektivität oder Effizienz von feindlichen Führungs-, Lage- und
Kommunikationssystemen sowie Maßnahmen zur Informationsgewinnung herabsetzen. IO kann auch die Moral einer Einheit senken, den Wert eines Ziels verringern
oder die Güte der Entscheidungen und Aktionen des Gegners verschlechtern.
•• Verweigern: Den Gegner daran hindern, auf wichtige Informationen, Systeme und
Dienste zuzugreifen und sie zu nutzen.
2 Bejtlich, Richard, TaoSecurity-Blog, »Real Security is Threat Centric« (November 2009), http://taosecurity.
blogspot.com/2009/11/real-security-is-threat-centric.html
3 Veröffentlichung 3-13 des US-Verteidigungsministeriums, »Information Operations« (13. Februar 2006),
http://www.carlisle.army.mil/DIME/documents/jp3_13.pdf
1.3 Network Security Monitoring 43
•• Täuschen: Personen etwas glauben lassen, was nicht wahr ist. Die gegnerischen Entscheidungsträger durch Manipulation ihrer Wahrnehmung in die Irre führen.
•• Ausnutzen: Zugriff auf gegnerische Führungs- und Lagesysteme erlangen, um Informationen zu sammeln oder um falsche oder irreführende Informationen unterzuschieben.
•• Beeinflussen: Andere dazu bringen, sich auf eine Weise zu verhalten, die für befreundete
Kräfte günstig ist.
•• Schützen: Schutzmaßnahmen gegen Spionage und das Abgreifen geheimer Informationen und Ausrüstungsteile treffen.
•• Erkennen: Frühere und laufende Einbrüche in Informationssysteme entdecken oder
wahrnehmen.
•• Wiederherstellen: Informationen und Informationssysteme in den ursprünglichen
Zustand zurückversetzen.
•• Reagieren: Auf die IO-Angriffe oder Einbrüche des Gegners oder anderer schnell
reagieren.
Viele dieser Ziele stehen miteinander in Verbindung. Der Großteil des Network Security
Monitoring betrifft das Erkennen, um besser reagieren zu können. Gelegentlich kann das
auch Elemente anderer Gebiete einschließen. Bei der Erörterung von Honeypots werden
wir uns auch mit Täuschung und Schwächung beschäftigen.
Das Erkennungselement dieser IO-Doktrin steht auch in Übereinstimmung mit der Definition für Angriffswahrnehmung und Warnung (Attack Sense and Warning, AS&W)
des US-Verteidigungsministeriums.4 Demnach ist AS&W die Erkennung, Korrelation,
Identifizierung und Charakterisierung eines breiten Spektrums beabsichtigter unautorisierter Tätigkeiten wie Einbrüche in Computer oder Angriffe darauf, in Verbindung
mit der Benachrichtigung der Befehlshaber und Entscheidungsträger, sodass eine geeignete Reaktion entwickelt werden kann. Zu AS&W gehören auch die Erfassung und Weiterleitung von Aufklärungsdaten im Zusammenhang mit Angriffen und Einbrüchen,
eingeschränkte Empfehlungen für unmittelbare Reaktionen und eingeschränkte Beurteilungen der möglichen Auswirkungen.
Network Security Monitoring wird als das neue Modell für das Gebiet des Erkennens
angesehen. Seine Eigenschaften weichen erheblich von denen der klassischen Intrusion
Detection ab:
Prävention schlägt irgendwann unvermeidlich fehl. Eine der bittersten Realitäten für Verteidiger besteht darin, dass sie irgendwann verlieren werden. Wie stark die Schutzeinrichtungen auch sind und welche vorbeugenden Maßnahmen auch immer unternommen wurden,
schließlich wird ein motivierter Angreifer doch eine Möglichkeit zum Eindringen finden.
Nicht nur in der Informationssicherheit gilt, dass die Verteidiger immer mit den Angreifern Schritt halten müssen. Wenn der Verteidiger stärkere Bunker baut, so baut der Angreifer stärkere Bomben. Trägt der Verteidiger beschusshemmende Westen, beginnt der
4 Direktive O-8530.1 des US-Verteidigungsministeriums, »Computer Network Defense (CND)« (8. Januar
2001), http://www.doncio.navy.mil/uploads/0623IYM47223.pdf
44 1 Network Security Monitoring in der Praxis
Angreifer, panzerbrechende Munition zu verwenden. Wenn Verteidiger professionelle
Firewalls für Unternehmen einsetzen und ihre Server stets auf dem neuesten Stand halten,
sollten sie daher nicht überrascht sein, dass die Angreifer mithilfe von Social-EngineeringAngriffen Fuß im Netzwerk zu fassen versuchen oder Zero-Day-Exploits einsetzen, um
Root-Zugriff auf den gepatchten Server zu bekommen.
Erst wenn Sie akzeptieren, dass Ihre Sicherheitsvorkehrungen irgendwann überwunden
werden, können Sie Ihre Haltung ändern, sodass Sie sich nicht mehr allein auf Prävention
verlassen, sondern sich auch mit Erkennung und Reagieren beschäftigen. Wenn der große
Einbruch geschieht, ist Ihre Organisation dann vorbereitet, um wirkungsvoll reagieren
und das Leck stopfen zu können.
Zielgerichtete Datenerfassung. Früher wurden Daten aus allen verfügbaren Quellen erfasst
und an einem zentralen Ort abgelegt. Die Verwaltung von Installationen nach diesem Muster war jedoch äußerst teuer und bot darüber hinaus keinen echten Wert, da die wirklich
brauchbaren Arten von Daten nicht zur Verfügung standen und sich die Erfassungswerkzeuge nicht an die Größenordnung der Daten anpassen ließen, mit denen sie zu arbeiten
gezwungen waren.
So wie ein Gramm Prävention ein Pfund Sanierung aufwiegt, so wiegt ein Gramm Datenerfassung ein Pfund Erkennung auf. Wenn Sie den gleichen Grad an Erkennung mit
weniger Daten erreichen können, dann sparen Sie dadurch CPU-Zyklen und arbeiten viel
effizienter. Außerdem können Sie den menschlichen Analytikern dann nur die Daten geben, die sie auch tatsächlich brauchen, sodass sie ihre Entscheidungen schneller treffen
können. Das kann den Unterschied zwischen einem kleinen Einbruch und einem umfassenden Datenleck ausmachen.
Zyklische Prozesse. Intrusion Detection alter Schule war ein linearer Prozess. Dabei erhielten Sie eine Alarmmeldung, bestätigten sie und reagierten nach Bedarf. Damit waren
sie fertig. Diese lineare Vorgehensweise ist jedoch nicht nur naiv, sondern auch unverantwortlich. Jeden einzelnen Zwischenfall einzeln zu betrachten, als liefe er im luftleeren
Raum auf, hilft nicht, das Netzwerk zu verteidigen. Manche Angriffe dauern zwar wirklich
nur wenige Sekunden, doch erfahrene Angreifer gehen oft langsam und methodisch vor.
Manchmal benötigen sie Monate, um ihre Ziele zu erreichen.
Um von dieser Einzelbetrachtung wegzukommen, ist es erforderlich, die Erkennung von
Einbrüchen und die Reaktion darauf als zyklischen Prozess zu behandeln. Das bedeutet,
dass die Datenerfassung in die Erkennung eingeht, die Erkennung in die Analyse und die
Analyse wiederum in die Erfassung. Dadurch kann der Verteidiger mit der Zeit Kenntnisse
aufbauen, um das Netzwerk besser zu verteidigen.
Bedrohungsorientierte Verteidigung. Alle Merkmale, die ich bis jetzt aufgezählt habe, führen uns zum Prinzip der an den Bedrohungen oder den Angreifern orientierten Verteidigung. Bei der schwachstellenorientierten Vorgehensweise liegt der Schwerpunkt auf dem
»Wie«, hier aber auf dem »Wer« und »Warum«. Insbesondere müssen Sie sich fragen,
wer daran interessiert sein mag, Ihr Netzwerk anzugreifen, und was die Angreifer damit
gewinnen können.
1.4 Schwachstellen- und bedrohungsorientierte Verteidigung im Vergleich 45
Eine bedrohungsorientierte Verteidigung lässt sich viel schwerer durchführen als die frühere Vorgehensweise, denn dazu sind erstens ausführliche Einsichten in Ihr Netzwerk und
zweitens die Möglichkeit erforderlich, Informationen über die Absichten und Fähigkeiten der Angreifer zu erfassen und zu analysieren. Ersteres lässt sich mit entsprechendem
Zeiteinsatz von jeder Organisation mit Leichtigkeit erreichen, doch die zweite Voraussetzung ist in allen Organisationen außer staatlichen Stellen nur sehr schwer zu erfüllen.
Unmöglich ist es aber sicherlich nicht.
Denken Sie noch einmal an unser Beispiel von Einbrüchen in einem Stadtviertel zurück.
Statt einer schwachstellenorientierten Vorgehensweise, bei der zusätzliche Schutzmechanismen wie Stacheldraht und Stahltüren aufgefahren werden, konzentriert sich die Polizei bei
einem an den Angreifern orientierten Ansatz darauf, die Häuser, in die eingebrochen wurde,
genau zu untersuchen, um nach Ähnlichkeiten oder Gemeinsamkeiten der verschiedenen
Einbrüche zu suchen und die wahrscheinlichen Ziele der Einbrecher herauszufinden. Anhand dieser Informationen kann die Polizei dann ein Profil der Kriminellen erstellen. Damit
wiederum ist es möglich, in der Verbrecherkartei nach Personen zu suchen, die ähnliche
Taktiken angewandt haben. Zusammen mit anderen Fahndungsmaßnahmen kann diese Art
von Analyse dazu führen, dass die Täter gefasst werden, was weitere Einbrüche verhindert.
Das ist im Grunde genommen die Vorgehensweise der bedrohungsorientierten Verteidigung und des Network Security Monitoring.
1.4 Schwachstellen- und bedrohungsorientierte
Verteidigung im Vergleich
Stellen Sie sich einmal vor, das Tor beim Eishockey würde nicht von einem Torwart verteidigt, sondern von einer Backsteinmauer geschützt. Das mag zu Anfang nach einer idealen
Lösung aussehen. Die schwachstellenorientierte Denkschule bevorzugt die Steinmauer.
Sie erscheint zunächst undurchdringlich, da sie den Großteil des Tors abdeckt und die
angreifende Mannschaft nur zum Ziel gelangen kann, wenn sie die Mauer durchbricht.
Mit der Zeit jedoch durchschlagen vereinzelte Schüsse die Mauer. Ganze Steine können
aus dem Verbund herausbrechen. Natürlich könnte man diese Steine wieder ersetzen, aber
während man an der einen Stelle einen Stein einfügt, kann sich an einer anderen Stelle
schon wieder ein Stein lösen.
Bedrohungsorientierte Personen dagegen bevorzugen die Verteidigung durch einen Torwart. Es ist dabei natürlich wichtig, dass der Torwart alle Schüsse abfängt. Wenn jedoch
gelegentlich ein Puck durchgeht, kann er erkennen, dass er beispielsweise tief an seiner
rechten Seite hereingekommen ist. Wenn er es wieder mit demselben Stürmer zu tun bekommt, wird er sein besonderes Augenmerk auf diese Stelle richten, sodass es weniger
wahrscheinlich ist, dass der Gegner ein weiteres Tor erzielt.
Der große Unterschied besteht darin, dass die Steinmauer ihre Taktik nie ändert und nicht
dazulernen kann. Ein Torwart dagegen macht sich nach und nach mit den Gewohnheiten
46 1 Network Security Monitoring in der Praxis
der einzelnen Stürmer vertraut. Dadurch kann er lernen, sich anpassen und immer erfolgreicher werden.
Sowohl bei der schwachstellen- als auch bei der bedrohungsorientierten Verteidigung besteht das Ziel darin, das Netzwerk zu schützen, doch auf unterschiedliche Weise. Eine
Übersicht über diese Unterschiede finden Sie in Tabelle 1.1.
Tabelle 1.1: Schwachstellen- und bedrohungsorientierte Verteidigung
Schwachstellenorientiert
Bedrohungsorientiert
Stützt sich auf Prävention
Akzeptiert, dass Prävention irgendwann versagen wird
Schwerpunkt auf Erkennung
Schwerpunkt auf Datenerfassung
Sieht alle Bedrohungen gleich an
Geht davon aus, dass Angreifer unterschiedliche Werkzeuge, Taktiken und Verfahrensweisen
einsetzen
Analysiert jeden Angriff für sich allein
Kombiniert die aus den verschiedenen Angriffen
gewonnenen Erkenntnisse
Verlässt sich sehr stark auf die signatur­
gestützte Erkennung
Nutzt Daten aus allen Quellen
Bis dahin unbekannte Bedrohungen
können nur sehr schwer erkannt werden
Gegnerische Aktivitäten auch jenseits der bekannten Signaturen können gut erkannt werden
Linearer Prozess
Zyklischer Prozess
1.5
Der NSM-Zyklus: Erfassung, Erkennung und Analyse
Der Zyklus des Network Security Monitoring besteht aus drei deutlich voneinander unterscheidbaren Phasen: Erfassung, Erkennung und Analyse (siehe Abb. 1.1). Dieses Buch
ist in drei Teile gegliedert, die sich jeweils einer dieser Phasen widmen.
Abbildung 1.1: Der NSM-Zyklus
1.5 Der NSM-Zyklus: Erfassung, Erkennung und Analyse 47
1.5.1
Erfassung
Am Anfang des NMS-Zyklus steht der wichtigste Schritt: die Erfassung. Sie erfolgt mit
einer Kombination aus Hardware und Software, um Daten für die NSM-Erkennung und
-Analyse zu generieren, zu gliedern und zu speichern. Die Datenerfassung ist der wichtigste Teil des Zyklus, da sie bestimmt, wie gut eine Organisation die Erkennung und Analyse
durchführen kann.
Es gibt verschiedene Arten von NMS-Daten und verschiedene Vorgehensweisen, um sie
zu erfassen. Zu den gebräuchlichsten Kategorien gehören Inhaltsdaten, Sitzungsdaten,
statistische Daten, Paketstringdaten und Alarmdaten. Je nach den Bedürfnissen der Organisation, der Netzwerkarchitektur und den verfügbaren Ressourcen können diese Daten
entweder hauptsächlich für die Erkennung oder ausschließlich für die Analyse oder für
beide Zwecke genutzt werden.
Aufgrund des erforderlichen starken Personaleinsatzes gehört die Erfassung am Anfang
zu den arbeitsintensivsten Elementen des NSM-Zyklus. Für eine wirkungsvolle Erfassung
sind gemeinsame Anstrengungen der Organisationsführung, des Informationssicherheitsteams und der Netzwerk- und Systemadministratoren erforderlich.
Die Datenerfassung schließt unter anderem folgende Aufgaben ein:
••
••
••
••
••
••
••
Festlegen, wo das größte Risiko in der Organisation liegt
Bedrohungen der Ziele der Organisation identifizieren
Relevante Datenquellen identifizieren
Die Auswahl der zu erfassenden Datenquellen verfeinern
SPAN-Ports zur Erfassung von Paketdaten einrichten
SAN-Speicher für die Aufbewahrung von Protokollen bereitstellen
Hardware und Software für die Datenerfassung einrichten
1.5.2 Erkennung
Bei der Erkennung werden die erfassten Daten untersucht und bei unerwarteten Ereignissen und Daten Alarme ausgelöst. Das geschieht gewöhnlich mithilfe einer Erkennungsmethode, die sich auf Signaturen, Anomalien oder Statistiken stützt. Als Ergebnis werden
Alarmdaten generiert.
Die Erkennung wird meistens durch entsprechende Software durchgeführt. Zu den am
häufigsten verwendeten Softwarepaketen für diesen Zweck gehören die Netzwerk-Intrusion-Detection Systeme (NIDS) Snort IDS und Bro IDS und die Host-Intrusion-DetectionSysteme (HIDS) OSSEC, AIDE und McAfee HIPS. Einige Anwendungen zur Verwaltung
von Sicherheitsinformationen und -ereignissen (Security Information and Event Management, SIEM) nutzen sowohl Netzwerk- als auch Hostdaten für eine Erkennung auf der
Grundlage korrelierter Ereignisse.
48 1 Network Security Monitoring in der Praxis
Zwar erfolgt die Erkennung zum Großteil durch Software, doch manchmal wird sie auch
durch eine manuelle Analyse der Datenquellen durchgeführt. Das gilt insbesondere bei
der retrospektiven Analyse.
1.5.3 Analyse
Die Analyse ist die letzte Phase des NSM-Zyklus. Hier deuten und untersuchen Menschen
die Alarmdaten. Dazu ist es oft nötig, zusätzliche Untersuchungsdaten aus anderen Quellen
zu erfassen und die Art des vorliegenden Alarms sowie alle möglicherweise gefährlichen
Hosts über öffentliche Informationsquellen zu recherchieren (Open Source Intelligence,
OSINT).
Es gibt eine Vielzahl von Vorgehensweisen für die Analyse. Sie kann beispielsweise folgende
Aufgaben einschließen:
••
••
••
••
Paketanalyse
Netzwerkforensik
Hostforensik
Malwareanalyse
Die Analyse ist der zeitraubendste Teil des NSM-Zyklus. Zu diesem Zeitpunkt kann das
Ereignis bereits als Zwischenfall klassifiziert sein, sodass die Reaktionsmaßnahmen beginnen können.
Der NSM-Zyklus wird dadurch geschlossen, dass die Erfahrungswerte aus der Erkennungs- und Analysephase in die Erfassungsstrategie der Organisation einfließen.
1.6
Kritik an NSM
Wie jeder Wechsel zu einem neuen Modell wurde auch die Einführung von NSM und
bedrohungsorientierter Sicherheit von einem gerüttelt Maß an Kritik begleitet. Das
Hauptproblem der NSM besteht darin, das sie selbst noch nicht ausgereift und darüber
hinaus Teil der ebenfalls noch nicht ausgereiften Informationstechnologie ist. Es hat zwar
Bemühungen gegeben, die verschiedenen Terminologien und Protokolle zu standardisieren, aber es gibt immer noch einen großen Unterschied zwischen dem geschriebenen
Wort und der Umsetzung in der Praxis. Das zeigt sich in den Betriebssystemen, in den
Anwendungen, die darauf laufen, und in den Protokollen, über die sie miteinander kommunizieren.
Es kann vorkommen, dass drei Personen, die sich über Informationssicherheit unterhalten, drei verschiedene Terminologien nutzen. Das behindert die Schulung sehr stark.
Einer der Gründe dafür, dass die Weiterbildung von Ärzten so erfolgreich verläuft, ist
die Tatsache, dass alle vor Beginn ihres praktischen Jahrs über das gleiche Grundwissen
1.7 Die Analytiker 49
verfügen (zumindest theoretisch), von welcher Schule sie auch immer kommen. Aufgrund der Standardisierung der Weiterbildungsprogramme und Prüfungen wird von
allen Kandidaten das gleiche Kompetenzniveau erwartet, damit sie ihre Approbation
erhalten. Das ganze System beruht darauf, dass man sich über die geforderten theoretischen Kenntnisse, praktischen Fertigkeiten und sonstigen Voraussetzungen einig geworden ist. Der NSM jedoch fehlt eine solche Standardisierung, weshalb die Fachleute
in diesem Gebiet oft verschiedene Sprachen sprechen. Die Medizin hat einige tausend
Jahre Vorsprung vor der NSM. Daher sind wir gezwungen, in der NSM große Schritte
nach vorn zu tun, aber es ist nicht zu erwarten, dass das Problem in absehbarer Zeit
überwunden wird.
Ein weiteres Problem der NSM besteht in dem Umfang der Fähigkeiten, die für eine wirkungsvolle Ausübung erforderlich sind. Einfach gesagt, gibt es nicht genug Leute mit der
nötigen Erfahrung und den Kenntnissen, um den Bedarf zu befriedigen. Es ist erstaunlich,
dass es in unserer krisengebeutelten Wirtschaft, in der viele Menschen Schwierigkeiten
haben, einen Job zu finden, so viele offene Stellen für Personen mit NSM- oder ähnlichen
Fähigkeiten gibt. Für NSM kann es zwar auch Posten für Einsteiger geben, aber dabei ist
es erforderlich, dass die Vorgesetzten über genügend Erfahrung verfügen, um die Neulinge
anzuleiten. Es ist aber schwer, die Mitarbeiter auf den mittleren und höheren Ebenen zu
halten, da sie häufig zu besser bezahlten Posten in der Beratung oder im Management
wechseln.
Ein letztes großes Problem für die Ausweitung von NSM sind die Kosten, die damit verbunden sind, ein NSM-Programm aufzustellen und zu erhalten. Die hohen Einstiegskosten werden zwar oft mit der Hardware zur Erfassung und Untersuchung der Daten in
Verbindung gebracht, doch den Großteil bilden gewöhnlich die Personalkosten für die
Analyse und die Kosten zur Unterstützung der NSM-Infrastruktur, die die Analytiker
nutzen. Dieses Problem verschlimmert sich noch bei Organisationen, die ein Network
Security Monitoring rund um die Uhr benötigen. Ein weiterer Kostenfaktor kommt bei
Organisationen hinzu, die eine kommerzielle SIEM-Software benötigen. Solche Pakete
sind zwar nicht in jedem Fall notwendig, können aber für einige Organisationen ein Muss
sein, und die Preise dafür liegen im sechs- bis siebenstelligen Bereich.
1.7
Die Analytiker
Das wichtigste Merkmal eines NSM-Programms ist der Mensch, der die Analyse durchführt. Der Analytiker interpretiert Alarmdaten, analysiert und untersucht sie im Zusammenhang mit verwandten Daten und ermittelt, ob es sich bei dem Ereignis um einen
Fehlalarm handelt oder ob eine weitergehende Untersuchung erforderlich ist. Je nach
Größe und Struktur der Organisation können die Analytiker auch an der Reaktion auf
Zwischenfälle beteiligt sein oder andere Aufgaben wie Hostforensik oder Malwareanalyse
durchführen.
50 1 Network Security Monitoring in der Praxis
Die Analytiker sind die entscheidenden Mitglieder einer Organisation. Sie sind es, die
erfasste Pakete nach einem einzigen verdächtigen Bit durchforsten. Von ihnen wird erwartet, dass sie sich mit den neuesten Werkzeugen, Taktiken und Verfahren auskennen, die
von Angreifern eingesetzt werden. Die Sicherheit Ihres Netzwerks hängt von der Fähigkeit
Ihrer Analytiker ab, ihre Aufgaben ordnungsgemäß zu erfüllen.
1.7.1
Wichtige Fähigkeiten
Es gibt eine Reihe wichtiger Fähigkeiten, die Analytiker mitbringen sollten. Sie setzen sich
aus einem allgemeinen Grundwissen zusammen, über das alle Analytiker verfügen sollten,
und aus Kenntnissen über einzelne Spezialgebiete. Im Idealfall sollten sich Analytiker in
zwei oder drei solcher Gebiete auskennen, aber in der Praxis verlange ich nur Kenntnisse
in einem solchen Gebiet.
Grundlegende Fähigkeiten
••
••
••
••
••
••
••
••
••
••
••
••
Bedrohungsorientierte Sicherheit, NSM und der NSM-Zyklus
TCP/IP
Gebräuchliche Protokolle der Anwendungsschicht
Paketanalyse
Windows-Architektur
Linux-Architektur
Grundlegende Datenanalyse (BASH, Grep, SED, AWK usw.)
Nutzung von Intrusion-Detection-Systemen (Snort, Suricata usw.)
Anzeichen von Einbrüchen und Feineinstellung von IDS-Signaturen
Informationsbeschaffung aus öffentlichen Quellen
Grundlegende Methoden der analytischen Diagnose
Grundlegende Malware-Analyse
Spezialisierung
Es gibt unter anderem folgende Spezialgebiete für Analytiker:
Offensivtaktiken. Der Schwerpunkt dieses Gebiets liegt auf Penetrationstests und Sicherheitsbewertungen. Analytiker mit diesem Spezialgebiet versuchen, Zugriff zu erhalten
und das Netzwerk auf die gleiche Weise anzugreifen, wie ein Gegner es tun würde. Solche
Versuche sind entscheidend, um Schwächen in der Arbeit anderer Analytiker zu finden.
Außerdem können Analytiker, die sich mit Offensivtechniken auskennen, Aktivitäten von
Angreifern bei der NSM-Analyse besser erkennen. Nützliche Fähigkeiten und Kenntnisse
für dieses Fachgebiet sind Aufklärung im Netzwerk, Ausnutzen von Software und Diensten, Hintertüren, Nutzung von Malware und Techniken zum Abrufen von Daten.
1.7 Die Analytiker 51
Defensivtaktiken. Defensivtaktiker sind Meister der Erkennung und Analyse. Zu diesem
Fachgebiet gehört es im Allgemeinen, neue Entwicklungstools und Analysemethoden zu
konzipieren. Von Analytikern mit dieser Spezialisierung wird auch erwartet, dass sie sich
stets über neue Werkzeuge und Forschungsergebnisse im Zusammenhang mit dem Schutz
von Netzwerken auf dem Laufenden halten und diese Werkzeuge auf Eignung für das
NSM-Programm der Organisation prüfen. Nützliche Fähigkeiten und Kenntnisse für dieses Fachgebiet sind ausführliche Kenntnisse in Netzwerkkommunikation, Funktionsweise
und Mechanismen von Intrusion-Detection-Systemen, IDS-Signaturen und statistischer
Erkennung.
Programmierung. Code zu schreiben ist eine nützliche Fähigkeit für praktisch alle Teil­
gebiete der Informationstechnologie, insbesondere für Informationssicherheit und
NSM. Analytiker, die in Programmierung bewandert sind, können eigene Erkennungsund Analyselösungen für ihr NSM-Team entwickeln. Außerdem sind sie oft sehr gut darin, auch große Datenmengen zu analysieren. Personen, die sich auf Programmierung für
die Zwecke des Network Security Monitoring spezialisieren, sollten sehr gute Kenntnisse
der BASH-Umgebung von Linux mitbringen und sich auch mit Interpretersprachen wie
Python oder Perl, Websprachen wie PHP oder Java und schließlich auch kompilierten
Sprachen wie C oder C++ vertraut machen.
Systemadministration. Die Systemadministration ist zwar eine allgemeine Fähigkeit für
sich, aber es ist auch möglich, sich auf Systemadministration im Zusammenhang mit
NSM zu spezialisieren. Analytiker, die das tun, sind sehr stark am Erfassungsprozess beteiligt, indem sie etwa IDS konfigurieren und Daten verschieben, sodass sie von verschiedenen Erkennungsprogrammen ordnungsgemäß erfasst werden können. Sie können auch
Sensoren verbessern oder eine Datenerfassung über gutartige Hosts entwickeln. Ausführliche Kenntnisse in Windows und Linux sowie der Daten- und Protokollerfassung sind
Voraussetzung für dieses Fachgebiet.
Malwareanalyse. Bei der NSM werden häufig auch Proben bekannter und vermutlicher
Malware erfasst. Jeder Analytiker sollte in der Lage sein, Malware in einer Sandbox auf
Indikatoren zu untersuchen. Sollte eine Organisation aber jemals für sie maßgeschneiderte Malware finden, ist es von großem Vorteil, über eine Person zu verfügen, die auch eine
ausgefeiltere Malwareanalyse durchführen kann. Dazu sind Kenntnisse sowohl in dynamischer als auch in statischer Analyse erforderlich.
Hostforensik. Spezialisten in Hostforensik können Informationen aus Angriffen ermitteln,
indem sie eine forensische Analyse des Hosts durchführen. Anhand dieser Informationen
kann dann der Erfassungsprozess in der Organisation verbessert werden. Die entsprechenden Kenntnisse können auch genutzt werden, um neue Erkennungsmechanismen
auf Hostebene zu bewerten und umzusetzen und neue Einbruchsindikatoren auf der
Grundlage von Artefakten auf dem Host zu entwickeln. Nützliche Fähigkeiten für dieses
Fachgebiet sind Festplatten-, Dateisystem- und Arbeitsspeicherforensik sowie die Aufstellung des zeitlichen Verlaufs von Zwischenfällen.
52 1 Network Security Monitoring in der Praxis
1.7.2 Einteilung von Analytikern
In den meisten Organisationen werden Analytiker gewöhnlich nach ihrer Erfahrung in
Jahren klassifiziert. Ich bevorzuge allerdings eine präzisere Einteilung nach drei Fähigkeitsgraden. Das ist nicht nur für die Einstellung und Disponierung nützlich, sondern
setzt Analytikern auch sinnvolle Karriereziele. Das Modell mag nicht unbedingt zu jeder
Organisation passen, aber es bildet immerhin einen guten Ausgangspunkt.
Analytiker der ersten Ebene (L1)
Auf Ebene L1 befinden sich die Einsteiger. Sie verfügen über gute Kenntnisse der zuvor
aufgeführten grundlegenden Fähigkeiten, haben sich aber noch nicht spezialisiert. Die
meiste Zeit bringen sie damit zu, IDS-Alarme zu untersuchen und Analysen der Befunde
durchzuführen. Am wichtigsten für die Karriere von L1-Analytikern ist es, Erfahrungen
zu sammeln. Je mehr Protokolle, Pakete und Ereignisse sie zu Gesicht bekommen, umso
besser können sie mit dem nächsten Ereignis umgehen, mit dem sie konfrontiert werden.
Das lässt sich mit der Karriere eines Chirurgen vergleichen, der mit jeder durchgeführten
Operation besser wird. In den meisten Organisationen fällt die Mehrheit der Analytiker
in die L1-Gruppe.
Analytiker der zweiten Ebene (L2)
L2-Analytiker beherrschen einen Großteil der Grundfähigkeiten. Sie sind auf mindestens
einem Gebiet spezialisiert und verbringen schon einen Teil ihrer Zeit außerhalb der üblichen Ereignisuntersuchungen, um ihre Fähigkeiten in dem gewählten Bereich zu schulen.
L2-Analytiker fungieren als Mentoren für L1-Analytiker. Außerdem legen sie die empfohlenen Vorgehensweisen für das NSM-Programm ihrer Organisation fest. Sie helfen
dabei, den Erkennungsprozess zu verbessern, indem sie Signaturen aufgrund von anderen Netzwerkereignissen und Recherchen in öffentlich zugänglichen Quellen entwickeln.
L2-Analytiker eignen sich auch die Fähigkeit an, unterschiedliche Datenquellen manuell
zu durchsuchen, um mögliche Ereignisse zu finden, anstatt sich nur auf automatische
Erkennungswerkzeuge zu verlassen.
Analytiker der dritten Ebene (L3)
Auf Ebene L3 befinden sich die erfahrensten Analytiker einer Organisation. Sie sind in
allen Grundfähigkeiten und auf mindestens einem Spezialgebiet firm. Innerhalb der Organisation übernehmen sie die Rolle der Vordenker. Anstatt Ereignisse zu untersuchen,
verbringen sie ihre Zeit hauptsächlich damit, andere Analytiker zu fördern, Schulungsmaßnahmen zu entwickeln und durchzuführen und bei komplizierten Untersuchungen
beratend zur Seite zu stehen. L3-Analytiker sind außerdem die Hauptverantwortlichen
dafür, die Fähigkeiten der Organisation zur Erfassung und Erkennung zu entwickeln und
zu verbessern. Dazu kann es gehören, neue Werkzeuge zu konzipieren oder zu entwickeln
und vorhandene Werkzeuge zu bewerten.
1.7 Die Analytiker 53
1.7.3 Messen des Erfolgs
In den meisten Organisationen wird die Messung des Erfolgs oder Misserfolgs eines
NSM-Programms nicht richtig gehandhabt. Findet tatsächlich ein Einbruch statt, hält
die Geschäftsführung das oft für ein entscheidendes Versagen des Sicherheitsteams. Bei
der schwachstellenorientierten Vorgehensweise, in der man sich voll und ganz auf Prävention verlässt, mag dies das angebrachte Denkmuster sein. Wenn eine Organisation
jedoch akzeptiert, dass Prävention eines Tages zwangsläufig fehlschlägt, dann rechnet
sie auch mit Einbrüchen. Organisationen, in denen diese Denkweise vorherrscht, hängen die E
­ ffektivität ihres NSM-Programms nicht daran auf, ob ein Einbruch stattfindet
oder nicht, sondern daran, wie wirkungsvoll dieser Vorfall erkannt, analysiert und an die
nächste Ebene übergeben wurde. Das NSM ist bei einem Einbruch für alles von der Erkennung bis zur Übergabe verantwortlich, wobei das Ziel darin besteht, den Reaktionskräften
so schnell wie möglich angemessene Informationen zu liefern, sobald festgestellt worden
ist, dass tatsächlich ein Zwischenfall vorliegt. In kleineren Organisationen kann das NSMTeam auch mit dem Reaktionsteam identisch sein, aber die Rollen sind logisch getrennt.
Die Frage, die die Organisationsführung dem NSM-Team stellen sollte, lautet nicht: »Wie
konnte das passieren?«, sondern: »Wie schnell konnten Sie den Zwischenfall erkennen?
Wie schnell konnten Sie ihn an das Reaktionsteam weiterleiten? Wie können wir unsere
NSM-Vorgänge anpassen, um das nächste Mal besser vorbereitet zu sein?«
Die meisten Leser dieses Buches werden Analytiker sein, keine Mitglieder der Geschäftsführung, aber ich habe diesen Abschnitt dennoch eingefügt, damit Sie seinen Inhalt der
Geschäftsführung nahebringen können. Vielleicht sind Sie auch eines Tages selbst in einer
Position, um diesen Sinneswandel durchzusetzen.
Das wichtigste Element eines NSM-Programms sind die Analytiker, die schließlich
die genannten Fragen beantworten müssen. Ich hatte das Vorrecht, mit den Sicherheitsteams von Organisationen aller Größenordnungen zusammenzuarbeiten und zu
beobachten. Dabei habe ich einige sehr gute, aber auch einige sehr schlechte Programme
kennengelernt. Es gibt viele verschiedene Möglichkeiten, ein großartiges NSM-Team
aufzustellen, aber alle Organisationen, die es nicht geschafft haben, durch NSM wirkungsvoll für Sicherheit zu sorgen, hatten eines gemeinsam: Sie hatten nicht erkannt,
dass die Analytiker die wichtigste Rolle bei dieser Mission spielen.
Anstatt in die Analytiker zu investieren und ihnen angemessene Befugnisse zu geben,
investierten diese Organisation in teure Softwarepakete und unnötige Automatisierung.
Wenn dann nach zwei Jahren ein massiver Einbruch geschieht, fragen sich die Entscheidungsträger, warum ihre für einen siebenstelligen Preis eingekaufte SIEM-Lösung den
Angriff nicht festgestellt hat, als er sechs Monate zuvor begann.
Es kommt aber noch schlimmer: Solche Organisationen sind beim Personal knauserig, sodass das ganze Team schließlich aus Anfängern ohne die erforderliche Erfahrung und den
Hintergrund für die vorliegenden Aufgaben besteht. Es ist ganz natürlich, dass es in einem
Team auch Einsteiger gibt, aber ohne Anleitung durch erfahrene Kollegen haben sie keine
Gelegenheit, ihre Fähigkeiten zu verbessern. Es sind auch meistens dieselben Organisationen, die sich weigern, ausreichend Zeit und Geld für die Weiterbildung bereitzustellen.
54 1 Network Security Monitoring in der Praxis
Erfolgreiche NSM-Teams weisen die folgenden Gemeinsamkeiten auf:
Eine Kultur des Lernens schaffen
Für den Erfolg des NSM sind Einfallsreichtum und Innovation unverzichtbar, die wiederum auf Motivation und Ausbildung fußen. Es ist eine Sache, die Weiterbildung durch
regelmäßige Schulungsmaßnahmen zu fördern, aber eine ganz andere, eine Arbeitskultur
zu schaffen, die das Lernen zur Grundlage hat. Das bedeutet nicht nur, Weiterbildung zuzulassen, sondern sie zu erleichtern, dazu zu ermutigen und sie zu belohnen.
Um eine solche Kultur aufbauen zu können, müssen viele Hindernisse überwunden
werden, die sich in einer typischen Arbeitsumgebung stellen. In einem traditionellen
Unternehmen würde es schon starkes Stirnrunzeln hervorrufen, wenn in einem Büro
mehrere Angestellte Bücher lesen oder an persönlichen technischen Projekten arbeiten,
die nichts mit der Untersuchung von Ereignissen oder Paketen zu tun haben. Für einen
Großteil des Personals ist es einfach undenkbar, seine Schreibtische zu verlassen, um
an einer Tafel über die Feinheiten von Zeitreisen zu diskutieren. In Wirklichkeit aber
sollten all solche Dinge willkommen geheißen werden, da sie die Moral verbessern und
die Freude an der Arbeit steigern. Sie führen dazu, dass die Analytiker nach Feierabend
mit einem guten Gefühl nach Hause gehen, sodass sie sich darauf freuen, am nächsten
Tag mit neuen Ideen und neuer Motivation wiederzukommen.
Auch wenn manche Anhänger der alten Schule eine solche Arbeitsumgebung niemals akzeptieren werden, hat sie sich doch als erfolgreich erwiesen. Google ist ein Beispiel für eine
Organisation, die eine erfolgreiche Kultur des Lernens aufgebaut hat, und ein Großteil des
Erfolgs von Google ist unmittelbar darauf zurückzuführen.
Was eine Kultur des Lernens bedeutet, lässt sich sehr einfach zusammenfassen: Bei jeder Tätigkeit, die ein Analytiker durchführt, sollte er immer entweder lehren oder lernen.
Ohne Ausnahme.
Teamwork fördern
Auch wenn es sich wie ein Klischee anhören mag: Die Dynamik eines Teams fördert den
gemeinsamen Erfolg statt den einzelner Personen. Das bedeutet, dass das Zusammenwachsen des Teams ein Muss ist. Der erste Schritt, um eine gute Bindung im Team zu
erreichen, beginnt damit, die richtigen Leute anzustellen. Die Fähigkeiten einer Person
sind wichtig, aber genauso wichtig ist es, wie sie mit den bereits vorhandenen Teammitgliedern zusammenarbeiten können. Ich habe schon mehrmals gesehen, dass ein einziger
Querulant das ganze Team in Mitleidenschaft zog.
Eines Tages wird es zu einem schlimmen Vorfall kommen, der von allen Beteiligten einen
hohen Zeiteinsatz verlangt. Analytiker, die einander vertrauen und gern Zeit miteinander
zu verbringen, können viel besser dafür sorgen, dass der Zwischenfall ordnungsgemäß
gehandhabt wird. Darüber hinaus fördert ein Team mit einer guten Bindung auch die
Kultur des Lernens.
1.7 Die Analytiker 55
Möglichkeiten für berufliches Vorwärtskommen bieten
Eine der größten Ängste von Vorgesetzten besteht darin, dass ihre Leute irgendwann über
eine so gute Weiterbildung und Zertifizierung verfügen, dass sie die Organisation verlassen, um sich nach lukrativeren Stellen umzusehen. Dies kann tatsächlich geschehen, aber
das sollte die Organisation trotzdem nicht daran hindern, Gelegenheiten zum beruflichen
Vorwärtskommen zu bieten.
Bei Gesprächen mit NSM-Analytikern, die ihren Arbeitgeber gewechselt haben, zeigte
sich, dass der Grund dafür selten etwas so einfaches wie ein höheres Gehalt war. Die meisten gaben an, dass sie gingen, weil sie in der Organisation nicht genügend Gelegenheiten
zum Vorwärtskommen hatten. Im Allgemeinen scheuen Menschen Veränderungen. Ein
Wechsel des Arbeitsplatzes, insbesondere wenn dazu ein Umzug erforderlich ist, stellt einen so großen Schritt dar, dass die meisten Menschen ihn lieber vermeiden. Das bedeutet,
dass Sie Ihre Mitarbeiter besser halten können, wenn Sie ihnen Gelegenheiten für professionelle Zertifizierungen, Beförderungen oder einen Wechsel in eine Managementrolle
bieten. Schon allein die Tatsache, dass der Weg für diese Art des beruflichen Vorwärtskommens klar festgelegt wird, kann einen großen Unterschied ausmachen. Ein Klassifizierungssystem wie das nach den Ebenen L1, L2 und L3 bietet daher auch in diesem Sinne
einen Vorteil für die Organisation.
Superstars fördern
Das Gebiet der Informationssicherheit ist berüchtigt dafür, dass es darin viele Personen
mit einem unglaublich aufgeblähten Ego gibt. Bescheidenheit mag durchaus eine Zier
sein, aber man kann die Persönlichkeit eines Menschen nun einmal nicht ändern, weshalb
man lieber sein Bestes geben sollte, um mit ihm zusammenzuarbeiten. Wenn es in Ihrer
Organisation eine Person mit einem überdimensionierten Ego gibt, dann machen sie aus
ihr einen Superstar. Menschen mit übermäßigem Selbstvertrauen gieren gewöhnlich nach
großen Erfolgen. Daher können Sie sie fördern, indem sie ihnen solche Erfolge bescheren.
Stellen Sie ihnen dazu große Herausforderungen, bieten Sie ihnen Gelegenheiten zum
Lernen und übertragen Sie ihnen Verantwortung. Echte Superstars sind selten, weshalb
manche der vermeintlichen Stars versagen, wenn es ans Eingemachte geht. Wenn das geschieht, trägt die Konfrontation mit der Wirklichkeit oft dazu bei, das aufgeblähte Ego
schrumpfen zu lassen. Hat die Person aber tatsächlich Erfolg, so haben Sie einen echten
Superstar gefunden.
Wenn es in Ihrer Organisation einen Superstar gibt, wollen die anderen ebenso erfolgreich
sein. Die Größe der Stars bringt andere dazu, über das hinauszugehen, was sie sich zugetraut haben. Davon profitieren alle. Solange ein Superstar sich nicht unhöflich, rüpelhaft,
überheblich oder auf andere Weise negativ gegenüber seinen Kollegen verhält, ist er ein
Plus. Der Unterschied zwischen Allen Iverson und Kobe Bryant besteht darin, dass Iverson
ein großartiger Spieler ist, Bryant aber alle anderen in seiner Umgebung dazu bringt, großartig zu spielen. Aus diesem Grund haben Iversons 76er niemals eine Meisterschaft gewonnen, Bryants Lakers dagegen fünf. Sorgen Sie dafür, dass Ihr Superstar ein Kobe Bryant ist.
56 1 Network Security Monitoring in der Praxis
Erfolg belohnen
Positive Rückmeldung kann die Moral enorm steigern. Wenn ein Analytiker etwas gefunden hat, was niemand sonst aufgefallen ist, dann sollten es alle wissen. Wenn ein Analytiker
nach Feierabend noch fünf Stunden an seinem Arbeitsplatz bleibt, um einem Zwischenfall
auf die Spur zu kommen, dann sollten Sie ihn wissen lassen, dass Sie sein Engagement
schätzen. Was für Belohnungen Sie geben, spielt keine so große Rolle, solange es sich nur
um etwas wirklich Wünschenswertes handelt.
Aus Fehlern lernen
Analysearbeit kann schnell ziemlich langweilig werden, insbesondere in kleinen Umgebungen, in denen nicht so viele Ereignisse oder Angriffe auftreten. Das führt dazu, dass
die Analytiker im Ernstfall leicht etwas übersehen. Anstatt die Gruppe dafür zu bestrafen,
sollten Sie dies als eine weitere Gelegenheit zum Lernen betrachten.
Bericht von der Front
Eine meiner Lieblingsmethoden, das Lernen aus Fehlern zu fördern, stammt aus
der Medizin. Wenn ein Patient stirbt, obwohl sein Tod medizinisch hätte verhindert werden können, treffen sich der behandelnde Arzt und ein Team weiterer
Ärzte zu einer sogenannten M&M-Besprechung (Morbidity and Mortality)5.
Dabei berichtet der behandelnde Arzt, wie für den Patienten gesorgt wurde, woraufhin die anderen Ärzte konstruktive Fragen stellen und alternative Schritte
vorbringen, die man hätte durchführen können. Solche Besprechungen sind
gefürchtet, aber wenn sie gut moderiert und mit einer positiven Haltung durchgeführt werden, können sie große Änderungen bewirken, wenn ähnliche Situationen erneut auftreten. Dieses Vorgehen besprechen wir im Analyseteil dieses
Buches noch ausführlicher.
Führung als Dienst ausüben
In den erfolgreichsten Organisationen, mit denen ich zusammenarbeiten durfte, wurde die
Führung als dienende Funktion verstanden (»Servant Leadership«). Dieses Führungsprinzip
gibt es schon eine ganze Weile, aber darauf aufmerksam gemacht wurde ich als Basketballfan
an der University of Kentucky vom britischen Basketballtrainer John Calipari.5
Die Führung als Dienst basiert nicht auf einem Titel oder übertragender Autorität. Führungspersonen erzielen ihre Erfolge vielmehr dadurch, dass sie die Bedürfnisse ihrer Mitarbeiter in den Vordergrund stellen. Diese demütige Haltung führt dazu, dass Sie danach
Ausschau halten, wie Sie anderen bei der Erfüllung ihrer Aufgaben helfen können, sodass
5 Campbell, W.B., »Surgical Morbidity and Mortality Meetings« (1988), http://www.ncbi.nlm.nih.gov/pmc/
articles/PMC2498614/?tool=pmcentrez
1.8 Security Onion 57
die gesamte Organisation davon profitiert. Das kann zu einer Organisation führen, die
nicht auf einen starken Führer fixiert ist, sondern in der eine Gruppe von Führern mit
unterschiedlichen Stärken und Schwächen harmonisch zusammenwirkt, um ein gemeinsames Ziel zu erreichen. Das mag ein bisschen nach Wolkenkuckucksheim klingen, doch mit
der richtigen Geisteshaltung und mit dem Engagement aller Beteiligen kann eine solche
Umgebung Wirklichkeit werden.
1.8
Security Onion
Im weiteren Verlauf dieses Buches werden wir über die Theorie hinausgehen und uns
mehrere praktische Beispiele ansehen. Zur Vereinheitlichung verwende ich für alle Beispiele Security Onion, eine Linux-Distribution für Intrusion Detection und Network
Security Monitoring. Security Onion wird von Doug Burks und einer Handvoll weiterer Beteiligten hergestellt und gehört zu meinen Lieblingsinstrumenten zum Lehren
und Lernen. Dank der einfachen Einrichtung können Sie eine komplette NSM-Suite
zum Erfassen, Erkennen und Analysieren in weniger als einer Viertelstunde bereitstellen.
­Security Onion ist jedoch nicht nur ein Weiterbildungswerkzeug. In verschiedenen kleineren Organisationen habe ich diese Distribution schon im Produktionseinsatz gesehen.
Ich selbst benutze sie für mein Büro zu Hause und mein Heimnetzwerk.
1.8.1
Installation
Wenn Sie die Beispiele in diesem Buch nachvollziehen wollen, müssen Sie Security Onion
herunterladen und installieren. Mehrere der besprochenen Werkzeuge sind darin bereits
vorinstalliert, z. B. Sort, Bro und Argus. Wenn Sie noch einen alten Computer und einige zusätzliche Netzwerkkarten haben, können Sie sie in Ihrem Netzwerk installieren, um
echten Datenverkehr zu untersuchen. Zum Durcharbeiten dieses Buches reicht es jedoch,
Security Onion in einer virtuellen Maschine zu installieren. VMWare Player und VirtualBox sind dafür hervorragend geeignet.
Nachdem Sie die Virtualisierungssoftware heruntergeladen haben, müssen Sie die ISODatei für Security Onion herunterladen. Die neueste Version finden Sie unter einem Link
auf http://ssecurityonion.blogspot.com/. Diese Seite nennt auch eine große Menge hilfreicher Quellen zur Installation und Konfiguration der verschiedenen Elemente von Security
Onion. Gehen Sie nach Abschluss des Downloads wie folgt vor:
1. Erstellen Sie eine neue virtuelle Maschine. Sehen Sie dabei mindestens 1 GB RAM für
jede überwachte Netzwerkschnittstelle und mindestens 2 GB insgesamt vor. Vergewissern Sie sich außerdem, dass die Netzwerkschnittstellen mit der virtuellen Maschine
verbunden sind.
2. Stellen Sie die heruntergeladene ISO-Datei als virtuelles CD/DVD-Laufwerk in Ihrer
Virtualisierungssoftware bereit.
58 1 Network Security Monitoring in der Praxis
Starten Sie die VM. Wenn Ihr Betriebssystem läuft, wählen Sie das Symbol Install SecurityOnion auf dem Desktop, um mit der Installation des neuen Betriebssystems auf der
virtuellen Festplatte zu beginnen.
Folgen Sie den Anweisungen des XUbuntu-Installers. Während der Installation werden
Sie um eine Reihe von Angaben gebeten, z. B. nach der gewünschten Festplattenpartitionierung, Ihrer Zeitzone, Ihrem Internetanschluss, dem Namen des Systems sowie einem
Benutzernamen und einem Passwort für Ihr Benutzerkonto (siehe Abb. 1.2). Sie können
die meisten dieser Optionen nach Belieben einrichten. Wählen Sie aber nicht die Option, Ihren Benutzerordner zu verschlüsseln, und aktivieren Sie nicht die automatischen
Updates. Diese Optionen sind standardmäßig deaktiviert. Nach Abschluss der XUbuntuInstallation werden Sie aufgefordert, das System neu zu starten.
Abbildung 1.2: Benutzerangaben während der Installation von Security Onion
Damit ist die Installation des Betriebssystems abgeschlossen.
1.8 Security Onion 59
1.8.2 Security Onion aktualisieren
Nachdem Sie die Installation abgeschlossen und die virtuelle Maschine neu gestartet haben, müssen Sie als Nächstes Security Onion auf den neuesten Stand bringen. Auch wenn
Sie die ISO-Datei gerade erst heruntergeladen haben, kann es sein, dass es Aktualisierungen für einzelne SO-Pakete gibt. Um die Aktualisierung auszulösen, geben Sie an der
Befehlszeile Folgendes ein:
sudo apt-get update && sudo apt-get dist-upgrade
Je nachdem, wie viele Aktualisierungen seit der letzten ISO-Datei freigegeben wurden,
kann der Vorgang eine Weile dauern. Wenn er abgeschlossen ist, ist Ihre Installation von
Security Onion auf dem neuesten Stand.
1.8.3 NSM-Dienste einrichten
Um die NSM-Dienste nutzen zu können, müssen Sie einen automatischen Einrichtungsvorgang ausführen. Melden Sie sich bei Security Onion an und gehen Sie dann folgendermaßen vor:
1. Starten Sie den Einrichtungsvorgang, indem Sie auf dem Desktop auf das Symbol
Setup klicken.
2. Nachdem Sie Ihr Passwort eingegeben haben, werden Sie gefragt, ob Sie etc/network/
interfaces konfigurieren möchten. Wählen Sie Yes. Bei mehreren Netzwerkschnittstellen werden Sie aufgefordert, eine davon als Verwaltungsschnittstelle auszuwählen, also
als diejenige, über die Sie auf das System zugreifen; bei nur einer einzigen Schnittstelle
wird automatisch diese als Verwaltungsschnittstelle eingerichtet. Fahren Sie fort, indem Sie die Option Static IP Address wählen und die IP-Adresse, die Subnetzmaske,
das Standardgateway, die Adresse des DNS-Servers und den lokalen Domänennamen
eingeben. Nachdem Sie diese Angaben bestätigt haben, wird das System neu gestartet.
Bericht von der Front
Auch wenn Sie es gewohnt sind, Ihre Netzwerkschnittstellen manuell einzurichten, ist es äußerst ratsam, diesen Schritt von SO ausführen zu lassen. Das
Betriebssystem führt dabei mehrere Optimierungen durch, damit Ihre Überwachungsschnittstellen korrekt eingerichtet werden, um alle möglichen Arten von
Netzwerkdatenverkehr zu erfassen.
3. Starten Sie den Einrichtungsvorgang erneut, indem Sie abermals auf das Symbol Setup
auf dem Desktop klicken.
4. Überspringen Sie die Netzwerkkonfiguration, da Sie sie bereits erledigt haben.
60 1 Network Security Monitoring in der Praxis
5. Wählen Sie Quick Setup. (Sie können natürlich auch Advanced Setup wählen, aber für
unsere Zwecke reicht die Schnelleinrichtung. Die erweiterten Optionen können Sie
sich gern auf eigene Faust ansehen.)
6. Wenn Sie über mehrere Schnittstellen verfügen, werden Sie dazu aufgefordert, die
gewünschten Überwachungsschnittstellen auszuwählen.
7. Geben Sie einen Benutzernamen und ein Passwort für die verschiedenen NSMDienste an.
8. Wenn Sie zur Aktivierung von ELSA aufgefordert werden, wählen Sie Yes.
9. Am Ende werden Sie dazu aufgefordert, die Konfiguration des Sensors zu bestätigen
(siehe Abb. 1.3). Klicken Sie auf Yes, proceed with the changes!, um Security Onion aufzufordern, die Änderungen zu übernehmen.
Abbildung 1.3: Bestätigen der Konfiguration
Nach Abschluss der Einrichtung teilt Ihnen Security Onion die Speicherorte verschiedener wichtiger Protokoll- und Konfigurationsdateien mit. Wenn Sie bei der Einrichtung
Probleme haben oder feststellen, dass einer der Dienste nicht richtig gestartet wurde,
können Sie sich das Einrichtungsprotokoll unter /var/log/nsm/sosetup.log ansehen. Sofern
nicht anders angegeben, wird im weiteren Verlauf dieses Buches vorausgesetzt, dass Sie die
Schnelleinrichtung von Security Onion abgeschlossen haben.
1.8.4 Security Onion testen
Die schnellste Möglichkeit, sich zu vergewissern, dass die NSM-Dienste in Security
Onion laufen, besteht darin, Snort einen Alarm generieren zu lassen. Dazu sollten Sie
zunächst den von Snort verwendeten Regelsatz mithilfe des Befehls sudo rule-update
1.8 Security Onion 61
aktualisieren. Dadurch werden mithilfe des Dienstprogramms PulledPork die neuesten
Regeln von Emerging Threats heruntergeladen, eine neue SID-Zuordnung erstellt (um
den Regelnamen eindeutige Bezeichner zuzuordnen) und Snort neu gestartet, damit die
neuen Regeln in Kraft treten. In Abb. 1.4 sehen Sie einen Teil der Ausgabe dieses Befehls.
Abbildung 1.4: Ausgabe bei einer Regelaktualisierung
Um die NSM-Dienste zu testen, starten Sie Snorby, indem Sie auf das zugehörige Symbol
auf dem Desktop klicken. Sie werden dazu aufgefordert, sich mit der während der Einrichtung angegebenen E-Mail-Adresse und dem zugehörigen Passwort anzumelden. Klicken
Sie danach auf die Registerkarte Events am oberen Bildschirmrand. Sehr wahrscheinlich
ist das Fenster zu diesem Zeitpunkt leer.
Um eine Snort-Warnung auszulösen, öffnen Sie im Browserfenster eine neue Registerkarte
und rufen dort http://www.testmyids.com auf.
Wenn Sie jetzt wieder zur Snorby-Registerkarte wechseln und die Seite Events aktualisieren,
sollten Sie einen Alarm mit der Ereignissignatur GPL ATTACK_RESPONSE id check returned root sehen (siehe Abb. 1.5). Wenn das der Fall ist, haben Sie die NSM-Umgebung von
Security Onion erfolgreich eingerichtet. Sie können den Alarm gern genauer untersuchen,
62 1 Network Security Monitoring in der Praxis
indem Sie darauf klicken und sich die Ausgabe in Snorby ansehen. In späteren Kapiteln
werden uns noch genauer mit Snorby beschäftigen.
Abbildung 1.5: Der Snort-Testalarm in Snorby
Diese Alarmmeldung sollte ziemlich schnell erscheinen. Wenn Sie sie nach einigen Minuten
immer noch nicht sehen, funktioniert etwas nicht richtig. Informieren Sie sich auf der Website zu Security Onion über die Fehlerbehebung. Wenn Sie das Problem dadurch nicht lösen
können, schauen Sie in die Mailingliste von Security Onion oder im zugehörigen IRC-Kanal
#securityonion auf Freenode.
Die beschriebenen Vorgänge sind bis Security 12.04 gültig, der aktuellen Version während
der Abfassung dieses Buches. Sollte sich der Vorgang geändert haben, schlagen Sie im SOWiki unter https://code.google.com/p/security-onion/w/list nach. Wir werden im Verlauf
dieses Buches noch häufiger auf Security Onion eingehen. Wenn Sie noch mehr darüber
erfahren wollen, ist das SO-Wiki die beste Informationsquelle.
1.9
Zusammenfassung
In diesem Kapitel haben Sie Network Security Monitoring, bedrohungsorientierte Sicherheit und verwandte Prinzipien kennengelernt. Wir haben uns auch Security Onion angesehen und ausführlich beschrieben, wie Sie eine NSM-Umgebung in wenigen Minuten installieren und einrichten. Für Neulinge in Sachen NSM ist es von entscheidender Bedeutung,
die in diesem Kapitel vorgestellten Prinzipien genau zu verstehen, da sie die Grundlage für
die Anwendung von NSM bilden. Der Rest dieses Buches ist in drei Teile gegliedert, die sich
jeweils mit den einzelnen Elementen des NSM-Zyklus beschäftigen: Erfassung, Erkennung
und Analyse.
Teil 1
Erfassung
2
Die Datenerfassung planen
Die Erfassung wird mit einer Kombination aus Hardware und Software durchgeführt,
die Daten für die NSM-Erkennung und -Analyse generieren und sammeln. Analytiker
mögen vielleicht denken, dass dieser Abschnitt keine große Bedeutung für sie hat. Das ist
allerdings ein Irrtum. Es gibt viele verschiedene Möglichkeiten, erfolgreiche Analytiker
zu beschreiben (ich bevorzuge den Begriff »Paket-Ninja«), aber letzten Endes muss ein
Analytiker Herr und Meister über die Daten sein, d. h., er muss wissen, welche Daten zur
Verfügung stehen, woher sie kommen, wie sie erfasst werden, warum sie erfasst werden
und was man damit tun kann. Gute Analytiker können auch schlechte Daten nützlich
einsetzen und mit guten Daten Hervorragendes leisten.
Nur allzu oft kümmern sich Analytiker nicht um die Erfassung. Das führt gewöhnlich
dazu, dass ein eigenes System oder eine andere Gruppe für die Erfassung zuständig ist
oder ein einzelner Analytiker als »Erfassungsknecht« abgestellt wird. Für das NSM ist es
jedoch nicht förderlich, wenn die Informationen über die Datenerfassung anderen Gruppen oder nur einzelnen Mitgliedern des NSM-Teams zur Verfügung stehen, denn dies
führt dazu, dass die Analytiker die Daten, die sie analysieren, nicht vollständig verstehen.
Die meisten Organisationen fallen in eine der folgenden drei Kategorien:
•• Organisationen ohne NSM-Infrastruktur, die gerade erst am Anfang stehen, ihre
Bedürfnisse für die Datenerfassung zu definieren.
66 2 Die Datenerfassung planen
•• Organisationen, die bereits Intrusion Detection durchführen, sich die erfassten Daten
aber nie genauer angesehen haben.
•• Organisationen, die viel Zeit investiert haben, um eine Datenerfassungsstrategie aufzustellen, und die diese Strategie im Rahmen ihres NSM-Zyklus ständig weiterentwickeln.
Dieser Abschnitt beschreibt die Datenerfassung von der Pike auf, sodass alle drei Arten
von Organisationen davon profitieren können.
2.1
Applied Collection Framework (ACF)
Abraham Lincoln sagte einmal: »Wenn ich sechs Stunden Zeit habe, um einen Baum zu
fällen, nutze ich die ersten vier Stunden, um meine Axt zu schärfen.« Ich kann mir kein
treffenderes Zitat vorstellen, um die Wichtigkeit der Datenerfassung zu beschreiben.
Wie ich bereits gesagt habe, muss ein guter Analytiker Herr und Meister der Daten sein.
Das lässt sich jedoch oft nur schwer erreichen, da viele Organisationen ihre Daten nicht
richtig verstehen. Meistens gibt es keine strukturierte Vorgehensweise, um die Bedrohungen zu definieren, denen die Organisation ausgesetzt ist. Stattdessen werden einfach alle
Daten erfasst, die gerade zur Verfügung stehen, und das Überwachungsprogramm wird
um diese Daten herum aufgebaut. Ein solches Übermaß an Daten führt jedoch dazu, dass
auf den Servern nicht genügend Speicherplatz zur längeren Aufbewahrung der Daten zur
Verfügung steht, dass mehr Personal erforderlich ist, um alle Ereignisse und Fehlalarme
zu durchforsten, und dass Erkennungs- und Analysewerkzeuge nicht mit der Menge der
vorliegenden Daten fertig werden.
Als Verteidiger unseres Netzwerks hassen wir Überraschungen. Gewöhnlich wird das
Auftreten von Überraschungen als eine Funktion der Unsicherheit angesehen, aber es ist
auch eine Funktion der Komplexität.1 Ein Übermaß an Daten zu sammeln, die nichts mit
sinnvoll anzunehmenden Bedrohungen der Organisation zu tun haben, ist eine sichere
Methode, um die Komplexität sehr schnell zu erhöhen.
Eine große Rolle dabei, die Kompexität der Datenerfassung zu senken, spielt das Applied
Collection Framework (ACF). Es handelt sich dabei um eine lockere Folge von Schritten,
mit deren Hilfe eine Organisation entscheiden kann, auf welche Datenquellen sie sich bei
der Erfassung konzentrieren sollte (siehe Abb. 2.1).
Bedrohungen
idenfizieren
Risiko
quanfizieren
Datenquellen
idenfizieren
Erfassung
eingrenzen
Abbildung 2.1: Das Applied Collection Framework (ACF)
1 Bracken, P. (2008), Managing strategic surprise, Cambridge, MA: Cambridge University Press
2.1 Applied Collection Framework (ACF) 67
Das ACF schwebt nicht im luftleeren Raum. Um es erfolgreich anwenden zu können, ist
von Anfang an eine Zusammenarbeit mit der Geschäftsleitung erforderlich. Das Sicherheitsteam und andere Beteiligte sind dafür zuständig, die aus den ersten Besprechungen
gewonnenen Erkenntnisse in Maßnahmen umzusetzen. Das ACF besteht aus vier Phasen:
die Bedrohungen der Organisation identifizieren, das Risiko quantifizieren, die relevanten Datenquellen herausfinden und die Erfassung auf die wirklich nützlichen Elemente
einschränken.
2.1.1
Bedrohungen identifizieren
Für eine bedrohungsorientierte Verteidigung ist es erforderlich, die Bedrohungen identifizieren zu können, denen Sie sich ausgesetzt sehen. Damit meine ich keine allgemeinen
Bedrohungen wie Konkurrenzunternehmen, Script-Kiddies, Hacktivisten oder feindliche
Nationen, sondern spezifische Bedrohungen der Ziele Ihrer Organisation.
Beginnen Sie dabei immer mit der Frage: »Was ist der schlimmste Fall für das Überleben
der Organisation?« Die Antwort muss von ganz oben kommen, weshalb die mit Informationssicherheit betrauten Personen mit der Geschäftsführung zusammenarbeiten müssen,
wenn sie damit beginnen, die Erfordernisse zur Datenerfassung aufzustellen.
Es ist hilfreich, die Bedrohungen danach einzuteilen, ob sie Vertraulichkeit, Integrität oder
Verfügbarkeit gefährden. Betrachten Sie dazu folgende Beispiele:
•• Ein produzierendes Unternehmen verlässt sich darauf, dass die Herstellung das ganze
Jahr über rund um die Uhr läuft, um die Nachfrage nach den Produkten zu befriedigen. Wenn irgendetwas geschieht, was die Produktion unterbricht, ruft das erhebliche
Kosten für die Organisation hervor. Daher kann eine Produktionsunterbrechung als
größte Bedrohung der Organisation angesehen werden. Es handelt sich dabei um eine
Gefährdung der Verfügbarkeit.
•• Eine Anwaltskanzlei muss sich darauf verlassen können, dass Informationen vertraulich bleiben. Oftmals handhaben solche Firmen Informationen, deren Freiwerden andere Organisationen Millionen von Euro oder sogar das Leben von Menschen kosten
könnte. Die Kommunikation zwischen Anwälten und ihren Mandanten ist von äußerster Wichtigkeit. Die Gefahr, dass Dritte diese Kommunikation abhören, kann die
größte Bedrohung einer Kanzlei sein. Hierbei handelt es sich um eine Gefährdung der
Vertraulichkeit.
•• Für seinen Umsatz stützt sich ein Onlinehändler auf seine Website. Wenn sie auch nur
für wenige Minuten nicht erreichbar ist, kann das zum Verlust vieler Verkäufe und
damit hoher Erträge führen. Die größte Bedrohung für eine solche Organisation ist
das Unvermögen, Verkaufe abzuschließen. Dies ist eine Gefährdung der Verfügbarkeit.
•• Rohstoffhändler müssen während des Börsentages mit ausländischen Partnern Informationen austauschen können, um Handelsgeschäfte abschließen zu können, die
Einkünfte generieren. Sind diese Informationen nicht korrekt, kann das aufgrund
automatischer Handelsalgorithmen zu einem Welleneffekt und dadurch zu Verlus-
68 2 Die Datenerfassung planen
ten in Millionenhöhe führen. Die größte Bedrohung für eine solche Organisation
sind vorsätzliche oder versehentliche Fehler in den Daten, die in diese Algorithmen
einfließen. Hierbei handelt es sich um eine Gefährdung der Datenintegrität.
•• Ein Pharmaunternehmen konzentriert alle seine Anstrengungen auf die Entwicklung
neuer Medikamente. Die Forschungsdaten stellen das dar, wofür die gesammelten Gelder der Investoren eingesetzt worden sind, und bilden eine wichtige Zukunftsinvestition für das Unternehmen. Sollte ein Konkurrent Zugriff auf diese Informationen
erlangen, kann das die gesamte Organisation ruinieren. Der Diebstahl des geistigen Eigentums ist die größte Bedrohung, der sich dieses Unternehmen gegenübersieht. Dies
ist eine Gefährdung der Vertraulichkeit.
In der Praxis machen sich Organisationen jedoch gewöhnlich Sorgen über mehrere verschiedene Bedrohungen. In diesem Fall muss die Geschäftsführung die Bedrohungen
nach Prioritäten ordnen, sodass sie entsprechend berücksichtigt werden können.
Nachdem die Bedrohungen identifiziert worden sind, ist es Aufgabe der Mitarbeiter für
Informationssicherheit, sich genauer mit den technischen Grundlagen dieser Bedrohungen zu befassen. Dazu müssen Sie die Infrastruktur des Netzwerks untersuchen und den
wichtigsten Beteiligten an den entsprechenden Geschäftsprozessen die richtigen Fragen
stellen.
Das wollen wir uns genauer am Beispiel des Pharmaunternehmens aus dem letzten Aufzählungspunkt ansehen. Diese Firma hat sehr stark in ihr geistiges Eigentum investiert und sieht
den Verlust dieses geistigen Eigentums als größte Bedrohung an. Daher sollten Sie folgende
Fragen stellen:
•• Welche Geräte generieren die Rohdaten der Forschungsarbeiten? Wie werden diese
Daten über das Netzwerk übertragen?
•• Auf welchen Geräten verarbeiten Mitarbeiter diese Rohdaten?
•• Auf welchen Geräten werden die verarbeiteten Forschungsdaten gespeichert?
•• Wer hat Zugriff auf die Rohdaten und die verarbeiteten Daten?
•• Sind die Rohdaten oder die verarbeiteten Daten außerhalb des Netzwerks zugänglich?
•• Welche Pfade ins interne Netzwerk stehen außerhalb zur Verfügung?
•• Welchen Zugriff auf die Forschungsdaten haben vorübergehend Beschäftigte?
Aufgrund der Antworten sollten Sie sich ein Bild davon machen können, welche Elemente im Netzwerk für den Schutz dieser sensiblen Daten besonders kritisch sind. Das Ziel
besteht darin, systematisch zu ermitteln, mit welchen Methoden jemand in das Netzwerk
eindringen und dadurch möglicherweise wichtige Informationen stehlen kann. Ein grobes Ergebnis kann etwa in einer Liste wie der folgenden bestehen:
••
••
••
••
Einbruch in den Webserver
Einbruch in den Datenbankserver
Einbruch in den Dateiserver
Abruf von Daten durch verärgerte Mitarbeiter
2.1 Applied Collection Framework (ACF) 69
2.1.2 Das Risiko quantifizieren
Nachdem Sie eine Liste der möglichen technischen Bedrohungen aufgestellt haben, müssen Sie sie nach Prioritäten ordnen. Eine Möglichkeit dazu besteht darin, das jeweilige
Risiko der einzelnen Bedrohungen zu berechnen. Das Risiko ist dabei das Produkt von
Auswirkung und Wahrscheinlichkeit, als Gleichung geschrieben also: Risiko = Auswirkung x Wahrscheinlichkeit.
Zur Bewertung der Auswirkung müssen Sie überlegen, wie stark eine Bedrohung, sollte
sie tatsächlich eintreffen, die Organisation beeinträchtigen würde. Gemessen wird dies
auf einer Skala von 1 bis 5, wobei 1 für geringe Auswirkungen und 5 für erhebliche Auswirkungen steht. Um die Stärke der Auswirkung zu bestimmen, können Sie Aspekte wie
finanzielle Verluste, die Fähigkeit, verlorene Daten wiederherzustellen, und die erforderliche Zeit berücksichtigen, um zum normalen Betriebsauflauf zurückzukehren.
Auch die Wahrscheinlichkeit dafür, dass die Bedrohung eintritt, wird auf einer Skala von
1 bis 5 gemessen. Auch hier steht eine 1 für eine geringe und eine 5 für eine hohe Wahrscheinlichkeit. Zur Bewertung können Sie überlegen, wie groß die Angriffsfläche eines
Objekts ist, also wie stark es Bedrohungen ausgesetzt ist, wie vertraut jemand mit dem
Netzwerk sein muss, um einen Angriff ausführen zu können, oder wie leicht jemand
physischen Zugang zu einem Objekt erhalten kann. Im Lauf der Zeit wächst die Wahrscheinlichkeit dafür, dass eine Schwachstelle ausgenutzt wird. Wenn wir Wahrscheinlichkeiten aufstellen, so gelten sie für den aktuellen Zeitpunkt und müssen später einer neuen
Prüfung unterzogen werden.
Das Produkt aus Auswirkungen und Wahrscheinlichkeit gibt den Grad des Risikos an,
dass die Bedrohung für die Sicherheit des Netzwerks und die Geschäftsziele der Organisation bildet. Gemessen wird dies auf einer Skala von 1 bis 25, die sich grob in drei Bereiche
unterteilen lässt:
•• 0–9: Geringes Risiko
•• 10–16: Mittleres Risiko
•• 17–25: Hohes Risiko
Die Bewertung der technischen Risiken für das Pharmaunternehmen aus unserem Beispiel
sehen Sie in Tabelle 2.1.
Tabelle 2.1: Quantifizierung der Risiken für das Beispielunternehmen
Bedrohung
Auswirkung
Wahrscheinlichkeit
Risiko
Einbruch in den Webserver
3
4
12
Einbruch in den Datenbankserver
5
3
15
Abruf von Daten durch verärgerte
Mitarbeiter
5
4
20
Einbruch in den Dateiserver
5
4
20
70 2 Die Datenerfassung planen
Auswirkung und Wahrscheinlichkeit sollen zwar eine Möglichkeit bieten, Bedrohungen
zu quantifizieren, doch sind die Zahlen subjektiv. Daher ist es wichtig, dass diese Zahlen
von einem Komitee ermittelt werden und dass die Bewertung aller erkannten Bedrohungen durch dieselbe Gruppe mit denselben Mitgliedern vorgenommen wird. Manche Organisationen nehmen zur Quantifizierung von Risiken die Hilfe von Dritten in Anspruch,
aber ich habe noch nie erlebt, dass das im Zusammenhang mit Netzwerksicherheit jemals
erfolgreich gewesen ist.
2.1.3 Datenquellen identifizieren
In der nächsten Phase des ACF geht es darum, die wichtigsten Datenquellen zu ermitteln,
die für die NSM-Erkennung und -Analyse von Wert sein können. Überlegen Sie, beginnend mit der Bedrohung, die das höchste Risiko zeigt, wo Sie Belege dafür finden können,
dass die Bedrohung tatsächlich eintritt.
In unserem Beispiel sehen wir uns also die Bedrohung durch einen Einbruch in den Da­
teiserver an. Bei der Definition dieser Bedrohung sollten Sie sich schon darüber informiert
haben, welche Architektur dieser Server aufweist, wo er sich im Netzwerk befindet, wer Zugriff drauf hat und auf welchen Wegen Daten zu und von ihm übertragen werden können.
Mithilfe dieser Angaben können Sie nun Datenquellen im Netzwerk und auf dem Host
ausfindig machen. Am Ende steht dabei eine Liste wie die folgende:
•• Im Netzwerk:
• Dateiserver-VLAN – Paketerfassungsdaten
• Dateiserver-VLAN – Sitzungsdaten
• Dateiserver-VLAN – Datendurchsatzstatistiken
• Dateiserver-VLAN – Alarmdaten des signaturgestützten NIDS
• Dateiserver-VLAN – Alarmdaten des anomaliegestützten IDS
• Vorgeschalteter Router – Protokolldaten der Firewall
•• Auf dem Host:
• Dateiserver – Daten aus dem Ereignisprotokoll des Betriebssystems
• Dateiserver – Alarmdaten der Antivirussoftware
• Dateiserver – Alarmdaten des HIDS
Wie Sie sehen, ist diese Aufstellung noch sehr grob, aber das ist ganz in Ordnung so. An
dieser Stelle beginnen wir erst damit, die brauchbaren Datenquellen zu identifizieren. Die
Verfeinerung erfolgt im nächsten Schritt.
2.1.4 Die Erfassung eingrenzen
Die letzte Phase des ACF besteht darin, die Auswahl der Datenquellen immer weiter zu
verfeinern. Dies ist der technisch anspruchsvollste Schritt, und er erfordert, dass Sie sich
2.1 Applied Collection Framework (ACF) 71
jede einzelne Datenquelle ansehen, um ihren Wert zu bestimmen. Manche Datenquellen erfordern im Vergleich zu dem Wert, den sie bieten, einen unverhältnismäßig hohen
Speicher-, Verarbeitungs- oder Verwaltungsaufwand, weshalb es sich nicht lohnt, sie zu
erfassen. Letzen Endes muss Ihre Organisation eine Kosten/Nutzen-Analyse der Datenquellen durchführen, um zu bestimmen, ob der Wert, den sie bieten, die Kosten für die
Implementierung und Pflege rechtfertigt. Zur Bestimmung der Kosten müssen Sie die
Hardware- und Softwareressourcen und die Mitarbeiter berücksichtigen, die erforderlich
sind, um die Daten zu generieren, zu verwalten und zu speichern. Um den Nutzen zu
ermitteln, forschen Sie nach, wie viele dokumentierte Fälle es gibt, in denen die fragliche
Datenquelle bei einer Untersuchung herangezogen oder schmerzlich vermisst worden ist.
Im Rahmen dieses Vorgangs können Sie auch festlegen, welche Arten von PCAP-Daten
Sie ausdrücklich erfassen wollen oder welche Ereignisse im Windows-Sicherheitsprotokoll
von so großer Bedeutung sind, dass sie aufbewahrt werden müssen.
Während dieses Vorgangs müssen Sie Fragen wie die folgenden stellen:
•• Was können Sie in einem bestimmten Netzwerksegment aus dem PCAP-Datenverkehr
herausfiltern?
•• Welche Systemereignisprotokolle sind am wichtigsten?
•• Müssen Sie sowohl die Aktionen der Firewall aufbewahren, die Verbindungen zulassen,
als auch diejenigen, die Verbindungen verweigern?
•• Sind die Protokolle zur WLAN-Authentifizierung und -Zuordnung von Wert?
•• Sollen Sie Protokolle für den Zugriff auf Dateien, für ihre Erstellung und Änderung
aufbewahren?
•• Für welche Teile einer Webanwendung brauchen Sie wirklich Webprotokolle?
Definieren Sie auch, wie viele Daten der einzelnen Typen wie lange aufbewahrt werden
sollen. Das können Sie in Form eines Mindest- und eines Optimalwerts angeben. Der
Mindestwert gibt dabei an, wie viele Daten unbedingt erforderlich sind, um eine Erkennung in nahezu Echtzeit durchzuführen, während der Optimalwert die bevorzugte Datenmenge für eine Erkennung im Nachhinein und für die Analyse nennt.
Die grobe Liste aus der vorherigen Phase können wir nun wie folgt verfeinern:
•• Im Netzwerk:
• Paketerfassungsdaten
ºº Alle Ports und Protokolle zum und vom Dateiserver
ºº Der gesamte außerhalb des VLANs geleitete SMB-Datenverkehr
• Sitzungsdaten
ºº Alle Einträge für das VLAN
• Datendurchsatzstatistiken
ºº Langfristige Datendurchsatzstatistiken für den Dateiserver
ºº Tägliche, wöchentliche und monatliche Durchschnittswerte
72 2 Die Datenerfassung planen
• Alarmdaten des signaturgestützten NIDS
ºº Alle Alarme für das Segment
ºº Regeln für Windows-Systeme und das Protokoll SMB
• Alarmdaten des anomaliegestützten IDS
ºº Alarme über Veränderungen im Betriebssystem des Dateiservers
ºº Alarme über ein plötzliches Übermaß oder einen hohen Durchsatz von Dateidownloads
• Vorgeschalteter Router – Protokolldaten der Firewall
ºº Verweigerung von eingehenden Verbindungen durch die Firewall
•• Auf dem Host:
• Daten aus dem Ereignisprotokoll des Betriebssystems – Windows-Sicherheitsprotokoll
ºº Erfolgreiche Anmeldungen
ºº Fehlgeschlagene Anmeldungen
ºº Kontoerstellungen und -änderungen
• Daten aus dem Ereignisprotokoll des Betriebssystems – Windows-Systemprotokoll
ºº Änderungen von Berechtigungen im Dateisystem
ºº Softwareinstallationen
ºº Neustarts des Systems
• Alarmdaten der Antivirussoftware
ºº Festgestellte Ereignisse
ºº Blockierte Ereignisse
• Alarmdaten des HIDS
ºº Alarme wegen kritischer Änderungen im Dateisystem
ºº Alarme wegen übermäßiger Aufzählungen von Dateien
ºº Alarme im Zusammenhang mit dem Anlegen und Ändern von Konten
Anhand dieser Liste können Sie den zuständigen System- und Netzwerkteams genau erklären, welche Daten Sie brauchen. Nun muss auch noch die Infrastruktur entsprechend
eingerichtet werden, um Ihre Bedürfnisse für die Datenerfassung zu erfüllen. Machen Sie
sich aber zunächst nicht zu viele Gedanken über die Kosten für diese Infrastruktur; das ist
eine Geschäftsentscheidung, die getroffen werden muss, nachdem Sie das ACF-Verfahren
komplett abgearbeitet haben. Der Zweck dieser systematischen Vorgehensweise besteht
darin, die zu erfassenden Daten zu ermitteln und zu bestimmen, wie wichtig sie sind.
Wenn das Budget keine optimale Datenerfassung ermöglicht, sollten Sie zumindest eine
Aufstellung zur Hand haben, die Ihnen sagt, worauf Sie am ehesten verzichten können.
Grundlage dafür kann die zuvor beschriebene Kosten/Nutzen-Analyse sein. Wichtig ist
hierbei, dass Sie Ihre Bedürfnisse für die Datenerfassung rechtfertigen, indem Sie sie direkt mit den Geschäftszielen und den Bedrohungen des Geschäftsbetriebs in Verbindung
bringen.
2.2 Fallstudie: Onlinehändler 73
Wenn Sie noch nicht viel Erfahrung mit NSM haben, ist Ihnen oft nicht klar, wie viel Wert
einzelne Datenquellen bieten. Im Laufe der Zeit werden Sie Erfahrungen darin sammeln.
Bis es soweit ist, werden Sie in einigen Fällen erleben, dass Sie auf einige Ihrer Datenquellen verzichten können, während es sich in anderen als ratsam erweist, zusätzliche Daten zu
erfassen. Die Dokumente, die Sie im Rahmen dieses Prozesses anlegen, sind niemals endgültig. Es ist wichtig zu verstehen, dass man bei der NSM-Datenerfassung niemals einen
endgültigen Stand erreicht. Sie ist ein dynamischer Prozess. Mit wachsenden Erfahrungen
in der Erkennung und Analyse und mit der Erweiterung Ihres Netzwerks müssen Sie Ihre
Erfassungsstrategie immer wieder anpassen.
Auf der Begleitwebsite zu diesem Buch finden Sie Vorlagen, die Ihnen dabei helfen, die
ACF-Schritte durchzuführen. Nach dem ersten Durchgang sind diese Vorlagen auch eine
hervorragende Ressource, mit deren Hilfe sich Ihre Analytiker mit den erfassten Daten
vertraut machen können.
2.2
Fallstudie: Onlinehändler
Sehen wir uns als Beispiel einen Onlinehändler an, der zum ersten Mal NSM einrichtet.
Unser fiktives Unternehmen Purple Dog Inc. (PDI) verkauft über seine Website kunsthandwerkliche Produkte und Nippes von anderen Herstellern. Da es kein Ladengeschäft
hat, hängen seine gesamten Einkünfte davon ab, dass es Verkäufe über die Website tätigen
kann.
Abb. 2.2 zeigt das Netzwerk von PDI. Wir haben es hier mit dem typischen Netzwerkdesign zu tun, bei dem sich öffentlich zugängliche Server in einer »entmilitarisierten Zone«
(De-militarized Zone, DMZ) hinter einem Edge-Router stehen. Die Benutzercomputer
und internen Netzwerkserver befinden sich in verschiedenen VLANs hinter einem Kernrouter.
In diesem Netzwerkdiagramm sind keine Sensoren enthalten. Das liegt daran, dass wir die
Erfassung erst einrichten müssen.
74 2 Die Datenerfassung planen
Abbildung 2.2: Diagramm des Netzwerks von Purple Dog Inc.
2.2.1 Bedrohungen der Organisation identifizieren
PDI stellt selbst keine Produkte her, sondern fungiert als Zwischenhändler für andere Produkte. Auf die Frage danach, wovor sie am meisten Angst hat, antworten die Geschäftsleitung wie folgt:
Angst Nr. 1: »Vor dem Diebstahl der Kreditkarteninformationen unserer Kunden. Wir
müssten dann hohe Strafen zahlen und unsere Kunden würden uns nicht mehr vertrauen,
worunter das Geschäft leiden würde.«
Angst Nr. 2: »Davor, dass unsere Website für längere Zeit unzugänglich wird. Ab einer
gewissen Dauer kann das die Fortführung unserer Geschäfte gefährden.«
Angst Nr. 3: »Davor, dass irgendjemand einen Bug findet, der es ihm erlaubt, auf unserer
Website zu bestellen, ohne dafür zu zahlen. Das würde zu Verlusten an Einnahmen führen.«
Diese Ängste wollen wir nun von den Formulierungen der Geschäftsführung in fassbare
Bedrohungen übersetzen.
2.2 Fallstudie: Onlinehändler 75
Diebstahl von Kundendaten (Vertraulichkeit)
Auf der E-Commerce-Site von PDI werden personenbezogene Kundendaten (Personally
Identifiable Information, PII) erfasst und gespeichert, darunter auch Kreditkartenangaben. Die Datenbank, in der diese Informationen festgehalten werden, ist zwar nicht direkt
vom Internet aus zugänglich, aber es ist denkbar, dass ein Angreifer durch eine Schwachstelle in der Webanwendung, die damit verbunden ist, auf diese Daten zugreift. Des Weiteren ist es möglich, dass ein Angreifer die Arbeitsstation eines Angestellten übernimmt, der
Zugriff auf die Datenbank hat, z. B. eines Entwicklers, und darüber an die Informationen
gelangt.
Unterbrechung des E-Commerce-Dienstes (Verfügbarkeit)
Ein Angreifer kann die E-Commerce-Website für Kunden unerreichbar machen. Das
kann durch einen Denial-of-Service-Angriff geschehen, der die Server oder das Netzwerk
überlastet. Es ist auch möglich, dass ein Angreifer ein von außen zugängliches Element des
Netzwerks übernimmt und darüber eine Aktion ausführt, die die Dienste unzugänglich
macht. Eine dritte Variante besteht darin, dass ein Angreifer in das interne Netzwerk einbricht und so in dem Netzwerksegment mit den E-Commerce-Servern Fuß fasst, sodass
er von dort aus seine störenden Aktionen durchführen kann.
Nicht bestimmungsgemäße Benutzung des E-Commerce-Dienstes
(Integrität)
Ein Angreifer kann die Webanwendung auf nicht bestimmungsgemäße Weise nutzen, z. B.
um Produkte zu erwerben, ohne dafür zu bezahlen. Die wahrscheinlichste Möglichkeit
dafür besteht darin, dass ein Angreifer von außen einen Bug in der E-Commerce-Webanwendung findet und ausnutzt. Es ist auch denkbar, dass ein Gegner einen internen Benutzercomputer übernimmt, der Zugriff auf die Back-End-Datenbank der E-Commerce-Site
hat.
2.2.2 Das Risiko quantifizieren
Anhand der Wahrscheinlichkeit für ihr Auftreten und ihre möglichen Auswirkungen
können wir die Bedrohungen nun nach Prioritäten ordnen. Die Risikobewertung der im
vorherigen Schritt identifizierten Bedrohungen finden Sie in Tabelle 2.2.
76 2 Die Datenerfassung planen
Tabelle 2.2: Quantifizieren der Risiken für die Bedrohungen von PDI
Bedrohung
Auswirkung
Wahrscheinlichkeit
Risiko
Diebstahl von Kundendaten über die
Webanwendung
4
4
16
Diebstahl von Kundendaten über
einen internen Benutzercomputer
4
2
8
Unterbrechung des E-CommerceDienstes durch DoS-Angriff
4
2
8
Unterbrechung des E-CommerceDienstes über ein extern zugängliches Netzwerkelement
5
3
15
Unterbrechung des E-CommerceDienstes über ein internes Netzwerk­
element
5
2
10
Nicht bestimmungsgemäße Benutzung des E-Commerce-Dienstes über
die Webanwendung
2
4
8
Nicht bestimmungsgemäße Benutzung des E-Commerce-Dienstes über
ein internes Netzwerkelement
2
1
2
Auswirkung
Wahrscheinlichkeit
Risiko
Diebstahl von Kundendaten über die
Webanwendung
4
4
16
Unterbrechung des E-CommerceDienstes über ein extern zugängliches Netzwerkelement
5
3
15
Unterbrechung des E-CommerceDienstes über ein internes Netzwerk­
element
5
2
10
Nicht bestimmungsgemäße Benutzung des E-Commerce-Dienstes über
die Webanwendung
2
4
8
Unterbrechung des E-CommerceDienstes durch DoS-Angriff
4
2
8
Tabelle 2.3: Nach Priorität geordnete Bedrohungen von PDI
Bedrohung
2.2 Fallstudie: Onlinehändler 77
Bedrohung
Auswirkung
Wahrscheinlichkeit
Risiko
Diebstahl von Kundendaten über
einen internen Benutzercomputer
4
2
8
Nicht bestimmungsgemäße Benutzung des E-Commerce-Dienstes über
ein internes Netzwerkelement
2
1
2
Laut dieser Tabelle ist die größte Bedrohung der Organisation der Diebstahl von Kundendaten über die Webanwendung. Am wenigsten besorgniserregend von allen aufgeführten
Bedrohungen ist die nicht bestimmungsgemäße Verwendung der E-Commerce-Dienste
mithilfe eines übernommenen internen Computers. Mithilfe dieser Erkenntnisse treffen
wir unsere Entscheidungen im nächsten Schritt.
2.2.3 Datenquellen identifizieren
Nachdem wir die Prioritäten aufgestellt haben, können wir bestimmen, welche Datenquellen für die NSM-Erkennung und -Analyse nützlich sind. Der Kürze halber sehen wir
uns nur die Bedrohungen mit der höchsten Risikobewertung an.
Diebstahl von Kundendaten über die Webanwendung
Die größte Bedrohung der Organisation besteht darin, dass ein Angreifer Kundendaten
stiehlt, nachdem er die Webanwendung übernommen hat. Die Angriffsfläche der Webanwendung ist sehr groß, allerdings kann darüber nur eine relativ kleine Angriffsfläche der
Netzwerkelemente bloßgelegt werden.
Es ist von entscheidender Bedeutung, dass wir Webservertransaktionen mit externen Benutzern erfassen und untersuchen, um unnormales Verhalten zu erkennen. Dazu können wir
am Rand des Netzwerks einen Sensor platzieren, um Paketdaten, Sitzungsdaten und Paketstringdaten zu erfassen. Das ermöglicht uns auch, signatur- und anomaliegestützte NIDS
einzusetzen.
Wir können uns auch Einblick in die Aktionen des Webservers verschaffen, indem wir die
Daten seiner Anwendungsprotokolle erfassen.
Da die Webanwendung einen indirekten Benutzerzugriff auf die Back-End-Datenbank
bietet, müssen wir auch die damit einhergehenden Transaktionen unbedingt untersuchen.
Da sich der Datenbankserver im internen Netzwerk befindet, brauchen wir einen zweiten
Sensor, der dort Einsicht nehmen kann. Auch dieser Sensor ermöglicht es uns, Paketdaten,
Sitzungsdaten und Paketstringdaten zu erfassen sowie signatur- und anomaliegestützte
NIDS einzusetzen.
78 2 Die Datenerfassung planen
Der Datenbankserver führt wahrscheinlich eigene Anwendungsprotokolle, über die wir
Einsichten in seine Aktionen gewinnen können.
Das Ergebnis unserer Planungen ist daher eine Liste der folgenden Datenquellen:
••
••
••
••
••
••
••
••
••
••
••
••
DMZ-Sensor: Paketdaten
DMZ-Sensor: Sitzungsdaten
DMZ-Sensor: Paketstringdaten
DMZ-Sensor: Signaturgestütztes NDIS
DMZ-Sensor: Anomaliegestütztes NDIS
Interner Sensor: Paketdaten
Interner Sensor: Sitzungsdaten
Interner Sensor: Paketstringdaten
Interner Sensor: Signaturgestütztes NDIS
Interner Sensor: Anomaliegestütztes NDIS
Anwendungsprotokolldaten des Webservers
Anwendungsprotokolldaten des Datenbankservers
Unterbrechung des E-Commerce-Dienstes über ein extern
zugängliches Netzwerkelement
Die nächste Bedrohung mit hohem Risiko besteht darin, dass ein extern zugänglicher
Computer geknackt und darüber der E-Commerce-Dienst unterbrochen wird. Da es hierbei auch um einen Angriff auf die Webanwendung gehen kann, muss auch deren Angriffsfläche bei den folgenden Überlegungen berücksichtigt werden.
Bei PDI gibt es nur zwei Arten von Netzwerkcomputern, die extern zugänglich sind, nämlich die E-Commerce-Webserver, auf denen die Ports 80 und 443 für Webdienste geöffnet
sind, und die Mailserver des Unternehmens mit dem offenen Port 25 für SMTP.
In der vorhandenen Netzwerkinfrastruktur stellen schon die Protokolle der Firewall eine
äußerst nützliche Datenquelle für Untersuchungen dar.
Aufgrund der Bedeutung der Web- und Mailserver bei dieser Art von Bedrohung ist unbedingt ein Sensor erforderlich, der den Netzwerkdatenverkehr an ihren Schnittstellen erfasst. Der DMZ-Sensor, den wir schon bei der vorherigen Bedrohung besprochen haben,
ist ideal platziert, um unsere Bedürfnisse auch für diesen Fall abzudecken.
Ein Einbruch in dieses System erfolgt wahrscheinlich über einen der von außen zugänglichen Dienste. Um solche Vorfälle angemessen erkennen und analysieren zu können,
müssen die anwendungsspezifischen Protokolle erfasst werden, also die Web-, Datenbank- und Mailserverprotokolle.
Die Sorge um einen Angriff auf Systemebene macht es nicht nur erforderlich, einen weiteren
Typ von Server zu berücksichtigen, sondern vergrößert auch erheblich die Angriffsfläche.
2.2 Fallstudie: Onlinehändler 79
Damit ausreichend Daten für die Erkennung und Analyse von Ereignissen in diesem Zusammenhang bereitstehen, müssen wir auch Betriebssystem- und Sicherheitsprotokolle, die
Protokolldaten von Antivirussoftware und die Alarmdaten von Host-IDS erfassen.
Am Ende unserer Planung steht daher folgende Liste von Datenquellen:
••
••
••
••
••
••
••
••
••
••
••
••
Protokolldaten der Edge-Firewall
DMZ-Sensor: Paketdaten
DMZ-Sensor: Sitzungsdaten
DMZ-Sensor: Paketstringdaten
DMZ-Sensor: Signaturgestütztes NDIS
DMZ-Sensor: Anomaliegestütztes NDIS
Anwendungsprotokolldaten des Webservers
Anwendungsprotokolldaten des Datenbankservers
Anwendungsprotokolldaten des Mailservers
Betriebssystem- und Sicherheitsprotokolldaten des Web- und des Mailservers
Antivirus-Alarmdaten des Web- und des Mailservers
HIDS-Alarmdaten des Web- und des Mailservers
Unterbrechung des E-Commerce-Dienstes über ein internes Netzwerkelement
Die nächste Priorität hat ein Einbruch in einen internen Computer des Netzwerks, der
zur einer Unterbrechung des E-Commerce-Dienstes genutzt wird. Da das Endziel eines
solchen Angriffs nach wie vor die E-Commerce-Webserver sind, müssen wir deren Angriffsfläche nach wie vor berücksichtigen, was den Bedarf für einen DMZ-Sensor noch
verstärkt.
Die einzigen Computer, die vom internen Netzwerk aus Zugriff auf die DMZ haben, sind
die Server in VLAN 200 und die Entwicklercomputer in VLAN 103. Auch hier müssen
wir also einen Sensor im Kern des Netzwerks vorsehen, um Daten von diesen Geräten zu
erfassen.
Wenn ein Angreifer in einen Entwicklercomputer eindringt, kann er Zugriff auf die DMZ
erlangen. Das bedeutet, dass wir die entsprechenden System- und Sicherheitsprotokolle
sowie die HIDS- und Antivirus-Alarmdaten von dieser Arbeitsstation erfassen sollten. Des
Weiteren interessieren wir uns dafür, was über die Verbindung vom internen zum DMZNetzwerk übertragen wird, weshalb sich auch eine Erfassung der Firewallprotokolle des
Kernrouters lohnt.
Angreifer, denen es gelingt, in einen Computer im internen Netzwerk einzudringen, werden höchstwahrscheinlich versuchen, ihren Halt in dem Netzwerk zu verstärken, indem
sie die Active-Directory-Umgebung manipulieren. Daher ist es wichtig, auch die Protokolle des Domänencontrollers zu erfassen. Wenn der primäre Domänencontroller auch
80 2 Die Datenerfassung planen
die DNS-Dienste des Unternehmens ausführt, sind diese Protokolle auch äußerst nützlich,
um zu bestimmen, ob die Clients versuchen, möglicherweise gefährliche Hostnamen aufzunehmen. Das kann darauf hindeuten, dass ein Angreifer versucht, zusätzliche Werkzeuge
herunterzuladen oder eine Steuerfunktion im Netzwerk auszuüben.
Die Planung ergibt folgende Liste von Datenquellen:
Im Netzwerk
••
••
••
••
••
••
••
••
••
••
••
Protokolldaten der Edge-Firewall
Protokolldaten der Kernfirewall
DMZ-Sensor: Paketdaten
DMZ-Sensor: Sitzungsdaten
DMZ-Sensor: Signaturgestütztes NDIS
DMZ-Sensor: Anomaliegestütztes NDIS
Interner Sensor: Paketdaten
Interner Sensor: Sitzungsdaten
Interner Sensor: Paketstringdaten
Interner Sensor: Signaturgestütztes NDIS
Interner Sensor: Anomaliegestütztes NDIS
Auf dem Host
•• Anwendungsprotokolldaten des Web- und des Datenbankservers sowie des Domänencontrollers
•• Betriebssystem- und Sicherheitsprotokolldaten des Webservers und der VLANs 200
und 103
•• Antivirus-Alarmdaten des Webservers und der VLANs 200 und 103
•• HIDS-Alarmdaten des Webservers und der VLANs 200 und 103
Die Liste der Datenquellen für die genannten Bedrohungen kann nicht alle möglichen
Verteidigungssituationen abdecken, aber doch eine ziemliche Menge.
Nachdem wir nun festgestellt haben, welche Datenquellen für die NSM-Erkennung und
-Analyse nützlich sind, können wir das ursprüngliche Netzwerkdiagramm ändern. In der
neuen Version sind auch der DMZ- und der interne Sensor enthalten. Außerdem sind
die Bereiche markiert, die diese Sensoren abdecken (siehe Abb. 2.3). Im nächsten Kapitel
werden wir uns eingehender mit der Platzierung von Sensoren beschäftigen.
2.2 Fallstudie: Onlinehändler 81
Abbildung 2.3: Erweitertes Netzwerkdiagramm mit Platzierung der Sensoren
2.2.4 Die Erfassung eingrenzen
Der letzte Schritt des Vorgangs besteht darin, die genannten Datenquellen so zu verfeinern, dass nur noch die nützlichen Aspekte der Daten erfasst werden. Es gibt unbegrenzte
Möglichkeiten, das zu erreichen. Unser Beispielunternehmen ist aufgrund einer Kosten/
Nutzen-Analyse zu dem Schluss gekommen, dass es sinnvoll ist, die folgende Teilmenge
der Daten zu erfassen:
Im Netzwerk
•• Protokolldaten der Edge-Firewall
• Verweigerung ausgehender Verbindungen
•• Protokolldaten der Kernfirewall
• Verweigerung/Zulassung eingehender Verbindungen
• Verweigerung ausgehender Verbindungen
82 2 Die Datenerfassung planen
•• DMZ-Sensor: Paketdaten
• Eingehende Webports
• Eingehende Mailports
• Ausgehende Mailports
•• DMZ-Sensor: Sitzungsdaten
• Alle Einträge
•• DMZ-Sensor: Signaturgestütztes NDIS
• Regeln zu Angriffen auf die Webanwendung: SQL-Injektion, XSS usw.
• Regeln zu Angriffen auf die Webserver
• Regeln zu Angriffen auf die Mailserver
•• DMZ-Sensor: Anomaliegestütztes NDIS
• Regeln zu Anomalien in Web- und Mailinhalten
•• Interner Sensor: Paketdaten
• Pakete aus dem internen Netzwerk zu Webserver-IP-Adressen
• Pakete aus dem internen Netzwerk zu Entwicklercomputern in VLAN 103
• Externe Pakete zu den Servern in VLAN 200
•• Interner Sensor: Sitzungsdaten
• Alle Einträge
•• Interner Sensor: Paketstringdaten
• Pakete von Entwicklercomputern in VLAN 103 nach außen
•• Interner Sensor: Signaturgestütztes NDIS
• Regeln zu Angriffen auf die Datenbank
• Regeln zu Verwaltungstätigkeiten und Angriffen auf dem Domänencontroller
• Allgemeine Malwareregeln
•• Interner Sensor: Anomaliegestütztes NDIS
• Regeln zu Anomalien bei der Interaktion mit der Datenbank
Auf dem Host
•• Anwendungsprotokolldaten des Mail-, Web- und Datenbankservers sowie des Domänencontrollers
• Mailserver: Anlegen und Verändern von Konten
• Webserver: Transaktionen aus der Subdomäne für die Rechnungsverarbeitung
• Webserver: Transaktionen aus der Subdomäne für die Administration
• Datenbankserver: Anlegen und Verändern von Konten
• Datenbankserver: Transaktionen zur Abrechnung
• Datenbankserver: Administrative Transaktionen
• Domänencontroller: Anlegen und Verändern von Konten
• Domänencontroller: Anlegen und Verändern von Computern
2.3 Zusammenfassung 83
•• Betriebssystem- und Sicherheitsprotokolldaten des Mailservers, des Webservers und
der VLANs 200 und103
• Anlegen und Verändern von Konten
• Benachrichtigungen über installierte Software
• Benachrichtigungen über Systemaktualisierungen
• Benachrichtigungen über Neustarts des Systems
•• Antivirus-Alarmdaten des Mailservers, des Webservers und der VLANs 200 und 103
• Alle Alarmdaten
•• HIDS-Alarmdaten des Mailservers, des Webservers und der VLANs 200 und 103
• Alarme über Änderungen an kritischen Systemdateien
• Alarme über das Anlegen und Ändern von Konten
2.3
Zusammenfassung
In diesem Kapitel haben wir einige Prinzipien der Datenerfassung kennengelernt und uns
eine systematische Vorgehensweise angesehen, anhand der wir entscheiden können, welche Arten von Daten erfasst werden sollten. Die vorgestellte Fallstudie bot einen allgemeinen Überblick über die Schritte, die eine Organisation unternimmt, um ihre Bedürfnisse
für die Datenerfassung zu ermitteln. Die Umsetzung muss natürlich im jeweiligen konkreten Zusammenhang erfolgen. Der Rest dieses Buches hilft Ihnen bei den Entscheidungen,
die Sie bei der Festlegung Ihrer Anforderungen an die Datenerfassung treffen müssen.
3
Sensoren
Die wichtigste technische Komponente im NSM sind die Sensoren. Definitionsgemäß ist
ein Sensor ein Gerät, dass eine physikalische Größe erkennt oder misst und meldet, anzeigt oder auf andere Weise darauf reagiert. Im Rahmen von NSM ist ein Sensor eine
Kombination aus Hardware und Software, die zur Erfassung, Erkennung and Analyse verwendet wird. Im NSM-Zyklus kann ein Sensor die folgenden Aktionen ausführen:
•• Erfassung
• PCAP-Erfassung
• NetFlow-Erfassung
• Generieren von PSTR-Daten aus PCAP-Daten
• Durchsatzdiagramme aus NetFlow-Daten erstellen
•• Erkennung
• Signaturgestützte Erkennung
• Anomaliegestützte Erkennung
• Reputationsgestützte Erkennung
• Erkennung mithilfe von Honeypots
• Erkennen der Verwendung bekanntermaßen schädlicher PKI-Anmeldeinformationen mithilfe eines benutzerdefinierten Tools
• Erkennen von PDF-Dateien mit möglicherweise schädlichen Strings mithilfe eines
benutzerdefinierten Tools
86 3 Sensoren
•• Analyse
• Bereitstellen von Werkzeugen für Paketanalytiker
• Bereitstellen von Werkzeugen für die Untersuchung von Snort-Alarmen
• Bereitstellen von Werkzeugen für NetFlow-Analytiker
Nicht alle Sensoren erfüllen alle drei Aufgaben des NSM-Zyklus. Dennoch ist der Sensor
der Motor der NSM-Architektur, weshalb es von entscheidender Bedeutung ist, sich gründlich zu überlegen, wie die Sensoren bereitgestellt und gepflegt werden. Wir haben bereits
festgestellt, wie wichtig die Datenerfassung ist, und die Sensoren sind die Komponenten,
die diese Datenerfassung ermöglichen. Es bringt überhaupt nichts, viel Zeit auf die Identifizierung der Bedrohungen aufzuwenden, wenn Sie dann die Sensoren ohne systematisches
Vorgehen zusammenschustern.
Es gibt vier wichtige architektonische Aspekte bei der Überlegung, wie Sie die Sensoren
in Ihrem Netzwerk einsetzen wollen. Dabei handelt es sich um den Typ der Sensoren,
die physische Architektur der verwendeten Hardware, die verwendete Betriebssystemplattform und die Platzierung der Sensoren im Netzwerk. Auch die auf den Sensoren
installierten Tools, die die Erfassung, Erkennung und Analyse durchführen, sind von Bedeutung. Damit werden wir uns in nachfolgenden Kapiteln ausführlicher beschäftigen.
3.1
NSM-Datentypen
Weiter hinten in diesem Buch folgen Kapitel, die sich ausschließlich den einzelnen NSMDatentypen widmen. Als Grundlage für unsere Architektur der Sensorarchitektur ist es
jedoch notwendig, zunächst einmal einen knappen Überblick über die wichtigsten NSMDatentypen zu geben, die zur Erkennung und Analyse erfasst werden können.
3.1.1
Paketdaten (FPC)
Mit FPC (Full Packet Capture, »vollständige Paketerfassung«) ist die komplette Erfassung
sämtlicher Datenpakete gemeint, die zwischen zwei Endpunkten übertragen werden. Das
häufigste FPC-Datenformat ist PCAP. FPC-Daten können aufgrund ihrer schieren Menge
zwar überwältigend wirken, doch aufgrund ihres großen Detailreichtums sind sie äußerst
wertvoll, um Kontext für die Analyse zu liefern. Andere Datentypen, etwa statistische oder
Paketstringdaten, werden oft von FPC-Daten abgeleitet.
3.1.2 Sitzungsdaten
Sitzungsdaten stellen die Gesamtheit der Kommunikation zwischen zwei Netzwerkgeräten dar. Sie werden auch als Konversation oder Fluss bezeichnet und gehören zu den flexibelsten und nützlichsten Formen von NSM-Daten. Zwar bieten sie nicht so viele Details
3.1 NSM-Datentypen 87
wie FPC-Daten, doch ihr geringer Umfang ermöglicht es, sie länger aufzubewahren, was
für Analysen im Rückblick eine sehr wertvolle Eigenschaft ist.
3.1.3 Statistische Daten
Statistische Daten gehen aus der Ordnung, Analyse, Deutung und Präsentation anderer
Arten von Daten hervor. Das kann viele unterschiedliche Formen annehmen, etwa statistische Werte über Ausreißer von der Standardabweichung oder Datenpunkte, die positive
oder negative zeitliche Beziehungen zwischen zwei Größen angeben.
3.1.4 Paketstringdaten (PSTR)
PSTR- werden aus FPC-Daten abgeleitet und bilden eine Form von Daten, die zwischen
FPC- und Sitzungsdaten angesiedelt sind. Dieses Datenformat besteht aus den Klartextstrings von ausgewählten Protokollheadern (z. B. HTTP-Headerdaten). Der Detailreichtum dieser Daten ist eher mit dem von FPC- als von Sitzungsdaten zu vergleichen,
wobei der geringere Umfang diesen Typ jedoch leichter handhabbar macht und eine längere Aufbewahrung ermöglicht.
3.1.5 Protokolldaten
Hierbei handelt es sich um die rohen Protokolldateien, die von Geräten, Systemen und
Anwendungen erzeugt werden. Das kann die Webbproxy-, von Routerfirewall-, VPNAuthentifizierungs- und Windows-Sicherheitsprotokolle sowie SYSLOG-Daten einschließen. Umfang und Nützlichkeit dieser Daten schwanken je nach Quelle.
3.1.6 Alarmdaten
Wenn ein Erkennungswerkzeug eine Anomalie in den Daten feststellt, die es untersuchen
soll, erstellt es eine Benachrichtigung. Solche Benachrichtigungen werden als Alarmdaten
bezeichnet. Gewöhnlich enthalten sie eine Beschreibung des Alarms und einen Zeiger auf
die Daten, die anomal erscheinen. Alarmdaten haben gewöhnlich einen sehr geringen Umfang und enthalten lediglich Zeiger auf andere Daten. Die Analyse von NSM-Ereignissen
basiert gewöhnlich auf der Generierung von Alarmdaten.
Es ist sinnvoll, sich eine Vorstellung von der relativen Größe dieser Datentypen zueinander machen zu können. Den größten Umfang haben FPC-Daten, gefolgt von PSTR- und
Sitzungsdaten. Protokoll-, Alarm- und statistische Daten sind im Vergleich zu den anderen Typen gewöhnlich sehr klein, ihr Umfang fällt aber je nach Art der erfassten Daten
und der Quellen sehr unterschiedlich aus.
88 3 Sensoren
FPC
PSTR
Sitzung
Alarm-,
Protokollund
statistische
Daten
(variabel)
Abbildung 3.1: Größenvergleich von NSM-Datentypen
Eine Quantifizierung der Größenunterschiede ist oft hilfreich, insbesondere bei der Ermittlung des Speicherplatzbedarfs für die Sensoren. Je nach Netzwerkumgebung kann es
dabei dramatische Unterschiede geben. In einem Netzwerk mit sehr vielen Benutzercomputern kann es beispielsweise viel mehr PSTR-Daten geben als in einem Netzwerksegment, das hauptsächlich von Servern eingenommen wird. Angesichts dessen haben wir
Daten aus verschiedenen Arten von Netzwerken herangezogen, um einige grundlegende
Statistiken über den Umfang der einzelnen Datentypen in einem gegebenen Zeitraum
aufzustellen. Protokoll-, Alarm- und statistische Daten sind in der Tabelle nicht enthalten.
Tabelle 3.1: Größenvergleich von NSM-Datentypen
FPC
PSTR
Sitzung
Multiplikator
100 %
4%
0,01 %
Datenumfang (MB)
1024
40.96
0,1024
Achtung
Die Zahlen in Tabelle 3.1 bieten zwar einen Anhaltspunkt für die relativen Datengrößen in den Beispielen dieses Kapitels, doch in der Praxis hängt die Beziehung
zwischen PSTR-, Sitzungs- und FPC-Daten sehr stark davon ab, welche Arten von
Netzwerkdaten Sie erfassen. Daher müssen Sie Stichproben des Netzwerkverkehrs
heranziehen, um die genauen Verhältnisse in Ihrer Umgebung zu bestimmen.
3.2 Sensortypen 89
3.2
Sensortypen
Je nach der Größe eines Netzwerks und den Bedrohungen, denen es ausgesetzt ist, können
die Sensoren unterschiedliche Rollen im NSM-Zyklus einnehmen.
3.2.1 Nur Erfassung
Ein reiner Erfassungssensor zeichnet lediglich erfasste Daten wie FPC- oder Sitzungsdaten
auf der Festplatte auf. Manchmal generiert er aufgrund der erfassten Werte auch noch
andere Daten (z. B. statistische und PSTR-Daten). Sensoren dieser Art werden in großen
Organisationen eingesetzt, in denen die Erkennungswerkzeuge über das Netzwerk auf die
erfassten Daten zugreifen, um sie zu verarbeiten. Auch die Analyse erfolgt unabhängig
vom Sensor, wobei die relevanten Daten nach Bedarf von anderen Geräten abgerufen werden. Ein reiner Erfassungssensor ist ein sehr grundlegendes Gerät ohne zusätzliche Software. Die Analytiker sind nur selten in der Lage, direkt darauf zuzugreifen.
3.2.2 Halbzyklus
Ein Halbzyklussensor führt alle Funktionen eines reinen Erfassungssensors und zusätzlich
auch Erkennungsaufgaben durch. Beispielsweise zeichnet er nicht nur PCAP-Daten auf
der Festplatte auf, sondern führt auch ein NIDS (z. B. Snort) aus, entweder in Echtzeit an
der Netzwerkkarte oder nahezu in Echtzeit an den PCAP-Daten auf der Festplatte. Die
Analyse dagegen erfolgt nicht auf dem Sensor selbst. Um sie durchzuführen, werden die
Daten von einem anderen Gerät abgerufen. Das ist die am weitesten verbreitete Art von
Sensor. Bei Bedarf greifen die Analytiker direkt auf den Sensor zu, um mit den verschiedenen Erkennungswerkzeugen zu arbeiten.
3.2.3 Vollzyklus
Bei diesem letzten Typ erfolgen Erfassung, Erkennung und Analyse auf dem Sensor. Daher
muss neben den Erfassungs- und Erkennungswerkzeugen auch eine komplette Analysesuite darauf installiert sein. Das kann auch Profile für verschiedene Analytiker, eine grafische
Benutzeroberfläche oder die Installation einer NIDS-GUI wie Snorby einschließen. Wird
ein Vollzyklussensor eingesetzt, so werden fast alle NSM-Aufgaben dort ausgeführt. Dieser
Typ wird hauptsächlich in kleinen Organisationen verwendet, in denen nur ein einziger
Sensor bereitgestellt wird oder in denen nur eingeschränkte Hardwareressourcen zur Verfügung stehen.
In den meisten Fällen ist ein Halbzyklussensor die beste Wahl. Das liegt hauptsächlich
daran, dass es viel einfacher ist, die Erkennungswerkzeuge auf dem System zu installieren,
auf dem die Daten auch erfasst werden. Es ist auch viel sicherer, wenn die Analytiker für
ihre Untersuchungen Kopien der Daten auf ihre dedizierten Analysecomputer übertragen,
anstatt mit den Rohdaten selbst zu arbeiten, denn ansonsten besteht die Gefahr, dass bei
90 3 Sensoren
einer falschen Behandlung der Daten wichtige Informationen verloren gehen. Analytiker
müssen zwar mit den Sensoren arbeiten, aber sie sollten sie nicht als Desktop-Analyse­
umgebung nutzen, es sei denn, es gibt keine andere Möglichkeit. Die Sensoren sind ein
sehr wertvolles Element des Netzwerks und müssen dementsprechend geschützt werden.
Abbildung 3.2: Arten von Sensoren
3.3
Sensorhardware
Nach Abschluss der Planung ist es an der Zeit, die Sensorhardware zu erwerben. Beachten
Sie dabei, dass es sich bei einem Sensor um einen Server handelt, weshalb Sie für diesen
Zweck Serverhardware bereitstellen sollten. Ich habe nur zu oft erlebt, dass Sensoren aus
Ersatzteilen zusammengeschustert waren. Einmal habe ich sogar eine Arbeitsstation gesehen, die quer in ein Regal gelegt worden war und als Sensor diente! Solche Geräte mögen
für eine Laborumgebung oder zum Testen geeignet sein, aber für ernsthaftes Network
Security Monitoring müssen Sie in zuverlässigere Hardware investieren.
3.3 Sensorhardware 91
Um zu bestimmen, wie viel Hardware Sie brauchen, müssen Sie berücksichtigen, welche
Art von Sensor Sie bereitstellen wollen, wie viele Daten er erfassen soll und wie lange diese
Daten aufbewahrt werden müssen.
Im Folgenden sehen wir uns die wichtigen Komponenten der Sensorhardware einzeln an.
Um die Hardwareanforderungen zu bestimmen, ist es oft jedoch hilfreich, zunächst einmal einen vorläufigen Sensor einzurichten. Dabei kann es sich um einen anderen Server,
aber auch um eine Arbeitsstation oder sogar einen Laptop handeln.
Bevor Sie den vorläufigen Sensor installieren, müssen Sie sich über seine physische und
logische Platzierung im Netzwerk im Klaren sein. Diese Platzierung bestimmt, welche
Netzwerkverbindungen der Sensor überwacht. Darauf werden wir weiter hinten in diesem
Kapitel noch ausführlicher eingehen.
Leiten Sie dem vorläufigen Sensor über einen SPAN-Port oder einen Netzwerk-Tap Datenverkehr zu. Installieren Sie die Erfassungs-, Erkennungs- und Analysetools auf ihm,
um die Leistungsanforderungen der einzelnen Programme zu bestimmen. Dabei muss
der vorläufige Sensor nicht leistungsfähig genug sein, um all diese Werkzeuge gleichzeitig
auszuführen. Aktivieren Sie immer nur eines auf einmal, um ihre Leistungsansprüche zu
berechnen. Zählen Sie dann die Werte von allen Tools zusammen, um den Gesamtbedarf
zu ermitteln.
3.3.1 CPU
Welche CPU-Ressourcen Sie brauchen, hängt größtenteils davon ab, was für eine Art von
Sensor Sie bereitstellen. Ein reiner Erfassungssensor braucht sehr hohe Prozessorleistung,
da diese Aufgabe nicht sehr verarbeitungsintensiv ist. Am stärksten wird der Prozessor
bei der Erkennung in Anspruch genommen, weshalb Sie bei einem Halb- oder Vollzyklussensor zusätzliche Prozessoren oder Kerne vorsehen müssen. Wenn Sie ein erhebliches
Wachstum erwarten, kann ein Bladesystem die richtige Wahl sein, da Sie dort einfach
weitere Einschübe hinzufügen können, um die CPU-Ressourcen zu steigern.
Eine einfache Möglichkeit zur Planung der Sensorbereitstellung besteht darin, die Anzahl
der Kerne für die einzelnen Tools zu bestimmen. Je nach der Bandbreite, die insgesamt
überwacht werden muss, der Art des Datenverkehrs, der Regelsätze für signaturgestützte
Erkennungsmechanismen wie Snort und Suricata und der Richtlinien für Werkzeuge wie
Bro können die konkreten Anforderungen sehr stark schwanken. Einige Aspekte zur Leistungsbestimmung sowie Referenzwerte werden wir in den Abschnitten zu den einzelnen
Werkzeugen besprechen.
Nachdem Sie Ihren Testsensor bereitgestellt haben, können Sie seine CPU-Nutzung mit
SNMP oder einem Unix-Programm wie top (siehe Abb. 3.3) oder htop untersuchen.
92 3 Sensoren
Abbildung 3.3: Überwachen der CPU-Nutzung auf dem Sensor mit top
3.3.2 Arbeitsspeicher
Für Erfassung und Erkennung ist im Allgemeinen weniger Arbeitsspeicher erforderlich als
für die Analyse. Das liegt daran, dass oft verschiedene Analytiker mehrere Instanzen derselben Programme nacheinander ausführen. Ein Sensor sollte schon an sich über reichlich
Arbeitsspeicher verfügen, aber bei einem Vollzyklussensor müssen Sie diese Menge noch
3.3 Sensorhardware 93
drastisch erhöhen. Da sich der Speicherbedarf nur schwer planen lässt, ist es am besten,
Hardware mit zusätzlichen Steckplätzen für Arbeitsspeicher zu kaufen, um für künftiges
Wachstum gewappnet zu sein.
Wie bei der Bestimmung der CPU-Ressourcen können Sie auch hier Programme wie top
oder htop einsetzen, um genau zu ermitteln, wie viel Arbeitsspeicher die einzelnen Tools
nutzen (siehe Abb. 3.4). Das muss natürlich geschehen, während der Sensor Datenverkehr
mit einem Durchsatz sieht, der mit der Produktionslast vergleichbar ist.
Abbildung 3.4: Überwachen der Speichernutzung auf dem Sensor mit htop
Arbeitsspeicher ist relativ billig, was von einigen modernen Netzwerküberwachungsprogrammen weidlich ausgenutzt wird. Stellen Sie für die Tools große Mengen an Arbeitsspeicher zur Verfügung, um auch bei hohen Datenlasten eine gute Leistung zu erzielen.
3.3.3 Festplattenplatz
Einer der Bereiche, dessen Planung vielen Organisationen die größten Schwierigkeiten bereitet, ist der Speicherplatz auf der Festplatte. Das liegt hauptsächlich daran, dass so viele
Faktoren ins Spiel kommen. Bei der Planung des Platzbedarfs müssen Sie die Platzierung
des Sensors und die Art des Datenverkehrs und der generierten Daten berücksichtigen.
94 3 Sensoren
Außerdem müssen Sie den künftigen Bedarf durch Wachstum des Netzwerks einkalkulieren. Angesichts all dieser zu beachtenden Aspekte ist es nicht überraschend, dass der
erforderliche Festplattenplatz nach der Installation eines Sensors oft einer Überprüfung
unterzogen werden muss.
Die folgenden Schritte können Ihnen helfen, die Platzanforderungen für einen Sensor zu
bestimmen. Sie müssen sie für jeden Sensor ausführen, den Sie bereitstellen wollen.
Schritt 1: Den erfassten Datenverkehr berechnen
Um mit der Berechnung des Festplattenplatzes zu beginnen, bestimmen Sie die Menge
der NSM-Daten, die der vorläufige Server in bestimmten Zeiträumen erfasst. Ich versuche dabei, in mehreren Intervallen von jeweils mindestens 24 Stunden Daten zu erfassen,
und zwar sowohl an Arbeitstagen als auch am Wochenende. Dadurch erhalten Sie eine
gute Darstellung des Datenflusses sowohl zu Spitzen- als auch zu ruhigen Zeiten. Wenn
Sie mehrere Datenreihen aufgenommen haben, können Sie daraus die durchschnittliche
Datenmenge pro Stunde berechnen.
Nehmen wir an, unser Sensor generiert in einem 24-Stunden-Intervall unter der Woche
(Spitzenzeit) 300 GB PCAP-Daten und am Wochenende (ruhige Zeit) 25 GB. Um den
Tagesdurchschnitt zu berechnen, multiplizieren wir die Datenmenge eines Arbeitstags mit
der Anzahl der Arbeitstage (300 GB x 5 = 1500 GB) und die Datenmenge eines Tages am
Wochenende mit der Anzahl der Tage eines Wochenendes (25 GB x 2 = 50 GB). Anschließend addieren wir die beiden Ergebnisse (1500 GB + 50 GB = 1550 GB) und bilden den
Durchschnitt, indem wir die Summe durch die Anzahl der Wochentage teilen (1550 GB /
7 = 221,43 GB). Wenn wir das noch durch die Anzahl der Stunden eines Tages dividieren,
erhalten wir die durchschnittliche Menge an PCAP-Daten pro Stunde (221,43 GB / 24 =
9,23 GB).
Die Ergebnisse dieser Berechnungen für mehrere Datenformate können Sie anschließend
wie in Tabelle 3.2 darstellen
Tabelle 3.2: Vom Sensor erfasste Datenmengen
Tagesmenge
(Arbeitstag)
Tagesmenge
(Wochenende)
Tagesdurchschnitt
Stundendurchschnitt
PCAP
300 GB
25 GB
221,43 GB
9,23 GB
Sitzung
30,72 MB
2,56 MB
16,64 MB
0,69 MB
PSTR
12 GB
102,4 MB
6,05 GB
258,1 MB
9,48 GB
3.3 Sensorhardware 95
Schritt 2: Eine sinnvolle Aufbewahrungszeit für die einzelnen Daten­
typen bestimmen
Jede Organisation muss einen Mindest- und einen Optimalwert für die Aufbewahrungszeit von NSM-Daten festlegen. Der Mindestwert stellt das Minimum dar, um NSMDienste auf akzeptablem Niveau durchführen zu können. Der Optimalwert gibt ein sinnvolles Ziel für eine bestmögliche Netzwerksicherheitsüberwachung vor. Welche Zahlen
Sie hier wählen, hängt davon ab, wie sensibel Ihr Geschäftsbetrieb ist und welches Budget
für die Sensorhardware zur Verfügung steht. Wenden Sie diese Werte anschließend auf
die zuvor bestimmten Datenmengen an, um zu sehen, wie viel Platz Sie benötigen. In
Tabelle 3.3 haben wir die Datenmengen aus Tabelle 3.2 mit den kürzestmöglichen und
den optimalen Aufbewahrungszeiten multipliziert.
Tabelle 3.3: Erforderlicher Speicherplatz für die minimale und optimale Aufbewahrungszeit
Tagesdurchschnitt
Minimum
Erforderlicher
Platz für
Minimum
Optimum
Erforderlicher
Platz für
Optimum
PCAP
221,43 GB
1 Tag
221,43 GB
3 Tage
664,29 GB
Sitzung
16,64 MB
90 Tage
1,46 GB
1 Jahr
5,93 GB
PSTR
6,05 GB
90 Tage
544,50 GB
1 Jahr
2,16 TB
2,21 GB
2,81 TB
Schritt 3: Modifikatoren für den Sensortyp hinzufügen
In der Produktion sind das Betriebssystem des Sensors und die Tools meistens auf einer
logischen Festplatte untergebracht und die erfassten Daten auf einer anderen. Um den
Festplattenplatz zu berechnen, der insgesamt benötigt wird, müssen wir jedoch auch das
Betriebssystem und die Tools berücksichtigen. Bis jetzt haben wir nur Berechnungen für
reine Erfassungssensoren angestellt. Bei einem Halbzyklussensor müssen Sie jedoch noch
10 % auf die Anforderungen aufschlagen, um Platz für die Erkennungswerkzeuge und die
von ihnen generierten Alarmdaten zu haben. Bei einem Vollzyklussensor ist sogar eine
Aufstockung um 25 % für die Erkennungs- und Analysewerkzeuge und deren Daten erforderlich. Anschließend fügen Sie noch weitere 10 bis 25 % für die jeweiligen Anforderungen des Betriebssystems sowie Zuschläge für das erwartete Wachstum des Netzwerks
hinzu. Denken Sie immer daran, dass es sich bei diesen Zahlen nur um generelle Richtwerte handelt, die je nach den Zielen der Organisationen und der Natur des vorliegenden
Netzwerks stark schwanken können. In Tabelle 3.4 haben wir solche Modifikatoren auf
unsere Beispieldaten angewendet.
96 3 Sensoren
In Tabelle 3.4 habe ich es zwar nicht getan, aber ich empfehle Ihnen, bei diesen Berechnungen stets aufzurunden, um sich selbst genügend Manövrierraum zu verschaffen. Es ist
einfacher, vor der Bereitstellung eines Sensors mehr Festplattenplatz zu planen, als ihn im
Nachhinein aufzustocken.
Berücksichtigen Sie bei der Planung auch immer die verschiedenen Techniken zur Minimierung des Platzanspruchs. Die beiden häufigsten Vorgehensweisen bestehen darin, die
Aufbewahrungszeit für einzelne Datentypen zu ändern bzw. Daten in Verbindung mit
bestimmten Hosts oder Protokollen von der Erfassung auszuschließen. Beispielsweise
kann Ihre Organisation entscheiden, dass FPC-Daten nur zwölf Stunden lang aufbewahrt
werden müssen, da schließlich die PSTR-Daten drei Monate lang erhalten bleiben. Bei der
zweiten Vorgehensweise können Sie beispielsweise die Erfassung von FPC-Daten so einrichten, dass bestimmte umfangreiche Arten des Datenverkehrs, etwa nächtliche Backuproutinen oder verschlüsselter SSL/TLS-Datenverkehr, ignoriert werden. Beide Techniken
haben ihre Vor- und Nachteile und sind die Konsequenz daraus, dass wir unsere Entscheidungen nun einmal nicht in einer idealen Welt treffen, sondern mit begrenzten Ressourcen arbeiten müssen. Um den Datenverkehr zu den Sensorprozessen zu filtern, können Sie
für den Anfang ein Werkzeug wie BPF (Berkeley Packet Filter) verwenden. Mehr darüber
erfahren Sie in Kapitel 13.
Tabelle 3.4: Fertige Abschätzung des erforderlichen Festplattenplatzes
Minimum
Ideal
PCAP
221,43 GB
664,29 GB
Sitzung
1,46 GB
5,93 GB
PSTR
544,50 GB
2,16 TB
Zwischensumme
2,21 GB
2,81 TB
+ 10 % für Halbzyklussensor
226,3 MB
287,74 GB
+ 15 % für erwartetes Wachstum
339,46 MB
431,62 GB
Gesamt
2,76 GB
3,51 TB
3.3.4 Netzwerkschnittstellen
Die Netzwerkkarte ist wahrscheinlich die wichtigste Hardwarekomponente im Sensor, da
sie für die Erfassung der Daten zuständig ist, die in den drei Phasen des NSM-Zyklus genutzt werden.
Ein Sensor braucht immer mindestens zwei Netzwerkkarten. Eine dient dazu, für die Administration oder die Analyse auf den Server zuzugreifen, die andere ist für die Datenerfassung da. Bei der Administrationsschnittstelle kann es sich um ein Standardmodell handeln,
da sie nicht anders genutzt wird als eine typische Netzwerkkarte in einem Server. Wie sehr
die zweite Karte spezialisiert sein muss, hängt davon ab, wie viel Datenverkehr damit erfasst
3.3 Sensorhardware 97
werden soll. Mit handelsüblichen Qualitätskarten, z. B. von Intel oder Broadcom, und der
richtigen Konfiguration eines Netzwerksocketpuffers mit Lastenausgleich, z. B. PF_Ring,
lässt sich Datenverkehr bis zu 1 Gbit/s problemlos ohne Paketverlust erfassen.
Wie viele Netzwerkkarten erforderlich sind, hängt von der Bandbreite der über die Verbindung gesendeten Daten und der Art der verwendeten Taps ab. Denken Sie daran, dass
es in modernen Ethernetverbindungen zwei Kanäle gibt, nämlich einen Übertragungskanal (Transit, TX) und einen Empfangskanal (Receive, RX). Eine Standardnetzwerkkarte
mit 1 Gbit/s kann insgesamt 2 Gbit/s transportieren, nämlich 1 Gbit/s in jede Richtung.
Wenn die Netzwerkkarte weniger als 500 Mbit/s (in jeder Richtung) sieht, dann sind Sie
mit einer einzigen 1-Gbit/s-Karte für die Überwachung relativ sicher. »Relativ«, weil eine
solche Netzwerkkarte an einem Router oder Uplink mit 500 Mbit/s den Datenverkehr
puffern kann, sodass Spitzenwerte über dem Durchsatz des Uplinks auftreten können. Mit
erweiterten Taps können Sie solche Arten von Leistungsproblemen lindern. Im nächsten
Abschnitt erfahren Sie mehr über Netzwerk-Taps.
Um genau zu bestimmen, was für einen Durchsatz die Erfassungskarte haben muss, müssen Sie ermitteln, wie stark der zu erfassende Datenverkehr ist. Die einfachste Möglichkeit
dazu besteht darin, eine Sammelüberwachung auf dem Router oder Switch einzurichten.
Die wichtigsten Größen dabei sind:
•• Datenverkehr von Spitze zu Spitze (gemessen in Mbit/s)
•• Durchschnittliche Bandbreite (Durchsatz) pro Tag (gemessen in Mbit/s)
Nehmen wir an, Sie möchten eine Schnittstelle von 1 Gbit/s überwachen. Der durchschnittliche Durchsatz beträgt 225 Mbit/s, wobei durchschnittlich 100 Mbit/s gesendet
und 350 Mbit/s empfangen werden. Dabei können anhaltende Spitzen bis zu 450 Mbit/s
auftreten. Die Netzwerkkarte, die Sie verwenden, muss nicht nur mit dem durchschnittlichen Volumen umgehen können, sondern auch mit den Spitzen.
Achtung
Datenverkehr verläuft in zwei Richtungen! Eine 1-Gbit/s-Verbindung hat einen
maximalen Durchsatz von 2 Gbit/s, nämlich 1 Gbit/s TX und 1 Gbit/s RX.
Ein weiterer wichtiger Faktor für die Planung eines Sensors ist die Zusammensetzung
des Datenverkehrs an einem Link aus verschiedenen Netzwerkprotokollen. Sie kann von
der Tageszeit abhängen (z. B. durch nächtliche Backuproutinen), von der Zeit im Jahreslauf (z. B. durch recherchierende Studenten) und von vielen anderen Variablen. Um zu
ermitteln, welche Arten von Daten über eine Verbindung fließen, konfigurieren Sie den
SPAN-Port oder Netzwerk-Tap, den Sie für den Sensor vorgesehen haben, und schließen
Sie ihn an einen vorläufigen Sensor an, der über eine Netzwerkkarte mit hohem Durchsatz
verfügt. Zur Analyse können Sie NetFlow-Daten erfassen und untersuchen oder PCAPDaten erfassen und offline in Analysewerkzeugen wiedergeben.
98 3 Sensoren
Diese Messungen müssen über einen längeren Zeitraum durchgeführt werden, um Spitzenwerte und die zu erwartenden Arten des Datenverkehrs zu ermitteln. Das hilft Ihnen
zu entscheiden, ob Sie eine Netzwerkkarte mit 100 Mbit/s, 1 Gbit/s, 10 Gbit/s oder einem noch höheren Durchsatz benötigen. Selbst bei geringem Durchsatz ist es wichtig,
Hardware für den professionellen Einsatz zu kaufen, um Paketverluste zu vermeiden. Eine
1-Gbit/s-Netzwerkkarte für 30 € bei einem Elektronikdiscounter mag wie ein Schnäppchen erscheinen, aber wenn Sie versuchen, ein Schad-PDF aus einem Paketstream zu entnehmen und dabei feststellen müssen, dass Ihnen einige Segmente der Daten fehlen, dann
werden Sie sich wünschen, etwas mehr Geld ausgegeben zu haben, um ein Qualitätsprodukt zu erwerben.
Um Datenverkehr mit mehr als 1 Gbit/s zu erfassen oder um die Leistung der Sensorhardware zu optimieren, können Sie Hochleistungskarten verwenden. Die drei bekanntesten
Hersteller solcher Karten sind, vom teuersten zum billigsten geordnet, Napatech, Endace
und Myricom. Solche Karten bieten unterschiedliche Kombinationen von Hochleistungsfunktionen wie Kartenpuffer, Hardwarezeitstempel, erweiterte Treiber für Netzwerksockets, GBIC-Schnittstellenoptionen usw. Der Markt für Profi-Netzwerkkarten wandelt
sich rasch. Zurzeit empfehlen wir Produkte von Myricom, da sie in Kombination mit dem
proprietären Netzwerksocketpuffer derselben Firma einen erstaunlichen Wert und eine
hohe Leistung bieten.
Wenn Sie feststellen, dass sich Ihr Sensor dem Grenzwert von 10 Gbit/s nähert, sollten
Sie seine Platzierung ändern oder eine Lastenausgleichslösung einsetzen. Die Menge der
Daten, die in einem solchen Fall erfasst und auf die Festplatte geschrieben werden, kann
auch Probleme bei der Festplatten-E/A hervorrufen.
3.3.5 Lastenausgleich: Anforderungen für Socketpuffer
Wenn der Datenverkehr an der Netzwerkkarte angekommen ist, muss er sorgfältig auf
die verschiedenen Prozesse und Anwendungsthreads auf dem Sensor verteilt werden. Der
herkömmliche Netzwerksocketpuffer von Linux reicht für eine Hochleistungsanalyse des
Datenverkehrs jedoch nicht aus. Hier kommt PF_Ring von Luca Deri ins Spiel. Allgemein
besteht der Zweck von PF_Ring darin, die Leistung von Netzwerksockets durch verschiedene Techniken zu optimieren, etwa durch einen Zero-Copy-Ringpuffer. Dabei platziert
die Netzwerkkarte den Datenverkehr direkt im Benutzerraum, anstatt ihn in den Kernelraum zu kopieren, was dem Betriebssystem einen teuren Kontextwechsel erspart. Dies
macht die Datenerfassung schneller und wirtschaftlicher.
Zur Veranschaulichung können Sie sich vorstellen, dass PF_Ring den Netzwerkdatenverkehr zur Lieferung an verschiedene Tools auffächert. Dabei gibt es zwei mögliche Modi:
Die einzelnen Pakete können im Rundlaufverfahren zugeordnet werden, es ist aber auch
möglich, den gesamten Datenfluss an einen einzigen Prozess oder Thread innerhalb des
3.3 Sensorhardware 99
Sensors zu leiten. Bei der aktuellen Implementierung von PF_Ring können Sie einen
5-Tupel-Hash aus dem Quellhost, dem Zielhost, dem Quellport, dem Zielport und dem
Protokoll erstellen. Dieser Algorithmus sorgt dafür, dass alle Pakete für einen einzigen
TCP-Fluss alle UDP/ICMP-Pseudoflüsse von einem bestimmten Prozess oder Thread gehandhabt werden.
PF_Ring ist zwar nicht der einzige Puffer, den Sie zusammen mit den üblichen Erkennungswerkzeugen wie Bro, Snort und Suricata einsetzen können, aber er stellt die am
weitesten verbreitete Option dar und wird von allen drei Tools unterstützt.
Bei Hochleistungssensoren und für solche, die in Umgebungen mit mehr als 1 Gbit/s
eingesetzt werden, können Sie erhebliche Leistungssteigerungen durch Netzwerksockets
von Drittanbietern erzielen. Mit Unterstützung von Silicom bietet Ntop.org jetzt unter
dem Namen PF_Ring + DNA Hochleistungs-Netzwerksockets für handelsübliche IntelNetzwerkkarten an. Die Lizenzen müssen jeweils pro Port erworben werden. Angesichts
der beeindruckenden Ergebnisse bei Leistungstests ist PF_Ring + DNA eine Option, die
Sie sich genauer ansehen sollten. Der Myricom-Treiber für die eigenen Netzwerkkarten
von Myricom wird pro Karte lizenziert und scheint zurzeit den größten Wert für den Preis
zu bieten.
3.3.6 SPAN-Ports und Netzwerk-Taps im Vergleich
Die Geräte, mit denen Sie Pakete zum Sensor leiten, gehören zwar nicht zu dem physischen Sensorcomputer, werden aber als Bestandteil der Sensorarchitektur aufgefasst. Je
nachdem, wo Sie einen Sensor im Netzwerk unterbringen, müssen Sie dazu entweder einen SPAN-Port oder einen Netzwerk-Tap verwenden.
Die einfachste Möglichkeit bietet ein SPAN-Port, da er die vorhandene Hardware nutzt.
SPAN-Ports sind eine Funktion von Switches für den professionellen Einsatz in Unternehmen, die es ihnen ermöglicht, einen oder mehrere physische Switch-ports auf einen
anderen Port zu spiegeln. Dazu müssen Sie als Erstes die Ports ermitteln, deren Datenverkehr Sie zum Server leiten möchten. Dabei handelt es sich meistens um den Port, der den
Switch mit einem vorausgehenden Router verbindet, es können aber auch mehrere Ports
sein, an denen sich wichtige Netzwerkgeräte befinden. Je nach Modell des Switches können Sie über eine grafische Benutzeroberfläche oder eine Befehlszeile dafür sorgen, dass
der ein- und ausgehende Datenverkehr an diesem Port auf einen anderen Port an dem
Switch gespiegelt wird. Wenn Sie nun die Erfassungskarte des Sensors mit diesem zweiten
Port verbinden, sehen Sie den Datenverkehr des gespiegelten Quellports. Das können Sie
in Abb. 3.5 erkennen. Hier ist der Sensor so eingerichtet, dass er den gesamten Datenverkehr, der von einer Gruppe von Netzwerkgeräten zu einem Router verläuft, überwacht.
Dazu wird der Port, an dem der Router angeschlossen ist, auf den Sensor gespiegelt.
100 3 Sensoren
24-Port-Switch
Port 1
Port 2–23
Router
Netzwerkgeräte
Angeschlossen an Port 24
Gespiegelter Datenverkehr von Port 1
Sensor
Abbildung 3.5: Paketerfassung mithilfe eines SPAN-Ports
Weitere Informationen
Die Portspiegelung ist eine übliche Funktion von Switches für den professionellen Einsatz in Unternehmen. Auf Switches für den Hausgebrauch ist sie jedoch
nur selten zu finden. Miarec unterhält auf http://www.miarec.com/knowledge/
switches-port-mirroring eine großartige Liste von einfacheren Switches, die über
diese Funktion verfügen.
Die meisten Switches erlauben eine n:1-Konfiguration, was bedeutet, dass Sie mehrere
Ports auf einen Port spiegeln können. Dabei müssen Sie jedoch die physischen Grenzen des Switches berücksichtigen. Wenn der Switch beispielsweise über 100-Mbit/s-Ports
verfügt und Sie 15 davon auf den Erfassungsport spiegeln, wird Letzterer mit Datenverkehr überlastet, sodass Pakete verloren gehen. Liegt an einem Port für längere Zeit die
Maximallast an, gehen manche Switches davon aus, dass ein Denial-of-Service-Angriff
oder ein Broadcaststorm vorliegt, und schalten den betreffenden Port ab. Das ist natürlich das Schlimmste, was Ihnen passieren kann, denn dann erhalten die an diesen Port
angeschlossenen Erkennungsprozesse keine Daten mehr.
Eine andere Möglichkeit, Pakete zu Ihrem Sensor zu leiten, besteht darin, einen NetzwerkTap zu verwenden. Dabei handelt es sich um ein passives Hardwaregerät, das zwischen
zwei Endpunkten sitzt und deren Datenverkehr an einen weiteren Port spiegelt. Stellen Sie
sich beispielsweise einen Router und einen Switch vor, die über ein einziges Kabel verbunden sind. Wenn Sie einen Tap zwischenschalten, brauchen Sie noch mehr Kabel, nämlich
eines vom Switch zum Tap und ein weiteres vom Tap zum Router. Dadurch kann der
Datenverkehr weiterhin zwischen Router und Switch übertragen werden (siehe Abb. 3.6).
3.3 Sensorhardware 101
Tap
Switch
Router
Sensor
Abbildung 3.6: Verwendung eines Netzwerk-Taps zur Erfassung von Paketen
Um den von dem Tap abgefangenen Datenverkehr zu überwachen, müssen Sie den Tap
mit dem Sensor verbinden. Wie das geschieht, hängt vom Typ des Taps ab. Am häufigsten
sind aggregierende Taps, die Sie über ein einziges Kabel mit der Erfassungskarte auf dem
Sensor verbinden. Darüber können Sie den Datenverkehr zwischen Router und Switch in
beiden Richtungen überwachen. Ein nicht aggregierender Tap dagegen hat zwei Überwachungsanschlüsse, nämlich jeweils einen für die beiden Richtungen des Datenflusses. Bei
solchen Taps müssen Sie die beiden Überwachungsports an unterschiedliche Netzwerkkarten auf dem Sensor anschließen. Abb. 3.7 zeigt beide Arten von Taps.
Aggregierender Tap
Nicht aggregierender Typ
Tap
Router
Bidirektionaler Datenverkehr
Netzwerkkarte 1
Tap
Switch
Router
Eingehender
Datenverkehr
Netzwerkkarte 1
Sensor
Ausgehender
Datenverkehr
Switch
Netzwerkkarte 2
Sensor
Abbildung 3.7: Aggregierende und nicht aggregierende Taps
Für Hochleistungsanwendungen bilden Taps gewöhnlich die bevorzugte Lösung. Es gibt
sie in allen Formen und Größen und für sehr hohe Leistungsansprüche. Bei Taps bekommen Sie die Qualität, für die Sie bezahlen. Seien Sie daher nicht knauserig, wenn Sie einen
Tap für die Überwachung einer kritischen Verbindung auswählen.
102 3 Sensoren
Schnittstellen binden
Bei der Verwendung eines nicht aggregierenden Taps brauchen Sie auf dem Sensor mindestens zwei Netzwerkschnittstellen für die Erfassung, die eine für den eingehenden und
die andere für den ausgehenden Datenverkehr. Damit lassen sich die vorliegenden Aufgaben zwar erledigen, doch Erkennung und Analyse werden durch das Vorhandensein von
zwei getrennten Datenströmen erschwert. Es gibt mehrere Möglichkeiten, diese Datenströme zu vereinen, und zwar sowohl Hardware- als auch durch Softwarelösungen. Ich
bevorzuge eine Technik, die als Schnittstellenbindung bezeichnet wird. Dabei legen Sie
eine virtuelle Netzwerkschnittstelle an, die die Datenströme mehrerer Schnittstellen zu
einem einzigen kombiniert. Das erfolgt durch Software.
Als Beispiel wollen wir zwei Schnittstellen in Security Onion binden. Wie Sie an der Ausgabe von Abb. 3.8 sehen, hat der Computer, auf dem meine Installation von Security Onion läuft, drei Netzwerkschnittstellen, wobei eth2 die Verwaltungsschnittstelle ist und eth0
und eth1 zur Datenerfassung dienen.
Abbildung 3.8: Die Netzwerkschnittstellen eines Systems
Nehmen wir an, dass eth0 und eth1 an einen nicht aggregierenden Tap angeschlossen sind
und jeweils Datenverkehr in einer Richtung sehen. Ein Beispiel für die Datenströme, die
an den beiden Schnittstellen abgefangen werden, sehen Sie in Abb. 3.9. Darin können Sie
das Ergebnis einer ICMP-Echoanforderung und die Antwort auf einen Ping sehen. Im
oberen Fenster wird der Datenverkehr an 4.2.2.1 gezeigt, im unteren der Datenverkehr
von 4.2.2.1.
3.3 Sensorhardware 103
Abbildung 3.9: Unidirektionaler Datenverkehr an den beiden Schnittstellen
Diese beiden Schnittstellen wollen wir nun zu einer einzigen vereinigen, um die Analyse
zu vereinfachen. In Security Onion können Sie das mithilfe von bridge-utils tun, das
mittlerweile mit zu dem Betriebssystem gehört. Mit den folgenden Befehlen können Sie
eine temporäre Brücke einrichten:
sudo
sudo
sudo
sudo
sudo
ip addr flush dev eth0
ip addr flush dev eth1
brctl addbr br0
brctl addif br0 eth0 eth1
ip link set dev br0 up
Dadurch wird die Schnittstelle br0 angelegt. Wenn Sie den Datenverkehr an dieser Schnittstelle abrufen, werden Sie feststellen, dass darin die Daten von eth0 und eth1 zusammengefasst sind. Dadurch müssen Sie nur noch mit einer einzigen virtuellen Schnittstelle arbeiten, über die Sie beide Kommunikationsrichtungen abrufen können (siehe Abb. 3.10).
Wenn diese virtuelle Schnittstelle auch nach einem Neustart des Betriebssystems Bestand
haben soll, müssen Sie einige Änderungen an Security Onion vornehmen. Dazu gehört
es, den grafischen Netzwerkmanager auszuschalten und bridge-uitls in der Datei /etc/
network/interfaces zu konfigurieren. Mehr darüber erfahren Sie in folgenden Quellen:
•• http://code.google.com/p/security-onion/wiki/NetworkConfiguration
•• https://help.ubuntu.com/community/NetworkConnectionBridge
104 3 Sensoren
Abbildung 3.10: Bidirektionaler Datenverkehr an der virtuellen Schnittstelle
3.4
Das Betriebssystem des Sensors
Als Betriebssysteme für Sensoren werden meistens Varianten von Linux oder BSD verwendet. Die verschiedenen Distributionen haben alle ihre eigenen Vor- und Nachteile, und die
Wahl ist zum größten Teil Geschmackssache. Da im US-Verteidigungsministerium Red
Hat eingesetzt wird, bevorzugen Personen mit einem entsprechenden Hintergrund Distributionen auf der Grundlage von Red Hat, etwa CentOS oder Fedora. Viele NSM-Experten
alter Schule dagegen greifen aufgrund des minimalistischen Aufbaus lieber zu FreeBSD
oder OpenBSD. Es kommt nicht darauf an, irgendeine bestimmte Variante auszuwählen;
wichtig ist nur, dass es sich um ein Betriebssystem auf *nix-Basis handelt. Dafür gibt es
viele Gründe. Der offensichtlichste ist, dass die meisten Erfassungs-, Erkennungs- und
Analysewerkzeuge eigens für diese Plattformen geschrieben wurden. 2013 war Linux am
weitesten verbreitet, nachdem praktisch alle Hardwaresteller dazu übergingen, aktuelle
Linux-Treiber für ihre Produkte bereitzustellen.
3.5
Platzierung von Sensoren
Die wahrscheinlich wichtigste Entscheidung bei der Planung der NSM-Datenerfassung
betrifft die physische Platzierung der Sensoren im Netzwerk. Sie bestimmt, welche Daten
erfasst werden können, welche Erkennungsmöglichkeiten für diese Daten zur Verfügung
stehen und in welchem Umfang eine Analyse möglich ist. Bei der Platzierung müssen Sie
dafür sorgen, dass die Sensoren einen guten Einblick in die Datenquellen nehmen können, die Sie zuvor als wichtig für das Network Security Monitoring in Ihrer Organisation
erkannt haben (anhand des in Kapitel 2 besprochenen Applied Collection Frameworks).
3.5 Platzierung von Sensoren 105
Es gibt keine Standardmethode, um den besten Platz für einen Sensor im Netzwerk herauszufinden. Die folgenden Tipps und empfehlenswerten Vorgehensweisen können Ihnen
aber helfen, den üblichen Fallstricken zu entgehen.
3.5.1 Die richtigen Ressourcen nutzen
Ebenso wie Sicherheitsmaßnahmen im Allgemeinen darf auch die Platzierung der Sensoren nicht losgelöst vom Rest der Organisation erfolgen. Die Platzierung an sich ist zwar
Aufgabe des Sicherheitsteams, aber die Überlegung, wie das Gerät am besten in das Netzwerk integriert werden kann, fällt mehr in den Bereich der Netzwerktechnik, weshalb sich
die Mitglieder des Sicherheitsteams schon recht früh bei der Planung der Platzierung an
die Kollegen von der Netzwerktechnik wenden sollten. Schließlich kennt niemand das
Netzwerk besser als die Leute, die es entworfen haben und täglich warten. Sie können
dafür sorgen, dass die Ansprüche an die Platzierung realistisch und in der vorhandenen
Netzwerktopologie auch erfüllbar sind. Es kann natürlich sein, dass die Aufgaben des Sicherheitsteams und der Netzwerktechniker von einer einzigen Person wahrgenommen
werden – und diese Person können Sie selbst sein. Das macht es zumindest ziemlich einfach, einen Termin für eine Besprechung zu finden.
Den besten Einblick in die Gesamtstruktur des Netzwerks oder einzelner Segmente
bietet das Netzwerkdiagramm. Detaillierungsgrad und Gestaltung solcher Diagramme
können sehr unterschiedlich sein, aber für die Platzierung sind sie unverzichtbar, da
sie die Netzwerkarchitektur grafisch darstellen. Wenn es in Ihrer Organisation keine
Netzwerkdiagramme gibt, ist das eine gute Gelegenheit, sie anzulegen. Schließlich sind
sie nicht nur wichtig, um das Sichtfeld der Sensoren festzulegen, sondern helfen auch
dabei, Sichtfelddiagramme für die Analytiker aufzustellen. Mehr über diese Diagramme
erfahren Sie in einem der nachfolgenden Abschnitte.
3.5.2 Ein- und Austrittspunkte
Im Idealfall und bei Vorhandensein der entsprechenden Ressourcen sollte ein Sensor an
einem ausgeprägten Ein- oder Austrittspunkt in das oder aus dem Netzwerk platziert werden. Dies können Internet-Gateways, herkömmliche VPNs und Verbindungen zu Partnernetzwerken sein. In kleineren Netzwerken kann das bedeuten, den Sensor an einem
Rand des Netzwerks bereitzustellen. In vielen großen Organisationen wird eine Hub-andSpoke-Architektur verwendet, bei dem der Datenverkehr von Satellitenbüros über VPN,
MPLS oder direkte Verbindungen zur Durchsetzung der Netzwerküberwachungsrichtlinien in das Hauptbüro geleitet wird. Dabei ist eine breitere Verteilung der Sensoren auf die
einzelnen Eintritts- und Austrittspunkte erforderlich.
Das Diagramm in Abb. 3.11 zeigt eine Netzwerkarchitektur, wie Sie sie in großen Organisationen mit vielen Ein- und Austrittspunkten finden können. Beachten Sie, dass nicht
alle Router in diesem Diagramm eine Netzwerkadressübersetzung (Network Address
Translation, NAT) durchführen.
106 3 Sensoren
In diesem Beispiel werden vier Sensoren bereitgestellt:
••
••
••
••
Sensor A am Rand des Firmennetzwerks
Sensor B am Rand des Forschungsnetzwerks
Sensor C am Eintrittspunkt vom Netzwerk eines Partnerunternehmens
Sensor D am Rand des drahtlosen Netzwerks
Edge-Router
Inline-Tap
Internet
(primär)
Sensor A
Router des
Forschungsnetzwerks
Switch
Sensor D
Inline-Tap
Interner Router
Inline-Tap
Switch
Inline-Tap
Sensor C
Sensor B
Switch
Drahtloser Zugriffspunkt
Switch
Benutzercomputer
Drahtlos
angeschlossene
Benutzercomputer
Netzwerk
eines
Partnerunternehmens
Abbildung 3.11: Platzierung von Sensoren an Ein- und Austrittspunkten
Abgesehen vom Diebstahl physischer Datenträger werden bei jeglichen negativen Aktivitäten in Ihrem Netzwerk immer Daten in das Netzwerk oder aus ihm heraus übertragen.
Diese Daten können von Sensoren an den entsprechenden Ein- und Austrittspunkten erfasst werden.
3.5 Platzierung von Sensoren 107
3.5.3 Sichtbarkeit interner IP-Adressen
Für die Erkennung und Analyse ist es entscheidend, bestimmen zu können, um welches
interne Gerät es bei einem Alarm geht. Wenn ein Sensor auf der falschen Seite eines NATGeräts, z. B. eines Routers steht, kann diese wichtige Information von Ihnen ferngehalten
werden.
Das Diagramm in Abb. 3.12 zeigt zwei verschiedene Platzierungsvarianten. Das Netzwerk
ist ziemlich einfach gehalten: Das Unternehmensnetzwerk befindet sich hinter einem internen Router, der eine DMZ zwischen sich selbst und dem Edge-Router ausbildet. Der
Edge-Router schließlich ist mit dem Internet verbunden.
Die IP-Adressen der Geräte hinter dem internen Router stammen aus dem Bereich
172.16.16.0/24. Im internen LAN hat der Router die IP-Adresse 172.16.16.1, im externen WAN 192.168.1.254. Dadurch entsteht eine DMZ zwischen dem internen Router und
dem Edge-Router.
Variante A: Externe Platzierung
Tap
Internet
Externe
Schnittstelle
192.168.1.254
Edge-Router
Interne
Schnittstelle
172.16.16.1
Interner Router
Interne Hosts
172.16.16.0/24
Sensor
Variante B: Interne Platzierung
Externe
Schnittstelle
192.168.1.254
Internet
Edge-Router
Interne
Schnittstelle
172.16.16.1
Tap
Interner Router
Sensor
Interne Hosts
172.16.16.0/24
Abbildung 3.12: Zwei mögliche Platzierungen eines Sensors in einem einfachen Netzwerk
In Variante A steht der Sensor vor dem internen Router in der DMZ. Der Alarm aus Abb.
3.13 zeigt, was geschieht, wenn ein Computer in der Gruppe der internen Hosts einem
Drive-by-Download zum Opfer fällt und eine schädliche PDF-Datei mit einem Link zum
Exploitkit Phoenix herunterlädt.
108 3 Sensoren
Abbildung 3.13: Ein Alarm bei der Platzierungsvariante A
Dieser Alarm besagt, dass das Gerät mit der Adresse 192.168.1.254 versucht hat, eine PDFDatei vom Host 1.2.3.4 herunterzuladen und dass dieses PDF einen Link zum Exploitkit
Phoenix enthält. Das Problem ist, dass es sich bei 192.168.1.254 um die externe IP-Adresse
des internen Routers handelt, sodass wir nicht erkennen können, welcher der internen
Hosts die Kommunikation eingeleitet hat. Ein Abruf von NetFlow-Daten liefert die Ergebnisse aus Abb. 3.14.
Abbildung 3.14: NetFlow-Daten bei Variante A
Bei dieser Sensorplatzierung sehen wir keine interne IP-Adresse aus dem Bereich
172.16.16.0/24, da der interne Router die IP-Adressen der Hosts innerhalb dieses Netzwerks durch NAT maskiert. Die von diesem Sensor erfassten Daten geben uns keinerlei
Möglichkeit, den Alarm weiter zu untersuchen. Selbst wenn Sie noch andere Datenquellen
zur Verfügung hätten, etwa die Protokolle von Antivirus- oder HIDS-Software, wüssten
Sie nicht, wo Sie mit der Suche beginnen sollten. In Netzwerken mit Hunderten oder gar
Tausenden von Hosts in einem Segment kann dies besonders kompliziert werden.
3.5 Platzierung von Sensoren 109
In Variante B befindet sich der Sensor hinter dem Router. Dieselbe schädliche Aktivität
ruft wieder den gleichen Alarm hervor, doch wie Sie in Abb. 3.15 sehen, erhalten wir dabei
jetzt andere Informationen.
Abbildung 3.15: Ein Alarm bei der Platzierungsvariante B
Wie im vorigen Beispiel wird die externe Adresse der Website angezeigt, auf der sich die
Schaddatei befindet (1.2.3.4), aber statt der externen IP-Adresse des internen Routers
können wir diesmal die interne IP-Adresse des Hosts erkennen, der auf Spuren einer Infektion untersucht werden sollte. Die NetFlow-Daten in Abb. 3.16 zeigen die gleichen Informationen.
Abbildung 3.16: NetFlow-Daten bei Variante B
Die erfassten Daten müssen für eine Analyse brauchbar sein. Dieses Beispiel gilt nicht nur
für Sensoren in internen Netzwerksegmenten, sondern auch für Segmente, die nur einen
Hop vom Internet entfernt sind. Achten Sie immer darauf, dass Sie die Sensoren auf der
richtigen Seite von Routern unterbringen.
110 3 Sensoren
3.5.4 Nähe zu kritischen Elementen
In der Einleitung zu diesem Buch haben wir schon festgestellt, dass es zu Problemen führen kann, wenn Sie versuchen, ein möglichst großes Netz auszuwerfen, um so viele Daten
wie möglich zu gewinnen. Denken Sie bei der Platzierung der Sensoren daran. Wenn Sie
sich die Zeit genommen haben, die entscheidenden Datenquellen angesichts der Bedrohungen ihrer Organisation zu ermitteln, dann sollten Sie dabei auch festgestellt haben, für
welche Elemente ein Schutz besonders wichtig ist. Falls Sie nur eingeschränkte Ressourcen
zur Verfügung haben und es sich nicht leisten können, eine Erfassung und Erkennung an
sämtlichen Ein- und Austrittspunkten des Netzwerks vorzunehmen, können Sie die Sensoren logisch so nah wie möglich an den kritischen Elementen platzieren.
Abb. 3.17 zeigt ein mittelgroßes Netzwerk. Bei der Planung der Datenerfassung stellt das
Unternehmen fest, dass sich die Geräte, die besonders schützenswert sind, im Forschungsnetzwerk befinden, da sie das geistige Eigentum der Firma enthalten. In der Abbildung
sehen Sie drei mögliche Sensorplatzierungen.
Wenn wir unbegrenzt Geld, Zeit und Ressourcen zur Verfügung hätten, könnten wir alle
Sensoren bereitstellen, um uns einen bestmöglichen Einblick in das Netzwerk zu verschaffen. Das aber ist leider nicht immer realistisch.
Inline-Tap
Internet
Sensor A
Edge-Router
Grenzrouter NYC
Grenzrouter ATL
Switch
Sensor B1 Inline-Tap
Interner Router NYC
Switch
Inline-Tap
Switch
NYC
ATL
Benutzer
allgemein
Benutzer
allgemein
Switch
NYC
Sensor B2
Interner Router ATL
Inline-Tap
Sensor C
Switch
Netzwerkserver
ATL
Forschungsserver
Abbildung 3.17: Ein mittelgroßes Netzwerk mit drei möglichen Sensorplatzierungen
3.5 Platzierung von Sensoren 111
Unser erster Gedanke mag sein, einen Sensor am Rand des Netzwerks zu platzieren (Sensor A). Wenn dies der einzige Sensor ist, den wir haben, dann ist er für die Erfassung und
Erkennung im ganzen Unternehmen verantwortlich. Wie wir bereits gesehen haben, lässt
sich diese Vorgehensweise nicht gut an unterschiedliche Größen von Netzwerken anpassen. Letzten Endes führt sie zu extrem hohen Hardwarekosten und kann eine gründliche
Erfassung, Erkennung und Analyse unmöglich machen.
Als Nächstes könnten wir überlegen, Sensoren an den Grenzen der jeweiligen physischen
Standorte aufzustellen (B1 und B2). Die beiden Sensoren für die Standorte New York City
(NYC) und Atlanta (ATL) haben dann jeweils nur noch die Hälfte der Arbeitslast von
Server A zu tragen. Das bietet zwar einige Leistungsvorteile, allerdings müssen die beiden
Sensoren immer noch eine große Menge unterschiedlicher Daten verarbeiten. Der Sensor
in New York etwa braucht Erkennungssignaturen für Bedrohungen, die verschiedene Server im Serversegment, aber auch normale Benutzercomputer betreffen. Dadurch konzentrieren wir uns immer noch nicht auf die größte Bedrohung der Organisation.
Damit kommen wir zu Sensor C, der so aufgestellt ist, dass er Einblick in das Forschungsnetzwerk in Atlanta hat. Dieses Segment umfasst die Computer von Benutzern, die in
der Forschung arbeiten, und die Server, auf denen die Forschungsdaten gespeichert sind.
Nach der Risikoanalyse, die wir für dieses Netzwerk durchgeführt haben, ist die größte
Gefahr für die Organisation ein Einbruch in dieses Netzwerksegment. Daher sollte der
erste Sensor hier aufgestellt werden. Dieser Teil des Netzwerks ist kleiner, sodass hierfür
auch weniger leistungsfähige Hardware ausreicht. Außerdem brauchen die Erkennungsmechanismen nur Signaturen für die Technologien, die in diesem Netzwerk auch tatsächlich benutzt werden.
In einer Situation wie dieser wäre es natürlich am besten, wenn Ressourcen bereitstünden,
um mehr als einen Sensor aufzustellen. Das möglicherweise beste Preis-Leistungs-­Verhältnis
bekommen Sie, wenn Sie Sensor A und C kombinieren. Der beste Ausgangspunkt ist in
unserem Fall allerdings das Forschungsnetzwerk, da sich hier die Elemente befinden, deren
Gefährdung die größte Bedrohung für das Unternehmen darstellt.
3.5.5 Sichtfelddiagramme der Sensoren aufstellen
Die Analytiker müssen wissen, wo sich ein Sensor in Bezug zu den Elementen, die er
schützen soll, sowie anderen vertrauenswürdigen und nicht vertrauenswürdigen Elementen befindet. Daher sind Netzwerkdiagramme äußerst wichtige Dokumente, die bei einer
Untersuchung zur Orientierung herangezogen werden können.
Die meisten Organisationen begnügen sich damit, in das vom Systemadministrator oder
von der Abteilung für Netzwerktechnik aufgestellte Netzwerkdiagramm einzuzeichnen,
wo sich der Sensor physisch oder logisch befindet. Das mag zwar durchaus einen gewissen
Nutzen haben, ist aber nicht die beste Möglichkeit, diese Informationen einem NSMAnalytiker zu präsentieren. Solche Diagramme sind nicht auf die Bedürfnisse der Analytiker zugeschnitten, sondern liefern oft viel zu viele irrelevante Informationen für deren
112 3 Sensoren
Zwecke und verschleiern die konkrete Architektur und deren Beziehung zu geschützten,
vertrauenswürdigen und nicht vertrauenswürdigen Elementen. Einem NSM-Analytiker
ein klassisches Netzwerkdiagramm in die Hand zu drücken ist vergleichbar damit, einem
Koch die DNS-Sequenz einer Tomate zu präsentieren. Wenn der Koch wissen will, wie das
Aroma einer Tomate zustande kommt, kann er diese Informationen darin finden, aber
normalerweise braucht er ein Rezept, das ihm sagt, was er mit der Tomate machen soll.
Bei der NSM-Analyse ist es zwar immer von Vorteil, ein ausführliches Netzwerkdiagramm
zur Verfügung zu haben, aber in den meisten Fällen ist ein vereinfachtes Diagramm besser
geeignet. Sensor-Sichtfelddiagramme sollen Analytikern die Möglichkeit geben, sich rasch
einen Überblick darüber zu verschaffen, welche Elemente ein Sensor schützt und welche
Elemente außen vor bleiben.
Ein grundlegendes Sichtfelddiagramm muss mindestens folgende Bestandteile enthalten:
•• Eine grobe logische Übersicht über das Netzwerk
•• Alle Routinggeräte, Proxys und Gateways, die Einfluss auf den Verlauf des Datenverkehrs nehmen
•• Die externen und internen IP-Adressen von Routinggeräten, Proxys und Gateways
•• Arbeitsstationen, Server und andere Geräte. Sofern es sich nicht um besonders kritische
Geräte handelt, sollten sie gruppenweise und nicht einzeln dargestellt werden.
•• IP-Adressbereiche für die Gruppen der Arbeitsstationen, Server und sonstigen Geräte
•• Sämtliche NSM-Sensoren sowie Markierungen (Kästen oder Flächen), die alle von
dem jeweiligen Sensor geschützten Hosts einschließen, also gewöhnlich die Hosts, von
denen der Sensor Daten erfasst. Bei Datenverkehr aus einem verschachtelten Teilnetzwerk wird zwar nur die IP-Adresse der externen Schnittstelle des zuständigen Routers
angezeigt, allerdings wird dieser Datenverkehr immer noch von dem Sensor erfasst
(sofern er nicht auf andere Weise ausgeschlossen wird).
Sehen wir uns dazu noch einmal das Beispielnetzwerk aus Abb. 3.17 an. In Abb. 3.18 sehen
Sie das gleiche Netzwerk, aber zusätzlich sind die Sichtfelder der einzelnen Sensoren und
die anderen oben genannten Details angegeben. Die verschiedenen Zonen lassen sich am
besten durch farbige Hinterlegungen kennzeichnen, aber da dieses Buch in Schwarzweiß
gedruckt wird, verwende ich Kästen mit unterschiedlichen Arten von Umrisslinien. Hier
überwacht jeder Sensor auch den Datenverkehr in den Teilnetzwerken, die in seinem eigenen Teilnetzwerk verschachtelt sind. Daher ist jede Zone auch wiederum in der Zone des
nächsthöheren Netzwerks enthalten.
3.6 Den Sensor absichern 113
Inline-Tap
192..0.2.180
192.168.1.1
Sensor A
Edge-Router
Internet
Grenzrouter NYC
192.168.1.2
Sensor B1
Grenzrouter ATL
Switch
192.168.1.3
192.168.2.1
192.168.3.1
Inline-Tap
Inline-Tap
Switch
Switch
NYC
ATL
Benutzer
allgemein
Benutzer
allgemein
192.168.3.2
192.168.2.2
Interner Router NYC
192.168.20.1
Switch
NYC
Sensor B2
Interner Router ATL
192.168.30.1
Inline-Tap
Sensor C
Switch
Netzwerkserver
ATL
Forschungsserver
Sensor A – 192.168.0.0/16
Sensor B1 – 192.168.2.0/24
Sensor B2 – 192.168.3.0/24
Sensor C – 192.168.30.0/24
Abbildung 3.18: Ein Sichtfelddiagramm
Ich lasse solche Diagramme gern laminieren und auf die Schreibtische der Analytiker
verteilen, sodass sie während einer Untersuchung schnell darin nachschlagen können.
Sie dienen jedoch nicht nur als Orientierungshilfe, sondern können einem Analytiker
auch Anhaltspunkte dafür bieten, welche zusätzliche Dokumentation sie für die Untersuchung noch finden oder anfordern müssen, z. B. ein ausführlicheres Diagramm eines
bestimmten Netzwerksegments oder Informationen über einen bestimmten vertrauenswürdigen Host.
3.6
Den Sensor absichern
Da es sich bei einem Sensor um ein sensibles Netzwerkgerät handelt, ist seine Sicherheit
von größter Bedeutung. Ein Sensor, auf dem vollständige Paketdaten oder auch nur Paketstringdaten gespeichert sind, enthält äußerst sensible Netzwerkinformationen. Selbst für
ungeübte Angreifer wäre es ein Leichtes, diese Informationen zu nutzen, um ganze Datei-
114 3 Sensoren
en, Passwörter oder andere kritische Daten zu entnehmen. Mithilfe eines Sensors, auf dem
Sitzungsdaten gespeichert sind, können Angreifer sogar Informationen gewinnen, die es
ihnen erleichtern, ihren Einfluss in dem Netzwerk weiter auszudehnen. Um die Sicherheit
der Sensoren zu gewährleisten, können Sie verschiedene Maßnahmen ergreifen.
3.6.1 Betriebssystem- und Softwareaktualisierungen
Bei jedem System besteht die wichtigste Sicherheitsmaßnahme darin, dafür zu sorgen,
dass die darauf laufende Software und das Betriebssystem stets auf dem neuesten Stand
sind und über die neuesten Sicherheitspatches verfügen. Sensoren sollten zwar nicht vom
Internet aus zugänglich sein, aber wenn jemand auf anderem Weg Zugang zu Ihrem Netzwerk erlangt und über eine seit Monaten nicht gepatchte Schwachstelle, die die Ausführung von Remotecode zulässt, in den Sensor eindringt, haben Sie verloren.
Ich habe schon oft erlebt, dass Organisationen bei der Bereitstellung von Patches für die
Software und das Betriebssystem von Sensoren sehr saumselig vorgingen, da diese Geräte
keinen Internetzugriff hatten, was regelmäßige Aktualisierungen schwierig macht. Eine
Lösung dafür besteht darin, innerhalb Ihres Netzwerks eine Art Updateserver einzurichten, sodass die regelmäßigen Aktualisierungen zeitnah erfolgen können. Das bedeutet
zwar einen gewissen höheren Verwaltungsaufwand, allerdings wird dadurch das Risiko
einer Gefährdung der Sensoren erheblich gesenkt. Es ist auch möglich, den Internetzugriff
des Sensors mithilfe eines internen Webproxys auf die Domänen einzuschränken, die für
die Software- und Systemaktualisierungen erreichbar sein müssen. Je nachdem, wo sich
der Sensor in Ihrem Netzwerk befindet, kann dies jedoch schwer umzusetzen sein.
3.6.2 Das Betriebssystem absichern
Sie müssen das Betriebssystem des Sensors nicht nur immer auf dem neuesten Stand
halten, sondern es auch nach den Richtlinien für eine sichere Konfiguration einrichten,
und zwar bevor Sie irgendwelche Sensorsoftware darauf installieren. Es gibt verschiedene
solcher empfohlenen Richtlinien. Wenn Ihre Organisation formale Konformitätsanforderungen wie HIPAA, NERC CIP oder PCI erfüllen muss, dann sind bei Ihnen wahrscheinlich schon irgendwelche Standards für die sichere Betriebssystemkonfiguration in Kraft.
Auch staatlichen und militärischen Stellen sind solche Richtlinien nicht fremd, da die
Sicherheit von Betriebssystemen durch zahlreiche Zertifizierungs- und Akkreditierungsprozesse wie DIACAP oder DITSCAP erzwungen wird.
Wenn Sie keine solchen formalen Normen erfüllen müssen, können Sie sich in verschiedenen
öffentlich zugänglichen Dokumenten über empfehlenswerte Vorgehensweisen informieren.
Besonders gefallen mir dabei die Benchmarks des Center for Internet Security (http://bench
marks.cisecurity.org/) und die Security Guides for Operating Systems der NSA (http://www.
nsa.gov/ia/mitigation_guidance/security_configuration_guides/operating_systems.shtml).
3.6 Den Sensor absichern 115
3.6.3 Eingeschränkter Internetzugriff
Ein Sensor sollte keinen uneingeschränkten Internetzugriff haben, denn wenn sich ein
Angreifer Zugriff auf dieses Gerät verschaffen kann, so fällt es ihm leicht, sensible Daten
davon abzurufen. Normalerweise richte ich auf Sensoren gar keinen Internetzugriff ein.
In Ausnahmefällen ist es auch möglich, mithilfe eines internen Webproxy einen eingeschränkten Zugriff ausschließlich auf unverzichtbare Domänen (z. B. für Software- und
Systemaktualisierungen) bereitzustellen.
Sensorprozesse sind oft so eingerichtet, dass sie regelmäßig IDS-Signaturen oder Reputationsdaten aus dem Internet beziehen müssen. Es wird auch immer üblicher, dass
Sensoren auf Datenquellen für Recherchedienste zugreifen. Beispielsweise nutzt Bro in
Echtzeit das Hash Registry von Team Cymru Malware und das SSL Observatory der
International Computer Science Institutes. Sie müssen zwar dafür sorgen, dass Ihre
Sensoren diese Daten empfangen, allerdings sollten Sie dazu vorzugsweise ein einziges
internes System einrichten, das diese Aktualisierungen herunterlädt und an das sich die
Sensoren wenden.
3.6.4 Minimale Softwareinstallation
Ein Sensor ist ein zweckgebundenes Sondergerät. Aufgrund dieser Spezialisierung sollte
nur die wirklich notwendige Software darauf installiert werden. Wir empfehlen, auf einem
Sensor neben einer minimalen Betriebssysteminstallation nur die Software unterzubringen, die für die Erfassungs-, Erkennungs- und Analyseaufgaben auf dem entsprechenden
Typ von Sensor erforderlich ist. Deaktivieren Sie auch nicht benötigte Dienste und entfernen Sie nicht benötigte Zuatzpakete, die zusammen mit dem Betriebssystem installiert
wurden. Das steigert nicht nur die Leistung des Sensors, sondern reduziert auch seine Angriffsfläche auf ein Minimum.
Der häufigste Fehler bei der Verschlankung einer Sensorinstallation besteht darin, zu vergessen, Compiler von dem Sensor zu entfernen. Häufig ist zur Installation von NSM-Tools
ein Compiler erforderlich, aber Sie dürfen ihn auf gar keinen Fall auf dem System belassen.
Wenn sich ein Angreifer Zugriff auf den Sensor verschaffen kann, dann stellt ein solcher
Compiler für ihn ein praktisches Werkzeug dar, um den Rest des Netzwerks anzugreifen.
Optimal ist es, die Sensortools auf einem anderen System zu kompilieren und dann auf
den Sensor zu übertragen, anstatt die Kompilation auf dem Sensor selbst vorzunehmen.
3.6.5 VLAN-Segmentierung
Sensoren müssen über mindestens zwei Netzwerkverbindungen verfügen, wobei die eine
Schnittstelle zur Erfassung von Netzwerkdaten dient, während die andere zur Administration des Sensors da ist, was gewöhnlich über SSH geschieht. Die Erfassungsschnittstelle
sollte keine IP-Adresse haben und nicht mit dem Netzwerk kommunizieren dürfen, aber
die Administrationsschnittstelle muss logisch in dem Netzwerk auftauchen. Wenn Ihre
116 3 Sensoren
Netzwerkumgebung die Segmentierung des Datenverkehrs mithilfe von virtuellen lokalen
Netzwerken (Virtual Local Area Networks, VLANs) erlaubt, sollten Sie das nutzen und die
Verwaltungsschnittstelle des Sensors in einem sicheren VLAN unterbringen, das nur für
den Sensoradministrator zugänglich ist.
3.6.6 Host-IDS
Die Installation eines HIDS (Host Intrusion Detection System) auf dem Sensor ist unverzichtbar. Solche Systeme nutzen verschiedene Methoden, um Veränderungen am Host zu
erkennen, etwa die Überwachung der Systemprotokolle und eine Erkennung von Änderungen der Systemdateien. Es gibt verschiedene kommerzielle HIDS-Produkte, aber auch
einige kostenlose Programme wie OSSSEC oder AIDE (Advanced Intrusion Detection Environment). HIDS-Software dient dazu, einen Einbruch auf dem System zu erkennen, auf
dem sie installiert ist. Die Protokolle, die sie generiert, müssen Sie an einen anderen Server
im Netzwerk senden, denn wenn Sie sie lokal speichern und nicht sofort untersuchen,
könnte ein Angreifer sie löschen oder manipulieren, bevor Sie Einsicht darin nehmen.
3.6.7 Zwei-Faktor-Authentifizierung
NSM-Sensoren sind lukrative Ziele für Angreifer. Die rohen und die verarbeiteten Netzwerkdaten, die darauf zu finden sind, können für eine Vielzahl von Angriffen genutzt werden. Daher ist es wichtig, einen sicheren Authentifizierungsvorgang für den Zugriff auf
den Sensor zu verlangen. Bei einer reinen Passwortauthentifizierung besteht die Gefahr,
dass ein Angreifer das Passwort aus einer anderen Quelle in Erfahrung bringt und sich
damit Zugriff auf den Sensor verschafft. Daher sollten Sie für Sensoren zwei Formen der
Authentifizierung vorsehen.
3.6.8 Netzwerk-IDS
Die Administrationsoberfläche eines Sensors muss unbedingt als ein sehr wertvolles Netzwerkelement angesehen und als solches überwacht werden. Eine der besten Möglichkeiten
besteht darin, sie mit demselben NIDS zu schützen wie den Rest des Netzwerks, wobei
diese Software allerdings mit großer Wahrscheinlichkeit auf dem Sensor selbst läuft. Die
einfache Lösung besteht darin, den Netzwerkdatenverkehr der Administrationsoberfläche auf die Überwachungsschnittstelle zu spiegeln. Obwohl sich das sehr einfach machen
lässt, wird es oft übersehen.
Eine der besten Maßnahmen, um sicherzustellen, dass der Sensor nicht mit unautorisierten Hosts kommuniziert, besteht darin, die Hosts festzulegen, mit denen eine Verbindung
zulässig ist, und eine Snort-Regel aufzustellen, die jegliche Kommunikation mit anderen
Geräten erkennt. Nehmen wir beispielsweise an, der Sensor an 192.168.1.5 darf nur mit
der Administrator-Arbeitsstation an 192.168.1.50 und dem lokalen Aktualisierungsserver
3.7 Zusammenfassung 117
an 192.168.1.150 kommunizieren. In diesem Fall können Sie unerlaubte Verbindungen
mit folgender Regel feststellen:
alert ip ![192.168.1.50,192.168.1.150] any < > 192.168.1.50 any (msg:
"Unauthorized Sensor Communication"; sid:5000000; rev:1;)
3.7
Zusammenfassung
Um Sensoren mit der richtigen Kapazität einzurichten und an den richtigen Stellen zu
platzieren, ist eine Menge Planung erforderlich. Wie über viele andere Themen könnte
man darüber schon fast ein eigenes Buch schreiben. Dieses Kapitel sollte Ihnen einen
Überblick über die wichtigsten Prinzipien geben. Darüber hinaus ist es empfehlenswert,
sich mit Ihren Kollegen und anderen Organisationen auszutauschen, um sich anzusehen,
wie sie ihre Sensoren im Rahmen ihrer eigenen Bedürfnisse und ihrer Netzwerkarchitektur aufgestellt haben. Dadurch können Sie solide Erfahrungswerte gewinnen, um das Wer,
Was, Wann, Wo und Warum der NSM-Sensorplatzierung zu klären.
4
Sitzungsdaten
Sitzungsdaten geben einen Überblick über die Kommunikation zwischen zwei Netzwerkgeräten. Sie werden auch als Konversation oder Fluss bezeichnet und gehören zu den vielseitigsten und nützlichsten Arten von NSM-Daten. Wenn wir die vollständigen Paketdaten (FPC) mit einer Aufzeichnung sämtlicher Telefongespräche vergleichen, die jemand
an seinem Apparat führt, dann entsprechen die Sitzungsdaten der Gesprächsaufstellung
auf der Telefonrechnung. Den Sitzungsdaten können Sie nicht entnehmen, um was es
ging, aber sie sagen Ihnen, wer, wo und wann kommuniziert hat.
Sitzungs- oder Flussdatensätze enthalten gewöhnlich das Protokoll, die IP-Adresse und
den Port der Quelle, die IP-Adresse und den Port des Ziels, einen Zeitstempel, der Beginn
und Ende der Kommunikation angibt, sowie die Menge der zwischen den beiden Geräten
übertragenen Daten. Die verschiedenen Formen von Sitzungsdaten, die wir uns in diesem
Kapitel ansehen, können noch andere Informationen enthalten, aber die genannten Felder sind in allen üblichen Implementierungen von Sitzungsdaten enthalten. Ein Beispiel
solcher Flussdaten sehen Sie in Abb. 4.1.
120 4 Sitzungsdaten
Abbildung 4.1: Beispiel für Flussdatensätze
Sitzungsdaten bieten zwar nicht so viele Details wie FPC-Daten, weisen aber besondere
Vorteile auf, die von erheblichem Wert für die NSM-Analyse sind. Wie wir im nächsten
Kapitel sehen werden, besteht das größte Problem bei FPC-Daten darin, dass der schiere
Umfang es den meisten Organisationen unmöglich macht, eine sinnvolle Menge davon
aufzubewahren. Das wiederum schränkt die Möglichkeiten ein, sämtliche Arten von Datenverkehr zu erfassen oder eine rückblickende Analyse durchzuführen, die für eine laufende Untersuchung von Bedeutung wäre. Die Datenmenge ist der große Nachteil der
FPC-Daten, aber eine Stärke der Sitzungsdaten: Da es sich bei ihnen nur um eine Sammlung von Berichten in Textform und Statistiken handelt, ist ihr Umfang äußerst gering.
Daher lassen sich sehr leicht Flussdaten in großem Maßstab speichern. Die Aufbewahrungszeiten für FCP-Daten zählen gewöhnlich in Minuten oder Stunden, aber Sitzungsdaten können Monate oder gar Jahre lang gespeichert werden. Ich habe sogar Organisationen kennengelernt, die Sitzungsdaten niemals löschen.
Ein weiterer Vorteil des geringeren Umfangs von Sitzungsdaten besteht darin, dass sie sich
schneller durchforsten und analysieren lassen. Das erleichtert die Arbeit für Analytiker,
die sich einen schnellen Überblick verschaffen wollen, und für Analysewerkzeuge, die Anomalien aufspüren oder Statistiken aufstellen sollen. Daher werden andere Datentypen,
etwa die statistischen Daten, mit denen wir uns in Kapitel 11 beschäftigen werden, von
Sitzungsdaten abgeleitet.
In diesem Kapitel sehen wir uns an, wie Flüsse generiert werden und welche Methoden
es für die Erfassung von Sitzungsdaten gibt. Außerdem stellen wir zwei weit verbreitete
Analyseprodukte für Sitzungsdaten vor, nämlich SiLK und Argus. Bevor wir uns mit den
Einzelheiten dieser Tools beschäftigen, müssen wir jedoch die Unterschiede zwischen den
verschiedenen Arten von Flussdaten kennen. In diesem Buch geht es um die beiden am
häufigsten verwendeten Typen, nämlich NetFlow- und IPFIX-Daten.
4.1
Flussdatensätze
Ein Flussdatensatz ist ein zusammengefasster Paketbericht. Die Art der Zusammenfassung hängt davon ab, welches Tool verwendet wird, um die Daten zu generieren und zu
untersuchen.
4.1 Flussdatensätze 121
Hinweis für Analytiker
In diesem Buch beschäftigen wir uns hauptsächlich mit SiLK. Daher beschreibt
dieser Abschnitt die Art und Weise, in der SiLK Daten zu Flussdatensätzen zusammenfasst.
Ein Flussdatensatz wird anhand von fünf Attributen identifiziert, die das Standard-Pentupel bilden: die IP-Quelladresse, der Quellport, die IP-Zieladresse, der Zielport und das
Transportprotokoll. Wenn ein Flussgenerator ein Paket untersucht, liest er diese Attribute,
zeichnet sie auf und erstellt einen neuen Flussdatensatz aus den Daten des Pentupels und
jeglicher anderer Felder, die bei dem vorliegenden Flusstyp (NetFlow 5, NetFlow 9, IPFIX
usw.) definiert sind.
Wenn ein neues Paket analysiert wird und dieselben Pentupel-Attributwerte enthält, dann
werden die Daten an den bereits vorhandenen Flussdatensatz angehängt. Das geschieht so
lange, wie Pakete mit übereinstimmenden Attributwerten eingehen. Es gibt drei Bedingungen, unter denen ein Flussdatensatz beendet werden kann (siehe Abb. 4.2):
1. Natürliche Zeitüberschreitung: Dies geschieht, wenn die Kommunikation wie im Protokoll spezifiziert auf natürliche Weise endet. Bei verbindungsorientierten Protokollen
wird das Vorkommen solcher Beendigungen verfolgt. Dabei wird auf Dinge wie RSTPakete und FIN-Folgen in TCP geachtet.
2. Zeitüberschreitung im Leerlauf: Wenn innerhalb von 30 s nach dem letzten Paket keine weiteren Daten für einen Fluss mehr eingehen, wird der Flussdatensatz abgeschlossen. Treffen nach diesen 30 s weitere Pakete mit denselben Pentupel-Attributwerten
ein, so wird ein neuer Flussdatensatz darüber angelegt. Die Frist ist einstellbar.
3. Zeitüberschreibung bei Aktivität: Wenn ein Fluss 30 Minuten lang geöffnet ist, wird
der Flussdatensatz abgeschlossen und ein neuer für dieselben Pentupel-Attributwerte
angelegt. Die Frist ist einstellbar.
Abbildung 4.2: Beendigung von Flussdatensätzen bei Leerlauf und bei Aktivität
Wenn Pakete mit neuen Pentupel-Attributwerten eingehen, wird ein neuer Flussdatensatz
angelegt. Es können jederzeit viele verschiedene Flussdatensätze geöffnet sein.
122 4 Sitzungsdaten
Ich veranschauliche das gern mit einem Mann am Fließband, der jedes an ihm vorbeilaufende Paket untersucht. Wenn er ein Paket mit einer neuen Zusammenstellung von
Pentupel-Attributwerten sieht, schreibt er die Werte auf eine Dose, entnimmt dem Paket
die Daten, die er braucht, steckt sie in die Dose und stellte diese zur Seite. Kommt auf dem
Fließband ein Paket angefahren, dessen Werte denen auf der Dose entsprechen, steckt er
dessen Daten ebenfalls in die bereitstehende Dose. Sobald eine der drei zuvor genannten
Bedingungen für die Beendigung eines Flussdatensatzs eintrifft, verschließt er die Dose
mit einem Deckel und schickt sie weiter.
Wie Sie anhand dieser Beschreibung schon ahnen können, werden Flüsse in den meisten
Fällen auf unidirektionale Weise generiert (einige Tools rufen auch bidirektionale Flüsse
hervor, z. B. YAF). Daher werden bei der TCP-Kommunikation, beispielsweise zwischen
192.168.1.1 und 172.16.16.1, immer mindestens zwei Flussdatensätze erstellt, einer für
den Datenverkehr von 192.168.1.1 zu 172.16.16.1 und der andere für die Gegenrichtung
(siehe Tabelle 4.1).
Tabelle 4.1: Zwei unidirektionale Flussdatensätze für eine einzige Kommunikationssequenz
IP-Quell­
adresse
IP-Ziel­
adresse
Quellport
Zielport
Protokoll
Pakete
192.168.1.1
172.16.16.1
3921
445
6
52
1331
FS PA
Out
172.16.16.1
192.168.1.1
445
3921
6
1230
310931
FS PA
In
Bytes
Flags
Typ
Um ein praxisnäheres Beispiel zu geben, stellen Sie sich eine Arbeitsstation (192.168.1.50)
vor, die versucht, von einem Remoteserver (192.0.2.75) eine Webseite abzurufen. Die
Kommunikationssequenz sehen Sie in Abb. 4.3.
4.1 Flussdatensätze 123
Abbildung 4.3: Ablauf der Kommunikation mit einem Webserver
Bei dieser Kommunikation muss die Clientarbeitsstation (192.168.1.50) zunächst einen
DNS-Server (4.2.2.1) außerhalb ihres lokalen Netzwerksegments abfragen. Nach dem
Eingang der DNS-Antwort kann die Arbeitsstation mit dem Webserver kommunizieren.
Tabelle 4.2 zeigt die Flussdatensätze für diese Kommunikation (aus der Sicht des Clients).
Tabelle 4.2: Flussdatensätze bei der Webkommunikation
IP-Quell­
adresse
IP-Ziel­
adresse
Quell- Zielport
port
Pro- PaBytes
tokoll kete
192.168.1.50
4.2.2.1
9282
53
17
1
352
Out
4.2.2.1
192.168.1.50
53
9282
17
1
1332
In
192.168.1.50
192.0.2.75
20239
80
6
1829
12283
FS PA
Outweb
192.0.2.75
192.168.1.50
80
20239
6
2923
309103
FS PA
Inweb
Flags Typ
124 4 Sitzungsdaten
Eine gute Übung, um sich mit Flussdaten vertraut zu machen, besteht darin, Flussdatensätze und Paketdaten für dasselbe Zeitintervall zu vergleichen. Wenn Sie diese beiden
Datentypen und ihre Darstellung für dieselbe Kommunikation nebeneinander betrachten, lernen Sie, wie Flussdaten abgeleitet werden. Als Nächstes sehen wir uns einige der
wichtigsten Flussdaten an.
4.1.1
NetFlow
NetFlow wurde 1990 von Cisco entwickelt, um den Routingvorgang auf den Netzwerkgeräten dieses Herstellers zu rationalisieren. Bei der ursprünglichen Version wurde ein
Flussdatensatz erstellt, wenn der Router das erste Paket einer neuen Netzwerkkonversation erkannte. Anhand dieser Datensätze konnte eine Messgrundlage für Netzwerkkonversationen aufgestellt werden. Außerdem konnten die Router anhand dieser Daten mit
anderen Geräten und Diensten im Netzwerk verglichen werden. Des Weiteren wurden
die Datensätze dazu herangezogen, große Mengen von Datenverkehr zu erkennen und
zusammenzufassen, was dabei half, viele Prozesse zu vereinfachen, z. B. Vergleiche mit
Zugriffssteuerungslisten. Außerdem boten diese Datensätze den Vorteil, dass sie sich von
Technikern viel leichter untersuchen ließen. In den letzten 23 Jahren wurde die ursprüngliche Spezifikation in neun Versionen sowie einigen davon abgeleiteten Arbeiten erweitert.
Die einzelnen Versionen weichen stark voneinander ab und werden von unterschiedlichen
Personen für unterschiedliche Aufgaben eingesetzt, von Infrastrukturunterstützung über
Anwendungsentwicklung bis zur Sicherheit.
NetFlow 5 und 9
Die beiden am häufigsten verwendeten NetFlow-Standards sind die Versionen 5 und 9.
NetFlow 5 ist die am leichtesten zugängliche Lösung, da die meisten modernen Routinggeräte einen Export in diesem Format unterstützen. Flussdatensätze nach NetFlow 5 bieten die standardmäßigen Pentupel-Informationen sowie alle erforderlichen Statistiken,
um die Zusammenfassung des Flusses für die betroffenen Pakete zu definieren. Anhand
dieser Statistiken können Analyse-Engines die Untersuchung der Informationen rationalisieren. Im Gegensatz zu NetFlow 9 und IPFIX unterstützt NetFlow 5 das Protokoll IPv6
jedoch nicht, was es für manche Umgebungen unbrauchbar macht.
NetFlow 9 beherrscht alles, was auch NetFlow 5 kann, und bietet darüber hinaus weitere
Möglichkeiten. So verfügt es über ein neues Template, das eine detailreichere Protokollierung erlaubt. In NetFlow 5 gibt es 20 Datenfelder (wobei zwei nur zum Auffüllen dienen),
in NetFlow 9 dagegen sind 104 Feldtypen definiert. Anhand des Templates kann die Ausgabe so gestaltet werden, dass sie die gewünschte Zusammenstellung von Datenfeldern
enthält. Damit können auch diese neuen Feldtypen übertragen werden. Dadurch kann
ein Administrator in NetFlow 9 ähnliche Datensätze wie in NetFlow 5 generieren, indem
er einfach ein Template anpasst. Darüber hinaus bietet NetFlow 9 auch Unterstützung für
IPv6. Mehr über die Unterschiede zwischen Version 5 und 9 erfahren Sie in der Dokumentation von Cisco.
4.1 Flussdatensätze 125
In seinem dreiteiligen Blog auf Plixer gibt Mike Patterson einen der besten und unterhaltsamsten Vergleiche zwischen NetFlow 5 und 9.1 Darin erklärt er, dass die spärliche
Verwendung von NetFlow 9 hauptsächlich an dem mangelnden Bedarf für die erhöhte
Nützlichkeit dieser Version liegt. Seiner Meinung nach ist NetFlow 5 mit einem einfachen Hamburger vergleichbar. Es erfüllt seinen Zweck, aber nicht mehr. Es gibt natürlich
Situationen, in denen man nur seinen Hunger stillen will, und dafür reicht ein einfacher
Hamburger aus. Er ist einfach zu bekommen, er ist billig, er besteht nur aus einem Minimum an Zutaten, aber er gibt Ihnen alles, was Sie gerade brauchen. NetFlow 9 dagegen ist
ein Angus-Cheeseburger mit allen Extras. Die meisten Administratoren haben entweder
nur minimale Anspruche an NetFlow-Daten und brauchen daher die Extras von NetFlow
9 nicht, oder sie haben nicht die Möglichkeit, auf die gleiche Weise mit den Daten von
NetFlow 9 zu arbeiten, wie Sie es in NetFlow 5 getan haben. Beides trägt dazu bei, dass
NetFlow 9 nicht weit verbreitet ist.
4.1.2 IPFIX
IPFIX hat viele Gemeinsamkeiten mit NetFlow 9 und baut auf demselben Format auf. Es
ist templategesteuert, datensatzorientiert und nutzt ein binäres Exportformat.2 Die kleinste Einheit der Datenübertragung in IPFIX ist die Nachricht. Sie enthält einen Header und
eine oder mehrere Mengen, die Datensätze enthalten. Dabei kann sich um Templatemengen oder um Datenmengen handeln. Eine Datenmenge verweist auf das Template, das die
Datensätze innerhalb der Datenmenge beschreibt. Was die Verbreitung angeht, ist IPFIX
mit NetFlow 9 vergleichbar. Die Unterschiede sind funktional. Beispielsweise bietet IPFIX
im Gegensatz zu NetFlow 9 Felder variabler Länge für den Export benutzerdefinierter
Informationen. Es gibt eine ganze Reihe von Unterschieden zwischen diesen beiden Flusstechnologien, die sich aber alle in einem Wort zusammenfassen lassen: IPFIX ist »flexibel«. Es gibt sogar eine Erweiterung namens »Flexible NetFix«, mit der Sie NetFlow 9
große Ähnlichkeiten mit IPFIX geben können. Diese Version jedoch ist nicht Gegenstand
dieses Buches.
4.1.3 Andere Flusstypen
Es gibt noch andere Flusstechnologien, und es kann durchaus sein, dass sie in Ihrer Umgebung bereits eingesetzt werden. Ihre Zugänglichkeit und ihre Möglichkeiten zur Analyse
können ihre Nutzung für NSM jedoch erschweren. Auf Juniper-Geräten kann Jflow zur
Verfügung stehen, auf Citrix-Geräten AppFlow. Eine der gebräuchlicheren Alternativen
zu NetFlow und IPFIX ist sFlow. Um die CPU-Belastung zu verringern, werden dabei
jedoch nur repräsentative Stichproben der übertragenen Daten genommen. Hersteller beginnen sich immer mehr für verschiedene Varianten von sFlow zu interessieren, sodass
sFlow inzwischen bei vielen verschiedenen Netzwerkgeräten und Hardwarelösungen im
1 http://www.plixer.com/blog/general/cisco-netflow-v5-vs-netflow-v9-which-most-satisfies-your-hunger-pangs/
2 http://www.tik.ee.ethz.ch/file/de367bc6c7868d1dc76753ea917b5690/Inacio.pdf
126 4 Sitzungsdaten
Lieferumfang enthalten ist. Diese anderen Flusstypen weisen durchaus jeweils ganz eigene
Vorteile auf. Denken Sie aber daran, dass Sie nicht nur einen zugänglichen Flussgenerator
brauchen, sondern auch eine Möglichkeit haben müssen, die Flussdaten zu erfassen und
zu analysieren.
Bei den Beschreibungen in diesem Buch werden wir nach Möglichkeit nicht auf konkrete
Flusstypen eingehen. Wenn es um die Analyse von Flussdaten geht, konzentrieren wir uns
auf das standardmäßige Pentupel, das in allen Arten von Flussdaten enthalten ist.
4.2
Sitzungsdaten erfassen
Sitzungsdaten lassen sich auf verschiedene Weise erfassen. Unabhängig von der konkreten
Methode brauchen Sie jedoch auf jeden Fall einen Flussgenerator und einen Kollektor.
Der Flussgenerator ist die Hardware oder Software, die die Flussdatensätze erstellt. Das
kann entweder durch die Analyse anderer Daten oder durch die Erfassung von Netzwerkdaten direkt an der Netzwerkschnittstelle geschehen. Bei einem Flusskollektor handelt es
sich um Software, die Flussdatensätze von einem Generator empfängt und sie in einem
abrufbaren Format speichert.
Viele Organisationen, die FPC-Daten erfassen, generieren die Flussdatensätze durch eine
Filterung dieser Daten. Das bedeutet aber, dass sie keine Flussdatensätze für Datenverkehr
aufstellen können, der nicht erfasst wurde. Gehen außerdem während der FPC-Erfassung
Pakete verloren, können Sie wertvolle Flussdaten verlieren. Die Filterung dient eigentlich
dazu, den Festplattenplatz optimal auszunutzen, aber die mit dem Datenverkehr verbundenen Flussdatensätze müssen trotzdem aufbewahrt werden. Diese Methode zur Generierung von Flussdaten ist gewöhnlich nicht empfehlenswert.
Die bevorzugte Methode besteht darin, auf die gleiche Weise wie FPC- und NIDS-Alarmdaten direkt an der Verbindung abzugreifen. Das kann entweder durch eine Software auf
einem Server oder durch ein Netzwerkgerät wie einen Router geschehen. In diesem Kapitel verwende ich dafür die Begriffe software- bzw. hardwareseitige Generierung.
4.2.1 Hardwareseitige Generierung
In vielen Situationen werden Sie feststellen, dass Sie bereits vorhandene Hardware nutzen
können, um Flussdaten zu generieren. Sie müssen dann nur auf einem flussfähigen Router
die Netzwerkadresse eines Kollektors angeben, und schon werden die Flussdatensätze von
der Schnittstelle des Routers an dieses Ziel gesendet.
Hardwareseitige Generierung mag sich zwar nach einem Kinderspiel anhören, aber es
kann durchaus sein, dass Ihnen der Netzwerkadministrator die Erlaubnis dafür verweigert. Auf Routinggeräten, die bereits durch erhebliche Mengen von Datenverkehr belastet sind, kann die zusätzlich erforderliche Verarbeitungsleistung zur Generierung und
Übertragung von Flussdatensätzen an einen externen Kollektor die CPU-Nutzung so weit
4.2 Sitzungsdaten erfassen 127
steigern, dass die Netzwerkbandbreite gefährdet ist. Der Zusatzaufwand für die Flussgenerierung ist zwar minimal, kann in Umgebungen mit starkem Datenverkehr aber trotzdem
erhebliche Auswirkungen zeigen.
Wie nicht anders zu erwarten, bringen die meisten Geräte von Cisco eine Möglichkeit
zur Generierung von NetFlow-Daten mit. Um diese Funktionen auf einem Cisco-Router
einzurichten, schlagen Sie in der entsprechenden Dokumentation des Herstellers nach.
Auf http://www.cisco.com/en/US/docs/ios/netflow/command/reference/nf_cr_book.pdf bietet Cisco eine Anleitung zur Konfiguration von NetFlow unter Cisco IOS.
4.2.2 Softwareseitige Generierung
Die meisten NSM-Experten wenden die softwareseitige Generierung an, weil sie mehrere
Vorteile bietet. An erster Stelle steht dabei die Flexibilität bei der Bereitstellung. Es ist viel
einfacher, einen Server mit einer Software zur Flussgenerierung in ein Netzwerksegment
einzubauen, als die Architektur des Segments zu ändern, um einen Router zur Flussgenerierung aufzustellen. Um Flussdaten mithilfe von Software zu generieren, müssen Sie
auf dem Sensor einen Daemon ausführen, der die Flussdatensätze gemäß seiner Konfiguration erfasst und weiterleitet. Erstellt werden die Flussdaten aus den Daten, die an der
Erfassungsschnittstelle eingehen. In den meisten Fällen handelt es sich dabei um dieselbe
Schnittstelle, die auch von anderer Erfassungs- und Erkennungssoftware genutzt wird.
Sehen wir uns nun einige der am weitesten verbreiteten Softwarelösungen für diesen Vorgang an.
Fprobe
Fprobe ist eine Minimallösung zum Generieren von NetFlow-Daten. Diese Software steht
in den meisten modernen Repositorys für Linux-Distributionen zur Verfügung und kann
mithilfe der meisten Paketverwaltungssysteme (wie yum oder apt) auf dem Sensor installiert werden.
Wenn auf dem Sensor keine ausgehenden Netzwerkverbindungen zur Verfügung stehen,
können Sie das Paket ohne seltsame Warnhinweise und obskure Optionen kompilieren
und manuell installieren. Zur Initialisierung geben Sie den Befehl fprobe und nennen
dabei die IP-Adresse und den Port des Orts, an den die Flussdaten geleitet werden sollen.
Wollen Sie beispielsweise Flussdaten an Schnittstelle eth1 generieren und zu einem Kollektor senden, der auf dem Host 192.168.1.15 an Port 2888 lauscht, müssen Sie folgenden
Befehl geben:
fprobe -i eth1 192.168.1.15:2888
128 4 Sitzungsdaten
YAF
YAF (Yet Another Flowmeter) generiert IPFIX-Flussdaten. Das Tool wurde vom NetSATeam (Network Situation Awareness) des CERT entwickelt, um IPFIX-Datensätze für die
Verwendung in SiLK (siehe den nächsten Abschnitt) zu generieren.
Wie bereits erwähnt, stellt NetFlow 5 unidirektionale Flussinformationen bereit. Das kann
zu redundanten Daten in den Flussstatistiken führen und damit in großen, dezentralen
Systemen zur Flusserfassung die Datenabfragen erheblich beeinträchtigen. Um mit der
naturgemäß wachsenden Bandbreite Schritt zu halten und den Analytikern bidirektionale
Flussinformationen zur Verfügung zu stellen, wurde IPFIX als eine unverzichtbare Ergänzung von SiLK angesehen. Um einen IPFIX-Generator zur Verfügung zu haben, wurde YAF entwickelt. Ein zusätzlicher Vorteil von YAF besteht darin, dass es die Template-­
Architektur von IPFIX in Kombination mit SiLK-Anwendungskennzeichen nutzen kann.
Damit ist eine detailliertere Analyse möglich als mit dem Pentupel von NetFlow 5.
Je nachdem, was Sie beabsichtigen und wie groß Ihre Umgebung ist, kann YAF ein Muss
für Sie sein. Die Installation dieser Software ist ganz einfach. In diesem Buch werden wir
nicht auf die Einzelheiten eingehen, aber es gibt einige Kleinigkeiten, die zu einem reibungslosen Vorgang beitragen. Lesen Sie die NetSA-Dokumentation gründlich durch,
bevor Sie YAF kompilieren. NetSA bietet auch ergänzende Installationstutorials, die Ihnen bei der Einrichtung helfen. Das entsprechende Dokument finden Sie auf https://tools.
netsa.cert.org/confluence/pages/viewpage.action?pageId=23298051.
4.3
Flussdaten mit SiLK erfassen und analysieren
SiLK (System for Internet-Level Knowledge) ist eine Werkzeugsuite, die eine effiziente,
netzwerkübergreifende Sicherheitsanalyse ermöglicht. Sie dient nicht nur als Flusskollektor, sondern kann auch Flussdaten speichern, abrufen, untersuchen und anzeigen. Das
Projekt wird zurzeit von der NetSA-Gruppe des CERT entwickelt, aber wie die meisten
großartigen Sicherheitstools wurde es aus der Not heraus geboren. Ursprünglich hieß
es »Sureh's Work« und kam zustande, als ein Analytiker Flussdaten schnell und effizient ohne komplizierte, CPU-intensive Skripte untersuchen musste. SiLK besteht aus
C-, ­Python- und Perl-Code und funktioniert damit in praktisch allen Umgebungen auf
UNIX-Grundlage.
Dokumentation ist stets von größter Wichtigkeit. Wie großartig ein Tool, ein Skript oder
ein Gerät auch immer sein mag, es nützt überhaupt nichts, wenn niemand außer dem Entwickler es einsetzen kann. Was Tools zur Informationssicherheit angeht, so ist die Dokumentation von SiLK unübertroffen. In den folgenden Abschnitten verweisen wir nicht nur
auf die Dokumentation, sondern nutzen sie auch im Rahmen des Anwendungsbeispiels.3
Es ist keine Übertreibung, wenn ich sage, dass die Dokumentation von SiLK und die Community, die dieses Tool unterstützt, zu den besten Merkmalen dieses Projekts gehören.
3 http://tools.netsa.cert.org/silk/docs.html
4.3 Flussdaten mit SiLK erfassen und analysieren 129
4.3.1 Das Packsystem von SiLK
SiLK besteht aus zwei Hauptkomponenten, dem Packsystem und der Analysesuite. Mit
dem Paketsystem erfasst und speichert SiLK Flussdaten in einem einheitlichen, eigenen
Format. Die Bezeichnung »Packsystem« bezieht sich darauf, dass SiLK die Flussdaten in
einem platzsparenden Binärformat speichert, das ideal für die Untersuchung durch die
Analysesuite geeignet ist. Diese Suite wiederum besteht aus verschiedenen Werkzeugen
zum Filtern, Anzeigen, Sortieren, Zählen, Gruppieren, Vereinigen usw. Es handelt sich dabei um äußerst flexible Befehlszeilenwerkzeuge, die nicht nur jedes für sich sehr leistungsfähig sind, sondern auch über Pipes verkettet werden können, um die logische Ausgabe
des einen Tools in das nächste einzuspeisen.
Um die Erfassungs- und Analysefunktionen von SiLK nutzen zu können, müssen Sie ihm
Daten aus einem Flussgenerator zuführen. Wenn der Kollektor Flussdatensätze eines Generators empfängt, trennt er sie logisch nach Flusstypen. Die Flusstypen werden dann auf
der Grundlage einer Konfigurationsdatei untersucht, die bestimmt, ob es sich um Datensätze über ausgehenden, eingehenden oder internen Datenverkehr handelt.
Der lauschende Erfassungsprozess von SiLK ist ein Tool namens Rwflockpack. Es ist dafür zuständig, den Flusstyp zu untersuchen, den Sensor zu ermitteln, von dem die Daten
kommen, und die aufbereiteten Flussdaten in seiner Datenbank zu speichern, damit sie
von den Werkzeugen in der Analysesuite untersucht werden können. Den Arbeitsablauf
sehen Sie in Abb. 4.4.
Abbildung 4.4: Der Arbeitsablauf von SiLK
130 4 Sitzungsdaten
Wie Rwflowpack ausgeführt wird, können Sie über die Konfigurationsdatei rwflockpack.
conf und über zusätzliche Befehlszeilenargumente steuern. Die üblichste Methode, dieses
Programm aufzurufen, bietet der folgende Befehl:
service rwflowpack start
Rwflowpack bestätigt, dass die Einstellungen in den Dateien silk.conf und sensor.conf korrekt sind und dass alle in sensor.conf genannten Sockets zur Verfügung stehen. Wenn alles
in Ordnung ist, legt Rwflowpack los, und Sie erhalten eine Bestätigung auf dem Bildschirm.
Der Packprozess in SiLK ist zwar unkompliziert, allerdings bietet er mehr Optionen, als
nur Flussdaten zu empfangen und zu optimieren. Das Packsystem von SiLK besteht aus
acht verschiedenen Tools, mit denen eingehende Flüsse akzeptiert und legitimiert werden. Wie bereits erwähnt, nimmt Rwflockpack Daten von den Flussgeneratoren an, die
in den beiden Hauptkonfigurationsdateien silk.conf und sensor.conf angegeben sind, und
konvertiert und sortiert die Flussdaten in geeignete Binärdateien für die Analysesuite. Die
einfachste Möglichkeit, SiLK-Sitzungsdaten zu generieren, besteht darin, die Flussdaten
direkt zu einem Rwflowpack-Listener weiterzuleiten. Häufig ist jedoch eine Zwischenstation erforderlich, um die Daten zwischen Generator und Kollektor vorübergehend zu
speichern und weiterzuleiten. Dazu können Sie Flowcap verwenden. In den meisten Situationen fungiert Flowcap als Präprozessor von Rwflowpack: Es nimmt die Flussdaten
entgegen und sortiert sie aufgrund der Quelle und einer Einheiten- oder Zeitvariable in
Behälter. In der SiLK-Dokumentation wird diese Speicherung mit »eine Datei pro Quelle und Quantum« beschrieben, wobei ein Quantum entweder eine Zeitüberschreitung
oder eine maximale Dateigröße ist. In Form von Werkzeugen wie Rwflowappend, Rwpackchecker und Rwpollexec verfügt das Packsystem auch über Möglichkeiten für die
Nachbearbeitung. Rwflowappend und Rwpackchecker tun genau das, was ihre Namen
besagen: Rwflopappend hängt SiLK-Datensätze an vorhandene Datensätze an, während
Rwpackchecker die SiLK-Dateien auf Integrität und Beschädigungen prüft. Rwpollexec
überwacht die eingehenden SiLK-Datendateien und führt für jede einen vom Benutzer
festgelegten Befehl aus. Diese drei Tools können als Postprozessor bezeichnet werden, da
sie nach der Konvertierung der Rohflüsse in binäre SiLK-Dateien eine Nachbearbeitung
an diesen Dateien vornehmen. Unter dem Strich gibt es mehr als genug Möglichkeiten,
Ihre Daten von Rwflowpack in binäre SiLK-Dateien umwandeln zu lassen.
4.3.2 Flusstypen in SiLK
SiLK ordnet Flüsse nach Typen, die zur Filterung und Sortierung der Flussdatensätze herangezogen werden. Das geschieht auf der Grundlage der Netzwerkbereiche, die in der Rwflowpack-Konfigurationsdatei sensor.conf für die internen und externen IP-Adressblöcke
angegeben werden (siehe Abb. 4.5). Es gibt folgende Flusstypen:
•• In: Eingehend auf einem Gerät in einem internen Netzwerk.
•• Out: Ausgehend zu einem Gerät in einem externen Netzwerk.
4.3 Flussdaten mit SiLK erfassen und analysieren 131
•• Int2int: Von einem Gerät in einem internen Netzwerk zu einem Gerät im selben oder
einem anderen internen Netzwerk.
•• Ext2ext: Von einem Gerät in einem externen Netzwerk zu einem Gerät im selben oder
einem anderen externen Netzwerk.
•• Inweb: Eingehend auf einem Gerät in einem internen Netzwerk über Port 80, 443 oder
8080.
•• Outweb: Ausgehend zu einem Gerät in einem externen Netzwerk über Port 80, 443 oder
8080.
•• Inicmp: Eingehend auf einem Gerät in einem internen Netzwerk über ICMP (IP-Protokoll 1).
•• Outicmp: Ausgehend zu einem Gerät in einem externen Netzwerk über ICMP (IP-Protokoll 1).
•• Innull: Eingehender gefilterter Datenverkehr oder eingehender Datenverkehr zu den
in sensor.conf genannten Null-IP-Adressblöcken.
•• Outnull: Ausgehender gefilterter Datenverkehr oder ausgehender Datenverkehr zu den
in sensor.conf genannten Null-IP-Adressblöcken.
•• Other: Quelle nicht intern oder extern oder Ziel nicht intern oder extern.
Abbildung 4.5: Flusstypen in SiLK
Kenntnisse dieser Flusstypen sind bei der Verwendung der Filterwerkzeuge, mit denen wir
uns als Nächstes beschäftigen werden, sehr hilfreich.
4.3.3 Die Analysesuite von SiLK
Die Arbeit mit Flussdaten erfolgt zum größten Teil in der Analysesuite. In der SiLK-Installation sind mehr als 55 Tools enthalten, die alle sehr nützlich sind, wobei aber natürlich einige häufiger verwendet werden als andere. Diese Analysewerkzeuge sind für den
kombinierten Einsatz vorgesehen, wobei die Daten nahtlos von einem Tool zum anderen weitergeleitet werden können. Am häufigsten verwenden Analytiker Rwfilter, um die
SiLK-Binärdateien nach den Daten zu filtern, die sie brauchen. Wir haben schon erwähnt,
dass der Umfang der Flussdatensätze es ermöglicht, sie lange Zeit aufzubewahren. Offensichtlich muss es daher eine bequeme Möglichkeit geben, diese Daten zu filtern, damit
132 4 Sitzungsdaten
sie nur diejenigen sehen, die sie für die vorliegende Aufgabe benötigen. Stellen Sie sich
beispielsweise einen Analytiker vor, der nur Daten aus einer bestimmten Woche des Vorjahres benötigt, und zwar nur über Datenverkehr von einer bestimmten Quelladresse in
einem bestimmten Teilnetzwerk zu Zieladressen in einem bestimmten Land. Diese Auswahl lässt sich mithilfe von Rwfilter sehr einfach treffen. Sofern nicht anders verlangt, ist
die Ausgabe von Rwfilter eine weitere SiLK-Binärdatei, die über Pipes zur Untersuchung
oder Bearbeitung an andere Werkzeuge weitergeleitet werden kann. Das Tool wird in der
SiLK-Dokumentation ausführlich beschrieben, sowohl was die Filtermöglichkeiten als
auch Zählen, Gruppieren und andere Funktionen angeht. Da es in diesem Teil des Buches
hauptsächlich um die Erfassung geht, sehen wir uns hier nur einige wenige Verwendungszwecke der Analysesuite an.
4.3.4 SiLK in Security Onion installieren
Die Installation der einzelnen Werkzeuge werden wir in diesem Buch nicht ausführlich
beschreiben, da diese Vorgänge meistens recht gut dokumentiert sind. In Security Onion
sind die meisten davon ohnehin schon vorinstalliert. Leider ist das bei SiLK zurzeit noch
nicht der Fall. Eine ausführliche Anleitung zur Installation finden Sie im Applied-NSMBlog auf http://www.appliednsm.com/silk-on-security-onion/.
4.3.5 Flussdaten mit Rwfilter filtern
Der breite Anwendungsbereich der Flusserfassung und die Geschwindigkeit des Abrufs
von Flussdaten mit SiLK legen es nahe, eine Flusserfassung in jeder Umgebung vorzusehen. Mithilfe von SiLK kann jeder Analytiker den Umfang eines Netzwerkzwischenfalls
mit einer Geschwindigkeit eingrenzen, die mit anderen Datentypen nicht erreichbar ist.
In den folgenden Beispielen sehen wir uns eine Reihe typischer Situationen an, in denen
Sie SiLK einsetzen können, um Netzwerkzwischenfälle zu ermitteln oder um eine große
Datenmenge durch Filterung auf eine handhabbare Größe zu schrumpfen.
Eine der ersten Tätigkeiten bei einer Untersuchung besteht meistens darin, den Umfang
des Schadens zu ermitteln, den ein angreifender Host mit einer einzigen IP-Adresse angerichtet hat. Es kann sehr zeitraubend, wenn nicht gar unmöglich sein, dies mit PCAPDaten zu versuchen. In SiLK können Sie als Erstes den Befehl rwfilter mit mindestens
einer Eingabe-, einer Ausgabe- und einer Partitionierungsoption geben. An erster Stelle
steht die Option --any-addrss, die die Datenmenge nach allen Flussdatensätzen zu der
angegebenen IP-Adresse abfragt. Dies können Sie mit den Optionen --start-date und
--end-date kombinieren, um den Zeitrahmen anzugeben, an dem Sie interessiert sind.
Des Weiteren können Sie die Option -type=all verwenden, um anzugeben, dass Sie sowohl an ein- als auch an ausgehenden Flüssen interessiert sind. Die Option --pass=stdout
versetzt Sie in die Lage, die Ausgabe über ein Pipe-Symbol an Rwcut zu übergeben, sodass
sie im Terminal-Fenster dargestellt wird. Der fertige Rwfilter-Befehl sieht dann wie folgt
aus:
4.3 Flussdaten mit SiLK erfassen und analysieren 133
rwfilter --any-address=1.2.3.4 --start-date=2013/06/22:11 --enddate=2013/06/22:16 --type=all --pass=stdout | rwcut
Wenn Sie nur ein Startdatum eingeben, wird die Suche auf einen Zeitraum eingeschränkt,
der durch den kleinsten angegebenen Zeitwert bestimmt wird. Beispielsweise zeigt der Befehl --start-date=2013/06/22:11 alle mit dem Filter übereinstimmenden Flussdaten der
elften Stunde dieses Tages an. Bei --start-date=2013/06/22 erhalten Sie die Datensätze für
den gesamten Tag. Durch Kombination dieser Optionen können Sie einzelne Ereignisse
in den verschiedenen Datentypen korrelieren, aber sich auch ein Gesamtbild über die
Situation verschaffen.
Nehmen wir beispielsweise an, es gibt mehrere Ereignisse, bei denen eine verdächtige IPAdresse (6.6.6.6) kurz nach Mitternacht plötzlich erhebliche Mengen verschlüsselter Daten von einem sicheren Webserver erhält. Die einfachste Möglichkeit, den Umfang dieses
verdächtigen Datenverkehrs abzuschätzen, besteht darin, eine breit gefasste SiLK-Abfrage
auszuführen:
rwfilter --start-date=2013/06/22:00 --any-address=6.6.6.6 --type=all
--pass=stdout | rwcut
Sind die Daten zu umfangreich, fügen Sie einfach die Partitionierungsoption --aport=443
hinzu, um die Suche auf Ereignisse in Zusammenhang mit Interaktionen zwischen der
verdächtigen IP-Adresse und beliebigen sicheren Webservern einzuschränken. Die Option
--aport führt eine Filterung nach dem angegebenen Port durch, in unserem Fall also 443,
dem am häufigsten für die HTTPS-Kommunikation verwendeten Port.
rwfilter --start-date=2016/06/22:00 --any-address=6.6.6.6 --aport=443
--type=all --pass=stdout | rwcut
Bei der Untersuchung der Daten stellen Sie fest, dass der verdächtige Webserver mit mehreren Hosts in Ihrem Netzwerk kommuniziert. Sie möchten sich aber insbesondere die
Kommunikation von einem bestimmten internen Host (192.168.1.100) zu der verdächtigen IP-Adresse ansehen. Statt -any-address können Sie in diesem Fall die Optionen
--saddress und --daddress verwenden, um nach bestimmten Quell- bzw. Zieladressen zu
filtern. Der Befehl dazu sieht wie folgt aus:
rwfilter --start-date=2013/06/22:00 --saddress=192.168.1.100
--daddress=6.6.6.6 --aport=443 --type=all --pass=stdout | rwcut
134 4 Sitzungsdaten
4.3.6 Verketten von Analysetools
Analytiker prüfen die Integrität von NSM-Daten oft durch eine Untersuchung des eingehenden Datenverkehrs. In den folgenden Beispielen lernen Sie eine Reihe von Rw-Tools
kennen und erfahren, wie Sie sie verketten können.
Rwfilter macht nichts anderes, als die Auswahl der eingegebenen Binärdateien einzuschränken. Dieses Tool gibt die Menge von Binärdateien aus, die den Filteroptionen genügen. In den vorherigen Beispielen haben wir die übereinstimmenden Binärdaten mithilfe
der Option --pass=stdouot an das Terminal gesendet und mithilfe einer Pipe an Rwcut
übergeben, sodass sie im Terminal in einem von Menschen lesbaren ASCII-Format angezeigt werden. In gewissem Sinne haben wir also bereits Rw-Tools verkettet. Bei Rwcut
handelt es sich um das grundlegendste dieser Werkzeuge – und auch um das wichtigste,
da es die Daten in eine Form überführt, die die Analytiker lesen können. Allerdings führt
es keine Berechnungen oder Sortierungen aus, sondern wandelt einfach nur die Binärdaten in ASCII-Daten um und bereitet sie nach den vom Benutzer gewählten Optionen zur
Anzeige auf.
Um Berechnungen an den gefilterten Daten anzustellen, müssen Sie diese direkt in ein
Analysewerkzeug leiten. Als Beispiel sehen wir uns das Tool Rwcount an, das einen Überblick über den gesamten Netzwerkdatenverkehr im Verlauf der Zeit gibt. Daraus können Analytiker ein besseres Verständnis der Netzwerke gewinnen, die sie überwachen.
Rwcount wird gewöhnlich für die Erstinspektion eines neuen Sensors verwendet. Wenn
Sie einen neuen Sensor online bringen, müssen Sie viele Dinge beachten. Wie viele Endbenutzer überwachen Sie? Wann herrscht der stärkste Datenverkehr vor? Was ist in den
Abendstunden zu erwarten? Rwcount liefert Ihnen den gewünschten Überblick über den
Datenverkehr. Dabei stützt sich das Werkzeug auf binäre SiLK-Daten. Wenn Sie diese Daten von Rwfilter an Rwcount übergeben, erhalten Sie einen Überblick über die Daten, die
die Filterkriterien erfüllen, im ASCII-Format.
Nehmen wir an, Sie müssen herausfinden, wie viele Daten von Ihrem SiLK-Manager erfasst werden. Dazu können Sie mit Rwfilter alle an einem Tag erfassten Daten ausgeben
und sie anschließend über eine Pipe an Rwcount übergeben:
rwfilter --start-date=2013/6/22 --proto=0-255 --pass=stdout --type=all |
rwcount --bin-size=60
Aufgrund dieses Befehls wird ein Überblick über den Datenverkehr im Zeitverlauf angezeigt. Dabei wird die Anzahl der Datensätze, Bytes und Pakete pro Minute für den Tag
ausgegeben, der als Filterkriterium festgelegt wurde. Das Zeitintervall, auf das die Werte
bezogen sind, geben Sie mit der Option --bin-size an, in diesem Beispiel also 60 Sekunden. Wenn Sie den Wert auf 3600 erhöhen, erhalten Sie die Datensätze, Bytes und Pakete
pro Stunde (siehe Abb. 4.6). Wie bereits erwähnt, müssen Sie bei Rwfilter mindestens eine
Eingabe-, eine Ausgabe- und eine Partitionierungsoption angeben. Hier verwenden wir
die Eingabeoption --type=all, um sämtlichen Datenverkehr am 22.6.2013 zu erfassen.
4.3 Flussdaten mit SiLK erfassen und analysieren 135
Um alle Daten an die Standardausgabe zu liefern, geben wir an, dass die Daten zu sämtlichen Protokollen (--proto=0-255) an stdout übergeben werden sollen (--pass=stdout).
Damit erfassen wir den gesamten Datenverkehr für den angegebenen Zeitraum.
Abbildung 4.6: Ausgabe der Flussdaten durch Rwcount
Nachdem Sie nun die grundlegende Filterung von Flussdatensätzen mit Rwfilter und den
Einsatz von Rwcount kennengelernt haben, wollen wir diese beiden Tools mit Rwsetbuild
kombinieren. Letzteres ermöglicht es uns, eine binäre SiLK-Datei zu erstellen, die SiLK
mit verschiedenen Partitionierungsoptionen verarbeiten kann. Sie werden häufig eine
Abfrage brauchen, die mehrere IP-Adressen berücksichtigt. Zwar enthält SiLK Tools, mit
denen sich mehrere Abfragen kombinieren lassen, doch mithilfe von Rwsetbuild wird dies
unnötig. Dieses Werkzeug vereinfacht den Vorgang. Legen Sie eine lineare Liste von IPAdressen und Subnetzen in Textform an (in unserem Beispiel testIPlist.txt) und lassen Sie
sie wie folgt von Rwsetbuild verarbeiten:
rwsetbuild testIPlist.txt testIPlist.set
Anschließend können Sie Rwfilter mit der Option --anyset einsetzen, um alle Flussdatensätze herauszufiltern, bei denen IP-Adressen aus der Liste im Feld für die Quell- oder die
Zieladresse stehen. Der Befehl dazu sieht wie folgt aus:
rwfilter --start-date=2014/06/22 --anyset=/home/user/testIPlist.set
--type=all --pass=stdout | rwcut
Damit können Sie einen wahren Schatz an Informationen finden. Nehmen wir an, dass
Sie die Kommunikationsdaten Ihres internen Netzwerks mit einer Liste schädlicher IPAdressen abgleichen wollen. Insbesondere interessieren Sie sich dafür, wie viele ausge-
136 4 Sitzungsdaten
hende Daten an diese »bösen« IP-Adressen übertragen werden. Die beste Möglichkeit,
das herauszufinden, bieten die Flussdaten, da Sie Rwsetbuild und Rwcount kombinieren
können, um sich eine übersichtliche Statistik der ausgehenden Daten zu diesen Adressen
anzeigen zu lassen. Gehen Sie dazu folgendermaßen vor:
1. Erstellen Sie die Datei badhosts.txt mit einer Liste der IP-Adressen.
2. Erstellen Sie mit folgendem Befehl die Set-Datei:
rwsetbuild badhosts.txt badhosts.set
3. Führen Sie mit folgendem Befehl die Abfrage durch, um die Statistik zu erstellen:
rwfilter --start-date=2013/06/22 --dipset=badhosts.set
--type=all --pass=stdout | rwcount --bin-size=3600
Als Nächstes wollen wir uns mit einer Situation beschäftigen, die mir täglich begegnet
und nach der ich oft gefragt werde: die Abfrage der Hosts im Netzwerk, die am meisten
kommunizieren.
Eine solche Abfrage kann sehr unterschiedlicher Natur sein. So kann es um Hosts mit
einem hohen Aufkommen an ausgehendem Datenverkehr in fremde Länder gehen, um
kommunikationsintensive Tor-Ausgangsknoten, die mit internen Geräten sprechen, oder
um geschwätzige lokale Geräte an den Ports 1 bis 1024. Um solche Dinge in Erfahrung
zu bringen, müssen Sie Statistiken für die Daten abrufen, die den entsprechenden Filterkriterien genügen. Das Werkzeug, das wir dazu verwenden, trägt – wie sollte es auch
anders sein – den einfallsreichen Namen Rwstats. Wenn Sie die Ergebnisse von Rwfilter an
Rwstats übergeben, erhalten Sie eine Liste der obersten oder untersten n Ergebnisse des
betreffenden Filters. Im folgenden Beispiel suchen wir nach den aktivsten ausgehenden
Verbindungen nach China. Insbesondere sind wir dabei an Kommunikationsvorgängen
interessiert, bei denen Daten an flüchtige Ports (> 1024) zurückgegeben werden. Das können Sie mit folgendem Befehl erreichen:
rwfilter --start-date=2013/06/22 --dcc=cn --sport=1024-65535 --type=all
--pass=stdout | rwstats --top --count=20 --fields=sip --value=bytes
In diesem Rwfilter-Befehl kommt eine Option vor, die wir bisher noch nicht verwendet
haben, nämlich -dcc. Damit können wir Datenverkehr filtern, der an einen bestimmten
Ländercode gerichtet ist. Das Gegenstück dazu ist der Filter -scc für Quellländercodes. Im
Lieferzustand ist eine Filterung nach Ländercode bei SiLK jedoch noch nicht möglich. Um
diese Funktion und damit den oben angegebenen Befehl nutzen zu können, müssen Sie
zunächst folgende Schritte ausführen:
1. Laden Sie mithilfe von wget die GeoIP-Datenbank MaxMind herunter:
wget http://geolite.maxmind.com/download/geoip/database/
GeoLiteCountry/GeoIP.dat.gz
4.3 Flussdaten mit SiLK erfassen und analysieren 137
2. Entpacken Sie die Datei und konvertieren Sie sie in das passende Format:
gzip -d -c GeoIP.dat.gz | rwgeoip2ccmap --encoded-input > country_codes.pmap
3. Kopieren Sie die resultierende Datei an den passenden Speicherort:
cp country_codes.pmap /usr/local/share/silk/
Das Ergebnis der zuvor genannten Abfrage sehen Sie in Abb. 4.7.
Abbildung 4.7: Das Ergebnis der Rwstats-Abfrage
Obwohl wir mit --count=20 angegeben haben, dass wir die obersten 20 IP-Adressen anzeigen lassen möchten, gibt Rwstats in diesem Beispiel nur drei Adressen aus, die mit
China kommunizieren. Das liegt daran, dass in dem betreffenden Zeitraum nur diese drei
Adressen Verbindungen mit China hatten. Wären es 50 gewesen, wären nur die oberen 20
angezeigt worden. Die Option --value=bytes gibt an, dass die Statistik auf der Anzahl von
Bytes im Datenverkehr beruhen soll. Ohne diese Option würde stattdessen die Statistik für
die Anzahl der Flussdatensätze erstellt.
Als nächster logischer Schritt müssen Sie in dieser Situation herausfinden, mit wem diese Adressen kommunizieren und ob sie Datenverkehr akzeptieren. Um die chinesischen
Adressen zu ermitteln, müssen Sie den Rwfilter-Teil des Befehls und die entsprechenden
Felder in Rwstats ändern. Mit der Option --saddress engen Sie außerdem die Suche auf
den Host ein, der am stärksten mit China kommuniziert.
rwfilter --start-date=2013/06/22 --saddress=192.168.1.12 --dcc=cn
--sport=1024-65535 --type=all --pass=stdout | rwstats --top --count=20
--fields=dip --value=bytes
Mit den Rwfilter-Befehlen aus den früheren Beispielen können Sie außerdem die Flussdatensätze für alle Hosts abrufen, um die Art der übertragenen Daten zu bestimmen.
Mithilfe dieser Informationen und der zugehörigen Zeitstempel lassen sich auch andere
nützliche Daten für die Untersuchung gewinnen, z. B. PCAP-Daten.
138 4 Sitzungsdaten
4.3.7 Zusätzliche Werkzeuge und Dokumentation
SiLK und YAF bilden nur einen kleinen Teil der Werkzeuge, die NetSA bereitstellt. Ich
rate Ihnen, sich auch die anderen öffentlich verfügbaren Tools anzusehen, die Sie neben
SiLK einsetzen können. So bietet NetSA mit iSiLK ein grafisches Front-End an, mit dem
auch Personen, die weniger Erfahrungen mit Unix haben, SiLK nutzen können. Ein weiteres hervorragendes Werkzeug ist Analysis Pipeline, eine Engine zur Automatisierung der
Flussanalyse, die fortlaufend weiterentwickelt wird und in die Flusserfassung integriert
werden kann. Sie müssen für Analysis Pipeline Regeln konfigurieren und können das Tool
dann nutzen, um an SiLK-Daten eine Blacklist-, DDoS- und Beacon-Erkennung vorzunehmen, ohne selbst Skripte dafür schreiben zu müssen.
Die Dokumentation von SiLK ist an sich schon hervorragend und eine unschätzbare
Quelle für professionelle Analytiker. Daneben gibt es noch ergänzende Handbücher und
Anleitungen, um auch das Interesse von Amateuranalytikern zu wecken und um Profis
beim Aufstellen von Abfragen zu unterstützen. Das Analyst Handbook4 ist eine umfassende, 107 Seiten starke Anleitung für viele SiLK-Anwendungsfälle. Es dient als offizielles Einführungstutorial zur Verwendung von SilK für die Flussdatenanalyse. Andere Dokumente
nennen Tipps und Tricks für die Analyse oder geben Informationen über die Installation.
Es gibt auch eine Einführung in PySiLK für diejenigen, die SiLK als Python-Erweiterung
implementieren wollen. Wir empfehlen Ihnen sehr, sich die üblichen Installationsszenarios anzusehen, um sich eine Vorstellung davon zu verschaffen, wie Sie SiLK in Ihrer eigenen Umgebung implementieren.
4.4
Flussdaten mit Argus erfassen und analysieren
Auch wenn wir uns in diesem Buch auf SiLK als Werkzeug zur Flussanalyse konzentrieren,
müssen wir Argus zumindest erwähnen. Auch dieses Tool ist aus den ersten Bemühungen des CERT-CC auf dem Gebiet der Flussanalyse hervorgegangen. 1989 wurde Argus
zum ersten Mal von staatlichen Stellen genutzt und wurde der erste Echtzeit-Netzwerkflussanalysator.5 Ab 1991 unterstützte das CERT Argus offiziell. Von diesem Zeitpunkt an
setzte eine rasche Entwicklung ein. 1995 wurde Argus schließlich für die Öffentlichkeit
freigegeben.
Argus wird als definitive Flussanalyselösung angepriesen, die nicht nur Flussdaten berücksichtigt, sondern einen umfassenden, systematischen Überblick über den gesamten
Netzwerkverkehr in Echtzeit bietet. Es handelt sich dabei um eine bidirektionale Flussanalysesuite, die beide Richtungen von Netzwerkkonversationen verfolgt und Messgrößen
für die zugehörigen Flussdatensätze bereitstellt.6 Neben vielen der Merkmale, die auch
andere IPFIX-Analyselösungen mitbringen, verfügt Argus über seine eigenen Tools zur
statistischen Analyse und seine eigenen Erkennungs- und Alarmmechanismen, die es von
4 http://tools.netsa.cert.org/silk/analysis-handbook.pdf
5 http://www.qosient.com/argus/presentations/Argus.FloCon.2012.Tutorial.pdf
6 http://qosient.com/argus/argusnetflow.shtml
4.4 Flussdaten mit Argus erfassen und analysieren 139
anderen Produkten abheben. In den nächsten Abschnitten gebe ich Ihnen einen Überblick
über die grundlegende Architektur und die Integration in Security Onion. Dabei werde
ich die bereits bekannten Aspekte nicht wiederholen, sondern mich auf das konzentrieren,
was wesentlich ist, um Daten erfassen und anzeigen zu können. Wie bereits erwähnt, hebt
sich Argus in einigen wichtigen Bereichen von anderen Werkzeugen ab. Ich werde Beispiele dafür geben, wie Argus Ihrer Organisation mit diesen Merkmalen mehr nutzen kann als
vergleichbare Flussanalysesoftware.
4.4.1 Architektur
Argus ist zwar in Security Onion enthalten, aber es ist dennoch wichtig, sich mit dem
allgemeinen Arbeitsablauf zum Abrufen und Verifizieren der Daten vertraut zu machen.
Trotz der Integration in Security Onion kann es vorkommen, dass Sie Probleme bei der
NSM-Erfassung beheben müssen. Es ist auch möglich, dass Sie Daten von externen Geräten verwenden möchten, bei denen es sich nicht um Security Onion-Sensoren handelt.
Für solche Fälle vermittelt Ihnen dieser Abschnitt Kenntnisse darin, wie Sie Argus bereitstellen und wie die Einzelteile zusammenwirken, damit Sie das Flussanalysepaket ohne
übermäßigen Zusatzaufwand nutzen können.
Bei dieser Erörterung beschränken wir uns auf Argus als eigenständige Bereitstellung. Argus besteht aus zwei Hauptpaketen. Das erste wird ganz allgemein als »Argus« bezeichnet
und zeichnet den Datenverkehr an einer festgelegten Netzwerkschnittstelle eines beliebigen Geräts auf. Es kann Daten auf die Festplatte schreiben, von wo aus sie weitergeleitet
werden können, aber auch eine Socketverbindung zu einem zentralen Sicherheitsserver
unterhalten, um die Daten direkt zu übertragen. Diese Komponente befindet sich gewöhnlich auf einem Sensor und sendet Daten an einen zentralen Protokollserver.
Bei der zweiten Komponente handelt es sich um das Argus-Clientpaket. Es liest Daten aus
Protokolldateien, Verzeichnissen oder Socketverbindungen zur Echtzeitanalyse. Die Clientwerkzeuge erfassen nicht nur Daten von externen Generatoren, sondern dienen auch
als Hauptanalysewerkzeug. Daher benötigen Sie die Tools auf allen Geräten, auf denen Sie
die Argus-Flussanalyse durchführen wollen.
Beim Arbeitsablauf unterscheiden sich Argus und vergleichbare Programme kaum. Das
Grundprinzip besteht darin, dass es eine Erfassungsschnittstelle gibt, auf der sich ein
Flussgenerator-Daemon befindet. Dieser Daemon erkennt den Datenverkehr, generiert
Flüsse und leitet die Flussdaten an eine zentrale Erfassungsplattform weiter, so sie gespeichert und analysiert werden.
4.4.2 Merkmale
Argus ist einzigartig, da es mehr Merkmale enthält als die meisten anderen Flussanalysewerkzeuge. Eine eigenständige Bereitstellung von Argus bietet mehr als nur grundlegende
Flussabfragen und Statistiken. Da über die Erfassung von IPFIX-Flussdaten und deren
140 4 Sitzungsdaten
Import in Argus auch Anwendungsteildaten abgerufen werden können, ist es möglich,
Aufgaben wie eine Filterung nach HTTP-URLs vorzunehmen. In heutigen NSM-Geräten
sind jedoch meistens bereits Werkzeuge enthalten, die diese zusätzlichen Aufgaben erledigen. Mechanismen wie die URL-Filterung sind daher redundant, wenn sie zusätzlich nach
der Analyse anderer Datentypen, etwa Paketstringdaten, eingesetzt werden. Da wir hier
über die Standardinstallation von Argus in Security Onion sprechen, werde ich die zusätzlichen Analysemöglichkeiten auf Anwendungsebene an dieser Stelle nicht behandeln. In
Kapitel 6 beschäftigen wir uns mit Paketstringdaten.
4.4.3 Grundlegender Datenabruf
Wenn Sie Daten in verschiedenen Flussanalysewerkzeugen abrufen, kann das aufgrund
der Ähnlichkeiten der Daten zu einem Déjà-vu führen. Die eigentlichen Unterschiede
zwischen den Tools liegen in der Abfragesyntax und in den Möglichkeiten zum Aufstellen
von Statistiken. Auf den ersten Blick scheint Argus eine sehr einfache Abfragesyntax zu
haben, doch der Lernvorgang kann sehr anspruchsvoll sein. Angesichts der großen Anzahl
von Abfrageoptionen und der eher schwammigen Dokumentation, die online zu finden
ist, bilden die man-Seiten für diese Software oft den Rettungsanker, um sich mit Argus
vertraut zu machen.
Das nützlichste Tool innerhalb der Clientsuite ist ra, das die grundlegenden Möglichkeiten
zum Filtern und Durchsuchen der von Argus erfassten Rohdaten bereitstellt. Es muss in
der Lage sein, auf eine Datenmenge zuzugreifen. Diese Daten können mithilfe der Option
-r über eine Argus-Datei bereitgestellt werden, aber auch über eine Pipe in den Standard­
eingang geleitet oder von einem entfernten Feed bezogen werden. Da wir hier eng mit
Security Onion zusammenarbeiten, können Sie auf das Verzeichnis für Argus-Dateien in
/nsm/sensor_data/<Schnittstellte>/argus/ verweisen. Auf den ersten Blick scheint es sich
bei ra um ein sehr einfaches Werkzeug handeln, und Sie werden häufig einfache Abfragen
stellen, die nur aus einer Leseoption und einem Berkeley-Paketfilter (BPF) am Ende bestehen. Wenn Sie beispielsweise den Verdacht haben, dass in Ihrem Netzwerk mehrere Genies
unterwegs sind, weil die HTTP-Protokolle Besuche auf www.appliednsm.com ausweisen,
können Sie sich die Daten mit folgendem Befehl in Argus ansehen:
ra –r /nsm/sensor_data/<Schnittstelle>/argus/<Datei> - port 80 and host
67.205.2.30
Eine Beispielausgabe für diesen Befehl sehen Sie in Abb. 4.8.
4.4 Flussdaten mit Argus erfassen und analysieren 141
Abbildung 4.8: Beispielausgabe von ra
Einer der größten Vorteile von Argus gegenüber anderen Flussanalyseprogrammen ist seine Fähigkeit, Protokolle mithilfe derselben BPFs zu untersuchen, wie sie auch von Tools
wie Tcpdump genutzt werden. Dadurch lassen sich die einfachsten Funktionen von ra
und Argus schnell und wirkungsvoll nutzen. Wenn Sie sich mit den grundlegenden Filtermethoden von ra vertraut gemacht haben, können Sie zu den zusätzlichen Optionen
übergehen. Wie bereits gesagt, kann ra die Standardeingabe verarbeiten und Daten über
die Standardausgabe an andere Argus-Tools weiterleiten. Wenn die Option -r nicht angegeben ist, liest ra standardmäßig von der Standardeingabe. Um die Ergebnisse von ra
in einer Datei auszugeben, verwenden Sie die Option -w. Betrachten Sie dazu als Beispiel
den folgenden Befehl:
cat /nsm/sensor_data/<Schnittstelle>/argus/<Datei> | ra -w - - ip and host
67.205.2.30 | racluster -M rmon -m proto –s proto pkts bytes
Hier verarbeitet ra die Standardeingabe und sendet die Ausgabe aufgrund der Option -w
an die Standardausgabe, wo sie an das Werkzeug Racluster übergeben wird. Dieses wiederum führt eine Datenaggreation zur IP-Profilerstellung aus. In dem Beispiel nimmt Racluster die Ergebnisse von ra entgegen und fasst die Ergebnisse protokollweise zusammen.
Ein Blick auf die man-Seite von ra zeigt, dass das Tool auch Racluster-Optionen zur Untersuchung der Ausgabe entgegennimmt. Der zuvor gezeigte Beispielbefehl führt zu einer
Ausgabe wie der in Abb. 4.9.
142 4 Sitzungsdaten
Abbildung 4.9: Beispielausgabe von ra und Racluster
4.4.4 Weitere Informationen über Argus
Wir werden in diesem Buch zwar nicht ausführlich auf die Verwendung von Argus zur
Analyse eingehen, aber es ist dennoch sinnvoll, es mit anderen Flussanalysesuites wie SiLK
zu vergleichen. Bei der Auswahl eines Flussanalysetools müssen Analytiker das Werkzeug
finden, das sich am besten für ihre Bedürfnisse, ihre Fähigkeiten und ihre Umgebung eignet. Die Möglichkeit, in ra zur Filterung von Daten BPFs einzusetzen, macht Argus selbst
für Anfänger in Sachen Flussanalyse zu einem leicht anzuwendenden Werkzeug. Eine anspruchsvolle Analyse mit Argus erfordert jedoch umfassende Kenntnisse sowohl der Vorgänge als auch der Ra-Tools. Mehr über Argus erfahren Sie auf http://quosient.com/argus/
index.shtml. Genauere technische Einzelheiten zur Arbeit mit Argus bietet http://nsmwiki.
org/index.php?title=Argus.
4.5
Überlegungen zur Speicherung von Sitzungsdaten
Im Vergleich zu anderen Daten weisen Sitzungsdaten nur einen geringen Umfang auf.
Allerdings darf die Flussdatensteuerung auch nicht auf die leichte Schulter genommen
werden. Ich habe es schon erlebt, dass Flussdaten als einzige Möglichkeit zur Protokollkorrelation aufgestellt wurden, es aber nach einigen Monaten der Datenerfassung nicht
mehr möglich war, die Protokolle abzufragen. Das lag an einem inkorrekten Überschreiben älterer Flussdaten. Werden Flussdaten sich selbst überlassen, können sie mit der Zeit
zu einer nicht mehr handhabbaren Größe anwachsen. Es gibt keine konkreten Empfehlungen für die Speicherkapazität, die Sie für Flussdaten vorhalten sollten, da dies davon
abhängt, welche Daten für Sie von Bedeutung sind und wie hoch der Durchsatz ist. Das
heißt aber noch lange nicht, dass Sie einen Universalfilter für den gesamten Datenverkehr
definieren sollten, den Sie erfassen. Selbst wenn Sie keine FPC-Daten für bestimmte Protokolle erfassen, beispielsweise für verschlüsselte GRE-Tunnel oder HTTPS-Datenverkehr,
sollten Sie Flussdatensätze dieser Kommunikationsarten aufbewahren.
Um die Menge des Speicherplatzes zu bestimmen, den Sie für Flussdaten benötigen, können Sie ein Arbeitsblatt heranziehen, dass das NetSA-Team des CERT für SiLK aufgestellt
hat. Zu finden ist es auf http://tools.netsa.cert.org/releases/SiLK-Provisioning-v3.3.xlsx.
4.5 Überlegungen zur Speicherung von Sitzungsdaten 143
Es gibt viele Möglichkeiten, Netzwerkprotokolleinträge zu verwalten. Als einfachste
Möglichkeit für mich hat sich ein cron-Job erwiesen, der die Daten überwacht und bei
Bedarf nach einem festgelegten Zeitraum überschreibt. Viele Datenerfassungswerkzeuge
verfügen über Funktionen, um ältere Daten zyklisch zu überschreiben, allerdings müssen Sie die Verwaltung dieser Funktionen meistens manuell durchführen. Das kann beispielsweise bei Flussdaten der Fall sein, wobei jedoch viele Organisationen Flussdaten nur
dann überschreiben, wenn es nötig ist. Eine Möglichkeit, die Datenmenge zu begrenzen,
besteht darin, einen einfachen cron-Job aufzustellen, der das Flussdatenverzeichnis bereinigt, indem er alle Dateien löscht, die älter als x Tage sind. Für SiLK können Sie das
beispielsweise mit folgendem cron-Job tun:
30 12 * * * find /data/silk/* -mtime +29 -exec rm {} \;
Hier werden jeden Tag um 12.30 Uhr alle Dateiendateien, die 30 Tage alt oder noch älter
sind, aus dem Verzeichnis /data/silk/directory entfernt. Falls Sie die Konfigurationsdateien
im selben Verzeichnis untergebracht haben wie die Daten, müssen Sie jedoch aufpassen,
dass Sie sie nicht versehentlich ebenfalls entfernen.
Viele Organisationen bewahren außerdem gern einen redundanten Satz der Flussdaten
auf. Dazu können Sie die Daten wie folgt auf ein externes USB-Speichergerät übertragen:
*/30****rsync--update-vr/data/silk//mnt/usb/data/silk/&>/dev/null
Dieser Befehl kopiert alle zwei Minuten sämtliche neuen Flussdateien auf das angegebene
Gerät. Wie Sie den cron-Job ausführen, hängt von der Art des Betriebssystems ab. Übrigens enthält auch SiLK Funktionen, um Daten an andere Orte zu übertragen.
Steuerbefehle wie diese schließe ich gern in ein allgemeines »Watchdog«-Skript ein. Es
soll dafür sorgen, dass bei einem Fehler oder einem Neustart des Systems die Dienste neu
gestartet werden, enthält aber auch regelmäßige Datenaktualisierungen und -löschungen,
die Übertragung und Kopie redundanter Daten, Statusskripts zur Sensorüberwachung sowie Skripts zur Dienstüberwachung, die dafür sorgen, dass die Prozesse aktiv bleiben. Das
bietet den zusätzlichen Vorteil, dass Fehler beim Start des Sensors vermieden werden und
dass die Dienste starten, sobald der cron-Job ausgeführt wird, und nicht erst zusammen
mit dem restlichen Kernel-Startvorgang.
Der größte Vorteil eines solchen Skripts aber besteht darin, dass es eine zentrale Stelle
bietet, um die Sensoren auf korrektes Funktionieren hin zu überwachen. Dazu gehört es
auch, dafür zu sorgen, dass die Daten kontinuierlich fließen. Mit dem folgenden Skript
können Sie YAF überwachen, um sicherzustellen, dass das Programm permanent läuft.
Möglicherweise müssen Sie es jedoch an Ihre Produktionsumgebung anpassen.
144 4 Sitzungsdaten
#!/bin/bash
function SiLKSTART {
sudo nohup /usr/local/bin/yaf --silk --ipfix=tcp --live=pcap
--out=192.168.1.10 --ipfix-port=18001 --in=eth1 --applabel
--maxpayload=384 --verbose --log=/var/log/yaf.log &
}
function watchdog {
pidyaf=$(pidof yaf)
if [ -z "$pidyaf" ]; then
echo "YAF is not running."
SiLKSTART
fi
}
watchdog
Ein weiteres Tool, das Sie ständig überwachen sollten, um sicherzustellen, dass es ständig
läuft und Flussdaten erfasst, ist Rwflowpack. Dazu können Sie folgenden Code verwenden:
#!/bin/bash
pidrwflowpack=$(pidof rwflowpack)
if [
echo
sudo
sudo
fi
4.6
-z "$pidrwflowpack" ]; then
"rwflowpack is not running."
pidof rwflowpack | tr ' ' '\n' | xargs -i sudo kill -9 {}
service rwflowpack restart
Zusammenfassung
In diesem Kapitel haben wir Ihnen einen Überblick über die grundlegenden Prinzipien der
Erfassung von Sitzungsdaten gegeben. Das umfasste eine Beschreibung der verschiedenen
Arten von Sitzungsdaten wie NetFlow und IPFIX, eine Beschreibung der Datenerfassung
und -gewinnung mit SiLK und eine kurze Einführung in Argus. Ich kann die Wichtigkeit
von Sitzungsdaten nicht genug betonen. Wenn Sie ein neues Sicherheitsprogramm aufstellen oder NSM in einer Organisation einrichten, bilden die Sitzungsdaten den besten
Ausgangspunkt und liefern den meisten Wert für die erforderlichen Bemühungen.
5
FPC-Daten
Die NSM-Daten mit dem größten Wert für Analytiker sind FPC-Daten (Full Packet Capture, »vollständige Paketerfassung«). Sie legen Rechenschaft über jedes Datenpaket ab, das
zwischen zwei Endpunkten übertragen wurde. FCP-Daten lassen sich mit den Aufzeichnungen einer Überwachungskamera vergleichen. Wenn ein Angreifer über ein Netzwerk
auf ein System zugreift, dann finden sich Spuren davon in den FPC-Daten.
Wegen ihrer Vollständigkeit können FPC-Daten erdrückend umfangreich wirken. Gerade
der große Detailreichtum aber ist für die Analyse sehr wertvoll. Der Preis dafür besteht
jedoch in dem hohen Platzbedarf für die langfristige Speicherung. Manche Organisationen haben nicht die Ressourcen, um in ihrer NSM-Infrastruktur FPC-Daten auf sinnvolle
Weise zu berücksichtigen.
Am häufigsten liegen FPC-Daten im PCAP-Format vor (siehe Abb. 5.1). Es wird von den
meisten Open-Source-Tools zur Erfassung, Erkennung und Analyse unterstützt und galt
relativ lange Zeit als Standard für FPC-Daten. Es gibt mehrere Bibliotheken, um Software
zu schreiben, die PCAP-Dateien generieren und verarbeiten kann. Die am weitesten verbreitete ist Libpcap, eine Open-Source-Bibliothek, mit deren Hilfe Anwendungen mit
Netzwerkkarten arbeiten können, um Pakete zu erfassen. Der Hauptzweck dieser 1994 geschriebenen Bibliothek bestand darin, eine plattformunabhängige API für die Paketerfassung bereitzustellen, für die keine betriebssystemspezifischen Module erforderlich waren.
Viele Anwendungen für die Paketerfassung und -analyse nutzen Libpcap, darunter auch
146 5 FPC-Daten
mehrere der in diesem Buch besprochenen Tools wie Dumpcap, Tcpdump, Wireshark usw.
Da Bibliotheken wie diese die Arbeit mit PCAP-Daten so leicht machen, werden andere
NSM-Datentypen, z. B. statische oder Paketstringdaten, oft aus PCAP-Daten gewonnen.
Abbildung 5.1: PCAP-Daten in Wireshark
Als Nachfolgeformat von PCAP hat sich in letzter Zeit PCAP-NG entwickelt. Es bietet
mehr Möglichkeiten als der Vorgänger. Unter anderem ist es möglich, Kommentare in
Paketerfassungen aufzunehmen (siehe Abb. 5.2). Das ist sehr hilfreich, wenn Analytiker
bereits untersuchte Dateien zu einer weiteren Analyse durch sie selbst oder durch Kollegen
speichern. Die meisten in diesem Buch besprochenen Tools unterstützen PCAP-NG.
Bericht von der Front
Das Format einer Paketerfassungdatei können Sie mithilfe des Tools Capinfos
ermitteln, das im Lieferumfang von Wireshark enthalten ist (siehe Kapitel 13).
Dazu müssen Sie den Befehl capinfos -t <Datei> ausführen. Bei einer PCAPDatei gibt Capinfos die Bezeichnung libpcap zurück, bei einer PCAP-NG-Datei
pcapng.
5.1 Dumpcap 147
Abbildung 5.2: Ein kommentiertes Paket im Format PCAP-NG
In diesem Kapitel sehen wir uns mehrere beliebte FPC-Erfassungsprodukte und deren
Vorteile an. Außerdem beschäftigen wir uns mit Strategien, um FPC-Lösungen auf möglichst wirtschaftliche Weise in Ihrem Netzwerk umzusetzen.
5.1
Dumpcap
Eine der einfachsten Möglichkeiten für eine vollständige Paketerfassung bietet Dumpcap.
Es ist in Wireshark enthalten, was bedeutet, dass es auf den Systemen der meisten Analytiker bereits vorhanden ist – möglicherweise ohne dass sich die Analytiker dessen bewusst
sind. Dieses einfache, auf Libpcap gestützte Tool dient einem einzigen Zweck, nämlich
Pakete an einer Schnittstelle zu erfassen und im Format PCAP-NG auf die Festplatte zu
schreiben.
In Security Onion ist Wireshark bereits installiert und damit auch Dumpcap. Außerdem
können Sie die Suite auch von http://www.wireshark.org herunterladen. Sie ist mit dem
Libpcap-Treiber gebündelt, der für die Paketerfassung erforderlich ist. Um Pakete zu erfassen, rufen Sie Dumpcap wie folgt auf und geben die Erfassungsschnittstelle an:
dumpcap –i eth1
Dieser Befehl sorgt dafür, dass Pakete erfasst und in eine zufällig benannte Datei im aktuellen Arbeitsverzeichnis geschrieben werden. Diese Erfassung wird so lange fortgesetzt, bis
Sie sie abbrechen. Um die Erfassung und Speicherung der Paketdaten zu steuern, können
Sie in Dumpcap verschiedene Optionen angeben:
•• -a <Wert>: Gibt an, wann das Schreiben in Erfassungsdateien beendet werden soll.
Dazu können Sie eine Zeitdauer, eine Dateigröße oder die Anzahl geschriebener Dateien angeben. Es ist auch möglich, mehrere Bedingungen zu kombinieren.
•• -b <Optionen>: Veranlasst Dumpcap dazu, aufgrund festgelegter Kriterien mehrere
Dateien zu schreiben. Hierbei kann es sich um eine Zeitdauer, eine Dateigröße oder
148 5 FPC-Daten
••
••
••
••
••
die Anzahl geschriebener Dateien handeln. Es ist auch möglich, mehrere Bedingungen
zu kombinieren.
-B <Wert>: Gibt die Puffergröße an, also die Menge der Daten, die zwischengespeichert
werden, bevor sie auf die Festplatte geschrieben werden. Wenn Paketverluste auftreten,
sollte dieser Wert erhöht werden.
-f <Filter>: BPF-Befehle (Berkeley-Paketfilter) zum Filtern der Erfassungsdatei.
-i <Schnittstelle>: Nennt die Schnittstelle, an der Pakete erfasst werden sollen.
-P: Speichert die Dateien im PCAP- statt im PCAP-NG-Format. Das ist sinnvoll, wenn
Sie für Abwärtskompatibilität mit Tools sorgen müssen, die mit PCAP-NG nicht umgehen können.
-w <Dateiname>: Legt den Namen der Ausgabedatei fest.
In einer Produktionsumgebung kann der Dumpcap-Befehl beispielsweise wie folgt aussehen:
dumpcap –i eth1 –b duration:60 –b files:60 –w NYC01
Auf diesen Befehl hin erfasst Dumpcap Pakete an der Schnittstelle eth1 (-i eth1)
und speichert sie in 60 Dateien (-b files:60), die jeweils 60 s Datenverkehr enthalten (-b duration:60). Nachdem die 60. Datei geschrieben wurde, wird die erste Datei
überschrieben. Die Dateinamen bestehen aus dem angegebenen String, der laufenden
Nummer der Datei und einem Zeitstempel (-w NYC01).
Dumpcap lässt sich leicht einrichten, hat aber seine Grenzen. Erstens kann es in Hochleistungsumgebungen mit hohem Durchsatz nur schwer mithalten, was dazu führt, dass
Pakete verloren gehen. Aufgrund seiner Einfachheit ist dieses Tool auch nicht gerade
sehr vielseitig. Das zeigt sich insbesondere in der beschränkten Anzahl von Konfigurationsoptionen, etwa bei der Ausgabe der erfassten Daten. Sie können dem Namen der
­Paketerfassungsdateien zwar einen selbst gewählten Text voranstellen, doch weitere Möglichkeiten, die Benennung der Dateien zu beeinflussen, haben Sie nicht. Das kann problematisch werden, wenn Sie für ein selbst geschriebenes Untersuchungsskript oder ein
Erkennungs- und Analysetool eines anderen Anbieters ein bestimmtes ­Namensschema
einhalten müssen.
Wenn Sie die FPC-Erfassung möglichst schnell und mit einem Minimum an Aufwand
einrichten möchten, bietet Dumpcap eine brauchbare Lösung. Falls Sie aber eine höhere
Vielseitigkeit brauchen oder Pakete an einer Verbindung mit hohem Durchsatz erfassen
müssen, sollten Sie sich lieber nach einem anderen Produkt umsehen.
5.2 Daemonlogger 149
5.2
Daemonlogger
Daemonlogger wurde von Marty Roesch kreiert, dem ursprünglichen Entwickler des IDS
Snort. Es handelt sich dabei um eine Paketaufzeichnungsanwendung für NSM-Umgebungen. Sie nutzt Libpcap zur Datenerfassung und weist zwei verschiedene Betriebsarten
auf. Im Hauptmodus werden die erfassten Pakete direkt auf die Festplatte geschrieben,
im zweiten Modus auf eine zweite, andere Schnittstelle übertragen. Dadurch fungiert
Daemonlogger praktisch als Software-Tap.
Ebenso wie Dumpcap lässt sich Daemonlogger sehr einfach verwenden, um Pakete zu
erfassen. Um mit der Erfassung zu beginnen, müssen Sie lediglich den Befehl geben und
die Schnittstelle nennen:
daemonlogger -i eth1
Damit werden standardmäßig Pakete erfasst und im aktuellen Arbeitsverzeichnis abgelegt.
Wenn die Erfassungsdatei eine Größe von 2 GB erreicht, wird eine neue Datei angelegt.
Das läuft so weiter, bis der Prozess angehalten wird.
Auch in Daemonlogger können Sie die Art und Weise, wie die Pakete gespeichert werden,
mit einer Reihe von Optionen steuern. Besonders nützlich sind dabei die folgenden:
••
••
••
••
••
••
••
••
••
••
-d: Wird als Daemon ausgeführt.
-f <Dateiname>: Lädt BPFs (Berkeley-Paketfilter) aus der angegebenen Datei.
-g <Gruppe>: Wird als die angegebene Gruppe ausgeführt.
-i <Schnittstelle>: Legt die Schnittstelle fest, an der Pakete erfasst werden sollen.
-l <Verzeichnis>: Gibt das Verzeichnis an, in dem die Daten abgelegt werden sollen.
-M <Prozentwert>: Im Ringpuffermodus werden die Paketdaten aufgehoben, bis der
angegebene Prozentwert der Datenträgerkapazität erreicht ist. Um den Ringpuffermodus zu aktivieren, müssen Sie die Option -r angeben.
-n <Präfix>: Gibt das Namenspräfix für die Ausgabedateien an (sehr praktisch ist hier
die Angabe des Sensornamens).
-r: Aktiviert den Ringpuffermodus.
-t <Wert>: Überschreibt die Protokolldatei nach dem angegebenen Zeitraum.
-u <Benutzer>: Wird als der angegebene Benutzer ausgeführt.
In einer Produktionsumgebung kann Daemonlogger beispielsweise wie folgt aufgerufen
werden:
daemonlogger –i eth1 –d –f filter.bpf –l /data/pcap/ -n NYC01
Hier wird Daemonlogger als Daemon ausgeführt (-d), erfasst Pakete an der Schnittstelle
eth1 (-i eth1) und schreibt sie in das Verzeichnis /data/pcap (-l /data/pcap). Den Datei-
150 5 FPC-Daten
namen wird der String NYC01 vorangestellt, um anzugeben, von welchem Sensor sie stammen (-n NYC01). Gefiltert werden die Daten anhand der BPF-Anweisungen in der Datei
filter.bpf (-f filter.bpf).
Was die Leistung angeht, zeigt Daemonlogger einige der Schwächen, die auch Dumpcap
aufweist. Daemonlogger verkraftet zwar höhere Durchsätze als Dumpcap, stößt in sehr
großen Unternehmensumgebungen aber ebenfalls an seine Grenzen.
Die Möglichkeiten zur Benennung der Dateien sind in Daemonlogger ebenfalls eingeschränkt. Sie können Text auswählen, mit dem die Dateinamen beginnen sollen, an diesen Text wird unveränderlich der Zeitpunkt der Erfassung im Epochenformat angehängt.
Es gibt keine Möglichkeit, ein anderes Datums- und Uhrzeitformat auszuwählen. Zwar
könnten Sie die Dateien anschließend mit einem selbst geschriebenen Skript umbenennen, aber das stellt einen weiteren Vorgang dar, um den Sie sich kümmern müssten.
Die Funktion, mit der sich Daemonlogger zurzeit von der Masse abhebt, ist der Ringpuffermodus, der eine manuelle Verwaltung des PCAP-Speicherplatzes unnötig macht.
Mithilfe der Option -r -M <Prozentwert> sorgen Sie dafür, dass ältere Daten automatisch
entfernt werden, wenn der Platz für die Speicherung der PCAP-Daten den angegebenen
prozentualen Wert übersteigt. In manchen Fällen kann diese Möglichkeit einen entscheidenden Vorteil darstellen. Wenn Sie jedoch auch andere Arten von Daten sammeln, ist
wahrscheinlich schon eine Speicherverwaltung in Form anderer Prozesse in Kraft (mit
denen wir uns weiter hinten in diesem Kapitel noch beschäftigen werden).
Auch Daemonlogger ist daher eine großartige FPC-Lösung, wenn Sie Ihre Erfassungsmöglichkeiten einfach und mit wenig Aufwand einrichten möchten. Es ist äußert stabil,
und ich habe es schon in verschiedenen Unternehmensumgebungen erfolgreich im Einsatz gesehen. Ob Daemonlogger für Sie geeignet ist, bestimmen Sie am besten, indem Sie
es an der Netzwerkschnittstelle ausprobieren, die Sie überwachen wollen, und prüfen, ob
dabei Paketverluste auftreten.
5.3
Netsniff-NG
Netsniff-NG ist ein Hochleitungswerkzeug zur Paketerfassung, entworfen von Daniel
Borkmann. Während sich die bisher besprochenen Tools auf Libpcap stützten, verwendet
Netsniff-NG einen Zero-Copy-Mechanismus, um eine vollständige Paketerfassung auch
an Verbindungen mit hohem Durchsatz zu ermöglichen.
Eines der praktischen Merkmale von Netsniff-NG besteht darin, dass es nicht nur eine Paketerfassung mit RX_RING erlaubt, sondern auch eine Paketübertragung mit TX_Ring,
sodass Sie Pakete an einer Schnittstelle lesen und zu einer anderen Schnittstelle umleiten
können. Diese Möglichkeit gewinnt noch dadurch an Wert, dass Sie die Pakete zwischen
diesen Schnittstellen filtern können.
5.3 Netsniff-NG 151
Um Pakete mit Netsniff-NG zu erfassen, müssen Sie einen Eingang und einen Ausgang
festlegen. In den meisten Fällen handelt es sich bei dem Eingang um eine Netzwerkschnittstelle und bei dem Ausgang um eine Datei oder einen Ordner auf der Festplatte:
netsniff-ng –i eth1 –o data.pcap
Dieser Befehl sorgt dafür, dass Pakete an der Schnittstelle eth1 (-i eth1) erfasst und in
die Datei data.pcap im aktuellen Arbeitsverzeichnis geschrieben werden (-o data.pcap),
bis die Anwendung angehalten wird. Wenn Sie diesen Befehl ausführen, wird der Inhalt
der erfassten Pakete auf dem Bildschirm dargestellt. Um dieses Verhalten zu unterbinden,
können Sie Netsniff-NG mit dem Flag -s in den stillen Modus versetzen.
Wenn Sie den Prozess beenden (durch Drücken von (Strg) + (C)), gibt Netsniff-NG einige grundlegende Statistiken über die erfassten Daten aus (siehe Abb. 5.3).
Abbildung 5.3: Die Ausgabe von Netsniff-NG
Netsniff-NG bietet eine Menge Funktionen, die wir auch schon in den anderen FPCAnwendungen kennengelernt haben, darunter die folgenden:
•• -g <Gruppe>: Wird als die angegebene Gruppe ausgeführt.
•• -f <Dateiname>: Lädt BPFs (Berkeley-Paketfilter) aus der angegebenen Datei.
•• -F <Wert>: Dateigröße oder Zeitraum, um zu bestimmen, wann die Erfassung im
Einzeldateimodus enden bzw. wenn im Ringpuffermodus zur nächsten Datei übergegangen werden soll.
•• -H: Setzt die Priorität auf »hoch«.
•• -i <Schnittstelle>: Legt die Schnittstelle fest, an der Pakete erfasst werden sollen.
•• -o <Datei>: Gibt die Datei an, in die die Daten ausgegeben werden sollen.
•• -t <Typ>: Verarbeitet nur Pakete der angegebenen Typen (Host-, Broadcast-, Multicast- oder ausgehende Daten).
•• -P <Präfix>: Gibt das Namenspräfix für die Ausgabedateien an (sehr praktisch ist hier
die Angabe des Sensornamens).
152 5 FPC-Daten
•• -s: Stummer Modus. Die erfassten Pakete werden nicht auf dem Bildschirm ausgegeben.
•• -u <Benutzer>: Wird als der angegebene Benutzer ausgeführt.
In einer Produktionsumgebung kann Netsniff-NG beispielsweise wie folgt aufgerufen
werden:
netsniff-ng -i eth1 –o /data/ -F 60 -P "NYC01"
Dieser Befehl führt Netsniff-NG im Ringpuffermodus aus, was Sie an der Angabe eines
Ausgabeverzeichnisses anstelle eines Dateinamens im Parameter -o erkennen können (-o
/data/). Alle 60 s wird eine neue PCAP-Datei erstellt (-F 60), an deren Namen jeweils der
Sensorname NYC01 steht (-P "NYC01").
In unseren Tests hat Netsniff-NG von allen in diesem Buch besprochenen FPC-Programmen an Verbindungen mit hohem Durchsatz die beste Leistung gezeigt. Sie ist so gut, dass
dieses Tool als Standardprogramm für die FPC-Erfassung in Security Onion enthalten ist.
5.4
Das passende FPC-Erfassungswerkzeug auswählen
Wir haben drei verschiedene FPC-Lösungen besprochen und sind in den Beschreibungen auch jeweils auf die Leistung insgesamt eingegangen. Dumpcap und Daemonlogger
funktionieren in den meisten Situationen reibungslos und ohne Paketverluste, doch in
Umgebungen mit einem anhaltend hohen Aufkommen an Datenverkehr brauchen Sie ein
Tool wie Netsniff-NG. Wenn Sie Ihre Erfassungswerkzeuge nicht an den Durchsatz Ihrer
Umgebung anpassen, verschwenden Sie CPU-Zyklen und sammeln unvollständige Daten.
Für Analytiker gibt es nichts Frustrierenderes, als einen Datenstream zu rekonstruieren
und dabei festzustellen, dass ein Paket fehlt, sodass alle Anstrengungen umsonst waren.
In der Geschichte der FPC-Erfassungswerkzeuge ging es immer wieder darum, Daten »auf
die beste Weise« zu generieren. Manchmal kann »die beste Weise« bedeuten, dass eine
Vielzahl von Funktionen zur Verfügung steht, aber meistens wurden neue FPC-Lösungen
erstellt, um die Anforderungen neuer, schnellerer Netzwerke zu erfüllen. Das bedeutet
aber nicht, dass das beste FPC-Erfassungstool dasjenige ist, das die Daten am schnellsten
aufnehmen kann, sondern dasjenige, das die wenigsten Pakete verliert und gleichzeitig
genügend Möglichkeiten bietet, die Daten in einem Format zu speichern, das Ihre Erkennungs- und Analysetools verarbeiten können.
Die drei zuvor erwähnten Tools werden wir auch weiterhin in diesem Buch verwenden.
In der Netzwerkumgebung, für die sie geschaffen sind, erfüllen sie alle erwiesenermaßen
ihren Zweck, und sie gehören zu den bekanntesten und am weitesten verbreiteten kostenlosen Lösungen. Das passende Werkzeug für Ihre Organisation müssen Sie aufgrund der
Kriterien auswählen, die für Sie selbst am wichtigsten sind.
5.5 Die FPC-Datenerfassung planen 153
5.5
Die FPC-Datenerfassung planen
Bei der Festlegung der Sensorarchitektur sollten Sie der Erfassung der FPC-Daten eine
hohe Priorität einräumen. Dafür gibt es viele Gründe, unter anderem die Tatsache, dass
Sie praktisch alle anderen wichtigen Datentypen aus FPC-Daten gewinnen können. FPCDaten sind ein »primärer« Datentyp, der direkt von der Verbindung abgegriffen wird. Sie
umfassen weit mehr Daten pro Zeiteinheit als alle anderen Typen, weshalb Sie auch mehr
Festplattenplatz benötigen als die anderen Typen. Das heißt aber nicht, dass FPC immer
den größten Teil der Festplatte einnehmen. Viele Organisationen legen auch viel Wert auf
eine rückblickende Protokollanalyse und -korrelation und widmen oft einen vergleichbaren oder noch größeren Anteil des Festplattenplatzes anderen Arten von Protokollen, z. B.
Bro-Protokollen. Dabei kann es natürlich sein, dass die PCAP-Daten nur 24 Stunden lang
aufbewahrt werden, die Bro-Protokolle dagegen ein Jahr lang. Der Kernpunkt ist, dass viele der Daten, die Sie erfassen, von PCAP-Daten abgeleitet sind, und dass die erheblichen
Speicheranforderungen der PCAP-Daten Auswirkungen auf die Erfassung anderer Daten
haben.
Der wichtigste Aspekt, den Sie bei der Bereitstellung einer FPC-Lösung bedenken müssen, ist der Durchsatz, also die durchschnittliche Rate des Netzwerkverkehrs an den überwachten Schnittstellen. Bevor Sie einen Sensor kaufen, sollten Sie den Durchsatz an dem
zu überwachenden Port bestimmen, damit der Sensor auch die nötigen Ressourcen für
die Erfassung und Erkennung im erforderlichen Maßstab mitbringt. Erst die Hardware
zu kaufen und dann nachträglich zu versuchen, diese Voraussetzungen zu erfüllen, endet
gewöhnlich in einem Desaster.
5.5.1 Speicherplatz
Der wichtigste Gesichtspunkt im Zusammenhang mit FPC-Daten ist der Speicherplatz.
PCAP-Daten nehmen im Vergleich zu allen anderen Datentypen sehr viel Platz ein. Daher
ist es von entscheidender Bedeutung, den Umfang der FPC-Daten zu bestimmen, die Sie
speichern wollen. Dazu müssen Sie als Erstes einen Aufbewahrungsplan nach Zeit oder
nach Umfang aufstellen.
Bei der Aufbewahrung nach Zeit legen Sie fest, dass die PCAP-Daten mindestens den
angegebenen Zeitraum über gespeichert bleiben sollen, beispielsweise 24 Stunden. Bei
der Aufbewahrung nach Umfang geben Sie die Höchstmenge an PCAP-Daten an, die
gespeichert bleiben können, was gewöhnlich durch den Datenträger bestimmt wird, z. B.
10 TB, festgelegt durch ein 10-TB-RAID-Array. Bei beiden Verfahren sollte Ihre Organisation ein Betriebsminimum und ein Optimum festlegen. Das Minimum nennt die
Mindestanforderungen dafür, um NSM-Dienste in sinnvollem Umfang durchführen zu
können. Es gibt die erforderliche Aufbewahrungszeit oder den erforderlichen Umfang
dafür an, die kleinstmögliche Datenmenge zu speichern. Das Optimum dagegen stellt
einen angestrebten Wert dafür an, ein Network Security Monitoring auf bestmögliche
154 5 FPC-Daten
Weise durchzuführen. Hier stehen der Zeit- bzw. der Umfangswert für die Menge der
Daten, die Sie unter idealen Bedingungen speichern möchten. Kurz gesagt, sollten Sie
immer wenigstens über das Minimum verfügen, aber das Optimum anstreben.
Ob Sie sich für eine Aufbewahrung nach Zeit oder nach Umfang entscheiden, hängt von
vielen verschiedenen Faktoren ab. In regulierten Branchen, in denen Normen erfüllt
werden müssen, kann eine Organisation keine andere Wahl haben, als eine Aufbewahrung nach Zeit durchzuführen. In anderen Branchen kann die Entscheidung für die
Aufbewahrung nach Zeit auch einfach fallen, weil dies den üblichen Verfahren in der
Organisation entgegenkommt. Sind dagegen das Budget oder die Hardwareressourcen
knapp, bietet sich eine Aufbewahrung nach Umfang an. Dieses Verfahren wird auch oft
in unhomogenen oder rasch wachsenden Netzwerken angewendet, da die Menge des erforderlichen Speicherplatzes für eine Aufbewahrung nach Zeit unter diesen Umständen
nicht genau abgeschätzt werden kann.
Wenn Sie eine Aufbewahrung nach Zeit planen, können Sie aus dem durchschnittlichen
Durchsatz an einer Schnittstelle theoretisch ermitteln, wie viele Daten Sie pro Zeiteinheit
auf gegebenem Festplattenplatz speichern können. Nehmen wir an, an einer Schnittstelle
tritt durchschnittlich ein Durchsatz von 100 MB/s auf und Sie haben 1 TB Festplattenplatz
zur Verfügung. Theoretisch können Sie daher FPC-Daten 24 Tage lang speichern. In der
Praxis ist es jedoch ein – weit verbreiteter – Fehler, sich ausschließlich auf die Messung des
durchschnittlichen Durchsatzes zu verlassen, da hierbei die Spitzen nicht berücksichtigt
werden, also kurze Zeiträume, in denen der Durchsatz dramatisch ansteigt. Solche Spitzen
treten aus einer Reihe von Gründen auf. Unter anderem können sie durch geplante, regelmäßige Ereignisse wie Backups und Anwendungsaktualisierungen zustande kommen,
aber auch durch zufällige Gegebenheiten wie eine höhere Webaktivität als üblich. Da es
sich bei FPC-Daten um einen primären Datentyp handelt, rufen diese Spitzen auch ein
höheres Aufkommen der anderen Daten hervor, die aus ihnen abgeleitet werden, was die
Auswirkungen der Spitzen noch verstärkt.
Aufgrund der Natur des Netzwerkverkehrs ist es sehr schwer, Spitzen beim Durchsatz
vorherzusagen. Daher müssen Organisationen, die sich für eine Aufbewahrung nach Zeit
entschieden haben, eine erheblich kürzere Aufbewahrungsdauer wählen, als mit der Hardware theoretisch machbar wäre, um Reserveplatz bereitzustellen. Ansonsten bestünde die
Gefahr, dass Daten verloren gehen oder der Sensor vorübergehend überlastet wird.
Die Aufbewahrung von FPC-Daten nach Umfang lässt sich einfacher handhaben und ist
auch von Natur aus gegen Spitzen abgesichert. Bei dieser Methode bestimmen Sie den
maximalen Betrag an Festplattenplatz, den FPC-Daten einnehmen können. Sobald dieser
Grenzwert erreicht ist, werden die ältesten FPC-Daten entfernt, um Platz für die neuen
zu machen. Wie bereits erwähnt, ist diese Funktion in Daemonlogger bereits eingebaut.
5.5 Die FPC-Datenerfassung planen 155
5.5.2 Den Durchsatz an der Sensorschnittstelle mit Netsniff-NG und
Ifpps berechnen
Wir haben schon mehrfach erwähnt, dass es für die Erfassung und Speicherung von
FPC-Daten erforderlich ist, den Durchsatz an der Überwachungsschnittstelle des Sensors
zuverlässig zu bestimmen. Im Folgenden sehen wir uns an, wie Sie Durchsatzstatistiken
berechnen können. Eine Möglichkeit dazu bietet das in der Netsniff-NG-Suite enthaltene
Tool Ifpps. In Security Onion wird Netsniff-NG allerdings ohne Ifpps installiert. Wenn Sie
die Erklärungen in diesem Abschnitt nachvollziehen möchten, müssen Sie es daher wie
folgt manuell nachinstallieren:
1. Installieren Sie mit apt die Voraussetzung libncurses-dev.
sudo apt-get install libncurses-dev
2. Laden Sie Netsniff-NG mit git herunter.
git clone https://github.com/borkmann/netsniff-ng.git
3. Konfigurieren, erstellen und installieren Sie nur Ifpps.
./configure
make && sudo make install ifpps_install
Um sich die möglichen Argumente für Ifpps anzeigen zu lassen, führen Sie es mit dem
Argument -h aus. Wenn Sie dagegen gleich loslegen wollen, verwenden Sie den folgenden
Befehl, der ständig aktualisierte Netzwerkstatistiken anzeigt:
iffpss -d <Schnittstelle>
Diese Statistiken geben den aktuellen Durchsatz an der angegebenen Schnittstelle sowie
Daten zur CPU, zur Festplatten-E/A und anderen Gesichtspunkten des Systems an. Ein
Beispiel dafür sehen Sie in Abb. 5.4.
156 5 FPC-Daten
Abbildung 5.4: Netzwerkstatistiken mit Ifpps gewinnen
Das Einheit .../t gibt an, dass die Werte auf das Zeitintervall bezogen sind, das oben
rechts angezeigt wird und das Sie mit der Option -t festlegen können. Der Standardwert
beträgt 1000 ms.
Ifpps zeigt Ihnen eine Momentaufnahme des Durchsatzes an der Schnittstelle. Bei einer
umfangreichen Stichprobe kann diese Statistik sehr nützlich sein. Bei dieser Methode
müssen Sie aber sicherstellen, dass Sie genügend Stichproben von Spitzen- und ruhigen
Zeiten aufnehmen, um daraus den durchschnittlichen Durchsatz zu bestimmen.
Leider ist der Funktionsumfang von Ifpps eingeschränkt. Sie können keine Filter anwenden, weshalb dieses Tool nicht so gut geeignet ist, wenn Sie, wie weiter hinten erklärt, die
FPC-Erfassung verschlanken wollen.
5.5.3 Den Durchsatz an der Sensorschnittstelle mithilfe von
Sitzungsdaten berechnen
Die wahrscheinlich flexibelste Möglichkeit, Durchsatzstatistiken zu berechnen, bieten die
Sitzungsdaten. Im Folgenden sehen wir uns an einem Beispiel an, wie Sie das mit den
SiLK-Tools Rwfilter, Rwcount und Rwstats tun können.
Als Erstes wählen wir mit Rwfilter die Daten eines bestimmten Zeitintervalls aus. Am
einfachsten ist es, die Daten eines Geschäftstags zu erfassen:
rwfilter --start-date=2013/10/04 --proto=0- --type=all --pass=daily.rw
Durch diesen sehr einfachen Filter werden alle am 4. Oktober erfassten Sitzungsdaten
ausgewählt und in der Datei daily.rw gespeichert. Mit dem folgenden Befehl können Sie
sich eine Stichprobe der Daten in dieser Datei ansehen:
cat daily.rw | rwcut | head
5.5 Die FPC-Datenerfassung planen 157
Nun können wir ermitteln, wie viele Daten über die Verbindung übertragen wurden. Daher rufen wir Rwcount für die ausgewählten Daten auf:
cat daily.rw | rwcount --bin-size=60
Dieser Befehl leitet die gefilterte Datenmenge an das Tool Rwcount weiter, das einen Überblick darüber ausgibt, wie viele Daten pro Minute durch den Sensor laufen. Das Zeitintervall wird durch die Einstellung --bin-size bestimmt, die angibt, dass die Daten in
Abschnitte von je 60 s gegliedert werden sollen. Das Ergebnis sehen Sie in Abb. 5.5.
Abbildung 5.5: Datendurchsatz pro Minute außerhalb von Spitzenzeiten
In der Abbildung können Sie erkennen, dass wir in den ruhigen Zeiten um 0.00 Uhr UTC
(was 20.00 EST, also Ortszeit, entspricht) einen Durchsatz von ca. 1,5 GB pro Minute haben. In Abb. 5.6 wird deutlich, dass der Datenverkehr zu Spitzenzeiten, also um 17.00 UTC
(15.00 Uhr Ortszeit), auf 8 bis 9 GB pro Minute anwächst.
158 5 FPC-Daten
Abbildung 5.6: Datendurchsatz pro Minute in Spitzenzeiten
Um den durchschnittlichen Durchsatz an einem Tag zu bestimmen, erhöhen Sie zunächst
den Wert von --bin-size auf 86.400 s, sodass sämtliche Daten eines Tages in ein einziges
Intervall fallen:
cat daily.rw | rwcount --bin-size=86400
Das Ergebnis sehen Sie in Abb. 5.7.
Abbildung 5.7: Die Gesamtmenge der Daten an einem Tag
Insgesamt haben wir an diesem Tag ein Verkehrsaufkommen von 4.915.977.947.088,87
Byte. Um diese Zahl besser handhabbar zu machen, teilen wir sie dreimal durch 1024
(4.915.977.947.088,87 x 1024-3), sodass wir zu 4578,36 GB kommen. Um den durchschnittlichen Durchsatz des Tages zu bestimmen, müssen wir dieses Gesamtaufkommen
durch das gewünschte Zeitintervall teilen. Wenn Sie den Durchsatz in Bytes pro Minute
haben wollen, dividieren Sie den Wert durch 1440 Minuten. Für den Durchsatz in Bytes
pro Sekunde müssen Sie eine Division durch 86.400 Sekunden ansetzen. Die Ergebnisse
lauten 3,18 GB/Minute bzw. 54,26 MB pro Sekunde. Bei diesen Berechnungen wurden alle
Zahlen auf zwei Dezimalstellen gerundet.
5.6 Den Speicherbedarf für FPC-Daten senken 159
5.6
Den Speicherbedarf für FPC-Daten senken
Es wäre ideal, FPC-Daten für jeden Host, jeden Port und jedes Protokoll in Ihrem Netzwerk zu erfassen und lange Zeit zu speichern. In der Praxis gibt es jedoch Budgetgrenzen
und andere Einschränkungen, die das verhindern, sodass wir gezwungen sind, die Menge
der erfassten Daten zu verringern. Im Folgenden lernen Sie verschiedene Maßnahmen
kennen, um die Menge der aufbewahrten FPC-Daten zu verringern, sodass Sie den Speicherplatz für Zwecke des Network Security Monitoring bestmöglich ausnutzen können.
5.6.1 Dienste ausschließen
Die erste und einfachste Methode, die Menge der gespeicherten FPC-Daten zu verringern,
besteht darin, den von bestimmten Diensten generierten Datenverkehr auszuschließen.
Eine Möglichkeit, herauszufinden, welche Dienste sich dafür anbieten, besteht in der Verwendung von Rwstats. Dieses Tools zeigt ausführlich an, welchen Anteil die Daten über
einzelne Ports, Protokolle und Hosts am Gesamtumfang der FPC-Datenspeicherung haben. Eine ausführliche Beschreibung von Rwstats finden Sie in Kapitel 11, doch wir wollen
uns hier schon mit zwei Rwstat-Befehlen beschäftigen, mit denen wir die Ports bestimmen
können, an denen die größte Menge von ein- und ausgehendem Verkehr anfällt.
Als Erstes ermitteln wir mit Rwstats die Ports, die für den Großteil der eingehenden Kommunikation in unserem Netzwerk verantwortlich sind. Dazu verwenden wir folgenden
Befehl:
cat daily.rw | rwstats --fields=sport --top --count=5 --value=bytes
Dieser Befehl übergibt unsere ursprüngliche Datenmenge an Rwstats, das die ersten fünf
(--top --count=5) Quellports (--fields=sport) mit dem größten Aufkommen an Datenverkehr in Byte (--value=bytes) ermittelt. Das Ergebnis sehen Sie in Abb. 5.8.
Abbildung 5.8: Die kommunikationsintensivsten Quellports
Wie Sie sehen, fällt der Großteil des Datenverkehrs in diesem Netzwerksegment an Port
80 an, der für HTTP zuständig ist. Genauer gesagt, macht der HTTP-Datenverkehr 44 %
des Verkehrsaufkommens aus. Da der HTTP-Datenverkehr für die NSM-Erkennung
und -Analyse von unschätzbarem Wert ist, dürfen wir natürlich nicht darauf verzichten.
160 5 FPC-Daten
In der nächsten Zeile können Sie jedoch erkennen, dass mehr als 16 % der insgesamt
übertragenen Daten vom Quellport 443 ausgingen. Um uns einen Gesamtüberblick zu
verschaffen, sehen wir uns wie folgt auch die verkehrsreichsten fünf Zielports an:
cat daily.rw | rwstats --fields=dport --top --count=5 --value=bytes
Die Ausgabe dieses Befehls sehen Sie in Abb. 5.9.
Abbildung 5.9: Die kommunikationsintensivsten Zielports
Daraus können Sie ablesen, dass 4 % des Datenverkehrs an den TCP-Port 443 geht. Daraus
folgt, dass an 20,9 % des Datenverkehrs an dem untersuchten Geschäftstag über diesen
Port abgewickelt wurde. Wenn wir den TCP-Datenverkehr über Port 443 herausfiltern,
können wir damit die Aufbewahrung von FPC-Daten durchschnittlich um 20,9 % pro
Geschäftstag steigern.
Gewöhnlich schließen Organisationen auch verschlüsselte Daten im Rahmen der HTTPSKommunikation von der Erfassung aus. Die Headerinformationen der verschlüsselten Daten
und die zugehörigen Statistiken sind für Untersuchungen verwendbar, die verschlüsselten
Daten selbst jedoch meistens nicht. Das ist ein gutes Beispiel dafür, wie Sie eine wirtschaftlichere Speicherung von FPC-Daten erreichen können, indem Sie auf die Aufbewahrung von
Daten verzichten, die Ihnen ohnehin nicht weiterhelfen können.
Nachdem wir den Datenverkehr über TCP-Port 443 ausgeschlossen haben, können wir
unsere frühere Durchsatzberechnung wiederholen, um herauszufinden, wie stark die Verringerung ist. Dazu ändern wir die vorhandene Datenmenge, indem wir mit Rwfilter jeglichen TCP-443-Datenverkehr aus der Datei daily.rw ausschließen:
cat daily.rw | rwfilter --input-pipe=stdin --aport=443 --fail=stdout| rwcount
--bin-size=86400
Dieser Befehl übergibt die vorhandene Datenmenge daily.rw an einen weiteren Filter, der
alle Einträge mit dem Quell- oder Zielport 443 herausnimmt. Anschließend werden diese
bereinigten Daten an Rwcount übergeben, um eine gefilterte Statistik der Daten darzustellen, die die Sensorschnittstelle durchlaufen (siehe Abb. 5.10).
5.6 Den Speicherbedarf für FPC-Daten senken 161
Abbildung 5.10: Gesamtes Datenaufkommen des Tages ohne TCP-443-Datenverkehr
Diese Statistik gilt für die gleiche Datenmenge, allerdings unter Ausschluss des TCP-Verkehrs an Port 443. Bei der Berechnung des Durchsatzes kommen wir auf Werte von 2,52
GB/Minute bzw. 42,9 MB/s. Das Herausnehmen des TCP-443-Datenverkehrs hat also
tatsächlich zu einer Verringerung der Datengesamtmenge um ca. 20,9 % während eines
Geschäftstages geführt.
Auf die gleiche Weise können Sie auch bei anderen Ports vorgehen, die verschlüsselte Daten übertragen, z. B. für verschlüsselte VPN-Tunnel. Der Ausschluss verschlüsselter Daten
von der FPC-Datenerfassung mag nicht für jede Organisation geeignet sein, ist aber ein
gutes Beispiel dafür, wie Sie die Anforderungen für die FPC-Datenspeicherung verringern, indem Sie auf die Aufbewahrung der Daten für bestimmte Dienste verzichten. Das
zahlt sich auch später aus, wenn Sie die FPC-Daten durchgehen, um daraus die sekundären Datentypen zu erstellen, und wenn Sie sie zur Erkennung und Analyse untersuchen. Es
gibt aber weitere Möglichkeiten, die Speicherlast durch FPC-Daten zu verringern.
5.6.2 Kommunikation zwischen bestimmten Hosts ausschließen
Eine weitere Möglichkeit, die Menge der gespeicherten FPC-Daten zu verringern, besteht
darin, die Kommunikation zwischen bestimmten Hosts nicht aufzubewahren.
Da wir bereites wissen, wie stark der Datenverkehr durch den Verzicht auf die TCP443-Kommunikation reduziert wird, nehmen wir diese Daten gleich aus unserem nächsten Beispiel heraus. Wie Sie schon im vorherigen Beispiel gesehen haben, können wir alles
herausfiltern, was bestimmten Kriterien genügt. In diesem Beispiel nutzen wir das aus und
sehen uns nur die kommunikationsintensivsten Quell- und Zieladressen für den Datenverkehr an, der nicht über Port 443 läuft:
cat daily.rw | rwfilter --input-pipe=stdin --aport=443 --fail-=stdout| rwstats
--fields=sip,dip --top --count=5 --value=bytes
Dieser Befehl leitet unsere vorhandene Datenmenge durch einen Filter, der den gesamten
TCP-443-Datenverkehr entfernt, und übergibt die Daten dann an Rwstats, das die kommunikationsintensivsten Paare von Quell- und Zieladressen (--fields=sip,dip) nach der
übertragenen Datenmenge in Byte (--value=bytes) bestimmt. Das Ergebnis sehen Sie in
Abb. 5.11.
162 5 FPC-Daten
Abbildung 5.11: Die kommunikationsintensivsten Paare von IP-Adressen
Wie Sie sehen, erfolgen 19 % der Kommunikation in diesem Netzwerksegment zwischen
den Hosts mit den Adressen 141.239.24.49 und 200.7.118.91. Um zu bestimmen, ob die
Kommunikation zwischen diesen Geräten ein guter Kandidat für den Ausschluss aus der
FPC-Datenerfassung ist, müssen Sie jedoch noch etwas mehr nachforschen. Im Idealfall
haben Sie Informationen über den internen Host, für den Sie verantwortlich sind, und
können den Dienst identifizieren, der für das hohe Aufkommen an Datenverkehr sorgt.
Eine Möglichkeit, das mit Rwstats zu tun, bietet folgende Abfrage:
cat daily.rw | rwfilter --input-pipe=stdin --saddress=141.239.24.49
--daddress=200.7.118.91 --pass=stdout| rwstats --fields=sport
--top --count=10 --value=bytes
Das Ergebnis sehen Sie in Abb. 5.12.
Abbildung 5.12: Die Kommunikation zwischen zwei Hosts untersuchen
Demnach tritt die gesamte Kommunikation an Port 22 auf. Unter der Voraussetzung, dass
es sich um eine rechtmäßige Verbindung handelt, bedeutet das, dass es ein SSH-VPN zwischen den beiden Geräten gibt. Falls Sie nicht in der Lage sind, diesen Datenverkehr zu
entschlüsseln und zu überwachen (z. B. durch einen zwischengeschalteten Proxy), dann
ist diese Verbindung ein guter Kandidat dafür, von der FPC-Datenerfassung ausgeschlossen zu werden. Den gezeigten Vorgang können Sie anschließend für andere kommunikationsintensive Hosts im Netzwerk wiederholen.
Mit den vorgestellten Verfahren haben wir die Menge der zu speichernden FPC-Daten um
ca. 40 % verringert, was bedeutet, dass der Sensor 40 % mehr brauchbare Daten aufbewahren kann. Leider können wir keine allgemein gültigen Beispiele für die Dinge anführen, die Sie in jedem Netzwerk aus der FPC-Datenspeicherung herausnehmen können,
5.7 Die Aufbewahrung der FPC-Daten verwalten 163
da dies je nach Netzwerk und nach den Zielen der Organisation sehr unterschiedlich sein
kann. Wenn Sie die Anleitungen aus Kapitel 2 zur Planung der Datenerfassung befolgen,
kann Ihnen das jedoch bei diesen Entscheidungen helfen.
Vorsicht
Zu Beginn dieses Kapitels haben wir gesagt, dass häufig viele andere Datentypen
aus FPC-Daten abgeleitet werden, beispielsweise PSTR-Daten. Wenn das in Ihrer Umgebung der Fall ist, dann müssen Sie dies bedenken, wenn Sie bestimmte
Arten von Daten aus der FPC-Erfassung herausnehmen. Nehmen wir beispielsweise an, Sie gewinnen aus den FPC-Daten PSTR-Daten. Wenn Sie dann den Datenverkehr über Port 443 ausschließen, können Sie keine Paketstrings für den
HTTPS-Handshake generieren, was zu einem blinden Fleck in Ihrer Sicht auf
das Netzwerk führt. Bei beschränktem Platz lässt sich das möglicherweise nicht
vermeiden, aber wenn Sie diese PSTR-Daten trotzdem aufbewahren möchten,
müssen Sie eine andere Möglichkeit finden, sie zu gewinnen, etwa indem Sie sie
über einen anderen Prozess direkt an der Verbindung erfassen.
5.7
Die Aufbewahrung der FPC-Daten verwalten
Da FPC-Daten pro Sekunde mehr Festplattenplatz verbrauchen als andere Datentypen,
steht zu befürchten, dass sie Ihren Sensor überlasten, wenn Sie die Aufbewahrung und das
Überschreiben älterer Daten nicht richtig einrichten. Ich habe selbst in erfahrenen Organisationen Situationen erlebt, in denen die FPC-Daten beim Auftreten von Datenspitzen schneller auf die Festplatte geschrieben wurden, als sie gelöscht werden konnten. Das
kann eine ganze Reihe übler Auswirkungen haben. Sie sollten die FPC-Daten auf einem
anderen Volume als dem Betriebssystem unterbringen, um das Schlimmste zu verhindern.
Aber auch wenn die FPC-Daten auf einem freigegebenen, dynamisch erweiterten virtuellen Datenträgern abgelegt werden, kann eine anhaltende Spitze dazu führen, dass andere
virtuelle Geräte der erforderlichen Ressourcen beraubt werden, was letzten Endes einen
Systemabsturz verursachen kann. Es gibt Dutzende von möglichen Vorfällen, die zu den
berüchtigten Anrufen des Systemadministrators um 2 Uhr morgens führen. Da niemand
gern einen solchen Anruf tätigen möchte, beschäftigen wir uns in diesem Abschnitt mit
der Verwaltung von FPC-Daten, und zwar insbesondere mit dem Entfernen alter Daten.
Es gibt verschiedene Möglichkeiten zur Verwaltung von FPC-Daten. Was wir uns im
Folgenden ansehen werden, ist eine einfache Vorgehensweise, für die nur Werkzeuge gebraucht werden, die in den meisten Linux-Distributionen enthalten sind. Diese Tools sind
nicht nur sehr wirkungsvoll, es lassen sich auch sehr einfach Skripte dafür erstellen. Einige
der hier beschriebenen Techniken mögen vielleicht nicht ganz passend für Ihre Umgebung sein, aber sie lassen sich relativ leicht anpassen.
164 5 FPC-Daten
Wir haben bereits zwei Aufbewahrungsstrategien für FPC-Daten kennengelernt, nämlich
die Aufbewahrung nach Zeit und nach Umfang. Dafür gibt es auch jeweils eigene Verwaltungsmethoden.
5.7.1
Aufbewahrung nach Zeit
Die Aufbewahrung nach Zeit lässt sich sehr einfach und automatisch verwalten. Das
­Linux-Dienstprogramm find kann Dateien aufspüren, die vor einer bestimmten Zeit zum
letzten Mal geändert wurden. Um beispielsweise alle Dateien im Verzeichnis /data/pcap/
zu finden, die älter als 60 Minuten sind, müssen Sie lediglich folgenden Befehl ausführen:
find /data/pcap -type f -mtime +60
Mithilfe dieses Befehls könne Sie eine Liste der PCAP-Dateien aufstellen, die gelöscht werden sollen. Um die Daten, die das Kriterium erfüllen, automatisch zu entfernen, kombinieren Sie den Befehl mit xargs. Mit der folgenden einfachen Zeile löschen Sie jegliche
Daten, die älter als 60 Minuten sind:
find /data/pcap -type f -mtime +60 | xargs -i rm {}
5.7.2 Aufbewahrung nach Umfang
Bei der Aufbewahrung nach Umfang ist die Verwaltung etwas schwieriger. Bei dieser
Methode werden die ältesten PCAP-Dateien gelöscht, sobald das Speichervolumen einen bestimmten Prozentsatz des Festplattenplatzes übersteigt. Je nachdem, wie Sie die
FPC-Datenerfassung eingerichtet haben, kann es ziemlich knifflig sein, dies umzusetzen.
Daemonlogger kann diese Art der Datenbereinigung selbstständig vornehmen, aber wenn
Sie ein Werkzeug einsetzen, dass nicht über diese Funktion verfügt, müssen Sie etwas
mehr Gehirnschmalz aufwenden.
Eine Möglichkeit besteht darin, ein bash-Skript wie das folgende zu verwenden:
#!/bin/bash
## Dieses Skript löscht PCAP-Daten, wenn ihr prozentualer Anteil am insgesamt
## verfügbaren Speicherplatz den vordefinierten Grenzwert erreicht. Der
## Einheitlichkeit halber wird für alle PCAP-Datenquellen derselbe Grenzwert
## verwendet. Die Einstellungen finden Sie im Konfigurationsabschnitt am Ende
## des Skripts.
5.7 Die Aufbewahrung der FPC-Daten verwalten 165
# Beispielkonfiguration
## Konfiguration der Datenlöschung
#dir="/data/pcap/eth1/"
#percentage=1
#datamanage $dir $percentage
#dir="/data/pcap/eth2/"
#percentage=3
#datamanage $dir $percentage
##################################################################
## FUNKTION #######################################################
##################################################################
totaldiskspace=$(df | grep SOsensor-root | awk '{print $2}')
function datamanage {
# Erste Datenbewertung
datadirectory="$1"
datapercent="$2"
datasize=$(du -s $datadirectory | awk '{print $1}')
diskstatus=$(df | grep SOsensor-root | awk '{print $5}' | egrep
-o '[0-9]{1,3}')
datapercentusage=$(echo "scale=2; $datasize / $totaldiskspace
* 100" | bc | sed 's/\..*//g')
echo "Data usage in $datadirectory is at $datapercentusage% of
hard drive capacity)"
# Prozedur zur Datenlöschung
while [ "$datapercentusage" -gt "$datapercent" ]; do
filestodelete=$(ls -tr1 $datadirectory | head -20)
printf %s "$filestodelete" | while IFS=read -r ifile
do
echo $ifile
if [ -z $datadirectory$ifile ]; then
exit
fi
echo "Data usage in $data directory ($datapercentusage%) is greater
than your desired amount ($datapercent% of hard drive)"
echo "Removing $datadirectory$ifile"
sudo rm -rf $datadirectory$ifile
du -s $datadirectory
#
datasize=$(du -s $datadirectory | awk '{print $1}')
done
datasize=$(du -s $datadirectory | awk '{print $1}')
166 5 FPC-Daten
datapercentusage=$(echo “scale=2; $datasize / $totaldiskspace * 100” |
bc | sed ‘s/\..*//g’)
du -s $datadirectory
datasize=$(du -s $datadirectory | awk ‘{print $1}’)
datapercentusage=$(echo "scale=2; $datasize / $totaldiskspace * 100" |
bc | sed 's/\..*//g')
done
}
# Konfiguration der Datenlöschung
pidofdiskclean=$(ps aux | grep diskclean.sh | wc -l)
echo $pidofdiskclean
if [ "$pidofdiskclean" -le "4" ]; then
dir="/data/pcap/eth1/"
percentage=40
datamanage $dir $percentage
dir="/data/pcap/eth2/"
percentage=40
datamanage $dir $percentage
wait
echo ""
fi
Um dieses Skript nutzen zu können, müssen Sie den Namen des Volumes angeben, auf
dem die Daten gespeichert werden sollen. Dazu bearbeiten Sie die Variable dir. Außerdem
müssen Sie im Konfigurationsabschnitt am Ende des Skripts die Verzeichnisse angeben, in
denen die PCAP-Daten gespeichert sind, sowie den Betrag an leerem Pufferplatz, den Sie
auf dem Volume vorhalten möchten.
Anhand dieser Variablen bestimmt das Skript den Prozentsatz des verfügbaren Speicherplatzes, den die Daten einnehmen. Übersteigt dieser Prozentsatz den zulässigen Grenzwert, entfernt das Skript die ältesten Dateien, bis wieder eine akzeptable Nutzung des
Speicherplatzes erreicht ist.
Dieses Skript können Sie mit einem cron-Job regelmäßig ausführen lassen, sei es stündlich,
alle zehn Minuten oder gar alle 60 Sekunden. Wie oft Sie das Skript ausführen müssen,
hängt davon ab, wie viel Speicherplatz Sie freihalten wollen und wie groß der Durchsatz
ist. Wenn Sie bei hohem Durchsatz nur 5 % Reserveplatz einräumen, müssen Sie das Skript
praktisch permanent ausführen, damit die Festplatte bei Spitzen nicht gefüllt wird. Haben
Sie dagegen eine Reserve von 30 % und nur wenig Durchsatz auf der überwachten Verbindung, kann es ausreichen, dass Skript nur stündlich auszuführen.
In dem erstgenannten Fall, also bei starker Belastung des Sensors und stark eingeschränktem
Pufferplatz, kann es vorkommen, dass der cron-Job nicht schnell genug ausgeführt wird, um
5.7 Die Aufbewahrung der FPC-Daten verwalten 167
die ältesten Dateien zu löschen. Selbst wenn Sie das Skript kontinuierlich ausführen, etwa
über einen Ruhezustandstimer, besteht die Gefahr, dass das Skript bei der Berechnung der
Festplattenbelegung zu langsam ist. Daher ist es oft am besten, das Skript bei einem Übersteigen des Grenzwerts gleich die zehn ältesten Dateien löschen zu lassen statt nur eine. Das
kann die Leistung des Skripts erheblich verbessern, führt aber zu einer (leichten) Verringerung der Aufbewahrungsdauer. Das folgende Skript geht auf diese Weise vor:
#!/bin/bash
#!/bin/bash
## Dieses Skript löscht PCAP-Daten, wenn ihr prozentualer Anteil am insgesamt
## verfügbaren Speicherplatz den vordefinierten Grenzwert erreicht. Der
## Einheitlichkeit halber wird für alle PCAP-Datenquellen derselbe Grenzwert
## verwendet. Die Einstellungen finden Sie im Konfigurationsabschnitt am Ende
## des Skripts.
# Beispielkonfiguration
## Konfiguration der Datenlöschung
#dir="/data/pcap/eth6/"
#percentage=1
#datamanage $dir $percentage
#dir="/data/pcap/eth7/"
#percentage=3
#datamanage $dir $percentage
##################################################################
## FUNKTION #######################################################
##################################################################
totaldiskspace=$(df | grep SOsensor-root | awk '{print $2}')
function datamanage {
# Initial data evaluation
datadirectory="$1"
datapercent="$2"
datasize=$(du -s $datadirectory | awk '{print $1}')
diskstatus=$(df | grep SOsensor-root | awk '{print $5}' | egrep -o '[0-9]
{1,3}')
datapercentusage=$(echo "scale=2; $datasize / $totaldiskspace * 100" |
bc | sed 's/\..*//g')
echo "Data usage in $datadirectory is at $datapercentusage% of hard
drive capacity)"
168 5 FPC-Daten
# Data Removal Procedure
while [ “$datapercentusage” -gt “$datapercent” ]; do
filestodelete=$(ls -tr1 $datadirectory | head - 10)
echo $filestodelete
printf %s “$filestodelete” | while IFS=read -r ifile
do
echo $ifile
if [ -z $datadirectory$ifile ]; then
exit
fi
echo "Data usage in $datadirectory ($datapercentusage%) is greater
than your desired amount ($datapercent% of hard drive)"
echo "Removing $datadirectory$ifile"
sudo rm -rf $datadirectory$ifile
done
datasize=$(du -s $datadirectory | awk '{print $1}')
datapercentusage=$(echo "scale=2; $datasize /
$totaldiskspace * 100" | bc | sed 's/\..*//g')
done
}
# Konfiguration der Datenlöschung
pidofdiskclean=$(ps aux | grep diskclean.sh | wc -l)
echo $pidofdiskclean
if [ "$pidofdiskclean" -le "4" ]; then
# Konfiguration der Datenlöschung
dir='/data/pcap/eth1/'
percentage=10
datamanage $dir $percentage
dir="/data/pcap/eth2/"
percentage=10
datamanage $dir $percentage
wait
fi
Es kann sein, dass diese Codebeispiele nicht unmittelbar in Ihrer Umgebung anwendbar
sind, aber sie bieten sicherlich eine Grundlage, die Sie an Ihre Bedürfnisse der Datenerfassung anpassen können. Schauen Sie sich auch die Skripte an, mit denen Security Onion
die Aufbewahrung von Paketdaten verwaltet. Diese Skripte nutzen ähnliche Techniken,
setzen sie aber in leicht abweichender Weise ein.
5.8 Zusammenfassung 169
5.8
Zusammenfassung
FPC-Daten geben Ihnen die gründlichste und umfassendste Darstellung von Netzwerkdaten, die Sie erfassen können. Sie sind schon für sich genommen äußerst nützlich, aber
ihr Wert steigt noch dadurch, dass viele andere Datentypen von ihnen abgeleitet werden
können. In diesem Kapitel haben wir uns verschiedene Technologien angesehen, um FPCDaten zu erfassen und zu speichern. Wir haben auch verschiedene Techniken zur effizienten Erfassung von FPC-Daten, zur Reduzierung der Menge von erfassten FPC-Daten und
zur Löschung alter Daten angesehen. Im Rest des Teils über die Datenerfassung wollen wir
uns nun damit beschäftigen, wie Sie aus diesen FPC-Daten andere Datentypen gewinnen
können.
6
Paketstringdaten
Viele NSM-Teams sehen sich dem Problem gegenüber, dass bei einer rückblickenden Analyse – also nach mehreren Tagen – keine ausreichenden Datenmengen für eine sinnvolle
Untersuchung mehr vorhanden sind. Im Idealfall erfasst eine Organisation sowohl FPCals auch Sitzungsdaten, doch leider weisen Sitzungsdaten nicht den Detaillierungsgrad
auf, um mit ihrer Hilfe genau zu bestimmen, was bei dem Netzwerkverkehr im Einzelnen
geschehen ist, während die FPC-Daten aufgrund ihrer Anforderungen an den Speicherplatz nicht länger als wenige Tage oder allerhöchstens zwei Wochen aufbewahrt werden,
sodass sie für eine rückblickende Analyse nicht zur Verfügung stehen.
Daher kann es vorkommen, dass wir Daten aus einem Zeitraum untersuchen müssen, für
den die Aufbewahrungszeit der FPC-Daten längst abgelaufen ist, sodass uns nur Sitzungsdaten zur Verfügung stehen, die aber viele Frage unbeantwortet lassen. Beispielsweise ist
es nur mithilfe von Sitzungsdaten nicht möglich, folgende Aufgaben durchzuführen, die
bei einer rückblickenden Analyse häufig erforderlich sind:
•• Einen HTTP-Benutzeragenten identifizieren, der zu einem neu ermittelten Angreifer
gehört
•• Die Benutzer ermitteln, die eine Phishing-E-Mail erhalten haben, mit deren Hilfe ein
Einbruch erfolgte
•• Nach Dateidownloads suchen, die nach kürzlich erkannten und möglicherweise gefährlichen HTTP-Anforderungen erfolgten
172 6 Paketstringdaten
Eine Lösung für dieses Problem besteht darin, Paketstringdaten (PSTR) zu erfassen. In
diesem Kapitel sehen wir uns an, was PSTR-Daten sind und wie sie manuell oder mit
Tools wie Httpry und Justniffer erfasst werden können. Der Erfassungsvorgang ist zwar
einfach und die Daten selbst sind sehr vielseitig nutzbar, aber das Prinzip ist relativ neu,
sodass es noch nicht viele Organisationen gibt, die diesen Datentyp verwenden. Da sie einerseits ebenso viele Kontextinformationen liefern wie FPC-Daten, andererseits aber auch
den Geschwindigkeitsvorteil, die geringeren Speicheranforderungen und die statistische
Analysierbarkeit von Sitzungsdaten bieten, stellen sie den besten Kompromiss zwischen
FPC- und Sitzungsdaten dar, der sich sowohl für die Echtzeit- als auch die rückblickende
Analyse erzielen lässt.
6.1
Was sind Paketstringdaten?
Wie Sie »Paketstringdaten« definieren, hängt gewöhnlich davon ab, wie Sie sie verwenden. Grob gesagt, handelt es sich um eine Auswahl von wichtigen, für Menschen lesbaren
Daten aus den vollständigen FPC-Daten. Diese Daten können unterschiedliche Formen
annehmen. Manche Organisationen generieren PSTR-Daten in einem bestimmten Format, um damit die Headerdaten gebräuchlicher Protokolle der Anwendungsschicht (wie
HTTP und SMTP) ohne die unnötigen Payloaddaten darzustellen. Ich habe hier bewusst
»unnötig« gesagt, da es bei der Analyse von PSTR-Daten nicht darum geht, Dateien zu
extrahieren oder den Datenverkehr Byte für Byte zu untersuchen, sondern um den Analytikern eine Momentaufnahme der Daten zu präsentieren, anhand der sie die Fragen klären
können, die bei der rückblickenden Analyse aufgetreten sind. Ein Beispiel dieser Art von
PSTR-Daten sehen Sie in Abb. 6.1.
Abbildung 6.1: PSTR-Protokolldaten, die eine HTTP-Anforderung und -Antwort zeigen
6.1 Was sind Paketstringdaten? 173
Diese Abbildung gibt ein Beispiel für die Daten, die gewöhnlich für die rückblickende
Analyse verwendet werden. Die beiden PSTR-Datensätze zeigen die vollständigen Anforderungs- und Antwortheader für eine einzelne HTTP-Kommunikationssequenz. Die Datenerfassung in diesem Beispiel ist ziemlich umfassend und speichert eine große Menge
der Informationen aus den Headern der Anwendungssschicht. In dem Beispiel aus Abb.
6.2 dagegen wird nur ein einziges Feld gespeichert.
Abbildung 6.2: PSTR-Protokolldaten, die nur den angeforderten URL zeigen
In diesem Beispiel werden nur die HTTP-URL-Anforderungen als PSTR-Daten gespeichert. Viele Organisationen bewahren PSTR-Daten zunächst nur für die rückblickende
Analyse auf, doch in diesem Beispiel werden sie in beinahe Echtzeit erfasst. Dadurch können die Daten mehreren Zwecken dienen, unter anderem auch für automatische reputationsbasierte Erkennungsmechanismen, wie wir sie in Kapitel 8 betrachten werden. Damit
lässt sich die gleiche Aufgabe viel schneller erledigen als mit der Untersuchung von FPCDaten.
Eine dritte mögliche Variante besteht darin, sich ganz auf die Payloaddaten des Pakets zu
konzentrieren, die auf den Header der Anwendungsschicht folgen. Dabei wird eine eingeschränkte Menge von Nichtbinärbytes der Payload erfasst, um eine Vorstellung von dem
Zweck des Pakets zu gewinnen. Einfach ausgedrückt: Stellen Sie sich vor, Sie würden das
Unix-Werkzeug strings auf Paketdaten anwenden.
Ein Beispiel für diese Art von Daten sehen Sie in Abb. 6.3. Es handelt sich dabei um eine
Momentaufnahme der für Menschen lesbaren Daten, die bei den Surfvorgängen eines Benutzers aufgetreten sind. Insbesondere können Sie erkennen, welche Seite besucht wurde,
wobei jedoch nicht sehr viele Einzelheiten angegeben sind. Da nicht lesbare Zeichen gar
nicht erst gespeichert werden, ermöglicht dies eine wirtschaftliche Datenspeicherung. Der
Nachteil besteht jedoch in dem Zusatzaufwand, den die Generierung von PSTR-Payloaddaten erfordert. Außerdem werden dabei auch eine Menge überflüssiger Daten erfasst,
denn nur weil sich ein Byte in ein lesbares ASCII-Zeichen übersetzen lässt, muss es noch
lange keinen Sinn ergeben. Das können Sie an der Menge der zufälligen Zeichen erkennen,
mit denen die Anzeige in der Abbildung übersät ist. Die Speicherung dieser zusätzlichen,
aber unnützen Bytes stellt eine überflüssige Belastung dar. Des Weiteren gibt es nur wenige
rationelle Methoden, um PSTR-Payloaddaten zu generieren, weshalb Sie fast immer auf
selbst geschriebene Skripte oder andere Hilfsprogramme zurückgreifen müssen. Daher
kommt das Kosten/Nutzen-Verhältnis dieser Daten nicht unbedingt dem anderer Daten-
174 6 Paketstringdaten
typen gleich, die mit einfacheren Werkzeugen generiert werden können. Das beste Kosten/
Nutzen-Verhältnis bei mehrzeiligen PSTR-Formaten erzielen Sie mit Protokolldaten wie
denen mit den Anforderungs- und Antwortheadern in Abb. 6.1.
Abbildung 6.3: PSTR-Payloaddaten
6.2
PSTR-Datenerfassung
Wir haben uns bereits mit der FPC-Datenerfassung beschäftigt, und da FPC für »full packet capture« steht, könnten wir PSTR-Daten als »partial packet capture«, also als eine
Teilerfassung von Paketen ansehen. Daher ist es nicht überrraschend, dass manche Organisationen die PSTR-Daten aus den ohnehin schon erfassten FPC-Daten gewinnen. Es
ist jedoch auch möglich, PSTR-Daten auf ähnliche Weise die FPC-Daten direkt an dem
überwachten Port eines Sensors zu erfassen.
Wie auch immer Sie vorgehen, so ist es doch von großem Vorteil, die Erfassung an derselben Quelle durchzuführen wie die der anderen Daten, also auf dem NSM-Sensor. Dadurch vermeiden Sie Korrelationsfehler bei der Analyse. So habe ich beispielsweise schon
Organisationen gesehen, die ihre PSTR-Daten über die HTTP-Kommunikation von Gerä-
6.2 PSTR-Datenerfassung 175
ten zur Filterung von Webinhalten bezogen. Dabei kann es geschehen, dass das Segment,
das der Webfilter beobachtet, nicht mit dem NSM-Sichtfeld übereinstimmt, für das sich
die Analytiker interessieren, weshalb die Daten nichts zur Analyse beitragen können. Außerdem haben Sie die volle Kontrolle über die PSTR-Daten, wenn Sie sie auf Ihrem NSMSensor erfassen oder generieren. Falls Sie die Daten von einem anderen Gerät beziehen,
insbesondere dem eines Drittanbieters, müssen Sie sich mit den Daten zufrieden geben,
die der betreffende Hersteller zur Verfügung stellt, da die Daten intern schon einer nicht
offensichtlichen Filterung unterzogen werden können. Wie bei allen NSM-Daten müssen
Sie auch bei der Erstellung und Untersuchung von PSTR-Daten eine schon paranoide
Wachsamkeit an den Tag legen.
Bevor wir mit der Erfassung oder Generierung von PSTR-Daten beginnen können, müssen
wir einige Überlegungen anstellen. Erstens müssen Sie den Umfang der zu erfassenden
PSTR-Daten abschätzen. Im Idealfall erfassen Sie so viele der wichtigen Anwendungsschichtdaten aus Klartextprotokollen, wie die Möglichkeiten zur langfristigen Speicherung
zulassen. Da es verschiedene Arten von PSTR-Daten gibt, kann auch der erforderliche
Speicherplatz dafür stark schwanken. Wenden Sie daher eine der Methoden aus Kapitel 3
an, um anhand des gewählten Datenformats und Ihrer Netzwerkgeräte zu bestimmen, wie
viel Platz Sie wahrscheinlich für die PSTR-Daten benötigen werden. Dazu müssen Sie einen temporären Sensor mit installierten Tools zur Erfassung bzw. Generierung von PSTR-­
Daten bereitstellen, sodass Sie Stichproben der Daten zu verschiedenen Zeiten nehmen
und auf längere Zeiträume extrapolieren können. Dabei kann es vorkommen, dass Sie den
gewünschten Umfang der PSTR-Daten anpassen müssen, um die Daten länger aufbewahren zu können.
Sie müssen nicht nur entscheiden, welche Arten von PSTR-Daten erstellt werden sollen,
sondern auch, wie lange Sie sie aufbewahren möchten. Die Aufbewahrung von FPC-Daten
zählt oft nach Stunden oder Tagen, während Sitzungsdaten gewöhnlich für ganze Quartale oder gar Jahre gespeichert werden. Die Aufbewahrungszeiten für PSTR-Daten liegen in
der Mitte und belaufen sich auf Wochen oder Monate.
Wenn Sie den Speicherbedarf für PSTR-Daten bestimmen, müssen Sie daran denken,
dass große Schwankungen auftreten können. Beispielsweise können Sie während der
Mittagspausen Spitzenwerte bei der HTTP-Kommunikation feststellen, während der
Datenverkehr über Protokolle, die stärker mit geschäftlichen Vorgängen verknüpft sind,
zurückgeht. Das muss sich nicht unbedingt auf die Gesamtmenge der PCAP-Daten auswirken, die während dieser Zeit erfasst werden, wird aber die Menge der PSTR-Daten
merkbar erhöhen.
Es gibt eine Reihe von kostenlosen und Open-Source-Anwendungen sowohl für die direkte Erfassung von PSTR-Daten an einer Schnittstelle als auch für ihre Generierung aus
FPC-Daten. Bei der Auswahl der entsprechenden Software müssen Sie sicherstellen, dass
die resultierenden Daten auf solche Weise standardisiert sind, dass Sie sie für Ihre Erkennungs- und Analysetools und -prozesse nutzen können. Im Rest dieses Abschnitts sehen
wir uns einige dieser Erfassungs- und Generierungswerkzeuge an.
176 6 Paketstringdaten
6.2.1 PSTR-Daten manuell generieren
Bevor wir einige Werkzeuge zur automatischen Generierung von PSTR-Daten unter die
Lupe nehmen, wollen wir alternative Möglichkeiten ansehen, um PSTR-Daten mithilfe
der Tools zu generieren, die in der Bash-Umgebung von Linux vorhanden sind. Als Ausgangspunkt verwenden wir die ASCII-Daten aus einer PCAP-Datei. Da wir nur an Daten
interessiert sind, die aus für Menschen lesbaren Zeichen bestehen, grenzen wir die Auswahl ein, indem wir die Daten an das Linux-Dienstprogramm strings übergeben. Aus
dem Ergebnis können wir nun verschiedene Arten von PSTR-Daten generieren, beispielsweise Protokoll- oder Payloaddaten.
Das folgende Skript erstellt Protokolldaten ähnlich wie in Abb. 6.2, wobei in den einzelnen
Zeilen die URIs der vom Benutzer angeforderten Seiten aufgeführt werden.
#!/bin/bash
# Sendet ASCII-Zeichen aus den FPC-Daten an stdout
/usr/sbin/tcpdump -qnns 0 -A -r test.pcap | \
# Normalisiert die PCAP-Daten
strings |\
# Entfernt alle Zeitstempelheader und Host-Felder
grep -e '[0\-9][0\-9]\:[0\-9][0\-9]\:[0\-9][0\-9].[0\-9]\{6\}\|
Host:'| grep -B1 "Host:" |\
# Bereinigt die Ergebnisse
grep -v -- "--"| sed 's/\(Host.*$\)/\1\n/g'| \
tr "\n" "-" | sed 's/--/\n/g'| sed 's/-Host:/ -/g'
Das folgende Payloadskript erzeugt PSTR-Daten, deren Datensätze durch Bindestriche
getrennt sind. In diesem Beispiel werden alle lesbaren Strings für sämtliche Protokolle
entnommen. Es gibt zurzeit nur wenige Möglichkeiten, solche Daten auf andere Weise als
manuell zu generieren.
#!/bin/bash
# Sendet ASCII-Zeichen aus den FPC-Daten an stdout
/usr/sbin/tcpdump -qnns 0 -A -r test.pcap |\
# Normalisiert die PCAP-Daten
strings |\
# Entfernt alle leeren Zeilen
sed '/°$/d' |\
6.2 PSTR-Datenerfassung 177
# Ersetzt die Leerzeilen zwischen den Datensätzen durch Trennzeichen
sed 's/˄$/\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\\-\-\-/g' |\
#Entfernt doppelte Sonderzeichen
sed 's/[˄[:alnum:][:space:]_():-]\+/./g'
Solche manuellen Lösungen sind bei der Verarbeitung der Daten gewöhnlich langsamer,
aber dafür haben Sie unbegrenzte Verarbeitungsmöglichkeiten für die eingehenden Daten. Als Nächstes sehen wir uns einige der Tools an, mit denen sich PSTR-Protokolldaten
effizient generieren lassen.
6.2.2 URLsnarf
Die Dsniff-Suite ist eine Sammlung von Tools, die für Zwecke der Netzwerksicherheit
sehr nützlich sein können. Die einzelnen Werkzeuge fallen dabei in zwei Kategorien: Die
einen dienen eher offensiven Zwecken, während es sich bei dem Rest – und das ist der
Teil, den wir benötigen – um Snarf-Tools handelt, mit denen Sie das Netzwerk passiv auf
interessante Informationen im Zusammenhang mit Dateien, E-Mails, Webanforderungen
usw. überwachen können. In diesem Buch beschäftigen wir uns vor allem mit URLsnarf.
URLsnarf sammelt passiv HTTP-Anforderungsdaten und speichert sie im allgemeinen
Protokollformat CLF. Die Dsniff-Suite habe ich sehr liebgewonnen, da es die Werkzeuge
schon lange gibt und sehr leicht zu installieren und anzuwenden sind. URLsnarf ist dabei
keine Ausnahme. Meistens können Sie Dsniff einfach über ihre bevorzugte Paketverwaltung installieren. Da die Suite in Security Onion nicht standardmäßig installiert ist, können Sie das mit apt nachholen:
sudo apt-get install dsniff
Anschließend können Sie die Installation von URLsnarf prüfen, indem Sie den Befehl
urlsnarf ohne Argumente geben. URLsnarf lauscht dann passiv an einer Schnittstelle und
übergibt die erfassten Daten an die Standardausgabe, wobei sie im Terminal-Fenster sichtbar werden. Standardmäßig lauscht das Programm an der Schnittstelle eth0. Die Überwachung des Datenverkehrs an den TCP-Ports 80, 8080 und 3128 ist hartkodiert.
Für URLsnarf gibt es nur vier Optionen:
••
••
••
••
-p: Führt URLsnarf für eine bereits erfasste PCAP-Datei aus.
-i: Gibt die Netzwerkschnittstelle an.
-n: Durchsucht die Daten, ohne DNS-Adressen aufzulösen.
-v <Ausdruck>: Standardmäßig können Sie zur Laufzeit einen Ausdruck angeben, sodass nur URLs angezeigt werden, die mit diesem Ausdruck übereinstimmen. Wenn
Sie die Option -v verwenden, werden dagegen alle URLs ausgegeben, die nicht dem
Ausdruck entsprechen.
178 6 Paketstringdaten
Ich finde es einfacher, die Ausgabe an BASH-Befehlszeilentools wie grep, cut und awk zu
übergeben, anstatt Ausdrücke mit -v anzugeben. In Abb. 6.4 habe ich zunächst den Datenverkehr mit Tcpdump erfasst und dann mit der Option -p an URLsnarf übergeben. Es ist
zwar nicht erforderlich, auf diese Weise vorzugehen, aber in einer Produktionsumgebung
werden Sie häufig bereits vorhandene FPC-Daten verwenden. Wenn Sie die Option -p
weglassen, werden die Daten direkt an der Verbindung erfasst.
Abbildung 6.4: Beispieldaten von URLsnarf
Die Ausgabe, die Sie in Abb. 6.4 sehen, besteht aus einem Satz von Standardprotokoll­
daten mit ausführlichen Angaben zu den HTTP-Anforderungen während meines Besuchs auf appliednsm.com. Auf den ersten Blick scheint dieses Tool zu nicht mehr nütze
zu sein, als Protokolldaten für die rückblickende Analyse zu speichern. Mithilfe von
geschicktem »Befehlszeilen-Kung-Fu« können Sie diese Ausgabe auch zu einer ernsthaften Live-Untersuchung des Benutzerdatenverkehrs in einem umfangreichen Netzwerk
verwenden.
URLsniff ist zwar sehr einfach zu benutzen, doch diese Einfachheit kann auch ein Problem darstellen. Wenn Sie eine weniger umfangreiche Ausgabe wünschen, müssen Sie die
Daten mit einem zusätzlichen Tool bearbeiten. Wollen Sie dagegen noch mehr Informationen, haben Sie Pech, denn im Gegensatz zu anderen Programmen ist eine mehrzeilige
Datenausgabe in URLsnarf nicht möglich.
6.2.3 Httpry
Httpry ist ein auf die Anzeige und Protokollierung von HTTP-Datenverkehr spezialisierter
Paketsniffer. Er kann ausschließlich HTTP-Datenverkehr erfassen, bietet im Vergleich zu
URLsnarf aber viel mehr Optionen für den Umgang mit den Daten. Beispielsweise können Sie eine beliebige Auswahl von HTTP-Headern erfassen und in beliebiger Reihenfolge
ausgeben. Darüber hinaus lassen sich die PSTR-Daten an die Bedürfnisse Ihrer Umgebung
anpassen. Aufgrund dieser zusätzlichen Anpassungs- und Nachbearbeitungsmöglichkeiten
kostet es jedoch etwas mehr Mühe, den Umgang mit Httpry zu erlernen.
6.2 PSTR-Datenerfassung 179
Standardmäßig ist Httpry in Security Onion nicht enthalten, es kann aber ziemlich leicht
installiert werden, indem man die Anwendung aus dem Quellcode erstellt. Dazu gehen Sie
folgendermaßen vor:
1. Installieren Sie die Entwicklungsbibliothek libpcap, die vorhanden sein muss, um
Httpry kompilieren zu können:
sudo apt-get install libpcap-dev
2. Laden Sie das Tar-Archiv von Jason Bittels Httpry-Website herunter:
wget http://dumpsterventures.com/jason/httpry/httpry-0.1.7.tar.gz
3. Entpacken Sie das Archiv:
tar -zxvf httpry-0.1.7.tar.gz
4. Wechseln Sie in das Httpry-Verzeichnis und erstellen und installieren Sie die Anwendung:
make && sudo make install
Wenn Sie das Programm anschließend ohne Argumente ausführen, beginnt es damit,
HTTP-Datenverkehr an Port 80 an der Netzwerkschnittstelle mit der kleinsten Nummer
zu erfassen. In Abb. 6.5 ist das Argument -r angegeben, sodass Httpry Datenverkehr aus
einer Datei liest und ausgibt.
Abbildung 6.5: Httpry-Beispielausgabe
Es gibt eine Reihe von Befehlszeilenargumenten für Httpry. Für den Anfang sind die folgenden am nützlichsten:
180 6 Paketstringdaten
•• -r <Datei>: Liest Datenverkehr aus der angegebenen PCAP-Datei, anstatt sie direkt zu
erfassen.
•• -o <Datei>: Schreibt die Daten in eine Httpry-Protokolldatei. (Dies ist für die Anwendung von Parserskripts erforderlich.)
•• -i <Schnittstelle>: Gibt die zu überwachende Schnittstelle an.
•• -d: Führt Httpry als Daemon aus.
•• -q: Führt Httpry im stummen Modus aus. Dabei werden nicht kritische Ausgaben wie
Banner und Statistiken unterdrückt.
Das Standardprotokollformat von Httpry ist nicht unbedingt als Analysegrundlage für
jede Umgebung geeignet. Zum Glück können Sie die Daten jedoch mit ein bisschen Befehlszeilenzauberei in eine Form umwandeln, die sich von Ihren Erkennungsmechanismen und Analysetools leicht untersuchen lässt. Im Lieferumfang von Httpry sind mehrere
Skripte enthalten, mit denen Sie die Ausgabe bearbeiten können. Um die von Httpry erfassten Daten über eines dieser Plug-Ins auszugeben, verwenden Sie den Schalter -o. Beispielsweise können Sie Hostnamenstatistiken und HTTP-Protokollzusammenfassungen
generieren oder die Daten in gebräuchliche Protokollformate umwandeln. Damit können
Sie ähnliche Ergebnisse erzielen wie mit URLsnarf. Bei den einzelnen Feldern gibt es kleine Unterschiede zur Ausgabe von URLsnarf, und da die gängigen Protokollformate ebenfalls leicht voneinander abweichen, kann es sein, dass Parser einen Unterschied bemerken.
Mithilfe von Parserskripten können Sie mehrere Plug-Ins nahtlos kombinieren und so eine
vollständige Lösung zur Generierung von PSTR-Daten auf der Grundlage von Httpry zusammenstellen. Zur Konvertierung von Daten ist das Skript parse_log.pl erforderlich, das sich
im Httpry-Verzeichnis scripts/plugins/ befindet und die in diesem Verzeichnis vorhandenen
Plug-Ins nutzt. Das folgende Beispiel zeigt die Befehle, die Sie brauchen, um ein Parserskript
auszuführen. Hier geben wir die Httpry-Daten in einem gebräuchlichen Protokollformat
aus, das für die Untersuchung durch Erkennungs- und Analysetools geeignet ist.
1. Führen Sie Httrpy aus und leiten Sie die Ausgabe in eine Datei:
httpry –o test.txt
2. Konvertieren Sie die Ausgabe:
perl scripts/parse_log.pl -p scripts/plugins/common_log.pm test.txt
Dieser Befehl funktioniert nicht so, wie Sie es erwarten würden. Der Versuch, HttpryAusgaben einem Programm zu übergeben, das sie bearbeitet, wird fehlschlagen, da die
richtigen Spaltenköpfe fehlen. Daher muss die Httpry-Ausgabe erst mit der Option -o
in eine Datei geschrieben werden. Anschließend kann das Skript parse_log.pl ausgeführt
werden, um die Daten zu konvertieren. Ein Beispiel der Ausgabe sehen Sie in Abb. 6.6.
6.2 PSTR-Datenerfassung 181
Abbildung 6.6: Beispielausgabe von Httpry, konvertiert in ein gebräuchliches Format
Mit Httpry lassen sich PSTR-Daten gewöhnlich deutlich schneller generieren als mit
URLsnarf. Der wahre Vorteil von Httpry für NSM-Umgebungen ist aber die Vielseitigkeit
bei der Datenausgabe.
6.2.4 Justniffer
Justniffer ist ein komplettes Protokollanalysetool, das eine umfassende Anpassung der
Ausgabe erlaubt. Damit ist es hervorragend dafür geeignet, TCP-PSTR-Daten zu generieren, die über den bloßen HTTP-Datenverkehr hinausgehen. Hauptsächlich wurde Justniffer entwickelt, um die Störungssuche in Netzwerken zu vereinfachen. Es konzentriert sich
auf Anforderungen und Antworten im Netzwerkverkehr, um nur die Informationen zu
liefern, die nötig sind, um Kommunikationsprobleme einzugrenzen. Das ist aber auch genau das, was wir mit den PSTR-Daten für NSM-Zwecke erreichen wollen. Justniffer kann
jedoch nicht nur Klartext-Protokollheader erfassen, sondern lässt sich mithilfe einfacher
Skripte auch erweitern. So kann es etwa mit einem einfachen BASH-Skript seine Ausgabe,
sortiert noch Hosts, direkt von der Verbindung zu einem lokalen Ordner zu leiten. Ein
weiteres Beispiel ist das mitgelieferte Python-Skript Justniffer-grab-http-traffic, das die bei
der HTTP-Kommunikation übertragenen Dateien extrahiert. Es gibt auch Möglichkeiten,
mit Justniffer eine Leistungsmessung aufgrund der Antwortzeiten, der Verbindungszeiten
usw. vorzunehmen. Dank seiner Vielseitigkeit ist Justniffer äußerst nützlich für eine Vielzahl von Aufgaben im Rahmen der Erfassung von PSTR-Daten.
Justniffer ist in Security Onion nicht standardmäßig enthalten. Um es zu installieren, gehen Sie wie folgt vor:
1. Fügen Sie das passende PPA-Repository hinzu:
sudo add-apt-repository ppa:oreste-notelli/ppa
2. Aktualisieren Sie das Repository:
sudo apt-get update
3. Installieren Sie Justniffer mit apt:
sudo apt-get install justniffer
182 6 Paketstringdaten
Zur Installation von Justniffer auf einer anderen Distribution können zusätzliche Schritte
erforderlich sein. Weitere Informationen erhalten Sie auf http://justniffer.sourceforge.net/#!/
install.
Die ersten Schritte mit Justniffer sind ziemlich einfach, allerdings kann es knifflig sein,
genau die Ausgabe zu bekommen, die Sie haben wollen. Wenn Sie keine Argumente
angeben, erfasst Justniffer die Daten an der Schnittstelle eth0 und zeigt den gesamten
HTTP-Datenverkehr in fast dem gleichen Format an wie URLsnarf. Darüber hinaus
bietet Justniffer einige sehr praktische Befehlszeilenargumente:
••
••
••
••
••
-i <Schnittstelle>: Legt die Schnittstelle fest, an der Datenverkehr erfasst werden soll.
-f <Datei>: Liest die Daten aus der angegebenen PCAP-Datei.
-p <Filter>: Wendet einen Paketfilter an.
-l <Format>: Gibt an, wie der Ausgabestring aufgebaut sein soll.
-u: Kodiert nicht druckbare Zeichen als Punkte.
Die standardmäßige Ausgabeformat von Justniffer ist zwar für den Anfang schon ganz
gut, aber es lassen sich auch anspruchsvollere Protokolle generieren. In Abb. 6.1 haben
Sie die vollständigen Anforderungs- und Antwortheader der HTTP-Kommunikation
gesehen. Mit Justniffer können Sie diese Ausgabe sehr leicht erzeugen, indem Sie die
Schlüsselwörter request.header und response.header verwenden:
sudo justniffer -f packets.pcap -p "tcp port 80" -u
-l "%newline%request.header%newline%response.header"
Die Option -f dient dazu, Daten aus einer Paketerfassungsdatei zu lesen. (Wenn Sie die
Daten direkt von der Verbindung abgreifen wollen, ersetzen Sie diese Option einfach
durch -i <Schnittstelle>.) Mit -p wird ein BPF angegeben, -u sorgt für die Konvertierung
nicht druckbarer Zeichen in Punkte, und mit -l geben Sie Ihr eigenes Protokollformat an.
Das Ergebnis sehen Sie in Abb. 6.7. Gezeigt werden hier zwei HTTP-Transaktionen.
6.2 PSTR-Datenerfassung 183
Abbildung 6.7: Beispiel für die Justniffer-Datenausgabe in einem benutzerdefinierten Format
Die Ausgabe dieses Beispiels ähnelt der aus der ursprünglichen Version in Abb. 6.1, allerdings ist sie aufgrund eines Mangels an entscheidenden Informationen nicht so gut
für die Analyse geeignet. Um die Daten angemessen untersuchen zu können, müssen
wir wissen, welche Hosts für diese Kommunikation verantwortlich sind und wann sie
aufgetreten ist. Hier sehen wir nur das »Was«, wir brauchen aber auch das »Wer« und
»Wann«. Zur Verbesserung weisen wir Justniffer ausdrücklich an, die entsprechenden
Felder auszugeben. Zurzeit bietet Justniffer 85 Formatierungsoptionen, von einfachen
Trennzeichen zu elementaren Optionen für Anforderungen, Antworten und Leistungsmaßen. Um die gewünschte Formatierung zu erzielen, brauchen wir einige weitere
Schlüsselwörter sowie ein benutzerdefiniertes Trennzeichen zu Beginn jedes mehrzeiligen Eintrags. Der entsprechende Befehl sieht wie folgt aus:
sudo justniffer –f packets.pcap -p "tcp port 80" -u
-l "------------------------------- %newline%request.timestamp - %
source.ip ->%dest.ip %newline%request.ader%newline%response.timestamp %newline%response.header"
Eine mit diesem Befehl generierte Beispielausgabe finden Sie in Abb. 6.8.
Wie Sie sehen, haben wir jetzt zwei komplette HTTP-Transaktionen einschließlich Angabe der Hosts, die für die Kommunikation verantwortlich sind, und eines Zeitstempels.
Damit kennen wir jetzt das »Was«, das »Wer« und das »Wann«. Wir werden uns später
noch mehrere Methoden ansehen, um diese Daten weiterzubearbeiten, sowohl mit BASHSkripten als auch mit kostenlosen Open-Source-Tools.
184 6 Paketstringdaten
Abbildung 6.8: Zur Analyse geeignete mehrzeilige Justniffer-Ausgabe
Mit Justniffer können wir auch ähnliche Daten generieren wie in Abb. 6.2, also in Form
eines minimalistischen, einzeiligen Protokolls, das nur den Zeitstempel, die Quell- und
Zieladresse und den angeforderten URL zeigt. Dazu benötigen wir den folgenden Befehl,
der nur wenige besondere Trennzeichen und die Variable request.url nutzt:
sudo justniffer –f packets.pcap -p "tcp port 80" -u -l "%request.timestamp %source.ip ->%dest.ip - %request.header.host%request.url"
Die Ausgabe dieses Befehls sehen Sie in Abb. 6.9.
Abbildung 6.9: Zur Analyse geeignete einzeilige Justniffer-Ausgabe
6.2 PSTR-Datenerfassung 185
Um URLsnarf diese Ausgabe zu entlocken, müssten wir einen erheblichen Aufwand an
Befehlszeilen-Kung-Fu betreiben.
Bis jetzt haben wir uns nur mit HTTP-Datenverkehr beschäftigt, da einige der besprochenen Tools nur HTTP erfassen können. Justniffer dagegen ist ein umfassender TCP-Analysator und kann problemlos auch Nicht-HTTP-Datenverkehr untersuchen. Beispielsweise
können Sie damit auch Klartext-Maileinträge der Protokolle SMTP und POP aus den
FPC-Daten herausziehen oder direkt erfassen.
Um ähnliche Ergebnisse wie zuvor für SMTP-Daten zu erhalten, weisen wir Justniffer mit
folgendem Befehl an, auf Datenverkehr an Port 25 zu lauschen:
justniffer -f packets.pcap -r -p "port 25"
Ein Beispiel dafür sehen Sie in Abb. 6.10.
Abbildung 6.10: Generieren von SMTP-PSTR-Daten mit Justniffer
186 6 Paketstringdaten
6.3
PSTR-Daten anzeigen
Ebenso wie bei NSM-Daten ist auch für eine PSTR-Datenlösung ein Zusammenwirken
von Erfassungs- und Anzeigemechanismus erforderlich. Je weiter ein benutzerdefinierter
Erfassungsmechanismus von den Standards abweicht, umso ausgefallenere Zerlegungsmethoden sind erforderlich. In diesem Abschnitt sehen wir uns einige Lösungen an, um
PSTR-Daten zu zerlegen, anzuzeigen und zu verarbeiten. Dabei greifen wir auf einige der
zuvor besprochenen Formatierungsbeispiele zurück.
6.3.1 Logstash
Logstash ist ein weit verbreiteter Protokollparser, der mehr- und einzeilige Protokolle verschiedener Typen verarbeiten kann, und zwar neben gebräuchlichen Formaten wie Syslog
und JSON auch benutzerdefinierte Protokolle. Dieses kostenlose Open-Source-Werkzeug
ist äußerst leistungsfähig und lässt sich auch in großen Umgebungen relativ einfach einrichten. Zur Veranschaulichung konfigurieren wir Logstash zum Zerlegen von Protokollen,
die mit URLsnarf erfasst wurden. Seit der Version 1.2.1 enthält Logstash die Schnittstelle
Kibana zur Anzeige der Protokolle. Wir werden auch ihre Funktionen besprechen, mit denen Sie die Daten abrufen können, die Sie brauchen, ohne von denen abgelenkt zu werden,
die Sie nicht brauchen.
Logstash ist nicht in Security Onion enthalten. Um die Beispiele in diesem Abschnitt
nachzuvollziehen, laden Sie es von der Projektwebsite www.logstash.net herunter. Das
Programm ist komplett in einem einzigen Java-Paket enthalten, weshalb Sie die JavaLaufzeitumgebung benötigen (zu finden auf http://openjdk.java.net/install/; Sie können
auch einfach sudo apt-get install java-default ausführen.)
Logstash benötigt eine Konfigurationsdatei, die ihm mitteilt, wie ihm die zu zerlegenden
Daten zugeführt werden. In der Praxis wird wahrscheinlich ein stetiger Datenstrom von
einer Protokollquelle eingehen. In diesem Beispiel soll Logstash die Daten verwenden, die
an einen bestimmten Speicherort geschrieben werden. Die Konfigurationsdatei trägt den
Namen urlsnarf-parse.conf und enthält eine sehr einfache Konfiguration:
input {
file {
type =>"urlsnarf"
path =>"/home/idsusr/urlsnarf.log"
}
}
output {
elasticsearch { embedded ¼>true }
}
6.3 PSTR-Daten anzeigen 187
Damit wird Logstash angewiesen, auf Daten jeglicher Art zu lauschen, die in /home/
idsusr/urlsnarf.log geschrieben werden, und davon auszugehen, dass alle in diese Datei
geschriebenen Protokolle vom Typ urlsnarf sind. Der Abschnitt zur Ausgabe startet
eine Instanz von Elasticsearch, um die Indizierung und Durchsuchung der empfangenen Daten zu ermöglichen.
Nachdem wir die Konfigurationsdatei erstellt haben, können wir Logstash starten und
initialisieren. Damit Logstash mit aktiviertem Web-Front-End Kibana startet, verwenden
wir folgenden Befehl:
java -jar logstash-1.2.1-flatjar.jar agent -f urlsnarf-parse.conf -- web
Die Ausgabe dieses Befehls sehen Sie in Abb. 6.11.
Abbildung 6.11: Logstash ausführen
Dieser Befehl initialisiert den Agenten und gibt hinter der Option -f die Konfigurationsdatei urlsnarf-parse.conf an. Die Option --web am Ende sorgt dafür, dass zusammen
mit dem Protokollagenten auch Kibana gestartet wird. Der Erststart kann einige Minuten
dauern. Da die Ausgabe dieses Werkzeugs nicht allzu ausführlich ist, können Sie sich jedoch auf einfache Weise davon überzeugen, dass es läuft, indem Sie netstat für das System
aufrufen:
sudo netstat –antp | grep java
Wenn alles ordnungsgemäß funktioniert, werden mehrere Ports angezeigt, die der gestartete Java-Dienst geöffnet hat (siehe Abb. 6.12).
188 6 Paketstringdaten
Abbildung 6.12: Diese offenen Ports zeigen, dass Logstash ordnungsgemäß läuft
Vergewissern Sie sich anschließend, dass das Front-End Kibana funktioniert, indem Sie in
Ihrem Browser http://127.0.0.1:9292 aufrufen (wobei Sie 127.0.0.1 durch die IP-Adresse
des Systems ersetzen müssen, auf dem Sie Logstash installiert haben). Dadurch gelangen
Sie zum Dashboard von Kibana.
Vorsicht
Wenn Sie Logstash auf einem Security-Onion-System installiert haben, können Sie
die Webschnittstelle Kibana standardmäßig nicht von einem anderen System aus
erreichen (etwa vom Hostsystem der virtuellen Maschine aus), weil die Firewall
des Security-Onion-Systems aktiviert ist. Mit dem Befehl sudo ufw allow 9292/
tcp können Sie eine Ausnahme für die Firewall aufstellen.
Da Logstash nun lauscht und das Front-End Kibana läuft, können Sie die Ausgabe von
URLsnarf an die in urlsnarf-parse.conf angegebene Datei senden:
sudo urlsnarf > /home/idsusr/urlsnarf.log
Nach der Initialisierung von URLsnarf öffnen Sie Ihren Browser (oder verwenden Sie curl
an der Befehlszeile) und besuchen Sie einige Websites, um Daten zu generieren. Beenden
Sie anschließend den URLsnarf-Prozess mit (Strg) + (C). Vergewissern Sie sich in Kibana,
dass die Protokolle eingehen. Auf dem Bildschirm sollten ähnlich wie in Abb. 6.13 einige
Daten dargestellt werden. Ist das nicht der Fall, prüfen Sie, ob Sie am oberen Rand des
Dashboards den richtigen Zeitraum ausgewählt haben.
6.3 PSTR-Daten anzeigen 189
Abbildung 6.13: Anzeige von Protokolldaten in Kibana
Dieses Diagramm stellt die »rohen« Protokolldateien dar, die zum Großteil noch nicht
in ihre einzelnen Elemente zerlegt sind. Wenn Sie sich ein Protokoll ansehen, werden Sie
feststellen, dass zurzeit nur der Eingangszeitstempel und der Hostname des aktuellen Geräts vorhanden sind. Das liegt darin, dass in der Logstash-Konfiguration noch kein Filter
definiert ist und das Programm daher nicht weiß, wie es die einzelnen Felder in den Protokolleinträgen verarbeiten soll. Die Filter bilden das Herz der Konfiguration und legen
fest, wie die Protokolle indiziert werden.
Daher wollen wir nun eigene Filter definieren, um nützliche Informationen in Kibana
hervorzurufen. Logstash verwendet die Sprache GROK, um Textmuster und reguläre Ausdrücke zu kombinieren. Damit ist eine Durchsuchung des Protokolltextes leichter möglich, als es allein mit regulären Ausdrücken möglich wäre. Um die Syntax kennenzulernen,
beginnen wir mit einem einfachen Beispiel. Wir erstellen einen Filter, der nach übereinstimmenden Textfeldern in einem mit Justniffer generierten Protokoll sucht, wobei am
Ende der Sensorname angegeben sein soll (siehe Abb. 6.14).
Abbildung 6.14: Benutzerdefinierte Justniffer-Daten mit Angabe des Sensornamens
Um zu zeigen, wie Logstash mit grundlegenden Vergleichen (im Gegensatz zu vorgefertigten Mustern) umgeht, verwenden wir in der Konfiguration einen Vergleichsfilter
(»match«). Die Grundkonfiguration sieht wie folgt aus:
190 6 Paketstringdaten
input {
file {
type =>"Justniffer-Logs"
path =>"/home/idsusr/justniffer.log"
}
}
filter {
grok {
type =>"Justniffer-Logs"
match =>[ "message", "insertfilterhere" ]
}
}
output {
elasticsearch { embedded =>true }
}
Wir verwenden die integrierten GROK-Muster, um die erforderlichen Daten für die Konfiguration zu erstellen, die wir schlicht justniffer-pare.conf nennen wollen. Diese Muster
sind auf https://github.com/logstash/logstash/blob/master/patterns/grok-patterns zu finden.
Bevor wir überlegen, welche Muster wir verknüpfen wollen, müssen wir uns jedoch das
Protokollformat ansehen und festlegen, welche Felder wir finden wollen. Das Datenformat weist folgenden Aufbau auf:
datestamp timestamp – IP ->IP – domain/path – sensorname SENSOR
Um das in GROK zu übersetzen, benötigen wir den GROK-Debugger, den Sie auf http://
grokdebug.herokuapp.com/ finden. Geben Sie die Protokollstrings, die Sie mit dem Filter
vergleichen wollen, einfach in die obere Zeile ein, und das GROK-Muster, mit dem sie
Ihrer Meinung nach übereinstimmen, in die Zeile darunter. Die Anwendung zeigt Ihnen,
bei welchen Daten eine Übereinstimmung auftritt. Bei der Entwicklung von Strings im
GROK-Format ist es entscheidend, mit kleinen Mustern zu beginnen, und sie nach und
nach zu erweitern, bis die gesamte Protokollzeile eine Übereinstimmung zeigt.
Abbildung 6.15: Der GROK-Debugger
6.3 PSTR-Daten anzeigen 191
Um eine Übereinstimmung mit der Protokollzeile zu erzielen, mit der wir arbeiten, verwenden wir folgendes Muster:
%{DATE:date} %{TIME:time} - %{IP:sourceIP} ->%{IP:destIP} %{URIHOST:domain}%{URIPATHPARAM:request} - %{DATA:sensor} SENSOR
Bei jedem Feld ist eine Feldbezeichnung angegeben. Wenn wir diesen Filter in die Konfigurationsdatei einbauen, erhalten wir eine Konfiguration, mit der wir sämtliche eingehenden
Justniffer-Logs zerlegen können, die mit dem zuvor angegebenen Format übereinstimmen.
Die resultierende Konfigurationsdatei sieht wie folgt aus:
input {
file {
type =>"Justniffer-Logs"
path =>"/home/idsusr/justniffer.log"
}
}
filter {
grok {
type =>"Justniffer-Logs"
match =>[ "message", "%{DATE:date} %{TIME:time} - %{IP:sourceIP}
->%{IP:destIP} - %{URIHOST:domain}%{URIPATHPARAM:request} - %{DATA:
sensor} SENSOR" ]
}
}
output {
elasticsearch { embedded =>true }
}
Nun können Sie den Logstash-Kollektor mit dem folgenden Befehl starten, sodass er die
neue Konfigurationsdatei nutzt:
java -jar logstash-1.2.1-flatjar.jar agent -f justniffer-parse.conf --web
Sobald Logstash läuft, können Sie mit die Datenerfassung mit dem folgenden JustnifferBefehl starten. Dadurch werden die Protokolldaten in dem Format generiert, das in der
neuen Konfiguration angegeben ist:
sudo justniffer -p "tcp port 80" -u -l "%request.timestamp - %source.ip >%dest.ip - %request.header.host%request.url - IDS1 SENSOR" >> /home/
idsusr/justniffer.log
192 6 Paketstringdaten
Suchen Sie erneut einige Websites auf, um Protokolle zu generieren. Prüfen Sie dabei, ob
in Kibana Protokolle angezeigt werden. Wenn alles richtig funktioniert, sollten jetzt die
komplett zerlegten Protokolle angezeigt werden. Sie können sie aber nicht nur einsehen,
sondern mit dem Feld Query am unteren Rand der Dashboard-Hauptseite von Kibana
auch durchsuchen. Mit dem Ereignisfilter Fields links neben dem Feld Query können Sie
außerdem die Anzeige auf die Felder eingrenzen, die Sie sehen wollen (siehe Abb. 6.16).
Abbildung 6.16: Untersuchung einzelner Protokolle in Kibana
Um Messgrößen für ein Feld einzusehen, klicken Sie in der Liste auf der linken Bildschirmseite auf den entsprechenden Feldnamen. Abb. 6.17 zeigt Messgrößen für das Host-Feld.
­Darin werden alle besuchten Hosts aufgeführt, die in den aktuellen Protokollen vorkommen.
Abbildung 6.17: Messgrößen für Felder in Kibana
6.3 PSTR-Daten anzeigen 193
Dieses Beispiel ist ein guter Ausgangspunkt für die benutzerdefinierte Zerlegung von
Protokollen mit Logstash. Einige Protokolltypen sind jedoch schwerer zu verarbeiten.
Beispielsweise sind URLsnarf-Protokolle bis auf ein oder zwei Zeichen identisch mit
Apache-Zugriffsprotokollen. Logstash kann normale Apache-Zugriffsprotokolle zwar
mit Leichtigkeit handhaben, doch die zusätzlichen Zeichen der URLsnarf-Protokolle
können die integrierten Filter in Verwirrung stürzen. Im folgenden Beispiel sehen wir
uns daher an, wie wir eigene GROK-Filter als Ersatz für die vorhandenen Filtermuster
für Apache-Zugriffsprotokolle schreiben können, um damit URLsnarf-Protokolle zu verarbeiten. Der neue Filter berücksichtigt die Unterschiede und löst die Unstimmigkeiten
durch die zusätzlichen Bindestriche auf. Da die Filter dem integrierten Muster sehr ähnlich sind, können wir einfach das Muster nach Bedarf abwandeln. Die neuesten GROKMuster sind im Git-Repository von Logstash auf https://github.com/logstash/logstash/
blob/­master/patterns/grok-patterns zu finden. Wenn Sie sich den Filter COMBINEDAPACHELOG
genau ansehen, werden Sie feststellen, dass das Problem durch einen fehlenden Bindestrich verursacht wird, der im folgenden Code ergänzt wurde:
COMBINEDAPACHELOG %{IPORHOST:clientip} %{USER:ident} %{USER:auth} \[%
{HTTPDATE:timestamp}\] "(?:%{WORD:verb} %{NOTSPACE:request}(?: HTTP/
%{NUMBER:httpversion})?|%{DATA:rawrequest})" %{NUMBER:response}|(?:%{NUMBER:bytes}|-) %{QS:referrer} %{QS:agent}
Dieser Filter sieht nicht nur kompliziert aus, er ist es auch. Ihn zu zerlegen ist eine Aufgabe, die Sie am besten dem GROK-Debugger überlassen. Die Änderungen gegenüber dem
ursprünglichen Filter bestehen in der Ergänzung des Bindestrichs und im Auskommentieren der inneren Anführungszeichen. Diesen GROK-Filter können wir der zuvor erstellten
Grundkonfiguration hinzufügen. Damit sieht die Konfigurationsdatei wie folgt aus:
input {
file {
type =>"urlsnarf"
path =>"/home/idsusr/urlsnarf.log"
}
}
filter {
grok {
type =>"urlsnarf"
match =>[ "message", "%{IPORHOST:clientip} %{USER:ident} %{USER:
auth} \[%{HTTPDATE:timestamp}\] \"(?:%{WORD:verb} %{NOTSPACE:
request} (?: HTTP/%{NUMBER:httpversion})?|%{DATA:rawrequest})\" (%
{NUMBER:response}|-) (?:%{NUMBER:bytes}|-) %{QS:referrer} %{QS:
agent}" ]
}
}
194 6 Paketstringdaten
output {
elasticsearch { embedded =>true }
}
Ohne einen GROK-Filter würden die Protokolle in Kibana wie in Abb. 6.18 aussehen: Die
Daten würden in einer fortlaufenden Zeile angezeigt, was eine weitergehende Analyse der
einzelnen Felder unmöglich macht.
Abbildung 6.18: Darstellung der Protokolldaten ohne GROK
Mit dem neuen Filter wird das Protokoll vollständig in seine einzelnen Felder zerlegt, wie
Sie in Abb. 6.19 sehen können.
Abbildung 6.19: Darstellung der Protokolldaten mit GROK
Wie Sie sehen, bilden Logstash, Kibana und GROK ein leistungsfähiges Trio zur Zerlegung
von Protokollen wie denen von PSTR-Daten. Um mehr über diese Werkzeuge zu lernen,
besuchen Sie http://logstash.net/.
6.3 PSTR-Daten anzeigen 195
6.3.2 Rohtextzerlegung mit BASH-Tools
Logstash und Kibana eignen sich hervorragend zur Zerlegung von einzeiligen PSTR-Daten, lassen sich aber nicht in jeder Umgebung anwenden. Je nachdem, wie Sie die Daten
beziehen, kann es sein, dass Sie einen umfangreicheren Satz von Werkzeugen benötigen.
Selbst wenn Hilfsprogramme zum Durchsuchen von Protokollen vorhanden sind, sollten
die Analytiker stets eine Möglichkeit haben, direkt auf Protokolle in linearem Textformat
zuzugreifen. In den folgenden Beispielen schauen wir uns PSTR-Daten mit mehrzeiligen
Anforderungs- und Antwortheadern an.
Dazu erzeugen wir zunächst ebenso wie in früheren Beispielen PSTR-Daten mit Justniffer:
sudo justniffer -i eth0 -p "tcp port 80” -u -l "------------------------------ %newline%request.timestamp - %source.ip ->
%dest.ip %newline%request.header%newline%response.timestamp - %newline%
response.header">pstrtest.log
Dadurch werden Daten wie in Abb. 6.7 generiert und in der Datei pstrtest.log gespeichert.
Die Zerlegung von Rohdaten mithilfe von BASH-Tools wie sed, awk und grep ruft manchmal irrationale Ängste hervor, die aber zum Großteil unberechtigt sind. Schließlich gehört
die Zerlegung solcher Texte zu den am umfangreichsten dokumentierten und am häufigsten diskutierten Themen in Unix-Foren. Ein unlösbares Problem ist mir dabei noch nie
untergekommen. Aus den zuvor genannten Beispieldaten können wir eine Menge nützlicher Daten für die Analyse gewinnen. Mit grep lassen sie sich sehr einfach durchsuchen
und zerlegen. Beispielsweise können wir in den Daten nach allen Hosts forschen, indem
wir einfach wie folgt nach dem entsprechenden Feld suchen:
cat pstrtest.log | grep "Host:"
Dadurch werden alle Zeilen ausgegeben, die das Wort »Host:« enthalten – und zwar in
jedem Kontext, also möglicherweise auch in Zusammenhängen, die Sie gar nicht brauchen. Damit nur Zeilen gefunden werden, bei denen »Host:« am Anfang steht, müssen Sie
Option -e und das Zirkumflexsymbol (^) angeben.
cat pstrtest.log | grep -e "^Host: "
Dieses Symbol bedeutet, dass der angegebene Text am Anfang der Zeile stehen muss. Daher erfüllen alle Zeilen, die mit »Host:« beginnen, diese Bedingung. Im jetzigen Zustand
wird bei der Suche noch zwischen Groß- und Kleinschreibung unterschieden. Wenn Sie
das nicht wollen, müssen Sie die Option -i angeben. Die Suche ist die einfachste und am
häufigsten eingesetzte Funktion von grep, allerdings können Sie damit auch eine Suche
nach regulären Ausdrücken, eine Zerlegung und weitere Bearbeitung der Daten vornehmen. Nehmen wir beispielsweise an, Sie wollen nach Etags in einem bestimmten Format
suchen (siehe Abb. 6.20).
196 6 Paketstringdaten
Abbildung 6.20: Etags in PSTR-Daten
Die Einträge haben zwar im Allgemeinen ein sehr ähnliches Format, doch einige weisen
zusätzliche Zeichen auf, z. B. mehr als einen Bindestrich. Ein Beispiel dafür finden Sie in
der fünften Zeile. Um solche Einträge zu finden, müssen wir theoretisch nach allen Zeilen
suchen, die mit ETag beginnen und auf die ein Wert mit zwei Bindestrichen folgt. Ausgeben wollen wir jedoch nur die eigentlichen Etags. Das können wir mit dem folgendem
Befehl erreichen:
cat pstrtest.log | grep -e "^ETag" | grep -oP "\".*?\-.*?\-.*?\"" | sed 's/ "//g'
Dieser Befehl sieht zwar ziemlich kompliziert aus, macht aber tatsächlich, was wir wollen.
Sehen wir uns die einzelnen Bestandteile dieses Befehls an:
1. cat pstrtest.log
Als Erstes sorgen wir dafür, dass die Datei pstrtest.log auf dem Bildschirm (Standardausgabe) ausgegeben wird.
2. grep -e "^ETag"
Anschließend übergeben wir die Ausgabe der Datei an grep und suchen dort nach
Zeilen, die mit dem Text ETag beginnen.
3. grep -oP "\".*?\-.*?\-.*?\""
Die gefundenen Etags werden an einen weiteren grep-Befehl geleitet, der mithilfe eines regulären Ausdrucks nach Daten mit dem richtigen Format sucht. Dieses Format
besteht aus beliebig vielen Zeichen (.*?) zwischen einem Anführungszeichen und
einem Bindestrich, gefolgt von beliebig vielen Zeichen zwischen diesem und einem
weiteren Bindestrich und anschließend weiteren beliebig vielen Zeichen und einem
Anführungszeichen.
4. sed 's/"//g'
Schließlich übergeben wir die Ausgabe des letzten grep-Befehls an sed, um alle Anführungszeichen daraus zu entfernen.
6.3 PSTR-Daten anzeigen 197
In diesem Beispiel haben wir auch sed genutzt. Dieser Befehl eignet sich zum Suchen und
Ersetzen von Text. Hier durchsucht er sämtliche Zeilen und ersetzt sämtliche Vorkommen
von doppelten Anführungszeichen (") durch nichts. Einfacher ausgedrückt, er entfernt
alle doppelten Anführungszeichen. Die Ausgabe des Befehls sehen Sie in Abb. 6.21.
Abbildung 6.21: Extraktion von Etags mit einem bestimmten Format aus PSTR-Daten
Eine weitere praktische Bearbeitungsmöglichkeit besteht darin, die vorhandenen Daten
zu ordnen und zu zählen. Das mag sich nach einer sehr einfachen Aufgabe anhören, bietet
aber enorm viel Nutzen. Betrachten Sie als Beispiel den User-Agent-String in den HTTPHeaderinformationen. Durch die Sortierung dieser Strings von den am wenigsten zu den
am häufigsten genutzten Benutzeragenten können wir schon eine gewisse rudimentäre
Erkennung durchführen, denn unerwartete User-Agent-Strings können auf verdächtige
Aktivitäten hindeuten.
cat pstrtest.log | grep -e "^User Agent: " | sort | uniq -c | sort –n
Dadurch geben wir nur die Zeilen der PSTR-Daten aus, die mit dem Text User Agent:
beginnen, und übergeben sie an den Befehl sort. Die geordneten Ergebnisse werden dann
an den Befehl uniq weitergeleitet, der alle eindeutigen Zeilen zählt und in der linken Spalte
angibt. Das Ergebnis dieses Vorgangs wird dann erneut an sort übergeben, wobei sie diesmal aufgrund des Schalters -n nach der Anzahl der Vorkommen sortiert werden. Am Ende
erhalten wir die in Abb. 6.22 gezeigten Daten.
Abbildung 6.22: Sortierte User-Agent-Daten
198 6 Paketstringdaten
Eine Analyse dieser Daten lässt sofort einige ungewöhnliche und möglicherweise verdächtige Benutzeragenten erkennen. Davon ausgehend können wir die entsprechenden
Kommunikationsvorgänge genauer untersuchen. Das ist ein Beispiel für die Generierung
grundlegender statistischer Daten aus PSTR-Daten.
6.4
Zusammenfassung
Die verschiedenen Spielarten von Paketstringdaten sind von entscheidender Bedeutung,
um die Effizienz der Erkennung und Analyse zu erhöhen. Angesichts des schnellen Zugriffs, der Breite der Daten, der Leichtigkeit der Bereitstellung und der geringen Speicheranforderungen für die Aufbewahrung bilden PSTR-Daten einen perfekten Kompromiss
zwischen FPC- und Sitzungsdaten. In diesem Kapitel haben wir uns angesehen, was PSTRDaten sind, und einige Möglichkeiten besprochen, Daten dieses Typs zu erfassen und zu
untersuchen. In späteren Kapiteln dieses Buches werden wir Situationen kennenlernen, in
denen PSTR-Daten die Analyse unterstützen können.
Teil 2
Erkennung
7
Erkennungsmechanismen, Einbruchs­
indikatoren und Signaturen
Für die Erkennungsphase des Network Security Monitoring müssen Sie die Taktiken der
Gegner verstehen, Ihre eigenen Erkennungsmöglichkeiten kennen und diese anwenden,
indem Sie die erfassten Daten untersuchen und Anomalien aufspüren.
In diesem ersten Kapitel des Teils über die Erkennung beschäftigen wir uns mit Erkennungsmechanismen, Indikatoren für einen Einbruch (Indicators of Compromise, IOCs)
und Signaturen. Insbesondere sehen wir uns an, wie Sie Indikatoren aus Netzwerkangriffen
ableiten können, wie Sie Indikatoren und Signaturen verwalten und welche gebräuchlichen
Frameworks es für sie gibt.
7.1
Erkennungsmechanismen
Allgemein gesagt, erfolgt die Erkennung mithilfe einer Software, die die erfassten Daten
durchforstet und Alarmdaten generiert. Diese Software bezeichnen wir als Erkennungsmechanismen. Die Alarmdaten werden anschließend einem Analytiker übergeben. An
dieser Stelle endet die Erkennungsphase, und es beginnt die Analyse. Das mag sich nach
202 7 Erkennungsmechanismen, Einbruchs­indikatoren und Signaturen
einem vollautomatischen Vorgang anhören, aber nichts könnte weiter von der Wahrheit
entfernt sein. Für eine erfolgreiche Erkennung müssen Sie den Erkennungsmechanismus
sorgfältig auswählen und ihm ebenso sorgfältig Daten zuführen.
Bei den meisten in diesem Buch besprochenen Erkennungsmechanismen handelt es sich
um Netzwerk-IDS (Intrusion-Detection-Systeme). Davon gibt es zwei Hauptklassen,
nämlich für die signatur- und die anomaliegestützte Erkennung.
Die signaturgestützte Erkennung ist die älteste Form der Intrusion Detection. Dabei
werden die Daten nach bestimmten Mustern durchsucht. Es kann sich dabei um einfache Muster wie IP-Adressen oder Textstrings handeln, aber auch um kompliziertere
wie eine bestimmte Anzahl von Null-Bytes, die bei der Verwendung eines bestimmten
Protokolls hinter einem bestimmten String auftreten. Wenn Sie diese Muster in objektive,
plattform­unabhängige Daten zerlegen, erhalten Sie Einbruchsindikatoren. Wenn Sie sie
in der plattformspezifischen Sprache des Erkennungsmechanismus ausdrücken, erhalten
Sie Signaturen.
Eine Unterkategorie der signaturgestützten Erkennung ist die reputationsgestützte Erkennung. Dabei geht es darum, eine Kommunikation zwischen den Hosts in Ihrem Netzwerk
mit Hosts im Internet aufzuspüren, die aufgrund einer früheren Teilnahme an schädlichen Aktionen als bedrohlich eingestuft werden. Diese Erkennung erfolgt im Prinzip
anhand von einfachen Signaturen in Form von IP-Adressen oder Domänennamen.
In Kapitel 9 werden wir mehrere weit verbreitete signaturgestützte Erkennungsmechanismen besprechen, darunter Snort und Suricata. Um die reputationsgestützte Erkennung
geht es in Kapitel 8.
Die anomaliegestützte Erkennung ist eine jüngere Form der Intrusion Detection, die dank
Tools wie Bro rasch an Bedeutung zunimmt. Hierbei werden Ereignisse im Netzwerk beobachtet und anomaler Datenverkehr mithilfe von Heuristiken und Statistiken erkannt.
Solche Mechanismen alarmieren Sie nicht nur, wenn sie ein zuvor festgelegtes Muster gefunden haben, sondern können Angriffsmuster erkennen, die vom üblichen Netzwerk­
verhalten abweichen. Diese Art der Erkennung ist unendlich viel leistungsfähiger, aber
auch deutlich schwieriger umzusetzen. In Kapitel 10 sehen wir uns Bro als Beispiel für
einen solchen anomaliegestützten Mechanismus an, und in Kapitel 11 beschäftigen wir
uns mit statistischer anomaliegestützter Erkennung.
Eine neue, aufkommende Unterkategorie der anomaliegestützten Erkennung ist die Verwendung von Honeypotmechanismen. Honeypots werden schon seit vielen Jahren eingesetzt, um Malware und Angriffsproben zu Forschungszwecken zu sammeln, lassen sich
aber auch für die Erkennung nutzen. Dabei wird ein Honeypotsystem eingerichtet, das
den Aufbau des Produktionssystems widerspiegelt. Es weist oft bekannte Schwachstellen
auf, enthält aber keine vertraulichen Daten. Dieses System wird umfangreich protokolliert, teilweise in Zusammenhang mit anderen Arten von Netzwerk- oder Host-IDS. Die
Erkennung mithilfe von Honeypots ist Thema von Kapitel 12.
Welchen Erkennungsmechanismus Sie bereitstellen, hängt davon ab, wie ausgereift Ihr
Sicherheitsprogramm ist. Die meisten Organisationen beginnen mit einem signatur­
7.2 Einbruchsindikatoren und Signaturen 203
gestützten Mechanismus und warten, bis sie sich in der Anwendung der ersten Technologie
ausreichend sicher fühlen, bevor sie zu etwas Anspruchsvollerem wie etwa einem anomaliegestützten Mechanismus übergehen. Das trägt zu einer gesunden Entwicklung bei. Ich
habe schon Organisationen kennengelernt, die von Anfang an die gesamte Palette der Erkennungsmechanismen umzusetzen versuchten und dabei einen argen Fehlschlag erlitten,
weil es nicht möglich ist, sich all die verschiedenen Fähigkeiten gleichzeitig anzueignen.
7.2
Einbruchsindikatoren und Signaturen
Erkennungsmechanismen sind nutzlos, wenn sie nicht korrekt gespeist und gewartet
werden. Dazu müssen Einbruchsindikatoren und Signaturen entwickelt, gepflegt und
implementiert werden.
Ein Einbruchsindikator ist eine Information, die objektiv und plattformunabhängig ein
Eindringen in ein Netzwerk beschreibt. Dabei kann es sich um einen einfachen Indikator
wie die IP-Adresse eines Steuerservers (Command and Control, C2) handeln, aber auch
um einen vielschichtigen Satz von Verhaltensweisen, die anzeigen, dass ein Mailserver
als SMTP-Relay für schädliche Zwecke missbraucht wird. Es gibt die unterschiedlichsten
Arten von Indikatoren, und sie können auf unterschiedliche Weise formatiert werden,
um sie den verschiedenen Erkennungsmechanismen zuzuführen. Während das eine Tool
IP-Adressen in kommagetrennten Listen verarbeiten kann, mag es für ein anderes erforderlich sein, die Adressen in eine SQL-Datenbank einzufügen. Die Darstellung der Indikatoren kann sich ändern, doch die Indikatoren selbst bleiben gleich. Außerdem kann
ein einzelner Verhaltensindikator in mehrere Einzelteile zerlegt und mehreren Erkennungsmechanismen zugeführt werden. Wird ein Indikator in einer plattformspezifischen
Sprache oder einem plattformspezifischen Format verwendet, etwa in einer Snort-Regel
oder einer Bro-Datei, so wird er Teil einer Signatur, wobei eine Signatur auch mehrere
Indikatoren umfassen kann.
Im Rest dieses Kapitels sehen wir uns die verschiedenen Klassen von Indikatoren und
Signaturen und ihre Verwaltung an.
Hinweis für Analytiker
In diesem Buch verwende ich statt »Einbruchsindikator« auch oft einfach den
Begriff »Indikator«. Dieser Begriff für sich allein kann je nach Zielpublikum
unterschiedliche Bedeutungen haben. Personen mit einem Hintergrund in der
Rüstungsindustrie mögen dabei eher an Verhaltens- oder Attributionsindikatoren denken und weniger an objektive Informationen zur Beschreibung eines
Eindringens in das Netzwerk.
204 7 Erkennungsmechanismen, Einbruchs­indikatoren und Signaturen
7.2.1
Host- und Netzwerkindikatoren
Die allgemeinste und am weitesten verbreitete Klassifizierung von Indikatoren ist ihre
Einteilung in Host- und Netzwerkindikatoren. Das gibt die grundlegende Natur des Indikators an, sodass Sie erkennen können, für welche Erkennungsmechanismen er geeignet
ist.
Hostindikatoren sind Informationen, die auf einem Host zu finden sind und objektiv
einen Einbruch beschreiben. Zu den bekanntesten Indikatoren dieser Art gehören:
••
••
••
••
••
••
••
••
Registrierungsschlüssel
Dateiname
Textstring
Prozessname
Mutex
Dateihash
Benutzerkonto
Verzeichnispfad
Netzwerkindikatoren beschreiben ebenfalls objektiv einen Einbruch, werden aber zwischen
den Hosts im Netzwerk erfasst. Zu den bekanntesten zählen:
••
••
••
••
••
••
••
••
IPv4-Adresse
IPv6-Adresse
X509-Zertifikathash
Domänenname
Textstring
Kommunikationsprotokoll
Dateiname
URL
Die meisten dieser Indikatoren sind zwar sowohl im Netzwerk als auch auf dem Host
anzutreffen, doch die Klassifizierung richtet sich danach, wo sie hauptsächlich zu finden
sind. Einige Indikatoren sind in beiden Kategorien aufgeführt, da sie gleichermaßen stark
an beiden Orten vertreten sind, beispielsweise Textstrings und Dateinamen.
Die Einteilung in Host- und Netzwerkindikatoren ist für den Anfang schon sehr praktisch, aber wir können auch noch eine Unterteilung in statische und variable Indikatoren
vornehmen.
7.2 Einbruchsindikatoren und Signaturen 205
7.2.2 Statische Indikatoren
Als statisch werden Indikatoren bezeichnet, für die ausdrücklich Werte definiert sind. Es
gibt drei Varianten davon, nämlich elementare, berechnete und Verhaltensindikatoren
(siehe Abb. 7.1).
Elementare Indikatoren sind kleiner und spezifischer und lassen sich nicht in kleinere
Bestandteile zerlegen, haben aber immer noch eine Bedeutung im Zusammenhang mit
Eindringversuchen. Dazu gehören Dinge wie IP-Adressen, Textstrings, Hostnamen,
­E-Mail-Adressen und Dateinamen.
Berechnete Indikatoren werden aus den Daten eines Zwischenfalls abgeleitet. Dazu zählen
u. a. Hashwerte, reguläre Ausdrücke und Statistiken.
Verhaltensindikatoren sind eine logische Kombination von elementaren und berechneten
Indikatoren, die oft dazu dient, einen gewissen Kontext herzustellen. Das kann beispielsweise eine Zusammenstellung von Dateinamen und der zugehörigen Hashwerte sein oder
eine Kombination aus Textstrings und regulären Ausdrücken.
Abbildung 7.1: Verhaltensindikatoren sind aus elementaren und berechneten Indikatoren
zusammengesetzt
Nehmen wir an, Sie vermuten, dass in ein Gerät in Ihrem Netzwerk eingebrochen wurde.
Anhand einer Analyse der NSM-Daten und der forensischen Hostdaten können wir erkennen, dass die folgenden Ereignisse in der angegebenen Reihenfolge eingetreten sind:
1. Ein Benutzer hat eine E-Mail von chris@appliednsm.com mit der Betreffzeile »Payroll Information« und der angehängten PDF-Datei Payroll.pdf mit dem MD5-Hash
e0b359e171288512501f4c18ee64a6bd erhalten.
2. Der Benutzer hat das PDF geöffnet und dadurch den Download der Datei kernel32.dll
mit dem MD5-Hash da7140584983eccde51ab82404ba40db von http://www.appliednsm.
com/kernel32.dll ausgelöst.
3. Mit dieser Datei wurde C:/Windows/System32/kernel32.dll überschrieben.
206 7 Erkennungsmechanismen, Einbruchs­indikatoren und Signaturen
4. Code in der DLL wurde ausgeführt und hat eine SSH-Verbindung mit der IP-Adresse
192.0.2.75 an Port 9966 aufgebaut.
5. Die Malware hat nach allen DOC-, DOCX- und PDF-Dateien auf dem betroffenen
Host gesucht und sie über die SSH-Verbindung an den gegnerischen Host übertragen.
Diese vollständige Beschreibung des Zwischenfalls lässt sich durchaus als Verhaltensindikator ansehen. Er bietet zwar einen guten Überblick über den Vorfall, ist aber zu komplex,
um uns für die NSM-Erkennung gute Dienste zu leisten.
Um signatur- und anomaliegestützte sowie statistische Erkennungsmechanismen richtig
einzustellen, müssen wir erst den Indikator in brauchbarere Einzelteile zerlegen und dabei
sicherstellen, dass noch ein sinnvoller Kontext erhalten bleibt. Beispielsweise können wir
dabei zu folgenden Verhaltensindikatoren (B für »behaviour«) kommen:
•• B-1: Ein Benutzer empfängt eine E-Mail von chris@appliednsm.com mit der Betreffzeile »Payroll Information« und der angehängten PDF-Datei Payroll.pdf. Die PDFDatei hat den MD5-Hash e0b359e171288512501f4c18ee64a6bd.
•• B-2: Die Datei kernel32.dll mit dem MD5-Hash da7140584983eccde51ab82404ba40db
wird von http://www.appliednsm.com/kernel32.dll heruntergeladen.
•• B-3: Die Datei C:/Windows/System32/Kernel32.dll wird durch eine Schaddatei desselben
Namens mit dem MD5-Hashwert da7140584983eccde51ab82404ba40db überschrieben.
•• B-4: Der Opfer-Host versucht eine SSH-Verbindung zu dem gegnerischen Host
192.0.2.75 an Port 9966 aufzubautén.
•• B-5: Über eine verschlüsselte Verbindung werden DOC-, DOCX- und PDF-Dateien an
192.0.2.75 und Port 9966 übertragen.
Als Nächstes versuchen wir, diese Verhaltensinicatoren in elementare (A, »atomic«) und
berechnete (C, »calculated«) Indikatoren zu zerlegen. Das Ergebnis sieht wie folgt aus:
••
••
••
••
••
••
••
••
••
••
••
••
C-1: MD5-Hash e0b359e171288512501f4c18ee64a6bd
C-2: MD5-Hash da7140584983eccde51ab82404ba40db
A-1: Gegnerische Domäne appliednsm.com
A-2: E-Mail-Adresse chris@appliednsm.com
A-3: Betreffzeile »Payroll Information«
A-4: Dateiname Payroll.pdf
A-5: Dateiname Kernel32.dll
A-6: Gegnerische IP-Adresse 192.0.2.75
A-7: Port 9966
A-8: Protokoll SSH
A-9: Dateitypen DOC, DOCX und PDF
A-10: Dateiname Kernel32.dll
7.2 Einbruchsindikatoren und Signaturen 207
Damit haben wir insgesamt fünf Verhalts-, zwei berechnete und zehn elementare Indikatoren, die wir in unsere Erkennungsmechanismen aufnehmen können. Unter anderem
können diese Indikatoren in Signaturen für verschiedene Mechanismen umgewandelt
werden, wie die folgenden Beispiele zeigen:
•• C-1/2: Antivirussignatur, um das Vorhandensein des Hashwerts zu erkennen
•• A-1: Snort-/Suricata-Signatur, um jegliche Kommunikation mit der gegnerischen
Domäne zu erkennen
•• A-2: Snort-/Suricata-Signatur, um E-Mails von der gegnerischen E-Mail-Adresse zu
erkennen
•• A-3: Snort-/Suricata-Signatur, um die Betreffzeile zu erkennen
•• A-3: Bro-Skript, um die Betreffzeile zu erkennen
•• A-4/C-1: Bro-Skript, um zu erkennen, dass der Dateiname oder der MD5-Hashwert
über das Netzwerk übertragen wird
•• A-5/C-S: Bro-Skript, um zu erkennen, dass die Datei Kernel32.dll oder eine Datei mit
dem MD5-Hashwert über das Netzwerk übertragen wird
•• A-6: Snort-/Suricata-Signatur, um die Kommunikation mit der IP-Adresse zu erkennen
•• A-7/A-8: Snort-/Suricata-Signatur, um die Kommunikation mit Port 9966 zu erkennen
•• A-10: HIDS-Regel, um Änderungen an Kernel32.dll zu erkennen
Wie Sie sehen, gibt es verschiedene Vorgehensweisen für die Erkennung auf der Grundlage dieser aus einem einzigen Zwischenfall abgeleiteten Indikatoren. Wenn wir noch
mehr Einzelheiten hätten, könnten wir aus dieser Situation sogar noch weitere Erkennungsmöglichkeiten gewinnen. Beispielsweise können wir schädliche Objektaufrufe in
der PDF-Datei selbst oder die Merkmale möglicherweise benutzter besonderer Protokolle
erkennen. Je nach der Architektur des zu schützenden Netzwerks können mehrere Erkennungsmechanismen für ein und denselben Indikator vorhanden sein, es ist aber auch
möglich, dass sich einige Indikatoren überhaupt nicht erkennen lassen. Welche Methode
die beste ist, um einen bestimmten Indikator zu erkennen, hängt von der Infrastruktur
des Netzwerks, den Details der Erkennungsmethoden und der Natur der Informationen
ab, die ein Indikator bietet.
208 7 Erkennungsmechanismen, Einbruchs­indikatoren und Signaturen
Bericht von der Front
Manche Organisationen verwenden mehrere Versionen desselben Entdeckungsmechanismus für Indikatoren unterschiedlicher Wichtigkeit, beispielsweise mehrere Instanzen des IDS Snort für die signaturgestützte Erkennung. Snort erkennt
Einbrüche, indem es die übertragenen Pakete »live« analysiert oder regelmäßig
vorhandene PCAP-Dateien untersucht. Das Hauptgewicht liegt dabei auf der
Snort-Instanz, die den Datenverkehr im laufenden Betrieb analysiert. Diese Echtzeit-Instanz ist für hocheffiziente Signaturen im Zusammenhang mit Indikatoren
reserviert, die Informationen oberster Priorität liefern. Um Signaturen mit geringerer Vertrauenswürdigkeit sowie allgemeine Malwaresignaturen kümmert sich
dagegen die Snort-Instanz, die regelmäßig die PCAP-Dateien untersucht. Dadurch können Alarmdaten zu kritischen Indikatoren schneller generiert werden,
was den Analytikern eine schnellere Reaktion ermöglicht.
7.2.3 Variable Indikatoren
Wenn die Erkennungsmechanismen in Ihrem Netzwerk nur Angriffe aufspüren können,
für die es bekannte Indikatoren gibt, dann wird mit hoher Wahrscheinlichkeit eines Tages
etwas Schlimmes durchschlüpfen. Irgendwann in der Punkt erreicht, an dem wir auch
variable Indikatoren einsetzen müssen, also solche, deren Werte unbekannt sind. Um sie
abzuleiten, wird gewöhnlich eine Folge von Ereignissen aufgestellt, bei der möglicherweise
ein Angriff vorliegen könnte (was einen Verhaltensindikator darstellt), und versucht, die
möglichen Variablen dabei ausfindig zu machen. Im Grunde genommen geht es darum,
einen theoretischen Angriff zu untersuchen und nicht einen, der tatsächlich stattgefunden
hat. Diese Art von Ursachenanalyse wird für einzelne Angrifftechniken durchgeführt und
nicht für Angriffe eines bestimmten Gegners.
Ich stelle mir variable Indikatoren gern wie das Drehbuch eines Films vor: Es sagt Ihnen,
was geschehen wird, aber Sie wissen nicht, wer die einzelnen Rollen spielt. Bei erfahrenen
Schauspielern besteht auch immer die Möglichkeit der Improvisation. Für signaturgestützte Erkennungsmechanismen sind variable Indikatoren nicht sehr sinnvoll, aber sie
werden sehr häufig in Anwendungen wie Bro eingestzt.
Um uns ein Beispiel für die Entwicklung von variablen Indikatoren anzusehen, beschäftigen wir uns noch einmal mit der Situation aus dem letzten Abschnitt. Hier jedoch geht es
nicht um einen tatsächlich erfolgten, sondern um einen theoretisch möglichen Angriff. In
diesem Sinne umformuliert, sieht das Szenario grob gesehen wie folgt aus:
1. Ein Benutzer erhält eine E-Mail mit einem schädlichen Anhang.
2. Der Benutzer öffnet den Anhang und löst damit den Download einer Datei aus einer
gegnerischen Domäne aus.
7.2 Einbruchsindikatoren und Signaturen 209
3. Mit dieser Datei wird eine Systemdatei durch eine schädliche Version überschrieben.
4. Der Code in der Schaddatei wird ausgeführt und baut eine verschlüsselte Verbindung
zu einem Schadserver auf.
5. Nach dem Aufbau der Verbindung werden große Mengen von Daten aus dem System
herausgeschleust.
Diese Schritte stellen Verhaltensindikatoren dar, die wiederum mehrere variable elementare und berechnete Indikatoren enthalten, darunter die folgenden:
•• VB-1: Ein Benutzer erhält eine E-Mail mit einem schädlichen Anhang.
• VA-1: E-Mail-Adresse
• VA-2: Betreffzeile der E-Mail
• VA-3: Schädliche E-Mail-Quelldomäne
• VA-4: Schädliche E-Mail-Quell-IP-Adresse
• VA-6: Dateiname des schädlichen Anhangs
• VC-1: MD-5-Hash des schädlichen Anhangs.
•• VB-2: Der Benutzer öffnet den Anhang und löst damit den Download einer Datei aus
einer gegnerischen Domäne aus.
• VA-6: Schädliche Umleitungsdomäne/IP-Adresse
• VA-7: Name der heruntergeladenen Schaddatei
• VC-2: MD-5-Hash der heruntergeladenen Schaddatei
•• VB-3: Mit der Datei wird eine Systemdatei durch eine schädliche Version überschrieben.
•• VB-4: Der Code in der Schaddatei wird ausgeführt und baut eine verschlüsselte Verbindung zu einem Schadserver über einen nicht standardmäßigen Port auf.
• VA-8: IP-Adresse des externen C2-Servers
• VA-9: Port des externen C2-Servers
• VA-10 Protokoll des externen C2-Servers
•• VB-5: Nach dem Aufbau der Verbindung werden große Mengen von Daten aus dem
System herausgeschleust.
Das V in den Indikatornamen deutet auf ihre variable Natur hin. Wie hier aufgezählt, gibt
es zehn variable elementare Indikatoren, zwei variable berechnete Indikatoren und fünf
variable Verhaltensindikatoren. Nun können wir uns Methoden überlegen, um diese Indikatoren in Signaturen für Erkennungsmechanismen aufzunehmen. Um eine Erkennung
für eine breite Skala von möglichen Angriffen zu ermöglichen, werden variable Indikatoren gewöhnlich wiederverwendet und kombiniert.
210 7 Erkennungsmechanismen, Einbruchs­indikatoren und Signaturen
•• VB-1 (VA-3/VA-4) VB-2 (VA-6) VB-4 (VA-8) VB-5 (VA-8): Snort-/Suricata-Regel, um
eine Kommunikaton mit IP-Adressen und Domänen zu erkennen, die eine schlechte
Reputation haben
•• VB-1 (VA-5/VC-1) VB-2 (VA-7/VC-2): Bro-Skript, um Dateien aus der Verbindung
herauszunehmen und ihre Namen und MD-5-Hashes mit denen auf einer Liste von
Dateinamen und MD-5-Hashes schlechter Reputation zu vergleichen.
•• VB-1 (VA-5/VC-1) VB-2 (VA-7/VC-2): Bro-Skript, um Dateien aus der Verbindung
herauszunehmen und in einer Sandbox zu platzieren, in der eine rudimentäre Malwareanalyse vorgenommen wird.
•• VB-2 (VA-6/VA-7/VC-2): HIDS-Signatur, um zu erkennen, dass der Browser von einem
Dokument aus gestartet wird.
•• VB-3: HIDS-Signatur, um zu erkennen, dass eine Systemdatei überschrieben wird
•• VB-4 (VA-9/VA-10) VB-5: Bro-Skript, um verschlüsselten Datenverkehr über einen
nicht standardmäßigen Port zu erkennen
•• VB-4 (VA-9/VA-10) VB-5: Snort-/Suricata-Regel, um verschlüsselten Datenverkehr
über einen nicht standardmäßigen Port zu erkennen
•• VB-5: Eigenes Skript, das anhand von Sitzungsdatenstatistiken umfangreichen ausgehenden Datenverkehr von Arbeitsstationen erkennt
Analytiker halten sich gewöhnlich auf dem neuesten Stand der Informationssicherheit,
z. B. anhand der Protokolle von entsprechenden Konferenzen sowie der Blogs und Tweets
von Branchenexperten. Dadurch kann ihre Organisation mit neuen Angriffstechniken
Schritt halten und ihre Verteidigungsmaßnahmen darauf einstellen. Dabei ist es äußerst
wertvoll, einen Angriff in variable Indikatoren zu zerlegen. Wenn plattformspezifische
Signaturen bereitgestellt werden, können daraus einzelne Indikatoren abgeleitet und für
die vorhandenen Erkennungsmechanismen genutzt werden. Das ist eine äußerst nützliche Übung für NSM-Analytiker. Sie hilft ihnen dabei, die Funktionsweise des Angriffs
besser zu verstehen und sich klar zu machen, wie der Erkennungsmechanismus eingesetzt
werden kann, um die einzelnen Phasen dieses Angriffs wirkungsvoll zu erkennen.
Die Bestandteile der variablen Indikatoren lassen sich für alle Arten der Erkennung einsetzen, aber am nützlichsten sind sie, um Dinge mit unbekannten Entitäten wahrzunehmen.
7.2.4 Evolution von Indikatoren und Signaturen
Softwareentwicklung ist gewöhnlich ein evolutionärer Prozess, in dem die Software als
»unreif« angesehen wird, bis sie vollständig getestet ist. Danach hat sie, während sie in
der Produktion eingesetzt wird, einen »reifen« Zustand, und wird schließlich »ausgemustert«, wenn sie nicht mehr nützlich ist. Ebenso wie Software haben auch Indikatoren und
Signaturen ein Verfallsdatum, und auch sie durchlaufen die Phasen »unreif«, »reif« und
»ausgemustert« (siehe Abb. 7.2).
7.2 Einbruchsindikatoren und Signaturen 211
Abbildung 7.2: Evolution von Indikatoren und Signaturen
Unreife Indikatoren und Signaturen sind solche, die erst neu entdeckt wurden, etwa durch
die interne Untersuchung eines Zwischenfalls oder aufgrund von Informationen einer
externen Quelle. In diese Kategorie fallen auch neu aufgestellte variable Indikatoren, die
noch nicht vollständig in eine Signatur für einen Erkennungsmechanismus umgesetzt
worden sind. Das Vertrauen, das die Organisation in unreife Indikatoren und Signaturen
setzt, kann zu Anfang stark schwanken, was vor allem von ihrer Quelle abhängt. Unreife
Indikatoren und Signaturen können sich auch häufig ändern und werden gewöhnlich erst
in einer Testumgebung bereitgestellt, bevor sie in der Produktion eingesetzt werden. Zu
diesem Test kann auch die Anwendung in verschiedenen Erkennungsmechanismen gehören, um herauszufinden, für wen sie am besten geeignet sind. Analytiker müssen diese
bereitgestellten Signaturen daher genau auf falsch positive oder falsch negative Ergebnisse
überwachen. In manchen Situationen ist es angebracht, Alarme aufgrund von unreifen Indikatoren und Signaturen nur von Analytikern der zweiten und dritten Ebene bearbeiten
zu lassen, von denen zu erwarten ist, dass sie mit der entsprechenden Vorsicht vorgehen.
Indikatoren und Signaturen, die sich für die NSM-Umgebung als nützlich erwiesen haben,
kein Übermaß an Fehlalarmen hervorrufen und auch keine Zwischenfälle übersehen, werden als »reif« eingestuft. Reife Indikatoren und Signaturen werden nicht mehr so häufig
revidiert wie unreife. Sie gelten als zuverlässig und stabil und können auch vertrauensvoll
mit anderen Indikatoren zu detaillierteren Verhaltungsindikatoren kombiniert werden,
um anspruchsvollere Signaturen zu erstellen. Jegliche Änderungen oder Revisionen an
reifen Indikatoren und Signaturen sollten dokumentiert werden.
Irgendwann ist ein Indikator oder eine Signatur nicht mehr wirkungsvoll oder wird nicht
mehr benötigt. Das kommt häufig im Zusammenhang mit Phishingkampagnen, mit
Drive-by-Downloads und mit den Steuerservern von Botnetzen vor. Das Prinzip der ordnungsgemäßen Archivierung und die Notwendigkeit rückblickender Analyse legen nahe,
dass Sie diese Elemente jedoch nicht einfach löschen sollen. Stattdessen werden nicht mehr
aktiv genutzte Indikatoren und Signaturen als »ausgemustert« betrachtet. Ein ausgemusterter Indikator wird nicht mehr in einer Signatur für einen Erkennungsmechanismus
bereitgestellt, eine ausgemusterte Signatur wird nicht mehr von einem Erkennungsmechanismus genutzt. Wenn es notwendig werden sollte, ausgemusterte Indikatoren oder
212 7 Erkennungsmechanismen, Einbruchs­indikatoren und Signaturen
Signaturen zu ändern und wiederzufinden, müssen sie wieder in den unreifen oder reifen
Zustand zurückversetzt werden.
7.2.5 Signaturen optimieren
Die Optimierung von Signaturen ist eine wichtige Aufgabe für Sicherheitsteams – und
zwar eine, die nie abgeschlossen ist. Dabei wird sichergestellt, dass die Indikatoren, auf denen die Signaturen beruhen, auf zuverlässige und wirkungsvolle Weise eingesetzt werden
und die Phasen der Indikatorevolution ordnungsgemäß durchlaufen. In manchen Fällen
lässt sich sehr leicht bestimmen, wie wirkungsvoll eine Signatur ist. Nehmen wir an, Sie
stellen eine Signatur mit neuen Indikatoren bereit, und sie fängt sofort an, die Bildschirme
aller Analytiker mit Tausenden von Alarmen zu überfluten. Das bedeutet, dass die Signatur höchstwahrscheinlich zu weit gefasst ist und noch umgearbeitet werden muss, um die
Fehlalarme auszuschließen. Allerdings lässt sich die Leistung von Signaturen nicht immer
so einfach feststellen. Wie vergleichen Sie beispielsweise zwei Signaturen, die demselben
Zweck dienen, und wie bestimmen Sie, welche davon die wirkungsvollere ist? Dabei können Ihnen Statistiken helfen.
Um die Reife und die Vertrauenswürdigkeit einer Signatur zu bewerten, müssen Sie vier
Aspekte berücksichtigen, nämlich wahr und falsch positive Ergebnisse sowie wahr und
falsch negative.
Wahr positiv (WP): Ein Alarm, der die angegebene Aktivität korrekt erkannt hat. Wenn
eine Signatur dazu dient, eine bestimmte Art von Malware zu erkennen, und beim Start
dieser Malware auf einem System ein Alarm ausgelöst wird, dann handelt es sich um ein
wahr positives Ergebnis. Das ist genau das, was wir mit unseren Signaturen erreichen
wollen.
Falsch positiv (FP): Ein Alarm, der die angegebene Aktivität fälschlicherweise erkannt hat,
also ein Fehlalarm. Wenn eine Signatur dazu dient, eine bestimmte Art von Malware zu
erkennen, und ein Alarm ausgelöst wird, obwohl diese Malware gar nicht vorhanden ist,
dann haben wir es mit einem falsch positiven Ergebnis zu tun.
Wahr negativ (WN): Es wird kein Alarm ausgelöst, wenn die angegebene Aktivität nicht
vorhanden ist. Wenn eine Signatur dazu dient, eine bestimmte Art von Malware zu erkennen, und kein Alarm ausgelöst wird, eben weil diese Malware nicht gestartet wurde, dann
haben wir es mit einem wahr negativen Ergebnis zu tun. Das ist ebenfalls eine wünschenswerte Reaktion. Wahr negative Ereignisse lassen sich im Rahmen der NSM-Erkennung
nur sehr schwer quantifizieren, aber es ist nicht unmöglich.
Falsch negativ (FN): Es wird kein Alarm ausgelöst, obwohl die angegebene Aktivität aufgetreten ist. Wenn eine Signatur dazu dient, eine bestimmte Art von Malware zu erkennen,
und kein Alarm ausgelöst wird, obwohl weil diese Malware auf dem System gestartet wurde, dann haben wir es mit einem falsch negativen Ergebnis zu tun. Das bedeutet, dass wir
etwas nicht erkennen, was wir hätten erkennen sollen – und das ist der schlimmstmögliche Fall. Die Anzahl falsch negativer Ereignisse lässt sich nur schwer berechnen, denn wie
7.2 Einbruchsindikatoren und Signaturen 213
wollen Sie darauf aufmerksam werden, wenn die Signaturen die betreffenden Aktivitäten
nicht bemerken? Dies ist einer der vielen Gründe, warum eine Post-mortem-Analyse nach
einem Zwischenfall so wichtig ist. Dabei gehen Sie den Vorfall systematisch durch, um zu
bestimmen, wann die Signatur eine Aktivität hätte erkennen sollen, und zeichnen Ihre
Ergebnisse auf.
Diese Daten sind schon für sich allein nützlich, um zu ermitteln, wie erfolgreich eine Signatur bei der Erkennung ist. Allerdings bieten diese Zahlen noch mehr Wert, wenn Sie sie
dazu heranziehen, die Genauigkeit der Signatur zu berechnen.
Genauigkeit
Die Genauigkeit einer Signatur, manchmal auch positiver Vorhersagewert genannt, ist ein
Maß für ihre Fähigkeit, zu wahr positiven Ergebnissen zu kommen. Berechnet wird sie als
Anteil der wahr positiven an sämtlichen positiven Ergebnissen (also sowohl wahr als auch
falsch positiven):
Genauigkeit = WP / (WP + FP)
Dafür lässt sich die Wahrscheinlichkeit dafür ermitteln, dass bei einem Alarm die erkannte
Aktivität auch tatsächlich aufgetreten ist. Wenn ein Alarm aufgrund einer Signatur mit
einer hohen Genauigkeit ausgelöst wird, ist es sehr wahrscheinlich, dass die betreffende
Tätigkeit korrekt erkannt wurde.
Stellen Sie sich eine Situation vor, in der ein und derselbe Netzwerkverkehr zwei verschiedene Alarme ausgelöst hat, die den Angriff auf zwei verschiedene Arten von Malware zurückführten. SID 1 in dem einen Alarm nennt Malware A als Übeltäter, SID 2 im anderen
Alarm dagegen Malware B. Wenn SID 1 eine Genauigkeit von 90 hat, SID 2 dagegen nur
eine Genauigkeit von 40, dann ist es wahrscheinlich, dass SID 1 die richtige Malware identifiziert hat.
Hinweis für Analytiker
Eine SID-Nummer (Signatur-ID) ist ein eindeutiger Bezeichner für eine Signatur.
Eine hohe Genauigkeit ist eine wünschenswerte Eigenschaft für Signaturen, und je höher
sie ist, umso vertrauenswürdiger ist die Signatur. Wenn Sie feststellen, dass eine Signatur
eine geringe Genauigkeit hat, dann sollten Sie versuchen, dies zu korrigieren, indem Sie
die Signatur weiterentwickeln, weitere Indikatoren hinzufügen oder sie in Kombination
mit anderen Signaturen einsetzen.
Wenn Sie keine eigene Anwendung für solche Statistiken haben, können Sie sie ziemlich
einfach in einem Arbeitsblatt oder einer CSV-Datei verfolgen, wie das Beispiel in Tabelle 7.1
zeigt.
214 7 Erkennungsmechanismen, Einbruchs­indikatoren und Signaturen
Tabelle 7.1: Signaturstatistiken
Indikator-­
GUID
IndikatorRevisionsnummer
Bereit­
stellung
Änderungsdatum
WP
FP
WN
FN
60003023
1
Snort-Signatur:
1000492
6/19/2013
1
432
0
0
60003023
2
Snort-Signatur:
1000492
6/23/2013
5
3
0
0
60003024
1
Snort-Signatur:
1000493
6/23/2013
2
17
0
0
60003025
1
Snort-Signatur:
1000494
6/25/2013
1
2
0
0
60003026
1
Snort-Signatur:
1000495
6/25/2013
3
0
0
1
60003026
2
Snort-Signatur:
1000495
6/28/2013
1
0
0
0
Anhand dieser Statistiken können Sie bestimmen, wie vertrauenswürdig eine Signatur ist.
Das wirkt sich darauf aus, wie Sie reagieren, wenn aufgrund dieser Signatur ein Alarm
ausgelöst wird, und wie viel Aufwand Sie betreiben, um die Signatur zu optimieren und
ihre Zuverlässigkeit zu erhöhen. Es gibt noch verschiedene andere Techniken und Statistiken, mit denen Sie bestimmen können, wie wirkungsvoll eine Signatur ist. Für mich
hat die Genauigkeit in vielen verschiedenen Organisationen immer gleichbleibend gut
funktioniert.
7.2.6 Entscheidende Kontextinformationen für Indikatoren und
Signaturen
Ohne Kontext sind Indikatoren und Signaturen nicht besonders sinnvoll. Bei einem neuen Alarm sollten Analytiker als eine der ersten Maßnahmen den Kontext der Signatur und
den Kontext der in ihr enthaltenen Indikatoren untersuchen. Die Natur des Kontextes, der
für eine Signatur oder einen Indikator bereitgestellt werden kann, kann sehr stark schwanken, aber auf jeden Fall ist er von entscheidender Bedeutung für die Untersuchung eines
Zwischenfalls. Es ist wichtig, eine Norm für ein Minimum an entscheidenden Kontext­
informationen für Indikatoren und Signaturen aufzustellen. Dadurch wird sichergestellt,
dass die Indikatoren und Signaturen eindeutig und rückverfolgbar sind und bei einem
Einbruch, einem Audit oder einem anderen Vorfall, bei dem es auf Genauigkeit ankommt,
korrekt angesprochen werden können. Es handelt sich dabei um folgende entscheidende
Angaben:
7.2 Einbruchsindikatoren und Signaturen 215
•• Eindeutiger Bezeichner: Ein Wert, der dazu dient, den Indikator oder die Signatur
eindeutig zu identifizieren. Diese Bezeichner dürfen nicht mehrfach verwendet werden. Die meisten Organisationen verwenden einfach automatisch inkrementierte
laufende Nummern oder zufällig generierte global eindeutige Bezeichner (Globally
Unique Identifiers, GUIDs) für Indikatoren. Die Bezeichner für Signaturen hängen
gewöhnlich von dem Erkennungsmechanismus ab, in dem sie eingesetzt werden. Am
gebräuchlichsten ist eine SID-Nummer (Signatur-ID). Diese Art der Benennung hat
auch den Vorteil, dass Sie in beliebigen Kommunikationsmedien auf bestimmte Indikatoren oder Signaturen verweisen können, ohne sie ausführlich beschreiben zu
müssen. Das verhindert auch Fehlalarme durch die Erwähnung von Indikatoren und
Signaturen in E-Mails oder ähnlichen Kommunikationsformen.
•• Autor: Der Analytiker, der den Indikator oder die Signatur erstellt oder hinzugefügt
hat. Wenn ein Alarm ausgelöst wird und Unklarheit über den Indikator oder die Signatur selbst oder die Implementierung herrscht, bietet diese Angabe die Gelegenheit,
Informationen beim Urheber einzuholen.
•• Erstellungsdatum: Das Datum, an dem der Indikator oder die Signatur erstellt wurde.
Falls es aus einer fremden Quelle stammt, kann dies das Datum sein, an dem es Ihrem
internen System hinzugefügt wurde.
•• Änderungsdatum: Das Datum der jüngsten Änderung an dem Indikator oder der
Signatur. Ideal wäre es, jegliche Änderungen an Indikatoren und Signaturen zu dokumentieren. Das werden wir weiter hinten ansprechen.
•• Quelle: Die Quelle, aus der der Indikator oder die Signatur stammt. Das kann eine andere
Organisation, ein URL, eine interne Fallnummer oder sogar ein anderer Indikator sein.
•• Typ: Die Art des Indikators. Host- oder Netzwerkindikator, statischer oder variabler
Indikator, elementarer, berechneter oder Verhaltensindikator. Bei Signaturen sind dies
Typen wie Snort, Suricata, Bro, Antivirus usw.
•• Klassifizierung: Die allgemeine Klasse, in die der Indikator oder die Signatur fällt. Indikatoren können als IP-Adressen, Hashwerte, Dateinamen, Betreffzeilen, DNS-Namen
usw. klassifiziert sein. Bei Signaturen handelt es sich um die Kategorie der Bedrohung,
um deren Erkennung es jeweils geht, also etwa Malwareaktivitäten, Botnetz-Steuerserver, Exploits, Phishing usw.
•• Evolutionsphase: Der Zustand der Entwicklung, in dem sich der Indikator oder die
Signatur gerade befindet, also unreif, reif oder ausgemustert.
•• Vertrauenswürdigkeit: Eine Angabe, wie viel Vertrauen dem Indikator oder der Signatur geschenkt werden kann. Damit wird bestimmt, wie zuverlässig das Element ist
und wie wahrscheinlich es ist, dass bei einem dadurch ausgelösten Alarm tatsächlich
ein Zwischenfall vorliegt. Bei dieser Abschätzung können mehrere Faktoren berücksichtigt werden, darunter die Genauigkeit, die Quelle und ihr Entwicklungsstand. Es
ist nicht ungewöhnlich, dass sich die Vertrauenswürdigkeit von Indikatoren und Signaturen mit der Zeit ändert. Ausgedrückt wird sie gewöhnlich durch eine Zahl (1 bis
100) oder eine relative Einschätzung (niedrig, mittel, hoch, sehr hoch).
•• Indikator/Signatur: Der eigentliche Indikator bzw. die Signatur in ihrem eigenen Format.
216 7 Erkennungsmechanismen, Einbruchs­indikatoren und Signaturen
Neben der Aufbewahrung und Klassifizierung von Indikatoren und Signaturen ist auch
ein einheitliches Vorgehen äußerst wichtig. Um diese Einheitlichkeit zu erreichen, ist es
unverzichtbar, den Prozess gut zu dokumentieren und in der Organisation häufig zu üben.
7.3
Indikatoren und Signaturen verwalten
Die Anzahl der Indikatoren und Signaturen, die eine Organisation verwaltet, kann im
Laufe der Zeit stark wachsen. Es ist wichtig, dass eine Organisation eine Strategie dafür
entwickelt, wie diese Indikatoren und Signaturen aufbewahrt werden, wie der Zugriff darauf erfolgt und wie sie weitergegeben werden.
Die meisten Organisationen speichern Indikatoren und Signaturen ausschließlich in dem
Erkennungsmechanismus, in dem sie eingesetzt werden. Wenn eine Organisation beispielsweise Snort verwendet, um den Zugriff auf bekanntermaßen schädliche Domänen
(elementare Indikatoren) zu erkennen und zu protokollieren, dann speichert sie diese Indikatoren als Snort-Signaturen dort, wo Snort unmittelbar darauf zurückgreift. Das ist
zwar die einfachste Möglichkeit aber sie schränkt die Möglichkeiten für die Verwendung
der Indikatoren ein. Es kann auch eine einfache Weitergabe einzelner Indikatoren oder
ihre Konvertierung in Signaturen für einen anderen Erkennungsmechanismus unmöglich
machen. Um Indikatoren und Signaturen bestmöglich zu nutzen, sollten Sie sich zu ihrer
Verwaltung daher nach folgenden empfohlenen Vorgehensweisen richten:
Rohdatenformat. Am einfachsten lässt sich mit Indikatoren arbeiten, wenn sie in ihrer
ursprünglichen Form vorliegen. Es sollte immer möglich sein, auf Indikatoren ohne zusätzliche Inhalte und ohne irrelevante Verarbeitungsschritte zuzugreifen. Das sorgt dafür,
dass die Indikatoren übertragbar sind, leicht von automatischen und selbst geschriebenen
Tools untersucht werden können und sich Signaturen verschiedener Erkennungsmechanismen einsetzen lassen. Das bedeutet beispielsweise, dass IP-Adressen und Dateihashes
als Klartext vorliegen sollten, Binärdaten dagegen im Binärformat.
Leichter Zugriff. Analytiker müssen in der Lage sein, ohne großen Aufwand auf Indikatoren und Signaturen zuzugreifen und sie zu bearbeiten. Wenn sie erst eine Menge komplizierter Schritte durchlaufen müssen, bevor sie neue Indikatoren hinzufügen oder die
Quelle eines Indikators herausfinden können, dann verschlingt das wertvolle Zeit. Es kann
Analytiker sogar davon abhalten, sich mit den Indikatoren und Signaturen zu beschäftigen, und das wäre das Letzte, was Sie wollen.
Leicht auffindbar. Es dauert nicht lange, bis ein Verzeichnis oder eine Datenbank voller
Indikatoren und Signaturen zu groß geworden ist, um darin manuell zu suchen. Um
Analytikern eine schnelle Untersuchung zu ermöglichen, müssen die Indikatoren und
Signaturen so gespeichert werden, dass sie leicht aufzufinden sind. Das bedeutet, dass es
eine Möglichkeit geben sollte, die Indikatoren und Signaturen als solche zu finden, aber
auch, um nach den zusammen damit gespeicherten Kontextdaten zu suchen, z. B. nach
dem Erstellungsdatum, der Quelle oder dem Typ. Bei der Speicherung in einer Datenbank
7.3 Indikatoren und Signaturen verwalten 217
kann dies über einen Datenbankclient oder ein einfaches Web-Front-End geschehen. Sind
die Indikatoren oder Signaturen in linearen Dateien gespeichert, lassen sich mit LinuxBefehlszeilenwerkzeugen wie grep Lösungen erstellen.
Dokumentation von Revisionen. Signaturen werden häufig revidiert, etwa wenn sie zu viele
Fehlalarme verursachen, wenn sie eine schädliche Aktivität nicht erkennen oder wenn
sich die Strategien des Gegners oder die Angriffstechniken geändert haben. In jedem Fall
sollten die Revision, die Person, die sie durchgeführt hat, und das Datum aufgezeichnet
werden, damit jegliche Probleme aufgrund dieser Änderung angegangen werden können.
Idealerweise sollte auch der Grund der Revision dokumentiert werden.
Dokumentation der Bereitstellung. Der Zweck eines Indikators besteht darin, in einer Signatur für einen Erkennungsmechanismus eingesetzt zu werden. Wenn das geschieht, sollte
festgehalten werden, für welchen Erkennungsmechanismus der Indikator verwendet wird.
Dadurch können Analytiker verstehen, wie die NSM-Infrastruktur bei der Nutzung dieses
Indikators verwendet wird. Es verhindert auch, dass Indikatoren versehentlich mehrfach
im gleichen Erkennungsmechanismus bereitgestellt werden. Dazu wird oft eine einfache
Zuordnung des Indikator-GUIDs zu einer SID verwendet.
Datensicherung. Inzwischen sollte Ihnen klar geworden sein, wie wichtig Indikatoren und
Signaturen für die NSM-Erkennung sind. Diese Daten sind von entscheidender Bedeutung für den Erfolg der NSM und sollten daher entsprechend sorgfältig gesichert werden.
Dazu gehört auch eine auswärtige Lagerung der Sicherung als Vorsichtsmaßnahme gegen
eine Katastrophe, die den Hauptsitz beeinträchtigt.
7.3.1 Einfache Verwaltung von Indikatoren und Signaturen mit
CSV-Dateien
Organisationen unterschiedlicher Größe setzen jeweils andere Techniken ein, um Indikatoren und Signaturen zu speichern und zu verwalten. Einige nutzen kommerzielle Lösungen, während andere selbst geschriebene Web-Front-Ends für eine Datenbank bereitstellen.
Alle diese Methoden sind sicherlich wirkungsvoll, aber es erfordert schon einen gewissen
Reifegrad der Organisation, bevor sie umgesetzt werden können. Aber selbst kleine und
weniger reife Sicherheitsteams brauchen eine Möglichkeit, Indikatoren und Signaturen zu
verwalten.
Es mag sich zwar primitiv anhören, aber eine solche Verwaltung lässt sich bereits auf
durchaus wirkungsvolle Weise mithilfe von CSV-Dateien (Comma-Separated Values, also
»durch Kommata getrennte Werte«) erreichen. In solchen Dateien sind die Daten in Zeilen und Spalten angeordnet, wobei die Spalten durch Kommata und die Zeilen durch
Zeilenumbrüche voneinander getrennt sind. Dieses Format ist für viele Arten von Daten
hervorragend geeignet, da es sich mit den im Lieferumfang von Linux enthaltenen Befehlszeilenwerkzeugen wie Grep, Cut, Sed, Awk und Sort leicht lesen und analysieren lässt.
CSV-Dateien können Sie auch in Microsoft Excel, Libre Office/Open Office Calc und den
meisten anderen grafischen Tabellenkalkulationsprogrammen öffnen.
218 7 Erkennungsmechanismen, Einbruchs­indikatoren und Signaturen
Um Indikatoren und Signaturen anhand der hier vorgestellten empfohlenen Vorgehensweisen wirkungsvoll zu verwalten, brauchen Sie mindestens drei CSV-Dateien, nämlich
die Statistikdatei, die wir uns schon zuvor angesehen haben (Tabelle 7.1), eine Masterliste
und eine Revisionstabelle.
7.3.2 Masterliste der Indikatoren und Signaturen
Die wichtigste CSV-Datei ist die Masterliste, denn in ihr sind die Indikatoren und Signaturen gespeichert. Sie enthält Felder für alle zuvor erwähnten kritischen Angaben sowie
Felder zum Nachvollziehen der Bereitstellung. Ein Beispiel sehen Sie in Tabelle 7.2.
Diese Liste kann auf zwei einfache Weisen durchsucht werden. Erstens können Sie ein
grafisches Tabellenkalkulationsprogramm wie Microsoft Excel verwenden und darin
eine einfache Sortierung vornehmen oder mit (Strg) + (F) nach bestimmten Werten
suchen. Je größer die CSV-Datei wird, umso schwieriger wird das jedoch. Daher verwenden Analytiker gewöhnlich Linux-Befehlszeilenwerkzeuge, um solche Listen abzufragen.
Nehmen wir an, es wurde ein Alarm zur Signatur SID 710031 generiert. Um weitere Informationen über diese Signatur und die damit verknüpften Indikatoren zu gewinnen,
können Sie die Masterdatei wie folgt mit Grep nach allen Vorkommen der betreffenden
SID durchsuchen:
grep 7100031 master_ioc_list.csv
Das Ergebnis dieses Befehls sehen Sie in Abb. 7.3. Unsere Suche gibt sowohl die Signatur
als auch den darin verwendeten Indikator zurück.
Abbildung 7.3: Durchsuchen der CSV-Datei nach einer SID
Manchmal kann es auch praktisch sein, die Spaltenköpfe mit auszugeben. Grep jedoch
sieht nur Daten und hat keine Vorstellung von Spalten, sodass es dazu nicht in der Lage
ist. Sie könnten Sed oder Awk mit Mustererkennung verwenden, es ist aber auch möglich,
einfach mit dem Befehl head die erste Zeile auszugeben, bevor Sie die Grep-Suche durchführen:
head -1 master_ioc_list.csv && grep 7100031 master_ioc_list.csv
Da die Befehle durch zwei kaufmännische Und-Zeichen (&&) verknüpft sind, werden sie
nacheinander ausgeführt. Abb. 7.4 zeigt das Ergebnis.
3/18/2013
3/18/2013
3/19/2013
3/24/2013
3/20/2013
3/24/2013
3/18/2013
10003 Sanders 3/18/2013
10004 Sanders 3/19/2013
3/20/2013
10005 Randall
10006 Sanders 3/20/2013
10007 Sanders 3/21/2013
3/20/2013
3
1
4
1
1
1
2
Protokoll/
Port
Protokoll/
Port
IP-Adresse
Verhalten/
variabel
Verhalten/
variabel
Verhalten/
variabel
Elementar/
statisch
Elementar/
statisch
Elementar/
statisch
Domäne
E-MailAdresse
Berechnet/
statisch
Typ
MD5
Klasse
Interne
Statisch
Diskussion
RSS-Feed
Analytiker
ZeusTracker
Fall 1498
MalwareDomänen­
liste
Fall 1492
Erstellungs­ Änderungs­
Rev. Quelle
datum
datum
Sanders 3/17/2013
10002 Smith
10001
GUID Autor
Tabelle 7.2: Masterliste der Indikatoren und Signaturen
Hoch
Sehr hoch
Mittel
Sehr hoch
Mittel
Unreif Niedrig
Reif
42039
18ee64a6bd
Eigenes
SiLK-Skript
SnortSignatur
7100032
Verhältnis des
ausgehenden
Datenverkehrs
größer als 4:1
SSH/9966
Eigenes
SiLK-Skript
SuricataSignatur
7100038
Verschlüsselter Bro-Skript
Datenverkehr
über nicht standardmäßigen
Port
192.0.2.99
com
chris@appliednsm.
SnortSignatur
7100031
Signature
88512501f4c
appliednsm.
com
Antivirus
Bereit­
stellung
e0b359e1712
Vertrauens­
Indikator
würdigkeit
Unreif Mittel
Reif
Reif
Reif
Reif
Phase
7.3 Indikatoren und Signaturen verwalten 219
220 7 Erkennungsmechanismen, Einbruchs­indikatoren und Signaturen
Abbildung 7.4: Ausgabe mit Spaltenköpfen
Wenn wir nur die Signatur selbst daraus gewinnen wollen, können wir das Ergebnis des
vorherigen Befehls (ohne die Spaltenköpfe) an einen weiteren Grep-Befehl übergeben, der
nach Zeilen mit dem Text sid sucht. Dadurch werden nur die Signaturen gefunden, nicht
die Indikatoren. Diese Ausgabe wiederum leiten wir mit dem Pipe-Symbol | an einen
Cut-Befehl, in dem wir mit dem Schalter -d das Komma als Trennzeichen angeben und
dann mit -f die elfte Spalte auswählen. Der Befehl sieht insgesamt wie folgt aus:
grep 7100031 master_ioc_list.csv | grep sid | cut –d , –f11
Das gleiche Ziel können wir auch mit dem Befehl awk erreichen. Mit dem Schalter -F können wir Awk anweisen, eine bestimmte Spalte auszugeben:
grep 7100031 master_ioc_list.csv | grep sid | awk –F '{print $11}'
Diese Techniken lassen sich noch erweitern, um die Suche zu verfeinern. Nehmen wir an,
Sie wollen alle E-Mail-Adressen aus der Liste abrufen, die noch aktiv als Indikatoren verwendet werden (also nicht ausgemustert sind), um sie in einem Erkennungsmechanismus
bereitzustellen. Das können Sie mit folgendem Befehl erreichen:
grep –v retired master_ioc_list.csv | grep IP | cut –d , -f11
Der Schalter -v in der ersten grep-Anweisung besagt, dass alles gesucht werden soll, was
nicht mit dem angegebenen Muster übereinstimmt. Hier weisen wir Grep an, alle Indikatoren aufzuführen, die nicht ausgemustert (»retired«) sind, also alle reifen und unreifen
Indikatoren.
Vorsicht
Selbst sauber formatierte CSV-Dateien können unerwartete Befehlsausgaben
hervorrufen, wenn für die Daten nicht genügend Sorgfalt aufgewendet wird.
Stellen Sie sich einmal vor, eine Signatur enthielte ein Komma. Dadurch würden
die hier vorgestellten Tools bei der Zählung der Spalten durcheinanderkommen.
Seien Sie sich immer bewusst, dass in einer CSV-Datei Trennzeichen am falschen
Ort stehen können. Es kann auch angebracht sein, bestimmte Zeichen zu ersetzen, um Verarbeitungsfehler zu vermeiden.
7.3 Indikatoren und Signaturen verwalten 221
Als Nächstes suchen wir nach allen Indikatoren, bei denen es sich um Domänennamen
handelt und die aktiv im IDS Snort bereitgestellt sind. Das erreichen wir mit folgendem
Befehl:
head -1 master_ioc_list.csv && grep –v retired master_ioc_list.csv | grep
Domain | grep Snort
Die Suchbegriffe »Domain« und »Snort« stehen hier in Großbuchstaben. Standardmäßig
unterscheidet Grep zwischen Groß- und Kleinschreibung, was hier praktisch ist, um nur
die gewünschten Einträge zu finden und nicht auch andere Stellen, in denen sie mit kleinem Anfangsbuchstaben vorkommen. Wenn Sie bei der Suche nicht zwischen Groß- und
Kleinschreibung unterscheiden wollen, verwenden Sie die Befehlsoption -i. Wichtig ist,
dass Sie wissen, wie die Einträge geschrieben sind, nach denen Sie mit Grep suchen wollen.
Im Zweifelsfall verwenden Sie -i.
Um die CSV-Datei zu ergänzen oder zu ändern, können Sie einen Befehlszeilen-Texteditor
nach Ihrem Geschmack verwenden, z. B. Vim, Emacs oder Nano. Achten Sie dabei darauf,
dass Sie nicht versehentlich Zeileneinbrüche einfügen, was die Untersuchung erschweren
würde.
7.3.3 Revisionstabelle für Indikatoren und Signaturen
Ich habe bereits erwähnt, dass Indikatoren und Signaturen häufig revidiert werden und
dass es wichtig ist, diese Revisionen zu dokumentieren. Dazu verwenden Sie eine zweite
CSV-Datei neben der Masterliste. Sie sollte sehr einfach gehalten sein und nur den eindeutigen Bezeichner des Indikators oder der Signatur, das Datum der Änderung, den Urheber
der Änderung, die Revisionsnummer, die Nummer der geänderten Spalte, den alten und
den neuen Wert der geänderten Daten sowie eine Begründung für die Änderung enthalten. Damit lässt sich die Entwicklung eines Indikators oder einer Signatur nachvollziehen,
insbesondere, wenn ein Fehler aufgetreten ist. Dokumentieren Sie nicht nur Änderungen
am Indikator oder der Signatur selbst, sondern auch Änderungen der Kontextinformationen, z. B. der Erkennungsmethode, für die das Element bereitgestellt wird. Ein Beispiel für
eine solche CSV-Datei finden Sie in Tabelle 7.3.
Diese CSV-Datei soll nicht sämtliche Informationen enthalten, sondern zusammen mit
der Masterliste verwendet werden. Mit Befehlen wie dem folgenden können Sie sich dann
den Änderungsverlauf eines Elements ansehen:
Abbildung 7.5: Änderungsverlauf des Indikators 10005
Autor
Sanders
Sanders
Randall
Smith
Sanders
Sanders
GUID
10001
10005
10005
10005
10007
10007
3/24/2013
3/22/2013
3/24/2013
3/21/2013
3/21/2013
3/20/2013
Datum
3
2
4
3
2
2
Revi­
sion
Indikator
Indikator
Phase |
Vertrauen
Bereit­
stellung
Typ |
Indikator
Vertrauen
Geändertes Feld
Tabelle 7.3: Revisionstabelle für Indikatoren und Signaturen
Verhältnis des
ausgehenden Daten­
verkehrs größer als 3:1
Verhältnis des
ausgehenden
Datenverkehrs größer
als 2:1
Wenige
Fehlalarme.
Wird weiterhin
überwacht.
Zu viele
Fehlalarme.
Immer noch
zu viele
Fehlalarme.
Verhältnis des
ausgehenden Daten­
verkehrs größer als 3:1
Verhältnis des
ausgehenden Daten­
verkehrs größer als 4:1
Skript fertig
gestellt.
Neue
Informationen
ergänzt.
Funktioniert
sehr gut.
Keine
Fehlalarme.
Hinweis
Reif | Mittel
Bro-Skript
NULL
Unreif | Niedrig
Protokoll/Port |SSH/9966
Hoch
Neuer Wert
Port | 9966
Mittel
Alter Wert
222 7 Erkennungsmechanismen, Einbruchs­indikatoren und Signaturen
7.4 Frameworks für Indikatoren und Signaturen 223
Wenn Sie noch nie mit Linux-Befehlszeilenwerkzeugen gearbeitet haben, kann das zunächst ziemlich mühselig sein und sogar einschüchternd wirken. Je mehr Erfahrung Sie
gewinnen, umso mehr wird Ihnen der Umgang mit diesen Tools jedoch zur zweiten Natur.
Die beste Möglichkeit zum Lernen besteht darin, sich mit diesen Werkzeugen zu beschäftigen und verschiedene Sachen auszuprobieren, bis Sie herausgefunden, haben, wie sie funktionieren. Irgendwann werden Sie dabei an die Grenzen stoßen, die Werkzeugen wie Grep
gesetzt sind, und damit beginnen, Tools wie Sed und Awk für anspruchsvollere Aufgaben
einzusetzen. Solide Kenntnisse in diesen Programmen sind für Analytiker unverzichtbar.
Mit genügend Wissen können Sie die Tools sogar in Skripte einsetzen, um häufig vorkommende Aufgaben zu automatisieren.
CSV-Dateien sind zwar schön einfach, aber diese Einfachheit bedeutet auch, dass Sie dem
Zustand der Daten besondere Aufmerksamkeit schenken müssen. Da die meisten Eingaben und Änderungen an diesen Dateien mithilfe eines Texteditors vorgenommen werden,
gibt es keine Vorkehrungen, um sicherzustellen, dass die Daten das richtige Format haben.
Das kann dazu führen, dass ein Analytiker versehentlich die Formatierung der CSV-Datei
durcheinanderbringt oder Daten in die falsche Spalte schreibt. Aus diesem Grund sind
Sicherungskopien der Dateien ein Muss. Es ist auch sehr zu empfehlen, die Daten regelmäßig auf korrekten Zustand zu überprüfen. Wenn Ihre Organisation auf diese Dateien
angewiesen ist, dann lohnt es sich, Zeit in ein Skript zu investieren, das die Fehlerfreiheit
der Dateien garantieren kann. Mit der CSV-Bibliothek für Python können Sie ein solches
Skript relativ schnell schreiben.
Vorlagen für diese CSV-Dateien finden Sie auf http://www.appliednsm.com/resources.
7.4
Frameworks für Indikatoren und Signaturen
Eines der größten Probleme für Personen, die auf dem Gebiet der Informationssicherheit
arbeiten, ist das Fehlen eines allgemeinen Frameworks, um Indikatoren und Signaturen
zu erstellen, zu verwalten und weiterzugeben. Alle benutzen Indikatoren und Signaturen,
aber jeder hat seine eigenen Methoden, um sie zu ordnen und zu speichern. Daher sind
Indikatoren und Signaturen nicht übertragbar und lassen sich nicht so einfach anderen
Organisationen zur Verfügung stellen. Die Daten selbst, also etwa IP-Adressen, lassen sich
zwar oft sehr einfach weitergeben, aber wenn es darum geht, Kontextinformationen für
andere bereitzustellen, wird es schwierig.
In den letzten Jahren hat es einige Versuche gegeben, Frameworks für die gemeinsame
Nutzung von Indikator- und Signaturdaten aufzustellen.
7.4.1 OpenIOC
Einer der größten Fortschritte auf dem Weg zu einem gemeinsamen Framework für Informationen über Bedrohungen ist das Projekt OpenIOC von Mandiant. Ursprünglich
224 7 Erkennungsmechanismen, Einbruchs­indikatoren und Signaturen
wurde es entwickelt, um es den Produkten von Mandiant zu ermöglichen, Informationen zu kodifizieren und dadurch rasch auf mögliche Sicherheitsvorfälle zu untersuchen.
Im Jahr 2010 wurde es als standardisiertes Open-Source-Schema für die Weitergabe von
Informationen über Bedrohungen veröffentlicht.
Im Grunde genommen ist OpenIOC ein XML-Schema, mit dem die technischen Merkmale schädlicher Aktivitäten beschrieben werden. Mithilfe von OpenIOC können Sie
Einbruchs­indikatoren zusammen mit vielen Kontextinformationen verwalten, die erforderlich sind, um die Indikatoren wirkungsvoll einzusehen. Ein Beispiel für IOC sehen Sie
in Abb. 7.6.
Abbildung 7.6: Ein einfacher Indikator im XML-Format von OpenIOC
In diesem Indikator sind die folgenden Kontextinformationen gespeichert:
••
••
••
••
••
••
••
••
••
••
9ad0ddec-dc4e-4432-9687-b7002806dcf8 – Ein eindeutiger Bezeichner
PHISH-UPS-218934 – Eine Kurzbeschreibung bzw. ein zusätzlicher Bezeichner
Part of the UPS Phishing scheme reported on 12/4. – Eine ausführliche Beschreibung
Chris Sanders – Der Autor
2013-02-20 T01:02:00 – Erstellungsdatum und -uhrzeit des Indikators
http://www.appliednsm.com – Die Quelle des Indikators
Mature – Die Phase des Indikators im Lebenszyklus (»reif«)
Atomic – Die Art des Indikators (»elementar«)
E-Mail/Subject – Die Klassifizierung des Indikators
UPS Alert: Shipment Delayed – Der eigentliche Indikator, hier die Betreffzeile einer
E-Mail.
7.4 Frameworks für Indikatoren und Signaturen 225
Auf einem Windows-Computer besteht die einfachste Möglichkeit, Indikatoren im
OpenIOC-Format zu erstellen und zu bearbeiten, darin, den kostenlosen OpenIOC
­Editor von Mandiant zu nutzen. Dieses Programm lässt sich ziemlich einfach benutzen und ermöglicht es Ihnen, Indikatoren von Grund auf neu zu erstellen sowie vorhandene Indikatoren zu ändern.
Abbildung 7.7: Der OpenIOC Editor für Windows von Mandiant
Wenn Sie OpenIOC Editor zum ersten Mal öffnen, werden Sie aufgefordert, Ihr Verzeichnis mit den Indikatoren auszuwählen. Anschließend sehen Sie einen Bildschirm wie den
in Abb. 7.7. Die Oberfläche von OpenIOC Editor besteht aus drei Teilen. Der linke Bereich
enthält eine Liste der Indikatoren in Ihrem Indikatorenverzeichnis. Wenn Sie dort auf einen Indikator klicken, werden die beiden anderen Bereiche ausgefüllt. Im oberen rechten
Bereich sehen Sie alle Informationen über den Indikator wie den Namen, den Autor, den
GUID, das Erstellungs- und das Änderungsdatum, eine Beschreibung sowie jegliche anderen Angaben, die Sie definiert haben, z. B. Quelle, Phase oder Typ. Im unteren rechtern
Bereich wird der Indikator selbst angezeigt. Dabei können auch mehrere Indikatoren mit
einem logischen UND oder ODER verknüpft sein.
Der OpenIOC Editor behandelt jeden Indikator als eine eigene Datei. Wenn Sie einen
neuen Indikator anlegen, finden Sie ihn daher in Form einer Datei in Ihrem Indikatorenverzeichnis.
Leider gibt es den OpenIOC Editor zur Zeit der Abfassung dieses Buches nur für Windows. Wenn Sie eine *nix-Plattform verwenden, wie es unter NSM-Analytikern üblich ist,
226 7 Erkennungsmechanismen, Einbruchs­indikatoren und Signaturen
bleibt das Erstellen und Bearbeiten von Indikatoren in diesem Format daher Handarbeit.
Alternativ können Sie den OpenIOC Editor auch in einer virtuellen Maschine oder mithilfe von WINE ausführen.
Die meisten kommerziellen Produkte von Mandiant können mit Indikatoren in diesem
Format umgehen. Darüber hinaus gewinnt der OpenIOC-Standard immer mehr an Verbreitung. Es ist nur eine Frage der Zeit, bis Tools zur Verwaltung von OpenIOC-Indikatoren allgemein erhältlich werden.
Auf http://www.openioc.org erfahren Sie mehr über das OpenIOC-Format. Dort können
Sie auch das XML-Schema und sogar einige Beispielindikatoren herunterladen.
7.4.2 STIX
STIX (Structured Threat Information eXpressions) ist ein von der Community getragenes, von MITRE für das US-Heimatschutzministerium entwickeltes Open-Source-Projekt
zur Standardisierung von Informationen über Bedrohungen, das bei staatlichen Stellen
und in der Rüstungsbranche immer mehr an Beliebtheit gewinnt.
Die Architektur von STIX basiert auf unabhängigen Konstrukten und ihren Beziehungen
(siehe Abb. 7.8).
Abbildung 7.8: Die STIX-Architektur
Den Dreh- und Angelpunkt dieser Architektur bilden Observablen (»beobachtbare Elemente«), die als statusbehaftete Eigenschaften oder messbare Ereignisse im Zusammen-
7.4 Frameworks für Indikatoren und Signaturen 227
hang mit dem Betrieb von Computern und Netzwerken definiert werden. Dabei kann
es sich um einen Dienst handeln, der gestoppt wird, um einen Dateinamen, um ein
System, das neu gestartet wird, oder um den Aufbau einer Verbindung. Diese Observablen werden in einem XML-Format gespeichert, das die Sprache CybOX verwendet,
ein weiteres MITRE-Projekt. Abb. 7.9 zeigt ein Beispiel für eine Observable, in diesem
Fall eine IPv4-Adresse mit einigen damit in Zusammenhang stehenden Objekten, die
anhand ihrer global eindeutigen Bezeichner angegeben sind.
Abbildung 7.9: Eine STIX-Observable für eine IP-Adresse mit zugehörigen Objekten
Im STIX-Framework können Observablen mit Inikatoren, Zwischenfällen, TTPs, spezifischen Bedrohungsakteuren, Feindkampagnen, bestimmten Zielen, Datenkennzeichnungen und Maßnahmenm verknüpft werden. Zusammengenommen bilden all diese
Elemente mehr als nur ein einfaches Verwaltungssystem für Indikatoren, nämlich ein
vollständiges Verwaltungssystem für Informationen über Bedrohungen.
Indikatoren sind Darstellungen möglicherweise anomaler Aktivitäten und werden durch
die Kombination von Observablen gebildet. Abb. 7.10 zeigt einen Indikator, der Domänen
auf einer Beobachtungsliste enthält.
Abbildung 7.10: Ein STIX-Indikator mit Domänen auf einer Beobachtungsliste
228 7 Erkennungsmechanismen, Einbruchs­indikatoren und Signaturen
Tatsächlich besteht dieser Indikator nur aus einer einzigen Observablen, nämlich der
Liste von Domänennamen. Dies ist ein Beispiel für einen elementaren Indikator im
STIX-Framework. Indikatoren können beliebig viele Observablen enthalten, wodurch
das Framework auch für Verhaltensindikatoren geeignet ist. Durch die Verknüpfung der
Indikatoren mit den anderen STIX-Konstrukten bieten sich Ihnen viele Möglichkeiten.
Zum Zeitpunkt der Abfassung dieses Buches gab es nur zwei Möglichkeiten, STIX-Objekte
zu erstellen, zu bearbeiten und zu verwalten. Die eine besteht darin, einen vor kurzem
veröffentlichten Satz von Python-Bindungen nutzen, um eigene Python-Anwendungen
zu schreiben. Ansonsten können Sie auch auf einen einfachen Text- oder XML-Editor
z­ urückgreifen.
Das STIX-Potential bietet sehr viel Potenzial. Neben DHS wird auch STIX zurzeit von
mehreren Organisationen beurteilt, darunter mehreren Behörden und militärischen
Dienststellen, Rüstungsfirmen und privaten Organisationen. Es gibt zurzeit zwar noch
nicht viele Tools, die bei der Nutzung von STIX helfen könnten, aber das wird sich sicherlich ändern, wenn das Framework weiter ausgereift ist und erweitert wird.
Mehr über STIX erfahren Sie auf http://stix.mitre.org.
7.5
Zusammenfassung
In diesem Kapitel haben wir uns die Grundlagen von Erkennungsmechanismen, Einbruchsindikatoren und Signaturen und ihre Rolle in der NSM-Erkennung angesehen.
Dabei ging es um die verschiedenen Arten von Indikatoren, um wichtigste Kontextinformationen zu Indikatoren und Signaturen und um empfohlene Vorgehensweisen zu
ihrer Verwaltung. Dabei haben wir uns einerseits geeignete Verwaltungsmethoden für
kleinere und weniger erfahrene Organisationen als auch die Frameworks OpenIOC und
STIX angesehen. In den folgenden Kapiteln des Teils »Erkennung« geht es darum, wie
die verschiedenen Erkennungsmechanismen, die Sie mit den Indikatoren und Signaturen
speisen, eingesetzt werden.
8
Reputationsgestützte Erkennung
Die grundlegendste Form der Intrusion Detection ist die reputationsgestützte Erkennung.
Dabei wird versucht, Vorgänge zu erkennen, bei denen die Hosts in Ihrem Netzwerk mit
Hosts im Internet kommunizieren, die aufgrund ihres schlechten Rufs als schädlich eingestuft werden.
Die Reputation oder der Ruf ist laut Definition die weit verbreitete Auffassung, dass etwas oder jemand eine bestimmte Angewohnheit oder Eigenschaft hat. Im Zusammenhang
mit dem Schutz von Netzwerken kann ein Host einen guten, einen schlechten oder gar
keinen Ruf haben. Da Sie den Hosts in Ihrem Netzwerk, die unter Überwachung Ihres
Sicherheitsteams stehen, vertrauen, haben sie im Allgemeinen einen guten Ruf. Hosts mit
negativer Reputation werden als mögliche Bedrohung Ihrer vertrauenswürdigen Systeme
eingeschätzt.
Es gibt verschiedene Gründe, aus denen ein Host einen schlechten Ruf erwirbt. Am häufigsten ist der Fall, dass ein öffentlich zugängliches System geknackt und dazu missbraucht
wird, Schaddateien vorzuhalten, sodass Besucher der betreffenden Website häufig mit derselben Art von Malware infiziert werden. In Branchen, in denen Wirtschaftsspionage blüht
und gedeiht, können IP-Adressbereiche, die Konkurrenten gehören, eine negative Reputation haben, weil man mit dem Diebstahl geistigen Eigentums rechnet. In staatlichen und
militärischen Netzwerken haben Hosts, die zu feindlichen Staaten gehören oder bekanntlich vom Geheimdienst dieser Staaten geknackt wurden, einen schlechten Ruf.
230 8 Reputationsgestützte Erkennung
In diesem Kapitel sehen wir uns öffentliche Reputationslisten und verschiedene Möglichkeiten an, eine reputationsgestützte Erkennung durchzuführen. Dabei erhalten Sie auch
einen Überblick über die Verwendung von BASH-Skripten, CIF, Snort, Suricata und Bro
für diesen Zweck.
8.1
Öffentliche Reputationslisten
In der Praxis nutzen die meisten Organisationen zur reputationsgestützten Erkennung
öffentliche Listen elementarer Indikatoren (hauptsächlich IP-Adressen und Domänennamen) mit negativer Reputation. Solche schwarzen Listen (»Blacklists«) werden einem
Erkennungsmechanismus übergeben, der die Analytiker alarmiert, wenn eigene Hosts mit
einem in dieser Liste aufgeführten externen Gerät kommunizieren.
Die Verwendung öffentlicher Reputationslisten bietet mehrere Vorteile. Erstens haben die
meisten Organisationen keinen so weit reichenden Einblick, dass sie selbst Reputationslisten mit sinnvollem Umfang aufstellen könnten. Selbst mit Sensoren in Zweigstellen rund
um die Welt können Sie nur eine begrenzte Anzahl von Vorfällen erkennen und selbst
diese nicht alle vollständig untersuchen. Bei der Nutzung einer öffentlichen Liste greifen
Sie auf ein viel umfassenderes Netzwerk von Sensoren zurück, die Vorfälle an die für die
Listen zuständigen Gruppen melden. Die meisten dieser Listen werden auch gut gepflegt.
Viele der Hosts, die auf einer solchen Liste landen, sind in Wirklichkeit völlig legitime
Server, die nur zeitweilig missbraucht werden, um über sie deren Benutzer anzugreifen
(»Wasserstellen-Angriff«). Daher ist es sehr wichtig, Hosts wieder von der Liste zu entfernen, sobald ihre Vertrauenswürdigkeit wieder sichergestellt ist.
Allerdings weisen diese öffentlichen Listen auch Nachteile auf. Die Urheber dieser Listen bieten nicht immer Kontext zu den einzelnen IP-Adressen und Domänen an. Wenn
aufgrund der Kommunikation mit einem Host auf dieser Liste ein Alarm ausgelöst wird,
können Sie daher oft nicht erkennen, warum der betreffende Host eine negative Reputation hat. Liegt es daran, dass er wegen einer inzwischen behobenen XSS-Schwachstelle eine
Zeit lang Besucher zu einer Schadwebsite umgeleitet hat, oder ist er einer der Hauptknoten in einem großen Botnetz? Mehr Kontext wäre wünschenswert, um die Untersuchung
in die richtige Richtung zu lenken.
Letzten Endes überwiegen die Vorteile der öffentlichen Listen aber ihre Nachteile. Die bestehenden Probleme lassen sich überwinden, wenn man für die Listen die entsprechende
Sorgfalt walten lässt, um sie zu überprüfen und ihre Benutzung zu regeln. Stellen Sie sicher,
dass die Listen, die Sie in ihr Erkennungssystem aufnehmen, den Zielen ihrer Organisation entsprechen, und dass die Analytiker darin geschult werden, wie Alarme aufgrund
dieser Informationen bewertet und untersucht werden sollten. Bei richtiger Anwendung
kann die reputationsgestützte Erkennung Ihnen die wenigen leicht zu erringenden Siege
bringen, die bei der NSM zu haben sind.
8.1 Öffentliche Reputationslisten 231
8.1.1
Gängige öffentliche Reputationslisten
Es stehen viele öffentliche Reputationslisten zur Verfügung. In diesem Abschnitt stelle ich
Ihnen einige meiner Favoriten vor und gebe dabei jeweils die Vor- und Nachteile sowie
Hinweise dafür an, wie Sie sie bestmöglich nutzen können.
Malware Domain List
Obwohl allgemein große Sorge über gezielte Angriffe durch ausgefuchste Gegner vorherrscht, verbringen Analytiker den Großteil ihrer Zeit mit der Untersuchung von Zwischenfällen, bei denen es um die Infektion ihrer Systeme mit Malware geht. Daher ist es
unverzichtbar, Malware sowohl auf einzelnen Hosts als auch im Netzwerk erkennen zu
können. Eine der einfachsten Möglichkeiten, um Malware im Netzwerk aufzuspüren, bietet die Verwendung von öffentlichen Reputationslisten mit IP-Adressen und Domänennamen, die mit der Verbreitung von Malware in Verbindung stehen.
Die Malware Domain List (MDL) ist ein nicht kommerzielles Community-Projekt, das Listen schädlicher Domänen und IP-Adressen unterhält. Es wird von einer offenen Gemeinschaft von Freiwilligen getragen und stützt sich auf deren Arbeit, um Einträge der Liste
hinzuzufügen, aber auch um sie zu überprüfen und gegebenenfalls wieder zu entfernen.
Die MDL-Listen können Sie von Fall zu Fall abfragen, Sie können sie aber auch in verschiedenen Formaten herunterladen, u. a. als CSV-Datei, als RSS-Feed oder als hosts.txtDatei. Es gibt auch Listen, die nur die täglichen Neueinträge nennen, sowie Listen der
Sites, die früher einmal auf der Hauptliste gestanden haben, inzwischen aber nicht mehr
als schädlich eingestuft werden oder offline sind. MDL gehört zu den umfangsreichsten
und am häufigsten genutzten Reputationslisten.
Ich habe viele Organisationen kennengelernt, die mit MDL als Quelle für die reputationsgestützte Erkennung große Erfolge beim Erkennen von Malwareinfektionen und BotnetzSteuerservern (C2) erzielt haben. Der große Umfang von MDL kann jedoch manchmal
zu Fehlalarmen führen. Wenn ein Alarm ausgelöst wird, weil einer Ihrer Hosts einen Host
besucht, der in der MDL verzeichnet ist, reicht das für sich allein noch nicht aus, um das
Vorliegen eines Zwischenfalls zu konstatieren. Bei solchen Alarmen müssen Sie zusätzliche
Datenquellen untersuchen und sich die Kommunikation Ihres Hosts in breiterem Rahmen
ansehen, um nach Anzeichen für eine Infektion oder einen Einbruch Ausschau zu halten.
Mehr über MDL erfahren Sie auf http://www.malwaredomainlilst.com.
ZeuS Tracker und SpyEye Tracker von Abuse.ch
ZeuS und SpyEye waren erschreckend weit verbreitete Crimeware-Kits, die von Angreifern
benutzt wurden, um Systeme zu infizieren und darin eine Vielzahl schädlicher Aktionen
auszuführen. Mit diesen Kits war es möglich, Malware zu erstellen, die über einen Driveby-Download andere Computer infizierte, um sie einem Botnetz hinzuzufügen, und dieses
Botnetz wiederum konnte mit dem Kit gesteuert werden. Eine Zeit lang war ZeuS das
232 8 Reputationsgestützte Erkennung
größte Botnetz der Welt, mit SpyEye als größtem Konkurrenten. Der Urheber von ZeuS
hat 2010 zwar angekündigt, dass er den Quellcode ausmustert, aber die Veröffentlichung
des Codes hat dazu geführt, dass auch heute noch mit ZeuS-Infektionen zu rechnen ist.
Auch SpyEye-Infektionen treten noch sehr häufig auf, obwohl der Urheber dieser Software
angeblich 2013 geschnappt und ins Gefängnis gesperrt worden ist.
Die Projekte ZeuS Tracker (siehe Abb. 8.1) und SpyEye Tracker führen eine Liste der Steuerserver für ZeuS- und SpyEye-infizierte Computer sowie der Hosts, die mit ZeuS- und
SpyEye-Dateien verseucht sind oder Exploits für Drive-by-Downloads vorhalten. Diese
Listen sind für Eingaben von Benutzern offen und können fallweise abgefragt oder komplett heruntergeladen werden. Für den Download stehen verschiedene Formate zur Verfügung, beispielsweise als reine Auflistung der Domänen oder IP-Adressen oder in Form
von Squid-, Iptables-, oder Hostdatei-Sperrlisten. Es wird auch eine Liste der in letzter
Zeit entfernten Einträge geführt.
Abbildung 8.1: Zeus Tracker
Nach meiner Erfahrung weisen beide Listen eine hohe Qualität auf und verursachen
nur sehr wenige Fehlalarme bei der reputationsgestützten Erkennung. Wie Sie auf einen
Alarm reagieren, der durch die Kommunikation mit einem Host einer dieser Listen ausgelöst wurde, hängt von der Art der Kommunikation und davon ab, ob es Anzeichen für eine
tatsächliche Injektion des Opferhosts mit diesen Arten von Malware gibt.
Weitere Informationen erhalten Sie auf https://zeustracker.abuse.ch/ bzw. https:/spyeyetracker.
abuse.ch/.
8.1 Öffentliche Reputationslisten 233
PhishTank
Viele gezielte Angriffe beginnen mit irgendeiner Art von Phishingvorgang. Die meisten
Organisationen bemerken solche Vorgänge erst in einem späteren Stadium. Für die Früherkennung (aber auch für die rückblickende Analyse) wäre es sehr praktisch, sofort feststellen zu können, ob ein Benutzer zu einer bekannten Phishingwebsite umgeleitet wird.
PhishTank wird von OpenDNS betrieben und ist eine freie, von der Community getragene Website zum Austausch von Daten über Phishing. Registrierte Benutzer können Links
einreichen, die bei Phishingversuchen verwendet wurden. PhishTank ist in dem Sinne
einzigartig, dass es sich nicht nur zum Einreichen von Einträgen, sondern auch zu deren
Überprüfung auf die Community stützt. Damit ein URL in die Liste aufgenommen wird,
muss er von einer bestimmten Anzahl registrierter PhishTank-Benutzer verifiziert werden. Je mehr URLs ein Benutzer erfolgreich bestätigt hat, umso höheres Gewicht wird
seinen Beurteilungen beigemessen. Liegen in einem Fall Verifizierungen durch solche
vertrauenswürdigeren Benutzer vor, sind also insgesamt weniger Verifizierungen dafür
erforderlich.
Eine besonders nützliche Funktion ist die Websuche nach Zielmarken (»Targeted Brand«),
also nach Firmennamen, die häufig in Phishingangriffen vorgespiegelt werden. Wenn Ihre
Organisation häufig als Köder für Phishingversuche missbraucht wird (z. B. eine Bank),
können Sie die PhishTank-Liste nutzen, um nach Gegnern zu suchen, die es auf Ihre Kunden abgesehen haben.
Die PhishTank-Listen werden in verschiedenen Formaten angeboten. Außerdem gibt es
eine API für die Integration in eigene Anwendungen. Es gibt zwar kein Webforum für
PhishTank, dafür aber eine offene Mailingliste für Benutzer und Entwickler.
Wenn Sie PhishTank-Listen in die Erkennungsmechanismen in Ihrem Netzwerk aufnehmen, müssen Sie den Dingen besondere Aufmerksamkeit schenken, die unmittelbar auf
den ersten Besuch eines Geräts auf einer bekannten Phishingwebsite folgen. Insbesondere
sollten Sie nach Umleitungen, dem Download von ausführbaren Inhalten oder der Eingabe von Anmeldeinformationen durch Ihre Benutzer Ausschau halten.
Weitere Informationen über PhishTank erhalten Sie auf http://www.phishtank.com/.
Tor-Austrittsknotenliste
Wenn Sie mit einem Gerät im Internet kommunizieren, z. B. mit einem Webserver, nimmt
Ihr Client unmittelbar Kontakt mit diesem Gerät auf. Der Webserver kann ein Protokoll
der Kommunikationsvorgänge führen, in dem auch die IP-Adressen der Clients aufgeführt sind. Wird der Webserver von einem NSM-Sensor überwacht, dann erscheinen die
IP-Adressen der Clients auch in anderen Datenquellen, z. B. in Paketerfassungs- oder
Sitzungsdaten.
Dienste wie Tor bieten jedoch die Möglichkeit, zu verhindern, dass die wahre IP-Adresse
des Clients in solchen Protokollen auftaucht. Bei Tor handelt es sich um ein offenes Netz-
234 8 Reputationsgestützte Erkennung
werk, mit dessen Hilfe Benutzer ihre IP-Adresse verschleiern und beim Zugriff auf Geräte
im Internet anonym bleiben können.
Wenn Sie im Web unterwegs sind und dabei einen Tor-Client nutzen, wird Ihr ausgehender Datenverkehr in das Tor-Netzwerk geleitet statt zum Zielwebserver. Innerhalb
dieses Netzwerks wird er dann schließlich zu einem Austrittsknoten weitergeleitet, der
die Verbindung zum eigentlichen Zielserver herstellt. Das Protokoll auf dem Webserver
und sämtliche NSM-Einrichtungen zeigen daher die IP-Adresse des Tor-Austrittsknotens
statt derjenigen des Clients, der die Kommunikation ausgelöst hat. Eine Darstellung dieses
Vorgangs sehen Sie in Abb. 8.2.
Abbildung 8.2: Kommunikation über Tor
Wenn jemand versucht, seine Identität bei der Kommunikation mit einem Gerät in Ihrem
Netzwerk zu verschleiern, kann das ein verdächtiger Vorgang sein, der eine nähere Untersuchung rechtfertigt. Allerdings nutzen viele Personen Tor für eine völlig legitime Anonymisierung. Datenverkehr von einem Tor-Austrittsknoten mag verdächtig erscheinen,
aber für sich allein genommen reicht dies nicht aus, um daraus in einer Untersuchung
irgendwelche Schlüsse zu ziehen.
Datenverkehr, der aus dem Tor-Netzwerk kommt, können Sie erkennen, indem Sie Listen der Tor-Austrittsknoten in Ihren Erkennungsmechanismen verwenden. Eine solche
Liste finden Sie auf blutmagie.de. Sie können sie im Browser abfragen oder als CSV-Datei
herunterladen.
Mehr über die Tor-Austrittsknotenliste finden Sie auf http://torstatus.blutmagie.de/.
Spamhaus-Sperrlisten
Spamhaus ist eine internationale Nonprofit-Organisation, die es sich zur Aufgabe gemacht hat, die Tätigkeiten von Spammern und die Quellen von Spam im Internet zu
verfolgen. Diese Organisation führt unter anderem folgende Listen:
8.1 Öffentliche Reputationslisten 235
•• Spamhaus Block List (SBL): Eine Datenbank mit IP-Adressen, von denen Sie nach
Empfehlung von Spamhaus keine E-Mails annehmen sollten.
•• Exploits Block List (XBL): Eine Datenbank mit IP-Adressen von Systemen, die von
Exploits infiziert und gekapert wurden. Zu solchen Exploits zählen u. a. offene Proxys
sowie Würmer und Viren mit eingebauten Spam-Engines.
•• Policy Block List (PBL): Eine Datenbank mit Endbenutzer-IP-Adressbereichen, die
keine nicht authentifizierten SMTP-E-Mails an irgendwelche Internet-Mailserver ausliefern sollten. Damit soll im Grunde verhindert werden, dass Hosts, die keine E-Mails
senden dürfen, dies trotzdem tun. Hauptsächlich dient dies dazu, dass Netzwerke ihre
Richtlinien für bestimmungsgemäßen Gebrauch durchsetzen können.
•• Domain Block List (DBL): Eine Datenbank mit Domänen, die in Spamnachrichten
gefunden wurden.
•• Don't Route or Peer (DROP): Eine Liste gekaperter Netzwerkblöcke des IP-Adressraums, die direkt Spammern zugeordnet sind. Diese Blöcke wurden gewöhnlich von
Netzwerkbesitzern vergessen und durch verschiedene Techniken von Spammern in
Anspruch genommen, z. B. durch die Registrierung aufgegebener Domänennamen,
Dokumentenfälschung und Social Engineering. Spamhaus bietet auch eine erweiterte
DROP-Liste an (EDROP oder Extended DROP), die über den gesamten Inhalt der
DROP-Liste hinaus auch IP-Adressen enthält, die höchstwahrscheinlich im Zusammenhang mit Cyberkriminalität stehen, aber nicht direkt Spamverteilern zugeordnet
sind.
Die Listen SBL, XBL, PBL und DBL stehen für den nicht kommerziellen Gebrauch kostenlos zur Verfügung. Für andere Anwendungen ist der Erwerb eines Abonnements erforderlich. Dagegen sind die Listen DROP und EDROP stets kostenlos, was sie zu guten
Kandidaten für die Aufnahme in ein reputationsgestütztes Erkennungssystem macht. Sie
werden auch gut gepflegt, sodass sie sehr nützlich sind, um zu erkennen, wann interne
Hosts mit bekannten Spamsystemen kommunizieren.
Besonders interessant ist die Verzahnung der DROP-Liste mit dem Signaturverzeichnis
ET für neu aufkommende Bedrohungen (Emerging Threats). ET unterhält einen Satz von
Signaturen aus Spamhaus-DROP-Listen, die in den Intrusion-Detection-Systemen Snort
und Suricata verwendet werden können. Das vereinfacht die Anwendung dieser Listen in
der Praxis.
Die Nutzung dieser Listen zur Spamerkennung ist zwar nicht sehr ergiebig, doch es kann
schon sehr wertvoll sein, informiert zu werden, wenn ein eigener Host (außer einem Mailserver) mit Systemen aus einem Adressbereich kommuniziert, der gewöhnlich von Spammern genutzt wird.
Mehr über die DROP-Listen von Spamhaus erfahren Sie auf http://www.spamhaus.org/
drop/.
236 8 Reputationsgestützte Erkennung
Weitere Listen
Es gibt eine Menge anderer Reputationslisten, auf denen IP-Adressen und Domänen verzeichnet sind – zu viele, um sie alle in diesem Buch zu behandeln. Unter anderem aber
sind die folgenden Listen einen Blick wert:
•• AlientVault Labs IP Reputation Database:
http://labs.alienvault.com/labs/index.php/projects/open-source-ip-reputationportal/
•• MalC0de Database
http://malc0de.com/database/
•• SRI Malware Threat Center
http://www.mtc.sri.com/live_data/attackers/
•• Project Honeypot
https://www.projecthoneypot.org/list_of_ips.php
•• Emerging Threats Rules
http://www.emergingthreats.net/open-source/etopen-ruleset/
8.1.2 Häufig auftretende Probleme bei der Verwendung öffentlicher
Reputationslisten
Die reputationsgestützte Erkennung ermöglicht zwar oft einen leichten Sieg, allerdings
lauern dabei auch einige Fallstricke.
Automatische Blockierung
Öffentliche Blacklists sollten Sie niemals in Kombination mit automatischer Blockierung oder mit sonstigen Sperrmechanismen verwenden, ohne irgendeine Form von
manueller Überprüfung vorzusehen. Ansonsten können auch völlig harmlose Websites
blockiert werden. Es ist sogar möglich, dass Dienste in Ihrem eigenen Netzwerk unerreichbar werden.
Bekannt geworden ist der Fall, in dem die US Navy Hosts auf der Grundlage der nicht
ausreichend überprüften Reputationsliste eines Drittherstellers automatisch blockieren
ließ. Danach hatte die Navy auch auf eine Reihe harmloser Websites keinen Zugriff mehr,
darunter Google.
Ein anderer Fall betraf eine Organisation, die eine öffentliche Reputationsliste unmittelbar in ihre internen DNS-Server einspeiste, um Namensabfragen für Schaddomänen
umzuleiten und dadurch den Zugriff darauf zu blockieren. Das funktionierte ganz gut, bis
eines Tages der eigene Mailserver auf der Liste stand. Dadurch könnten die Benutzer keine
E-Mails mehr senden und empfangen. Der Netzwerkadministrator brauchte eine ganze
Weile, um der Ursache des Problems auf die Spur zu kommen.
8.1 Öffentliche Reputationslisten 237
Es gibt nichts Peinlicheres, als solche Zustände in der eigenen Organisation heraufzubeschwören. Daher sollten Sie öffentliche Reputationslisten ausschließlich in Kombination
mit Erkennungsmechanismen einsetzen.
Pflege der Listen
Es kommt recht häufig vor, dass mit dem Internet verbundene Server geknackt und
zeitweilig für die Verbreitung von Malware oder anderen unerwünschten Inhalten missbraucht werden, was dazu führt, dass die IP-Adresse des Servers oder der Domänenname
auf eine Sperrliste gesetzt wird. Über kurz oder lang bemerken die Besitzer des betroffenen Systems, was da geschehen ist, und sanieren den Server wieder. Nicht immer aber wird
das System zeitnah wieder von der Liste entfernt. Dadurch können bei der Kommunikation mit diesem Server Fehlalarme auftreten.
Diese Art von Fehlalarmen kommt relativ häufig vor und lässt sich bei der reputationsgestützten Erkennung nie ganz ausschließen. Allerdings sollten Sie Ihr Möglichstes tun, ihr
Vorkommen zu minimieren, damit Sie nicht kostbare Analysezeit verschwenden. Grundsätzlich sollten Sie sich vergewissern, ob die Betreiber der Liste Einträge mit dem gleichen Eifer wieder von der Liste herunternehmen wie sie hinzufügen. Sorgen Sie außerdem
dafür, dass Sie regelmäßige aktualisierte Listen vom Server des Anbieters beziehen, und
zwar mindestens täglich. Wir werden uns weiter hinten in diesem Kapitel noch mehrere
Möglichkeiten ansehen, diesen Vorgang zu automatisieren.
Gemeinsam genutzte Server
Es kommt erstaunlich häufig vor, dass die IP-Adressen gemeinsam genutzter Server, wie
sie oft von Providern genutzt werden, auf öffentlichen Sperrlisten landen. Der Grund
dafür ist, das die Domäne eines einzigen Benutzers dieses Servers geknackt wurde und
irgendwelche schädlichen Inhalte bereitstellt. Statt dieser einen Domäne wird nun die IPAdresse des gesamten Servers auf die Sperrliste gesetzt, sodass bei Benutzern, die eine
andere auf diesem Server vorgehaltene Website besuchen möchten, Alarm ausgelöst wird,
obwohl gar keine schädliche Tätigkeit vorliegt. Dieses Problem ist für einen großen Teil
von Fehlalarmen verantwortlich.
Wenn ein Angreifer allerdings bereits in einer Website auf einem gemeinsam genutzten
Server Fuß gefasst hat, wächst auch die Gefahr, dass er in andere Websites eindringt. Daher
sollten Sie zunächst einmal jeden dieser Alarme untersuchen, sofern Sie keine zusätzlichen
Kontextinformationen haben. Falls Sie herausfinden, dass die Probleme eines gemeinsam
genutzten Servers auf der Liste von einer Art sind, die sich nicht auf die anderen darauf
untergebrachten Hosts auswirken kann, z. B. siteübergreifende Skripterstellung (CrossSite Scripting, XSS), dann können Sie die IP-Adresse des Servers aus der Speerliste herausnehmen und durch einen Eintrag für die Domäne ersetzen, die tatsächlich Schadinhalte
bereitstellt.
238 8 Reputationsgestützte Erkennung
Werbenetzwerke
Werbenetzwerke ermöglichen ihren Kunden, Code für Werbeanzeigen einzureichen, die
automatisch auf den Websites der der Abonnenten dieses Netzwerks angezeigt wird. Das
ist ein Riesengeschäft und die Haupteinnahmequelle vieler Websites. Es ist aber auch ein
lukratives Ziel für Angreifer, da es ihnen die Möglichkeit bietet, Schadcode in Anzeigen
einzubauen, die automatisch auf viele häufig besuchte Websites verteilt werden. Die meisten Werbenetzwerke führen zwar eine Überprüfung durch, um einen solchen Missbrauch
auszuschließen, aber erstens machen das nicht alle Werbenetzwerke, und zweitens gelingt
es Angreifern hin und wieder, eine Überprüfung zu unterlaufen.
Das kann dazu führen, dass die mit einem Werbenetzwerk verknüpfte Domäne auf öffentlichen Sperrlisten landet. Wenn das der Fall ist und Sie eine reputationsgestützte Erkennung durchführen, erhalten Sie jedes Mal einen Alarm, wenn ein Benutzer eine Anzeige
von dem betroffenen Werbenetzwerk angezeigt bekommt, ob sie nun schädlich ist oder
nicht. Das kann zu einer Menge von Fehlalarmen führen. Glauben Sie mir nicht? Dann
suchen Sie doch einmal in den Webprotokollen Ihrer Organisation nach Anforderungen
für die Domänen akamai.com oder scorecardresearch.com. Beide gehören zu umfangreichen
Werbenetzwerken und werden von einer Vielzahl populärer Websites genutzt.
Die zweckmäßigste Methode, das Übermaß an Fehlalarmen aufgrund von Werbenetzwerken zu verringern, besteht darin, alle Verweise auf diese Netzwerke von den Sperrlisten zu
entfernen, die Sie verwenden. Im Allgemeinen enthalten die Anzeigen nicht den Schadcode
selbst, sondern Code, der Benutzer zu einer Stelle umleitet, an der der eigentliche Schadcode lauert. Es ist besser, sich auf andere Erkennungsmechanismen zu verlassen, anstatt
sich mit all den Fehlalarmen abzuplagen, die ansonsten auftreten könnten.
Verringern von Fehlalarmen durch Whitelists
Bis jetzt haben wir nur über Listen mit Indikatoren für eine negative Reputation gesprochen (sogenannte Blacklists oder Sperrlisten). Es ist jedoch auch sinnvoll, Listen mit Indikatoren für eine positive Reptuation (Whistlists) zu verwenden. In Kombination mit
einem Erkennungsmechanismus können Sie mit Sperrlisten zwar sehr gute Ergebnisse
erzielen, allerdings treten dabei auch oft Fehlalarme auf, insbesondere wenn die Listen
nicht gut gepflegt werden.
Eine Vorgehensweise, um die Menge der Fehlalarme bei der reputationsgestützten Erkennung wirkungsvoll zu reduzieren, besteht darin, die Liste »Alexa Top Sites« als Whitelist
zu verwenden. Diese Liste enthalt die 1.000.000 meistbesuchten Websites im Internet.
Kürzen Sie sie auf die ersten 100 bis 500 Einträge und sorgen Sie dafür, dass keine der
Websites auf dieser Whiteliste einen Alarm auslöst, wenn sie in einer Blacklist erwähnt
wird. Natürlich können auch diese Websites mit irgendeiner Form von Malware infiziert
werden, aber die Wahrscheinlichkeit dafür ist gering, und wenn dieser Fall eintritt, dann
wird das Unternehmen, dem die betroffene Website gehört, schnellstens dafür sorgen, das
Problem zu beheben.
8.2 Automatisieren der reputationsgestützten Erkennung 239
8.2
Automatisieren der reputationsgestützten Erkennung
Für die reputationsgestützte Erkennung brauchen Sie zwei Dinge. Das erste ist mindestens eine Liste von IP-Adressen oder Domänen mit negativer Reputation. Im vorherigen
Abschnitt haben wir schon einige öffentlich verfügbare Sperrlisten besprochen, aber Sie
können sie auch um private, branchenspezifische oder interne Listen ergänzen. Die Inhalte dieser Listen müssen Sie nun einem Mechanismus zuführen, der eine Erkennung
auf der Grundlage dieser Listen durchführt. Es gibt verschiedene Möglichkeiten, diese
Aufgabe durchzuführen und zu automatisieren.
8.2.1 Manuelles Abrufen und Erkennen mit BASH-Skripten
Im weiteren Verlauf dieses Kapitels werden wir verschiedene kostenlose und OpenSource-Tools für die reputationsgestützte Erkennung kennenlernen. All diese Werkzeuge lassen sich in den meisten Organisationen wirkungsvoll einsetzen. Andererseits
ist die reputationsgestützte Erkennung so einfach, dass Sie auch simple Linux-BASHSkripte dafür einsetzen können. In den folgenden Beispielen werden wir genau das tun,
um eine öffentliche Reputationsliste herunterzuladen und zu durchlaufen und anhand
dieser Liste schädliche Domänen und IP-Adressen im Netzwerkverkehr aufzuspüren.
Die Liste herunterladen und vorbereiten
Das Erste, was Sie für die reputationsgestützte Erkennung benötigen, ist eine Liste der
Adressen oder Domänen, die einen schlechten Ruf haben. In diesem Beispiel verwenden
wir eine der besonders beliebten Listen, nämlich die Malware Domain List (MDL). Die
Betreiber pflegen sowohl eine Liste von Domänennamen als auch von IP-Adressen, und
wir wollen beide nutzen. Wir brauchen diese Listen als Textdateien, in denen die Einträge
durch Zeilenumbrüche getrennt sind.
Die IP-Adressliste können Sie wie folgt mit curl herunterladen:
curl http://www.malwaredomainlist.com/hostslist/ip.txt > mdl.iplist
Das Größer-als-Symbol (>) dient dazu, die Ausgabe des Befehls in die Datei mdl.iplist
umzuleiten. Wenn Sie sich diese Datei ansehen, werden Sie feststellen, dass darin alles so
aussieht, wie wir es erwarten – bis auf eine Abweichung, um die wir uns kümmern müssen, um die Liste später fehlerfrei durchlaufen zu können.
Wenn Sie den Befehl file mdl.iplist ausführen, erhalten Sie die Meldung, dass es sich
bei der gerade erstellten Datei um ASCII-Text mit CRLF-Zeienendezeichen handelt. Um
den Beginn einer neuen Zeile zu markieren, verwendet Windows sowohl ein Zeilenwechsel- (\n in ASCII, 0x10 in Hex) als auch ein Wagenrücklaufzeichen (\r in ASCII, 0x0D in
Hex), wohingegen Unix-Betriebssysteme nur das Zeilenwechsel einsetzen. Wenn wir die
240 8 Reputationsgestützte Erkennung
Datei später mit Unix-Tools durchlaufen, würde das zusätzliche Wagenrücklaufzeichen
am Ende jeder Zeile zu unerwarteten Ergebnissen führen.
Es gibt verschiedene Möglichkeiten, das Wagenrücklaufzeichen von allen Zeilen in der
Datei zu entfernen. Am einfachsten geht es mit dem Hilfsprogramm Dos2unix. Falls es
nicht im Lieferumfang Ihrer Distribution enthalten ist, können Sie es ganz einfach von
den meisten Standardrepositorys installieren (apt-get install dos2unix, yum install
dos2unix usw.). Die Ausgabe des curl-Befehls können wir direkt an dieses Hilfsprogramm
übergeben, bevor wir die Datei ausgeben. In dieser Form sieht der Befehl wie folgt aus:
curl http://www.malwaredomainlist.com/hostslist/ip.txt | dos2unix>mdl.iplist
Jetzt müssen wir das Gleiche noch mit der MDL-Liste schädlicher Domänen machen. Versuchen wir es zunächst mit dem folgenden Befehl, der genauso aufgebaut ist wie der letzte:
curl http://www.malwaredomainlist.com/hostslist/hosts.txt | dos2unix>mdl.
domainlist
Abbildung 8.3: Die Domänenliste in der ursprünglichen Form
Wenn Sie anschließend mdl.domainlist öffnen, werden Ihnen einige Probleme auffallen
(siehe Abb. 8.3). Zu Anfang der Datei befinden sich einige zusätzliche Textzeilen sowie
Leerzeilen, die alle entfernt werden müssen, da sie sonst bei der Verarbeitung der Datei
Fehler hervorrufen würden. Um diese Zeilen loszuwerden, können wir Sed anweisen, die
ersten sechs Zeilen der Datei zu entfernen:
8.2 Automatisieren der reputationsgestützten Erkennung 241
curl http://www.malwaredomainlist.com/hostslist/hosts.txt | sed '1,6d' |
dos2unix>mdl.domainlist
Des Weiteren stehen in jeder Zeile zwei Werte, wobei der erste jeweils die Loopbackadresse
127.0.0.1 ist und der zweite den eigentlichen Domänennamen nennt. Die Liste wird in
diesem Format angeboten, damit man sie leicht in eine Hosts-Datei kopieren kann, um
Anforderungen für diese Hosts umzuleiten. Das ist allerdings nicht die Art und Weise, wie
wir diese Liste verwenden wollen. Um nur die Daten der zweiten Spalte beizubehalten,
verwenden wir Awk:
curl http://www.malwaredomainlist.com/hostslist/hosts.txt | sed '1,6d' | awk
'{print $2}' | dos2unix>mdl.domainlist
Die resultierende Datei sehen Sie in Abb. 8.4.
Abbildung 8.4: Die bereinigte Domänenliste
Damit haben wir jetzt zwei sauber formatierte Dateien mit IP-Adressen und Domänen,
die wir für die Erkennung nutzen können. Die beiden vorherigen Befehle können Sie auch
in ein Skript aufnehmen, das Sie regelmäßig ausführen, um die Listen auf dem neuesten
Stand zu halten. Ich empfehle Ihnen, einen Cron-Job anzulegen, um diese Daten mindestens einmal täglich herunterzuladen. Der folgende Eintrag in /etc/crontab sorgt dafür, dass
das Aktualisierungsskript jeden Tag um 6.30 Uhr ausgeführt wird:
30 6 * * * /home/sanders/GatherMDL.sh
242 8 Reputationsgestützte Erkennung
Schädliche IP-Adressen in Sitzungsdaten erkennen
Mit diesen Listen können wir nun versuchen, jegliche Kommunikation zwischen Hosts
in unserem Netzwerk und Hosts auf der IP-Adressliste von MDL zu erkennen. Eine der
effizientesten Möglichkeiten dazu bieten die Sitzungsdaten. Im Folgenden schreiben wir
ein kurzes Skript, um eine Erkennung mithilfe von SiLK durchzuführen.
Als Erstes müssen wir den Zeitrahmen der Untersuchung festlegen. Hier entscheiden wir
uns dafür, den gesamten Datenverkehr der letzten Stunde zu überprüfen. Mit dem Befehl
date können wir sowohl die Uhrzeit und das Datum des aktuellen Zeitpunkts als auch des
Zeitpunkts vor einer Stunde abrufen. Diese Werte speichern wir in Variablen:
start=$(date -ud '-60 minutes'+%Y/%m/%d:%T)
endd=$(date -ud+%Y/%m/%d:%T)
Als Nächstes müssen wir die zuvor abgerufene Liste der IP-Adressen in einen Satz von IPAdressen umwandeln, den das SiLK-Werkzeug Rwfilter durchlaufen kann. Dazu verwenden wir den Befehl rwsetbuild, dem wir neben dem Namen der Eingabedatei auch den der
Ausgabedatei angeben, in unserem Fall mdl.iplist.set:
rwsetbuild mdl.iplist mdl.iplist.set
Schließlich suchen wir mit Rwfilter nach allen Datensätzen der letzten Stunde, bei denen
die IP-Adresse mit denen auf der Liste übereinstimmt. Der Befehl dazu lautet wie folgt:
rwfilter –start-date=$start –end-date=$end --anyset=mdl.iplist.set
--proto=0-255 --type=all --pass=stdout | rwcut
Dieser Befehl enthält verschiedene der Rwfilter-Optionen, die wir schon in Kapitel 4 kennengelernt haben, sowie die zuvor erstellten Variablen als Werte für die Optionen --startdate und --enddate. Mit --anyset wird die Eingabedatei angegeben.
Das komplette Skript sieht wie folgt aus:
#!/bin/bash
start=$(date -ud '-60 minutes'+%Y/%m/%d:%T)
end=$(date -ud+%Y/%m/%d:%T)
rwsetbuild mdl.iplist mdl.iplist.set
rwfilter --active-time=$start-$end --anyset=mdl.iplist.set
--proto=0-255 --type=all --pass=stdout | rwcut
Die Ausgabe dieses Skripts sehen Sie in Abb. 8.5.
8.2 Automatisieren der reputationsgestützten Erkennung 243
Abbildung 8.5: SiLK-Ausgabe mit übereinstimmenden IP-Adressen schlechter Reputation
Schädliche Domänen in FPC-Daten erkennen
Unsere nächste Aufgabe besteht darin, jegliche Kommunikation zwischen unseren eigenen Hosts und möglicherweise schädlichen Domänen auf der MDL-Liste zu finden. Da
die dazu erforderlichen Daten nicht in den Sitzungsdaten enthalten sind, sehen wir uns
stattdessen die vollständigen Paketdaten (FPC) an.
Dies ist etwas anspruchsvoller als die Überprüfung von IP-Adressen mit Rwfilter. Für die
einzelnen Vorgänge wenden wir daher BASH-Funktionen an. Bevor wir die erste Funktion schreiben, müssen wir dem Skript jedoch mitteilen, dass wir die zu untersuchende
PCAP-Datei als Befehlszeilenargument angeben werden, wenn das Skript ausgeführt wird.
Das erreichen wir mit folgender Anweisung:
pcapfile=$(echo $1)
Unsere erste Funktion nutzt Justniffer (siehe Kapitel 6), um die bereitgestellte PCAP-Datei
zu durchlaufen und alle Domänennamen im Zusammenhang mit HTTP-Kommunikation
über TCP-Port 80 in die Datei temp.domains zu schreiben:
ParsePCAP() {
justniffer -p "tcp port 80" -f $pcapfile -u -l "%request.timestamp
- %source.ip ->%dest.ip - %request.header.host %request.line">temp.domains
}
Als Nächstes schreiben wir die Funktion, die mit grep in einer while-Schleife den Inhalt
von temp.domains auf Überstimmungen mit der MDL-Domänenliste durchsucht. Die
Ausgabe zeigt die HTTP-Anforderungen, bei denen eine Übereinstimmung festgestellt
244 8 Reputationsgestützte Erkennung
wurde. Die sed-Anweisung dient dazu, am Ende der Anforderung Text hinzuzufügen, der
angibt, welche übereinstimmende Domäne gefunden wurde. Die Ausgabe erfolgt nicht
nur in der Konsole, sondern mithilfe des Befehls tee auch in einer Datei namens alert.txt.
DetectMDL() {
while read blacklistterm; do
grep -i $blacklistterm temp.domains | sed "s,$, Match\:$blacklistterm,g"| tee -a alert.txt
done<"mdl.domainlist"
}
Wir nehmen beide Funktionen in ein Skript auf und fügen eine weitere hinzu, die die bei
der Untersuchung der PCAP-Dateien erstellte temporäre Datei wieder löscht:
#!/bin/bash
pcapfile=$(echo $1)
ParsePCAP() {
justniffer -p "tcp port 80" -f $pcapfile -u -l “%request.timestamp %source.ip ->%dest.ip - %request.header.host - %request.line">temp.
domains
}
DetectMDL() {
while read blacklistterm; do
grep -i $blacklistterm temp.domains | sed "s,$, Match\:$blacklistterm,g"| tee -a alert.txt
done<"mdl.domainlist"
}
CleanUp() {
rm -rf temp.domains
}
ParsePCAP
DetectMDL
CleanUp
Exit
Abb. 8.6 zeigt die Ausgabe dieses Skripts.
8.2 Automatisieren der reputationsgestützten Erkennung 245
Abbildung 8.6: Domänennamen mit schlechter Reputation in einer PCAP-Datei aufspüren
Die hier vorgestellten Skripte sind sehr einfach gehalten und können noch auf verschiedene
Weise verbessert werden. Unter anderem sind folgende Erweiterungen denkbar:
•• Durchsuchung eines gesamten Verzeichnisses statt einer einzelnen PCAP-Datei
•• Möglichkeit, sowohl eine strikte als auch eine lockere Suche nach Übereinstimmungen
durchzuführen
•• Fehlerprüfung
•• Ausgabe in Systemprotokolle, eine Datenbank, per E-Mail usw.
Eine ausgefeiltere Version dieser Skripte haben wir in dem Tool Scruff zur Verfügung gestellt, dass Sie auf http://www.appliednsm.com/scruff finden können.
8.2.2 Collective Intelligence Framework (CIF)
Das Collective Intelligence Framework (CIF) ist ein Verwaltungssystem für Informationen über Cyberbedrohungen. Entwickelt wurde es von Wes Young bei REN-ISAC. In
CIF können Analytiker die zu verwendenden Listen festlegen, die dann automatisch regelmäßig abgerufen werden. Die Daten werden normalisiert und in der CIF-Datenbank
gespeichert. Wenn das geschehen ist, können sie von CIF abgefragt oder mithilfe eines
Verarbeitungsskripts einem Erkennungsmechanismus bereitgestellt werden.
CIF kann im Lieferzustand verschiedene Listen verarbeiten, darunter ZeuS/SpyEye Tracker,
die DROP-Liste von Spamhaus usw. Darüber hinaus ist es möglich, eigene Erweiterungen
für die Verarbeitung von Listen zu schreiben, für die die Software nicht vorkonfiguriert ist.
Außerdem können Sie Ausgabe-Plug-Ins nutzen, um die Listen den von Ihnen verwendeten Erkennungsmechanismen zuzuführen.
CIF ist nicht im Standardumfang von Security Onion enthalten. Wenn Sie die Beispiele in
diesem Kapitel nachvollziehen wollen, installieren Sie es nach der Anleitung auf https://
code.google.com/p/collective-intelligence-framework/wiki/ServerInstall_v1.
Indikatorlisten aktualisieren und hinzufügen
Nach der Installation von CIF sollten Sie als Erstes Befehle geben, die die Software dazu
veranlassen, ihre Datenbank mit Einträgen aus den Listen zu füllen, die bereits eingerichtet sind. Die Listen sind in zwei Gruppen eingeteilt – stündlich und täglich aktualisierte
Listen. Rufen Sie als Erstes die stündlich aktualisierten Listen ab:
246 8 Reputationsgestützte Erkennung
cif_crontool -d -p hourly
Als Nächstes sind die täglich aktualisierten Listen an der Reihe, von denen es aber viel
mehr gibt. Je nach der verfügbaren Bandbreite und der Leistung Ihres Systems kann dieser
Vorgang einige Zeit in Anspruch nehmen. Der Befehl dafür lautet:
cif_crontool -d -p daily
Anschließend ist die CIF-Datenbank mit Ergebnissen aus allen vorab eingerichteten
Listen gefüllt.
CIF bietet auch eine Möglichkeit, weitere Reputationslisten bereitzustellen und zu verarbeiten, die noch nicht im Lieferumfang enthalten sind. Das ist insbesondere für private
Reputationslisten praktisch, die nicht öffentlich zur Verfügung stehen oder nicht im Internet bereitgestellt werden. CIF kann Daten in Textdateien mit und ohne Trennzeichen,
in XML-Dateien, JSON-Dateien usw. verarbeiten.
Um herauszufinden, wie Sie CIF dazu bringen, eigene Listen abzurufen, können Sie sich
die vorhandenen Konfigurationsdateien ansehen. Abb. 8.7 zeigt die Konfigurationsdatei
für die Liste von malwaredomains.com, eine Textdatei mit Trennzeichen.
Abbildung 8.7: Konfigurationsdatei für eine Textliste mit Trennzeichen
Für diese Art von Liste ist nur eine minimale Konfiguration erforderlich. Der erste Abschnitt der Konfigurationsdatei gibt an, wo die Liste zu finden ist (Feed), und legt verschiedene Werte fest, darunter die Vertrauenswürdigkeit der Liste (confidence) und eine
Klassifizierung, wofür der Indikator verwendet wird (assessment). Der zweite Abschnitt
definiert, wie die einzelnen Textteile den Spalten in der CIF-Datenbank zugeordnet werden (values), welche Trennzeichen in der Textdatei verwendet werden (delimiter) und wie
oft die Liste aktualisiert werden sollte (period). In dem Beispiel werden die Einträge in der
8.2 Automatisieren der reputationsgestützten Erkennung 247
Liste durch ein Tabulator- und ein Seitenvorschubzeichen getrennt (\t|\f), und die Liste
wird täglich aktualisiert.
Mehr darüber, wie Sie eigene Konfigurationsdateien für verschiedene Datentypen erstellen können, erfahren Sie auf der CIF-Website.
Indikatoren abfragen
Nun brauchen wir eine Möglichkeit, die CIF-Informationen abzufragen. Dazu gibt es
zwei Möglichkeiten, den Perl-Client von CIF und die Webschnittstelle, wobei der PerlClient nicht nur der Standardmechanismus für den Umgang mit CIF-Daten ist, sondern
auch die stabilste Methode darstellt. Mit dem Befehl cif können Sie jeden Indikatortyp
abfragen, der in der CIF-Datenbank enthalten ist. Nehmen wir beispielsweise an, Sie suchen eine IP-Adresse, von der Sie vermuten, dass sie im Zusammenhang mit schädlichen
Aktivitäten steht. Das können Sie mit folgendem Befehl erreichen:
cif –q 112.125.124.165
Die Option -q sorgt für eine einfache Abfrage aller verfügbaren CIF-Daten. Sie können
mit der CIDR-Schreibweise (also z. B. 112.125.124.0/24) auch nach IP-Adressbereichen
suchen. Das Ergebnis des vorstehenden Befehls sehen Sie in Abb. 8.8.
Abbildung 8.8: IP-Adressabfrage in CIF
Diese Ausgabe zeigt, dass die fragliche IP-Adresse in den Reputationslisten sowohl von
ZeuS Tracker als auch von Alientvault enthalten ist und als Teil eines Botnetzes eingestuft
wird. In der Ausgabe ist auch der URL zu beiden Listen enthalten, sodass Sie weitere Kontextinformationen über den Indikator in Erfahrung bringen können. Des Weiteren sind
Informationen über Einschränkungen und die Vertrauenswürdigkeit angegeben. All diese
Werte können in der CIF-Konfiguration angegeben werden, wobei manche Listen Vorgabewerte für Einschränkungen und Vertrauenswürdigkeit erhalten.
Wenn Sie den Befehl ein weiteres Mal ausführen, erscheint in der Liste ein weiterer Eintrag
mit dem Vermerk »searched« unter der Überschrift »Assessment«. Sobald jemand in CIF
nach einem bestimmten Indikator sucht, wird dieser Vorgang protokolliert und in den
Suchergebnissen angegeben. Das ist praktisch, um herauszubekommen, ob schon einmal
andere Analytiker nach demselben Indikator gesucht wurden. Es kann vorkommen, dass
ein bestimmter Indikator, über den Sie sich Sorgen machen, in keiner öffentlichen Repu-
248 8 Reputationsgestützte Erkennung
tationsliste enthalten ist, dass aber mehrere andere Analytiker Ihrer Organisation schon
wiederholt danach gesucht haben. Wenn so viele Leute misstrauisch sind, deutet das darauf hin, dass Aktivitäten im Zusammenhang mit diesem Indikator eine weitere Untersuchung rechtfertigen. Die Ausgabe in Abb. 8.9 zeigt die CIF-Abfrage nach einem Indikator,
nach dem schon mehrfach gesucht wurde.
Abbildung 8.9: Eine CIF-Abfrage mit mehreren vorherigen Suchvorgängen
Wenn Sie die Ausgabe von Einträgen aufgrund früherer Benutzerabfragen unterdrücken
wollen, können Sie die Option -e verwenden. Hinter diesem Schalter können Sie unter
dem Punkt »Assessment« alle Arten von Informationen angeben, die Sie in den Suchergebnissen nicht sehen wollen. Um Angaben zu vorherigen Suchen zu unterdrücken,
hängen Sie an Ihre Abfrage -e search an.
Indikatoren bereitstellen
Eine meiner Lieblingsfunktionen von CIF ist die Möglichkeit, eigene Ausgabe-Plug-Ins zu
erstellen und zu nutzen. Damit können Sie die Indikatoren in der CIF-Datenbank in einem
geeigneten Format für verschiedene Erkennungsmechanismen ausgeben. CIF ermöglicht
die Ausgabe von Daten in verschiedenen Formen, z. B. als CSV-Dateien, ASCII-Tabellen,
HTML-Tabellen, Iptables-Firewall-Regeln, PCAP-Filter, Snort-Regeln und Bro-Eingaben.
Standardmäßig gibt CIF Ergebnisse in einem Tabellenformat aus, um die Lesbarkeit in
einem Terminal-Fenster zu erhöhen. Wenn Sie stattdessen eines der anderen Formate verwenden möchten, geben Sie es mit der Option -p an. Um beispielsweise die Ergebnisse der
vorherigen Abfrage als Snort-Regel auszugeben, geben Sie folgenden Befehl:
cif –q 112.125.124.165 –p Snort
Wie Sie in Abb. 8.10 sehen, wird daraufhin für jede Eintrag in den Suchergebnissen eine
Snort-Regel ausgegeben.
8.2 Automatisieren der reputationsgestützten Erkennung 249
Abbildung 8.10: Ausgabe einer CIF-Abfrage als Snort-Regel
Wenn Sie Snort-Regeln auf der Grundlage von CIF-Ausgaben erstellen, müssen Sie die
Regeln immer sorgfältig überprüfen, bevor Sie sie bereitstellen, damit sie eine optimale
Leistung zeigen und mit dem Standard folgen, den Sie für andere IDS-Signaturen in
Ihrer Organisation verwenden. Beispielsweise überprüfen von CIF erstellte Snort-Regeln
nur ausgehenden Datenverkehr an die genannten IP-Adressen. In vielen Fällen ist es jedoch sinnvoll, diese Regeln so umzuschreiben, dass sie den aus- und den eingehenden
Datenverkehr zu und von diesen Adressen überwachen. Die Anpassung dieser Regeln ist
ziemlich einfach und wird im nächsten Kapitel behandelt.
CIF steckt immer noch in den Kinderschuhen und weist einige Eigenheiten auf, hat aber
ein großes Potenzial. Die Unterstützung der Community für dieses Projekt hat enorm
zugenommen, wobei viele Benutzer Konfigurationen für verschiedene Arten von Listen
und Ausgabe-Plug-Ins beitragen. Ich habe selbst mehrere Organisationen kennengelernt,
die CIF erfolgreich zur Verwaltung der reputationsgestützten Erkennung einsetzen. Wenn
Sie mehr über CIF erfahren wollen, schauen Sie sich die Projektwebsite auf https://code.
google.com/p/collective-intelligence-framework/ an.
8.2.3 Reputationsgestützte IP-Adressenerkennung mit Snort
Snort gehört zu den am weitesten verbreiteten signaturgestützten IDS der Welt. Wir werden uns im nächsten Kapitel eingehender damit beschäftigen, uns hier aber schon einmal
die Möglichkeiten dieser Software zur reputationsgestützten Erkennung ansehen. Dazu
dient in Snort der Reputations-Präprozessor.
Früher erfolgte die reputationsgestützte IP-Adressenerkennung in Snort anhand von Standardregeln. Um die Leistungsprobleme zu überwinden, die sich bei dieser Methode stellten,
wurde der Reputations-Präprozessor entwickelt. Er wird vor allen anderen Präprozessoren
ausgeführt und ist so effizient, dass er auch mit umfangreichen IP-Adressenlisten umgehen
kann.
In Security Onion ist der Reputations-Präprozessor von Snort zwar standardmäßig aktiviert, die Alarmfunktion aber nicht. Bevor Sie Einträge zur Sperrliste des Präprozessors
hinzufügen, sollten Sie die Alarmfunktion einschalten. Dazu müssen Sie auf dem Security-Onion-Sensor zunächst die Datei preprocessor_rules im Verzeichnis /etc/nsm/rules
erstellen. Sie muss die folgende Regel zur Alarmierung bei Ereignissen des ReputationsPräprozessors enthalten:
250 8 Reputationsgestützte Erkennung
alert ( msg: "EPUTATION_EVENT_BLACKLIST"; sid: 1; gid: 136; rev: 1;
metadata: rule-type preproc ; classtype:bad-unknown; )
Als Nächstes müssen Sie die Snort-Konfiguration anpassen, damit die gerade erstellte
­Datei mit der Präprozessorregel auch verarbeitet wird. Dazu öffnen Sie die Datei /etc/
nsm/sensor_name/snort.conf und entfernen die Kommentarzeichen der folgenden Zeile:
include $PREPROC_RULE_PATH/preprocessor.rules
Jetzt müssen Sie der Sperrliste des Reputations-Präprozessors nur noch IP-Adressen hinzufügen. Die betreffende Datei ist /etc/nsm/rules/black_lists.rules und akzeptiert sowohl
einzelne IP-Adressen als auch IP-Adressbereiche in CIDR-Schreibweise. Hinter einem IPAdresseintrag können Sie mithilfe des Zeichens # auch Kommentare angeben. Beispielsweise können Sie eine Adresse, die Sie nur zum Testen des Präprozessors verwenden, wie
folgt kennzeichnen:
192.0.2.75 # Testadresse
Damit die Änderungen in Kraft treten, müssen Sie Snort auf dem Sensor neu starten
(siehe Abb. 8.11).
Abbildung 8.11: Neustart des Snort-Prozesses
Um die neue Regel zu testen, pingen wir einfach die Adresse 192.0.2.75 von Security Onion
oder von einem Gerät an, das von Security Onion überwacht wird. Abbildung 8.12 zeigt
einen Alarm, der von dieser Regel ausgelöst wird.
Sie können der Datei black_list.rules eine große Menge von IP-Adressen hinzufügen, ohne
die Leistung des Sensors zu beeinträchtigen. Da die von diesem Präprozessor ausgegebenen Alarme nicht sehr ausführlich sind, sollten Sie es sich angewöhnen, in der Sperrlistendatei Kommentare mit Kontextinformationen zu den Indikatoren anzugeben, sodass die
Analytiker darauf zurückgreifen können, wenn ein Alarm ausgelöst wird.
Der Reputations-Präprozessor von Snort bietet nicht viele Extras, aber wenn Sie in Ihrer
Umgebung ohnehin schon Snort verwenden, dann ist es sehr einfach, die reputationsgestützte Erkennung von IP-Adressen mit wenigen Änderungen einzurichten. Leider kann
8.2 Automatisieren der reputationsgestützten Erkennung 251
dieser Präprozessor nur IP-Adressen verarbeiten. Wenn Sie in Snort auch die Kommunikation mit schädlichen Domänen erkennen wollen, müssen Sie normale Snort-Regeln
verwenden, was wir in Kapitel 9 besprechen. Allerdings kann es zu Leistungsproblemen
kommen, wenn die Standardregeln eine sehr große Anzahl von schädlichen Domänen erkennen sollen. Mehr über den Reputations-Präprozessor von Snort und die verschiedenen
Konfigurationsoptionen erfahren Sie auf http://manual.snort.org/node175.html.
Abbildung 8.12: Ein vom Reputations-Präprozessor ausgelöster Alarm
8.2.4 Reputationsgestützte IP-Adressenerkennung mit Suricata
Als Alternative zu Snort für die signaturgestützte Erkennung nimmt Suricata rasch an
Beliebtheit zu. Das liegt hauptsächlich daran, dass es in der Lage ist, Datenverkehr parallel in mehreren Threads zu untersuchen, was für die Überwachung von Verbindungen mit hohem Durchsatz von Vorteil ist. Da Suricata die gleiche Regelsyntax verwendet
wie Snort, können Regeln zwischen den beiden Systemen ausgetauscht werden. In Kapitel 9 werden wir uns eingehender mit Suricata beschäftigen. Hier schauen wir uns nur
die ­reputationsgestützte IP-Adresserkennungs-Engine der Software an. Es kann vorteilhaft sein, das nächste Kapitel vorzulesen, um ein Verständnis für die Funktionsweise von
­Suricata zu bekommen, und dann zu diesem Abschnitt zurückzukehren.
Die reputationsgestützte IP-Adresserkennung von Suricata erfolgt auf eine Weise, die die
Verarbeitung großer Mengen von Einträgen optimieren soll. Dazu wird die gleiche API
verwendet wie für Kennzeichnungen und Schwellenwerte. Um diese Funktion zu aktivieren, müssen Sie in der Konfigurationsdatei Suricata.yaml den folgenden Abschnitt ändern:
252 8 Reputationsgestützte Erkennung
# IP Reputation
reputation-categories-file: /etc/nsm/sensor-name/iprep/categories.txt
default-reputation-path: /etc/nsm/rules
reputation-files:
- zeustracker.list
- spyeyetracker.list
- mdl.list
- watch.list
Das erste Element, das in dieser Konfigurationsdatei definiert wird, ist die Datei mit den
Reputationskategorien. Damit können Sie die Listen und die zugehörigen Alarme in verwaltbare Einheiten ordnen. In der Kategoriedatei müssen Sie eine eindeutige ID-Nummer
für die Kategorie, den Namen der Kategorie und eine Beschreibung angeben. Das Format
der einzelnen Einträge sieht also wie folgt aus:
<ID>,<Kurzname>,<Beschreibung>
Gewöhnlich werden Kategorien für die einzelnen Quellen von Listen erstellt. Beispielsweise
kann eine Kategoriedatei wie folgt aussehen:
1,ZeusTracker,IP-Adressen von Zeus Tracker
2,SpyEyeTracker,IP-Adressen von SpyEye Tracker
3,MDL,IP-Adressen von Malware Domain List
4,Watchlist,IP-Adressen von interner Überwachungsliste
Als Nächstes müssen Sie den Standardreputationspfad angeben, also das Verzeichnis, das
die Dateien mit den Reputationslisten enthält. In unserem Beispiel haben wir diese Dateien in dasselbe Verzeichnis gestellt, in dem Security Onion Suricata- und Snort-Regeln
unterbringt.
Mit dem letzten Konfigurationseintrag geben Sie die Listendateien an, die Suricata verarbeiten soll. Diese Dateien müssen sich im Standardreputationspfad befinden. Die Einträge
in diesen Dateien müssen folgendes Format aufweisen:
<IP-Adresse>,<Kategorie>,<Vertrauenswürdigkeit>
Dabei müssen die IP-Adressen im Standardformat aus vier durch Punkten getrennten
Oktetten angegeben werden. Dazu müssen eine der Kategorienummern aus der Kategoriedatei sowie ein numerischer Wert für die Vertrauenswürdigkeit angegeben sein. Eine
Reputationslistendatei sieht also beispielsweise wie folgt aus:
8.2 Automatisieren der reputationsgestützten Erkennung 253
192.0.2.1,1,65
192.0.2.2,1,50
192.0.2.3,2,95
Nach der Einrichtung der Reputationsfunktion müssen Sie nur noch Alarme definieren,
damit die Analytiker informiert werden, wenn eine Kommunikation mit einer der betreffenden IP-Adressen festgestellt wird. Dazu fügen Sie eine Regel mit der Direktive iprep
hinzu, die folgende vier Optionen annimmt:
•• Richtung des Datenverkehrs (any, src, dst oder both): Damit wird die Richtung des
Datenverkehrs zur oder von der IP-Adresse angegeben.
•• Kategorie (Kurzname): Der Kurzname der Kategorie, in der Sie nach einer Übereinstimmung suchen. Die Angabe muss genau der Bezeichnung entsprechen, die in der
Kategoriedatei angegeben ist.
•• Operator (>, <, =): Der Operator, der zusammen mit dem angegebenen Reputationswert verwendet wird.
•• Vertrauenswürdigkeit (1 bis 127): Damit werden Übereinstimmungen auf die Fälle
beschränkt, in denen der Wert der Vertrauenswürdigkeit mit dem Ausdruck aus dem
hier angegebenen Wert und dem Operator übereinstimmt.
Diese Direktive kann noch mit anderen Merkmalen kombiniert werden, die gewöhnlich
in Suricata-Regeln eingesetzt werden, was eine hohe Vielseitigkeit bietet. Allerdings verringern jegliche zusätzliche Merkmale, etwa eine Überprüfung auf übereinstimmende
Inhalte, die Geschwindigkeit, mit der die Reputationsregeln verarbeitet werden. Regeln,
die nur eine iprep-Direktive enthalten, bilden die schnellste Möglichkeit, um auch große
Mengen von Reputationsregeln auf der Grundlage von IP-Adressen zu verwenden.
Das folgende Beispiel zeigt eine sehr einfache reine IP-Adressregel:
alert ip any any ->any any (msg:"IPREP Malware Domain List – High Confidence";
iprep:dst,MDL,>,75; sid:1; rev:1;)
Diese Regel löst immer dann einen Alarm aus, wenn ausgehende Kommunikation zu einer IP-Adresse in der MDL-Liste mit einer Vertrauenswürdigkeit größer als 75 erkannt
wird. Einen solchen Alarm sehen Sie in Abb. 8.13.
254 8 Reputationsgestützte Erkennung
Abbildung 8.13: Ein Alarm aufgrund einer iprep-Direktive von Suricata
Mit dieser Methode ist Suricata in der Lage, große Mengen von IP-Adressen zu verarbeiten. Ich habe von Organisationen gehört, die das mit Listen von einer Million Adressen
getestet haben. Suricata ist sehr stabil und eine hervorragende Wahl für die reputationsgestützte Erkennung von IP-Adressen.
8.2.5 Reputationserkennung mit Bro
Das IDS Bro ist eines der leistungsfähigsten und flexibelsten NSM-Erkennungswerkzeuge.
Wir werden uns in Kapitel 10 ausführlich damit beschäftigen, wollen uns hier aber schon
einmal seine Fähigkeiten zur reputationsgestützten Erkennung ansehen.
Bro eignet sich sehr gut für die Erkennung verschiedenere Arten von Indikatoren wie
IP-Adressen, Domänen, E-Mail-Adressen und SSl-Zertifikaten. Dazu verwendet es seine eigenen Informationsverarbeitungsfunktionen, die zusammengenommen als »IntelFramework« bezeichnet werden (abgeleitet von »intelligence« für nachrichtendienstliche
Informationen, nicht von dem Prozessorhersteller). Tabelle 8.1 nennt die Datentypen, die
dieses Framework unterstützt, und die Bezeichnungen, die Bro dafür in seiner Skriptsprache verwendet. Für unser Beispiel beschränken wir uns auf IP-Adressen, Domänen und
E-Mail-Adressen.
8.2 Automatisieren der reputationsgestützten Erkennung 255
Tabelle 8.1: Datentypen, die das Intel-Framework von Bro unterstützt
Datentyp
Bezeichnung in Bro
Beschreibung
IP-Adresse
Intel::ADDR
Eine IPv4- oder IPv6-Adresse oder
ein CIDR-Block
URL
Intel::URL
Der vollständige URL, aber ohne das
Präfix http:// bzw. https://
Softwarename
Intel::Softwrae
Der Name einer bestimmten Software
E-Mail-Adresse
Intel::EMAIL
Eine E-Mail-Adresse
Domänenname
Intel::DOMAIN
Der vollständige Domänenname einschließlich jeglicher Subdomänen
Benutzername
Intel::USER
Ein Benutzername
MD5-, SHA-1- oder SHA256-Dateihash
Intel::HASH
Der Hash eines Dateiobjekts (hängt
vom Bro File Analysis Framework ab)
SSL-Zertifikathash
Intel::CERT_HASH
Der SHA-1-Hash eines SSL-Zertifikats
Das Intel-Framework ist eng mit der ausgedehnten Bibliothek von Protokollparsern verzahnt, über die Bro verfügt. Wenn Sie erst einmal einen Indikator in das Intel-Framework
geladen haben, müssen Sie sich selbst nicht mehr darum kümmern. Sollte Bro diesen
Indikator jemals in irgendeinem der Protokolle finden, weiß es, wie es ihn dekodieren
muss, und wird ihn protokollieren, unabhängig davon, wie viele Schichten von Tunneln
oder Verschlüsselungen es dabei abschälen muss. Das macht das Intel-Framework zu einer der leistungsfähigsten und flexibelsten Lösungen für die Erkennung von Indikatoren.
Bro lässt sich auch erstaunlich stark erweitern. Mit ein bisschen Brogrammierung (ja, so
wird das wirklich genannt!) können Sie Ihre eigenen Indikatortypen hinzufügen und Bro
danach Ausschau halten lassen.
Um das Intel-Framework zu konfigurieren, müssen Sie eine Eingabedatei erstellen, die alle
Indikatoren aufführt. Dabei handelt es sich um eine einfache tabulatorgetrennte Textdatei. Die erste Zeile sieht zwar wie ein Kommentar aus, ist aber obligatorisch und beschreibt
die Felder in den folgenden Zeilen. In Abb. 8.14 sehen Sie das Format einer solchen Eingabedatei. Was dieses Format angeht, ist Bro ziemlich wählerisch. Achten Sie also darauf,
dass Sie die einzelnen Felder durch genau einen Tabulatorschritt trennen und dass die
Datei keine Leerzeichen enthält.
256 8 Reputationsgestützte Erkennung
Abbildung 8.14: Beispieleinträge in einer Bro-Reputationsliste
Jede Datenzeile beginnt mit dem eigentlichen Indikator und seinem Datentyp (nach Tabelle 8.1). Die restlichen Felder müssen zwar in jeder Datenzeile vorhanden sein, die
Angabe von Werten ist jedoch optional. Wenn Sie einen Wert nicht bereitstellen wollen,
geben Sie einfach einen Bindestrich in das betreffende Feld ein.
Im Feld meta.source können Sie den Namen der Quelle angeben, aus der der betreffende Indikator stammt. Innerhalb dieses Namens können Sie Leerzeichen und Satzzeichen
verwenden, aber keine Tabulatoren. Ja nach Ihrer Informationsverwaltungsstruktur
kann es sich bei der Quelle auch um einen Datenbankschlüssel oder um den URL für
eine webgestützte Aufklärungsanwendung handeln. Wenn der Indikator im Datenverkehr
vorkommt, protokolliert Bro die entsprechenden Daten und nimmt in das Protokoll den
Wert dieses Feldes auf, um etwas Kontext bereitzustellen.
Das Feld meta.do_notice nimmt einen booleschen Wert an, also entweder T für wahr oder
F für falsch. Damit legen Sie fest, ob Übereinstimmungen mit dem Indikator auch in die
Datei notice.log aufgenommen werden sollen. Mit solchen »Notizen« kann Bro zusätzlich
Aufmerksamkeit auf ein Ereignis lenken, auch wenn es bereits an anderer Stelle protokolliert ist. Notizen und Gründe für ihre Verwendung werden wir ausführlicher in Kapitel 10
besprechen.
Mit dem Feld meta.if_in können Sie die Protokollierung von Notizen auf bestimmte
Kontexte einschränken (z. B. »nur wenn es im HTTP-Header Host: vorkommt«). Unabhängig von der Bedingung, die Sie hier angeben, protokolliert das Intel-Framework nach
wie vor sämtliche Protokolle, allerdings erstellt es nur dann Notizen, wenn die Bedingung erfüllt ist. Das ist beispielsweise dann praktisch, wenn ein Indikator insbesondere
im Zusammenhang mit HTTP-Datenverkehr von Bedeutung ist. Wenn er in DNS- und
E-Mail-Datenverkehr auftritt, schreibt Bro dafür auf jeden Fall Einträge in intel.log. Mit
der Angabe einer entsprechenden Bedingung können Sie jedoch verhindern, dass auch
Notizen dafür angelegt werden, da Sie schließlich nicht so sehr an dieser Aktivität in diesen Zusammenhängen interessiert sind.
Es gibt mehrere Möglichkeiten, um die Liste zu füllen. CIF enthält eine Option, um Daten in einem geeigneten Format für das Intel-Framework von Bro auszugeben. Das ist
8.2 Automatisieren der reputationsgestützten Erkennung 257
gewöhnlich die einfachste Möglichkeit. Alternativ können Sie auch ein eigenes Skript
schrei­ben, das Listeneinträge in diesem Format ausgibt. Zum Testen der Funktion können wir auch manuell Einträge hinzufügen.
Wenn wir die Datendatei mit Reputationsdaten haben, müssen wir sie mithilfe eines BroSkripts in das Intel-Framework laden. Bei der Standardinstallation von Bro werden Konfigurations- und Skriptdateien in /usr/local/bro/share/bro aufbewahrt, bei der in Security
Onion enthaltenen Version dagegen in /opt/bro/share/bro, weshalb wir in den folgenden
Beispielen diesen Speicherort verwenden. Erstellen Sie darin das Unterverzeichnis Reputation und kopieren Sie die Datendatei als /opt/bro/share/bro/sitze/Reputation/reputation.
dat dort hinein.
Als Nächstes müssen Sie der Bro-Standardstartdatei /opt/bro/share/bro/site/local.bro
folgende Codezeilen hinzufügen:
@load frameworks/intel/seen
@load frameworks/intel/do_notice
redef Intel::read_files+= {
"/opt/bro/share/bro/site/Reputation/reputation.dat"
};
In Kapitel 10 erfahren Sie mehr über die Skripterstellung in Bro. Der vorstehende Code
sollte allerdings auch so verständlich sein. Er lädt zwei Bro-Skritpmodule in das IntelFramework (seen und do_notice), fügt die neue Datendatei und die (zu Anfang leere)
Liste der Datendateien hinzu, die es beim Start von Bro lesen wird. Um den ganzen Rest
kümmert sich das Framework automatisch. Wenn Sie Ihrer Reputationsliste Einträge hinzufügen oder daraus entfernen müssen, dann können Sie einfach die Datei reputation.dat
entsprechend ändern. Bro ist intelligent genug, die Änderungen automatisch mitzubekommen und sich selbst zu aktualisieren.
Schließlich müssen wir Bro noch wissen lassen, dass wir die Konfiguration geändert haben.
Dazu sind folgende Vorgänge erforderlich:
1. Ausführen von broctl check: Dadurch wird der Code auf Fehler überprüft.
2. Ausführen von broctl install: Dadurch wird das neue Skript installiert.
3. Ausführen von broctl restart: Dadurch wird Bro neu gestartet.
Nachdem Sie diese Änderungen vorgenommen haben, sollte alles laufen. Wenn Bro irgendeinen der in der Datendatei aufgeführten Indikatoren erkennt, protokolliert es dies
in /usr/local/bro/logs/current/intel.log (Bro-Standardinstalltion) bzw. /etc/nsm/bro/logs/
current/intel.log (Security Onion). Bei Indikatoren, für die Sie meta.do_notice eingeschaltet haben, werden auch entsprechende Einträge in der Datei notice.log im selben
Verzeichnis angelegt. Ein Beispiel der Datei intel.log sehen Sie in Abb. 8.15.
258 8 Reputationsgestützte Erkennung
Abbildung 8.15: Beispielausgabe von intel.log
Die Protokollierung in Bro werden wir in Kapitel 10 noch ausführlicher besprechen. In
der Abbildung können Sie aber auch so schon leicht erkennen, dass jemand ein DNSLookup für applliednsm.com vorgenommen und die Security Onion-Website auf Google
Code besucht hat. Da die Reputationsdatendatei auch festlegt, dass beim Auftreten des
Indikators für appliednsm.com Notizen erstellt werden sollten, wird die DNS-Aktivität für
diese Domäne auch in notice.log festgehalten, wie Sie in Abb. 8.16 sehen.
Abbildung 8.16: Beispielausgabe von notice.log
Zur Veranschaulichung haben wir die Protokollausgaben hier im Rohformat direkt aus
den Dateien gelesen. In einer Produktionsumgebung ist es dagegen üblich, sie in ein Programm zur Protokollverwaltung wie ELSA oder Log Stash zu exportieren. Aber unabhängig davon, wie Sie die Daten einsehen, ist Bro ein äußerst wirkungsvolles Werkzeug zur
reputationsgestützten Erkennung.
8.3
Zusammenfassung
Die reputationsgestützte Erkennung ist eine der wenigen Möglichkeiten, in NSM leichte
Siege zu erringen, da sie einfach anzuwenden und doch wirkungsvoll ist. Wenn Sie gerade erst mit Network Security Monitoring beginnen, dann ist die reputationsgestützte
Erkennung die einfachste Möglichkeit, gleich von Anfang an möglichst viel aus Ihren
Bemühungen herauszuholen.
8.3 Zusammenfassung 259
In diesem Kapitel haben wir uns die Wichtigkeit der reputationsgestützten Erkennung
sowie mehrere Quellen für öffentliche Reputationslisten angesehen. Des Weiteren haben
wir uns verschiedene Möglichkeiten angesehen, die reputationsgestützte Erkennung zu
automatisieren – von einfachen BASH-Skripts über das Collective Intelligence Framework bis zum Einsatz von Snort, Suricata und Bro. Die drei letztgenannten Produkte
sehen wir uns in den folgenden Kapiteln genauer an.
9
Signaturgestützte Erkennung mit
Snort und Suricata
Die gängigste Form von IDS bilden die signaturgestützten Systeme. Sie untersuchen Paketdaten auf Indikatoren eines Einbruchs, wobei die Indikatoren mit IDS-spezifischen
Direktiven zu Signaturen kombiniert werden. Diese Signaturen (oder Regeln) sagen
dem IDS, wie es die Indikatoren in den Netzwerkdaten finden kann. Wenn ein solches
signaturgestütztes IDS Daten findet, die mit dem Inhalt einer Signatur übereinstimmen,
generiert es Alarmdaten, um die Analytiker zu benachrichtigen.
Die signaturgestützte Erkennung war mehr als ein Jahrzehnt lang das A und O der Netzwerksicherheit, was teilweise an seiner Ähnlichkeit mit der Erkennung schädlicher Aktivitäten durch Antivirussoftware auf Hostebene lag. Das Rezept ist ziemlich einfach: Ein
Analytiker beobachtet eine schädliche Aktivität, leitet Indikatoren daraus ab und entwickelt daraus Signaturen. Wenn die Aktivität erneut auftritt, lösen diese Signaturen Alarm
aus. Früher, als es nur eine geringe Anzahl von Malwarestämmen gab, über die man sich
auf dem Laufenden halten musste, war diese Vorgehensweise äußerst wirkungsvoll, doch
in der heutigen Zeit sind signaturgestützte Mechanismen als eine Art von »Antivirussoftware auf Netzwerkebene« nicht mehr so erfolgreich. Das bedeutende Malwarerepository
http://www.virusshare.com enthält bereits über elf Millionen verschiedene Malwareproben, und das ist nur ein Teil der gesamten Malware, die in den Weiten des Internets zu
262 9 Signaturgestützte Erkennung mit Snort und Suricata
finden ist. Signaturen für all diese Varianten von Malware zu erstellen und zu pflegen ist
praktisch unmöglich.
In der modernen Zeit stellt sich jedoch heraus, dass signaturgestützte IDS in einer guten
Position sind, um andere schädliche Aktivitäten als Malware zu erkennen, beispielsweise
übliche Tätigkeiten nach einem erfolgten Einbruch wie der Start einer Shell, das unerwartete Anlegen von Benutzerkonten über das Netzwerk oder Richtlinienverletzungen wie die
Bereitstellung von nicht autorisierten Servern oder Systemen, die versuchen, Aktualisierungen von nicht genehmigten Quellen herunterzuladen. Signaturgestützte IDS können
immer noch dazu verendet werden, Malware zu erkennen, aber anstatt zu versuchen, jedes
Vorkommen von Schadcode im Netzwerk aufzuspüren, ist es am besten, nach Malware im Zusammenhang bestimmter und aktueller Bedrohungen zu suchen. Das können
beispielsweise weit verbreitete webgestützte Exploit-Kits (Blackhole, Redkit usw.) oder
Malware sein, die im Zusammenhang mit aktuellen Weltereignissen steht. Wie Sie signaturgestützte IDS bestmöglich einsetzen können, hängt letzten Endes von Ihrem Netzwerk
und von den Bedrohungen ab, denen Sie sich ausgesetzt sehen. Allerdings ist dies immer
ein entscheidender Bestandteil des Network Security Monitoring.
In diesem Kapitel lernen Sie mit Snort und Suricata zwei der am weitesten verbreiteten signaturgestützten IDS kennen. Dabei besprechen wir allgemeine Fragen zur Konfiguration
beider Tools und sehen uns genauer an, wie Signaturen erstellt werden. Außerdem werfen
wir einen Blick auf einige beliebte Methoden, die von Snort und Suricata ausgelösten
Alarme sichtbar zu machen. Dieses Kapitel stellt keine erschöpfende Beschreibung von
Snort und Suricata dar, sondern soll Ihnen grundlegende Informationen darüber vermitteln, wie sie funktionieren und wie Analytiker damit eine wirkungsvolle signaturgestützte
Erkennung erreichen können.
9.1
Snort
Das IDS Snort wurde 1998 von Martin Roesch als schlankes, kostenloses Open-Source-Intrusion-Detection-System entwickelt, was schließlich zur Gründung der Firma Sourcefire
Inc. führte. Seither hat sich Snort mit über vier Millionen Downloads zum beliebtesten
IDS der Welt gemausert. Das »schlanke« System ist zu einer sehr leistungsstarken und
flexiblen Software geworden, die in der IDS-Branche Maßstäbe setzt. Snort wird in Universitäten, Unternehmen und Behörden rund um die Welt eingesetzt. 2013 hat Cisco seine
Absicht verkündet, Sourcefire zu erwerben. (Bei der Abfassung dieses Kapitels war dieser
Handel jedoch noch nicht unter Dach und Fach.)1
Snort ist in Security Onion standardmäßig installiert, lässt sich aber auch sehr leicht manuell installieren. Auf http://snort.org/docs gibt Sourcefire eine Installationsanleitung für
verschiedene Betriebssysteme.
Wenn Sie bei der Einrichtung von Security Onion Snort als IDS ausgewählt haben, dann
läuft es bereits. Das können Sie mit dem Befehl sudo nsm_sensor_ps-status überprüfen.
In der Ausgabe in Abb. 9.1 wird snort-1 (alert data) als [OK] geführt.
1 Anmerkung des Verlags: Cisco hat Sourcefire im Jahr 2013 übernommen
9.1 Snort 263
Abbildung 9.1: Überprüfen des Sensorstatus
Snort selbst wird von der Befehlszeile aus aufgerufen. Mit snort -V können Sie die Programmversion überprüfen. Die Ausgabe dieses Befehls sehen Sie in Abb. 9.2.
Abbildung 9.2: Überprüfen der Snort-Version
9.1.1
Die Architektur von Snort
Die Funktionsweise von Snort hängt von dem Betriebsmodus ab, der zur Laufzeit angegeben wurde. Snort verfügt über drei dieser Modi, den Sniffer-, den Paketlogger- und den
NIDS-Modus.
Im Sniffer-Modus kann Snort Pakete in der Verbindung erkennen und in einem für
Menschen lesbaren Format ausgeben. Das ist ähnlich wie bei Tcpdump (was wir in
Kapitel 13 besprechen werden), allerdings ist die Ausgabe übersichtlicher, da Snort einzelne Aspekte des Datenverkehrs auf besondere Weise kennzeichnet. Ein Beispiel dafür,
wie Snort Paketdaten anzeigt, sehen Sie in Abb. 9.3.
Der Sniffer-Modus ist der Standardmodus von Snort. Um die Software in diesem Modus auszuführen, müssen Sie also lediglich mit dem Befehl snort -i <Schnittstelle> die
Erfassungsschnittstelle angeben.
264 9 Signaturgestützte Erkennung mit Snort und Suricata
Der Paketlogger-Modus funktioniert ähnlich, protokolliert die Pakete aber in einer Datei,
anstatt sie auf dem Bildschirm auszugeben. Diese Protokollierung erfolgt gewöhnlich im
binären PCAP-Format. Um diesen Modus zu aktivieren, geben Sie den Schalter -l und dahinter das Protokollverzeichnis an: snort -l <Protokollverzeichnis>. Um die PCAP-Dateien
später zu lesen, rufen Sie Snort wie folgt mit der Option -r auf: snort -r <PCAP-Datei>.
Der Modus, der uns hier am meisten interessiert, ist jedoch der NIDS-Modus, der dazu
dient, die im Netzwerk erfassten Daten zu lesen und gegebenenfalls Alarm auszulösen.
Dazu durchlaufen die Paketdaten mehrere Schichten der Architektur von Snort, wie Sie in
Abb. 9.4 sehen können.
Um Daten zu empfangen, kann Snort manuell eine angegebene PCAP-Datei untersuchen
oder sie direkt von der Überwachungsschnittstelle des Sensors beziehen. Der erste Schritt
nach dem Empfang der Daten besteht darin, sie mit einem Paketdecoder zu analysieren.
Tatsächlich handelt es sich dabei um mehrere Decoder, die die Paketdaten untersuchen
und normalisieren, um sie in einen geeigneten Zustand für die Präprozessoren und Erkennungsengines zu versetzen.
Wenn die Daten den Decoder durchlaufen haben, werden sie an die Präprozessoren von
Snort gesandt. Es gibt zwei Arten dieser Präprozessoren: Die erste Art dient nur zur Erkennung, während die zweite die Paketdaten auch verändert, sodass sie von der Erkennungsengine besser untersucht werden können.
Abbildung 9.3: Ausgabe von Snort im Sniffer-Modus
9.2 Suricata 265
Rohe Paketdaten vom Überwachungsport
Paketdecoder
Präprozessoren
Erkennungsengines
Ausgabe-Plug-Ins
Abbildung 9.4: Die Architektur des NIDS-Modus von Snort
Nach Abschluss dieser Vorverarbeitung werden die Daten an den eigentlichen Motor der
Snort-Architektur weitergeleitet, die Erkennungsengine. Sie ist dafür zuständig, die Regeln anzuwenden und zu bestimmen, ob die in diesen Regeln genannten Bedingungen in
dem zu analysierenden Datenverkehr vorherrschen.
Wenn die Engine zu dem Schluss kommt, dass der Netzwerkdatenverkehr tatsächlich mit
einer der Regeln übereinstimmt, übergibt sie die Daten an die Ausgabe-Plug-Ins, die in
der Snort-Konfigurationsdatei aktiviert sind, damit die Analytiker über den Alarm informiert werden. Snort kann Daten in einer Vielzahl von Formaten protokollieren, etwa als
einzeilige Alarme in einer Textdatei, als CSV-Datei, im PCAP-Format, im XML-Format,
als Systemprotokolleinträge usw. In vielen Produktionsumgebungen ist Snort zur Verwendung des offenen Formats Unified2 eingerichtet, das von Tools wie Barnyard2 und Pigsty
gelesen werden kann. Diese Werkzeuge wiederum machen flexiblere Ausgabeformate
möglich, z. B. die direkte Ausgabe in eine Datenbank.
9.2
Suricata
Snort ist zurzeit das am häufigsten verwendete signaturgestützte IDS, doch die Alternative
Suricata gewinnt immer mehr an Beliebtheit. Es handelt sich dabei um ein Open-Source-IDS, das von der Open Information Security Foundation (OISF) entwickelt und zu
Anfang vom US-Ministerium für Heimatschutz mitfinanziert wurde. Seit der Veröffentlichung im Jahr 2010 hat es eine große Fangemeinde gewonnen. Das liegt hauptsächlich
an seiner Leistung, die durch das Multithreaddesign möglich gemacht wird. In der Funktionsweise ähnelt Suricata sehr stark Snort. Wenn Sie also mit Letzterem vertraut sind,
sollten Sie keine Schwierigkeiten haben, sich auch in Suricata zurechtzufinden.
266 9 Signaturgestützte Erkennung mit Snort und Suricata
Wenn Sie bei der Einrichtung von Security Onion Suricata als IDS ausgewählt haben,
dann läuft es. Das können Sie mit dem Befehl sudo nsm_sensor_ps-status überprüfen. In
der Ausgabe in Abb. 9.5 wird suricata (alert data) als [OK] geführt.
Abbildung 9.5: Überprüfen des Sensorstatus
Wenn Sie auf dem Sensor ein anderes Betriebssystem als Security Onion ausführen,
müssen Sie Suricata manuell installieren. Auf https://redmine.openinfosecfoundation.org/
projects/suricata/wiki/Suricata_Installation hat die OISF Installationsanleitungen für verschiedene Betriebssysteme bereitgestellt.
Suricata selbst wird von der Befehlszeile aus aufgerufen. Mit suricata -V können Sie die
Programmversion überprüfen. Die Ausgabe dieses Befehls sehen Sie in Abb. 9.6.
Abbildung 9.6: Überprüfen der Suricata-Version
9.2.1 Die Architektur von Suricata
Suricata besteht aus verschiedenen Modulen, die, je nachdem, wie die Software aufgerufen wird, auf unterschiedliche Weise zusammenarbeiten. Der gewählte Betriebsmodus
(runmode) gibt an, wie die Module und die damit verknüpften Threads und Warteschlangen angeordnet werden. Welchen Betriebsmodus Sie wählen, hängt davon ob, welchem
Verarbeitungsschritt Sie Priorität einräumen möchten.
9.2 Suricata 267
Der Standardmodus ist für die Erkennung optimiert, das ressourcenintensivste Modul.
Eine grafische Darstellung dieses Modus sehen Sie in Abb. 9.7.
Rohpaketdaten vom Überwachungsport
Paketabruf
Decoder- und Streamanwendungsschicht
Erkennungsengine
Erkennungsthread
Erkennungsthread
Erkennungsthread
Ausgaben
Abbildung 9.7: Der Standardbetriebsmodus von Suricata
In einem anderen Modus wird PF_Ring genutzt, um an Verbindungen mit hohem Durchsatz den Paketabruf und die Dekodierung zu optimieren. Dieser Modus ist in Abb. 9.8
dargestellt.
Rohpaketdaten vom Überwachungsport
Paketabruf
Abruhread
Abruhread
Decoderthread
Decoderthread
Abruhread
Decoder
Decoderthread
Flusswarteschlange
Streamanwendung
Streamthread
Streamthread
Streamthread
Erkennungsengine
Erkennungsthread
Erkennungsthread
Ausgabethread
Ausgabethread
Erkennungsthread
Ausgaben
Ausgabethread
Abbildung 9.8: Der PF_Ring-Betriebsmodus von Suricata
268 9 Signaturgestützte Erkennung mit Snort und Suricata
Unabhängig vom gewählten Betriebsmodus setzt Surcata als Erstes sein Abrufmodul ein,
um Pakete an der Netzwerkschnittstelle zu erfassen. Diese Pakete werden dann an den
Decoder geleitet, der den Verbindungstyp ermittelt und die Daten dann für die Weiterverarbeitung durch die anderen Module normalisiert. Anschließend gehen die Daten an
das Streammodul, das die sitzungsfähigen Protokolle (wie TCP) im Auge behält und die
Paketdaten in der korrekten Reihenfolge zusammensetzt. Außerdem sortiert es auch Daten von Protokollen der Anwendungsschicht wie HTTP. Die auf diese Weise aufbereiteten
Daten werden danach dem Erkennungsmodul übergeben, das sie auf Übereinstimmungen mit den vom Benutzer angelegten Signaturen oder Regeln überprüft. Wenn ein Alarm
auftritt, wird er zusammen mit den zugehörigen Daten an das Ausgabemodul gesendet,
das die Daten in verschiedenen Formaten bereitstellen kann.
9.3
IDS-Engines in Security Onion austauschen
Wenn Sie Security Onion bereits eingerichtet und Snort oder Suricata als IDS-Engine ausgewählt haben, aber noch eine andere Engine ausprobieren wollen, ohne Security Onion
neu zu installieren, können Sie die Engine einfach wie folgt austauschen:
1. Halten Sie die NSM-Prozesse auf dem Sensor an:
sudo nsm_sensor_ps-stop
2. Ändern Sie die Hauptkonfigurationsdatei von SO.
Für den Wechsel von Snort zu Suricata:
sudo sed -i 's|ENGINE=snort|ENGINE=suricata|g' /etc/nsm/securityonion.conf
Für den Wechsel von Suricata zu Snort:
sudo sed -i 's|ENGINE=suricata|ENGINE=snort|g' /etc/nsm/securityonion.conf
3. Aktualisieren Sie den Satz der Sensorregeln für die entsprechende IDS-Engine:
sudo rule-update
4. Starten Sie die NSM-Prozesse auf dem Sensor:
sudo nsm_sensor_ps-start
9.4 Snort und Suricata initialisieren 269
Wenn Sie eigene Regeln für Ihren Sensor entwickelt haben, müssen Sie überprüfen, ob sie
mit der IDS-Engine kompatibel sind, zu der Sie wechseln, und vorausschauend jegliche
Unstimmigkeiten beheben, die die Initialisierung des IDS verhindern könnten.
9.4
Snort und Suricata initialisieren
Um Snort und Suricata als IDS zu initialisieren, müssen Sie lediglich mit der Befehlszeilenoption -c eine gültige Konfigurationsdatei und mit der Option -i eine Überwachungsschnittstelle angeben.
Snort:
sudo snort –c snort.conf –i eth1
Suricata:
sudo suricata –c suricata.yaml –i eth1
Vorher allerdings müssen Sie überprüfen, ob die Konfigurationsdatei gültig ist. Das können Sie mit dem Argument -T bewerkstelligen. Damit wird die IDS-Engine versuchsweise
mit der angegebenen Konfigurationsdatei gestartet.
Snort:
sudo snort –Tc snort.conf –i eth1
Suricata:
sudo suricata –Tc suricata.yaml –i eth1
Wenn alles funktioniert, wird bei Snort die Meldung aus Abb. 9.9 angezeigt, die besagt,
dass die Konfiguration erfolgreich validiert wurde. Nach Abschluss dieses Tests wird Snort
wieder beendet.
270 9 Signaturgestützte Erkennung mit Snort und Suricata
Abbildung 9.9: Erfolgreicher Test einer Snort-Konfigurationsdatei im NIDS-Modus
Bei problemloser Initialisierung von Suricata wird die Meldung aus Abb. 9.10 angezeigt,
die besagt, dass die Konfiguration erfolgreich geladen wurde. Auch Suricata wird nach
Abschluss des Tests automatisch beendet.
Sollten Snort oder Suricata bei diesem Test irgendwelche Fehler melden, müssen Sie diese beheben, bevor Sie die Programme in der Produktion einsetzen können. Ein häufiger
Fehler besteht darin, die Tools ohne die erforderlichen Berechtigungen zum Abfangen von
Netzwerkverkehr aufzurufen. Um diese Berechtigungen zu erteilen, wird gewöhnlich der
Befehl sudo verwendet.
9.4 Snort und Suricata initialisieren 271
Abbildung 9.10: Erfolgreicher Test der Suricata-Konfigurationsdatei im Standardmodus
Wenn Snort erfolgreich im NIDS-Modus gestartet wird, werden Sie benachrichtigt, dass
mit der Paketerfassung begonnen wurde, wobei auch die Prozessnummer (PID) angegeben
wird (siehe Abb. 9.11).
Abbildung 9.11: Erfolgreicher Start von Snort im NIDS-Modus
272 9 Signaturgestützte Erkennung mit Snort und Suricata
Nach einem erfolgreichen Start von Suricata werden Sie informiert, dass das Programm
die Threads initialisiert und die Engine gestartet hat (siehe Abb. 9.12).
Abbildung 9.12: Erfolgreicher Start von Snort im Standardmodus
In Security Onion können Sie Snort und Suricata mit dem Skript nsm_sensor_ps-start
starten. Eine Beschreibung dieses Skripts finden Sie in Anhang A.3.
9.5
Snort und Suricata konfigurieren
Die Funktionsweise von Snort und Suricata wird durch Konfigurationsdateien und Befehlszeilenargumente gesteuert. Die Konfigurationsdatei von Snort heißt snort.conf, die
von Suricata suricata.yaml. Beide ermöglichen es, praktisch jede Verhaltensweise der jeweiligen Anwendung zu steuern und anzupassen, etwa die Einzelheiten der Erkennungsengines, den Speicherort der Regeldateien oder die Deklaration der Variablen in diesen
Regeln. Bei Security Onion finden Sie diese Dateien in /etc/nsm/<Sensorschnittstelle>.
Wenn Sie eine Snort- oder Suricata-Installation verwalten oder wenn Sie einfach nur
mehr über die Funktionsweise dieser Programme wissen wollen, sollten Sie sich die
Zeit nehmen, die Konfigurationsdateien Schritt für Schritt unter die Lupe zu nehmen.
Diese Dateien sind ausgesprochen gut kommentiert. Im Folgenden sehen wir uns einige
gängige konfigurierbare Elemente an, die in beiden Produkten zur Verfügung stehen.
9.5 Snort und Suricata konfigurieren 273
9.5.1 Variablen
In der Informatik sind Variablen symbolische Namen, die auf einen gespeicherten Wert
verweisen. Sowohl Snort als auch Suricata verwenden Variablen, um IDS-Regeln leichter
erstellen und pflegen zu können und die Vielseitigkeit zu erhöhen. Snort setzt Variablen
auch in seiner Konfigurationsdatei ein, um auf Pfade zu verweisen. Eine Variable muss
nur einmal angelegt werden, damit sie beim Start von Snort geladen wird. Anschließend
können Sie jederzeit in der Konfigurationsdatei oder in den Snort-Regeln darauf verweisen. In unserem Zusammenhang gibt es drei Arten von Variablen: IP-Adress-, Port- und
Standardvariablen.
IP-Adressvariablen
IP-Adressvariablen werden verwendet, um Netzwerkadressen oder Adressbereiche für die
Verwendung in IDS-Regeln zu definieren. Mit diesen Adressen werden die Quellen bzw.
Ziele des zu untersuchenden Datenverkehrs angegeben. Wenn Sie für häufig vorkommende IP-Adressbereiche Variablen verwenden, müssen Sie bei Änderung nur die Variable
anpassen, um sämtliche Regeln, die auf diesen Bereich verweisen, auf den neuesten Stand
zu bringen.
Bei Snort stehen die IP-Adressvariablen in snort.conf. Zur Definition einer solchen Variable verwenden Sie das Schlüsselwort ipvar gefolgt vom Variablennamen und den IP-Adressen, die darin gespeichert werden sollen. Beispielsweise können Sie die folgende Variable
für einen DNS-Server in Ihrem Netzwerk erstellen:
ipvar DNS_SERVERS 192.168.1.10
Um mehrere IP-Adressen anzugeben, schließen Sie sie durch Kommata getrennt in eckige
Klammern ein. Das folgende Beispiel zeigt dies für mehrere SMTP-Mailserver:
ipvar SMTP_SERVERS [192.168.1.75,192.168.1.76,192.168.1.77]
Adressbereiche können Sie mit der CIDR-Schreibweise angeben. Auch diese Bereiche lassen sich durch Kommata getrennt in eckigen Klammern kombinieren. Das folgende Beispiel zeigt eine Variable mit zwei Subnetzen, die nur Webserver enthalten:
ipvar HTTP_SERVERS [192.168.2.0/24,192.168.12.0/24]
In Suricata wird zum Erstellen von Variablen kein besonderes Schlüsselwort gebraucht.
Stattdessen werden die Variablen eines bestimmten Typs in einem eigenen Abschnitt von
suricata.yaml definiert. Alle Variablen müssen unter der Überschrift vars angelegt werden,
IP-Adressvariablen unter der Zwischenunterschrift address-groups. Das Format zur Angabe der Adressen und die Verwendung der CIDR-Schreibweise ist jedoch identisch mit
der Vorgehensweise bei Snort:
274 9 Signaturgestützte Erkennung mit Snort und Suricata
vars:
address-groups:
DNS_SERVERS 192.168.1.10
SMTP_SERVERS [192.168.1.75,192.168.1.76,192.168.1.77]
HTTP_SERVERS [192.168.2.0/24,192.168.12.0/24]
Um eine IP-Adressvariable in einer Regel zu verwenden, stellen Sie ihrem Namen ein Dollarzeichen voran. Im folgenden Beispiel werden die Variablen $SMTP_SERVERS und $EXTERNAL_NET verwendet, um Versuche zu erkennen, die SMTP-Authentifzierung mit einem
Brute-Force-Angriff zu knacken:
alert tcp $SMTP_SERVERS 25 ->$EXTERNAL_NET any (msg:"GPL SMTP AUTH LOGON
brute force attempt"; flow:from_server,established; content:"Authentication
unsuccessful"; offset:54; nocase; threshold:type threshold,
track by_dst, count 5, seconds 60; classtype:suspicious-login;
sid:2102275; rev:3;)
Die beiden wichtigsten Netzwerkvariablen sind $HOME_NET und $EXTERNAL_NET.
$HOME_NET wird verwendet, um die IP-Adressbereiche anzugeben, die Snort bzw. Suricata
schützen soll. Damit werden oft intern verwendete IP-Adressen nach RFC1918 (nicht routingfähig) angegeben, z. B. 10.0.0.0/8, 172.16.0.0/12 oder 192.168.0.0/16m, je nach Platzierung und Sichtfeld des SEnsors.
Die Deklaration von $HOME_NET sieht gewöhnlich wie folgt aus:
Snort:
ipvar HOME_NET [192.168.0.0/16,10.0.0.0/8,172.16.0.0/12]
Suricata:
vars:
address-groups:
HOME_NET [192.168.0.0/16,10.0.0.0/8,172.16.0.0/12]
Mit $EXTERNAL_NET geben Sie IP-Adressbereiche an, die nicht von Snort bzw. Suricata geschützt werden. Das sind Bereiche, die nicht zur Organisation gehören und außerhalb des
Perimeternetzwerks liegen. Im Allgemeinen ist das alles, was nicht zu $HOME_NET gehört,
weshalb diese Variable üblicherweise auf !$HOME_NET gesetzt wird. Das Ausrufungszeichen
kann in Variablen eingesetzt werden, um den angegebenen Wert zu negieren. Eine andere
gebräuchliche Methode besteht darin, die Variable auf any zu setzen, was sämtliche IPAdressen einschließt.
Snort:
9.5 Snort und Suricata konfigurieren 275
ipvar EXTERNAL_NET !$HOME_NET
Suricata:
vars:
address-groups:
EXTERNAL_NET !$HOME_NET
Sowohl in Snort als auch in Suricata sind die Netzwerkvariablen $HOME_NET und $EXTERNAL_NET erforderlich. Die meisten öffentlich verfügbaren Regeln greifen auf diese Werte
zurück. Die anderen bereits in snort.conf und suricata.yaml vorhandenen Netzwerkvariablen sind optional, allerdings ist ihre Verwendung sehr empfehlungswert, da sie beim
Schreiben von Regeln eine höhere Vielseitigkeit und einen größeren Detaillierungsgrad
ermöglichen. Außerdem werden sie in öffentlich erhältlichen Regelsätzen verwendet (über
die wir weiter hinten noch sprechen werden). Unter anderem stehen folgende Netzwerkvariablen zur Verfügung:
•• $HTTP_SERVERS: Praktisch für Regeln im Zusammenhang mit server- oder clientseitigen
Web-Exploits.
•• $DNS_SERVERS: Praktisch für Regeln im Zusammenhang mit Domänenreputation und
Malware-Steuerservern.
•• $SMTP_SERVERS: Praktisch für Regeln im Zusammenhang mit Spam oder schädlichen
E-Mail-Anhängen.
•• $SSH_SERVERS: Praktisch zum Protokollieren von Aktivitäten im Zusammenhang mit
der Verwaltung von Switches, Routern und anderen Netzwerkgeräten über das Protokoll SSH.
Mit der weiter vorn angegebenen Syntax können Sie auch eigene Variablen erstellen, was
eine praktische Vorgehensweise ist, um Geräte zu gruppieren, beispielsweise wie folgt:
••
••
••
••
••
••
Missionskritische Systeme
VoIP-Telefone
Drucker
Netzwerkfähige Fernseher und Projektoren
Administrator-Arbeitsstatonen
Sensoren
Es gibt unbegrenzte Möglichkeiten. Je spezifischer Ihre Gruppen sind, umso mehr Flexibilität haben Sie beim Schreiben von Regeln.
276 9 Signaturgestützte Erkennung mit Snort und Suricata
Vorsicht
Überprüfen Sie Ihre Variablen genau! Beispielsweise kann es bei der Einrichtung
der Variable HTTP_SERVERS sehr leicht passieren, dass man Geräte wie Drucker und
Scanner, die über eingebaute Webserver verfügen, übersieht.
Portvariablen
Portvariablen definieren einen Schicht-4-Port bzw. einen Portbereich für die Verwendung
in IDS-Regeln. Damit werden die Quell- bzw. Zielports des zu untersuchenden Datenverkehrs angegeben.
Bei Snort werden diese Variablen mit dem Schlüsselwort portvar in snort.conf erstellt. Das
folgende Beispiel dient zur Angabe eines einzigen Ports für den SMTP-Dienst:
portvar SMTP_PORTS 25
Falls nötig, können Sie auch mehrere Ports gleichzeitig angeben. Dazu verwenden Sie die
gleiche Schreibweise wie bei IP-Adressvariablen, nämlich eine kommagetrennte Liste in
eckigen Klammern ein. Das folgende Beispiel zeigt dies für mehrere HTTP-Ports:
portvar HTTP_PORTS [80,81,82,83,84,85,86,87,88,89,311,383,591,593,
631,901,1220,1414,1741,1830,2301,2381,2809,3037,3057,3128,3702,4343,
4848,5250,6080,6988,7000,7001,7144,7145,7510,7777,7779,8000,8008,
8014,8028,8080,8085,8088,8090,8118,8123,8180,8181,8222,8243,8280,8300,8500,
8800,8888,8899,9000,9060,9080,9090,9091,9443,9999,10000,11371,
34443,34444,41080,50002,55555]
Portvariablen sind nützlich, um Regeln für die Kommunikation mit einem Dienst zu
schreiben, der nicht immer den erwarteten Port verwendet. Während die HTTP-Kommunikation gewöhnlich über Port 80 erfolgt, gibt es Webserver (insbesondere solche zur
Verwaltung von Sonderanwendungen oder besonderen Geräten), die einen anderen als
den Standardport verwenden. Portvariablen sind auch praktisch, wenn Dienste in Ihrem
Netzwerk so eingerichtet sind, dass sie nicht den Standardport nutzen. Das ist gängige
Praxis für administrative Protokolle wie SSH. Administratoren verwenden dafür meistens
einen anderen als den Standardport 22, um zu verhindern, dass dieser Dienst durch automatische Scans entdeckt wird.
9.5 Snort und Suricata konfigurieren 277
Standardvariablen
Der letzte Typ sind die sogenannten Standardvariablen, die nur von Snort verwendet werden. Erstellt werden sie mit dem Schlüsselwort var. Gewöhnlich besteht ihr Zweck darin, Verzeichnisse zu definieren. In der Standardkonfigurationsdatei snort.conf werden sie
häufig eingesetzt, beispielsweise um die Verzeichnisse mit den verschiedenen Arten von
Snort-Regeln anzugeben:
var RULE_PATH /etc/nsm/rules
var SO_RULE_PATH /etc/nsm/rules
var PREPROC_RULE_PATH /etc/nsm/rules
Der Großteil dieser Variablendefinitionen befindet sich im ersten Abschnitt von snort.
conf. Wenn Sie eigene Variablen erstellen und auch in snort.conf unterbringen wollen (statt
in einer gesonderten Datei), sollten Sie sie ebenfalls in diesen Abschnitt stellen, damit Sie
sie immer leicht wiederfinden können.
9.5.2 Regelsätze definieren
Damit Snort und Suricata den Netzwerkverkehr auf Einbruchsindikatoren untersuchen
können, müssen Regeln aufgestellt sein, die den Erkennungsengines im Grunde genommen mitteilen, wie sie die Indikatoren im Netzwerkverkehr ausfindig machen können.
Die Regeln sind in einfachen Textdateien gespeichert, wobei jede neue Zeile eine neue
Regel enthält. Damit Snort und Suricata diese Regeldateien verarbeiten können, müssen
sie in den Konfigurationsdateien aufgeführt werden.
Snort-Regeldateien definieren
Regeldeklarationen erfolgen gewöhnlich im letzten Abschnitt der Konfigurationsdatei
snort.conf. Hier müssen Sie mit dem Schlüsselwort include den Pfad zum Regelverzeichnis
und den Namen der darin befindlichen Regeldatei angeben. Der Pfad wird dabei meistens
mit der Variable $RULE_PATH angegeben, die im ersten Abschnitt von snort.conf definiert ist.
include $RULE_PATH/emerging-exploit.rules
278 9 Signaturgestützte Erkennung mit Snort und Suricata
Bericht von der Front
Anstatt in snort.conf ständig Verweise auf Regeldateien hinzuzufügen und zu entfernen, können Sie eine Regel, die Sie zurzeit nicht nutzen wollen, einfach mit
dem Zeichen # am Zeilenanfang auskommentieren. Snort verarbeitet keine Zeilen, die mit diesem Zeichen beginnen. Damit können Sie nicht nur einzelne Konfigurationsdateien vorübergehend außer Kraft setzen, sondern auch Kommentare hinzufügen. Die gleiche Möglichkeit besteht auch in suricata.yaml.
Snort ermöglicht auch die Verwendung von anderen Regeln als denen des Standardtyps:
•• Präprozessorregeln: Der Aufbau dieser Regeln hängt von den Funktionen ab, die die
Präprozessoren zur Verfügung stellen. Sie werden vor den Regeln für die Erkennungsengine verarbeitet.
•• Regeln für gemeinsame Objekte: Diese Regeln sind keine interpretierten Textzeilen,
sondern werden kompiliert. Damit können hochentwickelte Regeln erstellt werden. Es
ist auf diese Weise auch möglich, Regeln zu schreiben, ohne darin auf die Einzelheiten
der Indikatoren einzugehen.
Diese Regeln können an anderen Speicherorten untergebracht sein, weshalb es für sie eigene Regelpfadvariablen gibt:
include $PREPROC_RULE_PATH/preproc.rules
include $SO_RULE_PATH/sharedobj.rules
Snort lädt die Regeln bei der Initialisierung. Es ist aber auch möglich, eine Aktualisierung
der Konfiguration zu erzwingen, ohne Snort komplett neu zu starten. Das bietet den Vorteil,
dass Sie die Erkennung nicht jedes Mal für einige Sekunden unterbrechen müssen, wenn Sie
eine Regel ändern. Voraussetzung dafür ist, dass Sie Snort mit der Option -­ enable-reload
kompiliert haben. Um ein erneutes Laden der Regeln im laufenden Betrieb durchzuführen,
gehen Sie wie folgt vor:
1. Bringen Sie die ID des laufenden Snort-Prozesses in Erfahrung. Mit dem Befehl ps
können Sie eine Liste der aktuellen Prozesse aufrufen und dann mit grep nach dem
Snort-Prozess suchen:
ps aux | grep snort.conf
In unserem Beispiel aus Abb. 9.13 lautet die Prozess-ID 22859.
9.5 Snort und Suricata konfigurieren 279
Abbildung 9.13: Ermitteln der ID des Suricata-Prozesses
2. Senden Sie den Befehl kill mit der Option -SIGHUP, um das erneute Laden der Regeln
auszulösen. In unserem Beispiel lautet der Befehl dafür wie folgt:
sudo kill -SIGHUP 22859
3. Snort wird neu gestartet und verarbeitet die Datei snort.conf sowie die zugehörigen
Regeln. Beachten Sie, dass einige Konfigurationsoptionen nicht im laufenden Betrieb
nachgeladen werden können. Eine Liste der betreffenden Optionen finden Sie auf
http://manual.snort.org/node24.html.
Suricata-Regeldateien definieren
In Suricata geben Sie die Regeldateien im entsprechenden Abschnitt von suricata.yaml an.
Dabei müssen Sie zunächst den Regelpfad und dann unter der Überschrift rule-files die
Regeldateien angeben, wobei jede Datei in einer eigenen, mit einem Bindestrich eingeleiteten Zeile steht:
default-rule-path: /etc/nsm/rules/
rule-files:
- local.rules
- downloaded.rules
Wie Snort muss auch Suricata nicht komplett neu gestartet werden, um neue Regeln in
Kraft zu setzen. Mit der folgenden Vorgehensweise können Sie Ergänzungen, Löschungen
und Änderungen von Regeln im laufenden Betrieb übernehmen:
1. Vergewissern Sie sich, dass Regelaktualisierungen im laufenden Betrieb in suricata.
yaml aktiviert sind:
# When rule-reload is enabled, sending a USR2 signal to the Suricata process
will trigger a live rule reload. Experimental feature, use with care.
- rule-reload: true
280 9 Signaturgestützte Erkennung mit Snort und Suricata
2. Bringen Sie die ID des laufenden Suricata-Prozesses in Erfahrung. Mit dem Befehl ps
können Sie eine Liste der aktuellen Prozesse aufrufen und dann mit grep nach dem
Suricata-Prozess suchen:
ps aux | grep suricata.yaml
Nehmen wir für unser Beispiel an, die Prozess-ID laute 30577.
3. Senden Sie den Befehl kill mit der Option -USR2, um das erneute Laden der Regeln
auszulösen. In unserem Beispiel lautet der Befehl dafür wie folgt:
sudo kill -USR2 30577
Die Protokollausgabe dieses Vorgangs sehen Sie in Abb. 9.14.
Abbildung 9.14: Erzwingen einer Regelaktualisierung in Suricata mit dem Befehl kill -USR2
Öffentliche Quellen für Regeln
Regeln können manuell erstellt, von Organisationen gemeinsam verwendet oder aus öffentlichen Quellen bezogen werden. Wie Sie eigene Regeln schreiben, werden wir weiter
hinten in diesem Kapitel besprechen. Hier wollen wir uns zunächst zwei wichtige Quellen für Snort- und Suricata-Regeln ansehen, nämlich Emerging Threats und Sourcefire
VRT.
Emerging Threats (ET) wurde ursprünglich unter dem Namen Bleeding Snort im Jahr
2003 von Matt Jonkman gestartet und sollte als offene Plattform für den Austausch von
IDS-Signaturen dienen. ET hat die Entwicklung einer umfangreichen und aktiven Community von Signaturentwicklern gefördert und sogar verschiedene Zuschüsse erhalten,
mit denen das Projekt noch weiter ausgebaut werden konnte.
Die ET-Community ist so stark wie nie zuvor und bietet kostenlose, offene Regelsätze
sowohl für Snort als auch für Suricata an. Erstellt und gepflegt werden sie von der Com-
9.5 Snort und Suricata konfigurieren 281
munity. Darüber hinaus gibt es das gebührenpflichtige Abonnement ETPro für Regelsätze, die vom Forschungsteam von Emerging Threats gepflegt werden. Mehr darüber
können Sie auf http://www.emergingthreats.net/open-source/etopen-ruleset/ lesen. Auf
http://www.emergingthreats.net/blog/ führt das ET-Team auch ein Blog mit Benachrichtigungen über Regelaktualisierungen.
Das Vulnerability Research Team (VRT) von Sourcefire – dem Hersteller von Snort – ist
eine Elitegruppe von Sicherheitsforschern, die vorausschauend Erkennungsmöglichkeiten
für neu aufkommende Angriffstechniken, Malware und Schwachstellen entwickelt. Die
äußerst begabten VRT-Mitglieder sind auch für die Entwicklung und Pflege der Regeln im
offiziellen Regelsatz von Snort.org verantwortlich.
Es gibt drei offizielle Snort-Regelsätze. Der VRT-Regelsatz stellt das Premiumprodukt dar
und erfordert ein gebührenpflichtiges Abonnement. Dadurch aber bekommen Sie unmittelbaren Zugriff auf alle vom VRT entwickelten Regeln, sobald sie veröffentlicht sind.
An zweiter Stelle steht das Release für registrierte Benutzer, das eine kostenlose Registrierung auf Snort.org erfordert und jeweils 30 Tage nach der Veröffentlichung Zugriff auf
die VRT-Regeln erlaubt. Das dritte und letzte Angebot ist der Community-Regelsatz, eine
kostenlose Teilmenge des Regelsatzes für Abonnenten. Dafür ist keine Registrierung erforderlich. Dieser Satz wird täglich aktualisiert. Alle in diesem Satz veröffentlichten Regeln
unterliegen der GPL2-Lizenz.
Das Sourcefire VRT bietet zwar keinen eigenen Regelsatz für Suricata an, doch einige
der Regeln funktionieren auch in dieser Software. Allerdings unterstützt Suricata viele
der Optionen für Snort-Präprozessoren nicht. Wenn Sie VRT-Regeln für Suricata nutzen wollen, sollten Sie daher einzelne Regeln auswählen und in Suricata testen, anstatt zu
versuchen, den kompletten VRT-Regelsatz zu implementieren. So können Sie die Regeln
einzeln anpassen.
VRT-Regeln für Snort können Sie von http://www.snort.org/snort-rules/ herunterladen.
Auf http://vrt-blog.snort.org/ finden Sie außerdem ein sehr informatives Blog des VRT.
Weitere Informationen über Regelaktualisierungen und die neuesten Meldungen zu den
Regelsätzen gibt es auf http://blog.snort.org.
Regelaktualisierungen mit PulledPork verwalten
Sowohl Emerging Threats als auch Sourcefire VRT veröffentlichen fast jeden Tag neue
Regeln. Es wäre sehr mühselig, wenn Sie manuell nach Aktualisierungen suchen, sie herunterladen, ins richtige Verzeichnis kopieren und in der Produktion bereitstellen würden.
Um diesen Vorgang zu automatisieren und dafür zu sorgen, dass Ihre Regeln immer auf
dem neuesten Stand sind, können Sie PulledPork verwenden. Zu den vielen Funktionen
dieser Software gehören Mechanismen, um Regelaktualisierungen herunterzuladen, die
Möglichkeit, auch eigene Regeldateien zu verwalten und zu verteilen, und die Fähigkeit,
Regeländerungen nachzuvollziehen. Die Konfiguration von PulledPork können wir in
diesem Buch nicht besprechen, aber auf https://code.google.com/p/pulledpork/ erfahren Sie
mehr darüber.
282 9 Signaturgestützte Erkennung mit Snort und Suricata
Regelverwaltung in Security Onion
In Security werden Regeln standardmäßig in /etc/nsm/rules/ untergebracht. Aus öffentlichen Quellen wie Sourcefire VRT oder Emerging Threats heruntergeladene Regeln
kommen in die Datei downloaded.rules, selbst erstellte Regeln in local.rules. Sie können
auch weitere Regeldateien verwenden, müssen diese aber in snort.conf bzw. suricata.yaml
angeben.
Wenn Sie Security Onion als Ihre NSM-Plattform nutzen, sollten Sie Regeln nicht mit
den in den vorherigen Abschnitten beschriebenen Methoden aktualisieren, sondern das
Skript rule-update nutzen. Es führt auch zusätzliche Aufgaben aus, die für andere Tools
wie Barnyard2 und PulledPork erforderlich sind. Sie können es wie folgt ausführen:
sudo rule-update
Einen Auszug der Ausgabe dieses Skripts sehen Sie in Abb. 9.15.
Abbildung 9.15: Ausführen des Security Onion-Skripts rule-update
Für die Regelverwaltung in Security Onion sind vor allem die beiden Dateien disablesid.
conf und modifysid.conf von Bedeutung. Sie gehören zu PulledPork und werden auch dann
genauso wie hier beschrieben verwendet, wenn Sie nicht Security Onion ausführen.
9.5 Snort und Suricata konfigurieren 283
Die Datei disablesid.conf dient dazu, Regeln, die Sie nicht mehr anwenden wollen, dauerhaft zu deaktivieren. Das ist insbesondere bei der Nutzung von öffentlich erhältlichen
Regeln wichtig, da diese häufig aktualisiert werden. Nehmen wir an, Sie wollen die Regel
mit der SID 12345 deaktivieren. Auf den ersten Blick mag es ausreichen, die Regel einfach aus der Regeldatei zu löschen oder sie auszukommentieren. Das mag auch kurzzeitig
funktionieren, aber wenn PulledPork später Regelaktualisierungen von Emerging Threats
oder Sourcefire herunterlädt, wird die gelöschte oder deaktivierte Regel wiederhergestellt
und wieder in der Produktion angewendet. Daher müssen Regeln mithilfe von disablesid
.conf deaktiviert werden. Wenn PulledPork Regelaktualisierungen herunterlädt, geht es
diese Datei durch, um alle darin aufgenommenen Regeln erneut zu deaktivieren. Die
Einträge in dieser Datei haben das Format GID:SID. Um unsere Beispielregel dauerhaft
zu deaktivieren, müssen wir daher folgenden Eintrag in die Datei schreiben:
1:12345
Die Datei modifysid.conf dient dazu, aus öffentlichen Quellen bezogene Regeln dauerhaft
zu ändern. Ebenso wie bei gelöschten Regeln würde eine Aktualisierung durch PulledPork
eine von Ihnen angepasste Regeldatei ersetzen und damit die Änderungen zunichte machen. Daher durchsucht PulledPork nach jeder Aktualisierung die Datei modify.sid, um
jegliche Änderungen wieder auf die aktualisierte Regel anzuwenden.
Nehmen wir an, wir wollen die folgende Regel ändern:
alert ip any any ->any any (msg:"GPL ATTACK_RESPONSE id check returned
root"; content:"uid=0|28|root|29|"; fast_pattern:only; classtype:
bad-unknown; sid:2100498; rev:8;)
Um diese Regel zu ändern, müssen wir in modify.conf einen Eintrag hinzufügen, der die
SID der Regel, den zu ändernden Inhalt und die neue Version dieses Inhalts enthält. Hier
wollen wir alert ip any any durch alert ip $HOME_NET any ersetzen, damit nur dann
ein Alarm ausgelöst wird, wenn das gesuchte Muster in Datenverkehr gefunden ist, der
seinen Ursprung in einer IP-Adresse des eigenen Netzwerks hat. Der erforderliche Eintrag
in modifysid.conf lautet daher:
2100498 "alert ip any any" "alert ip $HOME_NET any"
Sowohl in disablesid.conf als auch in modifysid.conf sind mehrere Beispieleinträge enthalten. Weitere Beispiele speziell für Security Onion finden Sie auf https://code.google.com/p/
security-onion/wiki/ManagingAlerts.
284 9 Signaturgestützte Erkennung mit Snort und Suricata
9.5.3 Alarmausgabe
Sowohl Snort als auch Suricata bieten viele Möglichkeiten für die Ausgabe von Alarmdaten zur Analyse. Das ist sehr praktisch, um die Ausgabe an verschiedene Situationen
anzupassen.
In Snort wird die Alarmausgabe durch den Abschnitt für Ausgabe-Plug-Ins in snort.conf
gesteuert. Um ein bestimmtes Ausgabe-Plug-In zu verlangen, geben Sie es hinter dem
Schlüsselwort output an. Im Anschluss an den Namen des Plug-Ins können Sie auch noch
jegliche Optionen nennen, die es benötigt.
output<Plug-In-Name>: <Optionen>
Das Standardprotokollverzeichnis von Snort ist /var/log/snort, allerdings können Sie zur
Laufzeit mit dem Argument -l auch ein anderes Verzeichnis angeben.
In Suricata wird die Alarmausgabe durch den Ausgabeabschnitt in suricata.yaml gesteuert.
Unter der Überschrift outputs werden hier die einzelnen Ausgabemöglichkeiten zusammen mit den relevanten Optionen aufgeführt:
outputs:
- <Ausgabetyp>:
<Optionen>
Das Standardprotokollverzeichnis von Suricata ist /var/log/suricata, allerdings können Sie
zur Laufzeit mit dem Argument -l auch ein anderes Verzeichnis angeben.
Hinweis für Analytiker
Sowohl in Snort als auch in Suricata können gleichzeitig mehrere Ausgabemöglichkeiten genutzt werden. Sie werden dann in der Reihenfolge aufgerufen, in der
sie in snort.conf bzw. suricata.yaml aufgeführt sind.
Im Folgenden sehen wir uns einige häufig verwendete Ausgabemöglichkeiten an. Es gibt natürlich noch mehr als die in diesem Abschnitt genannten. Wenn Sie eine bestimmte Option
brauchen, schauen Sie am besten in der Dokumentation von Snort bzw. Suricata nach, denn
wahrscheinlich gibt es sie schon. Für die Alarmbeispiele habe ich http://www.testmyids.com
besucht, um einen Alarm aufgrund der Regel mit der SID 2100498 auszulösen:
alert ip any any ->any any (msg:"GPL ATTACK_RESPONSE id check returned
root"; content:"uid=0|28|root|29|"; fast_pattern:only; classtype:
bad-unknown; sid:2100498; rev:8;)
9.5 Snort und Suricata konfigurieren 285
Schnell
Bei dieser Option werden Alarme in einem sehr einfachen, einzeiligen Format angezeigt.
Das ist die kompakteste Möglichkeit. Sie lässt sich von Analytikern noch bequem an der
Befehlszeile einsehen und enthält ein Minimum an Informationen, um mit der Untersuchung der verknüpften Daten beginnen zu können.
08/05-15:58:54.524545 [**] [1:2100498:8] GPL ATTACK_RESPONSE id check
returned root [**] [Classification: Potentially Bad Traffic] [Priority:
2] {TCP} 217.160.51.31:80 ->172.16.16.20:52316
Vollständig
Neben allem, was im Schnellformat angezeigt wird, enthält das vollständige Format zusätzliche Angaben aus dem Header des Pakets, das den Alarm verursacht hat. Alarme in
diesem Format umfassen mehrere Zeilen, weshalb sie nicht so leicht mit Befehlszeilenwerkzeugen untersucht werden können.
[**] [1:2100498:8] GPL ATTACK_RESPONSE id check returned root [**]
[Classification: Potentially Bad Traffic] [Priority: 2]
08/05-15:58:54.524545 217.160.51.31:80 ->172.16.16.20:52316
TCP TTL:40 TOS:0x20 ID:44920 IpLen:20 DgmLen:299 DF
***AP*** Seq: 0x6BD4465B Ack: 0xE811E4E6 Win: 0x36 TcpLen: 20
Systemprotokoll
Alarme in diesem Format werden an einen Systemprotokollserver gesandt, der entweder
auf dem Sensor selbst oder auf einem anderen Gerät ausgeführt werden kann. Es handelt
sich hierbei um ein sehr weit verbreitetes Protokollformat, das von vielen verschiedenen
Geräten unterstützt wird und von den meisten Protokollverwaltungs- und Analysewerkzeugen verarbeitet werden kann. Systemprotokollausgaben umfassen eine einzige Zeile
und lassen sich an der Befehlszeile leicht durchsuchen. Die Menge der in diesem Format
bereitgestellten Informationen entspricht derjenigen des Schnellformat.
Aug 5 15:58:54 lakota snort: [1:2100498:8] GPL ATTACK_RESPONSE id check
returned root [Classification: Potentially Bad Traffic] [Priority: 2]:
{TCP} 217.160.51.31:80 ->172.16.16.20:52316
286 9 Signaturgestützte Erkennung mit Snort und Suricata
Paketprotokollierung
Alarme in Textform bilden zwar einen hervorragenden Ausgangspunkt, aber im Laufe
der Untersuchung wollen Sie wahrscheinlich auch die Pakete inspizieren, die den Alarm
ausgelöst haben. Wenn Sie wie in Kapitel 5 beschrieben vollständige Paketdaten (FCP)
erfassen, dann werden Sie sicherlich dort nachschauen. Wenn nicht, können Sie Snort und
Suricata so einrichten, dass sie die Pakete, die zu einem Alarm führen, im PCAP-Format
festhalten. In Abbildung 9.16 sehen diesen Vorgang für das Paket, das unseren Beispiel­
alarm verursacht hat.
Abbildung 9.16: Ein Paket, das mit Regel SID 2100498 übereinstimmt
Unified2
Das am häufigsten verwendete Protokollformat in Unternehmensumgebungen ist Unified2. Es handelt sich dabei um ein Binärformat, das sowohl die Alarmdaten als auch die
zugehörigen Paketdaten festhalten kann. Wenn Sie versuchen sollten, eine solche Datei
manuell zu untersuchen, werden Sie jedoch feststellen, dass sie nicht lesbar ist. Unified2Ausgaben sind nicht dazu gedacht, von Menschen gelesen oder von Befehlszeilenwerkzeugen untersucht zu werden. Stattdessen werden sie von Tools wie Barnyard2 oder Pigsty
interpretiert, die wiederum die Alarmdaten in eine Datenbank stellen, z. B. MySQL oder
PostgreSQL. Snort enthält auch das Programm u2spewfoo, das in der Lage ist, das Format
Unified2 zu lesen und den Inhalt an der Befehlszeile auszugeben.
Barnyard2 gilt seit Jahren als Standardwerkzeug zum Speichern von Unified2-Alarmen in
Datenbanken, und es funktioniert gut. Darüber hinaus unterstützt es andere Ausgabemodi.
Mehr über Barnyard2 erfahren Sie auf https://github.com/firnsy/barnyard2.
9.5 Snort und Suricata konfigurieren 287
Ein neueres Werkzeug ist Pigsty, entwickelt von Threat Stack, von dem auch das weiter hinten in diesem Kapitel besprochene Tool Snorby stammt. Pigsty soll die gleichen Aufgaben
auszuführen wie Barnyard2, dabei aber mehr Erweiterungsmöglichkeiten bieten. Um die
Vielseitigkeit der Ausgabeoptionen für Alarmdaten von Snort und Suricata noch zu erweitern, erlaubt Pigsty Ihnen, eigene Ausgabe-Plug-Ins zu schreiben. Neben Ausgabe-Plug-Ins
für Datenbanken unterstützt diese Software auch andere Ausgabemethoden, z. B. Web­
sockets, Sguild, IRC und REST. Mehr erfahren Sie auf https://github.com/threatstack/pigsty.
Wenn Sie mehr darüber wissen wollen, wie Sie die Alarmausgabe einrichten, schlagen Sie in
den entsprechenden Abschnitten der Onlinedokumentation von Snort oder Suricata nach.
9.5.4 Snort-Präprozessoren
Bei Suricata ist die Mehrzahl der Funktionen in die Kernarchitektur eingebaut. Dagegen
stellt Snort viele Funktionen in einzelnen Präprozessoren bereit. Wie wir bereits im Überblick über Snort gesehen haben, gibt es zwei Arten von Präprozessoren: Die einen dienen
dazu, die Daten vor der Verarbeitung durch die Erkennungengine zu normalisieren, die anderen bieten erweiterte Möglichkeiten für die von dieser Engine verwendeten Regeln. Beide
Arten von Präprozessoren aber werden in der Datei snort.conf konfiguriert. Dazu müssen
Sie jeweils das Schlüsselwort preprocessor gefolgt vom Namen des Präprozessors und den
zugehörigen Optionen angeben. Bei einigen Präprozessoren lassen sich nur wenige Optionen einstellen, beispielsweise beim Präprozessor für die Portscanerkennung:
# Portscan detection. For more information, see README.sfportscan
# preprocessor sfportscan: proto { all } memcap { 10000000 } sense_level
{ low }
Andere dagegen haben mehrere Optionen, beispielsweise der Präprozessor zur Erkennung
von SSH-Anomalien:
# SSH anomaly detection. For more information, see README.ssh
preprocessor ssh: server_ports { 22 } \
autodetect \
max_client_bytes 19600 \
max_encrypted_packets 20 \
max_server_version_len 100 \
enable_respoverflow enable_ssh1crc32 \
enable_srvoverflow enable_protomismatch
Die Präprozessoren werden in der Reihenfolge ausgeführt, in der sie in der Konfigurationsdatei aufgeführt sind. Daher werden sie nach den Netzwerkschichten angeordnet, mit denen
sie verknüpft sind. Als Erstes kommen Präprozessoren der Netzwerkschicht wie Frag3, der
sich mit dem Zusammenbau von IP-Fragmenten beschäftigt. Darauf folgen Präprozessoren
288 9 Signaturgestützte Erkennung mit Snort und Suricata
für Transportschichtprotokolle wie Stream5, der TCP-Streams wieder zusammensetzt, und
anschließend Präprozessoren der Anwendungsschicht wie die Anomaliedetektoren für SSH,
HTTP und SMTP. Diese Reihenfolge ist wichtig, da die Präprozessoren der Anwendungsschicht keine Daten verarbeiten können, die fragmentiert sind, nicht in der richtigen Reihenfolge vorliegen oder sich in einem sonstigen unerwarteten Zustand befinden.
Bei Ihren ersten Schritten mit Snort werden Sie nicht allzu viele Präprozessoren nutzen,
und möglicherweise ist Ihnen nicht einmal bewusst, welche Sie tatsächlich einsetzen. Allerdings sollten Sie sich auf jeden Fall die Zeit nehmen, alle in snorf.conf aufgeführten Präprozessoren zu untersuchen und die zugehörigen Readme-Dateien zu lesen. Es kann sonst
sein, dass Sie versuchen, komplizierte Regeln zu schreiben, die bei der Verwendung eines
Präprozessors viel einfacher sein könnten. Es gibt unter anderem folgende Präprozessoren:
•• Reputation: Wird zur reputationsgestützten Erkennung und zum Blockieren der Kommunikation mit bestimmten IP-Adressen verwendet (siehe Kapitel 8).
•• ARPSpoof: Kann ARP-Spoofing erkennen.
•• SFportscan: Erkennt mögliche Aufklärungsscans.
•• Frag3: Defragmentiert IP-Pakete und hilft dabei, ein Unterlaufen des IDS zu verhindern.
•• Stream5: Ermöglicht die Statusverfolgung von TCP-Verbindungen und das Aufstellen
von statusbehafteten Regeln.
•• HTTP_Inspect: Normalisiert HTTP-Datenverkehr, sodass die Erkennungsengine ihn
ordnungsgemäß untersuchen kann. Dieser Präprozessor stellt verschiedene Direktiven
bereit, die in Snort-Regeln angewendet werden können.
Mehr über die Präprozessoren von Snort erfahren Sie im Abschnitt »Preprocessors« des
Snort Users Guide. Sie können sich auch die Readme-Dateien der einzelnen Präprozessoren
in der Dokumentation zu Snort ansehen.
9.5.5 Zusätzliche Befehlszeilenargumente für den NIDS-Modus
Die meisten Optionen werden in snort.conf bzw. suricata.yaml festgelegt. Optionen, die als
Befehlszeilenargumente angegeben werden, haben jedoch Priorität gegenüber den Angaben in den Konfigurationsdateien. Es ist üblich, Snort und Suricata unter Angabe einiger
dieser Argumente auszuführen.
Wenn Sie Security Onion verwenden, können Sie sich die verwendeten Befehlszeilenargumente ansehen, indem Sie den Prozess der IDS-Engine anzeigen lassen. Das Beispiel aus
Abb. 9.17 zeigt dies für Snort.
Abbildung 9.17: Snort mit Befehlszeilenargumenten
9.5 Snort und Suricata konfigurieren 289
Für Snort können Sie unter anderem die folgenden häufig genutzten Argumente verwenden:
•• -A<Modus>: Gibt den Modus für Alarme in Textform an. Mögliche Optionen sind
fast, full, unsock, console, cmg und none.
•• -c<Datei>: Gibt den Pfad zur Konfigurationsdatei snort.conf für den NIDS-Modus an.
•• -D: Führt Snort als Daemon aus (im Hintergrund).
•• -F<Datei>: Liest Berkeley-Paketfilter aus einer Datei. BPFs werden ausführlich in Kapitel 13 behandelt.
•• -g<Gruppe>: Gibt die Gruppe an, in der Snort nach der Initialisierung ausgeführt wird.
Das ermöglicht es, nach der Initialisierung Root-Rechte von Snort zu entfernen.
•• -i<Schnittstelle>: Gibt die Überwachungsschnittstelle an.
•• -l<Verzeichnis>: Gibt ein Ausgabeverzeichnis für Alarme in Textform an.
•• -L<Verzeichnis>: Gibt ein Ausgabeverzeichnis für Alarme im Binärformat an.
•• -m<Berechtigung>: Sorgt dafür, dass neue Dateien mit den angegebenen umask-Berechtigungen erstellt werden.
•• -u<Benutzer>: Gibt den Benutzer an, unter dessen Konto Snort nach der Initialisierung
ausgeführt werden soll. Das ermöglicht es, nach der Initialisierung Root-Rechte von
Snort zu entfernen.
•• -U: Ändert die Zeitstempel für alle Protokolle und Alarme auf UTC.
•• -T: Dient zum Testen der Konfigurationsdatei.
•• --perfmon-file<Datei>: Gibt die Datei an, die der Präprozessor perfmon zur Verfolgung der Snort-Statistiken verwenden soll.
In Abb. 9.18 können Sie sehen, wie Suricata in Security Onion mit mehreren Befehlszeilenargumenten ausgeführt wird.
Abbildung 9.18: Suricata mit Befehlszeilenargumenten
Für Suricata können Sie unter anderem die folgenden häufig genutzten Argumente verwenden:
•• -c<Datei>: Gibt den Pfad zur Konfigurationsdatei suricata.yaml an.
•• -D: Führt Suricata als Daemon aus (im Hintergrund).
•• --g<Gruppe>: Gibt die Gruppe an, in der Suricata nach der Initialisierung ausgeführt
wird. Das ermöglicht es, nach der Initialisierung Root-Rechte von Suricata zu entfernen.
•• -F<Datei>: Liest Berkeley-Paketfilter aus einer Datei. BPFs werden ausführlich in Kapitel 13 behandelt.
290 9 Signaturgestützte Erkennung mit Snort und Suricata
••
••
••
••
••
-i<Schnittstelle>: Gibt die Überwachungsschnittstelle an.
-l<Verzeichnis>: Gibt das Standardprotokollverzeichnis an.
-r<PCAP-Datei>: Untersucht eine PCAP-Datei im Offlinemodus.
--runmode<Modus-ID>: Legt fest, in welchem Betriebsmodus Suricata initialisiert wird.
-s: Hiermit können Sie manuell eine Datei mit IDS-Signaturen angeben, die neben
den in suricata.yaml aufgeführten Dateien verwendet werden soll.
•• -T: Dient zum Testen der Konfigurationsdatei.
•• --user<Benutzer>: Gibt den Benutzer an, unter dessen Konto Suricata nach der Initialisierung ausgeführt werden soll. Das ermöglicht es, nach der Initialisierung RootRechte von Suricata zu entfernen.
Zur Initialisierung von Snort und Suricata stehen weitere Befehlszeilenargumente zur Verfügung. Eine vollständige Liste dieser Optionen finden Sie in den jeweiligen man-Seiten.
Um sie aufzurufen, geben Sie an der Befehlszeile man snort bzw. man suricata ein.
9.6
IDS-Regeln
Wir haben uns bereits angesehen, wie Sie Snort und Suricata mit Regeln aus öffentlichen
Quellen versorgen und wie Sie diese Regeln auf dem neuesten Stand halten. Das ist zwar
alles sehr wichtig, aber das tägliche Brot von Analytikern, die mit diesen IDS arbeiten,
besteht darin, selbst neue Regeln zu erstellen und vorhandene Regeln zu ändern, um sie
zu optimieren. In diesem Abschnitt erfahren Sie, wie Regeln aufgebaut sind und welche
gängigen Regeloptionen es gibt. Außerdem gehen wir die Erstellung von Regeln in der
Praxis Schritt für Schritt durch.
Der Großteil des Stoffes in diesem Abschnitt gilt gleichermaßen für Snort wie für Suricata,
da beide dieselbe grundlegende Syntax verwenden. Wenn irgendeine Regeloption für eine
dieser beiden Technologien nicht verwendbar ist, weise ich jeweils ausdrücklich darauf
hin.
9.6.1 Aufbau von Regeln
Die von Snort und Suricata verwendete Regelsyntax ist äußerst flexibel, aber trotzdem
müssen Sie sich an einige Vereinbarungen halten. Das folgende Beispiel zeigt eine sehr
einfache Regel:
alert tcp $EXTERNAL_NET 80 ->$HOME_NET any (msg:"Users Downloading Evil);
content:"evil"; sid:55555555; rev:1;)
9.6 IDS-Regeln 291
Diese Regel löst einen Alarm aus, wenn ein Benutzer in Ihrem Netzwerk Daten von einem
Webserver herunterlädt, die das Wort »evil« enthalten. Natürlich ist es in Wirklichkeit
nicht so einfach, den Download von schädlichen Dingen aus dem Internet zu erkennen!
Die Regel besteht aus zwei deutlich verschiedenen Teilen, nämlich dem Regelkopf (Header) und den Regeloptionen. Der Header besteht aus allem, was vor den Klammern
steht, während es sich bei den Optionen um den gesamten Inhalt der Klammern handeln. Abb. 9.19 macht diesen Aufbau deutlich.
alert tcp $EXTERNAL_NET 80 -> $HOME_NET any (content:”evil”; sid:55555555; rev:1;)
Regelheader
Regelop€onen
Abbildung 9.19: Grundlegender Aufbau einer Regel
Regelheader
Der Header ist der erste Teil einer Regel und muss auf jeden Fall vorhanden sein. Er gibt
an, »wer« für das Datenverkehrsmuster verantwortlich ist, nach dem gesucht wird. Alles,
was im Regelheader definiert ist, lässt sich im Paketheader wiederfinden. Abb. 9.20 zeigt
den Aufbau des Regelheaders.
Quell-/
Zielports
Protokoll
Quell-/
Zielhosts
alert tcp $EXTERNAL_NET 80 -> $HOME_NET any
Akon
Quell-/
Zielhosts
Verkehrsrichtung
Quell-/
Zielports
Abbildung 9.20: Aufbau eines IDS-Regelheaders
Regelheader enthalten immer die folgenden Teile: Aktion, Protokoll, Quell- und Zielhosts,
Quell- und Zielports und Richtung des Datenverkehrs.
Aktion
Der erste Teil einer jeden Regel nennt die Aktion, die das IDS durchführen soll, wenn ein
Alarm ausgelöst wird. Hierfür gibt es drei mögliche Optionen:
•• Alert: Weist die IDS-Engine an, die Übereinstimmung mit der Regel sowie die damit
verbundenen Paketdaten zu protokollieren. Dies ist die übliche Regelaktion.
•• Log: Weist die IDS-Engine an, nur die Übereinstimmung mit der Regel, nicht aber die
damit verbundenen Paketdaten zu protokollieren.
•• Pass: Weist die IDS-Engine an, das Paket nicht weiter zu verarbeiten.
292 9 Signaturgestützte Erkennung mit Snort und Suricata
Protokoll
Dieses Feld teilt der IDS-Engine mit, auf welches Protokoll die Regel angewendet werden
soll. Mögliche Optionen sind tcp, idp, icmp, ip und any. Es kann allerdings immer nur eine
dieser Optionen angegeben werden. Wenn Sie also eine Regel schreiben wollen, die sowohl
für TCP- als auch für UDP-Datenverkehr gelten soll, dann müssen Sie im Regelheader die
Protokolloption ip verwenden. Aus Leistungsgründen sollten Sie das Protokoll, in dem
das gesuchte Muster auftritt, möglichst spezifisch angeben. In der Beispielregel sind wir an
HTTP-Datenverkehr interessiert. Da er auf dem Protokoll TCP aufsitzt, geben wir tcp an.
Quell- und Zielhosts
In einer Regel müssen Sie die IP-Adressen der Quell- und Zielhosts für den Datenverkehr
nennen, in dem das gesuchte Muster vorkommen soll. Diese Angabe kann auf verschiedene Weise erfolgen, z. B. in Form von Listen oder CIDR-Bereichen, wie wir es schon bei
unserer früheren Erörterung der Konfiguration von Snort und Suricata gesehen haben.
In unserer Beispielregel haben wir die Variablen $HOME_NET und $EXTERNAL_NET verwendet.
Lässt sich die Regel nicht auf eine bestimmte Gruppe von Hosts einschränken, geben Sie
das Schlüsselwort any an, um nach Übereinstimmungen in Datenverkehr von bzw. zu jedem beliebigen Host zu suchen.
Quell- und Zielports
Neben den Hosts müssen wir auch die Layer-4-Ports angeben, über die der gesuchte
Datenverkehr läuft. Wie bereits weiter vorn in diesem Kapitel erklärt, können Sie dabei
einzelne Ports, Listen oder Bereiche angeben. Wenn es um Datenverkehr über beliebige
Ports geht, verwenden Sie das Schlüsselwort any. In der Beispielregel haben wir Port 80 im
Zusammenhang mit der Netzwerkvariable $EXTERNAL_NET verwendet und any im Zusammenhang mit $HOST_NET.
Verkehrsrichtung
Die letzte Angabe im Header nennt die Richtung des Datenverkehrs. Dafür gibt es nur
zwei Möglichkeiten:
•• ->: Unidirektionaler Datenverkehr von der Quelle zum Ziel
•• <>: Bidirektionaler Datenverkehr
Beim Schreiben von Regeln müssen Sie zunächst überlegen, ob die Richtung des Datenverkehrs eine Rolle spielt. Wenn das nicht der Fall ist, ist es auch egal, ob Sie erst Quellhost
und Quellport und dahinter Zielhost und Zielport angeben oder umgekehrt. Kommt es
dagegen auf die Richtung an, dann müssen Quellhost und Quellport an erster Stelle stehen.
In dem Header unserer Beispielregel sind wir daran interessiert, ob Benutzer etwas
Schädliches von einem externen Webserver herunterladen. Die potenziellen Quellen der
Schadpakete sind daher externe Webserver, und das Ziel ist einer unserer internen Hosts.
Daher werden zuerst die externen Hosts und Ports aufgeführt ($EXTERNAL_NET 80) und
dann hinter dem Richtungsanzeiger (->) die internen Hosts und Ports ($HOME_NET any).
9.6 IDS-Regeln 293
Regeloptionen
Im Regelheader geht es um das »Wer«, in den Regeloptionen dagegen um das »Was«.
Sie teilen der IDS-Engine genau mit, wonach sie in den untersuchten Paketen Ausschau
halten soll und wie sie es finden kann. Welche Optionen Sie angeben, ist von Fall zu Fall
verschieden, aber immer müssen Sie den kompletten Optionsabschnitt in Klammern setzen. Innerhalb dieser Klammern werden die einzelnen Optionen in der folgenden Form
angegeben:
<Option>: <Optionswerte>;
Optionsname und Werte werden durch einen Doppelpunkt getrennt, und die Optionswerte werden mit einem Semikolon abgeschlossen. Optionswerte, die Leerzeichen enthalten, müssen in Anführungszeichen stehen.
Manche Optionen haben keine Werte, sondern werden einfach wie folgt angegeben:
<Option>;
Beachten Sie, dass hier ein Semikolon hinter dem Optionsnamen steht. Wenn Sie einen
der erforderlichen Doppelpunkte oder ein Semikolon vergessen, kann die IDS-Engine die
Regel nicht verarbeiten.
Vorsicht
Vergessen Sie nicht das Semikolon hinter der letzten Option im Optionsabschnitt! Dieser Fehler ist schnell gemacht und lässt sich später nur schwer finden.
Sehen wir uns nun einige gebräuchliche Regeloptionen an.
Optionen für Informationen über das Ereignis
Diese Optionen geben Kontextinformationen zu einer Regel. Je ausführlicher die Informationen, die Sie dabei angeben, umso besser können die Analytiker die Daten im Zusammenhang mit dem betreffenden Alarm untersuchen. Unter anderem stehen folgende
Optionen dieser Art zur Verfügung:
Nachricht (msg): Eine kurze Beschreibung der Regel in Textform. Dies wird gewöhnlich
als der »Name« der Regel angesehen und ist das, was Analytiker bei der Überprüfung der
Alarme als Erstes sehen. Sie sollten diesen Text so aussagekräftig wie möglich gestalten.
Die folgenden Beispiele geben Ihnen einige Fingerzeige:
•• ET POLICY: Ausgehendes unverschlüsseltes Base64-HTTP-Passwort für einfache
Authentifizierung erkannt
•• OS-WINDOWS SMB NTLM: Versuchte Einrichtung einer NULL-Sitzung
•• EXPLOIT KIT: Jar-Datei mit Explooit-Kit Blackholev2 heruntergeladen
294 9 Signaturgestützte Erkennung mit Snort und Suricata
Signatur-ID (sid): Hiermit werden die Regeln eindeutig bezeichnet. Jede Regel muss über
eine eindeutige SID verfügen. SIDs sind einfache Zahlen, wobei jedoch einige Bereiche
reserviert sind:
•• 0–1.000.000: Reserviert für Sourcefire VRT
•• 2.000.000–2.999.999: Verwendet von Emerging Threats
•• 3.000.000+: Zur öffentlichen Benutzung
Um Konflikte zu vermeiden, sollten Sie daher SIDs über 3.000.000 verwenden und eine
Liste der auf Ihren Sensoren verwendeten SIDs führen.
Revision (rev): Mit der Revisionsoption kennzeichnen Sie Änderungen an Regeln. Wenn
Sie eine Regel neu erstellen, weisen Sie ihr rev:1 zu, um anzugeben, dass es sich um die
erste Version handelt. Bei einer Änderung der Regel weisen Sie keine neue SID zu, sondern
erhöhen lediglich die Revisionsnummer. Wenn Snort oder Suricata zwei Regeln mit identischer SID finden, wenden sie diejenige mit der höheren Revisionsnummer an.
Verweis (reference): Mit dem Schlüsselwort reference können Sie externe Quellen für zusätzliche Kontextinformationen angeben. Gewöhnlich wird dabei einfach ein URL genannt:
alert tcp $HOME_NET any ->$EXTERNAL_NET $HTTP_PORTS (msg:"ET CURRENT
_EVENTS FakeAlert/FraudPack/FakeAV/Guzz/Dload/Vobfus/ZPack HTTP Post
2"; flow:established,to_server; content:"POST"; http_method; content:"/
perce/"; nocase; http_uri; content:"/qwerce.gif"; nocase;
http_uri; content:"data="; nocase; reference:url,threatinfo.trendmicro.
com/vinfo/virusencyclo/default5.asp?VName=TROJ_AGENT.
GUZZ&VSect=T; reference:url,www.threatexpert.com/threats/trojanfraudpacksd6.html; reference:url,vil.nai.com/vil/content/v_157489.
htm; reference:url,doc.emergingthreats.net/2010235; classtype:trojanactivity; sid:2010235; rev:6;)
Diese Regel dient dazu, verschiedene Arten von Malware zu erkennen, die ähnliche HTTPPOST-Anforderungen an einen Remoteserver stellen. Sie enthält vier Verweise auf weitere
Informationsquellen:
•• reference:url,threatinfo.trendmicro.com/vinfo/virusencyclo/default5.
asp?VName=TROJ_AGENT.GUZZ&VSect=T;
•• reference:url,www.threatexpert.com/threats/trojan-fraudpack-sd6.html;
•• reference:url,vil.nai.com/vil/content/v_157489.htm;
•• reference:url,doc.emergingthreats.net/2010235;
Verweise werden in folgendem Format angegeben:
reference: <Verweistyp>,<Verweis>
9.6 IDS-Regeln 295
Die verschiedenen Verweistypen werden in der Datei reference.config definiert. Sie wird
sowohl in Snort als auch in Suricata verwendet, und in beiden Produkten können Sie den
Namen und den Speicherort dieser Datei ändern. In Security Onion befindet sie sich in
­/etc/nsm/<Sensorname>/reference.config. Ein Beispiel dieser Datei sehen Sie in Abb. 9.21.
Die Verweistypen definieren Sie dort mit der folgenden Syntax:
config reference: <Verweistyp> <Verweispräfix>
Der Verweistyp ist ein einzelnes Wort, das Sie für diese Art von Verweis verwenden möchten. Mit dem Präfix können Sie einen URL-Wert zuweisen, der dem in der Regel angegebenen Verweis vorangestellt wird. Das hilft dabei, Regeln einheitlich zu gestalten, und bietet zusätzliche Möglichkeiten für grafische Front-Ends: Analytiker können dann einfach
auf den Verweis klicken und werden direkt zum Ziel umgeleitet.
Betrachten Sie als Beispiel folgenden URL-Verweis:
reference:url,vil.nai.com/vil/content/v_157489.htm;
Der vollständige Verweis lautet:
http://url,vil.nai.com/vil/content/v_157489.htm
Abbildung 9.21: Ein Beispiel der Datei reference.config
296 9 Signaturgestützte Erkennung mit Snort und Suricata
Mit anderen Verweistypen können Sie diese Funktion sogar noch nutzbringender anwenden. Betrachten Sie beispielsweise die folgende Regel zur Entdeckung eines versuchten
NTPDX-Überlaufs:
alert udp $EXTERNAL_NET any ->$HOME_NET 123 (msg:"GPL EXPLOIT ntpdx
overflow attempt"; dsize:>128; reference:bugtraq,2540; reference:
cve,2001-0414; classtype:attempted-admin; sid:2100312; rev:7;)
Hier werden zwei Verweise angegeben, bugtraq und cve. In der Datei reference.config aus
Abb. 9.21 können Sie erkennen, dass diese beiden Typen besondere URL-Präfixe verwenden, die ein rasches Nachschlagen der Daten erlauben:
config reference: bugtraq http://www.securityfocus.com/bid/
config reference: cve http://cve.mitre.org/cgi-bin/cvename.cgi?name=
Mit dieser Konfiguration ergeben sich für SID 2100312 letztendlich folgende Verweise:
•• http://www.securityfocus.com/bid/2540
•• http://cve.mitre.org/cgi-bin/cvename.cgi?name=2001-0414
Die Möglichkeit, nicht nur den Typ und den Wert des Verweises anzugeben, kann zu einer
starken Verkürzung der Regel beitragen, sodass sie sich leichter bearbeiten und verwalten
lässt. Mit selbst gestalteten Verweistypen gewinnen Sie sehr viel Flexibilität für die Aufnahme von Kontextinformationen in Ihre Regeln.
Priorität (priority): Mit dieser Option können Sie explizit eine Priorität für die Regel
angeben, was Analytikern dabei hilft, ihre Zeit bei der Untersuchung von Alarmen besser einzuteilen. Als Werte sind beliebige Integerzahlen möglich, allerdings werden in den
meisten öffentlichen Regelsätzen nur die Werte 1 bis 10 verwendet, wobei 1 für die höchste
und 10 für die niedrigste Priorität steht. Für diese Option verwenden Sie folgende Syntax:
priority:<Wert>;
Wenn Sie die Regel einer Klasse zuordnen, erhält sie normalerweise die in classification.
config angegebene Standardpriorität. Haben Sie allerdings mit priority ausdrücklich eine
Priorität vergeben, verwendet Snort diesen Wert.
Klassifizierung (classtype): Mit der Klassifizierungsoption können Sie Regeln auf der
Grundlage der Art von Aktivität, die erkannt werden soll, in Kategorien einteilen. Die
folgende Regel zeigt, wie Sie diese Option einsetzen:
9.6 IDS-Regeln 297
alert tcp $HOME_NET any ->$EXTERNAL_NET $HTTP_PORTS (msg:"ET CURRENT_
EVENTS Potential Fast Flux Rogue Antivirus (Setup_245.exe)"; flow:
established,to_server; content:"GET"; nocase; http_method; content:"/
Setup_"; nocase; http_uri; content:".exe"; nocase; http_uri;
pcre:"/\/Setup_\d+\.exe$/Ui"; reference:url,www.malwareurl.com/list
ing.php?domain=antivirus-live21.com; classtype:trojan-activity;
sid:2012392; rev:3;)
Die Klassifizierung geben Sie mit der folgenden Syntax an:
classtype:<Klassenname>;
Sowohl Snort als auch Suricata beziehen die Klassennamen aus der Datei classification.
config. Name und Pfad dieser Datei lassen sich in snort.conf und suricata.yaml einstellen.
In Security Onion befindet sie sich in /etc/nsm/<Sensorname>/classification.org. Einträge
in dieser Datei müssen das folgende Format aufweisen:
config classification: <Klassenname>,<Beschreibung>,<Standardpriorität>
Der Klassenname ist die Bezeichnung, die auch in der Regel verwendet wird. Sie sollte
kurz sein und darf keine Leerzeichen enthalten. Die Beschreibung dagegen kann länger
ausfallen. Sie dient dazu, nähere Angaben zu der Klasse zu machen. Die Standardpriorität
gilt für alle Regeln der Klasse.
Im Lieferumfang sowohl von Snort als auch von Suricata sind bereits einige Klassen enthalten. Wenn Sie Regeln von öffentlichen Quellen wie Sourcefire VRT oder Emerging
­Threats herunterladen, ist darin auch eine classification.config-Datei mit allen in den Regeln verwendeten Klassen enthalten. Abb. 9.22 zeigt als Beispiel die Datei classification.
config von Security Onion.
Im Allgemeinen sollten Sie alle Regeln in irgendeine Form von Klassen einteilen. Wenn Sie
eine Methode einsetzen, um sich stets über neu erstellte und veränderte Regeln auf dem
Laufenden zu halten, haben Sie wahrscheinlich schon irgendeine Form von Klassifizierung aufgestellt, die Sie auf Ihre IDS-Regeln anwenden können. Sollten Sie dagegen erst
mit dem Aufbau einer signaturgestützten Erkennung beginnen, bieten die in Snort und
Suricata vorhandenen Klassentypen einen guten Ausgangspunkt.
298 9 Signaturgestützte Erkennung mit Snort und Suricata
Abbildung 9.22: Ein Beispiel der Datei classification.config
Inhaltsuntersuchung
Die einfachste Maßnahme, die Sie im Optionsabschnitt einer IDS-Regel angeben können,
ist eine einfache Suche im Inhalt. Mit dem Schlüsselwort content können Sie die IDSEngine anweisen, den Inhalt der Anwendungsschicht (die Payload) nach Paketen mit den
angegebenen Daten zu durchsuchen. In Kapitel 13 werden wir uns ausführlicher damit
beschäftigen, wie Sie der Engine mitteilen, wo genau die Payload im Paket beginnt. Die
gesuchten Daten können als Text, als Binärdaten im Hexadezimalformat oder als eine
Mischung aus beidem angegeben werden.
Nehmen wir beispielsweise an, Sie wollen den Inhalt eines Pakets nach dem String »evilliveshere« durchsuchen. Dazu geben Sie folgende Option an:
content:"evilliveshere";
9.6 IDS-Regeln 299
Sie können in einer Regel auch mehrere Suchbegriffe angeben. Wie praktisch das ist, werden Sie noch sehen, wenn wir uns weiter hinten mit Inhaltsmodifikatoren und der Suche
nach Inhalten an bestimmten Stellen beschäftigen.
content:"evillives"; content:"here";
Mit dem Ausrufungszeichen können Sie auch Suchbegriffe ausschließen. Beispielsweise
können Sie die folgende Option bei der Erfassung von Anmeldeversuchen einsetzen, um
alle außer denen für das Benutzerkonto anonymous zu berücksichtigen:
content:"USER"; content:!"anonymous";
Sie können auch nach Binärdaten suchen, indem Sie sie als Hexadezimalzeichen in Betragsstrichen ausdrücken. Um etwa Paketdaten auf das Vorhandensein von JPEG-Dateien
zu überprüfen, können wir wie folgt nach dem Vorkommen der »magischen Zahlen« solcher Dateien suchen:
content:"|FF D8|"
Bei der Inhaltssuche lassen sich String- und Binärdaten auch kombinieren. Im folgenden Beispiel suchen wir nach drei Doppelpunkten, gefolgt vom Text »evilishere« und drei
NULL-Bytes:
content:"|3A 3A 3A|evilliveshere|00 00 00|";
Bei Inhaltsvergleichen wird stets auf die Groß- und Kleinschreibung geachtet. Inhalte werden an beliebigen Stellen im Paket gefunden.
Vorsicht
Wenn Sie Inhaltsregeln aufstellen, müssen Sie reservierte Zeichen wie das Semikolon, den umgekehrten Schrägstrich (Backslash) und Anführungszeichen maskieren
oder in Hexadezimalform angeben.
Modifikatoren für die Inhaltsuntersuchung
Es gibt verschiedene Modifikatoren, die Sie hinter dem Suchbegriff angeben können, um
zu steuern, wie die IDS-Engine nach Übereinstimmungen in den Netzwerkdaten forscht.
Damit können Sie die Genauigkeit von Inhaltssuchen erhöhen und auch die Leistung des
Erkennungsprozesses steigern, da Sie der Engine mitteilen, an welcher Stelle sie suchen
soll, anstatt sie die komplette Payload sämtlicher Pakete durchforsten zu lassen.
300 9 Signaturgestützte Erkennung mit Snort und Suricata
Im Folgenden sehen wir uns einige wichtige Modifikatoren an.
Nocase: Normalerweise wird bei der Inhaltssuche zwischen Groß- und Kleinschreibung
unterschieden, sodass beispielsweise kein Alarm ausgelöst wird, wenn Sie nach dem Text
root suchen, das Paket aber den String ROOT enthält. Um diese Unterscheidung aufzuheben, geben Sie wie folgt den Modifikator nocase an:
content:"root"; nocase;
Dadurch wird das Wort »root« in jeglicher Schreibweise gefunden.
Offset und depth: Mit dem Modifikator offset wird an einer bestimmten Stelle in der
Payload des Pakets gesucht, wobei diese Position vom ersten Byte der Payload an gezählt
wird. Beachten Sie dabei, dass dieses erste Byte nicht als Byte 1, sondern als Byte 0 gezählt
wird. Bei der Angabe offset:0 untersucht die Erkennungsengine daher die Inhalte am
Anfang der Payload, bei offset:1 die Inhalte ab dem zweiten Byte.
Betrachten Sie als Beispiel das folgende FTP-Paket:
14:51:44.824713 IP 172.16.16.139.57517>67.205.2.30.21: Flags [P.],
seq 1:15, ack 27, win 16421, length 14
0x0000: 4510 0036 efe4 4000 4006 4847 ac10 108b E..6..@.@.HG....
0x0010: 43cd 021e e0ad 0015 0bcb 6f30 fcb2 e53c C.........o0. . .<
0x0020: 5018 4025 2efb 0000 5553 4552 2073 616e P.@%....USER.san
0x0030: 6465 7273 0d0a ders..
Wenn wir eine Regel schreiben wollen, um jeden Versuch eines bestimmten Benutzers zu
erkennen, sich mit seinem Benutzernamen an diesem externen FTP-Server anzuwenden,
können wir zunächst einmal Folgendes schreiben:
alert tcp $HOME_NET any ->67.205.2.30 21 (msg:"Suspicious FTP Login";
content:"sanders"; sid:5000000; rev:1;)
Diese Regel löst bei dem gegebenen Paket sicherlich einen Alarm aus, verursacht aber auch
viele Fehlalarme. Beispielsweise gibt es auch dann Alarm, wenn sich jemand mit einem
anderen Konto an dem FTP-Server anmeldet und dann zu einem Ordner namens sanders
wechselt.
Um die Suche in dieser Regel einzuengen, geben wir die Position an, ab der der Benutzername in der Payload des Pakets auftauchen soll. Das erste Byte der Payload ist in unserem
Fall 0x55, wohingegen das erste Zeichen des Benutzernamens erst beim Offset 5 (0x73)
auftritt. (Nicht vergessen, wir beginnen beim Zählen mit null!) Damit können wir die Regel so umschreiben, dass erst ab dieser Position nach dem Benutzernamen gesucht wird:
9.6 IDS-Regeln 301
alert tcp $HOME_NET any ->67.205.2.30 21 (msg:"Suspicious FTP Login"
content:"sanders"; offset:5; sid:5000000; rev:1;)
Bei dieser neuen Version gibt es nicht nur deutlich weniger Fehlalarme, sie wird auch
schneller ausgeführt, da die IDS-Engine weniger Bytes untersuchen muss.
Mit dem Modifikator offset können Sie der IDS-Engine nur mitteilen, wo sie mit der
Suche nach einem bestimmten Inhalte beginnen soll. Um anzugeben, wo die Suche zu
enden hat, verwenden Sie den Modifikator depth. Die Endposition, die Sie dabei angeben,
wird ab dem ersten Payloadbyte gezählt, das untersucht wird. Wenn Sie depth ohne offset
verwenden, erfolgt die Zählung ab dem ersten Byte der Payload, anderenfalls ab der in
offset genannten Position.
Damit können wir unsere Snort-Regel für die FTP-Anmeldung noch effizienter gestalten.
In der folgenden Version schränken wir die Tiefe auf sieben Bytes ein, also die Länge des
Strings, den wir finden wollen. Mit den Modifikatoren offset und depth geben wir damit
genau den Bereich an, in dem der gesuchte Text stehen muss.
alert tcp $HOME_NET any ->67.205.2.30 21 (msg:"Suspicious FTP Login"
content:"sanders"; offset:5; depth:7; sid:5000000; rev:1;)
Distance und within: Wie wir bereits gesehen haben, können Regeln auch mehrere Inhaltssuchen enthalten. Dabei ist es natürlich äußerst praktisch, angeben zu können, in
welcher Position die gesuchten Inhalte relativ zueinander stehen sollen. Eine Möglichkeit
dazu bietet der Modifikator distance, mit dem Sie die Entfernung vom Ende der ersten
Übereinstimmung bis zum Beginn des Bereichs angeben können, in dem nach dem zweiten Inhalt gesucht werden soll. Ein Beispiel dafür finden Sie in der folgenden Regel:
alert tcp $HOME_NET 1024: ->$EXTERNAL_NET 1024: (msg:"ET P2P Ares Server
Connection"; flow:established,to_server; dsize:<70;
content:"r|be|bloop|00|dV"; content:"Ares|00 0a|";
distance:16; reference:url,aresgalaxy.sourceforge.net;
reference:url,doc.emergingthreats.net/bin/view/Main/2008591; classtype:policyviolation; sid:2008591; rev:3;)
Mit dieser Regel werden Aktivitäten im Zusammenhang mit dem Filesharing-Netzwerk
Ares aufgedeckt.
1. content:"r|be|bloop|00|dV";
Findet den gesuchten Inhalt an beliebigen Stellen in der Payload.
2. content:"Ares|00 0a|"; distance:16;
Sucht mindestens 16 Byte hinter der vorherigen Übereinstimmung nach dem angegebenen Wert.
302 9 Signaturgestützte Erkennung mit Snort und Suricata
Diese Regel löst bei der Untersuchung der folgenden Payload einen Alarm aus:
0x0000: 72be 626c 6f6f 7000 6456 0000 0000 0000 r.bloop.dV.......
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 .................
0x0020: 4172 6573 000a Ares..
In der folgenden Payload dagegen wird keine Übereinstimmung gefunden, da der zweite
Inhalt nicht mindestens 16 Bytes von dem ersten Treffer entfernt ist.
Bericht von der Front
Ein weit verbreiteter Irrglaube besteht darin, dass Snort oder Suricata die Inhalte
in der Reihenfolge suchen, in der sie in der Regel angegeben sind. Wenn es in der
Regel beispielsweise heißt: content:eins; content:zwei;, dann gehen viele davon
aus, dass die Engine nach Vorkommen dieser Texte in der angegebenen Reihenfolge sucht. Tatsächlich aber findet die Regel nicht nur eine Übereinstimmung in
einer Payload mit dem Inhalt einszwei, sondern auch mit zweieins. Um gezielt
nach Inhalten in einer bestimmten Reihenfolge zu suchen, können Sie den Modifikator distance mit dem Wert 0 angeben. Dadurch teilen Sie der IDS-Engine mit,
dass der zweite Inhalt hinter dem ersten stehen muss, dass der genaue Abstand
aber keine Rolle spielt. Wenn wir nach content:eins; content:zwei; distance:0;
suchen, finden wir daher nur einszwei, aber nicht zweieins.
Ein weiterer Modifikator, der eine Beziehung zwischen mehreren gesuchten Inhalten
vorschreibt, ist within. Damit geben Sie die Anzahl der Bytes vom Ende der ersten Übereinstimmung an, innerhalb derer sich die zweite befinden muss. Ein Beispiel dafür sehen
Sie in folgender Regel:
alert tcp $HOME_NET any ->$EXTERNAL_NET 3724 (msg:"ET GAMES World of
Warcraft connection"; flow:established,to_server; content:"|00|";
depth:1; content:"|25 00|WoW|00|"; distance:1; within:7; reference:
url,doc.emergingthreats.net/bin/view/Main/2002138; classtype:policyviolation; sid:2002138; rev:9;)
Mit dieser Regel werden Verbindungen mit dem Onlinespiel »World of Warcraft« aufgespürt, indem nach zwei bestimmten Inhalten in der richtigen Reihenfolge gesucht wird:
1. content:"|00|"; depth:1;
Findet den gesuchten Inhalt im ersten oder zweiten Byte der Payload.
2. content:"|25 00|WoW|00|"; distance:1; within:7;
Sucht im Bereich von einem bis sieben Byte hinter der vorherigen Übereinstimmung
nach dem zweiten Inhalt.
9.6 IDS-Regeln 303
Diese Regel löst bei folgender Payload einen Alarm aus:
0x0000: 0000 2500 576f 5700 0000 0000 0000 0000 ...WoW...........
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 .................
Bei der folgenden Payload dagegen erfolgt kein Alarm, da der zweite Inhalt außerhalb des
von distance und within angegebenen Bereichs liegt:
0x0000: 0000 0000 0000 0000 2500 576f 5700 0000 ..........WoW....
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 .................
HTTP-Inhaltsmodifikatoren: Am häufigsten werden Sie Regeln zur Untersuchung von
HTTP-Datenverkehr schreiben, da dieses Protokoll ausgiebig für legitimen Datenverkehr
genutzt wird und Angreifer oft versuchen, schädliche Aktivitäten darin zu verstecken. Mit
den bis jetzt besprochenen Inhaltsmodifikatoren können wir zwar verdächtige Aktionen
in HTTP-Datenverkehr erfolgreich aufspüren, allerdings ist diese Vorgehensweise ein bisschen mühselig.
Betrachen Sie beispielsweise das folgende HTTP-Paket:
11:23:39.483578 IP 172.16.16.139.64581>67.205.2.30.80: Flags [P.],
seq 1:806, ack 1, win 16384, length 805
0x0000: 4500 034d 532b 4000 4006 e1f9 ac10 108b E..MS+@.@.......
0x0010: 43cd 021e fc45 0050 2b1e 34a5 9140 5480 C....E.P+.4..@T.
0x0020: 5018 4000 5334 0000 4745 5420 2f20 4854 P.@.S4..GET./.HT
0x0030: 5450 2f31 2e31 0d0a 486f 7374 3a20 7777 TP/1.1..Host:.ww
0x0040: 772e 6170 706c 6965 646e 736d 2e63 6f6d w.appliednsm.com
0x0050: 0d0a 436f 6e6e 6563 7469 6f6e 3a20 6b65 ..Connection:.ke
0x0060: 6570 2d61 6c69 7665 0d0a 4163 6365 7074 ep-alive..Accept
0x0070: 3a20 7465 7874 2f68 746d 6c2c 6170 706c :.text/html,appl
0x0080: 6963 6174 696f 6e2f 7868 746d 6c2b 786d ication/xhtml+xm
0x0090: 6c2c 6170 706c 6963 6174 696f 6e2f 786d l,application/xm
0x00a0: 6c3b713d302e392c2a2f2a3b713d302el;q=0.9,*/*;q=0.
0x00b0: 380d 0a55 7365 722d 4167 656e 743a 204d 8..User-Agent:.M
0x00c0: 6f7a 696c 6c61 2f35 2e30 2028 4d61 6369 ozilla/5.0.(Maci
0x00d0: 6e74 6f73 683b 2049 6e74 656c 204d 6163 ntosh;.Intel.Mac
0x00e0: 204f 5320 5820 3130 5f38 5f34 2920 4170 .OS.X.10_8_4).Ap
0x00f0: 706c 6557 6562 4b69 742f 3533 372e 3336 pleWebKit/537.36
0x0100: 2028 4b48 544d 4c2c 206c 696b 6520 4765 .(KHTML,.like.Ge
0x0110: 636b 6f29 2043 6872 6f6d 652f 3238 2e30 cko).Chrome/28.0
0x0120: 2e31 3530 302e 3935 2053 6166 6172 692f .1500.95.Safari/
0x0130: 3533 372e 3336 0d0a 4163 6365 7074 2d45 537.36..Accept-E
0x0140: 6e63 6f64 696e 673a 2067 7a69 702c 6465 ncoding:.gzip,de
0x0150: 666c 6174 652c 7364 6368 0d0a 4163 6365 flate,sdch..Acce
0x0160: 7074 2d4c 616e 6775 6167 653a 2065 6e2d pt-Language:.en0x0170: 5553 2c65 6e3b 713d 302e 380d 0a43 6f6f US,en;q=0.8..
304 9 Signaturgestützte Erkennung mit Snort und Suricata
Wenn wir die Domäne appliednsm.com für schädlich halten, können wir eine IDS-Regel
schreiben, die erkennt, wenn Benutzer versuchen, diese Website in ihren Browsern aufzusuchen. Mit den Optionen, die wir bisher kennengelernt haben, würde die Regel wie folgt
aussehen:
alert tcp $HOME_NET any ->$EXTERNAL_NET any (msg:"Evil Domain www.appliednsm.
com"; content:"GET "; offset:0; depth:4; content:"Host|3a 20|www.appliednsm.
com"; distance:0; sid:5000000; rev:1;)
Dabei geschieht Folgendes:
1. content:"GET "; offset:0; depth:4;
Sucht den angegebenen Inhalt im Bereich zwischen dem Anfang der Payload und dem
vierten Byte.
2. content:"Host|3a 20|www.appliednsm.com"; distance:0;
Sucht den angegebenen Inhalt hinter der ersten Übereinstimmung.
Das funktioniert zwar, aber es gibt eine bessere Methode. Sowohl Snort als auch Suricata
können den HTTP-Stream wieder zusammensetzen und bieten einige Regelmodifikatoren, mit denen sich für diese Art von Datenverkehr viel effizientere Regeln schreiben lassen. Unsere vorherige Regel können wir mit den Modifikatoren http_method und http_uri
wie folgt umschreiben:
alert tcp $HOME_NET any ->$EXTERNAL_NET any (msg:"Evil Domain www.appliednsm.
com"; content:"GET"; http_method; content:"www.appliednsm.com"; http_uri;
sid:5000000; rev:1;)
Diese Regel bewirkt genau das Gleiche wie die vorherige Version, lässt sich aber viel
leichter schreiben und erfüllt ihre Aufgabe auf effizientere Weise. Außer den beiden hier
verwenden HTTP-Modifikatoren gibt es mehrere andere. Die gebräuchlichsten sind in
Tabelle 9.1 aufgeführt.
Tabelle 9.1: HTTP-Regelmodifikatoren
HTTP-Modifikator
Beschreibung
http_client_body
Inhalt im Rumpf einer HTTP-Clientanforderung
http_cookie
Inhalt im HTTP-Headerfeld »Cookie«
http_header
Inhalt irgendwo im Header einer HTTP-Anforderung oder -Antwort
http_method
Die vom Client verwendete HTTP-Methode (GET,
POST usw.)
9.6 IDS-Regeln 305
HTTP-Modifikator
Beschreibung
http_uri
Inhalt im URI der HTTP-Clientanforderung
http_stat_code
Inhalt im HTTP-Statusfeld der Serverantwort
http_stat_message
Inhalt in der HTTP-Statusmeldung der Serverantwort
http_encode
In der HTTP-Transaktion verwendete Kodierung
Perl-kompatible reguläre Ausdrücke (PCRE): Es kann Situationen geben, in denen es
nicht möglich ist, mit den von der IDS-Engine bereitgestellten Konstrukten die passenden
Regeln zu schreiben. In solchen Fällen können Sie Perl-kompatible reguläre Ausdrücke
verwenden. Sie sind sehr vielseitig, und ihre Syntax erlaubt es, nach allen möglichen Arten
von Inhalten zu suchen, die Sie finden müssen.
Solche regulären Ausdrücke können sehr einfach sein, etwa wie in der Beispielregel, die
Kreditkartennummern erkennt:
alert ip any any ->any any (msg:"ET POLICY SSN Detected in Clear Text
(dashed)"; pcre:"/ ([0-6]\d\d|7[0-256]\d|73[0-3]|77[0-2])-\d{2}-\d{4} /";
reference:url,doc.emergingthreats.net/2001328; classtype:policy-violation;
sid:2001328; rev:13;)
Sie können jedoch auch beliebig kompliziert werden wie in der folgenden Regel, die
schädliche Java-Abfragen nach dynamischen DNS-Domänen erkennt:
alert tcp $HOME_NET any ->$EXTERNAL_NET $HTTP_PORTS (msg:"ET CURRENT
_EVENTS SUSPICIOUS Java Request to ChangeIP Dynamic DNS Domain"; flow:to_
server,established; content:" Java/1."; http_header; pcre:"/^Host\x3a\
x20[˄\r\n]+\.(?:m(?:y(?:p(?:op3\.(?:net|org)|icture\.info)|n(?:etav\.
(?:net|org)|umber\.org)|(?:secondarydns|lftv|03)\.com|d(?:ad\.info|dns\.
com)|ftp\.(?:info|name)|www\.biz|z\.info)|(?:r(?:b(?:asic|onus)|(?:slov|fac)
e)|efound)\.com|oneyhome\.biz)|d(?:yn(?:amic(?:dns\.(?:(?:org|co|me)\.
uk|biz)|-dns\.net)|dns\.pro|ssl\.com)|ns(?:(?:-(?:stuff|dns)|0[45]|et|rd)\.
com|[12]\.us)|dns\.(?:m(?:e\.uk|obi|s)|info|name|us)|(?:smtp|umb1)\.com|hcp\.
biz)|(?:j(?:u(?:ngleheart|stdied)|etos|kub)|y(?:ou(?:dontcare|rtrap)|gto)|4
(?:mydomain|dq|pu)|q(?:high|poe)|2(?:waky|5u)|z(?:yns|zux)|vizvaz|1dumb)\.
com|s(?:e(?:(?:llclassics|rveusers?|ndsmtp)\.com|x(?:idude\.
com|xxy\.biz))|quirly\.info|sl443\.org|ixth\.biz)|o(?:n(?:mypc\.
(?:info|biz|net|org|us)|edumb\.com)|(?:(?:urhobb|cr)y|rganiccrap|tzo)\.
com)|f(?:ree(?:(?:ddns|tcp)\.com|www\.(?:info|biz))|a(?:qserv|rtit)\.
com|tp(?:server|1)\.biz)|a(?:(?:(?:lmostm|cmeto)y|mericanunfinished)\.
com|uthorizeddns\.(?:net|org|us))|n(?:s(?:0(?:1\.(?:info|biz|us)|2\.
(?:info|biz|us))|[123]\.name)|inth\.biz)|c(?:hangeip\.
(?:n(?:ame|et)|org)|leansite\.(?:info|biz|us)|ompress\.
to)|i(?:(?:t(?:emdb|saol)|nstanthq|sasecret|kwb)\.com|ownyour\.
306 9 Signaturgestützte Erkennung mit Snort und Suricata
(?:biz|org))|p(?:ort(?:relay\.com|25\.biz)|canywhere\.net|roxydns\.
com)|g(?:r8(?:domain|name)\.biz|ettrials\.com|ot-game\.org)|l(?:flink(?:up\.
(?:com|net|org)|\.com)|ongmusic\.com)|t(?:o(?:ythieves\.com|h\.
info)|rickip\.(?:net|org))|x(?:x(?:xy\.(?:info|biz)|uz\.com)|24hr\.
com)|w(?:ww(?:host|1)\.biz|ikaba\.com|ha\.la)|e(?:(?:smtp|dns)\.biz|zua\.
com|pac\.to)|(?:rebatesrule|3-a)\.net|https443\.(?:net|org)|bigmoney\.biz)(\
x3a\d{1,5})?\r$/Hmi”; classtype:bad-unknown; sid:2016581; rev:1;)
Wie Sie in diesen Regelbeispielen sehen, können Sie einen solchen regulären Ausdruck mit
folgender Syntax in eine Regel einfügen:
pcre:<regulärer Ausdruck>;
Das Schreiben von regulären Ausdrücken können wir in diesem Buch nicht erklären. Es
gibt jedoch eine Reihe von Online-Tutorials, die Ihnen den Start erleichtern. Wenn Sie
nach einem ausführlicheren Lehrbuch suchen, kann ich Ihnen je nach Kenntnisstand
»Einstieg in reguläre Ausdrücke« von Michael Fitzgerald und »Reguläre Ausdrücke« von
Jeffrey E. F. Friedl empfehlen.
Kommunikationsfluss
Sowohl in Snort als auch in Suricata können Sie Regeln schreiben, die den Kommunikationsfluss des Netzwerkverkehrs über das Protokoll TCP berücksichtigen. Da bereits im
Regelheader die Quell- und Zieladressen und -ports angegeben sind, mag das redundant
erscheinen, aber das ist nicht der Fall. Die Informationen im Header besagen, in welche
Richtung der Datenverkehr verläuft (eingehend oder ausgehend), aber sie geben nicht
zwangsläufig an, wer für welchen Teil dieser Kommunikation verantwortlich ist.
Um zu verstehen, wie die Flussoptionen funktionieren und warum sie so wichtig sind,
müssen wir uns vor Augen führen, wie eine TCP-Sitzung abläuft. In einer solchen Sitzung kommuniziert ein Client mit einem Server. Der Client löst die Kommunikation aus,
indem er ein SYN-Paket an den Port sendet, an dem der Server lauscht. Darauf antwortet
der Server mit einem SYN/ACK-Paket. Wenn der Client dieses Paket empfangt, antwortet er
wiederum mit einem ACK-Paket. Damit ist der Drei-Wege-Handshake abgeschlossen, sodass der Client und der Server miteinander kommunizieren können, bis einer der beiden
die Verbindung abbricht – entweder abrupt durch ein RST-Paket oder auf sauberere Weise
durch eine Folge von FIN-Paketen, was als »TCP-Teardown« bezeichnet wird. In Kapitel
13 sehen wir uns diesen Vorgang noch genauer an, aber der hier geschilderte Ablauf bildet
die Grundlage einer TCP-Sitzung.
Flussregeloptionen bestehen selbst aus mehreren Optionen, die in drei Kategorien fallen:
Zustandsoptionen, Richtungsoptionen und Streamoptionen. Angegeben werden sie im
folgenden Format, wobei eine Option erforderlich ist und die restlichen nach Belieben
hinzugefügt werden können:
9.6 IDS-Regeln 307
flow: <Option>,<Option>,<Option>;
Die beiden möglichen Zustandsoptionen sind established und stateless. Bei established
werden nur Übereinstimmungen gefunden, wenn eine TCP-Sitzung eingerichtet ist, bei
stateless erfolgt die Suche unabhängig vom Vorhandensein einer solchen Verbindung.
Es gibt vier Richtungsoptionen:
••
••
••
••
to_server: Datenverkehr vom Client zum Server
from_server: Datenverkehr vom Server zum Client
to_client: Datenverkehr vom Server zum Client
from_cleint: Datenverkehr vom Client zum Server
Hinweis für Analytiker
Ist Ihnen aufgefallen, dass die beiden Optionen to_server und from_client sowie
die Optionen to_client und from_server jeweils identisch sind? Keine Angst, Sie
haben sich nicht verlesen, und dies sind auch keine Druckfehler. Diese Optionen
sind tatsächlich paarweise identisch. Die unterschiedlichen Varianten gibt es, um
Regeln verständlicher zu gestalten.
Die beiden letzten Optionen sind no_stream und only_stream. Damit wird angegeben,
ob sich die gesuchten Daten in einem wieder zusammengesetzten Stream oder in einem
einzelnen Paket befinden.
Als Beispiel für die Verwendung von Flussoptionen sehen wir uns die folgende Regel an:
alert tcp $HOME_NET any ->$EXTERNAL_NET 5222 (msg:"GPL CHAT MISC Jabber/
Google Talk Outgoing Traffic"; flow:to_server,established; content:"<stream";
nocase; reference:url,www.google.com/talk/; classtype:policy-violation;
sid:100000230; rev:2;)
Mit dieser Regel wird eine Authentifizierung an einem Chatserver für Jabber oder Google
Talk erkannt. Die Option zur Inhaltssuche ist sehr einfach gehalten, aber davor wird noch
die Option flow:to_server,established verwendet. Dies sorgt dafür, dass nur fertig aufgebaute TCP-Sitzungen auf Übereinstimmung mit dieser Regel überprüft werden, was
die Leistung von Snort bzw. Suricata steigert. Außerdem wird die Genauigkeit der Regel
erhöht, da nur Datenverkehr zu dem in der TCP-Sitzung definierten Server erkannt wird.
Nicht bei allen Regeln lässt sich die Genauigkeit durch Flussoptionen steigern, allerdings
erhöhen die Flussstatusoptionen oft die Leistung. Daher verwende ich sie, wann immer
es möglich ist.
308 9 Signaturgestützte Erkennung mit Snort und Suricata
Protokollheaderoptionen
Snort und Suricata können auch Werte in den Headern der untersuchten Pakete erkennen, darunter fast alle Werte in den Headern der Protokolle ICMP, IP, TCP und UDP. Ich
werde hier nicht alle möglichen Werte nennen, da Sie sie auch in der Dokumentation zu
Snort bzw. Suricata nachschlagen können, sondern gebe nur einige der Elemente an, die
ich häufig nutze:
•• TTL: Sucht nach Übereinstimmungen mit dem angegebenen TTL-Wert. Hier kann entweder der genaue Wert genannt werden (mit =) oder ein Vergleich (mit den relationalen Operatoren >, >=, < oder <=). Das ist nützlich, um bestimmte Arten von Betriebssystemen anhand ihres ursprünglichen TTL-Werts zu erkennen.
•• dsize: Sucht nach Paketen mit einer Payload der angegebenen Größe. Hier kann entweder der genaue Wert genannt werden (mit =) oder ein Vergleich (mit den relationalen Operatoren >, >=, < oder <=). Das ist nützlich, um die Genauigkeit von Inhaltssuchen zu erhöhen.
•• itype: Sucht nach dem ICMP-Typ des angegebenen Werts.
•• icode: Sucht nach dem ICMP-Code des angegebenen Werts.
•• ip_proto: Sucht nach dem angegebenen IP-Protokoll. Hier können Sie entweder den
Protokollnamen (IGMP, GRE usw.) oder die Nummer nennen.
9.6.2 Optimierung von Regeln
In Kapitel 7 haben wir uns Techniken angesehen, um die Effektivität von Signaturen mithilfe von Messgrößen wie der Rate von Fehlalarmen und der Genauigkeit zu bestimmen.
Wenn die Effektivität nicht ausreicht, können verschiedene Methoden angewandt werden,
um sie zu steigern. Manche Methoden verbessern auch die Leistung. Im folgenden sehen
wir uns einige empfehlenswerte Vorgehensweisen an, um IDS-Regeln zu optimieren.
Ereignisfilterung
Manche Regeln lösen von Natur aus eine extrem große Zahl von Alarmen aus. Ein Beispiel
dafür ist eine Regel, die eine bestimmte Art von Denial-of-Service-Angriff erkennt. Es ist
wichtig, solche Angriffe zu bemerken, aber wenn die Regel bei jedem gesendeten DoSPaket eine Übereinstimmung findet und Sie Tausende dieser Pakete pro Sekunde erhalten,
dann werden auch Tausende von Alarmen pro Sekunde ausgelöst, was letzten Endes nicht
nur die IDS-Engine, sondern auch die Analytiker überfordert. Die Optionen zur Ereignisfilterung in Snort und Suricata erlauben Ihnen, in Ihren Regeln Schwellenwerte anzugeben, um eine solche explosionsartige Vermehrung von Alarmen zu verhindern.
Ereignisfilter werden nicht als Option in die Regel selbst aufgenommen, sondern in die
Datei threshold.conf geschrieben. Name und Speicherort dieser Datei lassen sich in snort.
conf bzw. suricata.yaml nach Bedarf anpassen. In Security Onion finden Sie diese Datei in
/etc/nsm/<Sensorname>/threshold.conf.
9.6 IDS-Regeln 309
Hinweis für Analytiker
Früher wurden Ereignisfilter als Schwellenwertoptionen bezeichnet und in die
Regel selbst aufgenommen. Zur Zeit der Abfassung dieses Buches wird diese Methode von Snort und Suricata immer noch unterstützt, und es gibt auch noch
eine Menge öffentlich verfügbarer Regeln in diesem Format. Die Syntax der beiden Varianten ist identisch. Da in diesem Buch Regeln aus öffentlichen Quellen verwendet werden, kann es sein, dass einige der Beispielregeln noch die alten
Schwellenwertoptionen enthalten. Es wird jedoch empfohlen, die neue Methode
anzuwenden und Ereignisfilter in die Datei threshold.conf zu schreiben.
Es gibt drei Arten von Ereignisfiltern:
•• Grenzwert (limit): Während des mit seconds angegebenen Zeitraums werden Alarme nur für die ersten Übereinstimmungen bis zu der in count angegebenen Anzahl
ausgelöst. Alle darüber hinausgehenden Alarme werden für den Rest dieses Zeitraums
ignoriert.
•• Schwellenwert (threshold): Während des mit seconds angegebenen Zeitraums wird
nur bei jeder n-ten Übereinstimmung ein Alarm ausgelöst. Der Wert von n ist in count
angegeben.
•• Beides (both): Löst nach der in count angegebenen Anzahl von Übereinstimmungen
im Zeitraum seconds einen einzigen Alarm aus und ignoriert alle weiteren Übereinstimmungen, die in dem Zeitraum noch auftreten.
Für Ereignisfilter gilt folgende Syntax:
event_filter gen_id<Wert>, sig_id<Wert>, type<limit|threshold|both>, track<by_
src|by_dst>, count<Wert>, seconds<Wert>
Dabei werden die folgenden Bestandteile verwendet:
•• gen_id: Gibt die Generator-ID der Regel an.
•• sig_id: Gibt die Signatur-ID der Regel an.
•• type <limit|threshold|both>: Gibt den Typ des anzuwendenden Ereignisfilters nach
der vorstehenden Beschreibung an.
•• track <by_src|by_dst>: Gibt an, ob die Regelübereinstimmungen nach eindeutiger
Quell- oder eindeutiger Zieladresse gezählt werden.
•• count: Die Anzahl der Regelübereinstimmungen im angegebenen Zeitraum, die als
Grenz- oder Schwellenwert für den Filter herangezogen wird.
•• seconds: Der Zeitraum in Sekunden, in dem die Regelübereinstimmungen gezählt
werden.
310 9 Signaturgestützte Erkennung mit Snort und Suricata
Die folgende Regel zeigt ein Beispiel für die Verwendung von Ereignisfiltern:
alert tcp $HOME_NET any ->!$WSUS_SERVERS $HTTP_PORTS (msg:"ET POLICY
Windows Update in Progress"; flow:established,to_server; content:"WindowsUpdate-Agent"; http_header; content:"Host|3a|"; http_header;
nocase; within:20;pcre:"/User-Agent\x3a[^\n]+Windows-Update-Agent/
i";reference:url,windowsupdate.microsoft.com; reference:url,doc.
emergingthreats.net/2002949; classtype:policy-violation; sid:2002949; rev:8;)
Mit dieser Regel werden Geräte aufgespürt, die Windows-Aktualisierungen von nicht zugelassenen Updateservern herunterladen. Dabei wird nach einem bestimmten String für
den Benutzer-Agent gesucht. Wenn ein Windows-Computer Aktualisierungen bezieht,
erscheint dieser String in mehreren Paketen, was dazu führt, dass ein einziger Host eine
erhebliche Nummer von Alarmen hervorruft. Bei mehreren Hosts, die dieses Verhalten
zeigen, kann die Anzahl der Alarme die Analytiker rasch überfordern. Damit ist diese Regel ein idealer Kandidat für einen Ereignisfilter. Der folgende Filter schafft Abhilfe:
event filter gen_id 1,sig_id 2002949,type limit,track by_src,count 1, seconds 300
Dieser Filter zählt alle Ereignisse für eine Quelladresse innerhalb eines Zeitraums von
300 Sekunden. Da es sich um einen Filter vom Typ limit handelt und der Wert von count
auf 1 gesetzt ist, wird pro Host nur ein Alarm alle 300 Sekunden ausgelöst.
Eine weitere großartige Anwendung von Ereignisfiltern besteht bei Regeln im Zusammenhang mit Scans, die Unmengen von Paketen erzeugen. Wenn für jedes der Pakete, das die
Kriterien in der Regel erfüllt, ein Alarm ausgelöst würde, könnten sich die Analytiker vor
Alarmen nicht mehr retten. Um Abhilfe zu schaffen, können Sie einen Ereignisfilter einsetzen, sodass die Analytiker von dem Scan informiert werden, ohne ihre Analysekonsole
mit Meldungen zu überfluten.
Alarme unterdrücken
Ich habe schon mehrfach erlebt, dass ein Analytiker viel Arbeit in eine neue Regel gesteckt
hat, nur um dann festzustellen, dass ein oder zwei Hosts in seinem Netzwerk Datenverkehr einer Form hervorrufen, die zu einer Menge von Fehlalarmen führt. Das kann ziemlich frustrierend sein und schließlich dazu führen, dass der Analytiker die Regel komplett
aufgibt. Das ist aber nicht nötig, denn für solche Fälle gibt es in Snort und Suricata eine
Funktion zur Unterdrückung von Alarmen. Damit können Sie eine Regel und eine IPAdresse (bzw. eine Gruppe von IP-Adressen aus einer Variable) angeben, sodass Alarme
aufgrund dieser Hosts und dieser Regel unterdrückt werden.
9.6 IDS-Regeln 311
Auch die Einträge dafür werden in der Datei threshold.conf vorgenommen, und zwar im
folgenden Format:
suppress gen_id<Wert>,sig_id<Wert>,track<by_src|by_dst>,ip<Wert>
Dabei werden folgende Optionen verwendet:
•• gen_id: Gibt die Generator-ID der Regel an.
•• sig_id: Gibt die Signatur-ID der Regel an.
•• track <by_src|by_dst>: Gibt an, ob die Alarme aufgrund von Datenverkehr von einer
Quell- oder zu einer Zieladresse unterdrückt werden sollen. Diese Angabe ist optional.
•• ip<Wert>: Die IP-Adresse, von der Alarme aufgrund der angegebenen Regel unterdrückt werden sollen.
Der folgende Eintrag unterdrückt alle Alarme, die ansonsten nach Regel SID 5000000 aufgrund von Datenverkehr von der IP-Quelladresse 192.168.1.100 ausgelöst würden:
suppress gen_id 1, sig_id 5000000, track by_src, ip 192.168.1.100
Die Unterdrückung von Alarmen ist eine nützliche Vorgehensweise, um einzelne Hosts,
die bei einer bestimmten Regel Fehlalarme auslösen, von dieser Regel auszuschließen. Das
sollte Ihre erste Maßnahme ein, bevor Sie die ganze Regel entfernen.
Erkennungsfilter
In Snort und Suricata können Sie auch Erkennungsfilter einsetzen. Damit legen Sie einen
Schwellenwert für die Anzahl der Regelübereinstimmungen fest, die in einem bestimmten
Zeitraum auftreten müssen, bevor ein Alarm ausgelöst wird. Erkennungsfilter können für
die Quell- und die Zieladresse des Datenverkehrs angewendet werden.
Die Erkennungsfilteroption wird im folgenden Format direkt in der Regel angegeben:
detection_filter: track<by_src|by_dst>, count<Wert>,seconds<Wert>;
Dabei werden folgende Optionen verwendet:
•• track <by_src|by_dst>: Gibt an, ob die Regelübereinstimmungen für eine eindeutige
Quell- oder eine eindeutige Zieladresse gezählt werden sollen.
•• count: Die Anzahl der Regelübereinstimmungen im angegebenen Zeitraum, ab der ein
Alarm ausgelöst wird.
•• seconds: Der Zeitraum in Sekunden, in dem Regelübereinstimmungen der angegebenen Menge auftreten müssen, damit ein Alarm ausgelöst wird.
312 9 Signaturgestützte Erkennung mit Snort und Suricata
Die folgende Regel zeigt ein Beispiel für die Verwendung von Erkennungsfiltern:
alert tcp $EXTERNAL_NET any ->$HTTP_SERVERS $HTTP_PORTS (msg:"ET SCAN Sqlmap
SQL Injection Scan"; flow:to_server,established; content:"User-Agent|3a|
sqlmap"; fast_pattern:only; http_header; detection_filter:track by_dst,
count 4, seconds 20; reference:url,sqlmap.sourceforge.net; reference:url,doc.
emergingthreats.net/2008538; classtype:attempted-recon; sid:2008538; rev:8;)
Diese Regel dient dazu, Scans durch das Tool Sqlmap aufzudecken, das zum Aufspüren
von Anfälligkeiten für SQL-Injektionsangriffe und zu deren Ausnutzung eingesetzt wird.
Hier wird nach Übereinstimmungen mit dem von Sqlmap verwendeten Benutzer-Agent
gesucht. Da Scans durch Sqlmap normalerweise sehr umfangreich sind, deutet es nicht auf
einen Scanangriff hin, wenn dieser Benutzer-Agent nur ein- oder zweimal in Erscheinung
tritt. Daher könnte es zu einer erheblichen Menge von Fehlalarmen führen, wenn bei jeder Übereinstimmung ein Alarm ausgelöst würde. Daher enthält die Regel den folgenden
Erkennungsfilter:
detection_filter:track by_dst, count 4, seconds 20;
Bevor die Erkennungsengine aufgrund dieser Regel einen Alarm auslöst, muss also erst
der angegebene Schwellenwert überschritten sein. Dazu zählt die Engine die Anzahl der
Regelübereinstimmungen für die Zieladresse, und wenn im Zeitraum von 20 Sekunden
mehr als vier solcher Übereinstimmungen auftreten, erfolgt ein Alarm.
Ereignisfilter eignen sich für viele verschiedene Situationen. Im Allgemeinen werden sie
angewendet, wenn ein geringes Vorkommen der gesuchten Inhalte noch nichts Schlechtes
bedeutet, ein massives Auftreten aber auf ein Problem hindeutet. Beispielsweise kann es
häufig vorkommen, dass ein Benutzer sich an einem Webdienst anzumelden versucht und
ein oder zwei Fehlschläge erleidet, weil er das Passwort falsch eingegeben hat. Wenn jedoch
innerhalb weniger Minuten mehrere hundert Anmeldeversuche an einem Webdienst erfolgen, dann deutet das auf den Versuch hin, das Passwort mit einem Brute-Force-Angriff zu
erraten, was eine weitergehende Untersuchung dringend erforderlich macht.
Unerwünschten Datenverkehr ausschließen
Nach einem weit verbreiteten Irrtum senkt jede Option, die Sie einer Regel hinzufügen, deren
Leistung. In Wirklichkeit ist das Gegenteil der Fall: Wenn Sie eine IDS-Regel um Optionen
ergänzen, die die Menge des von der Engine zu durchsuchenden Datenverkehrs verringern,
dann steigern Sie die Leistung der Regel. Daher sollten Sie Ihr Möglichstes tun, um solche
Optionen hinzuzufügen. Dazu bieten sich unter anderem folgende Maßnahmen an:
9.6 IDS-Regeln 313
•• Verwenden Sie nach Möglichkeit Protokollheaderoptionen. Die Erkennungsengine
schaut sich erst die Header und dann die Payload des Pakets an. Daher können Sie
wertvolle Verarbeitungszyklen einsparen, wenn Sie Pakete schon vor der Inhaltsuntersuchung ausschließen.
•• Setzen Sie das Schlüsselwort any im Regelheader nicht verschwenderisch ein. Wenn Sie
die Regel auf einen einzelnen Host oder eine Gruppe von Hosts einschränken können,
verringert das auch die Menge an Datenverkehr, den die IDS-Engine verarbeiten muss.
•• Bezeichnen Sie immer möglichst genau die Stelle, an der der gesuchte Inhalt zu finden
sein soll. Wenn Sie beispielsweise wissen, dass der Inhaltsstring, nach dem Sie Ausschau
halten, immer an derselben Position in der Payload auftritt, dann nutzen Sie die Optionen offset und depth, damit die Engine nicht den kompletten Inhalt des Pakets absucht.
•• Schränken Sie die Suche auf Pakete einer bestimmten Größe ein. Wenn Sie zwar nicht
die genaue Position des gesuchten Inhalts kennen, aber wissen, dass er immer in Paketen einer bestimmten Größe auftritt, dann können Sie die Option dsize nutzen, damit
die Engine nur Pakete mit diesem Umfang untersucht, was die Leistung steigert.
•• Verwenden Sie immer Flussoptionen, wenn es möglich ist. Wenn der gesuchte Datenverkehr nur in eingerichteten Verbindungen zum Server auftritt, dann kann sie
jeglichen anderen Datenverkehr von der Verarbeitung ausschließen. Das kann zu
einer erheblichen Leistungssteigerung führen.
•• Wählen Sie im Regelheader möglichst genau das Protokoll aus. Wenn Sie TCP oder
UDP statt einfach nur IP angeben, wird die Anzahl der Pakete, die die Erkennungs­
engine verarbeiten muss, erheblich reduziert.
Regeln für Schwachstellen schreiben
Oft ist es zum Schutz gegen die Ausnutzung eines Dienstes am einfachsten, Regeln zu
schrei­ben, die gezielt bestimmte Arten von Exploits erkennen. Allerdings bleiben bei dieser Vorgehensweise viele Angriffe unbemerkt. Die Regel spürt zwar den Exploit auf, für
den sie geschrieben wurde, übersieht aber andere Exploits, die dieselbe Schwachstelle ausnutzen. Daher ist es besser, die Regeln auf die Schwachstellen abzustimmen.
Stellen Sie sich beispielsweise eine Schwachstelle vor, die durch einen Pufferüberflauf im
Eingabefeld einer Netzwerkanwendung ausgenutzt werden kann. Es wäre ganz einfach,
eine Regel zu schreiben, die die öffentlich verfügbare Version dieses Exploits erkennt –
aber für einen Angreifer wäre es ebenso einfach, den Exploitstring zu ändern und eine
andere Auffüllung, anderen Shellcode oder eine andere Payload zu verwenden. Anstatt
nach einem String des Exploits zu suchen, sollte Ihre Regel darauf achten, ob das von der
Anwendung übermittelte Eingabefeld eine außerordentlich große Zahl von Zeichen enthält. Eine solche Regel lässt sich zwar schwerer schreiben und wird einige Fehlalarme zur
Folge haben, kann die Ausnutzung des angreifbaren Dienstes aber viel besser erkennen.
Diese Vorgehensweise erfordert mehr Arbeit, erzielt aber bessere Ergebnisse und verringert die Gefahr, dass Ihnen schädliche Aktivitäten durch die Lappen gehen.
314 9 Signaturgestützte Erkennung mit Snort und Suricata
PCRE und Inhaltssuche kombinieren
Perl-kompatible reguläre Ausdrücke (PCRE) steigern die Flexibilität von IDS-Regeln zwar
ins Unermessliche, erhöhen aber auch die Belastung des Systems. Eine Vorgehensweise,
um diese Belastung zu verringern, besteht darin, Regeln mit solchen regulären Ausdrücken und Regeln mit Inhaltssuche zu kombinieren. Die Erkennungsengine sucht erst nach
einer inhaltlichen Übereinstimmung, damit nur der Datenverkehr, der diese Bedingung
erfüllt, der weitergehenden PCRE-Untersuchung unterzogen wird.
Betrachten Sie beispielsweise folgende Regel:
alert tcp $EXTERNAL_NET any ->$HOME_NET any (msg:"ET TROJAN
IRC potential reptile commands"; flow:established,from_server;
content:"PRIVMSG|20|"; depth:8; content:"|3a|"; within:30; pcre:"/\.
((testdlls|threads|nsp|speed|uptime|installed|secure|sec|unsecure|unsec|
process|ps|rand|exploitftpd|eftpd|flusharp|farp|flushdns|fdn
s|resolve|dns|pstore|pst|sysinfo|si|netinfo|ni|driveinfo|di|
currentip)\s*[\r\n]|(iestart|ies|login|l|mirccmd|system|file\
s+(cat|exists|e|del|rm|rmdir|move|copy|attrib)|down|dl\dx|update|reg\
s+(query|delete|write))\s+\w+|(banner|ban|advscan|asc|scanall|sa|ntscan|nts)\
s*[\n\r])/i"; reference:url,doc.emergingthreats.net/2002363; classtype:trojanactivity; sid:2002363; rev:15;)
Diese Regel erkennt die Gegenwart des Malware-Stamms »Reptile«, wenn dieser versucht,
Befehle über IRC auszuführen. Sie enthält zwar einen sehr CPU-intensiven regulären Ausdruck, aber auch zwei Inhaltssuchen:
1. content:"PRIVMSG|20|"; depth:8;
2. content:"|3a|"; within:30;
Damit wird dafür gesorgt, dass die IDS-Engine nur solche Pakete auf Übereinstimmung
mit dem regulären Ausdruck untersucht, bei denen bereits festgestellt wurde, dass sie zum
IRC-Datenverkehr gehören.
Schnelle Mustersuche
Wenn eine Regel mehrere Inhaltssuchen umfasst, versuchen Snort und Suricata, als Erstes den spezifischsten String zu finden, sodass sie die Verarbeitung abbrechen können,
wenn sie dabei keine Übereinstimmung finden. Standardmäßig wird daher als Erstes nach
dem längsten String gesucht, weil die Engine davon ausgeht, dass dies der spezifischste ist.
Diese Vorgehensweise zeigt zwar gewöhnlich die erwünschte Wirkung, bewährt sich aber
nicht in allen Fällen. Daher gibt es in Snort und Suricata einen Modifikator für die schnelle Mustersuche. Angegeben wird er für kürzere Suchstrings, damit die Erkennungsengine
als Erstes versucht, eine Übereinstimmung damit zu finden.
9.6 IDS-Regeln 315
Die folgende Regel gibt ein Beispiel für die Verwendung dieses Modifikators:
alert tcp $EXTERNAL_NET any ->$HOME_NET $HTTP_PORTS (msg:"ET SCAN Nessus User
Agent"; flow: established,to_server; content:"User-Agent|3a|"; http_header;
nocase; content:"Nessus"; http_header; fast_pattern; nocase; pcre:"/^UserAgent\:[^\n]+Nessus/Hmi"; threshold: type limit, track by_src,count 1,
seconds 60; reference:url,www.nessus.org; reference:url,doc.emergingthreats.
net/2002664; classtype:attempted-recon; sid:2002664; rev:12;)
Diese Regel enthält zwei Inhaltssuchen:
1. content:"User-Agent|3a|"; http_header; nocase;
2. content:"Nessus"; http_header; fast_pattern; nocase
User-Agent|3a| ist zwar der längste String, aber sicherlich nicht der exklusivste, da er auch
im Standardheader von HTTP-Clientanforderungen zu finden ist. Daher ist es sinnvoll,
zuerst nach Nessus zu suchen, obwohl dieser String kürzer ist. Daher ist bei dieser Option
der Modifikator fast_pattern angegeben.
Hinweis für Analytiker
Der Modifikator für die schnelle Mustersuche kann in einer Regel immer nur
einmal eingesetzt werden. Darüber hinaus ist es nicht möglich, ihn mit den
HTTP-Inhaltsmodifikatoren http_cookie, http_raw_uri, http_raw_header, http_
raw_cookie, http_method, http_stat_code, http_stat_msg zu kombinieren.
Regeln manuell testen
Nachdem Sie eine Regel geschrieben haben, müssen Sie sie gründlich testen. Die Überprüfung der Regelsyntax haben wir uns bereits angesehen, aber das ist nur ein Schritt des
gesamten Vorgangs. Sie müssen sich auch vergewissern, das die Regel den Datenverkehr
entdeckt, den sie finden soll, aber keinen anderen. Angriffe oder andere schädliche Aktivitäten nachzustellen, kann sehr viel Zeit erfordern, aber zum Glück gibt es einige alternative Vorgehensweisen.
Wenn Analytiker eine Regel auf der Grundlage eines früheren Vorfalls schreiben und noch
über eine Aufzeichnung der betreffenden Pakete verfügen, können Sie diese an der Überwachungsschnittstelle eines Sensors wiedereinspielen, um auszuprobieren, ob dabei ein
Alarm ausgelöst wird. (Bei neuen Regeln sollte das vorzugsweise auf einem Testrechner mit
der IDS-Engine geschehen.) Eine gute Möglichkeit, erfasste Pakete live an einer Schnittstelle einzuspielen, bietet Tcpreplay. Ein Beispiel dafür sehen Sie in Abb. 9.23. Mehr über
Tcpreplay erfahren Sie auf http://tcpreplay.synfin.net/wiki/tcpreplay.
316 9 Signaturgestützte Erkennung mit Snort und Suricata
Abbildung 9.23: Wiedereinspielen einer PCAP-Datei an einer Schnittstelle mithilfe von Tcpreplay
Falls Sie keine Datei mit zuvor erfassten Daten für die Aktivität haben, für die die Regel
da ist, können Sie Scapy einsetzen, um manuell Datenverkehr zu generieren. Scapy ist
eine vielseitige Python-Bibliothek, mit der sie Pakete erzeugen und empfangen können.
Dieses Werkzeug ist für Analytiker wirklich äußerst wertvoll, allerdings werden wir es in
diesem Buch nicht im Einzelnen behandeln. Das folgende Beispiel zeigt ein sehr einfaches
Python-Skript, das Scapy nutzt, um ein TCP-Paket mit der Payload AppliedNSM über Port
80 an den Host 192.168.1.200 zu senden.:
ip=IP()
ip.dst="192.168.1.200"
ip.src="192.168.1.100"
tcp=TCP()
tcp.dport=80
tcp.sport=1234
payload="AppliedNSM"
send(ip/tcp/payload)
Mehr über Scapy erfahren Sie auf http://www.secdev.org/projects/scapy/.
9.7
Snort- und Suricata-Alarme anzeigen
Nachdem Sie die IDS-Engine Ihrer Wahl auf einem Sensor eingerichtet und IDS-Regeln
erstellt oder heruntergeladen haben, können Sie sich zurücklehnen und darauf warten,
dass Alarm ausgelöst wird. Es ist zwar möglich, diese Alarme direkt auf dem Sensor und
in den von Snort bzw. Suricata erstellten Dateien zu lesen, aber meistens wird ein grafisches Tool eines Drittanbieters verwendet, um diesen Vorgang zu erleichtern. Zur Anzeige
9.7 Snort- und Suricata-Alarme anzeigen 317
der von Snort und Suricata generierten Alarme gibt es verschiedene Mechanismen. Im
Folgenden sehen wir uns zwei der beliebtesten kostenlosen Open-Source-Schnittstellen
zur Alarmverwaltung an, nämlich Snorby und Sguil. Mit diesen Tools werden wir auch im
weiteren Verlauf dieses Buches arbeiten.
9.7.1
Snorby
Snorby ist eine relativ neue Alarmverwaltungskonsole. Sie wurde in Rugy on Rails
geschrieben und läuft im Webbrowser. Der Autor dieser Software, Dustin Weber, hat
inzwischen das Unternehmen Threat Stack gegründet, das Snorby als Open-SourceAnwendung weiterentwickelt. Snorby soll Analytikern eine Möglichkeit geben, Alarme
auf eine Weise zu untersuchen, die zwar einfach und übersichtlich ist, aber alles bietet,
was für eine wirkungsvolle Analyse erforderlich ist.
Eine Online-Demo von Snorby finden Sie auf http://demo.snorby.org. Für den Zugriff auf
diese Demo geben Sie den Benutzernamen demo@snorby.org und das Passwort snorby an.
Wenn Sie Security Onion verwenden, können Sie auch einfach auf das Snorby-Symbol
auf dem Desktop klicken oder https://<IP-Adresse von Security Onion>:444/ aufsuchen.
Abb. 9.24 zeigt das Dashboard von Snorby.
Abbildung 9.24: Das Dashboard von Snorby.
Weitere Informationen über Snorby erhalten Sie auf http://www.snorby.org.
318 9 Signaturgestützte Erkennung mit Snort und Suricata
9.7.2 Sguil
Viele Jahre lang war Sguil die Alarmverwaltungskonsole Nr. 1 für NSM-Analytiker. Im
Gegensatz zu Snorby handelt es sich bei Sguil um eine Desktop-Anwendung, die mit einer
zentralen Datenquelle verbunden ist. Diese Software wurde von Bamm Visscher geschrieben und wird als kostenlose Open-Source-Anwendung weiterentwickelt. Sie ist standardmäßig in Security Onion installiert und kann über das Sguil-Symbol auf dem Desktop
aufgerufen werden. In Abb. 9.25 sehen Sie das Hauptfenster von Sguil.
Abbildung 9.25: Das Hauptfenster von Sguil
Weitere Informationen über Sguil erhalten Sie auf http://sguil.sourceforge.net/.
9.8
Zusammenfassung
In diesem Kapitel haben wir ausführlich die signaturgestützte Erkennung mit Snort und
Suricata besprochen. Wir haben uns die Funktionsweise beider IDS-Engines
angesehen, ihre Unterschiede aufgezeigt und uns angesehen, wie Sie Erkennungsregeln
dafür schreiben können. Die signaturgestützte Erkennung war lange Zeit das Rückgrat
der Intrusion Detection und des Network Security Monitoring. Sie reicht zwar nicht als
alleinige Lösung aus, ist aber eine wichtige Komponente einer jeden NSM-Umgebung.
Im Abschnitt über die Analyse werden wir Methoden kennenlernen, um die von Snort
und Suricata generierten Alarme einzusehen und zu untersuchen.
10
Bro
Beim Network Security Monitoring geht es darum, Netzwerkdaten als Kontext für die Erkennung und Analyse zu sammeln. Die meisten NSM-Systeme schließen die drei Hauptquellen ein (IDS-Alarme, Sitzungsdaten und FPC-Daten), aber wie Sie in diesem Buch
schon gesehen haben, sind das nicht die einzigen Datenquellen, die Sie nutzen können.
Eine besonders reichhaltige Quelle ist Bro.
Bro wird häufig als IDS bezeichnet, doch wie Sie in diesem Kapitel sehen werden, wird
ihm dieser Begriff nicht gerecht. Stellen Sie sich Bro lieber als Entwicklungsplattform für
NSM-Anwendungen vor. Es bringt wesentliche vorgefertigte Funktionen zum Dekodieren und Protokollieren von Netzwerkverkehr, aber auch ein ereignisgestütztes Entwicklungsmodell mit, mit dem Sie gezielt nach Transaktionen einer bestimmten Art Ausschau
halten und eigene Skripts bereitstellen können, die bei einem solchen Ereignis ausgeführt
werden sollen.
In diesem Kapitel sehen wir uns an, wie Sie die eingebauten Protokolle von Bro verwenden, um die Aktivitäten in Ihrem Netzwerk aufzuspüren, an denen Sie interessiert sind.
Außerdem betrachten wir einige Beispiele der Bro-Programmierung, um einige der wichtigsten und nützlichsten Funktionen vorzuführen.
320 10 Bro
Vorsicht
Die Beispiele in diesem Kapitel wurden mit Bro 2.2 geschrieben, das zur Zeitpunkt der Abfassung dieses Buches noch im Beta-Stadium war. Daher ist Bro 2.2
in Security Onion nicht standardmäßig installiert. Wenn Sie die Beispiele nachvollziehen wollen, können Sie Bro 2.2 Beta nach der Anleitung auf http://www.
appliednsm.com/bro-22-on-seconion/ installieren.
10.1 Grundprinzipien von Bro
Im Gegensatz zu einem weit verbreiteten Irrglauben ist Bro kein IDS, auch wenn es
manchmal so bezeichnet wird. In Wirklichkeit handelt es sich bei Bro um eine Skriptplattform für die Arbeit mit Netzwerkverkehr. Wie Sie in den Beispielen in diesem Kapitel
sehen werden, weist die Skriptsprache von Bro (die verwirrenderweise auch Bro heißt)
äußerst nützliche Merkmale für die Protokollanalyse auf (beispielsweise sind IP-Adressen
und Ports native Datentypen). Außerdem bietet Bro eine Menge vorgefertigter Funk­
tionen für grundlegende Analyseaufgaben, darunter Protokolldekodierung, Transaktionsprotokollierung und Benachrichtigungen über einige gängige Sicherheitsereignisse.
Allerdings macht sich Bro tatsächlich auch sehr gut als IDS-Plattform, weshalb wir es in
diesem Buch behandeln. Bro ist anders als signaturgestützte IDS wie Snort und Suricata
und ergänzt sie. Die Regelsprache von Snort ist zwar gut geeignet, um bestimmte Bytes
im Netzwerkverkehr zu finden (wobei es viele Aufgaben gibt, für die wirklich nicht mehr
als das erforderlich ist), aber Bro ist oft die beste Möglichkeit, wenn es um kompliziertere
Dinge geht, etwa um Protokolle höherer Ebenen, die Arbeit über mehrere Netzwerkflüsse
hinweg oder die Verwendung eines maßgeschneiderten Algorithmus, um irgendwelche
Aspekte des zu untersuchenden Netzwerkverkehrs zu berechnen.
Eine der Stärken von Bro besteht darin, dass es alle gängigen Internetprotokolle und sogar
einige der weniger gebräuchlichen kennt. Es kann diese Protokolle im Netzwerkverkehr
auch dann erkennen, wenn sie nicht über die Standardports abgewickelt werden. Diese
Funktion wird dynamische Protokollerkennung genannt (Dynamic Protocol Detection,
DPD). Zu den Anwendungs- und Tunnelprotokollen, die Bro unterstützt, gehören u. a.
die folgenden:
••
••
••
••
••
DHCP
DNS
FTP
HTTP
IRC
10.1 Grundprinzipien von Bro 321
••
••
••
••
••
••
••
••
POP3
SMTP
SOCKS
SSH
SSL
SYSLOG
Teredo
GTPv1
Wenn Bro Netzwerkverkehr über ein Anwendungsprotokoll sieht, das es kennt, hält es die
Einzelheiten der betreffenden Transaktion in einer Datei fest. Die Art und Weise dieser
Aufzeichnung können Sie im Einzelnen einstellen, aber das ist noch nicht alles. Wenn Bro
den Datenverkehr verarbeitet und dekodiert, stellt es einen Mechanismus bereit, mit dessen Hilfe Sie eigenen Code zur Verarbeitung der Transaktionen in diesem Datenverkehr
schreiben können. Die Aktionen, die das Protokoll ausführt, werden von Bro als eine Folge
von Ereignissen betrachtet, für die Sie Ereignishandler in Bro-Code schreiben können.
Wenn das Ereignis, für das Sie einen Handler registriert haben, im Netzwerkverkehr auftritt, ruft Bro Ihren Code dafür auf. In diesen Handlern können Sie praktisch alles tun,
was Sie wollen, und Sie können so viele Handler vorhalten, wie Sie wollen. Es ist sogar
möglich, mehrere Handler für ein und dasselbe Ereignis einzurichten, etwa wenn Sie ein
Protokoll auf verschiedene Arten von Verhalten untersuchen.
Der folgende Bro-Beispielcode zeigt einen sehr einfachen Handler für das Ereignis http_
request. Bro generiert dieses Ereignis, wenn ein HTTP-Client eine Anforderung an einen
Server stellt. Der Code gibt den vom Client angeforderten URL an der Konsole aus (Standardausgabe). Natürlich wäre diese Vorgehensweise in der Produktion nicht sehr sinnvoll.
Weiter hinten in diesem Kapitel sehen wir uns einige praxisnahe Beispiele an, aber hier
geht es nur darum zu zeigen, dass Sie lediglich den Code in ein Skript aufnehmen müssen,
das in Bro geladen wird (wie das geschieht, wird ebenfalls weiter hinten erklärt). Dadurch
wird der Ereignishandler registriert und der Code von Bro aufgerufen, sobald eine HTTPAnforderung auftritt.
#
# Dies ist ein Beispiel-Ereignishandler für HTTP-Anforderungen
#
event http_request(c: connection, method: string, orig_uri: string,
unescaped_uri: string, version: string) {
print fmt("HTTP request found for %s", orig_uri);
}
322 10 Bro
10.2 # ausführen
Die einfachste Möglichkeit zur Verwendung von Bro besteht darin, es an der Befehlszeile
auszuführen und es eine PCAP-Datei nach seiner Standardkonfiguration verarbeiten zu
lassen. Dazu verwenden Sie folgenden Befehl:
bro -C -r file.pcap
Das Argument -r file.pcap weist Bro an, die Pakete in der Datei file.pcap zu lesen. Mit der
Option -C wird die interne Prüfsummenverifizierung von Bro ausgeschaltet. Jedes IP-Paket
verfügt über eine Prüfsumme, mit der es möglich ist festzustellen, ob es korrekt empfangen
wurde. Dies ist für eine ordnungsgemäße Übertragung im Netzwerk unverzichtbar, und jeder Host überprüft standardmäßig die Prüfsummen. Immer mehr Netzwerkkarten weisen
jedoch eine Funktion namens »TCP Checksum Offloading« auf, bei der diese Überprüfung von der Hardware der Netzwerkkarte durchgeführt wird, wodurch die CPU die Verarbeitungszyklen dafür einsparen kann. Bei Geschwindigkeiten im Bereich von Gigabit pro
Sekunde kann das einen großen Unterschied ausmachen. Wenn die Pakete das Betriebssystem erreichen, wo sie von Libpcap (oder einem anderen Treiber zur Paketerfassung)
gelesen werden können, kann es deswegen jedoch vorkommen, dass Prüfsummenwerte
fehlen oder inkorrekt sind. In der Standardeinstellung ignoriert Bro Pakete mit ungültigen
Prüfsummen, doch mit der Option -C können Sie es zwingen, den Prüfsummentest zu
überspringen und sämtliche Pakete zu verarbeiten. Das sollten Sie praktisch immer tun,
insbesondere, wenn Sie PCAP-Dateien von Systemen empfangen, bei denen Sie sich nicht
sicher sind, ob das Checksum Offloading aktiviert ist. Wenn Sie die Netzwerkschnittstellen Ihres Laborsystems mit dem Setupskript von Security Onion automatisch konfiguriert
haben, dann ist die Offloading-Funktion an der Überwachungsschnittstelle ausgeschaltet.
Bei den meisten anderen Systemen ist sie aber standardmäßig aktiviert.
10.3 Bro-Protokolle
Bro ist standardmäßig so eingerichtet, dass es eine ausführliche Protokollierung vornimmt. In dieser Phase sucht es gar nicht einmal besonders nach schädlichen Dingen (wie
ein IDS es tun würde), sondern erstellt lediglich sehr detaillierte Protokolle über das, was
es sieht. Abb. 10.1 zeigt ein einfaches Beispiel dafür, wie Bro eine einzelne PCAP-Datei verarbeitet. Zu Anfang ist das Verzeichnis leer, aber als Ergebnis der Untersuchung der Datei
erstellt Bro mehrere Protokolldateien und ein neues Verzeichnis.
Abbildung 10.1: Bei der Verarbeitung einer PCAP-Datei erstellt Bro Protokolldateien
10.3 Bro-Protokolle 323
Aus den Namen der Protokolldateien können Sie schließen, dass Bro in der PCAP-Datei
DNS-, FTP-, HTTP- und SSL-Datenverkehr gefunden hat. Die Inhalte der restlichen Dateien sind weniger offensichtlich. Conn.log enthält eine Aufzeichnung der Netzwerkverbindungen (Flüsse) und files.log eine Aufzeichnung aller übertragenen Dateien (hier über
HTTP oder FTP, einschließlich aller HTML-Bilder und sonstigen eingebetteten Medien,
aus denen sich der Webdatenverkehr zusammensetzt). In packet_filter.log dagegen ist lediglich der BPF-Filter zu finden, den Bro verwendet (der Standardfilter ist ip or not ip,
was letzten Endes heißt: »alle Pakete«). In weird.log zeichnet Bro ungewöhnliche Ereignisse aller Protokolle auf, wobei allerdings die Vorstellung von Bro, was »ungewöhnlich«
ist, nicht unbedingt mit Ihrer übereinstimmen muss. Schließlich haben wir noch das Verzeichnis extract_files, das zurzeit noch leer ist. Darüber werden wir weiter hinten noch
sprechen.
Wenn Sie eine dieser Protokolldateien öffnen, stellen Sie fest, dass es sich um eine tabulatorgetrennte Textdatei handelt. Die ersten Zeilen enthalten interne Bro-Metadaten, die
die Felder und deren Datentypen beschreiben, die Erstellungszeit der Datei angeben und
einige weitere Informationen, die aber nicht besonders nützlich sind. Um sich mit einem
neuen Typ von Bro-Protokolldatei vertraut zu machen, mit dem Sie zuvor noch nichts zu
tun hatten, ist es jedoch hilfreich, die als fields und types gekennzeichneten Zeilen zu
studieren. Auf die Metadaten folgen dann die eigentlichen Protokolle, wobei jede Zeile ein
Protokoll darstellt.
In Abb. 10.2 sehen Sie einen Teil der Datei http.log. Er zeigt einige der HTTP-Transaktionen,
die Bro in der PCAP-Datei erkannt hat.
Abbildung 10.2: Ausschnitt aus der Datei http.log
Dies ist nur ein Ausschnitt, und zwar in beiden Richtungen. Erstens gibt es zu viele Einträge, um alle in einem Fenster darzustellen, weshalb hier nur der Anfang der Datei zu sehen
ist. Vor allem aber sind die einzelnen Einträge sehr lang und gehen über den rechten Rand
des Fensters hinaus. Aufgrund dieser Länge ist es sehr schwer, eine Protokolldatei in einem
druckfähigen Format zu zeigen. Tabelle 10.1 gibt einen Überblick über einige der wichtigsten Felder, die gewöhnlich in http.log zu finden sind. Beachten Sie, dass es nicht nur
möglich, sondern auch üblich ist, diese Standardprotokolldateien in Abhängigkeit von
den Skripten, die Sie in Ihrer Bro-Instanz ausführen, um zusätzliche Felder zu erweitern.
324 10 Bro
Tabelle 10.1: Felder in http.log
Feld
Beschreibung
ts
Zeitstempel des Ereignisses
uid
Eindeutige ID für den Fluss, der die betreffende Transaktion
enthält
id.orig_h
Quellhost
id.orig_p
Quellport
id.resp_h
Zielhost
id.resp_p
Zielport
trans_depth
Position der Transaktion in der HTTP-Pipeline
method
HTTP-Verb für die Transaktion
host
Wert des HTTP-Headers für den Host
uri
Pfad der Anforderung
referrer
Wert des HTTP-Headers für den Referrer
user_agent
Wert des HTTP-Headers für den Benutzer-Agenten
request_body_len
Länge des Anforderungsrumpfes
response_body_len
Länge des Antwortrumpfes
status-code
Numerischer HTTP-Antwortstatus
status_msg
Für Menschen lesbare HTTP-Statusmeldung
filename
Name der heruntergeladenen Datei nach Angabe des Servers
username
Benutzername der einfachen HTTP-Authentifizierung
password
Passwort der einfachen HTTP-Authentifizierung
orig_fuids
Liste der eindeutigen Datei-IDs in der Anforderung (siehe
files.log)
orig_mime_types
MIME-Typen der Anforderungsobjekte
resp_fuids
Liste der eindeutigen Datei-IDs in der Antwort
resp_mime_types
MIME-Typen der Antwortobjekte
10.3 Bro-Protokolle 325
Bericht von der Front
Wenn Sie andere Paket- oder Flussanalysewerkzeuge wie Tcpdump, Wireshark
oder Snort gewohnt sind, fragen Sie sich wahrscheinlich, wo die IP-Adressen und
Ports von Quelle (»source«) und Ziel (»destination«) in Bro zu finden sind. Sie sind
da, aber Bro nennt sie Urheber (»originator«) und Antwortender (»responder«).
Die Felder für die Quell-IP-Adressen und -Ports tragen daher die Bezeichnungen
orig_h und orig_p, und diejenigen für die Zieladressen und -ports die Bezeichnungen resp_h und resp_p. Allerdings werde ich in diesem Kapitel wie auch im
ganzen Rest dieses Buches die üblichen Begriffe »Quelle« und »Ziel« verwenden.
Wenn Ihnen das alles ein bisschen zu viel für eine Protokolldatei erscheint, dann haben Sie
damit Recht. Um die Antwort auf eine bestimmte Frage zu finden, brauchen Sie praktisch
nie alle über 25 Felder. Meistens ist es viel bequemer, einfach die Felder zu entnehmen,
an denen Sie wirklich interessiert sind. Zum Glück gibt es dafür einen praktischen BroBefehl, nämlich bro-cut.
Die einfachste Möglichkeit, diesen Befehl zu verwenden, besteht darin, im Terminal eine
Protokolldatei mit cat auflisten zu lassen und das Ergebnis mit dem Pipe-Symbol an
bro-cut zu übergeben. Dabei können Sie genau die Felder angeben, die Sie haben wollen
(siehe Abb. 10.3).
Abbildung 10.3: Einfache Ausgabe von bro-cut
Hier haben wir angegeben, dass wir nur die Felder ts, uid, method und hosts sehen wollen.
Nützliche Optionen für bro-cut sind unter anderem -C (um alle Metadaten der Protokolldatei einzuschließen, ohne sie einzeln aufführen zu müssen) und -u (um Zeitstempel im
UTC-Format wiederzugeben). Letzteres sehen Sie in Abb. 10.4.
326 10 Bro
Abbildung 10.4: Ausgabe von bro-cut mit Zeitstempeln in einem für Menschen lesbaren Format
Bis jetzt haben wir uns nur mit einer der Protokolldateien beschäftigt. Es gibt aber noch
viele andere, und sie sind alle miteinander verknüpft. Beispielsweise gehören alle in http.
log aufgeführten HTTP-Transaktionen zu Netzwerkflüssen in der Datei conn.log, wobei
viele dieser Flüsse wiederum mit DNS-Lookups für die Zielhosts in der Datei dns.log
verknüpft sind. Wenn Sie sich die letzten Screenshots genauer ansehen, finden Sie darin
überall dasFeld uid. Bro nutzt an verschiedenen Stellen diese eindeutigen Bezeichner, um
verwandte Protokolleinträge aus unterschiedlichen Dateien miteinander zu verknüpfen.
Daher sollten Sie bei der Untersuchung von Bro-Protokollen dieses Feld einschließen, um
schnell in den anderen Protokolldateien nachschlagen zu können.
Nehmen wir beispielsweise an, Sie wollen mehr über die HTTP-Transaktion erfahren, die
in der ersten Zeile von Abb. 10.4 aufgeführt ist. In der zweiten Spalte ist der eindeutige Bezeichner für den Netzwerkfluss angegeben, der diese Transaktion enthält. Wenn Sie in allen
Protokolldateien nach diesem String suchen, finden Sie mehrere verschiedene Arten von
Protokolleinträgen (siehe Abb. 10.5). Die Datei http.log zeigt, dass mit dem betreffenden
Fluss zwei HTTP-Transaktionen verknüpft sind. Das ist das ganz normal, da HTTP häufig
mehrere Transaktionen über eine einzige Netzwerkverbindung sendet, um nicht ständig
TCP-Sitzungen aufbauen und wieder beenden zu müssen. Laut der Datei files.log wurden
bei diesen Transaktionen eine Textdatei und ein GIF-Bild abgerufen. Wenn Sie mehr über
die Netzwerksitzung selbst in Erfahrung bringen wollen, finden Sie sie in conn.log.
Viele Bro-Protokolle enthalten mehr als nur ein ID-Feld. So gibt es in den HTTP-Protokollen nicht nur das Feld uid mit dem Bezeichner der jeweiligen Verbindung, sondern
auch das Feld resp_fuids mit einem Verweis auf eine Liste der IDs von Dateien, die in
der Transaktion heruntergeladen wurden. Anhand dieser IDs können Sie Transaktionen
miteinander verknüpfen und zwischen verschiedenen Arten von Transaktionen wechseln,
während Sie die Protokolle untersuchen.
10.4 Eigene Erkennungswerkzeuge mit Bro erstellen 327
Abbildung 10.5: Zusammengehörige Bro-Protokolldateien aufgrund der Transaktions-ID finden
10.4 Eigene Erkennungswerkzeuge mit Bro erstellen
Bis jetzt haben wir uns nur mit den Protokolldateien beschäftigt, aber Bro ist mehr als nur
eine Protokollierungsplattform, sondern eine Allzweck-Programmiersprache, bei der der
Schwerpunkt bewusst auf die Verarbeitung von Netzwerkverkehr gelegt wurde. Die Protokollierung ist nur ein Nebenprodukt der ausgiebigen Zerlegung und Normalisierung, die
Bro zur Vorbereitung der Daten für die von Ihnen geschriebenen Programme vornimmt.
Gehen wir nun also zum interessanten Teil über und schreiben wir mithilfe von Bro ein
Tool, das uns bei der Erfassung, Erkennung und Analyse helfen kann.
Im weiteren Verlauf dieses Kapitels werden wir noch oft genug erwähnen, wie großartig
Bro ist, allerdings bietet sich hier die Gelegenheit, etwas anzusprechen, was die Bezeichnung »großartig« leider nicht verdient, nämlich die Dokumentation von Bro.
Im letzten Jahr hat es zwar einige Verbesserungen gegeben, aber das Bro-Team konzentriert sich fast ausschließlich auf die Arbeit an der Plattform selbst und erübrigt kaum
Zeit, um die Verwendung zu dokumentieren, außer in Form von Beispielen. Das gilt
in besonderem Maße für die Programmiersprache Bro. Es gibt zwar eine rudimentäre
Dokumentation (darunter eine Erklärung der integrierten Datentypen und eine knappe
Übersicht der im Lieferumfang inbegriffenen Ereignisse und Funktionen), aber kein umfassendes Tutorial für angehende Brogrammierer.
Die Skripterstellung mit Bro erlernen die meisten dadurch, dass sie vorhandenen Code
studieren. Dazu können Sie die umfassende Sammlung von Skripten verwenden, die
zusammen mit Bro geliefert wird (zu finden in /opt/bro/share/bro und den Unterverzeichnissen von Security Onion), aber auch Code von den Mailinglisten oder von
Codesharing-Websites wie GitHub herunterladen.
Um Sie darauf vorzubereiten, gehen wir in den Beispielen in diesem Kapitel auf die gleiche
Weise vor. Anstatt alles, was Sie mit Bro anstellen können, von A bis Z aufzulisten, untersuchen wir den Code einiger nützlicher Skripte und stellen dabei die wichtigen Prinzipien
von Bro vor, die sich in dem Code zeigen. Beim Durcharbeiten dieses Kapitels kann es hilfreich sein, in der Online-Dokumentation auf http://www.bro.org/documentation/­index.
html nachzuschlagen. Diese Vorgehensweise entspricht auch der Art und Weise, wie Sie
328 10 Bro
später eigenständig lernen werden: Sie finden neue, interessante Einzelheiten in vorhandenem Bro-Code und versuchen herauszufinden, wie sie funktionieren.
10.4.1 Dateien extrahieren
Eine gängige Aufgabe beim Network Security Monitoring besteht darin, die in einer Sitzung übertragenen Dateien zu extrahieren. Es gibt zwar Werkzeuge, um Dateien aus einer
PCAP-Datei zu entnehmen (z. B. Tcpxtract), aber sie arbeiten gewöhnlich auf Byteebene
ohne Kenntnis des zugrunde liegenden Protokolls. Wenn Sie beispielsweise den Beginn
einer PDF-Datei erkennen, können Sie gewöhnlich die nächsten paar tausend Byte abschöpfen und auf der Festplatte speichern, aber das stellt nur eine Annäherung der Datei
dar, die tatsächlich übertragen wurde. Es kann nötig sein, manuell nachzuarbeiten, um die
Datei zu bekommen, die Sie haben wollten.
Bro dagegen kennt die Protokolle, die es dekodiert, und das macht einen großen Unterschied aus. In unserem ersten Beispiel sehen wir uns eine Methode an, mit Bro Dateien
aus erfassten Paketen zu entnehmen. Dazu entwickeln wir zunächst ein Tool, das von der
Befehlszeile aus für eine einzelne PCAP-Datei aufgerufen wird, und zeigen dann, wie Sie
dieses Werkzeug in die Bro-Instanz in Security Onion aufnehmen, sodass es ständig läuft
und den Netzwerkverkehr live verarbeitet.
Als Erstes erstellen wir einen einfachen Prototyp. Mit dem so genannten File Analysis
Framework verfügt Bro über einen eingebauten Mechanismus, um die Dateien, die über
die Verbindung übertragen werden, im laufenden Betrieb zu analysieren. Eine der möglichen Arten von »Analyse«, die dieses Framework beherrscht, besteht darin, die Datei auf
die Festplatte zu schreiben. Sie müssen Bro nur anweisen, dies für jede Datei zu tun, an
der Sie interessiert sind.
Zum Glück lässt sich das viel einfacher erledigen, als es klingt. Erstellen Sie die Datei
extract-files.bro mit folgendem Code als Inhalt:
# Wenn Bro eine Datei findet, die (über ein ihm bekanntes Protokoll)
# übertragen wird, wird eine einfache Meldung in die Standardausgabe
# geschrieben und Bro angewiesen, die Datei auf der Festplatte zu speichern.
event file_new(f: fa_file)
{
local fuid=f$id;
local fsource=f$source;
local ftype=f$mime_type;
local fname=fmt("extract-%s-%s", fsource, fuid);
print fmt("*** Found %s in %s. Saved as %s. File ID is %s", ftype,
fsource, fname, fuid);
Files::add_analyzer(f, Files::ANALYZER_EXTRACT,
[$extract_filename=fname]);
}
10.4 Eigene Erkennungswerkzeuge mit Bro erstellen 329
Dieses Skript erstellt einen Handler für das Ereignis file_new, das Bro jedes Mal generiert,
wenn es den Beginn einer neuen Dateiübertragung erkennt, und zwar unabhängig vom
verwendeten Protokoll. Der einzige Parameter, den Bro dabei übergibt, ist f. Er ist vom
Typ fa_file, einem vom Framework definierten Datensatztyp. Beachten Sie, dass in Bro
ein Dollarzeichen verwendet wird, um auf die Felder in dem Datensatz zu verweisen. Damit greift das Skript auf die Felder id, source und mime_type zu, um eine kurze Meldung
über die einzelnen gefundenen Dateien zusammenzustellen und auszugeben. Anschließend hängt es den Dateiextraktionsanalysator an den Stream an. Diese Komponente ist
es, die Bro anweist, die Datei auf der Festplatte zu speichern. Das war es auch schon!
Nachdem ANALYZER_EXTRACT an die Datei angehängt worden ist, kümmert sich Bro um
den ganzen Rest.
Jetzt müssen Sie dieses Skript nur noch an einer PCAP-Datei ausführen. Bro-Skripte werden auf ähnliche Weise ausgeführt wie Bro selbst, aber hier müssen wir nur den Namen
der Skriptdatei am Ende der Befehlszeile angeben. Es ist sogar möglich, mehrere BroSkripte auszuführen, indem wir sie alle in ein und derselben Befehlszeile angeben. Hier
allerdings ist das nicht nötig. Der erforderliche Befehl lautet wie folgt:
bro –C –r ../pcaps/bro-sample-traffic.pcap ../scripts/extract-files.bro
Abb. 10.6 zeigt die Ausführung dieses Skripts. Jede Zeile enthält die ID der gerade verarbeiteten Datei. Das ermöglicht es Ihnen, weitere Informationen in den entsprechenden
Protokolleinträgen in files.log nachzuschlagen.
Abbildung 10.6: Ausgabe eines einfachen Dateiextraktors
Nachdem Sie das Skript ausgeführt haben, stehen Ihnen die gleichen Protokolldateien zur
Verfügung, die Bro auch in den vorherigen Beispielen angelegt hat. Alles sieht genauso aus
wie in den früheren Versuchen, doch diesmal befinden sich Dateien im Unterverzeichnis
extract_files, wie Sie in Abb. 10.7 sehen.
330 10 Bro
Abbildung 10.7: Die extrahierten Dateien
10.4.2 Selektive Dateiextraktion
In der Beispielausgabe können Sie sehen, dass in der von mir verwendeten PCAP-Datei
sehr viele GIF- und auch einige HTML-Dateien enthalten waren. Sie stammen aus dem
gewöhnlichen Webdatenverkehr und sind eigentlich nicht das, was man sich unter »heruntergeladenen Dateien« vorstellt. Was tun, wenn Sie an diesen Dateitypen nicht interessiert sind, sondern beispielsweise nur ausführbare Windows-Dateien entnehmen wollen?
Kein Problem! Wie Sie in unserem vorherigen Codebeispiele sehen konnten, kennt Bro
den MIME-Typ der einzelnen Dateien. Dabei findet es diesen Typ durch Untersuchung
der Datei heraus, anstatt sich auf das zu verlassen, was das Übertragungsprotokoll angibt.
Bericht von der Front
MIME steht für Multipurpose Internet Mail Extensions. MIME wird für E-Mails
(und inzwischen auch für HTTP und andere Protokolle) verwendet, um eine einzige Nachricht aus mehreren Teilen zusammenzusetzen. Wenn Sie eine E-Mail mit
einem Anhang erhalten, dann handelt es sich dabei um eine MIME-Nachricht.
Das wahrscheinlich am häufigsten genutzte Merkmal der MIME-Spezifikation ist
die Verwendung von Typen, um zu beschreiben, welche Art von Inhalt die einzelnen Teile der Nachricht haben. Sogar viele Nicht-MIME-Anwendungen nutzen
MIME-Typen, um die Daten zu beschreiben, die sie verarbeiten.
In HTTP wird für bestimmte Arten von Transaktionen, bei denen mehrere
Datenabschnitte auf einmal gesendet werden (z. B. die Übermittlung von Formularen mit der Methode POST), eine MIME-Formatierung verwendet. HTTP
nutzt zwar nicht das komplette MIME-Format, doch fast alles in HTTP wird mit
einem MIME-Typ gekennzeichnet. Zu den am häufigsten auftretenden Werten
gehören text/html, text/plain und image/gif. Es gibt viele andere, aber die Liste
ist zu lang, um sie alle hier aufzuführen.
10.4 Eigene Erkennungswerkzeuge mit Bro erstellen 331
Wir können unser bisheriges Skript nun so verfeinern, dass es zunächst den MIME-Typ
einer Datei überprüft und auf dieser Grundlage entscheidet, ob der Extraktionsanalysator
angehängt werden soll oder nicht.
#!/usr/bin/env bro
# Wenn Bro eine Datei findet, die (über ein ihm bekanntes Protokoll)
# übertragen wird, wird eine einfache Meldung in die Standardausgabe
# geschrieben und Bro angewiesen, die Datei auf der Festplatte zu speichern.
event file_new(f: fa_file)
{
# Prüft, ob in dem Datensatz ein Wert für den MIME-Typ angegeben ist
if (f?$mime_type) {
# Prüft, ob es einer der Typen ist, für die wir uns interessieren
if(f$mime_type == "application/x-dosexec" ||
f$mime_type == "application/x-executable") {
local ftype=f$mime_type;
local fuid=f$id;
local fsource=f$source;
local fname=fmt("extract-%s-%s", fsource, fuid);
print fmt("*** Found %s in %s. Saved as %s. File ID
is %s", ftype, fsource, fname, fuid);
Files::add_analyzer(f, Files::ANALYZER_EXTRACT,
[$extract_filename=fname]);
}
}
}
Diese Version ähnelt der ersten, enthält aber eine zusätzliche if-Anweisung, um zu
prüfen, ob in dem Dateidatensatz ein MIME-Typ angegeben ist (f?$mime_type). Wenn
ja, wird der MIME-Typ untersucht und auf dieser Grundlage entschieden, ob der Extraktionsanalyser angewendet wird. Abb. 10.8 zeigt die Ausgabe dieses Skripts. Hier
wurden alle Bilder und HTML-Inhalte übergangen und nur die ausführbaren Dateien
verarbeitet.
Abbildung 10.8: Extraktion ausschließlich von ausführbaren Windows-Dateien
Sehen wir uns nun einen kleinen Trick an, mit dem wir Bro-Code noch auf eine andere
Weise ausführen können. Bis jetzt haben wir ausdrücklich den Befehl bro gegeben und
dahinter das gewünschte Skript aufgeführt. Die erste Zeile unseres neuen Skripts beginn
aber mit dem Unix-typischen »Shebang«-Symbol #!. Das bedeutet, dass es sich hierbei
332 10 Bro
um ein zwar in Bro geschriebenes, aber trotzdem eigenständiges Programm handelt, dass
Sie ebenso an der Befehlszeile ausführen können wie ein Skript in einer anderen Sprache.
Dazu müssen Sie noch die Berechtigungen des Skripts ändern, sodass es ausführbar wird:
chmod 755 extract-exe-files.bro
Jetzt können Sie dieses Skript wie jeden anderen Befehl ausführen (siehe Abb. 10.9), wobei
es sich genauso verhält wie zuvor: Es legt Protokolldateien an und schreibt die extrahierten Dateien auf die Festplatte. Dies ist nur eine andere und häufig bequemere Möglichkeit,
den Code auszuführen, vor allem, wenn Sie Ihr Tool anderen Analytikern zur Verfügung
stellen, die mit Bro selbst nicht vertraut sind.
Abbildung 10.9: Aufruf des Skripts als Befehl
10.4.3 Dateien aus laufendem Netzwerkverkehr entnehmen
Nachdem wir unser Skript als eigenständiges Tool verbessert haben, wollen wir uns als
Nächstes ansehen, wie wir es kontinuierlich in der Bro-Instanz von Security Onion ausführen. Das wäre praktisch, um jegliche Dateien eines bestimmten Typs zu extrahieren,
sobald sie über das Netzwerk übertragen werden, anstatt im Nachhinein PCAP-Dateien
danach zu durchsuchen.
Wenn Sie erst einmal ein funktionierendes Bro-Skript haben, ist es gewöhnlich nicht mehr
sehr schwierig, es kontinuierlich ausführen zu lassen. Wird Bro von Security Onion im
Sensormodus ausgeführt, so bezieht es seine Konfiguration standardmäßig aus /opt/bro/
share/bro/site/local.bro, wobei wir den Begriff »Konfiguration« hier im weitesten Sinne
verwenden. Local.bro ist ein Skript, das Bro beim Start lädt und ausführt. Die im Liefer­
umfang von Security Onion enthaltene Standardversion dieser Datei lädt weitere BroSkripts nach, die einige nützliche Funktionen ausführen und z. B Scans erkennen, die im
Netzwerk ausgeführte Anwendungen protokollieren, GeoIP-Lookups zu den Aufzeichnen
bestimmter Übertragungsprotokolle hinzufügen usw. Da local.bro die »lokale« Konfiguration von Bro darstellt, müssen Sie darin auch Ihre eigenen Anpassungen hinzufügen. Die
einfachste Möglichkeit, den Dateiextraktionscode zu Bro hinzuzufügen, besteht darin, ihn
vollständig ans Ende der Datei local.bro zu kopieren, wie Sie in Abb. 10.10 sehen.
10.4 Eigene Erkennungswerkzeuge mit Bro erstellen 333
Abbildung 10.10: Hinzufügen des Dateiextraktionscodes zu local.bro
Wenn Sie Änderungen an local.bro vornehmen, müssen Sie anschließend drei einfache
Schritte ausführen, um die laufende Bro-Instanz darauf aufmerksam zu machen. Bei jedem dieser Schritte verwenden Sie das Bro-Steuerprogramm broctl. Die Befehle für die
einzelnen Schritte lauten wie folgt:
1. broctl check
Damit führen Sie eine schnelle Syntax- und Konsistenzüberprüfung der gesamten
Konfiguration durch, um sich zu vergewissern, dass Sie nicht versehentlich etwas beschädigt haben.
2. broctl install
Hiermit werden die Konfigurationsänderungen in Kraft gesetzt oder »installiert«.
3. broctl restart
Dieser Befehl startet Bro neu, damit die Änderungen gelesen werden.
Abb. 10.11 zeigt diese Befehle und deren Ausgabe.
334 10 Bro
Abbildung 10.11: Inkraftsetzen von Änderungen mit broctl
Wenn Ihr neuer Code eine Weile läuft, werfen Sie einen Blick in das Bro-Protokollverzeichnis /nsm/bro/logs/current und untersuchen Sie die Datei files.log, um sich anzusehen,
ob und wenn ja welche Dateien extrahiert worden sind. Im Feld analyzers können Sie
erkennen, auf welche Dateien der Analysator EXTRACT angewandt wurde (siehe Abb. 10.12).
Abbildung 10.12: Eine Datei wurde extrahiert!
Nach der Stringausgabe der extrahierten Binärdatei zu urteilen, handelt es sich hierbei um
eine Kopie des Windows-SSH-Clients PuTTY.
Ein Neustart von Bro führt übrigens dazu, dass alle zurzeit in /nsm/bro/logs/current befindlichen Protokolle archiviert werden und ein neuer Satz angelegt wird. Das geschieht
auch automatisch jede Nacht (um 0.00 Uhr GMT in der Standardkonfiguration von Security Onion). Wenn Sie die Beispiele durcharbeiten, sollten Sie daher nicht überrascht sein,
wenn einige Ihrer alten Protokolle nach einem Neustart von Bro oder von Security Onion
oder nach gewisser Zeit einfach von selbst scheinbar verschwinden. Die Protokolle sind
nach wie vor vorhanden, allerdings hat Bro sie in ein Unterverzeichnis von /nsm/bro/logs
verschoben. Der Name dieses Unterverzeichnisses spiegelt das Datum wider.
10.4 Eigene Erkennungswerkzeuge mit Bro erstellen 335
10.4.4 Bro-Code verpacken
Wir haben Bro jetzt so eingerichtet, dass es ausführbare Dateien im laufenden Betreib aus
dem Netzwerkstream entnimmt, was eine äußerst nützliche Funktion ist. Diese Dateien
können anschließend auf Anzeichen von Schadlogik untersucht oder für eine statistische
Analyse zusammengestellt werden. Es ist auch möglich, Informationen über diese Dateien
zur weiteren Analyse wieder in Bro zurückzuleiten. Das funktioniert zwar alles sehr gut,
aber wir können noch etwas mehr tun, nämlich unseren Code in eine eigene Datei packen.
Wenn Sie ständig neuen Code direkt in local.bro hineinschreiben, macht das die Handhabung im Laufe der Zeit immer schwerer. Um Ihre Skripte an andere Bro-Benutzer
weiterzugeben, müssten Sie außerdem Unmengen von Änderungen durchkämmen, die
gar nichts damit zu tun haben, und sorgfältig darauf achten, dass Sie nur die Zeilen entnehmen, die Sie wirklich weitergeben wollen. Nach einer Weile dürfte sich das zu einem
Verwaltungsalbtraum auswachsen.
Wenn Sie sich den Rest von local.bro ansehen (also den Teil, den wir nicht bearbeitet haben), werden Sie feststellen, dass dieses Skript nichts anderes macht, als andere Skripte zu
laden, die in eigenen Dateien gespeichert sind. Genau das können wir auch mit unserem
Code tun!
Das ist sogar äußerst einfach. Schneiden Sie dazu den gesamten Code Ihres Skripts in
local.bro aus, fügen Sie ihn in eine neue Datei namens extract-interesting-files.bro ein und
stellen Sie diese Datei dann in das Verzeichnis /opt/bro/share/bro/site. Da es sich dabei um
den Standardladepfad von Bro handelt, können wir einfach die folgende Anweisung in
local.bro schreiben, damit unser Skript wie zuvor ausgeführt wird:
@load extract-interesting-files
Wenn Sie nun mit broctl die Konfiguration überprüfen und installieren und die BroInstanz neu starten, funktioniert alles wie zuvor, aber der Code lässt sich jetzt viel einfacher finden, verwalten und weitergeben.
10.4.5 Konfigurationsoptionen hinzufügen
Unser Code ist jetzt auf eine viel sauberere Weise gespeichert, aber es stellt sich immer
noch das Problem, dass wir das Skript bearbeiten müssen, wenn wir andere Dateitypen
extrahieren wollen. Das erschwert es, die Übersicht über Änderungen an der Funktion zu
behalten, und kann sogar dazu führen, dass sich Fehler einschleichen.
Für die endgültige Version fügen wir unserem Skript den Konfigurationsparameter
­interesting_types hinzu, den wir auf die Strings für die MIME-Typen setzen, an denen
wir interessiert sind. Wenn Bro eine Datei mit einem dieser MIME-Typen sieht, schreibt es
sie auf die Festplatte. Diesen Parameter richten wir so ein, das wir seinen Inhalt mit einem
anderen Skript ändern können, ohne die Skriptdatei für unser Programm bearbeiten zu
müssen.
336 10 Bro
Die neue Version der Datei extract-interesting-files.bro sieht damit wie folgt aus:
#
# Ein Modul, um Dateien des gewünschten MIME-Typs zu finden und auf die
# Festplatte zu schreiben
#
module ExtractFiles;
export {
const interesting_types: set[string]=[
"application/x-dosexec",
"application/x-executable"
] &redef;
}
event file_new(f: fa_file)
{
# Prüft, ob in dem Datensatz ein Wert für den MIME-Typ angegeben ist
if (f?$mime_type) {
# Prüft, ob es einer der Typen ist, für die wir uns interessieren
if(f$mime_type in interesting_types) {
local ftype=f$mime_type;
local fuid=f$id;
local fsource=f$source;
local fname=fmt("extract-%s-%s", fsource, fuid);
print fmt("*** Found %s in %s. Saved as %s. File ID is %s", ftype,
fsource, fname, fuid);
Files::add_analyzer(f, Files::ANALYZER_EXTRACT,
[$extract_filename=fname]);
}
}
}
Schon auf den ersten Blick fällt auf, dass wir diesen Code jetzt als »Modul« namens
­ExtractFiles deklarieren. In Bro werden Module praktisch genauso angewandt wie in anderen Sprachen: Sie stellen einen neuen Namensraum für Funktionen und Variablen zur
Verfügung, der vom Hauptnamensraum getrennt ist, um Namenskonflikte zu vermeiden.
Standardmäßig sind diese Namen privat und gelten nur in dem Modul. Um sie in anderen
Namensräumen verfügbar zu machen, müssen wir für diese Variablen und Konstanten die
Exportdirektive verwenden.
Hier exportieren wir jedoch nur einen Namen, nämlich die Konstante interesting_types,
die als Stringmenge definiert ist. Eine Menge (set) ist in Bro eine ungeordnete Zusammenstellung von Elementen des angegebenen Typs. Sie können Elemente zu einer Menge hinzufügen und entfernen, und Sie können prüfen, ob ein gegebenes Element zu der Menge
10.4 Eigene Erkennungswerkzeuge mit Bro erstellen 337
gehört oder nicht. Das einzig Ungewöhnliche hier besteht darin, dass interesting_type
zwar eine »Konstante« ist, am Ende der Deklaration aber trotzdem &redef steht. Damit
können Sie die Inhalt der Konstante ändern, wozu Sie allerdings die besondere Anweisung redef einsetzen müssen. Dadurch verhindert Bro, dass Sie aufgrund eines Bugs im
Code oder eines anderen Fehlers versehentlich einen wichtigen Konfigurationsparameter
ändern. Wie wir eine solche Änderung bewusst wahrnehmen, sehen wir uns in Kürze an.
Als letzte Änderung an unserem Code ersetzen wir die Bedingung, die prüft, ob der vorliegende MIME-Typ einer derjenigen ist, für die wir uns interessieren. Bislang hatten wir
die gewünschten Typen hartkodiert:
if(f$mime_type =="application/x-dosexec" ||
f$mime_type =="application/x-executable") {
Das haben wir jetzt dadurch vereinfacht, dass nur noch geprüft wird, ob der vorliegende
MIME-Typ ein Element der Menge interesting_type ist:
if(f$mime_type in interesting_types) {
Da wir local.bro bereits die entsprechende @load-Anweisung hinzugefügt haben, sind wir
schon so gut wie startbereit. Zuvor wollen wir uns jedoch noch ansehen, wie Sie neue zu
extrahierende Datentypen hinzufügen. In Security Onion besteht die Bro-Datenbank der
bekannten MIME-Typen aus Textdateien im Verzeichnis /opt/bro/share/magic. In Abb. 10.13
sehen Sie, wie Sie local.bro ändern müssen, um weitere MIME-Typen (hier GIF und HTML)
zu den »interessanten Typen« hinzuzufügen: Mit dem Schlüsselwort redef werden zwei
neue Werte in die »konstante« Menge aufgenommen. (Da wir vom Haupt­namensraum aus
vorgehen, müssen wir die Menge als ExtractFiles::interesting_types ansprechen.)
Abbildung 10.13: Ändern der Konfigurationsdatei, um weitere zu extrahierende MIME-Typen
hinzuzufügen
338 10 Bro
Verwenden Sie broctl, um die neue Konfiguration zu überprüfen und zu installieren und
die Bro-Instanz neu zu starten. Wenn Sie nun HTTP-Datenverkehr überwachen, können
Sie erkennen, dass sehr schnell eine Menge Dateien extrahiert werden (siehe Abb. 10.14).
Abbildung 10.14: Extrahierte GIF- und HTML-Dateien
10.4.6 Darknet-Überwachung mit Bro
Dateien zu extrahieren ist zwar für viele Zwecke sehr nützlich, aber unsere bisherige Vorgehensweise wirft natürlich die wichtige Frage auf: »Wie bekomme ich Bro dazu, mich zu
informieren, wenn irgendetwas Bemerkenswertes geschieht?« Die Antwort darauf gibt das
folgende Beispiel, in dem Bro nach einer bestimmten Art von Ereignis Ausschau hält und
uns darüber informiert, wenn dieses Ereignis tatsächlich auftritt.
In diesem Beispiel schreiben wir mithilfe von Bro einen Darknet-Detektor. Ein Darknet
ist ein Subnetz (oder, technisch gesehen, auch eine einzelne IP-Adresse), das in Ihrer
Organisation nicht genutzt wird und mit dem andere Hosts aus keinem legitimen Grund
kommunizieren sollten. Nehmen wir an, Ihrer Organisation ist ein /16-Netzwerk zugeordnet. Darin kann es mehrere unbenutzte /24-Netzwerke geben. Wenn Sie sich einige
davon schnappen und dafür sorgen, dass sie auch in Zukunft nicht zugewiesen werden,
dann haben sie damit ein Darknet aufgebaut.
Darknets können sehr nützlich sein, um interne Scans und Aufklärungsvorgänge zu erkennen, die ein Wurm oder eine unautorisierte Person in Ihrem Netzwerk vornimmt. Zwar sind
sie nicht hundertprozentig zuverlässig, da ein legitimer Benutzer versehentlich eine IP-Adresse aus dem Darknet eingeben oder ein legitimer Server aufgrund einer Fehlkonfiguration
darauf verweisen kann, aber sie können als ein sehr nützliches Frühwarnsystem dienen. Es
lohnt sich daher, sich die Zeit zu nehmen, ein solches Netz einzurichten und zu beobachten.
Erstellen Sie dazu als Erstes die Datei /opt/bro/share/bro/site/darknets.bro und fügen Sie
folgenden Code darin ein:
10.4 Eigene Erkennungswerkzeuge mit Bro erstellen 339
#
# Mit diesem Modul geben Sie eine Menge mit unbenutzen Netzwerkblöcken oder
# Adressen in Ihrem internen Netzwerk an. Wenn Bro Datenverkehr zu oder von
# diesen Blöcken erkennt, gibt es eine Benachrichtigung aus.
#
@load base/frameworks/notice
module Darknets;
export {
# Erstellt einen Benachrichtigungstyp für die Protokollierung
redef enum Notice::Type+= { Darknet_Traffic };
# Ihre Darknets. Diese Menge ist zu Anfang leer. Fügen Sie
# Netzwerkblöcke in local.bro hinzu. HINWEIS: Sie können auch einzelne
# Hosts in Form von /32-Subnetzen angeben.
const darknets: set[subnet]={} &redef;
}
# Vergleicht jede neue potenzielle Verbindung (erfolgreich oder nicht,
# TCP/UDP/IP) mit der Darknet-Menge
event new_connection(c:connection) {
local darknet_conn=cat(c$id$orig_h, c$id$resp_h, c$id$resp_p);
if(c$id$orig_h in darknets) {
NOTICE([$note=Darknet_Traffic,
$msg=”Traffic detected FROM darknet”,
$conn=c,
$identifier=darknet_conn]);
}
if(c$id$resp_h in darknets) {
NOTICE([$note=Darknet_Traffic,
$msg=”Traffic detected TO darknet”,
$conn=c,
$identifier=darknet_conn]);
}
}
Dieser Code enthält einige neue Elemente, die wir uns etwas näher ansehen wollen, bevor
wir fortfahren.
Zu Anfang des Codes wird das Modul base/frameworks/notice geladen. Dabei handelt es
sich um die Implementierung des Benachrichtigungsframeworks von Bro, einem Satz von
Hooks, mit denen Sie eigene Arten von Benachrichtigungen erstellen und Benachrichtigungen anderer Module verwalten können. Bevor wir auf irgendetwas verweisen können,
das mit diesem Framework zu tun hat, müssen wir dieses natürlich erst in Bro laden.
340 10 Bro
Bericht von der Front
In der Praxis müssen Sie das Framework notice wahrscheinlich gar nicht ausdrücklich laden, da es als Teil des Standardframeworks praktisch immer schon geladen
ist. Wenn Sie den Code jedoch in besonderen Tools oder nicht standardmäßigen
Bro-Instanzen wiederverwenden oder an andere Bro-Benutzer weitergeben wollen,
können Sie sich nicht darauf verlassen, dass das Framework schon geladen ist. Daher ist es eine gute Vorgehensweise, alles ausdrücklich zu laden, was Sie brauchen.
Wenn es schon geladen ist, richtet diese Anweisung keinen Schaden an.
Danach erstellen wir die neue Menge darknets. Sie enthält Elemente vom Typ subnet, einem
eingebauten Bro-Datentyp zur Speicherung von CIDR-Blöcken, die im Code als Literalwerte im Format x.x.x.x/y angegeben werden. Zu Anfang ist diese Menge leer, sodass das Skript
in diesem Zustand nichts tun könnte. Allerdings ist diese Vorgehensweise sinnvoll, da wir die
Darknets nicht im Voraus kennen. Wir werden sie später in local.bro angeben.
Als Nächstes stellen wir einen Handler für das Ereignis new_connection bereit, das Bro
generiert, wenn es beginnt, eine neue Verbindung zu beobachten. Die Generierung dieses
Ereignisses bedeutet nicht, dass der Verbindungsversuch erfolgreich war, da es viel zu früh
erstellt wird, um das erkennen zu können. Aus dem Ereignis kann lediglich geschlossen
werden, dass versucht wurde, eine neue Verbindung aufzubauen.
Bericht von der Front
Bro überwacht Verbindungen aller Transportprotokolle, die es kennt. Für den
Aufbau einer Sitzung nutzt TCP das eigene Prinzip des Drei-Wege-Handshakes,
worauf Bro für die Erkennung zurückgreift. Bei verbindungslosen Protokollen
wie UDP und ICMP behandelt Bro jegliche Kommunikation zwischen zwei spezifischen Endpunkten als »Verbindung«, bis eine bestimmte Zeitspanne ohne
Kommunikation abgelaufen ist. Wenn das der Fall ist, wird die Verbindung »beendet«. Eine spätere Kommunikation zwischen denselben Endpunkten wird als
neue Verbindung aufgefasst.
Der einzige Parameter des Ereignisses new_connection ist c, ein Datensatz des Typs
c­ onnection. Verbindungsdatensätze sind ein Sammelbecken für die Daten, die Bro bei
Verbindungen im Auge behält. Neben grundlegenden Informationen wie den IP-Adressen und Ports von Quelle und Ziel, dem Verbindungsstatus und der Verbindungs-ID in
Bro werden in nicht standardmäßigen oder vom Benutzer geschriebenen Skripten auch
zusätzliche Daten darin gespeichert, etwa Geotagging-Informationen, Dateihashes usw.
Zu den Daten, die Sie am häufigsten aus diesen Datensätzen lesen werden, gehören die
IP-Adressen und Ports von Quelle und Ziel der Verbindung. Bro speichert sie als Teil des
Datensatzes id, der ein Bestandteil des Typ connection ist und selbst den Typ conn_id aufweist. Tabelle 10.2 zeigt den Aufbau von conn_id-Datensätzen.
10.4 Eigene Erkennungswerkzeuge mit Bro erstellen 341
Tabelle 10.2: Aufbau des Datensatztyps conn_id
Feld
Beschreibung
orig_h
IP-Adresse der Verbindungsquelle (des Clients)
orig_p
Portnummer und Protokoll der Quelle
resp_h
IP-Adresse des Verbindungsziels (des Servers)
resp_p
Portnummer und Protokoll des Ziels
Der native Datentyp von Bro für Ports besteht übrigens aus zwei Teilen, einem für die
Portnummer und einem für das Protokoll. Beispielsweise können Sie einer Variable mit
dem folgenden Code den normalen SMTP-Port zuweisen:
smtp_port=25/tcp
In unserem Beispiel jedoch sind wir nur an der IP-Adresse von Quelle und Ziel und am
Zielport interessiert, worauf wir in der verschachtelten Datenstruktur über c$id$orig_h,
c$id$resp_h bzw. c$id$resp_p zugreifen.
Unser Ereignishandler ruft als Erstes die Funktion cat() auf, die die Stringdarstellungen
ihrer Argumente zu einem einzigen String zusammensetzt und diesen zurückgibt. In diesem Fall bauen wir damit einen String aus der Quell- und Zieladresse und dem Zielport
zusammen. Das ist eine einfache Möglichkeit, eine ID für die Verbindung anzulegen.
Warum das wichtig ist, werden wir in Kürze besprechen. Zunächst einmal weisen wir
diesen Wert der Variable darknet_conn zu.
Als Nächstes untersuchen wir die IP-Quelladresse (und später in einem fast identischen
Codeabschnitt auch die IP-Zieladresse), um zu sehen, ob sie zu einem unserer Darknets
gehört:
if(c$id$orig_h in darknets) {
NOTICE([$note=Darknet_Traffic,
$msg="Traffic detected FROM darknet",
$conn=c,
$identifier=darknet_conn]);
}
Dieser Code besagt: »Wenn die IP-Quelladresse ein Element der Menge darknets ist, dann
erstelle eine Benachrichtigung.« Eine Benachrichtigung ist ein Eintrag in der Datei notices.
log. Dies ist die übliche Art und Weise, in der Bro zusätzliche Aufmerksamkeit auf etwas
lenkt. In Bro gibt es auch Alarme, die in die Datei alarms.log eingetragen werden und nach
einem Zeitplan per E-Mail gesendet werden. Benachrichtigungen können ebenfalls per
E-Mail oder als Pagernachricht verschickt werden, um schnell die Aufmerksamkeit auf ein
Ereignis zu ziehen, aber das wollen wir in diesem Beispiel nicht tun.
342 10 Bro
In unserem Code rufen wir die Funktion NOTICE auf, die als einziges Argument einen Datensatz mit allen Informationen für die Benachrichtigung entgegennimmt. Sie können
zwar auch eine Variable für den Benachrichtigungsdatensatz erstellen, doch die übliche
Vorgehensweise besteht darin, im Code mit dem Konstrukt [$field1=value1,­$field2=
value2,...,$fieldN=valueN] einen impliziten Datensatz aufzubauen. Das ist auch die
Methode, der wir in diesem Beispiel folgen.
Jede Benachrichtigung ist von einem bestimmten Typ. Dabei handelt es sich um einen der
Werte in einer besonderen Menge, die von den verschiedenen in Bro geladenen Modulen
definiert werden. Die Werte selbst sind dabei nicht von Bedeutung; sie dienen lediglich
dazu, die Benachrichtigungstypen voneinander zu unterscheiden. Sie müssen lediglich die
Namen kennen, sodass Sie sie als Wert des Feldes $note im Benachrichtigungsdatensatz
übergeben können. Jedes Modul, das eigene Benachrichtigungen erstellt, definiert auch
Typen dafür. Unser Code definiert den Typ Darknet_Traffic:
# Erstellt einen Benachrichtigungstyp für die Protokollierung
redef enum Notice::Type+= { Darknet_Traffic };
Im Feld $msg enthält jede Benachrichtigung auch eine für Menschen lesbare Meldung. In
unserem Code haben wir einen Benachrichtigungstyp mit zwei verschiedenen möglichen
Meldungen definiert, je nachdem, ob der Datenverkehr in das Darknet hinein- oder aus
ihm herausgeht.
Als Nächstes fügen wir im Feld $conn des Benachrichtigungsdatensatzes Informationen
über die aktuelle Netzwerkverbindung hinzu. Da Bro jetzt weiß, mit welcher Verbindung
die Benachrichtigung verknüpft ist, kann es die Verbindungs-ID in der Datei notice.log
korrekt aufzeichnen. Dadurch entstehen die Verknüpfungen zu der Datei conn.log, die wir
weiter vorn in diesem Kapitel gesehen haben.
Als Letztes fügt unser Code die zuvor erstellte ID als $identifier hinzu. Das ist wichtig,
um mit diesem Skript Benachrichtigungen erzeugen zu können.
Unterdrücken von Benachrichtigungen
Stellen Sie sich vor, dass ein System in Ihrem Netzwerk falsch konfiguriert ist, sodass es
versucht, einen Druckerdienst auf einem Host zu erreichen, den es für einen Druckserver
hält, bei dem es sich in Wirklichkeit aber um eine unbenutzte Adresse in einem Ihrer
Darknets handelt. Die von diesem fehlkonfigurierten Host übermittelten Druckaufträge werden niemals ausgeführt, aber das System übermittelt sie immer wieder, prüft den
Druckerstatus, übermittelt sie erneut usw. Das kann ziemlich lange so weitergehen, bis
irgendjemand den Fehler bemerkt und den Druckauftrag manuell löscht. Es kann sein,
dass Sie auf solche Vorgänge aufmerksam gemacht werden möchten, aber Sie möchten
bestimmt nicht für jede einzelne Netzwerkverbindung, die im Rahmen dieser fehlerhaften
Druckerkommunikation aufgebaut wird, eine Benachrichtigung erhalten.
10.4 Eigene Erkennungswerkzeuge mit Bro erstellen 343
Dieses Problem löst Bro durch die Unterdrückung von Nachrichten. Es ist intelligent genug, um zu erkennen, dass es bereits eine Benachrichtigung über ein bestimmtes Ereignis
gesendet hat, und um identische Benachrichtigungen eine Weile zurückzuhalten. Dazu
untersucht es den Benachrichtigungstyp (Darknet_Traffic) und den eindeutigen Bezeichner, den Ihr Code bereitstellt. Aus diesem Grund mussten wir den Wert darknet_conn
anlegen.
Darknet_conn erstellt aus der Quell- und Zieladresse und dem Zielport einen »eindeutigen« Bezeichner für die Verbindung. In Wirklichkeit ist dieser Bezeichner nicht so eindeutig, da der Quellport nicht angegeben ist, aber das haben wir absichtlich so gemacht.
Wiederholte Verbindungen zum selben Dienst kommen gewöhnlich von verschiedenen
Quellportnummern, weshalb die Angabe des Quellports den Bezeichner zu spezifisch gemacht und dazu geführt hätte, dass mehr Benachrichtigungen generiert werden. Wenn
wir wissen, dass 10.0.2.15 über Port 80 mit 192.168.1.1 kommuniziert hat, gehen wir stillschweigend davon aus, dass wir weitere dieser Kommunikationsversuche während der
nächsten Minuten ignorieren können. Anhand der ersten Benachrichtigung können wir
schließlich die vollständige Liste der Verbindungen in conn.log nachschlagen, falls wir sie
brauchen sollten.
Das Standardintervall für die Unterdrückung beträgt eine Stunde, sodass Sie für ein und
dasselbe Ereignis nicht mehr als 24 Benachrichtigungen pro Tag erhalten. Sie können
diesen Wert jedoch nach Bedarf erhöhen oder verringern. Wenn Sie das Standardintervall für alle Benachrichtigungen ändern wollen, fügen Sie local.bro folgenden Code hinzu:
# Ändert das Standardintervall für die Unterdrückung von Benachrichtigungen
# für sämtliche Benachrichtigungstypen
redef Notice::default_suppression_interval=30 min;
Bro verfügt außerdem über den integrierten Datentyp interval, den Sie auf eine beliebige
Zahl von Mikrosekunden (usec), Millisekunden (msec), Sekunden (sec), Minuten (min),
Stunden (hr) oder Tage (day) setzen können. Das macht es einfacher, die Zeitintervalle für
diese Art von Aufgaben festzulegen.
Sie können auch unterschiedliche Werte für die einzelnen Benachrichtigungstypen angeben. Wenn Sie beispielsweise den oben genannten kürzeren Wert für die meisten Typen
verwenden, für Darknet_Traffic aber ein längeres Intervall vorgeben wollen, fügen Sie
local.bro noch folgende Zeile hinzu:
Notice::type_suppression_intervals[Darknet_Traffic]=2 hour;
Wenn Sie mit Bro selbst und dem Einsatz von Bro in Ihrer Umgebung besser vertraut sind,
werden Sie wahrscheinlich irgendwann dazu übergehen, diese Unterdrückungswerte für
Ihren Bedarf zu optimieren.
344 10 Bro
Das Skript testen und einsetzen
Nachdem wir unseren Code als darknets.bro im richtigen Verzeichnis installiert haben,
müssen wir ihn von local.bro aus laden und ihm eine Liste unserer Darknets zuführen. Wie
das geschieht, sehen Sie in Abb. 10.15.
Abbildung 10.15: Angabe der Darknets in local.bro
In diesem Beispiel habe ich den gesamten Bereich von 10.0.4.0 bis 10.0.4.255 sowie die
einzelne IP-Adresse 192.168.1.100 als Darknet angegeben. In meinem Labornetzwerk ist
keiner dieser Bereiche in Benutzung, aber in der Praxis müssen Sie die Liste natürlich an
die Gegebenheiten in Ihrem Netzwerk anpassen.
Mit einer schnellen Runde broctl check/install/restart laden wir den Darknet-Code
in unsere laufende Bro-Instanz. Da es sich um »dunkle« Netzwerke handelt, sollten wir im
Idealfall keinerlei Datenverkehr darin erkennen. Da Bro erst dann Protokolldateien anlegt,
wenn es etwas zum Hineinschreiben hat, ist auch die Datei notice.log noch nicht sofort
vorhanden. Das ist völlig normal so.
Zum Testen müssen wir Datenverkehr zu einem unserer Darknets generieren. Als Erstes
habe ich es mit einfachem ICMP-Datenverkehr versucht. Dazu habe ich mit dem Befehl
ping einige Pakete an eine beliebige IP-Adresse in dem als Darknet definierten Bereich
10.0.4.0/24 geschickt (siehe Abb. 10.16). Da es diesen Host in meinem Netzwerk nicht
gibt, erhalte ich keine Antworten, aber Bro ist das egal.
10.4 Eigene Erkennungswerkzeuge mit Bro erstellen 345
In Abb. 10.16 können Sie erkennen, dass Bro eine Benachrichtigung vom Typ Darknets::Darknet_Traffic aufgezeichnet hat, sodass wir sie mit Grep oder einem ähnlichen
Tool leicht finden können. Die Ausgabe besagt auch, dass Datenverkehr zum Darknet
entdeckt wurde (»Traffic detected TO darknet«). Wir wissen also, dass wir es mit einer
eingehenden Verbindung zu dem Darknet zu tun haben.
Abbildung 10.16: Durch ICMP-Datenverkehr ausgelöste Benachrichtigungen vom Typ
Darknet_Traffic
Für einen weiteren Test versuchen wir einige TCP-Verbindungen zu der Adresse
192.168.1.100 aufzubauen, die wir zuvor als einzelnen »dunklen« Host eingerichtet haben. Dazu habe ich Verbindungen zu den Ports 80/tcp (HTTP) und 515/udp (UnixDruckspooler) verwendet. Die Benachrichtigungen zu diesen Aktivitäten sehen Sie in
Abb. 10.17.
Abbildung 10.17: Benachrichtigungen vom Typ Darknet_Traffic für einen dunklen Host
In Abb. 10.17 können Sie erkennen, dass Bro eine Reihe von Darknet_Traffic-Benachrichtigungen über Verbindungsversuche zu Port 80 auf 192.168.1.100 und eine Benachrichtigung
über Datenverkehr zu und von Port 515 aufgezeichnet hat. Daraus können wir schließen,
dass der Host nicht auf die HTTP-Anforderungen reagiert hat, aber am Druckspoolerport
lauscht, was bedeuten kann, dass jemand seinen Drucker falsch konfiguriert hat.
346 10 Bro
10.4.7 Das Darknet-Skript erweitern
Mit ein klein wenig zusätzlicher Arbeit können wir unser Darknet-Modul für andere Verwendungszwecke anpassen. Wenn beispielsweise Active-Directory-Server laut Ihrer Sicherheitsrichtlinie in einem eigenen besonderen Subnetz untergebracht sein müssen und
die Hosts in diesen Subnetzen keinen Zugriff auf das Internet haben dürfen, dann ersetzen
Sie in dem Code die Liste der Darknets durch eine Liste der Serversubnetze. Da in dieser
Situation aber immer noch eine Menge Datenverkehr zwischen dem AD-Subnetz und
dem Rest Ihres internen Netzwerks zu erwarten ist, können Sie nicht einfach bei jedem Ereignis einen Alarm auslösen. Sie können das Modul aber in einer Bro-Instanz ausführen,
die nur Datenverkehr vom und zum Internet sieht und daher keinen AD-Datenverkehr
wahrnehmen sollte. Eine andere Möglichkeit besteht darin, die Logik des Handlers für
new_connection so zu ändern, dass es sich bei der anderen Seite der Verbindung nicht um
ein gültiges lokales Subnetz handelt (z. B. indem Sie eine Menge mit Elementen vom Typ
subnet verwenden).
Auf ähnliche Weise können Sie auch nicht autorisierte Verbindungen zwischen Ihrer
DMZ und sensiblen Teilen des internen Netzwerks erkennen (»He, wieso kommuniziert
die DMZ da mit dem Computer des Geschäftsführers?«). Es ist auch möglich, die Liste
der Subnetze durch eine Liste zugelassener Ports zu ersetzen und damit Verbindungen
auf die Verwendung ungewöhnlicher, laut Ihren Richtlinien nicht erlaubter Dienste zu
überwachen. Es gibt praktisch unbegrenzte Möglichkeiten, dieses einfache Beispiel an die
Bedürfnisse in Ihrem Netzwerk anzupassen, was die Leistungsfähigkeit und Vielseitigkeit
veranschaulicht, die das Framework Bro zum Erkennen schädlicher Vorgänge im Netzwerk bietet.
10.4.8 Die Standardverarbeitung von Benachrichtigungen aufheben
Wir haben Bro so eingerichtet, dass wir alarmiert werden, wenn irgendetwas versucht, mit
einem unserer Darknets zu kommunizieren. Allerdings macht unser Skript keine genauen
Angaben darüber, was da mit dem Darknet kommuniziert. Ich habe zuvor gesagt, dass es
für die anderen Hosts in Ihrem Netzwerk keinen legitimen Grund geben sollte, mit einem
Darknet zu kommunizieren, aber es gibt einige Ausnahmen von dieser Regel, beispielweise die interne Netzwerkzuordnung.
Eine Organisation muss manchmal überprüfen, was sich in ihrem Netzwerk befindet, sei
es um neue Geräte zu entdecken, die verwaltet werden müssen, oder um sicherzustellen,
dass keine unautorisierten Geräte hinzugefügt wurden. Es kann daher sein, dass die Netzwerkingenieure diesen Überprüfungsvorgang regelmäßig durchführen. Auch viele Pakete
zum Aufspüren von Schwachstellen bieten diese Funktion an. Es gibt also tatsächlich einige Hosts, die versuchen, mit unseren Darknets zu kommunizieren, wenn auch nur, um
sich zu vergewissern, dass die Darknetz tatsächlich noch »dunkel« sind. Wegen solcher
legitimen Aktivitäten wollen wir nicht alarmiert werden, aber im jetzigen Zustand erstellt
unser Skript Benachrichtigungen für eine ganze Menge dieser Vorgänge. Sehen wir uns
nun an, wie wir dieses Problem beheben können.
10.4 Eigene Erkennungswerkzeuge mit Bro erstellen 347
Dazu gibt es eine Reihe von Möglichkeiten. Wenn wir nur die Techniken nutzen wollen, die
wir bereits kennen, können wir in dem Darknet-Modul eine weitere Menge von Adressen
für unsere autorisierten Netzwerkscanner anlegen und im Handler für new_connection Code
hinzufügen, der vor dem Generieren einer Benachrichtigung überprüft, ob die Kommunikation mit einem Element dieser Menge erfolgt. Das funktioniert sehr gut und stellt eine
sinnvolle Erweiterung des Skripts dar. Da wir den ursprünglichen Darknet-Code komplett
selbst geschrieben haben, ist dies wahrscheinlich auch die beste Vorgehensweise. Da wir die
betreffenden Techniken aber schon alle kennen, wollen wir hier noch eine andere Methode
ausprobieren.
Nehmen wir daher an, wir hätten den ursprünglichen Darknet-Code von einem anderen
Bro-Benutzer bekommen. In diesem Fall wäre es nicht sinnvoll, den Code direkt zu bearbeiten, da wir dann unseren lokalen Patch jedes Mal erneut anwenden und testen müssten, wenn wir eine neue Version des Moduls bekommen. Zum Glück gibt es aber eine
andere Möglichkeit: Wir können die Benachrichtigungen von Bro abfangen, bevor sie
auf die Festplatte geschrieben werden, sie untersuchen und dann entscheiden, ob wir sie
aufzeichnen oder verwerfen lassen oder irgendeine andere Maßnahme ergreifen wollen.
Den neuen Code könnten wir in eine eigene Datei packen, wie wir es bei den anderen
Beispielen getan haben. Wenn wir ihn direkt in local.bro aufnehmen, bleiben der Code, der
das Darknets-Modul lädt, und der Code, der den Umgang mit den Benachrichtigungen
ändert, zusammen, was zumindest in diesem Fall die Wartung übersichtlicher und einfacher macht. Das Ende von local.bro mit dem bereits vorhandenen Darknet-Code und den
neuen Ergänzungen sieht dann wie folgt aus:
# Zeichnet Benachrichtigungen über Datenverkehr von und zu unbenutzten
# Subnetzen auf
@load darknets.bro
redef Darknets::darknets=[
10.0.4.0/24,
192.168.1.100/32
];
# Dies sind unsere legitimen Netzwerkscanner, die mit unseren Darknets
# kommunizieren dürfen, ohne dass eine Benachrichtigung aufgezeichnet wird.
const allowed_darknet_talkers: set[addr]={
10.0.2.15
};
# Verarbeitet alle Benachrichtigungen mit hoher Priorität und sucht nach
# Benachrichtigungen vom Typ Darknets::Darknet_Traffic. Wenn darin die IP# Quell- oder Zieladresse zu einem Element von allowed_darknet_talker gehört,
348 10 Bro
# werden alle Aktionen von der Benachrichtigung entfernt, sodass Bro weder
# die Benachrichtigung noch einen Alarm aufzeichnet und auch keine E-Mail
# oder Pagermeldung sendet.
hook Notice::policy(n: Notice::Info) &priority=5 {
if(n$note == Darknets::Darknet_Traffic &&(n$conn$id$orig_h in
allowed_darknet_talkers || n$conn$id$resp_h in
allowed_darknet_talkers)) {
# Weist die leere Menge zu und entfernt damit alle Aktionen
n$actions=set();
}
}
Zu Anfang des neuen Codes wird die neue Konstante allowed_darknet_talkers als Menge
von IP-Adressen definiert. (Wenn Sie sehr viele Netzwerkscanner oder sonstige zulässige
IP-Adressen haben, können Sie stattdessen auch eine Menge von Subnetzen angeben). Ich
habe hier als einziges Element der Menge die IP-Adresse meines Scansystems hinzugefügt
(10.0.2.15).
Als Nächstes deklarieren wir eine neue Art von Funktion, nämlich einen sogenannten
Hook. Hooks ähneln Ereignishandlern darin, dass Bro sie aufruft, wenn es Datenverkehr
verarbeitet und seine Aufgaben erledigt. Der Hauptunterschied besteht darin, dass sich
Ereignisse auf Geschehnisse im Netzwerkverkehr beziehen, während Hooks aufgerufen
werden, wenn Bro seine eigenen internen Prozesse ausführt.
In diesem Fall erstellt Bro eine neue Benachrichtigung und ruft den Hook Notice::policy
auf, um eine lokale Verarbeitung durchzuführen, was die normale Handhabung der Benachrichtigung durch Bro (also die Umsetzung der Benachrichtigungsrichtlinie) ändert.
Der Hook nimmt ein einziges Argument entgegen, nämlich n, einen Datensatz vom Typ
Notice::Info mit allen Informationen, die Bro über die Benachrichtigung hat.
Ein bemerkenswerter Aspekt der Hookdeklaration ist die Verwendung des Schlüsselworts
&priority, um der Ausführung der Hookfunktion den Prioritätswert 5 zuzuweisen. Da es
für jedes Ereignis mehrere Ereignishandler und für jeden Hook mehrere Hookfunktionen
gibt, können Sie in Bro die Reihenfolge festlegen, in der sie aufgerufen werden. Gültige Prioritätswerte sind Integerzahlen von 0 (Standard) bis 5, wobei Hooks und Ereignishandler
mit höheren Prioritätswerten vor denen mit niedrigeren Werten aufgerufen werden. Mit
&priority=5 sorgen wir also dafür, dass Bro unsere Hookfunktion vor irgendeiner anderen
Form von Verarbeitung der Benachrichtigung ausführt, sodass wir eine Gelegenheit haben,
die Verarbeitung frühzeitig abzubrechen.
Als Erstes muss unser Hook entscheiden, ob die Benachrichtigung verarbeitet werden
soll oder nicht. Bro kann viele verschiedene Arten von Benachrichtigungen erstellen, aber
wir sind hier nur an denen vom Typ Darknets::Darknet_Traffic interessiert, und das
auch nur, wenn eine der beiden IP-Adressen ein Element der Menge allowed_darknet_
talkers ist. In dem ursprünglichen Code für das Modul Darknets haben wir schon gesehen,
10.4 Eigene Erkennungswerkzeuge mit Bro erstellen 349
dass wir die Quell- und Zieladressen der fraglichen Verbindung über den Datensatztyp
conn_id zugänglich sind. Der Typ Notice::Info enthält einen conn_id-Datensatz mit einem Verweis auf die ursprüngliche Verbindung, deretwegen die Benachrichtigung generiert wurde. Zugriff darauf erhalten wir über n$conn. Daher steht n$conn$id$orig_h für die
IP-Adresse des Clients und n$conn$id$resp_h für die des Servers. Die ganze Verarbeitung
steht in einer einfachen if-Anweisung am Anfang des Hooks, um sicherzustellen, dass alle
Anforderungen erfüllt werden. Wenn nicht, machen wir einfach gar nichts, sodass Bro die
Benachrichtigung ganz normal aufzeichnet.
Sind die Bedingungen dagegen wahr, verarbeitet Bro den Rumpf des Hooks. Er enthält
eine einzige Zeile, die der Variable n$actions die leere Menge zuweist:
# Weist die leere Menge zu und entfernt damit alle Aktionen
n$actions=set();
Hierzu sind einige Erklärungen erforderlich. Um zu entscheiden, was es mit einer Benachrichtigung tun soll, schaut sich Bro die Liste der zugewiesenen Aktionen an. Diese Liste ist
lediglich eine Aufzählung von Typwerten, wobei vier zur Auswahl stehen. Eine Aufstellung
und Erklärung dieser Typen finden Sie in Tabelle 10.3.
Tabelle 10.3: Bro-Aktionen für Benachrichtigungn
Aktion
Beschreibung
Notice::ACTION_LOG
Schreibt die Benachrichtigung in die Datei notice.log.
Notice::ACTION_ALARM
Schreibt die Benachrichtigung in die Datei alarm.log. Diese Datei wird stündlich per E-Mail an die in der Variable
Notice::mail_dest angegebene Adresse gesandt.
Notice::ACTION_EMAIL
Sendet die Benachrichtigung sofort per E-Mail an die in
der Variable Notice::mail_dest angegebene Adresse.
Notice::ACTION_PAGE
Sendet die Benachrichtigung sofort an die in der Variable
Notice::mail_page_dest angegebene Adresse. Dabei
handelt es sich normalerweise an ein E-Mail-zu-SMSGateway. Es kann aber auch eine E-Mail-Adresse sein.
Der Hook Notice::policy dient dazu, Ihnen eine Möglichkeit zu geben, die Menge der
Standardaktionen für eine Benachrichtigung zu ändern, bevor Bro damit beginnt, diese
Aktionen auszuführen. In unserem Code weisen wir die leere Menge zu und entfernen
dadurch sämtliche Aktionen, womit wir Bro letzten Endes mitteilen: »Mach nichts mit
dieser Benachrichtigung.«
Nun ist es an der Zeit, den neuen Code auszuprobieren. Wie Sie bereits wissen, legt Bro
nach einem Neustart ein frisches, leeres Protokollverzeichnis an, sodass sich keine Benachrichtigungen darin befinden. Zum Testen pingen wir von unserem Scanhost aus eines der
350 10 Bro
Darknets an (erfolglos) und stellen eine Verbindung zu dem Druckerport des angegebenen dunklen Hosts her (erfolgreich). Wenn Sie sich die Protokolldateien ansehen, finden
Sie aber immer noch keine Benachrichtigungen (siehe Abb. 10.18). Das zeigt, dass unser
Hook funktioniert, sodass keine Benachrichtigungen mehr über Datenverkehr von zugelassenen internen Scangeräten generiert werden.
Abbildung 10.18: Die Kommunikation von zugelassenen Geräten ruft keine Benachrichtigungen hervor
E-Mail-Benachrichtigungen zu Darknet-Ereignissen erstellen
Wie bei den anderen Beispielen in diesem Kapitel können Sie auch den Code, der die Protokollierung von Benachrichtigungen des Typs Darknets::Darknet_Traffic deaktiviert,
für andere Zwecke umgestalten. Wenn es keine autorisierten Netzwerkscanner in Ihrer
Organisation gibt, kann es sein, dass Sie sofort über Ereignisse in Darknets benachrichtigt
werden wollen. Dazu können Sie den Code so ändern, dass die Benachrichtigung nicht
nur protokolliert, sondern auch per E-Mail gesendet wird. Dazu nehmen Sie lediglich die
Überprüfung von n$conn$id$orig_h und n$conn$id$resp_h aus der if-Anweisung heraus
und ersetzen die folgenden Zeilen:
# Weist die leere Menge zu und entfernt damit alle Aktionen
n$actions=set();
durch diesen Code:
# Fügt zusätzlich zu der bereits zugewiesenen Standardaktion
# Notice::ACTION_LOG die Aktion Notice::ACTION_EMAIL hinzu, sodass die
# Benachrichtigung sofort per E-Mail verschickt wird.
add n$actions[Notice::ACTION_EMAIL];
Die E-Mail-Adresse müssen Sie als Wert von Notice::mail_dest in der Datei local.bro
angeben:
10.4 Eigene Erkennungswerkzeuge mit Bro erstellen 351
redef Notice::mail_dest="admin@appliednsm.com";
Nach dem Neustart von Bro erhalten Sie jedes Mal E-Mail-Alarme, wenn ein System versucht, mit einem Ihrer Darknets zu kommunizieren.
10.4.9 Benachrichtigungen unterbinden, E-Mails senden und Alarme
auslösen – auf die einfache Weise
Im letzten Abschnitt haben wir gesehen, wie wir uns in die Benachrichtigungsverarbeitung von Bro einklinken können, um detaillierte Änderungen daran vorzunehmen und zu
entscheiden, wie mit einzelnen Benachrichtigungen umgegangen werden soll. Eine solche
chirurgische Präzision ist zwar oft wünschenswert, aber in anderen Fällen braucht man
eher einen Vorschlaghammer.
Für die zuvor gezeigten Maßnahmen gibt es in Bro auch ein bequemes Schnellverfahren:
Sie können einfach bestimmten Konstanten einen neuen Wert zuweisen, um die Richtlinie
zur Verarbeitung von Benachrichtigungen für sämtliche Ereignisse eines Typs zu ändern.
Nehmen wir an, dass es in Ihrem Netzwerk einen einzigen SSH-Server gibt und dass dieser Server mit dem Internet verbunden ist. Es gibt einen legitimen geschäftlichen Zweck
zur Verwendung dieses Servers (die sichere Dateiübertragung für Ihre Geschäftspartner),
aber da er vom Internet aus direkt zugänglich ist und den SSH-Standardport benutzt, ist
er natürlich ein beliebtes Ziel für Versuche, das Passwort zu erraten. Wenn Sie die SSHUnterstützung von Bro einschalten, wird jedes Mal beim Auftreten einer solchen Aktivität
die Benachrichtigung SSH::Password_Guessing protokolliert. Es kann jedoch gut sein, dass
Sie dabei Hunderte dieser Benachrichtigungen pro Tag erhalten. Da Sie ohnehin nichts
tun können, um diese Arten von Angriffen zu unterbinden, sind diese Benachrichtigungen nur störend. Die SSH-Unterstützung für Bro komplett auszuschalten, ist auch nicht
gerade das, was Sie wollen, aber zum Glück gibt es noch eine andere Lösung.
Sie besteht darin, den Benachrichtigungstyp SSH::Passwort_Guessing der Liste der Typen
hinzuzufügen, die nie protokolliert werden sollen. Bro führt weiterhin eine Überwachung
auf solche Vorfälle durch (es kann schließlich sein, dass andere Arten von Benachrichtigungen wissen müssen, ob versucht wird, das Passwort zu erraten), aber die Benachrichtigungen
darüber werden Ihnen nie angezeigt. Dazu fügen Sie einfach Folgendes zu local.bro hinzu:
# Verhindert die Erstellung von Benachrichtigungen über Versuche, das SSH# Passwort zu erraten
redef Notice::ignored_types+= { SSH::Password_Guessing };
Nach dem Neustart von Bro erscheinen keine Benachrichtigungen über Passwortrateversuche mehr in den Protokollen. Das betrifft alle Benachrichtigungen dieser Art von
sämtlichen Hosts. Wenn Sie also Benachrichtigungen von einem Host sehen wollen, von
einem anderen dagegen nicht, ist dies nicht der richtige Mechanismus. Da wir in unserem
352 10 Bro
Beispiel jedoch ohnehin nur einen einzigen SSH-Server haben, ist diese Vorgehensweise
ideal für unsere Zwecke geeignet.
Auf der anderen Seite kann es auch sein, dass Sie bestimmte Arten von Benachrichtigungen zu Alarmen (Alarmdaten) oder E-Mail-Alarmen hochstufen möchten. Neben wir
an, Sie haben mindestens einen mit dem Internet verbundenen Webserver und machen
sich Sorgen über SQL-Injektionsangriffe. Wenn Sie das Skript detect-sqli laden (was
meistens standardmäßig geladen wird), kann Bro SQL-Injektionsversuche erkennen und
erstellt jedes Mal eine Benachrichtigung vom Typ HTTP::SQL_Injection_Attacker, wenn
ein Host einen solchen Angriff auf einen Ihrer Server durchführt. (Außerdem erstellt es
eine Benachrichtigung vom Typ HTTP::SQL_Injection_Victim für den Zielserver, aber das
wollen wir vorläufig ignorieren.)
Das Problem ist nur, dass diese Benachrichtigungen zusammen mit allem anderen in die
Datei notice.log geschrieben werden. Es wäre besser, wenn sie in alerts.log aufgenommen
würden, da Sie automatisch jede Stunde eine Übersicht über diese Datei per E-Mail erhalten. Das können Sie mit folgendem Code in local.bro erreichen:
# Alarm bei allen Versuchen von SQL-Injektionsangriffen
redef Notice::alarmed_types+= { HTTP::SQL_Injection_Attacker };
Sie können sogar noch weitergehen und sich wie folgt sofort per E-Mail über diese Vorfälle informieren lassen:
# Sendet bei allen Versuchen von SQL-Injektionsangriffen sofort eine E-Mail
redef Notice::emailed_types+= { HTTP::SQL_Injection_Attacker };
Damit das funktioniert, müssen Sie in beiden Fällen natürlich die Variable Notice::mail_
dest definiert haben, da Bro sonst nicht weiß, wohin es die Benachrichtigungen senden soll.
10.4.10 Den Bro-Protokollen neue Felder hinzufügen
In unserem letzten Beispiel kommen wir wieder zu dem Thema vom Anfang dieses Kapitels zurück, nämlich zur Protokollierung. Wie wir bereits gesehen haben, leistet Bro hervorragende Arbeit, um unterschiedliche Arten von Transaktionen festzuhalten, allerdings
reichen die Möglichkeiten von Bro manchmal trotzdem nicht aus, etwa wenn Sie für bestimmte Transaktionen zusätzliche Informationen aufzeichnen wollen oder wenn Sie für
einige Ereignisse zusätzlichen Kontext benötigen. Es ist ganz einfach und eine gängige
Vorgehensweise, den Bro-Protokollen neue Felder hinzuzufügen.
Nehmen wir an, Ihre Organisation ist daran interessiert, woher ihr Internet-Datenverkehr
stammt bzw. wohin er geht. Eine einfache Möglichkeit, das herauszufinden, besteht darin,
Bro die Ländercodes für alle Netzwerkverbindungen abzurufen (sowohl Quell- als auch
Zielcodes) und in neue Felder der Datei conn.log zu schreiben.
10.4 Eigene Erkennungswerkzeuge mit Bro erstellen 353
Erstellen Sie dazu als Erstes die Datei conn-geoip.bro und kopieren Sie folgenden Code
hinein:
redef record Conn::Info+= {
orig_cc: string &optional &log;
resp_cc: string &optional &log;
};
event connection_state_remove (c: connection)
{
local client_geo_data=lookup_location(c$id$orig_h);
local server_geo_data=lookup_location(c$id$resp_h);
if(client_geo_data?$country_code) {
c$conn$orig_cc=client_geo_data$country_code;
}
if(server_geo_data?$country_code) {
c$conn$resp_cc=server_geo_data$country_code;
}
}
Hier fügt das Skript zu Anfang dem Datensatz Conn::Info zwei Felder hinzu, in dem Bro
Informationen über jede von ihm wahrgenommene Verbindung festhält. Gewöhnlich
werden darin Angaben wie der Zeitstempel der Verbindung, ein eindeutiger Bezeichner,
die Endpunkte, das Anwendungsschichtprotokoll usw. festgehalten. Die beiden Felder, die
wir hinzufügen, heißen orig_cc und resp_cc und dienen dazu, die Ländercodes der Endpunkte zu speichern.
Bei beiden neuen Feldern sind zwei Optionen angegeben, die nicht Teil des Datensatzes
selbst sind, sondern Bro anweisen, wie es unter verschiedenen Umständen mit diesen Feldern umgehen soll. Mit &log weisen wir Bro an, den Wert des Feldes in die Protokolldatei
zu schreiben, wenn es den Eintrag in conn.log vornimmt. Ohne diese Option würden die
Daten zwar von Bro abgerufen werden, aber nie in der Protokolldatei auftauchen. Die
Option &optional besagt, dass es kein Problem darstellt, wenn dieses Feld keinen Wert hat
(etwa wenn es sich bei einem der Endpunkte um eine RFC-1918-Adresse ohne geografische Bindung handelt). Wenn das der Fall ist, schreibt Bro einfach einen Strich in das Feld,
was bei allen Feldern in allen Protokollen das Standardverhalten für fehlende Werte ist. Sie
können statt &optional auch &default="None" schreiben (oder mit &default irgendeinen
anderen Wunschstring angeben), um in einer solchen Situation einen anderen Wert in
das Protokoll schreiben zu lassen, aber da der Bindestrich überall sonst als Standardersatzwert verwendet wird, bleiben wir der Einheitlichkeit halber dabei.
Als Nächstes schreiben wir einen einfachen Handler für das Ereignis connecton_state_
remove, das Bro generiert, bevor es eine aktive Verbindung aus seiner Statustabelle entfernt und das Protokoll auf die Festplatte schreibt. Darin verwenden wir die im Lieferumfang von Bro enthaltene Funktion lokkup_location(). Sie nimmt eine IP-Adresse als
354 10 Bro
Argument entgegen und gibt einen Datensatz vom Typ geo_location zurück, der wie
folgt definiert ist:
type geo_location: record {
country_code: string;
region: string;
city: string;
latitude: double;
longitude: double;
}
Unser Skript stellt zwei Anforderungen zum Abrufen des Standorts, jeweils eine für jede
Seite der Verbindung, wobei die IP-Adressen aus dem Datensatz mit der Verbindungs-ID
bezogen werden:
local client_geo_data=lookup_location(c$id$orig_h);
local server_geo_data=lookup_location(c$id$resp_h);
Danach prüft es, ob die Rückgabewerte den Ländercode enthalten. Wenn ja, wird dieser Code dem entsprechenden Feld in dem neu definierten Datensatz mit Informationen
über die Verbindung hinzugefügt. Anderenfalls geschieht nichts.
if(client_geo_data?$country_code) {
c$conn$orig_cc=client_geo_data$country_code;
}
Das war es auch schon! Da wir für die beiden neuen Felder im Datensatz Conn::Info die
Option &log angegeben haben, werden die entsprechenden Werte in die Datei conn.log
geschrieben. Der Handler connecton_state_remove muss die Werte nur noch abrufen und
in den Datensatz einfügen. Um den Rest kümmert sich Bro.
Damit sind wir bereit, unser Skript einzusetzen. Sie wissen bereits, wie Sie es Ihrer laufenden Bro-Instanz hinzufügen können, um es kontinuierlich ausführen zu lassen. Zur
Veranschaulichung testen wir es hier aber wieder an der Befehlszeile für eine PCAP-Datei.
In Abb. 10.19 sehen Sie das hintere Ende des Verbindungsprotokolls mit den IP-Adressen
und Standortdaten für die einzelnen Endpunkte.
10.4 Eigene Erkennungswerkzeuge mit Bro erstellen 355
Abbildung 10.19: Verbindungsprotokolle mit GeoIP-Informationen
Achtung
Für dieses Beispiel ist eine sehr wichtige Voraussetzung erforderlich, die wir noch
nicht besprochen haben, nämlich die GeoIP-Datenbank. Bro kennt nicht alle
möglichen IP-Adressen und Ländercodes, sondern greift dafür auf die GeoIPLiteDatenbank von MaxMind zurück (http://www.maxmind.com). In Security Onion
ist diese Datenbank standardmäßig installiert, aber auf einem anderen System
müssen Sie sie möglicherweise nachinstallieren. Glücklicherweise ist GeoLite als
installierbares Paket für die meisten Linux- und *BSD-Plattformen erhältlich.
MaxMind stellt auch andere Datenbanken mit ausführlicheren Informationen
zur Verfügung. Die GeoIPLite-Standarddatenbank enthält nur die Ländercodes
und das auch nur für IPv4-Adressen. Damit kann Bro in der Struktur geo_­
location keine anderen Felder als nur die für die Ländercodes ausfüllen. In anderen MaxMind-Datenbanken werden jedoch auch die Städte und die geografische
Länge und Breite angegeben, und zwar sowohl für IPv4 als auch für IPv6. Wenn
Sie ausführlichere Ortsangaben benötigen oder sehr oft mit IPv6-fähigen Hosts
zu tun haben, schauen Sie sich auf http://dev.maxmind.com/geoip/legacy/geolite/
die Anleitungen zum Herunterladen und Installieren dieser zusätzlichen Datenbanken an.
Wenn Sie diese erweiterten Datenbanken nicht installieren, funktioniert die
Standortsuche nach wie vor, allerdings werden die meisten Werte in der Struktur geo_location dann nicht ausgefüllt. Wenn Bro vergeblich versucht, diese
Datenbanken zu öffnen, können auch Warnungen wie die in Abb. 10.19 angezeigt werden, die Sie aber getrost ignorieren können.
356 10 Bro
10.5 Zuammenfassung
Zu Anfang dieses Kapitels haben Sie einen Überblick über die Grundprinzipien von
Bro und die Protokolldateien bekommen und dann eine praktische Einführung in die
Programmierung in Bro erhalten. Dabei haben wir einige einfache, aber sehr nützliche
Aufgaben ausgeführt, z. B. den Abruf von Dateien und die Überwachung von Darknets.
Es wurden auch einige Techniken vorgestellt, die Sie immer wieder für die Arbeit in Bro
brauchen werden, z. B. der Umgang mit Benachrichtigungen und Alarmen, die Optimierung der Konfiguration und der Protokollierungseinstellungen sowie das Schreiben
eigener Module.
Dabei haben wir jedoch nur an der Oberfläche gekratzt, denn wie sehr man sich auch
bemüht, ist es doch nicht möglich, Bro mit einem einzigen Kapitel gerecht zu werden.
Bro hätte ein eigenes Buch verdient, aber in Ermangelung dessen sollten Sie sich vorläufig auf der Website http://bro.org umsehen, insbesondere in den E-Mail-Listen. Die
Bro-Community ist sehr aktiv und wächst rasch, und viele andere Bro-Benutzer sind
bereit, Ihre Fragen zu beantworten, Skripte zu veröffentlichen und neue Möglichkeiten
auszukundschaften, was mit der Plattform alles angestellt werden kann. Um zeitnah Hilfe
zu erhalten, können Sie sich auch den Freenode-IRC-Kanal #bro ansehen, wo fast immer
irgendwelche Leute anwesend sind, die Ihre Fragen beantworten oder einfach mit Ihnen
über die tollen neuen Sachen reden, die sie gerade mit Bro machen. Nach der Meinung
der Autoren dieses Buches und vieler anderer NSM-Experten ist Bro die Zukunft der
effizienten NSM-Erkennung.
11
Anomaliegestützte Erkennung
anhand von statistischen Daten
Die Grundlage des Network Security Monitorings besteht darin, Daten zu erfassen, um
eine Erkennung und Analyse daran ausführen zu können. Da hierbei so viele Daten gesammelt werden, ist es möglich, statistische Daten daraus zu gewinnen, und auch, diese
zur Erkennung und Analyse heranzuziehen. In diesem Kapitel sehen wir uns die Möglichkeiten an, Statistiken für eine Echtzeit- und eine rückblickende Erkennung aufzustellen.
Statistische Daten werden aus der Erfassung, Gliederung, Analyse, Interpretation und Darstellung der vorhandenen Daten abgeleitet.1 Angesichts der ungeheuren Menge von Daten,
mit denen NSM-Teams zu arbeiten haben, spielen statistische Daten eine große Rolle bei
der Erkennung und Analyse – von der Analyse des Datenverkehrs, der von einem bestimmten gegnerischem Host ausgeht, bis zu Aufdeckung des gesamten Sichtfelds eines neuen
Sensors. In den Produkten der großen Marken auf dem Gebiet des NSM werden statistische
Daten oft in Form von ineinander verschachtelten Dashboards anzeigt. Das wird teilweise
als Argument genutzt, um die Wände in den Büros Ihrer Organisation mit 70"-Plasmabildschirmen zu tapezieren und die Vorgesetzten der Vorgesetzten zu beeindrucken. Auf die
richtige Weise eingesetzt, bieten diese Daten jedoch tatsächlich einen großen Nutzen.
1 Dodge, Y. (2006), The Oxford Dictionary of Statistical Terms, OUP. ISBN 0-19-920613-9
358 11 Anomaliegestützte Erkennung anhand von statistischen Daten
11.1
Kommunikationsintensive Hosts mit SiLK finden
Ein einfaches Beispiel für statistische Daten ist die Liste der kommunikationsintensivsten Hosts in Ihrem Netzwerk, also der Geräte, die die umfangreichste Kommunikation
im überwachten Netzwerksegment hervorrufen. Anhand dieser Statistik kann ein NSMTeam beispielsweise Geräte finden, von denen ein verdächtig umfangreicher Datenverkehr
zu externen Hosts ausgeht, oder Computer aufspüren, die mit Malware verseucht sind
und deshalb Verbindungen zu sehr vielen verdächtigen externen IP-Adressen aufbauen.
Damit können Dinge erkannt werden, die sich mit Signaturen nicht feststellen lassen, da
es sich um echte Netzwerkanomalien handelt.
Ohne die richtigen Werkzeuge und ohne Zugriff auf Netzwerkdaten kann es schwierig
sein, eine solche Liste aufzustellen. Mit Analysewerkzeugen für Sitzungsdaten wie SiLK
und Argus wird diese Aufgabe jedoch ganz einfach.
In Kapitel 4 haben wir uns bereits verschiedene Möglichkeiten angesehen, Sitzungsdaten
zu erfassen und auf einfache Weise zu untersuchen. Dabei haben wir auch SiLK besprochen, ein Werkzeug zur effizienten Erfassung, Speicherung und Analyse von Flussdaten.
SiLK umfasst verschiedene nützliche Tools, um Statistiken und Messwerte zu erstellen.
Dabei muss der Benutzer die Quelldaten angeben und dann die gewünschten Tools zum
Anzeigen, Sortieren, Zählen, Gruppieren und Kombinieren dieser Daten auswählen. Um
die Liste der kommunikationsintensivsten Hosts aufzustellen, verwenden wir im Folgenden die Tools Rwstats und Rwcounts.
SiLK wird oft benutzt, um Flussdaten direkt anzuzeigen, aber mit Rwstats können Sie die
Sitzungsdaten auf eine Weise nutzen, die Ihnen ein besseres Verständnis der Umgebung
gibt. In allen Umgebungen, die ich kenne und in denen SiLK verwendet wird, ist Rwstats
das am häufigsten genutzte Werkzeug, um statistische Daten zu gewinnen.
Wie immer bei derVerwendung von SiLK empfehle ich Ihnen, als Erstes einen RwfilterBefehl zu verwenden, um die Datenmenge zu überprüfen, die Sie zur Gewinnung der
Statistiken verwenden wollen. Dazu reicht es im Allgemeinen, den passenden Filter zusammenzustellen und das Ergebnis an Rwcut zu leiten, um es auszugeben, sodass Sie sich
vergewissern können, dass Sie tatsächlich mit der gewünschten Datenmenge arbeiten.
Wenn Sie sich mit Rwfilter und der Weiterleitung der Ergebnisse eines Rwtools an ein anderes nicht auskennen, sollten Sie noch einmal in Kapitel 4 nachschlagen. In den meisten
der folgenden Beispiele verwenden wir einfache Rwfilter-Abfragen, sodass Sie sie mit einer
Standardbereitstellung von SiLK nachvollziehen können.
Für Rwstats müssen Sie lediglich drei Dinge angeben: einen Eingabeparameter, einen
Satz von Feldern, für die Statistiken erstellt werden sollen, und eine Beendigungsbedingung, um die Ergebnisse einzugrenzen. Bei dem Eingabeparameter kann es sich um einen Dateinamen handeln, den Sie an der Befehlszeile angeben. Meistens jedoch werden
als Daten die Ergebnisse eins Rwfilter-Befehls von der Standardeingabe gelesen. Diese
Eingabe sollte direkt vom Rwfilter ohne Zwischenverarbeitung durch Rwcut stammen.
11.1 Kommunikationsintensive Hosts mit SiLK finden 359
Die Felder, die Sie angeben, bilden einen benutzerdefinierten Schlüssel, anhand dessen
die SiLK-Flussdatensätze gruppiert werden. Daten, die mit dem Schlüssel übereinstimmen, werden in einzelnen Behältern für jede Übereinstimmung gespeichert. Anhand der
Größe dieser Behälter (ob in Bytes, Datensätzen, Paketen oder Anzahl unterschiedlicher
Kommunikationsdatensätze) wird dann eine Liste erstellt und nach Größe geordnet,
standardmäßig absteigend, aber auf Wunsch des Benutzers auch aufsteigend. Die Beendigungsbedingung begrenzt die Ergebnisse und kann als absoluter Wert angegeben werden (»gib 20 Behälter aus«), als Schwellenwert (»gib nur die Bins mit einer Byteanzahl
kleiner 400 aus«) oder als Prozentsatz der angegebenen Gesamtgröße (»gib nur Behälter
aus, die mindestens 10 % aller Pakete enthalten«).
Der erste Schritt, um unsere Liste der kommunikationsintensivsten Hosts aufzustellen,
besteht darin, einen geeigneten Rwfilter-Befehl zusammenzustellen, der uns die zu untersuchenden Daten liefert. Mit einem Pipe-Symbol übergeben wir diese Daten an Rwstats.
Der Befehl sieht wie folgt aus:
rwfilter --start-date=2013/08/26:14 --any-address=102.123.0.0/16 --type=all
--pass=stdout | rwstats --top --count=20 --fields=sip,dip --value=bytes
Dieser Filter erfasst alle Flussdatensätze, die von 14 bis 15 Uhr am 26. August 2013 gesammelt wurden, wobei nur Datenverkehr im IP-Adressbereich 102.123.0.0/16 berücksichtigt
wird. Diese Daten werden von Rwstats übergeben, das daraus die Liste der 20 (--count=20)
Kombinationen aus Quell- und Ziel-IP-Adressen (--fields=sip,dip) mit dem größten
Verkehrsaufkommen nach Anzahl der Bytes (--value=bytes) aufstellt.
Das gleiche Ergebnis erhalten wir, wenn wir die Ergebnisse des Rwfilter-Befehls in eine
Datei schreiben und diese Datei von Rwstats untersuchen lassen. Wenn wir diese Datei
test.rwf nennen, lauten die beiden dazu erforderlichen Befehle wie folgt:
rwfilter --start-date=2013/08/26:14 --any-address=102.123.0.0/16 --type=all
--pass=stdout>test.rwf
rwstats test.rwf --top --count=20 --fields=sip,dip --value=bytes
Das Ergebnis dieser Befehle sehen Sie in Abb. 11.1.
360 11 Anomaliegestützte Erkennung anhand von statistischen Daten
Abbildung 11.1: Von Rwstats aufgestellte Statistik der kommunikationsintensivsten Hosts
In den in Abbildung 11.1 gezeigten Daten können Sie mehrere äußerst aktive Geräte im
lokalen Netzwerk erkennen. Geräte, bei denen dies nicht zu erwarten gewesen wäre, sollten
Sie einer genaueren Untersuchung unterziehen. Beispielsweise ist Host 102.123.222.245
für eine sehr große Menge von Datenverkehr verantwortlich. Um uns diese Kommunikation näher anzusehen, können wir weitere Statistiken aufstellen.
Wenn Sie denselben Befehl noch einmal ausführen, dabei aber den CIDR-Bereich in der
Rwfilter-Anweisung durch die IP-Adresse des geschwätzigen Hosts ersetzen, können Sie
erkennen, welche Geräte, mit denen er kommuniziert, für diese Mengen von Datenverkehr verantwortlich sind.
rwfilter --start-date=2013/08/26:14 --any-address=102.123.222.245
--type=all --pass=stdout | rwstats --top --count=5 --fields=sip,dip
--value=bytes
Die Statistiken, die diese Abfrage hervorruft, sehen Sie in Abb. 11.2.
11.1 Kommunikationsintensive Hosts mit SiLK finden 361
Abbildung 11.2: Die bedeutendsten Kommunikationspartner eines einzelnen Hosts
Damit können Sie herausfinden, wer für ein abnorm hohes Maß an Datenverkehr verantwortlich ist. Um auch zu erfahren, um was es bei der Kommunikation zwischen den
Geräten geht, ändern wir die Suchkriterien und forschen nach den verwendeten Diensten:
rwfilter --start-date=2013/08/26:14 --any-address=102.123.222.245
--type=all --pass=stdout | rwstats --top --count=5 --fields=sip,sport,dip
--value=bytes
Die Datenmenge, auf die dieser Befehl angewendet wird, ist unverändert geblieben, allerdings ziehen wir hier das Quellportfeld als zusätzliches Kriterium für die Statistiken
heran. Das Ergebnis sehen Sie in Abb. 11.3.
Abbildung 11.3: Statistiken für die Nutzung von Diensten
Die Vorgänge stehen offenbar in Verbindung mit einer Art SSH-Verbindung, aber bevor wir den Benutzer befragen oder andere Datenquellen zur Bestätigung heranziehen,
wollen wir weitere Statistiken aufstellen, um auch zu klären, wann die Kommunikation
stattfindet. Dazu wenden wir uns vorübergehend von Rwstats ab und nutzen Rwcount,
ein weiteres Tool im Analysepaket SiLK, das eine Übersicht über die zeitliche Abfolge der
SiLK-Flussdatensätze geben kann. Um das zu tun, zählt es die Datensätze im Eingabestream und sortiert die Angaben über die Anzahl der Bytes und Pakete in Behältern, die
Zeitabschnitte darstellen. Wenn Sie einen Rwfilter-Befehl direkt an Rwcount weiterleiten,
erhalten Sie eine Tabelle, die angibt, wie Datensätze, Bytes und Pakete jeweils in Abschnitten von 30 s übertragen wurden. Mit der Option --bin-size können Sie die Größe dieser
Zeitabschnitte ändern. In unserem Beispiel verwenden wir folgenden Befehl:
rwfilter --start-date=2013/08/26:14 --any-address=102.123.222.245
--sport=22 --type=all --pass=stdout | rwcount --bin-size=600
362 11 Anomaliegestützte Erkennung anhand von statistischen Daten
Da wir herausfinden wollen, wann Datenverkehr über Port 22 aufgetreten ist, verwenden
wir im Rwfilter-Filter befehl die Option --sport=22. Außerdem haben wir Rwstats durch
Rwcount ersetzt, um herauszufinden, in welchen Zeitabschnitten die Daten übertragen
wurden. Weiter hinten in diesem Kapitel werden wir uns noch ausführlicher mit Rwcount
beschäftigen. Hier verwenden wir nur eine einzige Option, nämlich --bin-size, um den
Datenverkehr in Abschnitte von 10 Minuten (600 s) gruppieren zu lassen. Die Ergebnisse
dieses Befehls sehen Sie in Abb. 11.4.
Abbildung 11.4: Ergebnisse von Rwcount mit Angaben darüber, wann die Kommunikation
stattgefunden hat
Die Datenübertragung scheint im Zeitverlauf relativ konstant zu erfolgen, was darauf
hindeutet, dass der SSH-Tunnel genutzt wurde, um eine große Menge von Daten zu übertragen. Daber kann es sich um eine schädliche Aktivität wie das Herausschmuggeln von
Daten handeln, aber auch die legitime Nutzung des SCP-Tools, um Daten zur Sicherung
auf ein anderes System zu übertragen. Um das unterscheiden zu können, müssten Sie
weitere Datenquellen analysieren. Die Statistiken, die wir bis jetzt aufgestellt haben, geben
den Analytikern aber schon eine gute Vorstellung davon, wo sie als Nächstes nachforschen sollten.
11.2 Diensterkennung mit SiLK
Mit Rwstats können Sie auch schützenswerte Elemente in Ihrem eigenen lokalen Netzwerk aufspüren. Wenn ein neuer Server im Produktionsnetzwerk platziert wird, sollte das
Sicherheitsteam eigentlich darüber informiert werden, sodass es ihn schützen kann, doch
in der Praxis erhalten Analytiker solche Informationen nur selten zeitnah. Sofern sich
diese Server aber in dem Netzwerkbereich befinden, den Sie schützen sollen, können Sie
einen Mechanismus vorhalten, um ihre Gegenwart aufzuspüren. Dadurch können Sie sich
nicht nur über die eigenen Geräte auf dem Laufenden halten, sondern auch unautorisierte
und gegnerische Server finden, die von eigenen Benutzern oder Angreifern bereitgestellt
wurden.
11.2 Diensterkennung mit SiLK 363
Mit Rwstats können wir diese Server relativ leicht entdecken. Im folgenden Beispiel versuchen wir, bedeutende Server ausfindig zu machen, die regelmäßig mit Geräten außerhalb
des lokalen Netzwerks kommunizieren. Dazu erstellen wir zunächst einen Rwfilter, um die
Datenmenge zusammenzustellen, auf deren Grundlage Sie die Statistiken anlegen wollen.
Im Idealfall sollten Sie diese Abfrage regelmäßig ausführen und ihre Ergebnisse untersuchen, um Schadserver zu entdecken, die nur vorübergehend bereitgestellt und dann
wieder abgeschaltet werden.
Im folgenden Beispiel arbeiten wir mit einer von Rwfilter bereitgestellten Datei, die wir
an Rwstats übergeben, anstatt kontinuierlich eine Datenmenge zusammenzustellen und
weiterzuleiten. Der Filter legt eine Datenmenge mit dem gesamten Datenverkehr für einen
gegebenen Zeitraum an und schreibt sie in die Datei sample.rw.
rwfilter --start-date=2013/08/28:00 --end-date=2013/08/28:23 --type=all
--protocol=0- --pass=sample.rw
Als Nächstes müssen wir überlegen, was für Statisken wir überhaupt haben wollen. Um
das zu bestimmen, ist es immer sinnvoll, eine Frage zu stellen, die Sie anschließend in die
Rwstats-Syntax übersetzen. In diesem Fall könnten wir uns fragen: »Welche lokalen Geräte kommunizieren am meisten über die üblichen Serverports 1 bis 1024?« Auf diese Frage
kann es jedoch mehrere Antworten geben. Die Grenze, die Sie ziehen, um zu definieren,
was »am meisten« ist, kann eine entscheidende Rolle dabei spielen, ob Sie die Ergebnisse
bekommen, die Sie haben wollen. Formulieren wir unsere Frage daher etwas konkreter:
»Welche 20 lokalen Geräte kommunizieren über die Ports 1 bis 1024 zu den meisten unterschiedlichen IP-Zieladressen außerhalb des lokalen Netzwerks?« Übersetzt in die Form
eines Rwstats-Befehls, sieht diese Frage wie folgt aus:
rwfilter sample.rw --type=out,outweb --sport=1-1024 --pass=stdout |
rwstats --fields=sip,sport --count=20 --value=dip-distinct
Das Ergebnis dieser Abfrage sehen Sie in Abb. 11.5.
364 11 Anomaliegestützte Erkennung anhand von statistischen Daten
Abbildung 11.5: Kommunikationsintensivste Server
Diese Abfrage gibt die IP-Quelladressen und Ports (--fields=sip,sport) der 20 lokalen
Server (--count=20) zurück, die mit den meisten verschiedenen externen Geräten kommuniziert haben (--value=dip-distinct). Die Datenmenge, an der diese Abfrage ausgeführt
wird, ist durch die Anwendung eines Rwfilters auf die Daten in der bereits generierten Datei sample.rw noch weiter eingeschränkt worden und umfasst nur noch den ausgehenden
Datenverkehr über die Ports 1 bis 1024 (--type=out,outweb --sport=1-1024).
Damit bekommen wir schon eine gewisse Vorstellen von dem, was wir wissen wollen,
aber was ist mit Serverdatenverkehr, der keine Kommunikation mit externen Hosts einschließt? Wenn Ihr Flusskollektor (ein Sensor oder Router) so aufgestellt ist, dass er auch
Datenverkehr zwischen internen Geräten erfasst, können Sie diesen mit der zusätzlichen
Angabe int2int bei der Option --type ebenfalls einbeziehen.
Um die Qualität der Daten zu verbessern und uns bessere Voraussetzungen zum Anlegen statistischer Daten zu verschaffen, können wir die Datenmenge außerdem auf die
IP-Quelladressen aus den Netzwerkbereichen einschränken, für deren Schutz wir verantwortlich sind. Dabei handelt es sich gewöhnlich um die Werte, die in der SiLK-Datei
sensor.conf als interne IP-Adressblöcke definiert sind. Die beste Möglichkeit dazu besteht
darin, eine Menge zu erstellen, die aus diesen Blöcken besteht. Die Rwtools von SiLK verwenden Mengendateien, um auf Gruppen von IP-Adressen zu verweisen. Um eine solche
Datei anzulegen, stellen Sie einfach alle IP-Adressen (einschließlich CIDR-Bereiche) in
eine Textdatei und wandeln diese mit dem Befehl rwsetbuild um:
rwsetbuild local.txt local.set
11.2 Diensterkennung mit SiLK 365
Dieser Befehl gibt die Liste der in local.txt definierten IP-Adressblöcke in Form der Mengendatei local.set aus. Damit können wir nun folgenden Befehl verwenden, um die Daten
zu bekommen, die wir haben wollen:
rwfilter sample.rw --sipset=local.set --type=int2int,out,outweb
--sport=1-1024 --pass=stdout | rwstats --fields=sip,sport --count=20
--value=dip-distinct
Mit der Option --sipset im Rwfilter-Befehl schränken wir die Daten auf die IP-Quelladressen aus dem Netzwerk ein, für dessen Schutz wir verantwortlich sind.
Mit nur kleinen Änderungen können Sie diese Befehle mit erstaunlicher Genauigkeit
an Ihre Umgebung anpassen. Stellen Sie sich vor, Sie untersuchen die Top-20-Liste, die
bei unserer bisherigen Abfrage herauskommt, und kommen dabei zu dem Schluss, dass
Sie sich lieber alle Server ansehen sollten, die mit mindestens zehn verschiedenen Geräten kommunizieren. Dazu müssen Sie einfach die Angabe --count=20 in --threshold=10
ändern. Die Ergebnisse können Sie noch weiter verändern, indem Sie den Portbereich
eingrenzen oder eine neue Mengendatei anlegen. Beachten Sie, dass wir uns hier auf
die Suche nach Diensten konzentrieren. Durch die Angabe von --fields=sip,sport werden die kommunikationsintensivsten Kombinationen aus Quelladresse und Quellport
angezeigt. Um ganz allgemein die Server zu finden, die mit den meisten verschiedenen
IP-Zieladressen kommunizieren, müssen Sie das Feldkriterium sport aus dem RwstatsBefehl entfernen, sodass sämtliche Verbindungen des Geräts berücksichtigt werden:
rwfilter sample.rw --sipset=local.set --type=all --sport=1-1024
--pass=stdout| rwstats --fields=sip --count=20 --value=dip-distinct
Wenn wir auf die Ergebnisse dieser Abfrage weitere Rwstats-Befehle anwenden, um (wie
in den früheren Beispielen) gezielt einzelne Adressen zu untersuchen, erhalten Sie eingehendere Information über die Dienste, die auf den Geräten in der Liste ausgeführt
werden. Um sich beispielsweise die meistgenutzten Dienste auf 192.168.1.21 anzusehen,
können Sie nach einzelnen Quellports mit mindestens zehn verschiedenen ausgehenden
Verbindungen suchen. Geben Sie dazu die IP-Adresse in Rwfilter an und verwenden Sie in
dem Rwstats-Befehl den Schwellenwertparameter:
rwfilter sample.rw --saddress=192.168.1.21 --type=all --pass=stdout|rwstats
--fields=sport --threshold=10 --value=dip-distinct
Das Ergebnis dieses Befehls sehen Sie in Abb. 11.6.
366 11 Anomaliegestützte Erkennung anhand von statistischen Daten
Abbildung 11.6: Weitergehende Suche nach den Diensten auf einem bestimmten Gerät
In ihrem hervorragenden Artikel »Network Profiling Using Flow« beschreiben Austin
Whisnant und Sid Faber, wie Sie Netzwerkelemente auf diese Weise mithilfe von Sitzungsdaten aufspüren können.2 Darin erklären sie ausführlich, wie Sie die verschiedenen
SiLK-Tools nutzen müssen – hauptsächlich Rwstats –, um ein Netzwerkprofil der wichtigen Elemente und Server aufzustellen. Die Autoren bieten sogar einige Skripte an, um
diesen Erkennungsvorgang zu automatisieren. Dabei wird mit Rwfilter eine Stichprobe
der Daten erstellt (wie in unseren vorherigen Beisielen die Datei sample.rw). Wenn Sie
den Anleitungen aus diesem Aufsatz folgen, können Sie ein genaues Modell der Netzwerk­
elemente aufstellen und Datenmengen anlegen, die für weitere SiLK-Abfragen praktisch
sind. Das ist nützlich, um Informationen über das eigene Netzwerk zu gewinnen (was
wir in Kapitel 14 ausführlicher besprechen werden) und um Bedrohungen zu erkennen.
Dieser Artikel stellt eine hervorragende Ergänzung zu diesem Kapitel dar.
Die Beispielbefehle, die Whisnant und Faber bringen, sind so aufgebaut, dass Sie wirklich
mit hoher Genauigkeit die relevanten Daten sehen. Um Ihnen einige Beispiele dieser Genauigkeit zu geben, habe ich einige der Abfrageanweisungen aus »Network Profiling Using
Flow« in Einzeiler übersetzt. Probieren Sie sie aus, um ausführliche Informationen über
die in Ihrem Netzwerk bereitgestellten Dienste zu bekommen:
Webserver
rwfilter sample.rw --type=outweb --sport=80,443,8080 --protocol=6
--packets=4- --ack-flag=1 --pass=stdout|rwstats --fields=sip --percentage=1
--bytes --no-titles|cut -f 1 -d "|"|rwsetbuild>web_servers.set ;
echo Potential Web Servers:;rwfilter sample.rw --type=outweb
--sport=80,443,8080 --protocol=6 --packets=4- --ack-flag=1
--sipset=web_servers.set --pass=stdout|rwuniq --fields=sip,sport --bytes
--sort-output
E-Mail-Server
echo Potential SMTP servers ;rwfilter sample.rw --type=out
--sport=25,465,110,995,143,993 --protocol=6 --packets=4- --ackflag=1
--pass=stdout|rwset --sip-file=smtpservers.set ;rwfilter
sample.rw --type=out --sport=25,465,110,995,143,993 --sipset=smtpservers.set
--protocol=6 --packets=4- --ack-flag=1 --pass=stdout|rwuniq --fields=sip
--bytes --sort-output
2 http://www.sei.cmu.edu/reports/12tr006.pdf
11.2 Diensterkennung mit SiLK 367
DNS-Server
echo DNS Servers: ;rwfilter sample.rw --type=out --sport=53 --protocol=17
--pass=stdout|rwstats --fields=sip --percentage=1 --packets
--no-titles|cut -f 1 -d "|"| rwsetbuild>dns_servers.set ;rwsetcat
dns_servers.set
VPN-Server
echo Potential VPNs: ;rwfilter sample.rw --type=out --protocol=47,50,51
--pass=stdout|rwuniq --fields=sip --no-titles|cut -f 1 -d "|" |rwsetbuild>vpn.
set ;rwfilter sample.rw --type=out --sipset=vpn.set
--pass=stdout|rwuniq --fields=sip,protocol --bytes --sort-output
FTP-Server
echo -e "\nPotential FTP Servers"; rwfilter sample.rw --type=out --protocol=6
--packets=4- --ack-flag=1 --sport=21 --pass=stdout|rwstats --fields=sip
--percentage=1 --bytes --no-titles|cut -f 1 -d "|"|rwsetbuild>
ftpservers.set ;rwsetcat ftpservers.set ; echo FTP Servers making
active connections: ;rwfilter sample.rw --type=out --sipset=ftpservers.set
--sport=20 --flags-initial=S/SAFR --pass=stdout|rwuniq --fields=sip
SSH-Server
echo -e "\nPotential SSH Servers"; rwfilter sample.rw --type=out --protocol=6
--packets=4- --ack-flag=1 --sport=22 --pass=stdout|rwstats --fields=sip
--percentage=1 --bytes --no-titles|cut -f 1 -d "|"|rwsetbuild>
ssh_servers.set ;rwsetcat ssh_servers.set
TELNET-Server
echo -e "\nPotential Telnet Servers"; rwfilter sample.rw --type=out
--protocol=6 --packets=4- --ack-flag=1 --sport=23 --pass=stdout|
rwstats --fields=sip --percentage=1 --bytes --no-titles|cut -f 1 -d
"|"|rwsetbuild>telnet_servers.set ;rwsetcat telnet_servers.set
Übrige Server
echo Leftover Servers: ;rwfilter sample.rw --type=out
--sport=1-19,24,26-52,54-499,501-1023 --pass=stdout|rwstats --fields=sport
--percentage=1
368 11 Anomaliegestützte Erkennung anhand von statistischen Daten
Zur Erkennung würden diese Befehle regelmäßig ausgeführt und die Ergebnisse eines
Durchlaufs mit denen des vorherigen verglichen. Wenn dabei ein neues Servergerät auftaucht, sollte es untersucht werden.
11.3 Weitere Erkennungsmöglichkeiten mithilfe von
Statistiken
In den meisten Organisationen kommt der Großteil der Berichte über Zwischenfälle aufgrund der kontinuierlichen Analyse und der Analyse der Alarmdaten zustande. Wenn ein
neuer Alarm generiert wird, kann es sinnvoll sein, aus den Sitzungsdaten Statistiken aufzubreiten, um das Vorhandensein ähnlicher Indikatoren auf anderen Hosts zu erkennen.
Betrachten Sie als Beispiel den Alarm aus Abb. 11.7.
Abbildung 11.7: Ein von Snort ausgelöster ZeuS-Alarm
Dieser Alarm wurde ausgelöst, weil es Beweise für die Kommunikation eines Geräts gab,
das bekanntermaßen mit der Steuerung des ZeuS-Botnetzes zu tun hat. Auf den ersten
Blick sieht es so aus, als umfasse diese Kommunikation nur NTP-Datenverkehr, da sie mit
dem Protokoll UDP über Port 123 abgewickelt wurde.
Ohne Zugriff auf die Payload der Pakete (was bei einer rückblickenden Analyse der Fall
sein kann) besteht die Gefahr, dass ein Analytiker diesen Zwischenfall nicht weiter beachtet, da es keine unmittelbaren Indikatoren einer tatsächlich erfolgten Infizierung gibt.
11.3 Weitere Erkennungsmöglichkeiten mithilfe von Statistiken 369
Es besteht zwar die Möglichkeit, dass die eigentliche Kommunikation durch die Verwendung des NTP-Standardports verschleiert wird, aber ohne zusätzliche Informationen lässt
sich das nicht verifizieren. Um weitere Einzelheiten in Erfahrung zu bringen, müssen wir
die weitere Kommunikation mit dem Host untersuchen. Dazu ermitteln wir, ob der Host
noch mit anderen verdächtigen »NTP-Servern« kommuniziert. In diese Abfrage nehmen
wir auch das Feld für den Ländercode auf, da wir (bei einer in den USA heimischen Organisation) erwarten, dass unsere Geräte nur mit NTP-Servern in den USA in Verbindung
treten. Das führt uns zu folgendem Befehl:
rwfilter --start-date=2013/09/02 --end-date=2013/09/02
--anyaddress=192.168.1.17 --aport=123 --proto=17 --type=all --pass=stdout
| rwstats --top --fields=dip,dcc,dport --count=20
Hier verwenden wir Rwstats, um die Geräte anzuzeigen, mit denen 192.168.1.17 über
Port 123 kommuniziert. Das Ergebnis sehen Sie in Abb. 11.8, wobei einige IP-Adressen
anonymisiert wurden.
Abbildung 11.8: Der interne Host kommuniziert über Port 123 mit mehreren anderen Hosts
Wie Sie sehen, kommuniziert der fragliche interne Host mit mehreren externen Hosts
über Port 123. Die Anzahl der Datensätze für die einzelnen Hosts und der enorme Umfang
der Kommunikation deuten darauf hin, dass hier etwas nicht mit rechten Dingen zugeht. Normalerweise synchronisiert ein Host seine NTP-Einstellungen nur mit einem oder
wenigen leicht identifizierbaren Hosts. Die feindselige Natur dieses Datenverkehrs wird
außerdem durch das Vorhandensein von Kommunikationspartnern außerhalb der USA
bestätigt, die von Hosts und Netzwerken in den USA nicht zur NTP-Synchronisierung
herangezogen werden.
370 11 Anomaliegestützte Erkennung anhand von statistischen Daten
Damit liegt ein Zwischenfall vor, der weiter behandelt werden muss. Außerdem haben wir
einen interessanten Indikator gewonnen, mit dem wir mehr entdecken können, als unsere
IDS-Regeln zu bieten haben. Wie immer aber müssen wir uns erst überlegen, was wir eigentlich wollen, bevor wir uns Hals über Kopf auf die Daten stürzen. Bei diesem Ereignis
haben wir nach allen Sitzungsdaten gesucht, bei denen 192.168.1.17 die Quelladresse war
und die Kommunikation über den UDP-Port 123 stattfand. Der übermäßige Umfang des
UDP-Datenverkehrs über Port 123 zu so vielen externen Hosts hast uns zu der Schlussfolgerung gebracht, dass etwas Schädliches vor sich geht. Damit können wir einen Filter
erstellen, der für alle lokalen Adressen nach diesen verdächtigen Merkmalen sucht:
rwfilter --start-date=2013/09/02 --end-date=2013/09/02 --not-dipset=local.set
--dport=123 --proto=17 --type=all --pass=stdout | rwstats --top --fields=sip
--count=20 --value=dip-distinct
Der Filter in diesem Befehl besagt, dass der gesamte nicht für das lokale Netzwerk bestimmte, über das Protokoll UDP abgewickelte und an Port 123 gerichtete Datenverkehr
vom 2.9.2013 untersucht werden soll. Die damit ausgewählten Daten werden an Rwstats
gesendet, das Statistiken für die 20 lokalen IP-Adressen, die mit den meisten verschiedenen Zieladressen kommunizieren (siehe Abb. 11.9).
Abbildung 11.9: Mehrere Geräte mit ähnlichen Kommunikationsmustern
Den Filter können wir noch weiter einengen, indem wir nur nach Datensätzen suchen,
bei denen die UDP-123-Kommunikation zu Hosts außerhalb der USA geht, was einer
der Aspekte ist, die ursprünglich unseren Verdacht erregten. Die folgende Abfrage baut
auf der vorherigen auf, übergibt die Ausgabe des ersten Rwfilters aber an einen zweiten,
11.4 Statistiken mit Gnuplot grafisch darstellen 371
der alle Datensätze mit dem Zielcode us ausschließt (--fail), sodass wir nur Daten über
Verbindungen in andere Länder sehen.
rwfilter --start-date=2013/09/02 --end-date=2013/09/02 --not-dipset=local.set
--dport=123 --proto=17 --type=all --pass=stdout | rwfilter --input-pipe=stdin
--dcc=us --fail=stdout | rwstats --top --fields=sip --count=20
--value=dip-distinct
Eine weitergehende Untersuchung der Ergebnisse kann zur Entdeckung von Schadlogik
auf den Systemen führen, die ein ähnliches Verhalten an den Tag legen wie der Host, für
den der ursprüngliche IDS-Alarm ausgelöst wurde. Ein IDS kann einige Vorkommnisse
einer bestimmten schädlichen Aktivität erkennen, aber nicht alle, und um diese Lücke zu
schließen, eigenen sich statistische Daten. Das hier gezeigte Beispiel stammt übrigens aus
einer wahren Untersuchung, bei der die Analyse schließlich neun weitere infizierte Hosts
ans Tageslicht brachte, die das IDS übersehen hatte.
11.4 Statistiken mit Gnuplot grafisch darstellen
Die grafische Darstellung von Statistiken kann zu wichtigen Einsichten führen, die
sich aus den rohen Zahlen nicht so leicht ablesen lassen. Dafür bieten sich insbesondere Durchsatzstatistiken an. Die Möglichkeit, den Durchsatz an einer Sensorschnittstelle
oder zwischen zwei Hosts zu ermitteln und grafisch darzustellen, ist äußerst nützlich für
verschiedene Formen der Erkennung, insbesondere auf der Grundlage von Anomalien.
Dabei wird ein Alarm ausgelöst, wenn ein Gerät einen erheblich größeren Umfang an
Datenverkehr generiert oder empfängt als üblich. Damit lassen sich beispielsweise das
Herausschmuggeln von internen Daten, der Missbrauch eines internen Hosts zur Bereitstellung von Malware über das Internet oder ein eingehender Denial-of-Service-Angriff
aufspüren. Durchsatzdiagramme helfen Analytikern, ihre Abfragen auf einen kleineren
Zeitraum umzuschränken, was die Analyse beschleunigt.
Eines der nützlicheren Tools, um zu ermitteln, in welchen Zeiträumen bestimmte Daten
jeweils aufgetreten sind und um entsprechende Statistiken zu generieren, ist Rwcount.
Wir haben es schon weiter vorn eingesetzt, um den Zeitraum zu bestimmen, in dem eine
bestimmte Aktivität auftrat. Darüber hinaus können Sie sich damit auch eine Vorstellung
davon machen, wie viele Daten in einzelnen Kommunikationssequenzen übertragen werden. Die einfachste Anwendung besteht darin, herauszufinden, wie viele Daten pro Tag
durch überwachte Netzwerksegmente laufen. Wie bei fast allen SiLK-Abfragen beginnen
wir auch hier mit einem Rwfilter, um die Verarbeitung auf den Zeitraum einzuschränken,
an dem wir interessiert sind. Dann übergeben wir diese Datenmenge an Rwcount, das
die Daten in Behälter für einzelne Zeiträume mit einer bestimmten, vom Benutzer in
Sekunden festgelegten Länge sortiert. Um beispielsweise zu ermitteln, wie viele Datensätze, Bytes und Pakete in jeder einzelnen Minute (--bin-size=60) einer gegebenen Stunde
übertragen werden, geben Sie folgenden Befehl:
372 11 Anomaliegestützte Erkennung anhand von statistischen Daten
rwfilter --start-date=2013/09/02:14 --proto=0- --pass=stdout --type=all |
rwcount --bin-size=60
Den Rwfilter können Sie nach Bedarf ändern, um die Datenmenge festzulegen, die Sie zur
Untersuchung der Durchsatzzahlen heranziehen möchten.
Die Tabellen, die dieser Befehl ausgibt, sind schon an sich nützlich, aber wenn wir die
Daten grafisch darstellen, wird es leichter, Erkenntnisse daraus zu gewinnen. Schauen
wir uns dazu noch einmal das Beispiel aus dem letzten Abschnitt mit dem verdächtigen NTP-Datenverkehr an. Wenn wir die in Abb. 11.9 gezeigten Ergebnisse mit dem
zuvor genannten Rwcount-Befehl genauer untersuchen, können wir mehrere externe
IP-Adressen aus dem Bereich 204.2.134.0/24 erkennen, die ebenfalls NTP-Clientkommunikation anfordern, was auf schädliche Geräte hinweist, die zur Verwendung von
nicht lokalen NTP-Servern konfiguriert sind. Die Verteilung des Datenverkehrs im Tagesverlauf zeigt, dass die Menge der übertragenen Daten pro Minute gleichbleibend ist
(siehe Abb. 11.10). In der üblichen Tabellenform hilft uns diese Angabe nicht weiter, um
den Datenverkehr zu erklären.
Abbildung 11.10: Rwcount zeigt die gleichmäßige Verteilung der Daten über die Zeit
Um uns das Gesamtbild anzusehen, müssen wir die Daten großmaßstäblich grafisch
darstellen. Da SiLK keine Möglichkeiten dazu mitbringt, leiten wir die Ergebnisse der
SiLK-Abfrage zur Ausgabe an Gnuplot (http://www.gnuplot.info/) weiter, eine portable,
befehlszeilengesteuerte Diagrammanwendung. Es handelt sich dabei nicht gerade um
ein intuitiv zu bedienendes Programm für die grafische Darstellung, aber wenn Sie erst
einmal die richtige Konfiguration haben, um vorhandene Daten zu lesen, lassen sich
leicht Skripte für die Zusammenarbeit mit anderen Tools schreiben.
Um die gewonnenen Daten besser nutzen zu können, wollen wir ein Diagramm zeichnen,
das die Menge der Byte pro Stunde für Sitzungsdaten mit IP-Adressen aus dem Bereich
204.2.134.0/24 darstellt. Dazu verwenden wir den gleichen Rwcount-Befehl wie zuvor,
allerdings mit einer Intervalllänge von 3600, sodass die Ergebnisse pro Stunde angezeigt
werden. Die Ausgabe dieses Rwcount-Befehls durchläuft daraufhin einige Aufbereitungsvorgänge in der Befehlszeile. Dadurch wird eine CSV-Datei erstellt, die nur die Zeitstempel
und die damit verbundenen Bytewerte enthält. Insgesamt sieht unser Befehl wie folgt aus:
11.4 Statistiken mit Gnuplot grafisch darstellen 373
rwfilter --start-date=2013/09/02 --any-address=204.2.134.0/24 --proto=0--pass=stdout --type=all | rwcount --bin-size=3600 –delimited=, --no-titles|
cut -d "," -f1,3>hourly.csv
Damit ergeben sich Daten wie die folgenden:
2013/09/02T13:00:00,146847.07
2013/09/02T14:00:00,38546884.51
2013/09/02T15:00:00,1420679.53
2013/09/02T16:00:00,19317394.19
2013/09/02T17:00:00,16165505.44
2013/09/02T18:00:00,14211784.42
2013/09/02T19:00:00,14724860.35
2013/09/02T20:00:00,26819890.91
2013/09/02T21:00:00,29361327.78
2013/09/02T22:00:00,15644357.97
2013/09/02T23:00:00,10523834.82
Als Nächstes müssen wir Gnuplot mitteilen, wie es diese Statistiken grafisch darstellen
soll. Dazu schreiben wir ein Gnuplot-Skript. Ähnlich wie ein BASH-Skript wird es zeilenweise gelesen, es verwendet allerdings Gnuplot-Parameter und ruft in der ersten Zeile
auch Gnuplot als Interpreter auf. Das Skript für unser Beispiel sieht wie folgt aus:
#! /usr/bin/gnuplot
set terminal postscript enhanced color solid
set output "hourly.ps"
set title "Traffic for 204.2.134.0/24 (09/02/2013)"
set xlabel "Time (UTC)"
set ylabel "Bytes"
set datafile separator ","
set timefmt '%Y/%m/%dT%H:%M:%S'
set xdata time
plot 'hourly.csv' using 1:2 with lines title "Bytes"
Wenn das Postscript-Bildformat für Ihre Zwecke nicht geeignet ist, können Sie das Bild in
Linux auch mit folgendem Befehl ins JPG-Format umwandeln:
convert hourly.ps hourly.jpg
Schließlich haben Sie ein fertiges Gnuplot-Durchsatzdiagramm (siehe Abb. 11.11).
374 11 Anomaliegestützte Erkennung anhand von statistischen Daten
Traffic for 204.2.134.0/24 (09/02/2013)
4e+07
Bytes
3.5e+07
3e+07
Bytes
2.5e+07
2e+07
1.5e+07
1e+07
5e+06
0
13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 22:00 23:00
Time (UTC)
Abbildung 11.11: Das Durchsatzdiagramm in Gnuplot
Mit einem BASH-Skript können Sie automatisch Daten zu einem gegebenen Datum und
einem gegebenen Host abrufen und daraus ein Gnuplot-Diagramm erstellen lassen. Das
kann beispielsweise wie folgt aussehen:
#!/bin/bash
#traffic.plotter
echo "Enter Date: (Example:2013/09/02)"
read theday
echo "Enter Host: (Example:192.168.5.0/24)"
read thehost
if [
echo
exit
fi
if [
echo
exit
fi
-z "theday" ]; then
"You forgot to enter the date."
-z "thehost" ]; then
"You forgot to enter a host to examine."
rm hourly.csv
rm hourly.ps
rm hourly.jpg
11.5 Statistiken mit Google Charts grafisch darstellen 375
rwfilter --start-date=$theday --any-address=$thehost --proto=0- --pass=stdout
--type=all -- | rwcount --bin-size=3600 --delimited=, --no-titles| cut -d ","
-f1,3>hourly.csv
gnuplot<< EOF
set terminal postscript enhanced color solid
set output "hourly.ps"
set title "Traffic for $thehost ($theday)"
set xlabel "Time (UTC)"
set ylabel "Bytes"
set datafile separator ","
set timefmt '%Y/%m/%dT%H:%M:%S'
set xdata time
plot 'hourly.csv' using 1:2 with lines title "Bytes"
EOF
convert hourly.ps hourly.jpg
exit
Mit diesem Skript können Sie das Durchsatzdiagramm für die Bytes pro Stunde für jede
gewünschte IP-Adresse oder jeden IP-Adressbereich erstellen lassen. Es lässt sich ziemlich
leicht an die Erfordernisse Ihrer Umgebung anpassen.
11.5 Statistiken mit Google Charts grafisch darstellen
Eine weitere Möglichkeit, Durchsatzdaten und andere Statistiken grafisch darzustellen,
bietet die API von Google Charts (https://developers.google.com/chart/). Google bietet eine
breite Palette von Diagrammen an, um praktisch alle Arten von Daten, die Sie sich vorstellen können, interaktiv und auf verständliche Weise darzustellen. Die meisten mithilfe
dieser API generierten Diagramme funktionieren in allen Browsern, und die Nutzung der
API ist vollständig kostenlos.
Der größte Unterschied zwischen Google Charts und Gnuplot ist die Menge von Anwendungsbeispielen. Gnuplot wird schon seit 1986 entwickelt und kann praktisch alles tun,
was Sie wünschen, sofern Sie sich mit der Sprache auskennen. Da Gnuplot seit so langer
Zeit das Diagrammwerkzeug Nr. 1 ist, gibt es eine unüberschaubare Menge von Beispielen
dafür, wie Sie das erreichen können, was Sie sich vorstellen. Google Charts dagegen ist
noch relativ neu, weshalb es weniger Anwendungsbeisiele gibt. Zum Glück nimmt es jedoch rasch an Beliebtheit zu und bietet schon fertige Lösungen für viele häufig nachgefragte Arten der Darstellung. Um den Einstieg zu erleichtern, hat Google den Google Charts
Workshop eröffnet, in dem die Benutzer nach vorhandenen Beispielen suchen und sie bearbeiten können, um sie mit ihren Daten auszuprobieren, bevor sie sich selbst die Mühe
376 11 Anomaliegestützte Erkennung anhand von statistischen Daten
machen, ein Diagramm zu programmieren. Das Wort »programmieren« verwenden wir
im Zusammenhang mit Google Charts jedoch sehr frei, da die Syntax ziemlich einfach ist.
In diesem Abschnitt sehen wir uns ein einfaches Beispiel an, bei dem wir die von Rwcount
gelieferten Daten in eine HTML-Datei übernehmen, die die API von Google Charts nutzt.
Die meisten modernen Browser können die Ergebnisse anzeigen, ohne dafür irgendwelche Add-Ons oder Erweiterungen zu brauchen.
Für unser Beispiel verwenden wir die gleichen Daten, wie wir auch schon mit Gnuplot dargestellt haben, und erstellen daraus ein Liniendiagramm. Wenn Sie sich die API von Google
Charts für solche Diagramme ansehen, wird Ihnen als Erstes auffallen, dass die Daten nicht
in Form einer normalen CSV-Datei übernommen werden. Stattdessen nimmt die API Datentabellen im JavaScript- und im Objektliteralformat (OL) an. Es gibt verschiedene Tools
und Bibliotheken, um diese Formate zu erzeugen, aber der Einfachheit halber konvertieren
wir unsere CSV-Ausgabe mit ein bisschen Befehlszeilenzauberei in eine OL-Datentabelle.
Im vorherigen Beispiel haben wir eine kleine CSV-Datei mit nur elf Datenpunkten verwendet. Neben diesen Daten brauchen wir Spaltenköpfe, um die Namen der unabhängigen und der abhängigen Variable für jeden Datenpunkt zu definieren. Das heißt, wir
müssen am Anfang unserer CSV-Datei die Zeile Data,Bytes hinzufügen, um die beiden
Spalten zu benennen:
Date,Bytes
2013/09/02T13:00:00,146847.07
2013/09/02T14:00:00,38546884.51
2013/09/02T15:00:00,1420679.53
2013/09/02T16:00:00,19317394.19
2013/09/02T17:00:00,16165505.44
2013/09/02T18:00:00,14211784.42
2013/09/02T19:00:00,14724860.35
2013/09/02T20:00:00,26819890.91
2013/09/02T21:00:00,29361327.78
2013/09/02T22:00:00,15644357.97
2013/09/02T23:00:00,10523834.82
Jetzt können wir diese CSV-Datei durch Sed-Ersetzungsbefehle ins OL-Datentabellenformat umwandeln:
cat hourly.csv | sed "s/\(.*\),\(.*\)/['\1', \2],/g"|sed '$s/,$//'| sed "s/,
\([A-Za-z].*\)],/, '\1'],/g"
Dadurch sehen die Daten wie folgt aus und sind damit bereit, der API zugeführt zu
werden:
11.5 Statistiken mit Google Charts grafisch darstellen 377
['Date', 'Bytes'],
['2013/09/02T13:00:00',
['2013/09/02T14:00:00',
['2013/09/02T15:00:00',
[‘2013/09/02T16:00:00’,
[‘2013/09/02T17:00:00’,
[‘2013/09/02T18:00:00’,
[‘2013/09/02T19:00:00’,
[‘2013/09/02T20:00:00’,
[‘2013/09/02T21:00:00’,
[‘2013/09/02T22:00:00’,
[‘2013/09/02T23:00:00’,
146847.07],
38546884.51],
1420679.53],
19317394.19],
16165505.44],
14211784.42],
14724860.35],
26819890.91],
29361327.78],
15644357.97],
10523834.82]
Diese Daten können wir jetzt in eine HTML-Datei einfügen, die die API aufruft. Die einfachste Möglichkeit dazu besteht darin, den Beispielcode zu nutzen, der in der GoogleDokumentation über Liniendiagramme angegeben ist. Damit erhalten wir folgenden
Code:
<html>
<head>
<script type="text/javascript"
src="https://www.google.com/jsapi"></script>
<script type="text/javascript">
google.load("visualization", "1", {packages:["corechart"]});
google.setOnLoadCallback(drawChart);
function drawChart() {
var data=google.visualization.arrayToDataTable([
['Date', 'Bytes'],
['2013/09/02 T13:00:00', 146847.07],
['2013/09/02 T14:00:00', 38546884.51],
['2013/09/02 T15:00:00', 1420679.53],
['2013/09/02 T16:00:00', 19317394.19],
['2013/09/02 T17:00:00', 16165505.44],
['2013/09/02 T18:00:00', 14211784.42],
['2013/09/02 T19:00:00', 14724860.35],
['2013/09/02 T20:00:00', 26819890.91],
['2013/09/02 T21:00:00', 29361327.78],
['2013/09/02 T22:00:00', 15644357.97],
['2013/09/02 T23:00:00', 10523834.82]
]);
var options={
title: 'Traffic for 204.2.134.0-255'
};
378 11 Anomaliegestützte Erkennung anhand von statistischen Daten
var chart=new google.visualization.LineChart(document.
getElementById(‘chart_div’));
chart.draw(data, options);
}
</script>
</head>
<body>
<div id=”chart_div” style=”width: 900px; height: 500px;”> </div>
</body>
</html>
Abb. 11.12 zeigt, wie das resultierende Diagramm im Browser aussieht, einschließlich
Mouseover-Text.
Traffic for 204.2.134.0-24
40,000,000
Bytes
30,000,000
20,000,000
10,000,000
0
0
0
0
0
0
0
0
0
0
0
0
0:0 :00:0 :00:0 :00:0 :00:0 :00:0 :00:0 :00:0 :00:0 :00:0
0:0
6
5
0
3:0 14:0
7
3
2
1
8
9
1
1
2
1
1
2
2
2
1
1
T
T
T
T
T
T
T
T
T
T
T
/02
/02
/02
/02
/02
/02
/02
/02
/02
/02
/02
/09
/09
/09
/09 3/09
/09
/09
/09
/09
/09
/09
3
3
3
3
3
3
3
3
3
3
1
1
1
1
1
1
1
1
1
1
1
20
20
20
20
20
20
20
20
20
20
20
Abbildung 11.12: Das Durchsatzdiagramm in Google Charts
Ebenso wie die grafische Darstellung in Gnuplot können wir auch die grafische Darstellung in Google Charts mit einem Skript automatisieren. Die im folgenden gezeigte Methode dafür ist der Kürze halber noch roh und unfertig gehalten, funktioniert aber mit ein
bisschen zusätzlicher Benutzerinteraktion.
Hier haben wir in einem Arbeitsverzeichnis das Unterverzeichnis googlecharts angelegt.
Darin erstellen wir eine Reihe von Vorlagen, in die wir Daten einfügen können. Die erste
dieser Vorlagen heißt linechart.html:
11.5 Statistiken mit Google Charts grafisch darstellen 379
<html>
<head>
<script type="text/javascript"
src="https://www.google.com/jsapi"></script>
<script type="text/javascript">
google.load("visualization", "1", {packages:["corechart"]});
google.setOnLoadCallback(drawChart);
function drawChart() {
var data=google.visualization.arrayToDataTable([
dataplaceholder
]);
var options={
title: 'titleplaceholder'
};
var chart=new google.visualization.LineChart(document.
getElementById(‘chart_div’));
chart.draw(data, options);
}
</script>
</head>
<body>
<div id=”chart_div” style=”width: 900px; height: 500px;”></div>
</body>
</html>
In der Vorlage linechart.html gibt es zwei Platzhalter, einen für die Datentabelle (dataplaceholder) und einen für den Titel des Diagramms (titleplaceholder).
Im eigentlichen Arbeitsverzeichnis erstellen wir nun unser Hilfsprogramm zur grafischen
Darstellung mit dem Namen plotter.sh. Dieses BASH-Skript nimmt vom Benutzer Rwfilter- und Rwcount-Befehle entgegen und gibt Diagramme aus. Dazu wandelt es die Ausgabe dieser Befehle in das OL-Datentabellenformat um und stellt sie in eine temporäre
Datei, mit deren Inhalt sie wiederum den Datenplatzhalter in der Vorlage googlecharts/
linechart.html ersetzt. Da es in der Vorlage auch einen Titelplatzhalter gibt, enthält das
Skript eine Variable, in der wir einen Wert für den Titel angeben können.
## NACH BEDARF BEARBEITEN #################################
title=’Traffic for 204.2.134.0-255’
rwfilter --start-date=2013/09/02 T1 --any-address=204.2.134.0/24 --type=all
--proto=0- --pass=stdout | rwcount --bin-size=300 --delimited=,
|\cut -d “,” -f1,3 |\
#############################################
380 11 Anomaliegestützte Erkennung anhand von statistischen Daten
sed "s/\(.*\),\(.*\)/['\1', \2],/g"|sed '$s/,$//'| sed "s/,
\([A-Za-z].*\)],/, '\1'],/g">temp.test
sed '/dataplaceholder/{
s/dataplaceholder//g
r temp.test
}' googlechart/linechart.html | sed "s/titleplaceholder/${title}/g"
rm temp.test
}
linechart
Wenn Sie plotter.sh ausführen, fügt das Skript die passenden Daten in die Vorlage linechart.
html ein.
Dieses Skript ist noch einfach und roh, aber Sie können es erweitern, um auf schnelle
Weise Google-Charts-Diagramme zur Erkennung und Analyse zu generieren.
11.6 Statistiken mit Afterglow grafisch darstellen
Nur allzu leicht kann man sich so tief in die Daten verstricken, dass es äußerst schwierig
wird, anderen zu vermitteln, was sie bedeuten. Manchmal kann man nur erkennen, was
wirklich vor sich geht, wenn man einen Schritt zurücktritt. Das Perl-Tool Afterglow hilft
Ihnen dabei, Linkdiagramme aufzustellen. Solche Diagramme bieten eine grafische Darstellung der Beziehung, die »Elemente in Listen« zueinander haben. Afterglow nimmt eine
zwei- oder dreispaltige CSV-Datei entgegen und gibt entweder eine DOT-Datei in einer
Grafiksprache, wie sie für die Graphviz-Bibliothek erforderlich ist, oder eine GDF-Datei
zurück, die von Gephi verarbeitet werden kann. Beachten Sie, dass Afterglow Ausgabedaten
generiert, die zum Erstellen von Linkdiagrammen genutzt werden können, wobei die eigentliche Erstellung dieser Diagramme Drittanbietertools überlassen bleibt, beispielsweise
Graphviz, das wir im Folgenden nutzen werden. Im Internet gibt es zahlreiche Beispiele
dafür, wie Afterglow Beziehungen in verschiedenen Arten von Datenmengen finden kann.
Die Beispiele auf der Hauptwebseite von Afterglow beziehen sich auf PCAP und Sendmail.
Bevor Sie anfangen, mit Afterglow zu arbeiten, sollten Sie http://afterglow.sourceforge.net
aufsuchen, um das Benutzerhandbuch zu lesen und sich eine Vorstellung von den verfügbaren Funktionen zu machen. Im Grunde genommen brauchen Sie lediglich eine CSVDatei mit Ihren Daten, die Sie auf die richtige Weise an Afterglow übergeben müssen, um
im Handumdrehen das Diagramm zu bekommen.
Laden Sie Afterglow herunter und platzieren Sie es in einem Arbeitsverzeichnis. Um das
folgende Beispiel nachvollziehen zu können, brauchen Sie auch Zugriff auf die SiLK-Tools.
Nach dem Herunterladen und Entpacken von Afterglow, müssen Sie unter Umständen (je
nachdem, was auf Ihrem System vorhanden ist) noch ein Perl-Modul installieren. Wenn
ja, führen Sie folgenden Befehl aus:
11.6 Statistiken mit Afterglow grafisch darstellen 381
sudo /usr/bin/perl -MCPAN -e'install Text::CSV'
Zur grafischen Darstellung verwenden wir die Werkzeuge von Graphviz, das Sie mit dem
Paketverwaltungsprogramm Ihrer Linux-Distribution installieren können. Graphviz ist
eine Open-Source-Visualisierungssoftware von AT&T Research, die zahlreiche Hilfsprogramme für verschiedene Arten von Linkdiagrammen enthält. Die Dokumentation der
einzelnen Graphviz-Tools finden Sie auf http://www.graphviz.org/Documentation.php. Um
Graphviz in Security Onion zu installieren, verwenden Sie APT:
sudo apt-get install graphviz
An dieser Stelle sollten Sie sich im Arbeitsverzeichnis von Afterglow befinden. Für
­A fterglow benötigen Sie eine Konfigurationsdatei, allerdings ist die Beispielkonfiguration sample.properties im Lieferumfang enthalten. Sie sollten dieser Datei die Zeile
xlabels = 0 hinzufügen, damit Beschriftungen korrekt angezeigt werden. Denken Sie
bei der Zusammenstellung der Daten an die beiden »Modi«, die ich zuvor erwähnt
habe, nämlich zwei- und dreispaltig. Im Zweispaltenmodus haben Sie nur eine Quelle
(IP-Quelladresse) und ein Ziel (IP-Zieladresse). Wenn eine dritte Spalte zur Verfügung steht, lautet die Anordnung »Quelle«, »Ereignis«, »Ziel«.
Um ein Linkdiagramm zu erstellen, legen wir als Erstes mithilfe von SiLK eine CSV-Datei
mit den Daten an, die innerhalb einer Stunde im Netzwerk übertragen werden. Das zu
untersuchende Netzwerk sei in unserem Beispiel 184.201.190.0/24. Um die zusätzliche
Datenaufbereitung so gering wie möglich zu halten, fügen wir schon im Rwcut-Befehl
einige ergänzende Optionen hinzu:
rwfilter --start-date=2013/09/06:15 --saddress=184.201.190.0/24
--type=all --pass=stdout | rwcut --fields=sip,dip --no-titles --delimited=, |
sort -u>test.data
Führen Sie diesen Befehl aus und überprüfen Sie, ob die Datei test.data in jeder Zeile eine
Kombination aus Quell- und Ziel-IP-Adresse enthält. Damit haben Sie den schwierigen
Teil schon abgeschlossen. Um daraus das Linkdiagramm zu erstellen, haben Sie zwei Möglichkeiten. Die erste besteht darin, die Daten an Afterglow zu übergeben und mit dem
Argument -w eine DOT-Datei zu erstellen, die von Graphviz-Tools wie Neato verarbeitet
werden kann. Sie können die Ausgabe von Afterglow aber auch direkt an Neato übergeben. Da Sie Afterglow wahrscheinlich ausschließlich verwenden werden, um Daten an
eine Grafikanwendung Ihrer Wahl zu übergeben, verwenden wir in unserem Beispiel die
zweite Möglichkeit.
Um das Diagramm zu erstellen, führen Sie folgenden Befehl aus:
cat test.data | perl afterglow.pl -e 5 -c sample.properties -t | neato -Tgif
-o test.gif
382 11 Anomaliegestützte Erkennung anhand von statistischen Daten
Das Argument -e bestimmt, wie »groß« das Diagramm sein wird. Mit -c geben Sie die
zu verwendende Konfigurationsdatei an, wobei wir hier die im Lieferumfang enthaltene
Beispieldatei nehmen, und -t bedeutet, dass wir den Zweispaltenmodus nutzen. Die Daten
werden schließlich an Neato übergeben, wobei das Argument -T dafür sorgt, dass eine GIFDatei erstellt wird und wir mit -o den Dateinamen angeben können. Die resultierende Datei
test.gif sehen Sie in Abb. 11.13.
Abbildung 11.13: Ein aus Flussdaten erstelltes Linkdiagramm
Wenn Sie das Beispiel nachvollzogen haben, sehen Sie ein ähnliches Diagramm wie in
der Abbildung, allerdings möglicherweise mit anderen Farben. Welche Farben Afterglow für die Darstellung nimmt, wird in der Konfigurationsdatei festgelegt, wobei laut
11.6 Statistiken mit Afterglow grafisch darstellen 383
sample.properties bestimmte Farben für RFC-1918-Adressen verwendet werden. Wenn
Sie keinen dieser Bereiche verwenden (wie in unserem Beispiel), erscheinen die Quellknoten in Rot. Schauen Sie sich die Beispielkonfiguration genau an, da es wahrscheinlich sinnvoll sein wird, die Farbzuordnung für Ihre lokalen Bereiche zu ändern. Denken
Sie daran, dass von den in der Konfiguration genannten Farben jeweils die erste passende genommen wird. Wenn Sie beispielsweise die folgende Konfiguration verwenden,
werden alle Quellknoten blau dargestellt, da die erste Anweisung stets als true aufgefasst
wird und daher die erste Übereinstimmung liefert:
color.source="blue"
color.source="greenyellow" if ($fields[0]=_/˄192\.168\.1\..*/);
color.source="lightyellow4" if ($fields[0]=_/˄172\.16\..*/);
Damit haben wir einige hübsche Daten. Im nächsten Beispiel wollen wir einige nützliche
Daten erstellen. Dazu wollen wir uns die von unserem lokalen Adressbereich ausgehenden Verbindungen außerhalb der Geschäftsstunden ansehen. Dabei verwenden wir den
Dreispaltenmodus und schreiben eine eigene Konfigurationsdatei, die uns in die Lage versetzt, verschiedene Anomalien optisch zu erkennen. Wir erwarten nicht, dass Benutzer
außerhalb der Geschäftsstunden im Internet unterwegs sind, und abgesehen von gelegentlichen Antworten auf eingehende Verbindungen von externen Hosts sollte auch keine
umfangreiche ausgehende Serverkommunikation auftreten. Wie immer müssen wir uns
auch hier erst einmal eine Vorstellung davon machen, was wir als Datenmenge für die
weitere Verarbeitung verwenden wollen. Anhand des Diagramms wollen wir verschiedene
Dinge sichtbar machen. Daher erkläre ich Ihnen die einzelnen Spalten, während wir die
Konfiguration durchgehen. Außerdem zeige ich Ihnen, wie Sie den ganzen Vorgang zum
Erstellen des Diagramms zu einem einzeiligen Befehl zusammenfassen.
Als Erstes legen wir die Konfigurationsdatei an. Damit die Diagrammbeschriftungen
nicht verloren gehen, beginnen wir darin mit der Zeile xlabels=0. Wir wollen ein Linkdiagramm erstellen, das uns eine gute Vorstellung davon gibt, wie die lokalen Geräte mit der
Welt außerhalb des internen Netzwerks kommunizieren. Dabei gehen wir davon aus, dass
alle lokalen Adressen »gut« sind, weshalb wir color.source auf green setzen.
Um Anomalien sofort erkennen zu können, erhalten die Zielknoten ihre Farbe jeweils
aufgrund bestimmter Bedingungen. Um den Unterschied zwischen normalen Serverantworten und unerwarteten Antworten über Ports mit hoher Nummer sichtbar zu machen,
wollen wir jede Art von Kommunikation über einen Quellport größer als 1024 kennzeichnen. Dazu verwenden wir die Anweisung color.target="orange" if ($fields[1]>1024),
damit Afterglow alle Knoten der dritten Spalte (Zielknoten), bei denen der Wert in der
zweiten Spalte (Ereignisknoten) größer als 1024 ist, in Orange darstellt. Der Verweis auf
die Spalten in der CSV-Datei erfolgt am besten mithilfe von Feldangaben, wobei Feld 0 die
erste Spalte ist, Feld 1 die zweite usw.
Außerdem wollen wir uns ansehen, welche ausländischen Geräte nach Geschäftsschluss
Antworten von unseren Servern empfangen. Dabei sind wir besonders an Geräten in China
interessiert. Da es sich dabei durchaus auch um legitime Verbindungen handeln kann, fär-
384 11 Anomaliegestützte Erkennung anhand von statistischen Daten
ben wir die chinesischen Knoten mit color.target="yello" if ($fields[3]=~/cn/) gelb.
Mit dem Verweis auf das dritte Feld beziehen wir Informationen aus der vierten Spalte der
CSV-Datei. Sie wird zwar nicht für Knoten verwendet, enthält aber Verweise zu anderen
Knoten in derselben Zeile. Daher bedeutet der Befehl, dass wir den Knoten in der dritten
Spalte gelb färben, wenn im Text der viertel Spalte derselben Zeile irgendwo cn steht.
Wenn ein Knoten beide Bedingungen erfüllt, wollen wir besonders stark auf ihn aufmerksam
gemacht werden. Sollten also lokale Geräte über nicht standardmäßige Ports mit Adressen in
China kommunizieren, stellen wir die entsprechenden Zielknoten rot dar. Dazu müssen wir
die Bedingung angeben, dass der Quellport größer 1024 ist UND die vierte Spalte derselben
Zeile den Text cn enthält. Diese UND-Verknüpfung erreichen wir mit der Anweisung color.
target="red" if (grep($fields[1]>1024,$fields[3]=_/cn/)).
Wie bereits erwähnt, kommt es auf die Reihenfolge der Konfigurationszeilen an. Ich
empfehle Ihnen, sie von der strengsten zur lockersten Bedingung zu ordnen. Unsere
Konfigurationsdatei (nennen wir sie config.properties) sieht insgesamt wie folgt aus:
## Platziert alle Beschriftungen auf den Knoten
xlabels=0
## Färbt alle Quellknoten (Adressen in der ersten Spalte) grün
color.source="green"
## Färbt Zielknoten rot, bei denen der Quellport größer 1024 ist und die
## vierte Spalte "cn" enthält
color.target="red" if (grep($fields[1]>1024,$fields[3]=_/cn/))
## Färbt Zielknoten gelb, bei denen die vierte Spalte "cn" enthält
color.target="yellow" if ($fields[3]=_/cn/)
## Färbt Zielknoten rot, bei denen der Quellport größer 1024 ist
color.target="orange" if ($fields[1]>1024)
## Färbt Zielknoten blau, wenn keine der Bedingungen erfüllt ist
color.target="blue"
## Färbt Ereignisknoten der zweiten Spalte weiß
color.event="white"
## Färbt Verbindugnslinien schwarz und gibt ihnen die Dicke "1"
color.edge="black"
size.edge=1;
Um die erforderlichen Daten für dieses Diagramm zu generieren, verwenden wir den
folgenden Befehl:
rwfilter --start-date=2013/09/06:15 --saddress=184.201.190.0/24
--type=out,outweb --pass=stdout |\rwcut --fields=sip,sport,dip,dcc
--no-titles --delimited=,|\ sort -u|perl afterglow.pl -e 5 -c
config.properties -v |\neato -Tgif -o test.gif
11.6 Statistiken mit Afterglow grafisch darstellen 385
Mit den Optionen out und outweb im Argument type des Rwfilter-Befehls sorgen wir
dafür, dass nur ausgehender Datenverkehr berücksichtigt wird. Um die vier Spalten zu
erstellen, die wir benötigen, verwenden wir das Argument --fields=sip,sport,dip,dcc.
Die Ausgabe dieses Befehls wird direkt an Afterglow und Neato geleitet, um das Diagramm test.gif zu erstellen, das Sie in Abb. 11.14 sehen.
Abbildung 11.14: Benutzerdefiniertes Linkdiagramm für ausgehende Verbindungen
Die Vielseitigkeit von Afterglow ermöglicht es Ihnen, verschiedene Arten von Link­
diagrammen zu erstellen. Solche Diagramme sind in Situationen nützlich, in denen Sie die
Beziehungen zwischen Elementen untersuchen müssen. Diese Beispiele sollten Ihnen einen
Vorgeschmack auf die Möglichkeiten geben, die sich Ihnen bieten, und Sie in die Lage versetzen, Linkdiagramme mit der für Ihre Zwecke geeigneten Gestaltung zu erstellen.
386 11 Anomaliegestützte Erkennung anhand von statistischen Daten
11.7 Zusammenfassung
Den Fluss der Daten in Ihrer Umgebung im Bezug zu den Benutzern und dem Netzwerk
als Ganzem zu verstehen, stellt eine große Herausforderung dar. Es gibt jedoch eine Reihe
von statistischen Daten, die Sie aufstellen können, um Ihr Wissen über das Datennetzwerk
und die darin auftretende Kommunikation stets auf dem neuesten Stand der Entwicklung
Ihrer Organisation zu halten. Die Kernfrage dieses Kapitels lautete, wie Sie aus den Daten, die Sie haben, noch brauchbarere Daten gewinnen, die es Ihnen erlauben, sich einen
Überblick zu verschaffen. Dieser Überblick besteht manchmal darin, Listen aufzustellen,
die große Datenmengen in allgemeinere Kategorien fassen. Manchmal ist der Überblick
aber auch nur einfach ein Überblick im Sinne des Wortes. In diesem Kapitel haben Sie
zwar nicht gelernt, wie Sie Statistiken oder grafische Darstellungen für alle Situationen erstellen können, denen Sie bei den Erkennungs- und Analyseaufgaben des NSM begegnen
mögen, aber wir hoffen, dass wir Ihnen damit über die erste Hürde zum Erlernen dieser
Werkzeuge hinweggeholfen und ein Samenkorn gelegt haben, sodass Sie selbst nützliche
Statistiken für Ihre Umgebung aufstellen können.
12
Frühwarn-Honeypots zur Erkennung
Ein Honeypot ist eine Sicherheitseinrichtung, die eigens dazu da ist, sondiert, angegriffen und geknackt zu werden. In der Praxis wird dafür gewöhnlich ein System oder eine
Software verwendet, die ein anderes System oder einen Dienst nachahmt, aber absichtlich Schwachstellen aufweist. Dieses System wird so platziert, dass Angreifer es finden
und eindringen können. In Wirklichkeit jedoch enthält dieser Honeypot keine echten
Daten von irgendeinem Wert und ist von den anderen Netzwerkgeräten getrennt. Mit
den ausführlichen Protokollinformationen, die auf dem Honeypot erfasst wurden, können ­Sicherheitsteams herausfinden, welche Werkzeuge, Taktiken und Prozeduren die
Angreifer einsetzen.
In Produktionsnetzwerken sind nur selten Honeypots zu finden, da es widersinnig erscheint, in einer solchen Umgebung ein System bereitzustellen, das zum Einbruch einlädt.
Tatsächlich werden Honeypots meistens in Forschungs- und Lehrumgebungen eingesetzt.
Einige Organisationen, die sehr erfahren in NSM sind, sehen Honeypots jedoch als eine
Erkennungsmaßnahme an. In diesem Kapitel sehen wir uns an, was Frühwarn-Honeypots
sind und welche verschiedenen Arten von Honeypots Sie für NSM einsetzen können. Außerdem beschäftigen wir uns damit, wie Sie Frühwarn-Honeypots platzieren, wie Sie die
Protokollierung darauf durchführen und wie Sie sie bestmöglich einsetzen. Des Weiteren
stellen wir einige beliebte Softwarelösungen für Honeypots vor.
388 12 Frühwarn-Honeypots zur Erkennung
Zuvor aber möchte ich klarstellen, dass einige der Verteidigungsmöglichkeiten, die ich
in diesem Kapitel vorstelle, sehr umstritten sind. Manche Organisationen verzichten aus
rechtlichen Gründen auf die Verwendung von Honeypots, worauf ich hier nicht weiter
eingehen werde; das besprechen Sie lieber mit Ihrem Anwalt. Anderen Organisationen
ist nicht klar, wie sie ihre Umgebung so absichern sollen, dass ein Angreifer, der einen
Honeypot geknackt hat, diesen »Erfolg« nicht auf unerwartete Weise ausnutzen kann.
Andere sehen keinen betrieblichen Wert in einem Honeypot. Ganz unabhängig von Ihrer
Haltung gegenüber Honeypots muss ich aber betonen, dass deren Einrichtung für Zwecke
des NSM sehr arbeitsintensiv ist und sich gewöhnlich nur für Sicherheitsorganisationen
eignet, die eine Überwachung rund um die Uhr durchführen können.
12.1 Frühwarn-Honeypots
Ein Frühwarn-Honeypot ahmt ein Produktionssystem nach und wird auf eine Weise
bereitgestellt, dass es zur frühzeitigen Erkennung eines Netzwerkeinbruchs beitragen
kann. Es gibt zwei verschiedene Arten dieser Honeypots, nämlich angreifbare und nicht
angreifbare.
Ein angreifbarer Frühwarn-Honeypot enthält zwar Software, die einen echten Dienst
nachahmt, aber auch eine Schwachstelle. Wenn ein Angreifer diese Schwachstelle ausnutzt, erhält er gewöhnlich begrenzten Zugriff auf eine simulierte Umgebung, die ihn
glauben machen soll, dass er mit dem echten System arbeitet. Währenddessen schreibt
die Honeypot-Software ausführliche Protokolle, um die Methoden des Angreifers für den
Einbruch in den gefälschten Dienst und seine Aktionen in der simulierten Umgebung
festzuhalten. Dies kann mit anderen Formen der Erkennung kombiniert werden, z. B.
IDS-Signaturen, sodass Analytiker den Honeypot als Informationsquelle für die Erkennung nutzen können.
Ein nicht angreifbarer Frühwarn-Honeypot stellt die gleichen legitimen Dienste bereit
wie das Produktionssystem, das er zu sein vorgibt, ist aber nicht dafür ausgelegt, von einem Angreifer ausgenutzt zu werden. Der einzige Unterschied zwischen dem Honeypot
und dem echten Produktionssystem besteht darin, das die legitimen Systeme im Netzwerk
nicht mit dem Honeypot kommunizieren. Jeder Verbindungsversuch mit diesem System
ist daher verdächtig. Der Angreifer bekommt zwar keinen Zugriff auf das System, doch
wenn er versucht, sich daran anzumelden, es zu scannen oder auf irgendeine andere Weise
damit zu kommunizieren, wird von dem in der Umgebung vorhandenen signatur-, anomalie- oder statistikgestützten Erkennungsmechanismus ein Alarm ausgelöst. Das ähnelt
dem Prinzip unserem Darknet-Beispiel aus Kapitel 10.
Da keine dieser beiden Arten von Honeypots einen Dienst bietet, der einen Nutzen für
den wirklichen Betrieb hätte, gibt es keinen legitimen Grund, Kontakt damit aufzunehmen. Die ausführliche Protokollierung und die ausnahmslose Alarmierung wären bei
12.2 Arten von Honeypots 389
einem Produktionssystem nicht möglich, da dadurch zu viele Fehlalarme auftreten würden, aber auf einem System, mit dem niemand kommunizieren sollte, bilden sie eine
hervorragende Lösung.
Beachten Sie jedoch, dass ein Frühwarn-Honeypot nicht dazu geeignet ist, Angreifer zu
erkennen, die erst anfangen, sich Zugriff zu dem Netzwerk zu verschaffen. Was der Honeypot bemerkt, sind die Aktionen von Angreifern, die bereits einen Fuß in der Tür haben
und versuchen, ihren Zugriff zu erweitern. Wie raffiniert die Angreifer auch immer sein
mögen, sie werden stets den Weg des geringsten Widerstands gehen und sich nur so weit
tarnen, wie es erforderlich ist. Das Überhandnehmen von Social Engineering und gezielten Phishingangriffen hat die Verteidigung des Perimeternetzwerks und die Erkennung
von Übergriffen an dieser Grenze erschwert.
12.2 Arten von Honeypots
Honeypots werden nach dem Grad an Interaktion eingeteilt, die sie bieten, und gewöhnlich als Honeypots mit geringer oder hoher Interaktion bezeichnet. Um den erforderlichen Grad an Interaktion für Ihre Honeypot-Bereitstellung zu bestimmen, müssen Sie
die Ziele Ihrer Organisation, die zu schützenden Werte und die zu imitierenden Dienste
berücksichtigen.
Honeypots mit geringer Interaktion werden gewöhnlich in Form von Software bereitgestellt und dienen dazu, einen oder mehrere Dienste zu simulieren. Welchen Grad an Interaktion sie bieten, hängt einerseits von der Software selbst ab, aber auch davon, welchen
Dienst sie nachahmen. Die Honeypot-Software Kippo beispielsweise, die den SSH-Dienst
imitiert, erlaubt einem Angreifer, sich an dem Dienst anzumelden und sogar ein gefälschtes Dateisystem zu durchsuchen, aber nicht, auf die echten Komponenten des zugrunde
liegenden Betriebssystems zuzugreifen.
Honeypots mit hoher Interaktion dagegen spiegeln gewöhnlich ein echtes Produktionssystem wider. Sie verleiten Angreifer dazu, das Betriebssystem zu knacken, und stellen ihm
für diesen Fall auch ausgiebigen Zugriff darauf bereit. Allerdings findet auf dem ­Honeypot
auch eine detaillierte Betriebs- und Dateisystemprotokollierung und eine Überwachung
anhand eines erschöpfenden Satzes von IDS-Regeln statt. Honeypots mit hoher Interaktion werden oft als virtuelle Maschinen bereitgestellt, sodass sie sich relativ leicht auf einen
sauberen Zustand zurücksetzen lassen.
Bei der Einrichtung eines Honeypots mit hoher Interaktion müssen Sie besondere Maßnahmen treffen, um zu verhindern, dass der Angreifer das System als Ausgangspunkt für
Angriffe auf andere Systeme nutzt. Es muss den Angreifern möglich sein, in das System
einzudringen und darauf einige Aktivitäten durchzuführen, ohne es aber so weit zu übernehmen, dass sie damit legitime Systeme im Netzwerk angreifen können.
390 12 Frühwarn-Honeypots zur Erkennung
Achtung
Manche Honeypots werden als Lösungen mit »mittlerer Interaktion« angeboten,
also als Mittelding zwischen denen mit geringer und mit hoher Interaktion. Das
gilt beispielsweise für Kippo, da die Software zwar einerseits einen Dienst simuliert, andererseits aber auch ein gefälschtes Dateisystem, mit dem ein Angreifer
tatsächlich in Interaktion treten kann. Das steht im Gegensatz zu Einrichtungen
wie etwa Tom’s Honeypot, bei dem es sich um einen echten Honeypot mit geringer Interaktion handelt, da er mithilfe von Software einen Dienst simuliert, aber
keine gefälschte Umgebung vorspiegelt, mit der ein Angreifer nach dem Einbruch
interagieren könnte. Die Bezeichnung »Honeypot mit mittlerer Interaktion« mag
in manchen Fällen zwar angebracht sein, doch in diesem Buch werden wir sie
unter die Honeypots mit geringer Interaktion rechnen, da es sich gewöhnlich um
Anwendungen handelt, die auf einem anderen System laufen, anstatt ein eigenes
Betriebssystem mitzubringen.
Honeypots mit hoher Interaktion sind nützlich, um Informationen über raffinierte Gegner zu bekommen. Sie erfordern allerdings ein hohes Maß an Arbeit und Sorgfalt für die
Einrichtung sowie eine ständige, lückenlose Überwachung.
Dagegen lassen sich Honeypots mit geringer Interaktion im Allgemeinen leichter einrichten und betreiben. Außerdem stellen sie aufgrund ihrer Einfachheit das geringste Risiko
für die Umgebung dar. Da wir sie im Rahmen der NSM für die Erkennung einsetzen
wollen, sind für unsere Zwecke Honeypots mit geringer Interaktion am besten geeignet,
weshalb wir uns in diesem Buch darauf konzentrieren werden.
12.3 Architektur von Frühwarn-Honeypots
Wie alle anderen Aspekte des NSM muss auch die Bereitstellung von Frühwarn-Honeypots
sorgfältig geplant und auf die Bedrohungen zugeschnitten sein, denen die Organisation
ausgesetzt ist (siehe auch die Erörterung des Applied Collection Framework in Kapitel 2).
Die Planung der Bereitstellung von Honeypot-Systemen umfasst drei Schritte:
1. Die zu simulierenden Geräte und Dienste bestimmen
2. Die Platzierung der Honeypots bestimmen
3. Alarmierung und Protokollierung entwickeln
Sehen wir uns diese drei Phasen nun im Einzelnen an.
12.3 Architektur von Frühwarn-Honeypots 391
12.3.1
Phase 1: Die zu simulierenden Geräte und Dienste bestimmen
Die Risikoanalyse, die Sie bei der Planung der NSM-Erfassung vorgenommen haben, sollte Ihnen schon eine Vorstellung davon vermittelt haben, welche Netzwerkelemente hohe
Priorität genießen. Das sind auch die Hauptkandidaten für die Systeme, deren Dienste auf
einem Honeypot simuliert werden sollten. Wenn in den Honeypot eingebrochen wird,
erfolgt ein Alarm, der ein frühes Warnzeichen dafür ist, dass ähnliche Dienste hoher Priorität als Nächstes angegriffen werden könnten – oder dass dies schlimmstenfalls schon
geschehen ist.
Dazu ist es am besten, Honeypotsoftware bereitzustellen, die die von den kritischen Systemen bereitgestellten Dienste simuliert. In der Praxis gibt es natürlich keine Software, die
in der Lage ist, jeden von Ihrer Organisation als kritisch eingestuften Dienst zu simulieren,
aber es gibt Lösungen, die eine Menge der gängigeren Dienste imitieren.
Betrachten wir als Beispiel eine Umgebung, in der es sich bei den wichtigsten Netzwerk­
elementen um eine Gruppe von Windows-Servern handelt, die nicht extern zugänglich
sind und eine proprietäre interne Anwendung für die Finanzbuchhaltung bereitstellen.
Diese Windows-Server gehören zu einer Domäne und werden über das Protokoll RDP
(Remote Desktop Protocol) verwaltet. Es könnte ziemlich schwierig sein, die interne Anwendung als Honeypot zu simulieren, aber der RDP-Dienst ist ein idealer Kandidat dafür. Das Produkt Tom’s Honeypot, das wir später noch ausführlicher besprechen werden,
kann einen RDP-Server nachahmen und löst einen Alarm aus, wenn jemand auch nur
versucht, sich an diesem Server anzumelden. Auf den echten RDP-Servern wäre es nicht
möglich, alle RDP-Anmeldeversuche zu protokollieren und zu untersuchen, aber die von
dem RDP-Honeypot ausgelösten Alarme zu überprüfen ist sicherlich eine lösbare Aufgabe. Schließlich sollte niemand jemals versuchen, sich an diesem System anzumelden, da es
nicht mit dem Internet verbunden ist.
Betrachten wir als zweites Beispiel eine Organisation, die mehrere Linux-Server für die
Back-End-Datenbanken ihrer öffentlichen E-Commerce-Website unterhält. Diese Server
sind öffentlich nicht zugänglich, und die einzigen Dienste, die sie intern ausführen, sind
SSH für die Serververwaltung und MySQL für die Datenbanken. Beide lassen sich als
Honeypots simulieren, SSH beispielsweise mit Kippo und MySQL mit Tom’s Honeypot.
Auch hier gilt wieder, dass niemand einen legitimen Grund hat, sich jemals an diesen
Systemen anzumelden, weshalb jeglicher Zugriff darauf einen Alarm auslösen und als
Warnung betrachtet werden sollte, dass es wahrscheinlich einen Einbruch gegeben hat
und ein Angriff auf die kritischen Systeme bevorstehen mag.
12.3.2 Phase 2: Die Platzierung der Honeypots bestimmen
Nachdem Sie bestimmt haben, welche Dienste Sie simulieren wollen, müssen Sie die
Honeypotsysteme in Ihrem Netzwerk platzieren. Auf den ersten Blick scheint dazu nicht
mehr erforderlich zu sein, als die Honeypotanwendung auf einem Host bereitzustellen
und mit dem Netzwerk zu verbinden, aber es gibt noch einige Überlegungen, die Sie
zuvor anstellen müssen.
392 12 Frühwarn-Honeypots zur Erkennung
Erstens müssen Sie den Honeypot in demselben Netzwerksegment bereitstellen wie die
Elemente, die er simuliert. Steht er in einem anderen Segment, dann ist ein Einbruch in
den Honeypot kein Indiz dafür, dass sich ein Angreifer Zugang zu dem Segment verschafft
hat, das Sie schützen wollen. Betrachten Sie zur Veranschaulichung Abb. 12.1.
Darin sind mehrere Netzwerksegmente zu sehen. Das am stärksten bedrohte Segment
ist in diesem Fall das Forschungssegment. Neben den echten Servern in diesem Segment
stellen wir die zugehörigen Honeypotsysteme bereit: für die Linux-Dateiserver ein SSHHoneypot, für die Windows-Anwendungsserver einen RDP-Honeypot und für die Webserver einen HTTP-Honeypot.
Der wichtigste Zweck der Honeypotsysteme besteht darin, einen Alarm auszulösen und
Daten zu protokollieren, wenn jemand versucht, auf sie oder auf ihre Dienste zuzugreifen.
Daher müssen wir dafür sorgen, dass Daten vom Honeypot zu einem NSM-Sensor oder
einem Protokollierungsgerät übertragen werden können. In Abb. 12.1 ist Sensor B für
die Erkennung in dem genannten Netzwerksegment verantwortlich, indem er die Daten
analysiert, die in dieses Segment ein- und aus ihm herausgehen.
Sie müssen jedoch nicht nur dafür sorgen, dass der Honeypot seine Rolle vollständig erfüllen kann, sondern müssen auch die Kommunikation begrenzen, an der er teilnehmen
kann. Der Honeypot sollte zwar in der Lage sein, auf dieselben Arten von Anforderungen
zu antworten wie das echte Element, das er nachahmt, allerdings muss verhindert werden, dass er irgendeine Kommunikation mit anderen Hosts auslöst. Das können Sie durch
strenge Firewallregeln auf dem vorgeschalteten Router erreichen. In Abb. 12.1 ist das der
Router des Forschungsnetzwerks.
12.3 Architektur von Frühwarn-Honeypots 393
Abbildung 12.1: Platzierung von Frühwarn-Honeypots in der Nähe schützenswerter Elemente
12.3.3 Phase 3: Alarmierung und Protokollierung entwickeln
Der letzte Schritt bei der Bereitstellung von Frühwarn-Honeypots besteht darin, die Protokollierung und Alarmierung zu entwickeln, mit der Analytiker informiert werden, wenn
ein Angreifer mit einem Honeypotsystem interagiert.
Als Erstes müssen Sie sich klarmachen, welche Fähigkeiten die von Ihnen verwendete Honey­potsoftware mitbringt. Manche Software kann Daten generieren, die sich als
Alarmdaten nutzen lassen, beispielsweise MySQL-Datenbankeinträge oder Syslog-­
Ereignisse. Wenn das nicht möglich ist, können Sie versuchen, die Honeypotsoftware mit
einem anderen Erkennungsmechanismus zu kombinieren, um einen Alarm auszulösen.
Um die beste Möglichkeit zu finden, Alarme hervorzurufen, ohne dafür die Honeypotsoftware selbst zu nutzen, müssen Sie überlegen, wo sich der NSM-Sensor relativ zu dem
Honeypotsystem befindet. In Abb. 12.1 ist der Sensor dem kritischen Netzwerksegment
mit dem Honeypot unmittelbar vorgeschaltet. Wenn ein Angreifer von einem anderen
internen Netzwerksegment aus auf die Honeypots zugreift, können Sie den Erkennungsmechanismus auf diesem Sensor nutzen – sei es Snort, Suricata, Bro oder ein statistisches
Werkzeug –, um Alarm auszulösen.
394 12 Frühwarn-Honeypots zur Erkennung
Da jede Interaktion mit dem Honeypot unnormal ist, können Sie Alarme auf der Grundlage der gewöhnlichen Kommunikationssequenzen erstellen, die bei der Verwendung des
simulierten Dienstes auftreten. In der Situation von Abb. 12.1 sind beispielsweise IDSSignaturen für folgende Ereignisse angebracht:
1. SSH-Honeypot: Übertragung eines SSH-Serverbanners erkannt
2. RDP-Honeypot: RDP-Anmeldung erkannt
3. HTTP-Honeypot: GET-, POST- oder ähnliche HTTP-Anforderung erkannt
Wenn ein Angreifer ein System innerhalb des kritischen Netzwerksystems in seine Gewalt
gebracht hat und von dort aus auf das Honeypotsystem zugreift, kann der Sensor die
entsprechenden Aktionen wahrscheinlich nicht erkennen, da sie die Sensorgrenzen nicht
überschreiten können. Um auch in solchen Fällen Alarmdaten zu generieren, können sie
auf dem Honeypothost selbst einen hostgestützten Erkennungsmechanismus einrichten.
Dieser Mechanismus kann ein Bestandteil der Honeypotsoftware sein, aber auch eine
Drittanbieterlösung wie OSSEC für die hostgestützte Erkennung oder sogar ein selbst
geschriebenes Skript. In unserem Beispiel würde dieser Mechanismus seine Meldungen
direkt an Sensor B oder an ein anderes vorgeschaltetes System senden, das Protokolldaten
erfasst.
Wenn ein Alarm ausgelöst wurde, müssen die Analytiker die Möglichkeit haben, die von
dem Honeypotsystem erstellen Protokolle zu untersuchen, um herauszufinden, was der
Angreifer mit dem System angestellt hat. Wie detailliert diese Protokolle sind, hängt gewöhnlich von der Honeypotsoftware ab. Sie sollten allerdings in jedem Fall dafür sorgen,
dass die Protokollierung so ausführlich wie möglich erfolgt. Da es bei der Verwendung
von Frühwarn-Honeypots kaum Fehlalarme geben dürfte, werden auch weniger Protokolle geschrieben, sodass keine Gefahr besteht, die Speicherkapazität zu sprengen oder
eine nicht mehr handhabbare Flut von Protokolldaten zu erzeugen. Jegliche Aktivitäten,
die auf dem Honeypot stattfinden, sind verdächtig, da kein legitimer Benutzer jemals versuchen sollte, damit zu kommunizieren.
Gelegentliche Fehlalarme sind trotzdem möglich. Sie stehen gewöhnlich im Zusammenhang mit automatischen Netzwerkerkennungsdiensten und legitimen internen Scans. In
dieser Phase der Honeypotbereitstellung sollten Sie auch dafür sorgen, dass solche Fehlalarme ausgeschlossen werden, indem Sie die IP-Adressen der Honeypots aus den Scandiensten herausnehmen oder die Erkennungsmechanismen für die Honeypots anpassen.
12.4 Honeypotplattformen
Es gibt verschiedene frei erhältliche Honeypotsysteme mit geringer Interaktion. Im
restlichen Teil dieses Kapitels werden wir uns einige davon ansehen, die als FrühwarnHoneypots für NSM geeignet sind.
12.4 Honeypotplattformen 395
12.4.1 Honeyd
Wenn jemand die Geschichte der Honeypotsoftware aufs Tapet bringt, beginnt die Erörterung gewöhnlich mit Honeyd. Es wurde vor mehr als zehn Jahren von Niels Provos entwickelt und bietet die Möglichkeit, Hosts in Form von Honeypots mit geringer Interaktion
zu simulieren. Viele Jahre lang war Honeyd der De-facto-Standard für diese Art von Honeypot, und viele andere moderne Honeypotlösungen machen Anleihen an seine Funktionsweise. Es wurde zwar schon einige Zeit lang nicht mehr aktualisiert, ist aber immer
noch sehr brauchbar und kann als Frühwarnsystem gute Dienste leisten. Es gibt mehrere
Honeyd-Versionen für Windows, doch das ursprüngliche Honeyd lief ausschließlich auf
Unix-Betriebssystemen. Das ist auch die Version, mit der wir uns hier beschäftigen wollen.
Honeyd ist so vielseitig, weil es mit einer einfachen Konfigurationsdatei in der Lage
ist, viele verschiedene Arten von Systemen und Diensten zu simulieren. Eine einzige
­Honeyd-Instanz kann Dutzende, Hunderte und sogar Tausende von Honeypotsystemen
erzeugen. Darüber hinaus nutzt es auch die Fingerabdruckinformationen des Betriebssystems, um dessen Merkmale bis zu denen der dritten und vierten Schicht vorzuspiegeln. Wenn ein Angreifer versucht, das Betriebssystem des Geräts zu ermitteln, werden
ihm die meisten automatischen Sondierungswerkzeuge das Betriebssystem nennen, das
Sie in der Honeyd-Konfigurationsdatei angegeben haben, selbst wenn das Gerät, auf dem
der Honeypot läuft, über ein ganz anderes Betriebssystem verfügt.
Die beste Möglichkeit, die Funktionsweise von Honeyd vorzuführen, ist ein praktisches
Beispiel. Um Honeyd zu installieren, können Sie es aus dem Quelltext erstellen. Sie können auch mit dem folgenden Befehl einen Paketmanager wie APT verwenden:
apt-get install honeyd
Um Honeyd auszuführen, müssen wir eine Konfigurationsdatei erstellen. Die mitgelieferte Standardkonfigurationsdatei /etc/honeypot/honeyd.conf enthält einige Beispiele dafür,
wie eine solche Datei aufgebaut ist. Wir werden jedoch eine eigene Konfigurationsdatei
schreiben, die einfacher ist, und darauf weiter aufbauen. In diesem Beispiel richten wir
einen Honeypot ein, der ein Gerät mit Windows Server 2003 und nur den typischen Windows-Ports (135, 139 und 445) vorspiegelt.
Dazu müssen wir zunächst einige Standardeinstellungen für Honeyd einrichten:
create default
set default default tcp action block
set default default udp action block
set default default icmp action block
Diese vier Zeilen weisen Honeyd an, sämtliche eingehende Kommunikation zu blockieren,
sofern nichts anderes angegeben ist. Das können Sie sich wie die Standardblockierregel einer
Firewall vorstellen.
396 12 Frühwarn-Honeypots zur Erkennung
Danach erstellen wir mit dem Befehl create einen Honeypot und geben dessen Namen
an, hier ansm_winserver_1:
create ansm_winserver_1
Da wir ein Gerät mit Windows Server 2003 simulieren wollen, verwenden wir den Befehl
set mit der entsprechenden personality-Option:
set ansm_winserver_1 personality "Microsoft Windows Server 2003 Standard
Edition"
Die Merkmale dieser »Persönlichkeit« stammen aus der Fingerabdruckdatenbank, die von
dem weit verbreiteten Port- und Schwachstellenscanner Nmap verwendet wird. Für diese
Fingerabdrücke verwendet die Standardinstallation von Honeyd die Datei /etc/honeypot/
nmap.prints, allerdings ist sie alles andere als auf dem neuesten Stand. Wenn Sie die »Persönlichkeit« eines modernen Betriebssystems brauchen, das in der Standarddatei nmap.
prints nicht aufgeführt ist, dann können Sie aus der aktuellen Nmap-Fingerabdruckdatenbank auf https://svn.nmap.org/nmap/nmap-os-db einen eigenen Eintrag erstellen. Denken
Sie daran, dass die Fingerabdrücke für neuere Versionen von Nmap einige Anpassungen
erfordern können, bevor sie in Honeyd korrekt funktionieren.
Als Nächstes müssen wir festlegen, welche Ports geöffnet sein sollen. In diesem Fall sollen
es die drei Ports sein, die auf ein Windows-System hindeuten, nämlich die TCP-Ports 135,
139 und 445.
add ansm_winserver_1 tcp port 135 open
add ansm_winserver_1 tcp port 139 open
add ansm_winserver_1 tcp port 445 open
Der letzte Schritt besteht darin, unserem Honeypot eine MAC- und eine IP-Adresse zu
geben, sodass er im Netzwerk kommunizieren kann. Das geschieht mit den Befehlen set
und bind:
set ansm_winserver_1 ethernet "d3:ad:b3:3f:11:11"
bind 172.16.16.202 ansm_winserver_1
Damit haben wir alles zusammen, was wir brauchen, um diesen einfachen Honeypot ans
Laufen zu bekommen. Wenn Sie die zuvor angegebenen Konfigurationszeilen in einer
Datei namens ansm.conf gespeichert haben, können Sie Honeyd nun mit dem folgenden
Befehl ausführen:
sudo honeyd –d –f /etc/honeypot/ansm.conf
12.4 Honeypotplattformen 397
Der Schalter -d sorgt dafür, dass Honeyd nicht als Daemon ausgeführt wird, sodass wir
die Ausgabe auf dem Bildschirm sehen können. Mit -f geben wir den Speicherort unserer
Konfigurationsdatei an. Jetzt können wir Honeyd testen, indem wir einen Portscan an
dem Honeypot durchführen. Die Ausgabe dieses Scans sehen Sie in Abb. 12.2.
Abbildung 12.2: Der Portscan zeigt die offenen Ports des Honeypots
Natürlich hat Honeyd diesen Scanvorgang ausführlich protokolliert. Diese Protokolle
werden standardmäßig im Syslog-Format unter /var/log/syslog gespeichert, was es sehr
einfach macht, sie an Drittanbieterwerkzeuge wie ELSA oder Logstash zu übergeben. Die
Protokollausgabe zu dem Scanvorgang sehen Sie in Abb. 12.3.
Abbildung 12.3: Syslog-Protokollausgabe von Honeyd über den Scanvorgang
Bis jetzt ist der Funktionsumfang unseres Honeypots noch stark eingeschränkt. Ein Angreifer kann zwar den Host scannen und offene Ports finden (das Ergebnis eines TCPDrei-Wege-Handshakes), aber sonst nichts auf dem Host anstellen. Wenn Sie wirklich
nur einen Windows-Host simulieren wollen, der keinerlei Dienste außer denen eines
Domänencontrollers oder Dateiservers bereitstellt, reicht der bisherige Funktionsumfang völlig aus. Da niemand jemals mit diesem System kommunizieren sollte, können
Sie es im Sichtfeld eines IDS-Sensors platzieren, der über folgende Regel verfügt:
398 12 Frühwarn-Honeypots zur Erkennung
alert ip !$TRUSTED_MS_HOSTS any ->$MS_HONEYPOT_SERVERS [135,139,445]
(msg:"Attempted Communication with Windows Honeypot on MS Ports";
sid:5000000; rev:1;)
Mithilfe dieser Regel werden alle TCP- und UDP-Kommunikationsversuche mit diesem
Honeypot erkannt (vorausgesetzt, dass er in die Variable $MS_HONEYPOT_SERVERS aufgenommen ist), außer von den zulässigen Systemen in der Variable $TRUSTED_MS_HOSTS. Mit dieser Variable können Sie Kommunikationsversuche von Geräten wie Domänen­controllern
und Aktualisierungs- und Verwaltungsservern wie WSUS und SMS ausschließen.
Um für die Situation gewappnet zu sein, dass ein System im selben Netzwerksegment
versucht, mit dem Honeypot zu kommunizieren, sollten Sie auch einen Erkennungs­
mechanismus vorsehen, der Alarmdaten von dem Honeypotserver selbst generiert. Da
Honeyd Protokolle im Syslog-Format schreibt, können Sie dazu einfach die Syslog-Daten
auf einen anderen Host übertragen, der daraus Alarme erzeugen kann. Sie können auch
ein Host-IDS wie OSSEC einsetzen.
Die jetzige Konfiguration ist ideal geeignet, um einfache Dienste nachzuahmen, aber damit
ist der Funktionsumfang von Honeyd noch nicht erschöpft. Es kann viel anspruchsvollere
Dienste imitieren, indem es Skripte aufruft, die an bestimmte offene Ports gebunden sind.
Um ein Beispiel zu geben, wollen wir unseren Windows 2003-Honeypot so ändern, dass er
einen Webserver simuliert. Dazu fügen wir hinter der Angabe der offenen Ports folgende
Zeile hinzu:
add ansm_winserver_1 tcp port 80 "sh /usr/share/honeyd/scripts/win32/web.sh"
Wenn ein Angreifer jetzt einen Portscan durchführt, stellt er fest, dass Port 80 geöffnet
ist, was auf einen Webserver hindeutet. Greift derselbe Angreifer nun mit einem Browser
auf das System zu, wird ihm sogar eine Webseite angezeigt. Sie ist in dem aufgerufenen
Skript web.sh enthalten und kann so angepasst werden, dass sie der Webseite eines echten
Webservers in Ihrer Umgebung ähnelt. Neben der üblichen Syslog-Protokollierung hält
Honeyd bei dem Versuch des Angreifers, den falschen Webserver zu erreichen, auch den
HTTP-Header der Clientanforderung fest (siehe Abb. 12.4).
Abbildung 12.4: HTTP-Header der Clientanforderung bei dem Verbindungsversuch eines Angreifers auf dem Honeypot-Webserver
12.4 Honeypotplattformen 399
Mit einer Protokollierung in diesem Umfang können Sie ermitteln, welche Tools ein
Angreifer verwendet, um zu versuchen, auf Ihre Infrastruktur zuzugreifen. In dem
Beispiel aus Abb. 12.4 können Sie erkennen, dass der Browser Chrome (User-Agent:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_4) AppleWebKit/537.36 (KHTML, like
Gecko) Chrome/29.0.1547.65 Safari/537.36) mit dem Zeichensatz für amerikanisches
Englisch (Accept-Language: en-US,en;q=0.8) verwendet wurde.
Um die Kommunikation mit diesem Frühwarn-Honeypot zu erkennen, können Sie folgende IDS-Regel verwenden:
alert tcp any any ->$WEB_HONEYPOT_SERVERS 80 (msg:"HTTP GET Request to Web
Honeypot"; content:"GET"; http_method; sid:5000000; rev:1;)
Dadurch wird für jede HTTP-GET-Anforderung an diesen Host ein Alarm ausgelöst,
sofern er in die Variable $WEB_HONEYPOT_SERVERS der verwendeten IDS-Engine aufgenommen ist. Sie können in den HTML-Code der Honeypot-Website auch einen Inhaltsstring einfügen und eine Regel erstellen, die genau diesen String erkennt. Honeyd
bringt mehrere Skripte mit, die eine Vielzahl verschiedener Dienste auf ähnliche Weise
simulieren, darunter SMTP, SNMP, Telnet, POP usw. Diese Skripte bieten unterschiedlich viel Interaktion, weshalb Sie sie gründlich testen sollten, um zu sehen, ob sie sich
für Ihre Umgebung eignen.
In diesem Abschnitt konnten wir natürlich nur an der Oberfläche von Honeyd kratzen.
Neben dem, was wir hier gezeigt haben, kann Honeyd auch Angreifer zu einem anderen System umleiten und sich sogar als Routinggerät ausgeben. Es ist zwar nicht ganz so
stabil wie einige der Honeypotlösungen, die auf die Simulation eines einzigen Dienstes
spezialisiert sind, aber da es Dutzende von Honeypotsystemen erzeugen kann, ist es als
Frühwarnsystem für die NSM-Erkennung äußerst nützlich. Wenn Sie mit Honeyd experimentieren möchten, sollten Sie sich die Dokumentation auf http://honeyd.org/ ansehen.
12.4.2 Der SSH-Honeypot Kippo
Die nächste Plattform, die wir uns ansehen wollen, habe ich in diesem Kapitel schon einmal erwähnt, nämlich Kippo. Dieser Honeypot mit geringer Interaktion simuliert einen
SSH-Server und soll Brute-Force-Angriffe erkennen und die Aktivitäten, die Angreifer in
einer simulierten Shell-Umgebung ausführen, protokollieren.
Da das Protokoll SSH häufig zur Verwaltung sowohl von Geräten mit Unix-artigen Betriebssystemen als auch von Netzwerkgeräten wie Switches und Router eingesetzt wird,
gibt Kippo auch einen guten Frühwarn-Honeypot ab. Nachdem Angreifer im Netzwerk
Fuß gefasst haben, versuchen sie oft, über den SSH-Dienst auf andere Geräte Zugriff zu
erhalten. Dabei gibt es verschiedene Möglichkeiten:
1. Der Angreifer versucht mit einem Brute-Force- oder Wörterbuchangriff, Zugriff auf
den SSH-Server zu erhalten.
400 12 Frühwarn-Honeypots zur Erkennung
2. Der Angreifer versucht, das Passwort eines Benutzers zu erraten, um Zugriff zu erhalten.
3. Der Angreifer meldet sich an dem Dienst mit Informationen an, die er auf andere
Weise in Erfahrung gebracht hat.
Die erste Vorgehensweise lässt sich erkennen, wenn der Angriff über eine Sensorgrenze
hinweg erfolgt, sodass ein Alarm ausgelöst werden kann. Allerdings ist eine solche netzwerkgestützte Erkennung nicht möglich, wenn der Brute-Force-Angriff einem Gerät im
selben Netzwerksegment gilt. Das Gleiche gilt für die zweite Vorgehensweise, wobei die geringere Menge der Authentifizierungsversuche die Erkennung noch weiter erschwert. Ein
Brute-Force- oder Wörterbuchangriff ruft ein hohes Maß an Datenverkehr hervor, das
sich leicht mithilfe einer IDS-Signatur oder eines statistischen Verfahrens aufspüren lässt,
aber wenn ein Angreifer lediglich Passwörter für einen einzigen Benutzer zu erraten versucht, bleibt er dabei möglicherweise unter dem Schwellenwert für einen Alarm. Im dritten Fall ist eine herkömmliche netzwerkgestützte Erkennung praktisch unmöglich, da der
Angreifer legitime Anmeldeinformationen nutzt, weshalb der Vorgang genauso aussieht
wie bei der normalen Authentifizierung eines Benutzers. Eine solche Aktivität können wir
nur mithilfe einer anomaliegestützten Erkennung wahrnehmen, wenn sich der Benutzer
von einem System aus anmeldet, das er normalerweise nicht verwendet.
Als Schutzmaßnahme gegen solche Arten von Angriffen können wir in dem Netzwerksegment, in dem sich die kritischen Elemente befinden, einen SSH-Honeypot wie Kippo bereitstellen. Da niemand einen Grund hat, sich jemals an diesem System anzumelden, sollte
jeder Anmeldeversuch und jeder Netzwerkverkehr außer dem im Zusammenhang mit
Standardbroadcasts und Updates einen Alarm auslösen. In dieser Situation aber können
wir alle drei vorgenannten Aktivitäten erkennen. Unser Honeypot dient dann als Frühwarnsystem, das uns darüber informiert, dass jemand in unserem Netzwerk unzulässige
Dinge tut. Ein zusätzliches Plus besteht darin, dass wir es dadurch mitbekommen, wenn
ein Angreifer Anmeldeinformationen benutzt, die er sich auf andere Weise beschafft hat.
In diesem Fall müssen wir vermuten, dass auch andere Dienste, auf die der betreffende
Benutzer Zugriff hat, angegriffen worden sein können. Fehlalarme können eigentlich nur
auftreten, wenn sich ein Administrator versehentlich an einem dieser Systeme anmeldet.
Kippo können Sie von https://code.google.com/p/kippo/ herunterladen. Da es sich dabei um
ein Python-Skript handelt, ist keine Kompilierung und keine Installation erforderlich. Um
Kippo zu starten, führen Sie einfach die Datei start.sh im Kippo-Verzeichnis aus. Mithilfe
der Datei kippo.cfg können Sie die Konfiguration von Kippo ausführlich an Ihre eigenen Bedürfnisse anpassen, aber für unsere Zwecke lassen wir die Standardkonfiguration unberührt.
Bericht von der Front
Wenn Sie Kippo in einer Produktionsumgebung bereitstellen, sollten Sie sich die
Zeit nehmen, die Einstellungen zu ändern, an denen ein Angreifer das System als
Honeypot erkennen könnte, also unter anderem den Hostnamen und den Inhalt
des gefälschten Dateisystems. Am besten ist es, diese Aspekte möglichst ähnlich
zu gestalten wie auf den Produktionssystemen.
12.4 Honeypotplattformen 401
Wenn Sie Kippo gestartet haben, können Sie eine Verbindung zu seiner gefälschten SSHUmgebung herstellen. In der Standardkonfiguration von Kippo wird der SSH-Dienst an
Port 2222 bereitgestellt. Richten Sie Ihren Honeypot so ein, dass er den in Ihrem Unternehmen üblichen Port verwendet, etwa den Standardport 22.
In der Grundeinstellung protokolliert Kippo jede versuchte Anmeldung an dem Dienst
und hält dabei den Benutzernamen und das Passwort fest, die verwendet wurden. Gespeichert wird das Protokoll standardmäßig als log/kippo.log. Ein Beispiel für diese Datei zeigt
Abb. 12.5.
Abbildung 12.5: Protokollierung von Authentifizierungsversuchen in Kippo
Sie können in Kippo ein Benutzerkonto und ein Passwort festlegen, mit dem sich ein Angreifer erfolgreich in dem simulierten Dateisystem anmelden kann. Angegeben sind diese
Anmeldeinformationen in der Datei data/userdb.txt, wobei standardmäßig der Benutzer
root und das Passwort 123456 verwendet werden. In dem gefälschten Dateisystem, das ein
Angreifer mithilfe dieser Anmeldeinformationen erreicht, kann er nicht nur umsehen,
sondern auch Dateien erstellen und löschen (siehe Abb. 12.6).
Abbildung 12.6: Unterwegs im gefälschten Dateisystem von Kippo
Selbstverständlich werden die Aktionen des Angreifers in dieser Umgebung gründlich
protokolliert. Ein Beispiel für diese Aufzeichnungen sehen Sie in Abb. 12.7.
402 12 Frühwarn-Honeypots zur Erkennung
Abbildung 12.7: Kippo-Protokolle der Aktionen eines Angreifers im Terminal
In diesem Beispiel versucht der Angreifer, die Datei /etc/passwd mithilfe der Befehle scp
und ftp zu dem Host zurückzusenden, vom dem aus er sich angemeldet hat. Da in dieser
Umgebung weder ein SCP- noch ein FTP-Client zur Verfügung steht, meldet das System,
dass die Befehle nicht gefunden werden können. Die Standarddatei kippo.log enthält keine
ausführlichen Aufzeichnungen über diese Befehle, doch die Informationen können Sie
im Ordner log/tty finden. Dort gibt es eine ausführliche binäre Protokolldatei der Aktionen, die in allen von der Software erzeugten Terminalsitzungen abliefen. Die Datei­
namen enthalten jeweils den Zeitstempel der Initialisierung der Sitzung. Allerdings lassen
sich die Dateien nicht so einfach als Klartext einsehen, sondern müssen mit dem KippoHilfsprogramm playlog.py aus dem Ordner util/ geöffnet werden. Dieses Programm gibt
die Aufzeichnung so wieder, als würden Sie dem Angreifer über die Schulter blicken und
seine Terminalsitzung beobachten. Die Befehlseingaben werden in Echtzeit angezeigt, wobei jeder Tastendruck, jeder Rückschritt und jede Pause erfasst werden. Wenn Sie diese
Ausgabe in Präsentationen vorführen, kann das sehr eindrucksvoll wirken. Abb. 12.8 zeigt
die Ausgabe von playlog.py für den Angriff aus Abb. 12.7. Hier können Sie auch eine ausführlichere Ausgabe des Befehls id erkennen als in der Standardprotokolldatei kippo.log.
Die zusätzlichen Interaktionsmöglichkeiten, die Kippo in seinem gefälschten Dateisystem
bietet, sind sehr nützlich, um Informationen über die Motive oder Taktiken der Angreifer
zu gewinnen. Sobald Angreifer Zugriff auf ein System erlangen, laden sie meistens als
Erstes weitere Dateien von einer externen Website herunter, die ihnen dabei helfen sollen,
die nächsten Ziele zu erreichen. Dabei kann es sich um Malware handeln, um Keylogger,
Backdoors oder Rootkits. Wenn das in der Kippo-Umgebung geschieht, können Sie den
Remotehost erkennen, von dem sie versuchen, die Daten herunterzuladen. Das ist eine
sehr wertvolle Information, die Ihnen dabei helfen kann, Ihre Strategie für die Erfassung,
Erkennung und Analyse zu gestalten.
Abbildung 12.8: Wiedergabe eines Angriffs mit dem TTY-Protokoll von Kippo
12.4 Honeypotplattformen 403
Das eigene Protokollformat von Kippo lässt sich von anderen Tools leicht verarbeiten. Es
bietet auch die Möglichkeit der Protokollierung in einer MySQL-Datenbank, was praktisch sein kann, um die Kippo-Daten in ein anderes Werkzeug zu übernehmen. Um die
Erkennung zu verbessern, können Sie zusammen mit dem Honeypotserver noch IDSSignaturen und andere Mechanismen einsetzen. Das ist im Allgemeinen die bevorzugte
Methode, um bei der Interaktion mit einem Honeypot Alarm auszulösen. Beispielsweise
können Sie die folgenden Snort/Suricata-Regeln verwenden, um eine versuchte Authentifizierung an einem Honeypotsystem zu erkennen:
alert tcp $HONEYPOT_SERVERS $SSH_PORTS ->any any (msg:"ET POLICY SSH
Server Banner Detected on Expected Port – Honeypot System"; flow: from_
server,established; content:"SSH-"; offset: 0; depth: 4; byte_test:
1,>,48,0,relative; byte_test:1,<,51,0,relative; byte_test:1,=,46,1,
relative; reference:url,doc.emergingthreats.net/2001973; classtype:
misc-activity; sid:2001973; rev:8;)
alert tcp any any <> $HONEYPOT_SERVERS $SSH_PORTS (msg:"ET POLICY SSH
session in progress on Expected Port – Honeypot System"; threshold: type
both, track by_src, count 2, seconds 300; reference:url,doc.emergingthreats.
net/2001978; classtype:misc-activity; sid:2001978; rev:7;)
Die erste dieser Regeln (SID 2001973) erkennt es, wenn das SSH-Serverbanner an einen Client gesendet wird, die zweite (SID 2001978) erkennt eine laufende SSH-Sitzung.
Diese Regeln werden von Emerging Threats bereitgestellt, wobei ich sie ein wenig abgewandelt habe, um nur Datenverkehr zu Systemen zu berücksichtigen, die von der Variable $HONEYPOT_SERVERS abgedeckt sind. Damit die Regeln in dieser Form funktionieren,
müssen Sie diese Variable natürlich auf Ihrem Sensor eingerichtet haben.
Wenn Sie diese Regeln einsetzen, werden Sie alarmiert, sobald der Sensor erkennt, dass
jemand mit dem SSH-Dienst auf Ihrem Honeypotsystem umgeht. Das Ausmaß dieses
Vorgangs können Sie dann anhand der von Kippo erstellten Protokolldaten bestimmen.
Denken Sie aber daran, dass diese Aktivitäten nur dann erkannt werden, wenn der Angriff
auf Honeypot auf einem Weg erfolgt, den der Sensor überblicken kann. Um Ereignisse
wahrzunehmen, die innerhalb des Netzwerksegments ablaufen, müssen Sie die Alarme
von dem Honeypotsystem selbst hervorrufen lassen. Es gibt verschiedene Vorgehensweisen dazu. Beispielsweise können Sie die Kippo-Protokolle zu Syslog senden und eine Alarmierung bei bestimmten Ereignissen anrichten. Eine andere Möglichkeit besteht darin,
ein Host-IDS wie OSSEC zu verwenden.
Kippo bietet noch weitere Funktionen, die wir hier nicht alle beschreiben können. Außerdem gibt es eine Reihe zusätzlicher Hilfsprogramme und Drittanbietererweiterungen, die
einen Blick wert sind. Mehr darüber erfahren Sie auf https://code.google.com/p/kippo.
404 12 Frühwarn-Honeypots zur Erkennung
12.4.3 Tom’s Honeypot
Als Letztes sehen wir uns Tom’s Honeypot an, der von Tom Liston entwickelt wurde, dem
Autor eines der ersten Produktionshoneypots, LaBrea Tar Pit. Es handelt sich dabei um
einen Python-Honeypot mit geringer Interaktion, der einige wenige häufig angegriffene
Dienste simuliert:
••
••
••
••
••
Remote Desktop Protocol (RDP) (TCP/3389)
Microsoft SQL Server (MSSQL) (TCP/1433, UDP/1434)
Virtual Network Computer (VNC) (TCP/5900)
RAdmin (Remote Administration) (TCP/4899)
Session Initiation Protocol (SIP) (UDP/5060)
Tom’s Honeypot lauscht an den angegebenen Ports auf Kommunikation mit diesen
Diensten. Wenn ein Angreifer versucht, auf einen der Dienste zuzugreifen, wird in die
Datei tomshoneypot.log ein Alarm eingetragen.
Da es sich bei Tom’s Honeypot um ein Python-Skript handelt, müssen Sie zu seiner
Benutzung lediglich eine Voraussetzung installieren (das Python-Modul Twisted) und
es dann in Python ausführen. Zur Installation dieser Voraussetzung in Security Onion
verwenden Sie folgenden Befehl:
sudo apt-gete install python-twisted
Das Skript können Sie von http://labs.inguardians.com/tomshoneypot/ beziehen. Um es
auszuführen, geben Sie folgenden Befehl:
python tomshoneypot.py
Standardmäßig sind alle verfügbaren Dienste eingeschaltet. Wenn Sie nur einen Teil der
Dienste verwenden wollen, müssen Sie das Skript manuell bearbeiten und die entsprechenden Abschnitte auskommentieren:
reactor.listenTCP(1433, fMSSQL, interface=interface)
reactor.listenTCP(3389, fTS, interface=interface)
reactor.listenTCP(5900, fVNC, interface=interface)
reactor.listenTCP(22292, fDump, interface=interface)
reactor.listenTCP(4899, fRAdmind, interface=interface)
reactor.listenUDP(1434, uFakeMSSQL(), interface=interface)
reactor.listenUDP(5060, uFakeSIP(), interface=interface)
Wenn Sie einen bestimmten Dienst nicht ausführen wollen, stellen Sie der entsprechenden Zeile einfach ein amerikanisches Nummernzeichen (#) voran. Dadurch ignoriert
12.4 Honeypotplattformen 405
der Python-Interpreter die Zeile und verzichtet darauf, den Listener für den mit diesem
Dienst verbundenen Port zu starten.
Sehen wir uns ein Anwendungsbeispiel mit dem Dienst RDP an. Dieses Protokoll wird
für die Remotedesktopverwaltung von Windows-Computern verwendet. Wenn Angreifer
in einem Netzwerk Fuß gefasst haben, sehen sie sich gewöhnlich nach weiteren Zielen
um, die sie angreifen können. Der RDP-Dienst verwendet normalerweise Port 3389, und
wenn Angreifer diesen Port geöffnet sehen, versuchen Sie meistens, mithilfe eines RDPClients Verbindung damit aufzunehmen. Falls sie sich die Anmeldeinformationen eines
Benutzers auf andere Weise beschafft haben, können sie mithilfe des RDP-Dienstes die
Kontrolle über den Server übernehmen und damit beginnen, Daten zu rauben. Kennen
sie die Anmeldeinformationen nicht, können sie den RDP-Sever trotzdem nutzen, um zu
versuchen, das Passwort des Benutzers zu erraten, oder zumindest die Windows-Version
in Erfahrung zu bringen, die auf dem Computer läuft.
Bei Tom’s Honeypot läuft an Port 3389 ein gefälschter RDP-Server, der Angreifer dazu verleiten soll, Verbindung mit diesem Dienst aufzunehmen. Wenn ein Angreifer das versucht,
führt der von ihm verwendete Computer einen vollständigen TCP-Handshake mit dem
Honeypot durch und sendet eine RDP-Verbindungsanforderung, auf die der Honeypot
jedoch nicht antwortet. Der Angreifer nimmt dann gewöhnlich an, dass dies aufgrund
irgendwelcher Einschränkungen auf dem Host der Fall ist oder weil der Dienst ausgefallen
ist. In Wirklichkeit liegt es natürlich daran, dass es gar keinen legitimen RDP-Dienst gibt,
an dem man sich anmelden könnte. Anstatt einen RDP-Server bereitzustellen, protokolliert Tom’s Honeypot den versuchten Zugriff auf das gefälschte System. Ein Beispiel für
ein solches Protokoll sehen Sie in Abb. 12.9.
Abbildung 12.9: Ein Beispiel für ein Protokoll von Tom’s Honeypot über einen versuchten RDPZugriff
Das hier gezeigte Protokoll enthält fünf Einträge, wobei vier davon das Feld Login enthalten. Tom’s Honeypot zeigt keinen Bildschirm für eine interaktive Anmeldung an, sondern
nutzt die Tatsache, dass RDP-Clients versuchen, während der ersten Anmeldeanforderung
406 12 Frühwarn-Honeypots zur Erkennung
ein Cookie zu übertragen. Dieses RDP-Cookie hat mit der eigentlichen Authentifizierung
nichts zu tun, sondern enthält einen Benutzernamen, der zur Identifizierung in Terminaldiensten dient. Im ersten Protokolleintrag in Abb. 12.9 wird kein Ergebnis für dieses
Feld angezeigt, da während dieses Verbindungsversuchs noch kein RDP-Cookie vorhanden
war. In den folgenden vier Einträgen können Sie aber Werte dafür sehen. Der zweite und
der dritte Eintrag zeigen zwei verschiedene IP-Adressen, von denen aus versucht wurde,
Verbindung mit dem Honeypot aufzunehmen, wobei in den RDP-Cookies die Benutzernamen a und j verwendet wurden. Die beiden letzten Einträge zeigen zwei Anmeldeversuche
von der IP-Adresse 192.0.2.234 mit dem Benutzernamen NCRACK_USER im RDP-Cookie. Bei
Ncrack handelt es sich um ein Tool zum Knacken von Authentifizierungsmaßnahmen, das
für den Angriff auf RDP-Server verwendet wird. Das zeigt, dass 192.0.2.234 versucht, nicht
autorisierten Zugriff auf das Honeypotsystem zu erhalten.
Die anderen gefälschten Dienste, die Tom’s Honeypot bereitstellt, funktionieren auf ähnliche Weise. Abb. 12.10 zeigt ein Beispiel der Protokolle für die Honeypotdienste MSSQL
und SIP.
Abbildung 12.10: Protokolle von Tom’s Honeypot für die Protokolle MSSQL und SIP
In dieser Abbildung sehen Sie zwei Protokolle. Das erste zeigt die Daten über einen Angreifer, der versucht hat, über einen MS-SQL-Client (TCP-Port 1433) mit Tom’s Honeypot
zu kommunizieren. Hier sind auch Informationen über den Client zu sehen, über den die
Verbindung mit dem falschen MS-SQL-Dienst versucht wurde.
Im zweiten Protokoll versucht jemand, über das Protokoll SIP (UDP-Port 5060) mit
dem Honeypot zu kommunizieren, das gewöhnlich für VoIP-Dienste (Voice over IP)
12.4 Honeypotplattformen 407
verwendet wird. In diesem Fall wurde der Datenverkehr von dem Tool Sipvicious hervorgerufen, das zum Scannen, Auflisten und Untersuchen von SIP-Diensten verwendet
wird.
Tom’s Honeypot wird immer weiterentwickelt, und sehr wahrscheinlich sind neue Funktionen hinzugekommen, wenn Sie dieses Buch lesen. Um mehr über Tom’s Honeypot zu
erfahren, sehen Sie sich auf der Projektwebsite auf http://labs.inguardians.com/tomshoneypot/ um.
12.4.4 Honeydocs
Beim Konzipieren von Sicherheitsmaßnahmen konzentrieren wir uns meistens darauf,
Systeme und Prozesse zu schützen. Das ist zwar alles gut und schön, aber meistens sind es
gar nicht die Systeme und Prozesse, die geschützt werden müssen, sondern die Daten auf
diesen Systemen. An dieser Stelle kommen Honeydocs ins Spiel.
Dabei handelt es sich um eine besondere Form von »Honey-Technologie«. Anstatt ein
legitimes System zu simulieren und den Zugriff darauf zu protokollieren, spiegeln Honeydocs legitime Dokumente vor und halten den Zugriff darauf fest.
Üblicherweise werden Honeydocs neben den echten Dokumenten bereitgestellt. Sie enthalten gefälschte Daten und darüber hinaus versteckten Code, der auf einen Drittserver
verweist. Wenn sich ein Angreifer Zugriff auf die geschützten Daten verschaffen konnte,
wird er über kurz oder lang auch das Honeydoc öffnen, und dabei wird das System Verbindung mit dem Drittserver aufnehmen, der alle Einzelheiten über den Client aufzeichnet, der das Dokument geöffnet hat.
Es gibt verschiedene Möglichkeiten, Honeydocs anzulegen. Am gebräuchlichsten ist die
Methode, in ein Dokument Code aufzunehmen, der beim Öffnen des Dokuments eine
HTTP-Anforderung auslöst. Diese Anforderungen können zwar blockiert oder unterlaufen werden, aber bei unerfahrenen oder hastigen Angreifern werden sie oft erfolgreich
ausgeführt.
Um ein Beispiel zu geben, wollen wir ein Honeydoc in Form eines Microsoft-Word-­
Dokuments erstellen. Am schnellsten geht das, indem wir ein reines Textdokument ohne
jegliche Formatierung anlegen. Das können Sie am Terminal oder mit Programmen wie
dem Windows-Editor oder TextEdit machen. Das Dokument solle eine Reihe falscher
Daten enthalten, die für einen Angreifer interessant sein könnten, z. B. eine Liste angeblicher Benutzer und Passworthashes. Umgeben Sie die Daten anschließend mit den Tags
<html> und </html>, um sie als Webinhalte auszuzeichnen. Im letzten Schritt bauen wir
den Inhalt ein, der die Anforderung an unseren Webserver stellt. Dazu verwenden wir
das HTML-Tag <img>, in dem wir aber nicht den URL eines Bildes angeben, sondern
einen URL zu unserem Webserver mit einer laufenden Nummer:
<img src="http://172.16.16.202/doc123456">
408 12 Frühwarn-Honeypots zur Erkennung
Beim praktischen Einsatz muss dieser URL auf eine öffentliche IP-Adresse oder einen
Domänennamen verweisen. Es ist wichtig, eine laufende Nummer für jedes Honeydoc
anzugeben, sodass wir die Übersicht über die von den einzelnen Dokumenten ausgelösten
Anforderungen behalten. Das fertige Honeydoc sehen Sie in Abb. 12.11.
Abbildung 12.11: Ein Honeydoc im rohen HTML-Format
Der letzte Schritt besteht darin, das Dokument in einem geeigneten Format zu speichern,
gewöhnlich als eine DOC- oder DOCX-Datei, die von Microsoft Word und ähnlichen Anwendungen verarbeitet werden kann. Wenn Sie das Dokument öffnen, versucht Wort, die
in dem <img>-Tag angegebene Bilddatei zu öffnen und löst damit eine GET-Anforderung
an den Webserver aus. In diesem Beispiel führt der Verweis zu einem Honeyd-Server, der
die Ausgabe in Abb. 12.12 hervorruft.
Abbildung 12.12: Honeyd-Protokollausgabe für den Zugriff auf das Honeydoc
12.4 Honeypotplattformen 409
Mithilfe dieser Protokolldaten können Sie nun einen Alarm generieren, mit dem die Analytiker auf den Zugriff auf das Honeydoc aufmerksam gemacht werden. Da die Honeydocs gewöhnlich neben den echten Dateien platziert werden, besteht immer die Gefahr,
dass auch legitime Benutzer versehentlich darauf zugreifen, aber das sollte nicht allzu oft
vorkommen.
Bei Honeydocs sind Sie nicht auf Textdokumente beschränkt. Die gleiche Methode können Sie auch für andere Arten von Dateien anwenden, etwa für HTM-, PDF- oder sogar
XLS-Dateien. Wenn Sie das Erstellen und Verfolgen von Honeydocs ausprobieren möchten, ohne selbst einen Webserver einzurichten, können Sie den Dienst Honeydocs.com
nutzen. Sein Zweck besteht darin, das Erstellen von Honeydocs und die Verfolgung von
Honeydoc-Kampagnen (oder »Stings«, wie sie dort genannt werden) zu automatisieren.
Die kostenlose Registrierung bei Honeydocs.com ermöglicht es Ihnen, einen einzigen Sting
zu erstellen, der mehrere Honeydocs enthalten kann. Gegen eine Gebühr können Sie auch
mehrere Stings anlegen und den Honeydoc-Dienst nutzen, um E-Mail- oder SMS-Alarme
auszulösen, wenn jemand auf eines der von Ihnen erstellten Honeydocs zugreift. Die Webschnittstelle dieses Dienstes sehen Sie in Abb. 12.13.
Abbildung 12.13: Die Webschnittstelle von Honeydocs.com
Ich habe schon verschiedene Arten von Honeydocs gesehen, die mit großem Erfolg für
unterschiedliche Erkennungs- und Reaktionsaufgaben eingesetzt wurden. Ein Wort der
Vorsicht ist jedoch angebracht: Honeydocs funktionieren nicht gerade heimlich, still und
leise, und selbst ein relativ unerfahrener Angreifer wird es bemerken, wenn das Dokument
versucht, mit einem externen Host zu kommunizieren. Das könnte den Drittserver wiederum Sondierungsversuchen des Angreifers aussetzen, weshalb Sie dafür sorgen müssen,
dass er sicher und im Idealfall von Ihrem Firmennetzwerk getrennt ist. Er sollte auch nicht
auf Ihre Organisation zurückzuführen sein. Im Idealfall sollte der Angreifer nicht einmal
bemerken, dass das Honeydoc »nach Hause telefoniert«. Wenn er es doch mitbekommt,
muss das Risiko so gering wie möglich gehalten werden. Wie bei allen anderen in diesem
Kapitel besprochenen Technologien müssen Sie auch bei der Verwendung von Honeydocs
große Sorgfalt walten lassen.
410 12 Frühwarn-Honeypots zur Erkennung
12.5 Zusammenfassung
In diesem Kapitel haben wir die Verwendung von Frühwarn-Honeypots in einer NSMUmgebung behandelt. Dabei haben wir uns mit der Platzierung solcher Honeypots beschäftigt, uns Gedanken über Alarmierung und Protokollierung gemacht und uns einige
Softwarelösungen dafür angesehen. Außerdem haben wir einen Blick auf Honeydocs und
ihren Einsatz für die NSM-Erkennung geworfen. Honeypots werden gewöhnlich nur für
Forschungszwecke verwendet, doch mit den hier beschriebenen Vorgehensweisen können
Sie Frühwarn-Honeypots auch als äußerst nützlichen Erkennungsmechanismus im Kampf
gegen Angreifer nutzen.
Teil 3
Analyse
13
Paketanalyse
In der Analysephase des Network Security Monitorings geht es darum, die Daten zu untersuchen, um zu ermitteln, ob ein Zwischenfall stattgefunden hat. Da sich die meisten von
NSM-Tools erfassten Daten auf Netzwerkaktivitäten beziehen, gehören die Analyse und
Interpretation von Paketdaten zu den wichtigen Fähigkeiten von Analytikern. In diesem
ersten Kapitel des Teils über die Analyse werden wir uns daher aus dem Blickwinkel eines
NSM-Analytikers mit der Paketanalyse beschäftigen. Dabei gehen wir davon aus, dass Sie
gewisse Grundkenntnisse darin haben, wie Computer über das Netzwerk kommunizieren.
Vorkenntnisse in Paketanalyse werden aber nicht vorausgesetzt. Wir schauen uns an, wie
Sie Pakete mithilfe von »Paketmathematik« und Protokollheaderzuordnungen interpretieren und wie Sie sie filtern können. Zur Arbeit mit den Paketen verwenden wir Tcpdump
und Wireshark.
Der Hauptzweck dieses Kapitels besteht darin, Ihnen Grundkenntnisse über Pakete zu
vermitteln und eine Orientierungshilfe zu bieten, um auch die Protokolle zu verstehen,
die wir hier nicht behandeln.
414 13 Paketanalyse
Weitere Informationen
Dieses Buch ist zwar für Analytiker jeglichen Kenntnisstandes geschrieben, aber
wir setzen trotzdem voraus, dass Sie eine Vorstellung davon haben, wie Netzwerkgeräte miteinander kommunizieren. Sie sollten Grundwissen über das OSIbzw. TCP/IP-Modell mitbringen und wissen, wie Kapselung funktioniert. Zur
Auffrischung vor der Lektüre dieses Kapitels empfehle ich Ihnen mein Buch
»Practical Packet Analysis«. Sie müssen es nicht komplett lesen; das erste Kapitel
reicht aus, um den Stoff in diesem Kapitel zu verstehen.
13.1 Gestatten: das Paket!
In einem Netzwerk – sei es ein kleines Heimnetzwerk, ein großes Unternehmensnetzwerk
oder ein weltweites Netzwerk wie das Internet – kommunizieren mannigfaltige Geräte
von verschiedenen Herstellern miteinander. Das funktioniert, solange sie die gleiche Sprache sprechen, also das gleiche Protokoll verwenden.
Ein Netzwerkprotokoll ähnelt in gewisser Hinsicht einer menschlichen Sprache. Jede
Sprache hat Regeln, die etwas bestimmen, wo Substantive platziert werden müssen, wie
Verben konjugiert werden oder sogar wie Unterhaltungen formal begonnen und beendet
werden. Protokolle übertragen dieses Prinzip auf die Kommunikation zwischen Netzwerkgeräten. Ein Gerät, das TCP/IP spricht, kann unabhängig vom Hersteller mit anderen Netzwerkgeräten kommunizieren, die ebenfalls TCP/IP beherrschen. Natürlich gibt
es verschiedene Arten von Protokollen, sowohl einfache als auch komplizierte, und um
eine normale Kommunikation im Netzwerk zu erlauben, ist eine Kombination vieler
Protokolle erforderlich.
Welches Protokoll bei einem Kommunikationsvorgang verwendet wird, lässt sich an den
übertragenen Paketen erkennen, die den Vorgaben des jeweiligen Protokolls entsprechen
müssen. Ein Paket ist dabei eine besonders formatierte Dateneinheit, die von einem Gerät
über das Netzwerk zu einem anderen übertragen wird. Diese Pakete bilden die Grundbausteine der Kommunikation zwischen Computern und sind das A und O des Network
Security Monitorings.
Pakete werden aus Daten von mehreren Protokollen zusammengestellt. Beispielsweise sind
mindestens vier Protokolle erforderlich, damit eine typische HTTP-GET-Anforderung
auch tatsächlich von Ihrem Browser zum Webserver gelangt (HTTP, TCP, IP und Ethernet). Wenn Sie sich solche Pakete schon einmal angesehen haben, dann wahrscheinlich in
einem ähnlichen Format wie dem in Abb. 13.1, mit dem Wireshark Informationen über
Paketinhalte darstellt.
13.1 Gestatten: das Paket! 415
Abbildung 13.1: Ein Paket für eine einfache HTTP-GET-Anforderung in Wireshark
Wireshark ist ein hervorragendes Werkzeug, um Pakete zu analysieren, aber um ihre
Grundlagen zu verstehen, müssen wir ein viel einfacheres Tool einsetzen, nämlich Tcpdump (oder die Windows-Alternative Windump). Während Wireshark eine grafische
­Benutzeroberfläche hat und Ihnen viel Handarbeit bei der Zerlegung der Pakete abnimmt, müssen Sie bei Tcpdump viel mehr selbst tun, um die einzelnen Pakete zu interpretieren. Das mag sich eher nach einem Nachteil anhören, aber es zwingt Analytiker
dazu, genauer über die Pakete nachzudenken, und verschafft ihnen ein grundlegendes
Verständnis, das sich auch bei der Anwendung anderer Paketanalysewerkzeuge und sogar
bei der Rohuntersuchung von Paketdaten als nützlich erweist.
Nachdem Sie nun wissen, wie Wireshark das Paket für eine HTTP-GET-Anforderung zerlegt, wollen wir uns dasselbe Paket in Hexadezimalform ansehen. Eine solche Ausgabe
können Sie mit folgendem Befehl erreichen:
tcpdump -nnxr ansm-13-httpget.pcapng
Tcpdump werden wir uns in diesem Kapitel noch genauer ansehen. Zunächst einmal beschäftigen wir uns aber mit dem Paket in Abb. 13.2.
Wenn Sie noch keine Erfahrung damit haben, Pakete im rohen Hexformat zu untersuchen,
dann wirkt die Ausgabe in Abb. 13.2 völlig unverständlich. Es jedoch gar nicht so schwer,
die Daten zu lesen, wenn wir sie nach Protokollen gliedern. Bevor wir dazu kommen, müssen jedoch erst etwas grundlegende Paketmathematik lernen.
416 13 Paketanalyse
Abbildung 13.2: Ein Paket für eine einfache HTTP-GET-Anforderung in Tcpdump
13.2 Paketmathematik
Geht es Ihnen ebenso wie mir, dass es Ihnen bei einem Titel wie dem dieses Abschnitts
eiskalt den Rücken herunterläuft? Aber keine Angst, Paketmathematik ist ganz einfach,
und wenn Sie die einfache Addition und Multiplikation beherrschen, sollten Sie keine
Schwierigkeiten haben.
13.2.1
Hexdarstellung von Bytes
Wenn Sie Pakete mit Werkzeugen wie Tcpdump anzeigen lassen, sehen Sie die Paketdaten
in einem Hexadezimalformat, das von der binären Darstellung der Bytes abgeleitet ist. Ein
Byte besteht aus acht Bits, die jeweils 1 oder 0 sein können. Ein einzelnes Byte sieht daher
beispielsweise wie folgt aus: 01000101.
Um die Bytes besser lesbar zu machen, werden sie ins Hexformat konvertiert. Dazu wird
ein Byte zunächst in zwei Hälften aufgeteilt, die sogenannten Nibbles (siehe Abb. 13.3).
Die ersten vier Bits bilden dabei das höherwertige Nibble, da sie den höherwertigen Teil
des Bytes darstellen, während die hinteren vier Bits das niederwertige Nibble bilden.
Binärbyte
01000101
Höherwerges Nibble
0100
0101
Niederwerges Nibble
Abbildung 13.3: Aufteilung eines Bytes in Nibbles
Jedes Nibble des Bytes wird anschließend in eine Hexadezimalzahl umgewandelt, sodass
wir ein zweistelliges Byte bekommen. Für Anfänger besteht die schnellste Möglichkeit,
13.2 Paketmathematik 417
den Hexwert eines Bytes zu berechnen, darin, zunächst die Dezimalwerte der einzelnen
Nibbles zu bestimmen. Dies wird in Abb. 13.4 gezeigt.
Binärbyte
Höherwerges Nibble
Niederwerges Nibble
Dezimalwerte
Abbildung 13.4: Berechnen des Dezimalwerts für jedes Nibble
Jede Stelle im Binärwert steht für einen Wert, und dieser Wert wächst von rechts nach
links. Daher wird die Stelle ganz rechts auch als die erste Stelle bezeichnet. Die einzelnen
Stellen stehen für Vielfache von 2: die Stelle ganz rechts für 20, die nächste für 21, die
darauf folgende für 22, dann 23 usw. Für die Berechnungen ist es am einfachsten, die dezimalen Entsprechungen dieser Werte zu verwenden, also 1, 2, 4, 8 usw. Wenn eine Stelle
den Wert 1 hat, dann wird dieser Wert zur Summe addiert. In dem höherwertigen Nibble
in Abb. 13.4 steht der Wert 1 nur an der dritten Stelle, weshalb wir die Summe 4 erhalten.
In dem niederwertigen Nibble dagegen haben wir eine 1 sowohl an der ersten als auch
der dritten Stelle, sodass sich insgesamt 5 ergibt (1 + 4). Das Byte lässt sich daher durch
die Dezimalwerte 4 und 5 darstellen.
Im Hexadezimalformat gibt es die Ziffern 0 bis F, wobei 0 bis 9 den gleichnamigen Dezimalziffern entsprechen und A bis F die dezimalen Werte 10 bis 15 haben. Damit werden
die Dezimalwerte 4 und 5 im Hexadezimalformat ebenfalls als 4 und 5 ausgedrückt, sodass
das Byte 01000101 die hexadezimale Darstellung 45 hat. Den kompletten Rechenvorgang
sehen Sie in Abb. 13.5.
Binärbyte
Höherwerges Nibble
Niederwerges Nibble
Hexbyte
Abbildung 13.5: Umwandlung eines Binärbytes ins Hexformat
418 13 Paketanalyse
Üben wir das noch einmal an einem anderen Byte, nämlich dem aus Abb. 13.6.
Binärbyte
Höherwerges Nibble
Niederwerges Nibble
Hexbyte
Abbildung 13.6: Umwandlung eines weiteren Binärbytes ins Hexformat
Hier steht in dem höherwertigen Nibble eine 1 an erster, zweiter und dritter Stelle, was
einen Gesamtwert von 6 ergibt (2 + 4). Das niederwertige Byte enthält eine 1 an der zweiten, dritten und vierten Stelle, womit wir den Dezimalwert 14 bekommen (2 + 4 + 8). Der
Dezimalwert 6 ist auch im Hexadezimalformat 6, der Dezimalwert 14 dagegen wird zu E.
Damit ergibt sich 6E als Hexadezimaldarstellung von 01101110.
13.2.2 Hexwerte ins Binär- und Dezimalformat umwandeln
Wir haben jetzt beschrieben, wie Sie eine Binärzahl ins Hexformat umwandeln können,
aber später müssen wir auch den umgekehrten Weg gehen, weshalb wir uns im Folgenden
ansehen, wie Sie eine Hexzahl zunächst ins Binär- und dann ins Dezimalformat umwandeln. Dazu verwenden wir die Zahl aus unserem vorherigen Beispiel, also 0x6E.
Ein zweistelliger Hexwert steht für ein Byte, also 8 Bits, und jede einzelne Stelle des Hexwerts steht für ein Nibble des Bytes, wobei E das niederwertige Nibble darstellt. Als Erstes
wandeln wir daher die Hexziffern wieder in ihre binären Gegenstücke um. Dazu rechne
ich die die einzelnen Stellen zunächst in Dezimalwerte um. Wie Sie bereits wissen, entspricht die hexadezimale 6 der dezimalen 6 und das E dem Dezimalwert 14. Anschließend
rechnen wir diese Zahlen ins Binärformat um, indem wir Einsen in die entsprechenden
Bitpositionen (auf der Grundlage von Zweierpotenzen) der einzelnen Nibbles stellen. Damit bekommen wir das höherwertige Nibble 0100 und das niederwertige Nibble 1110.
Diese Nibbles kombinieren wir anschließend zu einem einzigen Byte und betrachten nun
die Stellen im Gesamtbyte als Zweierpotenzen. Dann addieren wir die Werte der Stellen,
deren Bitwert 1 ist, wodurch wir den Dezimalwert 110 erhalten. Den kompletten Vorgang
sehen Sie in Abb. 13.7.
13.2 Paketmathematik 419
Hexbyte
Höherwerges Nibble
Niederwerges Nibble
Dezimalwerte
Abbildung 13.7: Umrechnung eines Hexadezimalwerts ins Binär- und ins Dezimalformat
Weitere Informationen
Zur schnellen Umwandlung vom Hex- ins ASCII- oder Dezimalformat können
Sie die Tabellen in Anhang D zurate ziehen. Es gibt auch Onlinekonverter für
diese Umrechnungen.
13.2.3 Bytes zählen
Als Nächstes sehen wir uns an, wie Sie Bytes zählen, was Sie oft tun müssen, wenn Sie
Bytes in Hexdarstellung untersuchen. Zählen ist zwar ganz einfach (scheuen Sie sich nicht,
Ihre Finger und Zehen zu Hilfe zu nehmen), aber beim Zählen der Bytes in Paketen müssen Sie einige zusätzliche Umstände berücksichtigen.
So sind wir es gewohnt, beim Zählen mit 1 zu beginnen, doch beim Zählen von Bytes
müssen Sie mit 0 anfangen. Das liegt daran, dass wir beim Zählen den relativen Versatz
vom Anfang angeben.
Bericht von der Front
Mit dem »Anfang«, zu dem wir beim Zählen den relativen Versatz angeben, ist
normalerweise das Byte 0 des jeweiligen Protokollheaders gemeint, nicht das Byte
0 des Pakets.
Schauen Sie sich dazu das Paket in Abb. 13.8 an.
Es handelt sich dabei um ein einfaches IP-Paket, wobei wir die Bytes hier durch Leerzeichen getrennt haben, sodass sie leichter zu erkennen sind. Um herauszufinden, was
dieses Paket tut, müssen wir die Werte in bestimmten Feldern dieses Pakets bestimmen.
420 13 Paketanalyse
Das geht am besten dadurch, dass wir die einzelnen Felder den in dem Paket verwendeten
Protokollen zuordnen. In Anhang C finden Sie mehrere Diagramme, die solche Protokollfeldzuordnungen zeigen und die Sie heranziehen können, um die Felder für die einzelnen
Protokolle auseinanderzuhalten. Da wir schon wissen, dass es sich hier um ein IP-Paket
handelt, wollen wir die Werte im IP-Header bestimmen. Zur Vereinfachung zeigt Abb.
13.9 den Aufbau dieses Headers.
Abbildung 13.8: Ein einfaches IP-Paket im Hexformat
Abbildung 13.9: Feldzuordnung für den IP-Header
Um das Paket weiter zu zerlegen, wäre es gut zu wissen, welches eingebettete Protokoll auf
diesem IP-Header aufsitzt. Das Zuordnungsdiagramm für IP-Pakete zeigt uns, dass diese
Information in Byte 9 zu finden ist. Wenn Sie die Bytes in diesem Paket beginnend mit
1 zählten, kämen wir zu einem Feld mit dem Wert 40, aber das ist nicht der Wert für das
Protokoll. Die Angabe »Byte 9« bedeutet »das Byte mit dem Versatz von 9«, also das neunte Byte hinter 0 oder kurz 0x9. Daher müssen wir beginnend mit 0 zählen und kommen
13.2 Paketmathematik 421
damit zu einem Feld, das den Wert 06 hat, was bedeutet, dass es sich bei dem eingebetteten
Protokoll um TCP handelt. Den Zählvorgang sehen Sie in Abb. 13.10.
Byte 0x9: Protokoll
Abbildung 13.10: Das Protokoll im Header an der Position 0x9
Versuchen wir das mit einem weiteren Feld! Laut IP-Zuordnungsdiagramm befindet sich
das TTL-Feld (Time to Live) acht Bytes von 0 entfernt. Wenn wir vom Paketanfang zählen
und dabei mit 0 beginnen, kommen wir zu einem Feld mit dem Wert 40 (was dem Dezimalwert 64 entspricht).
In dem Zuordnungsdiagramm finden Sie auch einige Felder, die weniger als ein Byte lang
sind. So umfasst beispielsweise das Byte 0x0 zwei Felder, nämlich das für die IP-Version
und das für die Länge des IP-Headers. Dabei nimmt dass Feld für die IP-Version das höherwertige Nibble des Bytes ein, das für die Headerlänge dagegen das niederwertige. Damit haben wir bei diesem Paket den Wert 4 für die IP-Version. Die Headerlänge wird als 5
angezeigt, aber dieses Feld ist mit Vorsicht zu genießen, denn es enthält einen berechneten
Wert, der erst noch mit 4 multipliziert werden muss. Damit kommen wir zu einer Länge
von 20 Byte für den IP-Header. Der maximal mögliche Wert für die Headerlänge ist übrigens 60, da der höchste Wert, der im Feld für die Headerlänge auftreten kann, F ist (was
dem Dezimalwert 15 entspricht) und wir mit 15 x 4 auf 60 Byte kommen. Das Feld sehen
Sie in Abb. 13.11.
Byte 0x0: Headerlänge
5 x 4 = 20 Bytes
Byte 0x0: IP-Version
4 = IPv4
Abbildung 13.11: Die Felder für die IP-Version und die Headerlänge an der Position 0x0
Als letztes Beispiel sehen wir uns zwei der Felder an, die mehr als ein Byte umspannen,
nämlich die für die IP-Adressen von Quelle und Ziel, die jeweils vier Bytes lang sind und
im IP-Header an der Position 0x12 bzw. 0x16 stehen. In unserem Beispielpaket wird als
IP-Quelladresse ac 10 10 80 angegeben (dezimal 172.16.16.128) und als Zieladresse 43 cd
02 1e (67.205.2.30), wie Sie in Abb. 13.12 sehen.
422 13 Paketanalyse
Bytes 0x12:4 - IP-Quelladresse
172.16.16.128
Bytes 0x16:4 - IP-Zieladresse
67.205.2.30
Abbildung 13.12: Felder für die Quell- und Zieladresse an 0x12 und 0x16
Beachten Sie die besondere Schreibweise, mit der in dieser Abbildung auf Felder mit mehreren Bytes Länge verwiesen wird. Die Angabe 6x16:4 bedeutet, dass das Feld mit Byte 16
beginnt und vier Bytes lang ist. Diese Schreibweise wird uns später beim Schreiben von
Paketfiltern noch gute Dienste leisten.
Damit haben wir genug Paketmathematik gelernt, um Pakete im Hexadezimalformat
zerlegen zu können. Ich hoffe, die Sache war nicht zu kompliziert.
13.3 Pakete zerlegen
Kehren wir nun zu dem Paket aus Abb. 13.2 zurück, um es in die einzelnen Protokolle zu
zerlegen. Die Zusammenstellung eines Pakets beginnt mit den Daten der Anwendungsschicht. Danach werden nach und nach in absteigender Reihenfolge die Header der Protokolle tieferer Schichten hinzugefügt. Der letzte Protokollheader gehört demnach zur
Sicherungsschicht, und das ist der Header, dem wir als Erstes begegnen. Das am weitesten
verbreitete Protokoll der Sicherungsschicht ist Ethernet, aber wir wollen uns vergewissern,
dass in unserem Beispiel auch tatsächlich dieses Protokoll verwendet wird.
Dazu vergleichen wir den zu erwartenden Aufbau eines Ethernetheaders mit dem, was wir
am Anfang des Pakets sehen. Das Format eines Ethernetheaders finden Sie in Anhang C,
aber auch in Abb. 13.13.
Die ersten sechs Bytes dieses Headers sind für die MAC-Zieladresse reserviert, die folgenden sechs Bytes (also beginnend mit 0x6) für die MAC-Quelladresse. Abb. 13.14 zeigt, dass
diese Bytes in unserem Beispiel tatsächlich den MAC-Adressen von zwei Hosts entsprechen. Das einzige andere Feld im Ethernetheader ist das zwei Byte große Feld für den Typ
an der Position 0x12, das uns sagt, was das Protokoll hinter dem Header erwartet. Hier
hat das Typfeld den Hexwert 08 00, was bedeutet, dass als nächstes eingebettetes Protokoll
IP erwartet wird. Die Länge eines Ethernetheaders beträgt stets 14 Byte, sodass wir genau
wissen, dass es sich bei 00 um das letzte Byte dieses Headers handelt.
13.3 Pakete zerlegen 423
Bericht von der Front
Ich habe den Ethernetheader in dieses Beispiel aufgenommen, obwohl er von Tcpdump standardmäßig nicht ausgegeben wird. Da in diesem Buch immer Ethernet
verwendet wird, zeigen wir diesen Header in den folgenden Beispielen nicht mehr,
sondern beginnen gleich mit den Protokollen der Vermittlungsschicht.
Abbildung 13.13: Feldzuordnung für den Ethernetheader
424 13 Paketanalyse
Ethernetheader
Abbildung 13.14: Abgrenzung des Ethernetheaders
Da uns der Ethernetheader freundlicherweise mitgeteilt hat, dass er als Nächstes einen IPHeader erwartet, können wir auf den nächsten Teil des Pakets unser Wissen über den Aufbau von IP-Paketen anwenden. Da wir das Paket nur in die einzelnen Protokolle zerlegen
wollen, sind wir nicht an allen einzelnen Werten interessiert, sondern nur an denen, die
wir brauchen, um die Länge des IP-Headers zu bestimmen und herauszufinden, welches
Protokoll als Nächstes erwartet wird.
Als Erstes müssen wir bestimmen, welche Version von IP hier verwendet wird. Wie wir
bereits zuvor gelernt haben, steht die IP-Version im höherwertigen Nibble des Bytes 0x0.
Hier haben wir es mit IPv4 zu tun.
Da der IP-Header verschiedene optionale Werte enthalten kann, ist seine Länge variabel.
Als Nächstes müssen wir daher die genaue Länge bestimmen. Wie Sie bereits wissen, befindet sich das Feld mit dieser Angabe im niederwertigen Nibble des Bytes 0x0, das hier
den Wert 5 hat. Da es sich um einen berechneten Wert handelt, müssen wir ihn noch mit 4
multiplizieren, um die tatsächliche Länge des IP-Headers von 20 Byte zu bekommen. Die
letzten beiden Bytes des IP-Headers sind damit 02 1e.
Als letzte Maßnahme im IP-Header finden wir das Protokoll heraus, das als Nächstes folgt.
Im IP-Header finden wir diese Information im Protokollfeld an der Position 0x9. Der
Wert lautet 06, was für das Protokoll TCP steht (siehe Abb. 13.15).
13.3 Pakete zerlegen 425
Ethernetheader
IP-Header
Abbildung 13.15: Abgrenzung des IP-Headers
Nachdem wir das Protokoll TCP erreicht haben, müssen wir überprüfen, ob irgendwelche Daten aus der Anwendungsschicht vorhanden sind. Dazu bestimmen wir die Länge
TCP-Headers (siehe Abb. 13.16), die ebenso wie des IP-Headers von den verwendeten
Optionen abhängt.
Abbildung 13.16: Feldzuordnung für den TCP-Header
426 13 Paketanalyse
Dazu untersuchen wir das TCP-Datenversatzfeld im höherwertigen Nibble des Bytes 0x12.
Hier finden wir den Wert 5, den wir aber ebenfalls mit 4 multiplizieren müssen, um den
tatsächlichen Wert zu erhalten. Die Länge des TCP-Headers beträgt also 20 Byte.
20 Bytes hinter dem Beginn des TCP-Headers sind immer noch Daten zu finden (siehe
Abb. 13.17). Dabei handelt es sich um Daten der Anwendungsschicht. Leider hat TCP
kein Feld, das uns angibt, welches Protokoll dieser Schicht als Nächstes erwartet wird. Wir
können uns aber zumindest das Zielportfeld ansehen (sofern es sich um Datenverkehr
vom Client zum Server handelt; anderenfalls müssten wir uns das Quellportfeld ansehen),
das sich an der Position 0x2:2 des TCP-Headers befindet. Es hat den Wert 00 50, was dem
Dezimalwert 80 entspricht. Da Port 80 gewöhnlich vom Protokoll HTTP verwendet wird,
handelt es sich bei den noch folgenden Daten vermutlich um HTTP-Daten. Das können
Sie überprüfen, indem Sie die Hexdaten mit der Protokollzuordnung für HTTP vergleichen oder indem Sie einfach alle Daten vom Ende des TCP-Headers bis zum Ende des
Pakets in ASCII-Text umwandeln.
Ethernetheader
IP-Header
TCP-Header
Abbildung 13.17: Abgrenzung des TCP-Headers
13.3 Pakete zerlegen 427
Vorsicht
Nur weil die Daten über einen Port übertragen werden, der gewöhnlich von einem bestimmten Dienst verwendet wird – wie Port 80 von HTTP oder Port 22
von SSH –, sollten Sie nicht davon ausgehen, dass diese Dienste auch tatsächlich
für den Datenverkehr verantwortlich sind. Jeder Dienst kann für jeden beliebigen
Port eingerichtet werden, und Angreifer nutzen dies oft aus taktischen Gründen
aus. Beispielsweise führen sie häufig eigene Protokolle zur Steuerung anderer
Computer über Port 80 aus. Dadurch gewinnen sie viele Vorteile, unter anderem die Möglichkeit, den Datenverkehr aus dem Netzwerk herauszubekommen,
da ausgehender Datenverkehr über Port 80 von Firewalls fast immer zugelassen
wird. Außerdem können sie ihren Datenverkehr dann in dem erratischen und
unvorhersehbaren HTTP-Datenverkehr verstecken.
Die Zerlegung des Pakets in die einzelnen Protokolle sehen Sie in Abb. 13.18.
Ethernetheader
IP-Header
TCP-Header
HTTP-Daten
Abbildung 13.18: Zerlegung eines HTTP-Pakets in die einzelnen Protokolle
Als Nächstes sehen wir uns einige Tools an, um Pakete anzuzeigen und weiter mit ihnen
zu arbeiten.
428 13 Paketanalyse
13.4 Tcpdump für die NSM-Analyse
Das Paketerfassungs- und Analysewerkzeug Tcpdump bildet den De-facto-Standard für
die Paketanalyse an der Befehlszeile in Unix-Umgebungen. Es ist äußerst praktisch, da
es Ihnen ohne viel Fisimatenten gleich die Daten zur Verfügung stellt. Damit ist es ideal
dafür geeignet, einzelne Pakete oder ganze Kommunikationssequenzen zu untersuchen.
Es liefert auch eine konsistente Ausgabe, sodass Sie die Paketdaten mithilfe von Skripten
auf einfache Weise bearbeiten können. Tcpdump ist in einer großen Zahl von Betriebssystemdistributionen auf Unix-Basis enthalten, und wenn nicht, kann es leicht mit der
Paketverwaltungssoftware des Betriebssystems installiert werden. In Security Onion ist
Tcpdump im Lieferumfang enthalten.
Der Nachteil von Tcpdump besteht darin, dass ihm aufgrund seiner Einfachheit einige der
ausgefeilteren Analysefunktionen fehlen, die grafische Werkzeuge wie Wireshark bieten.
Da ihm das Prinzip des Verbindungsstatus unbekannt ist, kann es Protokolle der Anwendungsschicht nicht interpretieren.
Dieser Abschnitt soll keine ausführliche Anleitung zu allen Funktionen von Tcpdump
bieten, sondern nur die nötigen Grundlagen vermitteln, die NSM-Analytiker benötigen,
um die ersten Schritte zu unternehmen.
Tcpdump kann Pakete direkt von einer Verbindung abgreifen. Wenn Sie Tcpdump einfach
ohne Befehlszeilenargumente ausführen, erfasst es Pakete an der Netzwerkschnittstelle
mit der niedrigsten Nummer und gibt für jedes eine einzeilige Übersicht im aktuellen
Terminal aus. Um den Vorgang besser zu steuern, können Sie mit dem Argument -i die
Schnittstelle angeben und mit -nn die Host- und Protokollnamensauflösung abschalten.
Bericht von der Front
Wenn Sie Pakete erfassen, sollten Sie so heimlich wie möglich vorgehen. Nicht
etwa, weil Sie den Vorgang verschleiern wollen (es sei denn, Sie arbeiten als Penetrationstester), sondern um keinen zusätzlichen Datenverkehr hervorzurufen,
den Sie wieder herausfiltern oder bei der Untersuchung eines Ereignisses durchforsten müssen. Daher verwende ich immer mindestens einen der -n-Schalter, um
die DNS-Namensauflösung zu verhindern, die sonst zusätzliche Pakete erzeugen
würde.
Wenn Sie die erfassten Pakete für die spätere Analyse speichern möchten, können Sie mit
dem Schalter -w den Namen einer Ausgabedatei angeben. Ein Befehl mit allen genannten
Argumenten sieht beispielsweise wie folgt aus:
sudo tcpdump -nni eth1 -w packets.pcap
Um die Datei später zu lesen, geben Sie die Option -r und dahinter den Dateinamen an,
wie Sie in Abb. 13.19 sehen.
13.4 Tcpdump für die NSM-Analyse 429
Abbildung 13.19: Pakete in Tcpdump aus einer Datei lesen
Die Standardausgabe von Tcpdump macht einige grundlegende Angaben zu jedem einzelnen Paket. Wie die Ausgabe formatiert ist, hängt von dem verwendeten Protokoll ab.
Am häufigsten sind die beiden folgenden Formate:
TCP:
[Zeitstempel] [Protokoll von Schicht 3] [IP-Quelladresse].[Quellport]>[IPZieladresse].[Zielport]: [TCP-Flags], [laufende TCP-Nummer], [TCPBestätigungsnummer], [TCP-Fenstergröße], [Länge der Daten]
UDP:
[Zeitstempel] [Protokoll von Schicht 3] [IP-Quelladresse].[Quellport]>[IPZieladresse].[Zielport]: [Protokoll von Schicht 4], [Länge der Daten]
Sie können Tcpdump dazu bringen, in dieser Übersicht noch mehr Informationen anzuzeigen, indem Sie den Schalter -v angeben. Dabei können Sie bis zu drei v verwenden,
um die Ausführlichkeit der Ausgabe immer weiter zu steigern. In Abb. 13.20 sehen Sie das
gleiche Paket wie zuvor, aber diesmal angezeigt mit -vvv.
Abbildung 13.20: Paketanzeige mit erhöhter Ausführlichkeit
Die Daten sind zwar sehr nützlich, vermitteln uns aber kein Gesamtbild.
Eine Möglichkeit, das vollständige Paket zu sehen, besteht darin, Tcpdump mit dem
Schalter -x zu veranlassen, das Paket im Hexformat anzuzeigen. Das Ergebnis sehen Sie
in Abb. 13.21.
430 13 Paketanalyse
Abbildung 13.21: Anzeige der vollständigen Pakete im Hexformat
Achtung
In Beschreibungen von Tcmpdump wird oft das Argument -s für die »Snapshotlänge« (snaplen) erwähnt. Damit teilen Sie Tcpdump mit, wie viel von einem
Paket erfasst werden soll. In älteren Versionen von Tcpdump werden standardmäßig nur die ersten 68 Bytes (eines IPv4-Pakets) erfasst. Wenn Sie das gesamte Paket haben wollen, müssen Sie daher entweder einen größeren Wert für die
Snapshotlänge angeben oder den Wert 0, wodurch das gesamte Paket unabhängig
von seiner Größe erfasst wird. Seit Tcpdump 4.0 beträgt die Standardsnapshotlänge jedoch 65.535 Bytes, sodass Sie den Befehl -s 0 normalerweise nicht mehr
benötigen.
Eine weitere Möglichkeit besteht darin, Pakete mit dem Argument -A im ASCII-Format
anzuzeigen (siehe Abb. 13.22).
13.4 Tcpdump für die NSM-Analyse 431
Abbildung 13.22: Anzeige der vollständigen Pakete im ASCII-Format
Ich bevorzuge das Argument -X, das die Pakete parallel im Hex- und im ASCII-Format
anzeigt (siehe Abb. 13.23).
Abbildung 13.23: Anzeige der vollständigen Pakete im ASCII- und im Hexformat
Sie werden sehr oft mit umfangreichen PCAP-Dateien zu tun haben, sodass es notwendig
sein wird, Filter einzusetzen, um nur die Daten auszuwählen, die Sie untersuchen möchten, und diejenigen zu verwerfen, die nichts zu der vorliegenden Überprüfung beitragen.
Tcpdump verwendet das Berkeley-Paketfilterformat (BPF). Um einen Filter aufzurufen,
geben Sie ihn am Ende des Befehls tcpdump an. Der Übersichtlichkeit halber sollten Sie
die Namen der Filter in einfache Anführungszeichen stellen. Wenn wir beispielsweise nur
Pakete mit dem TCP-Zielport 8080 sehen wollen, können wir folgenden Befehl geben:
tcpdump -nnr packets.pcap 'tcp dst port 8080'
432 13 Paketanalyse
Wir können auch das Argument -w nutzen, um eine neue Datei zu erstellen, die nur die
gefilterten Pakete enthält:
tcpdump –nnr packets.pcap 'tcp dst port 8080' –w packets_tcp8080.pcap
Manchmal müssen Sie eine große Zahl von einzelnen Filtern verwenden. So etwas geschieht vor allem, wenn Analytiker den Datenverkehr für viele Hosts und Protokolle ausschließen, die mit der vorliegenden Untersuchung nichts zu tun haben. Dabei ist es nicht
einfach, die Filteroptionen mittels Befehlszeilenargumenten zu bearbeiten. Für solche
Fälle bietet Tcpdump das Argument -F, mit dem Sie eine Filterdatei angeben können, die
die BPF-Argumente enthält.
Vorsicht
Eine Tcpdump-Filterdatei darf nur Filteranweisungen enthalten. Kommentare
sind nicht zulässig. Da Kommentare aber sehr nützlich sind, um kompliziertere
Filter zu verstehen, unterhalte ich zwei Filterdateien: eine kommentarlose für den
Einsatz in der Produktion und eine kommentierte zum Nachschlagen.
Der folgende Befehl gibt mit dem Argument -F eine Filterdatei an:
tcpdump –nnr packets.pcap –F known_good_hosts.bpf
Wie Sie eigene Filter erstellen, sehen wir uns weiter hinten in diesem Kapitel an.
Die vorstehende Beschreibung von Tcpdump war natürlich alles andere als erschöpfend,
aber sie hat alle wichtigen Arten der Verwendung abgedeckt, denen Analytiker in ihrer
täglichen Arbeit begegnen. Um mehr über Tcpdump zu lernen, besuchen Sie http://www.
tcpdump.org. Sie können auch die Handbuchseiten lesen, indem Sie auf einem System, auf
dem Tcpdump installiert ist, den Befehl man tcpdump eingeben.
13.5 Tshark für die Paketanalyse
Tshark ist als Alternative für die Befehlszeile mit der grafischen Paketanalyseanwendung
Wireshark gebündelt. Es bietet einen Großteil des Funktionsumfangs von Tcpdump, kann
darüber hinaus aber auch die Protokollzerlegungsfunktionen von Wireshark zugreifen,
womit Sie eine zusätzliche automatische Analyse von Protokollen der Anwendungsschicht
durchführen können. Außerdem können Sie die Anzeigefiltersyntax von Wireshark nutzen, die mehr Möglichkeiten bietet als Berkeley-Paketfilter. In manchen Fällen erweisen
13.5 Tshark für die Paketanalyse 433
sich diese Vorteile jedoch als Nachteile, da die zusätzliche Verarbeitung, die für diese
Funktionen erforderlich ist, dafür sorgt, dass Tshark bei der Verarbeitung der Daten im
Allgemeinen langsamer ist als Tcpdump.
Wenn Sie ein System verwenden, auf dem Wireshark bereits installiert ist, wie das bei Security Onion der Fall ist, dann ist auch Tshark schon installiert und kann mit dem Befehl
tshark aufgerufen werden. Um mit dem Programm Pakete zu erfassen, geben Sie diesen
Befehl wie folgt:
sudo tshark -i eth1
Dadurch wird für jedes erfasst Paket eine einzeilige Übersicht im aktuellen Terminalfenster angezeigt. Wenn Sie die Pakete zur späteren Analyse speichern wollen, können Sie mit
dem Schalter -w eine Ausgabedatei angeben. Der folgende Beispielbefehl nutzt alle diese
Argumente:
sudo tshark –i eth1 –w packets.pcap
Um die Datei zu lesen, geben Sie ihren Namen mit dem Schalter -r an, wie Sie in Abb. 13.24
sehen.
Abbildung 13.24: Anzeige der erfassten Pakete in Tshark
Die Formatierung der Ausgabe hängt von dem verwendeten Protokoll ab. Tshark bietet
auch die Möglichkeit, Daten der Anwendungsschicht anzuzeigen, wie Sie an den Paketen
4 und 6 sehen. Das ist aufgrund der großen Menge von Protokollzerlegungsfunktionen
möglich. Wenn Sie eine ausführlichere Ausgabe benötigen, die auch Informationen aus
diesen Zerlegungsfunktionen einschließt, fügen Sie das Argument -V hinzu. Abb. 13.25
zeigt einen Teil einer solchen Ausgabe für ein einzelnes Paket.
434 13 Paketanalyse
Abbildung 13.25: Ausführlichere Anzeige von Paketen
Die Zeitstempel in der normalen Tshark-Ausgabe in Abb. 13.24 sehen ein bisschen eigenartig aus. Das Standardverhalten dieses Programms besteht darin, die Zeitstempel relativ
zum Beginn der Paketerfassung anzuzeigen. Mit der Option -t können Sie jedoch alternative Darstellungsformen für die Zeitstempel wählen. Wollen Sie beispielsweise wie in
Tcpdump das Datum und die Uhrzeit des Zeitpunkts sehen, an dem das Paket erfasst
wurde, fügen Sie wie in Abb. 13.26 die Option -t ad hinzu.
Abbildung 13.26: Anzeige von Paketen mit absoluter Datums- und Uhrzeitangabe
Mit dieser Option können Sie auch als Delta angeben, also als die Zeit seit dem zuvor
erfassten Paket. Dazu verwenden Sie das Argument -t d.
Wenn Sie die rohen Paketdaten der Erfassungsdatei untersuchen möchten, können Sie
Tshark mit dem Argument -x anweisen, die Pakete im Hex- und im ASCII-Format auszugeben, wie Sie in Abb. 13.27 sehen.
13.5 Tshark für die Paketanalyse 435
Abbildung 13.27: Anzeige von Paketen im Hex- und im ASCII-Format
In Tshark können Sie Erfassungsfilter mit der gleichen BPF-Syntax wie in Tcpdump angeben, aber auch Anzeigefilter verwenden, die die Paketzerlegungsfunktionen von Wireshark
nutzen. Der Hauptunterschied besteht darin, dass die Erfassungsfilter nur während der
Erfassung der Pakete eingesetzt werden können, die Anzeigefilter dagegen auch beim Lesen der Pakete aus einer Datei. Um Erfassungsfilter zu nutzen, geben Sie sie hinter dem
Argument -f an. Der folgende Beispielbefehl schränkt die Datenerfassung von Tshark auf
UDP-Pakete mit dem Zielport 53 ein, also auf DNS-Datenverkehr:
sudo tshark –I eth1 –f 'udp && dst port 53'
Um dieselbe Filterung an bereits erfassten Daten vorzunehmen, können Sie beim Lesen
der Datei mit dem Argument -R einen Anzeigefilter angeben:
tshark –r packets.pcap –R 'udp && dst.port == 53'
Die Anzeigefiltersyntax von Tshark und Wireshark sehen wir uns weiter hinten in diesem
Kapitel noch genauer an.
Ein weitere praktische Funktion von Tshark besteht darin, Statistiken aus den Paketdaten
aufzustellen. Um das zu tun, geben Sie die Option -z und den Namen der gewünschten
436 13 Paketanalyse
Statistik an. Auf der man-Seite von Tshark werden alle verfügbaren Statistikoptionen angezeigt. In dem folgenden Beispielbefehl verwenden wir die Option http,tree, um die in
den erfassten Paketen gefundenen HTTP-Statuscodes und Anforderungsmethoden anzuzeigen.
tshark –r packets.pcap –z http,tree
Die Ausgabe dieses Befehls sehen Sie in Abb. 13.28.
Abbildung 13.28: HTTP-Statistiken mit Tshark
Zu den von mir am häufigsten verwendeten Statistikoptionen gehören die folgenden:
•• io,phs: Zeigt die Hierarchie aller in der Erfassungsdatei gefundenen Protokolle an.
•• http,tree: Zeigt Statistiken über die Arten von HTTP-Anforderungs- und -Antwortpaketen an.
•• http_req,tree: Zeigt Statistiken über alle HTTP-Anforderungen an.
•• smb,srt: Zeigt Statisiken über SMB-Befehle an. Das ist nützlich für die Analyse von
Windows-SMB-Datenverkehr.
Tshark ist äußerst vielseitig und ein nützliches Tool für NSM-Analytiker in Ergänzung
zu Tcpdump. Wenn ich eine Analyse durchführe, beginne ich gewöhnlich mit Tcpdump,
sodass ich die Pakete schnell aufgrund ihrer Attribute der Schichten 3 und 4 filtern kann.
Wenn ich an der Befehlszeile weitere Einzelheiten über eine Kommunikationssequenz aus
der Anwendungsschicht brauche oder einige einfache Statistiken aufstellen möchte, wende ich mich gewöhnlich an Tshark. Um mehr über dieses Programm zu erfahren, besuchen Sie http://www.wireshark.org. Um sich die Handbuchseiten anzusehen, rufen Sie auf
einem System, auf dem Tshark installiert ist, man tshark auf.
13.6 Wireshark für die NSM-Analyse 437
13.6 Wireshark für die NSM-Analyse
Befehlszeilenwerkzeuge für die Paketeanalyse sind zwar ideal für die grundlegende Arbeit
mit Paketen geeignet, aber manche Analyseaufgaben lassen sich am besten mit einer grafischen Anwendung wie Wireshark erledigen. Sie wurde 1998 unter dem Projektnamen
Ethereal von Gerald Combs entwickelt. 2006 wurde das Projekt in Wirehshark umbenannt, und dank der Hilfe von mehr als 500 Mitwirkenden ist es seit seiner Einführung
stark gewachsen. Wireshark bildet die Messlatte für grafische Anwendungen zur Paketanalyse und ist in Security Onion vorinstalliert.
Wenn Sie nicht Security Onion verwenden, richten Sie sich zur Installation von Wireshark
nach der Anleitung für Ihre Plattform auf http://www.wireshark.org. Wireshark läuft auf
Window-, Mac- und Linux-Systemen. In Security Onion können Sie es an der Befehlszeile
starten, indem Sie einfach wireshark eingeben, oder auf dem Desktop, indem Sie unter der
Überschrift Security Onion auf das Symbol Wireshark klicken. Wenn Sie Pakete nicht nur
analysieren, sondern auch erfassen möchten, müssen Sie Wireshark mit erhöhten Rechten
ausführen, wozu Sie den Befehl sudo wireshark verwenden müssen. Das Wireshark-Fenster
zeigt zu Anfang keine brauchbaren Informationen an. Wir müssen erst einige Paketdaten
erfassen, die wir uns ansehen können.
13.6.1
Pakete erfassen
Um Pakete von einer Verbindung abzugreifen, wählen Sie im Hauptmenü Capture >
Interfaces, wodurch alle Schnittstellen auf dem System angezeigt werden (siehe Abb.
13.29). Hier können Sie eine Sensor- oder eine andere Schnittstelle auswählen, an der
Sie Pakete erfassen wollen. Klicken Sie auf die Schaltfläche Start neben der gewünschten
Schnittstelle.
Abbildung 13.29: Paketerfassung in Wireshark
438 13 Paketanalyse
Vorsicht
Seien Sie vorsichtig, wenn Sie mit Wireshark Pakete an einer gut ausgelasteten
Sensorschnittstelle erfassen möchten. Wireshark ist zwar ein großartiges Werkzeug, es kann aber überfordert werden, wenn Sie ihm zu viele Daten auf einmal
zuführen, da es versucht, alle Pakete in den Arbeitsspeicher zu laden. Daher ist es
meistens besser, umfangreiche Datenmengen zunächst mit einem Befehlszeilenwerkzeug zu analysieren und dann die Daten herauszufiltern, die Sie für die weitergehende Untersuchung benötigen, und nur diese an Wireshark zu übergeben.
Um die Paketerfassung abzuschließen, klicken Sie im Menü Capture auf Stop. Nun werden
die zu analysierenden Daten angezeigt. In Abb. 13.30 haben wir einfach eine der vielen
Paketerfassungsdateien geöffnet, die in Security Onion im Verzeichnis /opt/samples/ vorhanden sind.
Abbildung 13.30: Paketanzeige in Wireshark
Wie Sie in dem Bild erkennen können, ist Wireshark in drei Bereiche aufgeteilt. Der obere ist der Paketlistenbereich, in dem alle Pakete in Form in einer einzeiligen Übersicht
aufgeführt sind, wobei die einzelnen Felder als Spalten dargestellt werden. Zu den Standardspalten gehören die Paketnummer, der Zeitstempel (standardmäßig bezogen auf den
Beginn der Erfassung), Quell- und Zieladresse, Protokoll, Paketlänge und eine Spalte mit
protokollspezifischen Informationen.
Der mittlere Bereich zeigt detaillierte Angaben über die Datenfelder des Pakets, das in der
Paketliste ausgewählt ist. Im unteren Bereich finden Sie die einzelnen Bytes, aus denen
sich das Paket zusammensetzt, im Hex- und im ASCII-Format. Diese Anzeige entspricht
derjenigen, die Sie in Tcpdump mit der Option -X erhalten.
13.6 Wireshark für die NSM-Analyse 439
Beachten Sie bei der Arbeit in diesen Fenstern, dass das, was Sie in einem Bereich tun,
Auswirkungen darauf hat, was in den anderen Bereichen angezeigt wird. Wenn Sie auf ein
Paket in der Paketliste klicken, werden in den beiden anderen Bereichen Daten zu diesem
Paket angezeigt. Klicken Sie auf ein Feld im Bereich mit den Paketangaben, werden im
Bytebereich die Bytes aus diesem Feld hervorgehoben. Dadurch behalten Sie besser die
Übersicht, wenn Sie zwischen verschiedenen Paketen wechseln, und können die Eigenschaften der einzelnen Elemente schnell erkennen.
Wireshark bringt viele nützliche Funktionen für die Paketanalyse mit – so viele, dass wir
sie in diesem Kapitel unmöglich alle behandeln können. Wenn Sie eine ausführlichere
Darstellung von Wireshark lesen möchten, empfehle ich Ihnen mein Buch Practical Packet
Analysis oder das Buch Wireshark Network Analysis von Laura Chappell. Beide behandeln
die Paketanalyse und die TCP/IP-Protokolle auf einer breiten Grundlage. Es gibt jedoch
einige sehr praktische Funktionen, die wir uns im Folgenden kurz ansehen werden.
13.6.2 Das Format der Zeitanzeige ändern
Ebenso wie Tshark zeigt Wireshark Pakete standardmäßig mit einem Zeitstempel an, der
die Anzahl der Sekunden seit Beginn der Paketerfassung angibt. Das mag zwar in manchen Situationen sinnvoll sein, aber ich habe lieber eine absolute Zeitangabe. Sie können
diese Einstellung im Hauptmenü unter View > Time Display Format > Date and Time of
Day ändern. Wenn die Erfassungsdatei, mit der Sie arbeiten, nur Pakete eines einzigen
Tages enthält, können Sie den Zeitstempel auch kompakter fassen, indem Sie stattdessen
Time of Day wählen.
Um das Format der Zeitanzeige nicht bei jedem Start von Wireshark ändern zu müssen,
richten Sie wie folgt die Standardeinstellung ein:
1. Wählen Sie im Hauptmenü Edit > Preferences.
2. Wählen Sie die Überschrift Columns und das Feld Time.
3. Ändern Sie Field Type in Absolute Date and Time.
Ein weiteres Zeitanzeigeformat, das in manchen Situationen nützlich sein kann, ist Seconds Since Previous Displayed Packet. Sie können es beispielsweise verwenden, wenn
Sie eine einzelne Kommunikationssequenz analysieren und die Zeitabstände zwischen
einzelnen Aktionen bestimmen wollen. Damit können Sie herausfinden, ob die Aktionen von einem Menschen oder einem Skript hervorgerufen wurden, denn die Aktionen
eines Skripts erfolgen in präzisen Abständen, während das Handeln eines Menschen viel
regelloser ist.
Manchmal möchten Sie auch wissen, in welchem Zeitabstand zwei aufeinander folgende Ereignisse stattgefunden haben. Dazu können Sie in Wireshark ein einzelnes Paket
als Bezugspunkt für die Zeitbestimmung auswählen. Rechtsklicken Sie auf das Paket
und wählen Sie Set Time Reference. Wenn Sie dann das Zeitanzeigeformat auf Seconds
Since Beginnung of Capture ändern, wird als Zeitangabe für die nachfolgenden Pakete
440 13 Paketanalyse
die Anzahl der Sekunden seit der Erfassung des ausgewählten Pakets genannt. Sie können auch mehrere Pakete als Bezugspunkt für die Zeitangaben auswählen.
13.6.3 Übersicht über die Paketerfassung
Wenn ich eine Paketerfassung in Wireshark lade, öffne ich als Erstes das Übersichtsfenster,
indem ich im Hauptmenü Statistics > Summary wähle. In dem daraufhin eingeblendeten
Fenster aus Abb. 13.31 finden Sie eine Menge Informationen und Statistiken über die Paket­
erfassung und die darin enthaltenen Daten.
Abbildung 13.31: Übersichtsfenster in Wireshark
Für Analytiker besonders wichtige Angaben in diesem Fenster sind:
•• Format: Das Format der Datei. Wenn Sie hier sehen, dass Sie es mit einer PCAP-NGDatei zu tun haben, dann wissen Sie, dass Sie den Paketen Kommentare hinzufügen
können.
13.6 Wireshark für die NSM-Analyse 441
•• Time: Dieser Abschnitt zeigt an, wann das erste und wann das letzte Paket erfasst wurde und wie viel Zeit dazwischen verstrichen ist. Das ist wichtig, um zu bestätigen, dass
die Erfassung auch tatsächlich den gesamten Zeitraum abdeckt, den Sie für die vorliegende Untersuchung benötigen.
•• Bytes: Die Menge der Daten in der Erfassungsdatei. Diese Angabe vermittelt Ihnen eine
Vorstellung davon, wie viele Daten Sie sich ansehen.
•• Avg. Packet Size: Die durchschnittliche Größe der Pakete in der Erfassungsdatei. In
manchen Fällen können Sie damit die Zusammensetzung des Datenverkehrs abschätzen. Ein großer Durchschnittswert etwa deutet darauf hin, dass mehr Pakete Daten
enthalten, wohingegen sich aus einem kleineren Durchschnittswert schließen lässt,
dass mehr Steuer- und Befehlspakete auf Protokollebene vorhanden sind. Dies ist allerdings kein besonders zuverlässiger Indikator, da die durchschnittliche Paketgröße
von vielen verschiedenen Faktoren abhängt.
•• Avg. Bytes/sec und Avg. Mbit/sec: Die durchschnittliche Anzahl von Bytes bzw. Megabits pro Sekunde. Damit können Sie die Rate bestimmen, mit der die Kommunikation
abläuft.
13.6.4 Protokollhierarchie
Das Fenster mit der Protokollhierarchie können Sie über Statistics > Protocol Hierarchy
im Hauptmenü auswählen. Es zeigt eine Übersicht über alle in der Erfassungsdatei gefundenen Protokolle zusammen mit statistischen Angaben darüber, wie viel Prozent des
Datenverkehrs die einzelnen Protokolle ausmachen.
Abbildung 13.32: Das Protokollhierarchiefenster von Wireshark
442 13 Paketanalyse
Diese Statistik gehört ebenfalls zu den Dingen, die Sie sich gleich zu Anfang der Analyse einer Paketerfassungsdatei anschauen sollten. Aufgrund der knappen Darstellung
können Sie sehr schnell unnormale oder unerwartete Protokolle aufspüren, die eine
weitere Analyse erfordern, etwa wenn Sie SMB-Datenverkehr sehen, obwohl sich in
dem betreffenden Netzwerksegment keine Windows- oder Samba-Hosts befinden. Es
ist mit dieser Anzeige auch möglich, ungewöhnliche Anteile von Protokollen am Gesamtdatenverkehr zu erkennen. Wenn beispielsweise ein unerwartet hoher Prozentsatz
von DNS- oder ICMP-Datenverkehr zu finden ist, sollten Sie die betreffenden Pakete
genauer untersuchen.
Sie können unmittelbar in diesem Fenster Anzeigefilter erstellen, indem Sie auf ein Protokoll rechtsklicken, Apply As Filter wählen und sich dann für eine Filteroption entscheiden.
Mit Selected werden nur Pakete für das betreffende Protokoll angezeigt, mit Not Selected
alle Pakete, die nicht zu dem Protokoll gehören. Es gibt noch weitere Optionen, mit denen
Sie zusammengesetzte Anzeigefilter erstellen können.
13.6.5 Endpunkte und Konversationen
In Wireshark wird ein Gerät, das über das Netzwerk kommuniziert, als Endpunkt bezeichnet, und die Kommunikation zwischen zwei Endpunkten als Konversation. Das Programm ermöglicht es Ihnen, Kommunikationsstatistiken für einzelne Endpunkte und für
die Konversationen dazwischen anzuzeigen.
Um die Endpunktstatistiken einzusehen, wählen Sie im Hauptmenü Statistics > Endpunkts. Daraufhin wird der Bildschirm aus Abb. 13.33 angezeigt.
Abbildung 13.33: Das Endpunktfenster von Wireshark
Der Zugriff auf die Konversationen erfolgt über Statistics > Conversations. Das Fenster
dafür sehen Sie in Abb. 13.34.
13.6 Wireshark für die NSM-Analyse 443
Abbildung 13.34: Das Konversationsfenster von Wireshark
Beide Fenster sind ähnlich aufgebaut und die einzelnen Endpunkte bzw. Konversationen
jeweils in einer eigenen Zeile, wobei jeweils statistische Angaben zu den in beiden Richtungen übertragenen Paketen und Bytes gemacht werden. Am oberen Rand jedes Fensters
finden Sie außerdem eine Reihe von Registerkarten für die verschiedenen Protokolle in
den unterschiedlichen Schichten. Wireshark zerlegt Endpunkte und Konversationen nach
den Protokollen und Adressen, die in den einzelnen Schichten verwendet werden. Dadurch
kann ein einziger Ethernet-Endpunkt an mehrere IPv4-Endpunkte gebunden sein. Auch
eine Konversation zwischen mehreren IP-Adressen kann in Wirklichkeit auf zwei physische Geräte mit jeweils einer einzigen Ethernet-MAC-Adresse beschränkt sein.
Anhand der Fenster für Endpunkte und Konversationen können Sie bestimmen, wer die
wichtigsten Akteure in einer Erfassungsdatei sind. Sie können herausfinden, welche Hosts
die größte oder geringste Menge an Datenverkehr übermitteln oder erhalten, was Ihnen
dabei hilft, den Umfang Ihrer Untersuchung einzugrenzen. Wie im Protokollhierarchiefenster können Sie unmittelbar Filter erstellen, indem Sie auf einen Endpunkt oder eine
Konversation rechtsklicken.
13.6.6 Streams verfolgen
Wir haben uns bereits angesehen, wie Wireshark Datenverkehr darstellt, der im Rahmen
einer Konversation zwischen zwei Endpunkten auftritt. Meistens sind wir aber mehr an
dem Inhalt der zwischen diesen Geräten übertragenen Daten interessiert als an einer
Liste der Pakete, die bei dieser Kommunikation auftraten. Nachdem Sie einen Filter erstellt haben, der nur den Datenverkehr in einer gegebenen Konversation zeigt, können
Sie die Streamverfolgungsmöglichkeiten von Wireshark nutzen, um sich die Anwendungsschichtdaten in diesen Paketen aus einem anderen Blickwinkel anzusehen. Hier
können Sie das tun, indem Sie auf ein TCP-Paket rechtsklicken und Follow TCP Stream
auswählen.
444 13 Paketanalyse
Abbildung 13.35: Verfolgung eines TCP-Streams
Abb. 13.35 zeigt die TCP-Streamausgabe für eine HTTP-Verbindung. Wie Sie sehen, hat
Wireshark die Daten der Anwendungsschicht, die in den Paketen dieser Konversation enthalten sind, unter Ausschluss von Informationen aus den tieferen Schichten zusammengesetzt. Dadurch können Sie schnell erkennen, was in dieser HTTP-Transaktion vor sich
geht. Diese Informationen können Sie in verschiedenen Formaten ausgeben. Wenn Sie
wollen, können Sie auch nur die Kommunikation in einer Richtung anzeigen lassen.
Wireshark bietet die gleichen Möglichkeiten auch für UDP- und SSL-Streams. Wie wertvoll
die Streamverfolgung ist, hängt von dem verwendeten Protokoll der Anwendungsschicht
ab. Verschlüsselte Streams wie in HTTPS- und SSH-Verbindungen haben naturgemäß keinen großen Wert für die Analyse.
13.6.7 E/A-Diagramm
In dem Übersichtsdialogfeld von Wireshark, das wir uns schon zuvor angesehen haben,
können Sie den durchschnittlichen Datendurchsatz einer Paketerfassung erkennen. Das
ist zwar großartig, um den durchschnittlichen Gesamtdurchsatz zu bestimmen, aber um
den Paketdurchsatz zu einem beliebigen Zeitpunkt zu ermitteln, müssen Sie in Wireshark
ein E/A-Diagramm erstellen, in dem der Datendurchsatz im Zeitverlauf dargestellt wird
(siehe Abb. 13.36).
13.6 Wireshark für die NSM-Analyse 445
Abbildung 13.36: Darstellung des Datendurchsatzes in einem E/A-Diagramm
Abb. 13.36 zeigt einen einfachen Durchsatzgraphen für eine einzige Paketerfassung. Es
gibt eine Linie für den Durchsatz aller Pakete in der Erfassungsdatei (Graph 1) und zwei
weitere Linien für den Durchatz der Pakete, die mit den Anzeigefiltern übereinstimmen.
Einer dieser Filter zeigt den gesamten HTTP-Datenverkehr in der Erfassung (Graph 3), der
andere den Datenverkehr von einem bestimmten Host mit der IP-Adresse 74.125.103.164
(Graph 4).
Vorsicht
In der Druckversion dieses Buches können Sie die Linien in Abb. 13.36 schlecht
unterscheiden, da Wireshark sie durch Farben kennzeichnet. Auf die Graph-3-Linie wurde sogar komplett verzichtet, da ihre Farbe im Schwarzweißdruck überhaupt nicht erkennbar ist.
Die Einheiten und Abstände im E/A-Diagramm lassen sich ändern. Als Einheit bevorzuge
ich Bytes/Tick, und ich passe die Darstellungsgröße der Einheiten an die Dimensionen der
Daten an, die ich untersuche.
E/A-Diagramme sind praktisch, um den von bestimmten Geräten oder Protokollen hervorgerufenen Datenverkehr zu untersuchen oder um Spitzen beim Datenverkehr im Zusammenhang mit bestimmten Arten der Kommunikation rasch zu erkennen.
446 13 Paketanalyse
13.6.8 Objekte exportieren
Wireshark kann die Übertragung einzelner Dateien in bestimmten Protokollen erkennen.
Dadurch können Sie diese Dateien auch aus der Erfassung exportieren, vorausgesetzt, dass
in der Erfassung der komplette Datenstream für die Datei enthalten ist. Zum Zeitpunkt
der Abfassung dieses Buches ermöglicht Wireshark den Export von Objekten aus HTTP-,
SMB- und DICOM-Streams.
Um diese Funktion auszuprobieren, gehen Sie folgendermaßen vor:
1. Starten Sie eine neue Paketerfassung in Wirehsark. Wählen Sie die Netzwerkschnittstelle des Geräts aus, auf dem Sie Wireshark ausführen.
2. Öffnen Sie Ihren Browser und besuchen Sie verschiedene Websites.
3. Halten Sie die Paketerfassung an.
4. Wählen Sie im Hauptmenü von Wireshark File > Export > Objects > HTTP.
5. In einer Liste werden die Dateien aufgeführt, die Wireshark in dem Kommunikationsstream erkannt hat (siehe Abb. 13.37). Klicken Sie auf das Objekt, das Sie exportieren
möchten, und wählen Sie Save as. Anschließend können Sie den Speicherort für die
Datei auswählen und einen Namen für sie angeben.
Abbildung 13.37: Auswählen eines zu exportierenden HTTP-Objekts
Um eine Datei aus einer Paketerfassung extrahieren zu können, müssen alle für die Übertragung der Datei verwendeten Pakete darin enthalten sein.
13.6 Wireshark für die NSM-Analyse 447
Diese Funktion von Wireshark ist ausgesprochen wertvoll. Es gibt zwar noch andere
Möglichkeiten, Dateien aus Paketdatenstreams zu exportieren, z. B. das File Analysis
Framework von Bro, aber es ist sehr bequem, diesen Vorgang direkt in Wireshark vorzunehmen. Ich nutze diese Funktion häufig, wenn ich eine verdächtige Datei in der Übertragung sehe. Seien Sie dabei aber vorsichtig, denn bei der Datei, die Sie exportieren,
könnte es sich um eine Schaddatei handeln, die Ihr System mit irgendeiner Form von
Malware infiziert oder sonstige Schäden anrichtet.
13.6.9 Benutzerdefinierte Spalten hinzufügen
In der Standardinstallation zeigt Wirehshark im Paketlistenbereich sieben Spalten an –
für die Paketnummer, den Zeitstempel, die Quelladresse, die Zieladresse, das Protokoll,
die Länge und Informationen. Das sind sicherlich unverzichtbare Felder, aber für eine
bessere Analyse ist es oft angebracht, weitere Spalten hinzuzufügen. Es gibt zwei Möglichkeiten, das zu tun, und im Folgenden führen wir anhand von drei neuen Spalten beide
vor. Bei diesen Spalten handelt es sich um die für den Quell- und den Zielport sowie für
die ­HTTP-Methode.
Als Erstes kümmern wir uns um den Quell- und Zielport. Die Werte dafür werden zwar
auch im Informationsfeld angezeigt, aber wenn sie in einer eigenen Spalte stehen, können
Sie sie leichter erkennen und die Liste außerdem nach diesen Ports sortieren, was wiederum sehr praktisch ist, um die verschiedenen Streams zu identifizieren.
Um diese Spalten hinzuzufügen, verwenden wir das Dialogfeld Preferences von Wireshark:
1. Wählen Sie im Hauptmenü von Wireshark Edit > Preferences.
2. Wählen Sie auf der linken Seite des Bildschirms die Option Columns.
3. Klicken Sie auf Add und wählen Sie im Dialogfeld Field Type die Option Source Port
(unresolved) aus.
4. Doppelklicken Sie in den neu hinzugefügten Feld auf New Column und ersetzen Sie
diesen Titel durch SPort.
5. Klicken Sie auf Add und wählen Sie die Option Dest Port (unresolved).
6. Doppelklicken Sie in dem neu hinzugefügten Feld auf New Column und ersetzen Sie
diesen Titel durch DPort.
7. Ziehen Sie das Feld SPort hinter das Feld Source.
8. Ziehen Sie das Feld DPort hinter das Feld Destination.
9. Klicken Sie auf OK.
10. Der Bildschirm Columns sieht jetzt so aus wie in Abb. 13.38.
448 13 Paketanalyse
Abbildung 13.38: Der Bildschirm Columns mit den neu hinzugefügten Feldern
Als Nächstes fügen wir die Spalte für die HTTP-Methode hinzu. Das ist sicherlich kein
Feld, dass ständig wertvollen Platz auf dem Bildschirm einnehmen sollte, aber bei der
Analyse von HTTP-Datenverkehr ist es praktisch, da sie daran auf einen Blick zwischen
Paketen mit den HTTP-Befehlen GET und POST unterschieden können. Anstatt die gleiche
Methode anzuwenden wie zuvor, fügen wir es im Wireshark-Hauptfenster wie folgt hinzu:
1. Starten Sie eine neue Paketerfassung in Wireshark. Wählen Sie die Netzwerkschnittstelle des Geräts aus, auf dem Sie Wireshark ausführen.
2. Öffnen Sie Ihren Browser und besuchen Sie verschiedene Websites.
3. Halten Sie die Paketerfassung an.
4. Suchen Sie ein HTTP-Paket mit einer HTTP-Anforderungsmethode, also ein GET- oder
POST-Paket. Das können Sie manuell oder mithilfe des Anzeigefilters http.request tun.
5. Markieren Sie das Paket in der Paketliste und erweitern Sie im Bereich mit den detaillierten Angaben zum Paket den Abschnitt mit den HTTP-Headerinformationen.
Suchen Sie das Feld Request Method.
6. Rechtsklicken Sie auf das Feld Request Method und wählen Sie Apply as column.
Die Spalte Request Method wird jetzt rechts neben der Spalte Info eingefügt. Wenn Sie ihre
Position ändern wollen, können Sie mit der Maus an die gewünschte Stelle ziehen. Sie
können auch den Namen und andere Eigenschaften der Spalte ändern, indem Sie darauf
rechtsklicken und Edit column details wählen. Um eine Spalte wieder zu entfernen, rechtsklicken Sie auf den Spaltenkopf und wählen Remove column.
Spalten, die Sie mit einer der hier vorgeführten Methoden hinzufügen, werden in das zurzeit verwendete Profil aufgenommen, sodass sie nach einem Neustart von Wireshark nach
wie vor angezeigt werden. Spalten wie die für den Quell- und den Zielport verwende ich in
fast allen Situationen. Andere Spalten, etwa für die HTTP-Anforderungsmethode, ergänze
und entferne ich fallweise, je nachdem, welche Art von Datenverkehr ich untersuche. In
13.6 Wireshark für die NSM-Analyse 449
Wireshark können Sie praktisch alle Felder eines zerlegten Pakets zu einer Spalte machen,
indem Sie darauf rechtsklicken und Apply as column wählen. Scheuen Sie sich nicht, diese
Funktion zu nutzen!
13.6.10 Zerlegungsoptionen für Protokolle einrichten
Das wahrscheinlich spannendste Merkmal von Wireshark ist die große Menge von Zerlegungsfunktionen für Protokolle. Dabei handelt es sich um Module, die Wireshark nutzt,
um die einzelnen Protokolle zu zergliedern, um sie feldweise zu interpretieren. Dadurch
wird es möglich, dass die Benutzer Filter auf der Grundlage von Protokollkriterien erstellen. Einige dieser Zerlegungsfunktionen verfügen über praktische Optionen, um die
Vorgehensweise bei der Analyse zu ändern.
Im Hauptmenü können Sie auf diese Zerlegungsoptionen zugreifen, indem Sie Edit >
Preferences wählen und dann den Protokollheader erweitern. Die daraufhin angezeigte
Liste zeigt alle in Wireshark geladenen Zerlegungsfunktionen. Wenn Sie auf eines der
Protokolle klicken, sehen Sie die zugehörigen Optionen auf der rechten Seite des Fensters. Abb. 13.39 zeigt diese Optionen für TCP.
Eine Untersuchung der Zerlegungsoptionen für gebräuchliche Protokolle ist eine gute
Methode, um sich eine Vorstellung davon zu verschaffen, wie Wireshark die dargestellten
Informationen gewinnt. Beispielsweise sehen Sie in Abb. 13.39, dass Wireshark für TCPVerbindungen standardmäßig relative statt absoluter Sequenznummern anzeigt. Wenn
Sie das nicht wissen und dann versuchen, in einer anderen Anwendung nach einer bestimmten Sequenznummer zu suchen, werden Sie erschrocken feststellen, dass es diese
Nummer dort nicht gibt. In einem solchen Fall können Sie die relative Nummerierung
ausschalten, um die echten TCP-Sequenznummern zu erhalten. Wenn Sie viel Zeit mit
der Untersuchung von Paketen zubringen, sollten Sie sich die Mühe machen, sich die
Zerlegungsoptionen für die wichtigsten TCP/IP-Protokolle sowie andere Protokolle anzusehen, mit denen Sie regelmäßig arbeiten.
Abbildung 13.39: Zerlegungsoptionen für TCP
450 13 Paketanalyse
13.6.11 Erfassungs- und Anzeigefilter
In Wireshark können Sie Erfassungsfilter im BPF-Format sowie Anzeigefilter verwenden.
Letztere gehorchen ihrer eigenen Syntax, die eigens für den Umgang mit den von den
Zerlegungsfunktionen erstellten Feldern gedacht ist.
BPF-Erfassungsfilter können Sie in Wireshark nur während der Datenerfassung anwenden. Dazu wählen Sie im Hauptmenü Capture > Options, doppelklicken auf die Schnittstelle, an der die Erfassung ablaufen soll, und geben den Filter im Bereich Capture Filter
des Dialogfelds an (siehe Abb. 13.40). Klicken Sie dann auf OK. Wenn Sie anschließend auf
dem vorherigen Bildschirm auf Start klicken, wird der Erfassungsfilter angewendet. Alle
Pakete, die nicht mit dem Filter übereinstimmen, werden verworfen. Der Filter in diesem
Beispiel lässt nur Pakete aus dem Quellnetzwerk 192.168.0.0/24 durch, die nicht über Port
80 übertragen werden. Achten Sie darauf, die Erfassungsfilter wieder zu entfernen, wenn
Sie sie nicht mehr brauchen, da Sie sonst nicht alle Pakete erhalten, die Sie haben wollen.
Abbildung 13.40: Angeben eines Paketfilters
Anzeigefilter dagegen geben Sie direkt im Filterdialogfeld über dem Paketlistenbereich des
Hauptfensters von Wireshark ein. Wenn Sie anschließend auf Apply klicken, werden nur
die Pakete angezeigt, die mit dem Filter übereinstimmen. Brauchen Sie den Filter nicht
mehr, klicken Sie einfach auf Clear. Die erweiterten Filteroptionen finden Sie, indem Sie
den Ausdrucksfilter von Wireshark nutzen. Klicken Sie dazu auf die Schaltfläche Expression
neben dem Dialogfeld für Anzeigefilter.
13.7 Paketfilter 451
Abbildung 13.41: Zusammenstellen von Anzeigefiltern mit dem Expression Builder
In Abb. 13.41 ist eine Filterausdrucksopton für SMB2-SessionSetup-Anforderungen
ausgewählt.
In diesem Abschnitt haben Sie erfahren, wie Sie in Wireshark Erfassungs- und Anzeigefilter
anwenden können. Im nächsten Abschnitt sehen wir uns an, wie Sie solche Filter für die
Erfassung, Erkennung und Analyse erstellen.
13.7 Paketfilter
Mithilfe von Erfassungs- und Anzeigefiltern geben Sie an, welche Pakete Sie sehen bzw.
nicht sehen wollen. Bei der Analyse von Paketen werden Sie einen Großteil Ihrer Zeit damit verbringen, umfangreiche Datenmengen zu filtern, um sie auf handhabbare kleinere
Abschnitte einzugrenzen, die für die Untersuchung von Wert sind. Daher ist es unverzichtbar, sich mit der Paketfilterung auszukennen und zu wissen, wie Sie sie in verschiedenen
Situationen jeweils anwenden müssen. In diesem Abschnitt sehen wir uns zwei Formen
der Paketfilterung an, nämlich Berkeley-Paketfilter (Erfassungsfilter) und Wireshark- bzw.
Tshark-Anzeigefilter.
13.7.1
Berkeley-Paketfilter (BPF)
BPF ist die am häufigsten verwendete Paketfiltersyntax. Sie wird in einer Reihe von Paketverarbeitungsanwendungen eingesetzt. Tcpdump nutzt sie ausschließlich, und in
Wireshark und Tshark kann sie bei der Erfassung von Paketen im Netzwerk verwendet
werden, um Datenverkehr auszuschließen, den Sie für die Erkennung und Analyse nicht
452 13 Paketanalyse
benötigen (siehe Kapitel 4). BPF-Filter können auch bei der Analyse von Datenverkehr
eingesetzt werden, der bereits von einem Sensor erfasst wurde.
Aufbau von Berkeley-Paketfiltern
Ein Filter, der mit der BPF-Syntax erstellt wurde, wird als Ausdruck bezeichnet. Diese Ausdrücke weisen einen bestimmten Aufbau auf: Sie bestehen aus einem oder mehr Primitiva,
die durch Operatoren verbunden sind. Ein Primitivum ist eine einzelne Filteranweisung,
die wiederum aus einem oder mehreren Qualifizierern gefolgt von einem ID-Wert in
Form eines Namens oder einer Nummer besteht. Ein Beispiel für dieses Format sehen Sie
in Abb. 13.42.
Operator
Wert
Qu
al
ifi
zie
re
Qu
r
al
ifi
zie
re
r
Qu
al
ifi
zie
re
r
Qu
al
ifi
zie
re
r
Primitivum
Primitivum
Wert
Abbildung 13.42: Der Aufbau eines BPF-Ausdrucks
In diesem Beispiel besteht der Ausdruck aus den beiden Primitiva udp port 53 und dst
host 192.0.2.2. Das erste Primitivum hat die Qualifizierer udp und port und den Wert
53. Es steht für jeglichen Datenverkehr zu oder von Port 53 über das Transportschichtprotokoll UDP. Das zweite Primitivum ist aus den Qualifizierern dst und host und dem
Wert 192.0.2.2 aufgebaut und steht für Datenverkehr zu dem Host mit der genannten
IP-­Adresse. Diese beiden Primitiva werden mit dem Verkettungsoperator && zu einem einzigen Ausdruck verkettet, der wahr ist, wenn ein Paket beide Bedingungen erfüllt.
Einen Überblick über die drei verschiedenen Arten von BPF-Qualifizierern einschließlich
Beispielen finden Sie in Tabelle 13.1.
Wie Sie in Abb. 13.42 sehen, werden die Qualifizierer mit einem bestimmten Wert kombiniert. Dabei können Sie Primitiva mit nur einem einzigen Qualifizierer erstellen, z. B. host
192.0.2.2, was für jeglichen Datenverkehr zu oder von der genannten IP-Adresse steht,
oder mehrere Qualifizierer verwenden wie in src host 192.0.2.2, was nur Datenverkehr
bedeutet, der von dieser IP-Adresse ausgeht.
13.7 Paketfilter 453
Tabelle 13.1: BPF-Qualifizierer
Qualifizierertyp
Qualifizierer
Typ
Beschreibung
Gibt an, worauf sich der Wert bezieht.
»Wonach suchen Sie?«
host
Gibt einen Host anhand seiner IP-Adresse an.
net
Gibt ein Netzwerk in der CIDR-Schreibweise an.
port
Gibt einen Port an.
Richtung
Gibt die Übertragungsrichtung (zu oder von dem
Wert) an.
»In welche Richtung verläuft der Datenverkehr?«
src
Gibt an, dass der Wert die Quelle der Kommunikation ist.
dst
Gibt an, dass der Wert das Ziel der Kommunikation
ist.
Protokoll
Gibt das verwendete Protokoll an.
»Welches Protokoll wird verwendet?«
ip
Gibt IP als Protokoll an.
tcp
Gibt TCP als Protokoll an.
udp
Gibt UDP als Protokoll an.
Zur Kombination der Primitiva können die drei in Tabelle 13.2 aufgeführten logischen
Operatoren verwendet werden.
Tabelle 13.2: Logische Operatoren für Berkeley-Paketfilter
Operator
Symbol
Beschreibung
Verkettung (AND)
&&
Ist wahr, wenn beide Bedingungen wahr sind
Disjunktion (OR)
||
Ist wahr, wenn eine oder beide Bedingungen wahr
sind
Negation (NOT)
!
Ist wahr, wenn die Bedingung nicht erfüllt ist
Tabelle 13.3 zeigt einige einfache Beispiele für BPF-Ausdrücke.
454 13 Paketanalyse
Tabelle 13.3: Beispiele für BPF-Ausdrücke
Ausdruck
Bedeutung
host 192.0.2.100
Datenverkehr zu oder von der angegebenen
IPv4-Adresse
dst host 2001:db8:85a3::8a2e:370:7334
Datenverkehr zu der angegebenen IPv6Adresse
ether host 00:1a:a0:52:e2:a0
Datenverkehr zu der angegebenen MACAdresse
port 53
Datenverkehr zu oder von Port 53 (DNS)
tcp port 53
Datenverkehr zu oder von TCP-Port 53
(umfangreiche DNS-Antworten und Zonenübertragungen)
!port 22
Jeglicher Datenverkehr, der nicht zu oder
von Port 22 verläuft (SSH)
icmp
ICMP-Datenverkehr
!ip6
Jeglicher Datenverkehr außer IPv6
Filter für einzelne Protokollfelder
Mit der Syntax, die Sie bis jetzt kennengelernt haben, können Sie einige äußerst praktische Filter gestalten. Wenn Sie aber nur wenige bestimmte Protokollfelder untersuchen
möchten, stoßen Sie damit an die Grenzen. Einer der größten Vorteile der BPF-Syntax
besteht jedoch darin, dass Sie damit nach jedem beliebigen Feld in den Headern der TCP/
IP-Protokolle suchen können.
Nehmen wir zum Beispiel an, Sie sind am TTL-Wert (Time to Live) im IPv4-Header
interessiert, um den Datenverkehr auf der Grundlage der Betriebssystemarchitektur
des Geräts zu filtern, von dem die Pakete ausgehen. Der TTL-Ausgangswert beträgt auf
Windows-Geräten im Allgemeinen 128, auf Linux-Geräten dagegen 64. Das ist zwar kein
hundertprozentig sicheres Kriterium, aber es erlaubt eine rudimentäre passive Betriebssystemerkennung anhand der Pakete. Dazu schreiben wir einen BPF-Ausdruck, der nach
TTL-Werten größer als 64 sucht.
Um diesen Filter zu erstellen, müssen wir wissen, an welchem Versatz das TTL-Feld im
Header beginnt. In einem Protokollzuordnungsdiagramm können wir erkennen, dass der
Anfang des Feldes bei 0x8 liegt (die Zählung beginnt bekanntlich bei 0). Damit können
wir nun einen Filterausdruck schreiben, indem wir Tcpdump sagen, nach welchem Protokollheader es suchen soll, und dabei den Byteversatz, an dem der Wert zu finden ist, in
eckigen Klammern angeben. Mit dem Größer-als-Operator > geben wir außerdem den
gesuchten Wert an. Insgesamt sieht der BPF-Ausdruck also wie folgt aus:
ip[8]>64
13.7 Paketfilter 455
Dieser Ausdruck weist Tcpdump (oder welche BPF-fähige Anwendung Sie auch immer
nutzen) an, den Wert acht Bytes hinter 0 im TCP-Header zu lesen. Wenn der Wert dieses
Feldes größer als 64 ist, liegt eine Übereinstimmung vor.
Im folgenden Beispiel sind wir an einem Feld interessiert, das mehrere Bytes überspannt:
Das Feld für die Fenstergröße im TCP-Header dient dazu, den Datenfluss zwischen zwei
miteinander kommunizierenden Hosts zu steuern. Wenn einer der beiden Hosts mit Daten überflutet wird und sein Puffer voll ist, sendet er an den anderen Host ein Paket mit
dem Fenstergrößenwert 0, um den Kommunikationspartner aufzufordern, die Datenübertragung vorerst einzustellen, damit er aufholen kann. Dadurch wird eine zuverlässige
Datenübertragung sichergestellt. Um TCP-Pakete mit einem Fenstergrößenwert von 0 zu
erkennen, erstellen wir einen Filter, der dieses Feld untersucht.
Dazu gehen wir auf die gleiche Weise vor wie im vorigen Beispiel und bestimmen anhand
eines Zuordnungsdiagramms, wo sich das Feld im TCP-Header befindet. In diesem Fall
beginnt es bei Byte 0x14, allerdings ist es zwei Bytes lang. Das teilen wir Tcpdump dadurch
mit, dass wir in den eckigen Klammern sowohl den Versatz als auch die Länge angeben,
getrennt durch einen Doppelpunkt. Da ergibt folgenden Ausdruck:
tcp[14:2]=0
Hiermit weisen wir Tcpdump an, sich den TCP-Header anzusehen und dabei die Folge
der beiden Bytes zu untersuchen, die beim 14. Byte nach 0 beginnt. Hat dieses Feld den
Wert 0, so liegt eine Übereinstimmung mit dem Filter vor.
Damit wissen wir, wie wir mit Feldern umgehen, die länger als ein Byte sind. Was aber
machen wir mit Feldern, deren Länge weniger als ein Byte beträgt?
Das Protokoll TCP nutzt verschiedene Flags, um den Zweck eines Pakets anzugeben. Beispielsweise wird das Flag SYN für Pakete verwendet, die eine Verbindung einleiten, RST und
FIN dagegen für Pakete, mit denen die Verbindung abrupt oder ordnungsgemäß beendet
wird. Bei diesen Flags handelt es sich um 1-Bit-Felder innerhalb des Bytes 0x13 im TCPHeader.
Zur Veranschaulichung, wie Sie Filter für Felder kleiner als ein Byte erstellen können, wollen wir einen Ausdruck für TCP-Pakete schreiben, bei denen nur das Flag RST aktiviert ist.
Dazu sind mehrere Schritte erforderlich, da wir eine Bitmaske benötigen.
Als Erstes müssen wir den gewünschten Wert im Paketheader finden. Das Flag RST befindet sich im Byte 0x13 des TCP-Header, und zwar an dritter Stelle (von rechts nach links
gezählt). Um Tcpdump mitzuteilen, an welchem Bit in dem Feld wir interessiert sind,
müssen wir eine Binärmaske erstellen.
Da sich das gewünschte Bit an der dritten Stelle befindet, schreiben wir eine 1 in die dritte
Stelle der Bitmaske und 0 in alle anderen. Damit bekommen wir den Binärwert 00000100.
Diesen Wert müssen wir nun in seine hexadezimale Form übersetzen. Das ergibt 0x04.
456 13 Paketanalyse
Jetzt können wir unseren Ausdruck schreiben, indem wir das Protokoll und den Byteversatz für 0x13 und hinter einem kaufmännischen Und-Zeichen (&) den Bitmaskenwert
angeben:
tcp[13] & 0x04
Als Letztes geben wir den Wert an, den das Feld haben soll. Da wir alle Pakete erfassen
möchten, bei denen dieses Feld 1 ist, und eine 1 an der dritten Stelle eines Bytes den Wert
4 darstellt, verwenden wir einfach 4, um nach Übereinstimmungen zu suchen:
tcp[13] & 0x04=4
Dieser Ausdruck steht für alle Pakete, bei denen nur das TCP-Flag RST gesetzt ist.
Es gibt verschiedene Verwendungszwecke für BPF-Ausdrücke, die einzelne Protokollfelder
untersuchen. Beispielsweise können Sie mit dem Ausdruck icmp[0] == 8 || icmp[0] == 0
nach ICMP-Echoanforderungen und -antworten suchen. Anhand der Beispiele in diesem
Abschnitt sollten Sie in der Lage sein, Filterausdrücke für praktisch alle Protokollfelder
zu schreiben, an denen Sie interessiert sind. Als Nächstes sehen wir uns Anzeigefilter an.
13.7.2 Anzeigefilter von Wireshark
Sowohl in Wireshark als auch in Tshark können Sie Anzeigefilter verwenden. Sie unterscheiden sich von den Erfassungsfiltern, da sie die Protokollzerlegungsfunktionen der genannten Anwendungen nutzen, um Informationen über die einzelnen Protokollfelder zu
gewinnen. Dadurch sind sie erheblich vielseitiger. Wireshark unterstützt ca. 1000 Protokolle und fast 141.000 Protokollfelder. In den Filterausdrücken, die Sie schreiben, können
Sie all diese Felder verwenden. Im Gegensatz zu Erfassungsfiltern werden Anzeigefilter erst
nach der Datenerfassung auf die Paketerfassung angewendet.
Wie Anzeigefilter in Wireshark und Tshark verwendet werden, haben wir uns schon zuvor
angesehen. Hier wollen wir uns nun genauer damit beschäftigen, wie diese Ausdrücke
aufgebaut sind, und einige Beispiele dafür geben.
Ein typischer Anzeigefilterausdruck besteht aus einem Feldnamen, einem Vergleichsoperator und einem Wert.
Bei dem Feldnamen kann es sich um ein Protokoll, ein Feld in einem Protokoll oder
ein Feld handeln, das eine Zerlegungsfunktion im Zusammenhang mit einem Protokoll
liefert. Beispiele für solche Feldnamen sind beispiele das Protokoll icmp oder die Protokollfelder icmp.type und icmp.code. Eine vollständige Liste der Feldnamen finden Sie im
Dialogfeld zum Erstellen von Ausdrücken für Anzeigefilter (beschrieben im Abschnitt
13.7 Paketfilter 457
über Wireshark in diesem Kapitel) und in der Hilfedatei von Wireshark. Einfach ausgedrückt: Jedes Feld, das Sie im Wireshark-Bereich mit Detailangaben zu einem Paket
sehen, können Sie in einem Filterausdruck verwenden.
Auf den Feldnamen folgt der Vergleichsoperator (manchmal auch relationaler Operator genannt), der festlegt, wie Wireshark die angegebenen Werte mit den Daten im Feld
vergleichen soll. Die in Wireshark verwendbaren Vergleichsoperatoren sind in Tabelle
13.4 aufgeführt. Je nachdem, was Ihnen lieber ist, können Sie sowohl englische als auch
C-artige Operatoren verwenden.
Tabelle 13.4: Vergleichsoperatoren für Anzeigefilter
Operator
(englisch)
Operator
(C-artig)
eq
Beschreibung
Beispiel
==
Übereinstimmende Werte
sind gleich dem angegebenen Wert
ip.addr == 192.168.1.155
ne
!=
Übereinstimmende Werte
sind ungleich dem angegebenen Wert
ip.addr != 192.168.1.155
gt
>
Übereinstimmende Werte
sind größer als der angegebene Wert
tcp.port gt 1023
lt
<
Übereinstimmende Werte
sind kleiner als der angegebene Wert
tcp.port < 1024
ge
>=
Übereinstimmende Werte
sind größer oder gleich
dem angegebenen Wert
udp.length >= 75
le
<=
Übereinstimmende Werte
sind kleiner oder gleich
dem angegebenen Wert
udp.length le 75
Übereinstimmende Werte
enthalten den angegebenen Wert in dem Feld
smtp.req.parameter contains
"FROM"
contains
Das letzte Element in einem Ausdruck ist der Wert, nach dem Sie in Relation zu dem Vergleichsoperator suchen. Tabelle 13.5 zeigt die verschiedenen Arten von Werten.
458 13 Paketanalyse
Tabelle 13.5: Werttypen
Werttyp
Beschreibung
Beispiel
Integer (mit oder
ohne Vorzeichen)
Angegeben im Dezimal-,
Oktal- oder Hexadezimalformat
tcp.port == 443
Boolescher Wert
Angegeben als 1 (wahr)
oder 0 (falsch)
tcp.flags.syn == 1
Angegeben als ASCII-Text
http.request.uri == "http://www.
appliednsm.com"
String
ip.proto == 0x06
ip.frags.mf == 0
smtp.req.parameter contains
"FROM"
Adresse
Angegeben im entsprechenden Adressformat:
IPv4, IPv6, MAC usw.
ip.src == 192.168.1.155
ip.dst == 192.168.1.0/24
ether.dst == ff:ff:ff:ff:ff:ff
Damit sind wir nun in der Lage, eigene Filter zu schreiben. Als erstes einfaches Beisiel
wollen wir einen Filterausdruck aufstellen, um nur Pakete anzuzeigen, die das Protokoll
IP verwenden. Dazu müssen wir lediglich den Protokollnamen angeben:
ip
Mit dem Schlüsselwort src können wir nach Übereinstimmungen mit einer bestimmten
IP-Quelladresse suchen:
ip.src == 192.168.1.155
Alternativ können wir auch nach Paketen mit einer bestimmten IP-Zieladresse forschen:
ip.dst == 192.168.1.155
Wireshark enthält auch einige eigene Felder, die Werte aus verschiedenen anderen Feldern
enthalten. Um beispielsweise Pakete zu finden, bei denen eine bestimmte IP-Adresse als
Quelle oder als Ziel verwendet wird, verwenden wir folgenden Filter, der sowohl das Feld
ip.src als auch ip.dst untersucht:
ip.addr == 192.168.1.155
Mithilfe logischer Operatoren können mehrere Ausdrücke verknüpft werden. Eine Aufstellung dieser Operatoren sehen Sie in Tabelle 13.6.
13.7 Paketfilter 459
Tabelle 13.6: Logische Operatoren für Anzeigefilter
Operator
(englisch)
Operator
(C-artig)
Beschreibung
and
&&
Ist wahr, wenn beide Bedingungen wahr sind
or
||
Ist wahr, wenn eine oder beide Bedingungen wahr sind
xor
^^
Ist wahr, wenn genau eine der beiden Bedingungen wahr ist
not
!
Ist wahr, wenn die Bedingung nicht erfüllt ist
Damit können wir zwei Ausdrücke zu einem kombinierten Ausdruck verbinden. Der folgende Filter sucht nach Paketen, die von 192.168.1.155 ausgehen und nicht für Port 80
bestimmt sind:
ip.src == 192.168.1.155 && !tcp.dstport == 80
Auch hier gilt wieder, dass Sie alles, was Sie in Wireshark im Bereich mit den Detailangaben zu einem Paket sehen, für Filterausdrücke verwenden können. Tabelle 13.7 zeigt
einige weitere Beispiele für Anzeigefilterausdrücke.
Tabelle 13.7: Beispiele für Anzeigefilterausdrücke
Filterausdruck
Beschreibung
eth.addr !=<MAC-Adresse>
Findet Pakete, die nicht zu oder von der angegebenen
MAC-Adresse übertragen werden.
ipv6
Findet IPv6-Pakete.
ip.geoip.country == <Land>
Findet Pakete zu oder von dem angegebenen Land.
ip.ttl <= <Wert>
Findet Pakete mit einem TTL-Wert kleiner oder gleich
dem angegebenen Wert. Das kann für eine grobe
Identifizierung des Betriebssystems verwendet werden.
ip.checksum_bad == 1
Findet Pakete mit einer ungültigen IP-Prüfsumme.
Wenn Sie die Angabe ip in diesem Ausdruck durch
udp oder tcp ersetzen, können Sie ihn auch für Prüfsummen dieser Protokolle verwenden. Dieser Filter
ist praktisch, um unvorsichtig gefälschte Pakete zu
finden.
tcp.stream == <Wert>
Findet Pakete, die zu dem angegeben TCP-Stream
gehören. Das ist nützlich, um die Suche auf bestimmte Transaktionen einzugrenzen.
460 13 Paketanalyse
Filterausdruck
Beschreibung
tcp.flags.syn == 1
Findet Pakete, bei denen das Flag SYN gesetzt ist. Sie
können syn auch durch die Abkürzungen für andere
TCP-Flags ersetzen, um danach zu suchen.
tcp.analysis.zero_window
Findet Pakete mit der Angabe 0 für die TCP-Fenstergröße. Damit lassen sich Hosts aufspüren, deren
Ressourcen erschöpft sind.
http.request == 1
Findet HTTP-Anforderungspakete.
http.request.uri == "<Wert>"
Findet HTTP-Anforderungspakete mit dem angegebenen URI.
http.response.code == <Wert>
Findet HTTP-Antwortpakete mit dem angegebenen
Code.
http.user_agent == "Wert"
Findet HTTP-Pakete mit dem angegebenen String für
den Benutzeragenten.
http.host == "Wert"
Findet HTTP-Pakete mit dem angegebenen Hostwert.
smtp.req.command == "<Wert>"
Findet SMTP-Anforderungspakete mit dem angegebenen Befehl.
smtp.rsp.code == <Wert>
Findet SMTP-Antwortpakete mit dem angegebenen
Code.
smtp.message == "Wert"
Findet Pakete mit der angegebenen SMTP-Nachricht.
bootp.dhcp
Findet DHCP-Pakete.
!arp
Findet alle Pakete, die keine ARP-Pakete sind.
ssh.encrypted_packet
Findet verschlüsselte SSH-Pakete.
ssh.protocol == "<Wert>"
Findet SSH-Pakete mit dem angegebenen Protokollwert.
dns.qry.type == <Wert>
Findet DNS-Abfragepakete des angegebenen Typs (A,
MX, NS, SOA usw.).
dns.resp.type == <Wert>
Findet DNS-Antwortpakete des angegebenen Typs (A,
MX, NS, SOA usw.).
dns.qry.name == "<Wert>"
Findet DNS-Abfragepakete mit dem angegebenen
Namen.
dns.resp.name == "<Wert>"
Findet DNS-Antwortpakete mit dem angegebenen
Namen.
Nehmen Sie sich die Zeit, mit den Anzeigefilterausdrücken zu experimentieren und einige
für Ihre Zwecke nützliche zu erstellen. Das Dialogfeld zum Erstellen von Ausdrücken in
Wireshark kann Ihnen dabei Hilfestellung leisten.
13.8 Zusammenfassung 461
13.8 Zusammenfassung
In diesem Kapitel haben wir die Grundlagen der Paketanalyse besprochen. Als Erstes haben Sie eine Einführung in Paketmathematik erhalten, um Pakete im Hexformat lesen
zu können. Danach sind wir zu einer Beschreibung von Werkzeugen für die Paketanalyse übergegangen, nämlich der Befehlszeilentools Tcpdump und Tshark und der grafischen Anwendung Wireshark. Als Letztes haben wir uns mit dem Aufbau und der Syntax
von Erfassungs- und Anzeigefiltern beschäftigt. Die Paketanalyse ist eine der wichtigsten
Fähigkeiten für NSM-Analytiker, weshalb die Informationen in diesem Kapitel von unschätzbarem Wert sind. Wenn Sie diese Prinzipien beherrschen, können Sie sich mit den
weiteren Quellen zur Paketanalyse beschäftigen, die am Anfang dieses Kapitels erwähnt
wurden, um ein besseres Verständnis der Funktionsweise von Paketen und der TCP/IPProtokolle zu erwerben.
14
Aufklärung über Freund und Feind
Die meisten Sicherheitsteams, die ein Network Security Monitoring durchführen, sind
allgemein gesagt an zwei Arten von Informationen interessiert, nämlich an Informationen
über eigene Elemente und über Bedrohungen. In diesem Kapitel sehen wir uns den herkömmlichen Zyklus der Informationsbeschaffung oder Aufklärung und die Methoden an,
die dafür eingesetzt werden können. Denken Sie bei der Lektüre aber immer daran, dass
bei der Aufklärung viele Faktoren eine Rolle spielen, von denen wir hier nur einen kleinen
Teil behandeln können.
14.1 Der Aufklärungszyklus für NSM
Aufklärung erfordert die koordinierten Anstrengungen mehrerer Beteiligter innerhalb der
Organisation. Da es so viele bewegliche Teile gibt, ist es sinnvoll, dem Aufklärungsvorgang
eine geordnete, wiederholbare Struktur zu geben. Die US-Regierung und militärische Aufklärungsorganisationen verwenden dabei seit Jahren eine Struktur, die als Aufklärungszyklus (Intelligence Cycle) bezeichnet wird.
Dieser Zyklus kann in mehrere Schritte zerlegt werden, wobei jedoch je nach Quelle
unterschiedlich viele Schritte angegeben werden. In diesem Buch verwenden wir ein
Modell mit sechs Schritten: Definition der Anforderungen, Planung, Erfassung, Verar-
464 14 Aufklärung über Freund und Feind
beitung, Analyse und Weitergabe. Diese Schritte bilden einen Zyklus, der sich ständig
selbst speist, sodass die Ergebnisse in die Gestaltung der weiteren Aufklärung einfließen
(siehe Abb. 14.1).
Definion der
Anforderungen
Weitergabe
Planung
Analyse
Erfassung
Verarbeitung
Abbildung 14.1: Der herkömmliche Aufklärungszyklus
Im Folgenden wollen wir die einzelnen Schritte durchgehen, um zu zeigen, wie sich dieser
Zyklus auf die Aufklärung über Freund und Feind im Rahmen des NSM anwenden lässt.
14.1.1
Definition der Anforderungen
Die gesamte Aufklärung basiert auf definierten Anforderungen. Ein Film lässt sich nicht
ohne Drehbuch herstellen, und ebenso können Sie keine Aufklärung durchführen, ohne
die Anforderungen dafür klar definiert zu haben.
Im Zusammenhang mit Informationssicherheit und NSM geht es bei diesen Anforderungen allgemein gesagt darum, welche Informationen Sie über die eigenen, zu schützenden
Elemente und über Hosts benötigen, die eine mögliche Bedrohung dieser eigenen Elemente darstellen.
Damit sind diese Anforderungen im Grunde genommen der Bedarf an Kontext und Informationen, mit deren Hilfe NSM-Analytiker Entscheidungen im Rahmen ihrer Untersuchungen treffen können. In dieser Phase geht es darum, die richtigen Fragen zu stellen,
wobei es, je nachdem, ob es um kontinuierliche oder situationsbedingte Anforderungen
geht, unterschiedliche Fragen gibt. Die Aufklärung über eigene Elemente ist ein kontinuierlicher Vorgang, weshalb dazu weit gefasste Fragen gestellt werden müssen, die auch bei
wiederholter Anwendung nicht an Gültigkeit verlieren.
14.1 Der Aufklärungszyklus für NSM 465
Die folgenden Beispielfragen dienen dazu, eine Vergleichsgrundlage für die Kommunikation im eigenen Netzwerk aufzustellen:
•• Welche normalen Kommunikationsmuster bestehen zwischen den eigenen Hosts?
•• Welche normalen Kommunikationsmuster bestehen zwischen sensiblen eigenen Hosts
und unbekannten externen Hosts?
•• Welche Dienste werden den eigenen Hosts normalerweise bereitgestellt?
•• In welchem Verhältnis stehen die ein- und die ausgehende Kommunikation bei eigenen Hosts normalerweise?
Die Aufklärung über Bedrohungen dagegen ist situationsbedingt. Dabei werden oft spezifische Fragen gestellt, die eine einzige Information für die laufende Untersuchung liefern:
•• Hat der gegebene gegnerische Host jemals zuvor mit eigenen Hosts kommuniziert,
und wenn ja, in welchem Umfang?
•• Ist der gegebene gegnerische Host bei einem Provider registriert, von dem schon zuvor
feindliche Aktivitäten ausgegangen sind?
•• Gibt es Ähnlichkeiten zwischen dem Datenverkehr, den der gegebene gegnerische
Host hervorgerufen hat, und Tätigkeiten, die bekanntermaßen mit aktuellen Gegnern
zusammenhängen?
•• Steht der Zeitpunkt des gegebenen Ereignisses in Zusammenhang mit den Zielen einer
bestimmten Organisation?
Wenn Sie die richtigen Fragen gestellt haben, sind Sie in der Lage, das Puzzle zusammenzusetzen. In den späteren Abschnitten über die Aufklärung über Freund und Feind werden wir uns noch genauer mit den jeweiligen Anforderungen auseinandersetzen.
14.1.2 Planung
Nachdem Sie die Anforderungen aufgestellt haben, müssen Sie die einzelnen folgenden
Schritte des Aufklärungszyklus planen und Ressourcen dafür zuweisen, wobei beim NSM
für die einzelnen Schritte unterschiedliche Arten von Ressourcen erforderlich sind. Das
kann beispielsweise bedeuten, für die Erfassungsphase Analytiker der Ebene 3 (zur Klassifizierung von Analytikern siehe Kapitel 1) und Systemadministratoren für die Arbeit mit
den Sensoren und Erfassungswerkzeugen abzustellen, für die Verarbeitungs- und Analysephase dagegen Analytiker der Ebenen 1 und 2.
Welche Arten von Ressourcen den einzelnen Aufgaben zugewiesen werden müssen –
menschliche sowie technische –, hängt natürlich sehr stark von Ihrer Umgebung und der
Zusammensetzung Ihrer technischen Teams ab. In großen Organisation kann es sein, dass
Sie ein eigenes Team nur für die Aufklärung haben, während in kleinen Organisationen
möglicherweise Sie allein für sämtliche Aufgaben rund um die Aufklärung zuständig sind.
466 14 Aufklärung über Freund und Feind
14.1.3 Erfassung
In der Erfassungsphase des Aufklärungszyklus geht es darum, die Daten zu sammeln, die
gemäß den Anforderungen benötigt werden. Diese Daten werden in den weiteren Phasen
verarbeitet, analysiert und weitergegeben.
Es kann sein, dass Sie Ihren allgemeinen Erfassungsplan aufgrund des Bedarfs an Erfassung für die Aufklärung ändern müssen. Die Erfassung für die kontinuierliche interne
Aufklärung kann auch Statistiken wie diejenigen aus Kapitel 11 und passive Echtzeitdaten
umfassen, z. B. die Daten, die mit dem weiter hinten beschriebenen Tool PRADS ermittelt
werden.
Bei der situationsbedingten Aufklärung über Bedrohungen werden die Daten gewöhnlich aus vorhandenen NSM-Quellen wie FPC- oder Sitzungsdaten gewonnen. Dabei liegt
der Schwerpunkt auf den Interaktionen eines möglicherweise gegnerischen Elements mit
den vertrauenswürdigen Netzwerkelementen. Zusätzlich werden anhand öffentlich zugänglicher Quellen bekannte Informationen über möglicherweise gegnerische Elemente
gewonnen. Das kann Angaben über die Provider einschließen, bei denen eine bestimmte
IP-Adresse registriert ist, oder öffentlich bekannte Informationen über mysteriöse, verdächtige Dateien.
Für ein effizientes Vorgehen müssen die Erfassungsprozesse für bestimmte Arten von Daten (FPC-, PSTR- und Sitzungsdaten usw.) gut dokumentiert und leicht zugänglich sein.
14.1.4 Verarbeitung
Manche Arten von Daten müssen nach der Erfassung verarbeitet werden, bevor sie für die
Analyse geeignet sind. Das kann sehr unterschiedliche Aufgaben umfassen.
Eine grobe Form der Verarbeitung kann darin bestehen, die gesammelten Daten einfach
nur auf die unmittelbar nützlichen Informationen einzudampfen, beispielsweise durch
die Anwendung von Filtern auf eine PCAP-Datei, die die Datenmenge verringern, oder
durch die Eingrenzung einer großen Menge von Protokolldateien auf diejenigen eines
bestimmten Typs.
Die detailliertere Verarbeitung kann es mit sich bringen, die Ausgabe eines Tools mithilfe
von BASH-Befehlen so zu formatieren, dass sie besser lesbar wird. Organisationen, die
eigene Tools oder Datenbanken für die Erfassung verwenden, können dazu auch Abfragen schreiben, um die Daten im gewünschten Format in die Datenbank einzufügen oder
daraus abzurufen.
Im Grunde genommen kann die Verarbeitung als eine Erweiterung der Erfassung angesehen werden, bei der die gesammelten Daten zurechtgestutzt und in eine für die Analyse
geeignete Form gebracht werden.
14.2 Aufklärung über eigene Elemente 467
14.1.5 Analyse
In der Analysephase werden die gesammelten und verarbeiteten Informationen untersucht, korreliert und in den erforderlichen Kontext gestellt, um sinnvoll genutzt werden
zu können. An dieser Stelle werden die einzelnen Daten, zwischen denen es nur einen
lockeren Zusammenhang gibt, zu einem sinnvollen Ganzen kombiniert, das zur Entscheidungsfindung herangezogen werden kann.
Die Analytiker kombinieren in dieser Phase die Ausgaben verschiedener Werkzeuge und
Datenquellen zu einem Host und zeichnen damit das Gesamtbild des betreffenden Hosts.
Es stehen natürlich viel mehr Informationen über lokale Hosts zur Verfügung, weshalb
dieses Gesamtbild auch Angaben über seine Tendenzen und üblichen Kommunikationspartner enthalten kann. Für die Analyse möglicherweise gegnerischer Hosts dagegen steht
eine viel geringere Datenmenge zur Verfügung. Dabei müssen auch Informationen aus
öffentlichen Quellen in die Analyse einfließen.
14.1.6 Weitergabe
Die meisten Organisationen haben kein ausgewiesenes Aufklärungsteam, weshalb die
NSM-Analytiker die Aufklärung für ihre Zwecke selbst durchführen müssen. Das kann ein
großer Vorteil sein, da diejenigen, die die aus der Aufklärung gewonnenen Informationen
nutzen, die gleichen Personen sind, die sie auch liefern (oder zumindest im selben Raum
oder in derselben Abteilung sitzen). In der letzten Phase des Zyklus werden die Ergebnisse der Aufklärung an die Personen oder Gruppen weitergegeben, die die Anforderungen
aufgestellt haben.
In den meisten Fällen werden die Ergebnisse der Aufklärung ständig überprüft und verbessert. Die positiven und negativen Aspekte der Endergebnisse werden kritisch beleuchtet, und diese Kritik geht wiederum in die Definition der Anforderung und die Planung
ein. Daher sprechen wir von einem Aufklärungszyklus statt von einer Aufklärungskette.
Im restlichen Teil dieses Kapitels sehen wir uns die Aufklärung über Freund und Feind
an und lernen Möglichkeiten kennen, die gewünschten Daten zu generieren und zu gewinnen. Auch wenn wir dabei nicht ausdrücklich auf die Struktur für die Aufklärung
eingehen, lassen sich die im Folgenden beschriebenen Maßnahmen darin einfügen und
an die Bedürfnisse praktisch aller Organisationen anpassen.
14.2 Aufklärung über eigene Elemente
Um Ihr Netzwerk wirkungsvoll schützen zu können, müssen Sie wissen, was sich alles
darin befindet und wie diese Elemente miteinander kommunizieren. Diese Aussage kann
man gar nicht überbetonen. Wie simpel oder ausgefeilt ein Angriff auch immer sein mag,
468 14 Aufklärung über Freund und Feind
wenn Sie die Rollen der Geräte in Ihrem Netzwerk nicht kennen und insbesondere nicht
wissen, wo sich die kritischen Daten befinden, können Sie weder sicher feststellen, ob
überhaupt ein Zwischenfall vorliegt, noch einen tatsächlichen Zwischenfall eindämmen
oder Angreifer aus Ihrem Netzwerk vertreiben. Aus diesem Grund ist die Aufklärung über
die eigenen Elemente so wichtig.
In diesem Buch beschreiben wir die Aufklärung über eigene Elemente als kontinuierlich
weiterentwickelten Vorgang, mit dem Analytiker Informationen über die Hosts gewinnen
können, die sie schützen sollen. Zu diesen Informationen gehört alles, was die Analytiker
für eine Untersuchung wissen müssen. Außerdem müssen diese Informationen jederzeit
abgerufen werden können. Im Allgemeinen zieht ein Analytiker die Informationen über
einen bestimmten Host zurate, wenn er einen Alarm in Bezug zu diesem Host untersucht,
also wenn der Host das Opfer eines Angriffs geworden zu sein scheint. Es ist daher nicht
unüblich, dass ein Analytiker während seiner Schicht auf solche Daten für verschiedene
Hosts mehrfach zugreift. Außerdem können bei der Analyse von Aufklärungsergebnissen
über eigene Elemente Anomalien entdeckt werden, die eine Untersuchung auslösen. Sehen
wir uns nun einige Möglichkeiten an, aus den Netzwerkdaten Aufklärungsinformationen
über eigene Hosts zu gewinnen.
14.2.1 Anamnese und physische Untersuchung von Netzwerkelementen
Bei einem neuen Patienten führt ein Arzt erst eine Anamnese durch, um die Krankengeschichte in Erfahrung zu bringen, und dann eine körperliche Untersuchung. Dieses Prinzip lässt sich auch auf die Aufklärung über eigene Netzwerkelemente anwenden.
Zur Anamnese gehören Fragen über aktuelle und frühere Krankheiten, die Auswirkungen
auf die jetzige und zukünftige Gesundheit des Patienten haben können. Gewöhnlich wird
auch die Krankengeschichte von unmittelbaren Familienangehörigen berücksichtigt, um
Risikofaktoren für den Patienten erkennen und abschwächen zu können.
Anstelle der Krankengeschichte steht bei einem Netzwerkelement der Verbindungsverlauf. Dazu gehören frühere Kommunikationstransaktionen mit anderen Hosts im und
außerhalb des Netzwerks. Dabei werden jedoch nicht nur die Hosts betrachtet, die in diese
Kommunikation verwickelt waren, sondern auch die von dem Host verwendeten Dienste,
sowohl als Client als auch als Server. Wenn wir den Verbindungsverlauf kennen, haben
wir eine gute Grundlage, um im Rahmen einer Untersuchung die Gültigkeit neuer Verbindungen einzuschätzen, die dieser Host eingeht.
Bei einer ärztlichen Untersuchung wird die Gesundheit des Patienten ermittelt. Dazu werden neben demografischen Angaben des Patienten auch Größe, Gewicht, Blutdruck usw.
bestimmt. Ergebnis dieser Untersuchung ist ein Gesamteindruck von der Gesundheit des
Patienten. Oft werden solche Untersuchungen für bestimmte Zwecke durchgeführt, z. B.
für Versicherungen oder um die Erlaubnis für einen Sport zu erhalten.
14.2 Aufklärung über eigene Elemente 469
Für die »ärztliche Untersuchung« unserer Netzwerkelemente müssen wir Kriterien aufstellen, anhand derer wir den »Gesundheits«-Zustand des Elements einschätzen können.
Dazu können Dinge wie die IP-Adresse und der DNS-Name des Elements gehören, das
VLAN, in dem es sich befindet, seine Rolle (Arbeitsstation, Webserver usw.), das Betriebssystem oder die physische Platzierung im Netzwerk. Das Ergebnis dieser Untersuchung
ist sein Betriebszustand, anhand dessen wir dann im Rahmen einer Untersuchung seine
Aktivitäten einschätzen können.
Im Folgenden sehen wir uns einige Methoden an, um eine solche Anamnese und Untersuchung für Netzwerkelemente durchzuführen. Für den »Gesundheitscheck« können wir
Werkzeuge wie Nmap heranziehen, die es uns ermöglichen, ein Netzwerkbestandsmodell aufzustellen. Die passive Erfassung von Echtzeitdaten über die Elemente mithilfe von
PRADS dagegen dient dazu, die »Krankengeschichte« zu ermitteln.
14.2.2 Ein Bestandsmodell des Netzwerks aufstellen
Ein Bestandsmodell ist, einfach gesagt, eine Liste aller Hosts in Ihrem Netzwerk mitsamt
den zugehörigen wichtigen Informationen wie den IP-Adressen, DNS-Namen, allgemeinen Rollen (Server, Arbeitsstation, Router usw.), angebotenen Diensten (Webserver, SSHServer, Proxyserver usw.) und Betriebssystemen. Dies ist die grundlegendste Form von
Informationen über die eigenen Elemente. Alle Sicherheitsteams müssen sich darum bemühen, eine solche Liste aufzustellen.
Wie Sie sich vorstellen können, gibt es verschiedene Vorgehensweisen, um ein solches Bestandsmodell des Netzwerks aufzubauen. Viele Organisationen setzen ohnehin irgendeine
Form von Bestandsverwaltungssoftware ein, die oft auch die erforderlichen Daten für dieses Modell liefern kann. Dies bildet dann auch oft die einfachste Möglichkeit, die Daten
den Analytikern zur Verfügung zu stellen.
Falls Ihre Organisation nicht über eine solche Software verfügt, bleibt Ihnen nichts anderes übrig, als selbst für die erforderlichen Daten zu sorgen. Nach meiner Erfahrung gibt
es keine definitive Formel, um ein Bestandsmodell aufzustellen. Wenn Sie sich ein Dutzend Organisationen ansehen, werden Sie ein Dutzend Methoden finden, um ein solches
Modell anzulegen, und ein weiteres Dutzend Methoden, um auf die Daten zuzugreifen
und sie anzuzeigen. In diesem Abschnitt geht es nicht darum, Ihnen einen genauen Weg
vorzuschreiben, auf dem Sie an die Daten kommen, da Sie diesen Weg unter Verwendung
der in Ihrer Organisation genutzten Technologien selbst finden müssen. Hier sollen Sie lediglich eine Vorstellung davon bekommen, wie ein solches Bestandsmodell aussieht, und
einige Anregungen dafür erhalten, wie Sie anfangen können, um die benötigten Daten
bereitzustellen.
470 14 Aufklärung über Freund und Feind
Vorsicht
Eine Bestandsaufnahme ist selten zu 100 % genau. In riesigen Organisationen
mit Millionen von Geräten ist es einfach nicht möglich, Bestandsmodelle zu unterhalten, die stets vollständig und aktuell sind. Wenn eine 100-%-Lösung nicht
machbar ist, dann sollten Sie sich auch keine solche Lösung zum Ziel setzen. Es
ist in solchen Situationen besser, eine 80-%-Lösung anzustreben, weil 80 % immer noch besser sind als 0 %. In jedem Fall aber sollten Sie Ihr Möglichstes tun,
um ein Bestandsmodell der kritischen Geräte aufzustellen, die Sie während der
Planungsphase ermittelt haben.
Eine Möglichkeit, sich die Daten zu beschaffen, ist ein interner Portscan. Das können Sie
mit kommerzieller Software, aber auch mit freier Software wie Nmap tun. Beispielsweise
können Sie einen einfachen SYN-Scan mit dem folgenden Befehl durchführen:
nmap –sn 172.16.16.0/24
Dadurch wird ein ICMP-Scan (Ping) an allen Hosts im Netzwerkbereich 172.16.16.0/24
durchgeführt. Die Ausgabe sehen Sie in Abb. 14.2.
Abbildung 14.2: Ausgabe eines Ping-Scans in Nmap
Wie Sie anhand dieser Daten sehen, gibt jeder Host, der auf ICMP-Echoanforderungen
reagieren darf, eine ICMP-Echoantwort zurück. Sofern alle Hosts in Ihrem Netzwerk so
eingerichtet sind, dass sie auf ICMP-Datenverkehr reagieren (oder wenn eine entspre-
14.2 Aufklärung über eigene Elemente 471
chende Ausnahme in der Hostfirewall angegeben ist), können Sie damit die aktiven Hosts
im Netzwerk ermitteln. Dadurch erhalten wir eine grundlegende Liste der IP-Adressen.
Wir können aber auch anspruchsvollere Scans vornehmen. Bei einem SYN-Scan wird versucht, mit jedem Host im Netzwerk zu kommunizieren, der über einen offenen TCP-Port
verfügt. Dazu verwenden Sie folgenden Befehl:
nmap –sS 172.16.16.0/24
Damit wird TCP-SYN-Paket an die 1000 am häufigsten verwendeten Ports aller Hosts im
Netzwerk 172.16.16.0/24 gesendet. Die Ausgabe sehen Sie in Abb. 14.3.
Abbildung 14.3: Ausgabe eines SYN-Scans in Nmap
Der SYN-Scan liefert uns einige Informationen mehr. Neben den IP-Adressen der aktiven
Hosts im Netzwerk haben wir nun auch eine Liste der Ports, die auf diesen Geräten geöffnet sind, was ein Indiz für die bereitgestellten Dienste ist.
Wir können sogar noch weiter gehen und die Nmap-Funktionen zur Betriebssystem- und
Versionserkennung nutzen:
nmap –sV -O 172.16.16.0/24
472 14 Aufklärung über Freund und Feind
Dieser Befehl führt einen normalen SYN-Portscan und daraufhin eine Reihe von Tests
durch, um die an den offenen Ports lauschenden Dienste zu bestimmen und das Betriebssystem des Geräts zu erraten. Die Ausgabe sehen Sie in Abb. 14.4.
Abbildung 14.4: Ausgabe der Versions- und Betriebssystemerkennung
Ein solcher Scan ruft im Netzwerk eine ganze Menge zusätzlichen Datenverkehr hervor,
hilft aber dabei, das Bestandsmodell abzurunden, da er Informationen über die Betriebssysteme und die an den offenen Ports ausgeführten Dienste liefert.
In dem hier gezeigten Standardausgabeformat von Nmap lassen sich die Daten sehr gut
lesen, allerdings nicht so leicht durchsuchen. Wir können Nmap jedoch auch dazu bringen, die Ergebnisse in einem einzeiligen Format anzuzeigen, das sich mit Grep gut durchsuchen lässt und sich für Analytiker sehr gut zum Nachschlagen eignet. Dazu müssen wir
an die zuvor gezeigten Befehle lediglich -oG<Dateiname> anhängen. In Abb. 14.5 durchsuchen wir mit grep eine in diesem Format vorliegende Datei (data.scan) nach Daten
über eine bestimmte IP-Adresse (172.16.16.10).
14.2 Aufklärung über eigene Elemente 473
Abbildung 14.5: Mit Grep durchsuchbare Nmap-Ausgabe
Ein Scanner wir Nmap ist nicht immer besonders aussagekräftig. Viele Organisationen
legen störende Scans auf die Abendstunden, wobei es sein kann, dass manche Geräte
schon ausgeschaltet sind und daher nicht erfasst werden. Auch mobile Geräte, die nur
zeitweilig mit dem Netzwerk verbunden sind, können dabei übersehen werden, also
etwa Laptops, die die Angestellten abends mit nach Hause nehmen oder die von Außendienstmitarbeitern verwendet werden. Daher sollten Sie bei einer Bestandsaufnahme
aufgrund von Netzwerkscans die Ergebnisse mehrerer Scans kombinieren, die zu unterschiedlichen Zeiten durchgeführt wurden. Um sicherzustellen, dass auch alle Geräte
erkannt werden, kann es außerdem erforderlich sein, verschiedene Arten von Scans zu
verwenden. Um ein Bestandsmodell aus Scandaten aufzubauen, ist mehr erforderlich,
als einen einzigen Scan zu starten und die Ergebnisse zu speichern. Es sind gemeinsames Handeln und eine Nachbearbeitung notwendig, um die gewünschten Resultate zu
erzielen.
Wie zuverlässig Sie Ihre Scandaten auch immer einschätzen, Sie sollten sie in jedem Fall
anhand von Daten aus anderen Quellen überprüfen. Dabei kann es sich um etwas handeln, was in Ihrem Netzwerk bereits vorhanden ist, etwa ein DNS-Transaktionsprotokoll,
aber auch um einen Teil der NSM-Datenmenge, z. B. Sitzungsdaten. In den Kapiteln 4
und 11 haben Sie einige brauchbare Techniken kennengelernt, um mit SiLK Daten über
die eigenen Hosts aus Sitzungsdaten zu gewinnen. Eine weitere Möglichkeit bieten passive
Tools wie PRADS, das wir uns im nächsten Abschnitt ansehen werden.
14.2.3 PRADS (Passive Real-Time Asset Detection System)
PRADS gewinnt aus dem Netzwerkverkehr Daten über die Hosts und Dienste, womit Sie
eine Bestandsaufnahme Ihres Netzwerks machen können. Es basiert auf zwei anderen sehr
erfolgreichen Tools, nämlich PADS (Passive Asset Detection Sytem) und P0f, einem passiven Werkzeug zur Betriebssystemermittlung. PRADS kombiniert die Funktionen dieser
beiden Programme zu einem einzigen Dienst, der für die Informationsbeschaffung über
eigene Elemente sehr gute Dienste leistet. Die Daten, die PRADS dazu generiert, ähneln
im weitesten Sinne den Sitzungsdaten aus SiLK oder Argus.
PRADS ist standardmäßig in Security Onion enthalten, sodass wir die Daten mithilfe
einer Abfrage in Sguil untersuchen können. Im nächsten Kapitel sehen wir uns Sguil genauer an, aber in Kapitel 9 haben wir bereits kurz erwähnt, dass es sich um eine Konsole
handelt, in der Sie die von Erkennungsmechanismen hervorgerufenen Alarme und die
Daten aus anderen Erfassungs- und Erkennungstools einsehen können.
474 14 Aufklärung über Freund und Feind
Sie können den Sguil-Clilent auf dem Desktop von Security Onion starten, aber auch auf
einem anderen Gerät, zu dem Sie dann eine Verbindung über das Netzwerk aufbauen. In
jedem Fall sortieren Sie anschließend die angezeigten Alarme nach der Spalte Event Message, um die PRADS-Einträge zu finden. Es kann sein, dass Sguil immer noch von PADSEinträgen spricht, aber keine Sorge, es handelt sich definitiv um PRADS-Daten. Abb. 14.6
zeigt Beispiele für PRADS-Protokolleinträge.
Abbildung 14.6: PRADS-Daten in Sguil
In dieser Abbildung sehen Sie verschiedene Arten von Einträgen. Ein Alarm vom Typ New
Asset wird generiert, wenn ein Host im Netzwerk kommuniziert, der zuvor noch nicht zu
sehen gewesen ist. Dagegen bedeutet Changed Asset, dass ein bereits bekannter Host ein
Kommunikationsverhalten zeigt, das zuvor noch nicht beobachtet wurde, indem er z. B.
einen neuen HTTP-Benutzeragenten, einen neuen Dienst o. Ä. nutzt.
Um zu verstehen, wie diese Meldungen zustande kommen, sehen wir uns einige beispielhafte PRADS-Protokolldaten an. In einer Standardinstallation von Security Onion wird
PRADS mit einem Befehl wie dem folgenden ausgeführt:
prads -i eth1 -c /etc/nsm/<Sensorname>/prads.conf -u sguil -g sguil -L /
nsm/sensor_data/<Sensorname>/sancp/ -f /nsm/sensor_data/<Sensorname>/
pads.fifo -b ip or (vlan and ip)
Die folgende Aufstellung zeigt die hier verwendeten sowie einige weitere nützliche Befehlszeilenargumente für PRADS:
••
••
••
••
-b<Filter>: Setzt beim Abhören des Netzwerkverkehrs die angegebenen BPFs ein.
-c<Konfigurationsdatei>: Gibt die PRADS-Konfigurationsdatei an.
-D: Führt PRADS als Daemon aus.
-f<Datei>: Zeichnet die Netzwerkelemente in einer FIFO-Datei (First In, First Out)
auf.
•• -g<Gruppe>: Gibt die Gruppe an, unter der PRADS ausgeführt wird.
14.2 Aufklärung über eigene Elemente 475
•• -i<Schnittstelle>: Nennt die Schnittstelle, an der PRADS lauscht. Wenn diese Angabe
fehlt, nimmt PRADS die Schnittstelle mit der niedrigsten Nummer.
•• -L<Verzeichnis>: Zeichnet Ausgaben vom Cxtracker-Typ in dem angegebenen Verzeichnis auf.
•• -l<Datei>: Zeichnet die Netzwerkelemente in einer linearen Datei auf.
•• -r<Datei>: Liest Daten aus einer PCAP-Datei, anstatt sie von der Verbindung abzugreifen.
•• -u<Benutzername>: Gibt den Benutzer an, unter dessen Konto PRADS ausgeführt wird.
•• -v: Erhöht die Menge der Informationen in der PRADS-Ausgabe.
In Security Onion läuft PRADS standardmäßig unter dem Konto des Benutzers Sguil und
greift die Daten von der Verbindung ab. Die gesammelten Daten werden in einer FIFODatei gespeichert, sodass sie in eine Datenbank übernommen werden können, auf die
Sguil Zugriff hat.
Da die meisten Laufzeitoptionen von PRADS in Security Onion mithilfe von Befehlszeilenargumenten festgelegt werden, besteht der einzige Zweck der Datei prads.conf darin,
die Variable home_nets für den IP-Bereich anzugeben (siehe Abb. 14.7). Diese Variable teilt
PRADS mit, welche Netzwerke es überwachen soll. In den meisten Fällen werden Sie hier
die gleichen Angaben machen wie für die Variable $HOME_NET in Snort und Suricata.
Abbildung 14.7: Angabe der Variable home_nets in prads.conf
Die Speicherung der PRADS-Daten in einem Datenbankformat erleichtert es, sie abzufragen oder Tools zu schreiben, die diese Daten nutzen. Allerdings ist dies nicht die beste
Möglichkeit, die Rohdaten einzusehen. Zum Glück werden die Daten jedoch auch in
der linearen Textdatei /var/log/prads-asset.log gespeichert. Ein Beispiel dafür sehen Sie in
Abb. 14.8.
476 14 Aufklärung über Freund und Feind
Abbildung 14.8: Eine PRADS-Protokolldatei
Die erste Zeile dieser Datei definiert das Format der Einträge:
asset,vlan,port,proto,service,[service-info],distance,discovered
Dabei werden die folgenden Felder verwendet:
••
••
••
••
••
asset: Die IP-Adresse des erkannten Elements aus der Variable home_nets
vlan: Das VLAN-Kennzeichen des Elements
port: Die Portnummer des erkannten Dienstes
proto: Die Protkollnummer des erkannten Dienstes
service: Der Dienst, den PRADS erkannt hat. Dabei kann das Netzwerkelement sowohl als Client als auch als Server mit diesem Dienst kommunizieren.
•• service-info: Der Fingerabdruck des Dienstes und die zugehörige Ausgabe.
•• distance: Die Entfernung zu dem Element, bestimmt anhand des geratenen ursprünglichen TTL-Werts.
•• discovered: Der Unix-Zeitstempel des Zeitpunktes, an dem die Daten erfasst wurden.
Wie Sie anhand dieser Daten erkennen können, nimmt PRADS die zuvor in Sguil gezeigten Einschätzungen darüber, ob es sich um ein neues oder ein verändertes Element
handelt, nicht selbst vor. Es zeichnet einfach die beobachteten Daten auf und überlässt
jegliche weitere Verarbeitung dem Benutzer, Skripten oder Anwendungen. Die Alarme
New Asset und Changed Asset in Sguil werden nicht von PRADS selbst generiert, sondern
von Sguil auf der Grundlage der PRADS-Daten.
Sinnvolle Verwendung von PRADS-Daten
Es gibt verschiedene Möglichkeiten, PRADS-Daten für die interne Aufklärung zu verwenden. Die erste Methode besteht darin, die Benachrichtigungen von Sguil über neue und
veränderte Elemente zu nutzen. Ein Beispiel dafür sehen Sie in Abb. 14.9.
14.2 Aufklärung über eigene Elemente 477
Abbildung 14.9: Sguil-Abfrage nach einem einzelnen Host
Hier habe ich eine Sguil-Abfrage nach allen Ereignissen im Zusammenhang mit einem
bestimmten Alarm durchgeführt. Das können Sie in Sguil ziemlich leicht machen, indem
Sie auf ein Ereignis für einen Host rechtsklicken, auf Quick Query und dann auf Query
Event Table zeigen und schließlich die Option SrcIP oder DstIP wählen, je nachdem, ob Sie
an Ereignissen für die Quell- oder die Zieladresse interessiert sind. In der Abbildung sehen
Sie eine Reihe von Ereignissen im Zusammenhang mit dem Host 172.16.16.145, unter
anderem einige Snort-Alarme, die besuchten URLs und weitere PRADS-Alarme.
Unter den gezeigten PRADS-Alarmen sind vier vom Typ New Asset, die auf die vier Vorgänge verweisen, bei denen der Host zum ersten Mal mit den in dem Alarm aufgeführten
Zieladressen Verbindung aufgenommen hat:
••
••
••
••
Alarm-ID 4.66: HTTP-Verbindung zu 23.62.111.152
Alarm-ID 4.67: HTTPS-Verbindung zu 17.149.32.33
Alarm-ID 4.68: HTTPS-Verbindung zu 17.149.34.62
Alarm-ID 4.69: NTP-Verbindung zu 17.151.16.38
Bei der Untersuchung eines Ereignisses können Sie dadurch unmittelbar erkennen, ob
das betreffende eigene Gerät jemals zuvor Verbindung mit einem bestimmten externen
Gerät aufgenommen hat, was wertvollen Kontext liefert. Wenn Sie verdächtigen Datenverkehr zu einer unbekannten Adresse finden und das eigene Gerät vorher niemals mit
dieser Zieladresse kommuniziert hat, dann ist das ein Zeichen dafür, dass wirklich etwas
Verdächtiges vor sich geht, was eine eingehendere Untersuchung rechtfertigt.
In der Abbildung sehen Sie auch einen Change-Asset-Alarm aufgrund eines neuen HTTPBenutzeragentenstrings:
•• Alarm-ID 4.71: Mozilla/4.0 (kompatibel; UPnP/1.0; Windows NT/5.1)
Ein solcher Alarm zeigt, dass der eigene Host etwas tut, was er nie zuvor getan hat. Das
kann zwar durchaus etwas Harmloses wie das Herunterladen eines neuen Browsers sein,
aber auch auf eine schädliche Aktivität hindeuten. Seien Sie besonders achtsam, wenn
478 14 Aufklärung über Freund und Feind
Geräte plötzlich neue Dienste anbieten, insbesondere wenn es sich um Arbeitsstationen
handelt, die eigentlich nicht als Server fungieren sollten.
All dies bietet uns die Möglichkeit, neue oder veränderte Verhaltensweisen eigener Hosts
zu erkennen, was sehr wertvolle Informationen über das eigene Netzwerk liefert. Es kann
zwar einige Zeit dauern, bis PRADS Ihr Netzwerk nach der ersten Konfiguration kennengelernt hat, aber wenn das erst einmal der Fall ist, bietet es einen Schatz an Informationen,
die Sie sonst nur aufgrund aufwendiger Analyse von Sitzungsdaten gewinnen könnten.
Eine andere nutzbringende Verwendung von PRADS-Daten besteht darin, ein Referenzmodell der eigenen Elemente aufzustellen. Da PRADS alle gesammelten Informationen
über die in der Variable home_nets angegebenen Elemente speichert, können Sie sie nach
sämtlichen Daten für die einzelnen Hosts durchsuchen. Das macht das im Lieferumfang
von PRADS enthaltene Perl-Skript prads-asset-report möglich. Es nimmt die Ausgabe einer PRADS-Protokolldatei entgegen und gibt selbst eine Aufstellung aller Informationen
zurück, die es über die einzelnen IP-Adressen hat. Wenn Sie PRADS so einrichten, dass es
Daten in /var/log/prads-asset.log aufzeichnet, können Sie einfach den Befehl prads-assetreport ausführen, um diesen Bericht zu generieren. Anderenfalls müssen Sie den Speicherort der PRADS-Daten mit dem Argument -r<Datei> angeben. Ein Beispiel für einen
solchen Bericht sehen Sie in Abb. 14.10.
Abbildung 14.10: Ein PRADS-Bericht
14.2 Aufklärung über eigene Elemente 479
Wie Sie sehen, versucht PRADS auch zu erraten, welche Betriebssysteme auf den einzelnen Geräten vorhanden sind. In dem Beispiel in der Abbildung ist das jedoch nur bei
einem einzigen Gerät gelungen. Je besser PRADS die im Netzwerk kommunizierenden
Geräte beobachten kann, umso genauer wird seine Einschätzung.
In manchen Fällen ist es sinnvoll, diesen Bericht regelmäßig zu generieren und in einem
Format bereitzustellen, das von Analytikern leicht durchsucht werden kann. Mit dem Argument -w<Dateiname> können Sie den Bericht in einer Datei speichern. Wenn die Analytiker selbst direkten Zugriff auf die PRADS-Protokolldaten haben, können sie selbst das
Skript prads-asset-report einsetzen, um jeweils einen aktuellen Bericht zu generieren. Mit
dem Schalter -i lässt sich dieser Bericht wie folgt auch für eine einzelne IP-Adresse erstellen:
prads-asset-data –i 172.16.16.145
Die Ausgabe dieses Befehls sehen Sie in Abb. 14.11.
Abbildung 14.11: Suche nach einzelnen Adressen in den PRADS-Daten
Wenn Sie mithilfe von PRADS ein Bestandsmodell aufstellen, dürfen Sie nicht vergessen,
dass es sich dabei um ein passives Werkzeug handelt, das nur Informationen über Geräte
liefert, die es bei der Kommunikation über Sensorgrenzen hinweg beobachten kann. Geräte, die nur innerhalb eines Netzwerksegments kommunizieren und niemals über eine
von einem Sensor überwachte Verbindung, kann es daher nicht erkennen. Daher müssen
Sie PRADS immer mit anderen Techniken einsetzen, z. B. mit einem aktiven Scan, um das
Inventar Ihres Netzwerks genau zu bestimmen.
PRADS ist ein sehr leistungsfähiges und trotzdem einfaches Werkzeug, das Sie für die Informationsgewinnung über das eigene Netzwerk nutzen können. Da es so wenige Anforderungen stellt und so vielseitig ist, lässt es sich in die meisten Umgebungen aufnehmen.
Mehr über PRADS erfahren Sie auf http://gamelinux.github.io/prads/.
480 14 Aufklärung über Freund und Feind
14.3 Aufklärung über Bedrohungen
Nachdem Sie über Ihr Netzwerk Bescheid wissen, ist es an der Zeit, den Gegner kennenzulernen. Daher wollen wir uns als Nächstes mit der Aufklärung über Bedrohungen befassen, was für Sie nichts Neues sein sollte, wenn Sie in der Informationssicherheit arbeiten.
Angesichts der täglichen Gefahr von gezielten Angriffen werben viele Hersteller damit,
dass ihre Lösung es Ihnen ermöglicht, »Informationen über Angreifer zu gewinnen und
damit den APT zu stoppen«. Das ist zwar typisch schräges Marketingsprech, aber die Aufklärung über Bedrohungen ist tatsächlich ein wichtiger Aspekt der Analyse im Rahmen
des NSM und von entscheidender Bedeutung für den Erfolg.
Bei der Aufklärung über Bedrohungen konzentrieren wir uns ausschließlich auf die Gegner und versuchen Daten zu erfassen, mit deren Hilfe wir die Natur der Bedrohungen
einschätzen können. Diese Form von Aufklärung wiederum kann in die drei Teilbereiche
strategische, operative und taktische Aufklärung gegliedert werden (siehe Abb. 14.12).
Taksche
Aulärung
Operave Aulärung
Strategische Aulärung
Abbildung 14.12: Formen der Aufklärung über Bedrohungen
Bei der strategischen Aufklärung geht es um Informationen im Zusammenhang mit der
Strategie, der Politik und den großmaßstäblichen Plänen eines Angreifers. Eine Aufklärung
auf diesem Niveau führen gewöhnlich nur staatliche oder militärische Organisationen
als Reaktion auf Bedrohungen durch andere Staaten oder Streitkräfte durch. Allerdings
entwickeln auch große Organisationen immer mehr die Fähigkeiten zu einer solchen Aufklärung, und einige bieten die strategische Aufklärung sogar als Dienstleistung an. Dabei
geht es um die langfristigen Ziele der Kraft, die die einzelnen Angreifer unterstützt. Zu den
Ergebnissen dieser Art von Aufklärung gehören Richtliniendokumente, Militärdoktrinen,
Positionspapiere und die Ziele von Regierung, Militär oder anderen Gruppen.
Bei der operativen Aufklärung geht es um Informationen darüber, wie Angreifer die Operationen zum Erreichen ihrer strategischen Ziele planen und unterstützen. Im Gegensatz zur strategischen Aufklärung geht es hier um enger gefasste Ziele, gewöhnlich um
kurzfristige Zielsetzungen, die nur einen Teil des Gesamtbildes ausmachen. Auch dies fällt
14.3 Aufklärung über Bedrohungen 481
gewöhnlich mehr in die Domäne von Staaten und Streitkräften, doch auch einzelne Organisationen können Angreifern zum Opfer fallen, deren Maßnahmen operative Ziele erfüllen sollen. Daher haben einige öffentliche Organisationen Einblick in diese Angriffe und
können operative Informationen beschaffen. Die Ergebnisse dieser Art von Aufklärung
ähneln denen der strategischen Aufklärung, sind aber meistens enger gefasst.
Bei der taktischen Aufklärung geht es um Informationen im Zusammenhang mit einzelnen Aktionen bei der Durchführung von Operationen. Hier beschäftigen wir uns mit
den Werkzeugen, Taktiken und Vorgehensweisen von Angreifern. Dies ist das Gebiet, auf
das 99 % aller NSM-Sicherheitsteams ihre Anstrengungen konzentrieren. Hier werden
die einzelnen Aktionen der Angreifer erfasst und analysiert. Zu den Ergebnissen zählen
Einbruchsindikatoren (wie IP-Adressen, Dateinamen oder Textstrings) oder Listen von
typischen Angriffswerkzeugen. Diese Informationen veralten schnell.
Bericht von der Front
Die Erörterung der Aufklärung über Bedrohungen führt oft zu einer Diskussion
über die Zurückführung der Aktionen eines Angreifers zu einer Einzelperson oder
Gruppe. Erkennung und Zuschreibung sind jedoch zwei verschiedene Dinge, und
damit sind auch Erkennungs- und Zuschreibungsindikatoren etwas ganz anderes. Bei der Erkennung geht es darum, Zwischenfälle aufzuspüren, bei der Zuschreibung dagegen darum, diese Zwischenfälle auf die Urheber zurückzuführen.
Das ist zwar eine sinnvolle Maßnahme, die aber ohne die Korrelation der Daten
aus der strategischen, operativen und taktischen Aufklärung nicht durchgeführt
werden kann. Ohne erheblichen Einblick in die Daten anderer Organisationen zu
nehmen, können jedoch die wenigsten Organisationen im privaten Sektor eine
solche Erfassung und Analyse leisten. Die Sammlung von Einbruchsindikatoren
aus mehreren Netzwerkangriffen für die taktische Aufklärung ist ­jedoch ein erreichbares Ziel. Allerdings liegt die Erfassung und Analyse von Daten aus anderen
Quellen als den herkömmlichen – Menschen (Human Intelligence, HUMINT),
Signalübertragung (Signals Intelligence, SIGINT) und Geoinformationen (Geospatial Intelligence, GEOINT) – außerhalb der praktischen Möglichkeiten der
meisten Unternehmen. Selbst Organisationen, die diese Möglichkeiten haben,
werden durch Gesetze in deren Anwendung beschränkt.
Bei der Analyse der Erkenntnisse aus taktischer Aufklärung wird eine Bedrohung zunächst
gewöhnlich als eine IP-Adresse wahrgenommen, die in einem IDS-Alarm oder einem anderen Erkennungsmechanismus angezeigt wird, oder als eine verdächtige Datei, die ein
Client heruntergeladen hat. Zur taktischen Aufklärung werden diese Daten untersucht
und in einer Untersuchung miteinander in Verbindung gebracht. Im restlichen Teil dieses
Kapitels sehen wir uns Maßnahmen für die taktische Aufklärung über gegnerische Elemente an, die in NSM-Umgebungen auftauchen können.
482 14 Aufklärung über Freund und Feind
14.3.1 Recherche über gegnerische Hosts
Wenn aufgrund einer verdächtigen Kommunikation zwischen einem eigenen und einem
möglicherweise gegnerischen Host ein Alarm ausgelöst wird, sollten die Analytiker unter
anderem auch eine taktische Aufklärung des externen Hosts durchführen. Schließlich versorgen die meisten IDS-Alarme Sie schon mit der IP-Adresse dieses Hosts und einer Probe
der Kommunikation, die den Alarm veranlasst hat. In diesem Abschnitt sehen wir uns
an, welche Informationen Sie allein aus der IP-Adresse des Hosts oder einem Domänen­
namen gewinnen können.
Interne Datenquellen
Die schnellste Möglichkeit, Informationen über externe und potenziell gefährliche Hosts
einzuholen, besteht darin, die bereits vorhandenen internen Datenquellen zu untersuchen. Ein möglicherweise gegnerischer Host, an dem Sie interessiert sind, hat wahrscheinlich schon mit irgendeinem Ihrer Hosts kommuniziert, sodass Sie bereits Daten
über ihn gesammelt haben. Mit diesen Daten können Sie nun versuchen, folgende Fragen
zu beantworten:
1. Hat der gegnerische Hosts jemals zuvor mit diesem eigenen Host kommuniziert?
2. Welcher Art ist die Kommunikation dieses Hosts mit dem eigenen Host?
3. Hat der gegnerische Hosts jemals zuvor mit anderen eigenen Hosts in diesem Netzwerk kommuniziert?
Die Antworten auf diese Fragen können in verschiedenen Datenquellen zu finden sein.
Wenn Sie entsprechende Daten aus der internen Aufklärung zur Hand haben – beispielsweise PRADS-Daten –, können Sie Frage Nr. 1 schnell beantworten, also herausfinden, ob
der externe Host zum ersten Mal mit dem eigenen Host kommuniziert oder das schon
früher getan hat. Möglicherweise können Sie sogar das Betriebssystem erkennen, dass auf
diesem Host aufgeführt wird. Wenn Ihnen solche Aufklärungsdaten nicht zur Verfügung
stehen, bilden Sitzungsdaten wahrscheinlich die schnellste Möglichkeit, die Antwort zu
finden.
Frage 2 lässt sich nur mithilfe von detaillierteren Daten beantworten. In Sitzungsdaten
finden Sie zwar grundlegende Angaben wie den Zeitpunkt der Kommunikation und die
dabei verwendeten Ports, aber nicht genügend Einzelheiten, um genau zu erkennen, was
vor sich gegangen ist. In manchen Fällen kann das Erkennungswerkzeug, das den Alarm
ausgelöst hat, diese Einzelheiten liefern. Snort und Suricata sagen Ihnen, welches Paket
mit einer ihrer Signaturen übereingestimmt hat, und Programme wie Bro geben Ihnen so
viele zusätzliche Informationen, wie Sie bei der Einrichtung verlangt haben. In anderen
Fällen kann es sein, dass Sie die FPC- oder PSTR-Daten untersuchen müssen, um die Antwort zu finden. Dazu sind Erfahrungen in der Paketanalyse sehr nützlich.
14.3 Aufklärung über Bedrohungen 483
Zur Beantwortung von Frage 3 ist es am besten, bei den Sitzungsdaten anzufangen, da
dies die schnellste Möglichkeit ist, Informationen über die Kommunikation zwischen den
Hosts zu finden. Wenn Sie festgestellt haben, dass es tatsächlich bereits eine solche Kommunikation gegeben hat, dann sollten Sie sich jedoch weiteren Quellen wie FPC- oder
PSTR-Daten zuwenden, um die Natur dieser Kommunikation genauer zu bestimmen.
Falls keine entsprechenden Sitzungsdaten zur Verfügung stellen, können Sie die Antwort
anhand von PRADS-Daten finden.
Bei der groben Analyse dieser Art geht es darum, die Punkte zu verbinden und Muster zu
finden, etwa die Verwendung bestimmter Dienste bei der Kommunikation des gegnerischen Hosts mit den eigenen Geräten, die Einhaltung bestimmter Zeitabstände oder der
Zusammenhang mit technischen Vorfällen oder Ereignissen in der realen Welt. Bei einer
detaillierteren Analyse geht es darum, Muster wie die Verwendung maßgeschneiderter
C2-Protokolle oder den Download verdächtiger Dateien von anderen Hosts zu erkennen.
Anhand der gesammelten Antworten auf diese drei Fragen können Sie Informationen
über das Verhalten gegnerischer Hosts in Ihrem Netzwerk sammeln. Die Analyse dieses
Verhaltens bei einem einzigen Ereignis oder einer einzigen Kommunikationssequenz liefert meistens nicht genug Belege für eine weitergehende Untersuchung, aber angewandt
auf die Kommunikation im gesamten Netzwerk kann diese Analyse der Schlüssel sein, um
zu erkennen, ob ein Zwischenfall stattgefunden hat.
Aufklärung anhand von öffentlich verfügbaren Quellen
Nach den internen sollten Sie sich auch noch anderen verfügbaren Informationsquellen
zuwenden. Zur Aufklärung anhand von öffentlich verfügbaren Quellen (Open Source
Intelligence, OSINT) werden beim NSM hauptsächlich öffentliche Websites zurate gezogen. Der Vorteil besteht darin, dass Sie damit Informationen über einen Gegner einholen
können, ohne Pakete an ihn zu senden.
Im Folgenden wollen wir uns einige Websites ansehen, auf denen Sie Informationen über
IP-Adressen, Domänennamen und Schaddateien einholen können. Die Aufklärung aus
öffentlichen Quellen ist ein weites Feld, das viele verschiedene Vorgehensweisen umfasst,
und könnte leicht ein ganzes Buch füllen. Eine ausführlichere Liste von Websites für
OSINT-Recherchen finden Sie auf hptt://www.appliednsm.com/osint-resources.
Registraturen für IP-Adressen und Domänennamen
Die IANA (International Assigned Numbers Authority) ist als Abteilung der ICANN (Internet Corporation for Assigned Names and Numbers (ICANN) dafür zuständig, die Zuweisung von IP-Adressen und ASNs (Autonomous System Number), die Verwaltung von
DNS-Stammzonen usw. zu überwachen. Die Zuweisung der Adressen wiederum delegiert
die IANA an fünf regionale Internetregistraturen (RIRs), die dafür verantwortlich sind,
Aufzeichnungen über die Zuordnung von IP-Adressen zu deren registrierten Besitzern zu
pflegen. Eine Liste dieser Registraturen finden Sie in Tabelle 14.1.
484 14 Aufklärung über Freund und Feind
Tabelle 14.1: Regionale Internetregistraturen
Name
Abkürzung
Region
Website
African Network Information Centre
AfriNIC
Afrika
http://www.afrinic.net/
American Registry for
Internet Numbers
ARIN
USA, Kanada, Teile der
Karibik, Antarktis
https://www.arin.net/
Asia-Pacific Network
Information Centre
APNIC
Asien, Australien, Neuseeland und benachbarte Länder
http://www.apnic.net/
Latin America and
Caribbean Network
Information Centre
LACNIC
Lateinamerika und
Teile der Karibik
http://www.lacnic.net/
Reseaux IP Europeens
Network Coordination
Centre
RIPE NCC
Europa, Russland, Naher Oster, Zentralasien
http://www.ripe.net/
Jede dieser Registraturen können Sie nach den Registrierungsdatensätzen für eine IP-Adresse fragen. Abb. 14.13 zeigt das Ergebnis einer solchen Abfrage in der ARIN-Datenbank
für eine IP-Adresse im Bereich 50.128.0.0/9 über http://whois.arin.net/ui/advanced.jsp.
Hier sehen Sie, dass dieser Block von IP-Adressen Comcast zugewiesen ist. Über die
Links in dem Abfrageergebnis erhalten Sie Informationen zur Kontaktaufnahme mit
Ansprechpartnern (Points of Contact, POC) in dieser Organisation zu technischen und
Verwaltungsfragen sowie für Missbrauchsmeldungen. Das ist praktisch, wenn sich ein
gegnerisches Gerät, von dem aus ein Einbruch in Ihr Netzwerk versucht wird, in einem
IP-Adressraum befindet, der einem renommierten Unternehmen gehört. Oft ist das ein
Indiz dafür, dass der wahre Gegner dieses Gerät geknackt hat und als Ausgangspunkt
für seine Angriffe nutzt. In solchen Fällen ist es üblich, den Ansprechpartner für Missbrauchsmeldungen in der Organisation darüber zu informieren, dass aus deren Adressbereich ein Angriff vorgetragen wird.
Bericht von der Front
Andere Organisationen darüber zu informieren, dass einer ihrer Hosts möglicherweise übernommen wurde, kann manchmal schwierig sein. Es kann dabei
durchaus vorkommen, dass die betreffende Organisationen Ihnen nicht glaubt
und Sie in Extremfällen sogar beschuldigt, schädliche Maßnahmen gegen sie zu
betreiben. Angesichts dieser Gratwanderung müssen Sie die notwendige Etikette
walten lassen, wenn Sie jemandem mitteilen, dass sein Netzwerk angegriffen wurde. Einige wertvolle Erfahrungen damit beschreibt Tom Liston in einem Artikel für
SANS Internet Storm Center auf http://www.dshield.org/diary.html?storyid=9325.
14.3 Aufklärung über Bedrohungen 485
Abbildung 14.13: Ergebnis einer Abfrage an die Internetregistratur ARIN
In sehr vielen Fällen ist die IP-Adresse, nach der Sie suchen, bei einem Provider registriert.
Wenn Sie Glück haben, kann es sinnvoll sein, den Provider darüber zu informieren, dass
jemand von seinem IP-Adressraum aus einen Angriff auf Ihr Netzwerk versucht, aber
meiner Erfahrung nach ist das gewöhnlich nicht sehr fruchtbar. Dies gilt insbesondere
dann, wenn Sie es mit einem Provider außerhalb Ihrer Gerichtsbarkeit zu tun haben.
Da IP-Adressen auf die fünf regionalen RIRs verteilt sind, werden Sie oft erst erfahren,
welche RIR für eine gegebene Adresse zuständig ist, wenn Sie danach suchen. Wenn Sie auf
der Website der falschen RIR nach der Adresse suchen, werden Sie zum Glück auf die richtige RIR verwiesen, sodass Sie Ihre Nachforschungen dort fortsetzen können. Eine andere
Möglichkeit besteht darin, einen Dienst wie Robtex zu nutzen, der sich darum kümmert
(und den wir uns in Kürze genauer ansehen werden).
Eine weitere brauchbare Information, die Sie aus dem Registrierungseintrag gewinnen
können, ist die ASN (Autonomous System Number), die mit der IP-Adresse verknüpft
ist. Diese Zahl bezeichnet ein einzelnes Netzwerk oder eine Gruppe von Netzwerken, die
von einer einzigen Körperschaft beherrscht werden. Gewöhnlich werden solche ASNs
Providern, Großunternehmen und Universitäten zugewiesen. Wenn zwei IP-Adressen
unterschiedlichen Eigentümern zugeordnet sind, aber dieselbe ASN aufweisen, können
Sie daraus schließen, dass es irgendeine Verbindung zwischen ihnen gibt. Das allerdings
müssen Sie von Fall zu Fall untersuchen. In jeder Registratur können Sie auch gezielt nach
ASNs suchen.
486 14 Aufklärung über Freund und Feind
Bei Domänennamen beginnt die Recherche ebenso wie bei IP-Adressen gewöhnlich damit, den registrierten Besitzer zu finden. Es ist jedoch wichtig, zwischen dem physischen
Host und dem Domänennamen zu unterscheiden. Der IP-Adressraum ist endlich und unterliegt gewissen Einschränkungen. Wenn in Ihren Protokollen eine IP-Adresse erwähnt
wird, können Sie davon ausgehen, dass die Daten, die Sie im Zusammenhang mit dem
betreffenden Host erfasst haben, tatsächlich von dieser IP-Adresse stammen (zumindest
bei der sitzungsorientierten Kommunikation). Sie können auch mit ausreichender Wahrscheinlichkeit annehmen, dass die IP-Adresse dem Besitzer gehört, für den sie registriert
ist, wobei es natürlich möglich ist, dass der Computer von Dritten übernommen wurde.
Ein Domänenname dagegen ist nur ein Zeiger auf einen Speicherort. Wenn einer Ihrer
Hosts in irgendeiner Weise auf eine Domäne zugegriffen hat, dann wird der zugehörige
Domänenname zwar in Ihren Protokollen aufgeführt, kann aber auf beliebige und im
Laufe der Zeit sogar auf unterschiedliche Adressen verweisen. Der Domänenname aus
den Protokollen von gestern kann daher schon auf eine ganz andere Adresse zeigen. Es ist
ein übliches Vorgehen von Angreifern, Hosts zu knacken und dann den IP-Adressen dieser Hosts Domänennamen zuzuweisen, die Malware bereitstellen oder andere Schadfunktionen ausüben. Wenn der Besitzer des Hosts das bemerkt und den Angreifer aussperrt,
weist dieser den Domänennamen einfach der IP-Adresse eines anderen Computers zu,
über den er Einfluss hat. Es gibt sogar schon Malware, die Algorithmen zum Generieren
von Domänennamen einsetzt, um zufällig ausgewählte Domänennamen zu registrieren
und für Steuerfunktionen zu nutzen. Es ist nicht die Domäne, die von Angreifern übernommen wird, sondern die IP-Adresse. Ein Domänenname kann jedoch für schädliche
Zwecke verwendet werden. Das ist etwas, was Sie bei der Recherche von möglicherweise
schädlichen Domänen im Hinterkopf behalten müssen.
Zuständig für die Domänennamenregistrierung ist die ICANN, die diese Verantwortung
wiederum an Domänennamenregistraturen delegiert. Wenn jemand einen Domänennamen registriert, muss er Kontaktinformationen dafür angeben. Leider findet dabei so gut
wie keine Überprüfung statt, sodass die Registrierungsinformationen für eine Domäne
nicht unbedingt der Wahrheit entsprechen müssen. Viele Registraturen bieten auch einen
anonymen Dienst an, bei dem der tatsächliche Besitzer der Domäne verschleiert und stattdessen die Registratur angegeben wird. Trotzdem lassen sich in vielen Fällen auch aus der
Domänennamenregistrierung wertvolle Informationen gewinnen.
Angaben zu Domänen können Sie auf viele verschiedene Weisen abfragen. Eine Möglichkeit besteht darin, eine whois-Abfrage auf der Website einer Registratur wie GoDaddy
oder Network Solutions durchzuführen. Mit der folgenden einfachen Syntax können Sie
den Befehl whois auch an einer Unix-Befehlszeile ausführen (siehe Abb. 14.14):
whois<Domänenname>
14.3 Aufklärung über Bedrohungen 487
Abbildung 14.14: Ergebnisse einer whois-Abfrage nach ESPN.com
Wie Sie sehen, erhalten wir dadurch Informationen über das Unternehmen, für das die
Domäne registriert wurde (registrant) sowie einige weitere wertvolle Informationen. Das
Registrierungsdatum kann einen Hinweis auf die Echtheit der Domäne liefern. Wenn Sie
den Verdacht haben, dass eine Domäne, mit der Ihre Hosts kommunizieren, schädliche
Inhalte bereitstellt, und Sie dann feststellen, dass diese Domäne erst wenige Tage zuvor
registriert wurde, ist das ein weiteres Indiz dafür, dass hier tatsächlich etwas Ungutes vor
sich geht.
In der Ausgabe in Abb. 14.14 werden Ihnen auch die mit der Domäne verknüpften DNSServer genannt. Damit können Sie Verbindungen zwischen mehreren verdächtigen Domänen aufdecken. Mit etwas DNS-Zauberei und Techniken wie Zonenübertragungen
können Sie auch versuchen, sich Unterdomänen und DNS-Hostnamen anzeigen zu lassen, aber da Sie dabei in Interaktion mit potenziellen DNS-Servern treten müssen, ist
das in den meisten Fällen nicht zu empfehlen. Wenn Sie mehr darüber erfahren wollen,
können Sie sich jedoch in den vielen Anleitungen informieren, die es dazu im Internet
gibt. Auf http://www.securitytube.net finden Sie auch Videos dazu.
488 14 Aufklärung über Freund und Feind
Bei der Suche nach Informationen über IP-Adressen und Domänennamen klappere ich
gewöhnlich nicht all die verschiedenen einzeln Websites ab, sondern nutze öffentlich verfügbare Dienste, bei denen ich alle Angaben auf einmal erhalte. Zu meinen Favoriten dabei gehört Robtex (http://www.robtex.com), wo Sie in einer sehr praktischen Oberfläche
eine Menge wertvoller Informationen finden, darunter alles, was wir bis jetzt besprochen
haben. Als Beispiel sehen Sie in Abb. 14.15 die Ergebnisse auf der Registerkarte Records
von Robtex für meine Suche nach espn.com.
Abbildung 14.15: Die Registerkarte Records von Robtex
Wie Sie hier sehen, gibt Robtex alle gewonnenen DNS-Informationen, die zugehörigen
IP-Adressen und die damit verknüpften ASNs aus. Damit können Sie rasch ein Gesamtbild zeichnen, das für die Arbeit von Analytikern sehr gut geeignet ist.
Vorsicht
In diesem Kapitel werden viele Webdienste erwähnt, die öffentlich zugängliche
Informationen bereitstellen. Diese Websites können zwar sehr nützlich sein, aber
Sie müssen sich immer klarmachen, wie sie mit den Informationen umgehen, die
Sie ihnen geben, um nach verdächtigen IP-Adressen oder Domänen zu suchen.
Einige dieser Dienste kommunizieren mit diesen Adressen oder Domänen, und
die Weitergabe Ihrer IP-Adresse an einen möglicherweise schädlichen Host ist
natürlich das Letzte, was Sie wollen. Ich habe schon genug Fälle erlebt, in denen
ein Webdienst die IP-Adresse des anfordernden Clients im HTTP-Header weitergeleitet hat. Ob das der Fall ist, können Sie prüfen, indem Sie mit diesen Tools
eine Recherche über Ihr eigenes Netzwerk durchführen und dann die Daten über
die Kommunikation mit dem Webdienst untersuchen.
14.3 Aufklärung über Bedrohungen 489
Reputation von IP-Adressen und Domänen
In Kapitel 8 haben wir uns schon ausführlich mit der Reputation von IP-Adressen und
Domänen beschäftigt. Die Reputation ist nicht nur für eine nützliche Information für
die Erkennung, sondern auch für die Analyse. Wenn eine IP-Adresse oder Domäne schon
früher im Zusammenhang mit schädlichen Aktivitäten stand, dann ist es wahrscheinlich,
dass sie auch heute noch damit in Verbindung steht.
Meine bevorzugten Quellen für Reputationsinformationen zu Erkennungszwecken habe
ich bereits in Kapitel 8 genannt. Diese Websites sind zwar für die Erkennung optimiert, da
sie Listen generieren, die sich in Erkennungsmechanismen einspeisen lassen, können aber
auch für die Analyse von IP-Adressen und Domänennamen verwendet werden. Ich werde
sie hier aber nicht noch einmal aufführen. Stattdessen stelle ich zwei meiner bevorzugten
Reputationswebsites vor, die besser für die Analyse nach der Erkennungsphase geeignet sind,
nämlich IPVoid (http://www.ipvoid.com/) und URLVoid (http://www.urlvoid.com/).
Beide Websites wurden als kostenlose Dienste von dem Unternehmen NoVirusThanks
entwickelt. Sie greifen auf mehrere andere Reputationslisten zurück (darunter einige
derjenigen, die in diesem Buch erwähnt wurden) und zeigen an, ob die eingegebene IPAdresse bzw. Domäne auf einer dieser Listen zu finden ist. In den Abbildungen 14.16 und
14.17 finden Sie Beispielausgaben beider Dienste.
Abbildung 14.16: Beispielausgabe von URLVoid
490 14 Aufklärung über Freund und Feind
Abbildung 14.17: Beispielausgabe von IPVoid
Beide Dienste geben grundlegende Informationen über die IP-Adresse bzw. Domäne und
eine Statistik über die Anzahl der schwarzen Listen aus, auf denen sie gefunden wurde.
In Abb. 14.16 können Sie erkennen, das die Domäne auf drei von 28 Blacklists (11 %)
gefunden wurde, die URLVoid durchsucht hat. Diese drei Listen werden an der Spitze des
Ergebnisses aufgeführt, wobei Sie über den Link in der Spalte Info direkt zu dem Eintrag
für den betreffenden Domänennamen auf der zugehörigen Website gelangen. In Abb. 14.17
wurden die Informationen von IPVoid über die angefragte IP-Adresse aus Platzgründen
gekürzt, aber Sie können trotzdem noch mehrere der verwenden IP-Blacklistdienste sehen.
IPVoid und URLVoid sind hervorragende zentrale Anlaufstellen, um zu bestimmen, ob
eine bestimmte IP-Adresse oder Domäne auf irgendeiner schwarzen Liste geführt wird.
Wenn ja, ist das zwar immer noch kein sicherer Beweis für schädliche Aktivitäten, aber in
den meisten Fällen ein wertvolles Indiz.
Denken Sie bei der Analyse immer daran, dass mehrere Domänen eine einzige IP-Adresse
nutzen können. Wenn eine Domäne auf mehreren schwarzen Listen auftaucht, heißt das
nicht zwangsläufig, dass auch jede andere Domäne, deren Inhalt über dieselbe IP-Adresse
bereitgestellt wird, ebenfalls schädlich ist. Das gilt insbesondere für gemeinsam genutzte
Hostingserver. Wenn eine Website auf einem solchen Server unter falschen Einfluss gerät,
14.3 Aufklärung über Bedrohungen 491
liegt das gewöhnlich an einem Mangel in der Webanwendung. Meistens ist dieser Einbruch nur auf die betroffene Domäne beschränkt. Es kann natürlich auch Ausnahmen
von dieser Regel geben, aber Sie sollten sie bei der Untersuchung der Reputation von IPAdressen und Domänennamen trotzdem im Hinterkopf behalten.
Eine Möglichkeit, die über eine IP-Adresse bereitgestellten Domänen schnell zu ermitteln,
ohne selbst mit fremden DNS-Servern arbeiten zu müssen, bietet der Dienst Domains by
IP (http://www.domainsbyip.com/). Die Ausgabe dieses Dienstes sehen Sie in Abb. 14.18.
Abbildung 14.18: Ergebnisse einer Abfrage auf Domains by IP
In diesem Beispiel können Sie erkennen, dass über diese IP-Adresse vier verschiedene Domänen vorgehalten werden, zwischen denen es keine offenkundige Verbindung gibt. Das
sieht ganz nach einem gemeinsam genutzten Hostingserver aus. Wie Sie sehen, führt der
Dienst auch »nahegelegene« IP-Adressen auf (Nearby IP addresses), die numerisch nicht
so weit entfernt von der angefragten IP-Adresse liegen und ebenfalls Domänen bereitstellen. Dieser Dienst ist sehr nützlich, aber nicht allumfassend, weshalb Sie damit je nachdem, was Sie erreichen wollen, unterschiedlich weit kommen.
Nach diesen öffentlichen Informationsquellen über Hosts sehen wir uns im Folgenden
einige öffentliche Informationsquellen über Dateien an.
492 14 Aufklärung über Freund und Feind
14.3.2 Recherche über schädliche Dateien
Die Elemente, die Ihnen bei der NSM-Analyse neben IP-Adressen und Hostnamen am
häufigsten begegnen werden, sind Dateien. Manchmal haben Sie dabei nur einen Dateinamen, manchmal auch einen MD5-Hash, und im besten Fall können Sie sogar auf die
komplette Datei zugreifen. Verdächtig sind Dateien gewöhnlich dann, wenn sie von einem
verdächtigen Host heruntergeladen werden oder in Zusammenhang mit einem Alarm
stehen, den ein Erkennungsmechanismus ausgelöst hat. Informationen über Dateien zu
gewinnen ist ein wichtiger Bestandteil der taktischen Aufklärung über eine Bedrohung.
Bericht von der Front
Es gibt verschiedene Möglichkeiten, verdächtige Dateien an einer Verbindung
abzugreifen. Mit Bro können Sie bestimmte Dateitypen in Echtzeit abrufen, wie
wir bereits in Kapitel 10 besprochen haben. Bei der Untersuchung von FPCDaten können Sie Dateien mit Werkzeugen wie Wireshark aus dem Kommunikationsstream extrahieren. Diese Vorgehensweise wurde in Kapitel 13 erklärt.
Aufklärung anhand von öffentlich verfügbaren Quellen
Ebenso wie bei der Aufklärung über Hosts finden Sie auch für Recherchen über verdächtige Dateien verschiedene brauchbare Quellen im Internet. Im Folgenden wollen wir uns
einige davon ansehen.
Wenn Ihnen die verdächtige Datei tatsächlich vorliegt, ist es am einfachsten, eine Verhaltensanalyse dafür durchzuführen. Das können Sie auch mit internen Ressourcen erledigen, doch
wenn Ihnen die notwendigen Einrichtungen dafür fehlen, ist es besser, die Datei bei einer
Online-Malwaresandbox einzureichen, die eine automatische Verhaltensanalyse durchführt,
indem sie beobachtet, welche Änderungen die Malware an dem System vornimmt und welche Maßnahmen sie zu ergreifen versucht. Sehen wir uns einige dieser Sandboxes an.
14.3 Aufklärung über Bedrohungen 493
Vorsicht
Sehr viele öffentliche Malwaresandboxes indizieren die eingereichte Malware, sodass andere Personen danach suchen können. Dadurch muss die Sandbox eine
Datei, die schon einmal eingereicht wurde, nicht ein zweites Mal analysieren. Das
hilft den Betreibern der Website zwar, Ressourcen zu sparen, kann aber ein Risiko
darstellen. Wenn normale Benutzer in einer öffentlichen Sandbox nach Malware
suchen können, so ist das auch Personen und Gruppen möglich, die Malware
erstellen. Wenn ein Gegner mit einer Malware, die eigens auf Ihre Organisation
zugeschnitten ist, einen gezielten Angriff führt, kann er anschließend regelmäßig
die öffentlichen Sandboxes auf den Dateinamen oder MD5-Hash dieser Malware
untersuchen. Stößt er dabei auf die Malware, dann weiß er, dass Sie sie gefunden
haben und dass er seine Taktik ändern oder neue, weniger leicht zu erkennende
Malware schreiben muss. Das müssen Sie bedenken, bevor Sie Malware bei einer
öffentlichen Website einreichen, insbesondere wenn Sie in einer Hochsicherheitsumgebung arbeiten, auf die gezielte Angriffe durchgeführt werden.
VirusTotal
Die einfachste Möglichkeit, zu bestimmen, ob eine Datei schädlich ist, besteht darin, sie
von einem Antivirusprogramm überprüfen zu lassen. Leider ist die Erkennungsrate solcher Software sehr gering. Die Chance, dass ein einziges Antivirusprodukt eine Malware
erkennt, liegen bei 50:50. Sie können das Verhältnis verbessern, indem Sie eine verdächtige
Datei von mehreren Antivirus-Engines überprüfen lassen. Es ist jedoch technisch meistens nicht möglich, mehrere AV-Engines auf einem einzigen System einzurichten, und die
Lizenzierung dafür wäre auch nicht billig.
Es gibt jedoch den Onlinedienst VirusTotal (http://www.virustotal.com), einen kostenlosen Dienst, den Google 2012 gestartet hat und der verdächtige Dateien und URLs mithilfe
mehrerer Antivirus-Engines untersucht. Es gibt verschiedene Möglichkeiten, Dateien bei
VirusTotal einzureichen: über die entsprechende Website, per E-Mail oder mithilfe von
Tools, die die API von VirusTotal verwenden. Ich bevorzuge die entsprechende GoogleChrome-Erweiterung. Nachdem Sie eine Datei eingereicht haben, führt VirusTotal die
Analyse durch und gibt einen Bericht aus, der angibt, welche Antivirus-Engines eine
Übereinstimmung mit der Datei oder ihrem Inhalt gefunden haben und welche Strings
übereinstimmen.
Ein Beispiel dieser Ausgabe sehen Sie in Abb. 14.19. Zurzeit nutzt VirusTotal 49 verschiedene Antivirus-Engines, einschließlich derjenigen der größten und bekanntesten Hersteller auf diesem Gebiet.
494 14 Aufklärung über Freund und Feind
Abbildung 14.19: Beispiel für einen Bericht von VirusTotal
Dieser Beispielbericht besagt, dass sieben von 48 Antivirus-Engines die eingereichte
Datei als Malware erkannt haben. Zwei dieser sieben sind in dem Ausschnitt zu sehen,
nämlich antiy-AVL und Baidu-International. Beide sehen diese Datei als eine Art von
VNC-­Anwendung an, die zur Fernsteuerung eines Systems verwendet werden kann. Das
Zeigerinstrument oben rechts auf dem Bildschirm gibt aufgrund der Anzahl der Befunde
und einiger anderer Faktoren eine Einschätzung ab, ob es sich um eine schädliche Datei
handelt. In diesem Fall geht VirusTotal davon aus, dass sie wahrscheinlich schädlich ist.
VirusTotal stellt die eingereichten Proben nicht öffentlich zur Verfügung, leitet diejenigen,
die von mindestens einer Antivirus-Engine als Malware erkannt wurden, aber an die Hersteller von Antivirussoftware weiter. Denken Sie daran, wenn Sie Dateien einreichen, die
sehr sensibel sind oder in maßgeschneiderten Angriffen verwendet wurden.
Cuckoo und Malwr.com
Eine der beliebtesten Sandboxumgebungen zur Malwareanalyse ist Cuckoo (http://www.
cuckoosandbox.org). Sie führt Malware in einer neuen Instanz einer virtuellen Maschine
aus und nimmt dabei eine Reihe von Analyseaufgaben vor. Unter anderem zeichnet sie
die Änderungen und sonstigen Aktionen der Malware auf, z. B. alle Änderungen am System, alle Aufrufe von Windows-APIs und alle Dateien, die erstellt oder gelöscht werden.
Darüber hinaus kann Cuckoo auch ein komplettes Speicherabbild des Systems oder eines
14.3 Aufklärung über Bedrohungen 495
ausgewählten Prozesses erstellen und Screenshots der virtuellen Maschine während der
Ausführung der Malware anfertigen. All dies geht in den endgültigen Bericht von Cuckoo
ein. Das System von Cuckoo ist modular aufgebaut, sodass die Benutzer gezielt festlegen
können, was es bei der Ausführung der Malware und bei der Berichterstattung tun soll.
Sie können die Cuckoo-Sandbox herunterladen und intern bereitstellen. Ich habe sie
schon in vielen Umgebungen erfolgreich im Einsatz erlebt. In diesem Abschnitt geht es
jedoch um Online-Sandboxes zur Malwareanalyse. Die Website http://www.malwr.com
nutzt Cuckoo für einen kostenlosen Online-Analysedienst. Sie wird von Sicherheitsexperten auf freiwilliger Basis als nicht kommerzielle Dienstleistung angeboten. Die von Ihnen
eingereichten Dateien werden weder öffentlich noch privat weitergeben, es sei denn, dass
Sie ausdrücklich Ihre Erlaubnis dazu erteilen.
Die Abbildungen 14.20 und 14.21 zeigen Ausschnitte aus einem Cuckoo-Bericht von
Malwr.
Im ersten Bild gibt Cuckoo Informationen über Signaturen, mit denen die eingereichte
Datei übereinstimmt, was für Sie ein Hinweis ist, die entsprechenden Abschnitte des Berichts genauer zu untersuchen. Außerdem werden Screenshots der virtuellen Maschine
gezeigt, in der die Malware ausgeführt wurde. In Abb. 14.21 sehen Sie die Ergebnisse der
Verhaltensanalyse durch Cuckoo. Hier werden einige der Aktionen angegeben, die die
Datei mypcbackup0529.exe vorgenommen hat.
Malwr veröffentlicht freigegebene Analyseberichte auf seiner Homepage. Diese Berichte
geben Ihnen eine Vorstellung davon, was Cuckoo wirklich leisten kann. Sie können die Berichte auch nach dem MD5-Hash einer Malwareprobe durchsuchen, um herauszufinden,
ob es für die Datei bereits einen Bericht gibt. Dadurch kommen Sie schneller zu einem
Ergebnis und müssen nicht erst auf den Abschluss der Analyse warten.
Abbildung 14.20: Cuckoo-Bericht mit gefundenen Signaturen und Screenshots
496 14 Aufklärung über Freund und Feind
Abbildung 14.21: Cuckoo-Bericht mit den Ergebnissen der Verhaltensanalyse
Sofern die Möglichkeiten dazu bestehen, ist der Aufbau einer internen Cuckoo-Sandbox
in Sicherheits- und NSM-Umgebungen ein lohnendes Unterfangen. Die Einrichtung ist
ziemlich langwierig und kompliziert, doch dadurch erhalten Sie eine viel größere Vielseitigkeit, als Onlinedienste bieten. Unter anderem können Sie die Analyseroutinen und die
Berichterstattung Ihrem Bedarf anpassen. Cuckoo ist eine voll ausgestattete Sandbox zur
Malwareanalyse, die sich für viele tägliche Analyseaufgaben als nützlich erweist.
14.3 Aufklärung über Bedrohungen 497
ThreatExpert
ThreatExpert ist eine weitere Online-Sandbox und bietet ähnliche Funktionen wie
­Cuckoo und Malwr. Auf der zugehörigen Website (http://www.threatexpert.com) können
Sie verdächtige Dateien einreichen, die dann in einer Sandbox ausgeführt werden, um
eine eingeschränkte Verhaltensanalyse durchzuführen. Das Endergebnis ist ein Bericht,
der angibt, welche Aktionen die Datei im Dateisystem, in der Systemregistrierung und an
anderen Orten vorgenommen hat. Die Abbildungen 14.22 und 14.23 zeigen Auszüge aus
einem ThreatExport-Bericht.
Abbildung 14.22: Zusammenfassung eines ThreatExport-Berichts
498 14 Aufklärung über Freund und Feind
Abbildung 14.23: Detaillierte Darstellung der Aktionen in einem ThreatExpert-Bericht
In dem ersten Bild können Sie erkennen, dass die eingereichte Datei offensichtlich mit
UPX gepackt wurde und dass ThreatExpert einige ihrer Merkmale als Sicherheitsrisiken
einstuft, nämlich das Erstellen eines Starteintrags in der Registrierung und die Kommunikation mit einem externen IRC-Server. Der Ausschnitt in dem zweiten Bild gibt technische Einzelheiten zu diesen Befunden an, darunter Änderungen am Arbeitsspeicher und
der Registrierung, das Erstellen eines Mutex und das Öffnen eines Ports.
ThreatExpert verfügt auch über eine umfassende Suchfunktion. Sie können über den
MD5- oder SHA1-Hash nach bereits analysierten Dateien suchen, sodass eine bereits früher eingereichte Datei nicht erneut analysiert werden muss. Die wertvollste Funktion ist
jedoch die Möglichkeit, in den Berichten nach beliebigem Text, nach Dateinamen, IPAdressen oder Domänennamen zu suchen, die Sie in Ihrem Netzwerk gefunden haben,
um zu sehen, ob Sie in irgendeinem der Malwareanalyseberichte von ThreatExpert vorkommen. Bei vielen Untersuchungen, an denen ich beteiligt war, waren die ThreatExpertMalwareberichte die einzige Informationsquelle über eine gesuchte Adresse, und sehr oft
reichten die Angaben in diesen Berichten aus, mich auf die richtige Spur zu bringen und
entscheiden zu können, ob tatsächlich ein Zwischenfall vorlag oder nicht.
14.3 Aufklärung über Bedrohungen 499
ThreatBox ist zwar eine gut funktioniere Sandbox, allerdings geht sie nicht so sehr ins
Detail wie Cuckoo und kann auch nicht heruntergeladen und lokal installiert werden.
In vielen Fällen erfüllt sie aber ihren Zweck, und ihre Suchfunktionen machen sie für die
NSM-Analyse äußerst wertvoll.
Malware Hash Registry von Team Cymru
Eine Datei lässt sich am schnellsten anhand ihres kryptografischen Hashwerts identifizieren, wobei gewöhnlich ein MD5-, manchmal aber auch ein SHA1-Hash verwendet wird.
Der große Vorteil besteht darin, dass Sie anhand dieses Hashwerts eine Datei unabhängig
von ihrem Namen erkennen können. Wie wir in den vorigen Beispielen gesehen haben,
verwenden sowohl Malwr als auch ThreatExpert solche Hashes. Das Team Cymru nun hat
eine Liste der Hashwerte bekannter Malware aufgestellt.
Dieses Malware Hash Registry (http://www.team-cymru.org/Services/MHR/) ist eine Datenbank, die bekannte Malwarehashes aus verschiedenen Quellen enthält. Diese Datenbank lässt sich auf verschiedene Weisen abfragen und bietet eine schnelle und einfache
Möglichkeit, zu ermitteln, ob eine Datei, die Sie bei der Erkennung oder Analyse gefunden
haben, schädlich ist.
Die einfachste Methode zur Abfrage dieses Registers bietet der Befehl whois. Das mag eigenartig erscheinen, funktioniert aber sehr gut. Dazu müssen Sie den Befehl im folgenden
Format geben:
whois -h hash.cymru.com<Hash>
Abb. 14.24 zeigt das Ergebnis zweier Abfragen dieser Art.
Abbildung 14.24: Abfragen der Malware Hash Registry von Team Cymru
Die beiden Abfragen in diesem Beispiel geben jeweils drei Spalten zurück. Die erste enthält
den Hashwert, die zweite den Zeitstempel (im Epochenformat, das Sie mit dem Befehl
date -d in die lokale Uhrzeit umrechnen lassen können) des Zeitpunkts, an dem der Hash
das letzte Mal beobachtet wurde. In der dritten Spalte ist der prozentuale Anteil der Antivirus-Engines angegeben, die die Datei als schädlich einstufen. Im ersten Fall sind es 79 %,
im zweiten dagegen steht in diesem Feld NO_DATA, was bedeutet, dass es in dem Register
keine Einträge für den Hashwert gibt. Datensätze für Hashwerte mit einer Erkennungsrate
unter 5 % werden vom Malware Hash Registry nicht aufbewahrt.
500 14 Aufklärung über Freund und Feind
Dieses Register kann sich für die Analyse einzelner verdächtiger Dateien als sehr nützlich erweisen. Da es so viele verschiedene Möglichkeiten gibt, die Datenbank abzufragen,
eignet sie sich darüber hinaus auch sehr gut zur automatischen Analyse. So kann Bro
beispielsweise seine Extraktionsfunktionen (siehe Kap. 10) mit seinem Intel-Framework
kombinieren (siehe Kapitel 8), um Dateien selektiv zu extrahieren und ihre Hashes automatisch mit denen im Hashregister zu vergleichen. Das ist nicht nur für die Erkennung
äußerst praktisch, sondern kann auch die Arbeit bei der Analyse eines Ereignisses erleichtern.
Auf der zuvor genannten Website erfahren Sie mehr über das Hashregister und die zahlreichen Möglichkeiten, es abzufragen.
Die hier besprochenen Informationen aus der Aufklärung über IP-Adressen und Domänennamen und die Beobachtungen aus Ihren Netzwerkdaten liefern Ihnen zusammen
genommen wichtige taktische Erkenntnisse.
14.4 Zusammenfassung
Um eine Untersuchung erfolgreich durchführen zu können, müssen Sie Ihr Netzwerk und
Ihren Gegner kennen. Die Fähigkeit, Informationen über eigene Elemente zu gewinnen
und Recherchen über mögliche schädliche Elemente anzustellen, ist für die erfolgreiche
Analyse von Zwischenfällen unverzichtbar. In diesem Kapitel haben wir uns Vorgehensweise für beides angesehen. Es gibt verschiedene Ansätze zur Aufklärung. Wichtig ist jedoch,
dass Sie dabei Ergebnisse anstreben, die Analytikern helfen, Entscheidungen zu treffen,
die eine Untersuchung vorantreiben. Im nächsten Kapitel beschäftigen wir uns mit dem
Analyse­vorgang, der sich auf die Informationen aus der Erfassung und Erkennung stützt.
15
Der Analysevorgang
Der wichtigste Part des NSM ist die Analyse. Dabei nutzen die Analytiker die Ausgabe der
Erkennungsmechanismen und verschiedene Datenquellen, um Informationen zu sammeln und dadurch zu bestimmen, ob tatsächlich etwas vorgefallen ist, das sich schädlich
auf das Netzwerk oder die darin gespeicherten Informationen auswirkt.
Bei Besuchen bei Sicherheitsorganisationen und bei Gesprächen mit Analytikern habe ich
fast immer festgestellt, dass der Analysevorgang ad hoc durchgeführt wird und aus einer
subjektiv festgelegten Abfolge nur locker definierter Schritte besteht, die jeder Einzelne für
sich selbst aufstellt. Natürlich haben wir alle unseren eigenen Stil, und jeder geht anders an
die Untersuchung von Informationen heran, weshalb das bis zu einem gewissen Grad zu
erwarten ist. Allerdings kann es sich als wertvoll erweisen, einen formalen, systematischen
Analyseprozess zu verwenden, nach dem sich alle Analytiker bei ihrer Arbeit richten.
Die Nutzung eines solchen Prozesses beschleunigt die Entscheidungsfindung, macht die
Teamarbeit effizienter und sorgt für eine klarere Berichterstattung über Zwischenfälle. Vor
allem aber hilft sie den Analytikern, schneller mit einer Untersuchung fertig zu werden.
In diesem Kapitel sehen wir uns zwei verschiedene Vorgehensweisen an, die als Grundgerüst für die NSM-Analyse dienen können. Die erste ist einem System entlehnt, das
bei polizeilichen Ermittlungen eingesetzt wird, die zweite dagegen stammt von einem
Prozess, den Ärzte für medizinische Untersuchungen verwenden. Zum Zeitpunkt der
Abfassung dieses Buches habe ich noch keine schriftlich ausgearbeitete Struktur für die
502 15 Der Analysevorgang
NSM-Analyse gesehen. Daher soll Ihnen dieses Kapitel die nötigen Kenntnisse vermitteln, um eine dieser beiden Analysemethoden bei der täglichen Arbeit einzusetzen und
Ihre Fähigkeiten zur Analyse zu verbessern, damit Sie bei Ihren Untersuchungen nicht
nur zu besseren Ergebnissen kommen, sondern diese auch schneller erreichen.
Nach der Erörterung der Analysemethoden werde ich noch einige empfehlenswerte Vorgehensweisen vorstellen, die ich aus meiner eigenen Erfahrung als NSM-Analytiker und
von meinen Kollegen gelernt habe. Am Ende besprechen wir noch den Prozess, um die
»Morbidität und Mortalität« eines Zwischenfalls zu bestimmen. Dieser Vorgang dient
dazu, die Erfassung, Erkennung und Analyse nach dem Abschluss einer Untersuchung zu
verbessern.
15.1 Analysemethoden
In jedem Analyseprozess sind drei Dinge erforderlich: eine Eingabe, eine Untersuchung und
eine Ausgabe. Die Art und Weise, wie diese Schritte erledigt werden und gegliedert sind,
definiert eine Analysemethode, wobei es sich schlicht um eine systematische Vorgehensweise handelt, um zu ermitteln, ob ein Zwischenfall stattgefunden hat. In unserem Fall ist
die Eingabe gewöhnlich irgendeine Form von IDS-Alarm oder eine andere Anomalie, die
die Aufmerksamkeit eines Analytikers erregt hat, und die Ausgabe die Entscheidung, ob ein
Zwischenfall vorliegt. Es sind die Schritte, die dazwischen in der Untersuchungsphase unternommen werden, mit denen wir uns im Folgenden beschäftigen.
15.1.1
Relationale Untersuchung
Die Prozesse zur Untersuchung einer Verletzung der Informationssicherheit ähneln sehr
stark denen einer polizeilichen Ermittlung. Die Vorgehensweise, mit der Kriminalbeamte
einem Verbrechen auf den Grund geben, können wir sogar als Grundgerüst für eine Analysemethode verwenden. Dies ist die sogenannte »relationale Untersuchung«.
Diese Methode beruht darauf, lineare Beziehungen zwischen Objekten aufzustellen. Wenn
Sie jemals eine Folge von CSI oder NYPD Blue gesehen haben, wo die Ermittler Papierblätter an eine Pinnwand heften und dann versuchen, diese Elemente mit Garn zu verbinden,
dann haben Sie bereits ein Beispiel für eine relationale Untersuchung in Aktion erlebt.
Diese Art der Ermittlung stützt sich auf die Beziehungen zwischen den Anhaltspunkten
und den in den Fall verwickelten Personen. Ein Computernetzwerk ähnelt in gewisser
Hinsicht einer Gruppe von zusammengehörigen Menschen. Alles ist miteinander verbunden, und jede Aktion kann eine andere Aktion verursachen. Wenn wir als Analytiker die
Beziehungen zwischen verschiedenen Objekten gut genug erkennen, können wir daraus
ein Netz spannen, das uns hilft, uns ein Gesamtbild von dem zu machen, was bei dem
möglichen Zwischenfall vor sich geht.
Der Prozess der relationalen Untersuchung besteht aus vier Schritten (siehe Abb. 15.1).
15.1 Analysemethoden 503
Schri 1
Schri 2
Schri 3
Schri 4
(wiederholt)
Untersuchung
der Hauptbeteiligten
Untersuchung der
Beziehungen
zwischen
den Hauptbeteiligten
Untersuchung der
sekundären Beteiligten
Untersuchung
der Beteiligten
weiterer Grade
Vorläufige Bewertung
der Meldung
Untersuchung der
aktuellen Interakon
Unersuchung der
Beziehungen zwischen
primären und
sekundären Beteiligten
Untersuchung
der Beziehungen
zwischen Beteiligten
weiterer Grade
Abbildung 15.1: Die Analysemethode der relationalen Untersuchung
Schritt 1: Untersuchung der Hauptbeteiligten und vorläufige Bewertung
der Meldung
Die Untersuchung eines Verbrechens beginnt oft damit, dass die Polizeiwache eine Meldung über die Tat ausgibt. Die zuständigen Beamten erhalten darin Informationen über
die Art des Vorfalls und die darin verwickelten Personen.
Beim Eintreffen am Tatort besteht die erste Maßnahme darin, die Identität der anwesenden Personen (Hauptbeteiligte) festzustellen und herauszufinden, ob die Meldung eine
weitergehende Untersuchung erfordert. Diese Entscheidung wird aufgrund der gesetzlichen Erfordernisse und der Einschätzung der Beamten getroffen, ob ein Gesetzesbruch
vorliegt. Wenn die Beamten davon ausgehen, dass tatsächlich eine Straftat vorgelegen
haben kann, beginnen sie damit, Informationen über die einzelnen Beteiligten einzuholen. Das kann die Überprüfung von deren Ausweispapieren, einen Einblick in ihr
Strafregister und eine Durchsuchung umfassen, um festzustellen, ob sie Waffen oder
illegale Gegenstände mit sich führen.
Bei einer NSM-Untersuchung werden die Analytiker gewöhnlich durch Alarmdaten über
ein Ereignis informiert, also beispielsweise durch den Alarm eines IDS. Dabei werden gewöhnlich die Art des Vorfalls und die darin verwickelten Hosts genannt. Der Alarm entspricht der Meldung von der Polizeiwache, und die Hosts sind die Hauptbeteiligten. Auch
die NSM-Analytiker müssen zunächst entscheiden, ob der Alarm eine weitere Untersuchung rechtfertigt. Dazu werden zunächst die Einzelheiten der Regel oder die Angaben
des Erkennungsmechanismus untersucht, der den Alarm ausgelöst hat, und bestimmt,
ob der Datenverkehr tatsächlich die Bedingungen für einen Alarm erfüllt. Damit sollen
Fehlalarme möglichst schnell als solche erkannt werden. Wenn der Vorfall nicht sofort als
Fehlalarm abgetan werden kann, besteht der nächste Schritt darin, Informationen über
504 15 Der Analysevorgang
die Hauptbeteiligten an dem Alarm einzuholen, nämlich über die IP-Adressen der eigenen
und der möglicherweise gegnerischen Hosts. Das bedeutet Aufklärung über die eigenen
Elemente und taktische Aufklärung über Bedrohungen, wie wir sie in Kapitel 14 besprochen haben.
Schritt 2: Untersuchung der Beziehungen zwischen den Hauptbeteiligten und ihrer aktuellen Interaktion
Nachdem die Hauptbeteiligten identifiziert sind, untersuchen die Beamten die Beziehungen zwischen ihnen, was sowohl die frühere Beziehung als auch die gegenwärtige
Interaktion umfasst. Betrachten Sie dazu als Beispiel einen Polizeieinsatz aufgrund häuslicher Gewalt. In einem solchen Fall versuchen die Beamten erstens herauszufinden, ob
die beiden Beteiligten eine Beziehung führen, wie lange diese Beziehung besteht, ob sie
zusammenleben usw., und zweitens, welche Handlungen zu dem Vorfall geführt haben,
wann die Situation eskaliert ist und was danach geschah.
Auch NSM-Analytiker untersuchen die primäre Beziehung zwischen dem eigenen und
dem möglicherweise feindlichen Host. Als Erstes sehen sie sich dazu die Art der vorherigen Kommunikation an, wobei sie unter anderem folgende Fragen stellen:
•• Haben die beiden Hosts jemals zuvor miteinander kommuniziert?
•• Wenn ja, welche Ports, Protokolle und Dienste waren daran beteiligt?
Als Nächstes untersuchen die Analytiker gründlich die Kommunikation im Zusammenhang mit dem Alarm. Dazu müssen sie Daten aus verschiedenen Quellen abrufen und auf
Verbindungen überprüfen. Das umfasst unter anderem folgende Tätigkeiten:
••
••
••
••
••
Erfassen von PCAP-Daten
Paketanalyse
Erfassen von PSTR-Daten
Extrahieren von Dateien und Malwareanalyse
Aufstellen von Statistiken aufgrund von Sitzungsdaten
In manchen Fällen können die Analytiker an dieser Stelle bestimmen, ob ein Zwischenfall
stattgefunden hat. Damit kann die Untersuchung hier enden. Wenn jedoch immer noch
keine Entscheidung getroffen werden kann oder die Natur des Zwischenfalls noch nicht
ganz klar es, geht es mit dem nächsten Schritt weiter.
Schritt 3: Untersuchung der sekundären Beteiligten und ihrer
Beziehungen
Bei der Untersuchung der Hauptbeteiligten und ihrer Beziehungen werden oft sekundäre
Beteiligte ermittelt – Personen, die in irgendeinem Zusammenhang mit dem Fall stehen,
etwa Zeugen oder Bekannte, Freunde und Angehörige der Hauptbeteiligten. Oft ist es für
15.1 Analysemethoden 505
eine Ermittlung hilfreich, auf diese Personen die gleichen Vorgehensweisen anzuwenden
wie in den ersten beiden Schritten, also Informationen über sie einzuholen und ihre Beziehungen zu den Hauptbeteiligten zu untersuchen.
Dies geschieht auch oft bei der NSM-Analyse. Beispielsweise kann es sich bei Untersuchung der Beziehung zwischen zwei Hosts zeigen, dass der eigene Host auf die gleiche
Weise auch mit anderen fremden Hosts kommuniziert oder der möglicherweise feindliche
Host mit anderen eigenen Hosts. Die Überprüfung möglicherweise schädlicher Dateien
kann auch die IP-Adressen anderer verdächtiger Kommunikationsquellen offenlegen. All
diese Hosts sind sekundäre Beteiligte, die auf die gleiche Weise untersucht werden müssen
wie die Hauptbeteiligten. Auch ihre Beziehungen zu den Hauptbeteiligten müssen genau
überprüft werden.
Schritt 4: Untersuchung der Beteiligten weiterer Grade und ihrer
Beziehungen
Die Untersuchung von Beteiligten und Beziehungen sollte so oft wiederholt werden, wie
es nötig ist, und kann auch tertiäre und quartäre Beteiligte einschließen. Untersuchen
Sie dabei jeweils erschöpfend die Beteiligten und Beziehungen einer Ebene, bevor Sie zur
nächsten übergehen. Ansonsten könnten Sie sich in den Tiefen des Kaninchenlochs verirren und Beziehungen übersehen, die Ihre Sichtweise auf einige Hosts verändern könnten.
Wenn Sie damit fertig sind, können Sie die Beziehungen zwischen den Beteiligten beschreiben und angeben, wie eventuelle schädliche Aktivitäten abgelaufen sind.
Beispiel einer relationalen Untersuchung
Sehen wir uns nun ein Beispiel dafür an, wie der relationale Untersuchungsprozess in
einer NSM-Umgebung in der Praxis abläuft.
Schritt 1: Untersuchung der Hauptbeteiligten und vorläufige Bewertung der Meldung
Nehmen wir an, wir werden durch den folgenden Snort-Alarm auf eine Anomalie aufmerksam gemacht:
ET WEB_CLIENT PDF With Embedded File
In diesem Alarm werden die IP-Quelladresse 192.0.02.5 (möglicherweise feindlicher Host
A) und die IP-Zieladresse 172.16.16.20 (eigener Host B) angegeben. Dies sind die Hauptbeteiligten. Die vorläufige Untersuchung des zugehörigen Datenverkehrs zeigt, dass im
Rahmen des Vorfalls eine PDF-Datei heruntergeladen wurde. Als Nächstes beschaffen wir
uns die PCAP-Daten für die fragliche Kommunikationssequenz, entnehmen daraus mithilfe von Wireshark die PDF-Datei und reichen den MD5-Hash dieser Datei beim Malware Hash Registry von Team Cymru ein. Das Register gibt an, dass 23 % der AntivirusEngines die Datei für schädlich halten.
506 15 Der Analysevorgang
Der nächste Schritt besteht in einer taktischen Aufklärung über den eigenen und den
fremden Host. Dabei gewinnen wir folgende Informationen:
Erkenntnisse über den eigenen Host 172.16.16.20:
•• Bei dem System handelt es sich um eine Benutzerarbeitsstation mit Windows 7.
•• Auf dem System lauschen keine Dienste, es sind auch keine Ports geöffnet.
•• Der Benutzer dieses Systems ist häufig im Web unterwegs. In den PRADS-Daten
finden sich mehrere New-Assets-Benachrichtigungen.
Erkenntnisse über den fremden Host 192.0.2.5:
•• IPVoid findet keine Übereinstimmungen mit öffentlichen Blacklists für die IP-Adresse.
•• URLVoid findet fünf Übereinstimmungen mit öffentlichen Blacklists für die Domäne,
von der die PDF-Datei heruntergeladen wurde.
•• Die NetFlow-Daten zeigen, dass diese IP-Adresse nicht mit anderen Geräten im eigenen
Netzwerk kommuniziert hat.
Nicht definierte Beziehung
Snort-Alarm wegen des Downloads
einer PDF-Datei
Hauptbeteiligter
Gegnerisches Element
Hält eine schädliche Domäne vor
Hauptbeteiligter
Eigenes Element
Benutzerarbeitsstation
Abbildung 15.2: Die Hauptbeteiligten
Schritt 2: Untersuchung der Beziehungen zwischen den Hauptbeteiligten und ihrer
aktuellen Interaktion
Um die Beziehung zwischen 172.16.16.20 und 192.0.2.5 zu untersuchen, laden wir die
Paketdaten für die Kommunikation zwischen diesen beiden Hosts im Zeitraum von zehn
Minuten vor dem Alarm bis zehn Minuten danach herunter. Eine Analyse dieser Daten
zeigt, dass der eigene Host durch eine Drittanbieterwerbung auf einer legalen Website
zu dem gegnerischen Host umgeleitet wurde, wo er dann die Datei heruntergeladen hat.
Danach endete die Kommunikation mit dem gegnerischen Host.
Der nächste Schritt in der Untersuchung der Beziehung zwischen den beiden Hosts besteht darin, die heruntergeladene PDF-Datei zu inspizieren. Dazu übergeben wir sie an
Cuckoo, um eine automatische Malwareanalyse durchführen zu lassen. Die Verhaltensanalyse zeigt, dass das PDF eine ausführbare Datei einhält, in deren Konfiguration die
IP-Adresse 192.0.2.6 hartkodiert ist. Das allerdings ist alles an Informationen, was die
Malwareanalyse ergibt.
15.1 Analysemethoden 507
Damit haben wir die Untersuchung der Hauptbeteiligten und ihrer Beziehungen abgeschlossen. Alles deutet zwar darauf hin, dass es sich tatsächlich um einen Zwischenfall handelt, aber eine eindeutige Bestimmung ist noch nicht möglich. Allerdings haben wir einen
sekundären Beteiligten erkannt, weshalb wir zum nächsten Schritt übergehen können.
Schädliche EXE-Datei
Hartkodierte IP-Adresse in der Stringausgabe
In der Malware
erkannt
Schädliche PDF-Datei
Enthält schädliche EXE-Datei
Übereinstimmung in Team
Cymru MHR gefunden
Sekundärer Beteiligter
Gegnerisches Element
Downloads einer PDF-Datei durch das eigene Element
Umleitung aufgrund einer Anzeige auf einer legalen Website
Hauptbeteiligter
Gegnerisches Element
Hält eine schädliche Domäne vor
Hauptbeteiligter
Eigenes Element
Benutzerarbeitsstation
Abbildung 15.3: Beziehungen zwischen den Hauptbeteiligten
Schritt 3: Untersuchung der sekundären Beteiligten und ihrer Beziehungen
In der ausführbaren Datei innerhalb der heruntergeladenen PDF-Datei haben wir den
sekundären Beteiligten 192.0.2.6 gefunden, über den wir als Nächstes Informationen einholen müssen:
Erkenntnisse über den fremden Host 192.0.2.6:
•• IPVoid findet zwei Übereinstimmungen mit öffentlichen Blacklists für die IP-Adresse.
•• Die NetFlow-Daten zeigen, dass der Hauptbeteiligte 172.16.16.20 mit diesem Host
kommuniziert hat. Dies geschah etwa 30 Minuten nach dem Alarm.
•• Die NetFlow-Daten zeigen, dass zwei andere eigene Hosts in unserem Netzwerk während der letzten Tage regelmäßig mit diesem Host kommuniziert haben. Der Umfang
des Datenverkehrs war gering. Die Adressen dieser Hosts lauten 172.16.16.30 und
172.16.16.40.
508 15 Der Analysevorgang
Diese Informationen deuten darauf hin, dass das Problem größer ist als ursprünglich gedacht.
Als Nächstes bestimmen wir die Beziehung zwischen dem sekundären Beteiligten 192.0.2.6
und dem Hauptbeteiligten 172.16.16.20. Aufgrund unserer Aufklärung über den gegnerischen Host wissen wir bereits, dass zwischen diesen beiden Adressen eine Kommunikation
stattgefunden hat. Daher analysieren wir die PCAP-Daten über diese Kommunikation. Sie
zeigt, dass die Geräte zwar über Port 80 kommunizieren, dabei aber nicht das Protokoll
HTTP verwenden, sondern ein benutzerdefiniertes. Wir können auch die Befehle erkennen,
die an unser Gerät übertragen werden und die es dazu veranlassen, Systeminformationen an
den gegnerischen Host zu senden. Dabei bemerken wir auch einen regelmäßigen Rückruf
an diesen Host.
Damit haben wir genügend Informationen, um das Vorliegen eines Zwischenfalls und
einen Einbruch in 172.16.16.20 zu erklären (siehe Abb. 15.4). Unter Umständen kann die
Untersuchung damit enden. Hier aber haben wir zwei weitere Hosts gefunden (tertiäre
Beteiligte), die mit dem gegnerischen Host 192.0.2.6 kommunizieren. Es besteht daher
eine hohe Wahrscheinlichkeit, dass auch sie infiziert sind.
Schritt 4: Untersuchung der Beteiligten weiterer Grade und ihrer Beziehungen
Eine Untersuchung der zwischen den tertiären Hosts und 192.0.2.6 übertragenen Paketdaten zeigt, dass sie das gleiche Rückrufverhalten aufweisen, dass wir bereits bei unserem
eigenen Hauptbeteiligten festgestellt haben (siehe Abb. 15.5). Daraus können wir schließen, dass auch unsere eigenen tertiären Hosts übernommen wurden.
Schädliche EXE-Datei
Hartkodierte IP-Adresse in der Stringausgabe
Sekundärer Beteiligter
Gegnerisches Element
IP-Adresse auf schwarzer Liste
Unbekannte tertiäre Beziehung
In der Malware erkannt
Schädliche PDF-Datei
Enthält schädliche EXE-Datei
Übereinstimmung in Team
Cymru MHR gefunden
Tertiärer Beteiligter
Eigenes Element
Benutzerarbeitsstation
Unbekannte tertiäre Beziehung
Sekundäre Beziehung
Kommunikation über TCP-Port 80 mit benutzerdefiniertem Protokoll
C2-Befehle erkannt
Systeminformationen werden an gegnerisches Element gesendet
Regelmäßiger Rückruf an gegnerisches Element
Primäre Beziehung
Downloads einer PDF-Datei durch das eigene Element
Umleitung aufgrund einer Anzeige auf einer legalen Website
Hauptbeteiligter
Gegnerisches Element
Hält eine schädliche Domäne vor
Hauptbeteiligter
Eigenes Element
Benutzerarbeitsstation
Abbildung 15.4: Beziehungen zwischen Haupt- und sekundären Beteiligten
Tertiärer Beteiligter
Eigenes Element
Benutzerarbeitsstation
15.1 Analysemethoden 509
Schädliche EXE-Datei
Hartkodierte IP-Adresse in der Stringausgabe
Sekundärer Beteiligter
Gegnerisches Element
IP-Adresse auf schwarzer Liste
Tertiäre Beziehung
Regelmäßiger Rückruf an
gegnerisches Element
In der Malware erkannt
Schädliche PDF-Datei
Enthält schädliche EXE-Datei
Übereinstimmung in Team
Cymru MHR gefunden
Tertiäre Beziehung
Regelmäßiger Rückruf an
gegnerisches Element
Sekundäre Beziehung
Kommunikation über TCP-Port 80 mit benutzerdefiniertem Protokoll
C2-Befehle erkannt
Systeminformationen werden an gegnerisches Element gesendet
Regelmäßiger Rückruf an gegnerisches Element
Tertiärer Beteiligter
Eigenes Element
Benutzerarbeitsstation
Tertiärer Beteiligter
Eigenes Element
Benutzerarbeitsstation
Primäre Beziehung
Downloads einer PDF-Datei durch das eigene Element
Umleitung aufgrund einer Anzeige auf einer legalen Website
Hauptbeteiligter
Gegnerisches Element
Hält eine schädliche Domäne vor
Hauptbeteiligter
Eigenes Element
Benutzerarbeitsstation
Abbildung 15.5: Beziehungen aller Beteiligter
Zusammenfassung des Zwischenfalls
Das zuvor gezeigte Beispiel beruht auf einem tatsächlichen Zwischenfall. Durch einen
systematischen Analyseprozess, bei dem wir die beteiligten Hosts und die Beziehungen
zwischen ihnen identifizierten, konnten wir nicht nur bestimmen, ob tatsächlich ein Einbruch erfolgt war, sondern auch weitere betroffene Hosts entdecken, die in dem Alarm
nicht genannt worden waren. Dieses Beispiel zeigt deutlich, wie ein klar gegliederter Prozess Analytikern helfen kann, von A nach B zu gelangen, ohne sich zu verzetteln oder von
einer Informationsflut überwältigt zu werden, was in einer Situation wie dieser nur zu
leicht geschehen kann. Der Schlüssel zum Erfolg besteht darin, jeden Schritt so durchzuführen, wie er gedacht ist, und nicht zu weit vom Pfad abzuweichen. Wenn Sie auf dem
Weg bleiben, wird er Sie schließlich ans Ziel führen.
15.1.2
Differenzielle Diagnose
NSM-Analytiker untersuchen die von Erkennungsmechanismen ausgelösten Alarme, indem sie verschiedene Datenquellen zurate ziehen, Tests durchführen und Nachforschungen anstellen, um herauszufinden, ob eine Verletzung der Netzwerksicherheit vorliegt. Das
ähnelt der Vorgehensweise von Ärzten, die die von einem Patienten geschilderten Symptome untersuchen, indem sie verschiedene Datenquellen zurate ziehen, Tests durchführen
und Nachforschungen anstellen, um herauszufinden, ob schädliche Einflüsse das Immunsystem des Patienten überwunden haben. Beide verbinden die Punkte, um zu ermitteln, ob
etwas Gefährliches vor sich gegangen ist oder immer noch vor sich geht.
510 15 Der Analysevorgang
Im Gegensatz zum NSM, bei dem es sich um eine relativ neue Entwicklung handelt, gibt es
die Medizin schon seit Jahrhunderten, weshalb sie bei der Entwicklung von Diagnosemethoden einen gehörigen Vorsprung hat. Eine der in der klinischen Medizin am häufigsten
eingesetzten Methoden ist die differenzielle Diagnose. Wenn Sie jemals eine Folge von Dr.
House gesehen haben, kennen Sie den Vorgang wahrscheinlich schon. Einer Gruppe von
Ärzten wird eine Liste von Symptomen genannt, woraufhin sie auf einer Tafel eine Liste
möglicher Diagnosen aufstellen. Danach werden Nachforschungen und Tests angestellt,
um nacheinander die einzelnen möglichen Ursachen auszuschließen, bis nur noch eine
übrig ist. Die in der Fernsehserie angewendeten Methoden sind zwar oft ziemlich unkonventionell, aber der Vorgang als solcher ist nichtsdestotrotz eine differenzielle Diagnose.
Diese Methode beruht auf dem Ausschlussverfahren. Sie besteht aus fünf Schritten, wobei
in manchen Fällen jedoch auch nur zwei erforderlich sein können. Der Vorgang läuft wie
folgt ab:
Schritt 1: Bestimmen und Auflisten der Symptome
In der Medizin werden die Symptome gewöhnlich mündlich von der Person geschildert,
die darunter leidet. Beim NSM ist ein Symptom gewöhnlich ein Alarm, der von einem
Intrusion-Detection-System oder einer Erkennungssoftware ausgelöst wurde. In diesem
Schritt geht es zunächst um die ursprünglichen Symptome, wobei jedoch nach der Durchführung von zusätzlichen Tests oder Untersuchungen weitere Symptome hinzukommen
können.
Schritt 2: Untersuchung der häufigsten Diagnose
Jeder Medizinstudent lernt in seinem ersten Jahr den Lehrsatz: »Wenn Sie Hufe klappern hören, halten Sie nach Pferden Ausschau – nicht nach Zebras.« Das besagt, dass die
häufigste Diagnose wahrscheinlich die richtige ist und daher als erste untersucht werden
sollte. Analytiker sollten daher zunächst das tun, was erforderlich ist, um diese Diagnose
zu bestätigen. Wenn das nicht möglich ist, geht es mit dem nächsten Schritt weiter.
Schritt 3: Auflisten aller möglichen Diagnosen für die gegebenen
Symptome
Der nächste Schritt im differenziellen Prozess besteht darin, eine Liste aller Diagnosen
aufzustellen, die aufgrund der zurzeit verfügbaren Informationen und ursprünglichen
Symptome möglich sind. Das erfordert Kreativität und ist vor allem dann erfolgreich,
wenn mehrere Analytiker ihren Beitrag dazu leisten. Wenn die häufigste Diagnose im vorherigen Schritt nicht bestätigt, aber auch nicht vollständig ausgeschlossen werden konnte,
gehört sie auch auf diese Liste.
15.1 Analysemethoden 511
Schritt 4: Ordnen der Liste von möglichen Diagnosen nach dem
Schweregrad
Nachdem die Ärzte die Liste der möglichen Diagnosen aufgestellt haben, ordnen sie sie
nach Priorität, wobei die Diagnose, die den lebensbedrohlichsten Zustand darstellt, an
die Spitze gesetzt wird. Ebenso ordnen auch NSM-Analytiker ihre Liste danach, welche Befunde die größte Bedrohung für die Sicherheit des Netzwerks ihrer Organisation
darstellen. Wie die Prioritäten gesetzt werden, hängt sehr stark von der Natur des Unternehmens ab. Ein Einbruch in eine MySQL-Datenbank mit Root-Berechtigungen ist
für ein Unternehmen, dessen Datenbank Kreditkartennummern enthält, weitaus schwerwiegender als für ein Unternehmen, das nur eine Datenbank mit dem Schichtplan der
Mitarbeiter unterhält.
Schritt 5: Sukzessiver Ausschluss der möglichen Diagnosen, beginnend
mit der schwerwiegendsten
Die meisten Aktivitäten finden im letzten Schritt statt. Hier führen die Analytiker alle
erforderlichen Maßnahmen auf, um die möglichen Diagnosen nach und nach von der
Liste zu entfernen, wobei sie mit derjenigen beginnen, die die größte Bedrohung für
die Sicherheit des Netzwerks darstellt. Dabei müssen für die einzelnen Diagnosen Tests
durchgeführt, Nachforschungen angestellt und weitere Datenquellen untersucht werden,
um sie als eine Möglichkeit auszuschließen. In manchen Fällen kann die Untersuchung
einer Diagnose auch gleich mehrere andere ausschließen, was den Vorgang beschleunigt.
Es kann aber auch sein, dass sich bei der Untersuchung von einigen möglichen Diagnosen
keine eindeutigen Schlüsse ziehen lassen, sodass sie nicht definitiv ausgeschlossen werden
können. Das ist akzeptabel, da es beim Network Security Monitoring (wie in der Medizin)
Anomalien gibt, die vorläufig nicht erklärt werden können und eine weitere Beobachtung erfordern, bevor eine abschließende Diagnose gestellt werden kann. Letzten Endes
aber soll in diesem Schritt nur noch eine einzige Diagnose übrig bleiben, sodass ein Zwischenfall erklärt oder das Ereignis als Fehlalarm abgetan werden kann. Denken Sie immer
daran, dass »normale Kommunikation« eine gültige Diagnose ist. Tatsächlich ist es die
Diagnoe, die NSM-Analytiker am häufigsten stellen werden.
512 15 Der Analysevorgang
Schri 1
Bes mmen und Auflisten der Symptome
Schri 2
Untersuchung der häufigsten Diagnose
Schri 3
Auflisten aller möglichen Diagnosen für die gegebenen Symptome
Schri 4
Ordnen der Liste von möglichen Diagnosen nach dem Schweregrad
Schri 5
Sukzessiver Ausschluss der möglichen Diagnosen,
beginnend mit der schwerwiegendsten
Abbildung 15.6: Der Analyseprozess der differenziellen Diagnose
Beispiele für die differenzielle Diagnose
Sehen wir uns nun einige Beispiele dafür an, wie die differenzielle Diagnose in der Praxis
abläuft. Da dieser Vorgang sehr unterschiedlich sein kann, betrachten wir zwei verschiedene Situationen.
Beispiel 1
Schritt 1: Bestimmen und Auflisten der Symptome. In IDS-Alarmen und bei der Untersuchung der unmittelbar verfügbaren Daten wurden folgende Symptome beobachtet:
1. Ein eigener Host sendet Datenverkehr an eine russische IP-Adresse.
2. Dieser Datenverkehr tritt regelmäßig alle 10 Minuten auf.
3. Es handelt sich um HTTPS-Datenverkehr über Port 443, weshalb er verschlüsselt und
nicht lesbar ist.
Schritt 2: Untersuchung der häufigsten Diagnose. Angesichts dieser Symptome scheint
die logischste Annahme darin zu bestehen, dass der Computer mit Malware infiziert ist
und nach Hause telefoniert, um weitere Anweisungen zu bekommen, denn schließlich
wendet er sich alle 10 Minuten an die russische IP-Adresse. All diese Umstände sind zwar
durchaus beachtenswert (sonst hätte ich sie hier auch nicht aufgeführt), aber ich glaube trotzdem, dass wir uns nicht so schnell auf die Malwaretheorie versteifen sollten. Der
geografische Standort einer IP-Adresse wird meistens überbewertet. Dass es sich um eine
russische IP-Adresse handelt, sagt zunächst einmal nicht viel aus. Es gibt auch viele normale Kommunikationsmechanismen, die in regelmäßigen Zeitabständen durchgeführt
15.1 Analysemethoden 513
werden, beispielsweise für Webchats, RSS-Feeds, webgestützte E-Mail, Aktienticker, Softwareupdates usw. Wenn wir nach dem Prinzip vorgehen, dass alle Pakete gut sind, sofern
wir nicht das Gegenteil bewiesen haben, muss die wahrscheinlichte Diagnose hier lauten,
dass es sich um normalen Datenverkehr handelt.
Es kann jedoch schwer sein zu bestätigen, dass etwas normal ist. In diesem Fall könnten
wir dazu Informationen über die russische IP-Adresse einholen. Auch wenn sie in Russland beheimatet ist, kann sie durchaus einer legitimen Organisation gehören. Wenn wir
Recherchen über die IP-Adresse anstellen und feststellen, dass sie für einen renommierten
Hersteller von Antiviruslösungen registriert ist, können wir daraus schließen, dass hier
ein Antivirusprogramm nach Updates sucht. Wenn Sie auch den URL kennen, zu dem der
HTTPS-Datenverkehr gerichtet ist, können Sie in Google danach suchen, um herauszufinden, ob es sich um eine legitime Website, eine Malwareplattform oder eine Steuerzentrale für ein Botnetz handelt. Eine andere Technik besteht darin, die Systemprotokolle und
die Protokolle des Host-IDS darauf zu untersuchen, ob auf dem betroffenen Computer in
denselben Zeitabständen verdächtige Aktivitäten ablaufen, in denen auch der Datenverkehr auftritt. Sie können auch Informationen über den eigenen Host einholen. Stammt
der Benutzer etwa aus Russland? Läuft auf dem Computer ein Antivirusprodukt, für das
es Updateserver in Russland gibt (wie es bei Kaspersky der Fall ist)? All dies kann Ihnen
dabei helfen herauszufinden, ob es sich um normalen Datenverkehr handelt oder nicht.
Für dieses Beispiel nehmen wir an, dass wir nicht in der Lage waren, eindeutig zu erkennen, ob es sich um normale Kommunikation gehandelt hat oder nicht.
Schritt 3: Auflisten aller möglichen Diagnosen für die gegebenen Symptome. Für die
vorliegende Situation gibt es mehrere mögliche Ursachen. Der Kürze halber beschränken
wir uns hier nur auf die folgenden:
Normale Kommunikation. Da wir diese Möglichkeit im vorherigen Schritt nicht komplett
ausschließen konnten, müssen wir sie in diesen Schritt übernehmen.
Malwareinfektion/installierte Schadlogik. Das ist eine ziemlich breit gefasste Kategorie. Bevor wir nicht wissen, ob überhaupt Malware im Spiel ist, machen wir uns gewöhnlich
noch keine Gedanken über ihre konkrete Natur. Wenn Sie allerdings berechtigte Sorgen
wegen einer bestimmten Malware haben, dann können Sie sie als eigenen Eintrag in die
Liste aufnehmen. Das ist ungefähr so, als ob ein Arzt »bakterielle Infektion« in dem Bewusstsein auf die Liste schreibt, dass er die konkrete Natur dieser Infektion genauer bestimmen kann, sobald er mehr Informationen hat.
Datendiebstahl von dem betroffenen Host. Dies bedeutet, dass der Host in kurzen Abständen vertrauliche Informationen nach draußen sendet. Solche Vorfälle treten oft im Rahmen gezielter Angriffe auf.
Fehlkonfiguration. Es kann durchaus möglich sein, dass sich ein Systemadministrator bei
der Eingabe einer IP-Adresse vertippt hat, weshalb eine Software, die eigentlich regelmäßig mit einem internen System kommunizieren soll, jetzt ständig versucht, sich an die
russische Adresse zu wenden. So etwas geschieht sogar ziemlich häufig.
514 15 Der Analysevorgang
Schritt 4: Ordnen der Liste von möglichen Diagnosen nach dem Schweregrad. Die Sortierung der erkannten möglichen Ursachen nach dem Schweregrad hängt sehr stark vom
Risikoprofil der Organisation ab. In diesem Fall habe ich die Diagnosen wie folgt geordnet:
Priorität 1: Datendiebstahl von dem betroffenen Host
Priorität 2: Malwareinfektion/installierte Schadlogik
Priorität 3: Fehlkonfiguration
Priorität 4: Normale Kommunikation
Schritt 5: Sukzessiver Ausschluss der möglichen Diagnosen, beginnend mit der
schwerwiegendsten. Jetzt können wir Daten sammeln und Tests durchführen, um die
einzelnen möglichen Ursachen auszuschließen. Dieser Vorgang endet, wenn Sie die
richtige Diagnose ermittelt haben. Zur Veranschaulichung gehen wir in diesem Beispiel
jedoch alle möglichen Diagnosen durch.
Priorität 1: Datendiebstahl von dem betroffenen Host. Diese Möglichkeit auszuschließen
kann schwierig sein, denn da der Datenverkehr verschlüsselt ist, helfen Ihnen auch die
FPC-Daten nicht weiter. Falls Sie Sitzungsdaten zur Verfügung haben, können Sie immerhin den Umfang der gesendeten Daten ermitteln. Gehen in den 10-Minuten-Abständen
immer nur wenige Bytes nach draußen, handelt es sich wahrscheinlich nicht um Datendiebstahl, da dabei viel größere Mengen von Daten übertragen werden. Es kann sich auch
lohnen nachzuforschen, ob andere Hosts in Ihrem Netzwerk mit derselben IP-Adresse
oder mit anderen IP-Adressen im selben Adressraum kommunizieren. Der Vergleich
des möglicherweise schädlichen Datenverkehrs mit einem Referenzwert für die normale
Kommunikation kann ebenfalls wichtige Einsichten liefern. Dazu können Sie Informationen aus der Aufklärung über eigene Elemente einsetzen, z. B. PRADS-Daten.
Priorität 2: Malwareinfektion/installierte Schadlogik. Wenn Sie bei Ihren Untersuchungen
so weit gekommen sind, sollten Sie schon eine gute Vorstellung davon haben, ob dies die
Ursache ist oder nicht. Es ist durchaus wahrscheinlich, dass Sie diese Diagnose bei der Untersuchung der Möglichkeit eines Datendiebstahls ausschließen oder bestätigen können.
Neben den Maßnahmen, die in dem entsprechenden Schritt beschrieben wurden, können
Sie auch die Protokolle von Netzwerk-Antivirusprogrammen und dem Host-IDS genau
untersuchen.
Priorität 3: Fehlkonfiguration. Diese Möglichkeit lässt sich am besten dadurch untersuchen,
dass Sie den verdächtigen Datenverkehr mit dem Datenverkehr anderer eigener Hosts vergleichen, die in Ihrem Netzwerk eine ähnliche Rolle spielen. Wenn jede Arbeitsstation
im selben Subnetz das gleiche Verkehrsmuster aufweist, dabei aber andere IP-Adressen
anruft, ist es wahrscheinlich, dass an irgendeiner Stelle eine falsche IP-Adresse eingegeben
wurde. Auch in den Systemprotokollen von Windows- und Unix-Hosts können sich Hinweise darauf finden, ob eine Fehlkonfiguration vorliegt.
Priorität 4: Normale Kommunikation. Wenn Sie bis hierhin gekommen sind, ist »normale
Kommunikation« die einzige mögliche Diagnose, die noch übrig ist.
15.1 Analysemethoden 515
Abschließende Diagnose. Jetzt müssen Sie sich auf Ihre Erfahrung als Analytiker und Ihre
Intuition verlassen, um zu entscheiden, ob wirklich etwas Schädliches vor sich geht oder
nicht. Wenn Sie die vorstehende Analyse bis hierhin gründlich durchgeführt haben, dann
bedeutet das im Prinzip, dass alle Pakete gut sind, sofern nicht das Gegenteil bewiesen ist,
dass Ihre abschließende Diagnose »normale Kommunikation« lauten muss. Sollten Sie
aber trotzdem das Gefühl haben, dass etwas nicht mit rechten Dingen zugeht, sollten Sie
sich nicht scheuen, den Host weiterhin zu beobachten und die Situation erneut zu bewerten, sobald Sie weitere Daten zur Verfügung haben.
Beispiel 2
Schritt 1: Bestimmen und Auflisten der Symptome. In IDS-Alarmen und bei der Unter­
suchung der unmittelbar verfügbaren Daten wurden folgende Symptome beobachtet:
1. Ein Webserver in der DMZ empfängt erhebliche Mengen eingehenden Daten­
verkehrs.
2. Dieser eingehende Datenverkehr ist nicht lesbar und möglicherweise verschlüsselt
oder verschleiert.
3. Der Datenverkehr geht auf dem internen Host an mehreren Zielports ein.
4. Es handelt sich um UDP-Datenverkehr.
Schritt 2: Untersuchung der häufigsten Diagnose. Da es sich um erhebliche Mengen von
Datenverkehr handelt, der an den internen Host geht, und dabei das Protokoll UDP mit
zufälligen Zielports verwendet wird, liegt die Vermutung nahe, dass es sich um eine Form
von Denial-of-Service-Angriff handelt.
Am schnellsten lässt sich diese mögliche Ursache dadurch überprüfen, dass Sie den Umfang des empfangenen Datenverkehrs mit dem vergleichen, was normalerweise auf diesem
Host eingeht. Das können Sie sehr leicht mit den Sitzungsdaten und Durchsatzstatistiken
tun, die wir in Kapitel 11 besprochen haben. Wenn der Host nur 20 % mehr Datenverkehr
empfängt als gewöhnlich, sollen Sie sich lieber nach einer anderen Erklärung umsehen. Ist
der Datenverkehr aber um einen Faktor 10 oder gar 100 umfangreicher als üblich, ist ein
DoS-Angriff sehr wahrscheinlich. Denken Sie daran, dass auch ein unbeabsichtigter DoSAngriff ein DoS-Angriff ist.
Auch hier werden wir zur Veranschaulichung davon ausgehen, dass wir in diesem Schritt
keine klare Entscheidung treffen konnten, ob ein DoS-Angriff vorliegt.
Schritt 3: Auflisten aller möglichen Diagnosen für die gegebenen Symptome. Für die
vorliegende Situation gibt es mehrere mögliche Ursachen. Der Kürze halber beschränken
wir uns auf die folgenden:
Denial of Service. Da wir diese Möglichkeit im vorherigen Schritt nicht komplett ausschließen konnten, müssen wir sie in diesen Schritt übernehmen.
516 15 Der Analysevorgang
Normale Kommunikation. Es mag sehr unwahrscheinlich klingen, ist aber trotzdem
denkbar, dass es sich hierbei um normalen Datenverkehr durch einen legitimen Dienst
handelt.
Fehlgeleiteter Angriff. Angreifer fälschen oft die Quelladresse, um anonym zu bleiben und
zu verhindern, dass sie selbst Opfer eines DoS-Angriffs werden. Das führt dazu, dass der
Besitzer der falschen Adresse den betreffenden Datenverkehr wahrnimmt. Es kann sein,
dass der Webserver in unserem Beispiel die Auswirkungen eines solchen Vorgangs sieht.
Falsch konfigurierter externer Host. Eine Fehlkonfiguration kann in einem fremden Netzwerk genauso vorkommen wie in Ihrem. Das kann dazu führen, dass ein externer Host
Datenverkehr an Ihren Webserver sendet.
Spamrelais. Der Server kann fehlkonfiguriert oder übernommen worden sein, sodass er
zur Weiterleitung von Spammails über das Internet missbraucht wird.
Schritt 4: Ordnen der Liste von möglichen Diagnosen nach dem Schweregrad. Die Sortierung der erkannten möglichen Ursachen nach dem Schweregrad hängt sehr stark vom
Risikoprofil der Organisation ab. In diesem Fall habe ich die Diagnosen wie folgt geordnet:
Priorität 1: Denial of Service
Priorität 2: Spamrelais
Priorität 3: Falsch konfigurierter externer Host
Priorität 4: Fehlgeleiteter Angriff
Priorität 5: Normale Kommunikation
Schritt 5: Sukzessiver Ausschluss der möglichen Diagnosen, beginnend mit der schwerwiegendsten. Jetzt können wir Daten sammeln und Tests durchführen, um die einzelnen
möglichen Ursachen auszuschließen. Dieser Vorgang endet, wenn Sie die richtige Diagnose ermittelt haben. Zur Veranschaulichung gehen wir in diesem Beispiel jedoch alle
möglichen Diagnosen durch.
Priorität 1: Denial of Service. Diese Möglichkeit haben wir bereits untersucht, ohne dabei
zu einer eindeutigen Diagnose zu kommen. Auch wenn es sich um die schwerwiegendste
Ursache handelt, müssen wir zunächst damit weitermachen, die anderen Möglichkeiten
auszuschließen, um herauszufinden, ob es sich tatsächlich um einen DoS-Angriff handelt. Je nachdem, welche Auswirkungen der Vorfall hat, kann es jedoch sinnvoll sein, das
Problem zunächst einmal einzudämmen, indem Sie den entsprechenden Datenverkehr
blockieren, bevor Sie Ihre Zeit der Suche nach der Ursache widmen.
Priorität 2: Spamrelais. Diese Möglichkeit lässt sich relativ leicht ausschließen. Wenn der
Server tatsächlich als Mailrelais missbraucht wird, dann können Sie nicht nur sehr viel
eingehenden, sondern auch eine entsprechende Menge ausgehenden Datenverkehrs beobachten. Ist das nicht der Fall – geht also kein Datenverkehr in unnormalem Umfang von
dem Server aus –, dann handelt es sich wahrscheinlich nicht um ein Spamrelais. Das können Sie herausfinden, indem Sie aus den Sitzungsdaten Durchsatzstatistiken erstellen, wie
15.1 Analysemethoden 517
wir es in Kapitel 11 besprochen haben. Wenn auf dem Webserver auch Maildienste laufen,
sollten Sie sich auch deren Protokolle ansehen. Ist der Server dagegen nicht für Maildienste vorgesehen, überprüfen Sie ihn darauf, ob er sie ohne Autorisierung doch ausführt.
Priorität 3: Falsch konfigurierter externer Host. Dies ist gewöhnlich ein ziemlich kniffliges
Problem. Sofern Sie den Besitzer der IP-Adresse nicht kennen und mit ihm sprechen können, bleibt Ihnen meistens nichts anderes übrig, als den Datenverkehr lokal zu sperren
oder eine Missbrauchsmeldung bei dem zuständigen Provider einzureichen.
Priorität 4: Fehlgeleiteter Angriff. Dies ist aus ähnlichen Gründen wie im vorherigen Fall
schwierig. Wenn die Kapriolen irgendeines unbekannten Angreifers dafür sorgen, dass
Datenverkehr zu Ihrem Server umgeleitet wird, dann können Sie meistens nichts anderes tun, als das Problem dem für die IP-Adresse zuständigen Provider zu melden und
den Datenverkehr lokal zu blockieren.
Priorität 5: Normale Kommunikation. Das mag unwahrscheinlich klingen, aber solange
Sie keinen Referenzwert für den normalen Datenverkehr auf diesem Host haben, können
Sie es nicht mit Sicherheit ausschließen. Informationen über den eigenen Host, die Sie
mit einem Tool wie PRADS gewonnen haben, in Kombination mit einer Untersuchung
der Sitzungsdaten ermöglichen es Ihnen, den auf dem Host anfallenden Datenverkehr
zu ähnlichen Zeitpunkten am Vortag zu vergleichen und daraus Schlüsse zu ziehen. Ist
das Kommunikationsmuster normal und nur der Umfang anomal? Hat der Server jemals
zuvor mit der verdächtigen IP-Adresse kommuniziert? Die Beantwortung dieser Fragen
kann Ihnen wichtige Fingerzeige geben.
Abschließende Diagnose. Bei diesem Beispiel kann es sein, dass Sie am Ende drei mögliche Ursachen haben, die Sie nicht ausschließen können. Zum Glück können Sie aber bei
allen diesen Möglichkeiten Maßnahmen zur Eindämmung oder Linderung des Problems
einleiten. Damit sind Sie durch die Diagnose immerhin in eine Lage gekommen, in der
sich das Netzwerk von dem Vorfall erholen kann. Das ist ungefähr so, als ob ein Arzt zwar
weiß, dass bei einem Patienten eine Infektion vorliegt, und ihre genaue Natur zwar nicht
bestimmen kann, aber wenigstens weiß, dass eine Behandlung mit Antibiotika das Problem lösen wird.
Wenn der Datenverkehr nicht so umfangreich ist, dass er die Ausführung von Diensten
behindert, brauchen Sie die Aktivitäten möglicherweise gar nicht zu blockieren. Dadurch
haben Sie die Gelegenheit, sie weiter zu beobachten, um noch mehr Informationen zu
gewinnen, die zu einer genauen Diagnose führen können.
15.1.3
Umsetzen der Analysemethoden
Die beiden hier beschriebenen Analysemethoden sind sehr unterschiedlich. Es gibt keine
eindeutige Formel, um die richtige auszuwählen, da beide ihre Stärken und Schwächen haben. Welche Vorgehensweise besser geeignet ist, hängt von der vorliegenden Situation und
von den Stärken und Schwächen des Analytikers ab. Nach meiner Erfahrung eignet sich
die relationale Untersuchung bei komplizierten Vorfällen am besten, in die mehrere Hosts
518 15 Der Analysevorgang
verwickelt sind. Das liegt daran, dass Sie bei dieser Vorgehensweise den Überblick über
eine große Anzahl von Beteiligten und Beziehungen bewahren können, ohne überfordert
zu werden und auf Irrwege zu geraten. Die differenzielle Diagnose dagegen funktioniert
am besten in Situationen mit nur wenigen Hosts, bei denen Sie einige klar ausgeprägte
Symptome festgestellt haben.
Wichtig ist, sich nicht buchstabengetreu an diese Methoden zu klammern. Sie stellen lediglich ein Grundgerüst dar, das Sie an Ihre Umgebung anpassen müssen. Jede Analyse
profitiert von einer systematischen Vorgehensweise, die es den Analytikern erlaubt, ihre
Untersuchungen effizient durchzuführen.
15.2 Empfohlene Vorgehensweisen für die Analyse
Ich habe überall in diesem Buch schon verschiedene empfohlene Vorgehensweisen für die
Analyse erwähnt. Jeder geht bei der Analyse nach seinem eigenen Stil vor, aber es gibt einige Grundsätze, deren Beachtung ich immer als vorteilhaft erachtet habe. Die folgenden
empfohlenen Vorgehensweisen beruhen auf den jahrelangen Erfahrungen der Autoren
dieses Buches und unserer Kollegen.
15.2.1
Bei Paketen können Sie sich auf nichts verlassen
Bei der Analyse spielen Annahmen und fundierte Vermutungen eine große Rolle. Die
meisten Entscheidungen treffen Sie auf der Grundlage eines Pakets oder eines Protokoll­
eintrags sowie zusätzlicher Daten. Sobald neue Informationen hinzukommen, können
sich diese Annahmen und Vermutungen aber ändern. Doch keine Sorge, das ist ein ganz
normaler Vorgang. Fragen Sie mal Ihren Arzt oder Apotheker! Der Großteil von deren
Arbeit beruht ebenfalls auf Annahmen, und sie sind damit sehr erfolgreich.
Was Sie sich merken sollten, ist, dass es bei der Analyse kaum etwas gibt, auf das Sie sich
verlassen können, weshalb es sinnvoll ist, alle Annahmen und Vermutungen ständig zu
überprüfen. Handelt es sich bei der IP-Adresse wirklich um einen bekannten legitimen
Host? Gehört die Domäne wirklich zum Unternehmen XYZ? Soll der DNS-Server wirklich
mit dem Datenbankserver kommunizieren? Stellen Sie immer Ihre eigenen Annahmen
infrage und bleiben Sie wachsam.
15.2.2 Machen Sie sich klar, wie die Daten abstrahiert werden
Als Analytiker stützen Sie sich bei Ihrer Arbeit auf Daten, z. B. auf PCAP-Dateien, PSTREinträge oder IIS-Dateien. Da Sie beim Umgang mit diesen Daten meistens mehrere
Werkzeuge einsetzen, müssen Sie immer im Hinterkopf behalten, was diese Werkzeuge
mit den Daten machen. Manche »Features« solcher Tools können Daten verschleiern und
eine korrekte Analyse verhindern.
15.2 Empfohlene Vorgehensweisen für die Analyse 519
Ich habe einmal für eine Organisation gearbeitet, die eine weit verbreitete kommerzielle
SIEM-Lösung eingesetzt hat. Eines Tages entdeckten wir in der SIEM-Konsole merkwürdige Protokolleinträge, nach denen interner Datenverkehr in großem Umfang zu Port 80
an der IP-Adresse 255.255.255.255 ging. Eine genauere Untersuchung der Daten ergab,
dass es sich bei diesem Datenverkehr um interne HTTP-Anforderungen handelte, die von
einem Webproxy blockiert wurden. Eine Aktualisierung des Parsers, den das SIEM-System
nutzte, um Datensätze von diesem Proxy zu verarbeiten, hatte dazu geführt, dass er nicht
mehr wusste, wie er mit dem Feld für die IP-Zieladresse umgehen sollte, was zu dem
falschen Wert 255.255.255.255 führte. Dieses Beispiel zeigt, wie wichtig es ist, sich immer
darüber im Klaren zu sein, wie stark die Daten abstrahiert werden.
In einem Beruf, bei dem die Verwendung von Daten das A und O ist, ist es unverzichtbar
zu wissen, wie Ihre Werkzeuge sich auf die Daten auswirken.
15.2.3 Vier Augen sehen mehr als zwei
Es hat seinen Grund, dass Lektoren die Werke von Autoren lesen, dass Polizeibeamte zu
zweit arbeiten und in Raketensilos immer zwei Personen auf Wache sind. Wie viel Erfahrung Sie auch immer haben und wie gut Sie auch sein mögen, irgendetwas werden Sie
trotzdem übersehen, denn niemand arbeitet stets und ständig zu 100 % effizient. Schließlich sind wir alle nur Menschen.
Da ich aus der Rüstungsindustrie komme, schaue ich mir bei der Untersuchung von
Netzwerkverkehr als Erstes das Quell- und Zielland an. Ich weiß zwar, dass die Angaben
über den geografischen Standort meistens irrelevant sind, da sie sich leicht fälschen lassen
oder nur die Lage eines weiteren geknackten Hosts angeben, der von jemandem in einem
ganz anderen Land gesteuert wird. Aber diese Vorgehensweise ist mir in Fleisch und Blut
übergegangen. Viele meiner Kollegen sind ehemalige Systemadministratoren, weshalb sie
als Erstes nach den Portnummern schauen. Ich habe auch schon mit Personen zusammengearbeitet, die ursprünglich mit rechenintensiver Datenverarbeitung zu tun hatten,
und sie fragen als Erstes nach der Menge der übertragenen Daten. Dies zeigt, dass unsere
Erfahrungen unsere Vorgehensweise formen. Dadurch kann der Datenverarbeiter etwas
erkennen, was dem Systemadministrator nicht auffällt, und der Rüstungsexperte wiederum sieht etwas, was der Datenverarbeiter nicht wahrnimmt.
Lassen Sie nach Möglichkeit immer ein zweites Paar Augen einen Blick auf das vorliegende Problem werfen. In Sicherheitsteams setze ich gewöhnlich eine Zwei-PersonenRegel durch, laut der immer mindestens zwei Analytiker erforderlich sind, um einen
Zwischenfall zu konstatieren.
15.2.4 Laden Sie einen Angreifer niemals zum Tanz ein
Mein Mitarbeiter Mike Poor, leitender SANS-Ausbilder und Paketninjameister, hat es auf
den Punkt gebracht: »Laden Sie einen Angreifer niemals zum Tanz ein!« Für Analytiker
520 15 Der Analysevorgang
kann es eine große Versuchung sein, eine gegnerische IP-Adresse genauer zu untersuchen,
als es mit konventionellen Mitteln möglich ist. Es gab viele Gelegenheiten, bei denen es
mich gereizt hat, einen Portscan an einem gegnerischen Computer durchzuführen, der
schlecht zusammengestellte UDP-Pakete an mein Netzwerk sendete. Jedes Mal, wenn
jemand einen DoS-Angriff auf ein Netzwerk zu starten versucht, für dessen Schutz ich
verantwortlich bin, wünsche ich mir nichts sehnlicher, als über seine unvorbereitete DSLVerbindung die tobende Gewalt eines /8-Netzwerks loszulassen.
Das Problem dabei ist jedoch, dass wir in 99 % der Fälle nicht wissen, mit wem oder was
wir es zu tun haben. Auch wenn Sie nur einen Scan erkennen, kann es sein, dass der Host,
von dem dieser Datenverkehr stammt, von einer großen Gruppe von Angreifern oder sogar vom Militär eines anderen Landes betrieben wird. Selbst etwas so Harmloses wie ein
Ping kann einen Angreifer auf Sie aufmerksam machen und dazu veranlassen, seine Taktik
zu ändern, andere Quellhosts zu verändern oder sogar seine Anstrengungen zu verstärken.
Sie wissen nicht, mit wem Sie es zu tun haben, was er beabsichtigt und wozu er fähig ist.
Daher sollten Sie ihm niemals auch nur den kleinen Finger hinhalten, denn Sie wissen
nicht, ob Sie in der Lage sein werden, mit den Folgen fertig zu werden.
15.2.5 Pakete sind von Natur aus gut
Einer der großen Streitfragen im Leben dreht sich darum, ob die Menschen von Natur aus
gut oder von Natur aus böse sind. Dieselben Standpunkte gibt es auch bei Paketen: Manche Analytiker gehen davon aus, dass sie von Natur aus böse sind, andere dagegen halten
sie für von Natur aus gut.
Nach meiner Erfahrung neigen Analytiker am Anfang ihrer Karriere dazu, Pakete als generell böse einzuschätzen, gehen dann aber mehr und mehr zu der Ansicht über, dass sie im
Grunde genommen gut sind. Das liegt daran, dass es schlicht unmöglich ist, jede einzelne
im Netzwerk übertragene Information als etwas zu behandeln, was eine Bedrohung auf
Root-Ebene darstellen könnte. Wenn Sie so vorgingen, würden Sie schließlich gefeuert, weil
Sie den lieben langen Tag lang versuchen, einem einzigen Alarm auf die Spur zu kommen;
oder sie brechen einfach vor Erschöpfung zusammen. Gründlichkeit ist sicherlich nichts
Verkehrtes, aber es ist nun einmal Tatsache, dass der Großteil des Datenverkehrs in einem
Netzwerk nicht böse ist, weshalb Sie Pakete grundsätzlich als unschuldig ansehen sollten,
solange nicht das Gegenteil bewiesen ist.
15.2.6 Wireshark macht so wenig einen Analytiker wie ein Teleskop
einen Astronomen
Wenn ich ein Einstellungsgespräch für die Stelle eines Analytikers (oberhalb des Einsteigerniveaus) führe, bitte ich den Kandidaten immer zu beschreiben, wie er einen typischen IDS-Alarm untersuchen würde. Damit möchte ich mir über seinen Denkprozess
klarwerden. Nicht selten aber erhalte ich dabei Antworten wie: »Ich verwende Wireshark,
Network Miner, Netwitness und Arcsight.« Und das war es dann auch schon.
15.2 Empfohlene Vorgehensweisen für die Analyse 521
Es gibt es zwar Prozesse und wissenschaftliche Vorgehensweisen, um ein Network Security
Monitoring durchzuführen, aber NSM ist mehr als das. Anderenfalls wäre es gar nicht
nötig, überhaupt noch Menschen einzubeziehen. Einem guten Analytiker muss klar sein,
dass die vielen verschiedenen Werkzeuge zwar unentbehrlich sind, um die Aufgaben zu
erledigen, aber nur Teile des Gesamtkunstwerks darstellen. Für einen Astronomen ist ein
Teleskop nur eines von vielen Werkzeugen, mit denen er Erkenntnisse über den Lauf der
Gestirne gewinnt, und ebenso ist auch Wireshark nur eines von vielen Werkzeugen, die
Analytiker einsetzen, um herauszufinden, wie ein Paket von A nach B gelangt.
Gehen Sie von den wissenschaftlichen Grundlagen aus, nehmen Sie einige Werkzeuge und
formale Prozesse hinzu, behalten Sie das Gesamtbild im Auge und beachten Sie die Einzelheiten. Durch die Kombination all dieser verschiedenen Elemente und der Erfahrungen,
die Sie im Laufe der Zeit sammeln, werden Sie Ihre eigene Analysetechnik entwickeln.
15.2.7 Klassifizierung hilft
Es wird nicht lange dauern, bis Sie sich in einer Situation wiederfinden, in der Sie mehr
als ein signifikantes Ereignis auf einmal analysieren müssen. In einem Fall ist es hilfreich, ein System parat zu haben, um zu bestimmen, welcher Vorfall die Priorität für
die Untersuchung genießt. In den meisten Sicherheitsorganisationen gibt es ein solches
Klassifizierungssystem. Es gibt verschiedene Varianten, aber ich habe mich an das Klassifizierungssystem des US-Verteidigungsministeriums für Netzwerkzwischenfälle und
-ereignisse nach CJCSM 6510 gewöhnt.1 Tabelle 15.1 führt die die einzelnen Kategorien
nach ihrer Priorität auf.
Tabelle 15.1: Klassifizierungssystem des US-Verteidigungsministeriums für Zwischenfälle und
Ereignisse
Priorität
Kategorie
Name
Einstufung
0
0
Schulung
–
1
1
Einbruch auf Root-Ebene
Zwischenfall
2
2
Einbruch auf Benutzerebene
Zwischenfall
3
4
Denial of Service
Zwischenfall
4
7
[Installierte/ausgeführte] Schadlogik
Zwischenfall
5
3
Nicht erfolgreiche versuchte Aktivität
Ereignis
6
5
Nicht richtlinienkonforme Aktivität
Ereignis
7
6
Aufklärung
Ereignis
8
8
Untersuchung
Ereignis
9
9
Erklärte Anomalie
Ereignis
1 http://www.dtic.mil/cjcs_directives/cdata/unlimit/m651001.pdf
522 15 Der Analysevorgang
Bericht von der Front
Ereignisse im Zusammenhang mit Schadlogik bringen neue Analytiker oft zum
Stolpern. Wenn Anfänger irgendeinen Hinweis auf Schadcode erkennen, klassifizieren sie das Ereignis gewöhnlich als Kategorie 7. Bei Zwischenfällen dieser
Kategorie geht es jedoch um installierte oder ausgeführte Schadlogik und nicht
einfach darum, dass ein System Schadcode herunterlädt. Um ein Ereignis als
Kategorie 7 klassifizieren zu können, müssen Sie Belege dafür haben, dass der
Schadcode tatsächlich auf einem Computer installiert oder ausgeführt wurde.
Es kann zwar sein, dass sich dieses konkrete Modell nicht besonders gut für Ihre Organisation eignet, doch glaube ich, dass jede Organisation von einem Klassifizierungssystem
profitiert. Wenn ein Analytiker eine erste vorläufige Überprüfung eines Ereignisses durchführt und dabei zu dem Schluss kommt, dass eine gründlichere Untersuchung angebracht
ist, sollte das Ereignis immer einer Kategorie zugeordnet werden, und wenn es auch nur
die Kategorie »Untersuchung« (Kategorie 8) ist. Während der Untersuchung kann sich
die Kategorie mehrmals ändern, und zwar sowohl nach oben als auch nach unten. Die
Kategorie und jegliche Änderungen daran sollten zusammen mit einer Erklärung durch
den jeweils verantwortlichen Analytiker in dem internen Dokumentierungssystem der
Organisation festgehalten werden.
15.2.8 Die Zehnerregel
Neulinge auf dem Gebiet der Analyse neigen dazu, bei der Untersuchung eines Ereignisses
zu viele oder zu wenige Daten abzurufen. Nehmen wir beispielsweise an, am 7. Oktober um
8.35 Uhr tritt ein Ereignis ein. Wenn ein Analytiker nun NSM-Daten für den betroffenen
Host abruft, die den gesamten 7. Oktober umfassen, hat er viel zu viele Daten, um noch
eine effiziente Analyse durchzuführen. Am anderen Ende des Spektrums stehen Analytiker,
die sich nur die Daten für die eine Minute ansehen, in der das Ereignis stattfand. Das sind
zu wenig Informationen, um bestimmen zu können, was genau geschehen ist.
Um zu verhindern, dass meine Analytiker in eine dieser beiden Fallen tappen, habe ich
die Zehnerregel aufgestellt. Bei der Untersuchung eines Ereignisses, das an einem konkreten Zeitpunkt stattgefunden hat, sollen sie die Daten aus dem Zeitraum von zehn
Minuten vor bis zehn Minuten nach diesem Ereignis abrufen. Nach meiner Erfahrung
ist dieser Zeitraum ein guter Kompromiss, durch den die Analytiker gute Daten erhalten,
um herausfinden zu können, was zu dem Ereignis geführt hat und was danach geschehen
ist. Nachdem sie diese Daten untersucht haben, können Sie gegebenenfalls weitere abrufen. Natürlich ist diese Regel nicht für alle Situationen ideal, aber sie hat sich in 99 % der
Untersuchungen, die neue Analytiker durchführen, als wirkungsvoll erwiesen.
15.3 Morbidität und Mortalität von Zwischenfällen 523
15.2.9 Wenn Sie Hufe klappern hören, halten Sie nach Pferden
Ausschau – nicht nach Zebras
Diese Weisheit ist aus der Medizin ausgeborgt, wo sie den Studenten während ihrer gesamten Ausbildung immer wieder eingetrichtert wird. Wenn ein Patient mit Bauchschmerzen
zu Ihnen kommt, ist es nicht sinnvoll, bei der Diagnose mit Tests für seltene Erkrankungen
zu beginnen. Fragen Sie den Patienten stattdessen, was er am Abend zuvor gegessen hat.
Wenn es zwei Dutzend Tacos und eine halbe Pizza waren, dann sind Sie dem Problem
wahrscheinlich schon auf die Spur gekommen.
Ebenso sollen Sie auch bei der Untersuchung eines Ereignisses zuerst die offensichtlichste
Erklärung berücksichtigen. Wenn ein System regelmäßig Daten an einen unbekannten
Webserver sendet, sollten Sie nicht gleich annehmen, dass es sich um einen Rückruf an
eine gegnerische Steuerinfrastruktur handelt. Wahrscheinlich hat nur jemand eine Webseite geöffnet, die ständig nach aktuellen Sportergebnissen oder Börsenkursen sucht.
Um nach diesem Prinzip arbeiten zu können, müssen Sie die zuvor angeführte »Unschuldsvermutung« akzeptieren, nach der Pakete von Natur aus gut sind. Es ist auch
wichtig für die Analysemethode der differenziellen Diagnose, die wir in einem früheren
Abschnitt besprochen haben.
15.3 Morbidität und Mortalität von Zwischenfällen
Es mag wie ein Gemeinplatz klingen, aber durch die Stärkung des Teamworks in einer
Gruppe von Analytikern betonen Sie den gemeinsamen Erfolg gegenüber dem individuellen Erfolg. Es gibt dazu viele verschiedene Möglichkeiten, darunter die Vorgehensweisen,
die wir schon in Kapitel 1 kennengelernt haben, z. B. die Förderung von Superstars und
die Kultivierung von Führung als Dienst. Daneben gibt es aber keinen besseren Weg, für
den Erfolg eines Teams zu sorgen, als eine Kultur des Lernens aufzubauen. Das bedeutet
mehr als einfach nur die Analytiker auf Fortbildungskurse zu schicken oder für Zertifizierungen zu zahlen. Es erfordert, eine Haltung anzunehmen, nach der ein Analytiker bei
jeder Handlung immer entweder lehrt oder lernt – ohne Ausnahme. Wenn alle Analytiker
jeden Aspekt ihrer täglichen Arbeit als eine Gelegenheit sehen, etwas Neues zu lernen oder
ihren Kollegen etwas beizubringen, dann blüht und gedeiht die Kultur des Lernens.
Dazu gehört es auch, sowohl aus Erfolgen als auch aus Niederlagen zu lernen. Beim NSM
geht es um technische Untersuchungen von Fällen und, wenn etwas Schlimmes geschieht,
um Zwischenfälle. Das ähnelt wiederum der Medizin, bei der es ebenfalls um die Untersuchung von Fällen und, wenn das Schlimmste eintritt, von Todesfällen geht.
524 15 Der Analysevorgang
15.3.1
M&M in der Medizin
Wenn ein Patient stirbt und es so aussieht, als hätte sein Tod durch eine andere medizinische Behandlung verhindert oder verzögert werden können, wird der behandelnde Arzt oft
zu einer sogenannten Morbiditäts- und Mortalitätskonferenz oder kurz M&M gebeten, in
der er den Fall darstellt, vom ersten Besuch des Patienten mit den geschilderten Symptomen, der Krankengeschichte und den Ergebnissen der Untersuchung über die Diagnose bis
zu den Behandlungsschritten, die bis zum Tod des Patienten vorgenommen wurden.
An dieser Besprechung nehmen Kollegen teil, darunter alle weiteren Ärzte, die an der Behandlung des Patienten beteiligt waren, aber auch Ärzte, die gar nichts mit dem Fall zu tun
hatten. Diese Kollegen hinterfragen die Behandlung, um Fehler zu entdecken, die möglicherweise gemacht wurden, Prozesse, die verbessert werden können, und Situationen, die
besser auf andere Weise gehandhabt worden wären.
Das Ziel einer M&M in der Medizin besteht darin, aus den aufgetretenen Komplikationen
und Fehlern zu lernen, das eigene Verhalten und seine Entscheidungen aufgrund der gemachten Erfahrungen zu ändern und die Wiederholung der Fehler zu verhindern, die zu
den Komplikationen geführt haben. In der Medizin wird das seit über hundert Jahren so
gehandhabt und hat sich als äußerst erfolgreich erwiesen.2
15.3.2 M&M in der Informationssicherheit
Weiter vorn in diesem Kapitel haben uns bereits angesehen, wie sich das Prinzip der differenziellen Diagnose von der Medizin auf die Informationssicherheit übertragen lässt.
Ebenso können wir das Konzept von M&M-Konferenzen übernehmen.
Wenn man auf dem Gebiet der Informationssicherheit arbeitet, ist es sehr leicht, etwas zu
übersehen. Da wir wissen, dass vorbeugende Maßnahmen irgendwann versagen werden,
können wir nicht erwarten, niemals mit einem tatsächlich erfolgten Einbruch konfrontiert zu werden. Stattdessen müssen wir uns so aufstellen, dass wir einen Zwischenfall
erkennen und schnell darauf reagieren können. Nachdem das geschehen ist, können wir
aus den Fehlern lernen, die den Einbruch ermöglicht haben, damit wir die Vorbeugung,
Erkennung und Reaktion beim nächsten Mal besser machen können.
Wenn ein Zwischenfall eintritt, würden wir uns gern vormachen können, dass wir ohnehin nichts dagegen hätten tun können, weil es sich um einen besonders ausgeklügelten
Angriff handelt oder weil der Angreifer einen noch unbekannten Zero-Day-Exploit verwendet hat. In Wirklichkeit jedoch sind nicht alle Angriffe so kompliziert, und es gibt oft
Möglichkeiten für eine schnellere Erkennung, Analyse und Reaktion. Bei der M&M auf
dem Gebiet der Informationssicherheit sammeln wir solche Erkenntnisse und wenden
sie an. Um aus Fehlern zu lernen, wie wir uns verbessern können, müssen wir begreifen,
warum die Fehler passiert sind. In seinem Beitrag zu dem Buch Managing Strategic Surprise – Pflichtlektüre für Informationssicherheitsexperten! – fasst Uzi Arad das sehr gut
2 Campbell, W. (1988). »Surgical morbidity and mortality meetings«. Annals of the Royal College of
Surgeons of England 70 (6): 363–365. PMC 2498614.PMID 3207327.
15.3 Morbidität und Mortalität von Zwischenfällen 525
zusammen.3 Er beschreibt darin drei Probleme, die zu Fehlern bei der Verwaltung von
Aufklärungsinformationen führen. Diese drei Grundprobleme lassen sich auf die Informationssicherheit übertragen:
•• Die falsche Wahrnehmung des Materials, die aus der Schwierigkeit herrührt, die objektive Realität oder die Realität aus der Sicht des Gegners zu begreifen.
•• Das Vorherrschen vorgefasster Meinungen unter den Analytikern, die keine objektive,
professionelle Deutung der Realität zulässt, die sich aus den ermittelten Informationen
erkennen lässt.
•• Gruppenzwang, Gruppendenken und sozio-politische Überlegungen, die die professionelle Bewertung und Analyse verzerren.
Der Zweck einer M&M-Konferenz in der Informationssicherheit besteht darin, ein Forum
zu bieten, in dem diese Probleme durch strategische Überprüfung erfolgter Zwischenfälle
überwunden werden können.
Zeitpunkt
Die M&M-Konferenz wird einberufen, nachdem der Zwischenfall aufgetreten ist und behandelt wurde. Die Entscheidung, welche Zwischenfälle eine solche Konferenz erfordern,
trifft gewöhnlich der Teamleiter oder ein Mitglied der Geschäftsführung, das in der Lage
ist zu erkennen, ob eine Untersuchung auch besser gehandhabt worden sein könnte. Die
Konferenz sollte relativ kurz nach dem Zwischenfall stattfinden, sodass die Einzelheiten
noch im Gedächtnis der Beteiligten haften geblieben sind, aber es sollte auch genügend
Zeit verstrichen sein, um den Vorfall komplett zu analysieren. Ein guter Zeitpunkt ist gewöhnlich eine Woche nach dem Zwischenfall.
Referenten
Die Darstellung der Untersuchung wird oft von mehreren Personen vorgetragen. In der
Medizin kann dies der Arzt in der Notaufnahme, der Chirurg und der Hausarzt sein, in
der Informationssicherheit der NSM-Analytiker, der den Zwischenfall als Erster erkannt
hat, eine Krisenreaktionskraft, die den Zwischenfall eingedämmt und korrigierende Maßnahmen ergriffen hat, ein Forensiker, der den betroffenen Computer untersucht hat, oder
ein Malwarespezialist, der ein Reverse Engineering der bei dem Vorfall eingesetzten Malware durchgeführt hat.
Teilnehmende Kollegen
Als weitere Teilnehmer an der M&M sollte mindestens je ein weiterer Vertreter der durch
die Referenten vertretenen Fachgebiete anwesend sein, also beispielsweise für jeden direkt
3 Arad, Uzi (2008). »Intelligence Management as Risk Management«, in: Paul Bracken, Ian Bremmer, David
Gordon (Hrsg.), Managing Strategic Surprise (S. 43–77). Cambridge: Cambridge University Press.
526 15 Der Analysevorgang
in den Vorfall verwickelten NSM-Analytiker mindestens ein weiterer NSM-Analytiker, der
nichts damit zu tun hat. Das dient dazu, frische Ideen einzubringen, die nicht auf das Bedürfnis beschränkt sind, die Aktionen zu rechtfertigen, die im Rahmen der Untersuchung
vorgenommen wurden. Im Idealfall, der sich aber nur in großen Organisationen verwirklichen lässt, sollte es mindestens zwei zusätzliche Teilnehmer aus jedem Fachgebiet geben,
wobei der eine weniger und der andere mehr Erfahrung hat als der Referent.
Die Präsentation
Der oder die Referenten sollten mindestens einige Tage Zeit bekommen, sich auf die Präsentation vorzubereiten. Eine M&M-Konferenz ist zwar keine formale Veranstaltung, aber
es sollte trotzdem eine ordentliche Darstellung erwartet werden, die eine chronologische
Übersicht über den Zwischenfall gibt und alle unterstützenden Daten einschließt. Der
Referent sollte die Erkennung, Untersuchung und Wiederherstellung in der Reihenfolge
des Ablaufs beschreiben und die gewonnenen Erkenntnisse an den Stellen angeben, an
denen sie auch tatsächlich entdeckt wurden. Dadurch ist eine ganzheitliche Untersuchung
des Zwischenfalls möglich.
Die Kollegen werden dazu aufgefordert, während der Präsentation Fragen zu stellen,
sobald sie auftauchen. Natürlich muss dies auf geordnete Weise durch Handheben geschehen, aber die Fragen sollten nicht bis zum Ende der Präsentation aufgeschoben
werden. Das dient dazu, den Referenten auf die gleiche Weise mit den Fragen zu konfrontieren, wie es während der laufenden Untersuchung der Fall wäre.
Strategische Befragung
Die gestellten Fragen sollen dazu dienen herauszufinden, worum irgendetwas auf eine
bestimmte Weise getan wurde oder warum es nicht anders gemacht wurde. Solche Fragen
können sehr leicht als persönlicher Angriff aufgefasst werden, weshalb es wichtig ist, dass
alle Teilnehmer offen an die M&M herangehen und dass sowohl Referenten als auch teilnehmende Kollegen beim Stellen und Beantworten der Fragen professionell und mit dem
gebotenen Respekt vorgehen.
Zu Anfang mag es für die Teilnehmer schwierig sein, Fragen zu formulieren, die konstruktiv sind und dabei helfen, die drei zuvor genannten Probleme zu überwinden. Es gibt
jedoch verschiedene Möglichkeiten, die richtigen Arten von Fragen zu fördern.
Advocatus Diaboli
Eine Methode, die Uzi Arad in seinem Beitrag zu Managing Strategic Surprise erwähnt, ist
die des Advocatus Diaboli. Dabei versuchen die Teilnehmer, praktische jede analytische
Schlussfolgerung des Referenten anzuzweifeln. Dazu wird erst bestimmt, welche Schlussfolgerungen angreifbar sind, um dann Informationen aus dem Zwischenfall zu sammeln,
15.3 Morbidität und Mortalität von Zwischenfällen 527
die eine andere Annahme unterstützen. Aufgabe der Referenten ist es dann, ihre eigenen
Schlussfolgerungen zu verteidigen und gegenteilige Ansichten zu widerlegen.
Alternative Analyse (AA)
In seinem Aufsatz »The Limits of Intelligence Analysis« stellt R. J. Heuer mehrere Methoden für die strategische Befragung vor. Sie gehören alle zu einem Satz analytischer
Werkzeuge, die als alternative Analyse (AA)4 bezeichnet werden. Zu den gebräuchlicheren
dieser Methoden zählen:
Gruppe A/Gruppe B
Bei dieser Vorgehensweise analysieren zwei Gruppen von Experten den Zwischenfall
getrennt voneinander auf der Grundlage derselben Informationen. Dazu stellen die
Referenten (Gruppe A) den teilnehmenden Kollegen (Gruppe B) die unterstützenden
Daten zu dem Zwischenfall bereits vor der M&M bereit, sodass diese zusammenarbeiten
können, um eine eigene Analyse durchzuführen, die dann während der Besprechung
mit der Analyse von Gruppe A verglichen wird. Das Ziel besteht darin, zwei getrennte Gedankengänge durchzuführen. Wenn die beiden Gruppen an einzelnen Stellen zu
unterschiedlichen Schlussfolgerungen gelangen, sind weitere Diskussionen erforderlich,
um herauszufinden, warum das so ist.
Rote-Zellen-Analyse
Der Schwerpunkt dieser Methode liegt auf dem gegnerischen Standpunkt. Die teilnehmenden Kollegen nehmen hierbei die Rolle des Gegners in dem betreffenden Zwischenfall ein. Sie befragen die Referenten darüber, wie deren Untersuchungsmaßnahmen als
Reaktion auf die Aktionen des Angreifers durchgeführt wurden. Beispielsweise kann es
sein, dass sich die Verteidiger einzig und allein darauf konzentrieren, wie sie verhindern
können, dass eine Malware Rückmeldung an den Angreifer gibt, während der Angreifer mehr daran interessiert ist, ob die Verteidiger die stattgefundene Kommunikation
entschlüsseln konnten. Das kann zu einer sehr positiven Folge von Fragen führen, die
wiederum in neuen Analysemethoden resultieren, um den Einfluss des Angreifers besser
bewerten zu können. Davon profitiert letztendlich der Prozess zur Eindämmung von
Zwischenfällen.
Was-wäre-wenn-Analyse
Der Hauptaugenmerk bei dieser Methode liegt auf den möglichen Ursachen und Wirkungen von Ereignissen, die gar nicht eingetreten sind. So kann ein Kollege beispielsweise
Fragen, wie der Angriff hätte erkannt werden können, wenn der Mechanismus, mit dem
er aufgespürt worden ist, nicht richtig funktioniert hätte. Eine Frage zur Reaktion auf einen Zwischenfall könnte etwa lauten, was die Referenten getan hätten, wenn der Angreifer
nicht erst nach abgeschlossenem Datendiebstahl entdeckt worden wäre, sondern während
4 Heuer, Richards J., Jr. »Limits of Intelligence Analysis«, Orbis 49, Nr. 1 (2005)
528 15 Der Analysevorgang
er noch dabei war, die Daten aus dem Netzwerk herauszuschmuggeln. Solche Fragen stehen nicht immer in einer direkten Beziehung zu dem behandelten Zwischenfall, führen
aber zu sehr wertvollen Gedankenspielen, die Ihrem Team helfen können, sich besser gegen
zukünftige Zwischenfälle zu wappnen.
Analyse widerstreitender Hypothesen
Diese Methode ähnelt der Vorgehensweise bei der differenziellen Diagnose. Hier stellen
die Kollegen eine erschöpfende Liste alternativer Schlussfolgerungen aus den geschilderten Symptomen auf. Am wirkungsvollsten ist es, auf einer Whiteboardtafel alle möglichen
Diagnosen aufzulisten und sie nach der Überprüfung der zusätzlichen Daten sukzessive
auszuschließen und durchzustreichen.
Überprüfung der zentralen Annahmen
In praktisch allen Wissenschaften werden Annahmen auf der Grundlage allgemein anerkannter Fakten getroffen. Bei dieser Befragungsmethode geht es darum, die wichtigsten
Annahmen und deren Auswirkungen auf die Untersuchung zu überprüfen. Diese Vorgehensweise wird oft mit einer Was-wäre-wenn-Analyse kombiniert. Betrachten wir zum
Beispiel die Annahme, dass eine Malware, die in einer virtuellen Maschine ausgeführt
wird, nicht die Möglichkeit hat, auf den Host oder auf andere virtuelle Maschinen auf
diesem Host überzugreifen. Bei einem Zwischenfall, in dem eine virtuelle Maschine mit
Malware infiziert wurde, könnte ein Teilnehmer nun die Frage stellen, welche Maßnahmen ergriffen worden wären, wenn die Malware der virtuellen Umgebung entflohen wäre
und die anderen VMs auf dem Host oder den Host selbst infiziert hätte.
Ergebnis der M&M
Alle Teilnehmer sollten während der Durchführung der M&M Notizen machen. Nach
dem Ende der Besprechung fassen die Referenten ihre Notizen zu einem Abschlussbericht zusammen, der ihrem Präsentationsmaterial und den unterstützenden Daten beigefügt wird. Dieser Bericht sollte auch alles einschließen, was man anders hätte handhaben
können, sowie sämtliche Verbesserungen, die die Organisationen im Ganzen vornehmen
kann, sowohl technisch als auch was die Vorgehensweisen betrifft. Der Bericht wird der
Akte für die Untersuchung des Zwischenfalls beigefügt. Letzten Endes dienen diese Informationen als Erfahrungswerte, die aus dem Zwischenfall gewonnen werden konnten.
Weitere Tipps zur M&M
Nachdem ich schon mehrere solcher Konferenzen und ähnliche Überprüfungen organisiert und auch daran teilgenommen habe, kann ich Ihnen einige weitere Tipps geben, um
dafür zu sorgen, dass diese Besprechungen auch Nutzen bringen:
15.3 Morbidität und Mortalität von Zwischenfällen 529
•• M&M-Konferenzen sollten nur sporadisch abgehalten werden – nicht mehr als eine
pro Woche und nicht mehr als drei pro Monat.
•• Es muss betont werden, dass der Zweck einer M&M nicht darin besteht, Personen zu
kritisieren oder zu beurteilen, sondern um eine Kultur des Lernens zu fördern.
•• M&M-Konferenzen müssen von jemandem aus der Teamleitung oder dem unteren
Management moderiert werden, damit die Diskussion nicht zu hitzig wird und um
Fragen in die richtige Richtung zu lenken. Es ist wichtig, dass der Moderator einen
technischen Hintergrund hat und nicht etwa aus dem oberen Management stammt,
damit er auch genau versteht, was besprochen wird.
•• Wenn Sie in Ihrer Organisation M&M-Konferenzen einführen, sollte es ein Erfordernis sein, dass alle Mitarbeiter irgendwann dabei mitwirken, entweder als Referent oder
als teilnehmende Kollegen.
•• Der Abschlussbericht sollte dem gesamten technischen Personal sowie der Geschäftsführung zur Verfügung gestellt werden.
•• Spezialisten für Informationssicherheit ähneln Ärzten oft auch hinsichtlich eines aufgeblähten Egos. Bei den ersten Konferenzen dieser Art kann es daher zu Auseinandersetzungen und hitzigen Debatten kommen. Das ist zu Anfang zu erwarten, wird sich
aber bei guter Leitung und Moderation mit der Zeit legen.
•• Eine M&M-Konferenz sollte als zwanglose Veranstaltung durchgeführt werden. Um
die Anspannung zu verringern, können Sie vor oder nach der Besprechung etwas zu
essen reichen oder andere Tätigkeiten koordinieren.
•• Überlegen Sie es sich sehr gut, ob Sie jemanden aus dem oberen Management zu diesen
Konferenzen einladen. Die Gegenwart solcher Personen verhindert oft offene Fragen
und Antworten, und meistens bringen sie nicht genügend technisches Verständnis mit,
um Nutzen aus der Präsentation zu ziehen oder gar selbst wertvolle Beiträge zu leisten.
•• Wenn Sie nicht genügend Zwischenfälle für M&Ms haben, dann denken Sie sich
welche aus! Solche Konferenzen bilden eine hervorragende Vorgehensweise, um
Übungen durchzuführen, bei denen hypothetische Szenarien diskutiert werden. Sie
können dazu auch ein Gegenspielerteam einsetzen, das Angriffe simuliert.
Die Einführung solcher Konferenzen muss unbedingt mit großer Vorsicht erfolgen! In der
Medizin wurde das M&M-Prinzip in den frühen 1900er Jahren von Dr. Ernest Codman
am Massachusetts General Hospital von Boston eingeführt. Das MGH war so empört
über Dr. Codmans Vorschlag, die Kompetenz der Ärzte zu überprüfen, dass er seine Privilegien einbüßte. Heutzutage dagegen ist M&M in der modernen Medizin eine Standardmaßnahme und wird in den besten Krankenhäusern der Welt durchgeführt, auch im
MGH. Auch in der Informationssicherheit habe ich eine ähnlich abweisende Haltung auf
den Vorschlag von Peer-Reviews erlebt. Für uns als NSM-Fachleute ist es jedoch von entscheidender Bedeutung, ein solches Peer-Review anzunehmen, das Lernen in der ganzen
Gruppe zu fördern und zu einer Verbesserung unserer Fähigkeiten anzuregen.
530 15 Der Analysevorgang
15.4 Zusammenfassung
In diesem Kapitel ging es um den Analysevorgang und zwei verschiedene Methoden, um
ihn auf strukturierte und systematische Weise durchzuführen. Wir haben uns auch einige
Beispiele für die Anwendung dieser Methoden und bewährte Vorgehensweisen angesehen.
Zum Schluss haben wir uns mit Methoden für eine nachträgliche Untersuchung beschäftigt, um aus Zwischenfällen Lehren zu ziehen.
Wie sehr Sie sich auch immer anstrengen mögen, eines Tages wird in dem Netzwerk, das
Sie schützen, ein erfolgreicher Angriff und damit ein Einbruch erfolgen. In der Sicherheitslandschaft von heute ist das unvermeidlich. Dagegen können Sie nicht viel tun, denn
alle vorbeugenden Maßnahmen werden irgendwann versagen. Daher ist es wichtig, dass
Sie sich auf diesen Fall vorbereiten.
Bei einem Zwischenfall wird sich später niemand mehr dafür interessieren, wie er vonstatten gegangen ist, sondern wie darauf reagiert wurde, welche Ausfallzeiten er hervorrief, wie
viele Informationen verloren gingen und wie viel Geld die Organisation dadurch verloren hat. Welche Empfehlungen können Sie der Geschäftsführung machen, damit ähnliche
Zwischenfälle nicht wieder auftreten können? Wie können Sie Ihren Vorgesetzten erklären,
warum der Angriff nicht erkannt wurde? Welche Schwächen haben Ihre Tools? Vollständig
beantworten können Sie diese Fragen erst im Zusammenhang mit einem tatsächlichen Angriff, also erst dann, wenn ein Einbruch erfolgt ist. Dennoch sollten Sie sich diese Fragen
ständig selbst stellen, um Ihre Erfassungs-, Erkennungs- und Analyseprozesse zu verbessern. Jedes Ereignis und jeder Zwischenfall durchläuft den NSM-Zyklus, und die Lehren,
die Sie aus jedem dieser Ereignisse und Zwischenfälle ziehen, helfen dabei, den Prozess für
das nächste Mal zu verbessern.
Die Angreifer werden Sie überraschen, Sie werden an Ihrer schwachen Stelle getroffen,
und manchmal werden Sie den Kampf verlieren. Dieses Kapitel und dieses Buch haben
Sie mit den Werkzeugen und Techniken bekannt gemacht, mit denen Sie sich für diesen
Fall wappnen können.
A
Steuerskripte für Security Onion
Dieser Anhang führt