Jak jsem minule slíbil, v dnešním díle seriálu se zaměřím na problematiku IPv6 z pohledu správce sítě. Ani oni to nemají s příchodem IPv6 snadné, zvlášť pokud si chtějí v síti zachovat pořádek.
Na začátek malá exkurze do historie. V době, kdy vznikal protokol IPv4, se rozměry počítačů neudávaly v jednotkách U, ale v počtu sálů. Každý takový počítač měl k dispozici dostatečně erudovaného správce, pro kterého nebyl problém při instalaci nastavit celý systém, včetně IP adresy a směrovací tabulky. Teprve s rozmachem Internetu se objevila potřeba konfigurovat aspoň ty nejnutnější parametry IP protokolu automaticky. Tak vznikly postupně protokoly BOOTP a DHCP, bez kterých si dnes síťování nedovedeme představit.
IPv6 je zařízeno fundamentálně odlišně, už v návrhu bylo počítáno s nutností automatické konfigurace. Ta zde není nadstavbovým protokolem, který by zkonfiguroval původně statické parametry protokolu, ale přímo integrální součástí protokolu. Došlo to tak daleko, že každé síťové rozhraní získá svojí první IPv6 adresu prakticky ihned po aktivaci rozhraní, aniž by síťový kabel vůbec někam vedl. Počítač ji vytvoří slepením prefixu linkové adresy (fe80::/64) a 64-bitového identifikátoru rozhraní.
V obdobném duchu funguje i konfigurace směrování, každý směrovač vysílá do sítě ohlášení, podle kterých stanice nastavují svou směrovací tabulku. Velmi vzdáleně to připomíná například směrovací protokol RIP.
Výše popsaná bezestavová autokonfigurace funguje velice dobře a jednoduše. Její zásadní problém spočívá v tom, že adresy nejsou koncovým zařízením přidělovány (jako např. u DHCPv4), ale jsou vytvořeny spoluprací sítě, která dodá prefix a zařízení, které dodá identifikátor rozhraní. V dřevních dobách IPv6 to zas takový problém nebyl – identifikátor rozhraní byl prakticky vždy odvozen z MAC adresy ethernetového rozhraní.
Pak ale přišli lidé, nazvěme je třeba novotvarem privateroristi, kterým se zdálo, že MAC adresa síťové karty je příliš unikátní číslo, a že by na základě této adresy mohli ostatní uživatelé Internetu sledovat pohyb zařízení mezi různými sítěmi. Bez ohledu na to, že takové sledování je dost dobře možné už dnes (stačí k tomu třeba obyčejné cookie v prohlížeči), byl argument uznán jako oprávněný, a vzniklo RFC 4941, které k pevným idenrifikátorům rozhraní přidává ještě další, náhodně volené, v čase proměnlivé identifikátory. Klientské systémy s MS Windows si v rámci ještě většího soukromí ani pevný identifikátor neodvodí z MAC adresy, ale náhodně zvolí při prvním startu.
I když je bezestavová autokonfigurace zabudovaná v protokolu vcelku použitelná, byl nakonec vyvinut i pro IPv6 protokol DHCP. Vývojáři tehdy měli možnost vybrat mezi drobným rozšířením stávajícího DHCP tak, aby umělo poskytovat i IPv6 adresy a zásadním přepracováním protokolu tak, aby řešil problémy, které se za dobu existence „starého“ DHCP objevily. Vývojáři se vydali druhou cestou, a za sebe říkám bohužel.
Ve starém DHCP byla základním identifikátorem MAC adresa. Na základě té se vyhledal na DHCP serveru záznam v databázi konfigurací a následně byla klientovi nabídnuta odpovídající adresa, jako i další parametry. Tento systém začal drobně selhávat zejména s rozmachem notebooků, vybavených jak ethernetem, tak i wi-fi adaptérem, každý samozřejmě s jinou MAC adresou. Pro DHCPv4 server takový notebook vypadá jako dva zcela nezávislé počítače, nemá možnost zjistit, že jde ve skutečnosti o jeden systém. DHCPv6 tento drobný problém řeší. Bohužel, řešení je tak svérázné, že zároveň způsobuje několik mnohem fatálnějších problémů.
DHCPv6 se rozhodlo jít cestou zavedení nových identifikátorů. Každý počítač dostane jedinečný identifikátor DUID, každé síťové rozhraní daného počítače IAID. Nápad to není špatný. Praktická realizace ale jednoznačně špatná je. Všechny současné PC systémy implementující DHCPv6 používají DUID typu 1, což je identifikátor odvozený z MAC adresy jedné (náhodně volené) síťové karty a časového razítka prvního startu operačního systému. Tento identifikátor je uložen na pevném disku, z principu jej není možné predikovat.
Sečteno a podtrženo, takové řešení přináší tyto nové problémy:
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. Napadne ho, že by snad mohl existovat DHCPv6 server „v kompatibilním režimu“, který by na celý koncept s DUID a IAID kašlal a identifikoval klienta hezky postaru podle MAC adresy. Jenže neexistuje. A co víc, tvůrci protokolu DHCPv6 takovému přístupu aktivně brání, například tím, že z DHCPv6 zprávy odstranili informační pole s MAC adresou klienta. Případný „kompatibilní server“ by se tedy musel uchýlit ke sniffování MAC adresy, ze které požadavek přišel. Jenže tohle může fungovat jen tam, kde se nepoužívají DHCP relay agenti. Pro další studium si dovoluji odkázat na vlákno „Pre-determining DUID“ v archivu mailing listu DHC WG, zejména příspěvek Teda Lemona, jednoho z tvůrců protokolu, který právě existenci zmíněného „kompatibilního serveru“ rezolutně odmítl.
V knize o IPv6 situaci kolem autokonfigurace Pavel Satrapa glosuje humorem sobě vlastním:
Chaos v síti. Divocí uživatelé zapojující bez jakékoli kontroly a evidence nejrůznější aparáty. Jak v takové situaci řešit problémy, které způsobí? Jak odpovídat na dopisy „Tehdy a tehdy byl na počítači s adresou X z Vaší sítě nabízen P2P službou Y film „Zachraňte vojína Ryana“. Zbylo nám tu z natáčení pár tanků, tak s tím koukejte rychle něco udělat, nebo s nimi přijedeme!“
Skutečně současný stav autokonfigurace nahrává spíše nepořádníkům. Lidem, kteří chtějí mít v síti pořádek, zbývají v podstatě dvě cesty – buď zablokovat na nejbližším routeru všechny adresy kromě adres odvozených z MAC adres (a že se to dělá, dokazuje i existence modulu eui64 pro ip6tables), nebo nasadit sledovací software, který bude sledovat jaké IPv6 adresy který počítač právě používá. Oba přístupy ale tak říkajíc kulhají na obě nohy…
V tomto místě ukončuji druhý díl seriálu. Na třetí a snad i poslední díl zbývají témata, která s autokonfigurací celkem dost souvisí:
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).
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ý.
[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/zariadeni 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 autentifikacie/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.
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í.
[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.
[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é.
[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.“</blockquote>
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] 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).
Co o sobě napsat? Absolvent ČVUT FEL, linuxák, síťař. Mimo to se zajímám o elektrotechniku, elektroniku a speciálně elektrické pohony.
Přečteno 56 722×
Přečteno 15 752×
Přečteno 15 744×
Přečteno 14 960×
Přečteno 12 973×