Onderwerp: [colo] impact van een DDoS aanval

Zijn de Flooding Controls in de Cisco switch effectief om een DoS tegen te gaan? Ik las zoiets dat een poort automatisch uitgezet kan worden bij een bepaalde PPS.

En misschien een domme vraag, maar als ik een IP adres niet announce, dan krijgt mijn switch daar toch ook geen verkeer meer van. Dus als ik die poort dichtzet, dan houd het verkeer toch ook op?

Voor zover het uitmaakt, ik doe zelf geen routing...

Ik heb me wel eens laten vertellen dat een 3com 1100, oud beestje dus, intern 6TB aankan qua verkeer, dus zo snel zal dat ding niet stoppen met switchen lijkt mij. Kan ik natuurlijk heel erg mis hebben, maar ik ben geen netwerk man, dus misschien kan iemand me hierin verbeteren

GetUP: die 6TB zal wel 6Gb zijn, als je het tenminste over de backplane hebt.

MediaServe: volgens mij moet je provider zo'n ddos op de router afhandelen. Want wanneer jij gewoon de port dichtgooit op de switch zit het verkeer al in het netwerk voordat geconcludeerd wordt dat het betreffende IP niet bereikbaar is en moet jij alsnog dokken (itt de klant, die nu idd geen verkeer meer over z'n portje ziet gaan en dus "niets meer verbruikt").

Of zit ik er nu heel ver naast? 't Is tenslotte nog vroeg

Ik ben samen met een klasgenoot bezig met een onderzoek en implementatie van een anti DDoS mechanisme als afstudeerproject voor onze opleiding.

Ons mechanisme divert de DDoS attack door middel van het BGP protocol. Het idee is dat een specifiek deel van een netwerk (bijvoorbeeld /24, liefst nog specifieker, denk aan een /32) wordt geannounced door een bepaald mechanisme. Hierdoor wordt de DDoS attack afgewend van het netwerk van de ISP. Het DDoS verkeer wordt dan naar een blackhole oid gestuurd.

Resultaat: het resterende deel van de provider (er van uitgaande dat deze wel meerdere adres blokken heeft). De DDoS attack heeft dan geen resultaat meer! Er zijn natuurlijk nog wel wat problemen wat betreft het announcen, je kan natuurlijk niet zomaar de adresspace gaan announcen van andere partijen.

Wat zijn jullie ideeen bij dit mechanisme?

Je bedoeld dat je dan bijvoorbeeld stopt met het announcen van een bepaalde /24? Dan is de ddos gestopt, de rest van je netwerk prima bereikbaar maar de klanten in die /24 zijn nog steeds offline. Dus heeft de DDoS-er infeite bereikt wat hij wil..

Theoretisch zou je de geddos-de /24 nog verder op kunnen delen in kleinere ranges maar die worden door sommige providers uit de routing tabel gefilterd omdat ze zo klein zijn en daardoor de routing tabel te groot wordt. Dit is dus ook niet handig.

Zijn er betere oplossingen?

Origineel geplaatst door svbeek
Je bedoeld dat je dan bijvoorbeeld stopt met het announcen van een bepaalde /24? Dan is de ddos gestopt, de rest van je netwerk prima bereikbaar maar de klanten in die /24 zijn nog steeds offline. Dus heeft de DDoS-er infeite bereikt wat hij wil..

Theoretisch zou je de geddos-de /24 nog verder op kunnen delen in kleinere ranges maar die worden door sommige providers uit de routing tabel gefilterd omdat ze zo klein zijn en daardoor de routing tabel te groot wordt. Dit is dus ook niet handig.

Zijn er betere oplossingen?

Je klanten in 1 /24 zijn dan onbereikbaar, maar al je andere klanten hebben NERGENS meer last van. Opzich lijkt me dat al een fijn idee.

Beter is alle ddos gevoelige servers in een apart stuk PI te steken, zodat je deze kan withdrawen zodra je een ddos krijgt.

Origineel geplaatst door svbeek
Je bedoeld dat je dan bijvoorbeeld stopt met het announcen van een bepaalde /24? Dan is de ddos gestopt, de rest van je netwerk prima bereikbaar maar de klanten in die /24 zijn nog steeds offline. Dus heeft de DDoS-er infeite bereikt wat hij wil..

Nee, je stopt niet met announcen, je gaat noujuist op een andere plek (zo dicht mogelijk bij de source) als een malloot announcen zodat de attack wordt weg geleid. De gevolgen van de DDoS attack zijn negatief,maar het voordeel is dat de andere diensten (in een ander deel van het netwerk)van de provider toch weer bereikbaar zijn.

Of je zet een MAX connection limit op alle IRC porten, een ddos word dan netjes door je router gedropt.

Dan kunnen je klanten gewoon IRC hosten alleen geen grote netwerken/botnets of een denial of service aanval ontvangen.

9 van de 10 keer zijn ddos attacks toch op IRC en verder gewono udp op port 80 filteren etc, dat is soms ook in trek.

groeten
reinier

En als je een IRCD draait? met... 500 tot 1000 man op? Of als je 500 bouncers host?
Dat lijkt mij niet echt een oplossing...

Origineel geplaatst door Reinier v Eeden
Of je zet een MAX connection limit op alle IRC porten, een ddos word dan netjes door je router gedropt.

Dan kunnen je klanten gewoon IRC hosten alleen geen grote netwerken/botnets of een denial of service aanval ontvangen.

9 van de 10 keer zijn ddos attacks toch op IRC en verder gewono udp op port 80 filteren etc, dat is soms ook in trek.

groeten
reinier

Maar je router krijgt dan dus nog wel al het DDoS verkeer binnen waar je voor moet betalen, en deze moet dan wel zo'n hoeveelheid traffic aankunnen.

Origineel geplaatst door Tuinslak
En als je een IRCD draait? met... 500 tot 1000 man op? Of als je 500 bouncers host?
Dat lijkt mij niet echt een oplossing...

Je kunt het filter toch aanpassen, het max aantal connecties kun je zelf toch invoeren in je configuratie.

groeten
reinier

Origineel geplaatst door svbeek


Maar je router krijgt dan dus nog wel al het DDoS verkeer binnen waar je voor moet betalen, en deze moet dan wel zo'n hoeveelheid traffic aankunnen.

Natuurlijk ook afhangende wat voor router het is maar een beetje kan wel 48 miljoen packet/s droppen. Meestal komt er toch niet meer binnen

Althans wij hadden er geen problemen mee, nu filteren we niet meer.

groeten
reinier

Origineel geplaatst door MediaServe
Bedankt voor de reacties zover
In principe moet de klant betalen voor al het dataverkeer dat hij genereert. Als hij bijvoorbeeld IRC diensten draait en een DDoS aanval krijgt, dan vind ik het eigenlijk onterecht dat ik daar als provider voor moet betalen.

Maar wat ik eigenlijk nog belangrijker vind, hoe houd het netwerk zich tijdens zo'n aanval? De switch die XF-RICK noemt, de HP 2524, die levert vrijwel gelijke performance als de Cisco 3524 XL. Is zo'n aanval van 250 Mbps een hele fikse aanval, of zijn er geregeld grotere aanvallen?

Capaciteit is het probleem dus niet, maar het gaat meer om de PPS die de switch te verwerken krijgt.

Capaciteit is nooit echt een probleem, de wat goedkopere switches kunnen problemen krijgen van aardig wat veel PPS. Ze blijven in veel gevallen gewoon wel netjes doorswitchen, en krijgen een hoge CPU load, waardoor web en telnet niet meer beschikbaar wordt. Tevens zul je ook tijdelijk hogere pings hebben hierdoor.

Qua routing ook voor de rest geen problemen, wel leert men dan 100 Mbit lijntjes tegenwoordig niet meer voldoen tijdens een DDOS attack.

Het is al een heel stuk moeilijker om een gbit lijntje vol te krijgen dan een 100 mbit lijntje. Routers hebben tijdelijk wat hogere CPU load maar komen eigenlijk nooit boven de 45% uit.

Indien een klant slachtoffer is van een DDOS wordt er vrijwel gelijk gehandeld, we laten de lijn richting de klant niet vollopen, en lichten de klant in van de DDOS. Indien de klant geen reactie geeft, wordt er op tijdelijk afsluiting overgegaan.

Dossen van 250 Mbit is nog aardig klein te noemen, tegenwoordig is 700 Mbit geen raar verschijnsel meer.

Origineel geplaatst door XF-RICK

Qua routing ook voor de rest geen problemen, wel leert men dan 100 Mbit lijntjes tegenwoordig niet meer voldoen tijdens een DDOS attack.

Moet je die wel af kunnen krijgen..
Bij sommige transit providers moet je minimaal 50 mbit afnemen voor ze je willen voorzien van een gigabit lijntje.

Origineel geplaatst door XS-24
Je provider het ip laten nullrouten.

Ik heb er niet zoveel verstand van maar vroeg me het volgende af:
Kan je een IP null-routen ik snap dat je een domein kan null-routen maar een IP?

En wat heeft het voor een zin om een IP te null routen bij je provider dit betekend dat het verkeer toch nog helemaal naar je provider toe komt en dan pas wordt ge null-route, dan heeft het je provider toch al capaciteit gekost?