Hlavní navigace

Vlákno názorů k článku IPv6 Mýty a skutečnost, díl VI. - Bezpečnostní mechanizmy od Petr Bedle - To ze ma neco nekvalitni iplementaci muze mit...

  • Článek je starý, nové názory již nelze přidávat.
  • 18. 3. 2011 22:02

    Petr Bedle (neregistrovaný)

    To ze ma neco nekvalitni iplementaci muze mit tri duvody:
    - Je to prilis nova vec (coz ipsec neni).
    - Neda se to dobre naimplementovat protoze je to neskutecne slozite - tedy nejspis vymyslene nejakym vedatorem.
    - Je to k nicemu, tak se to naimplementovalo, aby byl ukol splnen a dal uz to nikoho nezajima.

    Ipsec je neco naprosto sileneho a pouzije to fakt snad jen masochista, zejmena kdyz existuji moznosti jako openvpn (jeden protokol jeden port proleze takrka cimkoliv).

  • 19. 3. 2011 9:55

    Petr Bedle (neregistrovaný)

    Ok. Tak tedy jak chcete:

    - Infsrastruktura verejneho klice je naprosto totozna, jak pro openvpn tak ipsec. Oboji vyuziva X509 certifikatu. Pokud se chcete certifikatum vyhnout muzete pouzit v obou pripadech dohodnute tajemstvi. Takze nevim jak myslite, ze je na tohle ipsec lepe pripraveny.

    - Pro ipsec musite musite provozovat doprovodny mechanizmus pro vymenu klicu (IKE), ktery krmi SPD, SA. Na Linuxu resi samosatny daemon (napr. racoon), ktery si veci vymenuje po UDP port 500, nekdy 4500 (nat-t). Takze dalsi dve diry na FW. Celkove tedy pro provoz ipsecu musite rozchodit komunikace na dvou portech + protokol ESP.

    - Vlastni rozhodovani co jde do IPSec je soucasti kernelu v podobe SPD. Pri zahajeni komunikce zacne vznikat SA. Jeji vyrizeni chvili trva. SA casem zmizi, takze nezbyva nic jineho nez ipsec spojeni je treba napriklad propingavat (pokud na lince neni trvale provoz).

    - ESP se rozbaluje "nekde" v kernelu, takze pokud chcete ve firewallu ovlivnit/kontro­lovat co leze ipsecem (nebo to poslat napr do NATu, DMZ) neni to uplne jednoduche. Stejne tak pokud si potrebujete udelat diagnostiku napriklad tcpdumpem - takrka nemozne (zejmena v netunelovacim rezimu).

    - Pokud pridavate novou SPD (napr. nova pobocka) vyzaduje to restart racoona, takze vam popadaji vsechny ostatni SA a vse se navazuje znovu. Takze ostatni pobocky nachvili odrovnate. To je snad veci implementace - mozna uz dneska doresene - nevim.

    Jsou to pravda zkusenosti nekolik let stare, kdy jsme propojovani ipsecem nakonec definitivne zavrhli. Od te doby jsou pobocky propojene na openvpn, ktere se chova o dost spolehliveji a hlavne proleze temer cimkoliv. Nasazeni ipsec znamena (ci spise znamenalo), ze na to musite malem najmout cloveka, ktery bude resit neustale problemy s ipsecem, ladit chyby implementacich a ucit konfigurovat adminy na pobockach firewall tak aby tim ipsec prolezl.

    Zajimave je, ze ipsec je nedotknutelnou svatou kravou, stejne jako IPv6. Sotva nekdo zmini vyhradu, tak se tak se na nej sesypou *jasanci, kteri si vec vyzkouseli tak max. mezi dvema PC. Jen by me zajimalo jestli jsou to stale ti stejni lide, nebo jsou to disjunktnti skupiny :-) Posledni dve vety berte prosim s nadsazkou :-))

  • 17. 3. 2011 18:35

    DB (neregistrovaný)

    Tak část o IPSec jste klidně mohli vyhodit, protože:
    - je společná pro IPv4 i IPv6
    - má téměř stejné vlastnosti jako ostatní technologie typu PPTP, L2TP, OpenVPN, atd.

    Co se týká IPSec pro eduroam, tak nahrazení IPSecu RadSecem bylo dáno spíš nekvalitní implementací než nějakou systémovou chybou IPSecu. S kvalifikací správců to nemá nic společného.

  • 17. 3. 2011 20:38

    ehm (neregistrovaný)

    Ja jsem obycejny amater, ale o IPSec se rika, ze v IPv6 je trochu odlisne od IPv4. Me osobne zarazila informace, ze kazde zarizeni, ktere umi IPv6, by melo umet i IPSec. Poznal jsem uz zarizeni, ktera mela pamet tak na 5 (slovy) paketu a zadychavala se i pri vypoctu CRC. Vypocet nejakych sifer by pro tyto brouky byl vrazedny.

    Neznam L2TP, ale IPSec se od OpenVPN hodne lisi a od PPTP docela taky.

  • 17. 3. 2011 20:43

    DgBd

    Jediné v čem se IPSec v IPv4 a IPv6 liší je to, že v IPv6 je jeho implementace povinná (což ovšem neznamená, že ji všichni výrobci do svých produktů zabudují, případně, že tam bude jiná metoda šifrování a autentizace než NULL, NULL)

    IPSec se samozřejmě od ostatních šifrovacích technologií liší, nicméně mají společné to, co se IPSec v článku vyčítá, tj. to, že není vidět do obsahu paketů a je tedy nutné IPSec zakázat. Tímto způsobem by se musely zakázat všechny šifrovací protokoly.

  • 17. 3. 2011 22:01

    TP

    Předně bych byl nerad, aby věc vyzněla tak, že se IPSec-u něco vytýká. Snahou bylo popsat realný stav věci.

    Důvod proč si myslím, že je to důležité je ten, že postupem času došlo k výraznému odklonu od původního záměru použití IPSec. Měl obecně zaručovat bezpečnou komunikaci v idelaním případě mezi jakýmimikoliv uzly (proto ta povinná implementace). To se projevilo v řadě návrhů standardů - například OSPFv3 neřeší autentizaci sousedů, protože se odkazuje na IPSec (viz. http://www.rfc-editor.org/rfc/rfc4552.txt).

    Dnes naštěstí postupně dochází k jistému IPSec-ovému "vystřízlivění" a IPSec se postupně dostává tam kde je, dle mého názoru, jeho místo - tunelové provozy, VPN, specializované průmyslové aplikace atd. Tedy rozhodně ne v pozici, kdy vaše účetní komunikuje IPSec-em s internetovým bankovnictvím.

    Podobnost s PPTP, L2TP či OpenVPN platí pouze v tunelovacím režimu. Tyto protokoly jsou na úrovní korporatniho firewallu dnes běžně zakazovány a povolovány pouze na validní adresy (tedy servery obsluhující tyto protokoly). OpenVPN tunel připojený na PC vaší účetní by vas určítě vyděsil, nicméně v případě IPSec-u není zvykem o "podivnosti" komunikace takto uvažovat - vždyť je to přece ten bezpečný protokol nového Internetu.

  • 17. 3. 2011 22:54

    DgBd

    z hlediska toho, že na konci všech pravidel korporátního firewallu je obvykle deny, tak se IPSec bude chovat stejně jako PPTP nebo OpenVPN. Takže IPSec mne děsí výrazně méně než OpenVPN, kterým se dá tunelovat provoz přes HTTP (a tedy potřebuju nějaký inteligentní L7 firewall).

  • 18. 3. 2011 13:19

    Majklík (neregistrovaný)

    To Vás může děsit o to spíše SSTP, což je přímo součástí Windows a je to VPNko jdoucí přímo skrz HTTPS...

  • 19. 3. 2011 10:06

    Ondrej Santiago Zajicek (neregistrovaný)

    > ESP se rozbaluje "nekde" v kernelu, takze pokud chcete ve firewallu ovlivnit/kontro­lovat co leze ipsecem (nebo to poslat napr do NATu, DMZ) neni to uplne jednoduche. Stejne tak pokud si potrebujete udelat diagnostiku napriklad tcpdumpem - takrka nemozne (zejmena v netunelovacim rezimu).

    Tohle je problem spojeny s tim, ze nektere implementace IPSecu (treba ta v Linuxu) maji divne reseny tunel mod z hlediska jak se prezentuje zbytku sitoveho stacku. Tyto problemy jsou popsane v RFC 3884, doporucene reseni je pro ucely VPN nepouzivat tunel mod, ale transport mod na ipip tunel.

  • 20. 3. 2011 9:14

    Petr Bedle (neregistrovaný)

    Ten prvni pripad s DES56 a AES256 mi teda prijde hodne pritazeny za vlasy, ale budiz. OpenVPN pouziva SSL/TLS vrstvu, kde se samozrejme muzete definovat jak algoritmus (volba cipher), tak delku klice pro jednotlive kanaly (volba keysize). Je to dano moznostmi OpenSSL nez samotnym OpenVPN.

    Myslenka s tcpdumpem je hodne zajimava - urcite by neco takoveho spousta lidi ocenila - obecne i do toho OpenVPN :-) .

    Argument o zplacanosti je velice sporny. Pokud bych chtel pouzit obdobne zabarveny ekvivalent, tak reknu, ze v IPSec je zas vsecko roztristene. Kupodivu s tou zaplacanosti zijeme v HTTPS, IMAPS, POP3S a nevim jeste v jakem vsem moznem *S. Vrstva SSL/TLS velice dobre odladena, protoze se uz nejaky ten patek pouziva.

    Jako vyhodou IPSecu vidim, ze je to standardizovane reseni, takze dokazete propojit treba CIsco a Linux. Tohle na OpenVPN neudelate (zatim).

    Jinak samozrejme pred vami smekam, ze jste ochoten dobrobvolne pouzivat IPSec aniz by vas k tomu nutily vnejsi okolnosti (skladba HW, korporatni politika definovana nekde na ustredi v USA). Na druhou stranu kazdy si zde muze zvolit presne to co mu vyhovuje, coz je zasadni rozdil oproti IPv6, kde se musi shodnout vsichni na jednom reseni.

    Jen mi hodne vadi, ze kazde IPv6 zarizeni by melo podporovat IPSec. Nastesti na to rada implementaci kasle bez ohledu na to co rikaji RFC.

  • 20. 3. 2011 11:23

    DgBd

    když se podíváte do man tcpdump, tak je tam položka -E. Opravdu stačí jenom malý krůček k tomu, aby si tcpdump bral parametry z nějaké jaderné struktury místo příkazového řádku. To podle mne u OpenVPN neuděláte, protože ten si svoje stavy udržuje uvnitř sebe (a řekl bych, že by to ani nebylo jednoduše implementovatelné, narozdíl od IPSec)

    IPSec používáme proto, že se nám dost často stává, že na jedné straně je linux a na druhé třeba cisco. Ale upřimně řečeno si jako masochista připadám pouze na linuxu, protože tam aby se v některých implementacích prase vyznalo a odladilo. U FreeSWAN bylo úplně jednoduché používat tcpdump, protože FreeSWAN vytvářel virtuální interface, přes který se dal odposlouchávat provoz nešifrovaně. U nové implementace je to dost problém. Na druhou stranu, nové řešení je funkční a nestává se mu, že by padalo.

  • 21. 3. 2011 8:00

    Majkl (neregistrovaný)

    Ehm, zrovna uvádět OpenVPN jake ukázkau, jak se dá jendoduše využít možností OpenSSL knihovny je dost úlet, že? Tak zkprasené využití jsem už dlouho neviděl. Hodně let měli v OpenVPN chybu spočívající v tom, že když se použíl CRL a jemu skončila platnost, tak se ignoroval, takže pokud byl nějaký certifikát zneplatněn a CRL prošlé, tak se přesto přihlásil. Teď je to už aspoň tak,že i po skončení plantosit se CRL uplatňuje a filtruje dle něj, akorát to do logu řve, že už je za zenitem (snad všechny IPsec implementace, co jsem měl v ruce, v takovém případě zastavily komplet vše s certifikáty nbo to bylo konfigurovatlené chování, je na uvážení co je horší). Dosud nezvládá OpenVPN korektn práci ve složitější certifikátové hiearchii (spoustu let visí v TODO, že to bude někdy vyřešeno). Jakmile certifikační autorita, co vydává certifikáty pro OpenVPN, není root, tak je těžký problém opět s CRL, nefungují (funguje jen jeden, a to první nalezený). Natož nějaká snaha o online ověřování certifikátů atd (což už umí i ta poprasená implmentae IPsec v historických XPčkách, když se to v registrech zapne). A pokud vezmu v potaz OpenVPN klienta a jeho použití normálním uživatelem ve woknech, pokud má práva jen user, tak to také není úplně jendoduché (vím, openvpn jako tkaové to relativně OK podporuje, jen k tomu chybí patřičně rozumné GUI, pokud s eněco v posledních mědsících nezměnilo). Taktéž dost problém s HW tokeny pro uložení certifikátů (zvláště v HW tokenech natvrdo v notebooku a kombinace s Windows).
    Ale uznávám, že OpenVPN je relativně jednoduché, pokud mám pár klientů/serverů, které mám sám pod kontorlou, k tomu několik mobilních notebookářů, které mockrát nemusím omezovat a ani nejsem závislý na složitější certifikační hiearchii, tak je to v pohodě nástroj. Taktéž to má schopnost lépe prolézat přes NATy, má to menší režii na data (pokud porovnán s defualt klientem ve wonech, který jede L2TP/IPsec mix). Jakmile jsem na to ale tak, že řadu klientů, serverů, protistran má pod palcem někdo jiný, jsem nucen fungovat v rámci hiearchických firemních delegovaných certifikačních autorit s oddělenými pravomocemi, jakmile musím připojovat do VPNka kdejaké obskurní zařízení (včetně třeba mobilních telefonů), tak to smrdí tím IPsecem, který kupodicu funguje. Ano, některé implementace má svoje slabiny, ale dá se s tím vyžít s použitím všech vyjmenovaných sprostých slov. :-)

  • 19. 3. 2011 0:09

    DgBd

    Vy o IPSec víte tak maximálně velké kulové. IPSec je založený na jednoduchých principech s dostatečnou rozšiřitelností.

    OpenVPN je sice pěkná věc, ale ve chvíli, kdy do toho zamotáte infrastrukturu veřejných klíčů, tak se dostanete do horší situace než IPSec, který je na to připravený.

  • 19. 3. 2011 11:22

    DgBd

    Zkuste mi tedy nastínit s OpenVPN situaci, kdy mám různé úrovně bezpečnosti procesů a chci, aby procesy na úrovni 2 mohly komunikovat pouze prostřednictvím šifrování s DES56 a vyšším a na úrovni 3 se šifrováním AES 256 a vyšším.

    To co zmiňujete s rozbalováním v kernelu je čistě implementační záležitost. Tcpdump svého času uměl tato spojení dešifrovat, pokud jste mu předhodili správný klíč. Takže vazba tcpdumpu na jaderné struktury ve kterých jsou aktuální šifrovací klíče tady toto celkem řeší.

    OpenVPN má jak provoz, tak výměnu klíčů splácanou dohromady, takže ladění případných problémů je komplikovanější.

    Osobně mám IPSec nasazený na několika lokalitách a problémy jsou pouze se starými verzemi FreeSWAN. Nutno přiznat, že dnešní způsob implementace IPSecu v Linuxu, nebo spíše nedotažení nástrojů jako tcpdump, nejsou taky úplně nejlepší.

  • 19. 3. 2011 11:46

    DgBd

    Abych to vyjádřil jednoduše, IPSec je možné, díky jeho architektuře, dekomponovat na jednotlivé součástky a ty pak jednodušeji ladit, případně nahradit jiným software. Je možné definovat vazby mezi součástmi mimo program a umožnit tím přístup programům třetích stran, jako třeba zmiňovanému tcpdumpu.

Upozorníme vás na články, které by vám neměly uniknout (maximálně 2x týdně).