Spesso ho letto l'opinione che lasciare la porta RDP (Remote Desktop Protocol) aperta su Internet sia molto pericoloso e che non si dovrebbe fare. E invece sarebbe bene fornire accesso a RDP solo tramite VPN o solamente da determinati indirizzi IP "autorizzati".
Amministro diversi Windows Server per piccole aziende, in cui mi è stato chiesto di garantire l'accesso remoto a Windows Server per i contabili. È una tendenza moderna — lavorare da casa. Ho capito piuttosto rapidamente che costringere i contabili a utilizzare una VPN è frustrante, e che non è possibile raccogliere tutti gli IP da inserire nella lista bianca, poiché gli indirizzi IP delle persone sono dinamici.
Pertanto, ho scelto la strada più semplice: ho esposto la porta RDP. Ora, per accedere, i contabili devono avviare RDP e inserire il nome host (incluso la porta), il nome utente e la password.
In questo articolo condividerò la mia esperienza (sia positiva che negativa) e le mie raccomandazioni.
Rischi
Quali rischi corri aprendo la porta RDP?
1) Accesso non autorizzato a dati sensibili
Se qualcuno indovina la password di RDP, potrà accedere ai dati che desideri mantenere privati: stato dei conti, bilanci, dati dei clienti, …
2) Perdita di dati
Ad esempio, a causa dell'azione di un virus di tipo ransomware.
O a causa dell'azione mirata di un aggressore.
3) Perdita della stazione di lavoro
I dipendenti devono lavorare, ma il sistema è compromesso, è necessario reinstallare / ripristinare / configurare.
4) Compromissione della rete locale
Se un aggressore ha ottenuto accesso a un computer Windows, potrà accedere anche a sistemi che non sono accessibili dall'esterno, da Internet. Ad esempio, a condivisioni di file, stampanti di rete, ecc.
Ho avuto un caso in cui un Windows Server è stato colpito da un ransomware
e questo ransomware ha inizialmente criptato la maggior parte dei file sul disco C:, per poi iniziare a crittografare i file sul NAS tramite rete. Poiché il NAS era un Synology con snapshot configurati, ho ripristinato il NAS in 5 minuti, mentre ho dovuto reinstallare Windows Server da zero.
Osservazioni e raccomandazioni
Monitora i Windows Server utilizzando , che invia i log a ElasticSearch. In Kibana ci sono diverse visualizzazioni e ho anche configurato un dashboard personalizzato.
Il monitoraggio di per sé non protegge, ma aiuta a determinare le misure necessarie.
Ecco alcune osservazioni:
a) RDP verrà sottoposto a brute-force.
Su uno dei server ho configurato RDP su una porta non standard, la 443 — per mascherarlo come HTTPS. Cambiare la porta da quella standard probabilmente ha senso, ma l'efficacia non è così elevata. Ecco le statistiche di questo server:
Si vede che nella settimana ci sono state quasi 400.000 tentativi di accesso falliti tramite RDP.
Si nota che i tentativi di accesso sono stati da 55.001 indirizzi IP (alcuni degli indirizzi IP erano già stati bloccati da me).
Da questo emerge chiaramente che è necessario installare fail2ban, ma
per Windows non esiste uno strumento del genere.
Ci sono un paio di progetti abbandonati su GitHub che sembrano farlo, ma non ho nemmeno provato a installarli:
Ci sono anche strumenti a pagamento, ma non li ho considerati.
Se conoscete uno strumento open source per questo scopo, condividetelo nei commenti.
Aggiornamento: Nei commenti mi hanno fatto notare che la porta 443 non è una scelta saggia, e sarebbe meglio optare per porte elevate (32000+), perché la 443 viene scansionata più frequentemente, e riconoscere RDP su quella porta non è un problema.
Aggiornamento: Nei commenti mi hanno fatto sapere che esiste uno strumento del genere:
b) Ci sono determinati username che gli malintenzionati preferiscono.
Si vede che il tentativo avviene tramite un attacco a dizionario con diversi nomi.
Ma quello che ho notato è che un numero significativo di tentativi riguarda l'utilizzo del nome del server come login. Raccomandazione: non utilizzate lo stesso nome per il computer e per l'utente. Inoltre, a volte il nome del server viene tentato di essere parsato in modo diverso: ad esempio, per un sistema con nome DESKTOP-DFTHD7C ci sono stati il massimo di tentativi d'accesso con il nome DFTHD7C:
Di conseguenza, se avete un computer chiamato DESKTOP-MARIA, probabilmente ci saranno tentativi di accesso con l'utente MARIA.
Inoltre, da ciò che ho notato nei log: sulla maggior parte dei sistemi, la maggior parte dei tentativi di accesso avviene con il nome "administrator". E non è casuale, perché in molte versioni di Windows, questo utente esiste. Inoltre, non può essere eliminato. Questo semplifica il compito per i malintenzionati: invece di dover indovinare nome e password, devono solo indovinare la password.
Tra l'altro, il sistema che ha catturato il ransomware aveva l'utente Administrator e la password Murmansk#9. Non sono sicuro di come sia stata violata quella macchina, perché ho iniziato a monitorarla proprio dopo quell'episodio, ma credo che l'attacco a dizionario sia probabile.
Allora, se non è possibile eliminare l'utente Administrator, cosa si può fare? Si può rinominare!
Raccomandazioni di questo punto:
- non utilizzare il nome utente nel nome del computer
- assicurati che non ci siano utenti Administrator nel sistema
- utilizza password sicure
In questo modo, osservo come diversi Windows Server sotto il mio controllo vengono continuamente attaccati con brute force da circa un paio d'anni, e senza successo.
Come lo so che senza successo?
Perché negli screenshot sopra si vede che ci sono log di accessi riusciti tramite RDP, nei quali c'è informazione:
- da quale IP
- da quale computer (hostname)
- nome utente
- informazioni GeoIP
E io guardo regolarmente — non ho trovato anomalie.
A proposito, se da un certo IP si sta tentando un brute force in modo particolarmente assiduo, è possibile bloccare singoli IP (o sottoreti) in questo modo 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 BlockA proposito, Elastic offre, oltre a Winlogbeat, anche , che può monitorare file e processi nel sistema. C'è anche un'applicazione SIEM (Security Information & Event Management) in Kibana. Ho provato entrambe, ma non ho visto particolari vantaggi — sembra che Auditbeat sia più utile per i sistemi Linux, mentre SIEM fino ad ora non mi ha mostrato nulla di chiaro.
Ecco quindi le raccomandazioni finali:
- fai regolari backup automatici.
- installa aggiornamenti di sicurezza in tempo.
Bonus: lista di 50 utenti che sono stati più frequentemente utilizzati per tentativi di accesso tramite RDP
"user.name: Descending"
Conteggio
dfthd7c (hostname)
842941
winsrv1 (hostname)
266525
ADMINISTRATOR
180678
administrator
163842
Administrator
53541
michael
23101
server
21983
steve
21936
john
21927
paul
21913
reception
21909
mike
21899
office
21888
scanner
21887
scan
21867
david
21865
chris
21860
proprietario
21855
manager
21852
administrateur
21841
brian
21839
administrador
21837
mark
21824
staff
21806
ADMIN
12748
ROOT
7772
ADMINISTRADOR
7325
SUPPORT
5577
SOPORTE
5418
UTENTE
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
RECEPTION
490
USER2
466
TEMP
452
SQLADMIN
450
USER3
441
1
422
MANAGER
418
Spesso ho letto pareri che tenere aperto il porto RDP (Remote Desktop Protocol) su Internet è piuttosto insicuro e non si dovrebbe fare.
410
Fonte: habr.com
