Hálózatbiztonság– MÉRÉSI SEGÉDLET –

Készítette: Fodor Péterfodorp@david.ttt.bme.hu

Átdolgozta: Pallos B. Richárdpallos@tmit.bme.hu

verzió 1.0

Budapesti Műszaki és Gazdaságtudományi EgyetemTávközlési és Médiainformatika Tanszék

2006.

Tartalomjegyzék1 Alapok.................................................................................................................................3

1.1 A biztonságról általában.............................................................................................31.2 Kliens-Szerver modell................................................................................................31.3 Biztonságos kommunikáció [2]..................................................................................41.4 Biztonsági elvek..........................................................................................................4

2 Támadási módszerek...........................................................................................................52.1 Belső támadás.............................................................................................................52.2 Social Engineering......................................................................................................62.3 Külső támadás.............................................................................................................6

2.3.1 Hamisítás alapú támadások.................................................................................72.3.2 Szolgáltatás lebénítása (Denial of Service, DoS)...............................................72.3.3 Információszerzés...............................................................................................8

3 Védekezési lehetőségek, módszerek...................................................................................83.1 Védekezés belső támadás ellen...................................................................................93.2 Védekezés külső támadások ellen.............................................................................10

3.2.1 Snifferek............................................................................................................103.2.2 Portscanek.........................................................................................................103.2.3 Távoli operációs rendszer detektálás (OS fingerprinting)................................12

3.3 Naplózás....................................................................................................................134 A hálózati forgalom védelme............................................................................................13

4.1 Az SSL/TLS protokoll [10]......................................................................................134.1.1 SSL kézfogás....................................................................................................144.1.2 A szerver hitelesítése........................................................................................154.1.3 A kliens hitelesítése..........................................................................................164.1.4 Titkosítási algoritmusok....................................................................................16

5 A Linux operációs rendszer biztonsági megoldásai..........................................................165.1 A chroot környezet....................................................................................................16

5.1.1 A chroot támadása.............................................................................................175.1.2 A szolgáltatások elzárásának biztonságos megoldása......................................18

5.2 A Pluggable Authentication Modules (PAM)...........................................................185.3 Az Access Control List (ACL).................................................................................195.4 Az Nmap portscan program......................................................................................205.5 A GrSecurity rendszermagfolt..................................................................................20

5.5.1 Hozzáférés-vezérlés (ACL)..............................................................................205.5.2 Hálózati kiegészítések.......................................................................................215.5.3 Rendszer kiegészítések.....................................................................................21

Felkészüléshez feladatok..........................................................................................................22Mérési feladatok........................................................................................................................23Segédletek a mérési feladatokhoz.............................................................................................24Irodalomjegyzék.......................................................................................................................25

2

„ ha ismerjük az ellenséget és ismerjük magunkat is, akkor száz csatában sem jutunk veszedelembe; ha azonban nem ismerjük az ellenséget, csak magunkat ismerjük, akkor egyszer győzünk, másszor vereséget szenvedünk; és ha sem az ellenséget, sem magunkat nem ismerjük, akkor minden egyes csatában feltétlenül végveszély fenyeget bennünket.”

Szun-Ce: A hadviselés törvényei

1 AlapokA számítógépes rendszerek bonyolultsági foka egyre inkább nő. Még a legjobb szakemberek sem ismerik részletekbe menően a pontos működési mechanizmusokat, így rendkívül nehéz arról meggyőződni, hogy egy rendszer tényleg úgy működik-e, ahogy kellene, valóban biztonságos-e [1].A mérés során a hálózatbiztonság kiemeltebb kérdéseivel fogunk foglalkozni a teljesség igénye nélkül, szubjektíven kiemelve részeket. A mérésnek nem célja támadási tippeket-trükköket ismertetnie, speciális hibák kihasználását megmutatnia, mivel ezen információk nagyon hamar elvesztik értéküket. A mérés sokkal inkább egy átfogó ismerethalmazt tartalmaz, mely igyekszik az elméletben tanult biztonsági szemléletet gyakorlati példákkal kiegészíteni.

1.1 A biztonságról általábanA biztonságot, mint fogalmat különböző szituációkban különbözőképpen értelmezhetjük. Informatikai rendszerek esetében nem elegendő, hogy egy rendszer jó, működőképes állapotban maradjon, hanem azt is meg kell gátolni, hogy bizalmas információk a rendszeren kívülre jussanak.Míg a biztonság fogalma pozitív oldalról közelíti meg a kívánt állapotot, addig a kockázat gyakorlatiasabb szemlélettel dolgozik: egy adott rendszert fenyegető veszélyeket veszi számba, és az általuk okozott károkat próbálja megbecsülni, összegezni. Informatikai rendszerek esetén – mivel a károk áttételesen továbbterjednek, és ez a hatás nehezen mutatható ki pénzben – a kockázat pontosan nem állapítható meg a gyakorlatban. Ezért inkább csak kockázatelemzésről, a kockázat csökkentéséről, menedzseléséről szokás beszélni ezen a területen. Az egyes fenyegető tényezők egymáshoz viszonyított kockázatbecslése az informatikai biztonság területén is jól kijelöli azon leggyengébb láncszemeket, ahol a védelmet célszerű erősíteni.Általában elmondható, hogy informatikai rendszerek esetén nem létezik tökéletes biztonság. A később bemutatásra kerülő módszerek és gondolatok a tudatos kockázatvállalás jegyében próbálják megvilágítani a biztonság sarkalatos kérdéseit. A biztonság növelésére irányuló erőfeszítéseknek a biztonságot olyan mértékre kell növelnie, melyet a védendő rendszer megkíván.

1.2 Kliens-Szerver modellAz Interneten keresztül elérhető szolgáltatások a kliens-szerver modell alapján működnek. A szolgáltatást nyújtó üzemeltet egy számítógépet, a szervert, ami a hozzá érkező kéréseket kiszolgálja. A szolgáltatást igénybe vevő felhasználó ehhez a szerverhez csatlakozik a saját számítógépével, a klienssel, általában az Internet hálózatán keresztül. Ebben a modellben a kommunikáció alapja általában az, hogy a kliens üzenetet küld a szervernek, melyben

3

valamilyen feladat elvégzését kéri tőle. Miután a szerver elvégezte a feladatot, visszaküld egy válaszüzenetet.A mérés során a hálózatbiztonsági kérdések gyökerének a kliens-szerver modellt tekintjük.

1.3 Biztonságos kommunikáció [2]Az, hogy két távoli fél biztonságosan szeretne kommunikálni egymással a konkrét esetektől függően jelentősen eltérő követelményeket is jelenthet. Az, hogy mit tekintünk biztonságosnak nagyon függ az adott szituációtól. Előfordulhat például, hogy a másik fél megbízható azonosítása alapkövetelmény, de lehet, hogy éppen az anonimitás biztosítása a kulcskérdés. Látni fogjuk, hogy a biztonságos kommunikációnak több egymástól függetleníthető és mégis egymással összefüggő összetevője van:

Sértetlenség: Annak garantálása, hogy hibamentesen (változás nélkül) ér célba egy elküldött üzenet, illetve egy esetleges hiba detektálható, így újraadással javítható.

Hitelesség: A sértetlenség önmagában még nem garantálja, hogy az üzenetet valóban az küldte, akit feltételezünk, pusztán azt, hogy a hálózati továbbítás során nem sérült. A hitelesség a sértetlenségen felül a vevő fél felé garantálja, hogy az adott üzenet a feltételezett küldőtől származik és annak tartalma nem módosult.

Letagadhatatlanság: A letagadhatatlanság a hitelességnél annyival több, hogy ez esetben nem csak a vevő felé, hanem tetszőleges harmadik személy felé is igazolható, hogy egy adott üzenetet (megrendelést, nyilatkozatot) a valódi küldő küldte, tettét letagadni nem tudja. A letagadhatatlanság követelményét csak az úgynevezett aszimmetrikus vagy nyilvános kulcsú kriptográfia módszereivel lehet biztosítani, amikor már a harmadik fél számára is bizonyítható, hogy az aláírást ki készítette.

Bizalmasság: A biztonságos kommunikáció kapcsán legtöbben a bizalmasság, avagy titkosság biztosítását értik. Kriptográfiai módszerekkel ugyanis elérhető, hogy olyan formában kódolva továbbítódjon egy üzenet, hogy azt egy támadó lehallgatva, a titkos kulcs ismerete nélkül ne értse meg, illetve szigorúbb esetben magának az üzenetnek a tartalmára még valószínűségi alapon se tudjon következtetni.

Távoli azonosítás: A mennyiben két fél személyesen még nem találkozott, illetve kettejük között nincs biztonságos (manipulálhatatlan, lehallgathatatlan) csatorna (pl. személyes találkozó), akkor egyéb módszerekkel, tipikusan külső szereplő(k) bevonásával kell biztosítani, hogy őket egymásnak biztonságosan mutassák be és a későbbiekben hitelt érdemlően tudják egymást azonosítani. Gyakorlatban a távoli azonosítást az úgynevezett elektronikus igazolványok rendszerével, illetve ezen igazolványok hitelességét biztosító PKI (Public Key Infrastructure) infrastruktúrával oldják meg.

1.4 Biztonsági elvekTitkolózásra alapozott biztonság (Security Through Obscurity, [3]) az olyan biztonsági intézkedések összefoglaló neve, amelyek arra építenek, hogy valamilyen információt titokban tartanak a támadók elől. (pl.: egy ismeretlen kódolási eljárás, biztonsági hibák titokban tartása, zárt forráskódra alapozott biztonság). Amennyiben ez a titok kiderül, akkor a biztonság sérül. Az ilyen technikák legjobb esetben is csak kiegészítő védelmi intézkedésnek felelnek meg, a tapasztalat azt mutatja, hogy ez az elv önmagában nem működik. Minden esetben úgy kell összeállítani a biztonsági rendszert, hogy ha a támadó pontosan ismeri a felépítését, akkor se legyen képes áthatolni rajta. Ilyen módszer minden általánosan ismert titkosító eljárás (DES, AES, SHA, stb…), ahol nem az eljárás titokban tartása a biztonság záloga, hanem az, hogy a kulcs ismerete nélkül a titkosított üzenet nem törhető fel ésszerű idő alatt. A titkolózásra alapozott biztonsággal szemben a Teljes közlés (Full Disclosure) elve áll.

4

Mindent tiltunk, azon kívül, amit kifejezetten engedünk. Gyakorlatban bevett szokás, hogy a bonyolult rendszerek biztonsági szabályozását nem a tiltások oldaláról közelítjük meg. Éppen ellenkezőleg, számba vesszük azon műveleteket, melyeket engedélyezünk, majd a hozzáférés vezérlést ennek megfelelően úgy építjük fel, hogy minden hozzáférés tiltása után engedélyezzük a rendszer működéséhez szükséges eljárásokat. Így nem fordulhat elő, hogy a biztonsági alapelvek tervezése közben bizonyos elemek tiltása elkerülje a tervező figyelmét, ami bonyolultabb rendszerek esetén igen könnyen bekövetkezhet.

2 Támadási módszerekA támadásokat kiváltó okok többfélék lehetnek, általában a következők valamelyike:

a támadó hasznot akar húzni a dologból, haszonszerzésre törekszik, előfordulhat, hogy el akarja adni más személyeknek a felhasználó adatait,

a támadó a szolgáltató megítélését, hírnevét akarja gyengíteni, ezzel kárt okozva a szolgáltatónak, mivel kevesebben bíznak meg benne ezután

a támadó bizonyos értelemben jó szándékú, csak a rendszer hibáira akarja felhívni a figyelmet

a támadás lehet egyszerű erőfitogtatás, szórakozás ugródeszka keresése más gépek feltöréséhez

A támadások megkülönböztethetők a szerint is, hogy a támadó a hálózaton keresztül, a hálózati biztonsági beállítások kijátszásával (külső); vagy e nélkül (belső) jut információkhoz, vagy bénítja meg gépünket. A támadások ellen elég nehéz konkrét megoldást nyújtani, de általánosságban elmondható, hogy a legtöbb esetben elkerülhetőek, kivédhetőek, ha megfelelően vannak beállítva a felhasználók jogosultságai, az erőforrásokhoz való hozzáférés, hálózati paraméterek.Nyilvánvaló, hogy a kliens és a szerver mind belső mind külső módon támadható, hiszen mindkettő kapcsolatban van a hálózattal. A köztük lévő hálózat esetén nem értelmezhető ez a megkülönböztetés.

2.1 Belső támadásBelső támadásnak nevezünk minden olyan támadási módszert, melyet olyan felhasználók valósítanak meg, akik már a rendszerrel szemben valamilyen bizalmi státuszban vannak (például van jelszavas hozzáférésük egy adott kiszolgálóhoz), így nem kell a hálózati biztonsági beállításait kijátszaniuk. A gyakorlatban a támadások nagy hányada belső támadás, ugyanakkor egy sikeresen megvalósított külső támadás célja sok esetben a rendszerhez való hozzáférés, és azon valamilyen belső támadás végrehajtása. A következőkben a belső támadások alapvető módszereit vesszük számba.

Fork bomba (fork bomb): Olyan program, amely a fork() rendszerhívás segítségével, saját magát több példányban elindítja, s így feleslegesen emészti fel a processzoridőt és memóriát. Védekezni ellene erőforrás korlátozással lehetséges.

Puffer túlcsordulás (buffer overflow): Programozási hiba folytán, ha egy puffer az adott méretén túlírható, akkor a függvény visszatérési címe átírható. Ennek az oka, hogy a C fordítók fordításkor nem figyelik a tömbhatár túllépést, illetve vannak olyan függvények, melyek nem ellenőrzik a puffer méretét írás előtt. Így az adott rendszeren a futó program jogaival tetszőleges más programok is futtathatók. Manapság egyre többféle megjelenése van ezen támadási formának. Nem csupán kiszolgáló programok, de akár ügyféloldali programok (pl. médialejátszó, webböngésző) ellen is készülnek hasonló támadást megvalósító kártékony programok.

Ismert tmp fájl támadás (known tmp filename attack): A lényege, hogy egyes programoknak a /tmp könyvtárba írt fájljainak neve kitalálható, így még a program

5

indítása előtt, ezzel a névvel létre lehet hozni egy linket, mely egy másik fájlra mutat. Ezzel az eljárással olyan fájlokat módosíthatunk, amelyhez egyébként nincs jogunk.

Exploit-ok: olyan előre gyártott programocskák, melyek minden különösebb szakértelem nélkül rendszergazdai jogköröket adhatnak az újdonsült támadóknak. Általában egy-egy program biztonsági hibái alapján készülnek, tudván, hogy nem minden rendszeren végzik el egy hiba bejelentése után az érintett programok biztonsági frissítését.

Ezekkel a módszerekkel lehetőség van a számítógépen tárolt adatok illetéktelen felhasználására. Régebben csak a szerveren tárolták a jelszavakat, ezért inkább a szervert kellett a támadások elleni védelemre felkészíteni. Az újabb böngészőkben megjelent azonban egy új kényelmi szolgáltatás, a felhasználó jelszavainak automatikus beírása. Ez felajánlja a felhasználónak, hogy adott felhasználói névhez tartozó jelszavát eltárolja, így a felhasználónak nem kell azt minden egyes alkalommal begépelnie. Így viszont egy újabb támadási pont keletkezik, ezúttal a kliens oldalon, hiszen ezek a jelszavak is egy fájlban tárolódnak valahol.

2.2 Social EngineeringA támadók legkönnyebben a felhasználók nem megfelelő jelszóválasztását és gondatlanságát kihasználva szerezhetik meg a jelszót. Ilyen támadáshoz nem is feltétlenül szükséges számítástechnikai ismeret. Nagyon gyakori, hogy a felhasználókat ismerve könnyen kitalálható az általuk használt jelszó, mivel az valamilyen kedvencük (háziállat, sportoló, zenész) neve, saját adatuk (születési hely, lakóhely, születésnap), stb. Szintén sűrűn előfordul, hogy a számítógép monitorára ragasztanak egy cetlit, amire felírják az általuk használt jelszót, így azt bárki láthatja.A Social Engineering [4] az emberek bizalomra való hajlamának kihasználása. A rossz szándékú támadók gyakran használják ezt a módszert a számítógépekhez való illetéktelen hozzáférésre és információk megszerzésére. A Social Engineering nem a hardver, a szoftver vagy a hálózat hibáit, hanem az emberi természet gyengeségeit használja ki a számítógépek feltörésére. Alkalmazásával bárki, aki csak minimális informatikai ismeretekkel rendelkezik, behatolhat egy biztonságosnak tartott rendszerbe, majd hozzáférhet, módosíthatja vagy akár törölheti az ott tárolt adatokat. A legjellemzőbb ilyen jellegű bűncselekmények körébe az "adathalászat" tartozik, amelynél a csalók különböző eszközökkel (például telefonhívás, e-mail) ráveszik a gyanútlan felhasználót, hogy árulja el jelszavát, adjon meg bizalmas adatokat, illetve számítógépén töltsön le, indítson el alkalmazást az elektronikus üzenetben kapott link segítségével.Habár úgy tűnik a szakmaiságtól elég messze áll ezen módszer, nagyon fontos gondolnunk a létezésére. Lehetséges ugyanis, hogy egy rendszer karbantartása esetén sok olyan emberrel kell együtt dolgoznunk, akikre (hálózatbiztonsági ismeretek hiányában) szigorúan bizalmas jelszavakat rábízni kockázatos.

2.3 Külső támadásKülső támadásnak nevezzük azokat a támadásokat, melyek a hálózati biztonsági beállítások kijátszásával próbálnak egy rendszerhez jogosulatlanul hozzáférni. A külső támadások irányulhatnak információ megszerzésére, törlésére, egy szolgáltatás megbénítására vagy speciális erőforrások jogosulatlan felhasználására (pl.: belső biztonsági rendszerhez hozzáférés, kiszolgáló erőforrásainak kihasználása, stb…).

6

2.3.1 Hamisítás alapú támadásokEzen támadások közös vonása, hogy az előállított protokoll üzeneteket valamilyen hamis információval töltik fel, így okozva nem várt működést a hálózatra kapcsolt eszközön.

IP cím hamisítás (IP address spoofing): az IP datagram alapú protokoll, melyben a kommunikáló felek építik fel a teljes IP fejlécet. Emiatt elképzelhető, hogy egy hálózati eszköz olyan üzenetet küldjön, melyben az IP datagram feladóját meghamisítja, abba nem a valós IP címét helyezi. Ugyan a feladó ekkor az IP útválasztása miatt nem kapja meg a válaszüzenetet, de látni fogjuk, hogy egyes támadások esetén erre nincs is szükség. Az esetek kis részében az IP hamisítás kiszűrheti például úgy, hogy bizonyos helyekről egyértelműen meghatározható címeket fogadunk csak el (pl. egy privát hálózatban gyanús lehet egy, a hálózati maszkhoz nem illő IP cím megjelenése), de általánosságban csak speciális protokollok segítségével bizonyosodhatunk meg az IP datagramokban levő IP címek valódiságáról (pl. IPSec).

Névszerver átejtés (DNS spoofing): a támadás lényege, hogy az áldozat egy névfeloldással hamis információt kapjon. Ez elérhető az áldozat DNS szerverének feltörésével, vagy hamis DNS válaszüzenet küldésével a DNS szerver nevében (a DNS lekérés UDP protokollon megy, egy megfelelő hálózati beékelődéssel pedig már nagyon könnyű meghamisítani a választ). A támadással elérhető, hogy az áldozat másik hálózati eszközzel lépjen kapcsolatba, mint amivel eredetileg szeretett volna. A DNS átejtéssel a támadó kikényszerítheti, hogy az áldozat kapcsolatot kezdeményezzen vele (pl. jelszóval elérhető szolgáltatás eltérítése esetén megszerezheti a jelszót, melyet a gyanútlan áldozat elküld neki).

TCP/UDP átejtés (TCP/UDP spoofing): Hibásan implementált protokollverem, vagy protokollhiányosságok miatt a már felépült, illetve kezdeményezett kapcsolatokat egy harmadik személy „elrabolhatja” vagy idegen csomagokat csempészhet bele.

2.3.2 Szolgáltatás lebénítása (Denial of Service, DoS) Szolgáltatás lebénítására irányuló támadási módszerek (Denial of Service, DoS) célja egy szolgáltatás lelassítása, megakasztása. DDoS (Distributed Denial of Service, Elosztott DoS támadás) esetén sok “ártatlan” számítógépre támadóprogramot telepítenek a tulajdonos engedélye (és akár tudta) nélkül, melyekről később egy időpontban indul “elosztott” támadás a célgép ellen. A támadott erőforrás alapján néhány példa DoS támadásokra:

A merevlemez kapacitás elleni támadás lehet olyan események előidézése egy adott hálózati kiszolgálón, melyek naplóbejegyzést okoznak. Rosszul tervezett kiszolgáló esetén a naplóbejegyzésekkel megtöltött merevlemez több szolgáltatás leállását is okozhatja (pl. levelezés, webszerver, stb.).

A számítási kapacitás elleni támadások a kiszolgálón nagymértékű processzorterhelést okoznak. A támadást általában olyan, nem várt eseményekkel váltják ki, melyekre a támadott program hibásan van felkészítve. Ilyen esemény lehet például egy nem specifikált értéket tartalmazó üzenet egy adott protokoll felett. Sikeres támadás esetén a támadott program végtelen ciklusba esve emészti fel a kiszolgáló számítási kapacitását.

A sávszélesség elleni támadásokat legtöbbször a már említett DDoS módszerrel valósítanak meg. Ilyenkor általában egy, az Interneten elérhető hálózati kiszolgáló hasznos forgalmát szeretnék kiszorítani nagymennyiségű haszontalan forgalom generálásával. A már több nagyvállalat Internetes portálja ellen bekövetkezett DDoS támadások tapasztalata, hogy ezen támadások kivédése általában nagyon sok pénzt és energiát emészt fel.

7

Egyéb hálózati erőforrás elleni támadások is elképzelhetőek. Ilyen lehet például akár egy DHCP kiszolgáló címterének szándékos kimerítése vagy egy hálózati switch MAC címtáblájának túltöltése is.

Néhány ismertebb gyakorlati példa DoS alapú támadásokra: SYN elárasztás (SYN flooding): Ez a támadási típus olyan TCP csomagokkal

árasztja el gépünket, melyekben a SYN flag értéke 1, azaz hatalmas mennyiségű kapcsolat kezdeményezését jelző csomagot kapunk, mely látszólag egy olyan géptől érkezik, ami nem érhető el. Mialatt gépünk a hamis SYN csomagok kiszolgálásával foglalkozik, nem marad elég erőforrása, hogy a valódi kapcsolatkezdeményezéseket kiszolgálja.Előfordul olyan SYN elárasztás is, mikor a támadó az áldozat címét helyezi feladóként a SYN üzenetbe, majd ezt nagyon sok helyre elküldi. Ebben az esetben a címzettek a hamis feladó alapján nem a támadó, hanem az áldozat felé küldenek nagyon sok SYN/ACK üzenetet. Ebben az esetben a támadónak nem is kell közvetlen kapcsolatban lennie az áldozattal.

Land attack: lényege, hogy valaki olyan csomagot küld, aminek a feladóját úgy hamisítja meg, hogy a címzettel essen egybe, ami egy végtelen ciklusba kergeti a fogadót, és bizonyos operációs rendszerek esetén a számítógép lefagyását eredményezi. Ezzel a módszerrel nem csak számítógépek, hanem routerek, hálózati nyomtatók is támadhatók.

Smurf attack: Egy adott hálózatban olyan ping csomagokat küldenek el broadcast üzenetként, melyben feladóként a megtámadni kívánt gép van feltüntetve. Ezért visszafelé hatalmas mennyiségű válaszüzenetet fog kapni a megtámadott számítógép, melyek fogadása teljesen felemészti a rendszer erőforrásait. Ilyen volt például néhány éve az Amazon elleni támadás is.

A halál pingje (Ping of Dead): A hálózati operációs rendszerek (UNIX, Windows, stb.) azon hibáját használta ki régen, miszerint olyan ICMP csomagot küldtek a támadott gép felé, mely 64 kB-nál nagyobb volt, s ettől a rendszer azonnal lefagyott. Az újabb verziókban már javították ezt a hibát.

Könnycseppek (Teardrop): Az ilyen jellegű támadások lényege az, hogy olyan TCP és UDP csomagokat küldünk a célgépnek, melyek fejléce valótlan adatokat tartalmaz. Számítógépünk ezen hamis adatok alapján próbálja meg összerakni a teljes csomagot, melynek eredménye az lesz, hogy gépünk iszonyatosan lelassul.

2.3.3 Információszerzés Szaglászás (Sniffing): Hálózati forgalmat figyelhetünk vele, mely segítségével

értékes információhoz juthatunk. Segítségükkel védekezni is lehet a támadások ellen, ezért bővebben a védekezésről szóló részben lesz róluk szó.

Portpásztázás (Portscan): Egy hálózati eszköz nyitott portjait ellenőrizhetjük e módszerrel. Szintén használható védekezésre is, így bővebben a védekezésről szóló részben lesz róla szó.

3 Védekezési lehetőségek, módszerekÁltalában nem állnak rendelkezésünkre konkrét, minden esetben tökéletes védelmet nyújtó védelmi módszerek. Vannak azonban általános elvek, melyek használatával minimálisra csökkenthető a támadás kockázata. Először nézzük végig a fenti támadási módszerek elleni védekezés formáit.

8

3.1 Védekezés belső támadás ellenA puffer túlcsordulás támadás ellen egyrészt gondos programtervezéssel és implementációval, másrészt a memóriatartalmat ellenőrző programozási segédeszközök használatával lehet. Az ismert tmp fájl támadást dinamikus tmp fájlokkal, illetve megfelelő szerverbeállítással is kivédhetjük. Az egyes programok folyamatos frissítéseivel, hibajavításaik használatával csökkenthetjük az általuk teremtett biztonsági lyukak számát, azonban minden ok nélkül ne cserélgessük a működő programjainkat. Először egy tesztgépen próbálkozzunk, és csak utána telepítsük az éles gépre a programokat.A támadás egyik lehetséges célpontja a szerver, ugyanis itt tárolják a felhasználók összes adatát, beleértve a jelszót is. Leggyakrabban az adatok valamilyen fájlban vagy pedig adatbázisban találhatók. Ezért nagyon fontos az adott fájlhoz vagy adatbázishoz történő hozzáférési jogosultságok megfelelő menedzselése. Ha lehetséges, akkor célszerű ezeket az adatokat valamilyen módszerrel titkosítani és így tárolni.Általában a Linux operációs rendszerek a felhasználóról az információkat, beleértve a kódolt jelszót is, a /etc/passwd fájlban tárolják, de ez a fájl mindenki által olvasható. A probléma ezzel az, hogy bárki letöltheti ezt, s megfelelő programok segítségével megpróbálhatja feltörni a kódolt jelszavakat. E probléma kiküszöbölésére találták ki a shadow passwd nevű fájlt. Ennek a lényege annyi, hogy a kódolt jelszavakra csak olyan programoknak van szüksége, melyek rendszergazdai jogosultsággal futnak, ezért a neveket és jelszavakat két különböző fájlban tároljuk. Amelyikben a jelszavakat tároljuk (shadow), ahhoz csak a rendszergazdának van hozzáférési joga.A jelszavakat általában egyirányú titkosítással kódolt formában tárolják (pl.: hash). Ez azt jelenti, hogy tipikusan a jelszótárolási technikáknál, nem magára a rejtjelezett adatra vagyunk kíváncsiak, hanem inkább a kódolt adatot hasonlítjuk össze, a rejtjelezve tárolt adattal. Ez csak akkor lehet azonos, ha ugyanazt a jelszót, adatot adtuk be a titkosító programnak. A probléma az, hogy ha ismerjük a titkosító eljárást, akkor próbálgatással kideríthető az eredeti jelszó. A próbálgatásra is többféle eljárás alkalmazható.Szótár alapú (Dictionary Based) támadás arra a feltételezésre épít, hogy a felhasználók többsége a saját anyanyelvének valamely szavát használja jelszóként. A program egy listából sorba veszi a szavakat, az ismert titkosító eljárással kódolja, s ha ez megegyezik a tárolt alakkal, akkor megvan a jelszó. A „Nyers erő” (Brute force) támadáskor a program az összes alfanumerikus karaktersorozatból tetszőleges sorrendben összerak szavakat, majd ezt kódolva hasonlítják a tárolthoz. Ezzel a módszerrel ugyan mindig megtalálhatjuk a jelszót, de nem mindegy, hogy mennyi időt fektetünk be. A jelszavak tipikusan ne legyenek túl rövidek, ne legyen értelmes szó, és tartalmazzon kis és nagybetűket, számokat is. A biztonságos használat érdekében célszerű a jelszót bizonyos időközönként lecserélni.A kliens oldalon leginkább a felhasználókat szabályozva védekezhetünk. Tudatosítani kell a felhasználóban, hogy mennyire fontos a jelszó titokban tartása. Nem engedhető meg neki, hogy azt leírva tárolja a számítógép közelében. Fel kell hívni a figyelmét arra, hogy ne engedje másoknak figyelni a billentyűzetet, miközben a jelszavát megadja. Az sem engedhető meg, hogy bárkivel telefonon közölje a jelszavát, még akkor sem, ha az a valaki esetleg az informatikai osztály alkalmazottjának mondja magát. A böngésző automatikus jelszóbeírásának használatát is érdemes tiltani. Ismertetni kell a felhasználókkal a jelszóválasztás fenti kritériumait. Amennyiben ezeket nem tartja be, akár büntető szankciókat is kilátásba helyezhetünk. Ilyen és ehhez hasonló szabályok alkalmazásával a kliens oldalt is biztonságosabbá tehetjük a belső támadásokkal szemben.A felhasználók csak kódolt formában levelezzenek, továbbá a szerver is képes legyen kódolt levéltovábbításra. Ehhez szükséges programok pl. a gpg, vagy pgp, illetve szerveroldalon pl. postfix-tls (levéltovábbító).

9

3.2 Védekezés külső támadások ellenA szolgáltatás megbénítására irányuló támadások ellen a leghatékonyabb védekezés a hálózati eszközök paramétereinek figyelmes beállítása, s maga a számítógép erőforrásaihoz való hozzáférés megfelelő beállítása. Például TCP SYN elárasztás ellen Linux alatt az alábbi beállítás szükséges a /etc/network/options fájlban: syncookies=yes, és spoofprotect=yes.A külső támadások ellen hálózatfigyelő, integritást ellenőrző programcsomagok használatával védekezhetünk. Ezen programok segítségével megoldódnak a szaglászásból származó problémáink, nyomon követhetjük adatforgalmunkat, titkosíthatjuk hálózati kapcsolatainkat, ellenőrizhetjük nyitott portjainkat. Óvatosan kell használni őket, mivel ugyanúgy használhatók védekezési és támadási célokra is. Két fő csoportjuk van, a sniffer-ek és a portscan-ek.

3.2.1 SnifferekA „sniffing”, szaglászás igazából egy szinonimája annak, hogy egy a számítógépen futó program segítségével betekintést nyerhetünk az adott hálózat adatforgalmába. Ennek általában két célja lehet:

Hibaelhárítás, hálózati adatforgalom elemzés, analízis. Felhasználói nevek és jelszavak jogosulatlan megszerzése.

Ezen programok működési alapja, hogy az adott számítógép a hálózatban nem csak a neki címzett csomagokra figyel, hanem az összes csomagra, mely a helyi hálózaton áthalad. Ezt a hálózati kártya ún. „promiscuous” üzemmódba történő átkapcsolásával lehet elérni. A snifferek futásának detektálása is a hálózati kártya promiscuous módjának beállításával függ össze. A detektorok működési elve a következő:A program végig pingeli a lokális hálózatot, így megkapja az összes hálózati interfész IP illetve fizikai (MAC) címét. Ezután az ARP cache-ben, ahol az IP címek össze vannak rendelve a hálózati kártya fizikai címével, véletlenszerűen összekeveri a megfeleltetéseket, majd újra végig pingeli a hálózatot. Amelyik számítógép erre is válaszol, annak a hálózati interfésze biztosan promiscuous módba van állítva, persze ez még nem biztos, hogy azt jelenti, hogy ő sniffert futtat, mert akad másfajta program is, mely átállítja a hálózati interfészt. A snifferek támadási célú felhasználása ellen az egyik leghatásosabb védekezési módszer az, ha az információkat kódolt formában küldjük át a hálózaton, így azokat a szaglászó programok nem tudják értelmezni, visszafejteni. A hálózati kommunikáció védelmével később, a 4. fejezetben foglalkozunk.

3.2.2 Portscanek„Még azt is meg kell jegyeznem, hogy ismeretes, hogy az nmap bizonyos gyengén megírt alkalmazások, TCP/IP vermek és még operációs rendszerek összeomlását is okozhatja.”

Fyodor az egyik legnépszerűbb portscan program írója saját programjáról

A portpásztázás egy eljárás, mellyel megállapítható, hogy egy távoli számítógépen mely portok vannak nyitva, zárva, vagy tűzfallal védve. A portscan szabályos vagy szabálytalan kapcsolatot kezdeményezés az összes vagy csak a privilegizált portokra. Ezáltal feltérképeződnek a számítógép támadható portjai, vagy egyszerűen futó szolgáltatásokat lehet meghatározni vele.. Mivel az 1–1024 portok előre meghatározott portok (well-known-ports), azaz a portszámhoz szolgáltatást rendeltek, mint (pl.: 21 ftp, 22 ssh, 23 telnet stb.), így a portszámból következtethetünk a vizsgált számítógép szolgáltatásaira.

10

Működésük általában igen egyszerű, ha ismerjük a TCP/IP modellben a kapcsolatkialakítás menetét. A program küld a célszámítógép vizsgálandó portjának egy kapcsolat kezdetét, vagy kapcsolat lezárását biztosító csomagot, majd vár a válaszra, melyből ki tudja deríteni azt, hogy az adott portszámhoz tartozó szolgáltatás fut-e a figyelt számítógépen vagy nem. A nyitott portok számának kiderítése fontos a gép védelme szempontjából, ugyanakkor egy nagyon jó támpont a célszámítógép feltörési stratégiájának kidolgozásához is. A számítógépek ellen irányuló támadások ezen részének felderítése eléggé egyszerű, hiszen a legtöbb portscan program sorban és egymás után nagyon gyorsan teszteli a PC portjait, így ha egy adott gépről sok kapcsolat indul a célgép különböző portjaira, akkor ezen számítógépeket érdemes kitiltani a számítógépes hálózatunkból.Sok rendszergazda rossz néven veszi, ha portscan alá veszik az általa felügyelt kiszolgálót. Általánosságban elmondható viszont, hogy a manapság elterjedt operációs rendszerek által implementált TCP és UDP protokollvermek ezen kapcsolódási kísérletektől nem omlanak össze, azok szoftverében kárt nem okoz.A portscan egyes típusai [5]:

TCP connect() scan: a legalapvetőbb fajtája a pásztázásnak, amikor az operációs rendszer által nyújtott connect() rendszerhívást használjuk egy kapcsolat megnyitásához a minket érdeklő portokon. Ha a távoli gép vizsgált portján szolgáltatás elérhető, akkor a connect() hívás sikeresen lefut. Legnagyobb előnye, hogy nagyon egyszerű megvalósítani és használatához nincs szükség az adott operációs rendszeren adminisztrátori jogosultságra. Másik előnye a gyorsaság. Míg egy portonkénti portscan a TCP időtúllépési mechanizmusa miatt sokáig is eltarthat, addig sok kapcsolatot párhuzamosan használva felgyorsíthatjuk a vizsgálatot.

TCP SYN scan: ezt a módszert gyakran nevezik „half open” ellenőrzésnek, mivel nem nyitunk meg egy teljes TCP kapcsolatot. Elküldünk egy SYN csomagot, majd választ várunk. Egy SYN/ACK esetén az adott porton egy szolgáltatás figyel, míg RST választ esetén a porton nem figyel szolgáltatás. Amennyiben SYN/ACK választ kapunk, feljegyezzük a port nyitott voltát, majd eltérően a szabványos TCP hívásfelépítéssel egy RST csomaggal zárjuk a félig felépült kapcsolatot. Ennek a módszernek előnye, hogy sokkal kevesebb helyen naplózzák az ilyen kísérletezéseket, ugyanakkor hátránya, hogy az adott rendszeren az alacsonyszintű csomagkezelés miatt rendszergazdai jogokkal kell futtatnunk a portscant.

TCP FIN scan: vannak helyzetek, amikor a SYN scan használata sem elég. Néhány tűzfal és csomagszűrő ugyanis figyeli az ilyen pásztázásokat is. A FIN csomagok viszont keresztüljuthatnak háborítatlanul. A módszer ötlete a következő: a zárt portoknak válaszolniuk kell a FIN csomagunkra egy megfelelő RST-vel. A nyitott portoknak azonban figyelmen kívül kell hagyniuk a kérdéses csomagokat. Ez elvárt TCP viselkedés. Ennek ellenére bizonyos gépek (például a Microsoft rendszerei) nem megfelelőek ebben a tekintetben. Ezen rendszerek RST-t küldenek, figyelmen kívül hagyva a port állapotát, más rendszerekkel viszont ez a vizsgálat jól működik. Valójában néha hasznos is lehet ez a tulajdonsága a különböző rendszereknek, erre a következő alfejezetben még visszatérünk.

UDP ICMP port nem elérhető - scan: az UDP datagram alapú protokol, semmilyen nyugtát, vagy hibaüzenetet nem kell válaszul küldenie egy kérésre. Szerencsére a legtöbb hálózati eszköz küld egy ICMP Port Unreachable (port elérhetetlen) hibát, amennyiben egy üzenetet küldünk egy lezárt UDP portra. Ezzel megtudhatjuk, hogy mely portok nincsenek nyitva, így kizárásos alapon, hogy melyek igen. Ebben az ellenőrzésbe be kell építenünk egy mechanizmust arra az esetre is, ha elvesznének csomagok, ebben az esetben ugyanis több fals pozitív találatunk lenne a nyitott portokra.

11

3.2.3 Távoli operációs rendszer detektálás (OS fingerprinting)Nyilvánvalóan hasznos tud lenni, ha el tudjuk dönteni távolról egy hálózati eszközről, hogy azon milyen operációs rendszer fut [6]. Erre legjobb példa, hogy a biztonsági rések általában erősen operációs rendszer függőek. Egy megfelelő portpásztázás és a távoli operációs rendszer típusának megismerése után a támadó képes lehet célzottan a mi rendszerünk ellen készített támadási módszereket alkalmazni.A legegyszerűbb megoldás a célpont kiszolgálóinak bejelentkezését megfigyelni. Az egyik magyar Internet szolgáltatónál például a Sendmail levelező szerver jelentkezik be:

ural2:~$ telnet smtp.axelero.hu 25Trying 195.228.240.14...Connected to smtp.axelero.hu.Escape character is '^]'.220 smtp.axelero.hu ESMTP sendmail @ axelero

Ez a trükk gyakran vezethet ugyan eredményre, de sokszor meg is téveszthet minket. A legtöbb helyen ezeket az információkat ugyanis nem csupán elhallgatják a kiszolgáló programok, de van, hogy félrevezetésből más típusúnak vallják magukat. Ezeket a bejelentkezési üdvözleteket (bannereket) ugyanis a legtöbb program esetén nagyon egyszerű átállítani (ezt sok szolgáltató meg is teszi).Egy hálózati eszköz operációs rendszerének felismerését ezen okok miatt tehát más módszerrel végzik. Az OS fingerprinting lényege, hogy a hálózati kommunikáció során olyan egyedi jellegzetességeket, „ujjlenyomatokat” keresnek az adatfolyamban, ami egyes rendszerekre jellemző, míg másokra nem. Ezen különbségek abból adódnak, hogy az egyes rendszerek fejlesztői az IETF de facto szabványainak, az RFC-knek [7] bizonyos ajánlásait másképpen értelmezik, vagy valamilyen indok alapján figyelmen kívül hagyják. Így egy hálózati kommunikáció alatt tucatnyi olyan árulkodó jelet találhatunk, mely csak bizonyos típusú rendszerekre jellemző. Ilyen jel volt az előző fejezetben említett TCP FIN scan esetén visszaküldött RST válasz. A továbbiakban ezen jelekből vesszünk sorra néhányat.

TCP FIN próba: ebben az esetben küldünk egy FIN csomagot (vagy bármilyen másikat ACK vagy SYN flag nélkül) és várjuk a reakciót. A helyes RFC793 viselkedés nem reagálni. A szabványtól eltérő rendszerek (mint például: MS Windows, a BSDI, a CISCO, a HP/UX, a MVS és az IRIX) egy RST-t küldenek vissza. A legtöbb távoli operáció rendszer detektáló eljárás alkalmazza ezt a próbát.

Hibás TCP flag próba: ez egy ötletes teszt melynek lényege egy definiálatlan TCP flag (64 vagy 128 értékű bitek) beállítása egy SYN csomag TCP fejlécében. A Linux rendszermagban megvalósított TCP verem egy adott verzióig (2.0.35-ig) ezt a flag-et megtartja beállítva a válaszban. Nem tudunk másik rendszerről, mely rendelkezik ezzel a hibával. Néhány rendszer azonban megszakítja a kommunikációt, ha ilyen csomagot kapnak.

TCP ISN mintavétel: ennek a tesztnek az ötlete, hogy találjunk szabályosságokat a TCP protokollverem által választott ISN (Initial Sequence Number, kezdeti azonosítószám) választásában, amikor kapcsolatkérésre kapunk választ (emlékeztető: ez az a véletlenről induló szám, melyet minden egyes üzenetváltáskor a TCP növel eggyel. Feladata megakadályozni, hogy egy TCP kapcsolatba illetéktelenül beékelődjenek csomagok, így helyes megválasztása kényes pontja lehet a rendszernek). Ezek a tapasztalatok csoportokba oszthatók mint például a tradicionális 64K (régi UNIX rendszerek), véletlen növekményű (újabb Solaris, IRIX, FreeBSD, Digital UNIX, Cray és sok másik rendszerek), valódi véletlen alapú (Linux 2.0.*, OpenVMS, újabb AIX, stb). Windows rendszerek egy időfüggő megoldást alkalmaznak, ahol az ISN minden időegység alatt meghatározott mértékben növekszik.

12

TCP kezdő ablakméret: az IP csomag fejlécében ez a szám mondja meg, hogy az adott gép mennyi fogadott csomag után küld vissza nyugtázást (ACK). Mivel ez egy, az operációs rendszerre jellemző konstans, sok rendszert be lehet azonosítani csupán ennek a számnak az ismerete alapján. Például az AIX az egyetlen operációs rendszer, ami 0x3F25 (16165) értéket alkalmazza. Az NT5-ben teljesen újraírt TCP veremben a Microsoft a 0x402E (16430). Érdekes módon ez ugyanaz az érték, amit az OpenBSD és FreeBSD rendszerek is alkalmaznak.

További próbák [8] az Nmap portscan program honlapján érhetőek el, mely ezen próbák alapján képes távoli operációs rendszer detektálásra is. Természetesen nem csak TCP alapú próbákat lehet végezni, például az ICMP protokollra is léteznek hasonló próbák.Kérdéses, hogy van-e értelme védekezni a távoli operációs rendszer detektálás ellen, annak fényében, amit az 1.4. fejezetben a titkolózásra alapozott biztonság estén olvastunk.Amennyiben mégis szükségét látjuk, hogy a kéretlen kíváncsiskodókat megtévesszük, Linux operációs rendszer estében lehetőségünk van különböző rendszermag foltokat telepítenünk [9]. Ezek a rendszermagban található TCP vagy egyéb protokollvermet úgy változtatják meg, hogy a távoli operációs rendszer detektálás során a rendszerre nem jellemző értékeket adjon vissza a kiszolgáló, megtévesztve ezzel a támadót.

3.3 NaplózásA védekezés során egy nagyon fontos, általánosan használható módszer a naplózás. A számítógépen történt események naplózása, s ezen fájlok rendszeres elemzése a rendszerbiztonság egyik legkritikusabb, legfontosabb eleme. Ezen fájlok tartalmazzák általában a felhasználók ki-, és bejelentkezését, valamint a különféle kiszolgáló programokhoz intézett kéréseket. Ezen fájlok vizsgálatával megelőzhetjük a betörést a gépünkre, hiszen ha bármilyen gyanús információt találunk, akkor időben felléphetünk a létrehozója ellen; de ezen fájlokból deríthetjük ki az esetleges megtörtént betörések okait is.Linux alatt ezek a fájlok rendszerint a /var/log könyvtárban helyezkednek el, s tartalmuk syslog() függvényhívással keletkezik. Az, hogy mit és hová naplózzon a rendszerünk a /etc/syslog.conf fájlban adható meg. Bár a naplófájlok nagy része egy speciális adatbázis formátumban tárolódik, azért a bennük tárolt információ megváltoztatható, így a körültekintő betörő el tudja tüntetni a betörés nyomait. Azért, hogy ezt olyan egyszerűen ne tehesse meg, szükség van a fájlok rendszeres másolatára egy másik számítógépen vagy esetleg papíron, hiszen ebből deríthető ki, hogy valójában mi is történt a rendszerrel.

4 A hálózati forgalom védelmeA következő támadható pont a kliens és a szerver közti kommunikációt megvalósító hálózat. A támadó a hálózati forgalmat figyelve megfejtheti a jelszót, amennyiben tudja, hogy azt milyen formában és hol keresse egy adott üzeneten belül. Mivel az internetes kommunikáció során adataink több hálózati eszközön is keresztülmennek, mire célba érnek, szükségszerű a bizalmas adatokat kódolt formában továbbítani.

4.1 Az SSL/TLS protokoll [10]A Secure Socket Layer (SSL) és Trasport Layer Security (TLS) protokollok lehetővé teszik a kliens és a szerver hitelesítését, valamint a kommunikáció bizalmasságának megteremtését. Az SSL-t a Netscape Communications cég fejlesztette ki 1994-ben, legutolsó verziója az SSL v3 (a korábbi verziók nem biztonságosak, használatuk nem javasolt). Az 1996-ban az IETF kerettében megalakult TLS munkacsoport fejleszti és szabványosítja a TLS protokollt. A TLS v1.0 (RFC2246) 1999-ben került kibocsátásra és biztonsági szempontból megfelel az SSL v3 változatának.

13

Az SSL/TLS a TCP/IP-re épülő alkalmazások felé teremti meg a hálózati két pontja között a biztonságos kapcsolat lehetőségét. Leggyakoribb használata a biztonságos HTTP alapú kliens-szerver kommunikáció egy web böngésző és kiszolgáló között. Ahogy előtérbe kerül a biztonságos kommunikáció, úgy egyre több protokoll SSL kiterjesztett változata kerül használatba a mindennapokban is. A követezőkben néhány protokoll SSL kiterjesztését soroljuk fel:

FTPS: az FTP állomány átviteli protokoll kiterjesztése POP3S: a POP3 levélletöltő protokoll kiterjesztése IMAPS: az IMAP szerveroldali leveleket kezelő protokoll kiterjesztése TELNET-SSL: a telnet protokoll kiterjesztése, gyakorlatban inkább az SSH protokoll

terjedt el HTTPS: a HTTP protokoll kitejesztése

Az SSL réteg logikailag a TCP és az IP réteg között helyezkedik el:

IPTCPSSL

HTTPS FTPS SMTPS POPS…

Hálózati réteg

Alkalmazási réteg

IPTCPSSL

HTTPS FTPS SMTPS POPS…

Hálózati réteg

Alkalmazási réteg

4.1.1 SSL kézfogásA Handshake Protocol feladata a kliens és a szerver hitelesítése valamint a titkosítási algoritmus és a titkos kulcsok egyeztetése. Ezeket a feladatokat összefoglalva SSL-kézfogásnak nevezzük. Egy SSL-viszony mindig ilyen SSL-kézfogással kezdődik.

A kézfogás során használt fontosabb fogalmak: Pre-master secret: a pre-master secret gyakorlatilag egy 384 bites (48 byte) véletlen

szám. A kliens hozza létre. Ezt rejtjelezi a szerver nyilvános kulcsával, majd elküldi neki. Ha a szerver képes dekódolni a számára kódolt üzenetet a saját titkos kulcsával (tehát valóban az, akinek állítja magát, mert rendelkezik a titkos kulccsal) és így meg tudja ismerni a pre-master secret-et, akkor ebből elkészíti a master secret-et.

Master Secret: egy 48 byte hosszú titkos adatcsomag, amit a kliens és a szerver ugyanazzal a módszerrel hoz létre. Ebből készül a szimmetrikus rejtjelezés közös szimmetrikus kulcsaként használt session key.

Session Key: a kapcsolat során rejtjelezésre, illetve a MAC aláírására használt szimmetrikus kulcs. A master secretből készíti egymással párhuzamosan a kliens és a szerver.

Az SSL-kézfogás tehát az alábbiak szerint megy végbe:1. A kliens elküldi a szervernek a kliens SSL protokolljának verziószámát, egy viszony-

azonosító számot, az általa használni kívánt titkosítási paramétereket és tömörítési módszert.

2. A szerver válaszként elküldi a saját SSL protokolljának verziószámát, a viszony-azonosítót, a saját titkosítási beállításait. Ezen kívül elküldi a saját tanúsítványát, és ha hitelesíteni akarja a klienst, akkor annak tanúsítványát. (A kliensek hitelesítése nagyon ritkán fordul elő.)

14

3. A kliens a kapott tanúsítvány alapján megpróbálja hitelesíteni a szervert (lásd A szerver hitelesítése részben). Amennyiben a hitelesítés nem sikerül, akkor nem lehetséges titkosított kapcsolat kiépítése, az egyeztetés megszakad.

4. A kézfogás során kapott adatok alapján a kliens generál egy pre_master_secret értéket, ezt kódolja a szerver nyilvános kulcsával, és elküldi a szervernek.

5. Ha a szerver hitelesíteni akarta a klienst, akkor a kliens a titkosított pre_master_secret mellett elküldi saját tanúsítványát is a szervernek.

6. Ha a szerver kérte a kliens tanúsítványát, akkor a kapott tanúsítvány alapján megpróbálja hitelesíteni a klienst (lásd A kliens hitelesítése részben). Amennyiben a hitelesítés sikertelen, az egyeztetés megszakad. Sikeres hitelesítés után a szerver a saját titkos kulcsával dekódolja a pre_master_secret értéket, és ezt használva létrehoz egy master_secret értéket.

7. Mind a kliens, mind a szerver létrehozza ezután a viszony-kulcsokat egy közös algoritmus alapján. Ezek szimmetrikus kulcsok, ezeket használják a továbbiakban az üzenetek titkosítására és az adatok sértetlenségének biztosítására (szimmetrikus kulcsok, mert az aszimmetrikus kulcsú titkosítás nagyon sok erőforrást emésztene fel. Így csupán csak a szimmetrikus kulcsú titkosítás kulcsát egyeztetik a kézfogás közben aszimmetrikus kulcsú titkosítást használva. Az adatfolyamot tehát szimmetrikus kulcsú titkosítással rejtjelezik).

8. A kliens küld egy üzenetet a szervernek, mellyel jelzi, hogy a kézfogás részéről befejeződött.

9. A szerver is küld egy üzenetet a kliensnek, mellyel azt jelzi, hogy a kézfogás részéről véget ért.

10. Ezzel az SSL-kézfogás véget ért. A továbbiakban a felek a viszony-kulcsok segítségével titkosítják az egymásnak küldött üzeneteiket.

4.1.2 A szerver hitelesítéseA kliens megkapja a szervertől annak tanúsítványát. Egy tanúsítvány az alábbi, a hitelesítéshez szükséges információkat tartalmazza:

a szerver nyilvános kulcsa a tanúsítvány érvényességi ideje a szerver neve a tanúsítvány kiállítójának (Certificate Authority, CA) neve a kiállító digitális aláírása.

A kliens karbantart egy listát, melyben az általa megbízhatónak tartott tanúsítvány-kiállítók adatai szerepelnek:

a kiállító neve a kiállító nyilvános kulcsa a kiállító digitális aláírása.

A sikeres hitelesítéshez az alábbi négy kritérium mindegyikének teljesülnie kell.1. Az adott pillanatban érvényes a szerver tanúsítványa, azaz az aktuális dátum beleesik

az érvényességi időbe.2. A tanúsítványt kiállító neve szerepel a kliens által megbízhatónak tartottak listájában.3. A listában szereplő nyilvános kulcs segítségével ellenőrizhető a kiállító digitális

aláírásának érvényessége.4. A szerver tanúsítványban megadott neve megegyezik a kliens által aktuálisan ismert

szervernévvel. (Ez nem része az SSL protokollnak, de ez az ellenőrzés védelmet nyújt a man-in-the-middle támadások ellen, ezért a gyakorlatban szinte mindig megvalósítják.)

15

Amennyiben mind a négy kritérium teljesült, a hitelesítés sikeres, és folytatható az SSL-kézfogás.

4.1.3 A kliens hitelesítéseA szerver megkapja a klienstől annak tanúsítványát, valamint a kliens titkos kulcsával aláírt adatot. Egy tanúsítvány az alábbi, a hitelesítéshez szükséges információkat tartalmazza:

a kliens nyilvános kulcsa a tanúsítvány érvényességi ideje a kliens neve a tanúsítvány kiállítójának (CA) neve a kiállító digitális aláírása.

A szerver karbantart egy listát, melyben az általa megbízhatónak tartott tanúsítvány-kiállítók adatai szerepelnek:

a kiállító neve a kiállító nyilvános kulcsa a kiállító digitális aláírása.

A sikeres hitelesítéshez az alábbi négy kritérium mindegyikének teljesülnie kell.1. Az adott pillanatban érvényes a kliens tanúsítványa, azaz az aktuális dátum beleesik az

érvényességi időbe.2. A tanúsítványt kiállító neve szerepel a szerver által megbízhatónak tartottak listájában.3. A listában szereplő nyilvános kulcs segítségével ellenőrizhető a kiállító digitális

aláírásának érvényessége.4. A kliens titkos kulcsával kódolt adat a kliens tanúsítványában szereplő nyilvános kulcs

segítségével visszafejthető.Amennyiben mind a négy kritérium teljesült, a hitelesítés sikeres, és folytatható az SSL-kézfogás.

4.1.4 Titkosítási algoritmusokAz SSL protokoll a titkosítási algoritmusok széles tárházát (DES, DSA, MD5, RC2, RSA, stb.) támogatja a hitelesítések, kódolt kommunikáció vagy tanúsítványcsere lebonyolítása során. Amennyiben a kliens és a szerver is többféle algoritmust támogat, akkor az SSL-kézfogás során egyeznek meg abban, hogy az adott kommunikációhoz pontosan melyiket is használják. A kézfogás a mindkét fél által támogatott algoritmusok közül a legerősebbet fogja kiválasztani.

5 A Linux operációs rendszer biztonsági megoldásai

5.1 A chroot környezetA chroot egy olyan művelet, mely megváltoztatja az alapértelmezett gyökérkönyvtárat. Maga a chroot-olt program a művelet végrehajtása után nem lesz képes elérni a fájlrendszer azon pontjait, mely a beállításra került gyökérnek nem gyermekei. Ezáltal a Unix rendszerekben gyakran használt azon szimbolikus linkek is elvesztik konzisztenciájukat (nem létező állományra fognak mutatni), melyek a chroot környezeten kívülre mutatnak. A következő ábra a chroot környezetet illusztrálja az állományrendszeren.

16

chroot

/

etcdevbin lib var…

etcdevbin lib var…

Chroot környezet

chroot

/

etcdevbin lib var…

etcdevbin lib var…

Chroot környezet

A chroot művelettel így olyan környezetet hozhatunk létre, melyben, elzárva a gazdarendszertől, nem megbízhatónak számító alkalmazásokat futtathatunk. Az így kialakított környezetet hívják börtönnek (jail) és homokozónak (sandbox) is.Gyakorlatban a chroot művelet megfelelő tervezést igényel, hiszen a chroot-olt környezetben futó programok a konfigurációs és dinamikusan linkelt függvénykönyvtárakat a szokásos helyeken keresik az állományrendszerben. Hogy képessé tegyünk egy alkalmazást a speciális környezetben futni általában szükséges egy minimális állománystruktúrát áthelyezni a leválasztásra kerülő rendszerbe. A futtatásra szánt program által használt dinamikus könyvtárak kilistázására a Unix rendszereken az ldd parancs szolgál. Sajnos a konfigurációs állományok esetében ilyen segítségünk nincs, itt a program ismeretére, vagy a programcsomag tanulmányozására van szükség.A chroot használata kedvelt eszköz olyan rendszereken, melyek nyilvános szolgáltatásokat futtatnak. Ilyen lehetnek például az anonim ftp kiszolgálók vagy web kiszolgálók. Szintén szívesen használják olyan programok esetében, melyek nagyobb biztonsági kockázat vállalására kényszerítik a szolgáltatás üzemeltetőjét. Így az esetlegesen kompromittálódott szolgáltatás segítségével bejutott támadó nem képes a rendszer többi komponensében kárt tenni, onnan információkat kinyerni.A "chroot" a Unix rendszerekben vonatkozhat a chroot() rendszerhívásra, mely a meghívó folyamatra (processz) és annak gyerekfolyamataira állítja be a gyökérkönyvtárat. Továbbá tétezik egy chroot program is, mellyel saját magunk tudunk chroot-olt programot indítani a kívánt könyvtárban, mint gyökérben.A rendszerhívásról a man 2 chroot, a programról pedig a man 8 chroot paranccsal kaphatunk több információt.

5.1.1 A chroot támadásaMint láthattuk a chroot művelettel hatékonyan növelhetjük kiszolgálónk biztonságát, de csakis akkor, ha körültekintően alkalmazzuk. Habár nagyon jól hangzik, hogy képesek lehetünk az állományrendszert teljesen elzárni egy esetlegesen biztonsági rést jelentő szolgáltatás elől, de vajon lehetséges-e kitörni egy chroot környezetből? A válasz sajnos igen, amennyiben bizonyos feltételek teljesülnek [11].Általában elmondható, hogy minél több szolgáltatást futtatunk a leválasztott környezeten belül, annál több lehetőséget adunk a támadónak, hogy a szolgáltatások közül valamelyiket sikeresen támadja. Ilyen esetben pedig képes lehet rendszergazdai jogokat is szerezni a "virtuális homokozóban". Miután a támadó rendszergazdai jogosultságot szerzett, már több támadási módja is létezik a chroot környezetből való kitörésnek. Amennyiben viszont képesek vagyunk a környezeten belül mellőzni a rendszergazdai jogosultságokkal futó szolgáltatásokat, elméletileg nem adunk lehetőséget arra, hogy a bent futó programok segítségével egy támadó kitörjön belőle.A chroot() rendszerhívás magában nem elegendő egy "virtuális homokozó" beállítására. A chroot program ezért nem csupán magát a chroot() rendszerhívást alkalmazza, hanem utána kiadja az aktuális chroot környezet gyökérkönyvtárára való könyvtárváltást is:

17

chroot ("/chroot");chdir ("/");

Mivel a chroot a filerendszeren logikailag csak egyetlen helyen szerepelhet, ezért egy root jogokkal futó alkalmazás képes ezt a chroot könyvtárat máshova állítani és kilépni belőle, amennyiben nem használja a könyvtárváltást eredményező rendszerhívást.A következő ábrákon a chroot törésének 3 lépését láthatjuk. Az első lépésben a root jogokkal futó támadó program a chroot-ot egy lentebbi könyvtárra helyezi, így saját maga „kikerül” belőle.

chroot

/

etcdevbin lib var…

etcdevbin lib var… Chroot áthelyezés

Könyvtár váltás

1

2chroot

/

etcdevbin lib var…

etcdevbin lib var… Chroot áthelyezés

Könyvtár váltás

1

2

Miután a támadó program képes elérni a teljes állományrendszert, annak gyökerére helyezi a chroot környezetet, így ettől fogva a teljes állományrendszert elérheti bármilyen program futtatásával.

chroot

/

etcdevbin lib var…

etcdevbin lib var…

Új Chroot környezet

3

chroot

/

etcdevbin lib var…

etcdevbin lib var…

Új Chroot környezet

3

5.1.2 A szolgáltatások elzárásának biztonságos megoldásaA chroot művelet megfelelő körültekintéssel képes a megkívánt biztonságot nyújtani. Ugyanakkor több fejlesztő is úgy érezte, hogy ezt a rendszerhívást szükséges megerősíteni további megoldásokkal. Ilyen megoldás például a Linux rendszermagjára alkalmazható folt (patch), a GrSecurity [12], mely számos további biztonsági funkciója mellett a chroot környezetek megerősítésére is alkalmazható.A chroot alapú megoldások egy új alternatívája a virtuális gépet emuláló programok. Manapság ezen emulációk olyannyira hatékonyak, hogy használhatóak arra, hogy egyetlen számítógépen akár tucatnyi virtuális példányát futtassuk az operációs rendszernek túlzott teljesítménycsökkenés nélkül. Mivel ezek az emulátorok egy felhasználó nevében futnak, ezért az emulált rendszer sikeres támadása esetén sem képesek a felhasználó jogainál magasabb jogosultságot szerezni a rendszerben. Napjainkban egyre több tartalom szolgáltató is kihasználja az emulátorok ezen új generációját, hogy biztonságosabbá tegye rendszerét.

5.2 A Pluggable Authentication Modules (PAM)A PAM egy egységes autentikációs interfész, melyet messzemenőkig a rendszerünkhöz tudunk igazítani (pl.: belépési korlátozások, különböző hitelesítés módok, stb…).Régebbi rendszereken a hitelesítés nagyrészt a shadow password állomány alapján történt. A PAM-ot használó rendszereken az összes olyan program, amelynek kritikus adatokhoz (pl. password file) van hozzáférése (pl. login és még sok egyéb program vagy segédprogram) a PAM API-n keresztül éri el ezeket a hitelesítési információkat. Ennek előnye, hogy a különböző programokban ugyanazokat a függvényeket használhatjuk, nem kell újra és újra feltalálni a spanyolviaszt (azaz az autentikációs technikát). A PAM képes a felhasználói hitelesítést a shadow passwd állományon kívül LDAP, SQL szerverek segítségével, vagy

18

akár távoli POP3, Kerberos, Radius, stb. kiszolgálók segítségével megoldani. Széleskörű elterjedése miatt kiegészítései vannak különböző token alapú hitelesítési technikához is (pl.: jelszó megadás mellett USB háttértáron tárolt biztonsági kulcs ellenőrzése).A PAM valójában a program API-n keresztül megkapja a hitelesítéshez szükséges adatokat a hitelesítést végző programtól, majd visszaad egy választ az autentikáció sikerességéről, vagy kudarcáról. Így ha egy meglévő rendszerben a felhasználói hitelesítést szeretnénk megváltoztatni, nem szükséges az összes kiszolgáló programot újra beállítanunk (pl.: levelező szerver, ftp szerver, belső weboldalakat kiszolgáló webszerver), elegendő csupán a PAM-ot a megfelelő hitelesítésre megtanítani.A PAM segítségével tovább korlátozhatóak a felhasználókra vonatkozó erőforráslimitek. A felhasználókra vonatkozó beállításokat a /etc/security/ könyvtárban lévő file-ok segítségével végezhetjük el, a programokkal kapcsolatos config file-ok /etc/pam.d/ könyvtárban vannak. A részletes dokumentáció a /usr/doc/pam*/ alatt található.

5.3 Az Access Control List (ACL)A hozzáférés vezérlő lista (Access Control List, ACL) egy mechanizmus, amely tetszés szerinti hozzáférés vezérlést biztosít egy erőforráshoz. Általában ACL használatával sokkal részletesebb, specifikusabb szabályokat tudunk felállítani egy erőforrás elérésére.Maga az ACL egy olyan lista, melynek elemei hozzáférést vezérlő szabályok. Egy szabály általában tartalmaz valamilyen erőforrás egyedet, valamint az ehhez kapcsolódó hozzáférési jogokat. Az ACL-ek tartalmazhatnak engedélyezést és tiltást meghatározó szabályokat is, de elképzelhető az adott program adottságainak megfelelő speciális vezérlés meghatározása is.Az ACL-ek végrehajtása általában a szabályok megadási sorrendjében történik, ezért fontos odafigyelnünk a szabályok megfelelő sorrendben való felvételére. Amennyiben egy ACL vezérelt erőforráshoz hozzáférési kérelem érkezik, az erőforrást vezérlő program egyesével végiglépked a szabályokon addig, amíg az adott kérésre egyezőt nem talál. Amennyiben az ACL nem tartalmaz megfelelő illeszkedő szabályt, a program egyéb beállításain múlik az erőforrás hozzáférés engedélyezés vagy tiltása.

Hozzáférés vezérlő listákat sok helyen alkalmaznak:Állományrendszerre alkalmazott hozzáférési lista: a Linux állományrendszere támogatja ACL-ek alkalmazását. Egy szabály megadásakor ebben az esetben megadhatjuk az állományrendszer egy részét (állomány, könyvtár), azt a felhasználót vagy csoportot, akire a szabály vonatkozik, illetve a szabványos Unix állományrendszer hozzáférési szabályait (olvasás, írás, futtatás jogok).A következő paranccsal kilistáztunk egy állományrendszer ACL-t. Az ACL john felhasználó mydir könyvtáráról szól, aki bill felhasználónak, valamint a students csoportnak teljes hozzáférést ad a könyvtárra.

debian :~# getfacl mydir# file: mydir# owner: john# group: usersuser::rwxuser:bill:rwxgroup::r-xgroup:students:rwxmask::rwxother::---

Szintén ACL-t alkalmaz a Linux csomagszűrője, az IPTables. Ebben az esetben egy ACL egy adott hálózati forgalomra vonatkozó szabályokat ír le. Az következő parancsokkal például az

19

alábbi szabályokat veszünk fel az IPTables-be. Az első parancs alapján az eth0 interfészen bejövő csomagokat engedélyezzük, míg a másodikban nem adunk megkötést a bejövő interfészre, azaz minden bejövő csomagot eldobunk. Az ACL tehát az eth0 interfésztől eltérő hálózati csatolón bejövő csomagokat eldobja (a –A segítségével adunk új szabályt az INPUT ACL-hez, a –i a bejövő interfészt, a –j pedig a csomagra alkalmazott műveletet írja le).

IPTABLES -A INPUT -i eth0 -j ACCEPTIPTABLES -A INPUT -j DROP

Figyeljük meg, hogy amennyiben a két szabályt felcseréljük, úgy az ACL értelme megváltozik. Gondoljuk végig, hogyan!

5.4 Az Nmap portscan program"We have all seen many movies like Hackers which pass off ridiculous 3D animated eye-candy scenes as hacking. So I was shocked to find that Trinity does it properly in The Matrix Reloaded. She whips out Nmap, uses it to find a vulnerable SSH server, and then proceeds to exploit it using the SSH1 CRC32 exploit from 2001. Shame on them for still being vulnerable."

Fyodor, az Nmap program készítője(A teljesen élethű, valódi betörés mozivásznon

való ábrázolása miatt a Brit Számítógépes Társaság (BCS) nemtetszését fejezte ki.)

Az Nmap az egyik legnépszerűbb nyílt forrású portscan program. Képes detektálni egy hálózati eszköz operációs rendszerét, valamint nyitott portjait. Futtatásakor a következőhöz hasonló képet kaphatunk:

debian:~# nmap localhost[…]PORT STATE SERVICE22/tcp open ssh25/tcp open smtp53/tcp open domain80/tcp open http993/tcp open imaps

Nmap finished: 1 IP address (1 host up) scanned in 0.328 seconds

A szükséges kapcsolók leírása megtalálható a man oldalakon (man nmap).

5.5 A GrSecurity rendszermagfoltA GrSecurity [12] egy gyűjteménye azon foltoknak (patch) a Linux rendszermaghoz, melyek növelik egy rendszer biztonságát. A GrSecurity egy nagyon jól összefogott csomag, mely sok biztonsági hiányosság lefedésére alkalmas. Képességeinek megismerésével sokkal közelebb kerülhetünk a biztonsági kérdések mélyebb ismeretéhez, ezért a továbbiakban bemutatjuk a folt néhány képességét a teljesség igénye nélkül [13].

5.5.1 Hozzáférés-vezérlés (ACL)A GrSecurity egy finom felbontású hozzáférés vezérlést alkalmaz. A módszer a korábban ismertetett ACL-ek elvén működik, kiegészítve azt különböző egyéb megoldásokkal:

Szerepeket oszthatunk ki, melyekkel akár a rendszergazda tevékenységét is bekorlátozhatjuk a megfelelő mértékig. Így elérhető, hogy az illetéktelenül

20

rendszergazdai jogokat szerzett támadónak olyan szűk mozgásteret biztosítsunk, mely a támadás befejezéséhez nem elegendő.

Korlátozhatjuk az állományrendszer egyes részeihez való hozzáférést speciális felhasználói és csoport szerepkörök kiosztásával.

Pontosan definiálhatjuk, hogy egyes programok az állományrendszer mely részéhez milyen jogokkal férhetnek hozzá, így megakadályozhatjuk, hogy egy hibás kiszolgáló programot megtámadva illetéktelenek programokat módosítsanak a kiszolgálón.

5.5.2 Hálózati kiegészítések A TCP/IP protokollverem kiegészítése további véletlenszámok alkalmazásával,

melyekkel a korábbi operációs rendszer detektáló technikák is becsaphatóak, valamint kiszámíthatatlanná teszik a támadó számára egy adatfolyamhoz való illetéktelen hozzáférést.

Hálózati erőforrásokhoz való hozzáférés korlátozása (pl.: hálózati socket nyitás kommunikáció céljából).

5.5.3 Rendszer kiegészítések A korábban ismertetett chroot() rendszerhívás biztonságának növelésére a folt

képes megakadályozni speciális műveleteket a chroot-olt környezetben. Tiltja például állományrendszerek csatolását (mount), a chroot környezeten kívül futó programokkal való interakciókat és sok egyéb „veszélyes”-nek minősíthető műveletet.

A GrSecurity tartalmazza a PaX foltot is. A PaX projekt elsődleges célja, hogy védelmi mechanizmust nyújtson a puffer túlcsordulási (stack és heap overflow) és egyéb rendszergazdai konzol elérésére lehetőséget adó hibák, kihasználása ellen. A programok futtatásakor a memóriacímek véletlenszerűen kiosztásával nehezíti egy támadás sikerességét, valamint figyel, hogy a nem futtatható memórialapokon lévő adatterületek valóban ne kerülhessen futtatásra. A PaX folt ezekkel a technikákkal a program címtér elleni támadást megvalósító exploitok nagy részét megakadályozza a sikeres támadásban.

Rendszerhívások figyelése és naplózása. Példák:o rendszeróra megváltoztatása (egyes biztonsági protokollok érzékenyek a

rendszerórára)o külső állományrendszer csatolása (normális működés esetén erre ritkán kerül

sor)o meghiúsult fork() rendszerhívás (az exploitok nagy számban alkalmazzák a

fork rendszerhívást jogosulatlan rendszergazdai parancsértelmező futtatásra)

21

Felkészüléshez feladatokA következő feladatok mérésre való felkészüléshez szükségesek

1. Ismételje át (ha nem tanulta, nézzen utána) a TCP protokoll háromutas kézfogás kapcsolatfelépítési eljárását! Mire való a SYN, ACK és RST nevű TCP flag?

2. A mérés során a rendszergazdai jogokat igénylő feladatokhoz a programokat a sudo paranccsal kell indítani. Nézzen utána hozzávetőlegesen Linux alatt az alábbi parancsoknak és programoknak is, amennyiben nem mozog otthonosan ebben az operációs rendszerben!

a. ethereal, tcpdumpb. sudoc. sshd. nmap

3. Frissítse fel C programozásban jártasságát, a 24. oldalon található „Segédletek a mérési feladatokhoz” című fejezet alapján. Ismerje meg a programrészleteket, próbálja megérteni a feladatukat!

Formai elvárások a jegyzőkönyvvel szemben: tartalmazza a feladatok megoldásának menetét, indoklást, forráskódot, ahol szükséges. Legyen jól áttekinthető, PDF vagy RTF formátumú. Amennyiben az áttekinthetőséget nem rontja, a jegyzőkönyv beadható TXT formátumban is. A jegyzőkönyv tartalmazza a hallgatók nevét, neptun kódját, a mérés nevét és órára pontos időpontját is!

Minta ellenőrző kérdések: Mire való a chroot környezet? Mi a Titkolózásra alapozott biztonság (Security Through Obscurity)? Mi a Brute Force (Nyers erő) támadás? Mi a hibás TCP flag próba? Mondjon legalább 3 példát a DoS támadások által célbavett erőforrásokra! Magyarázza a következő fogalmakat: sértetlen, hiteles, bizalmas! …

22

Mérési feladatok1. Készítsen fork bombát!

a. Készítsen fork bombát, mely létrehoz 100 gyermek folyamatot. A folyamatok mindegyike 30 másodperc tétlenség után lépjen ki.

b. A PAM modul /etc/security/limits.conf állományának szerkesztésével állítson be korlátot, mely korlátozza a saját felhasználónevében indított folyamatok számát! Ehhez vegye figyelembe, hogy jelenleg hány folyamattal dolgozik!

c. Futtassa újra a fork bombát! Mit tapasztal? A jegyzőkönyvbe kerüljön bele a program forráskódja és a futás eredménye is a támadás kivédése előtt és után! A feladat végeztével állítsa helyre a /etc/security/limits.conf állományt!

2. Készítsen chroot környezetet!a. Készítsen saját chroot környezetet a chroot program segítségével, mely

tartalmazza legalább a bash és ls binárisokat. A binárisok helyét a which, a binárisok által hivatkozott dinamikus programkönyvtárakat az ldd paranccsal tudja kilistázni.

b. Próbálja ki a környezetet, rögzítse tapasztalatait! Listázza ki a létrehozott struktúrát a chroot-on belül (használja az ls parancs –R kapcsolóját is)

c. Törjön ki a felépített chroot környezetből a segédletben megtalálható forrásprogram segítségével! A tapasztalatai és a segédlet 5.1.1. fejezet alapján írjon olyan programot, mely a megfelelő jogosultságokkal indítja a chroot környezetet! Működik a chroot-ból kitörő program ebben az esetben?

3. Hajtson végre egy man-in-the-middle támadást!a. A támadás végrehajtásához alakítson két számítógépből álló csoportokat! A

csoport egyik számítógépe legyen az Internet felé átjáró, ezen a gépen lesz a támadás megvalósítva.

b. Ha sikeresen ellenőrizte, hogy a kliens számítógép az internetes forgalmát az átjárón keresztül bonyolítja, használja a dsniff programot a támadás megvalósítására (lásd segédlet, 24. oldal)! Írja le tapasztalatait a beékelődés után, figyeljen a tanusítványokra! Vonjon le tanulságokat az esetből!

4. Szerezzen információkat egy távoli számítógépről!a. Portscan: próbálja ki az Nmap programot mérőtársa gépén! Milyen portokat

talált nyitva? Dokumentálja a futási eredményeket és ethereal segítségével figyelje meg egy port ellenőrzésének menetét (ehhez érdemes egyetlen portra végezni csak a próbát)!

b. Próbálja ki a FIN próbát Nmap segítségével! Ehhez keressen egy Windows és egy Linux rendszert (lehetőleg használja a laborkörnyezet gépeit)! Hasonlítsa össze a két rendszer viselkedését az ethereal program segítségével a FIN próbára!

c. Nézze meg néhány Interneten elérhető webszerver kezdeti TCP ablakméretét (ehhez használja a telnet programot)! Próbálja meg a kapott értékek alapján a weboldalakat csoportokba rendezni (legyen legalább 10 kiszolgáló próba, ebből kb. 3-4 csoport alakul ki). Miután elkészült, a netcraft.com oldal adatai alapján vesse össze tapasztalatait a kiszolgálók operációs rendszerével! Mit tapasztal a BSD és a Microsoft alapú kiszolgálók kezdeti ablakméretével? (tipp: általában a szervezetek a saját terméküket használják a saját weboldalakhoz, így érdemes lehet megnézni a bsd.hu vagy a microsoft.hu címeket)

23

Segédletek a mérési feladatokhozA rendszergazdai jogokat igénylő programokhoz használja a sudo parancsot! Pl.: sudo tcpdump –i eth0

1. Fork bomba - vázlat/*************************************************** * Fork Bomb - demo ***************************************************/#include <stdio.h>#include <unistd.h>

/* main function */int main(int argc, char *argv[]) { int forked_pid; forked_pid = fork(); if (forked_pid == -1) { /* fork() error */ perror("fork"); exit(1);

} if (forked_pid == 0) { /* child */

} /* parent */ printf("Child started, pid:%d\n", (int)forked_pid);...

Az elkészült program a gcc <állománynév.c> -o <kimeneti_bináris> paranccsal fordítható le.

2. Chroot törés

/*************************************************** * Break Out from Chroot - demo ***************************************************/#include <stdio.h>#include <unistd.h>

int main(void) { int i; mkdir("breakout", 0700); chroot("breakout"); for (i = 0; i < 100; i++) chdir("..") ; chroot("."); execl("/bin/sh", "/bin/sh",NULL);}

A törés kivédéséhez szükségünk lesz a setuid() függvényre, melyről bővebb információt ad a man setuid parancs.

3. A dsniff egy több programból álló programcsomag. HTTPS forgalomba ékelődéshez a webmitm programjára lesz szükségünk. Erről bővebb információ a man webmitm paranccsal érhető el.

24

Irodalomjegyzék[1] Informatikai biztonság – Bevezető

Demcu Karolinahttp://www.biztostu.hu

[2] Biztonságos kommunikációEndrődi Csillahttp://www.biztostu.hu

[3] Szakmai szótárAndrews IT Engineering Kft.http://www.andrews.hu/dictionary.hu.html

[4] BiztonságtudatMagyarorszag.hu - Ügyfélkapuhttp://www.magyarorszag.hu/ugyfelkapu/segitseg/biztonsagtudat/biztonsag.html

[5] Port szkennelés és TCP eltérítésJuhász Péter Károly, Modla Ferenchttp://www.biztostu.hu

[6] Távoli operáció rendszer detektálásJuhász Péter Károlyhttp://www.biztostu.hu

[7] Internet Engineering Task ForceRequest for Commentshttp://www.ietf.org/rfc.html

[8] Remote OS detection via TCP/IP Stack FingerPrintingFyodorhttp://www.insecure.org/nmap/nmap-fingerprinting-article.html

[9] A practical approach for defeating Nmap OS-FingerprintingDavid Barroso Berruetahttp://www.zog.net/Docs/nmap.html

[10] SSL/TLS alapú biztonságos kommunikációInformatikai és Hírközlési minisztériumhttp://www.itktb.hu

[11] Using Chroothttp://www.linuxexposed.com/Articles/General/Using-Chroot-3.html

[12] http://www.grsecurity.net [13] GNU Linux Szakmai Konferencia 2004

Linux-felhasználók Magyarországi EgyesületeBudapest, 2004. november 20.

25