A Nessus csodálatos eszköz. Az automatizált sebezhetőségi ellenőrző eszközök arzenáljában
de facto szabvánnyá vált az egykori teljesen ingyenes szoftver: a 3-as Nessus már nem nyílt forráskódú, viszont az eszköz sava-borsát jelentő pluginek otthoni használatra ingyenesen frissíthetőek, licencdíj csak az üzleti felhasználókra van - azaz ránk.
A Nessus alapfunkcionalitásában nagyon hasonlít az nmap-ra olyan szempontból, hogy ugyanúgy nyitott portokat képes azonosítani, azonban a tudásbázisban található pluginek segítségével a szolgáltatások fingerprintjén túl képes arra, hogy ismert sebezhetőségekre utaló szignatúrákra vadásszon a szolgáltatásokban - és még egyéb varázslatokra is képes.
Mielőtt kicsit bővebben beszélnénk a Nessus képességeiről, tisztázzunk elöljáróban egy nagyon fontos alapvetést:
a Nessusszal való automatizált point-and-click tesztelés önmagában nem tekinhtető betörési tesztnek. Sok esetben találkoztunk már azzal, hogy az ügyfélnek sok pénzért eladott "betörési teszt" átadott jegyzőkönyve gyakorlatilag szó szerinti fordítása volt a Nessus által generált sebezhetőségi jelentésnek - a sebezhetőségek igazolása, vagy kézi vizsgálatok nélkül. A Nessus (nem csak a Nessusra, hanem a Core Impactre, a Retinára, a Satanra, az összes ingyenes vagy fizetős automatizált szkennelőeszközre is igaz ez) nélkülözhetetlen a tesztelő számára, viszont önmagában értéktelen a használatuk: a kívánt eredményt csak úgy érheti el a teszt, ha a tesztelők igenis nekiülnek, és manuális módszerekkel is vizsgálják a célpontot.
Mire figyeljünk a Nessus használata során?
- Papírmunka. Lehetőleg legyen írásos hozzájárulásunk a megbízótól, amely hozzájárulásban a megbízó elismeri, hogy a tesztelés során a leggondosabb tervezés és legóvatosabb végrehajtás mellett is felléphetnek váratlan mellékhatásként nem kívánt események (a "nem kívánt események" mértékegysége egyrészt az idő, amíg az üzemeltetők talpra állíták a meghasalt infrastruktúrát, illetve byte, ami az elveszett adatokat méri). Jelen írásnak nem célja, hogy végigmenjünk az összes pluginen, az összes lehetőségen: kiemelünk néhány gyakori időzített bombát, amely beállítások helyes használatával jelentősen csökkenthető a "nem kívánt események" valószínűsége.
- Észre nem vett sebezhetőség vs. DoS. Valahányszor Nessusszal szkennelünk, döntést kell hoznunk: minél alaposabb a vizsgálat, annál pontosabb képet kapunk, viszont annál tovább tart, annál nagyobb hálózati forgalmat generál és annál nagyobb valószínűséggel okozunk kárt. A valószínűség nyilvánvalóan minimalizálható megfelelő vizsgálati beállításokkal, azonban soha nem nulla a károkozás valószínűsége.
- Egy scan nem scan. Valahányszor mérünk, egy mérés nem mérés- ugyanez igaz az automatizált sebezhetőségi vizsgálatokra is. A Nessusszal végzett vizsgálatokat minden esetben meg kell ismételni, valamilyen más hasonló eszközzel (az OpenVAS jó választás lehet, ha a költségkeret szűkös).
- A Nessus nem csodafegyver. Népszerű tévhit, hogy a Nessus mindent tud, azonban ez korántsincs így. Számos olyan részfeladat van, amelyre bár van plugin a Nessusban, sokkal inkább kifizetődő egy kimondottan az adott részfeladatot megvalósító céleszköz használata. Ilyen például a directory enumeration - a Nessusban van egy minimális szólista, amelyet végignéz, azonban sokkal inkább megfelel a célnak pl. a Wikto, vagy az OWASP DirBustere. Ugyanígy, ha kizárólag annyi a scan célja, hogy SNMP-t támogató eszközökről készítsünk listát, fölösleges beüzemelni a Nessust: jelen sorok írója egy 8 soros bash szkripttel és az snmpcheck-1.6.pl névre hallgató (BackTrack3-ban megtalálható) eszközzel oldotta meg a problémát.
- Célra tartás. Amikor megtervezzük a scant, tudatosan kell végiggondolni a vizsgálandó infrastruktúra sajátosságait. A Nessus portscannere például nem rossz, de a mezei nmap jobban testre szabható és egyszerűbben indítható - e sorok írója például a Nessus indítása előtt nmap-ot használ a célpont felderítésére.
Az nmap nagyon szószátyár módjában számtalan információt kapunk, amely segít a Nessus megfelelő beállításainak eltalálásában. Például nagy hálózat vizsgálatakor nagyon hasznos az, ha pl. hping3-mal megmérjük, hogy átlagosan mekkora a csomagvesztés a célpont felé a hálózaton és mekkora az rtt. Ennek ismeretében az nmap-ban megszabjuk, hogy hányszor küldje újra a csomagokat, illetve mekkora legyen a timeout - ezzel nagyon (NAGYON) sokat javíthatunk a sebességen.
Az nmap megmondja, hogy mely portok vannak nyitva - a Nessusos port scant ezekre a portokra korlátozva, a hoszt (nem) működésének megállapítását kikapcsolva nagyon sokat javíthatunk a vizsgálatok teljesítményén. - "Veszélyes" beállítások. A megfelelő beállítások a Nessus Policy menüjének testreszabását jelentik - a Nessus készítői jelentős egyszerűsítést csempésztek bele az eszközbe a "Safe Checks" pipa használatával: ha ezt bekattintjuk, jelentősen megnöveljük saját esélyeinket a zökkenőmentes vizsgálatok szempontjából.
Ez sem igaz teljesen: a Tenable összeállított a tapasztalatok alapján egy listát azokról az eszközökről, amelyek rosszul viselik a Nessus vizsgálódásait. Valahányszor a fingerprinting fázis során ilyen szolgáltatás, eszköz kerül horogra, a Nessus abbahagyja az irányában történő vizsgálódást a veszélyesnek ítélt pluginekkel. Másrészről, ez elég sok fals pozitív eredményt hozhat, ugyanis sok gyártó nem frissíti konzekvensen a szoftvereinek verziószámát a javítások ellenére sem, emiatt kizárólag a verziószámok alapján sokszor nem lehet egyértelműen megmondani a vizsgált szolgáltatás valódi verzióját. - "Consider Unscanned Ports as Closed": a Nessus, ha ez nincs beklattyintva, először megcsinálja a port scant, majd a kiválasztott plugineket szépen sorjában nekiküldi a célpontnak - akár vizsgálva volt az adott plugin által vizsgált port a szkópban és nyitott állapotúnak találtatott, akár nem is volt scannelve. Szükségtelen mondanunk, hogy ez mennyire zajos, és mennyire váratlan eseményekhez vezethet: a legtöbb esetben érdemes bekattintani - kivéve, ha pontosan a fenti viselkedés a célunk.
- LaBrea-hosztok. Sok IPS/tűzfal azzal nehezíti meg a tesztelő dolgát, hogy fokozatosan lassítva válaszol a kérésekre, ezáltal egy idő után eléri a TCP-s timeoutot (megjegyezzük, hogy spamszűrésként is ismert "tarpitting" néven a technika SMTP-szervereken) . Érdemes kikapcsolva tartani első közelítésben - ha érzékeli a Nessus, hogy egyre növekvő válaszidővel érkeznek csomagok a célponttól, honeypotként címkézi a végpontot és felhagy a tesztelésével. Ha pontos képünk van a célpontról, nem lehet szükség a használatára.
- Párhuzamosság. A Nessus policyjában van három érték, amellyel nagyon óvatosan kell bánni: ezek a "Number of hosts in parallel", a "Number of checks in parallel", illetve a "Port Scanner Range" névre hallgató mezők. A scan indítása előtt fontos tisztázni, hogy milyen kapacitású eszközök működnek a célponton - előfordulhat, hogy a sok egyidejű kérést rosszul viselő eszközök vizsgálatakor inkább 40 párhuzamos hosztot vizsgálunk hosztonként 5 párhuzamos kéréssel, mint 10 hosztot 20 párhuzamos kéréssel.
Ide tartozik még a Network taben található néhány beállítás. A "Reduce number of connections in parallel on congestion" pipa bekattintása után a Nessus, ha érzékeli, hogy a hálózati közeg kapacitásának közelében jár a forgalmazott adatmennyiség, akkor automatikusan visszavesz a tempóból. A TCP-s kapcsolatok párhuzamos számát egy hoszton akkor érdemes visszavenni, ha hálózati eszközt scannelünk (mondjuk switchet), ugyanis a menedzsment IP-címen többnyire telnet/SSH/SNMP/HTTP/HTTPS szolgáltatások futnak, amiket a switch CPU-ból szolgál ki, emiatt nem igazán viseli jól a sok párhuzamos TCP-kapcsolatot.
- "Legjobbjaink elhulltanak a hosszú harc alatt". A "Stop scanning hosts turned off during the audit" pipa bekattintása akkor hasznos, ha a vizsgálatok alatt egy-egy hosztot kikapcsoltak, illetve esetleg DoS miatt üzemképtelenné vált. Az ilyen végpontok nyilván nem fognak válaszolni, egy-két ilyen NAGYON lelassítja a scant és szükségtelen hálózati forgalomhoz vezet az újraküldések miatt.
Novell NetWare szerverek régi verziói hajlamosak elsegfaultolni a fingerprinting fázis során, emiatt a Nessus alapból nem vizsgálja ezeket a hosztokat, illetve a hálózati nyomtatók régi típusai a 9100/TCP-re küldött bármilyen adatot kérdés nélkül kinyomtatják, emiatt az nmap is és a nessus is elkerüli ezeket - az Advanced fülön lehet engedélyezni őket mégis.
- Időrabló vizsgálatok. Akárcsak az nmap használata során, itt is érdemes kikapcsolni a reverse DNS feloldást, ugyanis ez hosztonként 12 másodperces timeouttal dolgozik. A reverse DNS bejegyzések vizsgálatát amúgy is mindenképp meg kell tenni, de ehhez inkább használjuk az nmapot és némi linuxos varázslást (nmap -sL -PN 1.2.3.* | awk '/\(/{print $2,$3}'>reverse_dns.txt)
- Authentikációs beállítások. Ezek olyasmik, amiket egy black hat nem nagyon használ - ha ismerünk adminisztrációs felhasználóneveket és jelszavakat, a Nessus be tud jelentkezni a távoli hosztra, és pl. a registryben tud keresgélni sebezhetőségek után. Hálózati eszközök esetében az SNMP stringek ismerete szükséges.
Windowsos hosztok/hálózatok vizsgálatakor a távoli registry elérés csak nagyon advanced felhasználók számára elérhető (tipikusan Domain Adminok), emiatt célszerű létrehozni a teszt idejére egy ideiglenes accountot, amelynek joga van elérni a registryt távolról is. Kiváló whitepaper a kérdésről itt. - Pluginek kiválasztása. A plugineket egyesével lehet engedélyezni/tiltani, viszont fontos észben tartani, hogy a "consider unscanned ports as closed" pipa állapota alapvető jelentőséggel bír arra, hogy ténylegesen melyek futnak le. A DoS kategóriába tartozó pluginek használata során komoly kockázata van annak, hogy ténylegesen megakad valami - hiszen az ide tartozó pluginek ténylegesen triggerelik az adott DoS feltételt a szolgáltatásban, majd igazolják, hogy hanyattdőlt.
A fenti 13 pont nyilvánvalóan nem fedheti le a Nessus teljes képességtárát, az érdeklődők
ebből a könyvből teljes, kimerítő leírást kaphatnak.
