Świeżo zainstalowany serwer Debian to niezabezpieczona maszyna z domyślnymi ustawieniami — wystarczające do podstawowej pracy, ale niewystarczające dla serwera produkcyjnego. Hardening to proces systematycznego wzmacniania zabezpieczeń systemu. AI (Claude, ChatGPT) może być tu nieocenionym pomocnikiem — analizuje Twoją konfigurację i podaje konkretne zalecenia dostosowane do Twojego środowiska.

ℹ️ Jak używać AI do audytu konfiguracji serwera: Opisz modelowi AI swoją konfigurację: dystrybucja, wersja, uruchomione usługi, rola serwera (web, baza danych, VPN). Poproś o checklist hardening. Następnie wklej fragmenty plików konfiguracyjnych (np. /etc/ssh/sshd_config) i poproś o wskazanie konkretnych ustawień do zmiany. AI da Ci spersonalizowane zalecenia, a nie generyczny poradnik.

Krok 1 — Aktualizacje i unattended-upgrades

Podstawa każdego serwera: aktualny system. Włącz automatyczne aktualizacje bezpieczeństwa:

# Aktualizacja systemu:
sudo apt update && sudo apt upgrade -y

# Instalacja unattended-upgrades:
sudo apt install unattended-upgrades apt-listchanges -y

# Konfiguracja — włącz automatyczne poprawki bezpieczeństwa:
sudo dpkg-reconfigure -plow unattended-upgrades
# Wybierz "Yes" — system będzie automatycznie instalował
# aktualizacje bezpieczeństwa z debian-security

# Opcjonalnie — harmonogram (domyślnie raz dziennie):
# /etc/apt/apt.conf.d/20auto-upgrades
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
1

Hardening SSH — wyłącz root login

Root login przez SSH to jeden z największych wektorów ataków. Utwórz konto użytkownika z sudo, a następnie wyłącz bezpośrednie logowanie na root. Edytuj /etc/ssh/sshd_config.

# /etc/ssh/sshd_config — kluczowe ustawienia bezpieczeństwa:

# Wyłącz logowanie root przez SSH:
PermitRootLogin no

# Tylko uwierzytelnianie kluczem (wyłącz hasło):
PasswordAuthentication no
PubkeyAuthentication yes

# Zmień domyślny port (utrudnia ataki słownikowe):
Port 2222

# Ogranicz dostęp do konkretnych użytkowników:
AllowUsers twoj_uzytkownik deploy

# Limit prób logowania:
MaxAuthTries 3

# Wyłącz forwarding X11 jeśli nie potrzebujesz:
X11Forwarding no

# Restart SSH po zmianach (nie rozłączaj aktywnej sesji!):
sudo systemctl restart sshd
⚠️ Uwaga przed zmianą portu SSH: Upewnij się, że nowy port (np. 2222) jest otwarty w firewallu PRZED restartem SSH. W przeciwnym razie możesz stracić dostęp do serwera. Zawsze testuj nową konfigurację z otwartą zapasową sesją SSH.

Krok 2 — Firewall UFW

UFW (Uncomplicated Firewall) to przyjazny interfejs do iptables, domyślnie dostępny w Debian/Ubuntu:

# Instalacja i konfiguracja UFW:
sudo apt install ufw -y

# Domyślna polityka: blokuj wszystko przychodzące, zezwól wychodzące:
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Zezwól na SSH (użyj swojego portu!):
sudo ufw allow 2222/tcp comment "SSH"

# Typowe usługi webowe:
sudo ufw allow 80/tcp comment "HTTP"
sudo ufw allow 443/tcp comment "HTTPS"

# Włącz firewall:
sudo ufw enable

# Sprawdź status:
sudo ufw status verbose

Krok 3 — fail2ban

2

Instalacja i konfiguracja fail2ban

Fail2ban monitoruje logi i automatycznie blokuje adresy IP z wieloma nieudanymi próbami logowania. Szczególnie skuteczny przeciw atakom brute-force na SSH i panele administracyjne.

# Instalacja fail2ban:
sudo apt install fail2ban -y

# Utwórz lokalną konfigurację (nie edytuj jail.conf bezpośrednio!):
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

# Edytuj /etc/fail2ban/jail.local — sekcja [sshd]:
[sshd]
enabled = true
port = 2222
filter = sshd
logpath = /var/log/auth.log
maxretry = 5
bantime = 3600
findtime = 600

# Restart i weryfikacja:
sudo systemctl restart fail2ban
sudo fail2ban-client status sshd

Krok 4 — AppArmor i lynis audit

AppArmor to system obowiązkowej kontroli dostępu (MAC) wbudowany w Debian. Ogranicza co dany program może robić w systemie, nawet po jego skompromitowaniu. AppArmor jest domyślnie aktywny w Debian 11+:

# Sprawdź status AppArmor:
sudo aa-status

# Włącz profil w trybie enforce dla nginx:
sudo aa-enforce /etc/apparmor.d/usr.sbin.nginx

# Lynis — kompleksowy audyt bezpieczeństwa systemu:
sudo apt install lynis -y
sudo lynis audit system
# Lynis generuje raport z punktami do poprawy i sugerowanymi komendami
# Wynik "Hardening index" poniżej 70 oznacza znaczące luki

Krok 5 — Monitorowanie logów

Nawet doskonale zabezpieczony serwer wymaga monitorowania. Rekomendowane narzędzia:

  • logwatch — codzienne emailowe podsumowanie logów systemowych
  • auditd — szczegółowe logowanie akcji systemowych (kto, co, kiedy)
  • rkhunter — skanowanie w poszukiwaniu rootkitów
📷 Zrzut ekranu terminala z wynikami lynis audit — widoczny Hardening Index i lista rekomendacji z kategorii Authentication i Networking

Windows 11 i Windows Server — krótkie wskazówki

Jeśli zarządzasz też maszynami Windows, warto znać analogiczne mechanizmy. Dla Windows 11: włącz Windows Defender (aktywny domyślnie), skonfiguruj Windows Update na automatyczne instalowanie poprawek, wyłącz niepotrzebne usługi przez services.msc. Dla Windows Server: zastosuj CIS Microsoft Windows Server Benchmark (dostępny bezpłatnie na cis.org), włącz Windows Firewall i skonfiguruj Group Policy Security Baseline, monitoruj zdarzenia bezpieczeństwa przez Event Viewer (ID 4625 — nieudane logowania, ID 4624 — udane logowania).

📷 Porównanie narzędzi hardening: tabela Linux Debian (UFW, fail2ban, AppArmor, lynis) vs Windows Server (Defender, GPO, CIS Benchmark, Event Log)
⚠️ Nota informacyjna: Treści mają charakter edukacyjny. Wszelkie działania podejmujesz na własną odpowiedzialność. Przed zmianami w środowisku produkcyjnym wykonaj kopię zapasową.