Caroline Noordwijk is veiligheidsadviseur bij een ministerie. Net als veel andere bezoekers van de beurs Overheid & ICT 2013 maakt zij zich zorgen over de recente DDoS-aanvallen. Haar vraag gaat daar dan ook over.
‘De laatste weken zijn er veel aanvallen geweest op grote instellingen waarbij hele netwerken werden platgelegd’, zegt Caroline. ‘Aangezien dit in de toekomst hoogstwaarschijnlijk steeds meer gaat voorkomen, is het een interessante vraag om te kijken hoe organisaties zich hier het beste tegen kunnen beschermen. Er zijn uiteraard verschillende maatregelen die genomen kunnen worden, maar welke zijn efficiënt en wat is de impact ervan?’
Kortom, haar vraag is: hoe kunnen Nederlandse banken en andere organisaties zich het beste wapenen tegen DDoS-aanvallen?
Gedurende de beurs Overheid & ICT 2013 kunnen lezers van Computable vragen stellen over ict bij de overheid aan de ruim 1100 Computable-experts. Tijdens de beurs is permanent een expert in de Computable-stand aanwezig. Een vraag kun je stellen door het invullen van een formulier. Experts beantwoorden de vragen z.s.m.
Zie hiertoe de discussie bij de antwoorden op een vraag van gisteren: Moeten de banken zelf ISP worden?
Het beschermen tegen DDoS aanvallen is iets wat niet op 1 nivo geregeld kan worden. Het is een samenspel van verschillende technologien die de aanval zo veel mogelijk zullen beperken.
Op ISP nivo is het van belang om de grote aanvallen op layer 3 en layer 4 te blokkeren. Dit ter voorkomen van het vol raken van de internet verbinding naar de bank. Daarnaast is er speciale apparatuur beschikbaar voor op de bank locatie welke aanvallen op layer 3, 4 en 7 kunnen detecteren en kunnen blokkeren. Norea (beroeps organisatie voor IT auditors) heeft hier nog een stuk over geschreven: http://www.norea.nl/readfile.aspx?ContentID=73197&ObjectID=1018127&Type=1&File=0000038620_Factsheet_DDoS.pdf
Deze gelaagde oplossingen kunnen het probleem grotendeels beperken. Daarnaast zullen we hiermee moeten leren omgaan en moeten accepteren dat dit soort zaken helaas gebeuren. Verwachting is dat dit nog maar een begin is van dit soort aanvallen aangezien het redelijk makkelijk is om dit soort aanvallen uit te voeren. Veel tools zijn vrijelijk voor handen en genoeg mensen op Internet die dit als ‘grap’ willen proberen.
Martijn,
Interessant stuk! Je benaderd het alleen volledig verkeerd! Je verdedigt je tegen een DDOS aanval. Ik vergelijk een DDOS meteen dorp dat voor het eerst te maken krijgt met Inbraak. Moeten dan ineens alle Deuren op slot? Hang- en sluitwerk worden vervangen? Tralies voor de Ramen? Of pak je de Inbreker…? Juist, het wordt tijd dat iedereen verplicht een Virusscanner ‘gebruikt’ (zo niet, dan wordt je afgesloten door de ISP). Hetzelfde geldt voor het uitvoeren van Portscan’s (en afgeleiden). Daarnaast dienen alle Camouflage-middelen (zoals anonieme proxy’s) verboden te worden (op straffe van uitsluiting). Tenslotte dienen Datacenters een ‘hackerfree certificate’ in te voeren.
Het plaatsen van rekken vol ‘dozen’ lost alleen tijdelijk iets op en is uiterst kostbaar (prettige bijkomstigheid van de betreffende fabrikanten). Er komt vanzelf een DDOS die ook met de meest grote ‘dozen’ niet kan worden tegengehouden. De Politiek is nu dus aan zet. Helaas niet de meest doortastende club…
Er zijn mogelijkheden om DDOS attacks zo goed als onbruikbaar maken. Zoals hiervoor al opgemerkt zouden deze middelen in principe al in het internet zelf aangebracht moeten worden, omdat dit veel goedkoper is dan dat iedere op internet aangesloten instellingen deze middelen moet gaan inrichten.
Kort gezegd komt het neer op Big Data Analyse en SDN. Door alle routers informatie over verkeerstromen te laten verzamelen (Big Data) en deze zodanig te analyseren dat patronen herkent worden van verkeersstromen, kan door middel van intelligente algoritmes bepaald worden of er significantie afwijkingen van de voorspelde verkeerstromen optreden. Dat is een signaal dat er actie kan worden ondernemen. Die actie zou dan genomen moeten worden door Software Defined Networks, waarbij de fysieke componenten (routers, switches etc) die louter en alleen voor het data-pad gebruikt worden, ondergeschikt worden gemaakt aan de logica van het SDN netwerk: het control-pad. Via SDN kan bij sterk afwijkende verkeerspatronen vrijwel automatisch verdacht dataverkeer omgeleid worden naar een digitale bittenbak, in ieder geval niet naar de beoogde bestemming. Daarmee wordt voorkomen dat de host aansluiting (meestal een firewall, DMZ, authentication servers etc) volloopt met onzinnige aanvragen en plat gaat (het principe van een DDOS attack) of dat verbindingen zo vol lopen dat de routers met verbindingen naar die host volgelopen buffers krijgen met alle gevolgen van dien.
Maar daarvoor is het wel nodig dat de mainstream routers (knooppunten) van internet, in ieder geval in die gebieden waar DDOS attacks voor veel ongemak en schade zorgen (Europa, Amerika) voorzien worden van SDN mogelijkheden en dat er op IETF niveau maatregelen genomen worden voor het verzamelen van die data, en het omleidingspad.
IETF zal dat alleen doen als de getroffen landen gezamenlijk vinden dat het nodig is. Tot die tijd zullen getroffen bedrijven iets soortgelijks moeten doen bij de routers die hun internetaansluitingen vormen en die zij zelf beheren. Maar dat impliceert dat iedere bank, de KLM, DigID etc zelf het wiel moet gaan zitten uitvinden en veel kosten zullem moeten maken. Vandaar mijn opmerking dat het veel handiger is om dit in internet zelf aan te brengen.
Een hacker zal met inzet van een botnet op drie manieren een aanval starten:
– Methode 1: Aanval op het netwerk (laag 3) waarbij de systemen van het botnet allemaal tegelijkertijd domme (grote) pakketjes naar het doelwit. De internetverbinding raakt hier simpelweg mee overbelast. Vergelijkbaar met een file op de snelweg. Om dit op te lossen heb je een extreem grote internet-verbinding plus een DDOS-wasstraat nodig
– Methode 2: Aanval op een zwakke plek in een netwerkprotocol (laag 4). De systemen in het botnet sturen allemaal tegelijkertijd misvormde of onvolledige http-pakketjes naar bijvoorbeeld een webserver of firewall. De lijn raakt niet overbelast maar de firewall of webserver raakt overbelast. Dit type is iets ingewikkelder dan methode 1.
– Methode 3: aanval op een zwakke plek in een applicatie(laag 7). De hacker gaat eerst op zoek naar een zwakke plek in een applicatie. Zodra deze is gevonden zet de hacker het botnet in om deze zwakke plek uit te nutten. Deze heeft vaak nauwelijks effect op de bandbreedte maar is uiterst resoluut op een webapplicatie of dns-server.
Voor elk van de aanvalstechnieken zijn andere beveiligingsmaatregelen te treffen. Er is dus geen heilige graal die alle DDOS-aanvallen kan en zal tegenhouden. De hacker zal op basis van de getroffen beveiligingsmaatregelen kijken welke aanval het meeste geschikt is.
Volgens mij ligt het principe van de oplossing wat we al 20 jaar doen met parallelle hardware databases.
Die gaan volgens het MPP (Massive Parallell Processing ) principe te werk.
Of eenvoudig gesproken: “Verdeel en Heers” met een verzameling hardware/software autonome delen die 1 logisch geheel vormen.
Hierdoor werd een ‘loadbalancing” naar de database verkregen.
Beschouw de website als een database en neem dezelfde maatregelen.
Bij veel drukte kan je bij schakelen. Bij te weinig aanbod kan je terugschakelen.
In deze geest zou ik het volgende doen:
1. Buiten de Firewall een verzameling servers met een identieke
website/service waarop de thuisgebruiker terecht komt
nadat hij de betreffende URL heeft ingegeven.
De toegang tot deze server wordt bepaald door een specifieke IP
range. Het IP-toekennings mechanisme zou je van tijd tot tijd moeten
veranderen.
2. Elke van deze servers herbergt meerdere separate VMWare systemen.
De range van IP adressen wordt dan lokaal nog eens verdeeld over de
meerder VMWare systemen. Wordt een specifiek VMWare te druk dan stop
je dit systeem. Slechts een klein deel van de gebruikers vliegt uit
de lucht. Je start een verse clone van deze VMWARE en zal gauw weer
vragen van de gebruikers kunnen behandelen.
3. Deze externe server geeft dan op zijn webpagina, als de gebruiker er
voor het eerst komt, een grafische code op het scherm.
Deze moet door de gebruiker worden gelezen en bevestigd.
Hierdoor krijg je manueel extra controle informatie.
4. De server buiten de firewall zendt alleen de ‘goede’ transacties naar
de ECHTE website server ( die ook uit meerdere systemen net zoals
buiten de firewall kan bestaan) die de extra manuele code hebben al
of niet uitgebreid met een usernaam. De goede combinatie valt niet
automatisch door een onbekende te genereren.
doorstuurt. Dit moet een veilige verbinding worden.
Elke aanvraag die niet de manueel ingegeven extra code al dan niet
voorzien van een usernaam van de gebruiker, wordt afgebroken.
De sessie voor die aanvraag, vanuit het betreffende een specifiek IP
adres, wordt gekilled.
5. Wil je echt nog veiliger zijn. Dan kan je elke week de gebruikers,
voor die week geldig, een code via SMS sturen. Denk aan bijv TAN code
zoals nu reeds bij bepaalde banken gebeurt.
Geruikers zullen daar geen moeite mee hebben. Het extra werk weegt
op tegen het NIET in kunnen loggen.
Kortom buiten de Firewall moet je filteren om de echte klanten/gebruikers door te laten gaan. Zorg voor manuele unieke identificatie van de aanvraag.
Via UPTIME software kan je voor alle servers scripts lanceren om dit proces automatisch te laten verlopen/triggeren en bijsturen.
Succes.
Huub Hillege
Natuurlijk zijn er technische oplossingen om een DDos aanval af te slaan en zelfs gedeeltelijk te voorkomen. Veel on-line casino’s en andere bedrijven hebben hier al lang de nodige technieken voor in huis.
Maar we lijken voorbij te gaan aan het feit dat de “boeven” toch echt slim genoeg zijn om deze steeds opnieuw te omzeilen. Zolang zij, tegen betaling, toegang kunnen krijgen tot miljoenen geinfecteerde PC’s zal in ieder geval één maatregel een redelijk groot effect hebben en Fred Geerlings noemt deze ook al; verplicht de ISP’s om alleen PC’s met een recente AV scanner toe te laten. Gelukkig ben ik niet zo naief om te denken dat dit eenvoudig is; het zal een kwestie van uren zijn voordat een virusbouwer iets ontwikkeld heeft waardoor de ISP “denkt” dat een PC met een recente versie van een Av pakket werkt.
Daarom zijn er meer maatregelen nodig; Internationale Regelgeving over de vervolging van gebruikers van botnets, maatregelen die ISP’s dwingen om dit probleem serieuzer aan te pakken, betere identificatie van ECHTE gebruikers door niet slechts naar een User-id & password te kijken, maar ook naar andere omgevingsvariabelen (locatie, type HW/SW die deze klant normaal gebruikt etc.).
Natuurlijk is er een belangrijke taak voor de overheid, en zelfs de EU weggelegd. En het lijkt mij dan ook verstandig dat een aantal vertegenwoordigers van het bedrijfsleven, de ISP’s en de overheid op korte termijn eens bijelkaar gaan zitten om zit krachtdadig op nationaal-, maar zeker ook op internationaal niveau aan te pakken.
Inmiddels is onze maatschappij sterk afhankelijk van het Internet. Als de overheid WEL verwacht van ISP’s dat zij alle dataverkeer te bewaren om verdachte mails te kunnen traceren, dan lijkt het me dat andere maatregelen niet alleen mogelijk, maar zelfs noodzakelijk zijn.
Icann (BE) geeft advies over wat organisaties kunnen doen wanneer ze het slachtoffer zijn van een DDoS-aanval. icann benadrukt dat instellingen weinig kunnen doen om dergelijke aanvallen te voorkomen.
Senior security technologist Dave Piscitello van Icann heeft zijn adviezen beschikbaar gemaakt op de blog van Icann.
Hij stelt dat instellingen die vermoeden dat ze slachtoffer zijn van een DDoS-aanval de politie of het plaatselijke CERT (ons federale cyber emergency team, in NL het NCSC) snel moeten informeren, maar dat dergelijke instanties weinig kunnen doen om de aanvallen te voorkomen.
“Zeker wanneer je organisatie bedreigd is geweest, of wanneer er geld gevraagd wordt om niet aangevallen te worden is het zaak om de politiediensten snel op de hoogte te brengen”, zegt hij. “Ook wanneer je er van uit gaat dat kritische infrastructuur gaat aangevallen worden. Wanneer je een aangifte doet kunnen de autoriteiten immers snel informatie over de criminelen verzamelen.”
Het belangrijkste is dat een getroffen partij zo snel mogelijk contact opneemt met zijn hosting provider, het best nog tijdens de aanval. De provider kan immers een groot deel van het aanvalsverkeer blokkeren. Daartoe geef je zo veel mogelijk gedetailleerde informatie door, zoals het type verkeer (DNS, TCP, UDP, …), de poorten, de bron, hoeveel bandbreedte er in beslag wordt genomen, etc.
“Je hoster kan upstream-providers en ISP’s die het aanvalsverkeer doorgeven contacteren en hen wijzen op de aard van het verkeer”, aldus Piscitello. “Normaal gezien zorgen deze operatoren er dan voor dat de routes waarlangs het DDoS-verkeer loopt geblokkeerd worden, en dat verkeer van dicht bij de bron geblokkeerd wordt.”
Wanneer dat niet helpt, kan het lokale cyber emergency team (CERT) worden ingeschakeld. “Dat team zal de aanval verder onderzoeken, en op zijn beurt de hosting provider contacteren in naam van het slachtoffer. De CERT-teams werken trouwens met alle betrokken partijen samen om de impact van de aanval te beperken.”
Voorts adviseert Icann nog om een ‘DDoS-attack response plan’ op te stellen, zodat iedereen weet wat te doen wanneer er een aanval plaatsvindt.