Lo scorso Patch Tuesday, Microsoft ha rilasciato l’aggiornamento di sicurezza MS12-020 per chiudere due falle recentemente scoperte nell’implementazione di RDP (Remote Desktop Protocol) di Microsoft. Una di esse viene etichettata da Microsoft come “critica” perché potrebbe permettere agli hacker di ottenere il controllo di LocalSystem su una scatola di Windows con RDP abilitato.
Come probabilmente avrete già sentito, questa è una situazione ad alto rischio — una che potrebbe risultare in un’epidemia grave come quella causata da Code Red, Melissa, o SQL Slammer. Patchate o rimediate subito!
Microsoft vi aiuterà a fare entrambe le cose. È possibile installare la patch o eseguire uno script online Fix It per mitigare il problema fino a quando la patch viene applicata. Lo script abilita la Network Level Authentication, che richiede l’autenticazione prima che un sistema remoto possa connettersi.
Ma ho un altro consiglio. Come ho raccomandato per più di un decennio, gli amministratori dovrebbero considerare l’esecuzione di servizi collegabili a Internet su porte non predefinite, se possibile. In questo caso particolare, RDP dovrebbe essere eseguito su qualche porta diversa dalla porta 3389.
Questo consiglio si estende ad altre aree. I siti web amministrativi non dovrebbero essere eseguiti sulla porta 80 o anche 443. SSH non dovrebbe essere in ascolto sulla porta 22. Gli host Telnet non dovrebbero essere in ascolto sulla porta 23. L’unico servizio comune diffuso che non sono riuscito a far funzionare in modo affidabile su una porta non predefinita è FTP: usa le porte 21 e 22 (in modalità passiva), e anche la sua modalità attiva (dove potete indicare altre porte) non funziona bene attraverso i firewall.
Nel caso di RDP, potete cambiare la porta predefinita seguendo questa guida. Quando cambiate la porta predefinita, però, dovete indicare la porta non predefinita nella stringa di connessione (per esempio, mstsc.exe 192.168.1.12:50045).
La mia raccomandazione di cambiare la porta di ascolto predefinita su un servizio a livello aziendale è spesso oggetto di critiche. Il mio argomento centrale è questo: Nella maggior parte dei casi, un’azienda può cambiare la porta di ascolto predefinita, il che non causa problemi oltre all’istruzione dell’amministratore e alla riconfigurazione una tantum di alcuni script e strumenti, e diminuisce significativamente il rischio di attacco armato.
Anche se gli hacker e il malware possono usare un port scanner come Nmap per trovare la nuova porta, nessun exploit armato ha mai fatto la scansione della porta, anche se potrebbero facilmente. Questo fatto da solo vi dà molta protezione.
Alcuni chiamano questo tipo di raccomandazione “sicurezza per oscurità”, come se fosse una brutta cosa. Secondo me, la sicurezza per oscurità è una delle migliori difese. Altrimenti, ogni nazione renderebbe pubblico dove si trovano i suoi missili e sottomarini nucleari invece di mantenere l’informazione segreta.
Per me, il worm SQL Slammer è uno dei migliori argomenti per mettere servizi comuni su porte non predefinite. Rilasciato nel 2003, ha sfruttato quasi tutti i possibili server SQL senza patch e non protetti collegati a Internet in 10 minuti. È scoppiato di domenica mattina presto, e quando la maggior parte degli amministratori si è svegliata, il danno si era verificato per quasi un intero giorno lavorativo.
In pratica, quando ci siamo puliti il sale incrostato dagli occhi, era finita — poi abbiamo passato le successive 48 ore (o più) cercando di ripulire il casino. È stato un campanello d’allarme.
Nessuno che avesse abilitato SQL su una porta non di default (cioè una porta diversa dalla 1433 e 1434) ha dovuto fare qualcosa — oltre a guardare con calma tutti gli altri che affrontavano i loro disastri. Quelli che hanno cambiato porta non hanno dovuto ripulire un enorme casino. Non hanno dovuto affrettare le patch. Non hanno avuto server sfruttati. Un cambiamento con un impatto operativo minimo e sono stati in grado di evitare tonnellate di rischio.
Certamente altre mitigazioni funzionano altrettanto bene, come la richiesta di una connessione VPN valida prima di connettersi al servizio, richiedendo una combinazione di contatti di porte precedenti prima di abilitare il servizio, o richiedendo un’autenticazione di successo prima che il servizio risponda (questa è la soluzione Fix It di Microsoft), e qualsiasi altra cosa che potrebbe proteggervi da attacchi armati.
Ma non riesco a pensare a nessun’altra semplice soluzione di sicurezza che diminuisca il rischio in modo così efficace che cambiare la porta di default, quando possibile. Se seguite questo consiglio, spostate la porta su un numero abbastanza alto, sopra 10.000 o 12.000, per evitare possibili conflitti di porta con altri servizi esistenti. Testate tutte le apparecchiature di produzione e aggiornate qualsiasi firewall o proxy necessario. I lettori che hanno seguito questo consiglio in passato non hanno molta fretta questa settimana.