Onderwerp: Beveiliging tegen toekomstige DDOS aanvallen?

Beste mensen,

ik ben op zoek naar een goedkope beveiliging tegen ddos attacks.

heb er nu naar mijn weten nog geen last van,

ik heb een dedicated server met Windows Server 2008 R2 SP1.
de webserver is IIS7.5

Wat is een mogelijk goede oplossing om ervoor te zorgen dat ik geen last zal hebben va neventuele attacks in de toekomst?


Met vriendelijke groet,

Mark Schrik

Je hebt heel veel verschillende soorten (D)DoS attacks, dus wil je een goede bescherming hebben, dan moet je op meerdere punten kijken. Je hebt bijvoorbeeld een filter nodig die rare en grote hoeveelheden requests filtert. Maar als je maar een 100 mbps link hebt, dan kan iemand natuurlijk met een flinke hoeveelheid packets jouw 100 mbps makkelijk vol krijgen, dus dan moet er ook worden gefilterd bij je access/transit provider.

Oorspronkelijk geplaatst door dutchmarks

ik ben op zoek naar een goedkope beveiliging tegen ddos attacks.

Goedkope beveiliging tegen iets wat onmogelijk of extreem moeilijk te voorkomen is bestaat simpelweg niet. Als iemand je wijsmaakt dat het met software kan, dan vertellen ze niet de (volledige) waarheid.

Ga denken aan een kleine 100k wil je een redelijke firewall hebben.
Maar ook dan heb je nog niet iets perfects. praat je over een firewall met een 10gb verbinding.
ook die is vol te krijgen met een redelijke DDOS aanval

De goedkoopste en beste oplossing tegen DDoS aanvallen zijn goede afspraken met je uplink provider, hoe dichter je bij de bron geraakt hoe beter. DDoS stoppen op je server helpt totaal niet, je verplaatst gewoon het probleem. Het enige waar je iets of wat voordeel kunt uit halen is om packets te droppen in plaats van een reject terug te zenden, maar je inbound aantal packages blijft hierdoor op je server wel nog steeds hetzelfde. Hiermee bedoel ik in plaats dat je ram en cpu gebruikt worden voor zaken waar ze voor dienen (services) wordt het dan opgeslokt door je firewall en uit het standpunt van je switch/uplink/transit wordt jouw traffiek nog altijd toegelaten op het netwerk en betaal je er ook voor. Kortom het doel van een DDoS is het buiten werking stellen van de service/server op welke manier dan ook, door ofwel de service te overbelasten of de firewall te overbelasten of de switch te overbelasten of ...

Oorspronkelijk geplaatst door patrickekkel

Ga denken aan een kleine 100k wil je een redelijke firewall hebben.
Maar ook dan heb je nog niet iets perfects. praat je over een firewall met een 10gb verbinding.
ook die is vol te krijgen met een redelijke DDOS aanval

Een 10G DDos bestaat, maar de term 'redelijk' is dan een understatement. Dat is nog steeds een fors grote DDoS.
Als ik 100K moest besteden aan DDoS resiliency zou dat niet in één luxe firewall gaan zitten.

En al helemaal niet zonder een idee te hebben van wat service erachter zit. Sommige sites trek je met 10 valide adsl sessies ook makkelijk onderuit, ook al staan ze achter zo'n firewall van 100K....

Oorspronkelijk geplaatst door The-BosS

De goedkoopste en beste oplossing tegen DDoS aanvallen zijn goede afspraken met je uplink provider, hoe dichter je bij de bron geraakt hoe beter. DDoS stoppen op je server helpt totaal niet, je verplaatst gewoon het probleem. Het enige waar je iets of wat voordeel kunt uit halen is om packets te droppen in plaats van een reject terug te zenden, maar je inbound aantal packages blijft hierdoor op je server wel nog steeds hetzelfde. Hiermee bedoel ik in plaats dat je ram en cpu gebruikt worden voor zaken waar ze voor dienen (services) wordt het dan opgeslokt door je firewall en uit het standpunt van je switch/uplink/transit wordt jouw traffiek nog altijd toegelaten op het netwerk en betaal je er ook voor. Kortom het doel van een DDoS is het buiten werking stellen van de service/server op welke manier dan ook, door ofwel de service te overbelasten of de firewall te overbelasten of de switch te overbelasten of ...

In het eerste deel van je post ga je impliciet ervan uit dat de DDoS bestaat uit een overmaat van goed herkenbaar verkeer. Dat is vaak wel het geval, maar niet altijd natuurlijk.

Het droppen (of rejecten, maakt vrijwel niks uit) van verkeer is iets wat een server ontzettend veel makkelijk kan dan een echte dienst afhandelen, dus daar hoeft je server nauwelijks trager van te worden, zolang valide verkeer niet al op de verbinding weggedrukt is.

Het laatste deel van wat je schrijft is erg terecht, en daarom is de vraag van TS niet te beantwoorden.
(of, gegeven de vraag met ook nog de eis 'goedkoop' is het antwoord gewoon "nee" ).
Voor een redelijk capabele DDoSer moet je alle noodzakelijke resources beschermen. Niet alleen de pijp, ook bijvoorbeeld de DNS'en. Liggen die eruit, dan kan de server nog zo robuust zijn en hangen aan een heel dikke lijn,maar is de dienst toch feitelijk onbereikbaar.
Je moet dus de totale dienst op alle lagen snappen en navenant monitoren en kunnen beschermen bij een DDoS, en dat is lastig.

De goedkoopste oplossing is redelijk simpel. Tijdens de ddos gewoon de boel nulrouten. Ok, je bent dan niet te bereiken, maar het mogelijke verlies van eventuele orders of een paar 1000 bezoekers voor een paar uur etc... is in 99 van de 100 gevallen goedkoper dan een beheerder laten proberen om een ddos te tackelen, 100k firewalls aan te schaffen of simpelweg te dokken voor het traffic.
Als je namelijk al bang bent om door een ddos een paar uur eruit te liggen, moet je eerst eens gaan denken aan een echt redundant systeem (zowel hardwarematig als softwarematig) want een storing in je software kan je ook gemakkelijk een tijdje lam leggen.
Let wel: er zijn sites die zich downtijd niet kunnen permiteren uiteraard en wel de betreffende investeringen moeten doen om zoveel mogelijk tegen te houden, maar dan spreek je over een redelijk hoog nivo van sites. En anno 2012 gaan die ook gewoon nog down (paypal, facebook, google, ideal).

Ik heb er eventueel ook geen moeite mee om een 2e server in een ander datacenter te plaatsen.. ik weet niet of dit verschil maakt in de bovenstaande mogelijkheden?, en met goedkoop, is meer bedoeld dat we niet aan bedragen komen van 500 euro per maand..

In elk geval al bedankt voor de huidige reacties!

Je zou natuurlijk ook eens naar diensten kunnen kijken als https://www.cloudflare.com/plans of ddos protected hosting, heb er zelf geen ervaring mee. Maar op zich lijkt het me dat gedeelde infrastructuur goedkoper is dan alles helemaal zelf organiseren..

Oorspronkelijk geplaatst door dutchmarks

Ik heb er eventueel ook geen moeite mee om een 2e server in een ander datacenter te plaatsen.. ik weet niet of dit verschil maakt in de bovenstaande mogelijkheden?, en met goedkoop, is meer bedoeld dat we niet aan bedragen komen van 500 euro per maand..

Zoals visser het zo mooi uitlegt maakt dat voor een DDoS niets uit, als je eerst server down gaat en jij switched naar je 2de server in andere datacenter dan zal die ook gewoon een DDoS krijgen. We leven niet in de tijd dat er enkel nog op IP adressen (D)DoS aanvallen zijn, je zal waarschijnlijk vlugger een DDoS op je hostname krijgen. En dan kun je inderdaad je hostname in je dns even veranderen op 127.0.0.1, zodat de DDoS'ers (botnet) zichzelf aanvallen . Je kunt bijvoorbeeld ook een service aanvallen die je niet down wil krijgen, maar die zwakker beveiligd is en meer resource verbruikt op je server en connecties open houdt, zodat andere services geen resources meer hebben of geen connecties meer kunnen maken.

Om een voorbeeld te geven ik heb een volledig bedrijf stil zien vallen omdat de switch een DoS aanval kreeg op een management ip (dat gewoon via local lan bereikbaar was, dus geen management lan), waardoor alle servers op die switch onbereikbaar waren. Bij nader onderzoek bleek een van de client pc's geinfecteerd met een virus dat een nmap achtig iets deed en wanneer hij een router/switch vond direct begon met DoS aanval.

@visser: over dat eerst deel bedoel ik eigenlijk als jouw uplink provider goede contacten heeft met zijn transit/peering provider etc kun je bij de bron gaan blokken en dat is voor iedereen beter. Ben niet meer zo thuis in BGP etc, maar daar was een rfc voor met een community setting als ik me niet vergis om bij je transit automatische routes te blokken/null routen. Betreft de drop/reject bedoel ik meer op het feit dat een reject nog een packet terug zend en de DDoS'er dus weet dat je nog steeds online bent. Bij een directe drop zullen ze misschien vlugger stoppen omdat ze denken dat het niet meer werkt (of is het zo ingesteld in het botnet/...).

Vergeet ook niet dat je alle typen botnets kunt huren voor een paar tientjes. Daar kan je wel een hoop tegenaan gaan gooien maar die mensen lachen je vierkant uit. Is het niet je server die een ddos krijgt, dan is het wel je beurs

Oorspronkelijk geplaatst door The-BosS

[..]
@visser: over dat eerst deel bedoel ik eigenlijk als jouw uplink provider goede contacten heeft met zijn transit/peering provider etc kun je bij de bron gaan blokken en dat is voor iedereen beter. Ben niet meer zo thuis in BGP etc, maar daar was een rfc voor met een community setting als ik me niet vergis om bij je transit automatische routes te blokken/null routen. Betreft de drop/reject bedoel ik meer op het feit dat een reject nog een packet terug zend en de DDoS'er dus weet dat je nog steeds online bent. Bij een directe drop zullen ze misschien vlugger stoppen omdat ze denken dat het niet meer werkt (of is het zo ingesteld in het botnet/...).

Goede contacten hebben is inderdaad een deel van een effectieve DDoS/security respons, dat klopt, en hoe eerder iets gedropt wordt, des te beter.
Een upstream netwerk kan inderdaad met BGP communities een downstream klant de mogelijkheid geven om verkeer voor een bepaald adres *van die klant* al op de borders te null routen.
Met dit mechanisme kan een verkeer ook door een scrubber device geleid worden (die alleen 'valide verkeer' doorlaat), maar dat is echt een specifieke service die afgenomen moet worden; (Een null route community is een redelijk standaard feature)

Verkeer droppen is natuurlijk nog steeds een denial of service op dat adres, maar het beperkt de collateral damage voor andere bestemmingen binnen die klant die niet meer onbereikbaar zijn vanwege een overvolle access lijn.
(Het netwerk breed droppen van verkeer van bepaalde _source_ adressen is een mechanisme wat je, als upstream provider, niet zomaar aan een klant geeft. Het kan wel een tool in je gereedschapskist zijn, maar binnen je eigen netwerk).

Ik betwijfel (maar heb geen directe informatie) of DDoS aanvallers veel moeite doen om de aanval te controleren en dan kijken naar drop vs reject ; Ik verwacht eerder dat een aanval gewoon voor een tijd wordt aangezet.

Wij hebben goede ervaringen met Prolexic, om een euh "getargette klant" te beschermen. Kost een pak duiten, maar doet dingen die je super-duper-mega-de-luxe firewall niet kan: namelijk verhinderen dat je bandbreedte opgesoupeerd wordt. Want zelfs al jij 10Gbps zou hebben, wat ben je met je firewall als je 3Gbps normaal verkeer hebt + een DDoS van > 7Gbps? Mag die firewall nog zo goed zijn, plat ga je.

DDoS attacks vandaag de dag worden verzonden door dedicated servers met een snelle uplink die packets door duizende proxies tegelijk douwen
deze proxy lijst word natuurlijk regelmatig vervangen door een nieuwe lijst met ip's
firewalls zullen je hierbij niet echt kunnen helpen, zeker als de network uplink van de aanvaller groter is dan die van zijn target.

Als je een website wilt beschermen zou je een external DNS service zoals zoneedit.com kunnen linken aan je domain
en daar dan die A records toevoegen maar inplaats van de echte server ip voeg je reverse proxies toe van providers zoals www.x4b.org of www.xsltel.com
deze reverse proxies zelf link je aan het echte server ip en daarna activeer je de load balancing service van zoneedit (failover)
nu als iemand verbind met je domain gaan alle requests heen en terug via de reverse proxies dus je echte server ip word nooit getoond aan de bezoeker tenzij de server zelf het ip broadcast in bevoorbeeld de email headers als dat allemaal via de zelfde server draait.

Dit is een makkelijke manier om toch je website online te houden in het geval van een DDoS attack
als je meer dan alleen HTTP (TCP) traffic wil beschermen zou je dit eens moeten lezen http://wiki.buyvm.net/doku.php/gre_tunnel

Ik hoop dat je een betaalbare oplossing vind.