Конспект вебинара "Выбор виртуального хостинга с точки зрения безопасности"

-->
Наконец-то я добрался до составления конспекта. 

Аудио-запись можно взять здесь, а сам конспект ниже.

Если кому удобнее в PDF, то пожалуйста.

Информация приведённая ниже основана на моём личном опыте и опросе, который я проводил среди 15 первых (по выдаче поисковиков) российских хостингов и 5 западных. Всё что описано ниже ни в коем случае не является истиной в последней инстанции и должно применяться вами исходя из условий конкретно вашего случая.

1. Почему нужно об этом думать?

Даже если ваш проект отлично защищён, уязвимость в площадке хостинга может быстро свести на нет все старания программистов.

2. Часто встречающиеся ошибки в вопросах выбора хостинга

2.1 Не нужно брать хостинг у компаний, для которых сам хостинг не является основной услугой.

2.2 Бесплатный хостинг не значит не защищённый.

2.3 Не нужно переходить с виртуального хостинга на VPS/VDS в надежде повышения безопасности. В первом случае за неё отвечают опытные администраторы. Во втором — вы сами. Если у вас нет достаточных для этого знаний, то можно сделать только хуже. Осуществляйте такой переход только если вы полностью осознаёте что делаете и какой выигрыш от этого получите.

2.4 Дешёвый, недавно вышедший на рынок хостинг не всегда является плохим и ужасным. Вполне возможно что низкая цена является способом привлечения клиентов, или следствием внедрения новых технологий.

3. Когда хостинг выбран

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

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

3.3 Посмотрите FAQ/Wiki хостера. Изучайте любую информацию связанную с защитой сайтов клиентов.

4. Узнаём о хостере более подробно

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

4.1 Противодействие атакам

4.1.1 Есть ли система обнаружения вторжений (IDS/IPS)? Редко где встречаются. Может сильно помочь предотвращая атаки как через уже известные уязвимости, так и через совсем новые (0day). Часто IDS/IPS хостера не оповещает клиента о зафиксированных инцидентах, но иногда можно через запрос в тех. поддержку получить логи работы системы за определённый период времени. Редко IP нападающего блокируется на некоторое время.

4.1.2 Средства борьбы с подбором пароля. К сожалению сейчас почти не встречаются. Могут оповещать клиента или нет о происходящих попытках подбора. При фиксировании атаки могут блокировать на некоторое время либо нападающего, либо аккаунт (не сайт!), к которому производится подбор. Если таковые есть, важно узнать на каких именно сервисах (FTP/SSH/биллинг) они задействованы.

4.1.3 Антивирусная проверка. Чаще всего можно встретить только проверку почтового трафика, но иногда хостер проверяет и файлы сайтов клиентов. При нахождении вредоносного кода хостер оповестит вас. В некоторых случаях компания может заблокировать доступ к заражённому сайту, что спасёт вашу репутацию перед пользователями (вряд ли они вернутся на распространяющий вирусы сайт) и рейтинг сайта в поисковиках (ресурс не попадёт в блэк-лист).

4.1.4 Проверка сайтов клиентов на уязвимости. Очень редкая услуга хостеров. Из пятнадцати российских встретилась всего у одного. Реализуется в виде запроса на проверку из панели администрирования, после выполнения которого клиент получает соответствующий отчёт. Вещь полезная, но нужно понимать что без последствий для сайта может не пройти (начиная от комментариев со странным содержимым и кончая потерей работоспособности). Так что лучше создать клон проверяемого ресурса на отдельном поддомене и проверять уже его.

4.2 Возможности ограничения доступа

4.2.1 Можно ли ограничить доступ по IP-адресу к средствам администрирования? Иногда компании разрешают обращения к определённым службам с IP-адресов всех клиентов (я встречал это в отношении удалённого доступа к MySQL-базам), но это эффективно до тех пор пока нападающий не приобретёт себе аккаунт. Иногда такие ограничения накладываются через запрос в ТП или в панели управления хостинг-аккаунтом. Иногда и через личные конфигурационные файлы клиента (например .ftpaccess).

4.2.2 Есть ли удалённый доступ к MySQL? Плохо если есть и его никак не запретить для отдельного аккаунта. Чаще всего он отсутствует. Иногда можно к определённой базе разрешить удалённые обращения через обращение в ТП или панель администрирования.

4.3 Пароли

4.3.1 Совпадают ли при регистрации нового аккаунта пароли на разные средства администрирования? Если да, то можно ли их сменить? Если нельзя, то лучше с таким хостером не связываться. Иногда нельзя убрать одинаковые пароли только на определённые сервисы, что тоже не есть хорошо.
4.3.2 Есть ли регулярная смена пароля для доступа в биллинг?

4.4 Права доступа
4.4.1 Изолированы ли пользователи друг от друга? Если нет, то стоит хорошо подумать прежде чем работать с таким хостером. Либо серьёзно следить за правами доступа на скрипты/папки вашего сайта и никогда не ставить на них права 777. Хотя многие веб-приложения требуют установки таких прав на отдельные директории, это не всегда действительно необходимо. Иногда может быть достаточно 770 или даже 700.

4.4.2 Запрещает ли веб-сервер доступ в директории и файлы с правами 777? Редко где встречается, но очень полезно в тех случаях, когда пользователи друг от друга не изолированы. Даже если злоумышленник попробует атаковать изнутри, найдёт директорию в которую сможет писать и поместит туда вредоносный код, выполнить его ему не удастся.

4.5 Лог-файлы

4.5.1 К логам каких служб пользователь имеет доступ? Иногда их ведение нужно включить в панели администрирования или через обращение в ТП. Редко, но бывает когда клиент к логам доступа вообще не имеет и никак получить их не может.
4.5.2 Как и где хранятся лог-файлы? Они могут быть доступны по FTP и лежать на уровень ниже веб-директории. Этот вариант очень опасен если для сайта не установлена опция open_basedir в значение веб-директории, запрещая тем самым PHP работать с файлами/папками за её пределами. В случае взлома злоумышленник сможет удалить или модифицировать их. Также логи могут быть доступны только для просмотра через панель администрирования (идеальный вариант) или же находиться где-то вне директории доступной по FTP (работа с ними происходит например через SSH). В последнем варианте обязательно узнайте можно ли их удалять/модифицировать действуя от имени веб-сервера.

4.5.3 Желательно узнать логи каких служб ведутся ещё, помимо тех что доступны клиенту. Можно ли их получать при запросе в ТП?

4.6 Конфигурация PHP (рекомендую сразу зайти на http://ru2.php.net/manual/ru/ini.list.php и http://ru2.php.net/manual/ru/configuration.changes.modes.php чтоб смотреть какие опции что означают и через что могут быть изменены).
4.6.1 Как пользователь может менять настройки PHP для своего сайта? Тут всего 2 варианта — через .htaccess или php.ini. Последний лучше тем что позволяет определять директиву disable_functions (из перечисленных ниже). Вполне возможно что какие-то отдельные параметры можно будет изменить только через обращение в ТП.
4.6.2 Установлен ли Suhosin?
4.6.3 От чьего имени запускаются скрипты при обращении к ним браузером?
4.6.4 Смотрим конфигурацию PHP.

4.6.4.1 Установлена ли disable_functions? Если нет и у вас есть собственный php.ini, желательно вписать туда функции выполнения системных команд (popen(), system(), exec(), passthru(), proc_open(), pcntl_exec()).
4.6.4.2 Отключена ли allow_url_include? Если нет и в ней нет необходимости — отключить.
4.6.4.3 Отключена ли display_errors? Если нет — отключить.
4.6.3.4 Какое значение имеет error_reporting? Если нет возможности изменить display_errors можно установить в 0 данную опцию — эффект аналогичен.
4.6.3.5 Включён ли log_errors? Если нет — включить. Установить удобное значение error_log. Так вы всегда будете иметь лог ошибок, а пользователи их видеть не будут.
4.6.3.6 Установлена ли open_basedir? Если нет желательно установить в удобное для вас значение. Это поможет изолировать взломщика внутри выбранной директории при удачной атаке.
4.6.3.7 Отключена ли register_globals? Если нет и для функционирования сайта она не нужна — отключить.
4.6.3.8 Включена ли session.cookie_httponly? Желательно включить. Поможет предотвращать кражу идентификатора сессии при XSS-нападениях.
4.6.3.9 Какое значение в session.save_path? Обратите на эту опцию особое внимание. Важно чтоб она указывала на директорию доступную только вам. У большинства хостингов по умолчанию здесь прописаны общедоступные директории типа /tmp, что делает все файлы сессий доступными каждому клиенту хостинга.

4.7 DDoS
4.7.1 Есть ли минимальные средства защиты от DDoS атак? Например хостер может установить ограничения на обращения к сайту в секунду для одного клиента.
4.7.2 Что сделает хостер если DDoS-атака на ваш сайт будет слишком сильной? Чаще всего сайт либо будет отключен, либо станет «идти вверх» по тарифам, получая всё больше и больше ресурсов.

4.8 Резервные копии
4.8.1 Имеет ли к ним клиент прямой доступ? Аналогично лог-файлам, часто резервные копии лежат на уровень ниже веб-директории. При таком положении дел отсутствие ограничений через open_basedir может дать злоумышленнику доступ к резервным копиям в случае взлома сайта. Идеальным, на мой взгляд, вариантом является доступ к ним через панель администрирования и только с возможностью развёртывания, а не загрузки, удаления и т. д.
4.8.2 Как часто делаются резервные копии и какое время хранятся на сервере? Чем больше время хранения — тем лучше. Обратите внимание на то, что файлы сайта и база данных могут архивироваться с разной частотой. Может быть и так, что сохранятся будут лишь те файлы, которые были изменены со времени последнего резервного копирования.
4.8.3 Может ли клиент самостоятельно проводить восстановление из копии?

4.9 Взлом
4.9.1 Как можно восстановить доступ при его утрате и к аккаунту на хостинге, и к почте которая использовалась при регистрации? Самый лучший вариант — предоставление скана паспорта или письмо на фирменном бланке (для компаний).
4.9.2 Чем может помочь ТП в случае взлома? Сможет ли изменить в кратчайшее время все пароли? Сможет ли предоставить лог-файлы сервисов администрирования за период осуществления взлома? Иногда поддержка может бесплатно провести ручную чистку файлов сайта от вредоносных вставок, если сигнатура вставки статична.

Благодарю redreem с форума phpforum.ru за предоставление основы для конспекта.