Onderwerp: DDos bestrijden met BCP38

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.

Ik ben er nog geen tegen gekomen waar het niet gebeurd. Ons netwerk bestaat naast AMS-IX op het moment uit Level 3, Cogent en Openpeering. Alle drie werken met prefix filters, waarbij Level3 deze automatisch genereert. Tevens weet ik dat Telia en Global Crossing dit ook doen/deden. Vrijwel alle grote partijen dus.

Vergeet niet dat enkele netwerk providers spoofing bewust toestaan als USP.

Zolang de een naar de ander wijst dat hij het maar moet doen, wordt het nooit beter.

Ongeacht of een ander het wel of niet doet Mikey, je moet het zelf altijd doen om gekkigheid uit het netwerk te weren.

Oorspronkelijk geplaatst door Stewie

Ongeacht of een ander het wel of niet doet Mikey, je moet het zelf altijd doen om gekkigheid uit het netwerk te weren.

Maar nu een lichtelijke n00b vraag.... hoe doe je dat in de praktijk? Is dat iets wat wij bijvoorbeeld als kleine partij ook kunnen doen op de edge van ons netwerk b.v. een procurve 2810? Of zou dat toch dat meer upstream moeten gebeuren?

In dit geval kan je dit op een layer 3 device doen, voor jullie waarschijnlijk dus meer upstream.

Oorspronkelijk geplaatst door Stewie

Vergeet niet dat enkele netwerk providers spoofing bewust toestaan als USP.

Nu is peering een gunst en geen verplichting ...

Oorspronkelijk geplaatst door OrangeLemon

Maar nu een lichtelijke n00b vraag.... hoe doe je dat in de praktijk? Is dat iets wat wij bijvoorbeeld als kleine partij ook kunnen doen op de edge van ons netwerk b.v. een procurve 2810? Of zou dat toch dat meer upstream moeten gebeuren?

In de manuals van de procurve 2810 kan ik er zo geen optie voor vinden.
Op een Laag3 device is een simpele accesslist altijd wel een optie. Soms is het ook al mogelijk op een Laag 2 switch; De cisco 2950/2960 is een L2 switch maar kan toch IP gebaseerd packet filteren, en precies voldoende om spoofing tegen te gaan.

Wellicht kun je zelf (ook) nog filteren op de fysieke host waar VPSen op draaien, anders is het inderdaad de zaak van het eerste laag 3 device .
Een beetje jammer als je dat zelf niet bent, want hierop monitoren geeft je een waarschuwing als devices in je netwerk dingen doen die ze echt niet zouden moeten doen (en dat wil vaak zeggen dat ze besmet /gehacked zijn ).
Het is altijd makkelijker wanneer monitoring/alarmering ook gedaan wordt in het beheerdomein wat direct kan ingrijpen.

Oorspronkelijk geplaatst door rensariens

Ik ben er nog geen tegen gekomen waar het niet gebeurd. Ons netwerk bestaat naast AMS-IX op het moment uit Level 3, Cogent en Openpeering. Alle drie werken met prefix filters, waarbij Level3 deze automatisch genereert. Tevens weet ik dat Telia en Global Crossing dit ook doen/deden. Vrijwel alle grote partijen dus.

Plezierig om te lezen dat dan toch in iets ruimere mate dan mijn natte vinger verwachting prefix filtering gedaan wordt.

Toch wil ik nog even toelichten waar mijn skepsis op gebaseerd was (en is, trouwens).

Ook als je maar af toe eens wat bekijkt op de RIPE RIS (routing monitor) zie je met enige regelmaat 'obviously wrong' prefixen. Onmogelijk breed, te specifiek, bogons.
Kortom, dingen die als je maar _iets_ wilt filteren afgevangen zouden moeten zijn. Ook in een eigen netwerk zou je op uitgaande announcements filters kunnen (en moeten) hebben die de impact van 'dikke vingers' van een change engineer ergens in het netwerk beperken tot het eigen AS.
Gelukkig wat zeldzamer zijn de 'youtube pakistan' incidenten, ook iets wat een prefix filter bij de telco met het foutje, of diens transit had kunnen vangen.

Verder is transit een volume business met lage marges. Dat betekent dat er weinig ruimte is voor dingen die niet automatisch kunnen, of niet met een template en een relatief junior implementatie engineer.

Tenslotte, voor elk soort werk zijn er evenementen/fora waar mensen die in die tak zitten elkaar eens zien, en zo ook voor engineers van service provider transit cores. Ik heb gewerkt in deze hoek, en volg nog steeds de ontwikkelingen.
Bij presentaties, en daarna/daarnaast (BoF) hoor je geen mensen die zeggen 'wij hebben _alles_ voor elkaar', en het zijn al de goede en betrokken engineers die je daar tegenkomt. Wel doen ze wat ze reëel kunnen implementeren qua techniek en gegeven de support organisatie, "but we still have some corner cases that I hope to ..." . Ook bij mijn toenmalige werkgever was het niet technisch perfect. We deden het gemiddeld goed, de 'simpele' aansluitingen gewoon strak, maar hadden ook lastiger gevallen waarbij we wel een sanity check filter maar de zaak niet technisch strak en niet dicht tegen een voldoende creatieve fout of puur malicous gedrag. Nu hingen dat soort complexere setups natuurlijk
wel samen met klanten van voldoende omvang dat je redelijke competentie en professionaliteit mag verwachten, dus dat was wel te overzien.

Op een aanverwant onderwerp (en datapuntje) , er wordt gewerkt om route updates beter te verifiëren. Een van de kandidaten is soBGP (secure origin BGP). Het is een manier waarbij providers via een heel PKI framework bij de route registries (RIPE e.a.) kunnen controleren of een prefix de juiste bron heeft.
(zie 'rpki' op de site van RIPE )

Het kip-ei probleem is dat om het 100% automatisch aan te zetten de registry data dan ook wel _echt_ up to date moet zijn komt altijd naar voren. Bij de zaalvraag 'wie zou het nu 100% aan zetten' (en dus prefixen die mismatchen met registry data direct weigeren) gaan dan weinig of geen handen omhoog.
Mee experimenteren, loggen van mismatches, ja, maar goed genoeg om blindelings aan te zetten is een andere vraag.

Het is natuurlijk een analoge discussie voor secure DNS, wie nu een validating resolver niet alleen laat loggen maar echt geen antwoord geeft voor niet validerende domeins heeft veel onterecht onbereikbare domeinen (dwz: geen DNS spoofing maar wel een fout in DNSSEC configuratie)

Op termijn denk ik dat die ontwikkeling (soBGP) wel doorgaat, maar ik zie het nog wel een tijd lopen voor implementaties om zich uit te ontwikkelen, en de service providers om het in te gaan voeren, en dan het doordringen van implementaties van 'logging only' naar 'soms aan' naar 'aan met uitzonderingen' en uiteindelijk 'altijd aan'.

Anyway, met die achtergrond weet ik in elk geval zeker dat prefix filteren < 100% is . Waar ik wel benieuwd naar ben maar geen antwoord op heb is of het 50/50, 80/20, 90/10 ,70/30 is, en of die verhouding dan zou zitten in een aantal SPs dat helemaal niks doet (en andere die echt alles doen), of dat erg veel SPs het meeste wel doen maar allemaal wel een aantal lastige gevallen hebben waar ze niet alle prefixen kunnen filteren.