SkyCase — Делаем безопасный хостинг PHP-сайтов, хостинг без php.

SkyCase

авто мобильная лояльность

Делаем безопасный хостинг PHP-сайтов

Эта статья написана только по одной причине: мы сами сначала наступили на грабли. Наши сайты (skycase.ru и skycase.pro) сделаны на WordPress, т.е., внутри у них PHP и MySQL. Когда мы искали хостинг для них последнее о чем мы думали была безопасность. А зря. Буквально через два месяца сайты были взломаны, на главной странице висела фишинговая форма входа в Facebook. Удивительным образом это событие совпало с недоступностью сайта самого хостинг-провайдера, а недолгие поиски в Сети нашли несколько прежних обсуждений о взломанных серверах этого хостера. Конечно же, мы делаем бэкапы, сайты были восстановлены за несколько часов, но Gooogle успел добавить их в черный список. И последствия этого мы ощущаем до сих пор. Так вот, это статья для тех, кто (больше) не хочет наступать на грабли shared web hosting services — «обычных» сервисов хостинга сайтов.

Чем плох обычный PHP хостинг?

Рассмотрим поставленный вопрос только из соображений безопасности вашего сайта.

  1. Все хостеры размещают на одном сервере по несколько сотен, а иногда и тысяч, сайтов своих клиентов. Если злоумышленник взломал такой сервер, то все сайты на этом сервере становятся жертвами.
  2. Если вы приобрели хостинг для нескольких сайтов (соблазнившись соображениями очевидной экономии, как это когда-то сделали мы), то все ваши файлы на хостинге принадлежат одному и тому же пользователю системы, выданному вам хостером. Т.е., если злоумышленник смог получить доступ к системе, взломав один из ваших сайтов, все остальные ваши сайты тоже станут его жертвами.

Как сделать безопасным хостинг сайта?

Безопасность — это всегда солнечный зайчик. Его не поймать. Поэтому для обеспечения безопасности собственных сайтов мы пришли к разумному пересечению кривых паранойи и ресурсных затрат. Ресурсы здесь, как и всегда, это деньги и время. Вот наш security рецепт.

  1. Используйте виртуальные выделенные сервера (VDS) вместо обычного shared хостинга.

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

  • Вы сами можете настроить PHP: редактировать php.ini, устанавливать только необходимые модули PHP, …
  • На своем виртуальном сервере можно безопасно разместить несколько сайтов.
  • Можно установить любимый фаервол и дать своей паранойе по-настоящему разгуляться!

Команда SkyCase совершенно бесплатно для себя рекомендует присмотреться к сервису digitalocean.com, где сейчас за 5$ в месяц можно арендовать виртуальный сервер с 512 MB оперативной памяти, 20 GB на SSD диске, 1 TB трафика и кучей прочих плюшек вроде снэпшотов и бэкапов.

  • Настройте SSH-аутентификацию по ключам и запретите доступ по логину-паролю. Инструкции для вашего сервера вы легко найдете в интернете.
  • Создайте в системе по одному специальному пользователю на каждый размещенный на сервере сайт и запускайте PHP-скрипты каждого конкретного сайта от имени соответствующего пользователя. Таким образом, взломав один сайт, злоумышленник не сможет получить доступ ни к системе, ни к другим сайтам на этом сервер. Сказать легко, а сделать … мы расскажем вам как.
  • Запуск PHP-скриптов от имени пользователя, которому принадлежит сайт

    Концепт такой: nginx работает как фронтенд, раздает статику, а динимаку, PHP-скрипты, обрабатывает PHP-демон php5-fpm.

    А теперь пора засучить рукава. Вы уже разобрались с SSH, и находитесь в уютной консоли свеже-купленного виртуального сервера. Сразу оговорюсь, что все инструкции ниже написаны (и проверены) для Ubuntu версии 12.04. Если вы предпочитаете другие дистрибутивы, то процесс конфигурирования будет примерно таким же, с точностью до управления менеджером пакетов и расположением конфиг-файлов в системе.

    1. Устанавливаем nginx (в минимальной комплектации) и PHP
    2. Создаем системного пользователя с именем USERNAME. Он будет хозяином конкретного сайта, и будет удобно если его имя недвусмысленно говорит о названии сайта.
    3. В домашнем каталоге пользователя USERNAME создаем каталог www, который будет являться рутовым для данного сайта.
    4. Создаем тестовый PHP-скрипт чтобы позже проверить что вся схема работает исправно.
    5. К динамическому контенту (PHP-скриптам) сайта доступ, притом только на чтение, должен быть только у пользователя USERNAME.
    6. PHP-демон будет обрабатывать запросы, пришедшие на соответствующий сокет от nginx, от имени пользователя USERNAME. Для этого надо скопировать дефолтный конфиг fpm, назвать его соответственно, а в самом конфиге поменять имя и группу пользователя и имя слушаемого им сокета.
    7. Создаем конфигурацию сайта в nginx, где перенаправляем все запросы на динамический контент на PHP-демона через сконфигуренный в пункте 6 сокет. Статитка раздается nginx-ом прямо с файловой системы.
    8. Чтобы nginx работал с php5-fpm демоном нужно в файле конфигурации PHP-демона изменить значение cgi.fix_pathinfo на 0.
    9. Пора проверять! Откройте в браузере нашу тестовую страницу skycase-example.com/test.php. Должна открыться стандартная страница со всеми подробностями настройки PHP. Обратите внимание на раздел Environment, он должен говорить нам, что:

    Нет, не совсем. Сейчас nginx работает от имени пользователя www-data, а файлы сайта эксклюзивно принадлежат пользователю USERNAME и группе USERNAME. Nginx раздает статику, но не имеет к ней доступа. Плохо. Как я и говорил в начале статьи, нужно удерживать паранойю в узде. Разумным компромиссом будет разрешить доступ для группы www-data на чтение для всей статики сайта, сохранив эксклюзивное право на чтение PHP-скриптов для пользователя USERNAME. Что мы и проделаем.

    На старый вопрос «Как по-простому сделать систему X безопасной» есть старый ответ. Никак. Безопасность — это всегда компромисс. Стоит ли «заморачиваться», да еще и так изрядно как описано в этой статье — решать вам. Если от сайта зависит имидж вашей компании, работа с клиентами, и, наконец, доход, тогда… В общем, мы стали заморачиваться.