Ebből a cikkből szerintem nagyon fontos kiemelni egy részletet:

amennyiben a spekuláció helyes, ebből az következik hogy ezek az eszközök már régen egy botnet részei voltak. az adatvesztés az már konkrétan azért történt mert a puppet masternek nem volt tovább szüksége rájuk, factory reset, nyomok eltüntetve. a júzerek adatai járulékos veszteség.

miért lényeges ez? azért, mert végre egy konkrét, felhasználókon csattanó gyakorlati példa arra hogy miért nem szabad random ementáli sajtokat kiengedni a világhálóra. Ebből a szempontból kifejezettten üdvösnek tartom hogy a júzerek jelentős része megszívta, végre egy helyzet amiből testközelből lehet tanulni.


egyben arra is rávilágít miszerint az hogy nem látsz téged hátrányosan érintő nem üzemszerű működést az nem jelenti azt hogy az eszközöd nem egy botnet része.

[ Szerkesztve ]

A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)

A gond az, hogy amikor vásárolnál egy hasonló célú terméket, fogalmad sem lehet róla hogy az ementáli sajt-e. Tehát nem tanulnak semmit a felhasználók, mivel legközelebb sem lesz esélyük jól dnteni.

"Seems like humanity needs war and famine to correct itself."

Az IT-s cegeket kotelezni kellene a minel hosszabb supportra. Ha funkciobovites nincs is, de biztonsagi frissiteseket adjanak azert ki a regi cuccaikra is. Amugy meg jol fenekbe kellene billenteni oket, hogy ne nyomjanak ennyi xart ki! Elkepeszto, hogy milyen minosegben jonnek ki hardverek, szoftverek. Csomo bughalmaz…

Dicsõséges nagyurak, hát Hogy vagytok? Viszket-e ugy egy kicsit a Nyakatok? Uj divatu nyakravaló Készül most Számotokra... nem cifra, de Jó szoros.

a legszomorúbb, hogy azt a gány php kódot valószínűleg 5 perc lenne javítani, de harmadik fél nem tud belenyúlni egyszerűen. Vagy éppen a root exploittal lehetne hozzáférni a fájlhoz, hogy megjavítsák. Most meg ugye az a mondás, hogy talán valaki berágott a wd live-okon futó botnetre és így iktatta ki a hálózatot.

Ma volt épp egy érdekes beszélgetésem egy kollégával. Hogy ipv4-en az otthoni routerek igazából nem védenek szinte semmit a mögöttük lévő eszközök terén. Mivel, ha tudják a belső hálózati címet, akkor lehet internetről egy sima natos routerre küldeni olyan adatcsomagokat, amit simán beenged belülre a router. A visszafelé menő adat már problémásabb, de most a WD live példánál nem is kell visszamenő adat. Mókolt csomagokkal kívül, az internet felől is meg lehet elvileg hívni a belső hálózaton lévő eszköz címén azt a php fájlt. Mittudomén 192.168.1.33/factory-resest.php akármi.

Azt meg internet felől is látják, hogy a cikkben emlegetett botnet milyen ipcímekről támad. És akár az egész belsőhálózati tartományra meg tudhatják hívni a factory reset próbát, aztán, ha olyan belső címen ott egy wd live box, akkor letörli magát.
Szóval a Nat nem tűzfal.

Ja és a téma úgy került elő hogy ipv6-on meg simán kinn lóg az interneten sokaknál úgy az összes otthoni eszköz, hogy nem is tudatosul a felhaszánlóban ez. Lehet, hogy van a szolgáltatói routeren olyan beállítás, ami elvileg tűzfalként nem enged a belső eszközökre külső csatlakozást.... viszont például van olyan elterjedt szolgáltatói eszköz, amelyiknél semmi hatása nincsen a kapcsolónak. Anno úgy vettem észre ezt, hogy az egyik szolgáltató netjén egy gépem ipv6 címére rápróbáltam más szolgáltatói mobilnetről is... és válaszolt a gép a pingre... hoppá. Szóval, ha ipv6 címet is kapna a wd live, akkor még csak nem is kell olyan hálózati csomag hekk, ami ipv4 kapcsán belső hálózatba jutna, hanem eleve publikusan ott van a neten, bárki rácsatlakozhat. Ez jusson eszébe mindenkinek, akinek NAS vagy pécén megosztott könyvtár van hálózatba, pláne jelszó nélkül. Lehet, hogy bárki által elérhetően ott az interneten és ha valaki átpörgeti az ip címeket, akkor kívülsől simán elérhetőek.

[ Szerkesztve ]

nem is kell hogy fogalmad legyen róla., elég azt megnézni hogy kell-e neki hálózati kapcsolat. ha a funkcionalitásának az értelmes része elvégezhető hálózati kapcsolat nélkül, ne vedd meg. nem bonyolult ez.

A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)

Egy tcp kapcsolatnal hogy lehet, hogy nem kell visszameno adat?

Ha meg rosszul allitod be a NAT-ot, az nem azt jelenti, hogy nem vedene a NAT. Rosszul bealltiva barmi lehet veszelyes.

[ Szerkesztve ]

Ez a NAT mögé kéretlen becsatlakozás (Slipstream attack) védhető friss böngészővel. Azért, mert úgy kezdődik a támadás, hogy meglátogatsz egy rosszindulatú weboldalt, és az azon elhelyezett böngésződben futó JavaScript a belső hálóról nyit lyukat a NAT-on.

Az mondjuk irdatlan nagy hiba, ha egyesek olyan routerekt osztanak otthoni felhasználásnak, amin engedélyezve van az IPv6 (és azon nem lesz NAT), de nincs rajta "state estabilished" jellegű tűzfal szabály. Nem lehet, hogy csak a pinget engedte át az a tűzfal?

Egyébként slipsteram alapötlete IPv6 tűzfal kicselezésére is működőképes, szóval kicsit pontatlan, hogy NAT elleni támadásnak mondjuk. Bármi, aminek támogatni kell a visszacsatlakozást, és számomra felfoghatatlan merészen nem követi, hogy hol tartunk a TCP streamben, az átverhető ezzel.

Ezek a NAT mögé visszacsatlakozós trükkük azon alapulnak, hogy vannak protokollok (mint pl. FTP, meg ilyen VoIP borzalmak), amiknél te kimész a szerver felé, és ő egy tőle indított másik csatlakozással visszacsatlakozik oda, ahova te kéred. Ezt a NAT-os routerek kénytelenek támogatni. (Vagy hát, főleg otthoni felhasználónál nem nagyon kéne alapból, de hát alapból bennhagyják.) Ezek után, ha valahogy rávesznek egy belső hálón lévő gépet, hogy egy ilyen csatlakozást utánozzon le, akkor kész a baj. Böngészőt pl. rá lehet, ha nem elég friss, bár kell hozzá a router (valójában a Linux kernel) számomra meglepő hozzáállása is.

[ Szerkesztve ]

Te a hole punching-ra gondolsz. azbest meg azt emlegette, hogy a masquerade rule-t nem csak a belsohalozati cimekrol engedelyezed(vagy a wan-on kifele), hanem a wan felol is(azaz nem irsz melle feltetelt, csak siman odavagsz egy -j MASQUERADE szabalyt). Ekkor siman natol kintrol befele is, nem csak forditva.

[ Szerkesztve ]

A kollégám kifejezetten source ip spoofing kapcsán mondott valamit, de ahogy utánakerestem az másra jó. Az nem a belső hálózat támadására, hanem arra hogy egy routert kvázi ugrópontként tudnak használni, hogy más hálózatot támadjanak. [link]

Pár hónapja volt... ha jól emlékszem be is tudtam ssh-zni ipv6-on a gépre kívülről, nem csak ping ment. Bár újra kéne próbálnom, mert több hónapja volt. A legnyomorékabb dolog, hogy elrejve meg ott van a szolgáltatói eszköz menüjében olyan opció, amivel meg ki lehetne ütni ténylegesen azt, hogy publikus címet kapjanak a belső gépek. Gondolom nem akarják, hogy piszkálja a user, mert aztán csak hibát okoz, ha elállítja. Bár a kolléga szerint csúnya az is, ha local link címet osztatok ipv6-on a belső hálón

#11Reggie0
persze, hogy jó eszközökkel, meg akár dedikált tűzfalakkal is meg lehet mindent oldani. Viszont a szolgáltató által osztogatott eszköznél elég kellemetlen, ha lyukas, mint a sajt és le vannak tiltva / el vannak rejtve azok a beállítási lehetőségek, amivel magad állíthatod. Az a mondás, hogy központilag tiltasd le az ipv6-ot és ne a routeren játsz vele.

[ Szerkesztve ]

Jobb routerekben ki lehet utni. A megjobbak tudnak IPv6-ot is NAT-olni.

Az első (és utolsó) D-LINK 320 után épp ilyesmitől tartva dobtam a kész NAS-okat, és azok szoftvereit. Inkább egy Debian, amit melósabb felhúzni, beállítani, de jobban kézben van tartva.
#11Reggie0
Hihetetlen, hogy pl. a MikroTik nem tud v6-ot NAT-olni, és a dinamikus prefixekre sem lehet felkészíteni a tűzfalát. Van egy home serverem, őt ki akarom engedni (mármint bizonyos portokat), de semmi mást nem. A DIGI hetente váltogatja a prefixet. Nagyon sokat keresgéltem megoldásokat, végül mivel nem találtam, magamnak kellett írni szkriptet. Így már működik.

Sajnos az IPv6-nál ezek a rosszul kezelt biztonsági kérdések a routerek / HGW-k oldalán is csak az ellenérzéseket növeli, itt a fórumon is nem egy topikban csuklóból javaslat bármilyen problémára, hogy biztos az IPv6 ki kell kapcsolni. Pedig a normális dual stack-kel nincs gond, csak rendesen be kell lőni.

[ Szerkesztve ]

üdv, adika4444

Hogyan lehet elkerulni az ilyen problemakat?
Bevallom nem nagyon ertem mirol beszelgettek, amit en eddig megtettem a router-en az az UPNP kikapcsolasa es manualis portforward arra a 2-3 portra aminek ki kell menni.
Ubuntu Server 20.4 van a NAS-on, de peldaul az UFW nincs beallitva rajta.

Szia!

"Az mondjuk irdatlan nagy hiba, ha egyesek olyan routerekt osztanak otthoni felhasználásnak, amin engedélyezve van az IPv6 (és azon nem lesz NAT), de nincs rajta "state estabilished" jellegű tűzfal szabály."

Az még nagyobb hiba hogy a IPv6 még ki sem kapcsolható, én is csak a kliensekben tudtam letiltani!

Ez a DIGI féle TP-Link AX10 (AX1500) router, a tűzfalához (ha be van is kapcsolva?) meg nem lehet hozzáférni!

Ui:

Az előzőleg osztogatott, (csak Romániában volt elérhető) routerrel nem volt ilyen probléma!

[ Szerkesztve ]

“Lex malla, lex nulla. A bad law is no law.” A rossz törvény, nem törvény! DW: The Moment is Coming || Doctor Who BBC www.youtube.com/watch?v=uZAO6E2x9xs

Mikrotik nagyon el van uszva a fejlesztessel. Az uzleti modeljuk ezen reszet nem is ertem igazan, hogy miert oda helyezik a fokuszt ahova. Wifi-ben is nagyon lemaradtak.

talán mert elsősorban nem a wifis SOHO a fő profiljuk?

A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)

Akkor meg miert nincsen rendes IPv6 es vezetekes eszkozkon miert van ekkora kuszasag az interfeszekben? Vegen kiderul, hogy semmi sem a fo profiljuk

Mondjuk, ha a wifis SOHO nem a fo profiljuk, akkor miert ontjak a 100. wifi AP-t illetve LTE-s wifi routert, illetve inditottak a mesh-re hajazo routeruket(lte-vel is)?
Az elmult idokben hoztak ki az audience-t, a chateau-t, hap ac3-mat, mikozben vezetekes vonalon helybentoporgas megy mar miota. Persze AX wifi sehol, MU-MIMO epphogy csak disznek a beta OS-en es az is eleg tre.

[ Szerkesztve ]

lehet hogy én vagyok lemaradva, nekem a mikrotik mindig is a "megfizethető enterprise" szinonímája volt, bár se öreg se szaki nem vagyok. mindenesetre amiket írtál az nekem némileg újdonság.

A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)

Szegeny ember ciscoja

Amugy az volt, aztan ahogy gyorsult a piac minden szegmensben ok lemaradtak a nagyreszeben. Ilyen pl. a wifi, de a top routereikkel(CCR) is szivas van, mert a proci amit hasznalnak mar elegge eletciklusa vege fele jar, a kernel dobta a supportot a tilera procikhoz, igy arra is nekik kell eroforrast allokalni, hogy az ujdonsagokat backportoljak. RouterOs v7 mar evek ota beta. v6-ban pedig olyan alap dolgokat nem tudtak implementalni, mint pl. az UDP alapu openvpn kapcsolat, mert az openvpn-t sem importaltak, hanem ujraprogramoztak maguk. De ezen felul meg az SHA512 digestet sem tudja(pedig azt max. kb. 2 nap lenne leprogramozni), sem a regi, sem az uj OS. Szoval nagyon durva hianyossagokat szedtek ossze nehany regebbi rossz dontes miatt. Tul kicsi ceg ahhoz, hogy mindent sajat erobol oldjanak meg, ha a linuxos kozosseg mas iranyba kezd fejleszteni, muszaj lenne igazodniuk, mert igy nem birjak a tempot.

[ Szerkesztve ]