Fjernarbeid på kontoret. RDP, Port Knocking, Mikrotik: enkelt og sikkert

På grunn av covid-19-viruspandemien og generell karantene i mange land, er den eneste måten for mange bedrifter å fortsette å jobbe på, ekstern tilgang til arbeidsplasser via Internett. Det finnes mange relativt sikre metoder for eksternt arbeid - men gitt omfanget av problemet, er det som trengs en metode som er enkel for enhver bruker å koble til kontoret eksternt og uten behov for ytterligere innstillinger, forklaringer, kjedelige konsultasjoner og langvarige konsultasjoner. bruksanvisning. Denne metoden er elsket av mange administratorer RDP (Remote Desktop Protocol). Å koble direkte til en arbeidsstasjon via RDP løser ideelt sett problemet vårt, bortsett fra en stor flue i salven - å holde RDP-porten åpen for Internett er veldig utrygt. Derfor foreslår jeg nedenfor en enkel, men pålitelig metode for beskyttelse.Fjernarbeid på kontoret. RDP, Port Knocking, Mikrotik: enkelt og sikkert

Siden jeg ofte kommer over små organisasjoner der Mikrotik-enheter brukes som en Internett-tilkobling, vil jeg nedenfor vise hvordan du implementerer dette på Mikrotik, men Port Knocking-beskyttelsesmetoden kan enkelt implementeres på andre enheter av høyere klasse med lignende input-ruterinnstillinger og brannmur

Kort om Port Knocking. Den ideelle eksterne beskyttelsen av et nettverk koblet til Internett er når alle ressurser og porter er lukket fra utsiden av en brannmur. Og selv om en ruter med en slik konfigurert brannmur ikke reagerer på noen måte på pakker som kommer utenfra, lytter den til dem. Derfor kan du konfigurere ruteren slik at når den mottar en bestemt (kode) sekvens av nettverkspakker på forskjellige porter, vil den (ruteren) for IP-en der pakkene kom fra, nekte tilgang til visse ressurser (porter, protokoller osv. .).

Nå til poenget. Jeg vil ikke gi en detaljert beskrivelse av å sette opp en brannmur på Mikrotik - Internett er fullt av kvalitetskilder for dette. Ideelt sett blokkerer en brannmur alle innkommende pakker, men

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

Tillater innkommende trafikk fra allerede etablerte (etablerte, relaterte) forbindelser.
Nå konfigurerer vi Port Knocking på 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

Nå mer detaljert:

de to første reglene

/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

forby innkommende pakker fra IP-adresser som ble svartelistet under portskanning;

Tredje regel:

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

legger til ip til listen over verter som gjorde riktig første banking på ønsket port (19000);
Følgende fire regler:

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

opprette trap-porter for de som ønsker å skanne portene dine, og når slike forsøk oppdages, svartelister de IP-en deres i 60 minutter, hvor de to første reglene ikke vil gi slike verter muligheten til å banke på de riktige portene;

Neste regel:

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

setter ip-en i listen over tillatte i 1 minutt (nok til å etablere en forbindelse), siden den andre riktige bankingen gjøres på ønsket port (16000);

Neste kommando:

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

flytter reglene våre oppover i prosesseringskjeden for brannmuren, siden vi mest sannsynlig allerede har konfigurert forskjellige forbudsregler som vil hindre de nyopprettede i å fungere. Den aller første regelen i Mikrotik starter fra null, men på enheten min var null okkupert av en innebygd regel og det var umulig å flytte den - jeg flyttet den til 1. Derfor ser vi på innstillingene våre - hvor vi kan flytte den og angi ønsket nummer.

Neste innstilling:

/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

videresender en tilfeldig valgt port 33890 til en vanlig RDP-port 3389 og IP-en til datamaskinen eller terminalserveren vi trenger. Vi lager slike regler for alle nødvendige interne ressurser, fortrinnsvis ved å sette ikke-standardiserte (og forskjellige) eksterne porter. Naturligvis må IP-en til interne ressurser enten være statisk eller tilordnet en DHCP-server.

Nå er vår Mikrotik konfigurert og vi trenger en enkel prosedyre for brukeren å koble til vår interne RDP. Siden vi stort sett har Windows-brukere, lager vi en enkel bat-fil og kaller den StartRDP.bat:

1.htm
1.rdp

følgelig inneholder 1.htm følgende kode:

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

her inneholder to lenker til imaginære bilder som ligger på adressen my_router.sn.mynetname.net - vi tar denne adressen fra Mikrotik DDNS-systemet etter å ha aktivert dette i vår Mikrotik: gå til IP->Cloud-menyen - sjekk DDNS Enabled klikker du på Bruk og kopierer dns-navnet til ruteren vår. Men dette er bare nødvendig når den eksterne IP-en til ruteren er dynamisk eller en konfigurasjon med flere Internett-leverandører brukes.

Porten i den første lenken: 19000 tilsvarer den første porten du må banke på, i den andre tilsvarer den den andre. Mellom lenkene er det en kort instruksjon som viser hva vi skal gjøre hvis tilkoblingen vår plutselig blir avbrutt på grunn av korte nettverksproblemer - vi oppdaterer siden, RDP-porten åpnes igjen for oss i 1 minutt og økten vår gjenopprettes. Teksten mellom img-taggene skaper også en mikroforsinkelse for nettleseren, noe som reduserer sannsynligheten for at den første pakken blir levert til den andre porten (16000) - så langt har det ikke vært slike tilfeller på to ukers bruk (30 mennesker).

Deretter kommer 1.rdp-filen, som vi kan konfigurere en for alle eller separat for hver bruker (det er det jeg gjorde - det er lettere å bruke 15 minutter ekstra enn flere timer på å konsultere de som ikke kunne finne ut av det)

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

En av de interessante innstillingene her er bruk multimon:i:1 - dette inkluderer bruk av flere skjermer - noen mennesker trenger dette, men de tenker ikke på å slå det på selv.

tilkoblingstype:i:6 og networkautodetect:i:0 - siden mesteparten av Internett er over 10 Mbit, aktiver deretter tilkoblingstype 6 (lokalt nettverk 10 Mbit og over) og deaktiver nettverksautodetect, siden hvis standarden er (auto), så setter selv en sjelden liten Network latency automatisk hastigheten for økten vår til en lavere hastighet i lang tid, noe som kan skape merkbare forsinkelser i arbeidet, spesielt i grafikkprogrammer.

deaktiver bakgrunnsbilde:i:1 - deaktiver skrivebordsbildet
brukernavn:s:myuserlogin - vi angir brukerinnloggingen, siden en betydelig del av brukerne våre ikke kjenner deres innlogging
domene:s:mittdomene - angi domene- eller datamaskinnavnet

Men hvis vi ønsker å forenkle oppgaven med å lage en tilkoblingsprosedyre, kan vi også bruke 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

Også litt om RDP-klienten i Windows: MS har kommet langt med å optimalisere protokollen og dens server- og klientdeler, implementere mange nyttige funksjoner - som å jobbe med hardware 3D, optimalisere skjermoppløsningen for skjermen din, multi-skjerm, etc. Men selvfølgelig er alt implementert i bakoverkompatibilitetsmodus, og hvis klienten er Windows 7 og den eksterne PC-en er Windows 10, vil RDP fungere med protokollversjon 7.0. Men heldigvis kan du oppdatere RDP-versjoner til nyere versjoner – for eksempel kan du oppgradere protokollversjonen fra 7.0 (Windows 7) til 8.1. Derfor, for å gjøre det enklere for klienter, må du maksimere versjonene av serverdelen, og også gi lenker for å oppdatere til nye versjoner av RDP-protokollklienter.

Som et resultat har vi en enkel og relativt sikker teknologi for fjerntilkobling til en arbeids-PC eller terminalserver. Men for en sikrere tilkobling kan portbankemetoden vår gjøres vanskeligere å angripe med flere størrelsesordener, ved å legge til porter for å sjekke - ved å bruke samme logikk kan du legge til 3,4,5,6...port og i dette tilfellet vil direkte inntrenging i nettverket ditt være nesten umulig .

Filforberedelser for å opprette en ekstern tilkobling til RDP.

Kilde: www.habr.com

Legg til en kommentar