'DNS.be ligt onder vuur van botnet'

Volgens de beheerder van de .be-zone, DNS.be, hebben zijn nameservers te kampen met een aanval van een botnet. Leden van het botnet zouden herhaaldelijk valse dns-requests doen, waardoor twee servers overbelast raakten.

Sinds zondag worden zes keer meer query's op de nameservers van het .be-tld uitgevoerd dan gemiddeld, meldt Datanews. Volgens DNS.be, dat de .be-zone beheert, wordt het ongewoon hoge aantal query's veroorzaakt door een aanval van een botnet.

Leden van het botnet zouden steeds opnieuw mx-records opvragen bij de nameservers van de .be-zone. Mx-records, die verwijzen naar de mailservers die bij een domein horen, worden echter niet verstrekt door de dns-servers van een top-level-domein, waardoor ze een negatief antwoord moeten geven. Sinds de aanval is dit percentage gestegen van 10 naar 90 procent.

Door de aanval raakten twee van de acht nameservers gedurende vier uur overbelast. Internetters zouden daar niets van hebben gemerkt. Onlangs werd bekend dat de Belgische regering een noodprocedure wil instellen, om het beheer van .be-domeinen over te kunnen hevelen naar een andere partij als DNS.be het beheer niet meer aankan.

Reacties (54)

[YellowOnline]

Niet een gecoördineerde aanval van hackers, maar een slecht uitgevoerde spamactie zorgde de voorbije uren voor een plotse piek van internetverkeer naar ons land.

CERT.be, de veiligheidscoördinator van het Belgische internet, heeft de oorzaak gevonden van de verdachte stijging in het dataverkeer die de voorbije dagen werd opgemerkt op de servers van DNS.be, de beheerder van de .be domeinnamen. Het gaat volgens CERT.be niet om een georchestreerde aanval van internetcriminelen, maar wel om een slecht uitgevoerde spamactie vanuit het buitenland. Dat meldt de instelling in een persbericht.

DNS.be bracht gisteren zowel CERT.be als de FCCU, de Federal Computer Crime Unit, op de hoogte van een fikse stijging - tot zes keer meer dan normaal - van het internetverkeer op de .be name servers. Twee servers van DNS.be waren door de stijging in het verkeer gedurende een viertal uur overbelast.

De internetpiek vertoonde het typische patroon van een ‘aanval’ vanuit een botnet, een netwerk van gehackte computers of botnets. Het leek er dan ook op dat het op een bewuste aanval van cybercriminelen ging. Maar in feite waren amateuristische spammers aan het werk. "Alles wijst erop dat de spammers hun botnet slecht geconfigureerd hebben en zo de .be name servers gingen overladen met foutieve ’queries’ (zoekopdrachten). Dat is geen gerichte aanval, maar de gevolgen zijn wel hetzelfde: servers kunnen overbelast raken”, zegt Jan Torreele, woordvoerder van CERT. “We blijven de situatie sowieso monitoren, maar momenteel lijkt alles zich te normaliseren."

Het verkeer kwam vooral van botnets uit Oost-Europa en Zuid-Amerika, zegt CERT.be. Andere Europese CERT-diensten melden soortgelijke stijgingen in het internetverkeer in hun thuisland.

De Standaard

Heb het als nieuwstip ingestuurd voor een update, maar geen idee wanneer die door de queue zal komen.

[Verwijderd]

Is het niet mogelijk om met een goede firewall de MX aanvragen te blokkeren. Probleem opgelost lijkt me zo??

[TonnyTonny]

MX requests zijn nog steeds normale DNS requests. Een firewall is normaal gesproken niet in staad de payload van een pakket (DNS of wat anders) te bekijken wat het specifiek request type is.
Goeie firewall of niet: Dit is niet de taak/rol van een firewall. (Is meer iets proxy achtigs als je zoiets zou willen doen.)

Ook de top-level domain DNS moet trouwens MX afhandelen. Net als voor iedere ander request waarbij de DNS server het antwoord niet weet, forward hij de request naar de DNS server van het desbetrefende domain. Als daarop antwoord komt wordt het weer doorgestuurd naar de klant. Dit forwarden kan heel efficient omdat de tld zelf al alle ip-addressen van de DNS servers van de onderliggende domains heeft natuurlijk.
(B.v. ik vraag naar de mail-server van tweakers.net. en ik zit zelf bij ziggo.
De DNS van ziggo gaat te rade bij de DNS van de tld .net, die forward de request naar de DNS van tweakers.net en die geeft uiteindelijk antwoord.)

Wat hier gebeurd is dat de fake DNS queries om de MX records van .BE zelf vragen. Een tld HEEFT geen helemaal eigen MX records.
Een tld DNS is geoptimaliseerd voor het forwarden van DNS naar lower-level servers in de indivuduele domains. En dus niet voor het zelf beantwoorden van invalid requests. Vandaar dat bij een groot aantal van dit bogus reuqest er een performance probleem gaat optreden: DOS attack dus.

[the_stickie]

afaik ontstaat het probleem dat voor elke niet gecachete invalid request de hele zonefile doorzocht moet worden om dan tot de conclusie te komen "dat record heb ik niet , sorry"
Dat terwijl een tld dns-server normaliter waarschijnlijk meestal antwoord uit cache en anders beschikt over een geoptimaliseerde dns zonefile.

[IStealYourGun]

Tja, aangezien die worden gebruikt worden voor het verzenden van mail, lijkt me dat niet al te slim. DNS zal wel de nodige hard & software hebben om dit soort aanvallen tot een minimum te beperken, maar het is niet echt evident.

[Verwijderd]

"Leden van het botnet zouden steeds opnieuw mx-records opvragen bij de nameservers van de .be-zone. Mx-records, die verwijzen naar de mailservers die bij een domein horen, worden echter niet verstrekt door de dns-servers van een top-level-domein, waardoor ze een negatief antwoord moeten geven. Sinds de aanval is dit percentage gestegen van 10 naar 90 procent."

De mx records worden niet door de TLD verzorgt dus kunnen ze toch gewoon een firewall plaatsen die de mx records blokeerd.

[Verwijderd]

Je conclusie is juist omdat .be dit niet doet. Maar de gequote tekst is fout. Er zijn wel degelijk TLD's die MX records teruggeven.

[Keneo]

Het is maar zo netjes om een vraag waar je het antwoord niet op weet te beantwoorden met "ik weet het ook niet" ipv de vraagsteller gewoon te negeren (waarna hij wss gewoon opnieuw probeert)


Blokeringsmaatregelingen zijn hier ook nog helemaal niet aan de orde als ik het goed lees, 2 van de 8 servers zijn 4u overbelast, ok, geen normale gang van zaken, maar er is niets ernstig aan de hand, daarvoor is de extra capaciteit er dus.

[roy-t]

Maar hoe detecteerd een firewal of het om een MX aanvraag gaat? Nou die moet het request bekijken (kost tijd) en mogelijk een deny terug sturen. Een firewall houd wel veel dingen buiten, maar het kost CPU tijd om die dingen buiten te houden, je lost hier dus niet een DOS aanval mee op.

[TvdW]

"Sinds de aanval is dit percentage gestegen van 10 naar 90 procent."
Welk percentage?

Overigens neem ik toch aan dat dit geen (groot) probleem mag zijn voor DNS.be.

[Reactie gewijzigd door TvdW op 23 juli 2024 00:37]

[GlowMouse]

Dat gaat in ieder geval niet om het totaal aantal requests, want voor die toename van 10% naar 90% moeten er 900x meer queries worden verstuurd, en de toename is maar een factor 6. Het zou wel kunnen dat er 900x meer mx-queries worden verstuurd, en dat mx-queries maar 6/900ste van het totaal uitmaken.

[FragNeck]

Het opvragen van records, zoals vermeld in de tekst.

[TvdW]

Juist, maar hoe druk je dat uit in een percentage? 10% van de DNS requests zijn MX requests? Dan zijn de DNS clients wel lekker idioot bezig, kan 't me niet voorstellen.

-edit-
Daarbij doel ik dus op "Mx-records, die verwijzen naar de mailservers die bij een domein horen, worden echter niet verstrekt door de dns-servers van een top-level-domein". Als voor alle top-level-domeinen geldt dat ze geen MX records bijhouden, hoezo proberen DNS clients dan uberhaupt een MX record op te vragen? En als dit 10% is, hoeveel sneller zou het internet dan wel niet zijn als dit niet zou gebeuren?

[Reactie gewijzigd door TvdW op 23 juli 2024 00:37]

[Verwijderd]

Hoezo zijn de DNS clients dan lekker idioot bezig? Het is een botnet aanval, dan stuur je dat soort requests waarbij je de server maximaal probeert te belasten en blijkbaar zijn dat requests waarbij je zeker weet dat de DNS-servers het antwoord niet hebben.

[TvdW]

Klopt. Ik doel echter op die 10% die normaal al binnenkomt aan verzoeken. Dit lijkt mij extreem veel als een TLD nooit MX records bijhoudt.

[Verwijderd]

DNS.be doet dat misschien niet, maar er zijn TLD's die dat wel doen.

Copy&paste van een oud lijstje:

.ai – Anguilla
.as – American Samoa
.bj – Benin
.cf – Central African Republic
.cx – Christmas Island
.dj – Djibouti
.dm – Dominica
.gp – Guadeloupe
.gt – Guatemala
.hr – Croatia
.io – British Indian Ocean Territory
.kh – Cambodia
.km – Comoros
.mh – Marshall Islands
.mq – Martinique
.ne – Niger
.ni – Nicaragua
.pa – Panama
.td – Chad
.tk – Tokelau
.tl – East Timor
.ua – Ukraine
.va – Vatican City
.ws – Samoa

[White_Collar]

"waardoor ze een negatief antwoord moeten geven"

staat er toch duidelijk in...

[naam]

Het percentage aanvragen voor MX-records denk ik.

[maxietheboss]

"Leden van het botnet zouden steeds opnieuw mx-records opvragen bij de nameservers van de .be-zone. Mx-records, die verwijzen naar de mailservers die bij een domein horen, worden echter niet verstrekt door de dns-servers van een top-level-domein, waardoor ze een negatief antwoord moeten geven" dat dus lijkt me

[Tommert38]

Percentage negatieve antwoorden

[Bee.nl]

Ik denk het aantal Mx-recordaanvragen waarbij een negatief antwoord moet worden gegeven.

[SanderH_]

Het percentage requests die ze niet kunnen beantwoorden neem ik aan..

[Pete]

Het percentage MX-requests (van het totale aantal requests).

[webcrtor]

Ik gok het percentage van het opvragen van de mailservers bij het tld?

[Limaad]

ik gok..

o wacht er waren al 20 anderen voor me.

[Marathir]

"om het beheer van .be-domeinen over te kunnen hevelen naar een andere partij als DNS.be het beheer niet meer aankan."
Is DNS.BE dan een overheidsinstantie? Of enig ander overheid gecontroleerd orgaan?

[Het.Draakje]

Ik kan me voorstellen dat België een goed werkende dns.be wil hebben en anders de boel nationaliseert en daarna aan een ander uitbesteedt.

[PaulC]

Ik kan mij dat helemaal niet voorstellen ! Iets goed werkende in Belgie
Dat is tegenwoordig een contradictie op zich ...

[MPAnnihilator]

Het is anders wel de knowhow van .be die er toe heeft geleid dat .eu het .be model heeft overgenomen. Zo slecht zal dat dus wel niet zijn ...

De .be is een van de best georganiseerde registries , technisch , administratief zeer efficient. Alleen snap ik wel dat er een "failover" mogelijk moet zijn.

[drdelta]

Het kan natuurlijk wel ge-wel-dig in elkaar steken administratief, als 25% van je servers eruit klapt omdat een bot-net je 'aanvalt' kun je toch maar beter er voor zorgen dat die 75% gegarandeerd blijft draaien! Probleem met servers is natuurlijk het domino effect als er een aantal overbelast raken..

[MPAnnihilator]

Je kan je wapenen , maar niet overbewapenen. Hier blijken dus 75% van hun servers wel nog bereikbaar geweest te zijn. Op zich nog niets om je zorgen over te maken.

Op zich niet slecht als je weet dat ze nog kunnen terugvallen op een any cast netwerk ( en nog een local internet exchange zoals BNIX )

[Psqad]

zou het dan mss een "test" kunnen zijn om later op een grotere schaal uit te voeren -> eerst proberen op .be en dan op .eu? als het dan toch hetzelfde model is.
Lijkt me geen prettige gedachte...

[Dorgaldir]

nee het is niet van de overheid volgens mij, maar het is wel het enige bedrijf dat alle .be domeinen doet, en als er met hen iets gebeurd dan zijn alle .be domeinen onbereikbaar. En de regering wil dat voorkomen door hen te verplichten een noodplan op te maken, of ontdubbeling op een andere locatie ofzo.

[hiekikowan]

Volgens mij niet, maar ik neem aan dat de overheid hier handeld uit landsbelang... Als er geen internetverkeer meer mogelijk is vliegt belgië uit de internationale beurzen en dat lijkt me niet iets wat je als overheid zou willen laten gebeuren.

[IStealYourGun]

Neen, DNS.be is een VZW die een beheersovereenkomst heeft met de overheid voor een x aantal jaar.

[TDeK]

Heeft iemand enig idee wat het doel van deze aanval is? .be websites krijg je er niet mee plat aangezien eindgebruikers tegen de DNS van hun ISP praten. Deze kan dan in het uiterste geval geen updates meer bij DNS.be opvragen, maar dat is niet zo heel spannend voor de korte termijn.

[dupondje]

Je kan hier effectief de .be mee uit te lucht halen.

Als geen enkele .be nameserver nog response verzend, zal je niet meer weten welke nameservers hij moet opvragen voor bv google.be.
Wanneer dit niet meer gecached is in de nameservers van uw provider, dan zal je google.be niet meer kunnen bereiken.

[TDeK]

Ik ben niet heel erg bekend met de werking van het DNS systeem, maar als een ISP DNS geen response meer krijgt van zijn root DNS, dan zal die het bestaande record toch gewoon handhaven? Anders zou een simpele timeout een hele TLD doen laten omvallen. Het wordt pas gevaarlijk als de aanval tot gevolg heeft dat er valse responses worden verstuurd (dns poisoning) zodat bijv. google.be naar het verkeerde IP gaat resolven. Maar dat is hier - zover ik lees - niet aan de hand, dus het doel blijft me onduidelijk.

[Sissors]

Ik weet alleen niet of na loop van tijd een ISP zijn cache toch laat verlopen als ze geen antwoord meer krijgen van een TLD, en dan heb je het niet over een simpele time-out maar langdurig geen contact.
En ISPs zullen wel veel belgische sites hebben gecached, maar ook niet allemaal. Om het nog maar niet te hebben over buitenlanders die een .be site willen bezoeken.

[Pogostokje]

Dat noem je TTL (Time To Live), dat is per domein in te stellen door de eigenaar en over het algemeen zie je daar een week staan of iets in die richting. Dus, in dat geval kan er kan een week geen verbinding zijn.

Het wordt veel eerder een probleem wanneer de ISP het betreffende domein niet in de cache heeft staan, want dan werkt het direkt al niet.

[Fixi0n]

Ja, ik vraag me toch ook echt af wat de beweeg redenen zijn van zo'n botnet beheerder. Dit heeft toch totaal geen achterliggende gedachten. Die DNS records zijn toch al lang verspreid over de hele wereld en de records kunnen overal vanaf gehaald worden als de .be root servers down zijn. Correct me if i'm wrong!

[Rob Coops]

Het lijkt me dat er een simpele oplossing moet zijn om het verstrekken van MX records in een top-level DNS server uit te zetten. Ik neem aan dat het een kwestie is van een paar regels in de Bind server om in plaats van het geheel op te zoeken ze zeggen:
if ( top_level_domain_server ) then negative_response()
Om het maar even zo simpel mogelijk op te schrijven, het lijkt me dat de server dan niet even zijn DB hoeft te doorzoeken om te bekijken wat de MX records zijn voor het opgevraagde domein. Je zou zelfs in plaats van de negative_response gewoon geen response kunnen sturen omdat er nooit een goede reden kan zijn om een top level domain server om de MX records te vragen van een domein.

Als deze opties nog niet mogelijk zijn dan wordt het hoog tijd dat deze even toe worden gevoegd, het lijkt me heel erg makkelijk en omdat het antwoord toch altijd negatief is lijkt het me ook dat je er wat betreft RFC regeltjes geen probleem mee kan hebben als je de optie toe voegt voor top level domain servers om simpel weg dit soort verzoeken te negeren.

[Waking_The_Dead]

Maar misschien is het performanter om bij een gemiddelde bevraging van 10% gewoon de requests door te laten en niet eerst te laten analyseren alvorens naar de databank te sturen.

[Maasluip]

Geen response geven is in dit geval misschien goed, maar over het algemeen niet. Je weet niet waarom je dat soort aanvragen krijgt, misschien is het een configuratiefout. Dan is het goed om terug te zeggen "krijg je niet van mij, want". Daar kan een goed geprogrammeerde DNS iets mee doen (niet meer daar aanvragen) of je kunt het in logfiles zetten zodat een beheerder er iets mee kan doen.

Je doof en stom houden is meestal geen goed idee bij communicatie.

[Brahiewahiewa]

BE. MX 1 localhost.

[perlboy]

Het mooie is dat niet perse een DoS attack hoeft te zijn. Op de DNS servers die ik voor het bedrijf waar ik werk beheerde hadden we iets soortgelijks: een klant van ons had zijn DNS servers geupgrade welke niet correct omgingen met de negatieve antwoorden die onze servers ze stuurde. Die (windows based) systemen bleven maar malen en malen om bepaalde records en een IP blacklist was de enige oplossing.
In dit geval zou een redelijk groot mail cluster geupgrade kunnen zijn.

[TonnyTonny]

Kan inderdaad, maar in dat geval moet de bron erg gauw duidelijk zijn en te blacklisten zijn. (Kunnen maar een paar specifieke ip-addressen zijn.
Of ze zijn niet competent bij DNS.BE of er is echt een DoS.

[perlboy]

Ook gespoofte e-mail adressen in een From: gestuurde massa spam kan dit soort zogenaamde backscatter opleveren...
Het is gewoon in de mode om elk onverklaarbaar verkeersspike als DoS te betitelen
Niet dat echte DoS attacks niet voorkomen.

[Reactie gewijzigd door perlboy op 23 juli 2024 00:37]

[LFA]

Toch toevallig dat dit bericht naar buiten komt vlak nadat de Belgische regering verklaart dat ze een noodprocedure wil voor als DNS.be het niet meer aankan, of zou deze aanval al voorzien zijn door de regering?

[HAL 9000]

De reactie van de regering kwam er na een vorige aanval in november eind vorig jaar. Dit is gewoon een nieuwe aanval. Niets geheimzinnigs aan.

[Verwijderd]

<alu-hoedje>

Ik zou eens gaan kijken welk bedrijf profiteert van die eventuele noodprocedure

</alu-hoedje>

[marquis]

Onlangs werd bekend dat de Belgische regering een noodprocedure wil instellen, om het beheer van .be-domeinen over te kunnen hevelen naar een andere partij als DNS.be het beheer niet meer aankan

Betekent dit dan andere servers onder vuur worden genomen? Als dit zo is en zij stellen ook een noodprocedure in, valt DNS op een gegeven moment vanzelf om. My 2 cents.

[MorDrakka]

Belgische Regering?