Hardenowanie VPS (Bezpieczeństwo i konfiguracja Linux VPS)

1. Przegląd koncepcji i problem systemowy

Bezpośrednio po inicjalizacji serwera wirtualnego (VPS) u dostawcy chmurowego (Hetzner, DigitalOcean, AWS) instancja trafia pod skanowanie globalnych botnetów w ciągu pierwszych 5–15 minut. Domyślnie wiele obrazów systemu operacyjnego ma włączoną autoryzację hasłową dla użytkownika root, otwarte porty serwisowe oraz brak podstawowej ochrony przed atakami brute-force.

Hardening VPS (Utwardzanie serwera) to inżynieryjny standard wzmacniania bezpieczeństwa systemu Linux zgodny z wytycznymi CIS Benchmarks (Center for Internet Security). Cele hardeningu:

• Minimalizacja powierzchni ataku (Attack Surface).
• Całkowite wykluczenie możliwości logowania się przez hasło za pośrednictwem niezabezpieczonych kanałów.
• Izolacja wykonywania procesów od konta superużytkownika (Root).
• Konfiguracja audytu zdarzeń, automatyczne łatanie luk zero-day (0-day) oraz filtrowanie pakietów na poziomie jądra.

Początkowy stan VPS (Wysokie ryzyko):
[Internet] ---> [Port 22: SSH (Root + Hasło)] ---> [Pełne przejęcie systemu]

Po wdrożeniu hardeningu (Obrona wielowarstwowa):
[Internet] ---> [Zapora UFW (Default Deny)]
                     |
                     v
                [Fail2ban (Blokowanie skanerów)]
                     |
                     v
                [SSH: Tylko klucze Ed25519, sudo bez Roota]
                     |
                     v
                [Automatyczne aktualizacje (unattended-upgrades)]

2. Taksonomia architektoniczna i model mentalny

Hardening jest wdrażany w czterech izolowanych płaszczyznach bezpieczeństwa:

1. Poziom uwierzytelniania i kontroli dostępu (Identity & Access):
   • Pełna dezaktywacja bezpośredniego logowania jako root przez SSH (PermitRootLogin no).
   • Zakaz uwierzytelniania hasłem (PasswordAuthentication no).
   • Utworzenie nieuprzywilejowanego użytkownika z obowiązkowym członkostwem w grupie sudo.
   • Instalacja kluczy kryptograficznych Ed25519.
2. Poziom sieciowy (Network Perimeter):
   • Włączenie ufw z polityką odrzucania wszystkich przychodzących pakietów (default deny incoming).
   • Otwarcie wyłącznie krytycznie niezbędnych portów (np. 2222/tcp, 80/tcp, 443/tcp).
   • Wdrożenie fail2ban do automatycznego banowania hostów generujących anomalie w żądaniach.
3. Poziom systemu operacyjnego i jądra (OS & Kernel):
   • Tuning parametrów sysctl w celu ochrony stosu sieciowego (zakaz przekierowań ICMP, ochrona przed atakami SYN-flood).
   • Włączenie rozszerzonych aktualizacji bezpieczeństwa (unattended-upgrades).
4. Poziom aplikacji i środowiska wykonawczego (Runtime Isolation):
   • Uruchamianie kontenerów Docker oraz agentów AI pod osobnymi, nieuprzywilejowanymi UID/GID bez dostępu do /var/run/docker.sock.

3. Pipeline techniczny i mechanika wewnętrzna

Krok 1. Tworzenie użytkownika sudo i deploy klucza SSH

Łącząc się z czystym serwerem przy użyciu tymczasowego hasła root, natychmiast tworzymy konto inżynierskie:

# Створення користувача deploy з домашньою директорією та zsh/bash
adduser --gecos "" deploy
usermod -aG sudo deploy

# Копіювання публічного ключа Ed25519
mkdir -p /home/deploy/.ssh
cp /root/.ssh/authorized_keys /home/deploy/.ssh/
chown -R deploy:deploy /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
chmod 600 /home/deploy/.ssh/authorized_keys

Krok 2. Hardening demona OpenSSH (/etc/ssh/sshd_config.d/99-hardening.conf)

Tworzymy izolowany plik konfiguracyjny SSH, aby zapobiec nadpisaniu podczas aktualizacji pakietów:

# Зміна порту (опціонально, але рекомендовано)
Port 2222

# Повна заборона root-доступу та паролів
PermitRootLogin no
PasswordAuthentication no
ChallengeResponseAuthentication no
KbdInteractiveAuthentication no

# Дозвіл виключно надійних криптографічних ключів
PubkeyAuthentication yes
AuthenticationMethods publickey

# Захист сесій від зависання
ClientAliveInterval 300
ClientAliveCountMax 2

# Відключення небезпечних функцій перенаправлення
X11Forwarding no
AllowTcpForwarding yes

Testowanie konfiguracji przed restartem usługi:

# Валідація синтаксису (якщо порожній вивід — конфіг коректний)
sudo sshd -t
sudo systemctl restart sshd

Krok 3. Konfiguracja parametrów jądra Linux (/etc/sysctl.d/99-security.conf)

# Захист від TCP SYN Flood атак
net.ipv4.tcp_syncookies = 1

# Заборона перенаправлення пакетів маршрутизації (захист від Man-in-the-Middle)
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0

# Ігнорування підроблених ICMP-відповідей
net.ipv4.icmp_echo_ignore_broadcasts = 1

# Заборона IP Source Routing
net.ipv4.conf.all.accept_source_route = 0

Zastosowanie zmian w jądrze bez konieczności restartu:

sudo sysctl --system

4. Praktyczne scenariusze inżynierskie w produkcji

01. Automatyczny Hardening przez Cloud-Init w Hetzner Cloud

Podczas tworzenia serwera wirtualnego przez Terraform lub panel zarządzania Hetzner przekazywany jest skrypt User Data (cloud-init). Serwer uruchamia się już z zamkniętym dostępem root, wcześniej utworzonym użytkownikiem, wygenerowanymi regułami UFW oraz skonfigurowanym SSH na niestandardowym porcie, co całkowicie eliminuje okno podatności w pierwszych minutach życia maszyny.

02. Automatyczna aktualizacja łatek bezpieczeństwa jądra bez ingerencji

Konfiguracja pakietu unattended-upgrades w Ubuntu:

sudo apt install unattended-upgrades update-notifier-common
sudo dpkg-reconfigure --priority=low unattended-upgrades

Serwer samodzielnie pobiera i instaluje krytyczne aktualizacje bezpieczeństwa z oficjalnych repozytoriów Security każdej nocy, a narzędzie needrestart automatycznie restartuje zagrożone usługi bez ponownego uruchamiania systemu operacyjnego.

03. Izolacja ruchu wewnętrznego demona Docker

Docker domyślnie próbuje wystawić porty na wszystkie interfejsy sieciowe (0.0.0.0). Podczas hardeningu plik /etc/docker/daemon.json jest konfigurowany z ograniczeniem domyślnej bindacji:

{
  "iptables": true,
  "live-restore": true,
  "userland-proxy": false
}

Gwarantuje to, że usługi bez jawnego mapowania na localhost pozostają wewnątrz wirtualnego mostka sieciowego Dockera i nie eksponują portów w publicznym internecie.

5. Pułapki, typowe błędy i bezpieczeństwo

1. Przypadkowe zablokowanie siebie (SSH Lockout): Najczęstszy błąd inżyniera: zamknięcie dostępu przez hasło i zakazanie logowania root, przy jednoczesnym zapomnieniu o sprawdzeniu, czy klucz publiczny działa dla nowego użytkownika lub czy nowy port jest dozwolony w UFW. Nigdy nie zamykaj początkowej sesji terminala, dopóki pomyślnie nie połączysz się w równoległej zakładce.
2. Przechowywanie hasła sudo w skryptach lub .bash_history: Użycie konstrukcji echo "password" | sudo -S ... w skryptach shellowych lub wpisywanie haseł w terminalu prowadzi do wycieku danych w jawnej postaci w historii poleceń. Używaj sudo visudo do delegowania konkretnych komend bez hasła (NOPASSWD) dla wyspecjalizowanych kont serwisowych CI/CD.
3. Ignorowanie bezpieczeństwa konsoli Out-of-band dostawcy: Nawet idealnie utwardzony serwer można skompromitować, jeśli konto w konsoli hostingowej (Hetzner Cloud Console, DigitalOcean Dashboard) jest chronione prostym hasłem bez sprzętowej dwuskładnikowej autoryzacji (2FA / WebAuthn). Dostęp do konsoli dostawcy jest równoważny z bezpośrednim dostępem fizycznym do płyty głównej serwera.