Email
Favorite
Favorited ×
Download
Embed
Private Content
Copy and paste this code into your blog or website Copy Customize Close
We have emailed the verification/download link to "".
Login to your email and click the link to download the file directly.

To request the link at a different email address, update it here. Close
Validation messages. Success message. Fail message.

Check your bulk/spam folders if you can't find our mail.

Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

+ Follow

Drupal Paranoia

by Drupal Camp Kyiv on Aug 28, 2009

2,843 views

More…

Less

8 Embeds 101

http://camp09.drupal.ua	39
http://drupal4u.ru	28
http://my.ukrweb.info	12
http://www.drupal4u.ru	11
http://www.slideshare.net	7
http://itua.name	2
http://drupal4u.dev	1
http://druler.com	1

More...

Statistics

Favorites: 3
Downloads: 35
Comments: 0
Embed Views: 101
Views on SlideShare: 2,742
Total Views: 2,843

Некоторые меры защиты, о которых я расскажу в этом докладе могут показаться чрезмерными. Поэтому я перестраховался и назвал тему — «Друпал для параноиков» - то что для нормальных людей примут за сумасшествие, для сисадминов — норма жизни. Но тем не менее, всё о чем будет рассказано испльзовалось в различных коммерческих проектах и вылезло не просто так. Этот доклад — не мастеркласс, поэтому я не дам здесь детальных примеров кода и настроек программ, я только дам обзор возможных опасностей и обзор решений, которые позволят их избежать или уменьшить их последствия. Доклад насыщен информацией, поэтому я не буду углубляться в детали примеров — ссылки на код и программы о которых пойдёт речь — в конце доклада.
Я буду говорить в расчёте на выделенные сервера и 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 последней версии.

3 Favorites

Viktor Chmel 4 months ago
LibJackass 2 years ago
Slavikkk 2 years ago

Drupal Paranoia — Presentation Transcript

Drupal для параноиков: безопасность сайта и системного окружения VPS и выделенных серверов А.Графов < [email_address] >
Проблемы
- Нежелательный контент (спам, трояны)
- Изменение кода сайта (кража данных пользователей, вставка нежелательного контента — показ скрытой рекламы, перенаправление на другой ресурс)
- Несанкционированное использование ресурсов сервера (рассылка спама и др.)
Причины проблем
- Сеть:
- Локальный доступ:
- Физический доступ к серверу:
Способы защиты
- Контроль работы скриптов
- Защита сетевых сервисов
- Разграничение прав между пользователями на исполняемые процессы
- Разграничение прав на доступ к файловой систему
- Ограничение доступа к сетевым сервисам
- Защита данных хранимых на жёстком диске
Drupal: защита изнутри
- Обновления ядра и модулей
- Фильтр исполнения PHP
- Лишние модули
- Пользователь №1
- Модуль paranoia
Drupal + HTTPS
- Вариант использования:
- Как сделать? Нам поможет:
Фильтруем контент: технические средства
- «Фейсконтроль» сайта — роботам вход воспрещён: captcha
- Самобучающиеся фильтры
- Публичные спамбазы и блоклисты
Фильтруем контент: организационные методы
- Общественная модерация
- Тем эффективнее, чем больше человек задействовано в модерации
Apache mod_security
- mod_security — «файрвол для вебприложений»
Установка PHP
- mod_php в Apache — один пользователь на все процессы
- open_base_dir — можно указывать для каждого виртуального хоста
- FastCGI в Apache и NGINX — можно легко разделить пользователей виртуальных хостов
- Suhosin — патч и модуль расширения к PHP
Средства ОС
- Кража паролей — самый частый способ «взлома»
- FTP на продуктиве лучше отключать (use SFTP)
- Защита от последствий украденного пароля на VPS/сервере:
Средства ОС
- POSIX ACL на файловой системе:
Блокировка перебора паролей
- Можно сделать в друпале через hook_user()
- Fail2ban — защита от перебора паролей и от DOS
Сетевой файрвол
- Ограничения доступа на уровне сетевых протоколов и портов
- Не всем приложениям нужен доступ отовсюду из сети: ограничения по IP
- Всегда ли нужен файрвол?
Последний рубеж
- ФС в файле через loopback-интерфейс
- Или ФС в отдельном разделе
- Включить поддержку криптографии в ядре
- Критичные данные на шифрованном разделе
- Пример для Linux:
Мониторинг работы
- Мониторинг работы основных сервисов локально и перезапуск при необходимости (вебсервер, СУБД, PHP)
- Комплексный мониторинг (Zabbix, ZenOSS)
Ссылки на самое вкусное
- Коды примеров и файлов конфигурации можно скачать:
- Ссылки на п/о:
- Статьи по теме:
Презентация подготовлена в OpenOffice Использована иллюстрация из мультсериала Futurama Вопросы? А.Графов < [email_address] >

Drupal Paranoia

by Drupal Camp Kyiv on Aug 28, 2009

Accessibility

Tags

Upload Details

Usage Rights

8 Embeds 101

Statistics

Drupal Paranoia — Presentation Transcript