Fora laboro en la oficejo. RDP, Port Knocking, Mikrotik: simpla kaj sekura

Pro la covid-19-virusa pandemio kaj ĝenerala kvaranteno en multaj landoj, la sola maniero por multaj kompanioj daŭre labori estas fora aliro al laborejoj per interreto. Estas multaj relative sekuraj metodoj por fora laboro - sed konsiderante la amplekson de la problemo, necesas simpla metodo por iu ajn uzanto malproksime konekti al la oficejo kaj sen bezono de pliaj agordoj, klarigoj, tedaj konsultoj kaj longaj instrukcioj. Ĉi tiu metodo estas ŝatata de multaj administrantoj RDP (Remote Desktop Protocol). Konekti rekte al la laborejo per RDP ideale solvas nian problemon, krom unu granda muŝo en la ungvento - teni la RDP-havenon malfermita por la Interreto estas tre nesekura. Tial, ĉi-sube mi proponas simplan sed fidindan metodon de protekto.

Ĉar mi ofte renkontas malgrandajn organizojn, kie Mikrotik-aparatoj estas uzataj kiel Interreta aliro, ĉi-sube estos montrita kiel efektivigi ĉi tion sur Mikrotik, sed la Port Knocking-protekta metodo estas facile efektivigita sur aliaj altklasaj aparatoj kun similaj eniga enkursigilo kaj fajroŝirmilo. .

Mallonge pri Port Knocking. La ideala ekstera protekto de reto konektita al la Interreto estas kiam ĉiuj rimedoj kaj havenoj estas fermitaj de ekstere per fajroŝirmilo. Kaj kvankam enkursigilo kun tia agordita fajroŝirmilo neniel reagas al pakoj venantaj de ekstere, ĝi aŭskultas ilin. Sekve, vi povas agordi la enkursigilon tiel ke kiam certa (koda) sekvenco de retpakoj estas ricevita sur malsamaj havenoj, ĝi (la enkursigilo) por la IP de kie la pakoj venis detranĉas aliron al certaj rimedoj (havenoj, protokoloj, ktp.).

Nun al komerco. Mi ne faros detalan priskribon de la fajroŝirmilaj agordoj en Mikrotik - la Interreto estas plena de altkvalitaj fontoj por tio. Ideale, la fajroŝirmilo blokas ĉiujn envenantajn pakaĵojn, sed

/ip firewall filter
add action=accept chain=input comment="established and related accept" connection-state=established,related

Permesas alvenantan trafikon de establitaj rilataj konektoj.
Nun ni starigis Port Knocking sur Mikrotik:

/ip firewall filter
add action=drop chain=input dst-port=19000 protocol=tcp src-address-list="Black_scanners" comment=RemoteRules
add action=drop chain=input dst-port=16000 protocol=tcp src-address-list="Black_scanners" comment=RemoteRules
add action=add-src-to-address-list address-list="remote_port_1" address-list-timeout=1m chain=input dst-port=19000 protocol=tcp comment=RemoteRules
add action=add-src-to-address-list address-list="Black_scanners" address-list-timeout=60m chain=input dst-port=19001 protocol=tcp src-address-list="remote_port_1" comment=RemoteRules
add action=add-src-to-address-list address-list="Black_scanners" address-list-timeout=60m chain=input dst-port=18999 protocol=tcp src-address-list="remote_port_1" comment=RemoteRules
add action=add-src-to-address-list address-list="Black_scanners" address-list-timeout=60m chain=input dst-port=16001 protocol=tcp src-address-list="remote_port_1" comment=RemoteRules
add action=add-src-to-address-list address-list="Black_scanners" address-list-timeout=60m chain=input dst-port=15999 protocol=tcp src-address-list="remote_port_1" comment=RemoteRules
add action=add-src-to-address-list address-list="allow_remote_users" address-list-timeout=1m chain=input dst-port=16000 protocol=tcp src-address-list="remote_port_1" comment=RemoteRules
move [/ip firewall filter find comment=RemoteRules] 1
/ip firewall nat
add action=dst-nat chain=dstnat comment="remote_rdp" src-address-list="allow_remote_users" dst-port=33890 in-interface-list=WAN protocol=tcp to-addresses=192.168.1.33 to-ports=3389

Nun pli detale:

unuaj du reguloj

/ip firewall filter
add action=drop chain=input dst-port=19000 protocol=tcp src-address-list="Black_scanners" comment=RemoteRules
add action=drop chain=input dst-port=16000 protocol=tcp src-address-list="Black_scanners" comment=RemoteRules

malpermesi alvenantajn pakaĵojn de IP-adresoj kiuj estas nigralistigitaj dum havenskanado;

Tria regulo:

add action=add-src-to-address-list address-list="remote_port_1" address-list-timeout=1m chain=input dst-port=19000 protocol=tcp comment=RemoteRules

aldonas ip al la listo de gastigantoj, kiuj faris la ĝustan unuan frapon sur la ĝustan havenon (19000);
La sekvaj kvar reguloj estas:

add action=add-src-to-address-list address-list="Black_scanners" address-list-timeout=60m chain=input dst-port=19001 protocol=tcp src-address-list="remote_port_1" comment=RemoteRules
add action=add-src-to-address-list address-list="Black_scanners" address-list-timeout=60m chain=input dst-port=18999 protocol=tcp src-address-list="remote_port_1" comment=RemoteRules
add action=add-src-to-address-list address-list="Black_scanners" address-list-timeout=60m chain=input dst-port=16001 protocol=tcp src-address-list="remote_port_1" comment=RemoteRules
add action=add-src-to-address-list address-list="Black_scanners" address-list-timeout=60m chain=input dst-port=15999 protocol=tcp src-address-list="remote_port_1" comment=RemoteRules

kreu kaptitajn havenojn por tiuj, kiuj volas skani viajn havenojn, kaj se tiaj provoj estas detektitaj, nigrigu sian ip-on dum 60 minutoj, dum kiuj la unuaj du reguloj ne donos al tiaj gastigantoj la ŝancon frapi la ĝustajn havenojn;

Sekva regulo:

add action=add-src-to-address-list address-list="allow_remote_users" address-list-timeout=1m chain=input dst-port=16000 protocol=tcp src-address-list="remote_port_1" comment=RemoteRules

metas ip en la permesitan liston dum 1 minuto (sufiĉe por establi konekton), ĉar la dua ĝusta frapo estis farita sur la dezirata haveno (16000);

Sekva komando:

move [/ip firewall filter find comment=RemoteRules] 1

movas niajn regulojn supren laŭ la fajroŝirmila pretigĉeno, ĉar plej verŝajne ni jam havos malsamajn neregulojn agorditajn, kiuj malhelpos niajn ĵus kreitajn funkcii. La unua regulo en Mikrotik komenciĝas de nulo, sed ĉe mia aparato nulo estis okupita de enkonstruita regulo kaj estis neeble movi ĝin - mi movis ĝin al 1. Tial ni rigardas niajn agordojn - kien vi povas movi ĝin. kaj indiku la deziratan nombron.

Sekva agordo:

/ip firewall nat
add action=dst-nat chain=dstnat comment="remote_rdp_to_33" src-address-list="allow_remote_users" dst-port=33890 in-interface-list=WAN protocol=tcp to-addresses=192.168.1.33 to-ports=3389

plusendas arbitre elektitan havenon 33890 al la kutima RDP-haveno 3389 kaj la ip de la komputilo aŭ fina servilo, kiun ni bezonas. Ni kreas tiajn regulojn por ĉiuj necesaj internaj rimedoj, prefere fiksante eksternormajn (kaj malsamajn) eksterajn havenojn. Nature, la ip de internaj rimedoj devas esti aŭ statika aŭ fiksita sur la DHCP-servilo.

Nun nia Mikrotik estas agordita kaj ni bezonas simplan proceduron por ke la uzanto konektiĝu al nia interna RDP. Ĉar ni ĉefe havas Vindozo-uzantojn, ni kreas simplan bat-dosieron kaj nomas ĝin StartRDP.bat:

1.htm
1.rdp

respektive 1.htm enhavas la jenan kodon:

<img src="http://my_router.sn.mynetname.net:19000/1.jpg">
нажмите обновить страницу для повторного захода по RDP
<img src="http://my_router.sn.mynetname.net:16000/2.jpg">

ĝi enhavas du ligilojn al imagaj bildoj, kiuj troviĝas ĉe my_router.sn.mynetname.net - ni prenas ĉi tiun adreson de la Mikrotik DDNS-sistemo post ebligo de ĝi en nia Mikrotik: iru al la IP-> Nubo-menuo - kontrolu la markobutonon DDNS Enabled, klaku Apliki kaj kopiu la dns-nomon de nia enkursigilo. Sed ĉi tio estas nur necesa kiam la ekstera ip de la enkursigilo estas dinamika aŭ agordo kun pluraj interretaj provizantoj estas uzata.

La haveno en la unua ligilo: 19000 respondas al la unua haveno, sur kiu vi devas frapi, en la dua, respektive, al la dua. Inter la ligiloj estas mallonga instrukcio, kiu montras kion fari, se subite nia konekto estas interrompita pro mallongaj retaj problemoj - ni refreŝigas la paĝon, la RDP-haveno remalfermas por ni dum 1 minuto kaj nia sesio estas restarigita. Ankaŭ, la teksto inter la img-etikedoj formas mikro-prokraston por la retumilo, kiu reduktas la verŝajnecon de la unua pako esti liverita al la dua haveno (16000) - ĝis nun ne estis tiaj kazoj en du semajnoj da uzo (30). homoj).

Poste venas la 1.rdp-dosiero, kiun ni povas agordi unu por ĉiuj aŭ aparte por ĉiu uzanto (mi faris tion - estas pli facile pasigi pliajn 15 minutojn ol kelkajn horojn por konsulti tiujn, kiuj ne povis eltrovi ĝin)

screen mode id:i:2
use multimon:i:1
.....
connection type:i:6
networkautodetect:i:0
.....
disable wallpaper:i:1
.....
full address:s:my_router.sn.mynetname.net:33890
.....
username:s:myuserlogin
domain:s:mydomain

el la interesaj agordoj ĉi tie estas uzi multimon: i: 1 - ĉi tio inkluzivas la uzon de pluraj ekranoj - iuj bezonas tion, sed ili mem ne pensos ŝalti ĝin.

konektotipo: i: 6 kaj retoautodetekto: i: 0 - ĉar la plimulto de la Interreto estas super 10 Mbps, tiam ŝaltu konektotipo 6 (loka reto 10 Mbps kaj pli) kaj malŝaltu retonaŭtomatdetekton, ĉar se defaŭlte (aŭtomata) , tiam eĉ malofta malgranda reta latenco aŭtomate fiksas nian seancon al malrapida rapido dum longa tempo, kio povas krei rimarkindajn malfruojn en laboro, precipe en grafikaj programoj.

malŝalti tapeton: i: 1 - malŝalti la labortablan bildon
uzantnomo:s:myuserlogin - ni specifas la uzantan ensaluton, ĉar signifa parto de niaj uzantoj ne konas sian ensaluton
domain:s:mydomain - specifu la domajnan aŭ komputilan nomon

Sed se ni volas simpligi nian taskon krei konektan proceduron, tiam ni ankaŭ povas uzi PowerShell - StartRDP.ps1

Test-NetConnection -ComputerName my_router.sn.mynetname.net -Port 19000
Test-NetConnection -ComputerName my_router.sn.mynetname.net -Port 16000
mstsc /v:my_router.sn.mynetname.net:33890

Ankaŭ iom pri la RDP-kliento en Vindozo: MS faris longan vojon en optimumigado de la protokolo kaj ĝiaj serviloj kaj klientpartoj, efektivigis multajn utilajn funkciojn - kiel labori kun aparataro 3D, optimumigi la ekranrezolucion por via monitoro, multiekrano, kaj tiel plu. Sed kompreneble ĉio estas efektivigita en retrokongrua reĝimo, kaj se la kliento estas Windows 7, kaj la fora komputilo estas Windows 10, tiam RDP funkcios per protokolo-versio 7.0. Sed la avantaĝo estas, ke vi povas ĝisdatigi RDP-versiojn al pli lastatempaj versioj - ekzemple, vi povas ĝisdatigi la protokolan version de 7.0 (Vindozo 7) al 8.1. Tial, por la komforto de klientoj, necesas pliigi la versiojn de la servila parto kiel eble plej multe, kaj ankaŭ faligi ligilojn por ĝisdatigi al novaj versioj de RDP-protokolo-klientoj.

Kiel rezulto, ni havas simplan kaj relative sekuran teknologion por fora konekto al funkcianta komputilo aŭ fina servilo. Sed por pli sekura konekto, nia Port Knocking-metodo povas esti pli malfacile atakebla per pluraj grandordoj, aldonante havenojn por kontroli - vi povas aldoni 3,4,5,6 ... havenon laŭ la sama logiko. , kaj en ĉi tiu kazo rekta entrudiĝo en vian reton estos preskaŭ neebla .

Malplenaj dosieroj por krei malproksiman konekton al RDP.

fonto: www.habr.com