Firewallová obsese (diskuse)

[Michal Kubeček]

Nějak jsem nepochopil, jak autor dospěl k tomu závěru, že maškaráda něčemu pomáhá. Z bezpečnostního hlediska nepřináší maškaráda nic, z praktického hlediska pouze komplikuje fungování řady služeb. Článek pouze dokládá, že někteří lidé si na berličku v podobě maškarád zvykli natolik, že si život bez nich (a podstatně větší možnosti, které se tím nabízejí) ani nedokážou představit. Takže i nadále přetrvává stav, kdy maškarády sice neřeší problém nedostatečné velikosti adresního prostoru IPv4, ale tím, že vzbuzují takový dojem, naopak vyřešení tohoto problému brání…

[Michal Kubeček]

A pokud to snad někdo nechápe, řeknu to naplno: Maškaráda sama o sobě nebrání libovolnému přístupu do vnitřní sítě. K tomu musí být doplněna o patřičná filtrovací pravidla - a tato pravidla přístupu zabrání i bez té maškarády. Je to tedy filtr, kdo přístupu brání, maškaráda v tom nehraje žádnou roli.

[Radek Podgorny]

...presne tak. Jen doufam, ze se jednou doziju dne, kdy bude maskarada a obecne natovani jen neprijemna vzpominka...

[Dan]

+1

[Zdeněk Štěpánek]

Presne tak, NAT je zlo !

[Lu-Tze]

To jsem nevěděl, že adresy v ipv6 nejsou hierarchické a že funguje přenositelnost adres mezi poskytovateli připojení. Tak to až se rozhodnu přejít k jinému poskytovateli, nebudu muset ve vnitřní síti vůbec nic měnit! Paráda. A co když mám dvě připojení k internetu (jedno záložní pro případ výpadku primárního) to se asi taky nějak řeší. Skvělé. Pryč s NATem! Obzvlášť je třeba pranýřovat NAT 1:1, je to zlo!

[thingie]

Ano. Tohle co píšeš se řešit dá i bez NATu. Překvápko.

[Lu-Tze]

Jak?

[Lu-Tze]

Třeba tak, že se v lokální síti bude uvažovat jenom část adresy, takže když se změní provider, změní se jen prefix a na síť to nebude mít vliv. Zatracenej Štěpánek!

[thingie]

Třeba. Koukám, že jsem tu zbytečný

[thingie]

Tak tam šlo dost o ten stavový firewall, což je v tomhle případě docela podstatná věc, pokud chceme filtrovat všechno dovnitř krom navázaných spojení. Překládat adresy jen tak pro nic za nic je samozřejmě ptákovina.

[Michal Vyskočil]

Mě tedy nejvíce zaujal poslední odstaveček

Unlike NAT, which is almost a given for most consumers, especially when connecting more than one computer to the Internet, end users can disable the IPv6 firewall functionality if and when they feel they're better off without it.

[Filip Jirsák]

Ono se stejně dobře dá napsat, že koncový uživatelé mohou zapnout firewall, pokud si myslí, že jim to k něčemu pomůže. Nikoho nenapadne, že by měl u bytu dveře, ale bylo by mu jedno, zda a jak se zamykají, případně by otevřel každému, kdo zazvoní. Ale u firewallu je to drtivé většině lidí jedno. Já mám firewall a antivir, tak se nemusím ničeho bát – nevadí, že jim vůbec nerozumím, vždyť je přece mám.

[zde]

Jasně, jenže ani jedna volba není "ta správná". Článek popisuje, jak Apple nejdřív měla jako defaultní volbu OFF, a byli sprdnutí že je to špatně, že je to "vážné bezpečnostní riziko". Tak to změnili na ON, a byli sprdnutí pro změnu za to že nefungují P2P aplikace. Za současného stavu (IPv6 firewall defaultně zapnutý) je pro povolení příchozích spojení na IPv6 zařízeních NUTNÁ manuální intervence, obdobná té kterou u IPv4 zařízení konfigurujete portforward. Závěr: IPv6 neřeší problémy, které přináší NAT.

[trekker.dk]

Té manuální intervenci se říká nastavení firewallu a je to jednoduchá operace.

Závěr: docházíš ke špatným závěrům.

[zde]

Té manuální intervenci se říká nastavení NATu a je to jednoduchá operace.

Závěr: docházíš ke špatným závěrům.

[trekker.dk]

Té manuální intervenci se říká nastavení NATu a je to jednoduchá operace.

Akorát tím nedokážeš to, co nastavením celého firewallu.

Závěr: docházíš ke špatným závěrům.

Opět jsi došel ke špatnému závěru

[zde]

Aha, pan Kubeček reaguje aniž by TFA četl. Nikdo netvrdil že NAT "něčemu pomáhá" (snad krom úspory veřejných adres, a snadnější změny providera). Podle IETF budou (mají mít) IPv6 krabičky defaultně zapnutý stavový firewall, z čehož plyne že IPv6 NEVYŘEŠÍ problémy které přináší NAT, proto je NAT (a argumentace jeho domělými výhodami či nevýhodami) v diskusi o IPv6 irelevantní.

Internet Engineering Task Force's IPv6 Operations sayez: The broadband gateway/router should be equipped with stateful firewall capabilities. These should provide a default configuration where incoming traffic is limited to return traffic resulting from outgoing packets (sometimes known as reflective session state). There should also be an easy interface which allows users to create inbound 'pinholes' for specific purposes such as online-gaming.

...

So, ironically, what's required to make IPv6 work through a stateful firewall is almost identical to what's required to make IPv4 work though NAT. This means the IETF's efforts to keep IPv6 NAT-free in order to make protocols do their job without messy workarounds are defeated by the notion that everything should be firewalled.

[Filip Jirsák]

IPv6 krabičky defaultně zapnutý stavový firewall, z čehož plyne že IPv6 NEVYŘEŠÍ problémy které přináší NAT

Můžu se zeptat, jaká je souvislost mezi problémy, které přináší NAT a stavovým firewallem?

[zde]

Ona souvislost je složitým zobrazením na bázi identity(tm robert). Zjednodušeně, přes obé neprojdou příchozí spojení.

[Michal Kubeček]

To je ale pouze váš názor. Zatímco přes maškarádu neprojdou prostě proto, že to z principu nejde (pomineme-li různé více či méně obskurní ekvivalenty drbání se pravou nohou za levým uchem), přes stavový filtr projde to, co budete chtít, aby prošlo.

[zde]

Zatímco přes maškarádu neprojdou prostě proto, že to z principu nejde (pomineme-li různé více či méně obskurní ekvivalenty drbání se pravou nohou za levým uchem),

Jde to minimálně 4 způsoby: ručně konfigurované portforwardy, UDP NAT traversal, UPnP, nebo NAT-PMP. Poslední 3 metody jsou standardizované, široce implementované a stabilní (rozhodně víc než aktuální IPv6). To že Vaše chápání "obskurního" je poněkud ortodoxní není moje vina.

přes stavový filtr projde to, co budete chtít, aby prošlo.

Jistě, a jak si aplikace řekne, co má projít? Další oblezličkou? To už nebude "obskurní"?

[Filip Jirsák]

Firewall si nenastavují dle svého uvážení aplikace, ale nastavuje je administrátor. V tom spočívá význam firewallu. To, že existují 4 způsoby řešení problémů, které by bez NATu vůbec nenastaly, je opravdu zásadní výhoda. Mimochodem, kterou z těch 3 standardizovaných metod mám použít, pokud mám za NATem webserver, SMTP server, DNS server apod.? Případně jich tam může být víc, pokud byste chtěl argumentovat tím "nestandardním" prvním způsobem.

[zde]

Představa dosti mimo. xDSL a cable modemy jsou spotřební elektronika. Rozbalí se krabice, dvě tři kliknutí na změnu admin hesla, případné nastavení WPA hesla, a jakmile to funguje (ve smyslu běhá WWW), je s nastavováním konec. Pokud je v defaultním configu zapnut firewall, bude jej mít 90% uživatelů trvale zapnutý.

Nastavení portforwardu přes UPnP je jen HTTP post request XML souboru, takže si to klidně můžete dát do startovacích skriptů oněch serverů. Web, SMTP, i DNS pro libovolný počet domén lze realizovat jen jedním serverem, takže jich víc nepotřebujete. A když náhodou jo (třeba kvůli údržbě, vývoji nebo testování), tak použijte reverzní proxy. Nebo můžete fungovat na nestandardních portech.

[Filip Jirsák]

Spotřební elektronika může mít stavový firewall nastavena tak, že bude propouštět veškerá odchozí spojení a žádné příchozí. Pokud bude chtít uživatel používat některé další služby (IM, VoIP), zaškrtne příslušnou volbu v konfiguračním rozhraní. Pořád je to daleko snazší, než zjišťovat, jak to můj ISP má s NATem. Když bude chtít provozovat web server, zase si to kliknutím povolí – a nemusí přesvědčovat ISP, aby kvůli němu zřídil reverzní proxy.

[zde]

No, já si myslím, že IP adres ještě není (a dlouho nebude) takový nedostatek, aby na každou domácnost nevyzbyla jedna veřejná adresa. Dokonce i Karneval už dává vždycky veřejnou adresu.. S tím že ISP, který zákazníky NATuje a neumožňuje jim ani mapovat porty, je ZLO, souhlasím. Osobně mi ale jedna veřejná IP adresa na DSL a za tím NAT plně vyhovuje.

[Filip Jirsák]

Zkuste si jako firma o nějaký blok IP adres pro každý počítač (takže třeba jen 64) požádat. Pokud považujete situaci, kdy musíte zdůvodnit, proč tolik IP adres požadujete, za "dostatek"…

[zde]

To že musíte zdůvodňovat že si neděláte kozy ještě neznamená nedostatek.

[petr_p]

Když vy na to jdete moc obchodně. Internet není jen o TCP nebo UDP. Budu chtít IPsec, budu chtít IP6oIP4, budu chtít GRE. Ještě si stále mysíte, že NAPT tohle zvládne?

Zrovna tak nutnost nastavovaní port forwadingu, pro každou TCP/UDP službu je opruz. Kdyby tohle měl dělat velký ISP, tak to může zabalit.

[Filip Jirsák]

Zjednodušeně, přes obé neprojdou příchozí spojení.

Přes stavový firewall příchozí spojení projdou, záleží na nastavení. Obecně přes NAT příchozí spojení taky projdou, opět záleží na nastavení. Přes maškarádu, což je asi nejrozšířenější případ NATu, příchozí spojení neprojdou, ale to není zamýšlený účel NATu, ale jeho vedlejší nešťastný efekt. IPv6 tedy umožní zrušit NAT a používat stavový firewall tam, kde je potřeba.

[zde]

Přes maškarádu, což je asi nejrozšířenější případ NATu, příchozí spojení neprojdou,

Projdou, stačí o to požádat. Linky na popis UPnP a NAT-PMP jsou v článku.

IPv6 tedy umožní zrušit NAT a používat stavový firewall tam, kde je potřeba.

Ano, bude možné NAT zrušit. Ovšem podle IETF bude stavový firewall defaultně zapnut, takže zrušení NATu vám nepomůže. Budete muset vyvrtat díru do firewallu. To jste ovšem mohli rovnou vrtat do NATu, a ušetřit si investice s přechodem na IPv6.

[Filip Jirsák]

Firewall je pro to "vrtání děr" stavěn. Do NATu dvě díry na SMTP server, DNS server nebo HTTPS server nevyvrtáte, ani když se budete na hlavu stavět. Argumenty o reverzních proxy si tentokrát nechte pro sebe, ne vždy je majitel jednoho serveru, majitel druhého serveru a majitel NATu jedna a tatáž osoba nebo organizace.

[zde]

> Firewall je pro to "vrtání děr" stavěn.

Ano a ne. Ano- byl opravdu navržen s tím, že bude možno definovat výjimky. Ne- lze to pouze manuálně, nejsou rozhraní a standardy, jak o to dynamicky požádá aplikace uvnitř. Pro NAT tyto standardy existují, ergo do NATu se díry vrtají snadněji než do firewallu.

> ne vždy je majitel jednoho serveru, majitel druhého serveru a majitel NATu jedna a tatáž osoba nebo organizace.

Pro to aby se lidé dohodli není třeba aby šlo o stejnou osobu nebo organizaci. Stačí snaha pomoci. Komerční subjekty vykazují překvapivou vstříctnost, vyvinou-li na ně zákazníci tlak. Dnes je samozřejmě jednodušší chtít další veřejnou adresu, nebo rovnou zřídit webhosting. Čím méně jich bude, tím ochotněji budou provideři realizovat alternativy.

[Filip Jirsák]

Firewall, který se bude otevírat na žádost aplikace, to je fakt terno. Doma taky provozujete zámky, které se otevřou, když je o to kdokoli požádá? To co vy označujete u NATu za standardizované protokoly, není ve skutečnosti obdoba nastavení pravidel v NATu, ale zahájení naslouchání na určitém portu a určité IP adrese. V IPv6 a IPv4 tedy aplikace dělá pouze jednu věc – začne naslouchat na daném portu. V IPv4 s NATem musí tuto věc duplikovat – jednak začne naslouchat na daném portu, ale jednak ještě musí o to samé požádat NAT.

Pro to aby se lidé dohodli není třeba aby šlo o stejnou osobu nebo organizaci. Stačí snaha pomoci. Komerční subjekty vykazují překvapivou vstříctnost, vyvinou-li na ně zákazníci tlak.

Já jako zákazník s certifikátem pro HTTPS server se s mým ISP na reverzní proxy, které bych svěřil ten certifikát, asi nedohodnu. Tolik by mi ISP nezaplatil, abych mu jej svěřil

[zde]

1) Máte pravdu, v případě NATu je explicitní žádost aplikace principielně nutná, zatímco firewall je teoreticky jen volitelná položka. V praxi (defaultně zapnutý firewall) ale bude duplikování potřeba v obou případech. S otvíráním dveří na žádost aplikace to tak špatně nevidím- zámek se otevře jen když o to požádá aplikace která je uvnitř, takže zámek smysl neztrácí.

2) Jo, HTTPS je blbě navrženo. Host: header měl být před SSL handshake. Vsaďte se že časem to předělají, nejspíš se bude MIME hlavička posílat dvakrát.

[petr_p]

2) Jo, HTTPS je blbě navrženo. Host: header měl být před SSL handshake. Vsaďte se že časem to předělají, nejspíš se bude MIME hlavička posílat dvakrát.

Už se stalo. Kromě inbound TLS, které lze nasadit do každého chalenge-response protokolu, existují položky ve vyjednávací hlavičce šifrovacího protokolu, kam lze hostname propašovat. Server tak může ještě přes ustanovením SSL spojení vybrat správný certifikát.

[Filip Jirsák]

1) Máte pravdu, v případě NATu je explicitní žádost aplikace principielně nutná, zatímco firewall je teoreticky jen volitelná položka. V praxi (defaultně zapnutý firewall) ale bude duplikování potřeba v obou případech. S otvíráním dveří na žádost aplikace to tak špatně nevidím- zámek se otevře jen když o to požádá aplikace která je uvnitř, takže zámek smysl neztrácí.

A k čemu je takový zámek, který se otevře na žádost aplikace? Není pak takový firewall zbytečný? Buď na daném portu aplikace nenaslouchá, pak je omezení takového portu na firewallu zbytečné, nebo na něm naslouchá, pak si ale předem otevřela firewall - takže je tam firewall zase zbytečně.

[zde]

> pak si ale předem otevřela firewall - takže je tam firewall zase zbytečně.

Zbytečný není, aplikace si otevřela (nebo u NATu alokovala) jen jeden konkrétní port, na který pak firewall přijme spojení (a třeba i filtruje spojení jen z určité zdrojové IP adresy).

[Filip Jirsák]

Ale každá aplikace si otevře ten svůj potřebný port, takže ve výsledku firewall propustí všechna spojení na otevřené porty – tedy jako by tam nebyl (bavíme se o firewallu, který povoluje/zakazuje TCP spojení, ostatních funkcí firewallu se tahle debata vůbec netýká). Spojení z určité zdrojové adresy by musela umět aplikace firewallu zase nějak říct, a není mi jasné, proč by o to žádala nějaký externí firewall – buď se o to aplikace postará sama, nebo si to správce té aplikace nastaví na firewallu toho konkrétního počítače.

[zde]

Ono by to asi skončilo tak, že pro otevření portu by součástí žádosti musel být nějaký ticket, a admin by aplikacím rozdával tickety, a tím je k tomu opravňoval.. Sice je to celé nesmysl, ale tlak na to aby defaultně byl sebeděravější pasivní systém uvnitř "bezpečný" bude takový, že stavový firewall bude po odstranění NATu normou.

[trekker.dk]

Projdou, stačí o to požádat. Linky na popis UPnP a NAT-PMP jsou v článku.

Neprojdou. Pokud je jedna veřejná IP adresa a za ní pět lidí bude provozovat vlastní webserver, tak čtyřem z nich nezajistíš naslouchání na portu 80 ani kdyby ses rozkrájel.

Budete muset vyvrtat díru do firewallu.

Jakou díru pořád? iptables -A INPUT -p tcp --dport 80 -j ACCEPT a je hotovo

[zde]

1) to řeší diskutovaná reverzní proxy.

2) a co má být? tvrdil jsem snad že vyvrtání díry do firewallu je to něco složitého či nemožného? ovšem na tom boxu nemusí běhat Linux, nemusí tam být zrovna iptables, a nemusí tam být ani shell, může tam být stovka variant klikacího rozhraní.. Ale stejně je to jedno, protože administrátorské heslo jste beztak dávno ztratili.

[trekker.dk]

1) to řeší diskutovaná reverzní proxy.

To řeší diskutované IPv6. AJednoduššeji

2) a co má být? tvrdil jsem snad že vyvrtání díry do firewallu je to něco složitého či nemožného? ovšem na tom boxu nemusí běhat Linux, nemusí tam být zrovna iptables, a nemusí tam být ani shell, může tam být stovka variant klikacího rozhraní..

A ve všech to půjde naklikat.

Ale stejně je to jedno, protože administrátorské heslo jste beztak dávno ztratili.

Od toho mají modemy a firewally takové kouzelné tlačítko, kterému se říká reset.

[zde]

1) Ono jde na jedné IPv6 adrese (nikoliv jednom /64 prefixu) provozovat 5 webserverů?

2) Ahoj já jsem super-program-pro-voip. Prosím povol mi na firewallu porty 8417/udp, 4555/tcp, 4555/udp, 5060/tcp, 5060/udp, 5061/tcp a 5061/udp. Pokud máš router od Linksysu, je to čtvrté menu shora, položka "security". Pokud je od Netgearu, je to pod položkou "filtering". Pokud máš router od Ovislinku, je to položka "firewall". Vyplň tam uvedené porty, a kleplni na "apply", případně "add filtering rule", připadně "submit".

3) Péťo, nechtej ten čudlík na pokoji! Vidíš že to funguje, tak na to nehrab, ještě to polámeš. Třeba do ADSL modemů se píšou PAP/CHAP hesla pro PPPoX auth, o ty resetem samozřejmě přijdete, takže jestli jste zašantročili smlouvu, budete týden bez netu, než z vašeho ISP vydolujete svůj username/pass.

[trekker.dk]

1) Ono jde na jedné IPv6 adrese (nikoliv jednom /64 prefixu) provozovat 5 webserverů?

Ne. Ale místo toho si můžu říct o 50 adres a dostanu je.

2) Ahoj já jsem super-program-pro-voip. Prosím povol mi na firewallu porty 8417/udp, 4555/tcp, 4555/udp, 5060/tcp, 5060/udp, 5061/tcp a 5061/udp. Pokud máš router od Linksysu, je to čtvrté menu shora, položka "security". Pokud je od Netgearu, je to pod položkou "filtering". Pokud máš router od Ovislinku, je to položka "firewall". Vyplň tam uvedené porty, a kleplni na "apply", případně "add filtering rule", připadně "submit".

Modemy se dají přepnout do režimu bridge a nechat firewallování na počítači, na kterém ten super program běží. Nastavení firewallu naklikáš ve Windows i v Linuxu a určitě to půjde udělat tak, aby nastavení provedl instalátor sám o sobě.

Krom toho tohle nemá souvislost s IPv6 jako takovým, protože to samé musíš udělat u IPv4 firewallu.

3) Péťo, nechtej ten čudlík na pokoji! Vidíš že to funguje, tak na to nehrab, ještě to polámeš. Třeba do ADSL modemů se píšou PAP/CHAP hesla pro PPPoX auth, o ty resetem samozřejmě přijdete, takže jestli jste zašantročili smlouvu, budete týden bez netu, než z vašeho ISP vydolujete svůj username/pass.

a) Ten čudlík se nedá tak snadno zmáčknout.

b) Když někdo zašantročí smlouvu, je to jeho chyba; není to důvod, abys kvůli tomu omezoval všechny ostatní.

c) když někdo zapomene heslo k modemu, není kvalifikován k tomu, aby v něm nastavoval cokoliv.

[Michal Kubeček]

Ad 1. A proč bych neměl pro domácí síť dostat /64 rozsah? Právě proto se přechází na IPv6, aby nebylo nutné vymýšlet krkolomné obezličky umožňující celé síti tvářit se jako jeden počítač za cenu nefunkčnosti řady služeb a problematického provozu těch ostatních.

[Michal Kubeček]

Ale četl, četl… Možná dokonce pozorněji (určitě kritičtěji) než vy. Problém je v tom, že právě to, co teď vypichujete, vůbec není pravda. Skrz maškarádu řadu služeb neprotlačíte prostě proto, že to principiálně nejde. U klasického stavového filtru si můžete vybrat, co (a komu) dovnitř pustíte a co ne. IPv6 principiální problémy maškarád vyřeší prostě tím, že odstraní jejich potřebu.

[xxx]

Asi před měsícem jsem si koupil od Pavla Satrapy starší knížku s názvem IPv6. Ta mi konečně rozšířila obzory na tolik, abych si udělal ucelený obrázek o tomto protokolu, a odpoutal se od jeho nejčastějšího popisu: "je to IPv4 s více adresama".

Myslím si, že IPv6 by se mělo pomalu začít prosazovat. To co tomu podlemě nejvíce brání je zarputilost správců opustit snadno zapamatovatelné IPv4 adresy. Bohužel za tím stojí neznalost tohoto protokolu, který se snaží od tohoto odstínit uživatele bezstavovou konfigurací všeho možného (zejména tedy adresy rozhraní a DNS).

Nejsem žádný v6 fanatika z NATu kopřivku nemám. Jen mi na NATu vadí, že je to silně nesystémové řešení, a ještě víc mě vadí lidé, kteří to dokonce považují za klad.

[thingie]

Ale tak základní charakteristika IPv6 je skutečně prostě IP s více adresama Jinak má samozřejmě spousty velmi zajímavých vlastností, ale... některé nejsou ani konečné, implementace jakbysmet, jsou-li vůbec. A to všechno nad IPv4 vykouzlíte taky. Konfigurace si myslím nebude ten hlavní problém.

[Ondrej 'SanTiago' Zajicek]

Me zejmena prekvapuje ta firewallova obsese. Podle me bezny uzivatel firewall k nicemu nepotrebuje. A i kdyby ho potreboval, tak by ho neumel nastavit. Pokud na portu nic neposloucha, tak je celkem jedno, jestli je za firewallem nebo neni.

[Luk]

Tohle je právě jedna z rozšířených chyb. Běžný uživatel totiž většinou vůbec neví, co mu tam běží a na kterém portu to poslouchá. Takže ani nemusí vědět o tom, že mu tam někdo dělá něco nekalého.

Typickým příkladem byl červ MSBlaster. Ten využíval díry ve windowsové implementaci RPC. Kdo měl firewall (nastavený tak, že blokoval vše kromě explicitně povolených portů), nijak ho to neohrozilo. Zbývajících mnoho milionů počítačů po světě bylo červem napadeno. Na vině byl sice Microsoft (jak v tom, že spáchal zmíněnou chybu, tak proto, že zbytečně běžela služba, která se nepoužívala), ale firewall systém ochránil.

[Ondrej 'SanTiago' Zajicek]

Coz ovsem ukazuje, ze firewall je jen berlicka - spravne reseni je nastavit danou sluzbu tak, aby byla dostupna jen z localhostu. Mozna by misto uzivatelsky pratelskeho firewallu byl praktictejsi uzivatelsky pratelsky program ukazujici a konfigurujici poslouchajici sluzby.

[Filip Jirsák]

Jenže to nebyla zásluha firewallu, že systém ochránil. Služba byla náhodou děravá, náhodou běžela, a firewall náhodou příslušný port blokoval. Kdyby např. firewall port neblokoval, ale služba neběžela, taky se nic nestalo. Ale hlavně to vše bylo „náhodou“, nikoli záměrem uživatele.

[Vskutečnosti Saýc]

Na tohle tema mel fefe pomerne zajimavou stranku: http://www.fefe.de/pffaq/

[zde]

Téměř vždy s Felixem souhlasím, ale tohle je jedna z mála věcí kdy bych se hádal. Pokud daná černá skříňka (Windows) obsahuje službu (RPC), která má bezpečnostní díru, nejde opravit ani vypnout, je její zafiltrování účinnou ochranou, a je úplně jedno jestli to udělá router nebo osobní firewall. Jistě, je to jen berlička, neřeší příčinu, ale může pomáhat. Proto bych lidem co ji použijí neříkal idioti.

[David Jaša]

Ty krabičky mívají v sobě stavový firewall už teď (protože bez něj nejsou firewallem). Nechápu, v čem je problém, když odpadne nutnost NATu.

[tezkatlipoka]

zajimave ze i kdyz to nemaji cist lidi kteri maji koprivku z NATu, tak ti se na to hned vrhnou

1/ pro me za me muzu prejit hned, nahodim na routerech na verejne strane IPv6 adresu, a vnitrek si pojedu v4, hotove za par minut, vnitrek prejit na v6 muzu pak v klidu kdykoliv nebo taky nikdy (cert vi jestli to umi vsechny tiskarny, apod.). A lidem u nas by to stejne nic neprineslo (delsi popis).

2/ jestli se to neprosadilo za 10 let existence, neprosadi se to nikdy, spis prijdou s nejakou dalsi berlou, ktera bude zpetne kompatibilni s IPv4.

[Michal Vyskočil]

Pokud někdo napíše, tento zápisek nečtěte, tak jistě počítá s tím, že si ho lidé přečtou. Říká se tomu psychologie

[tezkatlipoka]

hlavologie

[Luboš Doležel (Doli)]

Mám obavy, že bude zapotřebí zahájit nějaký tlak zezhora. Tedy přestat přidělovat jakékoliv další bloky IP adres a začít zavádět "expiry dates" - tedy kdy jaké (již používané) bloky IPv4 adres zase odeberou. To by mohlo zabrat rychle

[tezkatlipoka]

tlak bude, ale trochu jinej.

1/ tlak na zrouty IP aby je pustili do placu /HP, apod./

2/ tlak na poskytovatele aby je nedavali kazdemu pro srandu kralikum

3/ zdrazeni IP adres, tim se presunou do firemniho prostoru, IP za 5.000 si kazdej domu neporidi

4/ rok 2020, ptame se jakze to vlastne bylo s tim IPv6

5/ rok 2022, Microsoft tlaci na zavedeni IPv6, dochazeji IP adresy pro lednicky

6/ rok 2023, predstaven IPv8, struktura IPv6 je zastarala, a jeji nasazeni zbytecne

7/ rok 2024, ve verejne drazbe prodana posledni IPv4, IP adresa na zlato

8/ rok 2028, zavedeno uplne neco jineho

[Michal Kubeček]

V čem konkrétně si představujete, že by se IPv8 lišil od IPv6?

[tezkatlipoka]

myslim ze to neni dulezite, podstatne jsou pouze prvni tri body, ktere podle mne nastanou.

PS coz by mel pochopit kazdy kdo dneska nevstal levou novou napred

[Filip Jirsák]

Přitom body 2) a 3) znamenají rozšiřování NATu. To by se brzy mohl začít vymýšlet nějaký protokol na kontaktování počítače za NATem z vnějšku. Nějaké reverzní SOCKS proxy. Ach jo. Proč se poslední dobou tak množí „řešení“, které místo průběžného prosazování nového standardu upřednostňují prosazování nějakého rádoby zpětně kompatibilního bastlu, kterému se stejně musí vše přizpůsobit? HTML5 místo modulárního XHTML (nebo něčeho jiného postaveného na XML), AJAX místo tenkých klientů, NAT místo IPv6…

[Michal Kubeček]

Protože je tu řada dost vlivných firem, které mají na realizaci takových "řešení" postaven velice úspěšný byznys. A ty nemají nejmenší zájem na tom, aby tato "řešení" byla nahrazena řešením skutečným, které by navíc bylo daleko jednodušší a praktičtější.

[tezkatlipoka]

to ale neni otazka jenom IT. To se deje vsude. Dulezite preci neni ani jednoduchost, spolehlivost, šetrnost, dulezity je zisk. V kapitalismu vse ridi bohate firmy, v komunismu nedoukove lumpen proletariatu. Ja fakt nevim kde bych chtel bydlet.

[Filip Jirsák]

Tohle vysvětlení bych ještě bral, aspoň by bylo jasné, kde je nepřítel. Ale já si nejsem jist, že je správné. Které vlivné firmy staví úspěšný byznys na implementaci NATu a implementaci jeho obcházení? Které na implementaci AJAXu? Velké firmy se toho podle mne chytnou až když už o tom mluví každý a když je "ostuda", že to také nemají. Ty, kterým to vyhovuje, jsou zpravidla menší firmy, které na tom ovšem staví byznys krátkodobě, a po několika letech je převálcuje jiná módní vlna. Je třeba vlivná firma Skype, který se prosadil asi mimo jiné proto, že si dokáže poradit s NATem?

[Michal Kubeček]

Třeba Cisco je ve svém oboru hodně významná firma a jejich negativní postoj k přechodu na IPv6 je IMHO dost dobře čitelný.

[Filip Jirsák]

Může být. I když Cisco samo by asi nic nezmohlo, pokud by jiné významné firmy IPv6 naopak prosazovaly. Přitom těch prachů, co by zrovna Cisco mohlo vydělat prodejem nových zařízení pro IPv6…

[tezkatlipoka]

pokud prechod moc poleze do penez, zase se na to vyflaknou odberatele.