Pierwsze uruchomienie Lynisa na świeżym VPS-ie daje zwykle coś koło 60 i długą listę sugestii, w której nie wiadomo, za co się zabrać. Dobra wiadomość: 80–85 to praca jednego wieczoru, a większość kroków to nie kosmetyka, lecz rzeczy naprawdę potrzebne. Zła: ostatnich piętnastu punktów na wynajętej maszynie wirtualnej nie da się zdobyć, a gonienie za nimi to błąd.

Co wskaźnik pokazuje, a czego nie

Wskaźnik utwardzenia to ważony stosunek zdanych testów do wszystkich, a nie procent bezpieczeństwa. Lynis wykonuje około trzystu testów i zwraca dwie osobne listy: warnings — to, co wygląda na realny problem, oraz suggestions — to, co można poprawić. Zaczynać należy zawsze od ostrzeżeń; jest ich zwykle niewiele.

Stu punktów nie ma: część zaleceń wymaga decyzji podjętych przy instalacji systemu (osobne partycje dla /home, /tmp i /var), część — dostępu do programu rozruchowego, którego na VPS-ie nie ma, a część wzajemnie się wyklucza. Porównywanie własnego wskaźnika z cudzym też nie ma sensu: Lynis odejmuje punkty za to, co na maszynie działa. Każda uruchomiona usługa to kolejny otwarty port, własna konfiguracja i tuzin nowych sugestii — dlatego wysokie wartości spotyka się głównie tam, gdzie poza SSH nic nie działa. Dla serwera roboczego z witryną, bazą i pocztą 85 to dobry wynik.

Uruchamiać jako root

sudo lynis audit system

Bez sudo Lynis pominie wszystkie testy wymagające plików systemowych i pokaże zaniżony wskaźnik — nie dlatego, że serwer jest zły, lecz dlatego, że sprawdzeń nie było widać. Raport trafia do /var/log/lynis-report.dat, czytelny dziennik do /var/log/lynis.log.

Każdy wiersz wyniku zaczyna się identyfikatorem testu w rodzaju SSH-7408 albo KRNL-6000. Po tym identyfikatorze znajduje się i wyjaśnienie, i sposób wyłączenia testu — warto zapamiętać jego postać, wszystko dalsze kręci się wokół niej.

Co naprawdę rusza liczbę

SSH (SSH-7408). Najcięższy blok: jeden test sprawdza od razu tuzin parametrów. Nie należy zmieniać całego sshd_config — lepiej położyć osobny plik, żeby aktualizacja pakietu niczego nie zatarła:

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 przed przeładowaniem usługi jest obowiązkowe: błąd w konfiguracji przy żywej sesji zostawi nas na zewnątrz. A zanim wpiszemy PasswordAuthentication no, trzeba upewnić się, że klucz naprawdę działa — z drugiego, otwartego terminala.

Parametry jądra (KRNL-6000). Test sprawdza dwadzieścia kilka wartości sysctl. Plik dla nich:

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

Brakujące narzędzia. Sporą część sugestii da się streścić jako „zainstaluj to, czego nie ma”: auditd (dziennik zdarzeń systemowych), aide (integralność plików), debsums (integralność pakietów), unattended-upgrades (automatyczne aktualizacje bezpieczeństwa), sysstat i acct (rozliczanie procesów), skaner antywirusowy. Każde zamyka jedno–dwa zalecenia, ale instalować je warto nie dla punktów: bez nich po incydencie niczego się nie odtworzy.

Drobiazgi o dobrym stosunku wysiłku do efektu. umask 027 w /etc/login.defs; okresy ważności haseł w tym samym pliku; banery /etc/issue i /etc/issue.net; kompilatory dostępne tylko dla roota (chmod 700 /usr/bin/gcc). O banerach szczerze: dla bezpieczeństwa nie znaczą nic, to formalność prawna — ale punkt dają.

Jedna pułapka w login.defs

Zmiana umask przez podmianę wiersza sedem często zostawia w pliku kilka wierszy UMASK naraz. Lynis wtedy wartości nie zalicza, a test AUTH-9328 pozostaje czerwony, choć ustawienie z pozoru jest zrobione. Po edycji trzeba sprawdzić:

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

Powinien być dokładnie jeden. To samo dotyczy każdego innego parametru w tym pliku.

Fałszywe trafienia i jak je poprawnie wyciszyć

Niektóre ostrzeżenia nie dotyczą naszego serwera w ogóle. Przykład z życia: na VPS-ie jednego z dużych dostawców test PKGS-7388 zgłasza, że nie znaleziono repozytorium bezpieczeństwa — po prostu dlatego, że repozytoria opisano w formacie deb822 z odwołaniem do pliku serwerów lustrzanych, a Lynis szuka zwykłego wiersza. Aktualizacje bezpieczeństwa przy tym przychodzą bez zarzutu.

Wycisza się takie rzeczy nie kasowaniem wierszy z raportu, lecz profilem. Pliki profili mają rozszerzenie .prf (nie .prof — na tym łatwo stracić pół godziny), a własne reguły trafiają do /etc/lynis/custom.prf:

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

Jedna zasada: przy każdym wierszu powinien znaleźć się komentarz, dlaczego test jest pomijany. Za pół roku nie da się przypomnieć, czy wyłączono go dlatego, że nie dotyczy, czy dlatego, że naprawa była kłopotliwa — a różnica między tymi przypadkami to cała rzecz.

Czego nie robić

Nie gonić za liczbą. Wskaźnik łatwo napompować, wyłączając niewygodne testy, i powyżej pewnego poziomu to jedyna droga — tylko że serwer nie staje się przez to bezpieczniejszy. Pożyteczne jest co innego: zapisać własną wartość i śledzić jej zmiany. Wskaźnik, który spadł po aktualizacji albo po cudzej zmianie konfiguracji, to sygnał znacznie cenniejszy niż jego bezwzględna wysokość.

Właśnie dlatego Lynisa warto uruchamiać według harmonogramu, a nie jednorazowo, i zachowywać raporty, żeby było z czym porównywać. Jak to wygląda zebrane na jednej stronie, pokazuje demonstracja poniżej: wskaźnik, lista ostrzeżeń z identyfikatorami testów i to, co zmieniło się od poprzedniego uruchomienia.