Halló félagar! Í dag, þegar ástríðan í kringum fjarvinnu hefur minnkað örlítið, hafa flestir stjórnendur sigrað verkefni fjaraðgangs starfsmanna að fyrirtækjanetinu, það er kominn tími til að deila langvarandi reynslu minni í að bæta VPN öryggi. Þessi grein mun ekki fjalla um IPSec IKEv2 og xAuth sem nú er í tísku. Þetta snýst um að byggja upp kerfi VPN notendur þegar MikroTik virkar sem VPN netþjónn. Nefnilega þegar „klassískar“ samskiptareglur eins og PPP eru notaðar.
Í dag mun ég segja þér hvernig á að vernda MikroTik PPP-VPN jafnvel þó að notendareikningnum þínum sé rænt. Þegar þetta kerfi var kynnt fyrir einum af viðskiptavinum mínum lýsti hann því stuttlega sem „jæja, nú er þetta bara eins og í banka!
Aðferðin notar ekki ytri auðkenningarþjónustu. Verkefnin eru unnin innbyrðis af leiðinni sjálfum. Enginn kostnaður fyrir tengda viðskiptavininn. Aðferðin virkar bæði fyrir PC viðskiptavini og farsíma.
Almennt verndarkerfi er sem hér segir:
- Innri IP tölu notanda sem hefur tengst VPN netþjóninum er sjálfkrafa bætt við gráa listann.
- Tengingartilvikið býr sjálfkrafa til einskiptiskóða sem er sendur til notandans með einni af tiltækum aðferðum.
- Heimilisföng á þessum lista hafa takmarkaðan aðgang að staðarnetsauðlindum, að undanskildum „authenticator“ þjónustunni, sem býst við að fá einu sinni lykilorðskóða.
- Eftir að kóðann hefur verið kynntur hefur notandinn aðgang að innri netauðlindum.
First minnsta vandamálið sem við þurftum að glíma við var að geyma tengiliðaupplýsingar um notandann til að senda honum 2FA kóða. Þar sem það er ómögulegt að búa til handahófskennda gagnareiti sem samsvara notendum í Mikrotik, var núverandi „comment“ reitur notaður:
/ppp leyndarmál bæta við nafni=Petrov lykilorð=4M@ngr! athugasemd = "89876543210"
Annað vandamálið reyndist vera alvarlegra - val á leið og aðferð til að afhenda kóðann. Eins og er, eru þrjú kerfi innleidd: a) SMS um USB mótald b) tölvupóst c) SMS með tölvupósti í boði fyrir fyrirtækjaviðskiptavini rauða farsímafyrirtækisins.
Já, SMS-kerfi hafa í för með sér kostnað. En ef þú horfir á það, "öryggi snýst alltaf um peninga" (c).
Mér persónulega líkar ekki tölvupóstkerfið. Ekki vegna þess að það krefjist þess að póstþjónninn sé tiltækur viðskiptavinurinn sem er auðkenndur - það er ekki vandamál að skipta umferð. Hins vegar, ef viðskiptavinurinn vistaði lykilorð fyrir bæði VPN og tölvupóst í vafranum af gáleysi og missti síðan fartölvuna sína, mun árásarmaðurinn fá fullan aðgang að fyrirtækjanetinu frá henni.
Svo það er ákveðið - við afhendum kóða í eitt skipti með SMS skilaboðum.
Í þriðja lagi vandamálið var hvar og hvernig á að búa til gervi-handahófi kóða fyrir 2FA í MikroTik. Það er ekkert sambærilegt við random() aðgerðina í RouterOS forskriftarmálinu og ég hef séð nokkra crummy forskriftagerða gervi-handahófsnúmeraframleiðendur áður. Mér líkaði hvorugt þeirra af ýmsum ástæðum.
Reyndar ER gervi-handahófskennd röð rafall í MikroTik! Það er falið fyrir yfirborðslegu sjónarhorni í samhengi við /certificates scep-server. Fyrsta leiðin Það er auðvelt og einfalt að fá einu sinni lykilorð - með skipuninni /vottorð scep-server otp búa til. Ef við framkvæmum einfalda breytuúthlutunaraðgerð fáum við fylkisgildi sem hægt er að nota síðar í skriftum.
Önnur leiðin að fá einu sinni lykilorð, sem er líka auðvelt í notkun - með ytri þjónustu til að búa til æskilega tegund af röð gervihandahófsnúmera. Hér er ein einfölduð cantilever dæmi um móttöku gagna í breytu:
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
Beiðni sem er sniðin fyrir stjórnborðið (sleppa sérstöfum verður krafist í meginmáli handritsins) fær sex tölustafi í breytuna $rnd1. Eftirfarandi "setja" skipun sýnir einfaldlega breytuna í MikroTik stjórnborðinu.
Fjórða vandamálið sem þurfti að leysa fljótt var hvernig og hvar tengdi viðskiptavinurinn myndi senda einskiptakóða sinn á öðru stigi auðkenningar.
Það verður að vera þjónusta á MikroTik beininum sem getur samþykkt kóðann og passað við ákveðinn viðskiptavin. Ef kóðinn sem gefinn er samsvarar þeim sem búist er við, verður heimilisfang viðskiptavinarins að vera með á ákveðnum „hvítum“ lista, þar sem heimilisföng fá aðgang að innra neti fyrirtækisins.
Vegna takmarkaðs þjónustuvals var ákveðið að samþykkja kóða í gegnum http með því að nota vefproxy sem er innbyggður í Mikrotik. Og þar sem eldveggurinn getur unnið með kraftmikla lista yfir IP tölur, þá er það eldveggurinn sem leitar að kóðanum, passar hann við IP viðskiptavinar og bætir honum við „hvíta“ listann með því að nota Layer7 regexp. Beininum sjálfum hefur verið úthlutað skilyrtu DNS nafni „gw.local“ og kyrrstæð skrá hefur verið búin til á honum til útgáfu til PPP viðskiptavina:
DNS
/ip dns static add name=gw.local address=172.31.1.1
Handtaka umferð frá óstaðfestum viðskiptavinum með proxy:
/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
Í þessu tilviki hefur umboðið tvær aðgerðir.
1. Opnaðu TCP tengingar við viðskiptavini;
2. Ef heimild er heppnuð skaltu beina vafra viðskiptavinarins á síðu eða mynd sem tilkynnir um árangursríka auðkenningu:
Stillingar proxy
/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
Ég mun telja upp mikilvæga stillingarþætti:
- viðmótslisti "2fa" - kraftmikill listi yfir viðskiptavinaviðmót, umferð sem krefst vinnslu innan ramma 2FA;
- heimilisfangslisti „2fa_jailed“ — „grár“ listi yfir IP vistföng VPN viðskiptavina;
- address_list "2fa_approved" - hvítur listi yfir IP vistföng göng VPN viðskiptavina sem hafa staðist tvíþætta auðkenningu.
- eldveggskeðja „input_2fa“ - það athugar TCP-pakka fyrir tilvist heimildarkóða og hvort IP-tala sendanda kóðans passi við það sem krafist er. Reglum í keðjunni er bætt við og fjarlægð á kraftmikinn hátt.
Einfaldað flæðirit fyrir pakkavinnslu lítur svona út:
Til þess að taka með umferð frá viðskiptavinum á „gráa“ listanum sem hafa ekki enn staðist annað stig auðkenningar í Layer7 skönnunina, hefur verið búin til regla í stöðluðu „inntak“ keðjunni:
Code
/ip firewall filter add chain=input !src-address-list=2fa_approved action=jump jump-target=input_2fa
Nú skulum við byrja að tengja allan þennan auð við PPP þjónustuna. MikroTik gerir þér kleift að nota forskriftir í sniðum (ppp-prófíl) og tengja þau við uppsetningu og rof á ppp-tengingu. Hægt er að nota ppp-sniðstillingarnar bæði á PPP-þjóninn í heild sinni og einstaka notendur. Í þessu tilviki hefur sniðið sem notandanum er úthlutað forgang og hnekkir með tilgreindum breytum færibreytum sniðsins sem valið er fyrir netþjóninn í heild sinni.
Sem afleiðing af þessari nálgun getum við búið til sérstakt prófíl fyrir tvíþætta auðkenningu og úthlutað því ekki til allra notenda, heldur aðeins þeirra sem við teljum nauðsynlega til að gera það. Þetta gæti skipt máli ef þú notar PPP þjónustu, ekki aðeins til að tengja saman notendur, heldur á sama tíma til að byggja upp tengingar frá síðu til staðar.
Í nýstofnaða sérsniðinu notum við kraftmikla viðbót við heimilisfang og viðmót tengda notanda við „gráa“ lista yfir heimilisföng og viðmót:
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
Nauðsynlegt er að nota „address-list“ og „interface-list“ listana saman til að bera kennsl á og fanga umferð frá VPN viðskiptavinum sem hafa ekki staðist aukaheimild í dstnat (prerouting) keðjunni.
Þegar undirbúningi er lokið, fleiri eldveggskeðjur og prófíl hafa verið búnar til, munum við skrifa handrit sem ber ábyrgð á sjálfvirkri gerð 2FA kóðans og einstakra eldveggsreglur.
á PPP-Profile auðgar okkur með upplýsingum um breytur sem tengjast PPP biðlaratengingu og aftengingartilvikum „Framkvæma skriftu á innskráningarviðburði notanda. Þetta eru tiltækar breytur sem eru aðgengilegar fyrir atburðarforskriftina: notandi, staðbundið heimilisfang, fjarvistfang, auðkenni hringir, kallað-auðkenni, viðmót". Sum þeirra munu nýtast okkur mjög vel.
Kóði notaður í prófílnum fyrir PPP on-up tengingarviðburðinn
#Логируем для отладки полученные переменные :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
Ég vara þig sérstaklega við þeim sem hafa gaman af því að copy-pastea án vitundar - kóðinn var tekinn úr prufuútgáfu og gæti innihaldið smávillur. Það verður ekki erfitt fyrir skilningsríkan mann að átta sig á hvar nákvæmlega.Þegar notandi aftengir sig myndast „On-Down“ atburður og samsvarandi forskrift með breytum er kölluð. Tilgangur þessarar skriftu er að hreinsa upp eldveggsreglurnar sem búið er til fyrir ótengdan notanda.
Kóði sem notaður er í prófílnum fyrir PPP-tengingartilvikið
: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]
Þú getur síðan búið til notendur og úthlutað sumum eða öllum þeirra á tveggja þátta auðkenningarsnið.winbox
Code
/ppp secrets set [find name=Petrov] profile=2FAHvernig lítur það út hjá viðskiptavininum.
Þegar þú kemur á VPN-tengingu er svona SMS sent til Android/iOS símans/spjaldtölvunnar með SIM-korti:
smáskilaboð
Ef tengingin er beint úr símanum/spjaldtölvunni þinni geturðu farið í gegnum 2FA einfaldlega með því að smella á hlekkinn í skilaboðunum. Það er þægilegt.
Ef VPN-tenging er komið á úr tölvu, þá verður notandinn að slá inn lágmarks lykilorð. Lítið eyðublað í formi HTML skráar er sent til notandans þegar VPN er sett upp. Jafnvel er hægt að senda skrána í pósti þannig að notandinn geti vistað hana og búið til flýtileið á hentugum stað. Svona lítur þetta í grófum dráttum út:
Merki á borðið
Notandinn smellir á flýtileiðina, einfalt innsláttareyðublað fyrir kóða opnast, sem setur kóðann inn í opnaða vefslóð:
Myndaskjár
Formið er frumstæðasta, gefið sem dæmi. Þeir sem vilja geta breytt því til að henta þeim.
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>Ef heimild tekst mun notandinn sjá MikroTik lógóið í vafranum, sem ætti að þjóna sem merki um árangursríka auðkenningu:
Athugaðu að myndinni er skilað frá innbyggða MikroTik vefþjóninum með WebProxy Deny Redirect.
Ég tel að hægt sé að sérsníða myndina með því að nota „hotspot“ tólið, hlaða upp þinni eigin útgáfu þangað og setja neita tilvísunarslóð á hana með WebProxy.
Stór beiðni til þeirra sem eru að reyna að kaupa ódýrasta „leikfangið“ Mikrotik fyrir $20 og skipta um það fyrir $500 beini - ekki gera það. Tæki eins og „hAP Lite“/“hAP mini“ (aðgangsstaður heima) eru með mjög veikan örgjörva (smips) og eru líkleg til að þola ekki álagið í viðskiptahlutanum.
Viðvörun! Þessi lausn hefur einn galli: þegar viðskiptavinir tengjast eða aftengja sig verða stillingarbreytingar sem leiðin reynir að vista í óstöðuglegu minni sínu. Með miklum fjölda viðskiptavina og tíðum tengingum og aftengingum getur þetta leitt til rýrnunar á innri geymslu í beini.
PS: aðferðir til að afhenda kóða til viðskiptavinarins er hægt að stækka og bæta við hvað varðar forritunargetu þína. Til dæmis geturðu sent skilaboð í símskeyti eða... bent á valkosti!
Ég vona að þessi grein muni nýtast þér og hjálpa til við að gera lítil og meðalstór fyrirtækjanet örlítið öruggari.
Heimild: www.habr.com