Hallo collega's! Nu de passie rond "thuiswerken" wat is afgenomen en de meeste beheerders de uitdaging van de afstandstoegang van medewerkers tot het bedrijfsnetwerk hebben overwonnen, is het tijd om mijn langeverworpen methode voor het verhogen van de VPN-beveiliging te delen. In dit artikel zullen de trendy IPSec IKEv2 en xAuth niet aan bod komen. We zullen het hebben over het opzetten van een systeem voor VPN-gebruikers, waarbij MikroTik fungeert als VPN-server. Dit betekent dat "klassieke" protocollen zoals PPP worden gebruikt.
Vandaag zal ik uitleggen hoe je MikroTik PPP-VPN kunt beveiligen, zelfs in het geval van "diefstal" van gebruikersaccounts. Toen deze regeling werd geïmplementeerd voor een van mijn klanten, omschreef hij het kort als: "Nou, nu is het net als in de bank!"
De methode maakt geen gebruik van externe authenticator-diensten. De taken worden uitgevoerd met de interne middelen van de router zelf. Zonder kosten voor de verbonden klant. De methode werkt zowel voor pc-klanten als voor mobiele apparaten.
Het algemene beveiligingssysteem ziet er als volgt uit:
- Het interne IP-adres van een gebruiker die succesvol met de VPN-server is verbonden, wordt automatisch op de "grijze" lijst geplaatst.
- Het verbindingsgebeurtenis genereert automatisch een eenmalige code die op één van de beschikbare manieren naar de gebruiker wordt verzonden.
- Adressen op deze lijst hebben beperkte toegang tot middelen van het lokale netwerk, met uitzondering van de "authenticator"-service, die wacht op ontvangst van de eenmalige code-wachtwoord.
- Na indiening van de code krijgt de gebruiker toegang tot de interne bronnen van het netwerk.
Eerste het kleinste probleem waarmee we werden geconfronteerd, was het opslaan van contactinformatie van de gebruiker om de 2FA-code naar hem te verzenden. Aangezien er geen willekeurige gegevensvelden konden worden gemaakt die overeenkomen met gebruikers in MikroTik, werd het bestaande veld "comment" gebruikt:
/ppp secrets add name=Petrov password=4M@ngr! comment=«89876543210»
Tweede het probleem bleek serieuzer — het kiezen van de manier en het pad voor het verzenden van de code. Op dit moment zijn er drie systemen geïmplementeerd: a) SMS via een USB-modem b) e-mail c) SMS via e-mail beschikbaar voor zakelijke klanten van de rode mobiele operator.
Ja, SMS-systemen brengen kosten met zich mee. Maar als je erover nadenkt, "veiligheid gaat altijd over geld" (c).
Het e-mail schema spreekt me persoonlijk niet aan. Niet omdat het vereist dat de mailserver beschikbaar is voor de geauthentiseerde client - dit is geen probleem om het verkeer te splitsen. Echter, als de client onoplettend zijn wachtwoorden voor zowel de VPN als de mail in de browser heeft opgeslagen en vervolgens zijn laptop verliest, krijgt de aanvaller volledige toegang tot het bedrijfsnetwerk.
Dus, het is besloten - we leveren de eenmalige code via sms-berichten.
Derde het probleem was waar en hoe je een pseudowillekeurige code voor 2FA genereert in MikroTik. In de script-taal van RouterOS is er geen overeenkomstige random() functie en eerder heb ik verschillende tijdelijke scriptgenerators voor pseudowillekeurige getallen gezien. Geen van deze sprak me om verschillende redenen aan.
In feite is er een generator voor pseudowillekeurige reeksen in MikroTik! Het is verborgen voor oppervlakkige blikken in de context van /certificates scep-server. De eerste manier om een eenmalig wachtwoord te verkrijgen is eenvoudig en gemakkelijk - met de command. /certificates scep-server otp generateAls je een eenvoudige toewijzing van een variabele uitvoert, krijgen we een array-type waarde die we later in scripts kunnen gebruiken.
De tweede manier om een eenmalig wachtwoord te verkrijgen dat ook gemakkelijk te gebruiken is - is het gebruik van een externe dienst voor het genereren van de gewenste reeks pseudowillekeurige getallen. Hier is een vereenvoudigd console voorbeeld van het verkrijgen van gegevens in een variabele:
Code
: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
De aanvraag is geformatteerd voor de console (in de script body moeten speciale tekens worden geëscaleerd) en krijgt een string van zes cijfers in de variabele $rnd1. Het volgende commando 'put' toont simpelweg de variabele in de MikroTik-console.
Het vierde probleem, dat we snel moesten oplossen - was hoe en waar de aangesloten client zijn eenmalige code zal doorgeven in de tweede fase van de authenticatie.
Op de MikroTik-router moet er een service zijn die in staat is om de code te ontvangen en deze aan de specifieke client te koppelen. Bij een overeenkomst tussen de opgegeven code en de verwachte, moet het adres van de client in een soort 'witte' lijst komen, waarvan de adressen toegang hebben tot het interne netwerk van het bedrijf.
Vanwege de beperkte keuze aan diensten is besloten om codes via http te accepteren met behulp van de ingebouwde webproxy in MikroTik. Aangezien de firewall kan werken met dynamische IP-adressenlijsten, wordt de code opgezocht, vergeleken met het IP-adres van de klant en toegevoegd aan de "witte" lijst door de firewall met behulp van Layer7 regexp. De router zelf heeft de geconditioneerde DNS-naam "gw.local" gekregen, waarop een statische A-record is aangemaakt voor PPP-klanten:
DNS
/ip dns static add name=gw.local address=172.31.1.1
Capturing proxy verkeer van niet-gecontroleerde klanten:
/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
In dit geval heeft de proxy twee functies.
1. TCP-verbindingen maken met klanten;
2. Bij succesvolle autorisatie de browser van de klant doorverwijzen naar een pagina of afbeelding die meldt dat de authenticatie succesvol is verlopen:
Proxy-configuratie
/ip proxy
zet ingeschakeld=yes poort=3128
/ip proxy access
voeg actie=weigeren uitgeschakeld=nee omleiden-naar=gw.local./mikrotik_logo.png src-adres=0.0.0.0/0
Belangrijke configuratie-elementen zijn:
- interface-list "2fa" — een dynamische lijst van klantinterfaces waarvan het verkeer moet worden verwerkt binnen 2FA;
- address-list "2fa_jailed" — een "grijze" lijst van tunneling IP-adressen van VPN-klanten;
- address_list "2fa_approved" — een "witte" lijst van tunneling IP-adressen van VPN-klanten die succesvol de tweefactorauthenticatie hebben doorlopen.
- de firewall-chain "input_2fa" — hierin vindt de controle van tcp-pakketten plaats op de aanwezigheid van een autorisatiecode en de overeenkomst van het IP-adres van de afzender van de code met het vereiste. Regels worden dynamisch aan de keten toegevoegd en verwijderd.
Een vereenvoudigd blokdiagram van de pakketverwerking ziet er als volgt uit:
Om pass-through voor Layer7-verkeer van klanten uit de "grijze" lijst die de tweede stap van authenticatie nog niet hebben doorlopen mogelijk te maken, is in de standaard "input"-keten een regel aangemaakt:
Code
/ip firewall filter add chain=input !src-address-list=2fa_goedgekeurd action=jump jump-target=input_2fa
Laten we nu al deze functionaliteit aansluiten op de PPP-service. MikroTik staat het gebruik van scripts in profielen (ppp-profile) toe en wijst deze toe aan gebeurtenissen van het opzetten en verbreken van ppp-verbindingen. Instellingen van het ppp-profile kunnen zowel voor de PPP-server als voor afzonderlijke gebruikers worden toegepast. In dit geval heeft het aan de gebruiker toegewezen profiel prioriteit boven de parameters van het profiel dat voor de server als geheel is gekozen.
Door deze aanpak kunnen we een speciaal profiel voor tweefactorauthenticatie aanmaken en dit niet aan alle gebruikers toewijzen, maar alleen aan degenen die we dat nodig vinden. Dit kan relevant zijn als de PPP-diensten niet alleen voor het verbinden van eindgebruikers worden gebruikt, maar ook voor het opzetten van site-to-site verbindingen.
In het nieuw aangemaakte speciale profiel gebruiken we dynamische toevoeging van het adres en de interface van de verbonden gebruiker aan de 'grijze' lijsten van adressen en interfaces:
winbox
Code
/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
Het is noodzakelijk om de lijsten 'address-list' en 'interface-list' gezamenlijk te gebruiken om verkeer van VPN-clients die de secundaire autorisatie niet hebben doorstaan, te identificeren en op te vangen in de dstnat keten (prerouting).
Wanneer de voorbereidingen zijn afgerond en extra firewall-ketens en een profiel zijn aangemaakt, schrijven we een script dat verantwoordelijk is voor de autogenese van de 2FA-code en afzonderlijke firewallregels.
over PPP-Profile verrijkt ons met informatie over variabelen die verband houden met de verbindings- en ontkoppelingsevents van de PPP-client «Voer script uit bij gebruikerslogin-evenement. Dit zijn beschikbare variabelen die toegankelijk zijn voor het event-script: user, local-address, remote-address, caller-id, called-id, interface». Sommige hiervan zullen zeer nuttig zijn voor ons.
De code die in het profiel wordt gebruikt voor het PPP-on-up verbindings-evenement
#Логируем для отладки полученные переменные :log info ("lokale-adres")
:log informatie ("remote-adres")
:log informatie ("caller-id")
:log informatie ("called-id")
:log informatie ([/int pptp-server get ("interface") naam])
#Объявляем свои локальные переменные
:lokale lijstnaam "2fa_gevangen"
:lokale viamodem valse
:lokale modempoort "usb2"
#ищем автоматически созданную запись в адрес-листе "2fa_jailed"
:lokale recnum1 [/ip fi address-list vind adres=("remote-adres") lijst=$lijstnaam]
#получаем псевдослучайный код через 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
:lokale vphone [/ppp geheim krijgen [vind naam=$gebruiker] opmerking]#Готовим тело сообщения. Если клиент подключается к VPN прямо с телефона ему достаточно
#будет перейти прямо по ссылке из полученного сообщения
:lokale msgbody ("Uw code: " . $comm1 . "n Of open link http://gw.local/otp/" . $comm1 . "")# Отправляем SMS по выбранному каналу - USB-модем или email-to-sms
als $viamodem doe={
/tool sms send phone-number=$vphone message=$msgboby port=$modemport }
anders={
/tool e-mail send server=a.b.c.d from=admin@mydomain.example to=mail2sms@mcommunicator.ru subject="@".$vphone body=$msgboby }#Генерируем Layer7 regexp
lokale vregexp ("otp/" . $comm1)
:lokale vcomment ("2fa_" . ("remote-adres"))
/ip firewall layer7-protocol add name=("vcomment") opmerking=(
"remote-adres") 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") protocol=tcp src-adres=(
"remote-adres") dst-limiet=1,1,src-adres/1m40s
Speciaal voor degenen die zonder nadenken kopiëren en plakken, waarschuw ik — de code is afkomstig van een testversie en kan kleine typfouten bevatten. Voor een begrijpend persoon is het geen moeite om te achterhalen waar precies.Bij het ontkoppelen van de gebruiker wordt het evenement 'On-Down' gegenereerd en wordt het bijbehorende script met parameters aangeroepen. De taak van dit script is om de firewallregels op te ruimen die voor de ontkoppelde gebruiker zijn aangemaakt.
De code die in het profiel wordt gebruikt voor het PPP-on-down verbindings-evenement
:lokale vcomment ("2fa_" . ("remote-adres"))
/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]
Daarna kunnen we gebruikers aanmaken en iedereen of sommige van hen een profiel met tweefactorauthenticatie toewijzen.winbox
Code
/ppp secrets set [find name=Petrov] profile=2FAHoe dit eruitziet aan de kant van de client.
Bij het opzetten van de VPN-verbinding ontvangt de telefoon/tablet met een Android/iOS simkaart een SMS-bericht van ongeveer deze inhoud:
SMSje
Als de verbinding rechtstreeks vanaf de telefoon/tablet is ingesteld, kan 2FA eenvoudig worden doorlopen door op de link in het bericht te klikken. Dit is handig.
Wanneer de VPN-verbinding met de pc tot stand wordt gebracht, heeft de gebruiker een minimale invoervorm voor het wachtwoord nodig. Een klein formulier in de vorm van een HTML-bestand wordt naar de gebruiker verzonden bij het instellen van de VPN. Dit bestand kan zelfs via e-mail worden verzonden, zodat de gebruiker het kan opslaan en een snelkoppeling op een handige plaats kan maken. Zo ziet het eruit:
Snelkoppeling op het bureau
De gebruiker klikt met de muis op de snelkoppeling, er opent zich een eenvoudig invoerveld dat de code in de geopende URL plaatst:
Screenshot van het formulier
Het formulier is erg eenvoudig, bedoeld als voorbeeld. Geïnteresseerden kunnen het verder naar eigen wens aanpassen.
2fa_login_mini.html
<html> <head> <title>SMS OTP-aanmelding</title> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> </head> <body> <form name="login" action="/nl/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="nl"/> <input type="button" value="Inloggen" onclick="location.href='http://gw.local/otp/'+document.getElementById('text').value"/> </form> </body> </html>Als de autorisatie succesvol is verlopen, ziet de gebruiker in de browser het logo van MikroTik, wat een teken moet zijn van een geslaagde authenticatie:
Ik wil opmerken dat de afbeelding vanuit de ingebouwde webserver van MikroTik wordt teruggestuurd met behulp van WebProxy Deny Redirect.
Ik denk dat de afbeelding kan worden aangepast met de ‘hotspot’ tool, door daar jouw variant te uploaden en de Deny Redirect URL met WebProxy in te stellen.
Een dringende oproep aan degenen die proberen de goedkoopste 'speelgoed' MikroTik van $20 te kopen om deze te gebruiken als vervanging voor een router van $500 – doe dit alstublieft niet. Apparaten zoals de 'hAP Lite'/'hAP mini' (home access point) hebben een zeer zwakke CPU (smips) en zullen waarschijnlijk niet in staat zijn de belasting in de zakelijke sector aan te kunnen.
Waarschuwing! Dit probleem heeft één nadeel: bij het aansluiten en loskoppelen van klanten zijn er wijzigingen in de configuratie, die de router probeert op te slaan in zijn niet-vluchtige geheugen. Bij een groot aantal klanten en frequente aan- en afmeldingen kan dit leiden tot degradatie van de interne opslag in de router.
P.S.: de methoden voor het afleveren van de code aan de klant kunnen worden uitgebreid en aangevuld zolang als uw programmeermogelijkheden dat toelaten. Bijvoorbeeld, het is mogelijk om berichten naar telegram te sturen of… doe suggesties!
Ik hoop dat dit artikel nuttig voor je zal zijn en helpt om de netwerken van kleine en middelgrote bedrijven nog iets veiliger te maken.
Bron: habr.com
