Iedere maand nemen de omvang, complexiteit en frequentie van cyberaanvallen tegen bedrijven toe. Toch zijn bedrijven voor een steeds groter deel van hun omzet afhankelijk van online kanalen. Recente aanvallen resulteerden in een datavolume dat tienduizend keer zo groot was als het normale verkeer dat e-commerce sites te verwerken krijgen Hoe moeten organisaties zich beschermen als deze trend zich verder voortzet?
De onbetrouwbaarheid van de DNS
In 2012 detecteerde Akamai 768 DDoS-aanvallen, ruim drie maal zo veel als in 2011. Daarbij nam het aantal aanvallen die de toegang tot diensten trachten te blokkeren – of om de servers die deze diensten mogelijk maken te overbelasten – iedere maand toe. Cybercriminelen hebben verschillende motivaties voor deze aanvallen. Door winstbejag gemotiveerde aanvallers proberen hun slachtoffers geld af te persen door DDoS-aanvallen uit te voeren, of ze gingen voor cyberfraude (diefstal van waardevolle informatie, zoals creditcardgegevens). Politiek gemotiveerde aanvallers (de zogenaamde ‘hacktivisten’) richten zich op overheidsinstellingen, zoals DigiD, of op bedrijven die activiteiten ontplooien waar zij tegen zijn, zoals de Operation Payback-aanvallen door Anonymous van enkele jaren geleden. Maar ze kunnen dit ook doen om hun eigen belangen te dienen, bijvoorbeeld groeperingen die tegen de globalisering zijn, alsmede bijvoorbeeld milieuactivisten.
Wat hun motivatie ook is, criminelen kunnen tegenwoordig heel gemakkelijk en goedkoop toegang krijgen tot computermiddelen die ze nodig hebben om hun aanvallen uit te voeren. De diensten van botnets zijn online te koop, zowel kant-en-klaar als in de vorm van goedkope toolkits om zelf nieuwe botnets op te zetten. Tegelijkertijd zorgt de wereldwijde toename van breedbandverbindingen ervoor dat er steeds meer systemen zijn die ze kunnen besmetten met botnetsoftware, waarbij ze ook steeds meer bandbreedte tot hun beschikking krijgen voor het uitvoeren van aanvallen. De gevolgen van dit alles hebben we de afgelopen maanden zelf kunnen ervaren in Nederland.
Deze situatie is zeer zorgwekkend. Terwijl online diensten steeds essentiëler worden voor onze maatschappij, wordt de omgeving waarin deze diensten bestaan steeds risicovoller. En onze systemen zijn vaak niet robuust genoeg om goed te kunnen schalen en te overleven in een vijandige omgeving. Het probleem is dat bij het ontwerpen en bouwen van deze systemen is uitgegaan van het idee dat ze altijd zouden werken, niet van de mogelijkheid dat ze zouden kunnen uitvallen. En op basis van deze aanname zijn systemen gebouwd die zo onbetrouwbaar en complex zijn, dat het niet makkelijk is om daarmee verder te gaan. Wat we echter wel kunnen doen, is hiervan leren en er voor zorgen dat toekomstige systemen zijn ontworpen met het oog op uitval, zodat ze robuuster zijn en beter bestand zijn tegen aanvallen.
Een goed voorbeeld is DNS (de Domain Name Service). Dit protocol doet in feite niets anders dan de namen van websites vertalen naar ip-adressen. Wat niet iedereen zich realiseert, is dat DNS een essentieel onderdeel van het internet is. Zonder DNS zou het voor mensen vrijwel onmogelijk zijn om het internet op een zinvolle manier te gebruiken. Zonder DNS zou het web zoals wij dat kennen, niet bestaan. De kracht van DNS zit in zijn eenvoud: je stelt een vraag (‘wat is het ip-adres van www.computable.com?’) en je krijgt een antwoord (87.233.225.180). Als je op deze vraag geen antwoord krijgt, werkt niets meer. De browser kan dan geen pagina’s laden, e-mailprogramma’s kunnen geen berichten ophalen, et cetera.. Het is daarom essentieel dat DNS altijd beschikbaar is. Gelukkig is DNS wel gebouwd met als uitgangspunt dat het niet altijd goed werkt. En hiervan kunnen we misschien leren hoe we andere robuuste infrastructuren kunnen bouwen.
Om te beginnen maakt DNS voornamelijk gebruik van het UDP-protocol, in plaats van TCP. De werking van UDP (ook wel bekend als het ‘Unreliable Data Protocol’) lijkt meer op het doorgeven van berichtjes dan op het houden van een echte conversatie: de afzender heeft geen idee of zijn bericht de geadresseerde ook daadwerkelijk bereikt. Een client stuurt een UDP-aanvraag naar een name server en die name server stuurt een UDP-antwoord terug. Als dit in TCP was geïmplementeerd, zou deze conversatie zeven data packets in beslag nemen. Als de client niet binnen een vaste tijdspanne een antwoord ontvangt, doet hij een nieuwe poging, maar dan zal die client het verzoek naar een ander server ip-adres sturen.
Omdat DNS geen ‘betrouwbaarheidsgarantie’ van UDP krijgt (en eerlijk gezegd zou een betrouwbaarheidsgarantie van TCP ook niet veel waard zijn), is er bij de implementatie – gelukkig – vanuit gegaan dat het zou kunnen falen en zelfs dat dit regelmatig zou kunnen gebeuren. Er is dus uitgegaan van falen. Omdat de DNS-query/response wordt gerealiseerd met één enkel packet, is het niet nodig dat de client altijd dezelfde DNS-server raadpleegt. Er kan een hele batterij DNS-servers achter een enkel ip-adres worden gezet, voorzien van eenvoudige stateless load-balancing. Er zijn geen complexe stateful load-balancers nodig. Geavanceerdere DNS-systemen kunnen zelfs ip-anycasting gebruiken om één ip-adres te laten reageren op verzoeken uit meerdere geografische regio’s. Clients kunnen ‘leren’ welke servers snel reageren en zullen daarna bij voorkeur deze servers gebruiken.
Uit deze uitvalgevoelige infrastructuur – een onbetrouwbaar transportmechanisme, servers die op ieder moment kunnen uitvallen en een internet dat helaas de neiging heeft om datapakketten kwijt te raken – is toch een systeem ontstaan dat zeer robuust is. Een volledige uitval van DNS komt slechts zeer zelden voor. Zelfs wanneer DNS wordt aangevallen, is het mogelijk om de service relatief eenvoudig te versterken, simpelweg door op te schalen.
Lessen om te leren
Dit laatste is het ‘leermoment’ dat we zoeken als we infrastructuren willen bouwen die bestand zijn tegen de toenemende aanvallen. Vaak worden web-infrastructuren gebouwd waarbij zelfs voor de meest eenvoudige zaken een database ‘in de loop’ zit, als onderdeel van het verzoek/aanvraagmechanisme. Hiermee wordt voorbijgegaan aan de doelstellingen die we in DNS zagen, namelijk dat verzoeken kunnen worden afgehandeld door een kleinst mogelijke set van systemen. Hoe kunnen we dus systemen ontwerpen voor de toekomst, die beter bestand zijn tegen aanvallen?
We beginnen met het bedrijfsmodel en de garanties die we willen bieden. In de hotelindustrie is het bijvoorbeeld gebruikelijk dat een hotelkamer voor een korte tijd wordt ‘gereserveerd’ als een klant op zoek is naar een kamer. Dus als je via verschillende sites zoekt naar de goedkoopste hotelkamer, kan het goed zijn dat je tientallen kamers hebt ‘gereserveerd’, ook al zal je bijna geen van deze kamers uiteindelijk bestellen. Het hotel wil er zo voor zorgen dat, wanneer je uiteindelijk besluit een kamer te reserveren, de kamer ook inderdaad beschikbaar is tegen de opgegeven prijs.
In de luchtvaartindustrie gebeurt precies het tegenovergestelde: als je een vlucht zoekt, wordt deze plaats niet direct gereserveerd. Het is dan ook mogelijk dat wanneer je uiteindelijk een vlucht wilt boeken, deze niet meer tegen het eerder opgegeven tarief beschikbaar is.
Dit zijn twee licht verschillende bedrijfsmodellen die ieder een totaal andere architectuur vereisen. In het hotel-model, moet het ‘voorraadsysteem’ een volledig geïntegreerd platform zijn: zodra iemand de prijs van een hotelkamer bekijkt, wordt die kamer in het ‘voorraadsysteem’ voor korte periode gereserveerd. Niemand anders krijgt die kamer gedurende die periode nog te zien. Dit vraagt om een goed ontworpen synchrone databasearchitectuur. Deze architectuur is ook een relatief gemakkelijk doelwit voor aanvallers. Zo kan een onbedoelde aanval voor problemen zorgen: een derde partij die bijvoorbeeld kamerprijzen wil verzamelen voor een eigen website, kan zo onbedoeld een groot aantal kamers voor korte tijd reserveren. Daarmee wordt de database overbelast en kunnen de kamers niet door andere bezoekers worden bekeken, laat staan gereserveerd. Het biedt een mooie zakelijke garantie, namelijk dat de kamerprijs die je eerder hebt aangeboden gekregen ook de prijs is die je uiteindelijk betaalt. Zolang je de transactie maar binnen een bepaalde tijd afrondt. Maar dit heeft wel een flinke prijs: een architectuur die niet goed schaalt, moeilijk is te repliceren en gevoelig is voor denial-of-service.
Het luchtvaartmodel daarentegen biedt, met slechts een kleine aanpassing in het bedrijfsmodel, de mogelijkheid voor een zeer sterke infrastructuur. Omdat de ‘voorraad’ van beschikbare stoelen pas afneemt op het moment dat daadwerkelijk een vlucht wordt geboekt, heeft het inventarissysteem veel minder schrijfoperaties te verwerken. En belangrijker: omdat er altijd een korte tijd zit tussen het weergeven van een ticketprijs en de daadwerkelijke bestelling, zijn kleine discrepanties in de voorraad niet zo belangrijk. Als een klant een ticket voor een bepaalde vlucht zoekt terwijl de allerlaatste stoel net door een andere klant wordt geboekt, zal de eerste klant teleurgesteld zijn. Als ze een beschikbaar ticket of een ticketprijs zien omdat ze net een halve seconde eerder zochten voordat deze door iemand anders werd geboekt, zullen ze echter net zo teleurgesteld zijn als wanneer ze een halve seconde later hadden gezocht.
Door een systeem op basis van dit uitgangspunt te ontwerpen, is het mogelijk om het ‘voorraadsysteem’ voor tickets te scheiden van het reserveringssysteem. Om klanten zo tevreden mogelijk te houden, is het natuurlijk wel zaak dat deze twee datasets zo synchroon mogelijk lopen. Maar een kleine vertraging is acceptabel. Het inventarissysteem is nu slechts een buffer voor het reserveringssysteem. Het is beter schaalbaar en kan makkelijk worden gedistribueerd. En als een aanvaller de voorraad scant, heeft dat geen gevolgen voor het back-end reserveringssysteem.
Door een systeem op deze manier te ontwerpen, met in het achterhoofd de mogelijkheid dat het kwetsbare onderdeel (het inventarissysteem) uitvalt, blijft de rest van het systeem beschermd en beschikbaar.
