Lynis: аудит безпеки Linux у 2026

Q: Чи можна Lynis запускати без прав root?

Можна, використовуйте lynis audit system --pentest . У цьому режимі він пропустить тести, що потребують привілейованого доступу (читання /etc/shadow, iptables, audit rules), але виконає всі інші. Індекс буде нижчим через пропущені тести, проте це корисно для self-аудиту звичайними користувачами.

Q: Як часто слід запускати Lynis на сервері?

Мінімум раз на тиждень через cron. Це впіймає випадкові зміни конфігурації, нові пакети з вразливими дефолтами, дії інших адмінів. На критичних серверах щоночі з відправкою звіту в SIEM. У CI/CD на кожному merge до main та nightly для базових образів.

Оновлено: 23 червня 2026 р.

Lynis — це безкоштовний інструмент аудиту безпеки з відкритим кодом для Linux, BSD та macOS, який сканує понад 300 категорій налаштувань і повертає так званий Hardening Index, числову оцінку рівня захищеності системи. Розробляється компанією CISOfy із 2007 року, а у 2026 році актуальна гілка — це Lynis 3.1.x. Чесно кажучи, як пентестер я використовую його як перший крок будь-якого внутрішнього аудиту: запустив, прочитав звіт, заклеїв діри. У цьому посібнику проведу вас від встановлення до інтеграції з CI/CD і виправлення критичних попереджень.

Lynis 3.1.x працює без агента, без root-прав у обмеженому режимі та підтримує Ubuntu, Debian, RHEL, Alma, Rocky, SUSE та FreeBSD.
Команда lynis audit system виконує повний аудит за 2–5 хвилин і записує результати у /var/log/lynis.log та /var/log/lynis-report.dat.
Hardening Index від 0 до 100, мета для production-серверів становить ≥85, для DMZ-хостів та bastion-вузлів ≥90.
Профіль custom.prf дозволяє відключати нерелевантні тести та задавати власні скіпи, що критично для серверів у контейнерах.
Lynis вбудовується у GitLab CI, GitHub Actions та Jenkins через прапорці --cronjob та --quick для автоматизованої перевірки регресій безпеки.
Для аудитів CIS, PCI-DSS та HIPAA доступна комерційна Lynis Enterprise, але базової версії достатньо для 90% задач хардненінгу.

Що таке Lynis і для чого він використовується

Lynis — це shell-скрипт обсягом близько 25 000 рядків, який послідовно виконує перевірки конфігурації ядра, мережі, файлових систем, користувачів, демонів та встановленого ПЗ. На відміну від сканерів вразливостей типу Nessus чи OpenVAS, Lynis не шукає CVE. Він шукає помилки адміністратора: відкриті порти, дозволи 777, відсутні політики паролів, незашифровані розділи, дефолтні налаштування SSH.

З погляду атакуючого, Lynis це чекліст того, що я перевіряю після отримання локального шелла. Якщо PermitRootLogin yes, password authentication enabled, sudo without password, /tmp без noexec, це означає, що адмін не запускав Lynis. У 2026 році інструмент активно підтримується CISOfy (засновник Майкл Боеланд), а останній реліз 3.1.4 вийшов у січні. Lynis ліцензований під GPLv3, повністю відкритий і входить у репозиторії більшості дистрибутивів.

Типові сценарії використання: щотижневий cron-аудит production-серверів, перевірка нового образу перед розгортанням, частина DevSecOps-конвеєра, підготовка до зовнішнього compliance-аудиту (PCI-DSS, ISO 27001, HIPAA), демонстрація прогресу хардненінгу керівництву через історію Hardening Index.

Встановлення Lynis на Ubuntu, Debian та RHEL

Я рекомендую ставити Lynis із GitHub, а не з системного репозиторію. Пакетна версія в Ubuntu 24.04 часто відстає на 1–2 мажорні релізи, а тести безпеки покращуються з кожною ітерацією. Клонування репозиторію займає секунди й дозволяє швидко оновлюватись через git pull. Офіційне джерело: репозиторій CISOfy на GitHub.

Встановлення через git (рекомендовано)

# Клонуємо офіційний репозиторій CISOfy
cd /opt
sudo git clone https://github.com/CISOfy/lynis.git
cd lynis

# Перевіряємо версію
sudo ./lynis show version
# Очікуємо: Lynis 3.1.4 (або новіше)

# Створюємо символічне посилання для зручності
sudo ln -s /opt/lynis/lynis /usr/local/bin/lynis

Встановлення з пакетного менеджера

# Ubuntu / Debian
sudo apt update && sudo apt install -y lynis

# RHEL / AlmaLinux / Rocky Linux 9
sudo dnf install -y epel-release
sudo dnf install -y lynis

# Перевірка
lynis --version

Як запустити перший аудит безпеки Lynis

Базова команда: lynis audit system. Її потрібно виконати від root, інакше частина тестів (наприклад, перевірка /etc/shadow чи правил iptables) буде пропущена. Аудит тривалістю 2–5 хвилин залежно від кількості встановлених сервісів виводить кольоровий звіт прямо у термінал.

# Повний аудит системи
sudo lynis audit system

# Швидкий аудит без інтерактивних пауз (для cron)
sudo lynis audit system --quick

# Аудит у режимі pentest (від звичайного користувача)
lynis audit system --pentest

# Аудит лише конкретної категорії
sudo lynis audit system --tests-from-group "authentication,ssh"

# Аудит з ID групи перевірок
sudo lynis show groups
sudo lynis audit system --tests "SSH-7408,AUTH-9262"

Після завершення Lynis запише три артефакти. По-перше, /var/log/lynis.log, це детальний лог із діагностикою (1–3 МБ). По-друге, /var/log/lynis-report.dat, машинно-читабельний звіт у форматі ключ=значення, який ідеально парситься скриптами та SIEM. По-третє, stdout, де ви побачите стислий звіт із Warnings, Suggestions і Hardening Index.

Як читати звіт та інтерпретувати Hardening Index

У хвості stdout-виводу Lynis показує підсумок:

  Lynis security scan details:

  Hardening index : 67 [#############       ]
  Tests performed : 248
  Plugins enabled : 0

  Components:
  - Firewall               [V]
  - Malware scanner        [X]

  Warnings (3):
  ! Found one or more vulnerable packages [PKGS-7392]
  ! No password set for single user mode [AUTH-9308]
  ! SSH PermitRootLogin is set to yes [SSH-7412]

  Suggestions (28):
  * Install package 'apt-show-versions' for patch management [PKGS-7394]
  * Configure minimum password age [AUTH-9286]
  ...

Hardening Index рахується як відсоток успішних тестів від загальної кількості релевантних. Дефолтна Ubuntu 24.04 server показує приблизно 60–67. Після стандартного хардненінгу (SSH-keys-only, UFW, unattended-upgrades, fail2ban, AppArmor enforce) індекс піднімається до 80–85. Щоб дотягнути до 90+, потрібні: повне шифрування диска, USB-port lockdown, audit-демон, sysctl-параметри для kernel hardening, intrusion detection.

Warnings (позначка !) це критичні знахідки, які слід виправити негайно. Suggestions (*) це рекомендації, які покращать індекс. Кожна знахідка має унікальний ID (наприклад, SSH-7412), за яким можна знайти детальний опис у офіційному каталозі контролів Lynis.

Як виправити попередження Lynis крок за кроком

Розглянемо три типові warnings, які я бачу на 80% серверів під час пентесту.

SSH-7412: PermitRootLogin yes

# Редагуємо конфіг SSH
sudo nano /etc/ssh/sshd_config

# Замінюємо
# PermitRootLogin yes
# на
PermitRootLogin no

# Перевіряємо синтаксис
sudo sshd -t

# Перезавантажуємо демон
sudo systemctl reload ssh

# Повторний аудит лише SSH-тестів
sudo lynis audit system --tests-from-group ssh

Якщо ви адмініструєте сервер віддалено, спершу переконайтесь, що у вас працює sudo від звичайного користувача з SSH-ключем, інакше залочите себе. Я колись отак залочився на бойовому сервері в Гонконгу о третій ночі, тож раджу перевірити двічі. Деталі налаштування SSH-доступу я описав у статті про Fail2ban і захист SSH від brute force. Базові принципи хардненінгу SSH також варто звірити з офіційною документацією OpenSSH.

AUTH-9286: політика мінімального віку паролів

# Встановлюємо для всіх нових користувачів
sudo nano /etc/login.defs

# Знаходимо й змінюємо
PASS_MAX_DAYS   90
PASS_MIN_DAYS   1
PASS_WARN_AGE   14

# Для існуючих користувачів
sudo chage -M 90 -m 1 -W 14 felix

KRNL-5820: відсутність захисту core dumps

# Створюємо файл налаштувань
sudo tee /etc/security/limits.d/coredump.conf << 'EOF'
* hard core 0
* soft core 0
EOF

# Та параметри sysctl
sudo tee /etc/sysctl.d/99-hardening.conf << 'EOF'
fs.suid_dumpable = 0
kernel.core_uses_pid = 1
kernel.dmesg_restrict = 1
kernel.kptr_restrict = 2
kernel.yama.ptrace_scope = 2
EOF

sudo sysctl --system

Подібний підхід застосовується для решти warnings: кожна має ID, для нього є офіційний опис із командою-рекомендацією. Я тримаю Ansible-роль, що автоматизує близько 40 типових fixes; після її застосування Hardening Index на нових Ubuntu 24.04-хостах стабільно ≥83.

Кастомізація через профілі та плагіни

Профіль Lynis це файл .prf, що зберігає список тестів для пропуску, кастомні шляхи логів, нестандартні порти та інші параметри. Дефолтний профіль лежить у /etc/lynis/default.prf; кастомні поряд, у custom.prf.

# /etc/lynis/custom.prf

# Пропускаємо тести, що не релевантні для контейнерів
skip-test=KRNL-5820   # ядро керується host
skip-test=USB-1000    # USB-портів у контейнері немає
skip-test=BOOT-5122   # bootloader відсутній

# Нестандартний порт SSH
ssh-port=2222

# Шлях до кастомного звіту
report-file=/var/log/security/lynis-report.dat

# Не питаємо натиснути Enter між секціями
quick=yes

Плагіни розширюють функціонал Lynis у напрямах compliance (PCI-DSS, HIPAA, GDPR), forensics та custom-checks. Безкоштовно доступні базові, розширені у Lynis Enterprise. Для більшості open-source задач кастомні тести пишуться шеллом і кладуться у /etc/lynis/custom.d/, Lynis підхопить їх автоматично.

Як інтегрувати Lynis у CI/CD пайплайн

Сучасний DevSecOps-підхід полягає в тому, щоб запускати Lynis на кожному merge до main або на nightly-збірці образу. У GitLab CI це виглядає так:

# .gitlab-ci.yml
security-audit:
  stage: security
  image: ubuntu:24.04
  before_script:
    - apt-get update -qq
    - apt-get install -y -qq git sudo
    - git clone https://github.com/CISOfy/lynis.git /opt/lynis
  script:
    - cd /opt/lynis
    - ./lynis audit system --quick --no-colors
    - HARDENING=$(grep "hardening_index" /var/log/lynis-report.dat | cut -d= -f2)
    - echo "Hardening index = $HARDENING"
    - if [ "$HARDENING" -lt 75 ]; then exit 1; fi
  artifacts:
    paths:
      - /var/log/lynis.log
      - /var/log/lynis-report.dat
    expire_in: 30 days
    when: always
  only:
    - main
    - merge_requests

Аналогічний приклад для GitHub Actions, Jenkins чи Drone виглядає так само: викликаємо lynis, парсимо hardening_index, виставляємо поріг. Я зазвичай задаю поріг 80 для production-образів та 70 для staging. У випадку зниження індексу пайплайн падає й ескалює до security-команди.

Для тривалого зберігання історії метрик експортуйте hardening_index до Prometheus через node_exporter textfile collector, і ви отримаєте графік деградації безпеки у Grafana. Для глибшого аудиту дій користувачів комбінуйте Lynis із демоном auditd та правилами MITRE ATT&CK, а для контролю доступу застосунків з профілями AppArmor у режимі enforce.

Lynis проти OpenSCAP, Tiger та CIS-CAT

Lynis не єдиний інструмент аудиту. Розгляньмо ключові відмінності між найпопулярнішими сканерами хардненінгу.

Критерій	Lynis	OpenSCAP	Tiger	CIS-CAT Lite
Ліцензія	GPLv3	LGPLv2.1+	GPLv2	Пропрієтарна
Платформи	Linux, BSD, macOS, Solaris	Переважно RHEL/Fedora	Linux, BSD	Linux, Windows
Час сканування	2–5 хв	10–30 хв	5–10 хв	15–25 хв
Стандарти compliance	CIS, PCI-DSS (Enterprise)	CIS, STIG, PCI-DSS, HIPAA	(немає)	CIS Benchmarks
Інсталяція	git clone, без залежностей	пакет + SCAP-контент	пакет	JRE + jar
Кастомні тести	shell-скрипти у custom.d	XCCDF/OVAL XML	shell-скрипти	(немає)
CI/CD-дружність	Висока	Середня	Низька	Низька
Активна підтримка	Так, реліз 2026	Так	Слабка (2017)	Так

Мій вердикт. Lynis це найкращий вибір для щоденного хардненінгу, швидких аудитів та CI/CD-інтеграції. OpenSCAP виграє, коли потрібен формальний звіт відповідності STIG чи DISA: він має офіційні XCCDF-профілі від NIST та Red Hat. Tiger я вже не рекомендую, бо останній серйозний реліз був ще у 2017. CIS-CAT Lite використовуйте, якщо ваш аудитор вимагає саме офіційний CIS-звіт із сертифікованого інструменту. У реальній практиці я ставлю Lynis у CI і паралельно раз на квартал ганяю OpenSCAP для формального compliance-звіту, і це покриває обидва use-cases без дублювання.

Часті запитання

Чи безпечно запускати Lynis у production?

Так. Lynis виконує лише read-only операції: читає конфіги, перевіряє дозволи, виконує неінтрузивні команди типу ss, ps, find. Він не змінює систему, не перезавантажує сервіси й не відкриває портів. Безпечний для запуску навіть на критичних production-серверах у будь-який час доби.

Чи підтримує Lynis Kubernetes та контейнери?

Lynis сканує саме хост, на якому виконується. Для аудиту вузлів Kubernetes запускайте його як DaemonSet або через kubectl debug. Для перевірки самого кластера (RBAC, network policies, etcd) краще використовувати kube-bench від Aqua Security, бо він робить CIS Kubernetes Benchmark, чого Lynis не покриває.

Як зрозуміти, чи добрий мій Hardening Index?

Для свіжовстановленої Ubuntu/Debian типовий індекс 60–67, RHEL/Alma 65–70 завдяки SELinux. Production-сервери повинні мати ≥85, bastion-хости та DMZ ≥90, серверні робочі станції адмінів ≥75. Якщо індекс <60, система непридатна для відкритого інтернету.

Чи можна Lynis запускати без прав root?

Можна, використовуйте lynis audit system --pentest. У цьому режимі він пропустить тести, що потребують привілейованого доступу (читання /etc/shadow, iptables, audit rules), але виконає всі інші. Індекс буде нижчим через пропущені тести, проте це корисно для self-аудиту звичайними користувачами.

Як часто слід запускати Lynis на сервері?