Jakie są najbardziej odpowiednie poziomy użytkowników i uprawnień dla witryn Drupal na hostingu współdzielonym?

Chociaż witryna Drupal zawiera szczegółowe informacje na temat uprawnień i bezpieczeństwa, istnieją tylko niejasne / niejasne odniesienia do hostingu współdzielonego . Z punktu widzenia Drupala, jaka jest najbezpieczniejsza konfiguracja (poziom własności i uprawnień) dla witryny na hostingu współdzielonym?

Jako przykład rodzaju informacji, których szukam, WordPress sugeruje następujące wspólne ustawienia hostingu:

• Wszystkie pliki powinny być własnością rzeczywistego konta użytkownika, a nie konta użytkownika używanego w procesie httpd.
• Własność grupy nie ma znaczenia, chyba że istnieją specyficzne wymagania grupy dotyczące sprawdzania uprawnień procesu serwera WWW. Zazwyczaj tak nie jest.
• Wszystkie katalogi powinny mieć 755 lub 750.
• Wszystkie pliki powinny mieć format 644 lub 640. Wyjątek: wp-config.php powinien mieć wartość 600, aby uniemożliwić innym użytkownikom jego odczytanie.
• Nigdy nie należy podawać żadnych katalogów 777, nawet katalogów przesyłanych. Ponieważ proces php jest uruchomiony jako właściciel plików, otrzymuje uprawnienia właścicieli i może zapisywać nawet w katalogu 755.

Opcje hostingu

Opcje hostingu witryny internetowej są zazwyczaj jedną z następujących czynności:

• serwer dedykowany
• wirtualny serwer prywatny (VPS)
• dzielony hosting

Dzięki serwerowi dedykowanemu tylko jedna witryna jest hostowana na fizycznym komputerze, a konfiguracja jest tak bezpieczna jak sam komputer.

Dzięki VPS oprogramowanie działa na tym samym komputerze fizycznym, co maszyny wirtualne innych użytkowników. Jest to jednak funkcjonalnie równoważne z serwerem dedykowanym. Co najważniejsze, VPS zapewnia prywatność i bezpieczeństwo dedykowanego serwera.

Dzięki współdzielonemu hostingowi Twoja strona internetowa znajduje się w systemie plików współdzielonym z innymi użytkownikami. To niestety czyni go mniej bezpiecznym niż wtedy, gdy działa na dedykowanym serwerze lub VPS. W dalszej części tego artykułu omówiono bezpieczeństwo WCMS we współdzielonym środowisku hostingowym.

Środowisko

Współdzielone środowisko hostingowe można uznać za składające się z serwera WWW, systemu plików, pliku ustawień, bazy danych i niektórych użytkowników.

W poniższych przykładach założono, że konto właściciela to „tom”, a plik ustawień (zawierający poświadczenia bazy danych) nosi nazwę „settings.php”.

Proces serwera WWW może przebiegać z uprawnieniami użytkownika konta właściciela „tom” lub z uprawnieniami grupy grupy „www”, w zależności od konfiguracji.

Przyjmuje się także standardowe środowisko Gnu / Linux lub Unix i zakłada się, że czytelnik rozumie system kontroli dostępu Unix z oddzielnymi uprawnieniami do odczytu (r), zapisu (w) i wykonania / dostępu do katalogu (x) podzielonymi na trzy bloki (użytkownik, grupa, inne).

Zanim przejdę do omówienia konkretnych ustawień, pomocne może być wyszczególnienie warunków, które chcemy spełnić:

1. Aby witryna mogła działać, serwer musi mieć dostęp do odczytu do wszystkich plików tworzących witrynę oraz dostęp do katalogu do wszystkich katalogów tworzących witrynę.
2. Aby zapewnić bezpieczne działanie, serwer WWW nie może mieć dostępu do zapisu do żadnego z obsługiwanych plików.
3. Aby zapewnić bezpieczne działanie, skrypt internetowy uruchamiany przez nieuczciwego użytkownika nie może mieć dostępu do odczytu plików należących do innego użytkownika.
4. Aby właściciel mógł pracować nad własną witryną przy użyciu interfejsu CLI, użytkownik musi mieć dostęp do odczytu i zapisu własnych plików.
5. Aby chronić pliki przed dostępem przez innych użytkowników korzystających z CLI, „innego” blok powinien mieć żadnych uprawnień określonych.

Niestety na wspólnym hoście możesz mieć tylko 4 na 5. Nie wiem, w jaki sposób możesz spełnić wszystkie pięć warunków na wspólnym hoście.

O ile mi wiadomo, dostawcy hosta współdzielonego używają dwóch różnych konfiguracji. Oba są omówione poniżej, wraz z uprawnieniami do używania w celu najlepszej ochrony plików i katalogów oraz warunkami, które konfiguracja nie spełnia.

Konfiguracja 1: serwer WWW działa jako właściciel

Jest to najczęściej używana konfiguracja AFAIK. Serwer WWW działa jako właściciel plików. Oznacza to, że nieuczciwy użytkownik nie może użyć swojego użytkownika serwera WWW do uruchomienia skryptu do odczytu plików innego użytkownika. Ten typ konfiguracji chroni również użytkowników przed sobą w interfejsie CLI.

Oznacza to jednak również, że nie możemy mieć oddzielnych uprawnień dla właściciela i serwera WWW. Aby spełnić warunek 2 przy tego typu konfiguracji, musisz ograniczyć uprawnienia do zapisu dla właściciela, aby uniemożliwić dostęp do zapisu dla serwera WWW do wszystkiego oprócz katalogu wysyłania.

Uprawnienia:

Directories:  500 r-x --- --- tom.tom
Files:        400 r-- --- --- tom.tom
settings.php: 400 r-- --- --- tom.tom
Upload Dir.:  700 rwx --- --- tom.tom

Niestety oznacza to, że warunek 4 nie może być spełniony. Tj. Witryna nie może być utrzymywana przez CLI. Właściciel będzie zobowiązany do korzystania z pewnego rodzaju internetowego pulpitu nawigacyjnego w celu uzyskania dostępu do witryny (zalecam, aby właściciel zachował kopię na jakimś serwerze pomostowym, na którym ma nieograniczony dostęp, i zmiany lustrzane wprowadzone na serwerze pomostowym do hosta współdzielonego ).

Konfiguracja 2: Serwer WWW działa jako członek grupy www

Z tej konfiguracji korzystają niektórzy (IMHO) mniej profesjonalni dostawcy wspólnego hosta. Serwer WWW działa jako członek grupy www i otrzymuje wymagany dostęp do odczytu przez blok grupy:

Uprawnienia:

Directories:  750 rwx r-x --- tom.www
Files:        640 rw- r-- --- tom.www
settings.php: 640 rw- r-- --- tom.www
Upload Dir.:  770 rwx rwx --- tom.www

Te ustawienia mają tę zaletę, że dają właścicielowi pełny dostęp do jego plików za pośrednictwem interfejsu CLI i ograniczają serwer WWW tylko do odczytu.

Jednak nie spełnia również warunku 3. To znaczy, że pozwala nieuczciwemu użytkownikowi na współdzielonym hoście (lub hakerowi, który naruszył witrynę innego użytkownika współużytkującego hosta) uruchomienie skryptu w celu odczytania dowolnego pliku, który może być odczytany przez serwer internetowy. Daje to nieuczciwemu skryptowi dostęp do pliku settings.php z poświadczeniami bazy danych, co sprawia, że ​​całkowite przejęcie witryny jest banalne.

Radzę unikać tego typu konfiguracji.

Dodatek: Jak niebezpieczne jest korzystanie z hosta współdzielonego?

Na pewno nie umieściłbym niczego wrażliwego, takiego jak numery kart kredytowych lub dokumentacja medyczna, na wspólnym hoście. Ale dzielony hosting jest tani i jest w tym atrakcja. Sam korzystam z hostingu współdzielonego w kilku moich witrynach. Nie zostałem jeszcze zhakowany, ale wiem, że istnieje ryzyko i jestem przygotowany na dzień, w którym to nastąpi. Jeśli ktoś mnie zhakuje, po prostu usunę wszystko ze współużytkowanego hosta i ponownie zainstaluję witrynę z kopii lustrzanej przechowywanej na bezpiecznym serwerze pomostowym.

W przypadku „config 2” głównym problemem są inne . Jeśli jakaś inna strona internetowa, z którą współdzielisz hosta, zostanie naruszona, twoja strona jest również na lunch. Uzależnienie bezpieczeństwa od innej strony, której nie znasz i nie masz nad nią kontroli, nie jest dobrym pomysłem. Dlatego zalecam unikanie organizacji hostów typu „config 2”.

Dzięki „config 1” samodzielnie kontrolujesz bezpieczeństwo swojej witryny. To jest lepsze (zwłaszcza jeśli wiesz, co robisz). Ale to nie jest głupie. Nikt nie jest doskonały, a jeśli przejdziesz do góry, a Twoja witryna zostanie naruszona, atakujący będzie miał dostęp do każdego pliku przechowywanego na tym hoście, który należy do Ciebie. Innymi słowy, aby zminimalizować ryzyko, że zostaniesz zhakowany, nie trzymaj na tym hoście niczego , co mogłoby zaszkodzić, jeśli ktoś inny uzyska do niego dostęp. W szczególności nie przechowuj poczty e-mail na tym udostępnianym hoście. Zazwyczaj w wiadomościach e-mail znajduje się mnóstwo poufnych danych, więc nie należy ich nigdzie w pobliżu serwera WWW wykonywać jako „ty”.

A jeśli aplikacja internetowa obsługuje poufne dane, upewnij się, że budżet pozwala na dedykowanego hosta lub VPS.

Możesz także przeczytać ten przewodnik dotyczący zabezpieczania uprawnień do plików i własności na Drupal.org.