Language: pl

Bezpieczeństwo VPS od podstaw: klucze SSH, zapora i Fail2ban

Nowego VPS nie należy uznawać za bezpieczny od razu po zainstalowaniu Ubuntu. Zanim skonfigurujesz dostęp, serwer jest już widoczny dla skanerów: próbują haseł SSH, szukają wystawionych paneli administracyjnych i sprawdzają typowe luki. W tym poradniku omawiamy podstawowe kroki zabezpieczenia VPS od zera: utworzenie osobnego użytkownika, konfigurację uwierzytelniania kluczem SSH, ograniczenie portów sieciowych za pomocą UFW oraz dodanie Fail2ban. Wszystkie kroki działają na Ubuntu 22.04 i 24.04, gdy polecenia wykonuje użytkownik z uprawnieniami sudo.

Zanim zaczniesz: spisz porty

Nie otwieraj portów „na wszelki wypadek”. Typowy serwer WWW potrzebuje:

• 22/tcp — SSH; najlepiej ograniczyć go po adresie IP albo przenieść na inny port, ale tylko jako dodatkowe zabezpieczenie;
• 80/tcp — HTTP; zwykle potrzebny do przekierowania na HTTPS i walidacji certyfikatu;
• 443/tcp — HTTPS.

Port aplikacji, taki jak 3000, 8080 lub 9000, nie powinien być dostępny z internetu, jeśli przed aplikacją działa Nginx albo Caddy. Przypisz aplikację do 127.0.0.1 albo zezwól na jej port tylko w sieci wewnętrznej. Najpierw sprawdź, co nasłuchuje na serwerze:

sudo ss -tulpn

Po zainstalowaniu Dockera sprawdź osobno jego reguły iptables: publikacja -p 3000:3000 może udostępnić port poza zakładanym układem. W przypadku publicznej usługi bezpieczniej użyć proxy HTTPS i ukryć port wewnętrzny.

Krok 1. Zaktualizuj system i utwórz administratora

Połącz się z VPS-em przy użyciu otrzymanych danych logowania i zainstaluj aktualizacje:

sudo apt update
sudo apt full-upgrade -y
sudo apt install -y ufw fail2ban unattended-upgrades

Utwórz osobistego użytkownika. Zastąp alex własną nazwą:

sudo adduser alex
sudo usermod -aG sudo alex

Nie usuwaj pierwotnego dostępu, dopóki nie przetestujesz nowego konta w osobnym oknie terminala. To ważna zasada: błąd w konfiguracji SSH łatwiej naprawić, gdy bieżąca sesja nadal jest otwarta.

Krok 2. Utwórz klucz SSH i zainstaluj go na serwerze

Na komputerze z Linuxem, macOS-em lub Windows PowerShell uruchom:

ssh-keygen -t ed25519 -C "alex@my-computer"

Naciśnij Enter, aby zapisać klucz w domyślnym pliku, a następnie ustaw hasło klucza. Nigdy nie wysyłaj klucza prywatnego na czacie, nie umieszczaj go w repozytorium ani nie kopiuj na VPS. Na serwer należy przesłać wyłącznie plik z rozszerzeniem .pub:

ssh-copy-id alex@SERVER_IP

Jeśli ssh-copy-id nie jest dostępne, wyświetl klucz publiczny poleceniem Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub w PowerShell, a następnie dodaj go na serwerze:

sudo install -d -m 700 -o alex -g alex /home/alex/.ssh
sudo nano /home/alex/.ssh/authorized_keys
sudo chown alex:alex /home/alex/.ssh/authorized_keys
sudo chmod 600 /home/alex/.ssh/authorized_keys

Wklej klucz w jednym wierszu i przetestuj logowanie przed wyłączeniem haseł:

ssh alex@SERVER_IP
sudo whoami

Oczekiwanym wynikiem ostatniego polecenia jest root. Jeśli klient SSH nie może znaleźć klucza, wskaż go jawnie: ssh -i ~/.ssh/id_ed25519 alex@SERVER_IP.

Krok 3. Wyłącz logowanie roota i uwierzytelnianie hasłem

Utwórz kopię konfiguracji SSH:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
sudo nano /etc/ssh/sshd_config

Upewnij się, że plik zawiera następujące parametry:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
KbdInteractiveAuthentication no
MaxAuthTries 3

W Ubuntu ustawienia mogą znajdować się w /etc/ssh/sshd_config.d/*.conf, dlatego sprawdź efektywną konfigurację:

sudo sshd -t
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|pubkeyauthentication|maxauthtries'

Jeśli sshd -t zgłosi błąd, nie restartuj usługi, dopóki nie poprawisz składni. Gdy test zakończy się pomyślnie, zastosuj ustawienia:

sudo systemctl reload ssh

Pozostaw stare połączenie SSH otwarte i przetestuj logowanie kluczem w nowym oknie. Wyłączenie haseł bez sprawdzonego klucza to najczęstszy sposób na utratę dostępu do serwera.

Krok 4. Skonfiguruj UFW bez blokowania SSH

UFW to wygodna nakładka na reguły sieciowe Linuksa. Najpierw ustaw bezpieczne wartości domyślne, a następnie zezwól na port SSH i porty WWW:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp comment 'SSH'
sudo ufw allow 80/tcp comment 'HTTP'
sudo ufw allow 443/tcp comment 'HTTPS'
sudo ufw enable

Potwierdź aktywację dopiero po dodaniu reguły SSH. Sprawdź wynik:

sudo ufw status verbose
sudo ufw status numbered

Jeśli masz stały biurowy adres IP, możesz ograniczyć SSH do tego adresu:

sudo ufw delete allow 22/tcp
sudo ufw allow from YOUR.PUBLIC.IP to any port 22 proto tcp comment 'SSH office'

Używaj tej opcji tylko przy stałym IP i dostępie do konsoli dostawcy: jeśli adres się zmieni, możesz zablokować sobie dostęp.

Jak tymczasowo otworzyć port aplikacji

Jeśli musisz bezpośrednio sprawdzić usługę, utwórz regułę z ograniczonym źródłem:

sudo ufw allow from YOUR.PUBLIC.IP to any port 8080 proto tcp

Po teście usuń ją, korzystając z numeru wyświetlonego przez ufw status numbered:

sudo ufw delete RULE_NUMBER

Nie używaj sudo ufw allow 1:65535/tcp: taka reguła zamienia zaporę w czystą formalność.

Krok 5. Włącz Fail2ban dla SSH

Fail2ban analizuje logi i po kilku nieudanych próbach logowania dodaje tymczasową regułę blokującą. Nie zastępuje kluczy SSH ani zapory, ale ogranicza szum generowany przez automatyczne próby łamania haseł.

Utwórz lokalną konfigurację, aby aktualizacje pakietu nie nadpisały Twoich ustawień:

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local

Ustaw rozsądne wartości w sekcji [DEFAULT]:

[DEFAULT]
bantime = 1h
findtime = 10m
maxretry = 5
backend = systemd
banaction = ufw

[sshd]
enabled = true
port = 22

Uruchom usługę i sprawdź jail:

sudo systemctl enable --now fail2ban
sudo fail2ban-client status
sudo fail2ban-client status sshd

W wynikach dla sshd sprawdź liczbę nieudanych prób i zablokowanych adresów. Nie dodawaj własnego IP do listy blokad. Aby utworzyć stały wyjątek, użyj ignoreip = 127.0.0.1/8 YOUR.PUBLIC.IP w sekcji [DEFAULT].

Krok 6. Włącz automatyczne aktualizacje

Automatyczne aktualizacje są przydatne dla pakietów bezpieczeństwa, ale restartów jądra nadal trzeba pilnować:

sudo dpkg-reconfigure -plow unattended-upgrades
sudo systemctl status unattended-upgrades

Raz w tygodniu sprawdź, czy wymagany jest restart:

test -f /var/run/reboot-required && echo 'Требуется перезапуск'

Przed ręcznym restartem upewnij się, że masz działający klucz i dostęp do konsoli VPS. Po ponownym uruchomieniu sprawdź usługi aplikacji, Nginx, UFW i Fail2ban.

Krok 7. Sprawdź wynik z zewnątrz

Sprawdź ochronę z innego komputera, a nie tylko przez odczyt konfiguracji:

ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no alex@SERVER_IP

Polecenie powinno zakończyć się odmową. Osobno przetestuj działające logowanie kluczem:

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 alex@SERVER_IP

Na VPS-ie sprawdź adresy nasłuchu i reguły:

sudo ss -lntup
sudo ufw status numbered
sudo fail2ban-client status sshd

Port aplikacji powinien nasłuchiwać na 127.0.0.1, jeśli nie jest przeznaczony do bezpośredniego dostępu. Z zewnętrznego hosta możesz użyć nmap SERVER_IP, ale skanuj wyłącznie własny serwer: sprawdzanie cudzej infrastruktury bez pozwolenia może naruszać prawo i zasady dostawcy.

Kopie zapasowe i odzyskiwanie

Ochrona SSH nie chroni przed usunięciem danych, błędem administratora ani przejęciem aplikacji. Przechowuj kopie bazy danych, konfiguracji i plików użytkowników poza VPS-em. Minimalny zestaw to codzienna kopia, kilka wersji z poprzednich dni oraz okresowe testy odtwarzania.

Nie zapisuj haseł ani tokenów w skryptach jawnym tekstem. Jeśli sekret zostanie ujawniony, natychmiast go unieważnij i utwórz nowy.

Jak wybrać VPS dla bezpiecznego projektu

Bezpieczeństwo zaczyna się od kontroli nad infrastrukturą. Na VPS-ie możesz samodzielnie wybrać system operacyjny, reguły zapory, sposób dostępu, kopie zapasowe i rozmieszczenie usług. W przypadku małej strony lub API stabilna sieć, pamięć SSD i konsola odzyskiwania są ważniejsze niż nadmiar wirtualnych rdzeni.

Uruchamiając projekt na VPS-ie w tropic.host, z góry określ jego publiczne punkty wejścia: w większości przypadków wystarczą SSH, HTTP i HTTPS. Bazę danych i panele administracyjne trzymaj w sieci wewnętrznej. Wraz z rozwojem projektu osobne instancje VPS dla aplikacji, bazy danych i monitoringu pomagają odizolować obszary awarii.

Typowe błędy

• Wyłączenie haseł przed przetestowaniem logowania kluczem. Pozostaw bieżącą sesję otwartą i sprawdź nowe logowanie osobno.
• Pozostawienie 22/tcp otwartego dla całego świata, gdy można zezwolić na dostęp tylko z zaufanych adresów.
• Bezpośrednie publikowanie portów Dockera. Najpierw sprawdź reguły Dockera i UFW.
• Zainstalowanie Fail2ban bez późniejszego sprawdzania logów. Po zmianach kontroluj journalctl -u ssh i stan jail.

Podsumowanie

Podstawowa ochrona VPS nie zajmuje wiele czasu, jeśli kroki wykonasz we właściwej kolejności: utwórz osobnego użytkownika, zainstaluj klucz SSH, sprawdź dostęp, wyłącz logowanie roota i hasła, włącz UFW, skonfiguruj Fail2ban oraz automatyczne aktualizacje. Następnie dodaj kopie zapasowe, logowanie i monitoring zewnętrzny.

Te kroki nie czynią serwera całkowicie odpornym na ataki, ale eliminują najczęstsze błędy początkowej konfiguracji. Kolejnym etapem jest dostosowanie profilu bezpieczeństwa do konkretnej aplikacji: aktualizowanie zależności, ograniczenie uprawnień usług, ochrona paneli administracyjnych i regularne sprawdzanie otwartych portów.

FAQ

Czy muszę zmienić domyślny port SSH?

Niekoniecznie. Zmiana portu ogranicza automatyczny szum, ale nie zastępuje kluczy, wyłączonych haseł, UFW ani Fail2ban. Jeśli zmienisz port, zaktualizuj regułę zapory oraz parametr port w jailu Fail2ban.

Co zrobić, jeśli po konfiguracji UFW stracę dostęp?

Użyj internetowej konsoli dostawcy albo konsoli ratunkowej, a następnie sprawdź regułę SSH i konfigurację sshd. Nie zamykaj starej działającej sesji, dopóki nie potwierdzisz nowego logowania.

Czy Fail2ban wystarczy do ochrony SSH?

Nie. Fail2ban reaguje na nieudane logowania, które już nastąpiły. Fundamentem powinny być klucze SSH, wyłączone uwierzytelnianie hasłem, minimalne uprawnienia użytkowników i ograniczona zapora.

Czy mogę zezwolić na SSH tylko z jednego adresu IP?

Tak, jeśli adres jest stały: dodaj regułę UFW allow from dla tego IP. Z wyprzedzeniem zapewnij dostęp do konsoli dostawcy albo inną metodę awaryjną, ponieważ po zmianie adresu połączenie zostanie zablokowane.

Jak często sprawdzać bezpieczeństwo VPS?

Po każdej zmianie SSH, zapory lub publikowania portów Dockera wykonaj sprawdzenie portów i przetestuj logowanie. W ramach rutynowej konserwacji przeglądaj aktualizacje i logi co najmniej raz w tygodniu, a odzyskiwanie z kopii zapasowej testuj regularnie.