Първото стартиране на Lynis на нов VPS обикновено дава около 60 и дълъг списък с препоръки, в който не е ясно откъде да се започне. Добрата новина: до 80–85 се стига за една вечер, а по-голямата част от пътя не е козметика, а наистина нужни неща. Лошата: последните петнадесет точки на наета виртуална машина изобщо не се получават и няма смисъл да се гонят.

Какво показва индексът и какво не

Hardening index е съотношението на преминатите тестове към общия им брой с тегла — а не процент на защитеност. 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 да се стартира не еднократно, а по график и отчетите да се пазят, за да има с какво да се сравнява. Как изглежда всичко това, събрано на една страница, показва демонстрацията по-долу: индексът, списъкът с предупреждения с идентификаторите на тестовете и това, което се е променило от миналото стартиране.