Сегодня я хочу поделиться нашим опытом в проведении аудита безопасности Drupal сайтов. В большей части это текст доклада нашего сотрудника Дмитрия Кочетова на DrupalCamp Krasnodar 2016. В основном, к нам обращаются за аудитом безопасности по 3-м причинам:
- На сайте были обнаружены вирусы (браузер показал уведомление, хостер сообщил о проблеме, пришло уведомление из панели вебмастера).
- Смена разработчиков (странная причина, но, видимо, так делают исходя из своего опыта).
- Сайт долго не обновлялся.
В процессе аудита мы готовим отчет о найденных уязвимостях сайта.
Прорабатывая эту услугу, мы постарались учесть специфику Drupal: анализ содержимого базы данных, структуры файлов и настроек Drupal сайта и т. п.
Порядок проведения аудита безопасности
Аудит безопасности Drupal сайта состоит из нескольких этапов:
- Изоляция Drupal сайта;
- Поиск вредоносного кода в файлах Drupal-сайта;
- Поиск изменений в ядре и модулях Drupal;
- Поиск лишних файлов в папках ядра и модулей Drupal;
- Поиск программного кода, требующего проверки на безопасность;
- Поиск кода PHP и JS в базе данных;
- Поиск нехарактерных для Drupal сайта запросов;
- Проверка Drupal сайта модулем security_review;
- Проверка на уязвимость Drupalgeddon;
- Проверка настроек веб-сервера.
Рассмотрим подробнее каждый из этих этапов.
1. Изоляция Drupal-сайта
Этот этап необходим для предотвращения изменений в файлах сайта во время проведения аудита. Если этого не сделать, после проведения аудита вирус может поразить ещё больше файлов, что приведёт к необходимости проведения ещё одного аудита. Изоляцию мы обычно делаем либо в контейнере docker, либо на виртуальном сервере, закрытом от внешних обращений к сайту.
2. Поиск вредоносного кода в файлах Drupal-сайта
Для поиска вирусов мы используем 2 программных продукта:
- AI-Bolit, сканер вирусов и вредоносных скриптов на хостинге;
- Linux Malware Detect (LMD), сканер для Linux, предназначенный для поиска веб-шеллов, спам-ботов, троянов и т.д.
На мой взгляд, AI-Bolit лучше справляется с поиском вредоносного кода, написанного на PHP и Perl.
3. Поиск изменений в ядре и модулях Drupal
Устанавливаем модуль hacked + diff вручную или через drush и запускаем отчет. Модуль hacked не проверяет папку sites/all/libraries, поэтому эту папку необходимо проверить вручную. Сделать это можно, например, так:
- скачиваем проверяемую библиотеку;
- выполняем команду diff:
diff path_to_site/sites_default/libraries/name_library/ path_to_download_library/
- анализируем изменения.
4. Поиск новых файлов в папках ядра и модулей Drupal
На этом этапе мы осуществляем поиск файлов, которых не должно быть в оригинальных версиях ядра и модулей с drupal.org. Для проверки используется скрипт на bash. Если нет изменений или есть только разница в файлах, скрипт выдаёт OK (исключение – файлы темы). Для работы скрипта необходимо три аргумента:
- путь к папке с модулями;
- путь к корню сайта;
- путь к папке темы.
Запускаем скрипт в папке путь_к_сайту/tmp/hacked_cache. Там должны быть файлы архивов модулей после запуска отчета модуля hacked.
После выполнения скрипта проверяем файл otchet.log и смотрим каждый найденный файл с помощью vi или less.
Исходный код скрипта в репозитории на github: https://github.com/initlabopen/drupal-security-audit
5. Поиск программного кода, требующего проверки на безопасность
Этот этап необходим ввиду того, что отчет модуля hacked не показывает корректно изменения, внесённые в кастомные и dev модули. Соответственно, мы составляем их список.
6. Поиск кода PHP и JS в базе данных
В рамках этого этапа мы ищем все вставки кода в базу данных. Для этого делаем дамп базы данных:
mysqldump -uuser -ppassword db > db.sql
После чего подготавливаем несколько отчетов:
cat db.sql | grep '<?php[^<]*>' > otchet_php.log cat db.sql | grep '<script[^<]*>' > otchet_script.log cat db.sql | grep '<object[^<]*>' > otchet_object.log cat db.sql | grep '<iframe[^<]*>' > otchet_iframe.log cat db.sql | grep '<embed[^<]*>' > otchet_embed.log
Анализировать каждый из отчетов можно любым редактором, мы используем для этой задачи vi, так как поиск в нём работает быстрее. В каждом отчёте делаем поиск по ключевому слову из вышеприведенных команд, то есть в файле otchet_embed.log ищем по слову “embed” и смотрим, что находится рядом с этим ключевым словом. Например, это может быть вставка объекта между тегами.
7. Поиск нехарактерных для Drupal сайта запросов
На этом этапе мы анализируем логи веб-сервера на наличие нехарактерных для Drupal сайта запрос. Для анализа логов веб-сервера переходим в директорию с логами, выполняем следующие команды, получаем результат, проводим анализ. Выборка запросов к PHP файлам:
cat log_access.log | awk ' { if($9==200) print $7 } ' | grep \.php | grep -v "index\.php" > php.log
Проверяем, какие php-файлы успешно выполнялись, сверяем их со списком файлов, найденных антивирусом в п. 1, открываем каждый файл и анализируем его содержимое. Выборка запросов к CGI:
cat log_access.log | awk ' { print $7 } ' | grep "\.cgi" > cgi.log
Выборка POST-запросов:
cat log_access.log | grep POST | awk ' { print $6 $7 } ' | sort | uniq -c | sort -rn > post.log
- смотрим количество запросов и их составляющие. Здесь проверяются успешные POST-запросы к сайту. Запрос может происходить к php-файлам. Эти файлы надо сравнить с найденными антивирусом в п.1, открывать каждый из них и анализировать его содержимое.
8. Проверка Drupal сайта модулем security_review
На этом этапе мы анализируем и код с помощью модуля security_review и устраняем недочёты согласно рекомендациям. Устанавливаем модуль security_review вручную или через drush, запускаем, изучаем его отчет, устраняем недочёты пункт за пунктом.
9. Проверка на уязвимость Drupalgeddon
Если сайт давно не обновлялся, следует проверить его наличие уязвимости Drupalgeddon. На тему Drupalgeddon есть много информации. Мы выполняем следующую последовательность действий.
- Проверка модулем https://www.drupal.org/project/drupalgeddon
- поиск файлов командой:
find ./ -type f -name "*.php" -exec grep -l '$form1=@$_COOKIE' {} \; >> report.log - поиск по базе данных запросами:
SELECT * FROM menu_router WHERE access_arguments LIKE '%form1(@$_COOKIE%'; SELECT * FROM role WHERE name='megauser'; SELECT * FROM users WHERE name='drupadev'; SELECT * FROM users WHERE name='drupaldev'; SELECT * FROM users WHERE name='drupdev';
10. Проверка настроек веб-сервера
На этом этапе мы проверяем настройки веб-сервера, на котором был запущен сайт. На drupal.org вы найдёте много материалов, посвящённых безопасности Drupal: https://www.drupal.org/security/secure-configuration.
Мы проверяем следующие настройки:
- Владелец файлов сайта и права доступа к файлам сайта. Рекомендации вы найдёте здесь: https://www.drupal.org/node/244924
- Возможность выполнения php файлов из папки /sites/default/files . Рекомендации – здесь: https://www.drupal.org/node/615888
Это последний этап, аудит безопасности считаем завершенным и готовим отчет. Надеюсь этот материал будет полезен. Если у вас есть замечания или предложения по проведению аудита безопасности – буду рад обсудить их в комментариях или в соц. сетях.