{"id":41229,"date":"2020-02-06T20:43:00","date_gmt":"2020-02-06T17:43:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/opasno-li-derzhat-otkrytym-rdp-v-internete"},"modified":"2020-02-06T20:43:00","modified_gmt":"2020-02-06T17:43:00","slug":"opasno-li-derzhat-otkrytym-rdp-v-internete","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/opasno-li-derzhat-otkrytym-rdp-v-internete","title":{"rendered":"\u00c8 pericoloso tenere RDP aperto su Internet?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Spesso ho letto l'opinione che tenere aperto il porto RDP (Remote Desktop Protocol) su Internet sia molto pericoloso e che non sia opportuno farlo. \u00c8 meglio concedere l'accesso a RDP solo tramite VPN o solo da determinati indirizzi IP \"bianchi\".<\/p>\n

<\/p>\n

Amministro diversi Windows Server per piccole aziende, in cui mi \u00e8 stato chiesto di garantire l'accesso remoto a Windows Server per i contabili. \u00c8 una tendenza moderna \u2014 lavorare da casa. Ho capito piuttosto rapidamente che costringere i contabili a utilizzare una VPN \u00e8 frustrante, e che non \u00e8 possibile raccogliere tutti gli IP da inserire nella lista bianca, poich\u00e9 gli indirizzi IP delle persone sono dinamici.<\/p>\n

<\/p>\n

Pertanto, ho scelto la strada pi\u00f9 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.<\/p>\n

<\/p>\n

In questo articolo condivider\u00f2 la mia esperienza (sia positiva che negativa) e le mie raccomandazioni.<\/p>\n

<\/a><\/noindex><\/p>\n

Rischi<\/h3>\n

<\/p>\n

Quali rischi corri aprendo la porta RDP?<\/p>\n

<\/p>\n

1) Accesso non autorizzato a dati sensibili<\/b>
\nSe qualcuno riesce a indovinare la password per RDP, potr\u00e0 accedere ai dati che desideri mantenere privati: situazione dei conti, saldi, dati dei clienti,\u2026<\/p>\n

<\/p>\n

2) Perdita di dati<\/b>
\nAd esempio, a causa dell'azione di un virus di tipo ransomware.
\nO a causa dell'azione mirata di un aggressore.<\/p>\n

<\/p>\n

3) Perdita della stazione di lavoro<\/b>
\nI dipendenti devono lavorare, ma il sistema \u00e8 compromesso, \u00e8 necessario reinstallare \/ ripristinare \/ configurare.<\/p>\n

<\/p>\n

4) Compromissione della rete locale<\/b>
\nSe un aggressore ha ottenuto accesso a un computer Windows, potr\u00e0 accedere anche a sistemi che non sono accessibili dall'esterno, da Internet. Ad esempio, a condivisioni di file, stampanti di rete, ecc.<\/p>\n

\nHo avuto un caso in cui un Windows Server \u00e8 stato colpito da un ransomware<\/b><\/p>\n

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\u00e9 il NAS era un Synology con snapshot configurati, ho ripristinato il NAS in 5 minuti, mentre ho dovuto reinstallare Windows Server da zero.<\/p>\n

<\/p>\n

Osservazioni e raccomandazioni<\/h3>\n

<\/p>\n

Monitora i Windows Server utilizzando Winlogbeat<\/a><\/noindex>, che invia i log a ElasticSearch. In Kibana ci sono diverse visualizzazioni e ho anche configurato un dashboard personalizzato.
\nIl monitoraggio di per s\u00e9 non protegge, ma aiuta a determinare le misure necessarie.<\/p>\n

<\/p>\n

Ecco alcune osservazioni:
\na) RDP verr\u00e0 sottoposto a brute-force.<\/b>
\nSu uno dei server ho configurato RDP su una porta non standard, la 443 \u2014 per mascherarlo come HTTPS. Cambiare la porta da quella standard probabilmente ha senso, ma l'efficacia non \u00e8 cos\u00ec elevata. Ecco le statistiche di questo server:<\/p>\n

\n\"\u00c8<\/p>\n

Si vede che nella settimana ci sono state quasi 400.000 tentativi di accesso falliti tramite RDP.
\nSi nota che i tentativi di accesso sono stati da 55.001 indirizzi IP (alcuni degli indirizzi IP erano gi\u00e0 stati bloccati da me).<\/p>\n

<\/p>\n

Da questo emerge chiaramente che \u00e8 necessario installare fail2ban, ma <\/p>\n

\nPer Windows non esiste un'utilit\u00e0 del genere.<\/b><\/p>\n

Ci sono un paio di progetti abbandonati su GitHub che sembrano farlo, ma non ho nemmeno provato a installarli:
\nhttps:\/\/github.com\/glasnt\/wail2ban<\/a><\/noindex>
\nhttps:\/\/github.com\/EvanAnderson\/ts_block<\/a><\/noindex><\/p>\n

<\/p>\n

Ci sono anche strumenti a pagamento, ma non li ho considerati.<\/p>\n

<\/p>\n

Se conoscete uno strumento open source per questo scopo, condividetelo nei commenti.<\/p>\n

<\/p>\n

Aggiornamento<\/strong>: Nei commenti mi hanno fatto notare che la porta 443 non \u00e8 una scelta saggia, e sarebbe meglio optare per porte elevate (32000+), perch\u00e9 la 443 viene scansionata pi\u00f9 frequentemente, e riconoscere RDP su quella porta non \u00e8 un problema.<\/p>\n

<\/p>\n

Aggiornamento:<\/strong> Nei commenti mi hanno fatto sapere che esiste uno strumento del genere:
\nhttps:\/\/github.com\/digitalruby\/ipban<\/a><\/noindex><\/p>\n

<\/p>\n

b) Ci sono determinati username che gli malintenzionati preferiscono.<\/b>
\nSi vede che il tentativo avviene tramite un attacco a dizionario con diversi nomi.
\nMa quello che ho notato \u00e8 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:<\/p>\n

\n\"\u00c8<\/p>\n

Di conseguenza, se avete un computer chiamato DESKTOP-MARIA, probabilmente ci saranno tentativi di accesso con l'utente MARIA.<\/p>\n

<\/p>\n

Inoltre, ho notato dai log che sulla maggior parte dei sistemi, la maggior parte dei tentativi di accesso avviene con il nome \"administrator\". E questo non \u00e8 casuale, poich\u00e9 in molte versioni di Windows, questo utente esiste. Inoltre, non pu\u00f2 essere eliminato. Ci\u00f2 semplifica il compito per gli aggressori: invece di dover indovinare sia il nome che la password, devono solo indovinare la password.
\nTra 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\u00e9 ho iniziato a monitorarla proprio dopo quell'episodio, ma credo che l'attacco a dizionario sia probabile.
\nAllora, se non \u00e8 possibile eliminare l'utente Administrator, cosa si pu\u00f2 fare? Si pu\u00f2 rinominare!<\/p>\n

<\/p>\n

Raccomandazioni di questo punto: <\/p>\n

<\/p>\n