Hè periculosu di mantene RDP apertu in Internet?

Aghju spessu leghje l'opinione chì mantene un portu RDP (Remote Desktop Protocol) apertu à Internet hè assai inseguru è ùn deve esse fattu. Ma avete bisognu di dà accessu à RDP sia attraversu una VPN, o solu da certi indirizzi IP "bianchi".

Amministrà parechji Servitori Windows per e piccule imprese induve sò stati incaricati di furnisce l'accessu remotu à Windows Server per i contabili. Questa hè a tendenza muderna - travaglià da casa. Piuttostu rapidamente, aghju realizatu chì u turmentu di i cuntabili VPN hè un compitu ingrate, è a cullizzioni di tutte l'IP per a lista bianca ùn funziona micca, perchè l'indirizzi IP di e persone sò dinamichi.

Per quessa, aghju pigliatu a strada più simplice - rinviatu u portu RDP à l'esternu. Per acquistà l'accessu, i contabili anu avà bisognu di eseguisce RDP è inserisce u nome d'ospitu (cumpresu u portu), u nome d'utilizatore è a password.

In questu articulu, sparteraghju a mo spirienza (pusitiva è micca cusì positiva) è cunsiglii.

Risichi

Chì risicate aprendu u portu RDP?

1) Accessu micca autorizatu à i dati sensibili
Se qualchissia indovinà a password RDP, puderà ottene e dati chì vulete mantene private: status di u contu, saldi, dati di i clienti, ...

2) perdita di dati
Per esempiu, per via di un virus ransomware.
O una azzione deliberata da un attaccante.

3) Perdita di stazione di travagliu
I travagliadori anu bisognu di travaglià, ma u sistema hè cumprumissu è deve esse reinstallatu / restauratu / cunfiguratu.

4) Cumprumissu di a reta lucale
Sè un attaccu hà acquistatu accessu à un urdinatore Windows, allura da stu urdinatore hà da pudè accede à i sistemi chì sò inaccessibili da l'esternu, da Internet. Per esempiu, à sparte file, à stampanti di rete, etc.

Aghju avutu un casu induve Windows Server hà pigliatu un ransomware

è questu ransomware hà prima criptatu a maiò parte di i fugliali nantu à u C: drive è poi hà cuminciatu à criptà i fugliali in u NAS nantu à a reta. Siccomu u NAS era Synology, cù snapshots cunfigurati, aghju restauratu u NAS in 5 minuti, è reinstalatu Windows Server da zero.

Osservazioni è Raccomandazioni

Monitoraghju i Servitori Windows chì utilizanu Winlogbeat, chì mandanu logs à ElasticSearch. Kibana hà parechje visualizazioni, è aghju ancu stallatu un dashboard persunalizatu.
U monitoraghju stessu ùn pruteghja, ma aiuta à determinà e misure necessarie.

Eccu alcuni osservazioni:
a) RDP serà brute forzatu.
In unu di i servitori, aghju installatu RDP micca nantu à u portu standard 3389, ma in 443 - bè, mi disguise cum'è HTTPS. Probabilmente vale a pena cambià u portu da u standard, ma ùn farà micca assai bè. Eccu e statistiche di stu servitore:

Pò esse vistu chì in una settimana ci sò stati quasi 400 000 tentativi falluti di login via RDP.
Pò esse vistu chì ci sò stati tentativi di log in da 55 001 indirizzi IP (alcuni indirizzi IP eranu digià bluccati da mè).

Questu suggerisce direttamente a cunclusione chì avete bisognu di stabilisce fail2ban, ma

Ùn ci hè micca una tale utilità per Windows.

Ci hè un paru di prughjetti abbandunati in Github chì parenu fà questu, ma ùn aghju mancu pruvatu à stallà:
https://github.com/glasnt/wail2ban
https://github.com/EvanAnderson/ts_block

Ci sò ancu utilità pagate, ma ùn l'aghju micca cunsideratu.

Se cunnosci una utilità open source per questu scopu, per piacè sparte in i cumenti.

vagabonda: I cumenti suggerenu chì u portu 443 hè una mala scelta, è hè megliu di sceglie porti alti (32000+), perchè 443 hè scansatu più spessu, è ricunnosce RDP in questu portu ùn hè micca un prublema.

b) Ci sò certi nomi d'utilizatore chì l'attaccanti preferanu
Si pò vede chì a ricerca hè fatta in un dizziunariu cù nomi diffirenti.
Ma quì hè ciò chì aghju nutatu: un numeru significativu di tentativi utilizanu u nome di u servitore cum'è login. Raccomandazione: Ùn aduprate micca u listessu nome per l'urdinatore è l'utilizatore. Inoltre, qualchì volta pare ch'elli provanu à analizà u nome di u servitore in qualchì modu: per esempiu, per un sistema cù u nome DESKTOP-DFTHD7C, i più tentativi di login sò cù u nome DFTHD7C:

In cunsiquenza, sè vo avete un computer DESKTOP-MARIA, vi prubabilmente pruvà à accede cum'è l'utilizatore MARIA.

Un'altra cosa chì aghju nutatu da i logs: in a maiò parte di i sistemi, a maiò parte di i tentativi di login sò cù u nome "amministratore". È questu ùn hè micca senza mutivu, perchè in parechje versioni di Windows, questu utilizatore esiste. Inoltre, ùn pò micca esse eliminatu. Questu simplificheghja u compitu per l'attaccanti: invece di guessà un nome è una password, avete solu guessà a password.
Per via, u sistema chì hà pigliatu u ransomware hà avutu l'amministratore di l'utilizatore è a password Murmansk#9. Ùn sò micca sicuru cumu quellu sistema hè statu pirate, perchè aghju cuminciatu à monitorà ghjustu dopu à quellu incidente, ma pensu chì l'overkill hè prubabile.
Allora se l'utilizatore Amministratore ùn pò micca esse sguassatu, allora chì duvete fà? Pudete rinominà!

Raccomandazioni da stu paragrafu:

• Ùn aduprate micca u nome d'utilizatore in u nome di l'urdinatore
• assicuratevi chì ùn ci hè micca un utilizatore Administrator in u sistema
• aduprà password forti

Allora, aghju fighjulatu parechji Servitori Windows sottu u mo cuntrollu essendu furzatu brute per circa un paru d'anni avà, è senza successu.

Cumu sapè chì ùn hè micca successu?
Perchè in i screenshots sopra, pudete vede chì ci sò logs di chjama RDP successu, chì cuntenenu l'infurmazioni:

• da quale IP
• da quale computer (hostname)
• nome d'utilizatore
• infurmazione GeoIP

E cuntrollà quì regularmente - ùn anu trovu anomalie.

A propositu, se una IP particulari hè furzata da brutale particularmente dura, allora pudete bluccà IP individuali (o subnets) cum'è questu in 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 Block

In modu, Elastic, in più di Winlogbeat, hà ancu Auditbeat, chì ponu monitorà i schedari è i prucessi in u sistema. Ci hè ancu una applicazione SIEM (Security Information & Event Management) in Kibana. Aghju pruvatu i dui, ma ùn aghju micca vistu assai benefiziu - pare chì Auditbeat serà più utile per i sistemi Linux, è SIEM ùn m'hà micca dimustratu nunda intelligibile.

Ebbè, cunsiglii finali:

• Fate una copia di salvezza automatica regulare.
• installà l'aghjurnamenti di sicurezza in modu puntuale

Bonus: lista di 50 utilizatori chì sò stati più spessu usati per i tentativi di login RDP

"user.name: Descendente"
Count

dfthd7c (nome d'ospite)
842941

winsrv1 (hostname)
266525

AMMINISTRATORE
180678

amministratore
163842

amministratore
53541

Giulio
23101

servore
21983

steve
21936

Ghjuvanni
21927

paul
21913

accuglienza
21909

Mike
21899

ufficiu
21888

flat
21887

scanning
21867

david
21865

Vince
21860

u patrone
21855

Manager
21852

amministratore
21841

briAN
21839

amministratore
21837

Marque
21824

vastuni
21806

ADMIN
12748

ràdica
7772

AMMINISTRATORE
7325

Support
5577

SUPPORTO
5418

utilizatore
4558

Admin
2832

TEST
1928

mysql
1664

Admin
1652

OSTITU
1322

USER 1
1179

À SCAN
1121

SCAN
1032

AMMINISTRATORE
842

ADMINISTRATORE 1
525

BACKUP
518

MySqlAdmin
518

RECEPTION
490

USER 2
466

TEMP
452

SQLADMIN
450

USER 3
441

1
422

DIRETTORE
418

pruprietariu
410

Source: www.habr.com