Første kjøring av Lynis på en fersk VPS gir som regel rundt 60 og en lang liste anbefalinger der det er uklart hvor man skal begynne. Den gode nyheten: 80–85 nås på én kveld, og det meste på veien dit er ikke kosmetikk, men ting som faktisk trengs. Den dårlige: de siste femten punktene er umulige å ta på en leid virtuell maskin, og det er ingen grunn til å jage dem.

Hva indeksen viser og hva den ikke viser

Hardening index er forholdet mellom beståtte tester og det totale antallet, med vekting — ikke en prosentandel for hvor sikker maskinen er. Lynis kjører rundt tre hundre tester og gir to ulike lister: warnings, som ser ut som reelle problemer, og suggestions, som er mulige forbedringer. Begynn alltid med warnings; de er som regel få.

Hundre poeng finnes ikke: noen anbefalinger krever valg som tas når systemet installeres (egne partisjoner for /home, /tmp og /var), noen krever tilgang til oppstartslasteren som en VPS ikke har, og noen motsier hverandre. Å sammenligne sin indeks med andres er også nytteløst: Lynis trekker poeng for det som kjører på maskinen. Hver tjeneste som er i drift er enda en åpen port, en egen konfigurasjon og et titalls nye anbefalinger, så høye verdier ses oftest der ingenting annet enn SSH kjører. For en server i drift med nettsted, database og e-post er 85 et godt resultat.

Kjør som root

sudo lynis audit system

Uten sudo hopper Lynis over alle tester som trenger systemfiler, og viser en for lav indeks — ikke fordi serveren er dårlig, men fordi kontrollene ikke lot seg gjøre. Rapporten havner i /var/log/lynis-report.dat, den lesbare loggen i /var/log/lynis.log.

Hver linje i utskriften begynner med et testnavn av typen SSH-7408 eller KRNL-6000. Ut fra den identifikatoren finner du både forklaringen og måten å slå testen av på — lær deg formen, alt annet dreier seg om den.

Det som gir effekt

SSH (SSH-7408). Den tyngste blokken: én enkelt test kontrollerer et titalls parametere. Ikke rediger hele sshd_config, legg en egen fil — da overskriver ikke pakkeoppdateringen noe:

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 omlastingen er obligatorisk: en feil i konfigurasjonen med en levende økt etterlater deg utenfor. Og før du setter PasswordAuthentication no — kontroller fra en annen åpen terminal at nøkkelen virkelig fungerer.

Kjerneparametere (KRNL-6000). Testen kontrollerer et tjuetalls sysctl-verdier. En fil for 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

Verktøy som mangler. En stor del av alle suggestions er rett og slett «installer det som ikke finnes»: auditd (logg over systemhendelser), aide (filintegritet), debsums (pakkeintegritet), unattended-upgrades (automatiske sikkerhetsoppdateringer), sysstat og acct (prosessregnskap), en antivirusskanner. Hvert av dem lukker én eller to anbefalinger, men grunnen til å installere dem er ikke poengene, men at du uten dem ikke kan rekonstruere noe etter en hendelse.

Småting med godt utbytte. umask 027 i /etc/login.defs; passordenes levetid samme sted; bannere i /etc/issue og /etc/issue.net; kompilatorer tilgjengelige bare for root (chmod 700 /usr/bin/gcc). Om bannerne skal det sies ærlig: de påvirker ikke sikkerheten i det hele tatt, de er en juridisk formalitet — men de gir poeng.

En felle med login.defs

Å endre umask med sed og linjeerstatning etterlater ofte flere UMASK-linjer i filen samtidig. Da regner ikke Lynis verdien, og testen AUTH-9328 forblir rød selv om innstillingen ser gjort ut. Kontroller etterpå:

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

Det skal stå nøyaktig én. Det samme gjelder alle andre parametere i den filen.

Falske utslag og hvordan du demper dem riktig

Enkelte advarsler gjelder ikke serveren din i det hele tatt. Et virkelig eksempel: på en VPS hos en stor hostingleverandør melder testen PKGS-7388 at sikkerhetsarkivet ikke finnes — rett og slett fordi arkivene er beskrevet i deb822-format med en henvisning til en speilfil, mens Lynis leter etter den gamle linjen. Sikkerhetsoppdateringene kommer samtidig inn som de skal.

Slikt skal dempes med en profil, ikke ved å slette linjer fra rapporten. Profilfiler har filendelsen .prf (ikke .prof — der er det lett å miste en halvtime), og egne regler skrives i /etc/lynis/custom.prf:

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

Én regel gjelder: ved siden av hver linje skal det stå en kommentar om hvorfor testen hoppes over. Om et halvt år husker du ikke om den er slått av fordi den ikke er relevant, eller fordi du ikke orket å fikse det — og forskjellen mellom de to tilfellene er hele poenget.

Hva du ikke skal gjøre

Ikke jag tallet. Indeksen er lett å skru opp ved å slå av ubekvemme tester, og det er den eneste måten å komme over et visst nivå på — men serveren blir ikke sikrere av det. Det nyttige er noe annet: noter verdien din og følg endringene. En indeks som har falt etter en oppdatering eller etter noen andres redigering, er et langt mer verdifullt signal enn det absolutte tallet.

Nettopp derfor er det fornuftig å kjøre Lynis etter en plan og lagre rapportene, slik at det finnes noe å sammenligne med. Hvordan det ser ut samlet på én side, viser demonstrasjonen nedenfor: indeks, listen over warnings med testnavn og det som er endret siden forrige kjøring.