Üdvözlet, kollégák! Ma, amikor a «távoli munkavégzés» körüli feszültségek kicsit alábbhagytak, a legtöbb adminisztrátor sikeresen megoldotta a munkatársak távoli hozzáférését a vállalati hálózathoz, elérkezett az idő, hogy megosszam régóta szorgalmazott megoldásomat a VPN biztonságának növelésére. Ebben a cikkben nem lesz szó a mostanában divatos IPSec IKEv2-ről és xAuth-ról. A téma a rendszer felépítése lesz VPN felhasználók számára, amikor a MikroTik működik VPN-szerverként. Nevezetesen, amikor „klasszikus” protokollokat, mint például a PPP-t használunk.
Ma elmondom, hogyan védhetjük meg a MikroTik PPP-VPN-t még akkor is, ha a felhasználói fiók „eltérítése” történik. Amikor ezt a megoldást bevezették egy ügyfelem számára, így jellemezte: „Nos, most tényleg olyan, mint egy bankban!”
A módszer nem használ külső hitelesítő szolgáltatásokat. A feladatokat magának az útválasztónak a belső eszközei végzik. Költség nélkül a csatlakozó kliens számára. A módszer PC-k és mobil eszközök számára is működik.
A védelem általános sémája a következőképpen néz ki:
- A VPN-szerverhez sikeresen csatlakozó felhasználó belső IP-címe automatikusan bekerül a „szürke” listába.
- A csatlakozás eseménye automatikusan generál egy egyszer használatos kódot, amelyet az egyik elérhető módon küldenek a felhasználónak.
- A listában található címek hozzáférése a helyi hálózat erőforrásaihoz korlátozott, kivéve az „ellenőrző” szolgáltatást, amely várja az egyszer használatos jelszó kódot.
- A kód bemutatása után a felhasználó hozzáférést kap a hálózat belső erőforrásaihoz.
Első A legkisebb probléma, amellyel szembesültem, a felhasználó elérhetőségi információinak tárolása volt az 2FA kód átküldésére. Mivel a MikroTik-ben nem hozhatók létre véletlenszerű adatformák, a meglévő „comment” mezőt használtuk:
/ppp secrets add name=Petrov password=4M@ngr! comment=«89876543210»
Második A probléma azonban komolyabbnak bizonyult – a kód átvitelének módjának és útvonalának megválasztása. Jelenleg három sémát valósítottunk meg: a) SMS USB-modemen keresztül b) e-mail c) SMS e-mailben, amely elérhető a piros mobilszolgáltató vállalati ügyfelei számára.
Igen, az SMS sémák költségekkel járnak. De ha jobban megvizsgáljuk, „a biztonság mindig a pénzről szól” (c).
Az e-mail alapú rendszer számomra nem tetszik. Nem azért, mert megköveteli a levelezőszerver elérhetőségét az azonosított kliens számára - ezt a forgalmat könnyen el lehet osztani. Azonban, ha a kliens gondatlanul mentette el a jelszavakat a VPN-en és az e-mailben a böngészőben, majd elveszítette a laptopját, a támadó teljes hozzáférést nyer a vállalati hálózathoz.
Tehát, el van döntve - egy egyszer használatos kódot küldünk SMS-üzenetben.
Harmadik probléma az volt, hogy hol és hogyan lehet MikroTikben véletlenszerű kódot generálni a 2FA-hoz.A RouterOS szkriptnyelve nem tartalmaz random() függvényt, és korábban láttam néhány kényszerített szkriptet véletlenszám-generátorokhoz. Egyik sem tetszett különböző okok miatt.
Valójában van véletlenszám-generátor MikroTikben! A felületes nézettől elrejtve a /certificates scep-server kontextusában. Első mód az egyszer használatos jelszó megszerzése könnyű és egyszerű - a parancs segítségével. /certificates scep-server otp generateHa egy egyszerű változóhozzárendelési műveletet végzünk, akkor egy array típusú értéket kapunk, amelyet később a szkriptekben felhasználhatunk.
Második módszer az egyszer használatos jelszó megszerzése, amely szintén könnyen alkalmazható - külső szolgáltatás használata a kívánt formájú véletlenszám-sorozat generálására. Íme egy egyszerűsített parancssori példa adatainak egy változóba való lekérésére:
Kód
:globális 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 konzolra formázott lekérdezés (a szkriptben speciális karakterek escape-elése szükséges) egy hatjegyű számjegyekből álló sort kap a $rnd1 változóba. A következő „put” parancs egyszerűen megjeleníti a változót a MikroTik konzolon.
Negyedik probléma, amelyet sürgősen meg kellett oldani - hogyan és hova fogja átadni a csatlakoztatott kliens az egyszer használatos kódját a második azonosítási szakaszban.
A MikroTik routeren egy szolgáltatásnak kell lennie, amely képes elfogadni a kódot, és azt hozzárendelni a konkrét klienshez. Ha a megadott kód egyezik a várt kóddal, az ügyfél címe egy úgynevezett „fehér” listára kerül, amelynek címei hozzáférést kaptak a vállalati belső hálózathoz.
Mivel a szolgáltatások választéka nem gazdag, döntés született arról, hogy a kódokat http-n keresztül a MikroTik-be épített webproxy segítségével fogadják. Mivel a tűzfal képes dinamikus IP cím listákkal dolgozni, a kód keresése, ügyfél IP-jével való összehasonlítása és a „fehér” listába való bekerülés a tűzfal feladatává válik, Layer7 regexp segítségével. A routernek egy feltételes DNS-nevet adtunk, „gw.local”, amelyen statikus A-bejegyzést hoztunk létre a PPP-ügyfelek számára:
DNS
/ip dns static add name=gw.local address=172.31.1.1
Proxy forgalom figyelése nem ellenőrzött ügyfelek esetében:
/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 proxy két funkciót lát el.
1. TCP kapcsolatok létesítése az ügyfelekkel;
2. Sikeres hitelesítés esetén az ügyfél böngészőjét átirányítja egy oldalra vagy képre, amely tájékoztat a hitelesítés sikeres lebonyolításáról:
Proxy konfiguráció
/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
Fontos konfigurációs elemeket sorolok fel:
- interface-list „2fa” — dinamikus lista az ügyfélinterfészekről, amelyek forgalma 2FA kezelésére szorul;
- address-list „2fa_jailed” — a VPN ügyfelek „szürke” IP cím lista;
- address_list „2fa_approved” — a VPN ügyfelek „fehér” IP cím lista, akik sikeresen teljesítették a kétfaktoros hitelesítést.
- tűzfalsorozat „input_2fa” — itt történik a TCP csomagok ellenőrzése a hitelesítési kód megléte és a kód küldésének IP címének szükséges értékkel való egyezés szempontjából. A szabályok dinamikusan kerülnek hozzáadásra és eltávolításra a sorozathoz.
Az egyszerűsített csomagkezelési folyamat a következőképpen néz ki:
A második hitelesítési lépést el nem végző ügyfelek „szürke” listás forgalmának Layer7 ellenőrzésbe való bekerüléséhez a standard „input” sorozatban egy szabályt hoztunk létre:
Kód
/ip firewall filter add chain=input !src-address-list=2fa_approved action=jump jump-target=input_2fa
Most kezdjük el összekapcsolni ezt a gazdagságot a PPP szolgáltatással. A MikroTik lehetővé teszi a szkriptek használatát a profilokban (ppp-profile), és ezek hozzárendelését a PPP kapcsolat létesítése és bontása eseményeihez. A ppp-profile beállításai alkalmazhatók a PPP szerverre összességében és egyedi felhasználókra is. Ugyanakkor a felhasználónak hozzárendelt profil prioritást élvez, felülbírálva a szerverre összességében vonatkozó profil beállításait.
Ennek a megközelítésnek köszönhetően külön profilt hozhatunk létre a kétfaktoros hitelesítéshez, és ezt nem minden felhasználónak, hanem csak azoknak a felhasználóknak rendelhetjük hozzá, akiket erre szükségesnek ítélünk. Ez releváns lehet, ha a PPP szolgáltatások nemcsak végfelhasználók kapcsolódására, hanem site-to-site kapcsolatok létrehozására is használatban vannak.
Az újonnan létrehozott speciális profilban dinamikusan hozzáadjuk a csatlakozó felhasználó címét és interfészét a "szürke" cím- és interfészlistákhoz:
winbox
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 "address-list" és "interface-list" listák együttes használatára van szükség, hogy meghatározzuk és elfogjuk a kétfaktoros hitelesítést még meg nem átugró VPN-kliens forgalmát a dstnat (prerouting) láncban.
Amikor a felkészülés befejeződött, és az extra tűzfal láncok valamint profil létrejöttek, írjunk egy szkriptet, amely a 2FA kód automatikus generálásáért és a tűzfal külön szabályaiért felelős.
a PPP-Profile információval lát el bennünket a PPP-kliens csatlakozási és bontási eseményeivel kapcsolatos változókról "Futtasd a szkriptet a felhasználói bejelentkezési eseményen. Az eseményszkripthez elérhető változók: user, local-address, remote-address, caller-id, called-id, interface". Néhány közülük nagyon hasznos lesz számunkra.
A profilban használt kód a PPP csatlakozási eseményhez on-up
#Логируем для отладки полученные переменные :log info ("helyi-cím")
:napló információ ("távoli-cím")
:napló információ ("hívó-azonosító")
:napló információ ("hívott-azonosító")
:napló információ ([/int pptp-server get ("felszerelés") neve])
#Объявляем свои локальные переменные
:helyi listanév "2fa_letiltott"
:helyi viamodem hamis
:helyi modemport "usb2"
#ищем автоматически созданную запись в адрес-листе "2fa_jailed"
:helyi recnum1 [/ip fi address-list find address=("távoli-cím") lista=$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
:helyi vphone [/ppp secret get [find name=$user] comment]#Готовим тело сообщения. Если клиент подключается к VPN прямо с телефона ему достаточно
#будет перейти прямо по ссылке из полученного сообщения
:helyi msgboby ("A kódod: ".$comm1."n Vagy nyisd meg a linket http://gw.local/otp/".$comm1."/")# Отправляем SMS по выбранному каналу - USB-модем или email-to-sms
ha $viamodem do={
/tool sms send phone-number=$vphone message=$msgboby port=$modemport }
különben={
/tool e-mail send server=a.b.c.d from=admin@mydomain.example to=mail2sms@mcommunicator.ru subject="@".$vphone body=$msgboby }#Генерируем Layer7 regexp
helyi vregexp ("otp\/".$comm1)
:helyi vcomment ("2fa_".("távoli-cím"))
/ip firewall layer7-protocol add name=("vcomment") komment=(
"távoli-cím") regexp=(
"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=("vcomment") protokoll=tcp src-cím=(
"távoli-cím") dst-limit=1,1,src-cím/1m40s
Külön figyelmeztetem azokat, akik gondolkodás nélkül másolják a kódot — a kód egy tesztverzióból származik és lehet, hogy apró hibákat tartalmaz. Ahol pontosan, az egy értő számára nem okoz nehézséget.A felhasználó lekapcsolásakor "On-Down" esemény generálódik, és a megfelelő szkript hívódik meg a paraméterekkel. Ennek a szkriptnek a feladata, hogy eltávolítsa a lekapcsolt felhasználóhoz készült tűzfalszabályokat.
A profilban használt kód a PPP lekapcsolási eseményhez on-down
:helyi vcomment ("2fa_".("távoli-cím"))
/ip firewall address-list remove [find address=("remote-address") list=2fa_approved]
/ip firewall filter remove [find chain="input_2fa" src-address=("remote-address") ]
/ip firewall layer7-protocol remove [find name=$vcomment]
Ezt követően felhasználókat lehet létrehozni, és a kétfaktoros hitelesítéssel rendelkező profilt minden felhasználónak vagy csak néhányuknak hozzárendelni.winbox
Kód
/ppp secrets set [find name=Petrov] profile=2FAHogyan néz ki ez az ügyfél oldalán.
VPN-kapcsolat létesítésekor a telefonra / táblagépre Android / iOS rendszerre SIM-kártyával érkező SMS körülbelül így néz ki:
SMS
Ha a kapcsolat közvetlenül a telefonról / táblagépről történik, akkor a 2FA-t egyszerűen az üzenetben található linkre kattintva teljesíthetjük. Ez kényelmes.
Ha a VPN kapcsolat PC-vel történik, akkor a felhasználónak minimális jelszóbeviteli forma szükséges. Egy kis űrlap HTML fájl formájában kerül átadásra a felhasználónak a VPN beállításakor. A fájlt akár e-mailben is elküldheti, hogy a felhasználó elmentse, és kényelmes helyen parancsikont készítsen belőle. Körülbelül így néz ki:
Parancsikon az asztalon
A felhasználó rákattint a parancsikonra, megnyílik egy egyszerű kódbeviteli forma, amely beilleszti a kódot a megnyíló URL-be:
Űrlap képernyőképe
Az űrlap a legegyszerűbb, példa céljából készült. Aki szeretné, továbbfejlesztheti saját igényei szerint.
2fa_login_mini.html
<html> <head> <title>SMS OTP bejelentkezés</title> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> </head> <body> <form name="login" action="/hu/location.href='http://gw.local/otp/'+document.getElementById(‘text').value/" method="post" <input id="text" type="text" data-trp-original-action="location.href='http://gw.local/otp/'+document.getElementById(‘text').value"/><input type="hidden" name="trp-form-language" value="hu"/> <input type="button" value="Bejelentkezés" onclick="location.href='http://gw.local/otp/'+document.getElementById('text').value"/> </form> </body> </html>Ha a hitelesítés sikeresen lezajlott, a felhasználó a böngészőben meg fogja látni a MikroTik logóját, ami jelzi a sikeres azonosítást:
Megjegyzem, hogy a kép a MikroTik beépített webkiszolgálójából érkezik a WebProxy Deny Redirect segítségével.
Úgy gondolom, a képet testreszabhatjuk a „hotspot” eszköz használatával, feltölthetjük oda a saját verziónkat, és megadhatjuk a Deny Redirect URL-t a WebProxy-val.
Nagy kérés azokhoz, akik a lehető legolcsóbb "játékszerű" MikroTik-et vásárolják 20 dollárért, hogy ne próbáljanak vele 500 dolláros útválasztót helyettesíteni — ne csináljátok ezt. Az olyan eszközök, mint a „hAP Lite”/„hAP mini” (otthoni hozzáférési pont) nagyon gyenge CPU-val (smips) rendelkeznek, ami miatt valószínűleg nem bírják el a terhelést az üzleti szegmensben.
Figyelmeztetés! Ennek a megoldásnak van egy hátránya: a kliensek csatlakozása és bontása során változások történnek a konfigurációban, amelyet az útválasztó megpróbál megőrizni az energiatakarékos memóriájában. Nagy számú kliens és gyakori csatlakozások bontása esetén ez a belső tároló degressziójához vezethet az útválasztóban.
P.S.: a kód klienshez történő kézbesítési módszerei a programozási lehetőségeidnek megfelelően bővíthetők és kiegészíthetők. Például küldhetsz üzeneteket a Telegramra, vagy… ajánljatok lehetőségeket!
Remélem, hogy a cikk hasznos lesz számodra, és segít az olyan kkv-k hálózatainak még biztonságosabbá tételében.
Forrás: habr.com
