Praktické problémy s IPv6, část druhá

Moc pěkný článek. Jen tak dál...

Naprosty souhlas s clankem.
Autokonfigurace je dobra tak na doma. Proto jsem odlozil implementaci IPv6 ve vnitrni siti ve firme na neurcito.

Dalsi problemek vidim ve zmene prefixu. Zatim jsem testoval pres 6to4, ale kdyz
si predstavim, ze po prideleni prefixu bych musel zmenit vsechny konfiguraky daemonu na serverech....
Preci jen v IPv4 a SNAT + DNAT resi zmenu verejne ip adresy daleko elegantneji.

Na to nejaky trik neznate?

Pekne.

>> Správce sítě, který se rozhodne mít v síti pořádek má obvykle velkou tabulku s jménem PC, MAC adresou, IP adresou.

..a priblizne v teto dobe jsem si rikal, ze celej IP protokol je v podstate jen zdvojnasobeni problemu a ze by bohate stacily MAC adresy - a jeden funkcni jmenny system (DNS).

[3]. Nestačily. Nejsou hierarchické – plní funkci univerzálního identifikátoru, ale ne lokátoru. A ani nemohou, jestliže jsou pevně dány výrobcem. Znamenalo by to, že každá síťová karta by byla vyrobena na míru pro danou síť a v žádné jiné by nefungovala.

dik, za clanecek, prvne musim souhlasit, ze prechod nebude pro poskytovatale asi uplne jednoduchy.

Děkuji za výborný článek.

Hezký článek, jen tak dál :-).

Nemůže DHCP relay předávat nadřazenému serveru i MAC adresu? Chápu, že to asi v dohledné době nebude zakotvené v RFC, ale technicky tomu snad nic nebrání.

Přijdu k síti, pozměním si MAC adresu a připojím se. Privacy extension je pouze standardizovaný způsob řešící výměnu adresu. Pokud chci stroje evidovat, hlídat a blokovat, musím mít filtrující switch s linkou vyhrazenou ke každé stanici (802.1x). V opačném případě si na zabezpečení jenom hraji.

Že DHCPv6 přešlo na DUID má svůj význam. (Už jste zkoušel IPv6 na neetherenetových point-to-point spojích?) Já jsem například ve své síti zažil více výměn síťových karet než přeinstalací. Váš problém pravděpodobně tolik lidí nepálí, protože jinak by někdo takovým způsobem klienta už upravil (například implementoval by ruční specifikaci DUID; ostatně specifikace nic takového nezakazuje, naopak tvrdí, že DUID má být nezávislý na výměně hardwaru). Nicméně například dibbler umožňuje odvodit DUID jen z linkové adresy (duid-type duid-ll).

[7] Ano, mohl by, kdyby normotvůrci chtěli. Jenže oni nechtějí. Viz odkazovaný mail Teda Lemona.

[8] Díky za příspěvek, přesně něco takového jsem chtěl slyšet. Ještě by mě zajímalo, protože nemám v téhle oblasti moc zkušeností, jestli switche, které umí 802.1x, umějí také nějak monitorovat, jaké IPv6 a IPv4 adresy na daných portech komunikovaly? Protože jinak v případě bezpečnostního incidentu pouze zjistím, že v dané chvíli bylo k VLANě autentifikováno 200 uživatelů a jeden z nich má incident na svědomí…
Nebo to má smysl jen když každý klient má svou VLANu? To by byl samozřejmě ideální stav, leč na spoustě míst, včetně např. Strahova, velice těžko dosažitelný.

prirazeni IP MAC port muzes delat napriklad pomoci dhcp snoopingu

[8]Cože? Více výměn síťových karet než reinstalací OS? To si nedovedu představit. Vy jste asi přecházel z Token Ring na tlustý Ethernet, pak na koaxiál, pak na 10MBits kroucenou dvoulinku, pak na 100MBits, pak na 1GBits a pak FO? A to jste vydržel s jedním, nebo několika málo OS? Opravdu jsem zvědav co to bylo za experimentální instalaci - nějaká videostřižna či animační studio?

[9] 802.1x standardne toto neriesi, pricom samozrejme je mozne pomocou accountingu pomocou RADIUS protokolu zalogovat MAC adresu autentifikujuceho sa zariadenia/za­riadeni na danom porte. Obvykle sa to riesi skor/zaroven vytahovanim MAC adres tabulky zo zariadenia (SNMP) - zistime na ktorom zariadeni/porte ktora MAC bola cca. od-do (pri RADIUSe to "do" nemusime vzdy zistit). IP adresu co sa tyka autentifikacie cez 802.1x neriesime, pretoze ju prideluje DHCP/RADV, k comu dochadza v inej fazy nez vo fazy autentifikaci­e/autorizacie zariadenia (samozrejme existuju konfiguracie s pridelovanim cez RADIUS, ale je to komplikovaniejsie a u IPv6 som sa s tym nestretol). Co sa tyka zistenia IP adresy, tak sa pouziva ndpmon (obdoba arpwatch) a tym sa ku kazdej MAC zisti IP, spoji sa s informaciou ziskanou zo SNMP a je to. Sofistikovanejsie riesenie je zatial dostupne len u Cisca (a to som zatial netestoval), kde je mozne pouzit funciu "RAguard", kde mozeme zapnut dhcp snooping pre ipv6 a ip source guard pre ipv6 - ale to nam riesi ak ma pamat neklame len pripad, kedy je pouzite DHCPv6. Vzhladom k tomu, ze vo velkych sietach su rozne typy zariadeni a to hlavne docasne prinesene zariadenia, ktore nie su sucastou siete, potom diskless stanice, mobilne hracky a pod. je nasadenie len DHCPv6 dost obtiazne (pretoze nie vsetky zariadenia vedia DHCPv6). Takze sa pouziva RADV metoda a proste sa to riesi metodou logovania MAC a IPv6 adries, ich parovanim atd..

inak EUI64 checking je fajn, ale vzhladom k tomu, ze zatial to je akurat tak v linuxe, tak na velkych sietach, kde su HW boxy v ulohe routrov to nie je mozne pouzit. Samozrejme niektori spravci to zatial riesia tak, ze IPv6 prehanaju cez linux router, kde je EUI64 checking zapnuty. Problem je v tom, ze sa tym padom u docasne prinesenych notebookov (hlavne s windows), vyzaduje rekonfiguracia sietovych nastaveni, co casto znamena aj restart windows, co je dost casto velmi iritujuca zalezitost pre uzivatelov - pokial by mal windows defaultne nahodne generovanie IPv6 adresy vypnute, tak by to bolo zatial jedno z najlepsich rieseni, ale takto je to tazko nasaditelne v pripade velkych heterogennych sieti.
Inak co sa tyka privacy extension (samozrejme nie je to len problem samotnych PE), tak vidim to ako dost velky problem, pretoze vo chvili ked dojde k masivnejsiemu rozmachu IPv6 a zacne sa skodit z nejakeho PC v sieti, tak v cielovej sieti viac menej neostane ina moznost ako vyblokovanie celeho IPv6 rozsahu odkial utocnik pochadza, pretoze bude velmi malo sieti kde bude EUI64 checking a utocnika bude mozne v cielovej sieti vyblokovat zakazanim jeho IP.
Sice v zdrojovej sieti zistime po case (tj. v pripade analyzy logov ak nejake mame), ze kto vtedy a vtedy skodil, ale v cielovej sieti bude vyblokovany cely nas adresny range. Samozrejme su predpoklady, ze postupne dojde aj k nasadzovaniu inteligentnych IDS/IPS v kazdej vacsej sieti, ale kedze je to otazka penazi a zaroven aj otazka urovne vyspelosti admina, tak sa obavam, ze to az take ruzove nebude.

Problém ohledně DUID jsem nějak nepochytil. V plném DHCPv6 přidělenou adresu řídí server, řídí ji podle toho, ze které sítě požadavek přišel a podle DUID (identifikátoru stroje). Takže DHCP server má vědomí toho, ke které síti a kdo se chce připojit. Na základě toho přidělí adresu, nebo nepřidělí :). Nevim jak vadí, že DUID je neměnné. Pokud jednou přidělím zařízení DUID, tak podle toho DUID je mu možné přidělit klidně 100 adres najednou (jednu ethernetu, jednu WIFI, jednu v tunelu ... Jestli je problém, že Dualboot má pokaždý jiný DUID, tak jej nastavte stejně, nebo na druhou stranu se radujte, protože máte možnost nastavit jiné adresy pro každý OS zvlášť (to u IPv4 nebylo).
Privát bych také moc neřešil... prostě pokud to firemní politika zakáže tak to vypnete a hotovo.

[14] Problém je v tom, že IPv6 neexistuje (a dlouho nebude existovat) samo o sobě, ale v kombinaci Dual Stack s IPv4. Existuje hromada backend systémů, které dokážou udržovat v síti pořádek (vazbu MAC adresy a IPv4 adresy) a do jisté míry tento pořádek vynucovat (např. port security na switchi, IP filtr a statický ARP na routeru). A do toho přijde DHCPv6 s novými identifikátory, které se nedají odvodit z žádných existujících a navíc se mění nezávisle na ostatních (ať už reinstalací OS, nebo dualbootem). Pokud budu chtít stejnou míru zabezpečení i pro IPv6 sítě, nemám jak naplnit ani IP filtr, ani statickou ND tabulku na routeru, protože vazba mezi DUID a ostatními identifikátory neexistuje.

Nebo dojde k bezpečnostnímu incidentu a já z logu DHCPv6 serveru zjistím DUID útočícího počítače, jenomže to je informace, kterou ze switch tabulek nevyčtu. Takže mi nezbude nic jiného, než ručně obejít všech třeba 253 stanic a zjistit, která z nich používá daný DUID.

Hmmm...., DHCPv6..... Takže když nabootuju bezdiskovou stanici, tak si při každém bootu vymyslí nějaký DUID, pokaždé jiný, a DHCPv6 server nebude vědět, kterou bootovací image jí předhodit. Tak to ať jdou s celým slavným IPv6 soudruzi někam!!

Bootovací firmware nemá přístup k disku, takže buď bude používat DUID, který bude součástí toho firmware, nebo použije DUID typu 3, což je MAC adresa jedné síťové karty. Rozhodně si nemůže při každém bootu vymyslet jiný, to by odporovalo definici.

V případě integrované síťové karty na základní desce, což je naprostý standard, mi DUID typu 3 (DUID-LL) připadá nejsympatičtější. Pokud přijmeme premisu, že počítač = základní deska, pak je DUID typu 3, odvozený z MAC adresy integrované síťové karty zároveň unikátní pro daný počítač, zároveň neměnný při výměně síťové karty (neboť ji nelze vyměnit bez výměny počítače) a k tomu všemu navíc jednoduše predikovatelný a stabilní proti multibootu a klonování.

[17] no tvrdit ze zakladna doska=pocitac (uz mam tretiu zakladnu dosku, OS som nemenil), pripadne ze kazda zakladna doska ma integrovanu sietovu kartu je dost odvazne ;-)

[18] Ano, může to tak být, pak ale navrhněte, co brát jako komponentu, která určuje počítač.
Asi se shodneme, že při výměně skříně, napájecího zdroje, CPU, nebo paměti, zůstane zachován stejný počítač. Ale při výměně základní desky nebo HDD, je to co vznikne stejný, nebo nový počítač?
Nebo snad ke změně počítače dojde při výměně nadpolovičního počtu komponent? Nebo ke změně nedojde, dokud zůstane alespoň jedna komponenta ze starého? Možností je spousta, základní deska mi připadá jako nejrozumnější kompromis.

A k síťové kartě: Právě koukám na první dvě stránky se základními deskami na známém e-shopu, všech cca. 20 mělo aspoň jeden vestavěný ethernetový adaptér, takže pokud se ještě vyrábí nějaké základní desky bez integrovaného ethernetu, bude to spíše výjimka, než běžný stav.

Možná to celé špatně chápu, ale tohle vypadá jako absolutně nepoužitelné. Máme ve firmě plno PC, u kterých je adresa víceméně ukradená. Ale u pár desítek je nutné, aby měly tu správnou IP adresu. Jedná se o průmyslová PC na testovacích linkách a je bezpodmínečně nutné, aby stanice XY měla neustále svou jednu pevnou IP adresu, protože ji podle toho ostatní počítače poznají a také jí na tuhle adresu "volají". Pokud některé z těch PC umře, vezme se jedno ze záložních předinstalovaných, připíchne se místo starého, podle MAC adresy (napsaná zezadu na počítači) se odklikne cosi v konfiguraci DHCP, počítač se spustí, dostane od DHCP serveru tu správnou IP adresu a běží. Výměna PC je tedy otázkou několika málo minut (<5) a nevyžaduje aby na tom PC někdo přepisoval konfigurační soubor s pevnou adresou (což by byl trochu problém, protože tam je speciálně upravená Linuxová distribuce bez roota).

Podle tohohle blogu mi to přijde, že tohle je v případě IPv6 neřešitelné. Všechna PC jsou naklonovaná, tu správnou IP adresu jim přidělí DHCP server, konfiguraci software si obslouží sama aplikace podle toho, co jí řekne aplikační server (který ji pozná podle IP adresy). Zkrátka tahle PC nejsou anonymní, musí se hlásit tím jediným správným jménem a to se v čase mění (podle toho, kam je to PC fyzicky připojeno). Teď stačí naskenovat čárový kód ze stolu (IP adresa) a čárový kód na PC (MAC adresa) a software přenastaví DHCP tak, že počítač při bootu již naběhne správně. Je to tedy takto řešitelné i s IPv6? Zkoušeli jsme to řešit i přes DNS, ale to nefungovalo - po výměně PC ještě pár minut trvalo, než ostatní počítače pochopily, že počítač "LTEST28" už není 10.214.3.48 ale je to teď 10.214.3.92. S IP adresou ho našly okamžitě jak nabootoval.

[20]: U Linuxu to problém není, DUID může být i MAC adresa, můžeš tedy klidně před spuštěním DHCPv6 vygenerovat DUID skriptem z MAC adresy. Tohle jsem použil, když jsem implementoval IPv6 do jednoho klientského Wi-Fi routeru. Případně u klienta Dibbler se to dá přímo nastavit, jak psal kdosi přede mnou, ale tam mi zase nefungovala prefix delegation.

[20]: Mimochodem, druhá cesta, kterou jsem zvažoval, bylo upravit DHCPv6 server tak, aby u DUID porovnával jenom tu část odvozenou z MAC a tu proměnlivou ignoroval. Nakonec jsem to ale zavrhl, protože by to bylo aplikovatelné jen na klienty s jediným síťovým rozhraním. DHCPv6 klient je schopný si klidně odvodit DUID z adresy na VPN rozhraní, které má náhodně generovanou MAC.

„Zkoušeli jsme to řešit i přes DNS, ale to nefungovalo - po výměně PC ještě pár minut trvalo, než ostatní počítače pochopily, že počítač "LTEST28" už není 10.214.3.48 ale je to teď 10.214.3.92. S IP adresou ho našly okamžitě jak nabootoval.“

Dlouhé TTL?

[20]: Tomu se rika "solution in search of a problem". Nejjednodussi je na takovych strojich tu IP adresu nastavit napevno pri prvnim bootu, problem vyresen.

Co se tyka privacy extensions, ty byly vytvoreny pro site kde probiha bezstavova autokonfigurace, aby bylo tezsi sledovat pocitac napric sitemi. Pokud se pouziva DHCP a to DHCP prideluje adresy jinak nez bezstavova autokonfigurace, tak nejsou privacy extensions potreba, a neni potreba je resit.

[15]
Z toho co píšete přímo čiší, že je třeba zvolit jiný přístup... Zmiňujete "stejnou míru zabezpečení", ale přitom máte na mysli "stejný způsob zabezpečení". Ne všechny věci z ipv4 světa půjdou dělat stejně v IPv6, určitě je mnoho věcí, které bude třeba se spolu s novou rodinou protokolů IPv6 naučit... Myslím, že naopak DUID má lepší opodstatnění než vázání nastavení sítě na MAC adresu počítače. A v tomto směru chápu odpor k zavádění "berliček" z ipv4 do IPv6 proto, že si na to administrátoři zvykli.

Incidenty chápu jako problém, ale bez znalosti konkrétní situace (prostředí, zařízení, politiky...) se dá těžko radit jinak, než logovat používané vazby IPv6-MAC (například pomocí NDPMon)... v tom logu to najdete stejně dobře jako v logu DHCP serveru, dokonce s jistotou, že tu adresu si zrovna ve chvíli incidentu neukradl někdo jiný.

asi by nebylo od veci vydat rfc na novy protokol DHCYPv6
prvni pole by byla mac. zbytek zpravy by odpovidal DHCPv6. funkce, ktere by byly volitelne nikoliv povinne by pak byly tu idecka.

jinak multi-(interface/access-media) systemy se resi snad bridgem, ktery ma svoji mac a te se prideluje ip. akorat je potereba dat bacha, aby vsechno v siti umelo stp a byly spravne nastaveny dulezitosti switchu, aby se pak pri hledani minimalni kostry netahal traffic vsech lidi v siti co chodi mezi mezi AP a switchem a routerem skrz nejakyho chudaka co ma zapojeny drat i bezdrat a blbe nastavenou prioritu bridge.

Vida, o této "vlastnosti" DHCPv6 jsem nevěděl. Ono sice řešení vyvinutá pro IPv4 nebyla dokonalá, ale lidé se s tím naučili pracovat, a úplně na nic to taky nebylo. Takže u IPv6 to pro jistotu uděláme znova a hezky, aby se za pár let vynořily zas jiné problémy, kterých se nám ve fázi návrhu ani nezdálo...

Zrovna MAC adresa a DHCPv4 je jednoduchá a jasná věc. Scénář s více rozhraními je problém, mnohem častějsí je scénář, kdy tohle nijak nevadí. MAC je dobrá jako identifikace počítače - ať ho přeinstaluji (třeba hromadně z image) nebo nabootuju ze sítě nějaký live systém, tak "sama" naskočí správná IP adresa. V tomto případě DHCPv6 řeší neexistující problém a navrch zavásí další. Sice řešitelný, ale je to práce navíc - můžu PC indentifikovat na "aplikační" úrovni, klidně to MAC adresou. Ale proboha proč, když do teď to chodilo "samo"?

Můj pohled je možná ovlivněný tím, že se pohybuju v prostředí se stovkami pevně připojenými PC, kde nějaký útočník nehrozí, a kde výměna základní desky = PC vyhodit a dát nový, jehož nová MAC se jen zapíše do databáze.

[15]: Jsou situace, kdy je lepší vázat adresu na konkrétní hardware, i situace, kdy je výhodnější vazba na software (nainstalovaný operační systém). Do DHCP pro IPv4 byl také mechanismus DUID dodatečně zaveden. Problém je to, že DHCPv6 nedává možnost volby, vnucuje jedno řešení i tam, kde to není výhodné.

Předchozí příspěvek měl být reakce na [25]

[11] se rozčiluje, že 802.1x řešící fyzickou/linkovou vrstvu neřeší síťovou. Jistě. Pokud chcete řešit síťovou, můžete použít IPsec.

Já takhle dělám WiFi AP. Když už zabírám frekvenci, tak ať z toho mají užitek i jiní. Router nepřeposílá pakety z/do WiFi, ale na AP se může asociovat kdokoliv. Pokud někdo chce použít služeb routeru, musí si na něj natáhnout IPsec tunel. Správce pak má jistotu, co která IP adresa je zač.

[28] Tvrdí, že DHCPv6 nedává možnost volby. Ale houbelec. Přečtěte si RFC. Máte tři různé automatické způsoby odvození DUID. Navíc nikdo vám nebrání DUID nebo rovnou IP adresu nastavit na stanici natvrdo.

Souhlasím s [25], že ne všechny hrůzy, které se v IPv4 považují za normální, fungují v IPv6. Samozřejmě, že bezpečnostní nástroje pro IPv6 nejsou tak vyspělé, ale to je jen otázka poptávky a času. Rovněž souhlasím, že řešení bezpečnostních incidentů se liší případ od případu. Jsou sítě, kde je přístup k lince volný, jsou sítě, kde máte pro každou stanici vyhrazený nakonfigurovaný port. Jsou sítě, kde se pravidla vynucují třeba vnitřními směrnicemi, jsou sítě, kde chce majitel sítě vydělávat na tranzitu ať se děje, co se děje. Vinit z problémů IPv6 je dětinské.

[30]

<blockquote>„Ale houbelec. Přečtěte si RFC. Máte tři různé automatické způsoby odvození DUID. Navíc nikdo vám nebrání DUID nebo rovnou IP adresu nastavit na stanici natvrdo.“</bloc­kquote>

Nejde o možnost manuálního nastavení, ta byla a je vždycky. Jde o to, že DHCP(v4) server dostane v požadavku od klienta vždy MAC adresu a někdy také DUID. DHCPv6 server dostane od klienta vždy DUID a _nikdy_ MAC adresu. Takže zatímco DHCPv4 server si může volit, zda použije k identifikaci klienta DUID, nebo MAC adresu, u DHCPv6 je tato volba zrušena.

[31]: jo, to je přesně jak jsem to myslel. Vím, že DUID si můžu nastavit jak chci a také to tak dělám, ale je to hack. Předpokladem pro nasazení nové technologie je maximální zpětná kompatibilita se stávající technologií - proto se IPv6 prosazuje tak pomalu.

[31] V čem je MAC adresa lepší než DUID? Všimněte si, že Media Access Control je z definice záležitost specifická pro lokální médium. DHCP relay skáče radostí. Pokud vám MAC adresa chybí, není nic jednoduššího než napsat návrh na přidání další DHPCv6 option. Nakonec MAC adresu najde DHCP server v hlavičce příchozího rámce (v IPv6 se nemusíte snižovat k Ethernetu, můžete si přečíst zdrojovou IP adresu).

S tvrzením "I když je bezestavová autokonfigurace zabudovaná v protokolu vcelku použitelná..." nesouhlasím. RA je neúplné a tudíž v zásadě samostatně nepoužitelné. Uživatel na síti jen s RA bude asi koukat, proč mu nejde www.seznam.cz.

Postřehy a zejména diskuze je však fajn a jsem za ně rád. Ještě lepší to však bude, když text dáte jazykovému korektorovi (první odstavec o DHCPv6, problémy...se objevilY).

Díky za připomínku opraveno. Korektora nemám k dispozici, ale od toho jsou snad komentáře, ne?