Studienbrief 5 Netzwerksicherheit Seite 1 Studienbrief 5 Netzwerksicherheit 5.1 Lernergebnisse In diesem Studienbrief wird Ihnen die Sicherheit in Kommunikationsnetzen näher gebracht. Sie lernen zunächst die Grundlagen von Netzwerken kennen und wissen, dass bei der Netzwerksicherheit der sichere Datenaustausch sowie die Absicherung von Netzknoten zentrale Aspekte sind. Sie kennen die Funktionsweise und Einsatzgebiete von Firewalls und Intrusion Detection Systemen und wissen, welche Angriffe diese verhindern können. Weiterhin erhalten Sie eine detaillierte Einführung in sichere Kommunikationsprotokolle, mit denen die üblichen Schutzziele gewährleistet werden. 5.2 Advance Organizer Netzwerksicherheit ist ein weit gefasster Begriff. Er umfasst unter Anderem den sicheren Entwurf von Netzwerkprotokollen, die sichere Übermittlung von Daten sowie die betriebliche Sicherheit von Netzwerkinfrastrukturen. Netzwerksicherheit beschreibt wie ein Netzwerk und Dienste (z.B. Email) in diesem Netzwerk benutzt werden können, so dass die vorher definierten Sicherheitsziele erreicht werden können. Darüber hinaus wird über das Internet auch Schadsoftware verteilt und einzelne Rechner werden über das Ausnutzen von Schwachstellen infiltriert. Die in diesem Kapitel vorgestellten Technologien sollen dabei helfen, diese Schwachstellen zu minimieren bzw. Angriffe auf IT-Systeme melden. 5.3 Grundlagen Computernetzwerke wie das Internet bestimmen heute einen sehr großen Teil unseres täglichen privaten und geschäftlichen Lebens. Sie werden für fast jede denkbare Anwendung von Telefonie über Online-Banking bis hin zur Steuerung von Atomkraftwerken eingesetzt. Der Vernetzungsgrad nimmt stetig zu, die Art der vernetzten Geräte verändert sich. Vor ein paar Jahren waren nur Computer miteinander vernetzt, heute wird wie selbstverständlich die Netzwerkfähigkeit der Smartphones benutzt. Auch die Vernetzung der Industrieproduktion (Stichwort Industrie 4.0) sowie von Geräten im Haushalt (Smart Home, Smart Meter) bringt Komfort, aber auch erhebliche neue Bedrohungen mit sich. Vernetzung nimmt zu Daher ist die Sicherheit der Netzwerke und auch der Kommunikation von entscheidender Bedeutung für Gesellschaft und Wirtschaftsunternehmen. Dieser Abschnitt beinhaltet eine Einführung in Netzwerke sowie deren zentrale Sicherheitsfragen und thematisiert insbesondere folgende Aspekte: Zwei Schwerpunktthemen 1. Sicherer Datenaustausch: Hierunter ist die Absicherung der Kommunikation bezüglich vorher definierter Schutzziele zu verstehen. Zum Beispiel soll eine E-Mail vom Sender zum Empfänger vertraulich übermittelt werden. Seite 2 Studienbrief 5 Netzwerksicherheit 2. Sichere Netzknoten, insbesondere sichere Endpunkte: Damit ist der Schutz von Netzknoten (z.B. Ihrem Computer oder einem Router) im Hinblick auf die Verfügbarkeit oder unautorisierten Zugriff gemeint. Namen, Adressen In Abbildung 5.1 wird exemplarisch die Kommunikation zwischen einem Browser und einem Webserver dargestellt. Der Browser wird auch als Client bezeichnet, weil dieser eine Anfrage an den Server stellt und dessen Dienste nutzt. Zunächst gibt der Nutzer die für ihn lesbare Adresse des Webservers in seinen Browser ein, die sogenannte URL (URL bedeutet Uniform Resource Locator). In diesem Beispiel will der Nutzer auf den Webserver unter der URL www.webseite.de zugreifen. Im Unterschied zum Menschen adressieren Netzwerkgeräte allerdings mittels maschinenlesbarer Adressen. Im Internet sind dies die Adressen des InternetProtokolls (IP-Adressen). Aktuell werden dabei noch Adressen der Version 4 des Internet-Protokolls (IP) verwendet. Diese haben eine Länge von 32 Bit, die als vier Zahlen der Länge 8 Bit dargestellt werden (d.h. vier Zahlen im Bereich 0 bis 255). Der Webserver aus diesem Beispiel besitzt die IP-Adresse 124.23.45.200. Abb. 5.1: Kommunikation zwischen Client und Webserver mit DNSAbfrage. DNS Für die Umsetzung einer menschenlesbaren URL in eine maschinenlesbare IPAdresse ist ein wichtiges Netzprotokoll zuständig, das Protokoll des Domain Name System (DNS-Protokoll). Bevor der Client auf den Server zugreifen kann, stellt dieser eine DNS-Anfrage an einen DNS-Server. In unserem Beispiel fragt der Client nach der IP-Adresse des Webservers unter der URL www.webseite.de und erhält diese als Antwort zurück. Mit dem Erhalt der IP-Adresse kann der Client anschließend eine HTTP-Anfrage an den Webserver stellen und bekommt als Antwort die Webseite zugesendet, die der Webbrowser auf dem Client verarbeitet und anzeigt. Abb. 5.2: Netzgeräte zwischen Client und Webserver. Forwarding, Routing Wie in Abbildung 5.2 verdeutlicht wird, durchlaufen die Datenpakete auf ihrem Weg vom Client zum Server zahlreiche weitere Netzgeräte, z.B. Switches im lokalen Netz des Client oder Server bzw. Router im Netzsegment der Internet Service Provider (ISP). Jedes dieser Netzgeräte kann die gesamten Informationen sehen, die 5.3 Grundlagen Seite 3 über diesen Knoten laufen. Außerdem muss das Gerät bestimmen, an welche Stelle das Paket weiterzuleiten ist. Dazu werden im Internet die IP-Adressen benötigt. Im lokalen Netz hingegen wird eine spezielle Hardware-Adresse des Geräts verwendet. Diese wird Media Access Control-Adresse (MAC-Adresse) genannt und ist 48 Bit lang und soll eindeutig für jede Netzwerkkarte weltweit sein. Das Weiterleiten der Daten auf einem Zwischenknoten wird Forwarding genannt. Oft existieren alternative Routen für die Weiterleitung von Paketen. Somit muss ein Router entscheiden, zu welchem benachbarten Netzknoten das Paket geschickt werden soll. Die Festlegung der Wege, die die Datenpakete nehmen sollen, wird als Routing bezeichnet. Dazu nutzt ein Router interne Routing-Tabellen, die fortlaufend mit anderen Routern synchronisiert werden. 5.3.1 OSI-Referenzmodell In der Informatik ist Kapselung ein wesentlicher Lösungsansatz zur Reduktion der Komplexität. In Netzwerken haben Sie bereits eine grobe Idee, wie komplex eine Lösung sein muss, damit unterschiedlichste Geräte miteinander kommunizieren können. Daher kapselt die Informatik die Kommunikation in unterschiedlichen Schichten, die jeweils eine dezidierte Funktion haben, deren Komplexität aber einfacher zu beherrschen ist als die Komplexität des ursprünglichen Problems. Das am meisten referenzierte Netzwerkmodell ist das Open Systems Interconnection Model (OSI-Referenzmodell) der internationalen Standardisierungsorganisation ISO. Kapselung Das OSI-Modell dient sowohl der Interoperabilität verschiedener Hersteller als auch der Einordnung und Veranschaulichung der Netzwerkkomponenten samt deren Konzepten, deren Software sowie deren Protokollen. Dazu sind sieben aufeinander folgende Schichten (engl.: layers) definiert, die jeweils genau spezifizierte Aufgaben übernehmen. Jede dieser Schichten kann nur mit einer direkt benachbarten Schicht über eine standardisierte Schnittstelle kommunizieren. Dadurch bleiben Veränderungen in einer Schicht für andere Schichten transparent, solange die Schnittstelle unverändert bleibt. Eine Übersicht über die Schichten des OSI-Modells finden Sie in Tabelle 5.1. OSI-Modell Ebene 7 6 5 4 3 2 1 Name (deutsch) Anwendungsschicht Darstellungsschicht Sitzungsschicht Transportschicht Vermittlungsschicht Sicherungsschicht Bitübertragungsschicht Name (englisch) Application layer Presentation layer Session layer Transport layer Network layer Data link layer Phyiscal layer Beispielprotokolle HTTP, SMTP, FTP Tabelle 5.1: Sieben OSISchichten TCP, UDP IP, ICMP Ethernet Die vier unteren Schichten definieren, wie die Daten mit Hilfe von Netzwerkkomponenten (Switch, Router) über physikalische Leitungen zum gewünschten Zielort übertragen und dort an die Anwendung übergeben werden: 1. Layer 1 ist die Bitübertragungsschicht, welche die einzelnen Bits von einem Netzknoten zum benachbarten Netzknoten transportiert, z.B. über eine Glasfaser oder durch die Luft. Physical layer 2. Die Sicherungsschicht gruppiert als Layer 2 die einzelnen Bits zu einer Dateneinheit zusammen, die Frame heißt. Sender und Ziel werden über ihre jeweilige Hardware-Adresse, die MAC-Adresse, definiert. Eine MAC-Adresse Data Link layer Seite 4 Studienbrief 5 Netzwerksicherheit besteht aus 48 Bit, die als 12 Hexadezimalziffern dargestellt werden, z.B. 04:25:6a:49:98:4e. Durch Prüfsummen im Frame können Übertragungsfehler entdeckt werden. Network layer 3. Auf Layer 3 stellt die Vermittlungsschicht eine logische Verbindung zwischen den beiden Endgeräten her. Die Dateneinheit heißt Paket. Sender und Ziel werden über ihre jeweilige IP-Adresse adressiert. IP-Pakete der Version 4 (IPv4) sind 32 Bit, IPv6-Pakete 128 Bit lang. Beispielsweise lautet eine IPv4Adresse 193.99.144.85. Transport layer 4. Die Transportschicht sorgt für eine tatsächliche Ende-zu-Ende-Verbindung aus Sicht der Anwendung. Sie nimmt auf Senderseite die Daten der oberen Schicht entgegen, segmentiert diese und sorgt dafür, dass die Daten am anderen Endpunkt in richtiger Reihenfolge der oberen Schicht übergeben werden. Die Dateneinheit heißt ebenfalls Paket, die jeweiligen Anwendungen auf Sender- und Empfängerseite werden über Ports adressiert. Ports sind Zahlen der Länge 16 Bit, wobei die Ports 0 bis 1023 sogenannte privilegierte Ports sind, also festen Anwendungen zugeordnet sind1 . Zum Beispiel werden Daten an einen Webserver per HTTP über den Port 80 adressiert. Application Layer Die drei obersten Schichten des OSI-Referenzmodells werden als Anwendungsschichten bezeichnet. Sie befassen sich mit der Darstellung und Separierung der Daten verschiedener Anwendungen. Die wichtigste der drei Schichten ist die Anwendungsschicht, ihre Dateneinheit ist ebenfalls das Paket. Wichtige Anwendungsprotokolle sind HTTP (Hyper Text Transfer Protocol) für die Kommunikation zwischen Browser und Webserver, SMTP (Simple Mail Transfer Protocol) zum Versenden von E-Mails oder FTP (File Transfer Protocol) für den Austausch von Dateien. Protokolle der Anwendungsschicht 5.3.2 Sichere Kommunikationsprotokolle Sicherheitsaspekte spielten in den Anfangszeiten des Internets kaum eine Rolle. Insbesondere bieten die in Abschnitt 5.3.1 genannten Protokolle keinen Schutz vor Angreifern. Das Internet ist aber seit dessen Entstehen in ständiger Weiterentwicklung, so dass im Nachhinein Lösungen zur Sicherung der Kommunikation im Internet konzeptioniert und implementiert wurden. Diese Protokolle sollen in diesem Abschnitt kurz angerissen werden. Zwei wichtige Protokollen werden später im Detail betrachtet. Sicherheitsprotokolle können auf unterschiedlichen Schichten des OSI-Modells konzipiert und eingesetzt werden, nämlich „unten“, „in der Mitte“ oder „oben“: IPSec 1. Die abgesicherte Variante des IP-Protokolls heißt IPSec. IPSec ist auf Layer 3 angesiedelt und bietet die Option, die Schutzziele Vertraulichkeit, Integrität und Authentizität zu erreichen. IPSec wird im Detail in Abschnitt 5.5 behandelt. Sofern IPSec eingesetzt wird, können ab Layer 3 aufwärts alle Daten vor unautorisiertem Lesen oder Verändern abgesichert werden. IPSec setzt also „unten“ im OSI-Modell an. TLS 2. Das Transport Layer Security Protocol (TLS, früher auch SSL) setzt – wie der Name schon sagt – auf Layer 4 auf. Wie auch IPSec bietet TLS die Möglichkeit, die Schutzziele Vertraulichkeit, Integrität und Authentizität zu erreichen. 1 Eine Liste dieser und anderen Ports können Sie unter http://www.iana.org/assignments/ service-names-port-numbers/ einsehen. 5.3 Grundlagen Seite 5 Mit TLS können Anwendungsdaten geschützt werden. Es liegt „in der Mitte“ des OSI-Schichtenmodells. TLS dürfte das heute am weitesten verbreitete Sicherheitsprotokoll sein. In Abschnitt 5.4 wird auf TLS im Detail eingegangen. 3. Auf Anwendungsebene existieren eine Reihe von „spezialisierten“ Sicherheitsprotokollen, also solchen Protokollen, die nur einen ganz bestimmten Anwendungsfall abdecken. Beispiele sind die Secure Shell ssh für den sicheren Zugriff auf einen entfernten Rechner, S/MIME zur sicheren Übertragung von Mails oder DNSSEC als sichere Variante des klassischen DNS-Protokolls. Sichere Anwendungsprotokolle 5.3.3 Netz-basierte Angriffe In diesem Abschnitt lernen Sie kurz wichtige Angriffe in oder unter Nutzung von Netzwerken kennen. Der vermutlich bedeutendste Angriff im Internet zielt auf die Verfügbarkeit von IT-Ressourcen. Mittels eines Denial of Service Angriffs (DoS) wird beispielsweise die Erreichbarkeit des Webservers eines Online-Shops eingeschränkt. Heute werden dazu typischerweise viele hundert oder tausend fremdgesteuerte Geräte genutzt, weshalb auch von einem Distributed Denial of Service Angriff (DDoS) gesprochen wird. Denial of Service Ein verbreiteter Angriff im Netzwerk ist das Sniffing. Darunter ist das unautorisierte Mitlesen von Daten zu verstehen, z.B. weil der Angreifer Zugriff auf einen Netzknoten hat und dort alle Kommunikation spiegelt. Dabei verhält sich der Angreifer passiv und verletzt das Schutzziel Vertraulichkeit. Schutz gegen Sniffing bietet Verschlüsselung (z.B. auf Layer 3 mittels IPSec oder auf Layer 4 mittels TLS). Sniffing Spoofing bezeichnet das Vorgeben einer falschen Identität und verletzt daher das Schutzziel Authentizität. Ein Beispiel ist das Vortäuschen, ein Online-BankingServer zu sein. Typische Protokolle zur Vermeidung von Spoofing sind wiederum IPSec oder TLS. Anzumerken ist an dieser Stelle aber, dass auch dezidierte Protokolle wie etwa DNSSEC existieren, die mittels PKI die Authentizität von DNSServern gewährleisten. Spoofing Ein Man-In-The-Middle-Angriff (manchmal auch Monkey-In-The-Middle-Angriff) ist eine Möglichkeit, einen Spoofing-Angriff durchzuführen. Will Alice z.B. mit Bob kommunizieren, dann setzt sich der Angreifer Oskar in die ’Mitte’ (siehe Abbildung 5.3). Gegenüber Alice tritt Oskar als Bob auf, gegenüber Bob hingegen Man-In-The-Middle Abb. 5.3: Man-In-TheMiddle Angriff als Alice. Weil ein Man-In-The-Middle-Angriff ein prominentes Beispiel für einen Spoofing-Angriff2 ist, wird es ebenso wie Spoofing durch IPSec, TLS oder dezidierte Protokolle verhindert. Unter dem Begriff Port-Scanning wird das Durchprobieren aller Ports auf einem Zielrechner verstanden. Der Angreifer will damit herausfinden, unter welchen Ports auf dem gescannten IT-System ein Dienst erreichbar ist. Port-Scanning ist für sich kein Angriff, es ist vielmehr vergleichbar mit einem ’Anklopfen’ an die Tür, ob jemand zu Hause ist. Angreifer setzen diese Scans jedoch ein um Angriffe 2 Der Angreifer gibt als Quell-IP-Adresse jeweils die Adresse von Alice bzw. Bob an. Port-Scanning Seite 6 Studienbrief 5 Netzwerksicherheit vorzubereiten, weil z.B. unter einem bestimmten Port ein Dienst mit einer bekannten Schwachstelle läuft. Jedoch wird Port-Scanning auch zu legitimen Einsätzen genutzt, um die eigenen IT-Ressourcen auf unerwünscht offene Ports zu prüfen. So könnte z.B. ein unautorisiert betriebener Webserver unter einem anderen Port als die Standardports 80 (HTTP) oder 443 (HTTPS) gefunden und dann abgeschaltet werden. Honeypots low-interactive vs. high-interactive Honeypots werden eingesetzt, um Netz-basierte Angriffe zu analysieren. Ein Honeypot ist ein absichtlich verwundbares System, das nur dem einen Zweck dient, angegriffen zu werden. Der Betreiber des Honeypots kann später die Vorgehensweise des Angreifers analysieren. Hierbei wird zwischen low-interactive sowie high-interactive Honeypots unterschieden. Erstere bieten nur Dienste an (z.B. einen verwundbaren Webserver) und müssen vom Angreifer gefunden und infiltriert werden. Letztere simulieren aktives Nutzerverhalten (z.B. Webbrowsing) und sollen z.B. durch einen Drive-by-Exploit3 infiziert werden. Abb. 5.4: Unterschied zwischen End-to-End und Hop-by-Hop Sicherheit Bei der sicheren Datenübertragung werden die folgenden zwei Ansätze unterschieden: Ende-zu-Ende-Sicherheit 1. Ende-zu-Ende-Sicherheit bedeutet, die gesamte Übertragungsstrecke vom Endgerät des Senders bis zum Endgerät des Empfängers bezüglich der vorher festgelegten Schutzziele abzusichern. Im Fall einer vertraulichen E-Mail bedeutet dies z.B., dass der Sender die Mail auf seinem Gerät verschlüsselt, die verschlüsselte Mail bis zum Gerät des Empfängers übertragen wird und der Empfänger die Mail erst dort entschlüsselt. Hop-by-Hop-Sicherheit 2. Hop-by-Hop-Sicherheit bedeutet, die Schutzziele nur jeweils auf den einzelnen Teilstrecken der Übertragungsstrecke zu erreichen, nämlich von einem Netzknoten zum nächsten. Im Fall einer vertraulichen E-Mail bedeutet dies, dass der Sender eine vertrauliche Verbindung zu seinem Mailserver aufbaut, die Mail selbst aber nicht auf seinem Gerät verschlüsselt (abgesicherter Hop 1). Danach baut der Mailserver eine sichere Verbindung zu dem Empfängermailserver auf (Hop 2) und abschließend der Empfänger zu seinem Mailserv3 Drive-By-Exploits bezeichnen die automatisierte Ausnutzung von Sicherheitslücken auf einem PC. Dabei werden beim Betrachten einer Webseite ohne weitere Nutzerinteraktion Schwachstellen im Browser, in Browser-Plugins oder im Betriebssystem ausgenutzt, um Schadsoftware unbemerkt auf dem PC zu installieren. 5.4 SSL/TLS Seite 7 er (Hop 3). Die Mail selbst liegt im Klartext auf jedem Zwischenknoten vor (als roter Briefumschlag dargestellt). Hop-by-Hop-Sicherheit hat den wesentlichen Nachteil, dass die Datenstrukturen auf Zwischenknoten ungeschützt vorliegen. Zum Beispiel kann ein Angreifer, der auf den sendenden oder empfangenden Mailserver Zugriff hat, die Mail im Klartext lesen. Daher sollte Ende-zu-Ende-Sicherheit bevorzugt werden. Ende-zu-Ende bevorzugen Kontrollaufgabe 5.1: Netzwerkgrundlagen K • Beschreiben Sie einen Spoofing-Angriff mittels des DNS-Protokolls. • Erklären Sie den Unterschied zwischen SHTTP und HTTPS. • Erläutern Sie den Unterschied zwischen Hop-by-Hop und Ende-zuEnde Sicherheit. 5.4 SSL/TLS Im Jahr 1994 veröffentlichte Netscape die erste Version des Protokolls Secure Sockets Layer (SSL). Damals ging es spezifisch um den Aufbau sicherer HTTPVerbindungen. Im Verlauf der Zeit adaptierte die Internet Engineering Task Force (IETF) SSL als Internet Standard für beliebige Protokolle der Anwendungsschicht. Dieser Standard wird mittlerweile von der IETF als Transport Layer Security (TLS) aktiv weiterentwickelt. Da die Kernkonzepte von TLS und SSL identisch sind, wird im Folgenden zur Erklärung der Grundlagen das modernere TLS beschrieben. SSL Mit TLS hat sich ein de facto Internetstandard für die Absicherung von Protokollen der Anwendungsschicht etabliert. Die aktuelle Version ist 1.2, die als RFC 52464 von der IETF standardisiert ist. TLS wird insbesondere für HTTP-Verbindungen genutzt, da das Protokoll von gängigen Webbrowsern unterstützt wird. Dabei fügt TLS eine weitere Schicht zwischen die OSI-Schichten 4 und 5 ein, wobei das Standard-TLS auf Layer 4 das TCP-Protokoll voraussetzt. Sofern eine HTTPVerbindung mit SSL bzw. TLS abgesichert ist, wird von „HTTP over TLS“ oder auch kurz HTTPS gesprochen. TLS 5.4.1 TLS Protokollstack In Abbildung 5.5 sehen Sie, dass TLS aus mehreren Teilprotokollen besteht, die als TLS-Protokollstack bezeichnet werden. Insgesamt existieren fünf TLS-Teilprotokolle, die auf zwei TLS-Schichten angesiedelt sind. Dabei sind vier TLS-Teilprotokolle auf der oberen TLS-Schicht sowie das TLS Record Protocol auf der unteren Schicht. TLS-Protokollstack Das TLS Record Protocol setzt auf TCP und damit auf Layer 4 des OSISchichtenmodells auf und ist das einzige TLS-Teilprotokoll auf der unteren TLS-Schicht, dem TLS-Layer1. Das TLS Record Protocol stellt die operativen Dienste von TLS bereit: auf Senderseite nimmt es die Daten der oberen Schicht entgegen, teilt sie in Datenstrukturen passender Größe und wendet darauf die ausgehandelten Sicherheitsmaßnahmen wie Verschlüsselung und Message Authentication Codes an. Das Ergebnis der Verarbeitung heißt TLS Record. Die TLS Records werden an die TCP-Schicht übergeben. TLS-Layer1 4 http://www.ietf.org/rfc/rfc5246.txt TLS Record Seite 8 Studienbrief 5 Netzwerksicherheit Abb. 5.5: Der TLS Protokollstack TLS-Layer2 Auf TLS-Layer2 gibt es insgesamt vier Protokolle, auf die wir in Abschnitt 5.4.3 noch genauer eingehen: 1. Das TLS Handshake Protocol dient dem Verbindungsaufbau zwischen Client und Server. Außerdem führt dieses Protokoll die Authentifikation durch und handelt die kryptographischen Verfahren sowie Schlüssel aus. 2. Das TLS Change Cipher Spec Protocol signalisiert, auf die gerade im Rahmen des Handshake Protocols ausgehandelten Sicherheitsparameter zu wechseln. 3. Das TLS Alert Protocol ist zuständig für die Behandlung von Fehlern, insbesondere im Rahmen des Handshakes. 4. Das TLS Application Data Protocol leitet die Daten zwischen Anwendungsschicht und TLS-Layer1 durch. Dies ist mittels der beiden Pfeile in Abbildung 5.5 visualisiert. 5.4.2 Sicherheitsparadigmen und CipherSuites Sicherheitsparadigmen TLS soll je nach Wunsch der beiden Kommunikationspartner die Sicherheitsziele Vertraulichkeit, Instanzauthentizität, Datenauthentizität sowie Datenintegrität erreichen. Als potenzielle kryptographische Verfahren stehen daher symmetrische Verschlüsselung (Vertraulichkeit), asymmetrische Public Key Verfahren (Instanzauthentizität) sowie MACs auf Basis von Hashfunktionen (Datenauthentizität und -integrität) zur Verfügung. Dabei realisiert TLS zwei wichtige Sicherheitsparadigmen, die wir zunächst kurz vorstellen und dann erläutern: 1. Verwende einen kryptographischen Schlüssel nur für einen dezidierten Zweck. 2. Tausche möglichst wenig Informationen zu geheimen kryptographischen Schlüsseln über das nicht vertrauenswürdige Internet aus. Einmalschlüssel Wie bereits erwähnt, wird bei einer TLS-Verbindung zur Erreichung der Sicherheitsziele Vertraulichkeit bzw. Datenauthentizität die symmetrische Verschlüsselung bzw. MACs eingesetzt. Das erste Paradigma setzt TLS dadurch um, dass für jedes unidirektionale Sicherheitsziel je ein kryptographischer Schlüssel genutzt wird. Konkret werden für TLS mindestens vier symmetrische Schlüssel benötigt: zunächst zwei Schlüssel für den Client als Sender (zum Verschlüsseln und für 5.4 SSL/TLS Seite 9 den MAC) und zwei weitere für den Client als Empfänger (d.h. für den Server als Sender). Die Empfängerschlüssel des Clients sind die Senderschlüssels des Servers und umgekehrt. Tatsächlich benutzt TLS oft je drei Senderschlüssel pro Seite, insgesamt also sechs. Hintergrund ist, dass für bestimmte Verschlüsselungsmodi ein Initialisierungsvektor benötigt wird. Um das zweite Paradigma zu berücksichtigen, werden diese Schlüssel aber nie über ein unsicheres Medium übermittelt. Stattdessen tauschen Alice und Bob via TLS nur eine einzige Datenstruktur aus: das Pre-Master-Secret (PMS). Das PMS ist eine Basisinformation zwischen Client und Server, mit der die beteiligten Partner dann dezentral zunächst das gemeinsame Master Secret (MS) und daraus ihre symmetrischen Sender- bzw. Empfänger-Schlüssel ableiten. Austausch kryptographischer Schlüssel Die Informationen zu den gewünschten Kombinationen kryptographischer Verfahren aus einem asymmetrischen Algorithmus zum Schlüsselaustausch, der symmetrischen Verschlüsselung und einer Hashfunktion wird bei TLS mittels einer CipherSuite dargestellt. Der Client schlägt beim Verbindungsaufbau eine Reihe von CipherSuites vor, der Server wählt daraus eine CipherSuite aus, die zur Absicherung der Client-Server-Verbindung genutzt wird. Nachfolgend werden ein paar Beispiele für diese Kombinationen vorgestellt. CipherSuite Die CipherSuites in SSL/TLS werden nach einem bestimmtem Muster angegeben. Dieses Muster ist eine Zeichenkette, in der die jeweiligen Abkürzungen der unterschiedlichen Verfahren durch Unterstriche verbunden werden. Für TLS startet die CipherSuite immer mit TLS. Das Muster lautet dann TLS_<KeyExchange>_WITH_<Cipher>_<Mac>, wobei die spitzen Klammern als Platzhalter für Verfahren dienen. Die drei Bereiche bedeuten: 1. KeyExchange: Diese Bezeichnung aus dem TLS-Standard ist leider irreführend, da zwei Aufgaben mit diesem Feld beschrieben werden: das Verfahren zum Austausch des Pre-Master-Secrets (PMS) (d.h. für den Schlüsselaustausch) sowie das asymmetrische Verfahren zur Instanzauthentifikation. Je nach Verfahren ist dazu die Angabe eines oder zweier asymmetrischer Verfahren notwendig. 2. Cipher: Gibt das symmetrische Verschlüsselungsverfahren zur Verschlüsselung der TLS Records an. Ist die Schlüssellänge nicht durch das Verfahren festgelegt, wird sie an dieser Stelle noch angegeben. Sofern die Chiffre eine Blockchiffre ist, wird zusätzlich der Betriebsmodus (oft CBC, GCM) angegeben. 3. Mac: Gibt das Hashverfahren zur Berechnung des MACs zur Datenauthentizität und -integrität der TLS Records an. In Beispiel 5.1 werden einige konkrete CipherSuites aus TLS 1.2 vorgestellt. Seite 10 B Studienbrief 5 Netzwerksicherheit Beispiel 5.1: CipherSuites von TLS 1.2 gemäß RFC 5246 In der folgenden Tabelle finden Sie einige standardisierte CipherSuites aus dem Standard TLS 1.2. Eine komplette Liste der standardisierten CipherSuites können Sie RFC 5246a entnehmen. -----------------------------------------------------------------------Cipher Suite Key Cipher Mac Exchange 5.4 SSL/TLS Seite 11 TLS_NULL_WITH_NULL_NULL NULL NULL NULL TLS_RSA_WITH_RC4_128_MD5 RSA RC4_128 MD5 TLS_RSA_WITH_RC4_128_SHA RSA RC4_128 SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA RSA 3DES_EDE_CBC SHA TLS_RSA_WITH_AES_128_CBC_SHA RSA AES_128_CBC SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 DHE_RSA AES_128_CBC SHA256 ------------------------------------------------------------------------ Das erste Beispiel nutzt keine Sicherheitsmechanismen: weder Client noch Server authentisieren sich, es wird weder eine symmetrische Chiffre noch ein MAC genutzt. Beim zweiten Beispiel steht RSA für den Schlüsselaustausch und die Instanzauthentifikation. Der Schlüsselaustausch geschieht wie folgt: Der Client wählt das PMS und verschlüsselt dieses mit dem öffentlichen RSA Schlüssel des Servers. Anschließend wird dieser Chiffretext an den Server geschickt. Die Authentifikation des Servers geschieht implizit durch Nachweis der Kenntnis des PMS. Als symmetrische Chiffre wird die Stromchiffre RC4 mit einer Schlüssellänge 128 Bit verwendet, der MAC verwendet MD5 als Hashfunktion. In der letzten CipherSuite dient das Diffie-Hellman-Verfahren zum Austausch des PMS. DHE steht dabei für Diffie-Hellman-Ephemeral: Client und Server nutzen jeweils einen einmaligen öffentlichen Diffie-Hellman-Schlüssel. Das RSA-Verfahren dient zur Instanzauthentifikation des Servers. Als symmetrische Chiffre wird AES mit einer Schlüssellänge 128 Bit im CBC-Modus verwendet, der MAC verwendet SHA256 als Hashfunktion. Diese Chiffre ist – eine hinreichende Schlüssellänge für RSA und das Diffie-Hellman-Verfahren vorausgesetzt – als sehr sicher einzustufen. a Der RFC ist https://www.ietf.org/rfc/rfc5246.txt abrufbar. Ab Seite 82 ist eine Liste der in TLS1.2 standardisierten Cipher Suites. 5.4.3 Funktionsweise Dieser Abschnitt beschreibt die Funktionsweise von TLS im Detail. Dabei ist vor allem wichtig zu wissen, welche Aufgaben die einzelnen Protokolle des TLSProtokollstacks übernehmen. Diese wurden bereits kurz in Abschnitt 5.4.1 erwähnt. Zunächst aber sollen die in TLS verwendeten Schlüssel beschrieben werden. Kryptographische Schlüssel, Pre-Master-Secret, Master-Secret In Abschnitt 5.4.2 wurde bereits erläutert, dass TLS sechs symmetrische Schlüssel verwendet und diese dezentral berechnet. Client und Server tauschen nur das Pre-Master-Secret als geheime Information über das unsichere Internet aus. Dient RSA zum Schlüsselaustausch, so bestimmt der Client alleine das PreMaster-Secret (PMS). Es ist in diesem Fall eine 48-Byte lange Datenstruktur: 46Byte stammen von einer Zufallszahl, die verbleibenden zwei Byte sind die TLSVersionsnummer. Der Client übermittelt das PMS an den Server, indem er es mit dem öffentlichen RSA Schlüssel des Servers verschlüsselt. Daraufhin kann nur der Server daraus das PMS mit seinem zugehörigen privaten Schlüssel berechnen. Im Fall von Diffie-Hellman als Schlüsselaustauschverfahren erzeugen beide Seiten Pre-Master-Secret Seite 12 Studienbrief 5 Netzwerksicherheit zunächst ein einmaliges Diffie-Hellman-Schlüsselpaar, aus dem nach dem klassischen Diffie-Hellman-Verfahren das PMS abgeleitet wird. Beide Seiten kennen also das PMS, obwohl dieses nie im Klartext übermittelt wurde. Master-Secret Aus dem Pre-Master-Secret berechnen der Client und der Server dezentral mit Hilfe von Hashfunktionen das 48-Byte lange Master-Secret (MS). Neben dem PreMaster-Secret gehen noch Pseudozufallswerte von Client und Server sowie aktuelle Zeitstempel in das Master-Secret ein. Aus dem MS berechnen beide Kommunikationspartner abschließend die sechs kryptographischen Schlüssel: • Ein symmetrischer Schlüssel KC für die Verschlüsselung der Daten, die der Client an den Server sendet. In der TLS-Notation wird dieser mit client_write_key bezeichnet. • Ein symmetrischer Schlüssel KS für die Verschlüsselung der Daten vom Server. TLS bezeichnet diesen Schlüssel als server_write_key. • Ein symmetrischer MAC-Schlüssel KMAC−C zur Integritätssicherung der TLSRecords, die der Client an den Server schickt. TLS nennt diesen Schlüssel client_write_MAC_key. • Ein symmetrischer MAC-Schlüssel KMAC−S zur Integritätssicherung der Daten, die der Client vom Server empfängt. Die TLS-Notation bezeichnet diesen Schlüssel als server_write_MAC_key. • Im Falle einer symmetrischen Blockchiffre existieren noch die beiden Initialisierungsvektoren client_write_IV sowie server_write_IV. Bitte erinnern Sie sich, dass aus Sicherheitsgründen immer nur ein Schlüssel für eine Operation benutzt wird und niemals ein Schlüssel für mehrere Operationen, da ansonsten die Gefahr besteht, aus den verschlüsselten Daten auf den geheimen, symmetrischen Schlüssel Rückschlüsse zu ziehen. TLS-Layer1 TLS Record Protocol Abb. 5.6: Das TLS Record Protocol Auf TLS-Layer1 gibt es nur das TLS Record Protocol. Eine Übersicht zu diesem Protokoll finden Sie in Abbildung 5.6. Zu den Aufgaben des Record Protocols gehört zunächst die Fragmentierung der Daten des TLS-Layer2 in Fragmente m1 , m2 usw. Ein Fragment ist höchstens 214 Byte groß, also 16 KiB. 5.4 SSL/TLS Seite 13 Jedes Fragment erhält einen Header1, aus dem das TLS-Layer2-Protokoll sowie die TLS-Version hervorgehen. Dieses Fragment samt Header wird komprimiert, sofern das im TLS-Handshake festgelegt wurde. Oft wird keine Komprimierung eingesetzt. Das komprimierte Fragment erhält einen neuen Header2 mit den gleichen Informationen wie Header1. Anschließend wird der MAC über Header2 und komprimiertes Fragment berechnet, danach wird das gesamte Fragment samt Header2 verschlüsselt. TLS-Layer2 Auf TLS-Layer2 sind vier Protokolle vorzufinden, die schon in Abschnitt 5.4.1 kurz erläutert wurden. In diesem Abschnitt werden nun weitere Details beschrieben, insbesondere zum TLS-Handshake. Das TLS Application Data Protocol hat eine einfache Aufgabe, nämlich die Durchleitung der Daten zwischen Anwendungsschicht und TLS-Layer1. Das ist in Abbildung 5.5 durch die beiden Pfeile dargestellt. Das Application Data Protocol stellt also die operative Schnittstelle zur Absicherung der Anwendungsschicht dar. TLS Application Data Protocol Die übrigen drei Protokolle auf TLS-Layer2 heißen TLS Handshaking Protokolle. Diese sind im Rahmen des TLS Handshakes relevant und sie haben keine Schnittstelle zur Anwendungsschicht. Bitte beachten Sie, dass das TLS Handshake Protocol eines der drei TLS Handshaking Protokolle ist und dass Sie die beiden Begrifflichkeiten nicht verwechseln. Im Folgenden werden diese Protokolle kurz vorgestellt: TLS Handshaking Protokolle • TLS Handshake Protocol: Dieses Protokoll dient dem Verbindungsaufbau zwischen Client und Server. Im Rahmen des TLS Handshakes findet die Authentifikation des oder der Kommunikationspartner, das Aushandeln der zu verwendenden kryptographischen Verfahren und der Austausch benötigter geheimer Informationen statt. Dabei sind für die Authentifikation drei Möglichkeiten vorhanden: keine Authentifikation, nur der Server authentisiert sich oder beide authentisieren sich. Eine vierte Möglichkeit, dass sich ein Client an einem nicht-authentisierten Server authentisiert, ist nicht zugelassen. Wenn der TLS Handshake abgeschlossen ist, liegen die kryptographischen Verfahren fest und beide Seiten haben Zugriff auf alle sechs Sitzungsschlüssel. TLS Handshake Protocol • TLS Change Cipher Spec Protocol: Das Change Cipher Spec Protocol umfasst lediglich eine Nachricht bestehend aus dem Klartext-Byte 0x01. Sie wird im Rahmen des TLS Handshakes gesendet. Mit dieser Nachricht signalisiert der Sender, dass er für die folgenden TLS-Records auf die gerade festgelegten Verfahren und Schlüssel umsteigt. TLS Change Cipher Spec Protocol • TLS Alert Protocol: Mit diesem Protokoll werden TLS-spezifische Warnungen an den Kommunikationspartner übermittelt. Eine Alert-Nachricht besteht aus zwei Bytes. Mit dem ersten Byte wird die Schwere der Warnmeldung angezeigt. Wird ein fataler Zustand signalisiert, führt das zum sofortigen Abbruch der Verbindung. Ebenso werden keine neuen Verbindungen für diese Sitzung mehr eröffnet. Das zweite Byte kodiert Hinweise zum Fehler, z.B. dass ein Zertifikat bereits abgelaufen oder zurückgerufen ist. TLS Alert Protocol TLS-Handshake Der Aufbau einer durch TLS gesicherten Verbindung wird auch als TLS-Handshake bezeichnet. Die wesentlichen Ziele des TLS Handshakes sind: Ziele des TLSHandshakes Seite 14 Studienbrief 5 Netzwerksicherheit 1. Festlegung der verwendeten kryptographischen Verfahren für die Absicherung der TLS-Records. 2. Festlegung der Komprimierung bzw. ob überhaupt komprimiert wird. 3. Festlegung, wer sich authentisiert sowie Durchführung der Authentifikation durch den Kommunikationspartner. In den meisten Fällen authentisiert sich nur der Server mittels TLS, es ist allerdings auch zugelassen, dass sich keiner oder beide Seiten authentisieren. Lediglich die Authentisierung eines Clients an einem nicht-authentifzierten Server ist verboten. Denken Sie exemplarisch an einen TLS-Handshake, bei dem ein Nutzer mit seinem Browser auf einen TLS-gesicherten Webserver zugreifen will. Meist authentisiert sich nur der Server gegenüber dem Client mittels TLS, während der Nutzer Passwort-basiert authentifiziert wird. TLS-Handshake im Detail Abb. 5.7: Der TLSHandshake gemäß RFC 5246. Der gesamte TLS-Handshake wird in Abbildung 5.7 gezeigt. Im nachstehenden Abschnitt werden die einzelnen Schritte diskutiert. Client ClientHello Server --------> <-------Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> Application Data <-------<-------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* ServerHelloDone [ChangeCipherSpec] Finished Application Data * Indicates optional or situation-dependent messages that are not always sent. Note: To help avoid pipeline stalls, ChangeCipherSpec is an independent TLS protocol content type, and is not actually a TLS handshake message. ClientHello Zunächst signalisiert der Client dem Server, dass er mit ihm eine TLS-Sitzung aufbauen möchte. Dazu sendet der Client eine ClientHello-Nachricht. Darin teilt der Client die von ihm unterstützten CipherSuites mit. Außerdem werden zur Vermeidung von Replay-Angriffen eine ID sowie eine vom Client gewählte Zufallszahl RND1 an den Server gesendet. ServerHello Der Server antwortet mit einer ServerHello-Nachricht. Darin teilt der Server die von ihm festgelegte CipherSuite für diese Sitzung mit. Außerdem wird die Client-ID sowie seine Zufallszahl RND2 zurückgeschickt. Anzumerken ist, dass der Client lediglich eine Liste der von ihm unterstützten Verfahren sendet und der Server über das Verfahren entscheidet. 5.4 SSL/TLS Seite 15 Soll der Server authentifiziert werden, sendet dieser anschließend mit der Certificate-Nachricht die Zertifikatskette, die mit seinem eigenen Zertifikat beginnt. Durch Angabe geeigneter CipherSuites zeigt der Client, dass sich der Server mittels TLS authentisieren soll (z.B. TLS_DHE_RSA_WITH...). Soll der Server sich nicht authentisieren, unterbleibt die Certificate-Nachricht. Daher ist sie in Abbildung 5.7 als optional markiert. Des Weiteren wird vom Server je nach festgelegter CipherSuite eine ServerKeyExchange-Nachricht gesendet, beispielsweise wenn Diffie-Hellman als Schlüsselaustauschmethode verwendet wird. Im Fall einer CipherSuite der Form TLS_RSA_WITH... sendet der Server diese Nachricht nicht, da der Client das Pre-Master-Secret wählt und RSA-verschlüsselt an den Server schickt (siehe Beispiel 5.1). (Server)Certificate Optional verlangt der Server eine TLS-Client-Authentifikation: dazu sendet er eine CerficateRequest-Nachricht. Zum Abschluss sendet der Server eine ServerHelloDoneNachricht, um dem Client zu signalisieren, dass der Server auf die Client-seitigen Nachrichten wartet. CerficateRequest Sofern der Server eine TLS-Client-Authentisierung wünscht, sendet der Client mittels einer Certificate-Nachricht seine Zertifikatskette an den Server. Andernfalls entfällt diese Nachricht. In jedem Fall sendet der Client eine ClientKeyExchangeNachricht. Im Fall von Diffie-Hellman als Schlüsselaustauschverfahren sendet der Client seinen DH-Public-Key an den Server, im Fall von RSA wählt er das PMS, verschlüsselt dieses mit dem öffentlichen RSA Schlüssel des Servers und sendet es als ClientKeyExchange-Nachricht. Im Falle einer TLS-Client-Authentisierung signiert der Client mit dem zu seinem Zertifikat gehörenden privaten Schlüssel alle bisherigen Handshake-Nachrichten. Er sendet diese Signatur als CertificateVerifyNachricht zum Server. (Client)Certificate Der letzte Schritt des Clients beginnt mit der ChangeCipherSpec-Nachricht, die angibt, dass der Client fortan seine gesendeten Nachrichten mit den ausgehandelten kryptographischen Verfahren und Schlüsseln absichert. Direkt darauffolgend wird eine Finished-Nachricht gesendet, die einen Hashwert enthält, der über alle empfangenen und gesendeten Nachrichten gebildet wird und mit den neuen Sicherheitseinstellungen abgesichert wird. Dadurch zeigt der Client, dass er das PMS kennt. ChangeCipherSpec ServerKeyExchange ServerHelloDone ClientKeyExchange CertificateVerify Finished Der TLS-Handshake wird dadurch abgeschlossen, dass auch der Server den Umstieg der von ihm gesendeten TLS-Records auf die neuen Sicherheitseinstellungen mittels einer ChangeCipherSpec-Nachricht signalisiert. Danach weist der Server durch eine gültig abgesicherte Finished-Nachricht nach, dass auch er das PMS kennt, weil er die daraus abgeleiteten Schlüssel nutzt. Ab diesen Zeitpunkt werden alle Informationen mit den neuen Sicherheitseinstellungen abgesichert: das TLS Application Data Protocol wird genutzt, um Daten zwischen TLS Layer1 und der Anwendungsschicht auszutauschen. 5.4.4 Sicherheit von TLS Eine Sicherheitsbetrachtung des TLS-Verfahrens schließt die Betrachtung von TLS ab. Eine wichtige Beobachtung ist, dass TLS selbst als sicher zu betrachten ist. Allerdings wird in der Praxis oft der Mensch zu einer Fehlhandlung ’motiviert’ (Social Engineering) oder eine Implementierung stellt sich als fehlerhaft heraus. Ein erster wichtiger Punkt zur Sicherheit von TLS ist die Art der Authentifikation. Zunächst bestimmt allein der Server die CipherSuite und damit das Authentifikationsverfahren. Der Client muss also seine Vorschlagsliste auf CipherSuites Authentifikation Seite 16 Studienbrief 5 Netzwerksicherheit beschränken, die er für sicher hält. Weiterhin ist die Prüfung der Zertifikatskette des Public Key des Servers sicherheitskritisch; diese übermittelt der Server mit seiner Certificate-Nachricht. Die Zertifikatskette muss aus vertrauenswürdigen Zertifikaten bestehen, insbesondere mit einem solchen enden. Andernfalls sind Phishing-Angriffe auch über eine HTTPS-Verbindung möglich. Keine Verbindlichkeit Keine Pseudonymität/Anonymität Die übertragenen Daten werden nicht signiert, TLS erzielt also keine Verbindlichkeit von Aktionen. Das ist meist nicht weiter wichtig. Relevanter ist, dass TLS keine Maßnahmen zur Abwehr von Verkehrsflussanalysen bereitstellt, da nur die Nutzdaten in den TCP/IP-Paketen verschlüsselt werden. Das Sicherheitsziel Pseudonymität oder gar Anonymität ist außerhalb des Fokus von TLS. CipherSuite Die Sicherheit des Protokolls hängt auch von den verwendeten kryptografischen Verfahren ab, die die Kommunikationspartner im Handshake miteinander abstimmen. Falls ein Angreifer dafür sorgen kann, dass die Kommunikationspartner schwache Verschlüsselungsverfahren oder schwache Schlüssel aushandeln, könnte er anschließend versuchen, den verwendeten Kommunikationsschlüssel zu brechen. Forward Secrecy Eine wichtige Eigenschaft in diesem Kontext ist Forward Secrecy. Das bedeutet, dass ein in der Vergangenheit ausgetauschtes PMS weiterhin sicher bleibt, selbst wenn ein Private Key (typischerweise der des TLS-Servers) heute kompromittiert wird und die alte TLS-Kommunikation gespeichert wurde. Die CipherSuite TLS_RSA_WITH_... gewährleistet kein Forward Secrecy, weil das PMS mit dem kompromittierten RSA-Private Key berechnet werden kann. Daher verwenden heutige TLS-Verbindungen CipherSuites der Form TLS_DHE_RSA_WITH_..., da die DiffieHellman-Schlüssel genau einmal verwendet werden. Eine Kompromittierung der DH-Schlüssel betrifft also nur die aktuelle Verbindung. TLS ’gebrochen’ Des Öfteren lesen Sie über Angriffe, die SSL/TLS ’gebrochen’ haben sollen. Meist wird nicht das TLS-Konzept selber kompromittiert, sondern der Angreifer hat spezielle Voraussetzungen auf dem Zielrechner oder der Angriff betrifft eine bestimmte Implementierung. Beispiele sind BEAST (hier muss der Angreifer Zugriff auf ein Java Applet haben), CRIME (hier muss Komprimierung eingesetzt werden), Heartbleed (siehe unten) oder der Poodle-Angriff. Poodle-Angriff Letzteren Angriff wird genauer beschrieben. Poodle zielt auf die Rückwärtskompatibilität von TLS ab. Bei diesem Angriff wird veranlasst, dass sich Server und Client auf das nun veraltete SSLv3 Protokoll anstelle von TLS einigen. Dazu muss der Angreifer allerdings als Man-In-The-Middle fungieren. Sofern einer der beiden Kommunikationspartner SSLv3 ablehnt, ist der Angriff nicht möglich. Eine weitere Hürde für den Angreifer besteht darin, dass er diesen Code auf dem Gerät des Opfers ausführen können muss. Das wird beispielsweise durch das Einbauen des Codes in eine unverschlüsselte Web-Seite erreicht, die der Anwender gerade öffnet. Durch eine wohlbekannte Padding-Attacke auf den CBC-Mode kann der Angreifer einzelne Bytes der SSLv3-Verbindung erfahren. Der Angreifer kann somit nicht die ganze SSLv3-Verbindung dechiffrieren, sondern Byte-weise ausgewählte Teile davon. Heartbleed Der Heartbleed-Angriff nutzt eine Schwachstelle in der Heartbeat-Erweiterung der verbreiteten TLS-Implementierung openssl aus. Über eine Heartbeat-Anfrage kann der Client den Server fragen, ob dieser noch verfügbar ist. Dazu wird eine Nachricht gesendet, die der Server wiederholen soll (echo-Nachricht). Die Schwachstelle besteht darin, dass der Client mehr Zeichen vom Server zurückfordert als er sendet. In diesem Fall liest der Server zum Auffüllen seiner echo-Antwort benachbarte Inhalte seines Hauptspeichers aus und sendet diese an den Client. In 5.5 IPSec Seite 17 dem betroffenen RAM-Bereich des Servers können aber sensible Daten (z.B. private Schlüssel) gespeichert werden, weil die Speicherseiten zum openssl-Prozess gehören. Kontrollaufgabe 5.2: TLS 1. Erläutern Sie, was unter ’Forward Secrecy’ zu verstehen ist. K 2. Welche TLS Handshaking Protokolle gibt es? 3. Wozu dient die Finished-Nachricht? 4. Welche Aufgabe hat das TLS Change Cipher Spec Protocol? 5. Erläutern Sie für die folgenden CipherSuites jeweils, welche kryptographischen Verfahren zum Austausch des PMS, zur Instanzauthentifikation sowie zur Datenvertraulichkeit bzw. -integrität genutzt werden. Bewerten Sie auch kurz die Verfahren. a) TLS_RSA_WITH_3DES_EDE_CBC_SHA aus Beispiel 5.1. b) TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 c) Wie funktioniert die Verhandlung bzgl. einer Ciphersuite zwischen den beiden Kommunikationspartnern? Worin sehen Sie bei dieser Verhandlung Probleme? 5.5 IPSec Beim Entwurf von IP wurden keine Sicherheitsmechanismen integriert. Das Internet-Protokoll-Security (IPSec) ist ein Rahmenwerk, welches in einem IP-Netz die Schutzziele Vertraulichkeit, Authentizität und Integrität erfüllen. Dazu werden verschiedene Mechanismen eingesetzt, etwa Verschlüsselung einzelner IP-Pakete und Einfügen eines zusätzlichen Paket-Headers mit einem MAC. IPSec wird in einer Reihe von Standarddokumenten, den Request For Comments (RFCs) definiert. Beim Einsatz von IPSec kann entschieden werden die Daten entweder nur zu Verschlüsseln, nur zu Authentifizieren, oder sie zu Verschlüsseln und zu Authentifizieren. Die IPSec-Spezifikation umfasst dabei drei Protokolle. 1. Das Internet Key Exchange (IKE) für die Autorisierung der Kommunikationspartner und deren Austausch von Schlüsseln bzw. Schlüsselparametern. 2. Das Enrcytped Service Payload (ESP) für den verschlüsselten und integren Datentransfer. 3. Den Authentication Header (AH) für authentifizierten Datenaustausch. Das IKE-Protokoll arbeitet dabei in zwei Phasen. In der ersten Phase wird eine Verbindung mit Sicherheitsparameter ausgehandelt. Die Verbindungen von IPSec werden als Sicherheitsassoziationen (engl.: Security Association (SA)) bezeichnet. Jeder Kommunikationspartner speichert zu seiner SA alle Daten, die für die kryptographische Verarbeitung der zugehörigen Daten notwendig sind. Die Datenstruktur, in der SAs gespeichert werden, heißt Security Association Database (SAD). Security Association Seite 18 Studienbrief 5 Netzwerksicherheit Diese Verbindungen gelten jeweils nur in eine Richtung, sodass für eine bidirektionale Kommunikation von zwei Parteien auch zwei SAs nötig sind. Eine SA zwischen den Kommunikationspartnern beinhaltet die: • Identifikation der Kommunikationspartner z.B. mit IP-Adressen oder Zertifikaten, • Festlegung der eingesetzten Kryptoalgorithmen, • Quell- und Zieladresse im (IP)-Netz für die IPSec-Verbindung, • Zeitspanne, in der eine erneute Authentifizierung erforderlich wird und in der IPSec-Schlüssel zu erneuern sind. Pre-Shared-Keys In Phase 1 werden Parameter, wie die Lebensdauer und die Authentisierungsmethoden für eine IPSec-Verbindung ausgehandelt. Anschließend werden in Phase 2 entweder Zertifikate oder Schlüssel aus einem zuvor vereinbartem Geheimnis, so genannte Pre-Shared Keys (PSK) verwendet um die Autorisierung umzusetzen. Verwendungszweck IPSec wird hauptsächlich zur Realisierung von sogenannten Virtual Private Networks (VPNs) benutzt, welche oft in Firmenumgebungen eingesetzt werden. Definition 5.1: Virtual Private Network D VPN Unter einem VPN wird eine Netzinfrastruktur verstanden, bei der Komponenten eines privaten Netzes über ein öffentliches Netz miteinander Kommunizieren. Dabei entsteht die Illusion, dieses Netz zur alleinigen Verfügung zu haben. Dort existiert in der Regel ein zentrales Firmennetzwerk (engl. enterprise network), welches nicht Teil des Internets ist, sondern ein abgekapseltes Netzwerk. Allerdings benötigen Angestellte einer Firma oft Zugriff auf die Dienste in dem Firmennetzwerk, ohne allerdings direkt mit dem Firmennetzwerk verbunden zu sein. Zum Beispiel kann sich ein Angestellter bei einem Kunden vor Ort befinden und mit seinem Laptop auf eine Datenbank im Firmennetzwerk zugreifen. Ein anderes Szenario wäre, dass Filialen auf einen zentralen Dateiserver zugreifen müssen. Diese Firmennetzwerke sollen natürlich nur für Angestellte der jeweiligen Firma zugänglich sein. Daher werden die VPNs benutzt. Die Daten von einem Computer der mit einem VPN verbunden ist, werden zunächst verschlüsselt bevor diese über das Netzwerk versendet werden. Auf der Gegenseite existiert ein sogenanntes VPN-Gateway, welches die VPN-Verbindung terminiert und die Daten in das Firmennetzwerk leitet und umgekehrt die Daten wieder zum Computer verschlüsselt zurückschickt. Für die verschlüsselte Übertragung zwischen dem mobilen Computer und dem VPN-Gateway wird IPSec ESP benutzt. Das ESP-Protokoll schreibt vor, symmetrische Verfahren zur Verschlüsselung zu verwenden. Da ESP-Pakete mittels IP übertragen werden und somit in beliebiger Reihenfolge zugestellt werden, muss jedes Paket alle Informationen beinhalten, die zur Entschlüsselung notwendig sind. Folglich müssen beim Padding auch Informationen über die Länge und Muster des Paddings im Paket enthalten sein. Wird der CBC-Modus verwendet benötigt jedes Paket einen Initialisierungsvektor. 5.5 IPSec Für IPSec VPNs wird der Tunnelmodus benutzt, da der gesamte Verkehr zum und aus dem Firmennetzwerk durch das VPN getunnelt wird. Im Tunnelmodus wird ein reguläres IP/TCP-Paket erstellt. Anschließend wird dieses Paket mit einem ESP und einem neuen IP-Header versehen. Somit ist für einen Angreifer nicht zu erkennen, was in dem VPN-Tunnel versendet wird, da alles zwischen dem ESP-Header und dem Authentifizierungsheader verschlüsselt wird. Die Authentifizierung die der ESP-Header, bzw. ESP-Trailer in Form der Authentifizierung, mitbringt erstreckt sich aber nicht über das gesamte Paket. Lediglich der ESP-Header, Trailer und die eigentlichen Daten sind authentifiziert. Falls die Authentifizierung des gesamten Paketes gewünscht ist, muss zusätzlich der AH verwendet werden. Anzumerken ist noch, dass bei ESP nur ein Teil des ESP-Trailers verschlüsselt ist, und das der ESP-Header im Klartext übertragen wird, um den Empfänger mit den Informationen in die Lage zu versetzen das Datenpaket korrekt zu verarbeiten. Falls der AH nicht benutzt wird, kann ein Angreifer gefälschte IP-Pakete erzeugen und an einen IPSec-Empfänger schicken, der diese Paket zunächst bearbeiten muss. Diese gefälschten Pakete werden spätestens bei dem Versuch des Entschlüsselns erkannt und verworfen. Jedoch kann ein Angreifer eine Unmenge an gefälschten Paketen senden und dem Empfänger überwältigen. Der Grund, wieso alle gängigen VPNs keinen AH verwenden ist, dass Geräte im Netz existieren, die den Inhalt des IP-Headers verändern. Ein Beispiel hierfür ist der NAT Mechanismus, der in fast allen Routern verbaut ist. Durch diese Veränderungen ist die Authentifizierung des Paketes nicht mehr gültig und das gesamte Paket wird verworfen. Sicherheit von IPSec Zum Abschluss sollen noch Sicherheitsaspekte von IPSec thematisiert werden. IPSec ist ein verbindungsloses Protokoll. Deshalb wird lediglich die Integrität einzelner Pakete aber nicht des gesamten Datenstroms einer Anwendung überprüft. Des Weiteren wird keine Zurechenbarkeit gewährleistet, da zur Authentifikation ein MAC verwendet wird. Damit lässt sich zwar berechnen ob ein Paket zwischen Sender und Empfänger verändert wurde. Jedoch kann keine Zuweisung der Aktion zu einem Subjekt erfolgen, da beide Kommunikationspartner den gleichen MACSchlüssel kennen. Dies wäre nur mit einer digitalen Signatur möglich. Ein Nachteil digitaler Signaturen ist aber, dass diese sehr viel größer als ein MAC sind. Für den Einsatz von IPSec wird eine Spezifikation einer Policy-Datenbank für jede Maschine benötigt. Auf Basis einzelner IP-Adressen und Ports (oder ähnlichem) ist festzulegen, welche Sicherheitsdienste in welcher Ausprägung einzusetzen sind. Eine lückenhafte und unvollständige Spezifikation eröffnet Sicherheitsprobleme. Das AH-Protokoll bietet zwar Authentizität und Integrität aber keine Vertraulichkeit. Mit AH werden auch Daten aus dem IP-Header vor Manipulation geschützt. IPSec schreibt nicht vor, dass für jede Verbindung ein eigener Schlüssel verwendet wird. Bei Host-basierter Schlüsselvergabe bedeutet dies, dass der selbe Schlüssel für alle Datenpakete verwendet wird die über die gleiche Host-zu-Host-Verbindung übertragen werden. Seite 19 Seite 20 K Studienbrief 5 Netzwerksicherheit Kontrollaufgabe 5.3: IPSec 1. Welche Schutzziele werden von IPSec gewährleistet? 2. Welche Angriff wird mittels des Authentication Headers (AH) bei IPSec verhindert? 3. Warum werden in IPSec Message Authentication Codes statt digitaler Signaturen verwendet? 5.6 Firewall-Technologie Im folgenden Abschnitt werden Architekturen und Konzepte der Firewall Technologie vorgestellt. Zunächst sollen die Aufgaben und grundlegenden Funktionen einer Firewall verstanden werden. Anschließend werden technische Details erklärt. Der Begriff Firewall (deutsch: Brandschutzmauer) entstammt aus dem Bereich des Feuerschutzes. Hierbei hat die Brandschutzmauer die Aufgabe ein Übergreifen des Feuers auf weitere bzw. nebenstehende Gebäude zu verhindern und somit den Brand einzudämmen. Eine ähnliche Aufgabe kommt der Firewall in Kommunikationsnetzen zu. Die Netzübergänge sollen von der Firewall abgesichert werden. Es entstehen durch die Anbindung an offene Kommunikationsnetze im privaten und wirtschaftlichen Bereich eine Vielzahl von potentiellen Bedrohungen. Eine Firewall kontrolliert hierbei den Datenfluss zwischen dem lokalen (internen) und dem offenen (externen) Netzsegment. Wie in Abbildung 5.8 zu sehen, findet keine vollständige Isolation statt, wie mit Hilfe einer Brandschutzmauer, sondern die Firewall dient als Zugangs- und Ausgangspunkt für den Datenverkehr. Abb. 5.8: Einsatz einer Firewall zur Kontrolle der Netzübergänge. Quelle: [Eckert] In der Praxis werden häufig der Begriff Sicherheitsgateway oder Firewall-System verwendet. Dieser soll lediglich verdeutlichen, dass für die Absicherung des Netzes mehrere Hard- und Software Komponenten eingesetzt werden, die für unterschiedliche Aufgaben zuständig sind. 5.6 Firewall-Technologie Definition 5.2: Firewall Ein Firewall-System ist zuständig für die Kopplung zweier Netze und stellt sicher, dass jeglicher Datenverkehr zwischen den Netzen durch die Firewall geleitet wird. Sie realisiert eine Sicherheitsstrategie und Zugriffsrestriktionen. Darüber hinaus umfasst sie ggf. Anforderungen an die Protokollierung sowie Seite 21 D Seite 22 Studienbrief 5 Netzwerksicherheit Authentifikation. Von der Firewall werden nur die Datenpakete weiter geleitet, die diese Sicherheitsstrategie erfüllen. Außerdem werden Authentifikationen sowie ein Auditing gemäß der festgelegten Firewall-Policy durchgeführt. Nach dieser Definition ist der Einsatz und die Konfiguration der Firewall an eine Sicherheitsstrategie gekoppelt. Im Umkehrschluss bedeutet dies, dass natürlich die Sicherheit, die die Firewall gewährleistet, von der definierten Sicherheitsstrategie abhängt. Befinden sich Fehler in der Policy oder ist diese unvollständig kann kein geeigneter Schutz sichergestellt werden. Ebenso ist zu bedenken, dass durch eine fehlerhafte Konfiguration der Firewall Sicherheitslücken entstehen können. Der Einsatz einer Firewall garantiert somit nicht automatisch eine höhere Sicherheit. Eine geeignete Sicherheitsstrategie bedarf nicht nur allgemeine Kenntnisse der Firewall-Technologie, sondern auch spezifisches Wissen über die eingesetzten technische Infrastruktur. Zum Beispiel über Schwachstellen der im Einsatz befindlichen Kommunikationsprotokollen oder Netzwerkdiensten. Die Firewall selbst muss ebenso vor potentiellen Angriffen geschützt werden. Eine Minimierung der Bedrohung kann erreicht werden, indem der Firewall-Rechner lediglich mit der nötigten Software ausgestattet wird. Präziser ausgedrückt, bedeutet das den Verzicht von Hardware-Komponenten und Software, wie beispielsweise eine graphische Oberfläche und ähnliches. Anschließend sollen die unterschiedlichen Klassen und Architekturen von Firewalls, sowie deren sicherheitsrelevanten Vor- und Nachteile erläutert werden. 5.6.1 Klassen & Architekturen In der Praxis werden unterschiedliche Architekturen und Klassen von Firewalls verwendet auf die im folgenden Abschnitt detaillierter eingegangen wird. Firewalls werden in die nachstehenden Kategorien klassifiziert: • Paketfilter • Applikationsfilter • Proxie-Firewalls Unterschiedliche Architekturen von Firewalls entstehen durch die Kombination dieser Klassen. Paketfilter Die Klasse der Paketfilter Firewalls arbeitet im OSI-Modell auf der Netzwerk- und Transportebene, d.h. auf den Schichten 3 und 4. Die Überprüfung der Datenpakete, die auf diesen Schichten übertragen werden, erfolgt nach den festgelegten Kriterien der Sicherheitsstrategie. In der Regel arbeitet eine solche Firewall an der Grenze eines vertrauenswürdigen internen Netze und dem Internet. Die für die Kontrollen herangezogenen Daten befinden sich auf der Protokollebene. Da der Paketfilter auf den Ebenen 3 und 4 arbeitet werden die Protokolle TCP/IP und UDP verwendet. Die Überprüfung der Datenpakete erfolgt nach definierten Filterregeln. 5.6 Firewall-Technologie Seite 23 Die Informationen können aus dem Header des entsprechenden Protokolls herangezogen werden. Das bedeutet, die Filterung der Datenpakete kann auf Basis von den IP-Adressen, also der Sender- und Empfängeradresse, den Ports oder spezifischen Header-Flags durchgeführt werden. Ergänzend können auch Daten, die sich nicht im Header des Datenpakets, sondern in den Nutzdaten befinden für die Untersuchung verwendet werden. Ebenso ist eine Plausibilitätsprüfung des Headers möglich. Beispielsweise kann durch die Firewall überprüft werden, ob die behauptete Größe eines Datenpakets der tatsächlichen Größe entspricht, womit sich einige DDoS Angriffe erfolgreich erkennen und abwehren lassen. Zusätzlich zur Weiterleitung und dem Blocken der Datenpakete kann der Paketfilter auf Grund der getroffenen Entscheidung geeignete passive und aktive Maßnahmen durchführen. Beispielsweise kann eine Fehlermeldung an den Absender des blockierten Paketes gesendet werden. In solchen Fällen kann auch ein Eintrag in einer Logdatei erfolgen. Eine solche Datei hilft der Nachvollziehbarkeit zu einem späteren Zeitpunkt oder kann für die Aufbereitung von Statistiken genutzt werden. Auch kann bei entsprechenden Paketen der Administrator durch einen Alarm informiert werden. Bei den aktiven Maßnahmen eines Paketfilters werden Datenpakete gezielt manipuliert. Das heißt der Paketfilter kann unzulässige Optionen oder Kombinationen im Header des Datenpakets entfernen. Zusätzlich hierzu kann mittels NAT (Network Address Translation) und/oder PAT (Port Address Translation) eine neue IP-Adresse oder Portnummer in das Paket eintragen werden. Somit kann das Paket an einen anderen Empfänger, beispielsweise einem Proxy, geleitet werden. Dies hat den Vorteil, dass die Netzinfrastruktur nach außen verschleiert werden kann. Filterregeln sollten dabei möglichst frühzeitig eingesetzt werden. Die Absenderadressen und -ports eintreffender Datenpakete sollten inspiziert werden. Router kennen die Netzwerkadressen derjenigen Netze, über die sie ihre Pakete empfangen. Somit kann als erster Schritt die Sendeadresse des IP-Pakets mit der Netzadresse des Netzes, aus dem das Paket empfangen wurde, abgeglichen werden. Auf diese Weise lassen sich mögliche IP-Spoofing Angriffe erkennen und abwehren. Von außen kommende Pakete, die eine interne Adresse als Absender angeben sollten verworfen werden. Außerdem müssen auch ausgehende Pakete, die keine interne Absenderadresse besitzen, blockiert werden. Sofern eingehende Pakete auf diese Art gefiltert werden, wird von Ingress filtering gesprochen. Falls ausgehende Pakete gefiltert werden heißt dies Egress filtering. Ingress filtering Egress filtering Zu beachten ist, dass die Filterregeln innerhalb einer Filtertabelle meist streng sequentiell abgearbeitet werden. Das heißt, sobald eine Regel auf das zu kontrollierende Paket zutrifft wird diese angewandt und die Analyse beendet. Um Sicherheitslücken auszuschließen muss bei der Aufstellung der Filtertabellen die korrekte Reihenfolge der Regeln beachtet werden. Filtertabellen sollen, sofern möglich, nach dem Erlaubnisprinzip aufgebaut werden welches besagt, dass jeder Typ von Paket zunächst explizit erlaubt werden muss. Das hat zur Folge, dass nur für jedes autorisierte Paket eine eigene Filterregel spezifiziert werden muss. Für alle anderen Pakete sollte eine generelle Sperrregel festgelegt werden, damit alles, was nicht ausdrücklich erlaubt ist, automatisch verboten wird. Die Reihenfolge der Filter sollte so konfiguriert sein, dass Pakete, die ein unbekanntes Protokoll verwenden, abgewiesen werden. Analog zu den Protokollen existieren eine Reihe von Netzdiensten, aus deren unbeschränkter Nutzung Sicherheitsprobleme entstehen können. Beispielsweise Erlaubnisprinzip Seite 24 Studienbrief 5 Netzwerksicherheit kann das unautorisierte Sammeln von Informationen mittels DNS durch das Filtern und Blockieren inverser DNS-Anfragen beschränkt werden. Proxy Firewall Eine einfache, generische Proxy-Firewall ist auf der Transportschicht gemäß OSI angesiedelt und wird deshalb auch Verbindungs-Gateway genannt. Das ProxyKonzept als Stellvertreter wird in der Informatik an unterschiedlichen Stellen verwendet. Im Zusammenhang mit Firewalls funktioniert das wie folgt: Anstatt dass sich ein Benutzer auf einem Vermittlungsrechner einloggen muss, um von dort Zugriffe auf das Internet durchzuführen, werden ihm spezialisierte Dienste auf einem Gatewayrechner angeboten. Diese können vom Benutzer aufgerufen werden und agieren als seine Stellvertreter. Auf diese Weise kann sichergestellt werden, dass ein Benutzer nur eine wohl definierte und beschränkte Menge von Programmen auf dem Gateway nutzen kann. Eine Proxy-Firewall wird in der Literatur zu dem als spezielle Ausprägung eines Applikationsfilters betrachtet. Applikationsfilter setzen jedoch auf einer höheren OSI-Schicht auf. Sowohl Proxy-Filter als auch Applikationsfilter werden üblicherweise auf einem Computer realisiert, der mehrere Netzwerkkarten besitzt. Alle Verbindungen zwischen einem internen und einem externen Netz gehen ausschließlich über diesen Rechner, so dass dieser zur Angriffsabwehr verwendet werden kann. Eine Proxy-Firewall übernimmt eine Stellvertreterfunktion. Gegenüber dem Client tritt Sie als Server auf. Für den Server übernimmt Sie den Part des Clients. Somit agiert die Proxy-Firewall als Vermittler zwischen beiden. Bei einem Verbindungsaufbau wendet sich der Client an die Proxy-Firewall, die die Zulässigkeit des beantragten Verbindungsaufbaus überprüft. Die Proxy-Firewall ist eine eigenständige Softwarekomponente und fähig, Zustandsinformationen zu verwalten und Sicherheitsdienste durchzuführen, die über einfache Kontrollen hinausgehen. Dazu gehören die Authentifikation des aufrufenden Clients und die Protokollierung durchgeführter Aktivitäten. Applikationsfilter Applikationsfilter sind auf der obersten OSI-Schicht, der Anwendungsschicht, angesiedelt. Sie erweitern die Dienste eines Verbindungs-Gateways, indem sie anstelle eines generischen einen dedizierten Proxy-Dienst zur Verfügung stellen. Im Gegensatz zu den Proxies der Transportebene besitzen Applikationsfilter Kenntnisse über die jeweilige Anwendung, die zu filtern sind. Dadurch sind dienst spezifische Kontrollen möglich. Ein anwendungsspezifischer FTP-Proxy kann beispielsweise die Nutzdaten analysieren und zwischen Befehlen, Dateiangaben oder Programmen unterscheiden. Folglich können diese gemäß der festgelegten Sicherheitsstrategie differenziert behandelt werden. Verbietet beispielsweise die Sicherheitsstrategie schreibende Zugriffe auf einen anonymen FTP-Server, so muss der Applikationsfilter die entsprechenden Anfragen und Kommandos filtern. Mit Applikationsfiltern können differenzierte Authentifikationen und Überprüfungen durchgeführt werden. Da die Filter zustandsbehaftet sind, lassen sich Nutzungsprofile erstellen und anhand auffälliger Zugriffsmuster Angriffsversuche auf das zu schützende Netz frühzeitig erkennen. Eine wesentliche Aufgabe von 5.6 Firewall-Technologie Seite 25 Applikationsfiltern ist neben der Überwachung und Filterung auch die anwendungsspezifische Protokollierung von Zugriffen, so dass auf dieser Basis eine Abrechnung der in Anspruch genommenen Dienstleistungen durchgeführt werden kann. Die Kenntnisse über die zu filternde Anwendung ermöglichen beispielsweise, dass ein FTP-Proxy-Server nicht alle übertragenen Datenpakete protokollieren muss, sondern sich auf übertragenen Befehle sowie die Antworten darauf zu speichern. 5.6.2 Sicherheitsaspekte Firewalls zählen zu den häufigsten eingesetzten Schutzkonzepten im Netzwerkbereich. Die vorangegangene Diskussion der verschiedenen Firewall-Typen und -Konfigurationen macht deutlich, dass ein gut konfiguriertes Firewall-System erheblich zur Steigerung der Sicherheit beitragen kann. Die Kombination der verschiedenen Filterungstechniken ermöglicht eine der Sicherheitsstrategie entsprechenden Firewall Konfiguration. Mit korrekt konfigurierten Firewalls lassen sich durch das selektive Verbieten der sicherheitskritischen Dienste und Protokolle solche Angriffe vermeiden, die darauf abzielen, bekannte Schwächen in Netzwerkdiensten oder Kommunikationsprotokollen auszunutzen. Allerdings ist das Konfigurieren eines Firewall-Systems, das spezifische Anforderungen seines Einsatzumfeldes erfüllen soll, eine schwierige Aufgabe. Dazu sind zum einen detaillierte Kenntnisse über Bedrohungs- und Gefahrenspotentiale der verwendeten Software als auch der Betriebssysteme erforderlich. Problematisch ist, dass mit Tunneling Filterregeln einer Firewall umgangen werden können. Sofern die zu tunnelnden Pakete in ein Paket oder in eine Nachricht einkapselt wird und diese von der Firewall als zulässig betrachtet und weitergeleitet wird, können beliebige Daten durch die Firewall hindurch geschleust werden. Die gekapselten Daten werden dann vom Empfänger ausgepackt und weiterverarbeitet. Ein solcher Vorfall ist im Zusammenhang mit Bezahlterminals in den USA im Oktober 2014 vorgefallen. Die Bezahlterminals sammelten Kreditkarteninformationen und sendeten diese mittels DNS-Tunneling weiter. Zusammenfassend können Firewalls als eine pragmatische Antwort auf bestehende Sicherheitsprobleme sowohl der Kommunikationssoftware als auch existierender Betriebssysteme darstellen. Sie versuchen mit gezielten Maßnahmen, bekannte Sicherheitslöcher auszumerzen. Sie werden zwar evolutionär weiterentwickelt, indem kontinuierlich auf aufgetretene Sicherheitsprobleme reagiert und die Firewall-Fähigkeiten entsprechend angepasst werden. Das Kernproblem, also die Designfehler der verwendeten Software und das Fehlen einer systematischen Integration von Sicherheitsfunktionen in den Software-Engineering-Prozess, werden aber mit Firewalls nicht beseitigt. Kontrollaufgabe 5.4: Firewalls 1. Zu welchem Zweck werden Firewalls eingesetzt? 2. Wie können Firewall Filterregeln umgangen werden? 3. Welche Sicherheitspolitik (Security Policy) sollte von einer Firewall umgesetzt werden? K Seite 26 Studienbrief 5 Netzwerksicherheit 5.7 Intrusion Detection Systeme Intrusion Intrusion Detection Systeme Monitoring Intrusion Prevention System Das Wort intrusion wird als Synonym für einen Angriff verwendet. Sogenannte Intrusion Detection Systeme (IDS) erkennen Angriffe auf Computer oder ganzen Netzwerken. Das IDS kann eine Firewall ergänzen oder auch direkt auf dem zu überwachenden Computersystem laufen und so die Sicherheit von Netzwerken erhöhen. Bei diesen Systemen wird grundsätzlich zwischen Host basierenden und Netzwerk basierenden IDS unterschieden (siehe Definition 5.3). Um einen Angriff erkennen zu können werden alle Events in einem Computer bzw. in einem Netzwerk analysiert. Diese Überwachung wird auch als monitoring bezeichnet. Dabei muss ein solches System entscheiden ob ein Event ein Angriff ist oder auf einen Angriff hinweist oder nicht. Erkannte Angriffsversuche können anschließend protokolliert und/oder sofort dem zuständigen Administrator über Alarmmeldungen z.B. via E-Mail angezeigt werden. Als Reaktion auf einen vermuteten Einbruchsversuch können beispielsweise alle nachfolgenden Zugriffe des Angreifers vom Administrator blockiert werden. Geschieht dieses Blockieren automatisch durch das System, wird im allgemeinen von einem Intrusion Prevention System (IPS) gesprochen. Jeder Event kann fälschlicherweise als ein Angriff identifiziert werden (false positive) oder Attacken nicht als solche ausgemacht werden (false negative). Das Ziel von IDS ist somit alle wirklichen Angriffe als Attacken zu erkennen und Events, die auf keine Attacken hinweisen auch als solche zu identifizieren. Definition 5.3: Host und Netz basierte IDS D • Host basierte IDS stellen die älteste Art von Angriffserkennungssystemen dar und wurden ursprünglich vom Militär entwickelt um die Sicherheit von Großrechnern zu garantieren. Dafür muss das Erkennungssystem auf jedem zu überwachenden Computer installiert werden. In diesem Kontext ist als Host jedes System gemeint, auf welchem ein IDS installiert ist. Das Erkennungssystem erhält seine Informationen aus Log-Dateien, Betriebssystemkern-Daten und anderen Systemdaten wie etwa der Registrierungsdatenbank. Sobald in den überwachten Daten ein möglicher Angriff identifiziert wird informiert das Erkennungssystem einen Administrator. • Netz basierte IDS versuchen, alle Pakete im Netzwerk zu analysieren und verdächtige Aktivitäten zu melden. Diese Systeme versuchen außerdem, aus dem Netzwerkverkehr Angriffsmuster zu erkennen. Da in der heutigen Zeit überwiegend IP eingesetzt wird, muss auch ein Angriff über dieses Protokoll erfolgen. Jedoch kann die Datenmenge die Bandbreite des eines IDS übersteigen. Dann müssen Pakete verworfen werden, was keine lückenlose Überwachung mehr garantiert. 5.7.1 Detektionsverfahren Da in diesem Kapitel die Netzwerksicherheit im Fokus liegt, werden Netz basierte IDS und dessen Detektionsansätze genauer betrachtet. Blacklist Ein Netz basiertes IDS überwacht permanent den Netzwerkverkehr um bösartige Aktivitäten zu erkennen. In der einfachsten Form benötigt das Erkennungssystem eine Blacklist, also eine Liste die beispielsweise IP Adressen oder Domains enthält 5.8 Zusammenfassung Seite 27 die mit bösartigen Aktivitäten assoziiert werden. Dieses Erkennungsverfahren wird auch als Reputations basierende Detektion bezeichnet. IDS benutzen zwei verschiedene Verfahren um Angriffe erkennen zu können. Das erste Verfahren wird Signatur basierte Detektion genannt, welches eine Attacke identifizieren kann, sofern der überwachte Netzwerkverkehr mit einer bestimmten und bekannten Charakteristik übereinstimmt. Sogenannte Signaturen beschreiben diese Charakteristiken. Diese können wie bei der Reputations basierenden Detektion lediglich eine IP-Adresse sein. Andere Signaturen können komplexer sein und beispielsweise eine Anzahl von Bytes nach einer bestimmten Zeichenkette in einem bestimmten Protokoll angeben. Das andere Verfahren wird als Anomalie basierte Detektion oder auch Anomalieerkennung bezeichnet. Dieses Verfahren kann Angriffe erkennen, sofern der überwachte Netzwerkverkehr nicht mit einem normalen Netzwerkverkehr Profil übereinstimmt. Dafür muss ein IDS im Vorfeld erlernt haben, was ein normales Netzwerkverkehrs Profil ist. Dazu wird Maschinelles Lernen verwendet und Netzwerkverkehr zum Lernen aufgezeichnet. Signatur basierte Detektion Anomalie basierte Detektion 5.7.2 Sicherheitsaspekte Die Signatur basierte Detektion ist nur so effizient wie die verwendeten Signaturen. Bösartige Kommunikation kann zudem verschlüsselt sein, sodass dieser Ansatz ineffektiv wird. Dieses Verfahren erkennt bereits bekannte Angriffe, sofern eine Signatur vorhanden ist. Neue Angriffe, für die noch keine Signatur vorhanden ist, können nicht erkannt werden. Außerdem ist zu bedenken, dass schlecht definierte Signaturen eine hohe Anzahl von false positives bzw. false negatives erzeugen können. Im Gegensatz dazu kann die Anomalieerkennung auch Angriffe wahrnehmen, die noch nicht bekannt sind, sofern das Verhalten ähnlich zu anderen Angriffen ist. Die Herausforderung von Anomalie basierter Detektion ist geeignete Daten, die normalen Netzwerkverkehr abbilden, für das Maschinelle Lernen zu erstellen. Eine Gefahr ist, dass aufgezeichneter vermeintlich legitimer Netzwerkverkehr bereits bösartiges Verhalten enthält. Eine weitere Problematik ist, dass nicht einfach Netzwerkverkehr mitgeschnitten werden darf, sodass Forscher legitimen Netzwerkverkehr künstlich erzeugen müssen. Kontrollaufgabe 5.5: Intrusion Detection Systeme 1. Definieren Sie den Begriff „Intrusion Detection System“. 2. Beschreiben Sie mögliche Ursachen für einen Alarm eines Intrusion Detection Systems. 3. Nennen Sie die Vor- und Nachteile von Signatur- und Anomalie basierter Detektion. 5.8 Zusammenfassung In diesem Studienbrief wurde das Thema Netzwerksicherheit genauer betrachtet. Die weit verbreitetste Technologie zu Abwehr von Angriffen sind dabei Firewalls. K Seite 28 Studienbrief 5 Netzwerksicherheit Mit Firewalls können bestimmte Pakete die in ein Netzwerk geleitet werden sollen verworfen werden. Firewalls werden dazu verwendet, dass bekannte Sicherheitslücken nicht ausgenutzt werden können, in dem gewissen Anfragen blockiert werden. Allerdings können mit Tunneling diese Filterregeln umgangen werden. Ein weiterer Ansatz Angriffe abzuwehren ist der Einsatz von IDS bzw. IPS, die das gesamte Netzwerk nach Anzeichen einer Attacke überwachen. Sobald etwas auf eine Attacke hinweist können diese Systeme Netzwerkadministratoren warnen oder auch automatisiert eine Verbindung sperren. Die beiden Kommunikationsprotokolle, die in diesem Studienbrief vorgestellt wurden sind zum einen das IPSec und SSL/TLS, die beide eine authentifizierte Kommunikation ermöglichen sowie die Integrität der Datenpakete gewährleisten. Das IPSec Protokoll wird bei der Etablierung von VPNs verwendet. Mit der Einführung des AH-Protokolls kann verhindert werden, dass ein Angreifer gefälschte IP-Pakete versendet. Allerdings wird dieses Konzept nicht verwendet, da Geräte im Netzwerk ggf. den Inhalt des IP-Headers verändern. SSL bzw. TLS übernimmt die Authentifikation der Kommunikationspartner unter Verwendung von asymmetrischen Verschlüsselungsverfahren und Zertifikaten. Weiter ermöglicht das Protokoll die vertrauliche Ende-zu-Ende-Datenübertragung mit Hilfe symmetrischer Verschlüsselungsverfahren unter der Nutzung eines gemeinsamen Sitzungsschlüssels. Außerdem wird die Integrität der transportierten Daten unter Verwendung von MACs sichergestellt. Die Sicherheit des Verfahrens hängt zum größten Teil von den verwendeten kryptografischen Verfahren ab, die die Kommunikationspartner im Handshake miteinander abstimmen. Angriffe wie die Poodle-Attacke verdeutlichen dies.