Nieuws
Volg hier ons laatste nieuws.
DNSSEC-inventarisatie 2017: banken en internet-sector lopen ernstig achter
Banken, internet-dienstverleners en de ondernemingen verantwoordelijk voor de datatransport-backbone lopen ernstig achter met de implementatie van DNSSSEC. Uit een inventarisatie van SIDN blijkt dat slechts een heel beperkt gedeelte van de bedrijven in deze sectoren zijn domeinnaam heeft ondertekend.
Banken
Ondanks dat de banken de belangrijkste gebruikers van DNSSEC zouden moeten zijn, scoren zij het slechtst van allemaal. Net als twee-en-half jaar geleden heeft slechts een enkeling (6%) zijn domeinnaam ondertekend. Met het opdoeken van de bankkantoren en het verminderen van het aantal pinautomaten is de online voordeur van de banken steeds belangrijker geworden. Bovendien hebben zij het meest van alle online bedrijven last van phishing, iets waar onder andere DNSSEC in combinatie met DKIM bescherming tegen kan bieden.
Daarnaast verhouden deze bevindingen zich slecht tot de verplichting die de banken zichzelf hebben opgelegd met de deelneming van Betaalvereniging Nederland in de onlangs opgerichte 'Veilige E-mail Coalitie'. Daarbij verklaren deelnemers dat zij in hun eigen organisatie en bij hun achterban zullen werken aan de invoering van onder andere DNSSEC.
Gepubliceerd op 06-03-2017
Overheid en bedrijfsleven richten 'Veilige E-mail Coalitie' op
Overheid en bedrijfsleven gaan gezamenlijk misbruik zoals phishing en het afluisteren van e-mail aanpakken. Daartoe hebben zij vorige maand op initiatief van het Ministerie van Economische Zaken en Forum Standaardisatie de 'Veilige E-mail Coalitie' opgericht.
Deelnemers in de coalitie zijn: PostNL, KPN, Betaalvereniging Nederland, DDMA, Thuiswinkel.org, VNO-NCW, MKB-Nederland, Stichting Zeker-OnLine, Dutch Datacenter Association, Stichting DINL, XS4ALL, Ministerie van Binnenlandse Zaken en Koninkrijksrelaties (Rijks-CIO), Fraudehelpdesk, Nederland ICT en de Belastingdienst. Deze partijen hebben zich verplicht om in hun eigen organisatie en bij hun achterban te werken aan de implementatie van moderne en veilige internetstandaarden: DMARC, DKIM en SPF tegen phishing, en DNSSEC, DANE en STARTTLS tegen afluisteren.
Gepubliceerd op 06-03-2017
Lengte van ZSK-sleutelpaar root zone op 2048 bits
Afgelopen najaar is de lengte van het ZSK-sleutelpaar voor de root zone van 1024 naar 2048 bits gebracht. Dat is gebeurd als onderdeel van de normale, geplande driemaandelijkse rollover. Daarmee heeft het ZSK-sleutelpaar nu dezelfde sterkte als het KSK-sleutelpaar.
Gepubliceerd op 06-03-2017
EPP Key Relay Mapping gestandaardiseerd als RFC 8063
Vorige maand is RFC 8063 'Key Relay Mapping for the Extensible Provisioning Protocol' gepubliceerd als officiële internet-standaard. Deze is ontwikkeld door SIDN Labs en beschrijft een uitbreiding van het EPP-protocol waarmee registrars via de registry (zoals SIDN) direct DNSSEC-sleutelmateriaal kunnen uitwisselen.
Deze uitbreiding was nodig om DNSSEC-ondertekende domeinnamen te kunnen verhuizen zonder daarvoor de beveiliging te hoeven onderbreken. De ontwikkeling van deze standaard heeft vier jaar geduurd en maakt DNSSEC technisch compleet.
Gepubliceerd op 06-03-2017
Tips en trucs voor DANE TLSA
door Wido Potters, BIT
Eind 2016 hebben we bij BIT het DNS-based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol — kortweg TLSA — geconfigureerd voor een aantal hosts. In dit artikel geven we een paar tips voor de implementatie ervan.
Probleem
TLSA is een protocol voor het veilig publiceren van publieke sleutels en certificaten dat voortbouwt op DNSSEC. DNSSEC voegt cryptografische verificatie toe aan het DNS en maakt het daarmee een betrouwbare bron voor certificaateigenschappen. Met DNSSEC is het Domain Name System veilig gemaakt en worden valse antwoorden op vragen aan het DNS voorkomen.
Certificaten worden onder andere gebruikt voor websites die HTTPS (TLS) ingeschakeld hebben. Die certificaten worden verstrekt door certificaatautoriteiten die met veel of weinig moeite controleren of jij wel daadwerkelijk de eigenaar/beheerder bent van de domeinnaam waar je een certificaat voor aanvraagt. Er zijn echter meer dan 100 certificaatautoriteiten die door browsers worden vertrouwd. Een probleem bij een van die autoriteiten kan tot gevolg hebben dat er valse certificaten worden uitgegeven voor grote en kleine sites. Onder andere Comodo en Diginotar hebben in het verleden valse certificaten uitgebracht. TLSA voorkomt niet de uitgifte van valse certificaten maar beperkt wel het gebruik ervan.
Gepubliceerd op 24-01-2017
Roll-over voor root zone vraagt om attentie van DNSSEC-beheerders
Afgelopen najaar heeft ICANN de roll-over van het (KSK) sleutelpaar voor de root zone in gang gezet. Dat betekent dat het cryptografische sleutelpaar dat aan de basis ligt van de hele DNSSEC-infrastructuur wordt ververst (dat wil zeggen vervangen).
Er kleven belangrijke risico's aan deze update. Hoewel de kans daarop klein is, kan een fout betekenen dat het hele internet (inclusief de niet-ondertekende domeinen) onbereikbaar wordt voor alle gebruikers/applicaties die gebruik maken van validerende resolvers.
Hetzelfde speelt op lokaal niveau. Beheerders van validerende resolvers zullen moeten zorgen dat eerst de nieuwe (publieke) sleutel aan de trust anchors op hun servers wordt toegevoegd, en later dat de oude sleutel van hun systemen wordt verwijderd. Laten zij dat na, dan kunnen de digitale handtekeningen onder de top-level domeinen (TLD's) in de root zone niet meer gevalideerd worden. In dat geval zouden alle internet-domeinen voor de gebruikers van de betreffende resolver onbereikbaar worden.
RFC 5011 maakt het mogelijk de nieuwe (publieke) sleutel automatisch als trust anchor te laten installeren. De ontwikkelaars van de meest gebruikte validerende resolvers — PowerDNS, BIND named, Unbound en OpenDNSSEC — geven aan dat hun software dit protocol ondersteunt. De sterk verouderde appliances van Infoblox ondersteunen RFC 5011 niet, waarmee ze hun klanten met een nieuw probleem opzadelen.
Lees hier het volledige artikel
Gepubliceerd op 19-01-2017
Ruim dozijn hands-on artikelen over DNSSEC gepubliceerd
De Duitse security-consultant Johannes Weber heeft de afgelopen maanden (in het Engels) meer dan een dozijn blog postings over DNSSEC geschreven. Naast een hele rits hands-on artikelen over de DNSSEC-configuratie van BIND named beschrijft hij ook de configuratie van DANE, de installatie van de Unbound resolver op de Raspberry Pi, de configuratie van SSHFP-records en het gebruik van een aantal DNSSEC-specifieke tools.
Gepubliceerd op 10-01-2017
Provider XS4ALL zet DNSSEC-validatie volledig aan
Internet-provider XS4ALL heeft vorige week de validatie van DNSSEC aangezet op al zijn caching resolvers. Daarmee zijn alle klanten die de standaard-instellingen gebruiken — en daarmee de DNS-dienst van XS4ALL — beschermd tegen vervalste DNS-records en omleiding van mail- en webverkeer door kwaadwillenden.
XS4ALL valideerde al langer, maar slechts op een van zijn resolvers, waarmee deze security feature tot nu toe alleen experimenteel ondersteund werd. Met deze volledige implementatie volgt XS4ALL in de voetsporen van providers als BIT en Edutel.
Gepubliceerd op 18-11-2016
Beveilig je thuis/kantoor-netwerk met de Valibox
SIDN heeft afgelopen maand de Valibox beschikbaar gemaakt. Dit software-image wordt geïnstalleerd op een generiek hardware-apparaatje, waarmee je in een keer je draadloze thuis/kantoor-netwerk van DNSSEC-validatie voorziet.
De Valibox-software is gebaseerd op OpenWRT en Unbound, en beschikbaar als open source. Er zijn op dit moment images beschikbaar voor drie verschillende devices, maar wie de software geschikt wil maken voor een ander apparaat waarop OpenWRT draait kan contact opnemen met Jelte Jansen.
Gepubliceerd op 20-10-2016
BIND named versie 9.11 brengt diverse verbeteringen voor DNSSEC
Eerder deze maand heeft ISC versie 9.11 van BIND named uitgebracht. Deze release bevat diverse belangrijke verbeteringen op gebied van DNSSEC ten opzichte van de vorige versies:
- beantwoording van queries in real-time op basis van data uit een LDAP back-end via een nieuwe DynDB-interface
- een nieuwe tool voor DNSSEC-sleutelbeheer: dnssec-keymgr. Dit commando bevat een wrapper op de bestaande commando's voor sleutelbeheer en wordt bij voorkeur regelmatig uitgevoerd via cron. Nieuwe sleutelparen worden dan automatisch aangemaakt, gepubliceerd en gerold, en dat alles op basis van een policy in een configuratiebestand.
- De rndc configuratie-tool biedt nu ondersteuning voor de dynamische toevoeging van Negative Trust Anchors (NTA's) zoals gedefinieerd in RFC 7646. Zo kunnen domeinnamen tijdelijk op een whitelist worden gezet in geval van "administratieve ongelukken".
- De optie 'trust-anchor-telemetry' laat named elke dag een speciaal query-bericht (RFC 8145) sturen naar de eigenaars van zones waarvoor een trust anchor is gedefinieerd. Die berichtjes kunnen gebruikt worden als trigger voor een roll-over of het verwijderen van oud sleutelmateriaal.
- De DNSSEC Lookaside Validation (DLV) service van ISC zal volgend jaar gestopt worden. Wie het gebruik van deze dienst heeft geconfigureerd krijgt nu automatisch een waarschuwing.
Gepubliceerd op 20-10-2016
STARTTLS en DANE verplicht voor overheidsorganisaties
Het Nationaal Beraad Digitale Overheid heeft afgelopen maand de beveiligingsstandaarden STARTTLS en DANE op de 'pas toe of leg uit'-lijst gezet. Dat betekent dat overheidsorganisaties vanaf nu verplicht zijn deze standaarden voor de beveiliging van mail-verkeer te implementeren zodra ze hun infrastructuur vernieuwen.
De twee standaarden bouwen voort op de DNSSEC-infrastructuur en voegen een extra cryptografische beveiliging toe aan het TLS-protocol, waarmee mail-servers hun berichten veilig kunnen afleveren.
Zoals te lezen in het 'Cybersecuritybeeld Nederland 2016' had het Nationaal Cyber Security Centrum (NCSC) al aangedrongen op de toevoeging van de STARTTLS/DANE-combinatie aan de ptolu-lijst.
Gepubliceerd op 06-10-2016
PowerDNS Recursor versie 4 ondersteunt DNSSEC-validatie
Met de lancering van versie 4 ondersteunt de PowerDNS Recursor nu ook DNSSEC-validatie. De nieuwe feature is nog experimenteel, maar volgens de ontwikkelaars al goed bruikbaar. Uitgangspunt is dat we opvragingen niet ten onrechte willen weigeren, want dan worden sites en services voor eindgebruikers geblokkeerd.
Validatie door de Recursor stond al veel langer op de agenda, maar heeft moeten wachten op de doorontwikkeling van DNSSEC op de authoritatieve server van PowerDNS. Ook de bescherming tegen DDoS/amplificatie-aanvallen had de afgelopen jaren hoge prioriteit en heeft onder andere geleid tot de ontwikkeling van de dnsdist load balancer.
Juist omdat Nederland wereldwijd voorop loopt met de ondertekening van de .nl-domeinnamen maar achterblijft op de validatie bij Internet Access Providers heeft SIDN de implementatie van validatie op de Recursor financieel ondersteund. Om diezelfde reden werkt de registry ook aan een eigen (validerende) DNS-service, vergelijkbaar met Google Public DNS en OpenDNS (inmiddels onderdeel van Cisco).
Gepubliceerd op 23-09-2016
Greenhost gebruikt KNOT voor ondertekening tienduizend domeinen
Deze zomer heeft hosting provider Greenhost DNSSEC op zijn name servers geïmplementeerd. In totaal heeft het bedrijf circa tienduizend domeinnamen onder zijn hoede, waarvan er zo'n zesduizend onder .nl vallen. Inmiddels zijn 9500 domeinnamen ondertekend, voor alle top-level domeinen waarvoor DNSSEC beschikbaar is. Greenhost is daarvoor van BIND named overgestapt naar de KNOT DNS-server.
Greenhost richt zich van origine op duurzaamheid,
vertelt CTO en eigenaar Mart van Santen. Niet veel later zijn daar digitale privacy en burgerrechten bij gekomen. Vandaar dat wij relatief veel stichtingen, activisten en journalisten als klant hebben. Denk aan Article 19 en Free Press Unlimited. In die context zijn we bewust bezig met de veiligheid en privacy van onze klanten. Zij vragen dan ook geregeld naar specifieke diensten als IPv6, DANE en Let's Encrypt. Wat dat betreft verwachten zij meer van ons dan bij de gemiddelde hoster. Zo werken wij nu aan de implementatie van Let's Encrypt voor alle domeinen. Deze dienst staat gepland voor lancering deze herfst.
Lees hier het volledige artikel
Gepubliceerd op 12-09-2016
Ondersteuning DANE in nieuwe versie OpenSSL
Met de release van versie 1.1 ondersteunt OpenSSL nu ook DANE. Dat betekent dat applicaties die gebruik maken van deze TLS/SSL software library voor het opzetten van hun versleutelde verbindingen de server-certificaten ook (of additioneel) via de DNSSEC-infrastructuur kunnen valideren.
Programmeurs die van deze nieuwe feature gebruik willen maken zullen zelf de betreffende TLSA-records op moeten laten halen (DNS) en valideren (DNSSEC). Vervolgens kunnen deze records bij het opbouwen van een nieuwe versleutelde verbinding worden gebruikt om de server-certificaten te valideren. Afhankelijk van de specifieke toepassing kunnen op dezelfde manier dus ook ingebouwde/lokale trust anchors worden gevalideerd.
Gepubliceerd op 05-09-2016
Ondersteuning van DKIM, SPF en DMARC in Exchange 2016
DKIM, SPF en DMARC — drie DNS(SEC)-gebaseerde protocollen ter bestrijding van phishing, spam, virussen en andere malware — worden inmiddels gedeeltelijk ondersteund door Exchange Server 2016. Alleen voor de ondertekening en validatie van DKIM is de installatie van aparte modules noodzakelijk.
Hoewel de online variant, Office 365, in principe dezelfde software gebruikt als de stand-alone van Exchange, is deze als onderdeel van Exchange Online gekoppeld aan de Exchange Online Protection (EOP) service, die wel volledige ondersteuning van DKIM bevat.
Gepubliceerd op 02-09-2016
DNSSEC-implementatie Infoblox sterk verouderd
Belangrijke aandachtspunten bij het aan zetten van DNSSEC
Twee jaar geleden bespraken we de configuratie van DNSSEC op de Trinzic DDI appliances van Infoblox. De belangrijkste conclusies waren dat het ondertekenen en valideren in de grafische interface erg eenvoudig aan te zetten waren — slechts een kwestie van aanklikken — maar dat de default-instellingen wel dringend verbetering nodig hadden.
Infoblox beloofde destijds bij monde van Chief Infrastructure Officer Cricket Liu om deze zaken in een volgende release aan te passen. Inmiddels zijn we echter twee jaar en een major release verder, en blijkt er helemaal niets te zijn aangepast of toegevoegd. Daarmee zitten Infoblox-klanten met een inmiddels sterk verouderd systeem.
Wie al een Infoblox-system heeft staan en DNSSEC aan wil zetten, zal bij de configuratie daarvan extra aandacht moeten besteden aan de cryptografische default-instellingen van zijn appliance.
Lees hier het volledige artikel
Gepubliceerd op 25-08-2016
OpenDNSSEC 2.0.1: verbeterde upgrade vanaf versie 1.4
Versie 2.0.1 van OpenDNSSEC is deze zomer verschenen. De DNSSEC-software zelf is niet veranderd, alleen de upgrade vanaf versie 1.4 is makkelijker geworden.
Tools
Bestaande gebruikers wordt aangeraden hun OpenDNSSEC-software eerst naar versie 1.4.10 op te waarderen. Vervolgens kunnen zij een van de conversie-scripts in de source directory '.../enforcer/utils/' gebruiken om hun SQLite/MySQL database om te zetten. Na de installatie van de nieuwe database moet nog het commando 'ods-migrate' gerund worden om de conversie af te maken.
De ODS-database wordt alleen intern gebruikt door de Enforcer (ods-enforced), die voor versie 2.0 flink onder handen genomen is. De Signer (ods-signerd) heeft bij deze upgrade geen conversie nodig. Wel moet het interne configuratiebestand '/var/opendnssec/enforcer/zones.xml' de eerste keer handmatig geïnstalleerd worden door het oude bestand '/etc/opendnssec/zonelist.xml' te copiëren.
Zie verder de source file '.../enforcer/utils/1.4-2.0_db_convert/README.md' voor details.
Gepubliceerd op 22-08-2016
"DNSSEC uiterlijk eind 2017 bij alle gemeenten geïmplementeerd"
Zonder veilige basisinfrastructuur geen digitale overheid
Gemeenten moeten DNSSEC uiterlijk eind 2017 hebben geïmplementeerd. Zo schrijft minister Plasterk van Binnenlandse Zaken en Koninkrijksrelaties in antwoord op kamervragen. Hetzelfde geldt voor de andere internet-beveiligingsstandaarden die op de 'pas toe of leg uit'-lijst staan: TLS, DKIM en SPF.
Aanleiding voor de kamervragen was het bericht dat Gemeentelijke e-mail 'gênant slecht' beveiligd
is. Volgens Binnenlands Bestuur blijkt uit een steekproef met e-maildomeinen van vijftig verschillende gemeenten dat slechts drie van hen aan de moderne standaarden voor veilige e-mail te voldoen: Den Haag, 's-Hertogenbosch en Woerden.
Die uitkomsten komen overeen met onze eerdere bevindingen, waaruit ook bleek dat hetzelfde geldt voor centrale overheden.
Gepubliceerd op 30-06-2016
'Key relay'-protocol voor verhuizen DNSSEC-ondertekende domeinnamen gestandaardiseerd
Deze zomer wordt het 'key relay'-protocol officieel gestandaardiseerd door de IETF. Dat betekent dat deze zal worden gepubliceerd als Internet Standard RFC.
Het 'key relay'-protocol is een noodzakelijk onderdeel voor het veilig verhuizen van DNSSEC-ondertekende domeinnamen tussen verschillende registrars. Om dat zonder onderbreking van de beveiliging te kunnen doen, moet een uitwisseling van sleutelmateriaal plaatsvinden. De bovenliggende registry is dan de aangewezen partij om dit voor zijn registrars te faciliteren.
Gepubliceerd op 23-06-2016
SIDN rolt KSK-sleutels van .nl-domein
Vorige week heeft SIDN het KSK-sleutelpaar voor het .nl-domein "gerold". Dit sleutelpaar vormt de cryptografische basis voor alle met DNSSEC beveiligde .nl-domeinnamen. De ingebruikstelling van een nieuw sleutelpaar verloopt dan ook volgens een strikt veiligheidsprotocol — de ceremonie — die de betrouwbaarheid van de DNSSEC-infrastructuur moet garanderen.
Het oude KSK-sleutelpaar is al in 2010 in gebruik genomen, met de onofficiële introductie destijds van DNSSEC in Nederland. Dit sleutelpaar moest uiterlijk binnen zes jaar — dat wil zeggen voor december van dit jaar — vervangen worden.
Gepubliceerd op 14-06-2016
