Hoofdcategorieën
Device Settings

RioRey RX1810: een firewall onder vuur

Door Arjen van der Meijden, woensdag 28 april 2010 09:00, views: 214.671

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.

T'rug naar huus


Inhoudsopgave

Advertentie

Reacties

«  1  2  3  4  »

Hmm, voor de Juniper staan de cijfers wel duidelijk in de datasheet.
Zie bijvoorbeeld de pdf datasheet van de SRX Branch Series.
De onderdelen van UTM / IPS zijn betaald, omdat je daar ook een abonnement voor signatures bij nodig hebt. Maar de DDOS bescherming zit er in standaard in, dat heet Screen.
Wat je vaak bij softwarematige oplossingen ziet is dat het beheer systeem niet meer werkt als het systeem overbelast is met verkeer.

[Reactie gewijzigd door xmenno op woensdag 28 april 2010 09:14]


We hebben een SRX210 bekeken om te zien hoe een en ander werkte, maar de bediening ervan was nou niet bepaald triviaal en ook was de DDoS-bescherming duidelijk niet het hoofddoel. Zelf heb ik hem niet heel uitgebreid bekeken, maar mijn collega heeft er wel wat uren in gestoken, dus wellicht dat ie straks nog een en ander wat uitgebreider kan toelichten. :)

Handig artikel voor de DDOS-ers, nu weten ze meten waar ze rekening mee moeten houden.

Ach als je vertrouwen hebt in je beveiliging kun je dit best doen. Security by obscurity werkt ook niet, en zeker niet in dit soort gevallen waarvoor alle informatie (over hoe je een goede aanval doet) gewoon op internet staat. Aan de techniek van een DDoS is niets geheim, je hebt alleen heel veel clients nodig.

Dat laatste hangt ook nog af van de aanval die je uitvoert. Volgens mij was de DDoS aanval die op Apache uitgevoerd kan worden zelfs mogelijk met enkele clients. Anyway, heel interessant artikel, jammer dat er nergens ook maar indicaties van prijzen te vinden zijn: dan ga ik er maar vanuit dat het voorlopig niet interessant is (als het kalf verdronken is dempt met de put...).

prijsindicaties staan er wel, maar niet in euro's.

Die Slowloris aanval waar jij het over hebt was dan ook geen DDoS maar een DoS. Om DDoS te zijn heb je per definitie een back blackhat clients nodig :)

DDOS-ers halen hun inspiratie over het algemeen niet van tweakers.net ;)

leuk en verhelderend artikel. Geinig om zo een kijkje 'achter de schermen' te hebben. is ook weer eens wat anders! ;)

Inderdaad een goed artikel. Ik vroeg me altijd al af of je echt een DDOS aanval kan testen maar dit komt aardig in de buurt.

Een echte DDoS aanval testen is heel erg lastig omdat je dan snel zelf al meerdere clients nodig hebt. Er zijn geen netwerkkaarten die hun eigen gbit kunnen vullen met data-loze packetjes bijvoorbeeld. Op een gbit passen 1.4 miljoen packetjes, maar door de software en hardware limiteert een 'gewone' dell server met broadcom of intel nics zich al snel tot ~350-550 duizend packets per seconde. Met name door interupt locking e.d.

Er zijn wel apparaten waarmee je dit soort testen kan doen - mijn werkgever gebruikt ze...

Volgens mij maakt Mu Dynamics ze - de Mu-8000 (http://www.mudynamics.com...reg/datasheet_mu-8000.pdf en ook http://www.mudynamics.com/products/test-modules/DoS.html

[Reactie gewijzigd door Tukkertje-RaH op woensdag 28 april 2010 13:12]


Ja, en die beginnen normaal gesproken bij bedragen waarmee we ons volledige serverpark kunnen vervangen. Ze zijn ook te huur, en dan beginnen ze ook bij duizenden euro's per dag.

Super artikel! Ik moet eerlijk toegeven, in de tijd dat ik Tweakers.net bezoek vind ik dit artikel en de andere artikels over het Tweakers.net serverpark (ik heb het hier over de reeks chronologische artikelen over de voortgang en het ontstaan van tweakers.net) de leukste artikels die ik tot nu toe gelezen heb!

Serieus, echt super interessant om te lezen!

Zelf zou ik dan ook graag zien dat er vaker dit soort artikelen komen, en misschien zelfs een sectie geweid aan servers, hun onderhoud, installatie, software, ontwikkelingen en producten. (Al dit soort informatie staat denk ik al wel op tweakers, maar omdat het tussen al het overige staat is het moeilijk om hier makkelijk naar te zoeken als je al niet zelf wat kennis hebt van wat je zoekt).

Zelf bijvoorbeeld heb ik nooit iets gestudeerd over servers of ICT maar interesseer me er nu wel erg in sinds het lezen van jullie artikels!

Wederom, aparte tweakers sectie voor 'everything server related' zou echt top zijn!

- Frank

Het nadeel aan dat soort reviews (en ook gedeeltelijk deze) is dat onze aanpak waarschijnlijk lang niet overeenkomt met hoe andere mensen het aanpakken, en dan zijn wij ineens onprefessioneel bezig (omdat we bv geen vmware gebruiken maar kvm), of we zijn goedkoop (omdat we een storage machine met opensolaris zelf opzetten ipv dat we hem voor 3x meer kopen), of zijn we naief omdat we php gebruiken en geen java/asp/perl/asm/python/c etc.

Er zijn heel veel manieren om dingen aan te pakken, en ik weet ook wel dat onze manier lang niet altijd de correcte manier is, maar het is wel de manier waarop wij dingen doen. Maar om een goed artikel te maken zul je onze manier moeten afzetten tegen andere manieren, en daar ben je dan heel erg veel tijd aan kwijt omdat je die andere manier volledig moet leren. En dan loop je nog steeds het grote risico dat je niet genoeg geleerd hebt en de review domweg onvolledig is. Een artikel over MySQL onder linux/solaris vs MSSQL onder windows zou gewoon niet eerlijk zijn; mijn linux kennis is veel uitgebreider dan mijn MSSQL kennis, en dat kan zomaar de doorslag geven in zo'n vergelijking, nog afgezien van de bias die wij tegen windows hebben :P

Ook is het vaak niet echt mogelijk om vergelijkingsmateriaal te regelen. Om voor deze review echt goede vergelijkingen en testen te maken zou je bv een packetgenerator moeten hebben/lenen/huren, en die beginnen over het algemeen bij een prijstag van meer dan 6 cijfers. Dus er zijn er niet al te veel van, en lenen wordt dan lastig, huren te duur, en kopen out of the question.

Ook is het vaak niet echt mogelijk om vergelijkingsmateriaal te regelen. Om voor deze review echt goede vergelijkingen en testen te maken zou je bv een packetgenerator moeten hebben/lenen/huren, en die beginnen over het algemeen bij een prijstag van meer dan 6 cijfers. Dus er zijn er niet al te veel van, en lenen wordt dan lastig, huren te duur, en kopen out of the question.
* CyBeR heeft wel 's met de packet generators van ams-ix gespeeld. 10gig/sec aan ipv6 neighbour solicitations door je switch heen proppen (model foundry rack-size) om te kijken of 'ie er mee kapt is toch best geinig :P

Het verbaast me enigszins dat de leverancier van het apparaat zelf geen service biedt om de werking te testen door een gesimuleerde attack (tegen een lager tarief uiteraard.) Zij hebben er immers ook baat bij dat een klant wéét dat het apparaat werkt in plaats van het enkel hoopt, zorgt voor (nog) betere reclame.En daarnaast neem ik aan dat ze voor hun eigen testen ook dit soort apparatuur nodig hebben (?)

Mooie review overigens!

[Reactie gewijzigd door Brunniepoo op woensdag 28 april 2010 21:26]


Ik vraag me eigenlijk wel af op basis van wat deze firma is gekozen. In het artikel word vermeld dat jullie zijn afgegaan op claims van de verkoper en op enkele ervaringen van leveranciers. Wat is dan echter de motivatie, wat maakt deze beter, dan andere oplossingen in de markt?

Artikel is wel zeer compleet en informatief daar niet van, maar dat wat ik hierboven beschrijf mis ik een beetje. :)

Dan heb je die zin niet helemaal goed begrepen :) Er zijn bedrijven die DDoS-apparatuur verkopen, maar het is allemaal niet zo makkelijk daar informatie over te vinden en dan is het nog maar de vraag wie het in nederland kan leveren. Deze oplossing werd ons aangeboden door een leverancier waar we al bekend mee waren en goede ervaringen mee hadden, dus dan krijgt ie daardoor automatisch een streepje voor op de rest natuurlijk.

We hebben met deze, en een paar andere oplossingen gespeeld (juniper, iptables firewall). Deze oplossing is dermate eenvoudig qua beheer en dat is wel een van de hoofdredenen geweest.

Voornamelijk omdat je, als je eenmaal onder een aanval ligt, je geen tijd hebt om te realizeren 'owh shit, de config is net iets anders dan ik had verwacht en ik moet het nu aanpassen'.

"Een slot erop zou beslist een vooruitgang zijn: het is tenslotte wel de uplink naar je netwerk die erdoor beschermd moet worden."

Waar staat deze dan? In de hal van CS?
Mag aannemen dat er maar een hele selecte groep mensen toegang hiertoe hebben.

Uiteraard. Maar de magneetjes zijn gewoon nogal zwak en houden het klepje niet goed dicht als de kabels er een beetje scheef uitkomen.
In een afgesloten serverruimte met een deur-met-slot in je rack is inderdaad wat overbodig zo'n klep weer op slot te doen. Maar een betere sluiting had dus sowieso wel gemogen en dan is een slot erop wellicht net weer dat beetje extra toevoeging (niet dat dat soort sloten zo lastig open te breken zullen zijn). Weet je iig beter dat ie gewoon dicht blijft nadat je de boel heb aangesloten :)

[edit]
Moest inderdaad 'niet' bij, Baseboy :)

[Reactie gewijzigd door ACM op woensdag 28 april 2010 14:15]


Uiteraard. Maar de magneetjes zijn gewoon nogal zwak en houden het klepje goed dicht als de kabels er een beetje scheef uitkomen.

Snap die niet helemaal. Zal wel moeten zijn houden het klepje niet goed dicht denk ik zo.

Artikel is wel interessant!

[Reactie gewijzigd door Baseboy op woensdag 28 april 2010 14:03]


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.
Even als leek, maar kunnen ze niet de IP-adressen van de bekende DNS servers spoofen?

Uiteraard, maar dan kan je die blokkeren en zelf weer andere instellen... Het blijft altijd wel een 'wedstrijd' op zo'n manier. Gelukkig is dat niet het enige wat je kan doen, sowieso is er nog van alles mogelijk aan ad-hocoplossingen op de appliance en kan je er ook nog voor kiezen die hele beveiliging uit te zetten en terug te vallen op de connection-tracking van de gewone firewall erachter. :)

Uitermate interessant artikeltje, sowieso voor het eerst dat ik wat hoor over een relatief effectieve (hardwarematige) bescherming tegen DDoS-aanvallen. Nou is Netwerkverkeer ook niet echt mijn forté ;)

De grafiekjes geven in elk geval een goed beeld van in hoeverre de Riorey zijn werk doet.

er wordt in het artikel ten onrechte gezegd dat iptables onvoldoende opties bied bij het maken van een SYN-ACK aanval. Iptables heeft namelijk sinds jaar en dag een optie beschikbaar die hashlimit heet. Hiermee worden paketten geclassificeerd vanaf een specifiek ip adres, en is het dus mogelijk om een rps per host in te stellen.

Interessant zou misschien ook de combinatie van een interne firewall samen met de RioRey te testen, als het apparaat namelijk net in maintenance modus staat als er een aanval plaatsvind, ben je wel goed de cigaar.

Als ik je goed begrijp bedoel je dat je per 'aanvaller' in kan stellen dat ze maximaal X packets/connecties per ip mogen opzetten? Als je die X veilig in wilt stellen zit je op meerdere connecties per seconde toelating, anders kan een gebruiker niet normaal in een paar tabjes tegelijk een pagina openen.
Stel voor het gemak dat er 5 connecties per seconde mogen komen vanaf een willekeurige host met een burst van 20 (en laten we die burst dan gelijk weer negeren het gaat tenslotte om de stroom van syn/acks). Dit zijn getallen die ik zo even uit de losse pols roep, maar imho niet heel irreel zijn voor webservers. Dan worden er met 1000 aanvallers 5000 connectie-requests per seconde doorgelaten. Apache zit dan echt wel over zijn limieten hoor...

je kan daarom ook een aparte limiet invoeren voor half-open connecties.
Bij normale connecties zal de verbinding binnen enkele honderden milliseconden overgaan van SYN naar SYN - ACK dus connecties die blijven hangen op SYN kun je veilig af laten breken na 200ms. Je zit daarmee direct aan een limiet van 5 SYN/sec zonder bursts (bursts zijn niet direct iets om rekening mee te houden bij standaard SYN requests, client limiet voor windows is nog steeds 20 SYN connecties simultaan)

hiernaast kun je een maximum concurrent server wide instellen, waarbij je wel rekening houd met de limiet van je server.

Je krijgt dan dus een gelaagde structuur waarbij iptables als volgt controleert binnen de chain.
Client < Onder 5 SYN/sec < onder x SYN/s concurrent
De volgorde is hiervan instelbaar, beide situaties hebben een voordeel (tweede optie blokeert sneller single SYN/host attacks en optie 1 blokeert sneller multi SYN/host attacks)

Kan kloppen allemaal, maar bij onze tests, en bij de laatste aanvallen kregen we niet meer dan 1 packetje per ip per seconde binnen. Als je kan spoofen dan heb je de beschikking over 4 miljard ip's. Laten we zeggen dat je er de helft van gebruikt, en je stuurt met 500k pps packetjes eruit, dan moet deze oplossing, om effectief te zijn, die half open connecties minimaal 2000-4000 seconden bewaren, en daar is het geheugen er niet voor, en is er ook geen manier om je legitieme verkeer te onderscheiden.

Je legitime verkeer maakt op dat moment namelijk meer connecties per seconde per IP dan het aanvallende verkeer. Bij de laatste DDoS die wij hadden kwamen er in 10 seconden meer dan 2 miljoen verschillende IP addressen langs.

Dan zou je alleen kunnen limiteren op half open connecties op bv 500 ms (200ms is al erg kort, dan block je al het legitieme verkeer buiten nederland zo ongeveer). Maar die 500 ms zorgt nog steeds voor een hash table met ruim 100-500k entries. Wat je dan krijgt, zeker met veel iptables verwerking, is dat je server nog niet klaar is met het ene packetje verwerken voor de volgende binnenkomt. en je dus interupt locking krijgt.

de vraag is natuurlijk, omdat jullie dit niet getest hebben, kan de RioRey hier wel mee omgaan.... Uiteindelijk zal ook deze op dergelijke hoeveelheden vast moeten lopen, omdat er qua techniek niet veel meer opties te bedenken zijn dan hashes van packets/ip's/connecties

Hoe bedoel je dat we dat niet getest hebben? We hebben toch een SYN-flood van random ip's op de RioRey losgelaten? Of mis ik een tussenvorm tussen de SYN-flood en de volledige connecties (die we ook hebben gedaan).
Want volgens mij is het na een SYN versturen, SYN/ACK terugkrijgen en daarna een ACK versturen helemaal open. Dus dan zit er toch niet een variant tussen die we niet getest hebben? :)

ik bedoel dat jullie de 500k pps niet hebben gehaald. Vanuit de grafieken hebben jullie getest tot 1200 rps. Volgens mij kan iedere ipables oplossing zoeits aan.

Want tenzij ik het verkeerd zie in de tests, hebben jullie niet met de statistieken van de laatste aanval (2 miljoen verschillende ip's) getest.

Met andere woorden, ik bedoel dus geen andere variant, ik bedoel de quantiteit in dit geval. Mochten jullie dit wel getest hebben, dan heb ik vanzelfspreken niets gezegd.

Vergelijken met een IPTables firewalletje? Pak dan een Cisco ASA of een vergelijkbaar iets van Nortel of Avaya. Ik vind deze test toch niet zo heel veel zeggen ... Je gaat in een beetje datacenter (waar je zo een appliance toch voor koopt) toch niet met IPTables draaien? Neem dan op z'n minst Packetfilter van OpenBSD als je toch per see een appliance met een hobby doosje wilt vergelijken. Deze test is naar mijn mening appels met peren vergelijken.

En dan maakt de reviewer een beetje opmerkelijke opmerking:
Veel ervaring met dit soort oplossingen hebben we niet, maar voor zover we kunnen nagaan zijn ze lastig te beheren.
Je hebt weinig ervaring met oplossingen van Cisco / Juniper / Avaya / Nortel maar je weet wel dat ze lastig te beheren zijn? Lijkt me logisch als je er weinig ervaring mee hebt ;)

Sorry, maar het idee van deze review is erg leuk , maar de uitvoering vind ik minder.

edit: iets genuanceerder, ik heb koffie nodig.

[Reactie gewijzigd door silentsnake op woensdag 28 april 2010 10:21]


Die Cisco zal ook wel niet toevallig op kantoor liggen voor als er een keer een firewalltest is. Daarnaast is IPtables gewoon een goede firewall, een goed product hoeft niet per sé tienduizenden euro's te kosten. Het gaat er in deze test om dat de specifieke DDoS-bescherming wordt vergeleken met een generieke firewall en daar is de test denk ik in geslaagd.
Als Cisco/Juniper/whatever een keer een doos van hun beschikbaar wil stellen om te reviewen ben ik ervan overtuigd dat die review er ook wel komt, maar ik betwijfel of daar een ander beeld uit naar voren komt.

Dan hadden we er ook gelijk de nodige consultancy danwel community support bij moeten nemen. Want zelf hebben we, zoals je al met een knipoog quote, er weinig ervaring mee. En dan ben je weer appels met peren aan het vergelijken, omdat in het geval van de riorey-appliance het eigenlijk gewoon "plug and play" is.
En ja, dan is het gewoon veel werk en lastig te beheren als je de kennis mist. Dat was een deel van het punt :)

Iptables-kennis hebben we daarentegen wel in huis. Dus dat was een stuk eenvoudiger uitwerken dan weer op zoek naar wat dan een geschikte concurrerende firewall is (en daar nog een demo-model van zien te regelen met bijbehorende ondersteuning). Dit artikel was overigens zeer zeker niet bedoeld als uitputtend onderzoek naar de beste mogelijkheden om DDoS-aanvallen tegen te houden. Daar hebben we de kennis en tijd domweg niet voor.

Mocht jij of iemand anders zich bereid voelen met een dergelijke firewall langs te komen, dan denk ik dat we wel de tests daar ook op los willen laten en hier een (korte) follow-up op schrijven.

Net zoals andere mensen al boven mij aangeven.
Ik zou graag zien wat de review in vergelijking met Cisco/Juniper/Fortigate/Watchguard/Sonicwall/Avaya doet.

Als er iemand hier rondloopt die ervaring met dit soort producten heeft, en over een testunit beschikt, dan ben ik best bereid om de tests nogmaals uit te voeren met die Cisco / Juniper /etc ertussen.

We hebben een tijdje een juniper gehad, maar de configuratie daarvan is dermate ingewikkeld dat ik nu ineens goed snap waarom er zoveel 'merk'-certified engineers certificaten zijn ;)

En nee, helaas hebben wij die certificaten niet in huis, maar als iemand ze wel heeft en ons ermee wil helpen, dan is er vast wel wat te regelen :)
«  1  2  3  4  »

Op dit item kan niet meer gereageerd worden.

VNU Media logo Hosted by True

© 1998 - 2012 Tweakers.net B.V. - Alle rechten voorbehouden - Contact - Jouw privacy - Algemene Voorwaarden

Uitgever van:

Website van het jaar 2011