Första körningen av Lynis på en färsk VPS ger vanligen omkring 60 och en lång lista rekommendationer där det är oklart var man ska börja. Den goda nyheten: 80–85 nås på en kväll, och det mesta på vägen dit är inte kosmetika utan sådant som faktiskt behövs. Den dåliga: de sista femton punkterna går inte att ta på en hyrd virtuell maskin, och det är ingen idé att jaga dem.

Vad indexet visar och vad det inte visar

Hardening index är förhållandet mellan godkända tester och det totala antalet, med vikter — inte en procentsats för hur säker maskinen är. Lynis kör omkring trehundra tester och ger två olika listor: warnings, som ser ut som verkliga problem, och suggestions, som är möjliga förbättringar. Börja alltid med warnings; de brukar vara ett fåtal.

Hundra poäng finns inte: en del rekommendationer kräver beslut som fattas när systemet installeras (egna partitioner för /home, /tmp och /var), en del kräver åtkomst till bootloadern som en VPS inte har, och en del motsäger varandra. Att jämföra sitt index med någon annans är också meningslöst: Lynis drar poäng för det som körs på maskinen. Varje igångsatt tjänst är ännu en öppen port, en egen konfiguration och ett tiotal nya rekommendationer, så höga värden ses oftast där ingenting utom SSH körs. För en arbetande server med sajt, databas och e-post är 85 ett bra resultat.

Kör som root

sudo lynis audit system

Utan sudo hoppar Lynis över alla tester som behöver systemfiler och visar ett för lågt index — inte för att servern är dålig, utan för att kontrollerna inte gick att göra. Rapporten hamnar i /var/log/lynis-report.dat, den läsbara loggen i /var/log/lynis.log.

Varje rad i utskriften börjar med ett testnamn i stil med SSH-7408 eller KRNL-6000. Utifrån den identifieraren hittar du både förklaringen och sättet att stänga av testet — lär dig formen, allt annat kretsar kring den.

Det som ger effekt

SSH (SSH-7408). Det tyngsta blocket: ett enda test kontrollerar ett tiotal parametrar. Redigera inte hela sshd_config, lägg en egen fil — då skriver paketuppdateringen inte över något:

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öre omladdningen är obligatoriskt: ett fel i konfigurationen med en levande session lämnar dig utanför. Och innan du sätter PasswordAuthentication no — kontrollera från en andra öppen terminal att nyckeln verkligen fungerar.

Kärnparametrar (KRNL-6000). Testet kontrollerar ett tjugotal sysctl-värden. En fil för 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

Verktyg som saknas. En stor del av alla suggestions är helt enkelt ”installera det som inte finns”: auditd (logg över systemhändelser), aide (filintegritet), debsums (paketintegritet), unattended-upgrades (automatiska säkerhetsuppdateringar), sysstat och acct (processredovisning), en antivirusskanner. Vart och ett stänger en eller två rekommendationer, men skälet att installera dem är inte poängen utan att du utan dem inte kan rekonstruera någonting efter en incident.

Småsaker med bra utbyte. umask 027 i /etc/login.defs; lösenordens livslängd på samma ställe; bannrar i /etc/issue och /etc/issue.net; kompilatorer tillgängliga bara för root (chmod 700 /usr/bin/gcc). Om bannrarna ska sägas ärligt: de påverkar inte säkerheten alls, de är en juridisk formalitet — men de ger poäng.

En fallgrop med login.defs

Att ändra umask med sed och radersättning lämnar ofta flera UMASK-rader i filen samtidigt. Då räknar Lynis inte värdet, och testet AUTH-9328 förblir rött trots att inställningen ser gjord ut. Kontrollera efteråt:

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

Det ska stå exakt en. Detsamma gäller alla andra parametrar i den filen.

Falska larm och hur man tystar dem rätt

Vissa varningar gäller inte din server över huvud taget. Ett verkligt exempel: på en VPS hos en stor hostingleverantör rapporterar testet PKGS-7388 att säkerhetsförrådet inte hittas — helt enkelt för att förråden är beskrivna i deb822-format med en hänvisning till en spegelfil, medan Lynis letar efter den gamla raden. Säkerhetsuppdateringar kommer samtidigt in som de ska.

Sådant ska tystas med en profil, inte genom att radera rader ur rapporten. Profilfiler har filändelsen .prf (inte .prof — där är det lätt att förlora en halvtimme), och egna regler skrivs i /etc/lynis/custom.prf:

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

En regel gäller: bredvid varje rad ska stå en kommentar om varför testet hoppas över. Om ett halvår minns du inte om det är avstängt för att det inte är tillämpligt eller för att du inte orkade fixa det — och skillnaden mellan de två fallen är hela poängen.

Vad man inte ska göra

Jaga inte siffran. Indexet är enkelt att skruva upp genom att stänga av obekväma tester, och det är det enda sättet att komma över en viss nivå — men servern blir inte säkrare av det. Det nyttiga är något annat: notera ditt värde och följ förändringarna. Ett index som fallit efter en uppdatering eller efter någon annans redigering är en långt mer värdefull signal än det absoluta talet.

Just därför är det meningsfullt att köra Lynis enligt schema och spara rapporterna, så att det finns något att jämföra med. Hur det ser ut samlat på en sida visar demonstrationen nedan: index, listan över warnings med testnamn och det som ändrats sedan förra körningen.