A legelején fontos tisztázni, hogy miért is használunk rejtjelezett csatornákat? Azzal talán mindenki tisztában van, hogy az ilyen csatornák legfőbb feladata az átvitel bizalmasságának megőrzése, másként fogalmazva biztosítani azt, hogy valóban csak a kommunikáló felek értsék az üzenetet. Sőt ezen felül az SSL-protokoll számos feladatot ellát. Hitelesíti például a feleket egymás számára.
A gyakorlatban azonban utóbbit csak szerverek hitelesítésére használjuk. Az üzemeltető úgynevezett tanúsítványt vásárol egy megbízható harmadik félnél (ezt minősített hitelesítés szolgáltatónak, angolul CA-nak - Certificate Authoritynak - hívják). A CA-nak természetesen van saját tanúsítványa, ami jó eséllyel minden operációs rendszerben és minden böngészőben telepítve van. A böngészőnk ennek segítségével tudja azonosítani, hogy valóban a megfelelő szerverhez kapcsolódott-e. Az SSL-ben emellett benne van az a képesség is, hogy a kliens, azaz a böngésző is küldjön ilyen tanúsítványt a szerver felé. Ezt kölcsönös autentikációnak hívják sokkal, ám e megoldás kevésbé elterjedt. Helyette a weboldalak más módszerrel, tipikusan jelszóval hitelesítik a felhasználókat. Bankok esetében ezt megfejelik más azonosítási módszerrel, mely többnyire a mobiltelefonunkkal áll kapcsolatban (SMS).
Ha az IT biztonság alapelemeit tekintjük: bizalmasság, sértetlenség, rendelkezése állás (C.I.A.) kiegészítve a letagadhatatlansággal és hitelességgel, látjuk, hogy az SSL a bizalmasságot, hitelességet valamint a sértetlenséget képes garantálni. Ez utóbbit, úgy, hogy ha valaki piszkálja a forgalmat, azt nem lehet többé az eredeti kulcsokkal visszafejteni. Amennyiben egy illetéktelen személy mégis csintalankodik - például közbeékelődéses támadást hajt végre (MITM) - azt könnyen észrevehetjük (lásd a lenti képen).
Itt érdemes megállni még egyetlen percre! Mit érdemes nézni, egy SSL védett oldalon?
- A tanúsítványt olyan CA állította ki, akiben megbízunk
- A tanúsítvány érvényességi ideje nem járt le
- A tanúsítványt nem vonta vissza sem a CA, sem pedig a tulajdonos
- A tanúsítványt arra használják, amire a CA engedélyt adott (és a tulajdonos kért)
- A tanúsítvány tényleg az adott weboldalnak szól (Subject mező CN ellenőrzés)
További VPN technológiák
Mivel az TCP/IP technológia tervezési szinten sem tartalmaz rejtjelezést (az őse, az ISO/OSI igen) ezért számos megoldás született ennek a funkciónak a megvalósítására. Az SSL technológia az alkalmazási rétegben oldja meg ezt a feladatot, egy SSL csatornában futatva a beágyazott protokoll, ami böngészés esetén HTTPS, levelezésnél pedig IMAPS vagy POP3S néven valósul meg. A fejlesztők és protokoll-tervezők azonban itt nem álltak meg. Szerették volna, ha nem csak néhány alkalmazás, hanem az egész gép, de akár több hálózat is "beszélhetne" egymással ezen a rejtjelezett nyelven. Ezen esetben minden alkalmazásnak képesnek kell lennie az SSL használatára, így egyszerűbb, ha ezt valamilyen másik szinten hajtjuk végre. Az egyik, az IPv6-ból visszafelé megvalósított (backportolt) IPSec technológia.
Itt az IP (v4) felett nem TCP protokoll, hanem egy másik, úgynevezett ESP protokoll található meg (illetve más is, de ezt most nem keverem ide). Az ESP egy rejtjelezett adathalmaz, melynek tartalma az eredeti alkalmazási, a TCP és opcionálisan az IP réteg. Utóbbira akkor lehet szükségünk, amikor nem két munkaállomás között, hanem gép és hálózat, illetve hálózat-hálózat közötti VPN-t szeretnénk kiépíteni. A másik lehetőség pedig az, amikor az alkalmazási rétegben felépített SSL csatornában nem az alkalmazási réteget, hanem egy IP réteget "tunnelezünk" be. Ezt csinálja például az OpenVPN. Az utóbbi két esetben tehát nem csak egy-egy alkalmazást, hanem több hálózatot is összeköthetünk.
A kétélű fegyver
A rejtjelezett hálózatok napjainkban olyan elterjedtek lettek, hogy a tűzfalakon való átengedésük üzleti követelménnyé vált! Ugye senki nem szeretne visszamenni a bankba minden egyes utalásra a megfelelő kis rózsaszín megbízást kitölteni és sorban állni órákat? Az adóbevallást és társait sem a postán adjuk fel, hanem az ügyfélkapun töltjük fel. Ezzel nem csak az folyamatokat gyorsítjuk fel, de pénzt is takarítunk meg és zöldebbek is leszünk! Az ilyen kapcsolatok tiltása a tűzfalon tehát manapság elképzelhetetlen. Ellenőrzés nélkül kiengedni viszont öngyilkosság! Ha nem ellenőrizzük ugyanis ezeket a csatornákat, akkor egy külső vagy belső támadó minden nehézség nélkül fog teljes hozzáférést kiépíteni a belső hálózatunkhoz.
Az etikus-MITM
A tűzfalakon tehát ezt a feladatot úgy oldják meg, hogy végződtetik a VPN kapcsolatokat, majd az ott futó proxyk belenéznek az adatfolyamba. Ilyenkor a tűzfal valamilyen belső tanúsítványt mutat fel a kliensek felé, és ellenőrzi a szerver eredeti tanúsítványát a tűzfalra telepített tanúsítványtárral. Ez persze azt is jelenti, hogy a tűzfal olyan forgalmat is lát, amit hivatalosan nem tehetne. Nincs mit tenni, a tűzfal már csak ilyen. Meg kell benne bízni! Akinek meg fáj, hogy bele lát a féltett forgalmába, az bankoljon otthonról. Van még egy hozadéka a tűzfalas végződtetésnek. A felhasználók túlnyomó többsége sajnos figyelmen kívül hagyja a böngésző figyelmeztetését, ha a szerver nem megbízható, mert rossz/lejárt tanúsítványt mutatott fel. Amennyiben a tűzfal köztük áll, ezt a feladatot a tűzfal látja el az előbb említett belső tanúsítványtárral.
Helyesen beállított szabályok mellett a lejárt vagy hibás tanúsítvány esetén a tűzfal megszakítja a kapcsolatot. Ennek természetes mellékhatása lesz, hogy az oldalak nagy többsége elérhetetlenné válik, ami rengeteg hibabejelentést eredményez a tűzfal üzemeltetőjénél. Az, hogy megengedjük a csatlakozást az ilyen szerverekhez, rontaná a helyzetet, mert a tűzfal minden esetben azt az egy belső tanúsítványt mutatná fel, amit beállítottunk, így a felhasználó nem tudná eldönteni, az eredeti tanúsítvány megbízható-e vagy sem.
Erre is van megoldás: ha a tűzfal először a szerverhez kapcsolódik, majd az eredet tanúsítvánnyal azonos paraméterű másolatot készít, azt az eredeti tanúsítványnak megfelelő belső megbízható, vagy nem megbízható CA-val aláírva. Így a tűzfal által felmutatott tanúsítványból a felhasználó következtetni tud, hogy az eredeti tanúsítvány milyen volt. míg párhuzamosan a tűzfal képes a beágyazott kapcsolat ellenőrzésére is.
Egyéb VPN-ek esetében a proxyk nem beágyazással, hanem rendes végződtetéssel oldják meg ezt a feladatot. A tűzfal ilyenkor rendes VPN koncentrátorként működik, lezárva a VPN kapcsolatot, majd a kapcsolatban átvitt protokollal pontosan azt a feladatot végzi el, mintha nem is rejtjelezett csatornán jönne. A megoldásnak blikkfanja, hogy a VPN-be ágyazott SSL csatornákkal is működik mindez. Így elkerülhető a gyakori tervezési hiba, hogy a VPN felhasználót teljes jogú belső gépként kezelik. Ilyenkor a támadó nem a belső hálózatot támadja, hanem a VPN kliens gépét és azon keresztül próbál belépni (be-routolja magát a belső hálózatba). Ha a tűzfal tehát nem ellenőrzi az ilyen kapcsolatokat, a támadó akadály nélkül jut a belső hálózatba. Természetesen csak akkor, ha a kliens gépen a hoszt védelmet ki tudja játszani.
Összefoglalásként látható tehát, hogy a rejtjelezett technológiák milyen kétélű fegyvert jelentenek a határvédelem szemszögéből. Ha nem használunk ilyen technológiákat, akkor a szigor miatt jó pár szolgáltatásból zárjuk ki magunkat. Ellenben ha ellenőrzés nélkül, korlátlanul engedjük, akkor egy sor kiskaput nyitunk a cég belső hálózata felé. Nincs más lehetőség, csak belenézni ezekbe a forgalmakba és elmagyarázni a munkatársaknak, miért is tesszük ez.
Höltzl Péter
Balabit IT Security
Szakértőnk korábbi cikkei
- Hálózatbiztonság: nincs tökéletes védelem!
- Mi történik a tűzfal mögött
- Hogyan működnek a tűzfalak?
