RTBH e blackholing BGP: come un ISP ferma un attacco DDoS

Quando un attacco volumetrico punta a un singolo IP della tua rete, il problema non è il server sotto tiro: è il link di transito che si satura. Se il tuo uplink è da 10 Gbps e l'attacco ne porta 40, tutto ciò che sta dietro quel link smette di funzionare — compresi i clienti che con l'attacco non c'entrano nulla. Il blackholing esiste per risolvere esattamente questo scenario.

L'idea di base: scartare a monte

Remotely Triggered Black Hole filtering, descritto nella RFC 5635, ribalta l'approccio intuitivo. Invece di cercare di proteggere l'IP attaccato, lo si butta via — ma lo si butta via il più lontano possibile dalla propria rete, cioè sui router del provider di transito o dell'internet exchange.

Il meccanismo è elegante nella sua brutalità:

• Annunci in BGP una rotta /32 (o /128 in IPv6) verso l'indirizzo bersaglio
• Alleghi all'annuncio una community concordata con l'upstream
• L'upstream riconosce la community e, invece di instradare quel traffico verso di te, imposta il next-hop su un'interfaccia di discard

Il risultato è che i pacchetti diretti a quell'IP vengono distrutti sui router del provider, prima di entrare nel tuo link. Il tuo uplink respira, tutti gli altri clienti tornano operativi.

La community BLACKHOLE

Storicamente ogni operatore definiva la propria community, e chi aveva cinque upstream doveva memorizzarne cinque diverse. La RFC 7999 ha standardizzato il valore 65535:666 come community BLACKHOLE well-known, e oggi la supportano la gran parte dei transit provider e degli internet exchange europei.

In IPv6 e nelle large community il valore equivalente è 65535:0:666. Molti operatori mantengono comunque anche la propria community proprietaria, spesso nella forma ASN:666, quindi vale la pena verificare la documentazione di peering dell'upstream prima di contarci.

Esempio di configurazione su RouterOS, dove si marca una rotta statica destinata all'annuncio:

/ip route add dst-address=203.0.113.45/32 blackhole comment="RTBH target"
/routing filter rule add chain=bgp-out-transit \
  rule="if (dst == 203.0.113.45/32) { set bgp-communities 65535:666; accept }"

Su Cisco IOS e JunOS la logica è identica: rotta statica verso un next-hop di discard, route-map che aggiunge la community in uscita, e un filtro che permette esplicitamente i prefissi /32 verso l'upstream — perché normalmente i transit provider scartano tutto ciò che è più specifico di un /24.

Il prezzo da pagare

Qui sta il punto che va capito bene prima di implementarlo: il blackholing completa l'attacco. L'obiettivo di chi attacca è rendere irraggiungibile un servizio, e tu lo rendi irraggiungibile con le tue mani.

La logica è di triage, non di difesa: sacrifichi un indirizzo per salvarne mille. È la scelta corretta quando l'alternativa è la saturazione del transito, ma resta una sconfitta tattica.

Conseguenze concrete:

• Il servizio su quell'IP è totalmente giù, per tutti, finché l'annuncio resta attivo
• Non c'è granularità: non puoi scartare solo il traffico malevolo e far passare quello legittimo
• Se il bersaglio è un IP condiviso — un reverse proxy, un load balancer, un server di hosting con cento siti — butti giù tutto ciò che ci sta dietro

RTBH selettivo e alternative

Esistono raffinamenti che riducono il danno collaterale.

Source-based RTBH scarta in base all'IP sorgente anziché alla destinazione, usando uRPF sui router upstream. Funziona contro attacchi che partono da un insieme circoscritto di sorgenti, ma è inefficace contro le botnet distribuite e contro qualsiasi attacco con sorgente spoofata — cioè la maggioranza dei volumetrici moderni.

BGP Flowspec (RFC 8955) è la risposta granulare: permette di distribuire regole che matchano porta, protocollo, lunghezza del pacchetto e altri campi, con azioni che includono il rate limiting invece della sola distruzione. Il limite è l'adozione: molti transit provider non accettano flowspec dai clienti, perché una regola sbagliata propagata in rete fa danni seri.

Scrubbing center: il traffico viene deviato verso un'infrastruttura di pulizia che filtra gli attacchi e reinietta il traffico legittimo. È l'unica soluzione che mantiene il servizio online, ma ha costi e latenza aggiuntiva, e ha senso sopra una certa soglia di criticità.

Come organizzarsi prima, non durante

Un attacco non è il momento per scoprire che la community è sbagliata o che l'upstream non filtra i /32. La preparazione minima:

• Verifica la policy di ogni upstream: quale community accetta, quale prefix-length massima ammette per il blackholing, se applica limiti di quantità
• Testa in condizioni normali, con un IP di servizio non produttivo, e conferma che il traffico venga effettivamente scartato a monte
• Automatizza l'attivazione: con un monitoraggio del traffico per IP, l'annuncio può partire in pochi secondi invece che dopo una telefonata
• Definisci una scadenza: ogni blackhole deve avere un timeout, altrimenti resta attivo per settimane e nessuno se ne accorge finché il cliente non chiama
• Documenta chi decide: sacrificare l'IP di un cliente è una scelta con impatto contrattuale, non solo tecnico

In sintesi

Il blackholing è lo strumento giusto per una categoria precisa di problemi: attacchi volumetrici che minacciano la capacità di transito. È rapido, gratuito e universalmente supportato. Non è protezione, è contenimento del danno.

Chi eroga servizi con SLA stringenti dovrebbe affiancarlo a una soluzione di mitigazione vera, e usare RTBH come ultima risorsa. Sulla rete Velix il blackholing è configurato su tutti i transit e sugli IX di peering, con soglie di traffico monitorate e attivazione rapida in caso di evento.