Am citit adesea opinia că menținerea unui port RDP (Remote Desktop Protocol) deschis către Internet este foarte nesigur și nu ar trebui făcută. Dar trebuie să oferiți acces la RDP fie printr-un VPN, fie numai de la anumite adrese IP „albe”.
Administrez mai multe servere Windows pentru firme mici, unde am fost însărcinat să ofer acces de la distanță la Windows Server pentru contabili. Aceasta este tendința modernă - lucrul de acasă. Destul de repede, mi-am dat seama că chinuirea contabililor VPN este o sarcină ingrată, iar colectarea tuturor IP-urilor pentru lista albă nu va funcționa, deoarece adresele IP ale oamenilor sunt dinamice.
Prin urmare, am luat cea mai simplă cale - am transmis portul RDP spre exterior. Pentru a avea acces, contabilii trebuie acum să ruleze RDP și să introducă numele de gazdă (inclusiv portul), numele de utilizator și parola.
În acest articol voi împărtăși experiența mea (pozitivă și nu atât de pozitivă) și recomandările.
Riscuri
Ce riști deschizând portul RDP?
1) Acces neautorizat la date sensibile
Dacă cineva ghicește parola RDP, va putea obține date pe care doriți să le păstrați private: starea contului, soldurile, datele clienților, ...
2) Pierderea datelor
De exemplu, ca urmare a unui virus ransomware.
Sau o acțiune deliberată a unui atacator.
3) Pierderea stației de lucru
Lucrătorii trebuie să lucreze, dar sistemul este compromis și trebuie reinstalat/restaurat/configurat.
4) Compromisul rețelei locale
Dacă un atacator a obținut acces la un computer Windows, atunci de pe acest computer va putea avea acces la sisteme care sunt inaccesibile din exterior, de pe Internet. De exemplu, la partajări de fișiere, la imprimante de rețea etc.
Am avut un caz în care Windows Server a prins un ransomware
iar acest ransomware a criptat mai întâi majoritatea fișierelor de pe unitatea C: și apoi a început să cripteze fișierele de pe NAS prin rețea. Deoarece NAS-ul era Synology, cu instantaneele configurate, am restaurat NAS-ul în 5 minute și am reinstalat Windows Server de la zero.
Observații și recomandări
Monitorizez serverele Windows folosind , care trimit jurnalele către ElasticSearch. Kibana are mai multe vizualizări și am configurat și un tablou de bord personalizat.
Monitorizarea în sine nu protejează, dar ajută la determinarea măsurilor necesare.
Iată câteva observații:
a) RDP va fi forțat.
Pe unul dintre servere, am instalat RDP nu pe portul standard 3389, ci pe 443 - ei bine, mă voi deghiza în HTTPS. Probabil că merită să schimbi portul din cel standard, dar nu prea va face bine. Iată statisticile de pe acest server:
Se poate observa că într-o săptămână au fost aproape 400 de încercări nereușite de autentificare prin RDP.
Se vede că au existat încercări de autentificare de la 55 de adrese IP (unele adrese IP au fost deja blocate de mine).
Acest lucru sugerează în mod direct concluzia că trebuie să setați fail2ban, dar
Nu există un astfel de utilitar pentru Windows.
Există câteva proiecte abandonate pe Github care par să facă acest lucru, dar nici măcar nu am încercat să le instalez:
Există și utilități plătite, dar nu le-am luat în considerare.
Dacă cunoașteți un utilitar open source în acest scop, vă rugăm să îl distribuiți în comentarii.
Actualizează: Comentariile sugerează că portul 443 este o alegere proastă și este mai bine să alegeți porturi înalte (32000+), deoarece 443 este scanat mai des, iar recunoașterea RDP pe acest port nu este o problemă.
b) Există anumite nume de utilizator pe care atacatorii le preferă
Se poate observa că căutarea se efectuează într-un dicționar cu denumiri diferite.
Dar iată ce am observat: un număr semnificativ de încercări folosesc numele serverului ca logare. Recomandare: Nu folosiți același nume pentru computer și utilizator. Mai mult decât atât, uneori se pare că încearcă să analizeze cumva numele serverului: de exemplu, pentru un sistem cu numele DESKTOP-DFTHD7C, cele mai multe încercări de autentificare sunt cu numele DFTHD7C:
În consecință, dacă aveți un computer DESKTOP-MARIA, probabil că veți încerca să vă conectați ca utilizator MARIA.
Un alt lucru pe care l-am observat din jurnale: pe majoritatea sistemelor, cele mai multe încercări de autentificare sunt cu numele „administrator”. Și acest lucru nu este fără motiv, deoarece în multe versiuni de Windows, acest utilizator există. În plus, nu poate fi șters. Acest lucru simplifică sarcina atacatorilor: în loc să ghiciți un nume și o parolă, trebuie doar să ghiciți parola.
Apropo, sistemul care a prins ransomware-ul avea utilizatorul Administrator și parola Murmansk#9. Încă nu sunt sigur cum a fost piratat acel sistem, pentru că am început să monitorizez imediat după incidentul respectiv, dar cred că este probabil că exagerarea.
Deci, dacă utilizatorul Administrator nu poate fi șters, atunci ce ar trebui să faceți? Îl poți redenumi!
Recomandări din acest paragraf:
- nu utilizați numele de utilizator în numele computerului
- asigurați-vă că nu există niciun utilizator Administrator pe sistem
- utilizați parole puternice
Așadar, mă uit la câteva servere Windows aflate sub controlul meu cum sunt forțate brutal de aproximativ câțiva ani și fără succes.
De unde știu că nu a reușit?
Pentru că în capturile de ecran de mai sus puteți vedea că există jurnalele de apeluri RDP reușite, care conțin informațiile:
- din care IP
- de pe ce computer (nume de gazdă)
- Nume de utilizator
- Informații GeoIP
Și verific acolo regulat - nu s-au găsit anomalii.
Apropo, dacă un anumit IP este forțat în mod deosebit de greu, atunci puteți bloca IP-uri individuale (sau subrețele) ca acesta în 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 BlockApropo, Elastic, pe lângă Winlogbeat, mai are , care poate monitoriza fișierele și procesele din sistem. Există, de asemenea, o aplicație SIEM (Security Information & Event Management) în Kibana. Le-am încercat pe ambele, dar nu am văzut prea multe beneficii - se pare că Auditbeat va fi mai util pentru sistemele Linux, iar SIEM nu mi-a arătat încă nimic inteligibil.
Ei bine, recomandări finale:
- Faceți copii de rezervă automate regulate.
- instalați actualizările de securitate în timp util
Bonus: listă cu 50 de utilizatori care au fost cel mai des folosiți pentru încercările de conectare RDP
„user.name: Descendent”
Conta
dfthd7c (nume gazdă)
842941
winsrv1 (nume gazdă)
266525
ADMINISTRATOR
180678
administrator
163842
Administrator
53541
michael
23101
serverul
21983
Steve
21936
Ioan
21927
paul
21913
recepție
21909
mike
21899
birou
21888
scanerului
21887
scanare
21867
david
21865
Chris
21860
proprietar
21855
manager
21852
Administrateur
21841
Brian
21839
administrator
21837
marca
21824
personal
21806
ADMIN
12748
ROOT
7772
ADMINISTRATOR
7325
SUPORT
5577
MEDIU
5418
USER
4558
admin
2832
TEST
1928
MySql
1664
admin
1652
PENSIUNEA
1322
UTILIZATOR1
1179
A SCANA
1121
SCAN
1032
ADMINISTRATOR
842
ADMIN1
525
BACKUP
518
MySqlAdmin
518
RECEPŢIE
490
UTILIZATOR2
466
TEMP
452
SQLADMIN
450
UTILIZATOR3
441
1
422
MANAGER
418
PROPRIETAR
410
Sursa: www.habr.com