VPN-felhasználók kéttényezős hitelesítése MikroTik-on és SMS-en keresztül

Hello kollégák! Ma, amikor egy kicsit alábbhagyott a „távmunka” körüli szenvedélyek intenzitása, az adminisztrátorok többsége megnyerte az alkalmazottak vállalati hálózathoz való távoli elérésének feladatát, itt az ideje, hogy megosszam a VPN biztonság javítása terén szerzett sokéves tapasztalatomat. Ez a cikk nem lesz divat most IPSec IKEv2 és xAuth. A rendszer felépítéséről van szó. kétfaktoros hitelesítés (2FA) VPN-felhasználók, ha a MikroTik VPN-kiszolgálóként működik. Nevezetesen, amikor "klasszikus" protokollokat, például PPP-t használnak.

VPN-felhasználók kéttényezős hitelesítése MikroTik-on és SMS-en keresztül

Ma elmondom, hogyan védheti meg a MikroTik PPP-VPN-t még a felhasználói fiók "eltérítése" esetén is. Amikor ezt a konstrukciót bemutatták az egyik ügyfelemnek, röviden így jellemezte, hogy „na, ez most olyan, mint a bankban!”.

A módszer nem használ külső hitelesítő szolgáltatásokat. A feladatokat belsőleg maga a router végzi el. A csatlakozó kliensnek nincs költsége. A módszer PC-klienseken és mobileszközökön egyaránt működik.

Az általános védelmi rendszer a következő:

  1. A VPN-kiszolgálóhoz sikeresen csatlakozott felhasználó belső IP-címe automatikusan szürkelistára kerül.
  2. A kapcsolódási esemény automatikusan létrehoz egy egyszeri kódot, amelyet az elérhető módszerek egyikével elküld a felhasználónak.
  3. A listában szereplő címek korlátozott hozzáféréssel rendelkeznek a helyi hálózati erőforrásokhoz, kivéve a „hitelesítő” szolgáltatást, amely egyszeri jelszó fogadására vár.
  4. A kód bemutatása után a felhasználó hozzáfér a hálózat belső erőforrásaihoz.

Első A legkisebb probléma, amellyel szembe kellett néznem, az volt, hogy a felhasználó elérhetőségi adatait tároltam, hogy elküldhessem neki a 2FA-kódot. Mivel a Mikrotikban nem lehet a felhasználóknak megfelelő tetszőleges adatmezőket létrehozni, a meglévő „megjegyzés” mezőt használtuk:

/ppp secrets add name=Petrov password=4M@ngr! comment="89876543210"

A második a probléma komolyabbnak bizonyult - a kód kézbesítésének útvonalának és módjának megválasztása. Jelenleg három séma van megvalósítva: a) SMS USB modemen keresztül b) e-mail c) SMS e-mailben a vörös cellás szolgáltató vállalati ügyfelei számára.

Igen, az SMS-sémák költségekkel járnak. De ha megnézzük, "a biztonság mindig a pénzről szól" (c).
Én személy szerint nem szeretem az e-mailezést. Nem azért, mert ehhez a levelezőszervernek elérhetőnek kell lennie a hitelesített kliens számára – nem probléma a forgalom felosztása. Ha azonban egy kliens hanyagul elmentette a vpn és az e-mail jelszavakat is egy böngészőbe, majd elvesztette laptopját, a támadó teljes hozzáférést kapna onnan a vállalati hálózathoz.

Tehát eldőlt – egyszeri kódot küldünk SMS-ben.

harmadik A probléma az volt, hogy hol hogyan lehet pszeudo-véletlen kódot generálni a 2FA-hoz a MikroTikben. A RouterOS szkriptnyelvében nincs analógja a random() függvénynek, és korábban is láttam több mankószkript pszeudo-véletlenszám-generátort. Különféle okok miatt egyiket sem szerettem.

Valójában a MikroTikben van egy pszeudo-véletlen sorrendgenerátor! A felületes pillantás elől el van rejtve a /certificates scep-server kontextusában. Az első út az egyszeri jelszó beszerzése könnyű és egyszerű - a paranccsal /certificates scep-server otp generál. Ha egy egyszerű változó-hozzárendelési műveletet hajtunk végre, akkor egy tömbértéket kapunk, amelyet később szkriptekben is használhatunk.

A második út egyszeri jelszó beszerzése, amely szintén könnyen alkalmazható – külső szolgáltatás igénybevételével random.org a kívánt típusú pszeudo-véletlen számsorozat létrehozásához. Itt van egy leegyszerűsített konzolos példa az adatok változóba való beillesztésére:

Kód
:global rnd1 [:pick ([/tool fetch url="https://www.random.org/strings/?num=1&len=7&digits=on&unique=on&format=plain&rnd=new" as-value output=user ]->"da
ta") 1 6] :put $rnd1

A konzolhoz formázott kérés (a szkript törzsében speciális karakterekre lesz szükség) hat számjegyű karakterláncot kap a $rnd1 változóba. A következő "put" parancs egyszerűen megjeleníti a változót a MikroTik konzolon.

A negyedik probléma amit gyorsan meg kellett oldani – a csatlakoztatott kliens így és hová fogja átvinni egyszeri kódját a hitelesítés második szakaszában.

VPN-felhasználók kéttényezős hitelesítése MikroTik-on és SMS-en keresztül

A MikroTik útválasztón kell lennie olyan szolgáltatásnak, amely képes elfogadni a kódot és egy adott klienshez illeszteni. Ha a megadott kód egyezik a várttal, akkor az ügyfél címét fel kell venni egy bizonyos „fehér” listára, ahonnan a címek hozzáférhetnek a cég belső hálózatához.

A rossz szolgáltatásválaszték miatt a Mikrotikba épített webproxy segítségével a http-n keresztüli kódok elfogadása mellett döntöttek. És mivel a tűzfal képes együttműködni az IP-címek dinamikus listáival, a tűzfal keresi a kódot, egyezteti azt az ügyfél IP-jével, és a Layer7 regexp segítségével hozzáadja a „fehér” listához. Magához az útválasztóhoz egy "gw.local" feltételes DNS név van hozzárendelve, rajta egy statikus A-rekord jött létre a PPP kliensek számára történő kiadáshoz:

DNS
/ip dns static add name=gw.local address=172.31.1.1

Ellenőrizetlen ügyfelek forgalmának rögzítése a proxyn:
/ip firewall nat add chain=dstnat dst-port=80,443 in-interface=2fa protocol=tcp !src-address-list=2fa_approved action=redirect to-ports=3128

Ebben az esetben a proxynak két funkciója van.

1. Nyisson meg tcp kapcsolatokat az ügyfelekkel;

2. Sikeres hitelesítés esetén irányítsa át a kliens böngészőjét a sikeres hitelesítésről értesítő oldalra vagy képre:

Proxy konfig
/ip proxy
set enabled=yes port=3128
/ip proxy access
add action=deny disabled=no redirect-to=gw.local./mikrotik_logo.png src-address=0.0.0.0/0

Felsorolom a fontos konfigurációs elemeket:

  1. interfész-lista „2fa” – a kliens interfészek dinamikus listája, amelyek forgalma 2FA-n belüli feldolgozást igényel;
  2. címlista "2fa_jaled" - VPN kliensek alagút IP-címeinek "szürke" listája;
  3. address_list "2fa_approved" – a kéttényezős hitelesítésen sikeresen átesett VPN-kliensek alagút IP-címeinek "fehér" listája.
  4. tűzfallánc "input_2fa" - ellenőrzi a tcp-csomagokat, hogy vannak-e jogosultsági kódok, és egyezteti a kód küldőjének IP-címét a szükségesvel. A lánc szabályai dinamikusan kerülnek hozzáadásra és eltávolításra.

A csomagfeldolgozás egyszerűsített folyamatábrája így néz ki:

VPN-felhasználók kéttényezős hitelesítése MikroTik-on és SMS-en keresztül

A „szürke” listáról érkező ügyfelek forgalmának Layer7 ellenőrzéséhez, amelyek még nem mentek át a hitelesítés második szakaszán, egy szabályt hoztak létre a szabványos „beviteli” láncban:

Kód
/ip firewall filter add chain=input !src-address-list=2fa_approved action=jump jump-target=input_2fa

Most kezdjük el ezt a vagyont a PPP szolgáltatáshoz kötni. A MikroTik lehetővé teszi a szkriptek használatát a profilokban (ppp-profil), és hozzárendeli azokat a ppp kapcsolat létrehozásának és megszakításának eseményeihez. A ppp-profil beállításai mind a PPP-szerver egészére, mind az egyes felhasználókra alkalmazhatók. Ugyanakkor a felhasználóhoz rendelt profil elsőbbséget élvez, felülírva a szerver egészére kiválasztott profil paramétereit a megadott paramétereivel.

Ennek a megközelítésnek köszönhetően létrehozhatunk egy speciális profilt a kéttényezős hitelesítéshez, és nem minden felhasználóhoz rendelhetjük hozzá, hanem csak azoknak, akik ezt szükségesnek tartják. Ez akkor lehet releváns, ha a PPP-szolgáltatásokat nem csak a végfelhasználók összekapcsolására használja, hanem egyúttal a helyek közötti kapcsolatok kiépítésére is.

Az újonnan létrehozott speciális profilban a "szürke" cím- és interfészlistákhoz a csatlakoztatott felhasználó címének és felületének dinamikus hozzáadását használjuk:

winbox
VPN-felhasználók kéttényezős hitelesítése MikroTik-on és SMS-en keresztül

Kód
/ppp profile add address-list=2fa_jailed change-tcp-mss=no local-address=192.0.2.254 name=2FA interface-list=2fa only-one=yes remote-address=dhcp_pool1 use-compression=no use-encryption= required use-mpls=no use-upnp=no dns-server=172.31.1.1

A dstnat (előútválasztási) láncban a nem másodlagos VPN-kliensek forgalmának észleléséhez és rögzítéséhez mind a „címlista” és az „interfész-lista” listákat kell használni.

Ha az előkészítés befejeződött, további tűzfalláncok és profil jön létre, írunk egy szkriptet, amely a 2FA kód és az egyes tűzfalszabályok automatikus generálásáért felelős.

Dokumentáció wiki.mikrotik.com a PPP-Profile a PPP kliens csatlakozási-leválasztási eseményeivel kapcsolatos változókkal kapcsolatos információkkal gazdagít minket "Futtassa a parancsfájlt a felhasználói bejelentkezési eseményen. Ezek az eseményszkripthez elérhető változók: user, local-address, remote-address, caller-id, call-id, interface". Ezek közül néhány nagyon hasznos számunkra.

A profilban használt kód a PPP bekapcsolási kapcsolódási eseményéhez

#Логируем для отладки полученные переменные 
:log info (

quot;local-address")
:log info (


quot;remote-address")
:log info (


quot;caller-id")
:log info (


quot;called-id")
:log info ([/int pptp-server get (


quot;interface") name])
#Объявляем свои локальные переменные
:local listname "2fa_jailed"
:local viamodem false
:local modemport "usb2"
#ищем автоматически созданную запись в адрес-листе "2fa_jailed"
:local recnum1 [/ip fi address-list find address=(


quot;remote-address") list=$listname]

#получаем псевдослучайный код через random.org
#:local rnd1 [:pick ([/tool fetch url="https://www.random.org/strings/?num=1&len=7&digits=on&unique=on&format=plain&rnd=new" as-value output=user]->"data") 0 4] #либо получаем псевдослучайный код через локальный генератор
#:local rnd1 [pick ([/cert scep-server otp generate as-value minutes-valid=1]->"password") 0 4 ]

#Ищем и обновляем коммент к записи в адрес-листе. Вносим искомый код для отладки
/ip fir address-list set $recnum1 comment=$rnd1
#получаем номер телефона куда слать SMS
:local vphone [/ppp secret get [find name=$user] comment]

#Готовим тело сообщения. Если клиент подключается к VPN прямо с телефона ему достаточно
#будет перейти прямо по ссылке из полученного сообщения
:local msgboby ("Your code: ".$comm1."n Or open link http://gw.local/otp/".$comm1."/")

# Отправляем SMS по выбранному каналу - USB-модем или email-to-sms
if $viamodem do={
/tool sms send phone-number=$vphone message=$msgboby port=$modemport }
else={
/tool e-mail send server=a.b.c.d [email protected] [email protected] subject="@".$vphone body=$msgboby }

#Генерируем Layer7 regexp
local vregexp ("otp\/".$comm1)
:local vcomment ("2fa_".(


quot;remote-address"))
/ip firewall layer7-protocol add name=(


quot;vcomment") comment=(


quot;remote-address") regexp=(


quot;vregexp")

#Генерируем правило проверяющее по Layer7 трафик клиента в поисках нужного кода
#и небольшой защитой от брутфорса кодов с помощью dst-limit
/ip firewall filter add action=add-src-to-address-list address-list=2fa_approved address-list-timeout=none-dynamic chain=input_2fa dst-port=80,443,3128 layer7-protocol=(


quot;vcomment") protocol=tcp src-address=(


quot;remote-address") dst-limit=1,1,src-address/1m40s

Főleg azoknak, akik szeretnek ész nélkül másolni-beilleszteni – a kód a tesztverzióból származik, és kisebb elírási hibákat tartalmazhat. Egy megértő embernek nem lesz nehéz kitalálnia, hogy pontosan hol.

Amikor egy felhasználó bontja a kapcsolatot, egy „On-Down” esemény generálódik, és a megfelelő parancsfájl paraméterekkel meghívódik. Ennek a szkriptnek az a feladata, hogy megtisztítsa a leválasztott felhasználóhoz létrehozott tűzfalszabályokat.

A PPP on-down kapcsolódási esemény profiljában használt kód

:local vcomment ("2fa_".(

quot;remote-address"))
/ip firewall address-list remove [find address=(


quot;remote-address") list=2fa_approved] /ip firewall filter remove [find chain="input_2fa" src-address=(


quot;remote-address") ] /ip firewall layer7-protocol remove [find name=$vcomment]
Ezután létrehozhat felhasználókat, és mindegyiküket vagy néhányukat hozzárendelheti egy kéttényezős hitelesítési profilhoz.

winbox
VPN-felhasználók kéttényezős hitelesítése MikroTik-on és SMS-en keresztül

Kód
/ppp secrets set [find name=Petrov] profile=2FA

Hogyan néz ki az ügyfél oldalon.

VPN-kapcsolat létrejöttekor egy SIM-kártyás Android/iOS telefon/táblagép a következő SMS-t kap:

SMS
VPN-felhasználók kéttényezős hitelesítése MikroTik-on és SMS-en keresztül

Ha a kapcsolat közvetlenül a telefonról / táblagépről jön létre, akkor a 2FA-n egyszerűen az üzenetben található hivatkozásra kattintva léphet át. Kényelmes.

Ha a VPN-kapcsolat PC-ről jön létre, akkor a felhasználónak meg kell adnia egy minimális jelszó űrlapot. A VPN beállításakor a felhasználó egy kis űrlapot kap HTML-fájl formájában. A fájl akár levélben is elküldhető, így a felhasználó elmenti, és létrehoz egy parancsikont egy kényelmes helyen. Ez így néz ki:

Címke az asztalon
VPN-felhasználók kéttényezős hitelesítése MikroTik-on és SMS-en keresztül

A felhasználó rákattint a parancsikonra, megnyílik egy egyszerű kódbeviteli űrlap, amely beilleszti a kódot a megnyitott URL-be:

Képernyőforma
VPN-felhasználók kéttényezős hitelesítése MikroTik-on és SMS-en keresztül

Példaként a legprimitívebb formát hozzuk fel. Aki szeretne, az maga módosíthatja.

2fa_login_mini.html

<html>
<head> <title>SMS OTP login</title> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> </head>
<body>
<form name="login" action="location.href='http://gw.local/otp/'+document.getElementById(‘text').value"  method="post"
 <input id="text" type="text"/> 
<input type="button" value="Login" onclick="location.href='http://gw.local/otp/'+document.getElementById('text').value"/> 
</form>
</body>
</html>

Ha az engedélyezés sikeres volt, a felhasználó a MikroTik logót fogja látni a böngészőben, amely a sikeres hitelesítést jelzi:

VPN-felhasználók kéttényezős hitelesítése MikroTik-on és SMS-en keresztül

Vegye figyelembe, hogy a kép a beépített MikroTik webszerverről a WebProxy Deny Redirect használatával érkezik vissza.

Feltételezem, hogy a kép testreszabható a "hotspot" eszközzel, feltöltve a saját verzióját, és beállítva rá a WebProxy segítségével az átirányítás megtagadása URL-t.

Nagy kérés azokhoz, akik a legolcsóbb Mikrotik "játékot" próbálják megvenni 20 dollárért és egy 500 dolláros routert cserélni vele – ezt ne tegyék. Az olyan eszközök, mint a "hAP Lite" / "hAP mini" (otthoni hozzáférési pont), nagyon gyenge CPU-val (smips) rendelkeznek, és valószínűleg nem fognak megbirkózni az üzleti szegmens terhelésével.

Figyelem! Ennek a megoldásnak van egy hátránya: amikor a kliensek csatlakoznak vagy lekapcsolódnak, konfigurációs változások következnek be, amelyeket a router megpróbál elmenteni a nem felejtő memóriájába. Nagyszámú kliens és gyakori csatlakozások és megszakítások esetén ez az útválasztó belső tárhelyének romlásához vezethet.

PS: A kód klienshez történő eljuttatásának módszerei bővíthetők és kiegészíthetők, amennyiben a programozási képességei elegendőek. Például üzeneteket küldhet a táviratnak, vagy ... opciókat javasolhat!

Remélem, hogy a cikk hasznos lesz az Ön számára, és segít egy kicsit biztonságosabbá tenni a kis- és középvállalkozások hálózatát.

Forrás: will.com