Gå til indhold
atlas

Hærdning (hardening)

Også kendt som: sikker konfiguration

At gøre et system sværere at angribe ved at slå det unødvendige fra og ændre usikre standardindstillinger.

Kladde - dette opslag er endnu ikke gennemgået.

Formelt

Praksis, hvor man mindsker antallet af veje ind i et system ved at fjerne overflødig software og tjenester, lukke unødvendige porte, skifte standardadgangskoder og anvende en nedskrevet sikker opsætning, ofte hentet fra en offentlig vejledning.

Forklaret enkelt

Som at flytte ind i et nyt hus og skifte låsene, mure en dør til, man aldrig bruger, og fjerne reservenøglen under måtten.

I praksis

Før et ministeriums nye webserver går i drift, fjerner IT-driften eksempelsiderne, slår fildeling udefra fra, skifter administratorens standardadgangskode og tjekker opsætningen mod en CIS-vejledning.

Hvorfor det betyder noget

Systemer leveres ofte sat op til at være nemme frem for sikre, og angribere kender standardindstillingerne godt; hver unødvendig tjeneste, der kører, er endnu en vej ind.

Sådan kommer du i gang

De typiske trin i rækkefølge. Tilpas dem til jeres organisation.

  1. Placér ansvaret for sikker konfiguration, og vælg en baseline pr. platform, fx en CIS Benchmark Level 1-profil eller Microsofts sikkerhedsbaselines.
  2. Hold en oversigt over servere, klienter, netværksudstyr og cloudtjenester, og notér, hvilken baseline der gælder for hver.
  3. Tilpas baselinen til systemets rolle ved at fjerne ubrugt software, tjenester, porte og eksempelindhold, og skift alle standardadgangskoder.
  4. Test baselinen på en pilotgruppe før bred udrulning, og registrér hver indstilling, der ikke kan anvendes, som en undtagelse med en risikoejer og en udløbsdato.
  5. Udrul baselinen som kode via Group Policy, Intune, Ansible eller lignende, så nye systemer er hærdede fra første dag.
  6. Tillad kun godkendte applikationer på klienterne med en positivliste, og begræns scriptværktøjer som PowerShell, hvor det er muligt.
  7. Scan systemerne mod baselinen mindst en gang om måneden med et værktøj som CIS-CAT eller OpenSCAP, og ret afvigelser.
  8. Gennemgå baselines, når der kommer en ny benchmarkversion, en ny version af styresystemet eller en større hændelse, og opdatér undtagelseslisten.

Typiske faldgruber

  • At hærde en server manuelt én gang og lade den glide tilbage, efterhånden som administratorer ændrer indstillinger.
  • At rulle en stram profil ud i produktion uden test, så applikationer går i stykker, og forretningen bliver skeptisk over for hærdning.
  • At lade standardadgangskoder og administrationsgrænseflader blive på netværksudstyr, printere og appliances, der falder uden for baselinen.

Gode vejledninger

Teknisk uddybning

Hærdning er reduktion af angrebsfladen gennem konfiguration: hver lyttende tjeneste, aktiveret protokol, installeret pakke, standardkonto og lempelig indstilling er et muligt indgangs- eller eskaleringspunkt, så baseline fjerner eller begrænser alt, systemets rolle ikke kræver. Arbejdet styres normalt af en offentliggjort benchmark frem for lokalt opfundne regler. De vigtigste kilder er CIS Benchmarks (konsensusvejledninger pr. produkt med Level 1-profiler, der er tænkt som bredt sikre, og Level 2-profiler til miljøer med højere sikkerhedskrav, som kan bryde funktionalitet), de amerikanske DISA Security Technical Implementation Guides (STIG'er), leverandørbaselines som Microsoft Security Compliance Toolkit og NIST's National Checklist Program beskrevet i SP 800-70. SP 800-123 er stadig NIST's generelle vejledning i serverhærdning, om end den er ældre.

Typiske punkter på Windows: slå SMBv1, LLMNR og NetBIOS-navneopslag fra (bruges til relay af legitimationsoplysninger), kræv SMB- og LDAP-signering, begræns NTLM, randomisér lokale administratoradgangskoder med LAPS, aktivér Credential Guard og attack surface reduction-regler, og begræns PowerShell til constrained language mode, hvor der er applikationskontrol. Typiske punkter på Linux: slå root-login og adgangskodeautentificering fra i sshd, fjern compilere og ubrugte dæmoner fra produktionsservere, sæt kerneparametre med sysctl (fx begrænsning af ptrace og uprivilegeret BPF), montér /tmp med noexec, og håndhæv SELinux eller AppArmor. For containere og Kubernetes: kør som ikke-root med skrivebeskyttet rodfilsystem, fjern Linux capabilities, anvend en seccomp-profil, forbyd privilegerede pods og hostPath-monteringer, og håndhæv Kubernetes Pod Security Standards (privileged, baseline, restricted) på namespace-niveau.

Maskinlæsbare formater gør baselines reviderbare: SCAP samler XCCDF-tjeklister og OVAL-tjek, og værktøjer som OpenSCAP, CIS-CAT eller cloud security posture management scorer systemer op imod dem. Den praktiske udfordring er drift - håndrettede servere glider tilbage, efterhånden som administratorer ændrer indstillinger - så modne organisationer udtrykker baseline som kode (Group Policy, Ansible, DSC, Terraform-politikker, admission controllers) og måler overholdelsen løbende. Hver afvigelse bør være en dokumenteret undtagelse med en risikoejer, fordi visse hærdningspunkter bryder ældre applikationer.

Hærdning er noget andet end patching: patching retter fejl i kode, der skal køre, mens hærdning fjerner eller begrænser kode og indstillinger, der ikke behøver at være eksponeret. CIS Controls v8 Control 4 (sikker konfiguration af virksomhedens aktiver og software) og ISO/IEC 27002:2022 kontrol 8.9 (konfigurationsstyring), som er ny i 2022-udgaven, er de sædvanlige kontrolankre.

Relationer

Krævet af
CIS-kontroller

Kilder og videre læsning

Standarder og officielle tekster

  • CIS Controls v8 - Control 4 (Secure Configuration of Enterprise Assets and Software) · Center for Internet Security
  • NIST SP 800-123 - Guide to General Server Security · NIST

Hvor dataene kommer fra

Dette opslag er skrevet af en AI ud fra kilderne ovenfor og er endnu ikke gennemgået af et menneske. Brug det som udgangspunkt, og tjek alt vigtigt mod kilderne.

Se gennemgangskøenForeslå en rettelse på GitHubDette begreb som JSON

Test dig selv

Indlæser…

Atlas er i beta.