Beveiliging voor versturen mails namens Timdehoog.nl via DMARC verbeterd

De afgelopen weken heb ik veel blogs gelezen over het onderwerp DMARC (Domain-based Message Authentication, Reporting, and Conformance). Dit is een standaard waarmee je de beveiliging voor het versturen van e-mails vanuit jouw domein kan beveiligen.

Een goed ingestelde DMARC zorgt ervoor dat ik alleen e-mails vanuit @timdehoog.nl kan versturen. Hiermee voorkom je dus dat anderen zich als mij voor kunnen doen en mails vanuit timdehoog.nl kunnen versturen.

DMARC gebruikt de onderstaande standaarden:

  1. SPF (sender policy framework), die controleert of een mailserver wel namens jouw domein e-mails mag versturen.
  2. DKIM (DomainKeys Identified Mail), koppelt een e-mail middels een digitale handtekening aan jouw domein.

DMARC stel je in als DNS record in de DNS instellingen voor jouw domein. Voor Antagonist moet je bijvoorbeeld inloggen op de DirectAdmin omgeving. Met SPF en DKIM kan DMARC de authenticiteit van de email verifiëren. Mislukt de verificatie dan wordt deze resultaten door DMARC verder afgehandeld.

Tim, had jij als IT blogger nog geen DMARC record dan?

Ik heb al een aantal jaren een DMARC record, maar deze stond heel simpel ingesteld.

Te strenge instellingen kunnen ervoor zorgen dat er geen mails meer verstuurd kunnen worden. Dat is ook niet iets wat je wilt. Maar met de nieuwe kennis durf ik de instellingen wel te verbeteren en zo de beveiliging te verhogen.

Het originele DMARC record:

v=DMARC1;p=none;

Het bijgewerkte DMARC record:

v=DMARC1; p=reject; rua=mailto:dmarc@timdehoog.nl; ruf=mailto:dmarc@timdehoog.nl; fo=1

Toelichting:

  • P = policy, dit is het beleid wat er moet gebeuren als een mail niet namens de mailserver van Timdehoog.nl is verstuurd. Dit stond op “none”. Hiermee wordt de mail gewoon doorgelaten. Maar dit is gewijzigd naar “reject”. Alleen mijn mailserver mag nu nog mails versturen. Mails vanaf andere mailservers worden geweigerd.
  • RUA = aggregated data reporting, hiermee ontvang je rapporten welke mails wel of juist niet bezorgd zijn en waarom deze niet bezorgd zijn. Deze mails bevatten geen inhoudelijke gegevens.
  • RUF = forensic data reporting, vergelijkbaar met RUA, maar je krijgt dan meer gedetailleerde informatie over mails die niet bezorgd kunnen worden. In deze rapporten zie je  inhoudelijke gegevens zoals afzender, ontvanger, IP-adres en inhoud. Echter wordt dit niet door alle mailservers ondersteund wegens de privacy.
  • FO = failure reporting options, dit bepaald wanneer een RUF report verstuurd wordt, zonder RUF heb je deze instelling niet nodig, ik heb gekozen voor 1.
    • 0 = Genereert rapport als SPF en DKIM falen
    • 1 = Genereert rapport als SPF of DKIM falen
    • 2 = Genereert rapport wanneer DKIM faalt
    • 3 = Genereert rapport wanneer SPF faalt

Praktijkvoorbeeld: D. Marc de portier van de lokale kroeg

Policy is vertaald naar het Nederlands beleid. Stel dat de portier als opdracht krijgt om het “none” beleid te voeren. Iedereen wordt doorgelaten. Maar als een persoon eigenlijk niet naar binnen mag zegt hij dat wel tegen het persoon. Als we het beleid aanpassen naar “reject” dan zal de portier bepaalde personen tegenhouden omdat ze bijvoorbeeld te jong zijn.

SPF zou je kunnen vergelijken met een lijst met personen die in de kroeg naar binnen mogen. Een soort van gastenlijst. DKIM zijn dan eigenlijk de toegangsbewijzen voor het feestje die voorzien zijn van een unieke handtekening. Deze is nodig om fraude tegen te gaan.

Aan het einde van de avond kan de baas van D. Marc vragen om zijn RUA rapport. Daarin zal staan hoeveel mensen hij wel of niet doorgelaten heeft. Maar de baas weet dan nog niet om wie het gaat. Daarvoor heeft hij het RUF rapport nodig. Daarin staan dan de namen van 5 personen die hij niet doorgelaten heeft wegens bijvoorbeeld de leeftijd. Maar net zoals bij mailservers heb je hier ook te maken met het privacy aspect.

De baas kan aan de portier ook vragen dat hij alleen een RUF rapport wil met FO=1. Dus een overzicht van personen die niet op de lijst stonden of geen toegangsbewijs hadden.

Hoe test je een DMARC record?

Om te zien of je het DNS record goed ingesteld hebt kan je de Free DMARC checker van van Dmarcly.com gebruiken.

Is DMARC nieuw voor je?

Dan kan je de policy het beste op “none” instellen. Mails worden dan hoe dan ook bezorgd. Maak gebruik van RUA of RUF om de benodigde rapporten te ontvangen.

Op een later moment kan je overstappen naar “reject” wat zorgt voor de beste beveiliging.

Wat kan je met de RUF of RUA rapporten?

Inmiddels heb ik mijn eerste RUF rapport binnen van de Google mailserver. Ik verzamel er eerst nog een aantal voordat ik die ga analyseren. Daar zal ik vervolgens dan weer een blog over schrijven.

Wil je nog meer lezen over dit onderwerp? Bekijk dan de ultieme DMARC gids van Spotler.

Laat een reactie achter

Your email address will not be published. Required fields are marked *

Deze site gebruikt Akismet om spam te verminderen. Bekijk hoe je reactie-gegevens worden verwerkt.