Portscan

A lap 2006. november 27., 17:26-kori változata

1 NMAP

Elsősorban portscannelésre használják, azonban a legújabb verzió (4.20) segítségével egy csomó egyéb dolgot is megtudhatunk a célgépről.

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 az nmap szerint:

• 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á. Használható egy arra pl, hogy megbizonyosodjunk, hogy a célgép be van-e kapcsolva egyátalán.

• 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.

Az nmap scantípusai

• 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. Ha lehet, inkább a SYN scant használjuk.

• sM, sF, sX, sN: Maimon, FIN, Xmas és NULL scan. Gyakorlatilag ugyanarra a logikára működnek: beállítunk egy bizonyos 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 és 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! (Bővebb infó: [1]) 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é.

• 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.

• 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!

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).

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.

Példa az nmap használatára

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)

"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 -T 1.2.3.4

és várunk. A szerző saját 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.

Children, DO NOT TRY THIS AT HOME!

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.

• --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.)

• S: IP-cím spoofolása. Bővebb magyarázatot nem igényel.

• --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ó).

• --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.

2 NESSUS

Az nmap mellett a másik igen elterjedt, hálózati sebezhetőségeket felderítő program. Népszerűségét jelzi, hogy a sectools.org toplistáján első helyezést ért el száz konyhakés-típusú eszköz közül (attól konyhakés-típusú, hogy gyilkolásra is alkalmas, noha nem arra szánták).

Népszerű, mivel van hozzá GUI, részfunkcióként tartalmazza a fent ismertetett NMAP-ot és még egy sereg egyéb szolgáltatás is tartozik hozzá (pl. mindenféle formátumokba tudja exportálni a vizsgálatok eredményeit, továbbá van hozzá update service és számtalan plugin.)

Architektúra

A nessus alapból linuxos kreálmány, de már van windows-os portolása is. A kettő nagyjából ugyanazt tudja, így most a linuxosra koncentrálunk. Ha pl. Ubuntun csomagból tesszük fel, a nessus és a nessusd csomagokra lesz szükségünk a használatához: a nessusd szerver végzi a tényleges portscannelést, a nessus csak egy grafikus kliens, amely csatlakozik a szerverhez. A szerver és a kliens közti kapcsolat titkosítható is - jelenleg az SSL-t támogatja.

A szerverhez lehet felhasználókat rendelni, a kliens egy használatához szerverre, júzernévre és jelszóra van szükség. Megadhatók policy-k is az egyes felhasználókhoz: milyen típusú támadást érhet el a felhasználó, mely hosztok szkennelése tiltott/engedélyezett stb.

Képességek

A nessus alapvető funkciója a portscan és az oprendszer kiderítése. Előbbihez gyakorlatilag az nmap-nál ismertetett módokon fog hozzá, az utóbbi meghatározásához az alábbi módokat használja (teljesen automatikusan alapból, de ki lehet klikkelni akármelyiket):

• Ha vindózra tippel és valahogy el tudja érni a registry-t, akkor egyszerűen kiolvassa a helyes választ onnét.
• SNMP: ha a célponton fut SNMP szolgáltatás, megkérdezi ilyen módon.
• szabálytalan ICMP-csomagokszekvenciákat küldve a célpontnak, a kapott válaszcsomagokból tippel.
• Megpróbál MSRPC csomagokat küldeni a 139-es és 445-ös portokra és a válaszok alapján tippel.
• Ha a célponton fut NTP szolgáltatás, ezt is ki tudja használni.

A szerver alapvetően pluginokat futtat - bárki írhat sajátot, de alapból is feltesz majdnem 1000(!) ilyet, úgyhogy a választék igazán bőséges. A nessus a GUI-n kívül (bár nem hinném, hogy a sokat tapasztalt, veterán 80x25-ös konzolkalózok izgalmi állapotba jönnének emiatt) itt nyújt jóval többet, mint a mezei nmap. Lássunk néhány plugint:

• féregkeresés (Plugins/Backdoors/). Bizonyos férgek nyitva hagynak portokat és jellegzetes módon reagálnak az oda küldött csomagokra, ezeket detektálja a Nessus.

• tűzfalak megfelelőségi vizsgálata (Plugins/Firewalls). Képes arra, hogy az alkalmazott tűzfal típusát felismerje bizonyos esetekben és ezek alapján megnézi, hogy az adatbázisban ismert-e valamilyen tűzfalspecifikus támadástípus.

• szolgáltatások vizsgálata. Már a mezei nmap is meg tudja mondani, hogy milyen verziójú apache fut a szerveren, a nessus viszont a már sokszor emlegetett adatbázisából megnézi, hogy milyen támadások ismertek az adott verzióra és pl. javasolja, hogy a HTTP1.1-es buffer overrun lehetőségét patcheljük ki.

• P2P alkalmazások vizsgálata. A P2P alkalmazások súlyos sec. hole-okat jelenthetnek egy rendszerben, ugyanis egy tipikus P2P alkalmazás a Knoppix image-ek letöltése közben számtalan kimenő és bejövő kapcsolatot kezel, amiken váratlan betolakodók is jöhetnek, ha a szoftver nem megfelelően van megírva. Másrészt pedig bizonyos környezetben már az ilyen alkalmazások puszta használata is tiltott lehet (pl. egy vállalatnál vagy egy gimnázium géptermében), a Nessus pedig az ilyen szoftverek ellen vívott küzdelem lángoló kardja is lehet.

• Windows. A Nessus adatbázisába belekerülnek a Microsoft Bulletinjei, így adott esetben segítséget nyújthat a hálózaton működő, nem kellően update-elt Xp-k megtalálásához. Megmondja például azt, hogy fut-e a crackerek körében roppantul kedvelt pcAnywhere a gépen - hogy aztán ezzel az információval ki mihez kezd, az már egyéni személyes ízlésére van bízva.

Használat

Kapcsolódva a szerverhez egy sereg lehetőségünk van arra, hogy a célpont sebezhetőségeit felderítsük: tudja az nmap támadástípusait (lásd feljebb), azonkívül egy csomó egyéb opciót is, ezeket mind nem fogjuk felsorolni; mindenki próbálgassa őket saját maga.

Ha ráuszítjuk egy hosztra, végigszkenneli a portjait, aztán beállítástól függően egyéb teszteket is elvégez. Ezek eredményeképp egy grafikus összesítést kapunk a célponton talált sebezhetőségekről és azok kijavításának módjairól. A plugineket egyébként ki-be lehet kapcsolgatni attól függően, hogy mire vagyunk kíváncsiak - pl. egy hipotetikus cracker a vállalat gépeit végigszkennelve első körben leginkább a futó szolgáltatások után kutat és minél inkább szeretne rejtve maradni, így kikapcsolhatja azokat a pluginokat, amelyek nagy forgalmat generálnak.

A Prefs fülön tudjuk állítgatni a scan paramétereit. Legnagyobbrészt az nmap-nál már ismertetett lehetőségek köszönnek vissza, lsd. feljebb. Ha befejeződött mind a portscan, mind a pluginok által történő tapogatózás, ízléses, grafikus összesítést kapunk, valahogy így: