Каковы наиболее подходящие пользователи и уровни разрешений для сайтов Drupal на виртуальном хостинге?

Хотя на сайте Drupal подробно рассказывается о разрешениях и безопасности, существуют лишь смутные / неясные ссылки на виртуальный хостинг. С точки зрения Drupal, какова наиболее безопасная настройка (уровень владения и разрешения) для сайта на виртуальном хостинге?

В качестве примера информации, которую я ищу, WordPress предлагает следующие настройки общего хостинга:

• Все файлы должны принадлежать фактической учетной записи пользователя, а не учетной записи пользователя, используемой для процесса httpd.
• Принадлежность группы не имеет значения, если только нет особых групповых требований для проверки разрешений процесса веб-сервера. Обычно это не так.
• Все каталоги должны быть 755 или 750.
• Все файлы должны быть 644 или 640. Исключение: wp-config.php должно быть 600, чтобы другие пользователи на сервере не могли его прочитать.
• Не нужно давать 777 каталогов, даже загружать каталоги. Поскольку процесс php запускается как владелец файлов, он получает разрешения владельцев и может записывать даже в каталог 755.

Варианты хостинга

Варианты хостинга для сайта сайта, как правило, один из следующих:

• Выделенный сервер
• виртуальный частный сервер (VPS)
• виртуальный хостинг

При выделенном сервере только один сайт размещается на физическом компьютере, и конфигурация так же безопасна, как и сам компьютер.

С VPS ваше программное обеспечение работает на том же физическом компьютере, что и виртуальные машины других пользователей. Тем не менее, он функционально эквивалентен выделенному серверу. Самое главное, VPS имеет конфиденциальность и безопасность выделенного сервера.

Благодаря общему хостингу ваш веб-сайт находится в файловой системе, доступной другим пользователям. Это, к сожалению, делает его менее безопасным, чем когда он работает на выделенном сервере или VPS. В оставшейся части этой статьи обсуждается безопасность WCMS в среде общего хостинга.

Окружающая обстановка

Среду общего хостинга можно рассматривать как состоящую из веб-сервера, файловой системы, файла настроек, базы данных и некоторых пользователей.

В следующих примерах предполагается, что учетной записью владельца является «tom», а файл настроек (содержащий учетные данные базы данных) называется «settings.php».

Процесс веб-сервера может выполняться с правами пользователя учетной записи владельца "tom" или с правами группы группы "www" в зависимости от конфигурации.

Кроме того, предполагается стандартная среда Gnu / Linux или Unix, и предполагается, что читатель понимает систему управления доступом Unix с отдельными правами чтения (r), записи (w) и выполнения / доступа к каталогу (x), разделенными на три блока. (пользователь, группа, другое).

Прежде чем перейти к обсуждению конкретных настроек, может быть полезно перечислить условия, которые мы хотим удовлетворить:

1. Чтобы веб-сайт работал, веб-сервер должен иметь доступ для чтения ко всем файлам, составляющим сайт, и доступ к каталогам для всех каталогов, составляющих сайт.
2. Для безопасной работы веб-сервер не должен иметь права на запись ни в один из файлов, которые он обрабатывает.
3. Для безопасной работы веб-скрипт, запускаемый мошенническим пользователем, не должен иметь права на чтение файлов, принадлежащих другому пользователю.
4. Чтобы владелец мог работать на своем собственном сайте с помощью интерфейса командной строки, пользователь должен иметь права на чтение и запись для своих собственных файлов.
5. Чтобы защитить файлы от доступа других пользователей с помощью интерфейса командной строки, блок «другие» не должен иметь никаких установленных разрешений.

К сожалению, на общем хосте у вас может быть только 4 из 5. Я не знаю, как вы можете выполнить все пять условий на общем хосте.

Насколько я знаю, провайдерами общих хостов используются две разные конфигурации. Оба обсуждаются ниже, наряду с разрешениями для лучшей защиты файлов и каталогов, а также с тем, какое условие конфигурация не удовлетворяет.

Конфигурация 1: веб-сервер работает как владелец

Это AFAIK наиболее широко используемая конфигурация. Веб-сервер работает как владелец файлов. Это означает, что пользователь-мошенник не может использовать пользователя своего веб-сервера для запуска сценария для чтения файлов другого пользователя. Этот тип конфигурации также защищает пользователей друг от друга в CLI.

Однако это также означает, что у нас не может быть отдельных разрешений для владельца и веб-сервера. Чтобы выполнить условие 2 с этим типом установки, необходимо ограничить права на запись для владельца, чтобы запретить доступ на запись для веб-сервера ко всему, кроме каталога загрузки.

Разрешения:

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

К сожалению, это означает, что условие 4 не может быть выполнено. Т.е. сайт нельзя поддерживать через CLI. Владелец будет вынужден использовать своего рода веб-панель управления для доступа к сайту (я рекомендую, чтобы владелец сохранял копию на каком-либо промежуточном сервере, к которому у него есть неограниченный доступ, и отражал изменения, сделанные на промежуточном сервере, на общем хосте ).

Конфигурация 2: веб-сервер работает как участник группы www

Эта конфигурация используется некоторыми (ИМХО) менее профессиональными поставщиками решений с общим хостом. Веб-сервер работает в качестве члена группы www, и ему предоставляется необходимый доступ для чтения через групповой блок:

Разрешения:

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

Эти настройки имеют то преимущество, что дают владельцу полный доступ к своим файлам через интерфейс командной строки и ограничивают веб-сервер только доступом для чтения.

Однако он также не удовлетворяет условию 3. Т.е. он позволяет мошенническому пользователю на общем хосте (или хакеру, который скомпрометировал сайт другого пользователя, разделяющего хост), запустить сценарий для чтения любого файла, который может быть прочитан веб сервер. Это дает мошенническому сценарию доступ к файлу settings.php с учетными данными базы данных, что упрощает полный контроль над сайтом.

Я рекомендую избегать такого типа конфигурации.

Приложение: Насколько опасно использовать общий хост?

Я, конечно, не стал бы размещать на общем хосте ничего конфиденциального, например номера кредитных карт или медицинских карт. Но виртуальный хостинг дешевый, и в этом есть привлекательность. Я сам использую виртуальный хостинг для нескольких своих сайтов. Меня еще не взломали, но я знаю, что риск существует, и я готов к тому дню, когда это произойдет. Если меня взломают, я просто удалю все на общем хосте и переустановлю сайт с зеркальной копии, которую я храню на безопасном промежуточном сервере.

С «конфигом 2» главная проблема - остальные . Если какой-либо другой веб-сайт, с которым вы делитесь хостом, будет взломан, ваш веб-сайт также будет обеденным. Заставлять безопасность зависеть от другой стороны, которую вы не знаете и не контролируете, - не очень хорошая идея. Вот почему я рекомендую избегать хостинга типа "config 2".

С «config 1» вы один контролируете безопасность своего веб-сайта. Это лучше (особенно если вы знаете, что делаете). Но это не надежно. Никто не идеален, и если вы будете обмануты и ваш сайт скомпрометирован, злоумышленник получит доступ ко всем файлам, хранящимся на том хосте, который вам принадлежит. Другими словами, чтобы минимизировать ущерб при взломе, не храните на этом хосте ничего , что могло бы причинить вред, если кто-то другой получит к нему доступ. В частности, не храните свою электронную почту на этом общем хосте. Обычно в электронной почте хранятся тонны конфиденциальных данных, поэтому вы не хотите, чтобы они находились рядом с веб-сервером, работающим как «вы».

И если ваше веб-приложение обрабатывает конфиденциальные данные, убедитесь, что ваш бюджет предусматривает выделенный хост или VPS.

Возможно, вы также захотите ознакомиться с этим руководством по защите прав доступа и владения файлами на Drupal.org.