Computerbeveiliging
- Hoe je bad guys buiten de deur houdt
Toegevoegde waarde van DMARC naast DKIM
25-01-2021, 14:19 door Anoniem, 23 reacties
Wij hebben DKIM geïmplementeerd maar DMARC niet.
Wat zou de toevoeging van het implementeren van DMARC naast DKIM zijn?
Wat zou de toevoeging van het implementeren van DMARC naast DKIM zijn?
Reacties (23)
Door Anoniem: Wij hebben DKIM geïmplementeerd maar DMARC niet.
Wat zou de toevoeging van het implementeren van DMARC naast DKIM zijn?
Wat zou de toevoeging van het implementeren van DMARC naast DKIM zijn?
Weer een huiswerkvraag . Het bestaat niet dat je DKIM geïmplementeerd hebt maar geen idee hebt van de relatie met DMARC.
Door Anoniem: Wij hebben DKIM geïmplementeerd maar DMARC niet.
Wat zou de toevoeging van het implementeren van DMARC naast DKIM zijn?
Wat zou de toevoeging van het implementeren van DMARC naast DKIM zijn?
Je kunt ermee aangeven wat er met mail moet gebeuren die niet voldoet aan DMARC.
En je kunt rapporten vragen waardoor je een idee krijgt wat er allemaal uit jouw naam wordt verstuurd en wat ermee gebeurd.
https://dmarc.org/
Door Anoniem:
Weer een huiswerkvraag . Het bestaat niet dat je DKIM geïmplementeerd hebt maar geen idee hebt van de relatie met DMARC.
Door Anoniem: Wij hebben DKIM geïmplementeerd maar DMARC niet.
Wat zou de toevoeging van het implementeren van DMARC naast DKIM zijn?
Wat zou de toevoeging van het implementeren van DMARC naast DKIM zijn?
Weer een huiswerkvraag . Het bestaat niet dat je DKIM geïmplementeerd hebt maar geen idee hebt van de relatie met DMARC.
Nou dat kan best. Er bestaat immers geen verwijzing van DKIM naar DMARC, alleen van DMARC naar DKIM.
25-01-2021, 15:34 door
Briolet
Het verschil is hemelsbreed.
Als je alle mail handmatig controleert via de header, dan is er geen toegevoegde waarde voor de ontvanger omdat die precies ziet wat ook DMARC zal zien. DMARC maakt het echter mogelijk om mail geautomatiseerd af te wijzen.
Echter, vergeet niet dat DMARC ook waardevolle informatie geeft aan de domeineigenaar. DIe kan via DMARC in de dagelijkse rapporten zien dat er mail met gespoofde afzender verstuurd wordt. Als dat veel is, kunnen ze actie ondernemen.
DKIM geeft helemaal geen terugkoppeling.
Als je alle mail handmatig controleert via de header, dan is er geen toegevoegde waarde voor de ontvanger omdat die precies ziet wat ook DMARC zal zien. DMARC maakt het echter mogelijk om mail geautomatiseerd af te wijzen.
Echter, vergeet niet dat DMARC ook waardevolle informatie geeft aan de domeineigenaar. DIe kan via DMARC in de dagelijkse rapporten zien dat er mail met gespoofde afzender verstuurd wordt. Als dat veel is, kunnen ze actie ondernemen.
DKIM geeft helemaal geen terugkoppeling.
25-01-2021, 16:33 door
Erik van Straten
Naast wat Briolet zegt: een DKIM signature zegt niets als deze door een server is gezet die het vertrouwen niet waard is.
Zoals zo vaak bij security: het probleem is dat veel mensen niks snappen van non-repudiation (it wasn't me). Het is fijn dat jij de authenticiteit van mails verzonden door jouw server kunt aantonen, maar dat heeft nauwelijks zin als je niet kunt aantonen dat een specifieke e-mail niet door jouw organisatie is verzonden.
Je moet leren denken vanuit de ontvanger: hij/zij heeft er nul-komma-niets aan als zij/hij een mail ontvangt en nergens aan kan zien of die mail daadwerkelijk is verzonden door jouw organisatie.
Zie bijv. https://www.security.nl/posting/463813/Waarom+DMARC+%28%2BSPF+%2BDKIM%29 waarin ik een DKIM-signed mail ontving van ashley.nivers@gmail.com die helemaal niet door een gmail.com server was verzonden.
Overigens ben ik na die bijdrage veel minder enthousiast geworden over SPF+DKIM+DMARC, omdat het voor DMARC goed genoeg is als ofwel SPF ofwel DKIM klopt - en belangrijker, omdat steeds meer mensen mailen op kleine devices waar je zelden nog de SMTP-afzender ziet en de meeste gebruikers er geen idee van hebben welke policies zendende servers gebruiken, hoe goed "hun" ontvangende mailserver daarop checkt en wat er met een mail gebeurt (spam folder, tagging) als er iets niet klopt. En bij gecompromitteerde afzender mail accounts (o.a. BEC) of slecht geconfigureerde/corrupte bulkmailers helpen deze maatregelen ook al geen zier (integendeel, ze suggereren onterecht authenticiteit).
Zoals zo vaak bij security: het probleem is dat veel mensen niks snappen van non-repudiation (it wasn't me). Het is fijn dat jij de authenticiteit van mails verzonden door jouw server kunt aantonen, maar dat heeft nauwelijks zin als je niet kunt aantonen dat een specifieke e-mail niet door jouw organisatie is verzonden.
Je moet leren denken vanuit de ontvanger: hij/zij heeft er nul-komma-niets aan als zij/hij een mail ontvangt en nergens aan kan zien of die mail daadwerkelijk is verzonden door jouw organisatie.
Zie bijv. https://www.security.nl/posting/463813/Waarom+DMARC+%28%2BSPF+%2BDKIM%29 waarin ik een DKIM-signed mail ontving van ashley.nivers@gmail.com die helemaal niet door een gmail.com server was verzonden.
Overigens ben ik na die bijdrage veel minder enthousiast geworden over SPF+DKIM+DMARC, omdat het voor DMARC goed genoeg is als ofwel SPF ofwel DKIM klopt - en belangrijker, omdat steeds meer mensen mailen op kleine devices waar je zelden nog de SMTP-afzender ziet en de meeste gebruikers er geen idee van hebben welke policies zendende servers gebruiken, hoe goed "hun" ontvangende mailserver daarop checkt en wat er met een mail gebeurt (spam folder, tagging) als er iets niet klopt. En bij gecompromitteerde afzender mail accounts (o.a. BEC) of slecht geconfigureerde/corrupte bulkmailers helpen deze maatregelen ook al geen zier (integendeel, ze suggereren onterecht authenticiteit).
Door Anoniem:
Nou dat kan best. Er bestaat immers geen verwijzing van DKIM naar DMARC, alleen van DMARC naar DKIM.
Door Anoniem:
Weer een huiswerkvraag . Het bestaat niet dat je DKIM geïmplementeerd hebt maar geen idee hebt van de relatie met DMARC.
Door Anoniem: Wij hebben DKIM geïmplementeerd maar DMARC niet.
Wat zou de toevoeging van het implementeren van DMARC naast DKIM zijn?
Wat zou de toevoeging van het implementeren van DMARC naast DKIM zijn?
Weer een huiswerkvraag . Het bestaat niet dat je DKIM geïmplementeerd hebt maar geen idee hebt van de relatie met DMARC.
Nou dat kan best. Er bestaat immers geen verwijzing van DKIM naar DMARC, alleen van DMARC naar DKIM.
Beter lezen als je pedant wilt doen .
Ik schreef niet dat DKIM een technische link heeft met DMARC, maar dat mensen die zo ver zijn dat DKIM *implementeren* - wat de vragensteller claimt - echt al lang de relatie met DMARC zijn tegengekomen en daar niet naar hoeven vragen.
Dit is de zoveelste luie huiswerkstudent , en die ga ik niet helpen.
Door Anoniem: Wij hebben DKIM geïmplementeerd maar DMARC niet.
Wat zou de toevoeging van het implementeren van DMARC naast DKIM zijn?
Naast de reports, zoals anderen al schreven, lost DMARC vooral het probleem op waarbij een ontvangende mailserver geen actie heeft voor mails zonder DKIM signature. Een mailserver kan er bijvoorbeeld voor kiezen om mails zonder DKIM handtekening bij de spam te zetten, of zelfs in de inbox te zetten als de spam score niet te hoog is. Via DMARC kan je als organisatie zelf aangeven wat er moet gebeuren wanneer een signature mist: niets, quarantaine of reject.Wat zou de toevoeging van het implementeren van DMARC naast DKIM zijn?
Door Erik van Straten:
Je moet leren denken vanuit de ontvanger: hij/zij heeft er nul-komma-niets aan als zij/hij een mail ontvangt en nergens aan kan zien of die mail daadwerkelijk is verzonden door jouw organisatie.
Het begint al met het foute beeld dat DMARC, DKIM en SPF iets zeggen over door welke ORGANISATIE een mail al of niet verzonden is. Nee! Het zegt iets over het afzender DOMEIN. En een domein correspondeert niet 1:1 met een organisatie.Je moet leren denken vanuit de ontvanger: hij/zij heeft er nul-komma-niets aan als zij/hij een mail ontvangt en nergens aan kan zien of die mail daadwerkelijk is verzonden door jouw organisatie.
26-01-2021, 13:37 door
Briolet
Door Erik van Straten: Overigens ben ik na die bijdrage veel minder enthousiast geworden over SPF+DKIM+DMARC, omdat het voor DMARC goed genoeg is als ofwel SPF ofwel DKIM klopt - en belangrijker, omdat steeds meer mensen mailen op kleine devices waar je zelden nog de SMTP-afzender ziet …
Dat één van beiden genoeg is, is inderdaad een gemis. Veel mensen forwarden hun mail echter en dan op zo'n manier dat de SPF check op de afzendernaam niet meer klopt. Als ik een mailing verstuur zie ik dan ook een groot percentage SPF fouten. Ik kan me voorstellen dat deze fouten geaccepteerd worden als DKIM klopt.
Een DKIM ondertekening overleeft het forwarden altijd, mits de titel of inhoud niet aangepast wordt. Dat hadden ze altijd verplicht kunnen maken. Ik heb me verbaast bij de Duitse DHL en de Duitse Post. Beiden sturen ze de tracking code naar klanten via dezelfde mailserver. Op beide domeinen zat een DMARC beveiliging met 'reject' policy. Echter voegde deze mailserver geen DKIM ondertekening toe. Als je die mail op de verkeerde manier forwarde (met behoud van oude afzender), kwam hij nooit aan.
Probleem is dat de gewone gebruiker onbekend is met het fenomeen DKIM. GMail toonde een paar jaar geleden bij hun webmail wel de DKIM informatie via een pull-down menu vanaf de afzender naam. Dit hebben ze weer verwijderd. Ik gok omdat dit alleen verwarde vragen opriep bij gewone gebruikers.
Voor Thunderbird was er een plug-in die de DKIM informatie direct boven de mailinhoud plaatste. Maar sinds de strengere eisen aan plug-ins is er geen nieuwe versie meer van gemaakt.
Hoe mailservers omgaan met een foute DMARC weet ik niet. Onze mailserver doet ook echt een reject als dat de policy was. Ik zie ze dan nooit. Maar misschien dat sommige mailservers ze toch doorlaten en alleen in de spamfolder gooien. Dan haal je idd de hele beveiliging onderuit. (Wat nu ook als gebeurd bij SPF met een hard fail instelling. Die komt vaak toch aan bij veel mailservers.)
26-01-2021, 13:39 door
Erik van Straten
Door Anoniem:
Je hebt natuurlijk 100% gelijk, suf dat ik dat niet zo verwoord heb...Door Erik van Straten:
Je moet leren denken vanuit de ontvanger: hij/zij heeft er nul-komma-niets aan als zij/hij een mail ontvangt en nergens aan kan zien of die mail daadwerkelijk is verzonden door jouw organisatie.
Het begint al met het foute beeld dat DMARC, DKIM en SPF iets zeggen over door welke ORGANISATIE een mail al of niet verzonden is. Nee! Het zegt iets over het afzender DOMEIN. En een domein correspondeert niet 1:1 met een organisatie.Je moet leren denken vanuit de ontvanger: hij/zij heeft er nul-komma-niets aan als zij/hij een mail ontvangt en nergens aan kan zien of die mail daadwerkelijk is verzonden door jouw organisatie.
Door Anoniem: Wij hebben DKIM geïmplementeerd maar DMARC niet.
Wat zou de toevoeging van het implementeren van DMARC naast DKIM zijn?
Wat zou de toevoeging van het implementeren van DMARC naast DKIM zijn?
KORT: DKIM en SPF kunnen DMARC / DMARC DNS entrys raadplegen om te zien of de ontvangen mail wel echt vanaf het orginele domein verstuurd is of dat een mail gespoofed is. Je verbeterd als het waren de DKIM en SPF functionaliteiten. Dit gaat geautomatiseerd en de gebruiker achter de mail server hoeft verder niets te doen (behalve beheer/servicedesk bellen bij onregelmatigheden).
LANG:
(Ik ben zelf vrij simpel dus probeer ik het in "simpel" uit te leggen) In iedergeval zover ik weet, is de 5 stack om je mail (server) "schoon" te houden "DKIM, DMARC, SPF, DANE, STARTLS":
MailServer A (stelt DMARC en DMARC dns entry's in) -> stuurt mail -> Mail Server B onvangt mail (SPF + DKIM op server B controlleerd de DMARC/DMARC dns entrys en DNS public keys.) Aan de hand hiervan word de mail in quarantaine geplaatst of doorgestuurd naar de mailbox van de gebruiker. Zo voorkom je spoofing van mail. Alleen de geauthoriseerde mail door (dmarc) mail server A word als echt gezien door (spf+dkim) mailserver B.
Maar je stelt DMARC, SPF, DNS ook allemaal op je eigen server en dns in aangezien jij het volgende wilt:
- Je wilt kunnen aantonen dat de mail wel echt van jou komt (authorise mail).
- Je wilt kunnen verifieren dat de ontvangen mail wel echt van de orginele afzender komt (check authorised mail).
- SPF;
SPF valideert of een mail echt afkomstig is van het orginele "door DMARC geauthoriseerde" domein. Dus voorkomt het Email Spoofing (en een deel van spam).
- DKIM;
DKIM doet een beetje hezelfde als SPF alleen gebruikt het vooral de Public Key (die geregistreerd staat in de dns registers) om te controlleren of de mail echt is.
- DMARC;
DMARC maakt op basis van DNS registraties een soort stempel. (De mail sturende server steld dit in) Hierdoor kunnen andere mailservers met SPF zien of de mail wel echt van het goede orginele en door DMARC geauthoriseerde domein komt.
- DANE;
DANE is een protocol wat je TLS certificaten laat binden aan DNS registraties. Dit gebeurd met DNSSEC. Het idee is (in dit geval) dat je hiermee STARTTLS kan forceren en handhaven.
- STARTTLS;
STARTTLS is een protocol dat er voor zorgt dat mail getransporteerd word over encrypted verbindingen "SSL/TLS verbindingen". Het heet STARTTLS omdat de TLS connectie eerst opgezet word voordat de mail verstuurd word, denk hierbij aan een HSTS achtige werking (lekker belangrijk). Het idee is dat je mail verstuurd over een beveiligde SSL/TLS verbinding net als met het HTTP over TLS/SSL (HTTPS) principe.
Nogmaals, verbeter me als ik foutjes maak, het word gewaardeerd ;)
- RAMLETHAL
Door Anoniem:
(Ik ben zelf vrij simpel dus probeer ik het in "simpel" uit te leggen) In iedergeval zover ik weet, is de 5 stack om je mail (server) "schoon" te houden "DKIM, DMARC, SPF, DANE, STARTLS":
Deze maatregelen hebben niets te maken met het "schoon houden van je server" (wat je er ook onder wilt verstaan).(Ik ben zelf vrij simpel dus probeer ik het in "simpel" uit te leggen) In iedergeval zover ik weet, is de 5 stack om je mail (server) "schoon" te houden "DKIM, DMARC, SPF, DANE, STARTLS":
Het heeft meer van doen met het "schoon houden van je reputatie". En misschien andermans servers.
Door Anoniem:
Het heeft meer van doen met het "schoon houden van je reputatie". En misschien andermans servers.
Dankje voor de verbetering!Door Anoniem:
(Ik ben zelf vrij simpel dus probeer ik het in "simpel" uit te leggen) In iedergeval zover ik weet, is de 5 stack om je mail (server) "schoon" te houden "DKIM, DMARC, SPF, DANE, STARTLS":
Deze maatregelen hebben niets te maken met het "schoon houden van je server" (wat je er ook onder wilt verstaan).(Ik ben zelf vrij simpel dus probeer ik het in "simpel" uit te leggen) In iedergeval zover ik weet, is de 5 stack om je mail (server) "schoon" te houden "DKIM, DMARC, SPF, DANE, STARTLS":
Het heeft meer van doen met het "schoon houden van je reputatie". En misschien andermans servers.
29-01-2021, 16:10 door
Erik van Straten
Door Anoniem: In iedergeval zover ik weet, is de 5 stack om je mail (server) "schoon" te houden "DKIM, DMARC, SPF, DANE, STARTLS":
SPF helpt je server schoonhouden doordat het zogenaamde "Joe jobs" helpt voorkomen (https://en.wikipedia.org/wiki/Joe_job). SPF checkt of mail vanaf het domein gebruikt in envelope from (ook bekend als Return path) verzonden mag worden vanaf het IP-adres van de zendende mailserver.Stel jij bent eigenaar van example.com. Een cybercrimineel verstuurt bergen spam via in een botnet opgenomen PC's (met IP-adressen die afwijken van die van jouw mailserver) met envelope-from *@example.com. Ontvangende mailservers, die mail eerst accepteren en er daarna pas achterkomen dat een mail niet kan worden afgeleverd (bijv. mailbox vol) zullen de foutmelding dan naar jouw server "terug" sturen. Dit kan tot een soort DDoS leiden (voordat SPF bestond heb ik een mailservertje beheerd die soms meer dan 1 foutmelding per seconde ontving waarvan een deel in bestaande mailboxen terechtkwam).
Door Anoniem: - Je wilt kunnen aantonen dat de mail wel echt van jou komt (authorise mail).
- Je wilt kunnen verifieren dat de ontvangen mail wel echt van de orginele afzender komt (check authorised mail).
Niet van jou of van de originele afzender, maar (zoals anoniem 26-01-2021, 10:48 terecht opmerkte) van het afzender-domein.- Je wilt kunnen verifieren dat de ontvangen mail wel echt van de orginele afzender komt (check authorised mail).
Door Anoniem: - SPF;
SPF valideert of een mail echt afkomstig is van het orginele "door DMARC geauthoriseerde" domein. Dus voorkomt het Email Spoofing (en een deel van spam).
SPF was er veel eerder dan DMARC en werkt ook zonder. SPF checkt of mail vanaf het domein gebruikt in envelope from (ook bekend als Return path) verzonden mag worden vanaf het IP-adres van de zendende mailserver. Daardoor werkt forwarding niet meer (tenzij de forwarding mailserver ten minste het domein in envelope-from wijzigt, maar om foutmeldingen te kunnen retourneren moet die mailserver dan "stateful" gaan werken, en niet elke mailadmin wordt daar blij van).SPF valideert of een mail echt afkomstig is van het orginele "door DMARC geauthoriseerde" domein. Dus voorkomt het Email Spoofing (en een deel van spam).
Door Anoniem: - DKIM;
DKIM doet een beetje hezelfde als SPF alleen gebruikt het vooral de Public Key (die geregistreerd staat in de dns registers) om te controlleren of de mail echt is.
DKIM is een protocol voor het digitaal ondertekenen van (een deel van) de onderdelen van een e-mail. Meestal doet de zendende mailserver dat. Probleem: het domein van de server die ondertekent mag afwijken van het domein in het From: veld dat een deel van de e-mail programma's laten zien, waardoor een DKIM signature door een server van een spammer kan zijn gezet, een niet vertrouwde partij dus. Een digitale handtekening zegt helemaal niets als je de zetter daarvan niet vertrouwt. Een ander probleem is dat sommige mailservers kleine wijzigingen in mails kunnen aanbrengen (onzichtbaar voor de ontvanger) die ertoe leiden dat de digitale handtekening niet meer klopt.DKIM doet een beetje hezelfde als SPF alleen gebruikt het vooral de Public Key (die geregistreerd staat in de dns registers) om te controlleren of de mail echt is.
Door Anoniem: - DMARC;
DMARC maakt op basis van DNS registraties een soort stempel. (De mail sturende server steld dit in) Hierdoor kunnen andere mailservers met SPF zien of de mail wel echt van het goede orginele en door DMARC geauthoriseerde domein komt.
Het primaire doel van DMARC is domain alignment. Bij een afdwingende instelling vereist DMARC dat ofwel het SPF domein (in envelope from) ofwel het domein van de DKIM-signerende server, of beide, overeenkomen met het domein in het vaak aan de gebruiker getoonde From veld.DMARC maakt op basis van DNS registraties een soort stempel. (De mail sturende server steld dit in) Hierdoor kunnen andere mailservers met SPF zien of de mail wel echt van het goede orginele en door DMARC geauthoriseerde domein komt.
Omdat SPF en/of DKIM "onderweg kapot kunnen gaan" vindt DMARC het nog acceptabel als één van die twee checks een negatief resultaat oplevert (als beide niet valideren heb je pech, tenzij het om spoofing gaat natuurlijk). Het nadeel hiervan is dat een spammer/spoofer maar één van beide (SPF of DKIM) hoeft te kunnen vervalsen.
Zie https://www.security.nl/posting/463813/Waarom+DMARC+%28%2BSPF+%2BDKIM%29 voor uitgebreide info.
Door Erik van Straten:
Stel jij bent eigenaar van example.com. Een cybercrimineel verstuurt bergen spam via in een botnet opgenomen PC's (met IP-adressen die afwijken van die van jouw mailserver) met envelope-from *@example.com. Ontvangende mailservers, die mail eerst accepteren en er daarna pas achterkomen dat een mail niet kan worden afgeleverd (bijv. mailbox vol) zullen de foutmelding dan naar jouw server "terug" sturen. Dit kan tot een soort DDoS leiden (voordat SPF bestond heb ik een mailservertje beheerd die soms meer dan 1 foutmelding per seconde ontving waarvan een deel in bestaande mailboxen terechtkwam).
Omdat SPF en/of DKIM "onderweg kapot kunnen gaan" vindt DMARC het nog acceptabel als één van die twee checks een negatief resultaat oplevert (als beide niet valideren heb je pech, tenzij het om spoofing gaat natuurlijk). Het nadeel hiervan is dat een spammer/spoofer maar één van beide (SPF of DKIM) hoeft te kunnen vervalsen.
Zie https://www.security.nl/posting/463813/Waarom+DMARC+%28%2BSPF+%2BDKIM%29 voor uitgebreide info.
Dankje voor de verbeteringen en toelichtingen! Ik zie trouwens dat ik STARTTLS verkeerd geschreven heb, sawry.Door Anoniem: In iedergeval zover ik weet, is de 5 stack om je mail (server) "schoon" te houden "DKIM, DMARC, SPF, DANE, STARTLS":
SPF helpt je server schoonhouden doordat het zogenaamde "Joe jobs" helpt voorkomen (https://en.wikipedia.org/wiki/Joe_job). SPF checkt of mail vanaf het domein gebruikt in envelope from (ook bekend als Return path) verzonden mag worden vanaf het IP-adres van de zendende mailserver.Stel jij bent eigenaar van example.com. Een cybercrimineel verstuurt bergen spam via in een botnet opgenomen PC's (met IP-adressen die afwijken van die van jouw mailserver) met envelope-from *@example.com. Ontvangende mailservers, die mail eerst accepteren en er daarna pas achterkomen dat een mail niet kan worden afgeleverd (bijv. mailbox vol) zullen de foutmelding dan naar jouw server "terug" sturen. Dit kan tot een soort DDoS leiden (voordat SPF bestond heb ik een mailservertje beheerd die soms meer dan 1 foutmelding per seconde ontving waarvan een deel in bestaande mailboxen terechtkwam).
Door Anoniem: - Je wilt kunnen aantonen dat de mail wel echt van jou komt (authorise mail).
- Je wilt kunnen verifieren dat de ontvangen mail wel echt van de orginele afzender komt (check authorised mail).
Niet van jou of van de originele afzender, maar (zoals anoniem 26-01-2021, 10:48 terecht opmerkte) van het afzender-domein.- Je wilt kunnen verifieren dat de ontvangen mail wel echt van de orginele afzender komt (check authorised mail).
Door Anoniem: - SPF;
SPF valideert of een mail echt afkomstig is van het orginele "door DMARC geauthoriseerde" domein. Dus voorkomt het Email Spoofing (en een deel van spam).
SPF was er veel eerder dan DMARC en werkt ook zonder. SPF checkt of mail vanaf het domein gebruikt in envelope from (ook bekend als Return path) verzonden mag worden vanaf het IP-adres van de zendende mailserver. Daardoor werkt forwarding niet meer (tenzij de forwarding mailserver ten minste het domein in envelope-from wijzigt, maar om foutmeldingen te kunnen retourneren moet die mailserver dan "stateful" gaan werken, en niet elke mailadmin wordt daar blij van).SPF valideert of een mail echt afkomstig is van het orginele "door DMARC geauthoriseerde" domein. Dus voorkomt het Email Spoofing (en een deel van spam).
Door Anoniem: - DKIM;
DKIM doet een beetje hezelfde als SPF alleen gebruikt het vooral de Public Key (die geregistreerd staat in de dns registers) om te controlleren of de mail echt is.
DKIM is een protocol voor het digitaal ondertekenen van (een deel van) de onderdelen van een e-mail. Meestal doet de zendende mailserver dat. Probleem: het domein van de server die ondertekent mag afwijken van het domein in het From: veld dat een deel van de e-mail programma's laten zien, waardoor een DKIM signature door een server van een spammer kan zijn gezet, een niet vertrouwde partij dus. Een digitale handtekening zegt helemaal niets als je de zetter daarvan niet vertrouwt. Een ander probleem is dat sommige mailservers kleine wijzigingen in mails kunnen aanbrengen (onzichtbaar voor de ontvanger) die ertoe leiden dat de digitale handtekening niet meer klopt.DKIM doet een beetje hezelfde als SPF alleen gebruikt het vooral de Public Key (die geregistreerd staat in de dns registers) om te controlleren of de mail echt is.
Door Anoniem: - DMARC;
DMARC maakt op basis van DNS registraties een soort stempel. (De mail sturende server steld dit in) Hierdoor kunnen andere mailservers met SPF zien of de mail wel echt van het goede orginele en door DMARC geauthoriseerde domein komt.
Het primaire doel van DMARC is domain alignment. Bij een afdwingende instelling vereist DMARC dat ofwel het SPF domein (in envelope from) ofwel het domein van de DKIM-signerende server, of beide, overeenkomen met het domein in het vaak aan de gebruiker getoonde From veld.DMARC maakt op basis van DNS registraties een soort stempel. (De mail sturende server steld dit in) Hierdoor kunnen andere mailservers met SPF zien of de mail wel echt van het goede orginele en door DMARC geauthoriseerde domein komt.
Omdat SPF en/of DKIM "onderweg kapot kunnen gaan" vindt DMARC het nog acceptabel als één van die twee checks een negatief resultaat oplevert (als beide niet valideren heb je pech, tenzij het om spoofing gaat natuurlijk). Het nadeel hiervan is dat een spammer/spoofer maar één van beide (SPF of DKIM) hoeft te kunnen vervalsen.
Zie https://www.security.nl/posting/463813/Waarom+DMARC+%28%2BSPF+%2BDKIM%29 voor uitgebreide info.
30-01-2021, 12:42 door
Briolet
Door Erik van Straten:SPF helpt je server schoonhouden doordat het zogenaamde "Joe jobs" helpt voorkomen (https://en.wikipedia.org/wiki/Joe_job). SPF checkt of mail vanaf het domein gebruikt in envelope from (ook bekend als Return path) verzonden mag worden vanaf het IP-adres van de zendende mailserver.
Op papier is dat alles mooi, maar in de praktijk werkt het slecht omdat te veel ontvangende mailservers er nagenoeg niets mee doen. Als je een ’soft-fail’ instelt, telt het meestal een beetje mee met de spamscore, maar meestal niet dusdanig dat een faal altijd in de spamfolder komt.
En als je een “fail’ instelt in je domein (ook wel hard-fail genoemd), dan bounced de mail nog zelden, is mijn ervaring.
Als voorbeeld:
Ik had een paar jaar geleden iets bij een webshop besteld die een SPF hard-fail ingesteld had op hun domeinnaam. De bevestiging van de bestelling kwam van een IP adres die niet op hun lijst stond. Onze mailserver blokkeerde die mail en in het log zag ik dat dit door hun foute SPF instelling kwam. Ik heb ze er per mail op geattendeerd.
Een paar dagen later belde de eigenaar me en bedankte me voor de waarschuwing. Hij vertelde me dat hij van meer klanten gehoord had, dat mail niet aankwam. Echter, toen ik twee jaar later weer iets bestelde, bleek hun fout er nog steeds in te zitten.
Als de meeste mailservers zo’n SPF hard-fail zouden bouncen, had deze webshop het probleem al lang verholpen. Nu gaat het maar bij een klein deel van de klanten mis en denkt hij misschien dat deze kleine groep klanten die geen bestelbevestiging per mail krijgen hun mailsysteem zelf niet goed ingesteld hebben.
Waarschijnlijk een kip-ei probleem. Er zijn zoveel bedrijven die hun SPF beleid niet op orde hebben dat strikte naleving van de regels, te veel reguliere mail zouden blokkeren. Mailservers treden daardoor niet streng op met fouten waardoor verzenders geen reden zien om hun mail systeem goed op orde te brengen. Dus als je je eigen mail systeem wel op orde hebt en bewust een hard-fail instelt, dan zal het gros van de gespoofde mail nog steeds bezorgd worden.
Wat dat betreft ben ik blij met DMARC. Ik hoop dat er met een schone lei begonnen wordt en een fail bij DMARC wel echt leid tot een reject als dat ingesteld is.
31-01-2021, 15:02 door
Erik van Straten
Door Briolet: Wat dat betreft ben ik blij met DMARC. Ik hoop dat er met een schone lei begonnen wordt en een fail bij DMARC wel echt leid tot een reject als dat ingesteld is.
Daarop inhakend: in https://www.security.nl/posting/618851/Bellingcat-journalisten+doelwit+van+phishingaanval+met+zeroday bleek phishing mogelijk ondanks DMARC, waar ik later in https://www.security.nl/posting/632307/Helft+overheidsdomeinen+kwetsbaar+voor+e-mailspoofing#posting632442 meer over schreef.Later is aan deze kwetsbaarheid in OpenDMARC, Fix multiple addresses in From vulnerability (meer dan 1 domeinnaam in header-From), op 17 september 2019 "CVE-2019-16378" toegekend (bron: https://github.com/trusteddomainproject/OpenDMARC/pull/48). Onderaan die pagina wordt verwezen naar een patch waarbij er een instelling "RejectMultiValueFrom" zou zijn toegevoegd aan "opendmarc.conf", maar als ik Google naar "RejectMultiValueFrom" krijg ik 0 resultaten (dat komt niet vaak voor ;-)
Bovendien lijken er alleen nog wat users actief in maillijsten gearchiveerd onder http://www.trusteddomain.org/mailman/listinfo/ (https werkt niet), de devs en announce lists lijken dood sinds eind 2017.
Weet jij of linux distro's gebruikmaken van OpenDMARC - of van een andere implementatie (welke?), en of tegenwoordig mails met meer (of minder) dan één geldige domeinnaam in From: by default worden afgekeurd?
31-01-2021, 17:50 door
Briolet
Door Erik van Straten:Weet jij of linux distro's gebruikmaken van OpenDMARC - of van een andere implementatie (welke?), en of tegenwoordig mails met meer (of minder) dan één geldige domeinnaam in From: by default worden afgekeurd?
Geen idee. Onze mailserver draait op een Synology NAS en gebruikt OpenDMARC versie 1.3.2. (uit 4 maart 2017)
Op SourceForge is dat ook de nieuwste versie. Ik zie dat de code ook op GitHub staat. Daar was versie 1.3.2 ook de nieuwste, maar is er op 28 jan 2021 een versie 1.4.0 bij gekomen. Dus blijkbaar de eerste update in bijna 4 jaar tijd. (Hoewel er tussendoor wel patches uitgegeven zijn als ik jouw verhaal lees)
In de releasenotes lees ik o.a.:
Add "RejectMultiValueFrom" configuration option to reject messages with multi-valued From fields.
Dat is de bug die je beschrijft. Daar wordt het echter geen bugfix genoemd, maar een optie die je kunt aanzetten.https://github.com/trusteddomainproject/OpenDMARC/blob/master/RELEASE_NOTES
31-01-2021, 19:08 door
Erik van Straten
Door Briolet:
https://github.com/trusteddomainproject/OpenDMARC/blob/master/RELEASE_NOTES
Dank voor de update!Add "RejectMultiValueFrom" configuration option to reject messages with multi-valued From fields.
Dat is de bug die je beschrijft. Daar wordt het echter geen bugfix genoemd, maar een optie die je kunt aanzetten.https://github.com/trusteddomainproject/OpenDMARC/blob/master/RELEASE_NOTES
Met een CVSS 3.x Severity Base Score van 9.8 (CRITICAL) zijn er mensen die dit een zeer erstige kwetsbaarheid vinden (https://nvd.nist.gov/vuln/detail/CVE-2019-16378). M.i. terecht, want hiermee kan een spoofer DMARC (en dus SPF en DKIM eronder) volledig omzeilen.
Bij SNYK wordt er voor de volgende XX-injectie gewaarschuwd:
https://snyk.io/vuln/SNYK-PYTHON-MODOBOADMARC-537532
Er bestaat nog geen fix voor deze kwetsbaarheid in modoboa-dmarc.
luntrus
https://snyk.io/vuln/SNYK-PYTHON-MODOBOADMARC-537532
Er bestaat nog geen fix voor deze kwetsbaarheid in modoboa-dmarc.
luntrus
Door Anoniem: Bij SNYK wordt er voor de volgende XX-injectie gewaarschuwd:
https://snyk.io/vuln/SNYK-PYTHON-MODOBOADMARC-537532
Er bestaat nog geen fix voor deze kwetsbaarheid in modoboa-dmarc.
luntrus
https://snyk.io/vuln/SNYK-PYTHON-MODOBOADMARC-537532
Er bestaat nog geen fix voor deze kwetsbaarheid in modoboa-dmarc.
luntrus
modoboa-dmarc is nog in BETA en kan op dit moment alleen XML rapporten parsen...
Heeft dus niks met een kwetsbaarheid in DMARC te maken!
https://github.com/modoboa/modoboa-dmarc
Door Anoniem:
Beter lezen als je pedant wilt doen .
Ik schreef niet dat DKIM een technische link heeft met DMARC, maar dat mensen die zo ver zijn dat DKIM *implementeren* - wat de vragensteller claimt - echt al lang de relatie met DMARC zijn tegengekomen en daar niet naar hoeven vragen.
Dit is de zoveelste luie huiswerkstudent , en die ga ik niet helpen.
AmenDoor Anoniem:
Nou dat kan best. Er bestaat immers geen verwijzing van DKIM naar DMARC, alleen van DMARC naar DKIM.
Door Anoniem:
Weer een huiswerkvraag . Het bestaat niet dat je DKIM geïmplementeerd hebt maar geen idee hebt van de relatie met DMARC.
Door Anoniem: Wij hebben DKIM geïmplementeerd maar DMARC niet.
Wat zou de toevoeging van het implementeren van DMARC naast DKIM zijn?
Wat zou de toevoeging van het implementeren van DMARC naast DKIM zijn?
Weer een huiswerkvraag . Het bestaat niet dat je DKIM geïmplementeerd hebt maar geen idee hebt van de relatie met DMARC.
Nou dat kan best. Er bestaat immers geen verwijzing van DKIM naar DMARC, alleen van DMARC naar DKIM.
Beter lezen als je pedant wilt doen .
Ik schreef niet dat DKIM een technische link heeft met DMARC, maar dat mensen die zo ver zijn dat DKIM *implementeren* - wat de vragensteller claimt - echt al lang de relatie met DMARC zijn tegengekomen en daar niet naar hoeven vragen.
Dit is de zoveelste luie huiswerkstudent , en die ga ik niet helpen.
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Digital Designer
Ben jij een Grafisch vormgever, UI-designer, Game-artist of gewoon een ‘self-proclaimed creative genius’, die op zoek is naar een leuke en uitdagende baan waarin je al je creativiteit kwijt kan?Je werkt samen met onze developers en UI/UX-designer aan onze Gamified Cybersecurity Challenges welke jij voorziet van de mooiste designs.
Cyber Security Trainer
"You know that feeling after you have been to the cinema and seen an exciting movie? It's the same after this training. I can only say that this is probably the BEST TRAINING that I've ever done!!!”
Are you ready for a challenge?
Senior Full Stack Developer
Als full stack developer bij Certified Secure maak je de mooiste cybersecurity challenges die onze deelnemers wereldwijd uitdagen en inspireren. Alle challenges zijn gebaseerd op actuele kwetsbaarheden, je komt dus telkens nieuwe technieken tegen, van machine learning tot web assembly, van Swift UI tot GCP.