RioRey RX1810: een firewall onder vuur

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:

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.