Vlákno názorů k článku Homenet: IPv6 v domácích sítích od Petr Holý - Nabídnu Vám jeden argument, který tady nezazněl... nejspíš...

mno ...jak u blbejch na dvorečku že :)

Mate pravdu. Je to hrozne. Nekolik lidi si mirne plete funkcionalitu prekladu adres a firewallu. Ale hodne ze zbytku je tolerantni a trpelive jim vysvetluje rozdil.

... a dal uz krmit trolly nebudu :-)

No kde je tu troll to je opravdu kardinální otázka :)
1) Já píšu : "Mno jeho NAT/PAT/FW domácí krabička to na 99,99% zahodí :)"

a odpověď je "Ne, NAT/maškaráda toto nezahodí"

2) Ukažte mi jedinou SOHO krabičku určenou pro BFU která obsahuje výhradně NAT

pak se můžeme bavit o tom kdo je tady troll

BTW: Nakrmte Krska :)

„a odpověď je "Ne, NAT/maškaráda toto nezahodí"“

NAT obecně žádné filtrování neprovádí.

IP maškaráda (jako speciální případ NATu) obecně rovněž žádné filtrování neprovádí, nicméně má někdy problém zjistit, kterému stroji daný paket doručit.

Výše uvedená vlastnost maškarády lze chybně využívat jako náhradní bezpečnostní mechanismus. Tedy použití IP maškarády místo firewallu
*snižuje* bezpečnost oproti standardní situaci, kdy se používá firewall.

Ve výsledku nás tedy nedostupnost IP maškarády v běžných implementacích IPv6 připravuje o možnost zhoršit zabezpečení sítě
spoléháním na vedlejší efekty maškarády.

A že IPv6 přináší spoustu problematicích věcí, toto mi přijde z hlediska
bezpečnosti jako téměř jednoznačný plus.

„No já nevím. Já tady trpělivě pročítám diskusi ve které je tisíckrát omleto "jestli si myslíš, že přes NAT zvenku neprolezu, tak jsi na omylu" a celou dobu čekám na věrohodné vysvětlení, jak je toto možné.“

A přitom se ti to za tu dobu již nejméně tisíckrát stalo, že nějaká služba odeslala data skrze NAT na tvůj počítač.

Nehledě na to, že jediným smyslem NATu je právě umožnění komunikace, která by bez něj byla implicitně zablokovaná absencí záznamů ve směrovacích tabulkách routerů.

„Shrnuto: Nebylo by od věci, kdyby ti "trpělivě vysvětlující" s tím vysvětlováním začali, řekněme, o 50 příspěvků dříve. Ušetřilo by to dost času jak diskutérům, tak čtenářům...“

Už se stalo.

Mno řekl bych že pouze nerozumí těm kecům zdejších IPV6-pošahaných rádobyodborníků, kteří na základě toho, že za jistých velice specifických okolností (veřejné adresy na stejné linkové vrstvě) lze navázat komunikaci se zařízením umístěným za !!!!HOLÝM!!!! NATem (opět v kontextu článku pod nímž diskutujeme prakticky neexistující situace) a díky tomu prohlašují věty

"Zadruhe, zkuste si trebas mojeip.cz a pod - pokud mate zapnute scriptovani, zjisti vasi interni adresu, coz muzu obratem vyuzit k tomu, ze na vas nat poslu paket s presne touto adresou a vite vy co stim vas NAT udela? Nj, jako spravny router to odroutuje => prave sem zvenku navazal spojeni s vasim vnitrnim strojem, to je co? Mate zapnute windowsi sdileni jako kazdy spravny BFU? Fajn, du se podivat co mate na disku"

Takže sem nepište když lžete!

Obvious troll is obvious.

Pak jsou mnohem lepší metodou skromně napsané dotazy než velkohubá prohlášení.

„Shrnuto: Nebylo by od věci, kdyby ti "trpělivě vysvětlující" s tím vysvětlováním začali, řekněme, o 50 příspěvků dříve. Ušetřilo by to dost času jak diskutérům, tak čtenářům...“

Bohuzel pokud se podivate na fungovani prekladu adres a prislusne RFC, tak uz to samo je technicky argument.

Tak NAT ochranou není a ani nemůže být, když je to technologie, která pouze zpřístupňuje spojení, která by bez něj nešla uskutečnit.

Technické argumenty chybí pouze těm, kteří nejsou ochotni je vidět.

Tak třeba předpokládejme, že jste soused, kterému se chci dostat za NAT/PAT krabičku. Vy máte veřejnou IP adresu ze stejné sítě jako soused, který dělá NAT. Což je u sousedů asi celkem častá situace. Pak prostě pošlete paket s cílovou adresou v jeho privátní síti na jeho krabičku (zdrojová bude vaše veřejná). NAT/PAT krabička bez firewallu tento paket standardně propustí na druhou stranu. Odchozí paket od vnitřní IP adresy už se přeloží, ale to už nevadí, komunikace nyní bude probíhat na přeložených IP adresách.

To je ta nejjednodušší metoda. Existují i komplikovanější příklady, které využívají vlastností některých NAT/PAT krabiček (connection tracking tabulka není úplná).

Až na to že "NAT/PAT krabička bez firewallu", vlhký toť sen všech IPV6-Jasánků, je něco jako žena inspektora Colomba o které se neustále mluví, ale nikdy ji nikdo neviděl..... :D

Já bych řekl, že je to standardní nastavení. Alespoň u krabiček, které jsem viděl.

A maj ty krabičky nějaké označení ? Nebo si zase jenom cintáš pentli....

dva háčky jsou jednoduše řešitelné - popisované řešení samozřejmě nefunguje na standardním TCP/IP stacku. Musíte to trochu umět, abyste mohl takto útočit. Není to pro úplného BFU, pokud nemá už připravený nějaký program, který to umí.

ad 2. conntrack SYN flag obvykle nezajímá.

NAT není firewall. Co tady někteří tvrdí je ovšem to, že NAT firewall je nebo se tomu svými vlastnostmi velmi blíží, což ostatní rozporují.

Je otázka, jestli by to troubovi na něco bylo.

Dobře, to je zisk pro vás. Jaký je zisk pro toho, kdo by to předváděl?

zajímavá výzva. Ozvu se.

Budu rád, když se ozveš i mně :).

Popis provedeného stažení souboru si můžete přečíst tady: http://uloz.to/xZDCzSt/nat-lupa-zip

(jsou tam i tcpdumpové soubory)

Pokud se vám to podaří reprodukovat (což by neměl být problém), tak zmíněnou částku prosím pošlete na bankovní účet fondu ohrožených dětí. http://www.fod.cz/

Bych řekl, že většinu lidí spíš zajímalo, jak tohle provedeš obecně komukoliv. Pro jednoduchost řekněme, že routovaná síť mezi útočníkem a routerem neklade žádné překážky žádným paketům.

To, že si každý myslí, že NAT je firewall má své opodstatnění. Nikdo (asi krom diskutujících tvrdících opak) si pod tímto pojmem nepředstavuje čistý NAT, ale PAT. A ten není realizovatelný bez něčeho typu conntrack tabulky, tedy v podstatě stavového firewallu. Udělat pravidlo related,established na forwardu nic nestojí.

S TP jsme se bavili konkrétně o této situaci.

Pokud jste četl ten dokument, tak tam je jasně ukázané, že jednoduchost toho přístupu spočívá právě v existenci connection trackingu a toho, že POSTROUTING chain se v tomto případě neuplatní. (A není to čistý NAT, ale to pravidlo je PAT - mapuje se 1:N)

Já tomu rozumím. Ale čemu nerozumím je, proč by v těch krabičkách nemělo být iptables -A FORWARD -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT a následně drop z eth0.
Tím samozřejmě netvrdím, že je znám všechny :-) a ani mě nenapadlo je zkoumat ...

Ale toto už je ochrana firewallem, nikoliv NATem. Tato ochrana bude fungovat i v případě, že tam budete mít normální nenatované adresy.

Je tam tak trochu ďura v tom, že nedokážete zjistit tu adresu za tím NATem a možných rozsahů je docela dost 192.168.x.x nebo dokonce 10.x.x.x ,
Z mého pohledu tedy odhad není možný, a to zjištění přes javascript je také pouze hypotetická možnost. Dál to podmiňujete připojením do stejného segmentu. Takže u mne máte z DÚ 4- a měl byste to dopracovat.

To je jak kdybyste tvrdil, že nemusíte mít zabezpečený barák, protože zloději to k vám mají daleko a sousedi nekradou.

Z vašeho pohledu odhad není možný, reálně když zkusíte všechny adresy z 192.168.[01].[0-9], ve spoustě případů se trefíte. Třeba na budování botnetu to bohatě stačí.

Nikoli, špatná je vaše analogie. Počítače sousedů na stejném segmentu rozhodně nejsou hlídané policajty. Naopak je dost pravděpodobné, že se mezi těmi sousedy vyskytují počítače, které si spravují samodomo administrátoři, pro které používat účet s nižšími právy nebo heslo je zbytečné zdržování, kteří musí vyzkoušet každý program, na který na internetu narazí – a dané počítače sousedů jsou pak pěkné ZOO.

Ano, jeden počítač v segmentu pak musí být napaden jinou cestou, než skrze NAT bez FW. Ale pak už se můžete v rámci segmentu snadno dostat z jednoho počítače na druhý. Takto budovaný botnet nebude malý – když z každého počítače napadeného virem ovládnete 5 dalších počítačů ve stejném segmentu, získáte šestkrát větší botnet, než jenom při napadení virem.

Opravdu věříte všem sousedům na stejném segmentu sítě, že mají dobře zabezpečené počítače?

Navíc prostřelení NATu ze stejného segmentu sítě je jen ta nejjednodušší možnost, ale zdaleka není jediná.

Jinak rozumně nastavený firewall od výrobce není potřeba vypínat, protože blokuje jen služby, o kterých se ví, že nejsou určeny ke zveřejnění (např. sdílení souborů v lokální síti Windows). Blokovat veškerou komunikaci a explicitně některé služby povolovat je pro bezúdržbový firewall nesmyslné nastavení.

Diskuse začínala tím, že NAT přináší určitou bezpečnost, tudíž domácí síť s veřejnými IPv6 adresami bez NATu bude nezabezpečená. Když to spojím s vaším tvrzením, že v realitě se dnes pro IPv4 zpravidla vyskytuje kombinace NAT+FW, kde NAT nemá bezpečnostní funkci, dostáváme se konečně k tomu, že odstraněním NATu se bezpečnost nijak nesníží.

Rozumně nastavený FW nemá blokovat nic, o čem neví, k čemu to je. Klasické SOHO firewally mají jedinou bezpečnostní funkci – očekávat, že za nimi je děravý nebo špatně nakonfigurovaný software, u kterého není jiná možnost, než komunikaci zastavit dřív, než se k tomu software dostane. Správné řešení je tedy opravit ten software. Jinými slovy – až Windows v základním nastavení nebudou děravé, SOHO firewally vůbec nebudou potřeba. Než toho MS docílí, stačí, aby firewally blokovaly ty notoricky známé notoricky děravé služby. Nic víc od nich není potřeba. Pak samozřejmě nikdo nebude mít důvod takový firewall vypínat a příchozí komunikace bude fungovat, tak jak má, tedy bez nějakého nastavování.

Pokud musí neznalý uživatel přenastavovat NAT, má samozřejmě spoustu možností, jak to zkazit. Velice snadno může bezpečnost snížit – na firewallu může mít zakázaný přístup z venku k domácímu NAS, ale přes NAT ho omylem otevře světu.

>"Diskuse začínala tím, že NAT přináší určitou bezpečnost, ..... že v realitě se dnes pro IPv4 zpravidla vyskytuje kombinace NAT+FW, ......dostáváme se konečně k tomu, že odstraněním NATu se bezpečnost nijak nesníží."

Mno diskuze myslím začínala především tím, že "jakmile odstraníme díky IPV6 zlý a ošklivý NAT který žere matky i s kočárkem, budou mít BFU naprosto pohodový život, protože jim bude bez nějakého otravného nastavování hned fungovat end_to_end komunikace"

Takže buď bude end-to-end komunikace fungovat bez nastavování a pak nebudou BFU chráněni, nebo budou chráněni firewallem a budou stejně něco muset nastavovat.
Takže jako obvykle přechod na IPV6 nebude v zásadě přinášet nic převratného.

End-to-end komunikace samozřejmě může fungovat bez nastavování. Ochrana uživatele nespočívá v tom, že úplně zbytečně zablokuju veškerou komunikaci, ale v tom, že zablokuju komunikaci špatně navrženými protokoly a na špatně navržené programy. Jejich seznam je všeobecně známý a vývojáři už snad budou natolik soudní, že se nebudou masově šířit nové špatně navržené protokoly a aplikace.

Těch služeb, které uživatel může potřebovat, je spousta. Akorát dnes kvůli NATům nepoužívají nejpřirozenější přímé spojení, ale místo toho se používají různé obezličky se zprostředkujícími servery.

Před čím podle vás FW chrání uživatele? Když vynecháme notoricky známé hloupé protokoly z rodiny sídlení disků Windows. Stává se, že je v aplikaci (třeba MS Wordu) omylem naprogramovaný síťový server? Pochybuju. Stává se, že by si uživatel omylem nainstaloval síťový server? Taky těžko. Takže zbývají síťové servery, které má uživatel nainstalované a spuštěné záměrně – třeba kvůli IM, sdílení fotek přátelům, telefonii, apod. Jenže když je má nainstalované záměrně, bude je mít povolené i na firewallu. Takže před čím bude firewall uživatele chránit?

Firewall, který nespravuje někdo, kdo jeho správě rozumí, je prakticky k ničemu. Nejlepší firewall pro SOHO tedy bude takový, který nikdo nikdy nebude muset konfigurovat. Takže žádný hodně restriktivní, naopak co nejméně omezující. Pokud nebudou Windows v základním nastavení spouštět žádné síťové služby, tak můžeme SOHO firewally rovnou škrtnout.

U všech těch dalších zařízení, která jste jmenoval, je správně, že budou dostupná z jiných sítí. Uživatel to očekává. Uživatele se chce k svým filmům v DVB-T nahrávači dostat, ať už má zrovna notebook do domácí sítě připojený kabelem a nebo přes WiFi – jeho nezajímá, že je to pokaždé jiná síť. Stejně tak si ledničku s možností podívat se kdykoli přes mobil dovnitř nebude kupovat proto, aby se pak dovnitř díval z pevného počítače doma v kuchyni… Ano, dostupnost těchhle zařízení z celého internetu na ně bude klást trochu vyšší nároky, jenže jejich dostupnost odkudkoli bude velká konkurenční výhoda.

To je úplně stejný argument, jako že uživatel očekává, že se někdo dostane do jeho e-mailů nebo do jeho bankovnictví. Neočekává, a taky se to neděje – není důvod, proč by se něco takového dělo.

Na příkladu mnoha služeb je zřejmé, že zabezpečení je technicky možné a snadné na implementaci (implementují se daleko složitější věci, třeba ta zařízení mají AJAXovou administraci – proti tomu je implementace zabezpečení přístupu brnkačka). Když to zařízení bude umět IPv6, bude se nejspíš chlubit tím, že se k němu dostanete odkudkoli z internetu. A vzápětí se bude muset pochlubit i tím, jak je přístup zabezpečený.

Ostatně, dnes máte v kdejakém NAS nebo routeru pro SOHO možnost zapnout sdílení přes internet, konfigurovat VPN apod. Takže se ještě víc zpřístupňují i zařízení, která jsou podle vás „chráněná“ NATem. Akorát je ten NAT pro právoplatné uživatele zbytečná komplikace a vytváří falešný pocit bezpečí.

Všimněte si kolikrát jste použil slovo "bude" v souvislosti s imaginárními zařízeními pro IPV6....
Nicméně představa IPV6-Jasánků, že s příchodem IPV6 přeštanou být vnitřní sítě oddělené od internetu je směšná.
No a nejlegračnější je, že ve druhé části příspěvku víceméně přiznáváte, že dnes díky možnostem domácích "krabiček" lze také nakonfigurovat kdeco. Takže ten NAT vlastně nepřekáží.

Směšné je, jak tady nemožnost provozovat síť s veřejnými IP adresami vysvětlujete lidem, kteří takovou síť úspěšně provozovali nebo provozují.

Když NAT kromě nedostatku IPv4 adres nepřináší nic pozitivního, za to je nutné kvůli němu kdeco konfigurovat, znamená to, že NAT jenom překáží.

Mno tvrzení, že s příchodem IPV6 nepřeštanou být vnitřní sítě od internetu oddělené, nemá nic společného s tím, co je nebo není možné.
Nicméně domácí i firemní sítě v drtivé většině oddělené zůstanou a vůbec nic na tom nezmění zbožné přání několika hlupáků.

No vidíte, konečně jste napsal něco pravdivého.

Výborně...konečně jste pochopil. že IPV6 prakticky nikoho neosvobodí od nastavování pravidel pro příchozí komunikaci a že tím pádem tvrzení "NAT je zlý protože bez něho nikdo nebude muset nic pro end_to_end komunikaci nastavovat" je hovadina.....

Nojo no. co holt dělat, když dojdou argumenty že.....

Do not feed trolls

Už jste s tím trapnej....

Máte naprostou pravdu. Hádat se s dementními IPV6-Jasánky nemá pražádný smysl. Oni jsou totiž do toho svého IPV6-grálu, zahleděni a strašlivě je rozčiluje, že se v praxi se nikdo normální do implementace IPV6 nehrne a tak jsou ochotni si vymýšlet milión zhůvěřilostí,jenom aby tu "potřebu" přechodu na IPV6 nějak zdůraznili, či vyvolali.
Nejlegračnější na tom je, že si kolikrát naprosto odporují a všimněte si, že jediné na čem se "točí" je právě to, že v každé takové diskuzi se propírá NAT podel následujícího scénáře:
1) Jasánci vyhlásí NAT za zlo které každého od rána do večera omezuje.
2) Obvykle se ozve někdo a (samozřejmě částečně chybně) prohlásí NAT za bezpečnostní prvek.
3) Následuje dehonestace všech odpůrců IPV6 páč to jsou lamy, které nevědí že NAT není firewall s výhružkou, že přes holý NAT projdou kdykoliv kamkoliv s prstem v nose.
4) Na námitku, že NAT bez FW se ve skutečnosti málokde najde přejdou k bodu 3

Nejvíc mne dostala diskuze s jedním podobným dementem, který mi na můj post, že NAT mi pro připojování vzdálených pracovníků do firemní sítě vůbec nevadí protože je připojím přes VPN odvětil, že jemu to nikdy nefungovalo protože firemní sítě, odkud se mimo jiné je potřeba také připojit, obvykle blokují odchozí provoz na nestandardní porty. Když jsem mu opáčil že od toho jsou tu SSL VPNky fungující přes port 443 mi začal tvrdit, že většinou je blokován i port 443. Ale už mi vůbec nedokázal vysvětlit, proč by správce sítě, který blokuje odchozí komunikaci i na portu 443 zrovínka po přechodu na IPV6 měl firewall otevřít pro sdílení souborů nebo pro RDP, když předtím blokoval i SSL.

Skutečně to nemá smysl......je to stejné jako se hádat z fanatiky o globálním oteplování...­..prostě tomu věřej a to je jejich "pravda"

do not feed trols

Otázka je, co dělat, když se trollové krmí navzájem :).

>"....ale vy se na nej nepripojite, neb je nastaveno jen pro vybrane adresy..."

mno myslím že říct to tady já jako obranu IPV4 tak zde okamžitě přistane návod jak mi to FTP pomocí ip spoofingu lze vykrást (a ani by to nemuselo být ze stejného veřejného segmentu sítě)
Ochrana pomocí přístupu z vyhrazených IP adres je zhruba stejně účinná jako holý NAT.

Pokud tedy cílem akce je mít doma anonymní FTP přístupné z vnitřní sítě, pak je ochrana NATem mnohem účinnější než Vaše ochrana vybranými IP adresami.

Prostě se smiřte s tím, že oddělení vnitřní sítě od internetu bylo, je a bude vždy žádoucí. A nic na tom nezmění ani IPV6xyz.

Naštěstí to nebyl úkol od vás, ale od TP. Takže víte co mi můžete...

No a jestli neumíte spustit nmap, tak to je váš problém.

nápodobně......

Super, tak alespoň něco pozitivního z této diskuse je :-)

Jinak musím přiznat, že jsem s tím zařazením do conntrack tabulky taky nepočítal. Ale z hlediska ustavení spojení je to logické. Navíc NAT krabička nemůže modifikovat porty ani IP adresy žádnému než prvnímu paketu spojení (jinak by to nefungovalo).

Ale i v případě, že by se ty IP adresy a porty změnily, tak jsem chtěl využít jednoduchého hacku právě s mangle table. Nastavil bych jednoduché logovací pravidlo na pakety přicházející od NAT krabičky, logovací hlášku při příchodu odpovědi bych zpracoval tak, aby se do mangle table to pravidlo přidalo. Při následné retransmisi by už bylo na místě a tím pádem by to prošlo. Ale určitě existují i mnohem elegantnější řešení, jako třeba modul do netfiltru, který by modifikoval hned první příchozí paket. :-) (ale toto už je na mne příliš vyšší dívčí)

To je jenom jeden z nejsnáze pochopitelných příkladů obcházení NATu. Existují složitější metody, ale chtěl jste alespoň nějakou - já jsem uvedl nejtriviálnější, nehodlám tady sepisovat desetistránkový odborný text.

Co se týká chyb konkrétních implementací - není to tak jednoduché. Popisované connection tracking je náročné na paměť, takže omezením některých polí v conntracku dostanete přibližně stejné vlastnosti za nižší cenu. A to se počítá.

„V tom případě nejde o zranitelnost technologie, ale o chyby v konkrétních implementacích.“

Chybu v implementaci je potřeba nejprve popsat a alespoň rozumně dokázat. U obecného překladu adres je to prakticky nemožné, protože chybou by byl především nefunkční překlad.

Vzhledem k tomu, že překlad neslouží k zablokování provozu, ale naopak k zajištění provozu, který je jinak implicitně znemožněn, to budeš mít opravdu těžké.