Sítě nejenom lokální atak Konrad Malewski
pomocí je možno takové propojení vytvořit.
stupeň obtížnosti
Rychlý nárůst počtu počítačů na světě (v případě Polska – ceny poskytovatelů internetu) způsobuje, že se snižuje množství volný IP adres. Nejčastěji využívané řešení čili NAT (Network Address Translation) kromě svých výhod, přináší i problém. Je jím nemožnost vytváření propojení mezi počítači nacházejícími se v různých lokálních sítích. V článku budou popsány metody, s jejíž
Z
ařízení používající veřejné IP adresy stále přibývají. Ze zprávy ([1]) zveřejněné v roce 2002 vyplynulo, že rozsah veřejných adres bude vyčerpán v roce 2005. Rok 2005 spokojeně uplynul a problém speciálního adresování se nás nedotknul. Nové zprávy přesouvají apokalypsu na roky kolem 2010 až 2026. Kromě toho, že dle některých zdrojů bude v roce 2012 definitivní konec světa a problém dostupnosti IP ustoupí do pozadí, přenechávajíc prvenství existenčním problémům, je dobré vědět, že právě rozvoj lokálních počítačových sítí se postaral mimo jiné i o posunutí chvíle, kdy již nebude možné připojit žádný nový počítač ke globální síti.
Problém IP a jeho řešení
Aby spolu mohly dva počítače na Internetu komunikovat, musejí mít veřejné IP adresy – říká všeobecně známá teze. Ale není až tak úplně pravdivá. Na jedné straně je pravda, že na Internetu putující pakety musí mít veřejnou zdrojovou a cílovou IP adresu, což s sebou přináší nutnost existence dvou počítačů majících vnější IP – jednu odesílající a druhou přijímací. Na druhé straně existují mechanismy, které umožní počítačům mají-
2
hakin9 1/2007
cím lokální adresy, bezproblémovou komunikaci s libovolnou IP adresou. Jedním z nich je právě NAT (Network Address Translation) čili překlad síťových adres. NAT není jediným mechanismem tohoto typu. K umožnění surfování je možno např. Užít proxy server nebo využít protokol RSIP. Alternativní řešení jsou často využívána v místech, ve kterých ten, kdo zpřístupňuje Internet, chce mít větší kontrolu nad posílanými daty.
Z článku se dozvíte... • • •
Jak funguje NAT; Jaké existují druhy NAT a jaké jsou jejich vlastnosti; Jaké existují techniky navazování bezprostředních UDP a TCP spojení mezi lokálními sítěmi.
Měli byste... • • •
www.hakin9.org
Znát model ISO/OSI; Mít obecné ponětí o pravidlech fungování TCP/ IP sítí; Mít obecné znalosti o programování síťových karet;
Komputer z publicznym adresem IP
INTERNET
Router z NAT
Router z NAT
Sieć lokalna
Komputer z lokalnym adresem IP
Sieć lokalna
Komputer z lokalnym adresem IP
Komputer z lokalnym adresem IP
Komputer z lokalnym adresem IP
Obrázek 1. Zjednodušený model sítě
Překlad adres
NAT je v současnosti jedním z nejčastěji používaných mechanismů sloužících ke zpřístupnění internetového připojení v lokálních sítích. Je to prověřený mechanismus, dobře otestovaný a podporovaný lépe či hůře v širokém spektru hardwarových routerů. Existují samozřejmě i implementace NAT zdarma – natd nebo iptables. Využití tohoto řešení má následující výhody: •
•
•
•
•
NAT šetří adresní prostor – mnoho počítačů může mít jednu veřejnou IP adresu, na které je bude vidět; Zpřístupnění Internetu dalším počítačům vyžaduje pouze přenastavení routeru. Není nutné dokupovat další IP adresy u ISP; Při využití NAT ve firmě je velmi jednoduché změnit poskytovatele Internetu; NAT „automaticky” vytváří svého druhu firewall, který neumožní nekontrolované propojování počítačů z internetu s těmi v lokální síti; NAT nevyžaduje žádné speciální nastavení aplikací na klientských počítačích.
Bohužel však kromě výhod použití NAT musíme mít na mysli také jeho nevýhody:
•
•
•
•
Použití NAT při velkém počtu počítačů a jedné adrese způsobuje nejrozmanitější problémy, které neukazují na konkrétní příčinu; Aby některé služby fungovaly správně, vyžadují veřejnou IP adresu nebo vyžadují dedikovaný port; NAT vyžaduje více zdrojů (paměť, CPU) než řešení založené výhradně na routingu. Některé protokoly v prostředí NAT hůře pracují (např. ftp, ipsec).
Existuje mnoho typů NAT: • • • •
Jednosměrný NAT; Obousměrný NAT; NAT s překladem portů; Dvojnásobný NAT.
Rozdíly mezi příslušnými druhy NAT a zásady fungování je nejlépe ukázat Komputer A IP: 192.168.19.100
pomocí příkladu. Předpokládejme, že v síti existuje počítač, který má lokální adresu 192.168.19.100 a je připojen do Internetu pomocí NAT, jehož veřejná adresa je 157.158.181.42. Co se stane, když se chce počítač s lokální IP adresou spojit s počítačem s adresou 157.158.180.200? V případě NATu využívá počítač s lokální IP počítač se službou NAT jako výchozí router, proto pro jakoukoliv komunikaci mimo LAN mu pošle pakety. Při průchodu paketu přes router je změněna cílová adresa paketu na veřejnou adresu routeru. Počítač, ke kterému dojde paket po změně adresy uvidí spojení ne z adresy 192.168.19.100 ale z 157.158.181.42. Jednosměrný NAT je charakterizován tím, že počítač vně lokální sítě nemůže navázat spojení dovnitř LAN. Všechny pokusy o navázání spojení s routerem jsou brány jako pokusy o spojení se samotným routerem. Tuto funkčnost umožňuje obousměrný NAT. Pokud počítač 157.158.180.200 pošle paket na 157.158.181.42, router změní cílovou adresu na tu z lokální sítě. Lokální počítač uvidí spojení z adresy 157.158.180.200. Autoři příslušných NAT implementací se postarají o to, aby pakety procházející přes router byly upraveny jen velmi málo. I tak např. pokud se NAT klient v lokální síti pokouší navázat vnější spojení a k tomu používá zdrojový port X, bude se NAT pokoušet použít zdrojový port X po překladu IP adresy. Abyste porozuměli závažnosti rozhodnutí existence NAT při překladu portů, musíte zvážit následující případ: co se stane pokud se dva klienti pokusí o otevře-
Komputer R1 IP: 157.158.181.42
Src: 192.168.19.100 Src: 157.158.180.200 Src port: 3000 Src port: 5000
Komputer C IP: 157.158.180.200
Src: 157.158.181.42 Src port: 3000
Src: 157.158.180.200 Src port: 5000
Src: 157.158.181.42 Src port: 5000
Src: 157.158.180.100 Src port: 5000
Obrázek 2. Princip fingování NAT zobrazený na příkladě jednosměrného NAT
www.hakin9.org
hakin9 1/2007
3
atak
ní vnější připojení a budou používat stejný zdrojový port? NAT by měl co nejméně zasahovat do obsahu procházejících paketů, ale nečinnost v tomto případě způsobí, že se po překladu připojení stane od sebe nerozlišitelné (obě používají port X jako zdrojový). Pokud NAT zjistí tuto situaci, provede překlad portu a v případě druhého NAT připojení také změní IP adresu a zdrojový port. Pokud existuje možnost změny adresy a zdrojového portu, pak nám nic nebrání, abychom změnili také cílovou adresu. Změna cílové adresy má smysl třeba v situaci, kdy chceme spojit dvě sítě, jejichž adresy se prolínají. Pokud bychom chtěli umožnit komunikaci mezi těmito dvěma sítěmi, pak bychom museli změnit adresy v jedné z nich nebo využít obousměrný NAT na routerech, měníc adresy sítě tak, aby se nepomíchaly. Existuje dělení NAT dle jiných parametrů, ale v této chvíli zůstaneme u tohoto dělení.
Problém nezprostředkovaných spojení
Přítomnost počítače při výměně paketů a lokální adresování velmi komplikují klasické schéma navazování spojení mezi počítači nacházejícími se v různých lokálních sítích. Většina NAT momentálně používaných je NAT s překladem portů. I když nejsou problémy s navazování sezení počítačů v LAN se serverem nabízejícím veřejné IP, všechny požadavky z vnější sítě budou routerem spoju-
Komputer A IP: 192.168.19.100
Komputer A IP: 192.168.19.100
Komputer R1 IP: 157.158.181.42
Src: 192.168.19.100 Src: 157.158.180.200 Src port: 3000 Src port: 5000
Komputer C IP: 157.158.180.200
Src: 157.158.181.42 Src port: 3000
Src: 157.158.180.200 Src port: 5000
Src: 157.158.181.42 Src port: 5000
Src: 157.158.180.200 Src port: 5000
Src: 192.168.19.100 Src: 157.158.180.200 Src port: 5000 Src port: 5000
Rysunek 3. Zasada działania dwukierunkowego NAT jící počítač s Internetem odmítnuta. I když máme přístup ke konfiguraci routeru a využijeme přesměrování portů na lokální síť, tak to neřeší všechny problémy, protože je možno přesměrovat port pouze na jednu adresu. Často může být přesměrování jednoho portu ideálním řešením, ale co v případě, kdy správce naší lokální sítě není ochoten změnit konfiguraci routeru a navíc se cílový počítač také nachází za NAT. Na pomoc nám přicházejí různé techniky, při jejichž použití můžeme navázat bezprostřední spojení a nebudeme muset motat hlavu našemu správci.
Jednoduše na P2P
Pokud má jeden z počítačů veřejnou IP adresu, pak problém s připojením k jedné straně prakticky neexistuje. Počítač s veřejnou IP adresou je dosažitelný bezprostředně, proto je možno se s ním spojit stejně, jako s každým jiným na Internetu. Spojení v opačném směru však dělá větší pro-
Komputer A' IP: 192.168.19.101
blémy. Abychom jim zabránili, musíme obrátit schéma spojení. Přesněji počítač s veřejnou IP adresou musí požádat o připojení k počítači za NAT. Nemůže to však udělat přímo, musí zde existovat zprostředkující počítač, přes který bude na počítač za NAT odeslán požadavek na připojení (Obrázek 6). Rozšíření tohoto nápadu, ještě z doby Napsteru, je posílání dat pomocí síťového prostředníka, který by měl veřejnou IP adresu. Klienti, místo toho aby se připojovali přímo, se připojují k serveru, který vytvoří tunel spojující dvě sítě. Tento nápad má jméno TURN (zkratka z anglického Traversal Using Relay NAT). Toto řešení je velmi univerzální a navíc velmi účinné (Obrázek 7). Má však jisté nevýhody, konkrétně vyžaduje dedikovaný zprostředkující server a protokol pro výměnu dat a informací řídící tunel. To vyžaduje existenci zprostředkující vrstvy, se kterou by komunikovala
Komputer R1 IP: 157.158.181.42
Komputer C IP: 157.158.180.200
Scr: 192,168.19.100 Dst: 157,158.19.200 Src port: 3000 Dsc port: 5000 Scr: 157.158.181.42 Dst: 157.158.180.200 Src port: 3000 Dst port: 5000 Scr: 192.168.19.101 Dst: 157,158.19.200 Src port: 3000 Dst port: 5000 Scr: 157.158.181.42 Dst: 157.158.180.200 Src port: 3000 Dst port: 5000
Obrázek 4. NAT s překladem portů
4
hakin9 1/2007
www.hakin9.org
Komputer A IP: 192.168.19.100
Komputer R1 IP: 157.158.181.42
Komputer S' IP: 157.158.191.236
Src: 157.158.180.200 Src: 157.158.180.200 Src port: 5000 Src port: 5000 Src: 157.158.181.42 Src port: 3000
Src: 157.158.180.200 Src port: 5000
Obrázek 5. Dvojnásobný NAT aplikace, která chce poslat data. Pokud by toto řešení mělo být využíváno ve větším rozsahu např. pokud by na jeho základě měly být nabízeny služby jako univerzální síťový zprostředkovatel, pak musíte počítat s problémy právního charakteru.
Vytváříme VPN
Pro vlastní potřebu si však můžeme velmi rychle vytvořit tunel tohoto typu. V nejideálnějším případě stačí mít pouze administrátorské oprávnění na počítači s veřejnou IP adresou. K vytvoření tunely mezi počítači A a B použijeme VPN pojmenované VTUN. VTUN umožňuje na počítači za NAT vytvoření virtuálního síťového rozhraní, které jej propojí s druhým počítačem. Ze strany routeru propojujícího A s internetem je tunel viditelný jako jedno propojení A s počítačem C. Navíc VTUN umožní šifrování posílaných dat. Alternativním řešením a často považované za bezpečnější je OpenVPN, které je dostupné i na platformě Windows. S přihlédnutím k jednoduchosti nastavení zůstaneme v tomto příkladě u VTUN. Po instalaci VTUN je nutno nastavit službu spouštěnou na serverovém počítači (v tomto případě nechť to je počítač C) a na počítačích klientů (A a B). Na počítači C by měl konfigurační soubor obsahovat: Konfigurační soubor na hostu A je vytvořen analogicky dle hosta B. Liší se pouze jménem sekce (hosta místo hostb) a IP adresou tunelu (10.1.0.2). Většina parametrů v konfiguračním souboru je samo popisující. Podrobnou dokumentací je výchozí konfigurační soubor dodávaný s programem. Můžete v něm najít podrobný popis každého z parametrů.
Pokud již máme připravené konfigurační soubory, spustíme VTUN server na počítači C:
a na počítači A:
vit dvěma způsoby. Můžeme k tomu použít standardní příkaz route nebo také pokročilejší ip z balíčku iproute. Výhodou používání ip je možnost nastavení zdrojové adresy, která bude používána pro přístup k dané síti. Na hostu A vyvoláme:
vtund -f vtun-hosta.conf -p hosta
ip route add 192.168.18.0/24 dev
vtund -s -f vtun-srv.conf
157.158.180.200
tap1 src 192.168.19.100
i nakonec na počítači B:
Na hostu B:
vtund -f vtun-hostb.conf -p hostb
ip route add 192.168.19.0/24 dev
157.158.180.200
tap1 src 192.168.18.200
Pokud šlo vše dobře, měl by server C obsahovat dvě další rozhraní – tap0 spojující C s A a tap1 spojující C s B. Teď stačí nastavit pravidlo routingu umožňující komunikaci A s B a zapnout předávání paketů mezi rozhraními tap0 a tap1 na hostu C. Routing na A a B můžeme nasta-
Ale hosta C naučíme předávání paketů a ARP požadavky a to, kde se nacházejí lokální sítě A a B: echo "1" > /proc/sys/net/ipv4/conf/ tap1/forwarding echo "1" > /proc/sys/net/ipv4/conf/ tap0/forwarding
C
Żądanie połączenia
INTERNET
R1
B Połączenie
A
Obrázek 6. Schéma opačného připojení
www.hakin9.org
hakin9 1/2007
5
atak
echo "1" > /proc/sys/net/ipv4/conf/ tap1/proxy_arp echo "1" > /proc/sys/net/ipv4/conf/ tap0/proxy_arp ip route add 192.168.19.0/24 dev tap0 ip route add 192.168.18.0/24 dev tap1
Po provedení výše uvedeného seznamu příkazů by měl tunel již fungovat. Odeslání ping paketů příkazem "ping 192.168.18.200" vyvolané na hostu A by mělo způsobit příchod ICMP paketů Echo Reply z hosta B. Některé programy (například nmap) nerespektují parametr src příkazu ip a používají IP adresu rozhraní, přes které odcházejí pakety. Pakety přicházející na druhý konec tunelu mají zdrojovou adresu tunelového rozhraní čili v našem případě pakety přicházející z A na B mají adresu 10.1.0.2. Aby host B uměl odpovědět na tento paket, je třeba mu nastavit další cestu routingu do sítě hosta A. Situace není tak jednoduchá, pokud nemáme administrátorská práva na hostu C. Ale i v tomto případě můžeme sestavit tunel. K tomu použijeme další SSH tunelování. Host B se spojí s hostem C přesměrováním svého lokálního portu 5000 na port 5000 hosta C: ssh -f -N -L5000:localhost:5000 uzivate
[email protected]
Následně host A provede spojení, ale přesměruje vzdálený port 5000 na svůj lokální: ssh -f -N -R5000:localhost:5000 uzivate
[email protected]
Teď stačí nastavit VTUN jako server na hostu A použít VTUN v módu klienta na hostu B. Host B připojující se na adresu localhost:5000 se připojuje na VTUN server fungující v druhé lokální síti. Je dobré vědět, že ssh zajišťuje další ochranu posílaných dat. V podstatě máme v tomto řešení dvojitou ochranu. První zajišťuje samotný mechanismus VTUN, druhou SSH. Být paranoikem se někdy vyplácí. Výše uvedené techniky nevyužívají specifické vlastnosti NAT. Je to jejich výhoda, pokud jsme si jistí, že
6
hakin9 1/2007
s velkou pravděpodobností se nám v každém případě podaří navázat spojení. Techniky, které vycházejí z využití chování NAT jsou mnohem zajímavější, ale nedávají tu jistotu.
C
Druhý přístup
Jednou z těchto technik je STUN (Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)). Jak je možno odvodit si ze jména, způsob průchodu přes NAT se týká výhradně protokolu UDP. Ale i tak, jak bude ukázáno níže, lze tuto techniku využít také pro protokol TCP. Předpokládejme, že počítače A a B si chtějí poslat datagramy přímo. Aby to udělaly, spojí se s prostředníkem C. Předpokládejme, že síť počítače A je 192.168.19.0/24 a síť počítače B je 192.168.18.0/24. Počítače A a B mají adresy ve svých sítích postupně 100 a 200. Veřejné rozhraní routerů R1 a R2 je 157.158.181.42 a 157.158.180.235 a prostředník má adresu 157.158.180.200. Když počítač A odešle UDP paket do počítače C přes router R1, pak si router zapamatuje, že se tato situace vyskytla a umožní obousměrnou komunikaci mezi počítači A a C. Například pokud A pošle paket se zdrojovým portem 3000 a cílovým 5000 na počítač C, pak ve chvíli průchodu skrz router s NAT R1, bude zdrojová adresa (čili 192.168.19.100) změněna na adresu vnějšího rozhraní – 157.158.181.42. Pokud NAT na routeru R1 mění také zdrojové porty pak bude změněn také tento port. Abychom zjednodušili situaci předpokládejme, že R1 i R2 mění čísla portů spojení za NAT. Zdrojové porty odchozích paketů jsou z rozsahu 30000-60000. Vraťme se k našemu paketu – po překladu zdrojové adresy a zdrojového portu prochází směrem k počítači C s nastavenou zdrojovou adresou 157.158.181.42 a zdrojovým portem 50025. Navíc router R1 si pamatuje toto spojení. Všechny pakety, které budu pocházet od počítače C a jejich cílový port bude roven 50025 (zdrojový port je roven 5000) budou předány obrácenému překladu čili
www.hakin9.org
Kanał komunikacyjny INTERNET
R1
A
R2
B
Obrázek 7. Principy fungování protokolu TURN bude navrácena adresa cílového počítače A a originální port – 3000. Tímto způsobem mohou A a C provádět obousměrnou komunikaci. Pokud B také naváže spojení s C, pak C bude mít spojení jak s A tak s B. Klienti A a B musejí velmi často komunikovat s C, aby routery R1 a R2 neodmítly zápisy ve svých translačních tabulkách. Teď může C informovat A o adrese a zdrojovém portu B (o tom po překladu) a uvědomit B o adresách a portech A. Předpokládejme, že požadavek B spojení na port 5000 počítače C z portu 4000 bylo změněno tak, že zdrojový port je po průchodu přes NAT rovno 50000. Pokud se objeví možnost komunikace s A a B pomocí techniky TURN, počítače mohou provést pokus o spojení přímo. V této chvíli si musíme trochu rozšířit naše znalosti o mechanismu NAT. Ve chvíli otevření tzv. tunelu a namapování lokální adresy a portu na vnější adresu a příslušný NAT port se jinak chová ve chvíli, při které vnější počítač (nepatřící ke konverzaci) odešle paket na router spojující lokální síť s Internetem na mapovanou adresu a port. Tuto situaci zobrazuje Obrázek 9.
Další druhy NAT
Souběžně s výše uvedeným rozdělením, klasifikuje literatura NAT vzhledem k chování v určitých situacích jako:
• • • •
Full cone NAT; Restricted cone NAT; Port restricted cone NAT; Symmetric NAT.
Všechny mají společnou vlastnost. Konkrétně tu, že konsekvence průchodu balíčku přes router je změnou adresy na vnější, zatímco zdrojový port, i když je to možné, bude zachován. Charakteristickým vlastnosti prvního je mezi jinými to, že host nepatřící ke konverzaci, když chce odeslat balíček lokálnímu počítači jej odešle na vnější adresu hosta za NAT. Navíc, pokud host v lokální síti použije stejný zdrojový port ke komunikaci s jiným hostem, NAT nezmění cílový port po převodu. Svou činností připomíná
částečně obousměrný NAT, který jo byl zmiňován dříve. Druhý - Restricted cone NAT, se chová jako Full cone NAT z tím rozdílem, že paket odeslaný vnějším hostem dojde do lokální sítě výhradně v případě, kdy host z vnitřní sítě poslal dříve paket vnějšímu hostovi. Port restricted cone NAT dává jistotu v podobě nutnosti zachování čísel portů. Paket odeslaný vnitřním hostem používající zdrojový port X a cílový port Y dojde k hostovi za NAT pouze tehdy, když tento host odešle odešle nejdříve paket vnějšímu hostovi, jeho cílový port je X a jeho zdrojový port po opuštění NAT routeru bude mapován na Y. Nejtěžší je průchod přes Symmetric NAT, protože omezení se v tomto
Výpis 1. Konfigurační soubor VTUN na zprostředkujícím počítači C options { port 5000; syslog daemon; ifconfig /sbin/ifconfig; } default { speed 0; } hosta { passwd Ma&^TU; type ether; device tap0; proto tcp; compress lzo:1; encrypt yes; stat yes; keepalive yes; up { ifconfig "%% 10.1.0.1 netmask 255.255.255.0"; }; down { # Shutdown tap device. ifconfig "%% down"; }; } hostb { passwd Ma&^TU; type ether; device tap1; proto tcp; compress lzo:1; encrypt yes; stat yes; keepalive yes; up { ifconfig "%% 10.2.0.1 netmask 255.255.255.0"; }; down { ifconfig "%% down"; }; }
www.hakin9.org
případě netýká jenom adres, ale také zdrojových a cílových portů a všechny parametry jsou unikátní pro každé připojení. Pouze počítač, který používá stejnou sadu parametrů, odpovídajíc paketem na zdrojovou adresu a port, komunikuje s hostem za NAT. Navíc, pokud počítač z lokální sítě použije stejný zdrojový port pro komunikaci s jinou adresou, pak bude po opuštění NAT zdrojový port změněn. Výše popisované chování NAT je popsáno na obrázcích 11,12 a 13. Symetrický NAT je často popisován jak „not well behaved”. Ale i při použití tohoto typu NAT jsme ve stavu vytvářet přímá propojení. Spočívají v předpovídání zdrojového portu, který bude vybrán jako další.
UDP tunel
Předpokládejme, že routerů R1 a R2 je Port restricted cone NAT, protože s těmi se setkáme nejčastěji. Port restricted cone NAT má tu zajímavou vlastnost, že je „well behaved”. Znamená to víceméně, že po tu dobu, co bude host A používat zdrojový port 3000 pro posílání paketu, bude stejně dlouho NAT používat stejný port (čili 50025). Pokud se vrátíme k situaci popsané dříve, hosté A a B mají spojení s C, host A odesílá paket ve směru routeru R2 s nastaveným zdrojovým portem 3000 a cílovým portem 50000. V době překladu – bude na routeru R1 změněna adresa a zdrojový port stejně, jako v případě připojování se k hostu C. Navíc bude zaznamenáno, že je nutno dovnitř pouštět provoz pocházející od routeru R2 přicházející z portu 50000. Router R2, který převezme paket jej odmítne, pokud host B ještě nenastavil svůj NAT tak, aby přijímal připojení z R1. V závislosti na nastavení routeru může být odeslán ICMP paket port unreachable. Předpokládejme, že NAT R2 neposlal tento paket. Když B odešle paket (za použití stejného zdrojového portu) na R1, pak on změní adresu a cílový port paketu, protože byl dříve přeprogramován při pokusu o spojení se A s B. Teď mohou A a B přímo komunikovat posíláním UDP paketů na své vnější adresy a porty. Při celé komunikaci
hakin9 1/2007
7
atak
byl ztracen pouze jeden paket. Je to cena, kterou musíme zaplatit za možnost přímého spojení. Výše uvedené schéma má využití v případě, kdy NAT na R1 a R2 mění zdrojové porty. Záležitost se zjednodušuje ve chvíli, kdy NAT nemění zdrojové porty. V tom případě nám nic nebrání, abychom provedli pokus o navázání spojení bez zprostředkovatele. Abychom otevřeli „tunel” v
NAT R1 musíme z A poslat paket ve směru R2. Tunel UDP v praxi Pro otevření UDP tunelu budeme potřebovat následující nástroje: netcat, hping2 a skript napsaný v jazyce Perl z Výpisu 3. Skript z Výpisu 3 spustíme na počítači C. Jeho úkolem je naslouchání na portu 5000 a vypisování parametrů připojovaných
200.158.180.200
C
hostů s hostem C na obrazovku terminálu a zprávy, jaké hosté posílají. Na počítači A spustíme netcat: netcat -l -u -p 3000
To zapne naslouchání počítače A na portu 3000. Obsah všech paketů adresovaných A majících cílový port 3000 bude vypsán na obrazovce terminálu. Následně otevřeme tunel v NAT na obou počítačích. Na A musíme použít zdrojový port rovnající se 3000, protože na tomto portu netcat očekává pakety: hping2 157.158.180.200 -2 -s 3000 -p 5000 -c 1
INTERNET
157.158.181.42
157.158.180.235
R1
[157.158.181.42: 3000]>
R2
192.168.19.100
192.168.18.200 Połączenie
A
způsobí vypsání hlášky na terminálu C
B
svědčícího o tom, že paket zpoza NAT došlý na R1 nezměnil zdrojový port. Další činnost opakujeme na počítači B: hping2 157.158.180.200 -2 -s 4000 -p 5000 -c 1
Obrázek 8. Schéma ukázkové sítě
což by mělo vést k objevení se hlášky na C:
200.158.180.200
[157.158.180.235: 4000]>
Teď na počítači A přenastavíme nat v R1 tak, aby akceptoval pakety od R2:
C
hping2 157.158.180.235 -2 -s 3000 -p
SRC:157.158.181.42:50025 DST 157.158.180.200:5000
SRC:157.158.180.235:4000 DST 157.158.181.42:50025
INTERNET
157.158.181.42
157.158.180.235
4000 -c 1
Na B nastavíme NAT R2 tak, aby akceptoval pakety od R1: hping2 157.158.181.42 -2 -s 4000 -p 3000 -c 1
R1 B
192.168.19.100
Teď můžeme na B spustit netcat s parametry:
Połączenie
nc -p 4000 157.158.181.42 3000 -u A
Obrázek 9. Host nepatřící ke konverzaci spojující se k mapovanému připojení na routeru
8
hakin9 1/2007
www.hakin9.org
Po provedení posledního příkazu se vše, co napíšeme do okna na hostu B objeví v okně netcat hosta A.
Vytváření tunelu tímto způsobem není příliš užitečné. Naštěstí existují nástroje, které automaticky posílají sekvence zpráv vytvářejících spojení. Velmi zajímavým nástrojem je perl skript nat-traverse dostupný na [13]. Abychom dostali stejný výsledek, stačí na počítači A provést příkaz: Komputer A IP: 192.168.19.100
nat-traverse 3000:157.158.180.235:4000 a na počítači B: nat-traverse 4000:157.158.181.42:3000
Tento program má jednu zajímavou funkci. Je jí možnost volání libovolného příkazu a přesměrování toků – vstupního i výstupního tak, že vše, co příkaz vypíše bude posláno síťo-
Komputer R1 IP: 157.158.181.42
Scr: 192.168.19.3000 Dst: 157.158.180.200:5000
vou kartou na druhý počítač. Vše co přijde tunelem je přesměrováno jako tok standardního vstupu příkazu. Pomocí tohoto parametru je možno posílat adresáře mezi počítači: hostA# nat-traverse 3000: 157.158.180.235:4000 –cmd=„tar cj adresář”
Komputer C IP: 157.158.180.200
Komputer B IP: 157.158.180.235
Dst: 157.158.181.42:3000 Dsc 157.158.180.200:5000
Scr: 192.168.19.5000 Dst: 192.168.19.100:3000
Dst: 157.158.180.200:5000 Dsc 157.158.181.42:3000
Dst: 157.158.180.200:7000 Dsc 192.168.19.100:3000
Dst: 157.158.180.200:7000 Dsc 157.158.181.42:3000
Dst: 157.158.180.235:5000 Dsc 192.168.19.100:3000
Dst: 157.158.180.235:5000 Dsc 158.158.181.42:3000
Dst: 157.158.180.235:5000 Dsc 192.168.19.100:3000
Dst: 157.158.180.235:7000 Dsc 157.158.181.42:3000
Obrázek 10. Fungování Full Cone NAT.
Komputer A IP: 192.168.19.100
Komputer R1 IP: 157.158.181.42
Scr: 192.168.19.3000 Dst: 157.158.180.200:5000
Komputer C IP: 157.158.180.200
Komputer B IP: 157.158.180.235
Dst: 157.158.181.42:3000 Dsc 157.158.180.200:5000
Scr: 192.168.19.5000 Dst: 192.168.19.100:3000
Dst: 157.158.180.200:5000 Dsc 157.158.181.42:3000
Dst: 157.158.180.200:7000 Dsc 192.168.19.100:3000
Dst: 157.158.180.200:7000 Dsc 157.158.181.42:3000 Dst: 157.158.180.235:3000 Dsc 157.158.181.42:3000
Dst: 192.168.19.100:3000 Dsc 157.158.180.235:5000
Dst: 157.158.181.42:3000 Dsc 157.158.180.235:5000
Dst: 157.158.180.235:5000 Dsc 192.168.19.100:3000
Dst: 157.158.180.235:5000 Dsc 192.168.19.100:3000
Dst: 157.158.180.235:7000 Dsc 192.168.19.100:3000
Dst: 157.158.180.235:5000 Dsc 157.158.181.42:3000
Obrázek 11. Funkce Restricted Cone NAT
www.hakin9.org
hakin9 1/2007
9
atak
hostB# nat-traverse 4000:
hostA# nat-traverse 3000:
157.158.181.42:3000 –cmd=„cat >
157.158.180.235:4000 –cmd=„nc -lvp
adresář.tar.bz2”
5000”
Pomocí tohoto nástroje můžeme také předávat TCP připojení. Stačí k tomu využít program netcat:
hostB# nat-traverse 4000:
Komputer A IP: 192.168.19.100
157.158.181.42:3000 –cmd=„nc -v localhost 22”
Komputer R1 IP: 157.158.181.42
Scr: 192.168.19.3000 Dst: 157.158.180.200:5000
Teď je možno se připojit z hosta A k ssh serveru fungujícím na hostu B pomocí připojení s rozhraním loopback na port 5000. S pomocí netcat je možno také předávat UDP připojení UDP. I když můžeme předávat UDP a TCP, nic nám nebrání ve spuštění VPN pracující skrz tunel.
Komputer C IP: 157.158.180.200
Komputer B IP: 157.158.180.235
Dst: 157.158.181.42:3000 Dsc 157.158.180.200:5000
Scr: 157.158.180:5000 Dst: 192.168.19.100:3000
Dst: 157.158.180.200:5000 Dsc 157.158.181.42:3000 Dst: 157.158.180.200:7000 Dsc 157.158.181.42:3000 Dst: 157.158.180.235:5000 Dsc 157.158.181.42:3000
Dst: 192.168.19.100:3000 Dsc 157.158.180.235:5000
Dst: 157.158.181.42:3000 Dsc 157.158.180.235:5000
Dst: 157.158.180.235:5000 Dsc 192.168.19.100:3000
Dst: 157.158.180.235:5000 Dsc 157.158.181.42:3000
Dst: 157.158.180.235:7000 Dsc 157.158.181.42:3000
Obrázek 12. Funkce Port Restricted Cone NAT Komputer A IP: 192.168.19.100
Komputer R1 IP: 157.158.181.42
Scr: 192.168.19.3000 Dst: 157.158.180.200:5000 Scr: 157.158.180.200:5000 Dst: 192.168.19.100:3000
Komputer C IP: 157.158.180.200
Komputer B IP: 157.158.180.235
Dst: 157.158.181.42:3000 Dsc 157.158.180.200:5000 Dst: 157.158.180.200:5000 Dsc 157.158.181.42:3000 Dst: 157.158.180.200:7000 Dsc 157.158.181.42:3000 Dst: 157.158.180.235:5000 Dsc 157.158.181.42:3000
Dst: 192.168.19.100:3000 Dsc 157.158.180.235:5000
Dst: 157.158.181.42:7000 Dsc 157.158.180.235:5000 Dst: 157.158.180.235:5000 Dsc 157.158.181.42:3000
Dst: 157.158.180.235:5000 Dsc 192.168.19.100:3000
Dst: 157.158.180.235:5000 Dsc 157.158.181.42:7000
Obrázek 13. Funkce Symmetric NAT
10
hakin9 1/2007
www.hakin9.org
Stačí přesměrovat lokální tcp port 5000 na vzdálený host, na kterém funguje VTUN a spojit se s klientem VTUN na localhost:5000. Musíme si zapamatovat, že za prvé přicházíme o spolehlivost protokolů jako je TCP a za druhé samotný proces obalování má velkou datovou náročnost (TCP na IP na ethernet na UDP).
Pokud je firewall na routerech nastaven tak, aby na UDP pakety které „nezná”odpovídal ICMP hláškami, pak se vytvoření tunelu může povést, protože některé NAT reagují na hlášky ICMP. Pokud paket hosta A dojde k NAT B před odeslání B UDP ve směru A, pak může nastat situace, ve které R2 odpoví paketem ICMP (port unre-
257.158.180.200
Pakiet UDP DST=157.158.180:5000 SRC=157.158.181:50000
Překážky ICMP
Pokud náš NAT reaguje na pakety ICMP tohoto typu, je možno změnit jeden typ ICMP na jiný. Stačí prvnímu paketu odeslanému ve směru druhého routeru nastavit příslušně nízkou hod-
257.158.180.200
Pakiet UDP DST=157.158.180:5000 SRC=157.158.181:50000
Pakiet UDP DST=157.158.181.42:5000 SRC=157.158.180.200:50000 O zawartości: "157.158.180.235:50025"
157.158.181.42
Pakiet UDP DST=157.158.180.235:50025 SRC=157.158.180.200:50000 O zawartości: "157.158.181.42:50000"
157.158.181.42 157.158.180.235
192.168.19.100
157.158.180.235
192.168.18.200
192.168.19.100
257.158.180.200
192.168.18.200
257.158.180.200
Pakiet UDP DST=157.158.180.235:50025 SRC=157.158.42:50000
Pakiet UDP DST=157.158.181.42:50000 SRC=157.158.180.235:50025
157.158.181.42
157.158.181.42 157.158.180.235
192.168.19.100
achable) R1, což v případě některých NAT znemožňuje spojení.
157.158.180.235
192.168.18.200
192.168.19.100
192.168.18.200
Obrázek 14. Příslušné fáze vytváření UDP tunelu
www.hakin9.org
hakin9 1/2007
11
atak
notu TTL. Hodnota TTL je snižována každým průchodem skrz router. Když dosáhne nuly, následuje odmítnutí paketu a odeslání ICMP hlášení číslo 36 "time exceeded in-transit". Další otázkou je synchronizace celé operace. Pokud NAT odesílá ICMP pakety znamená to, že host v lokální síti ještě neodeslal paket nastavující NAT. Některé verze NAT v této situaci začínají měnit zdrojové porty odcházejících paketů, což velmi zjednodušuje komunikaci. Aby pakety přišly na oba NAT přesně ve stejné chvíli, musíme zajistit, aby:
a zamyslet se, co při využití této techniky může skončit neúspěchem v příslušných krocích spojování. Inicializace připojení se skládá ze tří kroků. V prvním kroku klient posílá paket s nastaveným příznakem SYN, který signalizuje pokus o navázání připojení . Pokud vzdálený host chce akceptovat spojení, pak v druhém kroku posílá paket s nastaveným příznakem SYN a ACK. Ve třetím kroku iniciátor spojení potvrzuje obdržení informace o serveru odesláním paketu s nataveným příznakem ACK. Třístupňové schéma navazování spojení má navíc za cíl synchronizaci sekvenčních čísel používaný pro ujiš-
t1+t3=t2+t4
tění se o správnosti odesílaných dat. Příznak SYN nastavený v paketech informuje, že obsahuje sekvenční číslo. Každé TCP připojení má dvě taková čísla. Každá ze stran má vlastní hodnotu reprezentující jistého druhu počítadlo odesílaných dat. Abychom mohli využít techniku průchodu firewallem s použitím protokolu TCP, musíme zajistit, aby obě propojované strany správně přešly přes tři fáze. Jestliže některý krok vynecháme, pak navázání spojení vyžaduje využití dodatečných operací. Musíme vědět, že některé implementace NAT si hlídají, aby příslušné kroky spojeC
z čehož vyplývá, že každý z hostů musí před odesláním paketu počkat
t1
t2
T = max(t1+t3, t2+t4) – z,
kde z je součet časů vysílání paketů daného hosta z C a času cesty paketu protilehlému NAT Ale ve většině případů však takto přesná synchronizace není zapotřebí. Stačí zajistit, aby hosté A a B odesílali pakety ve stejné chvíli tedy:
NAT A
NAT B t3
T = max(t1, t2) - z
Čas na TCP
Technika UDP hole punching je obvykle velmi účinná, protože protokol UDP není tak komplikovaný jako například TCP. Pokud používáme jiné protokoly, takové jako TCP, situace se komplikuje, protože má přesně popsané schéma navazování připojení, jehož správnost mohou kontrolovat nejenom příslušné implementace NAT, ale také protihackerské systémy, firewall apod. Pokud ovládneme techniku průchodu NAT pomocí UDP, pak můžeme vždy využít obalení TCP nebo celého IP v UDP vytvořením plného IP tunelu. Kromě toho, že TCP je složitějším protokolem než UDP existují metody umožňující vytvoření přímých spojení mezi počítači za různými NAT. Na úvod se stačí podívat na metody navazování TCP připojení
12
hakin9 1/2007
A
B t4
Obrázek 15. Doby vysílání paketů Komputer R1 IP: 157.158.181.42
Komputer C IP: 157.158.180.200
S=157.158.181.42.3000 D=157.158.180.200:5000 SEQ:10000 ACK:0 FLAGS: SYN S=157.158.181.200.5000 D=157.158.181.42:3000 SEQ:20000 ACK:10001 FLAGS: SYN,ACK S=157.158.181.200.5000 D=157.158.181.42:3000 SEQ:20000 ACK:10001 FLAGS: SYN,ACK
Obrázek 16. Tři fáze navazování spojení.
www.hakin9.org
Výpis 2. Konfigurační soubor VTUN na počítači B
#while true; do nemesis tcp -x 3000
options { port 5000; timeout 60; ifconfig /sbin/ifconfig; } hostb { passwd Ma&^TU; type ether; device tap1; proto tcp; up { ifconfig "%% 10.2.0.2 netmask 255.255.255.0"; }; down { ifconfig "%% down"; }; }
-y 3000 -fSA -s 0 -a 0 -S 192.168.19.100 -D 157.158.180.235; done
Z hosta B musíme poslat TCP rámce s nastaveným příznakem SYN. #while true; do nemesis tcp -x 3000 -y 3000 -fS -s 0 -a 0 -S 192.168.18.200 -D 157.158.181.42; done
Abychom zjistili, zda do B přicházejí rámce A s nastaveným příznakem SYN-ACK, je nejjednodušší použít tcpdump:
ní následovaly jeden za druhým. Například nevpustí paket s nastaveným příznakem SYN do lokální sítě, pokud je očekáván paket s nastaveným příznakem SYN-ACK. Navíc NAT může sledovat správnost sekvenčních čísel ve třech krocích spojení. Jádra ze série 2.4 jsou velmi tolerantní pokud jde o porušování těchto zásad. Aby pakety procházely z jedné lokální sítě do druhé, stačí poslat velké množství příslušně naformátovaných rámců z A a B. Na hostu A spustíme program nemesis, který bude posílat
NAT_A
C
NAT_B
SYN (Małe TTL ICMP
rámce s nastavenými příznaky SYN-ACK:
#tcpdump -n 'tcp[13]==0x12'
Filtr tcpdump by měl propustit pouze ty rámce, které mají nastaven příznak SYN a ACK.
TCP není tak strašné
Pokus o propojení dvou počítačů ve dvou různých lokálních sítích používajících TCP může probíhat přesně analogicky s případem používání UDP protokolu. Připusťme, že NAT na R1 a R2 neupravuje zdrojové porty. Každý z klientů
NAT_A SYN (Małe TTL
SYN (Małe TTL
NAT_A
C
Wartosc TTL
ICMP SYN
ACK Wartosc TTL
NAT_B
SYN (Małe TTL ICMP
SYN (Małe TTL ICMP
SYN (Małe TTL
ICMP
Spoof SYN-ACK
NAT_B
A a B otevírá naslouchající spojení (pro zjednodušení předpokládejme, že na portu 3000). Následně oba počítače provedou připojení k C na port 5000 použitím portu 3000 jako zdrojového portu (před použitím je zapotřebí zadat příkaz „bind” na otevřené kartě). V té chvíli klienti A a B naslouchají na portu 3000 a mají spojení s hostem C (zdrojový port 3000 a cílový port 5000). Od serveru S se dozvědí o svých veřejných rozhraních. Host A se dozví, že veřejné rozhraní B je 157.158.180.235 a používá port 3000 k připojení se k C (za předpokladu, že NAT R1 a R2 neupravují zdrojové porty při překladu). Stejné informace obdrží host B. Teď mohou A i B provést pokus o přímé připojení. A se připojí k veřejnému rozhraní hosta B s použitím portu 3000 jako zdrojového. Podobně postupuje B. Pokud NAT není symetrický, měl by použít port 3000 pro připojení se k A na veřejné rozhraní B. Ve chvíli průchodu paketu s nastaveným příznakem SYN skrz router, NAT si uloží informaci o mapování a bude pouštět pakety, které pocházejí od NAT druhého hosta. Průběh navazování spojení je skoro identický jako v případě komunikace pomocí UDP.
Wartość TTLA
Wartość TTLB
Wartość TTLB Wartość TTLA
Spoof SYN-ACK
SYN-ACK SYN-ACK
ACK
ACK ACK
ACK
Obrázek 17. Použití TTL k vytvoření P2P spojení
www.hakin9.org
hakin9 1/2007
13
atak
Pořadí posílání a získávání paketů má zde velmi velký význam. Mohou se vyskytnout následující případy: •
•
Paket se SYN počítače A přijde k R2 před odesláním paketu inicializujícího spojení s A hostem B (nebo opačný případ); A a B odešlou pakety současně, což způsobí, že B dostane paket se SYN pocházející od A a naopak. Pokud jsou pakety ideálně časově synchronizovány , dochází k tzv. rovnoběžnému otevření spojení.
V jednom i v druhém případě se vyskytne situace, při které host obsahující kartu naslouchající na portu P a pokoušející se navázat spojení za použití portu P jako zdrojového dostane paket s nastaveným příznakem SYN. V závislosti na implementaci TCP/IP fronty bude přicházející paket spojen buď s naslouchající kartou nebo s kartou, která se pokoušela navázat připojení. Ne vždy však oba případy vedou k navázání spojení. V prvním případě – je paket interpretován jako pokus o navázání spojení. Jako odpověď bude odeslán paket s nastaveným příznakem SYN-ACK. Funkce connect volána na počítači, který povolil připojení, vrátí chybu, protože adresy a zdrojové a cílové porty jsou používány jiným připojením. V případě, kdy SYN paket bude spojen s kartou pokoušející se navázat spojení, nebude naslouchající karta všeobecně využívána. Funkce connect vrátí stav svědčící o úspěšném spojení. Paket, který byl poslán druhým počítačem neobsahuje příznak ACK, proto TCP/IP pošle paket s nastaveným příznakem SYN-ACK (zachová originální a nastaví vlastní sekvenční číslo paketu). Druhá strana, ve chvíli, kdy odebírá paket s nastaveným příznakem SYN-ACK, potvrzuje synchronizaci sekvenčních čísel a spojení je připraveno k „použití”. Při využití této techniky se můžete dostat do situace, ve které si oba hosté vzájemně ve stejné chvíli
14
hakin9 1/2007
pošlou paket SYN a následně si oba současně potvrdí obdržené sekvenční čísla paketem SYN-ACK a následně ACK. Implementace TCP/ IP si s touto situací poradí různě. Možná je situace, ve které se z obou stran vyvolaný connect nepovede, ale spojení bude „magicky navázáno” naslouchajícími kartami (na obou stranách se povede accept). Využití této techniky s sebou přináší nutnost existence dvou karet připojených na stejný port. Některé systémy to neumí a proto musí použít sekvenční verzi výše popsaného algoritmu . Host A oznámí úmysl spojení se s B přes server C. Host B provede spojení k veřejnému rozhraní A. Toto spojení se nepovede, protože R1 nevpustí pakety z B. Následně B vytvoří naslouchající kartu a čeká na spojení s A. Pokud NAT na straně B neodstraní řádky se spojením B->A ve chvíli kdy se spojení nepodaří, pak může A přerušit spojení s C a provést pokus o připojení se na veřejné rozhraní B (s použitím stejného zdrojového portu, který používal při připojení na C). NAT na stroně B by měl vpustit požadavky A a umožnit naslouchající kartě počítače B navázání spojení.
Důvtipný čtenář si jistě všimne, že pokud NAT R1 a R2 nemění zdrojové porty, pak není prostředník C zapotřebí. Tato úvaha je dobrá jak pro protokol UDP, tak i pro TCP. Pokud hosté A a B znají adresy svých veřejných rozhraní, zvolili si port, na kterém chtějí provést spojení a začnou celou operaci ve stejné chvíli – spojení bude zrealizováno. V případě chybějícího překladu portu prostředník slouží pouze pro výměnu informací o IP adresách a synchronizaci celé operace.
TCP – jiný přístup
Složitost TCP protokolu způsobila, že existují alternativní přístupy k tomu, prezentovanému výše. Stejně jako v případě UDP je možno použít metodou spočívající na nastavení takové TTL hodnoty, aby mohl paket opustit lokální síť, ale natolik malou, aby nedošel na cílový router. Pokud oba hosty pošlou takové pakety způsobí to nastaveních jejich NAT routerů tak, aby přijímaly pakety patřící budoucímu spojení. Po otevření „tunelů” do NAT je možno postupovat třemi způsoby. První spočívá v infor-
Výpis 3. Skript v jazyce Perl, díky kterému se dozvíme, jak jsou mapovaná připojení v našem NAT #!/usr/bin/perl -w use strict; use IO::Socket; my ($sock, $remote, $message); $sock = IO::Socket::INET->new(LocalPort => 5000, Proto => 'udp') or die "socket: $@"; while ($remote = $sock->recv($message, 1024)) { my ($port, $addr) = sockaddr_in($remote); my $host_str = inet_ntoa($addr); printf "[%s:%5d]> %s\n", $host_str, $port, $message; } die "recv: $!";
O autorovi
Konrad Malewski, absolvent informatiky na Slezské Polytechnice. Momentálně je doktorandem informatiky na AGH. Správce amatérských počítačových sítí. Jak v práci tak i doma se zabývá programováním a bezpečností síťových aplikací.
www.hakin9.org
mování prostředníka skrz A a B o sekvenčních číslech použitých k vytvoření tunelu. Následně prostředník odesílá dva pakety s falešnými zdrojovými adresami. Pakety mají nastavené příznaky SYN-ACK a jejich úkolem je simulování druhé fáze spojení A s B a B s A. Využití této techniky s sebou nese také nutnost nalezení ISP, který umožní posílání falešných rámců, což může znamenat největší problém. Další nápad spočívá v tom, aby po otevření tunelu v NAT přes hosta A (paketem SYN), pouze host B se pokoušel o přímé propojení k veřejnému rozhraní hosta A. Na rozdíl o předchozího způsobu, prostředník slouží výhradně k synchronizaci. Třetí přístup vyžaduje otevření tunelu na obou stranách – jak na NAT hosta A i B. Navíc je vyžadována výměna informací o sekvenčních číslech užitých k otevření „tunelu” přes prostředníka. Následně hosté A a B posílají každý po jednom paketu. Paket by měl mít nastavené příznaky SYN-ACK a sekvenční číslo vzdáleného počítače získané od prostředníka. Jedna z výše popsaných metod byl implementována do knihovny XSTUNT [14]. K vytvoření přímých spojení využívá prostředníka který kromě synchronizace slouží také k detekci typů NAT spojujících se klientů. Server ke správné funkci vyžaduje dvě IP adresy, které jsou využívány k popsání typu NAT. Abychom spustili server, stačí zadat příkaz: ./XSTUNTServer 157.158.180.200 157.158.180.201
Na stránce XSTUNT je dostupná ukázka klienta a serveru knihovny. Server se zaregistruje na prostředníkovi a očekává připojení od klienta. Klient připojující se k serveru (pomocí prostředníka) mu odesílá text zadávaný interaktivně z klávesnice . Když server přijme data od klienta, pak je ihned klientovi pošle zpět. Samozřejmě, že spojení mezi klientem a serverem je přímým spojením mezi lokálními
www.hakin9.org
hakin9 1/2007
15
atak
sítěmi. Abychom zkontrolovali fungování příkladu ze stránky, stačí na hostu A zadat příkaz:
./xecho client client_id to_je_id_
./xecho server to_je_id_mého_serveru
Pokud vše půjde dobře, pak text zadaný do okna terminálu hosta B bude přijmut serverem A a odeslán zpět na klienta B.
157.158.180.200 157.158.180.201
Zatímco na počítači B je nutno spustit stejný program pouze s jinými parametry:
mého_serveru 157.158.180.200 157.158.180.201
Zdroje: • • • • • • • • • • • • • •
http://news.zdnet.com/2100-1009_22-842973.html – článek předpovídající vyčerpání IP adres v roce 2005 http://bgp.potaroo.net/ipv4/ - zpráva předpovídající využití IP adres v budoucnosti http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj _8-3/ipv4.html – zpráva o „spotřebování” IP adres http://nutss.gforge.cis.cornell.edu/pub/imc05-tcpnat/ - analýza a popis techniky průchodu NAT a firewallu http://www.brynosaurus.com/pub/net/p2pnat/ - popis techniky průchodu NAT za použití UDP a TCP http://freshmeat.net/projects/nat-traverse/ - knihovna používající v článku popsané techniky http://nutss.gforge.cis.cornell.edu/stunt.php – domovská stránka STUNT (Simple Traversal of UDP Through NATs and TCP) http://freshmeat.net/projects/stund/ - domovská stránka klienta a serveru využívajícího STUN http://vtun.sourceforge.net/ - program umožňující vytvořit virtuální ethernetový tunel zabalený do TCP nebo UDP http://openvpn.net/ - implementace pokročilejší verze VPN než VTUN Linux Server Hacks, Oreilly 2003 – v této knize najdete mnoho zajímavých rad. Mezi jinými i popis VPN tunelování v SSH, který byl částečně popsán v článku http://samy.pl/chownat/ - stránka, ze které je možno stáhnout program chownat http://linide.sourceforge.net/nat-traverse/ - zde najdeme skript nat-traverse http://www.cis.nctu.edu.tw/~gis87577/xDreaming/XSTUNT/index.html – zde se nachází knihovna XSTUNT a ukázkový program.
Terminologie •
•
•
NAT – (anglicky Network Address Translation), zvaný také „maškaráda”. Služba fungující na routeru umožňující počítačům v lokální síti transparentní přístup k jiné síti (obvykle Internet). Často se můžete setkat s výrokem host NAT, host za NATem. V prvním případě jede jednoduše o počítač, na kterém je spuštěna služba NAT. Druhý výraz je používán pro popsání počítače používajícího tuto službu. STUN – (anglicky. Simple Traversal of User Datagram Protocol Through Network Address Translators). Obecně označuje protokol, díky kterému host za NAT může detekovat svou veřejnou adresu, typ NAT, způsob mapování jeho připojení atd. Tímto jménem jsou také popsány techniky vytváření připojení mezi lokálními sítěmi s pomocí protokolu UDP. TURN – (anglicky Traversal Using Relay NAT). Protokol s jeho pomocí si dva počítače nacházející se v různých lokálních sítích posílají data s využitím prostředníka.
Paket SYN, Paket SYN-ACK, Paket ACK – Hlavička protokolu TCP obsahuje pole, které je příznakem, jež je využíván mj. pro navazování, ukončování či synchronizaci připojení. Paket SYN nastavuje zprávy TCP nastavením příznaku SYN. Pakety SYN-ACK a paket ACK analogicky.
16
hakin9 1/2007
www.hakin9.org
Černé mraky na obzoru a nejenom ony
Pokud má NAT stavový počítač, s jehož pomocí filtruje pakety, které by neměly být přeposlány v daném stavu, je možné, že se nám nepodaří navázat spojení. Například, pokud jedinou NAT přijímanou sekvencí paketů je SYN, SYN-ACK, ACK, pak NAT nepřijme druhý přicházející paket SYN uváděný v druhém přístupu či odcházející paket SYN-ACK z třetího přístupu, a to nemluvíme o metodě, která nepoužívá metodu s TTL. Další problém může být interpretování ICMP paketů a těch s nastaveným příznakem RST, které mohou způsobit změnu vnitřního stavu spojení v NAT. Ale měli byste vědět, že i nejzarytějším NAT je možno za příznivých podmínek „projít”. Stačí využít mechanismus předpovídání portů, dobře sesynchronizovat chvíli navázání připojení nebo upravit TCP/IP na straně klientů tak, aby byl ve stavu navázání TCP připojení umožňující malou odchylku od pravidel protokolu. Popsání všech nápadů, které byly použity pro průchod NAT by vzalo mnohem více místa než tento článek a stačilo by na malou knihu.
Čekání na konec světa
Průchod mechanismem překladu adres a portů je velmi zajímavou a vzdělávací činností. Je možno se mnoho naučit nejenom o mechanismu fungování NAT, ale také poznat pravidla řídící fronty TCP/IP. Výrobci software a VoIP zařízení používají výše uvedené techniky ve svých řešeních prakticky od chvíle, kdy se tato technologie začala masověji využívat. Problém navazování přímých spojení je momentálně velmi aktuální. Proto bude muset být konec světa zmiňovaný na začátku článku posunut na blíže nespecifikovanou budoucnost a je dobré zamyslet se, zda v jisté chvíli nebudeme nuceni změnit protokol třetí vrstvy nebo zda nebudeme muset přivést techniky průchodu skrz NAT k dokonalosti. l
