Første kørsel af Lynis på en frisk VPS giver som regel omkring 60 og en lang liste anbefalinger, hvor det er uklart, hvor man skal begynde. Den gode nyhed: 80–85 nås på én aften, og det meste på vejen dertil er ikke kosmetik, men ting der rent faktisk er nødvendige. Den dårlige: de sidste femten punkter er umulige at tage på en lejet virtuel maskine, og der er ingen grund til at jagte dem.

Hvad indekset viser, og hvad det ikke viser

Hardening index er forholdet mellem beståede tests og det samlede antal, med vægtning — ikke en procentsats for, hvor sikker maskinen er. Lynis kører omkring tre hundrede tests og giver to forskellige lister: warnings, som ligner reelle problemer, og suggestions, som er mulige forbedringer. Begynd altid med warnings; de er som regel få.

Hundrede point findes ikke: nogle anbefalinger kræver valg, der træffes, når systemet installeres (egne partitioner til /home, /tmp og /var), nogle kræver adgang til bootloaderen, som en VPS ikke har, og nogle modsiger hinanden. At sammenligne sit indeks med andres er også nytteløst: Lynis trækker point for det, der kører på maskinen. Hver kørende tjeneste er endnu en åben port, en egen konfiguration og et tital nye anbefalinger, så høje værdier ses oftest, hvor intet andet end SSH kører. For en driftsserver med hjemmeside, database og e-mail er 85 et godt resultat.

Kør som root

sudo lynis audit system

Uden sudo springer Lynis alle tests over, der har brug for systemfiler, og viser et for lavt indeks — ikke fordi serveren er dårlig, men fordi kontrollerne ikke kunne udføres. Rapporten havner i /var/log/lynis-report.dat, den læsbare logfil i /var/log/lynis.log.

Hver linje i udskriften begynder med et testnavn af typen SSH-7408 eller KRNL-6000. Ud fra den identifikator finder du både forklaringen og måden at slå testen fra på — lær formen, alt andet drejer sig om den.

Det, der giver effekt

SSH (SSH-7408). Den tungeste blok: en enkelt test kontrollerer et tital parametre. Redigér ikke hele sshd_config, læg en separat fil — så overskriver pakkeopdateringen ingenting:

sudo tee /etc/ssh/sshd_config.d/10-hardening.conf <<'EOF'
PermitRootLogin no
PasswordAuthentication no
MaxAuthTries 3
MaxSessions 2
X11Forwarding no
AllowTcpForwarding no
ClientAliveInterval 300
ClientAliveCountMax 2
LogLevel VERBOSE
TCPKeepAlive no
EOF
sudo sshd -t && sudo systemctl reload ssh

sshd -t før genindlæsningen er obligatorisk: en fejl i konfigurationen med en levende session efterlader dig udenfor. Og før du sætter PasswordAuthentication no — kontrollér fra en anden åben terminal, at nøglen rent faktisk virker.

Kerneparametre (KRNL-6000). Testen kontrollerer et tyvetal sysctl-værdier. En fil til dem:

sudo tee /etc/sysctl.d/99-hardening.conf <<'EOF'
kernel.dmesg_restrict = 1
kernel.kptr_restrict = 2
kernel.sysrq = 0
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.all.log_martians = 1
EOF
sudo sysctl --system

Værktøjer der mangler. En stor del af alle suggestions er ganske enkelt »installér det, der ikke findes«: auditd (logfil over systemhændelser), aide (filintegritet), debsums (pakkeintegritet), unattended-upgrades (automatiske sikkerhedsopdateringer), sysstat og acct (procesregnskab), en antivirusscanner. Hvert af dem lukker én eller to anbefalinger, men grunden til at installere dem er ikke pointene, men at du uden dem ikke kan rekonstruere noget efter en hændelse.

Småting med godt udbytte. umask 027 i /etc/login.defs; adgangskodernes levetid samme sted; bannere i /etc/issue og /etc/issue.net; oversættere tilgængelige kun for root (chmod 700 /usr/bin/gcc). Om bannerne skal det siges ærligt: de påvirker slet ikke sikkerheden, de er en juridisk formalitet — men de giver point.

En faldgrube med login.defs

At ændre umask med sed og linjeerstatning efterlader ofte flere UMASK-linjer i filen på én gang. Så tæller Lynis ikke værdien, og testen AUTH-9328 forbliver rød, selv om indstillingen ser udført ud. Kontrollér bagefter:

grep -c '^UMASK' /etc/login.defs

Der skal stå præcis én. Det samme gælder alle andre parametre i den fil.

Falske udslag og hvordan du dæmper dem rigtigt

Nogle advarsler gælder slet ikke din server. Et virkeligt eksempel: på en VPS hos en stor hostingudbyder melder testen PKGS-7388, at sikkerhedsarkivet ikke findes — ganske enkelt fordi arkiverne er beskrevet i deb822-format med en henvisning til en spejlfil, mens Lynis leder efter den gamle linje. Sikkerhedsopdateringerne kommer samtidig ind, som de skal.

Den slags skal dæmpes med en profil, ikke ved at slette linjer fra rapporten. Profilfiler har filendelsen .prf (ikke .prof — der er det let at miste en halv time), og egne regler skrives i /etc/lynis/custom.prf:

skip-test=PKGS-7388
skip-test=KRNL-5788

Én regel gælder: ved siden af hver linje skal der stå en kommentar om, hvorfor testen springes over. Om et halvt år husker du ikke, om den er slået fra, fordi den ikke er relevant, eller fordi du ikke gad at rette det — og forskellen mellem de to tilfælde er hele pointen.

Hvad man ikke skal gøre

Jagt ikke tallet. Indekset er let at skrue op ved at slå ubelejlige tests fra, og det er den eneste måde at komme over et vist niveau på — men serveren bliver ikke sikrere af det. Det nyttige er noget andet: notér din værdi, og følg ændringerne. Et indeks, der er faldet efter en opdatering eller efter en andens redigering, er et langt mere værdifuldt signal end den absolutte størrelse.

Netop derfor giver det mening at køre Lynis efter en plan og gemme rapporterne, så der er noget at sammenligne med. Hvordan det ser ud samlet på én side, viser demonstrationen nedenfor: indeks, listen over warnings med testnavne og det, der er ændret siden sidste kørsel.