Vlákno názorů k článku Česko samo přechod na IPv6 nezvládne, trh to nevyřeší, říká Ondřej Filip od RDa - Problem IPv6 je, ze neprinasi zadny prakticky uzitek. Svet...

Spolupracovat nemusi nutne jen uzivatel. Tim "wtf" protokolem je jen tak mimochodem treba i FTP, ktery bez conntrack helperu taky nefunguje jak ma. A treba i PPTP stale pouzivane u nekterych socka-VPN-reseni. A zrovna i ten SIP je vec, co bezny uzivatel casto provozuje. Nebo chcete popirat existenci IP telefonie? ;-)

Ach jo, zase jeden, co neví o počítačové síti nic víc, než že propojuje zařízení...

- NAT není bezpečnostní funkce. Nikdy nebyl a nikdy nebude.
- NAT je komplikace jak z pohledu techniky, tak z pohledu legislativy.
- Pokud se útočník v lokální síti, tak na IPv4 prosknuje těch 255 adres za zlomek sekundy, 2^64 nezvládne tak rychle. mDNS a podobný mechanismy vyjdou v obojím nastejno.
- Pokud oddělím sítě a útočník se do jedné z nich dostane, vidí i do těch, co to mají povoleno na firewallu. Bez ohledu na to, jestli po IPv4 nebo IPv6
- IPv4 nemá privacy extension.

Na jednu stranu tvrdite, jak NAT je zlo a ze vas omezuje, a na druhou stranu pak tvrdite, ze vlastne NAT neni zadnej problem a vse je skrze nej mozne.
Představte si, že si do vchodu do bytu namontujete místo dveří turniket. Bude vás to omezovat, ale zlodějům ve vykradení bytu to fakt nezabrání.

Nevhodne prirovnani.

Kdyz uz mate analogii ke vchodum:

NAT je jako koule na dverich z jedne strany - zevnitr ven cokoliv, z vnejska dovnitr nic. Leda ze velice okate chytnete okamzik pootevrenych dveri v momente co majitel opousti byt.

A prece je takova jednostranna koule rozsirena jako NAT.. "v kazde rodine". A dokonce to spada mezi bezpecnostni prvky, ne mezi pridane benefity a luxus.

Nevhodne prirovnani.
V čem?

NAT je jako koule na dverich z jedne strany - zevnitr ven cokoliv, z vnejska dovnitr nic.
Jenže takhle právě NAT nefunguje.

A dokonce to spada mezi bezpecnostni prvky, ne mezi pridane benefity a luxus.
NAT nespadá mezi bezpečnostní prvky. Není to benefit nebo luxus, je to naopak zhoršení služby.

1/ mate to tam napsane, staci cist a porozumet textu

2/ ale ano, takhle klasicky NAT funguje (hovorove NAT, zde tedy SNAT, ne jinou variantu)

3/ kdyby jste opet neignoroval kontext, tak zjistite ze dana pasaz se tyka koule, ne NATu

mate to tam napsane, staci cist a porozumet textu
Ne, tam není napsáno, v čem je to přirovnání nevhodné. Je tam napsáno jiné přirovnání.

ale ano, takhle klasicky NAT funguje (hovorove NAT, zde tedy SNAT, ne jinou variantu)
Ne, NAT ani SNAT nezabraňuje komunikaci z venku. Komplikuje ji oprávněnému uživateli, ale nezabraňuje jí.

kdyby jste opet neignoroval kontext, tak zjistite ze dana pasaz se tyka koule, ne NATu
Kdybyste si to po sobě přečetl, zjistil byste, že se to dá interpretovat obojím způsobem. A interpretovat to tak, že se to týká koule na dveřích a ne NATu nedává smysl, protože řeč je o NATu, koule sloužila jen jako (nevhodné) přirovnání. Nedává smysl tu básnit o vlastnostech koule, které nejsou podstatné pro to přirovnání.

To jste dalsi takovej Cimrman..
Autor tak vlastně zastává názor, který zároveň vyvrací.

Na jednu stranu tvrdite, jak NAT je zlo a ze vas omezuje, a na druhou stranu pak tvrdite, ze vlastne NAT neni zadnej problem a vse je skrze nej mozne.

(kruh se uzavrel, tahle teze nadale plati)

Tak si zkuste do bytu místo vchodových dveří nainstalovat turniket. A pak si kupte novou lednici, kterou přes ten turniket nastěhujete do bytu. Třeba vám to pak dojde.

Dekuji, ze jste si timto myslenkovym nepochodem zodpovedel svoji predeslou otazku.

REF:
"Nevhodne prirovnani."
V čem?

Takže je to vhodné přirovnání, protože přesně ilustruje ten problém NATu, který vy nechápete. Nicméně nepochopil jste ho ani z toho přirovnání.

Ovšem pokud je nad vaše možnosti chápání to, že nějaká věc může komplikovat řádné užívání, ale zároveň nebrání nekalému užití, pak je to na pováženou. Ale můžu zkusit ještě pár příkladů, třeba se chytnete.

Třeba časový zámek s potvrzením zadání správného kódu na přenosné pokladně. Zadáte PIN a budete muset čekat – to je pro vás komplikace. Lupič vás donutí zadat PIN a s pokladnou uteče – to, že po útěku bude muset ještě chvíli počkat, než se do pokladny dostane, mu asi moc vadit nebude.

Nebo kompletní vyprázdnění nádrže auta při parkování. Pro vás bude komplikace, když při každém zaparkování auta vyprázdníte jeho nádrž, aby s ní m nikdo nemohl odjet. Bude pro vás komplikace i to, že když budete chtít někam jet, budete muset nádrž zase naplnit. Ovšem když zloděj přijede s přepravníkem, na který auto jednoduše naloží, prázdná nádrž mu vůbec vadit nebude – až auto odveze, klidně tu nádrž naplní.

Tak co, už chápete, že pokud něco komplikuje život právoplatnému uživateli, nemusí to nutně být nepřekonatelnou překážkou pro padoucha?

Melete hromadu nesouvisejicich nesmyslu, ale doposud jste zde vy a ani nikdo jiny neukazal:

1/ jak se SNAT da univerzalne prekonat z venku a adresovat sluzby na strojich ve vnitrni siti

2/ jak to omezuje bezneho uzivatele, ktery ma potrebu se pripojovat na uzly ve vnejsi siti

3/ vetsi nebo stejnou miru napadeni stroju za NATem vuci strojum ktere jsou dostupne primo, utocnikem na verejne siti (tj. zda NAT prispiva nebo neprispiva k bezpecnosti, resp. jeho souhrny efekt v otazce zabezpeceni)

jak se SNAT da univerzalne prekonat z venku a adresovat sluzby na strojich ve vnitrni siti
Úplně jednoduše pošlete na vnější rozhraní routeru paket s cílovou adresou ve vnitřní síti. Router ho normálně na základě routovací tabulky pošle do vnitřní sítě. NAT mu v tom nijak nezabrání. C.B.D.

jak to omezuje bezneho uzivatele, ktery ma potrebu se pripojovat na uzly ve vnejsi siti
Běžný uživatel má i potřebu připojovat se z venku do vnitřní sítě. Akorát to obvykle řeší různými cloudy. Při připojování na uzly ve vnější síti ho to omezuje například tak, že ty uzly často dělají různé kontroly na zdrojové IP adresy. Pokud třeba někdo škodí cílovému uzlu, zablokuje cílový uzel komunikaci s touto IP adresou, a tím i všechny, kteří jsou za ní schovaní na NATu. Nebo třeba různé hry omezují počet přístupů z jedné IP adresy.

vetsi nebo stejnou miru napadeni stroju za NATem vuci strojum ktere jsou dostupne primo, utocnikem na verejne siti (tj. zda NAT prispiva nebo neprispiva k bezpecnosti, resp. jeho souhrny efekt v otazce zabezpeceni)
Tohle je ovšem chybné vyvozování. NAT nemusí být příčina, může to být důsledek nějaké jiné společné příčiny.

Jako s tím turniketem na vstupu do bytu. Počet vyloupení bytu může být nižší, než když jste předtím bydlel v rodinném domě, kdy byly normální dveře. Ale nezpůsobí to ten turniket, nýbrž vchodové dveře do celého bytového domu, které zabrání tomu, aby se zloděj dostal do domu. Takže se nedostane ani před váš turniket. Akorát v takovém případě při zabezpečení svého bytu spoléháte na to, že máte poctivé sousedy, že do baráku nepouští cizí lidi, že neztrácejí klíče, že správce domu nedává klíč od domu každému, koho potká.

Proto je ten příměr s turniketem místo dveří do bytu vhodný. Protože ukazuje, že vám to život zkomplikuje, útočníka to nezastaví, a pokud se k vám zloděj nedostal, není to zásluha toho turniketu, ale toho, že se o vaši bezpečnost starají všichni okolo vás.

@RDa: S NATem jako bezpečnostní funkcí to nemyslíš vážně, že?

Definujeme si to takhle:
- Bezpečnostní funkce je taková, která:
1) zastaví útočníka (jinak nemá co do činění s bezpečností), a
2) nezabrání legitimnímu využití služby uživatelem (protože to by vypnutí byla ideální bezpečnostní funkce).
- Uživatel je osoba, která chce zařízení využít k jeho účelu a je k tomu oprávněna.
- Útočník je osoba, která má přístup k vnější síti, může odchytávat a posílat pakety a má zájem jakkoliv škodit.
- Protože NAT ovlivňuje průchod paketů v síti, berme oba případy, zdařené užití i zdařený útok doručení paketu s žádostí o navázání TCP spojení na zařízení ve vnitřní síti. Nebudeme uvažovat firewall atd.

Use case 1
Pepa je majitel domku. Udělal si domácí automatizaci, která mj. ovládá topení. Jede na dva týdny lyžovat, tak stáhne na ty dva týdny topení na 10°C. Druhý den si zlomí ruku a jede domů dřív. Protože je automatizace napojená na Ethernet, chce se připojit cestou domů z mobilu a zvednout teplotu dřív, aby nedojel do vymrzlýho baráku.
Nemůže, NAT mu nedovolí navázat spojení s PLC. Pakety končí na NATu, ale ten neví, kam je poslat dál.
V tomto případě jde o legtimní užití - nastavení topení v bytě jeho vlastníkem a obyvatelem. Nebylo umožněno, tj. v tomto bodě NAT nesplnil definici bezpečnostní funkce v bodě 2.
Tohle je Jirsákovo stěhování ledničky skrz turniket.

Use case 2
S Pepou má Lojza nevyřízený účty a ví, že po loňským úraze na lyžích si platí VPSku a jeho domácí automatizace na ni udržuje TCP spojení, kdyby něco. A že znovu odjel na lyže. Chce mu odstavit topení úplně, ať mu zamrznou a popraskají trubky.
Má přístup k lince. Odposlechne IP adresu a port VPSky.
Alternativa 1: V tu chvíli je NAT otevřený pro IP adresu a por VPSky kvůli doručování odpovědí. Pošle SYN paket s IP adresou a portem jeho VPSky, ten projde otevřeným oknem na NATu rovnou na zařízení.
Alternativa 2: Pošle jménem VPSky FIN paket. Spojení se přeruší, automatizace se ho pokusí navázat znovu. Vydává se za VPS a na jeho SYN odpoví ACK. ACK paket projde NATem na zařízení.

Bad boy won. Útočník nebyl zastaven, nebyla splněna ani první podmínka pro bezpečnostní funkci, a to rovnou dvěma různými způsoby.
Tohle je Jirsákův zloděj, co přelezl turniket.

Porovnání s IPv6 bez NATu
Pepa zná IP adresu a přihlašovací údaje k PLC, to je vidět zvenčí, nastaví, co potřebuje.
Lojza nemá spojení, který by shodil, protože PLC je jenom na přjmu a nekomunikuje. Nemá co shodit s tím, že se to k němu připojí. Proskenovat 2^72 adres (prefix /56) během Pepovy dovolené nestihl.
Bez NATu se kupodivu povedlo legitimní užití, ale útočník pohořel. Takže definici bezpečnostní funkce splňuje IPv6, ne NAT. Jak že to říkal ten beránek v bajce? To máš, vlku, bl-béééééé

15. 6. 2024, 23:20 editováno autorem komentáře

Use case 1:
Pepa vi ze ma doma NAT a provede DNAT konfiguraci na ovladaci port PLC. Pokud je trocha chytrejsi, provede to v dynamicke variante s povolenim na port knocking. Pokud ho zajima bezpecnost, sve PLC ovlada skrze VPN, treba na bazi WG. Problem vyresen bezpecne.

Use case 2:
Pokud ma Lojza pristup k lince, tak jste kompromitovan nezavisle na nasazene halde technologii, proste jste MITM = boss. Neni to relevantni k NAT ani IPv4 - vidi prece pakety na jeho lince. Problem neni resitelny zadnym zpusobem.

Takze jste stejny neschopa a demagog jako Filipek. Gratuluji.

RDa: Když nemáte argumenty a pokoušíte se místo toho jen zesměšnit oponenta, zesměšňujete akorát sám sebe. Pokud vám neschopa popíše, jak se může stát něco, o čem vy jste si myslel, že to nejde, kdo jste pak vy?

Bohuzel ani jeden priklad neni prikladem, jak se nekdo cizi z internetu dostane do vasi LAN za NATem. Proste to nejde, uz to pochopte. Reseni je to dostatecne bezpecne (opakuji znova statisticky dukaz: vzdalene nabourane stroje nejsou nikdy ty, ktere jsou v privatnim adresnim prostoru za NAT, ale kompromituji se verejne dostupne stroje).

Vsichni si pouze vymyslite dalsi, casto tezko splnitelne, podminky - jako ze potrebujete mit pristup na linku.. nebo posilat falesne pakety na rozhrani - coz znova vyzaduje byt v segmentu nadrazene site, jinak vam takovy paket zahodi prvni router.

Takze ne - zatim nikdo nedokazal onu magickou schopnost demonstrovat, ze takova SNAT mu nedela potize. A proto jste neschopove, oba dva. A to neni zesmesnovani - pouze konstatovani faktu, ze nedokazete prezentovat aplikovatelny vektor utoku.

RDa: No tak si to probereme postupně. Co se stane, když na vnější rozhraní vašeho routeru s NATem (kde nebude žádný firewall), dorazí paket s adresou z vaší vnitřní sítě? BUde směrován do vaší vnitřní sítě na zařízení, které má IP adresu uvedenou v tom paketu. Pokud to nevíte, dostudujte si to.

Vy určitě budete namítat, jak by se tam ten paket dostal. No jednoduše, ze sítě, ve které je to vnější rozhraní routeru. V té budou zařízení vašeho ISP, možná také zařízení dalších klientů vašeho ISP. Že vám tam ISP určitě nebude posílat žádný škodlivý provoz? Že ISP odděluje vaše zařízení od zařízení ostatních klientů? Jak to víte? Jste si tím jistý? Dokážete si to zkontrolovat? Zjistíte, pokud dojde ke změně? V každém případě to, co by vás chránilo, by byl firewall ISP, ne váš NAT.

Proto jsem NAT přirovnával k turniketu místo dveří do bytu v bytovém domě. Tam by vás také chránil nikoli ten turniket, ale zámek na vstupních dveřích do domu – a to, že byste měl slušné sousedy.

Další podmínky si tu vymýšlíte vy. Třeba to, že útočník musí být někdo cizí z internetu, pod čímž si představujete někoho hodně daleko. Jenže takhle se bezpečnost neřeší. Ochrana sítě musí fungovat i tehdy, když je útočník hned vedle, v síti ISP, v zařízení nějakého klienta, se kterým sdílíte segment sítě ISP apod.

Jediný, kdo je v této diskusi demagog, jste vy. Tváříte se, že útočník musí být někde daleko. Polemizujete s tvrzením, že SNAT nedělá útočníkovi potíže – jenže nic takového nikdo netvrdil. Bylo řečeno, že SNAT není dostatečná ochrana. Jako s tím turniketem – i ten by zloději dělal potíže, ale zloděje by nejspíš nezastavil.

Takže, speciálně pro superneschopu a demagoga, aplikovatelný vektor útoku: útočník ovládá zařízení vašeho souseda, který je klientem stejného ISP, jeho router je na stejném segmentu sítě ISP, jako váš router, a ISP nefiltruje komunikaci v rámci daného segmentu sítě.

Pokud byste se zase chtěl vymlouvat, že je to speciální případ – za prvé, bezpečnost se řeší i kvůli speciálním případům. Zámek do bytu si také nedáváte kvůli lidem, kteří vás nechtějí vykrást, ale kvůli těm, kteří vás chtějí vykrást a dostali se do baráku. Za druhé, pokud byste chtěl argumentovat tím, že ISP ale filtruje provoz mezi zařízeními v jednom segmentu sítě – pak by ale tu ochranu zajišťoval ten firewall ISP a ne váš NAT. Což poznáte například podle toho, že když tam firewall ISP bude, útok bude neúspěšný; když tam nebude, útok bude úspěšný. Za to přítomnost či nepřítomnost NATu na vašem routeru nebude mít na úspěšnost útoku žádný vliv.

Samozřejmě existují i možnosti, jak se dostat skrze NAT na dálku. Tam záleží na konkrétním způsobu fungování NATu, často může pomoci, pokud se kanál v NATu otevře zevnitř. Pokud byste měl pocit, že k tomu musí útočník už ovládat nějaké zařízení v interní síti, pak máte špatný pocit – může stačit třeba vmanipulovat uživatele, aby navštívil nějakou webovou stránku, a ten kanál v NATu otevře uživatelův webový prohlížeč.

opakuji znova statisticky dukaz: vzdalene nabourane stroje nejsou nikdy ty, ktere jsou v privatnim adresnim prostoru za NAT, ale kompromituji se verejne dostupne stroje
To není žádný důkaz. Za prvé to není pravda, samozřejmě je nabouraná spousta zařízení, která jsou za NATem. Za druhé už jsem vám vysvětloval, že i kdyby to byla statisticky prokázaná věc, nepoznáte z toho, zda jde o kauzalitu nebo korelaci.

Takže se přestaňte ztrapňovat pokusy o zesměšňování oponentů a začněte vnímat fakta. Je potřeba začít od toho, co je bezpečnost, a jak fungují sítě.

Proč NAT přirovnávat k turniketu? Není to spíše jako telefonní ústředna, která jednu veřejnou telefonní linku rozděluje mezi spoustu interních linek v závodě? Nebo vrátnice, která umožňuje jeden vchod - jednu adresu či dokonce jedno PSČ užívat mnoha lidem s jejich byty či kancelářemi?

I tou vrátnicí nebo ústřednou lze projít zvenku dovnitř, podle toho, jaký bude vrátný či spojovatel a jakou bezpečnostní politiku budou uplatňovat. Zároveň lze v případě potřeby zavést striktní pravidla, třeba že každý příchozí balíček vrátný zrentgenuje a zkontroluje detektorem na výbušniny...

Proč NAT přirovnávat k turniketu?
Protože to byl příklad něčeho, co oprávněnému uživateli komplikuje život (přes turniket budete do bytu nebo z bytu těžko stěhovat lednici nebo gauč), ale útočníkovi to nebrání v útoku (zloděj přes turniket z bytu vynese spoustu věcí, případně se nebude rozpakovat turniket zničit nebo demontovat, pokud mu bude překážet.

I tou vrátnicí nebo ústřednou lze projít zvenku dovnitř, podle toho, jaký bude vrátný či spojovatel a jakou bezpečnostní politiku budou uplatňovat. Zároveň lze v případě potřeby zavést striktní pravidla, třeba že každý příchozí balíček vrátný zrentgenuje a zkontroluje detektorem na výbušniny...
Jenže NAT právě žádnou bezpečnostní politiku neuplatňuje. To se tu celou dobu snažíme vysvětlit. Bezpečnostní politiku případně uplatňuje firewall.

"Jenže NAT právě žádnou bezpečnostní politiku neuplatňuje."
Vrátnice nebo ústředna také ne. Základní funkcí je sdílení vstupního místa pro několik uživatelů. Některými vrátnicemi může projít každý a pošta s bombou může být doručena až k danému uživateli. Některé ústředny hovor zvenku nepřepojí, jiné ho přepojí po doplnění upřesňující informace, možná i na základě předchozí informace, že linka 123 předtím volala do servisu. Sama vrátnice nebo ústředna není zárukou bezpečí, nanejvýš komplikuje život průchozím ale třeba i spammerům, kteří nevědí ke komu jdou nebo koho chtějí spojit, tak jejich žádost zůstane na vrátnici nebo v ústředně.

Turniket je ale něco jiného, ten nějakým způsobem kontroluje (třeba jen počítá) průchod z jednoho místa do druhého místa, není to křižovatka nebo rozcestník. Turniket může být klidně masivní odolná klec, která nepustí nikoho, kdo nesplní kritérium. Turniket je dimenzovaný na nějakou velikost, pokud se jím mají stěhovat ledničky, musí na to být uzpůsoben.

- Ústředna má nějakou klapku, kterou můžeš použít ve veřejné síti a spojí tě s konkrétním člověkem. NAT sám o sobě takovou možnost nemá - má jenom jedno veřejný číslo, nedovoluje přidat další číslice a s volajícím se nebaví.
- Vrátnice, no budiž. Ale taková, která nemá povědomí o tom, kdo za ní pracuje a nedovoluje ty zaměstnance kontaktovat. Takže ten musí co pět minut proběhnout ven na smluvený místo a podívat se, jestli za ním někdo nedošel.
- NATem tě může protáhnout jenom ten, kdo je uvnitř. To není o nastavení pravidel, to je fakt. Obcházení (maškaráda) je vyhnutí se té vrátnici skrz díru v plotě, kterou si ten zaměstnanec udělá na vlastní pěst a řekne o ní návštěvě. Když ji někdo nepovolaný objeví, proklouzne dovnitř a ta slavná vrátnice o tom vůbec neví.
- Rentgenování balíčků není NAT, rentgenování balíčků je firewall. To je úplně jiná funkcionalita. Nezávislá na NATu.

Tož proto...

Statistický důkaz neexistence bezpečnostní fuknce NATu je každý botnet, složený z IoT zařízení za NATem. Pár už jich bylo.

mozte uviest priklad?

vsetky priklady o ktorych viem, naopak boli prezentovane nad IoT ktore NEBOLI za NATom.
(to, ze si niekto otvori port a je pristupny zvonku je pochopitelne pripad, ze to za NATom nie je)

to, ze si niekto otvori port a je pristupny zvonku je pochopitelne pripad, ze to za NATom nie je

Ehm. Útok v tom případě šel na venkovní adresu NATu, NAT to propustil do vnitřní sítě a změnil těm paketům útočníka IP adresu ze svojí na jeho vnitřní. Takže nějak nechápu, proč tvrdíš, že to za NATem nebylo, když mezi útočníkem a tou napadenou věcí byl NAT a v tom trafficu se vrtal. Že v něm je otevřený okno je jeho normální funkcionalita, ne jeho nepřítomnost!!!

A tím pádem sis na to odpověděl sám - prakticky všechny*) útoky na IoT po IPv4, co se netýkaly routerů s veřejnou IPv4 adresou. Nějak je v tomhle stavu nevidím reálný, že profesionální firma vyrobí tisíce krabiček a bude individuálně řešit na desítkách routerů u desítek ISPíků obcházení NATu, aby je pak zarazil CGNAT, nebo je při tomhle vyčerpání adres všechny věšet na veřejný IPv4 adresy.

*) Jediná možnost je, že někdo z firem s prefixem class A z 50 let starýho přídělu si takovou krabičku zapne ve vnitřní síti bez NATu

pre pripad, ze viete o com hovorite, len neviete citat, este raz:

pisali ste o bootnetoch na IoT ktore boli zalozene z vekej casti na zariadeniach za NATom.
Mozte uviest konkretny priklad takeho bootnetu?

--

To, ze na presnujuci komentar k uvedenej otazke ste odpovedali nezmyselny sloh nepovazujem za hodne reakcie. Diskusia kde si dokazujete kto ma vacsieho ma naozaj nezaujima.

Treba o Mirai se zpravy na Slovensko nedostaly? :-) A jinak v obecne rovine, dnes je to s velkou mirou pravdepodobnosti tak, ze se proste zretezi nekolik ruznych zranitelnosti... a ve vysledku to vede k tomu, ze ten NAT vas proste pred nicim neochrani.

Vzhledem k tomu, ze zdrojak Mirai botu je na GitHub-u, a explicitne obsahuje podminku vylucujici privatni site (za NAT-em), tak jste si dobre nabehl, co tam mate dalsiho? :D

https://github.com/jgamblin/Mirai-Source-Code/blob/3273043e1ef9c0bb41bd9fcdc5317f7b797a2a94/mirai/bot/scanner.c#L674

Ještě kdybyste věděl, co ten zdroják dělá…

Tak bude delat to, co tam je napsano.. a pokud jste lini to studovat, zde mate popis pro laiky:

Devices infected by Mirai continuously scan the internet for the IP address of Internet of things (IoT) devices. Mirai includes a table of IP address ranges that it will not infect, including private networks and addresses allocated to the United States Postal Service and Department of Defense.

Victim IoT devices are identified by “first entering a rapid scanning phase where it asynchronously and “statelessly” sent TCP SYN probes to pseudo-random IPv4 addresses, excluding those in a hard-coded IP blacklist, on telnet TCP ports 23 and 2323”. If an IoT device responds to the probe, the attack then enters into a brute-force login phase. During this phase, the attacker tries to establish a telnet connection using predetermined username and password pairs from a list of credentials. Most of these logins are default usernames and passwords from the IoT vendor. If the IoT device allows the Telnet access, the victim's IP, along with the successfully used credential is sent to a collection server.

https://en.wikipedia.org/wiki/Mirai_(malware)

https://www.imperva.com/blog/malware-analysis-mirai-ddos-botnet/?redirect=Incapsula

Mirai tedy zamerne necilil na uzly za NAT, ale jen ty, co maji verejnou adresu. Ono totiz kdyz tam je C&C cast implementovana jako listener (ma to v sobe telnet-like shell), tak byt schovanej za NAT-em je jak to rict... totalne k nicemu.

Takze mit derave IoT za NAT-em, byla konkretne v pripade Mirai zaruka ochrany.

Nejak vam ta vase demagogie nevychazi :D

RDa: Jak jsem psal, to byste nejdříve musel vědět, co ten zdroják dělá a jak funguje internet.

Když se chcete připojit z druhého konce internetu na zařízení, k němuž znáte jen privátní IP adresu, opravdu nemůžete jen tak poslat paket s cílovou privátní IP adresou.

Konkrétní příklad – kdyby bylo ve vaší domácí síti za NATem nějaké zařízení napadené Mirai a kód si vygeneroval náhodnou IP adresu 172.16.173.127, s jakým zařízením se naváže komunikace?

Dokud nebudete znát odpověď na tuhle otázku, nemá smysl, abyste pokračoval v diskusi – protože nechápete podstatu diskuse. No a až zjistíte odpověď na tu otázku, budete se stydět, co tady celou dobu píšete za nesmysly, a v diskusi také pokračovat nebudete.

Vy jste totalne vedle.

Konkrétní příklad – kdyby bylo ve vaší domácí síti za NATem nějaké zařízení napadené Mirai a kód si vygeneroval náhodnou IP adresu 172.16.173.127, s jakým zařízením se naváže komunikace?

Ne.
1) Zarizeni v lokalni siti nebude napadeno Mirai.
2) Mirai nikdy nevygeneruje takovou IP, viz zdrojak.

Znova odbocujete do nesmyslu ktery nenastane.

A jsme u toho co tvrdim od pocatku:

Když se chcete připojit z druhého konce internetu na zařízení, k němuž znáte jen privátní IP adresu, opravdu nemůžete jen tak poslat paket s cílovou privátní IP adresou.

Z tohoto pohledu NAT poskytuje bezpecnostni zaruku stejnou jako specificke filtrovaci pravidlo ve firewallu - ze zarizeni za NATem NEBUDE kontaktovatelne z celeho verejneho internetu.

Dekuji tedy, ze jste konecne priznal, ze zarizeni za NATem je v bezpeci.

RDa: Tak ještě jednou a pro absolutně neznalé.

Představte si situaci, kdy zařízení v lokální síti bude napadeno Mirai. Chápu, že o sítích nic nevíte, ale vězte, že zařízení může mít více IP adres, takže může být v privátní síti a zároveň mít veřejnou IP adresu. Nebo může být jen v privátní síti, ale veřejná IP adresa může být na jeho IP adresu NATována. Nebo ta lokální síť prostě může mít veřejné IP adresy – psal jsem o lokální síti, ne o privátní síti. Takže máme situaci, kdy máte zařízení napadené Mirai.

Teď si představte, že by v tom zdrojáku Mirai nebyla ta podmínka při generování náhodných IPv4 adres. Takže by to zařízení vygenerovalo IP adresu 172.16.173.127 a s ní by začalo navazovat spojení. Co by se podle vás stalo?

Až to budete vědět, pochopíte (možná), proč je ve zdrojáku ta podmínka. Pak by vám mělo dojít, že ta podmínka neznamená, že Mirai nenapadá zařízení v privátních sítích.

Mimochodem, ono totiž není jak na dálku zjistit, že je nějaké zařízení v privátní síti. Ono totiž může mít více adres, může být provoz na tu privátní IP adresu NATován z veřejné adresy…

Z tohoto pohledu NAT poskytuje bezpecnostni zaruku stejnou jako specificke filtrovaci pravidlo ve firewallu - ze zarizeni za NATem NEBUDE kontaktovatelne z celeho verejneho internetu.
Má to jednu drobnou vadu – není to pravda.

Už jsem vám to psal, jenže vy to ignorujete. Tak ještě jednou. Máte router se SNAT, který směrem do lokální sítě má IP rozsah 192.168.1.0/24. Na vnější rozhraní toho routeru přijde IP adresa s cílovou IP adresou 192.168.1.3. Co udělá SNAT? Co udělá router?

Až budete umět odpovědět na tyhle otázky, pochopíte, v čem se celou dobu mýlíte.

Vy jste asi blbej nebo nevim, ale znova:

Pokud IoT zarizeni ma pristup na vice podsiti a bylo napadnuto z verejne site skrze DNAT, tak ta podminka zajisti ze NEBUDE napadat dalsi zarizeni za timto NATem v one konkretni privatni siti.

Coz je presny opak vaseho soucasneho vnimani, AKA:

Až to budete vědět, pochopíte (možná), proč je ve zdrojáku ta podmínka. Pak by vám mělo dojít, že ta podmínka neznamená, že Mirai nenapadá zařízení v privátních sítích.

Ta podminka zarucuje ze se Mirai o zarizeni za NATem nebude zajimat. Napadne jen to verejne dostupne zarizeni. A pokud je zarizeni verejne dostupne, protoze na nej nekdo skrze DNAT nastavil pristup, tak ho nelze povazovat za schovane za NAT.

Vy jste asi blbej nebo nevim, ale znova:
Od vás to beru jako pochvalu.

Pokud IoT zarizeni ma pristup na vice podsiti a bylo napadnuto z verejne site skrze DNAT, tak ta podminka zajisti ze NEBUDE napadat dalsi zarizeni za timto NATem v one konkretni privatni siti.
Ve skutečnosti je tam ta podmínka pro to, aby se zbytečně nestřílelo do IP adres, u nichž je nízká pravděpodobnost úspěchu.

Ta podminka zarucuje ze se Mirai o zarizeni za NATem nebude zajimat.
Nezaručuje. Zařízení za NATem může být dostupné přes veřejnou IP adresu.

A pokud je zarizeni verejne dostupne, protoze na nej nekdo skrze DNAT nastavil pristup, tak ho nelze povazovat za schovane za NAT.
Vida, už se blížíte k cíli. To, jestli je tam nastaven DNAT, ovšem nevíte – třeba i proto, že se to může kdykoli změnit. (Může to nastavit váš ISP, pokud byste chtěl tvrdit, že přece víte, co máte nastavené.) Takže žádné zařízení nemůžete považovat za schované za NATem. A to je to, co se vám tu snaží několik lidí vysvětlit už několik dní.

NAT totiž nic neschovává, NAT naopak zpřístupňuje.

17. 6. 2024, 09:00 editováno autorem komentáře

Ve skutečnosti je tam ta podmínka pro to, aby se zbytečně nestřílelo do IP adres, u nichž je nízká pravděpodobnost úspěchu.

To je vase dezinterpretace jasneho faktu. Zdrojak rika "neutocit na zarizeni v privatnich sitich" (aka za NAT-em). Nic vice, nic mene.

Jak jste prisel na to, ze to ma korelaci s nizkou mirou uspechu, ale zaroven tvrdite v predeslych komentarich, ze IoT zarizeni za NATem jsou castejsi nebo stejne snadne obeti, fakt nevim.

To je vase dezinterpretace jasneho faktu. Zdrojak rika "neutocit na zarizeni v privatnich sitich" (aka za NAT-em). Nic vice, nic mene.
To je vaše dezinterpretace jasného faktu. 127.0.0.0/8 nejsou privátní sítě, 15.0.0.0/7 nejsou privátní sítě atd. Navíc privátní síť nemusí být za NATem.

Jak jste prisel na to, ze to ma korelaci s nizkou mirou uspechu, ale zaroven tvrdite v predeslych komentarich, ze IoT zarizeni za NATem jsou castejsi nebo stejne snadne obeti, fakt nevim.
Přišel jsem na to jednoduše tak, že rozumím fungování IP sítí podstatně lépe, než vy. Takže například na rozdíl od vás chápu, že na zařízení za NATem na druhé straně internetu se fakt nedostanete tak, že do paketu uvedete jako cílovou adresu jeho IP adresu z privátního rozsahu. Co je na tom tak těžké pochopit?

To, že jsou IoT zařízení za NATem častější oběti plyne jednoduše z toho, že je takových zařízení podstatně víc.

Tohle je uz mega trapny ze nedokazete udrzet kontext o kterem se bavime.

Bavime se pouze a jenom o teto casti podminek:

(o1 == 10) ||                             // 10.0.0.0/8       - Internal network
(o1 == 192 && o2 == 168) ||               // 192.168.0.0/16   - Internal network
(o1 == 172 && o2 >= 16 && o2 < 32) ||     // 172.16.0.0/14    - Internal network

To jsou site za NATem.

Ze ten bot nema potrebu utocit na US DoD, USPS a jine specificke vyjimky ma zcela jine duvody (napr. souvisejici s mirou odhalitelnosti, tudiz zivotnosti botnetu)

Takže například na rozdíl od vás chápu, že na zařízení za NATem na druhé straně internetu se fakt nedostanete tak, že do paketu uvedete jako cílovou adresu jeho IP adresu z privátního rozsahu. Co je na tom tak těžké pochopit?

Ja tomu rozumim a presne tohle i ocekavam ze bude platit - a proto tvrdim ze NAT je zabezpeceni, protoze zamezi moznosti komunikace temer vsech utocniku na chranene zarizeni.

Tedy zcela stejne, jako kdyz si nastavite firewall s vyjimkou na chatu/do prace nebo odkud se bezne pripojujete - a utocnik bude mit stesti se nachazet na stejne zdrojove adrese.

Bavime se pouze a jenom o teto casti podminek:
Jen o části těch podmínek se bavíte vy. Přičemž jste to nikde nenapsal a vůbec jste nezdůvodnil, proč se bavíte zrovna o této části.

To jsou site za NATem.
Nejsou. Jsou to privátní rozsahy, které nejsou routovatelné ve veřejném internetu. To neznamená, že jsou to sítě za NATem.

Ze ten bot nema potrebu utocit na US DoD, USPS a jine specificke vyjimky ma zcela jine duvody (napr. souvisejici s mirou odhalitelnosti, tudiz zivotnosti botnetu)
To je vaše ničím nepodložená spekulace.

Ja tomu rozumim
V tom případě to velmi dobře maskujete.

a proto tvrdim ze NAT je zabezpeceni, protoze zamezi moznosti komunikace temer vsech utocniku na chranene zarizeni.
NAT ale ničemu nezamezí. A pokud je to „téměř všech“, není to „zabezpečení“.

Tedy zcela stejne, jako kdyz si nastavite firewall s vyjimkou na chatu/do prace nebo odkud se bezne pripojujete - a utocnik bude mit stesti se nachazet na stejne zdrojove adrese.
Není to stejné. Firewall nastavuju já, takže mám kontrolu nad tím, koho dovnitř pustím a koho ne. Ta „ochrana“, o které píšete, není způsobená NATem, ale konfigurací sítě a případně firewallu někde před tím NATem. A nemáte to ve své moci vy.

Rozdíl mezi firewallem a NATem je ten, že firewall vybrané pakety zahazuje, nepustí je dál. NAT jenom překládá adresy v paketech, nikdy žádný paket nezahodí. Nevím, jak si představujete, že by fungovalo síťové zabezpečení na úrovni paketů, které nikdy žádný paket nezahodí. To je jak kdybyste měl u vstupu do budovy ochranku, která by ovšem nikdy nemohla nikoho zastavit. To je podle vás zabezpečení?

Proto jsem NAT přirovnával k turniketu místo dveří do bytu v bytovém domě. Vy se pořád oháníte tím, jak vás chrání turniket, ale ve skutečnosti jediná ochrana je zámek na vchodových dveřích do bytového domu. Který ale nemáte pod kontrolou, nevíte, kdo všechno od něj má klíč. Nevíte ani zda zrovna není rozbitý a dveře nejdou otevřít i bez klíče. Takže vaše vlastní ochrana je nulová, a spoléháte na ochranu od někoho jiného, o které nevíte nic, ani jestli vůbec existuje. A tomu říkáte „zabezpečení“.

"Proto jsem NAT přirovnával k turniketu místo dveří do bytu v bytovém domě."
Proč to nepřirovnat spíše k té vrátnici nikoliv "místo" ale "navíc" ke dveřím v bytovém domě? Přímá komunikace jsou dveře z bytu přímo na ulici. Kdokoliv jde kolem, může si vyzkoušet jejich pevnost, klíč pod rohožkou nebo jestli někdo nezapomněl zamknout. V případě NATu máte před těmi dveřmi z bytu navíc vrátnici, která uplatňuje různý způsob řízení přístupu. Může to být vrátnice někde v knihovně, kde pustí každého nebo se vrátný aspoň zeptá, za kým jde. Když někdo projde vrátnicí, může zkoušet dveře bytů, jako by je jinak mohl zkoušet přímo z ulice. Zloděje může přes vrátnici neúmyslně provést i někdo z obyvatelů.

U toho IPv6 jsou těch dveří z ulice biliony, takže zloděj nebude zkoušet jedny po druhých a musí jít najisto. Ovšem také nelze vyloučit, že zloděj získá přesné číslo dveří. Takže je třeba ty dveře zabezpečit.

Kdybych psal botnet pro IPv4 adresy pro jinou síť, tak tam budu mít přesně tuhle podmínku.
Lokální síť znám (masku i vlastní adresu) a pročuchám to normálně v cyklu jako první. Co najdu, to infikuju. Udělám si tak zálohu v lokální síti, kdyby tenhle stroj někdo odstavil.
Ve druhým kole se pokusím hledat další cíle. Vygeneruju adresu a zkusím na ni zaútočit. Ale je určitá množina adres, na který se z lokální sítě nepodívám, protože je chytne první správně nastavený firewall a spadnou do logu. Nechci se nechat odhalit a nechci čekat na odpovědi, který nepřijdou. Takže když se vygeneruje něco z té množiny, rovnou to zahodím a zkusím jinou adresu.
To, že do téhle množiny zapadne i LANka, ve které sedím, je úplně jedno. Když se generují cizí adresy, svoji síť už mám proskenovanou a infikovanou, takže nevadí, že vypadne.

A navíc to má i další výhodu. Když se k tomu dostane nějaký tydýt, co nerozumí sítím, tak si bude myslet, že za NATem napadnu maximálně jeden stroj a bude řešit ten. A že má napadenou celou síť ho nenapadne, protože přece ostatní stroje kolem nesplňují tuhle podmínku...

Vyhledejte si Googlem „botnet IoT“. Kterýkoli botnet, který takhle najdete, se pravděpodobně skládá z velké části ze zařízení za NATem. On totiž dnes neexistuje způsob, jak by mohlo velké množství IoT zařízení mít veřejné IPv4 adresy. POkud by dnes někdo vyrobil IoT zařízení, které bude vyžadovat veřejnou IPv4 adresu, bude to zařízení prakticky neprodejné. Naopak pokud by měl někdo spoustu volných IPv4 adres, určitě je nepoužije tak, že na ně pověsí IoT zařízení. A botnet, který by se specializoval jenom na zařízení s veřejnou IPv4 adresou, by byl maličký a nepřinášel by žádnou výhodu oproti botnetům ze zařízení, která jsou za NATem.

ale ked teda ste vygooglili "bottnet z IoT obsahujuci relevantne percento zariadeni za NATom", mozte sa s nami podelit o tuto znalost.

(ocividne Mirai, co nasiel vas sparingpartner, take nie je)

--

inak len tak na okraj: pocet IPv4 x pocet dostupnych portov mi pride celkom dost na to aby z toho bolo mozne vyskladat aj niekolko bootnetov. Takze si musite najst lepsi argument, ked to skusate pouzit ako existencny dokaz existencie vami definovaneho objektu.

pocet IPv4 x pocet dostupnych portov mi pride celkom dost na to aby z toho bolo mozne vyskladat aj niekolko bootnetov
Netušil jsem, že jde nacpat tolik nesmyslů do jedné věty.

hmm... zaujimave... ste dvojicky alebo len duchovne spriazneni?

obaja miesto jednoduchej odpovede si vyberiete uplne zbytocnu cast prispevku s pocitom, ze k tomu musite povedat nejaku zbytocnost.

Ale som rad, ze zjavne s tym IoT bootnetom to bol nezmysel. Uz som sa zlakol, ze mi nieco v zivote uslo.

Pokud vidíte dvě reakce na svůj příspěvek ze 17. 6. 20:28, vysvětluje to, proč jsou vaše příspěvky tak zmatené.

Hlasce "proste to nejde" se osoby znale neprekvapive vysmeji. NAT bezpecnost nezvysi - mnohdy prave naopak. Popsane o tom jsou stohy papiru (doslova).

Tak ještě jednou prosím, NAT není firewall.
Zde na root.cz stále je velmi vydařený článek přesně na námi diskutované téma https://www.root.cz/clanky/proc-neni-nat-totez-co-firewall/

Typickým příkladem proč NAT není firewall je použití NATu na Cisco routeru (určitě i jiný výrobce, ale já znám hlavně Cisco). Ty zařízení nemají firewall, přesto umí překlad adres, ale před útoky z venku vás prostě neochrání. Paket určený pro vnitřní síť bez rozpaků doručí dovnitř. A pak postačí aby váš ISP měl bezpečnostní incident a máte v té chvíli problém i vy.

K tomu Use Case 1:
Včera ve 14:14 Filip Jirsák psal: Ne, NAT ani SNAT nezabraňuje komunikaci z venku. Komplikuje ji oprávněnému uživateli, ale nezabraňuje jí.
Ty teď popisuješ, jak to jde udělat, ale po tom, co uživatel vrtá do nastavení routeru. Rád bych jenom podotknul, že je to jaksi činnost navíc, kterou musí člověk umět. Pokud to neumí BFU, je to komplikace, protože ji musíš udělat za něj, nebo ho na to proškolit. Navíc je tam podmínka nebýt za CGNATem.

Stejně tak zřídit server někde na veřejné IP adrese znamená vybrat poskytovatele, zaplatit službu, nakonfigurovat to, otestovat to,... Zase další komplikace.

Docela se divím, že se o tom s Jirsákem hádáš, když to vidíš stejně.

K tomu Use Case 2:
Píšeš: Pokud ma Lojza pristup k lince, tak jste kompromitovan nezavisle na nasazene halde technologii, proste jste MITM = boss. Neni to relevantni k NAT ani IPv4 - vidi prece pakety na jeho lince. Problem neni resitelny zadnym zpusobem.
V tom případě ale nechápu, proč ty a tvoje sekta prezentujete svatý NAT jako univerzální ochranu před tím, aby zařízení zvenčí jakkoliv kontaktoval kdokoliv nepovolaný. Můžeš nějak, místo útoků ad hominem, vysvětlit, jaký útok a jakým způsobem by asi tak měl samotný NAT, bez asistence dalších bezpečnostních mechanismů, zastavit?

A ne, MITM neznamená, že útočník je king. Na to jsou zase jiný metody zabezpečení. Tady šlo jenom o tvoje tvrzení o filtraci provozu NATem. Zabezpečení má několik vrstev, každá řeší něco jinýho a NAT mezi ně nepatří. Proto jsem v podmínkách definoval jako podmínku prolomení to, že je doručen paket zvenku na zařízení.

Ale je fér přiznat, že jsem večer už byl unavený v tom use case 2 jsem udělal chybu. První doručený paket byl FIN, a dokonce spustil akci na koncovým zařízení.

Navíc si ještě dovolím podotknout, že v cybersec kurzu nás učili, že nemáme útočníkovi věci zjednodušovat, třeba tím, že prozradíme v chybovým hlášení druh a verzi produktu, protože pak může přesně cílit útok na konkrétní zranitelnost. Tady jede 24/7 spojení na nějakou IP adresu a port, to je na 99% tunel z nějaké běžící IoT věci ve vnitřní síti, co má překonat NAT. A s minimálně 60% pravděpodobností MQTT. Svítí to jak maják. A jediný důvod, proč to vidí je, že tam je NAT. Bez něho proletí v případě potřeby 10 paketů mezi neznámou IP adresou a nějakou adresou s prefixem v Pepově síti a útočník, aby to odhalil, musí zrovna v té chvíli logovat data. A když to náhodou chytne, tak než projde logy a zjistí, která páčka, tak session skončí a nestihne do ní zasáhnout.

Marena ty fotky budem at stale v tom cloude. Rovnako vsetky tie IiT udelatka, kamery,... pojdu stale cez cloud.
Nebol to len NAT preco to vzniklo. Je jednoduchsie spravovat clodu ako riesit support Mareny a podobnych, ze preco im to nejde. Rovnako to je pre nich bezpecnejsie.

Ale tohle je o možnosti volby. Máňa může mít klidně fotky v čmoudu, ale to není důvod nutit Lojzu, aby je tam měl taky.

Pokud jde o IoT, tak to je jednoznačně lepší bez čmoudu. Prodej 50k zařízení a budeš udržovat až 100k spojení v reálným čase skrz server (zařízení + mobil majitele, například). A tím, že ten server je SPOF a jak klekne, máš velký problém...

A IPv6 nativně podporuje IPSEC. Zapneš a je to zabezpečený... (původně to mělo být povinně, ale malý krabičky by to nedaly).

Pokud jde o ztrátu dat, tak platí zálohovat, zálohovat, zálohovat. O fotky přijdeš nejenom, když ti klekne NAS, ale i když provozovatele čmoudu chytne rapl a změní podmínky... V tom si nevybereš a záloha se vždycky hodí

Mas ku vsetkemu moznost volby? Ani nahodou. Moznost volby nieje zakaldne ludske pravo.
To je trh/podnikanie.
Chod, podnikaj a predavaj to be cmoudu. lojzu nikto nenuti ich tam tiez. Lojza ma moznost volby, len tie volby s amu nemusia pacit ale to je uz druha vec.

Hadam si to tie firmy spocitali a porovnali plusy/minusy, ze sa vidali cestou cmoudu. Myslis si, ze im ten cmoud bezi na jednom serveri? Ze im to len tak klakne? Aj keby, tak velky problem neubdem mat. Plus nevsimol som si zeby internet a diskusie boliz aplavene nefunkcnostou cmoudu.

Ako som psial niekde inde IPv6 povazujem viac za akadamicky protokol. IPSEC ako nativnu vec povazujem za jednu z tych akademicky veci, ktora sa minula realite.

Do nasazení IPv6 se nikdo moc nehrne, protože to je poměrně komplikované vzhledem k potenciálním přínosům (pro ISP), na druhou stranu nehrajme si na to, že by čmoudové řešení bylo lepší - to rozhodně není. Minimálně z hlediska soukromí, bezpečnosti, doby podpory a podobně.

Nésu síťař, takže - byl by praktický popis problému, který to tak moc komplikuje?

Poslední WiFinář nemoh bejt takový kopyto, aby to nezvládl nakonfigurovat, když mou veřejnou IP adresu protáhl NATem ne soukromý rozsah a potom s toho zpátky dělal "veřejku" se třema portama. Pustit cokoliv přímo rozhodně složitější nebude a i přesto to nechtěl zvládnout.

Jasně. Takže tvrdíš, že:
- Kupovat, provozovat a udržovat CGNAT je levnější, než to pustit rovnou.
- Logovat z CGNATu, kdo kdy kam lezl kvůli policajtům, archivovat to a hledat v tom je levnější a jednodušší, než se prostě podívat do tabulky a říct "Tenhle prefix má přidělenej Lojza Průša, Úchylná 550/12"
- Kupovat další IP adresy za stovky dolarů, pokud chceš růst, je efektivnější, než si na to vyčlenit nějaký blok z miliard adres, který už máš k dispozici.
- Je levnější udržovat na uplinku při MS v hokeji tisíce streamů toho samýho, než využít multicast a klonovat si to až na routeru ve vnitřní síti

A teď tu O poslanci, co nikdy nezalhal

V bývalé práci jsme na jednom produktu vyslyšeli volání po ovládání z mobilu odkudkoliv. Věř, že jako výrobce jsme si počítali každý cent, ale díky těm <píííp píííp píííp píííp> ISP nejlevnější řešení - TCP po IPv6 - padlo hned a dopadlo to tak, že:
- vývoj sežral o 2800 člověkohodin víc, protože aplikace do čmoudu, testování,...
- 30% z výrobní ceny bylo určeno jako žrádlo pro provozovatele čmoudu, bez kterýho by to nekomunikovalo
Takže výrobek, který by mohl jít z fabriky za 100€, prodáš do velkoobchodu za 150€ jenom kvůli debilnímu NATu. Když započítáš přepravu, marži pro velkoobchod a maloobchod, DPH... Kolik tak ten rovnák na vohybák může ve finále stát zákazníka? 70-120€?
A ty jako výrobce musíš řešit, z čeho ten čmoud platit po celou dobu životnosti výrobku... Nevíš, jestli ti to za rok nezdraží kvůli cenám energie atd.
Pro výrobce IoT věcí fakt to poslední, po čem by toužili, používání čmoudu. Buďto se musí uskromnit, abych nebyl cenově výrazně nad konkurencí, nebo plánovat kratší životnost výrobku kvůli vypnutí čmoudu a vnucení novýho kusu, kde je další předplatný, nebo výrobek jenom pronajímat. A je tam závislost na třetí straně, která je obecně blbě...

Tak pokud se to konkrétně Vás netýká, tak máte můj respekt, nicméně on ten čmoud (který nenávidím a odmítám) má jednu drobnou výhodu - představit si IoT které komunikuje směrem ven na nějaký čmoud a tam si vyměňuje data si dokážu celkem v pohodě (mnohem radší self-hosted, ale to je fuk).

Z představy průměrného dodavatele IoT, jehož zařízení je otevřené světu, a které je chráněné jen 2^64 obskuritou (kterou nejspíš naruší nějaký DynDNS nebo něco takového) mě běhá mráz po zádech.

Ty IoT krámy by se stejně slušelo schovat za VPN nebo alespoň nějakou proxy s omezením provozu, stejně jako v IPv4 (protože díry, protože potenciálně nebezpečné dopady při průniku, protože se výrobce po čase vykašle na aktualizace, ale nikdo soudný to zařízení jen kvůli tomu nevyhodí). Na druhou stranu mít možnost si po zralé úvaze na jakémkoliv zařízení spustit službu přístupnou potenciálně* z celého internetu by bylo velmi žádoucí.

* Pořád si můžeme přístupnost doladit firewallem.

14. 6. 2024, 09:22 editováno autorem komentáře

Co přesně znamená "Ty IoT krámy"? Pět let starý, neupdatovaný klon BSD se samo domo tuningem a zapnutým telnetem? Linuxový stroj, kde je update 1x za dva měsíce a SSH se povoluje po sériové konzoli? Nebo jednočip, který nemá možnost spouštět, co není v ROMce, nemá skriptování a nemá ethernetový bootloader?

Cokoliv z toho, moc bych mezi tím v principu nerozlišoval. Jde o to, že zranitelnost může být kdekoliv - u jednočipu možná s menší pravděpodobností výskytu, ale i opravy; u nějakého složitějšího systému pravděpodobnost výskytu téměř jistá, hlavně když to někdo dobastlí, aby to tak akorát fungovalo a víc se tím nezaobírá.

Pak samozřejmě záleží na dopadech - pokud si bude někdo číst data z wifi teploměru nebo mi zhasne žárovku, tak se nic moc neděje. Pokud mi ale hackne čínskou rychlovarnou konvici, může to být kardinální průšvih.

V obecné rovině mi přijde nejbezpečnější to všechno naházet do jednoho pytle a považovat apriori za děravé a potenciálně šmírující, a podle toho s tím taky zacházet.

Já se děsím spíš těch, co tvrdí, že za NATem jsou v bezpečí. Ono je to spíš naopak.
Už jenom to, že se udržuje spojení s čmoudem, prozradí, že za touhle adresou je tolik a tolik takových a makových zařízení. Podle délky paketů, frekvence, cílové adresy,... se to dá docela dobře uhodnout. Podstrčit paket s podvrženou zdrojovou adresou taky není problém a proletí NATem jak pendolino dodávkou. DoSnout IoT krabičku v IPv4 taky není problém, zasáhnout do několik hodin / dní existujícího spojení je jednodušší, než když se náhodou někde objeví nečekaný spojení odnikud, proletí 20 paketů a zase zmizí.

Teorie a zbytecne obavy.

Pokud by NAT byla technologie zneuzitelna v takovem meritku jak si myslite, tak ho dnes nikdo neprovozuje... a je tomu tak? no neni. NAT se tesi oblibe, protoze kazdy domaci router ho ma zaplej by default. Tudiz NAT je v kazde rodine.

Za kolik a jakych incidentu muze samotny NAT ? Rekl bych ze temer za nula - vzdy jsou jine, uspesnejsi, jednodussi vektory utoku. A samotny nat nestaci - jak uz tady nekdo psal, potrebuje mit na routru cinklej FW a nejakeho iniciatora zevnitr.

Jestli nejaky ISP dovoluje podvrhnout zdrojovou IP (aka nema na svem hranicnim routru nastaveni typu rp_filter=1) a jede open relay.. je problem sam o sobe, ale nikterak vam nepomuze. A jak caste jsou tyhle utoky? Znova nic nic nic, co by bylo na dennim poradku.

DoS/DDoS neni bezpecnostni kompromitace, jen provozni opruz.

NAT je v každé rodině ne kvůli bezpečnosti, ale proto, že každý rodina chce na internet a to nejde bez IP adresy pro každý zařízení. A pokud ta rodina dostane maximálně jednu IP adresu na přípojku, tak jinou možnost nemá.

Zeptat se, za kolik incidentů může NAT, je stejný, jako zeptat se, za koik vražd může sekera. Odpověď je, že za žádný, za všechny může ten, kdo tu sekeru držel v ruce, když k té vraždě došlo nebo nevědomky ten, kdo sekeru neschoval před agresivním opilcem...

Podvrhnout zdrojovou adresu nemusí ISP, ale může to udělat kdokoliv. A není to omezeno na lokální adresy. Když ze zařízení ve svojí síti pošlu UDP paket na obecnou veřejnou adresu, NAT ji pošle ven a zapamatuje si mou adresu. A když dojde odpověď z té veřejné adresy, podívá se o záznamů a prohodí odpověď zpátky na zařízení, co si ten paket vyžádalo. Prostě chvíli na NATu zůstane otevřeno okno na odpovědi... A aby tam to okno nebylo, tak je nesmím otvírat / udržovat otevřený, ale to s NATem neudělám, protože bych se nedozvěděl, že se mnou chce komunikovat někdo z vnějšího světa.

Samozřejmě, že pokud je médium přípojky 5GHz WiFi, může být celkem triviální se do toho nabořit nezávisle na ISPíkovi a pak už se i ta vnitřní adresa dá zneužít... Fantazii se meze nekladou.

Btw, zajímavější je si dojet autem před dům oběti a nabořit se po WiFi přímo do LANky, pokud nechává zabezpečení jenom na routeru a považuej vnitřní síť za bezpečnou... A pak je úplně jedno, na jakým protokolu to jede.