Hekk II.

Előző számunkban áttekintettük a legfontosabb támadástípusokat, essen most szó a védekezés lehetőségeiről is. Felmerül a kérdés, hogy egyáltalán van-e esélyünk arra, hogy "bombabiztos" rendszert állítsunk fel, lehet-e tenni a betörések ellen egyáltalán valamit. Csodaszer nincs, de általános elvek vannak, amelyek merev, néha komoly áldozatokba ütköző betartása árán közel nullára lehet leszorítani egy rendszer feltörésének esélyét. Ezeket azonban tényleg nagyon komolyan be kell tartani. A sikeresen végrehajtott betörések általában valamely ilyen alapelv súlyos elhanyagolására vezethetők vissza. Meg kell jegyezni, hogy ha mindent teljesen biztonságosan akarunk csinálni, a rendszer karbantartása nagyon macerás lesz.

Az általános jellegű védelmi módszereknek két alapvető fajtája van: a passzív és az aktív.

A passzív módszerek esetében nem végzünk konkrét intézkedéseket, csak a rendszert alakítjuk minél kevésbé feltörhető formába. Ez nagyon praktikus, mivel nem igényel extra fejlesztést vagy software-eket, hanem csak némi rendszergazdai tapasztalatot. Az aktív módszerek esetében viszont már tényleges változtatásokat is végzünk a rendszeren, külön software-rendszerek figyelik a behatolásokat, illetve riasztanak, vagy megpróbálkoznak az elhárítással. Ezek a módszerek természetesen mindig megelőző jellegűek, így soha nem lehetnek elég konkrétak. Lássunk néhányat!

Minimális szolgáltatások elve: törekedni kell arra, hogy a lehető legkevesebb szolgáltatást nyújtsa kifelé a gép, mert annyival is nehezebb bejutni valamelyiken. Mindig, minden szolgáltatás meglétével legyünk tisztában, és ezt időnként portscan-nel ellenőrizzük is.

Szolgáltatások szeparációja: az egyes szolgáltatások minél nehezebben legyenek egymásból elérhetők. Minél inkább sikerült ezt megvalósítani, annál kisebb a nemkívánatos kölcsönhatások előfordulásának esélye.

Iskolapélda ennek hibájára, amikor az FTP területet Weben keresztül is el lehet érni, élő példa erre a www.apache.org. Nyár elején törték fel, viszonylag korrekt holland hackerek voltak. A dolog érdekessége, hogy nem használtak semmiféle buffer overrun-t vagy social engineering-et, hanem csak és kizárólag (sportból! :)) konfigurációs hibákra mentek rá. Először a klasszikus anonymftp-vel feltöltött CGI script segítségével szereztek shellt, majd a rootként futó mysql adatbázissal hoztak létre adatbázisokat nem szokványos helyen, és ezen keresztül csináltak valahogy rootshellt. Ők maguk is leírták, hogyan tették mindezt. A dolog azért volt különösen veszélyes, mert ha rosszindulatúak, akkor megtehették volna, hogy az eredeti beszerzési helyükön trójai kódrészletet tesznek az Apache web-szerverbe, amivel kemény százalékpontokkal növelték volna a konkurencia végső győzelmének esélyét. De ezt nem tették meg. Természetesen a biztonság kedvéért a gépet teljesen újrainstallálták a rendszergazdái. A gépen egyébként FreeBSD futott.

Érdekes kísérlet egy biztonságos web-szerver létrehozására: winchester nélküli gép, oprendszer és minden egyéb CD-ről fut...

Minimális jogosultságok elve: igyekezni kell mindentől és mindenkitől minden jogot elvenni, mert így sokkal nehezebb lesz a gépre betörni. Alapból mindenkinek éppen csak annyit szabad megengedni, hogy a feladatát még épphogy el tudja látni.

Aktív módszerek

A következő "érdekes" aktív módszereket tartom érdemesnek leírni:

Behatolás-detektáló scriptek: olyan dolgokat periódikusan figyelni, amelyeket a behatoló általában el szokott követni. Ilyen például, hogy interaktív shellt indít, megváltoztatja a honlapot, vagy hasonló. Ezeket kell időnként ellenőrizni. Hasznos lehet a parancsshell átírása úgy, hogy:

– indulása után megnézze, hogy ő root-e;

– ha igen, akkor azt, hogy interaktív root-e;

– ha igen, akkor azt, hogy az első parancs, amit adtak neki, az volt-e, hogy "kismacska";

– ha nem, akkor riasszon, de gyorsan!

...honnan is tudhatná a szerencsétlen hacker vagy cracker, hogy mit is kellene beírnia. :)

Másik trükkös dolog a csapdagép. Ez egy olyan számítógép, amit ténylegesen is használnak, de csak nem kulcsfontosságú adatok vannak rajta, valamint kívül van a rendszer összes védelmén, és kívülről jól látható. Ugyanakkor tele van aktív védelmi scriptekkel, dezinformációkkal. Nagyon valószínű, hogy a betörők először ezzel a géppel fognak próbálkozni, és onnantól félig már nyert ügyünk is van, mert már tudjuk, hogy kik, honnan jönnek, mit csinálnak éppen...

A védelemhez szorosan kapcsolódik az események pontos rögzítésének igénye. Ez nem csak azért fontos, hogy felfedjük a behatolással próbálkozók kilétét, hanem rendszerünk esetleges hiányosságaira is fény derül belőle. Tipikus, hogy a hacker letörli az összes logot, ha teheti, vagy ha igényesebb, akkor "megszerkeszti". Ha ezt nem szeretnénk – és sok a papírunk –, loggoljunk nyomtatóra. :)

Védelem a rendszergazdával szemben

Nem Unix-okon, hanem IBM nagygépeken alkalmaztak egy biztonságtechnikai fogást, amivel a számítástechnika történetében egyedülálló módon lehetségessé vált a szerveren tárolt adatok megvédése még a szerver rendszergazdájától is. Ez normális körülmények között kivitelezhetetlen, mivel a rendszergazdai jogkörrel bármit meg lehet csinálni, semmiféle védelemnek nincs hatása, vagy ha mégis van, akkor azt a védelmet ki lehet kapcsolni. Amellett pedig a rendszergazda fizikailag is hozzáfér a géphez, ami miatt szintén bármit megtehet (például ha már végképp nem tud mit csinálni, akkor ki is kapcsolhatja a szervert, annak merevlemezeit egy másik gépbe teheti, és azzal a jelszavát visszaállíthatja egy általa kedvelt és ismert értékre. Tehát a rendszergazda ellen sehol a világon nincs védelem, sőt önmagában a védelem, mint olyan is értelmetlen. Kivéve bizonyos fajta mainframe-eket.

Az IBM a következő megoldást alkalmazta. Szétvágta több részre a rendszergazda funkcióját, legalább háromra. Az első maradt a közönséges rendszergazdai feladatokat ellátó személy, tehát a gép software-es karbantartója, főkezelője. Azonban hardware-es részekhez való hozzáférését megtiltották, tehát nem mehetett be a géphez csak úgy (például egy merevlemezt kicsit megbütykölni). Emellett pedig a rendszer az ő számára is kőkemény jogosultságokat vezetett be, amelyeket nem tudott áthágni. Tehát ha valami fontos, titkos file-hoz nem férhetett hozzá, akkor a saját gépére kellett volna betörnie, hogy ezt megtehesse. A jogosultságokat viszont nem tudta befolyásolni, mert ez egy harmadik személy, a security manager feladata lett. Ő mindenkinek tudta módosítani a jogosultságait, de ezen kívül semmihez sem volt joga.

Ezért aztán ahhoz, hogy titkos adatokhoz hozzáférjenek, a három tényezőből (hardware-es karbantartó, rendszergazda es security manager) legalább kettőnek össze kellett fognia, ami lényegesen kevésbé valószínű, mint az egyes személyek magánakciója. Persze ez a megoldás, a mai zsebpénzből megcsinált (egyébként minden más szempontból nagyon is gazdaságos) AMD proci által hajtott egyprocesszoros Linuxos PC szervereken nem kivitelezhető (csak éppen ugyanakkora teljesítmény kerül velük ötvenedannyiba).

Különösen emlékezetes, egyedi sec. hole-ok

X -config: Az X szerver, mivel alacsony szinten kezeli a videokátyát, linux alatt root jogokkal fut. Ezért képes a /etc/shadow olvasására is. A -config /etc/shadow opcióval ezt a file-t mint egy konfigurációs állományt adtuk meg neki, amit természetesen nem tudott értelmezni – és vissza is jelezte, hogy "nem tudom értelmezni a következő parancsot: ..." és a /etc/shadow első sorát. Benne az elkódolt root-jelszóval... ez a lyuk, mióta shadow van, mindenkinek kiszúrta a szemét, mégis csak most vették észre.

wuftpd LD_PRELOAD: Régebbi wu-ftpdkben kliens oldalról lehetett módosítani a szerver környezeti változóit is. Ez addig nem is volt gond, amíg meg nem jelentek a sharedlibek. De utána... az LD_PRELOAD környezetváltózóval egy tetszőleges sharedlib-et be lehetett linkelni az ftpdaemon elé, ami felülbírált néhány rendszerhívást valami trójai kóddal. Ebben az volt a nevezetes, hogy nem a wuftpd fejlesztői követtek el hibát, hanem maga a software-környezet, amiben a wuftpd működött, az alakult át úgy, hogy ami korábban még jó kód volt, most már nem volt az.

Heroin: Az ismert kábítószerrel szemben ez inkább a "hero" és az "in" szóösszetételből származhat. Nem igazi exploit, mivel nem lehet vele feltörni egy gépet, ellenben egy már feltört gépen, ha direkt ez nem jut a rendszergazda eszébe, akkor örök időre be lehet betonozni magunkat. A heroin ugyanis egy kernelmodul, ami láthatatlan processzek, láthatatlan file-ok létrehozását teszi lehetővé, mondani sem kell, hogy erre nem számító rendszergazda esetében milyen eredménnyel. Elsősorban a heroin hatására vert gyökeret linuxos körökben az a nézet, hogy az egyszer feltört géppel semmit nem lehet már csinálni, hanem újra kell installálni. Fura kettősség, hogy azt a linuxot kell ekkor újrainstallálni, amit egyébként – kellő, egyáltalán nem bennfentes tudás birtokában – soha semmilyen más esetben sem szükségszerű.

A legősibb DoS: a forkbomba. A forkbomba egy lokális DoS támadás, rosszul konfigurált gépet másodpercek alatt le tud fagyasztani. Szinte bármilyen nyelven megírható, egysoros kis programocska, amely nem tesz mást, mint végtelen ciklusban önmagát duplázgatja. Bizonyos szempontból ezért a vírusokra is hasonlít. Már akkor létezett, amikor a Unix-ot még assemblerben írták, és valószínűleg még akkor is létezni fog, amikor már nem C-ben fogják írni :) ...noha jelentőségét teljesen elvesztette, mióta szabályozni lehet az egy felhasználó által lefoglalható maximális memóriát.

Érdekességképpen a forkbomba kódja C nyelven:

#include <stdlib.h>

int main() {

for(;;) fork();

}

/* a fork() hívás végzi el a duplázást */

És shellscriptben:

while ./a & do ./a & done

ahol a helyi könyvtár "a" nevű file-ja ez a script.

f0 0f c7 c8 hiba: Az Intel, mint tudjuk, nem a tökély mintaképe. Ez körülbelül 3 évvel ezelőtt is megmutatkozott, amikor is találtak egy olyan byte-sorozatot, melynek hatására a Pentium processzor lock-olja a rendszerbuszt, és elfelejti levenni róla. (Egyébként az összes többi processzorcsaládjában vannak érdekes hibák.) Ez a hiba is egy lokális DoS. Ráadásul maga a kód egy atomikus feltételes adatcsere, amit bármely felhasználó végrehajthat. Sokáig (órákig :)) azt hitték, hogy nem is lesz ellene védelem, de egy nagyon súlyos, bitbabrálás szintű módszerrel mégiscsak ki tudták védeni software-esen is ezt a hardware-hibát. Néhány óra alatt kijött a FreeBSD, majd ezután a Linux védelem. Addig persze bármely internetszolgáltatót is meg lehetett zavarni egy egyszerű bináris byte-kóddal (perl exploit is van). A dolog érdekessége, hogy ez egy software-esen kijavított, hardware-es sec. hole. Másik érdekesség, hogy az NT-hez az első patch (néhány hét alatt ki is jött) úgy működött, hogy minden programinduláskor megnézte, hogy az adott kód tartalmazza-e ezt a stringet, és ha tartalmazta, akkor nem indította el...

Pentiumon a fenti byte-kód invalid opcode (kb. érvénytelen művelet) hibát csinált, így végrehajtása helyett a 6-os számú megszakításnak kellene bekövetkeznie. Ehhez azonban be kell olvasni a 6-os interruptvektort, ez a lock-olt adatbusz miatt nem sikerül. Kész, merev fagyás ezerrel, összes inteles rendszergazda retteg. A hiba javítása pedig úgy működik, hogy az interrupt-táblát laphatárra rakták úgy, hogy az invalid opcode interrupt vektorának beolvasása mindjárt laphibát is okozzon. Ekkor pedig mégiscsak sikerül rávenni a procit az adatbusz kilockolására. Ezzel persze a hiba kezelőjét kellett – csöppet sem túl egyszerűen – úgy átdolgozni, hogy meghívása esetén meg tudja állapítani, hogy ő nem a fent említett trükkös módon lett-e meghívva, kifejezetten egy f0 0f c7 c8 lekezelése céljából. Ez persze számottevően lassítana a rendszeren. A legtöbb interrupt elég ritkán hívódik meg ahhoz, hogy a dolog észlelhetően lelassítsa a rendszert, ez alól kivétel a laphiba. Annak lekezelése nagyon is sebességkritikus dolog. Szerencsére azonban vektora ebben a trükkös elrendezésben még a védetlen részbe esik... micsoda mázli!

...amint látható, sokszor még az alapos software-es felkészültség is kevés. Tehát a védelem fontos része, hogy bármely probléma fellépése esetén rendszerünket minél hamarabb újra tudjuk installálni. Ne érjük be ekkor az eredeti SOFTWARE-TERMÉK helyett pusztán a silány másolatokkal! Ez arra is feljogosít minket, hogy ha például 3 hónapot késik egy biztonsági hiba kijavítása, nyugodtan felhívjuk az ügyfélszolgálatot.

MaXX