Teknisk guide: punkt for punkt

Eksakt oppskrift for hvert av de tolv punktene vi måler: hva vi ser etter, hvordan du retter det, og hvordan du verifiserer at det er gjort. Kommandoene under kjører på Linux og macOS; på Windows finnes de i WSL eller PowerShell med Resolve-DnsName.

Slik måler vi

Alt måles utenfra, på konfigurasjon serverne deres kringkaster åpent: DNS-oppslag og vanlige nettforespørsler. Ingen systemer berøres, ingenting forseres. Metoden følger den nederlandske tjenesten internet.nl, som drives av blant andre det nederlandske økonomidepartementet og europeiske internettorganisasjoner.

Poengsummen er 100: 60 på e-post og 40 på nettsted. To forbehold verdt å kjenne:

• OCSP-stapling måles, men gir ikke poeng. Flere sertifikatutstedere, blant dem Let's Encrypt, har avviklet OCSP. Da mangler sertifikatet henvisningen stapling trenger, og det er ikke mulig å slå på uansett serverkonfigurasjon. internet.nl behandler det likedan.
• Vi måler ikke e-postserverens eget TLS-oppsett ennå. STARTTLS, chifferpakker og DANE på port 25 er ikke med i poengsummen. internet.nl måler dette, så en virksomhet kan få full pott hos oss og likevel ha noe å rette der.

1. SPF

Hva vi ser etter

En TXT-post på domenet som starter med v=spf1. Vi registrerer kvalifikatoren til slutt: -all (hard avvisning) gir full uttelling, ~all (myk) mindre, ?all nesten ingenting.

Fiks

# Microsoft 365
domene.no.  IN  TXT  "v=spf1 include:spf.protection.outlook.com -all"

# Google Workspace
domene.no.  IN  TXT  "v=spf1 include:_spf.google.com -all"

# Egen e-postserver
domene.no.  IN  TXT  "v=spf1 mx -all"

Har dere flere avsendere, listes de sammen i én post. Det skal finnes nøyaktig én SPF-post per domene; to poster gjør oppslaget ugyldig.

Verifiser

dig +short TXT domene.no | grep spf1

2. DKIM

Hva vi ser etter

Vi prøver de vanligste selektornavnene: selector1, selector2, google, default, mail og noen til. Finner vi ingen, rapporterer vi «ikke funnet via vanlige selektorer», ikke «mangler». Bruker dere et eget selektornavn, kan DKIM være helt i orden selv om vi ikke ser det. internet.nl har samme begrensning.

Fiks

Microsoft 365: aktiver DKIM-signering for domenet, og publiser de to CNAME-postene tjenesten oppgir. De peker fra selector1._domainkey og selector2._domainkey til verdier under <tenant>.onmicrosoft.com. Microsoft roterer nøklene selv når det er satt opp slik.

Google Workspace: generer nøkkel for domenet, publiser den oppgitte TXT-posten på google._domainkey, og slå deretter på signeringen.

Egen server: generer et nøkkelpar, la e-postserveren signere utgående post, og publiser den offentlige nøkkelen:

selektor._domainkey.domene.no.  IN  TXT  "v=DKIM1; k=rsa; p=<offentlig nøkkel>"

Verifiser

dig +short TXT selector1._domainkey.domene.no
dig +short TXT google._domainkey.domene.no

3. DMARC

Hva vi ser etter

TXT-post på _dmarc.domene.no. Vi leser p (policy), sp (subdomenepolicy) og om rua er satt.

Fiks

# Steg 1: overvåk (endrer ingenting for posten din)
_dmarc.domene.no.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@domene.no"

# Steg 2: etter at rapportene er gjennomgått
_dmarc.domene.no.  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@domene.no"

# Steg 3: full beskyttelse
_dmarc.domene.no.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@domene.no"

Om sp

Utelater du sp, arver subdomenene p automatisk (RFC 7489 § 6.3). Det er fullgodt, og vi trekker ikke for det. Derimot er sp=none ved siden av et strengt p en reell svekkelse: hovedomenet er beskyttet mens alle subdomener er åpne. Det gir ikke uttelling hos oss, og vi viser det eksplisitt på enhetssiden.

Verifiser

dig +short TXT _dmarc.domene.no

4. MTA-STS

Hva vi ser etter

TXT-post på _mta-sts.domene.no, og en policy-fil som faktisk kan hentes. enforce gir full uttelling, testing halv.

Fiks

To deler. Først DNS-posten, der id må endres hver gang policyen endres:

_mta-sts.domene.no.  IN  TXT  "v=STSv1; id=20260724120000Z"

Så policy-filen, som må serveres over https fra vertsnavnet mta-sts.domene.no på stien /.well-known/mta-sts.txt, med et gyldig sertifikat for det navnet:

version: STSv1
mode: testing
mx: mx1.domene.no
mx: mx2.domene.no
max_age: 604800

Alle MX-verter må listes. Mangler én, vil post via den bli avvist når dere går til enforce. Kjør testing til TLS-RPT-rapportene (neste punkt) er rene, og bytt så mode til enforce.

Verifiser

dig +short TXT _mta-sts.domene.no
curl -s https://mta-sts.domene.no/.well-known/mta-sts.txt

5. TLS-RPT

Hva vi ser etter

TXT-post på _smtp._tls.domene.no med v=TLSRPTv1.

Fiks

_smtp._tls.domene.no.  IN  TXT  "v=TLSRPTv1; rua=mailto:tlsrpt@domene.no"

Sett denne opp før MTA-STS går i enforce. Rapportene er den eneste måten å oppdage at en MX-vert mangler i policyen før posten begynner å bli avvist.

Verifiser

dig +short TXT _smtp._tls.domene.no

6. DNSSEC

Hva vi ser etter

At sonen er signert og validerer, altså at oppslaget kommer tilbake med ad-flagget satt fra en validerende resolver.

Fiks

Dette gjøres hos domeneleverandøren, ikke på serveren. De fleste norske registrarer har det som et av- og påvalg. Kjører dere egne navnetjenere, må sonen signeres og DS-posten registreres hos registraren.

Verifiser

dig +dnssec domene.no A | grep -E "^;; flags|RRSIG"
# Se etter «ad» i flaggene og minst én RRSIG

7. HTTPS-omdirigering

Hva vi ser etter

At http://domene.no svarer med en omdirigering til https.

Fiks

# nginx
server {
    listen 80;
    server_name domene.no www.domene.no;
    return 301 https://$host$request_uri;
}

# Apache
<VirtualHost *:80>
    ServerName domene.no
    Redirect permanent / https://domene.no/
</VirtualHost>

# Caddy gjør dette automatisk

Verifiser

curl -sI http://domene.no | head -3

8. HSTS

Hva vi ser etter

Strict-Transport-Security i svarhodene fra https-versjonen.

Fiks

# nginx
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

# Apache
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

# Caddy
header Strict-Transport-Security "max-age=31536000; includeSubDomains"

Verifiser

curl -sI https://domene.no | grep -i strict-transport

9. TLS-versjon

Hva vi ser etter

Hvilke protokollversjoner serveren faktisk godtar. TLS 1.0 og 1.1 trekker. Svarer ikke nettstedet i det hele tatt, viser vi en nøytral strek, ikke en hake, siden vi da ikke har målt noe.

Fiks

# nginx
ssl_protocols TLSv1.2 TLSv1.3;

# Apache
SSLProtocol -all +TLSv1.2 +TLSv1.3

# Caddy bruker kun moderne versjoner som standard

Verifiser

# Skal FEILE hvis 1.0 er avskrudd:
openssl s_client -connect domene.no:443 -tls1 </dev/null

# Skal lykkes:
openssl s_client -connect domene.no:443 -tls1_3 </dev/null

10. Sertifikat

Hva vi ser etter

At sertifikatet validerer mot en anerkjent utsteder og gjelder navnet vi ber om. Merk: vi måler domenet slik det står i vår domeneliste, altså som regel uten www.

Fiks

# Let's Encrypt via certbot, med BEGGE navn
sudo certbot --nginx -d domene.no -d www.domene.no

# Utvide et eksisterende sertifikat med et navn som mangler
sudo certbot --nginx --expand -d www.domene.no -d domene.no

Verifiser

# Hvilke navn dekker sertifikatet?
echo | openssl s_client -connect domene.no:443 -servername domene.no 2>/dev/null \
  | openssl x509 -noout -subject -ext subjectAltName

# Validerer det for navnet uten www?
curl -sI https://domene.no | head -1

11. Sikkerhetsheadere

Hva vi ser etter

Fire headere: Content-Security-Policy, X-Content-Type-Options, Referrer-Policy og X-Frame-Options. Tre av fire regnes som bestått.

Fiks

# nginx
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Content-Security-Policy "default-src 'self'" always;

De tre første kan settes uten risiko. Content-Security-Policy krever derimot testing: en for streng policy blokkerer nettstedets egne skript og stilark. Start med Content-Security-Policy-Report-Only, se hva som ville blitt blokkert, og skru den skarp først når loggen er ren.

Verifiser

curl -sI https://domene.no | grep -iE "content-security|x-content-type|referrer-policy|x-frame"

12. IPv6

Hva vi ser etter

At det finnes en AAAA-post for nettstedet. Vi måler tilstedeværelse, ikke nåbarhet.

Fiks

domene.no.  IN  AAAA  2001:db8::1

Krever at leverandøren tilbyr IPv6 og at serveren lytter på adressen. Publiser aldri en AAAA-post før tjenesten faktisk svarer på den: da blir nettstedet utilgjengelig for alle som har IPv6, mens det ser helt friskt ut for dere som ikke har det.

Verifiser

dig +short AAAA domene.no
curl -6 -sI https://domene.no | head -1

Vanlige feller vi faktisk har sett

Alle disse er reelle funn fra målingen av 1365 virksomheter, ikke tenkte eksempler:

• Sertifikat kun for www. Beskrevet over. Gir toppkarakter i en vanlig test og advarsel for alle som skriver adressen uten www.
• sp=none ved siden av p=reject. Hovedomenet er beskyttet, alle subdomener er vidåpne. Utelat sp heller enn å sette den til none.
• Ny protokoll på uten å skru av den gamle. Flere har slått på TLS 1.2 og 1.3, men latt 1.0 og 1.1 stå aktive ved siden av. Da er svakheten fortsatt der.
• MTA-STS som står i «testing» for alltid. Testing-modus håndhever ingenting. Den er et mellomsteg, ikke et mål.
• Postmottak som er lagt ned uten at DNS er ryddet. Flere virksomheter tar fortsatt imot post på adresser ingen leser.
• DKIM med eget selektornavn. Ikke en feil, men grunnen til at vi kan rapportere «ikke funnet» på et oppsett som virker. Skriv til oss, så retter vi.

← Utgaven uten fagspråk For ledere som skal bestille jobben, og for innbyggere som vil forstå hva svindelen går ut på. Inneholder en ferdig bestillingstekst til leverandøren.

Kilder og videre lesning

1. internet.nl, metoden målingen bygger på — internet.nl
2. Nasjonal sikkerhetsmyndighet, «Grunnleggende tiltak for sikring av e-post» — nsm.no
3. RFC 7489, DMARC (subdomenepolicy i § 6.3) — rfc-editor.org
4. RFC 8461, MTA-STS — rfc-editor.org
5. RFC 6797, HSTS — rfc-editor.org