Dags att göra rätt saker

Ha det så skönt – och glöm inte handduken

Lagom till semestern vill jag ge er något att fundera på där ni ligger i hängmattan och har det skönt. Något som jag själv har haft anledning att fundera på en tid. Vad skulle ni göra om det som inte får hända ändå skulle inträffa? Nu när telefonen tystnat och ni inte längre är absorberade av vardagens ständiga möten och pockande ärenden så får ni kanske tid att reflektera: Vad borde jag egentligen göra i höst?

Till vardags finns det massor av saker som vi skjuter framför oss därför att de inte är ”måsten”, bara ”borden”, sådant som vi skulle vilja göra men inte riktigt hinner med. Som att höja grundsäkerheten i systemen. Vad har hänt sedan det gjordes senast? Har det kommit några nya standarder som jag behöver känna till? Hur skyddar jag vår infrastruktur för DNS från att bli hi-jackad? Har jag infört moderna säkerhetsfunktioner för mejl och webb? Har vi signerat våra domäner med DNSSEC? Vilka funktioner har blivit så inaktuella att de inte längre är till någon hjälp utan snarare förvärrar situationen den dagen något inträffar? Krypterar vi information vid lagring och under transport? Har vi fortfarande kontroll över all information? Har någon annan kontroll över vår information.

Det är inte så att jag tycker att man ska jobba hela semestern och därmed slippa undan små grodorna, säcklöpningen eller kubbspelet med den odrägliga svågern. Inte alls. Men när alla deckare är slut och ni inte kan komma överens om reglerna i Monopol så kanske det är skönt med lite enskild kontemplation.

Själv skriver jag listor. Det är mitt sätt att få ner och sortera tankarna. Andra ritar skisser med boxar, fyrkanter, och pilar. Så, fram med block och penna, lägg dig i hängmattan, sätt dig i skuggan under trädet i skogen, vid stranden på kobben, på verandan på sommarstället, på caféet i världsmetropolen eller något annat av de många smultronställen där du trivs som bäst, och rita lite. Fundera på de stora frågorna. På vad du skulle vilja göra, i stället för att alltid vara tvungen att göra det du måste.

Här är min lista över några av de viktigaste funktionerna för att uppnå en säkrare infrastruktur för kommunikation över internet.

Infrastruktur:

• IPv4 och IPv6 för samtliga funktioner (DNS, mejl, webb)
• Konnektivitet (robusthet)

Domännamnsystemet (DNS):

• Name server configuration
• DNS/DNSSEC
• CAA

Webbtjänster:

Protokoll

• HTTP
• HTTPS

Säker transport

• TLS
• Certificates
• DANE
• Cookies
• Mixed Content

Modernare säkerhetsfunktioner

• Strict Transport Security
• Content Security Policy
• Subresource Integrity
• Expect CT

Applikationssäkerhet

• Frame Options
• XSS Protection
• Content Type Options

Mejl:

Transportskydd (SMTP)

• STARTTLS
• Certificates
• MTA-STS
• TLS-RPT
• DANE

Autentisering och policyer

• SPF
• DMARC

Sommaren är den allra bästa tiden för långsiktig planering och reflektion. Lägg upp en plan för en bättre internetnärvaro. Kolla regelbundet status med Hardenize.com.

Använd säker DNS

Det är genom uppslagningar i domännamnssystemet DNS som det går att hitta fram till rätt dator på internet när man till exempel surfar eller skickar e-post till en viss domän. DNS är en gigantisk databas som översätter domännamn till IP-adresser, det vill säga de unika nummerserier som unikt identifierar internetuppkopplade datorer. Man kan likna det vid hur en telefonkatalog ”översätter” namn till telefonnummer.

Säker DNS, eller DNSSEC som det förkortas, är en funktion som gör internet säkrare genom att försvåra manipulation av den information som trafikerar domännamnssystemet. Med DNSSEC signeras DNS-uppslagningar med kryptografiska nycklar och på så sätt säkerställs att svaren verkligen kommer från rätt källa och inte har ändrats under överföringen till mottagarens resolver.

Genom att använda DNSSEC motverkar du möjligheten att utnyttja några av de mest kända och största hoten mot DNS, cacheförgiftning (cache poisoning) och farmning (pharming).

Cacheförgiftning innebär att en situation skapas, antingen genom en attack eller oavsiktligt, som förser en namnserver med DNS-data som inte kommer från någon auktoritativ källa. Ett av de mest välkända exemplen på detta är den 2008 mycket uppmärksammade Kaminskybuggen.

Farmning innebär att någon kan få själva innehållet i DNS att peka på felaktiga servrar. Rent konkret innebär det att en webbadress för exempelvis en bank kan pekas om till en helt annan webbserver, men för besökaren ser det i adressfältet fortfarande ut som att det är rätt server i andra änden. På det sättet kan en besökare aningslöst lämna ifrån sig känslig information till en angripare.

Många andra internetprotokoll än webb och mejl är också beroende av DNS, medan DNS-information i resolvrarna har kommit att bli så sårbar för attacker att den inte längre går att lita på. Den ökade säkerhet som DNSSEC tillför gör att många attacker inte längre får någon effekt.

Även om man försöker täppa till säkerhetshål så gott det går med de program och verktyg som används vid DNS-uppslagningar, ligger grundproblemet i hur DNS fungerar. Det råder ingen tvekan om att DNS behöver bli säkrare. DNSSEC är en långsiktig lösning som skyddar mot flera olika typer av manipulering av DNS-frågor och -svar under kommunikationen mellan olika servrar i domännamnssystemet.

Det har inte gått någon längre tid sedan den allvarliga attacken med BGP-kapning riktad mot MyEtherwallet, där angriparen använde BGP-läckor för att kapa MyEhterwallets namnservrar på Amazons Route53 och ersätta dem med sina egna falska namnservrar som dirigerade om offer till sina egna falska plånböcker och därmed dränerade deras plånböcker. Det startade en hel del diskussion när det var aktuellt, men nu har den i princip dött ut. Folk slår sig till ro och fortsätter med sina liv. Det som inte alla har förstått är att attacken faktiskt har förändrat spelreglerna något, och det betyder att alla behöver ompröva sin syn på DNSSEC.

Varför spelar DNSSEC någon roll i ett hack som utfördes via BGP-kidnappning? Det går att diskutera hur lätt det är att utföra BGP-kidnappningar, men det finns trots allt inget definierat säkerhetsprotokoll på plats för att förhindra sådana attacker. Förra året fick EasyDNS några av sina IP-adressutrymmen kapade och det tog dem ungefär en vecka för att reda ut det. Den kunde tacka sin lyckliga stjärna att det handlade om outnyttjade IP-adresser, men hela händelsen fick många att inse hur dålig autentiseringen av routingmeddelanden verkligen är. Det har länge talats om att införa ett protokoll som tagits fram av IETF, RPKI, men det är långt ifrån implementerat, och frågan är om det ens någonsin kommer att bli det på grund av att det brister i bland annat skalbarhet.

Kvar har vi DNSSEC som huvudspår för att försvara oss mot dessa och andra attacker.

Hade MyEtherwallet DNSSEC-signerat sin zon, och dessutom använt TLSA pinning för sina TLS certifikat skulle attacken begränsats. Två av de resolver-tjänster som hämtade de falska IP-adresserna för MyEhterwallet var Google Public DNS och Cloudflare 1.1.1.1, båda DNSSEC-kompetenta resolvrar som istället för falska adresser skulle ha returnerat felmeddelanden.

Office365 och DMARC

Microsoft har gjort ett bra jobb för att stödja SPF, DKIM och DMARC i sin Office365 miljö.

Två saker är dock värt att notera:

1. Office365 behandlar en DMARC reject policy på samma sätt som en karantänpolicy, dvs inkommande mejl som inte klarar DMARC validering, sätts i karantän iställer för att kastas.
2. DKIM signeringen behöver justeras för att fungera tillsammans med en striktare, "quarantine" eller "reject", policy i DMARC.

Punkt ett

Detta är oftast inte ett problem, utan kan ibland till och med vara en fördel. Då det leder till att det är betydligt lättare att felsöka problem med inkommande DMARC, då mejlen finns i karantän och inte är permanent avvisade.

Punkt två

Vanligtvis dyker problemen upp först då en organisation som använder Office365, aktiverar DMARC med en "riktig" policy, dvs "quarantine" eller "reject".

Problemet manifesterar sig vanligen att mottagare, som validerar DMARC, inte längre kan ta emot (om policyn är satt till "reject") mail, alterntivt att inkommande mejl sätt i karantän (om policyn är satt till "quarantine").

Problemet beror i korthet på att defaultinställningen för DKIM i Office365 signerar "fel" domän. Korrigeras detta, så kommer också DMARC att fungera.

Lösning

Publicera två stycken DNS CNAME resource records som pekar på de två DKIM nycklar Microsoft har publicerat för er domän.

selector1._domainkey.xpd.se. IN CNAME selector1-xpd-se._domainkey.xpd.onmicrosoft.com.
selector2._domainkey.xpd.se. IN CNAME selector1-xpd-se._domainkey.xpd.onmicrosoft.com.

(Jag använder XPD i mina exempel, även om vi inte använder Office365, för att göra det hela lite enklare att förstå)

Förfarandet ovan finns väldigt bra beskrivet av Microsoft i " Use DKIM to validate outbound email sent from your custom domain in Office 365", dock verkar väldigt få hitta den artikeln eller ens känna till problemet innan de drabbas av det.

TL;DR

För varje ny mejlkund i Office365, så sätts en subdomän upp under onmicrosoft.com.

I detta exempel så skulle det ha inneburit att subdomänen xpd.onmicrosoft.com skapas.

Microsoft aktiverar DKIM automatiskt för alla nya kunder, vilket innebär att två stycken DKIM nyckelpar skapas och att de publika nycklarna publiceras som:

selector1-xpd-se._domainkey.xpd.onmicrosoft.com.
selector2-xpd-se._domainkey.xpd.onmicrosoft.com.

(Att två stycken nycklar skapas, selector1 och selector2, är för att facilitera automatisk nyckelrotation enligt Microsoft)

Office365 kommer nu att att genomföra DKIM signering med ovanstående nycklar för domänen xpd.onmicrosoft.com för utgående mejl från Office365:

From: Fredrik Soderblom <fredrik@xpd.se>
.
.
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=xpd.onmicrosoft.com;
    s=selector1-xpd-se;
    h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
    bh=iWawpsGgHFHdTHWJP334GNNkbPbgdgt0PrAlsT3Lzvg=;

Problemet med detta är att DKIM signeringen kommer endast att vara giltig för domänen xpd.onmicrosoft.com, vilket inte matchar min emailadress (fredrik@xpd.se), vilket i sig inte är ett problem när DMARC inte används.

Men, som leder till ovanstående problem (Punkt två), när DMARC aktiveras i "reject" eller "quarantine" läge, vilket då innebär att DMARC kommer att kräva att domänen som använts för DKIM signering matchar domänen i From: adressen.

Går inte den matchningen att göra, så klarar inte heller mejlet DMARC validering och kommer antingen att kastas (om policyn är "reject") eller att sättas i karantän (om policyn är "quarantine").

Varför låser du inte dörren?

Flera av de problem som drabbar små och stora företag och myndigheter till exempel skadlig kod eller ransomware, felaktiga utbetalningar har inte alltför sällan sitt ursprung ur nätfiske eller lösenordsfiske (phishing) eller det som kallas "whaling" och som till stor del bygger på att lura mottagaren på ett eller annat sätt, bland annat via förfalskade mejl.

Du har garanterat sett dem, du utlovas ett överdåd av pengar i arv från din saligt avlidne släkting i ett fjärran land, eller bilagor till mejl som innehåller vad som förefaller vara en faktura som behöver betalas skyndsamt.

Inte alltid, men ofta förefaller dessutom mejlen att komma från din egen organisation. "Hur är det möjligt?" kanske du tänker. Det är en mycket rimlig fundering, då skydd för detta har funnits i flera år nu, men väldigt få företag har infört det.

För att reda ut hur vi hamnade här så behöver vi backa ett antal år, tillbaka till 1982 då Jonathan Postel först skrev det förslag till standard som kom att kallas "Simple Mail Transfer Protocol" eller i korthet, SMTP.

Problemet är att protokollet utformades i en era då Internet var relativt litet och förhållandevis säkert. Det var till och med så säkert, så att en av de första programvarorna som implementerade SMTP protokollet, Eric Allmans Sendmail, hade en bakdörr som gjorde det möjligt för Eric att logga in med högsta möjliga privilegier på den server som körde Sendmail för att kunna hjälpa till vid eventuella problem.

Vad är då trasigt med SMTP? Ja, rätt mycket med dagens mått mätt.

Du kan med ytterst sparsamma kunskaper enkelt göra följande:

• Påstå att mejlet kommer från vem som helst. tomten@tomteland.se, potus@us.gov för att ge ett par exempel.

  Redan här är ju det mesta trasigt. Kan jag förfalska avsändaren, på ett sätt att mottagaren inte kan avslöja falsariet, så är ju möjligheterna oändliga som en del skulle säga.

• Av olika anledningar finns det två ställen där man anger vem som är avsändare av ett mejl, och det behöver inte vara samma. Detta gjordes på grunder som var rimliga 1982, men som leder till en del intressanta bieffekter om det utnyttjas på ett skadligt sätt.

Detta innebär att den som din mejlserver tror att mejlet är ifrån (via något som ibland refereras till som RFC5321.MailFrom) och det som kommer att stå på From: raden i ditt mejl (som kommer via RFC5322.From) inte behöver vara lika.

Liknelsen är att din mobiltelefon får ett samtal från ett vanligt nummer (RFC5321.MailFrom), exempelvis 070-123 456 789, men när du tittar på displayen så står det att det är nödnummret i Sverige, 112, som samtalet kommer ifrån (det sistnämnda sätts i det som kallas RFC5322.From).

Vad har man då gjort för att försöka komma tillrätta med dessa problem?

Det har under åren rullats ut tre olika tekniker, som tillsammans ger ett rätt vettigt skydd för både dig som konsument och för ditt företag eller organisation.

• Först ut var något som kallas "Sender Policy Framework", eller SPF som det vanligen förkortas.

  Tanken med SPF är att ett företag eller en organisation kan annonsera till omvärlden vilka mejlservrar som har rätt att skicka mejl som det företaget eller organisationen. Enkelt va?

  Om mejlet inte kommer från någon av de utpekade mejlservrarna, så har mottagande mejlserver möjlighet att antingen neka mejlet, sätta det i karantän eller flagga det som möjligt SPAM.

• Något därefter kom en teknik som kallas "DomainKeys Identified Mail", förkortningen DKIM är dock det som vanligtvis används.

  Tanken här är ungefär som ett signerat vykort, känner jag igen signaturen så kan jag på goda grunder anta att vykortet kommer från den som det utger sig att komma från.

  DKIM är både en autentiseringmetod för mejl och ett sätt att försäkra sig om att antal signerade delar av mejlet inte har förändrats.

• Det senaste tillskottet heter DMARC, en förkortning för "Domain-based Message Authentication, Reporting and Conformance" och är egentligen ett sätt för ett företag eller organisation att kunna meddela andra vad man vill att de ska göra, om de får mejl från företaget som bryter mot deras SPF policy (dvs mejlet skickades inte via de utpekade mejlservrarna) eller om det är en trasig eller att DKIM signering saknas helt och hållet.

  De möjligheter som står till buds som DMARC policy är "none", vilket innebär att det berörda bolaget har DMARC i monitorläge (mer om detta nedan), "quarantine" dvs sätt mejlet i karantän, eller "reject", dvs avvisa mejlet om det bryter mot policyn för SPF eller DKIM.

  Ytterligare en finess med DMARC är möjligheten att få rapporter, ett företag kan i sin DMARC policy be att få dagliga rapporter på hur mejl som skickas fråm deras domännamn tas emot.

  Fungerar som en liten automatiserad visselblåsarfunktion kan man säga, om någon från Brasilien har försökt att skicka ett förfalskat mejl från ditt företag till exempelvis Google, så kommer Google att rapportera detta till dig.

  Ett varningens ord dock, att aktivera DMARC i karantän eller reject läge direkt kan leda till en del oönskade sido-effekter. Framförallt berörs vidarebefodring av mejl och postningar till en del mejlinglistor.

  Detta går dock att mildra samt upptäcka i tid, om man genomför en mjuk utrullning av DMARC i 7 faser:

  • Fas 1: aktivera DMARC med policyn "none" och minst en rapportmottagare (rua=mailto:ad@res.se)

  • Fas 2: Ändra DMARC policyn till "quarantine" på 1% av mejlen (pct=1)

  • Fas 3: Ändra DMARC policyn till "quarantine" på 50% av mejlen (pct=50)

  • Fas 4: Ändra DMARC policyn till "quarantine" på 100% av mejlen (pct=100)

  • Fas 5: Ändra DMARC policyn till "reject" på 1% av mejlen (pct=1)

  • Fas 6: Ändra DMARC policyn till "reject" på 50% av mejlen (pct=50)

  • Fas 7: Sista fasen, ändra DMARC policyn till "reject" på 100% av mejlen (pct=100)

  Under alla faser behöver du monitorera de DMARC rapporter som kommer in för att kontrollera om du behöver justera SPF och/eller DKIM.

  Rapporterna kommer in komprimerade i XML-format, så någon form av verktyg kan behövas för att få ut något vettigt av det. Jag kan rekommendera både dmarcian och DMARC Analyzer, som bägge har en gratisversion man kan testa under vissa en tid.

  Ett sista tips avseende DMARC (egentligen SPF). Detta kan vara ett bra läge att flytta eventuella externa parter som används för att göra utskick åt företaget, tex nyhetsbrev eller marknadsundersökningar, till en separat underdomän, exempelvis marketing.domänen.se samt skapa egna SPF och DMARC policies för den nya domänen.

  På detta sätt har du dessutom också "städat" upp vilka som får använda ditt övergripande domännamn, vilket minskar dina risker något för obehörigt bruk av ditt huvudsakliga domännamn.

• Om du tröttnat på att lita på externa CA:s ska du definitivt studera TLSA (även kallat DANE) som ger dig möjligheten att vara din egen betrodda CA, under förutsättning att du använder DNSSEC för din domän.

  Fungerar utmärkt redan idag för SMTP i samband med STARTTLS som beskrivs nedan.

• STARTTLS ger möjlighet att kryptera transporten av mejl mellan mejlservrar, så att ingen kan tjuvlyssna eller förändra mejl du skickar externt.

  Sker helt transparent, och oftast helt utan att användaren vet om det. Så även om innehållet i mejlet inte är krypterat med tex PGP eller S/MIME, så skapas en skyddad tunnel mellan mejlservrarna som mejlet transporteras skyddat i.

  Med andra ord, mejlen kan gå i klartext internt, fram till den externa mejlservern för att sedan föras över krypterat, och sedan återigen eventuellt transporteras i klartext från mottagande mejlserver till själva mottagaren.

Vad har dessa fem tekniker gemensamt då?

Jo, de bygger till stor del på DNS och kan sålunda sättas ur spel om inte DNS säkras upp med DNSSEC.

Så vad är slutklämmen då?

Jo, trots att vi redan har tekniker som SPF, DKIM, DMARC, DANE, STARTTLS och DNSSEC som gör livet svårare för de som försöker göra livet surt för dig, är det långt ifrån alla företag som använder dem.

Hur svårt är det?

Inte speciellt svårt, det kanske tar 2-3 dagar för ett medelstort företag att komma igång med SPF, DKIM, DMARC, DANE, STARTTLS och DNSSEC. Den investeringen i tid, torde skriva av sig rätt snabbt, om det hjälper till att avvärja en enda incident med skadlig kod eller ransomware.

Så, ryck tag i närmaste tekniker, peka på den här artikeln, och säg "Det är inte så svårt tydligen?" :-)

Så kanske ni också kan få till vettiga skyddsmekanismer, som har funnits ett bra tag nu, för en kommunikationsform från 80:talet som vi förlitar oss på för merparten av vår kommunikation idag.

Lycka till!

Källor

• SMTP, RFC5321
• SPF, RFC7208
• DKIM, RFC6376
• DMARC, RFC7489
• DANE, RFC6698
• DNSSEC, RFC4033
• STARTTLS, RFC3207

Peter Norin på XPD gjorde i november 2016 en undersökning av bruket av SPF i .se domänen.

Tyvärr var det en smula nedslående resultat.

Av drygt en miljon (968 222 stycken) .SE domäner, hade bara 16% SPF uppsatt.

Och av dessa 16%, drygt 155 000 domäner, som har konfigurerat grundläggande säkerhet för mejl, dvs SPF, så var det bara 40% av dessa, dvs lite drygt 60 000 domäner som hade satt upp SPF på ett korrekt sätt. Detta motsvarar drygt 6% av alla undersökta .se domäner.

Resterande 60% (ca 90 000) hade inte lyckats konfigurera SPF rätt, och därmed helt satt den skyddsmekanismen ur spel.

Då mellan 80% och 90% av all skadlig kod som smittar företag och privatpersoner initieras via mail, så gjorde XPD i mars 2021 en undersökning av hur väl DMARC används av samtliga domäner i .se zonen.

En korrekt uppsatt DMARC policy, dvs med en policy antingen satt till "reject" eller "quarantine", ger ett grundläggande skydd mot Whaling och Phishing samt skyddar ens egen domän för missbruk mot 3:e part, exempelvis kunder.

Bara 2.1% av domänerna har satt upp DMARC korrekt, resterande 97.9% av domänerna saknar DMARC och det skydd DMARC erbjuder. (I ärlighetens namn så är detta inte helt rättvisande, då en okänd del av .se-zonen har domäner som är rena skyddsregistreringar, felstavade domäner, mer om det nedan, domäner för privatpersoner med mera och i viss mån saknar behovet av ett gott mailskydd)

Intressant är att nästan hälften av de organisationer som har gjort sig besväret att sätta upp DMARC, har missuppfattat hur DMARC fungerar och har en policy som är satt till "none", vilket effektivt sett innebär att DMARC inte är aktiverat.

Avseende DMARC för myndigheter och företag, så är den rapport som underhålls av Internetstiftelsen som nämns nedan, mer rättvisande, men också lika nedslående, eftersom i snitt endast 10% av de myndigheter och företag som är viktiga för Sverige, har något så grundläggande som DMARC korrekt konfigurerat.

Internetstiftelsen har publicerat en sammanställning på Ivan Ristiks fina site hardenize.com där de för Sverige, viktigaste domänerna (Myndigheter, Banker etc) i .se-zonen kontinuerligt kontrolleras.

Den visar till exempel att endast 10% av dessa, för samhället viktiga domäner, har DMARC korrekt uppsatt. Det finns en del gyllene undantag, exempelvis har Handelsbanken i princip full pott.

Holländska Internet Standards Platform har ett utmärkt och enkelt verktyg för att kontrollera hur väl webb och mail är uppsatt för en domän. Till exempel så har Skatteverket och Frobbit full poäng (100%) för sin respektive uppsättningar. Bra jobbat!

dnstwist är ett mycket trevligt verktyg för att hitta felstavade domäner som Marcin Ulikowski har skrivit, har ni inte provat den på era egna domäner, så bör ni göra det nu innan någon annan, med mindre goda avsikter, gör det.