Защита CMS WordPress/Bitrix: чек-лист
Если вы отвечаете за корпоративный сайт, то наверняка замечали: одно дело запустить проект, и совсем другое — поддерживать его безопасность хотя бы на минимальном уровне. Особенно когда бюджет не резиновый, а сроки горят.
Хакеры уже не ломятся тупым перебором — они терпеливо выискивают CVE в модулях Bitrix или безобидных на первый взгляд плагинах для WordPress. И если вы до сих пор думаете, что «у нас маленький сайт, никому не нужен», — у меня для вас плохие новости. Боты сканируют всё подряд. Вопрос не в том, попытаются ли взломать, а в том, когда это произойдёт и что к тому моменту будет защищено.
Эта статья — не очередная выжимка из документации. Это рабочий чек-лист, собранный по итогам реальных аудитов, инцидентов и разбора типовых ошибок. Он для тех, кто хочет системно подойти к защите WordPress или Bitrix, не надеясь на авось.
Карта угроз: что реально угрожает вашему сайту в 2026 году
Знаете, что удивляет? Люди до сих пор воспринимают веб-безопасность как набор абстрактных страшилок про «хакеров в капюшонах». Хотя на практике всё гораздо прозаичнее.
Давайте сразу к делу. Основные векторы атак на корпоративные сайты сегодня выглядят так:
SQL-инъекции. Классика, которая никуда не делась. Если в форме поиска или обратной связи дыра, через неё можно утащить всю базу пользователей. Или даже получить доступ к админке. Да, в 2026 году это всё ещё работает.
XSS (межсайтовый скриптинг). Через уязвимости в скриптах злоумышленники внедряют свой код, который выполняется в браузере посетителя. Результат — кража сессий, редирект на фишинг, подделка контента. Причём отражаемый XSS (reflected) чаще всего встречается в поиске, а хранимый (stored) — в комментариях или профилях.
RCE (удалённое выполнение кода). Самый страшный сон администратора. Если атакующий находит способ выполнить свою команду на сервере через уязвимый модуль — всё, сервер под контролем. Например, в 2022 году была критическая CVE в компоненте Bitrix Polls, через которую можно было выполнить произвольный PHP-код. И такие дыры находятся регулярно.
Brute-force. Админки WordPress (/wp-login.php) и Bitrix (/bitrix/admin/) долбят постоянно. Слабые пароли, отсутствие защиты от перебора, стандартный юзер «admin» — это приглашение к взлому.
Точки входа, которые реально используют
Устаревшие плагины и темы. Самое больное место WordPress. Люди ставят плагин, забывают про него, а через полгода выходит CVE, которую уже эксплуатируют в дикой природе. Особенно опасны nulled-темы и пиратские модули — там бэкдор может быть вшит изначально.
Открытые REST API и XML-RPC. В WordPress XML-RPC часто включён по умолчанию и позволяет делать массовые запросы. Через него проводят атаки перебором и даже DDoS. В Bitrix тоже бывают открытые эндпоинты, которые не нужны бизнесу, но забыты разработчиками.
Админ-панели без IP-ограничений. Если вход в админку доступен всему интернету, рано или поздно подберут пароль. Или найдут 0day. Геоблокировка и списки доступа — база, но её игнорируют.
Загрузка файлов без валидации. Формы аватарок, логотипов, документов. Если разрешено заливать PHP-файл, считайте, сервер уже у злоумышленника.
Слабый .htaccess и конфиги сервера. Неправильные права доступа, включённый листинг директорий, открытые phpinfo() — мелочи, но именно по ним начинается разведка.
Что это значит для бизнеса?
Утечка данных клиентов — прямой удар по 152-ФЗ и репутации. Дефейс сайта — потеря доверия и позиций в поиске. RCE и компрометация сервера — возможность использовать ваш ресурс для атак на другие компании. В случае с Bitrix, который часто интегрирован с CRM и учётными системами, последствия могут дойти до остановки бизнес-процессов. Это не просто сайт упал, это продажи встали.
Реальные методы защиты: от теории к практике
Технические меры: без этого никуда
Регулярные обновления. Звучит банально, но 90% взломов происходят из-за устаревшего софта. Обновлять нужно ядро CMS, все плагины, темы. В WordPress желательно включить автоматические обновления для минорных версий. В Bitrix — следить за уведомлениями в панели администратора.
Важный нюанс: перед обновлением всегда делайте бэкап. И проверяйте совместимость на тестовом стенде. По себе знаю — бывает, что свежий патч ломает кастомный функционал.
WAF — веб-апплайер. Это фильтр между сайтом и атакующим. Он анализирует трафик, отсекает SQL-инъекции, XSS, подозрительные запросы. Для WordPress отлично работают облачные WAF (Cloudflare, Sucuri). У Bitrix есть встроенный проактивный фильтр (WAF), который можно и нужно настраивать под свой проект. Плюс rate limiting — ограничение числа запросов с одного IP — помогает от перебора.
Контроль доступа. Запрещаем вход под admin. Используем сложные пароли и двухфакторную аутентификацию (2FA) для всех пользователей админки. В WordPress для этого есть плагины типа Google Authenticator, в Bitrix — встроенная поддержка OTP. Ограничиваем доступ к панели управления по IP (если в компании статические адреса) или через VPN. Разграничиваем права: редактор не должен иметь доступ к установке плагинов, а контент-менеджер — к изменению шаблонов.
Кстати, про уникальных пользователей БД. Никогда не используйте стандартного пользователя базы данных. Создайте отдельного, с минимально необходимыми правами.
Организационные моменты: о чём часто забывают
Аудит прав. Раз в квартал проверяйте, кто из сотрудников имеет доступ к админке и зачем. Уволился человек — сразу блокируем.
Мониторинг логов. В WordPress удобен плагин WP Activity Log — он показывает, кто и что делал в админке. В Bitrix смотрим error.log и логи сервера. Важно замечать подозрительную активность: массовое изменение файлов, необычные запросы, всплески 404 ошибок.
Процессы и процедуры: как не провалить защиту
Регулярное сканирование уязвимостей. Bitrix Scanner ищет типовые дыры в настройках и коде. Для WordPress есть онлайн-сканеры и плагины типа WPScan. Не идеально, но базовые проблемы находит.
Контроль целостности файлов. Если злоумышленник залил шелл, он изменит файлы. Мониторинг изменений (file integrity monitoring) позволит заметить это до того, как начнётся кража данных.
Бэкапы. Оффлайн-копии, хранящиеся отдельно от сервера. В идеале — автоматические, ежедневные, с тестом восстановления. Потому что бэкап, который нельзя развернуть, — это просто мусор.
Best Practices и стандарты: к чему стремиться
OWASP Top 10. Это не просто список, это база. Валидация входных данных, экранирование вывода, защищённые заголовки (CSP, X-Frame-Options), отключение ненужных эндпоинтов (тот же XML-RPC в WordPress, если не используется). HTTPS — обязательно, с современными протоколами.
CIS Benchmarks для WordPress. Там подробно расписано про права на файлы (644 для файлов, 755 для папок), смену префикса таблиц БД, настройки логирования. Рекомендую взять за основу — скучно, но надёжно.
NIST SP 800-53. Если нужна формализация, особенно для госсектора или компаний с жёсткими требованиями к безопасности. Акцент на контроль доступа, аудит, мониторинг.
Bitrix-specific: проактивный WAF по стандарту WAFEC 1.0, изоляция критичных подсистем, ограничение доступа к служебным скриптам. У 1С-Битрикс есть официальная документация по безопасности — там много полезного, хоть и местами маркетинга многовато.
Из практики проектов: недавно на аудите обнаружили, что на Bitrix-портале крупной компании открыт прямой доступ к папке с загруженными документами. Индексация была отключена, но любой знающий URL мог скачать конфиденциальные договоры. Причина — забыли настроить .htaccess. Закрыли за час, но осадочек остался.
Типовые ошибки: на чём прогорают чаще всего
Игнорирование обновлений. Я видел сайты, где ядро WordPress не обновлялось три года. «Работает же — не трогай». Знаете, чем кончается? Рано или поздно прилетает эксплойт под древнюю дыру, и сайт уходит в дамп. С Bitrix та же история — модули, за которые отвечал один разработчик, он уволился, обновления встали.
Открытая админка без защиты. Это как оставить дверь в квартиру открытой, надеясь, что никто не зайдёт. Подберут пароль — 100%. Если не подберут, найдут уязвимость в компоненте авторизации. 2FA и IP-фильтрация — святое.
Слабый WAF или его отсутствие. Многие думают: «У нас хостинг с защитой, всё ок». Хостинговая защита — это базовый уровень, который отсекает только самых тупых ботов. Целенаправленная атака обойдёт его без проблем. Например, есть техники обхода Bitrix WAF через null-байт или специфические кодировки. Нужна тонкая настройка под приложение.
Nulled-плагины и темы. Это просто чума. Ставят «бесплатно» премиум-тему с трещащего по швам сайта, а там бэкдор, который сливает все пароли админов. Потом удивляются, откуда взялись лишние пользователи в админке. Никогда так не делайте. Экономия копеечная, риски колоссальные.
Нет мониторинга. Если вы не знаете, что происходит на сайте, вы не сможете вовремя среагировать. Изменения в файлах, подозрительные запросы, всплески нагрузки — всё это индикаторы компрометации. Когда через неделю после взлома клиент говорит «сайт работал нормально, мы не заметили», это не аргумент. Данные уже утекли.
Чек-лист: что проверить прямо сейчас
Чтобы не быть голословным, вот минимальный набор действий, который стоит выполнить на любом корпоративном сайте на WordPress или Bitrix.
Обновления
Версии CMS, плагинов, тем — последние стабильные.
Включены ли автоматические обновления для ядра (хотя бы для минорных релизов).
Проверен ли список используемых плагинов/модулей, нет ли заброшенных, которые давно не обновлялись разработчиком.
WAF и защита периметра
Включён и настроен ли WAF (облачный или встроенный).
Настроены ли rate limiting и geo-blocking для админки и форм.
Отключён ли XML-RPC в WordPress (если не используется).
Закрыты ли служебные директории от индексации и прямого доступа.
Контроль доступа
Используются ли сложные пароли и 2FA для всех администраторов.
Ограничен ли доступ к /wp-admin или /bitrix/admin по IP (хотя бы для критичных аккаунтов).
Удалены ли лишние учётные записи и изменён ли стандартный префикс БД (в WordPress).
Проведён ли аудит прав пользователей (RBAC/ABAC).
Мониторинг и резервирование
Настроено ли логирование действий в админке.
Проверяется ли целостность файлов (можно через хостинг-панель или плагины).
Делаются ли регулярные бэкапы с хранением вне сервера, проверено ли восстановление.
Сканируется ли сайт на уязвимости хотя бы раз в месяц.
Безопасность кода и конфигурации
Отключён ли вывод ошибок PHP на продакшене.
Настроены ли правильные права на файлы и папки.
Используется ли HTTPS с корректными заголовками (HSTS, CSP).
Проведён ли аудит на предмет SQL-инъекций и XSS в самописных модулях.
Организационные моменты
Назначен ли ответственный за безопасность сайта.
Есть ли инструкция на случай взлома (план реагирования на инциденты).
Проводятся ли регулярные тренинги для контент-менеджеров (чтобы не переходили по фишинговым ссылкам).
Что в итоге
Безопасность корпоративного сайта — это не разовая акция, а постоянный процесс. Нельзя один раз настроить и забыть. Угрозы эволюционируют, появляются новые CVE, меняются бизнес-процессы. Если относиться к защите как к формальности, рано или поздно случится инцидент.
По моему опыту, самые устойчивые компании — те, где безопасность вшита в культуру разработки и эксплуатации. Где разработчик не пишет код с дырами, потому что знает: на code review завернут. Где админ не ставит обновления на прод без проверки, но и не затягивает с ними на полгода. Где руководство понимает, что профилактика дешевле разгребания последствий.
Если чувствуете, что вашей защите не хватает системности, или хотите провести аудит текущего состояния, — приходите, поможем разобрать всё по полочкам.
Нужна помощь?
Оставьте заявку на бесплатную консультацию на сайте:
https://securedefence.ru/
Мы подготовим чек-лист, дорожную карту и коммерческое предложение с учётом специфики вашего проекта и российских требований (152-ФЗ, 187-ФЗ). Для первых пяти заявок в этом месяце — расширенный аудит настроек сервера и CMS в подарок.
FAQ для руководителя: Безопасность сайта на WordPress и Bitrix
1. Я слышал, что WordPress и Bitrix «дырявые». Стоило ли вообще их выбирать для бизнеса, если они так уязвимы?
Честно говоря, сам термин «дырявая CMS» — это скорее маркетинговое клише, чем приговор. WordPress и Bitrix — самые популярные системы в своих нишах. WordPress держит больше 40% мирового рынка, а Bitrix — фактический стандарт для корпоративного сектора в России. И их популярность — это их главная уязвимость, но и главное преимущество.
Поясню аналогией. Что чаще угоняют: Ладу Весту или редкий спорткар? Конечно, массовую модель, потому что на неё есть спрос и запчасти. Хакеры пишут эксплойты под массовые CMS, потому что это дает им доступ к тысячам сайтов. Но для бизнеса это не недостаток платформы, а данность, которая лечится настройкой. У популярности есть и плюс: под эти CMS есть готовые стандарты защиты (CIS Benchmarks, OWASP), встроенные WAF и огромное сообщество, которое быстро закрывает дыры. Вопрос не в выборе CMS, а в том, занимаетесь ли вы её гигиеной.
2. Как мне, как руководителю, оценить риск? Что реально грозит компании, кроме того, что «сайт упадет»?
Давайте без эвфемизмов. «Падение сайта» — это лишь верхушка айсберга. Если злоумышленник получает контроль над корпоративным сайтом (особенно над Bitrix, который часто связан с CRM), последствия выстраиваются в цепочку:
Прямые финансовые потери. Это не только затраты на восстановление. Это остановка онлайн-продаж, кража платежных данных клиентов (если вы принимаете оплату на сайте) и последующие штрафы по 152-ФЗ за утечку персональных данных. Штрафы сейчас растут, и для юрлиц суммы становятся чувствительными.
Репутационный удар. Если сайт дефейсят (меняют главную страницу) или начинают рассылать спам с вашего сервера, клиенты теряют доверие. Восстановить репутацию сложнее и дороже, чем починить код.
Компрометация партнеров и внутренней инфраструктуры. Bitrix часто хранит переписку, договоры, контакты контрагентов. Получив к нему доступ, хакер может инициировать фальшивые счета на оплату от вашего имени (социальная инженерия на основе реальных данных). В моей практике был случай, когда через уязвимость в Bitrix вышли во внутреннюю сеть компании и парализовали работу производства на неделю. Риск — это не просто «сайт не работает», это остановка бизнес-процессов.
3. Наши разработчики говорят, что «всё обновляют» и «всё настроено». Как мне это проверить быстро, без погружения в код?
Самый надежный способ — инициировать внешний аудит безопасности (пентест) или хотя бы сканирование уязвимостей. Но если хотите поверхностную проверку прямо сейчас, задайте разработчикам или подрядчику три конкретных вопроса:
«Где у нас включена двухфакторная аутентификация (2FA) для входа в админку и почему она до сих пор не включена, если её нет?». Если её нет — это красный флаг.
«Покажите лог последних обновлений CMS и плагинов за полгода». Если там сплошные «пропущено» или даты годичной давности, защита спит.
«Кто имеет права администратора в системе и когда в последний раз проводилась ревизия этих прав?». Обычно выясняется, что пять бывших сотрудников до сих пор имеют ключи от главного входа.
Если на эти вопросы отвечают расплывчато — это повод заказать профессиональный аудит.
4. Сколько это стоит и не проще ли купить «защиту от хостинг-провайдера»?
Стоимость защиты всегда должна сравниваться со стоимостью потенциального ущерба. Простая математика: час простоя интернет-магазина в Черную пятницу может перекрыть годовой бюджет на безопасность.
Что касается защиты от хостинг-провайдера — это базовая гигиена. Это как мыть руки перед едой: необходимо, но не гарантирует защиту от всех инфекций. Хостинговая защита (обычно это «общий» WAF) настроена на массового бота, который долбит типовые дыры. Она спасает от 80% мусорных атак. Но оставшиеся 20% — это целевые атаки на ваш конкретный бизнес, которые используют специфику ваших плагинов или кастомного кода. Такую атаку обойдет только тонкая настройка WAF под ваше приложение и регулярный мониторинг.
По ценам: можно уложиться в бюджет, сопоставимый с зарплатой мидл-разработчика за пару недель работы, если делать системно. Это дешевле, чем один серьезный инцидент.
5. Что делать, если нас уже взломали? С чего начинать спасение бизнеса?
Главное правило: не паниковать и не дергать всё подряд, пытаясь «починить» самому, иначе уничтожите улики.
Первое. Отключаем сайт от сети или ставим заглушку («ведутся технические работы»), чтобы остановить распространение заразы и утечку данных.
Второе. Сохраняем логи и дисковый образ сервера (если есть возможность). Это нужно для расследования: как зашли, что украли, какие бэкдоры оставили.
Третье. Ищем точку входа. Это самый сложный этап. Если просто переустановить CMS, а дыра осталась в коде, через день взломают снова. Нужен forensic-анализ.
Четвертое. Восстанавливаемся с чистого бэкапа, который гарантированно сделан ДО взлома. Поэтому так важны офлайн-бэкапы.
Пятое. Уведомляем клиентов и регуляторов (Роскомнадзор), если произошла утечка ПДн. Закон обязывает, молчание грозит еще большими штрафами.
И только потом, когда пожар потушен, начинаем работу над ошибками и меняем процессы, чтобы это не повторилось.
6. Какой KPI поставить перед IT-отделом по безопасности сайта, чтобы он был понятен и мне, и им?
KPI должны быть измеримыми. Забудьте про абстрактное «обеспечить надежную защиту».
Время реагирования на критические уязвимости (SLA). Например: «Установка патча для критической CVE (с оценкой 9+ по CVSS) не позднее 24 часов с момента выхода обновления».
Процент успешных попыток проникновения на внешних пентестах. Проводите тестирование раз в полгода и ставьте цель: «0 критических и высокорисковых уязвимостей по итогам внешнего аудита».
Полнота резервного копирования. «Регулярное тестирование восстановления из бэкапа раз в месяц. Время полного восстановления сайта из резервной копии — не более 4 часов».
Это переведет безопасность из сферы чувств в сферу цифр.
7. Почему вы советуете обращаться к вам, если у нас и так есть штатный программист?
Штатный программист — это творец, он пишет код и создает функционал. Безопасность — это функция разрушения, поиска ошибок. Это парадигмально разные типы мышления. Программист часто смотрит на код как на то, что должно работать, а безопасник — как на то, что можно сломать.
Хороший специалист по безопасности (или отдел) смотрит на систему шире: не только на код, но и на конфигурацию сервера, сетевые взаимодействия, человеческий фактор. К тому же, мы видим сотни проектов и знаем, как ломают другие. У штатного сотрудника просто нет такого объема «боевого» опыта. Мы не заменяем разработчика, мы даем ему инструменты и знания, чтобы он писал более защищенный код, и проверяем, что в итоге получилось.
══════
Оставьте заявку на бесплатную консультацию: [Перейти на сайт]