Sveiki kolēģi! Šodien, kad kaislību intensitāte ap “attālināto darbu” nedaudz pierima, lielākā daļa administratoru uzvarēja uzdevumu attālināti piekļūt darbiniekiem korporatīvajam tīklam, pienācis laiks padalīties ar savu ilggadējo pieredzi VPN drošības uzlabošanā. Šis raksts tagad nebūs modē IPSec IKEv2 un xAuth. Tas ir par sistēmas izveidi. VPN lietotāji, kad MikroTik darbojas kā VPN serveris. Proti, kad tiek izmantoti "klasiskie" protokoli, piemēram, PPP.
Šodien es jums pastāstīšu, kā aizsargāt MikroTik PPP-VPN pat lietotāja konta "nolaupīšanas" gadījumā. Kad ar šo shēmu tika iepazīstināts kāds no maniem klientiem, viņš to īsi raksturoja kā “nu, tagad ir gluži kā bankā!”.
Metode neizmanto ārējos autentifikācijas pakalpojumus. Uzdevumus iekšēji veic pats maršrutētājs. Pieslēdzošajam klientam nav jāmaksā. Metode darbojas gan personālo datoru klientiem, gan mobilajām ierīcēm.
Vispārējā aizsardzības shēma ir šāda:
- Lietotāja, kurš ir veiksmīgi izveidojis savienojumu ar VPN serveri, iekšējā IP adrese tiek automātiski parādīta pelēkajā sarakstā.
- Savienojuma notikums automātiski ģenerē vienreizēju kodu, kas tiek nosūtīts lietotājam, izmantojot kādu no pieejamajām metodēm.
- Adresēm šajā sarakstā ir ierobežota piekļuve vietējā tīkla resursiem, izņemot pakalpojumu “autentifikators”, kas gaida vienreizējas piekļuves koda saņemšanu.
- Pēc koda uzrādīšanas lietotājam ir pieejami tīkla iekšējie resursi.
Pirmais mazākā problēma, ar kuru man nācās saskarties, bija kontaktinformācijas saglabāšana par lietotāju, lai nosūtītu viņam 2FA kodu. Tā kā Mikrotik nav iespējams izveidot patvaļīgus datu laukus atbilstoši lietotājiem, tika izmantots esošais komentāra lauks:
/ppp noslēpumi add name=Petrov password=4M@ngr! komentārs = "89876543210"
Otrais problēma izrādījās nopietnāka - koda piegādes ceļa un metodes izvēle. Pašlaik tiek ieviestas trīs shēmas: a) SMS caur USB modemu b) e-pasts c) SMS pa e-pastu, kas pieejams sarkano šūnu operatora korporatīvajiem klientiem.
Jā, SMS shēmas rada izmaksas. Bet, ja paskatās, "drošība vienmēr ir saistīta ar naudu" (c).
Man personīgi nepatīk shēma ar e-pastu. Ne tāpēc, ka tas prasa, lai pasta serveris būtu pieejams autentificētajam klientam — tā nav problēma sadalīt trafiku. Tomēr, ja klients pārlūkprogrammā neuzmanīgi saglabāja gan VPN, gan e-pasta paroles un pēc tam pazaudēja savu klēpjdatoru, uzbrucējs no tā iegūtu pilnu piekļuvi korporatīvajam tīklam.
Tātad, ir nolemts - mēs piegādājam vienreizēju kodu, izmantojot SMS.
Trešais Problēma bija kur kā MikroTik ģenerēt pseidogadījuma kodu 2FA. RouterOS skriptu valodā nav nejaušības () funkcijas analoga, un iepriekš esmu redzējis vairākus kruķu skriptu pseidogadījuma skaitļu ģeneratorus. Neviens no tiem man nepatika dažādu iemeslu dēļ.
Faktiski MikroTik ir pseidogadījuma secību ģenerators! Tas ir paslēpts no virspusēja skatiena /certificates scep-server kontekstā. Pirmā metode vienreizējas paroles iegūšana ir vienkārša un vienkārša - ar komandu /certificates scep-server otp ģenerēt. Ja mēs veiksim vienkāršu mainīgo piešķiršanas darbību, mēs iegūsim masīva vērtību, ko vēlāk varēs izmantot skriptos.
otrā metode vienreizējas paroles iegūšana, kuru arī ir viegli lietot, izmantojot ārpakalpojumu lai ģenerētu vēlamo pseidogadījuma skaitļu secību. Šeit ir vienkāršots konsoles piemērs datu iegūšanai mainīgajā:
Kods
: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
Konsolei formatēts pieprasījums (skripta pamattekstā būs nepieciešamas speciālās rakstzīmes), kas mainīgajā $rnd1 saņem sešu ciparu virkni. Sekojošā komanda "put" vienkārši parāda mainīgo MikroTik konsolē.
Ceturtā problēma kas bija ātri jāatrisina - šādi un kur savienotais klients pārsūtīs savu vienreizējo kodu autentifikācijas otrajā posmā.
MikroTik maršrutētājā ir jābūt pakalpojumam, kas var pieņemt kodu un saskaņot to ar konkrētu klientu. Ja norādītais kods sakrīt ar gaidīto, klienta adrese jāiekļauj noteiktā "baltajā" sarakstā, no kura adresēm ir atļauta pieeja uzņēmuma iekšējam tīklam.
Sliktās pakalpojumu izvēles dēļ tika nolemts pieņemt kodus caur http, izmantojot Mikrotik iebūvēto tīmekļa starpniekserveri. Un tā kā ugunsmūris var strādāt ar dinamiskiem IP adrešu sarakstiem, tieši ugunsmūris veic koda meklēšanu, saskaņojot to ar klienta IP un pievienojot to “baltajam” sarakstam, izmantojot Layer7 regexp. Pašam maršrutētājam ir piešķirts nosacīts DNS nosaukums "gw.local", tajā ir izveidots statisks A ieraksts izsniegšanai PPP klientiem:
DNS
/ip dns static add name=gw.local address=172.31.1.1
Neverificētu klientu trafika tveršana starpniekserverī:
/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
Šajā gadījumā starpniekserveram ir divas funkcijas.
1. Atvērt tcp savienojumus ar klientiem;
2. Veiksmīgas autorizācijas gadījumā novirziet klienta pārlūkprogrammu uz lapu vai attēlu, kas informē par veiksmīgu autentifikāciju:
Starpniekservera konfigurācija
/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
Es uzskaitīšu svarīgos konfigurācijas elementus:
- interfeisu saraksts "2fa" - dinamisks klientu interfeisu saraksts, no kuriem trafika nepieciešama apstrāde 2FA ietvaros;
- adrešu saraksts "2fa_jailed" - VPN klientu tuneļa IP adrešu "pelēks" saraksts;
- address_list "2fa_approved" - "baltais" VPN klientu tuneļa IP adrešu saraksts, kas veiksmīgi izturējuši divu faktoru autentifikāciju.
- ugunsmūra ķēde "input_2fa" - tā pārbauda tcp paketes, vai nav autorizācijas koda, un saskaņo koda sūtītāja IP adresi ar nepieciešamo. Noteikumi ķēdē tiek pievienoti un noņemti dinamiski.
Vienkāršota pakešu apstrādes blokshēma izskatās šādi:
Lai iekļūtu Layer7 pārbaudē trafiku no klientiem no "pelēkā" saraksta, kuri vēl nav izturējuši otro autentifikācijas posmu, standarta "ievades" ķēdē ir izveidota kārtula:
Kods
/ip firewall filter add chain=input !src-address-list=2fa_approved action=jump jump-target=input_2fa
Tagad sāksim visu šo bagātību piesaistīt PPP dienestam. MikroTik ļauj izmantot skriptus profilos (ppp-profils) un piešķirt tos ppp savienojuma izveides un pārtraukšanas notikumiem. Ppp profila iestatījumus var lietot gan PPP serverim kopumā, gan atsevišķiem lietotājiem. Tajā pašā laikā lietotājam piešķirtajam profilam ir prioritāte, kas ignorē serverim atlasītā profila parametrus ar tā norādītajiem parametriem.
Šīs pieejas rezultātā mēs varam izveidot īpašu profilu divu faktoru autentifikācijai un piešķirt to ne visiem lietotājiem, bet tikai tiem, kuri uzskata par nepieciešamu to darīt. Tas var būt svarīgi, ja izmantojat PPP pakalpojumus ne tikai galalietotāju savienošanai, bet tajā pašā laikā, lai izveidotu savienojumus starp vietni.
Jaunizveidotajā īpašajā profilā mēs izmantojam pieslēgtā lietotāja adreses un interfeisa dinamisku pievienošanu "pelēkajiem" adrešu un interfeisu sarakstiem:
winbox
Kods
/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
Ir nepieciešams izmantot gan "adrešu sarakstu", gan "interfeisu sarakstu" sarakstus, lai noteiktu un tvertu trafiku no nesekundāriem VPN klientiem dstnat (pirmsmaršrutēšanas) ķēdē.
Kad sagatavošanās būs pabeigta, tiks izveidotas papildu ugunsmūra ķēdes un profils, mēs uzrakstīsim skriptu, kas atbild par 2FA koda automātisku ģenerēšanu un atsevišķiem ugunsmūra noteikumiem.
uz PPP-Profile bagātina mūs ar informāciju par mainīgajiem lielumiem, kas saistīti ar PPP klienta savienojuma un atvienošanas notikumiem "Izpildīt skriptu lietotāja pieteikšanās notikumā. Šie ir pieejamie mainīgie, kas ir pieejami notikuma skriptam: lietotājs, vietējā adrese, attālā adrese, zvanītāja ID, izsauktā ID, interfeiss.. Daži no tiem mums ir ļoti noderīgi.
Profilā izmantotais kods PPP on-up savienojuma notikumam
#Логируем для отладки полученные переменные :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
Īpaši tiem, kam patīk bez prāta kopēt-ielīmēt, brīdinu - kods ir ņemts no testa versijas un var saturēt nelielas drukas kļūdas. Saprotošam cilvēkam nebūs grūti izdomāt, kur tieši.Kad lietotājs atvienojas, tiek ģenerēts notikums “On-Down” un tiek izsaukts atbilstošais skripts ar parametriem. Šī skripta uzdevums ir iztīrīt atvienotajam lietotājam izveidotos ugunsmūra noteikumus.
Profilā izmantotais kods PPP ieslēgšanas savienojuma notikumam
: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]
Pēc tam varat izveidot lietotājus un visus vai dažus no tiem piešķirt divu faktoru autentifikācijas profilam.winbox
Kods
/ppp secrets set [find name=Petrov] profile=2FAKā tas izskatās no klienta puses.
Kad ir izveidots VPN savienojums, Android/iOS tālrunis/planšetdators ar SIM karti saņem šādu SMS:
īsziņa
Ja savienojums tiek izveidots tieši no tālruņa / planšetdatora, varat iet cauri 2FA, vienkārši noklikšķinot uz ziņojumā esošās saites. Tas ir ērti.
Ja VPN savienojums tiek izveidots no datora, lietotājam būs jāievada minimālā paroles forma. Iestatot VPN, lietotājam tiek piešķirta neliela veidlapa HTML faila formā. Failu var pat nosūtīt pa pastu, lai lietotājs to saglabātu un izveidotu saīsni ērtā vietā. Tas izskatās šādi:
Etiķete uz galda
Lietotājs noklikšķina uz saīsnes, tiek atvērta vienkārša koda ievades forma, kas ielīmēs kodu atvērtajā URL:
Ekrāna forma
Kā piemērs ir dota primitīvākā forma. Tie, kas vēlas, var mainīt paši.
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>Ja autorizācija bija veiksmīga, lietotājs pārlūkprogrammā redzēs MikroTik logotipu, kam vajadzētu signalizēt par veiksmīgu autentifikāciju:
Ņemiet vērā, ka attēls tiek atgriezts no iebūvētā MikroTik tīmekļa servera, izmantojot WebProxy Deny Redirect.
Es domāju, ka attēlu var pielāgot, izmantojot "hotspot" rīku, augšupielādējot tur savu versiju un iestatot tam URL Noliegt novirzīšanu, izmantojot WebProxy.
Liels lūgums tiem, kas cenšas nopirkt lētāko "rotaļlietu" Mikrotik par 20$ un nomainīt ar to 500$ rūteri - nedariet to. Tādām ierīcēm kā "hAP Lite" / "hAP mini" (mājas piekļuves punkts) ir ļoti vājš CPU (smips), un visticamāk, ka tās netiks galā ar slodzi biznesa segmentā.
Uzmanību! Šim risinājumam ir viens trūkums: kad klienti pieslēdzas vai atvienojas, notiek konfigurācijas izmaiņas, kuras maršrutētājs mēģina saglabāt savā nemainīgajā atmiņā. Ar lielu klientu skaitu un biežiem savienojumiem un atvienojumiem tas var izraisīt maršrutētāja iekšējās atmiņas degradāciju.
PS: koda piegādes klientam metodes var tikt paplašinātas un papildinātas, ja vien pietiek ar jūsu programmēšanas iespējām. Piemēram, varat nosūtīt ziņas uz telegrammu vai ... ieteikt iespējas!
Es ceru, ka raksts jums būs noderīgs un palīdzēs padarīt mazo un vidējo uzņēmumu tīklus drošākus.
Avots: www.habr.com