Blocco della connessione UDP alla porta 389 attraverso il firewall

Panoramica

LDAP (Lightweight Directory Access Protocol) è il protocollo di livello applicativo alla base di Active Directory. Normalmente funziona su TCP, ma dispone anche di una variante senza connessione — CLDAP (Connectionless LDAP) — che funziona su UDP sulla porta 389. I client Windows utilizzano CLDAP per individuare i controller di dominio (il «ping LDAP» eseguito dal servizio Localizzatore di DC). Le versioni moderne di Windows possono spesso ricorrere al rilevamento basato su DNS e a LDAP su TCP in molti scenari, ma CLDAP su UDP 389 è ancora utilizzato per le operazioni del Localizzatore di DC e per l'aggiunta al dominio.

Il problema di sicurezza è l'abuso per riflessione (amplificazione). Un utente malintenzionato invia una piccola richiesta CLDAP contraffatta alla porta UDP 389 di un server, falsificando l'IP di origine in modo che sembri che la richiesta provenga dalla vittima. Il server invia quindi una risposta molto più grande all'indirizzo della vittima. Moltiplicato su molti server esposti, ciò inonda la vittima di traffico. In passato sono stati osservati fattori di amplificazione superiori a 50×, a seconda della dimensione della risposta LDAP, motivo per cui i server esposti vengono utilizzati come riflettori.

L'obiettivo di questa guida è impedire che il server agisca come tale riflettore — senza interrompere le funzioni legittime di Active Directory.

Passo 1: Determinare se il server è un controller di dominio

Questo è il passaggio più importante, perché determina cosa (se necessario) bloccare.

In un'installazione standard di Windows Server, la porta UDP 389 è normalmente utilizzata solo da Active Directory Domain Services dopo che il server è stato promosso a controller di dominio. Un normale Windows Server (web, applicazioni, file server, ecc.) non è in ascolto su UDP 389 per impostazione predefinita, quindi non può essere utilizzato come riflettore CLDAP a meno che un'altra applicazione (come AD LDS o un servizio LDAP di terze parti) non fornisca un servizio CLDAP su quella porta.

Aprire PowerShell come amministratore e verificare il ruolo effettivo del server nel dominio:

(Get-CimInstance Win32_ComputerSystem).DomainRole

Interpretazione del risultato:

• 0 — Workstation autonoma (Standalone Workstation)
• 1 — Workstation membro (Member Workstation)
• 2 — Server autonomo (Standalone Server)
• 3 — Server membro (Member Server)
• 4 — Controller di dominio (segnalato come «Backup Domain Controller» per compatibilità storica — tutti i moderni controller di dominio Active Directory restituiscono questo valore)
• 5 — Controller di dominio che detiene il ruolo FSMO di emulatore PDC (segnalato come «Primary Domain Controller» per compatibilità storica)

Se il risultato non è 4 o 5, il server non è un controller di dominio.

È inoltre possibile verificare se qualcosa è effettivamente in ascolto su UDP 389:

Get-NetUDPEndpoint -LocalPort 389 -ErrorAction SilentlyContinue

Se questo comando non restituisce nulla, Windows non è in ascolto sulla porta UDP 389, quindi il server non fornisce servizi CLDAP e non è esposto a questo attacco.

Se il server NON è un controller di dominio

Nulla è in ascolto su UDP 389, quindi il server non può essere utilizzato come riflettore LDAP. Non è necessaria alcuna modifica al firewall per questa specifica minaccia.

Se si desidera documentare la propria politica di sicurezza o applicare una regola di rifiuto esplicita, è comunque possibile creare la regola del firewall indicata di seguito. Poiché nessun servizio è in ascolto sulla porta UDP 389, la regola non ha alcun effetto pratico.

Se il server È un controller di dominio

Un controller di dominio è effettivamente in ascolto su UDP 389 e può essere utilizzato come riflettore — ma UDP 389 è anche essenziale per il normale funzionamento del dominio.

Avviso: Non bloccare ciecamente tutto il traffico UDP 389 in entrata su un controller di dominio. I client aggiunti al dominio utilizzano CLDAP (UDP 389) per trovare un controller di dominio, e la stessa porta è necessaria per l'aggiunta al dominio. Un blocco generalizzato può impedire ai client di individuare il controller di dominio e interrompere le operazioni di accesso e di aggiunta al dominio.

L'approccio corretto su un controller di dominio:

Idealmente, un controller di dominio non dovrebbe essere raggiungibile da Internet. L'abuso per riflessione proviene dall'esterno, quindi la soluzione più pulita è mantenere il DC dietro un firewall perimetrale e non esporre pubblicamente UDP 389.

Se il server deve essere esposto, non bloccare UDP 389 a livello globale. Bloccarlo invece solo da intervalli IP esterni/non attendibili, lasciando le subnet di dominio interne fuori dal blocco. Ciò arresta le richieste esterne contraffatte (che causano la riflessione) mantenendo funzionanti i client interni. Questo si ottiene tramite le impostazioni dell'Ambito (Scope) della regola, descritte di seguito.

Lo stesso principio di ambito si applica ai controller di dominio di sola lettura (RODC).

Creazione della regola del firewall (bloccare il traffico UDP 389 in entrata)

Aprire Windows Firewall e selezionare Impostazioni avanzate nel menu a sinistra:

Selezionare Regole in entrata dal menu laterale di sinistra:

Fare clic su Azione → Nuova regola... nel menu in alto:

Si aprirà la creazione guidata della regola. Selezionare il tipo di regola Porta e fare clic su Avanti >:

Nella pagina successiva, selezionare UDP, quindi in Porte locali specifiche digitare 389 e fare clic su Avanti >:

Nella pagina successiva, selezionare Blocca la connessione e fare clic su Avanti >:

Infine, assegnare un nome alla regola, ad esempio UDP LDAP block, e fare clic su Fine:

La stessa regola può essere creata da PowerShell, comodo per la creazione di script o per applicarla a più server:

New-NetFirewallRule -DisplayName "Block inbound UDP 389 (CLDAP)" -Direction Inbound -Protocol UDP -LocalPort 389 -Action Block

Avviso: Su un controller di dominio, non fermarsi qui. La regola precedente blocca UDP 389 da tutte le origini, il che interromperà la localizzazione del controller di dominio per i client interni. È necessario delimitarne l'ambito (passaggio successivo).

Delimitare l'ambito della regola (necessario su un controller di dominio)

Dopo aver creato la regola, aprirne le Proprietà e andare alla scheda Ambito (Scope). In Indirizzo IP remoto, selezionare Questi indirizzi IP e aggiungere gli intervalli esterni o non attendibili che si desidera bloccare. Non aggiungere qui le subnet di dominio interne — qualsiasi intervallo elencato in «Indirizzo IP remoto» è un intervallo che la regola bloccherà, quindi elencare le subnet interne bloccherebbe i propri client. Lasciare Indirizzo IP locale impostato su Qualsiasi indirizzo IP.

In questo modo il blocco si applica solo alle origini esterne non attendibili specificate, mentre i client interni (non elencati) rimangono inalterati.

In PowerShell, lo stesso ambito può essere applicato con la parola chiave integrata Internet. La parola chiave Internet corrisponde agli indirizzi remoti che Windows Firewall classifica come esterni, escludendo il computer locale, il loopback e i comuni intervalli di rete locale. Ciò blocca il traffico esterno lasciando inalterati i client interni:

New-NetFirewallRule -DisplayName "Block inbound UDP 389 (CLDAP) from Internet" -Direction Inbound -Protocol UDP -LocalPort 389 -RemoteAddress Internet -Action Block -Profile Public,Private

Su un controller di dominio configurato correttamente, il profilo firewall attivo è normalmente Dominio. Limitare la regola ai profili Pubblico e Privato impedisce che influisca sul normale traffico di dominio. Su un controller di dominio è comunque più sicuro definire esplicitamente le proprie subnet interne nell'Ambito della regola anziché affidarsi solo alla parola chiave Internet — se la rete utilizza intervalli privati non standard, potrebbero essere classificati erroneamente; in tal caso, elencare manualmente gli intervalli interni e bloccare tutto il resto.

Verificare il risultato

Avviso: Non utilizzare Test-NetConnection per verificare UDP 389 — verifica solo le connessioni TCP e fornirà risultati fuorvianti per UDP.

Il modo più diretto per verificare se un server risponde ancora alle richieste CLDAP è inviare un ping LDAP corretto da un client aggiunto al dominio:

nltest /ping /server:DC_NAME

Questo invia una richiesta CLDAP formulata correttamente e ne riporta la risposta. Sostituire DC_NAME con il nome del controller di dominio.

Come verifica secondaria, è possibile utilizzare PortQry (uno strumento gratuito da riga di comando Microsoft) da un altro computer:

portqry -n SERVER_NAME -p UDP -e 389

A seconda della risposta, PortQry può segnalare LISTENING o FILTERED. Si noti che PortQry invia un pacchetto di sondaggio anziché un ping LDAP CLDAP completo, e il servizio CLDAP potrebbe non riconoscerlo come una richiesta valida, quindi può segnalare FILTERED anche quando la porta è aperta. Per questo motivo, considerare nltest /ping come il test autorevole e PortQry come una verifica supplementare approssimativa.

Su un controller di dominio, verificare anche che la localizzazione del dominio funzioni ancora per i client interni:

nltest /dsgetdc:example.com

Sostituire example.com con il nome del proprio dominio. Una risposta positiva significa che i client possono ancora trovare il controller di dominio. Tenere presente che un dsgetdc positivo da solo non dimostra che CLDAP su UDP funzioni, perché il Localizzatore di DC può ricorrere a query DNS e LDAP su TCP se CLDAP non è disponibile, a seconda dell'operazione eseguita — motivo per cui la verifica nltest /ping precedente è il test più diretto.

Raccomandazioni aggiuntive

Mantenere Windows completamente aggiornato. Gli aggiornamenti di sicurezza correggono vulnerabilità critiche nell'implementazione stessa di LDAP (come falle che potrebbero consentire l'esecuzione di codice remoto) e proteggono il server dalla compromissione. Questa è una preoccupazione separata dall'abuso per riflessione — l'applicazione di patch rafforza il server stesso, mentre la delimitazione dell'ambito del firewall di cui sopra impedisce che il server venga utilizzato come riflettore contro altri.

Abilitare la firma LDAP e l'associazione di canale sui controller di dominio per rafforzare LDAP nel complesso.

Per la protezione volumetrica, la limitazione della velocità e il filtraggio DDoS spettano al firewall perimetrale o al provider upstream, non all'host Windows stesso.

Riepilogo: quando è opportuno bloccare UDP 389?

• Il server non è un controller di dominio → nessuna azione necessaria (UDP 389 non è in ascolto).
• Controller di dominio dietro un firewall, non esposto a Internet → nessuna azione necessaria; tenerlo lontano dalla rete Internet pubblica.
• Controller di dominio esposto a Internet → delimitare l'ambito della regola in modo che blocchi le origini esterne lasciando inalterate le subnet interne attendibili.