Tak zaprve, i kdybych znal seriova cisla vsech HW komponent, tak to z pravniho hlediska neznamena absolutne vubec nic. Maximalne tak zjistim, na koho je uzavrena smlouva s ISP, pripadne komu ten HW patri.
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.
Zatreti, privacy extensions tu uz zminovany jsou taky. Klido muzete mit jinou IPv6 adresu co minutu.
Výborně, takže zkuste být prosím konstruktivní a poučit mne technicky neznalého.
Chcete identifikovat konkrétního koncového uživatele a konkrétní zařízení. Jste v internetu a víte, že ten dotyčný sedí za natem, dohledáte vnější IP natu, jak určite ze své pozice konkrétní koncové zařízení v síti mající náhodou rotující DHCP adresu např. 192.168....?
Povšimněte si prosím rovněž, že identifikace uživatele je argument právní, nikoliv technický. Nehovořím o jeho loginu, ale o jeho osobní identitě. IPV6 adresa je formálně svázána dle s konkrétním HW, natovaná adresa nikoliv myslím.
>> Ale hodne ze zbytku je tolerantni a trpelive jim vysvetluje rozdil.
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é. Takže po cca 50 příspěvcích ala to v uvozovkách je tady o kousek výš konečně jeden, který *vysvětluje*.
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...
>> na vas nat poslu paket s presne touto privatni adresou
Jak se to prakticky udělá? Jak na zařízení s IP adresou IP1 doručím paket s cílovou adresou IP2 (IP1 <> IP2)?
Nejsem žádný znalec protokolů, ale nemůžu vymyslet nic jiného, než to vzít po linkové likové vrstvě (sestrojím paket s adresou IP2 a pošlu ho sousedovi, který má adresu IP1). To ale moc zneužitelné není - málokdo je můj soused na linkové vrstvě...?
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á).
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á.
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í.
OK... tak tedy zisk, pokud je pocit zadostiucineni nedostatecny, tak ten kdo to nazorne predvede dostane 2000 Kc na ruku + se muze pochlubit v nejakem clanku jak je dobry. Kdyz tvrdite, ze je to jednoduche tak to jiste nebude problem.
NAT(PAT) realizovany prostrtrednictvim iptables v linuxu s jedinym pravidlem realizujici praven onen nat (pripadne na jinem zarizeni dle dohody). Ukol lze povazovat za splnen v pripade, ze se vam podari prekopirovat soiubor z PC, ktere je umistene za onim NATem.
Provoz a cely utok bude odchycen tcpdumpem pro dalsi analyzu.
„Povšimněte si prosím rovněž, že identifikace uživatele je argument právní, nikoliv technický.“
Identifikace uživatele jako právní úkon nelze provádět pomocí IP adresy.
„IPV6 adresa je formálně svázána dle s konkrétním HW, natovaná adresa nikoliv myslím.“
Tento rozdíl mezi IPv4 a IPv6 neexistuje v obou protokolech je možné obojí.
„Nat umožňuje zabránit fyzické identifikaci konkrétního koncového zařízení...... resp. konkrétního koncového uživatele....“
Kdyby toto NAT dokázal, tak by se nejspíše dodával jako služba v řádu alespoň tisíců měsíčně. Nicméně tento váš názor je velmi nebezpečný
a dovolím si vás varovat před úmyslem na tuto domnělou vlastnost IPv4 NATu spoléhat.
„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.
Ondřej Bouda napsal:
"Jak se to prakticky udělá? Jak na zařízení s IP adresou IP1 doručím paket s cílovou adresou IP2 (IP1 <> IP2)?
Nejsem žádný znalec protokolů, ale nemůžu vymyslet nic jiného, než to vzít po linkové likové vrstvě (sestrojím paket s adresou IP2 a pošlu ho sousedovi, který má adresu IP1). To ale moc zneužitelné není - málokdo je můj soused na linkové vrstvě...?"
Co z toho je podle pavlix.net velkohubé prohlášení?
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í.
Krá krá, Uložto nevrmór. http://jenda.hrach.eu/f/nat-lupa.zip
Ano, takto vytržené z kontextu to velkohubě vyznívá. Jenže kontext je ten, že diskuse je zaplevelená hádnou "NAT je ochrana" versus "NAT není ochrana", ve které chybějí technické argumenty. A pak někdo napíše, že tady strana "NAT není ochrana" "celou dobu trpělivě vysvětluje".
Je mi líto, ale tak to prostě *není* :(
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čí)
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í.
Dobře, to je další faktor. V mé analogii to znamená, že do té ulice běžně a bez povšimnutí proplouvají zloději po střechách. V takovém případě ovšem nestačí mít na dveřích dobrý zámek, ale je nutno dát i mříže na okna, protože jinak ke mě zloděj přeleze od souseda oknem :)
To už se ale dostáváme dost jinam: od teoretické otázky, zda NAT má/nemá vlastnosti bezpečnostního prvku, k praktické otázce po bezpečnosti celého řešení vnitřní sítě. Např.: Pokud mám zapnuté aktualizace, tak se ze mě zombie nejspíš nestane => je ve hvězdách, zda/jaký efekt by pokus o rozšiřování botnetu skrze nedostatečnost NATu v praxi měl. Nehledě na to, že jakmile začneme brouzdat do reality, tak realita je, že NAT bez FW bude hodně vzácný.
>> rozumně nastavený firewall od výrobce není potřeba vypínat
Rozumně nastavený FW od výrobce by měl blokovat veškerou "neočekávanou" příchozí komunikaci - stejně, jako to ve většině případů dělá (z principu) NAT. A teď jsou dvě možnosti:
A) BFU příchozí komunikaci nepotřebuje (a pak je jedno zda jen FW nebo NAT+FW),
B) BFU příchozí komunikaci potřebuje => musí něco přenastavit.
A můj postřeh je, že dokud musí BFU přenastavovat NAT, nemá jinou možnost, než to nastavit správně => bezpečnostní prvek zůstane zachován (a to nejspíš včetně FW, když už jsme u té reality). Jakmile ale bude ke zprovoznění toho, co potřebuje, stačit vypnout FW (protože žádný NAT nebude potřeba), půjde nemalá část BFU cestou nejmenšího odporu. Tím jsem si jist, protože nebezpečných rad už jsem v nejrůznějších diskusích viděl mraky - a to, bohužel, včetně programátorských diskusí (kde bych očekával alespoň základní povědomí o bezpečnosti!). Přičemž tragédie těch diskusí nespočívá v tom, že někdo nebezpečnou radu dá, ale v tom, že za ni mnoho čtenářů děkuje slovy "works like a charm! and now also works XY!".
Přiznávám, že to je argument víc psychologický než technický. Jsem ale toho názoru, že selhá-li technické řešení na psychologickém faktoru, je to řešení technicky chybné. Protože technologie mají být vyvíjeny pro lidi... :)
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.
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.
Ach jo :(
Pokud se chcete bavit o ideálu, jak by to mělo být, tak ano: správná cesta je opravit všechny díry v SW. Ó jak se těším na tu dobu zaslíbenou, kdy všichni budou mít Wokna legálně, aby se nemuseli bát zapnout aktualizace. Kdy bude i veškerý ostatní SW trvale udržovaný (tzn. vývoj/podpora nebude ukončena), neustále testovaný na odolnost proti novým trikům a bezpečnou cestou automaticky aktualizovaný. Kdy bude vše dokonale odladěno a nebude se tudíž stávat, že by něco po nějaké aktualizaci přestalo fungovat.
Ale jak už jsem psal: řešení, které nezapočítává lidský faktor, je *chybné* :(
Takže zanechme iluzí a pojďme se bavit o tom, jak to *reálně* může fungovat. Reálně SW u BFU z mnoha příčin děravý bude a právě proto musí být "krabička" do domácnosti nastavena tak, aby děravý SW chránila. Přičemž výrobce nedokáže předem určit, čemu všemu je třeba bránit a automaticky aktualizovat nastavení krabiček je utopie. Takže zbývá cesta whitelistu: určit, co BFU může potřebovat (toho je poměrně málo a moc se to nemění - většina služeb pro BFU je stejně na http) a vše ostatní zakázat.
Souhlasím s tím, že pokud má neznalý uživatel nastavovat NAT, má možnost to zkazit. Rozeberme si to: má možnost to zkazit tak, že mu přestane jít net. Má možnost to zkazit tak, že net mu dál pojede, ale nepodaří se mu zprovoznit to, o co se původně snažil. A konečně má možnost kromě toho, co zamýšlel, zveřejnit i něco jiného. Ten třetí případ mi přijde nejméně pravděpodobný - a v těch prvních dvou případech to vyřeší tím, že si sežene někoho, kdo mu to zprovozní (a v lepším případě i opraví ty chyby, co tam BFU napáchal).
A teď si to pojďme srovnat se situací, kdy tentýž uživatel nastavuje FW. Předchozí tři možnosti zůstávají, ale přibývá k nim ještě možnost čtvrtá - FW úplně vypnout. A tahle možnost má největší pravděpodobnost: pokud ji uživatel nezvolí rovnou, uchýlí se k ní ve chvíli, kdy ho ty pokusy nastavit to správně omrzí nebo kdy to zmrví tak, že mu net přestane jít.
Takže: Aby varianty NAT+FW a IPv6+FW byly stejně bezpečné, musí být výchozí nastavení FW hodně restriktivní a ty krabičky IPv6+FW nesmí nechat uživatele ten FW vypnout (nebo přidat pravidlo povolující vše apod.).
A opakuju: hodnotím to na úrovni započítávající psychologii (lidský faktor), nikoliv pouze na úrovni technické.
Tak s tou soudností vývojářů jste mě pobavil :)
Na silnicích taky spoléháte na soudnost ostatních řidičů, nebo radši počítáte s tím, že kdykoli kolem Vás může něco prosvištět sebevražednou rychlostí (a vzít Vás do věčných lovišť s sebou)? A to na té silnici mají lidé mnohem větší motivaci chovat se soudně, protože jim přeci jenom jde o krk.
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.
Netuším, jestli je možné, aby Windows v základním nastavení nespouštěly žádné síťové služby - ony se ty počítače v BFU síti přeci jen nějak domluvit potřebují. Ale dobře, řekněme že tyhle porty budou to jediné, co bude FW ve výchozím nastavení blokovat.
Jenže pak jsou tu různé aplikace ala webserver typu WebCamXP, které si BFU může zprovoznit např. jen proto, aby se mu povedlo správně naštelovat anténu (jako já - nějak jsem nezvládal koukat v kuchyni na TV a současně na půdě otáčet anténou). Opravdu má být každá taková aplikace automaticky přístupná zvenku?
No a pak tu máme síťové tiskárny a disky, wifi AP/routery atd., časem třeba dojde i ty ledničky a žehličky. Čili zařízení, u kterých BFU neví, že je potřeba nastavit/změnit nějaké heslo pro správu (a když už to ví, tak dá heslo typu "petr") a u kterých se často ani nepředpokládá, že by byla "naostro" dostupná z internetu. A i kdyby se to u nich předpokládalo, tak i firmware jenom SW, ve kterém jsou občas díry - a nelze očekávat, že by si BFU hlídal bezpečnostní aktualizace ke každému zařízení, které do sítě připojí (nebuďme naivní, on to nebude dělat ani u toho firewallu).
Takže: Opravdu trváte na tom, že vnitřní síť má být otevřená? Já s tímhle předpokladem prostě souhlasit nebudu.
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.
Jistě. Uživatel očekává, že mu někdo cizí vymaže všehny filmy v jeho DVB-T nahrávači a začne ten nahrávač používat jako server pro své vlastní účely. Uživatel očekává, že mu někdo zvenku přenastaví jeho WiFi AP na otevřené, takže "kolemjdoucí" mu pak ucpou linku. A samozřejmě taky očekává, že přes tu otevřenou WiFi se pak též všichni dostanou jak do jeho DVB-T, tak např. k nasdíleným souborům.
Ne, přijde mi, že tahle debata nemá smysl. Zjevně máme naprosto opačné priority - já chci BFU chránit jak před jeho, tak před cizí chybou; Vy chcete, aby se BFU dostal zvenku ke všem svým zařízením "ať to stojí co to stojí". Rozumná cesta bude samozřejmě v nějakém kompromisu, ale k tomu se -zdá se- nedokážeme dostat...
Ze vas to bavi ...
Osobne pristupuju k domaci siti jako k otevrenymu netu a kazdou privatni sitovou sluzbu resim FW jednotlivych stroju. Napriklad mi aktualne (na verejne adrese) bezi anonymni ftp, ale vy se na nej nepripojite, neb je nastaveno jen pro vybrane adresy.
Navic widle i kdyz derave, tak od XP vejs jdou celkem snadno zabezbecit bez instalace dalsiho mallware v podobe antiviru ci externiho firewallu. Staci na tom integrovanem zavrit vsechny porty. Jen me osobne proste vadi to, ze ty sluzby vubec (by default) bezi, protoze kdyby nebezely, netreba konfigurovat ten FW, nehlede na to, ze v principu muze dojit k prvnimu utoku jeste driv, nez to nastavit stihnu.
>"....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.
„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é.
Šmarjá, to je logika :(
Bezpečnost je implicitní požadavek na jakýkoli SW. To znamená nejen zpřístupnění, ale i rozumnou formu omezení. Jeden příklad za všechny: Pokud se kdokoliv bude moci podívat na Vaše bankovní konto, pak přece bude bankovní aplikace dělat to, co od ní chcete: zpřístupňovat Vám informace o stavu/historii Vašeho účtu - ne?
Čili NAT musí nejen spojovat, ale především spojovat *relevantně*. A k tomu patří i určitá míra filtrování. Jinými slovy: je-li filtrování příliš přísné nebo naopak málo přísné, lze to nazvat chybou v implementaci. Uf :(
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čí.
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!
Chápu to správně, že je nutné sousedství na linkové vrstvě? Tak to je okruh útočníků hodně omezený.
>> Existují i komplikovanější příklady, které využívají vlastností některých NAT/PAT krabiček (connection tracking tabulka není úplná).
V tom případě nejde o zranitelnost technologie, ale o chyby v konkrétních implementacích. Což je dost slabý argument, protože stejným způsobem mohou být zneužívány chyby v konkrétních implementacích FW (a nikdo mi nenamluví, že nic takového se v SOHO krabičkách nevyskytne).
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.
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áží.
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"
>"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.
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 :)
Nikolivek, ze 60% to vpohode projde, dalsich 20% by vyzadovalo delsi pripravu, ale proslo by taky. Drtiva vetsina krabek co maj lidi doma nema aktivni firewall pro forward.
Tudiz bezpeci za NATem je ciste iluzorni, a lidi jako vy by bylo treba zavrit pro obecne ohrozeni, jelikoz sirite tyhle bludy.
Pokud se nepletu tak tady nekdo poukazoval na to jak si zjisti privatni adresu a uz se mi pak bude za natem prochazet po sdileni. Rad bych to nekdy nazrone videl.
I v pripade uvedene situace, kdy jsem se svym sousedem v jedne podsiti si moc nepomuzu. Mohu sice do site poslat paket (predpokladejme napriklad SYN na port 22) a dostanu odpoved SYN+ACK na moji puvodni adresu. Ma to dva hacky:
1. Na strane prijemce bych mel prohazena cisla portu a IP adresy, takze regulerni TCP relaci z toho sestavim velice obtizne.
2. Pokud NAT funguje jak ma, tak jak tak onomu spojeni nepredchazi SYN zevnitr ven, takze v tabulce spojeni se nevytvori zaznam.
Podotykam, ze i kdyby se podarilo najit fintu jak toto obejit tak se stale bavime o pripade, ze jsem se svym sousedem na jedne podsiti. To je asi hodne daleko od toho co bylo puvodne prezentovano.
Co me ale zarazi, je fakt jak se tady do nekonecna omila jak NAT neni firewall a sotva nekdou poukaze na fakt, ze NAT ma jako vedlejsi efekt jiste bezpecnostni prvky tak se z nej udela totalni blb. Nikdo netvrdi ze NAT je firewall stejne jako nikdo netvrdi, ze chleba jsou rohliky. Nicmene oboji se da jist a jedno i druhe ma urcite vlastnosti.
Skoda je ze jsem takovy trouba, ze to neumim, ale nicmene pokud by se nasel nekdo kdo to, jak pisete, trochu umi a predvede mi ja si prochazi sdileni na zarizeni za natem tak bude mit muj velky respekt. Klidne mu k tomu poskytnu i prostredi na kterem to muze predvest. Myslim se vsi vaznosti.
Ten příklad máte špatně; správná analogie by byla: Ve dne v noci stojí na koncích ulice policajti a do ulice pustí jen toho, kdo tam bydlí (předpoklad stejného segmentu sítě). A já si dám do bytu jen jednoduchý zámek a ani nebudu zamykat (NAT bez FW). Pak ano, spoléhám na to, že sousedi u mě krást nebudou a nikdo jiný se do ulice nedostane. A přijde mi to vcelku realistické (ano, bude se to stávat - ale ta šance, že mě soused vykrade, je dost podobná šanci na výhru ve Sportce). Řekl bych, že rozhodně nebude větší než šance, že když nechám na ulici nastartované auto a jdu zavřít vrata do dvora, tak po návratu už tam to auto nebude (a světe div, zrovna tohle dělám docela často - kolikrát se ještě i pro něco vracím do baráku :)
Ad budování botnetu: takový botnet by byl dost malý, neb by se nedokázal šířit mimo daný segment. Navíc je tu pro pachatele mnohem vyšší riziko postihu, než když bude budovat botnet ze zahraničních kompů.
Mně z toho pořád plyne, že NAT sám o sobě bezpečnostním prvkem je: sice není neprůstřelný, ale šanci na útok snižuje o několik řádů. Co se týče SOHO krabiček, může to být významný bezpečnostní prvek v tom smyslu, že BFU klidně vypne FW, aby mu začalo něco fungovat (neb to bude jednodušší a univerzálnější, než konfigurovat potřebná pravidla - a rada "vypni FW" bude jedna z prvních, kterou dogooglí), ale NAT na IPv4 rozhodně vypínat nebude (neb by mu "přestal" jít net).
Jistě, ideální by byla osvěta - ale realita, bohužel, se vždycky bude od ideálního stavu lišit. Ono kdyby bylo možné se ideálnímu stavu přiblížit, tak žádnou ochranu před útoky řešit nemusíme :)
Muzete mi prosim popsat, jak bude vypadat ten paket se kterym se dostanete na adresu (napr. 192.168.1.10) za NATem (presneji receno PATem), ktera je za verejnou adressou a.b.c.d ?
Predpokladam, ze nevyuzijete vynucene smerovani s vyuzitim IP options.
Pokud preci jen vymyslite zpusob jak se na to sdileni za NATem dosat tak je to skvele, protoze se vam podarilo najit cestu jak po IPv4 komunikovat se zarizenimi za N(P)ATem naprimo. Tedy asi pada duvod proc zavadet IPv6 (kdyz uvazim, ze prakticky jedinym argumentem zavadeni IPv6 je prima konektivita mezi koncovymi zarizenimi).
To je fakt hodne vtipne. Netfliter si skutecne ulozi do connrack tabulky i vnejsi komunikaci a nat to pak pri prekladu (resp. neprekladu) zohledni a tim padem data patrici prislusne relaci uz nenatuje. Sice to neni to jak jsme se o tom puvodne bavili, ale funguje to (odhaduju, ze vas tohle chovani taky tak trosku prekvapilo :-)) ). Zajimalo by me jestli se takto chovaji i dalsi implementace NATu.
Ale beru - to co bylo v zadani bylo nepopiratelne splneno, takze castka dle pokynu pripsana na FOD, viz.
https://docs.google.com/file/d/0B5GtWtSvjxxTYkhseFpkMHB3WUU/edit
Jeste bych si dovolil mensi polemiku k tomu zaveru s tim mangle v iptables. Zprehazi se vam tam i cisla portu, takze byste musel dostatecne rychle takove pravidlo vvytvorit. Stejne tak se do contrak nezaradi relace kterou nepredchazi pocatecni SYN. Pokud je tam rovnou SYN+ACK tak se nestane nic. Aspon podle zdrojaku, nedokazu to ted ale nejak v rychlosti vyzkouset. (Kdyz tak vyzkousim a pak se s nekym vsadim :-))