Как проверить взломан ли сайт на Друпале и как это исправить

Аватар пользователя ttenz

С каждым владельцем сайта хоть раз происходит очень неприятная вещь: его сайт кто-то взломал. Об этом можно узнать по разным признакам: появились непонятные страницы с кучей рекламы, пришло предупреждение из Гугла, Яндекса о том, что Ваш сайт взломан, сайт еле-еле грузится и так далее, одним словом с сайтом "что-то не так".

Итак, приступим:

1. Устанавливаем модуль  drupalgeddon:

drush dl drupalgeddon

2. Устанавливаем  Site Audit:

drush dl site_audit --dev

3. Устанавливаем  Hacked!:

drush dl hacked --dev; drush en hacked -y

4. Устанавливаем  Security Review:

drush en security_review -y

Можно и сразу всё установить.

drush dl drupalgeddon -y; drush dl site_audit --dev -y; drush dl hacked --dev -y; drush en hacked -y; drush en security_review -y

5. Запускаем drupalgeddon в режиме проверки (аудита) сайта.

Что также запустит всё вышеустановленные модули и создаст файл отчета 'report.html'. Мы его откроем и увидим наши проблемы.
Удаляем все найденные вломанными файлы, ноды, модули.
drush aa --html --bootstrap --detail --skip=insights > ./report.html
Находим все подозрительные файлы и директории и удаляем их. Усиливаем защиту сайта.

6. Запускаем Hacked в Drush.

Просматриваем все измененные проекты/модули:

drush hacked-list-projects --force-rebuild
После этого для каждого измененного проекта/модуля, например changedproject, запускаем:

drush hacked-details changedproject
Также, после этого находим все файлы/директории, которых нет в проекте/модуле:

drush hacked-diff changedproject

7. Drupalgeddon

drush asec

8. Удаляем пользователей

drush user-cancel username
drush ucan username

9. Сбрасываем пароль первого пользователя/администратора

drush uli

10. Изменяем пароли пользователей

drush user-password username --password="NEWPASS"
#или
drush upwd username --password="NEWPASS"

Переходим на сайте по /admin/reports/security-review/, смотрим, что у нас взломали.

11. Находим и удаляем взломанные файлы

find . -size 494c -name "*.php"
# также можно так:
find . -size 494c -name "*.php" | xargs rm

12. Находим файлы с PCT4B инъекцией

grep -Rl PCT4BA6ODSE .
# и
grep -Rl  q6ae4d5 .

13. Определяем местонахождение разных зараженных файлов

grep -Rl SOL_TCP .
grep -Rl SOCK_STREAM .
grep -Rl SOCK_DGRAM .
grep -Rl SOL_UDP .
grep -Rl SO_REUSEADDR .
​grep -Rl SO_RCVTIMEO .
​​grep -Rl SO_SNDTIMEO .

Как только нашли зараженные файлы, ищем лог файлы апачи и блокируем любой IP адрес, который обращался к этим зараженным файлам.

cd /var/log/httpd/
grep -iR 'ИМЯ_ЗАРАЖЕННОГО_ФАЙЛА.php' .

Если Вы найдете какой-нибудь зараженный файл в модуле, то лучше удалить весь модуль и повторно загрузить чистый.

14. Устанавливаем правильные права

cd /DRUPAL_DIR find . -type d -print0 | xargs -0 chmod 755; find . -type f -print0 | xargs -0 chmod 644; chmod 777 sites/default/files; find ./sites/default/files -type d -print0 | xargs -0 chmod 777; find ./sites/default/files -type f -print0 | xargs -0 chmod 666;

Или создаем и запускаем скрипт.

Копируешь код скрипта в файл и называешь его, нарример "fix-permissions.sh" и запускаешь:

sudo bash fix-permissions.sh --drupal_path=your/drupal/path --drupal_user=your_user_name
т.е. с нашими данными, это примерно так:

sudo bash fix-permissions.sh --drupal_path=..../директория_нашего_сайта --drupal_user=www-data

Также можно использовать скрипт для нормальных прав:

Запускаем его так:

/usr/local/bin/fix-permissions.sh --path=/home/USER/public_html --user=USER --group=GROUP

Скрипт для расстановки строгих прав:

Запускаем его так:

/usr/local/bin/fix-permissions-strict.sh --drupal_path=/home/USER/public_html --drupal_user=USER --httpd_group=GROUP

Сейчас ещё модуль для drush появился для правильной расстановки прав для файлов:  File permissions

15. Проверяем лог файлы

grep cwd /var/log/exim/mainlog | grep -v /var/spool | awk -F"cwd=" '{print $2}' | awk '{print $1}' | sort | uniq -c | sort -n

В DirectAdmin:

/var/log/directadmin/error.log
/var/log/directadmin/errortaskq.log
/var/log/directadmin/system.log
/var/log/directadmin/security.log

В Apache:

/var/log/httpd/error_log
/var/log/httpd/access_log
/var/log/httpd/suexec_log
/var/log/httpd/fpexec_log
/var/log/httpd/domains/domain.com.error.log
/var/log/httpd/domains/domain.com.log
/var/log/messages (generic errors)

В Proftpd:

/var/log/proftpd/access.log
/var/log/proftpd/auth.log
/var/log/messages (generic errors)

В PureFTPd:

/var/log/pureftpd.log

В Dovecot и vm-pop3d:

/var/log/maillog
/var/log/messages

В сообщениях:

/var/log/messages

В exim:

/var/log/exim/mainlog
/var/log/exim/paniclog
/var/log/exim/processlog
/var/log/exim/rejectlog
#вместо 'username' впиши имя пользователя системы
/home/username/.php/php-mail.log

В mysqld:

Debian:

/var/log/syslog

В crond:

/var/log/cron

Чтобы удобнее просматривать логи:

less /var/log/filename

Где /var/log/filename это путь к лог файлу, который Вы собираетесь просмотреть. Если лог файл очень большой используйте команду "tail":

tail -n 30 /var/log/filename

Где 30 это число линий от конца файла.

16. Удаляем подозрительные письма в exim

Настройте exim.conf для автоматического удаления подозрительных писем

vi /etc/exim.conf

Устанавливаем следующие значения:

ignore_bounce_errors_after = 0h
timeout_frozen_after = 0h

Удаляем замороженные (заблокированные) письма в exim

exipick -zi | xargs exim -Mrm

Удаляем письма в очереди

exim -bp | awk '{ print $3 }' | xargs exim -Mrm

Удаляем письма старше 1 дня

exiqgrep -z -o 86400 -i | xargs -r exim -Mrm

Устанавливаем ограничение на отправку писем в exim

vi /etc/virtual/limit_USER
#добавляем максимально разрешенное число писем за 1 день... например: 300
------------------------------------------------------------------------------------------------------------
Дополнительно:
Защита от ботов fail2ban+csf сервера nginx c друпалом на борту

Модули и темы:
Ключевые слова:
Тип материала:
Форумы:
5 Спасибо

Комментарии

Аватар пользователя bumble
bumble 4 месяца назад 1

Поместил на главную.
Многим может пригодится.

Спасибо!

Аватар пользователя ttenz
ttenz 4 месяца назад

Благодарю Вас.

0 Спасибо
Аватар пользователя bsyomov
bsyomov 4 месяца назад 1

Много вопросов о смысле разных действий, и применимости их в произвольном случае:
«11. Находим и удаляем взломанные файлы
find . -size 494c -name "*.php"»
И с чего бы взломанные файлы должны бы иметь именно такой размер?

«13. Определяем местонахождение разных зараженных файлов»
И что этими грепами в произвольном случае можно найти? Ответ: вероятнее всего ничего.

«14. Устанавливаем правильные права»
Нет правильных прав. Есть правильные права при определённых настройках окружения.

«15. Проверяем лог файлы»
RHEL|CentOS отнюдь не у всех, соответственно, пути будут отличаться.
А кто ставит DirectAdmin тот сам себе злобный буратино, и вероятность, что сломан не друпал в этом случае, а DA весьма не нулевая. =)
Логи mysql не там где указано лежат уже много лет. Скорее всего, в вашем дистрибутиве они пишутся в syslog,

«16. Удаляем подозрительные письма в exim»
Надо бы объяснить, что это не надо тупо делать. И объяснить, зачем, и в каких случаях понадобится это делать. Также, postfix более распространён чем exim, кстати.

Например timeout_frozen_after=0 не стоит делать. Стоит разбираться в чём дело, если frozen много. Это может быт не спам, а проблемы с вашим почтовиком...

Вообще, лучше по возможности использовать внешние сервисы для работы с почтой - это значительно упрощает обслуживание сервера и снимает массу головной боли лишней.

Аватар пользователя ttenz
ttenz 4 месяца назад

@bsyomov, благодарю Вас за Ваши уточнения. Вы, как всегда, неотразимы.

0 Спасибо
Аватар пользователя fairrandir
fairrandir 4 месяца назад 1

По очистке от зараженных файлов - если весь сайт лежит в гите, то
git checkout -- . #откатить измененные файлы
git clean -f #удалить все untrtacked файлы
могут спасти отца русской демократии. Собственно, ЕМНИП hacked так и работает - тащит с гита код модуля и сравнивает с ним.

З.Ы. Сайты на друпале лично у меня взламывали два раза: один раз drupageddon, второй - через старый джумловский сайт, который работал под тем же юзером.

Аватар пользователя ttenz
ttenz 4 месяца назад

Благодарю Вас, @fairrandir, очень хорошее дополнение.

0 Спасибо
Аватар пользователя K.V.
K.V. 2 месяца назад

удалять install.php или нет - вот в чем вопрос.

0 Спасибо
Аватар пользователя storm
storm 2 месяца назад 1

Спасибо за статью, пойду проверю и свои сайты на взлом

Аватар пользователя Виктор_Дуров
Виктор_Дуров 2 месяца назад

Мне кажется друпал не взломаешь если не знаешь пароль...

0 Спасибо
Аватар пользователя fairrandir
fairrandir 2 месяца назад

Я знаю пароль, я вижу ориентир.
Вам кажется. Перекреститесь.

0 Спасибо