BGP blackhole

[xares]

Ik ben bezig met onze nieuwe netwerk setup aan het uitwerken, echter kom ik ergens niet uit.
Op onze oude routers deden we altijd een blackhole community sturen naar alle BGP neighbours en was het IP-adres wat we blackholde offline.

Nu willen we het aanpakken door alleen op bepaalde transit partijen uit het buitenland een blackhole te sturen als we een DDOS binnen krijgen. Zo zijn we wel online voor de Nederlandse peers (en bereikbaar voor de grootste groep klanten).

Op zich geen probleem zou je zeggen echter kom ik er niet helemaal uit hoe we dit kunnen verwerken. Een static null-route met TAG hoe we het altijd deden werkt niet omdat het IP-adres dan alsnog voor alle neighbours offline is. De community naar alleen een bepaalde BGP neighbour sturen is het probleem niet.

Hoe we het altijd doen:

code:

ip route 192.168.1.100 255.255.255.255 null0 tag 200

Maar dan zal direct voor alle BGP neighbours incl. intern traffic offline zijn.

Tips en trucs zijn welkom

[Dafjedavid]

Zou je zo iets niet kunnen doen met een route-map?
En die alleen toepassen op de buitenlandse peers?
zo iets:
https://mailman.nanog.org...2011-February/033570.html

Ben niet zo BGP-erig maar daar zou ik naar kijken

[Voor 21% gewijzigd door Dafjedavid op 30-05-2015 12:25]

[ik222]

Je zou in plaats van een null route een kloppende route met een tag aan kunnen te maken. Vervolgens distribueer je die net als met een null route naar je edge routers. Daar zorg je er dans voor dat op basis van die interne community naar de transits waarop je dat wilt hun blackhole community wordt meegegeven.

Nadeel daarvan is wel dat je bij het aanmaken van de trigger route dan moet weten wat de juiste next hop is en dat je de trigger route dan het best kunt aanmaken op de router waar je target achter zit. Immers omdat het nu geen null route is moet je er voor zorgen dat het target ook echt via deze route bereikbaar is. In grotere deployments is het dus niet heel erg praktisch op deze manier.

[Voor 17% gewijzigd door ik222 op 30-05-2015 14:28]

[JackBol]

Het makkelijkst is om een peer-group maken voor je transit partijen en buitenlandse klanten en een peer-group maken voor je Nederlandse klanten en vervolgens deze blackhole community alleen naar de ene peer-group sturen.

[xares]

De oplossing van ik222 zou inderdaad kunnen, ga eens kijken of ik dat kan uitwerken.

@jackbol en @Dafjedavid Het nadeel is dat ik een ip route met null0 moet aanmaken om de route effectief in BGP te krijgen. Maar dan is dat IP-adres sowieso niet meer te bereiken intern en voor andere BGP transits.

[JackBol]

Je hoeft die null-route toch niet per se in je IGP op te nemen?

[xares]

Hm heb je een voorbeeldje toevallig?

Volgens mij gaat dat niet lukken aangezien zonder static route die route niet in BGP komt?


Het nadeel is dat onze BGP router waar transits op aangesloten zitten ook klanten direct met hun interface opzitten.

[Voor 31% gewijzigd door xares op 30-05-2015 17:05]

[JackBol]

xares schreef op zaterdag 30 mei 2015 @ 17:01:
Hm heb je een voorbeeldje toevallig?

Volgens mij gaat dat niet lukken aangezien zonder static route die route niet in BGP komt?


Het nadeel is dat onze BGP router waar transits op aangesloten zitten ook klanten direct met hun interface opzitten.

Ah okay, dan gaat dat niet zomaar lukken.
Wat je kan doen is een VRF aanmaken een daar de null-route in stoppen. Deze export je vervolgens van de VRF naar je global tabel. In de global tabel kun je een route-map gebruiken om ervoor te zorgen dat de route niet vanuit BGP in je IGP komt.

[ik222]

JackBol schreef op zaterdag 30 mei 2015 @ 21:36:
[...]


Ah okay, dan gaat dat niet zomaar lukken.
Wat je kan doen is een VRF aanmaken een daar de null-route in stoppen. Deze export je vervolgens van de VRF naar je global tabel. In de global tabel kun je een route-map gebruiken om ervoor te zorgen dat de route niet vanuit BGP in je IGP komt.

Over een oplossing met een VRF en dan een export heb ik ook zitten denken maar volgens mij werkt dit niet. Om de router de route uiteindelijk via BGP te kunnen laten adverteren moet hij altijd in de lokale routing table komen in de VRF waar ook je BGP neigbours in zitten waar je hem met een community naar wilt adverteren (global). Je kunt er middels een route-map / policy voor zorgen dat de route niet verder verspreid wordt via een IGP protocol. Maar dat neemt niet weg dat de router waar de transits op zitten waar je hem naar wilt adverteren dan altijd al het verkeer in die VRF (global) nog steeds zal nullrouten. Dus ook dat van andere peers of klanten op die router / in die VRF.

Als je gescheiden VRF's hebt voor de transits waar je de black hole naar wilt adverteren en de rest van het verkeer kan dit wel alleen is dat hier dus niet het geval zoals ik lees. Meerdere VRF's met in beide een volledige route tabel is meestal ook niet lekker ivm memory overigens.

In geval van gescheiden routers waarop je wel en niet wil blackholen kan je het makkelijk oplossen met communties en een route-map / policy op je iBGP sessie. Alleen heb je daar in deze situatie niets aan.

[Kabouterplop01]

Gaat je verkeer niet omzwaaien naar je peers, of heb je alles static?

[ik222]

Kabouterplop01 schreef op zondag 31 mei 2015 @ 14:46:
Gaat je verkeer niet omzwaaien naar je peers, of heb je alles static?

Bij blackholing door een transit provider trekt die provider nog steeds gewoon verkeer aan, zijn externe announcements van jou netwerken wijzigen namelijk niet. Alleen door een specifieke prefix (meestal in IPv4 een /32) ook nog eens met een speciale community te adverteren naar de transit provider gaat de transit provider verkeer naar die prefix droppen in zijn netwerk waardoor het niet op jou lijn aan komt. Verkeer gaat dus gewoon het zwarte gat in bij je transit provider en zwaait niet om naar een andere transit of naar peers.

[xares]

Ik zat nog te denken aan om een virtuele BGP router te installeren op een server en een iBGP sessie op te zetten naar onze router. Gaat dat werken of krijg ik die null-route die via iBGP wordt gestuurt ook niet geannounced zonder op te nemen in IGP?

[ik222]

Het probleem daarbij blijft dan volgens mij dat de null route altijd in de lokale route tabel moet komen te staan van de router / vrf die uiteindelijk hem moet announcen naar je transits.

De enige mogelijkheid voor jou gewenste situatie die ik kan bedenken met een null route is de transits waar je naar wilt nullrouten in een aparte VRF zetten. Vervolgens maak je in die VRF een BGP sessie met je trigger router (dat kan inderdaad prima een linux bak met een BGP deamon zijn). Als laatste exporteert je dan vanuit de transit VRF met een policy alles behalve de null routes van je trigger naar global. Andersom exporteer je alles vanuit global weer naar die transit VRF. Alleen persoonlijk vind ik dat geen mooie / goede oplossing om meerdere redenen waarbij een van de belangrijkste het geheugen gebruik is (vooral wanneer je met full route tabels werkt).

De mooiste oplossing hiervoor zou denk ik BGP flowspec zijn. Alleen is dat in de huidige vorm volgens mij niet geschikt om te praten tussen klant en provider waardoor je het daar ook niet ziet. Ook kan je het voor zover ik weet niet gebruiken om externe blackholes aan te sturen. Maar binnen je eigen netwerk geeft het wel echt hele mooie flexibele mogelijkheden voor DDoS mitigatie in de lijn met wat jij zoekt.

[JackBol]

xares schreef op zondag 31 mei 2015 @ 15:21:
Ik zat nog te denken aan om een virtuele BGP router te installeren op een server en een iBGP sessie op te zetten naar onze router. Gaat dat werken of krijg ik die null-route die via iBGP wordt gestuurt ook niet geannounced zonder op te nemen in IGP?

Ja dat kan prima, als je bgp no synchronization configureert hoeft de null route niet in je igp. Je moet ook een route map op je redistribution zetten die de null route uitfiltert.

[ik222]

JackBol schreef op zondag 31 mei 2015 @ 15:55:
[...]

Ja dat kan prima, als je bgp no synchronization configureert hoeft de null route niet in je igp. Je moet ook een route map op je redistribution zetten die de null route uitfiltert.

Maar dan komt de null route toch nog steeds in de ip route tabel te staan op de router / in de VRF waar die null route via iBGP ontvangen en weer via eBGP geadverteerd wordt? Of mis ik iets?

[Kabouterplop01]

ik222 schreef op zondag 31 mei 2015 @ 15:19:
[...]

Bij blackholing door een transit provider trekt die provider nog steeds gewoon verkeer aan, zijn externe announcements van jou netwerken wijzigen namelijk niet.

Maar de TS is niet de transit provider. De transit provider rekent gewoon geld voor een DDoS op jouw prefix (als het verkeer door de transit pijp loopt)
Dus het ligt aan jouw local prefs en med die je naar je peers én transit aankondigt, of het verkeer omzwaait, of niet, vandaar ook de vraag.

[ik222]

Dat weet ik maar je wilt je bij een DDoS gewoon je netwerk bereikbaar houden. Sowieso kun je in BGP niet alles adverteren behalve een specifieke /32, een hele prefix terugtrekken is meestal geen optie. Dus de enige optie is dan verkeer gewoon laten aantrekken door je transit providers of zelfs een speciale wasstraat en het daar filteren / droppen.

Overigens kost verkeer dat je laat nullrouten bij je transit meestal geen geld omdat het niet eens op je transit link aankomt. Een beetje transit provider gaat verkeer dat een klant wil nullrouten ook gewoon op alle borders nullrouten waardoor de transit provider het ook niet hoeft te transporteren. Maar dit hangt natuurlijk wel af van je contract inderdaad.

[JackBol]

ik222 schreef op zondag 31 mei 2015 @ 16:06:
[...]

Maar dan komt de null route toch nog steeds in de ip route tabel te staan op de router / in de VRF waar die null route via iBGP ontvangen en weer via eBGP geadverteerd wordt? Of mis ik iets?

Ne hoor, de route komt alleen in de BGP RIB.
Met een route-map zorg je ervoor dat de null route niet in de RIB komt.

Vervolgens kan je met bgp no syncrhonisation ervoor zorgen dat de null route gewoon adverteert word.

[ik222]

JackBol schreef op zondag 31 mei 2015 @ 16:34:
[...]


Ne hoor, de route komt alleen in de BGP RIB.
Met een route-map zorg je ervoor dat de null route niet in de RIB komt.

Vervolgens kan je met bgp no syncrhonisation ervoor zorgen dat de null route gewoon adverteert word.

Ah nu snap ik wat je bedoelt, even opgezocht en inderdaad kun je middels een table-map / table-policy statement in de address-family (Cisco) filteren welke routes vanuit BGP in de route tabel komen. En met no-synchronization kan je gefilterde routes dan inderdaad alsnog gewoon adverteren via eBGP. Dat is dan een mooie oplossing inderdaad

[Voor 7% gewijzigd door ik222 op 31-05-2015 17:13]

[xares]

Hm ik ben er gisteren weer mee aan de slag gegaan i.c.m. ExaBGP (mooie tool trouwens incl API!).
Alles lijkt nu te werken behalve dat de /32 nog steeds in IGP komt.

code:

ip prefix-list only32 seq 5 permit 0.0.0.0/0 ge 32

router bgp
 local-as xxxx
 -knip-

 address-family ipv4 unicast
 table-map deny-blackhole-in-IGP
-knip-
exit-address-family


route-map deny-blackhole-in-IGP deny 10
 match ip address prefix-list only32

Het gaat om een Brocade router.
Dat zou volgens de voorbeelden moeten werken? Jullie een idee?

[Kabouterplop01]

ik222 schreef op zondag 31 mei 2015 @ 16:20:
Dat weet ik maar je wilt je bij een DDoS gewoon je netwerk bereikbaar houden. Sowieso kun je in BGP niet alles adverteren behalve een specifieke /32, een hele prefix terugtrekken is meestal geen optie. Dus de enige optie is dan verkeer gewoon laten aantrekken door je transit providers of zelfs een speciale wasstraat en het daar filteren / droppen.

Vandaar ook mijn vraag je mag nl niet kleiner dan een /24 aankondigen naar internet (of tenminste mag wel, maar een beetje isp dropt dat)
dus als je dat door je transit laat doen klopt er iets niet; je staat dan je transit toe om een prefix hijack te doen, in dit geval een more specific van je superblock.

Of ik snap nog steeds niets van de vraag

[ik222]

Die /32 gaat door de transit provider ook helmaal niet verder announced worden Het adverteren van een dergelijke /32 (of ander klein subnet) in combinatie met een specifieke community is puur iets tussen jou en je transit provider en dient enkel als seintje naar je transit provider zodat deze weet dat verkeer naar die prefix gedropt moet worden in hun netwerk. Uiteraard moet je transit provider dit ondersteunen maar de meeste doen dat.

Maar de externe announcements van je netwerk veranderen dus helemaal niet tijdens een dergelijke blackhole. Je vertelt alleen je transit provider(s) het verkeer naar een bepaalde kleine prefix te droppen .

[Voor 44% gewijzigd door ik222 op 08-06-2015 23:10]

[Kabouterplop01]

check! een soort offramp community. Ik snap het nu beter!

[JackBol]

Kabouterplop01 schreef op maandag 08 juni 2015 @ 23:11:
check! een soort offramp community. Ik snap het nu beter!

Blackholing is wel een hele extreme vorm van off-ramping