← Wszystkie wpisy

Hardening Linux bez teatralnych gestów

Praktyczne podejście do wzmacniania systemów: konfiguracja, monitoring, logi i decyzje, które realnie zmniejszają ryzyko.


Hardening systemu Linux to nie jednorazowy checklist do odfajkowania i zapomnienia. To iteracyjny proces dopasowany do konkretnego środowiska — tego, co tam działa, kto ma dostęp i jakie ryzyka są realnie istotne.

Od czego zacząć

Pierwsza zasada: nie hardenuj w ciemno. Zanim zaczniesz zamykać porty i restrykcjonować uprawnienia, zbierz dane:

  • ss -tulnp — co faktycznie nasłuchuje i na jakich portach
  • systemctl list-units --type=service --state=active — jakie usługi działają
  • last, lastb, journalctl -u ssh — kto i skąd się logował

Bez tego bazowego obrazu możesz wyłączyć coś krytycznego albo zignorować faktyczne wektory ataku.

SSH — minimalna powierzchnia ataku

SSH to najczęstszy punkt wejścia. Trzy zmiany które robią największą różnicę:

# /etc/ssh/sshd_config
PermitRootLogin no
PasswordAuthentication no
AllowUsers twoj-uzytkownik

Klucze SSH zamiast haseł to podstawa. Jeśli środowisko tego wymaga, rozważ dodatkowo fail2ban albo sshguard do blokowania brute-force. Port-knocking jest efektowny, ale przez bezpieczeństwo przez ukrywanie — nie zastępuje solidnej konfiguracji.

Minimalizacja usług

Każda działająca usługa to potencjalny wektor ataku. Reguła jest prosta: jeśli nie wiesz po co coś działa, wyłącz to i sprawdź czy coś się posypało.

systemctl disable --now bluetooth
systemctl disable --now avahi-daemon
systemctl disable --now cups

Na serwerach headless większość tych usług jest zbędna. Sprawdź też cron, at i timery systemd — nieaktualne zadania to częsty zapomniany wejście.

Logowanie i monitoring

Hardening bez monitoringu to jak zamek bez alarmu — nie wiesz kiedy ktoś spróbował wejść. Minimum:

  • auditd z sensownymi regułami (zmiany w /etc/passwd, /etc/sudoers, logowania root)
  • journald z persistentnym logiem (/var/log/journal/)
  • Centralny odbiorca logów — jeśli serwer padnie lub zostanie skompromitowany, loki powinny być gdzie indziej

Wazuh jako SIEM nadaje się dobrze do środowisk gdzie chcesz korelować zdarzenia z wielu maszyn. Uruchomienie agenta na każdym serwerze daje widoczność której nie osiągniesz przez ręczne przeglądanie logów.

Uprawnienia i sudoers

Zasada minimalnych uprawnień: użytkownik ma dostęp tylko do tego, czego realnie potrzebuje.

# Sprawdź kto ma sudo
getent group sudo
grep -r 'ALL=(ALL)' /etc/sudoers /etc/sudoers.d/

# Ogranicz konkretne komendy
%devops ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart nginx

Unikaj NOPASSWD: ALL — to wygodne, ale niweluje sens oddzielnych kont.

Czego nie robić

  • Nie zmieniaj domyślnego portu SSH jako głównej ochrony — to security theater, nie hardening
  • Nie blokuj wszystkiego naraz na produkcji — testuj na stagingu
  • Nie ignoruj aktualizacji bezpieczeństwa — unattended-upgrades dla Debiana/Ubuntu to dobry punkt startowy

Hardening to kompromis między bezpieczeństwem a użytecznością. Cel to świadome decyzje, nie maksymalna restrykcyjność.