Menü
Ingyenes
bejegyzés
itthon  /  Navigátorok/ Feltörhető egy VPN szolgáltatás? Részletes áttekintés. Hogyan működik a VPN titkosítás

Feltörhető egy VPN? Részletes áttekintés. Hogyan működik a VPN titkosítás

Egy áttekintő cikk a modern magánalagutak használatáról egy népszerű lett márka útválasztókban. Beszélni fogok arról, hogyan állíthatok be vpn-szervert a mikrotikban olyan technológiák alapján, mint az l2tp, ipsec, openvpn, pptp, gre és eoip. Útközben röviden beszélek arról, hogy mik ezek a technológiák, miben különböznek egymástól, valamint összehasonlítom a mikrotika teljesítményét az összes megadott alagúttal.

Ez a cikk egyetlen cikksorozat része, amely erről szól.

Bevezetés

Azonnal szeretném felhívni a figyelmet arra, hogy ez a cikk inkább áttekintés, semmint valódi tapasztalat átadása, mivel én magam is leggyakrabban vpn szerver... Ennek ellenére a Mikrotikban is vpn-vel kellett foglalkoznunk. A csatlakozáshoz pptp szerverként konfigurálva távoli kliensekés l2tp két vagy több mikrotikus közös magánhálózatba való kombinálásához. Leginkább alapértelmezés szerint, anélkül, hogy belemerülnénk a beállítások bonyolultságába.

Azok számára, akik szeretnének járatosak lenni a hálózatokban, de valamiért még nem tudják, hogyan kell ezt megtenni, azoknak ajánlom ezt a cikksorozatot - hálózatok a kicsiknek.

VPN-kiszolgáló opciók a Mikrotikban

A Mikrotikban lévő vpn szerver opciókkal minden bonyolult :) Abban az értelemben, hogy sok vpn implementáció létezik, amiket nem olyan könnyű kiválasztani, ha nem érted részletesen hálózati technológiák... Nem sokat tudok róluk, de azt hiszem, egy kicsit ráérek a lényegre. Megpróbálom a saját szavaimmal elmagyarázni, hogy mik a különbségek.

Két alapvetően eltérő megoldás létezik a két mikrotika és a külső előfizető közötti kapcsolatok megszervezésére:

  1. L2 helyek közötti alagút létrehozása a EOIP alagút... A legegyszerűbb és gyors út kombináljunk két mikrotikumot. Ha nem használ titkosítást, akkor a leggyorsabb VPN-kapcsolatok jönnek létre. Dedikált fehér IP-cím szükséges mindkét eszközön. Az ilyen kapcsolatokat az irodák vagy fióktelepek VPN-en keresztüli összekapcsolására használják. Általában NAT-on keresztül nem működik. ide is hozzáteszem GRE alagút bár működik az l3-ban, és útválasztást használ, ugyanazt a webhelyet működik.
  2. Az l3 szintű VPN kapcsolatok a Client-Server technológián, mint pl PPTP, L2TP, SSTP, OpenVPN... Az ilyen kapcsolatokat az irodák összevonására és a távoli alkalmazottak összekapcsolására is használják. Csak egy fehér IP-cím a szerver oldalon elegendő a vpn kapcsolatok létrehozásához. NAT-on keresztül működik.

A vpn-kapcsolatok mindegyik típusáról külön mesélek egy kicsit.

  • GRE Tunnel – Az egyszerű gre protokollt használja egy alapvető, nem biztonságos helyek közötti VPN felépítéséhez. A CISCO fejlesztette. Lehetővé teszi a csomagok kapszulázását különféle típusú ip alagutak belsejében. Egyszerű szavakkal ezt csinálja. Elveszi az adataidat az összes fejléccel együtt, csomagba csomagolja, az interneten keresztül továbbítja a másik végére, ahol ezt a csomagot visszaelemzi az eredeti adatokká. A hálózat végfelhasználói számára mindez úgy tűnik, mintha egy helyi hálózaton keresztül kommunikálnának.
  • EOIP Tunnel – Ethernet over IP egy szabadalmaztatott MikroTik RouterOS protokoll, amely Ethernet alagutat hoz létre két router között IP-kapcsolaton keresztül. Az adatátvitelhez a GRE protokollt használja. Az eoip tunnel közötti alapvető különbség az, hogy l2-ben működik és közvetlenül továbbítja a kereteket, míg a gre tunnel csomagokon működik és routingot használ. Remélem jól magyaráztam és nem hazudtam. Nem tudom, hogy a mikrotik miért döntött úgy, hogy saját alagút implementációt hoz létre a gre protokollon keresztül. Talán egyszerűen nincsenek hasonló megoldások, ezért kitalálták a saját megvalósításukat.
  • A PPTP a Point-to-Point Tunneling Protocol rövidítése. Munkához a GRE protokollt használja, támogatja a titkosítást. A pptp valamikor nagy népszerűségre tett szert, mivel a 95-ös verziótól kezdve a Windows már eleve támogatta. Ma már nem ajánlott a pptp használata, mivel nagyon könnyen feltörhető. A titkosítási kulcsot rövid időn belül (több óra) lekérjük a forgalmi dump-ból, és az összes forgalmat visszafejtjük. Talán ezt valahogy meg lehet oldani különböző titkosítási protokollok használatával, de ezt a témát nem értettem részletesen. Saját magam számára úgy döntöttem, hogy a pptp a legegyszerűbb megoldás, ahol nincsenek fokozott biztonsági követelmények, és a forgalom visszafejtése, ha ez megtörténik, nem okoz gondot. A PPTP nem csak a Windowst támogatja, hanem az Androidot is, ami nagyon kényelmes. Nagyon könnyű beállítani.
  • L2TP – Layer 2 Tunneling Protocol. Annak ellenére, hogy a név l2-t jelez, a valóságban az ip hálózaton működik munkamenet szinten, azaz l3. Az udp 1701-es portot használja. Nem csak IP hálózatokban tud működni. A pptp-hez hasonlóan támogatja a felhasználói hitelesítést. Önmagában nem biztosít titkosítást. Az ipsec segítségével titkosítja a forgalmat, ami nagyon biztonságosnak számít, és nincs benne komoly sebezhetőség. Jelenleg szinte minden eszköz és rendszer támogatja, akárcsak a pptp. A beállítás nem sokkal bonyolultabb. Általában javaslom az ilyen típusú titkosított alagút használatát a vpn szervezéséhez.
  • Az OpenVPN a titkosított kapcsolatok nagyon népszerű megvalósítása. A fő előny a beállítások rugalmassága. Például az openvnp egyik nagyon klassz funkciója, hogy az útvonalakat közvetlenül a klienshez küldi csatlakozáskor. Régóta használok openvpn szervereket. Amikor először át kellett adnom egy útvonalat a pptp kliensnek, nem tudtam rájönni, hogyan állítsam be. Kiderült, hogy bármilyen módon, egyszerűen nem tudja, hogyan. Harmadik féltől származó eszközöket kellett használnom. Sajnos a mikrotikban ismeretlen okból az openvpn nem támogatja az udp protokollt, ami nagymértékben korlátozza a vpn szerver használatának lehetőségeit. Tcp-n sokkal lassabban működik, mint udp-n. A csomagfejlécek tömörítése sem működik. Tehát általános esetben nincs értelme openvpn szervert használni a Mikrotikban, hacsak nincs rá valami konkrét ok.
  • Az SSTP - Secure Socket Tunneling Protocol - protokollt a Microsoft vezette be ben Windows Vista SP1. Fő előnye, hogy integrálva van a Windowsba, tudja használni a 443-as portot, ami néha segít a tűzfalak megkerülésében. Nagyon biztonságosnak tekinthető, SSL 3.0-t használ. A mínuszok közül, amennyire én tudom, a Mikrotikban nagyon igényes a processzorerőforrásokra. Gyenge hardverdarabokon a legalacsonyabb sebességet adja az összes többi vpn-kapcsolathoz képest. Emiatt a felülvizsgálatomban egyáltalán nem veszem figyelembe.

A leírtakból a következő következtetést vonhatjuk le. Általában a legjobb az l2tp + ipsec alapú vpn használata a mikrotikában. Fő ok:

  1. Egyszerűség és könnyű testreszabhatóság.
  2. Erős titkosítás.
  3. Szinte minden modern eszköz és rendszer támogatja az l2tp kapcsolatokat. Nincs szükség további szoftver telepítésére.
  4. Alkalmas mind az irodák, mind a távoli alkalmazottak egyesítésére – telephely-telephely és ügyfél-telephely kapcsolat.

Ha maximális teljesítményre van szüksége titkosítás nélkül, akkor építsen kapcsolatokat a hálózatok vagy irodák között az EOIP Tunnel segítségével – a Mikrotik szabadalmaztatott fejlesztésével.

Kezdjük a vpn kapcsolatok konfigurálását és tesztelését a mikrotikban.

L2tp alagút konfigurálása a mikrotikban

Először is állítsunk fel egy egyszerű l2tp alagutat titkosítás nélkül, és mérjük meg a sebességet. Az l2tp vpn konfigurálásához a mikrotikban kövesse az alábbi lépéseket.

Megyünk a szakaszhoz IP -> Poolés adjunk hozzá egy IP-címkészletet a vpn-alagúthoz.

Hozzon létre egy profilt az alagúthoz PPP -> Profilok.

A többi lap alapértelmezett beállításokkal rendelkezik. Ezután létrehozunk egy felhasználót PPP -> Titkok.

Most elindítjuk az l2tp szervert. Menj PPPés nyomja meg a gombot L2TP szerver.

Beállítjuk az l2tp szerver beállításait. még ne engedélyezze az ipsec-et.

A VPN-kiszolgáló konfigurálva van. Most készítsünk neki egy állandó felületet, hogy ez alapján statikus útvonalakat hozzunk létre. Menj Interfészekés létrehozni.

Befejező simítás. Statikus útvonalat hozunk létre, amellyel az előfizetők helyi hálózat a szerverek VPN-en keresztül képesek lesznek csatlakozni egy távoli útválasztó mögött lévő helyi hálózati előfizetőhöz. Menj IP -> Útvonalakés adjunk hozzá egy útvonalat.

Statikus útvonalat adunk hozzá, hogy ennek az útválasztónak az ügyfelei tudják, hol léphetnek kapcsolatba a távoli helyi hálózat vpn-előfizetőivel.

Ez minden. Az l2tp-t egy távoli mikrotikon konfiguráltuk, és így 2 helyi hálózatot csatlakoztattunk vpn segítségével. A szerveren és a kliensen aktív l2tp kapcsolattal rendelkező IP-címek listájában látnia kell az IP-címeket a kiszolgálón a vpn hálózathoz beállított tartományból - 10.10.5.1-10.10.5.100. Mostantól mindkét hálózatról pingelhet ellentétes hálózatokat.

Van laptopom mindkét mikrotikához csatlakoztatva a teszthez. Most megmérem a kapcsolat sebességét az iperf3 segítségével. A router mögött m-távirányító laptopon 10.30.1.254 elindítom a szervert, 10.20.1.3-on pedig az ügynököt. Elkezdjük a vpn kapcsolat sebességének tesztelését:

átlagsebesség 194 Mbps... Őszintén szólva nem értettem, miért ilyen alacsony sebesség. A tesztpadom két mikrotikus routerre és közöttük egy gigabites mikroswitchre van felszerelve. Várhatóan valami 500 Mbps körüli sebességet fog látni. Hadd emlékeztesselek arra, hogy az alagút még nincs titkosítva. Ugyanakkor a processzorok terhelése az útválasztókon 90-95% körül mozgott. Ez tulajdonképpen ezeknek a vasdaraboknak a mennyezete.

Most próbáljuk meg engedélyezni az ipsec titkosítást, és mérjük vele a sebességet.

Az ipsec konfigurálása

Az ipsec beállításánál l2tp-hez egy időre elakadtam. Sok utasítás található a neten, de mindegyik elavult. Mint kiderült, a legújabb firmware-verziókban az ipsec indítása alapértelmezett beállításokban nem egyszerű, de nagyon egyszerű. Ehhez csak meg kell adnia az l2tp szerver tulajdonságait Használja az IPsec-et- igen, és állítson be jelszót.

Minden szükséges beállításokat Az ipsec automatikusan létrejön. Az ügynökön tegye ugyanezt - engedélyezze az ipsec titkosítást, és adjon meg egy jelszót.

Az l2tp kliens csatlakoztatása után hasonló sorokat fog látni a naplóban:

19:17:00 l2tp, ppp, info l2tp-out1: inicializálás ... 19:17:00 l2tp, ppp, info l2tp-out1: csatlakozás ... 19:17:03 ipsec, info 1. új fázis kezdeményezése (Identity Védelem): 192.168.13.197<=>192.168.13.1 19:17:04 ipsec, info Az ISAKMP-SA létrehozva: 192.168.13.197-192.168.13.1 spi: 407844c0ceb5d2ab: 46ce7ffb25d2ab: 46ce7ffb25d2ab: 46ce7ffb254951272727272727:pp19:pp1 , info l2tp-out1: csatlakoztatva

Annak érdekében, hogy megbizonyosodjon arról, hogy az ipsec titkosítás működik, lépjen a szakaszba IP -> Ipsec -> Telepített SA-kés nézd meg a titkosított csomagok számlálóját. Ha nő, akkor minden rendben van, a forgalom titkosított.

Ugyanott a részben Távoli társak megtekintheti azon távoli kliensek listáját, amelyeknél működik az ipsec titkosítás, megtekintheti a használt algoritmusokat. Az összes alapértelmezett ipsec-beállítás megtalálható ebben a részben. Megtekintheti őket, módosíthatja vagy új profilokat adhat hozzá. Alapértelmezés szerint az sha1 engedélyezési algoritmus és az AES titkosítás használatos. Ezeket a paramétereket módosíthatja, ha ismeri a témát. Nem leszek okos, nem én ástam a titkosítás témáját. Hogy melyik algoritmus a leggyorsabb és legbiztonságosabb – nem tudom.

Teszteljük a vpn kapcsolat sebességét l2tp + ipsec.

én így kaptam... 26 Mbpsátlagos. Ebben az esetben a processzor terhelése 100%. Nem sok. Ezek a vasdarabok nagyon rosszul alkalmasak titkosított csatornákra. Ezekben a tesztekben magán a teszten kívül semmi mást nem töltenek be. Valós körülmények között a sebesség még alacsonyabb lesz.

Elkészültünk a vpn beállításokkal az l2tp + ipsec alapján. Folytassuk a többi vpn alagutak konfigurálását, és hasonlítsuk össze a sebességüket.

A pptp szerver beállítása a mikrotikban

A pptp szerver beállítása alapvetően nem különbözik az l2tp-től. A műveletek logikája és sorrendje ugyanaz. Először létrehozunk egy címkészletet IP -> Pool vpn hálózathoz. Ugyanazt a készletet fogom használni, amelyet korábban létrehoztunk.

Ez a profil tartalmazza azokat az alapértelmezett titkosítási beállításokat, amelyeknél le van tiltva. Először nézzük meg a vpn csatorna sebességét nélkülük. Hozzon létre egy új felhasználót a távoli pptp kapcsolathoz.

Kapcsolja be a pptp szervert a PPP részben.

Most hozzuk létre az Interfész listában PPTP szerver kötés az előző részhez hasonlóan.

És végül adjon hozzá egy statikus útvonalat a távoli hálózathoz ezen keresztül pptp kapcsolat.

A pptp szerver beállítása ezzel befejeződött. A tűzfalon a következő dolgokat kell megnyitnia a külső interfész bejövő kapcsolataihoz:

  • TCP 1723-as port
  • GRE protokoll

A pptp kliens konfigurálására megyünk.

pptp kliens

Egy távoli útválasztóhoz lépünk, és ott a pptp kliensen keresztül létrehozunk egy kapcsolatot. Szokás szerint megyünk a szakaszra PPPés add hozzá PPTP kliens... Az Általános fülön nem érintünk semmit, de a Dial Out-on feltüntetjük a pptp szerver címét és a csatlakozáshoz szükséges felhasználónevet.

Statikus útvonal hozzáadása egy távoli irodához VPN-alagúton keresztül.

Minden készen áll. Aktiváljuk a pptp kapcsolatot, és megpróbáljuk pingelni a helyi hálózat címeit. Győződjön meg arról, hogy a titkosítás le van tiltva a kliens pptp kapcsolati állapotában.

Most nézzük meg a vpn kapcsolat sebességét pptp-n keresztül.

Azonos 194 Mbps hogy titkosítatlan l2tp-n 100%-os CPU terhelés mellett. Általában egy kicsit furcsa volt pontosan ugyanazokat a számokat látni. Többször lefuttattam a teszteket, de az eredmény mindenhol ugyanaz volt. Titkosítás nélkül nincs különbség a sebességben az l2tp és a pptp kapcsolatok között.

Most engedélyezzük a titkosítást a pptp-ben a szerveren, és nézzük meg a sebességet. Ehhez kifejezetten jelezzük a pptp profilban, hogy titkosítást használjunk. Menj PPP -> Profilokés szerkessze a profilunkat.

Ellenőrizzük a kliens állapotát, hogy működik-e a titkosítás.

Egy VPN-kapcsolat sebességét tesztelem pptp-n keresztül, engedélyezve a titkosítást.

Átlagosan kiderült 71 Mbps... Nem rossz eredmény az ipsec titkosításhoz képest l2tp-ben. Ahogy korábban mondtam, a pptp szerver jól használható ott, ahol vagy egyáltalán nincs szükség titkosításra, vagy megengedett a titkosított forgalom visszafejtése. De ugyanakkor továbbra is titkosítással zárva van, és mindenki, aki arra jár, nem fog látni semmit. Legalább meg kell szüntetnie a forgalmat, és valahogyan ki kell választania egy kulcsot szótár vagy nyers erő segítségével. Nem tudom pontosan, hogy ez a gyakorlatban hogyan valósul meg. Nem tanulmányozta a kérdést.

Térjünk át a Mikrotik openvpn szerverére. Nagyon kíváncsi az ilyen típusú vpn kapcsolatok sebességtesztjeire.

Openvpn szerver konfigurálása a Mikrotikban

Nincs semmi bonyolult az openvpn szerver mikrotikon beállításában, kivéve a tanúsítványokkal kapcsolatos árnyalatot. Aki még soha nem dolgozott velük, túlságosan zavarónak tűnhet. Ezenkívül a microtic maga nem tartalmaz semmilyen eszközt a szerver- és ügyféltanúsítványok létrehozására. Harmadik féltől származó segédprogramokat kell használnia. Ha van linuxos géped, használhatod az utasításaimat.

Ha nincs linuxos gépek, de még mindig be van állítva a vpn alagút emelése az openvpn segítségével a microtikban, akkor foglalkozzunk tovább a konfigurációval. Először is szükségünk van egy openvpn disztribúcióra a Windows számára. Letöltheti a linkről - https://openvpn.net/community-downloads/. Érdeklődni fogunk a Windows Installer iránt.

A telepítést az adminisztrátor megbízásából végezzük, és a folyamat során megadunk egy komponenst, az úgynevezett EasyRSA 2 tanúsítványkezelő szkriptek.

Menjen a könyvtárba C: \ Program Files \ OpenVPN... Innen visszük át a mappát könnyű-rsa valahol máshol, hogy ne kelljen állandóan az UAC-ban botorkálni, ami nem teszi lehetővé, hogy csendesen dolgozzon a Program fájlokban. oda költöztem D: \ tmp \ easy-rsa... Nevezze át a fájlt vars.bat.sample v vars.bat... Megnyitjuk szerkesztésre, és a következőhöz hasonlóra hozzuk.

Azok számára, akik nem értik, ezek csak változók, amelyeket az én igényeimnek megfelelően határoztam meg. Oda bármit le lehet írni, nem elengedhetetlen a feladatunkhoz. Egyáltalán nem változtathatsz semmit, hanem hagyd úgy, ahogy van. Hozzon létre egy mappát a könyvtárban kulcsok... Következő, fuss parancs sor az adminisztrátortól, és lépjen a megadott könyvtárba D: \ tmp \ easy-rsa.

Megválaszoljuk a feltett kérdéseket és befejezzük a gyökértanúsítvány létrehozását. Megjelenik a mappában D: \ tmp \ easy-rsa \ gombok... Ezután hozzon létre egy tanúsítványt az openvpn szerverhez a következő paranccsal - build-key-server szervernév.

Most generáljunk egy tanúsítványt az ügyfél számára. Csak egy kliensem van távoli mikrotika formájában. Pontosan annyit alkotsz, amennyire szükséged van. A parancsot használjuk build-key tanúsítvány_neve.

A tanúsítványok létrehozásával befejeződött. Mindannyiunkban megtalálhatók a kulcsok könyvtárában. A microticon, amely openvpn szerverként fog működni, át kell vinnie a fájlokat:

  • kb.crt
  • ovpnserver.crt
  • ovpnserver.key

A hozzáadott fájlokból tanúsítványokat importálunk. Menj Rendszer -> Tanúsítványokés először importálni kb.crt, után ovpnserver.crtés ovpnserver.key.

Valahogy így kell kinéznie. Most kezdjük el beállítani az openvpn szervert a mikrotikban. Készítsünk hozzá külön profilt PPP -> Profilok.

Minden beállítás alapértelmezett. Helyi és távoli címként az Ip Pool-ot használom, amelyet az l2tp konfiguráció legelején hoztam létre. Távoli felhasználó hozzáadása az openvpn-hez PPP -> Titkok.

Megyünk a szakaszhoz PPPés kattintson OVPN szerver... Jelöljük a beállításokat és a letöltött ca tanúsítványt.

Ezzel befejeződik az openvpn szerver konfigurálása a Mikrotikban. Alapértelmezés szerint a titkosítási protokoll lesz használatban BF-128-CBC... Megváltoztatható a kliens tulajdonságaiban, az összes támogatott titkosítás listája pedig a vpn szerver tulajdonságaiban.

Ahhoz, hogy az openvpn szerver megadott beállítása működjön, meg kell nyitnia a 1194-es bejövő tcp portot a tűzfalon. Most állítsunk be egy openvpn klienst, és teszteljük a kapcsolat sebességét a vpn-n keresztül az openvpn alapján.

openvpn kliens

Az openvpn kliens mikrotikon konfigurálásához az előző lépésben generált tanúsítványokat oda kell vinni. Pontosabban ezek a fájlok:

  • m-remote.crt
  • m-távirányító.kulcs

Ezekből a fájlokból importáljuk a tanúsítványt, valamint a szerverre. Kérjük, vegye figyelembe, hogy a tanúsítvány neve mellett KT karaktereknek kell lenniük.

Most konfigurálja az openvpn klienst. Menj PPPés add hozzá OVPN kliens.

Adjon hozzá egy statikus útvonalat az openvpn szerver mögötti távoli hálózat erőforrásainak eléréséhez.

Minden készen áll. Az openvpn-n keresztül csatlakozhat és tesztelheti a vpn-kapcsolat sebességét.

Átlagosan kiderült 24 Mbps 100%-os processzorterhelés mellett. Az eredmény az l2tp + ipsec-hez hasonlítható. Kicsit meglepett az eredmény. Azt hittem, hogy rosszabb lesz, mint az l2tp, de a valóságban ugyanaz. Én személy szerint jobban szeretem az openvpn opciót, bár a microtik korlátozott openvpn beállításai miatt az openvpn előnyeit nehéz megvalósítani. Hadd emlékeztesselek, hogy BF-128-CBC titkosítással, azaz blowfish-sel teszteltem.

Íme az eredmény az AES-128-CBC-vel - 23 Mbps, nagyjából ugyanaz.

Kliens-szerverrel vpn implementációk rendezte a szervert a mikrotikban. Most nézzük meg az l2-vpn sebességet eoip alagút formájában.

EOIP Tunnel + Ipsec beállítás

Beállítás vpn hálózat EOIP alapján a Mikrotikban. Itt meg kell értenie egy fontos különbséget az összes korábbi beállításhoz képest, amelyet korábban tettünk. Az EOIP alagút l2 szinten működik, vagyis mindkét hálózati szegmens ugyanazon a fizikai hálózaton lévőnek tekinti magát. Mindkettő címtere azonos lesz. Az én példámban ez 10.20.1.0/24. Mindkét hálózathoz csak egy DHCP-szerver legyen. Az én esetemben ez marad m-szerver.

Létrehozunk egy EOIP alagutat az m-szerverhez. Menj Interfész lista -> EoIP Tunnelés adjunk hozzá egy újat.

A beállítások közül elég csak a második mikrotika távoli címét megadni. Az új EoIP interfészt hozzá kell adni a helyi hídhoz a fizikai interfészekkel együtt.

A távoli mikrotikához megyünk, és ott mindent ugyanúgy csinálunk, csak megadunk egy másik távoli címet.

Ez elég ahhoz, hogy az EoIP alagút azonnal működjön. Állapota RS lesz.

A második mikrotikán az EoIP interfészt is hozzá kell adni a helyi hídhoz a többi interfésszel.

A legegyszerűbb módja annak, hogy ellenőrizzük, hogy minden rendben van-e, ha a dhcp-t lekérjük a híd interfész m-slave IP-címére. Kapnia kell egy IP-címet az m-szerveren lévő dhcp szervertől, feltéve, hogy már nincs más dhcp szerver a hálózaton. Ugyanez fog történni az m-slave mögötti hálózat helyi gépeivel is. IP címeket kapnak a dhcp szervertől az m-szerverhez.

Most nézzük meg egy ilyen EoIP-alapú vpn-alagút teljesítményét.

Megmutatom a maximális eredményt, amit elértem - 836 Mbps... Valamiért a különböző tesztekben a sebesség 600-850 Mbps között lebegett. A sebesség változásához az EoIP interfészt kellett letiltani és újra engedélyezni. A sebesség lenyűgöző. Ugyanakkor a processzor nincs 100%-ban betöltve. Azaz palacknyak nem ő. Úgy tűnik, belefutottam a hálózati teljesítménybe. Hadd emlékeztesselek arra, hogy itt nincs titkosítás és forgalomirányítás. Közvetlen l2 csatorna két mikrotika között EoIP vpn-n keresztül.

Adjuk hozzá az Ipsec titkosítást az EoIP alagúthoz, és nézzük meg a sebességet. Ehhez mindkét mikrotikán módosítjuk a csatornabeállításokat. Adjon hozzá Ipsec-jelszót és helyi címeket, tiltsa le a Fast Path-t.

Online tanfolyam "Hálózatmérnök"

Ha szeretné megtanulni, hogyan kell magasan elérhető és megbízható hálózatokat felépíteni és karbantartani, javasoljuk, hogy tekintse meg az OTUS „Hálózatmérnök” online tanfolyamát. azt szerzői program valódi berendezéseken való távgyakorlással és a Cisco tudományos bizonyítvánnyal kombinálva! A hallgatók gyakorlati ismereteket szereznek a berendezéseken való munkavégzésben egy oktatópartner alapján működő távoli online laboratórium segítségével - RTU MIREA: Cisco 1921, Cisco 2801, Cisco 2811 routerek; kapcsolók Cisco 2950, ​​​​Cisco 2960. A tanfolyam jellemzői:
  • A kurzus két tervezési munkát tartalmaz .;
  • A hallgatók beiratkoztak a Hivatalos Cisco Akadémiára (OTUS, Cisco Academy, ID 400051208), és hozzáférhetnek a CCNA Routing and Switching tanfolyam minden részéhez;
  • A hallgatók letehetik a vizsgát, és az OTUS tanúsítvánnyal együtt egy másik tanfolyami bizonyítványt is kaphatnak: „CCNA Routing and Switching: Scaling Networks”;
Ellenőrizze magát a felvételi vizsgán, és tekintse meg a programot a részletekért.

Oszd meg és uralkodj: Garantált MS-CHAPv2 Hack

Alekszandr Antipov

A huszadik Defcon konferencián David Hulton és én előadást tartottunk az MS-CHAPv2 feltöréséről. Ez a bejegyzés hozzávetőleges áttekintést nyújt arról, hogy miről beszéltünk.


A huszadik Defcon konferencián mi David Hulton előadást tartott az MS-CHAPv2 feltöréséről. Ez a bejegyzés hozzávetőleges áttekintést nyújt arról, hogy miről beszéltünk.

Miért az MS-CHAPv2?

Az első kézenfekvő kérdés az, hogy miért vágtunk bele az MS-CHAPv2-be, tekintettel arra a régóta fennálló érzésre, hogy az Internetnek nem szabad erre a protokollra hagyatkoznia. Sajnos, még elavult protokollként és széles körben kritika tárgyaként is, továbbra is mindenhol használják. A legfigyelemreméltóbb az MS-CHAPv2 használata PPTP VPN-en keresztül. A WPA2 Enterprise konfigurációkban is meglehetősen gyakran használják, különösen akkor, ha kölcsönös hitelesítési tulajdonságaira támaszkodik. Előadásunkhoz összeállítottunk egy listát a PPTP-től függő VPN-szolgáltatók százairól. Olyan figyelemre méltó példákat tartalmaz, mint az iPredator, a The Pirate Bay VPN, amelyet állítólag arra terveztek, hogy megvédje a kommunikációt a kormányzati felügyelettől.

Úgy gondoljuk, hogy az MS-CHAPv2 továbbra is annyira elterjedt, mivel a lehetséges protokollhiányok korábbi kutatói főként a szótári támadásokra összpontosítottak. Ezt a kutatási korlátot kombinálva a protokollt támogató kliensek rendkívül széles számával és annak operációs rendszerrel való kompatibilitásával, világossá válik, hogy miért olyan csábító ez a megoldás, amely a legkevesebb testmozgást igényli a felhasználótól.

Most mi?

1) A PPTP VPN-megoldások minden felhasználójának és szolgáltatójának azonnal el kell kezdenie az átállást egy másik VPN-protokollra. A PPTP-forgalmat titkosítatlannak kell tekinteni.

2) Azoknak a vállalatoknak, amelyek az MS-CHAPv2 kölcsönös hitelesítési tulajdonságaira támaszkodnak a WPA2 RADIUS szervereikhez való csatlakozáskor, azonnal el kell kezdeniük az átállást egy alternatív megoldásra.

A nagyvállalatok sok esetben az IPSEC-PSK használatát választották a PPTP helyett. Míg a PPTP-t jelenleg látszólag feltörték, az IPSEC-PSK valószínűleg még sebezhetőbb a szótári támadásokkal szemben, mint a PPTP valaha volt. A PPTP legalább megköveteli a támadótól, hogy elfogja az aktív hálózati forgalmat, hogy offline szótári támadást indítson, míg az IPSEC-PSK VPN agresszív módban lényegében kivonatokat ad ki minden támadónak, aki csatlakozik.

Tekintettel a ma elérhető megoldásokra, bárminek biztonságos telepítéséhez tanúsítványérvényesítés szükséges. Ez vagy az OpenVPN konfigurációjához, vagy az IPSEC tanúsítványmódban való használatához PSK helyett.

Virtuális magán hálózat(Virtuális magánhálózat, a továbbiakban: VPN) lehetővé teszi a létrehozását az interneten egy biztonságos virtuális alagút egyik eszközről a másikra... Ha egy ilyen alagúton keresztül éri el a hálózatot, akkor mindenki más beleértve a szolgáltatóját is nagyon nehéz lesz nyomon követni a tetteit.

A VPN-szolgáltatások abban is segítenek, hogy a fizikai tartózkodási helyét bármilyen más adattal helyettesítse, ami lehetővé teszi olyan szolgáltatások elérését, amelyek földrajzi elhelyezkedésük miatt bizonyos régiók felhasználói számára le vannak tiltva. VPN használata lehetővé teszi a hálózaton továbbított üzenetek titkosságának (az adatok titkosak maradnak) és integritásának (az adatok változatlanok maradnak) védelmét.

A VPN-hez való csatlakozás meglehetősen egyszerű. Először a felhasználó online lép fel, csatlakozik a szolgáltató szervereihez, majd VPN kapcsolatot létesít a VPN szerverrel a kliens segítségével ( speciális program telepítve van a felhasználó számítógépére). A VPN szolgáltatás ezután megkapja a felhasználó által kért oldalakat, és egy biztonságos alagúton keresztül továbbítja azokat neki. Ez biztosítja a felhasználó adatainak és magánéletének védelmét az online munkavégzés során.

Hogyan működik a VPN titkosítás?

A VPN-protokoll az adatok továbbítására és titkosítására vonatkozó szabályok összessége. A legtöbb VPN-szolgáltatás számos VPN-protokoll közül választhat ügyfeleit, amelyek közül a leggyakoribbak a Point-to-Point Tunneling Protocol (PPTP), a Layer Two Tunneling Protocol (L2TP), az Internet Protocol Security (IPSec) és az OpenVPN (SSL / TLS). ) ).

Nem lehet megmagyarázni, hogyan védik a VPN-ek a felhasználók adatait anélkül, hogy a titkosításról beszélnénk. A VPN-szolgáltatások speciális adatfeldolgozási módszert (titkosítást) használnak annak érdekében, hogy az olvasott adatokat (sima szöveg) teljesen olvashatatlanná (titkosított szöveg) tegyék bárki számára, aki el tudja fogadni azokat. Az algoritmus (rejtjel) határozza meg, hogy egy adott VPN-protokoll keretein belül hogyan történik az adatok titkosítása és visszafejtése. A VPN-protokollok ezeket a kriptográfiai algoritmusokat használják az adatok titkosításához és bizalmas kezeléséhez.

Ezen VPN-protokollok mindegyikének megvannak a maga erősségei és gyengeségei, a megfelelő kriptográfiai algoritmustól függően. Egyes VPN-szolgáltatások lehetővé teszik a felhasználók számára, hogy maguk válasszanak ki egyet az elérhető titkosítások közül. Háromféle titkosítás létezik: szimmetrikus, aszimmetrikus és hash.

A szimmetrikus titkosítás ugyanazt a kulcsot használja az adatok titkosításához és visszafejtéséhez. Az aszimmetrikus titkosítás két kulcsot használ, az egyiket a titkosításhoz, a másikat a visszafejtéshez. Az alábbi táblázat összehasonlítja ezeket a titkosítási típusokat egymással.

Paraméter Szimmetrikus titkosítás Aszimmetrikus titkosítás
Kulcsok Egy kulcs több entitáshoz Az egyik entitásnak nyilvános, a másiknak privát kulcsa van
Kulcscsere Szükséges biztonságos út kulcsok küldése és fogadása A privát kulcsot a tulajdonos őrzi, a nyilvános kulcs mindenki más számára elérhető
Sebesség Könnyebb és gyorsabb Nehezebben és lassabban
Megbízhatóság Könnyebb feltörni Nehezebb feltörni
Méretezhetőség Még szebb
Használat Bármit titkosítani Csak kulcsok és digitális aláírások
Biztonsági opciók A titoktartás biztosítása Titoktartás, hitelesítés és elutasítás megelőzés biztosítása
Példák DES, Tipple DES, AES, Blowfish, IDEA, RC4, RC5 és RC6 RSA, ECC, DSA és Diffie-Hellman algoritmus

Az aszimmetrikus kriptográfia segít, ha le kell küzdenie a szimmetrikus kriptográfiában rejlő korlátokat (amint azt a fenti táblázat mutatja). Whitfield Diffie és Martin Hellman része volt az első kutatócsoportnak, amely a szimmetrikus titkosítás fejlesztésén dolgozott, és ők fejlesztették ki az aszimmetrikus titkosítási algoritmust, Diffie – Hellman algoritmus.

Ez egy népszerű kriptográfiai algoritmus, amely számos VPN-protokoll alapját képezi, beleértve a HTTPS-t, az SSH-t, az IPsec-et és az OpenVPN-t. Ezzel az algoritmussal két, egymással korábban még soha nem találkozott fél megbeszélheti a privát kulcsot olyan esetekben is, amikor a kommunikáció nem biztonságos nyilvános hálózaton (például interneten) keresztül történik.

A kivonatolás egyirányú (visszafordíthatatlan) titkosítás, amelyet a továbbított adatok integritásának védelmére használnak. Sok VPN-protokoll hash-algoritmusokat használ a VPN-en keresztül küldött üzenetek ellenőrzésére. Ilyen például az MD5, SHA-1 és SHA-2. Az MD5 és az SHA-1 azonban már nem tekinthető biztonságosnak.

A VPN-szolgáltatásokat fel lehet törni, de ez nagyon-nagyon nehéz. Ha nem használ VPN-t, sokkal nagyobb az esélye annak, hogy eltalálják a hackerek.

Valaki fel tudja törni a VPN szolgáltatást?

A VPN-szolgáltatások továbbra is az egyik legmegbízhatóbb módja a felhasználók online adatainak védelmének. Nem szabad azonban elfelejteni, hogy bármit fel lehet törni, különösen akkor, ha Ön értékes célpont, és ellenségeinek van elég ereje, ideje és pénze. Szerencsére a legtöbb alkalmi VPN-felhasználó nem ilyen célpont, ezért nem valószínű, hogy felkeltik volna túl sok figyelmet.

A VPN-kapcsolat megszakításához meg kell szakítani a titkosítást, és ehhez vagy ki kell használni a rendszer vagy az algoritmus sebezhetőségét, vagy ilyen vagy olyan módon el kell lopnia a titkosítási kulcsot. A kriptográfiai támadásokat hackerek és kriptoanalitikusok használják arra, hogy titkosítási kulcs hiányában egyszerű szöveget vonjanak ki a titkosított változatból. A titkosítás feltörése azonban rengeteg számítási erőforrást és időt igényel – szó szerint évekbe telhet egy ilyen probléma megoldása.

Gyakran megpróbálják ellopni a titkosítási kulcsot, és ez érthető is: sokkal könnyebb, mint a titkosítást megoldani. Ezt a módszert alkalmazzák elsősorban a hackerek. Mindez nemcsak a matematikán múlik, hanem számos tényező kombinációján, beleértve a technikai trükköket, számítási teljesítmény, csalás, bírósági végzések és hátsó ajtók, vesztegetés és egyéb piszkos módszerek. És mindez azért, mert a rejtjelek megfejtése nagyon nehéz és erőforrás-igényes feladat.

Ismert VPN biztonsági rések

A hírhedt Edward Snowden és a szakemberek számítógép biztonság nem egy alkalommal állították, hogy az NSA (US Nemzetbiztonsági Ügynökség) feltörte a legtöbb internetes forgalom védelmére használt titkosítást, beleértve a VPN-forgalmat is. Snowden anyaga szerint az NSA dekódolja a VPN-forgalmat azáltal, hogy elfogja a titkosított forgalmat, és továbbítja az adatokat nagy teljesítményű számítógépeknek, amelyek aztán visszaadják a kulcsot.

Alex Halderman és Nadia Heninger számítógép-biztonsági szakértők meggyőző jelentést nyújtottak be arról, hogy az NSA valóban képes nagy mennyiségű HTTPS-, SSH- és VPN-forgalom visszafejtésére egy Logjam-támadással, amely a Diffie-algoritmus fő felhasználási területeit célozza meg.

Az NSA sikerét a Diffie-Hellman algoritmus megvalósításának sérülékenységének köszönheti. Ennek a sérülékenységnek az a lényege, hogy a titkosító programok szabványos prímszámokat használnak. Halderman és Heninger azzal érvelnek, hogy több száz millió dollárért olyan számítógépet lehet építeni, amely elég erős egyetlen 1024 bites Diffie-Hellman titkosítás megfejtéséhez. Egy ilyen számítógép elkészítése körülbelül egy évig tart, hiszen az ehhez szükséges összegért - az NSA éves költségvetése szempontjából semmi sem lehetetlen.

Sajnos előfordul, hogy nem minden prímszámot (1024 bitnél kevesebbet) használnak általánosan a mindennapi titkosított alkalmazásokban – beleértve a VPN-eket is. Ennek eredményeként még könnyebbé válik az ilyen algoritmusok feltörése. Ahogy Bruce Schneier kijelentette: „A matematika jó, de nem lehet feltörni. De a kód más kérdés."

Továbbra is használjon VPN-eket?

Halderman és Heninger azt tanácsolja a VPN-eknek, hogy váltsanak 2048 bites vagy még bonyolultabb Diffie-Hellman titkosítási kulcsokra, és elkészítettek egy oktatóanyagot a TLS-sel való használatukról. Az Internet Engineering Task Force (IETF) szintén javasolja a használatát legújabb verziói hosszabb prímsorozatokat igénylő protokollok.

A hackerek feltörhetik a Diffie-Hellman titkosítási kulcsokat, ha azok 1024 bitnél (körülbelül 309 karakterből) rövidebbek vagy azzal egyenlőek. A 2048 bites kulcsok feltörése igazi problémát jelent majd a hackerek számára! Más szóval, nagyon sokáig nem tudják majd visszafejteni az ilyen kulcsokkal védett adatokat.

Ami a felhasználókat illeti, meg kell jegyezni, hogy a hackerek ismerik a VPN-szolgáltatások és a titkosítási protokollok sebezhetőségét, amellyel titkosított adatokat lopnak, és hozzáférnek azokhoz. Azonban sokkal jobban védett VPN-ekkel, mint nélkülük.. A számítógépét feltörhetik, de ez nagyon drága és időigényes lesz.És igen, minél kevésbé vagy látható, annál jobban védett.

Ahogy Snowden érvel: „A titkosítás valóban segít. Valóban megbízhat a megbízható és jól hangolt titkosítási rendszerekben." Ennek megfelelően kerülje az olyan VPN-szolgáltatásokat, amelyek túlnyomórészt SHA-1 vagy MD5 kivonatolási algoritmusokat, valamint PPTP vagy L2TP / IPSec protokollokat használnak. Érdemes olyan VPN-szolgáltatást választani, amelyik használ legújabb verzió OpenVPN(rendkívül biztonságos opció) vagy SHA-2. Ha nem tudja biztosan meghatározni, hogy a szolgáltatás melyik titkosítási algoritmust használja, keresse meg ezt az információt a felhasználói kézikönyvben, vagy lépjen kapcsolatba a szolgáltatás ügyfélszolgálatával.

A VPN-ek a barátaid. Bízzon a titkosításban, ne kételkedjen a matematikában. A lehető leggyakrabban használja a VPN-t, és próbáljon meg meggyőződni arról, hogy a kilépési pontjai is biztonságosak. Így még akkor is biztonságban maradhat, ha titkosított alagútját feltörik.

@SooLFaa:
Habozás nélkül úgy döntöttem, hogy szó szerint veszem az ajánlást.

A program megismertetése, elindítása.

A routereket nem a helyi gépemről fogják támadni, hanem egy speciálisan bérelt távoli VDS-ről Windows vezérlés. Dupla kattintás bal egérgombbal, hogy átvigyen Hollandiába.


Ahogy a cím is mondja, a RouterScan támadási eszközként fog működni. A program letöltéséhez menjünk az Antichat fórumra. A szerző biztosítéka szerint csak onnan kell letölteni a programot.

A program hordozható, telepítése a letöltött archívum kicsomagolásából áll a megadott mappába.


Alapértelmezés szerint a program a 80-as, 8080-as, 1080-as portokon támadja meg a routereket. Szerintem ez a lista teljesen indokolt, és nem igényel kiegészítést vagy változtatást.
Ezenkívül a program további modulokat is csatlakoztathat
  • Router Scan (fő)
  • Proxyszerverek észlelése
  • Használja a HNAP 1.0-t
  • SQLite Manager RCE
  • Hudson Java Servlet
  • phpMyAdmin RCE

és az útválasztók elleni támadással együtt egy adott tartományban lévő összes IP-t "megvizsgálja".
De a program ilyen terhelése jelentősen lelassítja a munkáját, ezért ebben az ablakban nem érintünk semmit. végül is a támadás célja egy véletlenszerű router WEB felületének elérése cikkíráshoz.

Csak ki kell választani a támadás IP-tartományát, és futtathatja a programot.
Egy olyan oldalra megyünk, amely országonként megadja az IP-tartományokat, és áldozatként véletlenszerűen Lengyelországot választjuk (az ország kiválasztása véletlenszerű).


Miután a kívánt tartományokat beszúrta a megfelelő programablakba, elindíthatja a programot.
Az útválasztók feltörésére fordított idő a kiválasztott tartományban lévő IP-k számától függ, és meglehetősen hosszú ideig tarthat.
De egy cikk írásához csak egy feltört routerre van szükségem, amin VPN szervert lehet emelni. Ezek a modellek lehetnek ASUS routerek, Mikrotik vagy bármilyen más modell DD-WRT firmware... A „Jó eredmények” lapon megjelenő útválasztók listájára való gyors pillantást követően könnyen megállapíthatja, hogy a megadott útválasztók modelljei szerepelnek a listában.

Emeljük a VPN-kiszolgálót az útválasztón.

Ebben a cikkben az áldozat szerepére egy DD-WRT-t futtató útválasztót választottam.

Választásomat az magyarázza, hogy az említett firmware lehetővé teszi a router VPN-kiszolgálóként való használatát a PPTP protokoll segítségével, és a közelmúltban ennek a protokollnak szenteltem.

Másolja be a kívánt útválasztó URL-címét címsor böngésző és az oldal betöltése után a webes felületén találjuk magunkat rendszergazdai jogokkal.

Ahhoz, hogy az útválasztó VPN-kiszolgáló szerepét töltse be, lépjen a Szolgáltatások lapra - PPTP.