Jak zabezpieczyć nowy serwer VPS w 10 minut

Pierwsze 10 minut decyduje o bezpieczeństwie serwera

Nowy serwer VPS nie jest bezpieczny. Od momentu uzyskania publicznego adresu IP skanery próbują uzyskać dostęp, a domyślny obraz systemu stanowi łatwy cel: konto root jest często dostępne, hasła są zazwyczaj dozwolone, brak jest firewalla, a aktualizacje nie są wykonywane w harmonogramie. Dobrą wiadomością jest to, że zabezpieczenie tych elementów zajmuje około dziesięciu minut i wymaga kilku poleceń. Jest to procedura, którą wykonuję na każdym nowym serwerze, zanim umieszczę na nim jakiekolwiek dane.

Należy realizować kroki w podanej kolejności, ponieważ każdy z nich opiera się na poprzednim. Każdy etap posiada własny przewodnik, do którego prowadzą odnośniki; ta strona stanowi szybką ścieżkę łączącą wszystkie działania w całość.

Minuta 1: Aktualizacja systemu

Zaloguj się jako root, używając danych dostarczonych przez dostawcę, a następnie przeprowadź pełną aktualizację systemu przed wykonaniem jakichkolwiek innych czynności:

apt update && apt upgrade -y

Niezałatany serwer stanowi najłatwiejszy cel ataku, dlatego jest to priorytetowe zadanie. Po zakończeniu procesu skonfiguruj automatyczne aktualizacje bezpieczeństwa, aby system pozostawał zabezpieczony bez konieczności ręcznej interwencji.

Minuta 2: Utworzenie zwykłego użytkownika z uprawnieniami sudo

Nie należy pracować jako root. Należy utworzyć własne konto użytkownika i nadać mu uprawnienia sudo:

adduser matt
usermod -aG sudo matt

Od tego momentu logowanie odbywa się jako ten użytkownik, a do zadań administracyjnych używa się sudo. Praca z uprawnieniami root niesie ryzyko, że każdy błąd lub naruszenie bezpieczeństwa nastąpi przy użyciu nieograniczonych uprawnień, czemu właśnie zapobiega praca jako użytkownik bez uprawnień administracyjnych.

Minuta 4: Konfiguracja kluczy SSH

Hasła są podatne na odgadnięcie; klucze nie. Na własnym laptopie, jeśli nie posiadasz jeszcze klucza, utwórz go:

ssh-keygen -t ed25519

Następnie skopiuj część publiczną na serwer:

ssh-copy-id matt@YOUR_SERVER

ssh-copy-id wymaga włączonego logowania hasłem dla nowego użytkownika; jeśli jest ono już wyłączone, skopiuj ~/.ssh/authorized_keys użytkownika root do /home/matt/.ssh/authorized_keys (będącego własnością matt) lub wklej swój klucz publiczny do tego pliku ręcznie.

Model zakładający jeden klucz na urządzenie, uprawnienia uniemożliwiające logowanie kluczem oraz unieważnianie utraconego klucza zostały omówione w podstawy zarządzania kluczami SSH.

Wyloguj się i zaloguj ponownie jako matt przy użyciu klucza, a następnie potwierdź poprawność działania przed przejściem do kolejnego kroku. Zablokowanie SSH przed uzyskaniem dostępu za pomocą klucza jest częstą przyczyną utraty dostępu do serwera. Jeśli logowanie kończy się komunikatem Permission denied (publickey), rozwiąż ten problem teraz, zamiast wracać do hasła, ponieważ ten jeden komunikat obejmuje pięć różnych błędów, a dane wyjściowe ssh -v wskażą, który z nich faktycznie występuje.

Minuta 6: Wyłączenie logowania na konto root i haseł

Skoro klucz działa, należy zamknąć dwie furtki wykorzystywane przez skanery. Należy użyć pliku typu drop-in, aby aktualizacje pakietów nie nadpisały zmian. Plik należy nazwać 00-, aby był sortowany przed 50-cloud-init.conf, z którym dostarczane są obrazy chmurowe Ubuntu PasswordAuthentication yes; sshd zachowuje pierwszą odczytaną wartość, więc plik sortowany później zostałby zignorowany:

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

Następnie należy przeładować SSH:

sudo systemctl restart ssh

Potem należy sprawdzić ustawienia faktycznie używane przez sshd, aby uniknąć błędów wynikających z nieaktywnego pliku drop-in:

sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin'

Po wyłączeniu haseł i logowania na konto root, ciągły ruch typu brute-force wymierzony w serwer nie będzie skuteczny. Pełna procedura, w tym opcjonalna zmiana portu, znajduje się w utwardzanie SSH na VPS.

Minuta 8: Włącz zaporę sieciową

Zastosuj politykę domyślnego odrzucania całego ruchu przychodzącego, a następnie zezwalaj tylko na niezbędne połączenia. Zezwól na ruch SSH przed włączeniem zapory, w przeciwnym razie utracisz aktywne połączenie:

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw enable

Dodaj reguły allow dla każdej uruchomionej usługi, na przykład 80/tcp oraz 443/tcp dla serwisu WWW. Jeśli po tej operacji nowa sesja SSH nie nawiązuje połączenia, przeczytaj komunikat o błędzie przed podjęciem jakichkolwiek działań, ponieważ odmowa połączenia oznacza, że sshd odpowiedział, a przekroczenie czasu oczekiwania zazwyczaj oznacza, że zapora odrzuciła pakiet. Sprawdź, czy reguły obejmują zarówno IPv4, jak i IPv6, ponieważ zapora filtrująca tylko IPv4 pozostawia stronę IPv6 całkowicie otwartą. Pełny przewodnik znajduje się w sekcji Podstawy zapory sieciowej na VPS. Te polecenia ufw zakładają użycie systemu Ubuntu lub Debian; w systemach Rocky lub AlmaLinux cel domyślnego odrzucania ruchu jest ten sam, ale używanym narzędziem jest firewalld, dlatego należy wykonać kroki opisane w wersji tego etapu dla firewalld.

Minuta 10: Spowolnienie skanerów za pomocą Fail2ban

Na koniec należy dodać Fail2ban, aby usuwać adresy IP, które sondują porty:

sudo apt install -y fail2ban

W systemie Ubuntu 24.04 standardowa instalacja chroni SSH od pierwszego uruchomienia. Ponieważ klucze są już wymagane, stanowi to dodatkowe zabezpieczenie, które ogranicza szum w logach i blokuje powtarzających się intruzów, zamiast pełnić rolę głównej linii obrony.

Twoja lista kontrolna

To jest procedura operacyjna. Użyj poniższego generatora, aby zaznaczyć każdy punkt kontrolny i wygenerować spersonalizowaną listę, którą można przechowywać wraz z serwerem, zawierającą dokładne polecenia dla każdego kroku:

Przechodź przez listę przy każdym nowym serwerze, aż czynności staną się nawykowe. Dziesięć minut pracy teraz pozwala uniknąć bardzo nieprzyjemnego popołudnia, które następuje po przejęciu serwera.

Gdy podstawowe zabezpieczenia są wdrożone, automatyczne aktualizacje zabezpieczeń w systemie Ubuntu utrzymują serwer w aktualnym stanie bez konieczności logowania się. Każda kolejna usługa wymaga osobnej weryfikacji, a słabe punkty ulegają zmianie: w przypadku własnego menedżera haseł serwer nigdy nie przechowuje danych w postaci jawnej, więc rzeczywiste ryzyka związane z Vaultwarden ograniczają się do tokena administratora oraz pliku kopii zapasowej.

FAQ

Co należy zrobić w pierwszej kolejności na nowym VPS?

Zaktualizuj system za pomocą apt update && apt upgrade -y, następnie utwórz zwykłego użytkownika z uprawnieniami sudo i zakończ pracę na koncie root. Następnie skonfiguruj klucze SSH, wyłącz logowanie dla użytkownika root oraz uwierzytelnianie hasłem, włącz zaporę sieciową z domyślną polityką odrzucania połączeń i zainstaluj Fail2ban. Wykonanie tych kroków w tej kolejności zapewnia bezpieczeństwo i zapobiega utracie dostępu do serwera.

Jak uniknąć utraty dostępu podczas zabezpieczania SSH?

Skonfiguruj i przetestuj logowanie za pomocą klucza SSH przed wyłączeniem haseł lub dostępu dla użytkownika root. Wyloguj się i zaloguj ponownie przy użyciu klucza, aby potwierdzić poprawność działania, a dopiero potem wyłącz PasswordAuthentication oraz PermitRootLogin. Podczas włączania zapory sieciowej zezwól na ruch na porcie 22 przed uruchomieniem ufw enable. W przypadku utraty dostępu, konsola internetowa dostawcy serwera umożliwia odzyskanie dostępu bez użycia SSH.

Czy na małym serwerze naprawdę potrzebuję wszystkich tych zabezpieczeń?

Tak, ponieważ skanery nie sprawdzają wielkości serwera. Przeszukują one każdy publiczny adres IP w ten sam sposób. Cała procedura zajmuje około dziesięciu minut i eliminuje najprostsze wektory ataku: brak logowania root, brak zgadywania haseł, brak wystawionych niepotrzebnych usług oraz automatyczne poprawki znanych błędów.

Który krok jest najważniejszy?

Logowanie wyłącznie za pomocą kluczy SSH przy wyłączonym dostępie dla użytkownika root. Większość ataków na nowy VPS to zautomatyzowane próby odgadnięcia hasła do konta root; wyłączenie obu tych opcji czyni tę kategorię ataków niemożliwą do przeprowadzenia. Zapora sieciowa i Fail2ban ograniczają zakres wystawionych usług i spowalniają pozostałe próby ataków.

Jak potwierdzić, że serwer jest odpowiednio zabezpieczony?

Przed zaufaniem konfiguracji sprawdź ręcznie trzy elementy. Uruchom sudo ss -tlnp i potwierdź, że na publicznym adresie nasłuchują tylko te porty, które miały być otwarte, bez żadnych usług 0.0.0.0 lub [::], o których mogłeś zapomnieć. Uruchom sudo ufw status verbose i potwierdź, że domyślna polityka dla ruchu przychodzącego to deny oraz że obecne są reguły zarówno dla ruchu zwykłego, jak i (v6). Zawsze otwieraj drugą sesję SSH przed zamknięciem pierwszej, aby błąd w konfiguracji SSH nie spowodował utraty dostępu do serwera. Jeśli wszystkie trzy punkty są poprawne, podstawowe zabezpieczenia zostały wdrożone.