Ve středu 15.2. od 18:00 proběhne na Fakultě informatiky Masarykovy univerzity v Brně únorové setkání Czech JBoss User Group. Tentokrát bude tématem vytváření opravdových Java EE aplikací s JBoss AS. Zahraničním hostem bude Pete Muir, který posluchačům ukáže, jak se taková aplikace vytváří. Více informací na wiki stránce akce.
Cílem tohoto článku je zasvětit běžného administrátora do možností, které nabízí kernel 2.6 v oblasti tvorby VPN. Zaměříme se na protokol IPSec, který je silnější a bezpečnější alternativou k protokolu pptp (www.poptop.org) a také umožňuje použít nativního klienta Windows XP/2000 pro přístup do intranetu.
Předpokládají se běžné znalosti z oblasti linuxu a síťování. Naopak neočekávejte vysoce sofistikované popisy protokolu, rozebírání jednotlivých hashovacích a šifrovacích algoritmů apod. Článek ani není koncipován jako detailní porovnání s ostatními IPSec implementacemi. Pro budování šifrovaných tunelů máme i další možnosti. Od CIPE, OpenVPN až po nějaké ssh tunelování.
Kromě toho, že pptp je v oblasti šifrování slabší a méně bezpečné než IPSec, existuje také patentový problém, který nedovolí začlenit pptp přímo do distribucí.
Kompresní protokol MPPC (Microsoft Point-to-Point Compression) je patentován firmou Hifn Inc.. Protokol MPPE(Microsoft Point-to-Point Encryption) používá algoritmus RC4, který sice není patentovaný, ale je obchodní značkou firmy RSA Data Security Inc.
Původní návrh IP protokolu neobsahoval žádné bezpečnostní prvky. Nový návrh IPv6 obsahuje zabezpečení jako součást protokolu. Pro toto zabezpečení se vžil název IPSec (IP Security). IPSec je dostupný i pro protokol IPv4.
IPSec obsahuje 2 základní služby:
přičemž nemusíme nutně používat obě (ESP navíc dokáže zastat i funkce AH).
IPSec můžeme používat ve 2 režimech:
Dalším pojmem, se kterým se u IPSec setkáme, je SAD (Security Association Database). SA nám vznikne ustanovením spojení a jsou v ní obsaženy veškeré informace o spojení (bezpečnostní protokol, šifrovací algoritmus, countery, atd.). SA jsou identifikovány pomocí SPI (Security Parametr Index), ten je obsažen v každém z paketů.
SPD (Security Policy Database) obsahuje pravidla, podle kterých se buď na pakety IPSec aplikuje, nebo jsou pakety zahazovány, nebo propouštěny.
Protože manuální správa SAD by byla ve větších sítích velmi problematická, byl navržen protokol, který se snaží tento problém eliminovat. ISAKMP (Internet Security Association and Key Management Protocol) je popsán v RFC2408.
Zjednodušeně můžeme říci, že obě strany se snaží dohodnout na stejných parametrech spojení (tzv. proposal). Iniciátor pošle sadu navrhovaných parametrů a responder si z nich vybere tu, která vyhovuje jeho konfiguraci. Pokud se obě strany neshodnou, spojení není možné navázat.
ISAKMP komunikace probíhá na UDP portu 500, ten je třeba mít povolený ve firewallu.
Ustanovení IPSec spojení je dvoufázové. V první fázi (Phase 1) se vytvoří základní ISAKMP SA, která se dále používá pro druhou fázi (Phase 2) a ustanovení dalších SA pro ESP/AH. Tyto SA jsou zaváděny do kernelu.
Průběh komunikace (winXP - Linux[racoon] )
| 2004-05-17 18:00:10: INFO: respond new phase 1
negotiation:
192.168.0.226[500]<=>192.168.0.227[500]
2004-05-17 18:00:10: INFO: begin Identity Protection mode. 2004-05-17 18:00:10: INFO: received Vendor ID: MS NT5 ISAKMPOAKLEY 2004-05-17 18:00:10: INFO: ISAKMP-SA established 192.168.0.226[500]-192.168.0.227[500]spi:dcd3d3d25bc29952:a14e34a6864a095f 2004-05-17 18:00:10: INFO: respond new phase 2 negotiation:192.168.0.226[0]<=>192.168.0.227[0] 2004-05-17 18:00:11: INFO: IPsec-SA established: ESP/Transport 192.168.0.227->192.168.0.226 spi=174567934(0xa67b1fe) 2004-05-17 18:00:11: INFO: IPsec-SA established: ESP/Transport 192.168.0.226->192.168.0.227 spi=3143250583(0xbb5a3297) |
O výměnu klíčů v rámci ISAKMP frameworku se stará IKE (Internet Key Exchange) RFC2409. Jedním z kroků při navazování spojení je autentizace.
Autentizace může probíhat pomocí:
Problémem ve stávajících IPv4 sítích je pro IPSec NAT. Řešením tohoto problému je návrh draft-ietf-ipsec-nat-t-ike-08.txt. Otázkou kompatibility se zabývá RFC3715.
Implementace IPSecu na Linuxu
My se budeme dále zabývat druhou jmenovanou implementací, protože ta je standardně přítomna v kernelu 2.6 a enterprise distributoři provedli její downport i pro kernel řady 2.4 (např. RHEL3).
Pokud si kompilujeme vlastní jádro, musíme mít v konfiguraci následující položky:
|
CONFIG_NET_KEY=y CONFIG_INET_AH=m CONFIG_INET_ESP=m CONFIG_INET_IPCOMP=m CONFIG_XFRM_USER=m CRYPTO=y CRYPTO_HMAC=m CRYPTO_MD5=m CRYPTO_NULL=m CRYPTO_SHA1=m CRYPTO_DES=m CRYPTO_AES=m |
Pokud máme připravený kernel, vrhneme se na instalaci ipsec-tools. Pokud máme distribuci SuSE 9.1, Fedora Core 2, Mandrake 10 nebo další aktuální distribuci, jsou tam již ipsec-tools většinou přítomné. IPSec-tools jsou sponzorovány společností SuSE (Novell). Pokud je v distribuci nemáme, stáhneme si je z http://ipsec-tools.sf.net a nainstalujeme standardní trojkombinací:
| ./configure make make install |
ipsec-tools obsahují:
Konečně se dostáváme k něčemu trochu užitečnému, i když ne příliš používanému. Mějme následující topologii:
router kryton (192.168.0.226) ---- Internet ---- router lister (192.168.0.227)
a chceme mít komunikaci mezi těmito routery šifrovanou.
Použijeme manuální konfiguraci pouze s ESP a jako šifrovací algoritmus použijeme 3des.
výpis souboru ipsec-kryton.cfg pro router "kryton"
| #!/sbin/setkey -f flush; spdflush; # ESP SAs using 192 bit long keys (168 + 24 parity) add 192.168.0.226 192.168.0.227 esp 0x201 -E 3des-cbc 0x7aeaca3f87d060a12f4a4487d5a5c3355920fae69a96c831; add 192.168.0.227 192.168.0.226 esp 0x301 -E 3des-cbc 0xf6ddb555acfd9d77b03ea3843f2653255afe8eb5573965df; # Security policies spdadd 192.168.0.226 192.168.0.227 any -P out ipsec esp/transport//require; spdadd 192.168.0.227 192.168.0.226 any -P in ipsec esp/transport//require; |
Pro router "lister" prohodíme v konfiguračním souboru v sekci "security policies"(prikazy spdadd) ip adresy na řádcích (tzn. tam kde je 192.168.0.226, dáme 192.168.0.227 a naopak) a uložíme jako ipsec-lister.cfg.
Na obou routerech potom aktivujeme nastavení pomocí příkazů
| kryton#setkey -f
ipsec-kryton.cfg lister#setkey -f ipsec-lister.cfg |
SAD a SPD můžeme vypsat pomocí příkazu
| bash#setkey -D 192.168.0.227 192.168.0.226 esp mode=transport spi=769(0x00000301) reqid=0(0x00000000) E: 3des-cbc f6ddb555 acfd9d77 b03ea384 3f265325 5afe8eb5 573965df seq=0x00000000 replay=0 flags=0x00000000 state=mature created: Jun 1 01:13:14 2004 current: Jun 1 01:13:17 2004 diff: 3(s) hard: 0(s) soft: 0(s) last: hard: 0(s) soft: 0(s) current: 0(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 0 hard: 0 soft: 0 sadb_seq=1 pid=21880 refcnt=0 192.168.0.226 192.168.0.227 esp mode=transport spi=513(0x00000201) reqid=0(0x00000000) E: 3des-cbc 7aeaca3f 87d060a1 2f4a4487 d5a5c335 5920fae6 9a96c831 seq=0x00000000 replay=0 flags=0x00000000 state=mature created: Jun 1 01:13:14 2004 current: Jun 1 01:13:17 2004 diff: 3(s) hard: 0(s) soft: 0(s) last: hard: 0(s) soft: 0(s) current: 0(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 0 hard: 0 soft: 0 sadb_seq=0 pid=21880 refcnt=0 |
Tady vidíme dvě SA pro router kryton. První SA nám říká, že paket jdoucí z 192.168.0.227 na 192.168.0.226 se SPI=769 je dešifrován tímto klíčem: 0x0xf6ddb555acfd9d77b03ea3843f2653255afe8eb5573965df. Druhé SA nám říká, že paket jdoucí z 192.168.0.226 na 192.168.0.227 se SPI=513 je šifrován tímto klíčem: 0x7aeaca3f87d060a12f4a4487d5a5c3355920fae69a96c831.
| bash#setkey -DP 192.168.0.227[any] 192.168.0.226[any] any in ipsec esp/transport//require created: Jun 1 01:13:14 2004 lastused: lifetime: 0(s) validtime: 0(s) spid=1856 seq=1 pid=21881 refcnt=1 192.168.0.226[any] 192.168.0.227[any] any out ipsec esp/transport//require created: Jun 1 01:13:14 2004 lastused: lifetime: 0(s) validtime: 0(s) spid=1849 seq=0 pid=21881 refcnt=1 |
Tyto dvě SP na routeru kryton nastavují policy. První SP nám říká, že pro příchozí pakety jdoucí ze 192.168.0.227 na 192.168.0.226 má aplikovat ESP. U druhé SP je to analogické. Že je provoz šifrovaný se můžeme přesvědčit např. tcpdumpem na rozhraní, kterým pakety odchází do sítě.
Jak si můžeme domyslet, nebylo by zrovna ideální udržovat větší počet takovýchto manuálních SA a politik. Proto si příště ukážeme jak nám může pomoci IKE daemon. Také si povíme něco o L2TP, ukážeme si konfigurace pro sdílené klíče a X.509 certifikáty.
Za konzultace bych chtěl poděkovat jednomu z hlavních vývojářů ipsec-tools Michalu Ludvigovi.
Autor externě spolupracuje se společností IPEX a.s., která mu částečně umožnila práci na tomto článku.
O společnosti IPEX a.s.
Společnost IPEX a.s. (http://www.ipex.cz) je jedním z nejsilnějších poskytovatelů internetu a telekomunikačních služeb v České Republice. Celorepublikově nabízí bezdrátové i pevné připojení, ADSL, WiFi. Společnost IPEX a.s. poskytuje komplexní telekomunikační řešení.
Zdroje:
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
