DETEKCE FIREWALLU, SONDOVANI SITI
=================================
Tento dokument je diskusi o technikach identifikace, detekce a pruniku firewally, se zamerenim na schopnost pruzkumu site
nachazejici se za timto. Dalsi cast hovori o schopnostech ziskani pristupu ke klici nebo cilove siti za firewallem, bez
potreby vyrazeni/pozmeneni firewallu - pomoci techniky presmerovani portu. Je treba mit znalost siti, UNIXovych systemu
a utility nmap(http://www.insecure.org/nmap).
..welcome_to_cyberspace..
=========================
Prinutme server pripojit se k iNetu mimo firewall. Od vzniku knihy "Cheswick and Bellovin's", hovorici o umisteni a
stavby firewallu, jsou tyto stale potrebne pro ISP, hostingove spolecnosti, bezne uzivatele. Stejne destruktivni, nedbaly a
sebevrazedny, je povoleni nezkusenemu konfigurace firewallu. Obvykle to byva sitovy nebo systemovy administrator.
Spravce by mel mit zkusenosti se siti..ale jejich odbornost v zabezpeceni muze byt omezena. Tito smeruji k
nekonfigurovatelnym firewallum. Z toho plyne; prilis si jisty spravce, domnivajici se o neprustrelnosti vlastni site..
ma bozskou diru v paketovem filtru...
Uvod:
=====
V techto dobach existuji dva typy nejpouzivanejsich firewallu; Aplikacni proxiny a brany s paketovymi filtry. Vetsinou
si lide mysli, ze aplikacni proxiny jsou bezpecnejsi nez paketove filtry. hm. Aplikacni filtry jsou vice prisnejsi na
kontrolu paketu smerujici do site a stejne tak prisne jsou na tyto odchozi. Brany s paketovymi filtry mohou byt nalezeny
ve velkych korporacnich siti z duvodu velkeho vykonu a provoznich pozadavku. V minulych letech zabezpecily firewally
mnoho systemu a siti, zabezpecily je proti destrukcnim paketum, slidivym ocim..
V pripade pouziti jednoduchych firewallu , pak prave v techto docela casto vyvstavaji bezpecnostni diry. U kazdeho typu firewallu byl nalezen novy exploit s technikou obejiti. Nejvetsi zranitelnost v podobe exploitu predstavuji bezkonfiguracni firewally.
Neberte me spatne; dobre konfigurovatelny, dobre navrzeny, aktualizovatelny a udrzovany firewall, je stezi proniknutelny.
Vetsina nas vnika do techto firewallu a neobtezuji se jimi; pokousi se nalezt cestu pro praci mimo ne. Bud exploitovanim duverihodneho, zabezpeceneho systemu za firewallem nebo dokonce utokem skrz nefiltrovanou sluzbu, napriklad dial-up.
Detekce soucasnych firewallu a svetu za nim
===========================================
Kazdy firewall ma svuj jedinecny styl rozpoznani sebe sama. Proto jsme schopni vyuzit tento identifikacni sled, pouzitim jednoducheho skenovani, grabovani banneru,etc.Rovnez muzeme rozpoznat verzi, typ a mozna i nejaka urcita pravidla. Tato identifikace se nezda byt dulezitou, ale jakmile zmapujeme jejich firewally, zacnou se vynorovat na povrch slabiny.
Vetsinou je nejjednodussi detekcni/identifikacni technikou, jednoduche skenovani otevrenych portu. Urcite firewally mohou byt identifikovatelne podle standardnich otevrenych portu.
- CheckPoint's Firewall-1 standardne naslloucha na TCP portech 256,257,258.
- Microsoft's Proxy Server standardne nassloucha na TCP portech 1745 a 1080.
Ostatni firewally maji sve vlastni standardni porty. Pouzitim nmapu a jistych parametru jsme schopni projet kazdy firewall,
nebo vubec zjistit jeho existenci. Jednoduse:
[root@localhost]# nmap -n -vv -P0 -p256, 257, 258, 1080, 1745 10.10.1.8
Jsem si jist, ze kdokoli zkuseny vytvari tyto skeny na sit, k poskytnuti informaci o firewallu nebo paketovem filtru.
Mimochodem, Intrusion Detection Systems neboli IDS, tyto skeny neumoznuji. Ale i tyto loguji pouze hardcore skeny.
Dobrou technikou identifikace firewallu je grabing banneru.
C:\> nc -v -n 10.10.1.8 23
(UNKNOWN) [10.10.1.8] 23 (?) open
Eagle Secure Gateway.
Hostname:
Pro vetsi jistotu existence firewallu, hod netcat na TCP 25:
C:\> nc -v -n 10.10.1.8 25
(UNKNOWN) [10.10.1.8] 25 (?) open
421 10.10.1.8 Sorry, the firewall does not provide mail service to you.
Tim je jasne, ze nas hostitel je firewall. Prejdeme k mapovani site.
Ehm. Treti zpusob identifikace firewallu je technika identifikace portu. Nejake firewally mohou vracet sekvenci mnoziny cisel, proto je mozne rozpoznat typ a verzi firewallu. Pripojme tedy netcat k SNMP portu 259 s implementovanym Checkpoint Firewall-1 :
[root@localhost]# nc -v -n 10.10.1.72 259
(UNKNOWN) [192.168.21.1] 259 (?) open
30000003
[root@localhost]# nc -v -n 10.10.1.95 259
(UNKNOWN) [192.168.29.212] 259 (?) open
31300003
Dalsi technika pouziva ladici nastroje. Traceroute pracuje jemne. Traceroute, znamy jako tracert.exe na Win systemech, je sitova ladici utilita, pouzivana k detekci aktivnich hopu, smerujicich k hostiteli. Standardne odesila UDP nebo ICMP ECHO pakety pomoci prepinacu a voleb. Tyto pakety obsahuji pole s TTL[cas ziti]. TTL je nastaveno na 1. Hodnota TTL vzroste o 1 za nalezeneho hostitele, proto paket dojde k poslednimu neodhalenemu hostiteli s TTL 0. Kdyz tento paket s TTL 0 dosahne routeru, router bude standardne odpovidat chybovym hlasenim ICMP, puvodnimu traceroutingovemu hostiteli. Traceroute si vybere vysoky UDP port, ktery bude velmi nepravdepodobne pouzivan jakoukoli bezici sluzbou nebo aplikaci - tak se nemohou vyskytnout chyby. Proto muze byt traceroute pouzit pro odhaleni firewallu. Nasledujici priklad ukazuje zakladni traceroute pokus objeveni firewallu.
Traceroute:
===========
V tomto pribehu plnem vasne a zrady, je sit chranena paketovym filtrem, ktery blokuje vsechny excesy a prohledava provoz s vyjimkou ping a jeho odezev[typy ICMP 8 a respektive 0]. Muzeme se pokusit pouzit traceroute ke zjisteni, jak slaby je tento filtr, ktery muze byt firewallem nebo routerem[ktery je podle vseho proti bezpecnostnim pravidlum].
[root@localhost]# traceroute 10.10.1.10
traceroute to 10.10.1.10 [10.10.1.10], 15 hops max, 20 byte packets
1 10.10.1.2 [10.10.1.2] 0.022 ms 0.024 ms 0.025 ms
2 10.10.1.3 [10.10.1.3] 1.327 ms 2.360 ms 2.380 ms
3 10.10.1.4 [10.10.1.4] 4.217 ms 4.612 ms 4.656 ms
4 10.10.1.5 [10.10.1.5] 4.927 ms 5.090 ms 5.238 ms
5 10.10.1.6 [10.10.1.6] 5.529 ms 5.812 ms 6.003 ms
6 10.10.1.7 [10.10.1.7] 56.921 ms 59.162 ms 61.762 ms
7 10.10.1.8 [10.10.1.8] 63.832 ms 63.682 ms 61.235 ms
8 * * *
9 * * *
10 * * *
Hop 7 na adresu 10.10.1.8 je predpokladany firewall. Ovsem, nemusi to byt pravda. Jak jsme se dozvedeli drive, firewall muze byt router, paketovy filtr nebo aplikace pro presmerovani. Nase pakety projdou skrz do odhaleni firewallu, pouzitim argumentu -I na Linuxove verzi traceroute.
[root@localhost]# traceroute -I 10.10.1.10
traceroute to 10.10.1.10 [10.10.1.10], 15 Hops Max, 20 byte packets
1 10.10.1.2 [10.10.1.2] 0.022 ms 0.024 ms 0.025 ms
2 10.10.1.3 [10.10.1.3] 1.327 ms 2.360 ms 2.380 ms
3 10.10.1.4 [10.10.1.4] 4.217 ms 4.612 ms 4.656 ms
4 10.10.1.5 [10.10.1.5] 4.927 ms 5.090 ms 5.238 ms
5 10.10.1.6 [10.10.1.6] 5.529 ms 5.812 ms 6.003 ms
6 10.10.1.7 [10.10.1.7] 56.921 ms 59.162 ms 61.762 ms
7 10.10.1.8 [10.10.1.8] 63.832 ms 63.682 ms 61.235 ms
8 10.10.1.9 [10.10.1.9] 62.926 ms 66.125 ms 67.032 ms
9 10.10.1.10 [10.10.1.10] 70.482 ms 71.273 ms 71.762 ms
10 10.10.1.11 [10.10.1.11] 73.192 ms 76.921 ms 82.325 ms
Takze, namisto pouziti defaultnich UDP TTL paketu, ktere jak se zda nepracuji, rozhodli jsme se prinutit traceroute pouzitim
prepinace -I, pakety ICMP. Pri peclivem prohlednuti vysledneho vystupu jsme schopni objevit hostitele a systemy za firewallem.
Jeden bezny scenar konfigurace je firewall blokujici vsechna spojeni a provoz smerujici dovnitr nebo ven ze site, s vyjimkou DNS. Toto jede na otevrenem UDP portu 53.
[root@localhost]# traceroute 10.10.1.10
traceroute to 10.10.1.10 [10.10.1.10], 15 hops max, 20 byte packets
1 10.10.1.2 [10.10.1.2] 0.022 ms 0.024 ms 0.025 ms
2 10.10.1.3 [10.10.1.3] 1.327 ms 2.360 ms 2.380 ms
3 10.10.1.4 [10.10.1.4] 4.217 ms 4.612 ms 4.656 ms
4 10.10.1.5 [10.10.1.5] 4.927 ms 5.090 ms 5.238 ms
5 10.10.1.6 [10.10.1.6] 5.529 ms 5.812 ms 6.003 ms
6 10.10.1.7 [10.10.1.7] 56.921 ms 59.162 ms 61.762 ms
7 10.10.1.8 [10.10.1.8] 63.832 ms 63.682 ms 61.235 ms
8 * * *
9 * * *
10 * * *
Prihledneme k nedavnemu prikladu..posledni objeveny hop je na 10.10.1.8. Predpokladali jsme zablokovani vseho, krome DNS.
Mame tuto znalost, kterou muzeme vyuzit v nas prospech. Pouzitim prizbusobitelneho traceroute, ktery nam dovoli sondovat cile za firewallem. Muzeme ovladat nekolik veci; pouzitim startovaciho portu, ktery je navysen kazdou sondou. Muzeme ovladat pocet odeslanych sond, ktere jsou standardne nastaveny na 3. Rovnez muzeme pouzit nasledujici urceni, kolik hopu je mezi nami a firewallem.
Zacatek naseho skenu se startovnim portem:
(target_port - (number_of_hops * num_of_probes)) - 1
Pokusime se oklamat firewall myslenkou, ze jsme zaslali dotazovaci paket na DNS - tim obejdeme ACL[Access Control Lists]. Pouzitim vzorce vyse uvedeneho, docilime konfigurace a prizpusobeni treceroute. Rovnez si vsimnete, ze firewall neprovadi analizu obsahu paketu, proto mohou byt pakety spoofnuty.
Vzorec promennych vlozeny do scenare:
( 53 - ( 8 * 3 )) - 1 = 28
Nove upraveny paket bude mit cislo vhodneho vstupniho portu, proto mame moznost obejiti ACL.
Nasleduje priklad:
[root@localhost]# traceroute -p28 10.10.1.10
traceroute to 10.10.1.10 [10.10.1.10], 15 hops max, 20 byte packets
1 10.10.1.2 [10.10.1.2] 0.522 ms 0.624 ms 0.625 ms
2 10.10.1.3 [10.10.1.3] 5.327 ms 6.360 ms 6.380 ms
3 10.10.1.4 [10.10.1.4] 7.217 ms 7.612 ms 7.656 ms
4 10.10.1.5 [10.10.1.5] 8.927 ms 9.090 ms 9.238 ms
5 10.10.1.6 [10.10.1.6] 9.529 ms 10.812 ms 12.003 ms
6 10.10.1.7 [10.10.1.7] 56.921 ms 59.162 ms 61.762 ms
7 10.10.1.8 [10.10.1.8] 63.832 ms 63.682 ms 61.235 ms
8 10.10.1.9 [10.10.1.9] 65.158 ms * *
9 * * *
10 * * *
Vzpomente si na fakt, ze traceroute zvysuje hodnotu portu pro kazdou odeslanou sondu, tim skonci po nestalem skenovani naseho ciloveho firewallu. Proto mela prvni sonda prideleny port UDP 53[DNS] a dalsi UDP 54. Paketovy filtr zalozeny na shromazdovani ACL, blokuje UDP 54. Abychom mohli dostat vice informaci a radne prosondovat sit, musime udrzet paket ve stavu schopnosti obejiti ACL. Coz znamena udrzet port UDP 53. Je zde moznost pouziti argumentu k vyrazeni inkrementace cisla portu pro kazdou sondu.[Toto umoznuje traceroute1.4a5 na http://www.packetfactory.com]
[root@localhost]# traceroute -S -p28 10.10.1.12
traceroute to 10.10.1.12 [10.10.1.12], 15 hops max, 20 byte packets
1 10.10.1.2 [10.10.1.2] 0.522 ms 0.624 ms 0.625 ms
2 10.10.1.3 [10.10.1.3] 5.327 ms 6.360 ms 6.380 ms
3 10.10.1.4 [10.10.1.4] 7.217 ms 7.612 ms 7.656 ms
4 10.10.1.5 [10.10.1.5] 8.927 ms 9.090 ms 9.238 ms
5 10.10.1.6 [10.10.1.6] 9.529 ms 10.812 ms 12.003 ms
6 10.10.1.7 [10.10.1.7] 56.921 ms 59.162 ms 61.762 ms
7 10.10.1.8 [10.10.1.8] 63.832 ms 63.682 ms 61.235 ms
8 10.10.1.9 [10.10.1.9] 62.926 ms 66.125 ms 67.032 ms
9 10.10.1.10 [10.10.1.10] 92.332 ms 93.214 ms 96.016 ms
10 10.10.1.11 [10.10.1.11] 101.523 ms 103.273 ms 103.923 ms
11 10.10.1.12 [10.10.1.12] 104.516 ms 105.523 ms 105.682 ms
12 10.10.1.13 [10.10.1.13] 109.231 ms 111.122 ms 117.923 ms
Firewalking:
============
Firewalking je metoda stavby paketu, s IP TTL vypocitanym pro zanik prave po jednom hop posledniho firewallu[traceroute]. Ocekavany vysledek: paket je pruchozi firewallem a zanika rizene. Proto vypousti "ICMP TTL expired in transit". Pochopitelne, jestlize je paket blokovan pravidly firewallu, pak odpadne a my dostaneme nulovou odezvu nebo ICMP 13[filtr paket zakazal]. Zaslanim po sobe jdoucich sond a zjistovanim, ktera odpovida a ktera ne, seznam pristupu na brane muze byt predurceny. Z toho duvodu je treba mit dve informace pred zacatkem se�ny[source_code na www.packetfactory.net/projects/]:
[root@localhost]# firewalk -n -P1-8 -pTCP 10.10.1.7 10.10.1.12
Firewalking through 10.0.0.5 (towards 10.0.0.20) with a maximum of 25 hops.
Ramping up hopcounts to binding host...
probe: 1 TTL: 1 port 33434: [10.10.1.1]
probe: 2 TTL: 2 port 33434: [10.10.1.2]
probe: 3 TTL: 3 port 33434: [10.10.1.3]
probe: 4 TTL: 4 port 33434: [10.10.1.4]
probe: 5 TTL: 5 port 33434: [10.10.1.5]
probe: 6 TTL: 6 port 33434: [10.10.1.6]
probe: 7 TTL: 7 port 33434: Bound scan: 7 hops [10.10.1.7]
port 135: open
port 136: open
port 137: open
port 138: open
port 139: *
port 140: open
Jak vidime, ACL pravidla jsme obesli pouzitim firewalkingu. A nyni zpet k nasi chladne radikalni utilite nmap. Duvodem je fakt, ze nmap skenuje hostitele jako bezny skenr a poskytuje info o otevrenych nebo zavrenych portech + info o zpusobu zablokovani portu. Jsou zde tri duvody nebo situace, ktere zapricini odpoved filtrovaneho portu:
1. nebyl prijat zadny SYN/ACK paket
2. nebyl prijat zadny RST/ACK paket
3. system odpovedel ICMP 3[cil necitelny] s kodem 13[komunikace administrativne zakazana].
Nmap pouzije vsechny tyto podminky a povazuje port za filtrovany. Priklad:
[root@localhost]# nmap -p21,23,53,80 -P0 -vv 10.10.1.10
Starting nmap V. 2.07 by Fyodor ([email protected], www.insecure.com/nmap/)
Initiating TCP connect() scan against (10.10.1.10)
Adding TCP port 21 (state Open).
Adding TCP port 53 (state Firewalled).
Adding TCP port 23 (state Firewalled).
Adding TCP port 80 (state Open).
Interesting ports on (10.10.1.10):
Port State Protocol Service
21 open tcp ftp
23 filtered tcp telnet
53 filtered tcp domain
80 open tcp http
Vidime vystup, kde je par portu za firewallem. Pouzitim vystupu tcpdump urcime duvod filtrace.
Raw_paket a HPING
=================
Raw pakety jsou tez pouzivane pro zkoumani site za firewallem. Hping pracuje tak, ze zasle TCP pakety na cilovy port, prijmuty paket pote analyzuje a vyhodnoti. Hping umoznuje objeveni prijate, blokovane, odhozene nebo zamitnute pakety.
Tak nam umozni prozkoumat pravidla ACL jeste vice do hloubky.
[root@localhost]# hping 10.10.1.7 -c2 -S -p21 -n
HPING 10.10.1.7 (eth0 10.10.1.1) : S set, 40 data bytes
60 bytes from 10.10.1.1: flags=SA seq=0 ttl=242 id=65121 win=64240
time=144.4 ms
Vezmeme nedavny priklad; na adrese 10.10.1.7 vidime otevreny TCP port 21 a skutecnost, ze jsme prijmuly paket s nastavenym priznakem SA, ktery jse v podstate paketem SYN/ACK. Ta zprava ukazuje na otevreny port, ale nevime zda je to firewall ci nikoliv. Provedeme trochu vetsi pruzkum.
[root@localhost]# hping 10.10.1.10 -c2 -S -p80 -n
HPING 10.10.1.10 (eth0 10.10.1.1) : S set, 40 data bytes
ICMP Unreachable type 13 from 10.10.1.8
Hping nyni prijme ICMP 13, coz v podstate znamena paket administrativne zakazan. Z techto mala prikazu jsme se utvrdili v myslence, ze 10.10.1.8 je firewall a nejspise nejde o blokovani portu 80 na 10.10.1.10. Dalsi pravdepodobna odezva obdrzenou od firewallu muze byt nasledujici:
[root@localhost]# hping 10.10.1.16 -c2 -S -p23 -n
HPING 10.10.1.16 (10.10.1.1) : S set, 40 data bytes
60 bytes from 10.10.1.1: flags=RA seq=0 ttl=59 id=0 win=0 time=0.5 ms
Toto ukazuje jednu ze dvou moznosti. Prvni muze byt, ze paket byl prijat firewallem a sedel pravidlum ACL, presto hostitel na tomto portu nenasloucha. Druha moznost je, ze firewall paket odmitl. Pouzitim ICMP 13, ktery jsme obdrzeli drive, muzeme predpokladat, ze firewall povoli nasemu paketu projit skrz, ale hostitel nenasloucha. A pochopitelne, kdyz paranoidni spravce konfiguruje firewall k blokovani vsech paketu, pak prijmeme:
[root@localhost]# hping 10.10.1.16 -c2 -S -p23 -n
HPING 10.10.1.16 (10.10.1.1) : S set, 40 data bytes
Skaning zdrojovych portu
========================
Tato technika se tyka aplikacnich paketovych filtru a zarizeni, ktere neudrzuji stavy. Priklad: Cisco IOS.
Kdyz vezmeme v uvahu, ze firewall neudrzuje stavy, pak nemuzeme zjistit, zda jde spojeni dovnitr nebo ven. V tomto pripade, mohou prenosy projit skrz nefiltrovany port. Nastavenim zdrojoveho portu na bezny port, ktery umozni pruchod firewallem - vezeme si drivejsi priklad, port UDP 53. Pouzijme volbu -g s nmapem:
[root@localhost]# nmap -sS -P0 -g 53 -p 139 10.10.1.15
Jestlize prijmeme kladny vystup otevrenych portu, pak nejspise jde o zranitelny firewall.
Chybne konfigurovane ICMP pakety
================================
To je dobre zdokumentovane na www.blackhat.com. Nicmene, muzeme pouzivat ruzne metody vyvolani ICMP chybovych hlaseni od sondovaneho hostitele a objevit tak jeho existenci. Nasleduje cast techto metod:
- mandlovani IP zahlavi
- ruzna delka pole hlavicky
- pole IP voleb
- pouziti neplatnych hodnot pole v IP zahlavi
- pouziti platnych hodnot pole v IP zahlavi
- zneuziti fragmentace
Pouzitim prvni metody, kde mame spatne IP zahlavi v IP datagramu generujici chybu ICMP Parametr_Problem nebo se vraci od sondovaneho hostitele na zdrojovou IP adresu. Druha metoda pouziva neplatne hodnoty pole v zahlavi IP, za ucelem prinutit sondovany pocitac ke generovani chyboveho hlaseni ICMP Destination Unreachable zpet k nam. Treti metoda pouziva fragmentace ke spusteni chyboveho hlaseni ICMP Fragment Reassembly Time Exceeded ze sondovane masiny. Posledni metoda pouziva UDP Scan pro vyvolani chyboveho hlaseni ICMP Port Unreachable na uzavrenem UDP portu sondovaneho hostitele. Pro vetsi zazitky hod oko na http://expert.cc.purdue.edu/~frantzen.
Jestlize prosondujeme cely rozsah IP adres, se vsemi kombinacemi protokolu a portu, cilove site,dostaneme tak paradni mapu topologie site a zaroven budeme schopni urcit ACL paketoveho filtru.
..
Je mnoho zpusobu detekce a sondovani site.Nicmene, dobre konfigurovany firewall se da tezce obejit. Nastroje jako traceroute, nmap, hping a dalsi, mohou byt pouzity k objeveni pristupovych cest skrz firewall i s jeho identifikaci. Velikou zranitelnost predstavuji bezkonfiguracni ACL pravidla firewallu nebo nedostatecne sledovani logu, traffiky.