7.1. Intro mit händischer Eingabe

IPSec ist ein kompliziertes Thema. Eine Vielzahl an Informationen sind online verfügbar ist, diese HOWTO konzentriert sich auf die Grundlagen, die Inbetriebnahme und dessen Erhalt. Alle Beispiele basieren auf Racoon vom obigen Link.

IPSec bietet eine sichere Version des Internet-Protokolls. Sicherheit bedeutet in diesem Zusammenhang zwei verschiedene Dinge: Verschlüsselung und Authentifizierung. Nur Verschlüsseln bietet eine scheinbare Sicherheit, aber es kann leicht gezeigt werden, dass es nicht ausreichend ist - du kannst zwar verschlüsselt kommunizieren, eine Garantie, ob die Gegenstelle die von dir erwartete ist, gibt es nicht.

IPSec unterstützt 'Encapsulated Security Payload' (ESP) für die Verschlüsselung und 'Authentication Header' (AH) zur Authentifizierung des Remote-Partner. Du kannst beide konfigurieren, oder beschliessen es nicht zu tun.

Sowohl ESP als auch AH setzen auf Sicherheitszuordnungen (security associations). Ein Sicherheitsassoziierung (SA) mit einer Quelle, einem Ziel und einer Anweisung. Eine Authentifizierungs-Probe-SA kann wie folgt aussehen:

		add 10.0.0.11 10.0.0.216 ah 15700 -A hmac-md5 "1234567890123456";
	

Das besagt: 'Datenverkehr von 10.0.0.11 bis 10.0.0.216, benötigt einen AH welcher per HMAC-MD5 mit dem Schüssel 1234567890123456 signiert sein muss'. Dieser Befehl wird mit SPI ('Security Parameter Index) id '15700' gekennzeichnet, dazu später mehr. Interessant an SAs ist, dass sie symmetrisch sind. Beide Seiten eines Gesprächs teilen sich genau die gleiche SA, sie ist nicht auf der anderen Seite gespiegelt. Beachte es ist keine 'autoreverse'-Regel - die SA beschreibt nur eine mögliche Authentifizierung von 10.0.0.11 bis 10.0.0.216. Für Übertragungen in beide Richtungen, werden zwei SAs benötigt.

Ein Beispiel für ESP SA:

		add 10.0.0.11 10.0.0.216 esp 15701 -E 3des-cbc "123456789012123456789012";
	

Dies bedeutet: 'Datenverkehr von 10.0.0.11 bis 10.0.0.216, die Verschlüsselung erfolgt mittels 3des-cbc und muss mit dem Schlüssel 123456789012123456789012 verschlüsselt sein'. Die SPI-ID ist '15701'.

Bisher haben wir gesehen mit welchen Anweisungen SAs geschreiben werden, aber nicht wann diese Rgelen verwendet werden müssen. Tatsächlich könnten es beliebige Viele, nahezu identischen SAs sein, die sich nur in der SPI-ID unterschieden. Übrigens steht SPI für Security Parameter Index. Zur eigentlichen Verschlüsselung brauchen wir beschriebene Richtlinie. Diese Richtlinie kann Dinge wie 'verwende ipsec wenn verfügbar' oder 'verwerfe Verkehr (drop traffic) wenn ispec nicht vorhanden' beinhalten.

Eine typische einfache Sicherheitsregel (Security Policy/SP) sieht so aus:

		spdadd 10.0.0.216 10.0.0.11 any -P out ipsec
		esp/transport//require
		ah/transport//require;
	

Wurde auf dem Host die 10.0.0.216 eingetragen, muss der gesamte ausgehende Datenverkehr zu 10.0.0.11 verschlüsselt und iin einen AH-authentifizierten Header gepackt werden. Bitte beachte, dass nicht festgelegt wird, welche SA verwendet werden soll, es dient nur als Übung für ob der Kernel es kann.

Mit anderen Worten, eine Security Policy legt fest, WAS wir wollen; eine Security Association beschreibt, Wie wir es wollen.

Ausgehende Pakete werden gekennzeichnet mit dem SA SPI ('das wie'), welche der Kernel für die Verschlüsselung und Authentifizierung verwendet, so kann Gegenstelle die entsprechende Prüfung und Entschlüsselung nach Anweisung durchführen.

Nun folgt eine sehr einfache Konfiguration für die Unterhaltung von Host 10.0.0.216 zu 10.0.0.11 über die Verschlüsselung und Authentifizierung. Beachte, da der Rügweg in dieser ersten Version im Klartext erfolgt, sollte diese Konfiguration nicht eingesetzt werden.

Beim Host 10.0.0.216:

#!/sbin/setkey -f
add 10.0.0.216 10.0.0.11 ah 24500 -A hmac-md5 "1234567890123456";          
add 10.0.0.216 10.0.0.11 esp 24501 -E 3des-cbc "123456789012123456789012";

spdadd 10.0.0.216 10.0.0.11 any -P out ipsec
   esp/transport//require
   ah/transport//require;
	

Auf Host 10.0.0.11, die gleichen Security Associations, kein Security Policy:

#!/sbin/setkey -f
add 10.0.0.216 10.0.0.11 ah 24500 -A hmac-md5 "1234567890123456";
add 10.0.0.216 10.0.0.11 esp 24501 -E 3des-cbc "123456789012123456789012";
	

Mit der obigen Konfiguration (diese Dateien können ausgeführt werden, wenn 'setkey' in /sbin installiert ist), 'ping 10.0.0.11' von 10.0.0.216 erzeugt folgenden tcpdump:

22:37:52 10.0.0.216 > 10.0.0.11: AH(spi=0x00005fb4,seq=0xa): ESP(spi=0x00005fb5,seq=0xa) (DF)
22:37:52 10.0.0.11 > 10.0.0.216: icmp: echo reply
	

Wie man sieht, ist der Ping zurück von 10.0.0.11 in der Tat deutlich sichtbar. Der ausgehende Ping kann natürlich nicht durch tcpdump gelesen werden, aber man sieht den Security Parameter Index von AH und ESP, die 10.0.0.11 mitteilen, wie die Authentizität unserer Pakete zu prüfen und zu entschlüsseln sind.

Ein paar Dinge müssen jedoch erwähnt werden. An den oberen IPSec-Beispielen kann man erkennen, dass die Konfiguration sehr gefärlich sein kann. Das Problem ist, dass die obere Policy beinhaltet, wie die Pakete von 10.0.0.216 zu 10.0.0.11 kommen, und es wird erklä,rt, wie 10.0.0.11 die Pakete behandeln soll, aber es wird nicht angewiesen, dass 10.0.0.11 den unauthentifizierten oder unverschlüsselten Datenverkehr verwerfen soll!

Jeder kann jetzt gefä,lschte und unverschlüsselte Daten einschleusen und 10.0.0.11 wird es akzeptieren. Um da Abhilfe zu schaffen, mü,ssen wir eine eingehenden Security Policy auf 10.0.0.11 wie folgt anlegen:

#!/sbin/setkey -f 
spdadd 10.0.0.216 10.0.0.11 any -P IN ipsec
   esp/transport//require
   ah/transport//require;
	

Dies weist 10.0.0.11 an, dass der Verkehr von 10.0.0.216 einen gültig ESP und AH haben benötigt.

Um diese Konfiguration zu vervollständigen, müssen wir den rückkehrenden Verkehr verschlüssel und authentifizieren. Die vollständige Konfiguration auf 10.0.0.216:

#!/sbin/setkey -f
flush;
spdflush;

# AH
add 10.0.0.11 10.0.0.216 ah 15700 -A hmac-md5 "1234567890123456";
add 10.0.0.216 10.0.0.11 ah 24500 -A hmac-md5 "1234567890123456";

# ESP
add 10.0.0.11 10.0.0.216 esp 15701 -E 3des-cbc "123456789012123456789012";
add 10.0.0.216 10.0.0.11 esp 24501 -E 3des-cbc "123456789012123456789012";

spdadd 10.0.0.216 10.0.0.11 any -P out ipsec
           esp/transport//require
           ah/transport//require;

spdadd 10.0.0.11 10.0.0.216 any -P in ipsec
           esp/transport//require
           ah/transport//require;
	  
	

And on 10.0.0.11:

#!/sbin/setkey -f
flush;
spdflush;

# AH
add 10.0.0.11 10.0.0.216 ah 15700 -A hmac-md5 "1234567890123456";
add 10.0.0.216 10.0.0.11 ah 24500 -A hmac-md5 "1234567890123456";

# ESP
add 10.0.0.11 10.0.0.216 esp 15701 -E 3des-cbc "123456789012123456789012";
add 10.0.0.216 10.0.0.11 esp 24501 -E 3des-cbc "123456789012123456789012";


spdadd 10.0.0.11 10.0.0.216 any -P out ipsec
           esp/transport//require
           ah/transport//require;

spdadd 10.0.0.216 10.0.0.11 any -P in ipsec
           esp/transport//require
           ah/transport//require;

	

Du hast sicher bemerkt, in diesem Beispiel verwendeten wir identische Schlüssel für beide Richtungen. Dies ist jedoch nicht erforderlich.

Zum Prüfen der gerade erstellten Konfiguration, setkey -D zeigt die Security Associations und setkey -DP zeigt die konfigurierten Richtlinien an.