Fórum Root.cz
Hlavní témata => Sítě => Téma založeno: stahovac 29. 10. 2013, 16:59:29
-
Dobry den, na jednom pocitaci v siti mam Windows a uTorrent
Po letech bezproblemoveho uzivani jsem si vsiml velmi divne veci, kdyz v seznamu peeru vidim jednu konkretni IP, ktera uplne ignoruje limit na maximalni upload, ktery mam pro dany torrent nastaveny.
Asi nejaky bug utorrentu bych si rekl.
ALE:
Na svem hranicnim routeru mi bezi linux(Tomato), takze jsem se tu IP adresu pokusil v iptables zablokovat
timto prikazem
iptables -A INPUT -s 172.24.105.7 -j DROP
kdyz si vyjedu iptables -L , tak vidim, ze pravidlo by melo byt aktivovane
DROP 0 -- 172.24.105.7 anywhere
Po naslednem zapnuti a vypnuti utorrentu, se na me ta IP adresa opet napoji!
Vubec nechapu, jak je to mozne? Kde jsem udelal chybu? Jak proboha tu adresu zablokuji? :) Muj hranicni router by ji mel preci zahazovat.
-
Strelam z boku, ale nemalo by to pravidlo byt na FORWARD chaine? INPUT sa tyka veci ktore prichadzaju na ipku daneho routra.
-
aha, tak jsem zkusil tu IP adresu zadat do vsech chainu z obou smeru
muj zoufaly pokus
iptables -A FORWARD -d 172.24.105.7 -j DROP
iptables -A FORWARD -s 172.24.105.7 -j DROP
iptables -A INPUT -d 172.24.105.7 -j DROP
iptables -A INPUT -s 172.24.105.7 -j DROP
iptables -A OUTPUT -d 172.24.105.7 -j DROP
iptables -A OUTPUT -s 172.24.105.7 -j DROP
iptables -A wanin -d 172.24.105.7 -j DROP
iptables -A wanin -s 172.24.105.7 -j DROPP
iptables -A wanout -d 172.24.105.7 -j DROP
iptables -A wanout -s 172.24.105.7 -j DROP
# iptables -L
Chain INPUT (policy DROP)
target prot opt source destination
DROP 0 -- anywhere mujhostname.cz
DROP 0 -- anywhere anywhere state INVALID
ACCEPT 0 -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT 0 -- anywhere anywhere
ACCEPT 0 -- anywhere anywhere
DROP 0 -- 172.24.105.7 anywhere
DROP 0 -- anywhere 172.24.105.7
Chain FORWARD (policy DROP)
target prot opt source destination
ACCEPT 0 -- anywhere anywhere
DROP 0 -- anywhere anywhere state INVALID
TCPMSS tcp -- anywhere anywhere tcp flags:SYN,RST/SYN tcpmss match 1461:65535 TCPMSS set 1460
ACCEPT 0 -- anywhere anywhere state RELATED,ESTABLISHED
wanin 0 -- anywhere anywhere
wanout 0 -- anywhere anywhere
ACCEPT 0 -- anywhere anywhere
DROP 0 -- 172.24.105.7 anywhere
DROP 0 -- anywhere 172.24.105.7
DROP 0 -- 172.24.105.7 anywhere
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
DROP 0 -- anywhere 172.24.105.7
DROP 0 -- 172.24.105.7 anywhere
Chain wanin (1 references)
target prot opt source destination
ACCEPT tcp -- anywhere X tcp dpt:1218
ACCEPT udp -- anywhere X udp dpt:1218
DROP 0 -- 172.24.105.7 anywhere
DROP 0 -- anywhere 172.24.105.7
Chain wanout (1 references)
target prot opt source destination
DROP 0 -- anywhere 172.24.105.7
DROP 0 -- 172.24.105.7 anywhere
zase jsem vypl a zapl utorrent a ta IP se pripojila zase! :(
prosim, nejake napady?
-
BTW: To je privatna adresa, cize z Internetu to asi nebude.
-
ta adresa nepochazi na 100% z me site a pravdepodobne ani ze site meho ISP, tracert smeruje nekam do internetu pres klasicke hopy ktere znam a pak uz jsou ty ktere neznam
-
NetRange: 172.16.0.0 - 172.31.255.255
CIDR: 172.16.0.0/12
OriginAS:
NetName: PRIVATE-ADDRESS-BBLK-RFC1918-IANA-RESERVED
http://en.wikipedia.org/wiki/Private_network
-
tracert jeste nez jsem si to zablokoval v iptables
Tracing route to 172.24.105.7 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms muj router[192.168.1.1]
2 111 ms 139 ms 170 ms brana_meho_isp [ip_brany]
3 431 ms 428 ms 264 ms ip-85-132-191-35.pamico.cz [85.132.191.35]
4 338 ms 170 ms 51 ms 172.24.123.185
5 176 ms 197 ms 214 ms 172.24.123.66
6 176 ms 62 ms 90 ms 172.24.117.34
7 229 ms 98 ms 10 ms 172.24.105.7
pokud je ta adresa pristupna pouze v ramci meho ISP, tak stejne bych ji nemel mit problem blokovat. Kabel od providera mi vede do WAN portu... Vubec tomu nerozumim.
-
Chjo .... to ze mas ty (a nejspis i tvuj ISP) blbe nastaveny routery ...
Na routeru bys mel mit v pravidlech na forwardu (jinam do davas celkem zbytecne) zakazany vsechny privatni rozsahy = nemelo by (zadnym smerem) projit nic, co ma src/dst v jednom z tech rozsahu. Samo za predpokladu, ze mas na routeru verejny IPcko. A ne, NAT ti opravdu v nicem nepomuze. To je zaklad naprosto jakyhokoli zabezpeceni interni site. Totez by samozrejme mel mit ISP na KAZDYM routeru - neb dle RFC router nesmi odroutovat paket s takovejma IPckama (mineno opet samo ve verejny siti).
Mno a pro tvuj ucel, to pravidlo ve forwardu by to melo bloknout => jednoznacne je to ve tvy siti. Ostatne, podivej se na country u toho pravidla - tece ti pres to vubec neco? Pokud sou nulovy, tak neni co resit.
-
Prv je ACCEPT az potom je DROP...
Daj tie iptables prikazy nie s -A ale s -I aby sa dostali hore.
-
Dekuji za radu. -I posunuti nahoru pomohlo, nemusel jsem utorrent restartovat.
Ted me napadlo, ze uTorrent mozna ignoroval limit rychlosti, protoze si myslel, ze ta IP je lokalni.
j: No priznam se, ze do tech iptables hrabu ted poprve na svem routeru. Vsechno jsem doted nastavoval na webovem rozhrani a tam takovou moznost konfigurace nejspis ani nemam. Verejnou IP mam, no.
Je pravda, ze mam nastaveny port forwarding na port 1218 na pc s Windows. A tedy tento port, potazmo ta sluzba co na nem bezi by mela byt jedina napadnutelna z venku, ne?
Kdyz zminujes bezpecnost a rikas ze NAT mi nepomuze, tak jak by se pripadny utocnik mohl dostat skrz NAT bez toho, aby pouzil otevreny port o kterem vim? Jedine, co me napada je, ze bych se k nemu musel pripojit ja (backconnect).
Dekuji za objasneni
-
Tady je docela dobře popsaný jak se dá NAT "prostřelit":
http://en.wikipedia.org/wiki/Network_address_translation
Zjednodušeně řečeno, pokud nemáš "symmetric NAT", tak na tom dohromady nic neni a spousta programů to běžně dělá (Skype, zmiňovaný bittorrent, ...).
-
Já si dovolím řící, že celé tvé řešení je trochu postavené na hlavu. Ty cheš blokovat konkrétní IP adresu, ale uTorrent klient to neví a tedy můlže docházet ke zvláštním situacím.
Klidně si tuto IP blokuj i na externím firewallu (tedy ne na úrovni brány, který přímo ovlivňuje komunikující aplikace), pokud ale chceš zakázat komunikaci s tímto uzlem, měl bys ho dát na seznam v uTorrent aplikaci.
Zabráníš tak vzniku neočekávaných situací, a blokování externím firewallem bude jen pro "strýčka příhodu". Čti: úplně zbytečné, pokud ta aplikace opravdu funguje jak má. Zmiňuji to právě proto, že tak můžeš ověřit že aplikace se chová korektně, tak jak očekáváš.
P.S.
Ještě je dobré zmínit, že uTorrent bývá standardně konfigurován tak že využívá Terredo Tunel. Ty o svém nastavení nepíšeš nic. Ale pokud tvůj externí firewall (u interního by to bylo odlišné ale choval by se také jinak než předpokládáš) není úplně blbý (takové se snad dnes již ani nevyrábí), tak je možné že jsi mu dal nevhodné pravidlo.
-
Podivný Podivín: Jakym zvlastnim situacim? A jaky seznam v uTorrentu mas na mysli? nic takoveho jsem tam nenasel.
tadeas: To jsem si prohlizel a nikde konkretne nevidim, ze by resili bezpecnostni rizika. Zminuji se tam akorat o NAT loopbacku, ktery mam vypnuty.
Treba Skype ma udajne fungovat takto
"Without being too technical, each Skype client is always connected to a SuperNode (any Skype client can become a SuperNode, the SuperNode is acting as a hub). SuperNodes are always on routable open IP addresses. When a call is set up the established TCP connection with the SuperNode is used to signal that a call is coming. Dependent on the firewall status of the client the data stream is set up either as UDP (if firewall allows) or in worse case as outgoing TCP which is almost always allowed. If both clients are only allowed to do outgoing TCP calls are routed through another peer."
To je z meho pohledu backconnect a zde neocekavam, ze by me NAT nejak chranil.
U NATu ocekavam, ze me bude chranit pred prichozimi spojenimi, ktere nejakym svym programem nezinicializuji prvni ja. A to doufam dela dobre ?
-
tadeas: To jsem si prohlizel a nikde konkretne nevidim, ze by resili bezpecnostni rizika. Zminuji se tam akorat o NAT loopbacku, ktery mam vypnuty.
Tys dal hledat "security" a našlo to akorát NAT loopback sekci ne? ;D
Představme si, že máš tvůj router implementuje NAT stylem full-cone (pro jednoduchost). Připojíš se ze svého počítače (za NATem) na web rootu. Router otevře spojení z nějakého portu, řekněme 53342 na root.cz:80. Router si pamatuje, že co přijde na port 53342, má přeposlat na tvůj počítač. No a mně už stačí poslat request na <ip tvého routeru>:53342 a voilá! jsem za NATem, protože tvůj router všechny packety příchozí na port 53342 přeposílá.
U ostatních typů NATu je to obdobné, jenom složitější.
-
UPnP máš povolené?
-
tadeas: to co jsi popsal, jak by to slo prakticky zneuzit? Protoze, co se stane, az se pripojis na mujrouter:53342, tam nic nepobezi, ne? Jake ma utocnik moznosti?
Peter: UPnP nemam povolene
-
To se mi snad zda. Komunikace na LAN (kam patri ta tvoje "podivna" RFC1918 adresa) vubec neprobiha pres router. Ve firewallu na routeru si muzes nastavovat, co chces, bude to uplne jedno. Ty pakety pres nej vubec netecou.
-
Lol Phirae : ale prosimte, kdyby sis to cele precetl, tak bys zjistil, ze ta IP opravdu neni v me siti a muze za to muj ISP
-
tadeas: to co jsi popsal, jak by to slo prakticky zneuzit? Protoze, co se stane, az se pripojis na mujrouter:53342, tam nic nepobezi, ne?
V našem příkladu tam poběží prohlížeč. A samozřejmě desktopový operační systém. Ani jedno není zrovna vyhlášené bezpečností. Například (trošku ujetý, ale ani ne moc) tam můžu poslat PDFko a pokud to stihnu dřív, než root.cz odpoví, tak webový prohlížeč poslušně spustí PDF prohlížeč a máme další dimenzi bezpečnostních problémů.
Nicméně ta důležitá informace, na kterou jsi se ptal, je, že i když jsem za NATem, tak mi stejně kdokoliv může posílat packety.
-
tadeas: Jak bys neco poslal do meho browseru, pokud nebudes mit pristup na stroj, na ktery jsem ze zacatku vytvoril spojeni na port 80?
Vzdyt browser ze sebe neudela server, ktery nasloucha na portu x?
Jak se to snazim pochopit, tak bys musel mit stejnou IP jako server, ke kteremu jsem se pripojil na port 80
A nebo nekde v trase mit moznost zmenit obsah paketu co je pro me, co mi poslal ten http server
-
tadeas: Jak bys neco poslal do meho browseru, pokud nebudes mit pristup na stroj, na ktery jsem ze zacatku vytvoril spojeni na port 80?
Sry, líp už to vysvětlit nedokážu.
Vzdyt browser ze sebe neudela server, ktery nasloucha na portu x?
Browser samozřejmě poslouchá na portu x, jinak by k němu nedošly packety, které odesílá root.cz. Nenapadá mě, kde je hezky vysvětlené jak to funguje, někde na wikipedii ale asi jo.
Jak se to snazim pochopit, tak bys musel mit stejnou IP jako server, ke kteremu jsem se pripojil na port 80
Přečti si popis a prohlídni obrázek u toho full-cone NATu. "Server 1" je root.cz, "Server 2" jsem já.
-
tadeas:
Tak prece je to TCP spojeni, ktere se otevre, jsou tam nejaka konkretni sekvencni cisla, ktera se ocekavaji. Nemuzes prece jen tak prijit z cizi IP adresy a narusit vytvorene spojeni vlastnima datama,ne?
Jak se ten druh utoku co popisujes nazyva?
Jedine, co jsem nasel je TCP session hijacking / Blind attack a nejake hadani sekvencnich cisel, coz si neumim predstavit jak je v praxi treba u toho prohlizece realizovatelne, kdyz to spojeni je otevrene jen kratkou chvili.
-
tadeas:
Tak prece je to TCP spojeni, ktere se otevre, jsou tam nejaka konkretni sekvencni cisla, ktera se ocekavaji. Nemuzes prece jen tak prijit z cizi IP adresy a narusit vytvorene spojeni vlastnima datama,ne?
Hádání sekvenčních čísel je jeden z nejzákladnějších man in the middle útoků. Mimochodem já jsem nemluvil o TCP (vyjma nepříliš inteligentního příkladu s prohlížečem). NAT jako takové funguje pro jakýkoliv druh L4 packetů.
Jak se ten druh utoku co popisujes nazyva?
To neni útok, to je NAT traversal :) . Dá se použít jak pro "slušný" účely (skype, bittorrent, ...), tak pro neslušný.
Jedine, co jsem nasel je TCP session hijacking / Blind attack a nejake hadani sekvencnich cisel, coz si neumim predstavit jak je v praxi treba u toho prohlizece realizovatelne, kdyz to spojeni je otevrene jen kratkou chvili.
Hlavní je, že si to umí představit útočník :) .
-
Lol Phirae : ale prosimte, kdyby sis to cele precetl, tak bys zjistil, ze ta IP opravdu neni v me siti a muze za to muj ISP
Toz to neni tak upln pravda. Do hloubky jsem to nestudoval, ale jestli to spravne pohopuji, tak tyhle privatni adresy se vam bittorent klientovi objevi, kdy je druha strana za NATem nebo aspon firewallem a nema verejnou ip. Pokud vase strana verejnou ip ma, lze navazat spojeni a strana za firewallem vam posle pozadavek na zaslani souboru (push request nebo jak se to). Vy v torrent klientovi pak vidite privatni adresu, ale ta tam je asi jako identifikace klienta nebo neco. Vlastni komunikace pak ale tezko s touto adresou probiha, to by vyzadovalo celou serii blbe nakonfigurovanych routeru na Internetu, coz je dost nepravdepodobne. S cim vlastne komunikujete byste videl ve Wiresharku nebo v iptraf.
Proc neni respektovan limit uploadu, je zahada, ale tipnul bych nejakou botu v Microtorrentu, protoze nevidim, proc by to omezeni melo byt implementovano na strane prijemce, logicky by to bylo implementovano na strane odesilatele, jinak by vam nikdo nezarucil, ze to bude respektovano, az se objevi milion vylepsenych klientu, ktere na to dlabou.
-
Představme si, že máš tvůj router implementuje NAT stylem full-cone (pro jednoduchost). Připojíš se ze svého počítače (za NATem) na web rootu. Router otevře spojení z nějakého portu, řekněme 53342 na root.cz:80. Router si pamatuje, že co přijde na port 53342, má přeposlat na tvůj počítač. No a mně už stačí poslat request na <ip tvého routeru>:53342 a voilá! jsem za NATem, protože tvůj router všechny packety příchozí na port 53342 přeposílá.
U ostatních typů NATu je to obdobné, jenom složitější.
Ja se taky hlasim, ze toto mi prijde jako velmi naivni scenar. Ten router prece nebude prijimat TCP pakety z JAKEKOLIV adresy, co prijde na port 53342 a preposilat to klientovi. Prece pouze cilovy server (root.cz - jeho IP) bude vpusten dovnitr. Ten NAT router si otevre vlastni spojeni na root.cz a nikdo jiny mu tam ladovat zadny data nemuze :) Pokud samozrejme neni po ceste nekdo kdo muze odposlechnout sekvencni cisla, resp. handshake a predbehnout legitimni root.cz. Kazdop. i tak je to dost mission impossible IMHO.
Jo a jeste k tomu browseru jak to tady zaznelo, browser rozhodne neposloucha na zadnem portu, je to prece klient a ten navazuje spojeni.
-
Jo a jeste k tomu browseru jak to tady zaznelo, browser rozhodne neposloucha na zadnem portu, je to prece klient a ten navazuje spojeni.
Tak asi posloucha na portu, na kterem si otevrel spojeni na nejaky sever, ne? A to po dobu, nez spojeni bude uzavreno. Kdyz neposloucha, tak jak se asi doslechne, ze mu prisla odpoved?
-
JardaP: ne, opravdu to neni IP z moji site. Ukazal jsem vypis z tracert, ten hovori za vse - jde to pres branu meho ISP. Navic na te IP bezi nejake mikrotik webove rozhrani a ja zadny mikrotik doma nemam.
Vec s podivnou IP uz mam davno vyresenou, problem byl pouze v me neznalosti iptables :)
-
Tak asi posloucha na portu, na kterem si otevrel spojeni na nejaky sever, ne? A to po dobu, nez spojeni bude uzavreno. Kdyz neposloucha, tak jak se asi doslechne, ze mu prisla odpoved?
Podivejte se na man netstat. Jediné stavy socketu, kterými klient (browser) bude prochazet jsou IMHO tyto:
1) SYN_SENT - klient poslal paket se SYN flagem
2) ESTABLISHED - spojeni s cilovym serverem je navazano, ted se poslou data.
3) CLOSE
Klientuv soket se nikdy nedostane do stavu LISTEN, nikdy. Poslouchaji pouze sokety serverů, ale ne klientů.
Jsem si tim temer jist, vsadim boty.
-
Ja se taky hlasim, ze toto mi prijde jako velmi naivni scenar. Ten router prece nebude prijimat TCP pakety z JAKEKOLIV adresy, co prijde na port 53342 a preposilat to klientovi. Prece pouze cilovy server (root.cz - jeho IP) bude vpusten dovnitr.
Ty sis taky neprecet tu wiki stranku vid?
-
To neni útok, to je NAT traversal :) . Dá se použít jak pro "slušný" účely (skype, bittorrent, ...), tak pro neslušný.
S tím NAT traversal taky uplně nesouhlasím. Skype používá tzv. hole punching a to je oboustraný proces.
Vezměme si příklad:
internet --- NAT router --- muj stroj
Jediný případ, kdy by mohl někdo se dostat za NAT na můj stroj, je ten, kdy útočník je hned 1 hop za tím NAT routerem, tzn. je ve stejné síti jako ten NAT router (ale z vnějšku) a tím pádem může fejkovat i MACky. Jinak z internetu IMHO NAT nelze prostřelit. Opět vsadím boty.
-
tadeas: vsak muzeme ten NAT kompletne vypustit a brat v potaz jen pocitace na LAN - ggho argumenty budou stale, si myslim, relevantni vuci tomu co popisujes
-
Jěště k tomu NAT traversal.. Já určitě netvrdím, že NATy se nedají traverzovat, jen tvrdím, že vždy to musí chtít obě strany - tzn. nikdo nemůže SAMOVOLNĚ traverzovat NAT, to prostě nejde imho. Jediný případ kdy by to samovolně teoreticky šlo, jsem popsal výše (útočník v síti ISP), ale i tak by bylo IMHO šíleně těžké navázat TCP spojení. Možná by byl útočník (v síti ISP) schopen protlačit mi tam nějaké UDP pakety, ale k čemu by mu to bylo.. TCP by IMHO ani nebyl schopen navázat a napojovat se na mě.
Přijde mi to, že je to prostě takový mýtus, trochu FUD :) Pozor pozor, NAT se dá "prostřelit" !! Nedá... samovolně se prostě nedá prostřelit. Ale jestli nesouhlasíte, rád se nechám poučit, ale zajímal by mě konkrétní scénář jak se mi dostanete na můj stroj za NATem, který nic nedělá.
-
tadeas: vsak muzeme ten NAT kompletne vypustit a brat v potaz jen pocitace na LAN - ggho argumenty budou stale, si myslim, relevantni vuci tomu co popisujes
aby nedoslo k omylu tak doplnuji - relevantni vuci tomu, co popisujes s tim utokem na browser
a vynechme fakt, ze na ty LAN muzes zase provest jine druhy utoku, diky kterym bys ten prohlizec snadno mohl napadnout. (arp cache poisoning a co ja vim co vsechno)
-
Je pravda, ze mam nastaveny port forwarding na port 1218 na pc s Windows. A tedy tento port, potazmo ta sluzba co na nem bezi by mela byt jedina napadnutelna z venku, ne?
Kdyz zminujes bezpecnost a rikas ze NAT mi nepomuze, tak jak by se pripadny utocnik mohl dostat skrz NAT bez toho, aby pouzil otevreny port o kterem vim? Jedine, co me napada je, ze bych se k nemu musel pripojit ja (backconnect).
Dekuji za objasneni
Chjo ...
router ... cim se myslis asi tak vyznacuje ... nj, ze routuje. Takovej standardni domaci router zna dve site (tu vnitrni a tu venkovni), a potom nejakou jednu default routu. Standardni (=kazdy) router nedela nic jinyho, nez se bafne libovolnej prichozi paket, podiva se na jeho dst (src ho vubec nezajima) a doruci => posle bud do interni site nebo do vnejsi site nebo preda na default routu. Router s NATem kupodivu udela presne totez. Je to totiz primarne router. Tudiz pokud (rekneme) doma pouzivas 192.168... a ja poslu na tvoji verejnou adresu paket, kterej bude mit dst 192.168... tak se uplne vpohode spojim s tvym internim strojem. Zadnej forward na to netreba. Samo, "spravne" by mi takovej paket nemel projit (ale jak si sam ukazal, minimalne v raci tvyho ISP vpohode projde), navic existujou zcela standardni (ac nedoporucovane/zakazovane - ovsem asi tak stejne jako privatni adresy) postupy - technicky lze do paketu vymenovat i nekolik routeru, pres ktery si preju aby paket sel. A, kupodivu, ac je toto uz davno vynato z pozadovaneho chovani, hromada routeru to vpohode udela. Navic muzu vladnout strojem v siti ISP, a pak mi v doruceni paketu na tvoji IP nic nezabrani.
Nat traversal stim nema nic spolecnyho, skype nedela nic jinyho, nez se prolejza v nejhorsim vsechny porty ze site ven, a zkousi, jestli se pres nejakej dostane na supernode. Klidne k tomu pouzije oblibenou 80tku. Samo, pokud je odchozi traffic znemoznen, tak se i skype muze jit leda klouzat.
Já si dovolím řící, že celé tvé řešení je trochu postavené na hlavu. Ty cheš blokovat konkrétní IP adresu, ale uTorrent klient to neví a tedy můlže docházet ke zvláštním situacím.
Ale prdlajs ... nedostupnoust IP je zcela standardni situace, navic klient o tom, ze nejaka IP existuje, vubec nikdy a za zadnyho okolnosti nic nezjisti, pokud neprojde pres firewall
tadeas: to co jsi popsal, jak by to slo prakticky zneuzit? Protoze, co se stane, az se pripojis na mujrouter:53342, tam nic nepobezi, ne? Jake ma utocnik moznosti?
Moznosti ma takovy, ze muze klido pouzivat tvoje (dost pravdepodobne povolene) windowsi sdileni, aniz bys ho poustel do netu. Viz vejs.
tadeas: Jak bys neco poslal do meho browseru, pokud nebudes mit pristup na stroj, na ktery jsem ze zacatku vytvoril spojeni na port 80?
Vzdyt browser ze sebe neudela server, ktery nasloucha na portu x?
Jak se to snazim pochopit, tak bys musel mit stejnou IP jako server, ke kteremu jsem se pripojil na port 80
A nebo nekde v trase mit moznost zmenit obsah paketu co je pro me, co mi poslal ten http server
Obavam se, ze o moznostech prohlizece a js nemas predstavu, specielne s prichodem html5 a dalsich uzasnych ficur ...
Jěště k tomu NAT traversal.. Já určitě netvrdím, že NATy se nedají traverzovat, jen tvrdím, že vždy to musí chtít obě strany - tzn. nikdo nemůže SAMOVOLNĚ traverzovat NAT, to prostě nejde imho. Jediný případ kdy by to samovolně teoreticky šlo, jsem popsal výše (útočník v síti ISP), ale i tak by bylo IMHO šíleně těžké navázat TCP spojení. Možná by byl útočník (v síti ISP) schopen protlačit mi tam nějaké UDP pakety, ale k čemu by mu to bylo.. TCP by IMHO ani nebyl schopen navázat a napojovat se na mě.
Přijde mi to, že je to prostě takový mýtus, trochu FUD :) Pozor pozor, NAT se dá "prostřelit" !! Nedá... samovolně se prostě nedá prostřelit. Ale jestli nesouhlasíte, rád se nechám poučit, ale zajímal by mě konkrétní scénář jak se mi dostanete na můj stroj za NATem, který nic nedělá.
Viz vejs, nevis o cem mluvis ...
-
IPv6 se mi nelíbí, podle mě je ~nahovno, ale zase skončí ty věčné debaty, že NAT je bezpečnostní prvek, který spolehlivě ochrání vnitřní síť ::)
-
tak jsem si precetl clanek
http://www.root.cz/clanky/proc-neni-nat-totez-co-firewall/
konkretne Mýtus 3: nikdo se na mě nepřipojí
no, mylil jsem se. Jdu experimentovat s pfsense
-
j: Tou "podivnou situací" jsem měl na mysli jen tu blbost, že IP adresa nebude z daného klienta dostupná, přestože pro ostatní seadery a zbytek swarmu dostupná bude. Nejde o nic nestandardního a problematického, jen kdo si má pamatovat že takové pravidlo je na firewallu.
stahovač: Nevím jak je to v aktuální verzi uTorrent klienta. Pokud povolíte používání IPFiltru (advanced: ipfilter.enable), můžete pomocí IPFilter.dat definovat co blokujete. Vlastní klient míval dříve různé statistiky a byl tam i přehled toho co je zablokováno a kdo to blokoval, případně i proč. Prostě si prostudujte nápovědu a bude vám jasné i to kolem firewallu.
-
tak jsem si precetl clanek
http://www.root.cz/clanky/proc-neni-nat-totez-co-firewall/
konkretne Mýtus 3: nikdo se na mě nepřipojí
no, mylil jsem se. Jdu experimentovat s pfsense
Ale to je vsechno teorie..
Podivejte se na tento odstavec http://en.wikipedia.org/wiki/TCP_hole_punching#Other_requirements_on_the_NAT_to_comply_with_TCP_simultaneous_open
Zkratka i na blby TCP hole punching potrebuji router, ktery nevraci RST v takovych situacich. Vracet RST je standard, takze musim mit specialni router a na nem to povolit.
Za dalsi podivejte se zde do sekce odkazů http://en.wikipedia.org/wiki/NAT_traversal#External_links
a mrkněte na "NAT-Traversal Test". Dejte test. Ale ale, musíte stáhnout nějakou Javovou aplikaci. Proč asi? Protože to prostě musí být iniciováno z obou stran, takže pokud já se o to nepokouším, nikdo mi NAT zvenku svévolně "neprostřelí".
Za další source routing je IMHO uplná historie, nevěřím, že to dneska ještě funguje.. Ale i kdyby jo, tak pokud vím, tak NAT vždy nastavuji pouze na venkovní rozhraní. Tzn. pokud by na venkovní rozhraní NAT routeru přišel paket s "uhádnutou" vnitřní IP adresou, ten paket by byl zahozen, jelikož nesedí MAC adresa, protože NAT router má ve své ARP cachi MAC adresu té vnitřní IP adresy, a v tom případě by byla kolize v ARP cachi. Tzn. NAT router by na TCP paket vrátil TCP RST a na UDP pravděp. ICMP error (dle standardu, ale záleží na nastavení), každopádně jsem přesvědčen, že se dovnitř nedostane.
Krajní teoretický případ je právě ten, kdy se jedná o síť ISP, kdy právě lze falšovat i MAC adresu, ale i tak si nemyslím, že by dneska prošel takový paket.
-
Jeste jenom uvedu jaky NAT mam na mysli:
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
echo 1 > /proc/sys/net/ipv4/ip_forward
, kde eth0 je to venkovni rozhrani routeru. To ma proste dany smer a opacne to nepujde..
-
Jinak bacha, pamico jsou opravdu takový hovada, ze mi na domácím router lítali pakety z 172.0.0.0/8. Navíc dlouho nebyli schopný si zapnout DHCP alert apod, takže v síti se jim nejspíše děje kdoví co…
-
Jeste jenom uvedu jaky NAT mam na mysli:
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
echo 1 > /proc/sys/net/ipv4/ip_forward
, kde eth0 je to venkovni rozhrani routeru. To ma proste dany smer a opacne to nepujde..
Boze, muze bejt nekdo tak blbej ? Evidentne muze ...
Vis ty co dela nat/maskarada? Nj, nevis, jinak bys takovou blbost nemoh napsat. Nedela to nic jinyho, nez se ODCHOZIM paketum, ktery odchazeji pres to vymenovany rozhrani, dava IPcko prave toho rozhranni ... do src. A samo, aby to fungovalo = aby byly prijaty odpovedi, tak si poznamena, ze doslo k navazani komunikace z vnitrni IP + portu na verejnou IP a port.
Ostatne proto pres NAT nefungujou veci jako ftp, ipsec, ... ktery vymenujou informace o IP v ramci protokolu. Neco se obejit ruzne da, neco ne.
Takze jeste jednou, NAT umoznuje komunikaci zevnitr ven, ale rozhodne nebrani komunikaci zvenku dovnitr.
-
to j: Misto nadavek a urazek by ste mohl uvest konkretni priklad (prikaz / cmd) jak ten NAT prostrelite z venku
-
Jinak bacha, pamico jsou opravdu takový hovada, ze mi na domácím router lítali pakety z 172.0.0.0/8.
Na tom není nic zvláštního. 172.0.0.0/8 je adresní příděl ARINu a používají ho např. AT&T, T-Mobile USA, America Online nebo Google. Kromě malé části je to veřejný adresní prostor. Horší by bylo pokud by se jednalo o 172.16.0.0/12, ale ani to nic nemusí znamenat. Většina malých a středních ISP šetří adresama a ve svých sítích používají privátní rozsahy.