Inlägg

Som DMARC-tjänsteleverantör får vi frågan mycket: "Om DMARC bara använder SPF- och DKIM-autentisering, varför ska vi bry oss om DMARC? Är inte det bara onödigt?"

På ytan kan det tyckas göra liten skillnad, men verkligheten är väldigt annorlunda. DMARC är inte bara en kombination av SPF- och DKIM-teknik, det är ett helt nytt protokoll i sig. Den har flera funktioner som gör det till en av de mest avancerade e-postautentiseringsstandarderna i världen och en absolut nödvändighet för företag.

Men vänta lite. Vi har inte svarat exakt varför du behöver DMARC. Vad erbjuder det att SPF och DKIM inte gör det? Det är ett ganska långt svar. för länge för bara ett blogginlägg. Så låt oss dela upp det och prata om SPF först. Om du inte känner till det, här är ett snabbt intro.

Vad är SPF?

SPF, eller Sender Policy Framework, är ett e-postautentiseringsprotokoll som skyddar e-postmottagaren från falska e-postmeddelanden. Det är i huvudsak en lista över alla IP-adresser som är auktoriserade att skicka e-post via dina (domänägarens) kanaler. När den mottagande servern ser ett meddelande från din domän kontrollerar den din SPF-post som publiceras på din DNS. Om avsändarens IP finns i denna "lista" levereras e-postmeddelandet. Om inte, avvisar servern e-postmeddelandet.

Som du kan se gör SPF ett ganska bra jobb med att hålla många obehagliga e-postmeddelanden som kan skada din enhet eller äventyra din organisations säkerhetssystem. Men SPF är inte alls så bra som vissa kanske tror. Det beror på att det har några mycket stora nackdelar. Låt oss prata om några av dessa problem.

Begränsningar för SPF

SPF-poster gäller inte för från-adressen

E-postmeddelanden har flera adresser för att identifiera avsändaren: från-adressen som du normalt ser och retursökvägens adress som är dold och kräver ett eller två klick för att visa. När SPF är aktiverat tittar den mottagande e-postservern på retursökvägen och kontrollerar SPF-posterna för domänen från den adressen.

Problemet här är att angripare kan utnyttja detta genom att använda en falsk domän i sin return path-adress och en legitim (eller legitim) e-postadress i avsnittet Från. Även om mottagaren skulle kontrollera avsändarens e-post-ID skulle de se från-adressen först och bryr sig vanligtvis inte om att kontrollera retursökvägen. Faktum är att de flesta människor inte ens är medvetna om att det finns något sådant som Return Path-adress.

SPF kan ganska enkelt kringgås genom att använda detta enkla trick, och det lämnar även domäner säkrade med SPF till stor del sårbara.

SPF-poster har en DNS-uppslagsgräns

SPF-poster innehåller en lista över alla IP-adresser som domänägaren har godkänt för att skicka e-post. Men de har en avgörande nackdel. Den mottagande servern måste kontrollera posten för att se om avsändaren har behörighet och för att minska belastningen på servern har SPF-poster en gräns på 10 DNS-sökningar.

Detta innebär att om din organisation använder flera tredjepartsleverantörer som skickar e-post via din domän kan SPF-posten sluta överskrida den gränsen. Om du inte är korrekt optimerad (vilket inte är lätt att göra själv) kommer SPF-poster att ha en mycket restriktiv gräns. När du överskrider den här gränsen anses SPF-implementeringen vara ogiltig och din e-post misslyckas med SPF. Detta kan potentiellt skada dina e-postleveranskostnader.

 

SPF fungerar inte alltid när e-postmeddelandet vidarebefordras

SPF har en annan kritisk felpunkt som kan skada din e-post leveransbarhet. När du har implementerat SPF på din domän och någon vidarebefordrar din e-post kan den vidarebefordrade e-postmeddelandet avvisas på grund av din SPF-policy.

Det beror på att det vidarebefordrade meddelandet har ändrat e-postmeddelandets mottagare, men e-postavsändarens adress förblir densamma. Detta blir ett problem eftersom meddelandet innehåller den ursprungliga avsändarens Från-adress men den mottagande servern ser en annan IP. IP-adressen för vidarebefordran av e-postservern ingår inte i SPF-posten för den ursprungliga avsändarens domän. Detta kan leda till att e-postmeddelandet avvisas av den mottagande servern.

Hur löser DMARC dessa problem?

DMARC använder en kombination av SPF och DKIM för att autentisera e-post. Ett e-postmeddelande måste passera antingen SPF eller DKIM för att passera DMARC och levereras framgångsrikt. Och det lägger också till en nyckelfunktion som gör den mycket effektivare än SPF eller DKIM ensam: Rapportering.

Med DMARC-rapportering får du daglig feedback om statusen för dina e-postkanaler. Detta inkluderar information om din DMARC-justering, data om e-postmeddelanden som misslyckades med autentisering och information om potentiella förfalskningsförsök.

Om du undrar vad du kan göra för att inte bli förfalskad, kolla in vår praktiska guide på de 5 bästa sätten att undvika e-postförfalskning.

Bryta ner DMARC-myter

För många människor är det inte omedelbart klart vad DMARC gör eller hur det förhindrar domänförfalskning, imitation och bedrägeri. Detta kan leda till allvarliga missuppfattningar om DMARC, hur e-postautentisering fungerar och varför det är bra för dig. Men hur vet du vad som är rätt och vad som är fel? Och hur kan du vara säker på att du implementerar det korrekt? 

PowerDMARC är här för att rädda! För att hjälpa dig att förstå DMARC bättre har vi sammanställt den här listan över de 6 vanligaste missuppfattningarna om DMARC.

Missuppfattningar om DMARC

1. DMARC är samma som ett skräppostfilter

Detta är en av de vanligaste sakerna människor får fel om DMARC. Skräppostfilter blockerar inkommande e-postmeddelanden som levereras till inkorgen. Det kan vara misstänkta e-postmeddelanden som skickas från någons domän, inte bara din. DMARC, å andra sidan, berättar för mottagande e-postservrar hur man hanterar utgående e-postmeddelanden som skickas från din domän. Skräppostfilter som Microsoft Office 365 ATP skyddar inte mot sådana cyberattacker. Om din domän är DMARC-framtvingad och e-postmeddelandet misslyckas med autentiseringen avvisar den mottagande servern den.

2. När du har konfigurerat DMARC är din e-post säker för alltid

DMARC är ett av de mest avancerade e-postautentiseringsprotokollen där ute, men det betyder inte att det är helt självförsörjande. Du måste regelbundet övervaka dina DMARC-rapporter för att se till att e-postmeddelanden från auktoriserade källor inte avvisas. Ännu viktigare är att du måste kontrollera om obehöriga avsändare missbrukar din domän. När du ser en IP-adress som gör upprepade försök att förfalska din e-post måste du vidta åtgärder omedelbart och få dem svartlistade eller nedtagna.

3. DMARC minskar min e-postavlivningsförmåga

När du konfigurerar DMARCär det viktigt att först ange principen till p=none. Detta innebär att alla dina e-postmeddelanden fortfarande levereras, men du får DMARC-rapporter om huruvida de har klarat eller misslyckats med autentiseringen. Om du under den här övervakningsperioden ser dina egna e-postmeddelanden misslyckas DMARC kan du vidta åtgärder för att lösa problemen. När alla dina auktoriserade e-postmeddelanden har validerats korrekt kan du framtvinga DMARC med en policy för p=karantän eller p=avvisa.

4. Jag behöver inte genomdriva DMARC (p = ingen räcker)

När du konfigurerar DMARC utan att tillämpa det (princip för p=none) levereras alla e-postmeddelanden från din domän – inklusive de som misslyckas med DMARC. Du kommer att få DMARC-rapporter men inte skydda din domän från några falska försök. Efter den första övervakningsperioden (förklaras ovan) är det absolut nödvändigt att ställa in din policy på p=karantän eller p=avvisa och genomdriva DMARC.

5. Endast stora märken behöver DMARC

Många mindre organisationer tror att det bara är de största, mest igenkännliga varumärkena som behöver DMARC-skydd. I verkligheten kommer cyberbrottslingar att använda alla affärsdomäner för att starta en falsk attack. Många mindre företag har vanligtvis inte dedikerade cybersäkerhetsteam, vilket gör det ännu enklare för angripare att rikta in sig på små och medelstora organisationer. Kom ihåg att varje organisation som har ett domännamn behöver DMARC-skydd!

6. DMARC-rapporter är lätta att läsa

Vi ser många organisationer implementera DMARC och få rapporterna skickade till sina egna e-postinkorgar. Problemet med detta är att DMARC-rapporter kommer i ett XML-filformat, vilket kan vara mycket svårt att läsa om du inte är bekant med det. Att använda en dedikerad DMARC-plattform kan inte bara göra installationsprocessen mycket enklare, utan PowerDMARC kan konvertera dina komplexa XML-filer till lättlästa rapporter med diagram, diagram och djupgående statistik.

 

E-post är ofta det första valet för en cyberbrottsliga när de lanseras eftersom det är så lätt att utnyttja. Till skillnad från brute-force-attacker som är tunga på processorkraft, eller mer sofistikerade metoder som kräver en hög nivå av skicklighet, kan domänförfalskning vara lika lätt som att skriva ett e-postmeddelande som låtsas vara någon annan. I många fall är att "någon annan" är en stor mjukvarutjänstplattform som människor förlitar sig på för att göra sitt jobb.

Vilket är vad som hände mellan den 15 och 30 april 2020, när våra säkerhetsanalytiker på PowerDMARC upptäckte en ny våg av phishing-e-postmeddelanden riktade mot ledande försäkringsbolag i Mellanöstern. Denna attack har bara varit en av många andra i den senaste ökningen av phishing- och förfalskningsfall under Covid-19-krisen. Redan i februari 2020 gick en annan stor phishing-bedrägeri så långt som att utge sig för att vara Världshälsoorganisationen och skickade e-postmeddelanden till tusentals människor som bad om donationer för coronavirushjälp.

I den senaste serien av incidenter fick användare av Microsofts Office 365-tjänst vad som verkade vara rutinmässiga uppdateringsmeddelanden om statusen för sina användarkonton. Dessa e-postmeddelanden kom från deras organisationers egna domäner och bad användare att återställa sina lösenord eller klicka på länkar för att visa väntande aviseringar.

Vi har sammanställt en lista över några av de e-posttitlar vi observerade användes:

  • Ovanlig inloggningsaktivitet för Microsoft-konto
  • Du har (3) meddelanden som väntar på leverans på din e-post [email protected]* Portal!
  • [email protected] väntar på Microsoft Office UNSYNC-meddelanden
  • Sammanfattningsmeddelande för återaktivering för [email protected]

*kontouppgifter som ändrats för användarnas integritet

Du kan också visa ett exempel på ett e-posthuvud som används i ett förfalskat e-postmeddelande som skickas till ett försäkringsbolag:

Mottagen: från [malicious_ip] (helo= malicious_domain)

id 1jK7RC-000uju-6x

för [email protected] Tor, 02 apr 2020 23:31:46 +0200

DKIM-Signatur: v=1; a=rsa-sha256; q=dns/txt; c=avslappnad/avslappnad;

Mottagen: från [xxxx] (port=58502 helo=xxxxx)

av malicious_domain med esmtpsa (TLSv1.2:ECDHE-RSA-AES2 56-GCM-SHA384:256)

Från: "Microsoft-kontoteam" 

Till: [email protected]

Angående: Microsoft Office-meddelande [email protected] 23:46 23:46

Datum: 2 apr 2020 22:31:45 +0100

Message-ID: <[email protected]>

MIME-Version: 1.0

Innehållstyp: text/html;

charset="utf-8"

Content-Transfer-Kodning: citerad utskrivbar

X-AntiAbuse: Den här rubriken lades till för att spåra missbruk, vänligen inkludera det med alla missbruksrapporten

X-AntiAbuse: Primärt värdnamn – malicious_domain

X-AntiAbuse: Ursprunglig domän – domain.com

X-AntiAbuse: Upphovsman/uppringare UID/GID – [47 12] / [47 12]

X-AntiAbuse: Avsändaradressdomän – domain.com

X-Get-Message-Sender-Via: malicious_domain: authenticated_id: [email protected]_domain

X-Autentiserad avsändare: malicious_domain: [email protected]_domain

X-Källa: 

X-Source-Args: 

X-Source-Dir: 

Mottagen SPF: misslyckas (domänen domain.com anger inte malicious_ip_address som tillåten avsändare) klient-ip= malicious_ip_address ; kuvert-från=[email protected]; helo=malicious_domain;

X-SPF-resultat: domänen domain.com anger inte malicious_ip_address som tillåten avsändare

X-Sender-Warning: Omvänd DNS-sökning misslyckades för malicious_ip_address (misslyckades)

X-DKIM-Status: ingen / / domain.com / / / /

X-DKIM-Status: pass / / malicious_domain / malicious_domain / / standard

 

Vårt säkerhets åtgärdscenter spårade e-postlänkarna till phishing-url:er som riktade sig till Microsoft Office 365-användare. Webbadresserna omdirigerades till komprometterade webbplatser på olika platser runt om i världen.

Genom att helt enkelt titta på dessa e-posttitlar skulle det vara omöjligt att säga att de skickades av någon som förfalskade din organisations domän. Vi är vana vid en stadig ström av arbets- eller kontorelaterade e-postmeddelanden som uppmanar oss att logga in på olika onlinetjänster precis som Office 365. Domänförfalskning drar nytta av det, vilket gör deras falska, skadliga e-postmeddelanden oskiljbara från äkta. Det finns praktiskt taget inget sätt att veta, utan en grundlig analys av e-postmeddelandet, om det kommer från en betrodd källa. Och med dussintals e-postmeddelanden som kommer in varje dag har ingen tid att noggrant granska var och en. Den enda lösningen skulle vara att använda en autentiseringsmekanism som skulle kontrollera alla e-postmeddelanden som skickas från din domän och blockera endast de som skickades av någon som skickade den utan tillstånd.

Autentiseringsmekanismen kallas DMARC. Och som en av de ledande leverantörerna av e-postsäkerhetslösningar i världen har vi på PowerDMARC gjort det till vårt uppdrag att få dig att förstå vikten av att skydda din organisations domän. Inte bara för dig själv, utan för alla som litar på och är beroende av dig för att leverera säkra, pålitliga e-postmeddelanden i deras inkorg, varje gång.

Du kan läsa om riskerna med förfalskning här: https://powerdmarc.com/stop-email-spoofing/

Ta reda på hur du kan skydda din domän från att förfalska och marknadsföra ditt varumärke här: https://powerdmarc.com/what-is-dmarc/