Hardening Linux i audyt serwerów

Sprawdzam i wzmacniam konfigurację serwerów Linux, żeby środowisko było odporne na typowe błędy: hasło zamiast klucza SSH, usługę nasłuchującą na porcie, o którym nikt już nie pamięta, konto z uprawnieniami szerszymi, niż ktokolwiek świadomie nadał.

Dla kogo

Dla firm i zespołów technicznych utrzymujących serwery Linux, które chcą wiedzieć, że podstawy bezpieczeństwa zostały ustawione świadomie, nie tak, jak wyszło po instalacji dystrybucji.

Punkt startowy: audyt bez zmian

Zanim cokolwiek zamknę lub wyłączę, zbieram obraz środowiska: co faktycznie nasłuchuje, jakie usługi działają, kto i skąd się logował.

ss -tulnp
systemctl list-units --type=service --state=active
last
lastb
journalctl -u ssh

Bez tego kroku łatwo wyłączyć coś krytycznego albo przeoczyć realny wektor ataku. Serwer, który wygląda chaotycznie, często ma zależności, o których nikt już nie pamięta, dlatego etap kończy notatka ze stanem bazowym, do którego można wrócić po tygodniu pracy.

Co obejmuje

• SSH: wyłączenie logowania rootem i haseł, klucze zamiast haseł, ograniczenie AllowUsers, ocena sensowności fail2ban lub sshguard przy powtarzalnych próbach brute force.
• Minimalizacja usług: wyłączenie zbędnych demonów (typowo bluetooth, avahi-daemon, cups na serwerach headless), przegląd cron, at i timerów systemd pod kątem zapomnianych zadań.
• Uprawnienia: przegląd grupy sudo, wpisów ALL=(ALL) w sudoers, zamiana szerokich uprawnień na dostęp do konkretnych komend tam, gdzie to możliwe.
• Logowanie: auditd z regułami na zmiany w /etc/passwd i /etc/sudoers, persistentny log w journald, decyzja o centralnym odbiorcy logów poza serwerem.
• Aktualizacje: unattended-upgrades dla Debiana i Ubuntu albo odpowiednik dla dystrybucji RHEL-owych, tam gdzie środowisko na to pozwala.
• Raport: krótki opis wprowadzonych zmian, ryzyk, które zostały świadomie zaakceptowane, i zaleceń do dalszego utrzymania.

Kiedy przegląd ma sens

Typowy moment na audyt: przejęcie serwera po kimś innym, bez pełnej dokumentacji, z jednym zdaniem opisu “tam działa aplikacja”. Albo środowisko, które rosło latami, kilku administratorów wchodziło i wychodziło, a nikt już nie wie, które konta i klucze SSH są nadal potrzebne. W obu przypadkach pierwszy krok jest ten sam, żeby zobaczyć, gdzie w ogóle są klucze, zanim ktokolwiek zacznie je kasować:

find /home /root -name authorized_keys -type f -print

Widok z serwera i widok z zewnątrz często się różnią, dlatego audyt uzupełniam skanem z osobnej maszyny:

nmap -Pn -sV adres-serwera

Firewall, reverse proxy i reguły cloudowe potrafią zasłaniać usługi, które z poziomu samego hosta wyglądają na zamknięte.

Jak wygląda współpraca

Po audycie dostajesz listę ustaleń podzieloną na to, co wymaga zmiany od razu, i to, co może poczekać. Zmiany wchodzą w uzgodnionej kolejności, na stagingu albo w oknie serwisowym, nie hurtem na produkcji. Na końcu zostaje dokumentacja dla kolejnej osoby, która wejdzie do projektu.

Czego nie robię

Nie zmieniam portu SSH jako głównej ochrony, to security theater, nie hardening. Nie zamykam wszystkiego naraz na produkcji. Nie stawiam maksymalnej restrykcyjności ponad użyteczność środowiska: hardening to kompromis między bezpieczeństwem a wygodą pracy zespołu, cel to świadome decyzje, nie checklist do odfajkowania.

Efekt

Mniejsza powierzchnia ataku, przewidywalny dostęp administracyjny, czytelny zestaw zasad zamiast konfiguracji, którą trzeba za każdym razem odgadywać na nowo.

Zakres rozszerzony

Hardening łączę z monitoringiem Wazuh, gdy po audycie potrzebne są bieżące alerty na zmiany w systemie. Jeśli przegląd konfiguracji ma się powtarzać cyklicznie, na przykład przy każdym nowym hoście, część kroków da się przenieść do automatyzacji w N8N.