Skydda din e-post från spoofing, del 1: SPF

Jag utgår från 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 som annars leder till diverse problem. Utöver att vi luktar illa 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 artikelserie beskriva hur SPF, DKIM och DMARC fungerar och varför det är viktigt att ha dem på plats.

Det har funnits olika sorters 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 e-post 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 varandra. Detta blev dock aldrig någon succé. Systemet var för komplicerat, så den egentliga starten på e-post 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) publicerade RFC 821. Den beskriver protokollet Simple Mail Transfer Protocol. Det kan i detta sammanhang vara värt att notera att om man söker efter ord som security eller secure i RFC 821 så får man exakt noll träffar. Säkerhet och var någon kom frå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. För att avsluta historielektionen så ersattes även RFC 2821, denna gång av RFC 5321. Även om denna fått några tillägg sedan dess, så är det här som moderna e-postsystem har sina rötter. Året för detta är 2008 och i avsnitt 7.1 står följande att läsa:

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

Vi har alltså 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 (t ex spam) så har andra tekniker introducerats. Nedan följer de olika teknikerna och en förklaring.

Sender Policy Framework, SPF
Sender policy Framework (SPF) är första initiativet för att råda bot på så kallade spoofade mejl. Det nämns första gången år 2000, men det är först 2002 det tar fart och ett år senare bidrog bland andra Meng Wong till att det blev kommersiellt gångbart. I april 2004 blev detta standard.

När någon skickar e-post kommer SPF att kolla om dessa brev kommer från den domän som de säger sig komma från.

Vad är SPF?
Låt oss börja med vad SPF inte är. SPF är inte en antispamlösning. SPF kommer inte stoppa vare sig inkommande eller utgående spam. SPF är en lösning på så kallad spoofing, det vill säga att någon utger sig för att vara någon annan än den de är. Så när någon skickar e-post kommer SPF att kolla om dessa brev kommer från den domän som de säger sig komma frå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 e-postvärlden kommer den mottagande servern att se att det kommer ett mejl från en viss domän (frå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. Om detta matchar går e-post direkt till användarens inkorg, i annat fall hamnar det i skräppost eller raderas.

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 telefonkatalogen: Om du inte hittar något nummer kommer du inte vara mycket klokare än innan. Men kanske att detta säger dig något ändå? Till exempel varför personen som ringde inte ens finns i telefonkatalogen. Det fungerar på samma sätt med SPF. Att inte ha en SPF är alltså inte att rekommendera. Då tänker vän av ordning att ”Det ska vi ha! Vi matar in IP-adressen för vår mejlserver i vår DNS och sedan kör vi!” Detta är potentiellt väldigt dåligt.

I de fallen då vi har flera servrar eller tjänster (t ex nyhetsbrev) som inte är med på listan så blir dessa sannolikt skickade till skräppost eller borttagna. Det är därför 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 man inte kan lägga in fler än tio namnuppslag. Värt att notera är att om man lägger in en URL till servrar, t ex 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ärskilt bra är vidarebefordring.

Det vill säga att vår server skickar vidare till en annan mejlserver, här finns en vidarebefordring till ytterligare en server. Den första transporten går bra, men när mejlet vidarebefordras 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 mejlservrar 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

Den första punkten är ganska given – att ha alla servrar definierade är en förutsättning för att e-post ska komma fram till mottagaren. Att ha en så ”hård policy” som möjligt syftar på vad mottagande e-postservrar ska göra med e-post som påstår sig komma från oss, men som inte finns 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 ha 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. Gällande just SPF brukar detta inte vara ett oöverkomligt problem, men vi kommer senare i denna serie att se vikten av detta och hur detta kan spara oss stora summor pengar.

Vi på Exobe 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 begripligt 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”

Sammanfattning 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 mejl som vår domän, vilket vi styr 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. Tillhö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 vi på Exobe en workshop som är inriktad på just detta. I denna får du dessutom kontroll och kunskap även om DKIM och DMARC.