Pierwszy audyt serwera Linux

Objęcie opieką nad istniejącym serwerem Linux rzadko zaczyna się od czystej dokumentacji i spokojnego wdrożenia. Częściej dostajesz adres IP, konto SSH, krótką informację “tam działa aplikacja” i oczekiwanie, że od teraz będziesz wiedzieć, co się dzieje.

Zastrzeżenie na start: ten tekst opisuje pierwszy przegląd serwera przejmowanego do standardowej administracji, nie procedurę po potwierdzonym włamaniu. Jeśli powodem przejęcia jest podejrzenie kompromitacji przez atakującego, priorytety są inne: containment, zabezpieczenie dowodów, ustalenie zakresu naruszenia i rotacja poświadczeń z zaufanego, odizolowanego systemu, zwykle zanim zacznie się cokolwiek “obserwować” na żywym hoście. Poniższe kroki zakładają spokojniejszy scenariusz: serwer działa, nikt nie zgłasza włamania, trzeba go tylko poznać. Przy takim przejęciu praktyczny zakres pracy zwykle zaczyna się od audytu i hardeningu serwera Linux.

Pierwsza zasada: nie zaczynaj od zmian. Zanim wyłączysz usługę, poprawisz konfigurację SSH albo zrobisz aktualizację pakietów, zbuduj obraz sytuacji. Serwer, który wygląda chaotycznie, może mieć zależności, o których nikt już nie pamięta.

Zapisz punkt startowy

Na początku warto zebrać podstawowe informacje o systemie i zapisać je w notatce. Nie musi to być od razu pełna dokumentacja. Chodzi o stan bazowy, do którego można wrócić po kilku dniach pracy.

hostnamectl
uname -a
lsb_release -a 2>/dev/null || cat /etc/os-release
uptime
df -h
free -h

Sprawdź też, czy serwer jest maszyną fizyczną, VPS-em, instancją cloudową czy kontenerem. Inaczej podchodzi się do backupu, sieci i awarii w każdej z tych sytuacji.

Dostęp i konta użytkowników

Najważniejsze pytanie brzmi: kto może wejść na serwer i w jaki sposób?

getent passwd
last
lastlog
sudo -l

sudo -l pokaże tylko uprawnienia użytkownika, którym jesteś zalogowany, a nie pełną listę osób z dostępem do sudo. Do rzeczywistego audytu potrzebny jest przegląd /etc/sudoers i /etc/sudoers.d/, sprawdzenie członków grup sudo/wheel, a jeśli serwer korzysta z uwierzytelniania przez LDAP albo SSSD, także tamtejszych źródeł tożsamości, bo lokalne grupy nie pokażą całego obrazu.

W praktyce interesują Cię konta z shellem, konta techniczne, użytkownicy w grupach sudo, wheel, docker oraz wszystkie miejsca, w których są klucze SSH.

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

Przy okazji przeglądu kluczy i dostępów warto od razu sprawdzić, czy w katalogach domowych, skryptach albo historii shella nie leżą zapomniane sekrety i tokeny dostępowe — to częsty ślad po poprzedniej ekipie, który łatwo przeoczyć, patrząc tylko na konta.

To szybki, ale niepełny test. AuthorizedKeysFile w sshd_config może wskazywać zupełnie inną lokalizację, katalogi domowe użytkowników nie muszą leżeć w /home, a dostęp może być realizowany przez AuthorizedKeysCommand albo certyfikaty SSH zamiast zwykłych kluczy publicznych. Wynik z find warto traktować jako punkt startowy, nie jako pełną listę dróg wejścia.

Nie usuwaj od razu starych kont tylko dlatego, że wyglądają podejrzanie. Najpierw ustal, czy nie są używane przez deployment, backup, monitoring albo integrację, której nikt nie opisał.

SSH bez teatralnych gestów

SSH jest zwykle pierwszym realnym punktem kontroli. Sprawdź konfigurację, ale nie zakładaj, że każda niestandardowa opcja oznacza natychmiastową katastrofę.

sshd -T | sort
grep -R "^[^#]" /etc/ssh/sshd_config /etc/ssh/sshd_config.d 2>/dev/null

Warto zwrócić uwagę na:

PermitRootLogin,
PasswordAuthentication,
PubkeyAuthentication,
AllowUsers lub AllowGroups,
nietypowy port SSH,
ograniczenia po adresach IP.

Zmiana SSH na produkcji wymaga ostrożności. Zostaw otwartą działającą sesję, sprawdź konfigurację przez sshd -t, a dopiero potem restartuj usługę.

Co nasłuchuje na zewnątrz

Następny krok to usługi i porty. Nie chodzi tylko o to, co jest otwarte w firewallu, ale też o procesy, które faktycznie nasłuchują.

ss -tulpen
systemctl list-units --type=service --state=running

Jeżeli widzisz port, którego nie rozpoznajesz, nie zgaduj. Sprawdź proces, ścieżkę binarki, unit systemd i ewentualne pliki konfiguracyjne.

systemctl status nazwa-uslugi
systemctl cat nazwa-uslugi
ps auxf

Dobrym uzupełnieniem jest spojrzenie z zewnątrz, na przykład z osobnej maszyny:

nmap -Pn -sV adres-serwera

Widok z serwera i widok z internetu często się różnią. Firewall, reverse proxy i reguły cloudowe mogą zasłaniać część usług, więc rozbieżność między obiema perspektywami jest normalna.

Same porty nasłuchujące to nie wszystko. Warto też sprawdzić aktywne połączenia wychodzące, bo nawet czysty wynik ss -tulpen nie wykluczy procesu, który sam nawiązuje połączenie na zewnątrz, na przykład do serwera C2:

ss -tupn
lsof -i -P -n | grep ESTABLISHED

Dobrze jest też rzucić okiem na podstawową konfigurację sieciową: tablicę routingu, ustawienia DNS i plik /etc/hosts, bo podmieniony wpis DNS albo dodatkowa trasa routingu to typowy ślad po wcześniejszej ingerencji, który łatwo przeoczyć, patrząc tylko na usługi.

ip route
cat /etc/resolv.conf
cat /etc/hosts

Kontenery i wirtualizacja

Jeśli na serwerze działa Docker albo Podman, to osobna warstwa infrastruktury, którą łatwo przeoczyć, patrząc tylko na systemctl i ss.

docker ps -a
docker images
docker network ls
podman ps -a

Sprawdź, które porty kontenerów są zmapowane na hosta, jakie wolumeny są zamontowane i czy w docker-compose.yml albo definicjach systemd nie ma zapomnianych zmiennych środowiskowych z sekretami. Kontener, który nikt nie aktualizował od dawna, jest tym samym ryzykiem co nieaktualny pakiet systemowy, tylko poza standardowym procesem apt/dnf.

Warto też sprawdzić, czy system ma włączone mechanizmy kontroli dostępu na poziomie jądra:

getenforce 2>/dev/null
aa-status 2>/dev/null

To nie jest jeszcze pełny hardening, tylko szybkie ustalenie punktu startowego: czy SELinux lub AppArmor są aktywne, czy ktoś je już dawno wyłączył i zapomniał włączyć z powrotem.

Aktualizacje i źródła pakietów

Przed aktualizacją sprawdź, z czego system korzysta. Dodatkowe repozytoria, stare PPA albo ręcznie instalowane paczki potrafią zaskoczyć bardziej niż sama dystrybucja.

Dla Debiana i Ubuntu:

apt update
apt list --upgradable
grep -R "^[^#]" /etc/apt/sources.list /etc/apt/sources.list.d 2>/dev/null

Dla RHEL, Rocky, AlmaLinux:

dnf check-update
dnf repolist

Jeżeli system jest bardzo stary, nie rób pełnego upgrade’u w ciemno. Najpierw sprawdź aplikację, wersje runtime, zależności i plan cofnięcia zmian.

Backup: nie pytaj, czy jest, sprawdź

Najgorsza odpowiedź na pytanie o backup brzmi “powinien być”. Backup istnieje dopiero wtedy, gdy wiadomo:

co jest backupowane,
gdzie trafia kopia,
jak długo jest trzymana,
kto ma do niej dostęp,
kiedy ostatnio wykonano restore.

Sprawdź crony, timery systemd, skrypty w katalogach administracyjnych i konfigurację usług backupowych.

crontab -l
ls -la /etc/cron.* /var/spool/cron 2>/dev/null
systemctl list-timers

Proste kopiowanie plików działającej bazy danych zwykle nie zapewnia spójnego backupu, silnik w trakcie zapisu może zostawić dane w niespójnym stanie. Potrzebny jest mechanizm wspierany przez dany silnik (na przykład pg_dump/pg_basebackup dla PostgreSQL, mysqldump albo xtrabackup dla MySQL) albo poprawnie skoordynowany snapshot na poziomie systemu plików czy wolumenu, nie sam cp czy rsync na żywym katalogu danych.

Logi i pierwsze sygnały problemów

Logi pokażą, czy serwer jest spokojny, czy tylko jeszcze nikt nie patrzył.

journalctl -p warning --since "24 hours ago"
journalctl -u ssh --since "7 days ago"

W przypadku usług webowych sprawdź błędy aplikacji, reverse proxy i statusy HTTP. Szukaj powtarzalnych wzorców: timeoutów, restartów, błędów logowania, problemów z dyskiem, OOM killerem, brakiem miejsca i błędami DNS.

dmesg -T | tail -100
grep -R "error\|failed\|timeout" /var/log 2>/dev/null | tail -100

Ten ostatni grep po całym /var/log to metoda awaryjna, dobra jako szybki, pierwszy rzut oka, nie standardowy krok na dużym serwerze z rozbudowanym logowaniem: przeszukanie wielu gigabajtów logów naraz bywa kosztowne i potrafi zalać ekran szumem zamiast go ograniczyć. Na większą skalę lepiej sprawdzają się journalctl z filtrami po czasie i priorytecie albo docelowy system centralnego zbierania logów.

Nie każdy błąd jest incydentem, ale powtarzalny błąd, którego nikt nie zna, jest kandydatem do wpisania w plan działań.

Monitoring i alerty

Serwer bez monitoringu działa do momentu, aż ktoś zauważy skutki awarii. Sprawdź, czy są agenci monitoringu, eksportery metryk, log forwarding albo chociaż podstawowe healthchecki. Gdy potrzebna jest widoczność zdarzeń bezpieczeństwa z wielu hostów, naturalnym kolejnym krokiem jest monitoring Wazuh i analiza zdarzeń.

systemctl list-units | grep -Ei "zabbix|wazuh|prometheus|node_exporter|telegraf|filebeat|vector"

Praktyczny przykład, jak taki pierwszy przegląd i domknięcie monitoringu może wyglądać na realnym serwerze, opisuję przy projekcie monitoring i hardening systemów Linux.

Dobry pierwszy zestaw obserwacji to:

dostępność usługi z zewnątrz,
użycie dysku,
load, CPU i pamięć,
restarty usług,
błędy 5xx,
logowania SSH,
status backupu.

Alert ma prowadzić do działania. Jeżeli mówi tylko, że “coś jest czerwone”, szybko stanie się szumem.

Dokumentuj decyzje, nie tylko stan

Po pierwszym przeglądzie warto przygotować krótką notatkę:

co działa na serwerze,
jakie porty są wystawione,
kto ma dostęp,
gdzie są dane i backupy,
jakie są ryzyka,
czego nie zmieniać bez testu,
jakie działania mają priorytet.

Najcenniejsza dokumentacja nie opisuje wszystkiego. Opisuje to, co następnej osobie pozwoli nie zgadywać.

Najważniejsze: tempo zmian

Objęcie serwera opieką to nie wyścig w naprawianiu wszystkiego pierwszego dnia. Najpierw obserwacja, potem małe zmiany, potem większe porządki, zwłaszcza jeśli serwer utrzymuje usługę produkcyjną. Gdy obraz sytuacji jest już jasny, naturalnym kolejnym krokiem jest systematyczny hardening Linux bez teatralnych gestów.

Dobry administrator nie poznaje systemu po tym, jak szybko wpisuje komendy. Poznaje go po tym, że wie, kiedy jeszcze nie powinien ich wpisywać.