Blocco della connessione UDP alla porta 389 tramite il firewall

Questa guida spiega come proteggere un server Windows dall'essere utilizzato in modo improprio in attacchi DDoS di tipo "reflection/amplification" su LDAP (CLDAP) tramite la porta UDP 389 e come farlo in modo sicuro a seconda del ruolo del server.

Panoramica

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

Il problema di sicurezza è l’abuso della riflessione (amplificazione). Un aggressore 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, questo inonda la vittima di traffico. In passato sono stati osservati fattori di amplificazione superiori a 50×, a seconda delle dimensioni della risposta LDAP, motivo per cui i server esposti vengono utilizzati come riflettori.

L’obiettivo di questa guida è impedire che il vostro server funga da riflettore, senza compromettere le funzioni legittime di Active Directory.

Passaggio 1: Verificare se il proprio server è un controller di dominio

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

In un'installazione standard di Windows Server, la porta UDP 389 viene normalmente utilizzata solo da Active Directory Domain Services dopo che il server è stato promosso a controller di dominio. Un normale Windows Server (server web, applicativo, file server, ecc.) non è in ascolto sulla porta UDP 389 per impostazione predefinita, quindi non può essere utilizzato in modo improprio 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
• 1 — Workstation membro
• 2 — Server autonomo
• 3 — Server membro
• 4 — Controller di dominio (indicato come "Controller di dominio di backup" per motivi di compatibilità storica — tutti i moderni controller di dominio Active Directory restituiscono questo valore)
• 5 — Controller di dominio che ricopre il ruolo FSMO di emulatore PDC (indicato come "Controller di dominio primario" per motivi di compatibilità storica)

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

È inoltre possibile verificare se c'è effettivamente qualcosa in ascolto sulla porta UDP 389:

Get-NetUDPEndpoint -LocalPort 389 -ErrorAction SilentlyContinue

Se questo comando non restituisce alcun risultato, 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

Non c'è nulla in ascolto sulla porta 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 riportata di seguito. Poiché nessun servizio è in ascolto sulla porta UDP 389, la regola non ha alcun effetto pratico.

Se il vostro server È un controller di dominio

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

L’approccio corretto su un controller di dominio:

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

Se il server deve essere esposto, non bloccare la porta UDP 389 a livello globale. Bloccarlo invece solo dagli intervalli di indirizzi IP esterni/non attendibili, escludendo dal blocco le sottoreti interne del dominio. Ciò blocca le richieste esterne contraffatte (che causano la riflessione) mantenendo al contempo funzionanti i client interni. Ciò si ottiene tramite le impostazioni di ambito 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 (blocco del traffico UDP 389 in entrata)

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

Selezionare «Regole in entrata » dal menu a sinistra:

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

Si apre la procedura guidata per la creazione delle regole. 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, seleziona Blocca la connessione e fai clic su Avanti >:

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

La stessa regola può essere creata da PowerShell, il che è utile 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

Definire l’ambito della regola (obbligatorio su un controller di dominio)

Dopo aver creato la regola, aprite le sue Proprietà e andate alla scheda Ambito. In Indirizzo IP remoto, selezionate Questi indirizzi IP e aggiungete gli intervalli esterni o non attendibili che desiderate bloccare. Non aggiungere qui le sottoreti interne del dominio: qualsiasi intervallo elencato in «Indirizzo IP remoto» verrà bloccato dalla regola, quindi l’inserimento delle sottoreti interne bloccherebbe i propri client. Lascia l’opzione «Indirizzo IP locale » impostata su «Qualsiasi indirizzo IP».

In questo modo il blocco si applica solo alle fonti esterne non attendibili specificate, mentre i client interni (non elencati) non ne risentono.

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 gli intervalli comuni della 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 del firewall attivo è normalmente "Dominio". Limitare la regola ai profili "Pubblico" e "Privato" impedisce che essa influisca sul normale traffico di dominio. Su un controller di dominio è comunque più sicuro definire esplicitamente le sottoreti interne nell’ambito (Scope) della regola piuttosto che affidarsi esclusivamente alla parola chiave Internet: se la rete utilizza intervalli privati non standard, questi potrebbero essere classificati erroneamente; in tal caso, elencare manualmente gli intervalli interni e bloccare tutto il resto.

Verifica il risultato

Il modo più diretto per confermare se un server risponde ancora alle richieste CLDAP è inviare un ping LDAP corretto da un client membro del dominio:

nltest /ping /server:DC_NAME

Questo comando invia una richiesta CLDAP correttamente formata e riporta la risposta. Sostituisci DC_NAME con il nome del tuo controller di dominio.

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

portqry -n SERVER_NAME -p UDP -e 389

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

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

nltest /dsgetdc:example.com

Sostituire example.com con il proprio nome di dominio. Una risposta positiva indica che i client sono ancora in grado di individuare il controller di dominio. Tenete presente che un comando `dsgetdc` riuscito da solo non dimostra che CLDAP su UDP funzioni, poiché DC Locator può ricorrere a query DNS e LDAP su TCP se CLDAP non è disponibile, a seconda dell’operazione eseguita — motivo per cui il controllo `nltest /ping` sopra indicato è il test più diretto.

Raccomandazioni aggiuntive

Mantenere Windows completamente aggiornato. Gli aggiornamenti di sicurezza risolvono vulnerabilità critiche nell’implementazione LDAP stessa (come difetti che potrebbero consentire l’esecuzione di codice remoto) e proteggono il server da compromissioni. Si tratta di una questione distinta dall’abuso della riflessione: l’applicazione delle patch rafforza il server stesso, mentre la configurazione del firewall sopra descritta impedisce che il server venga utilizzato come riflettore contro altri.

Abilitare la firma LDAP e il binding di canale sui controller di dominio per rafforzare l’LDAP nel suo complesso.

Per la protezione volumetrica, la limitazione della velocità e il filtraggio DDoS devono essere gestiti dal firewall perimetrale o dal provider a monte, non dall’host Windows stesso.

Riepilogo: quando è opportuno bloccare la porta UDP 389?

• Il server non è un controller di dominio → nessuna azione necessaria (la porta UDP 389 non è in ascolto).
• Controller di dominio dietro un firewall, non esposto a Internet → nessuna azione necessaria; mantenerlo fuori dalla rete Internet pubblica.
• Controller di dominio esposto a Internet → definire l’ambito della regola in modo che blocchi le fonti esterne lasciando inalterate le sottoreti interne affidabili.