Zabezpiecz swój VPS: lista kontrolna na pierwsze 10 minut

Napisane przez zespół ApexVPS • Ostatnia aktualizacja: lipiec 2026 • 9 min czytania

Świeży VPS z Linuksem jest skanowany przez zautomatyzowane boty w ciągu kilku minut od uruchomienia, więc najmądrzejszym pierwszym ruchem jest przejście przez krótką, powtarzalną listę kontrolną zabezpieczania VPS przed instalacją czegokolwiek innego. Ten przewodnik to właśnie ta lista: praktyczna rutyna na pierwsze 10 minut, którą możesz zastosować na dowolnym nowym serwerze Ubuntu lub Debian, aby utworzyć użytkownika nie-root, zabezpieczyć SSH, włączyć zaporę i zamknąć drzwi przed atakami brute-force. Każde polecenie poniżej jest standardowe i bezpieczne do skopiowania, a żadne nie wymaga specjalnych narzędzi — wystarczy terminal i kilka minut.

Wykonuj kroki w kolejności. Każdy opiera się na poprzednim, a na końcu będziesz mieć serwer znacznie trudniejszy do włamania niż domyślny obraz, od którego zaczynałeś.

Po co ten pośpiech? Publiczna przestrzeń IPv4 jest skanowana ciągle. Wyszukiwarki urządzeń podłączonych do internetu, wraz z niezliczonymi botnetami, katalogują nowe hosty i próbują domyślnych danych logowania przez całą dobę. Odstęp między "serwer jest online" a "serwer jest atakowany" mierzy się w minutach, nie dniach. Spędzenie dziesięciu skoncentrowanych minut na tych podstawach usuwa Cię z puli łatwych celów, na których żerują zautomatyzowane narzędzia, i nie kosztuje niczego poza Twoją uwagą.

Zanim zaczniesz

Będziesz potrzebować dostępu SSH do swojego nowego serwera oraz adresu IP, który dostawca wysłał Ci e-mailem. W ApexVPS każdy plan obejmuje pełny dostęp root, więc możesz samodzielnie przeprowadzić cały proces zabezpieczania. Otwórz terminal i połącz się jako root (lub jako domyślny użytkownik utworzony przez obraz systemu):

ssh root@your_server_ip

Jedna zasada jest ważniejsza niż wszystkie inne: nigdy nie wyłączaj metody logowania, dopóki nie potwierdzisz, że nowa działa. Pozostaw pierwszą sesję SSH otwartą podczas testowania drugiej. Jeśli coś pójdzie nie tak, otwarta sesja będzie Twoją siatką bezpieczeństwa.

Krok 1 — Zaktualizuj system

Zaktualizowane oprogramowanie to podstawa każdej listy kontrolnej zabezpieczeń VPS. Zacznij od odświeżenia indeksu pakietów i zainstalowania najnowszych poprawek bezpieczeństwa:

sudo apt update && sudo apt upgrade -y

Na świeżym obrazie systemu często to pociąga za sobą wiele aktualizacji, w tym jądra i OpenSSH. Jeśli jądro zostało zaktualizowane, zaplanuj restart za pomocą sudo reboot po zakończeniu reszty listy kontrolnej.

Krok 2 — Utwórz użytkownika niebędącego rootem z uprawnieniami sudo

Logowanie bezpośrednio jako root jest ryzykowne: pojedyncza błędna komenda wykonuje się z nieograniczonymi uprawnieniami, a root to pierwsze konto, które próbuje złamać każdy atakujący. Utwórz dedykowanego użytkownika i przyznaj mu prawa administracyjne przez sudo:

adduser deploy
usermod -aG sudo deploy

Pierwsza komenda tworzy konto i prosi o hasło; druga dodaje je do grupy sudo. Zamień deploy na dowolną nazwę, którą lubisz. Odtąd loguj się jako ten użytkownik i podnoś uprawnienia do root tylko wtedy, gdy konkretna komenda tego wymaga.

Krok 3 — Skonfiguruj uwierzytelnianie kluczem SSH

Hasła można odgadnąć; klucze SSH praktycznie nie. Wygeneruj nowoczesną parę kluczy Ed25519 na swoim lokalnym komputerze (nie na serwerze):

ssh-keygen -t ed25519 -C "[email protected]"

Zaakceptuj domyślną lokalizację i, najlepiej, ustaw hasło (passphrase). Następnie skopiuj publiczną część klucza do swojego nowego użytkownika na serwerze:

ssh-copy-id deploy@your_server_ip

Jeśli ssh-copy-id jest niedostępne, utwórz katalog i plik ręcznie na serwerze, wklej swój klucz publiczny do ~/.ssh/authorized_keys i popraw uprawnienia:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Teraz otwórz nowy terminal i potwierdź, że możesz zalogować się bez hasła: ssh deploy@your_server_ip. Nie przechodź dalej, dopóki to nie zadziała — kolejny krok od tego zależy.

Krok 4 — Zablokuj SSH: wyłącz logowanie root i hasła

Po sprawdzeniu logowania kluczem, wyłącz słabsze opcje. Edytuj konfigurację demona SSH:

sudo nano /etc/ssh/sshd_config

Ustaw (lub odkomentuj i zmień) te trzy dyrektywy:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

Zweryfikuj plik przed zastosowaniem, a następnie zrestartuj usługę:

sudo sshd -t
sudo systemctl restart ssh

Kontrola sshd -t wyłapuje literówki, które mogłyby Cię zablokować. Po restarcie przetestuj nowe połączenie w osobnym terminalu. Logowanie root przez SSH i zgadywanie haseł są teraz wykluczone.

Zmień port SSH (opcjonalnie)

Przeniesienie SSH z portu 22 nie powstrzyma zdeterminowanego atakującego, ale ukryje Cię przed ciągłym hałasem botów, które skanują tylko domyślny port. Jeśli chcesz to zrobić, dodaj linię taką jak Port 2222 do /etc/ssh/sshd_config. Ważne: otwórz nowy port w zaporze ogniowej (następny krok) przed restartem SSH, w przeciwnym razie zostaniesz zablokowany.

Krok 5 — Włącz zaporę ogniową za pomocą UFW

Zapora ogniowa zapewnia, że tylko porty, które zamierzasz wystawić, są osiągalne. Ubuntu i Debian mają wbudowane UFW (Uncomplicated Firewall), które jest dokładnie tym, co obiecuje nazwa. Ustaw rozsądną domyślną politykę i zezwól na SSH przed włączeniem:

sudo apt install ufw -y
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw enable
sudo ufw status verbose

Profil OpenSSH otwiera port 22. Jeśli przeniosłeś SSH w poprzednim kroku, zezwól na nowy port zamiast tego za pomocą sudo ufw allow 2222/tcp. Prowadzisz stronę internetową? Dodaj HTTP i HTTPS:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Wszystko inne pozostaje domyślnie zamknięte, co jest dokładnie tym, czego chcesz na publicznym serwerze.

Krok 6 — Zainstaluj fail2ban, aby zatrzymać ataki brute force

Nawet z wymuszonymi kluczami atakujący będą nadal bombardować Twój port SSH. fail2ban monitoruje logi i tymczasowo banuje adresy IP, które zbyt wiele razy zawiodą. Zainstaluj i włącz go:

sudo apt install fail2ban -y
sudo systemctl enable --now fail2ban

Aby dostosować reguły, skopiuj domyślną konfigurację do lokalnego nadpisania, aby aktualizacje nigdy nie nadpisały Twoich zmian, a następnie edytuj ją:

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

W sekcji [sshd] możesz dostroić wartości, takie jak maxretry i bantime. Przeładuj za pomocą sudo systemctl restart fail2ban i sprawdź, kto aktualnie przebywa w więzieniu, używając sudo fail2ban-client status sshd.

Krok 7 — Włącz automatyczne aktualizacje zabezpieczeń

Luki w zabezpieczeniach są odkrywane bez przerwy, a te najbardziej bolesne to poprawki, których nigdy nie zastosowałeś. Pakiet unattended-upgrades instaluje ważne aktualizacje za Ciebie zgodnie z harmonogramem:

sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure -plow unattended-upgrades

Wybierz „Tak”, gdy zostaniesz o to poproszony, a Ubuntu lub Debian po cichu zastosuje aktualizacje zabezpieczeń w tle. Ten pojedynczy krok zamyka lukę między ujawnieniem podatności a ochroną Twojego serwera.

Krok 8 — Wyłącz nieużywane usługi i podstawowe wzmacnianie

Każda usługa nasłuchująca w sieci to potencjalna droga wejścia, więc usuń wszystko, czego nie potrzebujesz. Sprawdź, co faktycznie działa i co jest powiązane z portem:

sudo systemctl list-units --type=service --state=running
sudo ss -tulpn

Jeśli zauważysz usługę, której nie używasz, wyłącz ją i zatrzymaj:

sudo systemctl disable --now <service-name>

Kilka szybkich poprawek dopełnia listę kontrolną:

• Utrzymuj dokładny zegar — wiarygodne znaczniki czasu sprawiają, że logi są godne zaufania; timedatectl potwierdza, że synchronizacja czasu jest aktywna.
• Przejrzyj dostęp sudo — tylko konta, które naprawdę potrzebują roota, powinny być w grupie sudo.
• Czytaj swoje logi — sudo journalctl -u ssh pokazuje dokładnie, kto pukał do Twoich drzwi.

Aby uzyskać głębszy, frameworkowy przegląd bezpiecznej konfiguracji, Fundacja OWASP publikuje powszechnie szanowane wytyczne dotyczące wzmacniania i bezpieczeństwa, które warto dodać do zakładek, gdy Twoja konfiguracja się rozrasta.

Twoja 10-minutowa lista kontrolna w pigułce

Trzymaj to podsumowanie pod ręką — to cała procedura zabezpieczania VPS w formie listy kontrolnej, którą możesz powtórzyć w kilka minut na każdym nowym serwerze, który wznosisz:

1. Zaktualizuj wszystkie pakiety i uruchom ponownie, jeśli zmieniło się jądro.
2. Utwórz użytkownika niebędącego rootem i dodaj go do grupy sudo.
3. Wygeneruj klucz SSH Ed25519 i skopiuj klucz publiczny na serwer.
4. Potwierdź, że logowanie oparte na kluczu działa w drugim terminalu.
5. Wyłącz logowanie roota i uwierzytelnianie hasłem w sshd_config.
6. Opcjonalnie przenieś SSH na niestandardowy port.
7. Włącz UFW, domyślnie blokuj przychodzące połączenia i zezwól tylko na porty, których używasz.
8. Zainstaluj fail2ban, aby automatycznie blokować próby brute-force.
9. Włącz automatyczne aktualizacje zabezpieczeń.
10. Wyłącz nieużywane usługi i sprawdź, co nasłuchuje.

Żaden z tych kroków nie jest trudny sam w sobie, ale pominięcie któregokolwiek pozostawia oczywistą lukę. Wykonane razem tworzą solidną podstawę, która powstrzymuje przytłaczającą większość oportunistycznych ataków. Od tego momentu możesz dodawać rozszerzenia w miarę rozwoju potrzeb — odwrotne proxy z TLS, narzędzie do wykrywania włamań, izolację usług za pomocą kontenerów lub własną kopię zapasową poza serwerem, oprócz snapshotów dostawcy.

Jak ApexVPS uzupełnia Twoje wzmacnianie

Powyższa lista kontrolna wzmacnia system operacyjny, ale niektóre zagrożenia czają się poniżej. Ataki wolumetryczne i awarie sprzętu są obsługiwane na poziomie infrastruktury, i to właśnie tutaj znaczenie ma Twój dostawca. Każdy plan ApexVPS obejmuje zawsze włączoną ochronę DDoS, dzięki czemu fala ruchu jest pochłaniana, zanim dotrze do Twojej zapory, oraz automatyczne kopie zapasowe — codzienne w Starter Pro i godzinne snapshoty w Business i Enterprise — więc błąd lub kompromitacja nigdy nie oznacza zaczynania od zera. Całodobowe monitorowanie i prawdziwie dedykowane CPU i RAM oznaczają, że hałaśliwy sąsiad nie może Cię spowolnić ani stać się Twoim problemem.

Pełną listę zabezpieczeń znajdziesz w przeglądzie funkcji ApexVPS, a porównanie poszczególnych planów na stronie planów VPS i cen. Jeśli wzmacniasz serwer pod własne aplikacje, nasz przewodnik po self-hostingu VPS świetnie uzupełni tę listę kontrolną. Rejestracja wymaga tylko adresu e-mail, a płatność odbywa się wyłącznie kryptowalutami przez OxaPay — Bitcoin, Ethereum, USDT i ponad 30 innych monet, bez karty kredytowej, konta bankowego i KYC.

Często zadawane pytania

Co zrobić w pierwszej kolejności, aby zabezpieczyć nowy VPS?

Zaktualizuj wszystkie pakiety za pomocą sudo apt update && sudo apt upgrade -y, a następnie utwórz użytkownika bez uprawnień root z prawami sudo, aby przestać logować się jako root. Te dwa kroki zamykają najczęstsze i najbardziej szkodliwe ścieżki ataków, zanim skonfigurujesz cokolwiek innego.

Czy powinienem zmienić domyślny port SSH?

To opcjonalne. Przeniesienie SSH z portu 22 ogranicza liczbę automatycznych skanów w logach, ale samo w sobie nie jest realnym zabezpieczeniem — klucze autoryzacyjne, firewall i fail2ban robią całą ciężką robotę. Jeśli zmienisz port, otwórz nowy w UFW przed restartem SSH, aby nie zablokować sobie dostępu.

Czy nadal potrzebuję firewalla, jeśli używam kluczy SSH?

Tak. Klucze SSH chronią tylko serwis SSH; firewall taki jak UFW kontroluje każdy inny port na maszynie. Domyślne blokowanie całego ruchu przychodzącego i zezwalanie tylko na porty, których faktycznie używasz, to podstawowy element każdej listy kontrolnej zabezpieczania VPS, niezależnie od kluczy.

Czy fail2ban jest konieczny na VPS?

Zdecydowanie zalecany. Nawet przy wyłączonym logowaniu hasłem boty będą próbować sondować port SSH i zaśmiecać logi. fail2ban automatycznie banuje powtarzających się intruzów, redukując hałas i blokując niewielką szansę udanego ataku brute-force na jakikolwiek serwis.

Czy ApexVPS obejmuje ochronę DDoS i kopie zapasowe?

Tak. Każdy plan obejmuje stałą ochronę DDoS i automatyczne kopie zapasowe — codziennie w Starter Pro i godzinne migawki w Business i Enterprise — oraz całodobowe monitorowanie. Uzupełniają one własne wzmacnianie systemu, pokrywając warstwę infrastruktury, której nie zabezpieczysz z wnętrza serwera.