CageFS w codziennej pracy z hostingiem: izolacja systemu plików między kontami klientów

Dlaczego konta hostingowe wymagają izolacji

W przypadku hostingu współdzielonego kilku klientów prowadzi swoje strony internetowe na tym samym serwerze. Jeśli skrypt na koncie A zostanie przejęty, może próbować gromadzić informacje o otoczeniu i uzyskać dostęp do plików na innych kontach. Mogą to być pliki konfiguracyjne zawierające dane dostępowe lub dane osobowe. Rozdzielenie kont ma na celu utrudnienie takiego dostępu, mimo że infrastruktura jest wspólnie wykorzystywana.

W tym przypadku są to Widoczność i uprawnienia dostępu różne kwestie. Nazwa katalogu może być widoczna, mimo że uprawnienia do plików uniemożliwiają odczytanie jego zawartości. Z drugiej strony samo ograniczone wyświetlanie nie wystarczy, by zastąpić starannie ustawione uprawnienia: to, co jest dostępne w danym środowisku, musi nadal być odpowiednio chronione.

CageFS rozszerza uprawnienia o środowisko systemu plików specyficzne dla użytkownika. Proces działający w przewidzianym kontekście nie ma po prostu takiego samego wglądu w host jak administrator. Ma to na celu uniemożliwienie skryptowi uruchomionemu z konta A swobodnego przeglądania katalogów należących do innych kont. To, które obszary są faktycznie widoczne, zależy od konfiguracji.

Dla operatorów stanowi to dodatkowe Warstwa rozdzielająca, brak gwarancji, że nie będzie to miało żadnego wpływu na innych klientów. Błędy w usługach współdzielonych, zbyt szerokie uprawnienia lub niepełna integracja usług mogą wpływać na skuteczność ochrony. Dlatego izolację należy sprawdzać tam, gdzie faktycznie uruchamiane są programy klientów, a nie tylko na podstawie ustawienia w panelu administracyjnym.

Dla klientów korzystających z usług hostingowych to rozróżnienie jest również istotne: fakt, że własna aplikacja nie widzi obcych katalogów, opisuje przede wszystkim jedynie jej konkretny kontekst działania. Nie świadczy to ani o konfiguracji wszystkich usług, ani o zabezpieczeniu wszystkich pozostałych kont. Za ogólną konfigurację i kontrolę nadal odpowiada dostawca.

Jak CageFS kształtuje widok systemu plików

CageFS zapewnia użytkownikom własny widok systemu plików. Podstawą jest Szkielet: szablon zawierający pliki i katalogi udostępniane dla danego środowiska. Włączane są niezbędne elementy; również katalog domowy użytkownika jest włączany do jego środowiska. Widoczne drzewo katalogów nie jest zatem po prostu niezmienioną kopią widoku hosta.

Zintegrowanie można zilustrować na przykładzie narzędzia: administrator instaluje program na hoście, ale proces klienta nie znajduje go w swoim środowisku. Nie oznacza to automatycznie błędu instalacji. Program może znajdować się na hoście, ale nie być dostępny w szkielecie ani poprzez integracje przewidziane dla klienta.

Z drugiej strony każdy dodatkowo udostępniony plik rozszerza środowisko, które jest widoczne dla procesu. To samo dotyczy zamontowanego katalogu. Administratorzy muszą zatem rozważyć wymagania funkcjonalne w stosunku do dodatkowej widoczności: aplikacja może potrzebować określonego narzędzia i jego zależności, ale niekoniecznie całego katalogu hosta.

Die Konfiguracja uchwytu określa, które elementy systemu plików są widoczne w środowisku. Nie decyduje jednak samodzielnie o tym, czy proces może odczytywać, modyfikować lub uruchamiać widoczny plik. W tym zakresie istotne znaczenie mają między innymi prawa własności i uprawnienia. Widoczna ścieżka nie oznacza zatem automatycznie dozwolonego dostępu do zapisu.

Własny katalog domowy ma szczególne znaczenie w codziennym korzystaniu z hostingu: zazwyczaj znajdują się tam pliki danego konta. Zintegrowanie tego katalogu umożliwia dostęp w przewidzianym kontekście, podczas gdy pozostała część widoku jest ograniczona. To, czy konkretna aplikacja ma dostęp do wszystkich potrzebnych plików, zależy jednak od jej konfiguracji oraz faktycznie dostępnych ścieżek.

CageFS, LVE i wspólne zagrożenia

CageFS i LVE rozwiązują różne problemy. CageFS kształtuje widok systemu plików i kontekst wykonywania dla użytkownika; LVE służy do monitorowania i ograniczania zasobów, takich jak procesor, pamięć oraz operacje wejścia i wyjścia. Proces z ograniczonym dostępem do systemu plików może nadal zużywać zasoby. Z drugiej strony samo ograniczenie zasobów nie uniemożliwia dostępu do plików, które zostały nieprawidłowo udostępnione.

Panel sterowania hostingiem pełni jeszcze jedną funkcję: zarządza między innymi kontami i może integrować komponenty CloudLinux. Jednak sama instalacja panelu nie oznacza, że każdy proces internetowy, każda powłoka i każde zaplanowane zadanie działają w przewidzianym kontekście CageFS. Operatorzy muszą sprawdzić, jaka integracja jest odpowiednia dla ich konkretnej platformy.

CageFS nie jest oddzielną maszyną wirtualną dla każdego konta. Konta nadal korzystają z wspólny jądro i mogą zależeć od wspólnie obsługiwanych usług. Luka w zabezpieczeniach lub nieprawidłowa konfiguracja tych wspólnych komponentów nadal stanowi zatem część modelu zagrożeń. Izolacja systemu plików ogranicza część widocznego środowiska, ale nie zastępuje zabezpieczeń i konserwacji hosta.

Ryzyko istnieje nawet w przypadku prawidłowo izolowanego konta. Na przykład podatna na ataki aplikacja może ujawnić własne dane; skradzione dane logowania mogą umożliwić atakującemu uzyskanie dostępu w ramach danego konta. CageFS nie koryguje ani niebezpiecznego kodu aplikacji, ani zbyt szerokich uprawnień do plików dostępnych w ramach tego konta.

Aby strategia bezpieczeństwa była skuteczna, poszczególne warstwy muszą więc ze sobą współgrać: należy prawidłowo zintegrować konta i usługi, kontrolować uprawnienia do plików, odpowiednio dobrać limity zasobów oraz dbać o aktualność aplikacji. Skuteczność ochrony zależy od rzeczywistej konfiguracji i uruchomionych usług. Nazwa pojedynczego komponentu nie zastępuje tej weryfikacji.

Rozpatrywanie kont i stron internetowych oddzielnie

Dwa konta klientów na tym samym serwerze to inna sytuacja niż dwie strony internetowe w ramach jednego konta. CageFS zapewnia środowisko dostosowane do konkretnego użytkownika, ograniczając w ten sposób dostęp konta do systemu plików. Nie oznacza to jednak, że każda strona internetowa w ramach tego konta otrzymuje własną granicę systemu plików.

Jeśli agencja prowadzi kilka projektów w ramach tego samego konta hostingowego, jej aplikacje mogą uzyskać dostęp do plików innych projektów w zależności od kontekstu wykonania i uprawnień. Jeśli więc osoba atakująca uzyska dostęp do strony internetowej poprzez podatną na ataki wtyczkę, należy sprawdzić, do jakich plików konfiguracyjnych i danych dostępowych można uzyskać dostęp w ramach tego konta. Oddzielenie od drugiego konta klienta nie daje odpowiedzi na to pytanie.

Aby uzyskać bardziej precyzyjny Rozdzielenie stron internetowych CloudLinux, dzięki funkcji CloudLinux Isolates, zapewnia dodatkową izolację systemu plików na poziomie domeny. To, czy można z niej skorzystać, zależy od konkretnej dostępności produktu, wersji oraz integracji z panelem. Sprawdź te wymagania dla własnego środowiska hostingowego, zamiast wyciągać wnioski o rozdzieleniu domen wyłącznie na podstawie aktywacji CageFS.

Limity LVE związane z domenami stanowią również odrębną funkcję, podlegającą własnym warunkom. Dodatkowy limit systemu plików nie oznacza zatem automatycznie, że procesor lub pamięć są ograniczane oddzielnie dla każdej domeny. Artykuł na temat Izolacja witryn w systemie CloudLinux wyjaśnia różnicę między poziomem konta a poziomem strony internetowej; dla konfiguracji decydujące znaczenie mają wymagania zastosowanego wariantu produktu.

Na etapie planowania warto najpierw przeprowadzić analizę obecnej sytuacji: które witryny korzystają z tego samego konta, które pliki muszą być współużytkowane, a które dane dostępowe powinny pozostać oddzielne? Na tej podstawie można ustalić, czy oddzielne konta, czy też dostępna izolacja oparta na domenie lepiej pasują do modelu operacyjnego. Oba warianty wymagają sprawdzenia rzeczywistych ścieżek korzystania z aplikacji.

Sprawdź status pilota i CageFS

Przed rozpoczęciem projektu pilotażowego, jako operator, sprawdź, czy stosowana wersja systemu operacyjnego jest obsługiwana, czy dostępne są wymagane pakiety i licencja oraz czy panel sterowania jest odpowiednio zintegrowany. Udokumentowana obsługa panelu nie oznacza, że każda funkcja działa tak samo w każdej kombinacji. Należy również odnotować, jakie aplikacje i narzędzia są wymagane przez wybrane konta testowe.

Zacznij od wyraźnie autoryzowanych kont testowych i niewielkiego zestawu typowych aplikacji. Sprawdź ich katalogi domowe, wymagane programy i odpowiednie ścieżki uruchamiania, zanim dodasz kolejne konta. Na początek możesz skorzystać z trybu, w którym CageFS jest domyślnie wyłączony, a poszczególne konta są aktywowane; alternatywnie dostępny jest tryb, w którym CageFS jest domyślnie włączony, z pewnymi wyjątkami.

Poniższe polecenia odczytu są przeznaczone dla uprawnionych administratorów w systemie, w którym zainstalowano CageFS. TESTBENUTZER należy zastąpić istniejącym kontem, które ma uprawnienia do przeprowadzania testów. Wymagane uprawnienia i konkretny wynik zależą od systemu; polecenia te nie zmieniają konfiguracji.

/usr/sbin/cagefsctl --cagefs-status
/usr/sbin/cagefsctl --display-user-mode
/usr/sbin/cagefsctl --user-status TESTBENUTZER

Pierwsze polecenie wyświetla ogólny stan CageFS, drugie – Tryb pracy. Trzeci sprawdza status wybranego konta. Tryb i status konta należy rozpatrywać łącznie: tryb domyślnie aktywny może mieć wyjątki, podczas gdy w innym trybie poszczególne konta są wyraźnie uwzględniane.

Pozytywny wynik nie stanowi jeszcze dowodu, że każda usługa faktycznie działa w przewidzianym kontekście. Należy zatem oddzielnie udokumentować, co zgłasza administracja oraz jakie ścieżki wykonania zostały sprawdzone przy użyciu konta testowego. Dopiero wtedy można zdecydować, czy projekt pilotażowy można rozszerzyć na kolejne konta oraz jakie wyjątki są konieczne z operacyjnego punktu widzenia.

Porównanie metod ochrony

Podejścia te różnią się przede wszystkim tym, gdzie wyznaczają granice i kto nimi zarządza. W tabeli przedstawiono cele ochronne; dane dotyczące kosztów eksploatacji stanowią jakościowe wytyczne planistyczne, a nie zmierzone wartości. Konkretne wymagania zależą od danej platformy i jej konfiguracji.

Uprawnienia do plików i ograniczony dostęp nie są pojęciami zamiennymi: nawet widoczna ścieżka niekoniecznie musi być dostępna do odczytu, a udostępniona ścieżka musi być odpowiednio zabezpieczona. CageFS uzupełnia te uprawnienia poprzez specjalnie zaprojektowane środowisko. Z kolei LVE zajmuje się zużyciem zasobów; aby umożliwić wspólne korzystanie, obie warstwy muszą być odpowiednio skonfigurowane.

A własna maszyna wirtualna przesuwa granicę administracyjną w stosunku do środowiska specyficznego dla użytkownika: system gościnny wymaga samodzielnej konserwacji i pozostaje zależny od platformy wirtualizacyjnej. Oddzielny serwer ponownie zmienia charakter wspólnie wykorzystywanej infrastruktury. To, który wariant jest odpowiedni, zależy od modelu zagrożeń, wymaganych uprawnień oraz dostępnych zasobów operacyjnych.

Ogólny ranking bezpieczeństwa byłby zatem mylący. Aby porównać inne mechanizmy i ich odpowiednie obszary zastosowania, pomocny jest przegląd dotyczący Izolacja procesów w hostingu. Kluczowe znaczenie ma następnie konkretna analiza: które ograniczenie ma zapobiegać jakiemu dostępowi, które usługi je przekraczają i kto nadzoruje konfigurację?

Kontrolowane testowanie ścieżek wykonania

To, że konto jest aktywne, nie oznacza jeszcze, że każdy powiązany z nim proces faktycznie uruchamia się w CageFS. Decydujące znaczenie ma dany ścieżka wykonania: Logowanie przez SSH, serwer WWW i zaplanowane zadania mogą korzystać z różnych integracji. Dlatego administratorzy muszą sprawdzić dla każdej odpowiedniej usługi, w jaki sposób przypisuje ona procesy do konta i jego środowiska.

W celu przeprowadzenia kontrolowanego testu operator zakłada autoryzowane konto testowe i korzysta wyłącznie z własnych, wyraźnie zatwierdzonych plików testowych. Plik umieszczony w przewidzianym środowisku może wykazać, czy oczekiwany dostęp działa prawidłowo; plik przygotowany oddzielnie poza przewidzianym widokiem służy do sprawdzenia ograniczeń dostępu. Zewnętrzne katalogi klientów nie stanowią odpowiedniego materiału testowego do tego celu.

Najpierw sprawdź przez SSH, jakie środowisko faktycznie otrzymuje konto testowe i czy przewidziane pliki testowe są dostępne zgodnie z oczekiwaniami. Powtórz sprawdzenie przy użyciu skonfigurowanej w tym celu aplikacji internetowej oraz zaplanowanego zadania. Wyniki mogą się różnić, jeśli usługi są zintegrowane w inny sposób lub działają w innym kontekście użytkownika.

W przypadku każdego testu należy odnotować usługę, konto, ścieżkę i wynik. Odmowa dostępu potwierdza jedynie zaobserwowane ograniczenie w tym konkretnym kontekście; nie świadczy ona ani o prawidłowej izolacji wszystkich usług, ani o bezpieczeństwie całego hosta. Z drugiej strony, w przypadku nieoczekiwanego pomyślnego uzyskania dostępu należy przeprowadzić analizę przed uruchomieniem kolejnych kont.

Jako klient usługi hostingowej możesz sprawdzić swój własny kontekst wykonania oraz udostępnione pliki. Zazwyczaj nie masz możliwości samodzielnego sprawdzenia globalnych ustawień CageFS, innych kont ani integracji wszystkich usług. Za te kwestie odpowiada operator; w przypadku nieprawidłowości opisz mu, której usługi to dotyczy oraz podaj konkretną ścieżkę.

Brakujące narzędzia i konserwacja szkieletu

Jeśli narzędzie jest zainstalowane na serwerze, ale nie można go znaleźć na koncie klienta, najpierw sprawdź kontekst uruchamiania. Wywołanie przez SSH nie musi korzystać z tego samego środowiska, co aplikacja internetowa lub zaplanowane zadanie. Następnie sprawdź ścieżkę wyszukiwania i konkretny komunikat o błędzie, zanim założysz, że brakuje pakietu.

Następnie operator bada Szkielet oraz konfigurację montowania. Szkielet współdecyduje o tym, które pliki i katalogi zostaną udostępnione w CageFS. Program może zatem istnieć na hoście, a mimo to nie być dostępny w środowisku użytkownika; podczas udostępniania należy również uwzględnić wymagane biblioteki i inne zależności.

Praktycznym rozwiązaniem nie jest podłączanie na wszelki wypadek dużych katalogów hosta. Spowodowałoby to, że widocznych byłoby więcej plików niż to konieczne do wykonania zadania. Operator powinien zamiast tego, na podstawie dokumentacji producenta, wybrać niezbędne pliki programowe i zależności, a następnie sprawdzić w przewidzianym kontekście usługi, czy narzędzie działa.

Do Konserwacja szkieletu Należy również uwzględnić zmiany w pakietach systemowych i w Panelu sterowania. CloudLinux dokumentuje okresowe aktualizacje; po wprowadzeniu określonych zmian może być konieczna aktualizacja wymuszona. Może ona być również wymagana po przebudowie serwera Apache. Nie oznacza to jednak, że po każdej aktualizacji należy wykonywać to samo polecenie ręczne.

Zaplanuj aktualizację odpowiednio do używanej platformy, a następnie sprawdź, jakie aplikacje i narzędzia są nią objęte. Jeśli aplikacja wcześniej działała, a po wprowadzeniu zmiany przestała działać, w zawężeniu zakresu problemu pomogą: data zmiany pakietu, usługa, której to dotyczy, oraz dokładny komunikat o błędzie. W ten sposób można odróżnić problem związany z wdrożeniem od błędu aplikacji.

Bezpieczna eksploatacja i świadome podejmowanie decyzji

Przy podejmowaniu decyzji operacyjnej nie liczy się tylko to, czy CageFS jest w ogóle dostępny. Operator musi wiedzieć, które konta i usługi mają być chronione, jakie programy są do tego potrzebne oraz kto odpowiada za integrację i konserwację. Ograniczony dostęp do systemu plików stanowi uzupełnienie innych środków bezpieczeństwa; nie zastępuje on ani bezpiecznych aplikacji, ani ochrony danych dostępowych.

Na szczególną uwagę zasługują pomieszczenia wspólne oraz dodatkowe moduły. CloudLinux opisuje dla /dev/shm wspólne podłączenie oraz możliwość izolacji dla każdego użytkownika. To, który wariant faktycznie ma zastosowanie, należy sprawdzić na podstawie konkretnej konfiguracji. Dodatkowe punkty montowania powinny udostępniać wyłącznie to, czego potrzebują aplikacje, ponieważ mogą one rozszerzać widoczne środowisko.

Również błąd występujący podczas uruchamiania CageFS ma znaczenie dla bezpieczeństwa. Od wersji CageFS 7.2.0-1 firma CloudLinux udokumentowała opcję, która pozwala zapobiec uruchamianiu procesów w przypadku wystąpienia takiego błędu. Sprawdź zainstalowaną wersję i aktualne ustawienia, zamiast wyciągać wnioski na temat działania tej opcji w konkretnej ofercie hostingowej na podstawie samego faktu jej istnienia.

Zmiany dotyczące szkieletu, wierzchowców lub przypisania kont należy wprowadzać w ramach uzgodnionego Procedury konserwacyjne. Należy przy tym uwzględnić ewentualne ponowne zamontowanie dysków, aplikacje, których to dotyczy, oraz okno serwisowe; należy również udokumentować, w jaki sposób można cofnąć tę zmianę w razie problemów. Następnie należy ponownie sprawdzić odpowiednie ścieżki wykonania i wymagane narzędzia przy użyciu przewidzianych kont testowych.

Dla klientów kluczową kwestią jest to, jaki rodzaj izolacji faktycznie stosuje dostawca i w jaki sposób ją weryfikuje. Z kolei operatorzy muszą brać pod uwagę zarówno potrzeby w zakresie ochrony, jak i bieżące nakłady: zbyt rozbudowane środowisko może osłabić izolację, a zbyt skromne – utrudniać działanie niezbędnych aplikacji. Oba przypadki wymagają przemyślanej konfiguracji i regularnych kontroli.