Moje motivace pro nasazování IPv6

30.6.2010 01:38 | Přečteno: 2148× | ostatní |

Nemám chuť se v blogu zabývat jakoukoli agitací, všechno o čem píšu, je čistě můj subjektivní pohled. Objeví se tu některá pro a proti, která snad (možná) můžou někomu i pomoct.

Takže k věci... čas od času se zabývám IPv6 v podobě psaní technicky laděných článků, školení, konfigurace sítí a taky prostým hraním si na vlastním písečku.

Aktuální stav IPv6 na mých strojích

Link-local mi běží prakticky všude, stejně jako velké části z vás. Globální konektivitu jsem měl před časem v rámci experimentování řešenou tunely. Opakovaně jsem překopával sítě a končilo to různou mírou podpory IPv6.

Globální nativní konektivitu postupně rozjíždím jak na své domácí síti, tak na virtuálních serverech na Internetu (nejen vpsFree poskytuje IPv6).

V brzké době budu rozšiřovat použití AAAA záznamů na všecky svoje stroje, u kterých to má smysl.

Proč?

Zásadní otázka, že?

Tak zaprvé, proč ne? Počítačové sítě jsou jedna z mých hlavních činností a od ignorování aktuálních technologií jsou tu jiní. Jsem hračička. Ale najde se i pár zcela konkrétních důvodů.

Modernější protokol

Proti IPv4 jako takovému nic nemám, ale některé věci tam jsou ještě prostě postaru a jen jakž takž přizpůsobené dnešnímu stavu.

IPv6 není spása, ale každopádně po přečtení mnoha RFC mám pocit, že je to krok dopředu. Protokol čistší a připravenější na aktuální i budoucí použití. Odpusťte mi, že se v blogu zabývám svým pocitem více než fakty, ale o těch jindy :).

V jednoduchosti je krása

Už samotné odstranění IP maškarády spoustu věcí zjednodušuje. Ale kdo nezná, neocení. Bez maškarády funguje IP velmi přímočaře.

IPv4 tuto úlohu přestalo plnit už před delší dobou.

Důvěra v dlouhodobou investici

Ano, věřím, že IPv6 nahradí IPv4. Naopak nevěřím, že se objeví jiný protokol, který by IPv4 stihl nahradit a IPv6 předčasně odepsat. Berte to jako jakousi prognózu.

A když tuším, že se to tu bude používat, tak to chci pořádně umět. Tenhle blogpost jsem měl rozepsaný ještě před konferencí IT10, po které je budoucnoust IP v Česku o něco jasnější.

Rozsahy IP adres

Zeptal jsem se poskytovatele na veřejné IPv4 adresy. Dostal jsem jich tolik, kolik mám doma počítačů, plus ještě snad dvě navíc na různé testování. Přesto to necítím jako plnohodnotnou podsíť.

Rád bych si tu udržoval zmenšený model skutečné IP sítě pro hraní a experimentování. Proto dám přednost celému rozsahu IP adres včetně delegace reverzního DNS (to budu mít možná i na IPv4).

Správa vlastních sítí

Zapojením spravovaných počítačů do IPv6 zmizí potřeba používat specializovaný VPN software, kde není potřeba. Šifrování a autentizaci zajišťuje samo SSH (mimojiné) a odstínění ostatních portů zajistí triviální firewall.

Pro obecnější propojení počítám s nasazením IPsecu.

Otevřenost

Bezbariérový přístup (bez maškarády) přímo láká k otevřenější spolupráci po internetu. Tím má IPv6 bez maškarády velmi blízko k myšlenkám opensource, free software a dalším věcem u uživatelů Abclinuxu obvyklým.

End-to-end komunikace

Věřím na end-to-end konektivitu a služby. Nevidím důvod, proč by si člověk nemohl na notebook nahodit třeba webovou vizitku, file server s veřejnými daty a podobné věci.

Nevidím důvod, proč by nemohla probíhat přímá textová či audio/video komunikace. Proč nenastreamovat kousek něčeho, co chci zrovna pár lidem naživo ukázat.

End-to-end služby znalému člověku poskytují docela velké možnosti a při troše přizpůsobení by se to dalo převést i na běžné uživatele.

Repozitáře gitu, repozitáře softwaru, spousta veřejných zdrojů, které můžu jednou za čas mirrorovat na server, ale zároveň v reálném čase zpřístupňovat svým známým přímo.

Lidi si podle mě v poslední době až moc zvykají na modely typu v lepším případě //klient-server-server-klient// a v horším //klient-server-klient// (kdy vás ostatní navíc nutí odebírat službu od stejné firmy).

Správa lokálních strojů

IPv6 umožňuje přístup i k zařízením pomocí link-local addres. Ve spojení s mDNS to nabízí možnost se připojovat k zařízení bez ohledu na konfiguraci globální konektivity. Linková adresa zůstává nastavená společně s globální adresou.

Na IPv4 to lze do jisté míry taky, ale jednak to není úplně ustálené a jedna IPv4 link-local adresy ztrácí při pokusech o konfiguraci plnohodnotné konektivity.

Mobilita a IPsec

Uznávám, že v dnešním prostředí to půjde použít jen velkou oklikou a spíš to zůstane na různých IPv6-in-UDP tunelech. Ale proč si to aspoň nevyzkoušet, že?

Multicasting

Globální multicasting je na IPv4 velmi omezený. Teprve IPv6 má dostatečný adresní prostor na jeho volné použití.

Bezpečnost

Paradoxně bych IPv6 bral i kvůli bezpečnosti, která je u něj často kritizována (nechme stranou, že si myslím, že neoprávněně). Větší rozsah adres výrazně stěžuje prosté scanování. Při správném použití IPv6 nemusí vznikat nová rizika.

Co může od nasazení odradit?

Tahle část je hlavně pro vás, protože u mě je už pozdě :).

Byli jste na mém školení

Chápu. Na svých školeních už jsem odradil nejednoho nadšence pro konvertování celé firmy na IPv6.

Někteří přišli s nadšením, že IPv6 vyřeší všechny jejich problémy se sítí. Fajn, některé by to určitě vyřešilo. Ale ty šly při troše šikovnosti řešit i na IPv4.

A pak často síť ještě obsahovala nemalé procento zastaralých operačních systému, které byly opatřeny v lepším případě experimentální konektivitou.

Ale to trošku způsobil Microsoft tím, že Visty způsobily u zákazníků takový odpor, že mají doteď XP obrovský podíl na firemních desktopech. Zákazníci se po zkušenostech s Vistou (a downgradem na XP) snad začali bát i Windows 7.

Je to moc složité

Nevěřím. Oproti nasazení IPv4 mi ani nepřišlo, spíše je to v něčem nové.

Dlouhé adresy

Doporučuju DNS a mDNS (ano, obojí dohromady). Multicast varianta funguje i na link-local adresách.

Dlouhé adresy jsou v IPv6 typickým příkladem vlastnosti, ne chyby. A je to vlastnost, kvůli které IPv6 primárně vzniklo.

Nedostupnost nativní konektivity

Můžete počkat, můžete se aktivně snažit ji získat, nebo můžete používat tunely. Co z toho je pro vás nejlepší, to já nemůžu tušit.

Neužitečnost

Ta je velmi subjektivní. Přesto chápu, že se někdo nechce zabývat technologií která mu nic nepřinese. Teda kromě nových problémů. Než se projeví výhody IPv6 v reálném světě, bude se projevovat současný problém vejce a slepice.

Bezpečnost

O té už jsem někde psal. Jo aha, to bylo mezi pozitivy. Ano, za určitých okolností a při určitém (špatném) provedení může nasazení představovat bezpečnostní riziko.

Jakýkoli jiný důvod

Jistě, důvodů může být spousta. Zatím nasazovat není potřeba a ještě dlouho nebude.

Ať bude rychlost nasazení IPv6 jakákoli, IPv4 tu bude s námi ještě hodně dlouho. A vlastně mi to ani nevadí, přesto dám zatím přednost dualstackovému řešení před výběrem mezi čistým IPv4 a čistým IPv6.

Závěrem

Důvody pro a proti určitě nejsou vyčerpávající, jen jsem se chtěl podělit o ty, které mě napadly.        

Komentáře

[VSi]

Nástup IPv6 a tím jakési znovu obnovení možnosti end-to-end komunikaci rozhodně vítám. Podstatná je ta možnost - když budu chtít, zpřístupním si na domácí počítač SSH přístup bez nějakých VPN, které dnes potřebuju.

Jen v tom vidím dost podstatné bezpečnostní souvislosti, které mi "propagační" články o IPv6 zatím neobjasnily. Vlivem nasazování NATu, jsme se na IPv4 dostali do stavu, kdy end-to-end konektivita není obecně dostupná. Současně s tím přicházelo rozšíření firewallů, ať už v rámci domácích routerů, nebo i firemních sítí. Takový firewall si dnes může jako "výchozí konfiguraci" dovolit blokovat veškerá příchozí spojení a povolit odchozí. Výjimky pro příchozí spojení jsou jasně definovatelné právě v důsledku toho, že došlo k separaci "klientských" a "serverových" služeb.

Naznačená konfigurace firewallu podle mě velmi zásadně zvyšuje bezpečnost počítačů uvnitř LAN. V případě Windows znamená vystavení stroje na veřejnou IP adresu bez firewallu něco jako rychlou smrt, při použití základního firewallu na routeru už firewall na samotném počítači skoro není potřeba. Ale i pro linuxový stroj je takový centrální firewall přínos, často po instalaci různé služby (webserver, databáze) naslouchají na všech rozhraních, a aby byly ve výchozím stavu globálně přístupné, to mi nepřijde nejlepší.

Ptám se, jak po nasazení IPv6 toto řešit, abych nezabil tu výhodu end-to-end konektivity? Samozřejmě můžu použít klasický stavový firewall přes iptables, a blokovat příchozí spojení. Firemní sítě tak budou velmi pravděpodobně nastaveny. Očekávám, že aplikace typu Skype apod. stejně na IPv6 nebodou moci očekávat, že se vždy bude možné přímé připojení na jiné počítače s IPv6.

Samozřejmě tu zůstává velmi významná výhoda, že na IPv6 mají všechy PC za tím případným firewallem globální adresu, takže si snadno můžu třeba to příchozí ssh povolit. Ale to musí řešit správce firewallu, což není vždy průchodné a hned dostupné řešení. Vím, že existují nástroje typu UPNP, kde si počítače v LAN mohou na firewallu vyžádat otevření portů. Je toto řešení pro IPv6? Nebo je jím přesun pořádného firewallu na každý jednotlivý počítač v LAN? Na Windows alespoň existují "aplikační" firewally - když chce nějaký program naslouchat, můžete otevření portu povolit selektivně jen pro něj. Na Linuxu jsem nic takového neviděl.

[pht]

Takový firewall si dnes může jako "výchozí konfiguraci" dovolit blokovat veškerá příchozí spojení a povolit odchozí. Výjimky pro příchozí spojení jsou jasně definovatelné právě v důsledku toho, že došlo k separaci "klientských" a "serverových" služeb. Naznačená konfigurace firewallu podle mě velmi zásadně zvyšuje bezpečnost počítačů uvnitř LAN.

To je dost naivní pohled, který fungoval tak před 10 lety. Většina zranitelností vám dnes přijde mailem nebo se k vám dostane tak že procházíte web. Botnet sítě s tímto modelem "firewallu" počítají a nemají s tím sebemenší problém.

při použití základního firewallu na routeru už firewall na samotném počítači skoro není potřeba

Další přežitek: model všechno nebo nic. Na síti by měl každý kopat sám za sebe a věřit jen tomu čemu musí.

Ptám se, jak po nasazení IPv6 toto řešit, abych nezabil tu výhodu end-to-end konektivity? Samozřejmě můžu použít klasický stavový firewall přes iptables, a blokovat příchozí spojení. Firemní sítě tak budou velmi pravděpodobně nastaveny. Očekávám, že aplikace typu Skype apod. stejně na IPv6 nebodou moci očekávat, že se vždy bude možné přímé připojení na jiné počítače s IPv6.

Vyřešíte to normálně tak že povolíte ten port pro tu aplikaci. Nic lepšího s tím neuděláte. Jestli se aplikace spojuje ven nebo někdo na ni je z hlediska bezpečnosti té aplikace dost jedno. Absence modelu "interní sítě" aspoň donutí lidi se zamyslet nad zabezpečením té aplikace samotné.

[Zdenek]

Další přežitek: model všechno nebo nic. Na síti by měl každý kopat sám za sebe a věřit jen tomu čemu musí.

Tak prezitek? A tim sam za sebe myslite ty uzivatele netusi co je to IP adresa a veri nigerijskym mailum? Nebo ze by si tito lide najednou zacli platit administratory?

Absence modelu "interní sítě" aspoň donutí lidi se zamyslet nad zabezpečením té aplikace samotné.

Ktere lidi? Programatory nebo uzivatele? No stejne je to jedno, v realnem svete se nezamysli ani jedna skupina.

Jo az bude trestni odpovednost za nezabezpeceny pocitac tak to bude jina.

[Jirka]

Ale no tak. Bude to jako dnes, akorát ve větším měřítku. Naprostá většina BFU si na konfiguraci počítače nesahá a někoho na to mají. Takže to není žádný velký problém.

A pak mnoho lidí má veřejnou IPv4 a ani o tom neví (převážně ti s UPC a s 1 počítačem), přesto se nic moc neděje (své služby neprovozují a ty systémové ma na starost dodavatel systému).

Já bych do problematiky nasazování IPv6 vůbec BFU nezatahoval. Nic o tom neví (to neví ani o IPvv4 a NAT) a počítač si dokáží zasvinit i bez veřejné adresy.

Když použiji nějakou stupidní autonalogii, tak bych řekl, že pro řízení auta sice nemusím rozumět motorům, ale musím si umět alespoň zkontrolovat olej, tekutiny a alespoň odhadnout způsobilost ozidla pro provoz a případně zajít k automechanikovi.

A alespoň nám vzniknou nějaké nové obchodní příležitosti a nové pracovní místa.

[pht]

tim sam za sebe myslite ty uzivatele netusi co je to IP adresa a veri nigerijskym mailum?

Ne, to je myšleno na počítače na síti.

Ktere lidi? Programatory nebo uzivatele?

Nejspíš ti, co na dané síti zodpovídají za zabezpečení dat.

[VSi]

Takový firewall si dnes může jako "výchozí konfiguraci" dovolit blokovat veškerá příchozí spojení a povolit odchozí. Výjimky pro příchozí spojení jsou jasně definovatelné právě v důsledku toho, že došlo k separaci "klientských" a "serverových" služeb. Naznačená konfigurace firewallu podle mě velmi zásadně zvyšuje bezpečnost počítačů uvnitř LAN.

To je dost naivní pohled, který fungoval tak před 10 lety. Většina zranitelností vám dnes přijde mailem nebo se k vám dostane tak že procházíte web. Botnet sítě s tímto modelem "firewallu" počítají a nemají s tím sebemenší problém.

Tak jistě, že se malware přizpůsobil, a existuje mnoho zranitelností pro které firewall není překážka. Stojím si ale za tím, že použití popsaného firewallu omezí prostor pro významnou část útoků.

při použití základního firewallu na routeru už firewall na samotném počítači skoro není potřeba

Další přežitek: model všechno nebo nic. Na síti by měl každý kopat sám za sebe a věřit jen tomu čemu musí.

Na jednu stranu je to pravda, ale neplatí to podle mě obecně ve všech situacích. Např. při instalaci OS, ladění nějakého embedded systému, nebo nějaké nouzové opravě, kdy jsem rád že se mi povede nabootovat nějaký systém a nahodit síť, tak jsem rád, že LAN je oddělena od "nebezpečí" otevřeného internetu. Dnes už to není tak hrozné, ale pamatuji si instalaci Windows 2000 s veřejnou IP adresou nastavenou během instalace. Během 15 minut, ještě než jsem stihl nainstalovat firewall byl ten počítač v podstatě mrtvý. Samozřejmě je to chyba toho systému, ale takové situace nastávají, alespoň já se s nimi setkávám.

Model vnitřní síť vs. internet je jaksi proti filosofii původního internetu. Z nějakého důvodu ho ale správci používají i v sítích bez NATu, takže to není z nouze ctnost. Já to vnímám tak, že internet je dnes prostě jiný, než s jakými ideály byl navrhován, a realita se tomu přizpůsobuje. V praxi ideály obvykle podlehnou řešení, které je "funkční", ale ne hezké. Často čtu, že bychom na IPv6 měli využít příležistosi, a udělat to celé lépe, neopakovat chyby jako IPv4 NAT. Podle mě to tak úplně nedopadne.

Ještě k tomu multicastu. Nepředpokládám, že by začal být použitelný hned po rozšíření IPv6. Problém není jen v dostupnosti adres, ale také v řízení sítě, resp. účtování a omezování kapacity v sítích ISP. Nevím, jestli IPv6 přichází v této problematice s nějakým reálným řešením. V současnosti multicast funguje v akademických sítích (třeba CESNET) nebo v rámci jednoho ISP pro IPTV apod. (a i uvnitř sítě jednoho ISP není provoz multicastu triviální na správu), v globálním internetu v podstatě neexistuje, i když aplikace, pro které by se vyloženě hodil, jsou.

[pavlix]

Model vnitřní síť vs. internet je jaksi proti filosofii původního internetu. Z nějakého důvodu ho ale správci používají i v sítích bez NATu, takže to není z nouze ctnost.

Vnitřní samosatně adresovaná síť bez NATu (nebo nějaké proxy) je naprosto legitimní i když dneska ne tak obvyklé použití TCP/IP. Jen už se z takové sítě nepodíváš na net.

Často čtu, že bychom na IPv6 měli využít příležistosi, a udělat to celé lépe, neopakovat chyby jako IPv4 NAT. Podle mě to tak úplně nedopadne.

Zase hop nebo trop, ne. Snad nechceš tvrdit, že se nevyvarujeme žádných (nebo dejme tomu podstatného množství) chyb či nedostatků? Nikdo nikdy netvrdil, že tím vyřešíme všechny.

Ještě k tomu multicastu. Nepředpokládám, že by začal být použitelný hned po rozšíření IPv6. Problém není jen v dostupnosti adres, ale také v řízení sítě, resp. účtování a omezování kapacity v sítích ISP. Nevím, jestli IPv6 přichází v této problematice s nějakým reálným řešením.

Problím v účtování a omezování sítě mi přijde na multicastu víceméně nezávislý.

v globálním internetu v podstatě neexistuje

Protože na IPv4 musíš žádat o každou globální multicast adresu. Na IPv6 si můžeš globální multicast adresy přidělovat sám. Ale uznávám, že globální multicasting není jednoduchá oblast.

[VSi]

Vnitřní samosatně adresovaná síť bez NATu (nebo nějaké proxy) je naprosto legitimní i když dneska ne tak obvyklé použití TCP/IP. Jen už se z takové sítě nepodíváš na net.

Já se ale z té sítě chci "dostat na net", alespoň ve smyslu, že si přes http budu moci stáhout třeba balíčky v instalátoru systému.

TCP/IP v izolované síti se používá třeba v různých průmyslových aplikacích, ale je tendence, aby ta síť nebyla tak úplně izolovaná. Aby se z ní daly dostávat informace třeba v rámci firemni LAN nebo VPN. Často se to řeší skrze NAT, takže IPv6 je pokrok. Nicméně průmyslová sféra je v tomhle dost konzervativní. Jsou rádi, že ta zařízení v posledních letech jakž-takž zvládají IPv4. Dokud to uspokojivě funguje (třebaže ze síťového hlediska nehezky), je nějaká změna bezdůvodná.

Ohledně multicastu jsem viděl vyjádření v tom smyslu, že unicast je prostě tok dat z místa A do B. Kdežto multicast je z A do teoreticky nekonečně míst. Mám např. od ISP konektivitu 100 Mbit/s NIX a 10 MBit/s tranzit. Pokud bych pustil multicast skrze ten tranzit (a ještě by to šlo přes různé tranzitní ISP), asi bude dost problém v tom, řešit to omezení. Ode mě půjde 10 Mbit/s, ale v sítí ISP se ten tok může násobit, a tranzitní linky zatížit n×10 Mbit/s. Pokud se pletu, budu rád, když mě někdo opraví. Samozřejmě v praxi bude v této situaci zapojeno víc ISP, čímž se problém komplikuje. Multicast zřejmě není úplně kompatibilní se současným modelem prodeje konektivity.

[pht]

Stojím si ale za tím, že použití popsaného firewallu omezí prostor pro významnou část útoků.

Pokud 10% říkáte podstatná část tak proč ne :) Neříkám že takový firewall je a priori k hovnu, jen že sám o sobě je hned za tím hovnem...

Např. při instalaci OS, ladění nějakého embedded systému, nebo nějaké nouzové opravě, kdy jsem rád že se mi povede nabootovat nějaký systém a nahodit síť, tak jsem rád, že LAN je oddělena od "nebezpečí" otevřeného internetu.

To je fajn, ale proč by měla mít vaše účetní ze svého PC přístup k tomu embedded nebo čerstvě vylíhnutému OS?

Pokud se stroj sám o sobě neumí "bránit" tak mu lze simulovat samozřejmě soukromou síť pomocí předřazeného FW, ale je blbost cpát jeden FW na stovky strojů o kterých nic nevím; proto název "všechno nebo nic".

[pavlix]

Vlivem nasazování NATu, jsme se na IPv4 dostali do stavu, kdy end-to-end konektivita není obecně dostupná.

Což zdaleka neznamená, že jsi v bezpečí.

Ptám se, jak po nasazení IPv6 toto řešit, abych nezabil tu výhodu end-to-end konektivity? Samozřejmě můžu použít klasický stavový firewall přes iptables, a blokovat příchozí spojení.

Přesně tak, úplně stejně jako na IPv4. Plus nadefinujete výjimky. Problém IP maškarády je ten, že u ní nelze nadefinovat jednoduché výjimky (ano o portforwardu vím).

Skype bych sem netahal, ten žije právě z toho, že si ty díry vytvoří. Navíc bavit se o bezpečnostních rizikách a používat na stejné síti takový balast (šifrováním zamotaná binárka aktivně se bránící debuggerům) je přinejmenším podivné.

Samozřejmě tu zůstává velmi významná výhoda, že na IPv6 mají všechy PC za tím případným firewallem globální adresu, takže si snadno můžu třeba to příchozí ssh povolit. Ale to musí řešit správce firewallu, což není vždy průchodné a hned dostupné řešení.

A o tom to je. Buď to správce povolí, nebo ho musíš obcházet. Ale i v tom obcházení ti IPv6 pomůže, protože jakmile získáš kanál pro obousměrnou komunikaci, můžeš v něm udělat tunel a naroutovat si celou takto neomezenou síť.

Nebo je jím přesun pořádného firewallu na každý jednotlivý počítač v LAN?

I přesun firewallu je rozhodnutím provozovatele sítě.

[VSi]

Vlivem nasazování NATu, jsme se na IPv4 dostali do stavu, kdy end-to-end konektivita není obecně dostupná.

Což zdaleka neznamená, že jsi v bezpečí.

To netvrdím, napsal jsem to jako výchozí tvrzení. Důsledkem tohoto faktu je podle mě obecná možnost nasazení stavového firewallu na hranici LAN, který by-default blokuje příchozí spojení. Aplikace s takovým stavem musí počítat kvůli těm NATům, takže pokud mám takový firewall, neomezím zásadně nejvíce používané služby (a to je krom webu ten Skype, ICQ, nebo ať jsme korektní tak i Jabber, apod.).

Ptám se, jak po nasazení IPv6 toto řešit, abych nezabil tu výhodu end-to-end konektivity? Samozřejmě můžu použít klasický stavový firewall přes iptables, a blokovat příchozí spojení.

Přesně tak, úplně stejně jako na IPv4. Plus nadefinujete výjimky. Problém IP maškarády je ten, že u ní nelze nadefinovat jednoduché výjimky (ano o portforwardu vím).

Skype bych sem netahal, ten žije právě z toho, že si ty díry vytvoří. Navíc bavit se o bezpečnostních rizikách a používat na stejné síti takový balast (šifrováním zamotaná binárka aktivně se bránící debuggerům) je přinejmenším podivné.

To chápu, je mi jasná i ta výhoda, že nemusím řešit pofidérní port forward. Pokud ale někdo argumentuje, že IPv6 např. vyřeší současné značné problémy s posíláním souborů nezi IM klienty (to čtu a poslochám velmi často), tak to podle mě není obecná pravda. Když budu mít IPv6 a oba klienti budou v takovéhle síti za firewallem, stejně bude potřeba server pro zprostředkování přenosu.

Samozřejmě tu zůstává velmi významná výhoda, že na IPv6 mají všechy PC za tím případným firewallem globální adresu, takže si snadno můžu třeba to příchozí ssh povolit. Ale to musí řešit správce firewallu, což není vždy průchodné a hned dostupné řešení.

A o tom to je. Buď to správce povolí, nebo ho musíš obcházet. Ale i v tom obcházení ti IPv6 pomůže, protože jakmile získáš kanál pro obousměrnou komunikaci, můžeš v něm udělat tunel a naroutovat si celou takto neomezenou síť.

Souhlas.

[pavlix]

Důsledkem tohoto faktu je podle mě obecná možnost nasazení stavového firewallu na hranici LAN

Toto není pravda. Možnost nasazení takového stavového firewallu je na nasazení NAT zcela nezávislá, který by-default blokuje příchozí spojení.

Podle tvého tvrzení bych nemohl nasadit stavový firewall bez NATu, což na mnoha místech dělám.

Pokud ale někdo argumentuje, že IPv6 např. vyřeší současné značné problémy s posíláním souborů nezi IM klienty (to čtu a poslochám velmi často), tak to podle mě není obecná pravda.

Ano, neplatí to úplně obecně a nefunguje to samo od sebe při nasazení příliš restriktivního firewallu. Ale firewall je tu právě od toho, aby šly věci zakázat.

Když budu mít IPv6 a oba klienti budou v takovéhle síti za firewallem, stejně bude potřeba server pro zprostředkování přenosu.

Vyčítáš jiným zjednodušení, které neplatí obecně a sám se ho dopouštíš. To co píšeš, je obcházení firewallu. Pokud správce uzná za vhodné, může firewall nastavit tak, aby ho nebylo potřeba obcházet. Nezapomeň, že doma jsi buď správcem ty, nebo někdo, kdo nastaví firewall, jak si řekneš. Jako zaměstnanec zase nemáš na mimopracovní komunikaci po internetu nárok, maximálně je tolerována. Pro pracovní komunikaci si můžeš vyžádat takovou konfiguraci, aby fungovala.

[VSi]

Toto není pravda. Možnost nasazení takového stavového firewallu je na nasazení NAT zcela nezávislá, který by-default blokuje příchozí spojení.

Podle tvého tvrzení bych nemohl nasadit stavový firewall bez NATu, což na mnoha místech dělám.

Myslel jsem to jinak. Podle mě, kdyby historicky nedošlo k takovému rozšíření NATu, tak by velká část běžně používaných aplikací (třeba typu instant messaging) mohla počítat s dostupností end-to-end konektivity, a nasazení zmíněného firewallu by takové aplikace odřízlo. Tady to byla spíš taková úvaha co by kdyby. Nic důležitého o čem bych se chtěl dohadovat.

Souvislost těchto dvou technologií jsem rozhodně nemyslel jako technickou, spíš jako věc historického vývoje.

Vyčítáš jiným zjednodušení, které neplatí obecně a sám se ho dopouštíš. To co píšeš, je obcházení firewallu. Pokud správce uzná za vhodné, může firewall nastavit tak, aby ho nebylo potřeba obcházet. Nezapomeň, že doma jsi buď správcem ty, nebo někdo, kdo nastaví firewall, jak si řekneš. Jako zaměstnanec zase nemáš na mimopracovní komunikaci po internetu nárok, maximálně je tolerována. Pro pracovní komunikaci si můžeš vyžádat takovou konfiguraci, aby fungovala.

Ano zjednodušil jsem to, možná až moc. Doma je to jedna věc, když jsem někde zaměstnán tak je to taky jiná situace. Mě se často stává, že se někdě můžu připojit do sítě (nechce se mi psát, že do Internetu) - na návštěvě, ve škole, v cizí firmě, v hotelu a podobě. Takové sítě jsou často nastavé všelijak a třeba i dost restriktivně. A reálná možnost nějak komunikovat se správcem té sítě, nebo po něm něco chtít prostě není. A když jsem v takové síti, chci se podívat na web, připojit se na IM a chci aby "vše fungovalo" (jako obyčejný uživatel, co se připojí někde na WiFi, ne jako síťový odborník).

Nemalá část úspěchu Skype spočívá v tom, že na jakémkoliv počítači s Windows, kde mám třeba minimální práva, a kde jakýmkoliv způsobem jde přístup na web (klidně proxy, firewall etc.), tak tam Skype "prostě funguje". To je (možná smutná) realita, ať je to z pohledu znalého člověka špatně jak chce. I když princip fungování Skype není moc pěkný, o tom se nepřu. Ale normálním lidem "to funguje".

[pavlix]

Myslel jsem to jinak. Podle mě, kdyby historicky nedošlo k takovému rozšíření NATu, tak by velká část běžně používaných aplikací (třeba typu instant messaging) mohla počítat s dostupností end-to-end konektivity, a nasazení zmíněného firewallu by takové aplikace odřízlo. Tady to byla spíš taková úvaha co by kdyby. Nic důležitého o čem bych se chtěl dohadovat.

To už zní o něco věrohodněji, ale vycházíš z předpokladu, že tu dlouho byla IP maškaráda a pak teprve se vymyslel stavový firewall. Nemůžu se dogooglit konkrétních roků, ale všechno nasvědčuje tomu, že stavový firewall je tu minimálně stejně dlouho jako maškaráda.

Tudíž, by se aplikace musely přizpůsobit tak jako tak.

Ano zjednodušil jsem to, možná až moc. Doma je to jedna věc, když jsem někde zaměstnán tak je to taky jiná situace. Mě se často stává, že se někdě můžu připojit do sítě (nechce se mi psát, že do Internetu) - na návštěvě, ve škole, v cizí firmě, v hotelu a podobě. Takové sítě jsou často nastavé všelijak a třeba i dost restriktivně.

Mám zkušenost, že tyto sítě (například ve školicích střediskách) jsou restriktivnější jak než IP maškaráda, tak než klasický stavový firewall. Takže jedinou možností plnohodnotné konektivity je tunel.

A když jsem v takové síti, chci se podívat na web, připojit se na IM a chci aby "vše fungovalo" (jako obyčejný uživatel, co se připojí někde na WiFi, ne jako síťový odborník).

Co chceš je jedna věc, a co dostaneš druhá. Odesílání mailu na port 25 ti fungovat obvykle nebude.

Nemalá část úspěchu Skype spočívá v tom, že na jakémkoliv počítači s Windows, kde mám třeba minimální práva, a kde jakýmkoliv způsobem jde přístup na web (klidně proxy, firewall etc.), tak tam Skype "prostě funguje".

Nemalá část úspěchu Skype spočívá v tom, že je to malware.

I když princip fungování Skype není moc pěkný, o tom se nepřu. Ale normálním lidem "to funguje".

Normálním lidem funguje to, co jim kdo nainstaluje (nebo poradí nainstalovat). Horší je, když se z normálních lidí stanou rádobyodborníci, kteří přesvědčují a nutí ostatní nainstalovat si to samé.

Horší je, že jim to funguje jen do té doby, dokud nenarazí na člověka, který není ochotný si ten malware do počítače instalovat. Skype tímhle problémem trpí extrémně, ICQ už o něco méně díky využití alternativních klientů (tuším stále ještě v rozporu s podmínkami užití).

Holt pak tito normální uživatelé musí ještě navíc přemýšlet, kterému člověku můžou zavolat kterým programem, takže ve výsledku to mají ještě složitější (a pokud místo toho zvolí mobilní telefon, tak i o dost dražší).

[pavlix]

Aplikace s takovým stavem musí počítat kvůli těm NATům,

Ono bohatě stačí, aby protokol fungoval pouze na TCP a UDP spojení (ano, musí se k UDP chovat jako ke spojení navzdory povaze UDP!) na modelu klient-server, kdy server je na veřejné adrese.

V tomhle se běžné nastavení Firwallu neliší, takže není důvod, aby takovéto klient/server aplikace své chování měnily.

takže pokud mám takový firewall, neomezím zásadně nejvíce používané služby (a to je krom webu ten Skype

Skype je prokazatelný malware, takže škoda mluvit.

ICQ

ICQ (progam) je taky dost na hranici, ICQ (síť) umí využívat veřejné adresy ke zkrácení cesty komunikace, pokud vím.

nebo ať jsme korektní tak i Jabber, apod.).

Jabber má spoustu doplňkových služeb, které za NATem buď nefungují, nebo musí pomoct externí počítač (proxy, STUN apod).

Zapomněl jsi na e-mail, který taky v dnešní době funguje na modelu klient/server (původně to byla z hlediska uživatele p2p služba, i když se po technické stránce jedná o klient/server).

Nenapadlo tě někdy, že to přizpůsobení zpozdilo nástup třeba VoIP o celé roky? Mít veřejné adresy, tak stačilo na firewallu povolit VoIP, zapojit telefon a hotovo. Skype by tak možná ani nestihl vzniknout.

[VSi]

Nenapadlo tě někdy, že to přizpůsobení zpozdilo nástup třeba VoIP o celé roky? Mít veřejné adresy, tak stačilo na firewallu povolit VoIP, zapojit telefon a hotovo. Skype by tak možná ani nestihl vzniknout.

Ano, VoIP tu rozhodně mohlo být dříve. Ale Skype lidé často používají proto, že jim jde i v práci v restriktivně nastavené síti. Je to realita, nepište mi, že když si to správce nepřeje, lidé by Skype neměli používat. Prostě tohle "co by se mělo a nemělo" je válcováno realitou. Možná se pohybuji v jiném prostředí než ty, ale já to takhle vnímám.

Právě to stačilo na firewallu povolit VoIP je někdy nepřekonatelná věc.

[kolcon]

... coz se resi pracovnim radem a IT policy...

druha vec je, ze skype treba dost vyznamne setri penize za zahranicni volani

[VSi]

... jasně, je rozdíl jak se tohle řeší v menších a větších firmách. Třeba v menší firmě tu síť IT administrátor kvůli posílení bezpečnosti nastaví restriktivně. Zaměstnanec chce používat Skype, resp. by chtěl Jabber, pokud by admin vyšel vstříc s nastavením sítě. Vedení firmy to v principu nevadí, ale admin nějaké speciální nastavení nedovolí a vedení firmy mu to těžko nařídí protože tomu nerozumí, jsou rádi, že ho tam mají, a nejde o bussiness-critical věc.

[pavlix]

Vedení firmy to v principu nevadí, ale admin nějaké speciální nastavení nedovolí

Tím zkráceně říkáš, že firmě vládne admin a ne její vedení.

a vedení firmy mu to těžko nařídí protože tomu nerozumí, jsou rádi, že ho tam mají, a nejde o bussiness-critical věc.

Tím zkráceně říkáš, že vedení firmy jsou debilové.

Máš nějaký tip na takovou firmu, že bych tam šel dělat admina? Nějaká testovací síť na hraní, kde si můžu dělat co chci, by se mi hodila. A vedení bych přikázal, ať mi nakoupí ještě pár pěkných hraček, pokud nechce, abych jim zpomalil síť :).

[pavlix]

Možná se pohybuji v jiném prostředí než ty, ale já to takhle vnímám.

Možná. A možná na to taky nahlížím hodně z technického pohledu.

Právě to stačilo na firewallu povolit VoIP je někdy nepřekonatelná věc.

Jo, taky už jsem byl ve firmě, kde (všechny) věci střídavě fungovaly a nefungovaly a se správcem firewallu se nešlo domluvit, protože neměl dostatečné znalosti.

Jsem si vědom jednoduchosti nasazení Skype samotnými uživateli a že daleko lépe než firewall funguje audit programového vybavení a pohrůžka vyhazovem při opakovaném zneužití firemních počítačů k činnosti zakázané firemní bezpečnostní politikou, kterou zaměstnanec jistě podepsal.

Chápu i to, že je realita jiná a jsem s tím celkem smířený :).

[Michal Fecko]

Rozmyslam ze nasadim az IPv8 a upgrade na 6ku preskocim :P

[pavlix]

Až navrhneš IPv8, pošli mi odkaz na specifikaci :).

[Vašek Lorenc]

IPv6 nasazujeme taky, ale problém je pořád v segmentu u koncových uživatelů -- víceméně nulové bezpečnostní prvky (každý si může dělat RA, odpovídat na DHCP) a k tomu ke všemu ještě existující Privacy Extension (a následně špatná dohledatelnost kohokoliv podle IPv6 adresy) to celé komplikují.. Nicméně to je jen otázka času a částečně se tomu dá vyjít naproti např. za pomoci 802.1x.

Nicméně na serverech už by to i šlo, tam je to zpravidla snazší.. tedy, pominu-li nutnost nějakého IPv6 firewallu, je-li ho zapotřebí.

[pavlix]

IPv6 nasazujeme taky, ale problém je pořád v segmentu u koncových uživatelů -- víceméně nulové bezpečnostní prvky (každý si může dělat RA, odpovídat na DHCP) a k tomu ke všemu ještě existující Privacy Extension (a následně špatná dohledatelnost kohokoliv podle IPv6 adresy) to celé komplikují.. Nicméně to je jen otázka času a částečně se tomu dá vyjít naproti např. za pomoci 802.1x.

Takže staré problémy z IPv4, všechno? Ta bezpečnost místních sítí je dost netriviální problém, díval bych se po 802.1x pro linkovou vrstvu, ale taky IPsec pro vrstvu síťovou.

Síť zabezpečená proti lokálnímu zneužití nebude nikdy tak hladce konfigurovatelná.

Nicméně na serverech už by to i šlo, tam je to zpravidla snazší.. tedy, pominu-li nutnost nějakého IPv6 firewallu, je-li ho zapotřebí.

Takže proti IPv4 žádné nové problémy?

[Ivan]

Takže staré problémy z IPv4, všechno?

No vlastne az na mobility a multicast je vsechno pri starem. Nejak si nedovedu predstavit jak ISP resi security atack z nejakeho mobilniho IPcka, ktere se zrovna nachazelo v jejich siti. Globalni multicast je vlastne taky novinka. Problem s IPv6 je v tom, ze vsechno co jste museli resit musite vyresit znovu a jinak. Treba igmp, pokud chcete omezovat uzivatelum prijem lokalniho multicastu, tak nasadite igmp filtry. Pokud je ovsem utocnik mazanej tak posle do site specialni multicast packet a rekne "ja jsem multicast router" a pak je igmp filtry ignoruji a on kuze koukat na jaky kanal chcete. Tohle se samozrejme na IPv6 vyresit da, dokonce to musite vyresit ale jinak. U IPv6 se tohle vsechno resi pres ICMP.
Na IPv4 vznikaly best practices za pochodu a trvalo to 30 let. Nasazovani IPv6 probiha jinak.

[pavlix]

No vlastne az na mobility a multicast je vsechno pri starem.

V podstatě jo. Není se čeho bát... Ty možnosti většího zabezpečení sice v IPv6 jsou (některé jsou backportované i do IPv4), ale jednak je spousta věcí ještě v návrhu (secure NDP apod), a jednak o ně málokdo stojí.

Pokud je ovsem utocnik mazanej tak posle do site specialni multicast packet a rekne "ja jsem multicast router" a pak je igmp filtry ignoruji a on kuze koukat na jaky kanal chcete.

To patří do té třídy link-local bezpečnosti, která se tradičně spíš ignorovala.

Nasazovani IPv6 probiha jinak.

IPv6 je hlavně pečlivě porovnávané s IPv4 (což je dobře), jakákoli změna k horšímu se kritizuje a opravuje (viz privacy extensions). Teda aspoň pokud to jde (například zapamatovatelnost obecných adres těžko).

[Vašek Lorenc]

Ano, vše při starém.. snad s tím rozdílem, že pro IPv4 už spousta prvků má vlastnosti a schopnosti obrany (dhcp snooping), což pro IPv6 zatím není. A to _je_ rozdíl.

Není to nová věc, ale v tom výčtu chyběla.. a tohle je jeden z dost nepříjemných problémů nasazování IPv6.

[pavlix]

no, vše při starém.. snad s tím rozdílem, že pro IPv4 už spousta prvků má vlastnosti a schopnosti obrany (dhcp snooping),

Což to je jasné, když tu máme ten protokol už nějakých 30 let :).

což pro IPv6 zatím není. A to _je_ rozdíl.

Tak to je implementační rozdíl :).

Není to nová věc, ale v tom výčtu chyběla.. a tohle je jeden z dost nepříjemných problémů nasazování IPv6.

Přišlo by mi naopak zvláštní, kdyby nový protokol změny v implementaci nevyžadoval. Nevím, co na tom může koho překvapovat.

Disclaimer: Implementaci IPv6 ve firmě už jsem několika lidem rozmlouval a ač nevím, jak velký měly moje rady vliv, implementaci odložili na neurčito. Připomněl jsem jim pár věcí, kterými by se museli zabývat a navrhnul alternativy některých řešení, které šly provést i na IPv4.

[pavlix]

Jen ještě doplním, že nasazení zmíněných ochranných prvků na IPv4 není zrovna obvyklé a tím pádem ve většině nasazení tento problém vůbec neexistuje.

[Vašek Lorenc]

S tím se dá rozhodně souhlasit -- hodně záleží na rozsahu a typu organizace, některé tyto problémy vůbec řešit nemusí.