E-mail & DNS Hardening

Rechten Omlaag, Controle Omhoog

Aanvalspaden worden klein zodra rechten, segmenten en beheerkanalen consequent zijn ingericht.

Voor E-mail & DNS Hardening blijft de basis hetzelfde: minder impliciet vertrouwen en meer zicht op afwijkend gedrag.

Zo beperk je niet alleen de kans op incidenten, maar vooral ook de omvang en duur als er iets misgaat.

Directe maatregelen (15 minuten)

• Start met MFA, least privilege en tiering voor beheeraccounts.
• Voer segmentatie en expliciete firewallregels door op kritieke paden.
• Borg logging, detectie en hersteltests als structurele operatie.

Waarom dit telt

De kern van E-mail & DNS Hardening is risicoreductie in de praktijk. Technische context ondersteunt de maatregelkeuze, maar implementatie en borging staan centraal.

SPF (Sender Policy Framework)

SPF is het eerste mechanisme dat voorkomt dat aanvallers e-mails versturen namens jouw domein. Het werkt simpel: je publiceert een DNS TXT-record dat beschrijft welke mailservers namens jouw domein mogen verzenden. De ontvangende mailserver controleert of de afzendende server in dat lijstje staat.

Hoe SPF werkt

De afzender stuurt een e-mail, de ontvangende server doet een DNS TXT-lookup op het domein van de envelope-from, en controleert of het IP-adres van de afzender in het SPF-record staat. Resultaat: pass, fail, softfail, of neutral.

example.com.  IN  TXT  "v=spf1 <mechanisms> <qualifier>all"

Mechanisms

Qualifiers

~all vs -all

Het verschil is cruciaal:

# Soft fail -- verdachte mail wordt nog steeds afgeleverd (vaak in spam)
example.com.  IN  TXT  "v=spf1 include:_spf.google.com ~all"

# Hard fail -- niet-geautoriseerde mail wordt geweigerd
example.com.  IN  TXT  "v=spf1 include:_spf.google.com -all"

Gebruik altijd -all in productie. ~all is bedoeld als tijdelijke instelling tijdens de uitrol, niet als permanent beleid. Toch draaien de meeste organisaties jarenlang op ~all omdat “het werkt” en niemand het ooit aanpast.

Voorbeelden voor veelgebruikte setups

Office 365:

example.com.  IN  TXT  "v=spf1 include:spf.protection.outlook.com -all"

Google Workspace:

example.com.  IN  TXT  "v=spf1 include:_spf.google.com -all"

Self-hosted (Postfix op 203.0.113.25):

example.com.  IN  TXT  "v=spf1 ip4:203.0.113.25 mx -all"

Gecombineerd (O365 + marketingtool + eigen server):

example.com.  IN  TXT  "v=spf1 include:spf.protection.outlook.com include:mail.marketingtool.com ip4:203.0.113.25 -all"

Veelgemaakte fouten

• Te veel DNS lookups: SPF staat maximaal 10 lookups toe (include, a, mx, exists, redirect). Overschrijd je dit, dan faalt de hele SPF-check. Gebruik ip4/ip6 waar mogelijk.
• Te permissief: v=spf1 +all autoriseert de hele wereld om namens jouw domein te mailen.
• Geen SPF voor subdomeinen: Aanvallers gebruiken subdomeinen zonder SPF-record voor phishing.

DKIM (DomainKeys Identified Mail)

DKIM voegt een cryptografische handtekening toe aan uitgaande e-mails. De ontvangende server verifieert de handtekening met een publieke sleutel die in DNS staat. Hiermee kan de ontvanger vaststellen dat het bericht daadwerkelijk afkomstig is van het geclaimde domein en onderweg niet is gewijzigd.

Hoe DKIM werkt

1. De verzendende mailserver berekent een hash van specifieke headers en de body
2. De hash wordt ondertekend met een private key
3. De handtekening wordt toegevoegd als DKIM-Signature header
4. De ontvanger haalt de publieke sleutel op uit DNS: selector._domainkey.example.com
5. De ontvanger verifieert de handtekening

DNS-record

selector1._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

De selector is een vrij te kiezen naam (bijv. s1, google, selector1) waarmee je meerdere DKIM-keys kunt gebruiken – handig voor key rotation.

Key length

Gebruik minimaal 2048 bits. RSA 1024-bit keys worden als onveilig beschouwd. Sommige organisaties stappen over op Ed25519 (k=ed25519), maar de ondersteuning hiervoor is nog beperkt.

# Genereer een 2048-bit RSA keypair voor DKIM
opendkim-genkey -b 2048 -d example.com -s selector1

Dit produceert twee bestanden: - selector1.private – de private key (op de mailserver) - selector1.txt – het DNS TXT-record (publiceer in DNS)

Key rotation

Draai je DKIM-keys minstens jaarlijks: genereer een nieuw keypair met een nieuwe selector, publiceer het DNS-record, wacht op propagatie, schakel de mailserver over, en verwijder het oude record na 48 uur.

OpenDKIM configuratie

# /etc/opendkim.conf
Syslog                  yes
Domain                  example.com
KeyFile                 /etc/opendkim/keys/selector1.private
Selector                selector1
Socket                  inet:8891@localhost
Canonicalization        relaxed/simple
Mode                    sv
SubDomains              yes
AutoRestart             yes
MinimumKeyBits          2048

DMARC (Domain-based Message Authentication)

DMARC bouwt voort op SPF en DKIM. Het vertelt ontvangende mailservers wat ze moeten doen als een bericht faalt op zowel SPF als DKIM, en waar ze rapportages naartoe moeten sturen.

Hoe DMARC SPF en DKIM combineert

DMARC vereist alignment – het domein in de From:-header moet overeenkomen met: - Het domein dat door SPF is gevalideerd (envelope-from), of - Het domein waarvoor DKIM heeft ondertekend (d= parameter)

Als geen van beide aligned is, faalt DMARC – ongeacht of SPF en DKIM individueel slagen.

Policy levels

Uitrolstrategie

Rol DMARC gefaseerd uit. Ga niet direct naar p=reject, tenzij je graag wilt ontdekken welke systemen allemaal namens jouw domein mailen.

Fase 1 – Monitoring (2-4 weken):

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensic@example.com; fo=1"

Fase 2 – Quarantine met percentage (2-4 weken):

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@example.com"

Fase 3 – Quarantine 100% (2 weken):

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"

Fase 4 – Reject (einddoel):

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensic@example.com; fo=1"

Rapportages

Subdomein-policy

Vergeet subdomeinen niet. Zonder sp=reject erft een subdomein het hoofdbeleid, maar een aanvaller kan subdomeinen gebruiken die niet in je SPF-record staan:

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc-reports@example.com"

DMARC reporting tools

Handmatig XML-rapporten parsen is onbegonnen werk. Gebruik een tool als parsedmarc (open source, lokaal draaien), dmarcian (SaaS, free tier), DMARC Analyzer, of Postmark DMARC (gratis wekelijkse samenvattingen).

DNSSEC

DNSSEC beschermt tegen DNS spoofing en cache poisoning door DNS-antwoorden cryptografisch te ondertekenen. Zonder DNSSEC kan een aanvaller vervalste DNS-antwoorden injecteren en verkeer omleiden naar een kwaadaardige server – inclusief je MX-records.

Hoe DNSSEC werkt

De vertrouwensketen loopt van de root zone (.) via de TLD (.nl, .com) naar jouw domein. Elke laag bevat een DS-record dat verwijst naar de DNSKEY van de onderliggende zone.

Hoe activeren

1. Bij je DNS-provider/registrar: De meeste grote registrars (TransIP, Cloudflare, Route 53) ondersteunen DNSSEC met een enkele knop. Activeer het en de provider regelt automatisch het DS-record bij de TLD.

2. Self-hosted (BIND): Genereer een ZSK en KSK met dnssec-keygen, onderteken de zone met dnssec-signzone, en publiceer het DS-record bij je registrar.

dnssec-keygen -a ECDSAP256SHA256 -n ZONE example.com        # ZSK
dnssec-keygen -a ECDSAP256SHA256 -n ZONE -f KSK example.com # KSK
dnssec-signzone -A -3 $(head -c 1000 /dev/random | sha1sum | cut -b 1-16) \
    -N INCREMENT -o example.com -t db.example.com

Validatie testen

# Controleer of DNSSEC-signatures aanwezig zijn
dig +dnssec example.com A

# Kijk naar de 'ad' (Authenticated Data) flag in het antwoord
dig +dnssec +multi example.com SOA

# Uitgebreide DNSSEC-validatie
delv @1.1.1.1 example.com A +rtrace

# Online test
# https://dnssec-analyzer.verisignlabs.com/

Let op: een verkeerd geconfigureerd DNSSEC maakt je domein volledig onbereikbaar. Test grondig in een staging-omgeving.

DNS-filtering en sinkholing

DNS-filtering blokkeert verbindingen naar bekende malware- en phishing-domeinen door het DNS-antwoord te manipuleren. In plaats van het echte IP-adres terug te geven, krijgt de client een geblokkeerd-pagina of een NXDOMAIN.

Response Policy Zone (RPZ)

RPZ is een standaard voor DNS-firewalling. Je laadt een lijst met kwaadaardige domeinen in je DNS-resolver, en elke query voor die domeinen wordt geblokkeerd:

# /etc/bind/rpz.db
$TTL 300
@  IN  SOA  localhost. admin.localhost. (
   2024010101 3600 600 86400 300 )
   IN  NS   localhost.

; Blokkeer specifiek domein
malware-c2.evil.com     CNAME  .    ; NXDOMAIN
*.malware-c2.evil.com   CNAME  .    ; inclusief subdomeinen

; Redirect naar sinkhole
phishing.example.com    A      127.0.0.1

Oplossingen voor organisaties

Sinkholing

Bij sinkholing wijs je kwaadaardige domeinen naar een interne server die het verzoek logt. Elk systeem dat probeert een C2-domein te resolven verschijnt in je logs – ideaal voor het detecteren van geinfecteerde hosts:

# Unbound sinkhole configuratie
local-zone: "malware-c2.evil.com" redirect
local-data: "malware-c2.evil.com A 10.0.0.100"

Aanvullende DNS-hardening

DoH (DNS over HTTPS) en DoT (DNS over TLS)

Standaard DNS-verkeer is onversleuteld (poort 53/UDP). Iedereen op het netwerk kan meelezen. DoH en DoT versleutelen DNS-queries:

Voor interne netwerken is DoT vaak de betere keuze – je kunt het wel monitoren via de netwerklaag. DoH is lastiger omdat het over poort 443 loopt, dezelfde poort als al het andere HTTPS-verkeer.

# Unbound DoT configuratie (als forwarder)
server:
    tls-cert-bundle: /etc/ssl/certs/ca-certificates.crt

forward-zone:
    name: "."
    forward-tls-upstream: yes
    forward-addr: 1.1.1.1@853#cloudflare-dns.com
    forward-addr: 9.9.9.9@853#dns.quad9.net

Zone transfer beperken (AXFR)

Een open zone transfer lekt je volledige DNS-zone – alle hostnamen, IP-adressen, MX-records. Beperk AXFR tot je secundaire nameservers:

# BIND - named.conf
zone "example.com" {
    type master;
    file "db.example.com";
    allow-transfer { 198.51.100.10; 198.51.100.11; };  # Alleen secundaire NS
    also-notify { 198.51.100.10; 198.51.100.11; };
};

Test of je zone transfer daadwerkelijk geblokkeerd is:

# Dit moet falen
dig @ns1.example.com example.com AXFR

DNS-recursie uitschakelen op autoritatieve servers

Autoritatieve nameservers moeten geen recursie toestaan. Laat recursie alleen toe op je interne resolvers:

# BIND - op de autoritatieve server
options {
    recursion no;
    allow-query { any; };
};

# BIND - op de interne resolver
options {
    recursion yes;
    allow-recursion { 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16; };
};

MTA-STS (Mail Transfer Agent Strict Transport Security)

MTA-STS dwingt af dat inkomende mailservers TLS gebruiken bij het afleveren van e-mail, en voorkomt daarmee TLS-downgrade aanvallen. Configuratie vereist een DNS TXT-record en een policy-bestand:

_mta-sts.example.com.  IN  TXT  "v=STSv1; id=20240101T000000"

Het policy-bestand op https://mta-sts.example.com/.well-known/mta-sts.txt:

version: STSv1
mode: enforce
mx: mail.example.com
max_age: 86400

DANE (DNS-based Authentication of Named Entities)

DANE gebruikt DNSSEC om TLS-certificaten te binden aan DNS-namen via TLSA-records. Hiermee kun je specificeren welk certificaat een mailserver moet presenteren:

_25._tcp.mail.example.com.  IN  TLSA  3 1 1 a]b]c]d]e]f]...  (SHA-256 hash van certificaat)

DANE vereist een werkende DNSSEC-configuratie. Zonder DNSSEC heeft DANE geen enkele waarde.

TLS-RPT (SMTP TLS Reporting)

Vergelijkbaar met DMARC-rapportages, maar dan voor TLS-fouten bij mailaflevering. Publiceer een _smtp._tls TXT-record met een rua-adres om meldingen te ontvangen wanneer TLS-verbindingen falen.

_smtp._tls.example.com.  IN  TXT  "v=TLSRPTv1; rua=mailto:tls-reports@example.com"

De cynische noot

Phishing is al tien jaar de nummer-1 aanvalsvector. Niet nummer twee. Niet “een van de” vectoren. Nummer. Een. Elke pentest, elke red team-oefening, elke breach-analyse – phishing staat bovenaan. En de technologie om het te stoppen bestaat. SPF is er sinds 2006. DKIM sinds 2007. DMARC sinds 2012. Meer dan tien jaar geleden.

En toch draait minstens de helft van alle organisaties zonder fatsoenlijk DMARC-record. Of ze hebben p=none en denken dat ze beschermd zijn. p=none doet letterlijk niets. Het is het equivalent van een beveiligingscamera die wel opneemt maar die niemand bekijkt.

Het mooiste zijn de organisaties die een e-mail security gateway kopen voor tweehonderdduizend euro – met sandboxing, AI-detectie, URL-rewriting, en een dashboard dat eruitziet alsof het de NASA mission control is – maar vergeten een DMARC-record in te stellen. Dat is alsof je een gepantserde deur koopt voor je huis maar het keukenraam openlaat. De technologie die gratis is en uit drie DNS-records bestaat, is te moeilijk. Maar een appliance die een eigen rack nodig heeft, die willen we wel.

De waarheid is simpel: alles wat geen vendor-demo heeft, geen sales-lunch oplevert, en geen mooi dashboard heeft, wordt niet geimplementeerd. SPF/DKIM/DMARC is gratis, dus het is niemands project. DNSSEC is een DNS-instelling, dus het valt tussen beheer en security in het niemandsland van “dat doet de ander wel.” En ondertussen stuurt een aanvaller vanuit een willekeurig IP-adres e-mails namens jouw CEO, omdat jouw domein ~all heeft in plaats van -all en je DMARC-policy op none staat. Maar hey, die email gateway heeft de phish wel gedetecteerd – in de demo.

Veelvoorkomende fouten

Checklist

Samenvatting

E-mail en DNS vormen samen het fundament van vrijwel alle zakelijke communicatie, en daarmee ook het primaire aanvalsoppervlak voor phishing, spoofing en man-in-the-middle aanvallen. De verdediging bestaat uit lagen: SPF vertelt wie er mag mailen, DKIM bewijst dat het bericht authentiek is, en DMARC combineert beide en definieert het handhavingsbeleid. DNSSEC beschermt de DNS-infrastructuur zelf tegen manipulatie. Aanvullende maatregelen als MTA-STS, DANE, DNS-filtering en sinkholing maken de keten compleet. Geen van deze technologieen is nieuw, geen is bijzonder complex, en de meeste zijn gratis. Het enige wat ontbreekt is de discipline om ze in te richten, te testen, en door te zetten tot p=reject. Drie DNS-records scheiden je domein van een phishing-paradijs en een goed beschermde mailinfrastructuur. De keuze is niet moeilijk – de uitvoering blijkbaar wel.

In het volgende hoofdstuk behandelen we MSSQL hardening: hoe je SQL Server-instanties beveiligt tegen misbruik van xp_cmdshell, linked servers, en credential harvesting via UNC path injection.