Co zrobić najpierw na nowym VPS?

Wejdź kluczem SSH i wyłącz logowanie hasłem. Automatyczne boty walą w port 22 zgadywaniem haseł w ciągu minut od uruchomienia serwera; klucz czyni te próby bezcelowymi. Wszystko inne jest drugorzędne wobec tej jednej zmiany.

Czy potrzebuję zapory, jeśli uruchamiam tylko jedną usługę?

Tak. Zapora (ufw) oznacza, że osiągalne są tylko porty, które wyraźnie otworzyłeś — więc usługa, o której uruchomieniu zapomniałeś, lub taka, którą otworzyła zależność, nie jest po cichu wystawiona. To dwa polecenia i zamyka całą klasę błędów.

Czy fail2ban jest konieczny, jeśli wyłączyłem logowanie hasłem?

Jest opcjonalny, gdy klucze są wymuszone — przy wyłączonych hasłach brute force i tak nie może się udać. fail2ban głównie przycina szum logów i wcześnie blokuje nadużywające IP. Miły dodatek, nie krytyczny, na maszynie tylko z kluczami.

Czy powinienem zmienić port SSH?

To kosmetyczne bezpieczeństwo — przejście z 22 tnie szum logów od głupich botów, ale nie zatrzymuje zdeterminowanego napastnika. Zrób to, jeśli szum Cię przeszkadza, ale nie myl tego z prawdziwą ochroną. Klucze + brak haseł to, co faktycznie ma znaczenie.

Jak utrzymać VPS załatanym automatycznie?

Włącz unattended-upgrades (Debian/Ubuntu), by łatki bezpieczeństwa instalowały się same. To pojedynczy nawyk o najwyższej wartości po kluczach SSH — większość włamań wykorzystuje znane, już załatane błędy na serwerach, których nikt nie aktualizował.

Zabezpieczanie nowego VPS: lista kontrolna, która faktycznie ma znaczenie

Pierwsze dziesięć minut na świeżym VPS po cichu decyduje o wielu rzeczach. Nowe publiczne IP zaczyna być sondowane przez automatyczne boty niemal natychmiast — nie celują w Ciebie, po prostu skanują wszystko. Nie zrób nic, a polegasz na szczęściu. Zrób cztery lub pięć drobnych rzeczy, a zamknąłeś drzwi, które faktycznie są kopane. Oto lista, w kolejności priorytetów, z poleceniami.

1. Klucze SSH i zabij logowanie hasłem

To ta, która ma największe znaczenie. Jeśli możesz zalogować się hasłem, to może i bot, który je zgadnie — a próbują tysiące na minutę.

Z Twojego laptopa, jeśli nie masz jeszcze klucza:

ssh-keygen -t ed25519 -C "you@laptop"
ssh-copy-id root@your-server-ip

Potem na serwerze wyłącz hasła:

# /etc/ssh/sshd_config.d/99-hardening.conf
PasswordAuthentication no
PermitRootLogin prohibit-password

sudo systemctl reload ssh

⚠️ Przetestuj drugą sesję SSH, zanim zamkniesz pierwszą — jeśli logowanie kluczem działa, świetnie; jeśli nie, wciąż masz otwartą sesję, by to naprawić. Zablokowanie się na zewnątrz to klasyczny samobój tutaj.

2. Zapora — domyślnie odmawiaj

Wystawiaj tylko to, co zamierzasz. Na Ubuntu/Debian:

sudo apt install -y ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH        # lub Twój port SSH
sudo ufw enable

Teraz zabłąkana usługa nie może być osiągnięta z zewnątrz, chyba że ją otworzysz. To łapie rzecz, o której nieuchronnie zapomnisz.

Jedna uwaga dla planów typu NAT: Twój SSH ląduje na przekierowanym porcie, nie 22, i nie możesz otwierać dowolnych portów przychodzących — izolacja robi za Ciebie część tej pracy. Na planie z dedykowanym IP posiadasz wszystkie porty, więc zapora robi więcej.

3. Automatyczne aktualizacje bezpieczeństwa

Większość serwerów, które zostają przejęte, nie była sprytnymi celami — uruchamiały znany błąd, który łatka już naprawiła, na maszynie, której nikt nie aktualizował. Uczyń łatanie automatycznym:

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

Ustaw-i-zapomnij. To nawyk o najwyższej wartości po kluczach SSH.

4. fail2ban (opcjonalny, ale tani)

Przy już wyłączonym logowaniu hasłem brute force nie może wygrać — więc to o przycinaniu szumu i wczesnym banowaniu nadużywających IP, nie o podstawowej ochronie:

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

Wart tego dla cichszych logów; pomiń go bez wyrzutów sumienia, jeśli utrzymujesz sprawy minimalnie.

Co możesz pominąć

Zmiana portu SSH — tnie szum botów, nie zatrzymuje prawdziwego napastnika. Kosmetyczne. Nie myl tego z bezpieczeństwem.
Rozbudowane strojenie IDS/SELinux — przesada dla maszyny jednego przeznaczenia uruchamiającej bota lub agenta. Malejące zwroty.

Uczciwe podsumowanie

Jeśli robisz tylko jedną rzecz, zrób klucze SSH + brak logowania hasłem. Dodaj zaporę i auto-aktualizacje, a obsłużyłeś przytłaczającą większość realnego ryzyka w znacznie mniej niż dziesięć minut. Wszystko poza tym to polerowanie.

Uruchamiasz zawsze włączonego agenta lub bota na maszynie? Sparuj to z utrzymywaniem go przy życiu pod systemd, by przetrwał restarty i awarie, nie tylko napastników.