Lynis 3.1 säkerhetsaudit på Linux 2026: Härda enligt CIS Benchmark

Uppdaterad: 16 september 2026

Lynis 3.1 är ett open source-baserat säkerhetsauditverktyg som skannar en Linux-värd mot över 300 kontroller från CIS Benchmarks, STIG, PCI DSS, HIPAA och ISO 27001, poängsätter systemet med ett hardening index från 0–100 och skriver ut konkreta åtgärdsförslag. Verktyget är agentlöst, körs som ett shell-skript utan externa runtime-beroenden och integreras rent i CI/CD. Så, den här guiden visar hur jag kör Lynis 3.1 mot en Ubuntu 24.04-, Debian 13- och RHEL 10-värd, tolkar utdata, mappar kontroller till CIS Ubuntu Benchmark v3.0.0 och åtgärdar de tio vanligaste varningarna.

• Lynis 3.1.4 stöder Linux 6.6 LTS och 6.12 LTS och kör över 300 kontroller mot CIS Benchmark v3.0, STIG och PCI DSS 4.0, utan agent och utan root i skanningsläge.
• Ett hardening index under 70 är en röd flagga på en produktionsvärd; välhärdade RHEL 10-system landar rutinmässigt på 85–92 efter en Ansible-genomgång.
• De tio vanligaste varningarna är oftast: saknad process accounting, USB-storage tillåtet, ingen malware scanner, tomt sysctl-set, otillräcklig auditd-täckning och saknad file integrity monitoring.
• Lynis är kompletterande (inte en ersättning) till OpenSCAP: SCAP mappar formellt till CIS/STIG-strömmar, Lynis levererar snabb heuristisk feedback.
• Kör Lynis i GitLab CI eller GitHub Actions med --cronjob och tröskel för hardening index, så bryts pipelinen om en image regredierar under 80.
• För full CIS-efterlevnad kombinera Lynis rapporter med Ansible-rollen ansible-lockdown/RHEL10-CIS eller dev-sec/linux-baseline.

Vad är Lynis och när ska du använda det?

Lynis är utvecklat av CISOfy och började som en fork av rkhunters-idéer 2007. Version 3.1-serien (aktuell: 3.1.4, släppt februari 2026) är ett rent POSIX-shell-skript på cirka 30 000 rader som läser filer under /etc, /proc, /sys och några utvalda binärer, utan att skriva någonting utanför /var/log/lynis.log och /var/log/lynis-report.dat. Just avsaknaden av runtime-beroenden är det som gör Lynis intressant på minimala kernel-härdade värdar: du behöver ingen Python, ingen Ruby, inget SCAP-runtime och ingen daemon.

Verktyget passar tre distinkta arbetsflöden. Först: on-demand-audit när du tagit över ett arv-system och behöver en snabb bild av härdningsläget. Andra: pre-production baseline där du bakar in Lynis i en gyllene image-pipeline och kräver ett hardening index över en tröskel innan en artefakt släpps. Tredje: continuous compliance där Lynis körs som cronjob varje natt och skickar deltat till din SIEM. Lynis ersätter inte formell SCAP-baserad revision (för DoD- eller FedRAMP-uppdrag behöver du fortfarande OpenSCAP med officiella SSG-strömmar), men det ger snabbare feedback och läser mer distributionsspecifik kontext (Snap-paket, systemd-sockets, unattended-upgrades) än vanilla SCAP-innehåll.

Ärligt talat, en detalj som gör många nybörjare förvirrade: Lynis kör inte som root i basläget. Utan root får du en subset av kontroller (framförallt de som läser /etc/shadow, iptables -L och lsmod hoppas över). För en meningsfull audit vill du köra sudo lynis audit system från en interaktiv session eller lynis audit system --cronjob --quick från cron. Kontrollernas kärnimplementation ligger i /usr/share/lynis/include/. Öppna filerna om du vill förstå exakt vad ett CID (Control ID) faktiskt testar.

Installera Lynis 3.1 på Debian, Ubuntu och RHEL

Jag rekommenderar att installera Lynis från CISOfys officiella APT/DNF-repo snarare än från distributionens paketförråd, eftersom Debian- och EPEL-paketen ofta ligger 6–12 månader efter. På Ubuntu 24.04 LTS och Debian 13 (Trixie) ser installationen ut så här:

# Lägg till CISOfy-repo och GPG-nyckel
curl -fsSL https://packages.cisofy.com/keys/cisofy-software-public.key \
    | sudo gpg --dearmor -o /usr/share/keyrings/cisofy.gpg
echo "deb [signed-by=/usr/share/keyrings/cisofy.gpg] \
    https://packages.cisofy.com/community/lynis/deb/ stable main" \
    | sudo tee /etc/apt/sources.list.d/cisofy-lynis.list
sudo apt update && sudo apt install -y lynis
lynis --version   # verifiera 3.1.4 eller senare

På RHEL 10, Rocky 10 och AlmaLinux 10 använder du DNF-motsvarigheten. CISOfy signerar RPM-paketen med samma nyckel som Debian-paketen och rotcertifikatet är sha256-verifierat:

sudo tee /etc/yum.repos.d/cisofy-lynis.repo >/dev/null <<'EOF'
[lynis]
name=CISOfy Lynis
baseurl=https://packages.cisofy.com/community/lynis/rpm/
enabled=1
gpgcheck=1
gpgkey=https://packages.cisofy.com/keys/cisofy-software-rpms-public.key
EOF
sudo dnf install -y lynis

På systemd-baserade minimalimages där du inte vill dra in paketförråd är statisk klon från GitHub ofta bättre. Du får då en fristående installation utan att förändra pakethanteraren:

sudo git clone --branch 3.1.4 --depth 1 \
    https://github.com/CISOfy/lynis.git /opt/lynis
sudo ln -s /opt/lynis/lynis /usr/local/sbin/lynis

Tolka hardening index och rapportfiler

När du kör sudo lynis audit system skriver Lynis två filer: en loggfil /var/log/lynis.log med varje beslutsteg, och en maskinläsbar rapport /var/log/lynis-report.dat i nyckel=värde-format. Hardening index är en heuristisk poäng där varje suggestion drar ner ett par poäng och varje warning drar ner mer. Formeln är dokumenterad i include/functions. Öppna funktionen DisplayCompletedTest för att se den faktiska viktningen.

På en färsk Ubuntu 24.04 Server-installation med bara openssh-server installerat landar hardening index typiskt på 62–68. Efter att jag kört baseline-Ansible (SSH-härdning, unattended-upgrades, auditd, AppArmor-profiler, fail2ban/CrowdSec, sysctl-hardening, USB-storage-blockering och FIM med AIDE) landar samma värd på 88–92. Målvärdet för produktion är 85+; under 70 är en signal att grundhärdningen saknas.

Rapporten läses enklast med grep eller jq efter att du kört --report-file-formatering. Följande snutt extraherar alla warnings till ett JSON-fragment som du kan strömma in i din SIEM:

sudo lynis audit system --cronjob --quick \
    --report-file /var/log/lynis-report.dat
awk -F'[|=]' '/^warning\[\]=/{print $2}' /var/log/lynis-report.dat \
    | jq -R -s 'split("\n") | map(select(length > 0))' \
    > /var/log/lynis-warnings.json

Varje varning har ett Test-ID (t.ex. SSH-7408, KRNL-6000, AUTH-9262). Sök på ID:t i CISOfys officiella Lynis-kontrollkatalog för att se exakt vilken fil eller sysctl-parameter som utvärderades och vilken remediation som föreslås.

Mappa Lynis-kontroller mot CIS Benchmark v3.0

Lynis är inte formellt certifierat av Center for Internet Security, men majoriteten av CID:erna kartläggs manuellt mot CIS Benchmark-sektioner. För CIS Ubuntu 24.04 LTS Benchmark v3.0.0 ser mappningen ut ungefär så här:

Lynis Test-ID	CIS Benchmark v3.0-sektion	Beskrivning
BOOT-5122	1.4.1 – GRUB-lösenord	Verifierar att bootloader kräver lösenord för menyredigering.
KRNL-5820	1.5.1 – ASLR aktiverat	Kontrollerar kernel.randomize_va_space=2.
USB-1000	1.1.9 – USB-storage inaktiverat	Verifierar modprobe-blacklist för usb-storage.
SSH-7408	5.2.x – SSHD_CONFIG-kontroller	PermitRootLogin, MaxAuthTries, LoginGraceTime, Ciphers.
AUTH-9262	5.4.1 – PAM lösenordskvalitet	Kontrollerar pwquality.conf med minlen ≥14, minclass ≥4.
ACCT-9622	4.1.1.1 – process accounting	Verifierar att psacct/acct är installerat och aktivt.
FILE-6362	6.1.10 – filintegritetsövervakning	Söker efter AIDE, Samhain eller Tripwire.

Den fulla mappningen underhålls av CIS-communityn och kan hämtas som JSON från GitHub. På uppdrag där jag måste bevisa CIS Level 2-efterlevnad kombinerar jag Lynis-utdata med formell SCAP-baserad revision. SCAP ger den auditbara XCCDF-rapporten, Lynis ger snabbare feedback när teamet gör iterativa förändringar.

Lynis vs OpenSCAP vs Ansible-hardening

De tre verktygen löser överlappande men distinkta problem. Lynis är ett audit-verktyg (endast läs). OpenSCAP är ett audit- och remediation-verktyg med formell SCAP-inputspecifikation. Ansible-hardening-roller (dev-sec, ansible-lockdown) är rena remediation-verktyg. På ett moget team använder du alla tre.

Dimension	Lynis 3.1	OpenSCAP 1.4	Ansible-hardening
Typ	Audit	Audit + remediation	Remediation
Formell CIS-certifiering	Nej (community-mappning)	Ja (SCAP Security Guide)	Nej
Runtime-beroenden	POSIX-shell	OpenSCAP + SSG XML	Ansible 2.16+
Rapportformat	.dat, .log, JSON via awk	XCCDF, ARF, HTML	Ansible-fakta
Körtid på Ubuntu 24.04	~45 sekunder	~3 minuter	5–15 minuter
Best för	Snabb baseline	Formell revision	Konvergens av flotta

Min pragmatiska rekommendation: kör Ansible-hardening i din gyllene-image-pipeline, verifiera med Lynis i CI (snabbt, tröskelbrytande) och kör OpenSCAP som veckoveckuppgift på produktionsvärdar för att generera arkivbar XCCDF-rapport till complianceteamet. Vill du fördjupa dig i eBPF-baserad runtime-övervakning som komplement, se min tidigare artikel om eBPF-baserad runtime-säkerhet med Falco och Tetragon.

Automatisera Lynis i GitLab CI och GitHub Actions

Att bara köra Lynis manuellt är att missa poängen. Den verkliga vinsten är automatisk regressionsdetektion. När någon lägger till en ny Ansible-roll eller en Dockerfile-instruktion som sänker hardening index under 80 ska pipelinen brytas innan artefakten publiceras.

Följande GitLab CI-jobb kör Lynis inuti en Ubuntu 24.04-container, parsar rapporten och exit-kodar på tröskel:

lynis-audit:
  stage: security
  image: ubuntu:24.04
  script:
    - apt-get update && apt-get install -y curl gnupg jq
    - curl -fsSL https://packages.cisofy.com/keys/cisofy-software-public.key
        | gpg --dearmor -o /usr/share/keyrings/cisofy.gpg
    - echo "deb [signed-by=/usr/share/keyrings/cisofy.gpg]
        https://packages.cisofy.com/community/lynis/deb/ stable main"
        > /etc/apt/sources.list.d/cisofy.list
    - apt-get update && apt-get install -y lynis
    - lynis audit system --cronjob --quick
        --report-file lynis-report.dat
    - INDEX=$(awk -F= '/^hardening_index=/{print $2}' lynis-report.dat)
    - echo "Hardening index $INDEX"
    - if [ "$INDEX" -lt 80 ]; then
        echo "FAIL - hardening index under tröskel"; exit 1;
      fi
  artifacts:
    paths: [lynis-report.dat]
    expire_in: 30 days

På GitHub Actions blir det motsvarande. Nyckeln är att lagra lynis-report.dat som artifact så att security-teamet kan diffa mellan runs. En bra praxis: baseline-artefakten från main-grenen jämförs med PR-grenens rapport i en compare-jobb som kommenterar PR:n med varje nytt Test-ID som dykt upp. Jag råkade själv ut för en tyst regression där en Ansible-uppdatering avmonterade auditd.rules-filen; utan CI-tröskeln hade det gått genom till produktion.

Fixa de tio vanligaste varningarna

På de flesta Debian- och RHEL-installationer återkommer samma varningar. Här är hur jag åtgärdar dem i produktion.

ACCT-9622: Ingen process accounting

sudo apt install -y acct
sudo systemctl enable --now acct.service

USB-1000: USB-storage tillåtet

echo "blacklist usb-storage" | sudo tee /etc/modprobe.d/no-usb-storage.conf
sudo update-initramfs -u   # Debian/Ubuntu
sudo dracut -f              # RHEL/Fedora

KRNL-6000: Otillräckliga sysctl-parametrar

sudo tee /etc/sysctl.d/99-lynis-hardening.conf >/dev/null <<'EOF'
kernel.dmesg_restrict = 1
kernel.kptr_restrict = 2
kernel.yama.ptrace_scope = 2
kernel.unprivileged_bpf_disabled = 1
net.core.bpf_jit_harden = 2
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.all.log_martians = 1
net.ipv4.tcp_syncookies = 1
net.ipv6.conf.all.accept_ra = 0
fs.suid_dumpable = 0
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
EOF
sudo sysctl --system

De två raderna unprivileged_bpf_disabled=1 och bpf_jit_harden=2 är särskilt viktiga efter CVE-2024-1086 (nftables UAF via eBPF). De blockerar hela klassen av opriviligierade eBPF-attackvägar mot Linux-kärnan.

FILE-6362: Ingen filintegritetsövervakning

sudo apt install -y aide
sudo aideinit
sudo mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db
sudo systemctl enable --now aidecheck.timer

SSH-7408: Osäker SSHD-konfiguration

Se min separata artikel om SSH-härdning med postkvant-kryptografi och FIDO2 för hela härdningsuppsättningen. Miniminivån för att tysta Lynis är: PermitRootLogin no, PasswordAuthentication no, MaxAuthTries 3, LoginGraceTime 30, ClientAliveInterval 300, ClientAliveCountMax 2.

MALW-3280: Ingen malware scanner

På servrar med publik yta installera clamav och kör dagliga scanningar. På minimala kernel-imagar accepterar jag varningen dokumenterat i en /etc/lynis/custom.prf-fil med skip-test=MALW-3280.

Integrera med auditd, SELinux och brandvägg

Lynis-varningen ACCT-9628 pekar på att auditd inte är konfigurerat med tillräckligt bred regeluppsättning. Grundtäckningen bör inkludera watch-regler för /etc/shadow, /etc/sudoers.d/, /etc/ssh/sshd_config och syscall-regler för execve. Se min tidigare artikel auditd på Linux 2026: regler och SIEM-strömning för en färdig regeluppsättning som passerar Lynis-tröskeln utan att drunkna din SIEM i brus.

På RHEL 10-värdar med SELinux i enforcing-läge kommer Lynis rapportera MACF-6234 som passerad, men kontrollera fortfarande att selinuxenabled && getenforce returnerar Enforcing. Min guide om SELinux på RHEL 10, felsöka denials och skriva policymoduler täcker uppföljning av SELINUX-3204-varningar där en anpassad policymodul behövs.

Brandväggskontrollerna (FIRE-4590, FIRE-4592) verifierar att nftables eller firewalld är aktivt med en default-drop-policy. På 6.12 LTS-kärnan har nftables en förbättrad flowtable-implementation som ger märkbart bättre throughput. En modern nftables-baserad brandvägg är ett måste, inte en kompromiss.

Vanliga frågor

Vad är Lynis och vad används det till?

Lynis är ett agentlöst open source-verktyg som auditerar en Linux-värd mot över 300 säkerhetskontroller från CIS, STIG, PCI DSS och HIPAA. Det körs som ett POSIX-shell-skript, kräver inga externa runtime-beroenden och producerar ett hardening index samt konkreta åtgärdsförslag per Test-ID.

Hur ofta ska jag köra Lynis på en produktionsvärd?

Minst en gång per dygn som cronjob med --cronjob --quick och delta-jämförelse mot föregående dag. Vid större systemförändringar (kernel-uppgraderingar, Ansible-roll-uppdateringar, nya paket) kör du en interaktiv full audit direkt efter change window för att verifiera att hardening index inte regredierat.

Är Lynis gratis?

Community Edition är GPLv3 och helt gratis, inklusive alla 300+ kontroller. CISOfy erbjuder Lynis Enterprise som lägger till centraliserad rapportering, plugins för PCI DSS/HIPAA-specifika krav och support, men Community Edition räcker för de flesta on-prem och cloud-audits.

Vad är en bra hardening index-poäng?

Under 60 innebär att grundhärdning saknas. 60–75 är typiskt för en färsk distro-installation utan Ansible-baseline. 80–90 är målvärdet för välhärdade produktionsvärdar. Över 90 kräver att du accepterat vissa varningar dokumenterat i custom.prf. 100/100 är i praktiken inte uppnåeligt på ett faktiskt fungerande system.

Lynis vs OpenSCAP, vilket ska jag välja?

De löser överlappande problem. Välj OpenSCAP när du behöver formell auditbar XCCDF-rapport för DoD-, FedRAMP- eller PCI DSS-revision. Välj Lynis när du behöver snabb feedback (45 sekunder mot 3+ minuter), enklare CI-integration och distributionsspecifika kontext-kontroller. På mogna team kör man båda: Lynis för iterationshastighet, SCAP för formell certifiering.

Kan Lynis fixa varningar automatiskt?

Nej, Lynis är strikt läs-only. All remediation sker med Ansible-roller som dev-sec/linux-baseline eller ansible-lockdown/RHEL10-CIS, eller manuellt via de sysctl-, PAM- och SSHD-snuttar som visas i den här guiden. Detta är en medveten designprincip: audit-verktyg ska aldrig ändra det system de auditerar.