7 dobrych praktyk na serwerach VPS dla większego bezpieczeństwa

Posiadając serwer VPS bez administracji, który jest dostępny w publicznej sieci, warto pamiętać nie tylko o dbaniu o uruchomioną na nim stronę, ale również o zabezpieczeniu samego serwera i przechowywanych na nim danych. Nie tylko zaplanowane ataki są jedynym zagrożeniem, ale również nieumyślne działania osoby zarządzającej serwerem mogą spowodować, że serwer i usługi na nim uruchomione przestaną działać we właściwy sposób. W tym artykule przedstawionych zostało 7 dobrych praktyk, które pomogą Ci poprawić bezpieczeństwo serwera VPS.

Serwer VPS – Autoryzacja SSH kluczem RSA

Domyślnie, po uruchomieniu nowego serwera VPS, otrzymasz dostęp do niego przez SSH z wykorzystaniem hasła (zwykle dla użytkownika root). Jedną z pierwszych czynności, którą powinieneś wykonać, jest skonfigurowanie dostępu SSH w taki sposób, aby logowanie było możliwe wyłącznie przez klucz RSA, a dostęp za pomocą hasła został wyłączony. Dlaczego jest to takie ważne?

Autoryzacja SSH za pomocą hasła jest mniej bezpieczna niż przy użyciu klucza z kilku powodów:

• Podatność na ataki brute-force: Hasło może zostać „odgadnięte” przez oprogramowanie stosujące tę technikę, zwłaszcza w przypadku prostych i krótkich haseł.
• Ryzyko stosowania jednego hasła w wielu miejscach: Jeśli jedno z haseł wycieknie, istnieje ryzyko, że osoba nieuprawniona uzyska dostęp także do innych zasobów użytkownika.
• Przechwycenie hasła: Hasło jako ciąg znaków wprowadzanych przez użytkownika może zostać przechwycone przez keylogger, phishing lub w atakach typu man-in-the-middle. W przypadku autoryzacji kluczem, klucz prywatny pozostaje na urządzeniu użytkownika i nie jest przesyłany przez sieć.
• Łatwiejsza kontrola dostępu: Autoryzowany klucz może zostać łatwo odwołany. Jeśli hasło zostało udostępnione wielu osobom, odebranie dostępu jednej z nich wymaga zmiany hasła, co komplikuje dostęp pozostałym użytkownikom.

Jak wygenerować klucze SSH w Windows?

Najwygodniej zainstalować pakiet oprogramowania PuTTY (https://www.putty.org/) który oprócz najpopularniejszego klienta SSH zawiera w swoim składzie program Key Generator. Generując w nim zestaw kluczy RSA pamiętaj żeby ustalić hasło do klucza – to dodatkowe zabezpieczenie. Na wypadek wpadnięcia klucza prywatnego w niepowołane ręce, będzie on bezużyteczny bez znajomości hasła.

Po wygenerowaniu kluczy, zapisz jego prywatną i publiczną część na swoim komputerze. Możesz od razu skopiować klucz publiczny w formacie OpenSSH – będziemy go potrzebować podczas konfiguracji SSH na serwerze.

O sposobie generowania kluczy w systemach Linux przeczytasz tutaj: Jak wygenerować klucz SSH? | Jak to zrobić na hostingu?

Instalacja klucza publicznego na serwerze

Klucz publiczny powinien zostać dopisany do pliku tekstowego “.ssh/authorized_keys” znajdującym się w folderze domowym użytkownika. Może to być “root”, ale bezpieczniejszym rozwiązaniem będzie wybór innego użytkownika – w sekcji “Używaj użytkownika root tylko gdy to konieczne” dowiesz się dlaczego. Jeśli ten plik lub katalog “.ssh” nie istnieje, utwórz go, pamiętając o nadaniu odpowiednich uprawnień zarówno katalogowi “.ssh”, jak i pliku “.ssh/authorized_keys”.

cd /home/nazwa-uzytkownika
mkdir .ssh
chmod 700 .ssh
touch .ssh/authorized_keys
chmod 600 .ssh/authorized_keys

Jak połączyć się z serwerem przez PuTTY z wykorzystaniem klucza?

W pakiecie programów PuTTY znajdziesz program o nazwie Pageant, który działa jako agent kluczy. Po jego uruchomieniu dodaj do niego swój klucz prywatny. Następnie możesz zamknąć okno – Pageant będzie działał w tle aż do ponownego uruchomienia systemu.

Aby połączyć się z serwerem SSH za pomocą klucza, podaj nazwę użytkownika przed adresem serwera w formacie: nazwa-uzytkownika@moj-serwer.pl, tak jak na poniższy zrzucie ekranu:

Teraz, podczas próby autoryzacji, zostanie użyty dodany przez Ciebie klucz. Jeśli jego część publiczna została poprawnie dodana na serwerze (plik authorized_keys), autoryzacja przebiegnie pomyślnie i uzyskasz dostęp do serwera.

Wyłączenie możliwości logowania się do serwera hasłem

Dla zwiększenia bezpieczeństwa dostępu przez SSH do serwera zalecane jest, aby wyłączyć możliwość logowania za pomocą hasła. W tym celu z poziomu użytkownika root zmień konfigurację SSH znajdującą się najczęściej w pliku: “/etc/ssh/sshd_config”:

Ustaw parametr “PasswordAuthentication” na wartość “no”. Najczęściej wystarczy odkomentować tę linijkę.

Po zapisaniu zmian w pliku, zrestartuj serwer SSH poleceniem:

service sshd restart

I upewnij się, że dostęp SSH do serwera działa jak należy – tylko za pomocą klucza, bez możliwości autoryzacji hasłem. Najlepiej wykonaj to inicjując drugie nowym połączeniu SSH. Nie zamykaj obecnego.

Włączenie i konfiguracja zapory firewall

Firewall to oprogramowanie kontrolujące ruch wchodzący i wychodzący na serwerze na podstawie ustalonych reguł, dzięki czemu skutecznie blokuje dostęp do serwera oraz uruchomionych na nim usług.

W zależności od systemu zainstalowanego na serwerze, firewall może być domyślnie zainstalowany i włączony, działając w podstawowym zakresie. Aby to sprawdzić, uruchom w konsoli polecenie:

sudo ufw status

Jeśli wynik komendy będzie podobny do poniższego, oznacza to, że firewall jest zainstalowany, a status „active” wskazuje, że zapora jest aktywna i kontroluje ruch zgodnie z ustalonymi regułami:

Przykład przedstawia prostą konfigurację firewalla, która umożliwia dostęp przez porty 80 i 443 (dla HTTP i HTTPS) oraz port 2380 jako port dla SSH (zmieniony z domyślnego 22). Wszystkie zarówno dla IPv4 jak i IPv6.

Firewall pozwala nie tylko na blokowanie ruchu na wybranych portach, ale również na blokowanie ruchu z określonych adresów IP. Jak to działa w praktyce? Spróbujmy zablokować ruch z serwisu https://czystronadziala.net (wykonuje on test dostępności strony) po czym sprawdzimy, czy rzeczywiście strona stanie się dla tego serwisu nieosiągalna.

Po ustaleniu adresu IP serwera z którego wykonywane są testy stron, dodajmy go jako regułę typu DENY do konfiguracji zapory:

ufw deny from 70.34.244.81 to any

Reguła zablokuje wszelki ruch z podanego adresu IP. Pamiętaj o kolejności reguł, ponieważ ufw przetwarza je od góry do dołu, stosując pierwszą pasującą regułę. Dlatego reguła blokująca powinna znajdować się wyżej niż reguła dopuszczająca pozostałych klientów.

Po dodaniu powyższej reguły do firewalla, strona stanie się niedostępna dla serwisu testującego, tak jak jest to widoczne na poniższym zrzucie ekranu

Ustawienie wykonywania kopii bezpieczeństwa vps (backup)

Czasami nawet najlepsze zabezpieczenia mogą okazać się niewystarczające. Warto więc być przygotowanym na najgorszy scenariusz i posiadać plan przywrócenia serwera oraz działających na nim usług do prawidłowego stanu. Dotyczy to nie tylko skutków ewentualnych ataków na nasz serwer, ale także błędów, które możemy nieumyślnie popełnić, awarii sprzętowych czy nieudanych aktualizacji oprogramowania. Dlatego kluczowe zasoby na serwerze powinny być objęte regularnie i automatycznie tworzonymi kopiami zapasowymi, przechowywanymi w miejscach odizolowanych sieciowo, a najlepiej
także geograficznie.

Jednym z podstawowych zasobów, które zazwyczaj są obejmowane backupem jest zawartość bazy danych. W przypadku MySQL, możemy łatwo wykonać zrzut wybranej bazy do pliku poleceniem:

mysqldump -u nazwa_uzytkownika -p nazwa_bazy > zrzut_bazy.sql

Utworzony plik najlepiej poddać kompresji (np. ZIP), a następnie przesłać na zewnętrzny serwer np. za pomocą programu rsync: RSYNC – kopiowanie plików (backup) | Jak to zrobić na hostingu? lub za pomocą dedykowanych skryptów opisanych tutaj: Jak mogę wykonać backup plików? | Jak to zrobić na hostingu?

Rozważ objęcie backupem również:

• pliki strony działającej na serwerze jeżeli nie posiadasz ich kopii np. w repozytorium
• pliki przesyłane przez użytkowników na serwer (np. zdjęcia, avatary itp.)
• logi
• pliki konfiguracyjne
• certyfikaty SSL zainstalowane na serwerze

Dobrą praktyką jest przetestowanie scenariusza przywracania serwera do normalnego stanu. Czy dysponując jedynie plikami z kopii zapasowej, będziesz w stanie uruchomić stronę w akceptowalnym czasie na czystym serwerze, bez utraty zawartości merytorycznej strony?

Używaj użytkownika root tylko gdy to konieczne

Użytkownika root mającego największe uprawnienia w systemie używaj tylko wtedy gdy jest to konieczne. Przykładowo, jeżeli logujesz się do serwera, aby przejrzeć logi aplikacji na nim zainstalowanej lub zmienić jej konfigurację (np. strony www) zrób to z poziomu użytkownika, który posiada tylko do niej uprawnienia. W szczególności gdy dostęp do serwera posiadają różne osoby. Błąd użytkownika będącego zalogowanym jako root może mieć bardzo poważne konsekwencje. Mając pełne uprawnienia, root może przypadkowo usunąć ważne pliki systemowe, zmienić konfiguracje lub uszkodzić kluczowe elementy systemu, co może spowodować awarię całego serwera.

Dobrą praktyką jest też stosowanie polecenia “sudo” w sytuacjach w których potrzebujemy chwilowy dostęp do wyższych uprawnień, np. aby zrestartować jakąś usługę na serwerze.

Zmiana portów usług na serwerze

W internecie nieustannie działają boty skanujące serwery. Sprawdzają one które porty są otwarte na danym serwerze i jeżeli skojarzą wykryty otwarty port z jakąś usługą uruchomioną na serwerze (np. SSH, baza danych, serwer WWW) to próbują uzyskać do niej dostęp różnymi metodami. Prostym zabezpieczeniem jest zmiana domyślnych portów na inne tak, aby utrudnić botom wykrycie i identyfikację usługi pod nim działającej.

O ile niektórych portów raczej nie będziemy chcieli zmieniać (np. dla serwera WWW) to dla usługi SSH lub serwera bazy danych już jak najbardziej możemy to zrobić. Port możemy wybrać dowolny, pod warunkiem, że nie jest używany przez inną usługę

Dla SSH port z domyślnego 22 zmienimy edytując plik konfiguracyjny “/etc/ssh/sshd_config”:

Po zapisaniu zmian, pamiętaj o zrestartowaniu usługi SSH:

service sshd restart

Uwaga, tak jak w poprzednim przypadku, najlepiej przetestuj to na nowym połączeniu SSH, nie zamykając poprzedniego.

Oczywiście musisz pamiętać, że przy logowaniu do serwera przez klienta SSH musisz zmienić port na ustawiony w konfiguracji. To samo możesz zrobić dla innych usług uruchomionych na serwerze, np. bazy danych.

Bezpieczny VPS – Automatyczna aktualizacja oprogramowania na serwerze

Pamiętaj o regularnym aktualizowaniu oprogramowania na serwerze. Aktualizacje wprowadzają nie tylko nowe funkcjonalności, ale przede wszystkim naprawiają błędy i luki, które potencjalnie mogą zostać wykorzystane przez atakującego:

apt-get update
apt-get upgrade

W niektórych systemach operacyjnych (np. w Ubuntu) istnieje możliwość włączenia automatycznej aktualizacji paczek dot. bezpieczeństwa gdy tylko zostaną opublikowane. Aby skorzystać z tej wygodnej funkcji, najpierw zainstaluj paczkę:

apt-get install unattended-upgrades

Po zakończeniu instalacji sprawdź, czy proces odpowiedzialny za aktualizacje paczek jest poprawnie uruchomiony:

systemctl status unattended-upgrades

Monitoring działania serwera VPS i jego usług

W poprzednich krokach omówiliśmy sposoby na podniesienie poziomu bezpieczeństwa serwera, ale skąd będziemy wiedzieć, że działa on prawidłowo? Tutaj warto rozważyć monitoring – wewnętrzny, sprawdzający stan serwera od środka, oraz zewnętrzny – jako niezależną usługę, która w regularnych odstępach czasu zweryfikuje, czy na serwerze uruchomione są oczekiwane usługi i czy działają prawidłowo.

Monitoring wewnętrzny to oprogramowanie instalowane na serwerze, którego zadaniem jest kontrola zasobów sprzętowych serwera (zużycie CPU, RAM, dysków), usług na nim uruchomionych, a nawet logów. W przypadku wykrycia nieprawidłowości, zostaniemy o tym powiadomieni.

Popularnym dzisiaj rozwiązaniem jest Prometheus w połączeniu z narzędziem do wizualizacji danych Netdata. Prometheus dostarcza dane o systemie, które Netdata może następnie wyświetlić na różne sposoby (wykresy, diagramy, panele itp.). Samodzielnie Prometheus oferuje jedynie podstawowe wizualizacje, natomiast Netdata umożliwia tworzenie interaktywnych dashboardów, filtrów, a nawet alertów:

O sposobie instalacji Netdata dowiesz się na:
Instalacja penalu netdata – monitoring serwera (Debian). | Jak to zrobić na hostingu?, a tutaj o jego
integracji z Prometheus: Using Netdata with Prometheus | Learn Netdata
Co jeśli serwer stanie się całkowicie niedostępny np. z powodu awarii lub jego przypadkowego wyłączenia? Wspomniany monitoring nie zadziała bo funkcjonuje tylko wtedy, kiedy serwer jest uruchomiony. W takich sytuacjach swoją niezastępowalność udowadnia monitoring zewnętrzny, będący całkowicie niezależną od monitorowanego serwera usługą.

Przykładem tego typu serwisu jest https://ping.pl. Za jego pomocą możemy automatycznie i w regularnych odstępach czasu testować nie tylko serwer za pomocą żądania PING, ale również monitorować usługi na nim uruchomione: stronę internetową, serwer poczty, usługę API, DNS i inne.

Serwer VPS – Inne praktyki warte rozważania

W tym artykule przyjrzeliśmy się kilku prostym do wdrożenia działaniom, które mają na celu zwiększenie bezpieczeństwa serwerów VPS bez administracji. Warto jednak rozważyć także inne rozwiązania, takie jak:

1. Instalacja oprogramowania Fail2Ban lub podobnego, aby minimalizować skutki ataków typu brute-force lub DDoS.
2. Ograniczenie dostępu do powłoki SSH tylko dla wybranych adresów IP lub konfiguracja dostępu do SSH wyłącznie przez VPN.
3. Konfiguracja automatycznych punktów przywracania systemu lub snapshotów serwera, jeśli operator hostingowy oferuje taką możliwość.
4. Korzystanie z SFTP zamiast FTP.
5. Instalacja systemu antywirusowego i skanera malware na serwerze.