Vlákno názorů k článku IPv6 Mýty a skutečnost, díl I. - Jak jsme na tom od AB - Díky za tento "pilotní" díl seriálu. Konečně se...

tak pokud chcete provozovat takový provoz přes standardní internet bez VPN, tak jste směšný.

To byl jen priklad, zadnou takovou linku nemam a bez VPN je to pitomost.
Nicmene nenni to odpoved na problem, kterym je unik informaci pres postrani kanal predstavovany IP adresou. Argumet ze totez zjisti utocnik inspekci paketu neberu, mluvim o dokonale nastavenem firewalu a sifrovani. Bez NAT to nejde

tak vy žádnou linku nemáte a příklad jste si vycucal z prstu. Jestli máte problémy s postranním kanálem, tak prostě šifrujte tunel. Tam se vám vnitřní adresy neobjeví.

A to si myslíte, že Vás NAT před únikem informací postranním kanálem ochrání? Těžko. V IP sítích je každé spojení definované zdrojovou IP a portem a cílovou IP a portem. NATem schováte pouze polovinu identifikace.

Pokud jste opravdu dostatečně paranoidní, tak se poinformujte u lidí, kteří danému tématu rozumí (armáda, ...). Tam se rovněž používá šifrovaná komunikace a proti přesně takovému útoku, jaký popisujete existuje naprosto jednoduché řešení. V době informačního klidu se kanálem prostě posílá nějaký balast, aby to vypadalo, že se komunikuje.

A pokud ani to nebude dostačující, tak můžete měnit IP adresy těch svých zařízení. Nebo třeba použít proxy server.

Než začnete NAT prohlašovat za bezpečnostní zařízení, zkuste si někde vyhledat vysvětlení pojmů jako DNAT, SNAT, PNAT, symetrický NAT. Možná budete zděšen.

"NATem schováte pouze polovinu identifikace." - to je pravda ale take je pravda ze prave tuhle polovinu nedokazu bez NAT skryt. NAT nestaci, ale bez nej to nekdy nejde (ne vsude je mozne pouzit proxy)

PS: veci kolem IPv4 znam uz skoro 20 let (NAT od jeho zacatku)

To, že schováte IP adresu, vůbec neznamená, že znemožníte identifikaci. Pořád ještě máte spoustu dalších možností – časování, způsoby generování sekvenčního čísla, rozšiřování okna, reakce na chyby…

Tohle pomuze k identifikaci OS, ne konkretniho pocitace, to uz je lepsi resit velikost paketu, skusit podstrcit navnadu napriklad zamernym spustenim napriklad alarmu, atd. Moznosti je spousta. Ale proc to utocnikovy usnadnovat a dobrovolne odhalit vnitrni strukturu site? Proc si domu davate zamek, kdyz to zlodej stejne prekona? Kazdy zpusob jak omezit postranni kanal je dobry, i kdyz neni 100% spolehlivy, zvysuje pro utocnika cenu utoku.

Já teda bezpečnost domu řeším tak, že si pořídím na dveře zámek, ne tak, že bych zazdil okna, aby náhodou někdo nezjistil, že máme doma obývák.

No jo, ale u siti je to trosku jinak ne?

A jak v NATu řešíte případ, kdy se potřebujete zvenčí připojit na to zařízení schované za NATem?

Zalezi na tom o jakou sit jde, pokud jsou tam nejaka alespon trochu citliva data tak jedine VPN. Nebo je to pocitac primo urceny pro poskytovani sluzeb ven a je v DMZ bus s verejnou IP nebo DNAT.
V kazdem pripade to IPv6 neresi, protoze pro vsechna nevyjmenovana spojeni z venku smerem dovnit konci na firewall pravidle DROP.
PS: NAT u poskytovatelu = problem pro zakaznika. Tam je to jasne, jde o uzavrene site.

A jsme zpět na začátku.
Tímto nastavením se ale okamžitě vracíme do stavu bez NATu, kde jsou všechny čtyři parametry spojení jednoznačně identifikované.
Ostatně jaký je rozdí, když ta super citlivá komunikace pochází z nějakého serveru uvnitř sítě a nebo z NAT serveru?

Ano, i v IPv6 síti můžete server umístit do DMZ. A jak sám píšete, filtraci paketů provádí Firewall.

Je NAT bezpečnostní prvek? Není.
Například tady http://msmvps.com/blogs/alunj/archive/2007/12/29/1425918.aspx se dozvíte, že NAT nebyl vůbec zamýšlen jako bezpečnostní prvek sítě. Ale to ostatně jistě víte při Vašich dlouholetých zkušenostech. Dále se také dozvíte, že v některých případech NAT naopak bezpečnosti háže klacky pod nohy, viz. IPSec. A takto bychom mohli pokračovat dál.

Pokud se budu držet Vašeho příkladu s alarmem, tak se pokusím pro porovnání nastínit možný průběh útoku v IPv4 s NATem a v IPv6.
Předpokládejme, že útočník má k dispozici botnet, kterým může provést DDOS útok na Vaši síť, ale o její vnitřní struktuře neví nic. Pošle Vám tedy takový e-mail, na který odpovíte. Tím získal IP adresu Vašeho NATu a navíc pravděpodobně i vnitřní IP adresu vašeho PC. to pro začátek není špatné. Už zná částečně strukturu vnitřní sítě. Tedy za předpokladu, že není příliš obskurně nakonfigurována. I když tu vůbec nepotřebuje. Spustí DDOS útok na IP toho NATu a už se o alarm nemusí starart, protože ví, že alarm, který komunikuje přes ten NAT si prostě nezakomunikuje.
A jak to bude v případě IPv6? Bohužel úplně stejné. Protože tím DDOS útokem vám nejspíš zahltí linku, takže je jedno jestli zná, nebo nezná vnitřní strukturu sítě. Ale vy se nemusíte zabývat nějakým obskurním překladem adres.

Prostě se smiřte s tím, že v IPv6 NAT nebude, protože nepřináší žádnou přidanou hodnotu. Mimochodem, v lednu bylo zveřejněno RFC zabývající se defaultním nastavením síťových prvků určených pro domácí uživatele s ohledem na bezpečnost vnitřní sítě. Pokud se tím budou výrobci řídit, tak to bude by default, jako kdyby uživatelé byli za NATem. Tj. ven povoleno vše, dovnitř pouze navázaná spojení.
http://tools.ietf.org/html/rfc6092

s tim alarmem jsem to myslel jinak. Jde o vnejsi zasah do systemu ktery vyprovokuje nejakou akci. Spojenci takto napriklad za WW2 pokladaly miny na domluvene souradnice aby odposlouchavaly nemecke hlaseni a ze znalosti souradnic zjistiti denni sifrovaci klic.

Asi vetsina lidi tu vi, ze NAT neni o tom "vse ven, dovnitr nic". Tady jde o skryti ktere zarizeni komunukuje ven, prestoze vim, ze pri surfovani toho browser vykeca podstatne vic. Napriklad muze byt zajimave kdy si vas telefon aktualizuje informace o predpovedi pocasi u vas doma.

Konecnym cilem utocnika neni vas pocitac, ale penize. Bud vase, muzu vas vykrast, nebo napriklad zjistit co chysta konkurence na pristi rok.

Jen pro zajímavost. Enigma je stroj pro kódování, nikoliv pro šifrování. Dnešní šifrovací algoritmy nejsou náchylné na "plaintext attack".

NAT ale stejně tak není o skrývání identity komunikující entity. Byl vymyšlen pouze pro potřeby omezení spotřeby veřejných IP adres a pro snazší připojení sítí, které do té doby do globální sítě nebyly připojeny. Prostě byla síť postavená na privátních adresách a přes NAT ji bylo možné okamžitě připojit do internetu bez nutnosti readresace. Na to samozřejmě při návrhu IPv6 bylo myšleno také.

Proč se příslušné RFC o bezpečnosti zmiňuje až kdesi na konci?:
6. Security Considerations
Security issues are not addressed in this memo.

viz. http://tools.ietf.org/html/rfc1918
Nejspíš proto, že se o bezpečnosti při návrhu NATu vůbec nemluvilo.

Ale všechny ty informace co píšete mají téměř stejnou hodnotu, bez ohledu na to, zda jste, nebo nejste za NATem. Speciálně v případě, že za NATem budete mít malou domácí síťku. Naopak, budu mít práci usnadněnu, protože mi stačí filtrovat pouze IP vašeho NATu.

IPv4 asi moc neznate, jinak byste vedel, ze neni problem tunelovat IP v IP. Takze byste tech vasich 200 pocitacu schoval za jeden router. Pak by vas taky mozna napadlo, ze vse krome vnejsi IP hlavicky jde sifrovat, takze byste elegantne skryl celou vasi vnitrni sit.

Kdybyste pak znal i IPv6, tak byste vedel, ze ten protokol je narozdil od IPv4 navrzen tak, aby to vyse uvedene umel bez proprietarnich obezlicek.

pokud máte totiž někde výrobní linku posílající nějaká data na server, tak vám NAT stejně nepomůže, pokud ten útočník vidí provoz, tak vidí i dovnitř paketů a pak už si velmi lehce odvodí, co je výrobní linka a co je zaměstnanec bloudící po pornostránkách.

A zase ... placate nesmysly, takovyho sitare ktery ma takto zasadni neznalosti bych na minutu vyhodil.

a) NAT neskryje vubec nic, tech postranich kanalu mate tisice - napr kazdy prohlizec s povolenym scriptovanim (90%) na sebe praskne vnitrni IP a spoustu dalsich informaci.

NAT je nastroj, jak pripojit do netu vice zarizeni, kdyz mam nedostatek IP adres. NIC VIC.

b) adresy se mohou v ramci vaseho prefixu prakticky libovolne casto menit, takze zvenku pozna dotycny kulovy jestli to, co prave nekam komunikuje je to, co kumunikovali pred minutou.

d) pokud chci provozovat utajeny provoz kamsi, tak se na to pouzije sifrovany tunel.

e) na siti kterou spravuju nepotrebuju aby zarizeni melo nejakou konkretni IP, existuje hromada jinych zpusobu jak zarizeni identifikovat.

=> snazite se jen vymyslet naprosto debilni a v praxi neexistujici duvod, proc pouzivat NAT.

NAT ten postranní kanál nijak neskryje. Skryje konkrétní IP adresy, ale to je mezi těmi informacemi prkotina.

Jediný rozdíl je v tom, že u firewallu ten postranní kanál jako správce hned vidíte, ale spousta „správců“ si neuvědomuje, že u NATu existuje ten postranní kanál. Problém je, že si taky spousta lidí myslí, že NAT nahrazuje firewall, takže na správné nastavení firewallu se vykašlou – a přitom je pak možné využitím vlastností NATu navázat i komunikaci, která by měla být filtrovaná, dokonce někdy i zvenku dovnitř.

Ono vše vypadá strašně jednoduše, než se s tím člověk doopravdy potká. Přípklad technologické sítě a požadavků na ni:
- Musí být zajištěn bezproblémový provoz technologie. V některých provozech není odstávka myslitelná. Znovunahození ropné plošiny po výpadku trvá desítky hodin, odstavený reaktor nemůžede obratem opět nahodit a namíchaný roztok krátkodobou použitelností za pár miliónů můžete kvůli výpadku vyhodit....
- Takže budu odkazovat zařízení na sebe přímo IP adresou. Nestojím o to, aby mi výpadek jmenného serveru zrušil provoz. Zařízení tedy potřebují pevné IP. Ty se nesmí "hádat" s okolním světem.
- Technologická síť je opravdu jen a pouze pro technologii, nestojím o to, aby mi do sítě lezly multicasty a broadcasty a cokoli nežádoucího z okolí, co mi může dělat neplechu.
- Do technologické sítě je potřeba přístup zvenčí (Internet, LAN). Málokdy složitější technologii spravuje nějaký zaměstnanec dané firmy ale dost často její dodavatel. Ten nemusí být jen jeden, technologie se může inovovat a doplňovat. Každého dodavatele pustím, ať už SSH nebo VPN jen na zařízení na která se má dostat. Nestojím o to, aby se šťroural kde nemá.
- Kromě servisu je potřeba z firemní LAN zabezpečným spojením tahat data např. z MySQL na technologickém serveru, mít šifrované propojení na velín, který může být v normální síti a spoustu dalších požadavků.

Tak a teď nastavte bezchybně firewall tak, ať se v tom vyzná i někdo jiný než vy, zajistěte individuální adresování technologie s IPv6, zamezte kolizím a garnatujte svému zaměstnavateli, že jste nikde nenechali skulinku. Zajistěte firewall proti DOS (DDOS, obecně Flood) útokům, s tím, že mohou přijít i z vlastní LAN. A to bez NATu. Příjemnou zábavu. Až to vyřešíte dejte vědět, strašně rád se přiučím.

Vy tam někde vidíte něco, co by záviselo na NATu? Já tedy vůbec.

Některé z vašich bodů bude NAT komplikovat, žádný nezjednoduší. Takže když se vyhnete NATu, bude konfigurace celkově jednodušší.

Mám na starosti komunikaci v poměrně velké průmyslové firmě s mnoha oddělenými technologickými sítěmi a taky nechápu, jak s těmito požadavky souvisí NAT ??? Každá síť je jasně definovaná adresním prostorem a mezi nimi jsou samozřejmě firewally a to bez NATu. To platí nyní pro IPv4, tak by to platilo i pro IPv6. NAT by byl dokonce pro definice komunikací na takovéto síti dost velkou překážkou pro přehlednost v pravidlech na firewallech.

NAT s tim souvisi podstatne. "Každá síť je jasně definovaná adresním prostorem a mezi nimi jsou samozřejmě firewally a to bez NATu." To je presne ono, a ted me reknete, potrebujete vytrubovat mapu vnitniho usporadani site do sveta, nebu bede lepsi aby se to tvarilo jako jedna IP?

PS: vim ze NAT neni firewall, ze to neni zabezpeceni site. Ale jak to sakra chcete dokazat bez nej?

Opravdu by mne zajímalo, co tím „nevytrubováním“ získáte.

Totez co zakazem foceni v arealu. Fotka vam take zadnou skodu nedela. Duvody jsou podobne.

Jaké informace o vnitřní síti skrývané pomocí NATu nejdou zjistit snadno jiným způsobem? Stačí do vnitřní sítě přes klíčenku, neaktualizovaný prohlížeč nebo jen zvědavého uživatele klikače dostat trojského koně, a získáte daleko víc informací, než co skryjete NATem. Ty informace skrývané NATem zjistíte i sledováním NATovaného provozu, pohledem do rejstříků a map atd.

Podle podobne logiky nema smysl zamykat, protoze zlodej to stejne prekona.
PS: v pripade web browseru s JS nema NAT vyznam, zjistite toho daleko vic, ale web browser neni internet.

Vaše analogie je díivná. Vy nezamykáte (protože to dělá firewall), vy jen svůj dům zakryjete maskovací plachtou, takže bombardér nevidí, barvu vaší střechy, barvu omítky a zloděj neuvidí číslo vašeho domu na omítce, ale to mu vůbec nezabrání Váš dům vykrást.

Ne, podle mé logiky nemá smysl zazdít okna, aby náhodou někdo nezjistil, že máme doma obývák a kuchyň a koupelnu. A já si opravdu myslím, že to smysl nemá, že daleko lepší ochrana je zamykat.

To ze je to jedno vam, neznamena ze to nema vyznam. Pro mnoho lidi to muze byt duvod proc nebydlet v prizemi. Ale hlavne pro odeleni ve firme kde se pracuje se "strategickym" materialem je to standard.

Význam to opravdu nemá. Protože okna jsou sice zazděná, ale o obýváku a kuchyni stejně víte – protože nějakou jejich formu má v bytě snad každý. V tom je právě ten vtip – NATem skrýváte informace, které se dají snáz a podrobněji získat jinak.

Tohle je pravda pouze vetsinou, ne vzdy.

To je úhel pohledu, jak vnímáte nebezpečí znalosti nějakých IP adres vnitřní sítě venkovním světem. Uznávám, že NAT je jednoduché řešení pro skrytí vnitřní IP sítě před vnějším světem, ale v reálu to stejně není nějaká velká překážka k tomu zjistit nějaké podrobnější informace o vnitřní síti a zdrojové IP.

Problém je v tom, že pokud nějaký systém komunikuje do internetu, tak stavový firewall otevírá stejně zpětná spojení na vnitřní IP a cílovému systému (nebo nějakému útočníkovi po cestě) je proto úplně jedno, jestli je IP NATovaná. Firewall zkrátka cílovému systému tu komunikaci dovnitř na tom otevřeném portu povolí. Nikdo se nebude náhodně pokoušet komunikovat na známé IP do vnitřní sítě, když je jasné, že ta komunikace bude na firewallu zakázána. (A pokud ano, tak by to dle mých zkušeností byla spíš výhoda, vědět na jakou vnitřní IP se někdo pokouší útočit)

Z pohledu bezpečnosti je totiž už i dne s NATem na IPv4 důležitější zajistit to, aby důležité systémy sami přímo do internetu vůbec nekomunikovali a pro přístup z venčí (jak píše v následujícím komentáři FOK) používají tzv. Management station stroje.

Pokud je potřeba z nějakých takto důležitých systémů zajistit přenos dat mimo vlastní síť do nějakého neznámého prostředí, mělo by se to realizovat výhradně pomocí nějakých aplikačních proxy v DMZ, nebo replikací dat do DMZ a následně dál mimo síť. To je podle mě jediné rozumné řešení.

"Nestojím o to, aby mi výpadek jmenného serveru zrušil provoz"
Pokud jste někdy registroval doménu, tak víte, že se to řeší redundancí DNS serverů.

"nestojím o to, aby mi do sítě lezly multicasty a broadcasty ...."
Co jiného, než oddělení firewallem by jste na to chtěl nasadit?

"Do technologické sítě je potřeba přístup zvenčí (Internet, LAN)."
Pro přístup zvenčí se používají VPN koncentrátory. A pro takovéto technologické celky se vcelku úspěšně používají tzv. Management station stroje. To je počítadlo, na které se přihlásíte a až odsud máte přístup do řízené sítě. Navíc může mít tato izolovaná síť i jiný síťový protokol (IPv4, IPX/SPX, SNA, ...). Na takovém stroji múžete samozřejmě řešit přístup dle libosti.

"mít šifrované propojení na velín, který může být v normální síti"
Velín takto kritického technologického celku nemá co dělat v nezabezpečené síti!!!

"Tak a teď nastavte bezchybně firewall tak, ať se v tom vyzná i někdo jiný než vy"
V mnou popsaném řešení firewall vůbec nepotřebujete. Tedy abych byl přesný, nepotřebujete jej k ochraně daného technologického celku. Jediný firewall, který tu asi bude je ten, který chrání přístup na Management stanici, kde bude vše zakázáno, kromě VPN spojení z vnějšího světa a potom asi z vnitřní sítě pro potřeby dávkového přenosu dat. Ta management stanice bude mít dvě síťovky, jednu připojenou do firewallu a druhou do technologické sítě.
NAT alespoň ten který máte nejspíš na mysli, Vás z principu ochrání proti DOS útoku ještě méně než firewall. Ono ve skutečnosti pokud se mluví o NATu, tak se má na mysli NAT + Firewall.

Doufám, že než se dovzděláte, tak nebudete zodpovědný za nějakou podobnou síť. To by byla totiž tragédie. Alespoň co se otázky bezpečnosti týče.

Zase tak nevzdělaný nejsem, jenom trošku. Jak NAT funguje a že nic nefiltruje dokonce vím, zase tak jedinečná a překvapivá informace to není zřejmě ani pro ostatní. Nastavení pravidel firewallu, které omezí veškerý provoz zvenčí a následně se povoluje jen to co chci považuji za tak standardní věc, že jsem to jaksi opoměl pro všechny rýpaly několikrát zdůraznit.
Nechme zbytečných diskuzí, třeba nám skutečně zkreslený pohled na věc, třeba ne. Praxe ukáže.

V IPv6 zadne broadcasty nejsou... :-)

V IPv6 opravdu ne. Musíte mít ale čistě IPv6 síť, jakmile máte na sítovém adapteru povolenou IPv4 nebo nějaké jiné IPv4 zařízení, zřejmě se nějaký objeví.

no, upřimně řečeno, ono mnohdy není příliš velký rozdíl mezi IPv6 multicastem a broadcastem, zvlášť, když switche neumějí ty různé MLD snoopingy a pod.

a MRP a GARP a ...