Om het gebruiksgemak te vergroten, de website te kunnen analyseren en om advertenties te kunnen beheren maakt Security.NL gebruik van cookies. Door gebruik te blijven maken van deze website, of door op de akkoord button te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer weten over cookies? Bekijk dan ons cookieoverzicht.
Nieuws Achtergrond Community
Inloggen | Registreren
Computerbeveiliging - Hoe je bad guys buiten de deur houdt

Toegevoegde waarde van DMARC naast DKIM

Reageer met quote
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?
NXDOMAIN
Wat zijn ASN-1 parser attacks en hoe bescherm je je er tegen?
Reacties (23)
Reageer met quote
25-01-2021, 14:24 door Anoniem
Door Anoniem: Wij hebben DKIM geïmplementeerd maar DMARC niet.
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.
Reageer met quote
25-01-2021, 14:29 door Anoniem
Door Anoniem: Wij hebben DKIM geïmplementeerd maar DMARC niet.
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/
Reageer met quote
25-01-2021, 15:14 door Anoniem
Door Anoniem:
Door Anoniem: Wij hebben DKIM geïmplementeerd maar DMARC niet.
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.
Reageer met quote
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.
Reageer met quote
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).
Reageer met quote
25-01-2021, 17:06 door Anoniem
Door Anoniem:
Door Anoniem:
Door Anoniem: Wij hebben DKIM geïmplementeerd maar DMARC niet.
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.
Reageer met quote
25-01-2021, 18:00 door Anoniem
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.
Reageer met quote
26-01-2021, 10:48 door Anoniem
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.
Reageer met quote
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.)
Reageer met quote
26-01-2021, 13:39 door Erik van Straten
Door Anoniem:
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 hebt natuurlijk 100% gelijk, suf dat ik dat niet zo verwoord heb...
Reageer met quote
26-01-2021, 19:51 door Anoniem
Door Anoniem: Wij hebben DKIM geïmplementeerd maar DMARC niet.
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
Reageer met quote
27-01-2021, 11:57 door Anoniem
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).
Het heeft meer van doen met het "schoon houden van je reputatie". En misschien andermans servers.
Reageer met quote
27-01-2021, 17:02 door Anoniem
Door Anoniem:
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).
Het heeft meer van doen met het "schoon houden van je reputatie". En misschien andermans servers.
Dankje voor de verbetering!
Reageer met quote
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.

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).

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.

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.

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.
Reageer met quote
29-01-2021, 18:00 door Anoniem
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.

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).

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.

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.

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.
Reageer met quote
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.
Reageer met quote
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?
Reageer met quote
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
Reageer met quote
31-01-2021, 19:08 door Erik van Straten
Door Briolet:
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
Dank voor de update!

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.
Reageer met quote
31-01-2021, 23:59 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
Reageer met quote
01-02-2021, 16:06 door Anoniem
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

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
Reageer met quote
03-02-2021, 14:43 door Anoniem
Door Anoniem:
Door Anoniem:
Door Anoniem:
Door Anoniem: Wij hebben DKIM geïmplementeerd maar DMARC niet.
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.
Amen
Reageer met quote
03-02-2021, 18:26 door Anoniem
Het bestaat niet dat je DKIM geïmplementeerd hebt maar geen idee hebt van de relatie met DMARC.
Best wel hoor. Hier ook: ik heb DKIM in een vroeg stadium toegepast, en daarna er nooit meer aandacht aan gegeven.
Voor zover ik weet, weet ik niks van DMARC.
Reageren
Ondersteunde bbcodes
Bold: [b]bold text[/b]
Italic: [i]italic text[/i]
Underline: [u]underlined text[/u]
Quote: [quote]quoted text[/quote]
URL: [url]https://www.security.nl[/url]
Config: [config]config text[/config]
Code: [code]code text[/code]

Je bent niet ingelogd en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.

Je reactie is verstuurd en wordt zo spoedig mogelijk gemodereerd.

Verder
captcha
Nieuwe code
Preview Reageren
Zoeken
search
Vacature
Image

Senior Security Consultant

Als security consultant bij Cegeka speel je een uitermate belangrijke rol in het veilig houden van de bedrijven in Nederland en de Nederlandse maatschappij. Vandaar ook dat Cegeka dit hoog op de agenda heeft staan. Wij doen dit door, in close cooperation, onze klanten advies te geven op strategisch, tactisch en operationeel niveau.

Lees meer

Wat baart jou momenteel meer zorgen, traditionele criminaliteit of cybercrime?

11 reacties
Aantal stemmen: 834
Image
BYOD
04-03-2021 door Anoniem

Wanneer mensen een eigen device (BYOD) mee nemen naar werk: hoe bescherm jullie je daartegen? (Ben zelf tegen het gebruik van ...

8 reacties
Lees meer
De verkiezingsprogramma's doorgelicht: Deel 4 digitalisering
20-02-2021 door Redactie

Een digitaal paspoort, recht op betaalbaar en snel internet, 'digitale inburgering' of digitaal stemmen, het zijn slechts een ...

8 reacties
Lees meer
Prive bestanden van OneDrive worden openbaar bij gebruik van Versiegeschiedenis
02-03-2021 door hny3425

Als je voor OneDrive betaalt, kun je de functie Versiegeschiedenis gebruiken. Erg handig als je een vorige versie van een ...

26 reacties
Lees meer
Certified Secure LIVE Online training
Nieuwe Huisregels en Privacy Policy

Op 5 december 2017 hebben we een nieuwe versie van onze huisregels en privacy policy ingevoerd. Om verder te kunnen gaan dien je eenmalig akkoord te gaan met de nieuwe huisregels van Security.NL.

Op 24 mei 2018 hebben we, in het kader van de AVG, onze privacy policy bijgewerkt. Om verder te kunnen gaan dien je eenmalig akkoord te gaan met de bijgewerkte privacy policy. Heb je vragen neem dan contact op met info@security.nl.

Verzenden
Privacy Policy

Op 24 mei 2018 hebben we, in het kader van de AVG, onze privacy policy bijgewerkt. Om verder te kunnen gaan dien je eenmalig akkoord te gaan met de bijgewerkte privacy policy. Heb je vragen neem dan contact op met info@security.nl.

Verzenden
Inloggen

Bedankt! Je kunt nu inloggen op je account.

Wachtwoord vergeten?
Nieuwe code captcha
Inloggen

Wachtwoord Vergeten

Wanneer je hieronder het e-mailadres van je account opgeeft wordt er een nieuwe activatielink naar je gestuurd. Deze link kun je gebruiken om een nieuw wachtwoord in te stellen.

Nieuwe code captcha
Stuur link

Password Reset

Wanneer je het juiste e-mailadres hebt opgegeven ontvang je automatisch een nieuwe activatielink. Deze link kan je gebruiken om een nieuw wachtwoord in te stellen.

Sluiten
Registreren bij Security.NL

Geef je e-mailadres op en kies een alias van maximaal 30 karakters.

Nieuwe code captcha
Verzenden

Registreren

Je hebt je succesvol aangemeld. Voordat je je account kunt gebruiken moet deze eerst geactiveerd worden. Dit kan je zelf doen middels de activatielink die naar het opgegeven e-mailadres is verstuurd.

Sluiten
Over Security.NL
Huisregels
Privacy Policy
Adverteren
© 2001-2021 Security.nl - The Security Council
RSS Twitter