Ho spesso letto opinioni secondo cui mantenere aperto il port RDP (Remote Desktop Protocol) su Internet è molto insicuro e non dovrebbe essere fatto. L'accesso a RDP dovrebbe essere fornito solo tramite VPN o da determinati indirizzi IP "white-list".
Amministro diversi server Windows per piccole aziende, dove mi è stato chiesto di garantire l'accesso remoto ai server Windows per i contabili. È una tendenza moderna: lavorare da casa. Ho rapidamente capito che costringere i contabili a utilizzare una VPN è un compito ingrato, e non è possibile raccogliere tutti gli IP per la white list, perché gli indirizzi IP delle persone sono dinamici.
Perciò ho scelto la soluzione più semplice: ho esposto il port RDP all'esterno. Ora, per accedere, i contabili devono avviare RDP e inserire il nome host (incluso il port), il nome utente e la password.
In questo articolo condividerò la mia esperienza (sia positiva che negativa) e alcune raccomandazioni.
Rischi
Quali rischi si corrono aprendo il port RDP?
1) Accesso non autorizzato a dati sensibili
Se qualcuno riesce a recuperare la password di RDP, potrebbe accedere a informazioni che desideri mantenere private: lo stato dei conti, i saldi, i dati dei clienti, …
2) Perdita di dati
Ad esempio, a causa dell'azione di un virus di crittografia.
O per azioni mirate di un malintenzionato.
3) Perdita della stazione di lavoro
I dipendenti devono lavorare, ma il sistema è compromesso e necessita di reinstallazione / ripristino / configurazione.
4) Compromesso della rete locale
Se un malintenzionato ha accesso a un computer Windows, può accedere a sistemi inaccessibili dall'esterno, da Internet. Ad esempio, a condivisioni di file, stampanti di rete, ecc.
Ho avuto un caso in cui un Windows Server è stato infettato da un software di crittografia
e questo software ha inizialmente criptato la maggior parte dei file sul disco C:, poi ha iniziato a criptare i file su NAS attraverso la rete. Poiché il NAS era un Synology con snapshot configurati, ho ripristinato il NAS in 5 minuti, mentre il Windows Server l'ho reinstallato da zero.
Osservazioni e Raccomandazioni
Monitoro i server Windows utilizzando , che invia i log a ElasticSearch. In Kibana ci sono diverse visualizzazioni e ho anche impostato un dashboard personalizzato.
Il monitoraggio di per sé non protegge, ma aiuta a determinare le misure necessarie.
Ecco alcune osservazioni:
a) RDP verrà attaccato con brute force.
Su uno dei server ho impostato RDP non sulla porta standard 3389, ma sulla 443 — per mimetizzarmi come HTTPS. Cambiare la porta da quella standard è probabilmente una buona idea, ma l'effetto è limitato. Ecco le statistiche di questo server:
Si può vedere che in una settimana ci sono stati quasi 400.000 tentativi falliti di accesso tramite RDP.
Si nota che i tentativi di accesso sono provenuti da 55.001 indirizzi IP (alcuni indirizzi IP erano già stati bloccati da me).
Qui si può trarre la conclusione che sia necessario installare fail2ban, ma
per Windows non esiste un'utility di questo tipo.
Ci sono un paio di progetti abbandonati su GitHub che sembrano farlo, ma non li ho nemmeno provati:
Ci sono anche utility a pagamento, ma non le ho prese in considerazione.
Se conoscete un'utility aperta per questo scopo — condividete nei commenti.
Update: Nei commenti è stato fatto notare che la porta 443 è una scelta poco efficace, e sarebbe meglio scegliere porte alte (32000+), perché la 443 viene scansionata più frequentemente, e riconoscere RDP su quella porta non è un problema.
Aggiornamento: Nei commenti è stato fatto notare che esiste un'utility di questo tipo:
b) Ci sono determinati username che i malintenzionati preferiscono.
È evidente che si sta effettuando un attacco basato su un dizionario con nomi diversi.
Ma quello che ho notato è che una parte significativa dei tentativi utilizza il nome del server come login. Raccomandazione: non utilizzare lo stesso nome per il computer e per l'utente. Inoltre, a volte il nome del server sembra essere in qualche modo analizzato: ad esempio, per un sistema con il nome DESKTOP-DFTHD7C, ci sono stati più tentativi di accesso con il nome DFTHD7C.
Di conseguenza, se avete un computer chiamato DESKTOP-MARIA, è probabile che ci siano tentativi di accesso con l'username MARIA.
Inoltre, ho notato dai log che sulla maggior parte dei sistemi, la maggior parte dei tentativi di accesso avviene con il nome "administrator". E non è una coincidenza, perché in molte versioni di Windows, questo utente esiste. Inoltre, non può essere eliminato. Ciò semplifica il lavoro per i malintenzionati: invece di dover indovinare nome e password, devono solo indovinare la password.
A proposito, il sistema che ha catturato il ransomware aveva l'utente Administrator e la password Murmansk#9. Non sono ancora sicuro di come abbiano compromesso quel sistema, perché ho iniziato a monitorare proprio dopo quel caso, ma penso che un attacco a forza bruta sia probabile.
Se l'utente Administrator non può essere eliminato, cosa si può fare? Può essere rinominato!
Le raccomandazioni di questo punto:
- non utilizzare il nome utente nel nome del computer
- assicurati che nel sistema non ci sia l'utente Administrator
- usa password robuste
Così, ho monitorato come alcuni Windows Server sotto il mio controllo siano stati attaccati con forza bruta per circa un paio d'anni, senza successo.
Come lo so, che non hanno avuto successo?
Perché negli screenshot sopra si vede che ci sono registri di accessi riusciti via RDP, che contengono informazioni:
- da quale IP
- da quale computer (hostname)
- nome utente
- Informazioni GeoIP
E controllo regolarmente — non ho riscontrato anomalie.
A proposito, se da un certo IP stanno forzando con particolare impegno, puoi 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, in Elastic, oltre a Winlogbeat, c'è anche , che può monitorare file e processi nel sistema. C'è anche un'applicazione SIEM (Gestione delle Informazioni e degli Eventi di Sicurezza) in Kibana. Ho provato entrambe le cose, ma non ho notato molti vantaggi — sembra che Auditbeat sia più utile per i sistemi Linux, mentre SIEM finora non mi ha mostrato nulla di concreto.
E infine, alcune raccomandazioni:
- effettuate regolari backup automatici.
- installate tempestivamente gli aggiornamenti di sicurezza.
Bonus: elenco di 50 utenti utilizzati più frequentemente per tentativi di accesso RDP.
"user.name: Descending"
Conteggio
dfthd7c (hostname)
842941
winsrv1 (hostname)
266525
AMMINISTRATORE
180678
amministratore
163842
Amministratore
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
OSPITE
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
PROPRIETARIO
410
Fonte: habr.com
