I et miljø, hvor driften er bygget op om Active Directory, gruppepolitikker og Microsofts opdateringer, kan Linux-serverne stå på siden. De kører webløsninger, databaser, overvågning eller et fagsystem fra en leverandør, og de virker. Det er netop problemet: det, der virker, bliver måske ikke set efter. Svaret på, hvad en test kan finde, hviler derfor ikke nødvendigvis på Linux som sådan, men på, at serverne står uden for de processer, resten af driften følger.
Sådan ender serverne uden for processen
I et Windows-miljø får en ny server en række ting automatisk. Den bliver medlem af domænet, den modtager politikker, den kommer med i opdateringskørslen, og logins styres af de samme konti og grupper som alt andet. En Linux-server får ikke noget af det, medmindre nogen har sat det op med vilje.
Serverne kan komme ind ad tre veje:
- Leverandørens apparat · et færdigt system, der leveres som en virtuel maskine og drives af leverandøren, eller som ingen rigtigt driver.
- Projektserveren · sat op af en udvikler eller en tekniker til et bestemt formål og aldrig overdraget til driften.
- Den faste server · drevet af den ene medarbejder i IT, der kender Linux, efter en praksis, som kun den medarbejder kender.
Alle tre kan være i fin stand. Men ingen af dem er automatisk dækket af de regler, IT-afdelingen har skrevet for sine servere.
Hvad testen afprøver
En intern test ser på Linux-serverne ud fra de samme spørgsmål som på andre servere, men svarene ligner ikke nødvendigvis dem fra Windows-delen.
- Konti og login · hvem der kan logge på, om konti er personlige eller delte, og om der findes standardkonti fra installationen.
- Rettigheder · hvem der kan blive administrator, og om rettighederne er snævre eller brede.
- Opdateringer · om styresystemet og de installerede programmer er opdaterede, og om versionen stadig har support. → Servere og styresystemer uden support
- Tjenester · hvilke tjenester der lytter på nettet, og om de alle er nødvendige.
- Gemte oplysninger · adgangskoder og nøgler i filer, scripts og opsætning. → Adgangskoder i scripts og konfigurationsfiler
- Forbindelser · om serveren har adgang videre ind i Windows-miljøet, fx med en tjenestekonto i domænet.
Det sidste punkt kan være det vigtigste. En Linux-server, der har en konto med brede rettigheder i Active Directory, kan blive vejen fra et overset hjørne til hele domænet. → Tjenestekonti
Fundene minder om dem, myndighederne nævner
NSA og CISA har samlet de ti fejlopsætninger, de oftest ser i store organisationers net. Listen omfatter blandt andet standardopsætning af software, utilstrækkelig adskillelse mellem bruger- og administratorrettigheder, mangelfuld opdateringsstyring og dårlig håndtering af loginoplysninger. Ingen af dem er bundet til et bestemt styresystem, og de passer præcist til den Linux-server, der står uden for de faste processer.
Det gør fundene lettere at forklare internt. Det er ikke Linux, der er usikkert. Det er serveren, der ikke følger de regler, resten af miljøet følger.
Kan I se, hvad der skete på serveren?
Et spørgsmål, der måske først bliver stillet efter testen, er, om nogen i driften opdagede testerens aktivitet på Linux-serverne. Hvis svaret er nej, skyldes det ikke nødvendigvis manglende logning på selve serveren. Logningen findes, men den bliver liggende lokalt, hvor ingen læser den, og den kommer ikke med i det overblik, som Windows-miljøets hændelser samles i.
Bed testeren om at oplyse tidspunkter for det, der blev gjort på serverne. Så kan I bagefter sammenholde med jeres egne spor og se, om de var der, og om nogen ville have set dem. Det giver et konkret grundlag for at beslutte, hvilke servere der skal sende deres logning videre, og hvem der skal kigge på den. → Logning under den interne test
Det, IT skal oplyse før testen
Testeren skal vide, at serverne findes, og hvem der har dem.
- Liste over Linux-servere · formål, ejer og om de drives af jer eller en leverandør.
- Leverandørens vilkår · nogle apparater må ikke ændres, og en test kan kræve leverandørens accept.
- Testkonto · skal testen se serverne indefra som en almindelig bruger, skal en konto oprettes.
- Skrøbelige systemer · fx en ældre database, der ikke tåler belastning. → Skrøbelige systemer
Hvis I ikke kender alle Linux-servere, er det i sig selv et resultat. Testen vil sandsynligvis finde nogle af dem, og listen bliver bedre bagefter.
Sådan prioriterer og retter I
Rettelserne handler mindre om enkeltfund og mere om at få serverne ind i processen. Begynd med de servere, der har forbindelse til Active Directory eller til følsomme data, og som kan nås fra brugernes net.
Del arbejdet i tre spor. Det første er de hurtige rettelser: standardkonti fjernes, ubrugte tjenester slås fra, gemte adgangskoder fjernes og skiftes. Det andet er processen: serverne kommer med i opdateringsplanen, får en ejer og en plads i jeres overblik over servere. Det tredje er adgangen: personlige konti i stedet for delte, færre med administratorrettigheder og logning, som sendes et sted hen, hvor nogen ser den. → Hurtige rettelser og større projekter
NIST’s vejledning om generel serversikkerhed beskriver planlægning, opsætning og vedligehold af servere som én sammenhængende proces uden at skelne mellem styresystemer. Det er en god rettesnor, når I skal skrive jeres egen standard for Linux-serverne.
Er serveren et leverandørapparat, kan rettelsen være en sag for leverandøren. Send fundet videre, og bed om en dato.
Det skal I lade være med
- At holde Linux-serverne ude af testen, fordi de “bare virker”. De kan være dem, der er set mindst efter.
- At lade én medarbejder være eneste kilde til viden. Skriv opsætningen ned, så den kan overdrages.
- At rette serveren uden at rette processen. Næste nye server får de samme fejl.
- At glemme tjenestekonti i domænet. Linux-serverens forbindelse til Active Directory er en del af fundet.
- At ændre et leverandørapparat uden aftale. Det kan bryde supporten og give nye problemer.
Hvad kan og ikke kan konkluderes
Testen viser, hvordan de Linux-servere, den kunne nå, var sat op på testtidspunktet, og hvor langt de kunne bruges ind i resten af miljøet. Den siger ikke noget om servere, der ikke blev fundet, eller om de processer, der skal holde serverne i orden fremover. Fravær af fund på én server betyder ikke, at de andre er i samme stand.
Tjekliste til Linux-serverne
- ☐ Er alle Linux-servere listet med formål og ejer?
- ☐ Er de med i opdateringsplanen?
- ☐ Er standardkonti og delte konti fjernet eller begrundet?
- ☐ Er tjenestekonti i domænet gennemgået?
- ☐ Sendes logning til et fælles sted?
- ☐ Er leverandørapparaternes vilkår afklaret?
Kilder
- CISA og NSA: Top Ten Cybersecurity Misconfigurations (AA23-278A): de ti hyppigste fejlopsætninger, bl.a. standardopsætning, manglende adskillelse af bruger- og administratorrettigheder, mangelfuld opdateringsstyring og dårlig håndtering af loginoplysninger.
- NIST SP 800-123: Guide to General Server Security: planlægning, opsætning og vedligehold af servere, der leverer netværkstjenester.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Databaseservere · Virtualiseringsplatformen som testområde · Mac-computere i et Windows-miljø
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
