DMARC poster, når de er konfigureret på den rigtige måde, kan gavne dig på mere end én måde. Det er et nyt område inden for e-mail-sikkerhed, der giver domæneejere et væld af oplysninger om deres e-mail-forsendelseskilder og ydeevne. DMARC-sårbarhed henviser til meget almindelige fejl, som brugere begår, mens de implementerer protokollen eller håndhæver den.

Sårbarheder i dit e-mail-godkendelsessystem kan spænde fra enkle fejl som forkert syntaks til mere komplekse fejl. Hvis du ikke løser disse problemer og konfigurerer din protokol korrekt, kan det under alle omstændigheder gøre dine bestræbelser på e-mailsikkerhed ugyldige, medmindre du løser disse problemer og konfigurerer din protokol korrekt.

Før vi analyserer de mulige sårbarheder, som du kan støde på på din rejse til e-mail-godkendelse, skal vi gennemgå nogle få grundlæggende begreber. De er:

Hvad er e-mail-godkendelse?
Hvordan autentificerer DMARC dine e-mails?
Indvirkningen af DMARC-sårbarheder på din levering af meddelelser

Hvad er e-mail-godkendelse?

Cyberkriminelle kan få økonomiske fordele ved at opsnappe e-mailkommunikation eller bruge social engineering til at snyde intetanende ofre.

E-mail-godkendelse henviser til specifikke verifikationssystemer, som domæneejere kan konfigurere for at fastslå legitimiteten af e-mails, der sendes fra deres domæne. Dette kan gøres ved hjælp af digitale signaturer i meddelelsesteksten, verifikation af returadresseadresser og/eller identifikationsjustering.

Når godkendelseskontrollen bekræfter, at meddelelsen er legitim, ryger e-mailen ind i modtagerens indbakke.

Hvordan autentificerer DMARC dine e-mails?

Når en virksomhed sender en besked til sine brugere, sendes e-mailen fra den afsendende server til den modtagende server for at fuldføre sin leveringsrejse. Denne e-mail har en Mail From: header som er den synlige header, der viser den e-mail-adresse, som e-mailen er sendt fra, og en Return-path-header som er en skjult header, der indeholder Return-path-adressen.

En angriber kan forfalske virksomhedens domæne for at sende e-mails fra det samme domænenavn, men det er meget sværere for dem at skjule Return-path-adressen.

Lad os tage et kig på denne mistænkelige e-mail:

Selvom den e-mailadresse, der er knyttet til meddelelsen, ser ud til at komme fra [email protected] hvilket føles ægte, kan det ved at inspicere Return-path-adressen hurtigt fastslås, at bounce-adressen ikke har nogen som helst forbindelse til company.com og blev sendt fra et ukendt domæne.

Denne bounce-adresse (også kaldet Return-path-adresse) bruges af servere, der modtager e-mail, til at finde en afsenders SPF record, mens de verificerer DMARC. Hvis afsenderens DNS indeholder en IP-adresse, der svarer til IP-adressen for den sendte e-mail, godkendes SPF og efterfølgende DMARC for den, ellers mislykkes det. I henhold til den DMARC-politik, der er konfigureret af det afsendende domæne, kan meddelelsen blive afvist, sat i karantæne eller leveret.

Alternativt kan DMARC også kontrollere for DKIM identifikatortilpasning for at verificere en e-mails ægthed.

Indvirkningen af DMARC-sårbarheder på din levering af meddelelser

Sandsynligheden for, at dine meddelelser leveres til dine klienter, afhænger i høj grad af, hvor præcist du har konfigureret din protokol. Eksisterende sårbarheder i din organisations e-mailsikkerhed kan svække chancerne for, at dine meddelelser bliver leveret.

Der er følgende klare tegn på mangler i dit DMARC-godkendelsessystem:

Problemer med levering af e-mail
Legitime meddelelser markeres som spam
DMARC-fejlmeddelelser ved brug af online værktøjer

Typer af DMARC-sårbarheder

DMARC-sårbarhed nr. 1: Syntaktiske fejl i DNS-poster

En DMARC-post er en TXT-post med mekanismer adskilt af semikolon, der angiver visse instruktioner til MTA'er, der modtager e-mail. Nedenstående er et eksempel:

v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100;

Små detaljer som f.eks. mekanismeadskillere (;) spiller en vigtig rolle for at afgøre, om din post er gyldig, og kan derfor ikke overses. Derfor anbefaler vi, at du for at slippe for gætterierne, at du bruger vores gratis DMARC-recordgenerator værktøj til at oprette en præcis TXT-record for dit domæne.

DMARC-sårbarhed nr. 2: Ingen DMARC-record fundet / DMARC-record mangler sårbarhed

Domæneejere kan ofte støde på en meddelelse, når de bruger onlineværktøjer, der fortæller dem, at deres domæne mangler en DMARC-record. Dette kan ske, hvis du ikke har en gyldig post offentliggjort på din DNS.

DMARC hjælper dig med at beskytte dit domæne og din organisation mod en lang række angreb, herunder phishing og direkte domæneforfalskning. Da vi lever i en digital verden med trusselsaktører, der forsøger at opsnappe e-mail-kommunikation hele vejen igennem, er vi nødt til at udvise forsigtighed og implementere forebyggende foranstaltninger for at stoppe disse angreb. DMARC er en hjælp i denne proces for at fremme et mere sikkert e-mail-miljø.

Vi har dækket en detaljeret artikel om reparation af den ingen DMARC-record fundet sårbarhed, som du kan læse ved at klikke på linket.

DMARC-sårbarhed nr. 3: Politik på ingen: kun overvågning

En hyppig misforståelse blandt brugerne er, at en DMARC-politik på p=none er nok til at beskytte deres domæne mod angreb. I virkeligheden er det kun en håndhævet politik for afvisning/karantæne, der kan hjælpe dig med at opbygge dit forsvar mod spoofing.

En lempelig politik kan dog være nyttig, hvis du kun ønsker at overvåge dine e-mail-kanaler uden at håndhæve beskyttelse. Det anbefales dog, at du hurtigt skifter til p=reject, når du er sikker.

Vi har placeret dette under kategorien DMARC-sårbarhed ud fra det kriterium, at de fleste brugere implementerer DMARC for at opnå en højere grad af beskyttelse mod angreb. Derfor kan en politik med nul håndhævelse ikke være af nogen værdi for dem.

DMARC-sårbarhed nr. 4: DMARC-politik ikke aktiveret

I lighed med den tidligere sårbarhed kan denne fejlprompt ofte være et resultat af manglen på en håndhævet politik for DMARC. Hvis du har konfigureret dit domæne med en ingen politik, hvilket gør det sårbart over for phishingangreb, anbefales det at skifte til p=reject/quarantine så hurtigt som muligt. For at gøre dette skal du blot foretage en lille justering af din eksisterende DNS-record for at ændre og opgradere din politiktilstand.

Vi har dækket et detaljeret dokument om, hvordan man løser den DMARC-politik ikke aktiveret fejl, som du kan se ved at klikke på linket.

Fejlfinding af DMARC-sårbarheder i realtid

For at løse disse problemer kan du overveje at implementere følgende trin i din organisation:

Lav en liste over alle dine autoriserede e-mail-afsenderkilder, og konfigurer et DMARC-overvågningsværktøj til at spore dem dagligt eller fra tid til anden
Tag en diskussion med dine e-mail-leverandører for at få bekræftet, om de understøtter praksis for e-mail-godkendelse
Få mere at vide om SPF, DKIM og DMARC, før du går videre til de næste trin.
Sørg for, at din SPF-post ikke indeholder SPF Permerror ved at implementere et SPF-flattening-værktøj
Gør din protokolimplementeringsproces problemfri med ekspertindsigt og vejledning fra DMARC-specialister ved at tilmelde dig en gratis DMARC-analysator. Dette kan hjælpe dig med at skifte til p=reject sikkert med realtidsdetektion af sårbarheder og angreb.

Beskyttelse af dit domæne er et af de første skridt til at bevare dit omdømme og din troværdighed. Gør e-mail-sikkerhed til en del af din sikkerhedsindstilling i dag!