Mail controle met SPF, DKIM en DMARC (Uitgelegd)

Briolet

Forum Gebruiker
Berichten
4.338
Internet
  1. Ziggo
Digitale TV
  1. Ziggo
Sinds eind augustus schrijft Ziggo de resultaten van hun SPF, DKIM en DMARC tests in de mailheaders van binnenkomende mail. Het betreft drie testen om de authenticiteit van mail te kunnen beoordelen. Die testen deed Ziggo al langer, maar nu kunnen we het resultaat zelf in de header zien.

Dit is een mooie aanleiding om hier wat dieper op in te gaan. Mail op zich is niet ontworpen om de echte afzender te authenticeren. In principe kan iedereen elke willekeurige naam als afzender invullen. Misschien kan jouw mail programma dat niet, maar dan kun je altijd een ander programma pakken dat het wel kan.

Toch gebruiken de meeste phishing mailtjes niet de afzendernaam die ze willen imiteren. Ik denk dat een belangrijke reden is dat hun phishing mail dan snel door de mand valt door de testen die ontvangende mailservers doen. Op die manier voorkomen ze dat hun mail direct bounced of in de spambox terecht komt.

Om de beveiligingschecks te omzeilen, bevat een phishingmail meestal een afzender die een beetje op de echte afzender lijkt. Voor de gelijkende afzender kunnen ze het wel instellen dat alle testen kloppen, want de mail komt ook van die gelijkende afzender. Een mail beoordelen begint dus bij het goed kijken of het afzender domein, het stuk achter het apenstaartje, wel de goede naam is. Klopt die naam niet, dan is de mail direct al behoorlijk verdacht.

Klopt die afzender naam wel, dan wordt het tijd om de mail eens echt te bekijken. En dan bedoel ik niet de spelling, want dat is een zeer dubieuze controle. Nee, je moet echt in de header kijken. Veel mensen schrikken misschien van die brij aan tekst, maar als je weet waar je naar op zoek bent, kun je vrij snel het relevante deel opzoeken. De rest negeer je dan gewoon.

Als je op zoek bent naar de controles, zoek je die regel op die begint met Authentication-Results:. Direct erachter staat welke server de test uitgevoerd heeft en na de semicolon staan de resultaten. Bij Ziggo staat elk test resultaat op een eigen regel. De resultaten van een mailtje die je van “mijnbank.nl” gekregen hebt, kunnen er b.v. zo uitzien:

“legitieme mail” zei:
Authentication-Results: ⁨mail.iss.as9143.net;
spf=pass (17.164.72.57;mijnbank.nl);
dkim=pass header.d=mijnbank.nl;
dmarc=pass header.from=mijnbank.nl (p=quarantine sp=quarantine dis=pass);⁩

mail.iss.as9143.net is de naam van de Ziggo server die de controle uitgevoerd heeft. Niet direct herkenbaar, maar het zal altijd dezelfde naam zijn bij Ziggo, dus herken je hem wel na een paar mailtjes bekeken te hebben.

spf is een test of de mail wel van het goede IP adres afkomstig is. De naam op het eind, ‘mijnbank.nl’, heeft ergens een lijst gepubliceerd met IP adressen die voor hun mail gebruikt worden. Bij een ‘pass’ komt de mail vanaf een correct IP adres. BIj een fail komt de mail vanaf een foutief IP adres dat niet op de lijst staat. En bij ‘none’ of ‘neutral’ heeft ‘mijnbank.nl’ geen beveiliging ingesteld.

dkim is een digitale handtekening die in de mail zelf staat. Als er maar één teken in de mail verandert is, dan zal dkim een fail geven. De handtekening is geplaatst door het domein dat op het eind staat. In dit voorbeeld “mijnbank.nl”.
Een mail kan meerdere dkim handtekeningen bevatten. Ziggo geeft dan voor elke handtekening het resultaat.

Nu zijn spf en dkim zo ontworpen dat ook mailing bedrijven mail voor anderen kunnen versturen. Dus de naam die achter de spf of dkim test staat, is soms een andere dan die in het leesbare ‘from’ of ‘van’ veld. Het kan ook de naam van het mailingbedrijf zijn.

dmarc combineert de spf en de dkim test, maar voegt er een extra eis aan toe. Minimaal één van de spf en dkim tests moet een pass geven op het domein dat zichtbaar in het ‘van’ veld staat. Bij een pass op spf of dkim, moet je zelf nog kijken of er achter de test ‘mijnbank.nl’ staat, of dat er een ander domein staat dat je kunt vertrouwen. Als dmarc een pass geeft weet je zeker dat het mailtje van de zichtbare afzender komt. De dmarc beveiliging is nog relatief nieuw. Dmarc is in 2012 geïntroduceerd en pas de laatste jaren beginnen bedrijven hun afzender hiermee te beveiligen. Gelukkig lopen bedrijven die interessant zijn voor phishers voorop. Volgens mij hebben alle Nederandse banken inmiddels wel een dmarc beveiliging.

Als vergelijk geef ik hier het resultaat van een phishing mail die zogenaamd van een creditcard maatschappij kwam:

“Phishing mail” zei:
Authentication-Results: ⁨mail.iss.as9143.net;
spf=neutral (220.152.48.7;support.net);
dkim=none (nosigs);
dmarc=none header.from=support.net (dis=no_record);⁩

Neutral bij spf geeft aan dat elk IP geaccepteerd wordt. (geen beveiliging dus)
None bij dkim geeft aan dat er geen handtekening is om te controleren. (nosigs)
None bij dmarc geeft aan dat er geen beveiliging ingesteld is. (no_record)

Hier is duidelijk niet de naam van de creditcard maatschappij gebruikt als afzender om geen fail te krijgen. Merk wel op dat support.net geen beveiliging ingesteld had, maar als ze dat wel gedaan hadden, dan waren het 3 passes geweest voor die naam. Dus controle van de afzender naam is eerste prioriteit.

Het bekijken van de ‘Authentication-Results’ is voldoende voor de beoordeling. Als je in meer detail wilt weten hoe de methodes werken, moet je verder lezen in de volgende berichten.
 
Laatst bewerkt:
SPF (Sender Policy Framework)

Bij spf is het de eigenaar van een domein die een lijst met toelaatbare IP adressen in zijn DNS record zet. Aan de mail zelf hoeft hij niets toe te voegen. Als een mailserver een mail ontvangt, zal hij een DNS opvraag doen naar de lijst met toegelaten afzender IP’s, bij het domein dat claimt de afzender te zijn van de mail.

De eigenaar van de domeinnaam kan ook instellen hoe er gereageerd moet worden bij een fail. (hardfail of softfail). Bij een hardfail mag de mail bouncen, maar meestal kiest een mailserver ervoor om deze mail in de spambox te plaatsen. Bij een softfail doen de meeste mailservers niets. Ze verhogen meestal alleen de spamscore van de mail. Maar als de mail verder geen spam eigenschappen heeft, komt dergelijke mail gewoon in de inbox terecht.

De instelling van hardfail of softfail gebeurd dus door de domein eigenaar, waarbij banken iets sneller voor een hardfail zullen kiezen dan een sportclub. Ziggo moet gewoon handelen naar deze instelling.

Om het mogelijk te maken dat ook mailing bedrijven in jouw naam mail kunnen versturen, maakt mail onderscheid tussen de ‘van’ of ‘from’ afzender die de gebruiker bovenaan de mail ziet en de ‘enveloppe’ afzender die je alleen in de header terug vind. Vergelijk het met papieren post. De afzender in het briefhoofd van de brief (From), geeft de brief samen met een adressenlijst aan het mailing bedrijf. Die printen de brief gepersonaliseerd uit, stoppen het in een enveloppe en gooien het in de bus. De echte verzender is dus het mailingbedrijf.

De gewone spf test controleert dus de echtheid van de verzender van de enveloppe. De spf test die dmarc ook nog eens uitvoert, controleert of het IP adres ook bij de naam in het ‘From’ veld hoort. Indien van toepassing kunnen er dus meerdere spf tests uitgevoerd worden. Er wordt alleen het resultaat van de meest belangrijke in de header vermeld.

De spf test op de enveloppe werkt goed tegen phishingmail die via botnets verstuurd wordt, maar niet tegen mail via speciaal opgezette mailservers of gehackte mailservers. Bij beoordelen van de spf test moet je dus altijd kijken of het bij de test gebruikte domein ook vertrouwd is. b.v. door eerdere mailtjes van de afzender te bekijken.

Lees ook: https://www.open-spf.org
 
Laatst bewerkt:
DKIM (Domain Key Identified Mail)

Bij dkim plaats de verzendende mailserver een checksum over de mail in de mailheader zelf. Daarnaast zet hij erbij waar de publieke sleutel staat om de checksum te verifiëren. Die sleutel moet natuurlijk daar staan waar alleen de verzender toegang toe heeft. Dat is het DNS record dat bij zijn domeinnaam hoort.

Een dkim handtekening ziet er doorgaans als volgt uit:

Dkim-Signature: ⁨v=1; a=rsa-sha256; c=relaxed/relaxed; d=mijnbank.nl; s=04042017; t=1536649051; bh=Xp/H+LHRvdrx8Ppvp4w4cpcvElmWvqQHwrQU2NJmDuA=; h=From:Content-type:MIME-version:Subject:Message-id: Date:To; b=GFeIu2UN8T/KGLmgLZOM3YMY+0lcf05H8ab31a8sd+m1zhkfIYbitlNwSJX5SkJ83 4bczRLsbwV58sxjMfQRdg3fXfopO60lL0eCKOkSJRNXVq1aX1v9Kuy+eGHXGv/NM6h k4UHKCkskKzsMxRhUoEhndDrJ9sQPHXIoJNlztmHTqJPbRmy6Uh7rdRao/iULJ43ng bB4lTmHTz8Vy/VVSgMRlMvYfKSvzcWUjFjnaY3bKO4Zg+IfjYfSqIqcWWBzcULMuXN SJlzoDlx6ckaV1RX/1GbV8+oTKOxCpou3If1KieaAFd44ijuAaOTY/UE/3DOwzgh0h nMFKVGUqabQJw==⁩

Inderdaad, een heel blok tekst dat achter elkaar geschreven wordt. Als je goed kijkt zie je dat de elementen door een semicolon gescheiden worden. Laat ik hierbij de belangrijkste elementen even toelichten:

d= het domein waar de publieke sleutel voor controle staat.
s= De naam van de sleutel in dat domein. Een domein kan namelijk meerdere sleutels bevatten. Als er b.v. meerdere servers gebruikt worden, kun je elke server een eigen sleutel geven.
b= De eigenlijke checksum. Deze beslaat meerdere regels in de header.
h= De onderdelen van de mail waarover de checksum berekend is. (naast de body tekst, die altijd meegenomen wordt)
t= Het aanmaak tijdstip van de checksum in seconden vanaf 1 januari 1970 in UTC tijd.
l= Als dit veld er bij staat is er geen checksum over de hele body tekst berekend, maar alleen over de eerste l bytes.

Net als bij spf, kan ook hier een mailing bureau de mail met zijn eigen domeinnaam ondertekenen. Een mail mag echter meerdere dkim ondertekeningen bevatten. De dmarc test kijkt echter alleen naar een handtekening die door het domein in het zichtbare ’From’ geplaatst is.

Overigens verwacht ik niet dat je een mailtje zult zien met een dkim-fail. Naar mijn ervaring bouncen die bij Ziggo en komen dus ook niet in de spambox.

Lees ook: https://www.opendkim.org
 
Laatst bewerkt:
DMARC (Domain-based Message Authentication, Reporting & Conformance)

Zoals hierboven aangehaald, gebruikt dmarc ook de spf en dkim test, maar nu met het domein dat zichtbaar voor de ontvanger in het ‘From’ of ‘Van’ veld staat. Doordat dmarc op het echte ‘From’ veld controleert, is het voldoende dat maar één van de spf en dkim tests een pass geeft. De ander mag een fail geven. (SPF geeft eigenlijk altijd een fail bij geforwarde mail bij dmarc, omdat het verzend IP bij forwarden niet meer klopt)

Net als bij spf, zet de eigenaar van een domein een dmarc opdracht in zijn DNS record. Hierin staat hoe te handelen bij een fail. In hoofdlijnen heeft hij drie opties om in te stellen:

reject: Hierbij bounced de mail en heb je ook geen last van die foute mail.
quarantine: Hierbij wordt de mail doorgaans in je spambox geplaatst. (En mag jij het verder zelf uitzoeken) Een bedrijf met eigen mailserver kan er ook voor kiezen om deze mail naar een specialist in de bedrijf door te sturen en die moet dan kiezen of die mail afgeleverd mag worden.
none: Hierbij gebeurt er niets. Alleen een melding in de mail header dat er een fail was.

Omdat DMARC nog vrij nieuw is, zetten veel bedrijven de optie op ’none’. Ze weten niet zeker of hun mail infrastructuur wel op orde is voor deze beveiliging en zijn bang dat correcte mail niet aankomt door de beveiliging.

Lees ook: https://dmarc.org
 
Laatst bewerkt:
Forwarden

Een speciaal aandachtspunt bij al deze beveiligingen is het forwarden van mail. Het mag duidelijk zijn dat geforwarde mail van een ander IP adres komt dan de oorspronkelijke mail. Dit kan tot gevolg hebben dat als de oorspronkelijke afzender een ‘hardfail’ ingesteld heeft, zijn mail altijd bounced of in de spamfolder terecht komt.

Er zijn wel oplossingen voor, door de mail in een nieuwe ‘enveloppe’ te stoppen, zoals b.v. Gmail doet. Als ik een mail vanaf mijn iCloud account naar mijn Gmail account stuur en dan naar mijn Ziggo account laat forwarden, krijg is twee Authentication-Results in mijn mail header. De bovenste plaatst Ziggo en de onderste GMail:
“Van iCloud via Gmail naar Ziggo” zei:
Authentication-Results: ⁨mail.iss.as9143.net; spf=pass (209.85.217.54;gmail.com); dkim=pass header.d=icloud.com; dmarc=pass header.from=icloud.com (p=quarantine sp=quarantine dis=pass);⁩

Authentication-Results
: ⁨mx.google.com; dkim=pass [email protected] header.s=04042017 header.b=nArKnccN; spf=pass (google.com: domain of [email protected] designates 17.164.72.58 as permitted sender) smtp.mailfrom= [email protected]; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=icloud.com⁩
Je ziet aan de spf test dat Ziggo dit ziet als een mail die door Gmail verstuurd is, ook al staat er iCloud in het afzenderveld.

Ziggo doet het forwarden minder netjes. Die stopt de mail niet in een nieuwe ‘enveloppe’ maar stuurt hem gewoon door in de oude ‘enveloppe’ met als resultaat een fail op spf. Nu heeft iCloud een softfail ingesteld. Was het een hardfail geweest, dan kwam hij in de spamfolder of ik kreeg hem helemaal niet.
“Van iCloud via Ziggo naar Gmail” zei:
Authentication-Results: ⁨mx.google.com; dkim=pass [email protected] header.s=04042017 header.b=HZ0kP3n9; spf=softfail (google.com: domain of transitioning [email protected] does not designate 212.54.42.169 as permitted sender) smtp.mailfrom= [email protected]; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=icloud.com⁩

Authentication-Results: ⁨mail.iss.as9143.net; spf=pass (17.164.72.58;icloud.com); dkim=pass header.d=icloud.com; dmarc=pass header.from=icloud.com (p=quarantine sp=quarantine dis=pass);⁩

Desondanks geeft dmarc een pass omdat dkim wel geldig is en één geldige check op de afzender in het 'From' veld genoeg is.
 
Laatst bewerkt:
De instelling van hardfail of softfail gebeurd dus door de domein eigenaar, waarbij banken iets sneller voor een hardfail zullen kiezen dan een sportclub. Ziggo moet gewoon handelen naar deze instelling.
de netwerkbeheerder/postmaster van de rechtmatige afzender stelt het spf record in. alleen als een afzender absoluut zeker is dat alleen die ip adressen of fqdn's juist zijn zal hij een hard fail instellen, en dat valt niet mee. denk bv aan partijen die je mailings versturen namens je eigen domeinnaam, die moet je ook opnemen in je spf record.
het staat de postmaster van de ontvanger volledig vrij om een eigen reactie te kiezen. in ons geval: als ziggo een externe mail voor een @ziggo.nl emailadres binnenkrijgt moeten ze dus absoluut niks! spf is - net als dkim en dmarc - iets van de ontvanger, de verzender kan alleen maar een hulpmiddel aanreiken.
 
Laatst bewerkt:
Peter, volgens mij was dat ook wat ik schreef. Ik heb wel een aantal zaken wat meer zwart/wit opgeschreven om het verhaal kort te houden voor de geïnteresseerde leek. Als je alles precies wilt opschrijven met alle nuances, wordt het een heel boekwerk.
Hoe te handelen staat in RFC 7208, sectie 8. De ontvanger heeft veel vrijheid hoe te reageren.

als ziggo een mail voor een @ziggo.nl emailadres binnenkrijgt moeten ze dus absoluut niks!
Dat is logisch, want het blijft binnen dezelfde server. Sterker, Ik heb een eigen mailserver met eigen domeinnaam, maar stuur al mijn mail via de Ziggo smtp server naar buiten. Ook hier doet Ziggo niets als ik iets van mijn domein naar een @ziggo.nl adres stuur. Er worden ook geen authenticatie resultaten in de header geschreven.

SPF word inderdaad vaak verkeerd geconfigureerd door het vergeten van correcte verzend IP's. Dit viel me laatst nog op bij de mail van de ziggo helpdesk.
Vooral bij kleine bedrijven merk ik dat spf soms niet klopt. Ze kopen een e-mail dienst bij een hostingprovider. Die zet er een spf policy op en kijkt er verder nooit meer naar om. In de loop der tijd veranderd het afzend IP adres en je hebt een fail. En de gebruiker van dat domein kent vaak het woord spf niet.

Dat verzenders pas een hardfail instellen als ze zeker weten dat alles in orde is, klopt ook niet. Ik koop wel een telefonisch goederen bij een bepaalde firma. Een paar week geleden deed ik voor het eerst een aankoop via hun webshop. Heel toevallig zag ik de bounce van hun bevestigingsmail in het maillog. Zij hadden een hardfail ingesteld, maar het IP van de mail vanuit de webshop stond niet in hun spf record.
Ik heb direct een mailtje hierover naar hun info adres gestuurd. Binnen het uur had ik een mailtje terug van de eigenaar die aangaf dat ze al een tijdje problemen hadden dat mail vanuit de webshop bij bepaalde klanten niet aankwam. Waarom stel je dan een hardfail in?

Van een firma als BMW zou je verwachten dat ze wel alles op orde hebben. Op zijn minst op technisch gebied. Hun mailings (vanaf het domein info.bmw.nl) komen nu al een half jaar binnen met een permerror op spf. Zij gebruiken een 'include' statement in hun record zonder aan te geven wat er included is. Voor mij onbegrijpelijk dat bij zo'n bedrijf een fout zo lang in stand blijft en niemand dit opmerkt en in actie komt. (Het is een fix van nog geen minuut om dat duidelijk foute include te verwijderen)

Zelf gebruik ik een Mailserver van synology. Daar kan ik zelf niet instellen hoe hij een fail moet afhandelen. Als ik het controleren aan zet, betekent het een bounce van een hardfail.
 
Laatst bewerkt:
laat ik het dan anders formuleren. de verzender kan met spf ed de ontvanger de mogelijkheid bieden een mail te controleren op legitimiteit. óf, en hoe dat die ontvanger dat doet is zijn zaak. sommigen negeren spf totaal en anderen gooien een hard fail weg. ik heb zelfs eens - heel lang geleden - een automatische mail van het ontvangende domain teruggehad met het verzoek een spf record in te stellen op mijn domain. mails vanaf een domain zonder spf werden door hen simpelweg niet geaccepteerd.
ik weet niet hoe ziggo als ontvangende partij zich hierin opstelt of gaat opstellen. ik heb net als jij een mailserver onder mijn eigen domeinnaam en gebruik mijn ziggo mailadres nauwelijks.
 
Maar als bedrijven het wel op orde hebben en meer legitieme verzenders doen dit dan scheelt dat toch spam?
Als je alles weigert wat niet aan de juiste voorwaarde voldoet scheelt dat toch?

Ik zie in mijn mailserver toch redelijk vaak afwijzingen omdat de hostnaam niet klopt bij het ip adres.
Is toch slordig als bedrijf.
Als je ze er over inlicht is het antwoord altijd "kijk eens in uw spambox" terwijl ze het zelf fout doen.
 
een automatische mail van het ontvangende domain teruggehad met het verzoek een spf record in te stellen op mijn domain.
Dat scheelt in elk geval spam dat van volledig verzonnen afzenders komt, dus ik kan dat ergens begrijpen. Het gros van onze klanten zijn kleine bedrijven met minder dan 10 werknemers. Tegenwoordig hebben veel van hen een eigen website en bijbehorend mailadres.

Het hele inrichten besteden ze uit aan een 'expert' en die maakt een spf record aan voor dat mail domein. Zo'n expert behoort zich te realiseren dat zo'n verzend IP kan veranderen en moet dan eigenlijk helemaal geen fail instellen voor die klant die er zelf geen verstand van heeft. Als ik in mijn maillog filter op spf fails, zie ik dat het bij veel van onze klanten niet goed ingesteld is.

Maar dat zijn kleine bedrijven. Van een groot bedrijf verwacht ik dat het wel in orde is. En het hoofddoel van mijn posting was het herkennen van phishing. Banken en andere targets van phishing hebben het meestal wel goed voor elkaar.
 
Terug
Bovenaan