Az IETF éveken át tudatában volt annak, hogy a biztonság hiányzik az internetről. Ezt a hiányt azonban nem volt könnyű pótolni, mert nagy viszály tört ki annak kapcsán, hogy hová is tegyék a biztonsági funkciókat. A legtöbb biztonsági szakértő úgy véli, hogy az igazi biztonságot úgy lehet elérni, ha a titkosítás és a sértetlenség ellenőrzése a végpontok között zajlik (vagyis az alkalmazási rétegben). Azaz, a forrásfolyamat titkosítja és/vagy sértetlenségi védelemmel látja el az adatokat, majd elküldi a célfolyamatnak, ahol dekódolják és/vagy ellenőrzik azokat. Ha a két folyamat között vezető úton bármilyen csalás történik (akár valamelyik operációs rendszerben is), akkor azt észlelni lehet. Ezzel a megközelítéssel az a baj, hogy így az összes alkalmazást meg kell változtatni a biztonság érdekében. Ennek fényében a második legjobb megközelítés az, ha a titkosítást a szállítási rétegbe, vagy egy új, a szállítási és az alkalmazási réteg között lévő rétegbe helyezzük. Ezáltal még mindig végponttól végpontig fog terjedni a védelem, de nem lesz szükség az alkalmazások megváltoztatására.

Az ellenkező nézet szerint a felhasználók nem értenek a biztonsághoz, és nem lesznek képesek megfelelő módon használni azt, a meglévő programokat pedig senki nem akarja majd módosítani, ezért a hálózati rétegnek kellene hitelesíteni és/vagy titkosítani a csomagokat, a felhasználók bevonása nélkül. Sokévi elkeseredett küzdelem után ez a nézet végül elég támogatást kapott ahhoz, hogy sikerüljön kidolgozni egy hálózati réteg biztonsági szabványát. A tábor egyik érve egyébként az volt, hogy a hálózati rétegbeli titkosítás még nem gátolja meg a tudatosan biztonságra törekvő felhasználókat abban, hogy a saját útjukat járják, a többieknek pedig jó hasznára lehet bizonyos mértékig.

A viszály végét az IPsec (IP security – IP-s biztonság) nevű tervezet jelentette, melyet többek között az RFC 2401, 2402 és 2406 ír le. Nem minden felhasználó vágyik titkosításra (mivel annak nagy a számításigénye), de ezt a funkciót mégsem tették opcionálissá. Ehelyett úgy döntöttek, hogy titkosítani mindig kell, de megengedték egy „null” algoritmus használatát is. A null algoritmus leírását, továbbá egyszerűségének, könnyű megvalósíthatóságának és nagy sebességének méltatását az RFC 2410 tartalmazza.

Maga a teljes IPsec egy többféle szolgáltatásból, algoritmusból és felbontásból álló keretrendszer. A többféle szolgáltatást az indokolja, hogy nem mindenki akarja az összes szolgáltatás állandó használatának terhét magára venni, ezért az egyes szolgáltatások „à la carte” is kérhetők. A legfontosabbak a titkosság, a sértetlenség és a visszajátszásos támadások elleni védelem (ahol a támadó visszajátssza a párbeszédet). Ezek mind a szimmetrikus kulcsú kriptográfián alapulnak, mivel a nagy teljesítmény itt létfontosságú.

A többféle algoritmus azért használható, mert attól, hogy ma biztonságosnak gondolunk egy algoritmust, a jövőben még feltörhetik azt. Azáltal, hogy az IPsec független az algoritmusoktól, a keretrendszer még akkor is fennmaradhat, ha valamelyik algoritmust valamikor később feltörik.

A többféle felbontás pedig azért alkalmazható, hogy legyen lehetőség például egy külön TCP-összeköttetés, vagy két hoszt között menő összes forgalom, vagy két biztonságos útválasztó között menő összes forgalom stb. védésére.

Az IPsec-kel kapcsolatban kissé meglepőnek tűnhet az a tény, hogy – annak ellenére, hogy az IP-rétegben van – összeköttetés-alapú. Valójában persze ez nem is olyan meglepő, hiszen bármiféle biztonság eléréséhez először egy kulcsban kell megállapodni, majd azt egy ideig használni – lényegében ez is egyfajta összeköttetés. Sok csomag esetén az összeköttetések még azok kezelésének költségeit is csökkentik. Az összeköttetéseket az IPsec környezetében SA-nak (Security Association – biztonsági kapcsolat) nevezik. Az SA egy szimplex összeköttetés a két végpont között, melyhez egy biztonsági azonosítót is rendeltek. Ha mindkét irányban biztonságos forgalomra van szükség, akkor két biztonsági kapcsolatot kell alkalmazni. Az ilyen biztonságos összeköttetéseken utazó csomagok hordozzák azokat a biztonsági azonosítókat, melyeket a kulcsok és más fontos információ kikeresésére használnak a csomag megérkezésekor.

Műszaki szempontból az IPsec-nek két fő része van. Az első két új fejrészt ír le, melyek a csomagokban a biztonsági azonosítót, a sértetlenséget biztosító adatokat és az egyéb információt hordozza. A másik rész, az ISAKMP (Internet Security Association and Key Management Protocol – internetes biztonsági kapcsolat- és kulcskezelő protokoll) a kulcsok kezelésével foglalkozik. A továbbiakban nem foglalkozunk az ISAKMP-vel, mivel (1) rendkívül bonyolult és (2) a legfontosabb protokollja, az IKE (Internet Key Exchange – internetes kulcscsere) súlyos hibákat rejt, ezért ki kell cserélni – lásd Perlman és Kaufman [2000] írását.

Az IPsec-et a következő két módon lehet használni. A szállítási módban (transport mode) az IPsec-fejrészt közvetlenül az IP-fejrész után illesztik be. Az IP-fejrész protokollmezőjét megváltoztatják oly módon, hogy jelezze azt, hogy egy IPsec-fejrész követi a rendes IP-fejrészt (a TCP-fejrészt megelőzően). Az IPsec-fejrész tartalmazza a biztonsági információt, mindenekelőtt az SA-azonosítót, egy új sorszámot, és esetlegesen az adatmező sértetlenségét ellenőrző adatokat.

Az alagútmódban (tunnel mode) a teljes IP-csomag fejrésszel együtt belekerül egy új IP-csomag törzsébe, mely egy teljesen új IP-fejrészt fog hordozni. Az alagútmód akkor hasznos, amikor az alagút nem a végső címzett állomásnál ér véget. Egyes esetekben az alagút egy biztonsági átjáró-számítógépben végződik, például egy vállalati tűzfalban. Egy VPN-nél (Virtual Private Network – virtuális magánhálózat) ez a szokásos eset. Így a biztonsági átjáró fogja a rajta áthaladó csomagokat be- és kicsomagolni. Ha az alagút ennél a biztonságos gépnél ér véget, akkor a vállalati LAN-on lévő gépeknek nem kell tudniuk az IPsec-ről, elég, ha a tűzfal ismeri azt.

Az alagútmód akkor is hasznos, ha egy kötegnyi TCP-összeköttetést fogunk össze és kezelünk egyetlen titkosított folyamként, mivel a támadó így nem láthatja meg, hogy ki kinek hány csomagot küldött. Néha ugyanis az is értékes információnak számít, ha tudjuk, hogy hová mennyi forgalom megy. Ha például egy katonai válság idején a Pentagon és a Fehér Ház között menő forgalom erősen visszaesik, de valamelyest megnő a Pentagon és egy mélyen a coloradói Sziklás-hegységben lévő katonai támaszpont közötti forgalom, akkor a támadó már ebből is levonhat némi következtetést. A (titkosított vagy hagyományos) csomagok áramlási mintájának elemzését forgalomanalízisnek (traffic analysis) nevezzük. Az alagútmód bizonyos mértékig segít meghiúsítani az ilyen kísérleteket. Ennek a módnak az a hátránya, hogy egy külön IP-fejrészt ad a csomaghoz, jelentősen megnövelve ezzel annak méretét. A szállítási mód ezzel szemben nincs ilyen nagy hatással a csomagméretre.

Az első új fejrész az AH (Authentication Header – hitelesítési fejrész). Ez biztosítja a sértetlenség ellenőrzését és a visszajátszások elleni védelmet, de nem biztosít titkosságot (vagyis nem titkosítja az adatokat). Az AH használatát szállítási módban a 8.27. ábra szemlélteti. Az IPv4-nél ezt a fejrészt az (opciókkal együtt vett) IP-fejrész és a TCP-fejrész közé helyezik. Az IPv6-nál ez csak egy újabb kiegészítő fejrészt jelent, és eszerint is kezelik. Az AH formátuma valójában közelít a szabványos IPv6 kiegészítő fejrész formátumához. Ahogy az az ábrán is látható, az adatmezőt esetlegesen ki kell tölteni valamilyen adott hosszra, hogy a hitelesítő algoritmus működhessen.

8.27. ábra - Az IPsec hitelesítési fejrész szállítási módban, IPv4 esetén

Vizsgáljuk most meg az AH fejrészt! A Következő fejrész (Next header) mező az IP Protokoll (Protocol) mezőjének előző értékét tartalmazza, miután azt 51-re cserélték, annak jelzésére, hogy egy AH fejrész fog következni. Az esetek többségében ide a TCP kódja (6) kerül. Az Adatmező hossza (Payload length) az AH fejrészben lévő 32 bites szavak száma mínusz kettő.

A Biztonsági paraméterek indexe (Security parameters index) maga az összeköttetés-azonosító. Ezt a feladó helyezi el, és a vevő adatbázisának egy konkrét rekordjára utal vele. Az összeköttetést leíró egyéb információ mellett ez a rekord tartalmazza a felhasznált közös kulcsot. Ha a protokollt nem az IETF, hanem az ITU fejlesztette volna ki, akkor ezt a mezőt most Virtuális áramkör számá-nak neveznék.

A Sorszám (Sequence number) mezőt az SA csomagjainak megszámozására használják. Minden csomag egyedi számot kap, még újraküldés esetén is. Más szóval, az újraküldött csomag más számot kap, mint az eredeti (még akkor is, ha a TCP sorszáma ugyanaz marad). Ez a mező a visszajátszásos támadások elleni védelmet szolgálja. Ezek a sorszámok nem fordulhatnak körbe. Ha elfogyott mind a 232, akkor egy új SA-t kell kiépíteni a párbeszéd folytatásához.

Végül elérkeztünk a Hitelesítési adatokhoz (Authentication data), ami egy változó hosszúságú mező, mely az adatmező digitális aláírását tartalmazza. Amikor kiépítenek egy SA-t, a két oldal megállapodik arról, hogy melyik aláírási algoritmust fogják használni. Nyilvános kulcsú kriptográfiát többnyire nem alkalmaznak itt, hiszen a csomagokat rendkívül gyorsan kell feldolgozni, az ismert nyilvános kulcsú algoritmusok viszont túlságosan lassúak. Az IPsec szimmetrikus kulcsú kriptográfián alapul, továbbá az adó és a vevő az SA kiépítése előtt megegyeznek a közös kulcsról, az aláírás kiszámításánál így a közös kulcsot használják. Az egyik egyszerű megoldás szerint a pecsétet a csomag és a közös kulcs együttesére számítják ki. (A közös kulcsot természetesen nem viszik át.) Az ilyen sémákat HMAC-nek (Hashed Message Authentication Code – hash-elt üzenethitelesítő kód) nevezik. Sokkal gyorsabb ezt kiszámítani, mint először az SHA-1-et, majd az RSA-t futtatni az eredményen.

Az AH fejrész nem teszi lehetővé az adatok titkosítását, ezért többnyire akkor célszerű alkalmazni, amikor titkosságra nincs szükség, de a sértetlenség ellenőrzésére igen. Az AH egyik említésre méltó tulajdonsága az, hogy a sértetlenségi próba az IP-fejrész egyes mezőit is védi, mégpedig azokat, melyek nem változnak a csomag útválasztóról útválasztóra való haladása során. Az Élettartam (Time to live) mező például minden ugrásnál változik, ezért azt nem lehet bevonni a sértetlenségi védelembe. A forrás csomópont IP-címére viszont kiterjed az ellenőrzés, ezáltal a támadó nem tudja meghamisítani a csomag eredetét.

Az IPsec alternatívája az ESP (Encapsulating Security Payload – beágyazott biztonsági adatmező). A 8.28. ábra ennek a használatát mutatja be szállítási és alagútmód esetén.

8.28. ábra - (a) ESP szállítási módban. (b) ESP alagútmódban

Az ESP-fejrész két darab 32 bites szóból áll. Ezek az AH-nál már látott Biztonsági paraméterek indexe és a Sorszám mezők. Ezeket általában egy harmadik szó (ami azonban műszakilag már nem része a fejrésznek), a titkosításnál használt Inicializáló vektor (Initialization vector) követi, hacsak nem használunk „null” titkosítást, mert ebben az esetben ez kimarad.

Az AH-hoz hasonlóan az ESP is biztosít HMAC sértetlenség-ellenőrzést, de ezt nem a fejrészben, hanem az adatmezőt követő mezőben teszi, amint azt a 8.28. ábra is mutatja. A HMAC hátravitelének a hardveres megvalósításnál van előnye. A HMAC-t ugyanis elég akkor kiszámolni, amikor a bitek már mennek kifelé a hálózati illesztőn, majd az eredményt hozzáilleszteni a sorozat végéhez. Az Ethernet és más LAN-ok ezért nem fejrészben, hanem farokrészben helyezik el a CRC ellenőrző összegüket. Az AH-nál viszont előbb pufferelni kell a csomagokat, ki kell számítani az aláírást, és csak azután lehet küldeni; ezáltal pedig esetlegesen kevesebb csomagot lehet elküldeni másodpercenként.

Tekintve, hogy az ESP mindent tud, amit az AH, sőt még többet is, ráadásul még hatékonyabb is, adódik a kérdés: mi szükség van akkor az AH-ra egyáltalán. A válasz lényegében történeti okokra vezethető vissza. Eredetileg az AH csak a sértetlenséget, az ESP pedig csak a titkosítást kezelte. Később az ESP-hez is hozzáadták a sértetlenségi védelmet, az AH-t tervező emberek viszont nem akarták, hogy az összes munkájuk kárba menjen. Egyetlen elfogadható érvük volt csak, miszerint az AH az ESP-vel ellentétben az IP-fejrész egyes mezőit is védi, de ez nem igazán nyomós érv. Egy másik gyenge érvük az volt, hogy egy olyan termék, mely az AH-t támogatja, de az ESP-t nem, esetleg könnyebben kap majd exportengedélyt, hiszen nem képes a titkosításra. Az AH valószínűleg fokozatosan meg fog szűnni a jövőben.

Az a képesség, hogy bármely számítógépet bárhol, bármely másik számítógéphez csatlakoztatni lehet, nem csak áldás. Azoknak, akik otthon ülve barangolnak az interneten, jó móka. A vállalati biztonsági menedzsereknek azonban rémálom. A legtöbb társaság nagy mennyiségű bizalmas információt tart online módon a hálózaton: üzleti titkokat, termékfejlesztési terveket, marketingstratégiákat, pénzügyi elemzéseket stb. Súlyos következményekkel járhat ezeknek az információknak a felfedése egy versenytárs előtt.

Az információ kiszivárgásának veszélye mellett fennáll az információ beszivárgásának a veszélye is. Különösen a vírusok, férgek és más digitális kártevők lékelhetik meg a biztonságot, pusztíthatnak el értékes adatokat és vesztegethetik el az adminisztrátorok idejének nagy részét, amikor azok összetakarítják a rendetlenséget, amit hagytak. Ezeket gyakran figyelmetlen alkalmazottak hozzák be, akik valami csillogó új játékot akarnak játszani.

Következésképpen olyan módszerekre van szükség, melyek segítségével a „jó” biteket bent, a „rosszakat” pedig kint tarthatjuk. Az egyik lehetséges módszer az IPsec. Ez a megközelítés a biztonságos helyek között mozgó adatokat védi, ámde semmit sem tesz azért, hogy megakadályozza a digitális kártevők és hackerek betörését a vállalati LAN-ra. A tűzfalak tanulmányozásával azonban megláthatjuk, hogyan lehet elérni ezt a célt is.

A tűzfal (firewall) egyszerűen a régi középkori biztonsági intézkedések modern adaptációja: egy mély árok ásása a vár körül. Ez a tervezés mindenkit, aki a várba be- vagy onnan kilépett, arra kényszerített, hogy egyetlen felvonóhídon haladjon keresztül, ahol a kapuőrség meg tudta figyelni. A hálózatokkal is lehetséges ugyanez a trükk: egy társaságnak számos LAN-ja lehet, tetszőleges módon összekötve, de minden, a társaságtól ki- vagy befelé irányuló forgalomnak egy elektronikus felvonóhídon (tűzfalon) kell keresztülhaladnia, mint ahogy a 8.29. ábrán látszik. Semmilyen más út nem létezik.

8.29. ábra - Egy tűzfal, amely egy belső hálózatot véd

A tűzfal egy csomagszűrőként viselkedik. Megvizsgál minden egyes bejövő és kimenő csomagot. Azok a csomagok, amelyek megfelelnek a hálózati adminisztrátor által kialakított szabályoknak, feltételeknek, szabályosan továbbítódnak. Amelyek elbuknak a teszten, azok teketória nélkül eldobásra kerülnek.

A szűrési feltételeket jellemzően olyan szabályok vagy táblázatok segítségével adják meg, amelyek felsorolják, hogy mely források és célok elfogadhatók, melyeket kell blokkolni. Ezeken kívül vannak még alapértelmezési szabályok arra vonatkozóan, hogy mit kell csinálni más gépektől jövő vagy azokhoz menő csomagokkal. A szokásos TCP/IP-felállásban, a forrás és cél megadható IP-címekkel és portszámokkal. Például a 25-ös TCP-port a levelezéshez, míg a 80-as a HTTP-hez tartozik. Bizonyos portok egyszerűen blokkolhatók. Például egy vállalat blokkolhatja az összes IP-címmel összefüggésben a 79-es TCP-portot. Ez egyébként a valamikor népszerű, a felhasználók elektronikus levelezési címének lekérdezésére szolgáló Finger szolgáltatáshoz tartozott, napjainkban már kevésbé használják.

Más portok nem blokkolhatók olyan könnyen. A nehézség abból ered, hogy a hálózati adminisztrátorok biztonságra törekednek, de nem vághatják el a külvilággal folytatott kommunikációt. Ez a megoldás egyszerűbb és jobb lenne biztonsági szempontból, de végeláthatatlan felhasználói panaszkodáshoz vezetne. Ebben a helyzetben ügyes megoldás a 8.29. ábrán látható DMZ (DeMilitarized Zone – demilitarizált övezet). A DMZ a vállalati hálózat olyan része, mely kívül esik a biztonsági határon. Ide bármilyen forgalom bejöhet. A demilitarizált zónában elhelyezett gépeket, például egy webszervert, az internethez csatlakozó gépek elérhetik, a vállalat weboldalát böngészhetik. Ezek után a tűzfalat be lehet úgy állítani, hogy blokkolja a 80-as TCP-portra irányuló bemeneti forgalmat, vagyis az internetről a belső hálózat gépei nem támadhatók ezen a porton. Hogy a webszerver menedzselhetőségét lehetővé tegyük, a tűzfalnak lehet olyan szabálya, amely megengedi a webszerverhez kapcsolódást a belső gépekről.

A tűzfalak egyre fejlettebbek lettek a támadókkal folytatott fegyverkezési versenyben. Eredetileg a tűzfalak egyetlen szabályhalmazt alkalmaztak minden egyes csomagra. Nehéznek bizonyult azonban olyan szabályokat írni, amelyek fenntartják a hasznos funkciókat, de blokkolják az összes nemkívánatos forgalmat. Az állapottal rendelkező tűzfalak (stateful firewall) hozzárendelik a csomagokat az összeköttetésekhez és a TCP/IP-fejlécmezők segítségével nyilvántartják az összeköttetések állapotát. Ez lehetővé teszi például olyan szabályok írását, melyek megengedik, hogy egy külső webszerver csomagokat küldjön egy belső hosztnak, de csak akkor, ha a belső hoszt kezdeményezte az összeköttetést a külső webszerverrel. Ilyen szabályok nem működhetnek egy állapottal nem rendelkező megoldásnál, ahol vagy átmegy, vagy eldobásra kerül minden olyan csomag, amely a külső webszervertől jön.

A tűzfalaknál az állapottal rendelkező feldolgozás utáni következő fejlettségi szint az alkalmazásszintű átjárók (application-level gateway) megvalósítása. Ennél a fajta feldolgozásnál a tűzfal belenéz a csomagok belsejébe a TCP-fejlécen túl is, azt kutatva, hogy mit csinál az adott alkalmazás. Ezzel a képességgel elkülöníthető a webböngészésre használt HTTP-forgalom az egyenrangú társak közötti (peer-to-peer) fájlcserélésre használt HTTP-forgalomtól. Az adminisztrátorok írhatnak olyan szabályokat, amelyek megkímélik a vállalatot az egyenrangú társak közötti fájlcseréléstől, de megengedik az üzletvitelhez fontos webböngészést. Megvizsgálható például a kimenő vagy bejövő forgalom tartalma, hogy megakadályozzák érzékeny dokumentumok kijuttatását a vállalattól.

A fenti fejtegetésből világosnak kell lennie, hogy a tűzfalak megsértik a protokollok szabványos rétegzettségét. Ezek az eszközök a hálózati rétegben működnek, de a szállítási és alkalmazási réteget is figyelembe veszik a szűréshez. Ez gyengévé teszi őket. Például a tűzfalak hajlamosak a szabványos portszámozási konvenciókra támaszkodni a csomagban szállított forgalom típusának meghatározásához. A szabványos portkiosztást ugyan gyakran használják, de nem minden számítógép és nem minden alkalmazás. Néhány peer-to-peer alkalmazás dinamikusan választ portokat, hogy nehezebb legyen felfedezni (és blokkolni). Az IPsec titkosítása és más megoldások elrejtik a magasabb rétegek információit a tűzfalak elől. Végezetül egy tűzfal nem tud kommunikálni azokkal a számítógépekkel, melyek forgalma keresztülmegy rajta, vagyis nem tudja közölni, hogy milyen szabályok érvényesek, és hogy miért bontotta le közöttük az összeköttetést. Egyszerűen úgy tűnik, mint ha vezetékszakadás lenne. Ezekből az okokból kifolyólag a tiszta hálózati megoldások hívei a tűzfalakra az internetarchitektúra szennyfoltjaiként tekintenek. Az internet azonban a számítógép számára veszélyes hely. A tűzfalak segítenek ezen a problémán, tehát egyelőre nagy valószínűséggel maradnak.

Egy sereg biztonsági probléma merül föl azonban még akkor is, ha a tűzfal tökéletesen van konfigurálva, biztonsági problémák sokasága áll fenn. Például, ha a tűzfal úgy van beállítva, hogy csak bizonyos hálózatokból engedjen be csomagokat (például a vállalat másik telephelyeiről), egy behatoló a tűzfalon kívülről hamis forráscímek használatával megkerülheti ezt az ellenőrzést. Ha pedig egy belső alkalmazott titkos dokumentumokat akar kijuttatni, titkosíthatja vagy akár le is fényképezheti azokat, és a fotókat JPEG-fájlként küldve kijátszhatja az e-mail szűrőket. Azt a tényt pedig még nem is említettük, hogy bár a támadások háromnegyede a tűzfalon kívülről jön, a tűzfalon belülről érkező támadások, amelyek például elégedetlen alkalmazottak részéről érkeznek, tipikusan a legkártékonyabbak [Verizon, 2009].

A tűzfalakkal kapcsolatos további probléma, hogy egyszeres védelmi vonalat jelentenek. Ha ezt a védelmet áttörik, akkor minden gát szakad. Ezért a tűzfalakat gyakran egy többszintű védelem részeként alkalmazzák. Például egy tűzfal védheti a belső hálózatot, és minden gép futtathatja a saját tűzfalát. Azok az olvasók, akik úgy gondolják, hogy egyetlen biztonsági ellenőrző pont elég, biztosan nem repültek egy menetrend szerinti nemzetközi járattal mostanában.

Mindennek tetejébe a támadásoknak egy teljesen más csoportja is létezik, amellyel szemben a tűzfalak tehetetlenek. A tűzfal alapötlete az, hogy megakadályozza a támadók be-, valamint a titkos adatok kijutását. Sajnos vannak azonban olyan emberek is, akiknek nincs jobb dolguk, mint hogy megpróbáljanak egyes oldalakat térdre kényszeríteni. Ezt úgy érik el, hogy olyan nagy számban zúdítják az egyébként legális csomagjaikat a céljukra, hogy az összeomlik a terhelés alatt. Ha a támadó például egy webhelyet akar megbénítani, akkor elküldhet egy TCP SYN csomagot, mely az összeköttetés kiépítésére szolgál. A webhely ezután megpróbál egy táblázatbejegyzést rendelni az összeköttetéshez, és válaszul elküld egy SYN + ACK csomagot. Ha a támadó nem felel, a bejegyzés foglalt marad még egy pár másodpercig, mielőtt lejárna az időzítése. Ha tehát a támadó több ezer ilyen kérelmet küld el, akkor a táblázat összes bejegyzése foglalt lesz, és legális összeköttetéseket sem lehet majd létesíteni. Az ilyen támadásokat, melyekben a támadó célja nem az adatok ellopása, hanem a célgép megbénítása, DoS (Denial of Service – szolgáltatás megtagadása) típusú támadásoknak nevezzük. Ráadásul a kérelmet tartalmazó csomagok általában hamis forráscímet hordoznak, így a támadót nem könnyű megtalálni. A nagyobb webhelyek elleni DoS-támadások gyakoriak az interneten.

Ennél is rosszabb változat az, amikor a támadó már világszerte több száz másik számítógépbe tört be, majd mindegyiket arra utasítja, hogy egyszerre indítsanak támadást ugyanazon célpont ellen. Ez a megközelítés nemcsak a támadó tűzerejét növeli meg, de csökkenti a megtalálásának esélyét is, hiszen a csomagok nagyszámú, gyanútlan felhasználóhoz tartozó gépről érkeznek. Az ilyen támadások neve DDoS (Distributed Denial of Service – szolgáltatás elosztott megtagadása). Az effajta támadások ellen nehéz védekezni. Ha a megtámadott gép még gyorsan fel is tudja ismerni a hamis kérést, akkor is időbe telik neki feldolgoznia és eldobnia azt, és ha kellően sok kérés érkezik másodpercenként, akkor a processzor minden idejét azok feldolgozásával fogja eltölteni.

Sok vállalatnak van irodája és telephelye több városban elszórtan, olykor akár különböző országokban is. A nyilvános adathálózatok előtti régi szép időkben gyakori volt, hogy az ilyen vállalatok a telefontársaságoktól béreltek vonalakat, hogy összekössék néhány vagy az összes telephelyüket. Egyes vállalatok még ma is ezt teszik. A vállalati számítógépekből és bérelt telefonvonalakból álló hálózatokat magánhálózatnak (private network) nevezzük.

A magánhálózatok jól működnek és nagyon biztonságosak. Ha a bérelt vonalakon kívül nem alkalmaznak más összeköttetést, akkor semmilyen forgalom nem szivároghat ki a vállalat telephelyeiről, a támadóknak pedig fizikailag meg kell csapolniuk a vonalakat a betöréshez, ami azért nem olyan egyszerű. A magánhálózatokkal csak az a gond, hogy egyetlen T1-es vonal bérleti díja is több ezer dollárt tesz ki havonta, a T3-as vonalak pedig még ennél is sokkal drágábbak. Amikor az internet és a nyilvános adathálózatok megjelentek, sok vállalat szerette volna átvinni az adat- (és esetleg a hang-) forgalmát a nyilvános hálózatra, mégpedig a magánhálózatok nyújtotta biztonság feladása nélkül.

Ez az igény hamar elvezetett a VPN-ek (Virtual Private Networks – virtuális magánhálózatok) kifejlesztéséig, amelyek a nyilvános hálózatok tetejébe épülnek, mégis rendelkeznek a magánhálózatok legtöbb tulajdonságával. A „virtuális” nevet azért kapták, mert pusztán illúziónak számítanak éppúgy, mint ahogyan a virtuális áramkörök sem igazi áramkörök és a virtuális memória sem igazi memória.

Az egyik népszerű megoldás az, hogy a VPN-eket közvetlenül az interneten keresztül kell kiépíteni. Elterjedt megoldás, hogy minden irodát felszerelnek egy tűzfallal, az irodák között páronként létrehoznak egy alagutat az interneten keresztül, ahogy az a 8.30.(a) ábrán látható. További előnye az interneten keresztül történő összeköttetésnek, hogy az alagutak igény szerint kialakíthatók egy otthon tartózkodó vagy utazó személy számítógépének bevonásával mindaddig, amíg ő internetkapcsolattal rendelkezik. Ez sokkal rugalmasabb, mint a bérelt vonalak, még a VPN-en lévő gépek szempontjából is, a topológia látszólag megegyezik a privát hálózattal, ahogy az a 8.30.(b) ábrán látható. Amikor a rendszer feláll, a tűzfalaknak páronként egyeztetniük kell SA-paramétereiket, többek között a szolgáltatásokat, működésmódokat, algoritmusokat és kulcsokat. Ha az alagutak kialakítására IPsec-et használnak, akkor lehetőség van bármely irodapárok közti forgalom összevonására (aggregálására) egyetlen hitelesített, titkosított SA-ba, vagyis biztosítható az integritásellenőrzés, a titkosítás és jelentős immunitás a forgalom elemzése ellen. Sok tűzfal rendelkezik beépített VPN-képességekkel. Néhány hagyományos útválasztó is tudja ezt, de mivel a tűzfalak elsődleges feladata a biztonság megteremtése, természetes, hogy az alagutak végpontjai a tűzfalaknál vannak, tökéletesen elválasztva egymástól a vállalatot és az internetet. Így a tűzfalak, a VPN-ek és az ESP-vel alagútmódban működő IPsec természetes együttest alkotnak és a gyakorlatban széles körben használják.

8.30. ábra - (a) Egy virtuális magánhálózat (b) Topológia, ahogy az belülről látszik

Az SA kialakítása után megindulhat a forgalom. Az internetes útválasztók számára a VPN-alagúton utazó csomagok is ugyanolyanok, mint bármely más csomag. Ezekben a csomagokban az egyetlen rendhagyó dolgot az jelenti, hogy az IP-fejrész után egy IPsec-fejrész található bennük, de mivel az ilyen kiegészítő fejrészek nincsenek hatással a továbbítás folyamatára, a útválasztók nem foglalkoznak ezzel a fejrésszel sem.

A másik egyre népszerűbb megközelítés az, amikor az ISP alakítja ki a VPN-t. MPLS használatával (az 5. fejezetben tárgyalt módon) a VPN-forgalomhoz tartozó utak az ISP hálózatán keresztül felépíthetők a vállalat irodái között. Ezek az utak elválasztják a VPN-forgalmat a másfajta internetforgalomtól, és ugyanakkor egy adott sávszélesség vagy más szolgáltatásminőségi jellemző garantálható.

A virtuális magánhálózatok legfontosabb előnye, hogy az alkalmazási szoftverek számára átlátszó. A tűzfal építi fel és menedzseli az SA-kat. Az egyetlen személy, aki ennek a beállításnak a tudatában van, a rendszergazda, akinek be kell állítania és kezelnie kell a biztonsági átjárókat, vagy az az ISP-adminisztrátor, akinek az MPLS-utakat kell beállítania. Mindenki más számára ez egy bérelt vonalakból álló privát hálózatnak látszik. A VPN-ekkel kapcsolatos további információért lásd Lewis [2006] művét.

Meglepően egyszerű olyan rendszert tervezni, amely a VPN-ek és a tűzfalak révén elméletileg teljesen biztonságos, a gyakorlatban mégis olyan lyukas, mint a szita. Ez a helyzet állhat elő például akkor, ha a gépek egy része vezeték nélkül, rádiós úton kommunikál, mindkét irányban megkerülve ezzel a tűzfalat. A 802.11-es hálózatok hatótávolsága gyakran néhány száz méteres is lehet, így ha valaki kémkedni akar egy vállalatnál, elég, ha egyszerűen beáll a dolgozói parkolóba reggel, bennhagyja a kocsiban a 802.11-gyel felszerelt hordozható számítógépét, ami mindent rögzít, amit csak hall; majd a nap végén továbbáll. A merevlemez késő délutánra tele lesz értékes holmival. Elméletileg persze ilyesmi nem történhet meg. Bár elméletileg nem történhetnek meg a bankrablások sem.

A biztonsági problémák jó része a vezeték nélküli bázisállomások (hozzáférési pontok) gyártóinak azon törekvéseire vezethető vissza, hogy termékeiket minél inkább felhasználóbaráttá tegyék. Ezek az eszközök rendszerint azonnal működni kezdenek, ahogy a felhasználó kiveszi őket a dobozból és csatlakoztatja őket a villamos hálózathoz – gyakorlatilag bárminemű biztonság nélkül, az egész vételkörzetben szétkürtölve ezzel a titkokat. Ha a készüléket ezután csatlakoztatják az Ethernetre, akkor hirtelen a parkolóban is megjelenik az Ethernet teljes forgalma. A vezeték nélküli rendszerek a kémek valóra vált álmai: adatok ingyen, minden erőfeszítés nélkül. Mondani sem kell tehát, hogy a biztonság a vezeték nélküli rendszerekben még fontosabb, mint a vezetékesekben. Ebben a szakaszban megnézzük néhány módját annak, hogyan kezelhetik a vezeték nélküli hálózatok a biztonságot. További információval Nichols és Lekkas [2002] műve szolgál.

8.6.4.1. A 802.11 biztonsága

A 802.11 szabvány egy része, amely eredetileg 802.11i néven szerepelt, előír egy adatkapcsolati rétegben lévő biztonsági protokollt, mely megakadályozza, hogy a vezeték nélküli csomópontok olvassák vagy zavarják a vezeték nélküli hálózat másik csomópontpárjai közötti üzeneteket. Ez a megoldás fut még WPA2 (Wi-Fi Protected Access 2 – Wi-Fi védett hozzáféréssel 2) márkanéven is. A sima WPA egy átmeneti megoldás, mely a 802.11i egy részhalmazát implementálja. Használata kerülendő, jobb a WPA2.

Mielőtt bemutatjuk a 802.11i-t, meg kell jegyeznünk, hogy a WEP (Wired Equivalent Privacy – vezetékessel egyenértékű titkosság) leváltására jött létre, ami a 802.11 első generációs biztonsági protokollja volt. A WEP-et egy hálózati szabványokkal foglalkozó bizottság tervezte, merőben más eljárással, mint ahogy például a NIST az AES-t tervezte. Az eredmény katasztrofális volt. Mi volt a baj vele? Mint kiderült, biztonsági szempontból nagyon sok minden. Például a WEP úgy titkosította az adatokat, hogy azokat a biztonság érdekében kizáró vagy kapcsolatba hozta egy folyamtitkosító kimenetével. Sajnos a gyenge kulcskiosztás azt jelentette, hogy gyakori volt ennek a kimenetnek az újrafelhasználása. Ez azután triviális feltörési módokhoz vezetett. Egy másik példa, hogy az integritásellenőrzést 32 bites CRC-re alapozták. Ez ugyan hatékony kódolás átviteli hibák detektálására, de kriptográfiai szempontból egyáltalán nem erős védelem a támadók elriasztására.

Ezek és más tervezési hiányosságok a WEP-et könnyen kijátszhatóvá tették. A WEP feltörhetőségének első gyakorlati demonstrációja Adam Stubblefieldtől származik, aki akkor gyakornok volt az AT&T-nél [Stubblefield és mások, 2002]. Képes volt megírni és tesztelni egy Fluhrer és társai által vázolt támadást [Fluhrer és mások, 2001] egy hét alatt, melyből a legtöbb idő arra ment el, hogy rávegye a menedzsmentet a kísérlethez szükséges Wi-Fi-kártya megvásárlására. Manapság a WEP-jelszavakat egy percen belül feltörő szoftverek ingyenesen elérhetők, és a WEP használata erősen ellenjavallt. Bár megakadályozza az alkalmi hozzáférést, de valódi biztonságot egyáltalán nem nyújt. Amikor világossá vált, hogy a WEP komolyan feltörhető, sürgősen felállították a 802.11i csoportot, amely 2004 júliusára elő is állított egy hivatalos szabványt.

Most pedig bemutatjuk a 802.11i-t, amely megfelelően beállítva és használva valóban biztonságot nyújt. A WPA2 használatára két szokásos forgatókönyv létezik. Az első egy vállalati felállás, ahol a vállalatnak van egy különálló hitelesítő szervere felhasználóneveket és jelszavakat tartalmazó adatbázissal, amelynek segítségével eldönthető, hogy jogosult-e a vezeték nélküli kliens a hálózat használatára. Ebben az elrendezésben a kliensek szabványos protokollokat használnak hitelesítésre a hálózat felé. A fő szabvány a 802.1X, amelynek segítségével a hozzáférési pont biztosítja a kliens és a hitelesítő szerver közötti párbeszédet, és értesül az eredményről, valamint az EAP (Extensible Authentication Protocol – kiterjeszthető hitelesítő protokoll) (RFC 3748), mely leírja, hogyan működjön együtt a kliens és a hitelesítő szerver. Az EAP valójában egy keretrendszer, és a protokollüzeneteket más szabványok definiálják. Nem merülünk bele azonban ezeknek az üzenetváltásoknak a részleteibe, mert nem sokkal járulnak hozzá az áttekinthetőséghez.

A másik forgatókönyv egy otthoni felállás, amelyben nincs hitelesítő szerver. Ehelyett van egy közös jelszó, amelyet a kliensek a vezeték nélküli hálózat elérésére használnak. Ez az elrendezés sokkal egyszerűbb, mint a hitelesítő szerver használata, ezért is használják otthon, illetve kis vállalkozásoknál, de kevésbé biztonságos. A fő különbség az, hogy a hitelesítő szerver használatánál a forgalom titkosítására minden kliens a többi kliens számára nem ismert kulcsot kap. Egyetlen közös, megosztott jelszó segítségével minden kliens számára különböző kulcsok származtathatók, de mivel az összes kliensnek ugyanaz a jelszava, származtathatják egymás kulcsait, ha akarják.

A forgalom titkosítására szolgáló kulcsok egy hitelesítési kézfogás részeként számítódnak ki. A kézfogásra közvetlenül az után kerül sor, hogy a kliens vezeték nélküli hálózathoz kapcsolódik és hitelesíti magát a hitelesítő szerverrel, ha van ilyen. A kézfogás kezdetén a kliens vagy rendelkezik a közös hálózati jelszóval, vagy a hitelesítő szerverhez használható saját jelszóval. Ez a jelszó felhasználásra kerül egy mesterkulcs származtatására. A mesterkulcsot azonban nem használják közvetlenül a csomagok titkosításánál. A gyakorlatban az a szabványos kriptográfiai megoldás, hogy egy viszonykulcsot (session key) kell meghatározni minden használati időszakra, a kulcsot meg kell változtatni a különböző munkamenetek között, és a mesterkulcsot a lehető legkevesebb megfigyelési lehetőségnek kell kitenni. A kézfogás alkalmával a viszonykulcs az, amelyet kiszámítanak.

A viszonykulcs négyutas meghatározása látható a 8.31. ábrán. Először az AP (access point – hozzáférési pont) küld egy egyszer használatos véletlen számot azonosítás végett. A biztonsági protokollokban a pontosan egyszer használt véletlen számokat nonce ^[43] -nak hívják, ami többé-kevésbé a „number used once” rövidítése. A kliens szintén választ egy saját nonce-t. A kliens ezután az egyszer használatos számok, a saját és a hozzáférési pont MAC-címe, valamint a mesterkulcs alapján meghatározza a K_S viszonykulcsot. A viszonykulcsot részekre bontják, melyeket különböző célokra használnak, de ezek elhanyagolható részletek. A kliensnek most már vannak viszonykulcsai, de a hozzáférési pontnak még nincs. Ezért a kliens elküldi az egyszer használatos véletlen számát (nonce) az AP-nak, ami ugyanezen számításokkal meghatározza ugyanezeket a viszonykulcsokat. Az egyszer használatos véletlen számok elküldhetők nyílt szövegként, mivel a kulcsok nem határozhatók meg belőlük további titkos információ nélkül. A kliens üzeneteit egy a viszonykulcson alapuló integritásellenőrző védi, amelynek neve MIC (Message Integrity Check – üzenetintegritás-ellenőrző). Az AP a viszonykulcs kiszámítása után ellenőrizheti, hogy az MIC rendben van-e, és így az üzenet valóban a klienstől származik-e. Az MIC csupán egy másik elnevezés az üzenethitelesítő kódra, ahogy az előfordul egy HMAC-ban is. Az MIC kifejezést gyakran használják hálózati protokollok helyett, a MAC (Medium Access Control) rövidítéssel való potenciális keveredés elkerülése érdekében.

8.31. ábra - A 802.11i kulcsmeghatározási kézfogás

Az utolsó két üzenetben az AP átadja a K_G csoportkulcsot a kliensnek, és az nyugtázza az üzenetet. Ezek az üzenetküldések és nyugtázások lehetővé teszik, hogy a kliens és az AP kölcsönösen ellenőrizze, hogy a másiknak megfelelő viszonykulcsa van-e. A csoportkulcsot üzenetszórásra és többesküldésre használják a 802.11 LAN-on. Mivel a kézfogás eredményeként minden kliensnek saját titkosító kulcsai lesznek, az AP nem használhatja azokat az összes kliensnek szóló csomagszórásra; minden kliensnek külön el kellene küldeni ezeket a csomagokat a saját kulcsaikkal titkosítva. Ehelyett szétosztanak egy közös kulcsot, így az üzenetszórásos forgalmat csak egyszer kell elküldeni, és azt minden kliens venni tudja. Ezt frissíteni kell minden olyan esetben, ha kliensek elhagyják a hálózatot vagy csatlakoznak hozzá.

Végül eljutunk ahhoz a részhez, amikor a kulcsok ténylegesen gondoskodnak a biztonságról. A 802.11i-ben két protokollt lehet használni üzenettitkosság, integritás és hitelesítés biztosítására. A WPA-hoz hasonlóan, a TKIP (Temporary Key Integrity Protocol – időleges kulcsú integritási protokoll) is átmeneti megoldás volt. A régi és lassú 802.11 kártyák biztonságának fokozására tervezték, hogy a WEP-nél egy kicsit biztonságosabb megoldással firmware javításként lehessen kijönni a piacra. Ez is hibásnak bizonyult azonban, így jobban járunk a másik javasolt protokoll, a CCMP használatával. Mit jelent a CCMP? Ez a látványosan hosszú név, a Counter mode with Cipher block chaining Message authentication Protocol (titkos blokkláncolású számláló módú üzenethitelesítő protokoll) rövidítése. Mi csak CCMP-nek fogjuk hívni, Ön annak hívja, aminek akarja.

A CCMP elég lényegre törően működik. AES-titkosítást használ 128 bites kulcs- és blokkhosszal. A kulcs a viszonykulcsból származik. A titkosság biztosítására az üzenetek az AES számlálómódjával kerülnek titkosításra. Emlékezzünk vissza a 8.2.3. fejezetben a titkosító módokról elmondottakra. Ezek a módok megakadályozzák, hogy titkosításkor ugyanaz az üzenet mindig ugyanazon bitsorozattá kódolódjon. A számláló mód egy számlálót kever a titkosításhoz. Az integritás biztosítása érdekében, az üzenet a fejlécmezőkkel együtt keresztülmegy titkosított blokkláncolásos kódoláson, így az utolsó 128 bites blokk megtartható MIC-nek. Ezután mind a számlálómóddal tikosított üzenet, mind az MIC átvitelre kerül. Ezt a titkosítást a kliens és az AP is elvégezheti, illetve ellenőrizheti csomag érkezésekor. Az üzenetszóráshoz és a többesküldéshez ugyanez az eljárás használható a csoportkulccsal.