Wat gebeurt er zoal tijdens een DDoS-aanval?

Een DDoS-aanval op je server of servers zit niemand ooit op te wachten. TransIP kan hier helaas, net als vele andere hostingpartijen, over meepraten. Je systeem raakt overbelast, je klanten kunnen niet meer bij hun producten, of nieuwe producten kopen, installeren of configureren. Voor de meeste mensen is een DDoS-aanval alleen iets dat ze van veraf meemaken, of in het vervelendste geval iets waardoor ze tijdelijk niet bij hun website of applicatie kunnen. In dit artikel nemen we je mee achter de schermen bij TransIP, om te laten zien wat er zoal gedaan wordt tijdens een DDoS-aanval.

Distributed Denial of Service

DDoS-aanvallen komen regelmatig voor. Tijdens een dergelijke aanval wordt een server onbereikbaar gemaakt doordat er grote hoeveelheden verzoeken tegelijktijdig op afgevuurd worden. Een server, hoe geoptimaliseerd of van welke capaciteit ook, heeft een limiet voor de hoeveelheid werk die het tegelijktijdig kan uitvoeren. Alle verzoeken die hier bovenop binnenkomen, kunnen daardoor niet afgehandeld worden. Aanvallers vuren met een DDoS zo veel verzoeken op de server af, dat de server niet alleen vertraagt maar daadwerkelijk onbereikbaar raakt. Het gevolg: onbruikbare diensten en applicaties, boze gebruikers en blije aanvallers.

Dit jaar stond de Nederlandse hostingmarkt al regelmatig in de schijnwerpers vanwege DDoS-aanvallen. Naast TransIP waren ook partijen als Argeweb, Yourhosting en DirectVPS al doelwit. Een van de meer uitgebreide aanvallen die TransIP heeft doorstaan in het afgelopen jaar vond in mei 2021 plaats. Deze aanval richtte zich op de DNS-servers. Toen opviel dat een specifiek type request de oorzaak was van uitvallende DNS-servers en functionaliteit, is onderzoek gedaan naar de achtergrond en vonden we veel requests voor niet-bestaande subdomeinen waardoor onze nameservers niet meer snel genoeg de requests konden afhandelen.

Na wat meer onderzoek bleek dat de oorzaak in een toevallige samenloop van omstandigheden lag: we waren net bezig met het omzetten van onze domeinen naar een moderner DNSSEC-algoritme. Om dit soepel te laten verlopen zorgden we tijdelijk voor wat overlap door beide algoritmes in de signatures op te nemen. Hierdoor werden de responses groter dan normaal, wat uiteindelijk voor problemen zorgde.

UDP versus TCP

Normaal gesproken gebruikt DNS het UDP-protocol voor de verbinding tussen een domein en de DNS-server, maar het kan bij wijze van uitzondering overschakelen naar TCP. Het verschil tussen deze twee protocollen zit hem in de manier waarop ze communiceren met een server: UDP vereist geen verdere communicatie na het opzetten van een verbinding, terwijl TCP afhangt van een verbinding en verzoek en antwoord. Het UDP-protocol is te vergelijken met een lopende band aan packages die, onder normale omstandigheden, onafgebroken verzoeken afhandelt zonder steeds in te moeten checken met de server of het vorige pakketje is ontvangen.

UDP is, in bijna alle gevallen, ruim voldoende voor het verwerken van DNS-requests omdat de antwoorden van de server normaal gesproken niet zo heel groot zijn. Maar doordat onze serverresponses tijdelijk dus groter waren dan normaal, paste het niet in één bericht. UDP is niet geschikt voor een situatie waarin een bericht in tweeën wordt gesplitst, omdat de server aan de lopende band verzoeken afwerkt en responses in willekeurige volgorde bij de client terug kunnen komen. Als een pakketje te groot is om het via UDP te versturen, wordt er een signaal gestuurd dat de client het nogmaals moet proberen, maar dan via TCP. Dit protocol houdt wel de volgorde van berichten bij en kan dus een pakketje opsplitsen, indien nodig. Dit komt normaal gesproken weinig voor, waardoor DNS-software er niet op gemaakt is om veel TCP-verbindingen af te handelen.

Hier bovenop kwam nog dat de aanval gebruikmaakte van niet-bestaande subdomeinen, waardoor de server NXDOMAIN-responses teruggaf. Bij een NXDOMAIN-response wordt bij het gebruik van DNSSEC verwacht van de server dat hij ook bewijs meelevert dat het domein echt niet bestaat. Hierdoor werd de response dus nog vele malen groter, waardoor het eigenlijk elke keer weer die maximale grootte van een UDP-bericht overschreed. Het gevolg: een volle queue en overbelaste servers, precies wat de aanvallers in gedachten hadden.

Whack-a-mole

Wat volgde was een spelletje whack-a-mole. Ons team blokkeerde de requests voor de specifieke domeinnaam die gebruikt werd voor de aanval. Tegelijkertijd werd er gekeken naar een meer doelgerichte oplossing voor de aanval. Na internationaal overleg tussen TransIP en andere team.blue-teams werd een manier ontwikkeld om het spelletje whack-a-mole te automatiseren. Daarnaast werd er een caching-laag toegevoegd die impact op onze klanten verminderde. Deze laag kon namelijk de meeste klantenacties afhandelen zelfs als de DNS-servers niet bereikbaar waren. Het nadeel van deze tijdelijke caching-oplossing was wel dat er een extra vertraging in het doorvoeren van aanpassingen kwam.

Na veel testen en overleggen werd het script geïntroduceerd dat automatisch de domeinnamen ‘whackte’. Het werkte vrijwel meteen, waardoor de impact op onze klanten direct afnam en onze diensten weer helemaal naar behoren konden gaan werken. Om ervoor te zorgen dat ons webhosting-team meteen gewaarschuwd wordt bij dit soort misbruik is er een integratie gemaakt voor onze interne chat, die automatisch en in realtime alerts post in een speciaal chatkanaal.

Nadat er duidelijk werd bij de aanvallers dat hun insteek niet meer werkte, werd er nog wel opgeschaald: van tienduizenden naar miljoenen requests tegelijk, met meer nadruk op de NXDOMAIN-aanval in plaats van het afdwingen van het TCP-gebruik. Het geautomatiseerde whack-a-script werd opgeschaald naar een versie die ook UDP-requests afving en de activiteit werd goed gemonitord zodat nieuwe aanvallen snel afgeslagen worden.

Klaar zijn voor de toekomst

Hiermee is helaas de kous niet afgedaan, al zal dat niemand verbazen. Het script werkt nog steeds en slaat nog steeds dagelijks aanvallen af. Het grote publiek merkt hier inmiddels niets meer van, maar op kleine schaal veroorzaken de aanvallen nog steeds wel ongemak. Aan onze kant wordt er daarom steevast gewerkt aan het verstevigen van onze security zodat we niet alleen aanvallen afslaan, maar ook voorkomen waar mogelijk. Want dat we in de toekomst opnieuw last gaan krijgen van een DDoS-aanval staat helaas buiten kijf, maar dat geldt ook voor onze toewijding om ons platform en onze klanten te verdedigen.