Hola companys! Avui, quan la intensitat de les passions al voltant del "treball remot" va disminuir una mica, la majoria dels administradors van guanyar la tasca d'accés remot dels empleats a la xarxa corporativa, és hora de compartir la meva llarga experiència en la millora de la seguretat VPN. Aquest article no estarà de moda ara IPSec IKEv2 i xAuth. Es tracta de construir un sistema. Usuaris VPN quan MikroTik actua com a servidor VPN. És a dir, quan s'utilitzen protocols "clàssics" com el PPP.
Avui us explicaré com protegir MikroTik PPP-VPN encara que el compte d'usuari estigui "segrestat". Quan es va presentar aquest esquema a un dels meus clients, el va descriure breument com "bé, ara és com en un banc!".
El mètode no utilitza serveis d'autenticació externs. Les tasques les realitza internament el mateix encaminador. Sense cost per al client connectat. El mètode funciona tant per a clients de PC com per a dispositius mòbils.
El règim general de protecció és el següent:
- L'adreça IP interna d'un usuari que s'ha connectat correctament al servidor VPN apareix automàticament a la llista grisa.
- L'esdeveniment de connexió genera automàticament un codi únic que s'envia a l'usuari mitjançant un dels mètodes disponibles.
- Les adreces d'aquesta llista tenen accés limitat als recursos de la xarxa local, a excepció del servei "autenticador", que està esperant rebre una contrasenya única.
- Després de presentar el codi, l'usuari té accés als recursos interns de la xarxa.
La primera el problema més petit que vaig haver d'enfrontar va ser emmagatzemar informació de contacte sobre l'usuari per enviar-li el codi 2FA. Com que és impossible crear camps de dades arbitraris corresponents als usuaris a Mikrotik, es va utilitzar el camp "comentari" existent:
/ppp secrets add name=contrasenya Petrov=4M@ngr! comment="89876543210"
El segon el problema va resultar més greu: l'elecció del camí i el mètode de lliurament del codi. Actualment estan implementats tres esquemes: a) SMS via mòdem USB b) correu electrònic c) SMS via e-mail disponible per als clients corporatius de l'operador de telefonia mòbil vermella.
Sí, els esquemes de SMS comporten costos. Però si us fixeu, "la seguretat sempre és qüestió de diners" (c).
A mi personalment no m'agrada l'esquema amb el correu electrònic. No perquè requereixi que el servidor de correu estigui disponible per al client que s'autentica; no és un problema dividir el trànsit. Tanmateix, si un client desa descuidadament les contrasenyes de VPN i de correu electrònic en un navegador i després perdia el seu ordinador portàtil, l'atacant obtindria accés complet a la xarxa corporativa des d'aquest.
Per tant, s'ha decidit: entreguem un codi únic mitjançant missatges SMS.
La tercera El problema era on com generar un codi pseudoaleatori per a 2FA a MikroTik. No hi ha cap anàleg de la funció random() al llenguatge de script RouterOS, i abans he vist diversos generadors de nombres pseudoaleatoris de script de crossa. No em va agradar cap d'ells per diferents motius.
De fet, hi ha un generador de seqüències pseudoaleatòries a MikroTik! S'amaga a una mirada superficial en el context de /certificats scep-server. La primera manera obtenir una contrasenya única és fàcil i senzill, amb l'ordre /certificats scep-server otp generate. Si realitzem una simple operació d'assignació de variables, obtindrem un valor de matriu que es pot utilitzar més endavant en els scripts.
La segona manera obtenir una contrasenya única que també és fàcil d'aplicar mitjançant un servei extern per generar el tipus desitjat de seqüència de nombres pseudoaleatoris. Aquí hi ha un simplificat cantilever exemple d'aconseguir dades en una variable:
Codi
: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
Una sol·licitud formatada per a la consola (es necessitaran caràcters especials d'escapament al cos de l'script) rep una cadena de sis dígits a la variable $rnd1. La següent comanda "posar" només mostra la variable a la consola MikroTik.
El quart problema que s'havia de resoldre ràpidament: així és com i on el client connectat transferirà el seu codi únic en la segona etapa d'autenticació.
Hi ha d'haver un servei al router MikroTik que pugui acceptar el codi i relacionar-lo amb un client específic. Si el codi proporcionat coincideix amb l'esperat, l'adreça del client s'ha d'incloure en una llista "blanca" determinada, adreces des de les quals es permet l'accés a la xarxa interna de l'empresa.
A causa de la mala selecció de serveis, es va decidir acceptar codis via http mitjançant el webproxy integrat a Mikrotik. I com que el tallafoc pot funcionar amb llistes dinàmiques d'adreces IP, és el tallafoc qui realitza la cerca del codi, fent-lo coincidir amb la IP del client i afegint-lo a la llista "blanca" mitjançant l'expressió regular de Layer7. Al mateix encaminador se li ha assignat un nom DNS condicional "gw.local", s'ha creat un registre A estàtic per a l'emissió als clients PPP:
DNS
/ip dns static add name=gw.local address=172.31.1.1
Captura del trànsit de clients no verificats al servidor intermediari:
/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
En aquest cas, el proxy té dues funcions.
1. Obriu connexions tcp amb clients;
2. En cas d'autorització correcta, redirigeix el navegador del client a una pàgina o imatge que notifiqui sobre l'autenticació correcta:
Configuració del servidor intermediari
/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
Enumeré els elements de configuració importants:
- interface-list "2fa" - una llista dinàmica d'interfícies de client, el trànsit de la qual requereix processament dins de 2FA;
- address-list "2fa_jailed" - llista "grisa" d'adreces IP del túnel dels clients VPN;
- address_list "2fa_approved" - llista "blanca" d'adreces IP de túnel de clients VPN que han superat correctament l'autenticació de dos factors.
- cadena de tallafocs "input_2fa": comprova la presència d'un codi d'autorització dels paquets tcp i fa coincidir l'adreça IP del remitent del codi amb la necessària. Les regles de la cadena s'afegeixen i s'eliminen de forma dinàmica.
Un diagrama de flux simplificat del processament de paquets té aquest aspecte:
Per entrar a la comprovació de trànsit de la capa 7 dels clients de la llista "grisa" que encara no han passat la segona etapa d'autenticació, s'ha creat una regla a la cadena estàndard "d'entrada":
Codi
/ip firewall filter add chain=input !src-address-list=2fa_approved action=jump jump-target=input_2fa
Ara comencem a subjectar tota aquesta riquesa al servei PPP. MikroTik us permet utilitzar scripts als perfils (ppp-profile) i assignar-los als esdeveniments d'establir i trencar una connexió ppp. La configuració del perfil ppp es pot aplicar al servidor PPP en conjunt o a usuaris individuals. Al mateix temps, el perfil assignat a l'usuari té prioritat, anul·lant els paràmetres del perfil seleccionat per al conjunt del servidor amb els seus paràmetres especificats.
Com a resultat d'aquest enfocament, podem crear un perfil especial per a l'autenticació de dos factors i assignar-lo no a tots els usuaris, sinó només a aquells que ho consideren necessari. Això pot ser rellevant si utilitzeu serveis PPP no només per connectar usuaris finals, sinó també per crear connexions de lloc a lloc.
Al perfil especial de nova creació, utilitzem l'addició dinàmica de l'adreça i la interfície de l'usuari connectat a les llistes "grises" d'adreces i interfícies:
winbox
Codi
/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
Cal utilitzar tant llistes de "llista d'adreces" com de "llista d'interfícies" per detectar i capturar trànsit de clients VPN no secundaris a la cadena dstnat (preencaminament).
Quan s'hagi completat la preparació, es creen cadenes de tallafocs addicionals i un perfil, escriurem un script responsable de la generació automàtica del codi 2FA i les regles del tallafoc individuals.
a PPP-Profile ens enriqueix amb informació sobre variables associades als esdeveniments de connexió i desconnexió del client PPP "Executeu l'script a l'esdeveniment d'inici de sessió de l'usuari. Aquestes són variables disponibles que són accessibles per a l'script d'esdeveniment: usuari, adreça local, adreça remota, identificador de trucada, identificador de trucada, interfície". Alguns d'ells ens són molt útils.
Codi utilitzat al perfil per a l'esdeveniment de connexió activada PPP
#Логируем для отладки полученные переменные :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
Especialment per a aquells a qui els agrada copiar i enganxar sense pensar, us adverteixo: el codi s'ha extret de la versió de prova i pot contenir petites errades d'ortografia. No serà difícil per a una persona comprensiva esbrinar exactament on.Quan un usuari es desconnecta, es genera un esdeveniment "On-Down" i es crida l'script corresponent amb paràmetres. L'objectiu d'aquest script és netejar les regles del tallafoc creades per a l'usuari desconnectat.
Codi utilitzat al perfil per a l'esdeveniment de connexió PPP on-down
: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]
A continuació, podeu crear usuaris i assignar-los tots o alguns a un perfil d'autenticació de dos factors.winbox
Codi
/ppp secrets set [find name=Petrov] profile=2FACom es veu al costat del client.
Quan s'estableix una connexió VPN, un telèfon o tauleta Android/iOS amb una targeta SIM rep un SMS com aquest:
SMS
Si la connexió s'estableix directament des del telèfon / tauleta, podeu passar per 2FA simplement fent clic a l'enllaç del missatge. És còmode.
Si la connexió VPN s'estableix des d'un ordinador, l'usuari haurà d'introduir un formulari de contrasenya mínima. Un petit formulari en forma d'arxiu HTML es lliura a l'usuari quan configura la VPN. El fitxer fins i tot es pot enviar per correu perquè l'usuari el desi i creï una drecera en un lloc convenient. Es veu així:
Etiqueta a la taula
L'usuari fa clic a la drecera, s'obre un formulari d'entrada de codi senzill, que enganxarà el codi a l'URL obert:
Formulari de pantalla
La forma més primitiva es posa com a exemple. Qui ho desitgi es pot modificar per si mateix.
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>Si l'autorització ha tingut èxit, l'usuari veurà el logotip de MikroTik al navegador, que hauria d'indicar l'autenticació correcta:
Tingueu en compte que la imatge es retorna des del servidor web integrat de MikroTik mitjançant WebProxy Deny Redirect.
Suposo que la imatge es pot personalitzar amb l'eina "hotspot", penjant-hi la vostra pròpia versió i establint-hi l'URL de redirecció denegada amb WebProxy.
Una gran sol·licitud per a aquells que intenten comprar la "joguina" Mikrotik més barata per 20 dòlars i substituir-ne un encaminador de 500 dòlars; no ho feu. Dispositius com "hAP Lite" / "hAP mini" (punt d'accés domèstic) tenen una CPU molt feble (smips) i és probable que no facin front a la càrrega del segment empresarial.
Advertència Aquesta solució té un inconvenient: quan els clients es connecten o es desconnecten, es produeixen canvis de configuració, que l'encaminador intenta desar a la seva memòria no volàtil. Amb un gran nombre de clients i connexions i desconnexions freqüents, això pot provocar una degradació de l'emmagatzematge intern del router.
PD: Els mètodes per lliurar codi al client es poden ampliar i complementar en la mesura que les vostres capacitats de programació siguin suficients. Per exemple, podeu enviar missatges a telegram o... suggerir opcions!
Espero que l'article us sigui útil i ajudi a fer una mica més segures les xarxes de petites i mitjanes empreses.
Font: www.habr.com