Számítógépek és hálózatok biztonsága laboratórium (BMEVIHI4401) SEC-2 mérés. v1.0. Számítógépes rendszerek sebezhetőségi vizsgálata

Átírás

1 Számítógépek és hálózatok biztonsága laboratórium (BMEVIHI4401) SEC-2 mérés v1.0 Számítógépes rendszerek sebezhetőségi vizsgálata Tóth Gergely Hornák Zoltán Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék

2 Számítógépes rendszerek sebezhetőségi vizsgálata 1. Mérés célja Az Internet térhódításával egyre több szolgáltatás érhető el (kizárólag) a hálózaton keresztül. A szolgáltatások igénybevétele mellett azonban vele együtt megjelennek a visszaélések is. Az informatikai rendszeradminisztráció feladata ezen visszaélések megakadályozása. A jelen mérés célja annak bemutatása, hogy egy Internetre kötött szerver számítógépen futó szolgáltatásokat (felhasználóknak hálózaton keresztül elérhető funkciókat) miképp lehet távolról feltérképezni, milyen módszerek vannak a sebezhetőségek feltárására. Ezen a téren az úgynevezett megelőző-felderítő módszerek alkalmazása egy hatékony eszköz arra, hogy egy rendszer üzemeltetője a saját rendszerét vizsgálva előbb fedezze fel annak gyengeségeit, mint ahogyan azt rosszindulatú támadók kihasználhatnák. Figyelem: az itt bemutatásra kerülő eljárások nem csak megelőző-felderítő védekezésre, hanem támadásra is használhatók, így más tulajdonában álló rendszerek elleni illetéktelen használata törvénybe ütközik! Amennyiben valaki nem rendelkezik engedéllyel egy szerver távoli tesztelésére, úgy az itt bemutatott módszereket nem alkalmazhatja. 2. Elméleti háttér A következőkben röviden ismertetésre kerül a mérés sikeres elvégzéséhez szükséges ismeretanyag. Szolgáltatásokat nyújtó számítógép biztonságának növelése érdekében először meg kell ismerni azokat a technikákat, amelyeket egy lehetséges támadó alkalmazhat. Támadó alapvetően egy biztonsági rést keres, majd azt kihasználva tesz valamilyen kárt. Ennek elkerülése érdekében meg kell ismerni a biztonsági rések típusait, majd a lehetséges elvi ellenintézkedéseket Biztonsági rések A biztonsági réseket alapvetően két nagy csoportra lehet osztani, a technikai jellegűekre, valamint az emberi eredetűekre Technikai gyengeségek A technikai biztonsági rések a szerveren vagy éppen munkaállomáson futó szoftverben levő hibákból erednek. Ezen technikai biztonsági rések kiküszöbölése ennek megfelelően ugyanúgy technikai feladat. Felesleges szolgáltatások A legegyszerűbb biztonsági rés, amikor olyan szolgáltatások futnak egy szerveren, melyre nincs szükség. Mivel hasznos funkciókat nem nyújt, így teljesen feleslegesen okoz potenciálisan biztonsági rést.

3 Nem megfelelő beállítások Biztonsági rést okozhat, ha egy szoftver nem megfelelően lett beállítva. Sok program biztonságossá tehető kellő odafigyeléssel és szakértelemmel, ez azonban adott esetben nem történik meg. Default beállítások, mindenki számára elérhető szolgáltatások számos potenciális veszélyforrást rejtenek. Nem megfelelő szoftverek Biztonsági rést okozat nem megfelelő szoftver használata. Ez általában azt jelenti, hogy az idejétmúlt verziónak számos ismert hiányossága létezik, melyhez akár könnyen elérhető kihasználási útmutatók is találhatók. Hiányzó funkciók Biztonsági rés keletkezésére ad okot, ha a szerveren hiányoznak bizonyos funkciók. A hiányzó funkciók azért okoznak biztonsági réseket, mert miattuk olyan tevékenységet lehet elvégezni, melyre a szolgáltatásokat nyújtó szoftverek nincsenek felkészítve. Például amennyiben egy szerverre csak a telnet protokoll használatával lehet belépni, úgy ott a jelszó megszerezhető, és így az adminisztrátor akár meg is személyesíthető. Tehát hiányzik a biztonságos távoli bejelentkezés és feladat-végrehajtás lehetősége Humán veszélyforrások A technikai biztonsági réseken kívül léteznek az emberi (humán) biztonsági rések is. Egy szolgáltatás csak addig biztonságos, míg a hozzá tartozó jelszó titkos. Az emberi aspektus kellő szinten tartása csak képzéssel, valamint a megfelelő eljárási rend kialakításával és betartásával érhető el. Ezekkel a kérdésekkel jelen mérés során nem foglalkozunk Ellenintézkedések Miután áttekintettük a lehetséges biztonsági réseket, meg kell ismerkedni a lehetséges ellenintézkedésekkel. Az ellenintézkedések célja a biztonsági rések semlegesítése. Lehetőség van egyrészt magának a biztonsági résnek a megszűntetésére (pl. telnet lecserélése ssh-ra) vagy a feltételek módosítása olymódon, hogy az már ne okozhasson kárt (pl. telnet korlátozása intranetre). A következőkben ismertetésre kerül néhány alapelv, melynek alkalmazásával szolgáltatásokat nyújtó szerverek biztonsági szintje növelhető, tipikusan az ismertté vált visszaélések kivédése által Szolgáltatások minimalizálása A legtriviálisabb ellenintézkedés a felesleges szolgáltatások leállítása, hiszen az a szolgáltatás mely nem fut, nem használható ki rosszindulatúan Szolgáltatások biztonsági szintjének növelése Az első triviális lépés után a maradék szolgáltatásokat kell feljavítani. Beállítások felülvizsgálata Beállítások átgondolásával (a legtöbb szoftverhez létezik útmutató biztonsági beállításokhoz) számos olyan biztonsági rés szűntethető meg, mely nem magukból a használt szoftverekből ered, hanem azok nem megfelelő alkalmazásából. Pl. ha az adatbázisszerver csak belső

4 (UNIX) socketre hallgat és TCP/IP-n keresztül nem elérhető, úgy annak külső támadásától nem kell tartanunk. Biztonsági rések eliminálása Olyan szoftververziók alkalmazásával (patchek, javítóverziók), melyek nem tartalmaznak ismert biztonsági réseket, az ismert támadási módok kiküszöbölhetők. Pl. a PHP korai 4-es verziójában a fájlfeltöltés alkalmazásakor biztonsági rést keletkezett, amit azonban a legújabb verziók kiküszöbölnek. A különböző szoftverekben található biztonsági rések felfedezése alapvetően nem a rendszeradminisztrátor feladata. Ehhez számos segítség létezik: a legtöbb termék honlapján rendszeresen jelennek meg az új változatok, és amennyiben valamely verzióhoz biztonsági rést fedeztek fel, úgy általában megjelennek a patchek is; a legtöbb biztonság-kritikus szoftver dokumentációjában megtalálhatók a biztonság növeléséhez szükséges iránymutatók; léteznek kifejezetten biztonsági rések és veszélyforrások rendszerezésével, gyűjtésével foglalkozó honlapok és levelező-listák: o (Bugtraq) o Biztonsági megoldások alkalmazása Külön kategóriát képeznek azok az eszközök, melyek kifejezetten egy szerver biztonsági szintjét hivatottak növelni. A két legismertebb megoldás a tűzfal és az IDS. A tűzfal (firewall) feladata a nem megengedett forgalom kiszűrésre. Az IDS (Intrusion Detection System) pedig támadások detektálására és naplózására szolgál Biztonsági politika A biztonságot szem előtt tartva a mindent lehet, ami nem tilos szemlélet helyett át kell állni a minden tilos, ami nincs kifejezetten engedélyezve (need-to-know) elvre. Ez sajnos szöges ellentétben áll a felhasználó-barátsággal és a kényelemmel, de a biztonság érdekében ez szükséges. 3. Távoli vizsgálatok gyakorlati háttere Egy biztonsági rés kihasználása érdekében a támadó először felderíti a futó szolgáltatásokat és azok beállításait. Természetesen a következőkben bemutatott programoknak elsődleges célja nem a támadók eszköztárának bővítése, hanem hogy a rendszergazdáknak olyan lehetőségeket nyújtsanak, melyekkel saját rendszerük hiányosságait feltárják, kiküszöböljék azokat, így téve azt biztonságosabbá. Számítógépek hálózaton keresztüli távoli vizsgálatára, különféle információk begyűjtésére számos szoftver létezik (kisebb-nagyobb utility-k, komplex szoftverrendszerek), ezek nagy része megtalálható az átlagos UNIX/Linux disztribúciókban. A mérés és a további leírások során a TCP/IP protokoll stack alapvető ismeretét feltételezzük.

5 3.1. Távoli vizsgálat egyszerűen Az ebben a fejezetben ismertetett programok még alapvetően viszonylag kevés információval szolgálnak, azonban jelentőségüket nem szabad emiatt lebecsülni: számos támadási lehetőség alapját képezik és nagyon elterjedtek Ping A legegyszerűbb program a ping, melynek segítségével egy (nem megfelelően beállított) gépről eldönthető, hogy működik-e: az elküldött ICMP PING üzenetre egy ICMP PONG üzenettel válaszol. man ping Traceroute A traceroute paranccsal kideríthető, hogy egy távoli gépet milyen más gépek sorozatán keresztül érünk el. Ennek alapvető jelentősége a távoli gép fizikai helyének meghatározása és a közbülső routerek feltérképezése. man traceroute 3.2. Távoli vizsgálat fejlettebben: portscan Az egyszerű kis tool-okon túllépve ebben az ebben a fejezetben ismertetett portscan program már lényegesen több információval szolgál. Segítségével automatizáltan kideríthető, hogy a távoli gépen milyen szolgáltatások futnak. A portscan program gyakorlatilag megpróbál az összes lehetséges porton (vagy egyszerűbb esetben csak az ismert portokon) csatlakozni a távoli géphez és a nyitott portok alapján vonja le a következtetéseket.

6 A legismertebb protokollokat az alábbi táblázat foglalja össze: Protokoll név IP protokoll család Port Ping ICMP - DNS UDP 53 FTP TCP 21 SSH TCP 22 Telnet TCP 23 SMTP TCP 25 HTTP TCP 80 POP3 TCP 110 HTTPS TCP 443 MySQL TCP 3306 A fontosabb protokollok összefoglalása További funkció egy portscan programban, hogy képes nagy valószínűséggel megtippelni, milyen operációs rendszer fut a távoli gépen. Erre több módszer is létezik (néhányat lásd a következő fejezetben), azonban nmap lényegében a következőt végzi: az IP és TCP csomagokban található mezők értékeinek sajátosságai alapján jó eséllyel tippelhető meg az azokat generáló operációs rendszer és verziója. Bővebben lásd:

7 Fontos felismerni: minél kevesebb információhoz jut egy potenciális támadó, annál kevesebb esélye van egy sikeres támadás végrehajtásához. man nmap 3.3. Szolgáltatások felderítése Egy portscan elvégzése után megállapítható, hogy a távoli szerveren milyen szolgáltatások (pl. webszerver, SSH démon) futnak. Ezek után a következő lépés a szolgáltatásokat ellátó szoftverek típusának, verziójának kiderítése. Erre több módszer is létezik: Számos protokoll a kapcsolatfelvételkor megadja a másik félnek verzióját: SSH protokoll banner Webszerverek hiba esetén (pl. nem található oldal) általában a default hiba-oldallal térnek vissza, amely sok esetben tartalmazza a keresett információt: Apache az oldal nem található (error 404)

8 Számos dokumentált hiba (esetleg biztonsági rés) létezik, mely csak bizonyos programok esetén működik. Ezek kipróbálása sok esetben a fenti módszerek csődje mellett is működőképes Professzionális, komplex auditálás Nessus Az előzőekben bemutatott viszonylag egyszerűbb módszereken kívül olyan szoftverek is léteznek, melyek komoly biztonsági audit elvégzésével mérik fel egy távoli szerver (vagy akár egy egész hálózat) biztonságát. Ilyen program például a Nessus, mely az előzőekben említett egyszerű feladatokon kívül további funkciókat nyújt: a felismert szolgáltatásokról begyűjti a megszerezhető információt (a különféle bannerekből kideríthető a program típusa és verziója: pl. ProFTPD 1.2.5rc1 Server (Debian) [XXX.hu]) ismert biztonsági rések meglétét feltérképezi. Ezek alapján elkészít egy komplex sebezhetőségi jelentést (vulnerability report), melyben a talált hiányosságokat fontosság szerint rangsorolja, valamint amennyiben ismert, javítási lehetőségeket is javasol. vizsgált szerver Nessus szerver (errõl a géprõl indulnak a mérések) Nessus kliens (a konzol) Nessus architektúra Működési elve a következő: a biztonsági tesztelést egy UNIX gépen futó démon processz végzi, melyre TCP/IP-n keresztül grafikus felülettel rendelkező kliensekkel lehet bejelentkezni (létezik mind Windows-os, mind Linux-os kliens). A kliensben különböző session-öket lehet definiálni a különböző elvégzendő feladatokra, melyeket a kliensből kell elindítani, és ott is tekinthetőek meg az eredmények.

9 4. A rendszeradminisztrátor lehetőségei ellenintézkedések Két alapvetően fontos módszer van, mellyel drasztikusan növelni lehet egy szerver (egy hálózat) biztonságát. Egy jól beállított tűzfal rengeteg káros hálózati forgalmat képes kiszűrni, míg az IDS képes jelenteni, mikor ért bennünket támadás Tűzfal: IPTables Rengeteg tűzfal termék létezik, a következőkben a Linux 2.4-es kerneltől használt IPTables modulra korlátozzuk figyelmünket. Az IPTables segítségével minden egyes IP csomagra, mely valamely hálózati kártyán áthalad, szabályokat állíthatunk fel arra vonatkozóan, hogy mi legyen annak a csomagnak a sorsa: haladhat tovább, dobjuk el, pattanjon vissza, vagy naplózzuk-e az eseményt. Az IPTables elvéről áttekintés a következő címen található: Az IPTables konfigurációját pedig a következő oldal ismerteti:

10 A következő példa pedig egy egyszerű tűzfal beállításait tartalmazza: # resetting all chains # iptables -P INPUT ACCEPT iptables -F INPUT iptables -P OUTPUT ACCEPT iptables -F OUTPUT iptables -P FORWARD DROP iptables -F FORWARD iptables -t nat -F iptables -A INPUT -i eth1 -m state! --state RELATED,ESTABLISHED -j DROP # allow all connections out and only existing and related ones in # iptables -A FORWARD -i eth1 -o eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -i eth0 -o eth1 -j ACCEPT iptables -A FORWARD -j LOG # SNAT Masquerading functionality only on eth1 iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE IPTables példa IDS: snort Az széles körben használt IDS-es közül az egyik leggyakoribb a snort. A snort különböző szabályok alapján (melyeket a felhasználó saját maga is definiálhat, vagy letölthet az Internetről) dönti el, hogy vajon támadás alatt állunk-e. [**] [117:1:1] (spp_portscan2) Portscan detected from : 1 targets 21 ports in 20 seconds [**] 09/04-19:25: :4886 -> :19 TCP TTL:64 TOS:0x0 ID:5811 IpLen:20 DgmLen:40 ******S* Seq: 0xD2F0 Ack: 0x0 Win: 0x10 TcpLen: 20 Snort log példa

11 5. Mérési környezet A mérés során minden mérőcsoport saját gépen dolgozik. Ez a gép látja el a távoli szerver funkcióját, valamint ezen a gépen fog futni a csoport Nessus kliense is. A mérés 2. feladatához szükséges távoli felderítéshez minden csoport interaktívan (SSH-n keresztül) beléphet a közös szerverre. A saját és a közös gépre való belépéshez szükséges felhasználó és jelszó párost minden csoport a mérés során kapja meg. Közös Nessus szerver & távoli felderítéshez Távoli szerver & Nessus konzol Távoli szerver & Nessus konzol Távoli szerver & Nessus konzol Távoli szerver & Nessus konzol 1. Csoport 2. Csoport 3. Csoport 4. Csoport Mérési architektúra A mérés során használt gépek LINUX operációs rendszert futtatnak, ezért a LINUX alapvető ismerete hasznos a mérés elvégzéséhez. A csoportok által használt gépeken az alábbi szolgáltatások futnak: ssh szerver (22-es TCP port) telnet szerver (23-as TCP port) web szerver (80-as TCP port) mysql adatbázis szerver (3306-os TCP port)

12 6. Mérési utasítás Figyelem: a mérés elvégzése a mérési csoport saját távoli szerverén történik. Mivel a különböző szolgáltatások beállítása szükségessé teszi, minden mérési csoport adminisztrátori jogokkal rendelkezik ezeken a gépeken. A szerveren csak a mérési utasításban megkövetelt tevékenységeket lehet végezni. Új szolgáltatást nem lehet indítani, a konfigurációs változtatásokat pontosan dokumentálni kell a mérési jegyzőkönyvben! Fájlt csak a mérésvezető engedélyével lehet törölni! A mérés során a következő feladatokat kell elvégezni. A mérés eredményes lezárásához a mérés után egy Mérési jegyzőkönyvet kell elkészíteni és leadni. Ebben pontosan dokumentálni kell az eredményeket és elvégzett beállításokat. A mérési jegyzőkönyv pontos követelményeit a következő fejezet ismerteti. 1. Kiskérdések 2. Távoli szerver egyszerű távoli feltérképezése (ping, traceroute, nmap) Milyen operációs rendszer fut a távoli szerveren? Milyen szolgáltatások futnak a távoli szerveren és milyen szoftverek (gyártó, termék, verzió) látják el ezeket a feladatokat? Ellenőrizze ezeket a termékeket az Interneten (ez-e a legújabb verzió, léteznek-e ismert biztonsági lyukak ehhez a verzióhoz, javasolt-e az upgrade)! 3. Nessus scan #1 Gyűjtse ki a fontos jelentéseket és validálja azokat (nem vakriasztások-e)! Nézzen utána a valódi hiányosságoknak (pl. CVE, CAN besorolás alapján) és készítse el ezek rövid, magyar nyelvű ismertetését (ok, kihasználási lehetőség, javítás módja)! Sorolja be a fenti hiányosságokat (amelyek besorolhatók) a Landwehr taxonómiába (csak a genesis szerinti csoportokba)! A taxonómia elérhető on-line a következő címen: /1994landwehr-acmcs.pdf 4. Biztonsági szint növelése #1 Tiltsa le a felesleges szolgáltatásokat és a maradéknak növelje biztonsági szintjét! 5. Nessus scan #2 Mely biztonsági réseket sikerült eliminálni? 6. Tűzfal konfiguráció Konfigurálja be úgy az IPTables tűzfalat, hogy csak a szükséges hálózati forgalmat engedélyezze: o belülről minden TCP forgalom legyen engedélyezett,

13 o mindennemű UDP forgalom legyen tiltva, kivéve a DNS, o a szükséges szolgáltatások (HTTP, SSH) legyenek kívülről elérhetők, o további ötletekkel konzultáljon a mérésvezetővel! Specifikálja pontosan, mit tilt és mit engedélyez a tűzfal! Indítsa el és konfigurálja a tűzfalat! Ellenőrizze, hogy a konfiguráció megfelel-e a specifikációnak! 7. Nessus scan #3 Mely biztonsági réseket sikerült eliminálni és mik azok, melyek továbbra is veszélyeztetik a rendszert? 7. Mérési jegyzőkönyv A mérési jegyzőkönyv dokumentálja, hogy a mérőcsoport melyik feladatokat hogyan végezte el a mérés során. A jegyzőkönyv elkészítése során törekedjen a szabatos, magyar nyelvű megfogalmazásokra, valamint a pontosságra. Részletesen írja le, hogy az egyes feladatok során mit csinált. Ahol az a megértést elősegíti, készítsen ábrát. A jegyzőkönyveket kinyomtatva, papíron kell beadni. A mérési jegyzőkönyv a következőket mindenképpen tartalmazza: mérőcsoport (név, NEPTUN-kód), mérésvezető, dátum, időpont, mérés helye, mérési architektúra, 2. feladat eredményei (távoli felderítés), 3. feladat eredményei (Nessus jelentés fontosabb részletei, validálás, Landwehr besorolás), 4. feladat során elvégzett beállítások, megszűntetett biztonsági rések az újabb Nessus teszt alapján, tűzfal konfiguráció dokumentálása (specifikáció, tűzfal szabályok, működés vizsgálatának leírása és eredménye), végső Nessus teszt következtetései.