Duitse overheid publiceert richtlijnen voor beveiliging routers

Het Duitse Bundesamt für Sicherheit in der Informationstechnik heeft richtlijnen opgesteld om tot een minimumniveau van veiligheid van routers te komen. De overheidsdienst doet een beroep op fabrikanten om ze over te nemen.

Het Bundesamt für Sicherheit in der Informationstechnik richt zich met het document op fabrikanten van routers en somt een aantal verplichte en optionele beveiligingseisen voor routers op. Het gaat niet om hardwarematige vereisten, maar om instellingen en interfaces die de veiligheid moeten vergroten.

Zo beschrijft het document dat de router bij fabrieksinstellingen de toegang tot een gelimiteerde set van basale diensten moet beperken en via de wanpoort moet het aantal beschikbare diensten na initialisatie ook beperkt zijn. Wat wifi betreft schrijft de richtlijn onder andere voor dat wpa2 ondersteund moet worden, hoewel die standaard niet waterdicht is en wpa3 voor de deur staat.

Ook stelt het document eisen aan de aanwezigheid van standaardwachtwoorden voor de instellingen. Dat wachtwoord moet uniek zijn en niet gebaseerd worden op bijvoorbeeld het mac-adres. Bovendien moet de verbinding naar het instellingenmenu via https verlopen. Daarnaast schrijft de BSI voor dat routerfabrikanten ernstige kwetsbaarheden dichten via al dan niet automatische firmware-updates. Ook moeten ze hun klanten inlichten over de periode waarbinnen ze beveiligingsupdates bieden en het moment waarop ondersteuning voor de router eindigt.

De BSI ziet in de Technical Guideline Routers een belangrijke eerste stap naar de invoering van een IT Security-keurmerk, waaraan consumenten kunnen zien of de router aan de minimale beveiligingsrichtlijnen voldoet. De overheidsdienst belooft vergelijkbare documenten voor internet-of-things- en smarthomeapparaten op te stellen.

In Duitsland gaan al langer stemmen op voor een grotere aansprakelijkheid van fabrikanten, vooral na een incident eind 2016 waarbij 900.000 routers van Deutsche Telekom-klanten in storing raakten na een hack.

Reacties (43)

[Freeaqingme]

[...] bovendien moet de verbinding naar het instellingenmenu via https verlopen

Ben benieuwd hoe je dat goed zou moeten doen als fabrikant. Ik kan zo geen goede manier bedenken om op dit soort devices een certificaat te zetten die vertrouwd is door een erkende CA. Daarnaast moet je niet willen dat dit certificaat - als het wel 'officieel' gesigned zou zijn - door derden uit het apparaat geextract kan worden. Ook wil je het dan eigenlijk wel een validity van een jaar of 5 geven.

Aan de andere kant kan je natuurlijk ook een unsigned certificate gebruiken. Is de verbinding weliswaar versleuteld, maar je gaat dan wel weer mensen overtuigen dat ze de melding in hun browser maar even moeten wegklikken.

[Keypunchie]

Het belangrijkste is niet de eerste authenticatie in deze van het apparaat, maar echt de encryptie. Dus daar is self-signed prima voor.

Het scenario is immers: je staat ergens en prikt een ethernetkabel in het apparaat. Je bent er dan best wel zeker van dat je met dat apparaat verbindt (eerst was er geen apparaat, nu wel). Wat je niet wilt is dat er een gecompromitteerd device in het midden (een AP bvb.) tijdens deze aktie kan meelezen en zo de router later kan overnemen en/of dat er vanaf de WAN-zijde uberhaupt onversleuteld verbonden kan worden.

Vervolgens eenmaal aangesloten kun je, zoals AVM dat nu aanbiedt, Let's Encrypt gebruiken voor een 'cloud-based' domeinnaam voor verbindingen vanaf de WAN-zijde. Voor de LAN-zijde helpt dat niet echt, want een certificaat uitgegeven voor pak-em-beet 192.168.0.1 door een Public CA gaat hem niet snel worden, idd.

[Zer0]

De werking van het self-signed certificaat is ook helemaal niet het probleem, het probleem is dat elke browser standaard een self-signed certificaat als onveilig aanduidt, en je mensen dus aanleert om een waarschuwing van de browser te negeren.
Dat het in dit geval geen kwaad kan is niet zo relevant, het probleem is dat ze de volgende keer dezelfde truuk uithalen en op een echt onveilige site terecht komen.

[Goderic]

Maar wat is encryptie zonder authenticatie? Een man-in-the-middle kan gewoon zijn eigen certificaat injecteren en daar gaat je encryptie.

[RobinF]

Ja maar het serienummer van dat certificaat komt niet overeen met het serienummer die het certificaat v/d router heeft, toch?

[leuk_he]

Maar om voor elke router een certificaat te maken en te onderhouden.... Door wie? Hoe?

Er wordt een probleem opgelost dat er niet is.

[jaenster]

Het enige wat ik mij kan bedenken is: Een apparaat die naar huis belt, zodat je enkel bij de router settings kan komen via website van de fabrikant. Dan krijg je dus iets als wifiaccesspointnaam.routermerk.tld met een legit tls cert.

Ik moet er niet aan denken in ieder geval.

[HKS-Skyline]

Dan ben je dus afhankelijk van een internetverbinding om een router in te stellen, lijkt mij op zijn zachtst gezegd zeer onhandig.

[Keypunchie]

10 jaar geleden zou ik het 100% met je eens zijn. Anno 2018, waarbij smartphones met ruime dataverbindingen voorhanden zijn, vind ik het niet eens ondenkbaar of per se onwenselijk.

Het heeft mijn voorkeur niet, voor alle duidelijkheid, maar ik denk niet dat het per se ingewikkeld hoeft te zijn.

Je hebt dan de optie dat je met je smartphone verbind "buitenom", of als er nog instellingen geconfigureerd moeten worden aan de (modem)router voordat hij connectiviteit heeft, dat je ook bijvoorbeeld kan zorgen dat de verbinding eerst juist via je telefoon/laptop, of iets dat al internet heeft gaat lopen. Bluetooth is een simpele optie voor secure connectiviteit, maar ook IPv6 biedt mogelijkheden (alhoewel daar een aantal zelfde security implicaties uit voortkomen)

Voor gebruikers is deze complexiteit best te verbergen in een app.

@wilfredk Dat leg ik toch net uit? Hij kan juist met Bluetooth (of Ipv6) meeliften op je mobiele verbinding.

[Reactie gewijzigd door Keypunchie op 23 juli 2024 09:05]

[HKS-Skyline]

In Nederland hebben we een prima mobiel netwerk, maar vergeet niet dat zelfs in een land als duitsland er genoeg plaatsen zijn waar je geen mobiel netwerk hebt. Laat staan in andere landen waar de mobiele dekking nog veel meer te wensen overlaat. Erg gebruiksvriendelijk is het niet.
Het beste is een mobiele app met encryptie gebruiken en de optie voor een (eventueel minder veilige) webinterface bieden mocht de gebruiker de app niet kunnen installeren.
Want laten we eerlijk zijn, hoe groot is het risico als iemand een nieuwe router installeerd dat er al iemand op zijn zojuist ingeschakelde netwerk zit te snoopen?

[NBK]

Als er 1 ding is wat ik niet wil is het wel voor elke router die ik installeer een nieuwe app te moeten installeren op mijn telefoon. Het is al erg genoeg dat google en de fabrikant van je telefoon je volledig kunnen tracen. Ik hoef daar ook niet nog eens tientallen routerfabrikanten bij te hebben.

En je wil ook niet afhankelijk zijn van een cloudservice. Misschien leuk als extraatje, maar niet afhankelijk. Zolang de fabrikant daadwerkelijk ondersteuning bied kan het wel makkelijk zijn maar zodra de fabrikant failliet gaat of de ondersteuning stopt zit je als gebruiker zonder router.

[HKS-Skyline]

Iemand die verstand van zaken heeft wil doorgaans geen app, maar voor de gemiddelde consument is het toch wel ontzettend veel makkelijker om een qr code op de doos te scannen en de app direct te downloaden of naar de appstore te gaan en de app te downloaden welke vervolgens via bluetooth met de router verbindt en vrijwel automatisch de router insteld. Aangezien iemand met verstand van zaken het zelf in de hand zal willen houden noem ik de "eventueel minder veilige (dus zonder https) webinterface" als secundaire optie.
Deze gebruikers weten tenslotte meestal waar ze mee bezig zijn dus dan is de noodzaak voor https minder groot.

[wilfredk]

En hoe denk jij dat de instellingen bij de router komen voor dat deze internet heeft (hij moet in sommige gevallen namelijk wel eerst ingesteld worden om te kunnen werken)

[locke960]

Nog veel erger, je bent afhankelijk van de servers van de fabrikant. Behalve dat die elk moment kunnen verdwijnen (fabrikant failliet ofzo) is dat een joekel van een veiligheidsrisico. Als die gehacked wordt, of de fabrikant krijgt in een keer vreemde ideeën, dan ben je het haasje.

[84hannes]

Aan de andere kant kan je natuurlijk ook een unsigned certificate gebruiken. Is de verbinding weliswaar versleuteld, maar je gaat dan wel weer mensen overtuigen dat ze de melding in hun browser maar even moeten wegklikken.

Dat heet: mensen een slechte gewoonte aanleren. Lijkt me geen strak plan. Een USB stick meeleveren met het certificaat zodat je die in je browser kan invoeren: ook geen strak plan. Maar in alle eerlijkheid, waarom zou je ook https willen gebruiken binnen je eigen netwerk? Om een man in the middle aanval te voorkomen? Welk middle? Je huisgenoten?

Heb je eigenlijk wel iets aan een certificaat als je je router via een IP-adres benaderd?

[Freeaqingme]

Dat heet: mensen een slechte gewoonte aanleren. Lijkt me geen strak plan

Agree. Dat was ook min of meer mijn punt.

Heb je eigenlijk wel iets aan een certificaat als je je router via een IP-adres benaderd?

In principe kan een X.509 certificaat ook gebruikt worden voor ip-adressen in plaats van hostnames. Ik denk dat er geen CA's meer zijn die dat (mogen) issuen, en al zouden ze dat issuen, dan sowieso niet voor RFC1918 ip-adressen.

Om een man in the middle aanval te voorkomen? Welk middle? Je huisgenoten?

Als je kijkt naar het plaatje lijkt dat inderdaad de intentie te zijn van deze voorschriften. Wellicht dat je de mensen in je huis wel kan vertrouwen, maar dat als er een device gehacked wordt, dat apparaat in theorie (geautomatiseerd) die verbinding kan afluisteren om het zombie netwerk weer verder uit te kunnen breiden.

[slaapkopje]

Er staat in het BSI document "login to access the configuration SHOULD be secured using HTTPS" ... Als in, dat zou eigenlijk moeten. practisch gezien kan dat eigenlijk alleen een selfsigned certificate zijn. Daar zou de CABFORUM wel eens wat aan mogen doen.

IP addressen mogen trouwens wel in een certificate als SAN, maar niet in de commonName en ze moeten als iPAddress en niet als dNSName. Dat schijnt voor oudere Windows versies een probleem te zijn
https://cabforum.org/guidance-ip-addresses-certificates/

[robvanwijk]

Er staat in het BSI document "login to access the configuration SHOULD be secured using HTTPS"

Als (in technische specificaties) woorden als "may", "should" en "must" in all-caps staan, dan wordt daamee verwezen naar RFC 2119:

quote: https://www.ietf.org/rfc/rfc2119.txt

SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

Voor zover ik in kan schatten zou het dus aan de specificatie voldoen om te zeggen "via wifi kunnen we niets garanderen, dus daar bieden we alleen HTTPS aan, maar als je via een netwerkkabel verbindt naar een LAN-poort (wat afluisteren in alle gebruikelijke gevallen ^*) onmogelijk maakt), dan staan we HTTP ook toe".

*) Ja okee, je zult vast wel iets op kunnen zetten waarbij je laptop via (onbeveiligde) wifi verbindt met een oud access point dat je nog had liggen en vandaar met een kabel naar je nieuwe router gaat. Dan kun je ge-MitM'd worden en de router die je aan het configureren bent kan dat niet detecteren.

[NovapaX]

Je kunt de default (interne) DNS van je router toch gewoon myroutersettings.fabrikant.com laten resolven naar het interne adres van je router. En dan een valide certificaat van myroutersettings.fabrikant.com laten serveren?

Dat werkt als het goed is ook zonder internetverbinding. (zolang je apparaat maar met de router verbonden is, deze als primaire gateway gebruikt en ook de DNS van de router gebruikt. Ofwel gewoon via DHCP keurig naar de router luistert)

[Reactie gewijzigd door NovapaX op 23 juli 2024 09:05]

[Xinhood]

Aruba networks heeft dit heel lang gedaan voor de captive portal interface maar dat mag niet meer. Het probleem daarmee is dat je dan op heel veel devices een geldige private key moet hebben waardoor die niet meer private is. De CA die het uitgegeven had heeft het certificaat dan ook ingetrokken.

[uiltje]

OK, maar je zou een intermediate CA kunnen gebruiken en alle modems via een unieke naam kunnen geven - iets met een serie-nummer ofzo. Als je zelf CA bent dan kan je bij de fabricage de private key / certificaat + intermediate mee kunnen geven. Het eerdere genoemde probleem dat het certificaat verloopt heb je daar overigens niet mee opgelost.

Verder wordt je natuurlijk niet zomaar een intermediate CA. En na het grapje van Google om de certificaten van Symantec niet meer te vertrouwen zal dat wel niet "beter" zijn geworden.

[ShellGhost]

5 jaar gaat een dingetje worden: https://www.ssl.com/blogs...aximum-duration-825-days/
Is van drie naar twee jaar gegaan.

[CAPSLOCK2000]

Ben benieuwd hoe je dat goed zou moeten doen als fabrikant. Ik kan zo geen goede manier bedenken om op dit soort devices een certificaat te zetten die vertrouwd is door een erkende CA. Daarnaast moet je niet willen dat dit certificaat - als het wel 'officieel' gesigned zou zijn - door derden uit het apparaat geextract kan worden. Ook wil je het dan eigenlijk wel een validity van een jaar of 5 geven.

LetsEncrypt. Daarmee kan ieder apparaat zelf automatisch een SSL-certificaat aanvragen. De enige vereiste is dat het systeem een echte hostname heeft die gevonden kan worden via DNS. De juiste hostname vinden kan via DHCP of via rDNS. Niet alle providers ondersteunen dat maar dat is relatief eenvoudig op te lossen.

Dan is er wel nog een bootstrap-probleem. Als de gebruiker bv een wachtwoord moet ingeven voordat er verbinding gemaakt kan worden met internet dan werkt LetsEncrypt niet.
Als internet wel direct werkt en het apparaat een geldig SSL-cert krijgt dan is er nog een probleem: de gebruiker moet weten met welk adres hij moet verbinden om op de controlepagina van z'n router te komen.
Er zijn nu al routers (typisch iets met "cloud" in de naam) die via internet configureerbaar zijn. Die werken met een centraal register van de fabrikant waar de apparaten zichzelf registeren. Misschien kunnen de providers ook zo iets doen. Met goede rDNS kan het ook zo simpel zijn als dat je naar https://username.provider.com gaat.

Een andere oplossing is dat je bij de router zelf een CA is en dat je er een USB-stick bij krijgt met het certificaat. Dat installeer je op je eigen PC en dan vertrouw je het zelf-gegenereerde cert van je device.

[johnkeates]

Het is juist kinderspel en ook qua validity wil je het eerder zo kort mogelijk houden zodat een geëxtraheerd certificaat zo kort mogelijk misbruikt kan worden.

Het zou bijv. door middel van Let's Encrypt en dynamic DNS gedaan kunnen worden, of als we puur op de vendor willen vertrouwen door middel van een call naar de vendor om een SAN cert te krijgen met daarin de FQDN's en IP's die vertrouwd moeten worden. Een andere optie is dat de vendor een Intermediate CA wordt, maar dan heb je het probleem dat je de vendor moet gaan vertrouwen en dat is wat lastiger.

Een andere optie is dat de routers een specifieke TLD moeten gebruiken die alleen te gebruiken is voor lokaal verkeer, en dan kan je door middel van een aangepaste let's encrypt hetzelfde doen met een kleinere scope.

Een laatste optie is gewoon HTTP/2 en TLS 1.3 forceren met opportunistic encryption. Voor clients die dat nog niet kunnen kan je een app aanbieden die dat wel kan.

[uiltje]

Helaas gebruiken browsers inderdaad puur op X.509 gebaseerde authenticatie. In principe kan natuurlijk ook een HTTPS / TLS verbinding opgezet worden met Secure Remote Password authenticatie (SRP). Zonder browser implementatie is het echter een dode eend.

[uiltje]

Inderdaad. Er zijn wel technologien zoals SRP of opportunistische versleuteling, maar zonder browser support gaat dat niet helpen. Natuurlijk kan je wel een TLS verbinding opzetten met een client applicatie, maar ik vermoed dat web-pages toch wel de makkelijkste manier zijn om een router te bedienen.

Dus er zijn wel manieren om een verbinding op te zetten zonder certificaten maar het is de vraag of die toepasbaar zijn.

[ajolla]

Waarom niet via USB?

[svennd]

security patches / updates, en duidelijke communicatie hierover zou een serieuze stap voorwaarts zijn.

[BeosBeing]

Wat betreft wifi schrijft de richtlijn onder andere voor dat wpa2 ondersteund moet worden, hoewel die standaard niet waterdicht is en wpa3 voor de deur staat.

Ja dus.. Wpa3 staat voor de deur maar het aantal gecertificeerde apparaten dat al beschikbaar is, dat is minder dan minimaal. Als de eerste op de markt verschijnen zullen ze vooralsnog dusdanig hoog geprijsd zijn dat de gemiddelde consument ze alleen daarom al links laat liggen.

De gemiddelde automobilist rijdt ook niet met een Rolls-Royce en de gemiddelde amateurfotograaf gebruikt ook geen Leaf, Fuji GFX50, Pentax 645, Leica of Hasselblad, zelfs geen Eos 1D of Nikon D5 die maar de helft daarvan kosten of minder.

[Reactie gewijzigd door BeosBeing op 23 juli 2024 09:05]

[CAPSLOCK2000]

Goed bezig daar in Duitsland. Met een beetje geluk pikken wij een graantje mee van de extra security fixes.

Ik denk dat het heel verstandig is dat de overheid zich er mee bemoeit. Je kan niet van consumenten verwachten dat ze zelf kunnen beoordelen of een router veilig is. De meeste IT'ers kunnen dat niet, laat staan gewone burgers. Daarbij is het niet meer dan normaal dat consumenten niet echt met beveiliging bezig zijn en het goedkoopste apparaat kopen dat aan hun wensen voldoet. Fabrikanten die de boel wel beveiligen prijzen zichzelf al snel uit de markt.

Op deze manier wordt voor iedereen de lat hoger gelegd en wordt je er niet op prijs weggeconcurreerd door een bedrijf dat maling heeft aan de veiligheid van haar klanten.

[r2504]

Via de WAN poort moet het aantal diensten beperkt zijn na installatie... nee, het moeten er NUL zijn.

Alles vanaf de WAN kant moet de gebruiker maar expliciet open zetten (en eigenlijk is daar uiterst zelden een reden toe, laat de router fabrikant dan maar standaard een deftige VPN inbouwen).

[Mocro_Pimp®]

Wat ik vooral zorgelijk vind, is dat dit soort richtlijnen eigenlijk gewoon door de markt zelf opgesteld hadden moeten zijn. Of dat nou individueel of in een consortium maakt verder weinig uit. Het laat zien dat je als fabrikant de lat legt hoger hebt zitten dan anderen.

Een beetje zoals Ford ook zelfstandig heeft besloten door standaard gordels te plaatsen.

Triest dat grote groepen invloedrijke mensen weinig voor innovatie gaan mbt beveiliging. Marketing lijkt hier eerder de baas over te zijn.

[borft]

prachtig ook dat het een richtlijn voor routers is, en men vervolgens over WiFi begint...

[wizzkizz]

Consumenten spul is vaak router, switch en WiFi AP geïntegreerd in een enkel kastje dat gebruikers ofwel zelf los kopen ofwel van hun ISP krijgen. Over dat kastje gaat het dus, niet over routers voor professioneel gebruik.

[Olaf van der Spek]

Je vergeet modem nog.

[Geim]

Wat had je dan liever gezien? Dat ze het hele stuk over wifi achterwege hadden gelaten omdat er ook routers zijn zonder Wifi functionaliteit?
"A router MUST offer a Local Area Network (LAN) or WiFi interface to offer access to the Internet for the local user devices in the private network."

[3JL]

Goeie illustratie, nu begrijp ik het!!!

[B00st3r]

Ja, nu begrijp ik dus dat cyberaanvallen altijd door 2 aanvallers tegelijk wordt gedaan!

[well0549]

Goed plan,

We moeten af van die routers waar je standaard met admin admin moet inloggen.....

Voor de rest alles lekker dicht zetten zodat ook de niet Tweaker veilig kan internet bankieren.

En je niet bang hoeft te zijn dat je router gehackt is.

Maar ook printers en alle iot apparaten zouden zo ingesteld moeten worden.

[BushWhacker]

Nu nog toevoegen dat op 2.4 GHz alleen de kanalen 1,6 en 11 op 20MHz gebruikt kunnen worden.
Scheelt denk ik 90% van de WiFi problemen.
Hier in de buurt is het dramatisch. Al die Ziggo/KPN routers/APs gaan vanzelf naar de tussenliggende kanalen, liefst op 2,5,7 en 10, zodat ze lekker veel storing veroorzaken. Misschien willen ze zo bandbreedte besparen.
Mijn buurman moet regelmatig zijn KPN AP weer naar kanaal 11 zetten als hij vanzelf weer eens verspringt.
Ik heb zelf Unifi AP's en die blijven keurig op de ingestelde kanalen staan.