hosting współdzielony

Hosting współdzielony to usługa, w której strona działa na jednym serwerze razem z wieloma innymi stronami ^[1]. Moc procesora i pamięć RAM są współdzielone dynamicznie, a każde konto dostaje własne limity, na przykład miejsca na dysku ^[1]. To najtańsza i najpopularniejsza forma utrzymania małych stron WordPress. Jej bezpieczeństwo zależy w dużej mierze od tego, jak dostawca oddziela od siebie konta klientów ^[2].

Jak działa

Na jednym systemie operacyjnym działa jeden serwer WWW i jeden zestaw interpreterów PHP, a każdy klient dostaje swoje konto z katalogiem na pliki, bazą danych i panelem. Z punktu widzenia strony serwer wygląda jak prywatny, ale jądro systemu, dyski i sieć są wspólne. Dlatego potrzebne są dwa rodzaje granic: granica dostępu do plików i procesów oraz granica zużycia zasobów.

Poradnik SEOHOST wymienia wśród sposobów oddzielenia użytkowników chroot, kontenery i osobnych użytkowników systemowych ^[2]. SAX.PL podaje jako przykład mechanizmu, który uniemożliwia jednej stronie „zajrzenie” do plików innej, CloudLinux z CageFS ^[1].

Mechanizmy izolacji

Poszczególne mechanizmy działają na różnych poziomach i się uzupełniają.

Dokumentacja CloudLinux opisuje CageFS jako zwirtualizowany system plików, który zamyka każdego użytkownika w osobnej „klatce”. Użytkownik nie widzi innych użytkowników ani ich nazw, nie ma dostępu do plików konfiguracji serwera, a w katalogu /proc nie widzi cudzych procesów ^[4]. LVE to z kolei technologia na poziomie jądra, oparta w nowszych wersjach na cgroups, której celem jest to, by żadna pojedyncza strona nie mogła położyć całego serwera ^[5].

Dyrektywa open_basedir ogranicza pliki dostępne dla PHP do wskazanego drzewa katalogów, a dowiązania symboliczne są przy tym rozwiązywane ^[6]. Domyślnie jednak pozwala otwierać wszystkie pliki ^[6]. Podręcznik PHP ostrzega też, że dyrektywę disable_functions można obejść i nie należy jej traktować jako wystarczającego zabezpieczenia na hostingu współdzielonym ^[6].

W WordPressie

Dokumentacja WordPressa stwierdza wprost: jeśli strona działa na serwerze współdzielonym, a inna strona na tym serwerze zostanie przejęta, zagrożona może być także ona, nawet przy przestrzeganiu wszystkich zaleceń poradnika ^[3]. Zjawisko przenoszenia infekcji między kontami nazywa się cross-site contamination. Schemat poniżej pokazuje je przy słabej izolacji.

RYS. 1Zakażenie przez sąsiednie konto

Wiele zależy od uprawnień plików. Dokumentacja WordPressa zaleca, by wszystkie pliki należały do konta użytkownika i były przez nie zapisywalne, a prawo zapisu dla serwera WWW miały tylko pliki, które tego wymagają ^[3]. Jeśli pliki są zapisywalne dla wszystkich, proces PHP innego klienta może je zmienić. Szczególnie cenny dla atakującego jest wp-config.php z hasłem do bazy; stąd praktyki opisywane jako utwardzanie pliku wp-config.php (wp-config hardening).

Jedno konto hostingowe często obsługuje kilka instalacji WordPressa. Wtedy działają one jako ten sam użytkownik systemowy i izolacja dostawcy ich nie rozdziela. Webshell wgrany przez podatność w jednej z nich ma dostęp do plików pozostałych. Dotyczy to zwłaszcza zapomnianych kopii: starej wersji strony w podkatalogu, instalacji testowej albo porzuconego sklepu, których nikt nie aktualizuje. Przy czyszczeniu przejętej strony trzeba więc sprawdzić całe konto, a nie tylko katalog zainfekowanej instalacji.

Zagrożenia i skutki

• Infekcja z sąsiedztwa. Opisana wyżej sytuacja, przed którą ostrzega dokumentacja WordPressa ^[3].
• Hałaśliwy sąsiad. Nagły wzrost ruchu na jednej stronie może chwilowo spowolnić pozostałe ^[1]. Podobnie działa atak odmowy usługi (denial of service) skierowany na stronę sąsiada. Limity LVE mają temu przeciwdziałać ^[5].
• Wspólny adres IP. Wiele stron ma ten sam adres IP, więc wpis na czarną listę (blacklisting) adresu z powodu jednego klienta, np. wysyłki spamu, może dotknąć innych.
• Brak wpływu na konfigurację. Wersję PHP, moduły serwera i reguły WAF ustala dostawca. Stara wersja PHP to ryzyko opisane w haśle koniec wsparcia dla wersji PHP.

Dobre praktyki

Podział obowiązków między dostawcą a klientem to przykład modelu współdzielonej odpowiedzialności (shared responsibility model).

Po stronie dostawcy poradnik SEOHOST wymienia izolację kont i zasobów, regularne kopie zapasowe z możliwością przywracania, zaporę sieciową, WAF i podstawową ochronę przed atakami DDoS oraz aktualne oprogramowanie serwerowe, w tym PHP i bazy danych ^[2]. Przy wyborze hostingu warto zapytać, jaki mechanizm izolacji stosuje dostawca i czy każde konto działa jako osobny użytkownik systemowy.

Po stronie właściciela strony:

• osobne konto hostingowe dla każdej ważnej strony zamiast kilku instalacji w jednym katalogu;
• zasada najmniejszych uprawnień dla plików i kont FTP, najlepiej dostęp przez SFTP;
• aktualizacja wtyczek i usuwanie nieużywanych, zgodnie z dokumentacją WordPressa ^[3];
• własna kopia zapasowa poza serwerem; dokumentacja WordPressa zaleca regularne kopie danych, w tym baz MySQL ^[3].

Hosting współdzielony nie jest z założenia niebezpieczny. Ryzyko rośnie, gdy izolacja jest słaba, a na jednym koncie leżą porzucone instalacje, o których nikt nie pamięta.