Jeg har ofte læst den opfattelse, at det er meget usikkert at holde en RDP-port (Remote Desktop Protocol) åben til internettet og ikke bør gøres. Men du skal give adgang til RDP enten via en VPN eller kun fra visse "hvide" IP-adresser.
Jeg administrerer adskillige Windows-servere for små firmaer, hvor jeg har fået til opgave at give revisorer fjernadgang til Windows Server. Dette er den moderne trend - at arbejde hjemmefra. Ret hurtigt indså jeg, at det er en utaknemmelig opgave at plage VPN-revisorer, og at indsamle alle IP'er til hvidlisten vil ikke fungere, fordi folks IP-adresser er dynamiske.
Derfor tog jeg den enkleste vej - videresendte RDP-porten til ydersiden. For at få adgang skal revisorer nu køre RDP og indtaste værtsnavnet (inklusive port), brugernavn og adgangskode.
I denne artikel vil jeg dele mine erfaringer (positive og ikke så positive) og anbefalinger.
Risici
Hvad risikerer du ved at åbne RDP-porten?
1) Uautoriseret adgang til følsomme data
Hvis nogen gætter RDP-adgangskoden, vil de være i stand til at få data, som du vil holde private: kontostatus, saldi, kundedata, ...
2) Tab af data
For eksempel som følge af en ransomware-virus.
Eller en bevidst handling fra en angriber.
3) Tab af arbejdsstation
Arbejdere skal arbejde, men systemet er kompromitteret og skal geninstalleres/gendannes/konfigureres.
4) Kompromittering af det lokale netværk
Hvis en angriber har fået adgang til en Windows-computer, så vil han fra denne computer kunne få adgang til systemer, der er utilgængelige udefra, fra internettet. For eksempel til fildelinger, til netværksprintere osv.
Jeg havde et tilfælde, hvor Windows Server fangede en ransomware
og denne ransomware krypterede først de fleste af filerne på C:-drevet og begyndte derefter at kryptere filerne på NAS'en over netværket. Da NAS'en var Synology, med snapshots konfigureret, gendannede jeg NAS'en på 5 minutter og geninstallerede Windows Server fra bunden.
Observationer og anbefalinger
Jeg overvåger Windows-servere vha , som sender logfiler til ElasticSearch. Kibana har flere visualiseringer, og jeg har også opsat et brugerdefineret dashboard.
Overvågning i sig selv beskytter ikke, men det hjælper med at bestemme de nødvendige foranstaltninger.
Her er nogle observationer:
a) RDP vil blive brutalt forceret.
På en af serverne installerede jeg RDP ikke på standardporten 3389, men på 443 - ja, jeg vil forklæde mig som HTTPS. Det er nok værd at ændre porten fra standarden, men det vil ikke gøre meget godt. Her er statistikken fra denne server:
Det kan ses, at der på en uge var næsten 400 mislykkede forsøg på at logge ind via RDP.
Det kan ses, at der var forsøg på at logge ind fra 55 IP-adresser (nogle IP-adresser var allerede blokeret af mig).
Dette antyder direkte konklusionen om, at du skal indstille fail2ban, men
Der er ikke noget sådant værktøj til Windows.
Der er et par forladte projekter på Github, der ser ud til at gøre dette, men jeg har ikke engang prøvet at installere dem:
Der er også betalte hjælpeprogrammer, men jeg har ikke overvejet dem.
Hvis du kender et open source-værktøj til dette formål, bedes du dele det i kommentarerne.
Opdatering: Kommentarerne antydede, at port 443 er et dårligt valg, og det er bedre at vælge høje porte (32000+), fordi 443 scannes oftere, og det er ikke et problem at genkende RDP på denne port.
Update: Kommentarerne antydede, at et sådant værktøj eksisterer:
b) Der er visse brugernavne, som angribere foretrækker
Det kan ses, at søgningen udføres i en ordbog med forskellige navne.
Men her er, hvad jeg bemærkede: et betydeligt antal forsøg bruger servernavnet som login. Anbefaling: Brug ikke samme navn til computeren og brugeren. Desuden ser det nogle gange ud til, at de forsøger at analysere servernavnet på en eller anden måde: for et system med navnet DESKTOP-DFTHD7C er de fleste forsøg på at logge ind med navnet DFTHD7C:
Derfor, hvis du har en DESKTOP-MARIA-computer, vil du sandsynligvis forsøge at logge ind som MARIA-brugeren.
En anden ting, jeg bemærkede fra logfilerne: på de fleste systemer er de fleste forsøg på at logge ind med navnet "administrator". Og det er ikke uden grund, for i mange versioner af Windows findes denne bruger. Desuden kan den ikke slettes. Dette forenkler opgaven for angribere: I stedet for at gætte et navn og en adgangskode behøver du kun at gætte adgangskoden.
Forresten havde systemet, der fangede ransomwaren, brugeren Administrator og adgangskoden Murmansk#9. Jeg er stadig ikke sikker på, hvordan det system blev hacket, for jeg begyndte at overvåge lige efter den hændelse, men jeg tror, at overkill er sandsynligt.
Så hvis administratorbrugeren ikke kan slettes, hvad skal du så gøre? Du kan omdøbe den!
Anbefalinger fra dette afsnit:
- Brug ikke brugernavnet i computernavnet
- sørg for, at der ikke er nogen administratorbruger på systemet
- bruge stærke adgangskoder
Så jeg har set flere Windows-servere under min kontrol blive brute-forced i omkring et par år nu, og uden held.
Hvordan ved jeg, at det er mislykket?
For på skærmbillederne ovenfor kan du se, at der er logfiler over vellykkede RDP-opkald, som indeholder oplysningerne:
- fra hvilken IP
- fra hvilken computer (værtsnavn)
- brugernavn
- GeoIP oplysninger
Og jeg tjekker der jævnligt - ingen anomalier er fundet.
Forresten, hvis en bestemt IP bliver brute-forced særligt hårdt, så kan du blokere individuelle IP'er (eller undernet) som dette i PowerShell:
New-NetFirewallRule -Direction Inbound -DisplayName "fail2ban" -Name "fail2ban" -RemoteAddress ("185.143.0.0/16", "185.153.0.0/16", "193.188.0.0/16") -Action BlockDet har Elastic, udover Winlogbeat, også , som kan overvåge filer og processer på systemet. Der er også en SIEM-applikation (Security Information & Event Management) i Kibana. Jeg prøvede begge dele, men så ikke den store fordel - det ser ud til, at Auditbeat vil være mere nyttigt til Linux-systemer, og SIEM har endnu ikke vist mig noget forståeligt.
Nå, endelige anbefalinger:
- Lav regelmæssige automatiske sikkerhedskopier.
- installere sikkerhedsopdateringer rettidigt
Bonus: liste over 50 brugere, der oftest blev brugt til RDP-loginforsøg
"bruger.navn: Faldende"
Tælle
dfthd7c (værtsnavn)
842941
winsrv1 (værtsnavn)
266525
ADMINISTRATOR
180678
administrator
163842
Administrator
53541
michael
23101
server
21983
steve
21936
john
21927
paul
21913
modtagelse
21909
mike
21899
kontor
21888
scanner
21887
scanne
21867
david
21865
chris
21860
ejer
21855
leder
21852
πώς τα παράθυρα XNUMX να δείτε πόσο CPU που χρησιμοποιείται;
21841
brian
21839
administrator
21837
markere
21824
personale
21806
ADMIN
12748
ROOT
7772
ADMINISTRADØR
7325
SUPPORT
5577
SUPPORT
5418
BRUGER
4558
admin
2832
TEST
1928
MySql
1664
Admin
1652
GÆST
1322
User1
1179
AT SCANNE
1121
SCAN
1032
ADMINISTRATOR
842
ADMIN1
525
BACKUP
518
MySqlAdmin
518
RECEPTION
490
User2
466
TEMP
452
SQLADMIN
450
User3
441
1
422
MANAGER
418
EJER
410
Kilde: www.habr.com