„Tunneling technikák” változatai közötti eltérés

A lap 2014. május 22., 12:15-kori változata

A hálózati tunnel egy olyan számítógépes hálózatok által használt technika, mely egy vagy több hálózati átvitel megvalósítására másik hálózati kapcsolatot vesz igénybe. Lehetővé teszi az egymással egyébként nem kompatibilis hálózatok közötti adatátvitelt, biztonságos kommunikációt biztosít egy nembiztonságos hálózaton keresztül. Továbbá megkerülhető a használatával egyes hálózatok rendszergazdai korlátozásai.

A VPN pont ezen felhasználást teszi lehetővé, hogy tunelek segítségével bebiztosított hálózatot teremtsen a számítógépek vagy számítógépes hálózatok között.

Tunnel (alagút) - végülis nevezhetnénk egymásbaágyázásnak is, hiszen ezt használja ki: egyes protokollokat a másik hálózat csomagjaiba csomagolja be. Például itt van a Microsoft PPTP technológiája, mely megengedi az Internet használatát az adatátvitelhez egy VPN hálózatban. Lényegében az Internet által nyújtott/kezelt?! TCP/IP csomagokba ágyazza be a saját hálózati protokolját.

Port redirect és port forward

Alagút kialakításához szügséges technológiák közé sorolandó a port-továbbítás és a port-átirányítás. Az előbbi lehetővé teszi egyes belső hálózati(LAN)cím elérését egy megadott porton keresztül külső címről(WAN). A portok kinyitásáért a tűzfal a felelős, minden porthoz megvan határozva melyek nyitottak es melyek nem. Ez leginkább akkor használatos, ha a belső hálózatunkon egy webszervert üzemeltetünk. Ha port-forwardolunk azaz pl. a 80-as portot kinyitjuk, a webszerver IP címét pedig a router odaadja a 80-as porton befelé igyekvő csomagoknak. Port forward esetén 3 fajtát különböztetünk meg: lokális, távoli es dinamikus. 3 féle lehet port továbbítást használhatunk ki: Lokális : a kapcsolat az ssh klienstől ssh szerver által van továbbítva, amit aztán a cél szerverhez fut be. Használhatjuk : E-mailek fogadására, SSH tunnelen keresztüli kapcsolódásra weboldalakhoz(például notebookról). Távoli : a kapcsolat az ssh szervertől ssh kliens által van továbbítva, amit aztán a cél szerverhez fut be. Használhatjuk: távoli munkamenetre. SSHn keresztül használhatjuk saját grafikus felületünk megosztására (5900-as porton). Dinamikus : a kapcsolódás több programtól SSH kliensen keresztül továbbítódik az ssh szerverhez és ezekután egy vagy több célszerverhez. Használhatjuk: elővigyázatosságból érdemes ezt használni, a hacker támádások szembeni védelemnél.

VPN tunneling

A virtuális magánhálózat tehnológiája épp az alagút alapgondolatát használja ki. Magába foglalja egy logikai hálózati kapcsolat létrehozását és karbantartását. Ezen kapcsolaton, olyan speciális, VPN protokol formátumú csomagok vannak más csomagokkal egymásba ágyazva, melyek ezután továbbításra kerülnek a VPN kliens és a szerver között, végül pedig kifejtésre kerül a fogadó oldalon. Internet-alapú VPN-nél a csomagok (VPN protokollt használva) beágyazódnak az Internet Protokoll csomagokba. A VPN továbbá támogat autentikációt és titkosítást egyaránt az alagút biztonságossága érdekében. Kétfajta mód van az alagút kiépítésére, az önkéntes és a kötelező. Néhány hálózati protokollt direkt a VPN alagút használatára lett létrehozva. Egyébként egymással incompatibilisek. Ezek közé tartozik a Point-to-Point Tunneling Protocol (PPTP), melyet Windows beépített kliensel rendelkezik mely teljeskörűen támogatja a VPN protokollt. Másik ilyen a Layer Two Tunneling Protocol (L2TP), mely elsősorban Cisco termékekben található, az OSI modell 2.(adatkapcsolati) rétegében található, innen a neve is. Az Internet Protocol Security (IPsec) a 3. hálózati rétegben implementálható, teljes VPN protokoll megvalósításként is vagy mint kódolási sémaként használható az előző 2 protokoll valamelyikével. Az SSTP SSL 3.0 alapú VPN (TCP 443-as port), PPTP vagy L2TP adatforgalom küldésére alkalmas. Adatávitel melletta titkosítást is támogatja és ezen felül az adatintegritást is.

SSH tunneling

Tunnelling technikák egyik legelterjedtebbike az ssh tunnelezés.

Az SSH tunnel egy titkosított csatornából áll, mely SSH protokollt használ a kapcsolódásra. Az SHH alagút felhasználható arra, hogy egy nem titkosított adatfolyamot tudjunk küldeni a hálózatban egy titkosított csatornán keresztül. Példának okáért biztonságos fájlátvitelre használatos az FTP szerver és a kliens között, annak ellenére hogy maga az FTP protokoll nincs titkosítva.

Két csomópont közt kell kapcsolatot biztosítani, amelyből az egyik a lokális másik pedig a távoli gép.

-L <local-port-to-listen>:<remote-host>:<remote-port>

és

-R <local-port-to-listen>:<remote-host>:<remote-port>

Az egyik közülük megnyitja TCP portot (a port1-et). Az -L kapcsolóval ellátott parancs lokális port továbbítást míg -R pedig a távoli port továbbítást szemlélteti.

Ha érkezik erre a megnyitott portra kapcsolódás a másik féltől, az SSH a saját bebiztosított(kódolt) csatornájához tereli az adatforgalmat, továbbá kapcsolódik a másik fél port2 porján keresztül a host2-re. Felmerül a kérdés, igazából mire használható ez fel?! A leggyakoribb esetekre fókuszálva, például egy munkahelyi gépre való csatlakozásra otthonról. Feltételezvén, hogy a munkahelyi számítógépre van egy ssh hozzáférésünk és egy továbbin pedig egy mail szerverünk pop3 protokollon keresztül. Az email-jeinkhez való hozzáféréshez elég volna egyszerűen csak ez utóbbi mail szerverhez kapcsolódni, ámde ha így tennénk a jelszavunk kódolatlanul pásztázna végig az interneten, másrészt meg nem is biztos, hogy kívülről egyáltalán elérhető lenne. A megoldást nyújthatja erre az SSH, hisz így a jelszavunk ssh csatornán keresztül fut be a célba és a kapcsolat előálltja után tölthetjük le az üzeneteinket a pop3 szerverről. user@Pc1:~$ ssh -L pop3:Pc3:pop3 Pc2 Másik eset lehet ha mondjuk a rendszergazda letiltja a hozzáférésünket bizonyos weboldalakhoz egy proxy filterrel. Ha a felhasznalók nem szeretnék, hogy tiltva legyenek illetve nem szeretnék hogy monitorozva legyen a web forgalmuk, van viszont lehetőségük ssh szerverhez kapcsolódni, akkor könnyen létrehozhatnak maguknak egy ssh tunnelt, mellyel továbbítani tudják a lokális gép adott portját a a tavoli webszerver 80-as portjára a külső ssh szerver segítségével. Ha rendelkezünk ssh hozzáféréssel egy külső géphez és egy harmadik gépen egy proxy szerver szolgál ki kéréseket a 3128-as porton, akkor korlátozások nélkül böngészhetjük a webet. Az ehhez tartozó beállítás: user@Pc1:~$ ssh -L 3128:Pc3:3128 Pc2 és a böngészőben a proxy beállításokat localhost:3128-ra kapcsolni. Egy harmadik példával élve, nagy érdeklődés van az XWindows kapcsolat tunnelezésére. Persze, ahhoz hogy 3. fél elől elrejtsük, használhatjuk itt is az shh biztosítást egy egyszerű -X kapcsoló hozzáadásával: user@Pc1:~$ ssh -X Pc2 .

Az átirányítást megoldhatjuk iptáblákkal is.

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to 192.168.1.5:80

Ezzel a parancsal átirányítjuk a 80-as portot a lokális gépről a 192.168.1.5 -re. Ez akkor lehet hasznos, ha mondjuk csak egy publikus címünk van és azt szeretnénk, hogy a WWW szerver(ami kívülről érhető el) ne fusson a tűzfalon. Tehát a 192.168.1.5-ön futtatjuk a demilitarizált zónában(tehát abban ami tartalmazza a belső hálózatot), a tűzfalon pedig alkalmazzuk az átirányítást. Persze nem csak lokális gép esetén használható ez, hanem olyan esetekben is ha mondjuk egy hibaüzenetet kell megjelenítetnünk amíg a célszerver leállt. Ez esetben szeretnénk a forgalmat egy másik gépre irányítani, a parancsban meg kell adni a hibába ütköző gép ip-címét is.

SSL tunneling

Az SSL titkosítás sok előnyt élvez, amelyek kihasználására elég egy tanúsítványt generálni. A tanúsítvány erősségi szintjét mi magunk adjuk meg az OpenSSL verzió kiválasztásával és a szerveren való titkosítási könyvtárak meghatározásával. Bizonyára sokunk találkozott már tanúsítvány elfogadásáról szóló felszólítással a web böngészése közben. Az ilyen tanúsítványok közé tartozik az SSL tanúsítványa is. Az SSL tanúsítványt csak domain névvel rendelkező szervert üzemeltető természetes vagy jogi személy igényelheti, web szerverekkel történő biztonságos kommunikáció kialakítására használható (A, B, C osztály). Így a rendszergazda határozza meg egy-egy tanúsítvány lejártát is. A kommunikáció kezdeményezése a szerver által küldött igazolással vagy tanúsítvánnyal történik, amit a kliensnek címez. A kliens ezekután kiértékeli a tanúsítványt és ez alapján dönti el, hogy fogadja-e vagy sem a kapcsolatot. A titkosítás létrehozásának feltétele a kulcs váltás. Ha ez megtörtént a felek között, akkor a kliens és a szerver megegyezik abban, hogyan fogja a kommunikációt lebonyolítani s ezzel létrehozván a titkosított csatornát. Két része van a tanúsítványnak, a kulcs és a tanúsítvány maga. A kulcsot értelemszerűen nem szabad kívülről elérhetővé tenni. Az SSL technika biztosítja mind az adatforrás autentikációját, mind pedig az adat diszkrétségét. A biztonsági feltételek mindkét fél(kliens és szerver) által meghatározható. Fontos megjegyezni, hogy maga az SSL tunnel csak proxy konfigurációkra épül. Ahogy a KEEP látni az SSL alagút létrehozására a következő lépések fontosak:

SSL alagút létrehozása

1. A kliens létrehozza a tunnelling kérését: CONNECT server-host-name:port HTTP/1.1. A port száma itt opcionális, általában a 443-as szokott lenni. Ezután a kliens böngészője elküldi a kérést a proxy szerver összes HTTPS kérésnek, hogy megtudja be-e van konfigurálva a böngészőben. 2. A proxy fogadja a csatlakozást a 80-as porton, megkapja a kérést és kapcsolódik a célszerverhez azok a porton, amelyet a kliens megadott a CONNECT kérésében. 3. A proxy válaszol a kliensnek, hogy a kapcsolatot létrehozta. 4. A proxy közvetíti az SSL tárgyalás(a biztonsági feltételekről) mindkét irányban. 5. Azután, hogy megegyeztek, a proxy küldi és fogadja a titkosított adatot a kliensnek vagy a szervernek. 6. Ha a kliens vagy a célszerver kéri a kapcsolat bontását valamelyik használt porton, a proxy ezt követően bontja a kapcsolatot(minden porton).

HTTP tunneling

A HTTP tunneling olyan technika, amely a kommunikációt különböző hálózati protokollok HTTP protokollba való beágyazásával oldja meg. Ezen hálózati protokollok a TCP/IP protokoll családba tartoznak. A HTTP protokoll itt amolyan külső burkolatként szolgál a csatornához amelyet a tunnelezéshez használunk fel. Maga a HTTP adatfolyamot a csatornával eggyütt nevezzük HTTP tunnel-nek. A webszerverek rohamos terjedése hozza magával azt a támadási célpontot, amit ügyesen ki is használnak a támadók. Persze, mint a legtöbb esetben mindig egy tűzfal vagy proxy szerver mögé kerülnek. Védekezési szempontból a vállalatok további eszközöket vetnek be, melyeket a legtöbb esetben a webszerver és a külső hálózat(internet) közé ékelnek be, illetve egyenesen magára a webszerverre is. A HTTP tunnelling technikája itt kezdődik. Hisz az előzőleg említett rendszereknek vannak korlátozásai, amit egy alagúttal meg tudjuk kerülni. A HTTP tunnelling működése: a kliens egy HTTP fejlécbe ágyazza bele a forgalmat. A forgalom így továbbításra kerül a szerverhez, amely a csomagok beérkezése után kibontja az egységbe zárt fejlécet és átirányítja a csomagokat a végső célhoz.

DNS tunneling

Ismerős szituáció lehet, hogy blokkolva vagyunk a proxy által, ezért nem tudunk hozzáférni a weboldalakhoz. Ekkor van szükség arra, hogy DNS tunneling segítségével megkerüljük a proxy szervert. A DNS tunelen az adatok beágyazódnak a DNS lekérdezésekbe és válaszokba base32 bas64 kódolással. A DNS domén névfeloldása pedig kétirányú adattovábbításra van felhasználva. Igazából amíg a hálózaton lehetséges domén névfeloldást csinalni, addig bármilyen adatot tudunk alagúton keresztül továbbítani a távoli rendszerre.

ICMP tunneling

Kliens és proxy közt hoz létre titkosított kapcsolatot, ICMP echo kérések és a válaszul érkezett csomagok segítségével. Leginkább az ellenőrizhető vele, hogy adott távoli számítógép elérhető-e a hálózatban (amely TCP/IP protokoll családját használja). Maga a műküdése azon alapszik, hogy beékelünk valamilyen tetszőleges adatot az echo csomagjába és úgy küldjük a távoli számítógépnek. A túloldalt várakozó távoli gép ugyanilyen módszert alkalmazva válaszol, azaz szintén beékeli a válaszát egy (másik) ICMP csomagba és visszaküldi azt. Az ICMP tunnelling technika szintén kihasználható a tűzfal korlátozásainak megkerülésére némi adatfolyam nagyságának ködösítésével. Kivédeni a nemkívánt csomagokat csak a teljes ICMP forgalom letiltásával lehet, esetleg meghatározni mekkora méretű csomagokat engedjen át a tűzfal.

IPv6 to IPv4 tunneling

Érdekes lehet az IPv6 protokol IPv4-be való beágyazódása, tehát itt is az IPv6-os csomagjait az IPv4-es csomagokba pakoljuk bele. Lehetővé válik, így 2 IPv6-os protokollt használó hálózat közti kapcsolat még akkor is, ha egyébként nincs a két hálózat között IPv6-os összeköttetés. A becsomagolás rögtön a belépési pontnál hajtódik végre. Belépési csomóponton rendszerint valamilyen routert vagy hosztot értünk, itt ellenőrizni kell a tunnel információkat. Az IPv6 beagyazása IPv6ban fejléc--- KEEEEEEEP---- A köztes csomópontok avagy routerek IPv4 végpontokkal rendelkeznek, ezek alkotják magát az alagutat. A becsomagolt IPv6 "átutazik" ezeken a pontokon mindenféle vámkötelezettség nélkül, azaz nincs ellenőrizve hogy az IPv4 a csomagtartójában egy IPv6-os csomagot szállít-e. Persze ezt az alagútból kifelé jövet egy (dual-stack) csomópont már felismeri, leválasztja az IPv4-et és már csak az IPv6-os cím alapján küldi tovább egy szintén IPv6-os címmel rendelkező célállomáshoz. Az említett módszer kétféleképpen is kivitelezhető. Elsőként vegyük az automatikus alagutat, amely csak router-hoszt vagy hoszt-hoszt csomópontok esetén használatos. Ez esetben egy IPv6-os csomópont tud kommunikálni egy IPv4 kompatibilis IPv6-os címmel rendelkező interfésszel. A kompatibilis cím csak 32-biten működik (128 heleyett), ennek az az oka, hogy az IPv6-os csomagok IPv4-es csomagban utaznak a hálózatban. Az összes többi IPv6-os protokoll előnye kihasználható. Második módszer a konfigurált alagút. Ennek segítségével IPv6-os hálózatokat tudunk összekötni Ipv4-es alagúton keresztül, kompatibilis címek felhasználása nélkül. Konfigurálást az adminisztrátor végzi az alagút végpontjain, pontosabban az IPv6-IPv4 leképezését adja meg más forgalomirányításhoz szükséges információk mellett. A fogadó végpontján meg kell adni manuálisan a használható IPv4 becsomagoló címeket. Ezen alagúton kívül természetesen használhatóak az Ipv6-os 128 bites címek.