Saluton kolegoj! Hodiaŭ, kiam la intenseco de pasioj ĉirkaŭ "remota laboro" iomete malpliiĝis, la plimulto de administrantoj gajnis la taskon de fora aliro de dungitoj al la kompania reto, estas tempo dividi mian longdaŭran sperton pri plibonigo de VPN-sekureco. Ĉi tiu artikolo ne estos moda nun IPSec IKEv2 kaj xAuth. Temas pri konstruado de sistemo. VPN-uzantoj kiam MikroTik funkcias kiel VPN-servilo. Nome, kiam estas uzataj "klasikaj" protokoloj kiel PPP.
Hodiaŭ mi rakontos al vi kiel protekti MikroTik PPP-VPN eĉ se la uzantkonto estas "kaptita". Kiam ĉi tiu skemo estis prezentita al unu el miaj klientoj, li mallonge priskribis ĝin kiel "nu, nun ĝi estas same kiel en banko!".
La metodo ne uzas eksterajn aŭtentikilservojn. La taskoj estas faritaj interne de la enkursigilo mem. Neniu kosto por la konekta kliento. La metodo funkcias kaj por komputilaj klientoj kaj por porteblaj aparatoj.
La ĝenerala protektoskemo estas kiel sekvas:
- La interna IP-adreso de uzanto, kiu sukcese konektiĝis al la VPN-servilo, estas aŭtomate griza listo.
- La koneksa evento aŭtomate generas unufojan kodon, kiu estas sendita al la uzanto per unu el la disponeblaj metodoj.
- Adresoj en ĉi tiu listo havas limigitan aliron al lokaj retaj rimedoj, escepte de la servo "aŭtentikigilo", kiu atendas ricevi unufojan paskodon.
- Post prezento de la kodo, la uzanto havas aliron al la internaj rimedoj de la reto.
La unua la plej malgranda problemo, kiun mi devis alfronti, estis konservi kontaktinformojn pri la uzanto por sendi al li la 2FA-kodon. Ĉar estas neeble krei arbitrajn datumkampojn respondajn al uzantoj en Mikrotik, la ekzistanta "komento" kampo estis uzata:
/ppp secrets add name=Petrov-pasvorto=4M@ngr! komento="89876543210"
La dua la problemo montriĝis pli serioza - la elekto de la vojo kaj metodo de liverado de la kodo. Tri skemoj estas nuntempe efektivigitaj: a) SMS per USB-modemo b) retpoŝto c) SMS per retpoŝto disponebla por kompaniaj klientoj de la ruĝa ĉela funkciigisto.
Jes, SMS-skemoj alportas kostojn. Sed se vi rigardas, "sekureco ĉiam temas pri mono" (c).
Mi persone ne ŝatas la skemon kun retpoŝto. Ne ĉar ĝi postulas, ke la poŝtservilo estu disponebla por la aŭtentikigita kliento - ne estas problemo dividi la trafikon. Tamen, se kliento senzorge konservis kaj vpn kaj retpoŝtajn pasvortojn en retumilo kaj poste perdus sian tekkomputilon, la atakanto akirus plenan aliron al la kompania reto de ĝi.
Do, estas decidite - ni liveras unufojan kodon per SMS-mesaĝoj.
La tria La problemo estis kie kiel generi pseŭdo-hazardan kodon por 2FA en MikroTik. Ne ekzistas analogo de la random() funkcio en la skriptlingvo RouterOS, kaj mi antaŭe vidis plurajn lambastonajn skriptajn pseŭdo-hazardajn nombrogenerantojn. Mi ŝatis neniun el ili pro diversaj kialoj.
Fakte, ekzistas pseŭdo-hazarda sekvencogeneratoro en MikroTik! Ĝi estas kaŝita de supraĵa rigardo en la kunteksto de /certificates scep-server. La unua vojo ricevi unufojan pasvorton estas facila kaj simpla - kun la komando /certificates scep-server otp generi. Se ni plenumas simplan varian asigno-operacion, ni ricevos tabelan valoron, kiu povas esti uzata poste en skriptoj.
Dua vojo akiri unufojan pasvorton, kiu ankaŭ estas facile apliki - uzante eksteran servon por generi la deziratan specon de sekvenco de pseŭdo-hazardaj nombroj. Jen simpligita kantilevered ekzemplo de ricevado de datumoj en variablon:
Kodo
: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
Peto formatita por la konzolo (eskapado de specialaj signoj estos postulata en la skriptokorpo) ricevas ĉenon de ses ciferoj en la variablo $rnd1. La sekva "metu" komando simple montras la variablon en la MikroTik-konzolo.
La kvara problemo kiu devis esti rapide solvita - jen kiel kaj kie la konektita kliento transdonos sian unufojan kodon en la dua etapo de aŭtentigo.
Devas ekzisti servo sur la MikroTik-enkursigilo, kiu povas akcepti la kodon kaj kongrui ĝin kun specifa kliento. Se la provizita kodo kongruas kun la atendita, la adreso de la kliento estu inkluzivita en certa "blanka" listo, el kiuj adresoj estas permesitaj aliro al la interna reto de la firmao.
Pro la malbona elekto de servoj, estis decidite akcepti kodojn per http uzante la retproxy enkonstruitan en Mikrotik. Kaj ĉar la fajroŝirmilo povas funkcii kun dinamikaj listoj de IP-adresoj, ĝi estas la fajroŝirmilo kiu faras la serĉon por la kodo, kongruante ĝin kun la kliento IP kaj aldonante ĝin al la "blanka" listo uzante Layer7 regexp. La enkursigilo mem ricevis kondiĉan DNS-nomon "gw.local", statika A-rekordo estis kreita sur ĝi por eldonado al PPP-klientoj:
DNS
/ip dns static add name=gw.local address=172.31.1.1
Kaptante trafikon de nekontrolitaj klientoj sur la prokurilo:
/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 ĉi tiu kazo, la prokurilo havas du funkciojn.
1. Malfermu tcp-konektojn kun klientoj;
2. En kazo de sukcesa rajtigo, alidirektu la klientan retumilon al paĝo aŭ bildo sciiganta pri sukcesa aŭtentigo:
Prokura agordo
/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
Mi listigos la gravajn agordajn elementojn:
- interface-list "2fa" - dinamika listo de klientinterfacoj, de kiu trafiko postulas prilaboradon ene de 2FA;
- address-list "2fa_jailed" - "griza" listo de tunelaj IP-adresoj de VPN-klientoj;
- address_list "2fa_approved" - "blanka" listo de tunelaj IP-adresoj de VPN-klientoj, kiuj sukcese trapasis dufaktoran aŭtentikigon.
- fajroŝirmilo ĉeno "input_2fa" - ĝi kontrolas tcp-pakojn por la ĉeesto de rajtiga kodo kaj kongruas la IP-adreson de la kodsendanto kun la postulata. Reguloj en la ĉeno estas aldonitaj kaj forigitaj dinamike.
Simpligita fludiagramo de paka pretigo aspektas jene:
Por eniri la Layer7-kontrolon de trafiko de klientoj de la "griza" listo, kiuj ankoraŭ ne pasis la duan etapon de aŭtentikigo, regulo estis kreita en la norma "eniga" ĉeno:
Kodo
/ip firewall filter add chain=input !src-address-list=2fa_approved action=jump jump-target=input_2fa
Nun ni komencu ligi ĉi tiun tutan riĉaĵon al la PPP-servo. MikroTik permesas vin uzi skriptojn en profiloj (ppp-profile) kaj asigni ilin al la eventoj establi kaj rompi ppp-konekton. La ppp-profilaj agordoj povas esti aplikitaj al la PPP-servilo kiel tutaĵo aŭ al individuaj uzantoj. Samtempe, la profilo asignita al la uzanto havas prioritaton, superregante la parametrojn de la profilo elektita por la servilo entute kun ĝiaj specifitaj parametroj.
Kiel rezulto de ĉi tiu aliro, ni povas krei specialan profilon por dufaktora aŭtentigo kaj atribui ĝin ne al ĉiuj uzantoj, sed nur al tiuj, kiuj opinias necesa fari tion. Ĉi tio povas esti grava se vi uzas PPP-servojn ne nur por konekti finajn uzantojn, sed samtempe por konstrui ejon-al-ejan konektojn.
En la lastatempe kreita speciala profilo, ni uzas la dinamikan aldonon de la adreso kaj interfaco de la konektita uzanto al la "grizaj" listoj de adresoj kaj interfacoj:
winbox
Kodo
/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
Necesas uzi kaj listojn de "adreslisto" kaj de "interfaco-listo" por detekti kaj kapti trafikon de ne-sekundaraj VPN-klientoj en la dstnat (prerouting) ĉeno.
Kiam la preparado finiĝos, kreiĝas pliaj fajroŝirmilaj ĉenoj kaj profilo, ni skribos skripton respondecan pri aŭtomata generacio de la 2FA-kodo kaj individuaj fajroŝirmilaj reguloj.
sur PPP-Profilo riĉigas nin per informoj pri variabloj asociitaj kun eventoj de konekti-malkonekti kliento de PPP "Efektivigu skripton ĉe uzanto-ensaluto-evento. Ĉi tiuj estas disponeblaj variabloj, kiuj estas alireblaj por la okazaĵa skripto: uzanto, loka-adreso, malproksima-adreso, alvokanto, vokita-id, interfaco". Kelkaj el ili estas tre utilaj al ni.
Kodo uzata en profilo por PPP sur-supren konekto-evento
#Логируем для отладки полученные переменные :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
Precipe por tiuj, kiuj ŝatas senpripense kopii-alglui, mi avertas vin - la kodo estas prenita el la testa versio kaj povas enhavi etajn tajperarojn. Ne estos malfacile por komprenema homo eltrovi ĝuste kie.Kiam uzanto malkonektas, evento "On-Down" estas generita kaj la responda skripto kun parametroj estas vokita. La celo de ĉi tiu skripto estas purigi la fajroŝirmigajn regulojn kreitajn por la malkonektita uzanto.
Kodo uzata en profilo por PPP-malsupren-rilata evento
: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]
Vi tiam povas krei uzantojn kaj asigni ĉiujn aŭ iujn el ili al dufaktora aŭtentikiga profilo.winbox
Kodo
/ppp secrets set [find name=Petrov] profile=2FAKiel ĝi aspektas ĉe la klienta flanko.
Kiam VPN-konekto estas establita, Android/iOS-telefono/tablojdo kun SIM-karto ricevas SMS kiel ĉi tio:
SMS
Se la konekto estas establita rekte de la telefono / tablojdo, tiam vi povas trairi 2FA simple alklakante la ligilon de la mesaĝo. Estas komforta.
Se la VPN-konekto estas establita de komputilo, tiam la uzanto devos enigi minimuman pasvortformularon. Malgranda formo en formo de HTML-dosiero estas donita al la uzanto dum agordo de la VPN. La dosiero eĉ povas esti sendita per poŝto, por ke la uzanto konservu ĝin kaj kreu ŝparvojon en oportuna loko. Ĝi aspektas jene:
Etikedo sur la tablo
La uzanto klakas sur la ŝparvojo, malfermiĝas simpla koda eniga formularo, kiu algluos la kodon en la malfermitan URL:
Ekranformo
La plej primitiva formo estas donita kiel ekzemplo. Tiuj, kiuj deziras, povas modifi por si mem.
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>Se la rajtigo sukcesis, la uzanto vidos la MikroTik-emblemon en la retumilo, kiu devus signali sukcesan aŭtentikigon:
Notu, ke la bildo estas resendita de la enkonstruita retservilo MikroTik uzante WebProxy Deny Redirect.
Mi supozas, ke la bildo povas esti personecigita per la "hotspot" ilo, alŝutante vian propran version tie kaj fiksante la Deny Redirect URL al ĝi kun WebProxy.
Granda peto al tiuj, kiuj provas aĉeti la plej malmultekostan "ludilon" Mikrotik por $20 kaj anstataŭigi $500-enkursigilon per ĝi - ne faru tion. Aparatoj kiel "hAP Lite" / "hAP mini" (hejma alirpunkto) havas tre malfortan CPU (smips), kaj verŝajne ili ne traktos la ŝarĝon en la komerca segmento.
Averto! Ĉi tiu solvo havas unu malavantaĝon: kiam klientoj konektas aŭ malkonektas, okazas agordaj ŝanĝoj, kiujn la enkursigilo provas konservi en sia nevolatila memoro. Kun granda nombro da klientoj kaj oftaj konektoj kaj malkonektiĝoj, ĉi tio povas konduki al degenero de la interna stokado en la enkursigilo.
PS: Metodoj por liveri kodon al la kliento povas esti vastigitaj kaj kompletigitaj tiom kiom viaj programaj kapabloj sufiĉas. Ekzemple, vi povas sendi mesaĝojn al telegramo aŭ ... sugesti opciojn!
Mi esperas, ke la artikolo estos utila al vi kaj helpos iom pli sekurigi la retojn de malgrandaj kaj mezgrandaj entreprenoj.
fonto: www.habr.com