Czy hosting VPS jest bezpieczny? Poziom izolacji zasobów

Czy hosting VPS jest bezpieczny? Krótka odpowiedź

Tak. Hosting VPS jest bezpieczny dla większości zastosowań, do których jest nabywany, i stanowi realną poprawę względem hostingu współdzielonego. VPS (virtual private server) to maszyna wirtualna posiadająca własne jądro, pamięć, przestrzeń dyskową oraz konta użytkowników, a nadzorca (hypervisor) izoluje te zasoby od innych klientów. Osoba wynajmująca serwer na tej samej maszynie fizycznej nie może odczytać plików, wyświetlić listy procesów, zalogować się do serwera ani monitorować ruchu sieciowego.

Uczciwa odpowiedź składa się z dwóch części. Dostawca jest właścicielem sprzętu oraz hypervisora. Użytkownik posiada wszystko wewnątrz maszyny wirtualnej i to właśnie tam zaczyna się niemal każdy incydent. Do włamań na serwery dochodzi przez otwarte porty, słabe hasła SSH, nieaktualne pakiety lub ujawnione w plikach sekrety. Do przełamań zabezpieczeń przez hypervisor dochodzi bardzo rzadko.

Co faktycznie izoluje hypervisor

Hypervisor to oprogramowanie uruchamiające maszyny wirtualne na jednym fizycznym hoście. Na VPS typu KVM (KVM oznacza kernel based virtual machine, standard na hostach z systemem Linux) serwer jest pełnoprawną maszyną wirtualną. Uruchamia własne jądro systemu. Host przydziela mu stały obszar pamięci fizycznej, a jednostka zarządzania pamięcią procesora odrzuca wszelkie próby dostępu poza ten zakres, dzięki czemu kod działający w innym systemie gościnnym nie jest w stanie zaadresować pamięci RAM przypisanej do Twojego serwera. Nie istnieje współdzielony system plików ani wspólna tabela użytkowników, więc uprawnienia do plików na serwerze sąsiada nie mają żadnego znaczenia dla Twojego środowiska.

Hosting współdzielony działa inaczej. Wiele witryn funkcjonuje w ramach jednego systemu operacyjnego, pod kontrolą jednego serwera WWW i jednej instalacji PHP, jako zwykłe konta użytkowników. Jedyną barierą są uprawnienia do plików. Błąd w uprawnieniach lub podatna wtyczka działająca na koncie z nadmiernymi przywilejami może zatem uzyskać dostęp do plików innego użytkownika. To właśnie tę lukę eliminuje przejście z hostingu współdzielonego na VPS.

Należy sprawdzać ofertę przed zakupem, ponieważ nie każdy plan sprzedawany jako VPS jest maszyną wirtualną. Plany oparte na kontenerach (OpenVZ, LXC, Virtuozzo) współdzielą jądro systemu hosta i izolują klientów za pomocą przestrzeni nazw (namespaces) oraz cgroups zamiast wirtualizacji sprzętowej. Jest to słabsza bariera, ponieważ błąd w jądrze systemu hosta jest jednocześnie błędem w Twoim serwerze. W takich planach nie można również ładować modułów jądra, co wyklucza działanie niektórych programów. KVM jest bezpieczniejszym standardem. Przed dokonaniem płatności warto zapytać, z jakiej technologii korzysta dostawca.

Wpływ współdzielenia zasobów przez innych użytkowników

Współdzielenie fizycznego hosta wiąże się z utratą wydajności i jest to jedyny koszt takiego rozwiązania. Maszyny wirtualne na jednym serwerze współdzielą fizyczny procesor oraz dyski. Gdy procesor jest zajęty przez inny proces, wirtualny procesor Twojej maszyny czeka, a system Linux raportuje to jako steal time: pole %st w narzędziach top oraz vmstat. Wartość steal time utrzymująca się powyżej kilku procent przez wiele godzin oznacza, że host jest przeciążony. Nie oznacza to, że ktokolwiek uzyskuje dostęp do Twoich danych. Rozwiązaniem jest zmiana planu taryfowego lub dostawcy, a przed podjęciem decyzji możesz zmierzyć faktycznie otrzymaną wydajność procesora i dysku.

Warto znać jeden efekt wynikający z sąsiedztwa innych klientów, który nie stanowi luki w zabezpieczeniach. Jeśli wysyłasz pocztę e-mail ze swojego VPS, Twój adres IP znajduje się w puli używanej również przez innych klientów. Sąsiad wysyłający spam może doprowadzić do umieszczenia części tej puli na czarnych listach, przez co Twoja poczta trafia do folderów ze spamem z przyczyn niezależnych od Ciebie. Dostawcy aktywnie zwalczający nadużycia utrzymują czystsze zakresy adresowe. Zapytaj o to, jeśli wysyłka e-mail jest dla Ciebie istotna.

Czego nie może zrobić wrogi sąsiad i rzadkie przypadki, w których jest to możliwe

Klient korzystający z tego samego hosta nie ma dostępu do Twoich plików. Nie może podejrzeć Twoich procesów, zamontować dysku ani otworzyć powłoki na Twoim serwerze, ponieważ żadna z tych rzeczy nie istnieje wewnątrz jego maszyny wirtualnej. Warto wspomnieć o jednym wyjątku: każdą prywatną sieć dostawcy należy traktować jako sieć współdzieloną z obcymi i szyfrować dane, które przez nią przechodzą, zamiast zakładać, że są niewidoczne.

Ucieczki z hypervisora są realnym zagrożeniem. Błąd w warstwie wirtualizacji może pozwolić kodowi wewnątrz jednego gościa na dostęp do hosta, a z poziomu hosta na dostęp do każdego działającego na nim gościa. Błędy te są wykrywane, publikowane z identyfikatorem CVE (common vulnerabilities and exposures) i łatane. Dostawcy hostingu szybko wdrażają poprawki, ponieważ na tej warstwie opiera się cały ich biznes. Wykorzystanie takiej luki wymaga działającego exploita dla konkretnej wersji hypervisora, co jest zbyt kosztowne, by stosować to wobec małego konta hostingowego.

Kanały boczne między gośćmi również istnieją. Należy do nich rodzina podatności Spectre i Meltdown, które wykorzystują współdzielone pamięci podręczne procesora do wyciągania niewielkich ilości danych przez granicę izolacji. Aktualizacje mikrokodu oraz jądra systemu ograniczają to ryzyko, a tempo wycieku danych w opublikowanych badaniach jest znikome. Opisane przypadki to raczej demonstracje badawcze niż masowe ataki. Ryzyko nie jest zerowe, ale z pewnością nie znajduje się na szczycie listy zagrożeń, które mogą Ci zaszkodzić.

Gdzie kończy się odpowiedzialność dostawcy, a zaczyna Twoja

Dostawca odpowiada za budynek, sprzęt hosta, hypervisor i jądro systemu hosta, sieć fizyczną oraz panel sterowania, który umożliwia uruchamianie, zatrzymywanie, przebudowywanie i tworzenie migawek serwera. Jeśli którykolwiek z tych elementów zawiedzie, naprawa leży po stronie dostawcy.

Ty odpowiadasz za wszystko, począwszy od systemu operacyjnego w górę. Oznacza to zainstalowane pakiety, otwarte porty, konta i klucze służące do logowania, stosowane aktualizacje, kopie zapasowe oraz własny kod aplikacji. Większość planów VPS jest niezarządzana, co oznacza, że nikt nie instaluje poprawek na serwerze w Twoim imieniu i żadne zgłoszenie do pomocy technicznej tego nie zmieni. Warto przeczytać podział na usługi zarządzane i niezarządzane przed dokonaniem zakupu, ponieważ określa on zakres Twoich obowiązków.

O jednym elemencie Twojej odpowiedzialności łatwo zapomnieć: o samym panelu sterowania hostingiem. Każdy, kto posiada dane logowania do tego panelu, może przebudować serwer lub podłączyć dysk do systemu ratunkowego, nie znając żadnego hasła z wnętrza serwera. Włącz uwierzytelnianie dwuskładnikowe (2FA) na koncie hostingowym i nie używaj tego samego hasła w żadnym innym miejscu.

Czy dostawca hostingu ma wgląd w dane?

Tak, w zasadzie tak i jest to uczciwie określona granica ochrony, jaką zapewnia VPS. Obraz dysku znajduje się na pamięci masowej dostawcy. Konsola dostawcy zapewnia dostęp do wirtualnej maszyny na poziomie ekranu. Tryb ratunkowy (rescue mode) pozwala na uruchomienie innego systemu z podpiętym dyskiem użytkownika. VPS chroni przed innymi klientami, jednak dostawca pozostaje poza tym zakresem ochrony.

Jeśli przechowywane dane muszą pozostać nieczytelne dla hosta, należy je zaszyfrować w aplikacji przed zapisem. Pełne szyfrowanie dysku wewnątrz systemu gościa chroni przed skopiowaniem obrazu w stanie spoczynku, jednak klucz musi znajdować się w pamięci RAM podczas pracy serwera, więc nie eliminuje to dostawcy z procesu. To samo zaufanie dotyczy dedykowanego serwera wynajmowanego na wyłączność, z tą różnicą, że wyeliminowana zostaje jedna warstwa współdzielona.

Co faktycznie prowadzi do przejęcia serwera VPS

Usługa nasłuchująca na wszystkich interfejsach. Bazy danych, pamięci podręczne, kolejki komunikatów i panele administracyjne często domyślnie wiążą się z adresem 0.0.0.0, co oznacza każdy interfejs sieciowy, w tym publiczny. Skanowanie Internetu jest ciągłe i zautomatyzowane, więc nowy adres IP otrzymuje pierwsze niechciane zapytanie w ciągu kilku minut od uruchomienia. Redis bez hasła, nieuwierzytelniony węzeł Elasticsearch, otwarte API Docker na porcie 2375 oraz panel administracyjny z domyślnymi danymi logowania są wykrywane w ten sposób przez skaner, który nie posiada żadnych informacji o właścicielu serwera. Powiąż usługę z adresem 127.0.0.1, jeśli jest potrzebna tylko lokalnie, a pozostałe połączenia zablokuj na firewallu.

Docker omijający firewall. Publikacja portu kontenera tworzy reguły translacji adresów sieciowych (NAT), które są przetwarzane przed regułami z ufw, więc kontener może być dostępny z Internetu, mimo że ufw status wskazuje, iż port jest zablokowany. Jest to częsta pułapka dla osób, które poprawnie skonfigurowały pozostałe elementy. Warto przeczytać dlaczego port Docker ignoruje ufw przed opublikowaniem portu kontenera.

SSH z włączonym logowaniem hasłem. Przejrzyj /var/log/auth.log na dowolnym publicznym serwerze, a znajdziesz tysiące linii takich jak Failed password for root from 203.0.113.10 port 54312 ssh2, pojawiających się w dzień i w nocy. Boty sprawdzają popularne nazwy użytkowników i hasła. Logowanie hasłem w połączeniu z kontem root, które akceptuje połączenia, to wszystko, czego potrzebuje atakujący. Używanie wyłącznie kluczy przy wyłączonym logowaniu na konto root zmienia ten ruch w szum, który można zignorować.

Jeden klucz prywatny używany wszędzie. Jeden klucz skopiowany na każdy laptop i serwer oznacza, że kradzież jednego urządzenia odblokowuje wszystko. Klucze SSH nie wygasają, więc klucz przekazany podwykonawcy dwa lata temu nadal działa. Jeden klucz dla osoby i maszyny nic nie kosztuje, a ogranicza zasięg szkód w przypadku kradzieży pojedynczego klucza.

Nieaktualne pakiety. Opublikowana luka CVE dotycząca serwera WWW lub frameworka aplikacji to publicznie dostępna instrukcja, a skanery zaczynają testować podatność w ciągu kilku dni. Aktualizacje bezpieczeństwa to najtańsza dostępna forma ochrony i mogą działać automatycznie: zobacz automatyczne aktualizacje bezpieczeństwa w Ubuntu.

Wyciek sekretów. Hasła do baz danych i klucze API znajdują się w plikach .env, które bywają zatwierdzane w publicznych repozytoriach lub udostępniane przez serwer WWW skierowany na niewłaściwy katalog. Wszystko, co zostanie wklejone do kontekstu agenta programistycznego AI, może również trafić do logów, co stanowi osobne zagadnienie: ochrona sekretów przed dostępem agenta.

Wszystko uruchomione jako root. Gdy aplikacja działa z uprawnieniami root, jeden błąd w niej pozwala na przejęcie całego serwera, ponieważ wewnątrz systemu nie ma żadnej bariery, która mogłaby powstrzymać rozprzestrzenianie się ataku.

Twoja część zadania

Żaden z poniższych punktów nie dotyczy pracy hypervisora. Wszystkie te działania leżą po Twojej stronie granicy odpowiedzialności i to one decydują o bezpieczeństwie Twojego VPS.

• Wykonaj poprawnie pierwsze kroki: pierwsze dziesięć minut na nowym VPS obejmuje utworzenie użytkownika innego niż root oraz konfigurację firewalla.
• Ogranicz zdalny dostęp: zabezpieczanie SSH na VPS.
• Zamknij nieużywane porty: podstawy firewalla ufw.
• Nadaj każdej usłudze wyłącznie niezbędne uprawnienia: użytkownicy z minimalnymi uprawnieniami na VPS.
• Spowolnij ataki brute force: fail2ban na Ubuntu 24.04.
• Prowadź backupy, które przynajmniej raz zostały przetestowane pod kątem przywracania: backupy restic dla VPS.

Część zadań dostawcy jest wykonana w momencie uruchomienia serwera. Twoja część zajmuje około godziny pierwszego dnia i kilka minut w każdym kolejnym miesiącu. Jeśli nadal porównujesz dostępne opcje, czym w rzeczywistości jest VPS wyjaśnia podstawy wszystkich tych zagadnień.

FAQ

Czy inny klient na tym samym serwerze fizycznym może odczytać moje pliki?

Nie, nie w przypadku VPS typu KVM. Twój serwer jest maszyną wirtualną z własnym jądrem i własnym dyskiem wirtualnym, a także obszarem pamięci fizycznej przydzielonym przez hosta, przy czym procesor blokuje wszelki dostęp poza ten obszar. Między gośćmi nie ma współdzielonego systemu plików, więc uprawnienia do plików wewnątrz serwera sąsiada nie mają znaczenia w Twoim systemie. Plany oparte na kontenerach, takie jak OpenVZ i LXC, współdzielą jądro hosta i zapewniają słabszą izolację, dlatego sprawdź, jaki typ usługi kupujesz.

Czy VPS jest bezpieczniejszy niż hosting współdzielony?

Pod względem izolacji – tak. Na hostingu współdzielonym wiele witryn działa w ramach jednego systemu operacyjnego, a jedyną barierą są uprawnienia do plików, więc błąd na innym koncie może czasami ujawnić pliki. Na VPS barierą jest maszyna wirtualna. Ceną za to jest fakt, że hosting współdzielony jest łatany przez dostawcę, podczas gdy niezarządzany VPS jest łatany przez Ciebie. VPS jest bezpieczniejszy tylko wtedy, gdy faktycznie instalujesz aktualizacje i zamykasz niepotrzebne porty.

Czy mój dostawca hostingu może odczytać moje dane?

W zasadzie tak i żaden produkt typu VPS tego nie zmienia. Obraz dysku jest przechowywany na sprzęcie dostawcy, konsola zapewnia dostęp do ekranu działającej maszyny, a tryb ratunkowy (rescue mode) pozwala uruchomić inny system z podłączonym Twoim dyskiem. Jeśli niektóre dane muszą pozostać nieczytelne dla hosta, zaszyfruj je w swojej aplikacji przed zapisem. Szyfrowanie dysku wewnątrz gościa nadal przechowuje klucz w pamięci podczas pracy serwera, więc nie eliminuje dostawcy z modelu zaufania.

Jaki jest najczęstszy sposób przejęcia kontroli nad VPS?

Zdecydowanie wystawienie usługi na świat lub słabe zabezpieczenie logowania SSH. Zautomatyzowane skanery nieustannie sondują każdy publiczny adres IP, więc baza danych powiązana z 0.0.0.0 bez hasła lub panel administracyjny pozostawiony z domyślnymi danymi logowania zostaną znalezione w ciągu minut, a nie miesięcy. /var/log/auth.log na dowolnym publicznym serwerze pokazuje SSH od tej strony: powtarzające się linie Failed password for root z adresów z całego świata. Ucieczki z hiperwizora (hypervisor escapes) istnieją, ale są to prace na poziomie badawczym, wymierzone w cele o wysokiej wartości, a nie przyczyna typowych włamań.