Перший запуск Lynis на свіжому VPS зазвичай дає щось близько 60 і довгий список рекомендацій, у якому незрозуміло, за що братися першим. Добра новина: 80–85 — робота на один вечір, і більшість кроків не косметичні, а справді варті того. Погана новина: останні п’ятнадцять балів недосяжні на орендованій віртуальній машині, і гнатися за ними — помилка.

Що індекс показує, а що ні

Індекс захищеності — це відношення пройдених тестів до загальної кількості, з вагами, а не відсоток безпеки. Lynis запускає близько трьохсот тестів і формує два окремі списки: warnings, які схожі на справжні проблеми, і suggestions — те, що можна було б покращити. Починають завжди з попереджень; їх зазвичай одиниці.

Ста балів не буває: частина рекомендацій вимагає рішень, ухвалених під час встановлення системи (окремі розділи для /home, /tmp та /var), частина потребує доступу до завантажувача, якого у VPS немає, а деякі суперечать одна одній. І порівнювати свій індекс із чужим немає сенсу: Lynis знімає бали за те, що працює на машині. Кожна запущена служба — це ще один відкритий порт, власна конфігурація і десяток нових рекомендацій, тому високі цифри частіше трапляються там, де не працює нічого, крім SSH. Для робочого сервера з сайтом, базою і поштою 85 — добрий результат.

Запускайте від root

sudo lynis audit system

Без sudo Lynis пропускає всі тести, яким потрібні системні файли, і повідомляє нижчий індекс — не тому, що сервер поганий, а тому, що перевірки були невидимі. Звіт пишеться у /var/log/lynis-report.dat, читабельний журнал — у /var/log/lynis.log.

Кожен рядок виводу починається з ідентифікатора тесту, як-от SSH-7408 чи KRNL-6000. Саме за цим ідентифікатором ви знаходите і пояснення, і спосіб вимкнути тест — запам’ятайте його форму, усе нижче крутиться навколо цього.

Що справді рухає число

SSH (SSH-7408). Найважчий блок: один тест перевіряє одразу десяток параметрів. Не редагуйте весь sshd_config; покладіть окремий файл, щоб оновлення пакета не стерло вашу роботу:

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 перед перезавантаженням служби обов’язковий: помилка в конфігурації, поки ваша сесія жива, залишить вас зовні. А перед тим як ставити PasswordAuthentication no, переконайтеся, що ключ справді працює — із другого відкритого термінала.

Параметри ядра (KRNL-6000). Тест перевіряє пару десятків значень sysctl. Файл для них:

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

Відсутні інструменти. Чимала частина рекомендацій — це просто «встановіть те, чого немає»: auditd (запис системних подій), aide (цілісність файлів), debsums (цілісність пакетів), unattended-upgrades (автоматичні оновлення безпеки), sysstat і acct (облік процесів), сканер шкідливого коду. Кожен закриває одну-дві рекомендації, але ставте їх не заради балів: без них після інциденту ви нічого не відновите.

Дрібниці з добрим співвідношенням зусиль і віддачі. umask 027 у /etc/login.defs; старіння паролів у тому самому файлі; банери в /etc/issue та /etc/issue.net; компілятори, доступні на читання лише root (chmod 700 /usr/bin/gcc). Про банери чесно: для безпеки вони не роблять нічого, це юридична формальність — але бал дають.

Одна пастка в login.defs

Правка umask заміною рядка через sed часто лишає у файлі одразу кілька рядків UMASK. Lynis тоді не зараховує значення, і тест AUTH-9328 лишається червоним, хоча налаштування начебто зроблено. Перевірте після правки:

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

Має бути рівно один. Те саме стосується будь-якого іншого параметра в цьому файлі.

Хибні спрацювання і як їх правильно вимкнути

Деякі попередження до вашого сервера не стосуються зовсім. Живий приклад: на VPS одного великого провайдера тест PKGS-7388 повідомляє, що репозиторій безпеки не знайдено, — просто тому, що репозиторії описані у форматі deb822 з посиланням на файл дзеркала, а Lynis шукає звичний рядок. Оновлення безпеки при цьому надходять чудово.

Вимикайте це не видаленням рядків зі звіту, а профілем. Файли профілів мають розширення .prf (не .prof — тут легко втратити півгодини), а власні правила йдуть у /etc/lynis/custom.prf:

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

Одне правило: біля кожного рядка потрібен коментар, чому тест пропущено. Через півроку ви не згадаєте, вимкнули його тому, що він не стосується справи, чи тому, що виправляти було надто клопітно, — а різниця між цими двома випадками і є весь сенс.

Чого не варто робити

Не женіться за числом. Індекс легко роздути, вимкнувши незручні тести, і після певного рівня це єдиний спосіб — тільки сервер від цього не стає ні на йоту безпечнішим. Корисне інше: зафіксуйте власне значення і стежте за його змінами. Індекс, який просів після оновлення або після чужої правки в конфігурації, — значно цінніший сигнал, ніж його абсолютна величина.

Саме тому Lynis варто запускати за розкладом, а не одноразово, зберігаючи звіти, щоб було з чим порівняти. Який вигляд це має зібраним на одній сторінці, показує демо нижче: індекс, список попереджень з ідентифікаторами тестів і те, що змінилося з попереднього запуску.