Первое, что нужно сделать после запуска сайта на Drupal, — обновить ядро и все модули до последних версий с исправлениями безопасности, оставить административные права только тем, кому они действительно нужны, закрыть файл settings.php от записи и настроить trusted_host_patterns. Эти четыре шага закрывают большую часть типовых сценариев взлома ещё до установки каких-либо дополнительных модулей.
Drupal считается одной из самых защищённых CMS: у проекта есть собственная команда безопасности, которая публикует бюллетени об уязвимостях в ядре и модулях. Но именно публичность этих бюллетеней делает устаревшие сайты лёгкой целью. После выхода исправления злоумышленники быстро автоматизируют атаку, и сайты, которые не обновились в первые дни, массово взламываются ботами. Так было с известными уязвимостями Drupalgeddon в 2014 и 2018 годах.
Базовая защита не требует программирования. Большинство настроек делается в административном интерфейсе, а часть — одной правкой конфигурационного файла или прав доступа на хостинге. Ниже — порядок действий, который мы в Pear Advert применяем на каждом новом проекте.
1. Обновления ядра и модулей
Включите модуль Update Status (в ядре он называется Update Manager / Update Status — зависит от версии). Он раз в сутки проверяет наличие новых версий и показывает отчёт в разделе Отчёты → Доступные обновления (/admin/reports/updates). В его настройках укажите e-mail и выберите уведомления только о выпусках безопасности, чтобы важные письма не терялись среди обычных.
Подпишитесь на бюллетени команды безопасности на . Плановые выпуски безопасности ядра обычно выходят по средам, а о критичных проблемах команда может заранее предупреждать отдельным объявлением. Важно следить и за поддерживаемостью версии: Drupal 7 перестал получать официальные исправления в январе 2025 года, поэтому сайт на «семёрке» в 2026 году нужно переносить на актуальную ветку (Drupal 10 или 11), а не просто «латать».
Если сайт собран через Composer, обновления ставьте командой composer update drupal/core-recommended --with-all-dependencies и затем drush updatedb, предварительно сделав резервную копию. Обновлять сначала на тестовой копии, потом на рабочем сайте — нормальная практика даже для небольших проектов.
2. Роли и права пользователей
Система ролей — главный инструмент защиты в Drupal. Права настраиваются на странице /admin/people/permissions, роли — в /admin/people/roles. Основное правило: каждому сотруднику — минимально необходимый набор прав. Контент-менеджеру не нужны права на модули, темы и пользователей.
Особенно внимательно проверьте следующие права — их сам Drupal помечает как опасные («Warning: Give to trusted roles only»):
- Administer site configuration, Administer modules, Administer permissions, Administer users — фактически дают полный контроль над сайтом;
- использование текстового формата Full HTML — позволяет вставлять произвольный HTML и JavaScript, что открывает путь к XSS-атакам;
- Bypass content access control — даёт доступ ко всем материалам в обход ограничений.
Учётную запись с ID 1 (первый созданный пользователь) не используйте для ежедневной работы: у неё все права независимо от ролей. Дайте ей сложный уникальный логин и пароль и заходите под ней только для обслуживания. Для анонимных посетителей оставьте минимум — обычно это просмотр опубликованного контента.
3. Регистрация, пароли и двухфакторная аутентификация
В разделе /admin/config/people/accounts решите, кто может регистрироваться. Если открытая регистрация сайту не нужна, выберите вариант «Только администраторы». Если нужна — включите подтверждение по e-mail и, по возможности, одобрение администратором.
Ядро Drupal ограничивает число неудачных попыток входа (механизм flood control): после серии ошибок вход для IP-адреса или аккаунта временно блокируется. Для усиления используйте модули из официального каталога:
- Two-factor Authentication (TFA) — второй фактор входа через приложение-аутентификатор (одноразовые коды TOTP);
- Password Policy — требования к длине и сложности пароля, срок его действия;
- Automated Logout — автоматический выход после периода бездействия;
- Username Enumeration Prevention — затрудняет подбор существующих логинов.
Двухфакторную аутентификацию стоит сделать обязательной хотя бы для ролей с административными правами.
4. Файл settings.php и права на файлы
В sites/default/settings.php хранятся пароль к базе данных и ключевые параметры. После установки Drupal сам предупреждает в отчёте о состоянии (/admin/reports/status), если файл и каталог доступны на запись. Права нужно выставить так: settings.php — 444 (или 440), каталог sites/default — 555.
Что проверить внутри файла:
$settings['trusted_host_patterns']— перечень доменов, на которых должен открываться сайт. Без него возможна атака через подмену заголовка Host, и отчёт о состоянии покажет ошибку;$settings['hash_salt']— длинная случайная строка, уникальная для сайта. Лучше хранить её вне корня сайта и подключать из файла;$settings['file_private_path']— путь к приватным файлам за пределами веб-корня, если на сайте есть документы, недоступные посетителям.
Официальное руководство формулирует главный принцип: веб-сервер не должен иметь права изменять файлы, которые он исполняет. Писать он может только в каталог загружаемых файлов (sites/default/files), и PHP-скрипты оттуда исполняться не должны — Drupal для этого создаёт там свой .htaccess, его нельзя удалять.
5. Модули безопасности
Дополнительные модули стоит ставить осознанно: каждый новый модуль — это тоже код, который нужно обновлять. Минимальный набор, который мы рекомендуем:
| Модуль | Зачем нужен |
|---|---|
| Security Kit (seckit) | Заголовки безопасности: Content-Security-Policy, X-Frame-Options, HSTS, защита от clickjacking и CSRF |
| Two-factor Authentication (TFA) | Второй фактор при входе |
| Password Policy | Правила сложности паролей |
| Honeypot | Защита форм от спам-ботов без капчи |
| CAPTCHA / reCAPTCHA | Капча на формах входа, регистрации, обратной связи |
| Backup and Migrate | Резервные копии базы и файлов из админки |
Перед установкой проверьте на странице модуля в каталоге drupal.org, что он поддерживает вашу версию ядра и покрыт политикой безопасности (на странице есть соответствующая пометка). Модули без этой пометки и давно не обновлявшиеся лучше не использовать. Неиспользуемые модули не просто отключайте, а удаляйте из файловой системы.
6. Вывод ошибок, журнал и мониторинг
На рабочем сайте посетители не должны видеть технические сообщения об ошибках: в них бывают пути к файлам и фрагменты запросов. В разделе Конфигурация → Разработка → Журналирование и ошибки (/admin/config/development/logging) выберите вариант «Нет» для отображения ошибок.
Журнал событий (модуль Database Logging, раздел /admin/reports/dblog) показывает неудачные входы, ошибки «страница не найдена» и «доступ запрещён». Если вы видите сотни попыток входа или обращений к несуществующим адресам вроде /wp-login.php — значит, сайт сканируют, и стоит включить защиту на уровне хостинга или веб-сервера. На нагруженных сайтах вместо Database Logging лучше использовать модуль Syslog, чтобы журнал не раздувал базу данных.
Раз в неделю заглядывайте в отчёт о состоянии /admin/reports/status: Drupal сам подсвечивает проблемы конфигурации, включая отсутствующие обновления безопасности.
7. Резервные копии
Резервная копия — последняя линия защиты. Для Drupal нужно сохранять три вещи: базу данных, каталог загруженных файлов (sites/default/files и приватные файлы) и код сайта вместе с composer.json, composer.lock и экспортированной конфигурацией. Копии должны храниться вне сервера сайта, а восстановление из них стоит хотя бы раз проверить на практике. База данных — ежедневно, файлы — по мере изменения, перед каждым обновлением — внеочередная копия.
8. HTTPS и заголовки безопасности
Сайт должен работать только по HTTPS с автоматическим перенаправлением с HTTP. Административная часть без шифрования — прямой риск перехвата пароля в публичной сети. После перехода на HTTPS включите заголовок Strict-Transport-Security (через Security Kit или настройки веб-сервера), а также X-Frame-Options и X-Content-Type-Options. Content-Security-Policy настраивайте аккуратно: строгая политика может сломать счётчики, виджеты и формы.
Типичные ошибки
- Работа под учётной записью ID 1 каждый день и передача её пароля подрядчикам.
- Формат Full HTML доступен всем авторизованным пользователям.
- Обновления откладываются «до редизайна», а сайт годами живёт на неподдерживаемой версии.
- Модули отключены, но их файлы остаются на сервере.
- Файл
settings.phpдоступен на запись,trusted_host_patternsне задан. - Резервные копии хранятся на том же сервере, что и сайт.
- На рабочем сайте включён вывод ошибок и оставлены модули разработки (Devel, Views UI на продакшене без необходимости).
Чек-лист первичной защиты
- Обновить ядро и все модули до актуальных версий.
- Включить Update Status и уведомления о выпусках безопасности на e-mail.
- Убедиться, что используется поддерживаемая ветка Drupal (10 или 11).
- Перестать работать под пользователем ID 1, задать ему уникальный логин и сложный пароль.
- Пересмотреть роли и права, убрать «опасные» права у нетехнических ролей.
- Ограничить Full HTML доверенными ролями.
- Закрыть или ограничить регистрацию новых пользователей.
- Включить двухфакторную аутентификацию для администраторов (TFA).
- Выставить права 444 на
settings.phpи 555 наsites/default. - Задать
trusted_host_patternsи уникальныйhash_salt. - Отключить вывод ошибок посетителям.
- Установить Security Kit и защиту форм (Honeypot или CAPTCHA).
- Удалить неиспользуемые модули и темы.
- Настроить ежедневные резервные копии вне сервера и проверить восстановление.
- Перевести сайт полностью на HTTPS и включить HSTS.
Частые вопросы
Нужен ли отдельный модуль-«антивирус» для Drupal?
Универсального модуля, который «защищает всё», нет. Основную защиту дают своевременные обновления, правильные права и конфигурация. Проверку файлов на вредоносный код лучше выполнять средствами хостинга или сервера, а в Drupal — отслеживать отчёт о состоянии и журнал событий.
Как часто обновлять Drupal?
Обновления безопасности — в течение суток-двух после выхода бюллетеня, особенно если уровень угрозы помечен как высокий или критический. Обычные функциональные обновления можно ставить раз в месяц после проверки на тестовой копии.
Можно ли оставить сайт на Drupal 7?
Официальная поддержка Drupal 7 закончилась в январе 2025 года, исправления от команды безопасности больше не выходят. Существуют платные программы расширенной поддержки от сторонних компаний, но в долгосрочной перспективе правильное решение — миграция на актуальную версию.
Помогает ли смена адреса входа /user/login?
Это снижает количество автоматических попыток, но не заменяет сложные пароли, двухфакторную аутентификацию и ограничение попыток входа. Рассматривайте смену адреса как дополнительную меру, а не основную.
Если не хочется разбираться в правах, модулях и конфигурации самостоятельно, мы проведём аудит безопасности сайта на Drupal, обновим ядро и модули, настроим роли, резервное копирование и защиту форм, а по итогам передадим понятный отчёт.
Читайте также
- Признаки вируса на сайте и как его вылечить: пошаговая инструкция
- Топ-10 вирусов на сайтах: как распознать и удалить
Pear Advert · поддержка и защита сайтов
Защитим ваш сайт на Drupal
Проверим версию ядра и модулей, права пользователей и settings.php, настроим двухфакторный вход, резервные копии и защиту форм.
- Аудит безопасности и отчёт с приоритетами
- Обновления, бэкапы и мониторинг доступности
- Очистка от вирусов и восстановление после взлома
Ответим в течение рабочего дня
