Hei kollegat! Tänään, kun intohimot "etätyön" ympärillä hieman laantuivat, suurin osa järjestelmänvalvojista voitti tehtävän työntekijöiden etäkäytöstä yritysverkkoon, on aika jakaa pitkäaikainen kokemukseni VPN-turvallisuuden parantamisesta. Tämä artikkeli ei ole muodikas nyt IPSec IKEv2 ja xAuth. Kyse on järjestelmän rakentamisesta. VPN-käyttäjät, kun MikroTik toimii VPN-palvelimena. Nimittäin kun käytetään "klassisia" protokollia, kuten PPP.
Tänään kerron sinulle kuinka suojata MikroTik PPP-VPN jopa käyttäjätilin "kaappauksen" tapauksessa. Kun tämä järjestelmä esiteltiin eräälle asiakkaalleni, hän kuvaili sitä lyhyesti: "No, nyt se on kuin pankissa!".
Menetelmä ei käytä ulkoisia todennuspalveluita. Reititin itse suorittaa tehtävät sisäisesti. Ei kustannuksia yhdistävälle asiakkaalle. Menetelmä toimii sekä PC-asiakkaille että mobiililaitteille.
Yleinen suojajärjestelmä on seuraava:
- VPN-palvelimeen onnistuneesti muodostaneen käyttäjän sisäinen IP-osoite näkyy automaattisesti harmaalla listalla.
- Yhteystapahtuma luo automaattisesti kertaluonteisen koodin, joka lähetetään käyttäjälle jollakin käytettävissä olevista tavoista.
- Tämän luettelon osoitteilla on rajoitettu pääsy paikallisiin verkkoresursseihin, lukuun ottamatta Authenticator-palvelua, joka odottaa kertaluonteisen pääsykoodin saamista.
- Koodin esittämisen jälkeen käyttäjällä on pääsy verkon sisäisiin resursseihin.
Ensimmäinen Pienin kohtaamani ongelma oli käyttäjän yhteystietojen tallentaminen 2FA-koodin lähettämiseksi. Koska Mikrotikissa on mahdotonta luoda mielivaltaisia käyttäjiä vastaavia tietokenttiä, käytettiin olemassa olevaa "kommentti" -kenttää:
/ppp Secrets add name=Petrov salasana=4M@ngr! comment="89876543210"
Toinen ongelma osoittautui vakavammaksi - polun ja koodin toimitustavan valinta. Tällä hetkellä käytössä on kolme järjestelmää: a) SMS USB-modeemin kautta b) sähköposti c) SMS sähköpostin kautta punasolukkooperaattorin yritysasiakkaille.
Kyllä, tekstiviestijärjestelmät aiheuttavat kustannuksia. Mutta jos katsot, "turvallisuus on aina rahasta" (c).
En henkilökohtaisesti pidä sähköpostijärjestelmästä. Ei siksi, että se vaatii sähköpostipalvelimen olevan todennettavan asiakkaan käytettävissä – liikenteen jakaminen ei ole ongelma. Kuitenkin, jos asiakas olisi huolimattomasti tallentanut sekä vpn- että sähköpostisalasanat selaimeen ja kadonnut sitten kannettavan tietokoneensa, hyökkääjä saisi siitä täyden pääsyn yritysverkkoon.
Joten, se on päätetty - toimitamme kertakoodin tekstiviesteillä.
Kolmas Ongelma oli missä kuinka luoda pseudosatunnainen koodi 2FA:lle MikroTikissa. RouterOS-skriptikielessä ei ole analogia random()-funktiolle, ja olen nähnyt useita crutch script -pseudosatunnaislukugeneraattoreita aiemmin. En pitänyt niistä yhdestäkään eri syistä.
Itse asiassa MikroTikissa on näennäissatunnainen sekvenssigeneraattori! Se on piilotettu pinnalliselta silmäyksellä /certificates scep-server -kontekstissa. Ensimmäinen tapa kertaluonteisen salasanan saaminen on helppoa ja yksinkertaista - komennolla /certificates scep-server otp generoi. Jos suoritamme yksinkertaisen muuttujan määritysoperaation, saamme taulukon arvon, jota voidaan käyttää myöhemmin skripteissä.
Toinen tapa kertakäyttöisen salasanan hankkiminen, joka on myös helppo ottaa käyttöön - käyttämällä ulkoista palvelua generoidaksesi halutunlaisen pseudosatunnaislukujonon. Tässä on yksinkertaistettu cantilevered esimerkki tietojen saamisesta muuttujaan:
Koodi
: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
Konsolia varten muotoiltu pyyntö (skriptin rungossa tarvitaan erikoismerkkejä) vastaanottaa kuusinumeroisen merkkijonon $rnd1-muuttujaan. Seuraava "put"-komento näyttää muuttujan MikroTik-konsolissa.
Neljäs ongelma joka piti ratkaista nopeasti - näin ja mihin yhdistetty asiakas siirtää kertakoodinsa todennuksen toisessa vaiheessa.
MikroTik-reitittimessä on oltava palvelu, joka voi hyväksyä koodin ja yhdistää sen tietyn asiakkaan kanssa. Jos annettu koodi vastaa odotettua, tulee asiakkaan osoite olla tietyllä "valkoisella" listalla, josta osoitteista pääsee yrityksen sisäverkkoon.
Huonon palveluvalikoiman vuoksi päätettiin hyväksyä koodit http:n kautta Mikrotikiin sisäänrakennetun webproxyn avulla. Ja koska palomuuri voi toimia dynaamisten IP-osoitteiden luetteloiden kanssa, se on palomuuri, joka suorittaa koodin haun, sovittaa sen asiakkaan IP-osoitteeseen ja lisää sen "valkoiseen" luetteloon Layer7 regexpin avulla. Itse reitittimelle on annettu ehdollinen DNS-nimi "gw.local", sille on luotu staattinen A-tietue PPP-asiakkaille:
DNS
/ip dns static add name=gw.local address=172.31.1.1
Vahvistamattomien asiakkaiden liikenteen sieppaus välityspalvelimella:
/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
Tässä tapauksessa välityspalvelimella on kaksi toimintoa.
1. Avaa tcp-yhteydet asiakkaiden kanssa;
2. Jos valtuutus on onnistunut, ohjaa asiakasselain sivulle tai kuvalle, joka ilmoittaa onnistuneesta todennuksesta:
Välityspalvelimen asetukset
/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
Luettelon tärkeät kokoonpanoelementit:
- liitäntäluettelo "2fa" - dynaaminen luettelo asiakasliittymistä, joiden liikenne vaatii käsittelyä 2FA:n sisällä;
- osoiteluettelo "2fa_jailed" - "harmaa" luettelo VPN-asiakkaiden tunnelin IP-osoitteista;
- address_list "2fa_approved" - "valkoinen" luettelo VPN-asiakkaiden tunneli-IP-osoitteista, jotka ovat läpäisseet kaksivaiheisen todennuksen.
- palomuuriketju "input_2fa" - se tarkistaa tcp-paketit valtuutuskoodin varalta ja yhdistää koodin lähettäjän IP-osoitteen vaadittuun. Ketjun sääntöjä lisätään ja poistetaan dynaamisesti.
Yksinkertaistettu pakettien käsittelyn vuokaavio näyttää tältä:
Päästäksesi Layer7-tarkistukseen "harmaalta" listalta tulevilta asiakkailta, jotka eivät ole vielä läpäisseet todennusvaihetta, on luotu sääntö tavalliseen "syöttö"-ketjuun:
Koodi
/ip firewall filter add chain=input !src-address-list=2fa_approved action=jump jump-target=input_2fa
Nyt aletaan kiinnittää tätä rikkautta PPP-palveluun. MikroTik antaa sinun käyttää skriptejä profiileissa (ppp-profiili) ja liittää ne ppp-yhteyden muodostamis- ja katkaisutapahtumiin. Ppp-profiilin asetuksia voidaan soveltaa sekä koko PPP-palvelimeen että yksittäisiin käyttäjiin. Samalla käyttäjälle määrätyllä profiililla on etusija, ohittaen palvelimelle kokonaisuutena valitun profiilin parametrit määritetyillä parametreilla.
Tämän lähestymistavan tuloksena voimme luoda erityisen profiilin kaksivaiheista todennusta varten ja määrittää sitä ei kaikille käyttäjille, vaan vain niille, jotka katsovat sen tarpeelliseksi. Tämä voi olla olennaista, jos käytät PPP-palveluita paitsi loppukäyttäjien yhdistämiseen, myös sivustojen välisten yhteyksien rakentamiseen.
Äskettäin luodussa erikoisprofiilissa käytämme yhdistetyn käyttäjän osoitteen ja käyttöliittymän dynaamista lisäystä "harmaisiin" osoite- ja rajapintoihin:
winbox
Koodi
/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
On tarpeen käyttää sekä "osoiteluettelo"- että "liittymäluettelo" -luetteloita dstnat-ketjun (prerouting) -ketjun ei-toissijaisten VPN-asiakkaiden liikenteen havaitsemiseen ja sieppaamiseen.
Kun valmistelu on valmis, lisäpalomuuriketjut ja profiili luodaan, kirjoitamme skriptin, joka vastaa 2FA-koodin ja yksittäisten palomuurisääntöjen automaattisesta luomisesta.
on PPP-Profile rikastuttaa meitä tiedoilla muuttujista, jotka liittyvät PPP-asiakkaan yhteys-katkaisutapahtumiin "Suorita komentosarja käyttäjän kirjautumistapahtumassa. Nämä ovat saatavilla olevia muuttujia, jotka ovat käytettävissä tapahtumaskriptille: user, local-address, remote-address, caller-id, call-id, interface". Jotkut niistä ovat erittäin hyödyllisiä meille.
Koodi, jota käytetään profiilissa PPP on-up -yhteystapahtumassa
#Логируем для отладки полученные переменные :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
Varoitan erityisesti niille, jotka pitävät mielettömästä kopioinnista ja liittämisestä - koodi on otettu testiversiosta ja saattaa sisältää pieniä kirjoitusvirheitä. Ymmärtävän ihmisen ei ole vaikeaa selvittää tarkalleen missä.Kun käyttäjä katkaisee yhteyden, "On-Down" -tapahtuma luodaan ja vastaava skripti parametreineen kutsutaan. Tämän komentosarjan tarkoituksena on puhdistaa katkaistua käyttäjää varten luodut palomuurisäännöt.
Profiilissa käytetty koodi PPP on-down -yhteystapahtumassa
: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]
Tämän jälkeen voit luoda käyttäjiä ja määrittää kaikki tai osan heistä kaksivaiheiseen todennusprofiiliin.winbox
Koodi
/ppp secrets set [find name=Petrov] profile=2FAMiltä se näyttää asiakkaan puolella.
Kun VPN-yhteys on muodostettu, Android/iOS-puhelin/tabletti, jossa on SIM-kortti, vastaanottaa seuraavanlaisen tekstiviestin:
tekstiviesti
Jos yhteys muodostetaan suoraan puhelimesta/tabletista, voit käydä 2FA:n läpi yksinkertaisesti napsauttamalla viestissä olevaa linkkiä. Se on mukava.
Jos VPN-yhteys muodostetaan tietokoneelta, käyttäjän on syötettävä vähimmäissalasanalomake. Pieni HTML-tiedoston muodossa oleva lomake annetaan käyttäjälle VPN:ää määritettäessä. Tiedosto voidaan lähettää jopa postitse, jolloin käyttäjä tallentaa sen ja luo pikakuvakkeen sopivaan paikkaan. Se näyttää tältä:
Etiketti pöydällä
Käyttäjä napsauttaa pikakuvaketta, yksinkertainen koodinsyöttölomake avautuu, joka liittää koodin avautuvaan URL-osoitteeseen:
Näytön muoto
Alkeellisin muoto on annettu esimerkkinä. Halukkaat voivat muokata itse.
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>Jos valtuutus onnistui, käyttäjä näkee selaimessa MikroTik-logon, jonka pitäisi viestiä onnistuneen todennuksen onnistumisesta:
Huomaa, että kuva palautetaan sisäänrakennetulta MikroTik-verkkopalvelimelta käyttämällä WebProxy Deny Redirect -toimintoa.
Oletan, että kuvaa voidaan mukauttaa "hotspot"-työkalulla, lataamalla sinne oma versiosi ja asettamalla sille WebProxylla Estä uudelleenohjaus -osoite.
Suuri pyyntö niille, jotka yrittävät ostaa halvimman "lelun" Mikrotikin 20 dollarilla ja korvata sillä 500 dollarin reitittimen - älkää tehkö niin. Laitteilla, kuten "hAP Lite" / "hAP mini" (kotitukiasema), on erittäin heikko suoritin (smips), eivätkä ne todennäköisesti selviä liiketoimintasegmentin kuormituksesta.
Varoitus! Tällä ratkaisulla on yksi haittapuoli: kun asiakkaat muodostavat yhteyden tai katkaisevat yhteyden, tapahtuu konfiguraatiomuutoksia, jotka reititin yrittää tallentaa haihtumattomaan muistiinsa. Jos asiakkaita on paljon ja yhteydet ja yhteydet katkeavat usein, tämä voi johtaa reitittimen sisäisen tallennustilan heikkenemiseen.
PS: Menetelmiä koodin toimittamiseen asiakkaalle voidaan laajentaa ja täydentää ohjelmointikykysi mukaan. Voit esimerkiksi lähettää viestejä sähkeeseen tai ... ehdottaa vaihtoehtoja!
Toivon, että artikkelista on sinulle hyötyä ja se auttaa tekemään pienten ja keskisuurten yritysten verkostoista hieman turvallisempia.
Lähde: will.com