![Drupal для параноиков: безопасность сайта и системного окружения VPS и выделенных серверов А.Графов < [email_address] >](https://image.slidesharecdn.com/drupal-paranoia-090828150153-phpapp02/85/drupal-paranoia-1-320.jpg)
![Проблемы ,[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (19)
Destacado
Destacado (20)
Similar a Drupal Paranoia
Similar a Drupal Paranoia (20)
Más de Drupal Camp Kyiv
Más de Drupal Camp Kyiv (20)
Drupal Paranoia
- 1. Drupal для параноиков: безопасность сайта и системного окружения VPS и выделенных серверов А.Графов < [email_address] >
- 21. Презентация подготовлена в OpenOffice Использована иллюстрация из мультсериала Futurama Вопросы? А.Графов < [email_address] >
Notas del editor
- Некоторые меры защиты, о которых я расскажу в этом докладе могут показаться чрезмерными. Поэтому я перестраховался и назвал тему — «Друпал для параноиков» - то что для нормальных людей примут за сумасшествие, для сисадминов — норма жизни. Но тем не менее, всё о чем будет рассказано испльзовалось в различных коммерческих проектах и вылезло не просто так. Этот доклад — не мастеркласс, поэтому я не дам здесь детальных примеров кода и настроек программ, я только дам обзор возможных опасностей и обзор решений, которые позволят их избежать или уменьшить их последствия. Доклад насыщен информацией, поэтому я не буду углубляться в детали примеров — ссылки на код и программы о которых пойдёт речь — в конце доклада.
- Я буду говорить в расчёте на выделенные сервера и VPS. Часть вещей, особенно касающихся настроек друпала можно использовать и на shared-хостинге, но на shared-хостинге возможности настройки системного окружения сильно ограничены. И по-хорошему защита shared-хостинга — забота админов техподдержки. Мы же рассмотрим те варианты, когда вы хотите сами настроить защиту системы и отвечать за неё. >>>> Итак, каковы возможные проблемы для сайта? Нежелательный контент — то что попадает на сайт легальным путём, через те вебформы, которые сайт предоставляет для постинга. Более серьёзный вариант, когда в результате успешного применения эксплоита, злоумышленник может изменять файлы скриптов. И самый неприятный вариант, когда получена возможность запуска новых процессов или ещё хуже права суперпользователя. Тогда вы можете получить такой своего рода «shared-хостинг», где ресурсы вашей машины, CPU, память, трафик - вы будете использовать совместно с незнакомыми вам людьми, которые смогут использовать их в неизвестных вам целях. А вы даже не будете этого знать.
- Причины можно условно разделить на три группы. Различные атаки сетевых сервисов с целью организовать исполнение своего кода. А может быть заблокировать работу сервиса — так называемые «атаки отказа доступа» - DOS. Задействование уязвимостей, когда уже имеется shell-доступ — может быть легальный, а может быть полученный в результате успешного эксплойта применённого к сетевым сервисам. И самый маловероятный вариант, от которого однако проблематичней всего защититься — получение непосредственного доступа к дискам, когда сервер выключен и права операционной системы на процессы и файлы уже не действуют.
- Большинство методов о которых я расскажу тривиальны и наверняка известны администраторам. Но я надеюсь даже опытным админам временами будет интересно, ведь сколько ни изучай тему, всегда можно пропустить какие-нибудь любопытные мелочи. Итак, о чём пойдёт речь в докладе? Очевидно о том, что надо следить за установленными в системе программами. В первую очередь за скриптами вашего сайта, а также за системными программами, работающими с сетью. К каждой адекватной ОС регулярно выходят апдейты безопасности, за которыми стоит следить и регулярно их устанавливать. Мы поговорим о разграничения прав между пользователями на процессы и ограничения прав на файловой системе — это основные меры защиты системного окружения. А также рассмотрим случай, когда злоумышленники добрались до сервера физически и сняли жёсткий диск с данными. Разграничения прав здесь больше не помогут. Что делать чтобы помешать им завладеть данными? Чтобы на руках у них остался только мусор из байтов, а не данные вашей базы. Нет, не подумайте, я не рекомендую минировать сервер, есть другие методы о которых поговорим в конце.
- Базовые методы защиты — следите за обновлениями модулей друпала, модуль update status в этом вам поможет. Этот модуль обращается к drupal.org и сообщает о вышедших новых версиях модулей. Фильтры исполнения PHP — гибкая вещь, которая очень нравится разработчикам, позволяя сокращать время разработки — вставляем код прямо в текст страниц и блоков, и не нужно писать свой модуль. Но на продуктивных сайтах исполнение PHP обычно не требуются, разве что на очень специфичных ресурсах. Безопаснее — его отключить. Общий принцип — отключайте всё что не требуется, все лишние модули, темы, неиспользуемые роли. Если при повседневной работе с сайтом вам постоянно требуется пользователь #1, то значит что-то при создании сайта было спроектировано неправильно. Создайте роль с необходимыми для администрирования правами, используйте пользователя с этой ролью. Модуль paranoia — следит за всем этим за вас.
- Вообще Друпал без лишних телодвижений работает через защищённый канал. Настройте вебсервер, сгенерируйте ключи — обращайтесь к сайту через HTTPS — друпал будет корректно обрабатывать эти запросы. А вот пример когда нужно только часть сайта, например работу с платежами или админку завернуть на https. В друпале это делается также легко, хотя потребуется немного попрограммировать. [SKIPED — в принципе всё на картинке показано] Задача кстати вполне реальная. Ко мне обращались один раз, чтобы настроить сайт таким образом.
- Рассмотрим как избавляться от нежелательного контента. Очевидно, что большинство спама рассылается автоматически — программами-ботами и чтобы отделить роботов от нормальных людей есть универсальный механизм — капча. Механизм основан на том, что роботы пока умеют не всё, что умеют люди и в частности хуже умеют распознавать образы. С помощью капчи мы можем не допустить роботов-спамеров на сайт. Альтернатива — самообучающиеся фильтры отделяющие спам от не спама. В друпале это одноимённый модуль — Spam. Недостаток таких фильтров — есть вероятность ложного срабатывания. По похожему принципу работают публичные сервисы. Отметить: опыт использования Mollom на drupal.ru — неудачно. Вероятно он ориентируется больше на англоязычный контент. Дрис писал в твиттере об успешном применении Mollom например на сайте памяти Майкла Джексона, который к слову сделан на друпале.
- Кроме технических средств борьбы со спамом не стоит забывать об организационных мерах. Таких как модерация силами посетителей сайта или специально выделенных для этой цели сотрудников. Тут есть два метода, каждый со своими недостатками — первый, это предварительная проверка всех поступающих материалов, перед их публикацией; второй способ — снятие с публикации уже размещённых на сайте материалов, если они нарушают правила сайта. Если для модерации вы привлекаете не сотрудников, а самих посетителей сайта, как собственно происходит на сайтах сообществ, то тут встают вопросы доверия и контроля за действиями модераторов. Но тут тоже есть решения, как снизить последствия от ошибок модераторов. В качестве примера приведу drupal.ru: принцип - контент не удаляется!
- С большой вероятностью в качестве вебсервера у вас установлен Apache или Nginx. Под Апач есть замечательный модуль — mod_security, это по сути такой «файрвол для вебприложений». Модуль проверяет поступающие на сервер запросы и также проверяет ответы сервера. И на основе заданных правил производит фильтрацию тела и заголовков запроса. Проверяются и GET и POST запросы. С помощью этого модуля можно глобально для всех скриптов сервера избавиться от таких уязвимостей как вставки SQL, кросс-скриптинг, вызов команд операционной системы. Модуль может обнаруживать код троянов и аномалии HTTP-запросов. Одной установки модуля недостаточно. Нужно обязательно прочесть документацию и сконфигурировать набор правил, которые могут быть специфичны для ваших задач. На сайте проекта впрочем есть много примеров с правилами и шаблонами правил.
- Наиболее частый вариант работы PHP в Apache — модулем. Недостаток: все процессы работают под одним пользователем и скрипт одного виртхоста может получить доступ к файлам другого виртхоста. Альтернативный способ исполнения PHP — использование FastCGI, его преимущество: можно запускать скрипты разных виртхостов под разными пользователями и таким образом разделить права доступа. Suhosin состоит из двух независимых частей, которые могут использоваться раздельно или совместно. Первая часть – небольшой патч к ядру осуществляющий низкоуровневую защиту структур данных против переполнения буфера и других уязвимостей ядра PHP, впрочем со времени выхода патча часть проблем была исправлена в новых версиях PHP. Вторая часть реализована в виде расширения к PHP, которое фактически осуществляет всю основную защиту и добавляет ряд возможностей по ограничениям в конфигурации PHP. Хотя оригинальный патч Suhosin вышел ещё в 2007 году, но он адаптирован и к последним версиями PHP и идёт в поставке многих дистрибутивов Linux и во FreeBSD.
- По моим наблюдениям чаще крадут пароли на ftp, нежели находят уязвимость в системе. К слову, даже сайт киевского друпалкемпа взломали таким образом — был украден ftp-пароль и изменён файл скрипта, внедрён троян, так что потом ещё сутки в Файрфоксе красовалась надпись «Reported attack site», пока сайт не вытащили из блок-листа. Подробнее о работе с secure-shell можно послушать в моём докладе DrupalDo.
- Гибкая альтернатива классической юниксовой схеме разграничения прав на файлы — access control lists (ACL). Если вы ещё не используете ACL для разграничения прав на файлы — рекомендую это сделать. Я не буду здесь подробно объяснять возможности ACL, разве только в конце доклада возникнут вопросы по этой теме и останется время. Поставьте пакет в своей ОС и прочтите маны по setfacl и getfacl.
- Ещё вариант получения доступа к сайту — зная логин подобрать к нему пароль. Вручную это нелегко, а вот скриптом перебора — очень даже просто, если п/о не предоставляет защиты от таких переборов. Интересно, что в друпале в формах авторизации такой защиты по умолчанию нет. Да, можно организовать это через капчу — об этом поговорим дальше. Можно написать свой код... готовых модулей я не знаю, но это несложно сделать самому через hook_user(). А можно использовать fail2ban...
- Файрвол часто используют не глядя на любых серверах, но по сути он нужен тоже не всегда. Скажем классическая конфигурация сервера для хостинга с установленным вебсером, mysql и ssh для доступа. Mysql сконфигурирован только для прослушивания локального хоста — наружу смотрят только два tcp-порта — вебсервер и ssh доступные отовсюду, что собственно и требуется. Файрволу тут ограничивать нечего, так как все ограничения уже указаны в настройках сетевых служб. И можно его не устанавливать и отключить поддержку сетевой фильтрации в ядре. С другой стороны дополнительный контроль сетевых настроек файрволом позволяет избежать ошибок администрирования — например случайно выставить в сеть сервис, который не должен быть публично доступен, например мемкеш или mysql. Поэтому в общем случае, если не знаете зачем вам не нужен файрвол, лучше его оставить и корректно настроить.
- Та проблема о которой я говорил в начале доклада. И последняя стадия админской паранойи. Страшный сон: когда злоумышленники получают физический доступ к дискам с данными. С помощью шифрования файловой системы мы можем избежать неприятных последствий кражи данных. Это накладная операция, поэтому стоит использовать её только на самых критичных данных. Например вынести какие-нибудь данные пользователей в отдельную БД и хранить эту БД на шифрованном разделе. Есть ещё вариант применения: вы разрабатываете сайт и на серверных ресурсах заказчика. Очень удобно при этом взять администрирование сервера тоже на себя и хранить весь код и базы на шифрованных разделах — на этапе разработки такой перерасход ресурсов не критичен, зато если заказчик вдруг взбрыкнёт и заберёт управление сервером себе — он не получит доступа к данным. Ситуация вовсе не надуманная. В вебстудии с которой я работал, был такой инцидент с одним заказчиком и после него я решил, что конфиги всех новых проектов я буду строить таким образом.
- Важное средство предупреждения проблем — мониторинг системы. Это повышает надёжность системы и таким образом косвенно влияет на безопасность. Есть немало инструментов для мониторинга, я рекомендую вам обратить внимание на Zabbix, он позволяет мониторить ряд параметров и гибко настраивается [см слайд]. Агент zabbix — ставится на машину, параметры которой надо контролировать, под сервер zabbix лучше использовать отдельную машину.
- Это всё, что я хотел сказать. Я понимаю, что мой поверхностный рассказ врядли мог прояснить какие-то моменты по настройке, но может быть он обратил ваше внимание на вещи, которые вы раньше не замечали? Для заинтересовавшихся — подробности по ссылкам. TODO: найти ссылку на статью по ACL.
- Файл с презентацией распространяется под Creative Commons SA последней версии.