„Tunneling technikák” változatai közötti eltérés
| (egy szerkesztő 5 közbeeső változata nincs mutatva) | |||
| 8. sor: | 8. sor: | ||
'''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 | '''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 | + | 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 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. | + | 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. | 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 | + | Port-továbbítás 3 fajtáját különböztetjük meg: lokális, távoli es dinamikus. |
3 féle lehet port továbbítást használhatunk ki: | 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. | + | * '''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). | 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. | + | * '''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. | + | Használhatjuk: távoli munkamenetre. SSH-n 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. | + | * '''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. | Használhatjuk: elővigyázatosságból érdemes ezt használni, a hacker támádások szembeni védelemnél. | ||
| 27. sor: | 27. sor: | ||
==VPN tunneling== | ==VPN tunneling== | ||
| − | A virtuális magánhálózat | + | A '''virtuális magánhálózat''' technoló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 protokoll 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. |
| − | VPN | + | Internet-alapú VPN-nél a csomagok (VPN protokollt használva) beágyazódnak az Internet Protokoll csomagokba. |
| − | oldalon. | + | A VPN támogat autentikációt és titkosítást egyaránt az alagút biztonságossága érdekében. |
| − | Internet-alapú VPN-nél a csomagok (VPN protokollt használva) beágyazódnak az Internet Protokoll csomagokba. A VPN | + | Kétfajta mód van az alagút kiépítésére, az '''önkéntes''' és a '''kötelező'''. |
| − | biztonságossága érdekében. | + | Néhány hálózati protokollt direkt a VPN alagút használatára lett létrehozva, amelyek egyébként egymással inkompatibilisek. |
| − | Kétfajta mód van az alagút kiépítésére, az önkéntes és a kötelező. | + | Ezek közé tartozik a '''Point-to-Point Tunneling Protocol''' (PPTP), melyet a Windowsba beépített klienssel a Microsoft teljeskörűen támogat. |
| − | Néhány hálózati protokollt direkt a VPN alagút használatára lett létrehozva | + | 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 ered a neve is. |
| − | Ezek közé tartozik a Point-to-Point Tunneling Protocol (PPTP), melyet | + | 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. |
| − | 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 '''Secure Socket Tunneling Protocol''' (SSTP) SSL 3.0 alapú VPN-t (TCP 443-as port) használ és PPTP vagy L2TP adatforgalom küldésére alkalmas. |
| − | 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ő | + | Adatávitel mellett a titkosítást is támogatja és ezen felül az adatintegritást is. |
| − | 2 protokoll valamelyikével. | + | |
| − | Az SSTP SSL 3.0 alapú VPN (TCP 443-as port) | + | |
| − | Adatávitel | + | |
| 52. sor: | 49. sor: | ||
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. | 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> | + | ''-L <local-port-to-listen>:<remote-host>:<remote-port>'' |
és | és | ||
| − | -R <local-port-to-listen>:<remote-host>:<remote-port> | + | ''-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. | 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. | ||
| + | Itt 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, email-jeink hozzáféréséhez. 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 azt, 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 távoli webszerver 80-as portjára a külső ssh szerver segítségével. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | 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 | + | |
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. | 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: | Az ehhez tartozó beállítás: | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | ''user@Pc1:~$ ssh -L 3128:Pc3:3128 Pc2'' | |
| − | + | és nefeledjük 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 egy harmadik fél elől elrejtsük ezt, használhatjuk itt is az shh biztosítást egy egyszerű -X kapcsoló hozzáadásával: | ||
| − | 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 | + | ''user@Pc1:~$ ssh -X Pc2'' . |
| − | a WWW szerver(ami kívülről | + | |
| − | a tűzfalon pedig alkalmazzuk az átirányítást. | + | Magát az átirányítást megoldhatjuk iptáblákkal is. Lássuk: |
| − | 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 | + | |
| − | 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. | + | ''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 is elérhető) ne fusson a tűzfalon. Tehát a ''192.168.1.5''-ön futtatjuk a demilitarizált zónában(tehát abban ami tartalmazz egy 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 nem elérhető. Ez esetben szeretnénk a forgalmat egy másik gépre irányítani,ezesetben a parancsban meg kell adni a hibába ütköző gép ip-címét is. | ||
== SSL tunneling == | == 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 | + | 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. |
| − | é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. | 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 | + | Az ''SSL tanúsítványt'' csak domain névvel rendelkező szervert üzemeltető természetes vagy jogi személy igényelheti. Webszerverekkel 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. |
| − | használható (A, B, C osztály). Így a rendszergazda határozza meg egy-egy tanúsítvány lejártát is. | + | 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. |
| − | 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 | + | 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 egy 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, ezzel létrehozván a titkosított csatornát. |
| − | dönti el, hogy fogadja-e vagy sem a kapcsolatot. A titkosítás létrehozásának feltétele | + | |
| − | hogyan fogja a kommunikációt lebonyolítani | + | 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ó. [[Fájl:SSL_tunneling.gif|thumb|400px|SSL alagút létrehozása]] |
| − | + | ||
| − | 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. | Fontos megjegyezni, hogy maga az SSL tunnel csak proxy konfigurációkra épül. | ||
| − | Ahogy a | + | Ahogy a képen is észrevehető az SSL alagút létrehozására a következő lépések fontosak: |
| − | 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. | + | * 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. | + | * 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. |
| − | 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. | + | * 3. A proxy válaszol a kliensnek, hogy a kapcsolatot létrehozta. |
| − | 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). | + | |
| + | * 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 == | == HTTP tunneling == | ||
| + | [[Fájl:HTTPtunnelSetup.jpg|thumb|350px|HTTP alagút]] | ||
| − | 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 ''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 | + | 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 is bevetnek, 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 | + | 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 tudunk |
| − | kerülni. | + | 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. |
| − | 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 == | == 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 | + | 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. |
| − | szervert. | + | A DNS tunnelen 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. |
| − | A DNS | + | Igazából amíg a hálózaton lehetséges domén névfeloldást csinálni, addig bármilyen adatot tudunk alagúton keresztül továbbítani a távoli rendszerre. |
| − | Igazából amíg a hálózaton lehetséges domén névfeloldást | + | |
== ICMP tunneling == | == 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 | + | 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). |
| − | 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. |
| − | 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 | + | Az ICMP tunnelling technika szintén kihasználható a tűzfal korlátozásainak megkerülésére némi ködösítéssel az adatfolyam nagyságáról. |
| − | 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 | + | |
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. | 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 == | == IPv6 to IPv4 tunneling == | ||
| + | [[Fájl:IPV6EncapsulateIPV4.jpg|thumb|281px|IPv6 fejléc beágyazása IPv4-be]] | ||
| + | [[Fájl:IPv6toIPv4.jpg|thumb|500px|IPv4 alagút IPv6-os csomagok átvitelére]] | ||
| + | Érdekes lehet az '''IPv6 protokoll 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 beállításokat). | ||
| + | Az IPv6 fejléce beágyazódik az IPv4 fejlécébe(lásd. kép). | ||
| − | + | 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ó. | |
| − | 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 | + | 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. |
| − | 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. | 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. | ||
| + | |||
| + | |||
| + | == Források == | ||
| + | * Tunnelling protokoll - ([http://www.pcmag.com/encyclopedia/term/53236/tunneling-protocol honlap]) | ||
| + | * IPv6/Ipv4 ([http://ipv6.niif.hu/tipster6/papers/overview/4.transitipv6.html honlap]) | ||
| + | * Packet tunneling ([http://www.ietf.org/rfc/rfc2473.txt honlap]) | ||
| + | * Port forwarding ([http://www.pcmag.com/encyclopedia/term/49509/port-forwarding honlap]) | ||
| + | * SSL tunneling ([http://pic.dhe.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=%2Fcom.ibm.websphere.edge.doc%2Fedge%2Fcp%2Fadmingd119.htm honlap]) | ||
| + | * VPN tunneling ([http://compnetworking.about.com/od/vpn/a/vpn_tunneling.htm honlap]) | ||
| + | * SSH tunneling ([https://help.ubuntu.com/community/SSH/OpenSSH/PortForwarding honlap]) | ||
A lap jelenlegi, 2014. május 22., 16:02-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 TCP/IP csomagokba ágyazza be a saját hálózati protokolját.
Tartalomjegyzék |
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-továbbítás 3 fajtáját különböztetjük 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. SSH-n 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 technoló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 protokoll 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 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, amelyek egyébként egymással inkompatibilisek. Ezek közé tartozik a Point-to-Point Tunneling Protocol (PPTP), melyet a Windowsba beépített klienssel a Microsoft teljeskörűen támogat. 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 ered 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 Secure Socket Tunneling Protocol (SSTP) SSL 3.0 alapú VPN-t (TCP 443-as port) használ és PPTP vagy L2TP adatforgalom küldésére alkalmas. Adatávitel mellett a 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. Itt 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, email-jeink hozzáféréséhez. 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 azt, 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 távoli 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 nefeledjük 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 egy harmadik fél elől elrejtsük ezt, használhatjuk itt is az shh biztosítást egy egyszerű -X kapcsoló hozzáadásával:
user@Pc1:~$ ssh -X Pc2 .
Magát az átirányítást megoldhatjuk iptáblákkal is. Lássuk:
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 is elérhető) ne fusson a tűzfalon. Tehát a 192.168.1.5-ön futtatjuk a demilitarizált zónában(tehát abban ami tartalmazz egy 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 nem elérhető. Ez esetben szeretnénk a forgalmat egy másik gépre irányítani,ezesetben 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. Webszerverekkel 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. 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. 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 egy 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, ezzel létrehozván a titkosított csatornát.
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 képen is észrevehető az SSL alagút létrehozására a következő lépések fontosak:
- 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 is bevetnek, 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 tudunk 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 tunnelen 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 csinálni, 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 ködösítéssel az adatfolyam nagyságáról. 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 protokoll 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 beállításokat). Az IPv6 fejléce beágyazódik az IPv4 fejlécébe(lásd. kép).
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.
