Das Protokoll arbeitet auf der Netzwerkebene des OSI-Modells und ist daher für Anwendungen „transparent“. Mit anderen Worten, für Anwendungen (z Webserver, Browser, DBMS usw.) hat keinen Einfluss darauf, ob die übertragenen Daten durch IPSec geschützt sind oder nicht.

Betriebssysteme der Windows 2000-Familie und höher verfügen über eine integrierte Unterstützung für das IPSec-Protokoll. Aus Sicht des mehrschichtigen Sicherheitsmodells ist dieses Protokoll ein Sicherheitstool auf Netzwerkebene.

Reis. 5.9.

Die IPSec-Architektur ist offen, was insbesondere den Einsatz neuer kryptografischer Algorithmen und Protokolle, beispielsweise nach nationalen Standards, zum Schutz übertragener Daten ermöglicht. Hierzu ist es erforderlich, dass die kommunizierenden Parteien diese Algorithmen unterstützen und diese in der Beschreibung der Verbindungsparameter einheitlich registriert werden.

Der Prozess der sicheren Datenübertragung unterliegt den im System festgelegten Sicherheitsregeln. Die Parameter des erstellten Tunnels werden durch eine Informationsstruktur beschrieben, die als Sicherheitskontext oder Sicherheitsassoziation (von der englischen Security Association, Abk. SA) bezeichnet wird. Wie oben erwähnt, handelt es sich bei IPSec um eine Reihe von Protokollen, und die Zusammensetzung der SA kann je nach Protokoll variieren. SA umfasst:

• Empfänger-IP-Adresse;
• eine Angabe der bei der Datenübertragung verwendeten Sicherheitsprotokolle;
• die für die Verschlüsselung und Generierung des Nachahmungseinsatzes erforderlichen Schlüssel (falls erforderlich);
• eine Angabe der Formatierungsmethode, die bestimmt, wie Überschriften erstellt werden;
• Sicherheitsparameterindex (vom englischen Security Parameter Index, abgekürzt SPI) – eine Kennung, mit der Sie die gewünschte SA finden können.

Normalerweise ist der Sicherheitskontext unidirektional und es werden zwei SAs verwendet, um Daten in beide Richtungen durch den Tunnel zu übertragen. Jeder Host verfügt über eine eigene SA-Datenbank, aus der das erforderliche Element entweder basierend auf SPI oder der IP-Adresse des Empfängers ausgewählt wird.

Die beiden in IPSec enthaltenen Protokolle sind:

1. Authentifizierungs-Header-Protokoll- AH (vom englischen Authentication Header), das eine Integritätsüberprüfung und Authentifizierung der übertragenen Daten ermöglicht; letzte Version Das Protokoll ist in RFC 4302 (früher: RFC 1826, 2402) beschrieben.
2. Encapsulated Data Protection Protocol – ESP (aus dem Englischen). Kapselung der Sicherheitsnutzlast) – sorgt für Vertraulichkeit und kann optional eine Integritätsprüfung und Authentifizierung bereitstellen, beschrieben in RFC 4303 (früher – RFC 1827, 2406).

Beide Protokolle haben zwei Betriebsmodi – Transport und Tunnel, wobei letzterer als der Hauptmodus definiert ist. Tunnelmodus Wird verwendet, wenn mindestens einer der Verbindungsknoten ein Sicherheitsgateway ist. In diesem Fall wird ein neuer IP-Header erstellt und das ursprüngliche IP-Paket vollständig im neuen gekapselt.

Transportmodus Der Schwerpunkt liegt auf der Host-zu-Host-Verbindung. Bei Verwendung von ESP im Transportmodus sind nur die Daten des IP-Pakets geschützt, der Header ist nicht betroffen. Bei Verwendung von AH erstreckt sich der Schutz auf die Daten und einen Teil der Header-Felder. Nachfolgend werden die Betriebsarten näher beschrieben.

AH-Protokoll

In IP Version 4 wird der Authentifizierungsheader nach dem IP-Header platziert. Stellen wir uns das ursprüngliche IP-Paket als eine Kombination aus einem IP-Header, einem Protokoll-Header der nächsten Ebene (normalerweise TCP oder UDP, in Abb. 5.10 wird es als ULP bezeichnet – von Upper-Level Protocol) und Daten vor.

Betrachten Sie das ESP-Header-Format (Abb. 5.13). Es beginnt mit zwei 32-Bit-Werten – SPI Und SN. Ihre Rolle ist dieselbe wie im AH-Protokoll – SPI identifiziert die SA, die zum Erstellen dieses Tunnels verwendet wurde; SN- ermöglicht Ihnen den Schutz vor Paketwiederholungen. SN Und SPI sind nicht verschlüsselt.

Das nächste Feld enthält die verschlüsselten Daten. Danach folgt ein Platzhalterfeld, das benötigt wird, um die Länge der verschlüsselten Felder auf einen Wert auszurichten, der ein Vielfaches der Blockgröße des Verschlüsselungsalgorithmus ist.

Nach dem Platzhalter folgen Felder mit der Länge des Platzhalters und einer Angabe des übergeordneten Protokolls. Die vier aufgeführten Felder (Daten, Platzhalter, Länge, nächstes Protokoll) sind durch Verschlüsselung geschützt.

Wenn ESP auch zur Datenauthentifizierung verwendet wird, endet das Paket mit einem Feld variabler Länge, das den ICV enthält. Im Gegensatz zu AH werden in ESP bei der Berechnung des Imitovsert-Werts die Felder des IP-Headers (neu – für den Tunnelmodus, modifiziert alt – für den Transport) nicht berücksichtigt.

Bei Teilen Protokolle AH und ESP, nach dem IP-Header kommt AH, danach - ESP. In diesem Fall löst ESP die Probleme der Gewährleistung der Vertraulichkeit, AH – der Gewährleistung der Integrität und Authentifizierung der Verbindungsquelle.

Betrachten wir eine Reihe zusätzlicher Probleme im Zusammenhang mit der Verwendung von IPSec. Beginnen wir damit, woher die Informationen über die Verbindungsparameter – SA – kommen. Die Erstellung einer SA-Basis kann auf verschiedene Arten erfolgen. Insbesondere kann es erstellt werden Sicherheitsadministrator manuell oder mit speziellen Protokollen generiert - SKIP, ISAKMP ( Internet sicherheit Association and Key Management Protocol) und IKE (Internet Key Exchange).

IPSec und NAT

Bei der Verbindung von Organisationsnetzwerken mit dem Internet wird häufig ein Netzwerkadressübersetzungsmechanismus verwendet – NAT (Network Address Translation). Dadurch können Sie die Anzahl der registrierten IP-Adressen reduzieren, die in einem bestimmten Netzwerk verwendet werden. Innerhalb des Netzwerks werden nicht registrierte Adressen verwendet (normalerweise aus speziell für diesen Zweck zugewiesenen Bereichen, beispielsweise Adressen wie 192.168.x.x für Netzwerke der Klasse C). Wird ein Paket aus einem solchen Netzwerk ins Internet übertragen, dann verändert ein Router, dessen externe Schnittstelle mindestens eine registrierte IP-Adresse zugewiesen hat, die IP-Header Netzwerkpakete, wobei private Adressen durch die registrierte Adresse ersetzt werden. Die Art und Weise, wie die Substitution durchgeführt wird, wird in einer speziellen Tabelle erfasst. Beim Empfang einer Antwort wird entsprechend der Tabelle eine umgekehrte Ersetzung vorgenommen und das Paket an das interne Netzwerk weitergeleitet.

Schauen wir uns ein Beispiel für die Verwendung von NAT in Abb. an. 5.14. In diesem Fall werden im internen Netzwerk die privaten Adressen 192.168.0.x verwendet. Von einem Computer mit der Adresse 192.168.0.2 aus kontaktieren externes Netzwerk an einen Computer mit der Adresse 195.242.2.2. Dies sei eine Verbindung zu einem Webserver (HTTP-Protokoll, das den TCP-Port 80 verwendet).

Wenn ein Paket einen Router passiert, der eine Adressübersetzung durchführt, wird die IP-Adresse des Absenders (192.168.0.2) durch die Adresse ersetzt externe Schnittstelle Router (195.201.82.146) und einen Eintrag ähnlich dem in

ein kurzer historischer Hintergrund zum Erscheinen des Protokolls

1994 veröffentlichte das Internet Architecture Board (IAB) den Bericht „Sicherheit der Internetarchitektur“. In diesem Dokument wurden die Hauptanwendungsbereiche zusätzlicher Sicherheitstools im Internet beschrieben, nämlich Schutz vor unbefugter Überwachung, Paketspoofing und Datenflusskontrolle. Zu den ersten und wichtigsten Schutzmaßnahmen gehörte die Entwicklung eines Konzepts und grundlegender Mechanismen zur Gewährleistung der Integrität und Vertraulichkeit des Datenflusses. Seit der Veränderung grundlegende Protokolle Die TCP/IP-Familie hätte zu einer völligen Umstrukturierung des Internets geführt; die Aufgabe bestand darin, die Sicherheit des Informationsaustauschs in offenen Telekommunikationsnetzen auf Basis bestehender Protokolle zu gewährleisten. Daher wurde mit der Erstellung der Secure IP-Spezifikation begonnen, die die Protokolle IPv4 und IPv6 ergänzt.

IPSec-Architektur

IP-Sicherheit ist eine Reihe von Protokollen, die sich mit Fragen der Verschlüsselung, Authentifizierung und Sicherheit beim Transport von IP-Paketen befassen. es umfasst mittlerweile fast 20 Standardvorschläge und 18 RFCs.
Die IP-Sicherheitsspezifikation (heute bekannt als IPsec) wird von der IETF IP Security Protocol Working Group entwickelt. IPsec umfasste ursprünglich drei algorithmusunabhängige Kernspezifikationen, die als RFCs veröffentlicht wurden: IP Security Architecture, Authentication Header (AH), Encapsulation of Encrypted Data (ESP) (RFC1825, 1826 und 1827). Es sei darauf hingewiesen, dass die IP Security Protocol Working Group im November 1998 neue Versionen dieser Spezifikationen vorgeschlagen hat, die derzeit den Status vorläufiger Standards haben: RFC2401 – RFC2412. Beachten Sie, dass RFC1825-27 seit mehreren Jahren als veraltet gilt und nicht wirklich verwendet wird. Darüber hinaus gibt es mehrere algorithmenabhängige Spezifikationen unter Verwendung der Protokolle MD5, SHA und DES.

Abb.1. IPSec-Architektur

Die IP Security Protocol Working Group entwickelt außerdem wichtige Protokolle für das Informationsmanagement. Die Aufgabe dieser Gruppe besteht darin, das Internet Key Management Protocol (IKMP) zu entwickeln, ein Schlüsselverwaltungsprotokoll auf Anwendungsebene, das unabhängig von den verwendeten Sicherheitsprotokollen ist. Schlüsselverwaltungskonzepte werden derzeit anhand der ISAKMP-Spezifikation (Internet Security Association and Key Management Protocol) und des Oakley Key Determination Protocol untersucht. Die ISAKMP-Spezifikation beschreibt Mechanismen zum Aushandeln der Attribute der verwendeten Protokolle, während das Oakley-Protokoll die Installation von Sitzungsschlüsseln auf Computern im Internet ermöglicht. Früher wurden auch die Möglichkeiten der Nutzung wichtiger Verwaltungsmechanismen des SKIP-Protokolls in Betracht gezogen, mittlerweile werden solche Möglichkeiten praktisch nirgendwo genutzt. Neue Standards für die Verwaltung wichtiger Informationen unterstützen möglicherweise Schlüsselverteilungszentren ähnlich denen, die in Kerberos verwendet werden. Schlüsselverwaltungsprotokolle für IPSec auf Basis von Kerberos werden derzeit von einem relativ neuen Unternehmen entwickelt Arbeitsgruppe KINK (Kerberized Internet Negotiation of Keys).
Datenintegritäts- und Vertraulichkeitsgarantien in der IPsec-Spezifikation werden durch die Verwendung von Authentifizierungs- bzw. Verschlüsselungsmechanismen bereitgestellt. Letztere wiederum basieren auf der Vorabvereinbarung der Parteien des sogenannten Informationsaustausches. „Sicherheitskontext“ – angewandte kryptografische Algorithmen, wichtige Algorithmen für das Informationsmanagement und ihre Parameter. Die IPsec-Spezifikation bietet den Parteien die Möglichkeit, Informationen auszutauschen, um verschiedene Protokolle und Parameter zur Authentifizierung und Verschlüsselung von Datenpaketen sowie verschiedene Schlüsselverteilungsschemata zu unterstützen. In diesem Fall ist das Ergebnis der Einigung über den Sicherheitskontext die Erstellung eines Sicherheitsparameterindex (SPI), der ein Hinweis auf ein bestimmtes Element der internen Struktur der Informationsaustauschpartei ist und mögliche Sätze von Sicherheitsparametern beschreibt.
Im Wesentlichen operiert IPSec, das ein integraler Bestandteil von IPv6 werden wird, auf der dritten Schicht, also auf der Netzwerkebene. Dadurch werden übertragene IP-Pakete auf eine für Netzwerkanwendungen und Infrastruktur transparente Weise geschützt. Im Gegensatz zu SSL (Secure Socket Layer), das auf Schicht 4 (d. h. Transport) arbeitet und enger mit höheren Schichten des OSI-Modells verknüpft ist, ist IPSec darauf ausgelegt, Sicherheit auf niedrigem Niveau zu bieten.

Abb.2. OSI/ISO-Modell

Damit IP-Daten zur virtuellen Übertragung bereitstehen privates Netzwerk,IPSec fügt einen Header hinzu, um geschützte Pakete zu identifizieren. Bevor diese Pakete über das Internet übertragen werden, werden sie in andere IP-Pakete eingekapselt. IPSec unterstützt mehrere Verschlüsselungstypen, darunter Data Encryption Standard (DES) und Message Digest 5 (MD5).
Um eine sichere Verbindung herzustellen, müssen sich beide Sitzungsteilnehmer schnell auf Sicherheitsparameter wie Authentifizierungsalgorithmen und Schlüssel einigen können. IPSec unterstützt zwei Arten von Schlüsselverwaltungsschemata, über die Teilnehmer Sitzungsparameter aushandeln können. Diese doppelte Unterstützung verursachte zeitweise einige Spannungen in der IETF-Arbeitsgruppe.
Mit der aktuellen IP-Version IPv4 kann entweder Internet Secure Association Key Management Protocol (ISAKMP) oder Simple Key Management for Internet Protocol verwendet werden. MIT neue Version IP, IPv6, muss ISAKMP verwenden, jetzt bekannt als IKE, obwohl die Möglichkeit der Verwendung von SKIP nicht ausgeschlossen ist. Allerdings gilt es zu bedenken, dass SKIP schon lange nicht mehr als Schlüsselkandidat für das Management in Betracht gezogen wurde und bereits 1997 von der Liste möglicher Kandidaten gestrichen wurde.

AH- und ESP-Header

Authentifizierungsheader AH

Der Authentication Header (AH) ist ein allgemeiner optionaler Header und befindet sich normalerweise zwischen dem Hauptheader des IP-Pakets und dem Datenfeld. Das Vorhandensein von AH hat keinerlei Einfluss auf den Prozess der Informationsübertragung vom Transport und höheren Ebenen. Der Haupt- und einzige Zweck von AH besteht darin, Schutz vor Angriffen im Zusammenhang mit zu bieten unautorisierte Änderung Paketinhalte, einschließlich der Ersetzung der Quell-Netzwerkschichtadresse. Protokolle höherer Ebenen müssen geändert werden, um die Authentizität der empfangenen Daten zu überprüfen.
Das AH-Format ist recht einfach und besteht aus einem 96-Bit-Header und Daten variabler Länge, die aus 32-Bit-Wörtern bestehen. Die Feldnamen spiegeln ihren Inhalt recht deutlich wider: „Next Header“ gibt den nächsten Header an, „Payload Len“ stellt die Paketlänge dar, „SPI“ ist ein Zeiger auf den Sicherheitskontext und „Sequence Number Field“ enthält die Sequenznummer des Pakets.

Abb. 3. AH-Header-Format

Die Paketsequenznummer wurde 1997 im Rahmen des Überarbeitungsprozesses der IPsec-Spezifikation in AH eingeführt. Der Wert dieses Feldes wird vom Absender generiert und dient dem Schutz vor Angriffen im Zusammenhang mit der Wiederverwendung von Authentifizierungsprozessdaten. Da das Internet die Reihenfolge, in der Pakete zugestellt werden, nicht garantiert, muss der Empfänger Informationen über die maximale Sequenznummer eines erfolgreich authentifizierten Pakets speichern und darüber, ob mehrere Pakete mit vorherigen Sequenznummern empfangen wurden (normalerweise 64).
Im Gegensatz zu Prüfsummenberechnungsalgorithmen, die in Protokollen zur Übertragung von Informationen über geschaltete Kommunikationsleitungen oder über lokale Netzwerkkanäle verwendet werden und darauf abzielen, zufällige Fehler im Übertragungsmedium zu korrigieren, müssen Mechanismen zur Gewährleistung der Datenintegrität in offenen Telekommunikationsnetzen über einen Schutz vor gezielten Änderungen verfügen. Ein solcher Mechanismus ist eine spezielle Verwendung des MD5-Algorithmus: Während der Bildung des AH wird eine Hash-Funktion nacheinander aus der Vereinigung des Pakets selbst und einem vorab vereinbarten Schlüssel und dann aus der Vereinigung des resultierenden Ergebnisses und des berechnet transformierter Schlüssel. Dieser Mechanismus ist die Standardeinstellung, um sicherzustellen, dass alle IPv6-Implementierungen über mindestens einen gemeinsamen Algorithmus verfügen, der keinen Exportbeschränkungen unterliegt.

Kapselung verschlüsselter ESP-Daten

Wenn eine verschlüsselte Datenkapselung verwendet wird, ist der ESP-Header der letzte der optionalen Header, die im Paket „sichtbar“ sind. Da der Hauptzweck von ESP darin besteht, den Datenschutz zu gewährleisten, verschiedene Typen Informationen erfordern möglicherweise die Verwendung erheblich unterschiedlicher Verschlüsselungsalgorithmen. Folglich kann das ESP-Format abhängig von den verwendeten kryptografischen Algorithmen erhebliche Änderungen erfahren. Allerdings lassen sich folgende Pflichtfelder unterscheiden: SPI, das den Sicherheitskontext angibt, und Sequence Number Field, das die Sequenznummer des Pakets enthält. Das Feld „ESP Authentication Data“ (Prüfsumme) ist im ESP-Header optional. Der Empfänger des ESP-Pakets entschlüsselt den ESP-Header und verwendet die Parameter und Daten des angewendeten Verschlüsselungsalgorithmus, um die Transportschichtinformationen zu dekodieren.

Abb.4. ESP-Header-Format

Es gibt zwei Nutzungsarten von ESP und AH (sowie deren Kombinationen) – Transport und Tunnel:
Der Transportmodus wird verwendet, um das Datenfeld eines IP-Pakets zu verschlüsseln, das Transportschichtprotokolle (TCP, UDP, ICMP) enthält, die wiederum Anwendungsdienstinformationen enthalten. Ein Beispiel für eine Transportmodusanwendung ist die Übertragung Email. Nur alle Zwischenknoten auf dem Weg eines Pakets vom Sender zum Empfänger offene Informationen Netzwerkschicht und möglicherweise einige optionale Paketheader (in IPv6). Der Nachteil des Transportmodus ist das Fehlen von Mechanismen zum Verbergen des spezifischen Absenders und Empfängers eines Pakets sowie der Möglichkeit, den Datenverkehr zu analysieren. Das Ergebnis einer solchen Analyse können Informationen über Umfang und Richtung der Informationsübertragung, Interessengebiete der Abonnenten und den Standort von Managern sein.
Der Tunnelmodus verschlüsselt das gesamte Paket, einschließlich des Netzwerkschicht-Headers. Der Tunnelmodus wird verwendet, wenn es notwendig ist, den Informationsaustausch der Organisation mit der Außenwelt zu verbergen. In diesem Fall werden die Adressfelder des Netzwerkschicht-Headers eines Pakets im Tunnelmodus ausgefüllt Firewall Organisationen und enthalten keine Informationen über den konkreten Absender des Pakets. Bei der Übermittlung von Informationen von der Außenwelt an lokales Netzwerk Als Zieladresse wird die Organisation verwendet Netzwerkadresse Firewall. Nachdem die Firewall den anfänglichen Netzwerkschicht-Header entschlüsselt hat, wird das Paket an den Empfänger weitergeleitet.

Sicherheitsverbände

Eine Security Association (SA) ist eine Verbindung, die Sicherheitsdienste für den durch sie fließenden Datenverkehr bereitstellt. Zwei Computer auf jeder Seite der SA speichern den in der SA verwendeten Modus, das Protokoll, die Algorithmen und die Schlüssel. Jede SA wird nur in eine Richtung verwendet. Für die bidirektionale Kommunikation sind zwei SAs erforderlich. Jede SA implementiert einen Modus und ein Protokoll. Wenn also zwei Protokolle für ein Paket verwendet werden müssen (z. B. AH und ESP), sind zwei SAs erforderlich.

Sicherheitspolitik

Die Sicherheitsrichtlinie wird in der SPD (Security Policy Database) gespeichert. SPD kann eine von drei Aktionen für ein Datenpaket festlegen: das Paket verwerfen, das Paket nicht mit IPSec verarbeiten oder das Paket mit IPSec verarbeiten. Im letzteren Fall gibt das SPD auch an, welche SA verwendet werden soll (sofern natürlich bereits eine passende SA erstellt wurde) oder mit welchen Parametern eine neue SA erstellt werden soll.
SPD ist ein sehr flexibler Kontrollmechanismus, der sehr viel ermöglicht Gutes Management Verarbeitung jedes Pakets. Pakete werden nach einer großen Anzahl von Feldern klassifiziert, und das SPD kann einige oder alle Felder untersuchen, um die geeignete Aktion zu bestimmen. Dies könnte dazu führen, dass der gesamte Datenverkehr zwischen zwei Maschinen über eine einzige SA übertragen wird oder dass für jede Anwendung oder sogar für jede TCP-Verbindung separate SAs verwendet werden.

ISAKMP/Oakley-Protokoll

Das ISAKMP-Protokoll definiert allgemeine Struktur Protokolle, die zum Einrichten von SAs und zum Ausführen anderer wichtiger Verwaltungsfunktionen verwendet werden. ISAKMP unterstützt mehrere Domains of Interpretation (DOI), darunter IPSec-DOI. ISAKMP definiert kein vollständiges Protokoll, sondern stellt „Bausteine“ für verschiedene DOIs und Schlüsselaustauschprotokolle bereit.
Das Oakley-Protokoll ist ein Schlüsselerkennungsprotokoll, das den Diffie-Hellman-Schlüsselersetzungsalgorithmus verwendet. Das Oakley-Protokoll unterstützt Perfect Forward Secrecy (PFS). Das Vorhandensein von PFS bedeutet, dass es unmöglich ist, den gesamten Datenverkehr zu entschlüsseln, wenn ein Schlüssel im System kompromittiert wird.

IKE-Protokoll

IKE ist das Standard-Schlüsselaustauschprotokoll für ISAKMP und derzeit das einzige. IKE sitzt auf ISAKMP und übernimmt die eigentliche Einrichtung sowohl der ISAKMP SA als auch der IPSec SA. IKE unterstützt eine Reihe verschiedener primitiver Funktionen zur Verwendung in Protokollen. Dazu gehören die Hash-Funktion und die Pseudozufallsfunktion (PRF).
Eine Hash-Funktion ist eine kollisionsresistente Funktion. Kollisionsresistenz bedeutet, dass es unmöglich ist, zwei verschiedene Nachrichten m1 und m2 zu finden, sodass H(m1)=H(m2) ist, wobei H eine Hash-Funktion ist.
Was Pseudozufallsfunktionen betrifft, wird im HMAC-Design derzeit eine Hash-Funktion anstelle spezieller PRFs verwendet (HMAC ist ein Nachrichtenauthentifizierungsmechanismus, der Hash-Funktionen verwendet). Um HMAC zu bestimmen, benötigen wir eine kryptografische Hash-Funktion (bezeichnen wir sie als H) und Der geheime Schlüssel K. Wir gehen davon aus, dass H eine Hash-Funktion ist, bei der Daten mithilfe eines Komprimierungsverfahrens gehasht werden, das sequentiell auf eine Folge von Datenblöcken angewendet wird. Wir bezeichnen mit B die Länge solcher Blöcke in Bytes und die Länge der durch Hashing erhaltenen Blöcke mit L (L

ipad = Byte 0x36, B-mal wiederholt;
opad = Byte 0x5C B-mal wiederholt.

Um HMAC aus „Text“-Daten zu berechnen, müssen Sie den folgenden Vorgang ausführen:

H(K XOR opad, H(K XOR ipad, text))

Aus der Beschreibung geht hervor, dass IKE HASH-Werte zur Authentifizierung von Parteien verwendet. Beachten Sie, dass sich HASH in diesem Fall ausschließlich auf den Payload-Namen in ISAKMP bezieht und dieser Name nichts mit seinem Inhalt zu tun hat.

Angriffe auf AH, ESP und IKE

Alle Arten von Angriffen auf IPSec-Komponenten lassen sich in folgende Gruppen einteilen: Angriffe, die die endlichen Ressourcen des Systems ausnutzen (ein typisches Beispiel ist ein Denial-of-Service-Angriff, Denial-of-Service oder DOS-Angriff), Angriffe, die die Funktionen ausnutzen und Fehler einer bestimmten IPSec-Implementierung und schließlich Angriffe, die auf den Schwächen der AH- und ESP-Protokolle selbst basieren. Rein kryptografische Angriffe können ignoriert werden – beide Protokolle definieren das Konzept der „Transformation“, bei dem die gesamte Kryptografie verborgen ist. Wenn der verwendete Kryptoalgorithmus stabil ist und die damit definierte Transformation keine zusätzlichen Schwächen mit sich bringt (dies ist nicht immer der Fall, daher ist es richtiger, die Stärke des gesamten Systems zu berücksichtigen – Protokoll-Transformations-Algorithmus), dann Von dieser Seite aus ist alles in Ordnung. Was bleibt? Replay-Angriff – geebnet durch Verwendung der Sequenznummer (in einem einzigen Fall funktioniert dies nicht – bei Verwendung von ESP ohne Authentifizierung und ohne AH). Darüber hinaus garantiert die Reihenfolge der Aktionen (zuerst Verschlüsselung, dann Authentifizierung) eine schnelle Ablehnung „schlechter“ Pakete (darüber hinaus ist diese Reihenfolge laut neueren Untersuchungen in der Welt der Kryptographie die sicherste; in einigen Fällen ist die Reihenfolge jedoch umgekehrt). Sehr spezielle Fälle können zu potenziellen Sicherheitslücken führen; glücklicherweise gelten weder SSL noch IKE noch andere gängige „Zuerst authentifizieren, später verschlüsseln“-Protokolle für diese Sonderfälle und weisen daher diese Lücken nicht auf. Was bleibt, ist der Denial-Of-Service-Angriff.

Wie Sie wissen, handelt es sich um einen Angriff, gegen den es keine vollständige Verteidigung gibt. Die schnelle Ablehnung fehlerhafter Pakete und das Fehlen jeglicher Reaktion von außen darauf (laut RFC) ermöglichen jedoch eine mehr oder weniger gute Bewältigung dieses Angriffs. Im Prinzip werden die meisten (wenn nicht alle) bekannten Netzwerkangriffe (Sniffing, Spoofing, Hijacking usw.) von AH und ESP bei richtiger Anwendung erfolgreich abgewehrt. Bei IKE ist es etwas komplizierter. Das Protokoll ist sehr komplex und schwer zu analysieren. Darüber hinaus enthält es aufgrund von Tippfehlern (in der Formel zur Berechnung von HASH_R) beim Schreiben und nicht ganz erfolgreichen Lösungen (dasselbe HASH_R und HASH_I) mehrere potenzielle „Lücken“ (insbesondere in der ersten Phase nicht alle Payloads in die Nachricht wird authentifiziert), sie sind jedoch nicht sehr schwerwiegend und führen höchstens zu einer Verweigerung des Verbindungsaufbaus. IKE schützt sich mehr oder weniger erfolgreich vor Angriffen wie Replay, Spoofing, Sniffing, Hijacking. Bei der Kryptographie ist es etwas komplizierter – sie wird nicht wie bei AH und ESP separat durchgeführt, sondern im Protokoll selbst implementiert. Wenn Sie jedoch persistente Algorithmen und Primitive (PRF) verwenden, sollte es keine Probleme geben. In gewisser Weise kann es als Schwäche von IPsec angesehen werden, dass DES in den aktuellen Spezifikationen als einziger obligatorischer kryptografischer Algorithmus angegeben ist (dies gilt sowohl für ESP als auch für IKE), dessen Schlüssel 56 Bit nicht mehr als ausreichend erachtet . Dies ist jedoch eine rein formale Schwäche – die Spezifikationen selbst sind algorithmenunabhängig und fast alle namhaften Anbieter haben 3DES schon lange implementiert (und einige haben bereits AES implementiert). Bei korrekter Implementierung bleibt also der „gefährlichste“ Angriff bestehen Denial-of-Service.

Auswertung des IPSec-Protokolls

Das IPSec-Protokoll hat von Experten gemischte Kritiken erhalten. Einerseits wird darauf hingewiesen, dass das IPSec-Protokoll das beste unter allen anderen bisher entwickelten Protokollen zum Schutz der über das Netzwerk übertragenen Daten ist (einschließlich PPTP, das von Microsoft entwickelt wurde). Nach Ansicht der anderen Seite liegt eine übermäßige Komplexität und Redundanz des Protokolls vor. So stellen Niels Ferguson und Bruce Schneier in ihrer Arbeit „A Cryptographic Evaluation of IPsec“ fest, dass sie in fast allen wichtigen Komponenten von IPsec schwerwiegende Sicherheitsprobleme festgestellt haben. Diese Autoren weisen außerdem darauf hin, dass die Protokollsuite erheblich verbessert werden muss, damit sie ein gutes Maß an Sicherheit bietet.

(The Internet Key Exchange (IKE)) – Schlüsselaustausch.

IPsec-Architektur

IPsec-Protokolle arbeiten im Gegensatz zu den anderen bekannten Protokollen SSL und TLS auf der Netzwerkschicht (Schicht 3 des OSI-Modells). Dadurch wird IPsec flexibler, sodass es zum Schutz aller TCP- und UDP-basierten Protokolle eingesetzt werden kann. IPsec kann verwendet werden, um Sicherheit zwischen zwei IP-Hosts, zwischen zwei Sicherheits-Gateways oder zwischen einem IP-Host und einem Sicherheits-Gateway bereitzustellen. Das Protokoll ist ein „Überbau“ über dem IP-Protokoll und verarbeitet generierte IP-Pakete auf die unten beschriebene Weise. IPsec kann die Integrität und/oder Vertraulichkeit der über ein Netzwerk übertragenen Daten gewährleisten.

IPsec verwendet die folgenden Protokolle, um verschiedene Funktionen auszuführen:

• Der Authentication Header (AH) gewährleistet die Integrität der virtuellen Verbindung (übertragene Daten), die Authentifizierung der Informationsquelle und eine zusätzliche Funktion zur Verhinderung der erneuten Übertragung von Paketen
• Encapsulated Security Payload (ESP) kann die Vertraulichkeit (Verschlüsselung) der übertragenen Informationen gewährleisten und so den Fluss vertraulichen Datenverkehrs begrenzen. Darüber hinaus kann es die Integrität der virtuellen Verbindung (übertragene Daten), die Authentifizierung der Informationsquelle und die zusätzliche Funktion zur Verhinderung der erneuten Übertragung von Paketen gewährleisten (bei Verwendung von ESP muss der eine oder andere Satz von Sicherheitsdienstdaten verwendet werden).
• Security Associations (SAs) stellen eine Reihe von Algorithmen und Daten bereit, die die für den AH- und/oder ESP-Betrieb erforderlichen Parameter bereitstellen. Das Internet Security Association and Key Management Protocol (ISAKMP) bildet die Grundlage für die Authentifizierung und den Schlüsselaustausch und überprüft die Authentizität von Schlüsseln.

Sicherheitsverband

Das Konzept der „Secure Virtual Connection“ (SA, „Security Association“) ist grundlegend für die IPsec-Architektur. Eine SA ist eine Simplex-Verbindung, die so aufgebaut ist, dass der entsprechende Datenverkehr darüber übertragen wird. Bei der Implementierung von Sicherheitsdiensten wird eine SA basierend auf der Verwendung der Protokolle AH oder ESP (oder beider gleichzeitig) gebildet. SA ist nach dem Konzept der Inter-Terminal-Verbindung (Punkt-zu-Punkt) definiert und kann in zwei Modi betrieben werden: Transportmodus (RTR) und Tunnelmodus (RTU). Der Transportmodus wird mit SA zwischen zwei IP-Knoten implementiert. Im Tunnelmodus bildet die SA einen IP-Tunnel.

Alle SAs werden in der SADB (Security Associations Database) des IPsec-Moduls gespeichert. Jede SA verfügt über einen einzigartigen Token, der aus drei Elementen besteht:

• Sicherheitsparameterindex (SPI)
• Ziel-IP-Adressen
• Sicherheitsprotokoll-ID (ESP oder AH)

Das IPsec-Modul kann mit diesen drei Parametern einen Eintrag in der SADB für eine bestimmte SA finden. Die Liste der SA-Komponenten umfasst:

Da es sich bei sicheren virtuellen Verbindungen (SA) um Simplexverbindungen handelt, sind mindestens zwei SAs erforderlich, um einen Duplexkanal zu organisieren. Darüber hinaus muss jedes Protokoll (ESP/AH) für jede Richtung eine eigene SA haben, d. h. die AH+ESP-Kombination erfordert vier SAs. Alle diese Daten befinden sich in SADB.

• AH: Authentifizierungsalgorithmus.
• AH: Geheimer Schlüssel zur Authentifizierung
• ESP: Verschlüsselungsalgorithmus.
• ESP: Geheimer Verschlüsselungsschlüssel.
• ESP: Authentifizierung verwenden (ja/nein).
• Optionen zum Schlüsselaustausch
• Routing-Einschränkungen
• IP-Filterrichtlinie

Zusätzlich zur SADB-Datenbank unterstützen IPsec-Implementierungen eine SPD-Datenbank (Security Policy Database). Ein SPD-Eintrag besteht aus einer Reihe von IP-Header-Feldwerten und Protokoll-Header-Feldern der oberen Schicht. Diese Felder werden Selektoren genannt. Mit Selektoren werden ausgehende Pakete gefiltert, um jedes Paket einer bestimmten SA zuzuordnen. Beim Generieren eines Pakets werden die Werte der entsprechenden Felder im Paket (Auswahlfelder) mit denen im SPD verglichen. Die entsprechenden SAs werden gefunden. Anschließend werden die SA (sofern vorhanden) für das Paket und der zugehörige Sicherheitsparameterindex (SPI) ermittelt. Anschließend werden IPsec-Operationen (AH- oder ESP-Protokolloperationen) ausgeführt.

Beispiele für Selektoren, die im SPD enthalten sind:

• Ziel-IP-Adresse
• IP-Adresse des Absenders
• IPsec-Protokoll (AH, ESP oder AH+ESP)
• Sender- und Empfängerports

Authentifizierungsheader

Das AH-Protokoll wird zur Authentifizierung verwendet, d. h. um zu bestätigen, dass wir mit der Person kommunizieren, für die wir uns zu halten glauben, und dass die Daten, die wir empfangen, während der Übertragung nicht beschädigt werden.

Verarbeiten ausgegebener IP-Pakete

Wenn das sendende IPsec-Modul feststellt, dass das Paket einer SA zugeordnet ist, die eine AH-Verarbeitung beinhaltet, beginnt es mit der Verarbeitung. Je nach Modus (Transport- oder Tunnelmodus) fügt es den AH-Header unterschiedlich in das IP-Paket ein. Im Transportmodus wird der AH-Header nach dem IP-Protokoll-Header und vor den Protokoll-Headern der oberen Schicht (normalerweise TCP oder UDP) platziert. Im Tunnelmodus wird das gesamte ursprüngliche IP-Paket zunächst vom AH-Header und dann vom IP-Protokoll-Header umgeben. Dieser Header wird als extern bezeichnet, und der Header des ursprünglichen IP-Pakets wird als intern bezeichnet. Danach muss das sendende IPsec-Modul eine Seriennummer generieren und in das Feld schreiben Sequenznummer. Wenn eine SA eingerichtet wird, wird die Sequenznummer auf 0 gesetzt und vor dem Senden jedes IPsec-Pakets um eins erhöht. Zusätzlich wird geprüft, ob der Zähler in eine Schleife geraten ist. Hat er seinen Maximalwert erreicht, wird er auf 0 zurückgesetzt. Bei Nutzung des Replay-Prevention-Dienstes setzt das sendende IPsec-Modul die SA zurück, wenn der Zähler seinen Maximalwert erreicht. Dies gewährleistet den Schutz vor erneutem Senden von Paketen – das empfangende IPsec-Modul überprüft das Feld Sequenznummer, und ignorieren Sie wieder ankommende Pakete. Als nächstes wird die ICV-Prüfsumme berechnet. Es ist zu beachten, dass hier die Prüfsumme mithilfe eines geheimen Schlüssels berechnet wird, ohne den ein Angreifer zwar den Hash neu berechnen kann, aber ohne Kenntnis des Schlüssels nicht in der Lage ist, die korrekte Prüfsumme zu generieren. Die spezifischen Algorithmen zur Berechnung des ICV finden Sie in RFC 4305. Derzeit können beispielsweise die Algorithmen HMAC-SHA1-96 oder AES-XCBC-MAC-96 verwendet werden. Das AH-Protokoll berechnet eine Prüfsumme (ICV) basierend auf den folgenden Feldern des IPsec-Pakets:

• IP-Header-Felder, die während der Übersetzung nicht geändert wurden oder als die wichtigsten identifiziert wurden
• AH-Header (Felder: „Next Header“, „Payload Len“, „Reserved“, „SPI“, „Sequence Number“, „Integrity Check Value“. Das Feld „Integrity Check Value“ wird bei der Berechnung des ICV auf 0 gesetzt
• Protokolldaten der oberen Schicht

Verarbeitung eingegebener IP-Pakete

Nach dem Empfang eines Pakets mit einer AH-Protokollnachricht sucht das IPsec-Empfangsmodul anhand der IP-Adresse des Empfängers, des Sicherheitsprotokolls (SA) und des SPI-Index in der entsprechenden SADB (Security Associations Database). Wenn keine passende SA gefunden wird, wird das Paket verworfen. Die gefundene Secure Virtual Connection (SA) gibt an, ob der Packet Replay Prevention Service genutzt wird, d.h. über die Notwendigkeit, das Feld zu überprüfen Sequenznummer. Wenn der Dienst genutzt wird, wird das Feld überprüft. Hierzu wird die Sliding-Window-Methode verwendet. Das empfangende IPsec-Modul generiert ein Fenster mit der Breite W. Der linke Rand des Fensters entspricht der minimalen Sequenznummer( Sequenznummer) N korrekt empfangenes Paket. Paket mit Feld Sequenznummer, das einen Wert im Bereich von N+1 bis N+W enthält, wird korrekt akzeptiert. Befindet sich das empfangene Paket am linken Rand des Fensters, wird es zerstört. Das IPsec-Empfangsmodul berechnet dann den ICV aus den entsprechenden Feldern des empfangenen Pakets mithilfe des Authentifizierungsalgorithmus, den es aus dem SA-Datensatz erlernt hat, und vergleicht das Ergebnis mit dem ICV-Wert im Feld „Integrity Check Value“. Wenn der berechnete ICV-Wert mit dem empfangenen übereinstimmt, gilt das eingehende Paket als gültig und wird zur weiteren IP-Verarbeitung akzeptiert. Ergibt die Prüfung ein negatives Ergebnis, wird das empfangende Paket vernichtet.

Verarbeitung von IPsec-Ausgabepaketen

Wenn das sendende IPsec-Modul feststellt, dass das Paket einer SA zugeordnet ist, die eine ESP-Verarbeitung erfordert, beginnt es mit der Verarbeitung. Je nach Modus (Transport- oder Tunnelmodus) wird das ursprüngliche IP-Paket unterschiedlich verarbeitet. Im Transportmodus führt das übertragende IPsec-Modul den Vorgang des Framings (Einkapselns) des übergeordneten Protokolls (z. B. TCP oder UDP) unter Verwendung des ESP-Headers und des ESP-Trailers durch, ohne den Header des Quell-IP-Pakets zu beeinflussen. Im Tunnelmodus ist das IP-Paket von einem ESP-Header und einem ESP-Trailer umgeben und dann von einem äußeren IP-Header umgeben. Als nächstes wird die Verschlüsselung durchgeführt – im Transportmodus wird nur die Protokollnachricht über der darunter liegenden Schicht verschlüsselt (also alles, was nach dem IP-Header im Quellpaket war), im Tunnelmodus das gesamte Quell-IP-Paket. Das sendende IPsec-Modul ermittelt den Verschlüsselungsalgorithmus und den geheimen Schlüssel aus dem SA-Datensatz. IPsec-Standards ermöglichen die Verwendung von Triple-DES-, AES- und Blowfish-Verschlüsselungsalgorithmen. Da die Größe des Klartextes ein Vielfaches einer bestimmten Anzahl von Bytes sein muss, beispielsweise der Blockgröße für Blockalgorithmen, wird vor der Verschlüsselung auch das notwendige Padding der verschlüsselten Nachricht durchgeführt. Die verschlüsselte Nachricht wird im Feld platziert Nutzlastdaten. Auf dem Feld Pad-Länge passt zur Länge des Zusatzes. Dann wird es wie in AH berechnet Sequenznummer. Anschließend wird die Prüfsumme (ICV) berechnet. Die Prüfsumme wird im Gegensatz zum AH-Protokoll, bei dessen Berechnung auch einige Felder des IP-Headers berücksichtigt werden, beim ESP nur aus den Feldern des ESP-Pakets abzüglich des ICV-Felds berechnet. Es wird mit Nullen gefüllt, bevor die Prüfsumme berechnet wird. Der ICV-Berechnungsalgorithmus wird wie im AH-Protokoll vom sendenden IPsec-Modul aus dem Datensatz der SA gelernt, mit der das verarbeitete Paket verknüpft ist.

Verarbeitung eingehender IPsec-Pakete

Nach dem Empfang eines Pakets mit einer ESP-Protokollnachricht sucht das IPsec-Empfangsmodul anhand der IP-Adresse, des Sicherheitsprotokolls (ESP) und des SPI-Index des Empfängers nach der entsprechenden sicheren virtuellen Verbindung (SA) in der SADB (Security Associations Database). Wenn keine passende SA gefunden wird, wird das Paket verworfen. Die gefundene Secure Virtual Connection (SA) gibt an, ob der Packet Replay Prevention Service genutzt wird, d.h. die Notwendigkeit, das Feld „Sequenznummer“ zu überprüfen. Wenn der Dienst genutzt wird, wird das Feld überprüft. Hierzu wird wie bei AH die Sliding-Window-Methode verwendet. Das empfangende IPsec-Modul generiert ein Fenster mit der Breite W. Der linke Rand des Fensters entspricht der minimalen Sequenznummer N eines korrekt empfangenen Pakets. Ein Paket mit einem Sequenznummernfeld, das einen Wert im Bereich von N+1 bis N+W enthält, wird korrekt empfangen. Befindet sich das empfangene Paket am linken Rand des Fensters, wird es zerstört. Wenn dann der Authentifizierungsdienst verwendet wird, berechnet das IPsec-Empfangsmodul mithilfe des Authentifizierungsalgorithmus, den es aus dem SA-Datensatz erlernt hat, den ICV aus den entsprechenden Feldern des empfangenen Pakets und vergleicht das Ergebnis mit dem ICV-Wert im Feld „Integrity Check Value“. Wenn der berechnete ICV-Wert mit dem empfangenen übereinstimmt, gilt das eingehende Paket als gültig. Ergibt die Prüfung ein negatives Ergebnis, wird das empfangende Paket vernichtet. Als nächstes wird das Paket entschlüsselt. Das IPsec-Empfangsmodul erfährt aus dem SA-Record, welcher Verschlüsselungsalgorithmus verwendet wird und welchen geheimen Schlüssel es gibt. Es ist zu beachten, dass der Prüfsummenüberprüfungs- und Entschlüsselungsvorgang nicht nur sequentiell, sondern auch parallel durchgeführt werden kann. Im letzteren Fall muss das Prüfsummenüberprüfungsverfahren vor dem Entschlüsselungsverfahren abgeschlossen werden, und wenn die ICV-Prüfung fehlschlägt, muss auch das Entschlüsselungsverfahren beendet werden. Dadurch können Sie beschädigte Pakete schnell identifizieren, was wiederum den Schutz vor Denial-of-Service-Angriffen (DOS-Angriffen) erhöht. Als nächstes folgt die entschlüsselte Nachricht entsprechend dem Feld Nächster Header zur weiteren Bearbeitung übergeben.

Verwendung

Das IPsec-Protokoll wird hauptsächlich zur Organisation von VPN-Tunneln verwendet. In diesem Fall arbeiten die Protokolle ESP und AH im Tunnelmodus. Darüber hinaus kann das Protokoll durch die Konfiguration von Sicherheitsrichtlinien auf bestimmte Weise zum Erstellen einer Firewall verwendet werden. Der Sinn einer Firewall besteht darin, dass sie die durch sie hindurchgehenden Pakete gemäß festgelegten Regeln kontrolliert und filtert. Es wird eine Reihe von Regeln installiert und der Bildschirm prüft alle Pakete, die ihn passieren. Fallen übermittelte Pakete in den Geltungsbereich dieser Regeln, werden sie von der Firewall entsprechend verarbeitet. Es kann beispielsweise bestimmte Pakete ablehnen und so unsichere Verbindungen stoppen. Durch entsprechende Einstellung der Sicherheitsrichtlinie können Sie beispielsweise den Internetverkehr blockieren. Dazu reicht es aus, das Senden von Paketen mit HTTP- und HTTPS-Protokollnachrichten zu verbieten. IPsec kann auch zum Schutz von Servern eingesetzt werden – dabei werden alle Pakete verworfen, außer denen, die für die korrekte Ausführung von Serverfunktionen notwendig sind. Beispielsweise können Sie für einen Webserver den gesamten Datenverkehr außer Verbindungen über TCP-Port 80 oder über TCP-Port 443 blockieren, wenn HTTPS verwendet wird.

siehe auch

Links

• Beschreibung der IPSec-Konfiguration (cisco.com)

0 Dieser Artikel bietet einen Überblick über die IP-Sicherheitstools (IP Security) und die zugehörigen IPSec-Protokolle, die in Cisco-Produkten zum Erstellen virtueller privater Netzwerke (VPNs) verfügbar sind. In diesem Artikel definieren wir, was IPSEC ist und welche Protokolle und Sicherheitsalgorithmen IPSEC zugrunde liegen.

Einführung

Cisco VPN-Produkte nutzen die IPSec-Protokollsuite, den Industriestandard für die Bereitstellung umfassender VPN-Funktionen. IPSec bietet einen Mechanismus zur sicheren Datenübertragung über IP-Netzwerke und gewährleistet die Vertraulichkeit, Integrität und Zuverlässigkeit von Daten, die über ungesicherte Netzwerke wie das Internet übertragen werden. IPSec bietet die folgenden VPN-Funktionen in Cisco-Netzwerken:

• Datenprivatsphäre. Der IPSec-Datensender hat die Möglichkeit, Pakete zu verschlüsseln, bevor sie über das Netzwerk gesendet werden.
• Datenintegrität. Ein IPSec-Empfänger hat die Möglichkeit, die mit ihm kommunizierenden Parteien (die Geräte oder Software, bei denen IPSec-Tunnel beginnen und enden) und die von diesen Parteien gesendeten IPSec-Pakete zu authentifizieren, um sicherzustellen, dass die Daten während der Übertragung nicht verändert wurden.
• Authentifizierung der Datenquelle. Der IPSec-Empfänger hat die Möglichkeit, die Quelle der empfangenen IPSec-Pakete zu authentifizieren. Dieser Dienst ist vom Datenintegritätsdienst abhängig.
• Wiedergabeschutz. Der IPSec-Empfänger kann wiedergegebene Pakete erkennen und ablehnen und so verhindern, dass Pakete gefälscht oder Man-in-the-Middle-Angriffen ausgesetzt werden.

IPSec ist ein auf Standards basierender Satz von Sicherheitsprotokollen und -algorithmen. Die IPSec-Technologie und die zugehörigen Sicherheitsprotokolle entsprechen offenen Standards, die von der Internet Engineering Task Force (IETF) gepflegt und in RFC-Spezifikationen und IETF-Entwürfen beschrieben werden. IPSec arbeitet auf der Netzwerkebene und bietet Sicherheit und Authentifizierung für IP-Pakete, die zwischen IPSec-Geräten (Parteien) gesendet werden – wie z. B. Cisco-Routern, PIX-Firewalls, Cisco VPN-Clients und -Konzentratoren und vielen anderen Produkten, die IPSec unterstützen. Die IPSec-Unterstützung reicht von sehr kleinen bis hin zu sehr großen Netzwerken.

Sicherheitsvereinigung (SA)

Verteidigungsverband(Security Association – SA) ist eine vereinbarte Richtlinie oder Methode zur Verarbeitung von Daten, die zwischen zwei Geräten kommunizierender Parteien ausgetauscht werden sollen. Ein Bestandteil einer solchen Richtlinie kann der Algorithmus sein, der zur Verschlüsselung der Daten verwendet wird. Beide Parteien können denselben Algorithmus sowohl für die Verschlüsselung als auch für die Entschlüsselung verwenden. Die effektiven SA-Parameter werden in der Security Association Database (SAD) beider Parteien gespeichert.

Zwei Computer auf jeder Seite der SA speichern den in der SA verwendeten Modus, das Protokoll, die Algorithmen und die Schlüssel. Jede SA wird nur in eine Richtung verwendet. Für die bidirektionale Kommunikation sind zwei SAs erforderlich. Jede SA implementiert einen Modus und ein Protokoll. Wenn also zwei Protokolle für ein Paket verwendet werden müssen (z. B. AH und ESP), sind zwei SAs erforderlich.

Das IKE-Protokoll (Internet Key Exchange) ist ein Hybridprotokoll, das einen spezifischen Dienst für IPSec bereitstellt, nämlich die Authentifizierung von IPSec-Parteien, die Aushandlung von IKE- und IPSec-Sicherheitszuordnungsparametern und die Auswahl von Schlüsseln für in IPSec verwendete Verschlüsselungsalgorithmen. Das IKE-Protokoll basiert auf den Protokollen Internet Security Association and Key Management Protocol (ISAKMP) und Oakley, die zur Verwaltung der Erstellung und Verarbeitung von Verschlüsselungsschlüsseln verwendet werden, die in IPSec-Transformationen verwendet werden. Das IKE-Protokoll wird auch verwendet, um Sicherheitsbeziehungen zwischen potenziellen IPSec-Parteien herzustellen.
Sowohl IKE als auch IPSec verwenden Sicherheitszuordnungen, um Kommunikationsparameter festzulegen.
IKE unterstützt eine Reihe verschiedener primitiver Funktionen zur Verwendung in Protokollen. Dazu gehören die Hash-Funktion und die Pseudozufallsfunktion (PRF).

Hash-Funktion ist eine kollisionssichere Funktion. Kollisionsresistenz bezieht sich auf die Tatsache, dass es unmöglich ist, zwei unterschiedliche Nachrichten m1 und m2 so zu finden

H(m1)=H(m2), wobei H die Hash-Funktion ist.

Was Pseudozufallsfunktionen betrifft, wird im HMAC-Design derzeit eine Hash-Funktion anstelle spezieller PRFs verwendet (HMAC ist ein Nachrichtenauthentifizierungsmechanismus, der Hash-Funktionen verwendet). Um HMAC zu definieren, benötigen wir eine kryptografische Hash-Funktion (nennen wir sie H) und einen geheimen Schlüssel K. Wir gehen davon aus, dass H eine Hash-Funktion ist, bei der Daten mithilfe eines Komprimierungsverfahrens gehasht werden, das sequentiell auf eine Folge von Datenblöcken angewendet wird. Wir bezeichnen mit B die Länge solcher Blöcke in Bytes und die Länge der durch Hashing erhaltenen Blöcke mit L (L
ipad = Byte 0x36, B-mal wiederholt;
opad = Byte 0x5C B-mal wiederholt.

Um HMAC aus „Text“-Daten zu berechnen, müssen Sie den folgenden Vorgang ausführen:

H(K XOR opad, H(K XOR ipad, text))

Aus der Beschreibung geht hervor, dass IKE HASH-Werte zur Authentifizierung von Parteien verwendet. Beachten Sie, dass sich HASH in diesem Fall ausschließlich auf den Payload-Namen in ISAKMP bezieht und dieser Name nichts mit seinem Inhalt zu tun hat

IPSec-Infrastruktur

So funktioniert IPSec

• Schritt 1: Starten Sie den IPSec-Prozess. Datenverkehr, der gemäß der von den IPSec-Parteien vereinbarten IPSec-Sicherheitsrichtlinie eine Verschlüsselung erfordert, beginnt mit dem IKE-Prozess.
• Schritt 2: IKE Phase Eins. Der IKE-Prozess authentifiziert IPSec-Parteien und handelt IKE-Sicherheitszuordnungsparameter aus, was zu einem sicheren Kanal für die Aushandlung von IPSec-Sicherheitszuordnungsparametern während der zweiten Phase von IKE führt.
• Schritt 3: IKE Phase Zwei. Der IKE-Prozess handelt IPSec-Sicherheitszuordnungsparameter aus und richtet geeignete IPSec-Sicherheitszuordnungen für Geräte der kommunizierenden Partei ein.
• Schritt 4: Datenübertragung. Die Kommunikation zwischen kommunizierenden IPSec-Parteien erfolgt auf der Grundlage von IPSec-Parametern und Schlüsseln, die in der Sicherheitszuordnungsdatenbank gespeichert sind.
• Schritt 5: Beenden Sie den IPSec-Tunnel. IPSec-Sicherheitszuordnungen werden entweder beendet, weil sie gelöscht werden oder weil ihr Lebensdauerlimit überschritten wurde.

IPsec ist kein einzelnes Protokoll, sondern ein System von Protokollen zum Schutz von Daten auf der Netzwerkebene von IP-Netzwerken. In diesem Artikel wird die Theorie der Verwendung von IPsec zum Erstellen eines VPN-Tunnels beschrieben.

Einführung

VPN basierend auf IPsec-Technologie kann in zwei Teile unterteilt werden:

• Internet Key Exchange (IKE)-Protokoll
• IPsec-Protokolle (AH/ESP/beide)

Der erste Teil (IKE) ist die Verhandlungsphase, in der die beiden VPN-Punkte auswählen, welche Methoden zum Schutz des zwischen ihnen gesendeten IP-Verkehrs verwendet werden. Darüber hinaus wird IKE auch zur Verwaltung von Verbindungen verwendet, indem für jede Verbindung das Konzept der Security Associations (SA) eingeführt wird. SAs zeigen nur in eine Richtung, daher verwendet eine typische IPsec-Verbindung zwei SAs.

Der zweite Teil sind diejenigen IP-Daten, die vor der Übertragung mit den im ersten Teil vereinbarten Methoden (IKE) verschlüsselt und authentifiziert werden müssen. Es können verschiedene IPsec-Protokolle verwendet werden: AH, ESP oder beide.

Der Ablauf zum Aufbau eines VPN über IPsec lässt sich kurz wie folgt beschreiben:

• IKE handelt die Sicherheit der IKE-Ebene aus
• IKE handelt die Sicherheit der IPsec-Ebene aus
• Geschützte Daten werden per VPN IPsec übertragen

IKE, Internet-Schlüsselaustausch

Um Daten zu verschlüsseln und zu authentifizieren, müssen Sie die Verschlüsselungs-/Authentifizierungsmethode (Algorithmus) und die darin verwendeten Schlüssel auswählen. Die Aufgabe des Internet Key Exchange-Protokolls (IKE) besteht in diesem Fall darin, „Sitzungsschlüssel“-Daten zu verteilen und sich auf Algorithmen zu einigen, die die Daten zwischen VPN-Punkten schützen.

Die Hauptaufgaben von IKE:

• Authentifizierung von VPN-Punkten untereinander
• Aufbau neuer IPsec-Verbindungen (durch Bildung von SA-Paaren)
• Aktuelle Verbindungen verwalten

IKE verfolgt die Verbindungen, indem es jeder von ihnen eine bestimmte Sicherheitszuordnung (SA) zuweist. Die SA beschreibt die Parameter einer bestimmten Verbindung, einschließlich des IPsec-Protokolls (AH/ESP oder beides), Sitzungsschlüssel, die für die Verschlüsselung/Entschlüsselung und/oder Authentifizierung von Daten verwendet werden. SA ist unidirektional, sodass pro Verbindung mehrere SAs verwendet werden. Wenn nur ESP oder AH verwendet wird, werden in den meisten Fällen nur zwei SAs für jede der Verbindungen erstellt, eine für eingehenden Datenverkehr und eine für ausgehenden Datenverkehr. Wenn ESP und AH zusammen verwendet werden, sind für SA vier erforderlich.

Der IKE-Aushandlungsprozess durchläuft mehrere Phasen (Phasen). Zu diesen Phasen gehören:

1. IKE Phase-1:
   — Der Schutz von IKE selbst (ISAKMP-Tunnel) wird ausgehandelt
2. IKE-Phase zwei (IKE-Phase-2):
   — IPsec-Schutz wird ausgehandelt
   – Empfangen von Daten aus der ersten Phase, um Sitzungsschlüssel zu generieren

IKE- und IPsec-Verbindungen sind in ihrer Dauer (in Sekunden) und in der übertragenen Datenmenge (in Kilobyte) begrenzt. Dies geschieht zur Erhöhung der Sicherheit.
Die Dauer einer IPsec-Verbindung ist im Allgemeinen kürzer als bei IKE. Wenn eine IPsec-Verbindung abläuft, wird daher in der zweiten Aushandlungsphase eine neue IPsec-Verbindung neu erstellt. Die erste Aushandlungsphase wird nur bei der Neuerstellung der IKE-Verbindung verwendet.

Um IKE auszuhandeln, wird das Konzept des IKE-Vorschlags eingeführt – ein Vorschlag zum Schutz von Daten. Der VPN-Punkt, der die IPsec-Verbindung initiiert, sendet eine Liste (Satz), die verschiedene Methoden zum Sichern der Verbindung angibt.
Es können sowohl Verhandlungen über den Aufbau einer neuen IPsec-Verbindung als auch über den Aufbau einer neuen IKE-Verbindung geführt werden. Im Fall von IPsec sind die geschützten Daten der durch den VPN-Tunnel gesendete Datenverkehr, und im Fall von IKE sind die geschützten Daten die Daten aus den IKE-Verhandlungen selbst.
Der VPN-Punkt, der die Liste (Vorschlag) erhält, wählt daraus den am besten geeigneten aus und gibt ihn in der Antwort an. Kann keines der Angebote ausgewählt werden, lehnt das VPN-Gateway ab.
Der Vorschlag enthält alle notwendigen Informationen zur Auswahl eines Verschlüsselungsalgorithmus und zur Authentifizierung usw.

Phase 1 IKE – IKE-Sicherheitsverhandlung (ISAKMP-Tunnel)
In der ersten Aushandlungsphase authentifizieren sich VPN-Punkte gegenseitig anhand eines gemeinsamen Schlüssels (Pre-Shared Key). Zur Authentifizierung werden Hash-Algorithmen verwendet: MD5, SHA-1, SHA-2.
Bevor sie sich jedoch gegenseitig authentifizieren, tauschen VPN-Punkte, um Informationen nicht im Klartext zu übertragen, die zuvor beschriebenen Vorschlagslisten (Proposals) aus. Erst nachdem ein für beide VPN-Punkte passendes Angebot ausgewählt wurde, authentifizieren sich die VPN-Punkte gegenseitig.
Die Authentifizierung kann auf unterschiedliche Weise erfolgen: über Pre-Shared Keys, Zertifikate oder . Gemeinsame Schlüssel sind die gebräuchlichste Authentifizierungsmethode.
Die IKE-Aushandlung der Phase 1 kann in einem von zwei Modi erfolgen: Hauptmodus und Aggressiv. Der Hauptmodus dauert länger, ist aber auch sicherer. Dabei werden sechs Nachrichten ausgetauscht. Der aggressive Modus ist schneller und beschränkt sich auf drei Nachrichten.
Die Hauptarbeit der ersten Phase von IKE liegt im Austausch von Diffie-Hellman-Schlüsseln. Es basiert auf der Verschlüsselung mit öffentlichen Schlüsseln. Jede Partei verschlüsselt den Authentifizierungsparameter (Pre-Shared Key) mit dem öffentlichen Schlüssel ihres Nachbarn, der diese Nachricht nach Erhalt mit seinem privaten Schlüssel entschlüsselt. Eine weitere Möglichkeit, sich gegenseitig zu authentifizieren, ist die Verwendung von Zertifikaten.

Phase 2 IKE – IPsec-Sicherheitsverhandlung
In der zweiten Phase wird die IPsec-Verbindungsschutzmethode ausgewählt.
In der zweiten Phase wird Schlüsselmaterial verwendet, das aus dem Diffie-Hellman-Schlüsselaustausch der ersten Phase extrahiert wurde. Auf Basis dieses Materials werden Sitzungsschlüssel erstellt, die zum Schutz der Daten im VPN-Tunnel dienen.

Wenn der Mechanismus verwendet wird Perfektes Weiterleitungsgeheimnis (PFS), dann wird für jede Phase-2-Verhandlung ein neuer Diffie-Hellman-Schlüsselaustausch verwendet. Durch eine geringfügige Reduzierung der Betriebsgeschwindigkeit stellt dieses Verfahren sicher, dass die Sitzungsschlüssel unabhängig voneinander sind, was die Sicherheit erhöht, da selbst wenn einer der Schlüssel kompromittiert wird, er nicht zur Auswahl des Rests verwendet werden kann.

Für die zweite Phase der IKE-Aushandlung gibt es nur einen Betriebsmodus, den sogenannten Schnellmodus. Während des Verhandlungsprozesses der zweiten Phase werden drei Nachrichten ausgetauscht.

Am Ende der zweiten Phase wird eine VPN-Verbindung aufgebaut.

IKE-Optionen.
Beim Verbindungsaufbau werden mehrere Parameter verwendet, ohne deren Aushandlung ein Aufbau einer VPN-Verbindung nicht möglich ist.

• Identifizierung des Endknotens
  Wie Knoten sich gegenseitig authentifizieren. Der am häufigsten verwendete Schlüssel ist der Shared Key. Bei der Shared-Key-Authentifizierung wird der Diffie-Hellman-Algorithmus verwendet.
• Lokales und Remote-Netzwerk/Host
  Definiert den Datenverkehr, der durch den VPN-Tunnel zugelassen wird.
• Tunnel- oder Transportmodus.
  IPsec kann in zwei Modi betrieben werden: Tunnel und Transport. Die Wahl des Modus hängt von den zu schützenden Objekten ab.
  Tunnelmodus Wird zum Schutz zwischen entfernten Objekten verwendet, d. h. Das IP-Paket wird vollständig in ein neues Paket eingekapselt und nur die Verbindung zwischen den beiden VPN-Punkten ist für einen externen Beobachter sichtbar. Die tatsächlichen Quell- und Ziel-IP-Adressen werden erst sichtbar, nachdem das Paket entkapselt und am VPN-Empfangspunkt empfangen wurde. Daher wird der Tunnelmodus am häufigsten für VPN-Verbindungen verwendet.
  Transportmodus schützt die Daten des IP-Pakets (TCP, UDP und Protokolle der oberen Schicht) und der Header des ursprünglichen IP-Pakets selbst bleibt erhalten. Auf diese Weise sieht der Beobachter die ursprüngliche Quelle und das ursprüngliche Ziel, nicht jedoch die übertragenen Daten. Dieser Modus wird am häufigsten zum Schutz einer lokalen Netzwerkverbindung zwischen Hosts verwendet.
• Remote-Gateway
  Das VPN ist der Empfänger der sicheren Verbindung, der die Daten der Gegenseite entschlüsselt/authentifiziert und an das endgültige Ziel sendet.
• IKE-Betriebsmodus
  Die IKE-Aushandlung kann in zwei Modi erfolgen: Basic Und aggressiv.
  Der Unterschied besteht darin, dass im aggressiven Modus weniger Pakete verwendet werden, was einen schnelleren Verbindungsaufbau ermöglicht. Andererseits werden im aggressiven Modus einige Verhandlungsparameter wie Diffie-Hellman-Gruppen und PFS nicht übertragen, was eine vorläufige identische Konfiguration dieser Parameter an den teilnehmenden Verbindungspunkten erfordert.
• IPsec-Protokolle
  Es gibt zwei IPsec-Protokolle: Authentication Header (AH) und Encapsulated Security Payload (ESP), die Verschlüsselungs- und Authentifizierungsfunktionen ausführen.
  ESP ermöglicht die Verschlüsselung und Authentifizierung separat oder gleichzeitig.
  AH erlaubt nur die Authentifizierung. Der Unterschied zur ESP-Authentifizierung besteht darin, dass AH auch den äußeren IP-Header authentifiziert, sodass Sie bestätigen können, dass das Paket tatsächlich von der darin angegebenen Quelle angekommen ist.
• IKE-Verschlüsselung
  Gibt den zu verwendenden IKE-Verschlüsselungsalgorithmus und seine Schlüssel an. Es werden verschiedene symmetrische Verschlüsselungsalgorithmen unterstützt, zum Beispiel: DES, 3DES, AES.
• IKE-Authentifizierung
  Der bei der IKE-Aushandlung verwendete Authentifizierungsalgorithmus. Möglicherweise: SHA, MD5.
• IKE Diffie-Hellman (DH)-Gruppen
  Die DF-Gruppe, die für den Schlüsselaustausch in IKE verwendet wird. Je größer die Gruppe, desto größer die Größe der Austauschschlüssel.
• Lebensdauer der IKE-Verbindung
  Sie wird sowohl durch die Zeit (Sekunden) als auch durch die Größe der übertragenen Daten (Kilobyte) angegeben. Sobald einer der Zähler den Schwellenwert erreicht, beginnt eine neue erste Phase. Wenn seit der Erstellung der IKE-Verbindung keine Daten übertragen wurden, werden keine neuen Verbindungen erstellt, bis eine der Parteien eine VPN-Verbindung herstellen möchte.
• PFS
  Wenn PFS deaktiviert ist, wird das Schlüsselerstellungsmaterial in der ersten Phase der IKE-Aushandlung zum Zeitpunkt des Schlüsselaustauschs abgerufen. In der zweiten Phase der IKE-Aushandlung werden Sitzungsschlüssel basierend auf dem empfangenen Material erstellt. Wenn PFS aktiviert ist, wird beim Erstellen neuer Sitzungsschlüssel jedes Mal ein neues Material für diese verwendet. Wenn also ein Schlüssel kompromittiert wird, ist es nicht möglich, darauf basierend neue Schlüssel zu erstellen.
  PFS kann in zwei Modi verwendet werden: Das erste PFS für Schlüssel startet jedes Mal, wenn eine Aushandlung gestartet wird, einen neuen Schlüsselaustausch in der ersten IKE-Phase
  zweite Phase. Der zweite PFS im Identitätsmodus entfernt die SA der ersten Phase jedes Mal, wenn eine Aushandlung der zweiten Phase abgeschlossen ist, um sicherzustellen, dass keine Aushandlung der zweiten Phase mit einem identischen Schlüssel wie die vorherige verschlüsselt wird.
• IPsec-DH-Gruppen
  Die DF-Gruppendaten ähneln denen in IKE und werden nur für PFS verwendet.
• IPsec-Verschlüsselung
  Algorithmus zur Verschlüsselung von Daten. Wird verwendet, wenn ESP im Verschlüsselungsmodus verwendet wird. Beispielalgorithmen: DES, 3DES, AES.
• IPsec-Authentifizierung
  Der zur Authentifizierung übertragener Daten verwendete Algorithmus. Wird im Fall von AH oder ESP im Authentifizierungsmodus verwendet. Beispielalgorithmen: SHA, MD5.
• IPsec-Lebensdauer
  Die Lebensdauer einer VPN-Verbindung wird sowohl durch die Zeit (Sekunden) als auch durch die Größe der übertragenen Daten (Kilobyte) angegeben. Der erste Zähler, der das Limit erreicht, löst die Neuerstellung der Sitzungsschlüssel aus. Wenn seit der Erstellung der IKE-Verbindung keine Daten übertragen wurden, werden keine neuen Verbindungen erstellt, bis eine der Parteien eine VPN-Verbindung herstellen möchte.

IKE-Authentifizierungsmethoden

• Manueller Modus
  Die einfachste Methode, bei der IKE nicht verwendet wird und Authentifizierungs- und Verschlüsselungsschlüssel sowie einige andere Parameter manuell an beiden Punkten der VPN-Verbindung festgelegt werden.
• Durch gemeinsame Schlüssel (Pre-Shared Keys, PSK)
  Ein vorab eingegebener gemeinsamer Schlüssel an beiden Punkten der VPN-Verbindung. Der Unterschied zur vorherigen Methode besteht darin, dass IKE verwendet wird, wodurch Endpunkte authentifiziert werden können und rotierende Sitzungsschlüssel anstelle fester Verschlüsselungsschlüssel verwendet werden.
• Zertifikate
  Jeder VPN-Punkt verwendet: seinen eigenen privaten Schlüssel, seinen eigenen öffentlichen Schlüssel, sein eigenes Zertifikat, einschließlich seines eigenen öffentlichen Schlüssels und signiert von einer vertrauenswürdigen Zertifizierungsstelle. Im Gegensatz zur vorherigen Methode können Sie damit die Eingabe eines gemeinsamen Schlüssels an allen Punkten der VPN-Verbindung vermeiden und ihn durch persönliche Zertifikate ersetzen, die von einer vertrauenswürdigen Stelle signiert sind.

IPsec-Protokolle

Zum Schutz übertragener Daten werden IPsec-Protokolle verwendet. Die Auswahl des Protokolls und seiner Schlüssel erfolgt während der IKE-Aushandlung.

AH (Authentifizierungsheader)

AH bietet die Möglichkeit, übertragene Daten zu authentifizieren. Dazu wird eine kryptografische Hash-Funktion in Bezug auf die im IP-Paket enthaltenen Daten verwendet. Die Ausgabe dieser Funktion (der Hash) wird zusammen mit dem Paket gesendet und ermöglicht es dem Remote-VPN-Punkt, die Integrität des ursprünglichen IP-Pakets zu bestätigen und zu bestätigen, dass es unterwegs nicht geändert wurde. Zusätzlich zu den Daten des IP-Pakets authentifiziert AH auch einen Teil seines Headers.

Im Transportmodus bettet AH seinen Header nach dem ursprünglichen IP-Paket ein.
Im Tunnelmodus bettet AH seinen Header nach dem äußeren (neuen) IP-Header und vor dem inneren (ursprünglichen) IP-Header ein.

ESP (Encapsulated Security Payload)

Das ESP-Protokoll wird zur Verschlüsselung, Authentifizierung oder beidem in Bezug auf ein IP-Paket verwendet.

Im Transportmodus fügt das ESP-Protokoll seinen Header nach dem ursprünglichen IP-Header ein.
Im Tunnelmodus befindet sich der ESP-Header nach dem äußeren (neuen) IP-Header und vor dem inneren (ursprünglichen).

Zwei Hauptunterschiede zwischen ESP und AH:

• Zusätzlich zur Authentifizierung bietet ESP auch Verschlüsselungsfunktionen (AH bietet diese nicht an).
• ESP authentifiziert im Tunnelmodus nur den ursprünglichen IP-Header (AH authentifiziert auch den externen).

Arbeiten hinter NAT (NAT Traversal)
Zur Unterstützung der Arbeit hinter NAT wurde eine separate Spezifikation implementiert. Wenn der VPN-Punkt diese Spezifikation unterstützt, unterstützt IPsec den Betrieb hinter NAT, es gelten jedoch bestimmte Voraussetzungen.
Die NAT-Unterstützung besteht aus zwei Teilen:

• Auf der IKE-Ebene tauschen Endgeräte untereinander Informationen über Unterstützung, NAT-Traversal und die Version der unterstützten Spezifikation aus
• Auf der ESP-Ebene wird das generierte Paket in UDP gekapselt.

NAT Traversal wird nur verwendet, wenn beide Endpunkte es unterstützen.
NAT-Definition: Beide VPN-Endpunkte senden Hashes ihrer IP-Adressen zusammen mit dem UDP-Quellport der IKE-Aushandlung. Anhand dieser Informationen ermittelt der Empfänger, ob sich die Quell-IP-Adresse und/oder der Quell-Port geändert hat. Wenn diese Parameter nicht geändert wurden, wird der Datenverkehr nicht über NAT geleitet und der NAT-Traversal-Mechanismus ist nicht erforderlich. Wenn die Adresse oder der Port geändert wurde, liegt NAT zwischen den Geräten vor.

Sobald die Endpunkte feststellen, dass NAT-Traversal erforderlich ist, wird die IKE-Aushandlung von UDP-Port 500 auf Port 4500 verschoben. Dies geschieht, weil einige Geräte die IKE-Sitzung auf Port 500 bei Verwendung von NAT nicht korrekt verarbeiten.
Ein weiteres Problem ergibt sich aus der Tatsache, dass das ESP-Protokoll ein Transportschichtprotokoll ist und direkt über IP liegt. Aus diesem Grund gelten die Konzepte eines TCP/UDP-Ports nicht für ihn, was es unmöglich macht, mehr als einen Client über NAT mit einem Gateway zu verbinden. Um dieses Problem zu lösen, wird ESP in ein UDP-Datagramm gepackt und an Port 4500 gesendet, denselben Port, den IKE verwendet, wenn NAT Traversal aktiviert ist.
NAT Traversal ist in die Protokolle integriert, die es unterstützen, und funktioniert ohne vorherige Konfiguration.