Usa BGP per difenderti da un attacco DDoS proveniente da un AS remoto

Ho una domanda su BGP e su come realizzare questa configurazione.

Il mio router principale aziendale è collegato a un ISP (single homed). Questo router ha già scambiato i prefissi IP pubblici specifici con l'ISP negli aggiornamenti BGP. Ora lasciamo dire che c'è un AS a diversi salti di distanza che sta inondando il mio AS locale con un attacco DDoS. Esistono più reti in tale AS destinate ai server Web nel mio AS locale.

Come possiamo fermare questo traffico sul nostro router usando BGP?

Apprezzo la tua risposta !! :)

Ci sono due cose che potresti fare con BGP:

RTBH - Buco nero attivato da remoto

La prima opzione è quella radicale: Blackhole (blocco del traffico) per l'attacco dell'IP. Unico inconveniente: l'IP scelto come target non è più raggiungibile. Vantaggio: il resto della rete rimane attivo. Packetlife ha una bella spiegazione su come funziona e su come farlo. La seconda opzione si basa sulla prima:

RTBH basato sulla fonte

RTBH può anche essere utilizzato (in alcune configurazioni) per bloccare il traffico proveniente da IP specifici (in un DDoS reale che non sarebbe di grande aiuto poiché il traffico proveniente da migliaia di IP). Ancora una volta, Packetlife ha una spiegazione.

Nel tuo caso potresti ottenere tutti i prefissi per l'AS da un database di routing come RADB e bloccarli con RTBH basato su sorgente. Il traffico colpirebbe comunque la tua rete al confine.

Quando si utilizza RTBH "semplice", il vantaggio è che è possibile inviare queste rotte RTBH al proprio ISP a monte (se supportato) che potrebbe quindi bloccare il traffico nella propria rete già in modo da non doverlo gestire.

Il metodo RTBH descritto da @Sebastian tramite Packetlife è utile, ma quel metodo funzionerà solo se il tuo uplink non è saturo del traffico di attacco. Se il tuo uplink è saturo, allora il blackhole deve essere implementato in un punto prima che il traffico di attacco raggiunga la tua rete.

Puoi farlo con le comunità blackhole a monte.

Hurricane Electric offre una semplice spiegazione / esempio di blackholing innescato dal cliente con una comunità BGP:

1. Inizia l'attacco
2. Il cliente identifica la gamma ip o ip sotto attacco
3. Il cliente statico instrada l'intervallo ip o ip su Null0 e aggiunge un annuncio del prefisso corrispondente con una mappa del percorso che lo contrassegna con 6939: 666.

Esempio di configurazione Cisco (dove XXXX è l'IP che viene attaccato):

conf t
ip route X.X.X.X 255.255.255.255 Null0
router bgp YourAS
network X.X.X.X mask 255.255.255.255 route-map blackhole
route-map blackhole permit 10
set community 6939:666
end

Nota che 6939:666è la comunità blackhole specifica di Hurricane Electric. Modificare questo valore in modo che corrisponda alla comunità blackhole del provider upstream.

Esistono ovviamente diversi modi per configurarlo. Sul mio equipaggiamento Brocade, utilizzo la seguente configurazione:

router bgp
!
redistribute static route-map blackhole
!
!
route-map blackhole permit  5
 match tag  66
 set community  55555:666

Dov'è 55555:666la comunità blackhole del tuo provider upstream. Un buco nero a monte può quindi essere applicato con un semplice comando:

ip route 123.123.123.123 255.255.255.255 null0 tag 66

Dal punto di vista della BGP, non c'è molto che puoi fare. Potresti smettere di pubblicizzare il tuo prefisso ma poi stai solo completando l'attacco DoS perché nessuno sarà in grado di accedere al tuo servizio.

Se si hanno più prefissi, è possibile rinumerare ma probabilmente l'attacco si sposterà anche sul nuovo prefisso.

Quello che devi fare è lavorare con il tuo upstream. Hanno un servizio di lavaggio? Se hanno un sistema come Arbor Peakflow, potrebbero cancellare il traffico e ripulirlo prima che entri nella tua rete. Tali servizi sono spesso molto costosi.

Esistono anche altre opzioni come Cloudflare e società simili in cui si configura BGP attraverso un tunnel GRE per quella società e il traffico viene gestito dal loro "cloud" che può gestire molto più traffico dei dispositivi locali.

Lavoro per CloudFlare, vorrei condividere alcune delle conoscenze che ho sviluppato sulla mitigazione degli attacchi DDOS negli ultimi mesi in cui sono stato qui.

In primo luogo; molte persone ricorrono a misure a livello di rete per mitigare gli attacchi DDOS a livello di applicazione. Prima di immergerti in BGP Blackholing, considera se è possibile gestire una limitazione della velocità o una protezione a livello di applicazione. Detto ciò; ora è molto economico lanciare attacchi DDOS di grande capacità (dati il ​​numero di Open DNS Recursor in circolazione e il modo in cui possono amplificare gli attacchi).

Come Elliot ha descritto nella sua risposta, l'uso delle community BGP per creare blackhole nel traffico può funzionare bene se la tua rete è piccola; questo meccanismo è documentato in RFC 3882 . Tuttavia, come noi, se invece desideri assorbire il traffico di attacco anziché il blackhole (ovvero desideri raccogliere i dati di attacco DDOS ), fai attenzione ai danni collaterali in base ai quali i fornitori di rete intermediari finiscono per essere congestionati. È possibile mitigare il danno collaterale eseguendo il peering direttamente con gli ISP delle reti che stanno lanciando gli attacchi. In questo modo hai il percorso più breve dall'attaccante alla destinazione. Inoltre, è possibile implementare un progetto di rete Anycast , ciò significa che un indirizzo IP colpisce più data center (a seconda di quale sia il più vicino).

Ovviamente non è possibile per ogni azienda disporre dell'infrastruttura per eseguire Anycast e peering; ecco perché le aziende si rivolgono sempre più ai servizi cloud per rimuovere il traffico cattivo prima che raggiunga i loro datacenter. Naturalmente CloudFlare è uno di questi servizi.

Se tutte le prove che hai raccolto sono un flusso di pacchetti con indirizzi IP di origine da un determinato AS, probabilmente sei passato alla conclusione sbagliata. Una spiegazione più probabile sarebbe che tali IP di origine siano falsificati.

Un attacco di riflessione / amplificazione comporta l'invio di molti pacchetti che falsificano l'indirizzo IP di origine di una vittima. Se questo è effettivamente ciò che sta accadendo e disponi di server nella tua rete che possono amplificare un attacco, allora la rete che stai accusando di un attacco è in realtà la vittima e stai aiutando l'attaccante.

In tale situazione, la soluzione non è applicare alcun tipo di ingegneria del traffico, ma piuttosto configurare i server in modo tale che non possano essere utilizzati in un attacco di amplificazione. Come fare questo non è davvero una domanda di ingegneria di rete.

È ovviamente possibile che tutti i pacchetti provengano da un AS. Con la cooperazione dell'AS incriminato, è possibile ottenere la conferma che i pacchetti provengono effettivamente dal loro AS. Tuttavia, con quel livello di cooperazione, potresti anche bloccare l'attacco alla fonte.

Se assumiamo che tu abbia adottato un metodo che non ho pensato alla conferma ottenuta, i pacchetti provengono davvero dall'AS che pensi, e che non puoi bloccarlo alla fonte e invece voglio bloccarlo tramite BGP, quindi io ho letto un metodo un po 'rischioso per raggiungere questo obiettivo. L'idea è di anteporre un percorso AS al percorso che stai annunciando. In questo percorso AS anteposto si include il numero AS dell'origine di tali pacchetti.

Quando l'annuncio raggiunge i router BGP nell'AS incriminato, stanno per rilevare un loop e rilasciare l'annuncio. Nel frattempo il resto del mondo non vedrà un ciclo e accetterà l'annuncio.

Questa è la teoria. Se funzionerà effettivamente nella pratica dipende da alcuni fattori diversi. Ad esempio, dipende effettivamente dall'utilizzo del numero AS da cui provengono i pacchetti, che potrebbe essere diverso dal numero AS che annuncia tali indirizzi IP. (Tale differenza potrebbe essere legittima o dovuta allo spoofing.)

Dipende anche dal fatto che l'upstream non filtra il percorso se trova sospetto il percorso AS. Inoltre, le reti più lontane da te possono anche abbandonare il tuo percorso, ad esempio se hanno anche avuto brutte esperienze con l'AS incriminato e hanno deciso di abbandonare tutte le rotte da lì.

Sta a te decidere se questo approccio merita il rischio.

(Mi sarei collegato alla fonte per questo approccio, se potessi ritrovarlo.)

Puoi bucare il loro AS dalla tua rete locale, quindi il tuo router BGP crea percorsi nulli per qualsiasi prefisso che annunciano.

Pro:

• il tuo AS apparirà morto per loro, che è il loro obiettivo, mentre continui a scambiare dati con tutti gli altri normalmente.
• il tuo filtro di ingresso locale eliminerà automaticamente i pacchetti in arrivo da quel AS

Contra:

• possono creare percorsi blackhole sul router, quindi assicurati di disporre delle regole appropriate per mantenere intatti i percorsi più vitali