Adesea am citit opinia că a păstra portul RDP (Remote Desktop Protocol) deschis pe internet nu este deloc sigur și că nu ar trebui să facem asta. Ar trebui să oferim acces la RDP fie prin VPN, fie doar din anumite adrese IP "albe".
Administrez câteva servere Windows pentru firme mici, unde mi s-a dat sarcina de a asigura accesul la distanță la serverele Windows pentru contabili. Aceasta este o tendință modernă – munca de acasă. Am realizat destul de repede că a constrânge contabilii să folosească VPN este o preocupare inutilă și că nu voi putea aduna toate IP-urile pentru lista albă, deoarece adresele IP ale oamenilor sunt dinamice.
Prin urmare, am ales cea mai simplă cale – am expus portul RDP. Acum, pentru acces, contabilii trebuie să deschidă RDP și să introducă numele gazdei (inclusiv portul), numele de utilizator și parola.
În acest articol, voi împărtăși experiențele mele (pozitive și mai puțin pozitive) și recomandările.
Riscuri
Ce riscați deschizând portul RDP?
1) Acces neautorizat la date sensibile
Dacă cineva reușește să ghicească parola pentru RDP, va putea obține datele pe care doriți să le păstrați private: soldurile conturilor, bilanțurile, datele clienților, …
2) Pierderea datelor
De exemplu, ca urmare a activității unui virus de tip ransomware.
Sau a unei acțiuni deliberate din partea unui atacator.
3) Pierderea stației de lucru
Angajații trebuie să lucreze, iar sistemul este compromis; trebuie reinstalat / recuperat / configurat.
4) Compromiterea rețelei locale
Dacă un atacator a obținut acces la un computer Windows, de pe acel computer va putea accesa sisteme care nu sunt disponibile din exterior, din internet. De exemplu, la partajările de fișiere, la imprimantele de rețea etc.
Am avut un caz în care serverul Windows a fost infectat cu ransomware
iar acest ransomware a criptat mai întâi majoritatea fișierelor de pe discul C:, apoi a început să cripteze fișierele pe NAS prin rețea. Deoarece NAS-ul era Synology, cu snapshot-uri configurate, am recuperat NAS-ul în 5 minute, în timp ce serverul Windows a trebuit reinstalat de la zero.
Observații și Recomandări
Monitorizez serverele Windows folosind , care trimit jurnale în ElasticSearch. În Kibana există câteva vizualizări, iar eu mi-am configurat un panou de control personalizat.
Monitorizarea în sine nu oferă protecție, dar ajută la stabilirea măsurilor necesare.
Iată câteva observații:
a) RDP va fi supus atacurilor de tip brut-force.
Pe unul dintre servere, am configurat RDP nu pe portul standard 3389, ci pe 443 - pentru a mă masca ca HTTPS. Probabil că ar trebui să schimb portul de la cel standard, dar nu va ajuta prea mult. Iată statisticile de pe acest server:
Se vede că, în decurs de o săptămână, au fost aproape 400.000 de încercări nereușite de conectare prin RDP.
Se observă că încercările de conectare au fost efectuate din 55.001 adrese IP (unele dintre aceste IP-uri au fost deja blocate de mine).
Se impune concluzia că trebuie să instalez fail2ban, dar
nu există o astfel de utilitate pentru Windows.
Există câteva proiecte abandonate pe GitHub care par că fac asta, dar nici măcar nu le-am încercat:
Mai există utilități plătite, dar nu le-am considerat.
Dacă știți o utilitate deschisă pentru acest scop - vă rugăm să împărtășiți în comentarii.
Actualizare: În comentarii mi s-a sugerat că portul 443 nu este o alegere bună, ci e mai bine să alegi porturi ridicate (32000+), deoarece 443 este scanat mai des și a identifica RDP pe acest port nu este o problemă.
Actualizare: În comentarii mi s-a spus că există o astfel de utilitate:
b) Există anumite nume de utilizator pe care infractorii preferă
Se observă că atacurile sunt efectuate într-un mod bazat pe un dicționar cu diferite nume.
Dar iată ce am observat: un număr semnificativ de încercări folosesc numele serverului ca nume de utilizator. Recomandare: nu folosiți același nume atât pentru computer, cât și pentru utilizator. În plus, uneori pare că se încearcă să se parseze numele serverului: de exemplu, pentru un sistem cu numele DESKTOP-DFTHD7C, cele mai multe încercări de conectare sunt din numele DFTHD7C:
Așadar, dacă aveți un computer DESKTOP-MARIA, probabil vor exista încercări de conectare cu utilizatorul MARIA.
De asemenea, ceea ce am observat din jurnalele de activitate: în majoritatea sistemelor, cele mai multe încercări de conectare sunt cu numele "administrator". Și nu este întâmplător, deoarece în multe versiuni de Windows, acest utilizator există. Mai mult decât atât, nu poate fi șters. Acest lucru simplifică sarcina pentru infractori: în loc să găsească un nume și o parolă, trebuie doar să ghicească parola.
Apropo, acel sistem care a căzut victimă unei atacuri ransomware avea utilizatorul Administrator și parola Murmansk#9. Nu sunt sigur cum a fost compromis acel sistem, deoarece am început să monitorizez tocmai după acel incident, dar cred că a fost o tentativă de tip bruteforce.
Așadar, dacă utilizatorul Administrator nu poate fi șters, ce se poate face? Poate fi redenumit!
Recomandările din acest punct:
- nu folosiți numele de utilizator în numele computerului
- asigurați-vă că nu există utilizați Administrator pe sistem
- folosiți parole puternice
Așa, eu observ cum câteva Servere Windows sunt supuse atacurilor brute-forcing de câțiva ani și fără succes.
De unde știu că fără succes?
Pentru că în capturile de ecran de mai sus se vede că există jurnale de accesuri reușite prin RDP, în care există informații:
- de la ce IP
- de pe ce computer (hostname)
- numele utilizatorului
- informații GeoIP
Și mă uit regulat acolo – nu am observat anomalii.
Apropo, dacă de la un anumit IP se fac atacuri brute-forcing destul de intens, se pot bloca anumite IP-uri (sau subrețele) astfel î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 are, pe lângă Winlogbeat, și , care poate monitoriza fișierele și procesele de pe sistem. Mai există o aplicație SIEM (Security Information & Event Management) în Kibana. Am încercat ambele, dar nu am văzut o utilitate semnificativă – pare că Auditbeat va fi mai util pentru sistemele Linux, iar SIEM nu mi-a arătat nimic clar până acum.
Și ultimele recomandări:
- faceți copii de siguranță automate regulat.
- instalați actualizările de securitate la timp
Bonus: lista cu 50 de utilizatori care au fost folosiți cel mai frecvent pentru încercările de acces prin RDP
"user.name: Descending"
Număr
dfthd7c (hostname)
842941
winsrv1 (hostname)
266525
ADMINISTRATOR
180678
Administratorul
163842
Administrator
53541
michael
23101
server
21983
steve
21936
john
21927
paul
21913
recepție
21909
mike
21899
birou
21888
scanner
21887
scan
21867
david
21865
chris
21860
owner
21855
manager
21852
administrateur
21841
brian
21839
administrador
21837
mark
21824
personal
21806
ADMIN
12748
ROOT
7772
ADMINISTRADOR
7325
SUPPORT
5577
SOPORTE
5418
USER
4558
admin
2832
TEST
1928
MySql
1664
Admin
1652
GUEST
1322
USER1
1179
SCANNER
1121
SCAN
1032
ADMINISTRATEUR
842
ADMIN1
525
BACKUP
518
MySqlAdmin
518
RECEPCIE
490
USER2
466
TEMP
452
SQLADMIN
450
USER3
441
1
422
MANAGER
418
OWNER
410
Sursa: habr.com
