Hardening di un server Remote Desktop
A partire da Marzo 2013 si è verificato un incremento degli di tipo Ransomware, ovvero attacchi che mirano a creare dei disservizi nell’infrastruttura e a richiedere poi un riscatto per permettere di risolvere il problema.
Ultimamente si sta assistendo ad un attacco di questo tipo non solo sfruttando le vulnerabilità dei browser o tramite allegati in mail, ma anche eseguendo attacchi attivi tramite DUBrute su servizi Remote Desktop Protocol (RDP).
In sostanza vengono eseguiti attacchi a dizionario verso account utente comuni come “admin”, “Administrator”, “backup”, “Support”, “Test”, “Console”, “Guest”, “Sales”, “user” e vari a altri. Una volta ottenuto l’accesso l’attaccante è in grado di eseguire operazioni sul server RDP e sulla rete in base ai diritti dell’account che è riuscito a violare e tenta normalmente di bloccare l’accesso agli utenti, cancellare i backup e crittografare i file a cui riesce ad accedere.
Ovviamente gli antivirus non possono fermare attacco di questo tipo che però può trasformarsi in problema serio per l’azienda che lo subisce. Ultimamente sui forum in rete pare siano diverse le aziende italiane che hanno subito questo tipo di attacco ritrovandosi file e backup in rete criptati e ricevendo una richiesta di riscatto per ottenere la chiave di decriptazione.
Purtroppo in certi casi sono state utilizzare chiavi di cifratura a 1024 che rendono inutile qualunque tool che esegue tentativi a forza bruta per recuperare la chiave in quanto sarebbe necessario un tempo decisamente lungo utilizzando un normale computer.
Per proteggersi da questo tipo di attacco è consigliabile gestire la sicurezza a più livelli come da best practices. Di seguito elencherò una serie di misure che è possibile attuare per eseguire l’hardening dell’accesso al server RDP.
Si tenga presente che condurre un attacco attivo “costa” all’attaccante in termini di tempo, quindi più misure mettiamo in atto compatibilmente con un aumento
Hardening della pubblicazione del servizio RDP lato Firewall
Se possibile conviene pubblicare il server RDP tramite un server RDP Gateway per esporre il servizio RDP tramite HTTPS (TCP 443) anziché la porta TCP 3389 che viene provata dai tool di attacco.
In alternativa è possibile non pubblicare il server RDP tramite la porta TCP 3389 ma tramite una porta diversa nel range delle porte disponibili 41952 – 65535 non utilizzate da altri servizi. In questo modo all’attaccante occorrerà prima eseguire una scansione delle porte TCP esposte per identificare quella che espone il servizio TCP, questa operazione richiede tempo e inoltre molti firewall hanno funzionalità IDS che identificano e bloccano i tentativi di scansione delle porte TCP.
Se il servizio RDP non viene utilizzato 24 ore al giorno configurare le regole di pubblicazione per disabilitare l’accesso RDP nelle fascie orarie in cui il servizio non viene utilizzato. Da verifiche pare che i tentativi di attacco si concentrino prevalentemente nei fine settimana e durante le ore notturne.
Hardening del server RDP
Installare gli aggiornamenti di sicurezza necessari per il sistema in uso pubblicati sul Microsoft Security Bulletins, in particolare controllare che sia installato il Bollettino Microsoft sulla sicurezza MS12-036 di martedì 10 luglio 2012 che risolve una vulnerabilità relativa all’RDP in WS2003,WS2008 e WS2008 R2.
Configurare il protocollo RDP in modo da utilizzare l’autenticazione a livello di rete (NLA), questo oltre a dare il vantaggio di evitare attacchi Man in the Middle e Denial of Service inibisce gli attacchi a forza bruta di tool di attacco non che non supportano l’NLA. Se il server RDP viene acceduto da client XP su questi dovranno essere instalati il Service Pack 3, l’RDP Client 7.0 (KB 969084) e occorrerà abilitare l’uso dell’NLA (KB 951608).
Mettere in sicurezza l’utente Administrator locale impostando una password complessa diversa da quella dell’amministratore di dominio, evitare che tale utente possa navigare ed accedere a risorse di rete senza fornire credenziali.
Se non necessario impedire all’amministratore di dominio di accedere tramite RDP, in questo modo si eviterà di esporre ad attacchi a forza bruta una credenziale importante dal punto di vesta della sicurezza.
Un’altra misura di sicurezza che può essere attuata è il rename dell’account Administrator locale, a riguardo si veda HOW TO: Rename the Administrator and Guest Account in Windows Server 2003.
Hardening della sessione utente
Evitare di pubblicare il desktop agli utenti, utilizzare se possibile la pubblicazione delle applicazioni mediante RemoteApp.
In alternativa se possibile non rendere disponibile il desktop, ma avviare un’applicazione alla creazione della sessione che se chiusa causa la disconnessione.
Nel caso venga pubblicato il desktop configurare il blocco alle funzionalità non pertinenti all’attività svolta dall’utente mediante GPO.
Evitare di lasciare abilitare redirezioni non utilizzate che potrebbero essere sfrattate dall’attaccante come Clipboard, dischi, dispositivi plug & play, stampanti (per quanto riguarda la gestione delle stampanti utilizzare EasyPrint).
Password Utente
Assicurarsi che le password degli utenti RDP siano complesse, è possibile controllare la robustezza della password tramite lo Strumento di controllo delle password: utilizzo di password complesse | Microsoft Security).
Per maggior sicurezza è possibile configurare le GPO di blocco account dopo un certo numero di tentativi a riguardo si veda Account Lockout Policy.
Diritti di accesso utente
Se viene reso disponibile il desktop o se le applicazioni permettono tramite dialog di accedere ai volumi del server limitare al minimo i diritti dell’utente sul server RDP in modo che non possano essere cancellati o modificati file di sistema.
Monitoraggio
Come ultima best practices impostare l’invio di una mail se viene registrato un tentativo di accesso con credenziali errati errate, in WS2008 e successivi è possibile eseguire azioni in conseguenza ad un evento come ad esempio il 4625: An account failed to log on (a riguardo si veda anche la KB 2157973 The Security event that has Event ID 4625 does not contain the user account name on a computer that is running Windows Vista, Windows Server 2008, Windows 7, or Windows Server 2008 R2.
Un’atra operazione di monitoraggio utile può essere quella di monitorare giornalmnete gli accessi amministrativi al server RDP per controllare non si siano verificati accessi da parte di utenti sconosciuti. E’ possibile eseguire tale verifica in modo semplice tramite PowerShell:
Get-EventLog -LogName Security -InstanceId 4624 -EntryType SuccessAudit -After (Get-Date).Date | Where {$_.Message.Contains(“Administrator”)} | Select TimeGenerated, Message | FL
A riguardo si veda lo script Security Log Logon/Logoff Event Reporter che pemette la generazione di report degli utenti che si sono autenticati sul sistema.
[…] ho illustrato nel post Hardening di un server Remote Desktop PowerShell può tornare davvero utile come strumento per monitorare gli accessi ad un server […]