Ontwikkeling en gebruik van een testbed voor het DDoS-clearinghouse

DDoS-clearinghouse in het kort

Het DDoS-clearinghouse is een systeem waarmee organisaties continu en automatisch metingen van de DDoS-aanvallen die ze te verwerken krijgen, kunnen delen in de vorm van ‘DDoS-fingerprints’. Het clearinghouse verruimt zo het zicht van deze organisaties op het DDoS-aanvalslandschap en stelt hen in staat hun netwerken voor te bereiden op een bepaalde DDoS-aanval voordat deze hen daadwerkelijk treft. Hierdoor neemt de kans op systeemuitval af en de beschikbaarheid van diensten voor klanten en gebruikers toe. Het DDoS-clearinghouse is een extra beveiligingslaag die een aanvulling vormt op DDoS-mitigatiediensten zoals NaWas van NBIP. Hierover moeten organisaties beschikken om DDoS-verkeer af te handelen. Het DDoS-clearinghouse is een van de kerndiensten van een zogeheten ‘anti-DDoS-coalitie’, een groep die bestaat uit organisaties die DDoS-aanvallen gezamenlijk willen bestrijden. Een van die coalities is de nationale anti-DDos-coalitie. Dit is een samenwerkingsverband van 18 Nederlandse organisaties uit verschillende sectoren, zoals telecom, internetinfrastructuur, het bankwezen en de overheid. Leden van de coalitie zijn potentiële doelwitten van DDoS-aanvallen, of organisaties die zich bezighouden met DDoS-mitigatie. Ze wisselen kennis en expertise uit, bijvoorbeeld via het clearinghouse en door middel van grootschalige gezamenlijke DDoS-oefeningen. Door hun krachten te bundelen in een coalitie kunnen ze samen proactieve anti-DDoS-activiteiten organiseren. Het DDoS-clearinghouse bestaat uit drie kerncomponenten: de Dissector, DDoS-DB en Converters.

• De Dissector analyseert verzamelde captures van DDoS-verkeer en genereert een fingerprint die de belangrijkste kenmerken van de aanval samenvat, zoals protocoltypen, pakketlengtes en IP-bronadressen. Coalitieleden implementeren de Dissector in hun netwerken en verwerken hun eigen netwerkverkeer intern.

• DDoS-DB is een logisch gecentraliseerde interactieve database waarin DDoS-fingerprints worden opgeslagen en gedeeld die afkomstig zijn van Dissectors onder beheer van de leden van een anti-DDoS-coalitie. DDoS-DB is een gedeelde faciliteit van de coalitiepartners.

• Een Converter ontvangt fingerprints van DDoS-DB, waardoor leden die het doelwit worden van een aanval die in een fingerprint wordt beschreven, deze aanval kunnen afslaan. Een Converter zet DDoS-fingerprints om in mitigatieregels. Omdat fingerprints alleen de metagegevens van de aanvallen bevatten en niet het aanvalsverkeer zelf, lopen coalitiepartners niet het risico dat zij onbedoeld privacy- of commercieel gevoelige informatie over het netwerkverkeer met anderen delen.

Waarom een testbed voor het DDoS-clearinghouse?

We hebben een testbed nodig om te leren hoe het DDoS-clearinghouse functioneert in een realistische omgeving, zonder dat de leden van een anti-DDoS-coalitie een Dissector aan hun netwerken hoeven toe te voegen of fingerprints moeten uitwisselen met echte IP-adressen erin. Dit is van belang omdat we hebben ondervonden dat dit soort processen dikwijls behoorlijk wat tijd in beslag nemen, vaak wel maanden. Zo moeten organisaties hun productienetwerken aanpassen om de Dissector toe te kunnen voegen. Ook moeten ze een overeenkomst over gegevensuitwisseling ondertekenen omdat de IP-adressen in DDoS-fingerprints persoonlijk identificeerbare informatie (PII) zijn. Hoewel dergelijke processen niet te vermijden zijn bij een productieversie van het clearinghouse (TRL8-9), kunnen ze de ontwikkeling en evaluatie van het systeem flink vertragen. Met ons testbed wilden we TRL6 (‘technologie werkt onder relevante omstandigheden’) bereiken. Het gaat vooraf aan een pilot met de nationale anti-DDoS-coalitie, die op TRL7 (‘prototype kan getest worden onder operationele omstandigheden’) zal worden uitgevoerd. In het kader van de pilot installeren de leden van de coalitie de Dissector in hun netwerken en ondertekenen overeenkomsten over gegevensuitwisseling voor de uitwisseling van fingerprints via de DDoS-DB. Het is onze bedoeling om de pilot te gebruiken als input voor een productiesysteem (TRL8-9).

Technische vereisten

We ontwierpen het testbed voor het clearinghouse op basis van vier belangrijke vereisten:

• Het testbed moet ons in staat stellen het DDoS-clearinghouse te testen zonder de vaak tijdrovende implementatie- en juridische processen die nodig zijn voor een systeem op productieniveau. Tegelijkertijd moest het testbed voldoen aan de juridische basisvereisten die in de volgende paragraaf worden beschreven.

• Het moet in technisch opzicht sterk lijken op de operationele omgeving waarin het clearinghouse na ontwikkeling zal worden ingezet. Hiermee bedoelen we dat het opereert in een over het internet verspreide omgeving, en niet in een geïsoleerd gevirtualiseerd netwerk.

• Het moet ons in staat stellen elk onderdeel van het clearinghouse en, heel belangrijk, het systeem als geheel te testen en te demonstreren: van het capturen van DDoS-verkeer bij een lid van de anti-DDoS-coalitie tot het gebruik van mitigatieregels door andere leden, de potentiële slachtoffers.

• Het testbed moet DDoS-aanvallen kunnen emuleren, waarbij gedistribueerde externe bronnen sporen van DDoS-verkeer naar een deelnemer aan het testbed sturen die fungeert als doelwit. Dit betekent niet dat het een echte DDoS-aanval moet sturen; een klein monster van het testverkeer is al genoeg om het clearinghouse afdoende te testen. Het testbed zou dus moeten voorkomen dat leden meer verkeer versturen dan de Dissector nodig heeft.

Juridische vereisten

Voordat we met de ontwikkeling van het testbed begonnen, raadpleegden we eerst onze juridische afdeling om de juridische vereisten te bespreken. Het testbed genereert immers DDoS-testverkeer om het clearinghouse te activeren en dat kan aansprakelijkheidsrisico's met zich meebrengen. Ook wilden we weten wat onze opties waren qua testbedovereenkomsten tussen coalitieleden en hoe we deze overeenkomsten voor testdoeleinden tot een minimum konden beperken. Onze juridische experts vertelden ons dat we het testbed onder drie soorten overeenkomsten kunnen laten functioneren, variërend van strikt tot informeel:

1. Een volwaardige overeenkomst tussen de testbedpartners met alle details in steen gebeiteld, net zoals voor een pilot- of productiesysteem.

2. Een verklaring van afstand/vrijwaring om de bron van het verkeer of de uitvoerende partij te ontheffen van enige aansprakelijkheid, bijvoorbeeld als gevolg van het ontvangen van het DDoS-testverkeer op hun systemen.

3. Een overeenkomst per e-mail die alleen betrekking heeft op de voornaamste operationele specificaties van het testbed.

De keuze hing af van de leden die deelnamen aan het testbed en de mate waarin zij elkaar vertrouwden. In ons geval werken SIDN Labs en SURF samen aan het testbed in de vorm van een virtuele anti-DDoS-coalitie. We kozen voor de derde en meest informele overeenkomst, omdat SIDN Labs en SURF in het verleden al vaak hebben samengewerkt en het wederzijdse vertrouwen groot is. Bovendien beschikken beide partijen over afzonderlijke netwerken en middelen die zijn gereserveerd voor onderzoek, buiten de operationele infrastructuren van de respectieve moederorganisaties. Hierdoor is er minder kans dat zich per ongeluk iets voordoet wat ernstige schadelijke gevolgen heeft. Ten slotte zijn beide partijen Nederlands, wat betekent dat ze in hetzelfde rechtsgebied opereren en beide bekend zijn met de wetten die van toepassing zouden zijn als er onverhoopt een juridische kwestie zou ontstaan. Een andere juridische vereiste is dat leden van een virtuele coalitie gesimuleerd DDoS-verkeer alleen naar zichzelf kunnen sturen, zodat aansprakelijkheid tegenover anderen wordt vermeden. Het testbed is niet bedoeld om de DDoS-weerbaarheid van andere partners te testen, maar om testverkeer te ontvangen voor evaluatie van het clearinghouse. Voor pilots in gevestigde anti-DDoS-coalities en voor versies van het DDoS-clearinghouse op productieniveau zijn, anders dan bij het testbed, wel formele overeenkomsten inzake gegevensuitwisseling nodig.

Ontwerp van het testbed

Figuur 1 geeft een overzicht van het ontwerp van ons testbed, dat we hieronder nader toelichten. Het testbed bestaat uit 3 elementen: een virtuele anti-DDoS-coalitie, een generator van DDoS-aanvalsverkeer en het DDoS-clearinghouse dat bij de gehele vCoalition is geïmplementeerd. In ons ontwerp hebben we deze componenten over het internet verspreid en niet gevirtualiseerd in één enkel netwerk, omdat dit representatiever is voor de situatie waarin het DDoS-clearinghouse zal opereren.

Figuur 1: De 3 voornaamste componenten van ons testbed.

Virtuele anti-DDos-coalitie

Om het clearinghouse in een realistische omgeving te testen, moeten we de componenten ervan implementeren in een virtuele anti-DDoS-coalitie (kortweg vCoalition). Onze vCoalition bestaat uit SIDN Labs en SURF, 2 CONCORDIA-partners belast met de ontwikkeling van het DDoS-clearinghouse. De reden waarom wij op dit platform pilots kunnen uitvoeren zonder een overeenkomst over gegevensuitwisseling, is dat er geen echte DDoS-gegevens worden gebruikt. Om te voorkomen dat PII wordt gedeeld, genereren we sporen van DDoS-aanvalsverkeer met behulp van onze traffic generator. Het staat ons vrij om deze traffic captures te delen met wie dan ook, omdat ze geen persoonlijke IP-adressen bevatten.

Traffic generator

Met de traffic generator kan een lid van een vCoalition verkeersmonsters van verschillende DDoS-aanvalstypen genereren en deze naar zichzelf sturen. De traffic generator lanceert geen echte DDoS-aanvallen en staat alleen verwaarloosbare verkeersvolumes toe (maximaal 5 Mbps). Momenteel ondersteunt de generator aanvallen van het type TCP-no-flag, TCP SYN/ACK/FIN floods, UDP floods, fragmentatieaanvallen met verschillende protocollen en ICMP floods. De traffic generator bestaat uit 5 virtuele machines die over de hele wereld zijn verspreid in een cloudplatform, zodat het lijkt alsof een botnet een DDoS-aanval genereert. Deze 5 machines sturen tegelijkertijd verkeer naar een van de coalitiepartners, maar alleen op eigen verzoek. De IP-bronadressen in het verkeer zijn van de cloudprovider en niet van individuele personen. Dit betekent dat we de traffic captures voor het testbed kunnen gebruiken, omdat ze geen persoonlijke IP-adressen (geen PII) bevatten. We creëerden een online dashboard waarmee leden van de vCoalition aanpasbaar verkeer naar zichzelf kunnen sturen (zie Figuur 2). Veel van de details van het internetverkeer waaruit een DDoS-aanval bestaat, kunnen op dit dashboard worden aangepast, zoals communicatieprotocol, verkeerssnelheid, bestemmingspoort(en), pakketfragmentatie, TCP-vlaggen, ICMP-modus, pakketgrootte, enz.

Figuur 2: Dashboard van de traffic generator. Hier is de traffic generator geconfigureerd om lege TCP-pakketten naar poort 80 van het doelwit te sturen.

Omdat we maar een kleine hoeveelheid DDoS-verkeer nodig hebben om het systeem te testen, hebben we de capaciteit van de traffic generator beperkt. Zo kunnen er per machine niet meer dan 1.000 pakketten per seconde verstuurd worden, en niet meer dan 1.000 bytes per pakket. Met de 5 virtuele machines die we gebruiken, genereren we verkeer dat hooguit 5 MB/s bedraagt, wat onvoldoende is om een doorsnee hedendaags netwerk daadwerkelijk uit de lucht te halen. Als een lid van de vCoalition een aanval initieert, laat ons dashboard een bevestigingsscherm zien met de exacte details van het verkeer dat de traffic generator zal versturen. Als extra veiligheidsmaatregel kan de transmissie op elk moment op het dashboard worden gestopt. Bovendien is het dashboard alleen toegankelijk voor de leden van de vCoalition (SURF en SIDN Labs in onze huidige opzet). Toegang wordt verleend aan de hand van een IP-acceptatielijst en wachtwoordcontrole. De server die het dashboard host, instrueert de 5 wereldwijd verspreide virtuele machines via opdrachten die over SSH worden verstuurd. We gebruiken een programma voor pakketassemblage genaamd Hping3 om internetpakketten samen te stellen en naar het lid van de vCoalition te sturen dat het doelwit is.

Het testbed in actie

Ons testbed maakt het ons mogelijk om de technische componenten van het clearinghouse op een gedistribueerde manier te testen. Het gegenereerde ‘DDoS-verkeer’ is afkomstig van over de hele wereld, de partners in de vCoalition zijn fysiek gescheiden en het DDoS-clearinghouse is geïmplementeerd op de systemen van de vCoalition-leden. Figuur 3 is een animatie die de werking van ons testbed laat zien in 8 stappen.

Figuur 3: Animatie van het gedistribueerde testbed voor het DDoS-clearinghouse.

Eerst geeft coalitielid 1 (SIDN Labs in onze huidige opzet) de traffic generator de opdracht om hen aangepast DDoS-aanvalsverkeer te sturen. Coalitielid 1 verzamelt captures van dit verkeer op de doelmachine met behulp van tcpdump en geeft de resulterende PCAP-bestanden door aan de Dissector. De Dissector onderzoekt de PCAP's, vat ze samen in een fingerprint en deelt de fingerprint automatisch met de centrale instantie van DDoS-DB (ddosdb.eu). Een andere mogelijkheid is dat coalitielid 1 de fingerprint eerst uploadt naar een lokale instantie van DDoS-DB, die vervolgens de externe, centrale instantie van DDoS-DB bijwerkt. Vervolgens downloadt coalitielid 2 de fingerprint van de centrale DDoS-DB en gebruikt de Converter om een mitigatiestrategie te genereren in de vorm van iptables-regels. Met onze huidige implementatie van de Converter worden IP-adressen op de aangevallen poorten en protocollen simpelweg geblokkeerd. Nadat coalitielid 2 de mitigatieregels heeft gegenereerd, vraagt deze om dezelfde aanval die eerder door de traffic generator naar coalitielid 1 is gestuurd. Op die manier kunnen we bepalen of de gegenereerde mitigatieregels inderdaad proactief DDoS-aanvallen kunnen afslaan door gebruik te maken van de fingerprints die gedeeld zijn door andere partners in de vCoalition.

Resultaten

We gebruikten het testbed om het DDoS-clearinghouse te testen met verschillende soorten synthetisch DDoS-verkeer. Alle aanvallen werden met succes verstuurd en door de machines van het doelwit afgehandeld. Met behulp van Elasticsearch, Kibana en netwerkanalysepakket Packetbeat kunnen we het inkomende verkeer aanschouwelijk maken. Figuur 4 toont een visualisatie van een 15 seconden durende aanval van het type UDP flood.

Figuur 4: Visualisatie van testverkeer met behulp van Elasticsearch en Packetbeat.

Na het volgen van de testbedprocedure zoals geïllustreerd in Figuur 3, constateerden we dat we een DDoS-aanval op coalitielid 2 inderdaad konden blokkeren door de mitigatieregels toe te passen die door de Converter waren gegenereerd. Door gebruik te maken van het testbed demonstreerden we de volledige cyclus van het DDoS-clearinghouse, van (gesimuleerde) DDoS-aanval op een van de partners in de coalitie tot de succesvolle mitigatie van die aanval op een andere partner. Belangrijk is dat we dit deden zonder echte DDoS-fingerprints te hoeven delen, die in productie steevast persoonlijke IP-adressen zouden bevatten en waarvoor dus een overeenkomst over gegevensuitwisseling met de eigenaren en alle partners in de coalitie nodig zou zijn.

Wat hebben we geleerd?

Het eerste wat we leerden, is wat er nodig is om het DDoS-clearinghouse grondig te testen zonder de tijdrovende implementatie- en juridische processen te doorlopen die nodig zijn voor een pilot- of productiesysteem. En dat, terwijl er nog steeds voldaan wordt aan de juridische basisvereisten, zoals dat leden van een vCoalition alleen 'DDoS-aanvallen’ op zichzelf kunnen initiëren. De tweede geleerde les, is dat we nu weten hoe we een gesimuleerde omgeving voor het DDoS-clearinghouse moeten bouwen die representatief is voor een pilot in een echte anti-DDoS-coalitie. Dit deden we door de componenten van het clearinghouse wereldwijd over het internet te verspreiden, representatieve gegevens te gebruiken en met een gesimuleerde anti-DDoS-coalitie van 2 bedrijven te werken. De derde les, is hoe je een simulatie van het DDoS-clearinghouse vanuit juridisch oogpunt kunt organiseren. We bekeken de verschillende opties voor juridische overeenkomsten. Die zijn ook nuttig voor partijen die hun eigen DDoS-clearinghouse en coalities willen opzetten. We nemen de punten van overweging ook op in het kookboek dat we in het kader van CONCORDIA zullen publiceren. In dit kookboek beschrijven we hoe een DDoS-clearinghouse kan worden opgezet in een coalitie en de lessen die we in het traject hebben geleerd. Belangrijk is dat we ook kennis hebben opgedaan over hoe het DDoS-clearinghouse als geheel zal functioneren in een pilot- of productieomgeving en dat we die lessen kunnen gebruiken om de componenten van het clearinghouse te verbeteren. We hebben dankzij het testbed al verschillende verbeteringen kunnen aanbrengen, zoals een betere synchronisatie van fingerprints tussen meerdere instanties van DDoS-DB. Tot slot voldoet ons testbed aan de vereisten die we eerder in deze blog noemden: het geeft de operationele omgeving goed weer door het gedistribueerde karakter, het werkt met lichtgewicht implementatie- en juridische vereisten en het stelt ons in staat om het clearinghouse in zijn geheel te testen, van begin tot eind.

Toekomstplannen

Onze volgende stap is het uitvoeren van een pilot met de Dissector in de systemen van leden van de nationale anti-DDoS-coalitie en een consortium in Italië. Hierbij maken we gebruik van wat we van het testbed leerden. We verwachten overigens dat ons testbed de partners in die coalities verder aanmoedigt om de Dissector op hun infrastructuur te implementeren. We gaan het testbed verder verbeteren door de traffic generator in staat te stellen sporen te produceren van complexere DDoS-aanvalstypen, zoals bijvoorbeeld amplificatieaanvallen, reflectieaanvallen en combinaties van de huidige typen. We willen ook de Converter verbeteren, aangezien een simpele blokkeringslijst niet volstaat voor alle DDoS-aanvalstypen, zoals DNS-reflectieaanvallen of aanvallen met gespoofte IP-adressen. Tot slot zijn we van plan te onderzoeken hoe het testbed kan dienen als ‘cyber range’ in CONCORDIA, bijvoorbeeld als onderdeel van een DDoS-oefening.

Start video

In deze video demonstreren Thijs van den Hout (SIDN Labs) en Remco Poortinga (SURF) het DDoS-clearinghouse.

Open source

Zowel de software voor het clearinghouse als het testbed zijn open source. Je kunt de broncode bekijken op onze GitHub-pagina.

Met dank aan

SIDN, Universiteit Twente, SURF en FORTH zijn medegefinancierd door het onderzoeks- en innovatieprogramma Horizon 2020 van de Europese Unie in het kader van subsidieovereenkomst nr. 830927. Projectwebsite: https://www.concordia-h2020.eu/. SIDN, Universiteit Twente en SURF zijn lid van de nationale anti-DDoS-coalitie, een zelfgefinancierd publiek-privaat initiatief om leden en de bredere internetgemeenschap gezamenlijk te beschermen tegen DDoS-aanvallen. Website: https://www.nomoreddos.org.