Inleiding
An English translation of this article is available.
De RioRey RX1810 is een appliance die speciaal is ontwikkeld om DDoS-aanvallen tegen te gaan. Tweakers.net heeft deze aangeschaft om zich beter tegen zulke aanvallen te beschermen, en omdat het een interessant apparaat is, hebben we er een review over geschreven.
Attack!
Het doel van een Denial-of-Service-aanval, kortweg: een DoS, is het onbruikbaar maken van een service, zoals een website of een chatserver. Als er veel aanvallers bij een DoS betrokken zijn, spreken we van een distributed DoS oftewel een DDoS.
RioRey definieert een DDoS in zijn handleiding als 'an attack which uses a flood of traffic to overwhelm a server on the Internet.' Dit simpele concept kan op talloze simpele en vooral minder simpele manieren in de praktijk worden gebracht. Een aanval kan op elke legitieme vorm van internetverkeer lijken, en omdat het internet duizenden legitieme toepassingen kent, moet een DDoS-verdediging duizenden verschillende aanvallen kunnen afslaan.
Verder stelt de handleiding dat de meeste DDoS-aanvallen tegenwoordig door minstens vierduizend computers worden uitgevoerd en dat botnets bij echt grote aanvallen honderdduizenden machines tellen. Ook weet RioRey te melden dat eind 2008 al voor 4 dollarcent per bot per dag een aanval kon worden opgezet.
Waarom beschermen?
Bescherming tegen DDoS-aanvallen kost uiteraard tijd, geld en moeite en de meeste sites worden niet bepaald dagelijks aangevallen. Daarom zal het niet voor iedereen zinvol zijn om preventieve maatregelen te nemen. Er moet dan ook een afweging tussen kosten en baten van bescherming worden gemaakt.
De kosten zitten vooral in de aanschaf en het extra onderhoud. Het batenverhaal is wat ingewikkelder. In ons geval gaat het primair om een besparing op de uren die onze systeembeheerders moeten maken om een aanval (te proberen) af te slaan. Bovendien zorgt een succesvolle verdediging er direct voor dat de inkomsten uit de banners en de verschillende siteonderdelen niet in gevaar komen. Andere sites moeten bovendien rekening houden met het extra dataverkeer en de extra serverbelasting die een DDoS veroorzaakt.
De baten op de lange termijn zijn lastiger in te schatten. Als een site meer dan een paar uur down is, kan dat al bezoekers kosten. Er zijn doorgaans diverse andere sites die vergelijkbare informatie leveren, en een bezoeker die eenmaal een alternatief heeft gevonden, keert niet zomaar terug. Daarnaast kan downtime schade aan het imago van een site of het bedrijf erachter veroorzaken. Mensen verwachten tenslotte dat een site werkt.
Of bescherming zinvol is, hangt natuurlijk vooral af van de frequentie en de omvang van de DDoS-aanvallen die op een site worden uitgevoerd. Als een site nooit aangevallen wordt, is bescherming domweg weggegooid geld. De goedkoopste oplossing is immers om geen bescherming te nemen en te hopen dat het ook nooit nodig zal zijn.
Tweakers.net en DDoS-aanvallen
In augustus en september van 2009 werd Tweakers.net meermalen belaagd met DDoS-aanvallen. Een aantal van die aanvallen had ook daadwerkelijk effect. Deze aanvallen varieerden van tussen de 60 en 75 kilopackets per seconde met uitschieters tot 250kpps, en enkele tientallen tot een paar honderd megabits per seconde. Het is belangrijk om te bedenken dat dit soort aanvallen vooral veel pakketten nodig hebben om effectief te zijn. De grootte van de pakketten is vaak niet eens zo belangrijk en de hoeveelheid megabits dus ook niet.
Aangezien het niet de eerste keer was dat we last van DDoS-aanvallen hadden en we, helaas, verwachten dat het ook niet de laatste keer geweest zal zijn, zijn we dit keer op zoek gegaan naar een manier om ons te beschermen. We begrijpen uiteraard dat het lastig blijft om een aanval af te slaan die alle beschikbare bandbreedte inneemt, maar dat is dus niet per se nodig om een site plat te leggen.
De DDoS
Hoewel er heel veel verschillende aanvallen mogelijk zijn, zijn er voor websites een aantal echt relevant. Ten eerste kan een aanvaller domweg zo veel verkeer genereren dat het normale verkeer er niet meer bij kan. Een dergelijke brute-force-aanval bestaat meestal uit udp- of icmp-verkeer, maar kan ook uit kale tcp- en zelfs uit kale ip-packets bestaan.
Een 'slimmere' manier is om speciaal geconstrueerde tcp-pakketten te versturen, waarmee de werking van de netwerklaag wordt verstoord. Zo kunnen er bijvoorbeeld steeds nieuwe verbindingen half of helemaal worden geopend, zodat de lijsten met open verbindingen vol raken en er geen legitieme gebruikers meer bij kunnen. Dit zijn respectievelijk syn- en syn-ack-floods.
Als laatste kan nog geprobeerd worden om fouten of zware pagina's in webapplicaties of bugs in webservers of netwerklagen te misbruiken, bijvoorbeeld door een stroom speciale requests te versturen waar een webserver elke keer weer op crasht.
De verdediging
Tegen een brute-force-variant is weinig te doen, behalve zo snel en zo eenvoudig mogelijk het overtollige verkeer te negeren. Zo wordt er zo min mogelijk processorkracht aan besteed, waardoor er nog capaciteit is om het reguliere verkeer af te handelen.
Syn- en syn-ack-aanvallen hebben doorgaans geen volle pijp nodig, maar maken gebruik van het feit dat er maar een beperkt aantal verbindingen met een server kan worden gelegd. Zeker Apache is daar soms erg gevoelig voor. Helaas zijn er op applicatieniveau geen echt goede maatregelen tegen deze attacks, hoewel sommige webservers veel meer verbindingen tegelijk aankunnen. Dit type aanval is voor ons dan ook de belangrijkste reden om een extra beschermlaag te installeren.
Om de derde variant te voorkomen is het bijhouden van de software de beste bescherming. Als er een DoS-bug in een stuk software zit, kan een firewall daar meestal weinig tegen beginnen. In de meeste gevallen is een update van de software of een wijziging in de configuratie de beste verdediging.
Bij Tweakers.net besteden we veel aandacht aan de goede en snelle werking van de site en hebben we forse overcapaciteit om piekbelastingen op te vangen. Daardoor zijn DDoS-aanvallen op dat punt al gauw minder interessant voor aanvallers, ook al omdat die aanvallen deels met bescherming tegen de andere aanvalstypen kunnen worden opgevangen.
In de praktijk kiezen aanvallers er vaak voor om de diverse varianten te proberen en de succesvolle aanvallen te combineren. Dat gedrag maakt het voor DDoS-beschermers uiteraard alleen maar lastiger om een goede verdediging op te zetten.
/i/1268663843.jpeg?f=imagenormal "Botnet aanvallers")
Praktische mogelijkheden
Een probleem bij het kiezen van passende DDoS-bescherming is dat pas in de praktijk blijkt of deze werkt. Erger is dat in de praktijk ook kan blijken dat de oplossing false positives veroorzaakt. Het is uiteraard niet de bedoeling dat normaal verkeer geblokkeerd wordt.
Zo zijn er talloze softwarematige firewalls te vinden, waarmee een eenvoudige verdediging kan worden opgezet. Wie bescherming tegen een syn-flood zoekt, kan bijvoorbeeld uitkomen bij iptables-regels die het aantal connecties per seconde beperken, maar die kunnen averechts werken. Als een regel bijvoorbeeld maar 1 nieuwe connectie per seconde toestaat, terwijl een aanvaller probeert 99 connecties per seconde te openen, dan zal een legitieme gebruiker maar 1 procent kans hebben om de server te bereiken. Daarmee is een server met een aanval van slechts 99 packets per seconde dus nagenoeg onbereikbaar.
Andere firewallregels werken bijvoorbeeld alleen bij slecht opgezette aanvallen. Bij een van de aanvallen op Tweakers.net bleek bijvoorbeeld dat al het verkeer dezelfde ongebruikelijke source port had, zodat het blokkeren ervan triviaal was. Uiteraard moesten we dat wel eerst ontdekken en met een firewall die het nogal druk heeft, gaat dat niet erg vlot.
Er zijn ook complexere softwareoplossingen. Tijdens onze zoektochten kwamen we bijvoorbeeld de linux-tool floodmon tegen. Dit leek een veelbelovende tool, maar na een aantal tests bleek dit programma nauwelijks effectiever dan wat iptables-regels.
Een softwarematige oplossing vergt verder veel servercapaciteit. Een aanval met 350kpps zorgde er bij ons al voor dat de cpu-core die het netwerkverkeer afhandelt, volledig in gebruik was, zodat er vrijwel geen normaal verkeer verwerkt kon worden.
Kortom, de softwarematige oplossingen op een eigen linux-firewall hebben als nadeel dat er nog veel handwerk overblijft. Bovendien zijn de regels al snel te streng voor gewoon verkeer, of juist te ruim om tegen aanvallen te beschermen. Bovendien is een softwarematige verdediging niet effectief tegen gedistribueerde aanvallen met kleine hoeveelheden verkeer van heel veel verschillende adressen.
IJzervreters
Hardwarematige oplossingen zijn er in ruwweg drie smaken. Zo zijn er switches en routers met simpele DDoS-bescherming die je eigenlijk alleen maar 'aan' en 'uit' kan zetten. Het is dan echter de vraag wat er wel en niet wordt tegengehouden, of ze gericht zijn op het voorkomen van schade of juist op het bereikbaar houden van het doelwit, en hoe je er achter komt dat een systeem aangevallen wordt.
Daarnaast zijn er de generieke firewalls, die van uitbreidingsmodules kunnen worden voorzien om DDoS-aanvallen tegen te houden. Bekende namen hierbij zijn Cisco, Juniper en Checkpoint, maar er zijn nog veel meer spelers. Veel ervaring met dit soort oplossingen hebben we niet, maar voor zover we kunnen nagaan zijn ze lastig te beheren. Bovendien betaal je vaak een meerprijs voor bescherming tegen DDoS-aanvallen, terwijl het ons niet duidelijk werd in hoeverre deze systemen zijn opgewassen tegen grote hoeveelheden aanvallers die elk relatief kleine hoeveelheden verkeer genereren.
Ten slotte zijn er appliances die specifiek zijn ontworpen om DDoS-aanvallen tegen te houden. Onze nieuwe RioRey RX1810 is zo'n appliance. In deze markt zijn er eigenlijk geen bekende namen, althans, niet voor ons. Deze groep heeft natuurlijk ook nadelen: je moet weer een losse machine ophangen, die ook nog eens alleen maar dat specifieke werk kan doen. Bovendien is de kans groot dat je voor aanschaf en support niet bij je vaste leverancier terecht kan.
The sky is the limit
Het is ook nog mogelijk om bescherming buiten je eigen rack te kopen. Bij een dergelijke 'cloud'-verdediging wordt al het verkeer via het netwerk van een service provider geleid; alleen het 'schone' verkeer komt bij de eigen webservers aan. Eventueel kan dat tijdens een DDoS-aanval on demand worden gedaan door het aanpassen van routinginformatie. Dit vereist uiteraard ondersteuning van de eigen isp. Wij hebben hier verder niet naar gekeken, maar dit systeem heeft als voordeel dat er veel meer bandbreedte beschikbaar is om een DDoS op te vangen.
RioRey
Zoals al eerder gezegd was de markt voor DDoS-bescherming voor ons redelijk onbekend terrein. De keuze zou dus worden gemaakt op basis van specificaties en sales- en marketingclaims, maar gelukkig is er ook al de nodige kennis en ervaring bij onze leveranciers. Een daarvan bleek net in zee gegaan te zijn met RioRey, dat zichzelf aanprijst als 'the DDoS-specialist'.
RioRey levert momenteel drie productseries van DDoS-appliances. De RE-serie omvat twee redelijk betaalbare 1U-modellen en is bedoeld voor kleinere sites. Daarboven zit de RX-serie met met een drietal 2U-modellen. Helemaal bovenaan de ladder staat de RG: een 7U-behuizing voor maximaal acht blades met elk een 10Gbit-verbinding.
De belangrijkste verschillen bij de RE- en RX-series zitten in de hoeveelheid rekenkracht en geheugen. Daarnaast biedt de RX-serie tov de RE-serie meer redundantie en voldoende rekencapaciteit voor ipv6-ondersteuning.
Al deze modellen zijn gebaseerd op dezelfde RIOS-software. Dit is een aangepaste Linux-versie met uiteraard een laag software voor de DDoS-bescherming. Zo zijn er onder andere aparte algoritmes voor tcp-, http-, udp- en icmp-verkeer. De software meet continu of en hoe het verkeer in de afgelopen minuten is veranderd, en als er een significante verandering in verkeerspatronen wordt ontdekt, wordt er ingegrepen. De reactietijd op een DDoS bedraagt daardoor meestal rond de twee minuten.
Naast redundantie biedt de RX-serie ook nog een 'hardware bypass circuit', dat er bij uitval voor zorgt dat de verbinding die de appliance had moeten beschermen, in ieder geval blijft werken. Deze functie is overigens ook als optie voor de RE-modellen leverbaar.
Helaas heeft RioRey het grootste deel van zijn site achter een login verstopt, waardoor het wat lastig is om informatie op te snorren. We geven hier in het kort een overzicht van de belangrijkste eigenschappen van de diverse modellen.
| | RE-serie | RX-serie | RG-serie |
| Doel |
Entry-level |
Enterprise |
Large enterprise |
| Modellen |
RE500, RE1500 |
RX1800, RX2300, RX4400 |
RG10000 |
| Filtercapaciteit (kpps) |
150/300 |
300/425/1440 |
8000 |
| Aantal beschermde doelwitten |
128 |
1024 |
1024 |
| Connecties/seconde |
4M gelijktijdige sessies |
4M gelijktijdige sessies |
16M gelijktijdige sessies |
| Aansluitingen |
1000Base-T, -SX of -LX |
1000Base-T, -SX of -LX |
8x 10GBase-LX |
| Rackhoogte |
1U |
2U |
7U
|
| Gewicht |
6kg |
12,5kg, 15kg |
38kg |
| Voeding |
Enkelvoudig |
Redundant |
Redundant |
| Maximaal stroomverbruik bij 230V |
1,25A |
1,25A/2A |
15A |
De prijzen van de modellen hangen vooral af van de gekozen netwerkaansluiting. Voor de RE-modellen moet dan gedacht worden aan de bedragen die je voor de wat luxere dual-processorservers kwijt bent; de RX-serie kost grofweg hetzelfde als de duurdere dual-processor- en de goedkopere quad-processormachines. Voor de exacte prijzen kan het beste contact gezocht worden met een van de distributeurs. Voor Nederland is dat Quanza Engineering.
RioRey RX1810
De RX-serie bestaat uit de 18-, 23- en 44-modellen. Deze modellen verschillen volgens de specificaties alleen in de hoeveelheid verkeer die ze kunnen verwerken op het moment dat er een aanval bezig is. Dat is 300kpps, 425kpps en 1,4Mpps voor respectievelijk de 18-, 23- en 44-uitvoeringen. Aangezien wij normaliter vrij weinig inkomend verkeer hebben, leek ons de 300kpps-uitvoering voldoende. Deze bak kan met de kleinste packets van 64 bytes dik 150Mbps aan verkeer verwerken en met maximale grootte van 1500 bytes zelfs een theoretische 3,6Gbps.
De aanvallen die we uitvoerden zaten geregeld over de 350kpps, dus die inschatting van de capaciteit zit waarschijnlijk nog aan de veilige kant. Wel werd de RioRey-appliance dan behoorlijk zwaar belast.
Overigens kunnen de RX-machines naar keuze met een tweetal simpele RJ45-stekkers, multimode SX/LC-glasvezel of singlemode LX/LC glasvezel geleverd worden. Dat levert respectievelijk 10, 11 of 12 achter het typenummer op.
Uiterlijk
De RX1810 is een 2U-rackmount zonder sliders. De groene voorkant met het forse RioRey-logo valt nog wel een beetje op, maar voor de rest is het apparaat simpel en vrij saai. Hoewel een fraai staaltje industrieel design wel leuk zou zijn geweest, hebben we natuurlijk liever dat de fabrikant zijn geld in goede DDoS-bescherming investeert 
De constructie is robuust en professioneel. Het enige wat zwakkere onderdeel is de groene klep die de aansluitingen aan de voorkant beschermt. Die wordt door twee (te) kleine magneetjes op zijn plaats gehouden en sluit al niet goed meer als een van de kabels ook maar een beetje scheef door de opening aan de bovenkant komt.
Het verkeer wordt met twee netwerkkabels door de appliance geleid. Verder zijn er nog een seriële en een netwerkpoort voor de managementinterface aanwezig. Om ook op locatie een statusoverzicht te kunnen krijgen is het systeem voorzien van een drietal ledjes die de status van het systeem en een eventuele DDoS-aanval aangeven.
Innerlijk
Omdat we de garantie op onze gloedjenieuwe RX1810 graag geldig houden, hebben we het apparaat maar niet opengeschroefd. Wel hebben we een korte blik in een demomodel kunnen werpen. Ook de binnenkant bleek daarbij zakelijk en degelijk afgewerkt. Het kabelmanagement is niet zo strak als in de Sun- en Dell-servers die we eerder hebben aangeschaft, maar alles zit wel stevig en praktisch aangesloten.
De cpu-koeler is een gigantisch koelblok dat dankzij heatpipes direct voor de systeemfans geplaatst kon worden. De cpu is een gewone AMD Opteron-dualcore met in totaal 16GB ram. Voor de permanente opslag is flashgeheugen gemonteerd.
Bijzonder zijn de speciale netwerkkaart en de monitoringhardware die RioRey meelevert, maar aan de buitenkant is het lastig te zien wat die hardware precies doet. De netwerkkaart is in elk geval uitgerust met de eerder genoemde hardware-bypass, waarmee het apparaat in feite in een nogal prijzig RJ45-koppelstukje verandert; het verkeer over de kabels wordt dan ongezien doorgestuurd. Deze mode wordt bijvoorbeeld ingeschakeld als de appliance een update uitvoert of als de stroom eraf gehaald wordt. Zo zijn de servers achter de RioRey altijd bereikbaar.
Webinterface
De RX1810 heeft verder een eenvoudige webinterface. Hier stel je de basisconfiguratie voor met name de managementinterface in. Dat gaat dan om zaken als het ip-adres en de verschillende externe servers zoals ntp, smtp, dns, syslog, radius en snmp.
De interface is haast verfrissend kaal: er zijn wat simpele html-formulieren en tabellen met een licht oranje achtergrond, en daar houdt het wel zo'n beetje mee op. Het is dan ook de bedoeling dat er hier maar een paar minuten aan de instellingen wordt besteed. Daarna kan de appliance geheel met de rView-software worden bestuurd.
De rView-beheersoftware
De RioRey wordt gemonitord en bediend met de rView-software. Dit pakket is geschreven in Java en kan via een ssh-tunnel met een of meerdere RioRey-appliances communiceren.
Het updaten van de RIOS-software is erg simpel: je laadt de nieuwe systeemdefinitie in de appliance, vervolgens geef je aan dat er een update uitgevoerd moet worden en één reboot later ben je klaar. Het hele proces neemt maar een paar minuten in beslag. Mocht er iets misgaan, dan kan je op dezelfde manier terug naar een vorige versie. Tijdens de upgrade wordt de netwerkkaart in de hardware-bypass-mode gezet, zodat de beveiligde servers gewoon bereikbaar blijven.
De software wordt behoorlijk actief bijgehouden. RioRey heeft weliswaar geen vast schema voor updates, maar we begonnen deze review met versie 5.0.2 en tegen de tijd dat we aan het afronden waren, kwam versie 5.0.5 uit. Voor de testresultaten maakte de gebruikte versie weinig uit, dus we hebben de tests niet herhaald.
Wel is in de 5.0.5-update bescherming tegen Slowloris opgenomen. Dit hebben we uiteraard ook getest: de RX1810 vangt zelfs dergelijke langzame, vrijwel geen verkeer veroorzakende, DoS-aanvallen op.
Bediening
Als het pakket wordt gestart, wordt een overzicht van het 'sensor network' getoond. Hier is van alle RioRey-appliances te zien wat hun status is. Het is even zoeken waar bepaalde settings en informatie te vinden zijn, maar het is geen enorm doolhof van instellingen, dus met wat rondklikken is dat zo ontdekt. Er zijn twee niveau's: het systeemniveau en het interfaceniveau.
Op systeemniveau kan de algemene status van de machine opgevraagd worden, zoals de status van de diverse componenten en de belasting van de cpu en het geheugen. Verder kan je op dit niveau accounts beheren, alarm-notificaties instellen en diverse logbestanden bekijken. Daarnaast is het op dit niveau ook mogelijk om de licentie te verversen en de updates uit te voeren.
Op het interfaceniveau toont de software een overzicht van de netwerkbelasting van de betreffende lan- of wan-interface. In de normale versie van de RioRey-appliances wordt alleen inkomend verkeer gefilterd en de software geeft een redelijk gedetailleerd overzicht van het inkomende verkeer met een onderverdeling naar protocol (ip, tcp, udp, icmp), en per protocol het percentage malafide packets en bytes en de hoeveelheden ongeldige, gefilterde en gewhiteliste packets en bytes.
Per interface kan je ook het gedrag van de filters instellen. Hoewel we eerder aangaven dat de RX1810 geen firewall is, kent het wel een aantal instellingen die het werk van een firewall wat lichter maken. Zo is er bijvoorbeeld een instelling om icmp-, udp- non-ip- en ongeldige packets te blokkeren en ook het verkeer voor lokale netwerken kan worden tegengehouden. Daarnaast kent de software drie standen voor een interface: met 'filter' is de DDoS-bescherming actief en met 'monitor' wordt het verkeer wel geanalyseerd maar niet gefilterd. In de 'bypass'-stand fungeert de RioRey wederom als een veredeld koppelstukje.
Verder kan een lijst ip's gewhitelist of juist geblacklist worden. Hoewel de software hier een mask bij opslaat, moet hier elk ip afzonderlijk worden ingevoerd. Dat maakt het een beetje bewerkelijk om de boel te configureren als er veel ip's in een van beide lijsten moeten komen.
Ook noemenswaardig zijn de 'Service Definitions'. Hiermee kan voor ip's in het eigen netwerk worden opgegeven welk verkeer daarbij hoort. Voor een webserver kan bijvoorbeeld worden ingesteld dat er van buitenaf alleen tcp-verkeer voor de poorten 80 en 443 mag worden doorgelaten. Ander verkeer wordt geblokkeerd, wat volgens RioRey zorgt voor een geringere belasting van een (complexere) firewall verderop in het netwerk.
Rapportage
Naast alle instellingen biedt de rView-software een overzicht van de status van de diverse filters. Met grafiekjes wordt getoond hoeveel verkeer er binnenkomt en hoeveel daarvan wordt doorgelaten. Met zes 'confidence'-niveau's wordt er per filter aangegeven in hoeverre het verkeer op een DDoS-aanval lijkt. De appliance begint bij niveau 3 met filteren.
De niveau's worden hoger naarmate er bij achtereenvolgende analyses evenveel of steeds meer verdacht verkeer wordt gedetecteerd. Daarnaast wordt met kleurtjes aangegeven hoe groot het aandeel van het verkeer is dat met de aanval gemoeid is: minder dan 5 procent suspect verkeer wordt groen gekleurd, op 5 tot 10 procent wordt een geel label geplakt, een percentage tussen 10 tot 50 krijgt een oranje kleurtje en als meer dan de helft van de traffic verdacht is, kleurt het statistiekje rood.
/i/1268400082.png?f=thumb)
/i/1268400084.png?f=thumb)
Als een filter een van de twee hoogste niveaus bereikt, dan gaat het betreffende apparaat in het 'network sensors'-overzicht op oranje dan wel op rood. Bovendien wordt er dan een ledje aangezet en worden er waarschuwingsmails en snmp-traps verzonden.
Om na te gaan hoe zwaar de lijn belast wordt en hoeveel daarvan aanvallend verkeer is kan de rView-software diverse grafiekjes produceren. Hier wordt met een lichte vertraging het laatste verkeersoverzicht getoond; zowel de totale hoeveelheid verkeer als de hoeveelheid na filtering worden weergegeven.
/i/1268400081.png?f=thumb)
/i/1268400083.png?f=thumb)
Het is verder mogelijk om een overzicht van de doelwitten (RioRey noemt ze 'victims', al is het uiteraard de bedoeling dat het apparaat ingrijpt voordat er slachtoffers gemaakt worden) en aanvallers op te vragen. Tijdens een grote DDoS-aanval is met name het laatste lijstje wat overbodig door het grote aantal. Tijdens normaal gebruik is het echter een nuttig overzicht om te zien of er per ongeluk toch legitiem verkeer wordt geblokkeerd. Verder is hier te zien dat van sommige aanvallers slechts een enkel pakketje wordt tegengehouden, zonder dat het ip wordt geblokkeerd. Daarnaast kunnen vanuit deze lijst ip-adressen in de white- en blacklists worden opgenomen.
Testopstelling
Het blijkt in de praktijk erg lastig om een goede DDoS in een beperkte testomgeving uit te voeren. Zo slaagden we erin om de mac-adrestabellen van onze kantoorswitches geheel te vullen, zodat tijdens een van de eerste simulaties het complete kantoornetwerk werd platgelegd. Ook het genereren van divers legitiem verkeer is niet triviaal. We hadden helaas geen budget om dure testhardware van bedrijven als Spirent of Ixia te gebruiken, dus moesten we het doen met packetgeneratorsoftware die op een normale pc draait.
Onze testomgeving werd opgezet naar het voorbeeld van de situatie in ons serverrack. Daartoe namen we twee HP Procurve 2520G-8-switches voor het binnenkomende verkeer. Beide werden aan een interne netwerkswitch gekoppeld, waarbij een van de twee met prioriteiten in de spanning-tree belangrijker werd gemaakt. Deze switch werd beschermd met de RioRey RX1810.
Achter de interne switch werd een oude SuperMicro-server met twee Opteron 275-dualcores en 2GB ram opgesteld. Deze server is door zijn tamelijk gebrekkige capaciteit uitstekend geschikt om de effecten van een DDoS waar te nemen. Daarnaast gebruikten we twee afgedankte Dell 1950's met elk twee Intel Xeon 5150's, 4GB ram en Broadcom NetExtreme II 5708 netwerkchips om het binnenkomende verkeer te genereren; eentje voor het legitieme verkeer en een om de DDoS-aanval uit te voeren.
De systemen werden alle drie voorzien van recente Debian-installatie met een 2.6.32-kernel. De server draait lighttpd, versie 1.4.26, waarmee wat statische bestanden konden worden uitgeserveerd.
Legitiem verkeer
Het 'goede' verkeer werd gegenereerd door curl-loader, waarmee duizend unieke ip-adressen werden aangemaakt. Vanaf deze adressen werden ongeveer 1250 requests per seconde verstuurd, wat rond de 8000 packets per seconde oftewel 6Mbps aan inkomend verkeer opleverde. We lieten dit programma vervolgens diverse files downloaden, in grootte variërend van 100 bytes tot 100KB, waarbij de kleinere bestanden vaker werden opgevraagd om zo verzoeken om plaatjes, javascript- en css-bestanden, enzovoorts te simuleren. De server beantwoordde deze verzoeken met ongeveer 16.000pps, waarbij er ongeveer 190Mbit aan bandbreedte werd verstookt.
De requests van curl-loader werden gemiddeld met een vertraging van rond de 1ms beantwoord; het pakket kan helaas niet nauwkeuriger meten. Omdat de delay tijdens een DDoS-aanval fors oploopt, zijn de verschillen overigens duidelijk genoeg.
Er zijn uiteraard verschillen met de echte setup van Tweakers.net. Zo worden er in de praktijk veel meer uiteenlopende requests gedaan en ook de responstijden lopen doorgaans verder uiteen dan in deze test. We kwamen er tijdens een tcp-aanval dan ook achter dat onze setup de RioRey ten onrechte in de war kon brengen: er werd tenslotte door 'slechts' duizend adressen elke seconde een request gedaan. Bij andere aanvallen bleek dat geen probleem te zijn, dus we hebben maar valsgespeeld door de 'goede' ip-adressen in de whitelist te plaatsen.
Etterbak
De DDoS-machine werd voorzien van twee pakketten om willekeurig netwerkverkeer te genereren. Ten eerste gebruikten we de random packet generator hping3 voor het produceren van flinke hoeveelheden eenvoudig, willekeurig aanvalsverkeer. Hping is een 'fire and forget'-tool, waarmee geen echte tcp-verbindingen opgezet worden. Deze tool kan echter wel ruim 300.000 packets per seconde produceren en hoewel de naam het niet doet vermoeden, kan er naast icmp- ook udp- en tcp-verkeer worden gegenereerd. Met twee hping3-processen op onze DDoS-doos stuurden we ongeveer 350.000 packets per seconde naar onze webserver.
Om volledige tcp-connecties op te bouwen, waarbij ook nog wat met het retour-verkeer gedaan kan worden, gebruikten we bonesi. Dat is een afkorting voor 'BotNet Simulator'. Deze tool opent echte verbindingen vanaf willekeurige adressen en kan, nadat een verbinding is opgezet, ook http-requests uitvoeren.
Ten aanval!
Het doel van onze tests is uiteraard dat het aantal requests per seconde van de 'goede' client niet of nauwelijks verandert als er een aanval wordt uitgevoerd. We vergelijken daarom de statistieken van curl-loader in vredestijd met die tijdens onze DDoS-simulaties.
Om de prestaties van de RX1810 in context te plaatsen, hebben we dezelfde aanvallen ook uitgevoerd op dezelfde server met alleen een iptables-firewall. Verder hebben we de netwerkinstellingen geprobeerd te tweaken, onder andere met Floodmon. Deze tool hielp echter weinig en de bijbehorende resultaten hebben we dan ook weggelaten.
We hebben de volgende aanvallen uitgevoerd met de bijbehorende bereikbaarheid van de server:
| Aanval | Geen bescherming | Linux firewall | RioRey RX1810 |
| tcp-syn-flood, poort 80 |
0,6% |
4,6% |
90,6% |
| udp-flood, poort 80 |
9,5% |
10,9% |
100% |
| icmp-flood |
8,8% |
10,1% |
100% |
| icmp-flood, 1500 bytes |
4,7% |
33,4% |
100% |
| tcp-dataflood, poort 80, 1500 bytes |
15,2% |
17,0% |
76,9% |
| tcp-connecties, prt 80 |
4,9% |
5,3% |
100% |
| dns-reply-flood |
0% |
90% |
0%1 |
- Bij deze bescherming werd al het udp-verkeer op poort 53 geblokkeerd, dns-servers whitelisten werkt wel.
In bovenstaande tabel worden de bereikbaarheidspercentages gegeven die werden gemeten nadat de RioRey kon reageren. De eerste 90 seconden kan onze testserver dus onbereikbaar zijn geweest.
Tcp-syn-flood op poort 80
Het doel van een syn-flood is om zoveel mogelijk connecties aan te vragen. Normale connectie-aanvragen worden dan bij gebrek aan resources niet meer geaccepteerd.
De syn-flood zorgde bij de onbeschermde server - er werden wel syn-cookies gebruikt - voor een vrijwel onbereikbare site; slechts een enkel request kwam er nog door. Het inschakelen van iptables werkte iets beter, maar de server bleef slecht tot niet bruikbaar. De RioRey hielp enorm bij deze aanval, de bereikbaarheid daalde slechts tot iets meer dan 90 procent.
Bij deze aanval en sommige andere aanvallen zien we overigens dat de legitieme client zich na de DDoS-aanval niet volledig weet te herstellen. Voor zover we dat hebben kunnen nagaan, wordt dit met name veroorzaakt door het niet goed afsluiten van de opgezette verbindingen. Zodra de toegevoegde ip-aliassen van de client werden verwijderd en de curl-loadersoftware opnieuw werd gestart, kwamen de resultaten wel weer rond de 1250 requests per seconde uit.
Udp-flood op poort 80
Bij de udp-flood worden heel veel loze packets geproduceerd. Bij deze test gaat het dus voornamelijk om de verwerkingscapaciteit van de server.
Hoewel de onbeschermde server hier beter tegen bestand bleek dan tegen de syn-flood, is het nog steeds niet best met de bereikbaarheid gesteld. Ook een iptables-regel om al het udp-verkeer op poort 80 te droppen, veranderde opmerkelijk genoeg weinig aan de situatie. Het verschil tussen 'negeer udp-verkeer op poort 80' en 'gooi udp-verkeer op poort 80 direct weg' is blijkbaar niet zo groot.
De RioRey was echter uitstekend tegen deze aanval opgewassen. Die blokkeerde het foute verkeer zo effectief dat de client zelfs in de eerste minuten niets van de udp-flood merkte.
Icmp-flood
De icmp-flood heeft hetzelfde doel als de udp-flood. Ook hier gaat het om de verwerkingscapaciteit van de diverse netwerkelementen. Het effect op de server was dan ook vrijwel hetzelfde als met udp, en ook hier blokkeerde de RX1810 - nadat de aanval was ontdekt - al het aanvallende verkeer. Het is overigens mogelijk om al het icmp-verkeer te blokkeren en we twijfelen er niet aan dat we dan net zo'n plaatje als bij de udp-flood hadden gezien.
Icmp-flood met 1500B-packets
Deze variant op de icmp-flood werkt met aanzienlijk grotere packets, waardoor de maximale capaciteit van de netwerkverbinding bereikt kan worden. De interfacebelasting steeg volgens de RX1810 bij deze test dan ook naar 95 procent, de hoogste waarde die we in alle tests hebben waargenomen.
Bij deze aanval was de onbeschermde server zo mogelijk nog slechter bereikbaar dan bij de icmp-stroom van kleine packets. De met iptables beschermde server, die al het icmp-verkeer weggooide, liet dit keer wel betere resultaten zien. De bereikbaarheid stabiliseerde na ongeveer tien minuten op een derde van alle requests. Voor de RioRey was de grootte van de icmp-packets blijkbaar een teken dat er iets aan de hand was: deze aanval werd vanaf het eerste pakketje volledig geblokkeerd.
Tcp-flood met 1500B-packets op poort 80
Bij deze aanval wordt er verkeer gegenereerd dat een beetje lijkt op normaal webverkeer, maar dan zonder eerst een connectie op te zetten. In theorie zou dat dus heel goed met een iptables-firewall met connection tracking bestreden kunnen worden, omdat het verkeer niet gerelateerd is aan bekende connecties. De RioRey zou hier juist moeite moeten hebben met het onderscheiden van de aanvalpackets van de gewone packets.
In vergelijking met de andere aanvallen deed de onbeschermde server het hier vrij aardig, en zelfs beter dan bij de icmp-flood met grote packets. Ondanks de connection tracking voegde de iptables-firewall hier weinig toe. Zoals verwacht had de RioRey hier inderdaad wat moeite mee. Door de continue stroom requests van een relatief klein aantal legitieme clients, werden ook requests geblokkeerd die niets met de aanval te maken hadden.
We gaan er echter vanuit dat deze aanval in de praktijk een stuk voordeliger uitvalt: de regelmaat in de requests van onze legitieme client ontbreekt bij de requests van onze echte bezoekers. In deze test werd echter, zelfs na het whitelisten van de goede clients, het aantal legitieme requests per seconde zo'n 20 procent lager.
Tcp-connectieflood op poort 80
Ook deze aanval heeft als doel om zoveel connecties te openen dat er geen normale requests meer tussendoor komen. In dit geval worden de connecties echter volledig geopend en zijn ze dus nog lastiger te onderscheiden van die van legitieme clients.
De onbeschermde server kon hier maar weinig mee. Het aantal requests per seconde dat werd doorgelaten, fluctueerde vrij stevig, maar bleef doorgaans onder de 20 procent steken en af en toe werd er helemaal niks doorgelaten. De iptables-bescherming voegde hier weinig aan toe, het verkeer werd wel wat constanter maar de bereikbaarheid verbeterde amper.
Bij deze aanval zijn daadwerkelijk bestaande ip-adressen nodig. De hoeveelheid verschillende ip-adressen is hier dan ook iets kleiner dan bij een volledig willekeurig gegenereerde aanval. Dit zagen we duidelijk terug in de resultaten: de aanvallers werden vrij vlot gedetecteerd en voor langere tijd geblokkeerd.
Dns-reply-flood
Bij deze aanval werd random udp-verkeer met source-poort 53 verstuurd. Deze packets zijn lastig te onderscheiden van verkeer dat van dns-servers afkomstig is, waardoor in theorie het gebruiken van dns-servers onmogelijk wordt gemaakt.
Bij de onbeschermde server bleek het inderdaad onmogelijk om nog dns-lookups uit te voeren. Bij de met iptables en connection tracking beschermde server werd het verkeer nog wel gehinderd, maar kwamen de dns-reply's wel bijna allemaal goed aan.
De RioRey gebruikt geen connection tracking en kan bij deze aanval dan ook niet goed onderscheid maken tussen de aanval en de legitieme reply's. Door het instellen van de ip-adressen van een aantal bekende dns-servers als geldige bron van verkeer kan daar echter prima omheen gewerkt worden.
Conclusie
De appliance van RioRey doet zijn werk. De meeste aanvallen die we uitvoerden werden volledig tegengehouden, en bij andere aanvallen bleef er in ieder geval een veel groter deel van het legitieme verkeer werken dan zonder de bescherming. De aanvallen waar Tweakers.net in augustus en september 2009 last van had, zouden met de RX1810 volledig zijn afgeslagen.
Ook prettig is dat RioRey 24-uurs support op hun producten levert, waardoor je er tijdens een aanval niet alleen voor staat. Als een DDoS onverhoopt toch wordt doorgelaten, kan er dus samen met de experts van RioRey een ad-hoc oplossing in elkaar gezet worden. In de praktijk zal dat vermoedelijk betekenen dat RioRey het meeste werk doet, terwijl wij toekijken of het ze lukt
Onze zelfgebouwde firewall haalde tegen de meeste aanvallen maar weinig uit. Bovendien is iptables behoorlijk diep in de kernel weggestopt en zou nul-routering voor ip's en ip-ranges efficiënter werken - maar dat vereist uitgebreide scripting en een hoop handwerk. Er zijn verder vast nog wel betere netwerkinstellingen te vinden, maar we verwachten niet dat er nog veel winst te boeken is.
De RioRey heeft inmiddels een paar dagen in ons rack gehangen, en het lijkt erop dat legitiem verkeer niet ten onrechte wordt geblokkeerd. Dat betekent niet dat er op de lange termijn of tijdens een DDoS-aanval nooit een geldige request wordt weggegooid, maar het voorlopig uitblijven van false positives is op zijn minst hoopgevend.
Er zijn uiteraard ook nog wel wat verbeterpuntjes te noemen. De afwerking van het apparaat is goed, maar niet top; met name de klep aan de voorkant kan wel wat aandacht gebruiken. Een slot erop zou beslist een vooruitgang zijn: het is tenslotte wel de uplink naar je netwerk die erdoor beschermd moet worden.
Ook de bruikbaarheid van de rView-software verdient nog wel enige aandacht; zo zijn de grafiekjes voor het verkeer wat onhandig in het gebruik. Ook is het vervelend dat de status met een vertraging wordt getoond, al zal dat wel inherent zijn aan de werking van de software. Erger is dat er nergens ip-ranges kunnen worden gedefinieerd; elk goed- of afgekeurd adres moet afzonderlijk worden ingevoerd.
Toch overheerst de tevredenheid. We hopen natuurlijk dat we onze nieuwe RioRey voor niks hebben opgehangen, maar als de nood aan de man komt, zijn we in elk geval degelijk voorbereid.
Onze dank gaat uit naar Quanza Engineering, zowel voor het testexemplaar als voor de antwoorden op onze vele vragen over de RioRey.
/i/1321376437.png?f=fpa)
/i/1272464185.png?f=fpa)
:strip_exif()/u/133150/pixar_bird_static.gif?f=community){kind=small}
/u/1830/acm.png?f=community){kind=small}
/u/8/oog3.png?f=community){kind=small}
:strip_exif()/u/243981/luckyy_oranje.gif?f=community){kind=small}
:strip_icc():strip_exif()/u/303210/favritegotevj9.jpg?f=community){kind=small}
:strip_icc():strip_exif()/u/257176/troll.jpg?f=community){kind=small}
Vond ik wel grappig eerlijk gezegd. Dat hadden jullie hier op tweakers veel beter geregeld.
/u/25680/crop5db009d1c28fb_cropped.png?f=community){kind=small}
/u/223279/Congressman.png?f=community){kind=small}
/u/201651/beastie_300.png?f=community){kind=small}
/u/141385/r4.PNG?f=community){kind=small}
:strip_icc():strip_exif()/u/226826/aardblij-60.jpg?f=community){kind=small}
/u/34216/avatar-60x60.png?f=community){kind=avatar}
/u/34/crop5ffee40f13ac4_cropped.png?f=community){kind=small}
