IT-Sicherheit für TCP/IP- und IoT-Netzwerke: Grundlagen, Konzepte, Protokolle, Härtung [1. Aufl.] 978-3-658-22602-2;978-3-658-22603-9

Table of contents :
Front Matter ....Pages I-XX
Einführung (Steffen Wendzel)....Pages 1-3
Front Matter ....Pages 5-5
Grundlagen der Netzwerktechnik (Steffen Wendzel)....Pages 7-77
Grundlagen der IT-Sicherheit (Steffen Wendzel)....Pages 79-104
Front Matter ....Pages 105-105
Einführung in die Kryptografie (Steffen Wendzel)....Pages 107-163
Weiterführende Themen der Kryptografie (Steffen Wendzel)....Pages 165-187
Front Matter ....Pages 189-189
Einführung in die Netzwerksicherheit (Steffen Wendzel)....Pages 191-207
Angriffe auf TCP/IP-Netzwerkprotokolle (Steffen Wendzel)....Pages 209-242
Absicherung der Netzwerkschichten (Steffen Wendzel)....Pages 243-272
Front Matter ....Pages 273-273
Netzwerksteganografie (Steffen Wendzel)....Pages 275-294
Sicherheit im Internet der Dinge (Steffen Wendzel)....Pages 295-337
Back Matter ....Pages 339-354

Citation preview

Steffen Wendzel

IT-Sicherheit für TCP/IP- und IoT-Netzwerke Grundlagen, Konzepte, Protokolle, Härtung

IT-Sicherheit für TCP/IP- und IoT-Netzwerke

Steffen Wendzel

IT-Sicherheit für TCP/IPund IoT-Netzwerke Grundlagen, Konzepte, Protokolle, Härtung

Steffen Wendzel Fachbereich Informatik Hochschule Worms Worms, Deutschland

ISBN 978-3-658-22602-2 ISBN 978-3-658-22603-9 (eBook) https://doi.org/10.1007/978-3-658-22603-9 Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar. Springer Vieweg © Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2018 Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung, die nicht ausdrücklich vom Urheberrechtsgesetz zugelassen ist, bedarf der vorherigen Zustimmung des Verlags. Das gilt insbesondere für Vervielfältigungen, Bearbeitungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichenund Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Der Verlag, die Autoren und die Herausgeber gehen davon aus, dass die Angaben und Informationen in diesem Werk zum Zeitpunkt der Veröffentlichung vollständig und korrekt sind. Weder der Verlag, noch die Autoren oder die Herausgeber übernehmen, ausdrücklich oder implizit, Gewähr für den Inhalt des Werkes, etwaige Fehler oder Äußerungen. Der Verlag bleibt im Hinblick auf geografische Zuordnungen und Gebietsbezeichnungen in veröffentlichten Karten und Institutionsadressen neutral. Springer Vieweg ist ein Imprint der eingetragenen Gesellschaft Springer Fachmedien Wiesbaden GmbH und ist ein Teil von Springer Nature. Die Anschrift der Gesellschaft ist: Abraham-Lincoln-Str. 46, 65189 Wiesbaden, Germany

Meinen Eltern gewidmet.

Vorwort

Die Betrachtung der IT-Sicherheit von Netzwerken ist an sich kein grundlegend neues Thema. Im Gegenteil, es ist bereits seit Jahrzehnten ein ausgereiftes Forschungs- und Arbeitsgebiet für viele Menschen. Durch die immer weiter fortschreitende Durchdringung von IT-Technologie in unserem Alltag und die damit verbundene Verbreitung von Netzwerken und die zunehmende Interaktion zwischen bestehenden Netzwerken sind TCP/IP- und IoT-Netzwerke jedoch potenziell einer stetig steigenden Anzahl an Angreifern ausgesetzt. Derlei Angriffe stellen auch deshalb eine aktuelle und permanente Herausforderung dar, da ihre Perfektionierung zunimmt. Dieses Buch setzt sich mit den Grundkonzepten von TCP/IP- und IoT-Netzwerken und der zugehörigen IT-Sicherheit auseinander. Es erläutert Angriffe und Schutzmechanismen. Weiterhin führt das Buch in einige Vertiefungsthemen ein und verfolgt das Ziel, sowohl praxisrelevantes Know-how als auch grundlegende und aktuelle Forschungsideen in einem Werk zu vereinen. Aus Gründen der Lesbarkeit habe ich im Text auf eine permanente Unterscheidung hinsichtlich der Ausgereiftheit von erwähnten Methoden verzichtet. Das heißt, manch ein Schutzmechanismus mag bereits in vorhandene Netzwerkkomponenten und Netzwerkbetriebssysteme integriert sein, andere Schutzmechanismen wurden bisher hingegen nur unter Laborbedingungen erprobt und spiegeln den aktuellen Forschungsstand wider. Passend zum Buch gibt es eine Webseite, auf der Sie Zusatzmaterial, insbesondere Vorlesungsunterlagen, Links und Errata finden: http://linuxbuch.blogspot.com/ Ein mehrere hundert Seiten umfassendes Werk ist mit Sicherheit nie völlig frei von Fehlern. Eine Liste der aktuell bekannten Fehler finden Sie auf der oben genannten Webseite. Sollten Sie selbst einen Fehler finden, der nicht in der Fehlerliste der Buchwebseite enthalten ist, so würde ich mich über eine entsprechende E-Mail freuen, damit ich den Fehler bekanntmachen und für zukünftige Auflagen bereinigen kann. Einer Reihe von Menschen bin ich zu Dank verpflichtet. In erster Linie ist dies Sybille Thelen, meiner Lektorin vom Springer-Verlag. Sie hat mitten in der Manuskripterstellung einer Themenanpassung des Buchs zugestimmt und mir die dafür notwendige zusätzliche Schreibzeit gewährt. Ich danke Ralf Borchers, der die sprachliche Durchsicht des Manuskripts vornahm. Außerdem danke ich meinen Studentinnen und Studenten, die VII

VIII

Vorwort

in meinen Vorlesungen durch Fragen und Hinweise halfen, Inhalte zu perfektionieren, was insbesondere dienlich war, um fehlende Annahmen zu explizieren und Illustrationen didaktisch zu verfeinern. Ich wünsche Ihnen bei der Lektüre dieses Buches viel Freude und hoffe, dass es Ihrer Begeisterung für das spannende Gebiet der TCP/IP- und IoT-Sicherheit zuträglich sein wird. Worms, Juni 2018

Steffen Wendzel

Inhaltsverzeichnis

1

Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Kapitelüberblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Für wen dieses Buch geschrieben wurde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4 Über den Autor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Teil I 2

1 1 2 3 3 3

Grundlagen

Grundlagen der Netzwerktechnik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Reichweite von Netzwerken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.2 Netzwerktopologien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Datenpakete, Einkapselung und die Entwicklung von TCP/IP . . . . . . . . . . 2.2.1 Einige Worte zum OSI-Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.2 OSI- vs. TCP/IP-Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Grundzüge des TCP/IP-Modells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1 Link Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.2 Internet Layer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.3 Transport Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.4 Application Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.5 Zusammenfassung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 Die wichtigsten Protokolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5 Link Layer: ARP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.1 Reverse-ARP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.2 Proxy-ARP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6 Internet Layer: IPv4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6.1 IP-Adressen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6.2 Fragmentierung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7 7 8 9 10 12 13 13 13 23 24 26 26 26 27 28 28 29 32 33

IX

X

Inhaltsverzeichnis

2.7

Internet Layer: ICMPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.7.1 ICMP-Types 0 und 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.7.2 ICMP-Type 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.7.3 ICMP-Type 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.7.4 ICMP-Type 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.7.5 ICMP-Types 9 und 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.7.6 ICMP-Type 11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.7.7 ICMP-Type 12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.7.8 Weitere ICMP-Typen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.8 Internet Layer: IGMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.8.1 Der IGMPv2-Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.9 Internet Layer: IPv6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.9.1 IPv6-Adressen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.9.2 IPv6 Header Extensions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.10 Internet Layer: ICMPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.11 Transport Layer: UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.11.1 Der UDP-Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.12 Transport Layer: TCP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.12.1 TCP-Reliability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.12.2 Sende- und Empfangspuffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.12.3 Flusskontrolle (Flow-Control) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.12.4 Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.12.5 Kommunikationsphasen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.13 Application Layer: DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.14 Application Layer: HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.14.1 Aufbau des HTTP-Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.14.2 HTTP/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.15 Application Layer: DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.15.1 Resource Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.15.2 Resolving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.15.3 Der DNS-Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.15.4 DNS-Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.16 Application Layer: E-Mail- und Usenetprotokolle . . . . . . . . . . . . . . . . . . . . . . . 2.16.1 POP3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.16.2 IMAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.16.3 SMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.16.4 NNTP (Usenet) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.17 Application Layer: sonstige Protokolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.18 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.19 Weiterführende Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.20 Übungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

35 35 36 37 37 37 38 38 38 39 39 40 41 42 43 45 45 46 46 48 48 49 50 53 54 55 58 58 60 60 61 63 65 66 67 69 70 73 74 74 74 76

Inhaltsverzeichnis

3

Grundlagen der IT-Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Schutzziele der IT-Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Schwachstellen, Verwundbarkeiten und Co. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Zugriffskontrolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.1 Discretionary Access Control (DAC) . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.2 DAC-Erweiterungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.3 MAC und DAC: Das Bell-LaPadula-Modell. . . . . . . . . . . . . . . . . . . . 3.5 Authentifizierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6 Privatsphäre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6.1 Anonymität und Pseudonymität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6.2 Verkettbarkeit und Verfolgbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6.3 Überwachung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7 Schadsoftware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7.1 Arten von Schadsoftware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7.2 Schadsoftware-Mechanismen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.8 IT-Sicherheit: ein Trade-off samt Vorschriften . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.9 Science of Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.10 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.11 Weiterführende Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.12 Übungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Teil II 4

XI

79 79 83 84 85 86 86 87 89 91 91 92 93 95 95 98 99 100 101 101 102 102

Kryptografie

Einführung in die Kryptografie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Einführung und Grundbegriffe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Grundlegende Begriffe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 Verschlüsselung und Entschlüsselung als Abbildungen . . . . . . . . 4.2.2 Kryptografische Schlüssel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.3 Kryptosysteme. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.4 Symmetrische und Asymmetrische Kryptografie . . . . . . . . . . . . . . . 4.2.5 Grundlegendes Angreifermodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Historische Verfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1 Transpositionschiffre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.2 Die Caesar-Chiffre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.3 Die Vigenère-Chiffre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.4 Die Vernam-Chiffre (One-Time-Pad) . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 Kryptoanalyse für historische Chiffren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.1 Skytale-Chiffre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.2 Caesar-Chiffre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.3 Kryptoanalyse der Vigenère-Chiffre . . . . . . . . . . . . . . . . . . . . . . . . . . . .

107 107 109 109 110 111 111 112 113 113 113 115 115 116 116 116 118

XII

Inhaltsverzeichnis

4.4.4 Kryptoanalyse der Vernam-Chiffre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.5 Weitere Anmerkungen zu historischen Chiffren . . . . . . . . . . . . . . . . 4.5 Stromchiffren und Zufallszahlengeneratoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.1 Zufallszahlengeneratoren (PRNG) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.2 Der RC4-Algorithmus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.3 Die A5/1- und A5/2-Algorithmen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6 Blockchiffren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.1 Der Data Encryption Standard (DES) . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.2 Der Advanced Encryption Standard (AES) . . . . . . . . . . . . . . . . . . . . . 4.6.3 Blockchiffren-Betriebsmodi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7 Informationstheorie und Kryptografie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7.1 Grundzüge der Informationstheorie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7.2 Informationstheorie in der Kryptografie . . . . . . . . . . . . . . . . . . . . . . . . 4.7.3 Redundanz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7.4 Sicherheit eines Kryptosystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7.5 Spurious Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7.6 Unizitätsdistanz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.8 Kryptografische Hashfunktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.8.1 Einweg-Hashfunktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.8.2 Kollisionsresistenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.8.3 Geburtstagsangriff und Substitutionsattacke . . . . . . . . . . . . . . . . . . . . 4.8.4 Hashwertlänge im Kontext von Angriffen . . . . . . . . . . . . . . . . . . . . . . 4.8.5 Wörterbuchangriff (Brute-Force-Angriff) . . . . . . . . . . . . . . . . . . . . . . . 4.8.6 Hashwerttabellen und Regenbogentabellen . . . . . . . . . . . . . . . . . . . . . 4.8.7 Sicherheit von Hashfunktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.8.8 Aufbau einer typischen Hashfunktion . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.8.9 Message Authentication Codes (MAC) . . . . . . . . . . . . . . . . . . . . . . . . . 4.8.10 Hashfunktionen und Unix-Passwortdateien . . . . . . . . . . . . . . . . . . . . . 4.8.11 Hashfunktionen und Filesystem Intrusion Detection . . . . . . . . . . . 4.8.12 Hashfunktionen und Software Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.8.13 Hashfunktionen und Hashbäume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.9 Asymmetrische Kryptografie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.9.1 Schlüsselaustausch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.9.2 Rivest-Shamir-Adleman-Algorithmus (RSA). . . . . . . . . . . . . . . . . . . 4.10 Digitale Signaturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.11 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.12 Weiterführende Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.13 Übungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

120 120 121 121 122 123 124 125 130 132 133 134 137 138 138 139 140 141 141 142 143 144 145 145 148 148 149 150 150 151 152 152 153 155 157 157 158 159 162

Inhaltsverzeichnis

5

Weiterführende Themen der Kryptografie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Public Key Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.1 Digitale Zertifikate und PKI-Bestandteile. . . . . . . . . . . . . . . . . . . . . . . 5.2.2 Vertrauensmodelle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3 Virtuelle Private Netzwerke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.1 IPSec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.2 Transport Layer Security (TLS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4 Anonymität und Onion-Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4.1 Grundzüge der Mixe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4.2 Angriffe gegen Anonymisierungssysteme . . . . . . . . . . . . . . . . . . . . . . 5.5 Visuelle Kryptografie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.6 Secure Multi-Party Computation und homomorphe Verschlüsselung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.6.1 Dining Cryptographers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.7 Geteilte Geheimnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.8 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.9 Weiterführende Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.10 Übungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

XIII

165 165 166 166 168 171 172 177 179 179 181 181 182 183 183 184 185 185 186

Teil III Netzwerksicherheit 6

Einführung in die Netzwerksicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Angriff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.1 Scanning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.2 Wireless Wardriving. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.3 Protocol Fuzzing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.4 Sniffer und Promiscuous Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.5 Man-in-the-Middle- und Spoofing-Angriffe . . . . . . . . . . . . . . . . . . . . 6.2.6 Redirects (Routing-Angriffe) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.7 Denial-of-Service (DoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.8 Exploits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.9 Social Engineering und Advanced Persistent Threats . . . . . . . . . . 6.3 Verteidigung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.1 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.2 Intrusion Detection und Prevention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.3 Honeypots und Honeynets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

191 191 191 192 192 192 193 193 194 195 196 197 198 198 199 202

XIV

7

Inhaltsverzeichnis

6.3.4 Sandboxing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.5 Threat Intelligence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.5 Weiterführende Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.6 Übungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

204 204 205 206 206 207

Angriffe auf TCP/IP-Netzwerkprotokolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 Angriffe auf der Netzzugangsschicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.1 Angriffe mit physikalischer Grobeinwirkung . . . . . . . . . . . . . . . . . . . 7.2.2 Jamming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.3 Eavesdropping (Sniffing) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.4 Falsche Access Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.5 Sicherheit von ARP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3 Angriffe auf der Internetschicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.1 Reconnaissance (Aufklärung) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.2 IP-Spoofing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.3 Denial-of-Service-Angriffe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.4 Angriffe auf Basis von IP-Fragmenten . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.5 Grundlegende Angriffe auf das IP-Routing . . . . . . . . . . . . . . . . . . . . . 7.3.6 Weitere Anmerkungen zur Sicherheit von IPv6 . . . . . . . . . . . . . . . . 7.3.7 Sicherheit von ICMPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4 Angriffe auf der Transportschicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4.1 Sicherheitsaspekte von UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4.2 Sicherheit von TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4.3 Portscans mit TCP und UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5 Angriffe auf der Anwendungsschicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5.1 Anmerkungen zur Reconnaissance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5.2 HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5.3 DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5.4 E-Mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5.5 Telnet, R-Dienste und SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5.6 NNTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5.7 FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5.8 Sonstige historische Dienste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5.9 Zusammenspiel mehrerer Protokolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.6 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.7 Weiterführende Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.8 Übungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

209 209 210 210 210 210 211 212 214 214 217 218 220 221 224 224 225 225 226 227 230 230 231 232 234 235 236 236 238 238 238 239 239 241

Inhaltsverzeichnis

8

Absicherung der Netzwerkschichten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2 Absicherung auf der Netzzugangsschicht. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2.1 Zutrittskontrolle und physikalischer Netzwerkzugang . . . . . . . . . 8.2.2 Erwerb and Integration von Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2.3 Verfügbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2.4 Komponentenverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2.5 MAC-Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2.6 Denial-of-Serivce-Eindämmung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2.7 Virtuelle LANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2.8 Absicherung des ARP-Caches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2.9 IEEE 802.1X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2.10 WLAN-Verschlüsselung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3 Absicherung auf der Internetschicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.1 Härtung des IPv4/IPv6-Stacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.2 Firewalls für die IP-Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.3 SEND: Secure Neighbor Discovery Protocol . . . . . . . . . . . . . . . . . . . 8.4 Absicherung der Transportschicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.4.1 Firewalls und Angriffserkennung für TCP und UDP . . . . . . . . . . . 8.4.2 Portscan-Detektion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.4.3 TCP-Härtung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.5 Absicherung der Anwendungsschicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.5.1 Generelle Anmerkungen zur Anwendungsschicht. . . . . . . . . . . . . . 8.5.2 Proxyserver und Co. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.5.3 HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.5.4 DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.5.5 E-Mail-Protokolle: SMTP, IMAP und POP3 . . . . . . . . . . . . . . . . . . . 8.5.6 NNTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.6 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.7 Weiterführende Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.8 Übungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

XV

243 243 243 244 244 245 246 247 247 248 249 250 250 251 252 252 253 254 254 256 257 258 258 261 264 265 266 268 269 270 270 271

Teil IV Vertiefung 9

Netzwerksteganografie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.2 Methoden der Netzwerksteganografie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.2.1 Grundlegende Taxonomie. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.2.2 Versteckmuster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.2.3 Spezifische Versteckmethoden. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

275 275 278 278 279 282

XVI

10

Inhaltsverzeichnis

9.3

Gegenmaßnahmen zur Netzwerksteganografie . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.3.1 Detektion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.3.2 Limitierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.3.3 Unterbindung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.4 Exkurs: Linguistische Steganografie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.6 Weiterführende Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.7 Übungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

284 286 288 289 290 291 292 292 293

Sicherheit im Internet der Dinge. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2 Schuld sind die anderen – der Cycle of Blame . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.3 Standardisierung (und Zertifizierung) im IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.4 Patching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.5 Smart Homes und Smart Buildings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.5.1 Kommunikationsprotokolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.5.2 Angriffe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.5.3 Angriffsdetektion und Härtung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.6 Industriesteueranlagen (Industrial Control Systems) . . . . . . . . . . . . . . . . . . . . . 10.6.1 Angriffe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.6.2 Angriffsdetektion und Härtung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.7 Stand der Verwendung von Kryptografie IoT-Protokollen . . . . . . . . . . . . . . . 10.8 Generische IoT-Protokolle der Anwendungsschicht . . . . . . . . . . . . . . . . . . . . . 10.8.1 CoAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.8.2 MQTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.9 IT-Sicherheit weiterer IoT-Domänen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.9.1 Mobile IoT-Systeme (Smart Cars und Co.) . . . . . . . . . . . . . . . . . . . . . 10.9.2 Electronic Healthcare (eHealth) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.9.3 Landwirtschaft. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.9.4 Legacy-Equipment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.10 Digitale Forensik für das IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.11 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.12 Weiterführende Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.13 Übungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

295 295 301 303 305 306 307 308 310 312 313 314 316 319 319 324 325 325 326 327 328 329 331 332 332 333

Anhang A: Wichtige wissenschaftliche Zeitschriften und Tagungen . . . . . . . . . . . . . 339 Sachverzeichnis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343

Abkürzungsverzeichnis

ACL AES AH APT ARP ARS BACnet BAN BAS BFR BLP BSC BSI CA CA CARP CBC CCM CFM CGA CoRE CPS CS CSMA CSMA/CA CSMA/CD CTR CUING DAC DDC DEA

Access Control List Advanced Encryption Standard Authentication Header Advanced Persistent Threat Address Resolution Protocol Anti Replay Service Building Automation Control Networks Body Area Network Building Automation System BACnet Firewall Router Bell-LaPadula-Modell Binary Symmetric Channel Bundesamt für Sicherheit in der Informationstechnik Collision Avoidance Certificate Authority Common Address Redundancy Protocol Cipher Block Chaining Counter with CBC-MAC Cipher Feedback Mode Cryptographically Generated Address Constrained RESTful Environments (Link Format) Cyber-physical System Carrier Sense Carrier Sense Multiple Access CSMA/Collision Avoidance CSMA/Collision Detection Counter Mode Criminal Use of Information Hiding (Initiative) Discretionary Access Control Direct Digital Control Data Encryption Algorithm XVII

XVIII

DES DH DHM DNS EAP ECB ECN ECU EDC EIB ESP FDDI FTP GCM GMAC GNU GnuPG GPS GSM HAS HIDS HMI HSRP HTTP ICMP ICS ICT ICV IDS IGMP IKE IoT IP(v4) IPS IPv6 IRC ISN KNX LAN LTE MA MAC

Abkürzungsverzeichnis

Data Encryption Standard Diffie-Hellman Diffie-Hellman-Merkle Domain Name System Extensible Authentication Protocol Electronic Code Book Explicit Congestion Notification Electronic Control Unit Error Detection & Correction European Interface Bus Encapsulating Security Payload Fiber Distributed Data Interface File Transfer Protocol Galois/Counter Mode Galois Message Authentication Code GNU is Not Unix (rekursives Akronym) GNU Privacy Guard Global Positioning System Global System for Mobile Communications Home Automation System Host-based Intrusion Detection System Human Machine Interface Hot Standby Router Protocol Hyper-text Transfer Protocol Internet Control Message Protocol Industrial Control System Information and Communication Technology Integrity Check Value Intrusion Detection System Internet Group Management Protocol Internet Key Exchange Internet of Things Internet Protocol, version 4 Intrusion Prevention System Internet Protocol, version 6 Internet Relay Chat Initial Sequence Number (für das TCP-Protokoll) Konnex Local Area Network Long-Term Evolution Multiple Access Medium Access Control

Abkürzungsverzeichnis

MIME MitM MLS NIDS NRU NTP NWD OFM OSI OTP PAC PC PCAW PDoS PGP PHB PHCC PLC PSCC PSK PRNG RARP RBAC RC4 RFC RIP RNG RSA RTP RTU SA SBB SCADA SDP SEND SIP SMC SNMP SOA

Message Authentication Code Mandatory Access Control Multipurpose Internet Mail Extensions Man-in-the-Middle Multilevel Security Network Intrusion Detection System No Read-up Network Time Protocol No Write-down Output Feedback Mode Open Systems Interconnected One-time Pad One-time Password Physical Access Control Protocol Channel Protocol (Switching Covert) Channel-aware Active Warden Permanent Denial-of-Service Pretty Good Privacy Per-hop Behavior Protocol Hopping Covert Channel Programmable Logic Controls Protocol Switching Covert Channel Pre-shared Key Pseudo Random Number Generator Reverse Address Resolution Protocol Role-based Access Control Ron’s Code 4 Request for Comments Routing Information Protocol Random Number Generator Rivest, Shamir and Adleman Real-time Transport Protocol Remote Terminal Unit Security Association Smart Building Botnet Supervisory Control And Data Acquisition Session Description Protocol Secure Neighbor Discovery Session Initiation Protocol Secure Multi-Party Computation, auch mit SPMC abgekürzt Simple Network Management Protocol Start of Authority

XIX

XX

SPMC SPI SRTP TCP TCPCT TLD TTL UDP USV UUCP VCS VLAN VoIP VoLTE VRRP WEP WFP WPA XCBC XMPP

Abkürzungsverzeichnis

Secure Multi-Party Computation, auch mit SMC abgekürzt Security Parameter Index Secure Real-time Transport Protocol Transmission Control Protocol TCP Cookie Transactions Top-level Domain Time to Live User Datagram Protocol Unterbrechungsfreie Stromversorgung Unix-to-Unix-Copy Visual Crypto System Virtual Local Area Network Voice over IP Voice over LTE Virtual Router Redundancy Protocol Wired Equivalent Privacy Website Fingerprinting Wi-Fi Protected Access Extended CBC Extensible Messaging and Presence Protocol

1

Einführung

Unfortunately, many journalists and writers have been fooled into using the word ,hacker‘ to describe crackers; this irritates real hackers no end. The basic difference is this: hackers build things, crackers break them. – Eric Steven Raymond (2017)

Zusammenfassung

Dieses Kapitel führt in die Thematik des Buches ein und motiviert die Auseinandersetzung mit der Thematik. Es gibt ferner einen Überblick über die einzelnen Kapitel.

1.1

Motivation

Egal, ob Sie studieren, Freizeit-Autodidakt sind oder sich des Berufes wegen mit der Thematik dieses Buches auseinandersetzen. Egal, ob Sie Anwender, Spezialist oder Wissenschaftler sind. Unsere Gesellschaft befindet sich seit einigen Jahrzehnten im digitalen Umbruch, der uns alle betrifft. In den vergangenen zehn Jahren stieg die Bedeutung der digitalen Infrastruktur, insbesondere der Netzwerke, kontinuierlich an. Künstliche Intelligenz, Automation sowie die Fähigkeit, IT-Technologie anzuwenden und zu modifizieren, sind treibende Kräfte, die mit beeinflussen, welche geografischen Regionen florieren und welche destabilisiert werden oder unter einem Brain-Drain leiden werden [1, 2]. Doch ohne verlässliche, sichere Netzwerke können diese Technologien nicht problemfrei betrieben, angepasst und weiterentwickelt werden. Dies gilt für das Internet der Dinge nicht weniger als für traditionelle Netzwerke. Dieses Buch verfolgt den Anspruch, Ihnen das Kenntnis- und Verständnisfundament für diese Thematik zu liefern.

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2018 S. Wendzel, IT-Sicherheit für TCP/IP- und IoT-Netzwerke, https://doi.org/10.1007/978-3-658-22603-9_1

1

2

1 Einführung

Es enthält viele Verweise auf weiterführende Literatur sowie Übungsaufgaben, die den Lernprozess unterstützen.

1.2

Kapitelüberblick

Im ersten Teil dieses Buches befassen wir uns zunächst mit den Grundlagen der Netzwerktechnik (Kap. 2). Betrachtet werden dabei insbesondere die wichtigsten Protokolle der TCP/IP-Welt: ARP, IPv4, IPv6, ICMPv4, ICMPv6, TCP, UDP sowie einige Protokolle der Anwendungsschicht, vornehmlich DNS, HTTP und einige E-Mail-Protokolle. Kap. 3 führt anschließend in die Grundbegriffe und Konzepte der IT-Sicherheit ein. Es setzt sich mit dem Thema der Authentifizierung, der Zugriffskontrolle, den Grundlagen der Privatsphäre und mit Schadsoftware auseinander. Außerdem erläutert es, weshalb IT-Sicherheit immer mit einem Trade-off verbunden ist und betrachtet die Wissenschaftlichkeit von ITSicherheit. Leser, die sich bereits mit den Grundlagen der Netzwerke und der IT-Sicherheit befasst haben, können diesen Teil des Buches überspringen und bei Bedarf auf ihn zurückgreifen. Der zweite Teil zum Thema Kryptografie beginnt mit einem Grundlagenkapitel, das fast alle für dieses Buch wichtigen Themen der Kryptografie erläutert. Beginnend mit den grundlegenden Konzepten wie kryptografische Schlüssel und kryptografische Funktionen befasst sich das Kapitel anschließend mit historischen Chiffren und ihrer Sicherheit, da durch das Studium historischer Verfahren viel über moderne Verfahren gelernt werden kann. Anschließend werden wichtige Strom- und Blockchiffren, Hashfunktionen und Methoden der asymmetrischen Kryptografie betrachtet. Angewandte Themen der Kryptografie, nämlich Public Key Infrastructure, Virtuelle Private Netzwerke, Anonymität und Onion Routing sowie einige Spezialthemen, etwa verteilte Geheimnisse und visuelle Kryptografie, finden sich in Kap. 5. Teil drei des Buchs befasst sich mit der Netzwerksicherheit und baut auf den Grundlagen der ersten zwei Teile auf. Zunächst führt Kap. 6 in die wichtigsten Angriffstechniken und Verteidigungsmethoden für Netzwerke ein. Detailliert werden Angriffstechniken anschließend in Kap. 7, das sich mit jeder Schicht des TCP/IP-Modells separat befasst. Das Gegenstück zu Kap. 7 bietet Kap. 8: Es befasst sich schichtenweise mit der Sicherung der Netzwerkkommunikation. Sowohl Kap. 7 als auch Kap. 8 legen einen besonderen Fokus auf die jeweils eingesetzten Netzwerkprotokolle. Schließlich befasst sich der vierte Teil des Buches mit Vertiefungsthemen der Netzwerksicherheit. Kap. 9 führt zunächst in die Grundlagen der Netzwerksteganografie ein, beginnend mit der Terminologie und Taxonomie bis hin zu Verstecktechniken und einem Überblick über Möglichkeiten der Detektion, Limitierung und Verhinderung verdeckter Kommunikation. Eine ausführliche Betrachtung des Internet of Things liefert Kap. 10. Zunächst werden generelle Aspekte der IT-Sicherheit für das Internet of Things betrachtet und im Anschluss spezifische Gebiete im Detail betrachtet, nämlich Smart Buildings und Industriesteueranlagen. Die Sicherheit von Kommunikationsprotokollen in Automa-

Literatur

3

tionsumgebungen und von typischen Protokollen des Internet of Things wird ebenfalls betrachtet. Das Kapitel schließt mit einer Einführung in die digitale Forensik für das Internet of Things. Im Anhang findet sich eine Liste bedeutsamer Fachzeitschriften und Fachtagungen aus dem Bereich der Netzwerk- und Internet-of-Things-Sicherheit. Es lohnt sich, periodisch einen Blick in derlei Organe zu werfen, da sie bereits in der Vergangenheit immer wieder bedeutsame Beiträge zur IT-Sicherheit lieferten und den jeweils aktuellen Stand der Forschung adressieren. Viele der im Buch verwendeten Quellen stammen aus diesen Fachzeitschriften und -tagungen.

1.3

Für wen dieses Buch geschrieben wurde

Dieses Buch wurde so verfasst, dass ein breites Spektrum interessierter Personen von ihm profitieren kann, sowohl Praktiker, als auch Theoretiker. Vom Experten, der sich für einzelne Kapitel interessiert, bis hin zum Auszubildenden, der eine verständliche Einführung in die Thematik sucht, möchte es jedem Leser interessante Inhalte bieten. Für akademische Leser zu praktische Inhalte (etwa Details zu Konfigurationsdateien von Diensten) und für Professionals zu wenig bedeutsame (etwa stark mathematische/formale) Inhalte wurden, wann immer es möglich war, ausgelassen.

1.4

Über den Autor

Steffen Wendzel ist Professor für IT-Sicherheit und Netzwerke an der Hochschule Worms. Nach seiner Promotion leitete er ein Forschungsteam am Fraunhofer FKIE in Bonn und befasste sich während dieser Zeit mit der IT-Sicherheit von Smart Buildings. Seine Forschungsarbeiten wurden in der nationalen und internationalen Presse besprochen. Steffen Wendzel veröffentlichte über 120 Werke, darunter sechs Fachbücher sowie diverse Tagungs- und Fachzeitschriftenbeiträge. Die Webseite des Autors ist unter der Adresse http://www.wendzel.de zu finden.

Literatur 1. Ross, A.: The Industries of the Future. How the Next 10 Years of Innovation Will Transform Our Lives at Work and Home. Simon & Schuster, London (2016) 2. Frey, C.B.: Und tschüss, Mitarbeiter! DIE ZEIT Ausgabe 5 (2018)

Teil I Grundlagen

Dieser Teil führt Sie in die Grundlagen der Netzwerktechnik und in die Grundlagen der IT-Sicherheit ein. Er dient als Fundament für das Verständnis der folgenden Kapitel. Wenn Sie sich bereits mit diesen Themen befasst haben, dann können Sie diesen Teil des Buches überspringen und Einzelheiten bei Bedarf nachlesen.

2

Grundlagen der Netzwerktechnik

Today more than ever before, networking is a hot topic. – Christian Benvenuti (2006)

Zusammenfassung

Dieses Kapitel befasst sich mit den Grundlagen der Netzwerktechnik. Insbesondere werden dabei selektierte Aspekte betrachtet, die zum Verständnis des restlichen Buches notwendig sind. Sie erhalten ein Verständnis für die Funktionsweise und die Fähigkeiten von diversen Netzwerkprotokollen. Zum einen ist dies notwendig, um Angriffe zu verstehen. Zum anderen, damit Schutzmechanismen nachvollziehbar sind.

2.1

Einführung

Um1 die in den nächsten Kapiteln fokussierten Aspekte verstehen zu können, liefert Ihnen dieses Kapitel zunächst eine Einführung in die Grundlagen der Netzwerktechnik. Das Kapitel konzentriert sich dabei primär auf TCP/IP, da sich ein Großteil der Netzwerksicherheit auf TCP/IP konzentriert und TCP/IP in den folgenden Kapiteln immer wieder aufgreifen wird. Für den Fall, dass Sie sich bereits mit TCP/IP auskennen, können Sie dieses Kapitel überspringen oder einzelne Abschnitte im Bedarfsfall nachlesen.

An dieser Aussage hat sich in den letzten zwölf Jahren nichts geändert; dies gilt auch für die anderen historischen Zitate, die Sie in diesem Buch finden werden. 1 Einige Inhalte dieses Kapitels basieren auf meinem Buch Tunnel und verdeckte Kanäle im Netz (Springer-Vieweg, 2012) [29]. Sie wurden für dieses Buch grundlegend überarbeitet, korrigiert und aktualisiert. © Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2018 S. Wendzel, IT-Sicherheit für TCP/IP- und IoT-Netzwerke, https://doi.org/10.1007/978-3-658-22603-9_2

7

8

2 Grundlagen der Netzwerktechnik

Kommunikation kann als eine der zentralen Notwendigkeiten (moderner) Gesellschaften betrachtet werden. Rechnernetze (Computernetzwerke2 ) dienen dabei der Kommunikation von elektronischen Daten (Datenkommunikation) über physikalische Medien. Sie verbinden Computer (beliebiger Art) miteinander. Übertragen werden dabei Inhalte jedweder Art über unterschiedlichste Distanzen; sie können im Bereich von Zentimetern (Kreditkarte ↔ Kartenleser) oder Millionen von Kilometern (Erde ↔ Voyager) liegen. Rechnernetze benutzen verschiedenste Medien mit unterschiedlichen Eigenschaften (dies betrifft etwa die Datenrate und die Störanfälligkeit eines Mediums) zur Übertragung von Daten. Dabei kann es sich zum Beispiel um eine Funkverbindung, ein Kupferkabel oder eine Glasfaser-Verbindung handeln. Computer, die mit einem Netzwerk arbeiten sollen, benötigen entsprechend eine Netzwerkkarte, eine Verbindung zum Netzwerk über diese Netzwerkkarte (per Kupferkabel, Funk, . . . ) und ein netzwerkfähiges Betriebssystem. Netzwerke unterscheiden sich in ihrer Reichweite, ihrer Topologie, Architektur, der ermöglichten Kommunikationsrichtungen und -relationen sowie weiterer Attribute.

2.1.1

Reichweite von Netzwerken

Netzwerke können unterschiedliche Reichweiten aufweisen. Sogenannte Body Area Networks (BANs) sind nur im Bereich weniger Zentimeter bis etwa zwei Meter im Einsatz und werden beispielsweise bei Wearables, also tragbaren, oftmals in die Kleidung integrierten Computern verwendet. Local Area Networks (LANs) sind Netzwerke innerhalb eines Unternehmens beziehungsweise einer Organisation oder auch einer Wohnung/eines Hauses. Metropolitain Area Networks (MAN) sind bereits Netze, die sich über eine ganze Stadt ziehen können. Sie können etwa die Kommunikationsbasis zwischen den auf eine Stadt verteilten Gebäuden einer Hochschule darstellen. Wide Area Networks (WAN) kennen wiederum keine geografische Beschränkung und sind Netzwerke, die über die Grenzen einer Stadt oder Region hinausgehen. Ein WAN kann auch länder- und kontinentübergreifend sein. Das größte WAN – das Internet – umfasst den gesamten Globus sowie angrenzende Teile des Weltraums (Satelliten). Verbindungen mit höherer Distanz gibt es nur zu einigen Raumsonden.

2 Es gibt auch Netzwerke, die keine Computernetze sind, etwa Telegrafen-Netzwerke oder das

Turnschuhnetzwerk von Tanenbaum [27], das heißt Daten werden (etwa auf USB-Sticks) „zu Fuß“ übertragen, statt über ein Computernetzwerk.

2.1 Einführung

2.1.2

9

Netzwerktopologien

Topologien beschreiben die Struktur eines Netzwerks. Grundlegend unterscheidet man zwischen Punkt-zu-Punkt-, Bus-, Ring-, Stern- und Mesh-Topologie (siehe Abb. 2.1). Die Punkt-zu-Punkt-Topologie ist die einfachste. Es gibt genau eine direkte Verbindung zwischen zwei Computern (auch Knoten oder Nodes genannt). Bei der Bus-Topologie führt ein zentrales Kabel zu allen Knoten. Neue Knoten werden gesondert und einzeln an dieses Kabel angeschlossen. Die Enden der Buslinien müssen terminiert werden (dadurch wird das Kommunikationssignal terminiert). Anders ist dies bei der Ring-Topologie. Jeder Knoten besitzt genau einen linken und einen rechten Nachbarn. Über diese Nachbarknoten ist jeder Knoten indirekt mit weiteren Knoten verbunden. Nachrichten werden jeweils weitergeleitet. Bei der Stern-Topologie besitzt jeder Knoten eine separate Verbindung zu einer zentralen Verteilereinheit (etwa ein Hub oder Switch). Diese Topologieform findet sich in einem Großteil der heutigen Netzwerke. In Mesh-Netzwerken kooperieren alle Knoten eines Netzwerks bei der Zustellung von Daten. Nachrichten werden entweder durch Flutung (Flooding, das heißt Weiterleiten an alle bekannten Nachbar-Knoten eines Knotens, außer dem, von der die Nachricht empfangen wurde) oder durch Routing (gezieltes Weiterleiten) zugestellt. Derartige Netze sind oftmals hochgradig dynamisch. So werden sie etwa zwischen fahrenden Autos spontan aufgebaut und sind entsprechend einer permanenten Veränderung unterworfen. Ebenfalls ist es machbar, mobile Mesh-Netzwerke zwischen Drohnen aufzubauen.

Abb. 2.1 Klassische Netzwerktopologien: (a) Punkt-zu-Punkt-, (b) Bus-, (c) Ring-, (d) Stern-, (e) Mesh-Topologie

10

2.2

2 Grundlagen der Netzwerktechnik

Datenpakete, Einkapselung und die Entwicklung von TCP/IP

Daten werden in Netzwerken in Form von Paketen oder Frames, das sind Einheiten einer definierten Größe und Struktur, übertragen. In diesen Paketen werden sowohl Steuerinformationen, als auch die eigentlichen Nutzdaten übertragen. Steuerinformationen (auch Metadaten) regeln und beschreiben die Netzwerkkommunikation. Sie legen etwa fest, welcher Knoten der Sender und welcher Empfänger eines Pakets ist oder wie viele Nutzdaten in einem Paket enthalten sind. Nutzdaten stellen aus Benutzersicht die eigentlichen Daten dar. Es handelt sich dabei etwa um Daten eines Downloads, einer Webseite, eines Videostreams oder einer Sprachübertragung. Auch der Inhalt einer E-Mail stellt Nutzdaten dar. Damit verschiedene Computer sich gegenseitig „verstehen“ können, müssen sie dieselbe „Sprache“ sprechen, denn sonst wüsste Computer A nicht, wie die Daten, die Computer B über das Netz an ihn sendet, zu interpretieren sind und wie auf diese Daten zu antworten ist. Geregelt werden die Kommunikationsabläufe und die Aufbauten der Datenpakete daher durch sogenannte Kommunikationsprotokolle. TCP/IP stellt eine Suite solcher Protokolle dar. Diese Protokollsuite ist das Resultat der ursprünglich für den militärischen Kontext angedachten Netzwerkprotokolle des ARPANET, dem Vorgänger des heutigen Internets. Die Entwicklung des ARPANET begann 1968 [28]. Die militärische Forschungsförderung ermöglichte damals die Entwicklung der TCP/IP-Protokolle, doch muss auch darauf hingewiesen werden, dass das Internet erst mit seiner Öffnung für den nicht-militärischen Bereich und durch kreative Entwickler der Universitäten und der freien Software Community sowie der privaten Industrie zum großen Erfolg wurde [14, 24]. Tatsächlich beruht ein überraschend großer Anteil der wichtigsten Entwicklungen des Internets auf Hobbyisten und Forschern [24]. Die TCP/IP-Protokolle sind durch sogenannte Request for Comments (RFC) spezifiziert. Zugriff auf jedes veröffentlichte RFC erhalten Sie unter [23]. Die Anzahl der TCP/IP-Protokolle ist mittlerweile relativ beachtlich und ein Großteil dieser Protokolle wurde standardisiert. Die Buchstaben TCP stehen dabei für das Transportprotokoll Transmission Control Protocol, die Buchstaben IP für Internet Protocol. TCP/IP verwendet eine Kommunikationsarchitektur mit mehreren Schichten. Diese Kommunikationsarchitektur ist dabei ähnlich wie das OSI-Modell3 der ISO,4 siehe Abschn. 2.2.1, aufgebaut (Abb. 2.2). Die Systeme, die das OSI-Modell implementieren, werden als Open Systems bezeichnet, da sie anderen Systemen zur Kommunikation „offen“ stehen – schließlich sind die verwendeten Protokolle publiziert und damit nicht geheim [26]. Im Gegensatz dazu wäre ein Closed System eines mit proprietären Netzwerkschnittstellen. Ein Closed System könnte nicht mit andersartigen Systemen kommunizieren. Heute sind primär

3 Open Systems Interconnection Reference Model. 4 International Organization for Standardization.

2.2 Datenpakete, Einkapselung und die Entwicklung von TCP/IP

11

Abb. 2.2 Das TCP/IP- und das OSI-Modell

Open Systems in Verwendung. Egal, ob iPhone, Android, Windows PC, Linux-Server, Supercomputer oder Embedded System: Die meisten Systeme können miteinander kommunizieren. Das OSI-Modell soll derlei offene Systeme, auch wenn sie verschiedenste Netzwerktechnologien einsetzen, miteinander verbinden.

Das oben dargestellte TCP/IP-Modell verwendet, wie auch das gesamte Buch, die englischen Begriffe der einzelnen Protokoll-Schichten (engl. Layer). Das hat ganz einfach den Grund, dass Sie durch Verwendung der englischen Begriffe auch weitere Bücher zum Thema TCP/IP einfacher verstehen werden, weil diese oft in englischer Sprache verfasst sind. Auch verwenden die zugehörigen Standards die englischen Bezeichnungen.

Jeder Layer kommuniziert dabei mit seinem logischen Gegenüber. Der Internet Layer eines Rechners A kommuniziert folglich nur mit dem Internet Layer des Kommunikationspartners B. Die Layer nutzen dabei jeweils die Dienste der unter ihnen liegenden Layer, sodass das Abstraktions-, aber auch das Fähigkeitsspektrum mit jedem Layers ansteigt. Der Vorteil dieses Ansatzes besteht darin, dass verschiedene Layer auch unterschiedliche Aufgaben übernehmen und ein einzelner Layer nicht die Verantwortung über die gesamte Kommunikation übernehmen muss.5 Für den Anwender sind diese Layer völlig transparent, er benötigt lediglich eine Endapplikation, um auf die ihm angebotenen Dienste eines Netzwerks zuzugreifen. Wichtig ist hierbei das Konzept der Einkapselung, wie sie in Abb. 2.3 dargestellt ist: Der Network Access Layer kapselt die Daten des Internet Layers in sich. Der Internet Layer kapselt wiederum die Daten des Transport Layers in sich, der die Daten vom Application

5 Die erste TCP-Implementierung hatte genau diese problematische Eigenschaft. Mittlerweile ist die Arbeitsfunktion von TCP jedoch auf den Transport Layer beschränkt worden.

12

2 Grundlagen der Netzwerktechnik

Abb. 2.3 Einkapselung von Layern in TCP/IP am Beispiel eines HTTP-Pakets

Layer einkapselt, der wiederum die Nutzdaten (Payload) der jeweiligen Anwendung, also etwa Teile einer Bilddatei, enthält. In den folgenden Abschnitten werden das OSI-Modell und die einzelnen Layer des TCP/IP-Modells im Detail betrachtet.

2.2.1

Einige Worte zum OSI-Modell

Das OSI-Referenzmodell hat zwar direkt nicht viel mit der TCP/IP-Suite zu tun, wird aber hin und wieder erwähnt und stellt praktisch eine andere Möglichkeit der Einteilung einer Netzwerkkommunikation in Layer dar, als es beim TCP/IP-Modell der Fall ist. Das OSIModell wurde 1983/84 standardisiert. Bestrebungen zur Entwicklung des Modells gehen allerdings bis in die späten 1970er-Jahre zurück. Die Layer des OSI-Modells sind primär eine andere Betrachtungsweise auf denselben Gegenstand. Genau wie bei den TCP/IP-Layern wird also nur eine logische Sicht auf real arbeitende Protokolle abgebildet. Die Protokolle sind dabei das eigentlich Interessante, und die wichtigste Netzwerkprotokollsuite TCP/IP wird in diesem Kapitel behandelt. Die Erläuterung der Layer wird Ihnen dabei helfen, die Funktionsweise der Protokolle zu verstehen. Der Physical Layer (auch Bitübertragungsschicht genannt) ist für die Zustellung einzelner Bits zuständig. Dabei übernimmt dieser Layer auch die Aufrechterhaltung einer Bitstrom-Verbindung. Außerdem gibt es den Datalink Layer (Sicherungsschicht). Auf dem Datalink Layer werden Datenüberprüfung und -korrektur sowie eine grundlegende Flusskontrolle durchgeführt. Physical Layer und Datalink Layer konzentrieren sich ausschließlich auf die Kommunikationsverbindung zwischen zwei direkt miteinander verbundenen Systemen, also etwa die Übertragung der Daten eines Smartphones zu einem WiFi-Router.

2.3 Grundzüge des TCP/IP-Modells

13

Der Network Layer ist hingegen für die Zustellung von Daten zwischen den Verbindungsendpunkten zuständig, also etwa die Zustellung der Daten eines Smartphones über mehrere Router hinweg zu einem Zielsystem (etwa dem Server einer Suchmaschine). Der nächsthöhere Layer (Transport Layer) hat die Aufgabe, Daten für die nächsthöheren Layer transparent zu übertragen. Dies umfasst die Aufteilung von Daten in übertragbare Teile, das erneute Senden verlorengegangener Teildaten und das Sortieren von empfangenen Daten beim Empfänger. Auch laufen auf dem Transport Layer Funktionen zur Fehlerkorrektur ab. Auf dem Session Layer werden Aufbau und Abbau von Sitzungen (etwa bei TLS) sowie deren Aufrechterhaltung abgewickelt. Außerdem kümmert sich diese Schicht etwa um das Festlegen von Synchronisationspunkten und die Administration des Senderechtes. Die Unterteilung von Application Layer und Presentation Layer hat zur Folge, dass der Application Layer zwar ähnliche Aufgaben wie im TCP/IP-Modell übernimmt, jedoch Aufgaben, die die Datendarstellung betreffen, in den Presentation Layer ausgegliedert werden (er kümmert sich etwa um die Festlegung eines Zeichensatzes und um die Darstellung von Gleitkomma-Werten).

2.2.2

OSI- vs. TCP/IP-Modell

Piscitello und Chapin weisen darauf hin, dass die TCP/IP-Entwicklungen das Design des OSI-Modells stark beeinflusst haben (und vice versa). Beide Modelle würden zudem an Acronymania (der intensiven Verwendung von Abkürzungen) leiden und würden teils unterschiedliche Begrifflichkeiten verwenden, um dasselbe zu bezeichnen [16]. Die Komplexität der sieben Schichten des OSI-Modells (und die damit verbundenen Kosten zur Integration eines solchen Modells) sowie die freie Zugänglichkeit der TCP/IPStandards haben maßgeblich zum Erfolg von TCP/IP beigetragen, das für die Mehrzahl der Netzwerkprotokolle ab der Vermittlungsschicht aufwärts das wichtigere Modell darstellt [28] und deshalb auch den Orientierungsrahmen für das vorliegende Buch liefert.

2.3

Grundzüge des TCP/IP-Modells

Im Folgenden werden die einzelnen Layer des TCP/IP-Modells besprochen, beginnend mit dem untersten.

2.3.1

Link Layer

Dieser Layer ist eine Zusammenfassung des Physical Layers und des Data Link Layers aus dem OSI-Modell. Er hat die Aufgabe, die einzelnen Bits über ein physikalisches Medium zum nächsten Netzwerkrechner (eines Netzwerkpfades) zu übertragen. Dies könnte zum

14

2 Grundlagen der Netzwerktechnik

Beispiel ein Crossover-Kabel sein, das an einer handelsüblichen Ethernet-Netzwerkkarte angeschlossen ist. Diese physikalischen Verbindungen werden als Links bezeichnet und ein Layer-2-Gerät wird wiederum als Node bezeichnet. Typische Nodes des Link Layers sind: • Repeater: Signale (egal ob per Funk oder über Kabel) erreichen nicht immer vollständig und in ausreichender Qualität ihr Ziel. Manchmal sind Empfänger der Signale einfach zu weit entfernt, sodass das Signal beim Empfänger zu schwach wird. Repeater verstärken das Signal, damit es sein Ziel dennoch erreichen kann. Im Heimeinsatz finden sich bei größeren Wohngebäuden beispielsweise oft WLAN-Repeater. • Hubs: Repeating Hubs (auch: Multiport-Repeater) dienen der sternförmigen Verkabelung von Hosts in Netzen. Daten, die an einem Netzwerkport eines Hubs eintreffen, werden an sämtliche andere Ports weitergeleitet. • Switch: Switche analysieren die Daten, die an einem Port eintreffen. Sie überprüfen anhand der Zieladresse der Daten, an welchen Port sie weitergeleitet werden müssen. Entsprechend müssen Hosts im Netzwerk, an die bestimmte Daten nicht gerichtet sind, keine Rechenleistung aufwenden, um diese Daten zu verwerfen (das heißt, um zu überprüfen, ob sie überhaupt der Empfänger sind), da der Switch diese Arbeit abnimmt. Broadcast-Nachrichten werden dennoch an alle Teilnehmer des Netzes versendet (das heißt an alle Ports). Welche Hostadresse zu welchem Port gehört, lernt der Switch selbständig durch die permanente Überwachung des Netzwerks. Er speichert die gelernten Informationen in einer Tabelle. Manche Switche können Daten einer höheren Schicht verstehen und filtern. Sie unterstützten zudem Managementfunktionen für das Netzwerk, etwa das Bilden von Teilnetzen (sogenannte Virtual LANs, VLANs, die in späteren Kapiteln noch besprechen werden). Auf diesem Layer kommunizieren die Systeme in Form von Frames. Typische Medien sind neben Ethernet auch Wireless-LAN, Glasfaser-Verbindungen (FDDI) oder ISDNVerbindungen. Entsprechend wird von Ethernet-Frames, FDDI-Frames usw. gesprochen. Zu den Diensten des Link Layers gehören insbesondere das Framing, das ist die Einkapselung der Protokolle des Internet Layers in eine Frame und die Zustellung der Daten an nächste Node. Weiterhin kümmert sich diese Schicht um den Link-Zugriff, auch Medium Access Control (MAC) genannt. Dabei handelt es sich um Zugriffsverfahren, die regeln, wann welcher Node für wie lang über ein Medium senden darf. Eine weitere Aufgabe dieser Schicht ist das fehlerfreie Übertragen von Daten und die damit verbundene Detektion von Fehlern (Error Detection & Correction, EDC).

2.3.1.1 Error Detection and Correction Ein Grundmodell für die Übertragung von Daten liefert die Informationstheorie. Sie beschreibt, in welchen Schritten Daten über einen Kommunikationskanal übertragen werden können (Abb. 2.4).

2.3 Grundzüge des TCP/IP-Modells

15

Abb. 2.4 Modell für einen Kanal

Abb. 2.5 Der binärsymmetrische Kanal (BSC)

Nachrichten werden aus einer Nachrichtenquelle gesendet (etwa der Text ‘HALLO’ in einem Chat von einem Benutzer). Danach werden die Informationen, die übertragen werden sollen, durch einen Quellenkodierer verdichtet, das heißt komprimiert. Die nun komprimierten Daten werden wiederum mit Zusatzinformationen versehen, die eine Fehlerdetektion beziehungsweise -korrektur ermöglichen. Hierfür ist der Kanalkodierer zuständig. Die nun fertig kodierten Daten werden über einen Kanal übertragen (gesendet). Dieser Kanal ist im Normalfall immer ein rauschender Kanal, das heißt, dass Daten nicht immer fehlerfrei über diesen Kanal übertragen werden. So könnte etwa gerade ein Fehler im Netzwerkkabel vorliegen, der einen Teil des übertragenden Signals verändert. Der Empfänger nutzt zunächst einen Kanaldekodierer. Dieser entfernt die redundanten Informationen, die zur Fehlerkorrektur und -detektion verwendet wurden. Wenn die Daten fehlerfrei sind beziehungsweise trotz Fehlern rekonstruiert werden können, werden sie durch den Quellendekodierer dekomprimiert. Die nun dekomprimierte Nachricht (‘HALLO’) wird der Nachrichtensenke (dem Empfänger) übergeben. Das einfachste Modell für einen solchen Kanal ist der binärsymmetrische Kanal (engl. binary symmetric channel, BSC, siehe Abb. 2.5). Ein BSC kann ausschließlich 0’er und 1’er Bits übertragen. Diese werden mit der Wahrscheinlichkeit p durch Rauschen modifiziert und empfangsseitig als das jeweils andere Bit interpretiert. Im Normalfall gilt, dass 0 ≤ p ≤ 1/2. Wenn etwa eine von 1000 Nachrichten fehlerhaft übertragen wurde, dann ist p = 1/1000 = 0,001. Wenn p = 0 ist, dann gilt der Kanal als rauschfrei (noisefree), andernfalls als rauschend (noisy). Doch wie funktionieren Kanalkodierer und Quellenkodierer beziehungsweise ihre jeweiligen Dekodierer? Im Folgenden werden einige grundlegende Verfahren besprochen.

16

2 Grundlagen der Netzwerktechnik

2.3.1.2 Quellenkodierer David A. Huffman (Preisträger der Hamming-Medaille von 1999) entwickelte ein nach ihm benanntes Kodierungsverfahren, das im Folgenden betrachtet wird und eine Form der Quellenkodierung darstellt. Ziel des Verfahrens ist es, zu sendende Nachrichten zu komprimieren, bevor sie an den Kanalkodierer weitergeleitet werden. Komprimierte Nachrichten sind weniger fehleranfällig (weil weniger lang) und lasten das Netzwerk weniger stark aus (Performancesteigerung). Erläutern lässt sich die Huffman-Kodierung am besten anhand eines Szenarios. Ein Sender möchte bestimmte Nachrichtensymbole (etwa alle deutschen Großbuchstaben) von einer Nachrichtenquelle (Quellensymbole) an einen Sender übertragen. Nachrichten, die diese Quellensymbole verwenden, sollen komprimiert werden. Für die HuffmanKodierung erzeugt der Sender zunächst einen Huffman-Tree. Ein Huffman-Tree ist ein Baum, der Quellensymbole beinhaltet. Die Quellensymbole werden im Baum gemäß ihrer relativen Häufigkeit eingebaut, mit der sie auftreten. Dabei gilt folgendes Vorgehen [9,30]: 1. Der Sender ermitteln für jedes Zeichen (Quellensymbol) die Auftrittswahrscheinlichkeit und erstellen jeweils ein Blatt (ein Element des zukünftigen Baumes), an dem er diese Auftrittswahrscheinlichkeit notiert. 2. So lange, wie der Sender noch Teilbäume (Blätter) übrig hat: a. Wahl der beiden Teilbäume (Knoten) mit der geringsten Häufigkeit und Tiefe an der Wurzel (aus den bisherigen Teilbäumen und übrigen Quellensymbolen). b. Zusammenfassen dieser Bäume zu einem neuen Baum. c. An der Wurzel des neuen Baumes die Summe der Auftrittswahrscheinlichkeiten der enthaltenen Symbole notieren. 3. Jeder Kante wird ein Codesymbol zugeordnet (i.d.R. ein Binärwert, also 1 oder 0). 4. Anschließend liegt der finale Huffman-Tree vor. Beispiel für den Aufbau eines Huffman-Trees

Der Sender möchte Nachrichten kodieren, die aus den Symbolen A, B und C bestehen (ein typisches Alphabet beinhaltet natürlich mehr Symbole, doch ist das Verfahren analog anzuwenden). Durch die Analyse typischer Texte der Sprache weiß der Sender, dass A das häufigste Symbol ist. Es tritt mit einer Wahrscheinlichkeit von 50 % auf. B tritt mit einer Wahrscheinlichkeit von 30 % und C mit einer Wahrscheinlichkeit von 20 % auf. Der Sender wählt nun zunächst die beiden Symbole mit der geringsten Auftrittswahrscheinlichkeit, also B und C und fügt diese zu einem Baum zusammen. Das linke Blatt des Baums steht für das Symbol B und erhält den Wert 30 %. Das rechte Blatt des Baums steht für das Symbol C und erhält den Wert 20 %. Die Wurzel des Baums wird „BC“ genannt und erhält die Summe beider Werte (50 %). Nun sind zwei Teilbäume übrig: Das Blatt A und der Teilbaum, in den B und C integriert wurden. Der Sender wählt diese beiden Bäume und kombiniert sie zu einem neuen Baum. Die rechte Seite repräsentiert das Symbol A und ist mit dem Wert 50 % verbunden. Die rechte Seite

2.3 Grundzüge des TCP/IP-Modells

17

Abb. 2.6 Beispiel eines Huffman-Trees

des neuen Baums wird der zuvor erzeugte Baum „BC“. Die Wurzel des finalen Baums „ABC“ erhält den Wert 100 %. Den Baum sehen Sie in Abb. 2.6. Schließlich notiert der Sender noch Codesymbole am Baum. Die linke Seite erhält dabei immer 0er-Werte, die rechte 1er-Werte (dies kann auch umgedreht werden). Die linke Seite (A) des Baums bekommt folglich den Wert 0 zugewiesen. Die rechte Seite (BC) erhält den Wert 1. Selbiges Verfahren wird für den Teilbaum BC angewandt. Die links Seite (B) erhält den Wert 0, die rechte Seite (C) erhält den Wert 1 (Abb. 2.6). Mithilfe des dabei erzeugten Baums kann der Sender Nachrichten kodieren. Er führt dazu die folgenden Schritte für jedes Quellensymbol aus und beginnt dabei mit dem ersten Quellensymbol seiner Nachricht: 1. Wahl des ersten beziehungsweise nächsten Quellensymbols. 2. Konkatenieren alle Codesymbole von der Wurzel des Huffman-Trees bis zum gewünschten Quellensymbol. 3. Sofern noch unkodierte Quellensymbole vorliegen: weiter mit Schritt 1. Die komprimierte Nachricht liegt anschließend in Form der notieren, aneinandergereihten Codesymbole vor. Beispiel für die Kodierung einer Nachricht mithilfe eines Huffman-Trees

Anhand des im vorherigen Beispiel erzeugten Huffman-Trees (Abb. 2.6) soll die Nachricht „AAABC“ kodiert werden. Ausgehend von der Wurzel des Baums müssen alle Kanten besucht werden, um zum ersten Quellensymbol der Nachricht („A“) zu gelangen. Hierzu muss die linke Kante besucht werden, die das Symbol „0“ aufweist. Da „A“ durch eine einzelne Kante erreicht werden kann, wird ausschließlich diese „0“ notiert. Analog wird mit den zwei weiteren „A“ verfahren, womit sich konkateniert bisher die Nachricht „000“ ergibt. Als nächstes muss das „B“ kodiert werden. Von der Wurzel ausgehend muss zunächst eine Kante mit der Beschriftung „1“ passiert werden, um zu „BC“ zu gelangen. Anschließend führt eine weitere Kante mit der Beschriftung „0“ zu „B“. Das entsprechende Codesymbol ist also „10“ und wird zur Nachricht hinzugefügt (es ergibt sich „00010“). Analog wird für die Kodierung des

18

2 Grundlagen der Netzwerktechnik

Quellensymbols „C“ verfahren, das durch das Codesymbol „11“ kodiert wird, womit sich schließlich die kodierte Nachricht „0001011“ ergibt. Ein guter Kompressionsalgorithmus komprimiert oft verlustfrei (etwa HuffmanKodierung). Manchmal können Verluste allerdings auch toleriert werden (etwa bei MP3oder JPEG-Kompression). Die Effektivität von Kompressionsalgorithmen kann über die Kompressionsrate bestimmt werden [25]: Kompressionsrate =

Größe der Ausgabedaten Größe der Eingabedaten

Je größer die Kompressionsrate, desto stärker wurden die Eingabedaten komprimiert. Hohe Kompressionsraten erzielen dabei nur Daten, die nicht bereits komprimiert sind (also beispielsweise keine JPEG-Dateien) und unverschlüsselt sind (weil sonst die Auftrittswahrscheinlichkeit für alle Symbole in etwa gleich hoch ist).

2.3.1.3 Kanalkodierer Während der soeben besprochene Quellenkodierer für die Verdichtung von Nachrichten zuständig ist, fehlt nun noch der Schritt, der für die Robustheit einer Nachrichtenübertragung sorgt. Dieser Schritt wird durch den Kanalkodierer durchgeführt. Die oben erwähnten EDC-Daten werden dabei in Form von Bits in zu übertragende Frames eingebettet. Der Sender schickt eine Frame, die aus zwei Komponenten besteht, den eigentlichen Framedaten und den EDC-Bits (|| steht für die Konkatenation, also das Aneinanderfügen): Frame := Datagramm || EDC Die Frame wird über einen Kanal übertragen und dabei eventuell verfälscht. Der Empfänger erhält letztlich ebenfalls eine Frame mit den Elementen Datagram und EDC . Frame := Datagramm || EDC Mithilfe der EDC kann der Empfänger allerdings Datagram überprüfen. Nur dann, wenn der Prüfwert der EDC-Bits mit den Daten des Datagramms übereinstimmt, wird das Datagramm als fehlerfrei betrachtet. Ansonsten wird versucht, es zu korrigieren, oder es wird verworfen. Falls der Sender eine Bestätigungsnachricht für den Empfang der Frame erwartet, wird diese Bestätigungsnachricht im Fehlerfall nicht gesendet.6 Paritätsbits: EDC-Bits können im simpelsten Fall mit sogenannten Paritätsbits (engl. parity bits) realisiert werden. Die Funktionsweise von Paritätsbits ist recht einfach. Für die zu übertragenden n Datenbits zählt man die Anzahl der auf „1“ gesetzten Bits. Ist diese 6 Tatsächlich kann auch eine Bestätigungsnachricht fehlerbehaftet sein oder verloren gehen. Dieses Problem nennt sich Two-Army-Problem.

2.3 Grundzüge des TCP/IP-Modells

19

ungerade, beträgt das entsprechende Paritätsbit 1, andernfalls 0. Das Paritätsbit wird an die eigentlichen Datenbits per Konkatenation angehängt. Der Empfänger prüft, ob die Anzahl der 1er-Bits mit dem Wert des Paritätsbits übereinstimmt. Beispielanwendung von Paritätsbits

Es seien die folgenden Bits zu übertragen: 0 0 1 0 0 1 1 0 1 Somit sind eine gerade Anzahl 1er-Bits enthalten. Das Paritätsbit wird entsprechend auf 0 gesetzt. Für die Daten 0 0 1 0 0 1 1 0 0 wäre das Paritätsbit hingegen 1. Problematisch ist hierbei, dass die Paritätsbits versagen, wenn sich in den Daten zwei Bits verändern. Schließlich würde der Wert des Paritätsbits dann wieder mit den zu prüfenden Bits übereinstimmen. Abhilfe schaffen hierbei mehrdimensionale Paritätsbits. Sie ermöglichen nicht nur eine begrenzte Fehlerdetektion, sondern erlauben auch die Korrektur einzelner Bits. Daten werden dazu in Abschnitte der Größe n geteilt. Für jeden Abschnitt wird das Paritätsbit separat berechnet. Diese Paritätsbits können als horizontale Paritätsbits betrachtet werden. Anschließend wird ein Paritätsbit für jedes erste Element jedes Abschnitts berechnet, dann das Paritätsbit für jedes zweite Element eines Abschnitts usw. Diese Paritätsbits können als vertikale Paritätsbits betrachtet werden. Schließlich wird noch das Paritätsbit aller vertikalen und aller horizontalen Paritätsbits berechnet. Beide Werte sollten gleich sein. Durch vertikale und horizontale Paritätsbits liegen nun zweidimensionale Paritätsbits vor. Denkbar wäre das Hinzufügen einer weiteren Dimension. Beispielanwendung von zweidimensionalen Paritätsbits

Es sollen die Daten 1 0 1 0 0 0 1 0 1 1 1 0 0 1 0 1 mit zweidimensionalen Paritätsbits übertragen werden. Die Abschnitte sollen 4 Bits umfassen. Entsprechend dargestellt ergeben sich vier Zeilen á 4 Bits: 1 0 1 0

0 0 1 1

1 1 1 0

0 0 0 1

Im zweiten Schritt werden die zweidimensionalen Paritätsbits hinzugefügt (fett gedruckt). Außerdem wird das Paritätsbit hinzugefügt, das über die vertikalen und horizontalen Paritätsbits berechnet wird (hier unterstrichen):

20

2 Grundlagen der Netzwerktechnik

1 0 1 0 0

0 0 1 1 0

1 1 1 0 1

0 0 0 1 1

0 1 1 0 0

Die Daten werden anschließend übertragen und der Empfänger kann bei einem Übertragungsfehler durch Kreuzung des vertikalen und des horizontalen betroffenen Paritätsbits ein gekipptes Bit detektieren und korrigieren. Beispielanwendung von zweidimensionalen Paritätsbits (Fortsetzung)

Es seien erneut die Daten 1 0 1 0 0 0 1 0 1 1 1 0 0 1 0 1 zu übertragen. Auch diesmal sollen die Daten in Abschnitte der Größe 4 zerteilt werden. Dabei wurde das kursiv markierte Bit (dritte Zeile, zweite Spalte) fehlerhaft übertragen. 1 0 1 0 0

0 0 0 1 0

1 1 1 0 1

0 0 0 1 1

0 1 1 0 0

Der Empfänger sieht, dass das dritte vertikale und das zweite horizontale Paritätsbit nicht mit den vorliegenden Datenbits übereinstimmen und „kreuzt“ beide Positionen, um das fehlerhafte Bit zu ermitteln. Hamming-Codes: Vorteilhafter sind hingegen sogenannte Hamming-Codes, die von Richard W. Hamming (Namensgeber der gleichnamigen Medaille der IEEE) erfunden wurden. Hamming-Codes haben die Länge 2r − 1, wobei r Bits für die Fehlerkorrektur verwendet werden und 2r − 1 − r Bits Nutzdaten sind. Das Verhältnis der beiden Werte wird auch als Tupel dargestellt. So bedeutet (7, 4) beispielsweise, dass 4 Nutzdatenbits und 3 Korrekturbits verwendet werden. Ein Paritätsbit ist bei Hamming-Codes immer von mehreren Nutzdatenbits abhängig, statt nur von einem einzigen. Je länger die zu übertragenden Daten sind, umso mehr Paritätsbits werden benötigt. Die Paritätsbits werden dabei zwischen die Nutzdatenbits integriert. Zur Konstruktion des Hamming-Codes wird wie folgt vorgegangen: Das n.te Paritätsbit berechnet sich über alle Bits, die an der n.ten Bitstelle 1 sind. Das erste Paritätsbit würde also beispielsweise über alle Bits, die an der ersten Bitstelle 1 sind, berechnet werden. In den Code werden die Paritätsbits an jeder Stelle 2n−1 eingefügt. Das heißt, Paritätsbit 1 steht an Stelle 1, Paritätsbit 2 steht an Stelle 2, Paritätsbit 3 steht an Stelle 4, Paritätsbit 4 steht an Stelle 8 usw.

2.3 Grundzüge des TCP/IP-Modells

21

Beispiel für einen (7,4)-Hamming-Code:

Unsere Nutzdaten-Bits seien erneut die ersten vier der oben verwendeten Bits, also 1 0 1 0. An jeder Stelle 2n wird nun ein Paritätsbit platziert, somit: Position: 1 | 2 | 3 | 4 | 5 | 6 | 7 | ------------+----+---+----+---+---+---| Bit: p1 | p2 | 1 | p4 | 0 | 1 | 0 | Paritätsbit p1 prüft jedes zweite Bit (von sich aus gerechnet, das heißt Bits 3, 5, 7). Dual haben diese Bits an letzter Stelle eine „1“ (000, 001, 010, 011, . . . ). Der Kodierer zählt bei den betroffenen Bits (1, 0, 0) die Vorkommen des Wertes „1“ (dieser kommt nur einmal vor), womit er p1 = 1 setzt. Analog verfährt der Kodierer mit p2, das, von sich aus gerechnet, jeweils zwei Bits prüft, anschließend zwei Bits überspringt usw. Anders formuliert prüft es die Bits 3, 6, 7, denn dual betrachtet sind dies die Bits, die an zweiter Stelle eine „1“ haben (000, 001, 010, 011, 100, 101, 110, 111). Erneut klammert der Kodierer die Paritätsbits selbst aus, startet also mit dem dritten Bit. Aus den Bits (1, 1, 0) ergibt sich somit der Paritätswert 0. Das Paritätsbit p4 prüft jeweils Ketten von vier Bits (es ist unser drittes Paritätsbit und prüft also jedes Bit, das an dritter Stelle den Wert „1“ hat). Hier wären die Bits 4, 5, 6, 7 betroffen, wobei der Kodierer p4 wieder nicht einbezieht. Aus den Bits (0, 1, 0) ergibt sich der Paritätswert 1 und schließlich das folgende Ergebnis (Paritätsbits sind fett gedruckt): Position: 1 | 2 | 3 | 4 | 5 | 6 | 7 | ------------+---+---+---+---+---+---| Bit: 1 | 0 | 1 | 1 | 0 | 1 | 0 | Für die Fehlererkennung kann der Dekodierer mithilfe des Hamming-Codes das fehlerhafte Bit lokalisieren (dazu sind hierbei weniger Bits als bei zweidimensionalen Paritätsbits notwendig). Der Dekodierer prüft für alle vorhandenen Paritätsbits, ob der Ist-Wert des Paritätsbits mit dem Soll-Wert der Bitpositionen übereinstimmt. Angenommen p1 habe den Ist-Wert „1“ und den Soll-Wert „0“. Wenn nun zudem p2 den Ist-Wert „0“ und den Soll-Wert „1“ aufweist, dann kann der Dekodierer den exakten Fehler lokalisieren: Der Dekodierer addiert die Stellen der beiden Paritätsbits (1 + 2 = 3) miteinander und erhält dadurch das fehlerhafte Bit (3). Wären hingegen p2 und p4 auf Fehler zeigend, so wäre das sechste Bit fehlerhaft. Der Bitwert des jeweils fehlerhaften Bits muss invertiert werden, um ihn zu korrigieren. Ein weiterer Vorteil des Verfahrens liegt darin, dass, falls ein Paritätsbit fehlerhaft ist, auch die Paritätswerte uneinheitlich ausfallen: Es müssen immer mindestens zwei Paritätsbits einen Fehler in den Nutzdaten anzeigen, ansonsten kann ein Paritätswert selbst als fehlerbehaftet betrachtet werden.

22

2 Grundlagen der Netzwerktechnik

2.3.1.4 Medienzugriff Übertragungsmedien werden von mehreren Systemen verwendet. Beispielsweise werden Luft und Kabel von mehreren Nodes gleichzeitig zum Senden benutzt. Das mögliche Resultat sind kollidierende Frames. Verschiedene Zugriffsverfahren adressieren dieses Grundproblem. Betrachtet werden im Folgenden die Verfahren ALOHA, SLOTTED ALOHA und CSMA/CD sowie CSMA/CA. Das Konzept von ALOHA ist simpel. Wenn Daten zum Senden bereit sind, dann erfolgt ein sofortiges Senden von Frames über das Medium. Falls eine Kollision mit einer anderen Frame stattfindet, wird die aktuelle Frame dennoch vollständig verschickt. Danach wird mit Wahrscheinlichkeit p ein neuer Sendeversuch unternommen. Andernfalls wird eine festgelegte Zeitspanne gewartet und danach wieder mit Wahrscheinlich p ein Sendeversuch unternommen. Dieser Vorgang des wahrscheinlichen Wartens wird so lange wiederholt, bis die Frame gesendet wurde. ALOHA wurde durch die Einführung von Zeitslots verbessert und Slotted ALOHA getauft. Zeitslots sollen dabei ein effizienteres Senden ermöglichen. Außerdem wird festgelegt, dass alle Frames dieselbe Länge l bekommen und ein Zeitslot groß genug ist, um eine Frame dieser Länge zu versenden. Während eines Zeitslots kann entweder gesendet werden (erfolgreich oder mit Kollision) oder es wird nicht gesendet. Gesendet wird nur zu Anfang eines Zeitslots, nicht mittendrin oder zum Ende. Es wird zudem nicht zeitslotübergreifend gesendet. Alle Systeme sind synchronisiert und benutzen daher dieselben Zeitslot-Aufteilungen. Wenn es zu einer Kollision kommt, wird auf einen anderen Zeitslot gewartet und dann mit Wahrscheinlichkeit p erneut gesendet. Auf diese Weise werden Kollisionen, die nur durch sich überlappende Frameteile entstehen, vermieden. Eine weiteres Verfahren für den Medienzugriff ist Carrier Sense Multiple Access (CSMA). Carrier Sense (CS) überprüft dabei, ob eine andere Node bereits sendet (und beginnt das Senden nicht, wenn dies dies der Fall ist). Multiple Access (MA) erlaubt es, dass mehrere Nodes über das Medium senden und empfangen. Außerdem werden Daten, die eine Node sendet, generell von allen anderen Nodes empfangen. CSMA wurde zu CSMA/CD und CSMA/CA weiterentwickelt und kommt in diesen Formen in aktuellen Netzen zum Einsatz. CSMA/CD verhält sich wie CSMA, allerdings wird zusätzlich Collision Detection (CD) eingesetzt. Falls eine sendende Node detektiert, dass eine andere Node ebenfalls sendet (das kann durch zeitliche Verzögerungen passieren), so wird das Senden abgebrochen und eine Zufallszeit gewartet, bevor erneut gesendet wird. CSMA/CA führt hingegen das Konzept der Collision Avoidance (CA) ein. Dieses Konzept kann auch als Listen before you talk (höre auf das Medium, bevor du selbst sendest) verstanden werden. Nodes prüfen vor dem Senden, ob eine andere Node derzeit sendet (Kollisionen sind nach wie vor durch zeitlich Überlappung möglich, aber weniger wahrscheinlich), führen also CS durch. Falls eine andere Node sendet: Sende selbst nicht. Neben diesen im Wesentlichen zufallsbasierten Zugriffsverfahren existieren auch deterministische Zugriffsverfahren, insbesondere das Master-Slave-Verfahren, bei dem

2.3 Grundzüge des TCP/IP-Modells

23

ein Master feste Kommunikationszeiten mit untergeordneten Nodes (den Slaves) einhält. Master-Slave-Verfahren kommen insbesondere in Automationsumgebungen zum Einsatz. Ein Vertreter für das Master-Slave-Verfahren ist Master-Slave/Token-Passing (MSTP), das beim BACnet-Protokoll zum Einsatz kommt (siehe Kap. 10).

2.3.2

Internet Layer

Der Internet Layer hat die Aufgabe, Daten mit Hilfe des Internet-Protokolls (IP), das später noch genauer betrachtet wird, zu versenden und zu empfangen. Dazu besitzt jeder Rechner eine eindeutige Adresse – die sogenannte IP-Adresse – die ihn eindeutig in einem Netzwerk identifiziert. Die IP-Adresse wird in der Form a.b.c.d geschrieben, wobei die Buchstaben jeweils durch Ziffern ersetzt werden. Anders als beim Link Layer erfolgt auf diesem Layer sogenanntes Routing.  Wegfindung in Netzwerken Das Routing stellt sicher, dass Daten über verschiedene Netzwerke hinweg an das Ziel übertragen werden können. Dazu werden Informationen benötigt, die angeben, über welche Router man ein Zielnetzwerk erreichen kann. Dies ist vergleichbar mit einer Bahnfahrt. Um von München nach Frankfurt zu fahren, müssen Sie mehrere Stationen (analog zu den Routern) passieren, vermutlich Augsburg, Ulm, Stuttgart und Mannheim. Sie müssen an der jeweiligen Station jedoch nur wissen, in welchen Zug Sie steigen müssen beziehungsweise ob Sie im aktuellen Zug verbleiben können. So trifft analog auch jeder Router für ein weiterzuleitendes Paket jeweils die Entscheidung, über welchen Link das Paket gesendet werden muss, um das angegebene Ziel zu erreichen. Die Informationen zur Wegfindung, also die Routinginformationen, werden dabei in den Routingtabellen der einzelnen Rechner abgelegt. Diese können entweder statisch vom Administrator konfiguriert oder dynamisch über Routingprotokolle verwaltet werden. Letztere Variante bietet je nach Routingprotokoll und verwendetem Routingalgorithmus diverse Angriffspunkte für Hacker, erleichtert aber das Management großer Netzwerke. Die Routingtabelle eines Systems können Sie über das route-Programm aufrufen und administrieren. Unter vielen Systemen kann zudem alternativ auch das netstatProgramm verwendet werden.7 $ r o u t e −n K e r n e l −IP−R o u t e n t a b e l l e Ziel Router Genmask 0.0.0.0 10.0.2.2 0.0.0.0 10.0.2.0 0.0.0.0 255.255.255.0 172.16.0.0 172.16.0.1 255.255.0.0

Flags UG U U

Metric 100 100 100

Ref Use I f a c e 0 0 enp0s3 0 0 enp0s3 0 0 enp0s8

7 Bei Verwendung des netstat-Programms benötigen Sie für die Routingtabelle den Parameter -r (aktiviert die Ausgabe der Routingtabelle).

24

2 Grundlagen der Netzwerktechnik

Rechner und Netzwerke werden dabei durch IP-Adressen repräsentiert. Wie Sie sehen, ist für jedes Ziel ein Router (Gateway) angegeben. So erreichen der Rechner das Zielnetz 172.16.0.0 etwa über den Router mit der IP-Adresse 172.16.0.1. Das Ziel 0.0.0.0 steht für den Standardrouter – an ihn werden Datenpakete geschickt, damit er sie (hoffentlich) an das Ziel weiterleiten kann, auch wenn der sendende Host selbst nicht weiß, wie der Pfad zum Zielnetz aussieht. Ohne diesen Standardrouter bräuchte jeder mit dem Internet verbundene Rechner eine Routingtabelle, die die Routingdaten des gesamten Internets beinhaltet. Dank diesem Router muss ein Router beziehungsweise ein Host allerdings meist nur wenige Einträge in seiner Routingtabelle vorhalten. Der Standardrouter hat in seiner Routingtabelle wiederum entsprechende Informationen, um das Paket an den nächsten Router in Richtung des Zieles beziehungsweise direkt an das Ziel zu senden. Auf diese Weise werden die Pakete von einem zum nächsten Router weitergereicht, bis sie schließlich am Ziel ankommen. Neben dem Ziel und dem Router, der verwendet werden soll, um dieses Ziel zu erreichen, werden noch weitere Informationen zum Pfad (etwa die Netzmaske oder die zu verwendende Netzwerk-Schnittstelle) angegeben, was in diesem einführenden Kapitel allerdings nicht von Bedeutung ist. In diesem Buch werden die Begriffe Gateway und Router zwar synonym verwendet, jedoch sind beide nicht exakt gleich definiert. Ein Router leitet Pakete auf dem Internet Layer weiter, ein Gateway verwendet dazu auch durchaus einen anderen Layer und kann Protokolle übersetzen, um Netzwerke, die unterschiedliche Protokolle verwenden, interoperabel zu machen. Der Internet Layer nutzt den darunter liegenden Network Access Layer. Nur über diesen können die Pakete über das Kabel versendet werden. Dass die Pakete dazu in eine Frame gepackt werden, ist auch eine logische Konsequenz. Beim Empfänger wiederum entpackt der Network Access Laer die Frame und reicht das erhaltene Paket unverändert an den Internet Layer weiter – wie ein Ei, das erst geschält werden muss. Der Unterschied zum Ei besteht nun im Besonderen darin, dass jede Schicht erst ihre „Schale“ entfernen muss, bevor dem Benutzer die relevanten Daten zur Verfügung stehen. So betrachtet können Sie sich das zuvor erläuterte Prinzip der Einkapselung auch als Zwiebelschalenmodell vorstellen, dessen äußerste Schale das Protokoll des Network Access Layers ist, und dessen innerste Schale das Protokoll des Application Layers darstellt.

2.3.3

Transport Layer

Die nächsthöhere Schicht, der Transport Layer, hat die Aufgabe, die durch den Internet Layer zum Zielrechner beförderten Daten an die richtigen Anwendungen auszuliefern. Anwendungen werden dabei sogenannten Ports zugeordnet. Jede „Verbindung“ zwischen dem Sender und dem Empfänger hat auf Anwendungsebene jeweils zwei Ports: einen Quellport (dieser gehört zum Sender) und einen Zielport (dieser gehört zum Empfänger). Ein Paar aus Quell- und Zielport erlaubt die eindeutige Zuordnung der Verbindung zu den

2.3 Grundzüge des TCP/IP-Modells

25

Abb. 2.7 Portbasiertes Multiplexing des Transport-Layers: Senderseitige Daten der Anwendungen der Anwendungsschicht werden, obwohl sie sich ein Kommunikationsmedium teilen können, dennoch an die korrekten Anwendungen des Empfängers geleitet

jeweiligen Rechnern.8 Somit hat der Transport Layer die Hauptaufgabe des Multiplexings inne, da er zwischen Sender und Empfänger der Vermittler für eine Vielzahl an möglichen Anwendungen und ihren zugehörigen Verbindungen ist (Abb. 2.7). Das Verfahren des Multiplexings funktioniert ähnlich wie frühe Telefonanlagen, bei denen Steckverbindungen mit Anschlüssen (Ports) verbunden wurden. Dadurch wurde sichergestellt, dass ein bestimmter Teilnehmer mit einem anderen ausgewählten Teilnehmer sprechen kann, nicht jedoch mit einem beliebigen Teilnehmer. Analog soll heute die Kommunikation von einem E-Mailclient zu einem E-Mailserver nicht einfach bei einem anderen Dienst auf demselben Empfänger (etwa einem Webserver) landen (Abb. 2.7). Dieser Layer stellt neben einzelnen Spezialprotokollen (wie etwa dem Routingprotokoll OSPF (Open Shorted Path First)) im Prinzip nur zwei herausragende Protokolle, nämlich TCP (Transmission Control Protocol) und UDP (User Datagram Protocol) bereit. Während TCP eine etwas größere Datenlast pro Paket als UDP verursacht (da es einen größeren Header (also Protokollkopf mit Metadaten) verwendet), verfügt es über ausgefeiltere Fehlerkorrekturmechanismen, die die Auslieferung zu übertragenden Dateneinheiten (Segmente genannt) gewährleisten soll. UDP hingegen kümmert sich nicht darum, ob die über dieses Protokoll transferierten Dateneinheiten (Datagramme genannt) überhaupt ankommen. UDP wird daher für Systeme eingesetzt, die hohes Datenaufkommen bei ständig wechselnden, aber prinzipiell gleichen Daten verursachen.9 Diese beiden Protokolle werden selbstverständlich noch detaillierter besprochen. Ein weiterer Unterschied zwischen TCP und UDP ist der, dass TCP verbindungsorientiert arbeitet. Eine Verbindung besteht dabei aus vielen Segmenten. Das bedeutet, dass eine Verbindung vor der Kommunikation zunächst aufgebaut und am Ende wieder geschlossen werden muss. Auch muss eine Verbindung verwaltet werden. Bei UDP hingegen wird jedes Datagramm losgelöst von den vorherigen und nachfolgenden Datagrammen betrachtet.

8 Die Verbindungen werden den Rechnern wiederum über ihre Quell- und Ziel-IP-Adressen zugeordnet, doch dies ist die Aufgabe des Internet Layers. 9 Dies kann beispielsweise bei Statusdaten, die einmal pro Sekunde komplett übertragen werden, oder bei Internet-Telefonie der Fall sein.

26

2.3.4

2 Grundlagen der Netzwerktechnik

Application Layer

Der Application Layer, zu Deutsch die Anwendungsschicht, wird von den einzelnen Netzwerkprogrammen und -diensten verwendet. Die Anwendungen (Applications) stellen einen Dienst auf einem Port zur Verfügung (beziehungsweise greifen auf diesen zu) und können über diesen Port senden und empfangen. Solche Applikationen benötigen jeweils ihre eigenen, in der Regel glücklicherweise standardkonformen Protokolle. Die wichtigsten davon sind Hypertext Transfer Protocol (HTTP) für die Kommunikation zwischen Webserver und Browser, Domain Name System (DNS), primär für die Auflösung von Hostnamen in IP-Adressen, sowie das Simple Mail Transfer Protocol (SMTP) zum Versenden/Ausliefern von E-Mail und das Internet Message Access Protocol (IMAP) zum Abrufen von E-Mails. Auf dem Application Layer spricht man meistens nicht mehr von Paketen beziehungsweise Segmenten, sondern von Messages (Nachrichten) (UDP-basierte Kommunikation) und Streams (TCP-basierte Kommunikation).

2.3.5

Zusammenfassung

Ein Programm, das mit einem anderen Programm auf einem entfernten Rechner kommuniziert, benötigt ein Protokoll. Das Protokoll wird benötigt, damit die Kommunikation fehlerfrei funktionieren kann – und eigentlich ist ohne ein wie auch immer geartetes Protokoll auch keine Art von Kommunikation möglich. Schließlich können sich auch nicht zwei Menschen unterhalten, die keine gemeinsame (ggf. nonverbale) Sprache sprechen. Das Programm baut dazu eine Verbindung mit dem anderen Rechner auf, indem es Daten an einen Port des Zielrechners sendet. Die Transportschicht kümmert sich um die Zustellung der Daten des Programms an das entsprechende Programm des Zielrechners. Die Daten der Transportschicht nutzt wiederum das IP-Protokoll und damit den Internet Layer, um sicherzustellen, dass die Pakete auch ihr Ziel finden. Erst der Network Access Layer bringt die zwiebelförmig verpackten Daten auf das Kabel.

2.4

Die wichtigsten Protokolle

Im Folgenden werden die wichtigsten Protokolle, beginnend mit denen des niedrigsten Layers, besprochen. Mit „wichtig“ sind hier Protokolle gemeint, die besonders relevant für die IT-Sicherheit von Netzwerken sind. Dieses Kapitel beginnt jedoch nicht mit der Erläuterung von Ethernet- oder PPP-Frames, sondern mit ARP, und wendet sich anschließend IPv4, ICMPv4, IPv6 und ICMPv6 zu. Danach werden TCP und UDP als Transport-Layer-Protokolle besprochen. Zum Abschluss des Kapitels werden die wichtigsten Application-Layer-Protokolle betrachtet (insbesondere DNS und HTTP).

2.5 Link Layer: ARP

2.5

27

Link Layer: ARP

In Netzwerken kommunizieren Hosts über die oben erwähnten Frames miteinander. Diese Frames beinhalten eine Ziel- und eine Absenderadresse. Diese Adressen nennen sich MAC-Adressen (für Media Access Control, dt. Hardwareadressen) und sind zum Beispiel bei Ethernet-Netzwerken 48 Bit lang. MAC-Adressen sind in die Netzwerkkarten eingebrannt, aber einige Betriebssysteme ermöglichen es auch, diese Adressen manuell und zumindest virtuell zu ändern. Doch woher weiß ein Rechner, welche MAC-Adresse ein anderer Host hat? An dieser Stelle kommt ARP, das Address Resolution Protocol, zum Einsatz. ARP wurde bereits 1982 durch RFC 826 spezifiziert [17]. ARP hat die Aufgabe, die für eine IP-Adresse zugehörige MAC-Adresse herauszubekommen. Jeder Rechner, der eine ARP-Anfrage (den sogenannten Request) versendet, behält die darauf enthaltene Antwort eines anderen Rechners – in dieser Antwort steht die Zuordnung von IP- zu MAC-Adresse – in seinem lokalen Speicher, dem ARP-Cache. Der ARP-Cache kann sowohl unter WindowsSystemen als auch unter Unix mit dem arp-Kommando abgefragt werden. Angenommen der Rechner mit dem Namen eygo.sun verwendet die IP-Adresse 192.168.0.1 und soll einen ping (das ist eine Art Test-Paket, das von einem Empfänger einfach nur mit einer gleichen Nachricht beantwortet wird) an den Host yorick.sun mit der IP-Adresse 192.168.0.5 senden. Und weiterhin angenommen, dass diese beiden Hosts bisher keinen Kontakt miteinander pflegten oder der letzte Kontakt schon so lange zurückliegt, dass die gegenseitigen ARP-Einträge bereits gelöscht wurden. (Tatsächlich werden die dynamischen ARPEinträge nach einer gewissen Zeit aus dem ARP-Cache gelöscht.) In diesem Fall muss eygo.sun zunächst herausbekommen, welche MAC-Adresse der Host mit der IP-Adresse 192.168.0.5 besitzt. Er sendet eine Ethernet-BroadcastNachricht mit ARP-Request, das heißt eine Nachricht an alle Hosts im Netz, in der er nach der gewünschten MAC-Adresse fragt. Diese Nachricht beantworten aber jeweils nur solche Hosts, die eine Antwort auf diesen Request geben können. eygo.sun bekommt schließlich die Antwort, beispielsweise, dass 192.168.0.5 die MAC-Adresse 0:0:cb:59:fd:be hat. Diese Antwort nennt sich ein „ARP Reply“ und wird nicht mehr an die Broadcast-Adresse, sondern direkt an den Host gesendet von dem der ARP-Request ausging. Zur Verdeutlichung soll eine Betrachtung dieses Vorgehens mit dem Programm tcpdump unter dem OpenBSD-Betriebssystem dienen. Das Programm zeichnet den Datenverkehr im Netzwerk auf und ne3 ist hierbei schlicht die Bezeichnung der Netzwerkschnittstelle, auf der Netzwerkpakete aufgezeichnet werden. Der Parameter -vvv sorgt für eine detaillierte Ausgabe.

28

2 Grundlagen der Netzwerktechnik

root@eygo . s u n # tcpdump − i ne3 −v v v ... 1 1 : 5 9 : 2 7 . 6 8 1 2 1 4 a r p who−h a s 1 9 2 . 1 6 8 . 0 . 5 t e l l eygo . s u n 1 1 : 5 9 : 2 7 . 6 8 1 4 4 2 a r p r e p l y 1 9 2 . 1 6 8 . 0 . 5 i s −a t 0 : 0 : cb : 5 9 : f d : be ... ARP-Cache auf demselben Rechner kann mithilfe des arp-Programms angezeigt werden und listet nun die beiden Kombinationen aus IP- und MAC-Adressen (IP- und MAC-Adresse der eigenen Netzwerkschnittstelle waren dem Rechner sowieso bekannt): root@eygo . s u n # a r p −a ? ( 1 9 2 . 1 6 8 . 0 . 2 ) a t 0 0 : 6 0 : 9 7 : 3 0 : 0 c : bb on ne3 ? ( 1 9 2 . 1 6 8 . 0 . 5 ) a t 0 : 0 : cb : 5 9 : f d : be on ne3 Auf dem zweiten Host (ein Windows-PC) wurde der ARP-Cache ebenfalls aufgebaut: C : \ > a r p −a S c h n i t t s t e l l e : 1 9 2 . 1 6 8 . 0 . 5 on I n t e r f a c e 0 x1000003 Internetadresse Physikal . Adresse Typ 192.168.0.1 192.168.0.2

2.5.1

00−50−bf −11−35−a5 00−60−97−30−0c−bb

dynamisch dynamisch

Reverse-ARP

Die Gegenfunktion zum ARP bietet das Reverse Address Resolution Protocol, kurz RARP. Im Gegensatz zum ARP löst es nicht IP- in MAC-Adressen, sondern MAC- in IP-Adressen auf. RARP benötigt einen zugehörigen Server, der die Anfragen der – meist plattenlosen – Clients auflöst. Wie Sie wohl schon erahnen, ist die Hauptaufgabe von RARP die Zuweisung von IP-Adressen an Thin-Clients. Allerdings ist zu sagen, dass RARP von BOOTP und DHCP praktisch komplett verdrängt wurde, da diese Protokolle einen besseren Funktionsumfang bieten.

2.5.2

Proxy-ARP

Mittels Proxy-ARP kann ein Subnetz gespalten beziehungsweise zusammengefügt werden. Zwischen beiden Netzen fungiert eine Proxy-ARP-Einheit sozusagen als Router für ARP-Anfragen. Zudem sendet es die Pakete zwischen beiden Netzteilen hin und her. Proxy-ARP sollte jedoch nicht verwendet werden, da es sehr leicht ist, Spoofing-Angriffe gegen dieses Protokoll durchzuführen.

2.6 Internet Layer: IPv4

2.6

29

Internet Layer: IPv4

Der Internet Layer arbeitet – wie bereits erwähnt – paketorientiert: die Frames des Link Layers mit ihren Signalisierungsmechanismen werden abstrahiert und die im Link Layer eingekapselten Dateneinheiten als Pakete bezeichnet. Die Aufgabe des Internet Layers besteht darin, Pakete von ihrer Quelle zum Ziel zu übertragen und dabei einen Weg über zwischengeschaltete Systeme (Hops) zu finden. Die Wegfindung ist die Aufgabe von Routern. Eine weitere Aufgabe des Internet Layers ist die Adressierung und die Fehlerbehandlung. Im Folgenden werden die wichtigsten Protokolle dieser Schicht betrachtet, das sind IPv4 und IPv6 sowie ihre zugehörigen Protokolle, und dabei mit IPv4 begonnen. Das Internet Protocol Version 4 (IPv4) ist das derzeit noch immer wichtigste Netzwerkprotokoll des Internet Layers. Es wurde ursprünglich in den 1970er-Jahren als IEN-Standard und später durch RFC 760 spezifiziert [20]. Diese Spezifikation wurde in den folgenden Jahrzehnten immer wieder aktualisiert. Jedes IPv4-Paket beinhaltet einen mindestens 20 Byte großen Header, der in Abb. 2.8 dargestellt ist. Die einzelnen Headerbestandteile haben, der Reihenfolge ihres Auftretens nach, die folgenden Funktionen: • Version: Die IPv4-Protokollversion (valide ist nur Version 4 (beziehungsweise Version 6 für IPv6); Version 5 war ein experimentelles Protokoll). • Internet Headerlänge (Internet Header Length, IHL): Dieses Feld gibt die Anzahl der 32-Bit-Wörter des Headers an, entsprechend wird die Größe der eingekapselten Daten höherer Layer nicht mit eingerechnet. Im Normalfall beinhaltet der IPv4-Header 5 × 32 Bit an Daten. Da der IPv4-Header um Optionen erweitert werden kann, ist es möglich, in diesem Feld größere Werte als 5 zu erhalten.

Abb. 2.8 Aufbau des IPv4-Headers (jede Zeile entspricht 32 Bit)

30

2 Grundlagen der Netzwerktechnik

• Type of Service (ToS), Teil 1 (DSCP): Das Feld Differentiated Services Code Point (DSCP) implementiert Quality of Service (QoS), dabei handelt es sich um Qualitätsanforderungen für Pakete. In [7] lässt sich lesen: Diffserv uses six bits of the IPV4 or IPV6 header to convey the Diffserv Codepoint (DSCP), which selects a PHB. PHB steht für Per Hop Behavior und signalisiert, wie ein Paket behandelt wird, wenn es einen Router passiert. Der Standardwert für die PHB ist 000000 und bedeutet, dass (nach Möglichkeit) ein schnelles Weiterleiten des Pakets erfolgen soll. Die restlichen Werte (‘Codepoint-IDs’) werden von der Internet Assigned Numbers Authority (IANA) zugewiesen [8]. Typische Anforderungen für DSCP sind ein schneller Verbindungsaufbau, zuverlässige Datenübertragung mit wenig Störungen und hohe Verbindungsstabilität. Tanenbaum nennt verschiedenste Beispiele für die anwendungsabhängige Wahl dieser Anforderungen [27], etwa benötigt eine Videokonferenz eine geringe Zuverlässigkeit, weil es nicht schlimm ist, wenn einzelne Bild-Frames verlorengehen, stattdessen gibt es hierbei hohe Anforderungen hinsichtlich der Verzögerung einer Verbindung und ihrer Bandbreite. Bei einer Dateiübertragung gibt es hingegen eine hohe Anforderung an die Zuverlässigkeit einer Verbindung, doch ist die Anforderung an die Verzögerung von Paketen relativ gering. • ToS, Teil 2 (ECN, Explicit Congestion Notification): Die ECN-Bits werden nur benutzt, falls Empfänger und Sender sich auf die Nutzung derselben einigen. Anstatt Routerüberlastung nur durch Paketverlust zu detektieren, kann mit ECN eine drohende Überlastung signalisiert werden [8]. • Gesamtlänge (Total Length): Im Gegensatz zur zuvor besprochenen ‘Internet Header Length’ (IHL) repräsentiert dieses Feld die gesamte Größe des Datenpakets (IPv4Header samt Payload) in Bytes. Valide Werte liegen im Bereich von 20 Bytes bis 0 × 65535 Bytes. Die 20 Bytes ergeben sich aus der Minimalgröße des IPv4-Headers. • Identification (ID, auch IPID): Dieses Feld dient als Identifikationswert für ein Paket, es wird zur Wiederzusammensetzung nach einer Fragmentierung verwendet (siehe „Flags“ und Abschn. 2.6.2). • Flags: (3 Bits): Bit 0 hat immer den Wert 0 (es ist für die zukünftige Verwendung reserviert). Bit 1 verbietet das Fragmentieren (also Aufteilen des Pakets in mehrere kleine Pakete) und nennt sich Don’t Fragment-Flag (DF). Bit 2, das More FragmentsFlag (MF), signalisiert hingegen, dass dieses Paket ein Teilpaket eines ehemals größeren, aber nun fragmentierten, Pakets ist und weitere Fragmente folgen. Die weiteren Fragmente werden benötigt, um die finale Wiederzusammensetzung eines fragmentierten Pakets zu ermöglichen. • Fragment Offset: Dieses Feld zeigt an, an welcher Stelle im Empfangspuffer die im Paket enthaltenen Daten eines Fragments platziert werden müssen. Das heißt, das Fragment Offset gibt an, welcher Teil eines fragmentierten Pakets vorliegt und wo dieses Fragment eingesetzt werden muss, damit es, ähnlich einem Puzzlestück, zum ursprünglichen Gesamtpaket beiträgt. Es gibt 213 mögliche Fragment-Offset-Werte (das heißt: maximal 8.192 Fragmente pro Datenpaket). Jedes Fragment muss ein Vielfaches von 8 Bytes ausmachen. Damit gilt: 213 × 8 = 65.535 Bytes. Abzüglich der Header-

2.6 Internet Layer: IPv4

•

•

•

• •

31

Länge sind somit mehr Payload-Daten adressierbar, als ein unfragmentiertes Paket beinhalten kann. Time to Live (TTL, 8 Bit): Dieser Wert wird von jedem Router, den ein Paket passiert, um 1 verringert (dekrementiert). Erreicht die TTL den Wert 0, wird das Paket verworfen. Bei den meisten Implementierungen wird für ein neues Paket der Wert 255 vergeben. Auf diese Weise können Routing-Loops verhindert werden, bei denen Pakete zwischen Routern unendlich lang im Kreis verschickt werden. Protocol: Das Protocol-Feld spezifiziert das eingekapselte Netzwerkprotokoll und die Werte des Feldes sind standardisiert. Die häufigsten Werte sind: 1 (ICMP), 2 (IGMP), 6 (TCP) und 17 (UDP). Außerdem wird über dieses Feld IPv4-Tunneling ermöglicht.10 Checksum: Dieses Feld speichert eine Prüfsumme über den Header und dient der Fehlererkennung. Dieses Feld wird von jedem passierten Hop neu berechnet, da sich jeweils die TTL verändert. Source IP Address und Destination IP Address (Quell- und Zieladresse des Datenpakets): Hierbei handelt es sich um einen jeweils 32 Bit großen Adressierungswert. Options: Dieses Feld wird nur in Spezialfällen verwendet (die zuvor besprochene IHL muss entsprechend erhöht werden, da sich durch Hinzufügen von Options-Bereichen die Headergröße erhöht). Die Options waren ursprünglich zur Weiterentwicklung von IP gedacht und in einem einzelnen IPv4-Paket können mehrere Options hintereinander untergebracht werden. Das Ende der Options muss mit einem EOL-Wert (End of Options List, Wert 0) signalisiert werden. Folgende Options sind aus IT-Sicherheitssicht von Interesse; diese Optionen wurden ursprünglich zur Netzwerkanalyse entwickelt und werden nun dazu verwendet, Angriffe durchzuführen beziehungsweise vorzubereiten: – Loose Source Routing: Hierbei werden Hosts angegeben, die von einem IP-Paket passiert werden müssen. Zwischen den angegebenen Hops können auch Hops liegen, die nicht angegeben werden. – Strict Source Routing: Im Gegensatz zur Loose Source Route wird hierbei eine exakte Vorgabe einer Route verwendet. Das Passieren nicht explizit festgelegter Hosts ist nicht zulässig. – Record Route: Hierbei wird eine passierte Route zu Diagnosezwecken aufgezeichnet. Jeder passierte Router fügt dabei seine eigene IP-Adresse an das Ende der Options hinzu.

Hinter dem IPv4-Header folgen die eingekapselten Daten (aus Sicht vom Internet Protocol handelt es sich dabei um Payload, tatsächlich jedoch um Transport Layer-Daten).

10 Tunneling bezeichnet die Einkapselung eines Protokolls gleicher oder niedrigerer Schicht in ein

anderes Protokoll. Tunnel kommen etwa zum Einsatz, um von IPv4 auf IPv6 zu migrieren. Ein anderes Anwendungsgebiet stellen virtuelle private Netzwerke (VPNs), also private und zugleich gesicherte Netzwerkverbindungen zwischen Hosts beziehungsweise Netwerken, dar [29].

32

2 Grundlagen der Netzwerktechnik

Entsprechend folgt in einem Netzwerkpaket direkt hinter dem letzten Byte des IP-Headers beispielsweise ein UDP- oder ein TCP-Header.

2.6.1

IP-Adressen

Die bereits erwähnten 32-Bit-IP-Adressen dienen der eindeutigen Adressierung von Netzwerkrechnern in einem IP-Netzwerk (etwa einem lokalen Netzwerk oder dem Internet).11 Zwar lässt sich einiges über IP-Adressen und ihre Vergabe12 schreiben, doch sind diese Themen für dieses Buch nur von begrenzter Relevanz. IP-Netzwerke können in Teilnetze (Subnetze) gegliedert werden. Subnetze sind Bereiche aufeinander folgender IP-Adressen. Definiert werden Subnetze mit einer Subnetzmaske, die aus einem 32-Bit-Wort besteht. Die Subnetzmaske besteht genauer gesagt aus 1er-Bits, gefolgt von 0er-Bits. Dadurch gibt die Subnetzmaske an, wie viele Bits einer IPAdresse das Netzwerk spezifizieren (1er-Bits) und wie viele Bits in diesem Netzwerk für den Host verwendet werden (0er-Bits). Die Schreibweise zur Angabe eines Netzwerks samt Subnetz ist a.b.c.d/n, wobei a.b.c.d die IP-Adresse und n die für das Netzwerk verwendeten Bits angeben. Es verbleiben folglich 32 − n Bits für die Adressierung von Hosts in diesem Netzwerk. Zum Beispiel würde 7.0.0.0/8 uns verdeutlichen, dass acht Bits für das Netzwerk und 24 Bits für Hosts (also 224 IP-Adressen) verwendet werden. Üblicherweise ist die erste Adresse in einem Netzwerk die Adresse des Netzwerks selbst, im obigen Fall also 7.0.0.0. Der erste adressierbare Host ist die nächste IP-Adresse (das Bit mit der geringsten Wertigkeit wird inkrementiert, das heißt 7.0.0.1). Der letzte Host im Netzwerk erhält die vorletzte IP-Adresse im Subnetz (7.255.255.254) und die letzte Adresse dient als Broadcast-Adresse (hier also 7.255.255.255). Zudem gibt es einige für die Privatverwendung vorgesehene IP-Adressbereiche, die jeder Nutzer verwenden darf und die nicht im Internet geroutet werden (siehe Tab. 2.1). Tab. 2.1 Für die Privatverwendung vorgesehene IP-Adressbereiche Adressbereich

Netzbits

Hostbits

Adressen

10.0.0.0 – 10.255.255.255 172.16.0.0 – 172.32.255.255 192.168.0.0 – 192.168.255.255

8 12 16

24 20 16

224 (ca. 16.7 Mio.) 220 (ca. 1 Mio.) 216 (ca. 65.500)

11 Anm.: Es gibt Techniken, wie Network Address Translation (NAT), die eine eindeutige Identifizierung von Netzwerkrechnern für Systeme außerhalb eines internen Netzes verhindern. 12 Die Vergabe der IP-Adressen erfolgte ursprünglich durch die IANA. Später vergab die IANA nur noch Adressen an Regional Internet Registry-Organisationen (RIRs), etwa APNIC (Asia-Pacific Network Information Center) oder RIPE (Réseaux IP Européens Network Coordination Centre).

2.6 Internet Layer: IPv4

33

Localhost: Um mit dem eigenen Rechner (dem Localhost) zu kommunizieren gibt es die IPv4-Adressen im Bereich 127.0.0.1–127.255.255.255. Somit steht jedem Rechner das Subnetz 127.0.0.0/8 zur Verfügung.

Die Darstellung einer IP-Adresse in der Form a.b.c.d ist nur eine von vielen Möglichkeiten, die 32 Bits der Adresse darzustellen. Alternativ könnten auch 32 Nullen und Einsen zur Darstellung der binären Form dienen. Auch kann die Adresse Hexadezimal oder mit weniger Dezimalpunkten getrennt dargestellt werden. So lässt sich 127.0.0.1 beispielsweise auch als 0x7F 000001 oder 127.1 darstellen.

2.6.2

Fragmentierung

Für Netzwerkverbindungen existieren Limits hinsichtlich der maximalen Größe an Daten, die durch eine Frame des Link Layers übertragen werden können, die sogenannte Maximum Transmission Unit (MTU). Die MTU bezieht dabei nicht die Frame des Network Access Layers ein, sondern ausschließlich die Daten ab dem Internet Layer.13 Für Ethernet- und WLAN-Verbindungen beträgt die MTU meist 1500 Bytes. Die MTU eines Rechners lässt sich unter unixartigen Systemen mit ifconfig und unter Windows mit ipconfig abfragen: $ i f c o n f i g wlan0 wlan0 L i n k e n c a p : E t h e r n e t Hardware A d r e s s e 5 c : 5 1 : 4 f : d0 : 3 f : 7 c i n e t Adresse :192.168.2.106 Bcast :192.168.2.255 Maske : 2 5 5 . 2 5 5 . 2 5 5 . 0 UP BROADCAST RUNNING MULTICAST MTU: 1 5 0 0 M e t r i k : 1 ...

Verschickt ein Rechner, wie in Abb. 2.9 dargestellt, ein zu großes Paket über eine Route, die mehrere Netzwerkverbindungen passieren muss, so muss das Paket aufgeteilt (fragmentiert) werden. Angenommen, das Ausgangspaket sei 1600 Bytes groß und hat die Fragment ID 123. Für die Fragmentierung kommen die oben bereits erwähnten IP-Felder Identification, Flags und Fragment-Offset zum Einsatz. Das 1600 Bytes große Paket soll nun zur Verdeutlichung des Verfahrens über eine Verbindung mit einer MTU von 1492 Bytes übertragen werden. Zunächst wird der erste Teil des Pakets (20 Bytes für den IP-Header samt den ersten 1472 Bytes des Payloads) über die Verbindung übertragen und das More Fragments-Flag gesetzt. Das Abschneiden nach den ersten 1472 Bytes ist notwendig, denn 1492 Bytes MTU – 20 Bytes für den IP-Header ergeben den Maximalwert für den 13 beziehungsweise dem Network Layer im OSI-Modell.

34

2 Grundlagen der Netzwerktechnik

Abb. 2.9 Beispiel für die Fragmentierung durch IPv4. Ein 1600 Bytes großes Paket muss über eine Verbindung mit einer MTU von 1492 Bytes übertragen werden

anhängbaren Payload (also 1472 Bytes). 1472 Bytes sind gleichzeitig ein Vielfaches von 8 Bytes und somit ein valider Wert für das Fragment-Offset des folgenden Paketes (das Fragment-Offset des ersten Paketes ist 0). Die restlichen Payload-Daten (1600 Bytes abzüglich 20 Bytes für den ursprünglichen Header und 1472 Bytes an bereits übertragenem Payload, also 108 Bytes an Payload) werden in ein zweites Paket gepackt, welches denselben Header, wie das erste Fragment erhält (auch der Identifier-Wert 123 ist derselbe). Im zweiten Fragment wird das FragmentOffset angepasst und erhält den Wert 184 (= 1472 Bytes aus Fragment 1, dividiert durch Vielfache von 8 Bytes). Außerdem wird im zweiten Fragment das More Fragments-Flag nicht mehr gesetzt, da keine weiteren Fragmente mehr folgen. Nachdem das zweite Paket übertragen wurde, kann der Empfänger es verarbeiten. Die Wiederzusammensetzung eines Pakets erfolgt ausschließlich beim Empfänger und wird von keinem zwischengeschalteten Router vorgenommen, da einzelne Fragmente in IP-Netzen unterschiedliche Pfade passieren können. Es ist aus diesem Grund auch nicht sichergestellt, dass ein Router jedes Fragment eines Paketes erhält. Basierend auf dem Wert des Fragment-Offsets kann der Empfänger selbst dann die Payload-Bestandteile der einzelnen Fragmente in der richtigen Reihenfolge zusammensetzen, wenn diese in einer Reihenfolge ankamen, in der sie gar nicht verschickt wurden.14

14 Wie bereits erwähnt, können einzelne Pakete (somit also auch Fragmente, die an sich wieder

Pakete sind) unterschiedliche Pfade zum Ziel nehmen. Ein Weg über Pfad A kann länger benötigen, als ein Weg über Pfad B oder C, womit Paketreihenfolgen vertauscht werden können, weil sich Pakete während der Zustellung gegenseitig überholen.

2.7 Internet Layer: ICMPv4

2.7

35

Internet Layer: ICMPv4

ICMP (Internet Control Message Protocol) wurde 1981 in RFC 777 spezifiziert [21]. Es dient, wie sein Name schon verrät, der Kontrolle des IP-basierten Datenverkehrs. Genauer gesagt dient es der Fehleranalyse, der Informationserstattung und der Konfiguration von IP-Hosts und -Netzen. Der Standardaufbau des ICMPv4-Headers ist simpel und in Abb. 2.10 zu sehen. Der ICMP-Type spezifiziert die gewünschte Hauptfunktion eines ICMP-Pakets, die durch den ICMP-Code genauer spezifiziert werden kann. Die Prüfsumme hat dieselbe Funktion wie im IP-Header. Nach den ersten 32 Bytes des ICMP-Headers folgen Inhalte, die vom jeweiligen ICMP-Type abhängen. Die IANA (Internet Assigned Numbers Authority) hat eine offizielle Liste der ICMPTypes und zugehöriger ICMP-Codes veröffentlicht [10]. Die wichtigsten dieser ICMPTypen sollen im Folgenden besprochen werden.

2.7.1

ICMP-Types 0 und 8

Die wohl bekanntesten ICMP-Typen sind Type 0 und Type 8. Ersterer ist der sogenannte Echo Reply, letzterer der Echo Request. Diese beiden ICMP-Typen werden in der Regel zur Feststellung der Erreichbarkeit eines Hosts verwendet. Man spricht bei diesem Test auch von einem Ping. Eine ICMP-Echo-Nachricht besteht aus einem 16-Bit-Identifer sowie einer 16-BitSequenznummer zur Identifikation der Datagramme. Optional können noch Daten an das Paket angehängt werden, um die Netzlast zu erhöhen. Dies ergibt besonders bei Performance-Tests Sinn, denn die Datagramme müssen inklusive Payload bestätigt werden. Ein Ping funktioniert folgendermaßen: Host A sendet einen Echo Request an Host B, Host B antwortet darauf mit einem Echo Reply. Alternativ kann A den Echo Request auch per Broadcast an ein Netzwerk senden und erhält anschließend eine Antwort der Hosts im Netzwerk.

Abb. 2.10 Aufbau des ICMPv4-Headers

36

2.7.2

2 Grundlagen der Netzwerktechnik

ICMP-Type 3

Der ICMP-Type 3 (Destination Unreachable) wird immer dann versendet, wenn ein Datagramm nicht zugestellt werden konnte. Genauere Information zum Grund der Fehlzustellung gibt der ICMP-Code an. Es gibt folgende Möglichkeiten: • Code 0 (Net Unreachable): Das Zielnetzwerk ist nicht erreichbar. Dies kann zum Beispiel auf fehlende Einträge in der Routingtabelle zurückzuführen sein. • Code 1 (Host Unreachable): In diesem Fall ist zwar das Netzwerk, jedoch nicht der Host erreichbar. Entweder wurde die falsche Adresse angegeben oder der Host hat technische Probleme beziehungsweise ist ausgeschaltet. • Code 2 (Protocol Unreachable): Bekommt man diese Fehlermeldung, ist das Protokoll, an das das Datagramm weitergereicht werden soll, nicht erreichbar. • Code 3 (Port Unreachable): Diese Meldung wird ausgesandt, wenn das Datagramm – im Transport Layer also ein TCP-Streampaket oder eine UDP-Message – nicht an den entsprechenden Port weitergereicht werden konnte. Portscanner benötigen, je nach Scan-Technik, Port Unreachable-Nachrichten, um festzustellen, ob ein bestimmter Port erreichbar ist. • Code 4 (Fragmentation Needed, DF Flag Set): Diese Meldung wird ausgesandt, wenn ein Datagramm mit dem gesetzten Bit Don’t Fragment (DF) versandt wurde, aber zu groß für die MTU eines Netzes ist. Dieser Code wird in Verbindung mit der Path-MTUDiscovery15 und der Fragmentierung (siehe Abschn. 2.6.2) verwendet. • Code 5 (Source Route Failed): Wurde ein IP-Datagramm mit einer Loose- oder StrictSource-Route-Option versandt, wird diese Meldung im Falle einer nicht gangbaren Route gesandt. • Code 6 (Destination Network Unknown): Ist ein Netzwerk gar nicht vorhanden, wird diese Nachricht versandt. • Code 7 (Destination Host Unknown): Ist ein einzelner Host gar nicht vorhanden, wird diese Nachricht versandt. • Code 8 (Source Host Isolated): Dieser Typ findet normalerweise gar keine Verwendung und gilt als obsolet. • Codes 9 und 10 (Communication with Destination Network/Host Administratively Prohibited): Die Kommunikation zum Netzwerk beziehungsweise Host wurde vom Administrator untersagt.

15 Path-MTU-Discovery bedeutet, dass ein Host künstlich zu große Pakete an dasselbe Ziel sendet,

die er so lange verkleinert, bis er keine ICMP Meldungen mit Type 3, Code 4 mehr erhält. Die daraus resultierende Paketgröße ist die größte für den Pfad nutzbare und wird für die Kommunikation mit einem Ziel verwendet, um Fragmentierungen zu verhindern. Das ist nicht perfekt, da es insbesondere schlecht auf Situationen reagieren kann, bei denen sich Routingpfade zwischenzeitlich ändern.

2.7 Internet Layer: ICMPv4

37

• Codes 11 und 12 (Network/Host Unreachable for Type of Service): Diese Meldung wird versandt, wenn das Zielnetzwerk beziehungsweise der Zielhost nicht für den angegebenen Type-of-Service (siehe oben) erreichbar ist. • Code 13 (Communication Administratively Prohibited by Filtering): Die Kommunikation zum Zielsystem ist nicht möglich, da ein Firewall-System den Datenverkehr blockt. Der Header dieser Nachricht ist nach dem statischen Headerteil mit einem 32 Bit langen und ungenutzten Bereich versehen. Anschließend folgt der IP-Header des ursprünglichen Datagramms samt, gegebenenfalls gekürzten, Payload. Der Grund für diesen Anhang liegt in den besseren Diagnosemöglichkeiten, die sich aus den zusätzlichen Informationen ergeben.

2.7.3

ICMP-Type 4

ICMP-Type 4 (Source Quench) wird von einem Empfänger versandt, wenn zu viele Pakete bei ihm eintreffen. Der Sender dieses Types teilt dem Empfänger mit, dass dieser seine Aussenderate drosseln soll. Diese Funktionalität wird in Verbindung mit dem TCPProtokoll ermöglicht. Dieses Verfahren trägt zur Flusskontrolle bei. Die Hauptaufgabe besteht darin, überlastete Prozessoren und Netzwerkschnittstellen zu verhindern.

2.7.4

ICMP-Type 5

ICMP-Type 5 (Redirect) wird zur Umlenkung von Routen verwendet. Wird ein Router verwendet, um ein Paket zuzustellen, und kennt dieser Router zusätzlich einen besseren Pfad zum Ziel als den, der über ihn selbst führt, so kann der Router zum Absender des betreffenden Pakets eine ICMP-Redirect-Nachricht senden. Der Absender wird daraufhin die eigene Routingtabelle so abändern, dass er seine Pakete über den vom Router empfohlenen „besseren“ Router sendet. Alternativ kann der Absender die RedirectMeldung ignorieren. Via ICMP Redirect können Datagramme zu einem Host (Code 1), zu einem Netzwerk (Code 0) oder Type-of-Service-basierend für einen Zielhost (Code 3) oder ein Zielnetzwerk (Code 2) umgeleitet werden.

2.7.5

ICMP-Types 9 und 10

ICMP-Type 9 (Router Advertisement) wird zur Bekanntgabe von Routern verwendet, während Type 10 (Router Solicitation) diese Meldung anfordert. So kann ein Host sich über die im Netzwerk befindlichen Router informieren und seine Routingtabelle selbst konfigurieren.

38

2.7.6

2 Grundlagen der Netzwerktechnik

ICMP-Type 11

Eine Nachricht vom Type 11 (Time Exeeded for Datagram) wird versandt, wenn die TTL eines IP-Datagramms abgelaufen ist. Der Host, bei dem die TTL den Wert 0 erreicht, versendet diese Nachricht an den ursprünglichen Absender des Datagramms. Im Normalfall ist der ICMP-Code dann 0. Kommt jedoch eines (oder mehrere) von mehreren Fragmenten nicht an, so wird der ICMP-Code auf den Wert 1 gesetzt. Wird zum Beispiel versucht, dem Host www.google.de ein Echo Request zu senden, das mit einer TTL von 1 versehen ist, so wird dieses Datagramm (wenn man sich nicht gerade im entsprechenden Subnetz des Hosts befindet) sein Ziel nicht erreichen. Stattdessen wird der nächste Router, der die TTL auf den Wert 0 dekrementiert, ein ICMP-Type11-Datagramm zu dem Host zurücksenden, der das ICMP-Echo-Paket gesendet hat. Eine Betrachtung der zwei Pakete verrät mehr Einsicht: 1 9 : 0 2 : 5 2 . 0 3 0 1 1 8 1 9 2 . 1 6 8 . 0 . 1 > 2 1 6 . 2 3 9 . 5 9 . 1 0 4 : icmp : e c h o r e q u e s t ( i d : 5 d56 s e q : 1 0 ) [ t t l 1 ] ( i d 8 9 2 2 ) 1 9 : 0 2 : 5 2 . 0 3 1 0 3 3 1 9 2 . 1 6 8 . 0 . 2 > 1 9 2 . 1 6 8 . 0 . 1 : icmp : time exceeded in−t r a n s i t f o r 1 9 2 . 1 6 8 . 0 . 1 > 2 1 6 . 2 3 9 . 5 9 . 1 0 4 : icmp : e c h o r e q u e s t ( i d : 5 d56 s e q : 1 0 ) [ t t l 0 ] ( i d 8 9 2 2 ) ( DF ) ( t t l 2 5 5 , i d 1 1 1 2 3 ) Zu sehen ist hier, dass der Host 192.168.0.1 ein ICMP-Echo-Request an den Host 216.239.59.104 sendet. Dies jedoch kommt nur bis zum Router des lokalen Subnetzes (in diesem Fall ist dies der Router mit der IP-Adresse 192.168.0.2). Der Router 192.168.0.2 sendet nun die Meldung an den Host 192.168.0.1 zurück, dass die TTL des ICMP-Datagramms abgelaufen ist.

2.7.7

ICMP-Type 12

Ein Parameter Problem (ICMP-Type 12) liegt vor, wenn im Optionsbereich des IPHeaders ein dem Host unbekannter Parameter gefunden wurde. Der Host verwirft dieses Datagramm und sendet ICMP-Type 12 zum Sender zurück.

2.7.8

Weitere ICMP-Typen

Es gibt noch einige weitere ICMP-Typen, doch sollten an dieser Stelle nur die wichtigsten von ihnen besprochen werden. Eine vollständige Liste aller ICMP-Parameter erhalten Sie bei der IANA unter http://www.iana.org/assignments/icmp-parameters [10].

2.8 Internet Layer: IGMP

2.8

39

Internet Layer: IGMP

Das Internet Group Management Protocol (IGMP, Protokollnummer 2) wird zur Verwaltung von IPv4-Multicast-Gruppen verwendet. Die aktuelle Version IGMPv3 wurde 2002 durch RFC 3376 standardisiert. IGMP verwendet explizit für Multicast vorgesehene IPAdressen (Bereich 224.0.0.1–239.255.255.255 [11]), um die Adressierung einer Multicast-Gruppe zu ermöglichen. Die Möglichkeit des Multicast-Sendens ist besonders bei Radio- und Videoübertragungen von Belang.

2.8.1

Der IGMPv2-Header

Der Einfachheit halber betrachtet dieses Kapitel primär IGMPv2. Der IGMPv2-Header ist recht simpel aufgebaut. Im Folgenden werden die einzelnen Felder des Headers besprochen (Abb. 2.11). Das Type-Feld kann einen der folgenden Werte enthalten: • • • •

Membership Query (0 × 11) Version 1 Membership Report (0 × 12) Version 2 Membership Report (0 × 16) Version 2 Leave Group (0 × 17)

Ein Multicast-Router sendet Membership Querys zu den Hosts seines Netzwerks. Dies hat den Zweck herauszufinden, welche Multicast-Gruppen welchem lokalen Teilnehmer zugeordnet sind. Dabei unterscheidet man zwischen einer generellen Query, die an alle Gruppen gerichtet ist, und einer gruppenspezifischen Query, welche sich an eine einzelne Gruppe richtet. Dabei wird die Zieladresse 224.0.0.1 verwendet. Ein Host sendet darauf als Bestätigung ein Reply-Paket und verwendet dabei als Zieladresse die Adresse der Multicast-Gruppe, die er zudem auch im Feld Group Address des IGMP-Headers angibt. Ein Host kann an eine Gruppe senden, in der er selbst kein Mitglied ist, und kann gleichzeitig Mitglied in verschiedenen Gruppen sein. Die Maximum Response Time ist nur in Querys gesetzt und gibt die Zeitspanne (in Zehntelsekunden) an, die der Router auf einen Membership Report wartet, bevor er den Host aus der Verteilerliste der Gruppe entfernt.

Abb. 2.11 Aufbau des IGMP-Headers

40

2 Grundlagen der Netzwerktechnik

Das Feld Checksum sollte Ihnen bereits von IP und ICMP bekannt sein. Das Feld Group Adress enthält die Adresse einer Multicast-Gruppe, an die ein IGMP-Paket versendet wird. In den oben erwähnten „generellen“ Querys wird die Gruppenadresse mit Nullen überschrieben. In IGMPv3 werden im Header zusätzlich die Senderquellen samt eines Adressvektors und Robustness-Werten übertragen, wodurch der Headeraufbau komplexer wird. Im Kontext dieses Buches sind diese Features allerdings nicht von Bedeutung.

2.9

Internet Layer: IPv6

Der Nachfolger der Internet Protokollversion 4 wurde Version 6. Sie wurde bereits im Dezember 1995 in RFC 1883 beschrieben [4] und – wie wohl alle wichtigen Protokollstandards – erfuhr der Standard in den folgenden Jahren wiederholt Überarbeitungen. Erste IPv6-Netze existierten seit 1996 (insbesondere das „6Bone“-Netz). Es gab verschiedene Gründe dafür, eine neue Version des Protokolls zu entwickeln. Der wohl bekannteste Grund ist der, dass der Adressraum (es gibt über 4 Milliarden IPv4-Adressen) knapp wurde. Zu Anfang ging man recht großzügig mit der Vergabe der IP-Adressen um, und einige große Institutionen und Firmen in den Vereinigten Staaten bekamen gleich ganze Class-A-Netze zugeteilt. Europa kam bei der Verteilung der Adressen noch relativ gut weg, doch Asien und Afrika leiden unter Adressknappheit. Eine Maßnahme gegen die stetig schwindende Anzahl verfügbarer IPv4-Adressen ist die Network Address Translation (NAT), bei der viele private IP-Adressen wenige private IP-Adressen zusammen nutzen. Doch auf Dauer wird dies nicht mehr ausreichend sein – besonders nicht, wenn immer mehr mobile Geräte wie Handys und diverse Hausgeräte (Kühlschränke etc.) miteinander vernetzt werden. Ein weiterer wichtiger Grund für die Einführung von IPv6 ist die zumindest leicht verbesserte IT-Sicherheit im Vergleich zu IPv4. So ist IPSec Bestandteil von IPv6, und der Aufbau des Headers ist logischer und flexibler. Weiterhin unterstützt IPv6 eine Autokonfiguration der Netzwerkverbindungen ähnlich der des Dynamic Host Configuration Protocols (DHCP), Quality of Service (QoS), Mobile IP und Multicast. Anders formuliert macht IPv6 einige bisherige Protokolle überflüssig. In Abb. 2.12 sehen Sie den IPv6-Header. Wie bei IPv4 werden die ersten 4 Bits zur Angabe der Versionsnummer (Version) verwendet. Die nächsten 8 Bits stellen die Traffic Class dar. Diese Traffic Class dient der Prioritätsangabe, etwa wie beim DSCP-Feld des IPv4-Headers. Die folgenden 20 Bits (Flow Label genannt) dienen der Identifikation eines Datenstroms – hiermit sollen auch Performancezuwächse in Routern möglich sein, da diese über einen Hash auf diese Zahl eventuelle Fragmente schneller zusammensetzen können. Die Länge des Payloads (Payload Length) wird in den nächsten 16 Bits angegeben. Hierbei ist zu beachten, dass mögliche zusätzliche IPv6-Headererweiterungen als Payload gelten. Der Payload berechnet sich also aus den IPv6-Erweiterungsheadern

2.9 Internet Layer: IPv6

41

Abb. 2.12 Aufbau des IPv6-Headers

(dazu später mehr) plus den Headern der höheren Protokolle plus dem Payload des Protokolls der höchsten eingekapselten Schicht. Zum Beispiel kann die Payload Length eines HTTP-Pakets die Summe aus der Größe eines optionalen IPv6-Headers, des TCPHeaders, des HTTP-Headers und des HTTP-Payloads sein. Das Feld Next Header gibt an, wie der nächste Header auszuwerten, besser gesagt, an welchen Protokollhandler das Paket weiterzugeben ist. Typische Werte sind 6 (TCP) oder 17 (UDP). Unter IPv4 heißt dieses Feld Protocol. Dieses Feld wird aber auch zur Angabe der IPv6-Extension Header verwendet. Das sogenannte Hop Limit hat die gleiche Funktion wie das Feld Time to Live bei IPVersion 4. Es wird ebenfalls durch einen 8 Bit langen Wert (vom Typ unsigned integer) repräsentiert, dessen Wert bei jedem Hop um 1 verringert wird. Erreicht das Feld den Wert 0, wird das Paket verworfen. Typische Werte (wie auch bei IPv4) werden bei heutigen Betriebssystemen nicht mehr auf 255, sondern auf einen Wert ≥64 gesetzt. Routen über das Internet sind in den meisten Fällen nicht länger als 32 Hops [31]. Es folgenden zwei jeweils 128-Bit lange IPv6-Adressen für Sender und Empfänger der Nachricht.

2.9.1

IPv6-Adressen

IPv6 hat im Vergleich zu IPv4 genau viermal so große Adressen. IPv6-Adressen werden dabei in Hex-Form zu jeweils 16 Bit mit getrennten Doppelpunkten dargestellt.16 Ein Beispiel für eine IPv6-Adresse wäre etwa: 1234:1234:2342:2342:1234:1234:2342:2342

16 Selbstverständlich sind auch andere Repräsentationen von IPv4-Adressen möglich, etwa als HexDarstellung. Die Adresse 127.0.0.1 kann entsprechend als 0x7f000001 dargestellt werden.

42

2 Grundlagen der Netzwerktechnik

Folgen ein oder mehrere 16-Bit-Gruppen, die den Wert 0000 haben, aufeinander, kann dies durch zwei Doppelpunkte dargestellt werden. Die Adresse 1234:1234:2342:0000:0000:0000:2342:2342 könnte also auch folgendermaßen dargestellt werden: 1234:1234:2342::2342:2342. Es ist immer nur eine einzige Doppelpunkt-Gruppe bei der Darstellung durch zwei Doppelpunkte pro Adressangabe erlaubt. Damit Sie einen Eindruck davon bekommen, wie viele Adressen es theoretisch gibt: Es sind ganze 2128 = 340.282.366.920.938.463.463.374.607.431.768.211.456 Stück. IPv6-Adressen können automatisch für Netzwerk-Interfaces generiert werden. Hierzu wird die Hardware-Adresse (MAC-Adresse, 48 Bit) mit einem Prefix versehen. Dieses Schema ist durch den IEEE EUI-64-Standard spezifiziert. Alternativ können Adressen mit der IPv6-Version von DHCP (DHCPv6) und ICMPv6 vergeben und bekanntgegeben werden. Weiterhin besteht mit Cryptographically Generated Addresses (CGA) eine Möglichkeit, Signaturen öffentlicher, kryptografischer Schlüssel in IPv6-Adressen einzurechnen (siehe Abschn. 8.3.3). Localhost: Um mit dem eigenen Rechner zu kommunizieren, gibt es die IPv6-Adresse ::1, sie verwendet das Subnetz ::1/128.

2.9.2

IPv6 Header Extensions

Ein IPv6-Header besteht im Minimalfall nur aus dem Basis-Header. Diesen lernten Sie bereits oben kennen. Doch neben diesem Header gibt es noch die folgenden weiteren Header (wobei die Reihenfolge der tatsächlichen Reihenfolge der Aneinanderkettung entspricht, diese kann nämlich nicht willkürlich gewählt werden): • Hop-by-Hop Options und Destination Options: Hier können Optionen für jeden Host, den ein Paket passiert (Hop-by-Hop) oder für das Ziel des Pakets (Destination) festgelegt werden. RFC 2460 definiert zunächst nur 2 Bits (also 4 Kombinationen) der 8 Bits mit Funktionen, die insgesamt zur Verfügung stehen. Dabei kann eine Option entweder übergangen (0) oder das Paket (mit einer Bedingung) verworfen werden (1–3). • Routing: Routing-Optionen ähnlich denen von IPv4; es kann eine Liste von Hops festgelegt werden, die das Paket passieren soll. • Fragment: Dieser Header bietet eine ähnliche Funktionalität wie die FragmentFelder des IPv4-Headers – auch dieser besteht aus dem Fragment-Offset, dem MoreFragments-Bit und einem Identifikationsfeld. • Authentication: Der Authentication-Header (kurz AH) gewährleistet die Authentizität eines Datenpakets. In Abschn. 5.3.1 wird dieses Thema genauer besprochen.

2.10 Internet Layer: ICMPv6

43

Abb. 2.13 Aneinanderreihung der IPv6-Extension Headers

Der Authentication-Header kann auch in Verbindung mit dem ESP-Header verwendet werden. • Encapsulation Security Payload: Der Encapsulation-Security-Payload-Header (kurz ESP) wird in Abschn. 5.3.1 detailliert erläutert. Er sichert sowohl Authentizität als auch Vertraulichkeit. ESP kann mit dem AH kombiniert werden. • Destination Options: Optionen für das Ziel eines eingekapselten Pakets. Jeder Extension Header sollte nur ein einziges Mal in einem IPv6-Paket vorkommen. Die einzige Ausnahme ist der Header Destination Options, der bis zu zweimal vorkommen darf. Ihnen dürfte vielleicht aufgefallen sein, dass die Destination Options oben zweimal gelistet sind. Dies liegt daran, dass nur das erste Vorkommen der Destination Options für das eigentliche IPv6-Paket gilt. Das zweite Vorkommen bezieht sich auf ein eingekapseltes IPSec-Paket. Jeder Header gibt bei IPv6 den nächsten Header an (über das Feld Next Header). Die Aneinanderreihung der Header ist in Abb. 2.13 dargestellt. Wenn ein IPv6-Paket beispielsweise aus einem IPv6-Header, einem Routing Header und einem TCP-Segment besteht, dann gibt das Next-Header-Feld im Basis-Header an, dass es sich beim folgenden Header um einen Routing Header handelt. Der Routing Header gibt wiederum an, dass der folgende Header ein TCP-Header ist. Der Wert 59 im Feld Next Header gibt an, dass dem aktuellen Header kein weiterer Header folgt.

2.10

Internet Layer: ICMPv6

Wie auch bei IPv4, so wurde auch für IPv6 ein ICMP-Protokoll entwickelt. Ursprünglich wurde ICMPv6 in RFC 1885 spezifiziert [2]. Das Protokoll bekam die Protokollnummer 58 und ist ähnlich zu seinem Vorgänger ICMPv4 aufgebaut. Jeweils 8 Bit stellen den ICMP-Type und -Code dar. Es folgen eine 16-Bit Checksum und die typabhängigen Daten. Seit Version 6 des ICMP-Protokolls sind die ICMP-Typen in zwei Bereiche unterteilt: Fehlermeldungen und Informationsmeldungen. Den Fehlermeldungen wurde der Typbereich von 0 bis 127, den Informationsmeldungen der Bereich 128 bis 255 zugewiesen. Zudem verfügt die neue ICMP-Version nun auch über Multicast-Fähigkeiten, wie sie das IGMP-Protokoll zur Verfügung gestellt hat, und Möglichkeiten zur automati-

44

2 Grundlagen der Netzwerktechnik

schen Adressvergabe (DHCP-Ersatz), Routingkonfiguration und der Neighbour Discovery (ARP-Ersatz17 ). Es gibt folgende ICMPv6-Fehlermeldungen: • 1. Destination Unreachable: Das Zielsystem ist aus einem Grund, der im Code genauer spezifiziert wird, nicht erreichbar. • 2. Paket too big: Das Paket ist zu groß für einen Netzabschnitt, weil es größer als die zulässige MTU ist. Diese Meldung wird nur versandt, wenn das DF-Flag gesetzt war. • 3. Time Exeeded: Das Hop-Limit errichte den Wert 0 und das Datagramm wurde verworfen. • 4. Parameter Problem: Der Header des Paketes enthielt Fehler und konnte daher nicht korrekt ausgewertet werden. Außerdem gibt es folgende ICMPv6-Informationsmeldungen: • 128. Echo Request: Eine ICMP-Echo Anforderung (analog zum ICMPv4 Echo Request). • 129. Echo Reply: Die Antwort auf obige Anforderung (analog zum ICMPv4 Echo Reply). • 130. Group Membership Query: Hierbei handelt es sich um eine Funktionalität, wie sie bereits von IGMP Queries bekannt ist. • 131. Group Membership Report: Hierbei handelt es sich um eine Funktionalität, wie sie bereits vom IGMP Reports bekannt ist. • 132. Group Membership Reduction: Dieser Typ wird zum Austritt aus einer MulticastGruppe verwendet (analog zu IGMP Leave Group). • 133. Router Solicitation: Anfrage nach einem Router (analog zu ICMPv4). • 134. Router Advertisement: Router-Bekanntmachung (analog zu ICMPv4). • 135. Neighbour Solicitation: Anfrage nach der MAC-Adresse eines anderen Hosts im Netz. Diese Funktionalität ersetzt das Adress Resolution Protocol. • 136. Neighbour Advertisement: Dieser ICMP Type gibt die MAC-Adresse einer Schnittstelle bekannt und ist analog zu einem ARP-Reply zu sehen. • 137. Redirect: Dieser Typ ist ebenfalls schon von ICMPv4 bekannt und wird zur Umleitung von Routen verwendet.

17 Für Neighbour Discovery kommt das sogenannte Neighbour Discovery Protocol (NDP) als Teil von ICMP zum Einsatz.

2.11 Transport Layer: UDP

2.11

45

Transport Layer: UDP

Die Abkürzung UDP steht für User Datagram Protocol. UDP wurde in RFC 768 spezifiziert [19]. UDP-Pakete werden als Datagramme bezeichnet. Bei UDP handelt es sich um ein verbindungsloses Transport-Layer-Protokoll. Das heißt, für UDP müssen keine Verbindungen auf-, abgebaut und verwaltet werden. Datagramme werden unabhängig voneinander betrachtet. Da UDP nur über minimale Funktionalitäten bezüglich der Fehlerkorrektur – nämlich eine Checksum – verfügt, bleibt die Prüfung des Datenflusses, falls dieser kontrolliert ablaufen muss, dem Application Layer überlassen. Aufgrund dieser Eigenschaft verfügt UDP zwar über einen recht kleinen Header, wird aber generell nicht in Applikationen eingesetzt, bei denen eine gesicherte Nachrichtenübertragung gewährleistet sein muss. Einsatzgebiete für UDP sind in der Regel solche, bei denen Datagramme in periodischen Abständen (Aktualisierungs-)Nachrichten übertragen sollen oder beim Verlust einer Nachricht keine Schwierigkeiten auftreten, da Anfragen einfach wiederholt werden (etwa bei DNS oder DHCP).

2.11.1 Der UDP-Header Der UDP-Header ist, wie bereits angesprochen, nicht sonderlich groß, da er nur die für den Kernel des Betriebssystems wichtigsten Informationen beinhaltet. Der UDP-Header ist in Abb. 2.14 dargestellt und hat eine Größe von 8 Bytes (zum Vergleich: der TCP-Header hat eine Größe von 20 Bytes). Die ersten 32 Bits bestehen aus dem Source Port (Quellport) und dem Destination Port (Zielport). Es folgen die Längenangabe des Payloads und die Checksum zu jeweils 16 Bits. Da jeweils 16 Bits pro Port zur Verfügung stehen, was auch beim TCP-Protokoll der Fall ist, können also maximal 65.535 verschiedene Ports adressiert werden, da der Null-Port nicht verwendet wird. Generell gilt: Die ersten (meist 1024) Ports sind in dem Sinne „privilegierte“ Ports, als dass sie nur über administrative Rechte gebunden werden

Abb. 2.14 Der UDP-Header

46

2 Grundlagen der Netzwerktechnik

können. Die Portanzahl ist dabei betriebssystemspezifisch. Folglich kann ein Webserver an Port 80 nur mit Root-Rechten gebunden werden. Unter den meisten gängigen Systemen ist es möglich, die UDP-Checksum zu vernachlässigen. Sie kann mit Kommandos wie sysctl abgeschaltet werden, was sich auf stark belasteten Systemen positiv auf deren Performance auswirken kann, allerdings auf Kosten der Verbindungsqualität. Die Checksum berechnet sich (und dies ist, wie Sie später sehen werden, auch beim TCP-Protokoll der Fall) aus dem Protokoll-Header, dem Payload und einem sogenannten Pseudoheader. Der Pseudoheader beinhaltet die Source- und Destination-Adresse aus dem Internet Layer, die Protokoll-Nummer aus dem Internet Layer und die Länge von UDPHeader (beziehungsweise TCP-Header) sowie Payload. Typische UDP-Dienste sind das Domain Name System (DNS), (zumindest ältere) Implementierungen des Network Filesystems (NFS), DHCP und das Network Time Protocol (NTP).

2.12

Transport Layer: TCP

Das Transmission Control Protocol (TCP, ursprünglich in RFC 761 spezifiziert [18]) ist das wohl meistgenutzte Transport-Layer-Protokoll der TCP/IP-Protokoll-Suite. TCP wurde durch RFC 793 spezifiziert. Es gibt eine große Anzahl von Anwendungen, deren Protokolle auf TCP aufbauen. Die bekanntesten von ihnen sind wohl die folgenden (die Portangaben sind Standardports; sie können variieren): • WWW (Protokolle: HTTP (Port 80), HTTPS (Port 443)) • E-Mail (Protokolle: SMTP (Port 25), POP3 (Port 110), IMAP (Port 143), IMAPS (Port 993)) • sicheres Arbeiten auf einem entfernten Rechner (Protokoll: SSH (Port 22)) • Dateiserver (Protokoll: FTP (Port 21 sowie Port 20 (DATA-Port)) und SFTP (in der Regel gemeinsam mit SSH über Port 22))

2.12.1 TCP-Reliability TCP-Datenpakete (man bezeichnet diese als Segmente) werden, im Gegensatz zu UDPDatagrammen, nicht als einzelne Nachricht (Message), sondern als Datenstrom (Stream) versendet. Dieser Datenstrom muss kontrolliert werden, sodass die Reihenfolge der Daten in diesem Stream nicht verfälscht wird. Hierfür wird die sogenannte Sequenznummer (Sequence Number) verwendet. Jedes Segment kann durch diese Sequence Number in die richtige Position des Streams eingeordnet werden. Die Seite, die das Segment empfängt, bestätigt die empfangenen Daten anschließend mit der sogenannten Bestätigungsnummer (Acknowledgement Number). Diese gibt aber auch die nächste, vom empfangenden Host erwartete Sequence Number an. Stimmen die erwartete und die empfangene Sequence

2.12 Transport Layer: TCP

47

Abb. 2.15 Ein Beispiel für TCP-Reliability

Number nicht überein, kann TCP auf ein verlorengegangenes Segment schließen und sendet das verloren geglaubte Segment erneut aus. Auf diese Weise stellt TCP sicher, dass Datensegmente nicht verlorengehen und in der richtigen Reihenfolge ankommen. In Abb. 2.15 versendet Host A Daten an Host B. Host B empfängt und bestätigt diese. Darauf sendet Host A erneut Daten. Diese jedoch gehen unterwegs auf Grund von Netzwerkproblemen verloren, sodass Host B keine Bestätigung an Host A für die empfangenen Daten versendet. Daraufhin versendet Host A diese Daten erneut, in der Hoffnung, dass diese nun ankommen.18 Werden nun noch Sequenznummern und Bestätigungsnummern in die Betrachtung der Verbindung integriert, so gilt Folgendes: Ein Paket mit einer Sequenznummer X muss mit einer Bestätigungsnummer X+n bestätigt werden, wobei n das neue Datenoffset ist. Die Bestätigungsnummer ist dabei die für das folgende Paket erwartete Sequenznummer. Die erste Sequenznummer einer Verbindung wird von jedem der beiden Hosts, die miteinander kommunizieren, selbst gewählt (randomisiert) und wird als Initial Sequence Number (ISN) bezeichnet. Dabei hat jede Seite der Verbindung eine eigene ISN, weil TCP jede Kommunikationsrichtung separat verwaltet.

18 Die Zahlen hinter den Rauten entsprechen der Paketnummer, sie sind nicht mit der Sequence Number oder der Acknowledgement Number zu verwechseln.

48

2 Grundlagen der Netzwerktechnik

Es lässt sich zum Thema TCP-Reliability klärend anmerken, dass das Ziel für TCP also nicht darin besteht, einzelne Pakete ans Ziel zu bringen (dies ist die Aufgabe von IP). Stattdessen besteht die Aufgabe darin, den gesamten Payload zuverlässig zu liefern [6]. Dabei kann es vorkommen, dass die Inhalte mehrerer kleiner, aber verlorengegangener, Pakete anschließend durch ein einziges Paket mit dem Gesamtpayload verschickt werden, wenn dies im Sinne der Reliability durchführbar ist [6].

2.12.2 Sende- und Empfangspuffer TCP arbeitet mit sogenannten Sende- und Empfangspuffern. In diesen werden, wie sich wohl bereits erahnen lässt, die empfangenen beziehungsweise versendeten Daten gespeichert. Doch wozu speichert man diese überhaupt zwischen? Die wichtigsten Gründe hierfür sind, dass TCP Daten nur ab einer bestimmten Anzahl von Bytes im Sendepuffer versendet beziehungsweise nur eine gewisse Anzahl von Daten pro Applikation im Empfangspuffer zwischenspeichert, bevor die Applikation die Daten abholen muss. Es gibt einige Ausnahmeanwendungen (wie das Telnet-Protokoll, das ein unsicheres Arbeiten auf entfernten Rechnern ermöglicht), die diese Funktion nicht nutzen. Wird die Pufferung nicht benutzt, dann verursacht dies allerdings weitaus höhere Verbindungskosten. Ein TCP-Header ist im Normalfall 20 Bytes groß. Er baut wiederum auf einem IP-Header (ebenfalls 20 Bytes) auf. Und wenn nun ein einzelnes Zeichen via Telnet in einem eigenen Paket versendet wird, dann werden auch jedes Mal diese 40 Bytes großen Headerdaten pro Paket übertragen. Die Geschwindigkeit von großen Datenübertragungen wäre bei dieser Übertragungsart sehr wahrscheinlich eine Katastrophe. Bei Anwendungen wie Telnet (oder SSH), bei denen sofort auf jedes eingetippte Zeichen reagiert werden muss, führt an einer solchen Umsetzung allerdings kein Weg vorbei.

2.12.3 Flusskontrolle (Flow-Control) Wie Sie weiter unten sehen werden, verwendet TCP im Header ein Feld mit der Bezeichnung Window Size. Dieses teilt dem Empfänger mit, wie viele Daten der Sender im Empfangspuffer noch aufnehmen kann. Der Empfänger sendet daraufhin maximal so viele Daten, wie angegeben wurden, an den Sender zurück. Dieses Feature bezeichnet man auch als Receive Window Sizing. Ein weiterer Flow-Control-Mechanismus nennt sich fast genauso, nämlich Sliding Receive Windows. Hierbei wird nicht abgewartet, bis die Bestätigung eines bereits versendeten Segments eintrifft, sondern es wird – in der Hoffnung, dass eine Bestätigung schon noch kommen wird – bereits vorsorglich das nächste Segment abgeschickt. Dies kann die Verbindungsperformance steigern. Weitere bedeutsame Verfahren zur Flusskontrolle, etwa Slow Start, existieren, sind aber für dieses Buch nicht von zentraler Bedeutung.

2.12 Transport Layer: TCP

49

2.12.4 Header Viele der oben angesprochenen Informationen werden Sie – zumindest indirekt – im Header wiederfinden (Abb. 2.16). Wie bei UDP werden die ersten 32 Bits des Headers für die jeweils 16 Bit langen Felder Source Port und Destination Port verwendet. Es folgt eine 32 Bits lange Sequenznummer (Sequence Number), die die Position des Payloads im Datenstream angibt. Die Startnummer wird dabei als Initial Sequence Number (ISN) bezeichnet und bei gesetztem SYN-Flag im Three-Way-Handshake übergeben (dazu gleich mehr). Als ISN wird je nach Implementierung ein Zufallswert oder 1 verwendet; anschließend wird aufwärts gezählt. Hinter der Sequence Number folgt eine ebenfalls 32 Bits lange Bestätigungsnummer (Acknowledgement Number), die bereits die empfangenen Daten angibt. Dadurch, dass beide Systeme, zwischen denen eine TCP-Verbindung besteht, diese beiden Nummern verwalten, kann festgestellt werden, ob auch alle Datenpakete tatsächlich angekommen sind und welche verlorengingen und demzufolge neu gesendet werden müssen. Das nächste Feld (Offset, 4 Bits) gibt die Headerlänge in Wörtern (je 32 Bits) an. In der Regel beträgt dieser Wert 5 und wird bei der Verwendung der optionalen Felder (etwa TCP-Timestamps) erhöht. Bei den nächsten vier Bits handelt es sich um einen reservierten Bereich, der mit Nullen überschrieben wird. Für die Flags stehen 8 Bits zur Verfügung. Jedes gesetzte Bit hat eine spezielle Funktionalität, wobei zu beachten ist, dass es sich bei TCP um ein Protokoll handelt, dass beide Kommunikationsrichtungen (A → B und B → A) separat verwaltet, was im Zusammenhang mit dem Management der Verbindung, wie Sie im nächsten Abschnitt sehen werden, wichtig ist:

Abb. 2.16 Der TCP-Header

50

2 Grundlagen der Netzwerktechnik

• 0 × 01 (FIN): Der Sendevorgang des Kommunikators (Sender) zum Rezipienten (Empfänger) wird beendet. • 0 × 02 (SYN): Die Verbindung vom Kommunikator zum Rezipienten wird aufgebaut. • 0 × 04 (RST): Verbindungsreset. • 0 × 08 (PSH): Die Payload wird direkt an den Applikation Layer weitergereicht und nicht im Sendepuffer beziehungsweise Empfangspuffer zwischengespeichert (PUSH), siehe Abschn. 2.12.2. • 0 × 10 (ACK): Sofern dieses Bit gesetzt ist, ist die Acknowledgement Number gültig. • 0 × 20 (URG): Der Dringlichkeitszeiger (Urgent Pointer) ist gültig. • 0 × 40 (ECE) und 0 × 80 (CWR): Die Flags Explicit Congestion Notification und Congestion Window Reduced sind eine Erweiterung des TCP-Protokolls zum Umgang mit Netzwerküberlastungen. Die ECN-Bits des IP-Headers (siehe Abschn. 2.6) stehen hiermit in Verbindung. Das Empfangsfenster (Window) enthält eine Zahl. Diese Zahl gibt dem Rezipienten des Pakets an, wie viel Payload er in einem Paket an den Kommunikator zurücksenden darf. Kann der Kommunikator beispielsweise noch 1410 Bytes in seinen TCP-Buffer aufnehmen, beträgt der Wert des Empfangsfensters 1410. Die TCP-Checksum wird auf dieselbe Art und Weise wie beim UDP-Protokoll (nämlich mit einem zusätzlichen Pseudo-Header) berechnet. Der Urgent Pointer zeigt auf vorrangig zu behandelnde Daten in der Payload. Er ist jedoch nur gültig, wenn das URG-Flag gesetzt ist.

2.12.5 Kommunikationsphasen TCP-basierte Kommunikation besteht im Wesentlichen aus drei Phasen, dem Verbindungsaufbau, der Verwendung einer aufgebauten Verbindung und dem Abbau der eingerichteten Verbindung. Verbindungsaufbau: Ein Host, der von sich aus eine Verbindung einleitet, führt ein Active Open aus, und der Host, der die Verbindung akzeptiert, führt ein Passive Open aus. Das heißt, bei einem Passive Open bietet ein Host auf einem bestimmten Port seinen TCPbasierten Dienst an. Ein Host, der diesen Dienst nutzen möchte, verbindet sich mit dem jeweiligen Host aktiv mit dem jeweiligen Port. Eine Verbindung wird durch einen sogenannten Three-Way-Handshake eingeleitet. Dieser Three-Way-Handshake wird deshalb so betitelt, weil er drei TCP-Segmente benötigt, um eine Verbindung beidseitig zu initialisieren. Beim ersten Paket jeder Seite wird dabei das SYN-Flag gesetzt. Dies wird von der Gegenseite jeweils mit einem gesetzten ACK-Flag bestätigt. Da die Seite, die ein Passive Open ausführt (in Abb. 2.17 der Empfänger), die Bestätigung des SYN-Segments gleich mit in das eigene Segment zum Verbindungsaufbau einbringen kann, werden von dieser Seite keine zwei, sondern lediglich ein einziges Segment versendet.

2.12 Transport Layer: TCP

51

Abb. 2.17 SYN- und ACK-Flags beim Three-Way-Handshake

Bei der Betrachtung des Datenverkehrs beim Initialisieren einer Verbindung ist wird das Verfahren einfacher ersichtlich. Der Host yorick.sun verbindet sich im folgenden Listing mit dem Host eygo.sun auf Port 22. Die Ausgabe stammt von den Paketen, die der Host eygo.sun auf seiner Netzwerkschnittstelle sendet und empfängt: eygo # tcpdump − i ne3 tcpdump : l i s t e n i n g on ne3 2 0 : 1 5 : 2 4 . 8 8 3 1 7 6 y o r i c k . s u n . 1 1 8 1 > eygo . s u n . s s h : S 2 5 9 1 2 8 1 2 9 5 : 2 5 9 1 2 8 1 2 9 5 ( 0 ) win 16384 ( DF ) 2 0 : 1 5 : 2 4 . 8 8 3 2 6 6 eygo . s u n . s s h > y o r i c k . s u n . 1 1 8 1 : S 1 9 6 5 1 6 3 4 5 9 : 1 9 6 5 1 6 3 4 5 9 ( 0 ) a c k 2591281296 win 16384 ( DF ) 2 0 : 1 5 : 2 4 . 8 8 3 5 4 2 y o r i c k . s u n . 1 1 8 1 > eygo . s u n . s s h : . a c k 1 win 17520 ( DF ) tcpdump zeigt uns an, welche Flags gesetzt sind. In den ersten beiden Paketen ist das SYN-Flag (S) gesetzt. ACK-Flags werden nicht dargestellt und sind durch ack gekennzeichnet. Ist kein von tcpdump explizit gekennzeichnetes Flag gesetzt, wird ein Punkt ausgegeben – so wie im dritten Paket. Aufmerksamen Lesern wird bereits aufgefallen sein, dass es sich bei den Nummern hinter dem SYN-Flag um die Sequence Number handelt. Die ersten zwei Pakete beinhalten die ISN. Das zweite Paket gibt die eigene ISN von eygo.sun an und bestätigt die ISN von eygo zudem noch mit der Acknowledgement Number (ISN von eygo + 1).

52

2 Grundlagen der Netzwerktechnik

Datenkommunikation: Ist die TCP-Verbindung beidseitig eingerichtet, können beide Seiten mit dem Datentransfer beginnen. Dabei bestätigen sich beide Seiten gegenseitig die empfangenen Daten mit den Acknowledgement Numbers. Im Falle des folgenden Listings wurde telnet.exe auf yorick.sun zum Verbindungsaufbau verwendet. Dabei wird jedes von Hand eingegebene Zeichen an den Server als Extra-Segment versendet und mit einem PSH-Flag (P) versehen. Längere Meldungen, die auf einmal übertragen werden, etwa Fehlermeldungen, können allerdings in einem Paket (statt in vielen separaten) gesendet werden. PSH erlaubt die sofortige Übertragung von Tastatureingaben und die sofortige Anzeige einer etwaigen Aktion (etwa das Erscheinen eines eingegebenen Buchstabens auf dem Bildschirm durch das Paket des Servers). 2 0 : 1 5 : 2 4 . 8 8 6 2 9 1 eygo . s u n . s s h > y o r i c k . s u n . 1 1 8 1 : P 1 : 2 4 ( 2 3 ) a c k 1 win 17520 ( DF ) 2 0 : 1 5 : 2 5 . 0 9 3 0 9 6 y o r i c k . s u n . 1 1 8 1 > eygo . s u n . s s h : . a c k 24 win 17497 ( DF ) 2 0 : 1 5 : 2 8 . 5 9 3 7 7 4 y o r i c k . s u n . 1 1 8 1 > eygo . s u n . s s h : P 1 : 3 ( 2 ) a c k 24 win 17497 ( DF ) 2 0 : 1 5 : 2 8 . 5 9 4 0 5 1 eygo . s u n . s s h > y o r i c k . s u n . 1 1 8 1 : P 2 4 : 4 3 ( 1 9 ) a c k 3 win 17520 ( DF ) Das erste Segment beinhaltet eine 22 Zeichen lange SSH-Versionsangabe und ein Newline-Zeichen, insgesamt also 23 Zeichen. Die Bestätigung erfolgt mit einem ACK von yorick.sun und der Acknowledgement Number 24, weil die ersten 23 Bytes empfangen wurden und als nächstes das Byte mit der Nummer 24 erwartet wird. Nach der Eingabe von Return (auf yorick, Nachrichtenlänge: 2 Bytes) wird die Eingabe seitens eygo mit einem Protocol mismatch „bestätigt“ – eine Fehlermeldung die daher kommt, dass die Return-Eingabe nicht vorgesehen war, und, wie Sie gleich sehen werden, die Verbindung geschlossen. Entsprechend der vorherigen Return-Eingabe wird für diese Kommunikationsrichtung die Acknowledgement Number 3 gesetzt. Verbindungsabbau: Beim Verbindungsabbau sendet die Seite, die das Senden von Daten einstellen will, ein Segment mit gesetztem FIN-Flag an die Gegenseite. Die Gegenseite bestätigt dieses Segment mit einem ACK. Da TCP Full-Duplex ist, kann die Seite, die das FIN bestätigte, noch immer Daten senden. Man spricht beim Schließen einer Verbindung analog zum obigen Three-Way-Handshake von einem Active Close beziehungsweise einem Passive Close. In Abb. 2.18 führt der Sender einen Active Close und der Empfänger einen Passive Close durch. Es zeigt sich analog zu Abb. 2.18 folgender Datenaustausch, wobei die vorherige Verbindung weitergeführt wurde, weshalb auch die Sequence Numbers und Acknowledgement Numbers weiterhin bestehen:

2.13 Application Layer: DHCP

53

Abb. 2.18 FIN- und ACK-Flags beim TCP-Verbindungsabbau

2 0 : 1 5 : 2 8 . 5 9 4 1 0 0 eygo . s u n . s s h > y o r i c k . s u n . 1 1 8 1 : F 4 3 : 4 3 ( 0 ) a c k 3 win 17520 ( DF ) 2 0 : 1 5 : 2 8 . 5 9 4 4 3 5 y o r i c k . s u n . 1 1 8 1 > eygo . s u n . s s h : . a c k 44 win 17478 ( DF ) 2 0 : 1 5 : 2 8 . 5 9 5 2 7 2 y o r i c k . s u n . 1 1 8 1 > eygo . s u n . s s h : F 3 : 3 ( 0 ) a c k 44 win 17478 ( DF ) 2 0 : 1 5 : 2 8 . 5 9 5 3 8 8 eygo . s u n . s s h > y o r i c k . s u n . 1 1 8 1 : . a c k 4 win 17520 ( DF ) Alternativ kann eine Verbindung selbstverständlich auch durch gesetzte RST-Flags terminiert werden; in solch einem Fall erfolgt ein abrupter Verbindungsabbruch.

2.13

Application Layer: DHCP

Das Dynamic Host Configuration Protocol (DHCP) dient der Konfiguration von Hosts in Netzwerken. Es wird in UDP eingekapselt, weshalb es als Protokoll des Application Layers besprochen werden muss. Die Hauptfunktion von DHCP ist die Vergabe von IPAdressen. Neben der IP-Adresse gibt es allerdings weitere Konfigurationsmöglichkeiten (etwa den zu verwendenden Standardrouter und DNS-Server).

54

2 Grundlagen der Netzwerktechnik

DHCP funktioniert gemäß einem einfachen Verfahren. Ein DHCP-Client erhält seine Konfiguration dabei von einem DHCP-Server. Zunächst sendet ein DHCP-Client ohne IP-Adresse eine sogenannte DHCP-DISCOVER-Nachricht per Broadcast in das lokale Netzwerk. Ein (oder mehrere) DHCP-Server antworten daraufhin mit einer DHCPOFFER-Nachricht (sie enthält eine IP-Adresse). Der DHCP-Client wählt einen der empfangenen DHCP-OFFER-Nachrichten aus und versendet daraufhin eine DHCPREQUEST-Nachricht an den ausgewählten DHCP-Server. Der DHCP-Server bestätigt mit einem DHCP-ACK und einer sogenannten Lease Time den DHCP-REQUEST des Clients. Alternativ kann der DHCP-Server auch mit einem DHCP-NAK eine Ablehnung der Anfrage signalisieren, etwa weil eine angebotene IPAdresse in der Zwischenzeit bereits an einen anderen DHCP-Client vergeben wurde. Die Lease Time gibt an, wie lang ein DHCP-Konfiguration gültig ist. Anschließend verwendet der Client die zugewiesene IP-Adresse (und restliche Konfigurationsparameter) bis zum Ablauf der Lease Time beziehungsweise bis er diese nicht mehr benötigt (in letzterem Fall informiert der DHCP-Client den DHCP-Server mit einer sogenannten DHCP-RELEASE-Nachricht). Nach Ablauf der Lease Time muss sich der Client erneut an den Server wenden, um eine Konfiguration zugewiesen zu bekommen.

2.14

Application Layer: HTTP

Zur Übertragung von Webseiten über das Internet und andere Netzwerke wird das zustandslose Protokoll HTTP (Hyper-text Transfer Protocol) verwendet. Bei HTTP handelt es sich um ein Klartext-Protokoll, das verschiedene Anfragen (sogenannte Methods) unterstützt, die vom Client an den Server gestellt werden können: • GET: Anfrage einer Ressource (optionale Parameter können mit meist stark begrenzter Länge über die Adresse übertragen werden). Eine Ressource kann beispielsweise eine HTML-Datei oder eine Bilddatei sein. • POST: Anfrage mit (textuellem oder binärem) Inhalt seitens des Clients an eine Ressource des Servers (etwa Übertragen von Eingabedaten oder Dateien). • HEAD: Mit HEAD kann, wie bei GET, eine Ressource angefragt werden. Anstelle der gesamten Response erhält der Client hierbei nur die Metainformationen, also den HTTP Response-Header als Antwort (und keinen Payload, also etwa HTML- oder Bilddaten). • OPTIONS: Anfragen, welche Anfragetypen vom Server unterstützt werden. • CONNECT: Verbinden mit einer weiteren Instanz; der HTTP-Server spielt dabei den Vermittler, der die Daten weiterleitet (HTTP-ProxyHTTP!Proxy). • PUT: Upload von neuen Ressourcen durch den Client. • DELETE: Löschen einer Ressource auf dem Server. • TRACE: Zurücksenden einer Anfrage zu Debugging-Zwecken, um diese auf Veränderungen hin zu überprüfen.

2.14 Application Layer: HTTP

55

Die derzeit noch gängigste HTTP-Version ist 1.1 und wird von allen wichtigen Browsern implementiert. Die Schreibweise für die HTTP-Version ist „HTTP/Version“, also etwa „HTTP/1.1“.  Alte HTTP-Versionen HTTP/1.1 erfordert gegenüber der Vorgängerversion HTTP/1.0 die Angabe eines „Host:“-Headers, womit virtuelle Hosts (das sind mehrere Hosts auf einem Server mit derselben IP-Adresse) ermöglicht werden, was insbesondere für Cloud Computing relevant ist. Weitere Änderungen zwischen Version 1.0 und 1.1 existieren, sind aber für die dieses Buch nicht von Relevanz. Die Vorgängerversion von HTTP/1.0 war übrigens HTTP/0.9 von 1991.

2.14.1 Aufbau des HTTP-Headers Beim Aufbau des HTTP-Headers wird zwischen Request und Response unterschieden. Der Client sendet dabei immer in einer ersten Zeile folgenden Aufbau an den HTTPServer: [METHODE] [URL] [HTTP-VERSION] Eine minimale HTTP/1.0-Anfrage sieht beispielsweise wie folgt aus: GET /index.html HTTP/1.0 Für HTTP/1.1 müsste die Anfrage wie folgt aussehen: GET /index.html HTTP/1.1 Host: www.example.com HTTP-Requests werden mit zwei Zeichensequenzen, die jeweils Carriage Return und Linefeed enthalten (also ‘\r\n\r\n’), abgeschlossen. Eine HTTP-URL setzt sich, gemäß RFC 2068, aus den folgenden Bestandteilen zusammen: http://Host[:Port]/Pfad, also beispielsweise: http://www.wendzel.de:80/index.html Die Angabe des Ports (also etwa :80) kann bei Verwendung des Ports 80 (dieser ist der Standardport für HTTP) ausbleiben, sodass die Anfrage einer URL wie http://www.wendzel.de/index.html völlig korrekt ist. Der HTTP-Server antwortet auf Anfragen (Requests) mit einer Response der Form: [HTTP-Version] [Statuscode] [Status-Bezeichnung],

56

2 Grundlagen der Netzwerktechnik

also etwa HTTP/1.1 200 OK für die erfolgreiche Ausführung (Code 200, Bezeichnung „OK“) eines HTTP/1.1-Requests. Status-Codes im Bereich von 100–199 sind Statusmeldungen (etwa „102 Processing“), im Bereich von 200–299 Erfolgsmeldungen (etwa „200 OK“), im Bereich von 300–399 Umleitungen (etwa „301 Moved Permanently“), im Bereich von 400–499 clientseitige Fehlermeldungen (etwa „404 Not Found“ für eine vom Client angefragte Ressource, die nicht auf dem Server existiert) und im Bereich von 500– 599 serverseitige Fehlermeldungen (etwa „500 Internal Server Error“). Bei einer Response werden zudem einige weitere Parameter an den Client geliefert. Dazu zählen etwa Informationen über die Webserver-Software (Produkt, gegebenenfalls dessen Version und geladene Module), ein Timestamp, Informationen zur Länge des Payloads (Content), zum Verbindungsverhalten (dazu gleich mehr) und zur Art des Contents (Content-Type) sowie seiner Länge (Content-Length) und Codierung (etwa „text/html, charset=UTF-8“ für UTF-8 kodierten HTML-Text). Wie gerade erwähnt, wird der Client vom Server über das Verbindungsverhalten einer HTTP-Verbindung informiert. Dabei liefert der Server er entweder den Wert „close“ oder „keep-alive“ zurück. Keep-Alive-Verbindungen werden vom Server nicht sofort nach der Response terminiert, um weitere HTTP-Anfragen ohne erneutes Verbinden zu erlauben (etwa für die in einer HTML-Datei verlinkten/eingebetteten Ressourcen, wie Bilder). Close-Verbindungen werden hingegen direkt terminiert. Keep-Alive-Verbindungen sind performanter, weil sie die Auf- und Abbauvorgänge der TCP-Verbindungen überflüssig machen. Einige Beispielanfragen sollen den Aufbau von HTTP-Requests und HTTP-Responses verdeutlichen. Zunächst sollen mit HTTP/1.0-Methoden abgefragt werden, die der Webserver der Hochschule Augsburg unterstützt. Der Server antwortet mit den entsprechenden Methoden (Zeile „Allow“), Informationen zu seiner Software und weiteren Daten. Die Content-Length ist 0, da keine weiteren Inhalte (etwa Bilder oder eine Webseite) übertragen wurden. $ t e l n e t www. r z . fh−a u g s b u r g . de 80 Trying 1 4 1 . 8 2 . 1 6 . 4 0 . . . C o n n e c t e d t o wwwrz . r z . fh−a u g s b u r g . de . Escape c h a r a c t e r i s ’ ^ ] ’ . OPTIONS / HTTP / 1 . 0 HTTP / 1 . 1 200 OK D a t e : Mon , 02 May 2011 1 3 : 3 1 : 4 2 GMT S e r v e r : Apache / 2 . 2 . 9 ( Unix ) m o d _ s s l / 2 . 2 . 9 OpenSSL / 0 . 9 . 7 d DAV/ 2 m o d _ f a s t c g i / 2 . 4 . 6 Allow : GET , HEAD, POST , OPTIONS , TRACE C o n t e n t −L e n g t h : 0 Connection : close C o n t e n t −Type : t e x t / h t m l C o n n e c t i o n c l o s e d by f o r e i g n h o s t .

2.14 Application Layer: HTTP

57

Als nächstes soll dieselbe Anfrage über HTTP/1.1 gestellt werden, wozu der Parameter „Host“ angegeben werden muss. $ t e l n e t www. r z . fh−a u g s b u r g . de 80 Trying 1 4 1 . 8 2 . 1 6 . 4 0 . . . C o n n e c t e d t o wwwrz . r z . fh−a u g s b u r g . de . Escape c h a r a c t e r i s ’ ^ ] ’ . OPTIONS / HTTP / 1 . 1 H o s t : www. r z . fh−a u g s b u r g . de HTTP / 1 . 1 200 OK D a t e : Mon , 02 May 2011 1 3 : 3 1 : 4 9 GMT S e r v e r : Apache / 2 . 2 . 9 ( Unix ) m o d _ s s l / 2 . 2 . 9 OpenSSL / 0 . 9 . 7 d DAV/ 2 m o d _ f a s t c g i / 2 . 4 . 6 Allow : GET , HEAD, POST , OPTIONS , TRACE C o n t e n t −L e n g t h : 0 C o n t e n t −Type : t e x t / h t m l Nun soll mit einer GET-Methode die Startseite von www.wendzel.de abfragt werden. Man erhält als Antwort (hier gekürzt dargestellt) den HTML-Code der Seite mit einer Gesamtlänge von 10217 Bytes. $ t e l n e t www. w e n d z e l . de 80 Trying 8 9 . 1 1 0 . 1 4 6 . 1 9 5 . . . C o n n e c t e d t o www. w e n d z e l . de . Escape c h a r a c t e r i s ’ ^ ] ’ . GET / HTTP / 1 . 1 H o s t : www. w e n d z e l . de HTTP / 1 . 1 200 OK D a t e : Thu , 16 J u n 2011 1 9 : 3 1 : 0 8 GMT S e r v e r : Apache L a s t −M o d i f i e d : F r i , 03 J u n 2011 2 3 : 1 6 : 1 7 GMT ETag : " 697004 a −27e9 −4a 4 d 6 f 0 d 0 9 2 4 0 " Accept −Ranges : b y t e s C o n t e n t −L e n g t h : 10217 C o n t e n t −Type : t e x t / h t m l ; c h a r s e t =UTF−8

< html > ... ... C o n n e c t i o n c l o s e d by f o r e i g n h o s t .

58

2 Grundlagen der Netzwerktechnik

Bei POST-Anfragen werden zusätzlich Werte an den Server übertragen (in separaten Zeilen). Die HTTP-Methoden PUT, DELETE und CONNECT sind in der Regel nicht verfügbar, da sie sicherheitskritisch beziehungsweise nicht für die Erbringung eines typischen Webdienstes notwendig sind.

2.14.2 HTTP/2 Die sich aktuell langsam durchsetzende HTTP-Version 2.0 soll an dieser Stelle ebenfalls kurz Erwähnung finden. Die HTTP/2-Syntax ist abwärtskomatibel zu HTTP/1.1. Im Wesentlichen bietet HTTP/2 effizientere Netzwerkübertragungen, eine verringerte Wahrnehmung der Latenz durch Kompression der Header-Felder, und erlaubt es, mehrere Datenaustausche gleichzeitig über dieselbe Verbindung durchzuführen. Zur Verwendung von HTTP/2 wird ein HTTP/1.1-Request durchgeführt, der ein Upgrade auf Version 2 beinhaltet. Das zentrale Element ist hierbei der Befehl upgrade, der etwa h2c (Klartextverbindung für HTTP/2) verlangen kann. h2 entspreche hingegen einer TLS-verschlüsselten HTTP/2-Verbindung. Darauf folgen Details zur HTTP/2-Verbindung, die mit dem Base64-Verfahren19 kodiert werden (HTTP2-Settings). GET / HTTP / 1 . 1 H o s t : www. e x a m p l e . com C o n n e c t i o n : Upgrade , HTTP2−S e t t i n g s Upgrade : h2c HTTP2−S e t t i n g s : HTTP2−S e t t i n g s ( s p e z i e l l k o d i e r t )

2.15

Application Layer: DNS

Hauptaufgabe des Domain Name Systems (DNS) ist die Übersetzung von Hostnames in IP-Adressen (und vice versa). DNS ist ein hierarchisches System, dessen Ausgangspunkt als ‘.’ (ein Punkt) bezeichnet wird. Die hierarchische Organisation erfolgt in sogenannten Domains, die durch Punkte getrennt werden, etwa www.openbsd.org (Host www unter der Domain openbsd unter der Domain org), siehe Abb. 2.19. Hinter der Domain de kann ebenfalls ein Punkt stehen, der aber optional ist. Entsprechend ist die Domain www.fh-augsburg.de. korrekt angegeben. Außerdem gibt es Umlautdomains (etwa müller.de). Domainnamen müssen mit einem Buchstaben beginnen, können maximal 63 Zeichen beinhalten und dürfen Buchstaben, den Bindestrich (‘-’) und Zahlen beinhalten. Es können bis zu 127 Domainlevel erstellt werden. DNS-Namen dürfen 19 Beim Base64-Verfahren werden Eingabedaten in Byteschritten in druckbaren ASCII-Zeichen kodiert.

2.15 Application Layer: DNS

59

Abb. 2.19 Hierarchie der DNS-Domains

nur einmalig vergeben werden. Die obersten Domains der Hierarchieebene werden dabei als Top Level Domains (TLDs) bezeichnet, wobei verschiedene Arten solcher Top Level Domains existieren [27]: • Länder: .de (Deutschland), .at (Österreich), .us (Vereinigte Staaten), .nz (Neuseeland), .au (Australien) usw. • Organisationsformen: .com (kommerzielle Domains), .org (Organisationen), .gov (Regierungsorganisationen), .mil (militärische Organisationen), .edu (Bildungseinrichtungen) usw. • Seit 2000: .biz (Business), .info (Informationen), .name (Namen von Personen), .pro (freie Berufe), .aero (Luftfahrtindustrie), .museum etc. • Mit Beschluss der ICANN vom Juni 2011: Unternehmenseigene Top-Level-Domains (diese können von der ICANN nach Prüfung abgelehnt werden und sind äußerst kostspielig) [15]. Die Organisation von DNS ist dezentral: Server sind für einen Bereich (eine sogenannte Zone) zuständig und gelten damit als Authoritative Server). DNS-Server können aber auch die Informationen anderer Server zwischenspeichern (DNS-Caching). Obwohl DNS dezentral organisiert ist, gibt es in der Hierarchie eine oberste Instanz: Die sogenannten Rootserver. Es mehrere Rootserver-Adressen, die durch Anycasting durch zahlreiche physikalische Systeme repräsentiert werden können. Dabei teilen sich mehrere

60

2 Grundlagen der Netzwerktechnik

Rootserver die gleiche IP-Adresse und ein DNS-Client landet bei einem regionalen Server, der diese IP verwendet. Dadurch wird die Last auf die Rootserver verteilt und DNS etwas weniger anfällig gegenüber Angriffen. Jeder Client darf diese Rootserver direkt anfragen. Aus Gründen der Stabilität laufen die Rootserver mit unterschiedlichen Betriebssystemen (meistens unixartig, etwa BSD oder Linux) und unterschiedlicher Serversoftware (oftmals mit der Software Bind). Die meisten Root-Nameserver stehen in den USA. Rootserver verteilen die Adressen der DNS-Server für die Top-Level-Domains.

2.15.1 Resource Records DNS kennt sogenannte Resource Records. Diese sind in vier Klassen organisiert, wobei nur die Klasse IN (Internet) für dieses Buch relevant ist. Es können dabei bis zu 65.536 verschiedene Resource Records (RRs) in DNS definiert werden. Die wichtigsten sind: • • • • • • • • • •

•

A: IPv4-Adresse für einen gegebenen Hostname AAAA: IPv6-Adresse für einen gegebenen Hostname CNAME: kanonischer Hostname (Alias) DNSKEY: öffentlicher Schlüssel einer Zone für DNSSec20 MX: Mail Exchange für die Angabe der Mailserver einer Domain samt ihrer Priorität NAPTR: Erweiterung der A-Records um zusätzliche Funktionalität, etwa Angabe des verwendeten Protokolls eines Servers NS: Nameserver einer Domain PTR: Umwandlung einer IP-Adresse in einen Hostname (Gegenstück zu A und AAAA) RRSIG: Dieser Resource Record ermöglicht die Signatur anderer Resource Records und ist ebenfalls Bestandteil von DNSSec. SOA: Start of Authority, enthält Informationen zur zuständigen Zone eines DNSServers (Kontaktinformation zum Administrator, Standard-Lebenszeitspanne der Resource Records, Refresh-Time und weitere Werte). TXT: Freitext

2.15.2 Resolving Jeder Rechner beinhaltet einen lokalen Resolver. Unter unixartigen Systemen wird ein Resolver über die Datei /etc/resolv.conf konfiguriert, in der die IP-Adressen von Nameservern angegeben werden, die ein Client ansprechen soll, um einen Resource 20 Bei DNSSec handelt es sich um eine Erweiterung des DNS, die die Nachrichten-Authentizität

und -Integrität sicherstellen kann. DNSSec kümmert sich also, anders formuliert, darum, dass Nachrichten nicht manipuliert werden und darum, dass Nachrichten tatsächlich vom gewünschten Absender stammen. Mehr zu DNSSec erfahren Sie in Abschn. 8.5.4.

2.15 Application Layer: DNS

61

Record abzufragen. Dabei wird bei den Nameservern eine Unterscheidung hinsichtlich ihres Auflösungsverfahrens (Resolving) getätigt: • Iteratives Resolving: Der Namserver A fragt den ihm bekannten Nameserver B der nächsthöheren Instanz nach den gewünschten DNS-Informationen. Sollte der Nameserver B diese Informationen nicht kennen, leitet A die Anfrage an den hierarchisch nächsthöheren Nameserver C weiter usw., bis er am Ende einen Rootserver anfragt. • Rekursives Resolving: Nameserver A fragt Nameserver B nach den gewünschten DNS-Informationen. Hat Nameserver B diese Informationen nicht, fragt B selbst den nächsthöheren Server an. Das weitere Vorgehen für den Fall, das eine Antwort nicht erhalten wurde, läuft rekursiv. Rekursives Resolving hat den Vorteil, dass jedes Element in der Kette der Nameserver die finale Antwort zwischenspeichern kann, was erneutes Abfragen der gleichen DNS-Information beschleunigt.

2.15.3 Der DNS-Header Der DNS-Header gliedert sich in folgende Bereiche, die in Abb. 2.20 dargestellt sind: die Header Section (das ist der eigentliche Protokollheader), die Questions Section (gestellte Fragen nach Resource Records), Answer Section (Antworten für gestellte Fragen), Authority Section (Hinweise zu alternativen, zuständigen DNS-Servern für eine gestellte Anfrage) und Additional Section (zusätzliche Hinweise in Form weiterer Resource Records). Ein in UDP eingekapselter DNS-Request kann maximal 512 Bytes groß sein. Für TCP können Streams versendet werden, die nicht unter diese Beschränkung fallen. Während alle Sections, bis auf die Header Section, nur Resource Records beinhalten, ist die

Abb. 2.20 Der DNS-Header

62

2 Grundlagen der Netzwerktechnik

Header Section nach einem bestimmten Schema aufgebaut. Sie enthält neben einer ID zur Zuordnung von Anfragen und Antworten folgende Bestandteile (ebenfalls in Abb. 2.20 dargestellt): • QR-Bit. Das QR-Bit gibt an, um welche Art DNS-Nachricht es sich handelt; ein 0er-Bit steht für eine Anfrage (Query) und ein 1er-Bit für eine Antwort (Response). • Opcode. Der Opcode gibt die Art der DNS-Anfrage an. Es handelt sich dabei entweder um eine Standardabfrage (Standard Query), eine inverse Abfrage (Inverse Query), die für die Umkehrung (also Negierung) des eigentlichen Requests verwendet wird, um eine Abfrage des Server-Zustands ( Server Status Request, eine Benachrichtigung (Notification) oder um eine Aktualisierung (Update). • DNS-Flags. Weiterhin enthält der DNS-Header eine Reihe möglicher Flags: – AA: Dieses Flag (Authoritative Answer) ist gesetzt, wenn der angefragte DNSServer für die Resource Records der abgefragten Zone zuständig ist. Ein Server, der eine Anfrage für eine fremde Zone beantwortet (für diese Zone also etwa nur als Caching-Server fungiert), darf dieses Flag nicht setzen. – TC (Truncated): Nur die ersten 512 Bytes der Response sind enthalten und die restlichen Daten sind abgeschnitten. Dieses Bit dient als Hinweis für den DNSClient, dass weitere Daten über eine TCP-basierte Anfrage bereitgestellt werden können. – RD (Recursion Desired): Zuvor haben Sie den Unterschied zwischen iterativem und rekursivem Resolving kennengelernt. Setzt ein Client in einer Anfrage das RD-Bit, so fordert er ein rekursives Resolving an. – RA (Recursion Available): Da rekursives Resolving nicht immer verfügbar sein muss, kann ein Server mit dem RA-Flag signalisieren, dass er rekursives Resolving unterstützt. – Z-Bit: unbenutzt und für zukünftige Verwendung reserviert. – Die beiden Flags AD (Authenticated Data) und CD (Checking Disabled) stehen im Kontext von DNSSec. Mit gesetztem AD-Flag signalisiert ein DNS-Server, dass eine Überprüfung des Resource Records stattfand – die enthaltenen Informationen sind authentisiert. Das CD-Flag wird hingegen vom Client verwendet, um dem Server zu signalisieren, dass nicht überprüfte Antworten akzeptiert werden (der Client muss jedoch noch eigenständig Überprüfungen der Resource Records durchführen, weshalb er mit gesetztem CD-Flag dem Server die Arbeit ersparen kann) [1]. • Rcode. Dieser Wert gibt den Response-Code an. Die IANA definiert eine Liste möglicher Werte für den Rcode [12]. Die wichtigsten Werte sind: – 0 (No Error, es lag kein Fehler vor) – 1 (Format Error, die Nachricht ist nicht interpretierbar) – 2 (Server Failure, ein serverseitiges Problem liegt vor) – 3 (Non-existent Domain, die angefragte Domain existiert nicht)

2.15 Application Layer: DNS

• • • •

63

– 4 (Not Implemented, eine angefragte Funktionalität ist nicht verfügbar21 ) – 5 (Refused, die Anfrage wurde abgelehnt) Total Questions, 16 Bit: Anzahl der enthaltenen Anfragen an den Server Total Answers, 16 Bit: Anzahl der enthaltenen Antworten vom Server an den Client Total Authority Resource Records, 16 Bit: Anzahl der enthaltenen Hinweise auf authorisierte Server in einer Antwort Total Additional Resource Records, 16 Bit: Anzahl der enthaltenen zusätzlichen Resource Records in einer Antwort

2.15.4 DNS-Tools Den Umgang mit DNS erleichtern einige Tools, insbesondere dig und nslookup. Mit beiden können Sie gezielte Abfragen von Resource Records an DNS-Server stellen. Bei nslookup geben Sie den Typ der Abfrage mit set type= an, wobei die oben eingeführten Typen (etwa A, AAAA oder PTR) verwendet werden können. $ nslookup > s e r v e r av2 . r z . fh−a u g s b u r g . de D e f a u l t s e r v e r : av2 . r z . fh−a u g s b u r g . de A d d r e s s : 1 4 1 . 8 2 . 1 6 . 2 4 2 # 53 > s e t t y p e =A > www. r z . fh−a u g s b u r g . de Server : av2 . r z . fh−a u g s b u r g . de Address : 1 4 1 . 8 2 . 1 6 . 2 4 2 # 53 www. r z . fh−a u g s b u r g . de c a n o n i c a l name = wwwrz . r z . fh−a u g s b u r g . de . Name : wwwrz . r z . fh−a u g s b u r g . de Address : 141.82.16.40 > s e t t y p e =AAAA > www. r z . fh−a u g s b u r g . de Server : av2 . r z . fh−a u g s b u r g . de Address : 1 4 1 . 8 2 . 1 6 . 2 4 2 # 53 www. r z . fh−a u g s b u r g . de c a n o n i c a l name = wwwrz . r z . fh−a u g s b u r g . de . wwwrz . r z . fh−a u g s b u r g . de h a s AAAA a d d r e s s 2001:638:102:1:: a :6

21 Es ist beispielsweise möglich, dass kein rekursives Resolving verfügbar ist, der Client aber in einer Anfrage das RD-Flag setzte.

64

2 Grundlagen der Netzwerktechnik

> s e t t y p e =PTR > 2 4 2 . 1 6 . 8 2 . 1 4 1 . in−a d d r . a r p a Server : av2 . r z . fh−a u g s b u r g . de Address : 1 4 1 . 8 2 . 1 6 . 2 4 2 # 53 2 4 2 . 1 6 . 8 2 . 1 4 1 . in−a d d r . a r p a name = av2 . RZ . FH−Augsburg . DE . > s e t t y p e =CNAME > www. r z . fh−a u g s b u r g . de . Server : av2 . r z . fh−a u g s b u r g . de Address : 1 4 1 . 8 2 . 1 6 . 2 4 2 # 53 www. r z . fh−a u g s b u r g . de c a n o n i c a l name = wwwrz . r z . fh−a u g s b u r g . de . > s e t t y p e =MX > r z . fh−a u g s b u r g . de . Server : av2 . r z . fh−a u g s b u r g . de Address : 1 4 1 . 8 2 . 1 6 . 2 4 2 # 53 r z . fh−a u g s b u r g . de mail exchanger = 30 b e e . RZ . HS−Augsburg . de . r z . fh−a u g s b u r g . de mail exchanger = 30 f l y . RZ . HS−Augsburg . de . Oben wurde zunächst der Nameserver av2.rz.fh-augsburg.de festgelegt. Anschließend wurde die IP-Adresse (A) des Hosts www dieser Domain abgefragt und selbiges mit der IPv6-Adresse (AAAA) getan. Im Anschluss wurde der Hostname für die IPAdresse 141.82.16.242 (hierbei ist die umgekehrte Schreibweise zu beachten) und für den kanonischen Namen für den Hostname www.rz.fh-augsburg.de (dieser ist wwwrz.rz.fh-augsburg.de) sowie den Mailexchanger (MX), der zwei Mailserver für die Domain liefert, abgefragt. dig fragt ebenfalls derlei Informationen an. Dabei erfolgt der Aufruf in der Form dig @server name type, wobei server für den Nameserver, name für den angefragten Wert (etwa einen Hostname) und type für die Art des Resource Records stehen. Die folgende Beispielausgabe wurde gekürzt, um die Lesbarkeit zu steigern. $ d i g hs−worms . de [...] ; ; QUESTION SECTION : ; hs−worms . de . IN A ; ; ANSWER SECTION : HS−Worms . DE . 3600 IN A 1 4 3 . 9 3 . 1 6 0 . 2 9

2.16 Application Layer: E-Mail- und Usenetprotokolle

; ; AUTHORITY HS−Worms . DE . HS−Worms . DE . HS−Worms . DE .

65

SECTION : 3600 IN NS ns−s e c . HS−Worms . de . 3600 IN NS n s . HS−Worms . DE . 3600 IN NS m i n n e h a h a . r h r k . u n i −k l . de .

; ; ADDITIONAL SECTION : n s . HS−Worms . DE . 3600 IN A 1 4 3 . 9 3 . 1 6 0 . 9 ns−s e c . HS−Worms . DE . 3600 IN A 1 9 3 . 3 0 . 1 8 . 2 m i n n e h a h a . r h r k . u n i −k l . de . 13225 IN A 1 3 1 . 2 4 6 . 9 . 1 1 6 n s . HS−Worms . DE . 3600 IN AAAA 2 0 0 1 : 4 c80 : 8 1 : a000 : : 9 ns−s e c . HS−Worms . DE . 3600 IN AAAA 2 0 0 1 : 4 c80 : 8 1 : 1 2 0 0 : : 2 m i n n e h a h a . r h r k . u n i −k l . de . 22965 IN AAAA 2001:638:208:9::116 ;; ;; ;; ;;

Query t i m e : 3 msec SERVER : 1 4 3 . 9 3 . 1 6 0 . 9 # 5 3 ( 1 4 3 . 9 3 . 1 6 0 . 9 ) WHEN: Tue Dec 05 1 3 : 2 2 : 1 8 CET 2017 MSG SIZE r c v d : 289

Wie ersichtlich ist, wurde der A-Record der Domain hs-worms.de abgefragt. In der Antwort wurde die entsprechende IP-Adresse zurückgegeben. Weiterhin enthielt die Antwort Verweise auf drei Nameserver (NS) sowie auf zusätzliche IPv4- (A) und IPv6-Adressen (AAAA) dieser Server. IN bedeutet Internet-Klasse (heute der Standard) und der Wert 3600 beziehungsweise 22965 entspricht der Vorhaltezeit (TTL) für den entsprechenden Eintrag.

2.16

Application Layer: E-Mail- und Usenetprotokolle

Das Mailsystem hat die Aufgabe, E-Mails zum Empfänger zu übertragen, eine Abholmöglichkeit für den E-Mail-Empfänger zu bieten (Postfach) und E-Mails zu speichern. Es kommen dabei verschiedene Protokolle zum Einsatz, insbesondere das Simple Mail Transfer Protocol (SMTP), das Post Office Protocol (POP) und das Internet Message Access Protocol (IMAP). In allen drei Fällen handelt es sich um Protokolle, die – ähnlich wie bei HTTP – Klartextnachrichten verwenden. Die Befehle für diese Protokolle sind nicht case-sensitive (Groß- und Kleinschreibung spielt also keine Rolle), außerdem nutzen alle drei Protokolle TCP. Das E-Mail-System besteht dabei aus drei zentralen Komponenten: 1. Mail User Agent (MUA), das ist der E-Mail-Client eines Benutzers, etwa Microsoft Outlook oder Mozilla Thunderbird).

66

2 Grundlagen der Netzwerktechnik

2. Mail Transfer Agent (MTA), das ist der Mailserver, der E-Mails für die Weiterleitung entgegennimmt (etwa Sendmail). 3. Mail Delivery Agent (MDA), das ist die Software, die E-Mails ausliefert und diese etwa filtert und sortiert (ein Beispiel hierfür ist Procmail). Der MUA steht dabei üblicherweise am Anfang und am Ende eines Mailtransfers zur Zieldomain. Beispielsweise könnte ein Benutzer von example.com eine E-Mail an einen Benutzer von hs-worms.de versenden. In diesem Fall würde sich der MUA mit dem MTA von example.com verbinden; hierbei kommt das SMTP-Protokoll zum Einsatz. Der MTA von example.com verbindet sich mit dem MTA von hs-worms.de, der die E-Mail annimmt. Der MDA wird die entsprechende E-Mail anschließend in das Postfach des jeweiligen Empfängers von hs-worms.de einsortieren. Sobald der dortige Benutzer mit seinem MTA eine Verbindung (mit POP oder IMAP) zum lokalen Server herstellt, kann er die in seinem Postfach eingetroffenen E-Mails sichten.

2.16.1 POP3 Das Post Office Protocol (POP) liegt derzeit in der Version 3 (POP3) vor. Es verwendet standardmäßig den Port 110 und dient dem Abholen von E-Mails von einem Mailpostfach. Die Befehle sind simpel. Eine Anmeldung erfolgt mittels USER und PASS (siehe nachstehendes Listing). Die Liste aktuell vorhandener Nachrichten wird mit LIST abgefragt und Nachrichten werden mit RETR und DELE ) abgefragt beziehungsweise vom Server gelöscht. QUIT beendet eine POP3-Verbindung. Das folgende Beispiel illustriert das Anmelden an einem Mailserver und ein Szenario, in dem keine neuen E-Mails vorliegen. $ t e l n e t m a i l s e r v e r . e x a m p l e . com 110 Trying 1 0 . 0 . 0 . 1 . . . C o n n e c t e d t o m a i l s e r v e r . e x a m p l e . com . Escape c h a r a c t e r i s ’ ^ ] ’ . +OK POP s e r v e r r e a d y H e x a m p l e USER max . muster@example . com +OK p a s s w o r d r e q u i r e d f o r u s e r " max . muster@example . com " PASS MeinPassword +OK m a i l b o x " max . muster@example . com " h a s 0 m e s s a g e s (0 o c t e t s ) H example LIST / / Befehl i s t b e r e i t s u e b e r f l u e s s i g ! +OK . QUIT +OK POP s e r v e r s i g n i n g o f f C o n n e c t i o n c l o s e d by f o r e i g n h o s t .

2.16 Application Layer: E-Mail- und Usenetprotokolle

67

2.16.2 IMAP Das Internet Message Access Protocol (IMAP) arbeitet ähnlich wie POP3, verfügt allerdings über einige bedeutsame Funktionen, die POP3 nicht aufweist. Die aktuelle Version von IMAP ist 4 (Revision 1) und in RFC 3501 beschrieben [3]. Außerdem wurden einige Erweiterungen des Standards publiziert. Unter anderem unterstützt IMAP das serverseitige Durchsuchen einer Mailbox. Außerdem kann das Protokoll erweitert werden. Weiterhin unterstützt IMAP eine hierarchische Mailbox-Struktur (in Form von Ordnern). Im einfachsten Fall gibt es normalerweise einen Ordner für gesendete (Sent), für empfangene (Inbox), für gelöschte (Trash) und für in Arbeit befindliche E-Mails (Drafts). Weiterhin können E-Mails als „bereits gelesen“ und „bereits beantwortet“ markiert werden. IMAP wird über TCP übertragen und nutzt Port 143. Die folgende Beispielsitzung illustriert den Umgang mit IMAP. In IMAP stellt der Client jedem Befehl ein Tag voran (im folgenden Listing a001 bis a006), wobei es sich um einen Identifizierungscode für den jeweiligen Befehl handelt. Die Antwort des Servers bezieht sich jeweils auf dieses Tag. Nach dem Verbindungsaufbau des Clients teilt der Server dem Client mit, dass er IMAPv4 in der Revision 1 nutzt und verschiedene Module für die Authentifizierung und Verschlüsselung unterstützt. Der erste Befehl des Clients (a001 login ) meldet den Benutzer am Server an. Der Server akzeptiert die Anmeldung (gekürzte Darstellung). $ t e l n e t l o c a l h o s t 143 Trying 1 2 7 . 0 . 0 . 1 . . . Connected to l o c a l h o s t . localdomain . Escape c h a r a c t e r i s ’ ^ ] ’ . ∗ OK [ CAPABILITY IMAP4rev1 LITERAL+ SASL−IR LOGIN− REFERRALS ID ENABLE IDLE STARTTLS AUTH=PLAIN AUTH=LOGIN ] D o v e c o t ( Ubuntu ) r e a d y . a001 l o g i n swendzel@domain . e x a m p l e P a s s w o r t 1 2 3 a001 OK [ . . . ] Logged i n Als nächstes wählt der Client eine Mailbox (einen Ordner) aus, und zwar den Nachrichteneingang (Inbox). Der Server teilt dem Client unter anderem mit, dass 111 Nachrichten in der Mailbox vorliegen und die Nachricht 105 die erste der noch nicht angesehenen Nachrichten ist. a002 s e l e c t i n b o x ∗ FLAGS ( \ Answered \ F l a g g e d \ D e l e t e d \ Seen \ D r a f t $ F o r w a r d e d NonJunk $ l a b e l 1 J u n k r e c e i p t −h a n d l e d $MDNSent $ L a b e l i m p o r t a n t $ l a b e l 3 $ l a b e l 4 $ l a b e l 5 $ L a b e l l a t e r $Labeltodo $Labelpersonal $label2 $has_cal ) ∗ OK [PERMANENTFLAGS ( \ Answered \ F l a g g e d \ D e l e t e d

68

2 Grundlagen der Netzwerktechnik

\ Seen \ D r a f t $ F o r w a r d e d NonJunk $ l a b e l 1 J u n k r e c e i p t −h a n d l e d $MDNSent $ L a b e l i m p o r t a n t $ l a b e l 3 $label4 $label5 $ L a b e l l a t e r $Labeltodo $Labelpersonal $label2 $has_cal \ ∗ ) ] Flags permitted . ∗ 111 EXISTS ∗ 1 RECENT ∗ OK [UNSEEN 1 0 5 ] F i r s t u n s e e n . ∗ OK [ UIDVALIDITY 1 2 9 2 4 9 4 6 7 0 ] UIDs v a l i d ∗ OK [ UIDNEXT 1 6 5 5 9 ] P r e d i c t e d n e x t UID ∗ OK [HIGHESTMODSEQ 4 8 0 2 3 ] H i g h e s t a002 OK [READ−WRITE ] S e l e c t c o m p l e t e d ( 0 . 0 0 1 s e c s ) . Befehl a003 holt die Kopfzeilen (Header) der Nachricht mit der Nummer 111 ab. Dort ist zu sehen, dass die Nachricht von „Max Sender“ ([email protected]) an [email protected] gesendet wurde (Darstellung gekürzt). Außerdem sehen wir, dass der Nachrichtenbetreff „Hallo, Welt!“ ist und, dass das E-MailProgramm Mozilla Thunderbird verwendet wurde. Es handelt sich um eine Text-Nachricht (text/plain), also keine HTML-E-Mail. Die Nachricht verwendet eine englischsprachige Kodierung und wurde am 5. März 2018 um 16:39 versendet. a003 f e t c h 111 body [ h e a d e r ] ∗ 111 FETCH ( FLAGS ( \ Seen \ R e c e n t ) BODY[HEADER] {1870} R e t u r n −P a t h : < sender@example . xyz > D e l i v e r e d −To : r e c e i v e r @ e x a m p l e 2 . xyz R e c e i v e d : by m a i l . e x a m p l e 2 . xyz ( P o s t f i x , from u s e r i d 1 0 0 1 ) i d 970328058D ; Mon , 5 Mar 2018 1 6 : 4 0 : 3 0 +0100 ( CET ) To : r e c e i v e r @ e x a m p l e 2 . xyz From : "Max S e n d e r " < sender@example . xyz > S u b j e c t : H a l l o , Welt ! D a t e : Mon , 5 Mar 2018 1 6 : 3 9 : 4 6 +0100 User−Agent : M o z i l l a / 5 . 0 ( X11 ; L i n u x x86_64 ; r v : 5 2 . 0 ) Gecko / 2 0 1 0 0 1 0 1 T h u n d e r b i r d / 5 2 . 6 . 0 MIME−V e r s i o n : 1 . 0 C o n t e n t −Type : t e x t / p l a i n ; c h a r s e t = u t f −8 C o n t e n t −Language : en−US C o n t e n t −T r a n s f e r −E n c o d i n g : 7 b i t ) a003 OK F e t c h c o m p l e t e d . Um nun den eigentlichen Nachrichteninhalt zu lesen, wird erneut fetch bemüht, allerdings wird diesmal nicht der Header (body[header]), sondern der Nachrichtentext

2.16 Application Layer: E-Mail- und Usenetprotokolle

69

(body[text]) abgefragt. Der Inhalt der Nachricht ist „Hallo! Nachrichtentext.\r\n“.22 Schließlich meldet sich der Client mit logout vom Server ab. a004 f e t c h 111 body [ t e x t ] ∗ 111 FETCH (BODY[ TEXT ] {25} Hallo ! Nachrichtentext . ) a004 OK F e t c h c o m p l e t e d . a005 l o g o u t ∗ BYE L o g g i n g o u t a005 OK L o g o u t c o m p l e t e d . C o n n e c t i o n c l o s e d by f o r e i g n h o s t . Es gibt zahlreiche weitere Befehle für IMAP, doch soll dieser Einblick erst einmal genügen.

2.16.3 SMTP SMTP dient zum Versenden von E-Mails und nimmt standardmäßig Verbindungen auf Port 25 entgegen. Mit HELO beziehungsweise EHLO erfolgt die Bekanntgabe der eigenen Domain am SMTP-Server. SMTP unterstützt zudem Authentifizierungen. Mails werden in zwei Schritten versendet. Zunächst werden zentrale Headerbestandteile einer E-Mail (Absender und Empfänger) gesendet: mit MAIL FROM: und RCPT TO: . Anschließend leitet der Befehl DATA den restlichen Teil der E-Mail ein. Dabei können zeilenweise zunächst optionale Headerbestandteile (etwa der E-Mail-Betreff mit Subject: ) übertragen werden. Anschließend sendet der Client eine Leerzeile gefolgt von der eigentlichen Nachricht. Die Nachricht wird mit einem einzelnen Satzpunkt abgeschlossen, der in einer separaten Zeile stehen muss. QUIT terminiert die Verbindung schließlich. Das folgende Beispiel zeigt, wie eine E-Mail von [email protected] an [email protected] verschickt werden kann. Die Nachricht hat den Betreff „Hallo, SMTP-Server“ und wurde vom Mailprogramm „Mailprogramm/1.0“ (die Versionsangabe erfolgt analog zu der von HTTP) versendet. $ t e l n e t 1 2 7 . 0 . 0 . 1 25 Trying 1 2 7 . 0 . 0 . 1 . . . Connected to 1 2 7 . 0 . 0 . 1 . Escape c h a r a c t e r i s ’ ^ ] ’ . 22 Die beiden Escapesequenzen \r und \n bedeuten schlicht, dass am Ende der Nachricht eine Leerzeile stand.

70

2 Grundlagen der Netzwerktechnik

220 l o c a l h o s t ESMTP Exim 4 . 6 9 Tue , 02 May 2017 1 3 : 5 1 : 5 2 +0000 HELO e x a m p l e . com 250 e x a m p l e . com H e l l o e x a m p l e . com [ 1 2 7 . 0 . 0 . 1 ] MAIL FROM: max . muster@example . com 250 OK RCPT TO : e r i k a . muster@example . com 250 A c c e p t e d DATA 354 E n t e r message , e n d i n g w i t h " . " on a l i n e by i t s e l f User−Agent : Mailprogramm / 1 . 0 S u b j e c t : H a l l o , SMTP−S e r v e r . H a l l o , d i e s e M a i l w i r d m i t einem P u n k t b e e n d e t . So l a n g e d e r P u n k t n i c h t a u f t a u c h t , i s t d e r M a i l i n h a l t f u e r d a s SMTP−P r o t o k o l l noch n i c h t a b g e s c h l o s s e n . . . . 250 OK i d =1QGtYF−0000Ts−Uu QUIT 221 l o c a l h o s t c l o s i n g c o n n e c t i o n C o n n e c t i o n c l o s e d by f o r e i g n h o s t .

2.16.4 NNTP (Usenet) Das Network News Transfer Protocol (NNTP [5]) wird im sogenannten Usenet verwendet – einem Vorläufer heutiger Web-Foren. Es handelt sich um ein altes Netzwerkprotokoll, das in diesem Buch verwendet wird, um erstens ein Verständnis für historische Protokolle der Anwendungsschicht zu unterstützten, und zweitens, um zu zeigen, dass auch historische Protokolle sicherheitsrelevant sind. Mehr zur Historie von NNTP findet sich unter anderem in einem lesenswerten Aufsatz von Raymond [22]. Selbstverständlich sind auch IPv4, TCP und Co. alte Protokolle. Im Gegensatz zu NNTP werden sie allerdings noch intensiv verwendet. Einige Universitäten betreiben zwar nach wie vor Usenet-Server, doch hat NNTP keine vergleichbare Bedeutung mehr, wie die zuvor genannten Protokolle. Es lohnt sich dennoch, einen Blick in die spannende Historie von Netzwerkprotokollen zu werfen. Darunter auch Protokolle wie UUCP oder GOPHER. Sie können diese Protokolle noch immer verwenden und jedes dieser Protokolle lässt Sie implizit etwas Zusätzliches über heutige Protokolle und das Internet erlernen.23 23 Dies gilt im Übrigen auch für historische Betriebssysteme, deren Konzepte viel über die heutigen Betriebssysteme berichten können und zum Teil unverändert angewandt werden.

2.16 Application Layer: E-Mail- und Usenetprotokolle

71

Diskussionsforen heißen im Usenet Newsgroups und sind hierarchisch organisiert. So würde sich etwa die Newsgroup de.comp.os.linux.misc auf Deutsch (de) mit dem Thema Computer/Informatik (comp), genauer mit Betriebssystemen (os), und zwar dem Betriebssystem Linux (linux) und nicht näher definierten und sonst nirgends abgedeckten Themen (misc, Kurzform für miscellaneous) befassen. Dieses in die Jahre gekommene Protokoll ist auch deshalb für uns interessant, da es, falls es irgendwo zum Einsatz kommt, aus Sicht eines Angreifers interessant ist, um viele Informationen über eine Organisation zu erlangen. NNTP dient der Übertragung von Nachrichten zwischen einem Usenet-Client und einem Usenet-Server sowie zur Kommunikation zwischen Usenet-Servern (zum Abgleich von Nachrichten). NNTP ist ebenfalls ein Klartextprotokoll und funktioniert ganz ähnlich wie SMTP und POP3, hat allerdings etwas komplexere Befehle. NNTP wird über TCP betrieben und verwendet standardmäßig Port 119. Mit dem Befehl HELP liefert ein NNTP-Server eine Liste der vom Server unterstützten Befehle samt Parameter. Eine Übersicht über vorhandene Newsgroups liefert der Befehl LIST. Der Befehl liefert zudem die geringste und höchste Nachrichtennummer in einer Newsgroup sowie Daten darüber, ob das Senden von Nachrichten (das Posten) in der jeweiligen Newsgroup erlaubt ist (y) beziehungsweise nicht erlaubt ist (n). Die Liste der Nachrichten wird mit einem Punkt in einer separaten Zeile abgeschlossen. $ t e l n e t l o c a l h o s t 119 Trying : : 1 . . . Trying 1 2 7 . 0 . 0 . 1 . . . Connected to l o c a l h o s t . Escape c h a r a c t e r i s ’ ^ ] ’ . 200 WendzelNNTPd r e a d y ( p o s t i n g ok ) . LIST 215 l i s t o f n e w s g r o u p s f o l l o w s alt . test 4 1 y alt . test2 0 0 y . Um eine Nachricht an eine Newsgroup zu schicken, wird der Befehl POST verwendet. Analog zu SMTP wird hier zunächst ein Header definiert und nach einer Leerzeile der Nachrichteninhalt übertragen. Statt einem E-Mail-Empfänger wird allerdings eine Liste der Zielnewsgroups (in der Regel ist dies nur eine einzige Newsgroup) angegeben (Newsgroups: ), Newsgroups werden dabei durch Kommas voneinander getrennt). POST 340 s e n d a r t i c l e t o be p o s t e d . End w i t h . From : S t e f f e n Wendzel < t e s t . user@hs−worms . de > S u b j e c t : T e s t −N a c h r i c h t Newsgroups : a l t . t e s t

72

2 Grundlagen der Netzwerktechnik

T e s t −N a c h r i c h t ( Msg−Body ) . . 240 a r t i c l e p o s t e d Nachdem eine Nachricht gepostet wurde, erhöht sich entsprechend die Anzahl der Nachrichten in einer Newsgroup (in diesem Fall stieg die höchste Nachrichtennummer in alt.test von 4 auf 5). LIST 215 l i s t o f n e w s g r o u p s f o l l o w s alt . test 5 1 y alt . test2 0 0 y . Mit dem Befehl GROUP kann eine Newsgroup selektiert werden. Innerhalb dieser dieser Newsgroup können dann beliebig Nachrichten abgerufen werden. XOVER liefert eine Übersicht über gepostete Nachrichten (als Parameter wird eine Nachrichtennummer/ID oder ein Bereich von Nachrichtennummern angegeben). HEAD liefert den Header einer Nachricht, BODY die eigentliche Nachricht. STAT fragt den Status einer Nachricht ab und ARTICLE lädt eine gesamte Nachricht herunter, das heißt Header und Body. Alle vier Befehle erwarten eine Nachrichtennummer als Parameter. Einzelne Headerbereiche (etwa der Nachrichtenbetreff (subject)) können mit XHDR abgefragt werden, das analog zu XOVER verwendet wird. Wie üblich werden Verbindungen mit QUIT terminiert. GROUP a l t . t e s t 211 5 1 5 a l t . t e s t g r o u p s e l e c t e d XOVER 5 224 o v e r v i e w i n f o r m a t i o n f o l l o w s 5 T e s t −N a c h r i c h t S t e f f e n Wendzel < t e s t . user@ hs−worms . de > Mon , 02 May 11 1 5 : 5 9 : 3 8 +0200

273 1 . HEAD 5 221 5 < c d p 5 @ l o c a l h o s t > a r t i c l e r e t r i e v e d − h e a d f o l l o w s P a t h : s t e f f e n m o b i l e . unknown Message−ID : < c d p 5 @ l o c a l h o s t > D a t e : Mon , 02 May 11 1 5 : 5 9 : 3 8 +0200 Lines : 1 From : S t e f f e n Wendzel < t e s t . user@hs−worms . de > S u b j e c t : T e s t −N a c h r i c h t Newsgroups : a l t . t e s t .

2.17 Application Layer: sonstige Protokolle

73

BODY 5 222 5 < c d p 5 @ l o c a l h o s t > a r t i c l e r e t r i e v e d − body f o l l o w s T e s t −N a c h r i c h t ( Msg−Body ) . . STAT 5 223 5 < c d p 5 @ l o c a l h o s t > a r t i c l e r e t r i e v e d − r e q u e s t text separately XHDR s u b j e c t 4−5 221 H e a d e r f o l l o w s 4 t e s t −msg m i t Umlauten 5 T e s t −N a c h r i c h t DaKo . QUIT 205 c l o s i n g c o n n e c t i o n − goodbye ! C o n n e c t i o n c l o s e d by f o r e i g n h o s t .

2.17

Application Layer: sonstige Protokolle

Es gibt noch eine Vielzahl weiterer, teils recht bedeutsamer, Protokolle auf dem Application Layer, die an dieser Stelle allerdings nicht im Detail betrachtet werden können. So dient Telnet beispielsweise dazu, sich mit anderen Computern zu verbinden und dort Befehle auszuführen, teils zur Administration, teils um Netzwerkdienste zu testen. Das File Transfer Protocol (FTP) dient der Bereitstellung und Abfrage von Dateien über einen Server; einem Vorgänger von Cloudspeicher, der noch immer verlässlich funktioniert. Secure Shell (SSH) samt Secure Copy (scp-Programm) dient der sicheren Fernadministration von anderen Rechnern und der sicheren Übertragung und Bereitstellung von Dateien. SSH und Secure Copy sind wesentlich sicherer als Telnet und FTP; sie ersetzen diese beiden älteren Protokolle. Das Network Time Protocol (NTP) dient der netzwerkweiten Konfiguration von Uhrzeiten auf Rechnern. Weitere Protokolle sind etwa die Chatprotokolle Internet Relay Chat (IRC) und Extensible Messaging and Presence Protocol XMPP oder das Simple Network Management Protocol (SNMP), das zur Überwachung von Netzwerkkomponenten dient. Weitere bedeutsame Protokolle sind solche, die für die Übertragung von Multimediainhalten zuständig sind. Das Session Initiation Protocol (SIP) dient der Steuerung von Multimediaübertragungen. SIP verwendet in der Regel zusätzlich das Session Description Protocol (SDP), das – eingekapselt in SIP – die eigentlichen Multimediaparameter, etwa zu verwendende Audiocodecs, zwischen den Teilnehmern aushandelt. Die eigentliche Übertragung von Audio- und Videostreams kann wiederum mit dem (Secure) Real-time Transport Protocol ((S)RTP) erfolgen.

74

2 Grundlagen der Netzwerktechnik

Verschiedene bedeutsame Netzwerkprotokolle für das Internet der Dinge werden in Kap. 10 besprochen.

2.18

Zusammenfassung

Protokolle des TCP/IP-Modells sind in einer Schichtenarchitektur organisiert. Die Aufgaben der Schichten unterscheiden sich stark. Die unterste Schicht ist für die physikalische Datenübertragung und die darüber liegende Schicht für das Routing verantwortlich. Die dritte Schicht stellt Multiplexing bereit und die oberste Schicht beinhaltet anwendungsspezifische Funktionen. Es gibt, grob betrachtet, zwei Arten von Netzwerkprotokollen: solche mit binärem Header (etwa IPv4, IPv6, DNS) und mit Klartext-Header (etwa HTTP oder POP3). Die wichtigsten Protokolle der TCP/IP-Suite sind das ARP-Protokoll zur Übersetzung zwischen IP-Adressen und Hardware-Adressen, das Internet Protocol (IP) samt einem Steuerprotokoll (ICMP) sowie die neueren Versionen IPv6 und ICMPv6, die sich auf dem Internet Layer befinden, sowie UDP und TCP auf der Transportschicht, und verschiedene Protokolle der Anwendungsschicht (insbesondere HTTP, DNS, SMTP und IMAP). Viele weitere Protokolle existieren, sind aber im Rahmen dieses Buches nicht von nennenswerter Bedeutung oder werden erst in Kap. 10 eingeführt.

2.19

Weiterführende Literatur

Dieses einführende Kapitel kann ein so komplexes Thema wie Computernetze nur grob betrachten. Entsprechend hat es insbesondere solche Themen dargestellt, die für das Verständnis des restlichen Buches von besonderer Relevanz sind. Eine hervorragende und zugleich ausführliche Einführung in die Computernetze bietet etwa der Klassiker von Tanenbaum [27]. Empfehlenswert ist zudem das Buch Computer Networking: A Top-Down Approach von Kurose und Keith [13]. Zum Verständnis von Netzwerkprotokollen der TCP/IP-Suite empfiehlt sich aber insbesondere das Lesen der jeweiligen RFCs.

2.20

Übungsaufgaben

1. Erläutern Sie die vier Schichten des TCP/IP-Modells. 2. Wie funktioniert die Fragmentierung bei IPv4. Gehen Sie dabei auf die relevanten Headerbestandteile ein. Weshalb wird Fragmentierung benötigt und welche Rolle spielt dabei die MTU? 3. Ein IPv4-Paket mit folgenden Headerwerten trifft auf einem Router ein: IHL=5, Identifier=0x7f7f, DF=0, MF=1, Offset=256

2.20 Übungsaufgaben

4.

5. 6.

7. 8. 9. 10. 11. 12. 13. 14. 15.

16. 17. 18. 19. 20. 21. 22. 23. 24.

25.

75

Werden weitere Fragmente für das Paket folgen? (Falls ja: Wird der Router diese unter allen Umständen erhalten, wenn es keine Übertragungsfehler gibt?) Der Router muss das Paket aus der vorherigen Aufgabe erneut fragmentieren. Erläutern Sie, was dabei passieren würde (welche Auswirkung hat dies auf die Felder Identifier, MF und Offset bei einer von Ihnen frei wählbaren MTU?). Internetrecherche: ICMP kennt den ICMP-Type 8 (Echo Request). Wie sieht der Payload dieses Requests unter Windows beziehungsweise Linux aus? Ermitteln Sie die IP-Adresse Ihres Rechners und senden Sie einem anderen Rechner ICMP Echo Requests. Verwenden Sie zum Senden der Echo Requests den pingBefehl. Aufruf: ping , etwa: ping 127.0.0.1. Wozu dient der ICMP-Type Parameter Problem (Type 12)? Wozu dient der ARP-Cache? Welche Headerfelder wurden in IPv6 eliminiert, die IPv4 noch besaß? Wie sieht die IPv6-Adresse fe80::d497:fff1:85e2:7242 unkomprimiert aus? Weshalb kann IPv6 im Standardheader auf ein DF-Flag verzichten, wie es in IPv4 integriert ist? Welcher OSI-Schicht gehört IPv6 an? Was bedeutet ::1/128? Was ist die Standardroute (der Default Gateway) Ihres Rechners? (Verwenden Sie netstat oder route zur Lösung dieser Aufgabe.) Mit dem Befehl traceroute (Linux) beziehungsweise tracert (manche Versionen von Windows) können Sie Routen nachverfolgen. Wie viele Hops liegen zwischen Ihrem Rechner und dem Webserver der Hochschule Worms? Wie viele Hops sind es bis zu www.google.de und wie viele Hops sind es bis zu www.waikato.ac.nz? Wie funktioniert traceroute/tracert? Worin bestehen die primären Unterschiede zwischen den Protokollen UDP und TCP? Erklären Sie das Konzept der Reliability von TCP. Welche Aufgabe hat der Urgent Pointer von TCP? Wie groß ist ein IP-Paket, das aus einem Standard-IP-Header, einem Standard-TCPHeader und einem Payload von 120 Bytes besteht? Wie groß wäre ein solches Paket bei Verwendung des Protokolls UDP anstelle von TCP? Gibt es genauso viele UDP- wie TCP-Ports? (Ziel- und Quellports) Ermitteln Sie die Anzahl offener TCP-Verbindungen und alle offenen TCP-Ports Ihres Rechners mit dem Tool netstat. Welche Mailserver hat die Domain heise.de und welche Prioritäten weisen diese auf? Hinweis: Nutzen Sie hierfür das Programm nslookup unter Windows oder Linux. Zu welcher Organisation gehört die IP-Adresse 83.243.49.161? Hinweis: Diese IP gehört einer europäischen Organisation und für europäische Adressen ist die bereits erwähnte Organisation RIPE.net zuständig.

76

2 Grundlagen der Netzwerktechnik

26. Verwenden Sie das Programm telnet, um eine HTTP-GET-Anfrage an den Host www.prolinux.de zu senden (Port 80). Telnet wird wie folgt aufgerufen: telnet . Welche Antwort bekommen Sie von diesem Host geliefert?

Literatur 1. Arends, R., Austein, R., Larson, M., et al.: Protocol Modifications for the DNS Security Extensions – RFC 4035, März (2005) 2. Conta, A., Deering, S.: Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification – RFC 1885. Network Working Group (1995) 3. Crispin, M.: Internet Message Access Protocol – Version 4rev1 – RFC 3501. Network Working Group (2003) 4. Deering, S., Hinden, R.: Internet Protocol, Version 6 (IPv6) Specification – RFC 1883. Network Working Group (1995) 5. Feather, C.: Network News Transfer Protocol (NNTP) – RFC 3977. Network Working Group (2006) 6. Giffin, J., Greenstadt, R., Litwack, P., Tibbetts, R.: Covert messaging through TCP timestamps. In: Proceedings of 2nd International Conference on Privacy Enhancing Technologies, S. 194– 208 (2003) 7. Grossman, D.: New Terminology and Clarifications for Diffserv – RFC 3260, Apr. 2002 8. Hagen, S.: IPv6. Grundlagen, Funktionalität, Integration, 2. Aufl. Sunny Edition (2009) 9. Herold, H., Lurz, B., Wohlrab, J.: Grundlagen der Informatik. Pearson Studium, München/ Boston (2007) 10. Internet Assigned Numbers Authority: Internet Control Message Protocol (ICMP) Parameters, Version vom 26. (2018). https://www.iana.org/assignments/icmp-parameters/icmp-parameters. xhtml. Zugegriffen am 01.06.2018 11. Internet Assigned Numbers Authority: IPv4 Multicast Address Space Registry, Version vom 20 (2018). https://www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml. Zugegriffen am 01.06.2018 12. Internet Assigned Numbers Authority: Domain Name System (DNS) Parameters, Version vom 8. (2018). http://www.iana.org/assignments/dns-parameters. Zugegriffen am 01.06.2018 13. Kurose, J., Keith, R.: Computer Networking: A Top-Down Approach (Global Edition), 7. Aufl. Prentice Hall, Harlow (2016) 14. Laurent, A.: Understanding Open Source and Free Software Licensing, Kapitel 2. O’Reilly, Beijing/Sebastopol (2004) 15. Linux Magazin. Meldung zur ICANN-Abstimmung für neue TLDs (2011). http://www. linux-magazin.de/NEWS/ICANN-stimmt-fuer-neue-Generic-Top-Level-Domains. Zugegriffen am 01.06.2018 16. Piscitello, D.M., Chapin, A.L.: Open Systems Networking. Addison-Wesley, Wokingham/Reading (1993) 17. Plummer, D.C.: An Ethernet Address Resolution Protocol – or – Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware – RFC 826. Network Working Group (1982) 18. Postel, J. (Hrsg.): DoD Standard – Transmission Control Protocol – RFC 761. University of Southern California (1980) 19. Postel, J.: User Datagram Protocol – RFC 768 (1980)

Literatur

77

20. Postel, J. (Hrsg.): DoD Standard Internet Protocol – RFC 760. University of Southern California (1980) 21. Postel, J.: Internet Control Message Protocol – RFC 777. Network Working Group (1981) 22. Raymond, E.S.: Things Every Hacker Once Knew (2017). http://www.catb.org/~esr/faqs/thingsevery-hacker-once-knew/. Zugegriffen am 01.06.2018 23. RFC Editor: Webseite (2018). https://www.rfc-editor.org/. Zugegriffen am 01.06.2018 24. Ridley, M.: The Evolution of Everything. Fourth Estate, London (2015) 25. Salamon, D., Motta, G.: Handbook of Data Compression. Springer, London (2010) 26. Schneider, J.M.: Protocol Engineering. A Rule-Based Approach, Vieweg Advanced Studies in Computer Science. Vieweg Verlag Wiesbaden, Wiesbaden (1992) 27. Tanenbaum, A.S.: Computernetzwerke, 4. überarb. Aufl. Pearson Studium, München (2003) 28. Weitzel, T., Westarp, F.V.: From QWERTY to nuclear power reactors: historic battles for the standard. In: Geihs, K., et al. (Hrsg.) Networks. Standardization, Infrastructure, and Applications, pp. 33–61. Physica-Verlag, Heidelberg (2002) 29. Wendzel, S.: Tunnel und verdeckte Kanäle im Netz. Springer-Vieweg, Wiesbaden (2012) 30. Wikipedia: Eintrag zum Thema „Huffman-Kodierung“ (2018). https://de.wikipedia.org/wiki/ Huffman-Kodierung. Zugegriffen am 01.06.2018 31. Zander, S.: Performance of Selected Noisy Covert Channels and Their Countermeasures in IP Networks. Dissertation, Faculty of Information and Communication Technologies, Centre for Advanced Internet Architectures, Swinburne University of Technology (2010)

3

Grundlagen der IT-Sicherheit

For generations, people have defined and protected their property and their privacy using locks, fences, signatures, seals, account books, and meters. These have been supported by a host of social constructs ranging from international treaties through national laws to manners and customs. This is now changing, and quickly. – Ross Anderson (2001)

Zusammenfassung

Dieses Kapitel führt die Grundlagen der IT-Sicherheit ein. Es betrachtet die wichtigsten Begriffe samt Schutzzielen, zentrale Aspekte von Authentifizierung und Zugriffsschutz, das Thema Privatsphäre sowie Schadsoftware. Außerdem gibt es einen Einblick in nicht-technische Bereiche, die mit der IT-Sicherheit in Verbindung stehen. Das Kapitel schließt mit einem Einblick in die Wissenschaftlichkeit der IT-Sicherheit (Science of Security).

3.1

Einführung

Eine Bildersuche bei Google nach den Begriffen „IT-Sicherheit“ und „Netzwerksicherheit“ führt zu ganz unterschiedlichen Eindrücken. Oftmals sitzen maskierte Personen vor einem Computer, manchmal wird ein Netzwerkkabel sinnfreier Weise durch ein Schloss geführt. Unabhängig von diesen medial wirksamen Vorstellungen hat das Thema ITSicherheit seit vielen Jahren an Bedeutung gewonnen hat und eine Umkehr dieses Trends ist noch nicht absehbar. Dies bezieht sich etwa auch auf den Stellenwert der IT-Sicherheit in der Ausbildung und Hochschullehre [9].

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2018 S. Wendzel, IT-Sicherheit für TCP/IP- und IoT-Netzwerke, https://doi.org/10.1007/978-3-658-22603-9_3

79

80

3 Grundlagen der IT-Sicherheit

Dieses Buch betrachtet die IT-Sicherheit von Rechnernetzen. Das heißt, es bezieht IT-Sicherheit auf die netzwerkseitigen Aspekte von IT-Systemen. Nicht netzwerkseitig sind zum Beispiel Themen wie das sichere Programmieren oder der Speicherschutz in Betriebssystemen. Ein Studium der Netzwerksicherheit beinhaltet auch das Studium der Unsicherheit von Netzwerken und die Absicherung von Netzwerken. Es beinhaltet sämtliche Phasen des Lebenszyklus von Netzwerken – von der Planung, über die Inbetriebnahme, dem Betrieb samt Wartung, bis hin zur Außerbetriebnahme. Weiterhin beinhaltet dieses Studium Aspekte auf technischer sowie – zum gewissen Teil – auf organisatorischer Ebene. Was ist zunächst einmal unter dem zugrunde liegenden Begriff der IT-Sicherheit zu verstehen? Eckert schreibt in ihrem Standardwerk zur IT-Sicherheit: Definition 3.1. IT-Sicherheit hat die Aufgabe, Unternehmen und deren Werte (Knowhow, Kundendaten, Personaldaten) zu schützen und wirtschaftliche Schäden, die durch Vertraulichkeitsverletzungen, Manipulation oder auch Störung der Verfügbarkeit von Diensten des Unternehmens entstehen können, zu verhindern [12]. Hierbei könnte der Begriff „Unternehmen“ auch durch „Organisation und Individuen“ ersetzt werden. Neben Werten wäre dann auch die Privatsphäre schützenswert. Außerdem wären neben wirtschaftlichen Schäden sicherlich auch staatlich-hoheitliche oder persönliche Schäden durch Schaffung von IT-Sicherheit zu vermeiden. Gemeinhin wird IT-Sicherheit auch als Zustand betrachtet, nämlich der Zustand, in dem die IT-Infrastruktur exakt den Zweck erfüllt, für den sie vorgesehen ist. Ungewünschte Zwecke wären folglich nicht vorgesehen. In [25] relativierten wir diese Aussage jedoch sogleich, da die verwendeten Begriffe „Zweck“ und „IT-Infrastruktur“ nicht exakt definiert sind. Dennoch ist diese prägnante Definition hilfreich. Wenn ein Angreifer dafür sorgt, dass die IT-Infrastruktur nur einen Teil des vorbestimmten Zwecks abdeckt (weil beispielsweise Daten gelöscht wurden) oder zusätzliche Aufgaben durchführt (etwa Spam versenden), dann erfüllt sie nicht mehr „exakt den Zweck . . . für den sie vorgesehen“ wurde. Sicherheit kann auch mehrseitig betrachtet werden. Mehrseitige Sicherheit (engl. Multilateral Security) berücksichtigt die Sicherheitsanforderungen aller Beteiligten. Rannenberg et al. merken an, dass sich bei offenen Kommunikationssystemen [nicht alle Beteiligten] per se vertrauen [und sich daher] als potentielle Angreifer [sehen] können [26]. Eine Definition von mehrseitiger Sicherheit gibt Pfitzmann: Definition 3.2. Mehrseitige Sicherheit bedeutet die Einbeziehung der Schutzinteressen aller Beteiligten sowie das Austragen daraus resultierender Schutzkonflikte, etwa beim Entstehen einer Kommunikationsverbindung [23]. Er führt weiter an, dass diese Beteiligten jeweils Individualziele verfolgen und Teil unterschiedlicher Gemeinschaften sein können. Dabei können sie nicht nur legitime Rechte

3.1 Einführung

81

und Ansprüche an die Gemeinschaften, sondern Gemeinschaften [können] auch [Ansprüche] an ihre Mitglieder haben. Nicht immer sind die Ziele aller Beteiligten miteinander vereinbar und nicht immer kann eine für alle Beteiligten akzeptable Kommunikation realisiert werden [23]. Zur Definition des Zustands Netzwerksicherheit lässt sich obige Aussage leicht abändern, indem statt von einer IT-Infrastruktur von einem Rechnernetz gesprochen wird. Das heißt: Definition 3.3. Netzwerksicherheit, das heißt die IT-Sicherheit von Rechnernetzen, ist der Zustand, in dem ein Rechnernetzwerk samt seiner Komponenten exakt den vom Netzwerkbetreiber angedachten Zweck erfüllt, für den es vorgesehen ist. Der Zweck kann dabei verschiedene Teilaspekte aufweisen, etwa E-Mails zu versenden und Daten verteilt zu speichern. Der Zweck kann zudem erweitert werden und ändert sich mit seiner Erweiterung. Eine illegitimer Zweck (beispielsweise das Versenden von Spam über ein Netzwerk) würde den angedachten Zweck hingegen erweitern oder verändern. Das heißt, ein Angriff – etwa durch Löschen von Daten – würde einen angedachten Zweck unmöglich machen. Da in der obigen Definition von „exakt dem angedachten Zweck“ die Rede ist, wäre der Zweck nicht mehr realisiert und die Netzwerksicherheit nicht mehr gegeben.

Exkurs: Sabotage außerhalb von IT-Systemen Anfang 1944 gab das amerikanische Office of Strategic Services (OSS), der Vorläufer der heutigen CIA, ein Sabotage-Handbuch für seine Agenten heraus [22]. Mittlerweile ist das Handbuch frei im Internet verfügbar und nicht mehr geheim. Das Handbuch beschreibt den Umgang mit gewöhnlichen Bürgern, die zur Sabotage angestiftet werden sollen, insbesondere im Dritten Reich. Die Lektüre des Handbuchs ist auch für Studierende und Professionals der IT-Sicherheit relevant, da es einen Blick über den Tellerrand der eigentlichen Disziplin wirft und sich dem Leser Parallelen zwischen hochtechnlogischen Angriffen und traditionellen Sabotagekonzepten aufzeigen. Ein Großteil der Angriffe würde auch bei heutigen Unternehmen Früchte tragen und viele der dargestellten Sabotageakte sind eher subtil und bestehen ganz und gar nicht darin, große Explosionen zu verursachen. So besteht eine Überlegung etwa darin, unschöne Situationen in Organisationen des Feindes zu schaffen und langsam die Moral von Mitarbeitern oder Bürgern zu untergaben. Es kann sich dabei etwa darum handeln, dass Saboteure Prozesse verzögern, weil sie bestimmte Dokumente schlicht zu spät bearbeiten. Es spielt letztlich nur eine sekundäre Rolle, ob eine derartige Sabotage zur Kriegszeit mit Papier oder heutzutage mit einem Computer durchgeführt wird. (Fortsetzung)

82

3 Grundlagen der IT-Sicherheit

Auch Denial-of-Service-Angriffe lassen sich im Handbuch finden. So besteht ein Angriff etwa darin, die Toiletten mit zusammengerolltem Toilettenpapier, Haaren und anderen Gegenständen zu verstopfen. Auch die Entflammbarkeit von Gebäuden kann durch Saboteure begünstigt werden. Weitere Angriffe konzentrieren sich beispielsweise auf Kühlsysteme, elektrische Motoren, den Schienenverkehr, Telegraphen, die Stromversorgung oder das simple Verteilen von Nägeln auf der Straße. Das heute in der IT-Welt vorhandene Social Engineering lässt sich in den 1940erJahren ebenso finden. So wird etwa vorgeschlagen, die Moral von Arbeitern zu untergraben, indem solche Arbeiter, die es in keiner Weise verdient haben, vor den Augen der anderen befördert werden.

Somit stellt sich auf Basis der obigen Definition die Frage nach den primären Zielen von IT-Sicherheit und damit auch der IT-Sicherheit von Netzwerken. Bishop nennt drei Ziele [8], nämlich: 1. die Prävention von Angriffen (prevention of attacks), 2. die Angriffsdetektion (detection of attacks) und 3. die Systemwiederherstellung (recovery), die er wiederum in zwei Teilaspekte gliedert: a. stattfindende Angriffe stoppen und die Reperatur des Systems durchführen b. sowie die Funktionsfähigkeit eines Systems während einem laufenden Angriffs gewährleisten. Diese Ziele sind verwandt mit den sogenannten Schutzzielen der IT-Sicherheit, die im nächsten Abschnitt betrachtet werden. Genauer gesagt handelt es sich bei den von Bishop genannten Zielen um solche, die zur Erfüllung der Schutzziele beitragen können. So kann das Ziel Systemwiederherstellung etwa zum Schutzziel Verfügbarkeit beitragen. Die von Bishop genannten Ziele sind allerdings nicht hinreichend, um sämtliche Schutzziele unter jeder Bedingung zu erreichen.

Exkurs: Hacker, Cracker und Co. Der Begriff Hacker bezeichnet jemanden, der kreativ mit (technischen) Dingen umgeht beziehungsweise ein sehr fähiger Programmierer ist, es kann sich aber beispielsweise auch um einen fähigen Musiker handeln. Raymond beschreibt einen Hacker wie folgt: (Fortsetzung)

3.2 Schutzziele der IT-Sicherheit

83

Definition 3.4. There is a community, a shared culture, of expert programmers and networking wizards that traces its history back through decades to the first timesharing minicomputers and the earliest ARPAnet experiments. The members of this culture originated the term ‘hacker’. Hackers built the Internet. Hackers made the Unix operating system what it is today. Hackers make the World Wide Web work. If you are part of this culture, if you have contributed to it and other people in it know who you are and call you a hacker, you’re a hacker [27]. Hacker stehen insbesondere mit der Bewegung um freie Software in Verbindung [16, 21]; sie entwickelten bedeutsame Software, die auf fast jedem heute verwendeten Computer zum Einsatz kommt, etwa Linux, BSD und diverse Bibliotheken, siehe unter anderem [16,21,33]. Ein Grundkonzept der Hacking-Community ist das Teilen von Wissen, Erkenntnissen und Werkzeugen. Erst später wurde aus dem Hacker durch diverse Publikationen und Medienbeiträge ein böswilliger Angreifer gemacht. Diese Begriffsverwendung ist allerdings nicht korrekt. Wenn in diesem Buch von einem Hacker die Rede ist, dann ist ein kreativer Angreifer auf ein IT-System gemeint, der die Sicherheit eines Systems überprüft oder erhöht. Der Begriff wird ohne Bezug auf ein Geschlecht verwendet und soll primär die Kompetenz des Angreifers betonen. Oftmals werden Hacker in White hats und Black hats (oder Crackers) eingeordnet, also in solche die hacken, um Systeme zu sichern (Sicherheitslücken finden, ausbessern oder neue Sicherheitssysteme entwickeln) und solche, die hacken, um in Systeme einzudringen beziehungsweise diese sonstig negativ zu beeinflussen [4]. Dies ist konträr zur Auffassung von Raymond, der schreibt hackers build things, crackers break them; Black hats wären demnach folglich keine Hacker. Individuen, die nicht klar als White hat oder Black hat einzuordnen sind, werden oft Grey hats genannt. Neben Hackern gibt es die als unfähig betrachteten Individuen, die etwa nur in der Lage sind, fertige Angriffstools zu verwenden, aber diese nicht verstehen und nicht selber entwickeln können. Diese Art von Angreifer nennt sich Script Kiddie – im Sinne von Kindern, die mit bösartigen Skripten herumspielen. Der primäre Unterschied zwischen Hackern und Script Kiddies liegt folglich im Kompetenzniveau und in den Absichten.

3.2

Schutzziele der IT-Sicherheit

Es gibt drei wesentliche Schutzziele der IT-Sicherheit. Diese Schutzziele werden auch als CIA-Triade bezeichnet [6]. Das Kürzel CIA ergibt sich aus den Anfangsbuchstaben der drei englischen Bezeichnungen dieser Schutzziele. Dabei handelt es sich um Vertraulichkeit (confidentiality), das heißt es gibt keine unautorisierte Informationsgewinnung;

84

3 Grundlagen der IT-Sicherheit

Integrität (integrity), das heißt es ist Subjekten nicht möglich, die zu schützenden Daten unatorisiert und unbemerkt zu manipulieren; und Verfügbarkeit (availability), das heißt authentifizierte und autorisierte Subjekte werden in der Wahrnehmung ihrer Berechtigungen nicht unautorisiert beeinträchtigt [12]. Auch die Authentizität (authenticity) stellt ein Schutzziel dar. Sie ist gegeben, wenn durch geeignete Kontrollmaßnahmen sichergestellt wird, dass Daten und Informationen wirklich aus der angegebenen Quelle stammen und dass die Identität eines Benutzers oder eines angeschlossenen Systems korrekt ist, sie wird auch als Echtheit bezeichnet [6]. Zudem existiert das Schutzziel Verbindlichkeit (non-repudiation oder auch Nicht-Abstreitbarkeit und Unleugbarkeit). Verbindlichkeit bedeutet, dass von Subjekten durchgeführte Aktionen nachgewiesen und im Nachhinein nicht geleugnet werden können und das Daten/Dokumente Quellen zugeordnet werden können [6]. Verbindlichkeit kann beispielsweise durch digitale Signaturen erzielt werden. Weitere Schutzziele sind etwa die Anonymität und die Unverkettbarkeit, die in Abschn. 3.6 genauer betrachtet werden.

3.3

Schwachstellen, Verwundbarkeiten und Co.

Die zuvor besprochenen Schutzziele können durch Bedrohungen beeinträchtigt werden, doch worum handelt es sich dabei genau? Zunächst einmal muss definiert werden, was eine Schwachstelle (engl. Weakness) ist. Eine Schwachstelle ist eine Schwäche in einem System, etwa ein Drucker mit alter, fehlerhafter Software, der alle zwei Wochen eine leicht blasse Seite druckt. Diese Schwachstelle ist zunächst einmal ärgerlich, aber noch nicht sicherheitsrelevant. Diese Tatsache entspricht meist nicht dem Grundverständnis des Begriffs: In Debatten außerhalb der Sicherheits-Community wird der Begriff Schwachstelle nämlich gern mit Verwundbarkeit gleichgesetzt. Eine Verwundbarkeit (engl. Vulnerability) ist eine Schwachstelle, die durch einen Angreifer zu seinem Vorteil und zum Nachteil des zu schützenden Systems werden kann. Beispielsweise könnte der oben genannte Drucker einen Codeabschnitt besitzen, der es ermöglicht, ein Verzeichnis auszulesen, das Daten anderer Druckaufträge beinhaltet (Schutzziel: Vertraulichkeit). Die Verwundbarkeit kann wiederum zu einer Bedrohung (engl. Threat) werden, wenn ein Weg existiert, mit dem ein Angreifer die Verwundbarkeit tatsächlich ausnutzen kann. Zum Beispiel könnte es sein, dass die Verwundbarkeit des Druckers ausnutzbar wäre, wenn HTTP-Zugriff auf einen Webservice des Druckers existiert. Ein Angreifer könnte dann über HTTP eine Anfrage stellen, die die Verwundbarkeit (den besagten Codeabschnitt) ausnutzt, und somit ein Verzeichnis auslesen. Wäre dieser Webservice jedoch deaktiviert, dann wäre keine Bedrohung, sondern nur eine Verwundbarkeit gegeben. Wenn der Webservice hingegen aktiviert wäre, und der Angreifer die Verwundbarkeit mit einer entsprechenden HTTP-Anfrage ausnutzen kann, dann liegt eine Bedrohung vor.

3.4 Zugriffskontrolle

85

Zu schützende Werte (etwa vertrauliche Kundendaten) werden als Assets bezeichnet. Diesen Assets kann ein individueller Wert zugewiesen werden. Bei einem Bankhaus wird der Wert von Bankdaten der VIP-Kunden beispielsweise höher ausfallen, als der Wert von Kundendaten bei einer Bäckerei. Wenn sowohl den Assets (A), als auch den zugehörigen Verwundbarkeiten (V ) und Bedrohungen (B) Werte zugewiesen werden, dann lässt sich das Risiko (engl. Risk, R) berechnen. Üblicherweise werden hierbei Werte von 1–5 verwendet. Summiert man die drei Werte und subtrahiert den Wert 2, dann erhält man eine Skala von 1–13 [30].1 R = A+V +B −2

(3.1)

Alternativ lässt sich das Risiko auch so ausdrücken, das die Eintrittswahrscheinlichkeit eines Schadens (PE , wobei 0 ≤ PE ≤ 1) mit den damit verbundenen Kosten (Schadenshöhe, SE , wobei 0 ≤ SE ≤ ∞) kombiniert wird [12, 20]. R = PE · SE .

(3.2)

Dabei sollte beachtet werden, dass sich die Eintrittswahrscheinlichkeit eines Schadens abhängig von der Bedrohungslage ändern kann. Wenn beispielsweise kaum Angriffsmöglichkeiten für einen bestimmten Browser verfügbar wären, nun aber ein neues Programm auftaucht, dass eine besonders schwerwiegende Verwundbarkeit ausnutzt und diese durch die Medien kommuniziert wird, steigt die Eintrittswahrscheinlichkeit deutlich an.

3.4

Zugriffskontrolle

Ein grundlegendes Problem der IT-Sicherheit ist der Schutz des Zugriffs auf Ressourcen. Hiermit sind also mindestens die Schutzziele der Vertraulichkeit und Integrität verbunden. Es geht um Autorisierung und dabei werden primär zwei Modelle unterschieden: • Discretionary Access Control (DAC) – benutzerbasierte und -bestimmbare Zugriffskontrolle; Zugriff auf Daten wird anhand einer Identität getroffen. • Mandatory Access Control (MAC) – Zugriffskontrolle auf Basis von Regeln und Attributen, etwa einem bestimmten ‘Label’. DAC und MAC werden im Folgenden detaillierter betrachtet. Sie lernen Beispielansätze zur Umsetzung dieser Modelle kennen.

1 Andernfalls würde die Skala unschönerweise bei 3 beginnen.

86

3.4.1

3 Grundlagen der IT-Sicherheit

Discretionary Access Control (DAC)

DAC ist das bekannteste und grundlegendste Modell und lässt sich durch eine Zugriffskontrollmatrix abbilden, bei der Spalten und Zeilen die Objekte und Benutzer (und in einer weiteren Matrix die Objekte und Gruppen) abbilden. Für jede Art Zugriffsrecht wird dabei eine separate Matrix definiert. So kann eine Matrix etwa das Leserecht abdecken, eine andere das Schreib- und eine weitere das Ausführungsrecht für Dateien. Weitere Rechte, etwa für das Hinzufügen von Inhalten an eine Datei (Append) können nach Bedarf definiert werden. Illustration: Ein Zugriff auf ein Verzeichnis, für das ein Benutzer – wie im folgenden Listingbeispiel – keine Berechtigung hat, wird durch das Attribut Benutzer (und seiner Gruppenzugehörigkeit) überprüft. Der Benutzer „hsw“ und die Gruppe „hsw“ haben keinen Zugriff auf das Objekt /root. $ cd / r o o t b a s h : cd : / r o o t : K e i n e B e r e c h t i g u n g $ l s −l d / r o o t drwx−−−−−− 7 r o o t r o o t 4096 Okt 21 2 2 : 4 0 / r o o t $ id u i d = 1000( hsw ) g i d =1000( hsw ) Gruppen = 1000( hsw )

3.4.2

DAC-Erweiterungen

Nun ist es nicht immer praktikabel – insbesondere bei einer großen Anzahl an Benutzern –, jedes Zugriffsrecht für jeden Benutzer und jedes Objekt zu definieren. Aus diesem Grund wurde das DAC-Modell erweitert. Das klassische Modell für Zugriffsrechte unter Unix (Eigentümer, Gruppe und andere Benutzer, siehe etwa [37]) wurde insofern erweitert, dass Zugriffsrechte für mehrere Benutzer (statt nur für den assoziierten Eigentümer) und mehrere Gruppen (statt nur für die assoziierte Gruppe) geregelt werden können. Dieses Verfahren nennt sich Access Control Lists (ACL). Es können neben Lese-, Schreib- und Ausführungsrecht weitere Rechte definiert werden. Alle gängigen Betriebssysteme für Server und Workstations unterstützten ACL in unterschiedlichen Varianten. Role-based Access Control (RBAC) erlaubt hingegen den Zugriff eines Benutzers auf ein Objekt nicht mehr durch die Identität des Benutzers, sondern auf Basis der Zugehörigkeit des Benutzers zu einer bestimmten Rolle. So könnte beispielsweise die Rolle Entwickler-P1 für die Entwickler des Projekts P1 definiert werden. Anstatt jedem Benutzer nun die nötigen Zugriffsrechte zu geben, wird ein Entwickler nur noch der Rolle zugewiesen. Zugriffsrechte werden wiederum der Rolle gegeben. RBAC bringt allerdings das Problem mit sich, dass es statisch ist. Das heißt, dass dynamische Rechteänderungen nicht vorgesehen sind, die aber in lebendigen Organisationen oft vorkommen können, weil

3.4 Zugriffskontrolle

87

ein Mitarbeiter etwa die Aufgaben eines im Urlaub befindlichen Kollegen übernehmen muss und daher entsprechende Zusatzrechte benötigt. Schlegel schlägt daher ein dynamisches RBAC-Zugriffsmodell vor, das für derartige Situationen ausgelegt ist [29].

3.4.3

MAC und DAC: Das Bell-LaPadula-Modell

Es2 gibt sogenannte Multilevel Security-Richtlinien (MLS-Richtlinien). Bei diesen Richtlinien werden verschiedene Sicherheitslevels, etwa „Geheim“ oder „Streng Geheim“ vergeben. Das BLP-Modell sichert die Vertraulichkeit von Daten im Kontext eines MLSSystems und wurde 1973 von Bell und LaPadula vorgestellt. Das BLP-Modell enthält eine Menge von Sicherheitslevels. Eine höhere Klassifikation wird durch einen höheren Sicherheitslevel ausgedrückt und entspricht dabei auch einer höheren Datensensitivität. Jedes Subjekt s hat eine Security Clearance L(s), etwa L(John) = confidential, dies entspricht dem maximalen Sicherheitslevel des Subjekts. Jedes Objekt o ist einer Classification zugeordnet: L(o), beispielsweise L(Dateix ) = secret. Clearance und Classification beziehen sich auf dieselben Sicherheitslevels. Der Unterschied besteht darin, dass ein Subjekt seinen Sicherhitslevel zu einem Sicherheitslevels unterhalb seiner Clearance reduzieren kann. Objekte können dies nicht tun. Das BLP-Modell realisiert DAC-Zugriff basierend auf einer Access Control Matrix (Zugriffsmatrix), beinhaltet darüber hinaus aber zwei „Mandatory“-Regeln (für MAC zuständig), die unbedingt eingehalten werden müssen. Es gibt zwei dieser MandatoryRegeln: • Simple Security Condition (oder: No Read-up, NRU): Ein Subjekt s kann nur lesend auf ein o zugreifen, wenn L(s) ≥ L(o). • *-Property (oder No Write-down, NWD): Ein Subjekt s kann nur schreibend (Write/Append) auf o zugreifen, wenn gilt L(s) ≤ L(o). Jeweils muss zusätzlich DAC-basierter Zugriff für s auf o erlaubt sein, andernfalls wird der Zugriff verweigert.

3.4.3.1 Kategorien im BLP-Modell Das BLP-Modell kennt zudem sogenannte Kategorien, die spezifische Zugriffsberechtigungen auf Basis von beispielsweise Projekten oder Organisationseinheiten erlauben. Kategorien können sowohl Subjekten als auch Objekten zugewiesen werden. Auch hierbei muss jeweils noch DAC-basierter Zugriff für s auf o erlaubt sein.

2 Dieser Abschnitt basiert auf [36] und wurde für dieses Buch ins Deutsche übersetzt und erweitert.

88

3 Grundlagen der IT-Sicherheit

Beispiel. In einer Organisation existieren die Kategorien accounting, development, und support. John hat die Clearance (confidential, {accounting, support}). Der erste Parameter gibt in dieser Schreibweise den eigentlichen Sicherheitslevel an, der zweite die Kategorien. Man bezeichnet die Kombination beider Parameter jedoch ebenfalls als Sicherheitslevel oder auch Compartment. Das Objekt f ilex sei hingegen klassifiziert als (secret, {accounting}). Die sogenannte dom-Relation (für domination) erlaubt nun die Nutzung der Compartments. Das Compartment (L, C) hat den Sicherheitslevel L und die Kategorie C. (L, C) dom (L , C  ) gilt, wenn L ≤ L und C  ⊆ C [8]. Lesezugriff auf ein Objekt wäre also nicht möglich, wenn das Objekt einen Sicherheitslevel hätte, der höher als der des Subjekts ist, selbst dann, wenn der Zugriff über die Kategorien gegeben wäre [8]. Die bisherigen beiden Mandatory-Regeln NRU und NWD können nun wie folgt modifiziert werden, um mit Kategorien zu arbeiten: • Lesezugriff für s auf o ist nur erlaubt, wenn s dom o gilt und DAC-basierter Lesezugriff für s auf o gegeben ist (NRU-Regel). • Schreibzugriff für s auf o ist nur erlaubt, wenn o dom s gilt und DAC-basierter Schreibzugriff für s auf o gegeben ist (NWD-Regel). Beispiel. Die Subjekte Alice and Bob möchten auf das Objekt databasex lesend zugreifen (siehe Abb. 3.1). Es liegt folgende Situation zugrunde: • (L, C) für Alice: (secret, {accounting, research}) • (L, C) für Bob: (conf idential, {accounting, support}) • (L, C) für databasex : (conf idential, {support}) Alice würde in diesem Fall keinen Zugriff auf databasex erhalten, obwohl L(Alice) > L(databasex ) hat. Doch Alice hat keinen Zugriff auf die Kategorie support, das heißt Alice ¬dom databasex . Bob würde diesen Lesezugriff hingegen erhalten, denn L(Bob) = L(databasex ) und {support} ⊂ {accounting, support}, folglich Bob dom databasex . Abb. 3.1 Beispielszenario für das BLP-Modell.

3.5 Authentifizierung

89

MLS-Zugriffsschutz ist unter Linux beispielsweise durch SELinux möglich. SELinux unterstützt im Übrigen auch Role-based Access Control (RBAC), das heißt dass Subjekte basierend auf ihren Rollen Zugriff auf Objekte erhalten.

3.4.3.2 Tranquility und Weak Tranquility Das Konzept der Tranquility besagt gemäß Bishop, dass Subjekte und Objekte ihre Sicherheitslevel nicht im Nachhinein ändern können. Weniger restriktiv ist das Konzept der Weak Tranquility, das den Wechsel von Sicherheitslevels unter der Bedingung erlaubt, dass die Sicherheitsrichtlinie nicht gebrochen wird [8]. Zur Umsetzung von Weak Tranquility wird ein vertrauenswürdiger Dritter benötigt, der den Sicherheitslevel anpasst [8]. 3.4.3.3 BLP und verdeckte Kanäle Wenn ein Zugriff so passiert, dass die Regeln NRU oder NWD verletzt werden (MLSKontext) beziehungsweise generell eine Sicherheitsrichtlinie verletzt wird, repräsentiert die zugehörige Kommunikation einen sogenannten verdeckten Kanal (engl. covert channel). Covert Channels wurden in den frühen 1970ern von Lampson eingeführt. Viele der frühen Kanäle funktionierten über die Ausnutzung von Systemressourcen, insbesondere Hardware. Da verdeckte Kanäle auch in Netzwerken vorliegen, werden diese in Kap. 9 ausführlich behandelt.

3.5

Authentifizierung

Der Fokus des vorherigen Abschnitts lag auf der Zugriffskontrolle. Wie aber identifizieren Systeme Benutzer, um Zugriffskontrolle zu ermöglichen? An dieser Stelle kommt die Authentifizierung ins Spiel, sie ist der Prozess der Überprüfung auf Authentizität (Echtheit) eines Subjekts durch ein System. Unterschieden werden müssen hierbei zwei Verben. Ein Benutzer authentisiert sich gegenüber einem System (beispielsweise durch Angabe eines Passworts). Das System wiederum überprüft anschließend die Korrektheit des Passworts (es authentifiziert den Benutzer). Ein System speichert im simpelsten Fall nur Tupel (Benutzername, Passwort) lokal ab. Dadurch kann es bei der Anmeldung eines Benutzers überprüfen, ob Benutzer samt Passwort miteinander verbunden sind. Ein Passwort P sollte jedoch nicht im Klartext gespeichert werden. Eine sogenannte Hashfunktion H (P ) speichert ein Komprimat (Prüfsumme) des Passworts. Ein sicheres Komprimat ist nicht zurückrechenbar, das heißt, H ist nicht umkehrbar, sodass selbst mit hohem Rechenaufwand nicht auf das Originalpasswort geschlossen werden kann. Es liegt folglich nicht der Klartext des Passworts vor. Anschließend wird überprüft, ob das Komprimat des von einem Benutzer angegebenen Passworts PA mit dem Komprimat eines tatsächlichen Passworts PB übereinstimmt, das heißt, ob H (PA ) = H (PB ) gilt. Diverse Hashfunktionen existieren; sie werden in Abschn. 4.8 besprochen.

90

3 Grundlagen der IT-Sicherheit

Stärkere Formen der Authentifizierung existieren, etwa die Mehrfaktorenauthentifizierung, bei der mehrere Authentifizierungsmechanismen kombiniert werden – oftmals zwei, man spricht in diesem Fall von einer Two Factor Authentication (2FA). Eine weitere Möglichkeit, ist die Verwendung von Einmalpasswörtern (One-time Passwords, OTP). Dabei erhält ein Benutzer eine Liste mit Passwörtern und jedes dieser Passwöter darf nur einmalig verwendet werden. Nachdem eine Liste (weitestgehend) aufgebraucht wurde, erhält der Benutzer eine neue Liste an Passwörtern. Auch verbreitet sind Challenge-Response-Verfahren. Bei diesen bekommt ein Benutzer bei der Anmeldung von einem System eine Aufgabe (engl. Challenge) von selbigem gestellt. Diese Challenge muss der Benutzer korrekt beantworten. Die Beantwortung (engl. Response) ist nur möglich, wenn der Benutzer über geheimes Wissen verfügt. Oftmals werden hierbei Zufallszahlen als Challenge verwendet. Als Response kann etwa verlangt werden, die Zufallszahl mit einem bestimmten kryptografischen Schlüssel zu verschlüsseln. Genereller formuliert kann eine solche Zufallszahl auch als Parameter für eine mathematische Funktion dienen; das Ergebnis der Funktion muss anschließend als Response zurückgesendet werden. Eine Kombination aus Einmalpasswörtern und Challenge-Response-Verfahren sind TAN-Verfahren, bei denen ein Benutzer eine Liste von Nummern (TANs) erhält, die alle nur einmalig nutzbar sind. Die Challenge besteht darin, dass bei der Anmeldung an einem System (etwa Onlinebanking) eine TAN-Nummer verlangt wird. Als Response muss der Benutzer die TAN mit dieser Nummer aus der Liste heraussuchen und eingeben. Außerdem gibt es die Möglichkeit einer biometrischen Authentifizierung. Zum Einsatz kommen können dabei unter anderem Fingerabdrucksensoren, Irisscaner, Retinascanner, Geräte zur Erkennung von Mustern der Venen und Gesichtserkennung. Derartige Sensorik für verschiedene Bestandteile des menschlichen Körpers kann außerdem zu der erwähnten Mehrfaktorauthentifizierung kombiniert werden. Eine biometrische Mehrfaktorauthentifizierung kann sinnvoll sein, um Angriffe zu erschweren, bringt allerdings einen höheren Aufwand für Benutzer mit sich. Angreifer könnten beispielsweise versuchen, einen Fingerabdruck mithilfe von Fettrückständen eines eingelesenen Fingerabdrucks, den eine Person hinterlassen hat, zu reproduzieren (derlei Angriffe wurden in der Vergangenheit erfolgreich durchgeführt und können zum Beispiel durch eine Lebenderkennung erschwert werden). Wenn zusätzlich weitere Sensorik getäuscht werden muss (etwa ein Irisscaner), kann ein Angreifer allein durch den Angriff auf einen Sensor nicht zum Erfolg gelangen. Dabei ist zu beachten, dass manche Sensortypen fälschungssicherer sind als andere. Dies hängt damit zusammen, dass sich Sensoren hinsichtlich ihrer Genauigkeit, Fehlerraten bei der Identifikation und ihren Toleranzbereichen unterscheiden. Die Speicherung biometrischer Daten gilt als hochgradig sensitiv. Insbesondere bei biometrischen Merkmalen, die über die Lebensspanne von Menschen hinweg konstant bleiben, kann eine einmalige Entwendung biometrischer Daten auch zur Kompromittierung zukünftiger Systeme und zu Identitätsdiebstahl führen. In Kap. 8 werden selektierte protokollspezifische Authentifizierungsverfahren, etwa IEEE 802.1X, betrachtet.

3.6 Privatsphäre

3.6

91

Privatsphäre

Privatsphäre (engl. Privacy) ist gemäß Duden eine Sphäre, ein ganz persönlicher Bereich. Tatsächlich existieren diverse Möglichkeiten, Privatsphäre zu definieren, die von Porsch und Pieschl zu folgender Definition zusammengeführt wurden: Definition 3.5. Privatsphäre ist ein individueller Zustand der Abgeschiedenheit und Intimität [. . . ], der seiner stetigen Regulierung von Zuviel und Zuwenig Privatsphäre unterliegt [. . . ], wobei sich zu jedem Zeitpunkt vier verschiedene Privatsphärendimensionen unterscheiden lassen: informationale, soziale, psychische Privatsphäre [34]. Im Kontext des vorliegenden Buches ist insbesondere die informationale Dimension der Privatsphäre von Interesse.

Exkurs: Ein Auszug aus A Cypherpunk’s Manifesto [17] (1993): Privacy is necessary for an open society in the electronic age. Privacy is not secrecy. A private matter is something one doesn’t want the whole world to know, but a secret matter is something one doesn’t want anybody to know. Privacy is the power to selectively reveal oneself to the world. [. . . ] We cannot expect governments, corporations, or other large, faceless organizations to grant us privacy [. . . ]. We must defend our own privacy if we expect to have any [. . . ]. [. . . ] We know that someone has to write software to defend privacy, and since we can’t get privacy unless we all do, we’re going to write it.

3.6.1

Anonymität und Pseudonymität

Ein zentraler Begriff im Rahmen der Privatsphäre ist die Anonymität. Pfitzmann und Köhntopp definieren diesen Begriff wie folgt: Definition 3.6. Anonymity is the state of being not identifiable within a set of subjects, the anonymity set [24]. Das heißt, Anonymität ist nur möglich, falls genügend viele andere Individuen (Subjekte) eine gleiche/ähnliche Aktion ausführen könnten (Anonymity Set) und bedeutet, dass ein Subjekt innerhalb dieser Menge nicht identifizierbar ist. Anonymität nimmt mit der der wachsenden Größe des Anonymity Sets zu.

92

3 Grundlagen der IT-Sicherheit

Eine abgeschwächte Form der Anonymität ist die Pseudonymität, bei der Subjekte Pseudonyme anstelle von Identitäten verwenden. Pseudonyme lassen unter Umständen allerdings Rückschlüsse auf die dahinter verborgene Identität zu. Definition 3.7. Pseudonymity is the use of pseudonyms as IDs. [. . . ] The subject that may be identified by the pseudonym is the holder of the pseudonym [24]. Anonymität kann für Rechner und Benutzer auf Netzwerkebene hergestellt werden. Anonymisierungsdienste auf der Basis von Mixen (Abschn. 5.4) sind hierfür ein geläufiger Ansatz. Allerdings existieren Gegenmaßnahmen, die eine Deanonymisierung ermöglichen. Auch für die Pseudonymisierung gibt es viele Anwendungsfelder, etwa bei der Verarbeitung personenbezogener Daten, die IP-Adressen oder Namen beinhalten. Aus juristischen Gründen werden derlei Daten, wenn sie etwa veröffentlicht werden, so modifiziert, dass Attribute, die der Identifikation von Subjekten dienen könnten, ersetzt werden (durch Pseudonyme). So können offizielle IP-Adressen beispielsweise durch für den Privatgebrauch vorgesehene IP-Adressen ersetzt werden.3

3.6.2

Verkettbarkeit und Verfolgbarkeit

Verkettbarkeit bedeutet, dass Ereignisse, die in einem Zusammenhang und einer Abfolge stehen, miteinander verbunden werden können. Unverkettbarkeit (engl. Unlinkability) ist ein weiteres Schutzziel der IT-Sicherheit und das Gegenteil von Verkettbarkeit. Sie wird wie folgt definiert: Definition 3.8. Unverkettbarkeit von Subjekten, Objekten oder Aktionen [bedeutet], dass durch Beobachtungen des Szenarios die Wahrscheinlichkeit einer Relation zwischen enthaltenen Elementen unverändert bleibt [6]. Bedner und Ackermann führen an, dass die Nicht-Verfolgbarkeit (engl. Untraceability) eng mit der Unverkettbarkeit verwandt ist, sich im Gegensatz zu dieser aber nicht auf die allgemeine Möglichkeit des Verkettens, sondern auf das Nachverfolgen von Aktionen einzelner Personen bezieht.

3 Diese Pseudonymisierung wäre für Netzwerkdaten allerdings nur bedingt nützlich, da neben IPAdressen auch weitere Inhalte entfernt und ersetzt werden müssten.

3.6 Privatsphäre

3.6.3

93

Überwachung

Das Schutzziel der Unbeobachtbarkeit (engl. Unobservability) ist gewährleistet, wenn sich nicht erkennen lässt, wer Daten sendet oder empfängt [6]. Wenn eine Überwachung des Verhaltens eines Subjekts auf einem IT-System möglich ist, wäre die Unbeobachtbarkeit entsprechend verletzt, ferner wäre eine Überwachung möglich. Überwachung wird, wie von Bernard ausführlich in [7] beschrieben, durch erkennungsdienstliche Technologien ermöglicht, die heute in Smartphones, Wearables und sonstigen IoT-Geräten integriert sind. Die Präzision und Durchdringung der Überwachung, die durch derlei Geräte ermöglicht wird, war noch vor einigen Jahren nur in schwerwiegenden Kriminalfällen denkbar; man denke etwa an das Aufzeichnen der Aufenthaltsorte von Personen durch eine elektronische Fußfessel oder durch mobil genutzte Apps sozialer Netzwerke [7]. In den vergangenen Jahren konnte wie in einer Schleife beobachtet werden, dass Folgendes passierte: Ein fatales Ereignis (etwa ein terroristischer Anschlag) fand statt. Die Ermittlungen ergaben oft, dass die jeweiligen Attentäter sich über soziale Netzwerke, etwa Facebook, koordinierten. Politiker forderten daraufhin das immer Gleiche: eine stärkere Überwachung des Internets durch Ermittlungsbehörden und Geheimdienste. Verwendeten Attentäter eine verschlüsselte Kommunikation, etwa WhatsApp, so verlangte die Politik zudem Hintertüren in der entsprechenden Software, sodass Geheimdienste und Polizei Auswertungen vornehmen können. Auf den ersten Blick sind derlei Forderungen verständlich, doch werfen sie, auf den zweiten Blick, große Schatten auf die Privatsphäre der Bevölkerung: • Es ist nie ausgeschlossen, dass eine Datensammlung beziehungsweise Überwachung legitimer Nutzer von sozialen Medien und des Internets an sich stattfinden wird. Bei Ansätzen wie der Vorratsdatenspeicherung ist dies praktisch unumgänglich. • Hintertüren können erstens nie perfekt geheim gehalten werden und zweitens auch durch Gegenspieler (etwa feindliche Staaten, deren Geheimdienste oder beliebige Cyberkriminelle/Cracker) gefunden und somit ausgenutzt werden. • Es ist niemals ausgeschlossen, dass ein einmal entsprechend ermächtigter Geheimdienst beziehungsweise eine Polizeibehörde eines demokratischen Staates immer unter dessen – beispielsweise parlamentarischer – Kontrolle verbleibt, und, dass das Parlament auf ewig als Kontrollorgan verbleibt. Die Möglichkeit, dass Diktatoren die Macht in demokratischen Staaten ergreifen, ergibt Szenarien wie sie durch den Nationalsozialismus im Dritten Reich oder die Stasi in der DDR reichlich bekannt wurden. • Bekanntlich tauschen kooperierende Geheimdienste Daten untereinander aus. Dieser Austausch kann grenzübergreifend geschehen. Daten legitimer Benutzer sind auf diese Weise, sobald sie einmal in der Hand ausländischer Geheimdienste sind, nicht mehr

94

3 Grundlagen der IT-Sicherheit

löschbar. So könnten exfiltrierte biometrische Daten etwa dazu verwendet werden, Identitäten von unwissenden Bürgern anzunehmen. • Aufgezeichnete Daten könnten nachträglich verwendet werden, um Personen auszumachen, die einer aktuellen politischen Führung gegenüber nicht als konform gelten, etwa Dissidenten. Wären Facebook und Co. etwa dazu gezwungen, Suchbegriffe von Benutzern zugänglich zu machen, ergäben sich Szenarien wie das vom Journalisten Charles Arthur im Guardian beschriebene [3]: The problem is this: things can be done, but they open a Pandora’s box. The British government could insist that the identities of people who search for certain terror-related words on Google or YouTube or Facebook be handed over. But then what’s to stop the Turkish government, or embassy, demanding the same about Kurdish people searching on „dangerous“ topics?

Exkurs: Dumpster Diving Der Begriff Dumpster Diving deckt sich auf den ersten Blick stark mit dem Begriff Containern: das Durchsuchen von Müll, etwa zum Auffinden von Nahrungsresten. Dumpster Diving spielt allerdings auch für die IT-Sicherheit eine Rolle. Weggeforfene Dokumente im Müll von Unternehmen können Accountnamen, IPAdressen, Informationen über verwendete Software und sonstige relevante Daten enthalten, die zur Vorbereitung auf einen IT-Angriff dienen können. Diese Phase der Angriffsvorbereitung nennt sich auch Reconnaissance. Bekannt wurde das Dumpster Diving unter anderem durch den Film Hackers (dt. Hackers – Im Netz des FBI) von 1995. Dieser Film enthält zudem weitere Hinweise auf Techniken und Literatur (etwa die Rainbow Series [35] des U.S. Department of Defense) der damaligen Hacker-Subkultur.

Die Überwachung des Datenverkehrs kann als Teilkomponente beziehungsweise als eine Grundlage der Internetzensur, also der gezielten Blockade unerwünschter Kommunikationsverbindungen, betrachtet werden. Potenziell können Staaten Individuen bewerten, wie es etwa derzeit in China umgesetzt werden soll, und auf Basis solcher Bewertungen Zensurmechanismen individualisiert anwenden. Bereits in den 90er-Jahren wurden in einigen Staaten umfangreiche Überwachungssysteme etabliert. Bekannt wurde insbesondere das ECHELON-Projekt, das von den USA, Großbritannien, Australien, Kanada und Neuseeland eingerichtet wurde. ECHELON überwacht(e) die internationale Satellitenkommunikation, unter anderem auch von Bayern aus [13]. Allerdings hat auch China schon vor zehn Jahren große Anstrengungen unternommen, um Überwachung und Zensur umzusetzen [5]. Durch diverse in den vergangenen zehn Jahren bekannt gewordene Überwachungssysteme, deren Möglichkeiten hochgradig ausgefeilt sind und die von gut ausgestatteten Einheiten diverser Nachrichtendienste betrieben werden, wurde klar, dass ein Großteil der international stattfindenden Kommunikation nicht nur mitgelesen

3.7 Schadsoftware

95

werden kann, sondern auch tatsächlich mitgelesen und für den späteren Bedarf gespeichert wird. Besonders stark in der Öffentlichkeit diskutierte Überwachungssysteme der vergangenen Jahre sind insbesondere TEMPORA (Großbrittanien), PRISM (USA) sowie die dritte Ausbaustufe des russischen SORM. Weitere Programme wie RAMPART-A dienen der Überwachung von Glasfaser- oder speziell Unterseekabeln. Viele der über derlei Projekte verfügbaren Informationen wurden erst durch Whistleblower, also Personen, die geheime Informationen enthüllen, bekannt, etwa Edward Snowden. Neben Überwachungsprogrammen kamen zudem diverse Skandale ans Licht, die zeigten, dass auch Politiker nicht miteinander verfeindeter Staaten, etwa die deutsche Bundeskanzlerin, überwacht wurden. Auch wurde die Vermutung bestätigt, dass diverse Staaten ihre eigenen Bürger überwachen. Dem interessierten Leser sei an dieser Stelle der Spiegel-Beitrag zu PRISM [31] sowie eine prägnante Chronik der Ereignisse bis 2016 aus der ZEIT [40] empfohlen.

3.7

Schadsoftware

Schadsoftware (engl. Malware) ist Software, die vom Benutzer unerwünschte Funktionen ausführt, etwa Daten löscht, exfiltriert, einem Angreifer Zugang zu einem Rechner verschafft, einen Benutzer überwacht oder ihn erpresst. Es existieren verschiedene Arten von Schadsoftware. Schadsoftware samt Hintertüren kann sich in praktisch allen Komponenten eines Computers befinden, sei es im Mikrocode oder der Firmware von Chips, im BIOS, im Betriebssystemcode, in Treibern, in Bootsektoren von Speichermedien, oder in Programmcode. Die erste bekannte Schadsoftware namens Creeper wurde bereits 1971 bekannt und verbreitete sich über das damalige ARPANET. Zur Bereinigung der mit Creeper infizierten Systeme wurde Reaper entwickelt, das sich ebenfalls im ARPANET verbreitete und Creeper von befallenen Systemen entfernte.

3.7.1

Arten von Schadsoftware

Viren weisen die Eigenschaft auf, sich zu reproduzieren. Die Reproduktion erfolgt dadurch, dass sie kontinuierlich neue Dateien suchen, die so so modifizieren können, dass der Virus sich in diese neue Datei integriert. Beim neuen Virus handelt es sich im einfachsten Fall um ein exaktes Replikat des Virus, der die neue Datei infiziert hat. Die Übertragung und Infektion wird in der Regel mithilfe eines Benutzers umgesetzt. Beispielsweise könnte ein Benutzer ein mit einem Virus infiziertes Programm per E-Mail an einen anderen Benutzer senden, der das Programm auf seinem Rechner startet, womit Dateien seines Computers ebenfalls vom Virus infiziert werden. Der Virus wird dabei vom Empfänger in der Regel unbemerkt ausgeführt (es sei denn, eine böswillige Absicht

96

3 Grundlagen der IT-Sicherheit

unterliegt dieser Ausführung). Die sonstigen Funktionen eines Virus können beliebiger Art sein, so können etwa Dateien gelöscht oder verändert werden. Frühe Viren für MS-DOS infizierten oft Bootsektoren (von Disketten und Festplatten) oder Startskripte (insbesondere wurde die Datei autoexec.bat modifiziert), um das Hochfahren eines Rechners zu verhindern oder sonstige Aktionen während des Startvorgangs auszuführen. Ein äußerst bekannter Virus aus dem Jahr 2000 war ILOVEYOU, der sich über E-Mail-Anhänge mit dem Betreff „ILOVEYOU“ verbreitete. Die notwendige Benutzerinteraktion zur Verbreitung bestand darin, dass der Nutzer einen E-Mail-Anhang öffnen musste. Das Öffnen brachte wiederum ein Skript zur Ausführung. Dieses Skript enthielt den Viruscode und übernahm dessen Weiterverteilung über die E-Mail-Kontakte eines Nutzers. Da der Virus sich allerdings selbst an weitere Systeme (Nutzer dieser Systeme) senden konnte, kann er auch als Wurm definiert werden. Würmer sind, ähnlich wie Viren, Programme, die sich replizieren. Im Gegensatz zu Viren können Würmer die Vervielfältigung selbst übernehmen, während eine von einem Virus infizierte Datei zunächst auf einen anderen Computer übertragen werden muss (etwa per USB-Stick oder E-Mail-Anhang). Würmer nutzen zur Vervielfältigung Netzwerkschnittstellen aus und infiltrieren neue Systeme dadurch, dass sie deren Verwundbarkeiten ausnutzen. Der obig erwähnte Creeper war der erste bekannte Wurm. Dieses Programm kopierte sich selbst auf andere Systeme (ohne Zutun eines Nutzers). Tojanische Pferde sind als legitime Software getarnte Schadsoftware, die nach der Installation wie ein Virus arbeitet, dabei aber in der Regel universell ist, das heißt, durch den Angreifer (etwa über das Internet) steuerbar ist. Sie können zudem transitiv sein, das heißt in der Lage sein, selbst wieder eigene trojanische Pferde zu erzeugen [23]. Eine Logic Bomb (dt. logische Bombe) ist eine Schadsoftware, die ihre schädliche Funktion nur unter bestimmten Bedingungen auslöst, etwa einem bestimmten Zeitpunkt oder infolge einer bestimmten Eingabe. Sie kann illegitimer Teil einer ansonsten legitimen erscheinenden Software sein. Eine spezielle Form von Schadsoftware, die sich nicht unbedingt replizieren können muss, ist solche, die die Ressourcen eines Systems möglichst vollständig konsumiert, um ein System unnutzbar zu machen. Eine Fork Bomb erzeugt etwa in einer Endlosschleife so viele Prozesse, dass ein Betriebssystem nur noch mit der Prozessverwaltung beschäftigt ist und nicht mehr produktiv verwendet werden kann. Die frühe Schadsoftware Rabbit (1974) kopiert sich selbst so oft, bis ein System nicht mehr funktionsfähig war, weil sämtlicher Speicher beansprucht wurde. Ransomware (dt. Erpressungssoftware) infiziert einen Computer (üblicherweise über das Netzwerk) und macht die Daten des Systems unzugänglich, indem sie etwa verschlüsselt werden oder das Betriebssystem nicht gestartet werden kann. Erst wenn der Benutzer einen bestimmten Betrag (Lösegeld, engl. Ransom) zahlt, wird der Zugriff auf den Rechner – mit viel Glück – wieder freigegeben. Ein Programm, das eine Schwachstelle ausnutzt, um erweiterte Zugriffsrechte auf einem System zu erhalten oder sonstige negative Effekte zu ermöglichen, die einem Nutzer

3.7 Schadsoftware

97

sonst verwährt blieben, wird als Exploit bezeichnet. Exploits sind oftmals Teil von anderen Schadsoftwarearten, etwa Würmern und Rootkits. Rootkits ermöglichen einen – üblicherweise hochprivilegierten – Zugriff auf ein System. Ihr Name leitet sich von root (Superuser unter Linux/Unix/BSD) und kit (Werkzeug) ab. Diesen Zugriff können Rootkits etwa in Form einer Hintertür realisieren, die verdeckt bleibt, indem Modifikationen im Kernel des Betriebssystems vorgenommen werden. So können beispielsweise Inhalte eines Verzeichnisses mit einem Exploitprogramm nicht vollständig angezeigt werden, wenn ein Angreifer den entsprechenden Syscall zum Auslesen von Verzeichnisinhalten patcht. Bei Bots handelt es sich um fernsteuerbare Schadsoftware. Werden viele gleiche Bots zu einem Netzwerk zusammengeschlossen, dann bilden sie ein sogenanntes Botnetz (engl. Botnet). Botnetze werden durch einen sogenannten Botmaster gesteuert. Ein Botmaster steuert Bots üblicherweise über eine Internetanbindung und kann Bots weltweit verteilen. Bots können von ihm etwa den Befehl erhalten, weitere Systeme zu suchen, die potenzielle Opfer darstellen, und diese Systeme anschließend zu infiltrieren. Die Infiltration von Opfern erfolgt dabei auf Basis von Exploits. Ausgefeilte Bots bekommen von ihren Entwicklern zudem die Fähigkeit, mehrere Exploits und mehrere Verwundbarkeiten gleichzeitig ausnutzen zu können, was ihre Bekämpfung erschwert [14]. Dabei wird der Bot, ähnlich wie ein Wurm, dafür sorgen, dass er auf dem jeweiligen System ein Replikat von sich installiert. Bots können sich meistens selbständig beim Botmaster melden, um ihn über eine erfolgreiche Installation auf einem neuen Opfersystem zu informieren. Die Kommunikation erfolgt dabei in der Regel verschlüsselt, teils auch mithilfe von Steganografie versteckt, über einen Kommunikationskanal, der sich Command and Control Channel (C&C Channel) nennt. Ein C&C-Channel kann Standardprotokolle wie HTTP, IRC oder FTP ausnutzen. Bots wenden dabei das sogenannte Beaconing (auch Polling genannt) an: Sie fragen periodisch eine vom Botmaster bereitgestellte Informationsressoure an, die neue Anweisungen für die Bots enthalten kann. Alternativ kann der Botmaster seine Befehle auch direkt an seine Bots senden. Ein Botnetz kann dann wiederum verwendet werden, um auf Befehl des Botmasters Angriffe durchzuführen. Verbreitet sind insbesondere Denial-of-Service-Angriffe (siehe Abschn. 6.2.7) auf entsprechende Ziele sowie das massenhafte Versenden von Spam-EMails. Oftmals vermieten Botmaster den zeit- oder ressourcenbeschränkten Zugang zu einem Botnetz an Auftraggeber oder führen selbst gegen Bezahlung einen Angriff auf bestimmte Ziele aus. Große Botnetze können hunderttausende Bots beinhalten. Keylogger sind Schadsoftware (manchmal in Kombination mit einer Hardwarekomponente), die Tastatureingaben aufzeichnen und in eine geheime Datei abspeichern. Der Einsatzzweck von Keyloggern kann etwa das Aufzeichnen von Passwörtern sein. Keylogger verbleiben unbemerkt am Einsatzort und können etwa in Form eines kleinen USB-Sticks oder USB-Zwischengeräts, das zwischen Tastatur und USB-Port des Computers platziert wird, vorkommen. Spyware verfolgt das Ziel, Informationen über ein System und seine Nutzer zu sammeln. Es kann sich dabei etwa um Tastatureingaben (über Keylogger) oder besuchte

98

3 Grundlagen der IT-Sicherheit

Webseiten, Bankdaten oder E-Mail-Kontakte handeln. Die gesammelten Daten werden wiederum an einen Masterserver gemeldet und können beispielsweise für zielgerichtete Werbeeinblendungen verwendet werden [19]. Da diverse populäre Software, etwa Browser oder Apps für Smartphones, ebenfalls Daten zum Browsingverhalten sammelt, kann diese prinzipiell auch als Spyware betrachtet werden.

3.7.2

Schadsoftware-Mechanismen

Schadsoftware ist heutzutage nicht mehr nur in Form eines Programms vorliegend, das mit einem Debugger in kurzer Zeit analysiert werden kann. Stattdessen kommen Techniken für das Anti-Debugging beziehungsweise für die Anti-Forensik [11] zum Einsatz. Stellt eine Schadsoftware fest, dass sie in einem Debugger ausgeführt wird, reagiert sie anders, als wenn sie außerhalb eines Debuggers liefe. Insbesondere interessant ist Polymorphie. Polymorphie bedeutet, dass eine Schadsoftware einen Teil ihres Codes modifizieren kann. Software zur Detektion von Schadsoftware (etwa Antiviren-Programme) können somit nicht mehr auf eine statische Signatur zur Identifikation einer Schadsoftware aufsetzen. Die Software wird dabei teils verschlüsselt und entschlüsselt sich selbst zur Laufzeit, sie kann allerdings auch obfuskiert4 werden und sich zur Laufzeit deobfuskieren. Zudem kann eine Kombination aus Verschlüsselung und Obfuskation vorliegen. Etwas weiter reicht das Konzept der Metamorphie, bei der der Code (insbesondere für jede neue Version der Schadsoftware) stark modifiziert wird. Dabei kann sich der Code insbesondere selbst modifizieren und seine Größe, Struktur und Funktionsweise ändern [32]. Die Detektion metamorpher Schadsoftware ist entsprechend herausfordernd und Gegenstand aktueller Forschung. Außerdem kann Schadsoftware kryptografische Techniken, vorwiegend Verschlüsselung, einsetzen, um die Kommunikation zwischen weiteren Instanzen der Schadsoftware (bei Botnetzen) oder die Fernsteuerung (bei Trojanischen Pferden) geheim zu halten. Der Einsatz von Steganografie bei Schadsoftware ist ebenfalls möglich und wird derzeit von der CUING-Initiative (www.cuing.org) untersucht. Steganografie erlaubt das Verstecken des geheimen Nachrichtenaustauschs von Malware. In diesem Buch werden sowohl Kryptografie als auch Steganografie behandelt. Die Mechanismen von Schadsoftware greifen zudem zunehmend Virtualisierungssysteme und Hardwarekomponenten inklusive Firmware an, weshalb Gegenmaßnahmen auch auf all diesen Ebenen benötigt werden.

4 Bei der Obfuskation werden im Wesentlichen Charakteristika und Semantik des Codes verschleiert, um eine Analyse zu erschweren.

3.8 IT-Sicherheit: ein Trade-off samt Vorschriften

3.8

99

IT-Sicherheit: ein Trade-off samt Vorschriften

IT-Sicherheit ist kein rein technisches Unterfangen, bezieht es doch Endnutzer, Operatoren, Angreifer und deren Organisationen, Managemententscheidungen, Entwickler, Anbieter und Organisationsabläufe ein. Collins merkt in [10] an, dass IT-Sicherheit von Benutzern akzeptiert werden muss, aber einen Trade-off darstellt. Auf der einen Seite wird in Kauf genommen, dass Performance, Funktionalität oder Benutzerfreundlichkeit durch Sicherheitsmaßnahmen reduziert werden; auch können undurchdachte Sicherheitsmaßnahmen potenziell wiederum ausgenutzt werden, um ein System anzugreifen. Außerdem entstehen Kosten und ein Mehraufwand durch den Betrieb der Sicherheitsmaßnahmen. Auf der anderen Seite erhält der Endnutzer für diese Nachteile ein höheres Maß an eben dieser Sicherheit. Dabei merkt Collins auch an, das Benutzer als kreative Elemente betrachtet werden sollten, die Lösungen zur Umgehung von Sicherheitsmechanismen finden, um sich das Arbeiten mit diesen Systemen zu erleichtern. Ein klassisches Beispiel dafür, dass vorhandene, kostenfreie Sicherheitsmaßnahmen nicht von der breiten Masse der Benutzer verwendet werden, ist sicherlich die E-MailVerschlüsselung. Jedermann kann sie mittlerweile relativ komfortabel einsetzen, doch eben nur relativ komfortabel. Außerdem funktioniert zumindest die klassische E-MailVerschlüsselung mit PGP auch nur dann, wenn sich der Empfänger ebenfalls explizit daran beteiligt, womit sich ein Henne-Ei-Problem ergibt: Sender nutzen die Verschlüsselung nicht, weil Empfänger sie nicht benutzen. Die Empfänger benutzen die Verschlüsselung wiederum nicht, weil die Sender sie nicht benutzen. Das Gebiet der benutzbaren IT-Sicherheit (engl. Usable Security) wurde in den vergangenen zehn Jahren immer stärker untersucht. Diverse Wissenschaftler befassen sich auf renommierten Tagungen mit dem oben genannten Trade-off und mit der Usable Security. Eine gute Einführung in die psychologischen Hintergründe der IT-Sicherheit findet der interessierte Leser in [2]. Ein weiterer nicht-technischer Aspekt der IT-Sicherheit ist die Gesetzeslage. Unternehmen unterliegen gesetzlichen Vorgaben zur Sicherstellung von IT-Sicherheit, darunter fallen Themen wie das Fernmeldegeheimnis und die Bereitstellung von ITSicherheitsbeauftragten. Außerdem dürfen nicht einfach Angriffe auf fremde IT-Systeme durchgeführt werden. Ein damit verbundener Bereich sind Gegenangriffe – auch wenn ein Netzwerk von außen attackiert wird, darf ein Angreifer nicht einfach mit einem Gegenangriff von seinem Angriff abgehalten werden. Dies mag auf den ersten Blick verwundern, doch lässt sich leicht zeigen, weshalb Gegenangriffe eine schlechte Idee sind: Viele Angreifer verschleiern ihre tatsächliche Herkunft (IP-Adresse), indem sie gehackte Systeme ausnutzen. Oftmals sitzen die Angreifer sogar in anderen Ländern als die von ihnen ausgenutzten Hosts. Auch die oben genannten Botnetze fallen unter dieses Szenario. Ein Gegenangriff auf Bots würde die Systeme unwissender Dritter betreffen. Weiterhin ist aus juristischer Perspektive anzumerken, dass die Gesetzeslage je nach Land

100

3 Grundlagen der IT-Sicherheit

unterschiedlich ist und Datenverarbeitung oft international abgewickelt wird. In solchen Fällen müssen von den jeweiligen Unternehmen mehrere jeweils nationale Gesetzeslagen beachtet werden. In Konsequenz heißt dies, dass auch Software gemäß länderspezifischer Datenschutzvorgaben arbeiten muss.

3.9

Science of Security

Mit der IT-Sicherheit als Wissenschaft kann man sich auch auf einer Metaebene befassen: Science of Security, zu deutsch etwa „Wissenschaft über die Sicherheitswissenschaft“, befasst sich mit den wissenschaftlichen Grundlagen der IT-Sicherheit [15]. Dies bezieht wissenschaftstheoretische wie wissenschaftspraktische Fragestellungen ein. In der Science of Security werden Fragen danach gestellt und versucht zu beantworten, wie überhaupt Erkenntnisse im Sicherheitsbereich gewonnen werden können. Hinsichtlich der theoretischen Aspekte wird insbesondere auf der philosophischen Erkenntnistheorie aufgebaut. Hinsichtlich der praktischen Erkenntnisse wird hingegen insbesondere auf den Naturwissenschaften aufgebaut. Ich möchte das Thema an dieser Stelle anhand einiger eigener Arbeiten illustrieren. Zunächst stellten wir vor einigen Jahren fest, dass es im Bereich der Steganografie in Netzwerken eine uneinheitliche Terminologie und Taxonomie gibt, die wir in einigen Publikationen, insbesondere in [38], bereinigt haben (siehe Abschn. 9.2.2). Befasst man sich nur intensiv genug mit der Terminologie oder Taxonomie in einem Bereich, dann wird man sicherlich auch in anderen Bereichen Ungereimtheiten finden. Eine uneinheitliche Terminologie und Taxonomie bremst den Erkenntnisgewinn des jeweiligen Wissenschaftsgebiets aus, führt zu Re-Inventions (Neuerfindungen bereits bestehender Dinge, teils unter Verwendung anderer Begriffe) und erschwert zudem den Einstieg in eine Forschungsdomäne. Zu viele Versuche, die Terminologie und Taxonomie zu vereinheitlichen, können sich allerdings auch wieder negativ auf die Zugänglichkeit einer Domäne auswirken. Einen „Wildwuchs“ an Begrifflichkeiten gilt es daher zu vermeiden. Ein weiteres Thema der Science of Security ist die Beschreibung von wissenschaftlichen Methoden. So sind gleichartige Methoden immer wieder unterschiedlich beschrieben worden. Dies erschwert die Vergleichbarkeit von diesen Methoden. Wir haben in [39] beispielsweise eine Grundlage für eine einheitliche Beschreibung von Versteckmethoden aus der Steganografie gelegt. Science of Security befasst sich zudem damit, wie Gutachterverfahren ablaufen sollten. In der Wissenschaft sind diese in der Regel double blind gehalten, das heißt, die Autoren eines Aufsatzes wissen nicht, wer die Menschen sind, die ihren Aufsatz beurteilen. Gleichzeitig wissen die Gutachter nicht, wer die Autoren des Aufsatzes sind, den sie beurteilen sollen. Hierzu werden Aufsätze anonym eingereicht. Außerdem werden Gutachterprozesse von vertrauenswürdigen Dritten koordiniert – in der Regel die Organisatoren einer akademischen Tagung, die Editoren eines Buches oder einer (Ausgabe

3.11 Weiterführende Literatur

101

einer) Fachzeitschrift. Über die Qualitäts- und Gütekriterien der Beurteilung lässt sich trefflich debattieren. Ein ebenfalls bedeutsamer Gegenstand von Science of Security sind wissenschaftliche Experimente. Wie sollten Experimente in der IT-Sicherheit konzipiert, durchgeführt, beurteilt und beschrieben werden? In den Naturwissenschaften ist die Replizierbarkeit von Experimenten von fundamentaler Bedeutung. Die Reproduzierbarkeit kann in der IT-Sicherheit manchmal mit der Publikation von Quellcode ermöglicht werden. Oftmals werden allerdings auch die im Experiment verwendeten Daten (etwa Aufzeichnung von Netzwerkverkehr) benötigt, um Experimente tatsächlich reproduzieren zu können. Auch hier kann die Netzwerksteganografie als Beispiel dienen. In [18] haben wir ein Testbed entwickelt, dass der internationalen wissenschaftlichen Community zugänglich ist, um Experimente durchzuführen und in einer einheitlichen Umgebung zu reproduzieren.

3.10

Zusammenfassung

IT-Sicherheit ist ein umfassendes Themengebiet und von „der“ IT-Sicherheit eines Systems zu sprechen ist relativ unpräzise. Stattdessen sollte unterschieden werden, von welchem Schutzziel (etwa Vertraulichkeit oder Verfügbarkeit) gesprochen wird. Es gibt verschiedene Ansätze, IT-Sicherheit zu gewährleisten, etwa Authentifizierung und Autorisierung, von denen die Grundkonzepte in diesem Kapitel behandelt wurden. Von zentraler Bedeutung – insbesondere im heutigen Internet und dem Internet der Dinge – ist auch die Privatspähre. Das Ende des Kapitels lieferte einen Blick auf die verschiedenen Arten von Schadsoftware und besprach IT-Sicherheit im Kontext eines Trade-offs – IT-Sicherheit kostet schließlich etwas, beispielsweise Benutzerfreundlichkeit oder Performance. Das Gebiet der Science of Security befasst sich mit den wissenschaftlichen Grundlagen der IT-Sicherheit.

3.11

Weiterführende Literatur

Eine ausführliche Einführung in das Themengebiet der allgemeinen IT-Sicherheit bieten unter anderem Bishop [8] und Eckert [12]. Eine weitere Einführung, allerdings in das umfassende Thema Security Engineering, bietet das Werk von Anderson [2]. Anderson betrachtet dabei auch nicht-technische Aspekte (etwa Benutzbarkeit) und Anwendungsfelder (Banking, Telekommunikation). Bedner und Ackermann liefern in [6] eine wertvolle Zusammenfassung der Definition verschiedener Schutzziele, inklusive weiterführender Schutzziele, die in diesem Kapitel nicht betrachtet wurden. Für an der Hackerkultur interessierte Leser empfiehlt sich die Lektüre von Things Every Hacker Once Knew [28] sowie [16, 21, 27]. Empfehlenswert ist zudem das von Akhgar et al. herausgegebene Werk Cyber Crime and Cyber Terrorism Investigator’s Handbook [1], das sich mit der Cyberkriminalität, insbesondere aus Sicht von Ermittlungsbehörden, befasst.

102

3.12

3 Grundlagen der IT-Sicherheit

Übungsaufgaben

1. Erläutern Sie den Unterschied zwischen dem Schutzziel Verfügbarkeit und Vertraulichkeit. 2. Was versteht man unter Integrität? 3. Was ist der Unterschied zwischen einer Schwachstelle und einer Verwundbarkeit? 4. Nennen Sie ein Beispiel dafür, dass aus einer Schwachstelle eine Verwundbarkeit und aus dieser wiederum eine Bedrohung werden kann. 5. Worin besteht der Unterschied zwischen Discretionary Access Control (DAC) und Mandatory Access Control (MAC)? 6. Welche typischen Sicherheitslevels (Geheimhaltungsstufen) gibt es in der BRD? 7. In Abschn. 3.4.3.1 wurde ein Beispiel für das BLP-Modell eingeführt. Bekäme Alice (secret, {accounting, research}) lesenden beziehungsweise schreibenden Zugriff auf Databasex , wenn gelten würde, dass (L, C) für Databasex auf (confidential, {research}) gesetzt wäre? 8. Nennen Sie mindestens drei Möglichkeiten, um eine Authentifizierung umzusetzen. 9. Recherchieren Sie, welche Fähigkeiten die Projekte TEMPORA und PRISM aufweisen. Nutzen Sie dazu insbesondere die Quellen [31] und [40]. 10. Recherchieren Sie die Funktionsweise von CAPTCHAs. Was verbirgt sich dahinter? Dienen CAPTCHAS der Authentifizierung oder dem Zugriffsschutz? 11. Was bedeutet es, wenn ein Trojanisches Pferd universell und transitiv ist? 12. Was wird unter einer Logic Bomb und was unter Ransomware verstanden? 13. Was versteht man bei Botnetzen unter dem Begriff Polling (Beaconing)? 14. Wozu dient der C&C-Channel bei Botnetzen und wofür werden Botnetze typischerweise eingesetzt? 15. Erläutern Sie den Unterschied zwischen Polymorphie und Metamorphie bei Schadsoftware.

Literatur 1. Akhgar, B., Staniforth, A., Bosco, F. (Hrsg.): Cyber Crime and Cyber Terrorism Investigator’s Handbook. Syngress, Waltham (2014) 2. Anderson, R.: Security Engineering, 2. Aufl. Wiley, Indianapolis (2008) 3. Arthur, C.: ,Blame the internet‘ is just not a good enough response, Theresa May, erschienen In: The Guardian, 4. Juni 2017 4. Australian Anthill: (Borrett, L.): Hackers, Crackers, Script-Kiddies, Cyber-Spies: Can you spot the bad guy? (2010). http://anthillonline.com/hackers-crackers-script-kiddies-cyber-spies-canyou-spot-the-bad-guy/. Zugegriffen am 01.06.2018 5. Becker, K.-B.: Internetzensur in China. Aufbau und Grenzen des chinesischen Kontrollsystems. Vieweg-Springer Research (2011) 6. Bedner, M., Ackermann, T.: Schutzziele der IT-Sicherheit. Datenschutz und DatensicherheitDuD 34(5), 323–328 (2010). Springer

Literatur

103

7. Bernard, A.: Komplizen des Erkennungsdienstes. Das Selbst in der digitalen Kultur, S. Fischer Verlag GmbH (2017) 8. Bishop, M.: Computer Security. Art and Science. Addison Wesley, Boston (2003) 9. Brenner, W., Broy, M., Leimeister, J.M.: Auf dem Weg zu einer Informatik neuer Prägung in Wissenschaft, Studium und Wirtschaft. In: Informatik Spektrum, Bd. 40(6), S. 602–606. Springer, Berlin/Heidelberg (2017) 10. Collins, M.: Network Security Through Data Analysis, 2. Aufl. O’Reilly, Beijing (2017) 11. Day, D.: Seizing, imaging, and analyzing digital evidence: step-by-step guidelines. In: Akhgar, B., Staniforth, A., Bosco, F. (Hrsg.) Cyber Crime and Cyber Terrorism Investigator’s Handbook. Syngress, Waltham (2014) 12. Eckert, C.: IT-Sicherheit, 9. Aufl. De Gruyter, München (2014) 13. Federrath, H.: Überwachung in einer vernetzten Welt: Das Ende der Privatheit? In: Blick in die Wissenschaft – Forschungsmagazin der Universität Regensburg, Bd. 19, S. 18–24 (2007) 14. FortiGuard SE Team: Swarming IoT Attacks, Cryptojacking, and Ransomware Drive Dramatic Spike in Malware (2018). https://blog.fortinet.com/2018/02/20/swarming-iot-botnetscryptojacking-and-ransomware-drive-dramatic-spike-in-malware. Zugegriffen am 01.06.2018 15. Herley, C., van Oorschot, P.C.: Sok: Science, security and the elusive goal of security as a scientific pursuit. In: Proceedings of IEEE Symposium on Security and Privacy (S&P), S. 99–120. IEEE (2017) 16. Himane, P.: Die Hacker-Ethik und der Geist des Informations-Zeitalters. Riemann Verlag, München (2001) 17. Hughes, E.: A Cypherpunk’s Manifesto (1993). https://w2.eff.org/Privacy/Crypto/Crypto_misc/ cypherpunk.manifesto. Zugegriffen am 01.06.2018 18. Keidel, R., Wendzel, S., Zillien, S., Conner, E.S., Haas, G.: WoDiCoF – a testbed for the evaluation of (parallel) covert channel detection algorithms. J. Univers. Comput. Sci. (J.UCS) 24(5), 556–576 (2018) 19. Kirda, E., Kruegel, C., Banks, G., Vigna, G., Kemmerer, R.A.: Behavior-based Spyware Detection. In: Proceedings of 15th USENIX Security Symposium, S. 273–288 (2006) 20. Kühle, C.P., Lange, B., Pacholski, S.: Alternative Risikoformel für den Bereich IT-Sicherheit, Diskussionspapier. In: Proceedings of 2. Workshop IT-Sicherheitsmanagement, FHTW Berlin (2008). http://wi.f4.htw-berlin.de/users/messer/LV/Globals/ISM-Workshops/WorkshopSS08/IT-Risiko-Bewertung.pdf. Zugegriffen am 01.06.2018 21. Moody, G.: Die Software-Rebellen. Mi-Wirtschaftsbuch (2001) 22. Office of Strategic Services (OSS)/W.J. Donovan: Simple Sabotage Field Manual, Strategic Services Field Manual No. 3 (1944). https://www.cia.gov/news-information/featuredstory-archive/2012-featured-story-archive/CleanedUOSSSimpleSabotage_sm.pdf. Zugegriffen am 01.06.2018 23. Pfitzmann, A.: Datensicherheit und Kryptographie, Skript aus dem WS2000/2001, TU Dresden (2000) 24. Pfitzmann, A., Köhntopp, M.: Anonymity, unobservability, and pseudonymity – a proposal for terminology. In: Designing Privacy Enhancing Technologies, S. 1–9. Springer, Berlin/Heidelberg (2001) 25. Plötner, J., Wendzel, S.: Praxisbuch Netzwerksicherheit, 2. Aufl. Galileo Press, Bonn (2007) 26. Rannenberg, K., Pfitzmann, A., Müller, G.: Sicherheit, insbesondere mehrseitige IT-Sicherheit, it-Information Technology 38(4), S. 7–10 (1996) 27. Raymond, E.S.: How To Become A Hacker (2011) (aktuelle Version von 2017). http://catb.org/~ esr/fs/hacker-howto.html. Zugegriffen am 01.06.2018 28. Raymond, E.S.: Things Every Hacker Once Knew (2017). http://www.catb.org/~esr/faqs/thingsevery-hacker-once-knew/. Zugegriffen am 01.06.2018

104

3 Grundlagen der IT-Sicherheit

29. Schlegel, M.: Analyse und Simulation dynamischer RBAC-Zugriffssteuerungsmodelle. In: Proceedings of D-A-CH Security 2015, syssec (2015) 30. Shepherd, C., Petitcolas, F.A.P., Akram, R.N., Markantonakis, K., Fischer-Hübner, S., Lambrinoudakis, C.: An exploratory analysis of the security risks of the internet of things in finance. In: Proceedings of Trust, Privacy and Security in Digital Business (TrustBus), Lyon, S. 164–179. Springer International Publishing (2017) 31. Spiegel Online (Kremp, M., Lischka, K., Reißmann, O.: Projekt Prism US-Geheimdienst späht weltweit Internetnutzer aus (2013). http://www.spiegel.de/netzwelt/netzpolitik/projekt-prismnsa-spioniert-weltweit-internet-nutzer-aus-a-904330.html. Zugegriffen am 01.06.2018 32. Ször, P., Ferrie, P.: Hunting for metamorphic, Virus Bulletin Conference, S. 123–144 (2001). http://crypto.stanford.edu/cs155old/cs155-spring10/papers/viruses.pdf. Zugegriffen am 01.06.2018 33. Torvalds, L., Diamond, D.: Just For Fun. Wie ein Freak die Computerwelt revolutionierte, Hanser Fachbuch (2001) 34. Trepte, S., Dienlin, T.: Privatsphäre im Internet. In: Porsch, T., Pieschl, S. (Hrsg.) Neue Medien und deren Schatten. Mediennutzung, Medienwirkung und Medienkompetenz, S. 53–79. Hogrefe (2014) 35. U.S. Department of Defense: Rainbow Book Series (1988–1995). https://fas.org/irp/nsa/rainbow. htm. Zugegriffen am 01.06.2018 36. Wendzel, S.: Novel Approaches for Network Covert Storage Channels. Dissertation, FernUniversität in Hagen (2013) 37. Wendzel, S., Plötner, J.: Einstieg in Linux, 7. Aufl. Rheinwerk Verlag (2016) 38. Wendzel, S., Zander, S., Fechner, B., Herdin, C.: Pattern-Based Survey and Categorization of Network Covert Channel Techniques, Computing Surveys (CSUR), Bd. 47(3). ACM (2015) 39. Wendzel, S., Mazurczyk, W., Zander, S.: Unified description for network information hiding methods. J. Univer. Comput. Sci. (JUCS) 22(11), 1456–1486 (2016) 40. ZEIT Online (Beuth, P.): Snowden-Enthüllungen: Alles Wichtige zum NSA-Skandal (2016). http://www.zeit.de/digital/datenschutz/2013-10/hintergrund-nsa-skandal. Zugegriffen am 01.06.2018

Teil II Kryptografie

Der erste Teil dieses Buches führte in die Grundlagen der Netzwerktechnik und in zentrale Begriffe und Konzepte der IT-Sicherheit ein. Der zweite Teil baut auf diesem Wissen auf und erläutert zunächst zentrale Fundamente der Kryptografie. Im Anschluss werden anwendungsnahe Gebiete der Kryptografie, etwa VPNs, besprochen.

4

Einführung in die Kryptografie

Cryptography is fascinating because of the close ties it forges between theory and practice, and because today’s practical applications of cryptography are pervasive and critical components of our information-based society. – Ron Rivest (1997)

Zusammenfassung

Dieses Kapitel stellt eine Einführung in die Kryptografie dar. Es behandelt Grundbegriffe sowie historische Verfahren (Caesar, Vigenère, Vernam) und deren Kryptoanalyse (Friedman-Angriff und Kasiski-Test). Anschließend vermittelt es die Funktionsweise bedeutsamer Strom- und Blockchiffren ((3)DES und AES) sowie die Grundlagen von Zufallszahlengeneratoren und Hashfunktionen. Es führt ferner in informationstheoretische Grundlagen ein und befasst sich mit asymmetrischen Verfahren (Schlüsselaustausch über einen unsicheren Kommunikationskanal sowie RSA).

4.1

Einführung und Grundbegriffe

Zunächst einmal muss geklärt werden, was sich hinter dem Begriff Kryptografie verbirgt. Der Begriff stammt aus dem Griechischen: kryptós (verborgen) und gráphein (schreiben). In den weit verbreiteten Büchern finden sich einige Definitionen des Begriffs:

Rivest verfasste das Vorwort zum Buch Handbook of Applied Cryptography von Menezes et al., dem dieses Zitat entnommen wurde. © Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2018 S. Wendzel, IT-Sicherheit für TCP/IP- und IoT-Netzwerke, https://doi.org/10.1007/978-3-658-22603-9_4

107

108

4 Einführung in die Kryptografie

• Spitz et al. definieren Kryptografie als die Wissenschaft der Verschlüsselung von Informationen durch Geheimschriften beziehungsweise Chiffren [26]. • Beutelspacher et al. schreiben hingegen, die Kryptografie ist eine öffentliche mathematische Wissenschaft, in der Vertrauen geschaffen, übertragen und erhalten wird [5]. • Bishop schreibt in seinem Werk Computer Security. Art and Science: Cryptography is a deep mathematical subject [. . . ] it is the art and science of concealing meaning [6]. In diesem Buch wird nicht streng zwischen Kryptografie und Kryptologie unterschieden. Jedoch umfasst Kyptologie letztlich die Kryptografie (Entwurf von kryptografischen Verfahren) und die Kryptoanalyse (Analyse von kryptografischen Verfahren) [5]. Dieses Kapitel betrachtet beide Teilaspekte der Kryptologie, die Kryptografie und die Kryptoanalyse. Ohne Kryptoanalyse können Sie Kryptografie nicht bewerten und verstehen, da Sie ohne kritische Betrachtung von Verschlüsselungsverfahren gar nicht wüssten, wie gut ein solches Verfahren überhaupt ist.

Einsatzgebiete der Kryptografie Die Einsatzgebiete der Kryptografie sind zahlreich. Hier einige Beispiele: • Verschlüsselung von Browsing-Aktivitäten und Downloads (HTTPS, SFTP, . . . ) • Schutz von Integrität und Vertraulichkeit im Rahmen von eCommerce und Online-Banking • E-Mail-Verschlüsselung und Signatur von E-Mails • Verschlüsselung von Audio- und Videoübertragungen • Verschlüsselung von lokalen Dateien • Verschlüsselung des Datenverkehrs zwischen Liegenschaften eines Unternehmens, um Wirtschaftsspionage zu erschweren

Kryptografie ist ein sogenanntes Dual-use Good. Es kann für „gutartige“ Zwecke verwendet und für „bösartige“ Zwecke missbraucht werden. Hier einige Beispiele für bösartige Einsatzgebiete der Kryptografie: • Verschlüsselung von Daten auf einer Festplatte durch einen Erpressungstrojaner. • Verschlüsselung des E-Mail-Verkehrs eines Terroristen zum Schutz vor einem Lauschangriff. Basierend auf diesen Szenarien stellen sich Fragen wie diese: Sollte Kryptografie nicht einfach verboten werden, damit Terroristen sie nicht missbrauchen, um Anschläge zu planen? Tatsächlich gibt es politische Bestrebungen in verschiedenen Ländern dieser Welt, um Kryptografie entweder zu verbieten oder ihren Einsatz zu limitieren. Dabei geht es insbesondere um den bösartigen Einsatz der Kryptografie.

4.2 Grundlegende Begriffe

109

Die Unterscheidung zwischen „gutartig“ und „bösartig“ hängt hierbei maßgeblich vom Betrachter ab. Bei Kriegsparteien dürfte die jeweils andere Seite wohl unter den Bereich „bösartige“, die eigene Seite unter den Bereich „gutartige“ Verwendung der Kryptografie fallen. Darüber hinaus dürfte ein Verbot von Kryptografie bei Angreifern mit ernsten Absichten nur wenig bezwecken, da die Verwendung von Kryptografie nur sehr begrenzt kontrolliert werden kann, insbesondere bei sicherheitsaffinen Benutzern.

Exkurs: Crypto Wars? Laut Wikipedia handelt es sich bei Crypto Wars um an unofficial name for the U.S. and allied governments’ attempts to limit the public’s and foreign nations’ access to cryptography strong enough to resist decryption by national intelligence agencies (especially USA’s NSA). Dieser Satz kann mittlerweile sicherlich nicht mehr ausschließlich auf die USA und ihre Verbündeten beschränkt werden. Crypto Wars gibt es weltweit, etwa auch in China. Der erste bekannte Crypto War fand 1975 zwischen den beiden Kryptologen Diffie und Hellman auf der einen und dem National Buero of Standards (NBS, jetzt NIST) sowie der NSA auf der anderen Seite statt. Dabei ging es um die Schlüssellänge von DES, die Diffie und Hellman als zu kurz erachteten, sowie später um die Veröffentlichung des Diffie-Hellman-Schlüsselaustauschverfahrens [9]. Als Leseempfehlung für das Thema Crypto Wars sei auf eine Publikation von Baranetsky [3] sowie auf einen Vortrag von Opsahl mit dem Titel Crypto Wars Part II – The Empires Strike Back verwiesen, der im Rahmen des Chaos Communication Congress 2015 (32C3) stattfand. Dieser Vortrag ist kostenfrei unter der Adresse https://media.ccc.de/b/congress/2015 abrufbar.

4.2

Grundlegende Begriffe

Zunächst müssen einige Grundbegriffe betrachtet werden. Diesen Abschnitt können Sie optional überspringen, und im späteren Verlauf des Kapitels immer dann hierhin zurückblättern, wenn Ihnen einer der Begriffe unklar erscheint.

4.2.1

Verschlüsselung und Entschlüsselung als Abbildungen

Es gibt eine Menge aller Klartexte M und eine Menge aller Chiffretexte C. Eine geheime Nachricht m ∈ M wird bei einer Verschlüsselung in eine chiffrierte Nachricht c ∈ C überführt: f : M → C, m ∈ M, c ∈ C. Bei der Entschlüsselung hingegen wird die Umkehrfunktion benötigt: f −1 : C → M, c ∈ C, m ∈ M.

110

4 Einführung in die Kryptografie

Das heißt, f muss eindeutig umkehrbar sein (bijektiv, s. Box), sodass zu einem gegebenen Chiffretext der ursprüngliche Klartext zugeordnet wird, c = f (f −1 (c)) und m = f −1 (f (m)). Es gilt |C| = |M|.

Exkurs: surjektive, injektive und bijektive Abbildungen Gegenstand der Betrachtung ist eine Abbildung f : A → B, das heißt eine Abbildung, die einem Element einer Menge A (Definitionsbereich) ein Element der Menge B (Wertebereich) zuweist. f ist surjektiv, wenn y = f (x) für jedes y ∈ B mindestens eine Lösung x ∈ A besitzt, wenn also ∀y ∈ B gilt ∃ x ∈ A : y = f (x). f ist injektiv, wenn y = f (x) für jedes y ∈ B kein oder genau eine x ∈ A besitzt, wenn also ∀x1 , x2 ∈ A : f (x1 ) = f (x2 ) ⇒ x1 = x2 . f heißt bijektiv, falls f injektiv und surjektiv ist.

4.2.2

Kryptografische Schlüssel

Kryptografische Algorithmen sind in der Regel publiziert (mit wenigen Ausnahmen, etwa aus dem Bereich der geheimen Datenverarbeitung1 ). Mit Kenntnis eines Algorithmus wäre somit jede Ver- und Entschlüsselung von Nachrichten möglich. Daraus ergibt sich die Notwendigkeit einer geheimen Zusatzinformation, dem kryptografischen Schlüssel, der für Ver- und Entschlüsselung verwendet wird.  Prinzip von Kerckhoffs Das Prinzip von Kerckhoffs besagt, dass die Sicherheit eines kryptografischen Algorithmus’ nicht im Geheimhalten des Algorithmus, sondern nur im Geheimhalten des Schlüssels liegen sollte. Durch Befolgung des Prinzips werden Analysen (Bewertungen und sich daraus ergebene Verbesserungen) von Algorithmen durch die wissenschaftliche Community möglich. Außerdem ist es extrem schwierig, einen Algorithmus auf Dauer und bei wechselnden Personenkreisen (Mitarbeiter kündigen, neue werden eingestellt) tatsächlich geheim zu halten. Algorithmen müssen oft durch verschiedene Bündnispartner/Unternehmen implementiert werden, womit sich die Kenntnis des Algorithmus verteilt. Die Algorithmen A5 (anonymer Hinweis) und Comp128 (Reverse Engineering) konnten beispielsweise nicht geheim gehalten werden [5]. Außerdem gelten Algorithmen, die nicht durch möglichst viele anerkannte Wissenschaftler analysiert wurden, als unsicher. Aus diesem Grund werden auch geheime Algorithmen eher als unsicher betrachtet. 1 Der Libelle-Algorithmus, https://de.wikipedia.org/wiki/Libelle_(Kryptografie), ist beispielsweise vom BSI für den Schutz von Verschlusssachen (VS) der Sicherheitsstufe „streng geheim“ zugelassen.

4.2 Grundlegende Begriffe

111

Der kryptografische Schlüssel k wird aus einer Menge möglicher Schlüssel K selektiert. Er wird für Ver- und Entschlüsselung neben c und m benötigt: Verschlüsselung Entschlüsselung

c = f (k, m) = fk (m) m=f

−1

(k, c) =

fk−1 (c)

(4.1) (4.2)

Sie werden bei der Auseinandersetzung mit asymmetrischer Kryptografie sehen, dass für die Ver- und Entschlüsselung nicht notwendigerweise derselbe Schlüssel verwendet werden muss.

Exkurs: Benutzergemeinde Spitz et al. verweisen auf das Szenario der Benutzergemeinde [26]. Dabei gibt es eine Gruppe mit N Teilnehmern. Es soll dabei je eine mit einem separaten Schlüssel gesicherte Kommunikation zwischen allen Teilnehmern möglich sein. Damit stellt sich die Frage nach der Anzahl benötigter Schlüssel. Tatsächlich werden für diesen   Fall N2 = N ·(N2 −1) Schlüssel benötigt [26].

4.2.3

Kryptosysteme

Nachdem Sie nun kryptografische Schlüssel kennen, können Sie die grundlegende Struktur kryptografischer Verfahren verstehen. Ein Kryptosystem ist gemäß Bishop [6] ein 5-erTupel: (E, D, M, K, C), mit M (Menge der Klartexte), K (Menge der Schlüssel), C (Menge der Chiffretexte), E : M × K → C (die Menge der Verschlüsselungsfunktionen) und D : C × K → M (die Menge der Entschlüsselungsfunktionen).

4.2.4

Symmetrische und Asymmetrische Kryptografie

Es gibt zwei Möglichkeiten für die Verwendung von Schlüsseln: Symmetrische Algorithmen: Sie verwenden zum Verschlüsseln und Entschlüsseln denselben Schlüssel k. Die (je nach Anzahl der Teilnehmer sehr vielen) Schlüssel müssen geheim gehalten werden. Asymmetrische Algorithmen: Sie verwenden zum Verschlüsseln einen öffentlichen Schlüssel (engl. Public Key) kpub und zum Entschlüsseln einen zugehörigen privaten Schlüssel (engl. Private Key) kpriv . Nur die privaten Schlüssel müssen geheim gehalten werden. Öffentliche Schlüssel können in Datenbanken/Verzeichnissen abgelegt werden. Entsprechend müssen die Funktionen zur Ver- und Entschlüsselung mit dem jeweiligen Schlüssel arbeiten: c = E(kpub , m) = Epub (m) und m = D(kpriv , c) = Dpriv (m),

112

4 Einführung in die Kryptografie

wobei E die Funktion zum Verschlüsseln (engl. Encrypt) und D die Funktion zum Entschlüsseln (engl. Decrypt) darstellen. Benötigt werden N Schlüsselpaare (kpub , kpriv ) für N Teilnehmer.

4.2.5

Grundlegendes Angreifermodell

Im Laufe des Buches wird immer wieder von folgendem Angreifermodell die Rede sein. Hierbei nutzen Alice und Bob die Kryptografie für eine sichere Kommunikation zwischen ihnen und Mallory wird versuchen, sie entweder daran zu hindern oder ihre Geheimnisse in Erfahrung zu bringen. Hierbei ist zu beachten, dass die Namen Alice, Bob und Mallory sowie einige weitere Namen, standardmäßig in der IT-Sicherheitsliteratur verwendet werden (Abb. 4.1). Ein Kryptoanalytiker geht davon aus, dass Mallory folgende Komponenten des Kryptosystems in jedem Fall kennt: D und E. Es ergeben sich dadurch unter anderem folgende Angriffe [11]: • Ciphertext-only-Angriff: Der Angreifer kennt einzelne Chiffretexte. Er versucht, zugehörige Klartexte beziehungsweise zunächst den verwendeten Schlüssel zu finden. • Known-plaintext-Angriff: Der Angreifer kennt einige Chiffretexte und zugehörige Klartexte. Er versucht den zugehörigen Schlüssel zu finden. • Chosen-plaintext-Angriff: Der Angreifer kann einige Klartexte selbst wählen und verschlüsseln lassen (etwa durch unbemerktes Unterschieben der Klartexte an Alice). Er erhält die zugehörigen Chiffretexte und möchte k finden. • Chosen-ciphertext-and-plaintext-Angriff:2 Der Angreifer kann Klartext verschlüsseln und erhält für diese Daten den Chiffretext. Sowohl Klartext als auch Chiffretext kann der Angreifer dabei selbst wählen. Außerdem kann der Angreifer Chiffretext entschlüsseln und erhält den zugehörigen Klartext. Er sucht den verwendeten Schlüssel. Weitere Angriffe existieren, sind aber im Rahmen dieses einführenden Kapitels nicht relevant.

Abb. 4.1 Grundlegendes Angreifermodell mit den typischen Mitspielern

2 Eigentlich heißt dieser Angriff Chosen-ciphertext-Angriff, doch weisen Ferguson et al. darauf hin,

dass die oben genannte Bezeichnung passender ist [11].

4.3 Historische Verfahren

4.3

113

Historische Verfahren

Historische Chiffren sind insbesondere monoalphabetische Chiffren. Solche Chiffren verwenden nur ein einziges Schlüsselalphabet zur Ver- und Entschlüsselung. Polyalphabetische Chiffren können ebenfalls zu den historischen Chiffren gezählt werden, verwenden allerdings mehrere Schlüsselalphabete. Im Folgenden werden selektierte historische Verfahren betrachtet.

4.3.1

Transpositionschiffre

Eine einfache Variante einer monoalphabetischen Chiffre und zugleich die älteste bekannte militärische Chiffre [15] ist die Skytale: Sender und Empfänger benötigen einen Stab gleichen Durchmessers. Sie wickeln ein Band aus Papyrus oder Leder um diesen Stab [15]; und zwar so, dass das Band sich nicht überlappt und keine freie Fläche zwischen dem Band entsteht. Der Sender beschreibt das Band zeilenweise. Anschließend wird das Band vom Stab entfernt und die darauf enthaltenen Buchstaben erscheinen unsortiert. Der Empfänger nimmt das Band entgegen und wickelt es auf die zuvor beschriebene Weise auf einen gleichen Stab. Somit wird auch dem Empfänger die geheime Nachricht ersichtlich. Es handelt sich bei der Skytale um eine Transpositionschiffre (oder: Permutationschiffre): Die Symbole des Klartexts werden verschoben, um den Chiffretext zu erzeugen. Der für eine Transpositionschiffre verwendete Schlüssel ist eine Permutationsfunktion, die Auftrittswahrscheinlichkeit von Klartextbuchstaben bleibt daher unverändert und Symbole des Klartexts werden nicht durch andere Symbole ersetzt [6]. Aus „KATZE“ könnte beispielsweise „EZKTA“ werden, jedoch niemals „Q9$i%“.

4.3.2

Die Caesar-Chiffre

Bei Verschiebechiffren werden die Zeichen des Klartexts zyklisch verschoben. Eine äußerst bekannte Variante solcher Verschiebechiffren ist die monoalphabetische und einfach zu verstehende Caesar-Chiffre. Sie wurde nach Julius Caesar benannt, der diese Chiffre tatsächlich angewandt haben soll. Bei der Caesar-Chiffre werden Texte des lateinischen Alphabets um einen Wert k verschoben, um zu verschlüsseln.3 Eine Verschiebung um −k beziehungsweise 26 − k

3 Falls k = 13 ist, nennt man diese Chiffre auch ROT13.

114

4 Einführung in die Kryptografie

Abb. 4.2 Caesar-Chiffe mit k = 3

dechiffriert. Bei k = 3 würde aus ‘A’ beispielsweise ‘D’ werden (Abb. 4.2). Die Ver- und Entschlüsselungsfunktionen können mithilfe modularer Arithmetik beschrieben werden: • Verschlüsseln des Zeichens Z: Zc = (Zm + k) mod 26 • Entschlüsseln des Zeichens Z: Zm = (Zc − k) mod 26 Es gibt für die Caesar-Chiffre nur |Σ| mögliche Schlüssel für das Alphabet Σ. Beim lateinischen Alphabet gibt es folglich nur 26 mögliche Schlüssel (25 sinnvolle und k ∈ [0, 25]). Bei nur 26 möglichen Schlüsseln ist ein Angriff auf einen mit dem Caesar-Verfahren verschlüsselten Chiffretext daher recht einfach und durch Ausprobieren möglich. Die Caesar-Chiffre kann als Kryptosystem (E, D, M, K, C) wie folgt dargestellt werden [6]: M = {alle Sequenzen lateinischer Buchstaben} C=M K = {i | i ∈ Z, 0 ≤ i ≤ 25} E = {Ek | k ∈ K, ∀m ∈ M, Ek (m) = (m + k) mod 26} D = {Dk | k ∈ K, ∀c ∈ C, Dk (c) = (26 + c − k) mod 26}

Einschub: Modulare Arithmetik Für a, b ∈ Z, m ∈ N∗ gilt: a ≡ b mod m, wenn m die Zahl b − a teilt [12]. Oder anders formuliert: Wenn die beiden Divisionsreste 0 ≤ r1 , r2 ≤ m − 1 bei Berechnung von a = q1 m + r1 und b = q2 m + r2 mit q1 , q2 ∈ Z gleich sind (r1 = r2 ), dann gilt a ≡ b mod m [12]. Wenn für der Caesar-Chiffre gesagt wird, dass Zc = (Zm + k) mod 26 ist, dann bedeutet dies folglich, dass Zc der Rest r aus der Rechnung (Zm + k) = gm + r, also Zc = r = (Zm + k) − gm ist.

4.3 Historische Verfahren Tab. 4.1 Beispielanwendung der Vigenère-Chiffre

4.3.3

115

mi

ki

ci

H A L L O

A B A B A

H B L M O

Die Vigenère-Chiffre

Im Gegensatz zur Caesar-Chiffre hat eine sogenannte polyalphabetische Chiffre nun allerdings mehr als nur einen angewandten Schlüssel. Die Vigenère-Chiffre ist eine solche polyalphabetische Chiffre und wurde 1585 von Blaise de Vigenère entwickelt. Sie wurde erst Mitte des 19. Jahrhunderts gebrochen. Die Vigenère-Chiffre ist eine verbesserte Caesar-Chiffre. Statt einem k ∈ K wird dabei eine Folge k0 , . . . , kn−1 von n Schlüsseln mit ki ∈ K, 0 ≤ i ≤ n − 1 verwendet. Diese Schlüssel werden zyklisch angewandt. Die Nachricht M besteht aus m0 . . . mn−1 mit mi ∈ Z, 0 ≤ mi ≤ 25 und der Chiffretext C besteht aus c0 . . . cn−1 mit ci ∈ Z, 0 ≤ ci ≤ 25. Die Verschlüsselungsfunktion der Vigenère-Chiffre ist dabei sehr ähnlich zu der der Caesar-Chiffre, verwendet allerdings statt k jeweils ein ki . Selbiges gilt für die Entschlüsselungsfunktion. • Verschlüsselung von mi : ci = E(mi , ki ) = (mi + ki ) mod 26 • Entschlüsselung von ci : mi = D(ci , ki ) = (ci − ki ) mod 26. Wenn die Länge des Schlüssels kürzer der Länge des Klartextes ist, dann werden die Schlüssel so angewandt, dass sie zyklisch durchlaufen werden. Bei n Schlüsseln wäre ki entsprechend ki mod n . Beispiel. Es soll die Nachricht „HALLO“ mit dem Schlüssel „AB“ chiffriert werden. Berechnet werden müssen dazu (Tab. 4.1): Somit ergibt sich der Chiffretext „HBLMO“.

4.3.4

Die Vernam-Chiffre (One-Time-Pad)

Als letztes historisches Verfahren wird im Folgenden das 1917 eingeführte VernamChiffrierverfahren betrachtet. Diese Chiffre findet sich (in ähnlicher Form) auch auf modernen Computern. Wenn das Vernam-Verfahren mit echten Zufallszahlen arbeitet (diese also in keiner Weise bestimmbar sind), wird das Verfahren auch als One-Time-Pad bezeichnet und bietet perfekte Sicherheit.

116

4 Einführung in die Kryptografie

One-Time-Pads funktionieren dennoch erstaunlich einfach. Zunächst erzeugt der Anwender des One-Time-Pads einen Schlüssel, mit |K| ≥ |M|. Im Gegensatz zur VigenèreChiffre darf der Schlüssel also keinesfalls kürzer als die zu verschlüsselnde Nachricht sein. Die Zeichen in K müssen zufällig gewählt sein. Sowohl Sender als auch Empfänger der Nachricht kennen K. Zur Gewährung der Sicherheit muss nach Verwendung (eines Teils) von K sowohl Sender als auch Empfänger der Nachricht (den verwendeten Teil von) K zerstören. Weiterhin gilt das One-Time-Pad nur dann als perfekt sicher, wenn Mallory keinen Zugriff auf K erlangen kann und K nicht mehrfach verwendet wird. Die Ver- und Entschlüsselungsfunktionen arbeiten ähnlich dem bekannten Schema. Zeichenweise (m ∈ M, k ∈ K, c ∈ C) funktionieren die Funktionen wie folgt: • Verschlüsselung: ci = mi + ki mod 26 • Entschlüsselung: mi = ci − ki mod 26. Bei bitweisen Operationen am Computer lässt sich das One-Time-Pad hingegen mit dem XOR-Operator (⊕ beziehungsweise in den meisten Programmiersprachen der ˆ-Operator) realisieren: • Verschlüsselung: ci = mi ⊕ ki • Entschlüsselung: mi = ci ⊕ ki . Jede Schlüsselsequenz ist gleich wahrscheinlich, womit jede Chiffretextsequenz gleich wahrscheinlich wird. Allerdings darf eine Schlüsselsequenz auf keinen Fall mehrfach verwendet werden.

4.4

Kryptoanalyse für historische Chiffren

4.4.1

Skytale-Chiffre

Die Kryptoanalyse der Skytale gestaltet sich trivial und benötigt nur einen Zylinder und die abgefangene Nachricht C: [. . . ] wrap the strip of parchment around a cone and slide it up and down until sense appears; the diameter of the cone at that point is the diameter of the skytale [15].

4.4.2

Caesar-Chiffre

Wie Sie vielleicht schon ahnen, lässt sich eine Verschiebechiffre sehr einfach brechen, indem man alle möglichen Werte für k ausprobiert. Ein Ausprobieren aller möglichen Schlüssel wird auch als Brute-Force-Angriff bezeichnet.

4.4 Kryptoanalyse für historische Chiffren

117

Es gibt jedoch auch eine effizientere Möglichkeit, eine Kryptoanalyse bei einem derartigen Verfahren durchzuführen. Kennen Sie vielleicht noch das Glücksrad? Beim Glücksrad geht es darum, durch Raten von Buchstaben eine Lösung für ein verdecktes Wort zu finden. Die Buchstaben des verdeckten Worts wurden mit jedem korrekt geratenen Buchstaben weiter aufgedeckt. Zu manchen Zeiten im Spiel konnten die Spieler eine Kombination aus einem Vokal und fünf Konsonanten wählen, um einige der verdeckten Buchstaben selektieren zu lassen. So wählten Spieler oft die Buchstaben „ERNSTL“ aus.4 Die Auswahl „ERNSTL“ der Glücksrad-Spieler war unter diesen Bedingungen gut, kommt der Buchstabe E doch am häufigsten in deutschen Texten vor (17,4 %), gefolgt von N (9,8 %), I (7,6 %, nicht in „ERNSTL“ enthalten, da nur 1 Vokal erlaubt war), S (7,3 %) und R (7,0 %) [31]. Der duchschnittliche Buchstabe tritt mit einer Wahrscheinlichkeit von 3,7 % auf. Am seltensten tritt Q auf (0,02 %). Umlaute wurden als AE, OE, UE und ß als eigenes Zeichen (0,3 %) gezählt [31]. k kann nun bestimmt werden, indem angenommen wird, dass k die Differenz zwischen dem am häufigsten vorkommenden Buchstaben des Chiffretexts zum Buchstaben E ist. Beispiel einer Kryptoanalyse

Es soll versucht werden, k für den Chiffretext BJQHM JNS XHMTJSJW YFL zu finden. Zunächst muss herausgefunden werden, welcher Buchstabe am häufigsten auftritt, indem die Häufigkeitsverteilung analysiert wird (dies ist bei längeren Texten besonders zielführend): B:1 F:1 H:2 J:4 L:1 M:2 N:1 Q:1 S:2 T:1 W:1 X:1 Y:1 Offensichtlich tritt J am häufigsten auf. Nun kann die Stelle, die E im Alphabet einnimmt, von der Stelle subtrahiert werden, die J im Alphabet einnimmt. Somit ergibt sich k = ‘J’ (9) - ‘E’ (4) = 5. Wenn dieser Versuch erfolgreich war, dann kann mit k = 5 eine Entschlüsselung des Chiffretexts durchgeführt werden: $ echo ’BJQHM JNS XHMTJSJW YFL’ | caesar $((26-5)) WELCH EIN SCHOENER TAG Da im vorherigen Beispiel ein plausibler Klartext erzeugt wurde, wurde mit hoher Wahrscheinlichkeit der richtige Wert für k und somit der korrekte Klartext gefunden. Tatsächlich können theoretisch mehrere k zu plausiblen Klartexten führen. Mehr zu diesem Sonderfall erfahren Sie im Abschn. 4.7.6. Sollte das korrekte k auf diese Weise nicht gefunden werden, kann angenommen werden, dass das Zeichen, das am zweit- oder dritthäufigsten vorkommt, das E ist, oder der Kryptoanalyst vom falschen Alphabet ausging.

4 Diverse Beispielvideos für das Glücksrad finden sich auf Videoplattformen im Internet und können diese Vorgehen illustrieren.

118

4.4.3

4 Einführung in die Kryptografie

Kryptoanalyse der Vigenère-Chiffre

Für die Kryptoanalyse der Vigenère-Chiffre ist zu beachten, dass es 26n (n ist dabei die Anzahl der Elemente von K, also die Schlüssellänge) mögliche Schlüsselperioden gibt. Es sind dabei zwei Fälle zu unterscheiden: 1. Die Schlüssellänge n ist bekannt: Da k periodisch angewandt wird, werden alle Buchstaben, die zueinander den Abstand n (Schlüssellänge) haben, mit demselben ki verschlüsselt. Für jedes Element von K kann somit die bereits erläuterte Kryptoanalyse durchgeführt werden, die für die Caesar-Chiffre verwendet wird. Allerdings muss hierbei der Chiffretext länger als bei der Caesar-Chiffre sein. Sonst können keine brauchbaren Häufigkeiten bestimmt werden. 2. n ist unbekannt: In diesem Fall ist zunächst die Anwendung des Kasiski-Tests oder des Friedman-Angriffs notwendig. Diese beiden Verfahren können n ermitteln. Anschließend wird wie im Fall 1 verfahren.

4.4.3.1 Vigenère-Kryptoanalyse mit dem Kasiski-Test Beim Kasiski-Test wird versucht, zunächst die Schlüssellänge n zu ermitteln. In einem Text kommen häufig gleiche Wörter vor. Beim Verschlüsseln der Texte aus diesem Kapitel wären das etwa Wörter wie Schlüssel, Verschlüsselung oder Kryptoanalyse. Im Normalfall werden diese Wörter mit unterschiedlichen Elementen von K verschlüsselt: Klartext : B A U M Schlüssel: A B C A

U N D B C A

B A U M B C A B

Es kann allerdings passieren, dass aufgrund günstiger Wortabstände und passender Schlüssellänge dasselbe Wort mit denselben Elementen von K verschlüsselt wird: Klartext : B A U M Schlüssel: A B C A

A N B C

B A U M A B C A

Im Beispiel wird „BAUM“ jeweils mit „ABCA“ verschlüsselt, was zum gleichen Chiffretext führt. Der Abstand zwischen den Mustern muss somit einem Vielfachen von n (=Schlüssellänge) entsprechen. Die Distanz zwischen den gleichen Chiffretexten sind sechs Symbole und somit muss n|6 (n teilt 6, das heißt es gibt ein x für das gilt: n · x = 6) gelten. Ein Kryptoanalyst kann nun also davon ausgehen, dass n|6, doch woher weiß er, welches n genau verwendet wurde? Um n zu bestimmen, wird eine Primfaktorzerlegung von n durchgeführt (6 = 2 · 3). Weitere Bestandteile des Chiffretextes werden auf potenziell mit gleichem Teilschlüssel verschlüsselte Wörter untersucht. Beispiel. Es ergeben sich die weitere Distanzen 12 und 15, die erneut einer Primfaktorzerlegung unterzogen werden (12 = 2 · 2 · 3 und 15 = 3 · 5). n muss hier ein gemeinsamer Teiler sein (hier: n = 3).

4.4 Kryptoanalyse für historische Chiffren

119

 Euklidischer Algorithmus Im vorherigen Beispiel wurde ein sehr geringer Abstand für die Worte gewählt, die gleich verschlüsselt wurden. Es ist allerdings denkbar, dass derlei Abstände sehr groß ausfallen. Statt 6, 12 und 15 könnten etwa die Abstände 789 und 456 vorliegen. Der euklidische Algorithmus kann den größten gemeinsamen Teiler (ggT) solcher Zahlen liefern. Vorgehen: Die größere Zahl muss durch die kleinere Zahl geteilt werden. Der Rest wird beibehalten und durch ihn wird geteilt, bis der Rest 0 ergibt. Der letzte Divisor ist zugleich der ggT. Beispiel. Berechnung des ggT(789, 456): 789 : 456 = 1, Rest : 333 456 : 333 = 1, Rest : 123 333 : 123 = 2, Rest : 87 123 : 87 = 1, Rest : 36 87 : 36 = 2, Rest : 15 36 : 15 = 2, Rest : 6 15 : 6 = 2, Rest : 3 6 : 3 = 2, Rest : 0 Somit ergibt sich: ggT(789, 456) = 3. Falls der ggT von mehr als zwei Zahlen berechnet werden soll, ist die Mehrfachausführung des euklidischen Algorithmus möglich. ggT(a, b, c) kann wie folgt berechnet werden: ggT(a, ggT(b, c)). In N ist ggT assoziativ, das heißt ggT(a, b, c) = ggT(a, ggT(b, c)) = ggT(ggT(a, b), c).

4.4.3.2 Vigenère-Kryptoanalyse mit dem Friedman-Angriff Ein alternativer Kryptoanalyseansatz wurde von Friedman entwickelt und nach ihm benannt. Ziel ist (wie beim Kasiski-Test) die Bestimmung der Schlüssellänge , ausgehend von einem Chiffretext der Länge n. Diese kann über die folgende Formel berechnet werden [5]5 : =

0, 0377n (n − 1) · I − 0, 0385n + 0, 0762

5 In Beutelspacher et al. [5] findet sich eine exzellente Beschreibung der Herleitung dieser Formel.

120

4 Einführung in die Kryptografie

Die Werte 0,0377 und 0,0385 hängen von den charakteristischen Eigenschaften der verwendeten Sprache ab und sind in diesem Fall die Werte für deutsche Sprache und zufällige Buchstabenfolgen. Der Friedman’sche Koinzidenzindex I berechnet sich wie folgt [5]: 26 I=

− 1) n(n − 1)

i=1 ni (ni

ni gibt an, wie häufig der Buchstabe i im Geheimtext vorkommt. Mit Kenntnis der Ausgangssprache sowie n und dem Auszählen der Häufigkeiten der Symbole lässt sich somit  bestimmen.

4.4.4

Kryptoanalyse der Vernam-Chiffre

Bei der Vernam-Chiffre sollte die Schlüsselsequenz auf keinen Fall mehrfach verwendet werden. Falls K nämlich mehrfach verwendet wird und zwei Chiffretexte C1 und C2 abgefangen werden können, weiß der Angreifer bereits etwas über diese beiden Nachrichten: Wenn sie nicht gleich sind, sind auch ihre jeweiligen Klartexte M1 und M2 nicht gleich. Bei perfekter Sicherheit (Einfachverwendung von K) ist ein derartiger Rückschluss nicht möglich. Weiterhin kann der Angreifer mit zwei abgefangenen Chiffretexten wie folgt vorgehen: Angenommen, C1 und C2 wurden beide mit denselben Werten aus K verschlüsselt, dann gilt: C1 ⊕ C 2 = M1 ⊕ K ⊕ M 2 ⊕ K = M1 ⊕ M 2 .

(4.3)

Klartexte unterliegen im Gegensatz zu Chiffretexten statistischen Eigenschaften der Ausgangssprache. Somit sind mit der Umformung in 4.3 statistische Angriffe denkbar, wenn K mehrfach verwendet wurde.

4.4.5

Weitere Anmerkungen zu historischen Chiffren

Historische Chiffren wurden insbesondere in Kriegszeiten entwickelt. Vermutlich haben Sie bereits von der Enigma gehört, die im Zweiten Weltkrieg insbesondere von den Deutschen verwendet wurde. Dieses System wurde mehrfach verbessert. Das EnigmaNachfolgesystem Schlüsselgerät 41 (auch als Hitlermühle bekannt; erbaut von der Firma Wanderer aus Chemnitz) ist bereits weniger bekannt. Eine Auseinandersetzung mit diesen Chiffriermaschinen würde den Umfang dieses Kapitels allerdings sprengen. Eine detaillierte Auseinandersetzung mit der Geschichte der Kryptografie finden Sie in [15].

4.5 Stromchiffren und Zufallszahlengeneratoren

4.5

121

Stromchiffren und Zufallszahlengeneratoren

Bei Stromchiffren (Abb. 4.3) werden alle Zeichen des Klartexts einzeln und nacheinander verschlüsselt (beispielsweise ⊕ mit einem Schlüssel). Hierzu wird ein Schlüsselstrom erzeugt, sodass die Bits m1 . . . mn mit den Schlüsselbits k1 . . . kn chiffriert werden, also E = ek1 (m1 )ek2 (m2 ) . . . ekn (mn ). Ein Beispiel einer Stromchiffre ist das VernamChiffrierverfahren. Zur Generierung eines solchen Schlüsselstroms müssen Wege gefunden werden, um möglichst zufällige Schlüsselbits zu erzeugen. Dies kann entweder auf dem Computer geschehen oder durch ein externes System erfolgen, dass die Zufallsbits an den Computer übergibt. Im Folgenden wird zunächst besprochen, wie Zufallsbits erzeugt werden können. Anschließend werden die unsicheren Algorithmen RC4 und A5/1 beschrieben.

4.5.1

Zufallszahlengeneratoren (PRNG)

Ein System, das Zufallszahlen generiert, ist ein Zufallszahlengenerator (engl. Random Number Generator, kurz RNG). Wenn die Zahlen nicht echt zufällig sind, sondern mit künstlichen Mitteln nur möglichst nah am echtem Zufall sind, so spricht man auch von einem Pseudozufallszahlengenerator (engl. Pseudo Random Number Generator, PRNG). Die Sicherheit von Stromchiffren beruht fast ausschließlich auf dem PRNG: Wenn der PRNG nur Nullen produziert, dann ist C = M und wenn der PRNG-Output echt zufällig ist, ergäbe dies ein One-Time-Pad [24]. Schneier hält diesbezüglich fest: The reality of stream cipher security lies somewhere between the simple XOR and the onetime pad. The keystream generator generates a bit stream that looks random, but is actually a deterministic stream that can be flawlessly reproduced at decryption time. [24]

Ein PRNG generiert möglichst zufällige Zahlen, die für die Schlüsselerzeugung verwendet werden können. Das heißt, die durch einen PRNG generierten Werte sollten möglichst nicht vorhersagbar sein. Ein Grundproblem hierbei besteht allerdings in der Tatsache, dass auch ein PRNG durch einen Algorithmus implementiert und damit deterministisch sein muss. Abb. 4.3 Konzept einer Stromchiffre

122

4 Einführung in die Kryptografie

Dieser Algorithmus wird mit einem möglichst zufälligen Wert, dem Seed, initialisiert. Der Seed dient letztlich als Startwert für die Generierung von Zufallszahlen und sollte daher selbst möglichst zufällig sein. Häufig werden für die Generierung des Seed Benutzereingaben verwendet, etwa Tastaturanschläge oder Mausbewegungen und klicke. Leider sind diese Werte durchaus in gewissem Rahmen vorhersagbar und nicht einwandfrei für die Seed-Geneierung nutzbar. Als praktikable Lösung werden daher mehrerer solcher Werte sowie das Timing von bestimmten Hardwareevents (beispielsweise Interrupts) für die Seed-Generierung kombiniert. Beutelspacher et al. nennen das Beurteilungskriterium der Nicht-Vorhersagbarkeit für PRNGs: Ein PRNG erfüllt das Kriterium der Nicht-Vorhersagbarkeit, wenn die Erfolgswahrscheinlichkeit eines effizienten Angreifers, das i-te Bit vorherzusagen, nur unerheblich von 1/2 abweicht [5]. Ferguson et al. weisen zudem darauf hin, dass ein PRNG als kryptografisch „stark“ gilt, wenn ein Angreifer viele der durch den PRNG generierten Daten sehen kann, und die Nicht-Vorhersagbarkeit trotzdem gilt, siehe dazu auch [11]. Unzählige akademische Publikationen adressieren dieses Problem. Bestehende PRNGs werden dabei untersucht, angegriffen und durch bessere PRNGs ersetzt. Hauptaspekt ist oft das Einbeziehen möglichst zufälliger Bits (beispielsweise echtes Rauschen oder Einbeziehen von User-Input), manchmal jedoch auch die Steigerung der PRNGPerformance [16]. Um echte Zufallsbits zu erhalten (nicht bloß „pseudo“-zufällige), gibt es verschiedene Wege. Menezes et al. nennen einige Beispiele in [19]: Hardware-Generatoren (Auswahl): • Mikrofon-Input • Luftwirbel in (alten) Festplatten • Auftreten von Partikeln bei radioaktivem Zerfall Software-Generatoren nutzen folgende (halbwegs zufällige, aber beeinflussbare) Quellen (Auswahl): • • • •

Verwendung der aktuellen Uhrzeit (möglichst genau) Zeitabstand zwischen Tastaturanschlägen Mausbewegungen Statistiken des Betriebssystems (CPU-Auslastung, Netzwerkstatistiken, Füllstände von Puffern)

4.5.2

Der RC4-Algorithmus

RC4 wurde 1987 von Ronals Rivest (RC steht für Ron’s Code) für die Firma RSA Security entwickelt. RC4 wurde geheim gehalten, allerdings 1994 anonym veröffentlicht [26]. Der Algorithmus kommt etwa beim Verschlüsselungsverfahren WEP (siehe Abschn. 8.2.10) in Wireless-Netzwerken zum Einsatz.

4.5 Stromchiffren und Zufallszahlengeneratoren

123

Ein PRNG liefert bei RC4 Zufallsbytes, die mit Klartextbytes via ⊕ verschlüsselt werden. Dieses Verfahren kennen Sie bereits vom One-Time-Pad. Interessant ist bei RC4 daher primär der PRNG. Im Wesentlichen basiert dieser darauf, dass zunächst eine 256 Byte lange Liste permutiert wird (abhängig vom Schlüsselinhalt). Für alle Bytes des Nachrichtenstroms werden zum Chiffrieren Zufallszahlen auf Basis der zuvor permutierten Liste erzeugt. Dabei werden im Wesentlichen zwei der pseudozufälligen Elemente aus der Liste herausgegriffen und summiert. Das Ergebnis e der Summierung wird wiederum als Index für die Liste verwendet, um den Wert des Elements, also Liste[e], herauszugreifen. Dieser Wert ist das Pseudozufallsbyte. Anschließend werden die beiden verwendeten Elemente der Liste erneut vertauscht, sodass mit der modifizierten List der nächste Zufallswert generiert werden kann.

4.5.2.1 Dechiffriererung bei RC4 Für die Entschlüsselung wird, anstelle von M, C als Input für den Algorithmus verwendet. Das beim Verschlüsseln verwendete M ⊕ K wird somit wie folgt einbezogen: C ⊕ K = (M ⊕ K) ⊕ K = M Dabei heben sich also die beiden ⊕K auf, sodass M übrig bleibt. Dadurch, dass Sender und Empfänger dasselbe K verwenden, können zudem dieselben Zufallszahlen generiert werden, was die Entschlüsselung überhaupt erst ermöglicht.

4.5.2.2 Sicherheit von RC4 RC4 kann keine Integrität gewährleisten. Ein im Chiffretext verändertes Bit wird entsprechend auch im Klartext verändert.6 Außerdem konnte gezeigt werden, dass Angreifer einen Teil des Klartext mithilfe des Chiffretexts berechnen können, wenn TLS verwendet wird [2]. RC4 gilt als unsicher. Experten gehen davon aus, dass die NSA RC4 in Echtzeit brechen kann. Außerdem wurde der Einsatz teils durch Standardisierungsgremien für bestimmte Zwecke (etwa TLS [21]) verboten.

4.5.3

Die A5/1- und A5/2-Algorithmen

A5/1 beziehungsweise die abgeschwächte Version A5/2 sind ähnlich aufgebaut wie RC4. Insbesondere unterscheiden sie sich durch ihre Zufallszahlengeneratoren von RC4. A5/1 und A5/2 werden zur Verschlüsselung von GSM (Mobilfunk) eingesetzt, um die Kommunikation zwischen Telefon und Base Station zu verschlüsseln [8] (die restliche 6 Die Gewährleistung von Integrität ist ein generelles Problem symmetrischer Algorithmen. Eingeschränkt trifft dieses Problem auch auf Blockchiffren zu, die allerdings in bestimmten Modi betrieben werden, um dem Problem Herr zu werden, siehe Abschn. 4.6.3.

124

4 Einführung in die Kryptografie

Kommunikationsstrecke bleibt unverschlüsselt).7 Beide Algorithmen wurden ursprünglich geheim gehalten. Kryptoanalysten konnten die Algorithmen allerdings rekonstruieren. Die Neuerung des PRNG bei A5 liegt in der Verwendung sogenannter Schieberegister für die Generierung von Zufallsbits. Dabei handelt es sich um Register der Längen 19, 22 und 23 Bits. Die Register werden mit einem geheimen Schlüssel und der Nummer der aktuellen GSM-Übertragungsframe initialisiert. Bei jedem Takt werden alle oder ein Teil der Register um eine Stelle nach links verschoben8 und aus den in den Registern jeweils links stehenden Bits werden per ⊕ die Zufallsbits generiert. Die nun jeweils freie rechte Seite eines Registers wird wieder aufgefüllt. Das Auffüllen geschieht rekursiv mit Werten jeweils unterschiedlicher Positionen des jeweiligen Registers (erneut werden diese Werte per ⊕ miteinander verrechnet). Pro GSM-Frame (4.615 ms) und Kommunikationsrichtung werden 114 Zufallsbits benötigt.

4.5.3.1 Sicherheit von A5/1 A5 bietet keinen Integritätsschutz und kann mittlerweile in Echtzeit gebrochen werden. Es stellte sich die Frage, ob der Algorithmus mit Intention schlecht konzipiert wurde. An dieser Stelle soll ein Auszug aus der Wikipedia-Seite Aufschluss geben: Der britische Wissenschaftler Ross Anderson vertrat 1994 die Meinung, es sei absichtlich eine schwache Chiffre ausgewählt worden, um den Nachrichtendiensten der NATO das Abhören von Gesprächen zu ermöglichen. Dies wurde später bestätigt.

Ursprünglich wurde eine längere Schlüssellänge für A5/1 vorgesehen (128 Bits). Wie der norwegische Aftenposten berichtete, einigte man sich auf Druck der britischen Regierung (diese wollte eine Schlüssellänge von 48 Bits) auf die Schlüssellänge von 54 Bits: Audestad says that the British were not very interested in having a strong encryption. And after a few years, they protested against the high security level that was proposed. They wanted a key length of 48 bit. We were very surprised. The West Germans protested because they wanted a stronger encryption to prevent spying from East Germany. The compromise was a key length of 64 bit – where the ten last bits were set to zero. The result was an effective key length of 54 bit. [1]

4.6

Blockchiffren

Bei Blockchiffren wird blockweise (das heißt immer n Zeichen pro Durchlauf) verschlüsselt. Es gibt eine Vielzahl an Algorithmen, die in diese Kategorie fallen, etwa:

7 Anm.: Die Nachfolger A5/3 und A5/4 werden ebenfalls für den Mobilfunk eingesetzt und sind

keine Stromchiffren. 8 Dieser Vorgang wird durch sogenannte Taktkontrollbits gesteuert.

4.6 Blockchiffren

• • • • • • • •

125

Data Encryption Standard (DES) Tripple-DES (3DES) LUCIFER LOKI International Data Encryption Algorithm (IDEA) Blowfish Safer Advanced Encryption Standard (AES)

Betrachtet werden zunächst die Algorithmen DES und 3DES. Im Anschluss wird es um AES und Modi von Blockchiffren gehen.

4.6.1

Der Data Encryption Standard (DES)

DES (auch Data Encryption Algorithm, kurz DEA oder DEA-1) war über Jahrzehnte der dominierende Standard für Kryptografie [24]. Der Algorithmus gilt nicht mehr als sicher genug, wird aber noch in vielen Bereichen von Altsystemen eingesetzt. DES wurde insbesondere entwickelt, um einen einheitlichen Verschlüsselungsalgorithmus zu besitzen, anstatt diverse Algorithmen für verschiedene Produkte zu verwenden. Letztlich ist DES ein Industriestandard des National Institut of Standards and Technology (NIST), entwickelt von IBM und beeinflusst von der NSA. Zunächst führte das NIST zwei öffentliche Ausschreibungen durch, bei denen Vorschläge für einen solchen Algorithmus eingereicht werden konnten. Geforderte DesignPrinzipien des NIST waren laut Schneier die folgenden [24]: • Der Algorithmus sollte ein hohes Maß an Sicherheit bieten. • Algorithmus sollte komplett spezifiziert und einfach zu verstehen sein. • Sicherheit vom Algorithmus sollte ausschließlich im Schlüssel liegen (keine „Securityby-Obscurity“). • Verfügbarkeit des Algorithmus für alle potenziellen Anwender. • Anwendbarkeit des Algorithmus im Rahmen diverser Anwendungsfelder. • Die Implementierung des Algorithmus in elektronische Geräte sollte wirtschaftlich sein. • Die Benutzung des Algorithmus sollte effizient sein. • Der Algorithmus sollte validierbar sein. • Es sollte erlaubt sein, den Algorithmus zu exportieren. IBM schlug 1974 einen etwas komplizierten Algorithmus vor, gewann damit allerdings trotzdem die Ausschreibung. Zur Beurteilung des Algorithmus zog das NIST die NSA zu Rate. Die NSA schlug eine modifizierte Version des Algorithmus vor. Die neue Version verwendete 56-bit-Schlüssel statt 128-bit-Schlüssel. Das NIST ließ daraufhin die NSA-

126

4 Einführung in die Kryptografie

Version auf mögliche Hintertüren untersuchen. Trotz Kritik wurde der DES Ende 1976 als nationaler Standard verabschiedet. DES blieb von 1977 bis 2002 der Kryptostandard der USA und einem Großteil der restlichen Welt [9].

Hintergrund zur Historie des DES Weitere Details zur Geschichte und weshalb die NSA es bereute, das NIST bzgl. DES beraten zu haben, finden Sie im Buch von Schneier [24], Kapitel 12.1, Seiten 265–270.

4.6.1.1 DES: Funktionsweise DES verschlüsst Daten in 64-bit-Blöcken (dies entspricht der Größe von M- und CBlöcken) auf symmetrische Weise. Ein DES-Schlüssel ist 64 Bits lang, wovon allerdings jedes achte Bit ein Paritätsbit (siehe Abschn. 2.3.1.3) ist. Es bleiben folglich nur 56 Schlüsselbits übrig. DES verwendet im Prinzip zwei grundlegende kryptografische Techniken: Konfusion und Diffusion. Prinzip der Konfusion: Klartexte weisen die uns bekannten statistischen Eigenschaften auf und ermöglichen erst durch diese eine Vielzahl von Angriffen. Die Konfusion verfolgt das Ziel, derartige statistische Klartext-Eigenschaften (Redundanzen) zu verbergen. Gearbeitet wird mit sich bei jedem Klartextbit ändernden Mechanismen, die Klartextblöcke durch Chiffretextblöcke substituieren. Ein typischer Ansatz ist, dass jedes Klartextbit von mehreren Schlüsselbits abhängig gemacht wird. Prinzip der Diffusion: Diffusion sorgt dafür, dass jede noch so kleine Veränderung in einem Klartext zu einem möglichst unterschiedlichen Chiffrat führt. Dies ist beispielsweise bei der Caesar-Chiffre nicht der Fall: Ein verändertes Klartextzeichen wird nur das entsprechende Zeichen im Chiffrat verändern. Diffusion sorgt hingegen dafür, dass auch eine solch kleine Veränderung zu möglichst großen Veränderungen im Chiffrat führt. Am Beispiel des Prüfsummenalgorithmus’ MD5 lässt sich die Fähigkeit der Diffusion leicht zeigen. Im Folgenden wird nur der erste Buchstabe von ‘k’ auf ‘K’ verändert (betroffen sind hierbei nur wenige Bits der Nachricht), doch ergibt sich daraus eine stark unterschiedliche Prüfsumme: $ md5sum katze 2f57741f6a1ce8ed633395fc4ece1550 $ md5sum Katze a958290d7d801e6a0a0f63c727f86bbe

-

-

4.6 Blockchiffren

127

Abb. 4.4 Ein Feistel-Netzwerk (Abb. aus [20])

Klartext L1

R1

f()

Li+1

Ki

Ri+1 Geheimtext

4.6.1.2 Feistel-Netzwerke Wie gesagt verarbeitet DES den Klartext in Blöcken zu je 64 Bit.9 Zu diesem Zweck kommen sogenannte Feistel-Netzwerke (zumindest in modifizierter Form) zum Einsatz. Ein Feistelnetzwerk arbeitet rundenweise. Es spaltet den Klartext in einen linken und einen rechten Teil auf (Abb. 4.4). Dabei wird der rechte Teil (Ri ) eines Klartextes zum linken Teil (Li+1 ) des Geheimtextes der jeweiligen nächsten Runde. Ri wird außerdem verwendet, um mit einer Verschlüsselungsfunktion, die den Schlüssel als Eingabe bekommt, verrechnet zu werden (Abb. 4.4). Das Ergebnis dieser Verrechnung mit f wird mit der linken Klartextseite per ⊕ verrechnet und zum rechten Teil Ri+1 dieser Runde. Ausgaben einer Runde i dienen dabei als Eingaben für die Runde i + 1. Anders formuliert passiert in einem Feistel-Netzwerk also Folgendes: Für die Verschlüsselung berechnen wir: Li = Ri−1 Ri = Li−1 ⊕ fi (Ri−1 , Ki ) Für die Entschlüsselung wird hingegen Folgendes berechnet: Li−1 = Ri ⊕ fi (Ri−1 , Ki ) Ri−1 = Li

9 Dieser Unterabschnitt basiert auf unserem vergriffenen Titel J. Plötner, S. Wendzel: Praxisbuch Netzwerksicherheit, Galileo Press, 2007, siehe [20].

128

4 Einführung in die Kryptografie

fi ist die Verschlüsselungsfunktion und Ki der Schlüssel der i-ten Runde. Bei n Runden ist (Ln , Rn ) der finale Geheimtext. Bei DES ist n = 16. Für die Entschlüsselung wird allerdings nicht die inverse Funktion fi−1 benötigt. Die Begründung hierfür kennen Sie bereits, denn: M =M ⊕K ⊕K =C⊕K =M Es sei an dieser Stelle erwähnt, dass die Klartextblöcke vor Runde 1 durch eine Eingangspermutation permutiert werden. Eine zugehörige Schlusspermutation macht diesen Vorgang am Ende des Algorithmus wiederum rückgängig. Schneier schreibt, dass diese Funktionen für die Sicherheit von DES irrelevant seien und nur implementierungstechnische Gründe hätten [24].

4.6.1.3 Modifiziertes Feistel-Netzwerk DES verwendet allerdings nicht das ursprüngliche Feistelnetzwerk, sondern eine Modifikation desselben (hervorgehobene Kästchen in Abb. 4.5). Schritt 1 (Expansion): Die Länge von Ri beträgt 32 Bits (das ist die Hälfte des 64-BitBlocks). Im ersten Schritt expandiert f die Länge von Ri auf 48 Bit, da später 48 Bits des Schlüssels verwendet werden und beide Werte mittels ⊕ verrechnet werden. Für die Expansion werden schlicht bestimmte Bits nach einer vorgegebenen Tabelle verdoppelt. Abb. 4.5 Modifiziertes Feistel-Netzwerk bei DES

4.6 Blockchiffren

129

Neben dieser Expansion führt die Funktion an dieser Stelle noch eine zusätzliche Permutation von Ri durch, wobei allerdings nur wenige Bits permutiert werden. In diesem ersten Schritt wird nichts verschlüsselt und es wird keine Sicherheit gewonnen. Das Ergebnis der Expansion wird schließlich mit Ki via ⊕ verrechnet. Schritt 2 (S-Box): Die aus der ⊕-Operation resultierenden 48 Bits werden bei DES durch acht S-Boxen (Substitutions-Boxen) geleitet. Jede dieser S-Boxen verfügt dabei über sechs Eingangs-Bits und vier Ausgangs-Bits („6 × 4-S-Box“). Somit machen die S-Boxen aus den 48 Eingangs-Bits 32 Ausgangs-Bits (Abb. 4.6). Jede der DES-S-Boxen verwendet eine unterschiedliche Tabelle mit je vier Zeilen und 16 Spalten. Von den sechs Eingangs-Bits werden Bits 0 und 5 zur Wahl der Zeile und Bits 1–4 zur Wahl der Spalte verwendet. Der Spaltenwert ist ein 4 Bits langer Wert für den Ausgang der S-Box. Beispiel. Die S-Box erhält die Eingabe „011101“. Dann ist die Zeile 01=1 (=2. Zeile) und die Spalte ist 1110=14 (=15. Zeile). Die Ausgabe wäre nun der 4-Bit-Wert an Position (2, 15) der Tabelle. Die Tabellenwerte werden durch verschiedene mathematische Methoden, bei manchen Algorithmen aber auch einfach mit Zufallswerten, befüllt. Diese Werte sind für den Algorithmus statisch. S-Boxen erhöhen die Sicherheit von kryptografischen Algorithmen, da sie kein lineares Mapping zwischen Ein- und Ausgangsbits verwenden. Schneier verweist darauf, das S-Boxen umso sicherer werden, je größer sie ausgelegt sind, da ihre Größe die Kryptoanalyse erschwert [24]. Schritt 3 (Permutation): Schließlich werden die aus der S-Box resultierenden 32 Bits nach einem vorgegebenen Mapping (simple Tabelle) permutiert. f ist damit abgeschlossen und Li kann mit dem Ergebnis von f mittels ⊕ verknüpft werden. Es bleibt allerdings noch die Frage zu klären: Wie kommen die Bestandteile des Schlüssels (Ki ) zu Stande? Schlüsselerzeugung: Wie bereits erwähnt, werden vom Schlüssel 56 Bits verwendet, die restlichen Bits sind Parity-Bits. Für jede der 16 DES-Runden wird aus dem 56Bit-Schlüssel K ein 48-Bit-Schlüssel Ki generiert. Dabei wird folgende Vorgehensweise eingehalten [24]: Abb. 4.6 S-Boxen bei DES

130

4 Einführung in die Kryptografie

1. Zerlegung des 56-Bit-Schlüssels in zwei Teile zu je 28 Bit. 2. Je nach Runde werden die Teilschlüssel um 1 bis 2 Bits (weiter) verschoben (diese Entscheidung wird anhand einer Tabelle getroffen). 3. Anschließend wird eine Kompressionsfunktion ausgeführt: Sie selektiert 48 der 56 Bits durch Permutation. Diese 48 Bits bilden den Rundenschlüssel Ki . Dadurch werden in jeder Runde unterschiedliche Schlüsselbits verwendet.

4.6.1.4 DES: Angriffe DES ist insbesondere gegen Brute-Force-Angriffe verwundbar. Einige Zahlen: • DES kennt 256 = 72 Brd. mögliche Schlüssel. Brute-Force-Angriffe sind daher möglich. Hier kommt der NSA-Vorschlag für kürzere Schlüssel zum Tragen. • 1998: Die EFF baut den „Deep Crack“-Supercomputer. Er kann mit DES-Crack-Chips 88 Mrd. Schlüssel/s testen. • 1999: Mithilfe von Distributed Computing (100.000 Rechner!) konnten bereits 245 Mrd. Schlüssel/s getestet werden. • 2008: SciEngines GmbH (Erbauer des COPACOBANA-Projekts): 292 Mrd. Schlüssel/s, http://www.copacobana.org/docs.html. • Realistische momentane Crack-Dauer: ca. 20–30 Stunden. DES besitzt verschiedene Schwächen. Es gibt zum einen vier bekannte Schlüssel, für die gilt: EK (EK (M)) = M [22]. Diese Schlüssel werden allerdings einfach nicht verwendet. Zudem gibt es sechs Schlüsselpaare (K1 , K2 ), für die gilt: EK1 (EK2 (M)) = M [22]. Diese Schlüsselpaare werden ebenfalls nicht verwendet. Außerdem sind weitere Probleme bekannt. Letztlich bleibt auch noch einmal zu erwähnen, dass die Schlüssellänge des DES viel zu kurz für heutige Ansprüche ist.

4.6.1.5 Tripple DES Es sei kurz erwähnt, dass es möglich ist, die Sicherheit von DES durch das sogenannte Tripple DES-Verfahren (auch: 3DES) zu verbessern. 3DES ist die dreifache Anwendung von DES in der folgenden Form mit drei Schlüsseln K1 , K2 , K3 (EDE-(Encrypt-DecryptEncrypt)-Verfahren): C = EK1 (DK2 (EK3 (M))) und M = DK1 (EK2 (DK3 (C))) Man erhält somit 3 × 56 = 168 Bits Schlüssellänge. Durch die Charakteristika von DES ergeben sich effektiv allerdings nur 112 Bit [24].

4.6.2

Der Advanced Encryption Standard (AES)

Da DES als unsicher gilt, wurde nach einem Nachfolger für DES gesucht. Diese Suche wurde im Rahmen eines Wettstreits durchgeführt, aus dem schließlich der Advanced Encryption Standard (AES) hervorging. Der Algorithmus, der diesen Wettstreit gewann,

4.6 Blockchiffren

131

hieß eigentlich Rijndael, benannt nach seinen belgischen Entwicklern: Rijmen und Daemen. Bisher sind keine praktisch relevanten Angriffe gegen AES bekannt.

4.6.2.1 AES-Grobübersicht AES lässt sich am einfachsten erklären, wenn es zunächst vom zuvor besprochenen DES unterschieden wird. Grobe Unterschiede sind [5, 22, 26]: • Schlüssellänge: AES verwendet längere Schlüssel (128, 192 oder 256 Bit) statt 56 Bits bei DES. • Blockgröße: AES verwendet 128 Bits (Rijndael auch 192 und 256 Bit) statt 64 Bits DES. • Funktionsweise: Wie DES verwendet AES S-Boxen und eine Schlüsselexpansion, führt Permutationen und Substitutionen durch. AES verwendet kein Feistel-Netzwerk. • Art des Algorithmus: Sowohl AES als auch DES sind symmetrische Algorithmen. • Anzahl der Runden: Statt der 16 Runden des DES verwendet AES 10 (128-BitSchlüssel), 12 (192-Bit-Schlüssel) oder 14 (256-Bit-Schlüssel) Runden. • Betriebsmodi: Auch AES kennt die typischen Betriebsmodi (CBC, CFB etc.). Vorteilhaft ist an AES auch seine hohe Performance, weshalb AES im Bereich von Embedded Systems/Automation zum Einsatz kommt (etwa bei den Funk- und Busprotokollen BACnet, KNX und ZigBee). DES gilt allerdings ebenfalls als performant.

4.6.2.2 Die Kernkonzepte von AES Bei AES erfolgen Permutation und Substitution im Wechsel. Eine Aufteilung von M in eine linke und eine rechte Seite, wie bei DES, gibt es bei AES nicht. Der Klartext wird in eine 4 × 4-Matrix (8 × 16 = 128 Bit) zerlegt und in jeder Runde werden die Daten der Matrix verarbeitet, sodass die finale Ausgabe letztlich C ist. Eine Runde besteht dabei aus den folgenden Funktionen [5, 22]: 1. 2. 3. 4.

SubBytes ShiftRow MixColumn AddRoundKey

Zum Start wird AddRoundKey durchgeführt. In allen Runden außer der letzten werden alle vier Funktionen durchlaufen. In der letzten Runde wird MixColumn durch ein weiteres AddRoundKey ersetzt. Bei SubBytes handelt es sich um eine S-Box (für Konfusion zuständig). Jedes der 16 Bytes der Matrix wird nach einer Ersetzungstabelle durch ein neues ersetzt. Entsprechend verfügt die Tabelle über 256 Bytewerte (für jeden möglichen Byte-Wert).

132

4 Einführung in die Kryptografie

ShiftRow ist für die Durchmischung der Zeilen der Matrix zuständig (Diffusion). MixColumn sorgt schließlich für die Durchmischung der Spalten der Matrix (ebenfalls für Diffusion zuständig) [5, 22]. MixColumn wird in der letzten Runde nicht aufgerufen, weil es für die Verschlüsselung nicht mehr nötig ist. Der Grund: MixColumns und AddRoundKey sind vertauschbar, womit das Ergebnis bereits nach AddRoundKey festehen würde, wenn AddRoundKey zuerst ausgeführt werden würde [22]. AddRoundKey führt ein bitweises ⊕ von Matrix-Elementen und dem Rundenschlüssel durch. Ein Rundenschlüssel ist 4 × 4 Bytes groß (Matrixgröße). AES erzeugt die Rundenschlüssel im Wesentlichen durch die in SubBytes verwendete S-Box, eine byteweise Linksrotation und ⊕-Operationen. Es werden so viele Rundenschlüssel benötigt, wie es Runden gibt. Zusätzlich wird vor der ersten Runde der eigentliche AES-Schlüssel für AddRoundKey verwendet, womit es also bei 10 Runden 11 Anwendungen des (Runden) Schlüssels gibt. Entschlüsselung: Die Entschlüsselung durchläuft – allerdings invertiert und in umgekehrter Reihenfolge – sämtliche Schritte der Verschlüsselung. So muss etwa die S-Box-Tabelle rückwärts angewandt werden.

4.6.3

Blockchiffren-Betriebsmodi

DES, AES und weitere Blockchiffren kennen verschiedene sogenannte Betriebsmodi, von denen die folgenden besonders relevant sind

4.6.3.1 Electronic Codebook (ECB) ECB wird standardmäßig bei DES eingesetzt und verschlüsselt die bekannten (dort 64 Bits großen) Blöcke unabhängig voneinander, das heißt Ci = E(K, Pi ) und Pi = D(K, Ci ). Der letzte Block wird gegebenenfalls aufgefüllt (falls weniger als 64 Bits vorliegen). Eine Veränderung in einem Klartextblock führt zur Veränderung des entsprechenden Chiffreblocks. Gleiche Klartextblöcke resultieren in gleichen Chiffreblöcken. 4.6.3.2 Cipher Block Chaining (CBC) Vorherige Chiffreblöcke beeinflussen hierbei die folgenden Klartextblöcke (sie werden mit diesen durch XOR verrechnet): Ci = E(K, Pi ⊕ Ci−1 ) und: Pi = D(Ci ) ⊕ Ci−1 C0 wird auf einen Initialwert gesetzt. Eine Änderung im Klartext kann sich daher durch weitere Chiffreblöcke ziehen.

4.7 Informationstheorie und Kryptografie

133

4.6.3.3 Cipher Feedback Modus (CFM) Mithilfe der erzeugten Chiffreblöcke wird ein Schlüsselstrom erzeugt, der verwendet wird, um gemeinsam mit K den Rundenschlüssel Ki zu erzeugen. Der Rundenschlüssel ist somit vom vorhergehenden Chiffreblock abhängig, womit sich Veränderungen in M durchziehen: Ci = E(Ci−1 ) ⊕ Pi C0 wird auch hier zuvor auf einen Initialwert gesetzt.

4.6.3.4 Output Feedback Modus (OFM) Es wird ein Schlüsselstrom erzeugt (aus einem Initialwert), der durch eine Funktion zur Schlüsselgenerierung gemeinsam mit K zum Rundenschlüssel wird. Dieser Rundenschlüssel wird nicht nur für Ki ⊕ M verwendet, sondern dient in der Folgerunde neben K wieder als Eingabe für die Funktion zur Generierung des Rundenschlüssels Ki+1 . 4.6.3.5 Counter Mode (CTR) Hierbei wird ein Zufallswert auf Basis eines Initialwerts und eines bei jedem Durchlauf inkrementierten Counters generiert. Dieser Zufallswert dient als Schlüssel: Ci = E(Initialwert||Counteri ) ⊕ Pi

Es existieren weitere Blockchiffren-Modi, insbesondere in Verbindung mit Message Authentication Codes, die in Abschn. 4.8.9 erläutert werden.

4.7

Informationstheorie und Kryptografie

Bei Auseinandersetzung mit den theoretischen Aspekten der Kryptografie kommt irgendwann die Feststellung auf, dass Kryptografie in irgendeiner Form Informationen verschlüsselt und sichert. Es stellen sich somit grundlegende Fragen, etwa: Wie lässt sich Information messen? Welchen Bedeutung hat welche Art von Information für die Kryptografie? Bei der Beantwortung dieser Fragen liefert die Informationstheorie Abhilfe. Die Informationstheorie wurde von Claude E. Shannon begründet. Im Folgenden werden einige Grundbegriffe der Informationstheorie erläutert. Diese Grundlagen werden anschließend im Rahmen der Kryptografie betrachtet.

134

4 Einführung in die Kryptografie

l

l

Abb. 4.7 Entscheidungsgehalt H0 , abhängig von der Ereignisanzahl

4.7.1

Grundzüge der Informationstheorie

Die zentralen Grundbegriffe, die zum Verständnis der Informationstheorie benötigt werden, sind Entscheidungsgehalt, Informationsgehalt und Entropie.

4.7.1.1 Entscheidungsgehalt Ein Zufallsereignis stellt aus Sicht der Informationstheorie Information dar – etwa den Ausgang einer Sportwette. Ein [bit] repräsentiert dabei zwei gleich wahrscheinliche Ereignisse. In [bit] wird gemessen, wie viele Ja/Nein-Fragen benötigt werden, um den Ausgang eines Zufallsereignisses zu erfahren. Der sogenannte Entscheidungsgehalt H0 gibt an, wie viele [bit] benötigt werden, um n verschiedene Werte unterscheiden zu können: (4.4) H0 = log2 (n). Abb. 4.7 stellt dar, wie viele [bits] abhängig von der Anzahl der Ereignisse (Werte) benötigt werden. Für zwei verschiedene Ereignisse wird beispielsweise 1 [bit], für drei Ereignisse werden 1585 [bit] und für 16 Ereignisse werden bereits 4 [bit] benötigt.

Einschub: Anmerkung zum Begriff bit/Bit: In der Informationstheorie wird zwischen [bit] und [Bit] als Einheit unterschieden. Die Einheit [bit] hängt vom Logarithmus zur Basis 2 ab. Wird die Basis e verwendet, (Fortsetzung)

4.7 Informationstheorie und Kryptografie

135

wird die Einheit [nat] verwendet, bei der Basis 10 die Einheit [hartley] oder [ban]. Der Unterschied zur Einheit [Bit] ist der, dass [Bit] für die binäre Darstellung verwendet wird. Ein [Bit] ist immer ganzzahlig. Für die Darstellung von n [bit] sind also mindestens b Bits notwendig. Diese Feinheit wird allerdings nicht von allen Autoren unterschieden. Aus diesem Grund wird im Folgenden einheitlich von „Bit“ beziehungsweise dem Plural „Bits“ gesprochen.

4.7.1.2 Informationsgehalt Der Informationsgehalt I eines Ereignisses i gibt an, wieviel Information durch Kenntnis über das Ereignis gewonnen wird. Je unwahrscheinlicher das Ereignis ist, umso mehr Information wird erzeugt. Dies ist auch plausibel. Angenommen, Sie wissen, dass Ihre Nachbarn nächsten Sonntag heiraten. Am Montag darauf fragen Sie Ihre Nachbarn, ob sie wirklich geheiratet haben. Wahrscheinlich wird die Antwort „Ja“ lauten, was sie nicht überraschen wird. Der weniger wahrscheinliche Ausgang „Nein“ wäre hingegen überraschender.   1 = − log2 (pi ), mit 0 < p ≤ 1 Ii = log2 pi Ist I = 0, dann ist der Ausgang eines Ereignisses sicher, denn p = 1. Abb. 4.8 stellt die Werte von log2 (1/x) grafisch dar. Wie Sie sehen, sind besonders unwahrscheinliche Ereignisse mit einem besonders hohen Informationsgehalt versehen.

4.7.1.3 Entropie Die Entropie H ist der mittlere Informationsgehalt einer Menge von statistisch unabhängigen Ereignissen. Sie ist die Summe der Informationsgehälter, jeweils multipliziert mit der Auftrittswahrscheinlichkeit: H (p) =

n  i=1

pi Ii = −

n 

pi log2 (pi ).

(4.5)

i=1

Hierbei ist zu beachten, dass es zwei unterschiedliche Schreibweisen gibt: H (p) = H (p1 , p2 , . . . , pn ).

(4.6)

Angenommen, ein Proband soll einen von zwei symmetrischen Verschlüsselungsalgorithmen auswählen. Dazu soll ein Kleinkind auf eine von zwei Tasten drücken, von denen eine für DES und eine andere für AES steht. Das Kind wird diese Tasten mit ungefähr gleicher Wahrscheinlichkeit drücken, somit ist pDES = pAES = 0.5. Entsprechend ist H (p) = −2(0.5 · log2 (0.5)) = 1. Wenn das Kleinkind nun durch einen Leser

136

4 Einführung in die Kryptografie 7

log(1/x)/log(2)

6

5

4

3

2

1

0

0

0.2

0.4

0.6

0.8

1

Abb. 4.8 Plot der Funktion log2 (1/x)

der vorherigen Abschnitte ersetzt wird, dann dürfte das Ergebnis hingegen mit deutlich höherer Wahrscheinlichkeit für AES ausfallen, etwa pDES = 0.05 und pAES = 0.95. Somit ergibt sich eine deutlich niedrigere Entropie: H (p) = 0.286. Abb. 4.9 stellt die Entropie für die zwei Ereignisse p und 1 − p dar. Angenommen, X und Y seien Zufallsexperimente und der Ausgang von Y würde X beeinflussen. In dieser Situation liegt eine bedingten Entropie vor. Es gilt, dass H (X|Y ) = H (X), falls X gar nicht von Y abhängig ist. Falls X hingegen völlig von Y abhängig ist, so gilt H (X|Y ) = 0. X und Y bestehen aus i beziehungsweise j Ereignissen. Auf Basis der bedingten Entropie lässt sich eine interessante Frage stellen: Wie unbestimmt ist eine Quelle nach dem Empfang von Nachrichten? Oder, im Kontext der Kryptografie betrachtet: Wie unbestimmt ist eine Klartextnachricht M noch, wenn der Chiffretext C empfangen wurde, das heißt H (M|C)? Anstelle von M kann auch K in diese Fragestellung eingesetzt werden. Um in Erfahrung zu bringen, wie sich die bedingte Entropie für ein Ereignis yi aus Y auswirkt, muss H (X|Y = yi ) bestimmt werden: H (X|Y = yi ) = −

n  i=1

P (X = xi |yi ) log2 P (X = xi |yi ).

(4.7)

4.7 Informationstheorie und Kryptografie

137

1 0.9 0.8 0.7

H(p, 1-p)

0.6 0.5 0.4 0.3 0.2 0.1 -(x*(log(x)/log(2)) + ((1-x)*(log(1-x)/log(2))))

0

0

0.2

0.4

0.6

0.8

1

p

Abb. 4.9 Entropiewerte für H (p, 1 − p)

Für alle Ereignisse aus Y lässt sich dies ebenfalls berechnen10 : H (X|Y ) =

m 

H (X|Y = yi )P (Y = yi ).

(4.8)

j =1

4.7.2

Informationstheorie in der Kryptografie

Die Unsicherheit einer Nachricht wird im Folgenden mit H (X) bezeichnet. Das heißt H (X) repräsentiert die Anzahl der Klartextbits, die ein Angreifer wiederherstellen muss, um eine verschlüsselte Nachricht zu verstehen [24]: Wenn die verschlüsselte Nachricht ‘%_q)t’ eine von zwei Haustiersorten repräsentiert, dann verbirgt sich hinter ihr folglich auch nur 1 Bit an Information, die der Angreifer wiederherstellen muss, auch wenn für die Darstellung als String mehrere Bytes benötigt werden [24].

10 Die Schreibweisen p und P (X = x ) sind gleichbedeutend. i i

138

4.7.3

4 Einführung in die Kryptografie

Redundanz

(M) Informationsrate r (auch Coderate [23]) einer Sprache ist r = H N [24], wobei M die Nachricht und N = |M|. N wird möglichst groß gewählt, sodass möglichst viel Text einer Sprache analysiert wird. Bei natürlicher Sprache ist r etwa im Bereich 1,0–1,5 Bits pro Buchstabe [24], wobei die Entropie mit der Länge der Nachricht abnimmt. Auch dies erscheint plausibel: Oft kann mit einer kurzen E-Mail dasselbe gesagt werden, wie mit einer langen Mail. In der Kürze liegt die Würze!. Die absolute Informationsrate R ist log2 (L), wobei L die Anzahl der Zeichen der Sprache ist [24]. R stellt die maximale Entropie sämtlicher Symbole der Sprache dar. Die Redundanz D einer Sprache ist somit: D = R − r [24]. Umgestellt nach H ergibt sich somit H (M) = N(R − D). Bei 26 Buchstaben liegt die absolute Informationsrate bei log2 26 = 4,7 Bits/Symbol [19]. Tatsächlich beinhaltet das Englische jedoch nur etwa einen Informationsgehalt von 1,3 Bits/Symbol. Das heißt, 3,4 Bits pro Buchstabe sind redundant [24]. Menezes et al. geben mit D = 3,2 (basierend auf einem Informationsgehalt von 1,5 Bits/Symbol) einen leicht unterschiedlichen Wert für die englische Sprache an [19]. Die meisten Sprachen, die auf dem Lateinischen basieren, dürften grob einen Wert zwischen 3,0 − 3,5 liefern.

Etwas Unterhaltung am Rande Nun wissen Sie genug, um sich problemlos mit der Frage zu befassen, wie viele verschiedene Nachrichten auf Twitter gepostet werden können (ohne Redundanzen), und wie lang das Posten all dieser Nachrichten dauern würde, wenn es von Menschen durchgeführt wird. Eine Antwort hierauf finden Sie im Buch What If von Randall Munroe. Munroe ist übrigens auch Autor des unter Informatikern beliebten Web-Comics xkcd.

4.7.4

Sicherheit eines Kryptosystems

Einem Kryptoanalytiker ist oft die Art eines Klartexts bekannt. Damit ist ihm auch die verwendete „Sprache“ bekannt (beispielsweise Englisch, Perl oder die Struktur einer HTML-Datei). Sprache hat wiederum eine natürliche Redundanz.11 Neben Symbolen treten auch bestimmte Wörter nicht ganz frei auf; so enden deutsche Texte selten mit einem „Hallo“. Es gibt eine große Zahl möglicher Klartexte, aber eine geringe Zahl wahrscheinlicher Klartexte. Es gibt viel Redundanz und somit wenig Entropie. Aus diesem Grund sind statistische Angriffe auf Chiffretexte möglich.

11 Siehe auch Abschn. 4.4 zur Kryptoanalyse historischer Chiffren.

4.7 Informationstheorie und Kryptografie

139

Im Kontext dieser Redundanz stellt sich die Frage der perfekten Sicherheit des OneTime-Pads erneut. Die Anzahl möglicher Schlüssel war dabei größer als die Anzahl möglicher Nachrichten und C darf keinerlei Informationen über M erhalten. Somit ist folgende Bedingung erfüllt: H (M|C) = H (M) [29]. Entropie ist in der Kryptografie außerdem ein Maß für die Größe des Schlüsselraums [24] und H (|K|) = log2 (|K|). Bei einem 8 Bits langen Schlüssel gibt es maximal 256 mögliche Schlüssel, weil log2 (28 ) = 8 Bits; bei DES also beispielsweise H (256 ) = 56 Bits. Wenn die Schlüsselgenerierung nicht absolut zufällig ist, sinkt die Entropie. Daher ist log2 (|K|) ohne Gewichtung der einzelnen Schlüssel mit pi eigentlich nur näherungsweise korrekt.

4.7.5

Spurious Keys

Wie viele Schlüssel gibt es, die einen Chiffretext der Länge N in lesbaren Klartext der Ausgangssprache überführen? Die Anzahl A dieser Schlüssel entspricht gemäß einem 1977 veröffentlichten Aufsatz von Hellman in etwa [13, 19, 24]. A = 2H (|K|)−N ·D .

(4.9)

Die Ergebnisse von A sind manchmal unrealistisch. A ist letztlich nur eine Abschätzung. Die Herleitung für diese Formel ergibt sich über die Umstellung der Formel für D, also H (M) = N (R − D), wobei R in diesem Fall nicht benötigt wird, sondern nur D, wodurch −N · D übrigbleibt. Berechnet wird folglich: Entropie vom Schlüsselraum minus Länge vom Chiffretext multipliziert mit der Redundanz der Sprache. Die Berechnung erfolgt dabei mit einer Zweierpotenz (2x ), weil die Schlüsselanzahl aus der Entropie abgeleitet werden soll (andernfalls würde nur mit der Anzahl der Schlüsselbits gerechnet werden). Dies ist plausibel, denn mit einem längeren N wird es schwieriger, plausible Klartexte zu finden. Je größer D (Redundanz) ist, umso geringer ist auch r, wodurch ebenfalls weniger plausible Klartexte möglich sind. N · D steht somit für die sinnlosen (Hellman: meaningless) Nachrichten, die von der Gesamtzahl an Nachrichten (H (|K|)) abgezogen werden. Übrig bleiben die sinnvollen (Hellman: meaningful) Nachrichten [13].

4.7.5.1 Illustration Es liege eine Caesar-Chiffre mit der Ausgangssprache Englisch und dem Chiffretext „EVF“ vor. Mit unterschiedlichen Werten für k ergeben sich die Klartexte „NEO“, „BSC“ (akademischer Grad) beziehungsweise „DUE“, also plausible englische Klartexte. Bei einer Vigenère-Chiffre wären zudem weitere Klartexte denkbar, wenn |K| >= 2, etwa „THE“, „MOM“, „DAD“ oder „NOT“.

140

4 Einführung in die Kryptografie

4.7.5.2 Spurious Keys Das heißt, es existieren mehrere mögliche k ∈ K, die aus C einen irgendwie Sinn ergebenden Text erzeugen, der aber nicht der Ursprungstext M sein muss. Ein Schlüssel, der ein plausibles M  = M erzeugt, wird auch Spurious Key genannt (davon gibt es entsprechend A − 1 Stück). Beispiel. Ein Chiffrierverfahren verwendet einen Schlüssel der Länge 128 Bits. Der Chiffretext habe die Länge |C| = 40 und die Redundanz der Sprache sei etwa 3. Somit ist A = 2128−40·3 = 256 Schlüssel. Entsprechend gibt es in etwa A − 1 = 255 Spurious Keys.

4.7.6

Unizitätsdistanz

Die Unizitätsdistanz (engl. Unicity Distance) U ist ein Näherungswert für die Menge verschlüsselten Texts, die benötigt wird, damit der Erfolg von einem Brute-Force-Angriff in dem Sinne unwahrscheinlich ist, dass mehr als ein einziger möglicher Plaintext samt zugehörigem Schlüssel gefunden wird. Anders formuliert, ein Chiffretext, der länger als U Symbole ist, könnte wahrscheinlich nicht zu mehreren plausiblen Klartexten führen. Die Anzahl der Spurious Keys ist in diesem Fall wahrscheinlich Null. U kann hergeleitet werden, indem bei der Formel zur Berechnung der Spurious Keys der Exponent auf Null gesetzt wird, weil A = 20 = 1 ist und dieser eine Schlüssel der tatsächliche Schlüssel, also kein Spurious Key, ist: H (|K|) − nD = 0 H (|K|) = nD n=

H (|K|) = U. D

Geht D (die bereits eingeführte Redundanz einer Sprache) gegen Null beziehungsweise ist |K| sehr groß, dann ist ein Kryptosystem recht sicher, da U sehr groß wird. Beispiel Vigenère-Chiffre mit 3-Zeichen-Schlüssel: Für eine Vigenère-Chiffre gibt es  maximal | ||K| Schlüssel (also 263 = 17576). Dann ist H (|K|) = log2 (17576) = 14,1. Ein natürlicher Text hat etwa D = 3,5. Somit: U =

14,1 = ca. 4 Zeichen 3,5

Wenn der Text länger ist, wird ein Brute-Force-Angriff wahrscheinlich kein plausibles M  = M mehr erzielen. Anders formuliert heißt das: Ein Brute-Force-Angriff führt sehr wahrscheinlich zum korrekten M, sobald die Nachricht ≥ 4 Zeichen lang ist.

4.8 Kryptografische Hashfunktionen

141

Beispiel One-Time-Pad: Die Anzahl der Schlüssel für ein One-Time-Pad ist unendlich [19], denn sie wächst mit steigender Nachrichtenlänge automatisch mit [25]: U =

26|M| → ∞. 3,5

Es kann also maximal viel plausibler Klartext erzeugt werden, da eine Nachricht unendlich lang sein müsste, um einen aus Angreifersicht erfolgreichen Brute-ForceAngriff durchzuführen, das heißt um das echte M statt nur irgendein M  = M zu erhalten.

4.8

Kryptografische Hashfunktionen

Hashfunktionen sind zunächst einmal nicht notwendigerweise zur Kryptografie gehörig. Sie wurden in der Mitte des vergangenen Jahrhunderts vom IBM-Mitarbeiter und 1896 in Deutschland geborenen Hans Peter Luhn erfunden [27].  Eine Hashfunktion H , enthält eine Eingabe des Alphabets beliebiger Länge (etwa eine Textdatei), also das Urbild, und erzeugt daraus einen Hashwert h fester Länge n = |h|, etwa ‘24988892bfc53b18b6d0fcc6ccbb9b59’. h:

∗

→

n

,n ∈ N

Der Hashwert ist ein Komprimat im Sinne einer Prüfsumme [30], wobei auch die Bezeichnung Hashsumme geläufig ist. Weitere mögliche Bezeichnungen für h sind Fingerabdruck (engl. Fingerprint) und Message Digest. Die typische Länge von n beträgt bei den meisten modernen Hashfunktionen zwischen 224–512 Bits.

4.8.1

Einweg-Hashfunktionen

Ist H eine Einweg-Hashfunktion, dann bedeutet das, dass zu einem gegebenen M die Berechnung von H (M) einfach ist, umgekehrt aber die Berechnung von einem gegebenen h zu einem M, wobei wie oben h = H (M) gilt, schwierig ist. Anstelle des Wortes Einweg-Hashfunktion wird manchmal auch von einer kryptografischen Hashfunktion, einem Message Integrity Code, einem Manipulation Detection Code, einer Footprint-Funktion oder einem kryptografisches Prüfsummenverfahren gesprochen [22].

142

4.8.2

4 Einführung in die Kryptografie

Kollisionsresistenz

Es gibt noch einen weiteren wichtigen Begriff im Zusammenhang mit kryptografischen Hashfunktionen: Wenn es sehr schwierig ist, zu einem gegebenen M eine beliebige Nachricht M  (wobei gilt: M = M  ) zu berechnen mit H (M) = H (M  ), dann ist die Eigenschaft der Kollisionsresistenz erfüllt [24]. Schmeh erwähnt zwei wichtige Voraussetzungen für Kollisionen [22]: Probiert man alle Urbilder durch, dann sollte jeder Hashwert etwa gleich oft vorkommen. Der Hashwert sollte sich auch bei kleinen Änderungen des Urbilds ändern.

Ganz unbekannt ist Ihnen diese Anforderung nicht, da Sie sie bereits durch die Diffusion bei DES kennen. Wenn nur ein einziger Buchstabe von M verändert wird, verändert sich die gesamte Nachricht. Am Beispiel von MD5 lässt sich dies demonstrieren. $ md5sum katze 2 f57741f6a1ce8ed633395fc4ece1550 $ md5sum Katze a958290d7d801e6a0a0f63c727f86bbe

−

−

Die SHA1-Prüfsumme ist länger, als die von MD5, doch auch sie wird bei der kleinsten Änderung von M stark modifiziert: $ sha1sum katze c1f32a0edf42dc36a08bc8a16a222ce9d73a0524 $ sha1sum Katze 6 d22a6e528e5dd54b301b83127843a012421be53

−

−

Bei Buchmann [7] und Wätjen [30] wird die Kollisionsresistenz noch in die sogenannte schwache Kollisionsresistenz (engl. Second Preimage Resistant Function) und die sogenannte starke Kollisionsresistenz (engl. Collision Resistant Function) unterteilt. Der Unterschied liegt darin, dass es bei einer schwach kollisionsresistenten Funktion praktisch unmöglich seien muss, für ein gegebenes M ein M  zu finden, für das gilt H (M) = H (M  ), M = M  ). Bei einer starken Kollisionsresistenz muss es rechnerisch auch praktisch unmöglich sein, diese Bedingung mit einem beliebigen M zu erfüllen.

4.8 Kryptografische Hashfunktionen

4.8.3

143

Geburtstagsangriff und Substitutionsattacke

Ein eng mit kryptografischen Hashfunktionen zusammenhängendes Problem der Statistik ist der sogenannte Geburtstagsangriff. Die Idee hierfür basiert auf dem mathematischen Geburtstagsparadoxon (auch bekannt als Geburtstagsproblem). Das Geburtstagsparadoxon basiert auf folgender Überlegung und Fragestellung: Angenommen es gibt einen Raum, in dem sich eine bestimmte Anzahl von Personen befindet. Wie viele Personen müssen in diesem Raum sein, damit mit einer Wahrscheinlichkeit von mindestens 50 % eine Person an einem bestimmten Tag Geburtstag hat? Es sind 253 Personen notwendig, denn die Wahrscheinlichkeit dafür, Geburtstag an Tag x zu haben, ist P = 1/365 = 0,274 %. Die Wahrscheinlichkeit dafür, nicht an Tag x Geburtstag zu haben ist entsprechend y = 1 − P = 0.99726. Und durch Ausprobieren ergibt sich leicht y 253 = 49,9948 %. An dieser Stelle ist weniger die Zahl an sich, als vielmehr ihr Verhältnis zu einer anderen Zahl von Bedeutung: Formuliert man die Frage nämlich leicht um, so dass man nicht mehr die nötige Personenzahl zu einem bestimmten Geburtsdatum sucht, sondern die Anzahl von Personen sucht, bei denen zwei Personen am gleichen Tag Geburtstag haben (dies kann nun jeder Tag des Jahres sein), dann werden nur 23 Personen benötigt [18]. Die Anzahl möglicher Geburtstagskombinationen bei n Personen ist m = 365n . Davon haben u = 365!/(365−n)! einen unterschiedlichen Geburtstag. Die Wahrscheinlichkeit für mindestens einen doppelten Geburtstag beträgt somit P = 1−u/m, womit sich für n = 23 eine Wahrscheinlichkeit von ca. 50 % ergibt [32]. Hashfunktionen werden unter anderem (allerdings in Verbindung mit weiteren kryptografischen Funktionen) zur Überprüfung von elektronischen Dokumenten verwendet. Auch hier spielt das Geburtstagsparadoxon eine Rolle: Angenommen, unsere Angreiferin Mallory möchte zu einem Kaufvertrag K eine Fälschung Q mit für sie günstigeren Konditionen erstellen. Beide Kaufverträge (Original und Fälschung) sollen denselben Hashwert liefern. Möglichkeit 1 (schwache Kollisionsresistenz): Mallory sucht ein Q, für das gilt: H (Q) = H (K) unter der Bedingung, dass Q = K ist. Zu diesem Zweck führt Mallory einen Brute-Force-Angriff aus, das heißt sie probiert sämtliche Modifikationsmöglichkeiten durch, bis sie eine Kollision findet. Zu diesem Zweck führt sie möglichst subtile Modifikationen an K durch (beispielsweise Einfügen von Whitespaces). Bei einer guten Hashfunktion, wird es sehr schwierig, diesen Angriff erfolgreich durchzuführen. Möglichkeit 2 (starke Kollisionsresistenz): Mallory erstellt eine beliebige Anzahl entsprechend unsichtbar verschiedener Dokumente K1 bis Kn und versucht mit einer beliebigen Anzahl von unsichtbar modifizierten Dokumenten beziehungsweise geringfügig modifizierten Dokumenten (etwa durch unsichtbare Kommentare oder sinngemäß ersetzte Wörter [22]) Q1 bis Qm eine Kombination (Ki , Qj ) zu finden, bei denen der Hashwert übereinstimmt. Er unterzeichnet anschließend das zum Qj passende Ki . Man spricht in diesem Fall von einer Substitutionsattacke [22]. Es muss also gelten: H (Ki ) = H (Qj ).

144

4 Einführung in die Kryptografie

Da – wie beim Geburtstagsparadoxon – nun eine höhere Anzahl an Hashwerten (beziehungsweise Geburtstagen) zur Wahl steht, gibt es auch eine höhere Anzahl von Dokumentenpaaren, bei denen die Hashwerte übereinstimmen.

4.8.4

Hashwertlänge im Kontext von Angriffen

Interessant sind im Kontext des Geburtstagsangriffs zwei historische Aussagen zur Hashwertlänge. Wätjen kam 2002 zu folgendem Schluss: Ein 40 Bits großer Fingerabdruck wäre sehr unsicher, da eine Kollision mit Wahrscheinlichkeit 1/2 bei etwas über 220 (etwa einer Million) zufälligen Wahlen [. . . ] gefunden würde. Die minimale Größe eines Fingerabdrucks sollte schon 128 Bits sein [. . . ] [30].

Schneier kam bereits 1996 zu einem ähnlichen Fazit: Hashfunktionen mit 64 Bits sind einfach zu klein, um einem Geburtstagsangriff zu widerstehen. Die meisten Einweg-Hashfunktionen in der Praxis liefern Hashwerte mit 128 Bit. Das zwingt Angreifer, die mit einer Geburtstagsmethode arbeiten, 264 Dokumente zu untersuchen, um zwei mit dem gleichen Hashwert zu finden [24].

Schneier kam zudem zum Schluss, dass 128 Bits langfristig nicht genug seien. Nun stammen diese Aussagen von Wätjen und Schneier aus den Jahren 2002 und 1996. Mit der Zunahme an Rechenleistung ist es allerdings immer einfacher, Kollisionen bei Hashfunktionen zu finden. Entsprechend müssen Algorithmen und auch die Längen der Hashwerte kontinuierlich angepasst werden. Heute (Stand: Frühjahr 2018) gelten Hashfunktionen wie SHA-2 und SHA-3 mit Hashwertlängen ab 224 Bits als sicher. Das folgende Listing veranschaulicht Ihnen Beispielhashwerte der Algorithmen MD5, SHA1 und SHA2 (mit verschieden langen Hashwerten): $ e c h o " K a t z e " | md5sum ### 128 B i t a958290d7d801e6a0a0f63c727f86bbe − $ e c h o " K a t z e " | sha1sum ### 160 B i t 6 d22a6e528e5dd54b301b83127843a012421be53 − $ e c h o " K a t z e " | sha224sum ### 224 B i t 579 c 9 2 f 5 7 a 7 f b 6 e c 9 8 a 8 c 3 2 a c b 8 b 2 e d 2 2 7 e b 4 f c 3 c 1 b 5 e 8 0 a d 1 b 7 5 f d 9 $ e c h o " K a t z e " | sha256sum ### 256 B i t b6780d32db84249a92f9911b288007832cb0f0bb15da438ac16a0edf 9 ee49f07 − $ e c h o " K a t z e " | sha512sum ### 512 B i t 2 fe7c71762484914763ace83f80ced138f98352614846731522dda78 4 cbbd6b170aa9ceb101256cb3b9f5e3f512453a5c22630b7786da1d5 92 a 8 a 1 8 d 1 4 1 f 1 2 a 7 −

−

4.8 Kryptografische Hashfunktionen Tab. 4.2 Hashwertlängen bedeutsamer Hashfunktionen

145

Algorithmus

Hashwert-Länge

MD2 (Message Digest) MD4 MD5 MD6 SHA (Secure Hash Algorithm) SHA-1 SHA-2 SHA-3 RIPEMD-128 N-Hash RIPEMD-160 Snefru HAVAL

128 Bits 128 Bits 128 Bits 1-512 Bits (variabel) 160 Bits 160 Bits 256, 384 und 512 Bits 224, 256, 384 und 512 Bits 128 Bits 128 Bits 160 Bits 128 Bits 128, 160, 192, 224 und 256 Bit

Die folgende Tab. 4.2 listet die wichtigsten Hashfunktionen samt der Länge ihrer Hashwerte auf. Manche Hashfunktionen gibt es in mehreren Varianten, sodass sie mehr als eine Hashwertlänge unterstützen. Kürzere Hashwerte benötigen weniger Speicher und Rechenleistung, was bei sehr großen Datenmengen oder leistungsschwachen Systemen einen Vorteil bieten kann. Wenn Speicher und Performance keine Rolle spielen, sollte die Wahl auf einen längeren Hashwert fallen.

4.8.5

Wörterbuchangriff (Brute-Force-Angriff)

Beim Wörterbuchangriff, auch Brute-Force-Angriff genannt, wird versucht, ein einzelnes Wort beziehungsweise einen einzelnen String s1 zu einem gegebenen String s2 zu finden, sodass gilt: H (s1 ) = H (s2 ). Dieser Angriff führt speziell bei kurzen Zeichenfolgen oft zum erwünschten Erfolg, etwa bei kurzen Passwörtern in Passwortdateien unter Linux, BSD und Unix (siehe Abschn. 4.8.10). Um möglichst schnell auf ein verwendetes Passwort zu schließen, werden zunächst Wörterbücher mit besonders häufigen Passwörtern durchprobiert. Ein typisches Tool, das dabei zum Einsatz kommt, ist John the Ripper [14].

4.8.6

Hashwerttabellen und Regenbogentabellen

Hashwerttabellen (engl., Hashtables, siehe Tab. 4.3) sind vorberechnete Tabellen, die Nachrichtentexte und Hashwerte gegenüberstellen [22]. Auf diese Weise ist es möglich, von Hashwerten mit vergleichsweise geringem Aufwand auf einen potenziellen ursprünglichen Nachrichtentext zu schließen.

146

4 Einführung in die Kryptografie

Tab. 4.3 Beispiel: Auszug aus einer Hashwerttabelle

Klartext Hashwert aaa aab aac ...

3435h45g0q38fn 4j03gj34h04faM vMng2Qxjvvjpi9 ...

Tab. 4.4 Beispiel einer Rainbow Table P1

h1 = H (P1 )

P2 = R1 (h1 )

.. ..

Pn−1 = Rn−2 (hn−2 )

hn−1 = H (Pn−1 )

Pn = Rn−1 (hn−1 )

hn = H (Pn )

aaaa 3y16 ..

h3Gm LK × G ..

dEfg 1 × fg ..

.. .. ..

v84b mMJQ ..

m2uh jjQ1 ..

3hjk 9 × 4B ..

MeR2 UUqn ..

Da Hashwerte allerdings zahlreich und Klartextnachrichten ebenfalls zahlreich sind, ist zum einen viel Speicher und zum anderen nach wie vor viel Rechenzeit von Nöten, um mit dieser Methode einen erfolgreichen Angriff durchzuführen. Außerdem wird es keine Tabellen geben, die alle möglichen Klartextnachrichten samt deren Hashwerten beinhalten, da Nachrichten beliebig lang sein können. Hashwerttabellen eignen sich daher vielmehr als Alternative zu Brute-Force-Angriffen, wenn es darum geht, von Hashwerten auf kurze Strings (etwa Passwörter) zu gelangen. Eine verbesserte Technik basiert auf der Generierung von sogenannten Regenbogentabellen (engl. Rainbow Tables). Diese Tabellen bestehen aus n Spalten und verwenden Reduktionsfunktionen. Die Reduktionsfunktion i wird im Folgenden mit Ri bezeichnet. Mallory berechnet aus dem Plaintext einen Hashwert, wendet danach die erste Reduktionsfunktion auf den Hashwert an, hasht das Ergebnis wieder usf. (siehe Tab. 4.4). Gespeichert werden nur die Spalten 1 und n: R ist dabei natürlich keine Umkehrfunktion von H . Stattdessen bildet R einen Hashwert h auf einen Plaintextwert ab. Beispielsweise kann R einfach die ersten acht Zeichen von h abschneiden. Gute Reduktionsfunktionen arbeiten allerdings möglichst kollisionsfrei. Die Werte einer Tabellenzeile werden als Kette oder Chain bezeichnet.

4.8.6.1 Vorgehen bei einem Angriff Schritt 1: Mallory durchsucht zunächst die letzte Spalte der Rainbow Table und vergleicht diese Spalte mit dem gesuchten Hashwert h. Ist der gesuchte Hashwert in der Spalte enthalten (in Tab. 4.5 rot), berechnet sie durch den Wert von Spalte 1 (das heißt P1 derselben Zeile) alle Werte der Zeile bis zur vorletzten Spalte (in Tab. 4.5 blau) und erhält somit den gesuchten Plaintext (dieser ist Pn , da offensichtlich gilt: H (Pn ) = h). Schritt 2: Falls der gesuchte Hashwert nicht in der letzten Spalte gefunden wurde, ruft Mallory die letzte Reduktionsfunktion Rn−1 mit dem Hashwert h auf und prüft, ob der

4.8 Kryptografische Hashfunktionen

147

Tab. 4.5 Rainbow Table von Mallory P1

h1 = H (P1 )

P2 = R1 (h1 )

.. ..

Pn−1 = Rn−2 (hn−2 )

hn−1 = H (Pn−1 )

Pn = Rn−1 (hn−1 )

hn = H (Pn )

aaaa 3y16 ..

h3Gm LKxG ..

dEfg 1xfg ..

.. .. ..

v84b mMJQ ..

m2uh jjQ1 ..

3hjk 9x4B ..

MeR2 UUqn ..

Hashwert von diesem Ergebnis (also H (Rn−1 (h))) nun einem H (Pn ) der Rainbow Table entspricht.12 Nun können zwei verschiedene Fälle eintreten: 1. Mallory findet ein passendes H (Pn ), das ihrem H (Rn−1 (h)) entspricht. Das heißt, der Hashwert befindet sich in der entsprechenden Zeile und entspricht hn−1 . Sie berechnet nun analog zu Schritt 1 die Werte der Zeile ausgehend von P1 , bis sie zum gesuchten Pn−1 kommt, das ihr H (Pn−1 ) = hn−1 = h liefert. Dieses Pn−1 ist ihr gesuchtes Passwort. 2. Falls der neue Hashwert erneut keinem H (Pn ) entspricht: Schritt 2 analog wiederholen, indem sie die vorletzte Reduktionsfunktion geschachtelt aufruft und die Tabelle weiter „rückwärts“ (nach links) berechnet, also: H (Rn−1 (H (Rn−2 (h)))). Erneut testet sie, ob das Ergebnis einem H (Pn ) entspricht. Falls dem nicht so ist, schachtelt sie die nächsthöhere Reduktions- und Hashfunktion wieder analog zu Schritt 2 usf., bis sie einen passenden Hashwert gefunden hat oder an der ersten Spalte angelangt ist (dann hätte sie alle vorhandenen Reduktionsfunktionen durchprobiert). 3. Falls Mallory die linke Seite der Tabelle erreicht hat und keinen passenden Wert gefunden hat, der letztlich h erzeugt, befindet sich das gesuchte Passwort nicht in der Rainbow Table. Effizienz von Rainbow Tables: Bei Rainbow Tables müssen deutlich weniger Daten gespeichert werden, als bei einem Hashtable. Die Rückberechnung erfolgt gegenüber einem Hashtable verhältnismäßig effizient. Das Suchen nach Passwörtern kann jedoch noch immer extrem viel Zeit in Anspruch nehmen. Typische Programme für Rainbow Tables sind RainbowCrack und DistrRTgen, Letzteres verwendet sogar einen verteilten Rechenansatz.

12 Anm.: Mallory geht also einen Schritt nach links in der Tabelle und muss die Tabellenwerte zunächst berechnen, da sie diese nicht gespeichert hat.

148

4.8.7

4 Einführung in die Kryptografie

Sicherheit von Hashfunktionen

Für einige Hashalgorithmen sind zumindest teilweise kryptoanalytische Angriffe geglückt. Als regelrecht unsicher gelten N-Hash, Snefru und MD4. Auch MD2 gilt als unsicher. Für RIPEMD wurden Kollisionen beschrieben und MD5 gilt ebenfalls als hochgradig unsicher. Seit etwa zehn Jahren gilt auch SHA-1 als unsicher. Doch insbesondere seit der Anfang 2017 veröffentlichten Kollision SHATTERED, die durch einen praktischen Angriff hervorgerufen wurde, ist klar, dass SHA-1 keine Verwendung mehr finden sollte. Im Rahmen von SHATTERED wurden zwei Dokumente erzeugt, die zum selben SHA-1Hash führten, wofür allerdings noch immer einige Tausend CPU-Rechenjahre notwendig waren. Diese vielen Tausend Rechenjahre sind durch die Möglichkeiten des Parallel Computings (beispielsweise in einer Cloud) beziehungsweise durch die Ausnutzung von Bots in Botnetzen jedoch in den Bereich des Realistischen gerückt. Somit können viele Tausend Computer parallel an einer riesigen Aufgabe wie dem Finden von SHA-1Kollisionen arbeiten – in vertretbarer Zeit. Durchgeführt wurde das entsprechende Projekt von Wissenschaftlern der Universität Amsterdam und Google; sie schätzen die Kosten zum Auffinden einer SHA-1-Hashkollision auf etwa 75.000 bis 120.000 USD (Stand 2017), weshalb das BSI den Einsatz von neueren Alternativen wie SHA-2 empfiehlt [8]. SHA-2 gilt bisher noch als sicher und der Einsatz des Nachfolgers SHA-3 wird vom NIST empfohlen. SHA-3 wurde, wie AES, durch eine Ausschreibung des NIST bestimmt, bei dem (erneut) belgische Wissenschaftler eine Schlüsselrolle spielten.

4.8.8

Aufbau einer typischen Hashfunktion

Die meisten Hashfunktionen (ausgenommen ist etwa SHA-3) basieren auf dem sogenannten Merkle-Damgård-Verfahren. Eine Nachricht wird dabei in n Blöcke gleicher Länge zerlegt (der letzte Block wird, falls notwendig, aufgefüllt). Die Hashfunktion wird mit einem Initialisierungsvektor I in Runde 0 initialisiert (H (0) = I ) und anschließend wird rundenbasiert f aufgerufen. Dabei ist f eine Kompressionsfunktion, die meistens recht einfache Bitoperationen anwendet und die Nachricht auf eine feste Länge bringt. Das Ergebnis der Runde i − 1 wird mit Block M(i) zum Ergebnis der Runde i verrechnet: H (i) = f (M(i), H (i − 1)). Diese Berechnung wird für alle n Blöcke durchgeführt.

4.8 Kryptografische Hashfunktionen

4.8.9

149

Message Authentication Codes (MAC)

Bei Message Authentication Codes (kurz MACs) handelt es sich um kryptografische Hashfunktionen, die von Schlüsseln abhängig sind. Die Verifizierung des Hashwertes ist entsprechend nur mit Hilfe des Schlüssels möglich. Mit MACs sind etwa Überprüfungen von Dateien auf Veränderungen möglich. Im Gegensatz zu Hashfunktionen muss einem Angreifer hierfür allerdings auch der entsprechende Schlüssel bekannt sein. Im Folgenden werden einige besonders bedeutsame MAC-Funktionen besprochen.

4.8.9.1 HMAC (Hashed MAC) Für HMAC wird HMACK (M) = H ((K ⊕ opad)||H ((K ⊕ ipad)||M)) berechnet, wobei K zum Erreichen der Blockgröße (64 Bytes) bei Bedarf mit Nullen aufgefüllt wird. Sollte K länger sein, wird es mit einer Hashfunktion (in RFC 2104 wurde MD5 verwendet [17], was in RFC 6151 schließlich nicht mehr vorgesehen wurde [28]) verkürzt. ipad und opad (inner und outer pad) sind Konstanten in Blockgröße (repetitiv 0 × 5c beziehungsweise 0 × 36), die so gewählt wurden, dass sie eine hohe Hamming-Distanz aufweisen [4]. 4.8.9.2 CBC-MAC (Chipher Block Chaining MAC) CBC-MAC verwendet eine Blockchiffriertechnik im CBC-Modus (siehe Abschn. 4.6.3 zu Betriebsmodi von Blockchiffren), die somit eine Verkopplung der zu verschlüsselnden Blöcke darstellt. CBC-MAC erstellt also einen MAC aus einer Blockchiffre. Als Initialisierungsvektor (IV) wird 0 verwendet (der erste Block von M wird folglich zunächst mit ⊕0 und anschließend mit ⊕K verrechnet: c0 = (m0 ⊕ 0) ⊕ K). Im Anschluss wird das jeweilige ci mit dem folgenden mi+1 verrechnet, sodass ci = ((mi ⊕ ci−1 ) ⊕ K). 4.8.9.3 Counter Mode mit CBC-MAC (CCM/CCM*) Der CCM-Mode sichert neben der Vertraulichkeit auch die Integrität von Nachrichten. Dazu wird ähnlich wie bei CTR-Modus verfahren. Allerdings wird zusätzlich der CBCMAC-Algorithmus verwendet. Die Spezialvariante CCM* wird bei ZigBee eingesetzt. CCM* bietet zusätzlich die Option, entweder ausschließlich Integritätsschutz oder ausschließlich Vertraulichkeitsschutz zu nutzen. 4.8.9.4 Weitere MAC-Varfahren Es existieren noch einige weitere Modi für Blockchiffren, die teilweise auch in Verbindung mit Message Authentication Codes verwendet werden, insbesondere sind dies der Galois/Counter Mode (GCM, sichert die Authentizität und Vertraulichkeit übertragener Daten), die GCM-Variante Galois Message Authentication Code (GMAC), die ausschließlich die Authentizität übertragener Daten sichert, und XCBC-MAC (CBC-MAC mit Erweiterungen, siehe RFC 3566).

150

4 Einführung in die Kryptografie

4.8.9.5 MAC aus einer Einweg-Hashfunktion konstruieren Die Umwandlung von einer schlüssellosen Einweg-Hashfunktion in eine MAC ist dadurch möglich, dass man den Hashwert mit einem symmetrischen Algorithmus (. . . ) chiffrier(t) [24], etwa DESk (H (M)). Auch die „Umwandlung“ einer MAC in eine Einweg-Hashfunktion ist theoretisch denkbar, dazu muss deren Schlüssel veröffentlicht werden [24].

4.8.10 Hashfunktionen und Unix-Passwortdateien Unter Unix-Systemen und unixartigen Systemen werden Passwörter in einer gesicherten Datei (meist /etc/shadow (etwa Linux, Solaris und die meisten anderen verwandten Systeme) oder /etc/master.passwd (etwa OpenBSD)) gespeichert. Jeweils eine Zeile der Datei definiert durch Doppelpunkte getrennte Attribute eines Benutzeraccounts. Eines dieser Attribute (im Normalfall der zweite Wert einer Zeile) ist der Hash des Benutzerpassworts. Solche Passwörter können meist recht schnell (wenige Stunden bis Tage an Rechenzeit) durch den oben beschriebenen Brute-Force-Angriff erraten werden. Passwörter werden durch das Hinzufügen von Zusatzzeichen (dem sogenannten Salt) und durch die Zunahme der Zeichenlänge schwerer zu erraten. Tatsächlich wird anstelle von H (Passwort) das Tupel (S, H (S, Passwort)) gespeichert, wobei S der Salt ist. Ohne Salt würden alle gleichen Passwörter auf jedem System die gleichen Hashwerte erzeugen, sofern die gleiche Funktion H verwendet würde. Auch die Verwendung von Einmalpasswörtern (One-Time-Passwords), etwa via S/Key (vgl. [20]), oder auch das mehrfache Aufrufen einer Hashfunktion (Hash-Iteration, vgl. [22]) kann die Sicherheit von Passwörtern verbessern. Im Normalfall verwendet die dabei eingesetzte Funktion crypt(3) beispielsweise den AES-Algorithmus für Unix-Passwörter (der Schlüssel wird beim Funktionsaufruf übergeben). Werden die ersten beiden Zeichen des setting-Strings (beziehungsweise des salt-Parameters) entsprechend gewählt, so lässt sich ein Hashalgorithmus angeben, etwa “$1” für MD5, “$2a” für Blowfish, “$5” für SHA-256 und “$6” für SHA-512.

4.8.11 Hashfunktionen und Filesystem Intrusion Detection Ein System zur Angriffserkennung für Dateisysteme wird als Filesystem Intrusion Detection System (FIDS) bezeichnet. Ein FIDS erkennt Veränderungen im Dateisystem. Veränderungen können unter Umständen die Folge von Angriffen sein. So könnte sich etwa ein neuer Benutzeraccount in der Passwortdatei eines Linux-Systems befinden. Typische Tools für FIDS sind etwa mtree, tripwire oder AIDE. Diese Tools bilden eine Datenbank sämtlicher Hashes von Dateien im Dateisystem, etwa mit den Hashalgorithmen Tiger, MD5, SHA-2 oder GOST, sowie zugehöriger Metainformationen (Dateigröße, Zeit der letzten Modifikation, des letzten Zugriffs und der Dateierzeuung).

4.8 Kryptografische Hashfunktionen

151

Abb. 4.10 Das Programm mtree findet Differenzen zwischen einem aufgezeichneten und einem aktuellen Zustand eines Verzeichnisses

Veränderungen seit der letzten Überprüfung des Dateisystems werden dem Anwender aufgezeigt, sodass er die Möglichkeit hat, diese zu überprüfen. Das in Abb. 4.10 dargestellte Beispiel zeigt die grundlegende Verwendung des Tools mtree unter OpenBSD. Dabei werden zunächst mit dem SHA-2-Algorithmus die Metadaten des Verzeichnisses /etc eingelesen. Anschließend wird ein Angriff simuliert, indem eine leere Datei (touch exploit.sh) im Verzeichnis /etc/ppp versteckt wird. Beim nächsten Durchlauf des Programms wird die neue Datei sogleich detektiert (extra: ppp/exploit.sh). Außerdem wird von mtree angezeigt, dass das Verzeichnis ppp modifiziert wurde (da die neue Datei dort angesiedelt wurde).

4.8.12 Hashfunktionen und Software Ports Auch bei Port-Systemen werden Hashfunktionen eingesetzt. Ein Port ist in diesem Sinne keine Portierung einer Software, sondern ein Softwarepaket, das vom Anwender über Skripte/Programme auf seinem Rechner erstellt wird. Solche Port-Systeme gibt es etwa unter OpenBSD (ports), NetBSD (pkgsrc), FreeBSD und Gentoo-Linux. In einem Port sind Patches, Skripte, Abhängigkeiten und Parameter zum Kompilieren sowie Hashwerte der Quellpakete vorhanden. Stößt der Anwender das Erstellen eines Ports an, so wird das Quellarchiv (in der Regel vom Server des Anbieters, etwa http://gnu.org für GNU-Software) heruntergeladen. Um Manipulationen der Quellpakete auszuschließen, wird der in den Portinformationen enthaltene Hashwert mit dem Hashwert des soeben heruntergeladenen Quellarchivs verglichen. Nur dann, wenn beide Werte übereinstimmen, wird ein Buildvorgang fortgesetzt. OpenBSD etwa enthält für jeden Port eine distinfo-Datei, in der Hashwerte und Dateigröße eines Archivs hinterlegt sind. Früher wurden diverse Hashwerte kombiniert und nur dann, wenn alle Hashwerte überprüft wurden und übereinstimmen, wurde ein heruntergeladenes Paket entpackt. Mittlerweile wird nur noch SHA-2 mit einem Hashwert der Länge 256 Bits verwendet. SHA256 (asterisk-1.8.30.0.tar.gz) = XyW1X5OPqq6dwnmrryeO9ptk17OGUouOUx4jUuzBOnw= SIZE (asterisk-1.8.30.0.tar.gz) = 29540685

152

4 Einführung in die Kryptografie

Abb. 4.11 Schematischer Aufbau eines Hashbaums

4.8.13 Hashfunktionen und Hashbäume Hashbäume werden mit dem Ziel eingesetzt, Performancegewinne bei der Überprüfung von Hashwerten großer Datenmengen zu gewinnen. Ziel ist es daher, möglichst wenige Vergleiche von Hashwerten durchführen zu müssen. Angenommen, Alice und Bob betreiben Replikas einer Datenbank und in der Datenbank von Alice ergab sich eine Änderung. Bob soll effizient überprüfen können, ob es auch in seiner Datenbank zu dieser Änderung kam. Die Lösung dieses Problems, der Hashbaum, sieht folgendermaßen aus: Alice erzeugt von jedem Datensatz D0 bis Dn einen Hashwert H0 = H (D0 ), . . . , Hn = H (Dn ). Von den Hashwerten werden immer paarweise weitere Hashwerte erzeugt, sodass eine Hierarchie entsteht (Abb. 4.11). Letztlich wird in der höchsten Hierarchieebene nur noch ein finaler Hashwert erzeugt. Falls eine ungerade Zahl von Datensätzen vorliegt (und somit für den letzten Datensatz kein Hashwertpaar erzeugt werden kann), wird der letzte Hashwert auf Ebene 1 auf den Hashwert des letzten Datensatzes gesetzt [22]. Es könnte nun beispielsweise sein, dass sich in der Datenbank von Alice der Datensatz i verändert hat. Um nun effizient Datenbankänderungen zwischen Replikas auf Übereinstimmung zu prüfen, berechnet Alice die Hashwerte, die hierarchisch mit Datensatz i verbunden sind, neu. Am Ende dieser Berechnungen steht ein neuer, finaler Datensatz. Diesen sendet Alice an Bob (etwa in signierter Form, sodass der Hashwert nicht unbemerkt verändert werden kann). Ausgehend von dem auch in Bobs Datenbank modifizierten Datensatz i berechnet er die Hashwerte bis zum finalen Hashwert neu. Im finalen Schritt überprüft Bob letztlich, ob der eigene finale Hashwert dem erhaltenen Hashwert von Alice aus der Replika-Datenbank entspricht.

4.9

Asymmetrische Kryptografie

Im Unterschied zu symmetrischen Verfahren, bei denen mit demselben Schlüssel verschlüsselt wie entschlüsselt wird, werden bei einem asymmetrischen Verfahren beide

4.9 Asymmetrische Kryptografie

153

Schlüssel getrennt. Alice verschlüsselt eine Nachricht an Bob mit dem öffentlichen Schlüssel (Public Key) kpub von Bob. Mit dem privaten Schlüssel (Private Key) kpriv entschlüsselt Bob diese Nachricht wieder: C = E(Kpub , M) und M = D(Kpriv , C). Der öffentliche Schlüssel kann bekannt gegeben werden, während der private Schlüssel geheim bleibt. Für ein symmetrisches Verschlüsselungsverfahren mit N Teilnehmern werden N  N ·(N −1) Schlüssel benötigt. Im Falle der Pubic-Key-basierten Kryptografie werden 2 = 2 hingegen nur N Schlüsselpaare benötigt – jeweils bestehend aus einem Private Key und einem Public Key. In der Regel benötigt Public-Key-Kryptografie allerdings längere Schlüssel und ist langsamer als symmetrische Kryptografie.

4.9.1

Schlüsselaustausch

Bei einem symmetrischen Algorithmus schickt Alice ihren Schlüssel an Bob oder vice versa. Anschließend verwenden Alice und Bob denselben Schlüssel für die Ver- und Entschlüsselung der Kommunikation untereinander. Bei einem asymmetrischen Algorithmus schickt Alice ihren öffentlichen Schlüssel kAlice−pub an Bob und Bob schickt seinen öffentlichen Schlüssel kBob−pub an Alice. Die jeweils privaten Schlüssel bleiben geheim und somit jeweils nur ihrem Eigentümer zugänglich. Sowohl bei symmetrischen als auch bei asymmetrischen Algorithmen erfolgt der Schlüsselaustausch über irgendeinen Kanal. Dieser Kanal kann unsicher sein, der Schlüssel kann daher ggf. abgefangen oder manipuliert werden.

4.9.1.1 Diffie-Hellman-Schlüsselaustausch Whitfield Diffie und Martin Hellman haben 1976 einen Algorithmus zum Austausch eines geheimen Schlüssels über einen unsicheren Kanal mithilfe von Public-Key-Kryptografie vorgestellt. Heute bezeichnet man das zugehörige Verfahren als Diffie-Hellman-Schlüsselaustausch, wobei auch oft die Abkürzung DH verwendet wird.

Diffie-Hellman oder Diffie-Hellman-Merkle? Laut Hellman sollte der Algorithmus eigentlich nicht als Diffie-Hellman-, sondern als Diffie-Hellmen-Merkle-Schlüsselaustausch bezeichnet werden. Das folgende Zitat aus einem Aufsatz von Hellman in Communications of the ACM (2017) erläutert dies: In May 1976, Diffie and I developed the first practical, unclassified system for public key exchange, publishing both it and the public key cryptosystem concept in our paper ,New Directions in Cryptography‘ in IEEE Transactions on Information Theory, November 1976. That public key exchange system is widely known as Diffie-Hellman

(Fortsetzung)

154

4 Einführung in die Kryptografie

Key Exchange, but somewhat ironically, it is an implementation of Merkle’s public key distribution system concept, not our public key cryptosystem concept. I therefore refer to it as the "Diffie-Hellman-Merkle Key Exchange [9].

Tatsächlich reichte der damalige Student Merkle seinen Aufsatz bereits vor Diffie und Hellman zur Begutachtung bei einer Zeitschrift ein. Durch Verzögerungen wurde sein Aufsatz allerdings erst später publiziert.

Beim Diffie-Hellman-Schlüsselaustausch gehen Alice und Bob folgendermaßen vor: 1. Alice und Bob einigen sich auf eine nicht geheime Primzahl p, die möglichst groß sein sollte, und einen ebenfalls nicht geheimen Wert g. 2. Alice wählt eine Zufallszahl x und sendet X = g x mod p an Bob. 3. Bob wählt eine weitere Zufallszahl y und sendet Y = g y mod p an Alice. 4. Alice berechnet k1 = Y x mod p. 5. Bob berechnet k2 = Xy mod p. Nun sind x und y geheim (private Schlüssel) und (X, Y, g, p) öffentlich. Der Clou liegt darin, dass k1 = k2 , denn k1 = k2 = Y x mod p = g xy mod p = Xy mod p. Die Sicherheit des Diffie-Hellman-Schlüsselaustauschs liegt darin, dass ein Angreifer, der alle Daten des unsicheren Kanals sieht, nur die Werte (X, Y, g, p) sehen kann, jedoch nicht (x, y). Die Berechnungen werden dabei in Zp ausgeführt. Das klassische Anwendungsszenario für den Diffie-Hellman-Schlüsselaustausch ist das typisches Verschlüsselungsverfahren im Internet. Asymmetrische Kryptografie ist im Vergleich zu symmetrischen Verfahren recht langsam. Der Diffie-HellmanSchlüsselaustausch wird in einem solchen Verfahren verwendet, um einen Sitzungsschlüssel für eine schnelle symmetrische Verschlüsselung über einen unsicheren Kanal auszutauschen. Beispielsweise könnte das Verfahren von Diffie und Hellman eingesetzt werden, um einen AES-Schlüssel zu übertragen, der anschließend für die Verschlüsselung der Verbindung verwendet wird.

4.9.1.2 Finden von Primzahlen Ein Kernbestandteil des Diffie-Hellman-Algorithmus sind Primzahlen. Es stellt sich jedoch die Frage, wie auf einem Computer eigenltich Primzahlen gefunden werden können. Tatsächlich sind Primzahlen auch für andere Algorithmen bedeutsam, etwa für den RSA-Algorithmus. Aus diesem Grund ist es von Belang, sich zumindest grundlegend mit dem Finden von Primzahlen zu befassen. Eine einfache für die Primzahlgeneierung angewandte Vorgehensweise ist das Sieb des Eratosthenes. Das Verfahren geht so vor, dass zunächst eine Liste s mit n = |s| Elementen angelegt wird. Jedes Element in s steht für eine Zahl. Element 1 steht dabei für die Zahl 1,

4.9 Asymmetrische Kryptografie

155

Element 2 für die Zahl 2 usw. Potenziell gilt zunächst jede dieser Zahlen, außer die 1, als eine Primzahl. Beginnend mit der 2 wird jedes Element weitere Element in s dahingehend geprüft, ob es eine Primzahl ist (also durch eine Zahl außer sich selbst und 1 ohne Rest dividiert werden kann). Alle Vielfachen der gefundenen Primzahlen werden als nicht prim markiert. Beispiel. Angenommen, s habe in einem Programm n = 10 Elemente (1–10). Das Programm setzt jedes Element außer dem ersten auf den Wert 1. Ist ein Element mit einer 1 markiert, so bedeutet dies, dass es einer potenziellen Primzahl entspricht. Zum Start ist s = 0111111111. Die 2 ist eine Primzahl. Das Verfahren geht nun so vor, dass es mit der Zahl 2 beginnt. Jeden Wert von s, der sich durch 2 ohne Rest dividieren lässt, markiert das Programm als nicht prim. Entsprechend ist s nun 0110101010. Die nächste Zahl, die das Programm nun auf ihre Primzahleigenschaft testet, ist die 3. Da sie sich nicht durch die bereits gefundenen Primzahl (2) oder eine andere bereits getestete Zahl teilen lässt (also nicht 0 ist), ist 3 eine Primzahl. Erneut streicht das Programm jedes Vielfache von 3 aus s, womit s = 0110101000 übrig bleibt. Das Programm testet die 4, sie ist in s mit einer 0 markiert und daher nicht prim. Die Vielfachen von 4 (also die 8) wurden bereits als nicht prim markiert (Vielfache der Primzahl 2). Danach testet das Programm die 5, die durch keine der bereits gefundenen Primzahlen teilbar ist und somit selbst prim ist. Das einzige Vielfache von 5 in s (nämlich 10) wurde bereits als nicht prim markiert (als Vielfaches von 2). Die 6 ist ebenfalls als nicht prim markiert. Die 7 stellt sich als Primzahl heraus, doch es gibt aufgrund der geringen Größe von s kein Vielfaches von 7 zu markieren. Die Zahlen 8, 9 und 10 sind bereits als nicht prim markiert. Alle Primzahlen in s (2,3,5,7) sind nun markiert und bekannt.

4.9.2

Rivest-Shamir-Adleman-Algorithmus (RSA)

RSA (benannt nach Ron Rivest, Adi Shamir und Leonard Adleman) ist sicherlich eines der berühmtesten Verfahren der Public-Key-Welt. Bei RSA wird zunächst ein Schlüsselpaar pro Teilnehmer generiert und dann mithilfe dieses Schlüsselpaars sicher kommuniziert. Die Sicherheit von RSA beruht auf dem Problem der Primfaktorzerlegung bei sehr großen Primzahlen in endlichen Mengen. Diese ist nämlich äußerst aufwendig. Besondere Bedeutung kommt bei RSA der ϕ-Funktion zu. Die ϕ(n)-Funktion gibt für die Zahl n an, wie viele natürliche Zahlen aus dem Bereich 1 . . . n − 1 teilerfremd zu n sind. Zum Beispiel ist ϕ(6) = 2, denn 1 und 5 sind teilerfremd. Entsprechend gilt ϕ(3) = 2, denn 1 und 2 sind teilerfremd.

156

4 Einführung in die Kryptografie

Für zwei teilerfremde Zahlen a und b gilt, dass ϕ(a) · ϕ(b) = ϕ(a · b) ist. Wenn n eine Primzahl ist, dann ist ϕ(n) = n − 1. Falls n = p · q mit p, q als Primzahlen, dann gilt ϕ(n) = (p − 1)(q − 1). Für a, n ∈ N, a < n gilt zudem: a 1 mod ϕ(n) = a mod n und damit: a b = a mod n, wenn b − 1 ein Vielfaches von ϕ(n) ist [10, 22]. Für ein x a = b mod n gilt: Wenn a und ϕ(n) teilerfremd sind, dann kann mit dem erweiterten euklidischen Algorithmus c = a −1 mod ϕ(n) berechnet werden. c ist dabei die Inverse zu a für modϕ(n). Dies lässt sich letztlich wiederum zu x = bc mod n umformen [22]. Beide Seiten können mithilfe von c erweitert werden: (x a )c mod ϕ(n) = bc mod ϕ(n) mod n. Anschließend lässt sich die rechte Seite zu (x a )c mod ϕ(n) = bc mod n vereinfachen [22]. Da ac = 1 mod ϕ(n), ergibt die linke Seite: x 1 mod ϕ(n) = bc mod n, und dies ist wiederum x = bc mod n [22]. Wenn ggT (a, n) = 1 ist, dann gibt es ein x, das invers zu a ist und daher: x = a −1 mod n. Mithilfe des erweiterten euklidischen Algorithmus kann dieses x berechnet werden.

4.9.2.1 RSA-Schlüsselgenerierung Die Generierung der RSA-Schlüsselpaare erfolgt in fünf Schritten [10, 26]: Zunächst generiert Alice zwei große Primzahlen, üblicherweise als p und q bezeichnet. Um p und q zu generieren, verwendet Alice einen PRNG.13 Im zweiten Schritt berechnet Alice n = p · q sowie ϕ(n) = (p − 1)(q − 1) und im dritten Schritt wählt sie ein e ∈ Z mit 1 < e < ϕ(n). Damit ist e kein Vielfaches von ϕ(n), das heißt a b = a mod n ist bei b − 1 = ϕ(n) nicht möglich. Außerdem wählt Alice ein e, das teilerfremd zu ϕ(n) sein muss (es gilt, anders formuliert, ggT (e, ϕ(n)) = 1). Die Werte (n, e) bilden den öffentlichen Schlüssel. Im vierten Schritt muss Alice noch den geheimen Schlüssel d berechnen. Dazu formuliert sie ed = 1 mod ϕ(n) zu d = e−1 mod ϕ(n) um. Für die Berechnung verwendet Alice den erweiterten euklidischen Algorithmus. Im fünften Schritt liegen (e, n) als öffentlicher und (d, n) als privater Schlüssel vor. Die Werte p und q vernichtet Alice aus Sicherheitsgründen. 4.9.2.2 RSA-Anwendung Mithilfe der generierten Schlüsselpaare lässt sich eine Nachricht nun recht einfach verschlüsseln: C = E(M) = M e mod n. Die Entschlüsselung von C erfolgt mit M = D(C) = C d mod n. Größere Nachrichten müssen dabei blockweise verarbeitet werden.

13 Um zu testen, ob die Zufallszahlen prim sind, können der Fermat-Test und der Miller-Rabin-Test verwendet werden.

4.11 Zusammenfassung

4.10

157

Digitale Signaturen

Eine digitale Signatur (digitale Unterschrift, engl. Digital Signature) ist den bereits erläuterten Message Authentication Codes (MAC) sehr ähnlich. MAC sind Hashfunktionen, die mit einer symmetrischen Chiffre kombiniert werden. Digitale Signaturen verwenden anstelle der symmetrischen Chiffre hingegen eine asymmetrische Chiffre. Eine digitale Signatur besitzt eine Reihe von Eigenschaften [10]: • Sie ist fälschungssicher (nicht durch andere Subjekte erzeugbar). • Sie ist nicht wiederverwendbar (eine Signatur eines digital unterschriebenen Dokuments kann nicht auf andere Dokumente übertragen werden). • Sie macht ein unterschriebenes Dokument unveränderbar (ansonsten gilt die Signatur nicht mehr). • Sie ist bindend (Schutzziel der Verbindlichkeit, siehe Abschn. 3.2). Bei einer digitalen Signatur wird ein zu signierendes Dokument M mit dem privaten Schlüssel KAlice−priv von Alice unterschrieben. Ein signiertes Dokument ist das Tupel (M, EKAlice−priv (M)). Als Chiffre kann an dieser Stelle beispielsweise RSA dienen. Die Signatur wird von Bob mithilfe des öffentlichen Schlüssel von Alice KAlice−pub überprüft. Dazu berechnet er M  der signierten Dokumentversion: M  = DKAlice−pub (EKAlice−priv (M)) Anschließend prüft Bob, ob M  = M. Im vorherigen Fall würde M zusammen mit dem verschlüsselten M übertragen werden. Dies wäre ein doppelter Aufwand. Tatsächlich signiert Alice in der Praxis nur den Hashwert von M, sodass sie nur (M, EKAlice−priv H (M)) überträgt. Denkbar wäre es etwa, ein Dokument mit SHA-3 zu hashen und anschließend mit RSA zu signieren. Bob überprüft folglich analog, ob gilt, dass DKAlice−pub (EKAlice−priv H (M)) = H (M  ).

4.11

Zusammenfassung

Kryptografie muss als Dual-use Good verstanden werden. Sie basiert weitestgehend auf Algorithmen, die Schlüssel verwenden, um Daten zu ver- und entschlüsseln. Historische Chiffren können relativ leicht gebrochen werden und die Auseinandersetzung mit diesen historischen Chiffren erleichtert das Verständnis moderner Kryptografie. Moderne Verschlüsselungsverfahren werden von Computern ausgeführt. Stromchiffren wie RC4 und A5/1 verschlüsseln einen Strom von Klartextbits mithilfe eines Schlüsselstroms, der durch

158

4 Einführung in die Kryptografie

einen Zufallszahlengenerator erzeugt wird. Zufallszahlengeneratoren müssen möglichst unvorhersagbaren Output liefern und dienen insbesondere der Geneierung von Schlüsseln. Blockchiffren wie DES, 3DES und AES verschlüsseln im Gegensatz zu Stromchiffren ganze Blöcke von Klartext. Sie kennen verschiedene Modi, in denen sie betrieben werden können, etwa Electronic Code Book (ECB) oder Ciher Block Chaining (CBC). Eine informationstheoretische Betrachung von Kryptografie ermöglicht zu verstehen, warum es mehrere Schlüssel geben kann, die aus einem Chiffretext einen plausiblen Klartext erzeugen. Tatsächlich gibt es allerdings nur einen echten Klartext. Für einige Szenarien, etwa Brute-Force-Angriffe auf Passwortdateien, ist es allerdings irrelevant, ob der ursprüngliche Klartext gefunden wurde, oder ob es dem Angreifer nur gelungen ist, einen Klartext M  zu finden, der denselben Hashwert wie der ursprüngliche Klartext erzeugt. Hashfunktionen wie SHA und MD5 sind Einwegfunktionen, die eine Prüfsumme eines Inputs errechnen. Dieser Hashwert kann zur Überprüfung auf Veränderungen an Daten dienen und in Verbindung mit Chiffren zu einem Message Authentication Code werden. Diverse weitere praktische Anwendungsgebiete für Hashfunktionen existieren. Während symmetrische Kryptografie denselben Schlüssel für die Ver- und Entschlüsselung verwendet, kann bei asymmetrischer Kryptografie mit Schlüsselpaaren gearbeitet werden. Einer der beiden Schlüssel eines Schlüsselpaars dient zum Verschlüsseln, der andere zum Entschlüsseln einer Nachricht. Mithilfe des Diffie-Hellman-Merkle-Verfahrens kann ein Schlüssel über einen unsicheren Datenkanal ausgetauscht werden. Durch Kombination von Hashfunktionen mit asymmetrischen Chiffren wie RSA lassen sich digitale Signaturen erzeugen – ein Sender unterschreibt sie und ein Empfänger ist in der Lage, die Unterschrift des Senders zu überprüfen. Sie werden sich vielleicht fragen, was passieren sollte, wenn plötzlich Quantencomputer vor der Tür stehen und unsere aktuellen Kryptosysteme, etwa RSA, brechen können. Aus diesem Grund möchte ich mit einem weiteren Zitat aus einem Ende 2017 in Communications of the ACM erschienenenden Aufsatz von Hellman schließen: Given the impact another major advance in factoring would have on the global economy, I have argued that it would be prudent to already have backup systems for both key exchange and digital signatures in place and in use. For key exchange, two keys could be generated and hashed or XORed. One key would be produced by public key exchange and the other by the backup system. Such a system would provide seamless security even if one of the methods of key exchange were compromised [9].

4.12

Weiterführende Literatur

Dieses Kapitel beinhaltet eine prägnante Einführung in die Grundzüge der Kryptografie. Das nächste Kapitel betrachtet fortgeschrittene Themen der Kryptografie, insbesondere Anwendungsgebiete. Sollten Sie sich über dieses Kapitel hinaus tiefer mit den Grundlagen der Kryptografie beschäftigen wollen, so lege ich Ihnen die hervorragenden Bücher von

4.13 Übungsaufgaben

159

Beutelspacher et al. [5], Spitz et al. [26], Schmeh [22], Schneier [24] und Ertel [10] ans Herz. Ein hervorragendes Werk, das die geschichtliche Entwicklung der Kryptografie beschreibt, ist The Codebreakers von Kahn [15].

4.13

Übungsaufgaben

1. Welche Folgen hätte ein juristisches Verbot von Kryptografie? 2. Ist das Prinzip von Kerckhoffs Ihrer Meinung nach praxisrelevant? 3. Für zwei Teilnehmer wird bei einer symmetrischen Gruppenkommunikation ein Schlüssel benötigt. Für 100 Teilnehmer werden bereits 4950 Schlüssel benötigt. Können Sie sich Szenarien vorstellen, bei denen symmetrische Schlüssel nicht mehr praktikabel sind? 4. Verschlüsseln Sie einen eigenen Satz (max. 40 Zeichen) mit einer Caesar-Chiffe und wählen Sie ein beliebiges k. Permutieren Sie Ihren Schlüssel nicht. 5. Entschlüsseln Sie Ihren zuvor verschlüsselten Text. 6. Ist die Caesar-Chiffre ein symmetrisches oder ein asymmetrisches Verfahren? Ist es monoalphabetisch? Wenn ja: Weshalb? 7. Gibt es einen Zusammenhang zwischen dem verwendeten Alphabet und der Sicherheit einer Caesar-Chiffre? 8. Verschlüsseln Sie den Text ‘HALLO KATZE’ mit der Vigenère-Chiffre und dem Schlüssel ‘FELIX’. 9. Entschlüsseln Sie den Text aus der vorherigen Aufgabe wieder und überprüfen Sie, ob Sie zum korrekten Ergebnis gelangen. 10. Nutzen Sie den Kasiski- und den Friedman-Angriff, um die Schlüssellänge für den folgenden Chiffretext zu ermitteln. htay shz vwz cwuajjzau kapfa bzn hmo kwn dwoawjasojza ggc, usyo vay rapl ohz quv apden xkylhpwb, zhnhfc hdejw wbx Wie stark unterscheiden sich Ihre Ergebnisse in beiden Fällen? Beim Kasiski-Angriff erhalten Sie mehrere plausible Resultate. Weshalb? 11. Die Schlüssellänge ist Ihnen durch das Lösen der vorherigen Aufgabe bekannt (sie beträgt drei Zeichen). Dechiffrieren Sie nun den Text. Mit Kenntnis dieses Texts: Wie erklären Sie sich die leichte Abweichung der tatsächlichen Schlüssellänge zum Ergebnis des Friedman-Angriffs? Hinweis: Es handelt sich um einen Auszug aus „Alice im Wunderland“. 12. Für Ihr Studium an der Hochschule Worms verlässt Paula ihr Elternhaus im Schwarzwald und zieht nach Worms. Zwei Tage nach Ankunft läuft die Gültigkeit von Paulas alter EC-Karte ab. Zum Glück hatte Paula die neue EC-Karte von ihrer Bank bereits erhalten und mit nach Worms genommen. Die PIN wurde allerdings zeitversetzt in den Schwarzwald geschickt. Nun muss Paula dringend Geld von ihrem Bankkonto abheben.

160

4 Einführung in die Kryptografie

Paula und ihre Mutter haben zuvor einen Schlüssel für ein One-Time-Pad ausgetauscht und können Paulas PIN somit auf sichere Weise über das Telefon kommunizieren. Denken Sie sich einen Schlüssel und eine PIN aus und führen Sie die gesicherte Kommunikation auf Papier durch. Was lässt sich über den vorher ausgetauschten Schlüssel sagen? 13. Sie haben bereits gelernt, was eine Stromchiffre ist, und auch, dass die Vernam-Chiffre eine solche Stromchiffre ist. Sind die folgenden Chiffren ebenfalls Stromchiffren? • Vigenère • Caesar Begründen Sie Ihre Antworten. 14. Bieten Vernam-, RC4- beziehungsweise A5/1-Chiffre die folgenden Eigenschaften? • Vertraulichkeit • Verfügbarkeit • Integrität • Anonymität Begründen Sie Ihre Antworten. 15. Ein PRNG liefert die folgenden Werte – halten Sie diesen PRNG für sicher? 101010001011101001010 100100001010111010101 001011100001010100010 101010001011101001010 100100001010111010101 001011100001010100010 101010001011101001010 100100001010111010101 001011100001010100010 Begründen Sie auch hier wieder Ihre Antwort. 16. Wie setzt DES Konfusion und Diffusion um? 17. Fügen Sie für die linke Tabelle die notwendigen Parity-Bits ein und prüfen Sie die rechte Tabelle auf Korrektheit: 01100|_ 00110|_ 10100|_ 10100|_ 10001|_ _____|_

0001|1 0010|1 0101|0 1000|0 ----+1100|0

4.13 Übungsaufgaben

161

18. Wie wird beim CTR-Mode dechiffriert? 19. Was können Sie tun, um die Unizitätsdistanz positiv zu beeinflussen, ohne die Schlüssellänge anzupassen? 20. Halten Sie die Unizitätsdistanz für praxisrelevant? Begründen Sie Ihre Antwort. 21. Berechnen Sie U für eine Caesar-Chiffre. 22. Erstellen Sie eine Rainbow Table. Die Klartexte sollen eine Länge von zwei Zeichen haben und die Hashfunktion soll nur jeweils modular die Zeichen des Klartexts inkrementieren. Die Reduktionsfunktion Ri soll aus einem Zwei-Zeichen-Hashwert (h1 , h2 ) den Wert (h1 + i, h2 + i) machen (optional können Sie die Werte modulo 26 berechnen, um so bei Buchstaben zu bleiben). 23. Suchen Sie in Ihrer Rainbow-Table nach einem Hashwert, der in der letzten Spalte steht und nach einem Hashwert, der zwar enthalten ist, aber nicht in der letzten Spalte vorkommt. 24. Finden Sie heraus, mit welchem Algorithmus Ihr Betriebssystem Passwörter speichert. Unter Linux können Sie dazu insbesondere die Manpage von crypt verwenden. Wird ein Salt verwendet? 25. Berechnen Sie ϕ(5), ϕ(6) und ϕ(97). Hinweis: Unter Linux/Unix/BSD können Sie mithilfe von primes herausfinden, ob eine Zahl eine Primzahl ist. Unter anderen Betriebssystemen können Sie das folgende kurze C-Programm nutzen, um Primzahlen aufzlisten. # i n c l u d e < s t d i o . h> # i n c l u d e < s t d l i b . h> i n t main ( i n t a r g c , char ∗ a r g v [ ] ) { i n t high , i , q , ∗ primes ; i f ( argc < 2) { fprintf ( stderr , " A u f r u f : %s [ E n d z a h l ] \ n " , a r g v [ 0 ] ) ; return 1; } i f ( ! ( high = a t o i ( argv [ 1 ] ) ) ) { fprintf ( stderr , " Positiver Integer benoetigt . \ n" ) ; return 1; } i f ( ! ( primes = c a l l o c ( s i z e o f ( int ) , high ) ) ) { f p r i n t f ( s t d e r r , " c a l l o c () − F e h l e r \ n " ) ;

162

4 Einführung in die Kryptografie

return 1; } f o r ( i = 2 ; i < h i g h ; i ++) primes [ i ] = 1; f o r ( i = 2 ; i < h i g h ; i ++) { f o r ( q = 2 ; q < i ; q ++) { i f ( ( i % q ) == 0 ) primes [ i ] = 0; } } f o r ( i = 2 ; i < h i g h ; i ++) i f ( p r i m e s [ i ] == 1 ) p r i n t f ( "%i \ n " , i ) ; return 0; } 26. Steigern Sie die Performance des obigen C-Programms, indem Sie bereits als nicht prim identifizierte Zahlen nicht nochmals überprüfen. Wie groß ist Ihr dadurch erzielter Performancegewinn beim Durchsuchen der Zahlen bis 10.000? (Hinweis: Lenken Sie die Ausgabe des Programms zur Performancemessung auf eine Datei oder – unter Linux/Unix/BSD – auf /dev/null um und verwenden Sie einen Zeitmesser wie time ./IhrProgramm.) 27. Vergleichen Sie die Performance Ihres C-Codes mit der Performance von primes. 28. Berechnen Sie ϕ(37) · ϕ(89).

Literatur 1. Aftenposten: Sources: We were pressured to weaken the mobile security in the 1980s (2014). https://www.aftenposten.no/verden/i/Olkl/Sources-We-were-pressured-to-weaken-themobile-security-in-the-80s. Zugegriffen am 01.06.2018 2. AlFardan, N.J., Bernstein, D.J., Paterson, K.G., Poettering, B., Schuldt, J.C.N.: On the Security of RC4 in TLS. In: Proceedings of 22nd USENIX security symposium, Washington, S. 305–320. USENIX Association (2013) 3. Baranetsky, D.V.: Encryption and the press clause. NYU JIPEL 6(2) (2017). http://jipel.law.nyu. edu/vol-6-no-2-1-baranetsky/. Zugegriffen am 01.06.2018 4. Bellare, M., Canetti, R., Krawczyk, H.: Keying hash functions for message authentication. In: Proceedings of Advances in Cryptology – Crypto ’96. LNCS Bd. 1109. Springer, Berlin (1996) 5. Beutelspacher, A., Neumann, H.B., Schwarzpaul, T.: Kryptografie in Theorie und Praxis, 2. Aufl. Vieweg+Teubner, Wiesbaden (2010) 6. Bishop, M.: Computer Security. Art and Science. Addison Wesley, Boston (2003)

Literatur

163

7. Buchmann, J.: Einführung in die Kryptographie, 2., erw. Aufl. Springer, Berlin (2001) 8. Bundesministerium für Sicherheit in der Informationstechnik (BSI): Die Lage der IT-Sicherheit in Deutschland 2017, BSI (2017) 9. Hellman, M.E.: Cybersecurity, nuclear security, Alan turing, and illogical logic. Commun. ACM (CACM) 60(12), 52–59 (2017). ACM. https://cacm.acm.org/magazines/2017/12/ 223042-cybersecurity-nuclear-security-alan-turing-and-illogical-logic/fulltext. Zugegriffen am 01.06.2018 10. Ertel, W.: Angewandte Kryptographie, 2. Aufl. Fachbuchverlag, Leipzig (2003) 11. Ferguson, N., Schneier, B., Kohno, T.: Cryptography Engineering. Wiley, New York (2010) 12. Hartlieb, S., Unger, L.: Skriptum „Mathematische Grundlagen der Kryptografie“, FernUniversität in Hagen, Version von (2010) 13. Hellman, M.E.: An extension of the Shannon theory approach to cryptography. IEEE Trans. Inf. Theory IT-23(3), 289–294 (1977) 14. John the Ripper Password Cracker (2017). http://www.openwall.com/john/. Zugegriffen am 01.06.2018 15. Kahn, D.: The Codebreakers. The Story of Secret Writing. Scribner, New York (1996) 16. Keller, J., Spenger, G., Wendzel, S.: Enhanced Ant Colony-inspired Parallel Algorithm to Improve Cryptographic PRNGs. JCSM 6(2) (2017). http://riverpublishers.com/journaldownload. php?file=RP_Journal_2245-1439_623.pdf. Zugegriffen am 01.06.2018 17. Krawczyk, H., Bellare, M., Canetti, R.: RFC 2104 – HMAC: Keyed-Hashing for Message Authentication, IETF (1997) 18. Lingmann, T.: Datenverschlüsselung. Sichere Kommunikation für Linux und BSD. Computer & Literatur Verlag, Böblingen (2002) 19. Menezes, A.J., van Oorschot, P.C., Vanstone, S.A.: Handbook of Applied Cryptography. CRC Press, Boca Raton (1996) 20. Plötner, J., Wendzel, S.: Praxisbuch Netzwerksicherheit, 2. Aufl. Galileo Press, Bonn (2007) 21. Popov, A.: Prohibiting RC4 Cipher Suites – RFC 7465, IETF (2015) 22. Schmeh, K.: Kryptografie: Verfahren – Protokolle – Infrastrukturen, iX-Edition. dpunkt-Verlag, Heidelberg (2013) 23. Schönfeld, D., Klimat, H., Piotraschke, R.: Informations- und Kodierungstheorie, 4. Auflage. Springer-Vieweg, Wiesbaden (2012) 24. Schneier, B.: Angewandte Kryptographie, 5. Aufl. Addison-Wesley, Bonn (1996) 25. Schneier, B.: Secrets and Lies: Digital Security in a Networked World. Wiley, Somerset, Wiesbaden (2011) 26. Spitz, S., Pramateftakis, M., Swoboda, J.: Kryptographie und IT-Sicherheit, 2. Aufl. Vieweg+Teubner, Wiesbaden (2011) 27. Stevens, H.: Hans Peter Luhn and the Birth of the Hashing Algorithm. In: IEEE Spectrum, Heft 02.18, S. 42–47. IEEE (2018). http://spectrum.ieee.org/analogcomputer0218. Zugegriffen am 01.06.2018 28. Turner, S., Chen, L.: RFC 6151 – Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms, IETF (2011) 29. Wagstaff, S.S. Jr.: Cryptoanalysis of Number Theoretic Ciphers. Chapman & Hall/CRC, Boca Raton (2003) 30. Wätjen, D.: Kryptographie. Grundlagen, Algorithmen, Protokolle. Spektrum, Berlin (2004) 31. Wikipedia: Buchstabenhäufigkeit. https://de.wikipedia.org/wiki/Buchstabenh%C3%A4ufigkeit. Zugegriffen am 01.06.2018 32. Wikipedia: Geburtstagsparadoxon (2017). https://de.wikipedia.org/wiki/Geburtstagsparadoxon. Zugegriffen am 01.06.2018

5

Weiterführende Themen der Kryptografie

Too many engineers consider cryptography to be a sort of magic security dust that they can sprinkle over their hardware or software, and which will imbue those products with the mythical property of ‘security’. Too many consumers read product claims like ‘encrypted’ and believe in the same magic security dust. – Niels Ferguson und Bruce Schneier (2003)

Zusammenfassung

Dieses Kapitel führt in die Grundlagen der Public Key Infrastructure (PKI) und der Virtuellen Privaten Netzwerke (VPN), insbesondere IPSec und TLS, ein. Anschließend werden die technischen Grundzüge des Onion Routings betrachtet und das Gebiet der visuellen Kryptografie vorgestellt. Das Kapitel schließt mit einer kurzen Betrachtung der drei Gebiete Secure Multi-Party Computation, homomorphe Verschlüsselung und Aufteilung von Geheimnissen.

5.1

Einführung

Das vorherige Kapitel führte in die Grundlagen der Kryptografie ein. Aufbauend auf diesen Grundlagen befasst sich dieses Kapitel nun mit Themen, bei denen die Kryptografie entweder angewandt wird (PKI, VPNs, Onion Routing) oder bei denen das bisherige Wissen um Einblicke in Spezialthemen vertieft wird (visuelle Kryptografie, Secure MultiParty Computation, homomorphe Verschlüsselung und geteilte Geheimnisse).

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2018 S. Wendzel, IT-Sicherheit für TCP/IP- und IoT-Netzwerke, https://doi.org/10.1007/978-3-658-22603-9_5

165

166

5.2

5 Weiterführende Themen der Kryptografie

Public Key Infrastructure

Es gibt verschiedene Probleme beim Einsatz asymmetrischer Kryptografie. Schmeh nennt in sinem Standardwerk zur Kryptografie die folgenden Probleme [1]: 1. Authentizität der Schlüssel: Mallory könnte Bob einen Schlüssel für Alice untermogeln, der eigentlich Mallorys Schlüssel ist. Beispielsweise würde sich dies mit einem MitMAngriff oder durch Verbreitung des falschen Schlüssels erreichen lassen. 2. Sperrung von Schlüsseln: Mallory hat den privaten Schlüssel von Alice gestohlen. Angenommen, Alice hat diesen Angriff bemerkt und einen neuen Schlüssel generiert. Wie verhindert man nun, dass Bob nicht mehr den alten Schlüssel von Alice verwendet? 3. Verbindlichkeit: Alice kann prinzipiell im Nachhinein abstreiten, eine bestimmte Nachricht verschickt zu haben. 4. Policy-enforcement: Eine Organisation sollte beispielsweise festlegen können, dass jeder Mitarbeiter nur ein Schlüsselpaar erhält oder alle Schlüssel zentral registriert werden müssen. Diese Probleme können durch eine sogenannte Public Key Infrastructure (PKI) adressiert werden.

5.2.1

Digitale Zertifikate und PKI-Bestandteile

Die Kernkomponente einer PKI sind ihre digitalen Zertifikate (auch Public-KeyZertifikate). Ein solches Zertifikat stellt im Wesentlichen den öffentlichen Schlüssel eines Teilnehmers (einer Person, eines Dienstes/Servers) dar, der von einer vertrauenswürdigen Instanz signiert wurde [2]. Ein digitales Zertifikat enthält Informationen über seinen Besitzer (und seinen öffentlichen Schlüssel), seinen Aussteller und eine Signatur des Zertifikats durch seinen Aussteller; genauer gesagt handelt es sich dabei um folgende Informationen [1, 2]: • • • • • • •

Name des Inhabers Certificate Authority (CA), die das Zertifikat ausstellte öffentlicher Schlüssel der CA öffentlicher Schlüssel des Inhabers Seriennummer des Zertifikats Gültigkeitszeitraum Signatur der CA

Das Unterschreiben eines Zertifikats bezeichnet man als Zertifizieren. Zertifiziert wird ein Zertifikat von einer Zertifizierungsstelle (engl. Certification Authority, CA, oder auch Trust Anchor). Dabei ist es so, dass eine Organisation, etwa eine Firma oder

5.2 Public Key Infrastructure

167

eine Behörde, eine eigene Zertifizierungsstelle betreiben kann. Eine Zertifizierungsstelle signiert die jeweiligen Zertifikate, die ihr zugeordnet werden sollen. Eine Firma mit einer Zertifizierungsstelle kann folglich prinzipiell ihre eigenen Zertifikate für Mitarbeiter und für Dienste ausstellen. Außerdem kann eine Zertifizierungsstelle Listen für gesperrte Zertifikate erstellen (und signieren). Diese können beispielsweise verwendet werden, um kompromittierte Schlüssel von der weiteren Verwendung auszuschließen. Neben der Zertifizierungsstelle gibt es manchmal eine Certificate Registry, also eine Registrierungsstelle. Bei dieser können Benutzer Zertifikate beantragen und müssen sich dazu etwa mit ihrem Personalausweis authentisieren. Falls keine Certificate Registry vorhanden ist, können Benutzer ihre Zertifikate direkt bei der Zertifizierungsstelle beantragen. Die vorhandenen Zertifikate sowie die Sperrliste (engl. Certificate Revocation List) werden in einem Verzeichnis (Datenbank) abgelegt [3], die Certificate Repository genannt wird. Abb. 5.1 zeigt beispielhaft ein Zertifikat der Hochschule Worms. Dort sind oben genannte Komponenten ersichtlich: Das Zertifikat gehört zur Webseite moodle.hs-worms.de der Organisation „Hochschule Worms, University of Applied Sciences“. Das Zertifikat verfügt über eine Seriennummer und wurde von der Stelle „Regionales Hochschulrechenzentrum Kaiserslautern“ (RHRK-CA) ausgestellt. Die Gültigkeitsdauer ist auf etwa drei Jahre festgelegt. Ebenfalls ersichtlich sind die Hashwerte (SHA-256 und SHA-1). Doch woher weiß Bob, dass die angebliche Zertifizierungsstelle seiner Firma die echte ist? Woher weiß er, dass eine Signatur echt ist? Im Normalfall sieht die Lösung so aus, dass man den Schlüssel einer Zertifizierungsstelle (wie in Abb. 5.2 dargestellt) durch eine andere Zertifizierungsstelle (etwa eine Behörden-Zertifizierungsstelle) zertifizieren lässt. Das sich daraus ergebende Zertifikat wird auch CA-Zertifikat genannt. Damit verschiebt sich das Problem jedoch nur, da letztlich der höheren Instanz anstelle der eigenen Instanz vertraut werden muss. Theoretisch kann man sich jedoch einen Schlüssel am Telefon bestätigen lassen (der Mitarbeiter am Telefon kann natürlich trotzdem falsche Informationen liefern). Zertifikate sind hierarchisch zertifiziert. Das heißt, ein Zertifikat X wird durch eine Stelle Y zertifiziert. Deren Zertifikat wird wiederum durch eine Stelle Z zertifiziert usw. Am Ende der Hierarchie steht das Vertrauen in eine Organisation, deren Zertifikat von keiner höheren Instanz mehr zertifiziert wird. Dieses Zertifikat wird auch als Wurzelzertifikat (engl. Root Certificate) bezeichnet. Man spricht statt von einer Hierarchie auch von einer Zertifikationskette (engl. Chain of Trust) [2, 3]. Die Detailansicht im Browser (Abb. 5.2) verrät uns, dass das Zertifikat von moodle.hs-worms.de zwar in erster Instanz vom Regionalen Hochschulrechenzentrum Kaiserslautern ausgestellt wurde (RHRK-CA). Deren Zertifikat wurde aber wiederum durch die Deutsche Forschungsgemeinschaft (DFN) zertifiziert. Das DFN-Zertifikat wiederum wurde von der Deutschen Telekom zertifiziert. Das heißt, Benutzer müssen letztlich an irgendeiner Stelle anderen Instanzen vertrauen. Es gibt allerdings verschiedene Vertrauensmodelle, um dieses Vertrauen abzubilden. Auf den folgenden Seiten werden diese Vertrauensmodelle betrachtet. Dabei möchte Alice

168

5 Weiterführende Themen der Kryptografie

Abb. 5.1 Hochschule Worms – HTTPS-Zertifikat für den Moodle-Dienst

sicher mit Bob kommunizieren (sie benötigt also Bobs Schlüssel). Außerdem möchte Alice sicher mit Carsten und eventuell mit Daniela kommunizieren, denen sie allerdings nicht vertraut.

5.2.2

Vertrauensmodelle

Es gibt eine Reihe von Vertrauensmodellen samt Abwandlungen und unterschiedlichen Bezeichnungen für dieselben Modelle. Im Folgenden werden besonders bedeutsame und zugleich grundlegende Modelle besprochen, auf denen letztlich auch die weiterführende Modelle aufbauen. Im einfachsten Modell, genannt Direct Trust, siehe Abb. 5.3, gibt Bob gegenüber Alice an, dass sein Schlüssel von ihm selber stammt. Bob kann seinen Schlüssel folglich auch selber signieren, was aber keinen Vorteil bringt. Das Modell ist gegenüber Man-in-the-

5.2 Public Key Infrastructure

169

Abb. 5.2 Zertifikatsdetails für das HTTPS-Zertifikat für den Moodle-Dienst

Abb. 5.3 Direct Trust

Middle-Angiffen verwundbar, weil der Schlüssel unterwegs abgefangen werden kann [1]. Weiterhin kann Bob abstreiten, dass er Alice seinen Schlüssel geschickt hat und eine Policy ist ebenfalls nicht umsetzbar [1]. Im Anarchiemodell (engl. Web of Trust, siehe Abb. 5.4) verhält es sich bereits leicht anders. Hierbei signieren Personen/Systeme gegenseitig ihre Schlüssel, wenn sie sich vertrauen [1,3,4]. Vertraut nun Alice Bob, aber nicht Carsten, dann vertraut vielleicht Bob Carsten. Wenn Bob nun wiederum Carstens Schlüssel signiert, kann auch Alice indirekt Carsten vertrauen. Diese Verkettung lässt sich beliebig weiterführen. So kann Carsten

170

5 Weiterführende Themen der Kryptografie

beispielsweise den Schlüssel von Daniela signieren, der Alice doppelt indirekt vertrauen würde. Jeweils gilt, dass das Vertrauen, auch das indirekte, jeweils explizit und freiwillig erfolgen muss. Alice muss Carsten also nicht vertrauen, auch wenn Bob Carstens Schlüssel signiert hat. Jemand, der den Schlüssel eines anderen signiert, wird im Anarchiemodell auch als Introducer bezeichnet [2]. Ein Introducer ist also eine Person, die eine dritte Person anderen „vorstellt“, also ein gewisses Vetrauen impliziert. Problematisch ist, dass dieses Modell nur bei kleinen Gruppen anwendbar ist [4], da längere Ketten von indirektem Vertrauen eben wenig vertrauenswürdig sind [2] und auch bei diesem Modell keine Policy umgesetzt werden kann. Die Sperrung von kompromittierten Schlüsseln ist ebenfalls problematisch [1]. Zum Einsatz kommt das Anarchiemodell insbesondere bei der bekannten Software PGP (beziehungsweise GnuPG). Im hierarchischen oder browserorientierten Vertrauensmodel1 (engl. hierarchical trust, siehe Abb. 5.5) gibt eine Zertifizierungsstelle, die Zertifikate einer Organisation ausstellt, also etwa Schlüssel der Mitarbeiter und Netzwerkdienste signiert. Alle Teilnehmer vertrauen dieser Zertifizierungsstelle. Der öffentliche Schlüssel der Zertifizierungsstelle wird dabei verwendet, um zu zertifizierende Schlüssel zu überprüfen (signiert mit dem privaten Schlüssel der Zertifizierungsstelle). Alice kann ihren Schlüssel somit von der Zertifizierungsstelle zertifizieren lassen und Bob kann den zertifizierten Schlüssel von Alice mithilfe des öffentllichen Schlüssels der Zertifizierungsstelle überprüfen. Der Nachteil dieses Modells besteht insbesondere darin, dass die gesamte Sicherheit von der zentralen Zertifizierungsstelle abhängig ist. Wird sie kompromittiert, sind auch sämtliche Zertifikate nicht mehr vertrauenswürdig. Dafür kann eine Sperrliste verwendet werden, die alle Teilnehmer regelmäßig abfragen müssen. Außerdem ist eine Policy

Abb. 5.4 Anarchiemodell

1 Hierarchisches und browserorientiertes Modell unterscheiden sich minimal. Beim browserorien-

tierten Modell vertraut ein Benutzer a priori und implizit einer bestimmten Liste an Zertifikaten (diese sind von der Entwicklungsfirma des Browsers in diesem hinterlegt); im hierarchischen Modell vertraut ein Benutzer einer CA hingegen explizit [3].

5.3 Virtuelle Private Netzwerke

171

Abb. 5.5 Hierarchisches Vertrauensmodell

durchsetzbar, da etwa die Anzahl von Schlüsseln (Zertifikate) pro Benutzer samt Parametern wie Gültigkeitsdauer festgelegt werden können. In Ausbaustufen kann das hierarchische Vertrauensmodell auch über Organisationsgrenzen hinweg verwendet werden. Diese organisationsübergreifende Nutzung hat bereits das Zertifikat der Hochschule Worms samt der zugehörigen Zertifikationskette verdeutlicht. Entsprechend wird auch das Vertrauen organisationsübergreifend aufgebaut. Alternativ besteht die Möglichkeit einer Kreuzzertifizierung (engl. Cross Certification), bei der sich Zertifizierungsstellen gegenseitig, aber auf derselben Ebene, zertifizieren können. Bei zwischengeschalteten Zertifizierungsstellen, das heißt solchen, die zwischen zwei Zertifizierungsstellen von unterschiedlichen Organisationen eingesetzt werden, spricht man auch von einer Bridge Certification Authority.

5.3

Virtuelle Private Netzwerke

Die2 Grundlage vieler Sicherheitsmechanismen für das Internet ist eine sichere Datenübertragung in Form von Tunneln mit kryptografischer Sicherung (grob als Virtuelle Private Netzwerke, VPNs, bezeichnet). Kryptografische Tunnel kapseln ein Protokoll derselben oder niedrigeren Schicht in sich ein, um die eingekapselten Daten vor verschiedenen Angriffen zu schützen.

2 Dieser Abschnitt basiert auf meinem Buch Tunnel und verdeckte Kanäle im Netz, Springer-Vieweg, 2012, und wurde für dieses Buch grundlegend überarbeitet und aktualisiert.

172

5.3.1

5 Weiterführende Themen der Kryptografie

IPSec

Bei IPSec (Internet Protocol Security) handelt es sich um einen aus mehreren Komponenten bestehenden Standard, der verschiedene bedeutsame Funktionen zur Verfügung stellt: • Integrität: Sicherstellung der Integrität übertragener Daten durch HMACs (siehe Abschn. 4.8.9.1). (Dabei wird eine Prüfsumme für den Payload mit dem vereinbarten Schlüssel verschlüsselt. So kann der Absender den Hashwert berechnen und der Empfänger diesen prüfen.) • Authentizität: IPSec kann überprüfen, ob Daten tatsächlich von dem verschickt wurden, dessen Quelladresse angegeben wurde. • Replay Protection: Die Replay Protection bietet Schutz vor dem erneuten Senden eines durch IPSec geschützten Pakets. Realisiert wird dies über den ARS (Anti Replay Service), der unter anderem mit Hilfe von Sequenznummern realisiert wird.3 • Vertraulichkeit: IPSec bietet zudem die Verschlüsselung der übertragenen Daten an. IPSec besteht dabei primär aus dem AH (Authentication Header) und dem ESP (Encapsulating Security Payload). Beides sind standardisierte Protokolle. AH sichert die Integrität und Authentizität der Daten. Seine Aufgabe ist es jedoch nicht, die Vertraulichkeit der Daten – etwa durch Verschlüsselung – zu gewährleisten. ESP hat hingegen die Aufgabe, die Vertraulichkeit der Daten durch Verschlüsselung zu sichern. Je nach verwendetem Algorithmus kann jedoch auch die Authentizität und Integrität der Daten gewährleistet werden. Beide Protokolle können einzeln oder in Kombination verwendet werden. Zudem steht mit IKE (Internet Key Exchange) ein Protokoll zur Schlüsseldistribution bereit. IPSec kann in zwei verschiedenen Modi eingesetzt werden (siehe Abb. 5.6): • Zum einen gibt es den sogenannten Tunnelmodus. Im Tunnelmodus werden komplette IP-Pakete getunnelt. Das heißt, es wird ein komplett neuer IP-Header für die Zustellung des getunnelten Pakets verwendet. • Etwas sparsamer in der Übertragung, dafür jedoch weniger Layer sichernd, ist der Transportmodus. Hierbei wird der Tunnel nur für die Daten ab dem Transport-Layer verwendet. Der originale IP-Header wird entsprechend für die Zustellung des Pakets verwendet.

3 Replay Protection versucht ein grundlegendes Schutzziel der IT-Sicherheit zu gewährleisten, nämlich die Nicht-Vermehrbarkeit (engl. Non-propagation), das heißt, dass Unberechtigte nicht in der Lage sein sollen, Informationen wiederholt zu verwenden (oder zu kopieren) [5].

5.3 Virtuelle Private Netzwerke

173

Abb. 5.6 IPSec: Tunnel-Modi

5.3.1.1 Security-Assoziationen In einer sogenannten Security-Assoziation (SA) sind die grundlegenden Eigenschaften einer IPSec-Verbindung definiert. Dadurch ist es beispielsweise möglich, verschiedene Sicherheitsstufen über ein und dieselbe Leitung zwischen zwei IPSec-Gateways bereitzustellen. Jede dieser Stufen wird einer entsprechenden SA zugeordnet. Eine Stufe könnte nur Authentifizierung und Integritätsprüfung durch den AH verwenden, die andere könnte über diese Funktionen sowie eine zusätzliche Verschlüsselung via ESP und Replay Protection verfügen. Security Parameter Index: Auch der Verschlüsselungsalgorithmus und die Lebensdauer einer Security-Assoziation sind in selbiger festgelegt. Doch wodurch kann ein IPSec-Gateway unterscheiden, welcher SA ein Paket zugeordnet werden soll? Dies wird mit Hilfe des Security Parameter Index (SPI) realisiert. Der SPI befindet sich im Header der Pakete.4 Security-Assoziationen: Security-Assoziationen werden meist automatisch durch das IKE-Protokoll erzeugt und in der sogenannten Security Association Database (SAD) angelegt. In der SAD sind Informationen zum Sender und Empfänger, zum verwendeten IPSec-Protokoll (darunter die Sequenz-Nummer, das Anti-Replay Window, der Authentifizierungsalgorithmus und der Verschlüsselungsalgorithmus), die Lebensspanne der Assoziation, der verwendete Tunneling-Modus, die Path-MTU-Parameter und der SPI abgelegt. Nach Ablauf einer SA-Lebensspanne wird sie durch das IKE-Protokoll wieder verworfen und bei Bedarf automatisch neu erzeugt. Eine manuelle Erzeugung einer SecurityAssoziation ist, wie bereits erwähnt, ebenfalls möglich, jedoch aufwendiger. 4 Erst durch diesen Parameter kann der Endpunkt feststellen, wie dieses Paket entschlüsselt werden soll.

174

5 Weiterführende Themen der Kryptografie

5.3.1.2 IPSec Security Policys In einer IPSec Security Policy werden die einzelnen Regeln, die zur Handhabung der den Gateway passierenden Pakete notwendig sind, festgelegt. Man unterscheided hier zwischen der Flussrichtung der Pakete, das heißt eine Regel kann für ein einkommendes oder aber auch für ein ausgehendes Paket gesetzt werden. Security Policy Database: Ein Paket kann entweder verworfen (discard), einfach weitergeleitet (bypass) oder durch IPSec übertragen werden (apply). Diese Regeln werden in der sogenannten Security Policy Database (SPD) hinterlegt. 5.3.1.3 Authentication Header Der Authentication Header ermöglicht die Sicherung der Integrität und der Authentizität der getunnelten Daten. Wie ESP kann auch AH sowohl im Tunnel- als auch im TransportModus verwendet werden. Um die Authentifizierung sicherzustellen, wird eine Prüfsumme über alle sich während der Verbindung nicht ändernden Header-Daten des betreffenden TCP- und IP-Pakets gebildet. In RFC 2402 ist der Aufbau des Protokoll-Headers wie in Abb. 5.7 dargestellt definiert [6]: Das Feld Next Header gibt das getunnelte Protokoll an. Je nach Tunnel-Modus ist dies entweder IP oder ein Transport-Layer-Protokoll. Das Feld Payload Length gibt die Länge des Authentication Headers an. Die Folgenden 16 Bits sind reserviert und werden mit Nullen besetzt. Der vier Byte große Security Parameter Index (SPI) wird zur Angabe der SecurityAssoziation verwendet (s.o.). Das Feld Sequence Number wird zur Identifizierung des IP-Pakets und zum Schutz vor Replay-Angriffen verwendet. Bei jedem neu versendeten IP-Paket wird dieser Wert inkrementiert – kommt eine Sequenznummer also zweimal vor, liegt entweder ein potentieller Angriff oder aber ein Übertragungsfehler vor. Der letzte Header-Bereich wird zur Prüfung der Authentizität verwendet. Er hat eine variable Länge (daher das Feld Payload Length) und beinhaltet den Integrity Check Value (ICV). Die Länge wird in 32-Bit-Wörtern (IPv4) oder 64-Bit-Wörtern (IPv6) gemessen. Abb. 5.7 Der Authentication Header

5.3 Virtuelle Private Netzwerke

175

Der zur Berechnung der ICV verwendete Algorithmus wird in der Security-Assoziation festgelegt.5 Der AH stellt Integrität dadurch sicher, dass es HMAC verwendet (SHA und AES). Veränderungen können somit nur äußerst schwer durch einen Angreifer herbeigeführt werden. Die Authentizität der Nutzdaten (Payload) und des Senders wird gewährleistet, weil auch Teile des IPv4/v6-Headers mit in die HMAC einberechnet werden. Spoofing wäre somit nur möglich, wenn zugleich die Integrität der Daten sichergestellt werden würde. Gemäß RFC-Standard erlaubte Algorithmen, die hierbei zum Einsatz kommen können, sind AES-GCM(*)/GMAC(*), 3DES-CBC, AES-CTR und AES-XCBC(*)-MAC-96; DES-CBC soll nicht mehr verwendet werden [7]. Replay-Angriffe werden dadurch erschwert, dass nur Pakete mit Sequenznummer akzeptiert werden, die nah an den aktuell verwendeten Sequenznummern sind (IP-Pakete kommen schließlich nicht auf deterministische Weise zum Empfänger). Empfangene und (nicht) erfolgreich authentifizierte Pakete werden zudem protokolliert, um ReplayVersuche leichter zu erkennen.

5.3.1.4 Encapsulating Security Payload Das ESP (Encapsulating Security Payload)-Protokoll (Protokollnummer 50) wird, wie bereits erwähnt, zunächst einmal zur Verschlüsselung der Datenübertragung verwendet [8]. Dabei wird der Payload nach den Daten des EPS-Headers (nicht der ESP-Header selbst) verschlüsselt. Im Tunnel-Modus ist dies das komplette IP-Paket, im Transport-Modus sind es alle Protokolle ab Layer 3. Je nach verwendetem Verschlüsselungsalgorithmus kann ESP aber auch die Authentizität und Integrität der übertragenen Daten sichern. Da ESP im Gegensatz zum AH nicht automatisch Authentizität des verwendeten IPHeaders für den Datentransport gewährleistet, kann ESP auch in Netzwerken eingesetzt werden, in denen Network Address Translation angewandt wird. Der Aufbau des ESP-Headers (Abb. 5.8) ist mit Kenntnis des AH-Headers gut nachvollziehbar. Die Bedeutung des Security Parameter Index und die Bedeutung der Sequence Number sind analog zum AH zu verstehen. Es folgt das eingekapselte Paket (beziehungsweise im Transport-Modus der Teil des Pakets ab dem Transport-Layer aufwärts) und ein Padding-Bereich. Dieser PaddingBereich wird einerseits dazu verwendet, durch den Payload nicht komplett ausgefüllte Wörter zu vollständigen Wörtern zu strecken, und zum anderen, um dahinter eine einheitliche Position für die Felder Padding Length und Next Header zu schaffen. Padding Length legt die Länge des Padding-Bereiches fest, das Next Header-Feld gibt das eingekapselte Protokoll an. Für den Fall, dass ESP auch zur Authentifizierung der Daten verwendet wird, findet sich hinter dem Feld Next Header noch ein Feld für den Integrity Check Value (ICV), der bereits vom AH bekannt ist.

5 Bei AH bezieht die ICV-Berechnung auch statische Teile des IP-Headers ein, bei ESP nicht.

176

5 Weiterführende Themen der Kryptografie

Abb. 5.8 Der ESP-Header

Tab. 5.1 Vorgaben für die Verwendung von kryptografischen Algorithmen für ESP gemäß [7] in den drei möglichen Modi Auth. Verschlüsselung

Verschlüsselung

Authentifizierung

AES-GCM, AES-CCM

AES-CBC, AES-CTR, 3DES-CBC

HMAC-SHA1-96, AES-GMAC mit AES-128 AES-XCBC-MAC-96

Die Integritäts- und Authentizitätsprüfung erfolgt mit AES-CCM beziehungsweise GCM, jedoch ohne Einbeziehung von Feldern aus dem IP-Header. Der eingekapselte IP-Header ist im Tunnel-Modus allerdings im Payload enthalten, im Transportmodus nicht. Spoofing wird somit nicht automatisch entdeckt. Verschlüsselt werden der PayloadBereich sowie die Felder Payload Length und Next Header. Gemäß RFC 7321 sind die in Tab. 5.1 genannten Algorithmen für authentifizierte Verschlüsselung (sogenannter Combined Mode), für Verschlüsselung und für Authentifizierung vorgeschrieben: Je nach Konfiguration von ESP können beide Funktionen im Combined Mode oder nur eine der beiden Funktionen verwendet werden. Wie in [11] erwähnt, ist bei ausschließlicher Aktivierung der Verschlüsselung ein Replay-Angriff möglich.

5.3.1.5 Internet Key Exchange (IKE) Ein wichtiger Arbeitsschritt bei der Sicherung der Datenübertragung ist die Verteilung der Schlüssel. Kommt ein Angreifer in den Besitz dieser Schlüssel, ist die ganze Verschlüsselung und Authentifizierung umsonst. Daher sollte über Sicherung und Verteilung solcher Schlüssel genauer nachgedacht werden. Bei der manuellen Verteilung entsteht bei sehr kleinen Netzwerken ein erträglicher Arbeitsaufwand. Diese Methode ist zu empfehlen, wenn zum Beispiel nur wenige Mitarbeiter aus dem Außendienst über ein VPN an ein internes Firmennetzwerk angebunden werden

5.3 Virtuelle Private Netzwerke

177

müssen oder wenn eine geringe Anzahl von Netzwerken mit VPN-Gateways verbunden werden soll. Die zweite Methode ist die, bei der die automatische Schlüsselverteilung mit Hilfe des Internet Key Exchange-Protokolls, kurz IKE, erledigt wird [9]. Eine verbesserte Version existiert, die beispielsweise den Einsatz von NAT (durch NAT-Traversal) ermöglicht [10]. IKE ermöglicht die gegenseitige Authentifizierung der IPSec-Kommunikationsendpunkte und die Einigung auf Security Associations inklusive Schlüsseln. Zur Sicherung der Kommunikation wird in diesem Fall asymmetrische Kryptografie (Diffie-Hellman-Verfahren) verwendet. Außerdem kann IKE dazu genutzt werden, die Datenkompression für IP auszuhandeln [10].

5.3.2

Transport Layer Security (TLS)

Die Netzwerkprotokolle Transport Layer Security (TLS) beziehungsweise der Vorgänger Secure Socket Layer (SSL) werden zur Sicherung von Daten der Anwendungsschicht eingesetzt. TLS und SSL sichern Authentizität und Vertraulichkeit der übertragenen Daten. Beide Protokolle können zum Einsatz kommen, um Tunnel für VPNs zu realisieren (indem Sie etwa IP-Pakete einkapseln), werden aber standardmäßig nur für die Verschlüsselung der Anwendungsschicht verwendet, weshalb sie in diesem Fall – da sie selbst auf einer niedrigeren Schricht laufen – folglich keinen Tunnel umsetzen. TLS/SSL kommen bei diversen Diensten, unter anderem HTTPS, SMTPS und IMAPS, zum Einsatz. Besonders verbreitet sind einige quelloffene Implementierungen, etwa OpenSSL. Die Protokolle bestehen aus zwei Schichten, der Handshake- und Record-Schicht. Die Handshake-Schicht initiiert Verbindungen und stimmt die kryptografischen Rahmenbedingungen (zu verwendende Chiffre und Authentifizierung der Kommunikationspartner) für jede Kommunikationsrichtung separat ab. TLS verwendet dabei im Gegensatz zu SSL HMACs, ein modifiziertes Verfahren zur Schlüsselerzeugung und behandelt Fehler (etwa eine unbekannte Zertifizierungsstelle) insgesamt sensitiver [11]. Es können durch die Handshake-Schicht eine Vielzahl von Chiffren selektiert werden, mit denen SSL eine Verbindung verschlüsselt (etwa 3DES oder AES). Diese Chiffren können während der Initiierung einer SSL-Session zwischen Client und Server ausgemacht werden, später jedoch auch wieder geändert werden. Der Handshake läuft wie folgt ab: 1. Der Client sendet zunächst eine „Client Hello“-Nachricht. Diese Nachricht beinhaltet einen Timestamp, eine Session-ID, unterstützte Kryptoverfahren (und zwar für den Schlüsselaustausch, für die symmetrische Verschlüsselung, MAC-Algorithmen und PRNG-Funktionen) sowie unterstützte Kompressionsverfahren [12]. 2. Der Server antwortet mit einer „Server Hello“-Nachricht und sendet in dieser seinerseits ähnliche Daten (die Session-ID ordnet die Antwort der Client Hello-Nachricht zu). Er bildet die Schnittmenge zwischen den unterstützten Kryptoverfahren des Clients und

178

3.

4. 5.

6.

7.

5 Weiterführende Themen der Kryptografie

den von ihm unterstützten Verfahren [12]. Sollte die Schnittmenge leer sein, kann der Handshake nicht weitergeführt werden. Der Server schickt zudem entweder sein Zertifikat („Server Certificate“-Nach-richt) sowie ggf. eine Anforderung eines Client-Zertifikats („Certificate Request“-Nachricht) samt der vom Server vertrauten Zertifizierungsstellen zum Zweck der gegenseitigen Authentifizierung. Alternativ kann der Server auch seinen öffentlichen Schlüssel an den Client senden („Server Key Exchange Message“-Nachricht). Anschließend wird dieser Schritt mit einer „Server Hello Done“-Nachricht abgeschlossen. Falls vom Server ein Zertifikat gefordert wurde, so antwortet der Client mit seinem eigenen Zertifikat („Client Certificate“-Nachricht). Der Client überprüft zudem die vom Server erhaltene Nachricht (Zertifikat und Ciphers (also Algorithmen) des Servers) und antwortet mit einer „Client Key Exchange“Nachricht, um den Schlüsselaustausch einzuleiten. Der Client schickt mit dieser Nachricht auch ein 48-Byte Pre-Master Secret RSAverschlüsselt an den Server. Falls kein RSA verwendet wird, kann ein Pre-Master Secret auch mithilfe des Diffie-Hellmann-Verfahrens ausgetauscht werden. Das finale Master Secret wird von Client und Server berechnet, indem die zuvor ausgetauschten Zufallszahlen mit dem Pre-Master Secret mehrfach verrechnet werden. Details zur Berechnung finden sich im entsprechenden RFC [12]. Die verwendeten Ciphers können durch die „ChangeCipherSpec“-Nachricht jederzeit geändert werden.

In der Record-Schicht werden Daten höherer Schichten unmodifiziert und uninterpretiert entgegengenommen. Sie werden zunächst fragmentiert. Die daraus resultierenden Fragmente f1 . . . fn haben bei TLS 1.2 eine Größe von maximal 214 Bytes. Im nächsten Schritt wird eine MAC-Funktion auf jedes Fragment fi , konkateniert mit einer Sequenznummer seq_num, ursprünglichem Protokolltyp type, TLS-Version version und Fragmentlänge length, angewandt. Für diesen Schritt wird ein Teil der Daten (siehe unten) mit einem durch das Handshake Protocol selektierten Algorithmus compr komprimiert. Die Kompression muss gemäß RFC verlustfrei erfolgen [12]. Außerdem sorgt die Kompression für eine hohe Entropie und entfernt typische Charakteristika des Klartexts [12]. Der MAC-Schlüssel km wird sowohl für den Client als auch für den Server aus dem Master Secret gewonnen (unter anderem durch Expansion). Mi = MAC(km , seq_num||compr(type||version||length||fi )),

(5.1)

Damit bilden sich die zu verschlüsselnden Daten aus der Konkatenation des MACWertes Mi mit dem jeweiligen Fragment fi . Diese Daten werden wiederum mit dem Write-Key (kw , der ebenfalls aus dem Master Secret erzeugt wird) zum Ciphertext Ci verschlüsselt:

5.4 Anonymität und Onion-Routing

Ci = E(kw , Mi ||fi ).

179

(5.2)

Ci wird schließlich mit einem vorangestellten Header übertragen.

5.3.2.1 Datagram Transport Layer Security (DTLS) Während TLS auf Basis von TCP betrieben wird, also eine Verbindung mit Reliabilität voraussetzt, gibt es diverse Protokolle, die auf UDP-Basis übertragen werden, etwa SIP für die IP-Telefonie. Um auch diesen Protokollen eine vergleichbare Sicherung zu ermöglichen, wurde das in RFC 6347 spezifizierte Protokoll Datagram Transport Layer Security entwickelt [13]. DTLS arbeitet ähnlich wie TLS und setzt auf dem TLS-Standard auf. Es gibt einzelne Detailunterschiede, die insbesondere deshalb enstanden sind, da UDP keine Sequenznummern samt Sortierung verwendet und auch keine Reliabilität bereitstellt [13]. DTLS ist deshalb in der Lage, mit Nachrichtenverlust umgehen zu können (TCP würde Nachrichten, deren Empfang nicht bestätigt wurde, erneut senden).

5.4

Anonymität und Onion-Routing

Abschn. 3.6.1 setzte sich bereits mit der Anonymität und Unverkettbarkeit auseinander. Es gibt diverse Ansätze, Anonymität und Unverkettbarkeit zu erreichen. In Netzwerken werden sie insbesondere durch das Konzept des Onion-Routings erreicht. Onion-Routing kommt in verschiedenen Formen zum Einsatz, etwa bei Tor. Im Folgenden wird nur das Grundkonzept des Onion-Routings betrachtet – die von David Chaum 1981 eingeführten Mixe.

5.4.1

Grundzüge der Mixe

Eine Mix ist eine Art Router (siehe Abb. 5.9). Sie leitet eine Nachricht weiter, verwendet dabei allerdings kryptografische Funktionen. Mixe basieren letztlich auf asymmetrischer Kryptografie. Das Vorgehen der Mix ist allerdings etwas umfangreicher, als bei einem reinen Router (siehe Abb. 5.10). Die folgende Beschreibung hält sich an den Originalaufsatz von Chaum, der 1981 in Communications of the ACM erschien [14]. Alice verschlüsselt ihre Nachricht

Abb. 5.9 Grobkonzept der Chaum-Mix

180

5 Weiterführende Themen der Kryptografie

Abb. 5.10 Funktionsweise von Mix-Systemen

M an Bob mit Bobs öffentlichem Schlüssel. Sie legt außerdem eine Zufallswert R bei. R dient zur Vermeidung von Angriffen, bei denen gleiche Nachrichten durch gleiche Chiffretexte identifiziert werden können. Alice fügt letztlich noch die Adresse von Bob (AB ) an die Nachricht an, womit sich (KB (R, M), AB ) ergibt. Alice kaspelt die Nachricht auf dieselbe Weise in mehrere „Hüllen“, die jeweils die Adresse der nächsten Mix samt einem neuen R enthalten und verschlüsselt jede Hülle mit dem KX von Mix X. Die Nachricht wird von Mix zu Mix weitergeleitet, bis sie schließlich Bob erreicht. Auf ihrem Weg wird von der Nachricht jeweils eine Hülle entfernt. Deshalb spricht man auch vom Zwiebelschalen-Modell beziehungsweise von Onion-Routing. Wenn Bob diese Nachricht erhält, verwirft er R. AB dient zur Weiterleitung der Nachricht durch eine Mix an Bob. Damit Alice eine Antwort von Bob erhalten kann, kann sie zusätzlich zur oben beschrieben Nachricht an Bob ihre eigene Adresse AA gemeinsam mit einem Sealing Key R1 (Zufallswert zur Verhinderung von der Erkennung identischer Daten durch Abfangen der Nachricht), mit KM einer Mix M verschlüsseln. Sie kann Bob zudem einen temporären Public-Key KT zusenden, mit dem er seine Antwort verschlüsseln kann. Zusammengefasst sendet sie Bob folglich zusätzlich die folgenden Daten KM (R1 , AA ), KT [14]. Bob verschickt seine Antwort an Alice verschlüsselt über Mix M (und ggf. weitere Hüllen). Er verschlüsselt seine Antwortnachricht an Alice zusammen mit Zusatzbits R0 (um die Identifikation gleicher Chiffretexte zu vermeiden) mit dem Schlüssel KT , somit ergibt sich KM (R1 , AA ), KT (Antwort, R0 ). Die Mix kann bei der Entschlüsselung des Nachrichtenteils KM (R1 , AA ) die Adresse von Alice sehen (da die Mix den privaten Schlüssel für KM besitzt). Die Mix kann jedoch nicht die mit dem temporären Schlüssel KT verschlüsselte Antwortnachricht von Bob einsehen. Schließlich verschlüsselt die Mix M die erhaltene Antwortnachricht mit R1 zu R1 (KT (Antwort, R0 )) und leitet sie an Alice weiter, die sie entschlüsseln kann, da sie die privaten Schlüssel für R1 und KT besitzt [14].

5.5 Visuelle Kryptografie

5.4.2

181

Angriffe gegen Anonymisierungssysteme

Aufgrund der hohen Relevanz der Anonymisierungssysteme wurden zahlreiche Angriffe auf selbige entwickelt. Diese dienen insbesondere • der Durchsetzung von Internetzensur durch staatliche Organisationen (Identifikation von Personen, die beispielsweise unerlaubte, regimekritische Webseiten besuchen) und • der Detektion und Verhinderung von anonymisierter Kriminalität (auch Kriminelle schützen sich durch Software wie Tor). Stellvertretend soll an dieser Stelle das sogenannte Website Fingerprinting (WFP) dargestellt werden. Dabei geht es insbesondere darum, herauszufinden, welche Webseiten ein Benutzer besucht, auch wenn sein Datenverkehr anonymisiert oder obfuskiert wurde. Die Vorgehensweise gemäß Ejeta et al. [15] ist dabei wie folgt: • Der Angreifer besucht zu identifizierende Zielwebseiten zunächst selbst und zeichnet dabei seinen Datenverkehr auf, etwa mit einem Packet Capturing Tool wie tcpdump. • Die Metadaten der Datenübertragung (Paketintervallzeiten, Paketgrößen, Fragmentierungsverhalten, Paketanzahl etc.) werden protokolliert und als Fingerprint der Webseite bezeichnet. • Der Angreifer schneidet den (vermeintlichen) Datenverkehr des Opfers mit und speichert dessen Metadaten (Vergleichsfingerprint). • Weil der Datenverkehr nicht direkt verglichen werden kann (beispielsweise aufgrund von Obfuscation oder Verschlüsselung), werden mithilfe von maschinellen Lernverfahren nur diejenigen Metadaten verglichen, die zugänglich sind. Die Erfolgsquoten derartiger Verfahren können gemäß Ejeta et al. je nach Anonymisierungsdienst sehr gering oder recht hoch ausfallen. Die Autoren konnten zeigen, dass mit einem SVM-Classifier ein Großteil des Datenverkehrs, der durch den Anonymisierungsdienst Psiphon generiert wurde, korrekt klassifiziert werden konnte [15].

5.5

Visuelle Kryptografie

Eine 1994 von Naor und Schamir vorgestellte Form der Kryptografie ist die visuelle Kryptografie (visual cryptography) [16]. Ein derartiges Kryptosystem wird als VCS (visual crypto system) bezeichnet. Die geheime Nachricht M wird bei einem (k, n)-VCS auf n-Bilder aufgeteilt. Vorgegangen wird dabei wie folgt [16, 17]: Jedes der n Bilder enthält einen Teil der geheimen Nachricht, die allerdings nur durch Überlappung der Bilder, beispielsweise

182

5 Weiterführende Themen der Kryptografie

Abb. 5.11 Prinzip visueller Kryptografie

mit logischem OR oder XOR, erfolgt. Die Bilder bestehen dabei aus schwarzen und weißen (transparenten) Pixeln. k gibt dabei an, wie viele Bilder zur (De-)Chiffrierung übereinander gelegt werden müssen (nur die korrekte Anzahl der verwendeten Bilder ergibt M). Pixel werden dabei in mehrere Subpixel zerlegt, deren schwarze und weiße (transparente) Pixel zufällig festgelegt werden. Erst bei der k-fachen Überlagerung der einzelnen Bilder entstehen schwarze und graue Flächen, die für den menschlichen Betrachter unterscheidbar sind (Abb. 5.11).

5.6

Secure Multi-Party Computation und homomorphe Verschlüsselung

Secure Multi-Party Computation (SMC oder SPMC), auch Privacy-preserving Computation, erlaubt es, mit mehreren Parteien auf Daten zu rechnen, die nicht für alle Parteien zugänglich sind, die also privat bleiben. Ein potenzieller passiver (mitlesender) oder aktiver (manipulierender) Angreifer kann bei einer SMC an der Berechnung beteiligt sein, das heißt er ist kein externer Angreifer, sondern ein Insider. Beispielhaft wird das Problem der Dining Cryptographers (nach David Chaum) betrachtet. Wenn hingegen auf verschlüsselten Daten gerechnet wird (diese können allen Beteiligten zugänglich sein), und dabei nach einer anschließenden Entschlüsselung dieser Daten dasselbe Resultat gegeben ist, als ob die vorher durchgeführten Rechenoperationen auf nicht-verschlüsselten Daten erfolgten, so ist von homomorpher Verschlüsselung die Rede. Zum Einsatz kommen kann homomorphe Verschlüsselung zumindest potenziell in CloudSzenarien, in denen die Benutzer der Cloud den Betreibern der Cloud nicht vertrauen. Zum Beispiel könnten die Betreiber der Cloud versuchen, kryptografische Schlüssel aus dem Hauptspeicher der Cloudserver auszulesen und somit dort verarbeitete vertrauliche Daten entschlüsseln. Homomorphe Verschlüsselung ist in der Praxis allerdings noch nicht für sonderlich viele Szenarien einsetzbar, da sie sehr langsam abläuft. Homomorphe Verschlüsselung kann auch dann zum Einsatz kommen, wenn vertrauliche Informationen zwischen verschiedenen Teilnehmern gemeinsam benutzt werden sollen, aber nur unter bestimmten Bedingungen für andere Teilnehmer offengelegt werden sollen; hierzu können Policies (also Festlegungen darüber, welcher Teilnehmer wie mit welchen Daten

5.7 Geteilte Geheimnisse

183

umgehen darf) verwendet werden [18]. Beispielsweise könnte festgelegt werden, dass ein Teilnehmer zwar Berechnungen auf bestimmten Daten durchführen, sich das Resultat der Berechnung (also die entschlüsselten Resultate) aber nicht ansehen darf.

5.6.1

Dining Cryptographers

Beim Szenario der Dining Cryptographers geht es um drei Kryptologen (A, B und C). Diese Kryptologen befinden sich in einem Restaurant (runder Tisch). An einem anderen Tisch sitzt die NSA. Während des Dinners informiert der Kellner die drei Kryptologen darüber, dass ihr Essen bereits bezahlt wurde. Die Kryptologen wollen wissen, wer für das Essen bezahlt hat – einer von ihnen oder vermutlich die NSA? Wenn einer der drei Kryptologen bezahlt hat, dann soll zudem nicht aufgedeckt werden, wer es war (die Information soll geheim bleiben und nur dem jeweiligen Zahler bekannt bleiben, während die anderen beiden im Unklaren bleiben, welcher der jeweils anderen beiden Kryptologen zahlte). Das Protokoll sieht nicht vor, dass zwei Kryptologen die Rechnung teilen, es darf nur einer bezahlen, da sich sonst später ⊕-Operationen aufheben. Jeder der Teilnehmer muss zudem ehrlich antworten, ein aktiver (das heißt manipulierender) SMC-Angreifer wäre somit nicht vom Protokoll tolerierbar. Das Problem lässt sich mit folgender Vorgehensweise lösen: Jeweils zwei Kryptologen werfen hinter ihrem Rücken eine Münze, um ein gemeinsames Zufallsbit zu erhalten. Als Resultat ergeben sich insgesamt drei Zufallsbits, jeweils eins mit dem Kryptologen links beziehungsweise rechts von einem Kryptologen. Somit hat jeder der Kryptologen Kenntnis von zwei Zufallsbits (A hat beispielsweise Kenntnis von Zlinks-A und Zrechts-A ). Jeder Kryptologe i (1 ≤ i ≤ 3) berechnet nun für seine beiden Zufallsbits ⎧ ⎨¬(Z links-i ⊕ Zrechts-i ) falls i zahlte Ei (Zlinks-i , Zrechts-i ) = ⎩Zlinks-i ⊕ Zrechts-i falls i nicht zahlte und gibt das jeweilige Ergebnis Ei bekannt. Wenn E1 ⊕ E2 ⊕ E3 = 1, dann zahlte einer der drei Kryptologen. Andernfalls (Ergebnis ist 0) zahlte vermutlich die NSA.6

5.7

Geteilte Geheimnisse

Manchmal ist es sinnvoll, ein Geheimnis aufzuteilen. Zum Beispiel so, dass mindestens n von m (mit n ≤ m) Geheimnisträgern, ihr geheimes Wissen kombinieren müssen, um einen gemeinsamen Schlüssel zu bilden. 6 Oder ein (unbekannter) Dritter, etwa der Kellner.

184

5 Weiterführende Themen der Kryptografie 1

0.5

0

x**2 -x**2 2*x**2 3*x**2-1 ’-’

-0.5

-1

-1

-0.5

0

0.5

1

Abb. 5.12 Eine Parabel benötigt drei Punkte, um exakt beschrieben zu werden

Shamir schlägt die Nutzung eines Polynoms vom Grad n−1 vor, um n Geheimnisträger für die Bestimmung der Funktion notwendig zu machen [19]. Schließlich werden n Punkte benötigt, um eine Funktion vom Grad n − 1 korrekt zu bestimmen. Eine Funktion der Form ax 2 + bx + c (Abb. 5.12) kann etwa durch drei Geheimnisträger beschrieben werden. Jeder Geheimnisträger erhält einen unterschiedlichen Punkt (xi |yi ), durch den die Funktion verläuft, als Geheimnis. Bei nur zwei Punkten (also den Informationen von zwei Geheimnisträgern) wären noch immer unendlich viele Lösungen möglich. Entsprechend sind auch drei Geheimnisträger notwendig, um die Funktion vollständig zu beschreiben. Analog wäre dies bei einer linearen Funktion der Fall, die nur mit zwei Punkten exakt beschrieben werden kann, nicht jedoch ausschließlich mit einem einzigen Punkt.

5.8

Zusammenfassung

Die Verwendung von Kryptografie ist in der Praxis nicht trivial. Unter anderem müssen Wege gefunden werden, wie Schlüssel effizient und sicher ausgetauscht werden können. Auf Basis von Vertrauen können Infrastrukturen (sogenannte Public Key Infrastructures) zur Verwaltung von öffentlichen Schlüsseln und Zertifikaten umgesetzt werden. Ein weiteres Anwendungsgebiet, das in diesem Kapitel betrachtet wurde, sind Virtuelle Private Netzwerke (VPNs), die insbesondere mit IPSec realisiert werden können. Kryptografisch gesicherte Datenübertragungen sind zudem mit TLS möglich.

5.10 Übungsaufgaben

185

Sender- und Empfänger-Anonymität können auf der Basis von Mix-Netzen erzielt werden. Hierbei fungieren Mixe als Zwischenstationen, die kryptografische „Hüllen“ von Nachrichten vor dem Weitersenden entfernen, was durch asymmetrische Kryptografie ermöglicht wird. Aktuelle Forschungsgebiete, die in diesem Kapitel prägnant eingeführt wurden, sind die visuelle Kryptografie, Secure Multi-Party Computation und homomorphe Verschlüsselung.

5.9

Weiterführende Literatur

Mehr über Public Key Infrastructure und die zugehörigen Modelle erfahren Sie unter anderem in [1, 3, 4]. Um einen tieferen Einblick in VPNs zu werfen, empfiehlt sich ein Blick in die zitierten RFC-Dokumente. Weiterführende Literatur zum Thema visueller Kryptografie finden Sie unter anderem in [16, 17, 20]. Einen guten Überblick über die Thematik bietet [21].

5.10

Übungsaufgaben

1. Sie setzen einen eigenen Webserver (beispielsweise Apache) auf und möchten für Verbindungen TLS verwenden. Ohne die Details von TLS zu kennen und zu betrachten: Sie selbst stellen ein eigenes Zertifikat für Ihren Server aus – welches Vertrauensmodell verwenden Sie in diesem Fall? 2. Wie könnte man ein Web of Trust für E-Mails realisieren? (Hinweis: PGP!). 3. Auf welchen OSI-Schichten operieren SSL/TLS beziehungsweise IPSec? Begründen Sie Ihre Antworten. 4. Für die folgenden Szenarien: Würden Sie eher TLS oder IPSec einsetzen? • sichere Anbindung des Netzwerks einer Niederlassung an das Hauptnetz eines Unternehmens • Absicherung des E-Mail-Zugriffs auf den SMTP-Server einer Hochschule • „Road Warrior Setup“ (Mitarbeiter, die von unterwegs auf Daten des Firmennetzes zugreifen müssen) 5. Was versteht man unter einem Replay-Angriff? 6. Ein VPN ist eine durch einen kryptografischen Tunnel gesicherte Netzwerkverbindung zwischen Hosts/Netzen. • Weshalb ermöglicht TLS keine vollständige VPN-Anbindung für ein gesamtes Netzwerk? • Wie könnte man trotzdem ein VPN über TLS realisieren?

186

5 Weiterführende Themen der Kryptografie

7. Angenommen, das AH-Protokoll wird für den Austausch von Daten innerhalb eines VPNs verwendet. • Können Sie die eingekapselten Daten im Tunnelmodus lesen? • Können Sie die eingekapselten Daten im Transportmodus lesen? Begründen Sie Ihre Antworten. 8. Welche Daten können Sie im Falle von ESP im Tunnel-/Transportmodus lesen?

Literatur 1. Schmeh, K.: Kryptografie: Verfahren, Protokolle, Infrastrukturen, Kryptografie: Verfahren, Protokolle, Infrastrukturen, 6. Aufl. dpunkt.verlag (2016) 2. Schneier, B.: Applied Cryptography – Protocols, Algorithms, and Source Code in C, 2. Aufl. Wiley, Hoboken (1996) 3. Wölfl, T.: Formale Modellierung von Authentifizierungs- und Autorisierungsinfrastrukturen – Authentizität von deskriptiven Attributen und Privilegien auf der Basis digitaler Zertifikate, Dissertation, Universität Regensburg, Deutscher Universitäts-Verlag/GWV Fachverlage GmbH (2006) 4. Perlman, R.: An overview of PKI trust models. IEEE Netw. 13(6), 38–43 (1999). IEEE 5. Bedner, M., Ackermann, T.: Schutzziele der IT-Sicherheit, Datenschutz und DatensicherheitDuD, vol. 34(5), S. 323–328. Springer (2010) 6. Kent, S., Atkinson, R.: IP Authentication Header, RFC 2402, Nov 1998 7. McGrew, D., Hoffman, P.: Cryptographic Algorithm Implementation Requirements and Usage Guidance – RFC 7321. IETF (2014) 8. Kent, S.: IP Encapsulating Security Payload (ESP), RFC 4303, Dezember 2005 9. Hoffman, P.: Algorithms for Internet Key Exchange version 1 (IKEv1), RFC 4109, Mai (2005) 10. Kaufman, C. (Hrsg.): Internet Key Exchange (IKEv2) Protocol, Dezember (2005) 11. Eckert, C.: IT-Sicherheit, 9. Aufl. De Gruyter (2014) 12. Dierks, T., Rescorla, E.: The Transport Layer Security (TLS) Protocol Version 1.2 – RFC 5246. IETF (2008) 13. Rescorla, E., Modadugu, N.: Datagram Transport Layer Security Version 1.2 – RFC 6347. IETF (2012) 14. Chaum, D.L.: Untraceable electronic mail, return addresses, and digital pseudonyms. Commun. ACM (CACM) 24(2), 84–88 (1981). ACM 15. Ejeta, T.G., Kin, H.J.: Website fingerprinting attack on psiphon and its forensic analysis. In: Proceedings of the International Workshop on Digital Forensics and Watermarking (IWDW’17), pp. 42–51. Springer, Beijing (2017) 16. Naor, M., Shamir, A.: Visual cryptography. In: Proceedings of the Advances in Cryptology – EUROCRYPT 1994. LNCS 950, S. 1–12. Springer, Heidelberg (1995) 17. Wang, W., Liu, F., Guo, T., Ren, Y.: Temporal integration based visual cryptography scheme and its application. In: Proceedings of the 16th International Workshop on Digital Forensics and Watermarking (IWDW ’17). LNCS 10431, S. 406–419. Springer, Basel (2017) 18. Kasem-Madani, S.: Poster: a framework design for privacy-preserving computation on shared data. In: Proceedings of the 1st IEEE European Symposium on Security and Privacy. IEEE (2016). http://www.ieee-security.org/TC/EuroSP2016/posters/number10.pdf. Zugegriffen am 01.06.2018 19. Shamir, A.: How to share a secret? Commun. ACM 22(11), 612–613 (1979). ACM

Literatur

187

20. Li, P., Liu, Z.: A novel visual cryptography scheme with different importance of shadows. In: Proceedings of the 16th International Workshop on Digital Forensics and Watermarking (IWDW’17). LNCS 10431, S. 365–377. Springer, Basel (2017) 21. Weir, J., Yan, W.: A comprehensive study of visual cryptography. In: Shi, Y.Q. (ed.) Transactions on Data Hiding and Multimedia Security (DHMS). LNCS 6010, S. 70–105. Springer, Heidelberg (2010)

Teil III Netzwerksicherheit

Die folgenden Kapitel befassen sich mit dem Hauptthema dieses Buches: der Netzwerksicherheit. Zunächst betrachtet ein Kapitel die Grundlagen der Netzwerksicherheit. Anschließend widmet sich ein Kapitel den Angriffen auf die verschiedenen Netzwerkschichten und ein weiteres Kapitel erläutert schließlich, wie Netzwerke abgesichert werden können. Alle Kapitel konzentriern sich dabei stark auf die jeweiligen Netzwerkprotokolle und nur geringfügig auf die dabei potenziell eingesetzte Software.

6

Einführung in die Netzwerksicherheit

We frequently see a race between the security specialists and the attackers in the following sense: one day an intelligent solution is proposed to fix a network vulnerability, and the next day the attackers come up with a smarter way to circumvent the proposed countermeasure. – Sankardas Roy et al. (2010)

Zusammenfassung

Dieses Kapitel führt Sie in die Grundzüge der IT-Sicherheit für Netzwerke ein. Es erläutert Grundbegriffe und elementare Konzepte, die zum Verständnis der folgenden Kapitel von Bedeutung sind.

6.1

Einführung

Der Begriff Netzwerksicherheit wurde bereits in Kap. 3 definiert. Dieses Kapitel wendet sich nun Grundbegriffen und wichtigen Konzepten sowie Verfahren der Netzwerksicherheit zu. Es dient als Basis für das Verständnis der folgenden Kapitel, die sich mit den Angriffen und der Absicherung im Netzwerk auseinandersetzen.

6.2

Angriff

Angriffe können passiv (zur Gewinnung von Informationen) oder aktiv (zur Beeinflussung von Zielsystemen und -netzen) stattfinden. Außerdem können sie auf technischer

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2018 S. Wendzel, IT-Sicherheit für TCP/IP- und IoT-Netzwerke, https://doi.org/10.1007/978-3-658-22603-9_6

191

192

6 Einführung in die Netzwerksicherheit

(Netzwerkprotokolle, Netzwerkkabel, . . . ) und auf sozialer Ebene (etwa Bestechung von Mitarbeitern) erfolgen. Primär konzentriert sich dieses Kapitel auf die technische Ebene.

6.2.1

Scanning

Ein Scan ist ein aktiver Abfrageprozess, bei dem ein Angreifer zum Beispiel alle IPAdressen eines Netzwerks versucht anzusprechen (scannt). Genauso kann ein Scan aber auch offene Ports auf einem einzelnen Host überprüfen oder das Ziel haben, festzustellen, welche Software in welcher Version und mit welchen optionalen Modulen auf einem Server läuft. Scans werden sowohl zu Sicherheitszwecken (Administratoren können in Erfahrung bringen, welche Dienste in einem Netzwerk laufen und welche Rechner erreichbar sind), als auch zu Angriffszwecken (Verschaffen eines Überblicks über ein anzugreifendes Netzwerk) durchgeführt.

6.2.2

Wireless Wardriving

Wardriving bezeichnet eine populäre Technik, die darin besteht, Funknetzwerke zu finden, während sich die nach den Funknetzen suchende Person bewegt [1], was zunächst nicht notwendigerweise mit einem Angriff in Verbindung stehen muss. Schließlich kann Wardriving auch durch einen Administrator durchgeführt werden, um sich einen Überblick über unwissentlich aktivierte WLANs zu verschaffen. Aus Angriffssicht ist es allerdings möglich – und durchaus populär – sich mit einem Auto durch eine Stadt zu bewegen und mit einem Laptop nach verwundbaren Funknetzwerken zu suchen. Klassisch stehen dabei WLAN-Netzwerke im Fokus, doch dehnt sich Wardriving schon längst auch auf Netzwerktechnologien aus, die zum Internet der Dinge gehören, etwa ZigBee- oder EnOcean-Netzwerke für Logistik und Smart Homes. Mithilfe von GPS und Online-Karten lassen sich die entsprechenden Netzwerke zudem kartografieren und innerhalb der Wardriving Communitys teilen [1]. Mit der Verfügbarkeit und der Installation besserer Schutztechniken wie WPA-2 (siehe Abschn. 8.2.10) wurde das Angreifen von WLANs deutlich erschwert, da unverschlüsselte beziehungsweise schlecht gesicherte Netzwerke nicht mehr so leicht auffindbar sind – mit Ausnahme der mit Intention offenen WLANs von Cafés, Restaurants und weiteren öffentlich zugänglichen Einrichtungen.

6.2.3

Protocol Fuzzing

OWASP beschreibt Fuzzing als black box software testing technique, bei der es darum geht, Fehler in Implementierungen zu finden, indem nichtvorgesehene (malformed) Inhalte an ein Programm geschickt werden [2]. Im Kontext der Netzwerksicherheit

6.2 Angriff

193

ist insbesondere das sogenannte Protocol Fuzzing relevant. Dabei verbindet sich der Angreifer beziehungsweise Softwaretester über das Netzwerk mit einer zu testenden Netzwerksoftware, etwa einem HTTP-Server. Über die Verbindung werden anschließend nichtvorgesehene Pakete an den Empfänger geschickt. Dabei kann es sich um solche handeln, die schlicht zu große oder zu kleine Pakete, im Standard des jeweiligen Protokolls nicht vorgesehene Bitkombinationen, Mehrdeutigkeiten oder sonstige Inhalte aufweisen, die eventuell eine Fehlfunktion provozieren. Beim Protocol Fuzzing werden die Antworten des Empfängers auf die Fuzzing-Daten ausgewertet (inklusive der Tatsache, ob eine Antwort erhalten wurde, oder nicht, da eine ausbleibende Antwort auf einen Absturz des getesteten Systems hinweisen kann). Protocol Fuzzing kann mithilfe von Tools wie Scapy umgesetzt werden. Neben dem Protocol Fuzzing gibt es noch diverse andere Arten des Fuzzings, etwa Fuzzing für Dateiformate und Fuzzing für Web-URLs.

6.2.4

Sniffer und Promiscuous Mode

Sniffer sind passiv agierende Programme, die den Datenverkehr, der auf einer Netzwerkschnittstelle eintrifft, aufzeichnen. Im Normalfall zeichnen Netzwerkschnittstellen allerdings nur den Datenverkehr auf, der entweder explizit für sie bestimmt ist, also die Empfängeradresse des jeweiligen Hosts enthält, oder Broadcastnachrichten sind. In manchen Netzwerktypen (etwa Funknetze oder auch Koaxialkabel- und Hub-Ethernet) erhalten Hosts jedoch auch Nachrichten, die für andere Hosts bestimmt sind, und verwerfen diese. Um das Betriebssystem dennoch zur Verarbeitung solcher nicht an das eigene System gerichteten Nachrichten zu bewegen, können Netzwerkschnittstellen in den sogenannten Promiscuous Mode versetzt werden. Sniffer tun dies, um sämtlichen Datenverkehr, auch solchen anderer Teilnehmer, mitschneiden zu können. Außerdem ist es möglich, Netzwerkkarten in einen Modus zu schalten, in dem sie ausschließlich Daten annehmen, jedoch keine Daten versenden.1 Auf diese Weise können Hosts praktisch unsichtbar gemacht werden.

6.2.5

Man-in-the-Middle- und Spoofing-Angriffe

Bei einem Man-in-the-Middle-Angriff (MitM-Angriff) positioniert sich ein Angreifer zwischen zwei kommunizierenden Hosts beziehungsweise Verbindungsendpunkten (siehe Abb. 6.1). Der Angreifer kann die Verbindung auf verschiedene Weise negativ beeinflussen. Zum einen kann er die übertragenen Daten im einfachsten Fall mitlesen (etwa SMTP-Befehle,

1 Dies kann alternativ durch eine lokale Firewall geschehen, die das Entsenden sämtlicher Pakete unterbindet.

194

6 Einführung in die Netzwerksicherheit

Abb. 6.1 Drei MitM-Szenarien (MitM-Sniffing, Modifikation von Daten und selektives Verwerfen von Paketen) sowie Spoofing von Nachrichten

E-Mail-Header und -Inhalte). Das heißt, der MitM-Angreifer nutzt seine Position zwischen den Kommunikatoren Alice und Bob zum Sniffen. Zum anderen kann der Angreifer übertragene Daten modifizieren (etwa eigene Inhalte in eine E-Mail von einer dritten Person oder beliebige SMTP-Befehle), womit er die übertragenden Nutzdaten und die Protokollfunktionen beeinflussen kann. Weiterhin ist es möglich, die Weiterleitung von Daten zu blockieren, sodass etwa nur E-Mails zugestellt werden, die dem Angreifer gefallen. Fügt der Angreifer hingegen neue Datenpakete in eine Verbindung ein, um sie einem der Kommunikatoren zu senden (und dabei so zu tun, als ob sie vom jeweils anderen Kommunikator stammen), handelt es sich um Spoofing. Wenn ein Angreifer dabei nicht auf dem Routingpfad zwischen zwei Kommunikatoren sitzt (also keine MitM-Position einnimmt), dann kann er, durch geschicktes Raten von Quell- und Zielports sowie gegebenenfalls weiterer Protokollparameter, wie Sequenznummern, versuchen, blind Daten in die Verbindung einzuschleusen. Wir betrachten MitM- und Spoofing-Angriffe protokollspezifisch in Kap. 7. Angemerkt sei, dass insbesondere mehrere der dort beschriebenen TCP-basierten Angriffe Formen der MitM- und Spoofing-Attacken sind.

6.2.6

Redirects (Routing-Angriffe)

Angreifer können nicht beliebig Datenverkehr mitlesen. Insbesondere dann nicht, wenn Datenverkehr über Netzwerkpfade übertragen wird, die am Angreifer „vorbeigehen“ (sogenannte Off-Path-Szenarien). Bei Redirect-Angriffen (oder Routing-Angriffen) handelt

6.2 Angriff

195

Abb. 6.2 Beispielszenario für einen Redirect-Angriff: Mallory gibt sich als Router aus und bringt Bob dazu, an Alice gerichtete Nachrichten über ihn (statt über Router R2) zu senden

es sich um solche, die den Datenverkehr von Kommunikatoren umleiten, sodass diese den Angreifer zur Weiterleitung der Daten nutzen (siehe Abb. 6.2). Der Angreifer leitet als MitM oftmals tatsächlich (sämtliche) Daten weiter, damit die Kommunikation wie gehabt stattfinden kann. Allerdings versetzt sich der Angreifer damit auch in die Lage, Inhalte (bei verschlüsselter Kommunikation zumindest Metadaten) der Kommunikation mitlesen zu können. Zusätzlich kann der Angreifer alle typischen MitM-Angriffe durchführen, die in Abschn. 6.2.5 beschrieben wurden. Anders formuliert ermöglicht ein Redirect-Angriff in Off-Path-Szenarien überhaupt erst MitM-Angriffe. Redirect-Angriffe nutzen entweder ARP, ICMPv4/v6 oder dynamische Routingprotokolle aus. Diese Angriffe werden in Kap. 7 detailliert besprochen.

6.2.7

Denial-of-Service (DoS)

Manche Angriffe haben nicht das Ziel, sensible Daten zu erlangen oder Inhalte von Datenübertragungen zu manipulieren. Stattdessen sollen sie Systeme (oder die darauf angebotenen Dienste) außer Betrieb setzen. Solche Angriffe nennen sich Denial-ofService-Angriffe (DoS). DoS-Angriffe können von Benutzern lokal durchgeführt werden, aber auch über das Netzwerk. Dieses Buch behandelt in den nächsten Kapiteln verschiedene Varianten von DoS-Angriffen und erläutert, wie diese funktionieren. Meistens beruhen sie darauf, dass aus einem Datenpaket oder einer Anfrage eine Fülle an weiteren Datenpaketen generiert werden, die einen Host überlasten können. Ein überlasteter Host kann nicht mehr auf Anfragen reagieren und somit seinen Dienst nicht mehr erbringen. Dies gilt prinzipiell auch für überlastete Router, deren Funktion (Paketweiterleitung) durch einen erfolgreichen DoS-Angriff unmöglich gemacht werden kann.

196

6 Einführung in die Netzwerksicherheit

In den vergangenen Jahren wurden sogenannte Distributed DoS-Angriffe (DDoS) bedeutsamer. Das liegt daran, dass Botnetze (siehe Abschn. 3.7.1) mit einer großen Anzahl an Bots auf ein Ziel angesetzt werden können. Beispielsweise kann ein konkurrierender Onlinehändler mit einem DDoS-Angriff versuchen, das Onlineangebot seines Konkurrenten unerreichbar zu machen. Kunden, die dennoch einen solchen Dienst nutzen möchten, werden – so die Hoffnung des Angreifers – verstärkt das von ihm angebotene alternative Onlineangebot nutzen. Derartige DDoS-Anfragen lassen sich ohne spezielle Protokollkniffe realisieren. Stattdessen liegt die Wirkung in der reinen Masse – es werden einfach tausende von legitimen Anfragen pro Sekunde an wenige Server eines Opfers gestellt, sodass diese nicht mehr beantwortet werden können. Manche Dienstleister haben sich bereits darauf spezialisiert, DDoS-Angriffe durch extrem umfangreiche Netzwerkressourcen abzufangen. Ein betroffener Kunde kann einen derartigen Dienst mieten und DDoS-Angriffe auf einen solchen Anbieter umleiten (etwa über Umleitung von Domains im DNS). Bei extrem großen Botnetzen ist allerdings auch dieser Weg nicht unbedingt ausreichend, außerdem ist er mit entsprechenden Kosten für den betroffenen Anbieter verbunden. Da im Voraus nicht klar ist, wie lange ein DDoSAngriff anhalten wird – unter Umständen mehrere Wochen –, ist auch nicht klar, wie lange die Kosten für das Abfangen des Angriffs zu Buche schlagen werden. Aus dieser Tatsache ist ersichtlich, dass DDoS-Angriffe im schlimmsten Fall auch den finanziellen Ruin (oder den Totalausfall) einer Organisation zur Folge haben können. Außerhalb von Unternehmen sei hierbei noch angemerkt, dass DDoS-Angriffe auch militärische Streitkräfte und versorgungstechnische Einrichtungen wie Krankenhäuser angreifen können. Ein neuer Trend besteht zudem darin, DDoS-Angriffe hochfrequent und mit sehr geringer Zeitdauer zu realisieren, was Administratoren die realistische Chance verwehrt, auf diese Angriffe reagieren zu können. Eine spezielle Form des DoS-Angriffs sind Permanent-DoS-Angriffe (PDoS). Diese Angriffsform wurde etwa durch die Schadsoftware BrickerBot [3] hervorgerufen und führt zu einem permanenten Ausfall eines Geräts. Ein PDoS kann auf einem Gerät etwa dadurch hervorgerufen werden, dass es einem Angreifer durch Ausnutzung einer Sicherheitslücke gelingt, sämtliche Daten, inklusive Betriebssystem, zu löschen.

6.2.8

Exploits

Exploits sind Schadsoftware, die Verwundbarkeiten ausnutzen. Sie dienen entsprechend dazu, Angriffe auf verwundbare Software durchzuführen. Sie ermöglichen in der Folge meist den Zugang zu Systemen beziehungsweise das Erlangen höherer Privilegien (etwa Administratorrechte) auf den Zielsystemen. Gefährlich sind insbesondere Zero-Day-Exploits; diese nutzen in der Öffentlichkeit und bei den Herstellern noch nicht bekannte Schwachstellen aus und können entsprechend kaum abgefangen werden. Schließlich hatten Hersteller aufgrund der Unkenntnis über die jeweilige Lücke noch keine Möglichkeit, Updates für ihre Software zu entwickeln

6.2 Angriff

197

und zu verbreiten. Zero-Day-Exploits werden auf dem Schwarzmarkt teilweise für sehr hohe Beträge verkauft, abhängig von der Verbreitung der betroffenen Software und der Nützlichkeit, die sich durch das Ausnutzen der entsprechenden Verwundbarkeit ergibt.

6.2.9

Social Engineering und Advanced Persistent Threats

Das Thema der benutzbaren IT-Sicherheit betrachtete bereits Abschn. 3.8. Über die menschliche Ebene sind allerdings auch Angriffe auf Netzwerke möglich. Die entsprechende Angriffstechnik wird als Social Engineering bezeichnet und ist seit Jahrzehnten bekannt und verbreitet. Tatsächlich hat es Social Engineering auch in diverse HollywoodFilme geschafft. Beim Social Engineering wird eine Person unwissentlich dazu gebracht, eine für einen Angreifer nützliche Aktion auszuführen. Das klassische Beispiel für Social Engineering sind Phishing-E-Mails, bei denen versucht wird, jemandem einen Link für eine gefälschte Webseite unterzujubeln, etwa eine Seite für das Onlinebanking, oder ihn zur Herausgabe sensitiver Informationen zu bewegen. Manchmal soll eine Zielperson auch dazu gebracht werden, eine Hintertür zu installieren. Falls die Zielperson auf eine Webseite gelotst wird, soll sie dabei meist ihre Zugangsdaten für das Onlinebanking oder für andere Onlinedienste eingeben. Entsprechende Webseiten werden eigens für Phishing-Kampagnen erstellt und sind kaum vom Original zu unterscheiden.2 In Phishing-E-Mails bitten die Absender ihre Opfer in der Regel darum, „alte Informationen“ zu aktualisieren oder aufgelistete Informationen zumindest zu bestätigen [4]. Social Engineering kann allerdings auch offline erfolgen, etwa über das Telefon. Dazu gibt sich eine Person als Kollege, am besten Administrator, aus und verlangt beispielsweise das Passwort für einen E-Mail-Zugang zur „Umstellung auf das neue System“. Viele Szenarien dieser Art sind denkbar; selbstverständlich auch in Form von Phishing-E-Mails. Sehr bekannt wurde ein Angriff auf Lockheed Martin, einen amerikanischer Rüstungskonzern. Der erste Angriffsschritt bestand dabei aus Phishing-E-Mails, die einen Mitarbeiter dazu brauchten, einen Anhang (Excel-Datei mit einer Schadsoftware, die einen Zero-Day-Exploit verwendete) zu öffnen [5]. In der Folge hatten die Angreifer eine Hintertür zum Netzwerk von Lockheed Martin. Der Angriff endete mit der Exfiltration sensitiver Daten. Phishing hat den Vorteil, dass es eine Möglichkeit bietet, die teils umfangreichen technischen Sicherheitsmaßnahmen von Organisationen zu umgehen [6]. Das verbleibende schwächste Glied kann in solch einem Fall der Mensch sein. In Fällen, wie dem Angriff auf Lockheed-Martin, bei dem nicht Massen-E-Mails verschickt werden, sondern optimierte und personalisierte E-Mails an ausgewählte Zielpersonen verschickt werden, spricht man auch von Spear Phishing [6]. Solche Angriffe beziehen oft ein ausführliches Vorwissen

2 Dazu trägt auch das in Abschn. 7.5.3 besprochene Domain Fuzzing bei.

198

6 Einführung in die Netzwerksicherheit

über eine Person ein und können Teil von Advanced Persistent Threats (APTs) sein. APTs sind umfassende Angriffe, die teils mit mehrjähriger Vorbereitung und perfektionierten Social-Engineering-Angriffen sowie hohem Personal- und Finanzeinsatz durchgeführt werden. Die daraus resultierenden Phishing-E-Mails und weiteren Angriffe sind kaum detektierbar.

6.3

Verteidigung

Die Verteidigung eines Netzwerkes beziehungsweise eines einzelnen Hosts kann auf verschiedene Weisen erfolgen. Zunächst einmal gibt es passive Maßnahmen, die dafür sorgen können, dass ein Bewusstsein über stattfindende Angriffe und deren technische Möglichkeiten entsteht (etwa durch Intrusion Detection Systems und Honeynets), die aber keinen Angriff limitieren oder verhindern können.3 Auf der anderen Seite gibt es allerdings auch aktive Maßnahmen (etwa Firewalls und Intrusion Prevention Systems), die Angriffe eingrenzen/limitieren beziehungsweise verhindern können. Wir betrachten diese Ansätze im Folgenden separat. Tab. 6.1 gibt einen Überblick über die in diesem Abschnitt besprochenen grundlegenden Schutzmaßnahmen.

6.3.1

Firewalls

Firewalls verbinden Netzwerke miteinander, ähnlich wie Router, und sind wohl der grundlegendste und bekannteste Ansatz zur Schaffung von Netzwerksicherheit. Der Unterschied zu Routern besteht primär darin, dass Firewalls Datenverkehr basierend

Tab. 6.1 Übersicht über die wichtigsten Schutzmaßnahmen für Netzwerke Maßnahme

aktiv

passiv

Firewalls Intrusion detection systems Intrusion prevention systems Honeypots/-nets Sandboxing Threat intelligence

y – y durch Ablenkung y indirekt (durch Verbesserung der anderen Maßnahmen)

– y – y durch reporting y

3 Mit der Ausnahme, dass Honeynets die Aufmerksamkeit eines Angreifers auf sich und weg von

einem zu schützenden System ziehen können. Ist das eigentlich zu schützende System außerhalb des Honeynets allerdings in den Fokus des Angreifers geraten, so hilft das Honeynet nicht mehr aktiv beim Schutz dieses Systems.

6.3 Verteidigung

199

auf Regelsätzen weiterleiten beziehungsweise blockieren. Blockieren bedeutet hierbei, dass die Firewall eintreffende Pakete verwirft, statt sie weiterzuleiten. Firewalls sind ein äußerst bewährtes Mittel zur Absicherung von Netzwerkgrenzen und praktisch in allen Netzwerken im Einsatz, oftmals auch auf Endgeräten. Man unterscheidet zwischen zwei Arten von Firewalls. Zum einen gibt es Personal Firewalls, die Endnutzer auf einem Endgerät (üblicherweise ein PC oder Smartphone) installieren. Derartige Firewalls sind weniger detailliert konfigurierbar, da sie Benutzerfreundlichkeit in den Fokus stellen und Daten eher selten weiterleiten müssen. Im Gegensatz zu Personal Firewalls sind Network Firewalls auf Kopplungselementen im Netzwerk installiert, etwa auf Routern. Sie sind die für dieses Buch interessanten Firewalls. Im simpelsten Fall analysieren Firewalls den Datenverkehr paketweise. Das heißt, jedes neu eintreffende Paket wird unabhängig von den vorher gesichteten Paketen bewertet. Stateful-Firewalls gehen einen Schritt weiter, sie merken sich wichtige vorherige Pakete und können neu eintreffende Pakete daher in den Kontext der vorherigen Pakete setzen. Zum Beispiel könnte ein TCP SYN-ACK-Paket eines Verbindungsaufbaus als tatsächlich zu einem Verbindungsaufbau gehörend kategorisiert werden, wenn zuvor ein SYN-Paket versendet wurde. Entsprechend müssen Stateful-Firewalls bi-direktional arbeiten. Ein klassisches Problem von Firewalls besteht darin, dass Sie nicht immer mit Tunneln umgehen können. Wenn etwa ein zu blockierendes IP-Paket innerhalb eines anderen IP-Pakets eingekapselt wurde, muss die Firewall explizit auch das eingekapselte Paket analysieren, das heißt, seine Regelsätze darauf anwenden. Eine entsprechende Konfiguration ist allerdings nicht trivial, da sich Adressierung und Kontext eingebetteter Pakete von den äußeren Paketen unterscheiden. Wir betrachten selektierte weiterführende Aspekte der Firewalls in Kap. 8.

6.3.2

Intrusion Detection und Prevention

Sogenannte Intrusion Detection Systems (IDS) sind Programme, die Angriffe erkennen können. Reine IDS sind passiv, das heißt, sie sind nicht in der Lage, detektierte Angriffe abzuwehren. Wenn ein IDS einen Angriff erkennt, dann wird dieser protokolliert und gemeldet. Ein Intrusion Prevention System (IPS) wäre dazu hingegen in der Lage, indem zum Beispiel sofort nach einem detektierten Angriffsversuch die Firewallregeln so modifiziert werden, dass Pakete vom angreifenden Host geblockt, oder gar Dienste deaktiviert werden [7]. IPS müssen allerdings nicht notwendigerweise eine Angriffserkennung umsetzen. Ein IPS ist daher nicht automatisch eine Erweiterung eines IDS. Ein IPS könnte Regeln auch unabhängig davon auslösen, ob es Daten als „Angriffe“ bewertet, sondern beispielsweise auf Basis präventiver Regelsätze. Es gibt verschiedene Arten von IDS und IPS. Zum einen gibt es hostbasierte IDS (HIDS), das heißt solche, deren Sensoren sich auf ein lokales System beziehen und etwa Veränderungen an der Systemkonfiguration detektieren können. Ein Beispiel für ein HIDS ist ein Dateisystem-IDS (engl. Filesystem IDS), welches das Dateisystem periodisch auf

200

6 Einführung in die Netzwerksicherheit

Veränderungen hin scannt. Neben den HIDS gibt es netzwerkbasierte IDS (NIDS), die Netzwerksensoren auswerten, also im Wesentlichen eingehende (und ausgehende) Pakete protokollieren und ihre Inhalte analysieren. Ein NIDS könnte etwa HTTP-Anfragen nach kritischen Strings durchsuchen, die bekannterweise von Verwundbarkeitsscannern für Webservices stammen. Das aktive Gegenstück zum NIDS wäre ein netzwerkbasiertes IPS (NIPS). Es könnte potenziell schädlichen Datenverkehr normalisieren4 und blockieren. Manche netzwerkbasierte Lösungen verfügen sowohl über NIDS- als auch über NIPSKomponenten. Ein Beispiel hierfür ist Snort. Neben NIDS und HIDS existieren noch Varianten, die sowohl Host- als auch netzwerkbasierte Sensoren auswerten. Solche Systeme werden als Hybride IDS bezeichnet. Im Wesentlichen kann eine Angriffserkennung mit drei verschiedenen Ansätzen realisiert werden: der anomaliebasierten Erkennung, der signaturbasierten Erkennung und der spezifikationsbasierten Erkennung [8].

6.3.2.1 Anomalieerkennung Anomalieerkennung basiert darauf, dass statistische Modelle von einer Umgebung erstellt werden. Auf Basis dieser Modelle können Abweichungen vom Normalfall detektiert werden. In den vergangenen Jahren wurde verstärkt darauf gebaut, maschinelle Lernverfahren zu entwickeln, um Anomalien erkennen zu können. Derartige Lernverfahren sowie Ansätze, die ohne maschinelles Lernen auskommen, etwa eine Entropieanalyse, können allerdings nur so gut sein, wie es die vorhandenen Daten sind. Collins merkt an, dass hybride Datenquellen, das heißt die Kombination unterschiedlicher Sensortypen, favorisierbar sind [9], da sie die Kombination von unterschiedlichsten Informationstypen erlauben. Er verdeutlicht diese Aussage anhand eines Beispiels: Wenn ein Botnetz netzwerkbasierte Angriffe tätigt und auf Zielsystemen Exploits ausführt, dann wäre es sowohl interessant, den Datenverkehr zu beobachten, als auch interessant, lokale Sicherheitsinformationen von den jeweiligen Hosts zu erhalten. Gute Daten wiederum führen noch nicht zu guten Detektionsresultaten. Stattdessen bedarf es eines guten Verständnisses der jeweiligen Daten sowie der Methoden, die auf diese Daten angewandt werden [9]. Wenn eine Anomalieerkennung Ereignisse in nur zwei Gruppen einteilt – in der Regel die Gruppen „ein Angriff liegt vor“ und „es liegt kein Angriff vor“ –, spricht man auch von einer binären Klassifikation (engl. Binary Classification). Eine gute Anomalieerkennug muss in der Lage sein, eine binäre Klassifikation mit wenigen False Positives (FP) und False Negatives (FN) umzusetzen. Das heißt fälschlicherweise als Angriff beziehungsweise fälschlicherweise als Nichtangriff erkannte Ereignisse sollten möglichst selten auftreten, während die Raten der True Positives (TP, korrekt erkannte Angriffe) und der True Negatives (TN, korrekt erkannter legitimer Datenverkehr) möglichst hoch ausfallen. Dies ist schwierig, da ein Großteil des zu analysierenden

4 Man spricht in diesem Fall von einem Traffic Normalizer.

6.3 Verteidigung

201

Datenverkehrs im Normalfall legitimer Natur ist. Bei Daten, die von einem NIDS kommen, kann der Anteil an legitimen Daten deutlich geringer ausfallen, da das NIDS bereits vorfiltert und selbst nur solche Daten liefert, die seiner Logik nach einem True Positive entsprechen. Um die Qualität einer Anomalieerkennug zu beurteilen, lassen sich die sogenannte Precision (auch Positive Predictive Value) und der Recall (auch Sensitivity) berechnen. Die Precision gibt an, wie hoch der Anteil der korrekt als Angriff klassifizierten Ereignisse an der Gesamtzahl der als Angriff klassifizieren Ereignisse ist: precision =

TP . TP + FP

(6.1)

Der Recall gibt hingegen an, wie die Anzahl korrekt als Angriff klassifizierter Ereignisse im Verhältnis zur Gesamtzahl der Angriffsereignisse ausfällt: recall =

TP . TP + FN

(6.2)

Ein weiteres Beurteilungskriterium, das für die Beurteilung einer Anomalieerkennung verwendet werden kann, ist die Specificity (auch True Negative Rate). Specificity gibt den Anteil der korrekt als False kategorisierten Elemente an. specificity =

TN . TN + FP

(6.3)

Nehmen wir an, ein NIDS soll HTTP-basierte Angriffe pro TCP-Verbindung erkennen und diese in „harmlos“ oder „Angriff“ einordnen. Dann würde die Specificity den Anteil der korrekt als harmlos kategorisierten Verbindungen von der Gesamtzahl der tatsächlich harmlosen Verbindungen (inklusive der fälschlicherweise als „Angriff“ eingeordneten) angeben.

6.3.2.2 Signaturbasierte Erkennung Bei der signaturbasierten Angriffserkennung werden feste Regeln definiert, die einen Angriff explizit beschreiben. So kann etwa eine Regel definiert werden, die beschreibt, dass ein Portscan ab einer bestimmten Anzahl von unterschiedlichen angefragten Ports eines Senders pro Zeitfenster vorliegt. Das folgende Beispiellisting zeigt die PortscanKonfiguration für das NIDS Snort. Dabei wird konfiguriert, dass Snort bis zu 64 potenzielle Scanner-Hosts gleichzeitig analysieren soll und das dabei bis zu 128 Zielsysteme (die gescannten Hosts) betrachtet werden sollen – im Wesentlichen sind dies Performanceparameter, da Snort all diese Daten zwischenspeichern muss. Außerdem wird festgelegt, dass eine Portscan-Detektion vorliegt, wenn ein Angreifer mindestens einen Host scannt (target_limit) und dabei mindestens fünf Ports anfragt (port_limit). Diese Portanfragen müssen wiederum innerhalb von 30 Sekunden geschehen (timeout).

202

6 Einführung in die Netzwerksicherheit

preprocessor portscan2 : \ scanners_max 64 , \ targets_max 64 , \ target_limit 1, \ p o r t _ l i m i t 10 , \ t i m e o u t 60 Auf ähnliche Weise können beispielsweise fehlerhafte Loginversuche pro Zeit festgelegt oder Strings definiert werden, nach denen im Payload von Paketen gesucht werden soll – hierbei könnte etwa nach bekannten Exploit-Codes gesucht werden, ähnlich einem Antiviren-Scanner. Die Regeln des IDS werden auch als Signaturen bezeichnet und in einer Signaturdatenbank abgelegt. Bei Bekanntwerden neuer Angriffe müssen die entsprechenden Signaturen für diese Angriffe erstellt und in die Signaturdatenbank eingetragen werden. In Kap. 8 werden einzelne Aspekte zum Thema NIDS vertieft, insbesondere das Thema der Portscan-Erkennung.

6.3.2.3 Spezifikationsbasierte Erkennung Mit signaturbasierter Angriffserkennung können keine unbekannten Angriffe detektiert werden, da alle Angriffssignaturen explizit vorgegeben werden müssen. Anders verhält es sich mit NIDS, die Anomalien als Abweichung vom Normalverhalten verstehen (anomaliebasierte Erkennung). Ähnlich verhält es sich bei der sogenannten spezifikationsbasierten Angriffserkennung. Bei dieser wird zunächst festgelegt, welche Kommunikation beziehungsweise welche Ereignisse konform einer Spezifikation sind. Beispielsweise kann ein Netzwerkprotokoll formal beschrieben werden, etwa mit einer formalen Grammatik. Wenn das NIDS nun Pakete des Protokolls erhält, die nicht der Spezifikation entsprechen, dann liegt eine Abweichung von der Spezifikation vor. Ein Beispiel hierfür sind auf „1“ gesetzte Headerbits, die im Normalfall auf „0“ gesetzt wären, weil diese Headerbits gemäß Protokollstandard reserviert sind. Dies wäre etwa beim reservierten Bit im IPv4-Header der Fall. Eine Abweichung von einer Spezifikation kann ein Angriff sein, muss es jedoch nicht. Es kann sich genauso um einen Übertragungsfehler oder um einen Softwarefehler handeln. Aus diesem Grund muss die Art der Abweichung ebenfalls bewertet und gegebenenfalls in den Kontext vorheriger Pakete gesetzt werden (Stateful-Analyse).

6.3.3

Honeypots und Honeynets

Manchmal kann es sich als nützlich erweisen, potenziellen Angreifern lukrative Ziele vorzusetzen; besser gesagt, lockt man Angreifer auf diese Systeme, genannt Honeypots. Ein Honeypot, dt. Honigtopf, ist ein System, das nur so erscheint, als ob es ein (einfach zu übernehmendes und zugleich) interessantes Ziel für einen Angreifer ist. Tatsächlich sind

6.3 Verteidigung

203

keinerlei sensitive Daten oder kritische Dienste auf einem Honeypot installiert. Honeypots werden aufgesetzt, um mindestens eines der folgenden Ziele zu erreichen: 1. Man möchte potenzielle Angreifer von den eigentlichen, schützenswerten Systemen eines Netzwerks fernhalten und sie deshalb auf ein Honeypot locken. Die Zeit, die ein Angreifer damit zubringt, sich mit dem Honeypot zu beschäftigen, kann verwendet werden, um den Angriff erstens zu detektieren und den Angreifer auszusperren. Zweitens können, während sich ein Angreifer mit dem Honeypot beschäftigt, Vorkehrungen zum erweiterten Schutz der tatsächlich wichtigen Systeme getroffen werden. 2. Man möchte Angriffe studieren, um etwa neue Angriffstechniken zu sichten. Angreifer könnten diese Angriffstechniken auf einem Honeypot anwenden. Dem Angreifer bringt dies nichts, aber da Honeypots sämtlichen Datenverkehr und die auf dem Honeypot durchgeführten Aktionen protokollieren können, ist es beispielsweise denkbar, neue Zero-Day-Exploits zu sichten oder neue Muster in Angriffen aufzuzeichnen, die später für maschinelle Lernverfahren genutzt werden können. Mehrere Honeypots können auch zu einem Honeynet zusammengeschlossen werden. Gute Honeypot-Software kann mehrere Systeme, ganze Netze, auf einem einzelnen Rechner simulieren. Somit können beispielsweise Produktionsnetze mit mehreren Komponenten simuliert werden. Der Bedarf an Hardware für ein Honeynet ist durch die ausgefeilten Simulationsmöglichkeiten und die Kombination von vielen Honeypots auf einem einzigen Server nicht sonderlich groß. Ausnahmen bilden Fälle, bei denen etwa eine hochgradig realistische Industriesteueranlage simuliert werden soll; sie kann durch echte (aber kostspielige) Hardware bereichert werden. Das zeitliche Verhalten echter Hardwarekomponenten muss schließlich nicht simuliert werden, es ist somit tatsächlich authentisch. Insbesondere sind derlei Hardwareerweiterungen einer Honeypot-Software sinnvoll, wenn neue Angriffstechniken auf spezifische Hard- und Softwarekomponenten (etwa solche, die ein Unternehmen tatsächlich in Automationsumgebungen einsetzt) gefunden werden sollen. Honeypots teilen sich in virtuelle und physikalische Varianten auf [10]: Ein virtueller Honeypot ist eine Software, die sich innerhalb eines Hosts befindet, der Daten an ein Honeypot weiterleitet. Ein physikalischer Honeypot ist hingegen ein eigenständiger Computer; ein Angreifer kommuniziert entsprechend direkt mit diesem Computer. Der Nachteil physikalischer Honeypots sind die durch den Bedarf an mehr Hardware begründeten Kosten (virtuelle Honeypots können sich schließlich einen physikalischen Host teilen). Beim Aufsetzen eines neuen Honeypots muss entschieden werden, ob ein lowinteraction (LI) oder ein high-interaction (HI) Honeypot aufgesetzt werden soll [10]: Ein LI-Honeypot bietet wenige Dienste, wenige Überwachungsmöglichkeiten und bietet dem Angreifer insgesamt wenig Spielraum. Die dadurch zu gewinnenden Erkenntnisse sind relativ eingeschränkt. Ein HI-Honeypot wird hingegen auf einer physikalischen Umgebung umgesetzt, bietet viele, teils hochgradig authentisch und mit viel Aufwand umgesetzte Dienste, die detailliert protokollieren. Angreifer können ein HI-Honeypot

204

6 Einführung in die Netzwerksicherheit

potenziell leichter beeinträchtigen, doch können auch mehr Informationen über das Vorgehen eines Angreifers gesammelt werden [10]. Außerdem ist nach Nawrocki et al. der administrative Aufwand höher, als bei LI-Honeypots. Neben LI- und HI-Honeypots sind beliebig Zwischenvarianten möglich, die man auch als medium-interaction (MI) Honeypots bezeichnet [10].

6.3.4

Sandboxing

Zumindest grundlegende Parallelen zu Honeypots weisen sogenannte Sandboxes, zu deutsch Sandkästen, auf. Eine Software erhält durch eine Sandbox eine rechtlich eingeschränkte Umgebung. Eine solche Software kann prinzipiell auch jeder Netzwerkdienst sein. Sollte es sich bei der Netzwerksoftware um Schadsoftware handeln oder sollte die Netzwerksoftware durch einen Angreifer attackiert werden, so kann sie nur innerhalb der Sandbox Schaden anrichten.5 Beispielsweise kann mithilfe von Sandboxes festgelegt werden, auf welche Verzeichnisse, Bibliotheken und Systemaufrufe ein Webserver Zugriff bekommen darf.

6.3.5

Threat Intelligence

Threat Intelligence bedeutet, Informationen über mögliche (bevorstehende) Angriffe, Angriffstechniken und Verwundbarkeiten zu sammeln, auszuwerten und gegebenenfalls zum eigenen Vorteil zu nutzen. Threat Intelligence wird folglich von Organisationen angewandt, die sich über mögliche/bevorstehende Gefahren und Angriffe informieren möchten, um zeitnah auf diese reagieren zu können. Die Definition von Friedman und Bouchard spiegelt diese Ziele wider: Cyber threat intelligence is knowledge about adversaries and their motivations, intentions, and methods that is collected, analyzed, and disseminated in ways that help security and business staff at all levels protect the critical assets of the enterprise [11].

Diese Definition unterstreicht die Bedeutung der jeweiligen Assets, das heißt der zu schützenden Güter, etwa bestimmte Daten (siehe Abschn. 3.3). Um mit Threat Intelligence eine passende Bewertung von Bedrohungen durchführen zu können, ist daher die Identifikation von Assets als vorgeschalteter Schritt notwendig. Durch Threat Intelligence angehäufte Informationen werden durchaus zwischen Organisationen ausgetauscht, dazu können diese Informationen anonymisiert beziehungsweise

5 Es sei denn, die Sandbox selbst wird angegriffen, wodurch ein Angreifer potenziell aus ihr entkommen und damit Zugriff auf das eigentliche System bekommen kann. Eine Sandbox ist allerdings in jedem Fall eine zusätzliche, Sicherheit schaffende Angriffshürde.

6.4 Zusammenfassung

205

pseudonymisiert werden (siehe etwa Sykosch et al. [12] für einen entsprechenden Ansatz). Für die Threat Intelligence relevante Informationen können dabei innerhalb und außerhalb von Organisationen gesammelt werden [13]; innerhalb können etwa NIDS und HIDS sowie Botnetze Hinweise auf Angriffsmethoden liefern; außerhalb einer Organisation stellen diverse Unternehmen relevante Informationen bereit, etwa durch Publikation neuer Schwachstellen. Externe Informationen können zudem von Regierungsund Polizeibehörden wie dem BSI, Europol oder der ENISA stammen. Reaktionsmöglichkeiten auf neue Bedrohungen sind hochgradig kontextabhängig. Beispielsweise könnte ein neuer Zero-Day-Exploit bekannt werden, der angewandt werden könnte, um die Software anzugreifen, die als Maildienst der jeweiligen Organisation zum Einsatz kommt. In solchen Fällen kann versucht werden, den Maildienst zu schützen, indem etwa das verwundbare Modul temporär deaktiviert wird (bis ein Patch verfügbar ist). Einbezogen werden in die Threat Intelligence seit einiger Zeit auch Informationen aus dem Darknet, also auf dem Mix-Prinzip aufbauenden Netzwerken, die als OverlayNetzwerk auf Basis des Internets realisiert werden, und mit Programmen wie Tor zugänglich sind (siehe Abschn. 5.4). Robertson et al. haben in [14] gezeigt, dass Informationen aus dem Darknet dazu verwendet werden können, um Threat Intelligence zu betreiben. Im Darknet werden Zero-Day-Exploits gehandelt und Angriffe auf Organisationen koordiniert. Außerdem kann Threat Intelligence dabei helfen, Strukturen des Darknets sichtbar zu machen (welche Anbieter bieten welche Produkte auf welchen Darknet-Marktplätzen an und stehen mit welchen anderen Portalen und Usern in Verbindung) [14]. Gelingt es einer Organisation (etwa einem Industrieunternehmen oder einer Polizeibehörde), sich als vertrauenswürdiges Mitglied in den entsprechenden Untergrundforen zu bewegen, so kann mit etwas Glück frühzeitig in Erfahrung gebracht werden, dass Angriffe geplant sind. Um Threat Intelligence im Darknet durchführen zu können, müssen Teilnehmer sich als potenzielle Kunden oder zumindest vertrauenswürdige Teilnehmer ausgeben; das Vertrauen (engl. Trust) ist ein Kernkriterium, um im Darknet an Informationen zu gelangen beziehungsweise überhaupt Zugriff auf relevante Diskussionsforen zu erlangen [14]. Mithilfe maschineller Lernverfahren können einige Aspekte der Threat Intelligence im Darknet automatisiert werden, jedoch funktioniert dies nur dann, wenn etwa CAPTCHAs (statt ausgiebiger persönlicher Interviews) absolviert werden müssen, um Zugriff auf Foren zu erlangen [14].

6.4

Zusammenfassung

Dieses Kapitel betrachtete zunächst Angriffsmethoden, die auf Netzwerkebene stattfinden. Anschließend wurden grundlegende Gegenmaßnahmen eingeführt. Zentrale Angriffstechniken sind das Netzwerk-Scanning, Protocol Fuzzing, Wardriving für Funknetzwerke, das Sniffen, Man-in-the-Middle-Angriffe, Redirect-Angriffe, die Da-

206

6 Einführung in die Netzwerksicherheit

tenverkehr umleiten, Denial-of-Service-Angriffe, das Ausnutzen von Sicherheitslücken in Software durch Exploits und soziale Angriffe (Phishing). Die bedeutsamsten Verteidigungstechniken sind das Filtern von unerwünschtem Datenverkehr durch Firewalls, das Erkennen und Abwehren von Angriffen durch Intrusion Detection und Intrusion Prevention, sowie das Studieren neuer Angriffstechniken durch Honeypots. Ebenfalls bedeutsam ist die Einkapselung von potenziell schädlichen Netzwerkdiensten in Sandboxes, damit sie nur eingeschränkt Schaden anrichten können. Durch Threat Intelligence können Organisationen einen Überblick über aktuelle und aufkommende Gefahren, etwa geplante Angriffe, erhalten.

6.5

Weiterführende Literatur

Eine Zusammenfassung der IDS-Ansätze für Wireless Sensor Networks (WSN) findet der interessierte Leser in einer Publikation von Butun et al. [8] (allerdings von 2014) und eine ausführliche – und zugleich empfehlenswerte – Studie zu Honeypots liegt dank Nawrocki et al. ebenfalls vor [10]. Das Buch Darkweb Cyber Threat Intelligence Mining [14] zeigt auf, wie Informationen aus dem Darknet und dem Darkweb verwendet werden können, um (etwa mithilfe maschineller Lernverfahren) Threat Intelligence zu betreiben.

6.6

Übungsaufgaben

1. Recherchieren Sie, welche Rechte ein Benutzer auf einem Rechner benötigt, um eine Netzwerkschnittstelle in den Promiscuous Mode zu versetzen. Probieren Sie es einmal selbst aus. 2. Was ist Phishing und was macht Phishing zu Spear Phishing? 3. Firewalls können stateful arbeiten. Welchen Vorteil bietet diese Arbeitsweise? Welcher Nachteil muss dafür gegebenenfalls in Kauf genommen werden? 4. Worin besteht der Unterschied zwischen einem host- und einem netzwerkbasierten Intrusion Detection System? 5. Grenzen Sie anomaliebasierte von signaturbasierter und von spezifikationsbasierter Angriffserkennung ab. 6. Was ist ein Honeypot und für welche Einsatzzwecke kann es dienen? 7. Worin unterscheiden sich virtuelle und physikalische Honeypots? 8. Sie möchten neuartige Angriffe auf ein bestimmtes System studieren und möchten alle denkbaren Dienste des Systems anbieten, und zwar realistisch. Eignet sich für diesen Zweck potenziell eher ein LI-, MI- oder HI-Honeypot? 9. Wozu dient Threat Intelligence?

Literatur

207

Literatur 1. Caviglione, L.: Wireless wardriving. In: Zhang, Y. (Hrsg.) (ed.) Handbook of Research on Wireless Security, S. 61–77. IGI-Global, Hershey (2008) 2. Owasp.org: Fuzzing (2017). https://www.owasp.org/index.php/Fuzzing. Zugegriffen am 01.06.2018 3. Radware: „BrickerBot“ results in PDoS attack (2017). https://security.radware.com/ddosthreats-attacks/brickerbot-pdos-permanent-denial-of-service/. Zugegriffen am 01.06.2018 4. Jahankhani, H., Al-Nemrat, A., Hosseinian-Far, A.: Cybercrime classification and characteristics. In: Akhgar, B., Staniforth, A., Bosco, F. (Hrsg.) (Hrsg.) Cyber Crime and Cyber Terrorism Investigator’s Handbook. Syngress, Waltham (2014) 5. Davey, G.: Information Security Research – Analysis of RSA-Lockheed Martin Attack (2016). https://de.slideshare.net/GavinDavey2/analysis-of-rsa-lockheed-martin-attack. Zugegriffen am 01.06.2018 6. Hong, J.: The state of phishing attacks. Commun. ACM (CACM) 55(1), 74–81 (2012). ACM 7. Miyamoto, M.: Intrusion Detection und Intrusion Response Systeme (IDS & IRS), Seminararbeit an der Ruhr-Universität Bochum (2001) 8. Butun, I., Morgera, S.D., Sankar, R.: Survey of intrusion detection systems for wireless sensor networks. IEEE Commun. Surv. Tutor. 16(1), 266–282 (2014). IEEE 9. Collins, M.: Network Security Through Data Analysis, 2. Aufl. O’Reilly, Sebastopol (2017) 10. Nawrocki, M., Wählisch, M., Schmidt, T.C., Keil, C., Schönfelder, J.: A Survey on Honeypot Software and Data Analysis, ArXiV Pre-print (2016) 11. Friedman, J., Bouchard, M.: Definitive Guide to Cyber Threat Intelligence. Cyberedge Press, Annapolis (2015) 12. Sykosch, A., Neff, R., Meier, M.: Policy-driven Pseudonymization. In: Proceedings of the Security Research Conference „Future Security“, S. 445–452. Fraunhofer Verlag, Stuttgart (2014) 13. Bromiley, M.: Threat intelligence: What it is, and how to use it effectively. SANS organization (2016) 14. Robertson, J., Diab, A., Marin, E., Nunes, E., Paliath, V., Shakarin, J., Shakarin, P.: Darkweb Cyber Threat Intelligence Mining. Cambridge University Press, London (2017)

7

Angriffe auf TCP/IP-Netzwerkprotokolle

The TCP/IP protocol suite, which is very widely used today, was developed under the sponsorship of the Department of Defense. Despite that, there are a number of serious security flaws inherent in the protocols. – Steven Bellovin (1989)

Zusammenfassung

Dieses Kapitel befasst sich mit Angriffen auf die Netzwerkprotokolle der verschiedenen Schichten des TCP/IP-Modells. Beginnend mit der untersten Schicht des TCP/IPModells werden schließlich Angriffe auf die Anwendungsschicht erläutert.

7.1

Einführung

Dieses Kapitel deckt eine breite Fülle von Angriffstypen und -techniken ab. Die Angriffe werden dabei protokollspezifisch dargelegt. Es beginnt mit Angriffen auf die physikalische Schicht, behandelt anschließend die Internet- sowie die Transportschicht und zuletzt die Anwendungsschicht. Manche Angriffe unterschiedlicher Schichten und Protokolle funktionieren sehr ähnlich. Das liegt daran, dass Protokolle zum Teil ähnliche Funktionen aufweisen (etwa UDP und TCP – beide arbeiten portbasiert) oder voneinander abhängig sind (eine gefälschte IP-Adresse kann zum Beispiel für ICMP-basierte und für TCPbasierte Angriffe dienen).

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2018 S. Wendzel, IT-Sicherheit für TCP/IP- und IoT-Netzwerke, https://doi.org/10.1007/978-3-658-22603-9_7

209

210

7.2

7 Angriffe auf TCP/IP-Netzwerkprotokolle

Angriffe auf der Netzzugangsschicht

Das Kapitel betrachtet im Folgenden zunächst die IT-Sicherheit für die physikalische und grundlegend logische Übertragung von Daten (dies entspricht den OSI-Schichten 1 und 2 beziehungsweise der TCP-Schicht 1). Während einige der Angriffe auf dieser Schicht aufklärenden Charakter haben (siehe Abschn. 7.3.1 zum Thema Reconnaissance), dienen andere Angriffe der Beeinflussung von Zielnetzwerken.

7.2.1

Angriffe mit physikalischer Grobeinwirkung

Ein besonders grundlegender Angriff auf die Übertragung der untersten Kommunikationsschicht ist das Kappen einer Verbindung, etwa durch ein simples Zerschneiden eines Kabels. Verbindungen können böswillig oder unbeabsichtigt (beispielsweise durch Bauarbeiten mit einem Bagger vor dem Gebäude) durchtrennt werden. Es findet entsprechend nicht notwendigerweise ein Angriff statt, obwohl die Auswirkungen letztlich dieselben sind. Neben dem Kappen einer Verbindung können auch weitere grundlegende physikalische Angriffe durchgeführt werden, etwa das Zerstören von Geräten. Außerdem können Netzwerkkomponenten durch Diebstahl entwendet werden, um etwa die darauf gespeicherten Daten zu erlangen, oder um die Geräte weiter zu verkaufen.

7.2.2

Jamming

Angreifer können durch Jamming ein Kommunikationssignal stören, beispielsweise für Mobiltelefone oder Radioübertragungen. Dieses Vorgehen ist in den meisten Ländern illegal. Jammer-Geräte stören eine Verbindung im Wesentlichen durch Hinzufügen weiterer Signale, die die sogenannte Signal-to-Noise-Ratio (SNR) negativ beeinflussen, sodass das verwendete physikalische Kommunikationsmedium gar nicht oder nur minimal nutzbar ist.1

7.2.3

Eavesdropping (Sniffing)

Bereits auf Schicht 1 kann die Angreiferin Eve die Kommunikation zwischen den legitimen Kommunikatoren Alice und Bob mitlesen; hierbei handelt es sich um eine Form der Reconnaissance (vgl. Abschn. 7.3.1). Dies gilt zumindest dann, wenn die Kommunikation zwischen Alice und Bob nicht explizit gegen Abhören gesichert ist und Eve Zugriff auf

1 Die SNR wird über die Formel SNR = psignal berechnet. pnoise

7.2 Angriffe auf der Netzzugangsschicht

211

das Medium (etwa ein Kabel oder eine Funkverbindung) erlangen kann. Bezeichnet wird das illegitime Mitlesen von Nachrichten auch als Eavesdropping.2 Technisch betrachtet fängt Alice beim Eavesdropping Signale (auf physikalischer oder logischer Ebene, beispielsweise Ethernet Frames) ab. Teilweise können Frames zwar verschlüsselt werden, doch konzentriert sich die Verschlüsselung dann eher auf die eingebetteten Daten höherer Schichten. Eve kann entsprechend dennoch mehrere interessante Informationen abgreifen. Fängt Eve eine Frame des Ethernet-Protokolls ab, dann kann sie in jedem Fall folgende Informationen einsehen: • Wer sendet Daten? (Quelladresse, MAC) • An wen werden Daten gesendet? (Zieladresse, MAC) • Welches Protokoll der TCP/IP-Schicht 2 wird für die Kommunikation verwendet? Zur Feststellung des Protokolls liest Eve das Protocol-Feld der Frame aus. Typische Werte sind: – 0 × 0800 - IPv4 – 0 × 0806 - ARP – 0 × 86dd - IPv6 – 0 × 8892 - Profinet Mithilfe des Protokolls weiß Eve bereits, ob sie sich vermutlich in einem Automationsnetz befindet (Profinet). • Payload (ggf. teilverschlüsselt) Derartige Informationen lassen sich jedoch nicht nur im Standardfall von Ethernet erbeuten. Auch speziellere Protokolle wie MS/TP, das in automatisierten Gebäuden verwendet wird, bieten ähnliche Informationen. MS/TP liefert Eve etwa: • Frame Type (Poll for / Reply to Master (Reply); Test Request/Response; BACnet Data Expecting Reply; BACnet Data Not Expecting) • Quell- und Zieladresse • Payload (ggf. teilverschlüsselt)

7.2.4

Falsche Access Points

Ein weiterer wichtiger Angriffspunkt in Netzwerken sind Wireless Access Points. Bewohner, Besucher, Mitarbeiter und Kunden verbinden sich mit lokalen Netzwerken über ihre mobilen Endgeräte. Insbesondere in offenen Netzwerken von Hotels gibt es für Access

2 Der Begriff Eavesdropping wird im Campusroman Alle Seelen von J. Marías hervorragend erläutert.

212

7 Angriffe auf TCP/IP-Netzwerkprotokolle

Points typische Benennungen wie „Hotel XYZ Guest WiFi“. Ein Angreifer kann einen Access Point mit demselben Namen erstellen und darauf hoffen, das Hotelbesucher sich auf seinen Access Point verbinden. Die Hotelbesucher übertragen anschließend alle Daten über das System des Angreifers, der Eavesdropping durchführen kann. Weiterhin kann er die übertragenen Daten manipulieren. In solchen Umgebungen können Angreifer eigene Access Points bereitstellen. Ein ähnliches Szenario könnte man auch auf das bekannte „Eduroam“-Netzwerk anwenden (Eduroam ist weltweit an vielen Universitäten verfügbar). Ein Angreifer könnte ein vermeintlich sicheres „Eduroam“-Netzwerk aufsetzen, etwa an einer Hochschule oder an einem öffentlichen Platz. Zwar nutzt Eduroam Funktionen zur Authentifizierung und vorkonfigurierte Endgeräte werden eventuell auf Probleme bei der Authentifizierung hinweisen, eine neue Verbindung mit dem Netzwerk des Angreifers ist allerdings generell möglich.3

7.2.5

Sicherheit von ARP

Das ARP-Protokoll (Abschn. 2.5) dient der Übersetzung von TCP/IP-Adressen der Schicht 2 (IP) in solche der Schicht 1 (MAC-Adressen). ARP-Requests werden dabei per Broadcast verschickt. Zur Sicherheit ist zu sagen, dass ARP zumindest ein simples Schutzverfahren kennt. Es dient der Erkennung von Mehrfachzuweisungen von IP-Adressen an MAC-Adressen und dient der reinen Verfügbarkeitssteigerung. Dieses Verfahren wird ARP Probe genannt. Ein Rechner fragt dabei die für sich selbst angedachte IP-Adresse im Netzwerk nach und kann somit ausschließen, dass sie derzeit von einem anderen Host verwendet wird [5]. Wesentlich problematischer ist allerdings, dass ARP seine Nachrichten nicht authentifiziert. Auch gibt es keinen Mechanismus, der a priori sicherstellen kann, dass ein Sender, der vorgibt, eine bestimmte MAC-Adresse zu verwenden, diese tatsächlich oder zu jedem Zeitpunkt als einziger Rechner besitzt (ARP Probes können bei letzterem Punkt zumindest helfen). Daraus ergeben sich die beiden klassischen Angriffe auf ARP: ARP-Spoofing (auch ARP-Cache-Poisoning) sowie ARP-Cache-Flooding.

7.2.5.1 ARP-Spoofing Wenn Alice die MAC-Adresse von Bob erhalten möchte, dann sendet sie einen ARPRequest für die Auflösung der IP-Adresse von Bob an das Netzwerk. Bob antwortet mit einer ARP-Response, die seine gesuchte MAC-Adresse beinhaltet. Beim ARP-Spoofing (Abb. 7.1) sendet ein Angreifer (Eve) eine vermeintlich korrekte Antwort an den Rechner,

3 Eduroam-Netzwerke sind tatsächlich an vielen Orten verfügbar. Beim Joggen durch die Kennedyallee in Bonn verbindet sich ein für Eduroam konfiguriertes Telefon gleich mehrfach mit diesem Netzwerk, etwa dem Eduroam-Netz der DFG oder des DAAD.

7.2 Angriffe auf der Netzzugangsschicht

1.

Wh Te o-ha ll s „1 „19 92 .1 2.16 68 .0 8.0. .1 2 ? .

213

3. „192.168.0.2 at „….:b4 .

is

is 2 0. 8. 4 . 6 .1 :e 92 …. „1 t „ a 2.

Abb. 7.1 ARP-Spoofing Angriff von Eve

der eine ARP-Anfrage gestellt hat (Alice). Wenn die Nachricht von Eve vor der korrekten Antwort von Bob bei Alice eintrifft, verwirft Alice den ARP-Reply von Bob. Somit ordnet Alice’ ARP-Cache die MAC-Adresse von Eve der IP-Adresse von Bob zu. Als Folge dessen sendet Alice die Daten, die eigentlich für Bob gedacht sind, an Eve. Da dieser Angriff nur funktioniert, wenn die Antwort von Eve vor der Antwort von Bob bei Alice eintrifft, sind Spoofing-Tools für ARP stark performanceoptimiert. Da Switche im Gegensatz zu Hubs ein selektives Weiterleiten von Daten vornehmen, und eigene ARP-Caches besitzen, ist ARP-Spoofing insbesondere dann sinnvoll, wenn Alice, Bob und Eve sich einen Switch teilen. ARP-Spoofing kann in solchen Fällen auch Teil einer aktiven Aufklärung (Reconnaissance, vgl. Abschn. 7.3.1) sein.

7.2.5.2 ARP-Cache-Flooding Mithilfe der ARP-Caches in Switchen können Switche MAC-Adressen Ports zuordnen und Nachrichten entsprechend an ihre Empfänger weiterleiten. Allerdings verfügt der ARPCache, wie jedes Speichermedium, über eine limitierte Größe. Beim Fluten des Caches sendet ein Angreifer ungefragt ARP-Replies von einem Port des Switches, und zwar in einer sehr hohen Anzahl (das heißt ohne dabei auf echte ARP-Requests zu antworten). Der Switch trägt die neu gesichteten MAC-Adressen entsprechend in seinen ARP-Cache ein. Wird der ARP-Cache allerdings voll, können weiterhin eintreffende Informationen aus den ARP-Replies nicht mehr in den Cache eingetragen werden. Wenn dies passiert, dann schaltet der Switch in einen Hub-Modus um,

214

7 Angriffe auf TCP/IP-Netzwerkprotokolle

das heißt er leitet sämtliche Datenpakete an alle Ports weiter (außer an den Eingangsport einer Nachricht). Dadurch erhält Eve auch Nachrichten, die nicht an sie gerichtet sind, und kann somit die Datenpakete der anderen Netzteilnehmer mitlesen. Außerdem beeinflusst das höhere Datenaufkommen des Hub-Modus die Auslastung des Rechnernetzes negativ; dies ist allerdings nicht das zentrale Ziel von Eve und vielmehr ein Nebeneffekt.

7.3

Angriffe auf der Internetschicht

Für die Internetschicht werden zunächst aufklärende Angriffe und anschließend beeinflussende Angriffe erläutert.

7.3.1

Reconnaissance (Aufklärung)

Reconnaissance-Angriffe beinhalten alle Angriffe, die einem Angreifer Informationen über ein Netzwerk liefern. Bezogen auf Schicht 2 sind dies insbesondere die Anzahl der Hosts und deren IP-Adressen, die sich in einem Netzwerk befinden. Auf höheren Schichten können zusätzliche Informationen erfragt werden (etwa die Software eines Webservers). Details zu einzelnen Hosts erhält ein Angreifer über sogenannte Fingerprinting-Techniken, das heißt Techniken, die die Identifizierung eines Systems ermöglichen. Fingerprinting-Techniken können etwa verschiedene Betriebssysteme sowie deren Versionen anhand des Netzwerkverhaltens eines Systems identifizieren. Für den Angreifer sind Fingerprinting-Techniken ein zentraler Bestandteil der Reconnaissance. Man unterscheidet dabei zwei verschiedene Varianten von Reconnaissance-Angriffen: • passive Reconnaissance-Techniken erzeugen keinen eigenen Datenverkehr und ermitteln Informationen über das Netzwerk durch Mitlesen des Datenverkehrs. • aktive Reconnaissance-Techniken senden Test-Datenverkehr, um andere Hosts zu detektieren und anschließend zusätzliche Informationen von diesen Hosts zu erhalten (ggf. durch weitere aktive Anfragen).

7.3.1.1 Passive Reconnaissance Bei einer passiven Reconnaissance fokussiert sich ein Angreifer auf das Mitlesen des Datenverkehrs. Dieser Datenverkehr verrät bereits auf Schicht 2 viele Einzelheiten. Zentrale Informationen, die dabei in Erfahrung gebracht werden können, beantworten die folgenden Fragen: • Welche Hosts sind im Netzwerk vorhanden (und laufen derzeit)? • Welcher Benutzer (Host) kommuniziert mit welchem anderen Benutzer (Host)? • Welches Betriebssystem wird auf welchem Host verwendet?

7.3 Angriffe auf der Internetschicht Tab. 7.1 Typische TTLs für selektierte Betriebssystemversionen. Die Daten der Tabelle wurden von folgenden Webseiten bezogen und kombiniert: Netrsec.com, Nmap.meteoswiss.ch. Auf diesen Seiten nicht zu findende TTL-Daten wurden vom Autor selbst ermittelt

215

Betriebssystem

Standard-TTL

Linux 2.x - 4.4 FreeBSD/OpenBSD Windows 95/NT 3.51 Windows 98/NT 4 bis Windows 2008 Solaris 7 Cisco IOS 12.4 AIX 4.3 HP/UX 9.0x HP/UX 10.01

64 64 32 128 255 255 64a 30 64

a Einige andere AIX-Versionen verwenden eine TTL

von 60

Um derlei Informationen zu erhalten, werden die Inhalte der empfangenen Datenpakete (etwa Quell- und Zieladressen) ausgewertet. Eine wichtige Informationsquelle ist zum Beispiel die in einem IP-Paket gesetzte TTL eines Hosts – diese hängt nämlich stark vom verwendeten Betriebssystem ab. Tab. 7.1 listet einige Betriebssystemversionen samt zugehöriger TTLs auf. Im Internet sind Routen in der Regel kürzer als etwa 40 Hops. Entsprechend wird der maximal mögliche TTL-Wert von 255 in modernen Systemen kaum mehr verwendet. Bei den gelisteten Werten handelt es sich um initiale TTLs, das heißt ein Angreifer muss sich im gleichen LAN befinden, um sie zu sichten. Es ist allerdings auch denkbar, dass der Angreifer mehrere Hops vom Sender eines IP-Pakets entfernt ist. In diesem Fall muss er die Distanz in Hops zumindest grob ermitteln, um auf eine plausible Initial-TTL zu schließen.

7.3.1.2 Aktive Reconnaissance Im aktiven Fall kann Test-Traffic gesendet werden, um Zielsystemen bestimmte Informationen zu entlocken. Hierunter fallen insbesondere die klassischen Portscans (auf Schicht 3). Allerdings gibt es auch aktive Verfahren für Schicht 2. Ein Beispiel hierfür ist die Auswertung von ICMP-Replies [1, 16]. Wenn ein ICMP Echo-Request an ein Zielsystem geschickt wird, dann sollte im ICMP Echo-Reply der Code-Wert auf 0 gesetzt sein (dies ist etwa unter Windows schon seit Jahren der Fall). Einige ICMP-Implementierungen (insbesondere alte Betriebssysteme) setzen den Code allerdings nicht auf 0, insbesondere, wenn im Echo-Request ein anderer Wert stand. Auch mit den ICMP-Typen 15 (Information-Request), 7 (Address Mask Request) und 30 (Traceroute) können relativ leicht Informationen über ein System gesammelt werden. Teilweise reicht es, zu testen, ob ein System einen ICMP-Typ implementiert hat, oder nicht. Ebenfalls analysiert werden können die Fülldaten in ICMP Echo-Requests, wenn diese von Hosts versendet werden. Je nach Betriebssystem sind die im Echo-Request

216

7 Angriffe auf TCP/IP-Netzwerkprotokolle

Abb. 7.2 Die Fülldaten eines ICMP Echo-Requests unter Linux 3.13

enthaltenen Fülldaten hochgradig unterschiedlich. Abb. 7.2 zeigt die Fülldaten für einen typischen Echo-Reply unter Linux.

7.3.1.3 Kombination mehrerer Techniken Wie in Tab. 7.1 ersichtlich wurde, verwenden viele Betriebssysteme eine TTL von 64. Würde ein Angreifer einen solchen Wert sehen, dann würde er zwar bereits einige Betriebssysteme ausschließen können,4 doch bliebe noch immer eine Anzahl möglicher Betriebssystemen übrig. Diese Uneindeutigkeit trifft auf die meisten FingerprintingTechniken zu. Entsprechend werden möglichst viele Fingerprinting-Techniken kombiniert, um eine genaue Identifizierung eines Betriebssystems zu ermöglichen. Im Fall des populären Scan-Tools nmap werden zur Erkennung von Betriebssystemen viele Tests kombiniert, die in textueller Form kodiert sind. Tests werden dabei zeilenweise beschrieben und mit einem Schlüsselwort für eine Testkategorie eingeleitet (etwa T3 für bestimmte TCP-Tests oder IE für verschiedene ICMP-Tests). In [16] findet sich etwa folgendes Beispiel (Auszug): IE(R=Y%DFI=N%T=40%CD=S) Die zu einer Kategorie gehörigen Tests sind durch %-Zeichen voneinander separiert. Test und zu erwartendes Testresultat, das einem bestimmten Fingerprint-Test entsprechend sollte, sind wiederum durch ein =-Zeichen getrennt. Somit ergibt sich die oben ersichtliche Form =.

4 Die initiale TTL ist auf den meisten Systemen veränderbar. So könnte ein Linux-Administrator die zu verwendende TTL beispielsweise auf den Wert 128 setzen, den Windows 2008 verwendet.

7.3 Angriffe auf der Internetschicht

217

Im obigen Fall bedeutet etwa R=Y, dass der Reponsiveness-Test (Erreichbarkeitstest) erfolgreich (Y=yes) verlaufen musste. Nur wenn dieser Test erfolgreich verlief, werden die folgenden Tests durchgeführt. DFN=N testet, ob ein Echo-Reply das IPv4-Dont-Fragment-Flag (DF) gesetzt hat. T=40 testet wiederum, ob die initiale TTL den Wert 64 (0 × 40) hat. Schließlich führt CD=S den oben erwähnten Test durch, in dem getestet wird, ob ein Echo-Reply den CodeWert 0, einen Wert ungleich 0 oder genau den Wert aus dem Echo-Request (=S) beinhaltet. Generell gilt, dass anhand einer möglichst großen Anzahl verschiedener Informationen beim Fingerprinting ein Entscheidungsbaum erzeugt wird. Der Entscheidungsbaum dient dazu, ein Betriebssystem samt Version und gegebenenfalls darauf laufender Netzwerksoftware zu bestimmen. Die schematische Struktur eines solchen Baums zeigt das folgende Listing: if (TEST_1 == X) { /* OS A oder B */ if (TEST_2 == Y) { /* OS A */ } else { /* OS B, v. 1 or v.2*/ if (TEXT_3 == Z) { /* OS A v.1 */ } else { /* OS B v.2 */ } } } else if (TEST_10 == Q) { /* OS C, D oder E */ ... Selbstverständlich kann ein solcher Baum beliebig viele Ebenen haben und für eine frei wählbare Anzahl von Sonderfällen konzipiert werden.

7.3.2

IP-Spoofing

Prozesse können auf einem Host prinzipiell völlig frei IP-Pakete (und auch Pakete sonstiger Protokolle) zusammenstellen. Anders verhält es sich mit dem Versenden solcher selbst generierten Pakete. Während Pakete mancher Protokolle der Anwendungsschicht (etwa HTTP) von Prozessen beliebiger Benutzer erzeugt werden können, benötigt die Zusammenstellung einiger anderer Protokollheader (etwa IP und TCP) besondere Rechte. Unter Linux werden dazu beispielsweise Root-Rechte benötigt. Mit diesen können

218

7 Angriffe auf TCP/IP-Netzwerkprotokolle

bestimmte Sockets (SOCK_RAW, AF_PACKET, siehe socket(2)) erstellt werden. Mithilfe dieser Sockets können dann wiederum eigens erstellte IP-Paketdaten versendet werden, bei denen ein Prozess die Absender- und Empfangsadressen selbständig festlegt. Da für Versenden von derlei Protokollheadern keine Standardrechte genügen, kann ein normaler Benutzer auch keinen Ping verschicken, beziehungsweise geht dies nur, wenn für das ping-Programm das SUID-Bit gesetzt ist, es also auch von normalen Benutzern mit den effektiven Rechten des Superusers ausgeführt werden kann. Das Fälschen der Absenderadresse von IPv4- und IPv6-Paketen nennt sich IP-Spoofing. Eve kann sich somit als Alice ausgeben, wenn Sie mit Bob kommunizieren möchte. Antwortet Bob wiederum an Alice, erhält Eve die Nachricht nicht.

7.3.3

Denial-of-Service-Angriffe

Denial-of-Service-Angriffe (DoS-Angriffe) sind solche, die einen Dienst unerreichbar machen, beispielsweise durch Überlast oder durch Schaffung einer Bedingung, die den Dienst unerreichbar macht. Ein Angreifer kann hierzu etwa versuchen, einen Deadlock auf dem Zielsystem hervorzurufen. Die Grundlagen dieser Angriffe wurden bereits in Abschn. 6.2.7 beschrieben. Doch welche DoS-Angriffe ergeben sich für den Internet Layer? Ein Beispiel für einen DoS-Angriff auf IP-Ebene sind massive Pings, die durch einen Angreifer erzeugt werden. Der Angreifer führt die Pings mit einem extrem kleinen Intervall zwischen den verschickten ICMP Echo-Requests und einer gefälschten IPAdresse aus. Eve würde hierbei folglich IP-Spoofing und einen DoS-Angriff kombinieren. Das IP-Spoofing führt dazu, dass Eve die Antwortpakete nicht erhält. Das Ziel von Eve ist es, ihr Angriffsopfer zu überlasten. Das Opfer muss jeden der Echo-Requests verarbeiten, eine Antwort bereitstellen, und verschicken. Eve verschickt hingegen permanent dasselbe Paket, muss daher im Optimalfall nicht einmal mehrfach die Checksum des immer gleichen Pakets berechnen, und muss sich nicht um Antwortpakete kümmern.

7.3.3.1 Distributed DoS: Smurf Attack Eine verbesserte Version dieses DoS-Angriffs ist die sogenannte Smurf Attack. Bei der Smurf Attack spricht man auch von einem verteilten DoS-Angriff (auch: Distributed DoS, kurz DDoS, siehe Abschn. 6.2.7). Eve sendet dabei Echo-Requests an eine Broadcast-Adresse (siehe Abb. 7.3). Als Quelladresse gibt Eve hierbei die Adresse von Alice an. Entsprechend antworten die Hosts, die diesen Broadcast-Ping empfangen, mit einem Echo-Reply an die Adresse von Alice. Eve verschickt die Nachrichten auch bei dieser DoS-Variante mit einem besonders geringen Intervall. Die ausgenutzten Hosts im Netzwerk vervielfachen mit ihren EchoReplies die Antworten an Alice. Alice wird gegebenenfalls nicht sämtliche Nachrichten verarbeiten können und im schlimmsten Fall abstürzen.

7.3 Angriffe auf der Internetschicht

219

Abb. 7.3 Smurf Attack: Eve nutzt fremde Hosts als Multiplikatoren für einen DDoS-Angriff auf Alice

Man kann die Anzahl der Echo Replies R, die Alice bei einer Smurf Attack erhält, zumindest grob abschätzen. Sie entspricht in etwa dem Produkt aus der Anzahl der von Eve versendeten Echo-Requests r mit der Anzahl der antwortenden Hosts h. Allerdings gehen durch die hohe Netzwerkauslastung sowohl Pakete von Eve als auch Echo Replies verloren. Daher müssen die Faktoren vom Produkt um den durchschnittlichen Paketverlust der Brodcasts lr und den durchschnittlichen Paketverlust der Echo Replies rh ergänzt werden: R = (r − lr ) × (h − lh ) .

(7.1)

Diese Werte können für einen Zeitraum von beispielsweise einer Sekunde, in der BurstDatenverkehr gesendet wird, gemessen und anschließend eingesetzt werden. Dadurch lässt sich ein kurzer DoS-Zeitraum auf einen länger anhaltenden DoS-Zeitraum hochrechnen.

7.3.3.2 Fraggle Attack Die Smurf Attack kann auf den Application Layer gebracht werden, indem gespoofte UDP verwendet werden. Dazu sendet Eve mit der Absenderadresse von Alice UDP-Pakete an eine Broadcastadresse. Sie zielt dabei auf die UDP-Ports ECHO (Port 7) beziehungsweise CHARGEN (Port 19) ab. Diese Ports senden die enthaltenen Daten schlicht an den Sender zurück (Echo) oder generieren Daten, die an ihn gesendet werden (CHARGEN). Auch in diesem Fall würde Alice entsprechend viele Nachrichten erhalten. Heutzutage sind diese Ports nur auf wenigen Systemen offen, weshalb dieser Fraggle genannte Angriff nur sehr unwahrscheinlich zum Erfolg führt [2, 13, 19].

220

7 Angriffe auf TCP/IP-Netzwerkprotokolle

7.3.3.3 Amplifier Networks Eine noch effizientere Version der Smurf Attack verwendet sogenannte Amplifier Networks. Hierbei broadcastet Alice ihre Echo Replies in andere Netzwerke statt in nur ein Netzwerk. Entsprechend lässt sich die Anzahl der ICMP-Pakete an Alice steigern. Wie Abschn. 8.2.6 und 8.3.1 zeigen werden, gibt es auf Computern allerdings verschiedene Maßnahmen, um die Effektivität solcher DoS-/DDoS-/Smurf-Angriffe deutlich zu senken, etwa durch ICMP Rate Limiting.

7.3.4

Angriffe auf Basis von IP-Fragmenten

Es gibt zwei weitere klassische IP-Angriffe, die die IP-Funktionalität ausnutzen, IP-Pakete zu fragmentieren. Es können überlappende IP-Fragmente beim Sender erzeugt werden. Sehr alte Betriebssysteme konnten auf diese Weise aufgrund ihrer mangelhaften Netzwerkstacks zum Absturz gebracht werden (sogenannte Teardrop Attack). Veraltetes Automationsequipment sowie sonstige Altsysteme können unter Umständen noch immer mit der Teardrop Attack zum Absturz gebracht werden. Weiterhin kann mit überlappenden IP-Fragmenten unter Umständen ein IDS ausgetrickst beziehungsweise ein IPS umgangen werden. Ein Beispielszenario hierfür ist die Übertragung von Schadcode. Die Aufsplittung des Schadcodes erfolgt dabei derart, dass zwei legitim (unschädlich) erscheinende Fragmente übertragen werden, die sich jedoch letztlich geschickt überlappen, und einen Schadcode übergeben. Wenn ein IDS (oder IPS) beide Fragmente voneinander getrennt analysiert, wird das IDS beide Pakete vielleicht nicht als schädlich ansehen und an den Empfänger weiterleiten, der den Schadcode ausführt. Die zweite Variante, um die IP-Fragmentierung für einen Angriff auszunutzen, sind unvollständige IP-Fragmente. Der Angreifer sendet hierbei eine hohe Anzahl von IPPaketen an ein Zielsystem. Jedes Paket setzt das More Fragments-Flag (MF) im IP-Header auf 1, sodass der Empfänger die Daten zwischenspeichern muss, bevor er sie verwerfen kann. Der Angreifer sendet dabei sehr viele unvollständige IP-Fragmente, die den Speicher des Empfängers fluten. Das Resultat ist auch hier letztlich ein DoS. Da moderne Systeme durchaus in der Lage sind, die maximal 216 Fragment-Identifier pro Sender zu verarbeiten, ist ein Angriff heutzutage nur sinnvoll, wenn die IP-Adresse gespooft wird. Durch die dadurch erhaltenen weiteren Kombinationsmöglichkeiten (jeweils 216 Fragment-Identifier pro IP-Adresse) können Opfer potenziell zum Caching von deutlich mehr unvollständigen Fragmenten gezwungen werden. Auch dieser Angriff kann potenziell verteilt ausgeführt werden (DDoS).

7.3 Angriffe auf der Internetschicht

7.3.5

221

Grundlegende Angriffe auf das IP-Routing

Angriffe auf das dynamische Routing in IP-Netzwerken gibt es viele. Die meisten dieser Angriffe beziehen sich auf Routingprotokolle. Im Folgenden werden diese Angriffe grundlegend betrachtet.

7.3.5.1 Redirects und Router Advertisements Das ICMP-Protokoll kennt sogenannte Redirect-Nachrichten. Wenn Alice Nachrichten an Bob über einen Router X sendet, dann kann dieser Router X Alice darüber informieren, dass es einen besseren Routingpfad zu Bob gibt, als über X. Dazu schickt Router X eine Redirect-Nachricht an Alice, in der er ihr den aus seiner Sicht besseren Router Y nennt. Eve kann sich dieses Verfahren zunutze machen. Sie sendet dazu einen (eventuell gespooftes) ICMP-Redirect an Alice, indem sie sich selbst als besten Router für die Weiterleitung von Nachrichten an Bob ausgibt. Fortan sendet Alice ihre Nachrichten an Bob über Eve. Eve kann diese Nachrichten somit mitlesen. Zusätzlich kann Alice die über sie gesendeten Nachrichten manipulieren (MitM). ICMPv6 kennt analog die sogenannten Router Advertisements. Sie funktionieren auf eine ähnliche Weise und können einen Router im Netzwerk bekanntmachen. Auch diesen Nachrichtentyp kann Eve verwenden, um sich als geeigneten Router für ein beliebiges Ziel auszugeben. 7.3.5.2 Angriffe auf Routingprotokolle Routingprotokolle werden von Routern verwendet, um sich gegenseitig über Routingmöglichkeiten zu informieren. Routingpfade können sich etwa ändern, weil Links ausfallen, Router überlastet sind, oder neue Router in ein Netzwerk integriert werden. Entsprechende Nachrichten von Routingprotokollen beinhalten Einträge der Routingtabelle, die neu erlernt wurden oder, in einigen Fällen, sogar die gesamte Routingtabelle eines Routers. In passiver Form kann Eve diese Pakete für ihre Reconnaissance nutzen, das heißt, um Informationen über die Topologie eines Netzwerks zu sammeln. Im aktiven Angriffsfall versendet Eve hingegen eigene Nachrichten, um sich als Router im Netzwerk anzupreisen und somit Nachrichten mitlesen zu können. Ein relativ simpler Angriff ist etwas auf das Routing Information Protocol (RIP) möglich. RIP ist ein in die Jahre gekommenes Protokoll, das über UDP übertragen wird und den Distanzvektoralgorithmus verwendet. RIP beinhaltet zudem kaum Sicherheitsfunktionen. Zur Illustration eines typischen Angriffs ist es jedoch hervorragend geeignet. Eve sendet dabei ungefragt eine RIP-Response-Nachricht an andere Router. Sie preist sich dabei selbst als hervorragenden Router an. In dieser Nachricht steht in etwa: „Eve ist nur 1 Hop (Metrik = 1) vom Ziel (Bob) entfernt.“ Entsprechend leitet der Router, der diese Nachricht erhalten hat, alle Nachrichten an Bob über Eve. Ein simpler RIP-Spoofer ist im folgenden Listing – auf das Wesentliche gekürzt – dargestellt und kommentiert.

222

7 Angriffe auf TCP/IP-Netzwerkprotokolle

/ ∗ I n c l u d e −D a t e i e n g e k u e r z t ∗ / / ∗ Header d e s RIP−P r o t o k o l l s ∗ / struct riphdr { u_int8_t rip_cmd ; u_int8_t rip_vers ; u_int16_t r i p _ r e s 1 ; / ∗ 0 i n RIPv1 ∗ / / ∗ R o u t i n g −E n t r y : b e s c h r e i b t u_int16_t n_family ; u_int16_t n_tag ; /∗ 0 u_int32_t n_dst ; u_int32_t n_mask ; /∗ 0 u_int32_t n_nhop ; /∗ 0 u_int32_t n_metric ;

neue Route ∗ / i n RIPv1 ∗ / i n RIPv1 ∗ / i n RIPv1 ∗ /

}; void prnt_usage ( void ) { p r i n t f ( " usage : r i p < host / net to route >\ n" ) ; p r i n t f ( " exmpl : r i p 1 9 2 . 1 6 8 . 1 . 2 5 5 1 9 2 . 1 6 8 . 2 . 0 \ n " ) ; exit (0); } i n t main ( i n t a r g c , char ∗ a r g v [ ] ) { s t r u c t r i p h d r ∗ RIP ; i n t s o c k f d , i = 0 , on = 1 ; s t r u c t s o c k a d d r _ i n sa , me ; i f ( ! ( RIP = m a l l o c ( s i z e o f ( s t r u c t r i p h d r ) ) ) ) ... i f ( argc < 3) prnt_usage ( ) ; b z e r o ( ( char ∗ ) RIP , s i z e o f ( RIP ) ) ; RIP−>r i p _ c m d = 2 ; / ∗ RIP−R e s p o n s e −N a c h r i c h t ∗ / RIP−> r i p _ v e r s = 1 ; RIP−> r i p _ r e s 1 = 0 ; RIP−>n _ f a m i l y = h t o n s ( AF_INET ) ;

7.3 Angriffe auf der Internetschicht

223

RIP−>n _ t a g = 0 ; RIP−> n _ d s t = i n e t _ a d d r ( a r g v [ 2 ] ) ; RIP−>n_mask = 0 ; RIP−>n_nhop = 0 ; RIP−> n _ m e t r i c = h t o n l ( 1 ) ; b z e r o ( ( char ∗ ) &sa , s i z e o f ( s a ) ) ; s a . s i n _ f a m i l y = AF_INET ; sa . s i n _ p o r t = htons ( 5 2 0 ) ; sa . sin_addr . s_addr = i n e t _ a d d r ( argv [ 1 ] ) ; b z e r o ( ( char ∗ ) &me , s i z e o f ( me ) ) ; me . s i n _ f a m i l y = AF_INET ; me . s i n _ p o r t = h t o n s ( 5 2 0 ) ; me . s i n _ a d d r . s _ a d d r = INADDR_ANY ; i f ( ( s o c k f d = s o c k e t ( AF_INET , SOCK_DGRAM, 0 ) ) < 0 ) ... / ∗ V e r s e n d e n d e r RIP−N a c h r i c h t a l s B r o a d c a s t ∗ / i f ( s e t s o c k o p t ( s o c k f d , SOL_SOCKET , SO_BROADCAST, &on , s i z e o f ( on ) ) < 0 ) ... i f ( b i n d ( s o c k f d , ( s t r u c t s o c k a d d r ∗ ) &me , s i z e o f ( me ) ) < 0 ) ... i f ( ( i = s e n d t o ( s o c k f d , ( char ∗ ) RIP , s i z e o f ( s t r u c t r i p h d r ) + 0 , 0x0 , ( s t r u c t s o c k a d d r ∗ ) & sa , s i z e o f ( sa ) ) ) < 0) ... ... } Moderne Routingprotokolle, etwa solche, die – wie OSPF – auf dem Link-State- Algorithmus basieren, können zumindest auf grundlegend ähnliche Weise angegriffen werden. Allerdings verwenden aktuelle Routingprotokolle bessere Sicherheitsfunktionen, die Nachrichten kryptografisch authentifizieren. Entsprechend konfigurierte Router akzeptieren nicht-authentifizierte Nachrichten nicht mehr, sondern schlagen höchstens beim Administrator Alarm. Aus diesem Grund kann Eve zwar denselben Angriff durchführen,

224

7 Angriffe auf TCP/IP-Netzwerkprotokolle

muss aber zunächst ihre Nachrichten authentifizieren können, etwa mit einem geklauten kryptografischen Schlüssel eines anderen Routers.

7.3.6

Weitere Anmerkungen zur Sicherheit von IPv6

Auch wenn es eine relativ weit verbreitete Meinung ist, so ist IPv6 trotzdem nicht wesentlich sicherer als IPv4. Einige Details machen das neue Protokoll jedoch etwas sicherer. Da keine Broadcast-Adressen existieren, kann die Verfügbarkeit von Systemen nicht einfach mit einem Broadcast-Ping überprüft werden.5 Zudem sind dadurch Denialof-Service-Angriffe, bei denen ein Angreifer Pakete mit falscher Absenderadresse an Broadcast-Adressen schickt, nun auf diese Weise nicht mehr möglich. Das Sammeln von Informationen im Netzwerk über IP-Record-Route-Optionen oder das ID-Feld im IPv4-Header fällt ebenso weg, da diese schlicht nicht mehr vorhanden sind. Des Weiteren sind die Subnetze größer, was einen Netzwerkscan verkompliziert. Die zentralen Sicherheitserweiterungen durch IPSec, also AH, ESP und IKE, sind allerdings auch für IPv4 spezifiziert. Zudem sind IPv4-Stacks im Zweifelsfall schon ausgiebiger und länger getestet wurden.6 Die umfangreichere Erfahrung, die Administratoren mit IPv4 haben dürften, ist zumindest gegenwärtig noch als positiv zu betrachten.

7.3.7

Sicherheit von ICMPv6

Wie für IPv6, so gilt auch für ICMPv6, dass es nur wenig zusätzliche Sicherheit gegenüber seinem Vorgänger ICMPv4 mit sich bringt. Nach wie vor können gefälschte ICMP-Pakete versendet werden und so kann beispielsweise die Autokonfiguration von Rechnern (ein DHCP-Ersatz, der in ICMPv6 bereits integriert ist) gefälscht werden. Somit ist es einem Angreifer beispielsweise möglich, den gesamten Netzwerkverkehr eines Hosts über sich zu leiten, und somit zu sniffen und Man-in-the-Middle-Angriffe durchzuführen. Auf ähnliche Weise kann auch ein ICMPv6 Neighbor Discovery-Request ausgenutzt und mit falschen Daten beantwortet werden. Außerdem kann die ICMPv6 Duplicate Adress Detection angegriffen werden, mit der ein Angreifer nach Belieben Adressen für einen Host, der einen Adresswechsel durchführt, als bereits vergeben signalisieren kann. Hierbei handelt es sich um einen DoS-Angriff, der in RFC 3756 erwähnt wird [18].

5 Multicasting ist jedoch möglich. 6 Auch der Code für IPv6-Stacks ist in den meisten Betriebssystemen bereits 20 Jahre alt – jedenfalls in Teilen. Neuimplementierungen, etwa in IoT-Produkten, kommen allerdings immer wieder vor.

7.4 Angriffe auf der Transportschicht

7.4

225

Angriffe auf der Transportschicht

Auf der Transportschicht sind insbesondere UDP und TCP im Einsatz. In den nächsten Abschnitten werden zunächst Sicherheitsaspekte von UDP, dann solche von TCP, und darauf Portscan-Techniken für beide Protokolle betrachtet.

7.4.1

Sicherheitsaspekte von UDP

Zunächst einmal ist es für erfahrene Netzwerkprogrammierer äußerst einfach, UDPDatagramme zu fälschen, also UDP im Rahmen von IP-Spoofing zu nutzen. Dazu benötigt der Angreifer lediglich die entsprechenden Rechte auf einem System und entweder einen Paketgenerator, den er sich aus dem Internet lädt, oder einen Compiler beziehungsweise Interpreter für beispielsweise Perl-Code. So können unter falscher Absenderadresse beispielsweise DNS-Anfragen gefälscht werden. Praktisch alle Provider haben mittlerweile Spoofing-Schutz in ihre Zugangskomponenten integriert, sodass es Privatanwendern gar nicht mehr möglich ist, von ihrem Heimrechner aus gespoofte Pakete an Hosts im Internet zu senden. Innerhalb von autonomen Systemen besteht das Problem hingegen weiterhin. Da UDP im Gegensatz zu TCP keine Sequenz- und Bestätigungsnummern verwendet, ist es für einen Angreifer sehr einfach, eine UDP-Übertragung zu übernehmen (zu hijacken). Ein weiterer UDP-basierter Angriff ist das UDP-Flooding. Eve sendet dabei extrem viele UDP-Datagramme an ihr Opfer Bob. Bob muss jeweils prüfen, ob eine Anwendung Daten auf dem Port empfangen wird, und im Fehlerfall mit einer ICMP Destination Unreachable – Port Unreachable-Meldung antworten. Bei einer großen Anzahl von Paketen kann dies einen DoS-Angriff für Bob darstellen. Wenn Eve keine ICMP-Pakete von Bob erhalten möchte, kann sie außerdem die IPAdresse spoofen. Dieser Effekt kann gesteigert werden, wenn Eve sich aufteilt. Dies ist etwa dann möglich, wenn Eve über ein Botnetz verfügt und alle Bots Anfragen an Bob senden. Viele IP-Stacks verwenden ICMP Rate Limiting. Dieses setzt eine Begrenzung der gesendeten ICMP-Nachrichten pro Sekunde durch, womit Bob deutlich mehr UDP-Pakete verarbeiten kann und ein DoS-Angriff zumindest erschwert wird. Neben dem Flooding gibt es einen weiteren UDP-basierten DoS-Angriff, nämlich die in Abschn. 7.3.3.2 besprochene Fraggle Attack. Leider gibt es bei UDP-Kommunikationen aus Sicht der Paketfilter ein Problem. Die Software muss zwischen Verbindungsanfragen und Antwortpaketen unterscheiden können. Um dieses Problem zu lösen, merken sich die Paketfilter die Socket-Eigenschaften der ausgehenden Pakete (Quell- und Ziel-Adressen sowie Quell- und Ziel-Ports). Wurden bereits binnen einer gewissen Zeitspanne Pakete eines Sockets über ein Interface übertragen, kann auf ein Antwortpaket geschlossen werden, andernfalls handelt es sich um eine neue Kommunikation.

226

7 Angriffe auf TCP/IP-Netzwerkprotokolle

Maßnahmen zur Absicherung von UDP werden in Abschn. 8.4, samt untergeordneter Abschnitte, besprochen.

7.4.2

Sicherheit von TCP

Es gibt verschiedene Angriffe gegen TCP. Es sind sowohl Denial-of-Service- als auch Spoofing- und Hijacking-Angriffe möglich: Beim Spoofing von TCP-Paketen muss der Angreifer im Gegensatz zum UDPSpoofing neben der Source- und Destination-Portnummer auch die Sequenz- und Bestätigungsnummern kennen. Entweder muss er diese erraten, kann diese bei älteren TCP-Implementierungen errechnen oder hat diese gesnifft. Angreifer können bestehende TCP-Verbindungen übernehmen, dazu führen sie einen Man-in-the-Middle-Angriff aus.7 In der einfachsten Form erfolgt die Desynchronisation der Verbindung, indem der Angreifer nur einem der beiden Kommunikationsseiten ein Paket der angeblich anderen Seite mit neuer Sequenznummer sendet. Dadurch sind schließlich beide Seiten der Meinung, von ihrem Gegenüber andere Sequenznummern erhalten zu müssen. Ist dies der Fall, bricht ein sogenannter Ack Storm aus, da jede Seite ihre Bestätigungen sendet. Bei einem Hijacking-Angriff wird eine Verbindung zwischen Alice und Bob durch Eve übernommen, um Daten zu injizieren. Danach kann die Verbindung beendet werden, etwa durch anschließendes Einschleusen von RST-Paketen. In der ausgefeiltesten Variante werden Daten injiziert und die Verbindung anschließend resynchronisiert. Im Optimalfall bemerken die Kommunikatoren den Hijacking-Angriff daher nicht. Mit TCP-Hijacking ist es beispielsweise möglich, Authentifizierungsmaßnahmen zu umgehen (etwa durch das Einschleusen eines Befehls zum Anlegen eines neuen Accounts) oder Datenbestände zu korrumpieren. Die sogenannten Reset-Attacken setzen das RST-Flag in einem gespooften Paket und injizieren es in eine bestehende Verbindung. Dazu muss zwar die Sequenznummer der Verbindung bekannt sein, jedoch ist dies zumindest bei On-Path-Angriffen keine große Schwierigkeit. Dieser Angriff betrifft besonders Systeme, die eine stetige Verbindung benötigen. Beim TCP-SYN-Flooding wird ein Verbindungsstatus des TCP-Protokolls ausgenutzt. Dabei werden so viele (vom Angreifer dann nicht mehr beantwortete) Verbindungsversuche eingeleitet, dass der Server keine neuen Verbindungen mehr entgegennehmen kann, da er sich alle angeforderten Verbindungen merken muss. Man nennt diesen Verbindungsstatus auch halb offen.

7 Auch die im Folgenden beschriebenen Angriffsvarianten Hijacking und Reset-Angriff sind Arten von Man-in-the-Middle-Angriffe.

7.4 Angriffe auf der Transportschicht

227

Maßnahmen zur Absicherung von TCP werden in Abschn. 8.4, samt untergeordneter Abschnitte, besprochen.

7.4.3

Portscans mit TCP und UDP

Portscans überprüfen, welche TCP- beziehungsweise UDP-Ports auf einem Zielsystem geöffnet sind. Das bekannteste Scanning-Tool (weit mehr, als ein reiner Portscanner) ist Nmap (Network Mapper) von G. Lyon (alias Fyodor). Nmap ist aus diversen Filmen bekannt, die grüne Schrift auf schwarzem Text oder sonstige Hacker-Elemente benötigen.8 Im Folgenden werden die klassischen Scan-Techniken besprochen, wie sie in Nmap implementiert sind. Die folgende Besprechung von Scantechniken orientiert sich an der Originaldokumentation von Nmap (https://nmap.org/nmap_doc.html) und fasst deren zentrale Aspekte zusammen.

7.4.3.1 UDP-Portscan Für einen UDP-Portscan werden UDP-Pakete mit leerem Payload, also reine UDP-Header, verschickt. Falls daraufhin die ICMP-Meldung Port Unreachable empfangen wird, so ist der entsprechende Port geschlossen. Falls hingegen die ICMP-Meldung Communication Administratively Prohibited empfangen wird, so ist dieser Port durch eine Firewall blockiert. ICMP-Fehlermeldungen sind oftmals mit einem Rate Limit versehen, das die Anzahl emittierter ICMP-Pakete pro Sekunde begrenzt, sodass UDP-Scans recht langsam abgewickelt werden müssen, um Fehler zu vermeiden. Aus diesem Grund werden in der Praxis, etwa von Nmap, auch mehrere Versuche unternommen, bevor ein Port bewertet wird. 7.4.3.2 TCP-Connect-Scan Bei einem TCP-Connect-Scan wird, im einfachsten Fall mithifle der connect()Funktion, ein Three-Way-Handshake durchgeführt. Ist dieser Handshake erfolgreich, wird der jeweilige TCP-Port als offen gewertet. Diese Scantechnik hat den Vorteil, dass sie von einem normalen Systemnutzer durchgeführt werden kann, da ein connect()Aufruf keine Superuser-Rechte benötigt. Als Nachteil muss allerdings in Kauf genommen werden, dass dieser Scan recht langsam ist, da er vollständige Verbindungsanfragen durchführt. Außerdem tauchen Scan-Resultate in den Logdateien der Server auf. Das folgende Listing zeigt einen simplen Connect-Scan mit Nmap. $ nmap −sT l o c a l h o s t S t a r t i n g Nmap 6 . 4 0 ( h t t p : / / nmap . o r g ) a t 2018−02−21 0 8 : 2 9 CET

8 Siehe etwa https://nmap.org/movies/.

228

7 Angriffe auf TCP/IP-Netzwerkprotokolle

Nmap s c a n r e p o r t f o r l o c a l h o s t ( 1 2 7 . 0 . 0 . 1 ) H o s t i s up ( 0 . 0 0 0 2 1 s l a t e n c y ) . Not shown : 997 c l o s e d p o r t s PORT STATE SERVICE 2 2 / t c p open s s h 2 5 / t c p open smtp 6 3 1 / t c p open i p p Nmap done : 1 I P a d d r e s s ( 1 h o s t up ) s c a n n e d in 0.05 seconds

7.4.3.3 TCP-SYN-Scan (auch Half-Open-Scan) Eve sendet hierbei ein SYN-Paket an einen Port des Zielsystems. Beinhaltet die Antwort ein SYN- und ein ACK-Flag, ist der Port geöffnet. Ein gesetztes RST-Flag bedeutet, dass die Verbindung geschlossen wurde. Erhält man keine Antwort, wird der Port gefiltert. Diese Scantechnik hat den Vorteil, dass ein Scanvorgang nicht unbedingt protokolliert wird. Dafür benötigt diese Scan-Technik allerdings TCP-Raw-Sockets, die nur mit Superuser-Rechten angelegt werden können. Nmap kann mit dem Parameter -sS zu einem SYN-Scan bewogen werden, benötigt für die Erzeugung der dafür notwendigen Sockets allerdings Superuser-Rechte: $ s u d o nmap −sS l o c a l h o s t S t a r t i n g Nmap 6 . 4 0 ( h t t p : / / nmap . o r g ) a t 2018−02−21 0 8 : 4 4 CET Nmap s c a n r e p o r t f o r l o c a l h o s t ( 1 2 7 . 0 . 0 . 1 ) H o s t i s up ( 0 . 0 0 0 0 1 3 s l a t e n c y ) . Not shown : 997 c l o s e d p o r t s PORT STATE SERVICE 2 2 / t c p open s s h 2 5 / t c p open smtp 6 3 1 / t c p open i p p Nmap done : 1 I P a d d r e s s ( 1 h o s t up ) s c a n n e d i n 2 . 4 3 seconds

7.4.3.4 TCP-FIN-Scan Wenn eine Firewall SYN-Scans blockt, kann eine Vorgabe des RFC-Standards ausgenutzt werden, um dennoch zu scannen: Geschlossene Ports sollen auf FIN-Pakete nicht antworten und offene Ports sollen mit einem RST-Flag antworten. Ein entsprechender Scan

7.4 Angriffe auf der Transportschicht

229

ist dennoch fehleranfällig (heutige Firewalls blocken RST-Pakete in der Regel, wenn sie nicht zu einer vorherigen Verbindung gehören).

7.4.3.5 TCP-NULL-Scan Dieser Scan funktioniert wie der FIN-Scan, setzt allerdings keine Flags (NULL). Die Hoffnung des Angreifers ist in diesem Fall, dass dieser Scan noch funktioniert, wenn SYNund FIN-Scan durch eine Firewall blockiert wurden. 7.4.3.6 TCP-XMAS-Scan Analog zu NULL-Scan gibt es den XMAS-Scan. Im Unterschied zum NULL-Scan sind beim XMAS-Scan allerdings alle Flags gesetzt. Der Scan wird XMAS-Scan, also Weihnachts-Scan, genannt, da – wie bei einem Weihnachtsbaum – alle Bits gesetzt sind; der gesamte Weihnachtsbaum leuchtet festlich. 7.4.3.7 Der TCP-Fragmentation Scan in Nmap Bei diesem Scan des Hackers daemon9 wird der TCP-Header fragmentiert, also auf mehrere IP-Pakete aufgeteilt. Dieses Vorgehen wählt der Angreifer, damit der Scan nicht ohne Defragmentierung des ursprünglichen Pakets ersichtlich ist. Der Angreifer hofft, dass die Firewall des Zielsystems eine schlechte Portscan-Erkennung hat, die fragmentierte Pakete nicht zusammengesetzt verarbeiten kann. Infolge dessen würde der Angreifer somit eine Antwort auf seine Scanpakete erhalten. 7.4.3.8 Der TCP-Reverse-Idle-Scan in Nmap In dieser vom Hacker Antirez entwickelten Scantechnik möchte Eve den Rechner von Bob indirekt scannen [16]. Sie vermutet, dass Daten von ihrer IP-Adresse intensiver geblockt werden, als Daten, die von Alice stammen.9 Daher benutzt Eve Alice als „Zombie“. Eve schickt dazu ein IP-Testpaket an Alice, um Alice IPID (Fragment ID) zu ermitteln. Eve schickt anschließend ein gespooftes SYN-Paket an Bob (Quell-IP: Alice). Alice erhält eine Antwort (entweder ein SYN-ACK-Paket, falls der Port offen ist, oder ein RSTPaket, falls der Port geschlossen ist). Falls der Port offen ist (das heißt, Alice empfing ein SYN-ACK-Paket), wird Alice mit einem RST-Paket an Bob antworten (dieses Paket wird ignoriert) [16]. Alte Systeme inkrementieren die IPID einfach für jedes neue Paket, das sie aussenden. Eve sendet schließlich ein weiteres IP-Testpaket an Alice, um Alice’ aktuelle IPID zu ermitteln. Wenn die IPID der alten IPID + 2 (oder höher) entspricht, wurden neue Pakete von Alice verschickt. Somit ist der Port vermutlich offen. Wenn der Wert der alten IPID + 1 entspricht (das heißt es wurde zwischenzeitlich kein Paket von Alice versendet), ist der Port vermutlich geschlossen. 9 Zum Beispiel könnten mehr der verwendeten Firewall-Regeln für Datenpakete des Adressbereichs von Eve aktiv sein.

230

7.5

7 Angriffe auf TCP/IP-Netzwerkprotokolle

Angriffe auf der Anwendungsschicht

Keine andere Schicht im TCP/IP-Modell – außer eventuell Schicht eins – zeichnet sich durch eine so große Zahl in der Praxis verwendeter Protokolle aus. Im Gegensatz zur Schicht eins sind mit den Protokollen der vierten Schicht jedoch hochgradig unterschiedliche Zwecke (Services) verbunden. Diese Heterogenität führt zu sich stark unterscheidenden Angriffstypen. Interessant ist auf dieser Schicht insbesondere die Betrachtung der dominanten Protokolle, die das Internet in seiner heutigen Form ermöglichen: HTTP, DNS sowie die E-Mail-Protokolle. Die auf Schicht vier verwendeten Protokolle sind in den meisten Fällen recht alt – genauso wie die Protokolle der darunterliegenden Schichten. Die Sicherheitsfunktionen der ursprünglichen Protokolldefinitionen auf Schicht vier waren minimal. Diverse Protokolle wurden allerdings erweitert, um bessere Sicherheitsfunktionen zu ermöglichen, etwa eine bessere Authentifikation oder Verschlüsselung in Verbindung mit TLS. In der Praxis (Stand 2017) bieten beispielsweise jedoch noch immer diverse Webhoster unverschlüsselten FTP-Zugang für ihre Kunden an.

7.5.1

Anmerkungen zur Reconnaissance

Durch die Vielzahl an Diensten bietet diese Schicht für einen Angreifer die Möglichkeit, eine Vielzahl an unterschiedlichen Informationen für eine Reconnaissance zu erlangen. Im simpelsten Fall sind dies etwa in Protokoll-Headern beziehungsweise Mail-Headern übertragende User-Agents, also Angaben der von Clients verwendeten Software, oftmals samt Versionen. Mithilfe von derlei Daten lassen sich Clients sehr gut identifizieren und Rückschlüsse auf Betriebssysteme und Endgeräte ziehen. Weitere von Clients übertragene Daten ermöglichen etwa Rückschlüsse auf die von einem Benutzer gesprochenen Sprachen (z. B. Accept-Language bei HTTP). Serverseitig sind es hingegen Banner, die Angreifern zeigen, welche Software hinter einem Dienst steckt, etwa ob der Apache-Websever, der IIS oder ein anderer Webserver eingesetzt wird, oftmals samt Versionsnummern und eingebundener Zusatzmodule. Das folgende Listing fragt den Banner eines SMTP-Servers ab und zeigt, dass dort die Serversoftware Sendmail in Version 8.14.9/8.15.2 läuft. $ t e l n e t smtp . e x a m p l e 25 Trying . . . C o n n e c t e d t o smtp . e x a m p l e . Escape c h a r a c t e r i s ’ ^ ] ’ . 220 p o s t h o s t . hs−worms . de ESMTP S e n d m a i l 8 . 1 4 . 9 / 8 . 1 5 . 2 ; Tue , 22 May 2018 1 5 : 2 5 : 0 0 +0200 QUIT 221 2 . 0 . 0 p o s t h o s t . e x a m p l e c l o s i n g c o n n e c t i o n C o n n e c t i o n c l o s e d by f o r e i g n h o s t .

7.5 Angriffe auf der Anwendungsschicht

7.5.2

231

HTTP

Es gibt eine Vielzahl an Angriffen auf der Ebene des HTTP-Payloads (ApplicationLogik), etwa Cross-Site-Scripting (XSS). Diese Angriffe stehen jedoch nicht im Fokus des eigentlichen HTTP-Protokolls und werden an dieser Stelle nicht besprochen. Sie stellen vielmehr ein Problem des sicheren Softwareentwicklung dar. HTTP selbst ist allerdings auch kein sonderlich sicheres Protokoll. So werden etwa manchmal HTTP-Funktionen fälschlicherweise als Sicherheitstechniken interpretiert. Angenommen, Alice sei interne Mitarbeiterin einer Bank und muss sich über die Webseite http://de.xyz.com/user_authenticated.php bei einem Dienst anmelden. Anschließend wird sie auf eine interne Webseite umgeleitet, die prüft, ob Alice tatsächlich von der vorherigen Seite kam. Der HTTP-Request von Alice wird die vorher besuchte Seite im Referrer angeben und beispielsweise wie folgt aussehen: GET / HTTP / 1 . 1 H o s t : bank . e x a m p l e . com R e f e r r e r : h t t p : / / bank . e x a m p l e . com / u s e r _ a u t h e n t i c a t e d . php User−Agent : M o z i l l a SoUndSo / 1 . 2 . 3 ... Der HTTP-Referrer ist allerdings durch jeden Client frei wählbar. Alice kann den Referrer in Zukunft selbst in ihren HTTP-Header schreiben, selbst dann, wenn sie schon gar nicht mehr bei der Bank arbeitet. Weiterhin ist das HTTP-Protokoll für die bereits mehrfach besprochene Reconnaissance-Phase eines Angriffs interessant. Von zentraler Bedeutung ist dabei ein im Plaintext übertragener HTTP-Request sowie die daraufhin ersichtliche HTTP-Response. Headerelemente wie User-Agent und Accept-Language können diverse Rückschlüsse (etwa über die Sprachkompetenz eines Nutzers) ermöglichen. Selbiges gilt für die Inhalte der Response, etwa die verwendete Serversoftware, und selbstverständlich auch für den Payload. Außerdem sind Logdateien auf Servern auslesbar [9] – durch Administratoren und Angreifer. Logdateien enthalten Daten darüber, welcher Client welche Ressource anfragt, welche URL-Parameter dabei übertragen werden (etwa Passwörter) und – je nach Konfiguration – zusätzliche Daten über den Client, wie etwa seinen User-Agent, seine Spracheinstellungen, seine IP/seinen Hostname, den Referrer usw. Auch hierbei können wiederum Rückschlüsse auf das Vorhandensein eigentlich nicht für die Öffentlichkeit gedachter Systeme gezogen werden, man betrachte etwa die folgenden beiden beispielhaften Referrer: • http://internal-xyz.hs-worms.de • http://xyz.com/forward.php?user=max&pass=muster

232

7 Angriffe auf TCP/IP-Netzwerkprotokolle

Manche HTTP-Server prüfen die URLs nicht korrekt [9]. Wenn der Client etwa die Ressource /../../../../etc/passwd anfragt und der Server diesen Pfad schlicht öffnet, erhält der Client auch den Inhalt dieser Datei. Dies ist heute nicht mehr allzu häufig, jedoch noch immer denkbar, da HTTP selbst keinen Schutz gegen derlei Angriffe bietet. HTTP-Proxyserver, wie sie in unzähligen Netzwerken eingesetzt werden, speichern Informationen zwischen. Diese Informationen sind potenziell sensitiv und für eine bestimmte Zeit an einer zusätzlichen Stelle (dem Cache des Proxyservers) abgelegt. Dadurch sind derlei Informationen potenziell gefährdet [9]. Die HTTP-Spezifikation weist zudem darauf hin, dass Angriffe gegen HTTP-Proxys die Clients, die auf diesen Proxy angewiesen sind, von der HTTP-Kommunikation mit Remote-Netzwerken abtrennt. Ein erfolgreicher Angriff gegen einen Proxyserver kann daher einem DoS gleichkommen. Weitere Sicherheitsprobleme sind insbesondere in den RFCS 7230 [7] und 7231 [8] beschrieben. Außerdem bietet die Webseite https://www.owasp.org/ eine Anleitung zur Entwicklung sicherer Webanwendungen und -dienste, die äußerst empfehlenswert ist. Allerdings bezieht sich ein Großteil dieses Themas auf sichere Softwareentwicklung und nicht primär auf das Protokoll HTTP an sich, weshalb es an dieser Stelle nicht behandelt wird.

7.5.3

DNS

Das DNS-Protokoll stellt einen elementaren Dienst für das heutige Internet bereit. Angriffe auf die DNS-Infrastruktur sind daher besonders kritisch zu betrachten. In der Vergangenheit wurde insbesondere versucht, Denial-of-Service-Angriffe (DoS/DDoS) auf DNS durchzuführen, um das Internet zumindest praktisch unbenutzbar zu machen.10 Dabei werden von unzähligen Systemen gleichzeitig DNS-Abfragen an die (weltweiten) DNS-Server verschickt, um diese in eine Überlastsituation zu überführen. Dank der Dezentralität des DNS-Systems (durch Anycasting und die Caching-Hierarchie des DNSSystems) ist DNS bisher relativ robust gegenüber DDoS-Attacken gewesen. Es existieren jedoch einige weitere Angriffe gegen das DNS-Protokoll. Einen effizienten Weg, DNS für DoS-Angriffe auszunutzen, stellen sogenannte DNS Amplification Attacks dar. Dabei wird ein möglichst kleiner DNS-Request an einen DNSServer geschickt, der mit einer größeren Response-Nachricht antwortet. Die Nachricht ist deshalb größer, da in der Regel mehrere Resource Records zurückgeliefert werden, etwa in der optionalen Sektion des DNS-Headers. Der Absender kann dabei auch eine gespoofte Absender-Adresse angeben, sodass ein anderer Host mit den Antwortnachrichten übersät

10 IP-basierte Abfragen würden auch ohne DNS funktionieren, doch würde bereits der Besuch einer Webseite über eine IP-Adresse scheitern, wenn die Webseite Teilseiten oder Skripte von externen Seiten über deren Domainnamen einbindet.

7.5 Angriffe auf der Anwendungsschicht

233

wird. Ziel einer Amplification Attack kann jedoch auch der DNS-Server selbst sein, da er eine große Datenlast bewältigen muss [12]. Beim sogenannten DNS Cache Poisoning (auch DNS Spoofing) schickt ein Angreifer gefälschte, angeblich autoritative Antworten an einen DNS-Server. Dieser DNS-Server speichert die empfangenen Resource Records aus der Antwort. Fragt ein Opfer nun den entsprechenden Resource Record an, erhält der Client die durch den Angreifer injizierte falsche Antwort. Dabei lenkt der Angreifer sein Opfer in der Regel auf einen von ihm kontrollierten Host um. Dabei kann es sich etwa um einen Server handeln, der so aussieht, wie der Server der Bank des Kunden. Damit die entsprechenden Resource Records möglichst lang im manipulierten DNS-Server verbleiben, wählt der Angreifer eine besonders hohe TTL für diese aus – schließlich weiß der Angreifer nicht unbedingt, wann der Client einen bestimmten Resource Record abfragen wird. Eine ausgefeilte Variante des DNS Cache Poisoning zeigen Klein et al. in [14]. Ihr indirektes Cache Poisoning baut darauf auf, dass bereits bekannte Resource Records im Cache verfallen. Vor Ablauf der im Cache befindlichen Resource Records fügt der Angreifer über Cache Poisoning einen Verweis auf diese Records ein (CNAME), etwa für suchmaschine.example auf angreifer.example. Nach Ablauf des A-Records für suchmaschine.example kann der DNS-Server noch die Daten für angreifer.example liefern [14]. Neben CNAME-Records können auch NS-Records verwendet werden, um nach dem Ablauf eines MX-Records auf einen neuen MX-Record (den des Nameservers des Angreifers) umzuleiten [14]. In einem frühen Ansatz zur Vermeidung von DNS Cache Poisoning wurden Cookies verwendet – im Wesentlichen ist der Ansatz dabei jener, dass DNS-Server schlicht keine Antworten mehr akzeptieren, für die sie keine Anfragen gestellt haben. Ob eine entsprechende Anfrage tatsächlich gestellt wurde, lässt sich anhand eines Wertes (Identifier im DNS-Header) überprüfen. Das heißt, der Identifier im DNS-Reply muss zu einem kürzlich vergebenen Identifier eines selbst verschickten DNS-Requests passen. Dieses Verfahren verhindert allerdings keine MitM-Angriffe, die DNS-Replies „on the fly“ manipulieren [12]. Die Werte der Identifier wurden später zufällig gewählt, damit Angreifer sie nicht einfach erraten können, wenn sie nicht auf dem Routingpfad zwischen DNSServer und DNS-Client liegen. Man bezeichnet einen solchen Nicht-MitM-Angreifer als Off-Path-Angreifer. Allerdings konnte gezeigt werden, dass auch ein zufälliger Identifier keine Off-Path-Angriffe verhindern kann. Dazu wurde ausgenutzt, dass Identifier mit schwachen Zufallszahlengeneratoren (oder – ohne Randomisierung – schlicht sequenziell) gewählt wurden [11]. Schließlich wurde neben dem Identifier auch der UDP-Quellport randomisiert [6], um Off-Path-Angrife zu erschweren, doch auch für diese Lösung konnten Möglichkeiten gefunden werden, um sie zu umgehen, insbesondere in NATUmgebungen [11, 12]. Ein weiterer Ansatz zur Manipulation des DNS-Systems findet sich häufig in SPAMMails. Dabei werden Fuzzy-Domains angelegt, die fast so aussehen, wie die Domain eines Opfers, beispielsweise lassen sich manche Zahlen durch Buchstaben ersetzen (und andersherum). So könnte in einem Link einer SPAM-Mail aus der Domain HS-WORMS.DE

234

7 Angriffe auf TCP/IP-Netzwerkprotokolle

etwa HS-W0RMS.DE werden. Etwas perfekter täuschen Domainnamen, die Homoglyphen beinhalten. Bei diesen sehen zwei Zeichen für den Betrachter gleich aus, etwa ein „o“ aus einem kyrillischen Alphabet anstatt eines „o“ aus einem lateinischen Alphabet.11 Homoglyphen können sowohl Intrusion Detection Systems (wenn diese auf typische Strings filtern), als auch Menschen überlisten. Homoglyphen sind folglich hervorragend für das Social Engineering geeignet. Da DNS-Requests und -Responses in aller Regel unverschlüsselt verschickt werden, können Betreiber von DNS-Servern und MitM-Systeme diese Nachrichten im Zuge einer passiven Reconnaissance mitlesen und zur Profilbildung und Überwachung der Benutzer einsetzen [12]. Eine aktive Reconnaissance für interne Dienste, die private IP-Adressen verwenden, kann ebenfalls über DNS erfolgen [10]. Dazu fragt ein Angreifer interne IP-Adressen bei einem Nameserver an beziehungsweise lässt er Hostnames einer Zone auflösen und prüft, ob die im DNS-Reply enthaltene IP-Adresse eine interne ist. Mithilfe eines solchen Vorgehens kann ein Angreifer gezielt interne Netzwerke mappen, unter anderem auch automatisiert mit Tools wie privdns.12 Alternativ kann ein Angreifer auch versuchen, eine gesamte Zone zu übertragen. Ein solches Vorgehen erübrigt das Erraten einzelner Hosts. Wenn ein solcher Transfer erlaubt ist – was heutzutage sehr selten ist [4] –, dann kann dieser Transfer beispielsweise mit $ d i g AXFR z o n e @ s e r v e r bewerkstelligt werden. Zum Einsatz kommt der Abfragetyp AXFR. Hierbei wird im Wesentlichen eine Anfrage (Query) gestellt, die als Queryname (QNAME) die entsprechende Zone und als Querytpe (QTYPE) einen Resource Record angibt, der für den ZonenTransfer steht (Wert 252) [15]. Die Absicherung von DNS wird in Abschn. 8.5.4 besprochen.

7.5.4

E-Mail

Das E-Mail-System basiert im Wesentlichen auf SMTP und IMAP, sowie auf dem alten POP3-Protokoll. Ohne Absicherung übertragen auch diese Protokolle sämtliche Befehle und E-Mails im Klartext. Auch die Speicherung von E-Mails auf den Servern erfolgt im Klartext, etwa in Verzeichnissen oder in Datenbanken. Es ist entsprechend eine explizite Absicherung (Konfiguration von Verschlüsselung etc.) notwendig. Ursprünglich werden Bentzername und Passwort, die oftmals auch für andere Dienste, etwa SSH, auf einem Rechner verwendet werden können, einfach in einer Zeile bezie-

11 Alternativ ließe sich auch das koptische „o“ verwenden. 12 Siehe https://github.com/mhelwig/privdns.

7.5 Angriffe auf der Anwendungsschicht

235

hungsweise über zwei Zeilen hinweg übertragen – im Klartext. Das folgende Beispiel verdeutlicht die Anmeldung am Beispiel des POP3-Protokolls. USER max.muster PASS muster1234 Mangels Authentifizierung beziehungsweise mangels Zuordnung zwischen Absenderadresse und authentifiziertem Benutzer sorgen SMTP-Server für das weltweite Versenden von SPAM-Nachrichten. Wenn die Authentifizierung deaktiviert wurde, dann lassen sich besonders leicht SPAM-Nachrichten versenden. Ein Angreifer (oder ein Bot) muss nur die Verbindung zu einem E-Mail-Server aufbauen und die entsprechende E-Mail verschicken. Ist ein SMTP-Server nicht dafür konfiguriert, nur explizit in der eigenen Organisation vorhandene E-Mail-Adressen als Absender zu akzeptieren, dann kann ein SPAM-Sender jede beliebige Absenderadresse angeben. Wenn nur authentifizierte Benutzer ihre jeweils eigenen Absenderadressen in Verbindung mit dem SMTP-Server einer Organisation verwenden können, dann gestaltet sich der SPAM-Versand bereits deutlich schwieriger. Angreifer können zudem Reconnaissance-Angriffe über die E-Mail-Protokolle durchführen, wenn Sie Zugriff auf Server und Konten erhalten. Dazu lesen sie nicht nur E-Mails, sondern erhalten durch E-Mail-Footer und Ziel-, Absender- und Kopie-Adressen auch Informationen über weitere E-Mailkonten, Namen in Organisationen, Adressen, Telefonnummern und weitere Daten. Kritisch sind zudem zwei SMTP-Befehle. VRFY erlaubt das überprüfen von Accountnamen und EXPN ermöglicht das Auflösen von Mailinglisten (womit ersichtlich wird, welche Accounts in eine bestimmte Mailingliste eingetragen wurden). Die Absicherung von E-Mail-Diensten wird in Abschn. 8.5.5 erläutert.

7.5.5

Telnet, R-Dienste und SSH

Telnet (teletype network) ist ein Protokoll, das heute kaum mehr Verwendung findet. Einzeln ist es allerdings noch in vernetzten Produktionsumgebungen anzutreffen. Telnet dient der Remote-Administration von Rechnern und überträgt sämtliche Daten unverschlüsselt über TCP. Dies gilt auch für die Übertragung von Passwörtern und anderen sensitiven Daten. Selbiges gilt für die sogenannten R-Dienste [3] (rlogin, rsh und rcp), die das Remote-Administrieren und das Kopieren von Dateien auf andere Rechner ermöglichen. Zwar lässt sich definieren, welche Hosts eine Erlaubnis für die Nutzung der R-Dienste erhalten können, doch kann diese Sicherheitsmaßnahme durch Spoofing-Angriffe und Connection-Hijacking umgangen werden. Außerdem kann ein Angreifer unter Umständen die Konfigurationsdatei, in der die erlaubten Kommunikationspartner hinterlegt sind, manipulieren. Es empfiehlt sich daher der Einsatz der sichereren Alternative Secure Shell (SSH) als Ersatz für sowohl Telnet als auch für sämtliche R-Dienste.

236

7.5.6

7 Angriffe auf TCP/IP-Netzwerkprotokolle

NNTP

Das NNTP-Protokoll dient primär der Reconnaissance. Mit simplen Befehlen können, sofern keine Authentifizierung notwendig ist beziehungsweise dem Angreifer ein entsprechender Zugang bekannt ist, sämtliche Diskussionsgruppen aufgelistet (LIST) und Artikel sowie Metainformationen abgefragt werden (ARTICLE, HEAD, BODY, STAT, XOVER usw.). Wie auch bei der Reconnaissance über E-Mails sind hierbei nicht nur Nachrichteninhalte, sondern auch E-Mail-Adressen, Namen von Personen und Message-Footer interessant. Auch ist einem Angreifer ersichtlich, wie intensiv welches Thema in welcher Newsgroup debattiert wird, womit Rückschlüsse auf die Bedeutung bestimmter Themen für eine Organisation ersichtlich werden können. Derlei Wissen kann zur Vorbereitung von Spear Phishing oder anderen Formen des Social Engineerings verwendet werden. NNTP ist nicht vollständig von der Bildfläche verschwunden und wird beispielsweise noch als Support-Tool für die Kundenbetreuung eingesetzt. Kundenstämme und Kunden, die besonders schnell eine Antwort erhalten und vermutlich besonders wichtig sind, könnten von einem Angreifer (beispielsweise ein Konkurrenzunternehmen) relativ einfach identifiziert werden.

7.5.7

FTP

Das FTP kommt bei der Übertragung von Dateien (von einem Host auf andere Hosts) zum Einsatz. Es ist unverschlüsselt und basiert auf TCP. Analog zu den anderen unverschlüsselten Protokollen kann auch hier sämtlicher Datenverkehr mitgelesen werden. Bei schlechter Konfiguration können Benutzer zudem Verzeichnisse auslesen, auf die sie eigentlich keinen Zugriff haben sollten beziehungsweise entsprechend darin enthaltene Dateien herunterladen oder verändern. Manche Server erlauben zudem einen anonymen Login. Ist dieser nicht explizit deaktiviert, gelangen somit potenziell auch Angreifer auf einen FTP-Server. Anonyme FTP-Server können allerdings auch willentlich aufgesetzt werden, etwa, um Dateien öffentlich zur Verfügung zu stellen, wie das folgende Beispiel anhand des Anonymous-FTP-Servers des FreeBSD-Projekts zeigt. $ f t p f t p . f r e e b s d . org C o n n e c t e d t o f t p . geo . f r e e b s d . o r g . 220 T h i s i s f t p 0 . bme . f r e e b s d . o r g − h o s t e d a t Bytemark . co . uk Name ( f t p . f r e e b s d . o r g : s w e n d z e l ) : f t p 331 P l e a s e s p e c i f y t h e p a s s w o r d . Password : 230−

7.5 Angriffe auf der Anwendungsschicht

237

230− T h i s i s f t p 0 . bme . FreeBSD . org , g r a c i o u s l y h o s t e d by Bytemark . 230− 230−FreeBSD f i l e s c a n be f o u n d i n t h e / pub / FreeBSD directory . 230− 230 L o g i n s u c c e s s f u l . Remote s y s t e m t y p e i s UNIX . U s i n g b i n a r y mode t o t r a n s f e r f i l e s . ftp > Nicht zu vergessen ist, dass Angreifer oftmals versuchen, sich bei anderen Diensten, etwa SSH, mit FTP-Accounts anzumelden. Manchmal sind Benutzer dienstübergreifend auf einem Server freigeschaltet, was einen solchen dienstübergreifenden Login ermöglicht. Würde für obiges Beispiel ein Sniffer wie Wireshark eingesetzt werden, so würden Benutzername („ftp“) und Passwort (in diesem Fall „password“) für den menschlichen Betrachter lesbar sein (Abb. 7.4). Analog gilt dies auch für unverschlüsselte Übertragungen von SMTP, Telnet (dort aufgeteilt auf mehrere TCP-Segmente), POP, NNTP und weitere nicht binär operierende Protokolle.

Abb. 7.4 Mitgeschnittene FTP-Anmeldung in zwei Paketen: im obigen Paket wird der Benutzername übertragen, im unteren das Passwort

238

7.5.8

7 Angriffe auf TCP/IP-Netzwerkprotokolle

Sonstige historische Dienste

Diverse historische Dienste wie Finger, POP(2), TFTP, BOOTP und PCMAIL gelten als unsicher und sollten, wenn immer möglich, deaktiviert und durch neuere Protokolle ersetzt werden. Die Übertragungen über solche Dienste sind unverschlüsselt, dadurch mitlesbar und manipulierbar. Die veralteten Implementierungen sind zudem als hochgradig unsicher einzustufen. Eine historische Betrachtung der Sicherheit dieser genannten Protokolle findet sich in [3].

7.5.9

Zusammenspiel mehrerer Protokolle

Angemerkt sei an dieser Stelle noch, dass diverse Angriffe sich über mehrere Protokolle hinweg erstrecken. Ein Angriff auf ein bestimmtes Protokoll hat in einem solchen Szenario nicht primär den Ausfall oder die Manipulation des jeweiligen Dienstes zum Ziel, sondern verfolgt als Puzzlestück ein nachgeordnetes Ziel für ein zweites oder gar drittes Protokoll. Ein HTTP-basierter Request auf eine Ressource ABC der Domain XYZ kann etwa mit einem gleichzeitigen Angriff auf das DNS-Protokoll verbunden sein, um die IP von XYZ durch eine IP des Angreifers zu ersetzen. Ein Angreifer könnte auch den DNS-Eintrag für einen bestimmten SMTP-Server fälschen. Somit würde eine E-Mail an diesen falschen Mailserver versendet werden (jedenfalls, wenn die Domain vom Opfer aufgelöst wird und der angegriffene DNS-Server auch tatsächlich angefragt wird).

7.6

Zusammenfassung

Dieses Kapitel betrachtete Angriffe auf Netzwerkprotokolle für sämtliche Schichten des TCP/IP-Modells. Dabei können die zentralen Funktionen einer Schicht angegriffen werden. Auf der Netzzugangsschicht kann etwa durch Jamming die physikalische Datenübertragung beeinträchtigt werden. Auf der Internetschicht kann das Routing angegriffen werden, auf der Transportschicht können Nachrichtenströme unterbrochen, verfälscht oder übernommen werden und auf der Anwendungsschicht können gezielte Angriffe gegen Dienste durchgeführt werden – etwa das Verschicken von SPAM. Manche Angriffe wie etwa indirektes Cache Poisoning für DNS oder Angriffe auf dynamische Routingprotokolle sowie TCP-Reverse-Idle-Scanning sind nicht als trivial einzuordnen, ermöglichen allerdings Angriffe in für den Angreifer schwierigen Situationen. Für sämtliche Angriffe – außer solche mit physikalischer Grobeinwirkung, wie dem Kappen einer Verbindung, – ist das Verständnis der jeweiligen Netzwerkprotokolle essenziell. Im nächsten Kapitel wird ersichtlich, dass das Verständnis von Netzwerkprotokollen ebenso für die Verteidigung sämtlicher Netzwerkschichten von großer Bedeutung ist.

7.8 Übungsaufgaben

7.7

239

Weiterführende Literatur

In diesem Kapitel wurden Angriffe auf die wichtigsten Protokolle sowie einige protokollunabhängige Angriffe der vier Schichten des TCP/IP-Modells besprochen. Allerdings gibt es eine enorme Anzahl weiterer Netzwerkprotokolle, die ebenfalls sicherheitsrelevante Aspekte aufweisen. Auch gibt es so manch einen hier nicht betrachteten Sicherheitshinweis für die behandelten Protokolle. Generell empfiehlt es sich, einen Blick in die RFC-Spezifikationen der Protokolle zu werfen, die man im eigenen Netzwerk einsetzt. Für eine Zusammenfassung von DoS-Techniken empfiehlt sich die Lektüre von [17].

7.8

Übungsaufgaben

1. Bauen Sie Netzwerkverbindungen mit Remote-Hosts beliebiger Dienste auf. Nutzen Sie einen Sniffer Ihrer Wahl, etwa tcpdump, und sehen Sie sich die Datenübertragung im Detail an. Können Sie Benutzernamen und Passwörter sichten? Welche Daten sehen Sie bei einer unverschlüsselten SMTP- und POP3-Anmeldung? 2. Führen Sie in Ihrem eigenen LAN einen ARP-Spoofing-Angriff durch. Nutzen Sie frei verfügbare Tools. 3. Das Tool p0f (passive operating system fingerprinter) kann die Betriebssysteme von im LAN kommunizierenden Systemen ermitteln. Wie funktioniert es? Probieren Sie das Tool in Ihrem LAN aus. Weshalb handelt es sich bei diesem Tool um eines zur passiven Reconnaissance? 4. Erzeugen Sie ein gespooftes IPv4-Paket. Nutzen Sie dazu das Programm scapy und setzen Sie die Sender-Adresse auf eine, die nicht zu Ihrem Host gehört. 5. Vervollständigen Sie den RIP-Spoofer-Code aus Abschn. 7.3.5.2 und sehen Sie sich die erzeugten RIP-Pakete in einem Packet-Sniffer wie Wireshark an. 6. Welche Unterschiede gibt es zwischen RIPv1 und RIPv2 – was müsste sich beim Spoofing-Code ändern? 7. Für die Umsetzung eines RIPv2-Spoofers sind nur wenige Änderungen an Ihrem Code notwendig. Erweitern Sie Ihre Implementierung für RIPv2. 8. Führen Sie mithilfe von Nmap einen Portscan Ihres lokalen Rechners durch. Scannen Sie anschließend ein lokales Netzwerk (sofern dies Ihnen erlaubt sein sollte). Wenden Sie dabei die Scantechniken SYN-, FIN-, NULL- und XMAS-Scan an. Vergleichen Sie die erzielten Resultate. 9. Implementieren Sie einen TCP-Portscanner, der einen Connect-Scan durchführt. 10. Blockieren Sie lokale Ports durch eine Firewall. Vergleichen Sie, wie sich TCPConnect und -SYN-Scans in diesem Fall verhalten. Nutzen Sie dazu erneut das Tool Nmap. 11. Wie funktioniert der TCP-Reverse-Idle-Scan? 12. Erläutern Sie den Nutzen (Einsatzszenario) eines Fragmentation Scans für TCP, wie er in Nmap implementiert wurde.

240

7 Angriffe auf TCP/IP-Netzwerkprotokolle

13. Der folgende Code zeigt einen einfachen Banner-Scanner. Ihm kann eine IP-Adresse und ein Port übergeben werden. Die vom Server empfangene Begrüßungsnachricht, die oft das Banner enthält, wird schließlich angezeigt. Erweitern Sie den Code so, dass er auch HTTP-Server scannen kann – diese liefern Banner-Informationen nicht automatisch an den Empfänger. Stattdessen muss zunächst ein HTTP-Request gesendet werden, der bereits im Code vorgegeben ist (Variable buf). # include # include # include # include # include # include # include # include # include

< s y s / t y p e s . h> < s y s / s o c k e t . h> < s t d i o . h> < s t d l i b . h> < e r r . h> < a r p a / i n e t . h> < s t r i n g . h> < s t r i n g s . h> < u n i s t d . h>

i n t main ( i n t a r g c , char ∗ a r g v [ ] ) { int sockfd ; struct sockaddr_in sa ; char b u f [ ] = "OPTIONS / HTTP / 1 . 0 \ r \ n \ r \ n " ; char r e s p o n s e [ 2 0 4 8 ] = { ’ \ 0 ’ } ; i f ( argc < 3) { f p r i n t f ( s t d e r r , " Not enough p a r a m e t e r s . \ n " ) ; f p r i n t f ( " Usage : %s [ I P ] [ P o r t ] \ n " , a r g v [ 0 ] ) ; exit (1); } / ∗ A n l e g e n e i n e s S o c k e t s u e b e r I P v 4 ( AF_INET ) a l s ∗ Stream −S o c k e t ( f u e r TCP ) ∗ / i f ( ( s o c k f d = s o c k e t ( AF_INET , SOCK_STREAM, 0 ) ) < 0 ) { err (1 , " socket " ) ; } / ∗ ’ s a ’ m i t N u l l e n u e b e r s c h r e i b e n und a n s c h l . a u f ∗ IPv4−I n t e r n e t ( AF_INET ) den e n t s p r e c h e n d e n P o r t ∗ und A d r e s s e ( a r g v [ 1 und 2 ] ) k o n f i g u r i e r e n . ∗ / b z e r o (& sa , s i z e o f ( s a ) ) ; s a . s i n _ f a m i l y = AF_INET ; sa . s i n _ p o r t = htons ( a t o i ( argv [ 2 ] ) ) ;

Literatur

241

i f ( i n e t _ p t o n ( AF_INET , a r g v [ 1 ] , &s a . s i n _ a d d r ) < 0 ) { err (1 , " inet_pton " ) ; } / ∗ V e r b i n d u n g zum S e r v e r a u f b a u e n ∗ / i f ( c o n n e c t ( s o c k f d , ( s t r u c t s o c k a d d r ∗ ) &sa , s i z e o f ( sa ) ) != 0) { err (1 , " connect " ) ; } p r i n t f ( " Verbindung a u f g e b a u t . \ n " ) ; p r i n t f ( " r e c e i v e d %l i b y t e s \ n " , r e c v ( s o c k f d , r e s p o n s e , s i z e o f ( r e s p o n s e ) −1 , 0 ) ) ; p r i n t f ( " b a n n e r : ’% s ’ \ n " , r e s p o n s e ) ; /∗ Verbindung beenden ∗/ close ( sockfd ) ; return 0; } Beispielanwendung und -ausgabe des obigen Programms (lauffähig unter Linux): $ . / b a n n e r 1 4 3 . 9 3 . 1 6 0 . 2 0 22 Verbindung a u f g e b a u t . r e c e i v e d 21 b y t e s d a t a : ’SSH−2.0−OpenSSH_7 . 4 ’ 14. 15. 16. 17.

Was wird unter einer Amplification Attack bei DNS verstanden? Erläutern Sie die Vorgehensweise von DNS Cache Poisoning. Wie wird Cache Poisoning von Off-Path-Angreifern bei DNS durchgeführt? Setzen Sie einen Webserver (Software Ihrer Wahl) auf und konfigurieren Sie dort einen Passwortschutz mithilfe von .htaccess. Wie werden die Passwörter gespeichert? Lesen Sie ein korrekt übertragenes Passwort mit einem Sniffer mit und dekodieren Sie das Passwort in ein lesbares Format. (Hinweis: base64).

Literatur 1. Allen, J.M.: OS and application fingerprinting techniques (2007). https://www.sans.org/readingroom/whitepapers/authentication/os-application-finger-printing-techniques-32923. Zugegriffen am 01.06.2018 2. Anonymous: Maximum Security, 4. Aufl. SAMS, Indianapolis (2003) 3. Bellovin, S.M.: Security problems in the TCP/IP protocol suite. Comput. Commun. Rev. 19(2), 32–48 (1989)

242

7 Angriffe auf TCP/IP-Netzwerkprotokolle

4. Bernstein, D.J.: How the AXFR protocol works (2003). https://cr.yp.to/djbdns/axfr-notes.html. Zugegriffen am 01.06.2018 5. Cheshire: IPv4 Address Conflict Detection – RFC 5227. IETF (2008) 6. Debian Projekt: Debian Security Advisory, DSA-1603-1 bind9 – DNS cache poisoning (2008). https://www.debian.org/security/2008/dsa-1603. Zugegriffen am 01.06.2018 7. Fielding, R., Reschke, J. (Hrsg.): Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing – RFC 7230. IETF (2014) 8. Fielding, R., Reschke, J. (Hrsg.): Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content – RFC 7231. IETF (2014) 9. Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., Berners-Lee, T.: Hypertext Transfer Protocol – HTTP/1.1 – RFC 2616. Network Working Group (1999) 10. Helwig, M.: When your DNS leaks your infrastructure, 22 Jan 2018. https://www.codemetrix. net/when-your-dns-leaks-your-infrastructure/. Zugegriffen am 01.06.2018 11. Herzberg, A., Shulman, H.: Security of patched DNS. In: Proceedings of the European Symposium on Research in Computer Security (ESORICS), S. 271–288. Springer, Berlin/Heidelberg (2012) 12. Herzberg, A., Shulman, H.: DNS Security: Past, present and future. In: Proceedings 9th Future Security – Security Research Conference, S. 524–531. Fraunhofer Verlag, Stuttgart (2014) 13. Huegen, C.H.: The latest in denial of service attacks: „Smurfing“ description and information to minimize effects (1998). https://packetstormsecurity.com/files/15309/smurf.txt.html. Zugegriffen am 01.06.2018 14. Klein, A., Shulman, H., Waidner, M.: Internet-wide study of DNS cache injections. In: Proceedings of the IEEE Conference on Computer Communications (INFOCOM 2017), S. 1–9. IEEE, Atlanta (2017) 15. Lewis, E., Hoenes, A.: DNS Zone Transfer Protocol (AXFR) – RFC 5936. IETF (2010) 16. Lyon, G.F.: Nmap Network Scanning: The Official Nmap Project Guide to Network Discovery and Security Scanning (2009). https://nmap.org/book/. Zugegriffen am 01.06.2018 17. Masdari, M., Jalali, M.: A survey and taxonomy of DoS attacks in cloud computing. Sec. Commun. Netw. 9(16), 3724–3751 (2016). Wiley 18. Nikander, R. (Hrsg.), Kempf, J., Nordmark, E.: IPv6 Neighbor Discovery (ND) Trust Models and Threats – RFC 3756. IETF (2004) 19. Xiaoming, L., Sejdini, V., Chowdhury, H.: Denial of Service (DoS) attack with UDP Flood. School of Computer Science, University of Windsor, Canada (2010)

8

Absicherung der Netzwerkschichten

Any computer connected to the Internet is under threat from viruses, worms and attacks from hackers. Home users, as well as business users, are attacked on a regular basis. Thus the need to combat computer and network attacks is becoming increasingly important. – Simon Hansman und Ray Hunt (2004)

Zusammenfassung

In diesem Kapitel werden Techniken zur Absicherung von einzelnen Netzwerkschichten behandelt. Es beginnt dabei mit der Netzzugangsschicht des TCP/IP-Modells und endet bei der Anwendungsschicht.

8.1

Einführung

Für die Absicherung von Netzwerken gibt es auf jeder Schicht zahlreiche Optionen, die teils völlig unterschiedliche Ziele verfolgen. Im Folgenden werden die entsprechenden Schutzmaßnahmen, beginnend mit der untersten Netzwerkschicht, besprochen.

8.2

Absicherung auf der Netzzugangsschicht

Zunächst werden Methoden zur Absicherung der untersten Schicht im TCP/IP-Modell besprochen. Dabei handelt es sich zum Teil um technische und zum anderen um eher organisatorische Methoden.

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2018 S. Wendzel, IT-Sicherheit für TCP/IP- und IoT-Netzwerke, https://doi.org/10.1007/978-3-658-22603-9_8

243

244

8.2.1

8 Absicherung der Netzwerkschichten

Zutrittskontrolle und physikalischer Netzwerkzugang

Ein zentraler Aspekt der Absicherung dieser Schicht ist die Zutrittskontrolle. Inbesondere der Zugriff auf Kabel und Computer sowie auf Backups kann hierdurch geschützt werden. Zutrittskontrolle wird auch als Physical Access Control (PAC) bezeichnet. PAC ist Bestandteil der Gebäudetechnik. Umgesetzt wird PAC etwa mithilfe von CryptoTokens, Fingerabdruck-Scannern (beziehungsweise sonstigen biometrischen Scannern) oder klassischer Personal-/Mitarbeiterausweiskontrolle. Gemeint ist mit PAC nicht nur der Zutritt zu Gebäuden, sondern auch der zu Räumen oder „Käfigen“ in Räumen (Server eines Kunden im „privaten“ Bereich eines Serverraums). PAC spielt immer dann eine Rolle, wenn verschiedene Gebäude oder Räume mit einer unterschiedlichen Sensitivität verbunden sind. So kann ein Raum, in dem die Prüfungen von Studenten aufbewahrt werden, zum Beispiel als sensibler eingestuft werden als ein Hörsaal. Eine physikalische Zutrittskontrolle funktioniert selbstverständlich nur in dem Maße, wie ihre Umgehung durch einen Angreifer unmöglich ist. Wenn etwa ein Netzwerkkabel aus einem mit PAC gesicherten Raum herausführt und lose auf dem Flur hängt, kann ein Angreifer das Kabel verwenden, um etwa Daten mitzulesen. Ähnliches gilt selbstverständlich auch für Access Points – sie sollten möglichst an Decken hängen, sodass diese nicht ohne Leiter erreichbar sind. Die Konfiguration der Access Points könnte beispielsweise sonst von „Besuchern“ verändert werden. Nicht mehr verwendete Netzwerkports und Access Points sollten unbedingt deaktiviert werden beziehungsweise notfalls abgebaut werden. Zutrittskontrolle kann auch dadurch adressiert werden, dass Serverfarmen unter Wasser [1] oder unter Tage betrieben werden [2]. In beiden Fällen wird die Serverfarm besser gekühlt, was Lebensdauer und Performance der Hardware steigern kann. Unter Wasser können zudem in absehbarer Zeit einfacher erneuerbare Energien verwendet werden, um ein Rechenzentrum zu betreiben.

8.2.2

Erwerb and Integration von Hardware

Beim Erwerb und der Integration von Hardware weisen verschiedene Faktoren eine Sicherheitsrelevanz auf. Die „Fünf Ws“ können als Hilfestellung dienen, um bei Erwerb und Integration zu möglichst guten Entscheidungen zu kommen: 1. Wo wird Hardware erworben (und wer stellt diese Hardware her)? 2. Wo wird die Hardware voraussichtlich integriert werden? Hardware für vernetzte sensitive Bereiche sollte vorsichtiger ausgewählt werden, als solche für isolierte Systeme ohne sensitive Daten.

8.2 Absicherung auf der Netzzugangsschicht

245

3. Durch wen soll die Hardware integriert und gepflegt werden? Darf etwa nur ein Mitarbeiter mit Sicherheitsüberprüfung (SÜ) die Integration und Administration vornehmen? 4. Für welchen Zeitraum soll die Hardware verwendet werden? Diese Fragestellung ist etwa für Miete, Redundanz oder auch das Patching relevant. 5. Für welchen Personenkreis soll die Hardware (beziehungsweise darauf angebotene Dienste) zugänglich gemacht werden? Ergänzt werden könnten diese „Fünf Ws“ noch mit einem sechsten „W“, nämlich der Frage, wie die Komponenten letztlich entsorgt werden können. Ein simples Wegwerfen von Komponenten wäre eine schlechte Entscheidung, da Dumpster Diving (siehe Abschn. 3.6.3) erfolgen könnte. Ein Verkauf alter Hardware auf Webseiten wie Ebay kann wiederum zum Auslesen von Speichermedien durch potenzielle Angreifer führen – zumindest dann, wenn diese Medien nicht forensisch sicher gelöscht wurden.

8.2.3

Verfügbarkeit

Verfügbarkeit stellt ein zentrales Schutzziel der IT-Sicherheit dar und sollte in der Betrachtung der Netzwerksicherheit nicht vergessen werden. Ein zentraler Aspekt dabei ist die Redundanz von Komponenten, das heißt Netzwerkkarten, Lüfter, Netzteile, Netzkoppler und ganze Server. Im Extremfall kann sich eine Organisation auch Gedanken darüber machen, ein Rechenzentrum zu spiegeln – bei Großunternehmen ist dies gelebte Praxis und der zweite Ort eines Rechenzentrums wird oftmals geheim gehalten. Alternativ zur Spiegelung eines ganzen Rechenzentrums, aber sinnvoller als die Spiegelung einzelner Server vor Ort, ist die Option, nur Teile einer Serverinfrastruktur an einen Provider auszulagern. Für die Spiegelung von Netzwerksystemen existieren Protokolle wie CARP, das Common Address Redundancy Protocol. CARP ermöglicht es mehreren Hosts, eine einzige IP-Adresse zu verwenden. Beim Ausfall eines Servers kann somit auf einen anderen Server gewechselt werden, ohne dass sich die Adresse der Anfragen ändern muss. ARP-Requests werden entsprechend beantwortet. Alternative Protokolle zu CARP, insbesondere für Router, sind VRRP (Virtual Router Redundancy Protocol) und HSRP (Hot Standby Router Protocol) von CISCO. Die Verfügbarkeit kann allerdings auch durch gezielt eingesetzte Heterogenität gesteigert werden. Dies bedeutet, dass auf unterschiedliche Hardware- und Softwarekomponenten gesetzt wird, um einen Dienst redundant zu erbringen. Beim DNS werden beispielsweise verschiedene Hardwaresysteme eingesetzt, um darauf mit verschiedenen Betriebssystemen (etwa Unix, BSD und Linux) und verschiedener Software für die DNSServer (etwa Bind oder djbdns) einen ausfallsicheren Service zu ermöglichen. Kann etwa BSD mit einem neuen Exploit angegriffen werden, so bleiben Unix- und/oder Linux-Systeme mit etwas Glück davon verschont. Genauso muss eine Verwundbarkeit

246

8 Absicherung der Netzwerkschichten

in Bind nicht automatisch auch als Verwundbarkeit in djbdns vorliegen. Somit bleiben im erfolgreichen Angriffsfall immer noch Teile einer Service-Infrastruktur aktiv. Letztlich beinhaltet Verfügbarkeit aber auch, den Weiterbetrieb eines Netzwerks im Fall einer Katastrophe sicherzustellen. Hierzu zählen grundlegende Vorrichtungen wie CO2 -Anlagen und eine automatische Türschließung zur Eindämmung von Bränden, der Einsatz von unterbrechungsfreier Stromversorgung (USVs) mit Generatoren oder die Selektion von erdbebensicheren (beziehungsweise vor anderen Naturkatastrophen gesicherten) Orten für die Errichtung eines Rechenzentrums.

8.2.4

Komponentenverwaltung

Um eine Grundlage für die Schaffung von Sicherheit auf den untersten Ebenen zu ermöglichen, ist es notwendig, dass Administratoren eine genaue Übersicht über verwendete Hardware haben. Insbesondere sollten aus Sicht der Netzwerksicherheit alle Geräte mit Netzwerkzugang erfasst werden, inklusive Smartphones, Druckern und IoT-Geräten. Für diese Geräte sollten aber nicht nur Hersteller, Modell und Standort beziehungsweise Nutzer vermerkt werden. Stattdessen ist es äußerst förderlich, eine Liste von Firmwareversionen zu führen, inklusive des Zeitpunkts des letzten Upgrades. Dies ist von Hand nicht immer möglich und manchmal sind Firmwareversionen nicht einmal auslesbar. Wann immer es jedoch praktikabel und möglich ist, kann eine solche Liste enorm hilfreich sein, um den Überblick über vorhandene Komponenten und deren Patchlevel sowie Standorte zu haben. Sollte beispielsweise ein kritisches Sicherheitsupdate für Drucker des Modells X von Hersteller Y veröffentlicht werden, das für Firmwareversionen bis Z eingespielt werden muss, dann muss der Administrator wissen, welche Drucker aktualisiert werden müssen und wo sie sich befinden. Ein entsprechender Prüfprozess sollte regelmäßig durchlaufen werden. Zusätzlich können Sicherheitslücken selbstverständlich auch mit Penetrationstests gefunden werden. Für die meisten IoT-Geräte und Low-Level-Komponenten können allerdings nur Blackbox-Tests durchgeführt werden. Ein weiterer Gegenstand der Komponentenverwaltung kann eine Sicherheitsrichtlinie sein, die etwa ein regelmäßiges Ändern von Passwörtern verlangt; insbesondere bei solchen Passwörtern, die für eine Remote-Administration verwendet werden oder – im allerschlimmsten Fall – im Klartext übertragen werden.1

1 Bei einer exklusiven Direktverbindung, beispielsweise über die serielle Schnittstelle eines Switches, wird das Passwort selbstverständlich nicht über das restliche Netzwerk übertragen.

8.2 Absicherung auf der Netzzugangsschicht

8.2.5

247

MAC-Filter

Eine weit verbreitete Methode für den Zugriffsschutz auf dieser Netzwerkschicht stellen MAC-Filter dar. Sie erlauben den Netzwerkzugriff für Geräte ausschließlich für bekannte, festgelegte MAC-Adressen (Whitelist). Schließt ein Angreifer einen Computer an ein Netzwerk an, so werden dessen Pakete von der entsprechenden Kopplungseinheit nicht weitergeleitet; der Angreifer wird defacto isoliert. Entsprechend muss jeder neue Nutzer seine MAC-Adresse registrieren lassen. Eine MAC-Adresse sollte dabei auch jeweils nur für einen oder zwei Ports im Büro des Nutzers freigeschaltet werden. Wenn keine portspezifische Vergabe von MAC-Adressen festgelegt wird, könnte ein Nutzer ansonsten beliebige Ports in einem Netzwerk/Gebäude verwenden. Diese Situation kann wünschenswert sein, weil sie komfortabel ist, sollte aber dennoch nicht angestrebt werden. Es sollten zudem nicht einfach nur Ports freigeschaltet werden – sonst könnte ein Angreifer beispielsweise einen Drucker aus einem Port ausstecken und sein Laptop mit diesem Port verbinden. Alternativ könnte der Angreifer einen Hub verwenden, damit der Drucker weiterarbeitet, wodurch weniger Aufmerksamkeit erzeugt wird. Auch empfiehlt es sich, alle (versuchten) Anmeldungen an Ports zu protokollieren. Nun hört sich der Einsatz eines MAC-Filters gar nicht einmal so schlecht an. Wenn ein Angreifer allerdings Kenntnis über valide, das heißt ungefilterte, MAC-Adressen anderer Teilnehmer in Erfahrung bringen kann, dann kann er diese MAC-Adressen nutzen und sie spoofen. MAC-Adressen lassen sich mit Boardmitteln gängiger Betriebssysteme fälschen (beispielsweise unter Linux mit einem simplen Befehl). Daher sollten MACKonfigurationen auch nicht aushängen und Druckerräume nicht für Gäste zugänglich sein. Drucker können ihre Konfiguration zudem oft ausdrucken und solche Ausdrucke enthalten manchmal die MAC-Adresse der Netzwerkschnittstelle eines Druckers. Entsprechend könnten Angreifer diese MAC-Adresse analog zu obigem Angriffsszenario für sich selbst nutzen. Eine weitere Option stellt in diesem Kontext das Port/Address Locking dar [3]. Hierbei wird eine MAC-Adresse an einen bestimmten Port gebunden. Jede andere MAC-Adresse wird an diesem Port nicht akzeptiert (Pakete werden verworfen). Schließlich gilt auch für MAC-Filter das Aufräumprinzip: Nicht mehr benötigte MACAdressen sollten aus der Whitelist entfernt werden.

8.2.6

Denial-of-Serivce-Eindämmung

DoS-Angriffe können, wie im vorherigen Kapitel dargestellt, auch auf der untersten Schicht im TCP/IP-Modell durchgeführt werden. Dazu werden insbesondere Broadcastnachrichten über Hubs und Switche verteilt. Möglichkeiten zur Eindämmung von DoS-Angriffen sind das Sperren eines Ports beim Übersteigen eines bestimmten Thresholds für Broadcasts pro Zeiteinheit, zum Beispiel

248

8 Absicherung der Netzwerkschichten

Abb. 8.1 Illustration eines VLANs

fünf bis zehn ICMP-Broadcasts pro Sekunde. Eine Alternative besteht im Verwerfen von sämtlichem Broadcast-Traffic und nicht-kritischem Multicast-Traffic von einem thresholdübersteigendem Port [3]. Eine deutlich bessere Möglichkeit als das Sperren stellt allerdings das Verwerfen eines Teils der Pakete dar, wenn der Threshold erreicht wurde. Sollten etwa ICMP-Broadcasts oder ARP-Broadcasts einen Threshold übersteigen, könnte ein Switch/Router nur diese blocken, jedoch Datenverkehr sämtlicher sonstiger Protokolle weiterleiten. Dies isoliert einen potenziellen Angreifer nicht völlig und ermöglicht nach wie vor eine limitierte Kommunikation. Der Vorteil einer nur limitierenden Vorgehensweise besteht in der Behandlung von Systemen, die nur aufgrund einer Fehlkonfiguration beziehungsweise eines Softwarefehlers agieren – sie würden sonst fälschlicherweise isoliert werden. Ein Angreifer könnte im nicht-limitierenden – also vollständig isolierenden – Fall sogar explizit dafür sorgen, dass ein wichtiges System einen Threshold übersteigt, indem er Nachrichten spooft. Sollten daraufhin beispielsweise alle Pakete eines Servers geblockt werden, würde die Portsperrung einen DoS-Angriff ermöglichen.

8.2.7

Virtuelle LANs

Ein anderer isolierender Ansatz besteht in der logischen Aufteilung von lokalen Netzwerken in virtuelle Netzwerke (VLANs). Nachrichten werden nur innerhalb des jeweiligen VLANs weitergeleitet (Abb. 8.1). Dies gilt auch für Broadcasts. Ein Switch könnte beispielsweise bestimmte Ports an VLAN 1 und andere Ports an VLAN 2 zuweisen. VLANs können auch switchübergreifend realisiert werden [3]. Ein Mitarbeiter könnte beispielsweise eine Präsentation im Büro seines Vorgesetzten halten und dort sein Präsentationsnotebook verbinden – automatisch landet er im entsprechenden, ihm zugewiesenen, VLAN. Hierzu werden nicht einzelne Ports an VLANs zugewiesen. Stattdessen werden

8.2 Absicherung auf der Netzzugangsschicht

249

Systeme, die sich mit dem Switch verbinden, dem jeweiligen VLAN anhand ihrer MACAdresse zugewiesen.2 VLANs sind ein mächtiges Werkzeug und können in modernen Netzwerken im Prinzip netzwerkweit umgesetzt werden. Sie müssen jedoch von den Netzwerkgeräten unterstützt werden.

8.2.8

Absicherung des ARP-Caches

Um ARP Cache Poisoning durchführen zu können, muss der ARP-Cache dynamisch sein. Statische ARP-Einträge sind nämlich nur durch einen lokalen Administrator überschreibbar. Um nun das Spoofing (wichtiger) MAC-Adressen zu vermeiden, können diese im Prinzip statisch in den ARP-Cache eingetragen werden. Mit einer manuellen Eintragung ist allerdings ein enorm hoher Aufwand verbunden; bei größeren Netzen ist dieses Vorgehen praktisch unmöglich und entsprechend unattraktiv. Schutz bietet auch das bereits erwähnte VLAN (Abschottung der Netzwerkteilnehmer voneinander) sowie der genannte MAC-Filter (ein Teilnehmer mit unbekannter MACAdresse kann keine Netzwerkkommunikation durchführen). Diese Ansätze dämmen das Risiko des ARP Cache Poisonings etwas ein, doch können Bestandsnutzer nach wie vor Angriffe durchführen – zumindest innerhalb des jeweiligen VLANs. Weiterhin kann Proxy-ARP ähnlich einer Firewall eingesetzt werden. ARP-Requests werden dabei durch den Proxy für Geräte beantwortet, die nicht in dem LAN residieren, aus dem der Request stammt (sondern im hinter dem Proxy liegenden LAN). Somit kann ein ARP-Proxy Hosts auf der untersten TCP/IP-Schicht so abschotten, dass deren MACAdresse nicht sichtbar wird, weil er die MAC-Adressen des durch den Proxy geschützten LANs verdecktet. Neben diesen Limitierungs- und Präventionsansätzen gibt es die Möglichkeit, ARP Cache Poisoning zu detektieren. Dabei überwacht ein Netzkoppler (etwa Switch oder Host im „Promiscuous Mode“ in einem Netzwerk mit Hub) sämtlichen ARP-Datenverkehr. ARP Cache Poisoning wird identifiziert, wenn ein ARP Request mit unterschiedlichen ARP Replies innerhalb einer geringen Zeitspanne beantwortet wird. In diesem Fall liegt ein Original und eine Version des Angreifers vor. Allerdings genügt es nicht, duplizierte, aber inhaltlich identische ARP Replies zu „detektieren“, da mehrere Hosts im LAN einen ARP Request beantworten können, was ein legitimes Vorgehen darstellt. Im Falle einer Detektion empfiehlt sich das Verwerfen aller damit verbundenen Antworten des jeweiligen Systems und die Bereinigung des ARP-Caches sowie die Protokollierung der Angriffe. Einige freie Programme können bei der Detektion von ARP Cache Poisoning/ARP Spoofing helfen, etwa ArpOn und Arpwatch. Auch kann das Snort NIDS ARP-Spoofing im jeweils verbundenen Netzwerksegment detektieren.

2 MAC-Adressen können, wie bereits erläutert, gespooft werden. Deshalb sind zusätzliche Authentifikationsmethoden, etwa IEEE 802.1x (siehe Abschn. 8.2.9) empfehlenswert.

250

8.2.9

8 Absicherung der Netzwerkschichten

IEEE 802.1X

IEEE 802.1X ist ein Standard für die Authentifizierung von Geräten, die sich mit einem Netzwerk verbinden möchten. Die Nutzung des Netzwerks ist entsprechend nur nach erfolgreicher Anmeldung möglich und ohne Anmeldung erfolgt keine Weiterleitung der Daten durch den Zugangspunkt. Dieser Standard kann für verschiedene Netzwerktypen angewandt werden, sowohl kabelgebunden, als auch funkbasiert. Er kann zudem ergänzend zur Verschlüsselung der Übertragung eingesetzt werden (siehe Abschn. 8.2.10). Ein Endgerät verbindet sich zunächst mit einem Access Point. Dieser leitet die Authentifizierungsanfrage an einen Authentication Service weiter. Authentication Services können beispielsweise LDAP, RADIUS, TACACS und TACACS+ sein. Diese Systeme beinhalten im Wesentlichen Datenbanken der existierenden Benutzer und überprüfen, ob gesendete Benutzer-Passwort-Kombinationen korrekt sind. Das dabei verwendete Protokoll ist EAP (Extensible Authentication Protocol). EAP stellt eine Zwischenschicht zwischen verschiedenen Protokollen der untersten TCP/IP-Schicht und den Authentifizierungsmechanismen (etwa Smartcard oder Passwort) dar. Typischerweise wird IEEE 802.1X von professionellem Netzwerkequipment unterstützt und moderne Betriebssysteme verfügen ebenfalls über IEEE 802.1X-fähige Netzwerkstacks.

8.2.10 WLAN-Verschlüsselung Die Tatsache, dass Funkverkehr nicht mehr unverschlüsselt übertragen werden sollte, ist mittlerweile weitgehend bekannt und insbesondere in Wireless-LANs (und der Mobilfunkkommunikation) umgesetzt. Letztlich kommt es beim Einsatz der Verschlüsselungsverfahren in der Praxis nur noch auf zwei technische Aspekte an: die Selektion eines sicheren Verfahrens zum Integritäts- und Vertraulichkeitsschutz des Datenverkehrs und die Verwendung einer aktuellen und sicher konfigurierten Firmware/Software auf den beteiligten Geräten. Das frühe Verschlüsselungsprotokoll Wired Equivalent Privacy (WEP) gilt als hochgradig unsicher und ist kaum mehr im Einsatz. Der Nachfolger Wi-Fi Protected Access (WPA) wird ebenfalls nicht mehr für den Einsatz empfohlen und gilt ebenfalls als unsicher. Der Standard WPA-2 gilt hingegen als für den praktischen Einsatz sicher genug. Hierbei ist allerdings darauf zu achten, den verwendeten Zugangsschlüssel (symmetrischer Pre-Shared Key (PSK)) in regelmäßigen Abständen zu wechseln. Nach zehn Jahren und hunderten Gästen in einer Organisation, die den jeweiligen PSK auf ihren Geräten gespeichert haben, kann auch WPA-2 nicht mehr vor fremden Nutzern schützen. Wenn ein Angreifer nur ein einziges Altgerät aus einem WPA-2-Netzwerk mit nicht forensisch sicher gelöschtem Speicher – etwa bei Ebay – erwirbt, kann er eventuell bereits den PSK auslesen und für den Zugang zum jeweiligen Organisationsnetzwerk verwenden.

8.3 Absicherung auf der Internetschicht

251

8.2.10.1 Alte Verfahren: WEP und WPA WEP ist obsolet. Es sollte eine sichere WLAN-Verschlüsselung auf Basis von RC-4 (eine sogenannte Stromchiffre, siehe Abschn. 4.5.2) ermöglichen. Ein Schlüsselstrom wird dabei von einem Pseudozufallszahlengenerator (PRNG) erzeugt. Dieser Schlüsselstrom wird mit dem Klartext per XOR verrechnet. RC4 gilt allerdings als äußerst unsicher. WEPSchlüssel können mit aufgezeichnetem Datenverkehr heute in wenigen Minuten berechnet werden. WPA basiert ebenfalls auf WEP und RC4, kann jedoch eine bessere Authentifizierung (IEEE 802.1X) anbieten. Im Wesentlichen verwendet WPA für jedes Datenpaket einen neuen PRNG-Initialisierungsvektor (siehe Abschn. 4.5.1), WEP wechselt diesen Initialisierungsvektor hingegen nicht. WEP und WPA können relativ einfach mit Wörterbuchverfahren (Brute-Force-Angriff) angegriffen werden. 8.2.10.2 WPA-2 WPA-2 stellt eine Weiterentwicklung von WPA auf Basis des Sicherheitsstandards IEEE 802.11i dar. Anstelle einer Stromchiffre (RC4) wird die sichere Blockchiffre AES im CBC-Modus (siehe Abschn. 4.6.3) eingesetzt. Die Authentifizierung erfolgt bei WPA-2 über Pre-shared Keys (PSK) oder RADIUS. Das WPA-2-Verfahren gilt derzeit als sicher, sofern ein guter PSK (mit hoher Entropie und ausreichender Schlüssellänge) verwendet wird. Bisher sind primär Wörterbuchangriffe bekannt, sie stellen bei einem guten PSK allerdings einen äußerst hohen Aufwand dar. Im Jahr 2017 wurde zudem die Key Reinstallation Attack (KRACK) veröffentlicht, die insbesondere die Festlegung eines neuen Schlüssels durch einen Angreifer ermöglichte. Die damit verbundene Schwachstelle konnte allerdings durch Patches bereinigt werden. Ein kleiner Nachteil gegenüber WPA besteht darin, dass AES etwas mehr Rechenleistung als RC4 benötigt. Auf alten Komponenten mit wenig Rechenleistung mag AES unter Umständen zu langsam sein, um beispielsweise eine notwendige Response-Time einzuhalten. Auf der anderen Seite sollte sich dieses Problem relativ zeitnah beheben lassen, bedenkt man, dass AES durch Bitshifts und XOR-Operationen auch auf embedded Prozessen gut bearbeitet werden kann und alte Access Points kostengünstig ersetzt werden können.

8.3

Absicherung auf der Internetschicht

Bei der Betrachtung der Sicherheit der Internetschicht (sowie von ihr eingekapselter Netzwerkschichten) spielen Virtuelle Private Netzwerke (VPNs) eine zentrale Rolle. VPNs wurden bereits in Abschn. 5.3 separat behandelt. In diesem Abschnitt werden hingegen solche Absicherungsaspekte besprochen, die VPNs entweder nicht betreffen oder auf ihnen aufbauen.

252

8.3.1

8 Absicherung der Netzwerkschichten

Härtung des IPv4/IPv6-Stacks

Eine simple Schutzmaßnahme, die allerdings nicht immer applizierbar ist, besteht darin, unbenötigte Komponenten von Netzwerkstacks abzustellen. Soll in einem Netzwerk etwa nur IPv4 oder nur IPv6 verwendet werden, dann kann die Unterstützung, zumindest bei einigen Betriebssystemen, für die jeweilig andere Protokollversion deaktiviert werden. Auch können einzelne Funktionen der Protokolle deaktiviert und festgelegt werden, dass nur eine bestimmte Anzahl von Nachrichten des Typs X pro Zeitfenster gesendet werden darf. Ein Beispiel hierfür ist das ICMP Rate Limiting. Dabei wird ein Grenzwert festgelegt, der die Anzahl der ICMP-Nachrichten pro Zeiteinheit eindämmt, was wiederum DoSAngriffe limitiert. Die meisten IPv4-Schutztechniken sind für IPv6 ebenfalls einsetzbar. Dies betrifft etwa Firewalling und die Deaktivierung des Supports für bestimmte Netzwerknachrichten. Oftmals wird insbesondere die Verarbeitung bestimmter ICMP-Nachrichten deaktiviert. Teilweise können Nachrichten auch nur in bestimmten Fällen unverarbeitet bleiben. ICMP Redirects könnten beispielsweise akzeptiert werden, sofern sie von einem bisher tatsächlich benutzten Router versendet wurden.3 Eine Auflistung der unzähligen Parameter zur Konfiguration und Härtung von Netzwerkstacks findet sich in den jeweiligen Büchern zur Betriebssystem-Härtung sowie in unzähligen, online verfügbaren Guidelines. Auf eine detaillierte Diskussion wird an dieser Stelle auch deshalb verzichtet, weil sie immer betriebssystemspezifisch erfolgen muss und dargelegte Parameter zeitnah veralten würden.

8.3.2

Firewalls für die IP-Kommunikation

Ein Großteil der Fähigkeiten von Firewalls bezieht sich auf Protokolle der Transportschicht, doch gibt es auch relevante Fähigkeiten auf der Internetschicht. Wie verwoben beide Schichten in heutigen Firewalls sind, zeigt Ihnen Abschn. 8.4.1 am Beispiel von ICMP Source Quench. An einem Router, der ein autonomes System mit einem anderen autonomen System verbindet (der ein Border-Router ist), kann eine Firewall interne Adressen filtern, die nicht mit externen Systemen kommunizieren sollen (insbesondere ist dies für IPv6 relevant). Weiterhin lassen sich Spoofing-Angriffe durch Plausibilitätsprüfungen verhindern. Eine Absenderadresse, die in einem Subnetz X nicht vergeben ist, aber eine Firewall passiert, die mit diesem Subnetz verbunden ist, kann etwa geblockt werden. Sogenannte BogonAdressen können ebenfalls gefiltert werden. Es handelt sich dabei um nicht vergebene IPAdressen. Auch ist selbstverständlich das Filtern unerwünschter Nachrichtentypen (etwa

3 Durch die Möglichkeit des IP-Spoofings ist allerdings kein hinreichender Schutz gegeben und ICMP Redirects sollten generell nicht von Hosts verarbeitet werden.

8.3 Absicherung auf der Internetschicht

253

oben genannter ICMP Redirects) möglich. Viele Firewalls können Datenpakete zudem normalisieren, was jedoch über die eigentliche Funktionalität einer Firewall hinausgeht. So können etwa gesetzte Bits in reservierten Headerfeldern vor der Paketweiterleitung entfernt werden. Traffic Normalization wird in Abschn. 9.3.3 erläutert.

8.3.3

SEND: Secure Neighbor Discovery Protocol

Das IPv6-basierte Neighbor Discovery Protocol (NDP, siehe Abschn. 2.10) ist insbesondere deshalb so anfällig für Angriffe, weil Nachrichten nicht authentifiziert werden. Secure Neighbor Discovery (SEND, RFC 3971) sichert NDP mit kryptographischen Verfahren ab, um diesem Problem zu begegnen. SEND erhöht die Sicherheit des NDP dabei durch folgende Merkmale: SEND kann eine PKI mit Zertifikaten verwenden, um Router überprüfbar zu machen. SEND kann zudem eine RSA-Signatur zur Sicherstellung der Integrität und Authentizität der eigentlichen SEND-Nachrichten nutzen. Es kann außerdem einen Timestamp zur Absicherung gegen Replay-Angriffe (erneutes Senden abgefangener alter (aber verschlüsselter) Nachrichten durch einen Angreifer) verwenden. SEND adressiert auch das Problem der Duplicate Address Detection DoS-Attack. RFC 3791 gibt hierzu folgende Auskunft [4]: SEND counters this attack by requiring that the Neighbor Advertisements sent as responses to DAD (Duplicate Addr. Detection, Anm. d. Autors) include an RSA Signature option and proof of authorization to use the interface identifier in the address being tested. If these prerequisites are not met, the node performing DAD discards the responses.

SEND kennt Cryptographically Generated Addresses (CGA), die Spoofing erschweren. Im Wesentlichen handelt es sich bei CGA um einen 64-Bit Hashwert vom öffentlichen Schlüssel eines Senders; dieser wird in einem Teil der IPv6-Adresse eingebettet (und zwar in den Interface Identifier, genauer in den Bits 64–127). RFC 3972 weist darauf hin, dass diese 64-Bit alleine keine ausreichende Lösung darstellen [5]: As computers become faster, the 64 bits of the interface identifier will not be sufficient to prevent attackers from searching for hash collisions. It helps somewhat that we include the subnet prefix of the address in the hash input. This prevents the attacker from using a single pre-computed database to attack addresses with different subnet prefixes. The attacker needs to create a separate database for each subnet prefix. Link-local addresses are, however, left vulnerable because the same prefix is used by all IPv6 nodes.

SEND kennt zudem Nonces. Eine Nonce ist ein Zahlenwert und wird in die SolicitationNachricht eingefügt. Eine darauffolgende Advertisement-Nachricht muss dieselbe Nonce beinhalten, sonst wird sie als ungültig betrachtet. Dieses Verfahren sichert die Aktualität einer Antwort (ähnlich wie die Reply-Protection).

254

8 Absicherung der Netzwerkschichten

Leider ist auch SEND nicht perfekt. Es ist etwa denkbar, DoS-Angriffe mit einer hohen Anzahl von SEND-Nachrichten, die ein Empfänger überprüfen muss, durchzuführen. Aufgrund des Aufwands der kryptografischen Überprüfung der Nachrichten muss ein Empfänger viel Rechenzeit aufwenden, die ein Absender nicht unbedingt aufwenden muss (er kann etwa Zufallswerte verwenden). DoS-Angriffe können, so sieht es auch RFC 3971 vor, durch Rate Limiting eingedämmt werden. Weitere Angriffsmöglichkeiten auf SEND finden sich in [4] und [6].

8.4

Absicherung der Transportschicht

Die Transportschicht ist, wie im vorherigen Kapitel dargelegt, von einer Vielzahl möglicher Angriffe betroffen. Betrachtet werden im Folgenden insbesondere die Erkennungsmethoden für Portscans auf TCP und UDP sowie die Härtung des TCP-Stacks.

8.4.1

Firewalls und Angriffserkennung für TCP und UDP

Auch auf der Transportschicht können Firewalls eine wichtige Abschottungsfunktion erfüllen. Sie können beispielsweise Portscans blockieren. NIDS können Angriffe, darunter natürlich auch besagte Portscans, hingegen detektieren. Da es sich hierbei um ein Lehrbuch und nicht um ein Buch über ein bestimmtes Firewallprodukt handelt, verweise ich den interessierten Leser auf die Dokumentation der jeweilig verwendeten Firewall. Im Folgenden möchte ich Ihnen prägnant bedeutsame Funktionen moderner Firewalls erläutern. Das folgende Listing zeigt ein simples Beispiel für die Konfiguration der Firewall des OpenBSD-Betriebssystems, wobei egress für die Netzwerkschnittstelle mit der Standardroute steht. Umgesetzt wird ein Konzept namens Default Deny, bei dem zunächst alle Pakete, die auf dieser Schnittstelle eintreffen, geblockt werden. Die darauffolgenden Regeln definieren die erlaubte Kommunikation explizit (Whitelist): # " d e f a u l t deny " ; d i e l e t z t e R e g e l " g e w i n n t " b l o c k i n on e g r e s s # e i n g e h e n d e HTTP ( S)− P o r t s e r l a u b e n p a s s i n on e g r e s s p r o t o t c p p o r t { 8 0 , 4 4 3 } # e i n g e h e n d e DNS−P o r t e r l a u b e n p a s s i n on e g r e s s p r o t o udp p o r t 53 # e i n g e h e n d e n V e r k e h r zum SSH−P o r t u e b e r d i e # N e t z w e r k s c h n i t t s t e l l e ne3 von den H o s t s

8.4 Absicherung der Transportschicht

255

# 192.168.0.100/101/102 erlauben b l o c k i n on ne3 p a s s i n on ne3 p r o t o t c p from 1 9 2 . 1 6 8 . 0 . 1 0 0 t o \ 1 9 2 . 1 6 8 . 0 . 1 0 2 p o r t 22 Firewalls können sich TCP-Verbindungen merken, und somit in Erfahrung bringen, ob eintreffende Pakete zu bestehenden Verbindungen gehören, oder nicht. Das entsprechende Feature nennt sich State Keeping und soll erneut anhand der OpenBSD-Firewall verdeutlicht werden. Bei ihr wird State Keeping zum Teil automatisch aktiviert und muss durch no state explizit deaktiviert werden. TCP-Segmente, die nicht zu einer Verbindung gehören und keinen Verbindungsaufbau initiieren, werden entsprechend geblockt. Der zweite Teil des Listings zeigt eine etwas ausgefallenere Technik aus der OpenBSD-Dokumentation. Dabei merkt sich die Firewall, welche TCP-Verbindungen es gibt. Erreicht die Firewall nun ein ICMP Source Quench Paket (zur Drosselung der Aussenderate), wird dies nur akzeptiert, wenn es sich auf eine bestehende TCP-Verbindung bezieht. Außerdem werden die ISN-Werte der TCP-Verbindungen randomisiert, was Connection-Hijacking erschwert. # keeping s t a t e p a s s i n on ne3 p r o t o t c p from any t o any # m o d u l a t e s t a t e : J e d e ISN r a n d o m i s i e r e n und zudem # TCP−b e z o g e n e ICMP−N a c h r i c h t e n im k e e p s t a t e −Modus # bearbeiten . p a s s o u t on ne3 p r o t o { t c p , icmp } \ from any t o any m o d u l a t e s t a t e State Keeping wird in ähnlicher Form auch für UDP bereitgestellt. Die Funktion kann hier so verstanden werden, dass nur UDP-Pakete angenommen beziehungsweise versendet werden, für die zuvor Anfragen gesichtet wurden. Ein Beispiel mit der Linux-Firewall4 : # Pakete a k z e p t i e r e n , die Antworten auf eigene Anfragen # erhalten . i p t a b l e s −A INPUT −m s t a t e \ −− s t a t e ESTABLISHED , RELATED − j ACCEPT Für UDP-basiertes State Keeping sind natürlich einige Ausnahmen zu betrachten, etwa, dass DNS-Requests trotz der Regel, dass nur auf zuvor eingetroffene Pakete geantwortet werden darf, durchgeführt werden können. Regelsätze können sehr komplex werden. Sie können noch viele weitere Inhalte filtern, etwa nach Betriebssystem basierend auf OSFingerprinting (unterstützt von der OpenBSD-Firewall).

4 Mehr zum Thema State Keeping mithilfe von iptables erfahren Sie auf der Webseite http://

www.iptables.info/en/connection-state.html.

256

8.4.2

8 Absicherung der Netzwerkschichten

Portscan-Detektion

Portscans werden von NIDS üblicherweise dadurch erkannt, dass ein Host über einen relativ kurzen Zeitraum mehrere Ports abfragt. Als Grenzwert ließe sich hierbei etwa festlegen, dass innerhalb von 30 Sekunden mehr als 10 Zielports über UDP oder TCP angefragt werden – von dem jeweils gleichen Absender. Typische NIDS wie Snort unterstützen eine derartige Funktion; die Grenzwerte können jeweils in einer Konfigurationsdatei festgelegt werden. In [7] führt Collins an, dass hierbei eine relativ einfache Faustregel angewandt werden kann: Dazu stelle man sich ein Koordinatensystem vor, dessen horizontale Achse die Hosts eines Netzwerks und dessen vertikale Achse die Ports dieser Hosts darstellen (siehe Abb. 8.2). Ein gezielter Angreifer, der eine bestimmte Verwundbarkeit ausnutzen möchte, weiß, dass diese Verwundbarkeit auf sehr wenigen Ports, eventuell auf nur einem, zu finden sein wird. Entsprechend führt er einen horizontalen Scan durch, das heißt er überprüft den immer gleichen Port auf vielen Hosts. Ein Administrator würde zur Überprüfung der offenen Ports eines Hosts hingegen einen vertikalen Scan durchführen, also alle Ports eines Hosts scannen. Ein weiterer Indikator, der auf einen Portscan hindeutet, liegt vor, wenn nicht vorhandene Hosts in einem Netzwerk gescannt werden, wenn also ein Host versucht, diese nicht vorhandenen Hosts zu kontaktieren [7]. Angreifer wissen oftmals nicht, welche potenziellen Ziele es in einem Netzwerk gibt und können sich durch einen Scan, der alle IP-Adressen eines Netzes einbezieht, einen Überblick über selbige verschaffen. Darauf aufbauend finden die Angreifer manche Hosts, die offene Ports aufweisen, für die sie

Abb. 8.2 Darstellung typischer Portscans. Vertikal wurden besonders relevante Ports innerhalb der ersten 2000 Ports gescannt. Horizontal wurde auf jedem der zehn Hosts der Port 1337 gescannt

8.4 Absicherung der Transportschicht

257

Exploits haben [7]. Derlei Hosts notiert ein Angreifer gern auf einer sogenannten Hitlist. Für Systeme auf der Hitlist wird der Angreifer laut Collins aller Wahrscheinlichkeit nach einen horizontalen Scan durchführen; ein solcher horizontaler Scan deckt allerdings nicht mehr sämtliche verfügbaren Systeme ab und ist daher etwas schwieriger zu klassifizieren.

8.4.3

TCP-Härtung

Durch Härtung des TCP-Stacks können diverse Angriffe entweder verhindert oder erschwert werden. Insbesondere interessant ist die Unterbindung von TCP-Reset-Angriffen, TCP-Spoofing und TCP-Connection-Hijacking. Die IETF schlug vor, nur solche Pakete zu akzeptieren, deren Sequenznummern exakt denen entsprechen, die von einem Empfänger erwartet werden. Ein Angreifer müsste, um Pakete in eine Verbindung zu injizieren, folglich die richtigen Sequenznummern erraten. Dies betrifft alle drei genannten Angriffsszenarien. Früher wurden die ISNs nach einem simplen, nicht-randomisierten Schema vergeben. Dies ist nun anders. Gemäß RFC-Standard sollten TCP-Implementierungen randomisierte ISNs vergeben. Ein Angreifer muss die ISN beziehungsweise Sequenznummer somit für jede Verbindung neu erraten. Die zufällige Vergabe von Quellports statt ihrer inkrementellen Vergabe erhöht die Sicherheit zusätzlich, da auch Ports korrekt geraten werden müssen. Möchte der Angreifer kein umfangreiches Ratespiel mitspielen, könnte er sich noch als Man-in-the-Middle installieren und die übertragenen Segmente mitlesen. Dieser Angriff ist allerdings oft nicht möglich und erfordert zudem einen höheren Aufwand. Ein weiterer TCP-basierter Angriff, den Sie bereits kennen, ist das SYN-Flooding. Dem SYN-Flooding kann mit der Einführung sogenannter SYN-Cookies begegnet werden. SYN-Cookies wurden insbesondere durch D. J. Bernstein vorgeschlagen [8]. Die Idee ist folgende: Bob merkt sich die empfangenen SYN-Pakete von Alice nicht lokal, bettet aber Informationen über ein SYN-Paket in die ISN seiner eigenen Antwort ein. Er berechnet den Wert für seine ISN wie folgt: ISN = (t mod 32) : 5||m : 3||H (s) : 24 Die Schreibweise x : y bedeutet in diesem Fall, dass der Wert x genau y Bits aufweisen soll, || steht für die Konkatenation von Bits. H ist eine von Bob frei wählbare Hashfunktion. t ist ein Zeitstempel, der langsam inkrementiert wird (z.B. alle 30 Sekunden). m steht für die kodierte MTU einer Verbindung, wobei davon ausgegangen wird, dass die drei vorgesehenen Bits für typische MSS-Werte genügen sollten. Der Wert s stellt geheime Bits dar, selektiert und errechnet aus eintreffenden Paketen: Bei diesen Werten für s handelt es sich um die IP-Adresse und dem Quellport sowie den Zielport des Pakets. Die ISN von Bob wird von Alice im gutartigen Fall (es liegt kein SYN-Flooding vor) erhöht, Bob kann die Original-ISN allerdings errechnen und auf Plausibilität der Daten

258

8 Absicherung der Netzwerkschichten

prüfen. Bob prüft, ob t aktuell beziehungsweise (t − 1) ist, also ob die Daten folglich noch aktuell sind. Er überprüft anschließend, ob der Hashwert zur Quell-IP-Adresse, zum Quell-Port und zum Zielport passt. Sind diese Bedingungen nicht erfüllt, muss das Paket nicht weiter verarbeitet werden und Bob muss die entsprechenden Verbindungsdaten nicht zwischenspeichern. SYN-Cookies lassen sich unter den meisten Betriebssystemen mit einem kurzen Handgriff aktivieren, unter Linux etwa mit # e c h o 1 >/ p r o c / s y s / n e t / i p v 4 / t c p _ s y n c o o k i e s Eine Weiterentwicklung der klassischen SYN-Cookies nennt sich TCP Cookie Transactions (TCPCT) [9]. Dabei erfolgt die Einbettung der SYN-Cookies in eine TCP-„Cookie Option“ [10]. Auch gibt es sogenannte TCP Fast Cookies, die TCPCT ähneln, allerdings Detailunterschiede aufweisen. Letztlich bringen SYN-Cookies auch immer ein Ressourcenproblem mit sich, schließlich muss Bob die empfangenen Cookies validieren. Aus diesem Grund empfiehlt sich die Einführung eines Limits für die maximale Anzahl parallel zu vergebener Cookies. Auf eine Überschreitung des Limits folgt die temporäre Einstellung der Fast Cookies und beispielsweise die Aktivierung von normalen SYNCookies. In Ergänzung zu diesen Ansätzen der SYN-Flooding-Vermeidung empfiehlt sich der Einsatz eines NIDS beziehungsweise einer Firewall. Diese können eine Messung der SYN-Nachrichten pro Sekunde und der damit verbundenen Quelladressen und Zielports durchführen. Im Verdachtsfall für SYN-Flooding kann ein NIDS den Administrator informieren und eine Firewall entsprechende Absenderadressen (temporär) blockieren.5

8.5

Absicherung der Anwendungsschicht

In der Betrachtung der Absicherung von Netzwerkschichten fehlt nun noch die Anwendungsschicht. Diese Schicht ist die wohl diversifizierteste Schicht, denn ihre Protokolle erbringen hochgradig unterschiedliche Dienste.

8.5.1

Generelle Anmerkungen zur Anwendungsschicht

Auf der Anwendungsschicht werden die Netzwerkdienste für Endnutzer erbracht, etwa Webservice und Mailtransport. Aus diesem Grund ist zur Sicherung immer ein direktes Hardening der Serversoftware sinnvoll. Entsprechend ist die Konfiguration zu überprüfen und sind Hardening-Guidelines für den jeweiligen Dienst durchzulesen. Für die meisten Dienste kann etwa der sogenannte Banner deaktiviert werden. Ein Banner zeigt an, um was 5 Auch dieser Ansatz ist nicht perfekt, falls Eve die Absenderadresse für ihr SYN-Flooding spooft. In diesem Fall könnte sie dafür sorgen, dass die Kommunikation mit einem legitimen, eventuell wichtigen, System blockiert wird, also einen DoS hervorrufen.

8.5 Absicherung der Anwendungsschicht

259

für eine Serversoftware (ggf. samt Version, Betriebssystem und Modulen) es sich handelt. Ein Angreifer kann diese Informationen nutzen, um auf Verwundbarkeiten zu schließen. Die meisten Banner können über eine Telnet-Verbindung abgefragt werden. Das folgende Listing zeigt eine mögliche Antwort für einen HTTP/1.1-Request. $ t e l n e t w e b s e r v e r . e x a m p l e . o r g 80 Trying [ IP ] . . . Connected t o webserver . example . org . Escape c h a r a c t e r i s ’ ^ ] ’ . HEAD / HTTP / 1 . 0 HTTP / 1 . 1 200 OK D a t e : Mon , 09 Apr 2018 1 3 : 3 4 : 2 9 GMT S e r v e r : Apache / 2 . 4 . 6 ( CentOS ) OpenSSL / 1 . 0 . 2 k−f i p s m o d _ f c g i d / 2 . 3 . 9 mod_wsgi / 3 . 4 P y t h o n / 2 . 7 . 5 PHP / 7 . 1 . 1 0 Connection : close C o n t e n t −Type : t e x t / h t m l ; c h a r s e t =UTF−8 Ersichtlich ist, dass hier ein Apache-Webserver der Version 2.4.6 läuft. Das Betriebssystem ist CentOS (eine Linux-Distribution) und außerdem verwendet der Server mehrere aktivierte Module, nämlich OpenSSL in der Version 1.0.2k-fips, das FastCGI-Modul in der Version 2.3.9, das WSGI-Modul6 in der Version 3.4 und serverseitige Unterstützung für Skriptsprachen durch die Module für Python (2.7.5) und PHP (7.1.10). Weiterhin ist es wichtig, Zugriffsrechte für Dienstprozesse und für -nutzer zu überprüfen sowie zu minimieren. Diverse Schutzfunktionen moderner Betriebssysteme können zudem dabei helfen, die Ausnutzung von Diensten einzudämmen. Hierzu zählen insbesondere sämtliche Formen des Sandboxings. Eine Sandbox dämmt die Möglichkeiten eines Prozesses ein und stellt ihm eine reduzierte Arbeitsumgebung zur Verfügung. Beispielsweise können die Anzahl und die Parameter für bestimmte Systemaufrufe reduziert werden. Unter unixartigen Systemen sind dabei primär Jail/Chroot-Umgebungen sowie Erweiterungen der Kernfunktionen für das Betriebsystem (etwa SELinux) im Einsatz. Weiterhin können auf Dienstebene oftmals nicht (mehr) benötigte Module, die aber potenziell verwundbar sein könnten, deaktiviert werden. Beispielsweise können alte Verschlüsselungsmethoden und weniger sichere Authentifizierungsmethoden in SSH oder Webserver-Module deaktiviert werden. Selbiges gilt für Zusatzmodule von FTP-Servern und E-Mail-Diensten, etwa ungenutzte Datenbankschnittstellen. Während nicht benötigte Module deaktiviert werden, können allerdings Module integriert werden, die die Sicherheit eines Dienstes steigern. Für den Webserver Apache existiert etwa das Sicherheitsmodul mod_security, für PHP existiert eine Hardening-

6 Web Service Gateway Interface.

260

8 Absicherung der Netzwerkschichten

Umgebung und Remote-Logins auf den SSH-Dienst können nach mehreren Fehlversuchen mit fail2ban deaktiviert werden – die Möglichkeiten sind äußerst vielfältig. Dienste und ihre Umgebungen (etwa Dateisysteme) können zudem turnusmäßig auf Verwundbarkeiten und auf eine unsichere Konfiguration gescannt werden. Tools wie rkhunter (scannt nach Rootkits), AIDE und mtree (HIDS für Dateisysteme) sowie nikito (Verwundbarkeitsscanner für Webservices) können hierfür eingesetzt werden. Ein weiterer wichtiger Bestandteil der Sicherheit der Anwendungsschicht ist das Monitoring der Dienste.7 Monitoring bedeutet letztlich Überwachung. Tatsächlich wird Monitoring so umgesetzt, dass dabei ein Dienst Nachrichtenmeldungen anderer Dienste zentral aggregiert (etwa syslog). Die gesammelten Daten können dann zentral verglichen und ausgewertet werden, etwa mit Heuristiken oder maschinellen Lernverfahren, um auf Angriffe zu schließen. Der Vollständigkeit halber muss an dieser Stelle ein DoS-Angriff zur Sprache kommen. Es ist bei manchen Systemkonfigurationen für einen Angreifer möglich, die lokalen Logdateien eines Rechners mit Logmeldungen zu überfüllen. Betrifft dies eine für die Diensterbringung wichtige Partition, dann kann ein Dienst unter Umständen eingeschränkt werden. Vor allen Dingen können jedoch keine weiteren Nachrichten von Diensten protokolliert werden, sobald kein Speicher mehr dafür verfügbar ist. Dienste wie logrotate und eine separate Partition für einen Dienst können dieses Problem eindämmen. Selbstverständlich ist die Anwendung von kryptografischen Techniken auf der Anwendungsschicht essenziell, insbesondere sofern sich nicht untere Schichten darum kümmern. Dies kann etwa über SSH-basierte Tunnel oder den Einsatz von TLS für die Datenübertragungen erfolgen. Je nach Dienst und Szenario sind dabei unterschiedliche Verfahren interessant, primär solche zur Sicherung der Vertraulichkeit und der Integrität übertragener Daten. Bedeutsam kann auch die Absicherung der Protokollierung bereits durchgeführter (und somit schon übertragener) Transaktionen und abgelegter Daten sein. Diese sind nicht im Fokus dieses Buches, werden aber in der einschlägigen Literatur beschrieben. Von zentraler Bedeutung ist zudem die Regelung der Authentifizierung, die nicht immer kryptografisch erfolgen muss. Authentifizierung wird üblicherweise pro Dienst und nicht pro Netzwerkschicht umgesetzt. Unzählige Authentifizierungsverfahren existieren, etwa biometrische Authentifizierung (Fingerabdruck, Iris, . . . ), kryptographische (RSAToken, SSH Public Key, . . . ) oder klassisch-organisatorische (verschiedene Formen der Passwortauthentifizierung, etwa One-Time-Passwörter wie S/Key), die ebenfalls auf Kryptografie aufsetzen, siehe Abschn. 3.5. Bedeutsam ist zudem die Art der Autorisierung für die jeweilig verwendeten Dienste. Sie kann über die in vorherigen Kapiteln vorgestellten Ansätze, etwa ACL, RBAC oder MLS, erfolgen.

7 Generell können – und sollten – auch andere Netzwerkschichten Gegenstand des Monitorings sein.

8.5 Absicherung der Anwendungsschicht

261

Abb. 8.3 Grobe Funktionsweise eines Proxyservers

8.5.2

Proxyserver und Co.

Ein Proxyserver leitet Daten stellvertretend für einen Rechner weiter. Für alle wichtigen Dienste der Anwendungsschicht existieren solche Proxyserver. Ein Client baut dabei eine Verbindung mit einem Proxyserver auf und teilt ihm mit, mit welchem Zielsystem dieser Proxyserver eine Verbindung im Auftrag des Clients aufbauen soll. Anschließend erfolgt sämtlicher Datenaustausch über den Proxyserver. Das heißt, Anfragen der Clients werden stellvertretend durch den Proxyserver gestellt und die erhaltenen Antworten an den Client zugestellt (siehe Abb. 8.3). Proxyserver schotten Netzwerkclients von der Außenwelt ab, ermöglichen also einerseits einen eingeschränkteren und kontrollierten Zugriff auf andere Netzwerke/das Internet. Andererseits können Proxyserver besser gehärtet werden, als Clients. Bevor ein Client angegriffen werden kann, muss – je nach Szenario – oftmals erst der Proxyserver angegriffen oder umgangen werden. Ein Proxyserver dient dabei in der Regel vielen Clients gleichzeitig. Entsprechend kann die Installation eines Proxyservers etwa ein Firmennetzwerk schützen und isolieren. Betrachtet werden sollte dabei allerdings auch, dass Proxys eine zentrale Bedeutung für die Kommunikation mit dahinter liegenden Diensten zukommt. Fällt ein Proxy aus, kann dies zur Folge haben, dass keine Kommunikation mit der Außenwelt mehr möglich ist. Außerdem können Proxyserver sensitive Daten, beispielsweise aus URLs, cachen. Somit könnten etwa Passwörter in Logdateien auftauchen.

8.5.2.1 Beispiel SOCKS-Protokoll Exemplarisch8 wird im Folgenden das Proxyserver-Protokoll SOCKS betrachtet. Bereits Anfang der 1990er-Jahre erkannte man, dass eine steigende Anzahl an InternetAnwendungen und zugehörigen Protokollen durch den zunehmenden Einsatz von Firewalls blockiert wurde. Um innerhalb von Netzwerken dennoch eine kontrollierte Möglichkeit zur Kommunikation mit externen Systemen für eigentlich geblockte Protokolle zu bieten, entwickelte man das SOCKS-Protokoll samt zugehörigem Dienst. Die aktuelle SOCKS-Version 5 wird in RFC 1928 beschrieben [11]. Sie bietet als wichtigste Neuerung gegenüber der Vorgängerversion die Möglichkeit einer mehrere 8 Dieser Abschnitt basiert auf meinem Buch Tunnel und verdeckte Kanäle im Netz, Springer-Vieweg, 2012.

262

8 Absicherung der Netzwerkschichten

Verfahren unterstützenden Authentifizierung an. Zusätzlich können in Version 5 DNSNamen auf dem SOCKS-Server aufgelöst werden, bei Version 4 musste dies noch der Client erledigen. Ebenfalls neu sind bei SOCKS5 die Unterstützung für UDP und IPv6. Funktionsweise von SOCKS5 Das SOCKS-Protokoll ist verhältnismäßig einfach gehalten und daher leicht verständlich. Die Kommunikation erfolgt bei SOCKS4 und SOCKS5 auf unterschiedliche Weise und im Folgenden soll die aktuelle SOCKS-Version 5 von 1996 beschrieben werden. Zunächst verbindet sich der SOCKS-Client mit dem SOCKS-Server (dieser wird auch als SOCKS-Proxy oder SOCKS-Service bezeichnet). Der SOCKS-Server läuft standardmäßig auf Port 1080. Nach einem erfolgreichen Verbindungsaufbau sendet der Client Informationen über die von ihm unterstützten Authentifizierungsmaßnahmen (etwa Benutzername und Passwort). Das zugehörige Nachrichtenformat besteht aus drei Teilen. Im ersten Byte ist die SOCKS-Version (also 5) enthalten, im zweiten Byte die Anzahl der unterstützten Methoden. Byte 3 (und optional bis zu 254 folgende Bytes) spezifiziert die unterstützten Authentifizierungsmethoden des Clients (der Wert 0 × 02 steht beispielsweise für die Username/Password-Authentifizierung; dazu gleich mehr). Daraufhin wählt der Server entweder eine der vorgeschlagenen Authentifizierungsmethoden aus oder lehnt diese ab. Das Nachrichtenformat für die Serverantwort ist dabei simpel: Das erste Byte enthält erneut die SOCKS-Version und ein zweites Byte enthält die Authentifizierungsinformation. Typische Werte für eine Serverantwort sind dabei 0 × 00 (keine Authentifizierung notwendig), 0 × 01 (GSSAPI9 ), 0 × 02 Username/Password und 0 × ff (keine der vom Client genannten Authentifizierungsmethoden wird akzeptiert). Weitere Werte (0 × 03 bis 0 × 7f) werden von der IANA vergeben oder (0 × 80 bis 0 × fe) sind für den Privatgebrauch reserviert [11]. Nachdem die Authentifizierung durchgeführt wurde (hierzu können weitere Netzwerkpakete übertragen werden), überträgt der Client die gewünschte Verbindungsanfrage für einen externen Host an den SOCKS-Server (man spricht von einem „Relay Request“ seitens des Clients). Der Relay Request hat dabei folgenden Aufbau [11]: Version || Command || Reserved || Atyp || Destination Address || Destination Port Die ersten vier Felder sind jeweils ein Byte lang, die externe Zieladresse (Destination Address) hat eine variable Länge und der Zielport (Destination Port) ist selbstverständlich – passend zu UDP/TCP – zwei Bytes lang. Nach dem obligatorischen Version-Byte folgt ein Byte, das den SOCKS-Befehl angibt. Dabei sind folgende Befehle möglich:

9 Generic Security Service Application Program Interface, eine Authentifizierungsschnittstelle für

die Softwareentwicklung.

8.5 Absicherung der Anwendungsschicht

263

• CONNECT (0 × 01): Anfrage für den Aufbau einer TCP-Verbindung. • BIND-Befehl (0 × 02): Anfrage für die Akzeptanz einer Verbindung durch ein externes System (etwa für FTP-DATA-Transfer [11]). Nachdem der Verbindungsaufbau seitens des externen Systems stattfand, wird der Client darüber informiert. • UDP ASSOCIATE-Befehl (0 × 03): Wie CONNECT, aber für UDP. Das darauffolgende Byte ist für die zukünftige Protokollerweiterung reserviert. Der Adresstyp legt fest, ob es sich um eine IP-Version-4-Adresse (0 × 01), eine IP-Version6-Adresse (0 × 04) oder einen DNS-Namen (0 × 03) handelt. Abhängig vom gewählten Adresstyp hat das Feld für die Zieladresse eine unterschiedliche Länge. Entweder beträgt die Länge dieses Feldes 4 Bytes (für eine 32 Bit IP-Version-4-Adresse), 16 Bytes (für eine IP-Version-6-Adresse), oder eine im ersten Byte der Zieladresse angegebene variable Länge für den DNS-Namen. Der Zielport gibt (im Falle von CONNECT) den Port an, auf den sich der SOCKS-Server mit dem in der Zieladresse angegebenen externen Host verbinden soll. Im Falle des BIND-Befehls gibt der Zielport den Port an, auf dem der SOCKS-Server eine Verbindung entgegennehmen soll. Nachdem der SOCKS-Server die Verbindungsanfrage erhalten hat, kann er diese entweder durchführen oder ablehnen. Das Nachrichtenformat ist dabei fast dasselbe, wie beim Relay Request: Version || Reply || Reserved || Atyp || Binding Address || Bind Port Neu ist nur das „Reply“-Feld. Der darin enthaltene Wert gibt dem Client Auskunft über den Erfolg seiner zuvor gestellten Anfrage. Dabei sind folgende Werte möglich: • 0 × 00: Erfolgsmeldung (succeeded). • 0 × 01: Ein Fehler des SOCKS-Servers ist aufgetreten (general SOCKS server failure). • 0 × 02: Die Durchführung der gewünschten Verbindungsanfrage ist nicht erlaubt (connection not allowed by ruleset). • 0 × 03: Das Zielnetzwerk ist nicht erreichbar (network unreachable). • 0 × 04: Der Zielhost ist nicht erreichbar (host unreachable). • 0 × 05: Die Verbindung konnte nicht aufgebaut werden, etwa weil der Zielport nicht geöffnet ist (connection refused). • 0 × 06: Die TTL ist abgelaufen (TTL expired). • 0 × 07: Der verlangte Befehl (COMMAND) wird nicht unterstützt (Command not supported). • 0 × 08: Der Adresstyp wird nicht unterstützt; etwa bei einer IPv6-Anfrage in einem IPv4-Netz (Address type not supported). • 0 × 09-0×ff: Nicht verwendet. Bei einem BIND-Befehl werden die Werte Bind-Adresse und Bind-Port gemäß der vorherigen Client-Anfrage gesetzt. Im Falle eines CONNECT-Requests sind Bind-Adresse

264

8 Absicherung der Netzwerkschichten

und Bind-Port die Adressen des externen Hosts, mit dem eine Verbindung aufgebaut werden sollte. UDP-Anfragen gemäß RFC 1928 Da UDP ein verbindungsloses Protokoll ist, muss jedes UDP-Datagram einen RequestHeader beinhalten. Zusätzlicher Bestandteil des Headers ist eine Fragment-ID. (Der Wert 0 × 00 gibt dabei an, dass es sich um ein Paket handelt, das auf keine weiteren Fragmente aufgeteilt ist, bei anderen Werten wird im Bereich von 1 bis 0 × 7f eine Defragmentierung auf dem SOCKS-Server, der dafür einen Cache betreibt, durchgeführt [11]. Das höchstwertige Bit der Fragment-ID gibt an, ob es sich um das letzte Paket einer Fragmentierung handelt. Dem UDP-Request-Header folgt der eigentliche Payload. Socket-Forwarding Generell lässt sich sowohl für SOCKS4 als auch für SOCKS5 sagen, dass nach einem erfolgreichen Verbindungsaufbau des Clients über den SOCKS-Server eine Socketverbindung zwischen Client und SOCKS-Server besteht. In diese Datenverbindung können seitens des Clients protokollunabhängig Daten geschrieben werden. Der SOCKS-Server liest die Daten empfangsseitig aus der Socketverbindung und schreibt diese Daten in die Socketverbindung, die zwischen ihm und dem eigentlichen Ziel der Datenübertragung besteht. Anders formuliert schreibt der SOCKS-Server die Daten an den Empfänger weiter, die vom SOCKS-Client in die Socketverbindung geschrieben werden. Die gesamte Verbindung stellt sich daher analog zum bereits bekannten Prinzip von Proxyservern wie folgt dar: SOCKS-Client ←→ SOCKS-Proxy ←→ Zielhost.

8.5.3

HTTP

HTTP ist eines der am weitesten verbreiteten Protokolle und entsprechend oft im Fokus von Angriffen. Die Härtung eines HTTP-Servers beziehungsweise seiner Kommunikation kann zunächst dadurch erfolgen, dass HTTP-Verbindungen verschlüsselt und authentifiziert übertragen werden. Oftmals müssen hierfür entsprechende Module eingebunden werden, die HTTPS ermöglichen. Eine weitere grundlegende Härtungsmaßnahme ist die Deaktivierung von den Methoden TRACE, CONNECT, PUT und DELETE. Für sensible Daten kann zudem eine Authentifizierung verlangt werden. Ein simples Verfahren hierfür ist .htaccess, allerdings werden die Passwörter hierbei einfach nur kodiert, jedoch nicht verschlüsselt, übertragen und gespeichert. Generell sollte bei der Verwendung von Passwörtern immer überprüft werden, ob diese unverschlüsselt übertragen werden und ggf. ein entsprechendes Modul eingebunden werden. Für serverseitige Skriptsprachen wie PHP existieren zum Teil Sicherheitsmodule oder -erweiterungen, etwa Hardened PHP/Suhosin, das PHP härtet, oder mod_security für Apa-

8.5 Absicherung der Anwendungsschicht

265

che. Serverseitige Skripte (und auch clientseitige Skripte) sind sicherlich das bedeutendste Problem für die Sicherheit von Webservices. Allerdings ist sicheres Programmieren nicht im Fokus dieses Buches. Manche Webseiten prüfen, ob ein Benutzer von einer bestimmten Seite kommt, etwa einer internen Seite. Hierfür kann der Referrer des HTTP-Protokolls verwendet werden. Allerdings ist dieser leicht fälschbar und daher nicht vertrauenswürdig. Die Logdateien eines Webservers können außerdem diverse sensible Daten enthalten und sollten mit entsprechenden Zugriffsrechten gesichert werden. Daher kann auf das Logging von URL-Details verzichtet werden (dies verringert allerdings die Möglichkeiten beim Einsatz eines NIDS und die Diagnosemöglichkeiten bei Fehlern).

8.5.4

DNS

Beim DNS-Protokoll ist der Schutz der Integrität und Authentizität der Anfragen und Antworten essenziell. Vertraulichkeit ist hingegen ein oftmals sekundäres Ziel. DNS-Server sind in der Vergangenheit oftmals das Ziel von DDoS-Angriffen gewesen. Klassischer Weise sollen Managed DNS Provider dabei helfen, durch hoch-dimensionierte Rechenleistung und Netzwerkkapazität adäquat auf DDoS-Angriffe reagieren zu können. Es zeigte sich in den letzten Jahren jedoch mehrfach, dass auch solche Provider nicht dazu in der Lage waren, großvolumige DDoS-Angriffe zu bewältigen. Kunden von Managed DNS-Providern gingen nach Angriffen dazu über, Dienste weiterer Managed DNSProvider in Anspruch zu nehmen, um durch Redundanz für eine höhere Ausfallsicherheit zu sorgen [12]. DNS-Server sind wie alle anderen Dienste zu härten. Das heißt, dass etwa konfiguriert werden sollte, welche Systeme welche Anfragen stellen dürfen und unnötige Funktionen deaktiviert werden sollten. Der in Abschn. 7.5.3 beschriebene Reconnaissance-Angriff, bei dem interne IP-Adressen von einem DNS-Server abgefragt werden, funktioniert beispielsweise nur dann, wenn ein DNS-Server von externen IPs Anfragen zu privaten, internen Resource Records zulässt. Außerdem sollte der Zonentransfer über AXFR, insbesondere von außerhalb und von nicht explizit erlaubten kooperierenden internen DNS-Servern, deaktiviert werden. Alternativ zu AXFR kann ein Zonentransfer, wie in [13] vorgeschlagen, auch über das sichere OpenSSH durchgeführt werden. Werden generell im Rahmen einer Reconnaissance IP-Adressen und Hostnames abgefragt, so wird ein Angreifer vermutlich viele nicht existierende Resource Records anfragen. Eine hohe Anzahl an Anfragen an nicht vorhandene Resource Records von einem Sender während einer vorzugebenden Zeitspanne (etwa 30 Sekunden) kann für die Detektion von Reconnaissance-Angriffen herangezogen werden. Ein früher Ansatz zur Vermeidung von Cache Poisoning bestand in DNS-Cookies, die bereits in Abschn. 7.5.3 erläutert wurden. Dabei werden Off-Path-Angriffe erschwert indem Antworten nur dann akzeptiert werden, wenn der im Header enthaltene Identifier (sowie ggf. UDP-Port) zu einer vorher selbst gestellten Anfrage passt. Früher waren

266

8 Absicherung der Netzwerkschichten

diese Identifier-Werte nicht randomisiert, was jedoch relativ bald geändert wurde, um das Erraten zu erschweren.

8.5.4.1 DNSSec und DNSCurve DNSSec (DNS Security Extensions) ist eine Erweiterung des ursprünglichen RFCStandards. DNSSec kann Resource Records signieren und geht dabei zonenweise vor. Jede Zone erhält einen eigenen asymmetrischen Schlüssel. Der öffentliche Teil des Schlüssels einer Zone wird in einem DNSKEY-Resource-Record abgelegt. Im Resource Record Typ RRSIG können wiederum Signaturen von anderen Resource Records hinterlegt werden. Mithilfe dieser Signaturen gewährleistet DNSSec sowohl die Authentizität als auch die Integrität der übertragenden Daten. Dadurch ist es in der Lage, DNS Cache Poisoning zu verhindern: Der Server sendet neben einem angefragten Resource Record auch dessen Signatur und der Client kann die Signatur wiederum überprüfen. Herzberg und Shulman merken an, dass DNSSec allerdings nicht in der Lage ist, Amplification-Attacken zu verhindern. Rate Limiting, also eine Begrenzung der versendeten DNS-Antworten pro Zeiteinheit, kann hingegen als Mittel zur Vermeidung von Überlast bei DNS-Servern und bei Hosts, deren IP-Adresse vom Angreifer gespooft wurde, dienen [14]. Allerdings führen Herzberg und Shulman an, dass bei einer solchen Lösung auch legitimer Datenverkehr betroffen sein kann, weshalb Rate Limiting pro IP-Adresse durchgeführt werden sollte (diese Methode hilft allerdings nicht, wenn ein Angreifer viele unterschiedliche gespoofte IP-Adressen verwendet) [14]. Ein möglicher Weg seien hingegen Challenge-Response-Verfahren. Ein weiteres Verfahren derselben Forschergruppe nennt sich DNS X-Ray [15]. Dabei handelt es sich um eine freie Software, die es erlaubt, DNS-Server auf ihre Verwundbarkeit hinsichtlich DNS-Spoofing zu untersuchen. Mit DNSCurve besteht eine Alternative zu DNSSEC. DNSCurve verwendet Kryptografie auf Basis sogenannter elliptischer Kurven. Auch können zu übertragende Daten mit DNSCurve – im Gegensatz zu DNSSec – auch verschlüsselt übertragen werden.

8.5.5

E-Mail-Protokolle: SMTP, IMAP und POP3

Das Mailsystem kann sowohl serverseitig, als auch clientseitig abgesichert werden. Clientseitig emfiehlt sich die E-Mail-Verschlüsselung und Signatur. Eingesetzt werden können hierfür insbesondere OpenPGP und S/MIME. Bei OpenPGP handelt es sich um einen Standard, der insbesondere in den Tools PGP (Pretty Good Privacy) beziehungsweise der Open-Source-Variante GPG (GNU Privacy Guard) umgesetzt wird. Der Inhalt einer E-Mail wird mithilfe von asymmetrischen Verfahren (etwa RSA) chiffriert. Jeder Benutzer hat entsprechend einen öffentlichen E-Mail-Schlüssel, den ein Empfänger zum Verschlüsseln einer Nachricht an ihn verwendet. Die Entschlüsselung erfolgt mit dem privaten Schlüssel eines Empfängers. Im Falle einer Signatur verwendet ein Benutzer seinen privaten Schlüssel, um eine Prüfsumme seiner Nachricht zu verschlüsseln. Der

8.5 Absicherung der Anwendungsschicht

267

Empfänger kann die Signatur anschließend mit dem öffentlichen Schlüssel des Senders überprüfen. Bei MIME (Multipurpose Internet Mail Extensions) handelt es sich zunächst um ein Kodierungsformat für E-Mail, das neben Text auch andere Datentypen kodieren kann. Die Mit S/MIME stehen zwei Erweiterungen von MIME bereit, die zur Signatur beziehungsweise Verschlüsselung einer E-Mail dienen. Auch hierbei kommt asymmetrische Kryptografie (insbesondere RSA und SHA-256, aber optional auch DSA, SHA-1 oder MD5 [16]) zum Einsatz. Im Mai 2018 wurden Angriffe bekannt, die unter dem Titel EFAIL geführt werden. Sie zeigten, dass die Standards und die Implementierungen von E-MailClients Spielraum für Angriffe auf die E-Mailverschlüsselung zulassen, unter anderem indem Mailclients durch HTML-Inhalte dazu gebracht werden, entschlüsselte E-Mails an einen Server des Angreifers zu senden, siehe www.efail.de. Diese Art der E-Mail-Verschlüsselung betrifft also den Inhalt einer E-Mail (samt Anhängen). Die Verbindung mit dem Server (samt übertragener Befehle) ist deshalb jedoch noch nicht verschlüsselt. Entsprechend sollte TLS eingesetzt werden, um sicher mit SMTP-, POP3- oder IMAP-Servern zu kommunizieren. Um SPAM zu vermeiden, können SMTP-Server Blacklists beziehungsweise Whitelists verwenden, in denen (nicht) zugelassene Sender-IPs eingetragen werden. In Blacklists können bereits bekannte SPAM-Sender eingetragen werden. Alternativ kann eine solche Liste automatisch befüllt werden, indem solche Systeme dort eingetragen werden, die wiederholt und binnen einer kurzen Zeitspanne versuchen, E-Mails an eine größere Zahl zur eigenen Domain gehörender, aber gar nicht existenter E-Mail-Adressen zu versenden. Alternativ zum White- und Blacklisting empfiehlt sich jedoch eine deutlich komfortablere Variante, das Greylisting. Greylisting nutzt die folgende SMTP-Eigenschaft aus: Sendet ein Client (oder ein anderer SMTP-Server) eine Nachricht an einen SMTP-Server, kann dieser eine Nachricht – etwa aufgrund eines Fehlers – ablehnen. In diesem Fall wird ein ordentlich konfigurierter Sender die Zustellung der Nachricht nach einiger Zeit erneut versuchen, beispielsweise nach einer Stunde. SPAM-Sender verhalten sich jedoch oftmals nicht so und senden eine Nachricht nicht erneut an denselben SMTP-Server. Greylisting sorgt nun dafür, dass eine Nachricht von einem neuen Sender zunächst abgelehnt wird. Nach einer vorgegebenen Zeitspanne werden die eingehenden Mails von diesem Sender jedoch akzeptiert. Eine weitere Methode zur Absicherung eines Maildienstes (sei dieser basierend auf SMTP oder auf einem anderen Protokoll) ist die Integration einer Authentifizierung. Die Anmeldung mit verschlüsseltem Benutzernamen und Passwort ist hierbei die am weitesten verbreitete Methode. Eine Authentifizierung verhindert insbesondere SPAM, da Sender ohne Authentifizierung keine E-Mails versenden können, und Spionage, da IMAP und POP3 das Abrufen von E-Mails nicht ohne Authentifizierung ermöglichen. Ein früher weit verbreitetes Verfahren der E-Mail-Zustellung ist das sogenannte Relaying. Hierbei wird eine E-Mail von einem Mailserver zum nächsten (wie in einer Kette) weitergeleitet. Heute wird direkt der Zielserver angesprochen, sodass üblicherweise nur zwei SMTP-Server involviert sind (SMTP-Server des Senders, etwa mail.domainA.xyz, und des Empfängers, etwa smtp.domainB.xyz).

268

8 Absicherung der Netzwerkschichten

Selbstverständlich können sich Sender und Empfänger auch denselben SMTP-Server teilen, weil sie etwa in derselben Organisation arbeiten. Relaying sollte deaktiviert werden, weil es für SPAM verwendet werden kann. Beispielsweise könnte eine Mail von Relay A vertrauenswürdiger als von einem unbekannten System eingestuft werden, wodurch der SPAM-Level der Nachricht von einer SPAM-Erkennung unterschiedlich bewertet wird. Entsprechend ließe sich ein SMTP-Relay als SPAM-Verteiler missbrauchen. Bestimmte Befehle, insbesondere für SMTP, sollten ebenfalls deaktiviert werden. VRFY (VeRiFY) erlaubt die Überprüfung von Nutzern, somit kann ein Angreifer feststellen, ob ein bestimmter Account existiert. Dies erleichtert das Erraten von Passwörtern, da mit einem gefundenen Benutzer nur ein gültiges Passwort für einen existierenden Benutzer gefunden werden müsste – andernfalls müssten sowohl Benutzername als auch Passwort korrekt erraten werden. Im folgenden Beispiel existiert der Benutzername steffenwendzel. Der Benutzername irgendjemand existiert hingegen nicht. $ t e l n e t l o c a l h o s t 25 Trying 1 2 7 . 0 . 0 . 1 Connected to l o c a l h o s t . Escape c h a r a c t e r i s ’ ^ ] ’ . 220 m a i l . e x a m p l e . o r g ESMTP P o s t f i x ( Ubuntu ) VRFY s t e f f e n w e n d z e l 252 2 . 0 . 0 s t e f f e n w e n d z e l VRFY i r g e n d j e m a n d 550 5 . 1 . 1 < i r g e n d j e m a n d > : R e c i p i e n t a d d r e s s r e j e c t e d : U s e r unknown i n l o c a l r e c i p i e n t t a b l e EXPN (EXPaNd) erlaubt das Auflösen von Adressen, die zu Mailinglisten gehören. Somit können Angreifer ebenfalls Mailaccounts in Erfahrung bringen. Auf den meisten Mailservern sind sowohl VRFY als auch EXPN entsprechend deaktiviert. Für das IMAP-Protokoll ist analog laut RFC 3501 gefordert, dass die Server bei einer fehlgeschlagenen Authentifizierung keine Rückschlüsse auf Benutzernamen zulassen [17]. Ein vernünftiger IMAP-Server hält sich an diese Vorgabe und ein simpler Test mit falscher Anmeldung schafft Klarheit über das Verhalten einer eingesetzten Serversoftware.

8.5.6

NNTP

NNTP kann insbesondere für die Reconnaissance und für Social Engineering eingesetzt werden. Angriffe auf NNTP-Server sind eher unüblich und meist recht einfach gehalten (Erraten von Benutzername und Passwort). Zwar sind NNTP-Server nicht mehr sonderlich weit verbreitet, doch betreiben viele Universitäten noch eigene Server und so manch ein Unternehmen wickelt den Support ihrer Produkte und Dienstleistungen per NNTP ab. Entsprechend bedeutsam ist eine Zugriffskontrolle für NNTP. Ohne diese kann jeder Benutzer alle Postings in allen Newsgroups lesen und sich in jede Kommunikation

8.6 Zusammenfassung

269

einmischen. Es gibt zwei Verfahren zur Authentifizierung: AUTHINFO USER, gefolgt von AUTHINFO PASS (jeweils mit Benutzernamen beziehungsweise Passwort als Parameter) und AUTHINFO SIMPLE (gefolgt von Benutzername und Passwort). Sicher ist keines der beiden Verfahren, da die Daten im Klartext übertragen werden. Es gibt für den NNTP-Server von Windows noch eine Erweiterung, AUTHINFO GENERIC NTLM.10 Es handelt sich dabei um ein Microsoft-eigenes Authentifizierungsprotokoll, dass auf einem Challenge-Response-Verfahren aufsetzt und zumindest in der Vergangenheit für eine Reconnaissance ausgenutzt werden konnte [18]. In jedem Fall empfiehlt sich für NNTP die Aktivierung einer verschlüsselten Verbindung über TLS. Benutzern können auch bei NNTP unterschiedliche Berechtigungen zugewiesen werden, etwa mithilfe der bekannten Access Control Lists (ACL) und Role-based Access Control (RBAC). RBAC bietet hierbei den Vorteil, dass Zugriff nicht benutzer-spezifisch konfiguriert werden muss. Stattdessen können Benutzer zu Gruppen zugewiesen werden, etwa alle Entwickler eines Projekts X einer entsprechenden Gruppe „Projekt X“. Dieser Gruppe kann anschließend Zugriff auf alle gewünschten Newsgroups gegeben werden, was komfortabler und weniger fehleranfällig ist, als jedem Benutzer einzeln sämtliche Zugriffsrechte zu erteilen. Möglich ist auch, sogenannte unsichtbare Newsgroups (invisible newsgroups) zu verwenden. Ein Benutzer bekommt beim Auflisten der Newsgroups in solch einem Fall nur die Newsgroups zu Gesicht, auf die er auch Zugriff hat. Über die Existenz anderer Newsgroups erfährt er zunächst nichts. Dieses Feature ist allerdings nicht perfekt, da NNTP Cross-Postings erlaubt, das heißt, dass ein Posting an mehrere Newsgroups gesendet werden kann. Diese Newsgroups tauchen wiederum allesamt im Header des NNTP-Postings auf und somit können unter Umständen Newsgroups bekannt werden, die einem Benutzer verwehrt sind.

8.6

Zusammenfassung

Die Absicherung von Netzwerken muss schichten- und protokollweise erfolgen. Es gibt zwar generell anwendbare Maßnahmen zur Sicherung eines Netzwerks, etwa eine physikalische Zutrittskontrolle oder das Schaffen von Redundanz, doch sind dies die Ausnahmen. Netzwerksicherheit beginnt bereits beim Erwerb von Hardwarekomponenten und beim Aufsetzen von Diensten. Viele Angriffe basieren darauf, dass Angreifer die Netzwerkidentität (etwa SenderMAC-Adresse oder Sender-IP-Adresse) eines Dritten übernehmen, um sich somit über Beschränkungen hinwegsetzen oder Daten mitlesen zu können, die nicht für sie bestimmt sind. Derlei Angriffe können mit Authentifizierungsverfahren und signierten Adressen erschwert werden. Das Mitlesen von Daten in unverschlüsselten Netzwerken kann durch

10 NT LAN Manager.

270

8 Absicherung der Netzwerkschichten

Verschlüsselung (WPA-2, IPSec, TLS) und das Manipulieren der Daten durch Integritätsschutz (ebenfalls IPSec und TLS) sichergestellt werden. Betriebssysteme bieten in der Regel diverse Einstellungen, die zur Absicherung des Netzwerkstacks dienen. Beispielsweise können nicht benötigte Protokollfunktionen, wie die Annahme von ICMP-Redirect-Nachrichten, deaktiviert werden. Netzwerkscans können mithilfe von Intrusion Detection Systemen erkannt werden. Die Absicherung der Anwendungsschicht ist besonders protokollspezifisch – ein SMTP-Server kann völlig anders angegriffen werden als ein DNS-Server. Dennoch sollte nicht ausschließlich das jeweilige Netzwerkprotokoll, sondern auch der verwendete Netzwerkdienst (etwa Bind oder Apache) abgesichert werden. Zusätzliche Programme (etwa Sicherheitsscanner für Webserver oder Programme zur Verschlüsselung und Signatur von E-Mails wie PGP) können ebenfalls zur Sicherung der Anwendungsschicht verwendet werden.

8.7

Weiterführende Literatur

Viele Bücher konzentrieren sich auf die Absicherung von Netzwerken aus der Sicht eines Administrators. Diese Bücher sind in der Regel spezifisch für eine Plattform verfasst, etwa Juniper- oder Cisco-Router beziehungsweise Windows-Server, Linux-Systeme oder andere. Es empfiehlt sich, diese Bücher genau zu betrachten und die jeweils eingesetzten Plattformen zu härten. Zusätzliches Know-how liefern dienstspezifische Publikationen, etwa zum Apache-Webserver oder zum Bind-Nameserver. Diese gehen in der Regel weitaus detaillierter auf die Härtung eines entsprechenden Dienstes ein, als Bücher, die eine gesamte Plattform abdecken. Aus akademischer Sicht zeichnet sich ein ebenfalls interessantes Bild. Praktisch wöchentlich werden neue, experimentelle Maßnahmen zur Detektion und Abwehr von Angriffen publiziert. Größtenteils sind diese Maßnahmen nur unter Laborbedingungen einsatzbereit, doch gibt es manchmal auch brauchbare und erprobte Module samt Code, etwa für NIDS. Die meisten akademischen Publikationen zu Schutzmaßnahmen sind in der Regel etwas anspruchsvoller, decken dafür allerdings auch den State-of-the-Art ab und liefern Erkenntnisse, die in der Praxis erst in einigen Jahren in Produkte münden. Insofern kann die akademische Literatur auch für Praktiker von Interesse sein.

8.8 1. 2. 3. 4.

Übungsaufgaben

Was verbirgt sich hinter der Abkürzung PAC und wozu dient es? Welche fünf „Ws“ sind bei der Beschaffung von Hardware zu beachten? Wie funktioniert ein MAC-Filter? Was versteht man in der Netzwerktechnik unter einem VLAN? Auf welcher OSISchicht kann es zum Einsatz kommen? 5. Können Switche DoS-Angriffe eindämmen? Falls ja: Wie?

Literatur

6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.

271

Worum handelt es sich bei IEEE 802.1X? Weshalb ist das Verfahren WPA-2 dem Verfahren WEP vorzuziehen? Konfigurieren Sie auf Ihrem Notebook/PC ein NIDS, um Portscans zu detektieren. Welche lokalen Dienste laufen auf Ihrem Computer? Hinweis: Nutzen Sie das Konsolenprogramm netstat, um sich einen Überblick über offene Ports zu verschaffen. Wie funktionieren TCP SYN-Cookies? Aktivieren Sie SYN-Cookies auf Ihrem Computer. Nennen Sie Maßnahmen zur Härtung des IP- und des TCP-Stacks. Wie können DNS- und SMTP-Server gehärtet werden? Welches Ziel verfolgt Rate Limiting bei DNS? Welche Nebenwirkungen bringt Rate Limiting mit sich? Erläutern Sie die Funktionsweise von Greylisting. Was bedeutet es, wenn ein E-Mail-Server Relaying betreibt und weshalb ist Relaying sicherheitsrelevant? Angreifer können eine aktive Reconnaissance über SMTP mithilfe der Befehle VRFY und EXPN durchführen. Erläutern Sie, was diese beiden Befehle bewirken.

Literatur 1. Cutler B., et al.: Dunking the data center. Spect. IEEE 54, 26–31 (2017). IEEE 2. IEEE Spectrum-Redaktion: Cool Runnings. Spectrum IEEE, S. 14–15. IEEE (2017) 3. Guruprasad, A., Pandey, P., Prashant, B.: Security features in ethernet switches for access networks. In: Proceedings of the Conference on Convergent Technologies for the Asia-Pacific Region (TENCON 2003), Bd. 3, S. 1211–1214. IEEE, New York (2003) 4. Arkko, J. (Hrsg.), Kempf, J., Zill, B., Nikander, P.: SEcure Neighbor Discovery (SEND) – RFC 3971. IETF (2005) 5. Aura, T.: Cryptographically Generated Addresses (CGA) – RFC 3972. IETF (2005) 6. Gont, F.: Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery – RFC 6980. IETF (2013) 7. Collins, M.: Network Security Through Data Analysis, 2. Aufl. O’Reilly, Sebastopol (2017) 8. Bernstein, D.J.: SYN cookies (1996). http://cr.yp.to/syncookies.html. Zugegriffen am 01.06.2018 9. Simpson, W.: TCP Cookie Transactions (TCPCT) – RFC 6013. IETF (2011). Anm.: Dieses RFC wurde als „historic“ markiert, da der Ansatz laut RFC 7805 nicht weit verbreitet war und unter anderem durch RFC 7413 ein alternativer Ansatz besteht 10. Cheng, Y., Chu, J., Radhakrishnan, S., Jain, A.: TCP Fast Open – RFC 7413. IETF (2014) 11. Leech, M., Ganis, M., Lee, Y., et al.: SOCKS Protocol Version 5 – RFC 1928. IETF (1996) 12. Abhishta, van Rijswijk-Deij, R., Nieuwenhuis, L.J.M.: Measuring the impact of a successful DDoS attack on the customer behaviour of managed DNS service providers. In: Proceedings ACM SIGCOMM 2018 Workshop on Traffic Measurements for Cybersecurity (WTMC 2018). ACM, New York (2018) 13. Bernstein, D.J.: How to answer TCP queries (Abschnitt „What are zone transfers?“) (2003). https://cr.yp.to/djbdns/tcp.html#intro-axfr. Zugegriffen am 01.06.2018 14. Herzberg, A., Shulman, H.: DNS security: Past, present and future. In: Proceedings of the 9th Future Security – Security Research Conference, S. 524–531. Fraunhofer Verlag, Stuttgart (2014)

272

8 Absicherung der Netzwerkschichten

15. Klein, A., Kravtsov, V., Perlmuter, A., Shulman, H., Waidner, M.: Poster: X-Ray your DNS. In: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security (CCS), S. 2519–2521. ACM, New York (2017) 16. Ramsdell, B., Turner, S.: Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification – RFC 5751. IETF (2010) 17. Crispin, M.: Internet Message Access Protocol – Version 4rev1 – RFC 3501. Network Working Group (2003) 18. Cacak, J. und das Nmap-Projekt: File nntp-ntlm-info (2018). https://github.com/nmap/nmap/ blob/master/scripts/nntp-ntlm-info.nse. Zugegriffen am 01.06.2018

Teil IV Vertiefung

Die bisherigen Kapitel haben Wissen der Netzwerktechnik, IT-Sicherheit, Kryptografie und Netzwerksicherheit vermittelt. Im letzten Abschnitt dieses Buches lernen Sie ausgewählte Vertiefungsthemen kennen. Insbesondere handelt es sich dabei um eine Einführung in die Netzwerkaspekte der Steganografie (insbesondere Covert Channels) und um eine Betrachtung der Sicherheit im Internet der Dinge.

9

Netzwerksteganografie

Covert channel analysis can be viewed either as an arcane aspect of computer security having little to do with ,real‘ security issues or as the key to protecting nominally secure systems against a wide variety of both internal and external threats. – John Mc Hugh (1995).

Zusammenfassung

Dieses Kapitel führt in die Netzwerksteganografie und verdeckte Kanäle ein. Betrachtet werden dabei die grundlegende Terminologie sowie die bekannten Versteckmuster und selektierte Gegenmaßnahmen.

9.1

Einführung

Steganografie ist die Wissenschaft des Versteckens von Nachrichten innerhalb von Objekten beziehungsweise innerhalb von anderen Nachrichten. Steganografie findet bereits bei den Griechen des Altertums Anwendung. So widmet sich Aineas der Taktiker bereits im 4. Jahrhundert v. Chr. dieser Thematik in seinem Werk Von der Vertheidigung der Städte [9]. Techniken zum Verstecken von Nachrichten gibt es zahlreiche. Beispielsweise kann ein geheimer Text in der ersten Spalte eines Textes stehen, wie Abb. 9.1 zeigt, in der die Nachricht „insecure“ eingebettet ist. Die sich mit der Einbettung von Nachrichten in Sprache befassende linguistische Steganografie kann auf beliebige Sprachen angewandt werden und sich dabei auch auf Satzzeichen, White-spaces, aber auch auf Vorkommen von Klein- und Großbuchstaben (beispielhaft in Abb. 9.2 dargestellt), Silben, Redundanzen und sonstige sprachliche Merkmale konzentrieren. Auch für arabische und asiatische Sprachen sind steganografische © Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2018 S. Wendzel, IT-Sicherheit für TCP/IP- und IoT-Netzwerke, https://doi.org/10.1007/978-3-658-22603-9_9

275

276

9 Netzwerksteganografie Ich möchte diese Diskussion nicht auf die Spitze treiben. natürlich nicht. Doch sollte auch bedacht werden, dass sicherlich nicht jeder Teilnehmer des Kongresses einen erheblichen Anteil der BürgerInnen hinter sich weiß! Cuxhaven ist mehr, als nur eine Stadt! Es ist vielmehr unsere Stadt – im Wahlfieber! Wählen Sie Rolf Muster v. Regenstadt zum Bürgermeister! Mit ihm an der Spitze geht es wieder aufwärts!

Abb. 9.1 Eine simple Form der linguistischen Steganografie In den letzten Monaten konnten wir durch Herrn Regenstadt viele Erfolge hinsichtlich der Gesamtziele verbuchen, die wir uns definierten. Es ist nun an mir, noch einmal an die Notwendigkeit derselben zu erinnern.

Abb. 9.2 Eine weitere Form der linguistischen Steganografie, bei der Großbuchstaben die geheime Nachricht „IM REGEN“ kodieren

Techniken bekannt. Zudem sind die Möglichkeiten der Kodierung vielseitig. Somit ist einem Gegenspieler nicht bekannt, ob ein bestimmter Buchstabe für sich selbst, für ein Bit, für ein Morse-Symbol oder für eine ganz andere Kodierung steht. Steganografische Nachrichten können allerdings nicht nur in Text, sondern auch in digitale Bilder, Audiodateien, Videos, Audio- und Videostreams eingebettet werden, ja sogar in ungenutzte Bereiche von Dateisystemen. Das „Versteck“, in dem die steganografischen Daten untergebracht sind, nennt sich Cover Object.

Exkurs: Adressat Unbekannt Die Briefnovelle Adressat Unbekannt spielt in den 1930er-Jahren. Auf weniger als 100 Seiten stellt das Buch von Kressman Taylor (im Original Address Unknown) eine Konversation per Post zwischen zwei Personen aus den USA und Deutschland dar. Der sich zuspitzende Konflikt zwischen den einstigen Freunden, von denen einer Jude und der andere Hitler-Anhänger wird, beinhaltet auch den vermeintlichen Einsatz von Steganografie. Dieser vermeintliche Einsatz führt gewissermaßen zum Finale des Buchs. Ich empfehle dieses spannende und zugleich politisch interessante Werk wärmstens.

Exkurs: Die vielen Leben des Jan Six Mit dem Buch Die vielen Leben des Jan Six legt der Autor Geert Mak die Geschichte einer Amsterdamer Dynastie vor. Im Buch kommt unter anderem zur Sprache, dass (Fortsetzung)

9.1 Einführung

277

an einem Haus an der Herengracht der Spruch salvs pax hvic domvi (dt. Heil und Friede diesem Haus) angebracht wurde. Bei genauerer Betrachtung zeigen sich Buchstaben, die das Baujahr des Gebäudes verraten (saLVs paX hVIC DoMVI). Auch diess ist eine, wenn auch simple, Unterform der Steganografie.

Die Netzwerksteganografie ist nun wiederum diejenige Disziplin, die die Steganografie auf Netzwerkdaten anwendet [16]; sie kümmert sich darum, dass übertragene Daten legitim erscheinen, obwohl darin versteckte Botschaften enthalten sind. Definition 9.1. Ein verdeckter Kanal (engl. Covert Channel) ist ein nicht in einem System vorgesehener Kommunikationskanal [12], der eine Sicherheitsrichtlinie bricht [3]. Definition 9.2. Ein Seitenkanal (engl. Side Channel) ist ein verdeckter Kanal, der ohne Intention sendet [25]. Ein Beispiel für einen Seitenkanal ist etwa ein kryptografischer Algorithmus, der eine längere Laufzeit benötigt, wenn das erste Bit eines verwendeten Schlüssels 1 ist. Die Messung der Laufzeit des Algorithmus gibt einem Beobachter den Bitwert. Die Möglichkeit dieser Informationsübertragung wurde vom Entwickler des kryptografischen Algorithmus sehr wahrscheinlich nicht vorgesehen, womit der verdeckte Kanal ein Seitenkanal ist. In Netzwerken wird ein verdeckter Kanal von netzwerksteganografischen Methoden erzeugt [16]. Deartige Methoden betten steganografische Nachrichten in ein Cover Object ein (etwa ein UDP-Paket), das zum Empfänger übertragen wird. Die innerhalb des Cover Objects stattfindende verdeckte Kommunikation stellt den verdeckten Kanal dar. Auch Seitenkanäle gibt es in Netzwerken; beispielsweise können Angreifer die Dauer messen, die ein Server zur Beantwortung von Anfragen benötigt. Damit lassen sich unter Umständen Rückschlüsse auf sensible Daten ziehen [4]. Anwendung findet die Netzwerksteganografie etwa bei der Kommunikation von Botnetzen (C&C-Channel) und bei der Exfiltration vertrauenswürdiger Daten [38]. Es gibt auch positive Anwendungsfelder, die immer wieder genannt werden, wie die geheime Kommunikation von Journalisten, die mithilfe der Steganografie Internetzensur umgehen möchten. Die gutartige Verwendung der Steganografie ist allerdings aufgrund verschiedener, in [27] aufgeführter Gründe (etwa geringer Bekanntheit der Steganografie und technische Herausforderungen) schwierig. Leider sind keine Zahlen zu den gutartigen Fällen und kaum Zahlen zu den bösartigen Anwendungsfällen der Steganografie bekannt. Allerdings versucht die CUING-Initiative (www.cuing.org, siehe auch [15]) seit einigen Jahren, die Entwicklungen der kriminellen Nutzung von Steganografie zu protokollieren und analysieren. Tendenziell steigt dabei die Anzahl der Fälle, in denen (Netzwerk-)Steganografie für kriminelle Zwecke angewandt wurde.

278

9 Netzwerksteganografie

Ein weiteres bekanntes Anwendungsfeld ist die Überwachung von Smartphones. Hierfür kommt Spähsoftware wie etwa FinFisher von Gamma International zum Einsatz, dessen Ausführung Fin-Spy Mobile eine Live-Überwachung von SMS- und MMSNachrichten, E-Mails, Anrufen, Aufenthaltsort und Blackberry-Nachrichten ermöglicht. Diese Daten werden per verdeckter Kommunikation an ein „Master“-System gemeldet [35].

9.2

Methoden der Netzwerksteganografie

Die ersten Publikationen zur Netzwerksteganografie reichen zurück in die späten 80erJahre des vergangenen Jahrhunderts [15, 16]. Girling und Wolf präsentieren damals die ersten Verfahren, mit denen in lokalen Netzwerken unbemerkt Daten über verdeckte Kanäle übertragen werden können. Dies geschah etwa 15 Jahre, bevor man begann, den Begriff Netzwerksteganografie überhaupt zu verwenden. Auch in der heutigen Forschung und in diesem Kapitel ist der zentrale Begriff für versteckte Übertragungen im Netzwerk noch der oben eingeführte verdeckte Kanal. An dieser Stelle sei erwähnt, dass eine einheitliche Beschreibungsmethodik für verdeckte Kanäle in Netzwerken existiert [33].

9.2.1

Grundlegende Taxonomie

Die frühen Autoren stellten zwei grundverschiedene Ansätze vor, nämlich zeit- und speicherbasierte Kommunikation. Neben der Unterscheidung in zeit- und speicherbasierte Kanäle existieren weitere Unterscheidungsmerkmale für verdeckte Kanäle, etwa zwischen passiven und aktiven, sowie zwischen rauschenden und rauschfreien; außerdem wird zwischen aktiven und passiven verdeckten Kanälen unterschieden [25]. Für das vorliegende Kapitel ist allerdings insbesondere die erstgenannte Unterscheidung wichtig. Zeitbasierte verdeckte Kanäle nennen sich auch Timing Channels oder schlicht Zeitkanäle und speicherbasierte werden als Storage Channels (Speicherkanäle) bezeichnet. Timing Channels signalisieren Daten durch die Manipulation zeitlicher Abfolgen von Netzwerkevents. Dies geschieht zum Beispiel dadurch, dass sie die Intervallzeiten zwischen Netzwerkpaketen modulieren, um dadurch unterschiedliche Symbole (die Elementareinheit geheimer Informationen, wie etwa Striche und Punkte bei MorseNachrichten oder die Buchstaben des Alphabets für deutsche Texte) übertragen zu können. Beispielsweise könnte eine Intervallzeit von 0,1 s für ein 1er-Bit und eine Intervallzeit von 0.2 s für ein 0er-Bit stehen. Speicherbasierte Kanäle sind hingegen solche, die verdeckte Daten in Speicherbereichen zu übertragender Pakete (beziehungsweise Frames, Datagramme oder Segmente) unterbringen. So kann etwa ein ungenutztes Bit im IPv4-Header mit einer 0 oder einer 1 versehen werden.

9.2 Methoden der Netzwerksteganografie

279

Während Storage Channels immer von einem bestimmten Netzwerkprotokoll abhängen, sieht dies bei Timing Channels anders aus. 2016 führten wir deshalb in [16] eine neue Taxonomie für dieselben ein, bei der zwei Untergruppen für Timing Channels definiert wurden – protkollspezifische (engl. protocol-aware) und protokollunabhängige (engl. protocol-agnostic). Protokollunabhängig können etwa Durchsatz von und Intervallzeiten zwischen Paketen umgesetzt werden – es ist schließlich egal, ob ein TCP- oder UDPPaket für mehr Datendurchsatz sorgt, solange dieser Durchsatz irgendwie die verdeckte Nachricht kodieren kann. Die andere Kategorie von Timing Channels arbeitet hingegen mit der Reihenfolge von Nachrichten, etwa der Reihenfolge, in der TCP-Segmente versendet werden, oder anderen Ansätzen, die protokollspezifisch realisiert werden müssen. Doch auch für Storage Channels gibt es eine weitere Unterteilung: Sie können entweder Nutzdaten modifizieren (z. B. HTML-Inhalte, die in einer HTTP-Antwort enthalten sind) oder das Protokoll an sich (Metadaten/Header) [32]. Für das vorliegende Buch sind insbesondere Modifikationen der Protokollmetadaten interessant, da sie spezifisch für Netzwerksteganografie sind. Metadaten von Protokollen können wiederum so modifiziert werden, dass sich die Struktur der Daten ändert oder so, dass die Struktur erhalten bleibt [32]. Diese Varianten werden structure-modifying beziehungsweise structure-preserving genannt.

9.2.2

Versteckmuster

Alle verdeckten Kanäle können Versteckmustern (engl. Hiding Patterns) zugeordnet werden, die in [32] eingeführt und in [16] leicht weiterentwickelt wurden. Es existieren hunderte von Techniken zur Erzeugung von verdeckten Kanälen in Netzwerken. Einer der Vorteile von Hiding Patterns ist der, dass von diesen Einzeltechniken und von spezifischen Protokollen abstrahiert wird. Hiding Patterns lassen sich leichter verstehen und vermitteln, weil sie die Kernideen von Verstecktechniken darstellen. Praktischerweise sind etwa 70 % aller Verstecktechniken mit nur vier Hiding Patterns beschreibbar, da sich die Ideen vieler Autoren im Laufe der Zeit äußerst ähnlich waren [32, 33]. Insgesamt gibt es derzeit 14 uns bekannte Patterns, wobei ihre Anzahl zunehmen kann, wenn neue Patterns entdeckt werden. Die bisher bekannten Patterns werden analog zu Abb. 9.3 besprochen. Das heißt, es werden erst Timing Channel Patterns (zunächst protocol-aware, dann protocol-agnostic) und anschließend Storage Channel Patterns (structure-modifying und schließlich structure-preserving) erläutert. Die Beschreibung ist prägnant gehalten, sodass die wichtigsten Aspekte der jeweiligen Patterns deutlich werden. Eine ausführliche Darstellung der Patterns findet sich in [16, 32].

9.2.2.1 Timing Channel Patterns Es existieren drei bekannte Hiding Patterns für Timing Channels, die protocol-agnostic sind:

280

9 Netzwerksteganografie

Abb. 9.3 Die grundlegende Taxonomie für verdeckte Kanäle, die in [32] vorgeschlagen und durch [16] erweitert wurde

1. Rate/Throughput: Hierbei wird Datenverkehr zwischen Sender und Empfänger mit einer unterschiedlichen Datenrate übertragen. Verschiedene Datenraten kodieren unterschiedliche geheime Symbole. 2. Interpacket Times: Bei diesem Pattern signalisieren unterschiedlich lange Intervallzeiten zwischen zwei aufeinanderfolgenden Netzwerkpaketen die geheimen Symbole. Die Intervallzeiten werden auch als Inter-arrival Times (IAT) oder Inter-packet Gaps (IPG) bezeichnet. 3. Message Timing (auch Message Sequence Timing): Die zeitliche Abfolge von Nachrichten kann protokollunabhängig manipuliert werden. Dieses Pattern signalisiert durch derlei Manipulationen verdeckte Daten. Zum Beispiel kann eine Antwort eines Servers künstlich verzögert werden (oder nicht), um verschiedene geheime Bits zu signalisieren. Weiterhin gibt es fünf Timing Channel Patterns, die protocol-aware sind: 1. Artificial Loss: Protokolle, in denen Pakete Reihenfolgen aufweisen, etwa Sequenznummern für TCP-Segmente, können so manipuliert werden, dass ein künstlicher Paketverlust vorgetäuscht wird. Die Tatsache, ob ein Paket in einer Liste von empfangenen Paketen fehlt, kodiert das geheime Symbol. 2. Retransmission: Alternativ kann ein Sender Pakete auch mehrfach senden, was aber nur dann möglich ist, wenn ein Protokoll das Mehrfachsenden unterstützt. Die Reliabilität von TCP ist hierfür ein klassisches Beispiel: Wenn die Logik von TCP entscheidet, dass ein Segment verlorenging (da eine Empfangsbestätigung ausblieb), dann wird dieses Segment erneut gesendet. Ein verdeckter Kanal kann sich derartiges Verhalten zu Nutze machen und selbst für das erneute Versenden von Paketen sorgen. 3. Message Ordering: Manche Protokolle – auch hier ließe sich wieder TCP anführen – kennzeichnen zu übertragende Pakete (Segmente) mit einer Nummer. Pakete können in der korrekten oder einer manipulierten Reihenfolge versendet werden, wodurch der Empfänger im Fall dieses Patterns ein unterschiedliches geheimes Symbol erhält.

9.2 Methoden der Netzwerksteganografie

281

4. Frame Collissions: Moderne Netzwerkschnittstellen sind in der Lage, Kollisionen von Frames zu erkennen. Ein Angreifer kann eine solche Kollision künstlich hervorrufen; selbstverständlich kann auch hierdurch verdeckt signalisiert werden. 5. Temperature: Ein Spezialfall der verdeckten Kanäle sind solche, die auf der Beeinflussung einer messbaren Temperatur basieren. Ein Sender muss die Temperatur einer dem Empfänger zugänglichen Einheit beeinflussen, damit dieser selbige auslesen kann – sei es direkt oder indirekt. Der Temperaturwert kodiert das geheime Symbol. Das einzige bekannte Verfahren hierbei benötigt einen zwischengeschalteten Host, den Sender und Empfänger ausnutzen, und funktioniert auf indirekte Weise; außerdem benötigt er ein Protokoll, das möglichst genaue Zeitstempel verwendet [16]. Der Empfänger beeinflusst durch die Anzahl seiner an den zwischengeschalteten Host gestellten Anfragen die Temperatur auf selbigem. Die Temperatur beeinflusst wiederum den Taktversatz (engl. clock skew) auf diesem System, der indirekt über Zeitstempel durch den Empfänger (dieser fragt ebenfalls den zwischengeschalteten Host ab) festgestellt werden kann und letztlich einen Rückschluss auf die Temperatur (und damit das geheime Symbol) ermöglicht. Die Übertragungsrate für einen solchen Kanal ist bisher sehr gering.

9.2.2.2 Storage Channel Patterns Es existieren drei bekannte Storage Channel Patterns, die als structure-modifying zu kategorisieren sind: 1. Size Modulation: Die Größe von Paketen wird (durch Hinzufügen/Entfernen optionaler Headerelemente) moduliert und repräsentiert das geheime Symbol. 2. Sequence Modulation: Die Reihenfolge von Headerelementen/Protokollbefehlen wird moduliert; beispielsweise kann beim SMTP-Protokoll zuerst der Befehl NOOP gefolgt von MAIL FROM gesendet werden – oder andersherum. 3. Add Redundancy: Bei diesem Pattern fügt der Sender redundante Datenbereiche innerhalb eines Pakets beziehungsweise innerhalb eines Headerelements hinzu. Beispielsweise kann der IPv4-Header um Optionsheader erweitert werden, wodurch ein Mehr an – allerdings nicht zu verarbeitender und inhaltlich nicht relevanter – Information vorliegt. Im Gegensatz zum Pattern Size Modulation wird nicht die Größe eines Pakets, sondern das Vorhandensein redundanter Daten geprüft. Weiterhin sind drei Storage Channel Patterns bekannt, die als structure-preserving zu kategorisieren sind: 1. Random Value: Diverse Protokolle besitzen Felder, die (Pseudo-)Zufallswerte beinhalten, etwa die ISN von TCP. Ein verdeckter Kanal kann diese Werte durch geheime Symbole ersetzen.

282

9 Netzwerksteganografie

2. Reserved/Unused: Fast jedes Protokoll beinhaltet unbenutzte beziehungsweise als „für die zukünftige Nutzung reserviert“ beschriebene Elemente. Diese können verwendet werden, um geheime Symbole darin unterzubringen. 3. Value Modulation: Bei diesem Pattern werden zugelassene Werte eines Headerelements verwendet, um geheime Symbole zu kodieren. Im Gegensatz zum Pattern Random Value stellen diese Werte allerdings keinen Zufallswert dar und im Gegensatz zum Pattern Reserved/Unused handelt es sich nicht um reservierte oder unbenutzte Elemente. Stattdessen muss ein Sender für jedes Paket einen aus n erlaubten Werten für ein Headerelement selektieren, während bestimmte andere Werte aus beliebigen Gründen nicht erlaubt sind. Ein solcher Grund könnte etwa sein, dass eine ProtokollSpezifikation verletzt würde, wenn ein bestimmter Wert gesetzt wird. Zum Beispiel sind IPv4-Pakete mit gesetzten „reserved“-Bit nicht protokollkonform. Ein Beispiel für eine Value Modulation sind ICMP-Nachrichten, bei denen das Type-Feld ausgewertet wird. Da nur bestimmte ICMP-Typen (und ihre zugehörigen Werte) definiert sind, können nur diese verwendet werden.

9.2.3

Spezifische Versteckmethoden

Verdeckte Kanäle gibt es für eine Vielzahl von Netzwerkprotokollen, prinzipiell sogar für alle praktisch verwendbaren Protokolle. In den vergangenen Jahrzehnten wurden diverse Kanäle für Protokolle sämtlicher Schichten des TCP/IP-Modells gezeigt, darunter Standardprotokolle wie IPv4 [1], TCP [18], IPv6 [13] sowie VoIP-Protokolle [14] und IPSec [8]. Einen Überblick über die Vielzahl der einzelnen Techniken bieten unter anderem [38] und [32] (Letztere ordnet die Verstecktechniken den oben eingeführten Patterns zu). Neben den grundlegenden Patterns gibt es noch Hybridmethoden [16]. Hybridmethoden manipulieren sowohl das zeitliche Verhalten von Datenübertragungen, wie auch Speicherbereiche. Hybride Methoden kombinieren im Wesentlichen mehrere vorhandene Patterns zu einer umfassenderen Verstecktechnik. Beispielsweise kann ein Sender gleichzeitig einen Zeitkanal durch Manipulation der Intervallzeiten zwischen Paketen umsetzen und die in den Paketen eingebetteten reservierten Bits von Headerelementen für verdeckte Symbole nutzen. Wenn mehrere Patterns miteinander kombiniert werden – unabhängig davon, ob sie, wie bei Hybridmethoden explizit Storage- und Timing-Patterns verwenden, liegt eine Pattern Combination vor [32]. Ein Fall von Pattern Combination kann beispielsweise auch die Patterns Reserved/Unused mit Size Modulation kombinieren. Ein weiterer Ansatz besteht darin, Patterns abzuwechseln und nennt sich Pattern Hopping [32]. Dabei wird für jedes neu zu übertragende Fragment der geheimen Nachricht ein Pattern ausgewählt, mithilfe dessen das Fragment übertragen soll. Für jedes neue Fragment kann sich folglich auch das verwendete Pattern ändern. Die Idee basiert auf Protocol Hopping Covert Channels, die verschiedene Versteckmethoden für jedes neue

9.2 Methoden der Netzwerksteganografie

283

Fragment wählen können, dabei allerdings nicht patternbasiert vorgehen [28]. Wird einer der bei Pattern Hopping oder Protocol Hopping Covert Channels verwendeten verdeckten Kanäle detektiert, so bleiben die anderen Kanäle nach wie vor unentdeckt. Selbiges gilt für den Fall, dass einer der verdeckten Kanäle blockiert wird; die anderen Kanäle funktionieren nach wie vor [28]. Eine ähnliche Idee zu Protocol Hopping Covert Channels stellen sogenannte Protocol Switching Covert Channels, auch Protocol Channels genannt, dar. Sie kodieren eine verdeckte Nachricht durch Netzwerkprotokolle [29]. Zum Beispiel kann das ICMP-Protokoll ein geheimes 1er-Bit symbolisieren, während ein UDP-Paket ein 0er-Bit symbolisiert. Wird dann beispielsweise ein UDP-Paket, gefolgt von zwei ICMP-Paketen übertragen, so entspräche das der geheimen Nachricht „011“. Yarochkin et al. haben einen adaptiven verdeckten Kanal vorgestellt [37]. Dabei prüfen Sender und Empfänger, welche Protokolle für eine verdeckte Kommunikation verwendet werden können, um in diesen Protokollen Daten zu verstecken. Außerdem prüfen sie, welche Protokolle aktuell geblockt werden. Da sich Firewallkonfigurationen und Routen von Paketen dynamisch ändern können, teilten die Autoren ihren Ansatz in zwei Phasen ein. In der Network Environment Learning Phase (NEL Phase) probieren Sender und Empfänger permanent, sich mit bestimmten Protokollen zu erreichen. Die Erfolgs- und Misserfolgsfälle werden kontinuierlich protokolliert, da die NEL Phase permanent abläuft. In der Communication Phase (COM Phase) werden die geheimen Symbole über die durch die NEL Phase als nutzbar erkannten Protokolle übertragen. Ein solches System kann hervorragend auf veränderte Umgebungen reagieren. Eine verbesserte Variante des Verfahrens von Yarochkin et al. wird in [26] erläutert. Wie sämtliche legitime Datenübertragungen, so können auch verdeckte Kanäle interne Protokolle (auch Mikroprotokolle genannt) verwenden [28]. Mikroprotokolle bieten umfassende Möglichkeiten; dazu zählen etwa dynamisches Routing, das Initiieren von Protokollwechseln für das Protokoll/Pattern Hopping und das Signalisieren von Start und Ende einer Übertragung sowie simple Maßnahmen zur Fehlererkennung und -korrektur wie Paritätsbits [16, 28].1 Verdeckte Kanäle existieren zudem nicht ausschließlich in klassischen Netzwerkprotokollen, sondern beispielsweise auch in Cloudumgebungen. 2017 stellten Spiekermann et al. einzelne Storage Channels für die Virtualisierungsprotokolle VXLAN, STT, GENEVE und NVGRE vor. Dabei konnten pro Protokollheader 37 Bits (VXLAN), 18 Bits (NVGRE), 80+Bits (STT) und 18−142 Bits (GENEVE) platziert werden. Während dabei die bekannten Patterns zum Einsatz kamen, zeigten die Autoren allerdings auch einen interessanten Timing Channel: Durch Migration von virtuellen Maschinen an andere Rechenzentren auf der Welt verändert sich die Round Trip Time (RTT) zu diesen virtuellen Maschinen. Wenn nun schnell migriert wird, so kann die RTT verwendet werden, um verdeckte Informationen zu signalisieren [21].

1 Fehlererkennung und -korrektur sind auch Gegenstand von Steganografie, die nicht im Netzwerk stattfindet. Siehe dazu etwa Keller und Magauer [11].

284

9 Netzwerksteganografie

Weitere Ansätze existieren für die verdeckte Datenübertragung in Mobilfunknetzen. Zhang et al. konnten zeigen, dass für Sprachübertragung über LTE (Voice over LTE, VoLTE) verdeckt signalisiert werden kann, indem geräuschlose Übertragungszeiten, in denen kein Beteiligter spricht, leicht verzögert beziehungsweise verlängert werden [39]. Xu et al. konnten zudem verdeckte Kanäle für LTE Advanced (LTE-A) umsetzen [36]. Auch sind verdeckte Kanäle für GSM bekannt [17]. In den vergangenen Jahren konnten erste Arbeiten zudem zeigen, dass Netzwerksteganografie auch in automatisierten Umgebungen beziehungsweise dem Internet der Dinge (IoT) umgesetzt werden können. In diesen Szenarien können verdeckt Daten über IoTNetzwerke übertragen oder IoT-Geräte ausgenutzt werden, um auf ihnen steganografische Symbole zu hinterlegen [34]. In diesem noch sehr jungen Gebiet existieren allerdings recht wenige Arbeiten, unter anderem wird das Thema zum Teil in einer Publikation von Tonejc et al. [23] und in einer Publikation von Tuptuk und Hailes [24] aufgegriffen, sowie in den Publikationen des Autors, insbesondere [34] (Speicherung von geheimen Daten im IoT) und [31] (damals erster Ansatz für verdeckte Kanäle in Automationsumgebungen). Ein weiterer Forschungstrend besteht in Air-gapped oder Out-of-band Covert Channels [2], das heißt in verdeckten Kanälen, die zwischen physikalisch separierten Systemen Daten übertragen können. Dazu kann etwa nicht hörbarer Schall oder Licht als Netzwerkmedium dienen. Hanspach und Götz zeigten, wie sich mit verdeckten akustischen Kanälen Mesh-Netzwerke realisieren lassen [6, 7]. Dass verdeckte akustische Kommunikation auch ohne Lautsprecher funktionieren kann, zeigen Guri et al. in [5] durch Nutzung von Ventilatoren, die eigentlich zur CPU- und Gehäusekühlung dienen.

9.3

Gegenmaßnahmen zur Netzwerksteganografie

Gegenmaßnahmen werden im Kontext der Steganografie als Wardens bezeichnet. Sie können passiv sein (Passive Warden) oder aktiv sein (Active Warden). Active Wardens können zudem sogar bösartig agieren und nennen sich dann Malicious Wardens. Diesen Bezeichnungen liegt das sogenannte Prisoner’s Problem (Abb. 9.4) zugrunde, bei dem Alice und Bob in separaten Zellen untergebracht werden und nur über einen Wärter (engl. Warden) Nachrichten austauschen können. Trotz dieser widrigen Umstände wollen Alice und Bob einen Ausbruchsversuch planen, indem sie mithilfe von Steganografie geheime Nachrichten vom Warden übertragen lassen, ohne, dass dieser von der geheimen Kommunikation erfährt. Dieses Prisoner’s Problem geht auf Simmons zurück und wurde 1983 vorgestellt [19]. Gegenmaßnahmen können verschiedene Ziele verfolgen. Zander et al. [38] teilten Gegenmaßnahmen in solche ein, die

9.3 Gegenmaßnahmen zur Netzwerksteganografie

285

Abb. 9.4 Prisoner’s Problem. Die Aufgabe des Wardens ist es, geheime Nachrichten zu detektieren oder zu entfernen. Nicht dargestellt ist, dass der Warden auch eigene Nachrichten an Bob schicken und sich dabei als Alice ausgeben kann (Malicious Warden). Bob kann daher niemals sicher sein, ob eine Nachricht von Alice ihn erreicht und ob eine geheime Nachricht tatsächlich von Alice stammt

• ein Audit eines verdeckten Kanals vornehmen (dies schafft Bewusstsein über die potenzielle Existenz sowie Rahmenbedingungen eines verdeckten Kanals), • eine Detektion des verdeckten Kanals vornehmen (dies schafft Bewusstsein über die aktuelle beziehungsweise in der Vergangenheit liegende Präsenz eines verdeckten Kanals), • eine Limitierung des verdeckten Kanals vornehmen (das heißt, die Kanalkapazität des Kanals zu reduzieren) oder • versuchen, den verdeckten Kanal zu unterbinden (das heißt, die Existenz des Kanals unmöglich zu machen). Diese Kategorisierung wurde in [16] beibehalten. Bei Limitierung und Unterbindung verdeckter Kanäle handelt es sich um aktive (das heißt in den Datenverkehr eingreifende) Maßnahmen, also Active Wardens. Die Detektion ist hingegen eine passive (den Datenverkehr beobachtende und beurteilende) Maßnahme (Passive Wardens). Gegenmaßnahmen haben jeweils unterschiedliche Nebenwirkungen auf den Netzwerkverkehr (siehe [25] für eine detaillierte Analyse). So kann eine aktive Maßnahme beispielsweise Funktionalitäten eines Netzwerkprotokolls verringern. Angenommen, ein Element eines Protokollheaders kann verwendet werden, um darin versteckte Daten zu platzieren. Wenn eine Gegenmaßnahme dieses Element mit dem Wert Null überschreibt, ist es nicht mehr möglich, über dieses Element verdeckt zu kommunizieren. Gleichzeitig wird die eigentliche Protokollfunktionalität, die durch das Element signalisiert wird, unnutzbar. Eine passive Maßnahme kann hingegen zu falschen Detektionsresultaten führen. In solchen Fällen kann legitimer Datenverkehr etwa als verdeckt erkannt werden (und vice versa). Anders formuliert sind die False-Positive- und False-Negative-Raten eines Detektionsverfahrens in aller Regel nicht perfekt. Außerdem können viele Kanäle nicht sofort erkannt werden, sondern beispielsweise nur leicht zeitverzögert. Oftmals müssen mehrere Tausend Datenpakete

286

9 Netzwerksteganografie

ausgewertet werden, damit ein Detektionsalgorithmus überhaupt derart auf diesen Daten arbeiten kann, dass qualitativ brauchbare Resultate erzielt werden können. Kanäle, die mit geringer Datenrate senden, sind in der Regel schwieriger zu detektieren als solche, die mit einer höheren Datenrate senden. Dies lässt sich an einem Beispiel plausibel machen. Wenn etwa für die Inter-arrival Time die Intervallzeiten zwischen jedem Datenpaket ausgenutzt werden (Muster: Interpacket Times) und 50 Pakete pro Sekunde übertragen werden, dann ist innerhalb eines zu analysierenden Datenfensters (beispielsweise 2,000 Pakete) viel verdeckte Kommunikation enthalten, die zu entsprechenden Anomalien führen kann, da sie die statistischen Eigenschaften des Datenfensters beeinflussen kann. Wenn hingegen nur 1 aus 50 Paketen pro Sekunde verwendet wird, um durch eine manipulierte Inter-arrival Time Daten zu signalisieren, so ist die statistische Auswirkung jedes fünfzigsten Pakets auf das Datenfenster deutlich geringer. Je geringer die Datenrate gegenüber der Kanalkapazität eines verdeckten Kanals ist, umso schwieriger ist also die Detektion; anders formuliert steigt mit geringerer Ausnutzung der Kanalkapazität die Verdecktheit (engl. Covertness) an. Während [16,25] und [38] jeweils ausführlich und aus verschiedenen Blickwinkeln auf, teils unterschiedliche, Gegenmaßnahmen eingehen, soll dieses Kapitel einige besonders wichtige Gegenmaßnahmen erläutern.

9.3.1

Detektion

Für die Detektion von verdeckten Kanälen ist es essenziell, nützliche Metriken (beziehungsweise Features) zu wählen. Beispielsweise können die Anzahl von Paketen pro Sekunde, die Größe von einzelnen Netzwerkpaketen, die Anzahl unterschiedlicher Protokolle pro Sekunde, das Vorhandensein eines bestimmten gesetzten Bits in einem Protokollheader oder sonstige Werte einbezogen werden. Genauso können die Varianz, Standardabweichung oder Mittelwerte solcher Werte interessant sein. Für verdeckte Kanäle kann, wie bei NIDS (siehe Abschn. 6.3.2), ein signaturbasiertes, ein anomaliebasiertes Vorgehen oder ein spezifikationsbasiertes Detektionsverfahren umgesetzt werden. Ein simples spezifikationsbasiertes Verfahren könnte etwa darin bestehen, alle IPv4-Pakete dahingehend zu untersuchen, ob das „Reserved“-Bit gesetzt ist. Ist dem so, könnte ein verdeckter Kanal als detektiert gelten. Natürlich könnte es auch einen anderen Grund geben, weshalb dieses Bit gesetzt ist – etwa ein Übertragungsfehler. Signaturbasierte Verfahren zur Erkennung von verdeckten Kanälen finden sich teils in populären NIDS. Snort kann etwa erkennen, wenn im Nutzdatenbereich von ICMP Ping-Nachrichten ein bestimmter String vorkommt, der auf ein Tool namens Ping Tunnel schließen lässt, wobei es sich um ein Tool handelt, das verdeckte Kanäle in selbige Nutzdaten einbettet. Die entsprechende Erkennungssignatur wird in der Signaturdatenbank von Snort hinterlegt. Im Voraus ist es nicht immer trivial, die korrekten Werte auszuwählen und mit der entsprechenden Gewichtung in einen Detektionsalgorithmus einfließen zu lassen, zumal Detektionsalgorithmen praktisch für jeden Typ eines verdeckten Kanals neu entworfen

9.3 Gegenmaßnahmen zur Netzwerksteganografie

287

Inter Protocol Gaps 9

Normal Traffic 3 Protocol Channel Bursts with Interrupts (pct) Download Traffic

8

IPG time (in sec)

7 6 5 4 3 2 1 0

0

500

1000

1500 2000 IPG number

2500

3000

3500

Abb. 9.5 Inter Protocol Gaps von normalem Traffic (blau), Protocol Switching Covert Channelduchsetztem Traffic (mit drei Pausen, rot) und HTTP-Download-Traffic (grau)

werden müssen. Solche Metriken können sich aus verschiedenen anderen Werten zusammensetzen, wie das folgende Beispiel einer anomaliebasierten Erkennung illustriert. Für die Detektion der oben eingeführten Protocol Switching Covert Channels kann – aufbauend auf unterschiedlichen vorherigen Analysen – der Wert γ berechnet werden, der die verdeckten Kanäle mit einer akzeptablen Wahrscheinlichkeit detektieren kann [30]. Die zugrunde liegende Erkenntnis ist dabei jene, dass die sogenannten Inter-protocol Gaps (IPGs2 ), das sind die Zeitintervalle zwischen dem Wechsel von verwendeten Protokollen in Paketen, je nach Art des Datenverkehrs unterschiedlich ausfallen. Das heißt, dass sich die Anzahl der IPGs pro Tausend Paketen sowie die Zeitintervalle zwischen IPGs je nach Datenverkehr verändern. Abb. 9.5 verdeutlicht dieses Szenario anhand von normalem Datenverkehr eines Linux-PCs (5,000 Pakete), Datenverkehr eines Protocol Switching Covert Channels (auch Protocol Channel genannt) und HTTP-Downloadverkehr, der nur wenige IPGs aufweist, da eine große Anzahl an HTTP-Paketen nur durch wenige andere Pakete unterbrochen wird (etwa durch ARP-Requests). Der Wert γ wird wie folgt berechnet, wobei die tri-Funktion letztlich nur dazu dient, die IPGs der Protocol Switching Covert Channels zu erfassen:

γ =

 1−

Dtest Dnormal

q −1

·

q  i=2

tri

φ − (i−1)n i n/s

 , q ≥ 2,

(9.1)

2 Diese Abkürzung ist nicht mit den Inter-packet Gaps zu verwechseln, die ebenfalls mit „IPG“ abgekürzt werden.

288

9 Netzwerksteganografie

wobei n die Anzahl der aufgezeichneten Netzwerkpakete (in unserem Fall 5,000) und i die Anzahl unterschiedlicher Protokolle in der Aufzeichnung darstellen (i erhält man durch simples Zählen). Man berechnet für legitimen Datenverkehr – basierend auf historischen Aufzeichnungen des jeweiligen Netzwerks – die durchschnittlichen Protokollwechsel pro Zeiteinheit (Dnormal ) sowie die Anzahl der durchschnittlichen Protokollwechsel pro Zeiteinheit für den zu testenden Datenverkehr (Dtest ). q wird auf die maximal angenommene Anzahl an gleichzeitig verwendeten Netzwerkprotokollen gesetzt, die ein Protocol Switching Covert Channel verwenden kann (im Normalfall ist q = 4). Der Parameter s dient einzig dazu, die Spreizung der tri-Funktion zu verändern und dient der Optimierung des Algorithmus und wurde nach einigen Tests auf den Wert 2 gesetzt. Generell spricht ein höherer γ -Wert auch für das wahrscheinlichere Vorhandensein eines Protocol Switching Covert Channels; die Genauigkeit einer γ -basierten Detektion kann allerdings mithilfe des C4.5-Klassifikationsalgorithmus und leicht veränderter Metrik übertroffen werden [30].

9.3.2

Limitierung

Bei den Verfahren, die verdeckte Kanäle limitieren sollen, muss immer auch bedacht werden, welche Auswirkungen eine Limitierung auf legitimen Datenverkehr und legitime Prozesse hat. Ein klassischer Ansatz für die Limitierung von verdeckten Kanälen ist die Network Pump. Dieses von Kang et al. [10] entwickelte Verfahren reduziert die Anzahl der Empfangsbestätigungen pro Sekunde, die für eine Nachricht verschickt werden. Ein Timing Channel, der durch die Anzahl von Empfangsbestätigungen verdeckt signalisieren möchte (Message Timing/Sequence Pattern), wird dadurch zwar nicht eliminiert, aber kann weniger Symbole pro Sekunde übertragen. Eine Beurteilung des Verfahrens findet sich unter anderem in [25]; dort gehe ich auch auf verwandte Verfahren wie den ACK-Filter, das Store-and-Forward-Protocol, Einweg-Links, den Upwards Channel und die Quantized Pump ein. Ein von uns entwickeltes Verfahren zur Limitierung der Bitrate von Protocol Switching Covert Channels ist der sogenannte Protocol Channel-aware Active Warden (PCAW) [29]. Protocol Switching Covert Channels müssen das von ihnen verwendete Protokoll zwangsläufig oft wechseln. PCAWs setzen an diesem Punkt an und verzögern Pakete, die ein unterschiedliches Protokoll als vorherige Pakete aufweisen, minimal. Bei legitimem Datenverkehr ist dies kein Problem, da es wenige oder keine Abhängigkeiten zwischen verschiedenen Protokollen gibt und diese vorhandenen Abhängigkeiten3 kleine Verzögerungen problemlos tolerieren können. Bei Protocol Switching Covert Channels sorgt eine

3 Beispielsweise hängt ein HTTP-Request unter Umständen von einem DNS-Request ab, der zunächst einen Hostnamen in eine IP auflöst.

9.3 Gegenmaßnahmen zur Netzwerksteganografie

289

Verzögerung bei Protokollwechseln hingegen dafür, dass die Kodierung der geheimen Symbole zerwürfelt wird. Die Verzögerung kann dabei mit einem konstanten Wert d erfolgen oder für jedes neue Paket zufällig mit einem Wert dr im Bereich 0 < dr < d erfolgen. In Experimenten zeigte sich, dass zufällige Verzögerungen selbst dann effektiver als konstante Verzögerungen sind, wenn sie kleiner ausfallen. Dies liegt daran, dass sie den Datenverkehr aus Sicht des verdeckten Kanals unvorhersehbar verwürfeln, während eine konstante Verzögerung manche verdeckte Nachrichten nur insgesamt verzögert, aber ihre Reihenfolge erhält (durch die Wahl einer geschickten Kodierung für den verdeckten Kanal ist dies möglich). Auch bei PCAWs wird ein Protocol Switching Covert Channel nach wie vor ermöglicht; allerdings muss er seine Senderate abhängig von d drosseln [29].

9.3.3

Unterbindung

Detektion und Limitierung sind selbstverständlich nur von begrenztem Nutzen. Um etwa Datenexfiltration zu unterbinden, ist es viel besser, wenn diese nicht nur verlangsamt oder detektiert werden kann, sondern, wenn man sie ganz verhindern kann. Gezieltes Blocken von Verbindungen, bei denen verdeckte Kanäle zuvor detektiert wurden, ist eine Möglichkeit, verdeckte Kanäle zu unterbinden. Es gibt allerdings noch weitere Verfahren; bei diesen ist keine Kopplung mit einer vorherigen Detektion notwendig. Ein sehr effektives und zugleich praxistaugliches Verfahren ist die Traffic Normalization (Abb. 9.6) [25]. Bei der Traffic Normalization werden – abstrakt betrachtet – Mehrdeutigkeiten aus dem Datenverkehr entfernt und Datenverkehr an eine Spezifikation angepasst (vgl. Abschn. 6.3.2.3). Man kann bei Traffic Normalization entsprechend auch von einem Intrusion/Extrusion Prevention System mit spezifikationsbasierter (manchmal auch regelbasierter) Vorgehensweise sprechen. Die meisten Firewalls verfügen heute über Komponenten für Traffic Normalization. Diese können beispielsweise gesetzte Bits in

Abb. 9.6 Arbeitsprinzip eines Traffic Normalizers: Uneinheitlicher Datenverkehr wird in dem Sinne vereinheitlicht, dass er einer Spezifikation (und ggf. weiteren Vorgaben) entspricht

290

9 Netzwerksteganografie

Headerelementen oder Padding-Bereichen löschen (clearen), deren Bits 0 sein müssen. Sie können zudem Headerlemente entfernen, wenn diese nicht standardkompatibel oder erwünscht sind. Nicht-standardkonformer Datenverkehr wird insbesondere durch Fuzzer erzeugt. Fuzzer probieren verschiedene Kombinationsmöglichkeiten von Werten für Headerlemente und senden diese an ein Ziel. Immer dann, wenn ein Ziel die empfangenen Daten nicht korrekt verarbeiten kann, kommt es zu einer Fehlfunktion, beispielsweise einem DoS. Durch Traffic Normalization können zum Beispiel Optionsheader aus IPv4Paketen, Extension Header aus IPv6-Paketen oder NOOP-Befehle aus FTP-Datenverkehr entfernt werden, ohne tatsächlich die Semantik relevanter Protokollfunktionen zu beeinflussen. Durch das Entfernen (oder Überschreiben) solcher Inhalte wird ein Empfänger nicht zur Interpretation der Daten gezwungen. Gleichzeitig werden potenzielle steganografische Inhalte überschrieben beziehungsweise entfernt. Traffic Normalization kann entweder nebenwirkungsfrei oder nebenwirkungsbehaftet sein [25]. Wenn Sie nebenwirkungsfrei ist, dann sind die durch die Traffic Normalization durchgeführten Eingriffe in den Netzwerkverkehr frei von negativen Nebenwirkungen. Eine Nebenwirkung kann beispielsweise die Erzeugung zusätzlicher Verzögerungen auf legitimen Datenverkehr sein. Eine andere Nebenwirkung kann die Reduktion von Protokollfunktionen sein, weil die zugehörigen Headerfelder überschrieben werden. Außerdem sind fehlerfreie und fehlerbehaftete Normalisierung zu unterscheiden. Fehlerbehaftet kann sie etwa dann sein, wenn sie aufgrund unvollständiger Informationen (zum Beispiel fehlende IP-Fragmente) operieren muss [25].

9.4

Exkurs: Linguistische Steganografie

Selbstverständlich können Datenübertragungen Nutzdaten (Payload) jedweder Art beinhalten, etwa Bilddateien, Audiodateien und -streams, Word-Dateien, HTML oder simplen Text. Zu Beginn dieses Kapitels wurden Beispiele für linguistische Steganografie gezeigt, die sich beispielsweise für HTML-Nutzdaten eignen. Abb. 9.7 zeigt das Beispiel sogenannter Open Space Steganography (OSS). OSS ist eine sehr simple Form der Steganografie. Hierbei wird eine gemeine Nachricht durch nicht gedruckte Zeichen (Whitespaces) kodiert. Eine bestimmte Anzahl solcher Whitespaces pro Zeile kann beispielsweise ein geheimes Symbol repräsentieren. Wie für andere Methoden der Steganografie auch, gibt es diverse Maßnahmen zur Detektion von OSS. OSS gilt als besonders einfach detektierbar. Sui et al. schlagen etwa folgendes Vorgehen vor [20, 22]: Die Autoren berechnen zunächst den Anteil ptsco der Whitespaces einer Webseite w: ptsco (w) =

Anzahl der Whitespace-Zeichen von w Anzahl der Zeichen von w

9.5 Zusammenfassung

291

xyz

ABC



< head> xyz

ABC

Abb. 9.7 Eine HTML-Datei ohne steganografischen Inhalt (l.) sowie eine Datei, in der Open Space Steganograpfie durch Leerzeichen und Leerzeilen eingebaut wurde (r.)

Dabei stellte sich heraus, dass ptsco bei einer Datei, die keine Steganografie beinhaltet, bei etwa 0.2 ± 0.1 liegt, wobei die Autoren ab einem Thresholdwert von 0.3 die Verwendung von Steganografie vermuten [20,22]. Weiter berechneten Sui et al. den Anteil pscso der Whitespace-Sequenzen von w: pscso (w) =

Anzahl der Whitespace-Sequenzen von w Anzahl der Whitespace-Zeichen von w

Dabei ergab sich, dass pscso für normale Dateien bei 0.2 liegt. Mithilfe der Kombination beider Werte kann OSS in einigen Fällen bereits gut detektiert werden. Sedeeq et al. schlugen einen wesentlich verbesserten Ansatz durch Verwendung eines Classifiers4 vor [20]. Die dabei unter Einbeziehung von 150 Webseiten aus unterschiedlichen Bereichen (Nachrichtenseiten, Webshops etc.) erzielten Resultate wiesen eine sehr hohe Genauigkeit (Accuracy) gegenüber bisherigen Verfahren auf.

9.5

Zusammenfassung

Die kriminelle Verwendung der Steganografie stieg in den vergangenen Jahren an [15]. Die sich aus diesem Anstieg ergebende Gefahr gilt es nun durch Schutzmaßnahmen zu adressieren. Im Kontext der Netzwerksicherheit ist insbesondere die Netzwerksteganografie von Belang. Sie umfasst Methoden, die Daten im Netzwerkverkehr unterbringen, etwa indem zeitliches Verhalten von Datenpaketen manipuliert wird. Wie Versteckmethoden funktionieren, lässt sich am besten anhand von Versteckmustern (Hiding Patterns) verstehen. Versteckmuster repräsentieren alle wesentlichen Verstecktechniken für Netzwerke. Diverse ausgefeilte Methoden, etwa die Kombination von Hiding Patterns (Pattern Combination) und der Wechsel zwischen denselben (Pattern Hopping), erschweren die Wirkung von Gegenmaßnahmen.

4 Classifier sind eine Methodenfamilie aus dem Bereich des maschinellen Lernens.

292

9 Netzwerksteganografie

Gegenmaßnahmen (Wardens) können aktiv oder passiv agieren. Passive Methoden versuchen, Steganografie zu detektieren oder die Involvierung von Teilnehmern in eine steganografische Kommunikation festzustellen. Aktive Methoden können in zwei Gruppen geteilt werden: Limitierende Verfahren wie die Pump versuchen die Kanalkapazität einer steganografischen Kommunikation zu reduzieren. Eliminierende Verfahren wie die Traffic Normalization versuchen hingegen, Steganografie aus zu untersuchenden Objekten (Datenverkehr) zu entfernen. Eine besondere Form der aktiven Gegenmaßnahmen sind maliziöse Maßnahmen (Malicious Wardens), die etwa in der Lage sind, steganografischen Datenverkehr zu spoofen und dadurch wiederum selbst verdeckt mit den steganografischen Kommunikatoren interagieren bzw. diese besser überwachen zu können [16].

9.6

Weiterführende Literatur

Eine umfassende Einführung in die Grundlagen und den aktuellen Forschungsstand der Netzwerksteganografie (und verwandter Disziplinen) bietet unser Buch Information Hiding in Communication Networks [16]. In meinem Buch Tunnel und verdeckte Kanäle im Netz [25], auf dem das vorliegende Buch in Teilen basiert, betrachte ich insbesondere Gegenmaßnahmen deutlich ausführlicher, als im vorliegenden Kapitel. Eine ausführliche Betrachtung der Hiding Patterns findet sich wiederum in [32] und [16].

9.7

Übungsaufgaben

1. Was ist ein verdeckter Kanal? 2. Weshalb beschäftigt sich ein Kapitel zur Netzwerksteganografie ausführlich mit verdeckten Kanälen? 3. Worin besteht der Unterschied zwischen einem Passive Warden und einem Active Warden? 4. Was sind Hiding Patterns? 5. Welchen Vorteil bieten Protocol Hopping Covert Channels und Pattern Hopping gegenüber der Verwendung von nur einer einzigen steganografischen Verstecktechnik? 6. Erläutern Sie die Funktionsweise von Protocol Switching Covert Channels. 7. Welche möglichen vier Arten von Gegenmaßnahmen können gemäß Zander et al. zum Einsatz kommen, um Netzwerksteganografie zu unterbinden? 8. Was wird unter Open Space Steganography verstanden? 9. Erläutern Sie, weshalb die Verdecktheit eines Kanals zunimmt, wenn seine Senderate vom steganografischen Sender reduziert wird. 10. Was bedeutet es, wenn Timing Channels Protocol-aware beziehungsweise protocolagnostic sind? 11. Welchem Hiding Pattern entsprechen Protocol Switching Covert Channels? 12. Wie können Protocol Switching Covert Channels detektiert und wie limitiert werden?

Literatur

293

13. Erläutern Sie die in diesem Kapitel vorgestellten Hiding Patterns. 14. Welches Hiding Pattern kann mit einer Network Pump limitiert werden? 15. Wie funktioniert ein Traffic Normalizer?

Literatur 1. Ahsan, K., Kundur, D.: Practical data hiding in TCP/IP. In: Proceedings of Workshop on Multimedia Security at ACM Multimedia, vol. 2, no. 7. ACM (2002) 2. Carrara, B., Adams, C.: Out-of-band Covert channels – A survey. ACM Comput. Surv. 49(2), 1–36 (2016). Artikel 23, ACM 3. Department of Defense (DoD): Trusted Computer System Evaluation Criteria, DoD Standard 5200.28, Dezember 1985 4. Freiling, F.C., Schinzel, S.: Detecting hidden storage side channel vulnerabilities in networked applications. In: Future Challenges in Security and Privacy for Academia and Industry (IFIP SEC 2011), S. 41–55. Springer, Berlin (2011) 5. Guri, M., Solewicz, Y., Daidakulov, A., Elovici, Y.: Fansmitter: Acoustic Data Exfiltration from (Speakerless) Air-Gapped Computers (2016). arXiv preprint, Nummer 1606.05915 6. Hanspach, M., Goetz, M.: On Covert acoustical mesh networks in air (2014). arXiv preprint, Nummer 1406.1213 7. Hanspach, M., Goetz, M.: Recent developments in Covert acoustical communications. In: Proceedings of Sicherheit, S. 243–254. Gesellschaft für Informatik (2014) 8. Herzberg, A., Shulman, H.: Limiting MitM to MitE Covert-channels. In: Proceedings of the Availability, Reliability and Security (ARES), S. 236–241. IEEE (2013) 9. Kahn, D.: The Codebreakers. The Story of Secret Writing. Scribner, New York (1996) 10. Kang, M.H., Moskowitz, I.S., Chincheck, S.: The pump: a decade of Covert fun. In: Proceedings of the 21st Annual Computer Security Applications Conference, S. 352–360 (2005) 11. Keller, J., Magauer, J.: Error-correcting codes in steganography. In: Proceedings of the ARCS ’06 Workshop on Dependability and Fault Tolerance, S. 52–55. GI (2006) 12. Lampson, B.W.: A note on the confinement problem. Commun. ACM 16(10), 613–615 (1973). Springer 13. Lucena, N.B., Lewandowski, G., Chapin, S.J.: Covert channels in IPv6. In: Proceedings of the International Workshop on Privacy Enhancing Technologies, S. 147–166. Springer, Berlin (2005) 14. Mazurczyk, W., Szczypiorski, K.: Steganography of VoIP streams. In: OTM Confederated International Conferences – On the Move to Meaningful Internet Systems, S. 1001–1018. Springer, Berlin (2008) 15. Mazurczyk, W., Wendzel, S.: Information hiding – challenge for forensic experts. Commun. ACM 61(1), 86–94 (2018). ACM 16. Mazurczyk, W., Wendzel, S., Zander, S., Houmansadr, A., Szczypiorski, K.: Information Hiding in Communication Networks. Fundamentals, Mechanisms, Applications, and Countermeasures. IEEE Series on Information & Communication Networks Security, Wiley/IEEE Press, Hoboken (2016) 17. Munoz, A., Cuadrado, J.: Establishing Covert channels by abusing GSM AT commands, Vortrag im Rahmen der Tagung ,Hack-in-the-Box‘ Amsterdam (HITBAMS) (2018) 18. Rowland, C.H.: Covert channels in the TCP/IP protocol suite. First Monday 2(5) (1997). http:// ojphi.org/ojs/index.php/fm/article/view/528 19. Simmons, G.J.: The Prisoner’s problem and the subliminal channel. In: Advances in Cryptology – Proceedings of CRYPTO ’83, S. 51–67. Plenum Press (1984)

294

9 Netzwerksteganografie

20. Sedeeq, I., Coenen, F., Lisitsa, A.: A prediction model based approach to open space steganography detection in HTML webpages. In: Proceedings of the 16th International Workshop on Digital Forensics and Watermarking (IWDW ’17). LNCS, vol. 10431, S. 235–247. Springer, Berlin (2017) 21. Spiekermann, D., Keller, J., Eggendorfer, T.: Towards Covert channels in cloud environments: a study of implementations in virtual networks. In: Proceedings of the 16th International Workshop on Digital Forensics and Watermarking (IWDW ’17). LNCS, vol. 10431, S. 235–247. Springer, Berlin (2017) 22. Sui, X.-G., Luo, H.: A steganalysis method based on the distribution of space characters. In: Proceedings of the International Conference on Communications, Circuits and Systems, S. 54–56 (2006) 23. Tonejc, J., Güttes, S., Kobekova, A., Kaur, J.: Machine learning methods for anomaly detection in BACnet networks. J. Univers. Comput. Sci. (JUCS) 22(9), 1203–1224 (2016) 24. Tuptuk, N., Hailes, S.: Covert channel attacks in pervasive computing. In: Proceedings of the 2015 IEEE International Conference on Pervasive Computing and Communications (PerCom), S. 236–242. IEEE (2015) 25. Wendzel, S.: Tunnel und verdeckte Kanäle im Netz. Springer, Berlin (2012) 26. Wendzel, S.: The problem of traffic normalization within a Covert channel’s network environment learning phase. In: Proc. Sicherheit 2012 (6. Jahrestagung des Fachbereichs Sicherheit). LNI, Bd. 195, S. 149–161. Gesellschaft für Informatik (2012) 27. Wendzel, S.: Why Johnny can’t use stego: a human-oriented perspective on the application of steganography (2016). arXiv preprint, arXiv:1609.06664 28. Wendzel, S., Keller, J.: Low-attention forwarding for mobile network Covert channels. In: 12th Conference on Communications and Multimedia Security (CMS 2011). LNCS, Bd. 7025, S. 122–133. Springer, Berlin (2011) 29. Wendzel, S., Keller, J.: Preventing protocol switching Covert channels. Int. J. Adv. Secur. 5(3&4), 81–93 (2012). IARIA 30. Wendzel, S., Zander, S.: Detecting protocol switching Covert cHANNELS. In: Proceedings of the Local Computer Networks (LCN), S. 280–283. IEEE (2012) 31. Wendzel, S., Kahler, B., Rist, T.: Covert channels and their prevention in building automation protocols – a prototype exemplified using BACnet. In: Proceedings of the 2012 IEEE International Conference on Green Computing and Communications, Conference on Internet of Things, and Conference on Cyber, Physical and Social Computing, S. 731–736. IEEE (2012) 32. Wendzel, S., Zander, S., Fechner, B., Herdin, C.: Pattern-based survey and categorization of network Covert channel techniques. ACM Comput. Surv. (CSUR) 47(3), 1–26 (2015) 33. Wendzel, S., Mazurczyk, W., Zander, S.: Unified description for network information hiding methods. J. Univers. Comput. Sci. (JUCS) 22(11), 1456–1486 (2016) 34. Wendzel, S., Mazurczyk, W., Haas, G.: Steganography for cyber-physical systems. J. Cyber Secur. Mobil. (JCSM) 6(2), 105–126 (2017). River Publishers 35. Wolfe, H.B.: The mobile phone as surveillance device: progress, perils, and protective measures. In: IEEE Computer, S. 50–58. IEEE (2017) 36. Xu, G., Yang, W., Huang, L.: Hybrid covert channel in LTE-A: modeling and analysis. J. Netw. Comput. Appl. 111, 117–126 (2018). Elsevier 37. Yarochkin, F.V., Dai, S.-Y., et al.: Towards adaptive Covert communication system. In: Proceedings of the PRDC ’08, S. 153–159. IEEE Computer Society (2008) 38. Zander, S., Armitage, G., Branch, P.: A survey of Covert channels and countermeasures in computer network protocols. IEEE Commun. Surv. Tutorials 9(3), 44–57 (2007). IEEE 39. Zhang, X., Tan, Y.A., Liang, C., Li, Y., Li, J.: A Covert channel over VoLTE via adjusting silence periods. In: IEEE Access. IEEE (2018)

Sicherheit im Internet der Dinge

10

People’s ignorance, including criminals, of what information a device stores and the amount of data it generates means that a properly trained and equipped expert can recover and make use of information from almost any digital device. – Emlyn Butterfield (2014)

Zusammenfassung

Dieses Kapitel führt in die IT-Sicherheit für das Internet der Dinge (IoT) ein. Zunächst wird definiert, was das IoT ist und weshalb IT-Sicherheit im IoT sich von der ITSicherheit in klassischen Netzwerken unterscheidet. Es wird erläutert, weshalb im IoT ein Mangel an IT-Sicherheit herrscht und welche Rolle Standardisierung dabei spielt. Anschließend wird das Grundproblem des IoT-Patchings erläutert. Die Gebiete Smart Homes/Buildings und Industriesteueranlagen werden im Detail besprochen. Weitere Anwendungsgebiete (bspw. electronic Healthcare und Landwirtschaft) werden kurz aus Sicherheitssicht erläutert, wobei der Fokus insbesondere auf der Netzwerkkommunikation liegt. Das Ende des Kapitels widmet sich schließlich dem Thema IoT-Forensik.

10.1

Einführung

Hinter dem Internet der Dinge, kurz IoT für Internet of Things, steht ein 1999 vom AutoID-Laboratorium des MIT vorgestelltes Konzept, das RFID-Technologie, Sensorik, smarte Technologien und Nanotechnologie als Treibkräfte nutzt, um neue Dienstleistungen zu

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2018 S. Wendzel, IT-Sicherheit für TCP/IP- und IoT-Netzwerke, https://doi.org/10.1007/978-3-658-22603-9_10

295

296

10 Sicherheit im Internet der Dinge

entwickeln. Dabei besteht alles aus Dingen [37].1 Die Anzahl der vom Menschen erschaffenen IoT-Dinge übertrifft mittlerweile die Anzahl der Menschen auf dem Planeten [65]. Diese Kombination von Dingen verspicht ein höheres Maß an Safety, bessere Möglichkeiten für die Betreuung von Patienten, eine höhere Energieeffizienz für verschiedene Anwendungsberichte und verbesserte Produktionsprozesse [22], um nur einige angedachte Vorzüge zu nennen. Das IoT deckt dabei genauer betrachtet folgende Aspekte ab (übersetzt und zusammengefasst aus [37]): • RFID soll das Nachverfolgen und Identfizieren von Dingen ermöglichen. • Sensoren sollen Daten sammeln und verarbeiten, auch um Änderungen im physikalischen Status von Dingen zu detektieren. • Smarte Technologien sollen die Leistung von Netzen verbessern indem Verarbeitungskapazitäten verteilt werden. • Nanotechnologie soll wiederum immer kleiner werdende Dinge ermöglichen, die wiederum die Fähigkeit aufweisen sollen, sich miteinander zu verbinden und zu interagieren. Zentral für das Verständnis von Dingen ist wiederum die Sichtweise: „[view] everything as the same, not even discriminating between humans and machines“; diese Aussage gilt zudem für physikalische wie für virtuelle Dinge [37]. Dinge im IoT können laut dieser Betrachtungsweise folglich alle physikalischen und virtuellen sowie alle lebenden und leblosen Dinge sein. Sicherheit wird im IoT deshalb als umfassender, alle Lebensbereiche betreffender Gegenstand betrachtet. Entsprechend ist das IoT ein Grundelement der Smart City. Eine Smart City ist the effective integration of physical, digital and human systems in the built environment to deliver a sustainable, prosperous and inclusive future for its citizens.2 Allerdings deckt das IoT eben nicht nur Smart Citys, sondern auch potenziell die restliche Welt, kleine Ortschaften in der Pampa, Wanderer in der Einöde und gar Tiere (Tiertelemetrie) ab. Das IoT breitet sich zudem über und unter Wasser aus.3 Es ist zu erwarten, dass mithilfe des IoTs auch in den nächsten Jahren und Jahrzehnten Innovationen entstehen werden, über die gesellschaftlich bisher noch nicht nachgedacht wurde, etwa das Bekämpfen von Mücken, die Krankheiten wie den Zika-Virus übertragen, mithilfe von Dronen [1] – auch hier könnte zukünftig ein weltweites Netzwerk den Einsatz von IoT-Dronen koordinieren. Ein weiteres wachsendes Einsatzgebiet ist die Landwirtschaft, für die Ansätze wie das Internet of Cows [2] entwickelt wurden. Bedeutsam sind zudem mit dem Internet verbundene und

1 Nicht alle Autoren sehen das Internet der Dinge in einem allgemein akzeptierten und vollständigen

Sinne definiert [8]. 2 Diese Aussage stammt von der Webseite der BSI Group. 3 Tatsächlich deckt das IoT auch den Weltraum ab.

10.1 Einführung

297

durch smarte Technologien optimierte Traktoren [58], die die Erträge von Feldern steigern und den Einsatz von chemischen Stoffen (Pflanzenbekämpfung) reduzieren können. All diese IoT-Sektoren, von Produktionsanlagen über Dronen bis hin zur Agrarwirtschaft, müssen ihre jeweiligen IoT-Produkte zunächst in eine Phase der Akzeptanz überführen. Aufkommende IoT-Services und -Produkte werden zunächst von wenigen Personen, sogenannten Early Adopters, aufgenommen und verwendet. Falls es zu einem Durchbruch einer dieser Services/Produkte kommt, werden sie schneller und von zugleich mehr Personen in Verwendung genommen, bis schließlich eine Mainstream-Phase erreicht wird, bei der sie durch die Massen angewandt werden [47]. Kernelement des IoT sind die sogenannten Cyber-physikalischen Systeme (CPS). CPS sind als integrations of computation with physical processes definiert [44]. Song et al. sprechen etwas präziser von engineered systems that are built from, and depend upon, the seamless integration of sensing, computation, control, and networking in physical objects and infrastructures [65]. Tawalbeh und Tawalbeh beschreiben ein CPS als systems that consist of engineered and physical entities to perform computational and physical processes. The main idea [. . . ] is to enable the interaction between the physical world and the digital world through new computer-based modeling [. . . ], CPS [. . . ] perform interaction between networked computational resources and physical systems [70]. Dies können etwa smarte Gebäude (Smart Homes/Buildings), Industriesteueranlagen, tragbare Elektronik (Wearables), Systeme der Gesundheitsversorgung (electronic Healthcare, eHealth) oder smarte Autos sein. Beispiel Smart Transportation

Teil des IoTs können beispielsweise sämtliche Transportvehikel sein, auch solche, die sich autonom bewegen. Neben dem Straßenverkehr geht auch in der Zug- und sogar in der Schifffahrt die Entwicklung hin zur autonomen Beförderung [45], insbesondere von Fracht. IT-Sicherheit betrifft diese Transportsysteme selbst sowie die angeschlossenen Systeme; für Schiffe sind dies etwa Zutrittssysteme, Cargo-Handling und Steuersysteme für Kräne und damit verbundene SCADA-Systeme [33]. Das IoT lässt sich zudem in Domänen kategorisieren, unter anderem gibt es das Financial IoT und das Industrial IoT. Das Financial IoT befasst sich etwa damit, wie aufgrund von Dingen (und ihren Messwerten beziehungsweise ihrer Nutzung) Versicherungen bepreist werden können [64]. So können Fitnesstracker, die melden, dass Versicherte viel Sport treiben, positive Auswirkungen auf einen Versicherungstarif haben. Ein anderes Forschungsgebiet des Financial IoT besteht darin, individuelle Stromtarife basierend auf der Nutzung von Dingen zu ermöglichen [64]. So kann es etwa günstiger sein, seine Wäsche zu waschen, während das Stromnetz gerade nicht ausgelastet ist.4 Die

4 Selbstverständlich sind beide Szenarien mit einer potenziellen Beeinträchtigung der Privatsphäre ihrer Benutzer/Kunden verbunden.

298

10 Sicherheit im Internet der Dinge

Domäne des Financial IoT soll an dieser Stelle allerdings nur beispielhaft erwähnt sein, da die Sicherheit des IoT in diesem Kapitel generisch, also domänenübergreifend, beziehungsweise auf Netzwerkebene betrachtet wird. Wie das Beispiel der Financial IoT jedoch verdeutlicht, so ist das IoT eng mit der Digitalisierung der Wirtschaft und mit den Veränderungen unserer Gesellschaft durch dieselbe verbunden. Mit der Einführung des IoT ergeben sich dadurch auch zahlreiche soziale Herausforderungen und Fragestellungen, die von Sendler in [61] erläutert werden, und die teilweise die Grundfeste unseres Wirtschaftssystems betreffen. Sendler nach werden nicht mehr nur eine hohe Qualität und Haltbarkeit eines einzelnen Produkts, auch nicht die besondere Qualität eines bestimmten Softwareprogramms oder -diensts, [. . . ] über Erfolg und Gelingen entscheiden, sondern die Rolle, die das einzelne Ding oder Programm als System unter Systemen spielt. Diese Aussage lässt sich insbesondere im Kontext von Märkten und ihren Konkurrenzsituationen verstehen. Denn, so Sendler weiter, bei jedem Produkt muss sich der Produzent überlegen, ob die Wertschöpfungskette lediglich über den Verkauf erfolgen soll oder ob es ein Geschäftsmodell gibt, bei dem das vernetzte Produkt zumindest auch die Basis für neuartige internetbasierte Dienstleistungen ist [61].

Grundlegende Herausforderungen für die Sicherheit im IoT Ein Kernproblem der fehlenden IT-Sicherheit im IoT ist, dass Hersteller sich (i) gar nicht der Kritikalität ihrer Systeme bewusst sind (weil sie etwa nur eine Glühbirne herstellen, die allein genommen unwichtig erscheint, im größeren Kontext jedoch kritisch werden kann) und (ii) darauf bedacht sind, Kosten zu sparen [17]. Abschn. 10.2 betrachtet dieses Problem noch genauer. In einem Artikel für das Journal Communications of the ACM erklärte ich 2016 die notwendigen Pfade zu sichereren IoT-Systemen am Beispiel der Smart Buildings [76]. Ich fasse die zentralen Punkte im Folgenden zusammen: 1. Zum einen müssen dazu internetbasierte Kommunikationen abgesichert werden. Denn IoT-Geräte, inklusive solcher, die ursprünglich nie für das Internet ausgelegt wurden, etwa automatisierte Gebäude, werden ohne große Sorge um Sicherheit mit dem weltweiten Netz verbunden. 2. Weiterhin muss studiert werden, welche Auswirkungen Angriffe überhaupt haben können. Wird etwa eine Klimaanlage attackiert, ist dies hochgradig kontextabhängig. So kann eine Klimaanlage in einem Serverraum, wenn sie durch einen Angriff deaktiviert wird, wie ein Denial-of-Service-Angriff wirken, weil sie Server überhitzt. Nützliche Maßnahmen, etwa Türschlösser, können durch Angriffe gegen Kunden und Eigentümer verwendet werden, wie unter anderem der Fall eines österreichischen Hotels zeigt, bei dem Angreifer Hotelgäste (Fortsetzung)

10.1 Einführung

3.

4.

5.

6.

299

ausgesperrt und zugleich die Betreiber erpresst haben [16]. Anders formuliert ist es essenziell, Zusammenhänge zwischen verschiedenen Sicherheitsmaßnahmen und ihrer jeweiligen Umgebung zu verstehen. Hinzugefügt werden muss an dieser Stelle allerdings die Tatsache, dass nicht nur Angriffe zu problematischen Auswirkungen führen können, sondern auch Fehlfunktionen des IoT-Equipments. Man denke an eine Ampel, die durch einen Hardware- oder Softwarefehler plötzlich auf „grün“ schaltet, während sie eigentlich „rot“ leuchten sollte. Es müssen Wege gefunden werden, wie Software langfristig betrieben werden kann. Oft können nach einigen Jahren beispielsweise keine Software-Patches mehr in IoT-Geräte eingespielt werden; sie werden schlicht nicht mehr von Herstellern bereitgestellt oder die IoT-Geräte besitzen nicht mehr die Rechenleistung, Speicherkapazität o. ä., um verbesserte Algorithmen (etwa Verschlüsselung mit längeren Schlüsseln) performant genug auszuführen. Software muss benutzerfreundlicher werden. Das heißt, dass auch Sicherheitsaspekte verständlich beziehungsweise für den Benutzer transparent gemacht werden müssen (siehe Abschn. 3.8 zur Usable Security). Die Möglichkeit, ein VPN zu konfigurieren, bringt einem Otto Normalverbraucher wenig, wenn er nicht weiß, welche Einstellungen (Verschlüsselungsalgorithmen, Schlüssellänge etc.) am sichersten sind. Unsichere Implementierungen von Netzwerkprotokollen müssen abgesichert werden. Einst bewarb ein deutscher Hersteller von Smart Building-Produkten mir gegenüber sein Produkt, indem er sagte, dass ein guter Ingenieur den NetzwerkStack selbst geschrieben habe. Ein einzelner Ingenieur, vermutlich nicht einmal Informatiker, kann heute allerdings kaum einen besonders sicheren Netzwerkstack implementieren. Dies konnte man über viele Jahre bei den TCP/IP-Stacks beobachten. Vor der Integration von Netzwerkstacks in Produkte sollten diese Stacks auf IT-Sicherheit getestet werden, und nicht, wie in der Vergangenheit besonders häufig, nur auf ihr Funktionieren im ,Gutfall‘ (das heißt auf den Empfang korrekt gestellter, nicht-bösartiger Anfragen). Standards sind oftmals ohne Gebührenzahlung unzugänglich, auch für wissenschaftliche Institutionen. Dies macht die Untersuchung der Standards und ihre Bereitstellung, etwa für studentische Abschlussarbeiten, schwierig. Hier sollte, ähnlich den RFCs, ein offener Zugang für Jedermann ermöglicht werden. Dies schien bisher jedoch kaum im Interesse der Industrie zu liegen, die teils auf proprietäre und verschlossene Kommunikationsprotokolle setzt – mit der entsprechenden „Qualität“ hinsichtlich der Sicherheit ihrer Systeme. Leider sind deutsche Unternehmen hier nur in wenigen Fällen positiv aufgefallen. Dies betrifft allerdings nicht IoT-Branchen gleichermaßen.

(Fortsetzung)

300

10 Sicherheit im Internet der Dinge

7. Ein weiterer Aspekt, der jedoch nicht in meinem oben genannten Artikel zur Sprache kam, sondern von Collins in [18] genannt wird, ist der, dass oftmals gar nicht bekannt ist, welche Dienste IoT-Geräte anbieten. IoT-Geräte verfügen beispielsweise in zahlreichen Fällen über Webservices. Diverse vernetzte Lautsprecher, TV-Geräte, Wearables und sonstige mit dem Netz verbundene IoT-Geräte müssen entsprechend in Sicherheitsanalysen einbezogen werden, obwohl sie nicht im traditionellen Fokus der IT-Sicherheit von Organisationen stehen. Diese Geräte müssen entsprechend in das Sicherheitsbewusstsein von Administratoren Einzug halten. Allerdings ist die Durchsetzung besserer ITSicherheit für IoT-Geräte auch bei vorhandenem Sicherheitsbewusstsein nicht immer einfach, was auch durch hierarchische Organisationsstrukturen bedingt ist [18].

Eine zentrale Problematik der IT-Sicherheit im IoT-Sektor spielt das Vertrauen in die Dinge. Ullrich et al. haben in einer Veröffentlichung zur Sicherheit von Cyber-physikalischen Produktionssystemen (CPPS) zusammengefasst, welche möglichen Fragestellungen sich hinsichtlich des Vertrauens in solche Systeme ergeben [73]. Die von ihnen angeführten Punkte können auch auf das IoT im Allgemeinen bezogen werden (übersetzt aus dem Originalartikel und leicht angepasst): • Wie vertrauenswürdig sind eigentlich Informationen, die von Sensoren geliefert werden? • Erhalten Aktoren, also die physikalische Welt beeinflussende Geräte wie etwa ein Fensteröffner, überhaupt die Befehle, die an sie versendet werden (unverändert)? • Kann angenommen werden, dass Back-end-Algorithmen unverändert sind? • Sind die Algorithmen des Produktionssystems [Anm. beziehungsweise eines IoTSystems im Generellen] in der Lage, mit manipulierten Informationen umzugehen? • Ergeben sich neue Bedrohungen für die Betriebssicherheit? Tatsächlich ergeben sich neben diesen vertrauensbezogenen Fragen noch viele weitere Fragen, die auch die IT-Sicherheit und Privatsphäre betreffen. Können IoT-Geräte etwa genutzt werden, um Menschen zu überwachen? (Kippt das Vertrauen der Benutzer in die Dinge, wenn es zu Überwachungsskandalen kommt?) Können sensitive Informationen von einem IoT-Gerät an ein anderes IoT-Gerät auch ungewünscht/ohne Kenntnis der Nutzer/Betroffenen übertragen werden? Welchen Einfluss auf das Vertrauen können derartige Szenarien mit sich bringen und wie wirken sie sich auf das IoT aus? Spielen sie langfristig eine Rolle? Im Folgenden werden zunächst nicht-technische Aspekte der IoT-Sicherheit betrachtet. Dazu wird die Fragestellung adressiert, wie es zu unsicheren IoT-Geräten kommen kann. Anschließend wird das damit zusammenhängende Thema der Standardisierung betrachtet.

10.2 Schuld sind die anderen – der Cycle of Blame

301

Exkurs: Cyberkrieg und Industrie 4.0 Bekanntlich wird Industrie 4.0 als ein wichtiger Beitrag zur Digitalisierung der (deutschen) Wirtschaft betrachtet. Diesem Punkt kann schwerlich widersprochen werden. Einhergehend mit einer zunehmenden Digitalisierung der Wirtschaft entsteht allerdings auch eine zunehmende Verwundbarkeit. Diese Verwundbarkeit erschließt sich schnell, wenn betrachtet wird, was im Falle eines Cyberkriegs passieren könnte. Veranschaulicht werden kann dieses Szenario und seine Verbindung zum IoT am besten anhand von zwei imaginären Staaten A und B. Staat A sei durch und durch digitalisiert, während Staat B erst am Anfang seiner Digitalisierung steht. Ein Angriff auf die digitale Infrastruktur von Staat B hat vermutlich überschaubare Folgen für diesen Staat – schließlich sind nur wenige Prozesse und Teile der Wertschöpfungskette und Versorgung digitalisiert. Staat A hingegen kann bei einem Cyberkrieg viel mehr Schaden nehmen, und zwar aufgrund seiner komplexen und durchdringenden digitalen Infrastruktur sowie seiner Abhängigkeit von derselben. Das beeindruckendste Beispiel einer komplexen Infrastruktur stellen womöglich Energienetze dar, mit kontinentaler Spannweite und Hunderten von Millionen Komponenten [5]. Die Infrastruktur von Staat A bietet vielseitigere Möglichkeiten für Angriffe: Es können nicht nur mehr, sondern auch mehr verschiedene Komponenten der digitalen Infrastruktur, Wertschöpfungskette etc. angegriffen werden. Derlei Angriffe wiederum können Auswirkungen auf die physikalische Welt haben (denken Sie etwa eine manipulierte Steuerung des Zugverkehrs, die zu Zugunfällen führen kann). Diese Argumentation soll nicht zum Fehlschluss führen, dass Digitalisierung schlecht sei. Im Gegenteil, sie ist notwendig, bedarf aber besonders guter Absicherung.

10.2

Schuld sind die anderen – der Cycle of Blame

In einem Kurzbeitrag (Opinion) diskutierten wir 2016 einen wichtigen Grund für das Fehlen von ausreichender IT-Sicherheit in IoT-Produkten [77]. Zunächst einmal muss festgehalten werden, dass Sicherheits-Know-how mittlerweile überall und leicht verfügbar ist. Das heißt, Entwickler können dieses Know-how nutzen und für die Konzipierung und Verbesserung ihrer Produkte verwenden. Außerdem sind mittlerweile relativ viele Sicherheitsexperten und Beratungsunternehmen auf dem Markt verfügbar. Ferner wurde das Thema der IT-Sicherheit nicht mehr nur in Fachkreisen, sondern in der Öffentlichkeit unzählige Male debattiert, womit heutigen Entwicklern klar sein dürfte, welche Folgen eine schlechte IT-Sicherheit – auch von IoT-Produkten – haben wird. Die Fragestellung,

302

10 Sicherheit im Internet der Dinge

weshalb die notwendigen Sicherheitsfunktionen dennoch kaum in IoT-Produkte integriert werden, ist entsprechend berechtigt. Durch unzählige Diskussionen mit der Industrie und mit Anwendern, insbesondere im Bereich der Smart Buildings, konnten wir die Erfahrung sammeln, das die Gründe für schlechte IT-Sicherheit immer auf die anderen geschoben wurden. Ein simples Rollenmodell kann hierbei zugrunde gelegt werden. Rollen können etwa Hersteller, Entwickler, Integratoren, Planer, Operatoren oder Anwender sein. Je nach Domäne verbirgt sich hinter diesen Rollen eine spezifischere Rolle, so kann etwa ein Anwender ein Patient oder SmartHome-Nutzer sein. Anderson schrieb, dass Hersteller die IT-Sicherheit ihrer Produkte aus Kostengründen nicht erhöhen, weil Kunden nicht bereit seien, für diese höheren Kosten zu zahlen [3].5 Luiijf führt an, dass Unternehmen bei der Herstellung von ICT-Produkten schlicht nicht aus vorhergehenden Fehlern und Sicherheitsproblemen zu lernen scheinen [47]. Diese beiden Beobachtungen sind sicherlich durchaus berechtigt. Die Rolle der Hersteller schiebt die Schuld für das Nichtvorhandensein von IT-Sicherheit in diesem Fall auf die Rolle des Anwenders (des Kunden). Es ist verständlich, dass die Perspektive eines Herstellers, wie Anderson weiter schreibt, eher eine kostenspezifische statt eine von Sicherheitsbewusstsein getriebene ist. Allerdings muss angemerkt werden, dass Kunden (in der Regel kein Fachpersonal, sondern etwa Patienten oder Ärzte) wohl kaum ein höheres Sicherheitsbewusstsein aufweisen können. Kunden können aufgrund unbrauchbarer oder kaum vorhandener Darlegung von Sicherheitsfunktionen in IoT-Produkten (insbesondere auf Verpackungen) schlecht bis gar nicht über die Qualität der Sicherheit des Produkts urteilen. Aufgrund des noch immer mangelnden Sicherheitsbewusstseins von Kunden fordern diese die IT-Sicherheit zwar generell, aber nicht in hohem Maße, vom Hersteller ein. Aus Sicht der Rolle Anwender/Kunde ist unter anderem entsprechend der Hersteller „schuld“. Ebenfalls „schuld“ sind Operatoren. IoT-Operatoren können nur die Sicherheitsfunktionen integrieren, die die Produkte der Hersteller bieten beziehungsweise die Produkte absichern, die eine Einkaufsabteilung oder ein Planer vorgesehen haben. Entsprechend ist erneut eine Verschiebung der Schuld auf weitere Rollen zu betrachten. Wir bezeichnen diese zyklische Schuldzuweisung im oben genannten Beitrag als Cycle of Blame [77]. Diese Art der Schuldzuweisung kann beliebig weitergeführt werden, führt jedoch nicht zu Verbesserungen. Verbesserungen können von innen (das heißt durch Aktionen einzelner Rollen) oder von außen (etwa Gesetzesänderungen) hervorgerufen werden. Kunden könnten sich etwa stärker zusammenschließen (in einflussreichen Verbraucherverbänden), und IT-Sicherheit für IoT-Produkte fordern. Ohne Kunden werden keine Geräte verkauft und ohne Verkäufe gibt es keine überlebenden Hersteller. Hersteller könnten wiederum

5 Selbstverständlich gibt es auch weitere Gründe für den Mangel an IT-Sicherheit, die außerhalb einer Schuldzuweisung liegen, etwa den Grund, die Abwärtskompatibilität zu Vorgängerversionen von Produkten für Bestandskunden zu gewährleisten zu müssen.

10.3 Standardisierung (und Zertifizierung) im IoT

303

erkennen, dass IT-Sicherheit für IoT-Produkte langfristig mit Gewinn verbunden ist, auch Schneider et al. [60] vertreten diese Ansicht. Gutes Standing gegenüber den Kunden, und damit ein Vertrauen der Kunden in die eigenen IoT-Produkte, zahlen sich potenziell aus. Nicht zu erwarten ist jedenfalls, dass aufgrund der Meinung von Sicherheitsexperten ein Ausweg aus dem Cycle of Blame erreicht werden kann; der Einfluss von Sicherheitsexperten auf den Markt sei laut Schneier schlicht zu gering [59]. Allerdings können Sicherheitsexperten die Diskussion um das Thema zumindest beeinflussen.

10.3

Standardisierung (und Zertifizierung) im IoT

Wir haben uns im letzten Abschnitt mit der gegenseitigen Schuldzuweisung zwischen verschiedenen Rollen als Grund dafür befasst, weshalb IT-Sicherheit nicht hinreichend in IoT-Produkte integriert ist. Bojanova und Voas sehen Bedarf an weiteren Arbeiten für die Standardisierung (und Zertifizierung) im IoT-Sektor [8]. Leverett et al. befassen sich in einem Artikel ausführlich mit der Standardisierung und Zertifizierung für das IoT [46]. Darin legen sie die typischen Ziele für die Regulierung im IT-Sicherheitsbereich dar: Ermittlung, Einigung und Harmonisierung von Schutzzielen, Definition von Standards, Zertifizierung von Standardkonformität und Erzwingen von Standardkonformität sowie eine Verringerung von Verwundbarkeiten, der IT-Sicherheit betreffenden Kompromissen und von externen Effekten auf ein zu schützendes System. Ferner können die Ziele von Regulatoren darin bestehen, die Angriffskosten für Angreifer zu steigern und das Einkommen, das etwa mit gestohlenen Daten erwirtschaftet werden kann, zu minimieren. Auch kann versucht werden, die Kosten, die eine Verteidigung von IoT-Systemen mit sich bringt, und die Auswirkungen von Systemausfällen zu reduzieren [46]. Leverett et al. weisen zudem darauf hin, dass es Versicherungen ermöglicht werden sollte, Risiken angemessen zu bepreisen und dass von Regulatoren versucht werden sollte, die sozialen Kosten von Cyberkriminalität sowie die sozialen Verwundbarkeiten durch Angriffe zu minimieren. Die Autoren befassen sich auch mit dem Aspekt der Haftung. [The] Software industry fought hard for fifty years to avoid liability [. . . ], as did the car industry for the first seventy years of its existence. Im Gegensatz zu nicht-IoT-Software, insbesondere nichtCPS-Software, hat IoT-bezogene Software und haben IoT-Produkte die Eigenschaft, dass sie die physikalische Umgebung messen und steuern können. Entsprechend sind Auswirkungen auf die Sicherheit von beispielsweise Personen und anderen Lebewesen möglich. Man denke an autonome Autos, die Passanten aufgrund eines Softwarefehlers anfahren oder an die Tiererkennung von Volvo, von der sich 2017 zeigte, dass sie hüpfende Beuteltieren falsch interpretierte [71]. Schneier führt an, dass Märkte sich als ungeeignete Mechanismen erwiesen haben, um die Sicherheit von Produkten und Dienstleistungen zu verbessern [59], doch ist zumindest der Druck der öffentlichen Medien, des Prangers, ein erwiesenermaßen nützliches Mittel zur Steigerung der IT-Sicherheit von Produkten.

304

10 Sicherheit im Internet der Dinge

Gleichzeitig ist es illusorisch zu glauben, dass Hersteller hundertprozentig fehlerfreie Software erstellen können [6]. Menschen können Hersteller prinzipiell verklagen, wenn Produkte keinen Sicherheitsstandards (auch im Sinne von Safety) entsprechen. Genauso können zuständige Behörden in solchen Fällen die Marktzulassung von Produkten untersagen. Im IoT-Sektor ist genau diese Haftung aktueller Gegenstand der Forschung und der Standardisierungsarbeit. Entsprechend müssen Sicherheitsstandards potenzielle Tests und Vorrichtungen vorsehen, die einen potenziellen Personenschaden durch IoT-Produkte minimieren. Ein nicht-patchbares IoT-Gerät mag einen solchen Zweck vermutlich nicht langfristig erfüllen. Schneider et al. führen im Kontext autonomer, und in Zukunft sicherlich ebenfalls intensiv mit dem IoT-verbundener Systeme, an, dass heutige Systeme vor allem als Fail-Safe-Systeme [konstruiert werden und] im Zweifel in einen sicheren Zustand wechseln, in dem sie zwar sicher sind, aber nicht benutzt werden können. Stattdessen gelte es in Zukunft, Fail-Operational-Systeme zu entwickeln, weil es in vielen Fällen, [etwa] autonomen Fahrzeugen, auch gar keinen unmittelbaren erreichbaren Fail-Safe-Zustand gebe [60]. Zu erwarten ist auch, dass eine zunehmende Anzahl von unternehmerischen Anwendern und Herstellern von der Möglichkeit Gebrauch machen wird, sich gegenüber CyberSecurity-Vorfällen durch Versicherungen zu schützen. Derlei Versicherungen können etwa Haftungskosten (gegenüber Kunden) durch Datenverlust und -beschädigung beinhalten oder Mittel bereitstellen, um im Schadensfall koordiniert handeln zu können [35]. Hibberd und Cook weisen allerdings darauf hin, dass Unternehmen nicht der Versuchung verfallen sollten, sämtliche Risiken der Cyberkriminalität auf Versicherungen abzuwälzen, das heißt, der Versuchung zu erliegen, sich nicht selbst intensiv um die IT-Sicherheit kümmern zu müssen [35]. IoT-Sicherheitsstandards erweisen sich jedoch laut Leverett et al. als komplexes Problem. An dieser Stelle möchte ich mich eines – leicht abgewandelten – Beispiels aus dem Text der Autoren behelfen. Wenn im Jahr 2020 Software für ein Automobil entwickelt wird – wer wird dann in den folgenden Jahrzehnten für Sicherheitspatches sorgen (eventuell existiert das Unternehmen dann gar nicht mehr)? Wie kann ein Standard also beispielsweise den Vorgaben irgendeines nationalen oder europäischen Standards entsprechen, wenn er nach einigen Jahrzehnten im kenianischen Ausland eingesetzt wurde, dort anderen Standards entsprechen musste, eventuell Daten löschen musste, deren Protokollierung auf dem Speicher des Autos jedoch von einem anderen Land gefordert wurde. Auch sei wichtig, sich zu fragen, welche Aspekte eines IoT-Produkts ein Standard überhaupt abdecken kann [46]. IoT-Produkte sind nicht nur die physikalisch in den Händen oder auf dem Hof stehenden Systeme, sondern auch nachgeordnete Dienste, etwa auf Servern im Ausland. Dabei ist die Sicht von Regulatoren seitens der Regierung oder von Kunden immer gegenüber den Unternehmen benachteiligt, da Unternehmen ihre Produkte im Detail kennen, sie für Externe allerdings – zumindest in Teilen – eine Blackbox darstellen [46]. Entsprechend ist eine möglichst hohe Transparenz für Standards sinnvoll, die allerdings nicht ohne Weiteres gegeben ist. Weiterhin müssen Regulatoren festlegen,

10.4 Patching

305

welche Akteure im Falle einer Angriffsanalyse oder Bekanntgabe von Verwundbarkeiten involviert werden und welche Rollen sie dabei übernehmen. Unabhängige Institutionen (etwa polizeiliche Behörden wie Europol), staatliche Akteure (etwa ENISA oder BSI) oder unabhängige Experten können in Gesetzgebungen und standardisierten Prozessen vorgegeben werden. Derlei unabhängige Experten ermöglichen eine objektive Analyse, die Hersteller selbst nicht unbedingt liefern werden.

10.4

Patching

Tatsächlich wächst der Berg an IoT-Produkten, die nach kurzer Zeit entsorgt werden können, beständig. Man denke nur an Smartphones, die nach zwei Jahren nicht mehr mit Updates versorgt werden können. Sogenannter E-Waste (die Kurzform für electronic waste) ist ein großes Problem und für 2018 werden von diesem etwa 50 Mio. Tonnen erwartet [82]. Insofern ist es besonders wichtig, dass IoT-Produkte langfristig patchbar sind. Neben dem E-Waste sind ungepatchte, aber noch betriebene IoT-Produkte ein großes Problem für die IT-Sicherheit. Millionen von Smartphones können somit etwa relativ einfach zum Bestandteil von IoT-Botnetzen und entsprechend missbraucht werden, etwa um große Datenmengen von Spam zu versenden. Beispielhaft zeigte dies etwa das IoTroop-Botnetz, das auf Basis einer bekannten Sicherheitslücke (CVE-2017–8225) IoTGeräte infizieren konnte; die Suche nach verwundbaren Geräten gestaltete sich mithilfe der Computersuchmaschine SHODAN als einfach [51]. Ein Problem sind in diesem Kontext Produkte, die über einen längeren Zeitraum vor dem Verkauf gelagert wurden: Bei der ersten Inbetriebnahme ist die darauf enthaltene Firmeware oftmals veraltet und muss aktualisiert werden. Eine Infektion mit Schadsoftware kann in solchen Fällen binnen Minuten geschehen [6]. Wenn derlei Updates nicht automatisch geschehen, werden sie von vielen Benutzern schlicht nicht durchgeführt. Ein Automatismus ist allerdings ungenügend, es muss auch sichergestellt werden, dass Updates aus einer authentischen Quelle stammen (eventuell verschlüsselt übertragen werden) [6] und außerdem muss die Integrität der Updates gewährleistet werden. Benutzer sollten zudem auf gegebenenfalls (durch ein Update) erweiterte Rechte von Programmen hingewiesen werden. Eine maßgebliche Rolle spielt das Patching insbesondere bei Systemen, die über mehrere Jahrzehnte im Einsatz sind – beispielsweise Smart Buildings oder Industriesteueranlagen. Hierbei kann ein Betreiber allerdings kaum erwarten, dass nach 20 Jahren noch Patches möglich sind, die die dann Stat-of-the-Art-Algorithmen der Kryptografie umsetzen können. Ein möglicher Ansatz könnte es sein, Hardware patchbar zu machen, wie von Ray et al. vorgeschlagen [56]. Weiterhin sollte bedacht werden, dass Patches die Software auf einem System verändern, was wiederum bedeuten kann, dass ein System nicht mehr als nach einem Standard zertifiziert gilt, für den es in einer Altversion zertifiziert wurde. Dies kann Auswirkungen auf die Betriebserlaubnis eines IoT-Geräts haben, weil etwa Safety-Anforderungen nicht

306

10 Sicherheit im Internet der Dinge

mehr als erfüllt gelten könnten [60]. Die Gesetzeslage scheint sich zumindest in den USA derzeit dahingehend zu entwickeln, dass Patching für IoT-Systeme für Hersteller vorgeschrieben wird, das heißt, dass Geräte nicht mehr nur gepatcht werden können, sondern auch tatsächlich und zügig gepatcht werden [59].

10.5

Smart Homes und Smart Buildings

Automatisierte Gebäude standen bereits Mitte der 1990er-Jahre im Film Hackers im Zentrum von Angriffen.6 Doch worum handelt es sich bei diesen smarten Gebäuden eigenltich? Hinter einem Smart Building verbirgt sich zunächst einmal ein System, das Gebäude steuert, ein sogenanntes Building Automation System (BAS). Kleinere Varianten werden auch als Home Automation Systems (HAS) bezeichnet und verwenden teils unterschiedliche Technologie (etwa Kommunikationsprotokolle) als BAS. Eine alternative Unterscheidung zwischen verschiedenen Arten von Gebäudeautomation nennen Soucek und Zucker; sie unterteilen Gebäude in kommerzielle Gebäude, institutionelle Gebäude, Wohngebäude und Industriegebäude [66]. Neben einigen Unterschieden zwischen BAS und HAS gibt es aber auch diverse Gemeinsamkeiten, etwa ähnliche, manchmal gar gleiche, Aktoren und Sensoren und Konzepte. Smart Buildings werden anhand von Gewerken organisiert und aufgebaut [50]. Ein Gewerk kann etwa die HeizungsLüftungs-Klimatechnik (HLK) darstellen, ein anderes Gewerk ist die Beleuchtung. Jedes Gewerk wird von eigenen Spezialisten aufgebaut und betreut. So kümmert sich ein Elektrotechniker etwa um die Installation der Beleuchtung, auch in Bädern, wobei entsprechende Sicherheitsstandards und -vorschriften einzuhalten sind. Ein Heizungsinstallateur kümmert sich hingegen um die Integration des Ofens, der Heizungen, ggf. der Abflüsse. Die einzelnen gewerkespezifischen Komponenten liefern wiederum Daten, die sie in ein gemeinsames Kommunikationsnetz einspeisen. Sie können aus diesem Kommunikationsnetz zudem Befehle empfangen. So kann ein Temperatursensor etwa mit einer Heizung verbunden werden: Ist die Temperatur im Raum zu hoch, wird die Heizung gedrosselt. Das Gebäude-Netzwerk bildet entsprechend das Rückgrat eines Smart Buildings. In größeren Installationen wird es von einer Leittechnik-Zentrale gesteuert und kann mehrere Hierarchieebenen beinhalten, die jeweils von Controllern (genannt Direct Digital Controller, DDC) gesteuert werden (Abb. 10.1).

6 Genauer betrachtet hackte der Protagonist zunächst die Sprinkleranlage seiner Schule. Später wurde die Beleuchtung von Hochhäusern angegriffen. Tatsächlich wurden im Film auch weitere CPS-Ziele anvisiert, etwa das Verkehrsleitsystem (Ampelsteuerung).

10.5 Smart Homes und Smart Buildings

307

Abb. 10.1 Hierarchischer Aufbau einer Gebäudeautomation (weitere Elemente sind in der Praxis möglich – etwa Gateways zur Anbindung weiterer Liegenschaften oder eine Anbindung an die Office-IT)

10.5.1 Kommunikationsprotokolle In der IT-Welt ist es aus Sicherheitsgründen fast undenkbar, sich noch darüber zu streiten, ob offene Protokollstandards sicherheitstechnisch die besser Wahl darstellen. In der Branche der Gebäudeautomation sieht dies leider nach wie vor etwas anders aus. Zwar scheint man sich auch hier zunehmend für offene Protokolle zu entscheiden, die von der Community und unabhängigen Experten, etwa aus Universitäten, auf ihre Sicherheit hin überprüft werden können. Doch tauchen immer wieder neue unveröffentlichte Protokolle auf dem Markt auf, die teils mit einem Siegel einer Zertifizierungsstelle versehen werden. Ich konzentriere mich in diesem Kapitel nicht auf derart obskure Protokolle, sondern nur auf solche, deren Sicherheit betrachtet werden kann. Die klassischen Kommunikationsprotokolle der Gebäudeautomation sind KNX, Modbus, DALI, LON und BACnet. Zudem gibt es funkbasierte Protokolle wie ZigBee oder EnOcean. Diese Protokolle verfolgen jeweils unterschiedliche Ziele. So sind EnOcean-Sensoren etwa besonders energieeffizient, ZigBee hingegen ist ein MultiPurpose-Protokoll, das auch in anderen CPS-Domänen eingesetzt wird, zum Beispiel in der Container-Schifffahrt (zur Überwachung und für das Tracking von Containern). KNX ist ein Busprotokoll, das primär die Kommunikation in Gebäuden kleiner bis mittlerer Größe steuert. In größeren Gebäuden wird KNX hingegen eher als eines von vielen Protokollen eingesetzt. BACnet kann auf Basis von KNX, IP, Modbus und einigen anderen Protokollen betrieben werden und bietet eine objektorientierte Sicht auf ein Gebäude (Geräte besitzen Objekte (engl. Objects), etwa Temperatursensoren, und diese wiederum Eigenschaften (engl. Properties), etwa den aktuellen Temperaturwert, Minimalund Maximalwerte oder eine Modellbezeichnung). BACnet findet insbesondere beim Management von Gebäuden seinen Einsatz.

308

10 Sicherheit im Internet der Dinge

Gemeinsam ist den meisten dieser genannten Protokolle (außer Modbus), dass sie im Laufe der letzten Jahre deutlich hinsichtlich ihrer Sicherheitsfunktionen erweitert und aktualisiert wurden. KNX und BACnet etwa beinhalteten bereits seit etwa zehn Jahren Sicherheitsmechanismen in ihren Standards, allerdings wurden diese kaum bis gar nicht umgesetzt oder waren zum Zeitpunkt der Umsetzung nicht mehr aktuell (etwa Implementierung von DES, als dieser Algorithmus bereits als unsicher galt). Heute nutzen ZigBee, EnOcean, BACnet und KNX jeweils den AES-Standard mit unterschiedlichen Blockchiffren-Modi in Verbindung mit Message Authentication Codes (MAC) [80]. Außerdem werden einige der Protokolle derzeit nochmals stark überarbeitet: KNX verwendet zum Beispiel gemäß aktuellem Standard einen klassischen binären Protokollheader, wird im neuen Standard KNX/IoT allerdings auf Basis von HTTP und der REST-API umgesetzt; für die Sicherung der Übertragung kommt TLS zum Einsatz. Es ist anzunehmen, dass mindestens dem BACnet-Protokoll ähnliches bevorsteht.

10.5.2 Angriffe Angriffe auf Smart Buildings sind in der Regel netzwerkbasiert. Allerdings gibt es auch Möglichkeiten des physikalischen Eingriffs und hostbasierter Angriffe – etwa könnte ein Hausmeister, dessen Arbeitsvertrag nicht verlängert wird, die Gebäudeautomation so konfigurieren, dass einige Wochen nach seinem Ausscheiden das Gebäude nicht mehr beheizt wird. Die hostbasierte Sicherheit fällt allerdings nicht in ein Buch, dessen Thema die Netzwerksicherheit ist. Netzwerkbasierte Angriffe folgen zunächst einmal auch bei Smart Buildings klassischen Mustern und Verfahren, wie sie auch aus TCP/IP-Netzen bekannt sind. So konnten einige Autoren zeigen, dass aufgrund in der Praxis praktisch nicht vorhandener Authentizitätswahrung der Nachrichten Spoofing-Angriffe besonders einfach durchführbar sind [31]. Selbiges gilt auch für das Mitlesen von Nachrichten, da die Verschlüsselung von Nachrichten kaum implementiert wurde. Außerdem gilt, dass selbst dann, wenn ein Gerät kryptografische Methoden unterstützt, es nur dann verschlüsselt und authentifiziert mit anderen Geräten kommunizieren kann, wenn auch diese die entsprechenden Methoden unterstützen. Dies ist heute noch in fast keinem Busprotokoll für Smart Buildings der Fall; Funkprotokolle wie ZigBee sind in diesem Bereich deutlich weiter und Datenverschlüsselung ist meistens standardmäßig aktiviert. Weiterhin konnten diverse Autoren zeigen, dass Wardriving [38] und Scans zur Detektion von Komponenten für Gebäudenetze möglich sind [13]. Granzer et al. haben zudem gezeigt, dass DoS-Angriffe auf automatisierte Gebäude möglich sind [30]. In einer weiterführenden Arbeit zeigten wir zudem diverse netzwerkbasierte DoS-Angriffe für das BACnet-Protokoll [69]. Die Grundidee der Angriffe entspricht dabei oftmals der klassischen Smurf Attack (siehe Abschn. 7.3.3.1): ein Angreifer sendet

10.5 Smart Homes und Smart Buildings

309

eine gespoofte Nachricht mit der Absenderadresse eines Opfers per Broadcast an ein Netzwerk. Das Opfer enthält sämtliche Antworten und muss diese verarbeiten. Bei einer Überlast kommt es schließlich zum DoS. Die Überlast wird dadurch erreicht, dass der Angreifer besonders hochfrequente Nachrichten absendet, die im besten Fall durch die Anzahl der Empfänger im Gebäudenetz (abzüglich Opfer und Angreifer) multipliziert werden. Eine weitere Art von DoS-Angriffen, die ebenfalls in [69] vorgestellt wird, ist der sogenannte Routing-DoS-Angriff. Dabei wird ein Opfergerät als Router ausgegeben (eine Ankündigung des Routers wird bei BACnet ähnlich wie bei ICMP als Broadcast versendet), das gar nicht als Router fungiert und Nachrichten somit gar nicht weiterleiten kann. Ein derartiger Angriff wird oftmals auch als Sinkhole Attack bezeichnet. Auf diese Weise wird erreicht, dass Datenverkehr nicht mehr das Netzwerk verlässt. Der DoS liegt hierbei also in Form einer Isolation eines Netzwerksegments vor. Alternativ kann ein Router für mehr Netzwerke bekanntgegeben werden, als er eigentlich (direkt) erreichen kann, dies kann zu einer Überlast des Routers führen. Gasser et al. stellten in [26] jüngst einen weiteren Angriff vor, bei dem es sich um eine sogenannte Amplification handelt. Dabei werden gezielt kleine Anfragenachrichten versendet, die zur Folge haben, dass die Antwort auf diese Nachrichten deutlich größer ausfällt, als die ursprüngliche Anfrage. Beispielsweise kann mit einer kleinen Anfrage eine ganze Reihe an Messwerten abgefragt werden, die sämtlich in der Antwort enthalten sein müssen. Auch diese Technik kann zu einem DoS führen. Die Autoren führen an, dass bei ihren BACnet-basierten Amplification-Angriffen der Bandwidth Amplification Factor (BAF, manchmal auch Amplification Factor genannt), also das Verhältnis der Größe der Antwort- zur Anfragenachricht, in vielen Fällen zweistellig ausfiel. Der erreichte BAFMaximalwert betrug 120. Ein in den vergangenen Jahren aufkommendes Szenario für die massenhafte Ausnutzung von IoT-Geräten sind IoT-Botnetze. Wir stellten das Szenario bereits 2014 im Kontext der Smart Buildings vor [79]. Smart Building Botnets (SBB) sind Botnetze aus Smart Buildings, die für eine Fülle von Aufgaben herangezogen werden können, darunter etwa das Mining von Bitcoints, das Versenden von SPAM und die Durchführung von DoSAngriffen auf selektierte Ziele. Neben diesen klassischen IT-bezogenen Angriffsszenarien ermöglichen SBB durch ihre cyber-physikalische Natur (dies gilt prinzipiell für sämtliche IoT-Botnetze) jedoch auch weitere Angriffsszenarien, unter anderem [79]: • Ein Angreifer könnte versuchen, den Energiebedarf einer gesamten Region zu steigern. Dazu könnte er beispielsweise Lüftungsanlagen oder Heizungen hochfahren. Ein Unternehmen, das vom Verkauf von Strom, Gas oder Öl lebt, könnte somit seine Umsätze steigern. • Angreifer könnten versuchen, massenhafte Einbrüche in smarten Regionen, also solchen mit besonders vielen Smart Buildings, durchzuführen. Dazu müssten sie die Türsteuerungen beziehungsweise Aktoren von Fenstern manipulieren, um einfachen

310

10 Sicherheit im Internet der Dinge

Zugriff auf Gebäude zu erhalten. Durch Überwachung wäre zudem optimal planbar, wann Bewohner vor Ort sind und wann nicht.7 • Ältere Menschen könnten in Gebäuden eingeschlossen werden. Sie könnten von der Außenwelt abgetrennt und beispielsweise durch eine Ransomware (siehe Abschn. 3.7.1) nur nach Zahlung eines Lösegelds wieder freigelassen werden. Derlei Angriffe wurden bisher noch nicht berichtet,8 was sich jedoch ändern könnte und von der Qualität der IT-Sicherheit der Smart Buildings sowie von der Popularität der verwendeten Komponenten abhängt. Höhere Popularität führt schließlich zu attraktiveren Angriffszielen. Derzeit sind noch zu wenige Eigenheime (aber relativ viele wirtschaftlich genutzte Gebäude) automatisiert, was die obigen Szenarien für Angreifer noch nicht attraktiv genug erscheinen lassen dürfte, um den entsprechenden Aufwand zur Umsetzung von SBB zu forcieren.

10.5.3 Angriffsdetektion und Härtung Sicherheitslücken in Smart Buildings werden bereits seit vielen Jahren diskutiert und schon vor einigen Jahren nahm man an, dass für Smart Homes immer mehr Sicherheitsfunktionen aus anderen Bereichen (etwa klassischen TCP/IP-Netzwerken) übertragen würden [57]. Diese Annahme bewahrheitete sich bereits vor der Integration der Smart Buildings in das IoT, wurde durch selbiges aber unwiderlegbar. Einige Autoren haben internetbasierte Scans durchgeführt, um zunächst in Erfahrung zu bringen, wie viele Smart Buildings überhaupt online erreichbar sind. Diese Scans basierten meist auf der Computersuchmaschine SHODAN. Scans von Gasser et al. [26], Praus et al. [55] sowie Malchow und Klick [48] (ebenfalls 2014) aus verschiedenen Jahren zeigten jeweils fünfstellige Anzahlen an erreichbaren Geräten. Auf der Basis dieser Zahlen ist es wichtig, die Anzahl der online verfügbaren Smart Buildings zu reduzieren, Angriffe detektierbar zu machen und die Geräte nicht durch Unbefugte nutzbar zu machen. In den vergangenen Jahren konnten einige Arbeiten zeigen, dass mithilfe von maschinellen Lernverfahren zumindest unter Laborbedingungen sehr gute Resultate bei der Detektion von Angriffen auf Smart Buildings möglich sind. Tonejc et al. haben etwa diverse Angriffe auf BACnet-Netzwerke detektieren können [72]. Unter den von ihnen analysierten Angriffstechniken sind bestimmte Arten verdeckter Kanäle (nämlich jene aus [78]) sowie BACnet-Pakete mit inkorrekten Bitwerten im Header. 7 Das Szenario ist besonders bei einer homogenen Technikinfrastruktur realistisch. Etwa könnte ein

größerer Bauherr Gebäude in einer Neubausiedlung bauen und dort neben einheitlichen Fenstern und Türen auch ein einheitliches HAS integrieren lassen. Ein Angreifer würde in solch einem Fall nur ein einziges Exploit benötigen. 8 Zumindest nicht in Form von SBB. Beispielsweise wurden allerdings österreichische Hotelgäste aus ihren Zimmern ausgesperrt und das zugehörige Hotel zur Zahlung eines Lösegelds gezwungen.

10.5 Smart Homes und Smart Buildings

311

Für die Härtung von Smart Buildings existieren bisher wenige kommerzielle Lösungen, etwa Firewalls, die spezifisch für entsprechende Netzwerkprotokolle zum Einsatz kommen. Ein positiver Trend zeigt sich allerdings darin, dass Hersteller bestrebt sind, entsprechende Produkte auf den Markt zu bringen. Traffic Normalization (siehe Abschn. 9.3.3 oder [75]) und Intrusion Detection Systems dürften in den nächsten Jahren ebenfalls in Produktform zu erwarten sein. Traffic Normalization adressiert insbesondere Fuzzing-Angriffe, die Protokollinhalte beliebig manipulieren können und so die Interpretation empfangener Daten erschweren, was manche Geräte zum Absturz bringen kann [69]. Für das BACnet-Protokoll konnten Szlósarczyk et al. diverse Regeln aus dem BACnet-Standard extrahieren, die abhängig von verschiedenen Anfragetypen zu Modifikation oder Verwerfung von Datenpaketen führen [69], um etwaige Angriffe zu unterbinden. Traffic Normalization basiert jedoch letztlich auf der Idee, dass Regeln für nichtkonformen Datenverkehr manuell festgelegt werden. Diese Regeln müssen wiederum Entscheidungen beinhalten, wie mit derartigem Datenverkehr umzugehen ist (modifizieren, ignorieren oder verwerfen). Wenn es um reine Überwachung durch ein NIDS geht, also um eine für den Datenverkehr konsequenzenlose Überprüfung, dann kann diese manuelle Festlegung von Regeln auch automatisiert werden: Caselli et al. konnten zeigen, dass die Festlegung von Normalverhalten für spezifikationsbasierte Intrusion Detection für Gebäude-Kommunikation (zumindest für BACnet) automatisiert erfolgen kann [13]. Ihr Ansatz arbeitet anhand einer Pipeline, die zunächst Daten über die Netzwerkumgebung sammelt. Anschließend werden weitere Informationen über gefundene Geräte gesammelt, auf Basis von Dokumentationen und Konfigurationsdateien. Im Folgeschritt werden auf Basis der gesammelten Informationen Regeln für ein spezifikationsbasiertes NIDS definiert; diese Regeln können etwa abhängig vom Gerätetyp definiert werden, da die Gerätetypen im ersten Schritt identifiziert wurden. Mithilfe dieser Regeln kann das NIDS schließlich arbeiten und Alarme generieren. Open Source Software wie der BACnet Firewall Router (BFR) sind für den Praxiseinsatz zu wenig ausgereift und stehen nicht in Verbindung mit Supportverträgen. Es ist allerdings wichtig, dass es derartige freie Projekte gibt. Positiv zu bewerten ist zudem der Trend, dass Verschlüsselung für die Netzwerkprotokolle im HAS- und BAS-Bereich eine zunehmende Rolle spielt. Auch hier ist zu erwarten, dass entsprechend neue Produkte auf den Markt kommen werden. Im Jahr 2016 wurde beispielsweise das erste Security Gateway zur sicheren Verbindung (VPN) von BACnet-Installationen vorgestellt. Akademische Ansätze zur Adressierung der Nachrüstung von Bestandssystemen existieren bereits seit Jahren (siehe Abschn. 10.7). Ein von Glanzer et al. vorgestellter Ansatz für die Sicherung KNX-basierter Kommunikation vor Manipulation und Hardwareausfällen besteht darin, das KNX-Netzwerk in sichere und unsichere Segmente zu gliedern. Die unsicheren Netzsegmente sind wiederum mit sicheren Routern miteinander verbunden (sogenannte KNX Security Router) [27]. Zwischen den Routern erfolgt eine kryptografisch gesicherte Kommunikation, während in den unsicheren Netzwerksegmenten traditionelle, unverschlüsselte KNX-Kommunikation

312

10 Sicherheit im Internet der Dinge

verwendet wird. Die Kommunikationsverbindungen zwischen den KNX Security Routern sind redundant ausgelegt. Durch diese Redundanz kann wiederum einem Hardwareausfall vorgebeugt werden [27]. Selbstverständlich können auch hostbezogene Ansätze zur Angriffsprävention und -detektion eingesetzt werden, etwa restriktive Zugriffsrechte und Sandboxing [31].

10.6

Industriesteueranlagen (Industrial Control Systems)

Anlagen zur industriellen Steuerung (engl. Industrial Control Systems, ICS) sind automatisierte, vernetzte Systeme, die in Produktion, Logistik und Anlagenbetrieb zum Einsatz kommen. Sie beinhalten elektrische und mechanische Komponenten und setzen komplexe Prozesse um, die von Menschen überwacht werden [41]. Anwendungsgebiete sind etwa die Erzeugung chemischer Stoffe, die Herstellung von Medikamenten und die Produktion von Waren mithilfe von Robotern und Produktionsstraßen. Weitere typische Anwendungsgebiete sind die Aufbereitung von Trinkwasser und automatisierte Lagerung von Gütern in Lagerhallen. Ein bedeutendes Einsatzgebiet von ICS stellt zudem die Energieversorgung dar. Zum Einsatz kommen dabei oft Supervisory Control And Data Acquisition-Systeme (SCADA-Systeme), einem besonders weit verbreitetem ICS-Typus. Ähnlich wie automatisierte Gebäude verfügen auch ICS über eine hierarchische Struktur. Gesteuert von einer Leittechnik werden die unteren Ebenen überwacht und kontrolliert. Kernelemente sind dabei insbesondere: • Sensoren und Aktoren sind, wie bei der Gebäudeautomation, die zu steuernden und zu überwachenden Elemente. Allerdings sind die Typen von Sensoren und Aktoren im Kontext der ICS deutlich heterogener. So werden für die Herstellung von Brötchen oder Medikamenten andere Sensoren benötigt als bei der Herstellung von TV-Geräten. Weiterhin gibt es Unterschiede bei den Anforderungen an die Echtzeitfähigkeit von Sensoren/-Aktoren – man denke etwa an einen nur leicht verzögert agierenden Schweißroboter. • Speicherprogrammierbare Steuerungen (engl. Programmable Logic Controllers, PLCs). Diese Komponenten sind ähnlich den DDCs aus der Gebäudeautomation und erlauben die Steuerung und Überwachung von Feldkomponenten. An diese Komponenten werden Aktoren und Sensoren angeschlossen. • Human Machine Interfaces (HMIs) dienen der Visualisierung und Konfiguration von industriellen (Teil-)Prozessen. Sie können etwa visuell aufbereiten, wie viel Wasser in einem Tank ist, und können dazu dienen, ein Ventil per Befehl zu öffnen. Neben diesen Komponenten gibt es weitere, etwa Gateways und Remote Terminal Units (RTUs) für die Verbindung mit anderen (entfernten) Netzwerken. Der Autor verzichtet

10.6 Industriesteueranlagen (Industrial Control Systems)

313

allerdings auf die Darstellung dieser Komponenten, da sie für das weitere Verständnis des Abschnitts nicht von zentraler Bedeutung sind. Klassische Netzwerkprotokolle aus dem ICS-Bereich sind Modbus, Ethernet und PROFINET (insbesondere eine echtzeitfähige Variante), EtherCAT und POWERLINK.

10.6.1 Angriffe Evancich und Li berichten, dass der erste bekannt gewordene Angriff auf ein ICS bereits im Jahr 1982 stattfand; damals wurde ein Trojanisches Pferd verwendet, um eine Logic Bomb in ein sibirisches SCADA-System einzuschleusen, was zu einer Explosion führte und eine Pipeline stilllegte [21]. In den vergangenen Jahren gab es immer wieder Angriffe auf ICS, die auch in den internationalen Medien Betrachtung fanden. Darunter die ausgefeilte Stuxnet-Schadsoftware (2008/2009), die Zentrifugen der iranischen Urananreicherung angriff, indem sie dort verbaute Komponenten der Firma Siemens manipulierte [21]. Insbesondere war Stuxnet darauf ausgelegt, durch möglichst unmerkliche Druck- und Motorrotationsveränderungen an den Zentrifugen für regelmäßige Störungen zu sorgen und konnte sich sowohl über das Internet wie durch USB-Sticks verteilen [40]. Bekannt wurden auch die beiden Schadsoftware-Programme Duqu und Flame, die ebenfalls so hochgradig ausgefeilt sind wie Stuxnet. Für die Entwicklung derartiger Schadsoftware bedarf es eines immensen Know-hows sowie des Einsatzes größerer Geldmittel. Bekannt wurden zudem Angriffe auf die ukrainische Energieversorgung [39]. Angriffe auf ICS müssen unterschiedlich charakterisiert werden. Während Vandalismus kein besonderes Know-how, sondern nur das blinde Verändern von Anweisungen eines ICS notwendig macht, ist bei gezielten Manipulationen industrieller Prozesse ein umfassendes Know-how der jeweilig eingesetzten Technologie und seiner Sicherheit sowie der physikalisch-chemischen Prozesse notwendig. Eine gezielte Manipulation, etwa bei der Herstellung einer Haftcreme zur latenten Reduktion der Haftwirkung, ist entsprechend fernab der Möglichkeiten eines Script Kiddies und benötigt ausgefeiltes Know-how. Angriffe auf Industriesteueranlagen können entweder die Leittechnik, oftmals sind dies windowsbasierte PCs, und sämtliche sonstige Komponenten des ICS betreffen. Dabei ist anzumerken, dass auch auf HMIs oft ein typisches Betriebssystem wie Windows läuft und ggf. eine relativ hohe Anzahl offener Ports vorliegt [19] (tendenziell nimmt dieses Problem seit einigen Jahren ab), die es durch Deaktivierung von Diensten beziehungsweise durch Firewalls zu schützen gilt. Angreifer können versuchen, jeden dieser Ports für einen Angriff zu nutzen und werden entsprechend zunächst horizontale und gegebenenfalls vertikale Scans durchführen. Vorgeschaltet werden können die klassischen Reconnaissance-Angriffe, wie sie in vorherigen Kapiteln dargelegt wurden. Weiterhin ergeben sich diverse klassische Manipulationsmöglichkeiten, das heißt solche, bei denen Verbindungen durch Sniffing überwacht, durch Resets abgebrochen oder durch Spoofing und Hijacking manipuliert werden, womit die entsprechenden MitM-Szenarien einbegriffen sind. Derlei Angriffe wurden bereits für alle bedeutsamen

314

10 Sicherheit im Internet der Dinge

Protokolle erprobt und publiziert [83]. Sicherere Varianten der bisherigen Protokolle – etwa Secure Modbus [25] anstelle von Modbus – sind hingegen deutlich weniger anfällig für derlei Angriffe. Interessant ist allerdings der für ICS besondere Umstand, dass durch derlei Angriffe auch falsche ICS-Zustände vorgetäuscht werden können: Ein Angreifer sendet gespoofte Daten an ein HMI/Control Terminal beziehungsweise manipuliert er die Kommunikation zwischen anderen Geräten und dem HMI als MitM [39]. Durch seine Manipulation überschreibt er die eigentlich korrekten Zustandsdaten (Sensordaten, Aktorzustände), womit er erreicht, dass die auf dem HMI dargestellten Inhalte falsch sind. Das so manipulierte HMI täuscht dem Operator einen für ihn akzeptablen Ablauf der ICS-Prozesse vor; er vermutet aufgrund dieser Darstellung folglich keine derzeit stattfindende Manipulation. Angemerkt sei an dieser Stelle, das neben der Anzeige der vornehmlich aktuellen Situation durch HMIs auch historische Daten visualisiert werden können, sogenannte Trendlogs. Diese werden entweder in Datenbanken oder in den verschiedenen Geräten selbst gespeichert, sofern diese über die entsprechende Funktion und Speicherkapazität verfügen. Ein Angreifer kann prinzipiell auch versuchen, Bestände historischer Daten zu manipulieren [84]. Ein mögliches Szenario hierfür ist die Beeinflussung einer Anomalieerkennung, die auf Basis historischer Werte arbeitet; wenn die historischen Werte bereits gefälscht sind, wird ein neuer anomaler Wert unter Umständen nicht als solcher erkannt. Eine weitere Angriffstechnik ist das Protocol Fuzzing (Abschn. 6.2.3), das dazu führen kann, dass Komponenten empfangene Daten nicht korrekt handhaben können. Im schlimmsten Fall führen sie fehlerhafte Aktionen aus oder stürzen ab. Ein daraus folgender DoS ist im ICS-Kontext besonders schwerwiegend, da sämtliche Komponenten in Echtzeit arbeiten müssen und beispielsweise ein zu hoher Rohrdruck, auf den aufgrund eines Fehlers nicht reagiert wird, zum Platzen des Rohrs (und entsprechenden Folgeschäden für Mensch, Umgebung und Maschine) führen könnte. Bei einem sogenannten Downgradeangriff spielt ein Angreifer eine veraltete und zugleich verwundbare Firmwareversion in eine ICS-Komponente ein [60]. Ein Downgradeangriff kann am einfachsten vor Ort über eine oft serielle Schnittstelle, das heißt durch interne Angreifer, durchgeführt werden.

10.6.2 Angriffsdetektion und Härtung Klassischerweise können die in Abschn. 10.5.3 genannten Detektions- und Härtungsmethoden aus dem Bereich der automatisierten Gebäude in gleicher oder ähnlicher Form auch bei ICS angewandt werden, mit zum Teil jedoch unterschiedlichen Protokollen. Ein fundamentaler Unterschied besteht in der Echtzeitfähigkeit9 von ICS, die bei Smart

9 Mit IEC 61850 gibt es etwa einen Standard, der Anforderungen an die Latenz für den Datenverkehr festlegt.

10.6 Industriesteueranlagen (Industrial Control Systems)

315

Buildings nicht von großer Bedeutung ist. Wenn hingegen bei einer chemischen Fabrik nicht permanent auf die Korrektheit von sämtlichen Prozesskomponenten und -werten geachtet wird, so kann sich dies unter Umständen besonders folgenreich auswirken. Das einfache Filtern von Nachrichten durch eine Firewall sowie das sonstige Beeinflussen von ICS-Prozessen ist somit nicht machbar und muss äußerst bedacht erfolgen. Es ist eine gute Lösung, ICS zu isolieren und sie dadurch zumindest vor netzwerkseitigen Gefahren zu schützen. Dies ist allerdings nicht immer in der Praxis realisierbar oder würde den Nutzen von Teilkomponenten zum Teil drastisch reduzieren. Ich möchte diese Aussage durch ein Beispiel illustrieren. Ein Transportunternehmen, das Schienenverkehr betreibt, könnte Leittechnik einsetzen, die Zügen signalisiert, ob sie fahren dürfen oder ob sie halten müssen. Wenn derartige Signale über ein Netzwerk, etwa GSM oder UMTS, angebunden sind, sind sie über dieses Netzwerk potenziell auch angreifbar. Eine Isolation hätte hier allerdings zur Folge, dass die Signale nicht mehr remote steuerbar wären. Dies wiederum lässt die Signale an sich wiederum aus Sicht des Betreibers wertlos werden. Entsprechend müssen praxistaugliche Alternativen zur Isolation gefunden werden. Ein Ansatz könnte das sogenannte Zoning sein [5], bei dem keine vollständige Isolation angestrebt wird, aber ein komplexes System zumindest in Teilsysteme aufgeteilt wird; die Interaktion zwischen den Systemen wird minimiert. Oman et al. geben ein paar grundlegende, aber für die Praxis nützliche Hinweise dazu, wie mit ICS umgegangen werden kann, indem etwa bestimmte Vorgaben zur Verwaltung von Passwörtern und zur Handhabung von Alarmen verschiedener Art (etwa erfolglose Loginversuche) eingehalten werden sollten [54]. Eine verbreitete Methode, um Informationen über Angriffstechniken im ICS-Bereich zu sammeln, sind Honeypots (siehe Abschn. 6.3.3). Diverse solcher Honeypots wurden vorgestellt, etwa Lau et al. [43]. Sie liefern nicht nur Informationen über das Vorgehen von Angreifern, sondern auch darüber, welche Interessen Angreifer verfolgen und ob die Anzahl der Angriffe derzeit steigt, sinkt oder unverändert bleibt beziehungsweise auf welchem quantitativen Niveau sich die Anzahl der Angriffe für den Betreiber überhaupt bewegt. Neben Honeypots existieren selbstverständlich auch für Industriesteueranlagen Intrusion Detection Systeme [84]. Sie können etwa Anomalien in der Protokollkommunikation oder signaturbasiert Angriffsdaten erkennen (zum Beispiel Erkennung von fehlgeschlagenen Loginversuchen); eine hervorragende Zusammenfassung von IDS-Ansätzen findet sich in [84]. Der Überprüfung der IT-Sicherheit von ICS und der Erprobung neuer Angriffsverfahren dienen ICS Security Testbeds. Diese Testbeds sind weit verbreitet und erlauben Universitäten, Forschungseinrichtungen und Unternehmen die Überprüfung von neuen Komponenten, bevor sie in eigentliche, sensitive ICS-Umgebungen integriert werden. Bestandteil solcher Testbeds kann etwa Protocol Fuzzing sein. Security Testbeds finden sich auch für die Gebäudeautomation und andere IoT-Bereiche. Eine der vielen Schlüsselrollen solcher Testbeds spielt die Homogenität des Equipments [32]. Während Komponenten desselben Herstellers mit höchster Wahrscheinlichkeit hervorragend miteinander interagieren, sind

316

10 Sicherheit im Internet der Dinge

bei Komponenten unterschiedlicher Hersteller und ggf. bei unterschiedlichen Firmwareversionen und Konfigurationsparametern bereits Probleme denkbar. Langzeittests von neuem Equipment, bei denen dieses neue Equipment unter simulierten Bedingungen mit bereits verbauten Komponenten arbeiten muss, können helfen, derlei Probleme zu erkennen. Ein Ausfall einer neuen Komponente würde schließlich bereits die Verfügbarkeit, und damit ein Schutzziel der IT-Sicherheit beeinflussen. Außerdem wichtig sind ausführliches Logging und eine gute Dokumentation des Testbeds samt sämtlicher darin ablaufender Prozesse und Tests [32]. Eine hervorragende Zusammenstellung von zu beachtenden Aspekten beim Aufbau und Betrieb von ICS Security Testbeds bieten Green et al. [32]. Ein hingegen der Detektion und dem Schutz dienender Ansatz von Malchow et al. nennt sich PLC Guard [49]. PLC Guard ermöglicht es den Operatoren und Ingenieuren, sämtlichen Code, der auf eine PLC übertragen wird, zunächst zu überprüfen und mit vorhandenen Versionen zu vergleichen. Dieser Ansatz kann dabei helfen, Downgradeangriffe zu entdecken und zu verhindern, da nur explizit akzeptiere Änderungen eingespielt werden.10 Ähnliche Lösungen bieten auch Systeme von einigen deutschen Unternehmen. Wie bei automatisierten Gebäuden ist auch bei ICS der Einsatz von Traffic Normalization denkbar, um insbesondere Protocol Fuzzing zu unterbinden. Eine weitere Ähnlichkeit ist, dass es auch bei ICS die Möglichkeit der automatisierten Generierung von Regeln für spezifikationsbasierte NIDS gibt. Allerdings ist hierbei bei Produktivumgebungen eine manuelle Anpassung von Regeln an die Parameter der Umgebung notwendig [13].

10.7

Stand der Verwendung von Kryptografie IoT-Protokollen

Es existieren verschiedene Ansätze, um Verschlüsselung und Authentizität in Automationsnetzen und im Rahmen von Nahfeldkommunikation (NFC, etwa für Wearables) zu realisieren. Die Mehrzahl der verwendeten Protokolle arbeitet – zumindest in der Praxis – ohne nennenswerte Sicherheitsfunktionen, mit alten Sicherheitsfunktionen, oder definiert neue Funktionen nur in Standards, die noch nicht in der Praxis umgesetzt sind. Ein interessanter Ansatz zur Entwicklung sicherer KNX/EIB-Kommunikation war EIBSec (entwickelt von der TU Wien) [29]. Hierbei wird Datenverkehr mithilfe von AES verschlüsselt. Außerdem gibt es ein Key Management Protokoll zum Generieren und Austauschen von Schlüsseln (auch Gruppenschlüssel werden unterstützt). Ebenfalls wird eine kryptografische Authentifizierung ermöglicht. Das ursprüngliche KNX-Protokoll (sowie sein Vorgänger EIB) konnten derlei Funktionen nicht aufweisen. Es existieren zwei Modi in EIBSec: der „Normal Mode“ (paketweise AES-Verschlüsselung) wird während

10 Voraussetzung für die Detektion und Verhinderung eines Downgradeangriffs ist natürlich die

tatsächliche Erkennung der nicht-legitimen Veränderungen durch einen Ingenieur/Operator. Ob auch subtile Angriffe, etwa der Einbau von Seitenkanälen, durch solche Systeme erkennbar sind, ist dem Autor nicht bekannt.

10.7 Stand der Verwendung von Kryptografie IoT-Protokollen

317

des Aufbaus von Sessions und während einer Gruppenkommunikation verwendet. Der „Counter Mode“ verrechnet zusätzlich einen Counter (128 Bit) mit in sämtliche Daten, damit Replay-Angriffe unterbunden werden können. Angemerkt sei an dieser Stelle allerdings die Tatsache, dass das Schlüsselmanagement im IoT-Kontext eine Herausforderung darstellen kann. Wang und Nikolai weisen, wie einige Autoren vor ihnen, darauf hin, dass durch die Heterogenität von Komponenten die Verwendung einheitlicher kryptografischer Verfahren erschwert wird, etwa aufgrund der begrenzten Rechenleistung integrierter Prozessoren [74]. Auch weisen die Autoren darauf hin, dass die Echtzeit-Anforderungen mancher Cyber-physikalischer Systeme zur Folge haben, dass sich auch das Schlüsselmanagement diesen Anforderungen beugen, also innerhalb festgelegter Zeitschranken agieren muss. Da derlei Echtzeitanforderungen auch während einer Angriffsphase eingehalten werden müssen, und auch das Schlüsselmanagement während eines Angriffs nicht ausbleiben darf, muss dieses zudem eine Resilienz gegenüber Angriffen aufweisen.11 Die Autoren führen weiter an, dass durch die Heterogenität von CPS-Komponenten möglicherweise auch Probleme auftreten, wenn das Schlüsselmanagement der CPS-Komponenten nicht interoperabel ist. Weiterhin ist auch die Überlebensfähigkeit (engl. Survivability) des Equipments bedeutsam. Dieser auf Cárdenas et al. zurückgehende Begriff ist so zu verstehen, dass CPS ihre Zielvorgaben dynamisch reduzieren und anpassen können, wenn sie attackiert werden, um somit zumindest ihre Kernaufgaben zu erfüllen [12, 74].12 Survivability sollte laut Wang und Nikolai auch die Aufgaben der Schlüsselverwaltung beinhalten [74]. Wichtige Aspekte des Schlüsselmanagements sind dabei die Berechnungszeiten, die vom jeweiligen Algorithmus und von der Schlüssellänge abhängen, sowie der Bedarf an Energie, der bei Verwendung der Algorithmen samt Schlüssel entsteht [74]. Letzterer Aspekt ist insbesondere bei batterie- und solarpanelbetriebenen IoT-Komponenten von zentraler Bedeutung. Im Zuge der erwähnten Ressourcenbeschränktheit von IoT-Equipment und den daraus hervorgehenden Anforderungen an Kryptografie (Beanspruchung von wenig Rechenleistung und Energie) gibt es verschiedene Ansätze, die unter dem Begriff leichtgewichtige Kryptografie (engl. Lightweight Cryptography, LWC) zusammengefasst werden: Verschiedene kryptografische Algorithmen – etwa für Signaturen oder für symmetrische Verschlüsselung – werden so konzipiert beziehungsweise abgeändert, dass sie in möglichst kurzer Zeit und möglichst auf Dauer auf IoT-Equipment mit wenigen Ressourcen lauffähig sind. Ein Optimierungsproblem besteht dabei zwischen dem erzielten Niveau

11 So kann ein Angreifer etwa versuchen, PKI-Komponenten mit DoS-Angriffen zu beeinflussen

und ein resilientes System könnte infolge dessen wiederum so ausgelegt sein, dass es die Frequenz der Nachrichten für die Schlüsselkommunikation reduziert oder das Schlüsselmanagement sogar temporär aussetzt; dies wiederum könnte jedoch genau das Ziel des Angreifers sein [74]. 12 Die Definition des Begriffs aus der ursprünglichen Publikation lautet wie folgt: Survivability is the ability of the CPS to maintain or provide graceful-degradation of CPS operational goals when under attack [12].

318

10 Sicherheit im Internet der Dinge

an Sicherheit, der Performance und den Funktionalitäten. Ein längerer kryptografischer Schlüssel führt etwa dazu, dass eine Berechnung länger dauern kann, bringt aber in der Regel auch ein Mehr an Sicherheit. Wenn man bedenkt, dass, wie Tawalbeh und Tawalbeh berichten, 98,8 % aller hergestellten Mikroprozessoren im Embedded-Bereich eingesetzt werden, erschließt sich die Bedeutung von LWC [70].13 Beispiel für Sicherheit in Automationsnetzwerken: Das zuvor erwähnte ModbusProtokoll kommt sowohl bei automatisierten Gebäuden als auch bei Industriesteueranlagen zum Einsatz. Es kann nur simple Aktionen durchführen, nämlich das Lesen von Werten und Setzen von Werten auf über das Netzwerk erreichbaren Automationskomponenten. Beispielsweise kann ein Aktor einen Wert erhalten, den er annehmen soll, oder ein Sensorwert ausgelesen werden. Modbus bietet an sich keine Sicherheitsfunktionen. Es ist verwundbar gegenüber Replay-Angriffen, DoS-Angriffen und Manipulationen durch vom Angreifer selbst gewählte Befehle sowie MitM-Angriffen [25]. Die verbesserte Version Secure Modbus [25] stellt hingegen IPSec AH-ähnliche Funktionen bereit und erlaubt es dadurch, die Integrität und Authentizität übertragener Daten zu gewährleisten. Außerdem werden Nicht-Abstreitbarkeit und Replay-Schutz umgesetzt. Technisch wurde die Erweiterung von Modbus zu Secure Modbus relativ einfach umgesetzt. Dazu wird der Original-Modbusheader mit einem Timestamp versehen: Header := Timestamp || Originalheader An den Header wird wiederum eine SHA-2-Prüfsumme angehängt, die mit dem privaten RSA-Schlüssel Kpriv des Senders verschlüsselt wird: Header || E(Kpriv , SHA2(Header)) Der Angreifer kann ohne den privaten Schlüssel des Senders keine Nachrichten von diesem mit korrektem Hashwert spoofen, er kann sie zudem nicht verändern. Ein erneutes Senden abgefangener Nachrichten ist durch den dann veralteten Timestamp ebenfalls nicht möglich [25]. Bei den meisten neuen Standardversionen von Protokollen wie KNX, BACnet, ZigBee und EnOcean sind Verschlüsselungsverfahren bereits vorgesehen und zudem sind kryptografische Methoden im Einsatz, die die Authentizität von Daten und Replay-Schutz gewährleisten. Fast alle bedeutsamen Protokolle setzen dabei auf AES (in verschiedenen Modi) sowie auf eine AES-basierte Authentizitätsüberprüfung. Bei Funkprotokollen wie ZigBee und EnOcean ist die Verwendung der entsprechenden Funktionen einfacher gestaltet [80] und oftmals standardmäßig aktiviert; bei BACnet, KNX, LON und Co. besteht das erwähnte Problem der Kompatibilität mit Altequipment.

13 Selbstverständlich benötigen nicht alle Embedded-Prozessoren zwangsläufig LWC.

10.8 Generische IoT-Protokolle der Anwendungsschicht

319

Die meisten modernen Protokolle, etwa ZigBee und Bluetooth, sind im Laufe der letzten Jahre noch einmal deutlich sicherer geworden, als sie bereits waren. Diverse grundlegende Sicherheitsprobleme wurden bereits in den ersten Jahren der Protokollveröffentlichungen adressiert. Zwar werden immer wieder Angriffe auf Teilkomponenten dieser Protokolle bekannt (siehe etwa [68]), doch werden diese in neuen Standardversionen behoben.

10.8

Generische IoT-Protokolle der Anwendungsschicht

Während die bisher erwähnten Protokolle (BACnet, KNX, Modbus und Co.) spezifisch für den Einsatz in Automationsumgebungen – teilweise sogar spezifisch für die jeweilige Automationsdomäne – sind oder eine Low-level-Kommunikation für IoT-Geräte bereitstellen, werden im Folgenden einige generische IoT-Protokolle betrachtet, die auf der Anwendungsschicht arbeiten. „Generisch“ bedeutet in diesem Zusammenhang, dass diese Protokolle in diversen Bereichen des IoT zum Einsatz kommen können. Diese Protokolle wurden im Gegensatz zu den obig erwähnten auch nicht aus historischen Protokollstandards für die Gebäudeautomation oder Industriesteueranlagen heraus entwickelt, sondern explizit für eine breite Nutzung im IoT konzipiert.

10.8.1 CoAP Das Constrained Application Protocol (CoAP) wurde in RFC 7252 beschrieben [63]. Es handelt sich dabei um ein Protokoll der Anwendungsschicht, dass für ressourcenbeschränkte Geräte (wenig Rechenleistung, wenig Speicher, eingeschränkte Energieversorgung) entwickelt wurde und in UDP eingekapselt wird. Aus diesem Grund hat es einen kompakten Header. Da es für möglichst viele Einsatzszenarien des IoT dienen soll, ist es wiederum generisch aufgebaut. CoAP ermöglicht das automatische Interagieren zwischen IoT-Equipment. CoAP-Clients können zudem selbständig Dienste und Ressourcen in einem IoT-Netzwerk auffinden. Da viele IoT-Anwendungen auf dem Web basieren beziehungsweise mit dem Web interagieren und das Web auf HTTP aufsetzt, wurde CoAP so entworfen, dass es mit dem HTTP-Protokoll über eine Proxy-Funktion interagieren kann. CoAP kann analog auch an XMPP und SIP angebunden werden.

10.8.1.1 Auffinden von Diensten Wie erwähnt kann CoAP Dienste und Ressourcen finden, was insbesondere für Machineto-Machine Interaction (M2M) bedeutsam ist, da ein Client auf diese Weise automatisch herausfinden kann, welche Ressourcen und Dienste auf einem Server angeboten werden [63]. Das Finden von Diensten kann auf zwei Wegen erfolgen:

320

10 Sicherheit im Internet der Dinge

1. Zum einen über die Verbreitung von coap(s)-URIs (also Adressen, die ähnlich zu HTTP-URIs sind). Diese Adressen folgen dem Aufbau “coap://” host [ “:” port ] path-abempty [ “?” query ]. Während die Angabe des Hosts und des Ports selbsterklärend sind, steht der Platzhalter path-abempty für die Angabe eines Pfades, der entweder mit / beginnt, also etwa /ressource, oder leer ist. Optional kann an den Pfad, getrennt durch ein Fragezeichen, eine Anfrage (query) angehängt werden. Der Aufbau der Query und ihrer Bestandteile ist in RFC 3986 detailliert beschrieben [4]. 2. Zum anderen kann das Finden von Diensten über eine Suche erfolgen. Ein Host scant dabei nach CoAP-Diensten, die sich im Netzwerk befinden. Üblicherweise läuft CoAP auf Port 5683 und per Multicast können CoAP-Clients Anfragen an die Teilnehmer einer solchen Gruppe senden. Durch die Antwortnachrichten der Server erfahren die Clients letztlich auch, welche Server verfügbar sind. Das Auffinden von Ressourcen auf einem Server erfolgt wiederum über ein spezielles Datenformat namens Constrained RESTful Environments (CoRE) Link Format, das in RFC 6690 spezifiziert ist [62].

10.8.1.2 Der CoAP-Header Der CoAP-Header (siehe Abb. 10.2) folgt einem relativ simplen Aufbau. Die ersten zwei Bit (Vers.) geben die Version an. Gemäß RFC 7252 muss der Wert in diesem Feld 1 sein. Die nächsten zwei Bit geben den Nachrichtentyp (Type) an. Es gibt folgende Möglichkeiten: (0) confirmable-Nachricht, das heißt, die Nachricht muss eine Anfrage oder eine Antwort sein, die vom Empfänger mit einer Bestätigungsnachricht quittiert oder mit einem Reset abgelehnt wird; (1) non-confirmable-Nachricht, das heißt, es handelt sich um eine Nachricht, die keine Bestätigung verlangt (dennoch ist Bestätigung nicht ausgeschlossen), (2) acknowledgement-Nachricht, das heißt, dass diese Nachricht eine Bestätigung für eine andere Nachricht ist, und (3) reset-Nachricht, das heißt, die empfangene Nachricht konnte – etwa aufgrund eines Reboots des Empfängers – nicht verarbeitet werden [63]. CoAP-Nachrichten können Token übertragen. Token dienen der Zuordnung von Antworten zu Anfragen. Das von einem Client an den Server geschickte Token muss in einer Antwort des Servers unmodifiziert vorkommen. Die Länge eines Tokens (Token Len.) wird

Abb. 10.2 Der CoAP-Header

10.8 Generische IoT-Protokolle der Anwendungsschicht

321

durch die Bits 4–7 der Nachricht angegeben (in Bytes; derzeit sind nur die Längen 0–8 Bytes erlaubt [63]). Wenn die Länge nicht Null ist, dann ist ein Token der angegebenen Länge ab Bit 32 der Nachricht eingebaut. Andernfalls entfällt das Token-Feld. Der Code einer Nachricht besteht aus acht Bits. Die ersten drei Bits geben die Nachrichtenklasse (Class), die nächsten fünf Bit das Detail an [63]. Erlaubte Nachrichtenklassen sind die folgenden: (0) Anfrage, (2) Antwort im Sinne einer Erfolgsmeldung, (4) Antwort im Sinne einer Fehlermeldung des Clients (etwa Syntaxfehler), (5) Antwort im Sinne einer Fehlermeldung des Servers. Üblicherweise werden die ersten drei Bits als Dezimalzahl getrennt von den letzten fünf Bits (ebenfalls als Dezimalzahl) dargestellt, also in der Form c.dd. Die Codes ähneln auf diese Weise den HTTP-Codes, beinhalten jedoch auch Anfragetypen. In HTTP steht etwa der Code 404 für „Not found“ und 403 für „Zugriff verweigert“. In CoAP entspricht dies den Code-Detail-Kombinationen 4.04 und 4.03. Allerdings spiegeln nicht alle CoAP-Codes entsprechende HTTP-Codes wider. Für Anfragen haben die Codes hingegen eine führende Null. So steht 0.01 etwa für eine GETAnfrage und 0.02 für eine POST-Anfrage. Diese sind analog zu HTTP zu verstehen. Eine vollständige Liste der erlaubten Codes gibt die IANA in jeweils aktueller Version online heraus [36]. Die Message ID dient der Detektion von Duplikaten (falls Nachrichten doppelt gesendet wurden). Weiterhin dient sie dazu, Bestätigungsnachrichten ursprünglichen Anfragen zuordnen zu können (confirmable-Nachrichten). Die Message ID erscheint zunächst redundant, da doch Token bereits dazu gedacht sind, Antwortnachrichten den ursprünglichen Anfragen zuzuordnen. Dies ist bei näherer Betrachtung jedoch nicht der Fall. CoAP macht eine feine Unterscheidung zwischen Bestätigungs- und Antwortnachrichten. Im einfachsten Fall sendet ein Client eine Nachricht an einen Server. Daraufhin sendet der Server eine Nachricht an den Client, in der er die empfangene Nachricht bestätigt und beantwortet. Dies nennt sich piggybacked response. Alternativ ist es allerdings auch möglich, zunächst den Empfang einer Nachricht zu bestätigen und in einer separaten Nachricht die eigentliche Antwort auf die Anfrage zu liefern. Hierin zeigt sich die asynchrone Operationsweise von CoAP. RFC 7252 nennt auch ein Szenario für einen ansynchronen Fall: Wenn der Server für die Beantwortung einer Anfrage vermutlich viel Zeit benötigen wird, dann kann er den Empfang einer Nachricht zeitnah bestätigen, sodass der Client weiß, dass der Server seine Anfrage bearbeitet. Erst dann, wenn der Server die für die Erstellung der Antwort notwendigen Operationen durchgeführt hat, sendet er in einer separaten Nachricht seine Antwort. Dieses Vorgehen kann verhindern, dass der Client seine Anfrage wiederholt, obwohl der Server bereits mit der Bearbeitung der Anfrage beschäftigt (ausgelastet) ist [63]. Hinter dem Token-Wert können Optionen eingebaut werden [63]. Mit diesen Optionen können insbesondere Anfragen verfeinert werden, indem etwa Bedingungen hinzugefügt werden. Zum Beispiel kann die Option Max-Age verwendet werden, um Ressourcen nur unter der Bedingung abzufragen, dass die zugehörigen Werte nicht zu alt sind. Wenn etwa die aktuelle Raumtemperatur abgefragt werden soll, der Wert aber bereits 30 Minuten alt ist, dann ist dieser Wert für den Client unter Umständen nicht mehr

322

10 Sicherheit im Internet der Dinge

relevant. Mit den Optionen Location-Path und Location-Query können URIs (siehe oben) verwendet werden, um Ressourcen anzugeben. Mit der Block-Option können zudem größere Datenmengen, etwa Firmwareupdates, übertragen werden [9]. Eine vollständige Liste der momentan spezifizierten Optionen findet sich bei der IANA [36]. Beispiel (Luftdrucksensor) Ein CoAP-Client könnte zum Beispiel eine Ressource abfragen, die unter der URI coap://server.example.xyz/luftdruck verfügbar ist. Zunächst verbindet sich der Client mit dem Server server.example.xyz, der in diesem Szenario auf einem Luftdrucksensor läuft. Der Client würde für diese Nachricht den Code für eine GET-Abfrage (0.01) verwenden und dazu die Ressource /luftdruck angeben. Zudem würde der Client ein Token mit dem Wert x vergeben. Der Server würde auf diese Anfrage mit demselben Token x antworten und – im Erfolgsfall – mit dem CoAP-Code 2.05 („Content“) und dem entsprechenden Messwert des Luftdrucksensors.

10.8.1.3 Sicherheit von CoAP Ein grundlegendes Problem von CoAP sind Angriffe, die durch IP-Spoofing erfolgen. Der CoAP-Standard nennt in diesem Zusammenhang unter anderem die folgenden Szenarien [63]: 1. Angreifer können Reset-Nachrichten spoofen, um CoAP-Anfragen zu terminieren. 2. Angreifer können Bestätigungen für Anfragen des Typs Confirmable und NonConfirmable spoofen. Dies kann den Sender der Antwort davon abhalten, Nachrichten erneut zu senden und den Empfänger wiederum davon abhalten, die eigentliche Antwort auszuwerten. 3. Außerdem ist es möglich, künstliche Antworten (auf nicht gestellte Anfragen) zu stellen. Ähnlich dem DNS Cache Poisoning sind Angriffe denkbar, die Caches von CoAP-Proxyservern mit Falschinformationen befüllen. 4. Wenn Multicast-Anfragen gespooft werden, so erhält ein Opfer unter Umständen eine sehr hohe Zahl von Antworten, was wiederum zu einem DoS führen kann. IP-Spoofing kann dadurch erkennbar sein, dass Tokens nicht zu den tatsächlich zuvor vergebenen Tokens passen. Allerdings muss hierzu sichergestellt sein, dass für Nachrichten keine PRNGs verwendet werden, die schlecht vorhersagbare Tokens generieren. Dieses Verfahren hilft zumindest gegen Off-path-Angreifer [63]. Amplification Attacks wurden bereits für DNS und BACnet besprochen (siehe Abschn. 7.5.3 und Abschn. 10.5.2). Sie sind prinzipiell für eine Vielzahl von Netzwerkprotokollen realisierbar. RFC 7525 weist darauf hin, dass dies auch für CoAP gilt [63]. Wenn ein Angreifer in der Lage sein sollte, von einem CoAP-Server eine deutlich größere Antwort auf eine verhältnismäßig kleine Anfrage zu erhalten, dann kann die Arbeits- und Netzwerklast des Servers beeinträchtigt werden. Im schlimmsten Fall wäre ein DoS-Angriff damit realisierbar. Wie bei anderen Netzwerkprotokollen ist auch hier die

10.8 Generische IoT-Protokolle der Anwendungsschicht

323

Beeinflussung Dritter durch IP-Spoofing möglich. Die CoAP-Spezifikation empfiehlt daher, möglichst keine großen Bandwidth Amplification Factors (BAFs, siehe Abschn. 10.5.2) zu ermöglichen. Das heißt, es sollte vermieden werden, verhältnismäßig große Antworten auf kleine Anfragen zu geben. Dies kann durch Slicing, also die Aufteilung der Datenmenge in kleine Teile, geschehen [63]. Die CoAP-Spezifikation beinhaltet noch einige weitere Hinweise, unter anderem zur Implementierung von CoAP auf ressourcenbeschränkten Geräten. So bieten derlei Geräte oftmals keine guten Entropiequellen, und damit schlechte PRNGs. Die Erzeugung von kryptografischen Schlüsseln auf solchen Geräten ist daher als äußerst bedenklich einzustufen. Besser ist es, die Schlüssel auf einem anderen Gerät mit hoher Entropie und guten PRNGs zu erzeugen und sie vor dem Deployment über einen sicheren Kanal auf die ressourcenbeschränkten Geräte zu übertragen. Auch sind Geräte, die CoAP verwenden, in manchen Fällen dem physikalischen und zugleich ungeschützten Zugriff durch Angreifer ausgesetzt (etwa wenn sie in einem Park, an der Fassade von Gebäuden oder in der Landwirtschaft eingesetzt werden). Eine Sicherung gegen solche physikalischen Angriffe ist empfehlenswert und kann beispielsweise das Ziel verfolgen, das hardwareseitige Auslesen kryptografischer Schlüssel zu verhindern. Auch weist der Standard darauf hin, dass hochqualitative Parser für CoAPImplementierungen verwendet werden sollten. Kann ein Angreifer (etwa durch Fuzzing) CoAP-Daten generieren, die eine Implementierung zum Absturz bringen können, so entspräche dies einem DoS-Angriff auf die jeweilige Node. Ein ausgiebiges Fuzzing während der Implementierung beziehungsweise vor dem Deployment kann derlei Angriffe zumindest deutlich unwahrscheinlicher machen. Außerdem wurde CoAP so konzipiert, dass die Komplexität der zu parsenden Daten relativ gering ist und ein Teil des ParsingAufgaben an den Client ausgelagert wurde. Kryptografische Absicherung des Protokolls CoAP kennt vier Sicherheitsmodi. Im Modus „NoSec“ wird schlicht keine kryptografische Sicherheit geboten. CoAP kann allerdings alternativ über DTLS (siehe Abschn. 5.3.2.1) übertragen werden, das die anderen drei Modi ermöglicht. Verwendet werden können entweder • zuvor verteilte Schlüssel („PreSharedKey“-Modus; jeder Schlüssel enthält dabei Informationen darüber, für welches Gerät er gilt), • öffentliche Schlüssel („RawPublicKey“-Modus) oder • digitale Zertifikate („Certificate“-Modus) [63]. Unter anderem können durch DTLS einige der oben genannten Angriffe verhindert werden (unter anderem erfolgreiches Spoofing, da zwar die IP-Adresse gefälscht, die CoAP-Nachricht allerdings als nicht authentisch erkannt werden kann). Weiterhin kann DTLS verhindern, dass ein MitM-Angreifer unbemerkt CoAP-Nachrichten ändert

324

10 Sicherheit im Internet der Dinge

(die Manipulation würde vom Empfänger erkannt werden). Durch DTLS kann zudem das Mitlesen der Nachrichten durch On-path-Angreifer unterbunden werden. Wenn die DTLS-gesicherte Variante von CoAP verwendet wird, beginnt die URI mit coaps:// anstelle von coap://.

10.8.2 MQTT Ähnlich wie bei CoAP dient das Protokoll Message Queuing Telemetry Transport (MQTT) der M2M-Kommunikation in ressourcenbeschränkten Einsatzszenarien. Es setzt im Gegensatz zu CoAP allerdings keine Punkt-zu-Punkt-Kommunikation (1:1-Relation) um, sondern kann eine 1:n-Relation abbilden. Ein Sender kann Null, einen oder viele Empfänger haben. Ein weiterer Unterschied ist der, dass MQTT nicht auf UDP, sondern auf TCP aufsetzt. MQTT kann für diverse Arten der IoT-Kommunikation verwendet werden, natürlich auch dazu, um Sensorwerte abzufragen. MQTT ist als OASIS-Standard spezifiziert [53]; die aktuelle Versionsnummer ist 3.1.1. Bei MQTT handelt es sich um ein Publish-Subscribe-Verfahren. Netzwerkteilnehmer können dabei nicht nur Daten (genauer: „Themen“) anderer Teilnehmer abfragen, sie können sich auch automatisch darüber informieren lassen, wenn sich Werte ändern (wenn es neue Daten zu einem Thema gibt) [42]. Geräte, die Werte bereitstellen, nennen sich Publisher. Publisher senden Daten an Geräte, die Daten verteilen (sogenannte Broker). Broker stellen die Daten wiederum solchen Geräten bereit, die Themen abonnieren. Diese Abonnenten nennen sich Subscriber. Bei MQTT müssen Publisher nicht wissen, wer die Subscriber sind; sie müssen daher auch nicht die Adressen der Subscriber kennen, schließlich kümmern sich die Broker um die Zustellung [42]. Publisher und Subscriber werden auch als Clients bezeichnet. Für derlei Benachrichtigungen zu den Themen können zudem Bedingungen definiert werden. Zum Beispiel könnte es sein, dass ein Subscriber nur dann von einem Broker informiert werden möchte, wenn ein Temperatursensor einen Wert ≥ 20 ◦ C misst.14

10.8.2.1 Sicherheit von MQTT MQTT selbst stellt kaum Sicherheitsfunktionen bereit. In [53] wird insbesondere darauf hingewiesen, dass

14 Auch andere IoT-Protokolle, wie etwa das erwähnte BACnet-Protokoll, unterstützen dieses

beziehungsweise ähnliche Verfahren. Beim BACnet-Protokoll nennt sich das Verfahren, mit dem Geräte Wertveränderungen auf anderen Geräten abonnieren können, Change-of-Value Subscription und unterstützt ebenfalls die Angabe von Bedingungen; allerdings wird im Gegensatz zu MQTT kein Broker verwendet.

10.9 IT-Sicherheit weiterer IoT-Domänen

325

• Geräte kompromittiert werden könnten (diese Aussage ist sehr ungenau und betrifft nicht nur das MQTT-Protokoll, sondern das gesamte IoT-Gerät, auf dem es eingesetzt wird) und • Daten, die auf MQTT-Clients zwischengespeichert werden, eventuell durch Unberechtigte beeinflusst oder gelesen werden könnten. Weiterhin wird darauf hingewiesen, dass das Protokollverhalten eventuell Seiteneffekte (z. B. Seitenkanäle) aufweisen kann, dass DoS-Angriffe möglich sind, und zudem Verbindungen von Eavesdropping, Datenmanipulation und Re-Routing (durch MitM-Angreifer) betroffen sein könnten. Außerdem ist es möglich, dass Nachrichten gespooft werden. Im Standard werden deshalb Maßnahmen für Autorisierung, Authentifizierung und Vertraulichkeitssicherung vorgeschlagen. Insbesondere wird der Einsatz von TLS empfohlen, um eine Verbindung zu sichern. Die Integration eigener Authentifizierungsmethoden über CONNECT-Nachrichten wird ebenfalls empfohlen.

10.9

IT-Sicherheit weiterer IoT-Domänen

Im Folgenden werden einzelne weitere Domänen der IoT-Welt (solche, die weder Smart Buildings noch Industriesteueranlagen sind) betrachtet.

10.9.1 Mobile IoT-Systeme (Smart Cars und Co.) Praktisch alle Arten mobiler IoT-Systeme müssen unterwegs, insbesondere wenn temporär keine Netzwerkverbindung besteht, autonom Entscheidungen treffen können. Das heißt auch, dass diese IoT-Systeme ohne externe Überwachung und Administration auskommen und dabei Angriffe verhindern können müssen. Anspruchsvoll wird die Thematik, wenn zwischen autonom agierenden (mobilen) Systemen, die sich gegenseitig in einer Weise vertrauen können müssen, Sicherheit geschaffen werden soll – etwa mithilfe von kryptografischen Methoden [60]. So nutzen insbesondere Smart Cars Ad-hoc-Netzwerke, die sich je nach Position der Autos spontan über diese hinweg aufbauen. Daten werden zwischen den Autos weitergeleitet, können potenziell also auch durch MitM-Attacken beeinflusst werden. Smart Cars verwenden intern Bussysteme zur Kommunikation zwischen den verschiedenen Komponenten (genannt Electronic Control Units, ECNs) eines Automobils sowie funkbasierte Kommunikationssysteme zur Interaktion mit der externen Welt [13]. Ein klassisches Bussystem für die Kommunikation zwischen ECNs ist das Controller Area Network (CAN), weitere verbreitete Systeme sind FlexRay und LIN. Laut Caselli et al. könnte sich CAN aufgrund seiner CAN-Matrix, in der genau festgelegt wird, wie ECNs kommunizieren, gut für die automatisierte Generierung von Regeln für spezifikationsbasierte NIDS eignen, bringt allerdings durch fehlende Adressen in Netzwerknachrichten auch Probleme mit

326

10 Sicherheit im Internet der Dinge

sich [13]. Forscher konnten auch bereits vor einigen Jahren spektakuläre Angriffe auf mit dem Internet verbundene Autos durchführen; Miller und Valsek haben aus 10 Meilen Entfernung einen Jeep Cherokee angegriffen, der sich auf einem Highway befand; sie verbanden sich mit der IP-Adresse des Autos, erlangten von dort aus Zugriff auf den CAN-Bus, manipulierten die Firmware des Autos und konnten unter anderem den Lenker funktionsunfähig machen und die Bremsen auslesen [24]. Wenn Automobile (oder andere IoT-Systeme) ein dynamisches Routing für Ad-hocNetzwerke nutzen, dann ist es für eingesetzte Routingalgorithmen wichtig, dass sie die Distanz zwischen Systemen kennen. Das dynamische Routing kann angegriffen werden, indem Nodes falsche Metriken kommunizieren; sie geben dazu eine kleine Distanz für eine tatsächlich größere Distanz an. Dieser Angriff nennt sich Wormhole Attack [34]. Auf Basis der Wormhole Attack können MitM-Angriffe durchgeführt werden, etwa können legitime Datenpakete selektiv verworfen werden. Alternativ kann der Datenverkehr geblockt werden (was ebenfalls eine Form des DoS darstellt) aber einige selektierte Pakete weitergeleitet werden. Durch eine solche selektive Weiterleitung werden Nodes, die eine angegriffene Route nutzen, diese nicht sofort verschmähen (schließlich gelangen noch einige Pakete an das Ziel). Ein derartiger Angriff nennt sich auch Selective Forwarding Attack. Außerdem kann Datenverkehr leichter mitgelesen werden. Ein Angriff gegen Ad-hoc-Netzwerke ist die in Abschn. 10.5.2 besprochene Routing-DoS Attack (Sinkhole Attack). Schließlich muss an dieser Stelle noch die Sybil Attack erwähnt werden; bei diesem Angriff gibt sich eine Node als mehrere Nodes aus (etwa auf Basis parallel verwendeter IP-Adressen), das heißt, sie nutzt parallel mehrere Repräsentationsmöglichkeiten. Sybil Attacks zielen speziell auf Systeme ab, die auf Reputation basieren oder bei denen die Unterscheidung von Netzwerkteilnehmern essenziell ist. Wenn beispielsweise ein Bieter-System den Strompreis an einer Strombörse bestimmen soll, und jede Node einen Vorschlag einreichen darf, dann könnte es eine Sybil Attack einer Node erlauben, mehrere Gebote abzugeben. Ein anderes Szenario wäre eines, in dem Nodes sich gegenseitig bewerten können. Mithilfe der Sybil Attack könnte eine Node mehrfach bewerten. Authentifizierungsmethoden wie CGA (Abschn. 8.3.3) erschweren Sybil Attacks.

10.9.2 Electronic Healthcare (eHealth) Im Falle von Electronic Healthcare-Equipment, bei denen es um die Unterstützung des menschlichen Körpers oder die Überwachung der Körperfunktionen von Patienten geht, ist – ähnlich wie bei ICS-Echtzeitsystemen – eine ununterbrochene und fehlerfreie Funktionsweise des Equipments bedeutsam [14]. Insbesondere in einer alternden Gesellschaft, wie der deutschen, werden Bedarf und Bedeutung von eHealth-Services und -Produkten zunehmen. eHealth-Equipment nutzt in der Regel Body Area Networks (BAN) zur Kommunikation mit anderen Komponenten und zur Übertragung der Daten an Datenkollektoren, etwa beim Arzt. Bereits 2017 konnte gezeigt werden, dass zehntausende medizinische Geräte über die Suchmaschine SHODAN im Internet gefunden werden konnten; außerdem können

10.9 IT-Sicherheit weiterer IoT-Domänen

327

allein große Krankenhäuser mehrere Tausend IoT-Geräte aufweisen [28]. Die Sicherung einer so großen Zahl sensibler Geräte ist für die Sicherheitsverantwortlichen eine enorme Herausforderung. Zum Einsatz kommen bei eHealth-Equipment oftmals Protokolle wie Bluetooth oder ZigBee. Obig beschriebene DoS-Angriffe, etwa Sinkhole-Angriffe können die Verfügbarkeit der Kommunikation – und damit im schlimmsten Fall die Kommunikation kritischer Veränderungen von Vitalwerten – verhindern. Ein weiter wichtiger Aspekt ist Data Freshness (also das Verhindern, das veraltete Daten gesendet werden können), die etwa bei der ˇ Übermittlung von EEG-Werten besonders wichtig ist [14]. Cauševi´ c et al. führen zudem die Bedeutung der Authentifizierung und der Autorisierung in eHealth-Systemen als bedeutsam an; schließlich soll nur zuständiges medizinisches Personal oder (zertifiziertes) Administrationspersonal mit den Geräten interagieren können und dies wiederum nur im Rahmen der für das jeweilige Personal relevanten Parameter. Es erschließt sich sofort, dass die Integrität der Daten zu schützen ist und die Vertraulichkeit zum Schutz der Privatsphäre von Patienten ein weiterer Schlüsselfaktor für eHealth-Equipment ist. Insbesondere Eavesdropping von sensitiven Daten und das Auslesen gespeicherter sensibler Daten müssen daher mit hoher Priorität unterbunden werden. Weitere bedeutsame Ansätze zur Erhöhung der Sicherheit von BANs sind unter anderem [14]: • die Verwendung der körpereignen Signale (etwa Herzschlag oder Blutdruck) zur Generierung von Zufallszahlen (insbesondere für kryptografische Schlüssel), • benutzerbestimmbare Empfängerselektion (Patienten können somit die Übertragung medizinischer Daten explizit freigeben), • kryptografische Protokolle, die für die verschiedensten Einsatzzwecke ausgelegt wurden; dazu gehören etwa eine energieeffiziente Übertragung medizinischer Daten innerhalb eines BAN sowie die Sicherung der Kommunikation und des Patchings von implantierten Geräten (auch diese können beispielsweise Angriffen durch Schadsoftware ausgesetzt werden). Angemerkt sei an dieser Stelle, dass eHealth-Equipment prinzipiell auch in Form von Fitnesstrackern/Schrittzählern vorliegen kann. Die Anforderungen und die Kritikalität, die mit einem Schrittzähler verbunden sind, unterscheiden sich jedoch fundamental von einem implantierten Herzschrittmacher. Die Verfügbarkeitsanforderungen für einen Herzschrittmacher übersteigen die an einen Fitnesstracker um Längen.

10.9.3 Landwirtschaft Im Bereich der Agrarwirtschaft wird das IoT zur Optimierung von Erträgen und nachgeordneten Zielen, etwa der konstanten Überprüfung der Gesundheit von Nutztieren, eingesetzt [2]. Zu diesem Zweck werden etwa Videokameras in Ställen eingesetzt, die Tiere überwachen. Auch werden Roboter verwendet, um Pflanzen automatisiert

328

10 Sicherheit im Internet der Dinge

zu bewirtschaften [67]. Adams-Progar et al. weisen auf diverse durch das IoT in diesem Kontext existierende Gefahren hin. Etwa könnte die Geburtshilfe bei einer Kuh durch eine IoT-Videokamera gefilmt werden. Diese Geburtshilfe könnte bei fachfremden Personen wiederum einen martialischen Eindruck hinterlassen und als Misshandlung des Tiers verstanden werden; alternativ könnten Aktivisten das Video nutzen (und ggf. manipulieren, was in Zukunft hochgradig professionell in Echtzeit passieren könnte [7]), um es für ihre Zwecke zu nutzen und einem Betrieb zu schaden [2].15 Auch können Angreifer versuchen, Gerätschaften der Agrarwirtschaft zu beeinflussen, und damit etwa den Erträgen, der Gesundheit und Sicherheit von Tier und Mensch sowie Pflanzen auf Äckern schaden; beispielsweise könnte ein Angreifer probieren, den erlaubten Grenzwert für den Schadstoffausstoß einer landwirtschaftlichen Anlage übersteigen zu lassen, was wiederum zum Image- und Finanzschäden eines Betriebs führen kann [2]. Gemäß AdamsProgar et al. empfohlene Maßnahmen zur Steigerung der IT-Sicherheit und zum Schutz der Privatsphäre für das agrarwirtschaftliche IoT sind generell solche Maßnahmen, die die traditionellen Schutzziele verfolgen (CIA-Triade); insbesondere ist der Einsatz von oben bereits erwähnten kryptografisch gesicherten Protokollen sinnvoll, um Integrität, Authentizität und Vertraulichkeit sämtlicher Übertragungen zu sichern. Weiterhin sollten sensitive Datenbestände durch kryptografische Verfahren und gehärtete Datenbanken und Betriebssysteme gesichert werden. Da der landwirtschaftliche IoT-Sektor auf vielen anderen IoT-Sektoren aufbaut (die Bewässerung und Belüftung von Gewächshäusern erfolgt etwa durch Industriesteueranlagen und Methoden der Gebäudeautomation; Traktoren nutzen Technologie der Smart Cars), sollten auch die entsprechenden Sicherheitsansätze der anderen Domänen appliziert werden.

10.9.4 Legacy-Equipment Für sämtliche Arten von IoT-Equipment sowie für IoT-bezogene Daten gilt, dass Altequipment und alte Datenbestände als Teil der Außerbetriebnahme beziehungsweise vor einem Weiterverkauf bereinigt werden müssen. Der Verkauf von altem Equipment auf Ebay und Co. könnte schlicht zur Weitergabe sensitiver Informationen, etwa des aufgezeichneten Pulses durch einen Fitnesstracker, führen. Im Optimalfall können per Knopfdruck Resets durchgeführt werden, die auch die lokalen Speichermedien von IoT-Equipment sicher überschreiben. Hersteller könnten Kunden derartige Möglichkeiten bieten, sollten dann allerdings auch solche den Kunden betreffende Daten in eine Löschung einbeziehen, die in der Cloud zur Diensterbringung gespeichert wurden (etwa historische Daten eines Fitnesstrackers), vgl. hierzu Abschn. 10.4.

15 Der Autor möchte darauf hinweisen, dass er eine gesundheitsgefährdende oder schlicht nicht artgerechte Haltung von Nutztieren selbstverständlich nicht befürwortet.

10.10 Digitale Forensik für das IoT

329

10.10 Digitale Forensik für das IoT Forensik befasst sich mit der Rekonstruktion in der Vergangenheit liegender, in der Regel krimineller, Vorfälle. Dies können zunächst einmal Vorgänge aus der physikalischen Welt sein, etwa Einbrüche oder Morde. Es können allerdings auch Vorgänge der digitalen Welt sein, beispielsweise Einbrüche in Computer oder Übernahme digitaler Identitäten. Zwischen diesen beiden Bereichen, also der physikalischen und der digitalen Forensik, kann eine Schnittmenge betrachtet werden, nämlich die, die sich mit Auswirkungen auf physikalische und digitale Elemente befasst. Für das IoT gilt, dass durch digitale Ereignisse auch Vorfälle in der physikalischen Welt hervorgerufen werden können. Insofern könnte ein digital kontrollierter Roboter etwa dafür genutzt werden, einen Menschen zu verletzten. In [15] haben wir die Unterschiede zwischen klassischer IT-Forensik und der IoTForensik erläutert. Diese Unterschiede möchte ich im Folgenden noch einmal zusammenfassen. Zunächst einmal liegen diverse Unterschiede zwischen klassischen IT-Systemen und IoT-Geräten vor [15]: 1. IoT-Geräte verfügen oftmals über recht begrenzte Ressourcen. Folglich können sie insbesondere aufgrund des begrenzten Speichers nur wenige oder nur undetaillierte Vorgänge lokal protokollieren. Diese Vorgänge können sowohl die physikalische Welt betreffen (Sensordaten) als auch die Interna des IoT-Geräts (Logdaten über Anmeldeversuche, angenommene TCP-Verbindungen usw.). Somit stehen potenziell weniger Informationen für eine forensische Analyse zur Verfügung. 2. Unterschiedliche Typen von IoT-Geräten sowie unterschiedliche Hersteller integrieren inkompatible, teils nicht dokumentierte oder schlicht nicht vorhandene Schnittstellen, mit denen Daten von Geräten ausgelesen werden können. Auch dies erschwert eine forensische Analyse deutlich. Bei klassischen IT-Geräten, die Standardsoftware verwenden, sind diese Aspekte relativ einheitlich, bei IoT-Equipment hingegen oft uneinheitlich. Für unterschiedliche Gerätetypen, selbst für unterschiedliche Firmwareversionen des gleichen Geräts, können zudem heterogene Darstellungen von Daten vorliegen. Beispielsweise können fehlende Werte in einer Datenbank schlicht weggelassen werden, die zuvor als „false“ markiert wurden. Auch können unterschiedliche Geräte den Wert 2000 sehr unterschiedlich kodieren, etwa: 2000,000000, 2000.0, 2,000, 2,000.0 oder schlicht 2000. Bei der Auswertung mehrerer Geräte muss daher besonders darauf geachtet werden, Daten zunächst aufzubereiten. 3. Die begrenzte Energieversorgung insbesondere im Feld eingesetzter IoT-Geräte erlaubt es nicht unbedingt, Daten langfristig vorzuhalten, sondern etwa nur so lange, wie eine Sonneneinstrahlung die Solarpanele eines Sensors mit Energie versorgt. Wie Nieto et al. darstellen, ist auch die Betrachtung der Privatsphäre von IoT-Nutzern während der forensischen Analyse von Relevanz [52]. Die Autoren entwickelten ein

330

10 Sicherheit im Internet der Dinge

System namens PRoFIT, das die forensische Analyse von IoT-Systemen unter der Bedingung ermöglicht, dass die Privatsphäre der IoT-Nutzer nach Möglichkeit gewahrt bleibt. Auch ist anzumerken, dass für IoT-Forensik domänenspezifisches Know-how notwendig ist. So kann ohne ein Verständnis für die Daten eines Smart Buildings oder einer chemischen Fabrikanlage keine vernünftige Interpretation derselben erfolgen. Die Forensik eines IoT-Geräts muss sich zunächst einmal auch den nicht-IoTspezifischen Problemen der digitalen Forensik stellen, etwa den in Abschn. 3.7.2 angesprochenen Anti-Forensik-Techniken von Schadsoftware. IoT-Forensik kann entsprechend auch zunächst mit den Mitteln der nicht-IoT-Forensik erfolgen, etwa um an aufgezeichnete Sensordaten oder Logdateien zu gelangen. Diverse Publikationen beschreiben Vorgehensweisen für die technische Durchführung von IT-Forensik auf Betriebssystemen und Gerätetypen jeder Art. Einführende Literatur bieten etwa der BSI Leitfaden zur IT-Forensik [11] sowie die Bücher von Dewald und Freiling [20] und von Farmer und Venema [23]. Auch diverse spezielle Arbeiten existieren; Braun et al. erläutern beispielsweise die Vorgehensweise für die forensische Analyse von DSL-Routern [10]. Wenn traditionelle IT-basierte Angriffe auf ein IoT-Gerät forensisch rekonstruiert werden sollen, bleibt es auch bei den zugehörigen Methoden der digitalen Forensik. Ein Analyst kann beispielsweise versuchen, den internen Speicher eines zu analysierenden Geräts zu kopieren und dabei möglichst wenige lokale Veränderungen vorzunehmen. Er kann aber auch versuchen, direkt auf dem Gerät Analysen durchzuführen, wobei dies unter Umständen Indizien überschreibt. Diverse Werkzeuge zur Analyse des Hauptspeichers und von SD-Speichern stehen zur Verfügung, weitere Werkzeuge werten Logdateien aus. Wenn mithilfe der IoT-Forensik allerdings ein physikalischer Vorgang rekonstruiert werden soll, also etwa ein Überfall, muss im Anschluss an die rein digitale Forensik eine Analyse von Sensordaten erfolgen. Dabei kann es sich um Kameraaufnahmen, Temperaturdaten, Luftdruckdaten, CO2 -Werte, Daten, die anzeigen, ob eine Tür oder ein Fenster offen oder geschlossen war, Druckdaten oder sonstige physikalische Daten handeln. All diese Daten können dem domänenspezifischen Analysten Hinweise auf einen Tathergang erlauben. Wenn etwa die Temperatur in einem Raum steigt, kann dies auf die Anwesenheit von Menschen hinweisen; es kann aber auch daran liegen, dass die Steuerlogik des Gebäudes den Heizkörper stärker heizen lässt. Aufgrund der Natur der IoT-Geräte ergeben sich zudem einige weitere wichtige in [15] genannte Aspekte, die ich etwas detaillieren möchte: • Wenn es darum geht, die physikalische Umgebung von IoT-Geräten auszuwerten, dann hängen die von IoT-Sensoren lieferbaren Werte maßgeblich davon ab, wie diese ausgerichtet sind, wie genau sie messen und wie gut sie kalibriert sind. In [15] ist etwas abstrakter von der Density of Deployment die Rede, das heißt davon, wie weit Sensoren voneinander entfernt sind. Wenn zehn Temperatursensoren an unterschiedlichen

10.11 Zusammenfassung

331

Positionen in einem Raum verbaut sind, erhält ein Analyst genauere Informationen, als wenn nur ein Temperatursensor im Raum verbaut ist. Anders formuliert steigt die Auflösung mit der Deployment Density. Man kann die Density etwa in Sensoren/m2 oder auch Sensoren/m3 ausdrücken. • Platzierung der Geräte (Device Location) – Sensoren, die fernab eines Tatorts verbaut sind, sind unnütz. Daher muss für eine forensische Analyse selbstverständlich einbezogen werden, ob ein bestimmter Wert tatsächlich einen (indirekten) Rückschluss auf Events an einen Tatort liefern kann. Auch kann Device Location bedeuten, dass ein Gerät schlicht nicht zugreifbar ist. Dies kann daran liegen, dass es hinter einer Wand verbaut ist und in einem Rohr den Druck misst. Es kann aber auch daran liegen, dass ein mit einer Tat in Verbindung stehendes Gerät, etwa eine Smartwatch oder ein Smart Car, über eine Landesgrenze hinweg transportiert wurde und aus juristischen Gründen (andere Rechtslage) oder praktischen Gründen (etwa Platzierung auf einem Hochseefrachter) derzeit nicht ausgelesen werden kann. • Weiterhin hängt die forensische Analyse der Umgebung von IoT-Geräten von deren Gerätetyp (Device Type) ab. Ein Temperatursensor erfasst die Temperatur in einem Bereich, ein Luftdrucksensor hingegen den Luftdruck. Je nachdem, was über eine physikalische Umgebung in Erfahrung gebracht werden soll, sind unterschiedliche Gerätetypen von Interesse. Ein Aktor, der ein Fenster öffnet oder schließt kann etwa bei Einbrüchen sehr nützlich sein, sofern er die letzten ausgeführten Befehle protokolliert.

10.11 Zusammenfassung Während vorherige Kapitel sich rein auf die Welt der klassischen IT-Netzwerke konzentrierten, bezieht das Internet der Dinge auch die physikalische Umgebung, die Welt, in der wir leben, ein. Cyber-physikalische Systeme messen und steuern ihre Umwelt und weisen daher völlig neue Möglichkeiten auf, wie Überwachung und Manipulation stattfinden können. Cyber-physikalische Systeme sind sogar in der Lage, die Sicherheit (Safety) von Lebewesen zu gefährden. Die Sicherheit des Internet der Dinge kann nur im Kontext von sozialen, politischen, organisatorischen und wirtschaftlichen Aspekten gut verstanden werden. Diese Mechanismen spielen etwa in den Cycle-of-Blame und in die Standardisierung des Internet of Things hinein. Anhand von Smart Buildings und Industrial Control Systems wurden in diesem Kapitel diverse Angriffs- und Verteidigungsmethoden aufgezeigt, die sich im Wesentlichen auf alle sonstigen Gebiete des Internet of Things anwenden lassen – teils in modifizierter oder abgeschwächter Form.

332

10 Sicherheit im Internet der Dinge

10.12 Weiterführende Literatur Das IoT ist ein aktueller Forschungsgegenstand. Entsprechend gibt es viele neue Studien und Publikationen, die sich mit der IT-Sicherheit des IoT befassen. Empfehlenswert ist etwa eine Studie von Shepherd et al., die sich mit den Risiken des Financial IoT befasst [64]. In ihrer Arbeit führen die Autoren eine Risiko-Studie mit 40 Teilnehmern durch. Sie können zeigen, welche Schutzwerte, Verwundbarkeiten und Bedrohungen diese Teilnehmer als besonders wichtig erachten [64]. Die Ergebnisse sollten laut den Autoren jedoch nicht ohne Weiteres auf andere IoT-Domänen übertragen werden. In einem Buchkapitel haben wir recht ausführlich die Problematik der IT-Sicherheit von Smart Buildings beschrieben [80]. Wir gehen dabei insbesondere auf die Sicherheitsfähigkeiten der Netzwerkprotokolle und auf die netzwerkbasierte Absicherung von Smart Buildings ein. Wie bereits im vorherigen Kapitel angeführt, können IoT-Geräte auch für steganografische Zwecke verwendet werden – zur Speicherung und Übertragung versteckter Daten. Eine Einführung in dieses Spezialthema bietet [81]. Generell ist das Buch von Song, H., Fink, G. A., Jeschke, S. (Hrsg.): Security and Privacy in Cyber-physical Systems: Foundations, Principles, and Applications, Wiley-IEEE Press, 2018, sehr als Einführung in das Thema der IoT-/CPS-Sicherheit zu empfehlen. Mehrere der darin enthaltenen Kapitel fanden Erwähnung und Zitierung im vorliegenden Buch.

10.13 Übungsaufgaben 1. Welche grundlegenden Herausforderungen gibt es für die Umsetzung von Sicherheit im IoT? 2. Erläutern Sie prägnant das Konzept des „Cycle of Blame“. 3. Weshalb ist Standardisierung für das IoT von Bedeutung? Welche Faktoren behindern den Standardisierungsprozess auf welche Weise? 4. Das Patching von IoT-Komponenten ist insbesondere langfristig eine Herausforderung. Erläutern Sie, weshalb. 5. Was verbirgt sich hinter den Begriffen Leittechnik, DDC, Sensor, Aktor und KNX. 6. Wie funktionieren Smurf- und Routing-DoS-Angriffe auf Smart Buildings? 7. Wie funktionieren Amplification-Angriffe auf Smart Buildings und was versteht man unter dem Bandwith Amplicication Factor? 8. Welche potenziellen Gefahren bieten Smart Building Botnets? 9. Welche Besonderheiten ergeben sich bei der Absicherung von ICS gegenüber nichtkritischer Infrastruktur und IoT-Systemen, die nicht mit Echtzeitprozessen verbunden sind? 10. Was verbirgt sich hinter einer HMI-Manipulation Attack? 11. Erläutern Sie den Nutzen eines Downgradeangriffs.

Literatur

333

12. Secure Modbus verhindert Replay-Angriffe – wie? Wodurch sichert das Protokoll zudem die Authentizität von gesendeten Nachrichten? 13. Überlegen Sie sich drei Szenarien für den Einsatz einer Sybil Attack. 14. Was ist unter einer Wormhole Attack und was unter einer Selective Forwarding Attack zu verstehen? In welchem Kontext können diese Angriffe angewandt werden? 15. Worin unterscheiden sich die beiden IoT-Protokolle MQTT und CoAP von klassischen Protokollen, die in Automationsumgebungen zum Einsatz kommen? 16. Wie unterscheiden sich MQTT und CoAP? 17. Nennen Sie drei Angriffe auf das CoAP-Protokoll. 18. Erläutern Sie Besonderheiten der IT-Forensik für das IoT.

Literatur 1. Ackerman, E.: Nachrichtenbeitrag „Drones make a special delivery-mosquitoes“. IEEE Spectr. 54(12), 7–9 (2017). EEE 2. Adams-Progar, A., Fink, G.A., Walker, E., Llewellyn, D.: Security and privacy issues in the Internet of cows. In: Song, H., Fink, G.A., Jeschke, S. (Hrsg.) Security and Privacy in CyberPhysical Systems: Foundations, Principles, and Applications. Wiley-IEEE Press, Hoboken (2018) 3. Anderson, R.: The economics of information security. Science 314, 610–613 (2006) 4. Berners-Lee, T., Fielding, R., Masinter, L.: Uniform Resource Identifier (URI): Generic Syntax – RFC 3986. Network Working Group, Fremont (2005) 5. Bisson, P., Martinelli, F., Riesco Granadino, R.: Cybersecurity Strategic Research Agenda (SRA) of the European Network and Information Security (NIS) platform, version 0.96 (2015). https://resilience.enisa.europa.eu/nis-platform/shared-documents/wg3-documents/ strategic-research-agenda-final-v0.96/at_download/file. Zugegriffen am 01.06.2018 6. BITAG: Internet of Things (IoT) Security and Privacy Recommendations (2016). https:// www.bitag.org/documents/BITAG_Report_-_Internet_of_Things_(IoT)_Security_and_Privacy_ Recommendations.pdf. Zugegriffen am 01.06.2018 7. boingboing.net: The future of fake news is real-time video manipulation (2017). https:// boingboing.net/2017/01/31/the-future-of-fake-news-is-rea.html. Zugegriffen am 01.06.2018 8. Bojanova, I., Voas, J.: Trusting the Internet of Things (guest editor’s introduction). IT Prof. 19(5), 16–19 (2017). IEEE 9. Bormann, C., Shelby, Z. (Hrsg.): Block-Wise Transfers in the Constrained Application Protocol (CoAP) – RFC 7959. IETF, Fremont (2016) 10. Braun, S., Höfken, H., Schuba, M., Breuer, M.: Forensische Sicherung von DSL-Routern. In: Proceedings of the D-A-CH Security 2015, S. 369–377. syssec (2015) 11. Bundesamt für Sicherheit in der Informationstechnik (BSI): Leitfaden „IT-Forensik“, Version 1.0.1. BSI (2011) 12. Cárdenas, A.A., Amin, S., Sastry, S.: Secure control: Towards survivable cyber-physical systems. In: Proceedings of the International Conference on Distributed Computing Systems, S. 495–500. IEEE, Piscataway (2008) 13. Caselli, M., Amann, J., Sommer, R., Kargl, F.: Specification mining for intrusion detection in networked control systems. In: Proceedings of the 25th USENIX Security Symposium, S. 791–806. USENIX Association (2016)

334

10 Sicherheit im Internet der Dinge

ˇ 14. Cauševi´ c, A., Fotouhi, H., Lundqvist, K.: Data security and privacy in cyber-physical systems for healthcare. In: Song, H., Fink, G.A., Jeschke, S. (Hrsg.) Security and Privacy in Cyber-physical Systems: Foundations, Principles, and Applications. Wiley-IEEE, Hoboken (2018) 15. Caviglione, L., Wendzel, S., Mazurczyk, W.: The future of digital forensics: Challenges and the road ahead. IEEE Secur. Priv. 15(6), 12–17 (2017). IEEE 16. Central European News und Chris Summers (Mailonline): Four-star alpine hotel fell victim to blackmailers who hacked into their electronic keycard system and locked guests in their room (so they’ve brought back traditional locks and keys), MailOnline (2017). http://www.dailymail.co.uk/news/article-4163886/Alpine-hotel-brings-locks-cyberhacking.html. Zugegriffen am 01.06.2018 17. Class, S.: A chip to protect the Internet of Things. IEEE Spectr Ausgabe 01(17), 16–17 (2017) 18. Collins, M.: Network Security Through Data Analysis, 2. Aufl. O’Reilly, Sebastopol (2017) 19. Creery, A., Byres, E.J.: Industrial cybersecurity for power system and SCADA networks. In: Proceedings of the Industry Applications Society – 52nd Annual Petroleum and Chemical Industry Conference, S. 303–309. IEEE, New York/Piscataway (2005) 20. Dewald, A., Freiling, F.C. (Hrsg.): Forensische Informatik. Books on Demand, Norderstedt (2011) 21. Evancich, N., Li, J.: Attacks on industrial control systems. In: Colbert, E.J.M., Kott, A. (Hrsg.) Cyber-Security of SCADA and Other Industrial Control Systems, S. 95–110. Springer, Cham (2016) 22. Fernandes, E., Rahmati, A., Eykholt, K., Prakash, A.: Internet of things security research: A Rehash of old ideas or new intellectual challenges? IEEE Secur. Priv. 15(4), 79–84 (2017). IEEE 23. Farmer, D., Venema, W.: Forensic Discovery. Addison-Wesley, Boston (2004) 24. Fink, G.A., Edgar, T.W., Rice, T.R., MacDonald, D.G., Crawford, C.E.: Overview of security and privacy in cyber-physical systems. In: Song, H., Fink, G.A., Jeschke, S. (Hrsg.) Security and Privacy in Cyber-Physical Systems: Foundations, Principles, and Applications. Wiley-IEEE, Hoboken (2018) 25. Fovino, I.N., Carcano, A., Masera, M., Trombetta, A.: Design and implementation of a secure Modbus protocol. In: Proceedings of the International Conference on Critical Infrastructure Protection, S. 83–96. Springer, New York (2009) 26. Gasser, O., Scheitle, Q., Rudolph, B., Denis, C., Schricker, N., Carle, G.: The amplification threat posed by publicly reachable BACnet devices. J. Cyber Secur. 6(1), 77–104 (2017). Riverpublishers 27. Glanzer, H., Krammer, L., Kastner, W.: Increasing security and availability in KNX security. In: Meier, M., Reinhardt, D., Wendzel, S. (Hrsg.) Tagungsband Sicherheit, Schutz und Zuverlässigkeit (GI Sicherheit 2016), Teil: International Workshop on Security, Privacy and Reliability of Smart Buildings, S. 241–252. Gesellschaft für Informatik (2016) 28. Gralla, P.: Medical IoT devices: the security nightmare that keeps CIOs up late at night, HPE.net (2017). https://www.hpe.com/us/en/insights/articles/medical-iot-devices-the-securitynightmare-that-keeps-cios-up-late-at-night-1709.html. Zugegriffen am 01.06.2018 29. Granzer, W., Kastner, W., Neugschwandtner, G., Praus, F.: Security in networked building automation systems. In: Proceedings of the Factory Communication Systems. IEEE (2006) 30. Granzer, W., Reinisch, C., Kastner, W.: Denial-of-service in automation systems. In: Proceedings of the 13th IEEE Conference on Emerging Technologies and Factory Automation (ETFA ’08), S. 468–471. IEEE (2008) 31. Granzer, W., Praus, F., Kastner, W.: Security in building automation systems. IEEE Trans. Ind. Electron. 57(11), 3622–3630 (2010). IEEE 32. Green, B., Le, A., Antrobus, R., Roedig, U., Hutchison, D., Rashid, A.: Pains, gains and PLCs: ten lessons from building an industrial control systems testbed for security research.

Literatur

335

In: Proceedings of the 10th USENIX Workshop on Cyber Security Experimentation and Test. USENIX Association (2017) 33. Gutmann, J.: Digitale Piraterie – Cyber-Angriffe im maritimen Transportwesen, BSI-Magazin, Ausgabe 1, 2017 34. Hasan, M.M., Hussein, T.M.: Cyber-physical vulnerabilities of wireless sensor networks in smart cities. In: Song, H., Fink, G.A., Jeschke, S. (Hrsg.) Security and Privacy in Cyber-Physical Systems: Foundations, Principles, and Applications. Wiley-IEEE Press, Hoboken (2018) 35. Hibberd, G., Cook, A.: The rise of cyber liability insurance. In: Akhgar, B., Staniforth, A., Bosco, F. (Hrsg.) Cyber Crime and Cyber Terrorism Investigator’s Handbook. Syngress, Waltham (2014) 36. IANA: Constrained RESTful Environments (CoRE) Parameters (2018). https://www.iana.org/ assignments/core-parameters/core-parameters.xhtml. Zugegriffen am 01.06.2018 37. Jeyanthi, N.: Internet of Things (IoT) as Interconnection of Threats (IoT). In: Hu, F. (Hrsg.) Security and Privacy in the Internet of Things (IoTs). CRC Press, Boca Raton (2016) 38. Kahler, B., Wendzel, S.: How to own a building? Wardriving gegen die Gebäude-Automation. In: Proc. 20. DFN Workshop zur Sicherheit in vernetzten Systemen, S. H1–H13. BoD (2013) 39. Kleinmann, A., Amichay, O., Wool, A., Tenenbaum, D., Bar, O., Lev, L.: Stealthy deception attacks against SCADA systems. In: SECPRE 2017 – Computer Security, S. 93–109. Springer, Cham (2018) 40. Kosseff, J.: Cyber-physical systems and national security concerns. In: Song, H., Fink, G.A., Jeschke, S. (Hrsg.) Security and Privacy in Cyber-Physical Systems: Foundations, Principles, and Applications. Wiley-IEEE Press, Hoboken (2018) 41. Kott, A., Gonzalez, C.A., Colbert, E.J.M.: Introduction and preview. In: Colbert, E.J.M., Kott, A. (Hrsg.) Cyber-Security of SCADA and Other Industrial Control Systems, Kapitel 1, S. 1–14. Springer, Cham (2016) 42. Lampkin, V., Leong, W.T., Olivera, L., Rawat, S., Subrahmanyam, N., Xiang, R.: Building Smarter Planet Solutions with MQTT and IBM WebSphere MQ Telemetry. IBM, Armonk (2012) 43. Lau, S., Klick, J., Arndt, S., Roth, V.: POSTER: towards highly interactive honeypots for industrial control systems. In: Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security (CCS), S. 1823–1825. ACM, New York (2016) 44. Lee, E.A.: Cyber physical systems: design challenges. In: Proceedings of the 1st IEEE International Symposium on Object and Component-Oriented Real-Time Distributed Computing (ISORC), S. 363–369. IEEE, Piscataway (2008) 45. Levander, O.: Autonomous ships on the high seas. IEEE Spectr. 2017(2), 24–29 (2017). IEEE 46. Leverett, É., Clayton, R., Anderson, R.: Standardisation and certification of the ,Internet of Things‘. In: Proceedings of the 16th Workshop on the Economics of Information Security (WEIS’17) (2017). https://www.cl.cam.ac.uk/~rja14/Papers/weis2017.pdf. Zugegriffen am 01.06.2018 47. Luiijf, E.: New and emerging threats of cyber crime and terrorism. In: Akhgar, B., Staniforth, A., Bosco, F. (Hrsg.) Cyber Crime and Cyber Terrorism Investigator’s Handbook. Syngress, Waltham (2014) 48. Malchow, J.-O., Klick, J.: Erreichbarkeit von digitalen Steuergeräten. Ein Lagebild. In: Proc. 21. DFN-Workshop zur Sicherheit in vernetzten Systemen, S. A1–19. BoD (2014) 49. Malchow, J.-O., Marzin, D., Klick, J., Kovacs, R., Roth, V.: PLC guard: a practical defense against attacks on cyber-physical systems. In: Proceedings of the Conference on Communications and Network Security (CNS), S. 326–334. IEEE (2015) 50. Merz, H., Hansemann, T., Hübner, C.: Gebäudeautomation – Kommunikationssysteme mit EIB/KNX, LON und BACnet, 3. Aufl. Carl Hanser Verlag (2016)

336

10 Sicherheit im Internet der Dinge

51. NewSky security: A huge wave of IoT zombies are coming (2017). https://blog.newskysecurity. com/a-huge-wave-of-iot-zombies-are-coming-42d61d6cada0. Zugegriffen am 01.06.2018 52. Nieto, A., Rios, R., Lopez, J.: A methodology for privacy-aware IoT-forensics. In: Proceedings of the Trustcom/BigDataSE/ICESS, S. 626–633. IEEE (2017) 53. OASIS: MQTT Version 3.1.1 (OASIS Standard) (2014). http://docs.oasis-open.org/mqtt/mqtt/ v3.1.1/os/mqtt-v3.1.1-os.html. Zugegriffen am 01.06.2018 54. Oman, P., Schweitzer, E., Frincke, D.: Concerns about intrusions into remotely accessible substation controllers and SCADA systems. In: Proceedings of the Twenty-Seventh Annual Western Protective Relay Conference, Bd. 160. Washington State University (2000) 55. Praus, F., Kastner, W.: Identifying unsecured building automation installations. In: Proceedings of the 2014 IEEE Emerging Technology and Factory Automation (ETFA), S. 1–4. IEEE (2014) 56. Ray, S., Basak, A., Bhunia, S.: The patchable Internet of Things. IEEE Spectr 54(11) 30–35 (2017). IEEE 57. Rist, T., Wendzel, S., Masoodian, M., André, E.: Next-generation home automation systems. In: Proceedings of the Usability Day X, S. 80–87. Pabst Science Publishers (2012) 58. Ross, A.: The Industries of the Future. How the Next 10 Years of Innovation will Transform Our Lives at Work and Home. Simon & Schuster, London/New York/Sydney/Toronto (2016) 59. Schneier, B.: IoT security: what’s plan B? IEEE Secur. Priv. 15(5), 96 (2017). IEEE 60. Schneider, D., Trapp, M., Dörr, J., et al.: Umfassende Sicherheit: safety und Security im Kontext autonomer Systeme. Informatik Spektrum 40(5), 419–429 (2017). Springer 61. Sendler, U.: Menschheit im Umbruch. Informatik Spektrum 40(5), 455–465 (2017). Springer 62. Shelby, Z.: Constrained RESTful Environments (CoRE) Link Format – RFC 6690. IETF, Fremont (2012) 63. Shelby, Z., Hartke, K., Bormann, C.: The Constrained Application Protocol (CoAP) – RFC 7252. IETF, Fremont (2014) 64. Shepherd, C., Petitcolas, F.A.P., Akram, R.N., Markantonakis, K.: An exploratory analysis of the security risks of the Internet of Things in finance. In: International Conference on Trust and Privacy in Digital Business (TrustBus 2017), S. 164–179. Springer, Cham (2017) 65. Song, H., Fink, G.A., Jeschke, S.: Preface. In: Song, H., Fink, G.A., Jeschke, S. (Hrsg.) Security and Privacy in Cyber-Physical Systems: Foundations, Principles, and Applications. Wiley-IEEE Press, Hoboken (2018) 66. Soucek, S., Zucker, G.: Current developments and challenges in building automation. Elektrotechnik & Informationstechnik 129(4), 278–285 (2012). Springer 67. Stoˇces, M., Vanˇek, J., Masner, J., Pavlík, J.: Internet of Things (IoT) in agriculture – selected aspects. Agris On-Line Pap. Econ. Informat. 8(1), 83–88 (2016) 68. Sun, D.-Z., Mu, Y., Susilo, W.: Man-in-the-middle attacks on secure simple pairing in Bluetooth standard v5.0 and its countermeasure. Pers. Ubiquit. Comput. 22(1), 55–67 (2018). Springer 69. Szlósarczyk, S., Wendzel, S., Kaur, J., Meier, M., Schubert, F.: Towards suppressing attacks on and improving resilience of building automation systems – An approach exemplified using BACnet. In: Proceedings of Sicherheit 2014. LNI, Bd. 228, S. 407–418. Gesellschaft für Informatik (2014) 70. Tawalbeh, L.A., Tawalbeh, H.: Lightweight crypto and security. In: Song, H., Fink, G.A., Jeschke, S. (Hrsg.) Security and Privacy in Cyber-Physical Systems: Foundations, Principles, and Applications. Wiley-IEEE Press, Hoboken (2018) 71. The guardian: Volvo admits its self-driving cars are confused by Kangaroos (2017). https://www. theguardian.com/technology/2017/jul/01/volvo - admits - its - self - driving - cars-are-confused-bykangaroos. Zugegriffen am 01.06.2018 72. Tonejc, J., Güttes, S., Kobekova, A., Kaur, J.: Machine learning methods for anomaly detection in BACnet networks. J. Univers. Comput. Sci. (J.UCS) 22(9), 1203–1224 (2016)

Literatur

337

73. Ullrich, J., Voyiatzis, A.G., Weippl, E.R.: Secure cyber-physical production systems: Solid steps towards realization. In: 2016 1st International Workshop on Cyber-Physical Production Systems (CPPS), S. 1–4. IEEE (2016) 74. Wang, Y., Nikolai, J.: Mey management in CPSs. In: Song, H., Fink, G.A., Jeschke, S. (Hrsg.) Security and Privacy in Cyber-Physical Systems: Foundations, Principles, and Applications. Wiley-IEEE Press, Hoboken (2018) 75. Wendzel, S.: Tunnel und verdeckte Kanäle im Netz. Springer-Vieweg (2012) 76. Wendzel, S.: How to increase the security of smart buildings? Commun. ACM 59(5), 47–49 (2016) 77. Wendzel, S., Kasem-Madani, S.: IoT security – the improvement-decelerating ,Cycle of Blame‘. J. Cyber Secur. Mobil. (JCSM) (2016). http://doi.org/10.13052/popcas010 78. Wendzel, S., Kahler, B., Rist, T.: Covert channels and their prevention in building automation protocols – a prototype exemplified using BACnet. In: Proceedings of the GreenCom 2012, iThings 2012 and CPSCom 2012, S. 731–736. IEEE (2012) 79. Wendzel, S., Zwanger, V., Meier, M., Szlósarczyk, S.: Envisioning Smart Building Botnets. In: Proc. GI Sicherheit 2014. LNI, Bd. 228, S. 319–329. GI (2014) 80. Wendzel, S., Tonejc, J., Kaur, J., Kobekova, A.: Security of smart buildings. In: Song, H., Fink, G., Jeschke, S., Rosner, G. (Hrsg.) Security and Privacy in Cyber-Physical Systems: Foundations and Applications, Kapitel 16. Wiley, Hoboken (2017) 81. Wendzel, S., Mazurczyk, W., Haas, G.: Steganography for cyber-physical systems. J. Cyber Secur. Mobil. (JCSM) 6(2), 105–126 (2017). River Publishers 82. Wiens, K., Gordon-Bryne, G.: The fight to fix it. IEEE Spectr. 54(11), 24–29 (2017). IEEE 83. Yung, J., Debar, H., Granboulan, L.: Security of cyber-physical systems: An old idea – security issues and mitigation in ethernet POWERLINK, AIRBUS Group Innovations & Télécom SudParis, Vortragsfolien vom 10. Februar 2017 84. Zhu, B., Sastry, S.: SCADA-specific intrusion detection/prevention systems: A survey and taxonomy. In: Proceedings of the 1st Workshop on Secure Control Systems (SCS), Bd. 11 (2010)

Anhang A: Wichtige wissenschaftliche Zeitschriften und Tagungen

In diesem Anhang finden Sie eine Liste von bedeutsamen Fachzeitschriften und Tagungen, die Werke aus dem Bereich Netzwerksicherheit, IoT-Sicherheit und verwandten Themen publizieren. Diese Liste erhebt keinen Anspruch auf Vollständigkeit, sollte allerdings die zentralen Publikationsorgane abdecken.

A.1

Bedeutsame Fachzeitschriften

Es gibt in der Informatik diverse Fachzeitschriften, die sämtliche Themengebiete adressieren, also auch solche außerhalb der IT-Sicherheit. Die folgende Liste enthält solche Fachzeitschriften, die aus Sicht des Autors auch immer wieder hervorragende Beiträge im Bereich Netzwerksicherheit und IoT-Sicherheit beinhalten. Die Reihenfolge der Liste trifft keine Aussage über die Wertigkeit der Zeitschriften. • Communications of the ACM, https://cacm.acm.org/ • ACM Computing Surveys, https://csur.acm.org/ • IEEE Computing Surveys & Tutorials, http://ieeexplore.ieee.org/xpl/RecentIssue.jsp?punumber=9739 • Proceedings of the IEEE http://proceedingsoftheieee.ieee.org/ • Journal of the ACM (JACM) https://dl.acm.org/pub.cfm?id=J401 • Springer Computing https://www.springer.com/computer/journal/607

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2018 S. Wendzel, IT-Sicherheit für TCP/IP- und IoT-Netzwerke, https://doi.org/10.1007/978-3-658-22603-9

339

340

Anhang A: Wichtige wissenschaftliche Zeitschriften und Tagungen

• IEEE Computer https://publications.computer.org/computer-magazine/ • Journal of Universal Computer Science (J.UCS), http://www.jucs.org • Springer Frontiers of Computer Science https://www.springer.com/computer/journal/11704 Erwähnung finden kann an dieser Stelle zudem die Zeitschrift Informatik Spektrum (Springer), die von der Gesellschaft für Informatik herausgegeben wird. Der Impact Factor der Zeitschrift ist relativ gering, doch kann sie als wichtiges Kommunikationsmedium der deutschen Informatik-Community betrachtet werden; verfügbar unter: https://www. springer.com/computer/journal/287. Renommierte Journale aus dem Bereich IT-Sicherheit sind unter anderem: • IEEE Transactions in Information Forensics and Security (T-IFS), http://ieeexplore.ieee.org/xpl/RecentIssue.jsp?punumber=10206 • Elsevier Computers & Security, https://www.journals.elsevier.com/computers-and-security/ • ACM Privacy and Security (TOPS) https://tops.acm.org/ • IEEE Security & Privacy Magazine, http://ieeexplore.ieee.org/xpl/RecentIssue.jsp?punumber=8013 • IEEE Transactions on Dependable & Secure Computing, http://ieeexplore.ieee.org/xpl/RecentIssue.jsp?punumber=8858 • Springer EURASIP Journal of Information Security, https://jis-eurasipjournals.springeropen.com/ • Wiley Security and Communication Networks (SCN), Jahrgänge bis 2016 verfügbar unter http://onlinelibrary.wiley.com/journal/10.1002/(ISSN)1939-0122. Seit 2017 gehört diese Zeitschrift zu Hindawi und ist unter der Adresse https://www.hindawi.com/journals/scn/ verfügbar. • Journal of Cryptology, https://link.springer.com/journal/145 • ACM Transactions on Cyber-Physical Systems (TCPS), https://tcps.acm.org/, nicht spezifisch für die IT-Sicherheit von CPS, allerdings stellt die IT-Sicherheit derselben das Thema vieler dort erschienener Beiträge dar. • IEEE Internet of Things Journal, http://ieeexplore.ieee.org/xpl/RecentIssue.jsp?punumber=6488907, ebenfalls nicht auf IT-Sicherheit beschränkt, allerdings stellt auch hier IT-Sicherheit ein wichtiges Thema der in dieser Zeitschrift erschienenen Artikel dar. • Datenschutz und Datensicherheit (DuD), https://www.springer.com/computer/journal/11623, deutschsprachige Zeitschrift, die sich auch mit rechtlichen und politischen Aspekten des Datenschutzes befasst.

Anhang A: Wichtige wissenschaftliche Zeitschriften und Tagungen

A.2

341

Bedeutsame Fachtagungen

Nennenswerte Tagungen aus dem Bereich der Netzwerksicherheit/IoT-Sicherheit sind unter anderem: • ACM Conference on Computer and Communications Security (CCS), https://sigsac.org/ccs.html • ASIA CCS (unterschiedliche Webseiten, je nach Jahr) • IEEE Security & Privacy Symposium (S&P), https://www.ieee-security.org/index.html • IEEE European Security & Privacy Symposion, https://www.ieee-security.org/ • USENIX Security Symposion, https://www.usenix.org/conferences • Usenix Symposium On Usable Privacy and Security (SOUPS), https://www.usenix.org/conferences • Network and Distributed Systems Symposium (NDSS), https://www.ndss-symposium.org/ • European Symposium on Research in Computer Security (ESORICS) • Annual Computer Security Applications Conference (ACSAC), https://www.acsac.org/ • ACM Symposium on Applied Computing • IFIP Information Security Conference & Privacy Conference (SEC) https://www.ifipsec.org/ • International Conference on Availability, Reliability and Security (ARES), https://www.ares-conference.eu/ • IEEE Local Computer Networks (LCN), https://www.ieeelcn.org/ • Privacy Enhancing Technologies Symposion (PETS), https://petsymposium.org/ • IEEE Conference on Communication & Networks Security (CNS), http://ieee-cns.org • GI SIG SIDAR Conference on Detection of Intrusions and Malware & Vulnerability Assessment (DIMVA), https://www.dimva.org/ Es existieren zudem nationale Tagungen, insbesondere kann hierbei die Tagung des Fachbereichs Sicherheit der Gesellschaft für Informatik (GI SICHERHEIT) genannt werden. Bekannt ist zudem die eher praxisnahe Tagung D-A-CH Security. Neben diesen breiter aufgestellten Tagungen existieren diverse themenspezifische Tagungen. Auf selektierte Themenkomplexe, die Vertiefungskapitel dieses Buches oder zentrale Themen der IT-Sicherheit betreffen, möchte ich im Folgenden gezielt eingehen.

342

Anhang A: Wichtige wissenschaftliche Zeitschriften und Tagungen

A.2.1 Covert Channels, Information Hiding, Steganografie, Cybercrime • Workshop on Criminal Use of Information Hiding (CUING), siehe Links unter http://www.cuing.org. • Information Hiding & Multimedia Security (IHMMSec), https://www.ihmmsec.org/ • Information Hiding Workshop (IH); nicht mehr aktiv, ersetzt durch o. g. IHMMSec. Die Proceedings sind bei Springer verfügbar. Ursprünglich war der IH-Workshop der vermutlich wichtigste auf dem Gebiet und viele Schlüsselpublikationen wurden im Rahmen dieses Workshops publiziert. • International Workshop on Cyber Crime (IWCC) • International Conference on Communications & Multimedia Security (CMS) (bis 2015, div. Grundlagenbeiträge), Proceedings bei Springer verfügbar. • International Workshop on Digital Forensics and Watermarking (IWDW)

A.2.2 IoT-Sicherheit • • • • •

ACM Conference on Wireless Network Security (WiSec) Cyber-Physical Systems Security and PrivaCy (CPS-SPC) Workshop Workshop on Internet of Things Security and Privacy (IoT S&P) International Workshop On Cyber-Physical Systems Security (CPS-Sec) IEEE International Conference on Cyber, Physical and Social Computing (CPSCom), fokussiert jedoch nicht ausschließlich die Sicherheit von CPS.

A.2.3 Kryptografie • • • •

International Cryptology Conference (CRYPTO) European Cryptology Conference (EUROCRYPT) International Conference on Cryptology And Network Security (CANS) International Conference on the Theory and Application of Cryptology and Information Security (AsiaCRYPT) • Einige weitere bedeutsame Tagungen sind zudem ICICS, CHES und ICISC.

Sachverzeichnis

A A5/1 123, 124 A5/2 123 AAAA 60 A5-Algorithmus 123 Abbildung (math.) 109 Access Control List 86 Point 211 ACK-Flag 50 Acknowledgement 46 Ack Storm 226 ACL (Access Control List) 86 Active Warden 284, 285 Add Redundancy (Muster) 281 Ad-hoc-Netzwerk 325, 326 AES (Advanced Encryption Standard) 125, 130, 251, 308, 316, 318 Agrarwirtschaft 327 AIDE 260 Air-gapped Covert Channel 284 Aktor 300, 306, 309, 312 Algorithmus asymmetrischer 111 euklidischer 119 symmetrischer 111 Alice 112 ALOHA 22 Altequipment 318 Amplification Attack 309 DNS 232 Slicing 323 Amplification Factor 309 Amplifier Network 220

Anarchiemodell 169 Angreifermodell 112 Anomalieerkennung 200 Anonymität 91 Anonymity Set 91 Anti-Debugging 98 Anti-Forensik 98 Anti Replay Service (ARS) 172 APNIC 32 Application Layer 26 APT (Advanced Persistent Threat) 197, 198 A (Resource Record) 60 Arithmetik, modulare 114 ARP (Address Resolution Protocol) 27, 28, 195, 249 Cache 27 Cache Flooding 213 Cache Poisoning 212, 249 Probe 212 Sicherheit 212, 249 Spoofing 212, 213, 249 ARPANET 95 ArpOn 249 Arpwatch 249 ARS (Anti Replay Service) 172 Artificial Loss (Muster) 280 Asset 85, 204 Authenticity 84 Authentifizierung 89, 264 Authentisierung 89 Authentizität 84, 172, 175, 176, 318 Automobile 325 Availability 84 AXFR 234, 265

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2018 S. Wendzel, IT-Sicherheit für TCP/IP- und IoT-Netzwerke, https://doi.org/10.1007/978-3-658-22603-9

343

344 B BACnet (Building Automation Control Networks) 23, 307, 310, 311, 318, 324 BAN (Body Area Network) 8, 326 Bandwith Amplification Factor 309 Banner 230, 258 Scanner 240 Bedrohung 84 Bell-LaPadula-Modell (BLP) 87 BFR 311 Bijektivität 110 Binary Classification 200 Bind 60, 245 Biometrie 90 BIOS 95 Bit/bit-Einheit 134 Black box testing 192 hat 82 Blacklist 267 Blockchiffre 124 Betriebsmodi 132 Blowfish 125 BLP (Bell-LaPadula-Modell) 87 Bluetooth 319, 327 Bob 112 Body Area Network 8 Bogon-Adresse 252 6Bone 40 BOOTP 238 Bootsektor 95 Border-Router 252 Bot 97 Botnetz 97, 196, 200, 225, 277, 309 Botmaster 97 C&C-Channel 97 IoT 305, 309 Polling 97 Bridge CA 171 Broker 324 Brute-Force 116 Angriff 140, 143, 251 BSC (Binary Symmetric Channel) 15 Bus-Topologie 9 C CA 22, 166 Caesar-Chiffre 113

Sachverzeichnis Kryptoanalyse 116 CAN 325 CAPTCHA 205 Cargo 297 CARP (Common Address Redundancy Protocol) 245 Carrier Sense 22 CA-Zertifikat 167 CBC (Cipher Block Chaining) 132 CBC-MAC 149 CCM-Mode 149 CCM*-Mode 149 CD 22 Certificate Authority 166 Registry 167 Repository 167 Revocation List 167, 170 CFM (Cipher Feedback Mode) 133 CGA (Cryptographically Generated Address) 253, 326 Chain of Trust 167 Challenge-Response-Verfahren 90 Change-of-Value 324 Chiffre, polyalphabetische 113 Chosen-ciphertext-Angriff 112 Chosen-plaintext-Angriff 112 Chronogramm 277 CIA 81 CIA-Triade 83, 328 Cipher Block Chaining 132 Feedback Modus 133 Ciphertext-only-Angriff 112 Cloud 328 Kanal, verdeckter 283 CNAME 60 CO2 246 CoAP 319 Coderate 138 Codesymbol 17 Collision Avoidance 22 Detection 22 Compartment (BLP) 88 Confidentiality 83 CONNECT 54 Connection-Hijacking 235, 255 Connect-Scan 227

Sachverzeichnis COPACOBANA 130 CoRE-Link-Format 320 Counter-Modus 133 Cover Object 276, 277 Covert Channel 89, 277 Covertness 286 CPS (Cyber-physical System) 297 Cracker 82 Creeper 95 Cross Certification 171 Cryptographically Generated Addresses 253 Crypto Wars 109 CS (Carrier Sense) 22 CSMA (Carrier Sense Multiple Access) 22 CSMA/CA (CSMA/Collision Avoidance) 22 CSMA/CD (CSMA/Collision Detection) 22 CTR-Mode 133 CUING (Criminal Use of Information Hiding) 98, 277 Cyberkrieg 301 Cycle of Blame 301

D DAC (Discretionary Access Control) 85, 86 DALI 307 Darknet 205 Data Freshness 327 Datagramm 18, 25 Dateisystem-IDS 150 Datenexfiltration 277 DDC (Direct Digital Control) 306 DDoS 196, 218-220, 232 DEA (Data Encryption Algorithm) 125 Deep Crack 130 Default Deny 254 Definitionsbereich 110 DELETE 54 Denial-of-Service 195, 247 Permanent DoS 196 DES (Data Encryption Standard) 109, 125, 308 Funktionsweise 126 Historie 126 Sicherheit 130 3DES 125, 130 Destination-Option 43 Desynchronisation 226 Detektion, signaturbasierte 286

345 DHCP (Dynamic Host Configuration Protocol) 53 Diffie-Hellman-Schlüsselaustausch 153 Diffserv 30 Diffusion 126 dig 63, 64 Dining Cryptographers 183 Direct Digital Control 306 Trust 168 Distributed DoS 196 djbdns 246 DNS (Domain Name System) 58 Amplification 266 Angriffe 232 Cache Poisoning 233, 266 Cookies 233 DDoS 265 Header 61 Sicherheit 232, 265 Spoofing 233 DNSCurve 266 DNSKEY 60, 266 DNSSec 60, 266 Domain 58, 59 Fuzzing 197 Name System 58 dom-Relation 88 Don’t-Fragment-Flag 30 DoS 82, 195, 218, 232, 247, 254, 314 IoT 298, 308 Downgradeangriff 314, 316 Dronen 296 DSCP 30 Dual-use Good 108 Dumpster Diving 94 Duplicate Address Detection 224, 253 Duqu 313

E EAP (Extensible Authentication Protocol) 250 Eavesdropping 210, 327 ECB (Electronic Code Book) 132 ECHELON 94 Echtzeit 326 ECN (Explicit Congestion Notification) 30, 325 EDC (Error Detection & Correction) 14 EEG 327

346 EFAIL 267 egress-Filtering 254 eHealth 297, 326 EIB (European Interface Bus) 316 EIBSec 316 Einmalpasswort 150, 260 Electronic Codebook 132 Healthcare 326 E-mail 65 Angriffe 234 Sicherheit 266 Enigma 120 EnOcean 192, 307, 318 Entropie 135 bedingte 136 Kryptografie 137 Entscheidungsgehalt 134 Eratosthenes 154 Erpressungstrojaner 108 ESP (Encapsulating Security Payload) 175 EtherCAT 313 E-Waste 305 Exploit 97, 196, 200, 205, 245 EXPN 235, 268

F 2FA 90 fail2ban 260 False Negatives 200 Positives 200 Farming 327 Fehlererkennung 14 Feistel-Netzwerk 127 FIDS (Filesystem Intrusion Detection System) 150, 199 Filesystem IDS 199 File Transfer Protocol (FTP) 73 Financial IoT 297 FIN-Flag 50, 52 Finger 238 Fingerprinting 214, 255 FIN-Scan 228 Fin-spy Mobile 278 Firewall 198, 252, 254 Firmware 95 Fitnesstracker 328

Sachverzeichnis Flame 313 FlexRay 325 Flooding 9 Flow Label 40 Flusskontrolle 37, 48 Forensik 329 Fork Bomb 96 Fracht 297 Fraggle Attack 219 Fragment 30, 33 Offset 33 Fragmentation-Scan 229 Frame 14 Collissions (Muster) 281 Framekollissionen 281 Friedman-Angriff 119 FTP (File Transfer Protocol) 73, 236 Fuzzing 192, 314, 315 Fuzzy-Domains 233

G Gap inter-packet 287 inter-protocol 287 Gateway 24 GCM (Galois/Counter Mode) 149 Gebäudeautomation 306 Geburtstagsangriff 143 Geburtstagsparadoxon 143 Geheimnis, geteiltes 183 GENEVE 283 GET 54 Gewerk (Gebäudetechnik) 306 GMAC (Galois Message Authentication Code) 149 GnuPG (GNU Privacy Guard) 170 GPG (GNU Privacy Guard) 266 GPS (Global Positioning System) 192 Grey hat 82 Greylisting 267 GSM (Global System for Mobile Communication) 123, 284

H h2 58 h2c 58 Hacker 82

Sachverzeichnis Half-Open-Scan 228 Hamming-Code 20 Handshake 49, 50 Hashbaum 152 Hashed MAC 149 Hashfunktion 89, 141, 257 Aufbau 148 Hashwertlänge 144 HEAD 54 Header 25 Hiding Patterns 279 HIDS (Host-based Intrusion Detection System) 199, 205, 260 Hijacking 226, 313 Hitlermühle 120 HMAC (HashedMAC) 149, 172 HMI (Human Machine Interface) 312, 314 Homoglyphe 234 Honeynet 202 Honeypot 202 High-interaction H. 203 ICS 315 Low-interaction H. 203 Hop 29 Limit 41 Host 55 Host-based IDS 199 Hot Standby Router Protocol (HSRP) 245 HSRP (Hot Standby Router Protocol) 245 HTTP (Hyper-text Transfer Protocol) 54, 259, 264 Header 55 Referrer 231 Sicherheit 231 HTTP/2 58 Hub 14 Huffman-Kodierung 16 Hybrides IDS 200

I IANA (Internet Assigned Numbers Authority) 30, 32 ICMP (Internet Control Message Protocol) 35, 195 Echo 35 Rate Limit 252 Sicherheit 218

347 ICMPv6 43 Duplicate Address Detection 224, 253 Sicherheit 221, 224 ICS (Industrial Control System) 312, 315 ICV (Integrity Check Value) 174 IDEA (International Data Encryption Algorithm) 125 Identitätsdiebstahl 90 IDS (Intrusion Detection System) 199, 220, 254, 315 IEEE 802.1X 250, 251 IGMP (Internet Group Management Protocol) 39 IGMPv2 39 IGMPv3 40 IHL (Internet Header Length) 29 IKE (Internet Key Exchange) 172, 176 ILOVEYOU-Virus 96 IMAP (Internet Message Access Protocol) 67, 234 Industrial IoT 297 Industrie 4.0 301 Industriesteueranlage 297, 312 Informationsgehalt 135 Informationsrate 138 Informationstheorie 133 Initial Sequence Number (ISN) 47, 49, 51 Injektivität 110 Integrität 172, 175, 176 Inter-arrival Time 278, 286 Internet of Cows 327 der Dinge (IoT) 295 Header Length 29, 30 Key Exchange 172 Layer 23 Relay Chat 73 Internetzensur 94, 277 Interpacket Times (Muster) 280 Intervallzeit 278, 286 Introducer 170 Intrusion Detection System (IDS) 199 Intrusion Prevention System (IPS) 199 IoT (Internet of Things) 295 DoS 308 Forensik 329 Healthcare 326 ICS 312 Industriesteuerung 312

348 Landwirtschaft 327 Netzwerkprotokolle 299, 316, 319 Patching 305 Sicherheit 298 Smart Building 306 Smart Cars 325 Smart Home 306 Standardisierung 303 Verdeckter Kanal 284 IoTroop (Botnetz) 305 IP (Internet Protocol) 10 IP-Adresse 23, 32 IP-Fragmente (Angriffe) 220 IPID 30, 229 IPS (Intrusion Prevention System) 199, 220 IPSec 43, 172, 282 IKE 176 Policy 174 SPD 174 IP-Spoofing 217 iptables 255 IPv4 29, 282 Header 29 ID 30 IPID 30 Options 31 Sicherheit 252 IPv6 40, 224, 282 Extension Header 42 Header 40 Sicherheit 224, 252 IRC (Internet Relay Chat) 73 ISN (Initial Sequence Number) 47, 49, 51, 257 ISO 10

J Jamming 210

K Kanal adaptiver verdeckter 283 binärsymmetrischer 15 Kanaldekodierer 15 Kanalkapazität 286 Kanalkodierer 15, 18 Kasiski-Test 118 Kerckhoffs’sches Prinzip 110

Sachverzeichnis Keylogger 97 Known-plaintext-Angriff 112 KNX (Konnex) 307, 311, 316, 318 Kollision 22 Kollisionsresistenz 142 Kompressionsrate 18 Konfusion 126 KRACK-Angriff 251 Kreuzzertifizierung 171 Kryptoanalyse 108 A5/1 124 Caesar 116 Chiffre, historische 116 DES 130 RC4 123 Skytale 116 Vernam-Chiffre 120 Vigenère-Chiffre 118 Kryptografie 107 asymmetrische 111, 152, 155 Historie 113, 120 Schlüssel 110 Kryptologie 108 Kryptosystem 111 Sicherheit 138

L LAN (Local Area Network) 8 virtuelles 248 Landwirtschaft 327 Layer 11 Lease Time 54 Link Layer 13 Local Area Network 8 Localhost 33, 42 Logic Bomb 96 logrotate 260 LOKI 125 LON 307 LTE 284 LTE-A 284 LUCIFER 125 LWC (Lightweight Cryptography) 317

M MA (Multiple Access) 22 MAC (Medium Access Control) 85, 149, 308

Sachverzeichnis MAC-Filter 247 Malicious Warden 284 Mallory 112 Malware 95 MAN 8 Man-in-the-Middle 193, 221 Master-Slave-Verfahren 23 Maximum Transmission Unit (MTU) 33 Medienzugriff 22 Mehrfaktorenauthentifizierung 90 Mesh-Netzwerk 9 Message Authentication Code 149 Ordering (Muster) 280 Timing (Muster) 280 Metadaten von Protokollen 279 Metamorphie 98 Metropolitain Area Network (MAN) 8 Mikrocode 95 Mikroprotokoll 283 MIME (Multipurpose Internet Mail Extension) 267 MitM (Man-in-the-Middle) 193, 224, 226, 233, 314, 318 Mix 179 M2M 319, 324 Mobile IoT-Systeme 325 Mobilfunk 284 Modbus 307, 308, 318 Monitoring 260 Monoalphabetische Chiffre 113 MQTT 324 MSTP 23 mtree 260 MTU 33 Multilateral Security 80 Multiple Access 22 Multiport-Repeater 14 MX 60

N Nachrichtensenke 15 Nahfeldkommunikation 316 Nanotechnologie 296 NAPTR 60 NAT 40

349 Naturkatastrophe 246 NBS 109 NDP 44 netstat 23 Network Access Layer 13 Address Translation 40 Environment Learning 283 Firewall 199 Intrusion Detection System 200 Pump 288 Netzwerkreichweite 8 Netzwerkscan 215 IoT 308 Portscan 227 TCP-Reverse-Idle-S. 238 Tools (nmap) 216 Netzwerksicherheit 81, 191 Netzwerksteganografie 277, 278 Netzwerktopologien 9 Newsgroup 71 NFC 316 Nicht-Verfolgbarkeit 92 Nicht-Vermehrbarkeit 172 Nicht-Vorhersagbarkeit 122 NIDS (Network Intrusion Detection System) 200, 201, 205, 254, 286, 311, 316, 325 Spezifikation 202 nikito 260 NIST 109, 125 nmap 216, 227 NNTP (Network News Transfer Protocol) 70 Sicherheit 236, 268 No Read-up 87 Write-down 87 Node 14 Nonce 253 Non-propagation 172 Non-repudiation 84 NRU (No Read-up) 87 NS 60 nslookup 63 NULL-Scan 229 Nutzdaten 12 NVGRE 283 NWD (No Write-down) 87

350 O Obfuskation 98 Office of Strategic Services 81 Off-Path-Angreifer 233 Off-Path-Szenario 194 OFM 133 One-Time-Pad 115 One-Time-Password 90, 150 Onion-Routing 179, 180 OpenBSD 255 Open Space Steganography 290 OpenSSH 265 Open System 10 OPTIONS 54 OS-Fingerprinting 255 OSI-Modell 10, 12 OSS (Office of Strategic Services) 81 OTP (One-Time-Pad) 115 OTP (One-Time-Password) 90 Out-of-band Covert Channel 284 Output Feedback Modus 133

P PAC (Physical Access Control) 244 Padding 175 Paket 10 Paritätsbit 18 Passive Warden 284, 285 Passwort 89 Patching 299, 305 Path-MTU-Discovery 36 Pattern combination 282 hopping 282 Payload 12 PCAW (Protocol Channel-aware Active Warden) 288 PCMAIL 238 PDoS (Permanent Denial-of-Service) 196 Permanent DoS 196 Personal Firewall 199 pf-Firewall 255 PGP (Pretty Good Privacy) 170, 266 PHB (Per-hop Behavior) 30 Phishing 197 Physical Access Control (PAC) 244 PKI 166

Sachverzeichnis PLC (Programmable Logic Control) 312 Guard 316 Polymorphie 98 POP(2) 238 POP3 66, 235 Sicherheit 234 Port 24, 26, 45 Portscan 201, 227 UDP 227 Positive Predictive Value 201 POST 54 POWERLINK 313 Precision 201 Primzahl 154 PRISM 95 Prisoner’s Problem 284 Privacy 91 Private Key 152 Privatsphäre 91, 278 Videoüberwachung 327 PRNG (Pseudo Random Number Generator) 121, 123, 124, 156, 177, 251, 322, 323 PROFINET 313 Promiscuous Mode 193 *-Property 87 Protocol Channel-aware Active Warden 288 Channels 283 Fuzzing 192, 314, 315 Hopping Covert Channels 282 Switching Covert Channel 283, 287, 288 Proxy-ARP 28 Proxyserver 261 Pseudonymität 91, 92 Pseudo Random Number Generator (PRNG) 121 PSH-Flag 50, 52 PSK (Pre-shared Key) 250 PTR 60, 63 Public Key 152 Infrastructure 166 Publisher 324 Publish-Subscribe-Verfahren 324 Pump 288 Punkt-zu-Punkt-Verbindung 9 PUT 54 PUT (HTTP) 54

Sachverzeichnis Q QoS (Quality of Service) 30 Quellendekodierer 15 Quellenkodierer 15, 16 Quellensymbol 17

R Rabbit 96 Rainbow Table 145 RAMPART-A 95 Random Value (Muster) 281 Ransomware 96 RARP (Reverse Address Resolution Protocol) 28 Rate Limiting 225, 227, 254, 266 Rate/Throughput (Muster) 280 Rauschen 15 Rauschquelle 15 RBAC (Role-based Access Control) 86 RC4 (Ron’s Code 4) 122, 251 Sicherheit 123 R-Dienste 235 Reaper 95 Recall 201 Reconnaissance 94, 214, 230, 231, 235, 236, 265 aktive 215, 234 passive 214, 234 Record Route 31 Redirect 221 (ICMP) 37, 252, 253 (ICMPv6) 44 Routing, dynamisches 221 Redirect-Angriff 194, 252, 253 Redundanz 138, 245 Regenbogentabelle 145 Re-Invention 100 Relay (E-Mail) 267 Reliability 46 Repeater 14 Replay-Angriff 175, 318 Replay Protection 172 Request for Comments (RFC) 10 Reserved/Unused (Muster) 282 Reset-Angriff 226 Resolving 60 Resource Record 60 Retransmission (Muster) 280

351 Reverse-Idle-Scan 229 RFC (Request for Comments) 10 RFID 296 Ring-Topologie 9 RIP (Routing Information Protocol) 221 Spoofing 221 RIPE 32 RIR 32 rkhunter 260 RNG (Random Number Generator) 121 Role-based Access Control (RBAC) 86 Root Certificate 167 Rootkit 97 Rootserver 59 Router 24, 29 Routing 23 Information Protocol (RIP) 221 Sicherheit 221 Routing-DoS-Angriff 309 Routingprotokoll 195, 221 Routingtabelle 23 RRSIG 60 RSA (Rivest, Shamir and Adleman) 155, 318 RST-Flag 50 RTP (Real-time Transport Protocol) 73 RTT 283 RTU (Remote Terminal Unit) 312

S SA (Security Association) 173 Sabotage 81 SAD 173 Safer 125 Sandbox 204, 259 Sandboxing 312 S-Box 129 SCADA (Supervisory Control And Data Acquisition) 313, 314 Scanning 192, 256 Schadsoftware 95, 196 Schicht (Netzwerkschicht) 11 Schieberegister 124 Schiff 297 Schlüssel 110, 113 Anzahl 111 Aufteilung 183 öffentlicher 152 privater 152

352 Schlüsselaustausch 153 Schlüsselgerät 41 120 Schlüssellänge 109 Schlüsselmanagement 317 Schlüsselraum 139 Schlüsselstrom 121 Schwachstelle 84 Science of Security 100 SCP 73 Script Kiddie 82, 313 SDP (Session Description Protocol) 73 Secure Information Database 173 Modbus 314, 318 Multi-Party Computation 182 Parameter Index 173, 174 Policy Database 174 Security-Association 173 Seed 121 Segment 25, 46 Seitenkanal 277 Selective Forwarding Attack 326 SEND (Secure Neighbor Discovery) 253 Sensitivity 201 Sensor 295, 296, 300, 306, 312 Sequence Modulation (Muster) 281 Sequenznummer 46 SHA-2 318 SHODAN 305, 310, 326 Sicherheit mehrseitige 80 perfekte 115, 139 Sicherheitsrichtlinie 277 Side Channel 277 Sieb des Eratosthenes 154 Signal-to-Noise-Ratio 210 Signatur 201, 202 digitale 157 Signaturdatenbank 286 Sinkhole Attack 309 SIP (Session Initiation Protocol) 73, 319 Size Modulation (Muster) 281 S/Key 260 Skytale-Kryptoanalyse 116 Slotted ALOHA 22 Smart Building 297, 306 Building Botnet 309 Cars 297, 325, 328

Sachverzeichnis City 296 Home 297, 306 Smartphones 278 Smart Transportation 297 Automobile (Smart Cars) 325 SMC (Secure Multi-Party Computation) 182 SMTP (Simple Mail Transfer Protocol) 69, 193, 234, 235 Sicherheit 266 Smurf Attack (IoT) 308 (TCP/IP) 218 Sniffing 193, 210 SNMP (Simple Network Management Protocol) 73 Snort 200, 201, 286 Snowden, Edward 95 SNR 210 SOA (Start of Authority) 60 Social Engineering 197, 236 SOCKS 261 Proxy 262 via UDP 264 Software-Ports 151 SORM 95 Source Route 31 SPAM 233, 267, 309 SPD 174 Spear Phishing 197, 236 Specificity 201 Speicherkanal 278 Sperrliste 167, 170 SPI (Security Parameter Index) 173, 174 Spiegelung 245 SPMC (Secure Multi-Party Computation) 182 Spoofing 193, 194, 318 Spurious Keys 139 Spyware 97 SRTP (Secure Real-time Transport Protocol) 73 SSH (Secure Shell) 73, 235, 259, 260 SSL (Secure Socket Layer) 177 Standardisierung 299 Stateful-Firewall 199 State Keeping 255 Steganografie 97, 98, 275 Anwendungsfelder 277 Detektion 286 Gegenmaßnahmen 284 hybride 282

Sachverzeichnis Limitierung 288 linguistische 275, 290 Wissenschaftlichkeit von 100 Stern-Topologie 9 Storage Channel 278 Stream 46 Stromchiffre 121 Stromversorgung 246 STT 283 Stuxnet 313 Subpixel 182 Subscriber 324 Substitutionsattacke 143 Surjektivität 110 Survivability 317 Switch 14 Sybil Attack 326 SYN-Cookie 258 SYN-Flag 50, 51 SYN-Flooding 226, 257 SYN-Scan 228 syslog 260 System, cyber-physikalisches 297

T Taxonomie 100 TCP (Transmission Control Protocol) 46, 282 Ack Storm 226 Cookie Transactions (TCPCT) 258 Desynchronisation 226 Flow-Control 48 Header 49 Hijacking 226 Portscan 227 Puffer 48 Reliability 46 Reset-Angriff 226 Sicherheit 226, 257 Sicherheitsaspekte 226 SYN-Flooding 226 TCPCT (TCP Cookie Transactions) 258 tcpdump 27, 51 TCP-Spoofing 226 Teardrop Attack 220 Telnet 48, 52, 73, 235 Temperature (Muster) 281 TEMPORA 95

353 Terminologie 100 TFTP 238 Threat 84 Intelligence 204, 205 Three-Way-Handshake 49, 50 Tiertelemetrie 296 Time to Live (TTL) 31 Timing Channel 278 TLD (Top-level Domain) 59 TLS (Transport Layer Security) 177, 267 Topologie 9 Tor 179, 205 ToS 37 TRACE 54 Traffic Class 40 Normalization 200, 289, 311, 316 Traktor 297 Tranquility 89 Transport Layer 24 Transportmodus 172 Transpositionschiffre 113 Treiber 95 Tripple DES 125, 130 Trojanisches Pferd 96 True Negative Rate 201 Negatives 200 Positives 200 Trust 205 Anchor 166 TTL (Time to Live) 31 Tunnel 31, 199 Tunnelmodus 172 Two-Army-Problem 18 Two Factor Authentication 90 TXT 60

U Uberwachung 93 Videoüberwachung 327 UDP (User Datagram Protocol) 45 Header 45 Sicherheit 225 UDP-Flooding 225 Unbeobachtbarkeit 93 Unix-Passwortdatei 150 Unizitätsdistanz 140

354 Unleugbarkeit 84 Untracability 92 Unverkettbarkeit 92 URG-Flag 50 Urgent Pointer 50 Usable Security 99, 299 Usenet 70 USV (Unterbrechungsfreie Stromversorgung) 246 V Value Modulation (Muster) 282 Vandalismus 313 VCS (Visual Crypto System) 181 Verbindlichkeit 84 Verdeckter Kanal 89, 277 Methoden 282 Verdecktheit 286 Verfolgbarkeit 92 Verfügbarkeit 82, 84, 245 Verkettbarkeit 92 Vernam-Chiffre 115 Kryptoanalyse 120 Verschlüsselung 107, 109 homomorphe 182 Versteckmuster 279 Vertrauen 205, 300 Vertraulichkeit 83, 87, 172 Verwundbarkeit 84, 245 Vigenère-Chiffre 115, 118, 119, 139, 140 Kryptoanalyse 118 Virtual Host 55 Virus 95 Visual Crypto System 181 Visuelle Kryptografie 181 VLAN (Virtual Local Area Network) 248 VoIP (Voice over IP) 282 VoLTE (Voice over LTE) 284 VPN 171, 311 VRFY 235, 268 VRRP (Virtual Router Redundancy Protocol) 245 Vulnerability 84 VXLAN 283 W WAN (Wide Area Network) 8 Warden 284, 285

Sachverzeichnis Wardriving 192, 308 Weakness 84 Wearables 297 Web of Trust 169 Website Fingerprinting (WFP) 181 WEP (Wired Equivalent Privacy) 250, 251 Wertebereich 110 WFP (Website Fingerprinting) 181 Whistleblower 95 White hat 82 Whitelist 247, 254, 267 Wi-Fi 250 Protected Access 250 Wide Area Network (WAN) 8 Wired Equivalent Privacy (WEP) 250 Wireless Wardriving 192 Wireshark 237 Wissenschaftlichkeit der IT-Sicherheit 100 WLAN 192, 250 Wormhole Attack 326 Wörterbuchangriff 145 WPA (Wi-Fi Protected Access) 250, 251 WPA-2 192, 250, 251 Wurm 96 Wurzelzertifikat 167

X XCBC (Extended CBC) 149 XMAS-Scan 229 XMPP (Extensible Messaging and Presence Protocol) 73, 319

Z Zeitkanal 278 Zero-Day-Exploit 196 Zertifikat 166 digitales 166 Zertifikationskette 167 ZigBee 192, 308, 318, 319, 327 Zone 59 Zoning 315 Zufallszahlen 121 Zufallszahlengenerator 121, 123, 124, 156, 177, 251, 322, 323 Zugriffskontrolle 85 Zutrittskontrolle 244