Hoewel DDoS-aanvallen al tientallen jaren bestaan, zijn ze sinds een aantal weken wereldnieuws, door de urenlang onbereikbare websites van ING, DigiD en andere bedrijven. Zijn die aanvallen dan niet te weerstaan? Niet eenvoudig, maar met een gelaagde netwerkbeveiliging wel aanzienlijk beter.
Waarschijnlijk zal het altijd wel een kat en muisspel blijven tussen de cybercriminelen en hackers en ict-managers die hun netwerk zo goed mogelijk proberen te beveiligen. Net als in de echte wereld leiden er in de virtuele wereld echter meer wegen naar Rome, die ook voor het afweren van DDoS-aanvallen te volgen zijn.
De bekendste zijn special ontwikkelde DDoS-beveiligingsoplossingen, die net als virusscanners continu moeten worden aangepast aan de nieuwste technieken die aanvallers gebruiken. Die oplossingen zijn ongetwijfeld goed, maar ook vrij kostbaar. Een goede aanvulling op deze specialistische DDoS-oplossingen is bescherming met behulp van ‘Unified Application Services Gateways’ (UASG). Deze zijn namelijk speciaal ontwikkeld om de beschikbaarheid van bedrijfskritische applicaties onder alle omstandigheden te optimaliseren, dus ook tijdens de piekbelastingen door een DDoS-aanval. UASG’s bestaan uit een combinatie van hardware en software, inclusief beveiliging, om zowel applicatieservers te ontlasten van zware netwerktaken, als deze te beschermen tegen digitale aanvallen.
Aanvallen weerstaan
Om DDoS-aanvallen te kunnen weerstaan, is het belangrijk te weten waar die vandaan komen en waaruit ze bestaan. Zo’n 25 procent ervan zijn zogenaamde SYN flood-aanvallen. Via de speciale processor en software in UASG-appliances zijn tegenwoordig ruim tweehonderd miljoen SYN floods per seconde af te weren zonder dat applicatieservers daar merkbaar last van hebben. Verder bieden de appliances ook functionaliteit zoals een DNS Application Firewall, ter bescherming tegen uitzonderlijke piekbelastingen en aanvallen op de DNS-server. Door namelijk op voorhand verdachte queries te blokkeren, kan alleen geoorloofd verkeer de DNS-server bereiken.
Andere mogelijkheden die UASG’s bieden om DDoS-aanvallen te weerstaan, zijn het cachen van excessief netwerkverkeer, source/destination rate limiting en het filteren naar geografische herkomst. Bij de DigiD-aanval is bijvoorbeeld het blokkeren van buitenlands netwerkverkeer als tijdelijke oplossing gebruikt.
Tenslotte zijn er ook nog andere mogelijkheden om extreme pieken in het netwerkverkeer zoals door een DDoS-aanval veroorzaakt te limiteren zonder dat applicatieservers daardoor plat gaan of veel trager functioneren. Daarom kunnen UASG’s bij veel organisatie meer waarde toevoegen aan de netwerkinfrastructuur dan alleen maar de applicatieprestaties verhogen en de beschikbaarheid van applicaties garanderen.
Ik weet vrijwel niets van DDoS-attacks. Noch wijzelf, noch klanten van ons hebben er ooit mee te maken gehad. Maar dit opiniestuk helpt mij ook niet verder. Ik heb nooit gedacht dat de applicatie-servers ermee te maken zouden hebben. Het probleem zou zich m.i. alleen af kunnen spelen op BGP- of Layer 3 switch niveau. De applicatieservers kunnen er dus ook last van ondervinden (zonder een UASG).
Blokkeren van buitenlands verkeer snap ik ook al niet. Wat maakt het nu uit of de Denial-of-Service (is toch blokkeren?) nu plaatsvindt op basis van een (buitenlands) source ip-segment of op basis van gebrekkige integriteit van het pakket?
Hoeveel bandbreedte is 200 miljoen syn-floods per seconde? Ondervinden de applicatieservers dan überhaupt nog verkeer? Dit artikel roept m.i. meer vragen op dan dat het beantwoordt. Behoudens die ogenschijnlijke teaser van een UASG, zou het niet misstaan in een provinciale avondkrant of zo. Maar wat heeft de Computable-gemeenschap hier nou aan?
Het artikel is wel erg intern gericht, dwz. het beschermen van de applicatieserver. Dat er hele goede apparatuur is om de DDOS weg te houden bij de applicatieservers is duidelijk maar de vraag blijft wel of gebruikers er dan niet alsnog last van hebben als iedereen van buiten komt.
Blokkeren van buitenlands verkeer is wel logisch aangezien de meeste aanvallen van buiten europa komen (in landen met wat meer gebrekkige opsporing en/of wetgeving).
En in de gelaagdheid mis ik nog de benodigde bandbreedte. Als je het pijpje maar dun genoeg maakt dan komt het verkeer niet eens aan bij al die mooie spullen.
M.i. is het nog altijd zo dat een port te maken krijgt met een flood. Men kijkt doorgaans op welke wijze de grootste schade is aan te richten.
Dat gaat absoluut niet meer op domweg packages te zenden naar een bepaald IP adres.
Ik vraag me dan ook een beetje af of een UASG ‘het’ schijnt te doen. Hackers en flooders zijn niet helemaal van gisteren en doen doorgaans aardig huiswerk voor ze iets opzetten.
@Rob Koelmans, ik hoop dat je wat hebt aan de volgende toelichting.
Ad1: In hoofdlijnen zijn er twee typen DDoS attacks, die allebei in heel veel varianten kunnen worden toegepast.
1) Volumetric attacks, zorgen voor het te vol drukken van de uplinks/verbindingen van een hosting of internet access omgeving; dit gebeurt veelal met ICMP of UDP verkeer en dan vooral veel en grote packets. Voor het filteren van dit soort attacks moet je eigenlijk altijd terugvallen op je provider, of als je zelf provider bent is het afhankelijk van de afmetingen van je netwerk en kan je in sommige gevallen terugvallen op gespecialiseerde aanbieders van DDoS scrubbing diensten. Middels specifieke BGP advertisements is het mogelijk om attack verkeer om te leiden naar een scrubbing center. Overigens helpt het in sommige gevallen ook om de omleiding op basis van DNS te doen.
2) Application Level attacks, richten zich niet op het voldrukken van verbindingen, maar op het uitputten van resources van server(s), applicaties, of andere infrastructuur componenten van een hosting omgeving. Denk hierbij bijvoorbeeld aan de door Harry beschreven SYN attacks, die zorgen voor het vollopen van de connection tabel van een besturingssyteem, maar ook het sturen van meer HTTP requests dan een server, of platform kan afhandelen. Als je 1500 HTTP reqs/sec stuurt naar een platform dat maar 1000 reqs/sec kan afhandelen, dan wordt kan je spreken van “denial of service” voor de 500 requests die de limieten van het platform overschrijden.
UASG oplossingen en andere gespecialiseerde DDoS mitigation oplossingen kunnen in beide varianten helpen om de load te verminderen. In het geval van Volumetric attacks zet je de oplossing liever aan de provider kant van een verbinding. In het geval van een Application Level attack, kan je de oplossing ook in je eigen infrastructuur plaatsen.
**
Ad2. Het blokkeren van buitenlands verkeer kan helpen om de impact van een DDoS aanval te verkleinen. Dit statement gaat er wel van uit dat de aangevallen website/omgeving zich richt op legitieme gebruikers die zich in Nederland bevinden (denk Digid en Belastingdienst). De bulk van het Internet leeft immers buiten Nederland en de bulk van het attack verkeer is statistisch gezien dus afkomstig uit het buitenland. Als je buitenlands verkeer kan blokkeren binnen je netwerk middels een UASG of DDoS mitigation appliance, of kan verhinderen dat het uberhaupt je netwerk raakt (door samenwerking met ISP, of als ISP met je IP transit leveranciers of peers), dan is er meer ruimte voor het veelal legitiem verkeer dat z’n oorsprong in Nederland heeft. Natuurlijk zijn er in Nederland ook vele PC’s die geinfecteerd zijn en deelnemen in botnets, maar in vergelijking met de rest van het Internet zijn dat er weinig, omdat we in een klein land wonen. De schaalgrootte van attacks waarin Nederlandse bots worden gebruikt zijn veel kleiner en het is dus makkelijker om je tegen dat restje attackverkeer te beschermen.
**
Ad3. 200 miljoen SYN-packets per seconde is veel bandbreedte, meer dan veel ISP netwerken in Nederland op hun BGP edge routers kunnen verwerken. Het is natuurlijk fijn als je een UASG hebt waarvan je weet dat hij tot 200 miljoen SYN-packets kan handlen. Dan weet je tenminste zeker dat je ook een meer realistische attack van 200K tot 4M packets per seconde kan afweren. En je hoeft natuurlijk niet persee de grootste UASG of DDoS mitigation appliance te kopen.
@Frans: Hallo Frans, bedankt voor je toelichting. Hier heb ik absoluut wat aan (en veel andere computable-lezers vermoedelijk ook). Ik heb nog een andere vraag (wel of niet beantwoorden is uiteraard vrijblijvend).
Ik las ergens dat ze door misbruik van openstaande DNS servers het effect van een packet van een geïnfecteerde pc kunnen vervijftigvoudigen. Kun je dat mechanisme eventueel toelichten? Zijn er manieren om misbruik van een DNS te beperken vanaf geïnfecteerde pc’s (als het om pc’s gaat waarvoor die DNS wel open moet staan?
@Rob: Sorry voor de trage reactie. Ik had niet in de gaten dat je had gereageerd.
Je doelt op DNS amplification attacks. Dit is een attack type dat wij in de eerste maanden van dit jaar heel vaak voorbij hebben zien komen bij klanten.
Het is belangrijk om hier een aantal zaken toe te lichten:
1) DNS
2) Spoofing
3) DNS Amplification
1) Domain Name System (DNS) Servers zijn een essentieel onderdeel van het Internet om hostnames (www.bedrijf.nl) om te zetten in een IP(v4) adres, of een IPv6 adres; daarnaast geven nameservers bijvoorbeeld ook informatie over waar e-mails voor een bepaalde domeinnaam moeten worden afgeleverd.
Bedrijven en Service Providers gebruiken in hun infrastructuur caching nameservers. Deze caching nameservers vragen via een recursief systeem van rootservers en authorative nameservers die gegevens op bij de bron. Deze gegevens worden dan enige tijd opgeslagen, zodat niet voor iedere klant van bijv. XS4ALL, de bron nameservers moeten worden benaderd als die naar http://www.telegraaf.nl surft.
Het is de bedoeling dat een caching nameserver wordt geconfigureerd op zo’n manier dat deze alleen kan worden gebruikt door de gebruikers waar hij voor is bedoeld. XS4ALL doet dat natuurlijk goed en schermt z’n caching nameservers af, zodat alleen haar klanten er bij kunnen, maar helaas zijn er bedrijven met minder kennis van zaken, die recursieve “queries” toestaan vanaf de hele wereld. De verkeerd geconfigureerde nameservers worden ook wel Open Resolvers genoemd.
2) DNS werkt nog goeddeels op basis van UDP dataverkeer. Er hoeft dus in tegenstelling tot TCP geen handshake plaats te vinden tussen een server en een client. Bij UDP kan de authenticiteit van de client niet worden gegarandeerd.
Boosdoeners kunnen vanaf een vervalst IP adres een UDP DNS query sturen naar een Open Resolver. De server zal dan een antwoord sturen naar het vervalste IP adres, maar de eigenaar van dat vervalste IP adres had helemaal niet om dat antwoord gevraagd. Het vervalsen van IP adressen heet spoofing.
3) Een DNS query kan heel klein zijn, zo’n 60 bytes. Met de recente ontwikkelingen in het DNS systeem qua beveiliging (DNSSEC) en IPv6, worden de DNS antwoorden steeds groter. Voorheen was de maximale grootte van een DNS reponse 512 bytes, maar die is door de standaarden-organisaties bijgesteld naar boven om ruimte te bieden voor de extra functionaliteiten in DNS. Met de juiste DNS query van 60 bytes, kan je in theorie een response genereren van 4096 bytes, ofwel een “amplificatie” met ruim een factor 60.
Als je zo’n grootte amplificatie combineert met spoofing, dan kan je dus middels een 100Mbps (bijv. glasvezel) internet verbinding, een attack van zo’n 6 Gigabit per seconde lanceren op het gespoofde IP adres, terwijl de aanvaller daarbij niet direct terug te traceren is. Een andere manier van aanvallen is het gebruiken van een botnet van geinfecteerde PC’s. Als die allemaal wat gespoofde DNS queries versturen naar een Open Resolver, of naar meerdere Open Resolvers, dan kunnen er behoorlijk forse attacks worden gelanceerd.
De impact van dit type attack kan op een aantal manieren beperkt worden:
* eigenaren van Open Resolvers dienen ze af te sluiten, zodat alleen de legitieme gebruikers er verzoeken op af kunnen voeren
* service providers dienen aan de rand van hun netwerk te filteren en te zorgen dat alleen packets van en naar hun eigen IP adressen worden doorgelaten. Hiermee voorkom je spoofing, een belangrijk onderdeel van deze attack.
* In datacenter/internet omgevingen kan er middels UASG’s of DDoS mitigation appliances slim worden gefilterd. Nadeel is dat je het verkeer dan wel al in je netwerk hebt, dus je hebt kans dat de Internet uplink dan al vol zit.
’t Is weer een flink verhaal geworden, maar ik hoop dat het de boel verduidelijkt. Mocht je nog vragen hebben, dan hoor ik ’t graag.
Hoi Frans, bedankt voor je antwoord. Ik begrijp eruit dat een besmette machine dus ook zijn eigen dns-server niet kan misbruiken voor attacks naar adressen die niet tot de bediende reeks van die dns-server behoren (of het zou moeten zijn, dat de zombie en het aangevallen adres toevallig dezelfde dns-server hebben).
Het zou in een hiërarchisch ingerichte structuur als DNS toch vrij eenvoudig moeten zijn updaten van de cache te blokkeren als ze voor de wereld openstaan. Dan worden ze snel genoeg dichtgezet.
Beste Rob. Inderdaad kan een besmette machine niet z’n eigen DNS-server misbruiken, aangenomen dat dat geen ‘Open Resolver’ is.
Een beetje ISP zorgt er zelfs voor dat z’n nameserver ook niet kan worden gebruikt om andere klanten die van dezeffde nameserver gebruik maken aan te vallen, door IP spoofing in hun netwerk tegen te gaan. Dat kunnen de moderne subscriber management platformen over het algemeen heel goed.
’t Jammere is dat in een recursief request aan een root- of authoratative nameserver niet zichtbaar is of die voor een bepaalde valide of invalide eindgebruiker wordt gemaakt. Er wordt vanaf de Open Resolver gewoon een nieuwe DNS request gestuurd en die is niet van legitiem verkeer te onderscheiden. De “makkelijkste” methode om hier iets aan te doen is pro-actief het internet af te gaan scannen naar Open Resolvers. Dat doen de misbruikers ook. Alleen als je zelf gaat scannen met goede bedoelingen, dan heb je best kans dat dat niet door iedereen op prijs wordt gesteld. Het lijkt me beter dergelijke gecoordineerde acties te laten coördineren door organisaties als SIDN, RIPE, ARIN, Internic, zodat er onder de ISP’s ook voldoende draagvlak komt voor dergelijke scans.