Samen de Nederlandse DDoS-weerbaarheid vergroten, deel II van III
Cristian Hesselman (SIDN en Universiteit Twente), Remco Poortinga-van Wijnen (SURF), Gerald Schaapman (NBIP) en Remco Ruiter (Betaalvereniging Nederland)
Vorige week hebben we het gehad over hoe de nationale anti-DDoS-coalitie tot stand kwam en wat het doel ervan is, namelijk het realiseren van een coöperatieve DDoS-bestrijdingsstrategie door middel van 5 instrumenten. Deze week nemen we een daarvan nader onder de loep: het DDoS-clearinghouse, een technisch systeem waarmee coalitie-deelnemers de kenmerken van DDoS-aanvallen in real time kunnen meten en delen. Daarnaast vertellen we hoe ons werk er nu voor staat, met als cliffhanger welke lessen we hebben geleerd en wat de vooruitzichten zijn. Deze onderwerpen komen volgende week aan bod, in het derde en laatste deel van deze serie.
DDoS-clearinghouse
Een van de pijlers van de Nederlandse nationale anti-DDoS-coalitie is ons zogeheten DDoS-clearinghouse, een systeem waarmee deelnemers de kenmerken van DDoS-aanvallen waarmee zij geconfronteerd worden kunnen meten en deze informatie met andere coalitieleden kunnen delen. Onder de deelnemers bevinden zich ISP’s, banken, internet exchanges en overheidsinstellingen.
Figuur 1 laat zien hoe het clearinghouse functioneert aan de hand van een voorbeeld met serviceproviders SP1, SP2 en SP3. SP2 is het slachtoffer van een DDoS-aanval (A in Figuur 1) en deelt de kenmerken van A met SP1 en SP3. Deze kenmerken betreffen informatie, zoals bronadressen die bij A betrokken zijn, pakketgroottes, duur van de aanval en protocoltypen. SP2 deelt deze informatie in de vorm van een ‘DDoS fingerprint’ (FP in Figuur 1), bijvoorbeeld door gebruik te maken van packet captures (PCAP’s), NetFlow [Conrads19] of IPFIX. Het operationsteam van SP2 bepaalt welke fingerprints ze met de andere serviceproviders willen delen en kan een fingerprint eventueel ook handmatig genereren als A een ernstige storing van hun systemen veroorzaakt. Het team kan ook de filterregels die ze hebben gebruikt zijn om de aanval af te slaan in de fingerprint opnemen, bijvoorbeeld in de vorm van Snort-regels.
De operationsteams van SP1 en SP3 gebruiken de fingerprint die ze van SP2 krijgen om hun infrastructuur in gereedheid te brengen voor het geval zij het volgende doelwit van aanval A zijn, bijvoorbeeld door pakketfilterregels op hun routers te installeren (bijvoorbeeld regels R1 en R3 in Figuur 1). Zonder de fingerprint van SP2 zouden ze zelf zulke regels moeten schrijven tijdens de aanval, als ze het al meer dan druk genoeg hebben. Als A bijvoorbeeld SP1 zou aanvallen, moet het operationsteam van SP1 het verkeer van A inspecteren, een pakketfilterregel (R1) schrijven voor de verschillende soorten apparatuur binnen hun netwerk en die regel in het netwerk doorvoeren. Dat moet allemaal gebeuren terwijl mogelijk de bereikbaarheid van de diensten van SP1 in het gedrang begint te komen. Als ze van tevoren al een fingerprint van A hebben, hebben ze meer tijd om R1 te schrijven en door te voeren. Omdat ze hierdoor een voorsprong hebben, is er meer kans dat de regel de aanval effectief bestrijdt. Daarnaast kan SP1 de fingerprint gebruiken om de aanval te detecteren en het verkeer vervolgens weg te sluizen naar een (externe) wasstraat.
Hoewel het delen van DDoS fingerprints serviceproviders zoals SP1 een proactieve voorsprong geeft, hebben serviceproviders zoals SP2 nog steeds voorzieningen nodig om aanvalsverkeer te verwerken. Het DDoS-clearinghouse is dus een aanvulling op wasstraten zoals die van NBIP-NaWas of commerciële equivalenten en geen vervanging.
Serviceproviders kunnen de fingerprints ook voor andere doeleinden gebruiken. Bijvoorbeeld om in samenwerking met rechtshandhavingsinstanties daders op te sporen en te vervolgen en om de evolutie van DDoS-aanvallen te analyseren. Dergelijke toepassingen behandelen we niet in deze blogserie.
Een aanvaller kan ook verschillende serviceproviders tegelijkertijd onder vuur nemen. In dat geval delen alle getroffen serviceproviders hun fingerprint van het aanvalsverkeer dat ze te verwerken kregen, net als SP2.
Onze aanpak: een gecentraliseerd nationaal clearinghouse
We hebben ervoor gekozen om een nationaal DDoS-clearinghouse te ontwikkelen voor alle serviceproviders binnen de anti-DDoS-coalitie, ongeacht de sector waarbinnen ze opereren. Het concept kan echter ook in andere vormen worden toegepast. Zo zou je een clearinghouse kunnen hebben voor een specifieke sector (bijvoorbeeld financiële dienstverlening) of voor de verschillende divisies van een grote onderneming. Ook zou het model kunnen worden toegepast op de lidstaten van de EU, bijvoorbeeld door een EU-breed clearinghouse op te zetten voor de financiële dienstensector, voor NREN’s of mobiele providers.
We opteren in dit stadium daarnaast voor een logisch gecentraliseerd DDoS-clearinghouse om het uitgangspunt te testen: dat het delen van fingerprints bijdraagt aan een proactievere aanpak van DDoS-aanvallen. Het project H2020 CONCORDIA gaat ook andere gebruiksmodellen onderzoeken (zoals volledig gedistribueerd met behulp van blockchain-technologie [BloSS19]). Bijvoorbeeld om te kijken hoe de technische schaalbaarheid van het clearinghouse verder kan worden vergroot.
Een ander aspect van onze aanpak is om het clearinghouse te ontwikkelen door bestaande componenten te hergebruiken, met name de DDoS-dissector en de DDoS-DB [DDoSDB], prototypesystemen die zijn ontwikkeld door Universiteit Twente (hierover straks meer).
Grootste uitdaging: nationale toepassing
De grootste uitdaging waarvoor we staan is om het clearinghouse in Nederland op nationale schaal operationeel te maken. Het is een uitdaging omdat we niet alleen het clearinghouse in een aantal stappen van een lab-omgeving naar ‘preproductie’-niveau (rond TRL 5-7) moeten brengen, maar ook omdat we voor iedere stap niet-technische constructies (zoals juridische overeenkomsten en governancemodellen) moeten ontwikkelen en een breed scala aan serviceproviders op één lijn moeten houden. Om de complexiteit binnen de perken te houden, zijn we begonnen met een relatief kleine groep van 10 serviceproviders: Betaalvereniging Nederland, KPN, NBIP-NaWas, NCSC-NL, NL-ix, SIDN, SURF, THTC, Universiteit Twente en Vodafone-Ziggo.
Waar staan we nu?
We zijn nu iets meer dan een jaar bezig en hebben daarin een eerste iteratie van een technische pilot opgezet. Parallel daaraan hebben we niet-technische componenten ontwikkeld, zoals een overeenkomst om fingerprints uit te kunnen wisselen tussen coalitieleden en een organisatiestructuur. Vooruitkijkend verwachten we hiervan meerdere nieuwe versies te ontwikkelen om tot een preproductie-niveau te komen.
Pilot-iteratie #1: Een van de belangrijkste resultaten die we tot nu toe hebben behaald, is dat we de eerste iteratie van een technische pilot met het DDoS clearinghouse hebben opgezet. Hiervoor hebben we bij SIDN Labs een centrale instantie van DDoS-DB [DDoSDB] (zie Figuur 2) geïnstalleerd en hebben een aantal partners (zoals KPN en THTC) geëxperimenteerd met het genereren van fingerprints. We hebben de eerste iteratie van de pilot zo eenvoudig mogelijk opgezet, waarbij de DDoS fingerprints die we delen alleen DDoS-metadata en geen packet captures (PCAP’s) bevatten.
Overeenkomst om fingerprints uit te wisselen: Ons tweede belangrijke resultaat is dat we een eenvoudige overeenkomst voor het delen van fingerprints hebben opgesteld voor de pilot, waarin basale juridische aspecten zoals doelstellingen, aansprakelijkheid, beveiliging, identificeerbare persoonsgegevens en governance staan beschreven. De overeenkomst is geldig voor een vaste, verlengbare termijn van 6 maanden en wordt momenteel door de pilotpartners ondertekend. De ontwikkeling van de overeenkomst kende een lange aanlooptijd. Dit kwam onder meer doordat de juridische en technische experts elkaars probleemgebieden moesten leren begrijpen en het eens moesten worden over een gemeenschappelijke aanpak, zoals vaak het geval is.
Systeemarchitectuur: Ons derde resultaat is een basisarchitectuur voor het clearinghouse (Figuur 2), die dient als startpunt voor toekomstige iteraties van de pilot. De architectuur draait om 3 belangrijke componenten: de dissector [Conrads19] (genereert fingerprints uit DDoS-verkeer), DDoS-DB [DDoSDB] (distribueert fingerprints en biedt een doorzoekbaar fingerprint-archief) en een converter (koppelt fingerprints aan filterregels voor netwerkverkeer). Figuur 2 laat zien hoe deze componenten met elkaar samenhangen, afgebeeld op het voorbeeld in Figuur 1.
Systeemeisen: We ontwikkelden ook de technische eisen en use cases voor het verbeteren van de clearinghousecomponenten (dissector, DDoS-DB en converter) en het uitbreiden van hun functionaliteit. Zo mag de dissector geen gevoelige informatie over een slachtoffer van een DDoS-aanval in een fingerprint opnemen (zoals IP- of MAC-bestemmingsadressen) en moet de DDoS-DB een geautoriseerde gebruiker toestaan om in de fingerprint-index te zoeken en fingerprints te downloaden. Het uitwerken van de eisen werd gezamenlijk gefinancierd door Betaalvereniging Nederland, het Nationaal Cyber Security Centrum (NCSC-NL), NBIP en SURF.
Volgende week
Het laatste deel van deze blogserie gaat over wat we geleerd hebben bij het ontwikkelen van de resultaten hierboven en over onze weg voorwaarts voor 2020.
Met dank aan
SIDN, SURF en Universiteit Twente werden gedeeltelijk gefinancierd door Horizon 2020, een subsidieprogramma voor onderzoek en innovatie van de Europese Unie, in het kader van Subsidieovereenkomst 830927. Projectwebsite: https://www.concordia-h2020.eu/
[DDoSDB]
DDoSDB-homepage, https://github.com/ddos-clearing-house
[Conrads19]
J. Conrads, “DDoS Attack Fingerprint Extraction Tool: Making a Flow-based Approach as Precise as a Packet-based”, M.Sc. Thesis, Universiteit Twente, Nederland, augustus 2019
[BloSS19]
Bruno Rodrigues en Burkhard Stiller, “Cooperative Signaling of DDoS Attacks in a Blockchain-based Network”, SIGCOMM Posters and Demos ’19: Proceedings of the ACM SIGCOMM 2019 Conference Posters and Demos August 2019, https://doi.org/10.1145/3342280.3342300