Source: Dev.to

Взломы и вирусы в 1С‑Битрикс: как это происходит на самом деле

1С‑Битрикс — не «дырявая CMS» сама по себе. Но это большая система: её дорабатывают, подключают модули, пишут свой код и интегрируют с CRM и платёжными шлюзами. Уязвимости чаще всего появляются именно в этих местах — в кастомной логике и настройках сервера.

Если вы поддерживаете или разрабатываете проекты на Bitrix, рано или поздно сталкиваетесь с последствиями взлома: закладки в шаблонах, скрипты в /upload, «левые» запросы в логах. Ниже — как такие вещи выглядят в коде, где их искать и как закрывать дыры, не ломая рабочий функционал.

В материале — технический разбор без воды:

• какие виды взломов чаще всего встречаются на проектах под 1С‑Битрикс;
• в каких файлах и каталогах искать следы;
• как выглядит типичный вредоносный код;
• почему совет «просто переустановите Bitrix» не решает проблему;
• что на практике означает «нормально вылечить сайт», а не просто удалить пару файлов.

---

Какие взломы Bitrix встречаются чаще всего

1️⃣ Backdoor‑скрипты (самый частый сценарий)

Backdoor — это файл или кусок кода, который даёт атакующему постоянный доступ к серверу.

Часто выглядит максимально примитивно:

';
}

Последствия: обычный пользователь ничего не замечает, а поисковые системы фиксируют редирект или подгружаемый скрипт — в результате сайт вылетает из выдачи или помечается как небезопасный.

---

3️⃣ Вредоносные PHP‑файлы в /upload

В документации 1С‑Битрикс явно сказано: каталог /upload не предназначен для выполнения PHP. На практике же на многих хостингах и VPS выполнение скриптов в этом каталоге по умолчанию не отключено.

Типичный вредоносный файл:

getRequest();

// Только POST и только с валидной сессией Bitrix
if (!$request->isPost() || !check_bitrix_sessid()) {
    die('Access denied');
}

// Если обработчик только для авторизованных — проверяем пользователя
if (!CurrentUser::get()->isAuthorized()) {
    die('Access denied');
}

$data = $request->getPost('data');
if ($data === null || $data === '') {
    die('Invalid input');
}

// Дальше — только проверенные и санитизированные данные
echo htmlspecialchars($data, ENT_QUOTES, 'UTF-8');

---

5️⃣ Старые модули и «заброшенные» интеграции

Классическая картина: модуль или интеграция давно не обновлялись, разработчик недоступен, в коде используются устаревшие вызовы, а входящие данные не фильтруются и не экранируются. В таких случаях уязвимость возникает в кастомном или стороннем коде, а не в ядре Bitrix.

---

Почему «переустановить Bitrix» — плохая практика

Часто советуют: «Переустановите ядро и поднимите сайт из бэкапа». Такой подход не устраняет причину:

• бэкдор и закладки обычно лежат в /upload, /local, кэше — то есть вне ядра;
• уязвимость (например, дыра в кастомном обработчике) никуда не девается;
• пароли, ключи и сессии атакующего не отзываются;
• непонятно, как именно произошёл взлом, поэтому закрыть все входы невозможно.

В итоге сайт нередко взламывают снова — иногда уже на следующий день.

---

Как правильно искать следы взлома

1️⃣ Поиск опасных конструкций в коде

Прогоните поиск по типичным признакам:

# Подозрительный base64 + eval (часто маскировка бэкдора)
grep -R --line-number "eval(base64_decode" /var/www/site

# Прямой вызов выполнения команд
grep -R --line-number -E "shell_exec|passthru|system\s*\(" /var/www/site

Важно: искать нужно и в /upload, и в /local, и в шаблонах.

grep -Rl "eval(" /var/www/site/upload --include="*.php" 2>/dev/null

2️⃣ Поиск недавно изменённых PHP‑файлов в /upload

# Файлы, изменённые за последние 7 дней
find /var/www/site/upload -name "*.php" -mtime -7 -ls

# Вывод с датой изменения (удобно для отчёта)
find /var/www/site/upload -name "*.php" -mtime -30 -exec ls -la {} \;

В каталоге /upload по правилам не должно быть исполняемого PHP — любые .php там уже повод для разбора.

3️⃣ Анализ логов сервера

Без логов сложно понять, откуда пришёл запрос и к какому файлу обращались:

tail -n 500 /var/log/nginx/access.log
tail -n 500 /var/log/nginx/error.log

По логам можно выяснить IP, путь к скрипту, параметры запроса и момент появления подозрительной активности. Без этой информации расследование будет неполным.

---

Итоги

1. Не полагайтесь только на переустановку ядра — исследуйте кастомный код и файловую структуру.
2. Запретите исполнение PHP в /upload на уровне веб‑сервера.
3. Регулярно сканируйте код на eval, base64_decode, shell_exec и аналогичные конструкции.
4. Контролируйте права доступа к файлам и каталогам, особенно к local/php_interface.
5. Внедряйте проверку сессий и прав в любые пользовательские AJAX‑обработчики.

Следуя этим рекомендациям, вы сможете не только очистить уже взломанный сайт, но и построить надёжный процесс профилактики будущих атак.

Тапа: очистка остаётся неполной

Непонятно, все ли точки входа найдены.

Закрытие уязвимостей — обязательный этап

Удалить вредоносный файл — ещё не значит защитить сайт. Нужно закрыть саму возможность выполнения скриптов и ограничить доступ к служебным разделам.

Что обычно делают после очистки

• Ограничивают доступ к /bitrix/admin (по IP, VPN или базовой авторизацией);
• Запрещают выполнение PHP в /upload;
• Проверяют cron и агенты 1С‑Битрикс на подозрительные задачи;
• Обновляют проблемные модули до актуальных версий;
• Перепроверяют все кастомные AJAX‑обработчики и формы.

Примеры конфигураций

Nginx – запрет выполнения PHP в /upload

location ~ ^/upload/.*\.php$ {
    deny all;
}

Apache – тот же запрет через .htaccess (если разрешён AllowOverride)

Файл /upload/.htaccess

    Require all denied

Или в конфигурации виртуального хоста

    php_admin_flag engine off

Почему с Bitrix нужен именно инженерный подход

В проекте на 1С‑Битрикс обычно задействованы:

• ядро,
• десятки модулей,
• свой код в /local,
• интеграции с CRM, платёжными системами, внешними API.

Если действовать «наугад», легко сломать рабочую логику, пропустить второй бэкдор или оставить дыру в кастомном коде. Гарантировать результат можно только тогда, когда понятна архитектура и все точки входа.

Для опытных битрикс‑разработчиков

Если вы уже плотно работаете с 1С‑Битрикс, имеет смысл:

1. Включить и настроить модуль «Безопасность» (если ещё не используется): проверка целостности файлов, отчёт о подозрительных изменениях. Это не заменяет ручной разбор после взлома, но помогает выявлять новые закладки.
2. Смотреть раздел «Безопасность» на dev.1c-bitrix.ru — там описаны рекомендации по проверке входных данных, сессиям, правам доступа.
3. После обновления ядра и модулей заново проверить кастомные обработчики и хуки: иногда обновление меняет контекст (например, глобальные переменные), и старый код может стать уязвимым или сломаться.
4. Ограничить выполнение PHP в upload на уровне веб‑сервера (см. примеры выше) — это обязательная мера для любого продакшена на Bitrix.

Владельцу и разработчику стоит опираться на простые тезисы:

• Вирусы и взломы — следствие уязвимостей (часто в кастомном коде или настройках), а не «проклятия» CMS;
• Автоматические сканеры не находят всё;
• Вылечить сайт — это процесс анализ → очистка → закрытие дыр → мониторинг, а не разовая «чистка»;
• Безопасность — постоянное состояние, а не галочка «один раз почистили».

Полезные материалы по теме

Если хочется углубиться в автоматизацию и практику на Bitrix:

• Backend‑автоматизация без боли: cron, агенты и инженерный подход
• CI/CD для PHP, Bitrix и Laravel: GitHub Actions на практике

Сниппеты по теме

Готовые примеры кода и конфигов из этой статьи, которые можно сразу использовать в проекте:

Итог

Взлом сайта на 1С‑Битрикс — не повод паниковать, но и не та ситуация, где срабатывает совет «быстро переустановите и восстановите из бэкапа». Нормальный выход — анализ логов и кода, понимание причин, удаление закладок и последствий, а также обязательное закрытие уязвимостей. Тогда сайт действительно приходит в порядок, а не доживает до следующей атаки.

Read more on viku‑lov.ru.