# Hartowanie nowego VPS
> Hartowanie nowego VPS zajmuje około dwudziestu minut: wyłącz logowanie hasłem i root przez SSH, włącz tylko logowanie kluczem, skonfiguruj nftables na domyślne odrzucanie przychodzących, włącz automatyczne aktualizacje bezpieczeństwa i zainstaluj fail2ban. Te pięć kroków eliminuje przeważającą większość realnych kompromitacji.
**Source:** https://incognitovps.com/pl/guides/harden-a-new-vps
**Updated:** 2026-07-17

## Co faktycznie kompromituje serwery

Nie zero-day. W praktyce: brute force haseł SSH przeciw słabym poświadczeniom, niezałatane usługi działające miesiącami, odsłonięte panele administracyjne z domyślnymi hasłami i podatności aplikacji w tym, co operator zainstalował. Lista jest nudna i nie zmieniła się od piętnastu lat.

Lista kontrolna poniżej jest uporządkowana według tego, ile ryzyka każdy krok usuwa na minutę spędzonego czasu. Rób je w kolejności i przestań, gdy skończy się cierpliwość — i tak usuniesz większość ryzyka.

## Krok 1 — tylko klucze SSH

Ta pojedyncza zmiana całkowicie eliminuje najczęstszy atak. Wygeneruj klucz Ed25519, skopiuj jego część publiczną na serwer, a następnie edytuj `/etc/ssh/sshd_config`, ustawiając `PasswordAuthentication no`, `PermitRootLogin prohibit-password` oraz `KbdInteractiveAuthentication no`.

Przetestuj klucz w drugim terminalu, zanim zamkniesz pierwszy. Zablokowanie się jest żenujące i, na maszynie z dostępem do konsoli, całkowicie do naprawienia — ale mimo to zrób to w odpowiedniej kolejności.

## Krok 2 — zapora domyślnie blokująca

Użyj nftables na nowoczesnym Debianie i Ubuntu lub firewalld na pochodnych RHEL. Domyślnie blokuj ruch przychodzący, zezwól na ustanowione i pokrewne połączenia, zezwól na swój port SSH, zezwól na to, czego faktycznie potrzebuje Twoje obciążenie, i nic więcej.

Ważną zasadą jest to, że „nic więcej” to sedno. Zapora z permisywną regułą dodaną podczas debugowania i nigdy nieusuniętą to zapora, która nic nie robi.

- Domyślna polityka: odrzucaj przychodzące, akceptuj wychodzące
- Akceptuj ustanowione i pokrewne
- Akceptuj ruch na interfejsie loopback
- Akceptuj swój port SSH, najlepiej z ograniczeniem szybkości
- Akceptuj porty obciążenia, jawnie wymienione
- Akceptuj ICMP echo — nie psuj wykrywania MTU

## Krok 3 — automatyczne aktualizacje bezpieczeństwa

Użyj `unattended-upgrades` na Debianie i Ubuntu oraz `dnf-automatic` na pochodnych RHEL, skonfigurowanych tylko dla aktualizacji bezpieczeństwa. Większość włamań wykorzystuje podatności załatane miesiące wcześniej.

Włącz automatyczny restart w oknie konserwacyjnym, jeśli Twoje obciążenie na to pozwala. Aktualizacje jądra nic nie dają, dopóki maszyna nie zostanie zrestartowana, a serwer z 400 dniami uptime i jedenastoma zaległymi CVE w jądrze to nie powód do dumy.

## Krok 4 — fail2ban i uwaga o jego rzeczywistej wartości

Przy wyłączonym logowaniu hasłem fail2ban zatrzymuje stosunkowo niewiele faktycznych włamań. Za to drastycznie redukuje szum w logach, co ma znaczenie, ponieważ log pełen tysięcy nieudanych prób to log, którego nikt nie czyta, a nieczytane logi to sposób, w jaki prawdziwe włamania pozostają niezauważone przez tygodnie.

Domyślny jail sshd wystarczy. Dodaj jails dla wszystkiego innego, co wystawiasz na internet.

## Krok 5 — zmniejsz powierzchnię ataku

Uruchom `ss -tlnp` i sprawdź, co nasłuchuje. W domyślnej instalacji zwykle znajdziesz usługi, o których nie wiedziałeś, że działają, i których nie potrzebujesz. Usuń je zamiast blokować zapórą — oprogramowanie, które nie jest zainstalowane, nie ma podatności.

Powiąż usługi, które potrzebują dostępu tylko lokalnego, z 127.0.0.1 zamiast 0.0.0.0. Baza danych nasłuchująca na wszystkich interfejsach za zaporą jest jedną błędną konfiguracją od bycia publiczną.

## Co pominąć

Zmiana portu SSH zmniejsza szum w logach i nie zatrzymuje żadnych ukierunkowanych ataków. Możesz to zrobić, jeśli chcesz, ale nie licz tego jako zabezpieczenie. Port knocking dodaje kruchości dla marginalnego zysku. Systemy wykrywania włamań generują alerty, których nikt nie triażuje na pojedynczym serwerze.

Jeśli chcesz jeden bardziej znaczący krok po pięciu powyższych, to szyfrowane kopie zapasowe poza siedzibą, w innej jurysdykcji, przetestowane przez faktyczne przywrócenie. Zdolność odzyskiwania jest warta więcej niż kolejna warstwa prewencji.


## Często zadawane pytania

### Czy zmiana portu SSH jest tego warta?

Dla szumu w logach — tak. Dla bezpieczeństwa — nie: zatrzymuje oportunistycznych skanerów, a zero ukierunkowanych ataków. Rób to, jeśli lubisz cichsze logi, ale nie licz tego jako kontrola.

### Czy potrzebuję fail2ban, jeśli używam kluczy SSH?

Do bezpośredniego bezpieczeństwa — ledwo. Do higieny logów — tak: tysiące nieudanych prób czynią logi nieczytelnymi, a nieczytane logi to sposób, w jaki prawdziwe włamania pozostają niezauważone.

### Czy powinienem włączyć automatyczne restarty?

Jeśli obciążenie na to pozwala, tak, w oknie konserwacyjnym. Łaty jądra nic nie dają, dopóki nie nastąpi restart. Długi uptime z zaległymi CVE w jądrze to zobowiązanie, a nie osiągnięcie.


---

Incognito VPS — Offshore VPS, serwery bare-metal i GPU w 16 lokalizacjach, 8 z nich wybranych ze względu na właściwości prawne. Bez identyfikacji, płatności tylko kryptowalutą, wdrożenie w 55 sekund.
Operating since 2020. 16 locations, 8 of them privacy jurisdictions. AS204287.
Payment: BTC, XMR, ETH, USDT, USDC, LTC, TRX, SOL, BNB, DOGE, TON, DAI. No identity verification at any point.
Catalogue: https://incognitovps.com/pricing.md · API: https://incognitovps.com/openapi.json · Index: https://incognitovps.com/llms.txt