Ddos-wasstraat NaWas is voortaan via ERA-IX ook vanuit Duitsland te gebruiken

De Nederlandse ddos-beschermingsdienst NaWas is voortaan ook via internetknooppunt ERA-IX bereikbaar. Daarmee kan de 'wasstraat' ook vanuit Frankfurt worden gebruikt. Volgens beheerdersorganisatie NBIP maakt dat Europese bedrijven en diensten weerbaarder.

De Nationale Beheersorganisatie Internet Providers, NBIP, zegt dat het een samenwerking is aangegaan met ERA-IX. Dat is een Nederlands-Duits internetknooppunt, een tegenhanger van het bekende knooppunt AMS-IX. NBIP biedt meerdere diensten aan, maar de bekendste daarvan is de Nationale Wasstraat voor ddos-aanvallen, beter bekend als NaWas. Internetproviders en bedrijven kunnen via NaWas internetverkeer omleiden als dat wordt aangevallen met een ddos-aanval. NaWas kan die grote hoeveelheden verkeer verwerken en legitiem verkeer eruit filteren.

Nu is met name die NaWas ook te gebruiken via de ERA-IX-exchange. Dat betekent dat verkeer ook buiten Nederland kan worden gefilterd. ERA-IX heeft niet alleen in Amsterdam, maar ook in het Duitse Frankfurt datacenters staan. Volgens NBIP zijn organisaties daarmee weerbaarder dan eerder. De stichting wijst onder andere op de recente stappen om digitale weerbaarheid meer op Europees vlak te regelen in plaats van per land. Overigens is NaWas sinds 2021 ook via het Belgische knooppunt BelgiumIX te gebruiken.

Reacties (31)

[NoTechSupport]

Hoe werkt dit? Moet je een dienst afnemen en iets configureren? Is dit op DNS/firewall niveau. Cool dat eraan gewerkt wordt.

[Snow_King]

Via BGP, het protocol van het internet. Normaal komt verkeer gewoon via je reguliere uplinks binnen. Zodra jij echter een DDoS aanval detecteert kan je een IPv4 /24 of een IPv6 /48 via de NAWAS announcen. Een /24 en /48 zijn het kleinst mogelijke block wat je mag announcen via BGP. Deze is dan more-specific, dus het internet zal verkeer voor die subnets naar de NAWAS sturen.

De NAWAS gaat het verkeer vervolgens filteren op DDoS aanval met heel wat technieken. Via een private VLAN op de NL-IX, AMS-IX of nu de ERA-IX krijg je dan het schone verkeer afgeleverd.

Ons "record" is een DDoS van 800Gbps laten filteren door de NAWAS en dat ging prima.

[Bor]

In 2024 was 353Gbps de max DDoS die NaWas heeft gemitigeerd overigens. Deze info is te vinden in de infographic: NaWas DDoS attack statistics of 2024

In Q1 2025 was de max attack size 305 Gbps: DDoS attack statistics in the first quarter 2025

[Snow_King]

Dan zit ik er echt naast denk ik :-) Het is al weer in 2021 of 2022, daar stond mij bij dat het 800Gbps was. Ik heb het report van de NAWAS niet meer in mijn mailbox. I stand corrected als ik er naast zit.

Neemt niet weg dat de NAWAS een hele goede oplossing is voor het filteren van DDoS aanvallen.

[InsanelyHack]

Misschien ter aanvulling hoe het een werkt. In onze productarchitectuur lees ik dat er een GENIE ATM-appliance in de keten is opgenomen. Deze staat aan de rand van het netwerk en onderhoudt een GRE-tunnel met de NaWas-scrubbing infrastructuur. De appliance observeert continu het inkomende verkeer en bouwt een baseline van normaal gedrag op. Bij afwijkingen die duiden op DDoS-verkeer, kan de GENIE automatisch een BGP route change initiëren, waarmee het verkeer wordt omgeleid naar de NaWas.

Vanaf dat moment loopt zowel het DDoS-verkeer als het legitieme verkeer via de scrubbing-infrastructuur van NaWas. Daar wordt het kwaadaardige verkeer eruit gefilterd, waarna alleen het geschoonde, legitieme verkeer via de GRE-tunnel wordt teruggestuurd naar de organisatie.

Daarnaast zien we dat sommige organisaties ook DNS-filtering inzetten, bijvoorbeeld via KPN DNS Security, om verzoeken naar kwaadaardige domeinen of command-and-control infrastructuur al vroegtijdig te blokkeren. Dit voorkomt bijvoorbeeld dat geïnfecteerde systemen binnen het netwerk verbinding maken met botnets of malwaredomeinen.

DNS-filtering en DDoS-scrubbing zijn in dit opzicht complementair: DNS werkt preventief op domeinnaamniveau, terwijl NaWas via de GENIE ATM reactief ingrijpt op netwerk- en transportniveau bij volumetrische aanvallen. Samen bieden ze een bredere verdedigingslaag tegen verschillende typen dreigingen.

[The Zep Man]

Daarnaast zien we dat sommige organisaties ook DNS-filtering inzetten, bijvoorbeeld via KPN DNS Security, om verzoeken naar kwaadaardige domeinen of command-and-control infrastructuur al vroegtijdig te blokkeren. Dit voorkomt bijvoorbeeld dat geïnfecteerde systemen binnen het netwerk verbinding maken met botnets of malwaredomeinen.

Het beschermt ertegen maar voorkomt het niet helemaal. Zo worden legitieme diensten (die lastig zijn om te blokkeren) ook wel eens misbruikt om bots te laten communiceren met C&C servers.

[BramVroy]

Wat is de accuraatheid van dat filteren? Ben wel benieuwd wat de precision/recall is. Hoeveel % DDoS'ers haal je eruit? (En hoeveel % legitieme bezoekers gooi je er per ongeluk ook mee uit?)

[AW_Bos]

Volgens mij heb je een eigen AS nodig, en gaat het op BGP niveau. Dus niet zoals bij CloudFlare eventjes je nameservers aanpassen naar die van hun.

Op hun site staat meer informatie.

[Reactie gewijzigd door AW_Bos op 13 juni 2025 09:53]

[nasdude]

Een beheerder kan via BGP het verkeer via NaWas routeren, als je een eigen ASN hebt op bv de AMS-IX of NL-IX etc kun je via hun routeren, het is een flat fee abonnement op basis van /24 reeksen

[InsanelyHack]

Ik vraag me als architect dan direct af of dit voor overheidsgebruik niet nieuwe risico’s introduceert. Hoe zit het met controle op filtering en logging buiten Nederland? En fundamenteel: DDoS-bescherming draait ook om overcapaciteit, als je uitbreiding faciliteert zonder de capaciteit evenredig te vergroten, wordt de dienst minder krachtig. Wordt dan hiermee niet eerder de aanvalsvector verbreed dan de verdediging versterkt?

[Lord Anubis]

Het zit toch in Nederland? Zou dan eerder denken dat het buitenland er een probleem mee heeft als het in Nederland gelogd wordt.
Terzijde vind ik het systeem een goede zet en zo snel mogelijk Europees wijd uitrollen.
Terzijde twee; we moeten van dat polder gedoe af. We gooien alles in ‘the lap of the (tech) gods’ zonder blikken of blozen en dit zou een probleem zijn?

[InsanelyHack]

Het zit toch in Nederland?

De tekst zegt "Dat betekent dat verkeer ook buiten Nederland kan worden gefilterd."
Ik verwacht dat er dus een duplicaat van de dienst in Frankfurt komt. Als het verkeer terug naar Nederland moet voor scrubbing, dan is dat niet alleen duur en inefficiënt bij grote aanvallen, maar ook een zwak punt in de keten. En als het wél in Duitsland gebeurt, dan wil je weten wie daar precies toegang heeft tot logging en configuratie van de dienst.

[LanTao]

Dat is dus niet wat er gebeurt. ERA-IX heeft ook een POP (dus geen heel datacenter!) in Frankfurt. Partijen aangesloten in Frankfurt kunnen dus verkeer via ERA-IX direct aan NaWas overhandigen zonder verdere tussenkomst van transit providers. Als NaWas zelf infrastructuur in Frankfurt op zou bouwen zou het een heel ander persbericht zijn geworden.

[InsanelyHack]

Dan is het dus géén scrubbing in Frankfurt zelf, maar alleen een betere peering via de POP van ERA-IX. Dat betekent wel dat al het verkeer alsnog naar Nederland moet voor filtering. Juist bij grote volumetrische aanvallen lijkt me dat niet ideaal: je verplaatst het probleem dan naar de tussenliggende transitpaden. De aanval raakt je core misschien niet meer direct, maar je uplinks of internationale verbindingen kunnen alsnog vollopen. Vanuit efficiëntie én robuustheid had ik verwacht dat NaWas hier scrubbingcapaciteit had uitgerold. Dit voelt nu meer als routeringsoptimalisatie dan als capaciteitsuitbreiding toch?

[Ayyylias]

Het gaat er om dat netwerken in Duitsland nu de NaWas kunnen gebruiken. Inkomend verkeer blijft via Amsterdam lopen, "de opdracht" om iets te filteren kan dus vanuit Frankfurt komen.

NBIP gebruikt dus de backbone van ERA-IX om de dienst op meerdere plekken te kunnen aanbieden.

[InsanelyHack]

Helder, maar dan blijft het toch bij routeringsbereik in plaats van daadwerkelijke scrubbingcapaciteit op locatie. Dat is nuttig voor bereik en beschikbaarheid, maar het verandert fundamenteel niets aan het DDoS-verdedigingsmodel: het verkeer moet nog steeds via Nederland, met alle risico’s van saturatie op internationale links. Fundamentele principes zoals overcapaciteit aan de rand van het netwerk en scrubbing zo dicht mogelijk bij bron of doel worden hiermee dus niet ingevuld.

Daar komt bij: deze architectuur introduceert extra latency (Frankfurt–NL–Frankfurt), wat bij normaal webverkeer nog acceptabel is, maar bij latencygevoelige workloads (zoals databaseverkeer, real-time API’s, RDP/VPN of VoIP) gewoon niet werkbaar is. Voor dat soort toepassingen heb je lokale filtering nodig, of in elk geval een scrublocatie binnen dezelfde latencydomein. Dit voelt dus meer als een uitbreiding van gebruiksgemak dan als een daadwerkelijke versteviging van weerbaarheid.

Of maak ik een fundamentele denkfout?

[analog_]

Dat verkeer van Nawas DE loopt niet naar NL via public internet natuurlijk maar hun eigen darkfiber/dwdm, je zit daar tegenwoordig aan 16tbit (40x400g) over een duplex linkje, gezien het maar een richtingsverkeer is (de egress loopt via de GRE uit Nederland en is gefilterd kan je dat getal nog eens verdubbelen, en dat is maar 1 dark fiber paartje en dan nog wat redundantie ofcourse.

Binnen europa is ~20 ms voor lisbon/helsinki = 2/3 (glas) * speed of light. Jitter is trouwens een groter probleem.

Ik weet niet of er al 800gbitdwdm is maar ja, next steps.

[Reactie gewijzigd door analog_ op 13 juni 2025 13:03]

[InsanelyHack]

Voor de duidelijkheid: ik ben niet tegen Europese uitrol, integendeel, samenwerking is cruciaal. Mijn punt is: als overheden gebruik maken van een gedeelde infrastructuur, is het wél essentieel om te weten wie de controle heeft, wie toegang heeft tot beheer en logging, en wat er gebeurt bij fouten of misbruik. Dat heeft niets met "polderen" te maken, maar met architecturale scherpte en verantwoordelijkheidsbesef.

[kodak]

Dus als architect weet je hopelijk dat het internetverkeer gebruik maakt van BGP, wat niet ontworpen is om perse zelf controle te hebben. Een protocol wat je waarschijnlijk zelf ook laat gebruiken als je (inter)netwerken ontwerpt om bijvoorbeeld je klanten gebruik te laten maken van belangrijke dienstverlening via het internet? Waaruit het essentieel zijn dan?

Het is meestal belangrijk dat we in een samenleving leven met een balans tussen harde eisen en autonomie. Die verschillende netwerken heten niet zomaar Autonome Systemen. Ze hebben een grote eigen vrijheid om eigen eisen te stellen en eigen beslissingen te nemen. Als je dat niet wil dan zet je een eigen netwerk op, zowel logisch als fysiek. Dat is handig om zelf eisen op te leggen en niet afhankelijk te zijn van andermans diensten of hulp, maar je doelstellingen voor nodige bereikbaarheid ga je daar niet zomaar mee behouden of (terug)krijgen.

Het verkeer kan nu via een buitenlands knooppunt lopen? Dat kon het al. Als je daar moeite mee hebt dan lijkt de discussie niet bedoeld om het over deze uitbreiding te hebben maar over de fundamentele kanten van het internet en BGP.

[InsanelyHack]

Interessant betoog, maar ik denk dat het hier wat uitzoomt op het verkeerde moment. Ik ben me bewust van hoe BGP en autonome systemen werken dat is precies waarom ik dit relevant vind. Zodra we als organisatie actief verkeer omleiden naar een externe scrubbingdienst, dan maken we die dienst expliciet onderdeel van onze beveiligingsketen. Dan vind ik het logisch en noodzakelijk om vragen te stellen over waar het scrubbben gebeurt, wie toegang heeft tot beheer en logging, en wat de impact is op latency en beschikbaarheid bij kritieke workloads. Dat heeft niets te maken met "controle willen hebben over het internet", maar alles met architecturale verantwoordelijkheid over de diensten die wij als overheid leveren.

[kodak]

Vragen wat dienstverleners precies leveren, waar dat uit blijkt, zorgen dat het aan de eigen eisen voldoet en blijft voldoen enz is nmm te algemeen. Daarom gaat mijn antwoord om besef dat als je alleen verantwoordelijkheid probeert te nemen om waar je expliciet voor kiest het de bestaande risico's niet zomaar wijzigt en dus juist ook duidelijk hoort mee te laten tellen. Zeker als je het hebt over controle willen hebben over ongewenste omstandigheden.

Als iemand vooral gaat kijken naar risicos onder omstandigheden die je zelf het beste uit komt dan klinkt het meer als pogingen compliant te zijn. Natuurlijk moet je die risico's ook aandacht geven, maar een nawas bescherming neem je meestal pas af als je zelf onvoldoende de risico's kan beperken en niet zomaar aan de standaard verwachtingen kan worden voldaan. Bijvoorbeeld dat de prioriteiten meer liggen bij kunnen filteren in plaats van dat je zelf nog de gewenste controle hebt. Anders had je het immers zelf wel gedaan.

[InsanelyHack]

Ik zie wat je bedoelt, maar volgens mij draai je het om. Natuurlijk is internetverkeer niet volledig beheersbaar. Maar als je zelf kiest om een externe partij in je beveiligingsketen te zetten, dan moet je juist helder hebben wat dat betekent: waar wordt het verkeer gescrubd, wie heeft toegang, wat doet het met latency. Dat is geen wens tot volledige controle, maar gewoon architectonisch bewustzijn.

Het punt is niet dat alles maakbaar moet zijn, maar dat je weet wat je in huis haalt en welke afhankelijkheden je creëert. Zeker bij een dienst die je inzet omdat je zelf bepaalde capaciteit niet hebt. Dat maakt die vragen juist relevanter, niet overbodig. Als ik hier een recent NaWas overheidsarchitectuurdocument op nasla dan wordt dit ook beschreven als risico.

[kodak]

Het nieuws is dat het verkeer via Duitsland kan worden verwerkt. Maar het kon al via het buitenland verwerkt worden. Dit wijzigt niet zomaar fundamentele werking en risico's.

Als een systeem- of netwerkarchitect met dit nieuws pas gaat bedenken dit soort diensten in geval van nood misschien nodig te hebben en wat de gevolgen zijn dan is dat veel te laat. Dat lijkt meer op het negeren dat het internetverkeer hoe dan ook niet zomaar acceptabel onder controle hebt en dus niet zomaar nog aan de geaccepteerde risico's kunt voldoen waar ontwerp op gebaseerd is.

[InsanelyHack]

Klopt, fundamenteel verandert er niks aan het DDoS-model. Maar dat is juist m’n punt. De uitbreiding wordt gepresenteerd alsof het de weerbaarheid vergroot, terwijl het in de praktijk alleen een routeringsvoordeel oplevert. De bekende risico’s blijven, en zijn ook benoemd in onze overheidsarchitectuurdocumentatie. Juist daarom vind ik het belangrijk om bij dit soort nieuws stil te staan bij wat het wél en niet betekent en dat doe ik niet pas nu, maar juist bewust op het moment dat het als verbetering wordt gebracht. Dan moet je dat kritisch duiden.

[Scriptkid]

Het is de inet side dus dat heb je nooit.

Alle traffic loopt over de hele wereld voor het jouw edge binnen loopt.

[InsanelyHack]

Ik denk dat we elkaar niet helemaal begrijpen. Natuurlijk is het internet inherent open en onbeheersbaar. Maar zodra wij zélf besluiten verkeer af te staan aan een gedeelde infrastructuur zoals NaWas, dan moet je wél scherp zijn op wie daar precies bij kan, hoe beheer geregeld is en wat de risico’s zijn. Dus bewust ketenbeheer zeker als het over overheidsverkeer gaat.

[Aryan Blaauw]

geeft nawas openheid van zaken mbt infrastruktuur en toegang door overheden ?

[Bor]

Waar doel je precies op? De nodige informatie is te vinden op: https://www.nbip.nl/nawas/

Je vindt daar bijvoorbeeld ook:

Lawful Interception & Disclosure (tapdienst)

Aanbieders van openbare telecommunicatiediensten moeten in Nederland voldoen aan de aftapverplichting uit de Telecommunicatiewet. De NBIP Tapdienst neemt de operationele werkzaamheden die met deze verplichting gepaard gaan uit handen voor ruim 100 partijen.

Zie ook: Tapdienst - Lawful Interception & Disclosure

[Aryan Blaauw]

je begrijpt mijn vraag niet - en da's niet erg

wat ik bedoel:

is nawas ondertussen niet een virtuele branch van de AIVD/MIVD en nu de Duitse afdelingen ?
En als dat (niet) zo is wie kan dat / gaat dat borgen ?

*knip*

Admin-edit:

AI link verwijderd.

[Reactie gewijzigd door AlphaRomeo op 13 juni 2025 15:15]

[InsanelyHack]

Dit lees ik terug in een NL overheidsdocument: NBIP opereert als non-profit onder Nederlands recht, wat vertrouwen schept. Maar volledige transparantie over zaken als netwerktopologie, fysieke toegang, logging, auditmogelijkheden of betrokken derde partijen wordt niet standaard geboden zeker niet aan niet-leden. Ook is het niet duidelijk of overheidsorganisaties inzicht krijgen in wie toegang heeft tot scrubbing nodes, hoe logging is ingericht of welke procedures gelden bij buitenlandse verzoeken (bijv. via ERA-IX of BelgiumIX).
De opzet is solidair en technisch doordacht, maar vanuit overheidsoptiek ontbreekt formele borging op controleerbaarheid en compliance. Als we dit serieus als schakel in onze verdediging gebruiken, moeten we ook de vraag durven stellen: hoe blijven we zelf in control, juridisch en operationeel?

[FrostyPeet]

In de NRC van een paar dagen geleden staat een uitgebreid artikel achter een betaalmuur. Ze gaan de diepte in met betrekking tot ddos aanvallen met een uitgebreide analyse over het hoe en op welke wijze. Host diensten worden met naam en toenaam benoemd.

Een van de conclusies is dat de wasstraat niet zo effectief blijkt te zijn. De moderne ddos service schakelt binnen 1 seconde om als de wasstraat een bepaald filter activeert. Vervolgens gaat de aanval gewoon verder.

Aanrader om te lezen, heel begrijpelijke taal. Voorzichtige conclusie, als de grote jongens gaan meespelen met digitale aanvallen lijkt Nederland machteloos.

https://www.nrc.nl/nieuws...toch-de-chinezen-a4896073