Toto je starší verze dokumentu!
Obsah
IPsec
- IPSEC je sada protokolů pro bezpečný přenos
- The term Cisco IPsec is just a marketing ploy which basically means plain IPsec using ESP in tunnel mode without any additional encapsulation, and using the Internet Key Exchange protocol (IKE) to establish the tunnel. IKE provides several authentication options, preshared keys (PSK) or X.509 certificates combined with Extended Authentication (XAUTH) user authentication are the most common.
Teorie
- základní protokoly
- Authentication Header (AH) - pouze pro zaručení důvěryhodnosti
- Encapsulating Security Payload (ESP) - šifrování + ověření důvěryhodnosti (volitelné)
- režimy
- v obou režimech lze použít AH (IP proto 51) nebo ESP (IP proto 50)
- transportní - šifruje jen data a hlavičky paketu nechává
- nejde o klasickou VPN, pouze chrání a případně zašifrovává spojení mezi 2 uzly (z jednoho na druhý)
- tunelovací - šifruje celý paket, přidává novou hlavičku
- umožňuje propojit sítě bez veřejných IP adres (zachovává původní src/dst)
- někdy je implementován jako virtuální síťové rozhraní
- Security Association (SA)
- má přiřazeno unikátní Security Parameter Index (SPI)
- jsou to dohodnuté parametry bezpečného spojení mezi 2 body:
- způsob autentizace
- šifrovací algoritmus
- používá DES/3DES/AES a další - nejlepší je AES (DES je slabý, 3DES náročný)
- hash algoritmus
- hash funkce (SHA1/MD5) se používá pro Integrity Check Value (ICV)
- ICV kromě integrity dat zajišťuje i autenticitu obsahu paketu
- využívá Hashed Message Authentication Code (HMAC) - kromě obsahu paketu se hashuje i secret
- označuje se někdy jako HMAC-SHA1, HMAC-MD5
- Dieffiel-Hellman (DH) group
- jak velké prvočíslo se používá pro generování (výměnu) klíčů
- Možnosti autentizace
- Veřejným klíčem
- RSA nebo X.509
- Sdíleným klíčem (PSK) - textový řetězec
- Extensible Authentication Protocol (EAP)
- pro IKEv2
- více typů autentizace
- uživatel/heslo (EAP-MD5, EAP-MSCHAPv2, EAP-GTC)
- certifikátem (EAP-TLS)
- eXtended Authentication (XAuth)
- pro IKEv1
- určen primárně pro autentizaci přes login
- Internet Key Exchange
- slouží k ustanovení SA
- aktuálně existují dvě verze: IKEv1, IKEv2
- naslouchá na portu UDP/500
IKEv1
- fáze 1
- vytváří prvotní ISAKMP Security Association (SA)
- dohoda na velikosti klíčů, šifrovacím alg, hash funkci, platnosti klíče
- vygenerování klíče - každá strana pošle vygenerované číslo, k němu se přidá tajné sdílené a výsledek je klíč
- u Cisca implementuje ISAKMP
- u Openswan implementuje Pluto
- existují dva režimy
- Main mode - chrání identitu komunikujicích uzlů
- Aggressive mode - zjednodušený main mode, nechrání identitu uzlů (nevyžaduje veřejnou IP)
- fáze 2
- Quick mode
- vytvaří Security Associations pro jiné služby jako IPsec na základě SA z fáze 1
- u Cisca se označuje jako IPsec
- u Openswan jako Klips
- problémy s NAT/PAT
- NAT přepisuje src/dst IP (způsobí přepočet IP header cksum) a snižuje TTL o jedna.
- PAT přepisuje kromě src/dst IP i src/dst TCP/UDP porty
- protokol AH má IP adresy a payload (porty) zahrnuté do výpočtu ICV, proto nelze v případě NAT použít (ani v tunelovacím režimu)
- protokol ESP do výpočtu ICV zahrnuje pouze ESP hlavičku a šifrovaný payload.
- používá IP protokol ESP (50), který nemusí být povolen
- ESP protokol nemá porty - forward se musí dělat na základě src/dst IP a ne portů staticky
- X-Auth
- IPsec předpokládá, že oba konce mají veřejnou IP adresu
- X-Auth slouží k autentizaci klienta pomocí uživatelského jména a hesla
- komunikaci zde navazuje klient až po zadaní auth (bez X-Auth může navázat i server)
IKEv2
- NAT-T
- umožňuje průchod přes dynamický NAT jako Masquerade
- přejde z ESP na UDP 4500
Implementace
- skládá se z kernel a user-space části
- od kernel 2.6 je k dispozici API pro KAME, pak se přidalo pro FreeS/WAN, předtím se museli aplikovat patche
- implementace na Linuxu
- FreeS/WAN - již mrtvý projekt (2003)
- Openswan - fork FreeS/WAN, nejspíš pořád aktivní (2016)
- Strongswan - fork Openswan, prý nejvíce aktivní (2016)
- Libreswan - další fork Openswan
- KAME + Racoon
- IPsec-Tools
- aktuálně se doporučuje asi ten Strongswan :)
Strongswan prakticky
- podle návodu pro CentOS
- nainstalovat balíček strongswan (nevyžaduje žádné speciální kernel moduly)
- konfiguruje se úpravou tří souborů ve adresáři /etc/strongswan
- ipsec.conf - definice tunelů a globálních nastavení
- ipsec.secrets - definice hesel k šifrovacím klíčům a případné uživatelské účty (EAP). Musí zde být uvedeny také všechny používané privátní širfrovací klíče, aby je strongswan našel.
- strongswan.conf - zatím jsem nikdy nepoužil :)
- start se pak provádí normálně přes systemctl
- na CentOS je hlavní binárka nazvaná
strongswan, na Debian se nazývá přímoipsec
- při definici tunelu se používá označení left/right pro jednotlivé strany
- IPsec by měl sám poznat, zda je left nebo right na zákldě znalosti lokálního prostředí
- lepší je ale cfg tvorit tak, že left je strana lokální a right vzdálená
- vygenerovat klíče/certifikáty
- Self signed root CA - certifikační autorita pro generování certifikátů (pokud ještě nemáme)
- VPN Host key - používá se k identifikaci serveru u klientů. Musí prý v DN (Distinguished Name) nebo SAN (subject Alternative Name) obsahovat IP adresu nebo doménové jméno stroje. V opačném případě nemusí být akceptován.
- Klientsky certifikát - slouží k identifikaci klienta. Může to být opět certifikát stroje (vystavený na IP/hostname) nebo uživatele (vystavený na jeho email).
- klíče/certifikáty se nahrávají do
/etc/[strongswan]/ipsec.d/ - podporováno je kódování DER (binární) i PEM (ASCII, base64)
- Pro připojení z Windows 7 na GNU/Linux se strongswan lze použít následující autentizace:
- pomocí X.509 certifikátu stroje
- pomocí X.509 uživatelského certifikátu
- pomocí EAP-MSCHAP v2 (loginem)
- obecně k tomu stačí mít ve Windows naimportované příslušné certifikáty (včetně CA)
- import se provádí přes Microsoft Management Console (mmc)
- CA certifikát patří do „Důvěryhodné kořenové certifikační autority“
- Uživatelský certifikát do „Osobní“
- Windows do tunelu směruje implicitně veškerý provoz. Lze vypnout přes nastavení - vlastnosti protokolu TCP - upřesnit
- Windows vždycky vyžaduje přidělení virtuální IP adresy (rightsourceip), jinak se tunel nenaváže
Poznámky, Tipy, FAQ
Průchod IPsec jádrem
-
- ukazuje příchozí IPsec pakety rozbalené + původní zabalené
- odchozí IPsec pakety pouze zabalené (šifrované)
- iptables umí pracovat s IPsec pakety zabalenými i rozbalenými (schéma)
iptables -t filter -I OUTPUT -p esp -j DROP iptables -t filter -I OUTPUT -p ah -j DROP iptables -t filter -I OUTPUT -p udp -m multiport --dports 500,4500 -j DROP
iptables -t mangle -I PREROUTING -m policy --pol ipsec --dir in -j DROP iptables -t mangle -I POSTROUTING -m policy --pol ipsec --dir out -j DROP
- IPsec je implementován přes kernel xfrm
Virtuální IP adresy
Při definici tunelu se nastavuje, které IP adresy jsou na left/right straně dostupné. V případěš tunelu host-host je na každé straně dostupná právě jedna IP adresa (uzlů). U tunelu site-site mohou být definovány celé rozsahy, které uzel zpřístupňuje.
Virtuální IP adresa slouží jako dodatečná adresa. Strongswan implementuje přidělování virtuální IP adresy pouze klientům. Klient si zažádá, server přes tunel přidělí.
Pokud je potřeba nastavit virtuální IP na server, lze to provést ručně pomocí nastavení IP adresy na nějaké síťové rozhraní (klidně loopback) a oznámení této adresy v left/rightsubnet.
Virtuální adresy se hodí pro řešení konfliktů IP adres (stejná adresace v místní a vzdálené síti), identifikace klienta podle IP (vždy stejná) nebo třeba implementaci failover serveru (při navázání náhradního tunelu se komunikuje pořád se stejnou remote IP).
Route-based VPN / VTI
Zpracování IPsec je obvykle založeno na policies. Po bežném routování se kontroluje SPD (Secure Policy Database) a pokud se je nalezeno odpovídající SA (Security Association), paket je zpracován přes IPsec. Zkrátka pokud je aktivní IPsec tunel, jeho SA left/right subnety odpovídají paketu, jde paket do tunelu.
Router-based VPN využívá virtuální síťové rozhraní VTI (Virtual Tunnel Interface). Je to ale pouze jakoby obal pro IPsec policies. Pokud paket nasměrujeme na VTI spojené s IPsec tunelem, jehož SA nebude odpovídat src/dst, paket přes tunel stejně nepůjde. Řeší se to nastavením politiky na 0.0.0.0/0 (tedy SA odpovídají všechny zdroje/cíle). Do VTI můžemee paket nasměrovat přes routovací tabulku nebo přes iptables mark. IPsec tunel je s VTI spojen také přes mark.
Router-based VPN se tedy hodí, pokud potrebujeme mít větší kontrolu nad tím, co chodí přes tunel. Například pokud máme třeba dvě IPsec brány a chceme přes routovací tabulku určovat, která se má použít.
Užitečné příkazy
- přhledové informace přes
statusall- na kterých síťových rozhraních se naslouchá
- jaké tunely jsou definovány
- jaké tunely jsou aktivní
ipsec statusall
Listening IP addresses:
10.10.10.1
fd51:7e6d:cb2b:0:250:56ff:fc9e:c233
Connections:
sample-with-ca-cert: %any...10.10.10.2 IKEv1/2
sample-with-ca-cert: local: [C=NL, O=Example Company, CN=john@example.org] uses public key authentication
sample-with-ca-cert: cert: "C=NL, O=Example Company, CN=john@example.org"
sample-with-ca-cert: remote: [C=CZ, O=BARI2, CN=one.bari2.eu] uses public key authentication
sample-with-ca-cert: child: 10.10.10.1/32 === 10.10.10.2/32 TUNNEL
Security Associations (1 up, 0 connecting):
sample-with-ca-cert[1]: ESTABLISHED 5 minutes ago, 10.10.10.1[C=NL, O=Example Company, CN=john@example.org]...10.10.10.2[C=CZ, O=BARI2, CN=one.bari2.eu]
sample-with-ca-cert[1]: IKEv2 SPIs: 6010310d76aa1385_i* c742b439ee7aec46_r, public key reauthentication in 2 hours
sample-with-ca-cert[1]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
sample-with-ca-cert{1}: INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: cea441f5_i cf127dbc_o
sample-with-ca-cert{1}: AES_CBC_128/HMAC_SHA1_96, 5292 bytes_i (63 pkts, 56s ago), 5376 bytes_o (64 pkts, 56s ago), rekeying in 37 minutes
sample-with-ca-cert{1}: 10.10.10.1/32 === 10.10.10.2/32
- přidělené virtuální IP adresy
ipsec leases
Leases in pool '172.16.123.1', usage: 1/1, 1 online
172.16.123.1 online 'C=NL, O=Example Company, CN=john@example.org'
- statistiky tunelu
- pro každou stranu tunelu zvlášť
ip -s xfrm state
src 10.10.10.1 dst 10.10.10.2
proto esp spi 0xc99abce3(3382361315) reqid 1(0x00000001) mode tunnel
replay-window 32 seq 0x00000000 flag af-unspec (0x00100000)
auth-trunc hmac(sha1) 0x438b7318e495b86e5b9ab7058a57398f5efa89f8 (160 bits) 96
enc cbc(aes) 0x535db872f57ed1b2f1d6665dd1aff4c2 (128 bits)
encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
lifetime config:
limit: soft (INF)(bytes), hard (INF)(bytes)
limit: soft (INF)(packets), hard (INF)(packets)
expire add: soft 2519(sec), hard 3600(sec)
expire use: soft 0(sec), hard 0(sec)
lifetime current:
84(bytes), 1(packets)
add 2017-02-23 17:03:31 use 2017-02-23 17:09:26
stats:
replay-window 0 replay 0 failed 0
src 10.10.10.2 dst 10.10.10.1
proto esp spi 0xc92e5293(3375256211) reqid 1(0x00000001) mode tunnel
replay-window 32 seq 0x00000000 flag af-unspec (0x00100000)
auth-trunc hmac(sha1) 0x12364e3e549e32de4041093899e89b1d1f760c9e (160 bits) 96
enc cbc(aes) 0xbcc9351746352a5bd5ab257e37fea49f (128 bits)
encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
lifetime config:
limit: soft (INF)(bytes), hard (INF)(bytes)
limit: soft (INF)(packets), hard (INF)(packets)
expire add: soft 3022(sec), hard 3600(sec)
expire use: soft 0(sec), hard 0(sec)
lifetime current:
84(bytes), 1(packets)
add 2017-02-23 17:03:31 use 2017-02-23 17:09:26
stats:
replay-window 0 replay 0 failed 0
Odkazy
- jak nastavit L2TP/IPsec (prý je ten L2TP zbytečný, pokud není potřeba přenášet jiné než IP protokoly)
