ÚTMUTATÓ RENDSZER ÉRTÉKELİKNEK

ÚTMUTATÓ RENDSZER ÉRTÉKELİKNEK

Útmutató rendszer értékelıknek

A dokumentum az Új Magyarország Fejlesztési Terv keretében, az Államreform Operatív Program támogatásával, az „Elektronikus közigazgatási keretrendszer” tárgyú kiemelt projekt megvalósításának részeként készült. A dokumentum elkészítésében részt vett:

EKK_ekozig_utmutato_rendszer_ertekeloknek_080919_V3.docx

2


Metaadat-táblázat Megnevezés Cím (dc:Title) Kulcsszó (dc:Subject) Leírás (dc:Description)

Típus (dc:Type) Forrás (dc:Source) Kapcsolat (dc:Relation) Terület (dc:Coverage) Létrehozó (dc:Creator) Kiadó (dc:Publisher) Résztvevı (dc:Contributor) Jogok (dc:Rights) Dátum (dc:Date) Formátum (dc:Format) Azonosító (dc:Identifier) Nyelv (dc:Language) Verzió (dc:Version) Státusz (State) Fájlnév (FileName) Méret (Size) Ár (Price) Felhasználási jogok (UserRights)

Leírás Útmutató rendszer értékelıknek IT biztonság; értékelés; útmutató Az elkészült e-közigazgatási alkalmazásokat, valamint az ezt biztosító informatikai rendszereket használatbavételük elıtt meg kell vizsgálni, hogy megfelelnek-e a rájuk vonatkozó biztonsági követelményeknek. A követelménytár tartalmazza a szolgáltató (informatikai) rendszerek megfelelıség vizsgálatára alkalmazható biztonság értékelési módszertant. A módszertan egyaránt meghatározza az értékelési bizonyítékok létrehozásához kapcsolódó rendszer tulajdonosi és rendszer integrátori feladatokat, illetve a biztonságot értékelık feladatait. Ez a dokumentum a rendszer értékelık számára biztosít kiegészítı útmutatást az értékelési módszertan néhány kiemelten fontos részterületéhez. Szöveg, táblázat, ábra e-Közigazgatási Keretrendszer egyéb dokumentumai KOP-ok során megvalósuló projektek, központi IT fejlesztési projektek e-Közigazgatási Keretrendszer Kialakítása projekt Miniszterelnöki Hivatal Hunguard Kft. e-Közigazgatási Keretrendszer 2008.09.19. .doc Magyar V3 Végleges EKK_ekozig_utmutato_rendszer_ertekeloknek_080919_V3.doc

Korlátlan


3


A dokumentum neve A dokumentum készítıjének neve A dokumentum jóváhagyójának neve A dokumentum készítésének dátuma Verziószám Összes oldalszám A projekt azonosítója

Verzió V0.1 V1 V2 V3

Dátum 2008.05.21. 2008.07.20. 2008.07.30. 2008.09.19

Verziókövetési táblázat Útmutató rendszer értékelıknek Hunguard Kft 2008.09.19. V3

64 E-közigazgatási keretrendszer kialakítása

Változáskezelés A változás leírása Elsı tartalomjegyzék Elsı változat Résteljesítésként átadott Végleges változat


4


Szövegsablon Megnevezés 1. Elıszó (Foreword) 2. Bevezetés (Preamble) 3. Alkalmazási terület (Scope) 4. Rendelkezı hivatkozások (References) 5. Fogalom-meghatározások (Definitions) 6. A szabvány egyedi tartalma (UniqueContent) 7. Bibliográfia 8. Rövidítésgyőjtemény 9. Fogalomtár 10. Ábrák 11. Képek 12. Fogalmak 13. Verzió 14. Mellékletek (Appendix)

Leírás 1. fejezet 2. fejezet

8. fejezet 9. fejezet szövegben nincs 5. fejezet V3 nincs


5


Tartalomjegyzék 1. 2.

Elıszó.............................................................................................................................................................. 7 Bevezetés ........................................................................................................................................................ 7 2.1. A dokumentum célja ............................................................................................................................ 7 2.2. A dokumentum felépítése .................................................................................................................... 7 3. Alkalmazási terület ......................................................................................................................................... 8 4. Rendelkezı hivatkozások................................................................................................................................ 9 5. Fogalom-meghatározások ............................................................................................................................... 9 6. Útmutatók a rendszer értékelés kritikus területeihez....................................................................................... 9 6.1. Útmutató a behatolás teszteléshez...................................................................................................... 10 6.1.1. Bevezetés ...................................................................................................................................... 10 6.1.2. Elméleti alapok.............................................................................................................................. 10 6.1.3. Egy behatolás tesztelési modell..................................................................................................... 17 6.1.4. A behatolás tesztelés gyakorlati megközelítése............................................................................. 21 6.1.5. A legjobban használható értékelési eszközök ............................................................................... 33 6.1.6. Példák behatolás tesztelés forgatókönyvre.................................................................................... 39 6.2. Útmutató a rendszer sebezhetıségi vizsgálatához.............................................................................. 50 6.2.1. Útmutató a független sebezhetıség vizsgálat elvégzéséhez .......................................................... 50 6.2.2. Sebezhetıségi adatbázisok ............................................................................................................ 52 6.2.3. Az ingyenesen használható eszközök elérési lehetıségei ............................................................. 53 6.3. Útmutató az értékelési altevékenységek sorrendjére.......................................................................... 54 6.3.1. Lineáris megközelítés.................................................................................................................... 54 6.3.2. A sebezhetıség vizsgálatra koncentráló megközelítés .................................................................. 56 6.3.3. A két megközelítés összehasonlítása és javasolt alkalmazásuk .................................................... 61 7. Mellékletek ................................................................................................................................................... 62 8. Bibliográfia ................................................................................................................................................... 62 9. Rövidítésgyőjtemény .................................................................................................................................... 63 10. Fogalomtár.............................................................................................................................................. 64 11. Ábrák ...................................................................................................................................................... 64 12. Képek...................................................................................................................................................... 64 13. Táblázatok .............................................................................................................................................. 65 14. Verziószám ............................................................................................................................................. 65


6


1. Elıszó Jelen dokumentum az e-Közigazgatási Keretrendszer részét képezi. Az elkészült e-közigazgatási alkalmazásokat használatbavételük elıtt meg kell vizsgálni, hogy megfelelnek-e a rájuk vonatkozó biztonsági követelményeknek. A megfelelıség vizsgálatra alkalmazható biztonság értékelési módszertan a követelménytár alábbi dokumentumaiban található: ― Termékekre vonatkozó értékelési módszertan [1], ― Összetett termékekre vonatkozó értékelési módszertan [2], ― Rendszerekre vonatkozó értékelési módszertan [3]. A rendszer szintő értékelési módszertan felhasználja a rendszert alkotó összetevıkre (termékekre, illetve összetett termékekre) korábban elvégzett értékelési és tanúsítási munkák eredményeit. A rendszer szintő értékelési módszertan meghatározza az értékelési bizonyítékok létrehozásához kapcsolódó rendszer integrátori feladatokat, valamint a biztonságot értékelık feladatait. A rendszer szintő értékelési módszertanban meghatározott integrátori és értékelıi feladatok végrehajtásához két gyakorlati útmutató kapcsolódik: ― Útmutató rendszer integrátorok számára [4], ― Útmutató rendszer értékelık számára (jelen dokumentum),

2. Bevezetés 2.1.

A dokumentum célja

Jelen dokumentum a rendszer szintő értékelési módszertanban [3] meghatározott rendszer értékelıi feladatok végrehajtásához nyújt gyakorlati útmutatót. Feltételezi [3] tartalmának teljes ismeretét. A dokumentum célja a [3] által meghatározott rendszer értékelıi feladatok elvégzéséhez használható ismeretek nyújtása, s ezzel [3] gyakorlati szemlélető kiegészítése néhány fontos területen.

2.2.

A dokumentum felépítése

Az 1. fejezet elhelyezi a dokumentumot az e-Közigazgatási Keretrendszeren belül, tájékoztatást adva a célközönségrıl és a kapcsolódó dokumentumokról.


7


A 2. fejezet bevezetı információkat tartalmaz, megadva a dokumentum célját és felépítését. A 3. fejezet meghatározza az alkalmazás lehetséges területeit. A 4. és 5. fejezet a hivatkozásokat, illetve a fogalom-meghatározásokat tartalmazza. A 6. fejezet tartalmazza a dokumentum lényegi részét, 3 alfejezetben. A 6.1 alfejezet az egyik kritikus értékelıi altevékenységhez, a behatolás teszteléshez ad elméleti és gyakorlati útmutatást. Egy bevezetı rész (6.1.1) után áttekinti az elméleti alapokat (6.1.2), majd egy általánosan használható modellt ismertet a behatolás tesztelésre (6.1.3), mely hat különbözı szempontból osztályozza a lehetséges megközelítési és kivitelezési módokat. A behatolás tesztelés gyakorlati megközelítése alfejezet (6.1.4) a külsı támadó megközelítését is jellemzı alábbi sorrendet követi: elıkészületek (általános hálózati vizsgálatok), az operációs rendszerek alapkonfigurációira irányuló vizsgálatok, web szerverek vizsgálata, webes alkalmazások vizsgálata, adatbázisok vizsgálata. Az értékelık behatolás tesztelı munkájukhoz számos automatizált mőködést biztosító szoftvert használhatnak fel. 6.1.5 áttekinti a kipróbáltan legjobban használhatókat. A 6.2 alfejezet egy másik kritikus értékelıi tevékenységgel, a sebezhetıség vizsgálatával foglalkozik (melynek egyik altevékenysége a behatolás tesztelés). Elsı lépésben áttekinti az ilyen típusú vizsgálatokat (6.2.1). Ezt követıen a leginkább használható sebezhetıségi adatbázisokat (6.2.2), majd az ingyenesen használható szoftver eszközök elérési lehetıségeit adja meg (6.2.3). A 6.3 alfejezet a rendszer értékelési módszertan által meghatározott értékelıi feladatok végrehajtási sorrendjére ad javaslatot. Két lényegesen eltérı sorrendet ismertet, a lineáris (6.3.1) és a sebezhetıség vizsgálatra koncentráló (6.3.2) megközelítést, melyeket összehasonlítva javaslatot tesz a különbözı értékelési típusokban történı alkalmazásukra (6.3.3). Jelen dokumentumnak nincsenek mellékletei. A 8. - 14. fejezetek kiegészítı információkat tartalmaznak (8. Bibliográfia, 9. Rövidítésgyőjtemény, 10. Fogalomtár, 11. Ábrák, 12. Képek, 13. Táblázatok, 14. Verziószám).

3. Alkalmazási terület A [3] által meghatározott rendszer értékelési módszertan, s így az ezt gyakorlati útmutatóval kiegészítı jelen anyag is elsıdlegesen a közigazgatási operatív programok keretében megvalósított szolgáltató rendszerek biztonsági értékelésére vonatkozik. Ezáltal a közigazgatási operatív programok végrehajtásával elkészülı szolgáltató rendszerekre irányuló megfelelıségi vizsgálatok eljárásrendjének részét képezi. Ugyanakkor az informatikai rendszerek biztonsági értékelési módszertana az elektronikus közigazgatáson kívül, a közszféra más területein, valamint a magánszférában is


8


alkalmazhatók, minden olyan esetben, amikor rendszerek megfelelıség vizsgálatára, ezen belül biztonsági értékelésére van szükség.

4. Rendelkezı hivatkozások A jelen dokumentumban megfogalmazott irányelvek és követelmények az alábbi mértékadó dokumentumokon alapulnak: [1]: Termékekre vonatkozó értékelési módszertan (az „e-Közigazgatási Keretrendszer Kialakítása” projekt keretében kidolgozott dokumentum, V2, 2008.06.08) [2]: Összetett termékekre vonatkozó értékelési módszertan (az „e-Közigazgatási Keretrendszer Kialakítása” projekt keretében kidolgozott dokumentum, V2, 2008.06.08) [3]: Rendszerekre vonatkozó értékelési módszertan (az „e-Közigazgatási Keretrendszer Kialakítása” projekt keretében kidolgozott dokumentum, V2, 2008.08.01) [4]: Útmutató rendszer integrátorok számára (az „e-Közigazgatási Keretrendszer Kialakítása” projekt keretében kidolgozott dokumentum, V2, 2008.08.20) Az 1. táblázat a rendelkezı hivatkozások elérhetıségét adja meg. 1. táblázat - A rendelkezı hivatkozások elérhetısége Cím Termékekre vonatkozó értékelési módszertan Összetett termékekre vonatkozó értékelési módszertan Rendszerekre vonatkozó értékelési módszertan Útmutató rendszer integrátorok számára

Külföldi elérhetıség

Magyar elérhetıség e-Közigazgatási Keretrendszer e-Közigazgatási Keretrendszer e-Közigazgatási Keretrendszer e-Közigazgatási Keretrendszer

5. Fogalom-meghatározások Jelen dokumentum a [3]-ban meghatározott fogalmakon kívül egyéb külön meghatározandó fogalmakat nem használ. Jelen dokumentum feltételezi [3] tartalmának teljes ismeretét.

6. Útmutatók a rendszer értékelés kritikus területeihez A rendszerértékelés – hasonlóan a termék- és összetett termék értékeléséhez – a rendszer biztonsági elıirányzatból kiindulva vizsgálja a követelmények teljesülését, az egyes értékelt termékek- és rendszerek egymásra hatását. Az alábbiakban a legkritikusabb értékelési területek értékeléséhez nyújtunk segítı útmutatókat.


9


6.1.

Útmutató a behatolás teszteléshez

6.1.1. Bevezetés Egy rendszer tesztelésében a szoftver fejlesztıknek, a rendszer integrátoroknak és a rendszer értékelınek eltérı feladatai és felelısségei vannak (lásd részletesebben ezt a kérdést [4]: 6.2.1). Egy szoftver termék fejlesztıjének csak a saját termékét kell tesztelnie, de ennek során a szoftverminıség legtöbb jellemzıjére figyelemmel kell lennie, köztük az alábbiakra: funkcionalitás, megbízhatóság, használhatóság, hatékonyság, karbantarthatóság, hordozhatóság. A termékekbıl rendszert összeépítı rendszer integrátor feladata és felelıssége kettıs: kihasználni a fejlesztık által megvalósított jellemzıket a rendszer integrálásánál, egyúttal biztosítani azt, hogy a különbözı fejlesztık által megvalósított jellemzık ne vesszenek el, ne sérüljenek a rendszer integrálás során. A rendszer integrátoroknak a (komponens, alrendszer és rendszer szintő) teszteléseknél az együttmőködı képességre (interoperabilitás) és különösen a biztonság szempontjaira kell koncentrálniuk, mivel ezek azok a tulajdonságok (segédjellemzık), amelyek különbözı termékekbıl integrált rendszerekben könnyen sérülhetnek. Egy rendszer értékelınek nincs lehetısége a komponens termékek teljes körő vizsgálatára és tesztelésére. Támaszkodnia kell a termék fejlesztık által végzett munkára, szerencsés esetben a termék biztonságát tanúsító független harmadik fél vizsgálati eredményeire, valamit a rendszer integrátor által végzett biztonsági tesztelés eredményeire. A rendszer tesztelés területén az értékelınek két speciális feladata van: ― Ellenırizni és független teszteléssel kiegészíteni az integrátor biztonsági tesztelését (az ASTE garanciaosztály keretében), ― behatolás tesztelést végezni a rendszerre (az ASVA garanciaosztály keretében). A behatolás tesztelés célja potenciális biztonsági sebezhetıségek felfedése. Alapvetıen az értékelı feladata és felelıssége, minthogy különleges (támadói) szemléletet, valamint speciális szaktudást és eszközöket igényel. A biztonsági tesztelést [4] részletezi. Az alábbiak a behatolás tesztelésre összpontosítanak. 6.1.2. Elméleti alapok 6.1.2.1. A behatolás tesztelés helye az értékelési módszertanban A termékek, összetett termékek és rendszerek biztonsági értékelésére vonatkozó módszertanokban [1] - [3] fontos szerepet kap az értékelés tárgyára irányuló behatolás tesztelés. A továbbiak a rendszer értékelésre koncentrálnak, de a leírtak többsége termék és összetett termék értékelésre is érvényes.


10


A behatolási tesztelés nem garantálja, hogy nem lehet sikeresen támadni a rendszert, de jelentısen csökkenti ennek a valószínőségét. A behatolási tesztelés nem helyettesíti a szokásos IT biztonsági tesztelést, és nem váltja ki az értékelés egyéb elemzéseit, vizsgálatait sem. Ugyanakkor a behatolás tesztelés a betetızése minden értékelıi elemzésnek és vizsgálatnak. Ez ad lehetıséget az STOE “feltörésére”. Persze a megközelítési módnak módszeresnek és ésszerőnek kell lennie. Számos körülményt figyelembe kell venni, közte a rendszer értékeinek esetleges sérülését is. 6.1.2.1.1.

A behatolás tesztelés jellemzése

A nyilvános hálózatokkal összekötött informatikai rendszerek biztonságát fenyegethetik olyan illetéktelen és a legtöbb esetben névtelen próbálkozók, akik a rendszerekhez akarnak férni. Ez a helyzet olyan módszerek igénybevételét teszi szükségessé, amely a támadók szemszögébıl vizsgálja a rendszereket, biztosítva hogy a tesztelés feltételei olyan valóságosak legyenek, amennyire csak lehetséges. Mőszaki-technológiai oldalról a behatolás tesztelés egy ellenırzött próbálkozás egy informatikai rendszer vagy hálózat védelmének áttörésére, megtalálva annak sebezhetıségeit. A tesztelı azonos vagy hasonló technikákat használ, mint amit egy valódi támadás esetén alkalmaznak. Az így feltárt sebezhetıségek ellen fel lehet készülni még azelıtt, hogy egy külsı próbálkozó használná ki ıket. A behatolás tesztelés nem vizsgálja a biztonsági funkciók érvényességét, legalábbis nem közvetlenül. Ez éles ellentétben áll a biztonsági teszteléssel. Bár a kockázatok sorrendiségét használja a behatolás tesztelés fókuszának meghatározásában, az elsıdleges cél az, hogy betörjünk a célrendszerbe. A behatolás tesztelés nem vizsgálja az alkalmazáson belüli adatáramlást forráskód szinten. Még ha forráskód bevonására is sor kerül a behatolás tesztelés keretében, ennek kifejezett célja a rendszerbe való betörés elısegítése. Ilyen esetekben a forráskód egy olyan lehetséges input, amely segíti a behatolás tesztelıt abban, hogy hova fókuszálja az erıit, de a behatolás tesztelés önmagában nem forráskód elemzés. A behatolás tesztelés 3 legfontosabb jellemzıje az alábbi: ― sebezhetıség vizsgálaton alapul (sebezhetıségek keresése az STOE-ban vagy annak üzemeltetési környezetében, majd ezek kihatásainak a vizsgálata), ― tesztek kialakításával és futtatásával jár, ― a sebezhetıségek kihasználhatóságának meghatározására irányul. Behatolás tesztelést különbözı célokból lehet végezni, illetve végeztetni: a) a technikai rendszerek biztonságának fejlesztése érdekében, b) a sebezhetıségek azonosítására, c) az IT biztonság külsı fél általi megerısítése (igazolása) céljából, d) a szervezeti és személyzeti infrastruktúra biztonságának javítása érdekében. Az IT behatolási teszt eredménye több kell legyen, mint a létezı sebezhetıségek felsorolása, ideális esetben megoldásokat is kell javasolni ezek kivédésére.


11


A technikai rendszerek biztonságának fejlesztése érdekében végzett behatolási tesztek csak a technikai rendszerekre korlátozódnak (mint például a tőzfalak, routerek, web szerverek), a szervezeti és személyzeti infrastruktúra ilyenkor nem kerül közvetlen tesztelés alá. Példa erre egy olyan behatolási teszt, amelynek célja kifejezetten azt vizsgálni, hogy hozzáférhetnek-e jogosulatlan külsı felek egy szervezet LAN-jához az interneten keresztül. A lehetséges teszt eredmények lehetnek megtalált, szükségtelenül nyitva maradt portok a tőzfalon, sebezhetı verziójú internetes alkalmazások vagy operációs rendszerek. A sebezhetıségek azonosítása önmagában is fontos lehet. Például ha két szervezet összevonása esetén a két LAN-t is egyesíteni kell, szükség lehet annak tesztelésére, hogy az új LAN-ba nem lehet-e kívülrıl betörni. Ha ezt sikerül megtenni a behatolási tesztben, még az összevonás elıtt biztonságossá kell tenni a kapcsolatot, addig nem szabad egyesíteni a két hálózatot. Az IT biztonság külsı fél általi megerısítése céljából végeztetett behatolási teszt lehet önálló feladat és lehet egy általánosabb értékelési/igazolási eljárás egyik lépése is. Fontos megjegyezni, hogy a behatolási teszt csak egy adott idıpillanatban fennálló helyzetet tükröz, és ezért egy külsı fél által megerısített, igazolt biztonság szintrıl nem lehet a jövıre is érvényes következtetéseket levonni. A szervezeti és személyi infrastruktúra biztonságának javítása érdekében végzett behatolási tesztelés általában két területre összpontosít. Egyrészt a problémák észlelését és továbbítási eljárásait ellenırzi (incidens kezelés), a behatolási tesztelések hatókörének és/vagy agresszivitásának fokozatos növelésével. Másrészt az olyan social engineering technikák segítségével, mint például jelszavak kicsalása telefonon, fel lehet mérni a biztonsági tudatosság általános szintjét, a biztonság szabályzatok és a felhasználói nyilatkozatok hatásosságát. Egy informatikai rendszer értékelésén belül végrehajtott behatolás tesztelés célja az azonosított lehetséges sebezhetıségek kiaknázhatóságának megerısítése vagy megcáfolása (egy külsı fél által), vagyis a c) pontban meghatározott cél. Melléktermékként alkalmas az a) és b) célok elérésére is. A d) pontban meghatározottak azonban nem képezik részét egy mőszaki szempontú biztonsági értékelésnek, azok a szervezetet vizsgáló biztonsági auditok hatókörébe tartoznak. A behatolás tesztelésre is érvényes az értékelés egészére vonatkozó általános elvárás a megismételhetıségre. A behatolás tesztelés során biztosítani kell, hogy minden megállapítás feljegyezésre kerüljön, s ilyen módon a tesztek pontosan megismételhetık legyenek, eredményüktıl függetlenül. Az értékelésbıl származó összes korábbi elképzelését ebben a fázisban az értékelı teszt forgatókönyvekbe (szkriptek) építi be. Ez magában foglalja az STOE-ra vonatkozó nyilvánosan ismert sebezhetıségeket is. Azt is dokumentálni kell, hogy bizonyos sebezhetıségeket miért nem tesztelt az értékelı (pl. mert nem bizonyultak hozzáilleszthetınek az alkalmazáshoz, vagy mert kellı erıfeszítés után nem sikerült nyilvánosságra hozott teszt szkriptet szerezni futtatásra.


12


A behatolás tesztelés forrása alapvetıen a sebezhetıség vizsgálat, azon belül is az alábbiak: ― a tervek vizsgálata, ― a biztonsági tesztelés eredményeinek elemzése, ― a mőködési környezet kiértékelése. Közvetett módon azonban az értékelés összes fázisa hozzájárul a behatolás tesztelési tevékenységhez. Az értékelés során összegyőjtött elképzelések összeállítása elızze meg a behatolás tesztelést. Vannak olyan értékelık, akik teszt jegyzéket vezetnek az értékelés során felmerült ötleteik rögzítésére. A behatolás tesztelés elıtt a korábban összegyőjtött ötletek áttekintésével meghatározható, hogy mely ötletek a megalapozottak. Ezekbıl teszt scriptek készíthetık. Fontos, hogy minden elképzelés leírásra kerüljön az értékelés során, még akkor is, ha azokat végül elvetjük. 6.1.2.1.2.

A behatolás tesztelés típusai

A behatolás tesztelés 3 fı típusa az alábbi: ― Pozitív. (Azt bizonyítja, hogy a funkcionalitás mőködik. Ezeket a teszteket a biztonsági tesztelés feltehetıen lefedi, de végrehajthatók itt is kiegészítı tesztek.) ― Negatív. (Azt próbálja bizonyítani, hogy a funkcionalitás nem mőködik. Ezeket a teszteket is végre lehet hajtani a biztonsági tesztelés során. Magában foglalhatja a korlátoknak vagy a megengedett tartományon kívül esésnek a tesztelését, vagy bármely olyan szempontét, amelyet az értékelı ki tud gondolni az STOE-re vonatkozó ismeretei alapján.) ― Összetett tesztelés. (A funkcionalitás több vonatkozását egyszerre teszteli, illetve több funkciót egyszerre vizsgál. Egy példa erre annak ellenırzése, hogy lehetséges-e bejelentkezni egy rendszerbe, mielıtt a naplózási funkció mőködésbe lépne. Másik példa erre annak megfigyelése, hogy ha megváltoztatjuk a szerepkörünket, az új szerepkörünkben rendelkezünk-e további privilégiumokkal.) Egyéb tesztek is vannak, amelyek formálisan nem illenek a fenti kategóriák egyikébe sem. Példák erre a Z, , stb. Ezek a teszteket ki lehet alakítani negatív vagy összetett tesztként, minthogy megpróbálják aláaknázni az STOE funkcionalitását, de konkrétan meghatározott funkció célbavétele nélkül. 6.1.2.1.3.

A behatolás tesztelés tervezése

A tervezés a hatékony behatolás tesztelés legfontosabb szempontja. Ha nem tervezzük el, hogy milyen teszteket fogunk végrehajtani, nem lehetünk biztosak abban, hogy mindent leteszteltünk, vagy hogy mikor vagyunk készen. Egy másik fontos tényezı a sorrend, ahogyan a teszteket futtatjuk, minthogy ez hozzásegíthet a maximális eredmény eléréséhez a rendelkezésre álló idıtartam alatt.


13


Vannak értékelık, akik szeretnek formális szkripteket kialakítani, mielıtt elkezdenék a formális tesztelést, hogy be tudjanak fejezni minden szkriptet a tesztelési látogatás során. Ez különösen hasznos akkor, ha a helyszínen tesztelünk; ez tudomásunkra juttatja, hogy meddig jutottunk el a teszteléssel, így lehetséges a befejezés idejének a tervezése, és lehetıséget nyújt arra, hogy idıt takarítsunk meg a tesztek továbbfolytatásához. Az értékelı szervezet saját helyszínén folyó tesztelés esetén (ha megvalósítható) az STOE folyamatosan rendelkezésre áll, és a tesztelést végre lehet hajtani bármikor, amikor ötletek felmerülnek. Ez azt jelenti, hogy az ötletek kipróbálhatók és finomíthatók, mielıtt formálisan lefuttatnánk. Az „otthoni” tesztelés elınye, hogy az értékelık több idıt fordíthatnak a tesztelésre, mint amikor a tesztelés az integrálás/üzemeltetés helyszínén történik. Hátránya, hogy néha nehéz biztosítani, hogy a tesztelés formális konfiguráció ellenırzés mellett legyen végrehajtva. Az STOE konfigurációja módosulhat a tesztelés részeként, ekkor a behatolás tesztek nem az STOE „éles” verziójára hajtódnak végre. A behatolás tesztelésre elvárt, hogy a tesztelés felülvizsgált és engedélyezett scriptek szerint legyen végrehajtva, és az STOE konfigurációja ismert és feljegyzett legyen minden behatolás tesztelési munkaszakasz esetében. 6.1.2.1.4.

Kiegészítı tesztelés

A behatolás tesztelés alapos tervezése esetén is szükség lehet kiegészítı tesztelésre. A tervszerő behatolás tesztelés során - ahogyan elırehaladunk - több ötletünk is támadhat, például amikor váratlan eredményt kapunk, amely további vizsgálatokat igényel. Az ilyen teszteket is formálisan fel kell jegyezni, majd felül kell vizsgálni, de már csak az (adhoc) teszt lefutása után. Tudnunk kell, hogy mikor hagyjuk abba a behatolás tesztelést: amikor már csak annyi rendelkezésre álló idınk maradt, hogy leállítsuk a tesztelést és megírjuk a jelentést. Feljegyzéseket kell készítenünk, hogy biztosak lehessünk abban, hogy minden tesztelés megtörtént, és az esetlegesen feltárt problémák késıbb újra elıállíthatók legyenek. 6.1.2.1.5.

Viselkedés a rendszer integrátoraival és üzemeltetıivel

Amennyiben a behatolás tesztelésre a rendszer integrálásának vagy üzemeltetésének helyszínén kerül sor, különösen fontos figyelembe venni az alábbiakat. A behatolás tesztelés meglehetısen bonyolult szituációk kialakításával járhat, több biztonsági funkciót és paramétert is érinthet. Ezek együttesen nem biztonságos állapotba juttathatják az STOE-t. Nem szabad megfeledkezni arról, hogy a fejlesztık és az rendszer integrátorok jelentıs idıt fordítottak a komponensek és az STOE elıállítására, és az értékelı dolga munkájuk megerısítése vagy kijavítása. Arra például biztosan nincs szükségük, hogy derüljünk azon, ha a STOE összeomlik. Egy értékelınek nem csak a határozat hozatal során szükséges az objektivitásra törekednie, hanem kulturált viselkedés várható el tıle kiélezett


14


problémás helyzetekben, valamit az észrevételezési jelentések és egyéb jegyzıkönyvek megfogalmazásánál is. A megfelelı emberi kapcsolatok kialakítása a rendszer integrátorral nemcsak viselkedés kultúra és az objektivitás megırzésének kérdése. Az értékelınek azt is szem elıtt kell tartania, hogy egy helyszínen végrehajtott behatolás tesztelés során szüksége lehet a rendszer integrátor együttmőködésére, gyakorlati segítségére is. Másfelıl az értékelı a behatolás tesztelése és az eredmények jelentésbe foglalása során jogosan kívánhat meg bizonyos szintő visszavonultságot, elmélyülési lehetıséget. Különös figyelmet igényel az az eset, amikor a behatolás tesztelése egy „éles” szolgáltató rendszerben kerül sor. Ilyenkor a napközben végzett tesztelést a pozitív tesztelésre szükséges korlátozni, tekintetbe véve, hogy a rendszer tulajdonosnak szerzıdése lehet az ügyfelekkel a szolgáltatás szintjére vonatkozóan, tehát a normál üzemidı alatt nem maradhatnak szolgáltatás nélkül. A behatolás tesztelés végrehajtását követıen az STOE-t vissza kell állítani eredeti állapotába. 6.1.2.1.6.

Egy tipikus behatolás tesztelési terv tartalma

Egy tipikus behatolás tesztelési terv tartalma az alábbiakat: ― Teszt sorszám: hogy a teszt egyértelmően azonosítható legyen, ― Tárgy/téma: a teszt céljának összegzése (mit próbálunk tesztelni), ― A teszt eredete: honnan származik a teszt (dokumentált biztonsági funkciók, ismert sebezhetıségek), ― Kezdés/befejezés: mikor kezdıdött, és mikor fejezıdött be a teszt ― A teszt végrehajtója: aki futtatta a tesztet, ― A tesztelés ellenıre, jegyzıkönyvezıje: a teszt helyes végrehajtását ellenırzi személy, aki a jegyzıkönyvet alá is írja. ― Lépések: ezek lépésrıl lépésre részletezik, hogy mit kell megtenni a teszt végrehajtásához. A teszt lépések megkívánhatnak bizonyos alapfokú technikai ismereteket, de elegendıen részletesnek kell lenniük ahhoz, hogy biztosítva legyen, hogy ezeket végre lehessen hajtani, meg lehessen ismételni és az eredményeket újra elı lehessen állítani. ― Várt eredmények: a lépésekben megadott tevékenységektıl várható eredmények. ― Tényleges eredmények: azok a tényleges eredmények, amelyek a lépésekben megadott tevékenységek következtében keletkeztek. ― Végeredmény: a teszt kimenetele, megfelelt, nem felelt meg, nem meggyızı, megismétlendı. /Nem „megfelelt” végeredmény esetén meg lehet határozni egy másik futtatandó tesztet./ 6.1.2.2. A behatolás tesztelés jellemzése, általános forgatókönyve A behatolás tesztelés különbözı formái alkalmazhatók: ― Távoli (vagy külsı) behatolás tesztelés során az értékelı az Interneten keresztül végzi vizsgálatát. A hálózat külsı kapcsolati pontjait vizsgálva keres behatolási pontot,


15


biztonsági réseket, elsısorban a tőzfalakon és a DMZ-ben elhelyezett szervereken vagy routeren. ― Helyi (vagy belsı) behatolás tesztelés során az értékelı a helyi hálózat egy hosztján végzi vizsgálatát. Ennek során belsı „támadást” szimulál annak felderítése érdekében, hogy megkerülhetıek-e a hálózati hozzáférések korlátozásai, kivitelezhetı-e egy hamis megszemélyesítéses támadás. ― Fizikai hozzáférésen alapuló behatolás tesztelés során az értékelı vizsgálata arra terjed ki, hogy fizikai hozzáféréssel milyen adatokhoz lehet jutni, pl. telepíthetık-e kártékony programok CD, DVD, USB adathordozó behelyezésével. Egy más megközelítésben a behatolás tesztelés típusa attól függ, hogy a vizsgálatot végzı személy milyen információkkal rendelkezik a vizsgált rendszerrıl: ― Fekete dobozos behatolás tesztelésnél a vizsgálatot végzı személy semmilyen elızetes információval nem rendelkezik a rendszer infrastruktúrájáról és alkalmazásokról. ― Fehér dobozos behatolás tesztelésnél a vizsgálatot végzı személy minden információ birtokában van úgy, mint a rendszer adminisztrátora. ― Szürke dobozos behatolás tesztelésnél a vizsgálatot végzı személy egy szinten van a rendszer felhasználóival, célja a jogosultságok kijátszása. Egy rendszer behatolás tesztelésének lépései függnek a vizsgálat típusától (fekete, fehér, szürke). Természetesen a legkevesebb kiinduló információval rendelkezı vizsgálat tartalmazza a legtöbb lépést, mivel a vizsgálónak össze kell győjteni a kiinduló információkat a szimulált támadáshoz. Az alábbiak a fehér dobozos megközelítést követik, hiszen mindkét másik megközelítés ennek részét képezi. A szakirodalom egy része a következı fázisokat különíti el egy behatolás tesztelés során: a) Elıkészületek (E) aa) passzív és aktív felderítés ab) pásztázás (szkennelés) b) Kiaknázás (K) ba) hozzáférés bb) a hozzáférés megtartása c) Lezárás (L) ca) a nyomok elfedése Minthogy az értékelı által végzett behatolás tesztelés célja a rendszer sebezhetıségének vagy ezek hiányának kimutatása, az értékelık által alkalmazott forgatókönyvek a fenti lépések közül nem részletezik a hozzáférés megtartását és a nyomok elfedését. (Egy értékelı számára a sikeres hozzáférés már negatív végeredmény, s a nyomok eltüntetésére sem kell energiát fordítania.) A szőkebben a behatolás tesztelés folyamatára koncentráló megközelítés szerint a következı lépéseket kell követni: ― Információk kutatása a célrendszerrıl: Az internetrıl elérhetı számítógépekhez kell tartozzon egy hivatalos IP cím. Szabadon elérhetı adatbázisokban találni információkat arról, hogy milyen IP címek blokkolódnak a szervezetnél.


16


― A célrendszer által nyújtott szolgáltatások vizsgálata (szkennelés): A tesztelt számítógépeken port-szkennelést lehet végezni, a nyitott portok utalnak a hozzájuk tartozó alkalmazásokra. ― Rendszerek és alkalmazások azonosítása: A „fingerprinting” technika segítségével megszerezhetıek az operációs rendszerek és alkalmazások nevei és verziói. ― Sebezhetıségek kutatása: A győjtött információk segítségével hatékonyan lehet információt győjteni az operációs rendszerek és alkalmazások sebezhetıségeirıl. ― Sebezhetıségek kihasználása: A talált sebezhetıségek segítségével jogosulatlan hozzáférést lehet szerezni a rendszerhez vagy további támadást lehet elıkészíteni. 6.1.3. Egy behatolás tesztelési modell A BSI egy tanulmánya [A Penetration Testing Model - Study] az értékelık számára is jól használható modellt állít fel a behatolás tesztelésre. Az 1. ábra által bemutatott osztályozás ebbıl a tanulmányból való.

Behatolás teszt

Szempont:

1. Információs bázis

2. Agresszivitás

Fekete doboz

Passzív / szkennelés

3. Hatókör

Kiszámított

Óvatos

Korlátozott

Teljes

Hálózatalapú

6. Kiindulási pont

Egyéb kommunikációk

Agresszív

Fókuszált

Nyílt / elhíresztelt

Rejtett / óvatos

4. Megközelítés

5. Technika

Fehér doboz

Fizikai hozzáférés

Külsı

Social engineering

Belsı

Forrás - BSI: A Penetration Testing Model (Study)

1. ábra - A behatolás tesztelés lehetséges osztályai

Az 1. ábra bal oldalán a behatolási tesztek hat különbözı szempontja található, a jobb oldal pedig egy fa diagramon ábrázolja a tulajdonságok különbözı értékeit. Bár a különbözı szempontok amennyire csak lehet függetlenek egymástól, mégsem minden lehetséges kombináció vezet értelmes behatolási teszthez. Például egy agresszív teszt


17


általában nagyon gyorsan azonosítható, ezért általában nem ideális rejtett megközelítéssel együtt használni. Egy nyílt behatolási teszt sem megfelelı, ha például ennek során bizalmas információt kell megszerezni olyan alkalmazottaktól, akiket figyelmeztettek, hogy social engineering technikákat alkalmazhatnak rajtuk. A rendszer értékelı által végzett behatolási tesztelésre pedig egyéb korlátok is vonatkoznak, melyet az alábbiakban részletezünk. 6.1.3.1. 1. szempont: Információs bázis Információs bázis: Milyen kezdeti ismeretekkel bír a teszt végrehajtója a célhálózatról? Megkülönböztetünk fekete doboz tesztelést, ahol semmi belsı tudással nem rendelkezik a tesztelı, és fehér doboz tesztelést, ahol belsı információk is rendelkezésre állnak: ― A fekete doboz teszt valósághően szimulál egy internetes támadó által elkövetett támadást. A támadónak nyilvánosan hozzáférhetı adatbázisokban kutatnia kell a szükséges információk után, vagy kívülállóként vizsgálódnia kell. ― A fehér doboz teszt olyan támadást szimulál, amit egy (régebbi) alkalmazott vagy egy olyan külsıs követ el, aki részletes ismeretekkel rendelkezik bizonyos területekrıl. Ennek a tudásnak a mértéke a korlátozottól (ilyennel rendelkezhet egy alkalmazott, aki csak rövid ideig dolgozott a cégnél) egészen a rendszert mélyen ismerıig terjedhet (ilyen lehet egy külsı IT szolgáltató, aki a biztonsági rendszereket telepítette). Az értékelı elvileg mindkét típusú behatolási tesztelést végezheti. Ugyanakkor az értékelı számára általában minden fehér dobozos teszteléshez szükséges információ rendelkezésére áll, így a fekete dobozos megközelítést legfeljebb demonstrációs megfontolásokból, vagy egy feltárt sebezhetıséghez szükséges támadási képesség meghatározására használja. Kivételt képez az alap garanciacsomag, melynél az értékelı csak automatikus eszközökkel végrehajtott sebezhetıség elemzést végez. Ez esetben fekete dobozos behatolási tesztelést kell csak végrehajtania. 6.1.3.2. 2. szempont: Agresszivitás Agresszivitás: Milyen agresszív lehet a tesztelı a tesztelés alatt? Az agresszivitás négy szintjét határozza meg a tanulmány: ― A legalacsonyabb szinten – passzív - a tesztelési célokat csak passzívan lehet vizsgálni, vagyis a talált sebezhetıségeket nem szabad kihasználni. ― A második szinten – óvatos – az azonosított sebezhetıségeket csak akkor lehet kihasználni, ha a tesztelt rendszernek nem lehet baja. Például ilyen az ismert alap jelszavak kipróbálása vagy a hozzáférés kipróbálása könyvtárakhoz a web szerveren. ― A következı fokozatban - kiszámított – a tesztelı olyan sebezhetıségeket is kipróbálhat, amelyek a rendszer zavarához vezethetnek. Ilyen lehet például a jelszavak automatikus kipróbálása, vagy az ismert buffer túlcsordulásos hibák kihasználása a


18


pontosan azonosított rendszereken. Mielıtt a tesztelı ezeket megtenné, a tesztelınek figyelembe kell vennie milyen eséllyel lesz sikeres a támadás, és milyen súlyosak lehetnek a következmények. ― A legmagasabb szinten - agresszív – a tesztelı kipróbálja az összes lehetséges sebezhetıséget, pl. buffer overflow hibákat használ ki olyan rendszereken is, amelyek nincsen teljesen azonosítva, vagy a biztonsági rendszereket szándékos túlterheléssel deaktiválja (Denial of Service (DoS) támadások) A tesztelınek tisztában kell lennie azzal, hogy tesztelt rendszer mellett, a szomszédos rendszerekben vagy hálózati komponensekben is hibák történhetnek a tesztelés hatására. Az értékelınek elsısorban passzív és óvatos behatolási tesztelést kell alkalmaznia. Kivételes esetben alkalmazhatja a kiszámított variánst is, de csak teszt környezetben és a megfelelı helyreállítás lehetıségének ellenırzése után. Semmilyen körülmények között nem alkalmazhat agresszív behatolási tesztelést. 6.1.3.3. 3. szempont: Hatókör Hatókör: Melyik rendszereket kell tesztelni? A hatókör szempontjából az alábbi osztályok vannak: ― Fókuszált a behatolási teszt, ha csak egy meghatározott biztonsági tartományt, alrendszert vagy szolgáltatást kell tesztelni. Egy ilyen teszt természetesen csak a tesztelt rendszerekrıl szolgáltat információkat; nem ad általános információt az IT biztonságról. ― Korlátozott behatolási teszt esetén csak korlátozott számú alrendszert vagy szolgáltatást kell vizsgálni. Például minden rendszert a DMZ-ben, vagy a funkcionális egység részét képezı rendszereket. ― A teljes behatolási teszt az egész vizsgált rendszert érinti. Meg kell jegyezni, hogy még a teljes tesztben is bizonyos alrendszerek - például külsıleg hosztolt alrendszerek - esetén elıfordulhat, hogy nem lehetséges a tesztelés. Kezdeti értékelés esetén ajánlott egy teljes behatolási tesztelést elvégezni, biztosítva hogy nem maradt olyan biztonsági kibúvó, ami nem lett letesztelve. A behatolási teszthez szükséges idı közvetlenül függ a vizsgált rendszer hatókörétıl. A különbözı valós konfigurációkkal is egyedileg kell foglalkozni. Egy tervezett felülvizsgálati értékelés esetén érdemes a korlátozott behatolási tesztelést választani, biztosítva azt is, hogy a rendszeres idıközönként (pl. évente) megismételt felülvizsgálatok elıbb utóbb a teljes rendszert is lefedjék. Rendkívüli felülvizsgálati értékelés esetén a fókuszált behatolási tesztelés a javasolt, értelemszerően a rendszer módosított vagy bıvített részeire összpontosítva a vizsgálatot. 6.1.3.4. 4. szempont: Megközelítés Megközelítés: Mennyire legyen "látható" a csapat a tesztelés közben?


19


Ha az elsıdleges biztonsági rendszerek mellett másodlagos rendszereket – mint pl. IDS, szervezeti vagy személyi struktúra (pl. problématovábbítási eljárások) is tesztelni kell, a tesztelési megközelítést ehhez kell igazítani. ― Rejtett az a behatolási tesztelés, amely csak olyan módszereket alkalmaz, amelyek nem utalnak támadásra. ― Ha a rejtett megközelítés nem hoz eredményt, nyílt módszerek alkalmazásával fehér dobozos tesztet kell végezni, mint például port-szkennelés egy közvetlen kapcsolaton keresztül. Az értékelı elvileg mindkét típusú behatolási tesztelést végezheti. A másodlagos rendszereken és a létezı problématovábbítási eljárásokon végzett behatolási teszteknek - legalábbis kezdetben – rejtettnek kell lenniük. A nyílt módszerek alkalmazásánál a megrendelı alkalmazottai is részt vehetnek a tesztelésen. Ez különösen ajánlott a kritikusabb rendszerek esetén, mert ebben az esetben a tesztelık gyorsabban tudnak reagálni a felmerülı váratlan problémákra. 6.1.3.5. 5. szempont: Technika Technika: Milyen technikák használhatóak a tesztelésre? Egy hagyományos behatolási teszt esetén a rendszerek csak a hálózaton keresztül támadhatók. Ezek mellett használhatók fizikai támadások különbözı típusai és social engineering technikák is. ― A hálózat-alapú behatolási teszt a normál eljárás, és a tipikus hacker támadást szimulálja. A legtöbb IT hálózat jelenleg TCP/IP protokollt használ, ezért ezeket a teszteket IP alapú behatolási teszteknek is hívják. ― A TCP/IP hálózatokon kívül vannak más kommunikációs hálózatok, amelyeket támadásokban használhatnak. Ezek lehetnek a telefon és fax hálózatok, vezeték nélküli hálózatok a mobil kommunikációra, pl. az IEEE 802.1 1(b)-n alapuló hálózatok és a bluetooth technológia. ― Fizikai támadás. Manapság a biztonsági rendszerek (pl. tőzfalak, stb.) széles körben elterjedtek, és egy ilyen rendszer kialakítása általában olyan magas szintő biztonságot nyújt, hogy nagyon nehéz, ha nem lehetetlen egy ilyen rendszert eredményesen támadni. Gyakran könnyebb és gyorsabb megszerezni a kívánt vagy szükséges adatokat egy jelszóval nem védett munkaállomásból, ha sikerül bejutni az épületbe és/vagy a szerver szobába fizikai támadás útján.. ― Az ember gyakran a leggyengébb láncszem a biztonsági láncban, ezért a social engineering technikák, amelyek az emberek nem megfelelı biztonsági tudását és alacsony biztonság tudatosságát használják ki, gyakran sikeresek. Ezeket a teszteket egy általános biztonsági szabályzat bevezetése után érdemes elvégezni, így fel lehet mérni a megvalósítás és elfogadottság mértékét. A hamis feltételezések a biztonsági szabályzat vélt hatásosságáról gyakran vezetnek olyan biztonsági kockázatokhoz, amelyeket a helyzet helyes felmérése esetén, idejében mérsékelni lehetett volna. A rendszer mőszaki biztonságát értékelı az elsı két típusú behatolási tesztelést végezheti.


20


Semmilyen körülmények között nem alkalmazhat fizikai támadást, csak elméleti megfontolásokban veheti ezt figyelembe. A social engineering technikák alkalmazása pedig a szervezetet auditálók feladatát képezi, szintén nem a mőszaki értékelés feladata. 6.1.3.6. 6. szempont: Kiindulási pont Kiindulási pont: Honnan végezhetı el a behatolási teszt? A behatolási teszt kiindulási pontja, vagyis az a hely ahol a tesztelı a számítógépét a hálózatra csatlakoztatja, vagy ahonnan a támadási kísérletei kiindulnak, lehet a megrendelı hálózatán vagy épületén belül vagy kívül. ― A legtöbb támadást a hálózat az internet felıl kapja. A külsı behatolási teszt ezért megmutathatja és kiértékelheti egy ilyen támadás veszélyeit. ― Egy belsı behatolás teszt esetén a tesztelınek nem kell átjutnia a tőzfalon és beléptetı rendszereken, hogy hozzáférjen a belsı hálózathoz. Az értékelı mindkét típusú behatolási tesztelést végezheti. A külsı behatolási teszteléssel elsısorban a tőzfalakat, a DMZ biztonsági tartomány alrendszereit és a RAS kapcsolatokat kell vizsgálni ezekben a tesztekben. A belsı behatolási tesztelésnél az értékelınek nem kell átjutnia a tőzfalon és beléptetı rendszereken, hogy hozzáférjen a belsı hálózathoz. Ez is nagyon fontos eset, részben a belsı támadók lehetıségeit, részben egy esetleges sikeres külsı támadás következı lépéseit térképezi fel. 6.1.4. A behatolás tesztelés gyakorlati megközelítése A behatolás tesztelés tárgyalásánál (a külsı támadó megközelítését is jellemzı) alábbi sorrendet követjük: ― elıkészületek, általános hálózati vizsgálatok, ― az operációs rendszerek alapkonfigurációira irányuló vizsgálatok, ― web szerverek vizsgálata, ― webes alkalmazások vizsgálata, ― adatbázisok vizsgálata. 6.1.4.1. Elıkészületek (általános hálózati vizsgálatok) 6.1.4.1.1.

Passzív és aktív felderítés

Ennek az elıkészületi lépésnek a során az értékelı (támadó) minden elérhetı, a késıbbiekben hasznosítható információt begyőjt a vizsgálandó rendszerrıl. Az információkat összegezve pontos kép alkotható az alábbi területekrıl: ― Internet: IP címek, tartományok, fıbb rendszerelemek, átjárók, stb., ― Intranet: mint az „Internet” esetében csak kívülrıl nem elérhetı elemeket is tartalmaz, ― Távoli hozzáférés: távoli hozzáférési pontok (Dial-UP, VPN),


21


― Egyéb információk: minden más összegyőjtött információ az alkalmazottakról, vezetıségrıl stb. Ennek keretében (az úgynevezett „Enumeration” technika alkalmazásával) összegyőjti a rendszerben található felhasználói neveket és az ezekhez kapcsolódó adatokat. Ez azért lehetséges, mert különbözı protokollok és szolgáltatások kihasználásával a Windows és Unix rendszerek „kiadják” a felhasználói adatokat. Az így megszerzett felhasználói adatok birtokában egy támadó a késıbbiekben a felhasználók megszemélyesítésével hozzáférhet a rendszer további elemeihez. A Windows rendszerek alábbi szolgáltatásai érintettek a fenti technika alkalmazhatóságában: ― TCP 53 DNS zone transfer ― TCP 135 Microsoft RPC Endpoint Mapper ― UDP 137 NetBIOS Name Service (NBNS) ― TCP 139 NetBIOS session service (SMB over NetBIOS) ― TCP 445 SMB over TCP (Direct Host) ― UDP 161 Simple Network Management Protocol (SNMP) ― TCP/UDP 389 Lightweight Directory Access Protocol (LDAP) ― TCP/UDP 3268 Global Catalog Service ― TCP 3389 Terminal Services A Linux rendszerek alábbi szolgáltatásai érintettek a fenti technika alkalmazhatóságában: ― TCP 445 SMB over TCP (Direct Host) ― TCP/UDP 389 Lightweight Directory Access Protocol (LDAP) 6.1.4.1.2.

Pásztázás

Ennek az elıkészületi lépésnek a célja, hogy az értékelı (támadó) egy adott rendszerben (IPtartományban) behatárolja az „élı” hosztokat, valamint megvizsgálja, hogy ezeken milyen szolgáltatások érhetık el. A pásztázás (szkennelés) célja az alábbi lehet: ― élı hosztok felderítése, ― elérhetı szolgáltatások (nyitott portok) felderítése, ― a hoszton futó operációs rendszer típusának megállapítása, ― IP címek felderítése. Az élı hosztok felderítésének lehetséges módszerei: ― Ping sweep: ICMP csomagok formájában „ping” küldése a hoszt felé, majd a válasz figyelése. Általában nem hoz megbízható eredményt, mert a tőzfalak kiszőrik az ilyen típusú ICMP csomagokat és nem válaszolnak rá. Intranet esetén sokkal megbízhatóbb eredményt hoz az ARP csomagokra épülı felderítés, mert az ARP protokoll elengedhetetlen kelléke az üzenetszórásos Ethernet hálózatnak. ― Port scan: Port felderítés során a vizsgált rendszer nyitott és zárt portjait deríthetık fel, amely egyértelmően elárulja a vizsgált hoszt funkcióját. A nyitott portok szolgáltatásokhoz kapcsolhatók, amelyek a szabványos portok listájából azonosíthatók. ― Network scan: Az elérhetı hosztok megkeresése egy nagy hálózatban.


22


― Vulnerability scan: Automatikus biztonsági rés felderítése, ismert biztonsági hibák alapján. Élı hosztok felderítésére alkalmazhatók az alábbi szkennelı programok: ― Angry IP: Windows-on használható, képes felderíteni az IP-tartományt, kikeresni az élı hoszt nevét és MAC címét. ― HPING: Windows-on használható TCP/UDP scanner. Az elérhetı szolgáltatások (nyitott portok) felderítésére alkalmazott fı technika: ― Banner grabbing: a pásztázást végzı (szkennelı) szoftver egy adott portra történı sikeres csatlakozáskor beolvassa a szolgáltatás által küldött adatokat, s ebbıl számos információt kigyőjt. Például web szerver esetén ezzel a technikával kideríthetı a futtató operációs rendszer típusa, a szerver szoftver típusa és az esetleg betöltött modulok verziója is. Nyitott portok felderítésére alkalmazhatók az alábbi szkennelı programok: ― Nmap: Windows és Unix rendszereken is fut, ingyenes, a legnagyobb tudással rendelkezı port-szkenner, ismeri az összes port-szkennelési technikát, képes nagy hálózatok gyors felderítésére. Parancssoros, de létezik hozzá grafikus felhasználói interfész (GUI). ― SuperScan: Windows-on futó gyors, grafikus és parancssoros interfésszel rendelkezı, ingyenes, különbözı formátumokba naplózó szkenner. A távoli hoszton futó operációs rendszer típusának megállapításának módszerei: ― a szkennelı program a banner grabbing technikát alkalmazza, ― a szkennelı program speciális TCP/IP csomagokat küld ki, majd kihasználva, hogy az egyes operációs rendszerek másként kezelik ezeket, a kapott válaszok alapján pontosan behatárolja a távoli operációs rendszert. Az operációs rendszer típusának megállapítására alkalmazható szkennelı program: ― HPING IP címek felderítésére alkalmazható szkennelı program: ― Angry IP 6.1.4.1.3.

Null session

A Windows rendszerek egyik komoly gyengesége, hogy a CIFS/SMB protokoll hitelesítés nélkül is lehetıvé teszi a rendszerhez csatlakozást. (Ráadásul a Windows Server 2003 és 2008 alapértelmezésében is elérhetı.) Csatlakozás után a felhasználókról, a megosztásokról és a registry kulcsokról információk szerezhetık. Null Session kihasználására alkalmazható információgyőjtı alkalmazás: ― winfo.exe. A winfo.exe egy parancssori alkalmazás, amely a paraméterként kapott szerverhez csatlakozik és a következı információkhoz juttatja a használóját: ― System Information, ― Domain Information,


23


Password Policy, Lockout Policy, Logged in Users, User Accounts (password age, privilege level, home directory, last logon, failed logins, full name), ― Workstation / Interdomain / Server Trust Accounts, ― Shares. ― ― ― ―

A fenti listából látható, hogy a jelszavakon kívül szinte mindent elárul magáról a rendszer. Ezzel az eszközzel könnyen megállapítható, hogy melyik felhasználónak van rendszergazdai jogosultsága (gyakran jogosulatlanul). 6.1.4.1.4.

Megosztások

Alaptelepítésben a Windows rendszerek megosztják az összes partíciójukat (c$, d$,…), távoli adminisztrációs célokkal. Ezeket távolról fel lehet csatolni rendszergazdai jogosultsággal, vagyis local admin illetve domain admin joggal. Sikeres felcsatolás után távolról a partíció teljes tartalma hozzáférhetı, írható, olvasható. Ilyen esetben a felcsatolás feltétele egy helyi adminisztrátori jelszó ismerete. Ez gyakran azon keresztül is megismerhetı, hogy egyes felhasználók (gyakran nem is tudatosan) adminisztrátori joggal használják a gépüket, s az ilyen felhasználók hajlamosak „gyenge” jelszavakat használni. Domain admin jogosultság megszerzését pedig a már ismertetett null session szolgáltatáson keresztül elérhetı kiinduló információk alapján lehet megpróbálni. Amennyiben a felhasználóknak megengedett megosztásokat létrehozni vagy létezı megosztásokba fájlokat másolni, akkor számítani lehet arra is, hogy tudatlanságból vagy felelıtlenségbıl érzékeny adatokat is megosztanak. Ezáltal egy megszemélyesített felhasználón keresztül más felhasználók érzékeny adatai is megismerhetıkké válnak. 6.1.4.2. Az operációs rendszerek alapkonfigurációira irányuló vizsgálatok A telepített operációs rendszerek és szolgáltatásaik biztonságának növelésére ajánlások, biztonsági ellenırzı listák (security checklist) léteznek, melynek használata feltétlenül javasolt. Ezek lényege az alábbi két ellentétes szempont figyelembe vétele: ― az operációs rendszerek alapértelmezéső telepítése a biztonság szempontjából hiányos, ezért kiegészítésre, megerısítésre szorul, ― az operációs rendszerek alapértelmezéső telepítése számos olyan tulajdonságot és szolgáltatást biztosít, mely a biztonságra kifejezetten veszélyes, ezért ezek (hacsak a funkcionalitás oldaláról külön nem indokolható feltétlen szükségességük) eltávolítandók, korlátozandók, kikapcsolandók.


24


6.1.4.2.1.

Windows rendszerek

Windows rendszerek esetén az alábbi mértékadó dokumentum tartalmaz hasznos ötleteket: http://www.sans.org/score/checklists/Win2K_XP_Checklist.pdf 6.1.4.2.2.

Linux rendszerek

Linux rendszerek esetén például a Sans féle „Linux Security Checklist” írás tartalmaz hasznos javaslatokat a biztonság növelésére. http://www.sans.org/score/checklists/linuxchecklist.pdf 6.1.4.3. Web szerverek vizsgálata A web szerverek által nyújtott szolgáltatások HTTP és SSL-el védett HTTP protokollon (HTTPS) érhetık el, rendszerint a 80-as és 443-as porton. Egy teljeskörő web szerver vizsgálat a következı lépésekbıl áll: 1. lépés: A web szerver felderítése (fingerprinting), 2. lépés: Proxy funkciók felderítése a hálózatban, 3. lépés: A virtuális hosztok felderítése a szerveren, 4. lépés: Az alrendszerek és a betöltött modulok felderítése a virtuális hosztokon, 5. lépés: A web szerver támadása. 6.1.4.3.1.

1. lépés: A web szerver felderítése

Ez történhet manuális módszerrel, a HTTP HEAD kéréssel: telnet www.trustmatta.com 80 Trying 62.232.8.1... Connected to www.trustmatta.com. Escape character is '^]'. kérés: HEAD / HTTP/1.0 válasz: HTTP/1.1 200 OK válasz: Date: Mon, 26 May 2003 14:28:50 GMT válasz: Server: Apache/1.3.27 (Unix) Debian GNU/Linux PHP/4.3.2 válasz: Connection: close válasz: Content-Type: text/html; charset=iso-8859-1 A szerver válaszából látható a webszerver típusa (Apache), verziója (1.3.27), a futtató operációs rendszer (Debian) és a betöltött szerveroldali nyelv típusa, verziója (PHP/4.3.2). A web szerver felderítése történhet automatikus módszerrel is. Számos célszoftver érhetı el csak erre a funkcióra, a nagyobb biztonsági tesztelı alkalmazások is képesek erre a vizsgálatra. A httpprint nevő alkalmazás egy web szerver


25


fingerprinting eszköz, amely gyorsan beazonosítja a vizsgált hálózatban található web szervereket és megjeleníti az azokról összegyőjthetı információkat. Ingyenesen letölthetı és használható windows és linux rendszereken. 6.1.4.3.2.

2. lépés: Proxy funkciók felderítése a hálózatban

A proxy funkciókat is hasonló módszerekkel lehet felderíteni mint a web szolgáltatásokat. A manuális módszer esetén a kapcsolat kiépülése után http proxy kéréseket kell kiadni. Az 1. lépésben leírt HTTP HEAD kérés most is változatlanul alkalmazható. GET esetében pedig: kérés: GET http://www.akarmi.com/akarmi.html. HTTP/1.1 kérés: Host: www.akarmi.com válasz: HTTP/1.1 200 OK válasz: Date: Mon, 26 May 2003 14:28:50 GMT válasz: Server: Apache/1.3.27 (Unix) Debian GNU/Linux PHP/4.3.2 válasz: Connection: close válasz: Content-Type: text/html; charset=iso-8859-1 Automatikus proxy tesztelı alkalmazásra egy hatékony alkalmazás a pxytest, amely Perl nyelven íródott és képes http CONNECT és POST típusú tesztelésre Socks 4 és 5 verziójú szervereken is. /A proxy funkció felderítésére azért van szükség, mert lehetséges, hogy csak proxy-n keresztül érhetjük el az internetet vagy egy webes alkalmazást./ 6.1.4.3.3.

3. lépés: A virtuális hosztok felderítése a szerveren

A virtuális hosztok (vagyis több egymástól logikailag elkülönülı webtartalom egy webszerveren) felderítése történhet manuálisan, amennyiben a web szerver beállításaihoz hozzáférünk. A felderítés történhet távolról DNS lekérdezéssel és SSL tanúsítványok vizsgálatával is. Ilyen aktív felderítésre képes a Wikto nevő alkalmazás, amely a szerver pásztázása közben felderíti a virtuális hosztokat. 6.1.4.3.4.

4. lépés: Alrendszerek és betöltött modulok felderítése

A web szerverek vizsgálatának talán legfontosabb része az alrendszerek, betöltött modulok vizsgálata, mert leggyakrabban ezek tartalmaznak kritikus hibákat, vagy rosszul bekonfigurált funkciókat. Általános modulok a következık lehetnek: ― HTTP 1.0 methods ― HTTP 1.1 methods


26


― Web Distributed Authoring and Versioning (WebDAV) ― PHP ― Basic authentication mechanisms A Microsoft IIS web szerver esetén a következı modulok is elıfordulhatnak: ― IIS sample and administrative scripts ― ASP and ASP.NET ― ISAPI extensions ― Proprietary WebDAV extensions ― Microsoft FrontPage ― Windows Media Services ― Outlook Web Access (OWA) ― RPC over HTTP support ― Enhanced authentication mechanisms (NTLM and Negotiate) Az Apache web szerveren esetén a következı modulok is elıfordulhatnak: ― OpenSSL ― Apache modules (mod_perl, mod_ssl, mod_security, mod_proxy, mod_rewrite) 6.1.4.3.5.

5. lépés: A web szerver támadása

A korábbi lépések eredményeinek ismeretében már meg lehet kísérelni a web szerver támadását, az alábbi módszerekkel: ― az ismert sebezhetıségek (biztonsági rések) meglétének vizsgálata a web szerveren és a betöltött modulokon, ― a web szerveren található fájl és könyvtárszerkezet felderítése (melynek segítségével olyan szerver oldali konfigurációs fájlokhoz és adatokhoz is hozzáférhetünk, amelyek a web szerver alatt vannak, de nem akarták azokat a külvilággal megosztani, nincs rá hivatkozás a weboldalon), ― a web szerverhez való hozzáférésre alkalmazott hitelesítési mechanizmusok felderítése és közvetlen támadása (feltörése). A modulok felderítése és vizsgálata rendszerint automatikus eszközökkel zajlik. A web szerverek ismert sebezhetıségeinek meghatározására javasolt két jól használható alkalmazás a Nikto és N-Stalker, amelyek a leggyakoribb hibákat képesek megtalálni a vizsgált szerveren. A web szerveren található fájl és könyvtárszerkezet felderítése a következı módszerekkel történhet: ― tippeléssel, ― HTML forrás elemzésével. A hitelesítési mechanizmusok felderítése: A web szerverek hozzáférés védelmére legtöbbször a HTTP BASIC hitelesítést alkalmazzák. Ez a hitelesítési eljárás a (felhasználói név, jelszó) párost BASE64 (triviálisan dekódolható) kódolással küldi a szerver felé. Ez egyrészt a hálózati forgalomból nagyon könnyen kideríthetı, másrészt nagy eséllyel szótáras vagy teljes kipróbáláson alapuló támadással sikeresen megtörhetı. Erre a célra használható alkalmazások a THC-HYDRA és a BRUTUS.


27


6.1.4.4. Webes alkalmazások vizsgálata Miután felmértük a web szerver biztonságát, érdemes az azon futó web alkalmazást is alaposan megvizsgálni. A vizsgálat történhet a szerveroldali kódok forrásának vizsgálatával, a tervdokumentációk alapján, vagy mőködés közben távoli kliensen keresztül. A forráskód és a tervdokumentációk vizsgálatára csak a webes alkalmazás (mint informatikai termék) független értékelése és tanúsítása során kerülhet sor. Ez meghaladja egy informatikai rendszer vizsgálatának lehetıségeit, így annak gyakorlati megközelítést alkalmazó behatolás tesztelésének lehetıségeit is. Ezért a továbbiak a mőködés közbeni vizsgálatra vonatkoznak. Webes alkalmazások fejlesztésére és kiszolgálására számos technológia és rendszer van. A hazai informatikai rendszerekben (köztük a közigazgatási szervek rendszereiben is) ezek közül az alábbiak a legelterjedtebbek: ― Microsoft ASP.NET, ― Sun JSP, ― PHP. Webes alkalmazások mőködésekor az alábbi 3 réteg különböztethetı meg: ― megjelenítési réteg (HTML formátum, a kliensnél jelenik meg), ― alkalmazási réteg (szerveroldali technológia /PHP, ASP, stb./, szerveren fut), ― adat réteg (adatbázis mőveletek). A vizsgálat elsı lépése, hogy feltérképezzük, hogy a webes alkalmazás milyen technológiát használ (PHP, ASP.NET, JPS) és megértsük mőködését és logikáját. Eközben ki kell deríteni azt is, hogy mőködése során használ-e adatbázisszervert, vagy csak fájlokat szolgál ki. Ebben a fázisban hasznos eszköz lehet a Paros vagy a Wikto. A Paros képes mélyebb szintő HTTP vizsgálatra és kigyőjti a mőködés során elıforduló SessionID-t és egyéb változókat is. A Wikto csak a technológiát képes megállapítani. A feltérképezés a következı mőveletekbıl áll: ― a HTML forrás vizsgálata, ― a szerver oldali fájlok kiterjesztésének vizsgálata, ― a session azonosító feltérképezése, ― a háttér adatbázis feltérképezése. 6.1.4.4.1.

A HTML forrás vizsgálata

A HTML forrás vizsgálatához hasznos eszköz a wget és a grep párosítása, mert ezekkel az eszközökkel gyorsan ki lehet győjteni a hidden mezıket és a HTML megjegyzéseket. (Mindkettı Windows és Linux rendszerekre egyaránt használható, és ingyenesen elérhetı.) Windows-os rendszerek esetén a Sam Spade is alkalmazható, mely egy olyan automatikus kiértékelı eszköz, amely minden használható információt kigyőjt a HTML forrásaiból. Gyakran a HTML-be ágyazott linkekbıl és URL-ekbıl kideríthetı, hogy milyen szerver oldali technológiát használnak.


28


6.1.4.4.2.

A szerver oldali fájlok kiterjesztésének vizsgálata

A szerver oldali fájlok kiterjesztése is utal a technológiára, sıt gyakran az alkalmazott platformra is, ahogyan azt a 2. táblázat mutatja. 2. táblázat – A fájl kiterjesztés, a technológia és a platform kapcsolata Fájl kiterjesztés(ek) ASP ASPX, ASMX

Technológia Microsoft Active Server Pages (ASP) Microsoft ASP.NET

CFM, CFML

Adobe ColdFusion

DO JSP

IBM WebSphere Sun Java Server Pages (JSP)

NSF PHP, PHP3, PHP4,PHP5 PL, PHTML, PM

IBM Lotus Domino PHP script

6.1.4.4.3.

Perl CGI script

Alkalmazás szerver platform Microsoft IIS Microsoft IIS 5.0 és késıbbi (.NET Framework-t használó) Általános, bár gyakran a Microsoft IIS-hez kapcsolódik. IBM WebSphere Application Server Több Unix-alapú webes alkalmazáshoz kapcsolódik (Apache Tomcat, BEA WebLogic, Sun Java System Application Server, Oracle Application Server). IBM Lotus Domino Általános, bár gyakran az Apache web szerverekhez kapcsolódik. Általános, bár gyakran Unix alapú.

A session azonosító feltérképezése

A session azonosítót legtöbbször cookie formájában állítják be a kliensek. Ez az azonosító is gyakran utal a szerver oldali kiterjesztésre. A 3. táblázat néhány session azonosítót és az ezekhez kapcsolódó webes alkalmazás szervert adja meg. 3. táblázat - Session azonosítók és a kapcsolódó webes alkalmazás szerverek Session ID változó név ASPSESSIONID ASP.NET_SessionId CFID and CFTOKEN JROUTE JSESSIONID

PHPSESSID WebLogicSession

6.1.4.4.4.

Webes alkalmazás szerver (standard ASP scriptet használó) Microsoft IIS (.NET Framework-t és ASP.NET-t használó) Microsoft IIS Adobe ColdFusion Sun Java System Application Server Különbözı JSP motort használó szerverek, köztük: Apache Tomcat, IBM WebSphere Application Server, és Caucho Resin (a session ID érték formájából a konkrét motorra is következtetni lehet) PHP BEA WebLogic

A háttér adatbázis feltérképezése

A webes alkalmazások gyakran használnak adatbázis lekérdezéseket, amelyeket a klienstıl érkezı paraméterekkel lehet befolyásolni. Ha találunk ilyen manipulálható beviteli értéket, a kapott szerver válaszából (hibajelentés) jó eséllyel kideríthetı a háttér adatbázis típusa, verziója.


29


Microsoft OLE DB Provider for ODBC Drivers error '80040e14' [Microsoft][ODBC SQL Server Driver][SQL Server]Unclosed quotation mark before the character string ''. /target/target.asp, line 113 A fenti hiba jelentés úgy született, hogy az URL paramétereket nem várt karakterekkel (") módosítottuk. A hiba jelentésbıl látható, hogy a szerver ASP technológiát használ és MsSQL adatbázis szervert. Miután feltérképeztük, hogy a webes alkalmazás milyen technológiát használ (közte azt is, hogy milyen háttér adatbázisra épül) rátérhetünk az adott technológia sebezhetıségeinek kihasználására. /Az egyes biztonsági rések, helytelen konfigurációkból adódó problémák technológiához köthetık. A profi automatikus eszközök (pl. Acunetix Vuln. Scanner) automatikusan felismerik a technológiát és ismerik a legtöbbet, de az egyszerőbb eszközök csak egy-egy sebezhetıség feltárására szolgálnak. Ezért már az alkalmazandó eszköz megválasztásához ismerni kell a technológiát./ 6.1.4.4.5.

Webes alkalmazások sebezhetıségei (biztonsági rései)

A biztonsági rések vizsgálatánál célszerő figyelemmel kísérni a leggyakrabban bekövetkezı webes támadási technológiákat. Az alábbi forrás szerint meghatározza a 10 leggyakoribb sebezhetıséget: http://www.owasp.org/index.php/Top_10_2007 A 4. táblázat a 10 leggyakoribb sebezhetıséget adja meg. 4. táblázat – A 10 leggyakoribb sebezhetıség 1

Cross Site Scripting (XSS)

2

Injection Flaws

3

Malicious File Execution

4

Insecure Direct Object Reference

5

Cross Site Request Forgery (CSRF)

XSS hiba akkor lép fel, amikor a szerveroldali alkalmazás úgy küld adatokat a kliens böngészıjének, hogy elıtte az érkezı input adatokat nem ellenırizte le. Ilyen esetekben a támadó képes eltéríteni az áldozat böngészıjét, megváltoztatni a web szerver nyitó oldalát (index.html), vagy trójait telepíteni. Beszúrásos támadás legtöbbször SQL parancsokban történik. Ez a hiba akkor lép föl, amikor a webes alkalmazás ellenırizetlenül beilleszti az SQL parancsba a klienstıl érkezı adatot. A szerveroldali kód távoli kódrészletet (fájlt) futtat le, mert a mőködése során nem ellenırzi megfelelıen a klienstıl érkezı adatokat, amelyek befolyásolják a mőködését. Távoli kód betöltést lehet végrehajtani PHP, XML és minden más formátumban, amelyek fájlneveket fogadnak a klienstıl. Direkt objektum hozzáférés akkor következik be, amikor a webtartalom fájl, könyvtár vagy adatbázis rekordra hivatkozik egy linken vagy őrlap mezın keresztül. A támadó a link vagy az őrlap mezı manipulálásával jogosulatlan tartalmakhoz férhet hozzá. CSRF támadáskor a támadó az áldozat hitelesített állapotát használja ki, hogy kártékony tevékenységet tegyen.


30


6

7

8

9 10

Information Leakage and Improper Error Handling Broken Authentication and Session Management Insecure Cryptographic Storage Insecure Communications Failure to Restrict URL Access

Az alkalmazás érzékeny információkat árul el a mőködésérıl, belsı struktúrájáról, háttér adatbázisáról. A támadó kihasználhatja ezeket az adatokat további támadások kivitelezéséhez. A felhasználói azonosítók és a session azonosítók sokszor nem megfelelıen védettek, ami a támadónak hamis megszemélyesítésre ad lehetıséget.

Webes alkalmazások gyakran használnak kriptográfiai eszközöket adataik védelmére, ám ezek gyakran feltörhetık, kijátszhatók. A kódolatlan kommunikáció a kliens és a szerver között gyakran jelszavak ellopását, az alkalmazás kijátszását eredményezi. Az alkalmazás írói gyakran védik a rendszer érzékeny részét oly módon, hogy a védendı (adminisztrációs) részekre mutató hivatkozásokat elrejtik. A támadó kellı információval, tippeléssel megtalálhatja ezeket a rejtett funkciókat.

6.1.4.5. Adatbázisok vizsgálata Az adatbázisok az informatikai rendszerek, ezen belül a webes szolgáltatások elengedhetetlen részét alkotják. Mivel a háttérben kiszolgáló funkciót ellátó adatbázisszervereken értékes információk találhatók, ezért az adatbázisszerverek a támadások gyakori célpontjai. Ezért a rendszer értékelésnek, ezen belül a behatolás tesztelésnek ki kell térnie az adatbázisok vizsgálatára is. A legtöbb hazai szervezet (köztük a közigazgatási szervek is) informatikai rendszerei SQL szervereket tartalmaznak. A legismertebb és leggyakrabban alkalmazott SQL szerverek az alábbiak: ― Microsoft SQL Server (MsSQL), ― Oracle, ― MySQL. Az 5. táblázat olyan portokat ad meg, amelyeken ezek általában megtalálhatók. 5. táblázat – Gyakori SQL szerverekhez kapcsolódó portok ms-sql ms-sql-ssrs ms-sql-hidden oracle-tns oracle-tns-alt oracle-tns-alt mysql

6.1.4.5.1.

1433/tcp 1434/udp 2433/tcp 1521/tcp 1526/tcp 1541/tcp 3306/tcp

Microsoft SQL server (MsSQL)

Az MsSQL szerverrel 3 módon lehet kapcsolatot kiépíteni: ― TCP/IP–n keresztül, alaptelepítésben az 1433-as porton, ― Microsoft RPC-n keresztül, ― Name Pipe-on keresztül.


31


Az MsSQL felderítéséhez, vizsgálatához a következı eszközök használhatók: ― SQLPing, amelynek segítségével ki lehet deríteni a szerver szoftver verziószámát és a kiszolgáló példány nevét. A kiderített verziószám többek között elárulja a szoftver aktuális frissítési állapotát, és meg lehet tudni belıle, hogy az alaptelepítés esetén mi az alapértelmezett felhasználó. ― MetaCoretex egy java-ban írt SQL szervereket vizsgáló szkenner, amely képes MsSQL, MySQL és Oracle adatbázisok felderítésére, vizsgálatára. ― SQLBF, amely az MsSQL hitelesítését tesztelı alkalmazás, felhasználónév és jelszó fájl alapján próbál meg bejelentkezni az adatbázis szerverre. Az MsSQL szerver adminisztrátori jogosultságú felhasználója az „sa”, amely alaptelepítésben jelszó nélkül tud bejelentkezni egészen az SQL Server 2003 verzióig, amelyben, majd a késıbbi verziókban már nem engedik meg a jelszó nélküli bejelentkezést. 6.1.4.5.2.

Oracle szerver

Oracle esetén TNS (Transparent Network Substrate) protokollon keresztül lehet csatlakozni a szerveren hallgató TNS listener szolgáltatáshoz. Ez a szolgáltatás alaptelepítés esetén az 1521 porton található. A TNS listener szolgáltatáshoz alaptelepítés esetén hitelesítés nélkül is lehet csatlakozni és parancsokat futtatni az adatbázisrendszeren kívüli környezetben is. A következı eszköz áll erre rendelkezésre: ― Tnscmd.pl, amely az Oracle TNS szolgáltatásával kommunikálni képes perl szkript. A Tnscmd.pl képes „ping” parancsot futtatni, amelynek a válaszából kideríthetı az Oracle SQL szerver szoftver verziószáma, s ez utalhat az ismert, kihasználható sebezhetıségekre. A tnscmd.pl program segítségével további parancsok is futtathatók: ― Ping: ping küldése a TNS listener szolgáltatásnak, ― Version: visszaadja a TNS listener verzióját és a futtató környezetrıl információkat, ― Status: a TNS státuszát és változóit adja vissza, ― Debug: debugging információkat ad vissza, ― Reload: újratölti a konfigurációs fájlokat, ― Services: szolgáltatás információkat ad vissza, ― Stop: Leállítja a TNS szolgáltatást. A már említett MetaCoretex alkalmazás az Oracle esetén is képes a jelszó próbálgatásos támadásra, mivel az Oracle alaptelepítése után is alapértelmezett (felhasználó, jelszó) párok jönnek létre: (system, manager) és (sys, change_on_install). Az alapértelmezett (felhasználó, jelszó) párok listája több száz termékre elérhetı a következı helyen el: http://www.phenoelit.de/dpl/dpl.html. 6.1.4.5.3.

MySQL szerver

A MySQL szerver alaptelepítésben a 3306 TCP porton érhetı el. Parancssoros és grafikus kliensekkel lehet kapcsolódni a szolgáltatáshoz. A MySQL szerver verziószáma itt nagyon


32


egyszerően kideríthetı: telnet-tel kell kapcsolódni a szerver 3306 portjára és a visszaadott válaszban megtalálható a verziószám. A MySQL alaptelepítésekor létrejön egy saját „root” felhasználó, amelynek a jelszava üres. További veszélyforrás lehet, ha a webes alkalmazások root felhasználóval kapcsolódnak az adatbázishoz, mert ennek jelszava gyakran visszakereshetı a konfigurációs állományokból. Mysql rendszerek vizsgálatához a következı eszközök használhatók: ― a már ajánlott MetaCoreTex, valamint ― a finger_mysql. Mindkét eszközzel a jelszó teljes kipróbálásán alapuló támadást (brute-force) is lehet végezni. Az SQL szerverek biztonságával kapcsolatos hasznos publikációkat és eszközöket találunk a következı oldalakon is: http://www.sqlsecurity.com, http://www.cgisecurity.com 6.1.5. A legjobban használható értékelési eszközök Az értékelık biztonsági tesztelı, behatolás tesztelı és sebezhetıség elemzı munkájukhoz számos automatizált mőködést biztosító szoftvert használhatnak fel. Ebben az alfejezetben áttekintjük a legjobban használhatókat. Az alábbi eszközök forrása: http://www.sectools.org A honlapot Gordon Lyon szerkeszti, aki tudományos kutató, számos publikáció szerzıje, és gyakorló hacker (saját állítása szerint a „jobbik” fajta). Legfrissebb összeállítása egy 2006-os, több ezer szakértı felhasználó véleményének felmérésén alapul, s a 100 legjobban használhat eszköz leírását tartalmazza. A szerzı az eszközöket kategorizálta (exploit framework, IDS, information gathering, IPS, password recovery, patch management, penetration tester, port scanner, scanner, sniffer, traffic analyzer, vulnerability scanner), röviden jellemezte és kiegészítı információkkal látta el. A 6. – 24. táblázatok a fenti lista rendszer értékelık által legjobban használható elemeit (elsısorban az ingyenesen elérhetı, jelen dokumentum készítıi által a gyakorlatban is kipróbált eszközöket) ismertetik. 6. táblázat - Nessus Nessus Részletek Kategória Operációs rendszer

http://www.nessus.org vulnerability scanner Windows, Linux


33


Nessus Leírás

A Nessus a legkedveltebb nyílt forráskódú sebezhetıségi szkenner. Kliens-szerver architektúrája lehetıvé teszi nagy rendszerek, gyors, hatékony felmérését. Folyamatosan bıvülı biztonsági rés adatbázisa már több mint 20000 plugint tartalmaz. A nessus szkenner ingyenesen letölthetı, azonban a biztonsági rés adatbázis frissítése csak otthoni felhasználóknak (HomeFeed) ingyenes, vállalati alkalmazásra a „ProfessionalFeed” regisztráció szükséges, amelynek költsége 1200$ /év. 7. táblázat - Nmap

Nmap Részletek Kategória Operációs rendszer Leírás

http://nmap.org/ Scanner Windows, Linux Az Nmap (Network Mapper) a legnagyobb tudással rendelkezı portszkenner. 8. táblázat - Wireshark

Wireshark Részletek Kategória Operációs rendszer Leírás

http://www.wireshark.org sniffer, traffic analyzer Windows, Linux A Wireshark (elızı verziókban Ethereal) a leggyakrabban használt hálózati forgalomelemzı rendszer. Pcap formátumú fájlokat offline módban is képes kielemezni, a TCP kapcsolatokat követni (follow tcp stream), forgalmakat szőrni protokoll szerint. Több száz protokollt és formátumot képes megkülönböztetni. Statisztikai modulja összesítéseket tud készíteni az analizált forgalomról. Windows és Linux rendszerekre is ingyenes. 9. táblázat - Snort

Snort Részletek Kategória Operációs rendszer Leírás

http://www.snort.org IDS, IPS, sniffer, traffic analyzer Windows, Linux A Snort komplex hálózatbiztonsági rendszer, melynek több funkciója külön-külön is használható. A hálózati forgalmat képes lehallgatni (sniffer), majd különféle feldolgozó modulokon keresztülvezetve (preprocessor) képes online analizálni a forgalmat, vírusokat, férgeket és különféle támadásokat (WEB, SQL, SMB,…) detektálni. Képes csomagszőrı tőzfallal együttmőködni, szükség esetén a forgalomba beavatkozni (IPS). Windows és Linux rendszerekre ingyenes, a Snort kereskedelmi verziója (http://www.sourcefire.com/) vállalati szintő megoldásokat szállít terméktámogatással, frissítésekkel. 10. táblázat - Metasploit Framework

Metasploit Framework Részletek http://www.metasploit.com Kategória exploit framework Operációs rendszer Windows, Linux


34


Leírás

A Metasploit Framework egy nyílt forrású keretrendszer exploitok (támadó kódok) tesztelésére és használatára (támadási és behatolási eszközkészletet). Moduláris felépítése lehetıvé teszi, hogy különbözı biztonsági réseket kihasználó támadó kódokat állítsunk össze belıle, és ezt egy sebezhetı rendszer ellen irányítsuk. Windows és Linux rendszerekre is ingyenes, folyamatosan bővölı exploit adatbázisával együtt. 11. táblázat – Tcpdump

Tcpdump Részletek Kategória Operációs rendszer Leírás

http://www.tcpdump.org sniffer Linux, Windows (Windump) A Tcpdump egy nyílt forrású sniffer, még az Ethereal elıtt jelent meg. Parancssoros módban használható, kimenetként pcap formátumú fájlba képes menteni. Windows-os verziója a Windump. 12. táblázat - Cain & Abel

Cain & Abel Részletek Kategória Operációs rendszer Leírás

http://www.oxid.it/cain.html password recovery Windows A Cain & Abel a leggyakrabban használt Windows-os jelszótörı alkalmazás. 28 féle jelszóképet (Windows, Linux, SQL, SMB, VNC, Cisco,…) képes megkülönböztetni és több módszerrel támadni. Beépített sniffer funkciójával akár ARP poisoning (arp mérgezés) támadással is képes forgalmi adatokhoz jutni, amelyekbıl ki tudja győjteni a jelszavakat, jelszóképeket. Pcap típusú fájlokat is képes offline elemezni. 13. táblázat - John the Ripper

John the Ripper Részletek Kategória Operációs rendszer Leírás

http://www.openwall.com/john/ password recovery Windows, Linux A John the Ripper egy gyors, bıvíthetı parancssoros jelszótörı alkalmazás. Képes brute-force és szótáras támadást alkalmazni. Windows és Unix rendszereken is futtatható, ingyenesen 14. táblázat - GFI LanGuard

GFI LanGuard Részletek Kategória Operációs rendszer

http://www.gfi.com/lannetscan/ Vulnerability scanner, patch management Windows


35


Leírás

A GFI LanGuard nagy kiterjedéső IP hálózatokban felkutatja az élı hosztokat és azokról mély elemzést végez. Képes port-szkennelést végezni, operációs rendszert felismerni, Windows Service Packet detektálni, frissítéseket, USB eszközöket, Wireless csatolókat, futó szolgáltatásokat, gyenge jelszavakat, felhasználókat kigyőjteni, detektálni, a szkennelés eredményét különbözı formákban eltárolni, exportálni. Tartalmaz egy patch management modult, amelynek segítségével naprakész állapotban tarthatjuk Windows rendszereinket. Ingyenes verzió 30 napig használható korlátozott funkciókkal. A kereskedelmi verzió a menedzselendı hálózat nagyságától függ: 4 db. IP-címre 249 $, …, 512 db IP-címre 3538 $. 15. táblázat - SuperScan

SuperScan Részletek Kategória Operációs rendszer Leírás

http://www.foundstone.com/us/resources/proddesc/superscan4.htm Port scanner Windows A SuperScan egy nagyon gyors, Windows-on futó, grafikus felülettel rendelkezı port szkenner, amely tartalmaz még egyéb kiegészítı modulokat is (windows enumeration, traceroute, ping, …). 16. táblázat - Sysinternals tools

Sysinternals tools Részletek Kategória Operációs rendszer Leírás

http://www.microsoft.com/technet/sysinternals/default.mspx utilities (process, file and disk, network, security, system) Windows A Sysinternals tools egy hibaelhárító, diagnosztikai, rendszermonitorozó eszközkészlet Windows rendszerekre. File and disk utilities: Filemon: Filemőveletek monitorozása real-time módban, nyomon követhetıek vele a futó processek filemőveletei. ShareEnum: Megosztásokat kutatja fel a hálózatban, nagyon hasznos eszköz rendszergazdák és auditorok számára. ProcessMonitor: Real-time monitorozó eszköz, file rendszer, registry, process, thred és DLL mőveleteinek nyomon követésére. PsTools: parancssoros eszközök győjteménye, amely számos hasznos programot tartalmaz: ― Psexec: távoli kódfuttatás ― Psinfo: távolról információk győjtése (rendszerrıl, diszkekrıl, installált szoftverekrıl) ― PsKill: távoli processek leállítása ― PsList: távoli processek lekérdezése ― PsLogList: távoli rendszernaplók lekérdezése ― PsPasswd: távoli jelszavak megváltoztatása ― PsService: távoli szervizek kezelése ― PsShutDown: távoli leállítás ― Psloggedon: távoli bejelentkezések kezelése ― Psfile: távoli fájlmőveletek lekérdezése


36


Sysinternals tools Networking Utilities: TcpView: TCP kapcsolatok nyomon követése real-time módon, processekre lebontva. (Nagyon hasznos eszköz, amikor ki akarjuk deríteni, hogy melyik process kommunikál egy adott hosztra, portra.) AD Explorer: Active Directory editor Process utilities: Autoruns: Összegyőjti azokat a programokat, service-ket, driver-eket, dll-eket, amelyek a rendszer indulásakor automatikusan elindulnak. Lehetıség van a Microsoft által aláírt alkalmazásokat elkülöníteni a nem Microsoft termékektıl. Vírusok és egyéb kártékony programok felkutatását segíti elı. Regmon: Registry mőveletek monitorozás real-time módon. Nyomon lehet vele követni, hogy egy-egy alkalmazás milyen registry mőveleteket végez. Security utilities: RootkitRevealer: fejlett rootkit detektáló eszköz, ismeri az összes publikált rootkit technikát, amelyet a www.rootkit.com tartalmaz. SDelete: fájl eltávolító eszköz, amely ténylegesen felülírja a fájl által elfoglalt helyet a merevlemezen. Strings: parancssoros alkalmazás, amely kigyőjti a futtatható kódokból a sztringeket. 17. táblázat - Retina Retina Részletek Kategória Operációs rendszer Leírás

http://www.eeye.com/html/Products/Retina/index.html vulnerability scanner Windows A Retina egy Windows-on futó vulnerability scanner. Központosított biztonsági rés felmérésére, policy kezelésére, biztonsági jelentések készítésére használható. Ára a vizsgálandó IP tartomány méretétıl függ, 32 db IP-re 575$,…., 256 db IP-re 1650$. 18. táblázat - BackTrack

BackTrack Részletek Kategória Operációs rendszer

http://www.remote-exploit.org/backtrack.html vulnerability scanner, sniffer, penetration tester Linux


37


Leírás

BackTrack egy olyan Linux disztribúció, amely tartalmazza a legkedveltebb eszközöket a biztonsági tesztelések során. Több mint 300 eszközt tartalmaz, különféle kategóriákban. Pár eszköz egy-egy kategóriában: Information gathering (információ győjtés): ― Dnsenum, firewalk, netenum, google-search, tctrace,…. Network mapping (hálózat feltérképezése): ― Nmap, fping, hping, IKE-scan, Xprobe2,… Vulnerability Identification (biztonsági rés felkutatás, azonosítás): ― Openssl-scanner, smbdumpuser, smb bruteforcer, snmp enum,… Penetration (behatolás): ― Metasploit Framwork3, Millworm, … Privilege Escalation (jogosultság kiterjesztés): ― Hydra, SMB sniffer, Dsniff, VNCcrack, wireshark,… Maintaining Access (hozzáférés biztosítása): ― 3proxy, Privoxy, TinyProxy, sbd Radio Network Analysis (vezetéknélküli eszközök vizsgálata): ― Kismet, AirSnort, wep_crack, air_reply, bluedebugger,… 19. táblázat - Ntop

Ntop Részletek Kategória Operációs rendszer Leírás

http://www.ntop.org/ sniffer, traffic analyzer Windows, Linux A Ntop hálózati forgalom statisztikázására szolgál. Sniffeli a forgalmat és saját adatbázisában statisztikákat készít, majd saját webes felületén különféle formákban megjeleníti azokat. 20. táblázat - Ngrep

Ngrep Részletek Kategória Operációs rendszer Leírás

http://www.packetfactory.net/projects/ngrep/ sniffer, tarffic analyzer Windows, Linux A Ngrep egy parancssoros sniffer, kibıvítve azzal a hasznos funkcióval, hogy a forgalmi adatokban real-time lehet keresni, szőrni adott sztringekre. Nagyon gyorsan meg lehet vele találni egy program jellegzetes hálózati forgalmát. 21. táblázat - PwDump

PwDump Részletek Kategória Operációs rendszer Leírás

http://www.foofus.net/fizzgig/pwdump/ password recovery Windows A PwDump egy parancssoros alkalmazás, amely képes kiexportálni az NTLM és LanMan jelszavak hash képt fájlba, amelyet azután jelszótörı alkalmazásokkal (John, Cain) lehet támadni. A legújabb verziója képes távoli Windows állomásokhoz is csatlakozni. 22. táblázat - Acunetix Web Vulnerability Scanner

Acunetix Web Vulnerability Scanner Részletek http://www.acunetix.com


38


Kategória Operációs rendszer Leírás

vulnerability scanner Windows Az Acunetix Web Vulnerability Scanner egy webszerverek és webes alkalmazások vizsgálatára szolgáló eszköz. Ismeri a legújabb webes támadási módokat, hatalmas biztonsági rés adatbázissal rendelkezik, képes authentikált session-öket is kezelni. Javascript, Ajax, SOAP technológiákat használó webalkalmazásokat is képes vizsgálni, elemezni. Fontosabb moduljai: - Version Check - CGI Tester - Parameter Manipulation - File Checks - Directory Checks - Text Search - Input Validation - Authentication attacks - Buffer overflows Ára a választott licensztıl függıen 995$ és 4995$ között változik. 23. táblázat - MBSA - Microsoft Baseline Security Analyzer

MBSA - Microsoft Baseline Security Analyzer Részletek http://technet.microsoft.com/en-us/security/cc184924.aspx Kategória security scanner, patch management Operációs rendszer Windows Leírás Az MBSA képes Windows hálózatokban található hosztok biztonsági felmérésére, megállapítja a hiányzó biztonsági frissítéseket, szerviz csomagokat, hibás konfigurációkat. XML és HTML formátumban tud jelentéseket készíteni. 24. táblázat - Winfo Winfo Részletek Kategória Operációs rendszer Leírás

http://www.ntsecurity.nu/toolbox/winfo/ information gathering Windows A Winfo a Windows NULL session-t kihasználva számos információt összegyőjt a Windows munkaállomásokról vagy szerverekrıl. Megosztások, felhasználók, jelszó beállítások részleteit lehet vele megismerni. Nagyon hasznos Windows szerverek vizsgálatánál, mert gyorsan ki lehet győjteni a felvett felhasználókat, és kigyőjteni közülük a szerveren rendszergazdai jogosultsággal rendelkezıket.

6.1.6. Példák behatolás tesztelés forgatókönyvre 6.1.6.1. Egy rejtett behatolás tesztelés áttekintı forgatókönyve Az alábbiakban ismertetett részletes forgatókönyv egy olyan behatolási teszteléshez készült, melynek a 6.1.3 modell szempontjai szerinti jellemzése a következı: ― Információs bázis: fekete doboz , fehér doboz ― Agresszivitás: passzív, óvatos, kiszámított, agresszív ― Hatókör: fókuszált, korlátozott, teljes ― Megközelítés: rejtett, nyílt


39


― Technika: hálózat-alapú, más kommunikációs hálózatok, fizikai támadás, social engineering ― Kiindulási pont: külsı, belsı A forgatókönyv az elıkészítési fázisra (E) vonatkozik, ahogyan azt 6.1.2.2 meghatározza (tehát a passzív és aktív felderítésre, valamint a pásztázásra, szkennelésre). E1. Nyilvános adatok vizsgálata A tesztelı megpróbál annyi információt szerezni a célszervezetrıl, amennyi csak lehetséges. Különösen a szervezettel kapcsolat információk érdeklik, mint például az alkalmazottak, a használt technológiák. Várt eredmények: ― A szervezet profilja, ― Az alkalmazottak profilja, ― Áttekintés a szervezet által használt technológiákról, ― A szervezet társasági viszonyainak és stratégiájának áttekintése. Elıfeltételek:--Tesztelési lépések: ― Információk keresése a szervezet honlapján ― Kutatás a nyilvános adatbázisokban ― Kapcsolódó információk keresése a hírcsoportokban E2. Az alapvetı hálózati információk rejtett lekérdezése A tesztelendı hálózat alapvetı információit meg kell próbálni megszerezni rejtett lekérdezések használatával. Várt eredmények: ― Domain nevek ― IP cím tartomány ― Hoszt nevek ― IP címek ― Szerver funkciók leírása ― ISP információi ― Kapcsolattartó személyek Elıfeltételek: ― IP cím / IP tartomány vagy Domain / szerver nevek Tesztelési lépések: ― Nyilvános adatbázisok lekérdezése ― Név szerverek lekérdezése (óvatosság szükséges, mert a zóna átvitel kísérletét észlelhetik) ― Információk vizsgálata az e-mail fejlécekben


40


― A HTML információk vizsgálata a web helyeken belsı linkek vagy kommentek után kutatva ― Hírcsoportok átkutatása a cél szervezet alkalmazottainak a bejegyzései után ― A szervezet álláshirdetéseinek átnézése, az IT környezet jobb megismerése céljából E3. Rejtett port-szkennelés Rejtett port-szkennelést kell indítani az összes azonosított eszközön, hogy azonosíthassuk a szolgáltatásokat, amelyeket az eszköz futtat, valamint a használt operációs rendszert. Várt eredmények: ― Információk az eszköz által nyújtott szolgáltatásokról ― Operációs rendszer azonosítása. Elıfeltételek: ― Az alapvetı hálózati információk ismerete Tesztelési lépések: ― Olyan port-szkennelés végrehajtása, amit lehetetlen vagy legalábbis nehéz detektálni, például megfelelı paraméterek beállításával a port-szkennelı eszközök használata közben, vagy a kérések hosszú idıközönként küldésével. E4. Alkalmazások azonosítása A tesztelı megpróbálja azonosítani az interneten keresztül elérhetı alkalmazásokat és szolgáltatásokat. Várt eredmények: ― A szerver által nyújtott szolgáltatások azonosítása (pl. HTTP, FTP, NNTP) ― Az alkalmazások azonosítása (pl. e-mail, online bank, e-kereskedelmi szoftver) Elıfeltételek: ― A port-szkennelés (E3) eredményei Tesztelési lépések: ― A port-szkennelés eredményének kiértékelése ― Nyilvánosan elérhetı internetes alkalmazások azonosítása, mint pl. az online bank E5. Rendszer azonosítása A tesztelı megpróbál információkat szerezni az operációs rendszerrıl, a javítások (patchek) alkalmazásának szintjérıl, a rendszer hardverérıl. Várt eredmények: ― Információ az operációs rendszerrıl, ― Információ a javítások alkalmazásának szintjérıl, ― Információ a hardverrıl


41


Elıfeltételek: ― Az alapvetı hálózati információk ismerete Tesztelési lépések: ― Port-szkennelés végzése rendszer felderítéssel és IP csomag analízissel ― Fejléc információk vizsgálata E6. Rejtett router azonosítás A tesztelı megpróbálja rejtett lekérdezésekkel azonosítani a szervezet által használt routereket, rendeltetésüket a hálózatban, a használt operációs rendszereket, a router típusának gyártóját. Várt eredmények: ― A routerek IP címei ― A routerek feladata a hálózatban ― Operációs rendszer, gyártó és router típus Elıfeltételek: ― Az alapvetı hálózati információk ismerete ― A rejtett port-szkennelés (E3) eredményei ― Rendszer azonosítás (E5) eredményei Tesztelési lépések: ― Útvonalak óvatos nyomonkövetése a „trace route” parancs segítségével ― Az irányított(routed) IP csomagok vizsgálata E7. Tőzfal azonosítás A tesztelı megpróbálja azonosítani a tőzfalak alábbi tulajdonságait: ― fajtája (csomag szőrı, hálózati interfészek száma, alkalmazás átjáró stb.) ― típusa (gyártó, verzió, konfigurációs hozzáférés, stb.) ― konfigurációja (nyitott portok, nyitott protokollok, stb.) Várt eredmények: ― A tőzfal komponensek (tőzfal hoszt, alkalmazás átjáró stb) IP címei és/vagy DNS nevei ― A tőzfal operációs rendszere ― A tőzfal szoftver modellje és hibajavítási szintje Elıfeltételek: ― Az alapvetı hálózati információk ismerete ― A rejtett port-szkennelés (E3) eredményei Tesztelési lépések: ― Fejléc vizsgálat a tőzfal komponenseken ― Tőzfalak közvetlen port-szkennelése ― Routolás követése a „trace route” parancs használatával


42


E8. Sebezhetıség kutatás A megszerzett információ (nyitott portok, alkalmazások, operációs rendszerek) vizsgálatával sebezhetıségeket kell keresni, ehhez különbözı eszközök széles választéka használható. Várt eredmények: ― Lista a hibajavítások szintjérıl a rendszerekben és alkalmazásokban ― Lehetséges sebezhetıségek listája Elıfeltételek: ― A nyitott portok ismerete ― A nyújtott szolgáltatások ismerete ― A használt operációs rendszerek és alkalmazások ismerete Tesztelési lépések: ― Magas szintő sebezhetıség szkennerek használata ― Naprakész sebezhetıség adatbázisok lekérdezése ― Levelezési listák/underground FTP archívumok, IRC szerverek és hírcsoportok átkutatása hackelésrıl szóló anyagok és exploit-ok (kihasználást megkönnyítı hackerek által írt programok) után. E9. Alkalmazási interfész azonosítása Az azonosított és internetrıl elérhetı interfészeket meg kell vizsgálni a sebezhetıség szempontjából, különösen azokat, amelyek házon belül kifejlesztett rendszerekhez tartoznak. Ez vonatkozik a DMZ alkalmazásokra, amelyek el tudnak érni alkalmazásokat a szervezet hálózatából egy interfészen keresztül (pl. a rendszer elérése online tranzakciókkal), és vonatkozik a szervezet hálózatán belüli alkalmazásokra is. Várt eredmények: ― Az alkalmazási interfészek lehetséges sebezhetıségeinek listája (pl. web szerverek, ERP rendszerek) ― Információk bármilyen különbözı alkalmazásokat összekötı interfészrıl Elıfeltételek: ― Információ a használt operációs rendszerekrıl és alkalmazásokról ― A rejtett port-szkennelés (E3) eredményei Tesztelési lépések: ― A honlapon lévı szolgáltatások vizsgálata sebezhetıségek szempontjából (pl. adatbázis lekérdezések) E10. Vezeték nélküli kommunikáció tesztelése (csak szkennelés) A tesztelı megvizsgálja mőködik-e WLAN. Ha talál WLAN-t, a fontosabb adatokat össze kell győjteni.


43


Várt eredmények: ― WLAN létezésének ellenırzése ― A WLAN típusának és hozzáférési pontjainak azonosítása ― Kapcsolat típusa (hitelesített vagy hitelesítés nélküli) ― A WLAN földrajzi kiterjedése ― Titkosítás használatának és típusának vizsgálata Elıfeltételek: --Tesztelési lépések: ― WLAN-hoz kapcsolódás kísérlete ― Forgalom figyelése a WLAN-on ― War walking/war driving (A WLAN kiterjedésének meghatározásához) E11. Fax rendszer tesztelése (Azonosítás) A tesztelı megpróbálja kideríteni milyen fax eszközöket használnak a célszervezetben és milyen rendszerek irányítják ezeket. Várt eredmények: ― Fax eszközök listája ― A fax eszközöket irányító rendszerek és operációs rendszerek listája Elıfeltételek: ― Telefon számtartomány ismerete Tesztelési lépések: ― Teszt hívások a célszervezet számtartományában ― War dialer (telefonszámok felderítésére szolgáló program) használata a rendszer összetevıinek azonosításához. ― A fax eszközök dokumentációjának vizsgálata külsı üzemeltetési hozzáférési pontokat keresve. 6.1.6.2. Egy nyílt behatolás tesztelés áttekintı forgatókönyve Az alábbiakban ismertetett részletes forgatókönyv egy olyan behatolási teszteléshez készült, melynek a 6.1.3 modell szempontjai szerinti jellemzése a következı: Információs bázis: fekete doboz , fehér doboz Agresszivitás: passzív, óvatos, kiszámított, agresszív Hatókör: fókuszált, korlátozott, teljes Megközelítés: rejtett, nyílt Technika: hálózat-alapú, más kommunikációs hálózatok, fizikai támadás, social engineering ― Kiindulási pont: külsı, belsı ― ― ― ― ―

A forgatókönyv a kiaknázási fázisra (K) vonatkozik, ahogyan azt 6.1.2.2 meghatározza (tehát a hozzáférésre és a hozzáférés megtartására).


44


A forgatókönyv feltételezi az E fázis sikeres végrehajtását, annak folytatását jelenti. K1. A tényleges sebezhetıségek nyílt igazolása A sebezhetıségek által jelentett tényleges fenyegetést csak úgy lehet megismerni, ha a tesztelı megpróbálja kihasználni a sebezhetıséget, megpróbálja megtámadni a rendszert. Várt eredmények: ― A rendszerek és alkalmazások hibajavítási szintjeinek részletes listája ― A tényleges sebezhetıségek listája ― A lehetséges sebezhetıségek listája, amelyeket a rejtett technikákkal nem lehetett ellenırizni Elıfeltételek: ― E8 eredménye: lehetséges sebezhetıségek listája Tesztelési lépések: ― Magas szintő sebezhetıség szkennerek használata ― A maradék sebezhetıségek kézi ellenırzése, mint pl. buffer overflow exploit-ok, stb. K2. Az alkalmazás interfész tényleges sebezhetıségeinek igazolása A kommunikációban (interfészekben) talált sebezhetıségek által jelentett tényleges fenyegetést (pl. adatbázis elérése web szerveren keresztül) úgy lehet megismerni, ha a tesztelı megpróbálja kihasználni a sebezhetıséget, megpróbálja megtámadni a rendszert. Várt eredmények: ― A rendszerek és alkalmazások hibajavítási szintjeinek részletes listája ― Tényleges sebezhetıségek listája az alkalmazás interfészekben Elıfeltételek: ― E8 és E9 eredménye: az alkalmazási interfészek lehetséges sebezhetıségeinek listája, részletes leírások az alkalmazások interfészérıl Tesztelési lépések: ― Magas szintő sebezhetıség szkennerek használata ― A maradék sebezhetıségek kézi ellenırzése, mint pl. buffer overflow exploit-ok, stb. K3. Nyílt router tesztelés Az azonosított routerek vizsgálata, sebezhetıségek és manipulációs lehetıségek keresése. Várt eredmények: ― Információk a routerek ACL-jeirıl ― Információk a routerek beállításairól ― Adminisztratív hozzáférés a routerekhez


45


Elıfeltételek: ― Részletes információk az E6 által azonosított routerekrıl Tesztelési lépések: ― Bejelentkezés kísérlete a routerbe az alap jelszavakkal és teljes kipróbálás (brute force) támadás alkalmazása. ― Router ACL-jeinek azonosítása a megfelelı eszközökkel (firewalking). ― A router viselkedésének vizsgálata széttördelt és hamisított csomagok esetén, amelyeket egy csomagkészítı programmal lehet elıállítani. K4. Rendszerek közötti bizalmi kapcsolatok tesztelése A tesztelı megpróbál jogosulatlan hozzáférést szerezni a rendszerek közötti bizalmi kapcsolaton keresztül, pl. egy megbízható hosztot kihasználva a felhasználó hitelesítésénél. Várt eredmények: ― A rendszerek közötti bizalmi kapcsolatok listája ― Jogosulatlan információk győjtése ― Jogosulatlan hozzáférés fájlokhoz vagy rendszerekhez Elıfeltételek: ― Az E4 és E5 által azonosított rendszerek és alkalmazások leírása Tesztelési lépések: ― A rendelkezésre álló információk elemzése a rendszerek közötti függıségek és bizalmi kapcsolatok szerint. ― Hozzáférés kísérlete hamisított IP címekkel vagy más hitelesítési tulajdonságokkal K5. Nyílt tőzfal tesztelés kívülrıl A tesztelı megpróbálja megkerülni a tőzfalat, vagyis kívülrıl hálózati kapcsolatot próbál létesíteni a biztosított hálózati szegmenssel. A tesztelı megpróbálhatja átvenni az uralmat a tőzfal felett vagy megpróbálhatja kihasználni hibás beállításait. Várt eredmények: ― A kívülrıl megismerhetı tőzfal szabályok listája ― A tőzfal azonosított sebezhetıségeinek igazolása ― Lista a tőzfal mögött elérhetı rendszerekrıl Elıfeltételek: ― Az E7által azonosított tőzfal komponensek Tesztelési lépések: ― Sebezhetıség szkenner használata a tőzfal rendszer hosztjaira (tőzfal hoszt, külsı router, belsı router) ― Tőzfal szabályok azonosítása a megfelelı eszközökkel ― Tőzfal mögötti rendszerek elérésének kísérlete


46


― A router viselkedésének vizsgálata széttördelt és hamisított csomagok esetén, amelyeket egy csomagkészítı programmal lehet elıállítani. K6. Tőzfal tesztelése mindkét oldalról A tőzfal vizsgálata a tőzfal mindkét oldalának tesztelésével. Egy kívül elhelyezett rendszer csomagokat küld, egy belül elhelyezett rendszer pedig elemzi a csomagokat, majd fordítva. Várt eredmények: ― A kívülrıl megismerhetı tőzfalszabályok listája ― A tőzfal fajtákra azonosított sebezhetıségek igazolása ― Részletes lista a tőzfal mögött elérhetı rendszerekrıl Elıfeltételek: ― Az E7 által azonosított tőzfal komponensek, valamint egy hálózati hozzáférési pont a tőzfal mögött Tesztelési lépések: ― Annak tesztelése, hogy (akár bújtatott protokollon keresztül) lehet e hitelesítés nélküli kapcsolatot létesíteni a belsı hálózattal az interneten keresztül. ― Sebezhetıség szkenner használata a tőzfal rendszer hosztjaira (tőzfal hoszt, külsı router, belsı router) belülrıl ― Tőzfal szabályok azonosítása a megfelelı eszközökkel, mindkét oldalról ― Tőzfal mögötti rendszerek elérésének kísérlete ― A router viselkedésének vizsgálata széttördelt és hamisított csomagok esetén, amelyeket egy csomagkészítı programmal lehet elıállítani. K7. IDS rendszer tesztelése Annak tesztelése, hogy az IDS észleli-e a támadásokat és riaszt-e. Várt eredmények: ― IDS típusa ― Az IDS válasza különbözı típusú támadásokra ― IDS teljesítményének leírása Elıfeltételek: ― A rendszer és a tőzfalak részletes ismerete. Annak monitorozási lehetısége, hogy az IDS riaszt-e. Tesztelési lépések: ― Fokozatosan egyre „zajosabb” támadások elvégzése a hálózaton ― IDS támadásokra adott reakciójának kiértékelése ― A támadások és az IDS naplófájljainak összehasonlítása K8. Jelszavak elfogása


47


A tesztelı megpróbálja elfogni a hálózaton átmenı jelszavakat a megfelelı eszközök segítségével (hálózati snifferek, backdoor-ok) Várt eredmények: ― Nyílt jelszavak Tesztelési lépések: ― Jogok megszerzése a figyelıprogramok telepítéséhez az adott rendszereken ― Billentyőfigyelı programok telepítése az adott rendszereken ― Hálózati forgalom rögzítése és elemzése, jelszavak keresése K9. Jelszavak törése A tesztelı különbözı módszerekkel megpróbál olyan jelszót szerezni, amely magasabb jogosultságot adna neki a rendszerben/alkalmazásban. Várt eredmények: ― Nyílt jelszavak Elıfeltételek: ― A rejtjelezett jelszavakat tároló fájlhoz való hozzáférés, például K8 eredményeként, vagy egy beépített segítségtıl. A védett hálózatra csatlakozási lehetıség is kell a valósidejő támadások megvalósításához. Tesztelési lépések: ― Jelszó fájlok vizsgálata a megfelelı eszközök használatával (offline) ― Online támadások végrehajtása, ha nincs jelszófájl az offline támadáshoz ― Alap vagy gyakori jelszavak kézi tesztelése K10. Szolgáltatás megtagadás ( DoS) támadásokra való érzékenység tesztelése A tesztelı megvizsgálja milyen mértékben érzékeny a rendszer a DoS támadásokra. Várt eredmények: ― DoS támadásoknak kitehetı rendszerek listája Elıfeltételek: ― A DoS támadásokra érzékeny rendszer jelöltek (web szerverek, levelezı szerverek) elérhetısége. Tesztelési lépések: ― Az E8 (Sebezhetıség kutatás) lépés eredményeinek vizsgálata ― DoS támadás kivitelezése különbözı technikákkal K11. Vezeték nélküli kommunikáció tesztelése A tesztelı megpróbál hozzáférni a WLAN-hoz


48


Várt eredmények: ― A WLAN sebezhetıségeinek listája Elıfeltételek: ― Az E10 által azonosított WLAN-ra vonatkozó információ Tesztelési lépések: ― Az E10 „Vezeték nélküli kommunikáció tesztelése” lépés eredményeinek elemzése ― A lehetséges sebezhetıségek kihasználása ― WLAN-hoz kapcsolódás kísérlete ― Hozzáférési kísérlet a WLAN-hoz ― WLAN adataihoz való hozzáférési kísérlet K12. Adminisztratív hozzáférési pontok tesztelése a fax rendszerben A tesztelı megpróbálja megkerülni a fax rendszer biztonsági funkcióit, és megpróbál adminisztratív hozzáférést szerezni a rendszerhez. Várt eredmények: ― Adminisztratív hozzáférés a fax rendszerhez ― Sebezhetıségek igazolása Elıfeltételek: ― Az E11 által azonosított fax rendszerre vonatkozó információ Tesztelési lépések: ― Az E11 (Fax rendszer tesztelése) lépés eredményeinek tesztelése ― Más olyan technikai teszt végrehajtása, amely a fax rendszer ismeretét igényli. K13. Modem tesztelése A tesztelı megpróbál hozzáférést szerezni a célszervezet hálózatához modemen keresztül, így megkerülve a tőzfalat. Várt eredmények: ― A „vad” modemek listája ― Sikeres behatolási kísérletek listája Elıfeltételek: ― Modem telefonszámok vagy a számtartomány ismerete Tesztelési lépések: ― War dialer használata (rendszert azonosító összetevıkkel) a szervezet számtartományán ― Behatolás a hálózatba az azonosított modem kapcsolatokon keresztül.


49


6.2.

Útmutató a rendszer sebezhetıségi vizsgálatához

6.2.1. Útmutató a független sebezhetıség vizsgálat elvégzéséhez SAP-A esetén a sebezhetıségi elemzés középpontjában egy automatikus eszközökkel végrehajtott behatolás tesztelés áll. SAP-F és SAP-K ezen kívül elvárja, hogy az értékelı egy független sebezhetıség vizsgálatot is végrehajtson az STOE-ra, felhasználva az SST, a biztonsági architektúra leírás, a rendszer interfész specifikáció, az STOE terv, a rendszer-mőködési biztonsági koncepció és az útmutató dokumentációk által biztosított ismereteket, az STOE lehetséges sebezhetıségeinek azonosítása érdekében. Ez az alfejezet a független sebezhetıség vizsgálat elvégzéséhez nyújt gyakorlati útmutatót. A független sebezhetıség vizsgálat középpontjában a hiba hipotézis megközelítés áll. Ez a következıképp szerepel az értékelési módszertanban (ASVA_VAN.2-4, ASVA_VAN.3-4): „Hiba hipotézis módszer használata szükséges, amely a specifikációk, a tervezési és útmutató bizonyítékok vizsgálata után az STOE-ban lévı lehetséges sebezhetıségeket feltételezi, illetve ezzel kapcsolatos vizsgálódásokat folytat. Az értékelı használja fel az STOE-ra szerzett ismereteit, hiba hipotézis módszert alkalmazva, az STOE integrálásában, vagy specifikált üzemmódjában lévı lehetséges hibák azonosítása céljából.” Az alábbiakban meghatározzuk, hogy az egyes értékelési bizonyítékok értékelése esetén milyen hiba hipotézist érdemes használni a független sebezhetıség vizsgálathoz. Az SST értékelése során a sebezhetıségi vizsgálat elıkészítése érdekében az értékelıknek a következıkrıl érdemes feljegyzéseket írni: ― Az SFR-ek nem teljesülésének következményei (legyen az helytelen megvalósítás, helytelen használat, vagy sikeres megkerülés vagy fizikai módosítás alapú támadás, stb. következménye). Ezek fenyegetések formájában kerülnek leírásra, amelyeket meg lehet valósítani, és az értékek kompromittálódhatnak. ― Bármi más az SFR-ekhez kapcsolódó említésre méltó dolog, például: az adott SFR ki lehet-e téve közvetlen támadásnak, mik az adott SFR-hez szorosan kapcsolódó SFRek (pl. függıségek miatt), stb. A biztonsági architektúra leírás értékelése során az értékelı tulajdonképpen a rendszer integrátor sebezhetıség elemzését ellenırzi. Ennek során azt kell megerısítenie, hogy a rendszer integrátornak sikerült-e úgy megterveznie és megvalósítani az STOE-t, hogy a rendszer biztonsági funkcionalitását ne lehessen megkerülni, egyúttal az képes legyen megvédeni magát a nem-megbízható aktív egyedek hamisításaitól.


50


Az értékelınek feljegyzéseket érdemes készítenie arról is, hogy milyen szerepet játszanak a biztonsági architektúra leírásban szereplı védelmi mechanizmusok a megkerüléssel és fizikai módosítással végzett támadások megelızésében. A rendszer interfész specifikáció értékelése során felállított hiba hipotézisnél az értékelınek elsısorban a következı támadási módszereket kell figyelembe venni, annak megállapítására, hogy a vizsgált SFR érzékeny-e rá: ― Sorrend manipulációs támadások. Ez a fajta támadás olyan SFR-re irányul, amely az események egy meghatározott sorrendjét követi, és a támadó hatással lehet magára a sorrendre. A sorrend manipuláció magába foglalja a várt sorrend felcserélését, a sorrend egyik elemének kihagyását, vagy más lépés (pl. más SSF interfész hívás) vagy más entitás beszúrását (mint például a man-in-the-middle támadásnál) a várt sorrendbe. ― Nem várt input támadások. Ide tartozik a rosszul formázott input adat biztosítása az SSF interfész számára. Általánosságban bármely SSF interfész sebezhetı lehet egy ilyen támadással szemben, és a rendszer interfész specifikáció kevés támpontot adhat, hogy melyik interfészt érdemes támadni (sokkal inkább a terv dokumentációk elemzése segíthet rávilágítani a tesztelendı interfészekre). Mindazonáltal az értékelınek meg kell állapítani, hogy vannak-e olyan SSF input adat paraméterek, amelyeknek közvetett vagy közvetlen módon egy tartományba kell esniük, vagy néhány megengedett értékük lehet csak. A közvetett inputokat (biztonsággal összefüggı konfigurációs, vagy inicializáló fájlok) is be kell azonosítani további vizsgálat céljára. ― Nem várt rendeltetés támadások. Mint az elızı támadásnál, a rendszer interfész specifikáció itt sem szolgáltat túl sok támpontot. Ennek ellenére az értékelı a rendszer integrátor által készített SSF megfeleltetéseket használva az értékelés során megállapíthatja, hogy vannak-e nyilvánvaló SSF interfészek, amelyet az integrátor kifelejtett (és ezért egyszerő megkerülı utat biztosítanak). ― Privilégium öröklés támadások. Ez a fajta támadás akkor releváns, ha az STOE tartalmaz olyan privilegizált alkalmazásokat vagy parancsokat, amelyek segítségével megkerülhetı vagy hatástalanítható az SSF. Az alkalmazás interfész elleni támadásnál egy olyan ellenırizetlen kijáratot, vagy mőködési állapotot találhatunk, ahol a támadó megörökli az alkalmazás privilégiumait. A rendszer biztonsági terv értékelése során felállított hiba hipotézisnél az értékelınek elsısorban a következı támadási módszereket kell figyelembe vennie: ― Sorrend manipulációs támadások. Ennek a támadás típusnak a vizsgálata akkor javasolt, ha az STOE terv azt jelzi, hogy egy SFR-t érvényre juttató vagy SFR-t támogató alrendszer érzékeny a külsı interfészre. Ez tipikusan az a helyzet lehet, amikor az alrendszer egy processz (folyamat), amelyet ki lehet lıni, alacsonyabb prioritást lehet rá beállítani vagy más entitással más módon meg lehet zavarni mőködését, így zárolva egy kritikus erıforrást. ― SSF adat támadások. Ennél a támadás típusnál azt kell figyelembe venni (minden egyes SFR esetén), hogy hogyan tárolják és védik az SSF adatokat. ― Interfész input támadások. Ennek a támadás típusnak a vizsgálata különösen azon komponensek esetében javasolt, amelyek kívülrıl is látható (külsı) interfésszel rendelkeznek, és itt ellenırizniük kell az SSF-releváns input adatokat, például az SSF adat elemeket módosító paramétereket.


51


― Nem rendeltetésszerő használat támadások. Ennek a támadás típusnak a vizsgálatánál figyelembe kell venni a komponensek egymás közötti kölcsönhatását. Kívülrıl látható funkciók segítségével megvalósítható megkerülı utak feltárása a cél, amelyeket az SSF-nek meg kellene védenie, de mégsem teszi ezt meg. A rendszer-mőködés biztonsági koncepciójának értékelése során felállított hiba hipotézisnél az értékelınek elsısorban a következı támadási módszereket kell figyelembe venni, annak megállapítására, hogy a vizsgált SFR érzékeny-e rá: ― SSF függıségi támadások. Ennél a támadás típusnál azonosítjuk (elsısorban a rendszer-mőködés biztonsági koncepció és az STOE-hoz hasonló más rendszerek ismerete alapján) az SSF azon függıségeit, melyek a rendszer erıforrások elérhetıségébıl, a rendszer szintő konfigurációs paraméterekbıl vagy az környezet külsı behatásaiból származnak. ― Osztott erıforrás támadás. Ennek a támadás típusnak a figyelembe vétele akkor indokolt, ha a rendszer-mőködés biztonsági koncepció olyan erıforrásokat azonosít, amelyeket különbözı alrendszerek is használnak. Az ilyen erıforrásokat meg kell vizsgálni, hogy nem biztosítanak-e tiltott hozzáférést érzékeny felhasználói vagy SSF adatokhoz (pl. nyílt jelszavak és kulcsok), vagy nem tesznek lehetıvé tiltott adatáramlást. A rendszer útmutató dokumentumok értékelése során az értékelı által felállított hiba hipotézisnek a lehetséges téves használatból eredı sebezhetıségekre kell irányulnia (pl. olyan lehetséges hibákra az STOE mőködésében, amelyek nem biztonságos állapothoz vezethetnek, a nem biztonságos konfiguráció vagy üzemeltetés révén). Ez a vizsgálat nagyban támaszkodjon más elemzések eredményeire, ahol ez lehetséges. Példának tekintsük azt az esetet, amikor a rendszer interfész specifikáció elemzése már megállapította, hogy az STOE nem jól kezel egy csak az adminisztrátor által beállítható SSF adatot, ha az a megfelelı tartományon kívül esik. Az értékelı ezek után olyan téves használati forgatókönyveket készíthet, amelyben az adminisztrátor tévedésbıl „nem várt” értékre állítja az adott SSF adatot. Az értékelı független tesztelése során az értékelı a tervezési és tesztelési dokumentációkból nyert ismereteit is használja fel a független tesztek meghatározásához, például: ― azokat az SSF interfész opciókat vizsgálja, melyeket nem tesztelt kellıen a rendszer integrátor, ― kiemelt figyelmet kapjanak azok az SFR-ek, amelyeket érvényre juttató funkciók terve különösen komplex (és ezért implementációs hibákat tartalmazhat). ― a kritikus komponensekben olyan végrehajtási útvonalak tesztelése, amelyeket nem fedett le megfelelıen teljesen a rendszer integrátor. 6.2.2. Sebezhetıségi adatbázisok A 25. táblázat a biztonsági témákban leghasznosabb internetes elérhetıségeket adja meg. 25. táblázat – A biztonsági témákban leghasznosabb elérhetıségek Elérhetıség

Leírás


52


Elérhetıség

Leírás

www.securityfocus.com

Biztonsági résekrıl, sebezhetıségekrıl információcsere lehetısége, a nyilvánosságra került sebezhetıségek legnagyobb adatbázisa. Biztonsági rések adatbázisa, biztonságot növelı ellenırzı listák (checklist), bevizsgált ellenırzı eszközök: National Vulnerability Database Francia biztonsági kutató intézet, biztonsági sebezhetıségek adatbázisa, riasztások Hazai biztonsági riasztások: Isidor Biztonsági Központ Átfogó hálózatbiztonsággal, audittal és oktatással foglalkozó szervezet, amelynek honlapján több mint 1600 darab 70 témában csoportosított ingyenesen hozzáférhetı szakmai anyag található. Naponta frissülı, biztonsági réseket publikáló „hacker” adatbázis. Rendszeresen megjelenı, ingyenesen letölthetı pdf formátumú, digitális, biztonsággal foglalkozó újság (InsecureMag). „Globális” biztonsági non-profit szervezet, hatalmas biztonsági eszközkészlettel, biztonsági leírásokkal. Windows rendszerek biztonságával foglalkozó weboldal. Számítógépes incidensek kezelése. Egy ingyenes szolgáltatás és eszköz (Cassandra), mely képes a hálózatokon, illetve egyedi hosztokon futó szolgáltatásokról és alkalmazásokról profilt létrehozni, s ezt letárolni. Ezt követıen a Cassandra e-mailen keresztül értesíti az érintett rendszeradminisztrátort az adott profilra vonatkozó új sebezhetıségekrıl. Az egyéb sebezhetıséggel kapcsolatos tanácsadói szolgáltatások átfogó listáját tartalmazza. Az USA nemzetbiztonsági minisztériuma nevében a MITRE Corporation által futtatott amerikai Közös Sebezhetıségi és Kockázati Projekt tartja karban A Beyond Security Ltd izraeli cég által üzemeltetett biztonsági portál, amely az új sebezhetıségekrıl biztosít tájékoztatást. Jól szervezett listákkal rendelkezik, és jó alternatív forrást biztosít az amerikai szereplık mellett.

http://nvd.nist.gov/

http://www.frsirt.com/english/ http://www.isbk.hu http://sans.org/

http://www.millworm.com http://www.netsecurity.org/insecuremag.php http://packetstormsecurity.com http://www.windowsecurity.com/ http://www.cert.org/ https://cassandra.cerias.purdue.edu/

http://icat.nist.gov

http://www.securiteam.com/

6.2.3. Az ingyenesen használható eszközök elérési lehetıségei Az útmutatóban említett alábbi eszközök ingyenesen elérhetık az alábbi címen: ― Angry IP http://www.angryziber.com ― BRUTUS http://www.hoobie.net/brutus/


53


― ― ― ― ― ― ― ― ― ― ― ― ― ― ― ―

finger_mysql http://www.securiteam.com/tools/6Y00L0U5PC.html HPING http://www.hping.org Httpprint http://www.net-square.com/httprint/ MetaCoretex http://sourceforge.net/projects/metacoretex/ Nikto http://www.cirt.net/code/nikto.shtml Nmap http://nmap.org Paros http://www.parosproxy.org pxytest, http://freshmeat.net/projects/pxytest/ Sam Spade http://samspade.org SQLBF http://newdata.box.sk/2001/may/sqlbf_bin.zip SQLPing http://www.sqlsecurity.com/Tools/FreeTools/tabid/65/Default.aspx SuperScan http://www.foundstone.com/us/resources/proddesc/superscan3.htm THC-HYDRA http://freeworld.thc.org/thc-hydra/ Tnscmd.pl http://www.jammed.com/~jwa/hacks/security/tnscmd/ Wikto http://www.sensepost.com/research/wikto/ winfo.exe http://www.ntsecurity.nu/toolbox/winfo

Az útmutatóban említett alábbi eszköz nem ingyenes: ― N-Stalker /a részletek megtalálhatók: http://www.nstalker.com/

6.3.

Útmutató az értékelési altevékenységek sorrendjére

Az értékelési tevékenységek sorrendjére két lehetséges megközelítést tárgyalunk: ― A lineáris megközelítés, mely a CC termék értékelés tevékenységi sorrendjének alkalmazását jelenti rendszerek esetén is, ― A sebezhetıség vizsgálatra koncentráló (VLA-centrikus) megközelítés, mely a rendszer értékelések gyakorlatában jól használható újszerő sorrendiséget javasol). 6.3.1. Lineáris megközelítés Az értékelési tevékenységek lineáris sorrendjét a 2. ábra szemlélteti.


54


Idı

ASST SFR-ek megismerése ASDV_ARC ASDV_SIS ASDV_SDS ASDV_OSC

Befejezett ASDV eredmények

ASTE_FUN ASTE_COV ASTE_DPT ASTE_IND

Befejezett ASTE eredmények

Bizonyítékok összegyőjtése, támadási ötletek kialakítása

ASVA_VAN Behatolás tesztelés

Befejezett ASVA eredmények

2. ábra - A lineáris értékelési struktúra

A 2. ábra csak az ASST (rendszer biztonsági elıirányzat), ASDV (Rendszer fejlesztés), ASTE (Rendszer tesztelés) és ASVA (Rendszer sebezhetıség felmérés) garanciaosztályokkal foglakozik, mivel csak az ezekkel kapcsolatos értékelıi tevékenységek számára fontos az idızítés. Az ASGD (Rendszer útmutató dokumentumok) és az ASCM (Rendszer konfiguráció kezelés) osztály a folyamatba párhuzamosan beilleszthetı, idızítésük rugalmasan változtatható. A lineáris sorrend alkalmazása esetén az értékelı a rendszer biztonsági elıirányzat tanulmányozásából indul ki, az abban meghatározott és levezetett funkcionális biztonsági követelményekre (SFR) koncentrálva. Ezt követıen a funkcionális biztonsági követelményeket visszavezeti a különbözı terv reprezentációkra: a) a biztonsági architektúra leírás (ASDV_ARC) értékelése során a tartomány szétválasztásra, valamint a biztonsági funkcionalitás önvédelmére és nemmegkerülhetıségére vonatkozó biztonsági követelmények teljesülését vizsgálja,


55


b) a rendszer interfész specifikáció (ASDV_SIS) értékelése során a rendszer külsı interfészein keresztül látható biztonsági funkcionalitás vizsgálatával közelíti meg a biztonsági követelmények teljesülését, c) a rendszer biztonsági terv (ASDV_SDS) értékelésével az elızı szempontot kiegészítve a biztonsági funkcionalitás belsı viselkedését vizsgálja, míg végül d) a rendszer-mőködési biztonsági koncepció (ASDV_OSC) értékelésével a rendszer mőködésére vonatkozó szabályozást vizsgálja meg az alábbi szempontokból: a külsı és belsı információ áramlás ellenırzése, a lokális és távoli hozzáférések ellenırzése, ez erıforrásokhoz való hozzáférés ellenırzése, a mőködési mód specifikus mőveletek ellenırzése. A fenti terv reprezentációk egymást követı értékelésével az értékelı különbözı szempontok (önvédelem, külsı és belsı viselkedés, ellenırzési koncepciók) alapján egyre mélyebb ismereteket szerez a biztonsági követelményekrıl és annak rendszeren belüli érvényre juttatásáról. Ezt követıen az értékelı a tesztelésre vonatkozó bizonyítékokat vizsgálja meg: a tesztdokumentációt (ASTE_FUN), a teszt lefedettség elemzést (ASTE_COV), valamint a teszt mélység elemzést (ASTE_DPT). Ezekben a bizonyítékokban azonosítja az egyes biztonsági követelményeket, s ezzel arról is képet kap, hogy e követelményeket milyen alaposan tesztelte a rendszer integrátor. Ezt az ismeretet két célra is használhatja: egyrészt a független tesztelés során megismételendı vagy kiegészítésként elvégzendı tesztesetek meghatározásához, másrészt a behatolás tesztelés megtervezéséhez. A független tesztelés (ASTE_IND) során az értékelı ellenırzi a rendszer integrátor tesztelési tevékenységét (egy kiválasztott minta teszthalmaz megismétlésével és az eredmények összehasonlításával), valamint a szükséges területeken ki is egészíti azt. Eredményeképp az értékelı pontosabb képet kap a funkcionális biztonsági követelmények rendszeren belüli érvényre juttatásáról. A tervek (ASDV) és a tesztelés (ASTE) értékelése után az értékelı összegzi az STOE-ról szerzett információit és ismereteit, s ebbıl kialakítja a sebezhetıség vizsgálat és a behatolás tesztelés lépéseit. A behatolás tesztelés célja a lehetséges sebezhetıségek kihasználhatóságának bizonyítása vagy megcáfolása. Ez azt jelenti, hogy a behatolás tesztelésre a sebezhetıség vizsgálat (és más értékelı tevékenység) után kerül sor, és inkább megerısítı, mintsem feltáró jellegő. Ebben a megközelítésben a behatolás tesztelés az értékelı azon ismereteit egészíti ki, melyeket a tervezés, a tesztelés (és más) értékelésre átadott bizonyítékaiból, valamint az STOE mőködésének megfigyelésébıl már megszerzett. 6.3.2. A sebezhetıség vizsgálatra koncentráló megközelítés Az értékelés egy másik megközelítése a rendszer sebezhetıség felmérés (ASVA) és a rendszer független tesztelés (ASTE_IND) tevékenységeire fókuszál, egyúttal feltáró jelleget ad a sebezhetıség vizsgálatnak és a behatolás tesztnek.


56


Az elemzı és teszt tevékenységek sokkal erısebben épülnek az STOE mőködésének megfigyelésére, mint a különbözı (tervezési és útmutató) dokumentációk kezdeti megértésére. Az ASDV, ASGD és ASCM garanciaosztályok követelményeit most elsısorban annak érdekében kell kielégíteni, hogy az értékelı elegendı ismerettel rendelkezzen a szisztematikus és részletes sebezhetıség vizsgálat végrehajtásához, valamint az ezt támogató behatolás tesztek létrehozásához. Ebben a megközelítésben a behatolás tesztelés felszínre hozhat olyan életképes kreatív gondolatokat, amelyek elveszhetnének, ha a sebezhetıség vizsgálat csupán a korábbi ASDV és ASTE tevékenységekbıl származó ellenırzı listára korlátozódik. A 3. ábra a sebezhetıség vizsgálatra koncentráló megközelítés értékelési struktúráját szemlélteti. Az ebben vázolt sorrendet jellemzi, hogy az értékelés korai szakaszában sorra kerülnek az alábbiak: a) a mőködı STOE vizsgálata, b) egyes behatolási és független tesztek végrehajtása.


57


Idı ASST ASDV_ARC ASDV_SIS ASDV_SDS ASDV_OSC ASTE_FUN ASTE_COV ASTE_DPT

SFR-ek kezdeti megismerése

Mőködı STOE kezdeti vizsgálata

1. Sebezhetıség vizsgálat

Kezdeti tesztek végrehajtása (független + behatolás)

Kezdeti ASDV, ASGD és ASTE eredmények

2. Sebezhetıség vizsgálat Teszt eredmények elemzése, új hipotézisek és tesztek kidolgozása

Befejezett ASDV, ASGD és ASTE eredmények (kivéve ASTE_IND)

3. Sebezhetıség vizsgálat Végsı tesztek végrehajtása (független + behatolás)

Befejezett ASVA és ASTE_IND eredmények

3. ábra - A sebezhetıség vizsgálatra koncentráló értékelési struktúra

Az alábbiak részletezik a 3. ábra fıbb értékelési tevékenységeit. 6.3.2.1. Az SFR-ek kezdeti megismerése Ennek a tevékenységnek a célja az, hogy az értékelı megismerje az SST-t, ezen belül különösen az STOE által érvényre juttatott funkcionális biztonsági követelményeket (SFReket). Ennek során értse meg az egyes biztonsági követelményeket, beleértve a védendı/használt értékeket, a kivédendı fenyegetéseket, a kapcsolatokat (pl. függıségek) a biztonsági követelmények és a biztonsági architektúra között, és minden biztonsági követelmény tesztelhetı aspektusát.


58


Az SFR-ek kezdeti megismerése során a tervezési dokumentációkból az értékelı egy elızetes képet kap az alábbiakról: ― hogyan reprezentálják a tervek az értékeket, ― hogyan reprezentálják a tervek a biztonsági követelményeket, ― milyen feltételek teremtenek lehetıséget a biztonsági követelmények megkerülésére vagy fizikai módosítására. Ezzel számos ASDV munkaegység elsıdleges értékelése is megtörténik, mint például a tervezési dokumentációk teljessége, helyessége és konzisztenciája. Az SFR-ek kezdeti megismerése során a tesztelési dokumentációkból az értékelı egy elızetes képet kap az alábbiakról: ― milyen szempontból mutatta be helyesen és elégségesen a rendszer integrátor a biztonsági követelményeket, ― milyen szempontból nem mutatta be helyesen vagy elégségesen a rendszer integrátor a biztonsági követelményeket, milyen további teszteket vagy tesztvariációkat szeretne az értékelı kipróbálni a kezdeti tesztekben (melyek vagy az STOE mőködésének megértését és feltárását célozzák meg, vagy az STOE mőködését különbözı biztonsági helyzetekben hivatottak megmutatni). A tesztek vizsgálata segítheti a biztonsági követelmények érvényre juttatásának és a tervezési dokumentációknak a megértését is (például a teszt leírások megvilágíthatják, hogy az STOE részei vagy mőveletei hogyan illeszkednek egymáshoz, amelyet nem könnyő leírni a tervezési reprezentációkban.) Az SFR-ek kezdeti megismerése tevékenység tipikusan a következı lépésekbıl áll: ― Az SST átolvasása annak megértése céljából, hogy az egyes biztonsági követelmények mit várnak el, milyen értékek védelmét és/vagy használatát igénylik, milyen fenyegetések kivédését követelik meg, illetve ezek alapján milyen módok létezhetnek megkerülésükre). Már ekkor érdemes elkezdeni a lehetséges behatolás tesztek és független tesztek listájának elkészítését. ― Az összes biztonsági követelmény visszavezetése a tervezési reprezentációkra és a teszt dokumentációra. ― Kérdések megfogalmazása a rendszer integrátorok felé. A tevékenység végrehajtása során valószínőleg befejezhetı az SST értékelése, s részleges eredmények születnek a különbözı tervezési és tesztelési dokumentációk ellenırzésében. 6.3.2.2. A mőködı STOE kezdeti vizsgálata Ennek a tevékenységnek az a célja, hogy az értékelı minél hamarabb gyakorlati tapasztalatokra tegyen szert az STOE-val kapcsolatosan. (Ez jelentıs különbség a lineáris megközelítéssel szemben, ahol a gyakorlati megértés és tapasztalat csak a késıbbi fázisokban kerül elı.) A mőködı STOE megismerése tipikusan a biztonsági követelmények teljesülésének ad hoc tesztelését jelenti, hogy azok a már eddig megismert és elvárt módon mőködnek-e. További tesztek származhatnak az ASGD keretében benyújtott útmutató dokumentumokból.


59


Az értékelı számára a fı cél a mőködı STOE elérése a jobb megértés érdekében, a rendszer integrátortól függetlenül (amennyire ez lehetséges). 6.3.2.3. Kezdeti tesztek végrehajtása Ennek a tevékenységnek az a célja, hogy az értékelı az STOE elméleti megértése (az SFR-ek kezdeti megismerése) és gyakorlati megismerése (a mőködı STOE kezdeti vizsgálata) után rátérjen az STOE biztonságának tesztelésére. A biztonsági tesztelés magába foglalja a tesztesetek meghatározását és végrehajtását is. A kezdeti biztonsági tesztelés már feltételezi a biztonsági követelmények és STOE-beli reprezentációjuk alapos ismeretét. Az értékelık a rendszer architektúra leírás, a nyilvánosan elérhetı sebezhetıségi információk, valamint a saját hipotézisük és elképzelésük alapján (szisztematikusan) beazonosítják a lehetséges sebezhetıségeket. Ezt követıen a lehetséges sebezhetıségekre olyan teszteseteket dolgoznak ki, amelyekkel kimutathatják a tényleges sebezhetıségeket, vagy azt, hogy a lehetséges sebezhetıséget megnyugtató módon kivédték. A tesztek meghatározása és tervezése során az értékelı nagyrészt befejezi az ASDV és az ASTE munkaegységeit, mivel ez szükséges az STOE alapos megértéséhez, és a tesztek pontos meghatározásához. A „kezdeti” tesztelés nem azt jelenti, hogy az értékelınek a biztonsági követelmények hiányos ismerete is elég, hanem azt, hogy az értékelı megszerzi ezeket az ismereteket a lehetséges sebezhetıségek azonosítása érdekében, s ezáltal újabb teszteket határoz meg. A gyakorlatban erre a tevékenységre közvetlenül a „Mőködı STOE kezdeti vizsgálata” tevékenység után, vagy azzal egyidejőleg kerül sor. A kezdeti tesztek során kombinálni lehet a rendszer integrátori tesztek megismétlését és új vizsgálatokat (ASTE_IND), valamint a behatolás teszteket (ASVA_VAN). A tesztelés eredménye egyúttal bizonyítékokat szolgáltat az ASGD munkaegységei számára is. 6.3.2.4. A (kezdeti) teszt eredmények elemzése A 3. ábra önállóan tünteti fel a (kezdeti) teszt eredmények elemzését (és ennek alapján új hipotézisek és tesztek kidolgozását), hogy világosan látszódjon a behatolás és a független értékelıi tesztelés iteratív természete, ahogy azt a sebezhetıség vizsgálatra koncentráló megközelítés megköveteli. A (kezdeti) teszt eredmények vagy új teszteseteket határoznak meg (pl. egy hipotézis kivitelezhetıségének az eldöntése, vagy egy hipotézis optimális tesztelési módjának a meghatározása), vagy olyan részeredményeket hoznak, amelyekbıl új tesztek születnek (pl. egy hardver hiba beiktatásával létrehozott teszt újabb elektromos tápellátást érintı tesztet vonhat maga után, hogy a megtalált hiba típust kihasználó módszert találjunk). Az új tesztek elemzéséhez és meghatározásához már biztos szükség van a komponens szintő tervek elemzésére is.


60


A „Teszt eredmények elemzése” – „új hipotézisek és tesztek kidolgozása” ciklus többször ismétlıdhet. Ezen a ponton általában befejezıdik az ASDV, ASTE és ASGD összes munkaegysége. Elképzelhetı viszont, hogy az ASTE_IND kiegészítı funkcionális tesztjei nem készülhetnek el addig, amíg nem kerül sor a „Végsı tesztek végrehajtása” tevékenységre. 6.3.2.5. A végsı tesztek végrehajtása Már említettük, hogy a „Teszt eredmények elemzése” – „új hipotézisek és tesztek kidolgozása” ciklus többször ismétlıdhet. A „Végsı tesztek végrehajtása” azt az állapotot jelenti, amikor a legutolsó tesztet is végrehajtották és a sebezhetıség vizsgálat is befejezıdött. 6.3.3. A két megközelítés összehasonlítása és javasolt alkalmazásuk A lineáris struktúra követése viszonylag egyszerővé teszi a rendszer értékelési jelentés elkészítését, de ugyanakkor viszonylag könnyő kihagyni a biztonsági követelmények különbözı szintő leírásainak kapcsolatait, valamint a kapcsolatot a dokumentációk és a mőködı STOE között. A lineáris megközelítés segítségével átfogó és hatásos biztonsági értékelést lehet végrehajtani. Ugyanakkor nem a leghatásosabb módja az értékelés levezetésének és dokumentálásának. Tapasztalatok szerint az STOE tervezési reprezentációinak megértése általában minden értékelı számára nehéz feladat, és ez még nehezebb, ha nem az STOE (elméleti vagy gyakorlati) mőködésére koncentrál. Veszélyt jelenthet az is, hogy a sebezhetıség vizsgálatot, és a behatolás tesztet a folyamat végére hagyják, mert így erre általában kevesebb idı jut a határidı szorítása miatt, vagy stresszes körülmények között hajtják végre, ami nem kedvez a kreatív és pontos munkának. Mivel a sebezhetıségek megtalálása és bemutatása az értékelés kritikus része, ezt a veszélyt érdemes elkerülni. A sebezhetıség vizsgálatra koncentráló megközelítés arra a meggyızıdésre épül, hogy a rendszer biztonsági értékelés alapvetı célja a sebezhetıségek feltárása. A sebezhetıségek feltárását pedig jobban szolgálja az a szemlélet, amely az STOE sebezhetıség vizsgálatára és gyakorlati használatára koncentrál, az értékelés minél korábbi fázisában. Ennek a megközelítésnek a hátránya, hogy nehézséget okoz néhány (a hagyományos lineáris megközelítés esetén egyszerre elvégezhetı) értékelıi tevékenység különbözı munkafázisokra bontása és külön elvégzése. Ez különösen a tervezési és útmutató dokumentumokat érinti, ahol ebben a megközelítésben idıben is elkülönülnek a „kezdeti megismerés”, „elemzés” és „elemzés befejezése” munkafázisok. Mindkét megközelítés életképes, az elınyök kihasználhatók, a hátrányok pedig kezelhetık.


61


SAP-A esetén a sebezhetıség vizsgálatra koncentráló megközelítés valószínőleg könnyebben alkalmazható, mert ezen a szinten az értékelınek az azonosított lehetséges sebezhetıségek alapján csak automatikus eszközökkel kell behatolás tesztelést végrehajtania. SAP-F és SAP-K esetén az értékelınek egy független sebezhetıség vizsgálatot is végre kell hajtania az STOE lehetséges sebezhetıségeinek azonosítása érdekében., s ehhez fel kell használnia az útmutató dokumentációkból, a biztonsági architektúra leírásból, a rendszer interfész specifikációból, az STOE tervbıl és rendszer-mőködési biztonsági koncepcióból kinyerhetı ismereteket. Ez a független sebezhetıség vizsgálat valószínőleg könnyebben megoldható a lineáris megközelítés esetén, ahol az elvégzéséhez szükséges ismeretek már elıállnak a végrehajtás tervezett idıpontjára. A két megközelítés közötti választásban ugyanakkor az értékelıi csapat személyi összetétele is szerepet játszhat. Attól függıen lehet (akár értékelési projektenként) választani a két sorrend között, hogy az értékelık között a „gyakorlat orientált”, vagy az „elméleti megközelítést elınybe részesítı” munkatársak vannak-e többségben. Valószínőleg az elıbbieknek a sebezhetıség vizsgálatra koncentráló, az utóbbiaknak pedig a lineáris megközelítés lesz a könnyebben megvalósítható sorrend.

7. Mellékletek -

8. Bibliográfia Chris McNab: [Network Security Assessment] O`Reilly, 2008 Federal Office for Information Security (BSI): [A Penetration Testing Model - Study] http://www.cgisecurity.com http://www.owasp.org/index.php/Top_10_2007 http://www.phenoelit.de/dpl/dpl.html http://www.sans.org/score/checklists/linuxchecklist.pdf http://www.sans.org/score/checklists/Win2K_XP_Checklist.pdf http://www.sectools.org http://www.sqlsecurity.com VLA-Centric Evaluation: Improving Evaluations by putting Vulnerability First (Tony Boswell és Steve Hill)


62


9. Rövidítésgyőjtemény A 26. táblázat a dokumentumban használt rövidítéseket adja meg. 26. táblázat – A dokumentumban használt rövidítések Rövidítés ACL API ASCM ASDV ASDV_ARC ASDV_OSC

Angol Access Control List Application Programming Interface Assurance: System Configuration Management Assurance: System Development ASDV: Security Architecture ASDV: Operational Security Concepts

ASDV_SDS ASDV_SIS ASGD

ASDV: STOE Design ASDV: System Interface specification Assurance: System Guidance documents

ASST

Assurance: System Security Target

ASTE ASTE_COV ASTE_DPT ASTE_FUN ASTE_IND ASVA

CC CD CEM CIFS DLL

Assurance: Security Tests ASTE: Coverage ASTE: Depth ASTE: Functional tests ASTE: Independent testing Assurance: System Vulnerability Assessment Active Server Pages Assurance: System Vulnerability Assessment ASTE: Vulnerability Analysis Federal Office for Information Security (Germany) Common Criteria Compact Disk Common Evaluation Methodology Common Internet File system Dinamic Link Library

DVD DNS DoS EKK FTP GUI HTTP HTTPS ICMP IDS IIS IP IPS IRC

Digital Video Disk Domain Name System Denial of Service --File Transfer Protocol Graphical User Interface Hypertext Transfer Protocol Secure http Internet Control Message Protocol Intrusion Detection System Internet Information Service Internet Protocol Intrusion Prevention System Internet Relay Chat

ASP ASVA ASVA_VAN BSI

Magyar Hozzáférés ellenırzési lista Alkalmazás programozói interfész “Rendszer konfiguráció kezelés” garanciaosztály “Rendszer fejlesztés” garanciaosztály Biztonsági architektúra garanciacsalád Rendszer-mőködési biztonsági koncepció garanciacsalád STOE terv garanciacsalád Rendszer interfész specifikáció garanciacsalád “Rendszer útmutató dokumentumok” garanciaosztály “Rendszer biztonsági elıirányzat” garanciaosztály “Rendszer tesztelés” garanciaosztály Lefedettség garanciacsalád Mélység garanciacsalád Funkcionális tesztek garanciacsalád Független tesztelés garanciacsalád “Rendszer sebezhetıség felmérés” garanciaosztály Aktív szerver oldalak “Rendszer sebezhetıség felmérés” garanciaosztály Sebezhetıségi elemzés garanciacsalád Szövetségi Informatika Biztonsági Hivatal (Németország) Közös szempontok Kompakt lemez Közös értékelési módszertan Közös Internet fájl rendszer Dinamikus csatolású könyvtár (alkalmazás kiterjesztés) Digitális videó lemez Tartomány név rendszer Szolgáltatás megtagadás (támadás) e-Közigazgatási Keretrendszer Fájl továbbítás protokoll Grafikus felhasználói interfész Hipertext továbbító protokoll Biztonságos HTTP Internet vezérlıüzenet protokoll Behatolás észlelı rendszer Internet információs szolgáltatás Internet protokoll Behatolás megelızı rendszer Internet csevegés


63


Rövidítés ISAPI IT JSP KOP LDAP MBSA NNTP NTFS NTLM RAS RPC SAM SFR SOAP SMB SQL SSH SSL STOE TCP TNS TOE UDP USB URI URL VNC VPN WLAN XML

Angol Internet Server Application Programming Interface Information Technology Java Server Pages --Lightweight Directory Access Protocol Microsoft Baseline Security Analyzer Network News Transfer Protocol Windows NT File System NT LAN Manager Remote Access Service Remote Procedure Call --Security Functional Requirement Simple Object-access Protocol Server Message Block Structured Query Language Secure Shell Secure Sockets Layer System Target of Evaluation Transmission Control Protocol Transparent Network Substrate Target of Evaluation User Datagram Protocol Universal Serial Bus Uniform Resource Identifier Uniform Resource Locator Virtual Network Computing Virtual Private Network Wireless Local Area Network Extensible Markup Language

Magyar Internet szerver alkalmazás programozói interfész Információs technológia, informatika Java szerver oldalak közigazgatási operatív program Könnyített könyvtár elérési protokoll Microsoft alap biztonsági vizsgálóeszköz Windows NT fájl rendszer Távoli hozzáférés szolgáltatás Távoli eljáráshívás Windows NT jelszó adatbázis Funkcionális biztonsági követelmény Egyszerő objektum-hozzáférés protokoll Szerver üzenet blokk (protokoll) Strukturált lekérdezı nyelv Biztonságos csatorna Biztonságos kapcsolati réteg Rendszer értékelés tárgya Átvitel vezérlési protokoll Transzparens hálózati alap Értékelés tárgya Felhasználói adat protokoll Univerzális soros busz Egységes erıforrás azonosító Egységes erıforrás helymeghatározás Virtuális hálózati számítás Virtuális magán hálózat Vezeték nélküli lokális hálózat Bıvíthetı jelölınyelv

10. Fogalomtár -

11. Ábrák 1. ábra - A behatolás tesztelés lehetséges osztályai 2. ábra - A lineáris értékelési struktúra 3. ábra: a sebezhetıség vizsgálatra koncentráló értékelési struktúra

12. Képek -


64


13. Táblázatok 1. táblázat - A rendelkezı hivatkozások elérhetısége 2. táblázat – A fájl kiterjesztés, a technológia és a platform kapcsolata 3. táblázat - Session azonosítók és a kapcsolódó webes alkalmazás szerverek 4. táblázat – A 10 leggyakoribb sebezhetıség 5. táblázat – Gyakori SQL szerverekhez kapcsolódó portok 6. táblázat – Nessus 7. táblázat – Nmap 8. táblázat – Wireshark 9. táblázat – Snort 10. táblázat - Metasploit Framework 11. táblázat – Tcpdump 12. táblázat - Cain & Abel 13. táblázat - John the Ripper 14. táblázat - GFI LanGuard 15. táblázat – SuperScan 16. táblázat - Sysinternals tools 17. táblázat – Retina 18. táblázat – BackTrack 19. táblázat – Ntop 20. táblázat – Ngrep 21. táblázat – PwDump 22. táblázat - Acunetix Web Vulnerability Scanner 23. táblázat - MBSA - Microsoft Baseline Security Analyzer 24. táblázat – Winfo 25. táblázat – A biztonsági témákban leghasznosabb elérhetıségek 26. táblázat – A dokumentumban használt rövidítések

14. Verziószám V3


65

ÚTMUTATÓ RENDSZER ÉRTÉKELİKNEK

Recommend Documents