Auteur: internetcleanup-foundation

Nieuwe meting: Overheids-niveau TLS (juli 2023)

Met de verplichting van TLS voor de overheid, wordt vanaf nu ook de internet.nl TLS meting meegenomen. Deze meting verschilt van de andere metingen rondom TLS en HSTS op basisbeveiliging. In dit artikel staan de verschillen.

Het eerste rapport met deze meting staat live op 4 juli 2023.

De nieuwe meting

De nieuwe meting wordt geintroduceerd als oranje. Hoewel het een wettelijke verplichting is, en alles zegt dat dit rood zou moeten zijn, beginnen nieuwe metingen volgens ons publicatiebleid altijd ten hoogste op oranje.

We houden deze meting nog op oranje totdat is uitgekristaliseerd hoe de handhaving werkt, dat er wordt gehandhaafd en of er eventuele uitzonderingen ontstaan de komende tijd. Deze meting wordt op dit moment alleen uitgevoerd op hoofd-domeinen.

De meting wordt verder toegelicht met de volgende bronnen:

Deze meting omvat 20 sub-metingen die soms wel en soms niet relevant zijn. Deze afzonderlijke punten publiceren we niet, om zo de lezer van de site niet te overladen met metingen. Het testrapport is te zien op internet.nl, volg daarvoor de link bij “show measured data” zoals in het screenshot hieronder.

Screenshot van de meting op het niveau oranje

Anders dan de huidige TLS/HSTS metingen

Zoals gezegd: Op basisbeveiliging testen we al HSTS en TLS. Maar toch is deze meting anders.

De andere TLS meting is afkomstig van Qualys SSL Labs. Deze commerciele partij gebruikt dit als marketingstool voor hun dienstverlening. Deze meting past niet hetzelfde beleid toe als het NCSC, maar een algemener beleid. Er zijn twee belangrijke meetwaarden in SSL Labs die niet uit de meting van internet.nl komen, namelijk:

  1. Of er specifieke en state of the art kwetsbaarheden aanwezig zijn in de verbinding. Regelmatig komen er nieuwe uit die voor veel problemen zorgen. Een bekend en wat ouder voorbeeld is Heartbleed, maar zo zijn er nog 10.
  2. Of er vertrouwen is in het certificaat. Zijn de naam, tijd, geldigheid, CA, revocation nog op orde.

De HSTS meting van basisbeveiliging is ook anders. Wij volgen namelijk redirects, waar internet.nl dat expliciet niet doet. Voor een goede HSTS meting zou iedere stap in de ketting aan redirects HSTS moeten hebben, maar dat meten we op dit moment niet: alleen de laatste. Deze twee HSTS metingen vullen elkaar nu dus aan.

Eigenaar van 8% overheidsdomeinen onduidelijk (Mei 2023)

Bij 8% van de overheidsdomeinen is het niet te achterhalen of de overheid eigenaar is. Dat is te verdelen in twee categorien: er zijn 95 domeinen zonder informatie en 68 domeinen met een onjuiste eigenaar.

Juiste houderinformatie geeft vertrouwen: iemand kan hierdoor checken of de site eigendom is van de overheid. De overheid heeft nog een andere reden om eigenaar te zijn: zelf bepalen wat er met een domein gebeurt nadat een project of contract afloopt.

Dit is het overzicht van eigendom van domeinen op dit moment:

OverheidDomeinenGeen eigenaarOnjuiste eigenaarJuiste eigenaar
Gemeenten431328391
Provincies132011
Overheid154661601425
TOTAAL199095 (4.77%)68 (3.41%)1827 (91.81%)
Overzichtstabel juistheid houders van domeinen.

Houder van een domein

Iedere domeinnaam is uniek en heeft een eigenaar. De adminstratie van alle .nl domeinen zoals rijksoverheid.nl wordt bijgehouden door “Stichting Internet Domeinregistratie Nederland”: SIDN.

Om te zien wie eigenaar is van een domein kan je op de site van het SIDN de administratie doorzoeken. In het onderstaande voorbeeld zie je het zoekresultaat voor de site “rijksoverheid.nl”.

Screenshot met de houdergegevens van rijksoverheid.nl. Je kan dit zelf proberen op de site https://www.sidn.nl/nl-domeinnaam/domeinnaam-zoeken/

In het screenshot zit een highlight op de informatie uit het “houder” veld: “Rijksoverheid”, dit is de naam van de eigenaar van het domein.

De nieuwe meting op basisbeveiliging.nl controleert of de eigenaar van het domein juist is. Hieruit kunnen drie conclusies komen:

  • Geen eigenaar: het is niet te zien van wie het domein is omdat het “Houder” veld leeg is. Dit wordt beoordeeld met Oranje.
  • Onjuiste eigenaar: een tussenpartij, een persoon, een onduidelijke organisatie of een geanonimiseerde organisatie (en nog wat andere gevallen) is allemaal onjuist. Dit wordt beoordeeld met Oranje. Wij verwachten dat “Gemeente Texel” eigenaar is van “texel.nl”.
  • Juiste eigenaar: Is de registratie in te zien en behoort die tot een van de goedgekeurde organisaties? Dan wordt dat beoordeeld als Groen.

Bepaling van de meting

Het is lastig om te bepalen wie de juiste eigenaar is. Dat gebeurd dan ook voor een deel met de hand. Dit is een detail-overzicht van hoe we de juiste eigenaar vaststellen.

In deze gevallen zien wij de juiste eigenaar:

  • De houder is ongeveer hetzelfde als het domein. Bijvoorbeeld “rijksoverheid” op “rijksoverheid.nl”.
  • De houder is een overheidsorganisatie, ziekenhuis of andere aanverwante entiteit.
  • De houder is een bedrijf/organisatie en deze staat genoemd op de voorpagina van de site of onder contactgegevens. Bijvoorbeeld in het e-mail adres of bij de copyright informatie.
  • Sites met een rijksoverheidslogo mogen alleen op een naam van een overheid staan.
  • De houder bestaat uit een onbekend deel, maar ook een bekend deel zoals: “TweeToffePeren B.V. i.o. Rijkswaterstaat” op een site van Rijkswaterstaat.
  • Bij onduidelijkheden wordt altijd kort gezocht naar wie de eigenaar is. Bijvoorbeeld kan bij ICT-samenwerkingsverbanden de gebruikte naam niet direct worden herleid omdat er een “abstracte” naam wordt gebruikt waar geen van de deelnemers wordt genoemd.

In deze gevallen zien we een onjuiste eigenaar:

  • Bedrijfsnaam van een ontwikkelbedrijf, consultancybedrijf, juristenbureau of andere ontwikkelaar. “TweeToffePeren B.V.” terwijl de site zegt: Rijkswaterstaat.
  • Namen van personen.
  • Afgeschermde gegevens. Houder hoeft niet afgeschermd te zijn omdat het altijd gaat over namen van organisaties.
  • Namen van organisaties die geen of ‘generieke’ resultaten hebben in zoekmachines. Het is dus niet duidelijk van wie het is.
  • Onherleidbare informatie als “Crediteurenadministratie X-12391”.
  • Een leeg veld.
In dit voorbeeld staat dat de eigenaar onbekend is. Er staat “Privacy protected by Hostnet”. De juiste houder zou “Trimbos-Instituut” kunnen zijn, of een andere organisatie in dezelfde strekking.

Dank aan SIDN

Informatie over eigenaarschap is afkomstig uit de WHOIS database van Stichting Internet Domeinregistratie Nederland (SIDN) en wordt verwerkt en gepubliceerd met toestemming.

Je kan controleren van wie een domein is op de volgende pagina: https://www.sidn.nl/nl-domeinnaam/domeinnaam-zoeken/

Bij iedere meting wordt verwezen naar het WHOIS register van het SIDN als second opinion.

De Helpdesk, aflevering 4 – “gesloten” poort en G1 certificaten

In de helpdesk kijken we naar vragen die binnenkomen via de mail en geven we een kort antwoord op vragen die vaker binnenkomen.

Poort 8080 is gesloten (of toch open)

We kregen een korte mail met de melding: “Poort 8080 staat niet open”. Dus wij tikken in onze browser: http://[gemeentesite].nl:8080. In plaats van ‘geen gehoor’ wordt de gebruiker doorgestuurd naar de site van een gemeente. Daarna proberen we de site http://[gemeentesite].nl:9090, en daar gebeurd niets.

Conclusie: op poort 8080 gebeurd wel iets, dus deze poort staat open met iets overbodigs. We kunnen niet zien wat en of dit een uitzondering waard is. Dus de conclusie ‘overbodige poort’ blijft staan.

Screenshot bij het bezoeken van het hoofd-domein op dit adres op :8080. De melding op deze pagina zegt dat je mogelijk iets bijzonders moet hebben gedaan om geblokkeerd te worden. Daaronder valt dus ook gewoon bezoeken 🙂

Fix voor uitzondering G1 certificaten

De overheid geeft een certificaat uit dat by design niet wordt vertrouwd in browsers. Dit is het G1 certificaat. We hebben al wat jaren code in Basisbeveiliging die hiervoor een uitzondering toevoegt. Of… dat dachten we.

We ontvingen een mailtje met de vraag of we een G1 certificaat konden uitzonderen. We hadden zoiets van: dit doen we toch al?

Dit was het begin van een paar uur lang debuggen. Uit de logs konden we halen dat deze uitzondering is aangeroepen na de ‘niet vertrouwd’ conclusie van de TLS meting. We hebben de code erbij gepakt en het met de hand aanroepen van alle functies ging goed.

We hebben de code lokaal en op de server gedraaid als allerlei gebruikers: werkt altijd. We hebben extreem gedetailleerde logging toegevoegd aan deze code en we zagen dat alleen op de server, tijdens het meten via een worker, een specifieke SSL foutmelding optrad.

De conclusie is dat een van de componenten om parallel te kunnen meten (“gevent” voor de nerds) de SSL bibliotheek aanpast wat kan zorgen voor ander gedrag. Nadat we de worker hadden omgezet naar ‘prefork’ zagen we dat het probleem was opgelost.

We hebben deze taak dus overgezet naar een prefork worker. Dat kost wat meer geheugen maar dan hebben we wel zekerheid dat de meting goed gaat.

Inmiddels is de helft van de uitzondering-checks er doorheen en zijn er 83 G1 certificaten gevonden. We zien dit certificaat o.a. op sites als api.kvk.nl, isb.rdw.nl, en data.* subdomeinen van gemeenten.

Overzicht van uitzonderingsmetingen op het domein van de vraagsteller…

De Helpdesk, aflevering 3 – Diensten voor medewerkers en onjuiste header metingen

In de helpdesk kijken we naar vragen die binnenkomen via de mail en geven we een kort antwoord op vragen die vaker binnenkomen.

Dienst voor medewerkers via het open internet

Een organisatie die graag mailtjes stuurt maakt gebruik van een standaardpakket. Medewerkers kunnen op die omgeving inloggen en de nieuwsbrieven opstellen.

Wij raden aan om dit soort diensten niet publiek te zetten: die vraag was voorgelegd aan de hoster. De hoster geeft aan bang te zijn om deze aanpassing door te voeren. Het zou meer problemen leveren dan het oplost. Dus ze gaan dat niet doen.

Oplossing: In dit geval zien we een Plesk PHP omgeving staan. Beiden zijn bekend en geroemd om hun vele kwetsbaarheden. Dat betekent voor een aanvaller: “Rustig wachten op de dag… van een nieuwe kwetsbaarheid… van een nieuwe kwetsbaarheid“. Dan kan IT weer fijn in het midden van de nacht / carnaval stekkers ergens uit halen, patchen, datalekmeldingen sturen enzovoorts. All in a good days work: maar je kan ook kiezen voor nachtrust, een goede reputatie en een stabiele dienstverlening.

Het is alsof je een deel van de interne organisatie buiten het gebouw naast de ingang zet. In plaats van binnen met verwarming, een beveiligingspoortje en een receptie. Iedereen kan er naartoe lopen en proberen binnen te komen: via gokken op het loginformulier of via een (nieuwe) kwetsbaarheid. Net zoals je bij een bedrijf een veiligheidspoortje hebt, wil je voor de toegang tot dit soort diensten altijd een controle uitvoeren.

Daar is in dit geval ook wel een poging tot gedaan. In plaats van de dienst op het standaard poort 443 aan te bieden, word deze “verborgen” op poort 8443. Dat soort security through obscurity werkt vertragend, maar uiteindelijk niet.

Er zijn diverse manieren om diensten te verbergen voor de buitenwereld. Het mooiste is achter een VPN, waarbij er publiek niets meer te vinden is. Een medewerker logt in op het deel VPN en kan dan naar mailing.intern.belangrijkeorganisatie.nl gaan om het werk te doen. Het is ook mogelijk om toegang op basis van certificaat of IP in te richten: dan kan een buitenstaander zien dat er nog wel *iets* is, maar niet meer wat. Dat is natuurlijk minder mooi en uiteindelijk ook meer werk. Er zijn vast nog wel andere oplossingen te bedenken. Wij gaan altijd voor de optie om zo min mogelijk diensten over het open internet aan te bieden.

Onjuiste header meting

We kregen de melding dat we onterecht bevinden dat bepaalde http security headers ontbreken. We gingen op onderzoek uit.

Oplossing: Hier hebben we inderdaad een fout gemaakt. We stuurde een “Host” header mee, maar hielden geen rekening met dat we konden worden doorgestuurd. Dat betekent dat we de verkeerde site (“Host”) opvroegen nadat we werden doorgestuurd naar een andere site.

We hebben dit aangepast.

Ook zagen we dat we http headers aan het meten waren op sites als http://example.nl:443. Dan sturen we dus met opzet een onversleuteld verzoek naar een versleutelde pagina. Een gemiddelde webserver geeft dan een behulpzame waarschuwing dat dit niet is wat je wil. Om ook daar op headers te controleren gaat wel erg ver, dus dat hebben we even uitgezet. We kijken daar wel naar andere dingen zoals versienummers bijvoorbeeld.

De Helpdesk, aflevering 1 – Intrusion attacks en beheer op een vreemde poort

In de helpdesk kijken we naar vragen die binnenkomen via de mail en geven we een kort antwoord op vragen die vaker binnenkomen.

Intrusion attacks bij bezoeken site…

De eerste vraag gaat over een firewall. Deze ziet een intrusion attack als we de website bezoeken via http://. Het verkeer via https werd geweigerd. Dus basisbeveiliging ziet alleen een blokkade-website en dat is niet de site die de beheerder verwachtte.

Oplossing: Als je niet gemeten wil worden, dus bijvoorbeeld ip-restricties toepast, dan moet je dat op alle endpoints doen: ook op http://. Ons vermoeden: De firewall herkent ons gewone bezoek niet als een bekend IP, dus blokkeert dat als ‘intrusion’. Maar we zouden deze website helemaal niet mogen zien natuurlijk, want het is maar een gewoon websitebezoek.

Fortinet firewall blokkeert bezoek aan http:// website

Beheer op een vreemde poort

De tweede vraag ging over een vreemd poortnummer. We geven daar een oranje beoordeling aan. De hoster van de site gebruikte dit poortnummer om beheer uit te voeren via het plesk beheersysteem.

Oplossing: Voor iedere vorm van beheer (van overheidssites) raden we een VPN/afgescheiden netwerk aan. Hierdoor is zo’n beheerpanel niet meer bereikbaar via het publieke internet: dus veel minder mensen die het kunnen vinden en er een aanval kunnen uitvoeren. Er zijn natuurlijk regelmatig kwetsbaarheden in dit soort beheerpanelen: ze geliefd door aanvallers.

Op de schermprint zie je geen 2e factor, wat wel gebruikelijk is voor beheerpanelen. Het kan natuurlijk zijn dat je die vraag pas krijgt nadat je een inlogpoging hebt gedaan… of niet.

Plesk inlogpaneel op een vreemd poortnummer

Lubach bezoekt 1800 overheidssites, gelukkig is er nog veel meer!

In deze afgelopen uitzending van de Avondshow met Arjen Lubach wordt het enorme aantal overheidswebsites besproken. Onderzoeker Tex heeft gedaan wat menselijk mogelijk was: alle 1800 sites bezoeken en drie maanden geen daglicht gezien. Dat kon nog in tijden van corona. We weten hoe het voelt.

Het doel was om het antwoord te vinden op een simpele vraag. Maar het kan zijn dat je zelfs na het bezoeken van al deze sites geen antwoord hebt. We zien namelijk dat ieder van die sites gemiddeld zo’n 10 “subdomeinen” heeft met informatie en dienstverlening voor specifieke doelgroepen.

De 1800 sites die zijn bezocht door Tex staan in het websiteregister rijksoverheid. Wat daar niet in staat zijn de sites van gemeenten, provincies, waterschappen, regionale samenwerkingsverbanden (bijvoorbeeld het afvalverwerkingsbedrijf enzo) en alle semi-overheidsbedrijven.

Maar hoeveel sites zijn er dan? Dat weten we ook niet precies: dat weet niemand. In onze database staan zo’n 90.000 adressen, waarvan het ruime overgrote merendeel van de overheid is. Wekelijks komen er meer bij.

Waarom weten we dit?

Wij meten al deze sites op veiligheid. Dat doen we niet meer met menselijke onderzoekers, maar met een heel leger aan hamsters in luxe kooitjes. Zij bezoeken regelmatig de sites om te kijken of ze voldoen aan bijvoorbeeld de basis veiligheidsafspraken.

De resultaten daarvan worden dagelijks gepubliceerd op https://basisbeveiliging.nl.

Onderzoeker Tex die de 1800 sites laat zien tijdens de Avondshow met Arjen Lubach. Beeld van de VPRO via YouTube.

Nieuwe metingen (februari 2023) – Security.txt, RPKI

Security.txt

We kijken en publiceren nu ook metingen over security.txt. We beoordelen deze op drie manieren:

  • Aanwezig: dan is het goed
  • Ontbreekt op een subdomein: dan krijg je een info score (dit is nu groen). Eigenlijk hoort security.txt op alle domeinen en subdomeinen beschikbaar te zijn, maar dat is een klus. Dus we beoordelen alleen het ontbreken op het hoofddomein nu als onvoldoende (oranje).
  • Ontbreekt op domein: je krijgt dan een oranje score. Het niet hebben van een security.txt bestand betekent dat je kritieke informatie over kwetsbaarheden kan missen. Het samenstellen van een security.txt bestand kan o.a. door dit formuliertje in te vullen. Zet dan het bestand op je webserver. We meten dit elke paar dagen. Het oplossen hiervan is vooral procesmatig (wie krijgt de meldingen), het maken en plaatsen van een tekstbestandje is een kwetsie van een paar minuten en een kleine wijziging.

Deze nieuwe meting komt van internet.nl, en is ontwikkeld door dcypher en internet.nl.

RPKI Aanwezigheid

We kijken nu of RPKI aanwezig is voor webservers en e-mail diensten. We beoordelen dit op de volgende manieren:

  • Aanwezig: we keuren het goed. Andere RPKI metingen tonen we niet, het kan dus zijn dat de geldigheid is verlopen of dat de RPKI naar de nameserver niet juist is. Met deze ene meting proberen we het belangrijkste resultaat te vatten. Als iedereen dit goed doet, dan kunnen we de volgende aanzetten.
  • Afwezig: we keuren het als ‘middenmoot’ dus oranje. RPKI is kritiek voor een veilig internet, maar een organisatie kan naast melden/waarschuwen niet direct actie ondernemen omdat de organisatie niet geheel verantwoordelijk is voor het onderliggende internetverkeer. Een organisatie kan wel kiezen om naar een andere hoster te gaan bijvoorbeeld: maar het is makkelijker als groep klanten druk uit te oefenen om dit gewijzigd te krijgen.

Deze nieuwe meting komt van internet.nl, en is ontwikkeld door het Nationaal Cyber Security Centrum (NCSC) en internet.nl.

Zo zien de resultaten eruit

Een niet geslaagde test voor security.txt op het hoofddomein.
Een geslaagde RPKI meting