Názory k článku InstallFest 2014: IPv6 na Strahově, bezpečná VLAN a provoz DNS
-
Ondřej CaletkaZlatý podporovatelNení to o nic méně bezpečné než řešení IPv4, kde každý uživatel na síti vystupuje svou jedinečnou veřejnou adresou. Navíc neanonymita obecně kultivuje prostředí. To se týká nejen internetových diskuzí. ale i IP adres :)
-
j (neregistrovaný)
Potom ale jaksi nema smyslu mluvit o bezpecnosti. Nemluve o tom, ze podvrhnout MAC umel na SH kazdej druhej uz kdysi davno, kdy jeste vetsina site byla na koaxu ... takze pripojit se s cimkoli kamkoli je jen otazka stazeni prislusny db/zaposlouchani se na siti => o bezpecnosti nemuze byt ani slova.
Takhle "zabezpecena" sit neni zajistena ani proti neautorizovanym pristupum, ani nepokytuje absolutne zadnou bezpecnost svym uzivatelum.
-
Ondřej CaletkaZlatý podporovatel
Na rozdíl od koaxu tady musíš kromě MAC adresy podvrhnout také správnou zásuvku na switchi. To celý spoofing poměrně zásadním způsobem komplikuje.
-
j (neregistrovaný)
Nikolivek, jen potrebuju znat MAC stroje na te zasuvce, coz se da zjistit velmi snadno - casto se staci proste podivat a precist si to. Nepotrebuju na to ani zadne odposlouchavani provozu.
Navic je podobny "system" na poradny ...houno, protoze pokud se mi rekneme i jen 10% lidi prestehuje, tak mi bude stat kazdorocne fronta na presun na jinej port ... o tom ze si spolubydlici pak musej pamatovat "tohle je moje dira" ani nemluve.
Ostatne prave proto existuje 802.1x, aby se podobny hovadiny nemusely resit.
Mezi nama v dobach kdy se sit na Shcku budovala davalo jeji pripojeni na cesnet smysl ... ovsem uz hezkych par patku si myslim, ze by studaci udelali mnohem lip, kdyby se proste slozili na komercni linku (coz by dali zcela vpohode) a nemuseli resit vsemozna uzasna omezeni.
-
Ondřej CaletkaZlatý podporovatel
Jenomže, když ten stroj na té zásuvce je, těžko tam připojíš další. Když ten zdroj na té zásuvce není, těžko zjistíš jeho MAC adresu (musíš ji znát z dřívějška). Tedy ano, můžeš třeba ukrást připojení spolubydlícímu v době, kdy tam není, ale to je asi tak všechno.
802.1x sice řeší problémy s evidencí zásuvek, na druhou stranu ale zase naprosté většině studentů musíš počítač osobně ručně nastavit, protože nejsou schopni to dát dohromady ani podle obrázkových návodů.
-
j (neregistrovaný)
Kdyz je stroj na te zasuvce ... tak si tam kupodivu pripojim switch. Navic tak nejak predpokladam, ze v roce 2014 neni zarizeni komunikujici po siti zas takova rarita, jako tomu bylo v roce 1994 ... takze takovy student muze mit trebas na koleji desktop a do skoly si nosit nejaky notes + ma nejaky telefon ... a registrovat tisice ruznych zarizeni dle MAC je proste naprosto padly na hlavu.
Pokud nekdo neni schopen trivialniho nastaveni dle navodu ... tak holt nemuze pouzivat tu sit.
Prijde mi to asi tak stejne mimonsky jako kdyz tu onehda byl clanek o stovkach APcek v technicky knihovne ... coz me zarazilo mimo jine proto, ze bych predpokladal alespon elementarni znalost fyziky ... procez by muselo byt vsem zucastnenym naprosto jasny, ze takhle to proste nikdy chodit nebude.
Tak nejak bych proste od vysokoskolsky site ocekaval, ze pouziva technologie tam, kde je misto jejich urceni, ale tohle naprosto presne odpovida tomu, co z VS ve finale vyleze - z 90% zcela nepouzitelny mimon.
-
z koleje matfyzu (neregistrovaný)
Obvykle se v sítích tohoto typu nedá použít 802.1x proto že to nepodporují všechny switche. Konkurenční kolej MFF UK v Tróji 802.1x používá už dlouho (asi mají novější switche). Jde ovšem o zabezpečení na úplně jiné úrovni - na Strahově se rozhodli že stačí důvěřovat MAC adrese, takže když někdo zjistí mou MAC adresu tak si jí nastaví na svém počítači a může se klidně do mé zasuvky na Strahově připojit. V Tróji by mi ovšem ještě k tomu musel ukrást privátní klíč uložený na mém disku.
-
Ondřej CaletkaZlatý podporovatel
802.1x řeší pouze L2 vrstvu, tedy kdo kdy otevřel daný port (a jakou MAC adresou). Nijak ale neřeší vazbu „které identitě patřila v dané době daná IP adresa“. K tomu jsou možnosti dvojí:
- zaznamenávat z routerů vazby IP adresa <−> MAC adresa a pouze v případě problému tyto záznamy spojit s logem RADIUS serverů, popřípadě v případě Strahova s databází MAC adres uživatelů
- nasadit systém, který vynutí k dané MAC adrese konkrétní IP adresu a zároveň zabrání použití jakékoli jiné IP adresy
Většina eduroamů běží v režimu podle prvního bodu, na Strahově se ale rozhodli jít pro řešení ad 2. Zatímco pro IPv4 je takové vynucování vcelku jednoduché a podporované, v případě IPv6 jde vesměs o nepodporované nedodělané funkce se spoustou nežádoucích vedlejších efektů, nemluvě o tom, že tvůrci IPv6 vazbám čehokoli na MAC adresy poměrně intenzivně brání (viz v článku popsaná nutnost svést všechny VLANy na jeden stroj a použít speciální DHCPv6 server).
-
Anonym, nejsem odbornik, snazim se zde vzdelat (neregistrovaný)
Zdravim, rekl bych, ze 802.1x jako zabezpeceni je daleko lepsi, ale switch by mel umet take DHCP Snooping, Port Security, coz cisco umi. Potom by mel resit vyse zmineny problem. Ale nevim jak je to s IPv6, pokud to pisu spatne, tak se rad poucim. Diky za reakce
-
TP (neregistrovaný)
802.1x prilis neresi problem, protoze 802.1x nic nerika o vztahu mezi pripojnym mistem a IPv6 adresou. Z radius serveru je mozne zniskat maximalne MAC adresu, ale bez dalsich doplnujicich informaci (napr. nd cache ze smerovacu) z takove MAC adresy nejsem schopen ziskat IPv6 adresu (a obracene).
V IPv4 je to o neco snazsi, protoze kdyz si na siti vynutim pouziti DHCP, tak prislusnou vazbu mezi MAC-IP pak najdu v logu dhcp serveru. To opet v DHCPv6 moc dobre nejde protoze mi schazi ta MAC adresa (pokud tedy nepouziju reseni podobne jak na strahove, kde si ty MAC adresy logovat muzu).
-
Ondřej CaletkaZlatý podporovatel
Přesně tak, PowerDNS recursor DNSSEC validaci nepodporuje, PowerDNS autoritativní server podepisuje on-the-fly.
-
Alice (neregistrovaný)
"Druhou variantou je DHCPv6, který sice funguje podobně jako DHCPv4, ale v dotazu na server neputuje klientova MAC adresa. Není proto možné přidělovat IP adresu na základě MAC adresy. Druhým problémem je, že DHCP nepřiděluje výchozí routu.
... Konkrétně bylo použito řešení zvané dhcpy6d, což je implementace DHCPv6 napsaná v Pythonu."Hmmm, trik je to hezký, ale od těch dob, co
+ bylo zavedeno DUID-LL
+ je implementováno v ISC DHCPD serveru 4.2, který dokonce umí použít LLT jako LL*)
+ Windows 7 umí DUID-LLT,
popsané elegantní řešení asi časem ztratí ten svůj půvab.http://tools.ietf.org/html/rfc3315#page-22
*) "The 'hardware [ethernet|etc] ...;' parameter in host records has been extended to attempt to match DHCPv6 clients by the last octets of a DUID-LL or DUID-LLT provided by the client."
-
Ondřej CaletkaZlatý podporovatel
+ bylo zavedeno DUID-LL
…ale téměř žádné zařízení ho nepoužívá+ je implementováno v ISC DHCPD serveru 4.2, který dokonce umí použít LLT jako LL*)
…Tedy jinými slovy ISC DHCPD server 4.2 (kteří mnozí berou jako referenční implementaci) porušuje RFC 3315: „Clients and servers MUST treat DUIDs as opaque values and MUST only compare DUIDs for equality. Clients and servers MUST NOT in any other way interpret DUIDs.“Nehledě na to, že není vůbec jisté, že MAC adresa obsažená v DUID-LLT bude zrovna ta MAC adresa, kterou zařízení komunikuje v dané síti.
-
A zase ta Alice (neregistrovaný)
Rozumím-li správně, Vás prostě štve, že si lidé z ISC pro "samozřejmě zcela bezvýznamovou hodnotu" půjčili shodou okolností zcela zavádějící označení "hardware ethernet" a že Microsoft Windows úplnou náhodou prezentují zásadně tento údaj a odvozují ho shodou okolností z MAC adresy karty, která je do příslušné sítě zapojená (a v těch Sedmičkách naštěstí není, navzteka například RFC6724, ani potřeba vypínat anonymizaci/volbu dočasných rozhraní palbou příkazů "netsh interface ipv6 set privacy state=disabled" a "netsh interface ipv6 set global randomizeidentifiers=disabled" jako dřív). ...ale přiznám se, že nevím, jak Osmičky.
Patrně zde dochází k nějakému hlubokému nedorozumění. V každém případě laskavým čtenářům doporučuji, aby si s Wiresharkem v ruce někde půjčili počítač s Windowsy (jako jsem to teď kvůli panu Caletkovi udělala já, abych se neblamovala), ověřili, co lze, co nelze, poskládali si ve správném pořadí moje výroky (jejichž vztažnost byla poněkud rozbita - o užitečnosti DUID-LL jako takového jsem nikde nepsala, pouze o tom, že je to "prerekvizita" pro LLT) a udělali si sami úsudek o výrocích, které zde padly.
Jinak z toho bude nudný a nesmyslný flamewar.
-
Ondřej CaletkaZlatý podporovatel
a že Microsoft Windows úplnou náhodou prezentují zásadně tento údaj a odvozují ho shodou okolností z MAC adresy karty, která je do příslušné sítě zapojená…
Opravdu? To je dost závažné tvrzení a dovoluji si o něm pochybovat. Kdyby to tak skutečně bylo, znamenalo by to, že takový notebook, který má drátovou síťovou kartu a Wi-Fi se na každé z těchto karet prezentuje jiným DUID, takže DUID ztratí funkci jednotného identifikátoru stanice. Netvrdím, že to tak určitě není (Windows moc neznám), ale rozhodně by to pro mně byl velký šok, kdyby se to takhle chovalo (mnohem větší než to, že dhcpd interpretuje DUID i když se to nesmí).
Stejně tak by mě zajímalo, co se stane, když do počítače připojím novou síťovou kartu, jestli si Windows opravdu vygenerují další DUID.
Jinak co mě štve je, když se software, který se má chovat podle nějakého standardu, začne chovat v přímém rozporu s tímto standardem a ještě se to prezentuje jako cool new feature. To se můžeme na nějaké standardy vykašlat rovnou a každý ať si píše software, jak sám uzná za vhodné…
-
BobTheBuilderStříbrný podporovatelAno, a dokonce to je ještě horší: sice se po restartu vygeneruje nové DUID, ale v něm zůstane původní MAC adresa. Zatím jsem nepřišel na to, jak tam vnutit MAC adresu skutečně přítomné síťové karty (ani v tom ideálním případě, že je jen jedna jediná).
Asi lze editovat výše zmíněnou položku registry, ale je to navíc binární hodnota, takže to je poněkud problematické. -
JiriHorky (neregistrovaný)
Ahoj Ondro, se zajmem jsem si precetl vycuc z tve prednasky. Zaujala mne informace ohledne minimalni cache DNS dotazu v Linuxu - mel jsem dojem, ze v libc zadna cache dotazu neni a tudiz skutecne kazdy dotaz se pta znovu.
Za dalsi, tusis proc vyvojari libc nechcou snizit hodnotu timeoutu/retry na DNS servery? Zvykl jsem si na serverech i uz i na ntb provozovat volbu "options timeout:1 attempts:1 rotate" v /etc/resolv.conf, coz situaci dost vyrazne zlepsuje. Jen pozor na pomale pripojeni v hotelech :) Napada te s tim nejaky problem?
Jinak dalsi past je, ze libc bere jen max. 3 zaznamy z /etc/resolv.conf, tj. psat tam cokoliv navic je k nicemu :) -
Ondřej CaletkaZlatý podporovatel
Ahoj Ondro, se zajmem jsem si precetl vycuc z tve prednasky. Zaujala mne informace ohledne minimalni cache DNS dotazu v Linuxu - mel jsem dojem, ze v libc zadna cache dotazu neni a tudiz skutecne kazdy dotaz se pta znovu.
Ano, taky si myslím, že v glibc žádná cache není. Ale kód jsem nezkoumal.
Za dalsi, tusis proc vyvojari libc nechcou snizit hodnotu timeoutu/retry na DNS servery? Zvykl jsem si na serverech i uz i na ntb provozovat volbu "options timeout:1 attempts:1 rotate" v /etc/resolv.conf, coz situaci dost vyrazne zlepsuje. Jen pozor na pomale pripojeni v hotelech :) Napada te s tim nejaky problem?
Problém je, že jedna sekunda je hooodně krátký timeout. Rekurzivní dotaz na doménu hostovanou v zahraničí, delegovanou přes 3 úrovně (což je třeba pro reverzní adresy poměrně běžné) a s několika nefunkčními autoritativními servery zabere klidně 3-4 sekundy, při DNSSEC validaci ještě o něco víc. Takže se sice systém přestane zasekávat při výpadku DNS serveru, ale zároveň vzroste počet neresolvnutých adres, na což většina aplikací reaguje tak, že skončí na fatalní chybu. Někde to může vadit míň než zablokování celého systému, ale asi se nedá obecně říct, že by to bylo lepší
Jinak dalsi past je, ze libc bere jen max. 3 zaznamy z /etc/resolv.conf, tj. psat tam cokoliv navic je k nicemu :)
Ano, přesně tak.
ČLÁNKY DO MAILU