Audyt i skanowanie podatności Linuksa w 2026 — Lynis, OpenVAS i OpenSCAP w praktyce

Wprowadzenie: Po hartowaniu czas na weryfikację

W poprzednich pięciu artykułach naszej serii poświęconej hartowaniu Linuksa przeszliśmy przez kluczowe warstwy obrony: zabezpieczenie jądra (sysctl, Seccomp, Landlock), hartowanie SSH (OpenSSH 10, kryptografia postkwantowa, FIDO2), konfigurację zapory sieciowej (nftables), kontrolę dostępu MAC (SELinux, AppArmor) oraz bezpieczeństwo kontenerów Docker (rootless, Seccomp, AppArmor, audyt CIS). Sporo roboty, prawda?

Ale teraz pojawia się fundamentalne pytanie: skąd właściwie wiesz, że to wszystko działa?

Konfiguracja, która wygląda poprawnie w edytorze tekstu, może zawierać subtelne błędy, pominięcia albo regresje wprowadzone podczas aktualizacji systemu. Widziałem to wielokrotnie — admin skrupulatnie hartuje serwer, a potem rutynowy apt upgrade cicho nadpisuje połowę ustawień. Dlatego szósty, naturalny krok w procesie hartowania to systematyczna weryfikacja — audyt konfiguracji i skanowanie podatności.

Rok 2026 przynosi dodatkowe argumenty za regularnym skanowaniem. W 2025 roku opublikowano rekordowe 5530 CVE dotyczących jądra Linuksa — wzrost o 28% rok do roku. Grupy ransomware, takie jak Qilin i RansomHub, aktywnie wykorzystują niezałatane podatności. Do tego dochodzą regulacje NIS2 (obowiązujące w UE od października 2024), które wymagają od organizacji udowodnienia, że prowadzą ciągły monitoring bezpieczeństwa. Narzędzia opisane w tym artykule — Lynis, OpenVAS/GVM i OpenSCAP — pozwalają spełnić te wymagania w sposób zautomatyzowany i powtarzalny.

Trzy filary skanowania bezpieczeństwa

Kompleksowa weryfikacja bezpieczeństwa systemu Linux wymaga podejścia wielowarstwowego. Żadne pojedyncze narzędzie nie pokryje wszystkich aspektów — dlatego w praktyce stosujemy trzy uzupełniające się filary. Przejdźmy przez każdy z nich.

Audyt konfiguracji hosta (Lynis)

Lynis to narzędzie do audytu bezpieczeństwa działające lokalnie na hoście. Analizuje konfigurację systemu operacyjnego, usług, uprawnień plików, ustawień jądra i setek innych parametrów. Nie skanuje sieci ani nie szuka podatności w oprogramowaniu — zamiast tego weryfikuje, czy system jest poprawnie skonfigurowany zgodnie z najlepszymi praktykami. Lynis odpowiada na pytanie: „Czy mój system jest poprawnie zahartowany?"

Skanowanie podatności sieciowych (OpenVAS/GVM)

OpenVAS (Open Vulnerability Assessment Scanner), będący częścią platformy Greenbone Vulnerability Management (GVM), to skaner podatności sieciowych. Działa z zewnątrz — łączy się z hostem przez sieć i sprawdza, jakie usługi są dostępne, jakie wersje oprogramowania działają i czy zawierają znane podatności (CVE). Innymi słowy, OpenVAS odpowiada na pytanie: „Co widzi atakujący, gdy skanuje mój serwer?"

Audyt zgodności z benchmarkami (OpenSCAP)

OpenSCAP to framework do automatycznej oceny zgodności systemu z predefiniowanymi profilami bezpieczeństwa, takimi jak CIS Benchmarks, DISA STIG czy PCI-DSS. Każdy profil zawiera setki reguł sprawdzających konkretne ustawienia. OpenSCAP odpowiada na pytanie: „Czy mój system spełnia wymogi danego standardu bezpieczeństwa?"

W praktyce te trzy narzędzia tworzą kompletny obraz: Lynis weryfikuje ogólne hartowanie, OpenVAS wykrywa podatności widoczne z sieci, a OpenSCAP potwierdza zgodność z konkretnymi standardami. Żadne z nich samodzielnie nie wystarczy — ale razem dają naprawdę solidne pokrycie.

Lynis 3.1 — audyt konfiguracji i hartowania

Lynis to jedno z najbardziej dojrzałych narzędzi do audytu bezpieczeństwa systemów Unix/Linux. Rozwijane przez firmę CISOfy od 2007 roku, jest dostępne na licencji GPL. Aktualna wersja to Lynis 3.1.6 (wydana w październiku 2025), która wprowadza wsparcie dla CachyOS, OpenMandriva Lx oraz ulepszoną detekcję agenta Wazuh.

Instalacja Lynis

Lynis można zainstalować na kilka sposobów. Najbardziej zalecana jest instalacja z oficjalnego repozytorium CISOfy, które zawsze udostępnia najnowszą wersję:

# Metoda 1: Repozytorium CISOfy (Debian/Ubuntu)
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 013baa07180c50a7101097ef9de922f1c2fde6c4
echo "deb 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 lynis

# Metoda 2: Repozytorium CISOfy (RHEL/Fedora)
sudo cat > /etc/yum.repos.d/cisofy-lynis.repo << 'EOF'
[lynis]
name=CISOfy Software - Lynis package
baseurl=https://packages.cisofy.com/community/lynis/rpm/
enabled=1
gpgkey=https://packages.cisofy.com/keys/cisofy-software-rpms-public.key
gpgcheck=1
priority=2
EOF
sudo dnf install lynis

# Metoda 3: Bezpośrednio z GitHuba (uniwersalna)
cd /opt
sudo git clone https://github.com/CISOfy/lynis.git
cd lynis
sudo ./lynis audit system

Po instalacji warto zweryfikować wersję:

lynis show version
# Oczekiwany wynik: 3.1.6

Uruchomienie pełnego audytu

Podstawowe skanowanie systemu wymaga uprawnień root i wykonuje się jednym poleceniem:

sudo lynis audit system

Lynis przejdzie przez kilkadziesiąt kategorii testów, wyświetlając wyniki w czasie rzeczywistym. Szczerze mówiąc, obserwowanie tego procesu po raz pierwszy jest dość satysfakcjonujące — widzisz dokładnie, co narzędzie sprawdza i jak ocenia Twój system. Po zakończeniu skanowania zobaczysz podsumowanie z trzema kluczowymi elementami:

• Hardening index — wynik od 0 do 100 punktów. Świeża instalacja typowej dystrybucji osiąga 55-65 punktów. Docelowy wynik dla serwerów produkcyjnych to 80 punktów lub więcej.
• Warnings — krytyczne problemy wymagające natychmiastowej uwagi (np. brak zapory sieciowej, domyślne hasła).
• Suggestions — zalecenia poprawy bezpieczeństwa, uporządkowane według identyfikatorów testów.

Kluczowe kategorie testów

Lynis organizuje testy w kategorie oznaczone unikalnymi prefiksami. Oto te najważniejsze z perspektywy naszej serii hartowania:

Prefiks	Kategoria	Przykładowe testy
KRNL	Jądro systemu	Parametry sysctl, moduły jądra, wersja
SSH	Serwer SSH	Algorytmy, uwierzytelnianie, PermitRootLogin
FIRE	Zapora sieciowa	Status iptables/nftables, domyślne polityki
AUTH	Uwierzytelnianie	Polityka haseł, PAM, konta systemowe
ACCT	Rozliczalność	auditd, logi systemowe, syslog
MALW	Malware	ClamAV, rkhunter, detekcja Wazuh
FILE	System plików	Uprawnienia, SUID/SGID, integralność
CONT	Kontenery	Docker daemon, konfiguracja kontenerów

Praca z sugestiami i ostrzeżeniami

Po zakończeniu skanowania szczegółowe wyniki znajdziesz w dwóch plikach:

# Pełny log skanowania
sudo cat /var/log/lynis.log

# Raport z sugestiami i ostrzeżeniami (format klucz=wartość)
sudo cat /var/log/lynis-report.dat

# Wyświetlenie samych sugestii
sudo grep "suggestion\[\]" /var/log/lynis-report.dat

# Szczegóły konkretnego testu
sudo lynis show details SSH-7408

Każda sugestia zawiera identyfikator testu (np. SSH-7408), opis problemu oraz — w wielu przypadkach — konkretne polecenie naprawcze. Systematyczne rozwiązywanie sugestii pozwala stopniowo podnosić indeks hartowania. Warto potraktować to jak checklistę i odhaczać punkt po punkcie.

Profile niestandardowe

Lynis pozwala dostosować zachowanie skanera za pomocą profili konfiguracyjnych. Domyślny profil znajduje się w /etc/lynis/default.prf, a własne ustawienia należy umieszczać w /etc/lynis/custom.prf:

# /etc/lynis/custom.prf — profil niestandardowy

# Pomiń test, który nie ma zastosowania w Twoim środowisku
skip-test=NETW-2400
skip-test=USB-1000

# Włącz kolorowe wyjście
colors=yes

# Ustaw minimalny akceptowalny indeks hartowania
min-hardening-index=80

# Skonfiguruj ścieżki do logów
log-file=/var/log/lynis/lynis.log
report-file=/var/log/lynis/lynis-report.dat

# Włącz skanowanie kontenerów Docker
containers-scan=yes

# Weryfikacja uprawnień plików konfiguracyjnych
config-data=permissions:/etc/ssh/sshd_config:root:root:600:

Przydatna wskazówka: zanim zaczniesz pomijać testy za pomocą skip-test, upewnij się, że naprawdę nie mają zastosowania w Twoim środowisku. Łatwo wpaść w pułapkę wyciszania „niewygodnych" wyników zamiast faktycznego naprawiania problemów.

Automatyzacja za pomocą cron

Regularne skanowanie jest kluczowe dla utrzymania bezpieczeństwa. Poniższy wpis w crontabie uruchomi audyt Lynis codziennie o 3:00 w nocy:

# Edytuj crontab roota
sudo crontab -e

# Dodaj wpis: codzienny audyt o 3:00
0 3 * * * /usr/sbin/lynis audit system --cronjob --quiet 2>&1 | logger -t lynis

Opcja --cronjob wyłącza interaktywne elementy interfejsu, a --quiet ogranicza wyjście do ostrzeżeń i błędów. Proste, a daje spokój ducha.

OpenVAS/GVM 24 — skanowanie podatności sieciowych

Greenbone Vulnerability Management (GVM) to wiodąca platforma open-source do skanowania podatności sieciowych. Jej centralnym komponentem jest skaner OpenVAS, który dysponuje bazą ponad 180 000 testów podatności (NVT), aktualizowaną codziennie. W 2026 roku zalecaną metodą wdrożenia jest Greenbone Community Edition 24.10 uruchamiana w kontenerach Docker.

Architektura GVM

Platforma GVM składa się z kilku współpracujących komponentów (tak, jest tego sporo, ale Docker Compose załatwia większość konfiguracji za nas):

• GSA (Greenbone Security Assistant) — interfejs webowy do zarządzania skanami i przeglądania raportów.
• gvmd (Greenbone Vulnerability Manager Daemon) — centralny demon zarządzający zadaniami skanowania, konfiguracjami i wynikami.
• ospd-openvas — warstwa pośrednia między gvmd a skanerem OpenVAS, implementująca protokół OSP.
• openvas-scanner — właściwy silnik skanujący, wykonujący testy NVT na zdalnych hostach.
• notus-scanner — skaner odpowiedzialny za weryfikację wersji zainstalowanych pakietów.
• pg-gvm — baza danych PostgreSQL przechowująca wyniki skanów i konfiguracje.

Instalacja za pomocą Docker Compose

Poniższa konfiguracja Docker Compose uruchamia pełny stos GVM 24.10. Utwórz katalog roboczy i pobierz oficjalny plik compose:

# Utworzenie katalogu roboczego
export DOWNLOAD_DIR=$HOME/greenbone-community-edition
mkdir -p $DOWNLOAD_DIR
cd $DOWNLOAD_DIR

# Pobranie oficjalnego pliku docker-compose
curl -f -O -L https://greenbone.github.io/docs/latest/_static/docker-compose-22.4.yml
mv docker-compose-22.4.yml docker-compose.yml

# Uruchomienie stosu GVM
docker compose -p greenbone-community-edition up -d

# Sprawdzenie statusu kontenerów
docker compose -p greenbone-community-edition ps

Pierwsze uruchomienie trwa dłużej ze względu na pobranie obrazów kontenerów i synchronizację baz danych NVT. W zależności od sprzętu może to zająć od 15 minut do nawet kilku godzin — dobry moment na kawę.

Konfiguracja początkowa

Po uruchomieniu kontenerów interfejs webowy GSA jest dostępny pod adresem http://127.0.0.1:9392. Domyślne dane logowania to admin/admin. Natychmiast po pierwszym logowaniu zmień hasło — to naprawdę ważne, zwłaszcza jeśli serwer jest dostępny w sieci:

# Zmiana hasła administratora
docker compose -p greenbone-community-edition \
  exec -u gvmd gvmd gvmd \
  --user=admin --new-password='TwojeNoweS1lneH@slo!'

# Sprawdzenie, czy bazy NVT są zsynchronizowane
docker compose -p greenbone-community-edition \
  exec -u gvmd gvmd gvmd --get-feeds

Przed uruchomieniem pierwszego skanu upewnij się, że kolumna Status dla wszystkich feedów pokazuje Current. Skanowanie z nieaktualnymi bazami zwróci niekompletne wyniki — a to gorzej niż brak skanowania, bo daje fałszywe poczucie bezpieczeństwa.

Konfiguracje skanowania

GVM oferuje kilka predefiniowanych konfiguracji skanowania, różniących się zakresem i głębokością:

Konfiguracja	Opis	Zastosowanie
Full and Fast	Pełny skan z optymalizacją szybkości	Standardowe skanowanie produkcyjne
Full and Fast Ultimate	Pełny skan z testami mogącymi zakłócić usługi	Środowiska testowe
Full and Deep	Dogłębny skan bez optymalizacji szybkości	Dokładna analiza krytycznych systemów
Discovery	Tylko wykrywanie hostów i usług	Inwentaryzacja sieci
Host Discovery	Wykrywanie aktywnych hostów (ping)	Mapowanie infrastruktury

Dla serwerów produkcyjnych zdecydowanie polecam konfigurację Full and Fast — stanowi optymalny kompromis między dokładnością a bezpieczeństwem skanowania.

Uruchomienie pierwszego skanu

Skan można uruchomić zarówno przez interfejs webowy GSA, jak i za pomocą narzędzia wiersza poleceń gvm-cli. Poniżej przykład z użyciem API:

# Instalacja klienta GVM (na hoście zarządzającym)
pip install gvm-tools

# Uruchomienie skanu za pomocą gvm-cli
gvm-cli --gmp-username admin --gmp-password 'TwojeH@slo' \
  socket --socketpath /run/gvmd/gvmd.sock \
  --xml '<create_task>
    <name>Skan produkcyjny - serwery web</name>
    <config id="daba56c8-73ec-11df-a475-002264764cea"/>
    <target id="ID_CELU"/>
    <scanner id="08b69003-5fc2-4037-a479-93b440211c73"/>
  </create_task>'

W praktyce większość administratorów korzysta po prostu z interfejsu webowego GSA, gdzie proces tworzenia skanu jest intuicyjny: Configuration > Targets (definiowanie celów), a następnie Scans > Tasks (tworzenie zadania skanowania). Interfejs CLI jest przydatny głównie przy automatyzacji.

Interpretacja wyników — skala CVSS

Wyniki skanowania OpenVAS są klasyfikowane według skali CVSS (Common Vulnerability Scoring System) w wersji 3.1:

Wynik CVSS	Poziom zagrożenia	Wymagane działanie
9.0 - 10.0	Krytyczny	Natychmiastowa naprawa (do 24 godzin)
7.0 - 8.9	Wysoki	Naprawa w ciągu 7 dni
4.0 - 6.9	Średni	Naprawa w ciągu 30 dni
0.1 - 3.9	Niski	Naprawa przy okazji następnego okna serwisowego

Oczywiście te ramy czasowe to rekomendacje — w praktyce krytyczne podatności na serwerach publicznych wymagają reakcji jeszcze szybciej, najlepiej w ciągu kilku godzin.

Planowanie cyklicznych skanów

W interfejsie GSA przejdź do Configuration > Schedules, aby utworzyć harmonogram. Zalecane częstotliwości:

• Serwery publiczne (webowe, mailowe, DNS) — co tydzień
• Serwery wewnętrzne — co 2 tygodnie
• Stacje robocze — co miesiąc
• Po każdej istotnej zmianie — skan ad hoc

OpenSCAP i CIS Benchmarks — audyt zgodności

SCAP (Security Content Automation Protocol) to zestaw standardów opracowanych przez NIST, umożliwiających automatyczną ocenę zgodności systemów z predefiniowanymi profilami bezpieczeństwa. OpenSCAP to referencyjna implementacja open-source tych standardów, a SCAP Security Guide (SSG) dostarcza gotowe profile zgodności dla dziesiątek platform.

CIS Benchmarks (Center for Internet Security) to uznane na całym świecie standardy konfiguracji bezpieczeństwa, opracowywane przez społeczność ekspertów. Każdy benchmark dzieli się na dwa poziomy:

• Level 1 — podstawowe zabezpieczenia, które powinny być wdrożone na każdym systemie. Nie powodują istotnego wpływu na funkcjonalność.
• Level 2 — zaawansowane zabezpieczenia dla środowisk o podwyższonym ryzyku. Mogą wymagać dostosowania konfiguracji aplikacji (więc ostrożnie na produkcji).

Instalacja OpenSCAP

Instalacja zależy od dystrybucji. Pakiet scap-security-guide w wersji 0.1.75 lub nowszej zawiera profile CIS Benchmark aktualizowane na rok 2025/2026:

# RHEL / Fedora / CentOS Stream / AlmaLinux / Rocky Linux
sudo dnf install openscap-scanner scap-security-guide

# Debian 12 / Ubuntu 22.04+
sudo apt install libopenscap8 ssg-debian ssg-base

# Ubuntu 24.04 — dodatkowy pakiet z profilami Ubuntu
sudo apt install libopenscap8 ssg-ubuntu

# Sprawdzenie zainstalowanej wersji
oscap --version

Dostępne profile

Po instalacji możesz wyświetlić listę dostępnych profili dla danej dystrybucji:

# Lista profili dla RHEL 9
oscap info /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

# Lista profili dla Ubuntu 24.04
oscap info /usr/share/xml/scap/ssg/content/ssg-ubuntu2404-ds.xml

Najczęściej używane profile CIS:

Identyfikator profilu	Opis
xccdf_org.ssgproject.content_profile_cis	CIS Level 2 Server (pełny)
xccdf_org.ssgproject.content_profile_cis_server_l1	CIS Level 1 Server
xccdf_org.ssgproject.content_profile_cis_workstation_l1	CIS Level 1 Workstation
xccdf_org.ssgproject.content_profile_cis_workstation_l2	CIS Level 2 Workstation
xccdf_org.ssgproject.content_profile_pci-dss	PCI-DSS v4.0
xccdf_org.ssgproject.content_profile_stig	DISA STIG

Uruchomienie skanowania zgodności

Poniższy przykład uruchamia skanowanie zgodności z profilem CIS Level 1 Server na systemie RHEL 9:

# Skanowanie zgodności CIS Level 1 Server — RHEL 9
sudo oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_cis_server_l1 \
  --results /tmp/oscap-cis-results.xml \
  --report /tmp/oscap-cis-report.html \
  /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

Dla Ubuntu 24.04:

# Skanowanie zgodności CIS Level 1 Server — Ubuntu 24.04
sudo oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_cis_server_l1 \
  --results /tmp/oscap-cis-results.xml \
  --report /tmp/oscap-cis-report.html \
  /usr/share/xml/scap/ssg/content/ssg-ubuntu2404-ds.xml

Polecenie generuje dwa pliki wyjściowe:

• /tmp/oscap-cis-results.xml — wyniki w formacie XCCDF (do przetwarzania maszynowego).
• /tmp/oscap-cis-report.html — czytelny raport HTML z kolorowymi oznaczeniami zgodności. Ten plik warto otworzyć w przeglądarce — jest naprawdę dobrze zorganizowany.

Generowanie raportów HTML

Jeśli masz już plik wyników XML z wcześniejszego skanowania, możesz wygenerować raport HTML osobno:

# Generowanie raportu HTML z istniejących wyników
oscap xccdf generate report /tmp/oscap-cis-results.xml > /tmp/oscap-cis-report.html

# Generowanie raportu naprawczego (remediation guide)
oscap xccdf generate fix \
  --fix-type bash \
  --result-id "" \
  /tmp/oscap-cis-results.xml > /tmp/remediation.sh

Raport HTML zawiera dla każdej reguły informację o statusie (pass, fail, notapplicable), opis reguły, uzasadnienie oraz instrukcje naprawcze.

Automatyczna remediacja — z ostrożnością

OpenSCAP umożliwia automatyczne naprawianie niezgodności za pomocą wygenerowanych skryptów Bash lub playbooków Ansible:

# Wygenerowanie playbooka Ansible z naprawami
oscap xccdf generate fix \
  --fix-type ansible \
  --profile xccdf_org.ssgproject.content_profile_cis_server_l1 \
  /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml > /tmp/cis-remediation.yml

# Alternatywnie: gotowy playbook z pakietu scap-security-guide
ls /usr/share/scap-security-guide/ansible/
# rhel9-playbook-cis_server_l1.yml
# rhel9-playbook-cis.yml
# ...

# Uruchomienie remediacji Ansible (na serwerze docelowym)
ansible-playbook -i localhost, -c local \
  /usr/share/scap-security-guide/ansible/rhel9-playbook-cis_server_l1.yml

Ostrzeżenie: Automatyczna remediacja może zakłócić działanie usług produkcyjnych. Zawsze — naprawdę zawsze — najpierw przetestuj zmiany na systemie testowym. Szczególną ostrożność zachowaj przy regułach dotyczących konfiguracji sieci, usług systemowych i partycjonowania dysków. Ich automatyczne zastosowanie na działającym serwerze może skończyć się niedostępnością, a to raczej nie jest pożądany efekt audytu bezpieczeństwa.

Zdalne skanowanie za pomocą oscap-ssh

Narzędzie oscap-ssh umożliwia skanowanie zdalnych hostów bez konieczności instalowania OpenSCAP na każdym z nich:

# Instalacja narzędzia do zdalnego skanowania
sudo dnf install openscap-utils   # RHEL/Fedora
sudo apt install libopenscap8     # Debian/Ubuntu

# Zdalne skanowanie serwera 192.168.1.100
oscap-ssh [email protected] 22 xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_cis_server_l1 \
  --results /tmp/remote-results.xml \
  --report /tmp/remote-report.html \
  /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

Narzędzie automatycznie kopiuje pliki SCAP na zdalny host, wykonuje skanowanie i pobiera wyniki. Wymaga jedynie połączenia SSH i uprawnień root na zdalnym serwerze. Jeśli zarządzasz większą liczbą maszyn, to jest zdecydowanie wygodniejsze niż instalowanie OpenSCAP na każdej z nich osobno.

Budowa zautomatyzowanego pipeline'u skanowania

W środowisku produkcyjnym ręczne uruchamianie trzech osobnych narzędzi po prostu się nie sprawdza. Poniższy skrypt łączy Lynis i OpenSCAP w jeden zautomatyzowany pipeline, generujący skonsolidowany raport i wysyłający powiadomienia.

#!/usr/bin/env bash
# ============================================================
# security-audit-pipeline.sh
# Zautomatyzowany pipeline audytu bezpieczeństwa
# Lynis 3.1.x + OpenSCAP (CIS Benchmark)
# ============================================================
set -euo pipefail

# ---------- Konfiguracja ----------
REPORT_DIR="/var/log/security-audit"
DATE=$(date +%Y-%m-%d_%H%M)
HOSTNAME=$(hostname -f)
EMAIL_TO="[email protected]"
OSCAP_PROFILE="xccdf_org.ssgproject.content_profile_cis_server_l1"
OSCAP_CONTENT="/usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml"
MIN_HARDENING_INDEX=80
LYNIS_BIN="/usr/sbin/lynis"

# ---------- Przygotowanie ----------
mkdir -p "${REPORT_DIR}/${DATE}"
LOG="${REPORT_DIR}/${DATE}/pipeline.log"
exec > >(tee -a "$LOG") 2>&1

echo "=== Pipeline audytu bezpieczeństwa — ${HOSTNAME} ==="
echo "=== Data: ${DATE} ==="
echo ""

# ---------- Etap 1: Audyt Lynis ----------
echo "[1/3] Uruchamianie audytu Lynis..."
${LYNIS_BIN} audit system --cronjob --quiet \
  --logfile "${REPORT_DIR}/${DATE}/lynis.log" \
  --report-file "${REPORT_DIR}/${DATE}/lynis-report.dat"

# Pobranie indeksu hartowania
HARDENING_INDEX=$(grep "hardening_index=" "${REPORT_DIR}/${DATE}/lynis-report.dat" \
  | cut -d= -f2)
WARNINGS=$(grep -c "^warning\[\]" "${REPORT_DIR}/${DATE}/lynis-report.dat" || true)
SUGGESTIONS=$(grep -c "^suggestion\[\]" "${REPORT_DIR}/${DATE}/lynis-report.dat" || true)

echo "  Indeks hartowania Lynis: ${HARDENING_INDEX}/100"
echo "  Ostrzeżenia: ${WARNINGS}"
echo "  Sugestie: ${SUGGESTIONS}"
echo ""

# ---------- Etap 2: Skanowanie OpenSCAP ----------
echo "[2/3] Uruchamianie skanowania OpenSCAP (CIS)..."
oscap xccdf eval \
  --profile "${OSCAP_PROFILE}" \
  --results "${REPORT_DIR}/${DATE}/oscap-results.xml" \
  --report "${REPORT_DIR}/${DATE}/oscap-report.html" \
  "${OSCAP_CONTENT}" || true  # oscap zwraca kod != 0 przy niezgodnościach

# Zliczenie wyników
OSCAP_PASS=$(grep -c 'result="pass"' "${REPORT_DIR}/${DATE}/oscap-results.xml" || true)
OSCAP_FAIL=$(grep -c 'result="fail"' "${REPORT_DIR}/${DATE}/oscap-results.xml" || true)
OSCAP_TOTAL=$((OSCAP_PASS + OSCAP_FAIL))
if [ "$OSCAP_TOTAL" -gt 0 ]; then
  OSCAP_PERCENT=$(( (OSCAP_PASS * 100) / OSCAP_TOTAL ))
else
  OSCAP_PERCENT=0
fi

echo "  Reguły spełnione: ${OSCAP_PASS}/${OSCAP_TOTAL} (${OSCAP_PERCENT}%)"
echo "  Reguły niespełnione: ${OSCAP_FAIL}"
echo ""

# ---------- Etap 3: Generowanie raportu zbiorczego ----------
echo "[3/3] Generowanie raportu zbiorczego..."

cat > "${REPORT_DIR}/${DATE}/summary.txt" << SUMMARY
===================================================
RAPORT AUDYTU BEZPIECZEŃSTWA — ${HOSTNAME}
Data: ${DATE}
===================================================

--- Lynis ---
Indeks hartowania:  ${HARDENING_INDEX}/100
Ostrzeżenia:       ${WARNINGS}
Sugestie:           ${SUGGESTIONS}
Status:             $([ "${HARDENING_INDEX}" -ge "${MIN_HARDENING_INDEX}" ] \
                      && echo "OK" || echo "PONIŻEJ PROGU (min. ${MIN_HARDENING_INDEX})")

--- OpenSCAP (CIS Level 1 Server) ---
Reguły spełnione:   ${OSCAP_PASS}/${OSCAP_TOTAL} (${OSCAP_PERCENT}%)
Reguły niespełnione: ${OSCAP_FAIL}

--- Pliki raportów ---
Lynis log:          ${REPORT_DIR}/${DATE}/lynis.log
Lynis raport:       ${REPORT_DIR}/${DATE}/lynis-report.dat
OpenSCAP raport:    ${REPORT_DIR}/${DATE}/oscap-report.html
OpenSCAP wyniki:    ${REPORT_DIR}/${DATE}/oscap-results.xml
===================================================
SUMMARY

# ---------- Wysyłka e-mail ----------
if command -v mail &> /dev/null; then
  mail -s "[Security Audit] ${HOSTNAME} — HI:${HARDENING_INDEX} CIS:${OSCAP_PERCENT}%" \
    -a "${REPORT_DIR}/${DATE}/oscap-report.html" \
    "${EMAIL_TO}" < "${REPORT_DIR}/${DATE}/summary.txt"
  echo "Raport wysłany na: ${EMAIL_TO}"
fi

# ---------- Alerty ----------
if [ "${HARDENING_INDEX}" -lt "${MIN_HARDENING_INDEX}" ]; then
  echo "ALERT: Indeks hartowania (${HARDENING_INDEX}) poniżej progu (${MIN_HARDENING_INDEX})!"
  # Opcjonalnie: wyślij alert do Wazuh/SIEM przez syslog
  logger -t security-audit -p auth.warning \
    "Lynis hardening index ${HARDENING_INDEX} below threshold ${MIN_HARDENING_INDEX} on ${HOSTNAME}"
fi

echo ""
echo "=== Pipeline zakończony pomyślnie ==="

Skrypt uruchamiamy za pomocą cron:

# Codzienny audyt o 2:00 w nocy
sudo crontab -e
0 2 * * * /opt/scripts/security-audit-pipeline.sh

Integracja z Wazuh i SIEM

Aby zintegrować wyniki audytu z systemem SIEM, takim jak Wazuh, skonfiguruj agenta Wazuh do monitorowania plików raportów Lynis:

<!-- /var/ossec/etc/ossec.conf — konfiguracja agenta Wazuh -->
<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/lynis.log</location>
</localfile>

<localfile>
  <log_format>full_command</log_format>
  <command>grep "^warning\[\]" /var/log/lynis-report.dat</command>
  <frequency>86400</frequency>
  <alias>lynis-warnings</alias>
</localfile>

Wazuh automatycznie parsuje logi Lynis i generuje alerty w panelu SIEM, umożliwiając centralne monitorowanie stanu bezpieczeństwa całej infrastruktury. To naprawdę wygodne rozwiązanie, gdy zarządzasz więcej niż kilkoma serwerami.

Porównanie narzędzi

Poniższa tabela zestawia kluczowe cechy trzech omawianych narzędzi. Pomoże Ci szybko zdecydować, które z nich najlepiej pasuje do Twojego przypadku:

Kryterium	Lynis	OpenVAS/GVM	OpenSCAP
Typ narzędzia	Audyt lokalny hosta	Skaner podatności sieciowych	Audyt zgodności ze standardami
Zakres analizy	Konfiguracja OS, usług, uprawnień	Podatności CVE widoczne z sieci	Zgodność z CIS, STIG, PCI-DSS
Metoda działania	Bezagentowa, lokalna	Zdalna, przez sieć	Lokalna lub zdalna (oscap-ssh)
Złożoność instalacji	Niska (jeden pakiet/skrypt)	Wysoka (Docker Compose, kilka GB)	Niska (pakiety systemowe)
Zgodność z CIS	Częściowa (ogólne zalecenia)	Nie	Pełna (oficjalne profile CIS)
Skanowanie CVE/CVSS	Nie	Tak (180 000+ testów NVT)	Częściowe (weryfikacja wersji pakietów)
Automatyczna remediacja	Nie (sugestie tekstowe)	Nie	Tak (Bash/Ansible)
Format raportów	Tekst, JSON (Enterprise)	HTML, PDF, XML, CSV	HTML, XML (XCCDF/ARF)
Najlepsze zastosowanie	Codzienny audyt hartowania	Cykliczne skanowanie infrastruktury	Audyt zgodności regulacyjnej
Aktualna wersja (2026)	3.1.6	GVM 24.10	SSG 0.1.75+

Moja rekomendacja: Dla kompleksowej ochrony wdróż wszystkie trzy narzędzia. Lynis służy jako codzienna linia bazowa hartowania, OpenVAS wykrywa podatności widoczne z perspektywy atakującego, a OpenSCAP zapewnia formalną zgodność ze standardami wymaganymi przez audytorów i regulatorów. Razem dają obraz, którego żadne z nich nie da samodzielnie.

FAQ — Najczęściej zadawane pytania

Czy Lynis może zastąpić OpenVAS?

Krótka odpowiedź: nie. Lynis i OpenVAS pełnią fundamentalnie różne funkcje. Lynis analizuje konfigurację hosta od wewnątrz — sprawdza ustawienia jądra, usług, uprawnień plików i polityk bezpieczeństwa. OpenVAS skanuje system od zewnątrz przez sieć — wykrywa otwarte porty, identyfikuje wersje usług i sprawdza je pod kątem znanych podatności CVE.

System może mieć doskonałą konfigurację wewnętrzną (wysoki wynik Lynis), ale jednocześnie uruchamiać usługę z krytyczną podatnością widoczną z sieci — którą wykryje tylko OpenVAS. Oba narzędzia są komplementarne i powinny być stosowane łącznie.

Jak często skanować serwery produkcyjne?

Częstotliwość zależy od ekspozycji systemu na zagrożenia. Rekomendowane minimum: Lynis — codziennie (niski narzut, szybkie wykonanie), OpenVAS — co tydzień dla serwerów publicznych, co dwa tygodnie dla wewnętrznych, OpenSCAP — co tydzień lub po każdej znaczącej zmianie konfiguracji.

Dodatkowo zawsze uruchom skanowanie ad hoc po aktualizacji systemu, wdrożeniu nowej usługi lub zmianie konfiguracji sieciowej. Regulacje NIS2 wymagają udowodnienia ciągłego monitorowania — dokumentuj harmonogramy i wyniki skanów, bo audytor na pewno o nie zapyta.

Czy OpenSCAP działa na Ubuntu i Debianie?

Tak, choć wsparcie jest najszersze na platformach Red Hat. Pakiet scap-security-guide w wersji 0.1.75+ zawiera profile dla Ubuntu 20.04, 22.04 i 24.04 oraz Debian 11 i 12. Profile CIS są dostępne, choć mogą mieć nieco mniejsze pokrycie reguł niż profile dla RHEL.

Na Debianie zainstaluj pakiety ssg-debian i ssg-base, a na Ubuntu — ssg-ubuntu. Pliki datastream znajdziesz w katalogu /usr/share/xml/scap/ssg/content/ z odpowiednimi prefiksami (ssg-ubuntu2404-ds.xml, ssg-debian12-ds.xml).

Co zrobić, gdy indeks hartowania Lynis jest poniżej 70?

Indeks poniżej 70 wskazuje na istotne braki w konfiguracji bezpieczeństwa. Nie panikuj — systematyczne podejście pozwoli to szybko poprawić:

(1) Uruchom sudo lynis audit system i zanotuj wszystkie ostrzeżenia (warnings) — to krytyczne problemy do natychmiastowej naprawy. (2) Przejrzyj sugestie (suggestions) i zacznij od kategorii KRNL, SSH i FIRE — odpowiadają one pierwszym trzem artykułom naszej serii. (3) Wdróż zaporę sieciową nftables, jeśli jej brakuje — sam ten krok może podnieść indeks o 5-10 punktów. (4) Skonfiguruj auditd i włącz monitorowanie kluczowych plików. (5) Ustaw politykę haseł w PAM. (6) Po każdej zmianie uruchom ponownie skanowanie, żeby zweryfikować postęp.

Realizacja zaleceń opisanych w naszej serii hartowania powinna pozwolić na osiągnięcie indeksu 80+ na większości dystrybucji.

Czy skanowanie OpenVAS może zakłócić działanie serwera produkcyjnego?

W konfiguracji domyślnej (Full and Fast) ryzyko zakłóceń jest minimalne — OpenVAS unika testów mogących powodować odmowę usługi. Ale pewne środki ostrożności warto zachować:

Unikaj konfiguracji Full and Fast Ultimate oraz Full and Deep Ultimate na produkcji — zawierają testy, które mogą zakłócić usługi. Planuj skanowanie w oknie o niskim ruchu (np. w nocy). Ogranicz liczbę równoczesnych testów NVT w ustawieniach skanera. Poinformuj zespół monitoringu o planowanym skanowaniu, żeby uniknąć fałszywych alarmów IDS/IPS. I — co ważne — pierwsze skanowanie nowego serwera przeprowadź na jego kopii testowej.

W praktyce, przy standardowych ustawieniach, OpenVAS bezpiecznie skanuje tysiące serwerów produkcyjnych na całym świecie bez powodowania przestojów. Ale lepiej dmuchać na zimne.