Open standaarden

Al in de jaren negentig werd duidelijk dat het aantal IPv4-adressen ooit zou opraken. Daarom is men sinds 1998 begonnen met de uitrol van IPv6, dat een veel grotere adresruimte biedt. Beide protocollen dienen naast elkaar gebruikt te worden. Uiteindelijk zal, mede door schaarste, het IPv4 gebruik afnemen. Websites zonder IPv6 zijn dan niet langer bereikbaar.

DNS vertaalt een domeinnaam naar een IP-adres van de server waar een website host. Op onveilige netwerken kan deze vertaling worden onderschept en vervalst. DNSSEC voorkomt dit door middel van digitale ondertekening, waarmee een computer kan verifiëren of een DNS-vertaling legitiem is.

Tegenwoordig wordt een beveiligde verbinding (HTTPS) als vanzelfsprekend gezien; browsers gaan hier van uit. Let bij de implementatie van TLS (voorheen SSL) wel goed op het gebruik van een moderne versie: TLS 1.2 of 1.3. Oudere versies zorgen ervoor dat browsers waarschuwingen tonen of de site helemaal niet laden. Een uitgebreide test kan via ssllabs.com/ssltest worden uitgevoerd.
Ook het instellen van HSTS is belangrijk: deze header dwingt browsers altijd de beveiligde verbinding te gebruiken. Zonder deze forcering kunnen gevoelige gegevens, zoals username en wachtwoord, alsnog onveilig worden verzonden en worden onderschept.

Niet alle beveiligings opties op internet.nl zijn verplicht, en een website kan prima functioneren zonder. Toch bieden ze waardevolle bescherming, vooral wanneer er iets mis gaat. Zo voorkomt de X-Frame-Options header dat je website wordt weergegeven in een frame op een andere site. De Content-Security-Policy bepaalt vanaf welke bronnen content mag worden ingeladen op een website. Bij een slechte post of hack voorkom je dus kwaadaardige content dat elders is gehost. Met de Referrer-Policy bepaal je of, en welke, informatie wordt meegestuurd naar websites die door gebruikers na jouw site worden bezocht. Vreemd dat dit gebeurt? Het is (helaas) standaard gedrag van browsers. Door deze instelling te beperken (bijvoorbeeld met no-referrer of same-origin) vergroot je de privacy van bezoekers.

Voor wie meer wilt weten over deze security headers en de mogelijke opties, hebben wij een blog geschreven over de vijf meest gebruikte security headers.

Deze beveiligingsstandaard krijgt steeds meer aandacht en is verplicht voor publieke organisaties. Het betreft een txt bestand die je plaatst bij je website. Hierin staan de contactgegevens waar een eventuele hacker of onderzoeker melding kan doen van kwetsbaarheden op de website. Dit bestand moet voldoen aan een vast format en kun je idealiter centraal beheren voor al je klanten en websites.

Als ontwikkelaar heb je op dit punt wellicht de minste directe invloed: het is aan je hostingpartij om route-autorisatie via RPKI op orde te hebben. Dit voorkomt dat internetverkeer naar zijn servers kan worden omgeleid door kwaadwillenden. Gelukkig hebben de meeste hostingproviders dit onderdeel tegenwoordig goed op orde.

Ook voor e-mailverkeer gelden standaarden. Als je deze niet implementeert, heeft dit vrijwel altijd impact op het kunnen afleveren e-mail aan ontvangers. Berichten komen direct terecht in de SPAMfolder of bereiken de ontvanger helemaal niet. De e-mailtest op internet.nl laat zien dat ook hier het gebruik van IPv6, DNSSEC, TLS en RPKI vereist is. Daarnaast spelen DMARC, DKIM en SPF ook een essentiële rol.

Met SPF specificeer je via een DNS-record welke servers (IP-adressen) gemachtigd zijn om e-mail te verzenden namens een domeinnaam. Hierin benoem je, logischerwijs de e-mailserver van de organisatie, maar bijvoorbeeld ook een webserver, mailingsysteem en facturatiesysteem. Ontvangers beoordelen een bericht negatief als de verzendende mailserver niet via SPF is vrijgegeven, met een hoge kans dat het bericht als SPAM wordt gemarkeerd.

DKIM biedt een methode om te verifiëren of de afzender van een e-mail ook daadwerkelijk de eigenaar is van het domein. Als eigenaar van een domeinnaam publiceer je een publieke DKIM-sleutel via een DNS-record. De uitgaande mailserver krijgt een private DKIM-sleutel waarmee hij ieder e-mailbericht kan ondertekenen. Alle ontvangende mailservers controleren vervolgens of de DKIM-handtekening van een e-mailbericht past bij de gepubliceerde sleutel in de DNS van een domeinnaam. Klopt dit niet, dan wordt het bericht als SPAM gezien.

DMARC stelt je in staat om via DNS instructies te geven over wat een ontvangende mailserver moet doen als SPF en/of DKIM-checks falen. Je kunt als eigenaar bijvoorbeeld aangeven dat berichten die niet slagen voor deze controles moeten worden geweigerd of gemarkeerd. Daarnaast biedt DMARC de mogelijkheid om rapportages te ontvangen over het e-mailverkeer dat namens jouw domein wordt verzonden, zodat je verdachte activiteiten kunt monitoren.

DKIM biedt een methode om te verifiëren of de afzender van een e-mail ook daadwerkelijk de eigenaar is van het domein. Als eigenaar van een domeinnaam publiceer je een publieke DKIM-sleutel via een DNS-record. De uitgaande mailserver krijgt een private DKIM-sleutel waarmee hij ieder e-mailbericht kan ondertekenen. Alle ontvangende mailservers controleren vervolgens of de DKIM-handtekening van een e-mailbericht past bij de gepubliceerde sleutel in de DNS van een domeinnaam. Klopt dit niet, dan wordt het bericht als SPAM gezien.