Benutzer:Zim/UML - IPsec: Unterschied zwischen den Versionen
Zim (Diskussion | Beiträge) |
Zim (Diskussion | Beiträge) |
||
Zeile 48: | Zeile 48: | ||
UML-Switch 2: | UML-Switch 2: | ||
- Hostnetze | - Hostnetze | ||
+ | |||
+ | Traffic beobachten: | ||
+ | Ich hab dazu wireshark auf dem Hostsystem gestartet und es auf dem tap-device horchen lassen, dass dem Switch 1 gehoert. Deswegen ist der Switch auch ge"hub"t. | ||
+ | |||
+ | Zum Traffic erzeugen nehm ich einfach "ping" oder spaeter zwischen den Hostnetzen netcat: | ||
+ | |||
+ | Host A - client: | ||
+ | |||
+ | # netcat 192.168.30.2 1234 | ||
+ | |||
+ | netcat macht eine tcp-verbindung zu 192.168.30.2 (host B) port 1234 auf | ||
+ | |||
+ | |||
+ | |||
+ | Host B - server: | ||
+ | |||
+ | # netcat -l -p 1234 | ||
+ | |||
+ | netcat oeffnet port 1234 und horcht darauf. Die Serverseite sollte man natuerlich vorher starten. Wenn die Verbindung steht, kann man in beiden netcats schreiben und es wird auf dem jeweils anderen host angezeigt. Wird die Verbindung beendet (ctrl-c), beendet sich die Gegenseite auch. | ||
Zeile 54: | Zeile 73: | ||
Auf den Routern (Alpha, Bravo) laeuft "quagga" mit ospf als routing-protocol. Kann man natuerlich auch mit statischen Routen machen, aber das waere ja langweilig. | Auf den Routern (Alpha, Bravo) laeuft "quagga" mit ospf als routing-protocol. Kann man natuerlich auch mit statischen Routen machen, aber das waere ja langweilig. | ||
− | + | "quagga" koennen wir ja mal zu einem anderen Thema machen. Zusammen mit Routing. | |
Zeile 87: | Zeile 106: | ||
add <local_ip> <remote_ip> <ah/esp> <SPI> <-A fuer AH (authentification), -E fuer ESP (encryption)> <key> | add <local_ip> <remote_ip> <ah/esp> <SPI> <-A fuer AH (authentification), -E fuer ESP (encryption)> <key> | ||
− | Die erste Zeile legt also einen key (128bit, 16*8bit) fuer AH fest, die zweite eine key (192bit) fuer ESP. Die dritte Zeile enthaelt eine policy, wie mit entsprechenden Traffic umgegangen werden soll. | + | Die erste Zeile legt also einen key (128bit, 16*8bit) fuer AH fest, die zweite eine key (192bit, 168 + 24 parity) fuer ESP. Die dritte Zeile enthaelt eine policy, wie mit entsprechenden Traffic umgegangen werden soll. |
Damit die Paket von der Gegenseite entschluesselt/verifiziert werden koennen reichen auf Router Bravo folgende Zeilen: | Damit die Paket von der Gegenseite entschluesselt/verifiziert werden koennen reichen auf Router Bravo folgende Zeilen: | ||
Zeile 151: | Zeile 170: | ||
Die configs sind gleich, bis auf die geaenderte Richtung in der jeweiligen policy. Das "flush" und "spdflush" wirft nur alte keys und policys raus. Tadaa, deine erste IPsec-Verbindung ist fertig! | Die configs sind gleich, bis auf die geaenderte Richtung in der jeweiligen policy. Das "flush" und "spdflush" wirft nur alte keys und policys raus. Tadaa, deine erste IPsec-Verbindung ist fertig! | ||
+ | |||
+ | An dieser Stelle wuerde ich gern auf den Aufbau der config eingehen, damit sich jeder schnell selbst eine Loesung zusammenbauen kann. Die config unterscheided SAD "Security Association Database" und SPD "Security Policy Database". SAD sind die Zeilen mit dem "add" und SPD mit "spdadd". | ||
+ | |||
+ | SAD: | ||
+ | |||
+ | add [-46n] src dst protocol spi [extensions] algorithm ... ; | ||
+ | |||
+ | add - fuegt ein SAD eintrag hinzu (es gibt noch get, delete und deleteall) | ||
+ | |||
+ | [-46] - ipv4 oder ipv6 - optional | ||
+ | |||
+ | src - quelle | ||
+ | |||
+ | dst - ziel | ||
+ | |||
+ | protocol - ah, ah-old, esp, esp-old, ipcomp, tcp - tcp-md5 | ||
+ | |||
+ | spi - Security Parameter Index, dient der Zuordnung, der Pakete, ist im paket zu sehen | ||
+ | |||
+ | [extensions] - -mode - tunnel, transport, any - optional - es gibt noch mehr extensions, siehe setkey-manual | ||
+ | |||
+ | algorithm - -E ealgo key, -A aalgo key - ealgo, aalgo sind verwendbar algorithmen zb: hmac_md5, hmac-sha512, 3des-cbc, twofish-cbc, | ||
+ | aes-ctr - man unterscheided digest (authentification) und cipher (encryption), die ersten beiden sind digest und die letzten drei cipher | ||
+ | |||
+ | SPD: | ||
+ | |||
+ | spdadd [-46n] src_range dst_range upperspec label policy ; | ||
+ | |||
+ | spdadd - fuegt ein SPD eintrag hinzu | ||
+ | |||
+ | src_range, dst_range - address, address/prefixlen, address[port], address/prefixlen[port] | ||
+ | |||
+ | upperspec - siehe /etc/protocols oder zb icmp6, ip4 oder any fuer alle | ||
+ | |||
+ | label - bezeichner, der zb von SELinux ausgewertet werden kann | ||
+ | |||
+ | policy - | ||
+ | -P direction [priority specification] discard | ||
+ | -P direction [priority specification] none | ||
+ | -P direction [priority specification] ipsec | ||
+ | protocol/mode/src-dst/level [...] | ||
+ | |||
+ | directory - in, out, fwd | ||
+ | |||
+ | priority - position in der SPD | ||
+ | |||
+ | discard, none, ipsec - was die Regel macht, aehnlich dem target in iptables | ||
+ | Machen wir mal mit einem Tunnel weiter, der die beiden Hostnetze an den Routern miteinander verbindet. |
Version vom 22. Januar 2009, 22:48 Uhr
Umgebung:
Als Testumgebung kommt ein Verbund von UML-Instanzen zum Einsatz.
2x Hosts (A, B) Dienen als Endgeraete die miteinander kommunizieren
2x Router (Alpha, Bravo) Verbinden die beiden Endnetze
3x UML-Switch (sw0, sw1, sw2) Ein Switch fuer die Verbindung Host <-> Router, einer zwischen Router <-> Router und ein Switch der die Router mit dem Hostsystem verbindet.
Grafik folgt (irgendwann), dann wird das sicher etwas klarer.
Host A: - 192.168.20.2/24
Host B: - 192.168.30.2/24
Router Alpha: - 192.168.20.1/24
- Hostnetz
- 192.168.0.11/24
- Netz zum Hostsystem, Gateway
- 192.168.10.1/24
- Netz zum Router Bravo
Router Bravo: - 192.168.30.1/24
- Hostnetz
- 192.168.0.12/24
- Netz zum Hostsystem, Gateway
- 192.168.10.2/24
- Netz zum Router Bravo
UML-Switch 0: - Hostsystem - Gateway ins "richtige Netz"
UML-Switch 1: - Switch zwischen den Routern - gehubt ( -hub) - wireshark auf dem tap-dev des Hostsystems, um die Pakete zu beobachten
UML-Switch 2: - Hostnetze
Traffic beobachten: Ich hab dazu wireshark auf dem Hostsystem gestartet und es auf dem tap-device horchen lassen, dass dem Switch 1 gehoert. Deswegen ist der Switch auch ge"hub"t.
Zum Traffic erzeugen nehm ich einfach "ping" oder spaeter zwischen den Hostnetzen netcat:
Host A - client:
# netcat 192.168.30.2 1234
netcat macht eine tcp-verbindung zu 192.168.30.2 (host B) port 1234 auf
Host B - server:
# netcat -l -p 1234
netcat oeffnet port 1234 und horcht darauf. Die Serverseite sollte man natuerlich vorher starten. Wenn die Verbindung steht, kann man in beiden netcats schreiben und es wird auf dem jeweils anderen host angezeigt. Wird die Verbindung beendet (ctrl-c), beendet sich die Gegenseite auch.
Routing (optional):
Auf den Routern (Alpha, Bravo) laeuft "quagga" mit ospf als routing-protocol. Kann man natuerlich auch mit statischen Routen machen, aber das waere ja langweilig.
"quagga" koennen wir ja mal zu einem anderen Thema machen. Zusammen mit Routing.
IPsec:
AH oder ESP?
AH steht fuer "Authentication Header", was nur eine Authentifizierung der Pakete bewirkt. Dagegen steht ESP "Encapsulating Security Payload", was neben der Authentifizierung auch die Pakete verschluesselt.
Transport oder Tunnel?
Transport ist fuer den Traffic zwischen zwei Host, die beide IPsec verstehen. Tunnel baut einen Tunnel, durch welchen Pakete zb von dahinter liegenden Hosts, geleitet werden.
IKE oder Pre-Key
Waerend bei Pre-Key die Schluessel haendisch eingegen werden, kuemmert sich bei IKE ein daemon um die Verwaltung der Schluessel ua auch die regelmaessige Aenderung dieser.
Praxis:
Transport zwischen den Routern:
Auf beiden Routern werden "ipsec-tools" installiert. Diese Paket stellt die Anwendung "setkey" zur verfuegung.
#!/usr/sbin/setkey -f add 192.168.10.1 192.168.10.2 ah 24500 -A hmac-md5 "1234567890123456"; add 192.168.10.1 192.168.10.2 esp 24501 -E 3des-cbc "123456789012123456789012";
spdadd 192.168.10.1 192.168.10.2 any -P out ipsec esp/transport//require ah/transport//require;
add <local_ip> <remote_ip> <ah/esp> <SPI> <-A fuer AH (authentification), -E fuer ESP (encryption)> <key> Die erste Zeile legt also einen key (128bit, 16*8bit) fuer AH fest, die zweite eine key (192bit, 168 + 24 parity) fuer ESP. Die dritte Zeile enthaelt eine policy, wie mit entsprechenden Traffic umgegangen werden soll.
Damit die Paket von der Gegenseite entschluesselt/verifiziert werden koennen reichen auf Router Bravo folgende Zeilen:
#!/usr/sbin/setkey -f add 192.168.10.1 192.168.10.2 ah 24500 -A hmac-md5 "1234567890123456"; add 192.168.10.1 192.168.10.2 esp 24501 -E 3des-cbc "123456789012123456789012";
Da wir fuer den zweiten Router keine policy angelegt haben, werden die Pakete von Alpha zwar entschluesselt, aber Antworten gehen unverschluesselt uebers Netz. Viel schliemmer ist aber, dass Bravo beliebige Pakete von Alpha annimmt. Damit die Pakete auch verschluesselt werden, fuegen wir noch eine policy hinzu:
spdadd 192.168.10.1 192.168.10.2 any -P in ipsec esp/transport//require ah/transport//require;
sieht aus wie vom Router Alpha, allerdings wuerde das vorletzte Wort in der ersten Zeile geaendert out -> in. Bravo nimmt jetzt keine unverschluesselten Pakete mehr von Alpha an, sendet aber weiterhin unverschluesselt. Also kommt noch jeweils eine policy fuer die andere Richtung pro Router hinzu:
Alpha:
#!/usr/sbin/setkey -f # config Router Alpha
flush; spdflush;
# AH add 192.168.10.1 192.168.10.2 ah 24500 -A hmac-md5 "1234567890123456"; add 192.168.10.2 192.168.10.1 ah 24500 -A hmac-md5 "1234567890123456";
# ESP add 192.168.10.1 192.168.10.2 esp 24501 -E 3des-cbc "123456789012123456789012"; add 192.168.10.2 192.168.10.1 esp 24501 -E 3des-cbc "123456789012123456789012";
spdadd 192.168.10.1 192.168.10.2 any -P out ipsec esp/transport//require ah/transport//require; spdadd 192.168.10.2 192.168.10.1 any -P in ipsec esp/transport//require ah/transport//require;
Bravo:
#!/usr/sbin/setkey -f # config Router Bravo
flush; spdflush;
# AH add 192.168.10.1 192.168.10.2 ah 24500 -A hmac-md5 "1234567890123456"; add 192.168.10.2 192.168.10.1 ah 24500 -A hmac-md5 "1234567890123456";
# ESP add 192.168.10.1 192.168.10.2 esp 24501 -E 3des-cbc "123456789012123456789012"; add 192.168.10.2 192.168.10.1 esp 24501 -E 3des-cbc "123456789012123456789012";
spdadd 192.168.10.1 192.168.10.2 any -P in ipsec esp/transport//require ah/transport//require; spdadd 192.168.10.2 192.168.10.1 any -P out ipsec esp/transport//require ah/transport//require;
Die configs sind gleich, bis auf die geaenderte Richtung in der jeweiligen policy. Das "flush" und "spdflush" wirft nur alte keys und policys raus. Tadaa, deine erste IPsec-Verbindung ist fertig!
An dieser Stelle wuerde ich gern auf den Aufbau der config eingehen, damit sich jeder schnell selbst eine Loesung zusammenbauen kann. Die config unterscheided SAD "Security Association Database" und SPD "Security Policy Database". SAD sind die Zeilen mit dem "add" und SPD mit "spdadd".
SAD:
add [-46n] src dst protocol spi [extensions] algorithm ... ;
add - fuegt ein SAD eintrag hinzu (es gibt noch get, delete und deleteall)
[-46] - ipv4 oder ipv6 - optional
src - quelle
dst - ziel
protocol - ah, ah-old, esp, esp-old, ipcomp, tcp - tcp-md5
spi - Security Parameter Index, dient der Zuordnung, der Pakete, ist im paket zu sehen
[extensions] - -mode - tunnel, transport, any - optional - es gibt noch mehr extensions, siehe setkey-manual
algorithm - -E ealgo key, -A aalgo key - ealgo, aalgo sind verwendbar algorithmen zb: hmac_md5, hmac-sha512, 3des-cbc, twofish-cbc, aes-ctr - man unterscheided digest (authentification) und cipher (encryption), die ersten beiden sind digest und die letzten drei cipher
SPD:
spdadd [-46n] src_range dst_range upperspec label policy ;
spdadd - fuegt ein SPD eintrag hinzu
src_range, dst_range - address, address/prefixlen, address[port], address/prefixlen[port]
upperspec - siehe /etc/protocols oder zb icmp6, ip4 oder any fuer alle
label - bezeichner, der zb von SELinux ausgewertet werden kann
policy -
-P direction [priority specification] discard -P direction [priority specification] none -P direction [priority specification] ipsec protocol/mode/src-dst/level [...]
directory - in, out, fwd
priority - position in der SPD
discard, none, ipsec - was die Regel macht, aehnlich dem target in iptables Machen wir mal mit einem Tunnel weiter, der die beiden Hostnetze an den Routern miteinander verbindet.