...

Serverhærdning: Praktiske tips til Linux-servere

Serverhærdning beskytter min Linux-server mod angreb ved at reducere angrebsflader, stramme adgangen og specifikt sikre kritiske komponenter. Jeg er afhængig af Firewallsstærk autentificering, løbende opdateringer og verificerbare politikker for at holde tjenesterne kørende sikkert og data pålidelige.

Centrale punkter

  • Angrebsoverflade Minimér: fjern unødvendige tjenester, porte og pakker
  • Lapper Konsistent: Hold kerne, OS og apps opdateret
  • Adgang kontrol: Mindste rettigheder, sudo, ingen root-login
  • SSH/MFA sikker: nøgler, politikker, timeouts
  • Firewall & overvågning: regler, IDS/IPS, analyse af logfiler

Hvad betyder serverhærdning på Linux?

Jeg forstår serverhærdning som en målrettet reduktion af Angrebsoverflade af et Linux-system gennem streng konfiguration, fjernelse af unødvendige funktioner og aktiveret logning. Jeg slukker for tjenester, der ikke opfylder en opgave, indstiller sikre standardindstillinger og begrænser al adgang. Jeg tjekker netværksstier, systemparametre og filtilladelser, indtil kun det, der rent faktisk er brug for, kører. Jeg hærder kernen via sysctl, aktiverer sikre protokoller og gennemtvinger kryptering af data i transit og i hvile. Jeg dokumenterer alle trin, så ændringer forbliver sporbare, og status kan gentages.

Reducer antallet af angrebspunkter: Tjenester, porte, pakker

Jeg starter med en opgørelse: Hvilke Tjenester Jeg lytter til systemet, hvilke pakker der virkelig er nødvendige, og hvilke porte der skal være åbne. Jeg afinstallerer software, der medfører ressourcer og risici uden nogen fordel, og blokerer standardporte, som ingen bruger. Jeg bruger minimalistiske images, tillader kun hvidlistede porte og adskiller strengt den administrative adgang fra applikationsstierne. Jeg bruger jævnligt værktøjer som ss eller lsof til at tjekke, om der er oprettet nye lyttere, og fjerner konsekvent de gamle. Jeg holder konfigurationsfilerne slanke, så der er færre muligheder for konfigurationsfejl.

Hærdning af kerne og filsystem i detaljer

Jeg sikrer kernen med specifikke sysctl-parametre: Jeg aktiverer reverse path filtering, TCP syncookies, begrænser ICMP, deaktiverer IP forwarding på servere uden routing-opgaver og reducerer angrebsflader som dmesg-output eller kernel address leaks (kptr_restrict). Jeg forbyder unødvendige kernedumps, begrænser ptrace og aktiverer kernelockdown-tilstand, hvor det er muligt. På filsystemniveau adskiller jeg partitioner og indstiller restriktive mount-muligheder: Jeg monterer /tmp, /var/tmp og ofte /var/log med noexec,nosuid,nodev; /home modtager nosuid,nodev; administrative stier som /boot er skrivebeskyttede. Jeg bruger også attributter som immutable til særligt kritiske filer (f.eks. vigtige konfigurationer), indstiller fornuftige umask-standarder og kontrollerer ACL'er, så undtagelser forbliver kontrollerede. På den måde reducerer jeg virkningen af kompromittering betydeligt og bremser angribere.

Afgrødemoduler, filsystemer og enhedsgrænseflader

Jeg forhindrer automatisk indlæsning af unødvendige kernemoduler og blokerer eksotiske filsystemer, som jeg ikke bruger. Jeg sortlister moduler som cramfs, udf eller hfs/hfsplus, hvis de ikke spiller en rolle i mit miljø, og jeg forhindrer USB-masselagring på servere i datacentret. Jeg deaktiverer FireWire/Thunderbolt eller serielle konsoller, hvis de ikke er nødvendige, og dokumenterer undtagelser. Jeg tjekker jævnligt, hvilke moduler der rent faktisk er indlæst, og sammenligner det med target-listen. Jo færre drivere og undersystemer, der er aktive, jo mindre angrebsflade tilbyder jeg for low-level exploits.

Opdaterings- og patch-strategi uden overraskelser

Jeg holder kerne, distribution og applikationer via en fast Patch-strategi og planlægge vedligeholdelsesvinduer med mulighed for tilbagerulning. Jeg bruger staging og tester opdateringer på testsystemer, før jeg ruller dem ud. Jeg bruger uovervågede opgraderinger eller centraliserede løsninger og overvåger, om pakkerne virkelig er blevet opdateret. Jeg dokumenterer afhængigheder, så sikkerhedsrettelser ikke mislykkes på grund af inkompatibilitet, og jeg prioriterer kritiske opdateringer. Jeg uddyber processer med klare ansvarsområder og bruger også Håndtering af patchesfor at spore ændringsstatusser.

Sårbarhedsstyring og løbende testning

Jeg administrerer aktivt sårbarheder: Jeg registrerer aktiver, sammenligner pakkestatusser med CVE-feeds og prioriterer fund i forhold til risiko og eksponering. Jeg planlægger regelmæssige scanninger med værtsbaserede værktøjer og bruger hærdningstjek som CIS/BSI-orienterede profiler. Jeg forankrer OpenSCAP-profiler i byggeprocessen, får rapporter versioneret og sporer afvigelser som tickets med klare deadlines. Jeg kontrollerer pakkeintegritet (signaturer, verifikationsmekanismer) og bruger kun repositories med GPG-verifikation. Jeg vedligeholder en liste over tilladte pakker og repositories, reducerer eksterne kilder til det nødvendige og registrerer begrundede undtagelser. På den måde forebygger jeg risici i forsyningskæden og opdager forældede, sårbare komponenter på et tidligt tidspunkt.

Adgangsrettigheder og kontoadministration

Jeg anvender princippet om mindst mulig Privilegier igennem: Hver person og hvert system får kun præcis de rettigheder, der er brug for. Jeg deaktiverer det direkte root-login, arbejder med sudo og logger alle administrative handlinger. Jeg adskiller servicekonti, indstiller restriktive umask-værdier og kontrollerer regelmæssigt gruppemedlemskaber. Jeg integrerer central autentificering, så jeg kan kontrollere og tilbagekalde autorisationer ét sted. Jeg låser straks inaktive konti og roterer nøgler og adgangskoder med faste intervaller.

Stærk autentificering og SSH-hærdning

Jeg bruger nøgler i stedet for adgangskoder og aktiverer MFA til administrative logins. Jeg sætter PermitRootLogin til no i sshd_config, tillader kun sikre kex og cipher suites og deaktiverer password-godkendelse. Jeg bruger AuthorisedKeysCommand til at administrere SSH-nøgler centralt og forkorte sessionstider via LoginGraceTime og ClientAliveInterval. Jeg øger gennemsigtigheden med detaljerede SSH-logfiler og reagerer på mislykkede forsøg via fail2ban. Jeg begrænser SSH til administrationsnetværk og indstiller port knocking eller single sign-on, hvis det passer til driften.

TLS, service- og protokolhygiejne

Jeg sikrer alle eksternt tilgængelige tjenester med TLS og begrænser mig til moderne protokoller (TLS 1.2/1.3) og robuste cipher suites med Perfect Forward Secrecy. Jeg planlægger livscyklusser for certifikater, automatiserer fornyelser og aktiverer OCSP-hæftning og strenge transportretningslinjer, hvor det er relevant. Jeg fjerner konsekvent usikre ældre protokoller (Telnet, RSH, FTP) eller indkapsler dem til ældre protokoller via sikre tunneler. Jeg indstiller minimal HTTP-header-hærdning, begrænser klartekst-porte og kontrollerer regelmæssigt, om konfigurationer utilsigtet er blevet løsnet. Jeg holder interne management endpoints kun internt tilgængelige og adskiller datakanaler fra kontrolkanaler, så fejlkonfigurationer ikke kompromitterer alle tjenester.

Netværkssikkerhed: Firewall og IDS/IPS

Jeg definerer strenge regler med nftables eller iptables og dokumenterer, hvorfor en Havn kan være åben. Jeg arbejder med default deny, tillader kun nødvendige protokoller og segmenterer netværket i zoner. Jeg sikrer fjernadgang via VPN, før jeg frigiver administrationstjenester, og bruger DNSSEC og TLS, hvor det er muligt. Jeg bruger intrusion detection eller prevention, korrelerer alarmer med systemlogs og definerer klare responsplaner. Jeg opdaterer min viden med kompakt Grundlæggende om firewall så reglerne forbliver slanke og forståelige.

Obligatorisk adgangskontrol: SELinux/AppArmor pragmatisk

Jeg bruger MAC-frameworks, så tjenesterne forbliver begrænsede, selv om en konto eller proces er kompromitteret. Jeg sætter SELinux eller AppArmor til enforcing, starter i permissive/complain mode i følsomme miljøer og lærer rene profiler, før jeg skifter til hard. Jeg administrerer politikker centralt, dokumenterer booleans og undtagelser og tester opdateringer i forhold til profilerne. Jeg indkapsler specifikt kritiske tjenester som f.eks. webservere, databaser eller backup-agenter, så de kun har adgang til de nødvendige stier. På den måde forhindrer jeg laterale bevægelser og reducerer konsekvenserne af forkerte filtilladelser.

Beskyttelse på hardwareniveau og i boot-kæden

Jeg sikrer platformen ved at beskytte UEFI, firmware og fjernstyring med stærke Adgangskoder og deaktiverer unødvendige grænseflader. Jeg aktiverer Secure Boot, kontrollerer bootloaderens integritet og bruger TPM-understøttede funktioner, hvor de er tilgængelige. Jeg bruger fuld diskkryptering med LUKS og sørger for sikker nøglehåndtering. Jeg isolerer out-of-band-adgang, logger brugen af den og begrænser den til betroede administratornetværk. Jeg tjekker regelmæssigt firmwareopdateringer, så kendte sårbarheder ikke fortsætter.

Logning, auditering og overvågning

Jeg indsamler hændelser centralt via rsyslog eller journald og udvider visningen med auditd-Regler for kritiske handlinger. Jeg opretter alarmer for mislykkede logins, uventede processtarter og konfigurationsændringer. Jeg tildeler unikke værtsnavne, så jeg hurtigt kan kortlægge hændelser og korrelere data i en SIEM-løsning. Jeg tester tærskler for at reducere falske positiver og har playbooks, der beskriver reaktioner. Jeg holder øje med opbevaringsperioder, så retsmedicinske analyser fortsat er mulige.

Integritetstjek, basislinjer og tid

Jeg definerer et rent udgangspunkt og sikrer det: Jeg registrerer kontrolsummer for vigtige systemfiler, bruger filintegritetsovervågning og opsætter alarmer for afvigelser. Jeg holder AIDE/sammenlignelige værktøjer opdaterede, låser deres databaser mod manipulation og forsegler særligt kritiske mapper. Jeg synkroniserer systemtiden via sikre tidskilder (f.eks. chrony med autentificering), så logfiler, certifikater og Kerberos fungerer pålideligt. Jeg har en gylden system- og konfigurationsbaseline, som jeg hurtigt kan nulstille kompromitterede systemer med i stedet for møjsommeligt at rydde op i dem.

Automatisering af sikkerhed

Jeg er afhængig af konfigurationsstyring som Ansible, Puppet eller Chef, så jeg kan konsekvent håndhæver de samme sikkerhedsstatusser. Jeg skriver gentagelige playbooks, adskiller variabler rent og tester roller i pipelines. Jeg tjekker regelmæssigt afvigelser og retter dem automatisk, før der opstår risici. Jeg tilføjer kontrolprofiler som f.eks. OpenSCAP-politikker og dokumenterer undtagelser med årsager. Jeg holder hemmeligheder adskilt, bruger vault-løsninger og styrer nøglerotationer som kode.

Hærdning af containere, VM'er og orkestrering

Jeg hærder containere og virtuelle maskiner efter de samme principper: minimale images, ingen unødvendige pakker, ingen root i containere, klare ressourcebegrænsninger via cgroups og namespaces. Jeg bruger seccomp og capability profiles, deaktiverer privilegerede containere og forhindrer host mounts, der ikke er absolut nødvendige. Jeg scanner images før udrulning, signerer artefakter og knytter base-images til definerede, verificerede versioner. I orkestreringer håndhæver jeg netværkspolitikker, secret management og pod-sikkerhedskrav. På hypervisorer holder jeg managementniveauet adskilt fra gæstenetværket og begrænser strengt synligheden af enheder for VM'er.

Retningslinjer, dokumentation og uddannelse

Jeg formulerer en klar sikkerhedsretningslinje, ansvarsfordelingen, Standarder og metrikker er defineret. Jeg har runbooks klar til incident response, patch-processer og adgangsautorisationer. Jeg dokumenterer alle konfigurationsændringer med billetreference, dato og mål. Jeg uddanner regelmæssigt de involverede og tester deres viden ved hjælp af korte øvelser. Jeg bruger også Guide til rodserverfor at få nye kolleger hurtigt i gang.

Hændelsesrespons og kriminalteknik i operationer

Jeg planlægger for nødsituationer: Jeg definerer klare rapporteringskanaler, isolationstrin og beviser. Jeg sikrer flygtige data på et tidligt tidspunkt (netværksforbindelser, processer, hukommelse), har retsmedicinske værktøjer klar og dokumenterer alle foranstaltninger med et tidsstempel. Jeg træffer en bevidst beslutning mellem inddæmning og øjeblikkelig nedlukning, afhængigt af risikoen for tilgængelighed og beviser. Jeg har signerede, pålidelige redningsmedier klar, bruger kun autoriserede værktøjer og respekterer beviskæder. Efter hændelsen foretrækker jeg at genopbygge systemer fra kendte baselines, lære af grundårsagsanalyser og tilpasse hærdning og overvågning med det samme.

Backup, gendannelse og genstart

Jeg planlægger sikkerhedskopier, der er krypterede, offline-kompatible og med definerede Målsætninger for gendannelsestid og datastatus. Jeg tester gendannelser på en realistisk måde og logger varigheden, så jeg kan genkende huller. Jeg opbevarer kopier separat, forhindrer uautoriseret sletning gennem separate identiteter og indstiller uforanderlighed, hvor det er muligt. Jeg sikrer firewall-, IDS- og administrationsværktøjskonfigurationer sammen med applikationsdata. Jeg øver mig regelmæssigt i at genstarte, så jeg ikke mister tid i stressede situationer.

Overholdelse, dokumentation og målinger

Jeg forbinder hærdning med verificerbare mål: Jeg tildeler foranstaltninger til etablerede benchmarks og indsamler automatisk beviser fra CI/CD, konfigurationsstyring og SIEM. Jeg definerer metrikker som f.eks. gennemsnitlig tid til patch, afvigelser fra hærdningsregler, blokerede konti pr. periode eller andel af systemer med MFA. Jeg genererer regelmæssige rapporter til teknologi og ledelse, vurderer risici, sætter korrigerende foranstaltninger på køreplaner og forankrer undtagelser med udløbsdatoer. På den måde skaber jeg gennemsigtighed, prioriterer ressourcer og holder sikkerheden i et bæredygtigt flow.

Tjekliste til hverdagen

Jeg tjekker ugentligt, om der er kommet nye Tjenester kører, og om der er åbne porte, som ingen har brug for. Jeg tjekker alle brugere, grupper og sudo-regler hver måned og blokerer inaktive konti. Jeg bekræfter, at SSH kun accepterer nøgler, at root-login forbliver slået fra, og at MFA er aktiv for administratorer. Jeg sammenligner firewall-regler med target-listen, læser alarmer og log-udtræk og retter straks op på uregelmæssigheder. Jeg kontrollerer, at backups er komplette, og udfører kvartalsvise restore-tests, så jeg har sikkerhed.

Sammenligning af hostingudbydere

Når jeg vælger en udbyder, lægger jeg vægt på sikre standardbilleder, klare SLA og hjælper med hærdning. Jeg tjekker, om firewalls, DDoS-beskyttelse og kryptering er tilgængelige uden ekstra omkostninger. Jeg vurderer valget af operativsystem, kvaliteten af support, og om der er mulighed for administrerede løsninger. Jeg tjekker, hvordan leverandøren håndterer patching, overvågning og hændelser, og om den understøtter revisionsanmodninger. Jeg bruger følgende sammenligning som en guide til at hjælpe mig med at vælge en passende udbyder.

Sted Udbyder Valg af operativsystem Sikkerhedsfunktioner Støtte
1 webhoster.de forskelligartet Omfattende serverhærdning, kryptering, firewall, managed services Premium support 24/7
2 Udbyder X Standard Grundlæggende firewall, regelmæssige opdateringer Standard support
3 Udbyder Y begrænset Grundlæggende beskyttelsesforanstaltninger Support via e-mail

Resumé: Hærdning i praksis

Jeg sikrer Linux-servere effektivt ved at reducere angrebsfladerne, Opdateringer planlægge, strømline adgang og kontrollere netværksstier. Jeg sætter min lid til stærk autentificering, logning med klare alarmer og automatisering, så forholdene forbliver reproducerbare. Jeg dokumenterer alle ændringer, praktiserer gendannelser og holder politikker i live. Jeg gennemgår regelmæssigt resultater, tilpasser foranstaltninger og holder teknologi og viden opdateret. På den måde bevarer jeg kontrollen, reagerer hurtigere på hændelser og holder tjenesterne pålideligt tilgængelige.

Aktuelle artikler