ID.nl logo
Hoe de techniek DMARC domeinspoofing moet voorkomen
© Reshift Digital
Huis

Hoe de techniek DMARC domeinspoofing moet voorkomen

Je hebt wellicht weleens phishingmails ontvangen waarbij het afzendadres wel degelijk van je bank afkomstig leek. Een geval van domeinspoofing dus en laat dat nou net de praktijken zijn die het e-mailprotocol DMARC moet voorkomen, met als bouwstenen SPF en DKIM.

DMARC staat voor Domain-based Message Authentication, Reporting & Conformance en is een protocol voor e-mailverificatie, e-mailbeleid en e-mailrapportage dat grotendeels steunt op de SPF- en DKIM-validatieprotocollen. DMARC maakt het mailservers makkelijker om na te gaan of een bericht daadwerkelijk van de vermeende zender afkomstig is en wat er dient te gebeuren indien dat niet zo is.

Het oude SMTP (Simple Mail Transport Protocol) is, zoals de naam al aangeeft, een simpel protocol om e-mails te verzenden. Er is geen sprake van enige encryptie of verificatie, wat maakt dat berichten makkelijk kunnen worden onderschept en gespooft (bijvoorbeeld via een man-in-the-middle-opzet). Er werden weliswaar enkele oplossingen aan clientzijde bedacht, zoals S/MIME en PGP, maar die vereisen de actieve medewerking van de gebruikers. 

Extensies en internetstandaarden die het SMTP-protocol en transport zelf beveiligen zijn daarom een betere werkwijze. SSL gebruiken voor SMTP-verbindingen bleek niet zo praktisch wegens poort-issues. STARTTLS is een betere aanpak aangezien de SMTP-client en -server over het TLS-gebruik (Transport Layer Security) kunnen onderhandelen en hierbij ook de mailheaders worden versleuteld.

Helaas beschermt TLS de berichten alleen wanneer het wordt verstuurd tussen twee servers die beide TLS ondersteunen.

©PXimport

SPF (Sender Policy Framework)

Inmiddels werden er nog andere technieken ontwikkeld die het vooral op e-mailspoofers gemunt hebben. SPF (Sender Policy Framework) is er één van, een techniek die steunt op DNS (Domain Name System). Er wordt hierbij immers een txt-record opgenomen in de nameserver-configuratie van het domein. Je vindt de syntaxregels hier

Zo’n record zou onder meer de volgende regel kunnen bevatten:

domeinnaam.nl TXT "v=spf1" a:email.domeinnaam.nl -all

Deze geeft aan dat de host email.domeinnaam.nl (alleen) berichten mag verzenden namens @domainnaam.nl en is dus bedoeld om e-mailspoofing tegen te gaan. Je kunt je eigen SPF-record en ook die van andere instanties hier testen

Het volstaat hier een domeinnaam te vullen (bijvoorbeeld telegraaf.nl), waarna je het SPF-record te zien krijgt, gevolgd door een analyse en een veiligheidsbeoordeling.

©PXimport

DKIM (DomainKeys Identified Mail)

DKIM (DomainKeys Identified Mail) is een complementair e-mailverificatieprotocol dat door het toevoegen van een handtekening wil voorkomen dat berichten tijdens het transport tussen de mailservers kunnen worden gewijzigd of vervalst. Meer informatie hierover vind je op dkim.org.

De mailservers of e-mailgateway moeten wel met DKIM overweg kunnen. Na het instellen van de DKIM-functie wordt er dan een sleutelpaar gegenereerd. De private sleutel komt terecht op de mailserver, terwijl de publieke sleutel in het DNS wordt opgenomen met de nodige parameters. Dat kan er in eenvoudige vorm als volgt uitzien:

selector._domainkey.domeinnaam.nl TXT "v=DKIM1; p=<publieke-sleutel>"</publieke-sleutel>

DKIM werkt namelijk op basis van een selector, met een willekeurige naam, die het zo mogelijk maakt dat je meerdere DKIM-sleutels voor je domein opneemt.

Op basis van de private sleutel wordt dan een cryptografische handtekening gegenereerd, die aan de mail wordt toegevoegd als DKIM-header. De ontvanger kan dan in het DNS de bijbehorende publieke sleutel opzoeken en controleren. Is er geen match, dan wordt de e-mail geweigerd.

Je kunt hier een DKIM-record testen. Naast een domeinnaam dien je hier wel nog een geldige DKIM-selector in te vullen. Zo’n selector kun je in de e-mailheader terugvinden. In Outlook bijvoorbeeld open je hiervoor de gewenste mail en kies je Bestand / Eigenschappen, waarna je in het veld Internetheaders zoekt naar de DKIM-ingang (indien aanwezig). Je leest de selector-naam af achter de parameter s=.

©PXimport

Hoe werkt DMARC?

Met SPF en DKIM zijn we al een heel eind richting DMARC opgeschoven. Op dmarc.org/wiki/FAQ vind je een uitgebreide lijst met vragen en antwoorden.

DMARC gebruikt de verificatieprotocollen SPF en DKIM als bouwstenen. Zo controleert DMARC of het <header from>-veld van het bericht overeenkomt met het <envelope from>-veld dat via SPF wordt gecheckt. Ook gaat DMARC na of dat veld eveneens overeenkomt met de parameter d=<domeinnaam> uit de DKIM-handtekening.

Een belangrijke meerwaarde van DMARC is dat je via beleidsregels niet alleen kunt aangeven hoe streng je die SPF- en DKIM-controles wilt interpreteren (met parameters als aspf=r en adkim=s, waarbij r voor relaxed en s voor strict staat), maar vooral ook dat je precies kunt aangeven wat er moet gebeuren als deze controles niet blijken te kloppen. In het DMARC-txt-record zou je bijvoorbeeld iets als het volgende kunnen zetten:

_dmarc.domeinnaam.nl IN TXT "v=DMARC1; p=quarantine; rua=dmarc@domeinnaam.nl; ruf=dmarc@domeinnaam.nl sp=reject"

©PXimport

Recordanalyse

Een blik op bijvoorbeeld Flowmailer maakt meteen duidelijk wat deze record-ingang inhoudt. Zo geef je met de parameter p= aan wat de ontvangende mailserver met berichten moet doen die de bovenvermelde controles niet hebben doorstaan: niets, afwijzen of ter verdere controle in quarantaine plaatsen.

Absoluut interessant zijn ook de parameters rua= en ruf=, die elk verwijzen naar een andersoortige rapportage, respectievelijk aggregated en forensic, waarbij de laatste het meest gedetailleerd is. De ontvangende mailserver stuurt deze rapporten dan automatisch door naar de in het DMARC-record vermelde e-mailadressen.

Net als bij SPF en DKIM kun je ook het DMARC-record voor een domeinnaam testen op mxtoolbox.com/dmarc.aspx. Voor all-roundtests kun je terecht op powerdmarc.com/analyzer en internet.nl.

DMARC mag dan de nodige configuratie vergen, het is in elk geval een extra, zinvolle blokkade tegen e-mailspoofing (en dus ook phishing). Jammer dus dat de implementatie van DMARC op de mailservers van Nederlandse en Belgische e-commercebedrijven relatief langzaam verloopt.

De ontwikkeling van DMARC 2012: Eerste publicatie van de DMARC-standaard (RFC 7489), onder meer door Google, Microsoft, Yahoo! en PayPal. 2013: Krijgt de status van internet-draft. 2018: Opgenomen in de ‘pas-toe-of-leg-uit-lijst’ met open standaarden van het Forum Standaardisatie van de Rijksoverheid. In deze lijst tref je onder meer nog aan: SPF, DKIM en DNSSEC.

▼ Volgende artikel
Logan Paul verkoopt duurste Pokémon-kaart ooit voor 16,5 miljoen dollar
Huis

Logan Paul verkoopt duurste Pokémon-kaart ooit voor 16,5 miljoen dollar

Worstelaar en influencer Logan Paul heeft zijn zeldzame Pikachu Illustrator-Pokémon-kaart verkocht voor 16,49 miljoen dollar.

De kaart werd in 1998 uitgereikt aan winnaars van een tekenwedstrijd georganiseerd door Coro Coro, een Japans mangamagazine. De kaart is zo’n 40 keer gedrukt en is nooit in winkels verkocht, waardoor deze al snel veel geld waard was. Ook werd de art gemaakt door Atsuko Nishida, de artiest die de eerste ontwerpen van Pikachu maakte, en heeft de Pikachu Illustrator-kaart in kwestie een PSA 10-beoordeling. Dat is de hoogste beoordeling van de toestand van Pokémon-kaarten.

View post on Instagram
 

Verkocht tijdens veiling

In 2021 kocht Logan Paul de kaart voor 5,28 miljoen dollar, waardoor het meteen de duurste Pokémon-kaart ooit werd. Ook liet hij een ketting en hoes van zo’n 70.000 dollar maken, die hij droeg tijdens verschillende worstelwedstrijden.

De Pikachu Illustrator-kaart werd verkocht via een veiling, die tussen 4 januari en 14 februari liep. Met een openingsbod van 500.000 euro liep het bedrag uiteindelijk op tot zo’n 16,5 miljoen dollar, waarna Guinness World Records bevestigde dat het wederom om de duurste Pokémon-kaart ooit gaat. De nieuwe eigenaar van de kaart is niet bekend.

View post on Instagram
 
▼ Volgende artikel
Slachtoffers Odido-datalek hebben geen automatisch recht op compensatie
Huis

Slachtoffers Odido-datalek hebben geen automatisch recht op compensatie

Telecombedrijf Odido laat weten dat mensen geen automatisch recht op compensatie hebben nadat hun gegevens via een datalek afgelopen week op straat zijn gekomen.

In het weekend van 7 en 8 februari vond een cyberaanval plaats op de website van Odido, waarbij criminelen toegang kregen tot een klantcontactsysteem. De criminelen hebben een bestand kunnen downloaden met daarop gegevens van klanten. Het zou om gegevens van mogelijk 6,2 miljoen klanten kunnen gaan.

Onder de gegevens die zijn gestolen, vallen mogelijk de volledige naam, het adres en de klantnummers van klanten. Ook de mobiele nummers, IBAN-rekeningnummers, geboortedata, e-mailadressen en identificatiegegevens (waaronder rijbewijs- en paspoortnummers) kunnen zijn buitgemaakt.

Odido benadrukte kort na het lek dat er geen scans van identiteitsbewijzen zijn gelekt, noch wachtwoorden, factuurgegevens of belgegeven. Mensen kunnen daarbij gebruik blijven maken van de diensten van Odido, maar er wordt wel aangeraden dat klanten alert zijn op vreemde sms'jes of e-mails, zeker als daar links in staan.

Geen automatisch recht op compensatie

Op een speciale pagina met informatie over het datalek heeft Odido inmiddels meer informatie gegeven over het lek en diverse vragen beantwoord. Er staat ook een vraag en antwoord bij over mogelijke compensatie voor klanten wanneer data van de klant is gelekt.

Odido schrijft: "Een datalek geeft niet automatisch recht op compensatie. Onze inspanningen zijn er momenteel op gericht om juist te voorkomen dat klanten op enige manier schade zouden ondervinden als gevolg van dit incident. We hebben klanten proactief geïnformeerd zodat zij extra alert kunnen zijn op eventueel verdachte signalen. Dit is in lijn met het advies van het Centraal Meldpunt Identiteitsfraude (CMI) van de Rijksoverheid."

Het antwoord vervolgt: "Het CMI benadrukt bovendien dat niet automatisch sprake is van identiteitsfraude of dat met de gestolen gegevens identiteitsfraude kan worden gepleegd. Ook meldt het CMI dat met de betrokken gegevens niet zomaar een lening, bankrekening of telefoonabonnement kan worden afgesloten. Ook kan er geen nieuw identiteitsbewijs mee worden aangevraagd. Daarvoor zijn immers extra controles nodig, zoals een echt identiteitsbewijs, je DigiD of de inloggegevens van je bank."

Op de website staat nog een vraag over compensatie, met daarbij nadrukkelijk vermeld dat sommige 'cybersecurity-experts' claimen dat men recht heeft op compensatie. Ook daarop wordt gemeld dat "een datalek geen automatisch recht op compensatie geeft".