Teknisk Audit

Linux‑servere: fjernlogin, rettigheder og pakker

Linux-servere: fjernlogin, rettigheder og pakker

I et miljø, der ellers kører Windows, står Linux-serverne ofte for sig selv. De er sat op til én opgave, af én person, og bliver ikke ramt af de politikker, der styrer resten. Gennemgangen læser dem derfor direkte: konfigurationsfilerne, de åbne porte, de installerede pakker og opsætningen af fjernlogin.

Ingen af de læste kilder har talt op, hvor mange fund Linux-servere giver. Grunden til, at de let bliver overset, er derimod enkel: Ingen central kontrol rammer dem.

Hvad NIST siger, der læses

Afsnit 3.4 i NIST SP 800-115 fra 2008 handler om at gennemgå konfigurationer. Blandt de filer, der kan gennemgås, nævner NIST Unix-konfigurationsfiler som dem under /etc. Gennemgangen afslører ifølge NIST unødvendige tjenester og programmer, forkerte konto- og passwordindstillinger og forkerte indstillinger for logning og backup. NIST noterer også, at visse indstillinger kun kan ses med root-rettigheder.

Det giver en enkel arbejdsdeling. Driften trækker filerne og output fra kommandoerne med de nødvendige rettigheder, og den, der gennemgår, læser dem.

Åbne porte

Canonical skriver i Ubuntus sikkerhedsdokumentation, at unødvendigt åbne porte øger angrebsfladen. Kommandoen ss -utln viser de TCP- og UDP-porte, der lytter. Kontrollen er at gå listen igennem og spørge, hvilken tjeneste der står bag hver port, og om den skal være der.

Typiske fund er tjenester, der blev installeret som en del af en pakke og aldrig slået fra, og administrationsflader, der lytter på alle adresser i stedet for kun den interne. Listen kan lægges ved siden af den lokale firewalls regler. Den lokale firewall er beskrevet i den lokale firewall på klienter og servere.

Pakker

Canonical anbefaler at starte med den mindste standardinstallation og tilføje pakker efter behov. Manuelt installerede pakker, der ikke bruges længere, bør fjernes, men man skal være varsom med standardpakkerne. Canonical advarer mod at installere pakker fra ukendte kilder, fordi en pakke kan køre vilkårlig kode som root under installationen.

Kontrollen har tre dele:

  • En liste over installerede pakker, gerne delt i dem, der kom med systemet, og dem, der er tilføjet.
  • En liste over de pakkekilder, serveren henter fra, så kilder uden for distributionen kan ses.
  • Status for opdateringer, så pakker med kendte rettelser, der ikke er installeret, kan findes.

En pakkekilde, ingen kan forklare, er et fund i sig selv.

Fjernlogin

Canonicals side om OpenSSH beskriver nøglebaseret login. Den siger, at ændringer i /etc/ssh/sshd_config bør kontrolleres, før tjenesten genstartes, og at rettighederne på filen authorized_keys skal være sådan, at kun brugeren selv kan skrive i den.

Den læste side behandler ikke login som root over SSH eller login med password. Vi giver derfor ingen anbefaling om dem her. Gennemgangen kan alligevel læse indstillingerne og skrive dem ned, så I selv kan holde dem op imod den målestok, I har valgt.

To spørgsmål giver ofte fund:

  • Hvilke nøgler står i authorized_keys for hver bruger, og ved I, hvem der ejer dem?
  • Er rettighederne på nøglefilerne og mapperne sat, så andre ikke kan skrive i dem?

Nøgler fra tidligere medarbejdere eller leverandører, der ikke er fjernet, er den samme slags fund som en konto, der ikke er lukket. Kontrollen af inaktive konti står i inaktive og forældreløse konti.

Rettigheder

Det sidste område er, hvem der kan blive root, og hvordan. Det er almindelig praksis at læse, hvilke brugere og grupper der må køre kommandoer med forhøjede rettigheder, og om det er begrænset til bestemte kommandoer. Det svarer til opgørelsen af lokale administratorer på Windows.

Logning og backup

NIST nævner forkerte indstillinger for logning og backup blandt det, en konfigurationsgennemgang afslører. På en Linux-server betyder det to spørgsmål. Sendes loggen fra serveren til den centrale opsamling, eller bliver den liggende lokalt? Og er serveren med i backuppen, med de mapper, hvor data og konfiguration faktisk ligger?

Begge dele er ofte sat op, da serveren blev bygget, og ikke set på siden. En server, der er flyttet eller har fået ny opgave, kan stå uden for begge. Kontrollen er at lægge listen over Linux-servere ved siden af logopsamlingens kilder og backupjobbene og se, hvilke der mangler.

En målestok

Canonical beskriver Ubuntu Security Guide, som kan revidere et system mod CIS Level 1 og 2 og mod DISA-STIG og lave en rapport. Værktøjet forudsætter et abonnement. For andre distributioner har vi ikke læst producentens hærdningsvejledning. Har I et blandet miljø, er det et valg, hvilken målestok I vil bruge, og valget bør skrives ned.

Hvad det kræver, og hvad det koster at lade være

Det kræver root-adgang til at trække filerne og output, en liste over serverne og en person, der kan forklare, hvad hver server bruges til. Gennemgangen af en enkelt server er ikke tung. Det tunge er at finde alle serverne.

Uden kontrollen bliver Linux-serverne det sted, hvor gamle nøgler, ukendte pakkekilder og åbne administrationsflader overlever. De ses ikke i Windows-rapporterne, og ingen har ansvaret for at se efter.

Det skal I lade være med

  • At lade nøgler ligge efter fratrædelser · gennemgå authorized_keys på samme tidspunkt som kontolukningen.
  • At tilføje pakkekilder uden at skrive hvorfor · en ukendt kilde kan køre kode som root.
  • At genstarte SSH-tjenesten uden at kontrollere ændringen · I risikerer at lukke jer selv ude.

Det skal gennemgangen kunne vise

  • ☐ En liste over Linux-servere med formål og ejer.
  • ☐ Åbne porte pr. server med tjenesten bag hver.
  • ☐ Installerede pakker og pakkekilder.
  • ☐ Nøgler i authorized_keys med ejer.
  • ☐ Brugere og grupper med forhøjede rettigheder.

Kilder

Senest gennemgået: november 2026.

Næste skridt

Kør ss -utln på jeres Linux-servere, og skriv tjenesten bag hver åben port ved siden af.

Læs også: Udtræk med script og API · Opdateringsniveau

→ Kontakt · Tlf. 70 13 63 23 · Teknisk sikkerhedsgennemgang hos Nielco IT

Skrevet af John Nielsen, indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Om John Nielsen · LinkedIn

John Nielsen, Nielco IT

Skal jeres opsætning gennemgås?

Skriv kort, hvilke dele af miljøet det drejer sig om, og hvad der sætter det i gang. Så vender jeg tilbage. Gennemgangen er uvildig og uafhængig, og Nielco IT har ingen forhandleraftaler.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.