Portscan

A Unix/Linux szerverek üzemeltetése wikiből
A lap korábbi változatát látod, amilyen KornAndras (vitalap | szerkesztései) 2012. április 4., 12:18-kor történt szerkesztése után volt.

Írta: Kovács Zsombor

Tartalomjegyzék

1 A portscannelésről általában

TCP/IP-s protokollstacket használva gépünk több, mint 65.000 különféle porton kommunikálhat. Egy portnak alapvetően hat állapota lehet:

  • Open: a portra érkező csomagokkal foglalkoznak és van egy alkalmazás, amely reagál az ide érkező adatokra. A portscannelés legfontosabb célja, hogy az összes ilyet megtaláljuk.
  • Closed: a port reagál a kérésekre, de nincs alkalmazás, amely használná.
  • Filtered: a legidegesítőbb mind közül. A portot szűrik, és az nmap ebben az esetben nem tudja eldönteni, hogy open vagy closed állapotban van-e (azaz ha pl. egy tűzfallal kiszűrik valamelyik irányban a csomagokat, vagy kéréseink egy DROP-actionben végződnek a célgép iptables-beállításaiban.)
  • Unfiltered: bár a csomagjainkat nem szűrik, az nmap mégsem tudja eldönteni a port állapotát. Az ACK-szkennelés eredményezi.
  • Open/filtered: az nmap nem tud dönteni, hogy a port open vagy filtered. Az olyan szkennelési módoknál kapunk eredményt, amelyeknél az jelzi a port nyitott állapotát, hogy nem érkezik válasz (UDP, FIN, PROT, Xmas scantípusok).
  • Closed/filtered: ld. feljebb, csak itt a close és a filtered között vacilálunk. IPID idle scan esetén.

2 Az nmap scantípusai

  • sP: ping scan. Egyszerűen megpingeti a célpontol és ha választ kap, örülünk - máris van mire célozni a többi scantípust. Az alap mód az ICMP echo request/reply, ezt azonban mostanra sok helyen szűrik. Az ICMP azonban lehetőséget ad többfajta módra is, amivel a célpontot válaszra lehet bírni: ezeket nagyon nehézkes szűrni, és ha szűrik, fennakadásokat okoz a legitim hálózati forgalomban.
    • PE/PP/PM: ICMP echo, timestamp és netmask kéréseket küld a célpontnak.
    • PS/PA/PU: SYN, ACK és UDP csomagokkal bírja válaszra a célpontot. Fontos megjegyezni, hogy a -PS 80 működése nem azonos a portscannelés közbeni SYN csomagokéval: az előbbi célja egyszerűen annyi, hogy kiderítse, működik-e az adott IP-n valaki.
  • sS: a default, SYN scan. A TCP-s háromutas kapcsolatfelvételi mechanizmus első (SYN) csomagját küldi el a célportra. Ha érkezik rá SYN/ACK, akkor a port open, ha RST, akkor closed állapotban van. Ha ICMP port unreachable vagy semmi sem érkezik, akkor a port filtered. A leggyorsabb és legkedveltebb az összes scantípus közül, viszont kellő körültekintéssel kell élni az intenzitás megválasztásánál: gyakorlatilag DoS is megvalósítható vele és figyelmes rendszergazdák szűrni szokták.
  • sT: az aktuális oprendszer TCP protokoll-implementációjának connect() függvényét használja a kapcsolódásra, nem közvetlenül küldi ki a kapcsolatfelvételi csomagot. Akkor használatos, ha valamiért nem tudunk közvetlenül SYN csomagot küldeni (pl. nem root-ként indítjuk el az nmap-ot. Erre a „sorry, dude!” hibaüzenettel figyelmeztet is. Érdekes scantípus olyan szempontból, hogy ez a legzajosabb, ugyanakkor a legnagyobb rejtőzködést is ez biztosíthatja: zajos, mivel a kapcsolatokat minden esetben megpróbálja felépíteni, viszont megvan az az óriási előnye a többi scantípussal szemben, hogy proxyzható.
  • sM, sF, sX, sN: Maimon, FIN, Xmas és NULL scan. Gyakorlatilag ugyanarra a logikára működnek: beállítunk egy bizonyos értelmetlen flagbit-kombinációt a TCP fejlécében, majd útjára engedjük a csomagot. A Maimonnél a FIN+ACK, FIN-nél csak a FIN, az Xmas-nél a FIN+PSH+URG flagek vannak bekapcsolva, NULL-nál értelemszerűen semmi. Az egész játék arra megy ki, hogy a TCP RFC-jét teljes egészében megvalósító implementációk eldobják az ilyen értelmetlen csomagot, ha a porton értelmes forgalmat várnak (azaz nyitva van) és RST-t küldenek vissza, ha a port closed. Butább állapotmentes tűzfalakon keresztül is működik a dolog, azonban mivel a figyelmes rendszergazdák is olvassák az nmap dokumentációját, könnyen szűrhető - másrészt az nmap lehetőséget nyújt arra is, hogy a nyolc flagbitet tetszés szerint kapcsolgassuk a tapogatózáshoz (--scanflags kapcsoló).
  • sA: ACK scan. Különbözik az előzőektől – soha nem mondja azt, hogy a port open (ugyanis mindenképp RST csomag jön vissza, akármelyik állapotban is van igazából a port). Arra használatos, hogy a célgép előtt őrködő tűzfal szabályait puhatoljuk ki. A kipuhatolás olyan módon történhet, hogy megscannelünk egy gépet, amelyről biztosan tudjuk, hogy a tűzfal mögött található. Ha a tűzfal helyesen beállított állapottartó, akkor nem fogunk választ kapni a csomagjainkra (ugyanis ACK csomagok nem kezdhetnek legitim kommunikációt). Ha azonban figyelmetlenül van bekonfigurálva és egy-egy portot szabadon hagy, akkor a célgép RST csomagot fog válaszul küldeni függetlenül attól, hogy a simogatott port open vagy closed állapotban van-e. Az nmap ezeket a portokat unfiltered-ként fogja jelölni.
  • sW: Window scan. Pontosan ugyanúgy működik, mint az ACK scan, viszont bizonyos rendszerek/implementációk esetén képes különbséget tenni a szűretlen portok open/closed állapotai között. Az alapötlet az, hogy a visszaérkező RST csomag TCP fejlécében a window mező értéke ezen implementációk esetében nulla, ha a port closed, viszont pozitív, ha open. Ha a éppenséggel nem jön be a window mezők különbözősége, széttárja a karját ésnem azt mondja, hogy unfiltered - ilyen értelemben pedig használhatóbb, mint a mezei ACK scan.
  • sI: Idle scan. A legkifinomultabb mind közül - azon alapszik, hogy nem a saját gépünkről végezzük a scannelést, hanem egy Ártatlan Áldozat forgalmát manipuláljuk úgy, hogy végül is portscannelést hajtson végre a célgépen. Ennek megfelelően a scan eredménye azon portok listája lesz, amelyet az áldozat lát! A következőképp működik: az operációs rendszer minden általa kiküldött csomagnak egyedi számot ad: ez az IP fejlécben lévő IPID érték. Butább operendszerek (pl. Xp, vagy a legtöbb nyomtató oprendszere) inkrementálisan növelgetik ezt a mezőt az egymás utáni csomagok kiküldésekor. A Támadó két dolgot csinál egyszerre: egyrészt folyamatosan SYN csomagokat küld a zombi egy ismert, unfiltered portjára, amire az annak rendje-módja szerint válaszol. A kettes pályán olyan csomagokat küld a hálózatra, amelyek feladója a zombi, címzettje pedig a célpont: a célpont nyilván a zombinak fog válaszolni ezekre a csomagokra. A varázslat itt jön: ha a célpont nyitott portját szólította meg a csomag, akkor a zombi egy SYN/ACK-ot kap, amire neki RST-t kell küldenie. A kiküldött RST viszont ugrást fog okozni az egyes pályán, a támadónak visszaküldött RST-k (nyitott port esetén SYN/ACK-ok) IPID-szekvenciájában - a támadó pedig pont erre figyel.
    Számos tulajdonsága közül a tisztasága a legvonzóbb; a saját ip-tartományunk vagy MAC-címünk soha nem kerül a célpontra felügyelő IDS-ek elé. Hogy hogyan találhatunk zombit? Nagyon egyszerű: használjuk a Nessust. A plugin száma 10201.
  • sO: Kitapogatja, hogy az IP-re épülő protokollok (UDP, TCP, ICMP, IGMP,...) közül melyekre hallgat a célpont, így igazából nem is portscanner a szó hagyományos értelmében. A TCP fejlécben beállítjuk a tapogatott protokoll azonosítóját, majd elküldjük a csomagot a célgépnek. A headerek korrekt kitöltésével a legtöbb esetben nem is foglalkozik az nmap: ha ICMP protocol unreachable érkezik vissza, akkor a protokollt closed-nak nyilvánítjuk. Ha érkezik válasz az adott protokollra, akkor open, ha pedig egyéb ICMP hibaüzenetet kapunk, a protokoll filtered. Ha az újraküldés után sem érkezik semmi, a protokoll open/filtered.
  • b: FTP bounce scan. Az eredeti RFC szerint való FTP-szerverekben van egy feature, ami azt csinálja, hogy csatlakozva egy FTP-szerverhez kérhetjük, hogy a file-okat egy harmadik félnek küldje! (Egy ideális világban ezzel lehetne megoldani egyszerűen azt, hogy az A gépen ülő júzer a B gépen lévő fájlokat a C gépre juttassa úgy, hogy az A gépen csak a parancscsatorna megy keresztül, maguk a másolt fájlok nem.) Ezen a sec. hole-on persze egy tankhajó is keresztülfér, így aztán a legtöbb implementációban egyszerűen nem engedélyezik ezt a proxy-szerű funkciót. (Gondoljunk bele: pl. wardrivinggal lesniffelünk egy plaintext ftp-bejelentkezést, majd a megszerzett usernévvel-jelszóval feltöltjük az ftp-szerverre az exploit kódját és ha az ftp-szerver támogatja ezt a proxy-funkciót, akármelyik hosztra ráuszíthatjuk a vállalati hálózaton...) Portscanre eléggé triviális rávenni az ilyen ftp-proxyt: egyszerűen megmondjuk a célgép ip-jét és a minket érdeklő port számát és az ftp-szerver elvégzi a piszkos munkát azzal, hogy megpróbál áttölteni valamit.
bt pentest # nmap -b zombie.ftp.hu -v -PN celpont.hu

Starting Nmap 4.60 ( http://nmap.org ) at 2008-07-10 11:25 GMT
Initiating Parallel DNS resolution of 1 host. at 11:25
Completed Parallel DNS resolution of 1 host. at 11:25, 0.00s elapsed
Attempting connection to ftp://anonymous:-wwwuser@@zombie.ftp.hu:21
Connected:220-Welcome to the archive!
220-
220-All transfers are logged with your username and hostname.
220-
220-This machine is a dual Intel(R) Xeon(TM) CPU 3.20GHz with 4GB memory and 2TB RAID5
220-storage, powered by Gentoo Linux (http://www.gentoo.org).
220-
220-
220-
220
Login credentials accepted by FTP server!
Initiating TCP FTP bounce scan against celpont.hu (1.2.3.4) at 11:26
Discovered open port 1723/tcp on celpont.hu
Discovered open port 25/tcp on celpont.hu
  • sU: UDP scan. A TCP-től eltérően az UDP kapcsolat- és állapotmentes, így a scan úgy történik, hogy egy üres UDP csomagot küldünk a célgép egy portjára. Ha ICMP port unreachable jön vissza, a port closed, ha egyéb ICMP hiba, akkor open/filtered. Ha értelmes válasz érkezik UDP-n, akkor a port nyitva van. Tipikus használati módok: DHCP, Kazaa, játékok stb. felderítésére (egyébként érdemes elgondolkozni, hogy a hentelés közben harmadszorra is felugró, figyelmeztető tűzfalablakon a felhasználók legnagyobb része mindent megenged az adott játéknak). A legnagyobb nehézséget az UDP-s scannelésben az jelenti, hogy megfelelő időlimitet válasszunk a port felé küldött csomagok között. Fontos megjegyezni, hogy bámelyik TCP-s scan móddal használható karöltve, TCP-s scanmódokat nem lehet egymással zatyulni!


3 Az NMAP portkezelése

Az NMAP lehetőséget ad arra is, hogy megadjuk a minket érdeklő portok listáját. Az alábbi kapcsolók segítségével érhető el a portkezelés:

  • -p: megadható port, porttartomány. Ha -sO kapcsolóval együtt használjuk protokollscannelésre, a protokollok kódját kell értelmszerűen megadnunk.
  • -F: gyorsított scannelés, a leggyakoribb portok listáját pörgeti végig. Ha kerülni szeretnénk a feltűnést, kiváló választás; az nmap_services file-ban lehet személyre szabni a listát.
  • -r: nem keveri meg a kipróbált portok sorrendjét, hanem egyszerűen elindul az 1-esen és addig megy, amíg el nem éri a 65535-öt.
  • --allports: nem hagy ki egy portot sem a portscanből. Általában érdemes átugrani a 9100-as portot, mivel sok nyomtató egyszerűen kiírja az ide érkező adatokat (ezáltal sok-sok mókusnak otthont adó erdőt kell kivágni az elpazarolt papír miatt, amint számtalan oldalnyi SSL-handshake-et vagy HTTP-kérést nyomtatunk nagy lelkesen).


4 Hátborzongatás

A fenti funkciók mellett az nmap még egy sereg dologra is képes, ezek között vannak elég hátborzongatóak is (jelen sorok írója például egészen elképedt, hogy egy háromnapos, tűzfalazott, otthoni használatra szánt Xp-n mennyi nyitott port is van és hogy az nmap a nyitott portok mellett egy sereg információt is megmond a gépről...) Ezen funkciók közül az operációs rendszer és a rajta futó szolgáltatások típusának és verziószámának(!) kiderítése a leghasznosabb - mind a rendszergazda, mind a Gonosz Cracker szempontjából.

A hátborzongató funkciók elérésére szolgáló kapcsolók az alábbiak:

  • sV, A, : verziódetektálás. Az nmap a tcp stack tulajdonságai és különféle nem szabványos csomagokra történő válaszok alapján több száz oprendszert tud felismerni és ha nem biztos a dolgában, három-négy lehetőséget ad vissza.
  • O: operációs rendszer detektálása. Az A kapcsoló tartalmazza.
  • --version-intensity: azt állíthatjuk be vele, hogy mennyire gyanakodjon szokatlan helyeken futó szolgáltatásokra. 1-től 9-ig lehet értéket adni - minél magasabb, annál valószínűbb a helyes diagnózis, viszont annál hosszabb ideig tart a scannelés.
  • --version-light: ~--version-intensity 2
  • -sR: RPC-re szolgáló portok felderítésére használható. Portscan után végignézi a nyitott portokat és a SunRPC NULL parancsával elárasztja őket abban a reményben, hogy valamelyik válaszol. A verziófelismerés már tartalmazza ezt, így önmagában ritkán használatos - ha viszont gyanakszunk valamelyik portra, hogy RPC céljából van nyitva, jó választás.

5 "Udvariasság"

A portscannelést végre lehet hajtani pokoli gyorsan (a szerző tapasztalatai szerint egy 100Mbit-es egyetemi/kollégiumi hálózaton ideális esetben nem egész egy másodperc alatt végigpörgethetők a portok), azonban ez nagyjából annyira csendes és észrevehetetlen, mintha a zsebtolvajt egy teljes hangerőn játszó tűzoltózenekar követné. Nagyon könnyű észrevenni - ha IDS működik a célpont hálózatán, szinte biztos, hogy valamilyen szankciót fog bevezetni az IP-nkről érkező csomagokkal szemben, másrészt pedig feltehetőleg jelzi a rendszergazdának, hogy mi történt. Vannak célpontok persze, amelyeknél annyi portscan történik úgyis, hogy eggyel több vagy kevesebb semmit sem számít - ilyen pl. a google.com, a whitehouse.gov és társaik.

Az időzítési tulajdonságok szempontjából a legfontosabb szabály az, hogy a scan időigénye O(n*p), ahol n a simogatott hosztok, p a vizsgált portok számát jelenti. Ennek megfelelően egy több száz gépből álló (pl. vállalati) hálózat okos, csendes felderítése akár több napig is eltarthat.

A -M kapcsoló segítségével megadható a párhuzamosan scannelt portok max. száma, ilyen módon jó kis DoS támadásokat lehet végrehajtani az nmap segítségével. Csak kiadjuk, hogy

nmap -T 5 -M 1000 -sT 1.2.3.4 

és várunk.

Jelmagyarázat: a lehető leggyorsabb portscan, egyszerre 1000 porton(!) próbálkozik egyszerre kapcsolatfelvétellel. A szerző saját, SP2 nélküli Xp professionaljét gyakorlatilag megölte az iménti parancs kikapcsolt tűzfallal, ha viszont be volt kapcsolva akárcsak a difót vindózos tűzfal, akkor is jelentős lassulást tapasztalt.

6 Tűzfalak, IDS-ek és egyéb házörzők

Az nmap számtalan opciót tartalmaz, amely igyekszik minél nehezebben felderíthetővé tenni a tevékenységét. Ezt az nmap fórumain néhányan nehezményezik: szerintük túlozottan megkönnyítik a crackerek dolgát azzal, hogy konkrét eszközöket integrálnak tűzfalak és IDS-ek elkerülésére az nmap-ba. Az nmap készítői azzal reagáltak a felvetésekre, hogy mivel a szoftver open-source, előbb-utóbb valaki biztosan beleteszi ezeket az opciókat, így viszont a rendszergazdák is próbára tehetik saját hálózatuk biztonságát.

A mezei portscan elég egyszerűen észrevehető, ha nem kellő körültekintéssel választjuk meg a paramétereit: lényegében egy olyan egyszerű, netflow statisztikákat megevő algoritmus is elég jól detektálja, amely egyszerűen a 60byte-os csomagokra érkező 40byte-os válaszokra figyel. Ha ilyenből egy hoszt sokat összeszed, akkor valószínűleg portscant hajt végre.

Csomagszinten figyelő tűzfalak és IDS-ek kijátszására jók az alábbi kapcsolók:

  • f: ezen kapcsoló használatakor a simogató csomagok nem egyben érkeznek meg a célpont közelébe, hanem apró fragmentek formájában - a célpont úgyis összerakja őket, viszont ha a csomag részeit külön-külön megvizsgálja egy csomagszűrő tűzfal, sokkal nehezebb dolga lesz a portscan azonosításakor. Az IP fejléc mögé 8byte-os adagokba pakolgatja a TCP header darabkáit - így pl. egy 20byte-os csomag helyett hármat küldünk ki, 8 byte-os mérettel. Óvatosan bánjunk ezzel a kapcsolóval, ugyanis sok kiszolgáló nem tudja megfelelően kezelni ezeket a parányi csomagocskákat, így előfordulhat, hogy a szolgáltatás felfedezése helyett jól seg.faultra futtatjuk a kiszolgálót. Kis kitérő: fragrouter.
  • --mtu: a paraméterül megadott MTU értéket veszi figyelembe, nyolccal oszthatónak kell lennie. Ekkora fragmentekben küldi ki az összes csomagot (még a ping-et is). Az -f kapcsolóval együtt nem használható.
  • D: decoy scan használata. Hamisított TCP/IP fejlécek segítségével a célpontban (és a körülötte őrködőkben) azt a (tév)képzetet kelti, hogy a portscan nem csak a mi címünkről jön, hanem az összes, a listában megadott hoszt egyszerre scanneli a célpontot. Ez persze nagyon hasznos, ugyanis a célpontnak fogalma sem lesz arról, hogy melyik támadó az igazi. Mindazonáltal óvatosan kell eljárni az ilyen "beárulásokkal", ugyanis a célpont a portscanre küldött csomagokat a "beárult" hosztoknak is elküldi, ilyen módon floodolja őket és csinosan leterheli a hálózatot. A kapcsoló szintaktikája szerint a "beárult" hosztokat vesszővel kell elválasztani és akár a saját IP-t jelentő ME string is beletehető. Az nmap fejlesztői szerint a hatodik helyre bebökve a legtöbb portscan-detektor nem fogja észlelni a címünket a sok hamis cím között (a szerző ezt némileg kétkedve fogadja, de ám legyen.) Kis kitérő: mire jó ez? Milyen esetekben lehet komoly szolgáltatáskiesést okozni?
  • S: IP-cím spoofolása. Bővebb magyarázatot nem igényel. Házi feladat: vajon mire lehet jó?
  • --source-port: forrásport meghamisítása. Hasznos pl., ha a tűzfal forrásport alapján szűr (pl. ha gonosz módon az irodából szeretnénk portscannelni, de csak a 80-as van kiengedve.) Másrészt aktív FTP-szerverekkel történő kommunikáció esetében vonzó lehetőség, hogy a buta tűzfalon nyitva hagyjuk az utat azoknak a kapcsolatoknak, amelyek a 20-as portról érkeznek (azaz a szerver számára lehetőséget biztosítsunk arra, hogy visszakapcsolódjon a kliensre). A crackerek számára egyébként ez a hozzáállás termi meg leginkább a gyümölcsét: a lusta rendszergazdák nem csinálják meg a bonyolult, ám biztonságos megoldást, hanem egy olyat vezetnek be, amelyik egyszerűen megcsinálható még az ebédszünet előtt, viszont kis tapogatózás után kihasználható.
  • --data-length: lehetőség van arra is, hogy random számokkal töltsük fel a csomagjaink payload részét (alapból ugye payload nélkül küldi ki a csomagokat, ami meg elég könnyen detektálható). Érdemes megnézni egyébként pl. a snort nmap-ra vonatkozó szabályait, ezeket egyesével lehet kicselezni különféle kapcsolókkal. Házi feladat: nézzétek meg a snort.org szabályai között az nmap-osakat, és cselezzétek ki őket! Nagyon tanulságos játék egyébként...
  • --ip-options: a megadott IP-fejlécmezőkkel küldhetjük ki a csomagjainkat. Gyakorlatilag az összes fenti opciót megadhatjuk így, de ezzel lényegében teljesen testre (és hálózatra) szabhatjuk a scant.
  • --randomize-hosts: ha több scannelt célgépet adunk meg, ezzel véletlenszerű sorrendben veszi őket, ezáltal nehezítve a házőrzők dolgát.
  • --spoof-mac: önmagáért beszél. Megadhatunk gyártót is (ebben az esetben a fennmaradó byte-okat véletlenszerűen tölti ki az nmap).
  • --badsum: helytelen ellenőrző összeggel küldi ki a csomagokat. Mivel ebben az esetben a célpont nem dolgozza fel a csomagot, ha választ kapunk ilyenre, akkor az szinte biztosan egy checksumot nem ellenőrző tűzfaltól jött.

Példa az nmap használatára

Tűzfal mögött csücsülő kiszolgáló vizsgálata, első kör: SYN scan. Óvatosak vagyunk, ezért cafatokban küldjük ki a csomagokat, hamis IP-ket is megadva.

root@chihiro:/home/zsombor# nmap -f -vv -sS -A -D84.3.181.158,65.55.213.14,ME www.xxxx.hu

Starting Nmap 4.10 ( http://www.insecure.org/nmap/ ) at 2006-11-30 14:10 CET
DNS resolution of 1 IPs took 0.00s.
Initiating SYN Stealth Scan against xxxxx.hu (1.2.3.4) [1679 ports] at 14:10
The SYN Stealth Scan took 35.93s to scan 1679 total ports.
Warning:  OS detection will be MUCH less reliable because we did not find at least 1 open and 1 closed TCP port
Host xxxxxx (1.2.3.4) appears to be up ... good.
All 1679 scanned ports on xxxxxx (1.2.3.4) are filtered
Too many fingerprints match this host to give specific OS details
TCP/IP fingerprint:
SInfo(V=4.10%P=i686-pc-linux-gnu%D=11/30%Tm=456ED882%O=-1%C=-1)
T5(Resp=N)
T6(Resp=N)
T7(Resp=N)
PU(Resp=Y%DF=N%TOS=0%IPLEN=164%RIPTL=148%RID=E%RIPCK=E%UCK=E%ULEN=134%DAT=E)

Nmap finished: 1 IP address (1 host up) scanned in 44.221 seconds
               Raw packets sent: 30855 (863.892KB) | Rcvd: 7 (1282B)

Jó lövés, szép védés - a célpont tűzfal mögött csücsül. Megpróbálhatjuk a kapcsolatfelvételt valamelyik bitbabrálós scantípussal is: nekem az Xmas scan a legszimpatikusabb.

root@chihiro:/home/zsombor# nmap -f -vv -sX -A -D84.3.181.158,65.55.213.14,ME 1.2.3.4

Starting Nmap 4.10 ( http://www.insecure.org/nmap/ ) at 2006-11-30 14:02 CET
DNS resolution of 1 IPs took 0.00s.
Initiating XMAS Scan against xxxxxx (1.2.3.4) [1679 ports] at 14:02
The XMAS Scan took 35.89s to scan 1679 total ports.
Initiating service scan against 1678 services on 1.2.3.4 at 14:03
Discovered open port 9/tcp on 1.2.3.4
Discovered open|filtered port 9/tcp on xxxxxx (1.2.3.4) is actually open
Discovered open port 13/tcp on 1.2.3.4
Discovered open|filtered port 13/tcp on 1.2.3.4 is actually open
Discovered open port 21/tcp on 1.2.3.4
Discovered open|filtered port 21/tcp on 1.2.3.4 is actually open
Discovered open port 22/tcp on 1.2.3.4
Discovered open|filtered port 22/tcp on 1.2.3.4 is actually open
Discovered open port 24/tcp on 1.2.3.4
Discovered open|filtered port 24/tcp on 1.2.3.4 is actually open
Discovered open port 25/tcp on 1.2.3.4
Discovered open|filtered port 25/tcp on 1.2.3.4 is actually open
Discovered open port 37/tcp on 1.2.3.4
Discovered open|filtered port 37/tcp on 1.2.3.4 is actually open
Discovered open port 53/tcp on 1.2.3.4
Discovered open|filtered port 53/tcp on 1.2.3.4 is actually open
Discovered open port 80/tcp on 1.2.3.4
Discovered open|filtered port 80/tcp on 1.2.3.4 is actually open
Discovered open port 110/tcp on 1.2.3.4
Discovered open|filtered port 110/tcp on 1.2.3.4 is actually open
Discovered open port 443/tcp on 1.2.3.4
Discovered open|filtered port 443/tcp on 1.2.3.4 is actually open
Discovered open port 587/tcp on 1.2.3.4
Discovered open|filtered port 587/tcp on 1.2.3.4 is actually open
The service scan took 108.53s to scan 1679 services on 1 host.
Warning:  OS detection will be MUCH less reliable because we did not find at least 1 open and 1 closed TCP port
For OSScan assuming port 9 is open, 43423 is closed, and neither are firewalled
Insufficient responses for TCP sequencing (0), OS detection may be less accurate
Host 1.2.3.4 appears to be up ... good.
Interesting ports on 1.2.3.4:
Not shown: 1667 open|filtered ports
PORT    STATE SERVICE    VERSION
9/tcp   open  discard?
13/tcp  open  daytime
21/tcp  open  ftp        ProFTPD 1.2.10
22/tcp  open  ssh        OpenSSH 3.8.1p1 Debian-8.sarge.6 (protocol 2.0)
24/tcp  open  priv-mail?
25/tcp  open  smtp       Sendmail 8.13.4/8.13.4/Debian-3sarge3
37/tcp  open  time        (32 bits)
53/tcp  open  domain     ISC Bind 9.2.4
80/tcp  open  http       Apache httpd
110/tcp open  pop3       Teapop pop3d 0.3.8
443/tcp open  ssl/http   Apache httpd
587/tcp open  smtp       Sendmail 8.13.4/8.13.4/Debian-3sarge3
1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at http://www.insecure.org/cgi-bin/servicefp-submit.cgi :
SF-Port24-TCP:V=4.10%I=7%D=11/30%Time=456ED695%P=i686-pc-linux-gnu%r(Gener
SF:icLines,27,"status=-1\0msg=Bad\x20client\x20protocol\x20type\0")%r(GetR
SF:equest,27,"status=-1\0msg=Bad\x20client\x20protocol\x20type\0")%r(HTTPO
SF:ptions,27,"status=-1\0msg=Bad\x20client\x20protocol\x20type\0")%r(RTSPR
SF:equest,27,"status=-1\0msg=Bad\x20client\x20protocol\x20type\0")%r(RPCCh
SF:eck,27,"status=-1\0msg=Bad\x20client\x20protocol\x20type\0")%r(DNSVersi
SF:onBindReq,27,"status=-1\0msg=Bad\x20client\x20protocol\x20type\0")%r(DN
SF:SStatusRequest,27,"status=-1\0msg=Bad\x20client\x20protocol\x20type\0")
SF:%r(Help,27,"status=-1\0msg=Bad\x20client\x20protocol\x20type\0")%r(SSLS
SF:essionReq,27,"status=-1\0msg=Bad\x20client\x20protocol\x20type\0")%r(SM
SF:BProgNeg,27,"status=-1\0msg=Bad\x20client\x20protocol\x20type\0")%r(X11
SF:Probe,27,"status=-1\0msg=Bad\x20client\x20protocol\x20type\0")%r(FourOh
SF:FourRequest,27,"status=-1\0msg=Bad\x20client\x20protocol\x20type\0")%r(
SF:LPDString,27,"status=-1\0msg=Bad\x20client\x20protocol\x20type\0")%r(LD
SF:APBindReq,27,"status=-1\0msg=Bad\x20client\x20protocol\x20type\0")%r(LA
SF:NDesk-RC,27,"status=-1\0msg=Bad\x20client\x20protocol\x20type\0")%r(Ter
SF:minalServer,27,"status=-1\0msg=Bad\x20client\x20protocol\x20type\0")%r(
SF:NCP,27,"status=-1\0msg=Bad\x20client\x20protocol\x20type\0")%r(NotesRPC
SF:,27,"status=-1\0msg=Bad\x20client\x20protocol\x20type\0")%r(WMSRequest,
SF:27,"status=-1\0msg=Bad\x20client\x20protocol\x20type\0")%r(oracle-tns,2
SF:7,"status=-1\0msg=Bad\x20client\x20protocol\x20type\0");
Device type: general purpose|media device|firewall
Running: Linux 2.1.X|2.2.X|2.4.X|2.6.X, Microsoft Windows Longhorn, Pace embedded, Symantec Solaris 8
Too many fingerprints match this host to give specific OS details
TCP/IP fingerprint:
SInfo(V=4.10%P=i686-pc-linux-gnu%D=11/30%Tm=456ED6FE%O=9%C=-1)
T1(Resp=N)
T2(Resp=N)
T3(Resp=N)
T4(Resp=N)
T5(Resp=N)
T6(Resp=N)
T7(Resp=N)
PU(Resp=Y%DF=N%TOS=0%IPLEN=164%RIPTL=148%RID=E%RIPCK=E%UCK=E%ULEN=134%DAT=E)
Service Info: OS: Unix

Nmap finished: 1 IP address (1 host up) scanned in 147.552 seconds
               Raw packets sent: 30651 (817.908KB) | Rcvd: 2 (402B)

És láss csodát: a bután bekonfolt tűzfalon a karácsonyfás vizsgálódás keresztüljut.

root@chihiro:/home/zsombor# nmap -v -A scanme.nmap.org

Starting Nmap 4.10 ( http://www.insecure.org/nmap/ ) at 2006-11-24 18:34 CET
DNS resolution of 1 IPs took 0.00s.
Initiating SYN Stealth Scan against scanme.nmap.org (205.217.153.62) [1679 ports] at 18:34
Discovered open port 53/tcp on 205.217.153.62
Discovered open port 80/tcp on 205.217.153.62
Discovered open port 22/tcp on 205.217.153.62
The SYN Stealth Scan took 36.93s to scan 1679 total ports.
Initiating service scan against 3 services on scanme.nmap.org (205.217.153.62) at 18:34
The service scan took 11.57s to scan 3 services on 1 host.
For OSScan assuming port 22 is open, 25 is closed, and neither are firewalled
Host scanme.nmap.org (205.217.153.62) appears to be up ... good.
Interesting ports on scanme.nmap.org (205.217.153.62):
Not shown: 1673 filtered ports
PORT    STATE  SERVICE VERSION
22/tcp  open   ssh     OpenSSH 4.3 (protocol 2.0)
25/tcp  closed smtp
53/tcp  open   domain
70/tcp  closed gopher
80/tcp  open   http    Apache httpd 2.2.2 ((Fedora))
113/tcp closed auth
Device type: general purpose|broadband router
Running: Linux 2.4.X|2.5.X|2.6.X, D-Link embedded
OS details: Linux 2.4.0 - 2.5.20, Linux 2.4.18 - 2.4.20, Linux 2.4.26, Linux 2.4.27 or D-Link DSL-500T (running linux 2.4),
Linux 2.4.7 - 2.6.11, Linux 2.6.0 - 2.6.11
TCP Sequence Prediction: Class=random positive increments
                         Difficulty=2907531 (Good luck!)
IPID Sequence Generation: All zeros

Nmap finished: 1 IP address (1 host up) scanned in 53.607 seconds
               Raw packets sent: 3376 (149.316KB) | Rcvd: 26 (1314B)

7 Nmap Scripting Engine

Az nmap scripting engine az 5.00-s nmap egyik legszimpatikusabb újítása. Nmap szkripteket írni nagyon egyszerűen lehet, az nmap.org-on számos tutorial és kész szkript várja az érdeklődőket. A leghíresebb használata a conflicker idején volt, amikor a 139/TCP digitális fingerprintjéből meg tudta mondani, hogy fertőzött-e az adott hoszt.

8 Mire jó az nmap?

A fenti kapcsolókkal szó szerint több ezer üzemmódban lehet használni a kicsi, parancssoros nmap-ot. Mire lehet használni? Csak néhány tipp:

  • Hálózatra betörve portok feltérképezése.
  • Tűzfalak szabályrendszerének kiderítése.
  • DoS (no comment...)
  • Tömeges reverse DNS-feloldás.
  • ARP táblák ellenőrzése lokális hálózaton.
  • Hálózatmonitorozás (á la Nagios).
  • Szolgáltatásmonitorozás.
  • Hálózati eszközök katalógusának automatizált összeállítása.
  • Hálózati eszközök terhelésvizsgálata (stress test).
  • Szolgáltatások terheléses vizsgálata (pl. Apache).
  • Stb.

9 Advanced portscan

A portscannelés sok esetben túlmutat az nmap-on. Az nmap zseniális eszköz, pilótavizsgás kezekben csodákra képes, de értő használatához szükséges az is, hogy ismerjünk alternatív lehetőségeket. Az órán mutatok néhány ilyen alternatív módot. Ilyen módok portscanre:

  • Proxychains
  • ToR
  • NQT + Webscarab
  • Google
    • Bannerek
    • Nessus scanek logjai
    • ...
  • SNMP
  • XSS sebezhetőségek kihasználása portscanre
  • Nyomtatók
  • Fordíts magadnak saját nmap-ot!
  • Időzítési kérdések, hatékonyítás
  • pornolize.com, youhide.com,...

Oprendszerdetektálás:

  • p0f
  • xprobe2
  • amap
  • netcraft.com
Személyes eszközök