Konfiguracja bezpieczeństwa nowego VPS

Pierwsze 10 minut decyduje o bezpieczeństwie serwera

Nowy VPS nie jest bezpieczny. Od momentu uzyskania publicznego adresu IP skanery próbują nawiązać połączenie. Domyślny obraz systemu stanowi dla nich łatwy cel: użytkownik root jest często dostępny, hasła są często dozwolone, brak jest firewalla, a system nie posiada zaplanowanych aktualizacji. Rozwiązanie wszystkich tych problemów zajmuje około dziesięciu minut i wymaga wykonania kilku komend. Jest to instrukrukcja (runbook), którą stosuję na każdym nowym serwerze przed instalacją jakichkolwiek danych.

Należy postępować zgodnie z kolejnością, ponieważ kroki budują się jeden na drugim. Każdy krok posiada własny przewodnik, do którego linki znajdują się w tekście; ta strona stanowi szybką ścieżkę łączącą te instrukcje.

Minuta 1: Zaktualizuj wszystko

Zaloguj się jako root przy użyciu danych uwierzytelniających dostarczonych przez dostawcę i w pełni zaktualizuj system przed podjęciem innych działań:

apt update && apt upgrade -y

Niezałatany system jest najłatwiejszym możliwym celem, dlatego ten krok jest priorytetowy. Po zakończeniu procesu skonfiguruj automatyczne aktualizacje bezpieczeństwa, aby system pozostawał aktualny bez konieczności ręcznego interweniowania.

Minuta 2: Utwórz zwykłego użytkownika z sudo

Nie należy pracować na koncie root. Utwórz własnego użytkownika i nadaj mu uprawnienia sudo:

adduser matt
usermod -aG sudo matt

Od tego momentu należy logować się jako ten użytkownik i używać sudo do zadań administracyjnych. Ciągłe korzystanie z konta root oznacza, że każdy błąd i każde naruszenie bezpieczeństwa odbywa się z nieograniczonymi uprawnieniami, czego zapobiega użytkowanie konta o ograniczonych uprawnieniach.

Minuta 4: Skonfiguruj klucze SSH

Hasła mogą zostać odgadnięte; klucze nie. Na własnym laptopie, jeśli nie posiadasz jeszcze klucza, należy go wygenerować:

ssh-keygen -t ed25519

Następnie skopiuj klucz publiczny na serwer:

ssh-copy-id matt@YOUR_SERVER

ssh-copy-id wymaga włączenia logowania hasłem dla nowego użytkownika; jeśli jest ono już wyłączone, należy skopiować ~/.ssh/authorized_keys użytkownika root do /home/matt/.ssh/authorized_keys (własność matt) lub ręcznie wkleić klucz publiczny do tego pliku.

Zasady dotyczące jednego klucza na urządzenie, uprawnień blokujących logowanie kluczem oraz unieważniania utraconego klucza zostały omówione w podstawach 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 dostępu do SSH przed uzyskaniem dostępu za pomocą klucza jest częstą przyczyną utraty dostępu do serwera.

Minuta 6: Wyłącz logowanie root i logowanie hasłem

Po potwierdzeniu działania klucza należy zamknąć dwie drogi dostępu wykorzystywane przez skanery. Należy użyć pliku typu drop-in, aby aktualizacje pakietów nie nadpisały ustawień. Nazwij plik 00-, aby sortowanie nastąpiło przed 50-cloud-init.conf, które Ubuntu cloud images dostarczają z PasswordAuthentication yes; usługa sshd zachowuje pierwszą odczytaną wartość, więc plik o późniejszym sortowaniu spowoduje ciche przeoczenie ustawień:

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

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

Następnie przeładuj usługę SSH:

sudo systemctl restart ssh

Następnie sprawdź ustawienia faktycznie używane przez sshd, aby plik drop-in nie wprowadził w błąd:

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

Po wyłączeniu haseł i logowania root, ciągły ruch brute-force skierowany przeciwko serwerowi nie będzie mógł odnieść sukcesu. Pełna procedura, w tym opcjonalna zmiana portu, znajduje się w utwardzaniu SSH na VPS.

Minuta 8: Włącz firewall

Zastosuj domyślną politykę deny dla całego ruchu przychodzącego, a następnie zezwól tylko na niezbędne połączenia. Zezwól na SSH przed aktywacją firewalla, w przeciwnym razie połączenie zostanie przerwane:

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

Dodaj reguły allow dla wszelkich uruchamianych usług, takich jak 80/tcp i 443/tcp dla witryny internetowej. Sprawdź, czy objęte są zarówno protokoły IPv4, jak i IPv6, ponieważ firewall filtrujący tylko IPv4 pozostawia stronę IPv6 całkowicie otwartą. Pełny przewodnik znajduje się w Firewalls 101 na VPS.

Minuta 10: Spowolnij skanery za pomocą Fail2ban

Na koniec dodaj Fail2ban, aby blokować adresy atakujące porty:

sudo apt install -y fail2ban

W systemie Ubuntu 24.04 standardowa instalacja chroni SSH od pierwszego uruchomienia. Przy wymaganych kluczach SSH, rozwiązanie to służy jako zabezpieczenie redukujące szum w logach i blokujące powtarzających się sprawców, a nie jako główna linia obrony.

Twoja lista kontrolna

To jest instrukcja postępowania. Użyj generatora poniżej, aby odznaczyć każdą kontrolę i wygenerować spersonalizowaną listę kontrolną do zachowania przy serwerze, zawierającą dokładną komendę dla każdego kroku:

Stosuj tę procedurę przy każdym nowym serwerze, aby wypracować nawyk. Dziesięć minut poświęconych teraz zapobiegnie bardzo niekorzystnym skutkom przejęcia serwera w przyszłości.

Po wprowadzeniu niezbędnych zabezpieczeń, automatyczne aktualizacje bezpieczeństwa na Ubuntu zapewnią aktualność systemu bez konieczności ponownego logowania.

FAQ

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

Należy zaktualizować system za pomocą apt update && apt upgrade -y, następnie utworzyć zwykłego użytkownika z uprawnieniami sudo i przestać pracować na koncie root. Następnie należy skonfigurować klucze SSH, wyłączyć logowanie root i uwierzytelnianie hasłem, włączyć firewall z domyślną polityką deny oraz zainstalować Fail2ban. Wykonanie tych kroków w tej kolejności gwarantuje bezpieczeństwo procesu i zapobiega utracie dostępu do serwera.

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

Należy skonfigurować i przetestować logowanie kluczem SSH przed wyłączeniem haseł lub konta root. Należy wylogować się i zalogować ponownie za pomocą klucza w celu potwierdzenia działania, a dopiero potem wyłączyć PasswordAuthentication oraz PermitRootLogin. Podczas aktywacji firewalla należy zezwolić na port 22 przed uruchomieniem ufw enable. W przypadku utraty dostępu, konsola webowa dostawcy pozwala na powrót do systemu bez użycia SSH.

Czy na małym serwerze naprawdę potrzebne są wszystkie te zabezpieczenia?

Tak, ponieważ skanery nie biorą pod uwagę wielkości serwera. Próbują one każdego publicznego adresu IP w ten sam sposób. Cała procedura zajmuje około dziesięciu minut i eliminuje łatwe ścieżki ataku: brak logowania root, brak możliwości odgadnięcia hasła, brak niechcianych usług wystawionych na świat oraz automatyczne łatanie znanych błędów.

Który krok jest najważniejszy?

Logowanie SSH wyłącznie za pomocą kluczy przy wyłączonym logowaniu root. Większość ataków na nowe serwery VPS to zautomatyzowane próby odgadnięcia hasła do konta root; wyłączenie obu tych opcji uniemożliwia całą tę kategorię ataków. Firewall i Fail2ban ograniczają natomiast to, co pozostaje wystawione na widok publiczny, i spowalniają ewentualne próby ataku.

Jak potwierdzić, że serwer został skutecznie zabezpieczony?

Przed zaufaniem serwerowi należy ręcznie sprawdzić trzy elementy. Należy uruchomić sudo ss -tlnp i upewnić się, że tylko zamierzone porty nasłuchują na publicznym adresie, bez żadnych zapomnianych usług 0.0.0.0 lub [::]. Należy uruchomić sudo ufw status verbose i potwierdzić, że domyślna polityka przychodząca to deny oraz że obecne są reguły dla IPv4 i (v6). Zawsze należy otworzyć drugą sesję SSH przed zamknięciem pierwszej, aby błąd w konfiguracji SSH nie spowodował utraty dostępu do serwera. Jeśli wszystkie trzy elementy są poprawne, podstawowe zabezpieczenia zostały wdrożone.