Kom i kontakt med oss!

Kontakta vår support!

SPF, DKIM och DMARC – som att borsta tänderna…. Del 1 av 4

SPF, DKIM och DMARC – som att borsta tänderna… Del 1 av 4 Jag tror att du som läser detta borstade tänderna i morse! De flesta gör det utan att ens tänka på det, det är en självklarhet för att annars får vi diverse problem. Utöver att vi luktar illa så kommer våra tänder att falla ur efter ett tag. Och även om det inte är en personlig favorit så går vi då och då till tandläkaren.

Men hur ser självklarheterna ut när det kommer till e-post? Jag tänker i en serie bloggar beskriva hur dessa tekniker fungerar och varför det är viktigt att ha dem på plats. Följ gärna serien eller ta del av detta och mycket mer i en workshop vi på Altitude 365 utvecklat.

Historik

Det har funnits olika varianter av system för att skicka elektroniska meddelande sedan 1960-talet, på den tiden rörde det sig dock om meddelande mellan användare i slutna system och det första steget för att skicka epost mellan olika system får anses vara vad som beskrivs i RFC 524. Denna beskriver hur man med hjälp av två kommandon i File Transfer Protocol, FTP, ska kunna utväxla meddelande med varann. Detta blev dock aldrig någon succé. Det var för komplicerat så den egentliga starten på epost som vi känner det idag fick vänta.

Året var 1982 då Jonathan B. Postel (enligt undertecknad är just namnet Postel roande med tanke på ämnet) publiserade RFC 821. Den beskriver protokollet Simple Mail Transfer Protocol. Det kan i detta sammanhang vara värt att notera att om man söker i RFC 821 efter ord som security eller secure så får man exakt noll träffar. Som sagt året var 1982 och världen bestod enligt ett stort gäng långhåriga hippies på Berkeley ungefär av ett stort snällt gäng andra långhåriga hippies. Säkerhet och var någon kom ifrån var helt enkelt inte prioriterat.

I april 2001 ersattes RFC 821 med RFC 2821. Säkerhet hade blivit ett begrepp och nu finns det faktiskt ett avsnitt som handlar om just säkerhet beskrivet.

För att avsluta historielektionen så ersattes även RFC 2821, denna gången med RFC 5321. Även om denna fått några tillägg så är det här moderna epostsystem har sina rötter, året för denna är 2008. Och i avsnitt 7.1 står det att läsa följande:

 

SMTP mail is inherently insecure in that it is feasible for even fairly casual users to negotiate directly with
 receiving and relaying SMTP servers and create messages that will trick a naive recipient into believing 
that they came from somewhere else.
 Constructing such a message so that the "spoofed" behavior cannot be detected by an expert is somewhat 
more difficult, but not sufficiently so as to be a deterrent to someone who is determined and knowledgeable.

Det vill säga, vi har med ett ganska osäkert protokoll att göra när det kommer till att veta vem som verkligen är avsändaren till det vi läser.

För att råda bot på detta och flera andra problem (SPAM tex) så har andra tekniker introducerats. Nedan följer de olika teknikerna och en förklaring.

Sender Policy Framework, SPF

Sender policy Framework, eller SPF, är första initiativet att råda bot på så kallade spoofade mail. Det nämns första gången år 2000 men det är 2002 det tar fart och ett år senare bidrog bland andra Meng Wong (se fun facts för mer info om denna driftige man) till att det blev kommersiellt gångbart. I april 2004 blev det en standard.

Vad är SPF?

Låt oss börja med vad SPF inte är. SPF är inte en antispam lösning. SPF kommer inte stoppa varken inkommande eller utgående spam. Så vad är det då? SPF är en lösning på så kallad spoofing, dvs att någon utger sig för att vara någon annan än den de är. Så när någon, kan vara någon som skickar spam men nuförtiden mycket oftare någon som ägnar sig åt mer avancerade saker, skickar epost så kommer SPF kolla om dessa brev kommer ifrån den domän som de säger att de kommer ifrån.

Hur fungerar SPF?

Man kan enkelt se det som att när någon ringer dig så tar du telefonkatalogen (ja det fanns en gång en bok som hette så) och kollar personens namn och ser om det matchar det telefonnummer som just nu ringer. I epostvärlden så kommer den mottagande servern att se att det kommer ett mail ifrån en viss domän (ifrån avsändaradressen som presenteras i SMTP-konversationen), därefter kolla i denna domäns DNS efter ett SPF-record för att se om det matchar den IP-adress som brevet just kom ifrån. I fallet att det matchar så går epost direkt till användarens inkorg och i fallet att det inte matchar så läggs det i skräppost eller tas bort.

Risker och problem med SPF

SPF har en del begränsningar och risker som kan komma väldigt ovälkommet om det slås på utan att man vet vad man gör. Om vi går tillbaka till exemplet med att någon ringer till dig och du slår upp telefonkatalogen men inte hittar något nummer så kan man säga att man faktiskt inte vet mer än innan man kollade och därmed inte kan fatta ett mycket klokare beslut i frågan om personen som ringer verkligen är den som den utger sig för att vara. Men kanske säger det ändå något… Man undrar ju lite om varför den inte finns i telefonkatalogen. Det är på samma sätt med SPF. Att inte ha ett SPF är inte bra. Okej, då tänker vän av ordning att det ska vi ha. Vi tar och matar in IP-adressen för vår mailserver i vår DNS och så kör vi. Detta är potentiellt väldigt dåligt!

I fallet att vi har fler servrar eller tjänster (nyhetsbrev mm) som nu inte är med i listan så blir dessa sannolikt skickade till skräppost eller borttagna. Det är därför väldigt viktigt att få med samtliga utgående servrar när man lägger upp ett SPF-record.

En begränsning som finns i SPF är att antalet namnuppslag som kan läggas in i ett record. Man kan inte lägga in fler än tio namnuppslag. Värt att notera är att om man lägger in en URL till servrar, tex, spf.protection.outlook.com, som är SPF för Office 365, så slås detta upp till flera servrar.

Ett annat scenario som inte fungerar så bra är vidarebefordring.

Det vill säga att vår server skickar till en annan mailserver, här finns en vidarebefordring till ytterligare en server. Den första transporten går bra men när det vidarebefordras så uppstår problemet om den andra servern inte finns med i vårt SPF-record. Eftersom vidarebefordring är något alla användare kan göra är det i princip omöjligt att lösa detta.

Hur ser ett SPF-record ut och hur fungerar det?

För att skapa ett bra SPF-record vill vi uppnå följande:

·       Alla utgående mailservrar för vår domän är definierade

·       Vi vill för alla andra ha en så hård policy som möjligt (mer om detta nedan)

·       Informera berörda om att vi som organisation använder SPF och varför

Det första punkten är ganska given, att ha alla servrar definierade är en förutsättning för att epost ska komma fram till mottagaren.

Att ha en så ”hård policy” som möjligt syftar på vad mottagande epostservrar ska göra med epost som påstår sig komma från oss men som inte är med bland våra definierade servrar i vårt SPF-record.

Punkten kring information är den absolut svåraste, speciellt i en större organisation. Men vi bör ska en intern policy för hela vår organisation för att förhindra att någon avdelning på egen hand upphandlar något system som vi inte kan hantera. Just gällande SPF brukar detta inte vara ett oöverkomligt problem men vi kommer senare i denna serien se vikten av detta och hur detta kan spara oss stora pengar.

Vi på Altitude 365 har naturligtvis ett SPF-record, nedan tittar vi på hur det ser ut och analyserar de ingående delarna. För att göra det en smula mer förklarande så har jag modifierat det något från verkligheten.

”v=spf1 include:spf.protection.outlook.com include: 90.224.80.216 include:servers.mcsv.net include:spf.fouredge.se -all”

SyntaxBeskrivning
v=spf1Identifierar TXT record I DNS som SPF version 1
include:spf.protection.outlook.comGodkänner epost från dessa servrar att skicka epost
include: 90.224.80.216Godkänner epost från serven med denna ip att skicka epost
-allAlla icke deffinierade servrar ska anses som icke godkända och epost från dessa ska leda till en hard fail

För ytterligare information om syntax för SPF-record läs gärna: http://www.openspf.org/SPF_Record_Syntax

För att skapa ditt eget SPF-record använd gärna denna guide (men iaktta försiktighet enligt tidigare beskrivna risker):

https://www.spfwizard.net/

Samanfattning SPF

För att sammanfatta detta kan vi säga att SPF är ett enkelt sätt att införa en viss kontroll på vem som får skicka som vår domän, vi styr detta via våra egna DNS-record. SPF på egen hand kommer sannolikt inte lösa några stora problem men idag tillhör detta en av självklarheterna för varje seriös e-postdomän. Till hör du dem som ännu ej har ett SPF-record eller ett svagt SPF-record så finns det hjälp att få. Utöver de länkar du ser nedan så erbjuder Altitude 365 en workshop som är inriktad på just detta. I denna får du dessutom kontroll och kunskap om DKIM och DMARC också.

Nästa del i denna bloggserie kommer handla om just DKIM- Stay tuned!

Ytterligare läsning

Altitude 365 Workshop, Hur skickas e-post från era domäner? Vår workshop kring e-postsäkerhet med fokus på SPF, DKIM och DMARC riktar sig till er som vill säkra och skydda era domäner mot bland annat spoofing. 

Set up SPF in Office 365 to help prevent spoofing

Grundläggande information om SPF

En intervju med Meng Wong, bland annat om hand samarbete med Microsoft

7 Kommentarer

  1. Sture Haglund

    Tack för väldigt bra information!
    Hittade ett litet skönhetsfel i att ”publicera” stavas fel i illustrationerna. Går det att åtgärda enkelt så rekommenderar jag att du gör det annars överlever man som det är också.

    Svara
  2. Magnus

    När kommer nästa delarna ? 🙂

    Svara
  3. Yngve Spång

    Vad händer med fortsättningen 2,3,4/4
    Mycket informativ första del

    Svara
  4. Joakim

    Bra skrivet….nu undrar man ju bara var del 2-4 hittas?

    Svara

Skicka kommentar

E-postadressen publiceras inte. Obligatoriska fält är märkta *