Onderwerp: DDos bestrijden met BCP38

Op het blog van CloudFlare staat een interessant artikeltje over hoe ze de DDos tegen SpamHaus hebben aangepakt.

http://blog.cloudflare.com/the-ddos-...offline-and-ho

In het artikel wordt gerefereerd naar BCP38 een Best Practive voor "Network Ingress Filtering - Defeating Denial of Service Attacks which employ IP Source Address Spoofing".

Het is een artikel uit 2000, maar omdat het door Cloudflare wordt aangehaald wellicht nog actueel.

http://tools.ietf.org/html/bcp38

Ik kan hier verder niks concreets over vinden over hoe dit toegepast zou moeten worden.

Iemand hier ervaring mee of ooit iets mee gedaan?

Oorspronkelijk geplaatst door OrangeLemon

Op het blog van CloudFlare staat een interessant artikeltje over hoe ze de DDos tegen SpamHaus hebben aangepakt.

http://blog.cloudflare.com/the-ddos-...offline-and-ho

In het artikel wordt gerefereerd naar BCP38 een Best Practive voor "Network Ingress Filtering - Defeating Denial of Service Attacks which employ IP Source Address Spoofing".

Het is een artikel uit 2000, maar omdat het door Cloudflare wordt aangehaald wellicht nog actueel.

http://tools.ietf.org/html/bcp38

Ik kan hier verder niks concreets over vinden over hoe dit toegepast zou moeten worden.

Iemand hier ervaring mee of ooit iets mee gedaan?

Bijna iedereen, hoop ik ?

Het zegt gewoon 'zorg dat er geen verkeer uit je netwerk gaat met source adressen die niet van jou zijn' .

Dat is voor 'eind netwerken' (niet-transit) vrij simpel om te doen . Het kan wat lastiger zijn om het tot op host niveau te doen, maar op de rand van je netwerk zorgen dat alleen source adressen van je 'eigen' IP space naar buiten gaan kan prima.
Liever natuurlijk doe je dit op het niveau van access subnets, of nog beter op host niveau .

Routers hebben vaak een 'unicast RPF' feature. Daarbij worden packets waarbij de beste route terug naar de source NIET via het inkomende interface loopt gedropt. (rpf - reverse path forwarding) .
Op een gewoon access interface met een subnet met een stel hosts is dat een prima check.
Natuurlijk kan het ook met gewoon een access list, maar die moet je per interface bijhouden met de bijbehorende subnets.
(alleen in een transit wolk, met asymmetrische paden kun je dat niet zo maar doen ).

Erg veel van de DDoSen de laatste tijd werkten via DNS Amplifiers; En naast de open resolvers , en ongelimiteerde authoritieve DNSen hebben die aanvallen ook spoofing nodig (om de query met het source adres van het slachtoffer te doen).
Hoe meer netwerken BCP38 (anti spoofing) doen, des te lastiger worden deze DDoSen.

Dus ja, heb je een router, zorg dat er geen gespoofed verkeer vanuit je hosts kan komen.
Log het als een host dat toch probeert, want de kans is dan erg groot dat de klant (bewust, of gehacked) deelneemt aan een DDoS.

BCP38 / Ingress filtering is het filteren van je uitgaand verkeer zodat alleen traffic van je eigen IP's verder het internet op gaat.

Als grote transit providers als Level 3, Cogent etc. eens beginnen met het filteren van het uitgaande verkeer van hun klanten dan zal dat al veel schelen.

Oorspronkelijk geplaatst door dennis0162

BCP38 / Ingress filtering is het filteren van je uitgaand verkeer zodat alleen traffic van je eigen IP's verder het internet op gaat.

Als grote transit providers als Level 3, Cogent etc. eens beginnen met het filteren van het uitgaande verkeer van hun klanten dan zal dat al veel schelen.

Nou even niet afschuiven dat "hullie" vooral moeten filteren. anti-spoofing is vooral iets voor wat _jullie_ (edge netwerken) kunnen en moeten doen.

Lees vooral BCP 38, want die gaat voor een groot deel wanneer het filteren niet meer simpel kan.
Hoe dichter bij de bron, des te simpeler is het filteren.

Een transit provider kan lang niet in alle omstandigheden technisch _weten_ welke source IPs valide zijn van een klant aansluiting.
De business (case) dat een klant precies één upstream provider had waarover 'alles' naar buiten gaat is al lang weg, en klanten kunnen heel wel een sources een transit insturen waarvoor het beste pad terug niet via die transit loopt.

In een ideale wereld zijn alle mogelijke source prefixen dan geregistreerd (RIPE e.a.), en zou de transit provider daarmee statische filters kunnen bouwen. En de echte wereld is de transit provider dan snel klanten kwijt, want goed/compleet registreren gebeurt bij lange na niet genoeg.(juist niet door de prutsers die zelf ook al niet filteren).

Kortom, als filteren niet bij de rand (1e provider van de host) gedaan is, is het technisch al heel snel vervelend om het 'verderop' nog goed te kunnen doen.
Afschuiven is geen optie.

het makkelijkste is op je eigen firewall zaken proberen tegen te houden.
Door bijvoorbeeld trafiek naar een niet bestaande dest te sturen

Oorspronkelijk geplaatst door visser

Nou even niet afschuiven dat "hullie" vooral moeten filteren. anti-spoofing is vooral iets voor wat _jullie_ (edge netwerken) kunnen en moeten doen.

Lees vooral BCP 38, want die gaat voor een groot deel wanneer het filteren niet meer simpel kan.
Hoe dichter bij de bron, des te simpeler is het filteren.

Een transit provider kan lang niet in alle omstandigheden technisch _weten_ welke source IPs valide zijn van een klant aansluiting.
De business (case) dat een klant precies één upstream provider had waarover 'alles' naar buiten gaat is al lang weg, en klanten kunnen heel wel een sources een transit insturen waarvoor het beste pad terug niet via die transit loopt.

In een ideale wereld zijn alle mogelijke source prefixen dan geregistreerd (RIPE e.a.), en zou de transit provider daarmee statische filters kunnen bouwen. En de echte wereld is de transit provider dan snel klanten kwijt, want goed/compleet registreren gebeurt bij lange na niet genoeg.(juist niet door de prutsers die zelf ook al niet filteren).

Kortom, als filteren niet bij de rand (1e provider van de host) gedaan is, is het technisch al heel snel vervelend om het 'verderop' nog goed te kunnen doen.
Afschuiven is geen optie.

Als maar 10% van de edge netwerken filtert dan blijf je met het probleem zitten. Als de grote transit providers gaan filteren bereik je meteen veel netwerken.

Het correct filteren van ingress verkeer bij je klanten vandaan zorgt ervoor dat je in ieder geval niet zelf de veroorzaker bent van een deel van dit probleem.

Maar je upstreams vragen dat correcte filters toepassen bij hun klanten is minstens net zo belangerijk ...

Tijdens RIPE66 in Dublin vandaag werd hier vanmiddag een aantal uur over gesproken en dat het spoofing probleem een 80/20 probleem is.. De 20% die het niet doet is de oorzaak van de ellende en dat is niet alleen bij rogue hosters, maar ook veel CPE's die geen spoofed traffic stoppen en access providers die niet eens weten wat ingress filtering is of doen en daarmee wellicht nog wel een grotere source van dit probleem zijn ...

Iedere transit partij weet van welke downstream hij bep. Verkeer kan verwachten, omdat ze ook die pfizes adverteren..

En als een klant bep. Verkeer niet naar een transit stuurt in bgp, wil niet zeggen dat ze die transit niet kunnen vragen om dat wel in het ingress filter toe te staan zodat het niet tegen een acl loopt.

Er is geen excuus om te zeggen dat het niet kan ... En als je goeie edge equipment gebruikt, dan dropt de edge switch by default al het aangeboden Layer 3 verkeer wat er niet op het vlan is geconfigureerd...

Op de Extreme Networks equipment die wij gebruiken in ons netwerk moeten we het uitzetten als we specifiek spoofing zouden willen aanzetten. ( dat kan soms noodzakelijk zijn in geval van migraties van netwerk naar netwerk ).

Oorspronkelijk geplaatst door visser

In een ideale wereld zijn alle mogelijke source prefixen dan geregistreerd (RIPE e.a.), en zou de transit provider daarmee statische filters kunnen bouwen. En de echte wereld is de transit provider dan snel klanten kwijt, want goed/compleet registreren gebeurt bij lange na niet genoeg.(juist niet door de prutsers die zelf ook al niet filteren).

De meeste transit's filteren ook je announcements dus voor het uitgaand filteren kan je dezelfde access lists voor gebruiken.

Oorspronkelijk geplaatst door dennis0162

Als maar 10% van de edge netwerken filtert dan blijf je met het probleem zitten. Als de grote transit providers gaan filteren bereik je meteen veel netwerken.

Lees mijn verhaal nog een paar keer. Er zijn praktische en technische redenen waarom filteren op transit gewoon erg lastig is.

Oorspronkelijk geplaatst door Rubra

Iedere transit partij weet van welke downstream hij bep. Verkeer kan verwachten, omdat ze ook die pfizes adverteren..

Nee, dat hoeft op zich niet. De meest botte manier van traffic engineering is een aantal prefixen gewoon niet adverteren naar bepaalde neighbours.

Plus dat adverteren helemaal niet wil zeggen dat die route ook in de forwarding table als beste route terecht komt.
Je kunt een route met een berg prepends en wat communities erg onaantrekkelijk maken, zodat de route via een andere transit (zolang die aanwezig is) een beter pad vormt.
Desnoods door meer specifieke prefixen via de preferred transit te announcen, en alleen een aggregaat via de 'backup' .

Packet filteren op basis van een route die alleen als 'reserve' in BGP zit maar niet in de forwarding hardware is bepaald geen standaard feature.

Oorspronkelijk geplaatst door Rubra

En als een klant bep. Verkeer niet naar een transit stuurt in bgp, wil niet zeggen dat ze die transit niet kunnen vragen om dat wel in het ingress filter toe te staan zodat het niet tegen een acl loopt.

Yeah right. Inderdaad, dat kunnen ze vragen als ze eraan denken. Het type klant wat daar aan denkt heeft het niet nodig, en degenen voor wie het moet vragen dat zeker niet tevoren.
De business case voor transit verkeer laat weinig handmatig werk toe. En bouwen op basis van registry data is ook onbetrouwbaar, omdat juist de prutsers dat ook niet bijhouden.

Er is geen excuus om te zeggen dat het niet kan ... En als je goeie edge equipment gebruikt, dan dropt de edge switch by default al het aangeboden Layer 3 verkeer wat er niet op het vlan is geconfigureerd...

Op de Extreme Networks equipment die wij gebruiken in ons netwerk moeten we het uitzetten als we specifiek spoofing zouden willen aanzetten. ( dat kan soms noodzakelijk zijn in geval van migraties van netwerk naar netwerk ).

Voor _edge_ netwerken is er inderdaad echt geen excuus om niet standaard te filteren.
Daar is het simpel , zero maintenance en min of meer fool-proof.

Oorspronkelijk geplaatst door dennis0162

De meeste transit's filteren ook je announcements dus voor het uitgaand filteren kan je dezelfde access lists voor gebruiken.

Ik waag te betwijfelen of "de meeste" transits filteren op basis van _prefix_ filters per klant. Het zou mooi zijn, maar ik denk het niet.
Dat is een beetje onderhouds intensief, in tegenstelling tot wat generieker filteren op AS pad, prefix lengte e.d, en deny van wat obviously wrong prefixen.
Verder zitten in routers prefix filters in een ander stuk config dan access lists (packet filters); Niet meteen technisch herbruikbaar, hoewel je inderdaad een packet filter zou kunnen genereren uit dezelfde bron waar je een prefix gebaseerd bgp filter vandaan haalt.

(En als die bron 'mail/telefoon/ticket met de klant' moet zijn wordt het al snel lastig om vol te houden ).

Oorspronkelijk geplaatst door visser

Ik waag te betwijfelen of "de meeste" transits filteren op basis van _prefix_ filters per klant. Het zou mooi zijn, maar ik denk het niet.
Dat is een beetje onderhouds intensief, in tegenstelling tot wat generieker filteren op AS pad, prefix lengte e.d, en deny van wat obviously wrong prefixen.

Doen ze zeker. Soms geautomatiseerd d.m.v. route objecten via bijvoorbeeld RIPE. Overigens kunnen er legitieme redenen zijn om het tijdelijk toe te staan, dus afschuiven lijkt me niet echt verstandig. Als je apparatuur het aan kan gewoon regelen dus

Oorspronkelijk geplaatst door rensariens

Doen ze zeker. Soms geautomatiseerd d.m.v. route objecten via bijvoorbeeld RIPE. Overigens kunnen er legitieme redenen zijn om het tijdelijk toe te staan, dus afschuiven lijkt me niet echt verstandig. Als je apparatuur het aan kan gewoon regelen dus

Sorry, maar daar wil ik toch wat onderbouwing voor.
"Mijn transit doet het voor ons" is niet genoeg onderbouwing voor "de meeste transits" en/of "bij de meeste klanten" doen het.

Met name als de klant ietwat complexer is (meer dan een handvol prefixen, doet zelf een transit voor een paar ASjes) is het bijhouden van goede filters (prefix, laat staan packet filter) relatief veel overhead, terwijl de de business gewoon marginaal is.

Oorspronkelijk geplaatst door visser

Sorry, maar daar wil ik toch wat onderbouwing voor.
"Mijn transit doet het voor ons" is niet genoeg onderbouwing voor "de meeste transits" en/of "bij de meeste klanten" doen het.

Met name als de klant ietwat complexer is (meer dan een handvol prefixen, doet zelf een transit voor een paar ASjes) is het bijhouden van goede filters (prefix, laat staan packet filter) relatief veel overhead, terwijl de de business gewoon marginaal is.

Wij hanteren ook prefix lists, gewoon met de hand maargoed zo ontiegelijk veel hebben we er dan ook weer niet.
Wat ik wel weet is dat o.a Interoute letterlijk een uitdraai maakt van onze Ripe as-set en die inlaad op hun routers. M.a.w als wij vergeten hun een mail te sturen dat ze opnieuw een uitdraai moeten maken van de as-set dan werkt de nieuw toegevoegde prefix dus echt niet. (voorbeeld)