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

Hmmn, waarom draaien ‘we’ dat eigenlijk bij Transip?

Dat lijkt mij inderdaad het geval. Ik zojuist ook de RSS ontvangen.

In de opbouw gebruikt Freedom services van derden om niet alles in één keer alles te hoeven doen. Zo kun je rustig bouwen aan je eigen services en wanneer rijp voor productie dat zelf afhandelen. Telefonie zit by Voys en mail bij Soverin.

De DNS servers waren net dicht bij de snelweg binnen Freedom gezet:

Toevoeging: de DNS servers zijn verbonden met die van TransIP, die schakel heeft dus nu problemen door de DDos. De authoritative lijkt bij TransIP te staan en dan krijgt niemand geen resolve meer voor Freedom.nl als die in cache verlopen is.

Freedom verricht wonderen. Zij schijnen eventjes de wereldwijde plaag van DDos aanvallen te hebben te hebben opgelost. :wink:

Dat vind ik altijd zo flauw…
“we zijn op de hoogte van het probleem”
“we werken hard aan een oplossing”
“we hebben het probleem gevonden en opgelost”

Wat was het probleem dan? hoe is het opgelost? wat zijn de acties die genomen worden om te voorkomen dat het probleem weer optreedt?

(Ik neem aan dat het probleem niet “er zitten teveel mensen op de website” was, en dat de oplossing niet “we hebben gewacht tot ze weer weg zijn gegaan” is.)

2 likes

Ddos aanval, zie berichtgeving

Ja, dus met andere woorden: “er zitten teveel mensen op de website”, en “we hebben gewacht tot het over was”.

Een ddos kan door één persoon worden gedaan en er worden gehackte computers en servers gebruikt om services van anderen te ontregelen.

De Freedom domeinen in de DNS hebben lange TTL’s maar de cname van smtp.freedom.nl is 500 seconden en die zal dan snel niet meer gecached zijn als de DNS servers aangevallen worden. Ik denk tenminste dat de TTL van de cname is bepalend voor hoelang smtp.freedom.nl in cache blijft zitten.

Het is momenteel een echt probleem en niet alleen voor Freedom maar ook voor andere ISP.

Tweakers.net over de voordurende ddos-aanvallen

Toevoeging, ik zie dat smtp.freedom.nl een veel langere TTL heeft gekregen. :slight_smile:

1 like

Volgens mij is het Cambrium-deel van Freedom nog altijd niet bereikbaar. Ik zie in ieder geval dat het tussen cr0.nikhef.nl.fusixnetworks.net en (vermoedelijk) freedom-core-nikhef.fusixnetworks.net mis gaat wanneer ik van buiten kom, en wanneer ik vanaf mijn KPN WBA-verbinding een Cambrium-verbinding probeer te benaderen, heb ik 100% packet loss vanaf lo0.cmbr.nikhef-1.connected.by.freedom.nl. Ik meen dat daar normaliter 2a10:3780::1:1 en 2a10:3780::2:2 achteraan kwamen.

Dus ik heb niet het idee dat alles al is opgelost eigenlijk.

Ja, maar wat hebben ze nou gedaan om het op te lossen? De melding is dat het gevonden en opgelost is. Hoe een aanval werkt is wel duidelijk, mede daarom is het zo interessant om te weten wat eraan gedaan is om daar tegen te weren. Of is dat allemaal diep geheim en “security by obscurity”?

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