Ho letto spesso l'opinione secondo cui mantenere aperta una porta RDP (Remote Desktop Protocol) su Internet è molto pericoloso e non dovrebbe essere fatto. Ma è necessario consentire l'accesso all'RDP tramite una VPN o solo da determinati indirizzi IP "bianchi".
Amministro diversi server Windows per piccole aziende in cui mi è stato assegnato il compito di fornire accesso remoto a Windows Server per i contabili. Questa è la tendenza moderna: lavorare da casa. Ben presto mi sono reso conto che tormentare i contabili delle VPN è un compito ingrato e che raccogliere tutti gli IP per la lista bianca non funzionerebbe, perché gli indirizzi IP delle persone sono dinamici.
Pertanto, ho scelto la strada più semplice: ho inoltrato la porta RDP all'esterno. Per ottenere l'accesso, i contabili ora devono eseguire RDP e inserire il nome host (inclusa la porta), nome utente e password.
In questo articolo condividerò la mia esperienza (positiva e non così positiva) e i miei consigli.
Rischi
Cosa stai rischiando aprendo la porta RDP?
1) Accesso non autorizzato a dati sensibili
Se qualcuno indovina la password RDP, potrà ottenere i dati che desideri mantenere privati: stato del conto, saldi, dati del cliente, ...
2) Perdita di dati
Ad esempio, a seguito di un virus ransomware.
O un'azione deliberata da parte di un aggressore.
3) Perdita di posto di lavoro
I lavoratori devono lavorare, ma il sistema è compromesso e deve essere reinstallato/ripristinato/configurato.
4) Compromissione della rete locale
Se un utente malintenzionato ha avuto accesso a un computer Windows, da questo computer potrà accedere a sistemi inaccessibili dall'esterno, da Internet. Ad esempio, alle condivisioni di file, alle stampanti di rete, ecc.
Ho avuto un caso in cui Windows Server ha rilevato un ransomware
e questo ransomware ha prima crittografato la maggior parte dei file sull'unità C: e poi ha iniziato a crittografare i file sul NAS in rete. Poiché il NAS era Synology, con le istantanee configurate, ho ripristinato il NAS in 5 minuti e ho reinstallato Windows Server da zero.
Osservazioni e raccomandazioni
Controllo i server Windows utilizzando , che inviano i log a ElasticSearch. Kibana ha diverse visualizzazioni e ho anche impostato una dashboard personalizzata.
Il monitoraggio in sé non protegge, ma aiuta a determinare le misure necessarie.
Ecco alcune osservazioni:
a) L’RDP sarà sottoposto a forza bruta.
Su uno dei server, ho installato RDP non sulla porta standard 3389, ma su 443 - beh, mi travestirò da HTTPS. Probabilmente vale la pena cambiare la porta da quella standard, ma non servirà a molto. Ecco le statistiche di questo server:
Si può notare che in una settimana sono stati quasi 400 i tentativi falliti di accesso tramite RDP.
Si può vedere che ci sono stati tentativi di accesso da 55 indirizzi IP (alcuni indirizzi IP erano già stati bloccati da me).
Ciò suggerisce direttamente la conclusione che è necessario impostare fail2ban, ma
Non esiste una tale utilità per Windows.
Ci sono un paio di progetti abbandonati su Github che sembrano fare questo, ma non ho nemmeno provato a installarli:
Ci sono anche utenze a pagamento, ma non le ho considerate.
Se conosci un'utilità open source per questo scopo, condividila nei commenti.
Aggiornanento: I commenti suggeriscono che la porta 443 è una cattiva scelta, ed è meglio scegliere porte alte (32000+), perché la 443 viene scansionata più spesso e riconoscere l'RDP su questa porta non è un problema.
b) Esistono alcuni nomi utente preferiti dagli aggressori
Si può vedere che la ricerca viene effettuata in un dizionario con nomi diversi.
Ma ecco cosa ho notato: un numero significativo di tentativi utilizza il nome del server come accesso. Raccomandazione: non utilizzare lo stesso nome per il computer e l'utente. Inoltre, a volte sembra che stiano tentando di analizzare in qualche modo il nome del server: ad esempio, per un sistema con il nome DESKTOP-DFTHD7C, la maggior parte dei tentativi di accesso avviene con il nome DFTHD7C:
Di conseguenza, se hai un computer DESKTOP-MARIA, probabilmente proverai ad accedere come utente MARIA.
Un'altra cosa che ho notato dai log: sulla maggior parte dei sistemi, la maggior parte dei tentativi di accesso avviene con il nome “amministratore”. E questo non è senza motivo, perché in molte versioni di Windows questo utente esiste. Inoltre, non può essere cancellato. Ciò semplifica il compito degli aggressori: invece di indovinare nome e password, devi 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 sia stato violato il sistema, perché ho iniziato a monitorare subito dopo l’incidente, ma penso che sia probabile un eccesso.
Quindi, se l'utente Amministratore non può essere eliminato, cosa dovresti fare? Puoi rinominarlo!
Raccomandazioni da questo paragrafo:
- non utilizzare il nome utente nel nome del computer
- assicurarsi che non sia presente alcun utente amministratore nel sistema
- utilizzare password complesse
Quindi, è ormai da circa un paio d'anni che osservo diversi server Windows sotto il mio controllo sottoposti a forza bruta, e senza successo.
Come faccio a sapere che non ha avuto successo?
Perché negli screenshot sopra puoi vedere che ci sono registri delle chiamate RDP riuscite, che contengono le informazioni:
- da quale IP
- da quale computer (nome host)
- имя пользователя
- Informazioni GeoIP
E controllo lì regolarmente: non sono state riscontrate anomalie.
A proposito, se un particolare IP viene sottoposto a forza bruta in modo particolarmente duro, 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, Elastic, oltre a Winlogbeat, ha anche , che può monitorare file e processi sul sistema. Esiste anche un'applicazione SIEM (Security Information & Event Management) a Kibana. Ho provato entrambi, ma non ho visto molti benefici: sembra che Auditbeat sarà più utile per i sistemi Linux e SIEM non mi ha ancora mostrato nulla di comprensibile.
Bene, raccomandazioni finali:
- Effettua backup automatici regolari.
- installare gli aggiornamenti di sicurezza in modo tempestivo
Bonus: elenco di 50 utenti utilizzati più spesso per i tentativi di accesso RDP
"nome.utente: discendente"
Contare
dfthd7c (nome host)
842941
winsrv1 (nome host)
266525
AMMINISTRATORE
180678
amministratore
163842
Amministratore
53541
michael
23101
server
21983
steve
21936
Giovanni
21927
Paolo
21913
reception
21909
microfono
21899
office
21888
scanner
21887
scansione
21867
david
21865
chris
21860
proprietario
21855
direttore
21852
administrateur
21841
brian
21839
amministratore
21837
marchio
21824
personale
21806
ADMIN
12748
ROOT
7772
AMMINISTRATORE
7325
SUPPORTO
5577
SUPPORTO
5418
UTENTE
4558
Admin
2832
TEST
1928
MySql
1664
Admin
1652
OSPITE
1322
USER1
1179
SCANNER
1121
SCAN
1032
AMMINISTRATORE
842
AMMINISTRATORE1
525
BACKUP
518
MySqlAdmin
518
RICEZIONE
490
USER2
466
TEMP
452
SQLADMIN
450
USER3
441
1
422
MANAGER
418
PROPRIETARIO
410
Fonte: habr.com