NEUMANN JÁNOS INFORMATIKAI KAR SZAKDOLGOZAT VÁRFALVI TAMÁS MILÁN NIK-O-NI OE-NIK 2010

Átírás

1 NEUMANN JÁNOS INFORMATIKAI KAR SZAKDOLGOZAT OE-NIK 2010 VÁRFALVI TAMÁS MILÁN NIK-O-NI

2 Óbudai Egyetem Neumann János Informatikai Kar Informatikai Rendszerek Intézet SZAKDOLGOZAT FELADATLAP Hallgató neve: Törzskönyvi száma: Várfalvi Tamás Milán NIK-O-NI A dolgozat címe: Sérülékenységvizsgálat a gyakorlatban Ethical hacking in practice Intézményi konzulens: Külső konzulens: Dr. Broczkó Péter Beadási határidő: május 21. A záróvizsga tárgyai: Architektúrák Informatikai rendszermérnök

3 A feladat Ismertesse a számítógépes hálózatokat fenyegető támadásokat, különös tekintettel az aktuálisokra. Alakítson ki egy olyan követelményrendszert, mely bemutat egy webszerverre irányuló sérülékenységvizsgálati szolgáltatást és annak folyamatát. Mutasson be és valósítson meg egy olyan éles támadás-sorozatot, mely rámutat egy valós rendszer sérülékenységeire. Úgy dokumentálja le a támadásokat, hogy azokat utána reprodukálni lehessen. Értékelje a kapott eredményeket és mutasson rá a továbbfejlesztési lehetőségekre. A dolgozatnak tartalmaznia kell: számítógépes hálózatokat fenyegető, jellemző támadásokat, a tesztelendő webszerver és annak környezete ismertetését, a tesztelendő webszerverre irányuló sérülékenységvizsgálati szolgáltatás bemutatását, a sebezhetőségre irányuló vizsgálatok megtervezését, a vizsgálatok reprodukálási célú dokumentálását, a kapott eredmények értékelését, a továbbfejlesztési lehetőségeket, kitérve a felhasználó számára adott biztonsági javaslatokra, a szükséges dokumentumokat (nyilatkozat, megbízás, szerződés) és a kapott eredmények listáit csatolja mellékletben. Ph. A szakdolgozat elévülésének határideje: május 21. (BMF TVSz pont szerint).... Dr. Szeidl László intézetigazgató A dolgozatot beadásra alkalmasnak tartom:... intézményi konzulens

4 HALLGATÓI NYILATKOZAT Alulírott záróvizsgázó hallgató kijelentem, hogy a szakdolgozat saját munkám eredménye. A felhasznált szakirodalmat és eszközöket azonosíthatóan közöltem. Egyéb jelentősebb segítséget nem vettem igénybe. Az elkészült szakdolgozatban talált eredményeket az egyetem, a feladatot kiíró intézmény saját céljaira térítés nélkül felhasználhatja. Budapest, május hallgató aláírása

5 Konzultációs Napló helye

6 TARTALOMJEGYZÉK 1. TARTALOMJEGYZÉK ÁBRAJEGYZÉK IRODALOMKUTATÁS Bevezetés Az OSI referenciamodell és a TCP/IP protokollstruktúra Eszközök Szabad szoftverek (Open source) Fizetős szoftverek Támadások osztályozásának lehetőségei Komplexitás Főbb módszerek Cél A kivédés lehetőségei GYAKORLATI PÉLDA A feladat bemutatása A szolgáltatás bemutatása a gyakorlatban A vizsgált hálózat bemutatása Mérések előkészítése Első mérés Második mérés Harmadik mérés Negyedik mérés Kiértékelés A sérülékenységek kijavítása és a megismételt mérés bemutatása Továbbfejlesztési lehetőségek ÖSSZEFOGLALÁS ABSTRACT IRODALOMJEGYZÉK MELLÉKLETEK... 53

7 ÁBRAJEGYZÉK 1. ÁBRA: AZ OSI MODELL ÉS A TCP/IP PROTOKOLLSTRUKTÚRA KAPCSOLATA [1] ÁBRA: A BACKTRACK LINUX DISZTRIBÚCIÓ[4] ÁBRA: A TENABLE SÉRÜLÉKENYSÉGVIZSGÁLÓ ESZKÖZE: A NESSUS[5] ÁBRA: A SEGÉDPROGRAMOK KOMPLEXITÁSA ÉS AZ AZOKHOZ SZÜKSÉGES TUDÁS VÁLTOZÁSA ÁBRA: A WIRESHARK HASZNÁLAT KÖZBEN[9] ÁBRA: PORT SCANNING: AZ NMAP HASZNÁLAT KÖZBEN[11] ÁBRA: TRUST EXPLOITATION TÁMADÁS ÁBRA: MAN-IN-THE-MIDDLE TÁMADÁS ÁBRA: DOS TÁMADÁS I.[13] ÁBRA: DOS TÁMADÁS II.[13] ÁBRA: DDOS TÁMADÁS ÁBRA: A QUALYSGUARD FELHASZNÁLÓI FELÜLETE ÁBRA: A VIZSGÁLT HÁLÓZAT LOGIKAI TOPOLÓGIÁJA ÁBRA: A MÉRÉSEK TULAJDONSÁGAI ÁBRA: OPTION PROFILE ÁBRA: OPTION PROFILE - HALADÓ BEÁLLÍTÁS: SCAN ÁBRA: OPTION PROFILE - HALADÓ BEÁLLÍTÁS: MAP ÁBRA: OPTION PROFILE - HALADÓ BEÁLLÍTÁS: ADDITIONAL ÁBRA: ELSŐ MÉRÉS BEÁLLÍTÁSA ÁBRA: ELSŐ MÉRÉS FUTÁS KÖZBEN ÁBRA: ELSŐ MÉRÉS ÖSSZEGZÉSE ÁBRA: MÁSODIK MÉRÉS BEÁLLÍTÁSA ÁBRA: MÁSODIK MÉRÉS FUTÁS KÖZBEN ÁBRA: MÁSODIK MÉRÉS ÖSSZEGZÉSE ÁBRA: HARMADIK MÉRÉS BEÁLLÍTÁSA ÁBRA: HARMADIK MÉRÉS FUTÁS KÖZBEN ÁBRA: HARMADIK MÉRÉS ÖSSZEGZÉSE ÁBRA: NEGYEDIK MÉRÉS BEÁLLÍTÁSA ÁBRA: NEGYEDIK MÉRÉS FUTÁS KÖZBEN ÁBRA: NEGYEDIK MÉRÉS ÖSSZEGZÉSE ÁBRA: A CROSS-SITE SCRIPTING SÉRÜLÉKENYSÉG BEMUTATÁSA ÁBRA: AZ ELSŐ MÉRÉS RÉSZLETES EREDMÉNYE (RÉSZLET) ÁBRA: AZ UTOLSÓ MÉRÉS RÉSZLETES EREDMÉNYE (RÉSZLET) ÁBRA: ÜTEMEZETT MÉRÉS BEÁLLÍTÁSA...48

8 IRODALOMKUTATÁS 3.1. Bevezetés Napjainkban elképzelhetetlenné vált egy cég működtetése informatikai eszközök használata nélkül; elég, ha csak a munkaállomásokra vagy az azokat kiszolgáló szerverekre gondolunk. Bár a vállalatok fejlődése magával vonja az eszközpark fejlesztését is, ez biztonságtechnikai értelemben általában nem követi a kívánt fejlődési ütemet, és ami még tovább rontja a helyzetet, ez ki sem derül addig, amíg egy, a céget kompromittálni kívánó személy ki nem használja annak hiányosságait. Ez jelenthet információhoz való illetéktelen hozzáférést (kémkedés), szolgáltatás megbénítását, anyagi haszonhoz jutást, stb. Minden szoftverben, és egyben minden frissítésben is megtalálhatóak biztonsági rések, amelyeket kellő mennyiségű háttérismerettel, tapasztalattal és türelemmel ki lehet használni, ezért belátható, hogy feltörhetetlen rendszer nem létezik. A kockázat egyenesen arányos a kár értékével és az esemény bekövetkezésének a valószínűségével. Mivel a védeni kívánt eszközök és információ értéke adott, a bekövetkezés valószínűségét kell csökkenteni minimálisra. Ehhez naprakész biztonsági eszközökre és azok rendszeres frissítésére van szükség, továbbá ismerni kell azokat a technikákat, amelyeket a támadók felhasználhatnak a sikeres behatolás folyamatában. Mivel a cégek adminisztrátorai általában elfogultak az általuk fenntartott rendszerrel kapcsolatban, előfordulhat, hogy abban egy létfontosságú sérülékenységet nem vesznek észre. Az elmúlt években egyre több olyan informatikai tanácsadó cég jelent meg a piacon, amely titoktartási nyilatkozat betartása mellett vállalja, hogy független szakértői segítségével teszteli le a megbízó fél informatikai eszközeinek a sebezhetőségét, továbbá az eredményeket dokumentálja, és azt átadja az adott vállalatnak. Ezt a folyamatot hívják Ethical hackingnek. Szakdolgozatomat abból a célból készítettem, hogy bemutassam a sérülékenységvizsgálat jelentőségét, a támadási formák többségét, továbbá bemutassam az Ethical hackinget, mint szolgáltatást, egy információbiztonsági tanácsadó cég szemszögéből.

9 Az OSI referenciamodell és a TCP/IP protokollstruktúra A hálózati kommunikáció alapjául az ISO (International Organization for Standardization, magyarul Nemzetközi Szabványügyi Szervezet) egy referenciamodellt hozott létre, amelyet az 1970-es évek végéig szabványként javasolt.[1] A gyakorlatban a modell ilyen tisztán ritkán volt megtalálható, a legelterjedtebb gyakorlati megvalósítása a TCP/IP protokollstruktúrában valósult meg. Mindkét modellre jellemző, hogy a rétegek tisztán megfogalmazott, egyedi feladatokat látnak el, és ezek kizárólag az alattuk vagy a felettük álló réteggel képesek kommunikálni. Az 1. ábrán bemutatom a két modell közötti összefüggést azok rétegeinek szempontjából. A végpontokon a rétegek közöt virtuális kapcsolat épül ki. OSI modell TCP/IP modell Alkalmazási réteg Megjelenítési réteg Együttműködési réteg Szállítási réteg Hálózati réteg Adatkapcsolati réteg Alkalmazási réteg Szállítási réteg Hálózati réteg Adatkapcsolati réteg Fizikai réteg 1. ÁBRA: AZ OSI MODELL ÉS A TCP/IP PROTOKOLLSTRUKTÚRA KAPCSOLATA [1] A hálózati kommunikáció során a csomagokat megvizsgálva azt tapasztaljuk, hogy azok egymásba ágyazott szerkezetetet mutatnak. Ezt mutatja be egyszerűsítve az alábbi ábra:

10 - 5 - Az OSI referenciamodell rétegeinek rövid leírása (alulról felfelé haladva): 1. Fizikai réteg: Minden olyan feladatkör ide tartozik, amely elősegíti az adatáramlás fizikai megvalósítását, például: kábelek és csatlakozók kialakítása, jelérzékelés, analógdigitális jelátalakítás. A rétegre jellemző de facto szabvány az Ethernet, amelynek az adatkapcsolati réteggel is együtt kell működnie. A réteghez társítható hálózati eszközök: ismétlő (repeater), hub. 2. Adatkapcsolati réteg: A réteg feladata, hogy két hálózati eszköz között a szabványoknak megfelelő hálózati kereteket (frame) lehessen továbbítani, továbbá megvalósuljon a fizikai rétegben keletkezett hibák javítása. Az eszközök fizikai címzését jellemzően MAC címmel valósítják meg. A réteghez társítható hálózati eszközök: híd (bridge), switch (kapcsoló). 3. Hálózati réteg: Ez a réteg a hálózatok közötti forgalom közlekedését biztosítja. Feladata továbbá, hogy az alternatív útvonalak közül az eszközökben rendelkezésre álló információk alapján adott algoritmusokkal kiszámolják az optimális útvonalat. A réteg része a TCP/IP modellben megtalálható ICMP protokoll is, amely a hálózati problémákat hivatott detektálni és jelezni. A réteghez tartozó hálózati eszköz a forgalomirányító (router). 4. Szállítási réteg: A réteg feladata, hogy a hálózati adatforgalom a két fél között konzisztens maradjon. Két fő protokollt tartalmaz, a TCP t (Transmission Control Protocol) és az UDP (User Datagram Protocol). A TCP protokoll olyan adatforgalom használata esetén szükséges, amely nem engedheti meg sem csomagok elvesztését, sem azok sorrendjeinek felcserélődését, ezek megoldására hibajavító eljárásokat tartalmaz. UDP csomagok esetében megengedhető a csomagok bizonyos mértékű hiánya, ha a sebesség az elsődleges szempont (a TCP protokoll a hibajavítás miatt jóval lassabb). Az UDP csomagokat jellemzően internetes médiaszolgáltatásoknál (rádió, televízió, stb.), valamint hálózaton futtatható játékszoftverek használata alkalmazzák.

11 Együttműködési réteg: A réteg legfontosabb feladata az, hogy a szállítási rétegben kialakított kapcsolatot fenntartsa. Ehhez úgynevezett sessiont alakít ki (ezért is nevezik Session layer nek ezt a réteget). A TCP protokoll a háromutas kézfogás módszert használja fel ehhez. 6. Megjelenítési réteg: Ahhoz, hogy a címzett rendszerén az adott csomagban található adat a számára megfelelő formába kerülhessen, a megjelenítési réteg szolgáltatását kell igénybevenni. Itt történhet meg legkorábban egy adott szöveges állomány karakterkészletének konvertálása, titkosítás és fejtés, tömörítés és visszaállítás. A Little Endian Big Endian tárolási módok közötti átalakítás is itt történhet meg. 7. Alkalmazási réteg: A felhasználóval közvetlenül kapcsolatban lévő réteg. Az alkalmazási rétegből érkező igényeket az alatta lévők képesek feldolgozni. Erre a rétegre jellemző protokollok például: FTP, Telnet, HTTP, SMTP, NTP. Az adatok feldolgozásának sorrendjét és átvitelét az alábbi ábra szemlélteti: Alkalmazási réteg Alkalmazási réteg Megjelenítési réteg Megjelenítési réteg Együttműködési réteg Szállítási réteg Együttműködési réteg Szállítási réteg Hálózati réteg Hálózati réteg Adatkapcsolati réteg Fizikai réteg Adatkapcsolati réteg Fizikai réteg Host 1 Host 2 A támadások végrehajtásához túlnyomórészt a hálózati rétegben megtalálható ICMP, és az együttműködési rétegben lévő TCP protokollokat használják fel.

12 Eszközök A sérülékenységvizsgálathoz használt szoftvereket többféleképpen lehet csoportosítani, például tudásuk, kezelhetőségük vagy hozzáférhetőségük alapján, a dolgozatban ez utóbbit választottam Szabad szoftverek (Open source) A szabad (vagy nyílt forráskódú) szoftverek általános jellemzője az, hogy bizonyos feltételeket betartva, bárki számára hozzáférhető és módosítható annak forráskódja. Éppen ebből fakad a legnagyobb előnye ennek az újszerű felfogásmódnak, miszerint lelkes szakértők ezrei dolgozhatnak együtt például a legfrissebben felfedezett biztonsági rések befoltozásán, és a felhasználóknak semmilyen költségbe nem kerül az ilyen módon elkészített illetve továbbfejlesztett szoftverek használata. A dolgozat témájába vágó operációs rendszert, a BackTrack linux disztribúciót[4] éppen a behatolástesztelésre fejlesztették ki rengeteg elemzőszoftverrel ellátva, mint például a Nmap portscanner alkalmazás, amelyről később még szót fogok ejteni. 2. ÁBRA: A BACKTRACK LINUX DISZTRIBÚCIÓ[4]

13 Fizetős szoftverek A fizetős szoftvereknek a szabad szoftverekkel szembeni legnagyobb előnyük az, hogy a fejlesztő cég folyamatos támogatást (support) nyújt a felhasználók számára, valamint egyéb szolgáltatásokat is nyújthatnak. Az sem ritka, hogy bizonyos mértékű garanciát vállalnak a termékük működésére. Bár a szabad szoftverek felhasználhatóak üzleti célokra is, egy vállalkozásnak szüksége lehet támogatásra, így a vezetőségnek kell döntenie arról, hogy megéri-e azok használata, vagy sem. Fizetős sérülékenységvizsgáló alkalmazás például a Nessus.[5] 3. ÁBRA: A TENABLE SÉRÜLÉKENYSÉGVIZSGÁLÓ ESZKÖZE: A NESSUS[5] Természetesen a fizetős szolgáltatásoknak léteznek próbaváltozatai, amelyek vagy időkorlátosak, vagy a hozzáférhető funkciókat csökkentik le. Az általam kipróbált szolgáltatást a Qualys vállalat nyújtja QualyGuard[6] néven, ehhez 30 napos hozzáférést kaptam, amelyet a Proyet Kft. műszaki igazgatója biztosított a számomra. Ezzel a felhasználói fiókkal az összes funkció kipróbálására jogosult lettem. Létezik ugyanakkor olyan lehetőség is, amely segítségével ingyenesen vehetjük igénybe a szolgáltatást, de például a kimutatásokat csak PDF formátumban kaphatjuk kézbe. Ennek kipróbálásához a Qualys internetes portálján kell regisztrálni.

14 Támadások osztályozásának lehetőségei A támadásokat sokféle képpen lehet csoportosítani, én ezek közül három módszert mutatok be. Először azt vizsgálom meg, hogy mennyi háttérismeretet és előkészítést igényelnek a támadások, majd a főbb módszerek alapján osztályozom őket, végül a lehetséges támadási okokat mutatom be Komplexitás Struktúrált Az 1980-as években még sokkal nehezebb dolguk volt a szakembereknek, ha kompromittálni akartak egy célpontot. Szükségük volt a technológiák, protokollok alapos ismeretére, idegen nyelvű irodalmakra és rengeteg türelemre. A segédszoftverek akkoriban még kezdetlegesek voltak, a szaktudásra nehezebb volt szert tenni. Nem-struktúrált Napjaink támadásaira jellemző. Rengeteg segédprogram (toolkit) található meg az interneten használati utasítással együtt, továbbá fórumok és cikkek, amik a témában való elmélyülést segítik. Ha valaki támadást akar indítani, azt akár néhány kattintással is megteheti, nem igényel alapos tervezést sem. Belátható, hogy a toolkitek komplexitása és a támadásokhoz szükséges előismeretek nagysága fordítottan arányos. 4. ÁBRA: A SEGÉDPROGRAMOK KOMPLEXITÁSA ÉS AZ AZOKHOZ SZÜKSÉGES TUDÁS VÁLTOZÁSA

15 Főbb módszerek Buffer overflow Buffer túlcsordulásról akkor beszélünk, amikor egy eszköz memóriájába nagyobb mennyiségű adatot helyezünk el, mint amennyit kezelni tudna, ennek eredménye képpen adatokat vagy futtatható parancsokat tudunk eltárolni benne. [7] A módszerrel eszköz- és alkalmazásfüggő eredményeket lehet elérni, például jogosultságellenőrzés szüneteltetése, szolgáltatásmegtagadás, távoli parancsvégrehajtás. Védekezés ellene: alkalmazás védelmének fejlesztésével, protokollverzió frissítéssel. Brute force Autentikáláshoz használják, ez az úgynevezett nyers erő támadási módszer. [8] Az adott karakter-intervallumon belül az összes lehetséges kombinációt kipróbáljuk a jelszó megszerzéséhez. A módszer előnye az, hogy előbb-utóbb biztosan megkapjuk az eredményt, a hátránya pedig, hogy ha rövid idő alatt akarunk célt elérni, óriási teljesítménnyel kell rendelkezzünk (nagy számítási kapacitású PC vel, vagy botnettel) A védekezés ellene: adott időtartamon belüli próbálkozások maximális számát be kell állítani (például egy IP címről 10 másodperc alatt csak 3x lehessen próbálkozni). Szótáras jelszótörés Szintén egy jelszó megfejtésében segít. Kellően gyenge jelszavak esetén megesik, hogy értelmes kifejezéseket és/vagy számokat tartalmaznak, például neveket, évszámokat, egymás után következő számokat. (például: alma123, password1986, stb). Ezeket a sűrűn előforduló kifejezéseket úgynevezett szivárványszótárak alapján végig lehet próbálni. Előny: nagy valószínűséggel meg lehet szerezni a könnyű megjegyezhetőség miatt használt - gyenge jelszavakat. Hátrány: erős jelszavak (például: P@5Sw0rD) megfejtésében nem segít. Védekezés a módszer ellen: erős jelszavak használatával sikeres lehet a védekezés. Social Engineering Emberi hiszékenységből vagy gondatlanságból származó, illegálisan megszerzett információk megszerzése (például jelszavak) és felhasználása. Azt is ebbe a kategóriába soroljuk, ha a támadó fél a nem publikus munkafolyamatok sorrendjéhez fér hozzá (ki, mit, mikor, mivel csinál).

16 Cél Talán szokatlan, de ésszerű csoportosítás lehet az is, hogy a támadó az eszközeit és módszereit milyen célból veti be: felderítés, illetéktelen jogosultságszerzés vagy a szolgáltatás megbénítása érdekében. Felderítés Csomagfigyelő és analizáló programok (Packet sniffers) ICMP scannelés (Ping sweep) Port scannelés Internetes információs adatbázisok (Internet information queries) Csomagfigyelő és analizáló programok (Packet sniffers) Főleg hálózati forgalommal kapcsolatos anomáliáknál szokták felhasználni a sniffer szoftvereket (gyanús adatforgalom, sikertelen csatlakozási kísérletek, stb), illetve oktatásban.[3] Olykor viszont a protokollok gyengeségeiből fakadóan értékes információkhoz is juthatnak a támadók, mint például egy Telnet -es bejelentkezés esetén, ahol a felhasználónév és a jelszó titkosítatlan csatornán halad át, és a csomagok megfigyelésével könnyen meg is szerezhető. Ilyen szoftver például a Wireshark.[9] 5. ÁBRA: A WIRESHARK HASZNÁLAT KÖZBEN[9]

17 ICMP scannelés (Ping sweep) Napjainkban nem túlságosan megbízható technika, ugyanis a jelenlegi hálózati eszközök gyári beállításokkal is védekeznek már ellene. Lényege, hogy a támadó ICMP echo kérésekkel árasztja el az adott hálózati címtartományt, és ahonnan ICMP echo reply jön, azok aktív, működő hostok. Így felderíthető, hogy milyen eszközök találhatóak meg egy lokális hálózaton belül. Az fping program ebben nyújthat segítséget.[10] Port scannelés Léteznek olyan alkalmazások, amelyek felhasználásával kideríthető, hogy a célpontként megjelölt eszközön mely TCP illetve UDP portok vannak nyitva, továbbá azok mögött milyen alkalmazások figyelnek. Ezekből az adatokból, illetve az operációs rendszer típusából jó kiindulási ponthoz juthatnak a támadók, ugyanis a megszerzett információk alapján elkezdhetik felkutatni azon sérülékenységet kihasználó programokat (exploit), amelyeket kifejezetten ezekhez az alkalmazásokhoz és verziókhoz írtak. Ilyen port scanner program például az Nmap.[11] 6. ÁBRA: PORT SCANNING: AZ NMAP HASZNÁLAT KÖZBEN[11]

18 Internetes információs adatbázisok Utoljára hagytam azokat az interneten található adatbázisokat, amik közvetlen segítséget általában nem nyújtanak a támadáshoz, ugyanakkor a kompetens támadók hasznos információkat nyerhetnek ki belőlük. Az egyik ilyen szolgáltatás a WHOIS [16], amellyel például a megadott domainről nyerhető ki minden publikus információ az ahhoz tartozó DNS rekordból (tulajdonos, szolgáltató, stb.). Hozzáférési támadás A hozzáférési támadások közös jellemzője az, hogy a támadó valamilyen módon el akarja nyerni a célpontnak jelölt eszköz bizalmát, és a jogosultságok megszerzése után adatokat akar megszerezni vagy manipulálni, illetve befolyásolni kívánja a rendszer működését. Ehhez mindenképpen szükséges az azonosítás (autentikáció) és a jogosultságok megszerzése (autorizáció); ez utóbbit az azonosítás után a rendszer biztosítja a támadó számára. Fontos továbbá, hogy a támadó fél számára nem is a jelszó az igazán fontos, hanem az abból számított úgynevezett hash érték, amit a jelszó alapján egyértelműen ki lehet számolni. Az a folyamat, mely során a hash előáll, egyirányú (a hash birtokában nem lehet visszaállítani a jelszót), ugyanakkor - mivel ez egy szűkebb halmazra való leképzést jelent - kulcsütközés léphet fel, tehát több jelszónak is lehet ugyanaz a hash értéke. Ebből fakadóan - elméletileg - elég, ha a támadó fél talál egy ugyanolyan karakterláncot, aminek a függvény ugyazt a hash kódot adja eredményül, és megszerzi a jogosultságot, de az adott hash érték megtalálására még így is kicsi az esély. Ennél vannak egyszerűbb módszerek is az illetéktelen hozzáférés megszerzésére, mégpedig a következők: Nyers erő módszer (Brute force) Trójai programok IP cím hamisítás (IP Spoofing) Csomagfigyelő és analizáló programok (Packet sniffers) Bizalom elnyerése köztes eszköz segítségével (Trust exploitation) Középső ember támadás (Man-in-the-middle)

19 Nyers erő módszer (Brute force) A korábbi fejezetben már volt szó róla, egy olyan támadási forma, ami a megadott karatker-intervallumokon belül (a..z, A..Z, 0..9, speciális karakterek) az összes lehetséges lehetőséget kipróbálja. Hatalmas számítási kapacitás szükséges ahhoz, ha belátható időn belül eredményt szeretnénk elérni. A számítási idő exponenciálisan nő a megszerezni kívánt karakterlánc hosszával. Sikeres jelszótörési módszer lehet, amennyiben a célponton nincsen beállítva olyan érték, amelyet nem érhetnek el sikertelen autentikációs kisérlettel adott idő alatt. Trójai programok Főként ben terjedő trójai programok[12] lefuttatása esetén a támadó félnek esélye van átvenni a célpont feletti irányítást, rendszergazdai jogosultságokat megszerezni. Innentől fogva adminisztrátori jogkörrel cselekedhet az adott eszközön, adatokhoz férhet hozzá, sőt, a többi felhasználó adatait (jelszavakat, állományokat) is megszerezheti. Ez a veszély nem fenyegeti a legtöbb céget általában, hiszen annak dolgozói (és főleg az eszközök adminisztrátorai) folyamatos továbbképzésben vesznek részt, aminek köszönhetően elkerülhető a gyanús alkalmazások futtatása és terjesztése. A trójai programok segítségével továbbá botnetek alakíthatók ki, olyan hálózatok, amelyek a támadó fél akarata szerint akár DDoS[13] támadást is végrehajthatnak tetszőleges célpontok ellen. A probléma megelőzhető víruskereső szoftverek rendszeres használatával és frissítésével. IP cím hamisítás (IP Spoofing) Kellően gyenge védelemmel rendelkező eszközök esetén elképzelhető, hogy a támadó már azzal is megoldhatja az autentikációt és autorizációt, hogy meghamisítja a saját IP címét, mégpedig olyanná, amelyet a rendszer megbízhatónak tart. Természetesen ezt az információt előzőleg meg kellett szereznie a támadónak. Napjainkban önmagában ez a technika már nem elég egy sikeres támadás végrehajtásához, a legtöbb hálózaton ennél komplexebb autentikációra van szükség.

20 Bizalom elnyerése köztes eszköz segítségével (Trust exploitation) Az igen jól védett eszköz támadása helyett olyan eszközre hatol be a támadó, amelyben az eredetileg kiszemelt célpont megbízik, ezáltal könnyebben használhatja ki annak sérülékenyégeit. Ilyen eszköz lehet például egy DHCP szerver, alacsony védettséggel. X 7. ÁBRA: TRUST EXPLOITATION TÁMADÁS Középső ember támadás (Man-in-the-middle) A módszer lényege, hogy a támadó úgy avatkozik bele egy kommunikációba, hogy mindkét féllel elhiteti, hogy a partnerének küldenek üzeneteket, valamint a kapott csomagok is tőlük származnak. Ehhez a támadó meghamisítja azon csomagok forrását, amelyeket ő bocsát ki, és elkapja azokat, amiket az eredeti címzettnek küldtek. 8. ÁBRA: MAN-IN-THE-MIDDLE TÁMADÁS

21 Szolgáltatás megtagadásos támadás (DoS) A támadott fél (eszköz, hálózat, cég) kompromittálásának egyik leghatásosabb formája a szolgáltatásainak megbénítása. A szolgáltatás leállásából fakadóan közvetett és közvetlen anyagi és egyéb kárt is okozhat a támadás: Közvetett módon: a felhasználók a számukra garantált elérhetőség (availability) hiányából fakadóan az SLA ra (Service Level Agreement, Szolgáltatási Szint Megállapodás[14]) hivatkozva kártérítési igénnyel és a szolgáltatás lemondásával élhetnek, az adott vállalat hírneve is csorbulhat (ez szintén fontos része a kompromittálásnak) Közvetlen módon: az aktuális üzleti folyamatok félbeszakadnak, a vészhelyzet megoldására erőforrást (munkaerőt, időt, pénzt, eszközöket) kell fordítani. A szolgáltatás megtagadásos támadások (Denial of Service, DoS) osztályozása a csomagok számán és eredetén alapul. Ezek a következők: 1. Egy helyről egy csomag: A támadásban a támadó fél csak egy eszközt használ, és a célponton található sérülékenységek pontos ismerete alapján a szükséges eszköz segítségével képes olyan csomagot küldeni a webszerver számára, amely leblokkolhatja annak működését. Példa: Ping of Death: a támadó olyan csomagot küld a szervernek, aminek mérete nagyobb, mint amit az kezelni tud. A csomag a hálózaton több IP csomagra van felbontva, ennek szabványos méretét azok nem lépik át. A probléma a csomagok összeillesztésénél merül fel, ami a támadott fél eszközén történik. Az összeállított csomag méretéből adódóan puffer túlcsordulás történik, amitől megbénulhat az eszköz. 9. ÁBRA: DOS TÁMADÁS I.[13]

22 Egy helyről sok csomag Ez a támadási forma tekinthető az általános értelemben vett DoS támadásnak. A támadó fél a korábban tárgyalt módszerrel ellentétben a támadást a csomag minőségi jellemzője helyett azok mennyiségére alapozza. A sérülékenység ebben az esetben is a célpont memóriájának végességéből fakad, ugyanis ha egy eszköz adott idő alatt kevesebb adatot (esetünkben csomagot, kérést) képes kezelni, mint amennyit kap, véges időn belül (megfelelő védelmi intézkedések hiányában) működésképtelenné válik. Példa: TCP SYN flood: A támadás alapja a háromutas kézfogás módszerének ismerete. A támadó fél a célpont számára hamis forráscímmel rendelkező TCP SYN csomagokat küld, amire az TCP SYN+ACK csomaggal válaszol, de amíg erre nem kap olyan választ, amivel a TCP csatornát kialakíthatná, eltárolja azt a memóriában. Amint ez megtelik, nem lesz képes további TCP kapcsolatok kialakítására más irányból sem. 10. ÁBRA: DOS TÁMADÁS II.[13] 3. Sok helyről sok csomag (DDoS) Az elosztott szolgáltatás megtagadásos támadás (Distributed Denial of Service) napjainkban igen elterjedt támadási forma.[15] A különbség az előzőekben tárgyaltakhoz képest az, hogy a támadó fél nem csupán egy eszközt használ fel a forgalom generálására, hanem egy kiterjedt, átlagos számítógépekből kialakított hálózatot (botnetet). Ezen gépek tulajdonosai nincsenek tudatában annak, hogy az eszközeiket támadásokhoz használják fel, a támadó ban terjedő féreg vagy trójai programok segítségével éri el az azok feletti irányítást. A módszer viszonylag egyszerűnek mondható: a megfertőzött számítógépek ICMP echo request (ping) csomagokat küldenek a célpontnak, az pedig a megnövekedett adatforgalmat nem képes kezelni.

23 Példa: MyDoom féreg[17], január végén terjedt el, február elsején 1 millió számítógép egyszerre kezdte meg a DDoS támadást az SCO Group hivatalos webszervere ellen. A domain egy időre elérhetetlenné vált, a támadás sikeres volt. Ezután nem sokkal újabb támadásokat indítottak a Microsoft és a RIAA (Recording Industry Association of America, Amerikai Hanglemezkiadók Szövetsége) ellen, majd hónapokkal később megbénították a Google cég kereső szolgáltatásának motorját és az AltaVista műkődésében is érezhető lassulás volt tapasztalható. 11. ÁBRA: DDOS TÁMADÁS

24 A kivédés lehetőségei Felderítő támadás ellen védekezhetünk erős jelszavak használatával[18], az adatok minél hatásosabb titkosításával, anti-sniffer eszközökkel, valamint IPS (Intrusion Prevention System, Támadás Megelőző Rendszer[19]) és tűzfal segítségével. Ez utóbbin gyárilag is megtalálhatóak olyan beállítások, amelyek felismerik, ha a támadó port scannelést hajt végre. A csomagfigyelő szoftverek ellen továbbá hatásos megoldás lehet a kapcsolt infrastruktúra (switched infrastructure) kiépítése, amely megnehezíti a két fél közötti információáramlás megfigyelését. Hozzáférési támadás ellen szigorú jelszó szabályzattal (policy) védekezhetünk, például a jelszó erősségének minimumát meghatározhatjuk a felhasznált karakter-intervallumok kibővítésével. Fontos a Trust exploitation támadás kivédéséhez az úgynevezett Principle of minimum trust gondolkodásmód kialakítása és alkalmazása, amely biztosítja, hogy kizárólag azok az eszközök bízzanak meg egymásban, amelyeknél ez igazán szükséges, és azok se teljes mértékben. A Man-in-the-middle támadás ellen a titkosítás továbbfejlesztésével lehet védekezni, pl. SSL és PGP technikák felhasználásával.[20] Mivel a legtöbb sikeres támadás a szoftverek felfedezett sérülékenységei miatt következhet be, létfontosságú a rendszer működése szempontjából az operációs rendszer és a többi alkalmazás biztonsági frissítéseinek telepítése és folyamatos karbantartása. DoS támadás ellen anti-spoofing technológiákat használhatunk fel, amik nagy arányban derítik fel az álcázás megtörténtét, IPS segítségével megelőzhető a szolgáltatás megbénítása, és sok esetben már az olcsóbb tűzfalak is képesek gyárilag a DoS támadás felismerésére. Amennyiben egy hálózaton belül létezik olyan adatforgalom, amelynél fontos a csomagok késési idejének minimalizálása, érdemes elgondolkozni a QoS (Quality of Service) bevezetésén. Ennek segítségével előtérbe hozható például a VoIP forgalmazás, ahol a csomagok késése érezhető változást okoz a telefonos beszélgetés során, míg az ek kézbesítése általában alacsonyabb prioritással rendelkezik. Természetesen ezt teljes mértékben a saját igényekre lehet szabni, és elkerülhető a rendszer lassulása esetén a fontos adatforgalom akadályozása, kimaradása.

25 GYAKORLATI PÉLDA 4.1. A feladat bemutatása Szakdolgozatom elsődleges feladataként azt a célt tűztem ki, hogy egy tanácsadó cég szemszögéből mutassam be a sérülékenységvizsgálatnak, mint szolgáltatásnak a megvalósítását. Ennek érdekében segítséget kértem egy hazai információbiztonsági tanácsadó cég, a Proyet Kft. műszaki igazgatójától, aki a bemutatta a sérülékenységvizsgálati szolgáltatásuk folyamatát, az ajánlattételtől a feltárt sérülékenységeket tartalmazó dokumentáció átadásáig. A mérésben résztvevő hálózatot az egyik évfolyamtársam biztosítja, a webszerver elérhetősége: A Proyet Kft. többféle módszert ajánl fel a megrendeléseik teljesítéséhez: Az internet irányából az eszközök (kiszolgáló, hálózat) vizsgálatához a külföldi Qualys, Inc. szolgáltatását, a QualysGuard ot veszik igénybe. Ez utóbbit fogom a következőkben részletesebben is bemutatni. A megrendelő belső hálózatában elhelyezett, kifejezetten az ilyen jellegű mérésekre kifejlesztett készülékkel pontosabb információkhoz juthatunk, de ez kiszállást, több munkát és több időt igényel. Az eszköznek két Ethernet portja van, az egyik a mérni kívánt hálózatba kerül bekötésre (mérés), a másik segítségével pedig a WAN irányában kommunikál, a központtal tartja fent a kapcsolatot (vezérlés). Fontos, hogy a vizsgálni kívánt eszközök ugyanabban a VLAN -ban helyezkedjenek el. Ezen az eszközön szintén megtalálható a QualysGuard, mint szoftveres környezet. A QualysGuard szolgáltatás két fő részből épül fel: 1. A méréseket lehetővé tevő mérőeszközök (akár egyedi) beállítása alapján elindítható vizsgálatsorozatok, és 2. Az a háttérben meghúzódó, jelen pillanatban megközelítőleg sérülékenységet tartalmazó adatbázis. Ezek a sérülékenységek típusuk, súlyosságuk, kategóriájuk szerint csoportosítva vannak, valamint azok túlnyomó többségéhez ezek a bejegyzések megoldási javaslatokat is tartalmaznak. Úgy gondolom, ez a tudásbázis a szolgáltatás legértékesebb része.

26 ÁBRA: A QUALYSGUARD FELHASZNÁLÓI FELÜLETE A cég által alkalmazott üzleti folyamat a következő lépésekből épül fel: 1. Kapcsolatfelvétel, konzultáció: A kapcsolatfelvétel kétféle módon történhet meg: vagy a megrendelő keresi fel közvetlenül a vállalatot, vagy pedig ez utóbbi tesz ajánlatot a leendő ügyfélnek. A valóságban az utóbbi a gyakoribb. Konzultációs alkalmakat a későbbiekben is lehet kérni a cég munkatársaitól, előzetes egyeztetés alapján. 2. Műszaki egyeztetés: Első lépésben titoktartási nyilatkozat aláírását vállalja a megbízott fél. A tanácsadó cég az ügyféllel letisztázza a műszaki részleteket a vizsgálat elvégzéséhez, mint például a vizsgálni kívánt eszközök típusa és száma vagy a mérés fajtája (külső vagy belső). A szerződésben foglalt készülékek száma az esetek túlnyomó többségében nagyságrendben n és n*10 (virtuális szerverek esetén a mérések számát az IP címek alapján határozzák meg, amelyekből egy fizikai eszközön többet is lehet találni. Ezek külön eszközöknek számítanak a vizsgálat szempontjából). Ezeken felül általában az IT osztály vezetőjének, illetve kis vállalatok esetén a cég adminisztrátorának a munkaállomása is beletartozik a vizsgálatba.

27 Jelentés elkészítése: A vizsgálat ebben a szakaszban történik meg, ahogy a kapott eredmények alapján történő dokumentáció elkészítése is. Többféle jelentésről (Report) beszélhetünk egy mérés elvégzése után, attól függően, hogy kinek készül: a. Az IT osztály (biztonsági csoport, stb.) számára készült jelentésben minden rendelkezésre álló részlet szerepel a hibák minél hamarabbi kijavítása érdekében, megoldási javaslatokkal, pontos adatokkal, b. A vezetőség számára látványos, gyorsan átlátható jelentés a mérés eredményességét és szükségességét mutatja be, a lehető legkevesebb informatikai szakkifejezés használata mellett az érthetőség érdekében. 4. Összefoglaló előadás A tanácsadó cég vállalja, hogy a megbízó fél vezetősége előtt prezentálja a vizsgálat során tapasztalt hiányosságokat. 5. A vizsgálat esetleges megismétlése Amennyiben arra igény van, a vizsgálatokat adott időközönként végrehajtva rendszeresíteni is lehet, így lehetőség van arra, hogy megfigyelhessenek egyfajta tendenciát az informatikai biztonsággal kapcsolatban. A rendszeres vizsgálat segít minél hamarabb kiszűrni például egy adott szoftver frissítése, vagy éppen annak hiánya okán kialakuló biztonsági rések jelenlétét, de mindenesetre minimalizálja a kompromittálás lehetőségét és annak bekövetkezése esetén az okozott kár nagyságát. Bár a többszöri mérés lehetősége csak opcionális, ugyanakkor erősen ajánlott az ügyfelek számára. Fontosnak tartom megjegyezni, hogy az Ethical hacking csupán a hibák felfedezésére és dokumentálására irányul, a javítás minden esetben a helyi adminisztrátor, vagy az ebben illetékes csoport (biztonsági csoport, IT, stb.) feladata és kötelessége. Külön kérésre konzultációs időpontot lehet a tanácsadó céggel egyeztetni, ekkor személyes véleményezést adhatnak a legfontosabbnak tűnő sérülékenységekről.

28 A szolgáltatás folyamata során a szükséges dokumentumok az alábbiak lehetnek: 1. Titoktartási nyilatkozat: Mindkét fél számára fontos a bizalom, és annak jogi hátterének kialakítása a későbbi félreértések elkerülése érdekében. 2. Szerződés: A felhatalmazás (és annak részletei) a vizsgálatok elvégzésére Penetration test, azaz behatolásvizsgálat esetén külön figyelmeztetni kell a megrendelőt a későbbi jogi incidensek elkerülése miatt, és ennek érdekében abba írásban bele kell egyezniük. 3. Hálózati dokumentáció bekérése: Szerverek, gépek, portok, tehát informatikai vagyonelemek és azok aktuális beállításai. Mivel sűrűn változhatnak (például a portok vagy az IP címek), ezért általában nincs frissen tartva. Ritkán található hálózati dokumentáció egy cégnél, ha mégis lenne, akkor azt valószínűleg még a szolgáltatójuk adhatta a hálózat kiépítésekor, ők viszont csak a saját felszerelésükről tudtak adni dokumentációt, más készülékekről nem) 4. Dokumentáció: Az eredmény birtokában és annak felhasználásával különböző jelentések, és azok mellé szubjektív véleményezés csatolása a hálózat állapotáról, valamint a legsürgősebbnek tűnő teendőkről. A mellékletben megtalálható a Hozzájárulás sérülékenységi vizsgálathoz c. dokumentum, a további dokumentumok a szakdolgozat CD mellékletére kerültek rá. A szolgáltatást kínáló cég mindig törekszik arra, hogy független szakértőként állhassanak rendelkezésre. Amennyiben nem független szakértőre bíznák a vizsgálat végrehajtását, az biztonsági kockázatokkal járhat (rossz esetben például a cég adminisztrátora akár el is hallgathatja azokat a réseket, amelyek kiküszöbölése meghaladja a szakmai tudását, ezáltal lehetőséget nyújt a sikeres támadásra a rendszer ellen).

29 A szolgáltatás bemutatása a gyakorlatban Előzetes konzultációkon vettem részt a dolgozatomban segítséget nyújtó Proyet Kft. műszaki igazgatójával, aki segített kiválasztani a feladatban meghatározott hálózati eszköz vizsgálatához optimális mérési módszert, továbbá az időközben felmerült kérdéseimre rövid időn belül teljes mértékben kielégítő válasszal tudott szolgálni. Konzultáció, műszaki egyeztetés A megrendelővel több konzultációt is tartottam, miután korábban megbizonyosodtam ingyenesen elérhető szolgáltatások segítségével a tulajdonjogokról és néhány mellékes további információról (szolgáltató, stb.), ilyen szolgáltatás például a WHOIS.[16] Az előzetes felmérés a későbbi bonyodalmak (adott esetben perek) elkerülése érdekében szükséges. A műszaki egyeztetésen a titoktartási nyilatkozat aláírása után megismerkedtem a vizsgálni kívánt hálózat topológiájával, valamint a hálózati eszközök tulajdonságaival. A titoktartási nyilatkozatnak része, hogy a szakdolgozatban felhasználhatom a hálózatról begyűjtött részleteket és az eredményeket, de semmilyen más formában nem adhatom tovább azokat. Jelentés elkészítése (mérés) Arra a megállapításra jutottam, hogy a vizsgálni kívánt hálózatot legeredményesebben a QualysGuard webes felületű szolgáltatásával tudjuk megmérni. A kapott eredményeket HTML és PDF formátumban a megrendelő részére át fogom adni (további lehetőségként megemlítettem a hivatalos kimutatási formát is, amely a Mellékletek/Dokumentumok/Pelda_Report.doc állományban található a szakdolgozat CD mellékletén, de ezt a megrendelő nem igényelte). Javítás, a vizsgálat megismétlése Amennyiben a felfedezett sérülékenységeket a megrendelő segítségével képesek leszünk kijavítani, az eszközön új mérést fogok elvégezni, hogy megbizonyosodjak a mérési eredmény pontosságáról és a szolgáltatásom eredményességéről.

30 A vizsgált hálózat bemutatása Ebben a fejezetben a mérni kívánt webszerver hálózati topológiáját, szoftveres és hardveres jellemzőit, továbbá néhány beállítását (IP és MAC cím) fogom bemutatni. Logikai topológia A webszerveren kívül a helyi hálózat része még egy munkaállomás, továbbá egy forgalomirányító. A hálózat logikai topológiája a 13. ábrán látható Si Router DLink DI Workstation MUSZK Server IDSERVER ÁBRA: A VIZSGÁLT HÁLÓZAT LOGIKAI TOPOLÓGIÁJA Az eszközök jellemzése Az eszközökön megtalálható főbb alkalmazások (operációs rendszer, firmware, stb): Router (Router): Firmware version: V3.15, Fri, Apr Workstation (MUSZK): Server (IDSERVER): Microsoft Windows XP Professional SP3, COMODO Internet Security Microsoft Windows XP Professional SP3, COMODO Firewall , Apache HTTP Server 2.2, PHP

31 A MUSZK nevű munkaállomás bemutatása: A gép egy általános célú munkaállomás. Több operációs rendszer közül is választhatunk a boot folyamat közben. Az IDSERVER kiszolgáló leállása esetén a MUSZK munkaállomás képes átvenni annak szerepét, így a redundancia megjelenik a hálózaton. A MUSZK-ot ehhez újra kell indítani, majd a megfelelő operációs rendszer elindítása esetén automatikusan betöltődik a webszolgáltatáshoz szükséges szerveralkalmazás. Az IDSERVER nevű kiszolgáló (server) bemutatása: A mérés elsődleges célpontja a hálózaton megtalálható kiszolgáló, az IDSERVER. A webalkalmazás ideális esetben ezen az eszközön fut. Apache webszerver és MySQL adatbáziskezelő szerver van telepítve rá, PHP motor, valamint a webalkalmazáshoz szükséges Microsoft Windows XP operációs rendszer.[21][22][23][24] Az IDSERVER részletes hardveres és szoftveres jellemzői: Processzor: Intel Pentium 4, 2533 MHz (14 x 181) Rendszermemória: 1536 MB (DDR SDRAM) Hálózati kártya: Intel(R) PRO/1000 CT Network Connection Operációs rendszer: Microsoft Windows XP Professional SP3 PHP motor: PHP Webszerver: Apache HTTP Server 2.2 Tűzfal: COMODO Firewall A webszerver statikus (fix) IP címmel rendelkezik, elérhető a címen: Pinging with 32 bytes of data: Reply from : bytes=32 time=11ms TTL=55 Reply from : bytes=32 time=9ms TTL=55 Reply from : bytes=32 time=10ms TTL=55 Reply from : bytes=32 time=10ms TTL=55 Ping statistics for : Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 9ms, Maximum = 11ms, Average = 10ms

32 Mérések előkészítése A vizsgálatok során négy különböző mérést hajtok végre a rendszeren: Alkalom TCP beállítások UDP beállítások 1. mérés Standard TCP Standard UDP 2. mérés Light TCP Standard UDP 3. mérés Standard TCP Light UDP 4. mérés Light TCP Light UDP 14. ÁBRA: A MÉRÉSEK TULAJDONSÁGAI A Standard és a Light közötti különbség főként a vizsgálatban résztvevő portok számára vonatkozik. Mindkét esetben lehetőségünk van (a megrendelő külön kérésére, illetve a saját feladatunk megkönnyítése érdekében) az eredetileg meghatározott portok halmazát kiegészíteni saját kezűleg megadott portokkal vagy porttartománnyal. A TCP és az UDP protokoll közötti alapvető különbségekből adódóan felmerül a mérés futásidejének kérdése is. A TCP protokoll használatakor a két végpont között szinkronizációs folyamat háromutas kézfogás történik meg, és annak meghatározott időn belül létre kell jönnie, vagy a kapcsolat létrehozására irányuló törekvés megszakad. Az UDP protokoll esetében szinkronizációról nem beszélünk, tehát itt minden esetben meg kell várnunk a timeout ot, ha egy portot akarunk megszólítani. Ez akkor jelenthet problémát, ha viszonylag sok UDP portot vizsgálunk meg a teszt során. A tanácsadó cég műszaki igazgatójának tapasztalatai szerint nem történt még olyan vizsgálat az eddigi megrendeléseik során, ahol ne találtak volna sérülékenységet, amennyiben ez történne, az gyanúra adhat okot, például, hogy rossz beállításokkal indítottuk el a vizsgálatokat. Ez a valóságban a hibás (vagy csak részleges) dokumentáció, illetve a kellő mennyiségű segítségnyújtás hiánya miatt történhet meg. Az alábbiakban bemutatom a beállítási profil elkészítését lehetővé tevő menüpontot.

33 Beállítási profilok létrehozása és alkalmazása A QualysGuard szolgáltatás részeként lehetőségünk nyílik létrehozni saját beállítási profilokat. Ésszerű megoldás lehet arra az esetre, ha több (vagy adott esetben sok) hasonló jellegű mérést kell elvégezni a megrendelések során, amelyek nagyjából azonos beállításokat igényelnek. Természetesen létezik egy alapbeállítás (default), amelyet a rendszeren belül Initial Options nek van elnevezve. Egy saját beállítási profil elkészítésénél első pillantásra nem találunk sok beállítási lehetőséget, viszont az Advanced gombra kattintva lehetőséget kapunk a beállítások finomhangolására is. Amennyiben vissza szeretnénk térni az előző állapotba, a Basic gombra kell kattintanunk. 15. ÁBRA: OPTION PROFILE A beállítási profil elkészítéséhez három kategóriába vannak osztva azok a tulajdonságok, amikkel a mérést paraméterezhetjük: Scan, Map, Additional. Ha jobban megfigyeljük a Basic és az Advanced mód közötti különbséget, akkor azt az összefüggést tapasztaljuk, hogy a Basic módban beállítható értékek mindegyikét megtaláljuk az Advanced módban is. Az alábbi képeken kiemeléssel jelzem azokat a beviteli és információs mezőket, amelyek a Basic módban is megtalálhatóak.

34 ÁBRA: OPTION PROFILE - HALADÓ BEÁLLÍTÁS: SCAN

35 A Scan kategóriában található meg a legtöbb olyan beviteli mező, amely értékeinek megváltoztatására szükségem lehet a feladat elvégzése érdekében. Ezek közül is a legfontosabb a portok beállítása (Ports), ahol a vizsgált TCP és az UDP portok halmazát lehet szűkíteni illetve bővíteni. A None lehetőség kiválasztásával teljes mértékben ki lehet hagyni az adott protokollokat, a Full lal pedig az összes adott protokollhoz tartozó portot megvizsgálhatjuk (ez drasztikusan megnövelheti a mérés futásidejét). Az Additional mező kiválasztásával, kézzel is hozzáadhatunk portokat a korábban megjelölt intervallumhoz. 17. ÁBRA: OPTION PROFILE - HALADÓ BEÁLLÍTÁS: MAP A Map kategóriában meghatározott értékek alapján fogja a vizsgálat adatokkal feltölteni az eredményben az összegyűjtött információk (Information Gathered) csoportot (később kifejtve). Tapasztalataim szerint az alapbeállításban megtalálható értékek megfelelnek az általános célú felhasználásra, azokon a jelenlegi feladat elvégzéséhez nem kellett változtatni.

36 ÁBRA: OPTION PROFILE - HALADÓ BEÁLLÍTÁS: ADDITIONAL Az Additional kategóriában további beállításokat hajthatunk végre a mérésünkre - főként a host -okra - vonatkozóan, továbbá olyan eszközöket adhatunk meg, amelyeket szeretnénk kihagyni a vizsgált tartományból. A feladat elvégzésekor ezek átállítására nem volt szükségem, így meghagytam az alapbeállításokat. A beállítási profilokat a méréseim során főként a vizsgált TCP és UDP portok száma alapján állítottam át, ennek megfelelően kapták a nevüket: default: Standard TCP és Standard UDP idphoto4you_2_tcp_light: Light TCP és Standard UDP idphoto4you_3_udp_light: Standard TCP és Light UDP idphoto4you_4_tcp_udp_light: Light TCP és Light UDP

37 Első mérés Az előkészületek után megkezdem a sérülékenységvizsgálat kulcsfontosságú részét, a méréseket. Első alkalommal azt a beállítási profilt használom, amit a szolgáltatás eredetileg beépítve tartalmaz (default, Standard TCP és Standard UDP). A mérés elindításakor három adatot kell megadni: a mérés nevét (Title), a beállítási profilt (ezt egy legördülő listából választhatjuk ki), továbbá a vizsgált IP címtartományt. Az elvárásaim az első méréssel szemben: fedezzük fel a teszt segítségével a sérülékenységek számát, típusait és súlyosságukat, és ezeket egyértelműen meg lehessen állapítani az eredményül kapott riportból. Az így kinyert adatokat a későbbi hibajavításhoz fel szeretném használni, ezért is fontos, hogy minél informatívabbak legyenek. Mivel nincs még semmilyen tapasztalatom a szolgáltatással kapcsolatban, ezért a vizsgálat időtartamáról sincs elképzelésem. Egy meglehetősen komplex teszt-sorozatról van szó, ezért valószínűnek tartom, hogy nem kapok perceken belül jelentést a mérés befejeződéséről. A vizsgált portok száma alapján ettől a méréstől várom a legnagyobb mérési időt, ugyanakkor a legrészletesebb és legpontosabb eredményt is. 19. ÁBRA: ELSŐ MÉRÉS BEÁLLÍTÁSA

38 ÁBRA: ELSŐ MÉRÉS FUTÁS KÖZBEN 21. ÁBRA: ELSŐ MÉRÉS ÖSSZEGZÉSE A mérés futásideje körülbelül 45 perc volt. Ennél kevesebbre számítottam, de valószínűleg a többi mérés sem fog tovább tartani. Az összegzés (Vulnerability Summary) csak minimális információt tartalmaz a kapott eredményről, annak részletes bemutatását és kiértékelését később teszem meg.

39 Második mérés Ebben a mérésben már felhasználhattam a korábban említett New Option Profile menüpontban létrehozott beállítási profilt is, aminek az idphoto4you_2_tcp_light nevet adtam. A későbbi mérésekre való tekintettel célszerűnek láttam az egyértelmű elnevezést, és ennek megfelelően adtam ugyanezt a nevet a második mérésnek is. A további mérések során is ezt az elvet fogom követni az elnevezések tekintetében. Az előző méréshez képest mindenképpen rövidebb futásidőre számítok, ugyanakkor nagyságrendi különbséget az UDP portok számának azonossága miatt nem várhatok el a korábban említett okok miatt (timeout). A megtalált sérülékenységek számát figyelembevéve semmiképpen sem kaphatok nagyobb értékeket az előző mérésnél. Ez csak két módon történhetne meg: ha az aktuális mérés mélyrehatóbb vizsgálatot eredményezne (ez egyértelműen kizárható), illetve ha a vizsgált eszközön más feltételek között indítanám el a mérést, például, régebbi verziójú PHP motor, rosszul beállított tűzfal, vagy olyan operációs rendszer használata, amelyet nem frissítenek rendszeresen. Mivel a mérések között semmilyen változtatást nem okoztunk a szerveren, ezért ezt az esetet is kizárhatjuk. Sejteni lehet, hogy a későbbi hibajavítás során ez a mérés kevésbé fog szerepet játszani. 22. ÁBRA: MÁSODIK MÉRÉS BEÁLLÍTÁSA

40 ÁBRA: MÁSODIK MÉRÉS FUTÁS KÖZBEN 24. ÁBRA: MÁSODIK MÉRÉS ÖSSZEGZÉSE A mérés befejeződése több érdekességgel is szolgált. A hibajavításban irreleváns, mégis meglepett, hogy nagyságrendben ugyanannyi ideig tartott a mérés, mint az első esetben (44 perc). Ennél sokkal érdekesebb a megtalált sérülékenységek és információk száma, ami pontosan ugyanannyi volt, mint az előző mérés során. Látszólag tehát az első két mérés eredménye semmiben sem különbözik egymástól.

41 Harmadik mérés Ehhez a méréshez is új beállítási profilt hoztam létre idphoto4you_3_udp_light névvel, ez Standard TCP és Light UDP beállításokat tartalmaz. Az elnevezési konvenciókat az előző mérésnél fejtettem ki. A korábbi mérésekhez képest futásidőben jóval kevesebbet várok el, a megszerzett sérülékenységek listájával és a begyűjtött információval kapcsolatban nagyságrendi különbséget érzésem szerint nem fogok tapasztalni. A szerveren futó tűzfalon valószínűleg nagyon kevés UDP port van nyitva, ebből fakadóan valószínűleg egyik mérés során sem fogok tapasztalni ezzel kapcsolatos sérülékenységeket. Mivel ezúttal sem változtattunk semmit a szerveren, ami a védelmet befolyásolhatná, ezért több sérülékenységet most sem tapasztalhatunk az első méréshez képest. 25. ÁBRA: HARMADIK MÉRÉS BEÁLLÍTÁSA

42 ÁBRA: HARMADIK MÉRÉS FUTÁS KÖZBEN 27. ÁBRA: HARMADIK MÉRÉS ÖSSZEGZÉSE Ettől a méréstől vártam a futásidő drasztikus csökkenését leginkább, de ezúttal is körülbelül 45 perc volt az időtartam. Ebből azt a következtetést vontam le, hogy ezt az időmennyiséget elsősorban nem a mérési feltételek befolyásolják. A sérülékenységek száma ezúttal is megegyezik az előző mérések eredményével.

43 Negyedik mérés Elméletileg az utolsó méréstől várható a legkevesebb értékes információ, hiszen az idphoto4you_4_tcp_udp_light beállítás szűkíti le leginkább a vizsgált portok halmazát. Az előző mérések eredményeit megfigyelve ugyanakkor belátható, hogy nincs különbség esetünkben a Standard és Light TCP, illetve a Standard és Light UDP beállítások során tapasztalt eredmények között, és ez akkor sem változhat, ha a két Light beállítást kombináljuk. Az első mérésem elkezdése előtt úgy gondoltam, hogy ez a mérés fog a legrövidebb ideig tartani, de az előző három mérésből kiindulva ebben is elkezdtem kételkedni. További lehetőségként be lehetne állítani a New Option Profile menüpontban a portok halmazának manuális bővítését, de ezt általában akkor célszerű megtenni, ha a megrendelő ezt kifejezetten kéri, illetve valamilyen információ áll a rendelkezésünkre arról, hogy bizonyos szolgáltatások milyen portokon futnak az adott eszközön. Jelen esetben nem történt ilyen kérés, ezért ettől eltekintünk a mérések során. 28. ÁBRA: NEGYEDIK MÉRÉS BEÁLLÍTÁSA

44 ÁBRA: NEGYEDIK MÉRÉS FUTÁS KÖZBEN 30. ÁBRA: NEGYEDIK MÉRÉS ÖSSZEGZÉSE A korábbi mérések alapján a jelenlegi vizsgálat semmi újjal nem szolgált, az időtartam is megközelítőleg ugyanakkora volt, és a megtalált sérülékenységek száma is azonos a korábbi eredményekkel. Mivel számomra a négyféle beállítás gyakorlatilag ugyanazt az eredményt hozta ugyanannyi idő alatt, elgondolkoztam rajta, nem rontottam-e el valamit a beállításoknál? Utólag is leellenőrizve, mindent jól csináltam. A következő konzultáció során meg fogom kérdezni a konzulensemet ezzel kapcsolatban.

45 Kiértékelés Miután a mérések eredményeit összehasonlítottam egymással, a várakozásaimnak ellenmondó következtetést kellett levonjak. Mint kiderült, mind a négy mérés ugyanazt az eredményt adta, másképpen fogalmazva a negyedik legdurvább szemcsézettségű mérés által biztosított adatoknál többet a komplexebb mérések sem tudtak nyújtani. A konzultáció során megtudtam, hogy a legtöbb esetben a vizsgált eszköz illetve hálózat sérülékenységéhez elegendő a Light TCP és Light UDP beállítások használata. A mérések eredményei között például akkor lehet különbség, ha úgynevezett egzotikus portok vannak használatban (például 9xxx es porton fut egy bizonyos szolgáltatás), ezt a Light TCP illetve Light UDP beállítású mérés nem feltétlenül találná meg. Amennyiben használatban van ilyen port az eszközön, azzal általában a megrendelő is tisztában van, és ennek az információnak az átadásával segítheti az együttműködést. A beállítási profiloknál ezeket a portokat kézzel is hozzá lehet adni, amennyiben az nem szerepel a listában. A mérési eredmény dokumentuma több részre osztható fel: A dokumentum fejlécében megtalálható a mérés dátuma mellett annak a személynek az adatai is (név, felhasználónév, beosztás, elérhetőségek), aki azt elvégezte. Ez abban az esetben lehet igazán értékes információ, amikor az adott eszköz (hálózat) vizsgálata egy csapatnak (project team) van kijelölve. A dokumentum törzsében található meg a jelentés összegzése (Report Summary), a sérülékenységek összegzése (Summary of Vulnerabilities), azok táblázatos formában megadott eloszlása a súlyosságuk és típusuk, valamint kategóriájuk szerint, végül azok részletes kifejtése (Detailed Results). A Report Summary rovat tartalmazza azokat az adatokat, amelyek a hálózatot és magát a mérést jellemzik, többek között a vizsgált hostok számát, az IP címek tartományát, a mérés típusát, állapotát, a mérőeszköz azonosítóját, és azt a beállítási profilt, amellyel a vizsgálat elindult. A sérülékenységek összegzése (Summary of Vulnerabilities) két értéket foglal magába: a felfedezett (valós vagy vélt, a továbbiakban: igazolt illetve potenciális) sérülékenységek és megszerzett információk (később kifejtve) összegét, illetve a biztonsági kockázat nagyságát (Security Risk (Avg)). Itt jegyezném meg, hogy ez

46 utóbbi kifejezés félreérthető, a mérés eredményeinek áttekintése után felvettem a kapcsolatot a konzulenssel, aki a kérdésemre felvilágosított, hogy ez az érték a legsúlyosabb (később kifejtve) sérülékenység nagysága, nem pedig azok átlaga. A sérülékenységek csoportosítása elsőre számomra nem volt egyértelmű, ezért az alábbi ábrán érthetőbb módon mutatom be azok osztályozását a szolgáltatás szemszögéből: Összes sérülékenység (Summary of Vulnerabilities) Sérülékenységek (Vulnerabilities) Összegyűjtött információk (Information Gathered) Igazolt sérülékenységek (Vulnerabilities) Potenciális sérülékenységek (Potential Vulnerabilities) Ezek alapján három fő csoportról beszélhetünk: igazolt és potenciális sérülékenységekről, illetve megszerezhető információkról Igazolt sérülékenységek (Vulnerabilities): Olyan biztonsági rések az adott eszközön, amely valós fenyegetést jelent, és befoltozásaik elsődleges fontosságúak az informatikai biztonság szempontjából. Potenciális sérülékenységek (Potential Vulnerabilities): Veszélyek, amelyeket a mérőeszköz nem tudott bizonyítani, de a létezése valószínű. Olyan esetekben fordulhat ilyen elő, ha egy eszköz elméletileg képes lenne álcázni bizonyos jellemzőit. Összegyűjtött információk (Information Gathered): Olyan publikus adatok az adott eszközről, amelyet a támadó felhasználhat a saját céljainak eléréséhez. Ezek egy része viszonylag ritkán használható fel (például: van tűzfal az eszközön), de akadnak olyanok is, amelyek elősegíthetnek egy sikeres DoS támadást (például ICMP Echo requestre válaszol, stb), vagy a támadó megtalálhatja a webhely korábbi változatát a publikus könyvtárstruktúrában, amennyiben annak elfedésére nem történt erőfeszítés.

47 Amint a bevezetőmben már említettem, feltörhetetlen rendszer nem létezik, sérülékenységek mindig akadnak. Korábban említettem azt is, hogy amennyiben a vagyonelem (esetünkben: webszerver) értéke adott, a kockázat a veszély bekövetkezésével egyenesen arányos. Ezért is fontos az, hogy a sérülékenységeket súlyosságuk alapján kategorizálhassuk. Ezt a QualysGuard megteszi helyettünk. Az igazolt és a potenciális sérülékenységeket 1-5-ig, az összegyűjtött információkat pedig 1-3-ig terjedő skálán sorolják be a veszélyességük alapján az alábbi táblázat szerint: Igazolt Potenciális Összegyűjtött sérülékenységek sérülékenységek információk Elhanyagolható Elhanyagolható Elhanyagolható Könnyű Könnyű Közepes Közepes Közepes Fontos Súlyos Súlyos - Extrém Extrém - Összességében elmondható, hogy igazolt és potenciális sérülékenységek esetén a 4-5-ös besorolásúakat sürgősen ki kell javítani, a 3 asat illik, tehát ha van rá kapacitás, akkor foglalkozni kell velük. Az 1-2 es súlyosságú sérülékenységeket csak a profi hackerek képesek kihasználni, ezekhez ugyanis komolyabb tudás és eszköz szükséges. Összegyűjtött információk esetén csak a kettes és hármas súlyosságúakkal célszerű foglalkozni, az előbb említett okokból kifolyólag. A mérések során az alábbi sérülékenységeket találtam a rendszerben: Igazolt sérülékenységek: Specific CGI Cross-Site Scripting Vulnerability Web Server HTTP Trace/Track Method Support Cross-Site Tracing Vulnerability Expose_php Set to On in php.ini Apache Web Server ETag Header Information Disclosure Weakness

48 Potenciális sérülékenységek: Session-Fixation Social Engineered Session Hijacking PHP curl "safe_mode" and "open_basedir" Restriction Bypass Vulnerability PHP "exif_read_data()" Denial of Service Vulnerability PHP Versions Prior to Multiple Vulnerabilities PHP Versions Prior to Multiple Vulnerabilities Összegyűjtött információk: Web Server Version Traceroute Firewall Detected DNS Host Name Internet Service Provider List of Web Directories Default Web Page Open TCP Services List Host Names Found ICMP Replies Received Host Responds to TCP SYN Packet with Other Flags On with SYN ACK IP ID Values Randomness Degree of Randomness of TCP Initial Sequence Numbers Operating System Detected HTTP method TRACE and/or TRACK Enabled Host Scan Time A továbbiakban a felsorolt sérülékenységek és megszerzett információk közül bemutatok néhányat, azok kijavítására megoldási javaslatokat is teszek.

49 Néhány sérülékenység bemutatása A korábban felsorolt vélt vagy valós sérülékenységek közül az alábbiakat mutatom be: Specific CGI Cross-Site Scripting Vulnerability (igazolt) Session-Fixation Social Engineered Session Hijacking (potenciális) PHP Versions Prior to (5.3.1) Multiple Vulnerabilities (potenciális) Specific CGI Cross-Site Scripting Vulnerability (igazolt) A Cross-Site Scripting (rövidítve: XSS) kifejezés egy olyan módszerre utal, ahol a támadó fél általában egy weblap felületén található szövegbeviteli mezőben olyan karaktersorozatot (string) ír be, amely kellő védelem hiányában a szerveren található adatokat megjelenítheti (SQL injection) vagy annak a személyes információit érheti el, aki a weblapot látogatja. Ez utóbbit javascript beágyazásával teheti meg, aminek alapjait most fogom bemutatni a vizsgált webszerver segítségével. A sikeres kísérlethez mindössze a böngészőalkalmazás címsorában található URL-t kell kibővítenünk, például a 31. ábrán látható állapotot kapjuk eredményül, ha beírjuk a karakterláncot a címsorba: 31. ÁBRA: A CROSS-SITE SCRIPTING SÉRÜLÉKENYSÉG BEMUTATÁSA

50 Session-Fixation Social Engineered Session Hijacking (potenciális) A weboldalak látogatása esetén az aloldalak közötti navigálás közben az adataink továbbítását (például egy bejelentkezés után) az úgynevezett munkamenet (session) segítségével oldják meg. Ezeknek a munkameneteknek véletlenszám-generátorral meghatározott azonosítóik vannak (Session ID), amellyel azokat meg lehet egymástól különböztetni. A mérőeszköz segítségével arra a következtetésre jutottam, hogy lehetséges olyan explicit értékadás, amellyel adott azonosítójú munkamenet indítható el a vizsgált webszerveren. Ezt például olyankor használhatja fel a támadó fél, ha az így létrehozott URL használatára veszi rá a gyanútlan felhasználókat (emiatt szerepel a sérülékenység nevében a Social Engineered kifejezés), és miután befejezték a saját munkamenetüket, a támadó a munkamenet azonosító birtokában további műveleteket is végrehajthat a felhasználó jogosultságaival. Az ehhez tartozó URL a következő: PHP Versions Prior to (5.3.1) Multiple Vulnerabilities (potenciális) Mint minden alkalmazás, a webszerveren futó PHP motor is tartalmaz kihasználható biztonsági réseket. Az alkalmazások fejlesztői folyamatosan adnak ki frissítéseket a szoftverükhöz, amelyben a fejlesztések mellett a felfedezett biztonsági hiányosságokat is igyekeznek csökkenteni. Ezért létfontosságú tehát, hogy az operációs rendszert, valamint lehetőleg az összes többi alkalmazást is naprakészen tartsuk azok legfrissebb stabil verzióinak megszerzésével. Ennek hiányát jelzi a szóban forgó sérülékenység. Azért nem lehet bizonyítani ezt a veszélyt, mert a webszerverek képesek arra, hogy bizonyos adatokat elrejtsenek vagy megváltoztassanak a külső fél számára, így például azt is elhitetheti a támadóval, hogy egy korábbi verziót használ, miközben a legfrisebb van telepítve. Ezt az adatrejtő technikát használhatják fel például az úgynevezett mézesbödön (honeypot) szervereken, amelyek a támadó részére látszólag könnyű célpontot nyújtanak, ugyanakkor csak naplózó és behatolásfigyelő funkciója van, semmilyen fontosabb szolgáltatás, sem adat nem található meg rajta.

51 A sérülékenységek kijavítása és a megismételt mérés bemutatása Ebben a fejezetben a korábban bemutatott négy sérülékenység kijavításának menetetét tervezem bemutatni. Miután a javítások megtörténtek, új mérést fogok végrehajtani, hogy bebizonyítsam a sérülékenységvizsgálat által feltárt biztonsági rések számának csökkenését, ezáltal a rendszer állapotának jelentős javulását. Specific CGI Cross-Site Scripting Vulnerability A felfedezett Cross-Site Scripting sebezhetőség alapja a böngésző címsorában megfigyelhető Lang paraméter értékének módosításával előidézhető javascript programkód lefuttatása.[2] Ezt úgy tudjuk megakadályozni, hogy a paraméter értékét annak feldolgozása előtt megvizsgáljuk, és a tartalom alapján folytatjuk a HTML oldal generálását. Az ellenőrzést a PHP programban kell elvégezni, ami a fejlesztők feladata. Session-Fixation Social Engineered Session Hijacking A sérülékenységet abban az esetben használhatja ki a támadó, ha a böngésző címsorában explicit módon rendel a munkamenet-azonosítóhoz (Session ID) értéket. Ha ezt a veszélyt meg szeretnénk előzni, a webszerveren megtalálható php.ini konfigurációs állományban a session.use_only_cookies változó értékét 1 re kell, hogy állítsuk (azaz engedélyeznünk kell a beállítást). A változtatás a munkamenet-kezelést nem befolyásolta, ez ki lett próbálva a javítás során. PHP Versions Prior to (5.3.1) Multiple Vulnerabilities A webszerveren található PHP motor az es verziószámot viseli, a két egymáshoz hasonlító sérülékenység viszont azt jelzi, hogy elérhetőek frisebb verziók is belőle, azaz azok letöltésével és telepítésével biztonsági réseket foltozhatnánk be. Ezzel a sérülékenységgel a gyakorlatban viszonylag egyszerűen tudnánk foglalkozni, azonban a webszerveren futó webalkalmazás szerkezetét és nyelvének szintaktikáját olyan mértékben kellene leellenőrizni és átdolgozni az új verzióhoz való igazítás következtében, amelyre a webalkalmazás fejlesztőjének jelenleg nincsen kapacitása. A megrendelő a szubjektív javaslatomat megértette, és a biztonsági kockázatok tudatában a PHP motor aktuális verzióra történő frissítésétől eltekintett.

52 A javítások utáni mérés A webszerver tulajdonosával való időpontegyeztetés után lefuttattam az utolsó mérést. Várakozásom szerint két sérülékenységgel kevesebbet kell tapasztaljunk a javításoknak köszönhetően, továbbá azt, hogy azok a rések, amelyek javításával nem foglalkoztunk, a továbbiakban is jelenjenek meg a mérési eredményben. A mérési eredmény szembetűnő változásokat jelez a korábbiakhoz képest: 32. ÁBRA: AZ ELSŐ MÉRÉS RÉSZLETES EREDMÉNYE (RÉSZLET) 33. ÁBRA: AZ UTOLSÓ MÉRÉS RÉSZLETES EREDMÉNYE (RÉSZLET) Az adott sérülékenységek eltűntek a rendszerből. Az újonnan megjelent potenciális sérülékenység a két mérés között eltelt időtartam alatti sérülékenységi adatbázis bővítésére utal (Zero Day vagy 0-day: frissen felfedezett biztonsági rés). A javításokat hatásosnak tartom, így a feladatban kitűzött célt sikerült elérnem.

53 Továbbfejlesztési lehetőségek Az eddig bemutatott vizsgálatok a webszerverre vonatkoztak kizárólag. Lehetőség van ugyanakkor a Qualys szolgáltatásainak felhasználásával a webalkalmazást is vizsgálni, ezzel letesztelhetőek például az SQL injection sérülékenységek, a session és autentikációs problémák feltárása valamint a fájlfeltöltések korlátozása érdekében beépített védelem állapota is. Érdekes lehet továbbá a Malware védelme is a szolgáltatónak, ez béta változatban van, ezért lehet még egy ideig ingyenes a fogyasztók számára.[25] A méréseket rendszeressé is lehet tenni, és ezt követően trendet állítani fel a webszerver biztonságáról, ebben segítségünkre lehet az ütemezett sérülékenységvizsgálat (Scheduled Vulnerability Test) funkció is. Itt lehetőségünk van a mérés pontos idejének és gyakoriságának meghatározására a 34. ábrán látható beállítások segítségével. Ezután automatikusan fog lefutni a vizsgálat a megadott paraméterek alapján. 34. ÁBRA: ÜTEMEZETT MÉRÉS BEÁLLÍTÁSA