Domain Name System (DNS) är ett av internets mest grundläggande protokoll. Det fungerar som internets telefonkatalog och översätter domännamn till IP-adresser.
Varje gång du ansluter till ett domännamn litar du på att DNS ger dig rätt IP-adress. Men DNS utvecklades i en tid då internet var en vänligare plats och protokollet saknar mekanismer för att verifiera att svaret verkligen stämmer.
Jag ska ge ett exempel
Jag äger domänen learntodefend.se och sätter upp en DNS-server för den. Därefter kontaktar jag min registrar och anger vilka namnservrar som är ansvariga för domänen.
När någon vill besöka min webbplats börjar det med att klienten frågar en resolver efter IP-adressen till www.learntodefend.se. Resolvern frågar först en root-server, men den har inte svaret utan hänvisar istället till namnservrarna för toppdomänen .se.
Resolvern frågar en av .se-servrarna. Den vet inte heller IP-adressen till www.learntodefend.se, men den vet vilka namnservrar som är ansvariga för domänen.
Till slut skickas frågan till min DNS-server, som svarar med den korrekta IP-adressen.
Men tänk om du sitter på ett osäkert nätverk. En angripare kanske manipulerar DNS-trafiken och svarar på dina förfrågningar med falska IP-adresser.
Du tror att du besöker min webbplats, men i själva verket hamnar du på en fejkad sida.
Det kanske inte är hela världen om en angripare skapar en fejkad version av min blogg. Men tänk om det till exempel hade varit din banks webbplats.
I varje steg litar resolvern på att den får rätt information, men det finns inget sätt att verifiera detta. Det är här DNSSEC kommer in.
Vad är DNSSEC?
Domain Name System Security Extensions (DNSSEC) är ett komplement till DNS som gör det möjligt att verifiera att DNS-svar är rätt.
DNSSEC löser detta genom att komplettera svaren med digitala signaturer.
Såhär fungerar det
När man aktiverar DNSSEC så genererar DNS-servern kryptografiska nycklar:
En Key Signing Key (KSK)
En eller två Zone Signing Key (ZSK)
Zone Signing Keys används för att signera zonens DNS-poster. Den privata delen av nycklarna skyddas noga och lämnar aldrig DNS-servern.
Den publika delen publiceras som DNSKEY-poster i zonen och används för att verifiera signaturer.
Den långa base64-strängen är alltså signaturen för A-posten. Den har skapats med den privata delen av Zone Signing Key (ZSK) med key tag 21120.
Verifiera signaturen
För att verifiera signaturen behöver resolvern tillgång till den publika delen av nyckeln. Som jag skrev tidigare publiceras den som en DNSKEY-post. Du kan enkelt se dessa genom att använda kommandot dig och ange att du vill hämta poster av typen DNSKEY.
I det här exemplet har jag markerat den publika DNSKEY-posten med key tag 21120 – det är den som användes för att skapa signaturen.
Med hjälp av den publika nyckeln kan resolvern verifiera RRSIG-posten och säkerställa att svaret är giltigt.
I DNSKEY-svaret ser vi två ZSK, en KSK och en RRSIG-post (den återkommer jag till strax).
Det är vanligt att ha två ZSK samtidigt under en period. Eftersom nycklarna roteras, publiceras den nya i förväg och börjar användas innan den gamla tas bort. På så vis kan man byta nyckel utan att något slutar fungera.
Även DNSKEY-posten innehåller en del intressant metadata:
Fält
Beskrivning
IN
Klass (Internet)
DNSKEY
Detta är en publik DNSSEC-nyckel
256 / 257
Flagga som anger typ av nyckel * 256 = ZSK (Zone Signing Key) * 257 = KSK (Key Signing Key)
Genom att behandla DNSKEY-postens innehåll med en särskild algoritm (RFC 4034 Appendix B) kan man räkna fram ett 16-bitars värde som kallas key tag. Det är tack vare detta värde som resolvern vet vilken nyckel som ska användas för att validera signaturen i en RRSIG-post.
Men om en angripare kontrollerar zonen, kan den inte bara skapa egna nycklar?
Jo, om en angripare sätter upp en falsk DNS-server som den kontrollerar skulle den kunna skapa egna nycklar och signera falska svar. Därför räcker det inte att verifiera signaturen, utan vi måste även verifiera att själva nyckeln är rätt.
Det är här Key Signing Keys (KSK) kommer in i bilden.
När man aktiverar DNSSEC grupperas DNS-posterna efter typ i så kallade RRsets (Resource Record Sets). Ett RRset består av alla poster av samma typ och namn, till exempel alla MX-poster för en domän, eller alla DNSKEY-poster.
Det är dessa RRsets som signeras – inte varje enskild post individuellt.
Bild från DNSViz.net
De flesta RRsets i zonen signeras av den privata delen av ZSK (i denna bild den vita DNSKEY:n med ID 21120). Men DNSKEY-setet, alltså själva nycklarna, signeras av den privata delen av KSK (den grå DNSKEY:n med ID 12412).
Det betyder att om vi litar på KSK, då kan vi också lita på DNSKEY-setet, och därmed på ZSK.
Okej, men hur kan vi lita på KSK?
Nu börjar vi närma oss kärnan i DNSSEC, nämligen hur man bygger en chain of trust. Svaret är att förtroendet inte skapas i den egna DNS-servern – det skapas i föräldrazonen.
Man tar den publika delen av KSK och räknar ut ett hashvärde av denna. Detta hashvärde registreras sedan som en DS-post (Delegation Signer) i föräldrazonen, i detta fall .se.
DS-posten innehåller alltså inte själva nyckeln, utan bara ett kryptografiskt fingeravtryck av KSK.
För att se denna post kan vi återigen använda kommandot dig och ange att vi vill hämta poster av typen DS.
Posterna i bilden ovan ligger alltså i föräldrazonen .se. Och DS-postens key tag 12412 motsvarar key tag på vår KSK.
Postens värde är en hash av vår KSK och detta är enkelt att verifiera själv med verktyget dnssec-dsfromkey:
# Spara DNSKEY-poster till fil
> dig learntodefend.se DNSKEY > dnskey.txt
# Räkna ut hash från KSK i filen dnskey.txt
> dnssec-dsfromkey -f dnskey.txt learntodefend.se
learntodefend.se. IN DS 12412 8 2 8194D32EA0F45CCE32F11D3BB901D23D4B30DD02E1E994D56F37E7F8747A0DEB
Om vi tittar på svaret igen ser vi att även denna post är signerad med en RRSIG-post. Signaturen är skapad av en nyckel med key tag 65293, och eftersom signaturen kommer från föräldrazonen står det .se som signer istället för learntodefend.se.
Men var finns denna nyckel? Jo, den hittar vi genom att fråga föräldrazonen efter dess DNSKEY-poster.
I det här exemplet har jag markerat den publika DNSKEY-posten med key tag 65293 – det är den som användes för att signera DS-posten.
Precis som i min egen zon är även föräldrazonens DNSKEY-poster signerade med en RRSIG-post. Och så fortsätter det hela vägen upp till root-zonen. På så sätt byggs en chain of trust – fiffigt värre!
Om du vill få en komplett översikt över DNSSEC-konfigurationen för din domän rekommenderar jag verktyget DNSViz.net, som både analyserar din zons konfiguration och skapar en överskådlig rapport:
Bild från DNSViz.net
Aktivera DNSSEC i praktiken
Nu när vi gått igenom hur DNSSEC fungerar tänkte jag visa hur man aktiverar det i praktiken.
Om din DNS-leverantör dessutom fungerar som din registrar är det oftast väldigt enkelt. I många fall räcker det att logga in i leverantörens portal och aktivera funktionen. Resten hanteras automatiskt:
DNSSEC aktiveras för zonen
ZSK och KSK genereras
Zonens RRsets signeras
En hash av den publika delen av KSK registreras i föräldrazonen som en DS-post
För domänen learntodefend.se använder jag Loopia både som DNS-leverantör och registrar. Då räcker det att logga in och klicka på ”Aktivera DNSSEC”.
Jag har även en annan domän där jag hanterar DNS via Cloudflare, medan Loopia fortfarande är min registrar. Där ser processen lite annorlunda ut.
Då behöver jag istället:
Logga in i Cloudflares portal och aktivera DNSSEC.
Eftersom Cloudflare inte är min registrar kan de inte uppdatera föräldrazonen automatiskt.
Cloudflare räknar då ut en hash av min KSK och skapar en DS-post som jag får kopiera.
Därefter loggar jag in hos Loopia, aktiverar DNSSEC och klistrar in DS-posten där.
Loopia registrerar DS-posten i .se-zonen och länkar ihop Cloudflares KSK med föräldrazonen.
Sammanfattning
Jag hoppas att den här genomgången har gjort att DNSSEC känns lite mindre mystiskt, och kanske till och med inspirerar några av er att aktivera det på er domän. DNSSEC är trots allt ett av de viktigaste protokollen för ett säkrare internet – men tyvärr något som hoppas över alldeles för ofta.
DNSSEC är egentligen inte särskilt svårt att använda. Absolut, en felaktig konfiguration kan få allvarliga konsekvenser (till exempel att resolvers slutar lita på dina DNS-svar), men så länge du är noggrann med att DS-posten registreras korrekt brukar de flesta DNS-servrar hantera resten automatiskt idag.
Har du egna erfarenheter av DNSSEC får du gärna dela med dig i kommentarerna.
Ett område inom cybersäkerhet som jag tycker är extra roligt är att analysera och minimera den externa attackytan.
Med extern attackyta menas alla kontaktytor som går att nå från internet – från webbservrar och TLS-konfiguration till DNS och e-postinställningar. I den här artikeln går jag igenom hur man analyserar dessa ytor och identifierar svagheter i konfigurationen.
Det går förstås att göra allt manuellt med hjälp av nmap, dig, openssl och liknande verktyg – men då krävs det också att man vet vad man ska leta efter. Som tur är finns det färdiga tjänster som hjälper dig komma igång.
Jag brukar ofta börja med Hardenize eftersom det är enkelt att använda och ger en väldigt tydlig överblick över de vanligaste säkerhetsparametrarna för en domän.
På senare tid har jag dock börjat använda Internet.nl allt mer, och det har blivit något av en ny favorit. Internet.nl är ett initiativ inom ramen för Internet Standards Platform – ett samarbete mellan flera nederländska aktörer med målet att göra internet mer tillgängligt, säkrare och mer tillförlitligt för alla.
Man kan tycka att dessa analyser mest hittar lågt hängande frukt som de flesta borde ha koll på. Men förvånansvärt ofta upptäcker jag att företag missar, eller saknar kunskap om, grundläggande skyddsåtgärder. För organisationer med mer komplexa miljöer kan det dessutom vara svårt att ha full koll på sin externa attackyta.
Mindre företag har ofta en relativt statisk attackyta, och då kan dessa tjänster i kombination med manuella kontroller räcka långt. Vill man däremot arbeta systematiskt med External Attack Surface Management (EASM) och göra löpande analyser kan det vara värt att investera i en professionell lösning, som Bitsight, SecurityScorecard eller Qualys. Arbetar man mycket i Microsoft Azure kan Defender EASM också vara ett intressant alternativ.
Vad skiljer då professionella lösningar mot de kostnadsfria alternativen?
Professionella lösningar analyserar ofta attackytan bredare. Medan kostnadsfria alternativ främst granskar svagheter i specifika konfigurationer – till exempel DNS, webb och e-post – gör professionella lösningar en mer heltäckande kartläggning och skannar alla portar för att identifiera flera tjänster. De kan även inkludera funktioner som genomsöker webbapplikationer efter sårbar kod. Men överlag tycker jag att de kostnadsfria alternativen gör ett riktigt bra jobb.
Det som de professionella alternativen framförallt kan hjälpa till med är att inventera den faktiska attackytan. Visst går det att lösa med lite detektivarbete genom att skanna IP-adresser, granska DNS-poster och söka efter utfärdade certifikat, men för större organisationer med komplexa miljöer kan detta snabbt bli en utmaning. Här kan ett automatiserat verktyg vara till stor hjälp.
I den här artikeln tänkte jag dela med mig av hur jag brukar arbeta, med en kombination av kostnadsfria tjänster och manuella kontroller, och steg för steg visa hur jag förbättrar säkerheten för min domän learntodefend.se.
Ett oväntat prestandaproblem
Redan innan jag började titta på attackytan upplevde jag att min blogg var lite långsam. Visserligen kör jag ett enklare webbhotell hos Loopia, men det här kändes som något annat. Ganska snabbt konstaterade jag att bloggen svarade betydligt långsammare när jag anslöt mot toppdomänen learntodefend.se jämfört med subdomänen www.learntodefend.se.
En omdirigering kan såklart innebära viss fördröjning, men i mitt fall kunde det skilja flera sekunder. Det visade det sig att anslutningar mot toppdomänen behövde gå hela vägen via webbservern, starta PHP och ladda WordPress innan de vidarebefordrades till www.learntodefend.se. Det är onödigt tungt, så istället ville jag hantera omdirigeringen direkt i webbservern. I mitt fall är det en Apache-server, och den enklaste lösningen var att konfigurera detta i en .htaccess-fil.
Här stötte jag på problem. Jag började med att skriva omdirigeringen i två steg: först tvingade jag all trafik från HTTP till HTTPS och därefter vidarebefordrade jag anrop mot toppdomänen learntodefend.se till subdomänen www.learntodefend.se.
Det här funkade inte alls, och jag kunde inte ens komma åt bloggen längre. Efter lite detektivarbete verkar det som att Loopia terminerar TLS i en NGINX-proxy framför Apache-servern. Så för Apache är anropen alltid HTTP.
När jag tvingade HTTP till HTTPS skapade jag en evighetsloop.
Jag har inte verifierat detta med Loopia, men utifrån hur trafiken beter sig och vilka headers som skickas ser det ut att fungera på det sättet.
Lösningen blev en enklare konfiguration som bara vidarebefordrar anrop mot toppdomänen learntodefend.se till subdomänen www.learntodefend.se.
Därefter gjorde jag en analys med hjälp av Hardenize och gick igenom resultatet uppifrån och ner. Resultatet är indelat i kategorierna Domain Name System, Email och WWW.
Domain Name System
Denna kategori är indelad i fyra tester:
DNS Zone
DNS Records
DNSSEC
CAA
DNS Zone & DNS Records
De två första testerna, DNS Zone och DNS Record, gör en övergripande kontroll av att DNS är korrekt uppsatt och att det inte finns några uppenbart onödiga (”dangling”) DNS-poster. Det här är sällan några problem och brukar inte kräva några större åtgärder.
DNSSEC
För mig är DNSSEC en självklarhet, men det är fortfarande förvånansvärt många domäner som inte har detta aktiverat. Jag tror det finns en rädsla för att DNSSEC ska vara komplicerat att konfigurera, när det i många fall är ganska enkelt.
DNSSEC är en teknik för att skydda DNS så att svaren inte kan bli manipulerade. Jag kommer inte gå in på detaljer, istället planerar jag att skriva en egen artikel om DNSSEC. Men kortfattat innebär det att man skapar ett nyckelpar, Zone-Signing Key (ZSK), där den privata delen är hemlig och signerar DNS-posterna. Den publika delen görs tillgänglig via en DNSKEY-post och används av klienter för att verifiera svaren.
För att klienterna ska kunna lita på nycklarna skapas även en Key-Signing Key (KSK), som signerar den publika ZSK:n. En hash av KSK:n publiceras sedan som en DS-post i domänens föräldrazon (i mitt fall .se-zonen), vilket skapar en kedja som går att verifiera.
I de flesta fall är DNSSEC enkelt att konfigurera. Ofta räcker det att logga in i DNS-verktyget och aktivera funktionen. Då får man tillbaka en DS-post som man ger till domänregistraren, som i sin tur publicerar den i föräldrazonen. Om man, som jag, använder DNS-servrar hos samma leverantör som även agerar registrar för domänen, brukar det oftast räcka att bara aktivera DNSSEC.
⚠️ Viktigt! Med det sagt gäller det att vara noggrann. Om någon av nycklarna blir fel bryts förtroendekedjan, och klienter slutar att lita på DNS-svaren.
💡 Tips: Vill man analysera djupare eller felsöka DNSSEC är DNSViz och Zonemaster två väldigt bra verktyg.
CAA
Det sista testet, CAA, kontrollerar om domänen har CAA-poster i DNS som styr vilka certifikatutfärdare (CA) som får utfärda certifikat för domänen. Det är en enkel men effektiv funktion för att minska risken att certifikat blir utfärdade av misstag eller i bedrägligt syfte.
Det första testet, Mail servers, kontrollerar att domänens MX-poster är korrekt konfigurerade och pekar på giltiga mejlservrar. Hardenize verifierar även att mejlservrarna svarar på SMTP och beter sig som förväntat.
TLS & Certificates
De efterföljande testerna, TLS och Certificates, granskar kryptering vid e-postkommunikation. Här kontrolleras bland annat om mejlservern stödjer TLS, vilka protokoll och ciphers som tillåts samt vilket certifikat som presenteras vid anslutning.
I dag är rekommendationen att endast tillåta TLS 1.2 eller senare, och att använda moderna ciphersuites. Äldre protokoll och svaga algoritmer bör tas bort i takt med att de blir föråldrade. Använder man till exempel Microsoft 365 behöver man inte justera dessa inställningar själv, då tjänsten redan är konfigurerad med säkra standardvärden.
MTA-STS
Mail Transfer Agent Strict Transport Security (MTA-STS) är en funktion för att tala om för andra mejlservrar att e-post till din domän ska levereras via krypterad TLS. Funktionen liknar DANE och är enklare att sätta upp eftersom den till skillnad från DANE inte kräver DNSSEC.
Tekniken är enkel och består av två delar:
En TXT-post i DNS, _mta-sts.dindomän.se, som signalerar att domänen stödjer MTA-STS och vilken version av policyn som används
En policyfil som är tillgänglig via HTTPS på adressen https://mta-sts.dindomän.se/.well-known/mta-sts.txt
Policyfilen innehåller fyra rader:
version – alltid STSv1
mode – anger hur policyn ska tillämpas
none – policyn är inaktiv
testing – för att testa konfigurationen; tillåter okrypterade anslutningar men begär rapporter
enforce – instruerar avsändande mejlservrar att avvisa leveransen om det inte går att ansluta krypterat
mx – anger vilka mejlservrar som är godkända att ta emot e-post för domänen
max_age – hur länge policyn får cachas av avsändande servrar
Min TXT-post för MTA-STS ser ut så här:
_mta-sts.learntodefend.se. IN TXT "v=STSv1; id=202602100718"
Om id-värdet blir ändrat vet avsändande servrar att de behöver hämta policyn på nytt.
⚠️ Viktigt: MTA-STS innebär inte att din egen mejlserver automatiskt kräver kryptering. Policyn talar om för avsändande servrar att leverera e-post via TLS, men det är fortfarande upp till respektive server att stödja och följa MTA-STS.
TLS-RPT
TLS Reporting (TLS-RPT) används ofta tillsammans med MTA-STS och är viktigt för att få reda på när leveranser misslyckas på grund av problem med TLS. Med TLS-RPT kan avsändande mejlservrar skicka rapporter när de inte lyckas leverera e-post.
TLS-RPT konfigureras genom en TXT-post, _smtp._tls.dindomän.se. I mitt fall ser posten ut så här:
_smtp._tls.learntodefend.se. IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt@ezj9gpjt.uriports.com"
Jag använder URIports för att ta emot och sammanställa rapporterna. Det går såklart att skicka rapporterna till en vanlig brevlåda, men jag rekommenderar någon form av verktyg som kan hjälpa till att tolka och sammanställa datan.
DANE
DNS-based Authentication of Named Entities (DANE) har liknande funktion som MTA-STS, nämligen att säkerställa att e-post levereras via krypterad TLS.
Till skillnad från MTA-STS, som publicerar en policy via HTTPS, så använder DANE istället TLSA-poster i DNS. Posterna publiceras under mejlserverns namn och anger vilket certifikat som är giltigt för servern.
En annan viktigt skillnad är att DANE kräver DNSSEC för att andra mejlservrar ska kunna verifiera att de ansluter till rätt server med rätt certifikat.
TLSA-posten för SMTP har följande format:
Värdet består av tre siffror (”3 1 1” i detta exempel) och en hash. Siffrorna anger usage, selector och matching type:
Usage – anger hur certifikatet ska valideras
PKIX-TA (använd inte för SMTP)
PKIX-EE (använd inte för SMTP)
DANE-TA (pekar på CA/intermediate-certifikat)
DANE-EE (pekar på servercertifikatet)
Selector – anger vad som måste matcha
Hela certifikatet
Den publika nyckeln (rekommenderas)
Matching type – anger hash-algoritm
Ingen hash
SHA-256 (rekommenderas)
SHA-512 (mindre vanligt)
Den vanligaste kombinationen för SMTP i dag är 3 1 1, vilket innebär att man publicerar en SHA-256-hash av servercertifikatets publika nyckel.
Sista steget är att generera SHA-256-hashen. Detta görs enklast med verktygen openssl:
💡 Tips: Vill du läsa mer on DANE och hur man konfigurerar detta rekommenderar jag Internet.nl:s DANE for SMTP how-to.
Konfigurera DANE för Microsoft 365
Om man som jag använder Microsoft 365 så pekar MX-posten på en Microsoft-domän, i mitt fall learntodefend-se.mail.protection.outlook.com.
Eftersom jag varken hanterar mejlservern, dess certifikat eller domänen kan jag inte skapa TLSA-poster manuellt. I stället behöver DANE konfigureras via Exchange Online.
Börja med att installera Exchange Online PowerShell-modulen och logga in som global administratör:
Därefter aktiverar du DNSSEC med kommandot Enable-DnssecForVerifiedDomain. Kommandot returnerar en ny MX-domän som är konfigurerad för DNSSEC, och som du behöver lägga till i din DNS.
Kommandot kan ta några sekunder att slutföra. Därefter kan det dröja ytterligare 15–30 minuter innan TLSA-posten är skapad och publicerad.
När allt är aktiverat brukar jag använda till exempel CheckTLS för att kontrollera att TLSA-posten är korrekt publicerad och att DANE-konfigurationen ser bra ut.
SPF & DMARC
Sender Policy Framework (SPF) och Domain-based Message Authentication, Reporting, and Conformance (DMARC) är tekniker som används för att minska risken för att någon skickar e-post i din domäns namn.
SPF innebär att man lägger till en TXT-post i DNS som anger vilka servrar som är tillåtna att skicka e-post för domänen.
v=spf1 ip4:40.92.0.0/15 -all
I mitt fall använder jag Microsoft 365 och inkluderar deras färdiga SPF-post istället för att lista specifika IP-adresser:
v=spf1 include:spf.protection.outlook.com -all
DMARC används för att rapportera om någon försöker skicka e-post som bryter mot SPF eller DKIM. Precis som med SPF lägger man till en TXT-post i DNS som indikerar till vilken adress rapporterna ska skickas:
De första testerna, HTTP 80 och HTTPS (443), kontrollerar om domänens webserver är korrekt konfigurerad. Det innebär till exempel att servern svarar med rätt statuskoder, inte läcker onödig information och vidarebefordrar HTTP-trafik till HTTPS.
TLS & Certificates
De följande två testerna, TLS och Certificates, kontrollerar om webbservern stödjer TLS, vilka protokoll och ciphers som tillåts samt vilket certifikat som presenteras vid anslutning.
I dag är rekommendationen att endast tillåta TLS 1.2 eller senare, och att använda moderna ciphersuites. Äldre protokoll och svaga algoritmer bör tas bort i takt med att de blir föråldrade.
Om du vill analysera TLS och certifikat är Qualys SSL Labs ett bra verktyg.
Cookies
Detta test identifierar och presenterar de cookies som sätts av webbservern. Det kontrollerar till exempel att de är markerade som Secure, vilket innebär att de bara skickas över krypterade anslutningar.
Testet granskar även andra attribut:
Attribut
Beskrivning
Secure
Cookien skickas bara över HTTPS
HttpOnly
Cookien kan inte läsas via JavaScript (skydd mot XSS)
SameSite
Styr om cookien ska skickas med när anropet kommer från en annan webbplats (skydd mot CSRF).
Path
Anger vilken sökväg cookien gäller för
Expires / Max-Age
Anger hur länge cookien är giltig
HTTP Content
Detta test kontrollerar att allt länkat innehåll, till exempel bilder, stylesheets och JavaScript-filer, hämtas via HTTPS. Om en krypterad webbplats laddar resurser över HTTP uppstår så kallat mixed content, vilket kan försvaga säkerheten.
Strict Transport Security
HTTP Strict Transport Security (HSTS) är en säkerhetsfunktion som talar om för webbläsare att alltid ansluta till webbplatsen via krypterad HTTPS.
Webbservern konfigureras att skicka med en särskild header:
Headern talar om för webbläsaren att inte försöka ansluta via HTTP under den angivna tidsperioden (max-age) och, om includeSubDomains används, även tillämpa regeln på alla subdomäner.
HSTS skyddar mot så kallade nedgraderingsattacker, där en angripare försöker lura webbläsaren att ansluta till webbplatsen okrypterat.
⚠️ Viktigt: Webbläsaren sparar policyn första gången den ansluter till webbplatsen via HTTPS och tar emot HSTS-headern. Innan dess kan en angripare försöka genomföra en nedgraderingsattack.
Tänk också på att policyn sparas i webbläsaren och normalt tas bort om man väljer att rensa all webbplatsdata.
För att även skydda första besöket kan man använda HSTS preload. Jag kommer återkomma till detta i en kommande artikel, men vill du läsa mer redan nu finns information på https://hstspreload.org/.
Content Security Policy
Content Security Policy (CSP) är en HTTP-header som talar om för webbläsaren varifrån innehåll, till exempel bilder, stylesheets och Javascript, får laddas.
Syftet är att minska risken för attacker som cross-site scripting (XSS) genom att begränsa vilka resurser som får köras eller laddas på sidan.
Varje direktiv anger varifrån en viss typ av resurser får laddas. Till exempel innebär script-src'self''unsafe-inline' att JavaScript får laddas från den egna domänen samt köras som inline-kod.
⚠️ Viktigt: Helst vill man undvika unsafe-inline eftersom det kan användas för XSS-attacker. Men WordPress använder många inline-script och inline-styles som är svåra att lösa utan detta direktiv.
Subresource Integrity
Subresource Integrity (SRI) är en säkerhetsfunktion som gör det möjligt för webbläsaren att verifiera att en extern resurs inte har blivit manipulerad.
Många webbplatser använder Content Delivery Networks (CDN) för att hämta externa resurser. Ett exempel kan se ut så här:
SRI fungerar genom att man lägger till en hash i <script>– eller <link>-taggen. När webbläsaren laddar resursen beräknar den själv en hash och jämför med den angivna. Om inte värdena matchar blockerar webbläsaren filen.
Frame Options, XSS Protection & Content Type Options
Dessa tester gäller säkerhets-headers som är rekommenderade att konfigurera på webbservern.
X-Frame-Options används för att tala om för webbläsaren om din webbplats får visas inuti en <iframe>. Då kan angripare bädda in din webbplats i en skadlig sida och lura användare att klicka på något de inte ser – en attack som kallas clickjacking.
Denna header kan konfigureras med något av följande värden:
DENY – sidan får aldrig bäddas in
SAMEORIGIN – får endast bäddas in från samma domän
Precis som tidigare valde jag att konfigurerade detta i min .htaccess-fil:
<IfModule mod_headers.c>
Header always set X-Frame-Options "SAMEORIGIN"
</IfModule>
X-XSS-Protection är en header som tidigare användes för att aktivera webbläsarens inbyggda skydd mot vissa typer av XSS-attacker. Idag är denna funktion föråldrad och borttagen (eller inaktiverad) i moderna webbläsare.
Hardenize föreslår att denna header ska sättas till ”0” för att inaktivera funktionen. Men den generella rekommendationen i dag är att inte använda headern alls, och i stället konfigurera CSP.
Den sista header, X-Content-Type-Options, används för att förhindra så kallad MIME-sniffing.
Genom att gå igenom dessa tester och åtgärda de brister som upptäcktes har jag nu uppnått “grönt” resultat på nästan samtliga tester hos både Hardenize och Internet.nl. Det enda undantaget är TLS Key Exchange Parameters, vilket jag inte kan påverka så länge jag använder webbhotellets färdigkonfigurerade miljö.
Den här guiden visar hur relativt små justeringar kan göra stor skillnad för den externa attackytan. Och förhoppningsvis kan genomgången fungera som vägledning för dig som också vill stärka din säkerhet och få bättre kontroll över din attackyta.
Dags för del 4 i vår serie om Defender for Endpoint. Först gick vi igenom startguiden, därefter avancerade inställningar, och nu senast rekommendationer på hur man konfigurerar sin antiviruspolicy.
Jag har sett fram emot att skriva den här delen, för utöver antivirus och EDR är Attack Surface Reduction (ASR) en funktion som verkligen kan göra skillnad för säkerheten.
Till skillnad från antivirus och EDR så fokuserar inte ASR på skadlig kod eller misstänkt beteende. Istället handlar det om (precis som det låter) att minska attackytan genom att stänga av eller begränsa funktioner som ofta blir angripna.
I den här posten kommer jag dels att visa hur man skapar ASR-policyer, men också förklara vad varje regel innebär och ge rekommendationer på konfiguration.
Delar i serien
Här är en översikt över de delar som ingår i serien. Jag uppdaterar länkarna löpande allt eftersom nya inlägg blir publicerade.
Del 5 – Onboarding av enheter, device groups och RBAC-modellen
Del 6 – EDR, AIR, advanced hunting och incidenthantering
Skapa en ASR-policy
Som jag skrev i förra posten så hanteras policyer olika beroende på licens och konfiguration.
Om du använder en Enterprise-version (Defender for Endpoint Plan 1 eller Plan 2) kan du konfigurera ASR-policyer i Defender-portalen under menyn ”Endpoint → Configuration management → Endpoint security policies”.
Använder du däremot en Business-version så går det inte att konfigurera dessa policyer i Defender-portalen. Då måste du använda Microsoft Intune.
💡 Tips: Om du vill veta hur man kopplar ihop Defender-portalen med Microsoft Intune så har jag skrivit om det i Del 3 – Antivirus & Intune-portalen.
Scrolla ner till sektion Manage och välj Attack Surface Reduction.
Klicka på Create Policy och välj:
Platform: Windows
Profile: Attack Surface Reduction Rules
Klicka på Create.
Fyll i namn och beskrivning.
💡 Tips: Det är bra att använda en namnstandard som gör det enkelt att överblicka vad varje policy gör. Jag brukar använda formatet plattform-funktion-målgrupp.
Plattform kan vara Win, macOS, Linux, iOS eller Android.
Funktion beskriver vad policyn hanterar, till exempel AV (Antivirus), ASR (Attack Surface Reduction), DC (Device Control), FW (Firewall).
Målgrupp anger vilka enheter som omfattas av policyn, till exempel Clients, Servers eller Virtual.
Exempel på namn:
macOS-AV-Clients
Win-AV-Clients
Win-ASR-Clients
Klicka på Next för att fortsätta med konfigurationen.
Konfigurera ASR-regler. En beskrivning av varje regel finns längre ner i denna artikel. När du är nöjd klickar du på Next för att fortsätta.
Scope tags används för att gruppera resurser och styra vad olika administratörer ska kunna se och hantera. Detta är användbart i stora miljöer, men ligger utanför scope för den här guiden. Klicka på Next för att fortsätta.
På sidan Assignments lägger du till vilka grupper som ska använda denna policy. Det går även att lägga till grupper som ska vara exkluderade. Klicka på Next för att fortsätta.
⚠️ Obs! Det går att skapa Device Groups i Defender-portalen, men eftersom dessa grupper är unika för Defender-portalen och inte används av andra tjänster brukar jag rekommendera vanliga säkerhetsgrupper i Microsoft Entra istället.
Det finns ett undantag och det är Automated Investigation & Response (AIR). Men vi återkommer till denna funktion i en senare artikel.
På sista sidan (Review + create) kan du kontrollera alla inställningar. När du är nöjd klickar du på Save.
⚠️ Viktigt att tänka på:
ASR stöds bara på Windows-klienter och Windows-servrar (inte macOS, Linux eller mobila enheter).
Tänk på att du kan behöva olika ASR-policyer för olika ändamål, till exempel en för servrar, en annan för klienter som främst använder kontorsprogram och en tredje för utvecklare.
Börja med att sätta alla regler i audit-läge och analysera vad som påverkas. När du känner dig trygg med vilka undantag som behövs kan reglerna ändras till Block-läge.
Det går att skapa undantag per regel för alla ASR-regler utom ”Block persistence through WMI event subscription”. Så även om du upptäcker problem med någon fil eller process behöver du inte stänga av hela regeln.
Attack Surface Reduction – inställningar och rekommendationer
I det här avsnittet går vi igenom alla ASR-regler för sig. Målet är att beskriva varje regel så enkelt och tydligt som möjligt.
⚠️ Obs! Jag vill än en gång poängtera att detta inte är en “How to” som passar alla, utan snarare en “How I do”. Jag tror att mina rekommendationer fungerar bra för många, men det finns såklart situationer där du kan behöva anpassa inställningarna.
Block Adobe Reader from creating child processes
Denna regel hindrar Adobe Reader från att starta nya processer, något som skadliga PDF-filer ofta utnyttjar.
Jag har ännu inte stött på något legitimt scenario som använder denna funktion.
Rekommendation: 🟢 På
Block process creations originating from PSExec and WMI commands
Denna regel blockerar processer som skapas via PsExec och WMI.
Angripare kan använda PsExec och WMI för att läsa ut information och köra kommandon. Samtidigt används dessa tekniker även av legitima verktyg för fjärradministration, till exempel Microsoft Endpoint Configuration Manager.
Om ni kör verktyg för fjärradministration som använder PsExec eller WMI rekommenderar jag att sätta regeln i audit-läge och analysera vad som blir påverkat. Baserat på resultatet kan ni välja att skapa undantag eller att fortsätta köra regeln i audit-läge.
Rekommendation: 🟡 På (beroende på miljö)
Block execution of potentially obfuscated scripts
Denna regel blockerar skript som är obfuskerade (avsiktligt ändrade för att göra dem svåra att läsa och analysera).
Angripare använder obfuskering för att dölja skadlig kod och försöka undgå säkerhetsanalyser. Vanliga exempel är att byta namn på variabler till slumpmässiga tecken eller att Base64-koda skriptet.
Rekommendation: 🟢 På
Block persistence through WMI event subscription
Angripare använder WMI event subscriptions för att trigga skadlig kod när specifika händelser inträffar, till exempel vid systemstart eller när en användare loggar in.
Detta är ett effektivt sätt att skapa ett fotfäste som finns kvar även efter en omstart. Eftersom koden går att lagra i WMI-databasen, istället för som filer på hårddisken, är den svår att upptäcka för traditionella antivirusprogram.
Denna regel blockerar nya, okända processer från att registrera den här typen av WMI event subscriptions.
Rekommendation: 🟢 På
Block Win32 API calls from Office macros
Det är ovanligt att Office-makron behöver anropa Win32 API:er, även om det förekommer i undantagsfall.
Angripare använder Win32 API:er för att komma åt mer avancerade funktioner, till exempel för att manipulera minne eller injicera kod i andra processer.
Jag rekommenderar att aktivera denna regel. Om något legitimt makro blir påverkat går det att lägga till undantag.
Rekommendation: 🟢 På (lägg till undantag vid behov)
Block Office applications from creating executable content
Denna regel hindrar Office-applikationer från att skapa körbara filer med skadligt innehåll.
Angripare kan använda makron för att skapa filer med skadligt innehåll och skriva dessa till disk. På så sätt etablerar de ett fotfäste som finns kvar på systemet även efter en omstart.
Jag rekommenderar att aktivera denna regel. Vid behov går det att lägga till specifika undantag.
Rekommendation: 🟢 På (lägg till undantag vid behov)
Block credential stealing from the Windows local security authority subsystem
Angripare försöker ofta läsa ut autentiseringsuppgifter, till exempel hashvärden och Kerberosbiljetter, från LSASS. Denna regel blockerar sådana försök.
Även legitima applikationer anropar LSASS, vilket innebär att regeln kan skapa en del falsklarm. I många fall är dock dessa anrop inte nödvändiga för applikationens funktion. Dessutom blir inte den anropande processen blockerad, utan endast försöket att läsa från LSASS-processens minne.
Jag rekommenderar att aktivera denna regel. Vid behov går det att lägga till specifika undantag.
Rekommendation: 🟢 På (lägg till undantag vid behov)
Block use of copied or impersonated system tools
Denna regel blockerar försök att köra kopierade eller förfalskade systemverktyg.
Rekommendation: 🟢 På
Block executable files from running unless they meet a prevalence, age, or trusted list criterion
Blockerar körbara filer (till exempel .exe, .dll eller .scr) om de är nya eller okända.
Hur bra denna regel fungerar beror väldigt mycket på miljön. I miljöer med relativt statiska och välkända applikationer kan den ge ett bra skydd. Men för till exempel utvecklingsteam som kompilerar program och uppdaterar verktyg löpande kan regeln generera många falsklarm.
Prevalence, dvs hur utbredd en fil är, baseras på Microsofts globala molndata. Om en fil bara finns på 10 datorer i hela världen anses den ha låg prevalence och blockeras.
Jag rekommenderar att börja i audit-läge och analysera vad som blir påverkat. Det här är en regel som kan behöva konfigureras olika för olika delar av organisationen – vissa kan köra den i block-läge, medan andra behöver undantag eller att regeln fortsätter köra i audit-läge.
Rekommendation: 🟡 Börja med audit och lägg till undantag vid behov.
Block JavaScript or VBScript from launching downloaded executable content
Denna regel blockerar JavaScript och VBScript från att starta körbara filer som har laddats ner från internet.
Angripare använder ofta skript för att ladda ner och köra skadliga filer som nästa steg i en attack.
Rekommendation: 🟢 På
Block Office communication application from creating child processes
Idag är det vanligt att angripare skickar mejl med skadligt innehåll, till exempel länkar eller bilagor, för att få Outlook att starta skript eller körbara filer. Denna regel blockerar Outlook från att starta nya processer, och blockerar dessa angrepp.
Rekommendation: 🟢 På
Block Office applications from injecting code into other processes
Denna regel blockerar Office-applikationer från att injicera kod i andra processer.
Den här tekniken används av angripare för att injicera skadlig kod i en annan process, och på så sätt kringgå säkerhetsfunktioner. Vid normal användning är det väldigt ovanligt att detta behövs.
Jag rekommenderar att aktivera denna regel. Vid behov går det att lägga till specifika undantag.
Rekommendation: 🟢 På (lägg till undantag vid behov)
Block all Office applications from creating child processes
Blockerar Office-applikationer från att starta nya processer.
Ett väldigt vanligt angreppssätt är att använda makron i Office-dokument för att ladda ner och köra skadlig kod. Denna attackvektor är så pass vanlig att makron i filer som kommer från internet (till exempel via e-post eller nedladdningar) är blockerade som standard i dag.
Jag rekommenderar verkligen att aktivera den här regeln. Samtidigt kan det finnas betrodda makron som behöver starta andra processer, och i sådana fall går det att lägga till specifika undantag.
Rekommendation: 🟢 På (lägg till undantag vid behov)
Block rebooting machine in Safe Mode
Denna regel blockerar försök att starta om datorn i felsäkert läge.
Många säkerhetsprodukter blir inaktiverade eller begränsade i felsäkert läge. Angripare försöker utnyttja detta för att kunna köra kommandon utan att bli blockerade.
Rekommendation: 🟢 På
Block Webshell creation for Servers
Ett webshell är ett skript som en angripare laddar upp på en webbserver för att kunna köra kommandon, ladda upp eller ner filer och behålla åtkomst till systemet.
Normalt sett brukar man inte kunna ladda upp egna skript på webbservrar. För att lyckas med detta måste angriparen först hitta en server som kör en sårbar applikation.
Denna regel blockerar försök att spara webshells på servrar.
Rekommendation: 🟢 På
Block untrusted and unsigned processes that run from USB
Denna regel blockerar att osignerade eller ej betrodda program startar från flyttbara medier.
Angripare använder flyttbara medier, till exempel USB-minnen, för att sprida skadlig kod. Detta var ett större problem förr när AutoRun startade program automatiskt när en enhet anslöts. I moderna Windows-versioner är AutoRun avstängt som standard.
I de flesta miljöer påverkar regeln inte normal användning, eftersom legitima applikationer sällan körs direkt från USB-enheter.
Rekommendation: 🟢 På
Use advanced protection against ransomware
Denna regel ger ett extra skydd genom att analysera programs beteenden och försöka upptäcka mönster som är typiska för ransomware.
Regeln fungerar som ett extra skyddslager ovanpå det vanliga antiviruset och ger ett ökat skydd mot nya eller okända ransomware-varianter.
Rekommendation: 🟢 På
Block executable content from email client and webmail
Blockerar Microsoft Outlook och populära webmail-tjänster från att starta körbara filer och skript.
Detta inkluderar bland annat:
Körbara filer (.exe, .dll eller .scr)
Skript (PowerShell .ps1, Visual Basic .vbs eller JavaScript .js)
Arkivfiler (till exempel .zip-filer)
De flesta e-postklienter blockerar körbara filer och skript automatiskt. Denna regel fungerar därför som ett extra skyddslager och är ett bra komplement till det inbyggda skyddet.
Rekommendation: 🟢 På
Block abuse of exploited vulnerable signed drivers (Device)
Denna regel hindrar applikationer från att skriva kända sårbara drivrutiner till disk (även om de är korrekt signerade).
Applikationer med tillräcklig behörighet kan utnyttja sårbara drivrutiner för att få åtkomst till operativsystemets kernel och på så vis kringgå säkerhetsskydd eller manipulera systemet.
Regeln bygger på en blocklista över kända sårbara drivrutiner och ger ett bra skydd mot den här typen av attacker.
Rekommendation: 🟢 På
Attack Surface Reduction Only Exclusions
Här kan du ange filer eller mappar som ska exkluderas från alla ASR-regler. Dessa undantag påverkar bara ASR och gäller inte för antivirus eller EDR.
Eftersom dessa undantag gäller samtliga ASR-regler bör funktionen användas med försiktighet. I de flesta fall är det bättre att konfigurera per rule exclusion för specifika regler.
Rekommendation: ⚠️ Används endast vid behov
Enable Controlled Folder Access
Denna funktion hjälper dig skydda din viktigaste data från skadliga appar och hot, framförallt ransomware.
När funktionen är aktiverad får bara betrodda program skriva till skyddade mappar, till exempel Dokument, Bilder, Musik, Videor eller andra känsliga platser. Om ett program som inte är betrott försöker ändra filer blir åtgärden blockerad.
Controlled Folder Access är särskilt effektivt mot ransomware som ofta försöker kryptera användarens filer i just dessa mappar.
Detta är en kraftfull funktion, men jag rekommenderar att börja i audit-läge för att identifiera om ni behöver lägga till undantag för vissa applikationer.
Rekommendation: 🟡 Börja med audit och lägg till undantag vid behov.
Controlled Folder Access Protected Folders
Controlled Folder Access skyddar som standard ett antal vanliga användarmappar, till exempel Dokument, Bilder, Musik, Videor och Skrivbord.
Med denna inställning kan du lägga till egna mappar som ska vara skyddade.
Rekommendation: 🟡 Lägg till mappar vid behov.
Controlled Folder Access Allowed Applications
När Controlled Folder Access är aktiverat tillåts endast betrodda program att skriva till skyddade mappar. Program som inte är betrodda blockeras som standard.
Med denna inställning kan du lägga program som ska tillåtas, till exempel:
egenutvecklade program
äldre applikationer
skript eller administrativa verktyg
Rekommendation: 🟡 Lägg till program vid behov.
Sammanfattning
Det här var del 4 i serien om Defender for Endpoint och en genomgång av Attack Surface Reduction (ASR) och de regler som går att konfigurera.
Förhoppningsvis gav artikeln tips på hur du kan använda ASR-regler för att stärka säkerheten, utan att påverka användarupplevelsen.
Har du frågor, egna erfarenheter eller arbetar på ett annat sätt i din miljö? Dela gärna med dig i kommentarerna så hjälps vi åt att göra guiden ännu bättre 👍
Detta är del 3 i vår serie om Defender for Endpoint, och i den här delen ska vi titta närmare på antiviruspolicyer och Intune-portalen.
Innan vi går in på själva inställningarna är det bra att reda ut hur och var policyerna hanteras, eftersom det kan skilja sig åt beroende på licens och konfiguration.
Det finns flera sätt att arbeta med policyer, och i den här artikeln går vi igenom de vanligaste alternativen och hur de används i praktiken.
Direkt i Defender-portalen
Via Intune-portalen, genom att koppla ihop Defender for Endpoint med Microsoft Intune
Delar i serien
Här är en översikt över de delar som ingår i serien. Jag uppdaterar länkarna löpande allt eftersom nya inlägg blir publicerade.
Del 5 – Onboarding av enheter, device groups och RBAC-modellen
Del 6 – EDR, AIR, advanced hunting och incidenthantering
Konfiguration i Defender-portalen
Om du använder en Enterprise-version (Defender for Endpoint Plan 1 eller Plan 2) finns möjlighet att konfigurera alla policyer direkt i Defender-portalen, till exempel:
Antivirus
Brandvägg
Attack Surface Reduction (ASR)
Device Control
Dessutom går det att konfigurera policyer för både Windows, macOS och Linux.
Du hittar policyinställningarna under menyn ”Endpoint → Configuration management → Endpoint security policies”.
Använder du däremot en Business-version så ser menyerna lite annorlunda ut. I denna version hittar du policyinställningarna under ”Endpoint → Configuration management → Device configuration”.
Denna sida är väldigt begränsad jämfört med Enterprise-varianten. I Defender for Business kan du via Defender-portalen bara konfigurera:
Antivirus
Brandvägg
Och bara för Windows-enheter.
Men Defender for Business har faktiskt stöd för flera funktioner, till exempel Attack Surface Reduction (ASR). Likaså finns stöd för macOS och Linux. Skillnaden är att dessa policyer inte går att konfigurera i Defender-portalen utan måste hanteras via Microsoft Intune.
Man kan såklart nöja sig med att konfigurera antivirus- och brandväggspolicyer men det innebär att man går miste om flera viktiga säkerhetsfunktioner, framförallt Attack Surface Reduction, som är en central funktion i ett modernt skydd.
Därför rekommenderar jag starkt att man kopplar ihop Defender for Endpoint med Microsoft Intune. Intune ger tillgång till fler typer av policyer och är dessutom ett väldigt kraftfullt verktyg för enhetshantering.
⚠️ Viktigt: Använder du en Enterprise-version kan samtliga policyer som beskrivs i den här guiden konfigureras direkt i Defender-portalen.
I mitt fall använder jag Defender for Business, därför kommer jag koppla ihop Defender-portalen med Microsoft Intune och visa konfigurationen via Intune-portalen.
Inställningarna och rekommendationerna är dock desamma, oavsett vilket alternativ du använder.
Koppla ihop Defender-portalen med Microsoft Intune
Steg 1: Aktivera Intune-kopplingen i Defender-portalen
Scrolla ner till Configuration management och klicka på Enforcement scope
Aktivera inställningen Use MDE to enforce security configuration settings from Intune
När du aktiverat denna funktion visas en lista över vilka operativsystem som ska kunna hanteras via Intune.
I mitt fall klickar jag i:
Windows Client devices
Linux devices
macOS devices
Men det finns även möjlighet att välja:
Windows Server devices
Windows Server Domain Controller devices
När dessa inställningar är konfigurerade kan Defender for Endpoint och Microsoft Intune kommunicera med varandra. Detta innebär att enheter som onboardas i Defender-portalen även visas i Intune, samt att policyer som skapas i Intune kan tillämpas av Defender for Endpoint.
Antiviruspolicy – inställningar och rekommendationer
I detta avsnitt går vi igenom inställningarna i antiviruspolicyn. Jag har försökt beskriva varje funktion så tydligt och kortfattat som möjligt.
För att göra det enklare har jag lagt in en översiktstabell. Du kan klicka på namnen i tabellen för att hoppa direkt till respektive avsnitt.
⚠️ Obs! Jag vill än en gång poängtera att detta inte är en “How to” som passar alla, utan snarare en “How I do”. Jag tror att mina rekommendationer fungerar bra för många, men det finns såklart situationer där du kan behöva anpassa inställningarna.
Denna inställning innebär att Defender övervakar beteenden i realtid för att identifiera misstänkt aktivitet.
I stället för att enbart förlita sig på signaturer så analyserar Defender hur program, tjänster och filer beter sig. Detta gör det möjligt att upptäcka även nya och okända angrepp.
Inställningen är markerad som föråldrad och kan bli ändrad eller borttagen. Moderna funktioner som Network Protection och Attack Surface Reduction ersätter denna inställning.
Jag brukar sätta denna till Not configured för att följa Microsofts rekommendationer och undvika beroenden till funktioner som kan bli ändrade.
Aktiverar realtidsskydd, vilket innebär att filer, processer och aktiviteter skannas kontinuerligt medan de används. Detta är en grundläggande säkerhetsfunktion som alltid bör vara aktiverad.
Anger hur mycket processorkraft som Defender får använda vid skanningar.
Standardvärdet är 50% vilket kan påverka prestandan märkbart. På användarklienter sätter jag vanligtvis detta till 20–30%. Det blir bättre balans mellan skydd och prestanda.
Anger om Defender ska söka efter nya signaturer innan en schemalagd eller manuell skanning startar.
Om man uppdaterar skyddssignaturer regelbundet kan denna inställning vara överflödig. I miljöer där uppdateringar sker mer sällan kan det däremot vara bra att ha den aktiverad.
Rekommendation: 🟠 Inte konfigurerad (beror på uppdateringsfrekvens och miljö)
Anger om Microsoft Defender ska blockera potentiellt oönskade program (Potentially Unwanted Applications).
Jag rekommenderar att denna inställning är aktiverad. Potentiellt oönskade program kan innebära säkerhetsrisker. Om legitim programvara blir blockerad är det bättre att skapa ett undantag.
Anger vilken typ av skanning som ska köras vid schemalagda skanningar – snabbskanning eller fullständig skanning.
Det finns en separat inställning för att konfigurera dagliga snabbskanningar. Därför ser jag denna inställning som ett komplement och använder den för att schemalägga fullständiga skanningar.
Anger vilken tid den dagliga snabbskanningen ska köras.
Värde 0 motsvarar kl. 00:00, värde 60 motsvarar kl. 01:00 och så vidare.
Många guider rekommenderar att man kör denna skanning utanför arbetstid. Eftersom snabbskanning går fort och vanligtvis inte påverkar prestandan tycker jag att man ska köra den vid en tidpunkt då klienten sannolikt är på.
Anger vilken veckodag den schemalagda skanningen ska köras. Typ av skanning beror på ”Scan Parameter”.
Denna skanning är ett komplement till den dagliga snabbskanningen. Om det finns möjlighet att köra schemalagd fullständig skanning utan att påverka användarupplevelsen negativt är detta ett bra komplement.
Anger hur ofta Defender ska söka efter uppdaterade signaturer.
Standardvärde är 8 timmar, vilket i praktiken innebär en gång om dagen. När nya signaturer finns tillgängliga vill jag få ut dem så snabbt som möjligt.
Anger om Defender får skicka misstänkta filer till Microsoft för vidare analys.
Genom att tillåta automatisk insamling kan systemet analysera nya och okända hot snabbare. Denna inställning kan vara känslig ur integritetssynpunkt, därför rekommenderar jag ”Safe” som bara skickar nödvändig information och undviker känslig persondata.
Remediation action for Severe / Moderate / Low / High threats
Anger vilken åtgärd Defender vidtar när den identifierar ett hot. Jag rekommenderar att alltid placera hot i karantän, så att en säkerhetsanalytiker kan analysera hotet.
Anger om Network Protection ska analysera UDP-trafik även på Windows Server.
Som standard är denna inställning inaktiv eftersom den kan påverka prestandan negativt. Jag tycker man ska testa funktionen och se hur den fungerar på respektive server.
Dessa inställningar styr om Network Protection ska inaktivera analys av viss nätverkstrafik.
Jag rekommenderar att låta all protokollinspektion vara aktiv för att få maximalt skydd. Märker man att någon av funktionerna påverkar prestandan kan man stänga av den specifika analysen.
Rekommendation: 🟢 Av (aktivera protokollinspektion)
Anger om Defender ska slumpa starttider för schemalagda skanningar.
Denna inställning kan till exempel vara användbar i virtualiserade miljöer för att undvika att många virtuella gäster startar schemalagda jobb samtidigt.
Anger hur stort tidsintervall Defender kan använda för att slumpa starttider för schemalagda uppgifter (om randomisering är aktiverad).
Jag har inte haft behov av att justera denna inställning och har därför lämnat den okonfigurerad. Som standard innebär detta ett intervall på 4 timmar.
Anger om Core Service ska skicka diagnostik- och telemetridata till Microsoft.
Telemetri används för att förbättra funktionalitet, stabilitet och felsökning. Denna datadelning kan vara känslig ur integritetssynpunkt, beroende på organisationens krav och policyer.
Det här var del 3 i serien om Defender for Endpoint och en genomgång av de antiviruspolicyer som går att konfigurera. Förhoppningsvis ger artikeln en tydligare bild av hur man bygger ett bra grundskydd utan att i onödan påverka prestanda eller användarupplevelse.
Har du frågor eller arbetar du på ett annat sätt i din miljö? Dela gärna med dig i kommentarerna så hjälps vi åt att göra guiden ännu bättre 👍
Kryptering är en av de mest grundläggande byggstenarna inom IT-säkerhet. Samtidigt är det ett område som kan kännas svårt att greppa, särskilt när man börjar prata om publika nycklar, digitala signaturer och certifikat.
Tanken med det här inlägget är att enkelt förklara principerna bakom kryptering och signering – utan att djupdyka i tekniska detaljer.
Förhoppningsvis blir det också en bra grund inför kommande inlägg om DNSSEC, DANE och andra säkerhetsfunktioner som bygger på kryptering.
Vad är kryptering?
Kryptering är ett sätt att göra information oläsbar för alla som inte har rätt nyckel. Man tar klartext och förvandlar den till något som ser ut som slumpmässiga tecken. På så sätt kan man skicka känslig information över nätverk som andra kan avlyssna, utan att någon obehörig kan läsa innehållet.
Det är viktigt att skilja på kryptering och hashning.
Kryptering är en tvåvägsfunktion – man kan både kryptera och dekryptera.
Hashning är däremot envägs – när något väl är hashat går det inte att återskapa originalet.
Symmetrisk kryptering – när en nyckel räcker
Vid symmetrisk kryptering använder både avsändaren och mottagaren samma nyckel för att kryptera och dekryptera.
Ett klassiskt exempel är Caesar-chiffer, där man flyttar varje bokstav ett visst antal steg i alfabetet. Om originaltexten är “abc” och nyckeln är +5, blir det krypterade resultatet “fgh”. För att dekryptera texten flyttar mottagaren tillbaka bokstäverna med samma nyckel.
Eftersom symmetrisk kryptering är väldigt snabb och effektiv använder vi den i stort sett överallt – i TLS, VPN-tunnlar, för att kryptera filer och mycket mer.
Exempel på algoritmer för symmetrisk kryptering är:
AES – den vanligaste algoritmen i modern IT-säkerhet.
ChaCha20 – modernt och snabbt alternativ till AES.
3DES – klassisk algoritm som är föråldrad idag.
Men symmetrisk kryptering har ett stort problem: hur delar man nyckeln på ett säkert sätt?
Om någon får tag på nyckeln kan de läsa all trafik och data som krypterats med den. Ju fler som ska använda samma nyckel, desto större risk att den läcker.
Dessutom skalar det dåligt. För varje person eller system du vill kommunicera med måste du skapa en unik nyckel. I större miljöer blir det snabbt ohanterligt.
Det är dessa utmaningar som gjorde att man började utveckla lösningar där man inte behöver dela en nyckel i förväg. Resultatet blev asymmetrisk kryptering.
Asymmetrisk kryptering – två nycklar som bildar ett par
Asymmetrisk kryptering löser problemet med att dela hemliga nycklar i förväg. Istället använder man ett nyckelpar med en publik nyckel och en privat nyckel.
Den publika nyckeln kan du dela med vem som helst.
Den privata behåller du själv och skyddar noga!
Nycklarna konstrueras på ett sätt så att de hör ihop matematiskt. Det du krypterar med den publika nyckeln går bara att dekryptera med den tillhörande privata nyckeln.
Genom att dela din publika nyckel kan alla skicka krypterad information till dig, och bara du kan dekryptera den med din privata nyckel.
📌 Exempel: Tänk dig att du vill skicka ett hemligt meddelande till Anna. Du använder då Annas publika nyckel för att kryptera meddelandet.
När det kommer fram kan bara Anna dekryptera meddelandet, eftersom det krävs hennes privata nyckel. Om någon annan får tag i det krypterade meddelandet kan de ändå inte läsa innehållet, eftersom de inte har den privata nyckeln.
Exempel på algoritmer för asymmetrisk kryptering är:
RSA – klassisk och mycket spridd. Används ofta i TLS-certifikat och för signering.
ECDSA / ECDH – moderna algoritmer för signering och nyckelutbyte.
Ed25519 / X25519 – moderna och snabba alternativ till ECDSA / ECDH.
Men om asymmetrisk kryptering löser de här problemen, varför använder vi inte alltid den metoden? Jo, för i jämförelse med symmetrisk kryptering är asymmetrisk kryptering långsammare och mer resurskrävande.
Istället använder man en kombination:
Asymmetrisk kryptering för att säkert komma överens om en nyckel.
Därefter symmetrisk kryptering för att snabbt och effektivt kryptera själva trafiken och datan.
Nedan kommer ett exempel på hur asymmetrisk och symmetrisk kryptering används tillsammans.
⚠️ Viktigt! Detta är en förenklad illustration. Moderna protokoll som TLS 1.3 använder mer avancerade nyckelutbyten, men principen är densamma.
Signering – bevisa äkthet och integritet
Kryptering löser problemet att hålla hemlig data skyddad. Men hur kan vi vara säkra på vem som skickat informationen och att den inte blivit ändrad? Det är här signering kommer in.
Vid asymmetrisk kryptering använder vi mottagarens publika nyckel för att kryptera data. På så vis vet vi att bara mottagaren kan dekryptera innehållet.
Signering fungerar precis tvärtom. Här använder avsändaren sin privata nyckel för att signera informationen. Alla som har tillgång till avsändarens publika nyckel kan verifiera signaturen och därmed bekräfta två saker:
Äkthet – att informationen kommer från den som äger den privata nyckeln.
Integritet – att innehållet inte har blivit ändrat efter signeringen.
📌 Exempel: Tänk dig att du vill skicka ett viktigt meddelande till Anna, och du vill att hon ska kunna verifiera att det verkligen kommer från dig.
Du signerar meddelandet med din privata nyckel.
När Anna tar emot meddelandet använder hon din publika nyckel för att verifiera signaturen.
Hashfunktionens roll
Hashning är en viktig del av signering. I praktiken signerar man nästan aldrig hela meddelanden. Istället beräknar man en hash av innehållet och signerar hashvärdet.
Hashning är en metod som tar emot vilken data som helst – en text, en fil eller ett lösenord – och omvandlar det till en unik sträng, ett så kallat hashvärde.
Det fiffiga med hashning är att:
samma input ger alltid samma hashvärde.
minsta lilla ändring (även om det bara är ett enda tecken) gör att hashvärdet blir annorlunda.
hashning är envägs – det går inte att återskapa originalet från hashvärdet.
Dessa egenskaper gör hashning populär även i andra sammanhang – till exempel för att beräkna checksummor på filer, eller för att lagra hashade lösenord i databaser.
Vanliga typer av hash-algoritmer är:
SHA-256 – en av de vanligaste hashfunktionerna idag. Används i TLS, certifikat, signering och många säkerhetsprotokoll.
SHA-1 – tidigare mycket vanlig, men idag osäker och bör inte användas i säkerhetskritiska system.
MD5 – historiskt sett extremt vanlig, men helt osäker idag.
Hur kan vi lita på nycklarna?
Nu när vi lärt oss hur asymmetrisk kryptering och signering fungerar blir det tydligt att dessa metoder bygger helt på att vi kan lita på den publika nyckeln. Om vi inte är säkra på vem den publika nyckeln tillhör, hur vet vi då att vi skickar krypterad information till rätt person?
I vissa implementationer, som GPG, kan vi behöva verifiera manuellt att en publik nyckel verkligen tillhör rätt person – till exempel genom att ringa personen och jämföra nycklarnas fingeravtryck. Många andra system använder certifikat och betrodda utfärdare för att automatisera den här kontrollen.
Vad är ett certifikat?
I grunden är ett certifikat en publik nyckel kombinerad med information om vem nyckeln tillhör. Du kan tänka dig att ett certifikat är ett slags digitalt ID-kort.
Vem utfärdar certifikaten?
Precis som vanliga ID-kort så behöver certifikat utfärdas av någon vi litar på. Den rollen har en Certificate Authority (CA).
En CA är en betrodd part som:
Intygar att den som ansöker om ett certifikat verkligen är rätt person eller domän.
Skapar ett certifikat som innehåller den publika nyckeln och information om ägaren.
Signerar certifikatet med sin privata nyckel, så att andra kan verifiera att det är äkta.
Det är CA:ns signatur som gör att vi kan lita på att certifikatet, och att den publika nyckeln verkligen tillhör rätt mottagare.
Din dator eller mobil har en inbyggd lista över betrodda CA, och kraven för att få vara med på den listan är väldigt höga. Det går även att skapa en egen CA för interna system, men då måste du även konfigurera alla klienter så att de också litar på denna.
Sammanfattning – tre saker att ta med sig
1. Kryptering skyddar innehållet
Kryptering gör informationen oläsbar för obehöriga.
Symmetrisk kryptering är snabb och används för själva datatrafiken.
Asymmetrisk kryptering löser problemet med att dela hemliga nycklar genom att använda ett nyckelpar (en publik och en privat nyckel).
2. Signering verifierar äkthet och integritet
Genom att signera data med en privat nyckel kan mottagaren verifiera både äkthet (vem som skickat det) och integritet (att innehållet är oförändrat).
3. Certifikat hjälper oss att veta vem nyckeln tillhör
Kryptering och signering fungerar bara om vi kan lita på nycklarna. En betrodd CA signerar certifikat så att vi kan lita på att en publik nyckel verkligen tillhör rätt person eller server.
I det förra inlägget gick vi igenom grunderna i Defender for Endpoint – bland annat vilka versioner som finns, vad som skiljer dem åt och hur du kommer igång via setup-guiden.
I den här delen går vi igenom Advanced features. Jag vill redan nu flagga för att det är en hel del att gå igenom – men det beror på att det här är viktiga funktioner som förtjänar att få en ordentlig genomgång.
Jag har försökt beskriva varje funktion så tydligt och kortfattat som möjligt. Och för att göra det ännu enklare har jag även lagt in en översiktstabell. Du kan klicka på namnen i tabellen för att hoppa direkt till respektive avsnitt.
⚠️ Obs! Jag vill poängtera att detta inte är en “How to” som passar alla, utan snarare en “How I do”. Jag tror att mina rekommendationer fungerar bra för många, men det finns såklart situationer där du kan behöva anpassa inställningarna.
Delar i serien
Här är en översikt över de delar som ingår i serien. Jag uppdaterar länkarna löpande allt eftersom nya inlägg blir publicerade.
Där hittar du alla funktioner som vi går igenom i detta inlägg.
Genomgång av funktionerna
Enable EDR in block mode
Till att börja med är det viktigt att förstå att Defender for Endpoint består av flera olika delar. Antivirus är en funktion och EDR en annan, och du måste inte nödvändigtvis använda båda.
EDR in block mode gör att Defender kan blockera skadliga aktiviteter som EDR-funktionen hittar, till exempel beteenden eller processer som tagit sig förbi det primära antiviruset.
Denna funktion är särskilt värdefull om du använder ett antivirus från en annan leverantör. I sådana miljöer går Defender in i passive mode och analyserar bara attacker utan att blockera dem. Med EDR in block mode kan EDR-funktionen ändå blockera skadliga aktiviteter – utan konflikt med befintligt antivirus.
Med allow or block file kan du blockera eller tillåta filer baserat på filens hash. Du lägger till hashar manuellt under menyn Indicators.
Funktionen är särskilt användbar vid en incident, till exempel om du snabbt behöver stoppa filer som antiviruset inte detekterat. Eller om en legitim fil blir blockerad av misstag.
Rekommendation: 🟢 Bör vara påslagen – lägg till indicators vid behov.
Liknar allow or block file, men låter dig blockera eller tillåta IP-adresser, URL:er och domäner.
Detta är en bra funktion om du snabbt behöver blockera specifika adresser, till exempel vid en incident eller om du fått hotinformation från en leverantör, CERT-SE eller en säkerhetspartner. Den är också ett bra komplement till traditionella webbfilter eller brandväggsregler.
Rekommendation: 🟢 Bör vara påslagen – lägg till indicators vid behov.
Vid en cyberattack är det vanligt att angripare försöker stänga av antivirus och EDR för att kunna fortsätta attacken utan att bli upptäckt.
Tamper protection hindrar en angripare från att ändra inställningar eller stänga av Defender for Endpoint, även om angriparen har lokala administratörsbehörigheter.
När du aktiverar den här inställningen visas detaljer om vilken användare som är kopplad till en specifik enhet eller incident. Det gör det enklare att förstå vem som är påverkad så att du kan kontakta rätt person.
Rekommendation: 🟢 Bör vara påslagen, förutom i miljöer där du har särskilda krav på integritet och behöver anonymisera användare.
Med den här inställningen får du en Skype for Business-länk bredvid användarinformation i Defender-portalen. På så sätt kan du snabbt kontakta användare direkt från portalen.
Skype for Business är föråldrat. Om du använder Teams fyller inställningen ingen funktion.
Den här inställningen integrerar Defender for Endpoint med Microsoft Defender for Cloud Apps. Då kan klienterna skicka information som hjälper dig att se vilka molntjänster dina användare nyttjar.
Den här integrationen är bra för att upptäcka skugg-IT och riskabla eller otillåtna molntjänster.
Rekommendation: 🟢 Bör vara påslagen (förutsatt att du har licens för Defender for Cloud Apps).
Låter dig blockera webbplatser baserade på kategorier, till exempel sociala medier, spel eller vuxeninnehåll.
Många organisationer har redan webbfilter i brandväggen men jag gillar att komplettera med denna funktion eftersom den blockerar direkt på klienten, oavsett vilket nätverk enheten är ansluten till.
Med Device discovery kan dina enheter som kör Defender for Endpoint hjälpa till att upptäcka och rapportera andra enheter i nätverket som ännu inte är onboardade.
Syftet är att se vilka enheter som saknar skydd eller inte är hanterade av organisationen.
⚠️ Viktigt:Device discovery körs på det nätverk som enheten är ansluten till. Det innebär att även hemmaroutrar och annan utrustning i ett hemmanät kan dyka upp i listan. Jag tycker att fördelarna överväger nackdelarna – att kunna kartlägga nätverket är en fantastisk funktion – men det är viktigt att vara medveten om detta, särskilt i miljöer med höga integritetskrav.
Default to streamlined connectivity when onboarding devices in Defender portal
Den här inställningen förenklar kommunikationen mellan enheter och Defender-portalen. Särskilt bra om du har strikta brandväggsregler för utgående trafik.
Apply streamlined connectivity settings to devices managed by Intune and Defender for Cloud
Den här inställningen gör att enheter du hanterar via Intune eller Defender for Cloud använder samma förenklade kommunikationsinställningar som övriga enheter. Särskilt bra om du har strikta brandväggsregler för utgående trafik.
Defender for Endpoint gör sitt bästa för att filtrera bort händelser som är återkommande eller har lågt informationsvärde.
Med Aggregated Reporting visas fler typer av händelser, även sådana som normalt filtreras bort. Men istället för att skicka tusentals likadana event skickas de i en sammanfattad, aggregerad form.
Det innebär att du får mer data och bättre kontext, utan att mängden brus ökar. Däremot kan datavolymen bli större om du skickar vidare data till en SIEM-lösning.
Rekommendation: 🟢 Bör vara påslagen – särskilt om du jobbar med advanced hunting eller använder SIEM.
När du isolerar en enhet i Defender for Endpoint stoppar systemet all inkommande och utgående nätverkstrafik (förutom den trafik som Defender kräver). Med Isolation Exclusion Rules kan du lägga till undantag och tillåta specifika IP-adresser eller portar även när enheten är isolerad.
Rekommendation: 🔴 Lämna avstängd – använd endast om du har ett tydligt och dokumenterat behov.
Live response låter dig fjärransluta till en enhet via ett kommandogränssnitt i Defender-portalen. På så sätt kan du felsöka, samla loggar, analysera filer och utföra åtgärder direkt på enheten – utan behov av fjärrskrivbord eller andra verktyg.
Funktionen är väldigt kraftfull vid incidenthantering, men du behöver tydliga rutiner eftersom kommandon körs med hög behörighet på enheten.
Live response for servers fungerar på samma sätt som för klienter: du kan fjärransluta till en server via ett kommandogränssnitt i Defender-portalen och felsöka eller utföra åtgärder direkt på systemet.
På servrar innebär detta en betydligt större risk, eftersom funktionen kringgår säkerhetsmodeller som tiering, krav på begränsade admin-konton eller dedikerade jumpstations.
Rekommendation: 🔴 Stäng av – fjärrstyr servrar via kontrollerade metoder.
Med den här inställningen kan du köra osignerade PowerShell-skript via Live Response. Det innebär en tydlig säkerhetsrisk eftersom skript körs med hög behörighet.
Share endpoint alerts with Microsoft Compliance Center
Den här inställningen gör att Defender for Endpoint skickar sina säkerhetslarm till Microsoft Purview Compliance Center. Det innebär att du får larmen direkt i compliance-utredningar och att systemet samtidigt samlar all relevant information på ett ställe.
Den här inställningen aktiverar kommunikationen mellan Intune och Defender for Endpoint.
När den är på kan du använda Intune för att skapa policyer, compliance-regler och rapporter baserat på säkerhetsdata från Defender. En riktigt bra funktion om du använder Intune för att hantera dina enheter.
Rekommendation: 🟢 Bör vara påslagen (om du använder Intune).
Authenticated telemetry innebär att enheter måste verifiera sig när de skickar data till Defender-portalen. På så vis minskar risken för spoofad eller felaktig telemetri.
Preview features låter dig prova nya funktioner i Defender for Endpoint innan Microsoft släpper dem skarpt.
⚠️ Viktigt: Vissa förhandsversioner kan innebära att telemetri eller data behandlas i andra regioner än den du valt. Om ni har strikta krav på var data lagras bör denna funktion vara avstängd.
Rekommendation: 🔴 Stäng av (kan vara på i testmiljöer).
Det var en genomgång av Advanced features i Defender for Endpoint. Förhoppningsvis ger det här dig en tydligare bild av vilka funktioner som är värda att aktivera – och varför.
Har du frågor eller gör du på något annat sätt i din miljö? Dela gärna med dig i kommentarerna!
Microsoft Defender for Endpoint (MDE) är Microsofts lösning för att skydda klienter och servrar mot skadlig kod och cyberattacker. Dessutom är det en av de centrala byggstenarna i Microsofts säkerhetsplattform Defender XDR.
I den här bloggserien går jag igenom hur du kommer igång med MDE och får en bra grundkonfiguration som passar de flesta organisationer. Fokus ligger på praktiska exempel, så att du snabbt kommer igång och kan stärka skyddet i din miljö.
När vi har gått igenom MDE kommer jag även att titta närmare på andra delar i Defender XDR, till exempel Defender for Office 365 och Defender for Cloud Apps – och hur de tillsammans bildar en helhet för att bygga ett heltäckande skydd mot moderna hot.
Delar i serien
Här är en översikt över vad som kommer i resten av serien. Jag uppdaterar länkarna löpande allteftersom nya delar blir publicerade.
Del 5 – Onboarding av enheter, device groups och RBAC-modellen
Del 6 – EDR, AIR, advanced hunting och incidenthantering
Vilken version av Defender for Endpoint behöver du?
Defender for Endpoint finns i tre olika versioner:
Plan 1 – Grundläggande skydd med antivirus och ASR
Defender for Business – Ingår i Microsoft 365 Business Premium (passar bra för små och medelstora företag)
Plan 2 – Avancerat skydd med samtliga säkerhetsfunktioner
Funktion
Plan 1
Defender for Business
Plan 2
Next Gen Protection
✅
✅
✅
Attack Surface Reduction
✅
✅
✅
Endpoint Detection & Response (EDR)
❌
✅
✅
Threat Analytics
❌
✅
✅
Vulnerability Management
❌
✅
✅
Automated investigation and response (AIR)
❌
✅
✅
Advanced Hunting (KQL queries)
❌
❌
✅
Min erfarenhet är att många företag använder Plan 1 eftersom det ingår i Microsoft 365 E3. Det täcker de mest grundläggande delarna, men för att stå emot dagens attacker räcker det inte med antivirus. För ett komplett skydd behöver du EDR som analyserar beteenden och upptäcker mer avancerade hot.
Endpoint Detection & Response hjälper till att upptäcka, analysera och åtgärda hot som tagit sig förbi traditionellt antivirus.
Ett vanligt antivirus blockerar kända skadliga filer, medan en EDR analyserar beteenden och kontext — till exempel att ett Office-program plötsligt startar PowerShell och gör ovanliga nätverksanrop.
I den här serien använder jag Defender for Business eftersom det ingår i Microsoft 365 Business Premium. Det är ett prisvärt alternativ som innehåller det mesta en mindre organisation behöver. Det enda jag saknar är möjligheten att köra avancerade KQL-frågor. Vill man ha den funktionen behöver man köpa till Defender for Endpoint Plan 2 som innehåller all funktionalitet.
Kom igång med Defender
Steg 1 – Logga in i Defender-portalen
För att komma igång, öppna Defender-portalen och logga in. Vid första inloggningen kan det vara bra att använda ett konto med rollen Global Administrator eller Security Administrator. Det säkerställer att du har rätt behörighet för att köra den initiala setup-guiden.
⚠️ Obs: När du loggar in för första gången kan det hända att alla menyer inte visas direkt. Du kan även få upp felmeddelanden eller ett meddelande som liknar detta:
Detta beror på att tjänsten håller på att startas upp för din organisation. Vanligtvis är detta klart på några minuter.
När tjänsten är redo visas guiden ”Welcome to Microsoft Defender for Business”. Klicka på ”Get started” för att starta setup-guiden.
Steg 2 – Tilldela behörigheter
På sidan ”Let’s give people access” konfigurerar du vilka användare som ska få rollerna ”Security Administrator” eller ”Security Reader”.
Dessa är fördefinierade roller i Microsoft Entra ID som ger generell behörighet till olika säkerhetsfunktioner. Utöver dessa har Defender XDR även sin egen RBAC-modell som ger möjlighet till mer detaljerad behörighetsstyrning. Men vi återkommer till detta senare under bloggserien.
Security Administrator rekommenderas för den eller de som ska konfigurera Defender for Endpoint, hantera policys, onboarda enheter och agera på incidenter.
Security Reader passar bra för helpdesk eller IT-tekniker som behöver kunna se incidenter och enheternas status, men som inte ska kunna vidta åtgärder.
💡 Tips: Om du inte är säker på vilka användare eller grupper som ska ha vilken behörighet kan du enkelt justera dessa roller i efterhand via Entra ID.
Steg 3 – Sätt upp e-postnotiser
Jag rekommenderar att man sätter upp en delad postlåda, till exempel security@företag.se, så att flera i teamet blir notifierade när en incident uppstår. Den här lösningen fungerar bra för mindre organisationer som inte får så många incidenter.
För större miljöer är e-post sällan tillräckligt. Då använder man ofta Microsoft Sentinel eller andra SIEM-lösningar för att integrera notiser med till exempel Teams, Slack eller ett ärendehanteringssystem.
Steg 4 – Hoppa över onboarding tills vidare
Därefter finns det möjlighet att börja med onboarding. Jag avvaktar med detta och väljer att slutföra alla grundläggande inställningar först. Del tre i bloggserien kommer att fokusera helt på olika alternativ för onboarding.
💡 Tips: I guiden kan du bara lägga till Windows-enheter. Vill du lägga till andra operativsystem måste du göra det efter att guiden är slutförd.
Steg 5 – Aktivera standardpolicys
Sista steget är att aktivera standardpolicys för antivirus och brandvägg. Klicka på ”Continue” för att låta guiden skapa dessa automatiskt.
💡 Tips: Standardpolicys fungerar ofta bra för de flesta miljöer. Du kan antingen använda dem som de är, eller använda dem som en grund när du vill skapa egna policys.
När konfigurationen är klar kan det hända att följande felmeddelande visas:
Something went wrong, and we couldn’t complete your setup process. There’s an integration issue between Defender for Business and Microsoft Endpoint Manager.
Detta felmeddelande innebär att det inte finns någon koppling mellan Defender for Business och Microsoft Intune, vilket är helt rimligt eftersom vi inte satt upp den integrationen än. Vi återkommer till detta i nästa del av serien.
Vad är nästa steg?
Setup-guiden täcker det mest grundläggande, men det finns fler inställningar som är värda att se över. I nästa inlägg i bloggserien går jag igenom ”Advanced features” där du kan anpassa Defender for Endpoint efter dina behov. Det handlar bland annat om:
EDR in block mode
Tamper Protection
Web content filtering
Device discovery
Live response
Microsoft Defender for Cloud Apps
Custom indicators
… och flera andra funktioner som är bra att känna till
Där går jag igenom vad du bör aktivera, varför — och vad du kan låta vara avstängt beroende på hur din organisation arbetar.
För att skydda din domän mot spam, phishing, spoofing och andra bluffmejl finns det tre tekniker du måste känna till: SPF, DKIM och DMARC.
Tillsammans ser de till att mejl som skickas i ditt namn verkligen kommer från dig, och skyddar mot att någon missbrukar din domän för bedrägerier.
I den här guiden går vi igenom hur varje teknik fungerar, hur du implementerar dem, och hur de samverkar till ett komplett skydd.
SPF – Vilka servrar som får skicka mejl
Sender Policy Framework (SPF) skyddar mejl mot förfalskning (även kallat spoofing). Tanken är enkel – du som ägare av en domän anger vilka servrar som får skicka mejl i ditt namn.
Du gör detta genom att lägga till en TXT-post i din DNS. I posten anger du de IP-adresser som får skicka mejl för din räkning.
v=spf1 ip4:40.92.0.0/15 -all
I exemplet ovan har jag lagt till en av de nätadresser som Microsoft 365 använder för att skicka mejl. Men Microsoft använder många olika adresser och istället för att behöva lägga till dessa manuellt kan du inkludera Microsofts färdiga SPF-post:
v=spf1 include:spf.protection.outlook.com -all
Här är en snabb förklaring av de vanligaste taggarna i en SPF-post:
Tagg
Betydelse
v=spf1
Anger vilken version som SPF-posten använder. Den här taggen ska alltid stå först.
ip4:
Specificerar en IPv4-adress, eller en nätadress som får skicka mejl från domänen.
include:
Används för att inkludera en annan domäns SPF-post.
-all
Anger vad som ska hända med mejl som inte matchar någon tillåten server: -all = neka ~all = markera som misstänkt ?all = låter mottagaren avgöra Den här taggen ska alltid stå sist.
Jag skriver att mejl kan ”blockeras”, ”flaggas” eller ”accepteras”, men det är viktigt att förstå att det inte är din SPF-post som bestämmer detta. SPF fungerar snarare som en rekommendation till mottagarens mejlserver.
Låt säga att företaget ”Fiffel & Båg” försöker göra ett bedrägeriförsök i ditt namn. Det finns inget som hindrar dem från att skicka ett mejl och ange din domän som avsändare. Det är först när mejlet når mottagarens server som SPF-kontrollen görs:
Servern kontrollerar vilken IP-adress mejlet skickades från.
Den läser din SPF-post i DNS.
Och den avgör om mejlet ska blockeras, flaggas eller accepteras utifrån resultatet.
Om du använder Microsoft 365 sköts detta automatiskt – du behöver bara lägga till SPF-posten i DNS.
Så aktiverar du SPF för din domän
För att implementera SPF behöver du bara lägga till en TXT-post i DNS. Hur du gör det beror på din DNS-leverantör, men principen är densamma.
Här är ett exempel från min post hos Loopia där jag har konfigurerat SPF för Microsoft 365. I Loopia loggar man in i kundzonen, klickar på det domännamn man vill konfigurera, väljer knappen ”DNS-editor” och lägger sedan till en ny post under ’@’.
💡 Tips: Glöm inte att även inkludera andra tjänster du använder för mejl, t ex verktyg för nyhetsbrev eller maillistor.
DKIM – Skriv under dina mejl digitalt
SPF är en bra grund, men för att få bästa möjliga skydd måste du även konfigurera DKIM.
Så här fungerar tekniken: du som ägare av en domän skapar ett nyckelpar (en privat och en publik nyckel). Den privata nyckeln är hemlig och finns bara på din mejlserver. Den publika nyckeln är, precis som det låter publik, och läggs upp som en TXT-post i din DNS (i formatet id._domainkey.dittföretag.com). På så vis kan alla ta del av den.
När du skickar mejl skapar mejlservern en signatur med den privata nyckeln och lägger till den i mejlet. När mottagaren får mejlet hämtar deras server den publika nyckeln från din DNS och verifierar signaturen. På så sätt kan mottagaren vara säker på att mejlet verkligen kommer från dig. Dessutom säkerställer signaturen att innehållet i mejlet inte blivit förändrat på vägen.
Så lägger du till DKIM-signering
Konfigurationen kan se lite olika ut beroende på vilken DNS- och mejlleverantör du använder. I mina exempel använder jag Loopia och Microsoft 365.
Skrolla ner till rubriken ”Rules” och klicka på ”Email authentication settings”
Klicka på fliken ”DKIM” och markera ditt domännamn i listan.
Klicka på ”Create DKIM keys”
När du klickar på ”Create DKIM keys” skapas ett nyckelpar automatiskt i bakgrunden. Exchange Online konfigureras med den privata nyckeln, medan den publika nyckeln görs tillgänglig via DNS.
Microsoft hanterar det här automatiskt, så du behöver inte lägga upp den publika nyckeln manuellt. Istället publiceras den under en domän som är unik för din tenant. Guiden visar sedan två CNAME-poster som du ska lägga till i din DNS för att peka på den publika nyckeln.
🛡️ Säkerhetstips: När man aktiverar DKIM i Defender-portalen genererar Microsoft nycklar som är 1024 bitar långa. Idag är best practice att använda 2048 bitar. Tyvärr går det inte att välja nyckellängd i webbgränssnittet men det går att göra om man roterar nycklarna med PowerShell.
DMARC samarbetar med SPF och DKIM för att upptäcka och rapportera försök att missbruka din domän.
Diagrammet nedan visar hur processen ser ut när ett mejl skickas och tas emot:
Även denna teknik är enkel. Du skapar en TXT-post i DNS med formatet _dmarc.dindomän.se.
När en mottagare får mejl från din domän kontrollerar deras server först SPF och DKIM. Om något inte stämmer läser servern din DMARC-post för att avgöra hur den ska hantera och rapportera mejlet.
None: gör ingenting, bara rapportera
Quarantine: lägg i skräppost
Reject: blockera
Därefter skickar mottagarens mejlserver tillbaka en rapport. På så sätt ser du snabbt om någon försöker missbruka din domän.
Så ställer du in din DMARC-policy
Precis som för SPF och DKIM så behöver du lägga till en TXT-post i DNS med namnet _dmarc.dindomän.se.
Här är en snabb förklaring av de viktigaste taggarna i rapporten:
Tagg
Förklaring
<report_metadata>
Anger vem som skickat rapporten och vilken tidsperiod den gäller.
<policy_published>
Din aktuella DMARC-konfiguration.
<record>
En eller flera resultat med IP-adress, antal mejl och om de klarade SPF/DKIM-kontrollerna.
Men ingen blir lycklig av att få dessa rapporter mejlade och behöva granska dem manuellt. För att verkligen dra nytta av DMARC behöver du ett verktyg som:
tar emot rapporterna automatiskt
sammanställer tydliga grafer och statistik
och skickar larm om någon försöker missbruka din domän
Det finns en mängd olika tjänster som gör detta, även en del gratisalternativ. För learntodefend.se använder jag URIports. I deras dashboard ser jag tydligt alla mejl som är skickade från min domän och om de klarat SPF/DKIM-kontrollerna:
I exemplet ovan ser du två testmejl. Ett giltigt som är skickat från min Microsoft 365-tenant, och ett fejkmejl som jag skickat med ett verktyg för att spoofa min domän.
Sammanfattning
Om du följer de här tipsen och aktiverar SPF, DKIM och DMARC så får du ett bra skydd mot falska mejl och bedrägerier.
Alla tre teknikerna arbetar tillsammans och kompletterar varandra, men det går så klart fint att börja med exempelvis SPF och sedan bygga på med DKIM och DMARC efter hand.
Finns det några risker med att aktivera SPF, DKIM och DMARC?
Ja, det finns en viss risk att giltiga mejl blir blockerade. Jag har arbetat på flera företag där vi använt SPF, DKIM och DMARC med en blockerande policy, och det vanligaste problemet är avsändare som konfigurerat SPF felaktigt (dvs att de skickar mejl från en IP-adress som inte finns med i deras SPF-post).
Men jag föredrar att dessa blockeras, och att jag får en rapport så att jag kan kontakta avsändaren och hjälpa dem rätta till felet. Hellre det än att blunda och släppa igenom felaktiga poster. I de flesta fall brukar avsändare bli glada när man hör av sig och vill hjälpa dem förbättra sin säkerhet.
Och tänk på att även om du har aktiverat SPF, DKIM och DMARC finns det nästan alltid möjlighet att lägga till undantag i mejlservern.
Det finns andra tekniker som också är värda att nämna – DANE, MTA-STS och TLS-RPT. De tillför ytterligare en nivå av skydd utöver SPF, DKIM och DMARC. Men jag återkommer till dem i en kommande bloggpost.
Varje år under cybersäkerhetsmånaden anordnar CERT-SE en öppen CTF och i år var inget undantag. Utmaningen bestod av en nätverksdump som gick att hämta från deras webbplats och målet var att hitta totalt tio flaggor som de gömt i filen.
Nu har sista datum för att skicka in svar passerat och jag har fått tillåtelse från CERT-SE att publicera hur jag tog mig an utmaningen och lyckades hitta alla flaggor.
Stort tack till mina kollegor Anton, Magnus, Martin och Mattias. I år fick vi möjlighet att sätta av en förmiddag för att börja med CTF:en tillsammans, och det var både lärorikt och riktigt roligt.
En CTF är en perfekt teamaktivitet – man lär sig nytt och får träna problemlösning samtidigt som man vässar sina kunskaper inom IT-säkerhet. Win-win!
🏁 Flagga 1 – strings
Jag började med det enklaste: att köra kommandot strings på PCAP-filen. Då dök första flaggan upp direkt: ctf[strings_or_cat?].
🏁 Flagga 2 – FTP lösenord
Jag öppnade PCAP-filen i Wireshark. Direkt visas ett felmeddelande: ”The capture file appears to be damaged or corrupt”. Redan här får vi en hint om att filen förmodligen är manipulerad.
Jag började med att klicka på menyn Statistics > Protocol Hierarchy för att få en överblick över trafiken. Därefter högerklickade jag på ett TCP-paket, valde menyn Follow > TCP Streams och stegade igenom de olika sessionerna för att titta närmare på innehållet.
PCAP-filen består av både HTTP-, SMTP- och FTP-sessioner, och flera filer som skickats via dessa protokoll.
index.html
sessionstore.jsonlz4
CERT-SE.jpg
PHOTOS.img
monstrum_piscis_tres
ctf.txt
passwd_policy.txt
Jag sparade alla filer och kommer att återkomma till dem i tur och ordning, men noterade direkt en FTP-inloggning med användarnamn flag och lösenord 983e3a1fbb4232fff96282ab9a37f89a.
Lösenordet ser ut att kunna vara en MD5-hash. Enligt passwd_policy.txt ska alla lösenord komma från ordlistan rockyou.txt men vara formaterade som ctf[lösenord]. Så jag skapade en modifierad version av rockyou.txt enligt det angivna formatet och använde John the Ripper för att knäcka lösenordet.
sed 's/^/ctf[/' /usr/share/wordlists/rockyou.txt | sed 's/$/]/' > ctf_rockyou.txt
john --format=raw-md5 --wordlist=ctf_rockyou.txt hash.txt
John knäckte snabbt lösenordet: ctf[cutenessie4eva].
🏁 Flagga 3 – index.html
Index.html visar ett mönster med gröna rutor. Till en början trodde jag det skulle representera binärdata, men när jag ändrade webbläsarens bredd började ett mönster formas och efter lite labbande framträdde texten CTF[MAtrix].
🏁 Flagga 4 – sessionstore.jsonlz4
Sessionstore.jsonlz4 är en fil som används av Firefox för att spara information om sessioner, inklusive öppna flikar och fönster.
Eftersom filen var bifogad i ett mejl behövde jag först Base64-dekoda den. Därefter använde jag verktyget lz4jsoncat för att skriva ut innehållet. Då hittade jag flikar med följande adresser:
https://cert.se/#16n4[2t
https://cert.se/#13t1c3f
https://cert.se/#17]12c5r
https://cert.se/#6e8u11e
https://cert.se/#15o7s9r
https://cert.se/#10r14i
Detta visade sig vara ett enkelt chiffer där siffrorna anger på vilken plats efterföljande tecken ska skrivas ut:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
c
t
f
[
r
e
s
u
r
r
e
c
t
i
o
n
]
På så vis bildas flaggan ctf[resurrection].
🏁 Flagga 5 – CERT-SE.jpg
CERT-SE.jpg innehåller ett mystiskt rutmönster i övre högra hörnet. Jag klippte ut detta mönster, gjorde en bildsökning med Google och identifierade chiffret som Hexahue.
PHOTOS.img visade sig vara en avbildning av ett filsystem. När jag monterade avbildningen fanns fem filer:
beach.png
best_friends.png
biking.png
ice_cream.png
sherLOCH.png
Eftersom det var en avbildning började jag misstänka att det kunde finnas mer data. Jag läste in avbildningen i Autopsy och hittade en borttagen fil mystery.jpg.
Den saknade fyra bytes i början av headern, men efter att jag lade till dem manuellt gick det att öppna bilden.
Även denna fil var bifogad i ett mejl, så jag började med att Base64-dekoda den. Därefter körde jag kommandot file för att identifiera filens innehåll:
file rapporterade att innehållet är MP3-audio. När jag spelade upp ljudet hördes en svag, förvrängd röst som lät baklänges eller robotliknande, och ett konstant pip som gjorde rösten svår att höra.
Eftersom jag inte är van vid att analysera ljudfiler tog jag hjälp av ChatGPT för att reversera ljudet och filtrera bort piptonen så gott det gick.
Rösten läste upp bokstäver, och vid första försöket tolkade jag sekvensen som IMKDMW2GJFJUQXJA. En Base32-dekodning av den strängen gav resultatet C\x146[FISH], vilket tydde på att jag var på rätt spår.
💡 Tips: Jag visste inte från början att strängen var Base32-kodad, men när jag testade den i CyberChef föreslog verktyget att jag skulle testa just det formatet.
Efter att ha lyssnat igen kom jag fram till strängen INKEMW2GJFJUQXJA, och då blev resultatet CTF[FISH].
🏁 Flagga 8 – ctf.txt
Texten i ctf.txt visade sig vara ett påskägg. Det står ”you will not find a complete flag in this text”, men texten innehåller istället instruktioner för hur man bygger en flagga.
Om man följer denna instruktion blir flaggan ctf[a guess].
🏁 Flagga 9 – cert-se_ctf2025.pcap
Jag bestämde mig för att titta närmare på PCAP-filen. Wireshark varnade för att filen kunde vara skadad eller korrupt, därför misstänkte jag att den var manipulerad.
Jag körde verktyget binwalk och noterade en JPEG-bild i slutet av PCAP-filen. Jag använde verktyget ’dd’ för att exportera ut detta segment av filen:
Den sista flaggan höll sig gömd ett bra tag, men jag hade en känsla av att den borde finnas någonstans i nätverkstrafiken.
Efter lite letande upptäckte jag flera små UDP-paket med väldigt lite data i. När jag började titta närmare såg jag att innehållet var Base64-kodad text. Det visade sig vara data från en keylogger.
💡 Tips: När jag hittade det här spåret blev jag så glad att jag gick igenom alla paket, ett efter ett, i Wireshark 😅 Ett betydligt smidigare sätt hade varit att använda verktyget tshark.
I mitten av UDP-strömmen dök flaggan upp: ctf[keylog_over_udp].
Extramaterial
Filen beach.png gäckade mig länge. När jag undersökte rådata hittade jag sekvensen ctf[ följt av 18 byte och sedan ett ]-tecken. I hex ser det ut så här:
Jag försökte länge lista ut om det här var en dold flagga. Jag provade flera olika sätt att dekoda sekvensen, men inget gav något läsbart resultat.
Till slut hittade jag den sista flaggan på en helt annan plats (UDP-strömmen). När jag skickade in mina resultat passade jag på att fråga CERT-SE, som bekräftade att den här strängen bara var en ren slump 😅
Stort tack till CERT-SE för en riktigt rolig och välgjord utmaning. Som vanligt höll den hög kvalite, med lagom mycket variation mellan uppgifterna. Jag ser redan fram emot nästa år!
I förra inlägget, Kom igång med Microsoft 365, satte vi upp grunden för en fungerande Microsoft 365-miljö. Nu är det dags att ta nästa steg – att stärka säkerheten och skydda din organisation mot attacker.
Security Defaults – snabbt och enkelt grundskydd
Security Defaults är en uppsättning förkonfigurerade säkerhetsinställningar som ger dig ett bra grundskydd. När du aktiverar det får du:
Krav på MFA för alla användare – alla måste registrera sig och använda multifaktorautentisering.
Blockering av legacy authentication – gamla inloggningsmetoder som inte stödjer MFA blockeras (t ex IMAP, POP och SMTP).
Skydd av administrativa aktiviteter – användare som utför privilegierade aktiviteter måste använda MFA.
💡 Tips: Security Defaults är en bra lösning för organisationer som inte har möjlighet att själva underhålla Conditional Access-policies. Du får ett starkt grundskydd på bara några minuter, utan att behöva konfigurera egna regler.
Längst ner på sidan hittar du inställningen Manage security defaults.
Klicka på Enable security defaults och välj Save.
💡 Tips: Det kan ta en liten stund innan Security Defaults slår igenom för alla användare.
När Security Defaults inte räcker till
Security Defaults är en bra grund, men det har sina begränsningar. Funktionen är “allt eller inget” – alla användare får samma skyddsfunktioner, och de går inte att anpassa. Ibland behöver man helt enkelt lite mer kontroll.
Vanliga exempel jag har stött på är att man vill:
Kräva MFA för alla användare, men göra undantag för särskilda konton (t.ex. servicekonton)
Endast tillåta inloggningar från säkra, och av organisationen hanterade enheter
Styra åtkomst baserat på plats, t ex tillåta åtkomst från kontoret utan MFA men kräva MFA vid distansinloggning
🛡️ Säkerhetstips: Det sista exemplet är vanligt, men ingenting jag rekommenderar. Bara för att någon sitter på kontoret betyder det inte automatiskt att nätverket är säkert. Jag tycker att man alltid ska använda MFA.
Så här konfigurerar du Conditional Access-policies
Gå till ID Protection > Risk-based Conditional Access.
Klicka på New policy för att skapa en ny policy.
Om du vill ha hjälp att komma igång finns det färdiga mallar för de grundläggande policies som Microsoft rekommenderar. Välj då New policy from template istället.
Konfigurera åtminstone de policies som motsvarar grundskyddet i Security Defaults:
Require multifactor authentication for admins
Require multifactor authentication for all users
Block legacy authentication
Require multifactor authentication for Azure management
⚠️ Varning: Du kan inte ha både Security Defaults och Conditional Access aktiverat samtidigt. Om du vill använda Conditional Access måste du först stänga av Security Defaults.
Säkra administratörskonton
Administratörskonton är angriparnas främsta mål. Om någon får kontroll över ett globalt administratörskonto är det game over. Då kan angriparen ändra inställningar, stänga ute riktiga admins och ta över hela miljön.
Skapa separata administratörskonton – ha aldrig rollen Global Administrator på ett vanligt användarkonto. Använd i stället ett separat konto som bara används för administration.
Tilldela roller efter behov – de flesta behöver inte fulla rättigheter. Använd t ex Exchange Administrator eller Teams Administrator i stället för Global Administrator.
Använd Privileged Identity Management (PIM) – om ni har licenser som inkluderar PIM är detta en riktigt bra säkerhetsfunktion. Med PIM kan du höja dina behörigheterna under en begränsad tid. På så vis kan du jobba med ditt vanliga konto och bara aktivera administrativa roller när det verkligen behövs.
Kräv stark MFA – använd t ex Microsoft Authenticator eller en fysisk säkerhetsnyckel (FIDO2).
Skapa ett ”break glass”-konto – ett särskilt administratörskonto utan MFA eller Conditional Access som bara används i nödfall. Skydda kontot med starkt lösenord, loggning och mycket begränsad åtkomst.
💡 Tips: Microsoft 365 Business Premium inkluderar Entra ID P1, vilket räcker för de flesta scenarion. För funktioner som Privileged Identity Management (PIM) eller Identity Protection behöver du däremot Entra ID P2. Den kan köpas som tilläggslicens och behöver bara tilldelas de administratörer som ska använda dessa funktioner.
Använd Microsoft Secure Score som guide
När de viktigaste säkerhetsinställningarna är på plats är det bra att få en överblick över hur din miljö faktiskt mår. Det är här Microsoft Secure Score kommer in.
Secure Score är ett verktyg som analyserar din Microsoft 365-miljö och ger en poäng baserat på vilka säkerhetsfunktioner du har aktiverat.
