DMARC-beveiligingsprotocol voor mail krijgt een update

Een policy voor ontvangende mailservers

Beheerders van maildomeinen gebruiken DMARC om aan te geven wat er moet gebeuren met berichten waarvoor SPF of DKIM geen geldige validatie oplevert. Daarnaast beveiligt DMARC de 'From'-header van een bericht. Daartoe publiceert de beheerder een DMARC-record in het DNS-systeem, met daarin zijn aanwijzingen (de policy) voor ontvangende mailservers. Dat record kan vervolgens worden opgehaald door MX-gateways alvorens zij een binnenkomend bericht accepteren.

Het DMARC-record bevat niet alleen SPF- en DKIM-specifieke aanwijzingen voor ontvangende mailservers, maar kan ook een mailadres bevatten waarop die mailservers afgewezen berichten kunnen rapporteren. Omdat het formaat van deze meldingen geformaliseerd is, kunnen deze automatisch worden verwerkt tot statistieken en rapportages. Zo krijgt de beheerder van het betreffende maildomein inzicht in de aflevering van zowel echte als vervalste berichten. Dit alles is essentieel in de strijd tegen phishing, CEO-fraude, ransomware [1, 2] en andere malware-aanvallen.

Authenticatie van mail-envelope en 'From'-header

Om de werking van DMARC te kunnen begrijpen, moet je eerst iets weten over de mail-headers en de mail-envelope. Dit is de informatie over de verzender (een systeem), de afzender (een mailadres) en de geadresseerde (een mailadres) die de aanbiedende mailserver via het SMTP-protocol overdraagt aan de ontvangende server:

• bij het 'EHLO'/'HELO'-commando: de hostname van de aanbiedende mailserver

• bij het 'MAIL FROM'-commando: het afzender/return-adres van het bericht (het bounce-adres)

• bij het 'RCPT TO'-commando: de geadresseerde(n) voor wie het bericht bestemd is

• in de 'From'-header: de afzendernaam en -adres (de display name) zoals uiteindelijk door de mail-client getoond aan de ontvangende gebruiker;

• omdat hier zonder DMARC geen enkele authenticatie op zit, en de 'From'-header geen rol speelt bij het transport en de aflevering van een bericht, is het vervalsen van de display name triviaal

En dit is hoe SPF, DKIM en DMARC deze informatie gebruiken om de authenticiteit van verzender en afzender vast te stellen:

• SPF: de validatie van de 'EHLO'/'HELO'- en 'MAIL FROM'-informatie (de mail-envelope)

  • (optioneel) check de 'EHLO'/'HELO' hostname om te zien of die inderdaad verwijst naar het IP-adres van de SMTP-client,

  • waarmee is bewezen dat de client (de aanbiedende mailserver) inderdaad is wie hij zegt te zijn

  • (verplicht) check het afzenderdomein van het 'MAIL FROM'-adres om te zien of het IP-adres van de SMTP-client inderdaad geautoriseerd is om mail van dit domein aan te bieden, waarmee is bewezen dat de client (de aanbiedende mailserver) gerechtigd is om namens de afzender berichten door/uit te sturen

  • is er geen 'MAIL FROM'-informatie beschikbaar (typisch voor bounceberichten), dan valt SPF terug van het afzenderdomein naar de 'EHLO'/'HELO' hostname;

  • maar let op: deze mogelijkheid wordt niet gebruikt door SPF als onderdeel van DMARC

  • het (positieve) resultaat is een gevalideerde mail-envelope

  • als de validatie van een bericht/envelope faalt, dan kan een verbinding/bericht gelijk geblokkeerd worden, of het bericht wordt verder doorgegeven met het negatieve resultaat in een 'Received-SPF'- en/of 'Authentication-Results'-header

• DKIM: de ondertekening van uitgaande mail-berichten en hun headers aan verzendende zijde, en de validatie van de handtekening onder binnenkomende berichten aan ontvangende zijde

  • check of de digitale handtekening meegestuurd met het bericht (in de 'DKIM-Signature'-header) klopt;

  • gebruik daarvoor de publieke sleutel gepubliceerd in het signing domain dat ook in deze header staat aangegeven

  • omdat het signing domain niet per se overeen hoeft te komen met het afzenderdomein in het 'MAIL FROM'-commando of de 'From'-header, doet DKIM op zichzelf niet meer dan de verantwoordelijkheid van het signing domain bevestigen voor het in het verkeer brengen van een bericht

  • DKIM blokkeert zelf geen berichten; de uitkomst van de validatie wordt aan het bericht toegevoegd in een 'Authentication-Results'-header en bijvoorbeeld meegenomen in de score van een spamfilter of in de DMARC-evaluatie; daarmee is dus vooral de reputatie van het signing domain van belang

• DMARC: de verwerking van de uitkomsten van de SPF- en/of DKIM-validatie op basis van een policy gepubliceerd door het afzenderdomein in de 'From'-header

  • check of het afzenderdomein in de 'From'-header ten eerste overeenkomt met het gevalideerde afzenderdomein in de envelope (voor SPF) en ten tweede met het gevalideerde signing domain (voor DKIM);

  • met deze alignment-checks wordt een koppeling gemaakt tussen de SPF/DKIM-gevalideerde afzenderdomeinen enerzijds en de informatie in de 'From'-header (de display name) anderzijds

  • gebruik de policy zoals gepubliceerd in het afzenderdomein van de 'From'-header om te beslissen wat te doen met binnengekomen mail-berichten waarvan zowel de SPF- als de DKIM-validatie (inclusief de alignment) negatief is: doorlaten, blokkeren of in quarantaine plaatsen;

  • ook voor DMARC geldt dat de policy geen hard voorschrift is; net als bij DKIM kunnen de uitkomsten worden meegenomen in de score van een spamfilter

  • stuur desgevraagd (in de policy) geaggregeerde en failure-rapportages naar de beheerder van het afzenderdomein

  • De DMARC-policy

De DMARC-policy laat zich nu het makkelijkst uitleggen aan de hand van een voorbeeld en een diagram. Hieronder zie je hoe een DMARC-record eruit zou kunnen zien:

_dmarc.example.nl IN TXT "v=DMARC1; p=reject; sp=reject; aspf=s; adkim=s;
rua=mailto:dmarc-reports@example.nl; ruf=mailto:dmarc-reports@example.nl; fo=1;"

met daarin:

• 'v=DMARC1;' we gebruiken DMARC versie 1 (op dit moment de enige beschikbare versie)

• 'p=reject;' de policy voor het hoofddomein

• 'sp=reject;' de policy voor de subdomeinen (als zij zelf geen eigen DMARC-policy publiceren)

• 'aspf=s;' de alignment tussen het 'From'-afzenderdomein en het door SPF gevalideerde 'MAIL FROM'-afzenderdomein

• 'adkim=s;' de alignment tussen het 'From'-afzenderdomein en het signing domain van de door DKIM gevalideerde digitale handtekening

• 'rua=mailto:dmarc-reports@example.nl;' ons mailadres voor geaggregeerde rapportages (één keer per dag)

• 'ruf=mailto:dmarc-reports@example.nl;' ons mailadres voor forensische (failure) rapportages (voor individuele mail-berichten die geweigerd zijn)

• 'fo=1;' verzoek aan een ontvangende mailserver om een forensische rapportage te genereren als SPF of DKIM geen geldige validatie en alignment oplevert

Hierbij is het belangrijk te weten dat de 'p'- en 'sp'-tags de policy’s geven voor berichten waarvoor SPF en DKIM geen van tweeën correct valideert. Door DMARC positief te laten valideren als SPF of DKIM positief valideert, worden validatieproblemen veroorzaakt door mailing lists en doorgestuurde berichten zo veel mogelijk opgevangen. Verderop meer over deze problematiek.

En het is goed om te weten dat DMARC niet per se afhankelijk is van SPF en DKIM. Het protocol is zo gedefinieerd dat in de toekomst ook andere onderliggende authenticatieprotocollen aan DMARC toegevoegd kunnen worden. Zolang één van deze zogenaamde Authenticated Identifiers positief valideert (inclusief de alignment), valideert DMARC ook positief.

Alignment

De tags 'aspf=s;' en 'adkim=s;' specificeren hoe streng de ontvangende mailserver moet omgaan met de alignment tussen het 'From'-afzenderdomein van een binnenkomend bericht enerzijds en de gevalideerde domeinnamen behorend bij respectievelijk SPF en DKIM anderzijds.

Staat de 'adkim'-tag ingesteld op 's' (strict), dan moet het 'From'-afzenderdomein precies overeenkomen met het signing domain in de 'd'-tag van de DKIM-header. Dat betekent dat je dan geen berichten kunt sturen van een subdomein (bijvoorbeeld alerts@news.example.nl) voorzien van een digitale handtekening afkomstig van je hoofddomein (example.nl). Gebruik je de tag 'adkim=r;' (relaxed, de default), dan mag dit wel. Merk op dat het gebruik van DKIM met DMARC impliceert dat het signing domain gelijk is aan je hoofddomein. En let op dat je deze tag niet verward met de canonicalization tag ('c=relaxed/simple;') in de DKIM-header.

Voor de 'aspf'-tag kun je op dezelfde manier kiezen tussen 'strict' en 'relaxed'. Alleen gaat het hier om de alignment tussen het 'From'-afzenderdomein van het bericht en het 'MAIL FROM'-afzenderdomein van de envelope.

Beveiliging van de display name

Waar SPF en DKIM je dus de mogelijkheid geven om het 'MAIL FROM'-afzenderdomein en de verzendende mailservers te beveiligen, maakt DMARC nog eens de koppeling met de 'From'-header. Die bevat immers de afzenderinformatie (de display name) die uiteindelijk door de mail-client aan de geadresseerde eindgebruiker wordt getoond. De 'aspf'- en 'adkim'-tags geven je daarbij de mogelijkheid om de alignment-eisen van de DMARC-validatie te finetunen voor subdomeinen.

Onderstaand diagram laat nog eens zien hoe de 3 beveiligingsprotocollen zich tot elkaar verhouden en waar de alignments aangrijpen.

Nieuwe policy-tags

Met de werking van deze mail-beveiligingsprotocollen in het achterhoofd kijken we nu naar de voorgestelde wijzigingen. Om te beginnen staat de nieuwe RFC op zichzelf. Dat betekent dat het de huidige RFC's 7489 (DMARC voor reguliere domeinnamen) en 9091 (DMARC voor registry’s) volledig vervangt. Bovendien wordt de status van DMARC hiermee opgewaardeerd van 'Informational' naar 'Proposed Standard'.

Parallel aan deze vernieuwing krijgt ook RFC 6591, waarin het foutrapportage-formaat is gedefinieerd, een update [1, 2].

Met de update worden verschillende nieuwe tags geïntroduceerd:

• np: de policy voor niet-bestaande subdomeinen

• psd: een vlag om aan te geven dat om een zogenaamd Public Suffix Domain (PSD) gaat (e.g. 'psd=y'), dat wil zeggen een domein beheerd door een registry; merk op dat dit niet persé een top-level domein hoeft te zijn; denk maar aan het .co.uk-domein; deze vlag wordt gebruikt om het hoofddomein van het 'From'-afzenderdomein te bepalen

• t: een vlag om aan te geven dat de huidige 'p'-policy alleen getest wordt (e.g. 't=y'); ontvangende mailservers wordt gevraagd om binnenkomende berichten één niveau lichter te behandelen dan aangegeven ('quarantine' -> 'none', 'reject' -> 'quarantine'); daarmee vervangt de 't'-tag de oude 'pct=0'- en 'pct=100'-tags

Daarnaast worden diverse bestaande tags afgeschaft:

• pct: werd gebruikt om alleen een bepaald percentage van de binnenkomende berichten onder de huidige DMARC-policy te laten vallen; de rest zou één niveau lichter moeten worden behandeld

• rf: het formaat van de geaggregeerde rapportages

• ri: het interval tussen de geaggregeerde rapportages

De versie blijft na de update op DMARC1 staan. De betekenis van de bestaande tags verandert immers niet, en de nieuwe tags worden door oude software genegeerd.

DNS Tree Walk

Een andere belangrijke verandering is dat het zoekalgoritme naar de relevante DMARC-policy (het juiste DMARC-record) voor het 'From'-afzenderdomein is aangepast. De 'DNS Tree Walk'-methode maakt daarbij gebruik van de nieuwe 'psd'-tag om de organisatorische domeinnaam te achterhalen. Tref je een policy met 'psd=y' (of 'psd=n'), dan ben je klaar, want hieruit is het organisatorische domein af te leiden. En anders probeer je het nog eens op het bovenliggende domein (maximaal 8 diep), net zolang tot je de policy voor het organisatorische domein te pakken hebt.

Deze aanpak kost weliswaar meer DNS-query’s, maar maakt het makkelijker om de specificatie van DMARC-policy’s te delegeren naar subdomeinen.

Een domeinnaamhouder publiceert voor dit alles dus een DMARC-record op al zijn of haar authordomeinen (de displaydomeinnamen) en op het hoofddomein (een organisatorische domeinnaam). Daarnaast zorgt de houder dat de alignment van de Authenticated Identifiers (SPF en DKIM) met het 'From'-afzenderdomein positief valideert (direct of als subdomein). In het ideale geval regel je alles zo in dat je alle alignment-policy’s op 'strict' kunt instellen.

Een mail-afdeling of -partner kan een subdomein direct als organisatorisch declareren door 'psd=n' in de DMARC-policy op te nemen.

Als een registry een DMARC-policy op zijn domein publiceert, dan moet hij daar 'psd=y' aan toevoegen. Dan weet een validerende mailserver dat het hoofddomein (een organisatorische domeinnaam) daaronder ligt.

SPF én DKIM

Hoewel je DMARC in principe ook kunt gebruiken met alleen SPF of DKIM, wordt dat sterk afgeraden in de RFC. Dat heeft alles te maken met de interoperabiliteitsproblemen tussen DMARC en zogenaamde Indirect Email Flows, in detail besproken in RFC 7960. Concreet gaat het om:

• derden, bijvoorbeeld externe dienstverleners, die mail verzenden namens jouw domeinnaam; voor een positieve SPF-validatie zouden alle verzendende mailservers van die partij(en) in je SPF-record opgenomen moeten worden; voor een positieve DKIM-validatie zou elke partij een private DKIM-sleutel uitgereikt moeten krijgen, waarvan het publieke gedeelte door de houder wordt gepubliceerd; voor een grote organisatie kan het dan makkelijker zijn om een DKIM-sleutel in het DNS-systeem van zijn partners te autoriseren middels een CNAME-verwijzing; een mail-bericht mag immers meerdere DKIM-handtekeningen bevatten, waarvan er maar één geldig hoeft te zijn; alternatief is de delegatie van een heel subdomein

• de grootste problemen treden op bij berichten afkomstig van mailing lists; die servers sturen immers berichten (door) namens "willekeurige" afzenders; dat betekent dat ze over het algemeen niet kunnen worden opgenomen in de SPF-records van het afzenderdomein (alleen de grootste mailverwerkers kunnen de meest gebruikte forwarders in een actuele whitelist bijhouden); bovendien hebben mailing-list forwarders er een handje van om de Subject-header te veranderen (bijvoorbeeld door een name-tag toe te voegen) of het bericht zelf (door een footer toe te voegen), waarmee een originele DKIM-handtekening niet meer zal valideren; om toch een valide alignment te krijgen, zit er niet veel anders op dan het 'From'-afzenderadres aan te passen; dat kan bijvoorbeeld door het 'From'-afzenderadres op een eigen adres (van de forwarder of de mailing list, na toepassing van het Sender Rewrite Scheme) in te stellen, en het originele afzenderadres in de 'Reply-To'- en 'Original-From'-headers te zetten; het is echter aan de mail-client om die laatste header al dan niet aan de ontvangende eindgebruiker te tonen

Ook met deze update van DMARC blijven de problemen met forwarding en aliassen onopgelost. Vandaar dat nu expliciet wordt aangegeven de DMARC-policy niet op 'reject' in te stellen als gebruikers 'mailing list'-berichten ontvangen.

SPF in combinatie met DMARC en DKIM

SPF-validatie vindt zo vroeg mogelijk plaats in de SMTP-uitwisseling [Postfix, Exim]. Dus als de SPF-policy op '-all' ingesteld staat, worden niet-validerende berichten gelijk geweigerd. In dat geval zal nooit meer een positieve DKIM-validatie als onderdeel van een DMARC-validatie kunnen plaatsvinden (wel krijgt de aanbiedende server via SMTP een terugmelding dat het betreffende bericht geweigerd is en waarom). Vandaar dat de SPF-policy in combinatie met DMARC en DKIM meestal wordt ingesteld op '~all' (een softfail).

De DKIM- en DMARC-validaties vinden later in de keten plaats, maar indien mogelijk nog wel tijdens de SMTP-uitwisseling. Een SMTP-terugmelding heeft immers de voorkeur boven een failure report of een bouncebericht vanwege alle backscatter van niet-validerende mail naar het return-adres.

Om je DMARC-configuratie te testen, kunnen we deze tool aanraden:

https://www.dmarctester.com/

Toepassing DNSSEC aangeraden

Rest ons hier alleen nog om iets over DNSSEC te zeggen: Ook in de nieuwe RFC wordt de toepassing van DNSSEC aangeraden om de integriteit van de verschillende DNS-records te beschermen. Het gebruik ervan is echter (nog steeds) niet verplicht.

Voor een overzicht van alle moderne internetbeveiligingsstandaarden en hun onderlinge afhankelijkheden verwijzen we graag naar ons maturitymodel.