[ITNOG] DDos Mitigation all'Internet Exchange?

Gioanola, Marco mgioanola@arbor.net
Lun 13 Gen 2014 08:44:44 CET


On 10/1/14 7:13 PM, "Marco d'Itri" <md@Linux.IT> wrote:


>
>Come giustamente notato, è follia pensare che qualcuno possa fare
>blackholing di un IP sulla piattaforma del IX in un modo che riguardi
>anche terzi non interessati alla questione.

Ovviamente è follia, e io non intendevo suggerire questo. Ciò che penso si
potrebbe forse realizzare è un sistema di blackholing (o ancora meglio, di
mitigation "intelligente") azionato dall'AS vittima e implementato dall'IX
prima che l'attacco raggiunga, appunto, la vittima.

Altrettanto ovviamente, è necessario non coinvolgere "terzi non
interessati", e ciò si realizza solo facendo blackholing (o mitigation)
del solo /32 sotto attacco, su iniziativa dell'AS relativo.

>D'altra parte, se l'unica soluzione proposta a un DDoS è chiudere una o
>più sessioni al IX (e ricordiamoci dei route server che complicano le
>cose...) allora siamo molto vicini al punto in cui questo non è più
>adeguato.

Concordo, non è adeguato per nulla, in quanto dobbiamo assumere il caso
peggiore in cui l'attacco ddos (*distributed* :-) dos) giunge
omogeneamente da tutti i peer.

>
>Partiamo pure dal presupposto che qualsiasi soluzione che richieda di
>contattare i propri peer e convincerli a fare cose dal loro lato:
>- non è ovvio che funzioni (anzi...)

Quali sono i tuoi dubbi a riguardo?

>- comunque quando funziona ha una latenza troppo alta

"Latenza" nel senso di tempo necessario ad attivare il
blackholing/mitigation o nel senso di "delay" introdotto dai processi di
mitigation?
In entrambi i casi direi che gli impatti sono trascurabili: se mi evitano
un down di ore, sia i secondi necessari a propagare una null route che gli
eventuali ms introdotti ad uno scrubbing center mi sembrano il minore dei
mali.

>- non scala con l'aumentare dei peer

Beh, questo dipende appunto da come viene realizzata la soluzione.

>
>La soluzione più elegante sarebbe estendere ai propri peer le funzioni
>di blackholing controllato via BGP che già si mettono a disposizione dei
>propri clienti.

Concordo; è qui che volevo arrivare.

>È abbastanza ovvio però che questo non può funzionare a meno che alcuni
>grandi reti inizino ad imporlo come condizione per fare peering, visto
>che chi dovrebbe fare il lavoro (la sorgente del attacco) non sarebbe
>chi ne beneficierà (il destinatario del attacco).
>
>Molto più semplice la soluzione proposta da AMS-IX nell'ultima slide,
>di fare una cosa simile mediante i route server. Però richiede
>necessariamente che tutte le route siano correttamente registrate nel
>IRR e filtrate e, diversamente da MIX e DE-CIX, AMS-IX ha già detto di
>non averne voglia.
>Visto che qui ne avremmo la possibilità, forse possiamo esplorare
>meglio questa opzione: proviamo a riflettere un po' su cosa
>comporterebbe.
>Forse non era chiaro a tutti, ma appunto lo scopo di questa funzione
>sarebbe fare blackholing del *proprio* IP destinazione dell'attacco,
>non delle sorgenti...
>
>Dopo questo rimane solo che l'IX fornisca una API che permetta di
>installare sulla propria porta di una ACL personalizzata, che però deve
>essere L3 per essere utile. Questa è la soluzione che non richiede
>alcuno sforzo implementativo ai membri del IX, ma richiede che gli
>switch possano gestire ACL L3 sulle porte L2, e senza problemi di
>prestazioni. (E su questo punto non sono preparato.)

Una tecnologia che promette molto a questo riguardo è Flow Spec. Vorrei
aggiungere qualche link ma sono dietro una pessima connessione e non
riesco a controllare.
Così alla cieca, direi
http://www.monkey.org/~labovit/papers/labovitz-bgp-flowspec.pdf e
http://njetwork.wordpress.com/2013/04/30/mitigating-ddos-attacks-with-bgp-f
low-specification/


>
>> esiste, la frequenza dell'adozione di accordi bilaterali tra peer per
>> l'utilizzo di community di null route?

>Io non ne ho mai visto uno, e tu?

Uno dei miei clienti (un ISP "regionale" italiano) ha accordi coi propri
upstream (che sono in numero ridotto) per esportare verso di loro annunci
/32 taggati con una community concordata per il blackhole.
Tralasciando i "dettagli" politici e/o commerciali :-) francamente mi
sembra una soluzione di facile implementazione e basso costo operativo:
banalizzando, serve una telefonata per mettersi d'accordo e tre righe di
configurazione sui router.

saluti


--
Marco Gioanola
Consulting Engineer, EMEA
Arbor Networks
mgioanola@arbor.net
+39 339 7584747 (m)

--> See you at Cisco Live, Jan.28th-30th, Milano <--

Please be advised that this email may contain confidential information. If
you are not the intended recipient, please notify us by email by replying
to the sender and delete this message. The sender disclaims that the
content of this email constitutes an offer to enter into, or the
acceptance of, any agreement; provided that the foregoing does not
invalidate the binding effect of any digital or other electronic
reproduction of a manual signature that is included in any attachment.





>



Maggiori informazioni sulla lista itnog