switche bez DHCP snoopingu už nekupuji. Sice to nepoužívám v té nejsložitější variantě (tedy s ARP inspection) ale jenom pro blokaci nechtěných DHCP serverů. User X má pravdu - v nějaké firemní síti (nějaké běžné, střední) mám velkou kontrolu nad tím, co tam zapojím. Ale v metropolitní síti už ne (trochu nadnesený název třeba pro panelák o deseti vchodech). Stačí jeden trouba s ADSL routerem z bazaru a má problém desítky lidí jenom proto, že to používá jako switch a DHCP tam nejde vypnout ...
A používám i IP source guard (což lze použít i pro blokování DHCP). Nemám rád, když někdo používá IP která není jeho ... Nasazení nějaké pokročilejší kontroly přístupu (802.1x apod.) zatím totiž bohužel nepřipadá v úvahu.
To mi chybí pro IPv6. Kde je k tomu potřeba ještě RA guard. Takových switchů bohužel moc nexistuje.
Ano, pouzivam. DHCP snooping je v siti, kde se pripojuji uzivatele nad jejichz PC nemate kontrolu, naprosta nutnost. Nastesti rada zarizeni to uz dnes umi za relativne prijatelne ceny.
Motani DNS hijacking s tim uzce souvisi. Jednou z technik nasackovani do klientu falesneho DNS serveru je prave zneuziti DHCP. Zamorene PC si odposlechne odpoved DHCP serveru a vymeni v ni adresy DNS serveru (samozrejme pod utocnikovou kontrolou). To prosim neni nejaky hypoteticky problem. Toto se na siti bezne deje! Viz DNSChsanger - http://isc.sans.edu/diary.html?storyid=5434
Jestli ti staci firma s +-150 desktopy a +- 20ti servery, kde je provozovano IPv4/IPv6 spolecne, tak jednu takovou mam jako zakaznika. Uzivatelum je to celkem jedno a me celkem tesi ze to funguje a predevsim ze se muzu zvenku pripojit na cokoli, aniz bych musel pro kazdej stroj nastavovat forward.
To, co popisujete je klasický DHCP snooping, ale už bez navazujících technologií jako je IP source guard. Tímto zabráníte maximálně tak výskytu falešných DHCP serverů v síti. Mně šlo spíš o ten source guard, případně ARP inspection.
No a DHCP odpovědi jdou standardně unicastem, takže "odposlechnout odpověď DHCP serveru" dost dobře nejde, pokud k tomu nepoužijeme ještě nějakou další fintu.
Je otázka, jak to myslel. Některé DHCP krámy dělají to, že je broadcast adresa je v IP záhlaví (což musí být), ale v Ethernetu je už unicast na danou stanici a ne broadcast.
Jinak neplatí ani to o té obnově. Je pár DHCP serverů, které odpovídají vždy broadcastem, a to i při obnově adresy (např v ROSu je to i konfigurovatlené jak to má dělat).
Nutno podoktnout, že tyto optimalizace mají občas nehezké vedlejěší dopady. Pokud třeba klient má wokna s ESETetem, v něm zapnutou kontolu ARP, tak občas toto vede k tomu, že nedostane IP adresu, ale přitom úspěšně vyčerpá celý dynamický pool na DHCP serveru opakovanými dotazy. :-)
Ty odpovedi se unicastem dorucuji velice spatne, kdyz zarizeni jeste zadnou adresu nema, takze prvnidotaz/odpoved jde pochopitelne broadcastem. Obnovovani adresy se uz pak deje naprimo mezi klientem a serverem. Rozumny zpusob zasazeni do tohoto procesu je v dobe prvni vymeny (napr. po zapnuti PC).
Mimochodem to je zase neco co se zrejme nekomu v ramci IPv6 jevilo jako vhodne ke zmeneni a DHCPv6 se vzdy dotazuje pres multicastovou skupinu - komunikace naprimo tam uz neni. Takze opet o neco bohatsi moznosti pro utocnika.
Jen by me zajimalo jestli na tech zasedani IETF se na vymysleni tech "vylepseni" stridaji a nebo je to dilo nejakolika jedincu. A teda u autokonfigurace se vyradili o 106. Skoda je ze pak stoji extremne hodne usili ostatni lidi aby se to z tech standardu dostalo pryc.
Podle me to je ponekud umely priklad. Pokud bych mel zprovoznovat IPv6 presne kvuli tomu tak si najdu radeji jiny zpusob jak vec vyresit. V IPv4 si zprovoznim VPN (coz mi dneska umoznuje prakticky kdejaka krabice, ktera soucasne resi firewall pro firemni sit). V pripade IPv6 zadnu resit pridelovani adres, tedy zprovozneni DHCPv6, evidenci DUIDu (protoze o databazi adres z IPv4 se oprit nemuzu) a vytvareni der do firewallu. Nejak v tom nevidim ten benefit. Navic vsechny WinXP jsou timto mimo hru (leda ze bych do nich naklapal adresu rukama). Takze IPv6 v tomto smeru bude mozna prinosem, ale tak za 10 let.
Jasne rada siti toto nepouziva, protoze to zkratka neni potreba. Nicmene kdyz vec nekdo potrebuje, tak v IPv4 ma tu moznost za relativne dostupne penize. V IPv6 jsou tyhle veci zatim dost chabe. V tom je ten problem, protoze kdyz chci koupit switch dneska a pozaduju tyto funcionality tak na vyber moc nemam anebo si musim priplatit.
Takze kdyz to vezmu ryze z ekonomickeho hlediska je pro me lepsi koupit switch, ktery ma tyhle feature pro IPv4 a protokol IPv6 odfiltrovat jako celek - coz rada operatoru dela.
Existuje v ČR firma o velikosti řekněmě 700-1000 PC, s dvěma desítkami svých serverů pro interní potřeby, možností práce na VPN z domova, vlastním mail serverem, vlastním nameserverem která UŽ jede kompletně na IPv6? Pořád se tu bavíme o SOHO nebo backbone, ale "zatím" si nedokáži (a nejsem rozhodně sám) představit "implementaci" IPv6 do nějakého takového podniku...rozhodně ne v téhle chvíli. Jen vysvětlování svému nadřízenému, že potřebujeme x novývh boxů za desítky nebo stovky tisíc, když to vlastně teď vše šlape tak jak má... Počítá se vůbec s přechodem stávajícíh IPv4 sítí na IPv6?
To je porad dokola. Kdyz nekdo rekne, ze DHCP snooping a odvozene bezpecnostni prvky jsou dulezite, tak se vzdy najde nekdo kdo tvrdi ze se to vlastne nikde nepouziva. Budete se divit, ale pouziva. Je rozdil mit firemni sit, kde je nad vsim jakz takz kontrola a pripojovat sit rekneme v panelaku. Pokud tam tyto ochrany nemate, tak staci jedno zamorene PC, ktere vam ovlivni chovani vsech ostatnich (= platicich zakazniku). Uz vubec neresime spoofovani adres a ruzne ARP (ND) utoky.
Tyhle ochrany jsou v rade siti dneska nutnost uz jen proto, ze DNS Hijack vyuzivaji lecktere viry/trojany (coz pred 10 lety napriklad nebylo). Problem je ze na IPv6 tyhle veci zatim poradne nefunguji a tak je v takove siti pak lepsi odfiltrovat IPv6 jako celek a je klid (coz zvladne dneska switch byt jen se zakladni filtraci).
Naprosty souhlas vcetne tech problemu, ktere popisujete. Mnozi vyrobci skutecne maji problem uvedene veci odladit uz treba jen proto, ze tech stavu a kombinaci, ktere v siti muzou nastat neni zrovna malo.
A presne proto je to v IPv6 pro jistotu 2x abychom se pri sprave siti prilis nenudili. Takze krome dohadovani se vyrobci ze nefunguje dobre ochrana na bazi DHCPv6, tak si k tomu jeste prihodime ochrany na bazi SLAAC (RA a spol.) a samozrejme kombinace uvedeneho. Aby to bylo jeste veselejsi tak SLAAC i DHCPv6 pouziva zcela jiny protokol a jinou logiku pristupu k problemu.
Ano, provozuji. A to jak ve firmách, tak i u ISP. Nejen DHPC snooping, ale IP guard, ARP inspekce, IGMP/multicast snooping, ve firmách i 802.1x, v roli ISP je místy jen ověření MAC proti Radiusu, dynamciké VLANy atd.
Někdy je oddělení (panelák) řešeno tak, že switch je nastavne pro izolaci jednotlivých portů a komunikace mezi sousedy musí jít přes L3 prvek před ním, což také řeší řadu nepříjemností atd.
Switche různé - Cisco, HP Procurve, 3Com/H3C, Allied Telesis, . Nutno poznamenat, že souhlasím, že to není jendoduché, protože v řadě z nich jsou chyby a složka emailů diskusí s tech supporty je hodně tlustá. Zvláště fáze, než se člověk probije přes vrstvu neschopných tech supportů a managerů až k vývojáři v Indii/Číně a vysvětlí si o co jde a doufá, že to pak snad trošku vylepší.... Protože dost často vše nefunguje jak má nebo kombinace některých věcí spolu (a v tom mají máslo na hlavě tak všichni výše zmínění výrobci, každý má nějaké ale, dost často i závislé na produktové řadě), a to je teprve IPv4 svět. V IPv6 toto bude dlouho ještě horší.
žádné DHCP krámy. Doručování odpovědí L2 unicastem je standardní chování. V případě, že klient není schopen přijímat L2 unicast pakety, pokud nemá ještě nastavenou IP adresu, tak v tom případě je v DHCP paketu nastaven flag B, který říká, že DHCP server má vracet odpověď broadcastem.
Takže pokud se Wokna s Esetem chovají tak jak se chovají, tak se chovají špatně. Viz RFC 2131, strana 10.
Ostatně počet DHCP requestů za jednotku času se dá na portu switche omezit (na některých switchích).