IPSec na Linuxu, krok za krokem - 1

17. 3. 2006 | Jan Vondráček | Bezpečnost | 20230×

Pracuji už dlouhou dobu s Cisco zařízeními, routery, pixy a další. Můj takový koníček je zkoušet nahrazovat služby, která Cisco zařízení poskytují, Linuxem. Chci se s vámi podělit o své zkušenosti.

Úvod a teorie ipsecu

Pracuji už dlouhou dobu s Cisco zařízeními, routery, pixy a další. Můj takový koníček je zkoušet nahrazovat služby, která Cisco zařízení poskytují, Linuxem. Určitě není žádný problém spojit dva cisco routery proti sobě různými způsoby, ale spojit proti sobě zařízení různých výrobců už bývá problém. V internetovém prostředí často na takovouto nutnost narazíte, protože každý z nás si nemůže dovolit koupit Cisco router. Při takových pracech často velmi dobře pochopíte fungování nejrůznějších technologií i fungování Linuxu.

O jednu takovou technologii se s vámi chci teď podělit. Návodů na rozchození ipsecu pod Linuxem jsem četl spoustu, ale pomocí žádného se mi nepodařilo spojit přes ipsec linuxový stroj proti Cisco zařízení. Určitě to musí jít, protože ipsec je standard a už jsem to i viděl v činnosti. Ovšem všechny návody spojovaly pouze dva Linuxy proti sobě a využívaly manuální spojení ipsecem bez IKE (internet key exchanger) a to mi nevyhovuje. Ipsec je podporován i ve spoustě dalších levných necisco zařízeních a tam byste manuální spojení ipsecu jen opravdu marně hledali. Takže se do toho pustíme a nejdříve si povíme něco o teorii, co ipsec je a samozřejmě se zmíním i o manuálním spojení.

Pro Linux existuje spousta programů, které řeší bezpečnou komunikaci. Některé se dokonce honosí, že fungují na ipsecovém standardu, ale jejich implementace ipsecu není plná, a proto se nemohou spojit s jinými programy. Program, který podporuje standard je dle mého takový, který vám dovolí sestavit vpn mezi ciscem, linxovým strojem a třeba Windows. Ano, nedivte se, i Windows mají implementován ipsec, psalo ho pro ně přímo Cisco Jako nejvhodnější, a v podstatě jediný, se mi pro Linux jeví projekt Openswan. Je to pokračování projektu Freeswan. Implementace ipsecu je zde plná, i když v dokumentaci trochu vázne. A tím se zde budeme zabývat.

Teorie ipsecu

Co je to vlastně ipsec? Je to služba, která umožňuje dvěma zařízením komunikovat bezpečně, tedy šifrovaně. Co je to ale bezpečně? Bezpečně znamená nejen tak, aby nikdo neviděl obsah paketů, které posíláme, ale také, abychom přišli na to, že se nám spojení snaží někdo rušit a i v případě, že by někdo šifrování prolomil, jsme o tom věděli. Toto vše je v ipsecu implementováno. Ipsec má dvě fáze svého běhu - Main mod a Quick mod.

V Main modu pracuje IKE, který ověří obě strany šifrovaného spojení a ustanoví prvotní bezpečnou komunikaci. V této fázi se nepřenáší zatím žádná data. Cisco používá pro tuto část ISAKMP, Openswan Pluto.

Quick mod se pak již používá pro samotný přenos dat. U Cisca se to nazývá ipsec, Openswan Klips.

Existuje ještě jeden mód, Agressive. Je to zjednodušené spojení main a quick s trochu ořezanou bezpečností. Tento mód se používá pro připojení klientů, kteří nemají pevnou IP adresu, třeba připojení z dial-upu a podobně. Omezení bezpečnosti je ale vyváženo ještě dodatečnou autorizací (xauth), ale o tom si povíme dále.

Ipsec je jen o matematice. A je nutno si pamatovat jedno základní pravidlo: Bezpečná jsou jen ta čísla, která jsem si potvrdil vlastním výpočtem. A proto při počítání klíčů se skutečně všechny výpočty provádějí duplicitně, na obou stranách. Ono by to jinak ani nešlo.

Ipsecové spojení je pouze bod-bod. Pokud budete mít tři místa, která mezi sebou budete chtít spojit, vyjdou vám tři ipsecová spojení, na každé ipsecové bráně dvě - metoda spojení do full mesh. Další způsob, jak spojit tři místa, je, zvolit si jednu centrálu a ostatní místa připojit jen do ní. Výhodou je jen jeden tunel na pobočce, ale více na centrále. Pobočky se mezi sebou vidí přes centrálu, ale data tekoucí mezi pobočkami zatěžují linku centrály 2x - metoda hvězda. Při konstrukci sítě si toto musíte uvědomit a podle toho zvolit patřičnou metodu.

Pro pochopení funkce ipsecu si musíme povědět něco o základních pojmech a parametrech, které budeme nastavovat:

hash SHA-1 nebo MD5	Hash je jednosměrná funkce, která nám z textu nebo čísla vyrobí šifru. Tímto způsobem se uchovávají hesla v Linuxu, v zašifrované podobě. Při přihlášení se pak heslo, které zadáváte, zahashuje a porovná s uloženou hashí. V ipsecu se toto používá pro kontrolu, že paket nebyl modifikován. Po vytvoření, zašifrování paketu se číslo jeho velikosti prožene hashí a připojí se k paketu. Při přijetí paketu se číslo opět kontroluje, tj. velikost paketu se zahashuje a spočítaná hash se porovná s obdrženou.
DH group Dieffiel-Hellmanovo číslo	Je to velké prvočíslo používané pro počítání klíčů. A skupina nám prozradí, jak velké to číslo má být, a samozřejmě jak časově a výkonnostně náročný výpočet to je. U každé skupiny je definována šíře bitového základu. DH group 2 = 1024 bitů DH group 5 = 1536 bitů DH group 14 = 2048 bitů DH group 15 = 3072 bitů DH group 16 = 4096 bitů DH group 17 = 6144 bitů DH group 18 = 8192 bitů Skupina 1 není openswanem podporována z důvodu bezpečnosti, číslo je příliš malé. A například Cisca nemají, krom nejnovějších IOSů, podporu více než 5. Může se vám tedy stát, že příliš staré nebo hodně ořezané zařízení nebude s novým fungovat.
klíče	Preshare key - sdílený klíč je textový klíč, který je svázán s IP adresami a používá se při obou fázích. Zahrnuje se do výpočtů jak autentizačních klíčů, tak i šifrovacích klíčů. Je to jediná konstanta ve výpočtech, obě strany tento klíč musí obsahovat. Generování je snadné - něco si napište, kus textu, pozdrav a nebo jen uhoďte do klávesnice. Že se vám to zdá jednoduché a málo bezpečné? Ano, není to nejbezpečnější metoda, ale je nejsnazší a nejuniverzálnější na rozchození. RSA klíče jsou dalším typem klíčů. Asi je znáte z SSH. U nich je trochu problém, že se musí generovat v každém zařízení. Jsou bezpečnější, ale v praxi jsem je nikdy nepoužil. Posledním typem jsou certifikáty od certifikační autority. Obě zařízení se musí spojit s třetím, který jim vydá certifikát. Je to metoda nejbezpečnější, protože klíč není uložen v ipsecovém zařízení. V praxi jsem to viděl v činnosti, ale také nikdy nepoužil.
DES	Šifrovací algoritmus s délkou klíče 56 bitů. Dnes je již dost zastaralý, protože jeho rozlousknutí při dnešních výkonech počítačů trvá asi 20 minut. Pokud jej používáme, měli bychom nastavit životnost klíče tak na 10 minut. Openswan DES vůbec nepodporuje z důvodů malé bezpečnosti.
3DES	Silnější šifra s délkou klíče 168 bitů, šifruje jako DES, ale 3x dvěma klíči. Nejdříve prvním, pak druhým a na konec zase prvním. Tímto mechanizmem se sice dostaneme na dnes nerozlousknutelnou dobu, ale výpočetní náročnost je také trojnásobná. Efektivní délka klíče se tak smrskne na 112 bitů.
AES	Odlišný algoritmus od DESů s délkou klíče 128, 192 nebo 256 bitů. Je mnohem bezpečnější a také rychlejší. Dnes nejvhodnější pro používání.
PFS	Perfect Forward Secrecy - říká, jestli se v quick módu mají použít čísla vygenerovaná v main módu. Pokud je na yes, čísla se generují znovu. Je to bezpečnější, ale trochu náročnější na výkon a čas při sestavování spojení. Při dnešních výkonech je zdržení nepostřehnutelné.
tunelovací a transportní mód	Při transportu dat se ipsec může chovat dvěma způsoby. Zašifruje datovou část a zbytek, IP záhlaví, nechá bez změny, a nebo zašifruje celý paket a přidá novému paketu nové IP záhlaví. První, transportní, mód vyžaduje, aby pakety mezi ipsecovými zařízeními mohly chodit i bez šifrování. Druhý, tunelovací mód, umožňuje propojit dvě sítě s neveřejnými adresami. Rozdíl je ve větším overheadu v tunelovacím módu a mohou se pak vyskytnout problémy s fragmentací paketů. Na Linuxu jsem se ale s problémy s fragmentací nesetkal. Na Cisco routerech problémy s fragmentací bývají a tam se to řeší tak, že se vytvoří gre tunel a šifrují se až pak gre pakety. Je to nelogické, ale funguje to. Cisco zařízení mají při použití přídavných šifrovacích modulů, VPN akcelerátorů, až 5x větší výkon při tunelovacím módu. Na to je také třeba pamatovat. transportní mód tunelovací mód

IKE, ISAKMP, PLUTO

Jak již jsem psal výše, IKE se stará o počáteční navázání spojení a především o autentizaci. Autentizací zde rozumíme to, že pokud chci s někým, dle konfiguračního nastavení, navázat spojení, musím si být jistý, že je to on. A především, že naši počáteční domluvu nikdo nerušil a i pokud poslouchal, že mu to není nic platné. Je důležité si uvědomit, že musíte vytvořit zabezpečené spojení skrz prostředí, kde vás může kdokoliv slyšet. Pro lepší představu si vemte místnost plnou lidí a vy si potřebujete s někým promluvit tak, aby z vaší komunikace nemohl nikdo jiný těžit. Tomu, že vás uslyší, bohužel nemůžeme zabránit.

Main mód za účelem navázání spojení sestavuje spojení na UDP 500. Port 500 je cílový i zdrojový. Někde se také můžete setkat s pojmenováním, že je navázán jeden obousměrný tunel, samotná data pak proudí dvěma jednosměrnými tunely navázanými quick módem. To je dáno asymetrickým šifrováním ipsecu, zašifrujete jedním klíčem, ale rozšifrovat musíme druhým. U asymetrické šifry se klíč na zašifrování nedá použít na rozšifrování zprávy.

V rámci main módu se tedy posílá šest zpráv. Výsledkem těchto zpráv je autentizace obou stran a šifrovací klíč pro posílání prvních navazovacích zpráv quick módu. Nejdříve vysvětlím, jak onen šifrovací klíč vznikne. Pro zjednodušení to ukážu na skutečně jednoduchém příkladu se symetrickou šifrou. Symetrická šifra má jeden klíč pro šifrování i dešifrování. Příklad, který uvádím, je velice jednoduchý, a proto, jestli to bude někdo zkoušet, zapomeňte na komplexní čísla a také na kalkulačky. To aby vynikla výpočetní i časová náročnost tohoto procesu.

5*2*3=30

Zde jsme si vytvořili klíč 30 a pro zjednodušení si vezměte zprávu napsanou v čistém textu. Každému znaku přiřaďte číslo, třeba podle ASCII tabulky. Pro zašifrování vám stačí přičíst ke každému číslu ASCII znaku klíč 30 (pokud dojdeme nad 255, skáčeme zpátky na nulu) a vyjde vám z toho již dosti obtížně čitelný text. Počítače to provádějí tak, že klíč je binární sada 1 a 0, a mezi daty a klíčem se provádí logická funkce XOR. Pokud takto zašifrovanou textovou zprávu někdo dostane a ví, že má od každého ASCII znaku zašifrované zprávy odečíst 30, výsledek dostane poměrně rychle. Pokud je ale klíč složen ze dvou velkých prvočísel, je řešení v rozumném čase prostě nemožné. A na tomto podobném principu, ovšem složitější v tom, že klíče jsou dva, funguje i ipsec.

Klíč tedy máme, ale jak jsme se k němu dostali, aniž by to někdo zjistil, že klíč je 30, i když poslouchá naši domluvu? Odpověď je právě v tom násobení. Při sestavování klíče si strana A vygenerovala číslo, zde 5. Strana B číslo 2. Strana A pošle straně B svoje vygenerované číslo a strana B udělá pro stranu A to samé. Číslo 3 je v příkladu sdílený klíč. Obě strany tedy mají všechna čísla a mohou vypočítat daným vzorcem, který je všeobecně znám, šifrovací klíč. Asi si někdo řekne, že to je nesmysl, když znám vzorec a že jsem odposlechl čísla 5 a 2, mohu si klíč sestavit. To je omyl, nevíte třetí číslo, ze kterého se šifrovací klíč skládá. Takže si můžete dát do hromady 5*2*x=šifrovací klíč, co vám to ale pomůže? I v případě, že budeme za klíč uvažovat čísla 0-9, získáme 10 různých klíčů a pomocí nich se musíme pokusit zprávu přečíst. Kolik úsilí a času nám zabere takto rozšifrovat byť i jedno slovo? Pokud nejste génius, zcela jistě 100x déle, než kdybyste klíč znali. Zpráva mezitím už třeba pozbyde platnosti. Dalším opatřením, které se zde implementuje, je, že klíč platí jen po určitou dobu nebo že platí jen pro přenesení určitého objemu dat. Při výměně dat mezi A a B stanovíte znovupočítání klíče každou minutu a nebo 10 slov. Po uplynutí minuty nebo přenesení deseti slov se šifrovací klíč počítá nový a čísla z příkladu 5 a 2 se změní. Pokud byste chtěli zprávu rozšifrovat jako záškodník, musíte si také dát pozor na včasnou změnu klíče, jinak by vám zase vycházely nesmysly.

Navíc pokud ipsec pojme podezření, že mu došel poškozený paket a že by mohlo dojít k narušení bezpečí obsahu - paket raději zahodí a iniciuje nové počítání klíče. Přesto, že je náš příklad matematicky pro první třídu, již to tak jednoduché není, že?

Jednoduchý příklad pro počítání klíče v main módu máme za sebou a teď se tedy můžeme vrátit k oněm šesti zprávám:

1. Pokud chce strana A navázat spojení, pošle straně B své schopnosti. Třeba: "Použiji sdílený klíč, hashovací algoritmus MD5, kryptovací metodu AES o velikosti klíče 128 bitů, pro generování náhodného velkého prvočísla (v příkladu jsme generovali čísla 5 a 2) DH skupinu 5, klíč bude platit hodinu nebo bude pro přenesení 100 MB dat." Tento soubor schopností se nazývá policy a zařízení jich může poslat více s různými kombinacemi.
2. Strana B odpoví straně A, jakou policy akceptovala. Policy jde jako čistý text výše zmíněným obousměrným tunelem. Do našeho příkladu by se dala zanést jako domluva, jak velká čísla budeme generovat a jakou metodou budeme posouvat znaky - šifrovat. Vzoreček pro výpočet šifrovacího klíče je pevně dán standardem.
3. Před vysláním třetí zprávy dojde na základě parametrů z policy k vygenerování našeho velkého prvočísla. Generování jakéhokoliv náhodného čísla je pro počítač problém, není na to stavěn, a tak se jako generátory náhodnosti berou různé zdroje. Brumy ze zdroje a nebo, jak jsem nedávno četl o společnosti Via, z teploty cpu Toto číslo se pošle straně B.
4. Strana B také vygeneruje číslo, ze kterého se šifrovací klíč počítá, a pošle ho straně A. Upozorňuji, že toto je dost zjednodušený model, protože čísel se kvůli kontrole a výpočtu pomocí skutečného vzorečku generuje více.
5. Před dalším paketem se provede výpočet klíče. Pak se vezmou známá data, vypočítaným klíčem se zašifrují a pošlou straně B. Paket jde stále obousměrným tunelem, ale už v šifrované podobě.
6. Strana B také spočítá klíč a pošle ho straně A. Zároveň vezme spočítaný klíč a pokusí se s ním přečíst paket poslaný ve 5. zprávě od A. Pokud se to povede straně A i B, obě prohlásí quick mód za úspěšně ukončený.

Tímto se obě strany bezpečně poznaly a vytvořily šifrovací klíče pro přenos zpráv pro druhý mód.

Jestliže vám navazování ipsecu selže v této fázi, bude určitě chyba v konfiguraci. Nejjednodušší způsob, jak problém odhalit je zapnout debug. Zde vám jak Openswan tak i Cisco velmi přesně popíší, při jaké zprávě došlo k chybě. V debugu totiž přímo uvidíte jednotlivé stavy MM (main modu).

Jak může dojít k chybě při spojování? Pokud používáte Linux proti Linuxu, tak asi nijak, když si dáte pozor na stejné parametry v konfiguraci. Ale když spojujete zařízení různých výrobců nebo platforem, může nastat problém. Každé ipsecové zařízení má určité defaultní parametry, které nejsou vidět v konfiguraci, a problém může být na světě. Proto pro jistotu všechny parametry raději určete přímo sami, je o možný problém méně. Openswan má kupříkladu defaultně DH skupinu 5, ale Cisco má defaultně skupinu 2; než mi to došlo, chvilku to trvalo.

Jen pro úplnou představu přikládám skutečné vzorečky, které se používají, i když by asi někdo našel mnohem lepší. Generovaných proměnných a počítání je tam opravdu o dost více. Každá fáze je oddělena prázdným řádkem. PRF je pseudonáhodná funkce, SKYID je pak už vlastní šifrovací klíč. Hash na konci je poslední zpráva s kontrolou šifrování. Index i nebo proměná a je iniciator, index r nebo proměná b je responder.

Vzorečky

Příště: IPSEC, KLIPS, druhá fáze quick mód.

       

Komentáře

[Michal Kubeček]

Ovšem všechny návody spojovaly pouze dva Linuxy proti sobě a využívaly manuální spojení ipsecem bez IKE (internet key exchanger) a to mi nevyhovuje.

Např. v LARTC HowTo je i návod na zprovoznění IPsec na jádře 2.6 s automatickým klíčováním (s démonem racoon).

[Papek]

Pekny clanok..dakujem

[Kris]

Ahoj,chtěl bych se zeptat jestli IPSec nutně potřebuje průchozí UDP port 500 nebo jestli se dá použít i jiný.

[erchamion]

Zatim jsem nikdy nevidel, ze by se ISAKMP (ktere potrebuje ten port 500/udp) dalo rozjet na jinem portu. Ale nejsem Ded Vseved...

[Pavel]

Neviděl jsem to nikde, ale port 500 je dan RFC 2401.

[Michal Ludvig]

RFC pravi ze ano, IPsec-tools umi pracovat i s jinymi porty, ale obavam se ze na vetsine klientu to nastavit nelze, takze udp/500 je fakticky potreba.

Krome toho pro cisty IPsec musite mit pruchozi IP protokol ESP, pripadne AH (tzn. IP protokol 50, pripadne 51). Neni to ani TCP ani UDP, je to proste ESP/AH. Bohuzel spousta levnejsich firewallu nedovede nastavovat jine protokoly nez TCP a UDP.

Nastesti existuje tzv. NAT-Traversal rezim ve kterem je IPsec/ESP zabaleno do UDP paketu. Pak ovsem navic potrebujete mit pruchozi port UDP/4500.

[Hany]

UDP 500 musi byt nezbytnepruchozijinak to nemaka...

[Michal Kubeček]

Nemusí. Za prvé pokud implementace IKE na obou stranách budou ochotny používat jiný port, bude to fungovat i s jiným portem. Za druhé s manuálním klíčováním nepotřebujete UDP vůbec (ale manuální klíčování je samozřejmě lepší nepoužívat).

[AX]

Autor si bohuzel nehral s OpenSWANem dost. Samozrejme, ze podporuje 1DES. "Jenom" je nutno rucne zkompilovat co nejnovejsi verzi a ve zdrojacich povolit -DUSE_1DES. Grepnout si to urcite uz umite sami. Je nutna i podpora v jadre. Mnohem vetsi porod je NATT a ADSL routery s NATovanim 1:1. BTW: OpenSWAN patch na SLES9 SP3 + vanila kernel 2.6.15.6 pro x64 masinu celkem spolehlive system sestreli. Takze bych prosil u vseho uvadet i variantu s NETKEY aka 26sec.

[PSIkappa]

Dovolil bych si upozornit, ze pluto kernelova implementacia ISAKMP a pokial budete mat vela tunnelov a pouzivat dost dlhe kluce, tak mozete mat problem s dostatkom RAM, kedze kernelova pamat sa neswapuje.

Odporucam zabudnut na taketo stariny a obskurne metody patchovania kernelu a radsej pouzit userspace implementaciu racoon, ktora ma v standardnom kernely 2.6.x podporu uz zabudovanu.

[AX]

Bohuzel musite brat ohled na "Attention: When using Linux kernel >= 2.6.10 you must use the ipsec-tools >=0.5 because this kernel added a new forward policy unknown to racoon in the older ipsec-tools."
Coz se tyka nekterych "starsich" distribuci. Konkretne SUSE LINUX Enterprise Server 9 (x86_64) SP3 ma ipsec-tools-0.3.3-1.3 a nejsem si uplne jisty, jestli si poradi s poslednim vanilkovym kernelem.

[Michal Kubeček]

Tenhle příklad bych zrovna nepovažoval za příliš relevantní, protože pokud někdo používá SLES (nebo RHEL), dělá to obvykle proto, aby měl oficiálně supportovanou platformu s pěti lety updatů, takže tam nejspíš nebude tlačit vanilla jádro…

[AX]

Bohuzel predpokladate spatne.
Nastesti jsem na zminovane konfiguraci rozjel OpenSWAN a nemusim se patlat s racoonem.

[Michal Kubeček]

No jo, vycházel jsem z toho, co by mne asi tak mohlo vést k utracení netriviální finanční částky za enterprise distribuci. Pokud budu chtít nestabilní "bleeding edge" bastl, tak ten můžu mít zadarmo…

[AX]

Netusil byste, co dokazi radice Adaptec se starymi kernely.
;(
BTW: Hlavni duvod je Oracle 10g Release 2 a na tu sedi 'nestabilní "bleeding edge" bastl' ve srovnani s cistym linux kernelem podstatne lepe.

[Michal Ludvig]

Dovolil bych si upozornit, ze pluto kernelova implementacia ISAKMP a pokial budete mat vela tunnelov a pouzivat dost dlhe kluce, tak mozete mat problem s dostatkom RAM

Pluto jsem v kernel space jeste nevidel. Vsechny IKE demony co znam (pluto, racoon, isakmpd, ...) bezi v userspace a do kernelu cpou teprve vysledky sveho snazeni, tedy klice a dalsi parametry spojeni.

Ano, kdyz budete mit fakt hodne tunelu (radove tak miliony), tak na problem s pameti mozna narazite

[Lada]

Moc pěkné čtení, děkuji za velice pěkné a hlavně srozumitelné čtení. Těším se na další nášup.

[Filip Korbel]

Diky za perfektni clanek! Vice podobnych

[Jaroslav Aster]

Ahoj, nedávno jsem řešil problém s propojením Cisca a Linuxu (racoon implementace), který se mi nepodařilo vyřešit. Pokud se někdo s podobným problémem již setkal a vyřešil jej a mohl by mi poradit, tak bych byl moc rád.

Mám dvě zařízení - Cisco směrovač a Linuxový směrovač (Debian Sarge). Za směrovači je několik sítí s neveřejnýma adresama, řekněme sítě A, B, C, D, kde sítě A a B jsou za směrovačem s Ciscem a sítě C a D jsou za směrovačem s Linuxem. Pokud chci propojit sítě A a C přes IPsec tunel mezi Ciscem a Linuxem, tak vše funguje, jak má. Pokud chci přes stejný tunel propojit i sítě B a D, tak to již nefunguje, tj. funguje jen jedna varianta tj. A <-> C nebo B <-> D, podle toho, které propojení bylo po restartu IPsec tunelu poprvé použito. Propojení Linux to Linux mi, samozřejmě, fungovalo v pořádku.

Níže uvádím výpis konfiguračních souborů:

#
# /etc/racoon/racoon.conf
#
path pre_shared_key "/etc/racoon/psk.txt";

log notify;

timer {
        phase1 60 sec;
        phase2 60 sec;
}


listen {
        isakmp verejna_adresa_Linux;
}

remote verejna_adresa_Cisco {
        exchange_mode main, aggressive;
        proposal {
                encryption_algorithm 3des;
                hash_algorithm md5;
                authentication_method pre_shared_key;
                dh_group modp1024;
                lifetime time 10 min;
        }
}

sainfo address C any address A any {
        lifetime time 10 min;
        encryption_algorithm 3des;
        authentication_algorithm hmac_sha1;
        compression_algorithm deflate;
}

sainfo address D any address B any {
        lifetime time 10 min;
        encryption_algorithm des;
        authentication_algorithm hmac_sha1;
        compression_algorithm deflate;
}

#
# /etc/ipsec-tools.conf
#
spdadd C A any -P out ipsec
        esp/tunnel/verejna_adresa_Linux-verejna_adresa_Cisco/require;

spdadd A C any -P in ipsec
        esp/tunnel/verejan_adresa_Cisco-verejan_adresa_Linux/require;

spdadd D B any -P out ipsec
        esp/tunnel/verejna_adresa_Linux-verejna_adresa_Cisco/require;

spdadd B D any -P in ipsec
        esp/tunnel/verejna_adresa_Cisco-verejna_adresa_Linux/require;

[Michal Ludvig]

Zkuste v spdadd pravidlech zmenit .../require za .../unique - tim padem se vytvori nova SA (Security Association) pro kazdy tunel a nezrecykluje se ta uz jednou vytvorena.

[Michal Ludvig]

Pekny clanek, ale precejen se tam chybky najdou. Vezmu to postupne:

Jako nejvhodnější, a v podstatě jediný, se mi pro Linux jeví projekt Openswan.

Ktery projekt je nejvhodnejsi je otazka osobnich preferenci, nicmene jediny neni: IPsec-tools (daemon racoon a utilita setkey) je zcela stabilni a kompatibilni implementace IPsec ktera vam nejen s Ciscem a Windows bude taky chodit.

V Main modu pracuje IKE, který ověří obě strany šifrovaného spojení a ustanoví prvotní bezpečnou komunikaci. V této fázi se nepřenáší zatím žádná data. Cisco používá pro tuto část ISAKMP, Openswan Pluto.

... a v IPsec-tools se ten daemon jmenuje racoon.

Quick mod se pak již používá pro samotný přenos dat. U Cisca se to nazývá ipsec, Openswan Klips.

Tesne vedle. Phase 2, neboli Quick mode, se pouziva pro nastaveni jednotlivych tunelu. Jinak receno - pri sestavovani spojeni mezi dvema pocitaci se provede Phase1 a tim se ziskaji klice pro naslednou komunikaci mezi IKE demony na obou stranach. Tito demoni si potom v Phase2 sifrovne domlouvaji parametry jednotlivych tunelu, tzn. pouzite algoritmy, sifrovaci klice (ruzne od Phase1), atd. Az se domluvi tak pro kazdy tunel zadaji tyto parametry do kernelu.

Vlastni sifrovani dat potom provadi kernel, nikoliv IKE demon at uz v Main modu ve Phase 1, nebo v Quick modu ve Phase 2.

Existuje ještě jeden mód, Agressive. Je to zjednodušené spojení main a quick s trochu ořezanou bezpečností. Tento mód se používá pro připojení klientů, kteří nemají pevnou IP adresu, třeba připojení z dial-upu a podobně. Omezení bezpečnosti je ale vyváženo ještě dodatečnou autorizací (xauth), ale o tom si povíme dále.

Tohle je uplne spatne - Aggressive mode neslucuje Main mode a Quick mode ale je nahradou jen za Main mode. Rozhodne neni nezbytne ho pouzivat pro klienty bez pevne IP, tem bude za urcitych okolnosti fungovat i Main mode. Ma sve vyhody i nevyhody a ano, je mene bezpecny. Jo a xauth je neco uuuuplne jineho. Bezpecnost Aggressive modu sice muze zvysit, ale je to zcela nezavisly algoritmus ktery jen shodou okolnosti Cisco pouziva dohromady s Aggressive mode.

DH group - Dieffiel-Hellmanovo číslo

Chudak pan Whitfield Diffie, tedy nikoliv Dieffiel, takhle mu zkomolit jmeno! V tabulce jsou jeste dalsi drobne nepresnosti u Preshared key (nejak se mi nezda ze by se PSK primo zapojoval do vypoctu, ale cist RFC se mi ted nechce) a u Perfect forward secrecy, ale nebudu zas takovy hnidopich

samotná data pak proudí dvěma jednosměrnými tunely navázanými quick módem. To je dáno asymetrickým šifrováním ipsecu, zašifrujete jedním klíčem, ale rozšifrovat musíme druhým. U asymetrické šifry se klíč na zašifrování nedá použít na rozšifrování zprávy.

To taky neni pravda. Quick mode samozrejme domluvi symetricke sifrovaci klice a kernel je potom pouziva. Vzdyt i v tabulce mate uvedeny algoritmy 3DES a AES, to jsou prece symetricke algoritmy! Dva nezavisle tunely pro data s ruznymi klici se pouzivaji z ruznych praktickych duvodu a taky proto ze tak pravi RFC Ovsem s asymetrickymi klici to nema nic spolecneho - ty se v IPsecu pouzivaji jen pri navazovani spojeni pres RSA nebo X.509 certifikaty a to jen na vzajemne overeni komunikujicich stran. Pak uz vsechno bezi na symetrickych klicich jako obvykle.

Klíč tedy máme, ale jak jsme se k němu dostali, aniž by to někdo zjistil, že klíč je 30, i když poslouchá naši domluvu? Odpověď je právě v tom násobení. Při sestavování klíče si strana A vygenerovala číslo, zde 5. Strana B číslo 2. Strana A pošle straně B svoje vygenerované číslo a strana B udělá pro stranu A to samé. Číslo 3 je v příkladu sdílený klíč. Obě strany tedy mají všechna čísla a mohou vypočítat daným vzorcem, který je všeobecně znám, šifrovací klíč. Asi si někdo řekne, že to je nesmysl, když znám vzorec a že jsem odposlechl čísla 5 a 2, mohu si klíč sestavit.

Sorry, ale tohle je nesmysl. Patrne to mel byt pokus o popis Diffie-Hellmanova algoritmu, ktery je ovsem tak zjednoduseny, ze doufam ze vam ho nikdo neuveril V D-H nestaci jen nasobit a uz vubec ne posilat moje tajna cisla otevrenym kanalem. Kdo chce vedet vic at mrkne treba na Wikipedii, je to tam velice nazorne ukazano a clovek nemusi byt matematik aby to pochopil.

Ale jak rikam, je to pekny clanek. Ovsem u takhle sloziteho a exaktniho tematu by to chtelo proof-reading od nekoho kdo by dokazal vychytat nepresnosti.

[Hany]

Bezpochyby dobry clanek akorat bych si dovolil podotknout ze na koncovich zarizenich ktere maji mezi sebou vytvorit VPN tunel musi byt polici definovany NAPROSTO shodne jinak to clovek nerozchodi ani kdyby se na hlavu postavil. Specielne u Check pointu

[Michal Kubeček]

Nemusejí.