[Freedom server:] DDoS-aanval op DNS: en nu?

Ook ik heb die vraag eerder gesteld en ben daar nieuwsgierig naar,
maar ik kàn me voorstellen, dat Freedom niet àlles publiek wil maken.
Om 2 redenen (misschien meer) :

  • concurrentie-voordeel
  • de ‘treiteraars’ niet te slim maken

Concurrentie voordeel lijkt mij hier niet op zijn plaats en iedereen zit in hetzelfde bootje. Het probleem is niet oplosbaar en je kunt alleen mitigeren (minder erg maken).

Het zou wel fijn zijn als Freedom laat weten of er gebruik is gemaakt van van de Nationale Wasstraat https://www.nbip.nl/nawas/.
Cambrium is een deelnemer en het lijkt mij dan ook dat deze hulp is gebruikt.

Wat de mitigatie is ligt eraan wat van aanval het is en het belangrijkste is om de mitigatie te plaatsen zover mogelijk van jouzelf weg. Wat je niet kan bereiken kan je ook niet aanvallen.

Een korte TTL in de DNS zal bij uitval door een aanval ook de andere services onbereikbaar maken voor klanten. Als de TTL langer is zal het adres langer bij de klant in cache zitten en die merkt dan niet dat de DNS server er zelf niet meer kan antwoorden.

Ik zie DNS als belangrijkste onderdeel van het internet voor klanten maar helaas ook kwetsbaar.

Ik gebruik vaak technische termen en mocht die niet duidelijk zijn kun je die hier opzoeken in de woordenlijst van Freedom.nl: Verklarende woordenlijst

3 likes

In mijn optiek zou DNS juist heel erg resilient moeten zijn. In ieder geval is het prima mogelijk om ervoor te zorgen dat de resolvers voor de klanten van Freedom goed blijven functioneren ze alleen vanuit het netwerk van Freedom bereikbaar te maken bijvoorbeeld. Als dat zo zou zijn, dan wordt het heel wat lastiger om zo’n DDoS aanval op te zetten.

Naast resolvers kunnen ook de name servers voor bepaalde zones redelijk resilient gemaakt worden door ze via verschillende netwerken bereikbaar te maken. Nu merkte ik dat een DDoS aanval op TransIP (kennelijk) ook gevolgen heeft voor Freedom en zelfs voor het bedrijf waar mijn zoon werkt.

Wat nu als er ook een DNS zone server zou staan bij Equinix? En eentje ergens anders? Nu krijg ik de indruk dat een enkele DDoS aanval op een grote(re) hosting partij meteen heel veel andere infrstructuren raakt. Dat is volgens mij te voorkomen.

Dat blijft mitigeren want de aanvallers weten de publieke adressen van de DNS servers en je zou er heel veel moeten hebben om de aanval te verzachten.

Het langer in cache laten staan bij de client en caching DNS servers zorg ervoor dat je tijd hebt om de aanval af te slaan of gedeeltelijk af te slaan. De aanvaller kan de aanval eenmaal niet oneindig lang laten duren.

Het plaatsen in verschillende netwerken is altijd verstandig want als jouw eigen netwerk onverhoopt uitvalt dan blijft de andere in de lucht. Bedenk wel dat de services die zelf aanbied door de uitval ook niet meer zijn. Nu heb je wel een werkende DNS maar de servers waarna toegegaan wordt antwoorden niet meer.

Freedom maakt gebruik van verschillende partijen en er is al veel gedistribueerd en dat werkt dan door en blijft bereikbaar als ook de DNS er ook is. En de cirkel is weer rond, een langere tijd dat de klant het IP adres in cache heeft te langer blijven de services beschikbaar blijven als de DNS server aangevallen wordt.

1 like

Ik heb het niet over DNS servers, maar resolvers in dit geval. De resolvers zou je onbereikbaar kunnen maken vanuit het Internet.

DNS servers kan je prima resilient maken door verschillende netwerken te gebruiken, zelfs in verschillende regio’s en/of via anycast bereikbaar te maken. Er zijn nogal wat aanbieders van goede, resilient oplossingen die echt niet down te brengen zijn.

Het gebruik van resolvers die alleen bereikbaar zijn via het eigen netwerk van Freedom is een goede methode en ook gebruikt door Xs4all als ik mij dat goed herinner.

Ik gebruikte resolvers alleen voor resolves die ik niet via authoritative DNS server kon oplossen.

Maar goed de authoritative servers blijven belangrijk voor derden als die bijvoorbeeld e-mail willen afleveren. Gelukkig is dat ook bestendig tegen onderbrekingen en dan komt de e-mail later binnen.

Resolvers zijn ook gewoon DNS servers. Die hebben ook toegang tot andere DNS servers nodig om de antwoorden op onze vragen te vinden. Als dat pad overbelast is dan is 's overbelast.
Er is maar een protocol … ook al wordt gebruik gemaakt van IPv4 of IPv6 als carrier protocol, en UDP dan wel TCP als verbinding
En mogelijk bij TCP native / DOT of DOH.
Het zijn dezelde vragen en antwoorden.

Vergis je niet in de DNS infra structuur… Er zijn heel wat meer DNS servers voor de ROOT van DNS. (meer dan de 13 ip adressen die geadverteerd worden). De meeste van de root servers hebben een reeks duplicaten waarbij al die duplicaten hetzelfde IP adres gebruiken. jij krijgt alleen de DNS root server te zien die toevallig het dichtst bij staat (volgens de BGP tabellen).

Ik denk dat jij op iets als Akamai wijst als je resilient bedoeld: KrebsOnSecurity Hit With Record DDoS — Krebs on Security
Krebs onsecurity had in 2016 al een 400Gbps te verwerken, de capaciteit op het internet is niet bepaald minder geworden.
Je hebt alleen 1000en servers nodig niet een 10-tal om zoiets te kunnen behappen.
Zelfs Akamai kon dat niet meer aan en heeft Kreb verzocht een andere oplossing te vinden. Het is toen verhuisd naar Google Shield.

Juist bij DNS is er een goed versterking te krijgen, je kan met een vrij klein DNS query pakket, een vrij fors antwoord produceren, zeker met DNSSEC kan dit een factor 10 meer data opleveren. (100Mbps aan vragen levert een 1Gbps aan antwoorden).

Het klopt dat de resolvers afhankelijk zijn van upstream of authorative servers.

Wat als je de resolver als volgt laat werken. Zolang er geen recentere gegevens gevonden kunnen worden dan blijven de huidige gegevens in gebruik. Zelfde als een hogere TTL → caching bij de client.

Dit is ook een kwetsbaarheid omdat verouderde gegevens gebruikt blijven en dat kan een aanvaller juist weer benutten omdat, eventuele nieuwe DNS gegevens door Freedom, niet bij de resolver aankomen.

Denk hierbij aan een comprimeerde servers die niet meer onder controle van Freedom is.

Wat is wijsheid hier…

1 like

Bij gebruik van verouderde gegevens zal ook uitwijken naar een andere server lastig maken. Er zijn vele internet diensten die inmiddels zelfs tot 1 minuut TTL gegaan zijn. 5 minuten wordt vaker gebruikt.

Dus inderdaad hier is een mooie afkorting voor YMMV…

TCP, DOH of DOT kunnen wel verlichting geven omdat daar geen vals afzender adres kan worden opgegeven. Alleen vertraagd dat een een hoop omdat voor een vraag en een antwoord pakket dan in totaal 8 paketten moeten worden uitgewisseld, met wachten op antwoorden.

Overigens zou martian (pakketten die uit een richting komen waarvandaan ze niet verwacht worden) filtering meer upstream ook een stuk kunnen schelen. Alleen vereist dat de medewerking van heel veel partijen die al hun egress verkeer gaan bewaken…, ik denk dat er voldoende bulletproof hosting bedrijven zijn om dat een onmogelijke wens te maken).

@Noci Een resolver kan beperkt worden qua resolve requests. Bijvoorbeeld beperkt tot alleen de IP adressen van Freedom, en verder geen connecties toestaan. Afhankelijk van configuratie, netwerkverbindingen e.d. zijn resolvers die zo werken heel goed te beschermen tegen DDoS.

Een DNS zone server moet voor het hele Internet bereikbaar zijn. Dat is een andere situatie. En ja, er zijn oplossingen die domweg praktisch gezien niet down gebracht kunnen worden door middel van DDoS vanwege de brede implementatie, en aanvullende maatregelen.

DNS zone servers zijn essentieel voor bereikbaarheid van e-mail, en andere services. Afhankelijk van hoe kritisch de services zijn, en afhankelijk van budget is het mogelijk om zeer solide DNS oplossingen te implementeren.

Hier de blog van TransIP over de DDOS aanval(len) op maandag 22 maart 2021. Inclusief een post-mortem rapport.
https://www.transip.nl/blog/ddos-aanval-transip

Zo te lezen hebben BGP gebruikt om bepaalde providers jou niet meer te laten bereiken.

Zie het als een rangeer terrein en je zet een wissel zo dat het verkeer wat over dat spoor komt op een dood spoor komt te staan.

Het is een zwaar middel want alles vanaf dat spoor loopt dood als het naar jou wil gaan.

Als de aanval voorbij is zet de wissel weer om en en kan verkeer op dat spoor jou weer bereiken.

BGP = Border Gate Protocol

https://nl.wikipedia.org/wiki/Border_Gateway_Protocol

Uit het verslag van TransIP blijkt dat de twee DDoS een zgn. volumetric DDoS was – domweg zoveel verkeer veroorzaken dat de verbindingen van TransIP vol lopen. Extreem vervelend, en alleen op te lossen als je flink wilt investeren in bescherming die door enkele zeer grote ‘wasstraten’ geleverd kan worden.

Het is eerder dat BGP gebruikt wordt om het verkeer naar de EIGEN site via een peer met grotere capaciteit te laten lopen en die dan te laten filteren.
Daarbij kan gewenst verkeer doorgestuurd worden en ongewenst verkeer hetzij gedropped dan wel geanalyseerd worden.

Ik lees wat TransIP schreef toch anders:

Aangezien de meeste schade al was aangericht, hebben we het besluit genomen om al het verkeer – zowel schoon als vuil – dat vanaf enkele internetproviders binnenkwam geheel af te sluiten. Het bleek namelijk dat verreweg het grootste deel van het vuile verkeer was terug te leiden naar die paar providers. Kort nadat we de kraan hadden dichtgedraaid, zagen we de DDoS-aanval in kracht afnemen en waren onze systemen en websites van onze klanten weer online voordat de avond viel.