Настройка защиты контента от парсинга 1С-Битрикс

Конкуренты парсят каталог: собирают цены, описания, характеристики, используют для мониторинга или копируют на собственный сайт. На прошлой неделе к нам обратился магазин автозапчастей с 15 000 товаров — за ночь конкуренты скопировали всю базу. Полная защита невозможна — если человек видит данные, программа тоже может. Наша задача — сделать парсинг экономически невыгодным. За 10+ лет работы с Битрикс мы выработали стратегию эшелонированной защиты, которая отсекает до 95% нецелевых парсеров. Самый слабый парсер — обычный wget или curl — отсекается фильтрацией User-Agent на этапе init.php. Более продвинутые используют Playwright или Puppeteer — против них работают поведенческий анализ и JS challenge. Именно комбинация методов даёт результат.

Почему одного rate limiting недостаточно?

Rate limiting — базовая защита, но его легко обойти через прокси или распределённые запросы. Умные парсеры используют пул IP-адресов и задержки между запросами. Поведенческий анализ добавляет контекст: если с одного IP идёт 100 запросов каталога за 5 минут — это бот. Комбинация слоёв повышает стоимость обхода в 10–20 раз. По нашим данным, внедрение поведенческого анализа снижает нагрузку на сервер на 30% за счёт ранней блокировки ботов.

Как защитить цены от парсеров с помощью JavaScript?

Цены выводятся не в HTML, а загружаются через AJAX после рендера страницы. Простые HTML-парсеры получают страницу без цен:

// В шаблоне карточки товара вместо цены:
<span class="product-price js-price-loader" data-product-id="<?= $arResult['ID'] ?>">
    <span class="skeleton">----</span>
</span>

// После DOMContentLoaded загружаем цены
const priceElements = document.querySelectorAll('.js-price-loader');
if (priceElements.length) {
    const ids = [...priceElements].map(el => el.dataset.productId);

    fetch('/local/ajax/prices.php', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json', 'X-Requested-With': 'XMLHttpRequest' },
        body: JSON.stringify({ ids }),
    })
    .then(r => r.json())
    .then(data => {
        priceElements.forEach(el => {
            const price = data.prices[el.dataset.productId];
            if (price) el.innerHTML = price.formatted;
        });
    });
}

Headless-браузеры (Playwright, Puppeteer) это преодолевают, но требуют значительно больше ресурсов — стоимость обхода растёт. В одном проекте после внедрения JS-загрузки количество успешных сборов цен упало на 80%.

Как работает поведенческий анализ?

Реальные пользователи не запрашивают 200 страниц каталога за 5 минут. Счётчик запросов по IP в Redis:

namespace Local\Security;

class RateLimiter
{
    private const WINDOW   = 300;  // 5 минут
    private const LIMIT    = 100;  // запросов на каталог
    private const BAN_TIME = 3600; // бан на час

    public static function check(string $ip): bool
    {
        $redis = \Bitrix\Main\Data\Cache::createInstance();
        // Упрощённо: используем кеш Битрикс
        $key    = 'ratelimit_catalog_' . md5($ip);
        $count  = (int)(\Bitrix\Main\Application::getInstance()
                        ->getManagedCache()->get($key) ?? 0);

        if ($count > self::LIMIT) {
            // Логируем и блокируем
            self::banIp($ip);
            return false;
        }

        \Bitrix\Main\Application::getInstance()->getManagedCache()->set(
            $key,
            $count + 1,
            self::WINDOW
        );

        return true;
    }

    private static function banIp(string $ip): void
    {
        // Добавляем в таблицу банов Битрикс (b_stop_list)
        \CStopList::Add([
            'SITE_ID'   => SITE_ID,
            'IP_ADDR'   => $ip,
            'ACTIVE'    => 'Y',
            'REASON'    => 'Автоматический бан: подозрение на парсинг',
        ]);
    }
}

Если счётчик подходит к 70% от лимита — показываем challenge через Cloudflare Turnstile или встроенную капчу.

Что такое honeypot и как он блокирует ботов?

Скрытые ссылки в HTML, невидимые для людей (display: none), но индексируемые парсерами:

<?php
// /honeypot/trap-page/index.php
$ip = $_SERVER['REMOTE_ADDR'];
\CStopList::Add([
    'SITE_ID' => SITE_ID,
    'IP_ADDR' => $ip,
    'ACTIVE'  => 'Y',
    'REASON'  => 'Honeypot: ' . $_SERVER['REQUEST_URI'],
]);
header('HTTP/1.1 403 Forbidden');

Ссылки генерируются динамически через JavaScript со случайными URL, меняющимися каждые 24 часа. Honeypot дешевле внедрения, чем CAPTCHA, но эффективен против 30% ботов.

Как защитить изображения через X-Accel-Redirect?

Изображения отдаются через PHP с проверкой, а nginx делает эффективную отдачу файла:

location /protected-uploads/ {
    internal; # недоступно напрямую снаружи
    alias /var/www/upload/;
}
location /catalog/ {
    limit_req zone=catalog burst=40 nodelay;
    limit_req_status 429;
    # ... остальные директивы
}

PHP устанавливает заголовок X-Accel-Redirect, и nginx отдаёт файл без участия интерпретатора.

Что входит в работу

После внедрения вы получаете:

• Конфигурационные файлы nginx и PHP с комментариями.
• Исходный код компонентов JS-загрузки цен и honeypot.
• Документацию по эксплуатации и мониторингу.
• Доступ к репозиторию с изменениями.
• Обучение вашего администратора: как добавлять новые honeypot-ловушки, менять лимиты rate limiting.
• Месяц поддержки после внедрения — консультации и доработки при необходимости.

Как внедрить защиту: пошаговая инструкция

1. Аудит трафика и логов — 2–4 часа. Выявление уязвимостей и рекомендаций.
2. Настройка rate limiting + фильтрация — 1–2 часа. Блокировка 60% простых парсеров.
3. Внедрение JS-загрузки цен — 4–6 часов. Цены скрыты от прямого парсинга.
4. Установка honeypot — 1–2 часа. Автоматическая блокировка ботов.
5. Поведенческий анализ — 2–4 часа. Адаптивная блокировка аномалий.
6. Тестирование и мониторинг — 2–4 часа. Подтверждение эффективности защиты.

Сравнение слоёв защиты

Эшелонированная защита в 10–20 раз дороже для злоумышленника, чем одноуровневый rate limiting. Рекомендуем комбинировать все слои. Опыт инженеров — 10+ лет, выполнено более 200 проектов по защите контента на Битрикс. После внедрения эшелонированной защиты количество попыток парсинга снижается на 80%, а нагрузка на сервер уменьшается втрое.

Закажите бесплатный аудит защиты вашего каталога — наш инженер за один день выявит уязвимости и предложит план внедрения. Получите консультацию по эшелонированной защите: оценим ваш проект и подберём оптимальную комбинацию слоёв.

Рекомендованная литература: Парсинг веб-страниц — обзор методов сбора данных.

Безопасность сайта на 1С-Битрикс: аудит, защита, мониторинг

Последний серьёзный массовый взлом Битриксов — через уязвимость в модуле vote (BDU:2022-05127). Через неё заливали веб-шеллы пачками. Причина? Владельцы не обновляли ядро по полгода, а модуль голосований стоял «на всякий случай». С тех пор мало что изменилось в подходе: Битрикс выпускает патч, а его ставят через три месяца. Мы выстраиваем комплексную безопасность сайта так, чтобы между выходом патча и его применением проходили дни, а не месяцы. И чтобы даже без патча сайт не лёг от типовой атаки.

Закажите аудит безопасности сайта — получите отчёт с приоритетами и план закрытия уязвимостей за 1-2 дня.

Модуль «Проактивная защита» — мощный, но не из коробки

Модуль security установлен почти на каждом Битриксе, но настроен правильно — от силы на каждом пятом. Что конкретно нужно включить и подкрутить:

• WAF (Веб-антивирус) — фильтрует SQL-инъекции, XSS, CSRF, path traversal на уровне OnPageStart. Ключевая настройка — режим «Активная реакция»: не просто логировать, а блокировать. В /bitrix/admin/security_filter.php проверяем, что все типы атак включены, а исключения — минимальны.
• Контроль активности (/bitrix/admin/security_iprule.php) — лимиты на количество запросов с одного IP. По умолчанию 100 запросов в минуту. Для API-эндпоинтов, куда стучат мобильные приложения, нужны исключения — иначе заблокируете своих же пользователей.
• 2FA — OTP через Google Authenticator. Включается в настройках пользователя. Для группы «Администраторы» делаем обязательным через OnAfterUserAuthorize — без второго фактора в админку не пускаем.
• Контроль целостности (/bitrix/admin/security_file_verifier.php) — хэши системных файлов. Если кто-то изменил файл в /bitrix/modules/ — система заметит. Запускаем проверку по cron ежедневно через агент CSecurityFileVerifier::Verify().
• Стоп-лист — b_security_filter_stoplist. Автоматическая блокировка IP при срабатывании WAF. Ручное добавление подсетей — когда видим сканеры.
• Журнал безопасности — b_event_log. Кто, когда и что менял в админке. Хранение минимум 90 дней. При расследовании инцидента — бесценно.

Что включает аудит безопасности сайта Битрикс?

Серверный уровень — тут чаще всего и дыры:

• phpinfo() доступен по /info.php или /phpinfo.php — встречается на каждом третьем проекте. Атакующий получает версию PHP, пути, модули, конфигурацию. Удаляем.
• display_errors = On на продакшне — стектрейсы с путями к файлам и именами таблиц улетают пользователю в браузер.
• PHP-функции exec, system, passthru, proc_open не отключены в php.ini. Если веб-шелл всё-таки зальют — с этими функциями он получит полный контроль над сервером.
• Версия PHP < 8.1 — без security-апдейтов. PHP 7.4 больше не поддерживается, но до сих пор живёт на четверти проектов.

Уровень приложения:

• Устаревшие модули: vote, forum, blog — часто стоят неиспользуемые, но с активными обработчиками. Деактивируем и удаляем.
• Кастомный код: grep по $DB->Query( с конкатенацией $_REQUEST — классическая SQL-инъекция. Должны быть $DB->ForSql() или D7 ORM.
• Загрузка файлов: если CFile::CheckFile() не вызывается или проверяет только расширение без MIME-типа — через форму обратной связи зальют .php файл.
• dbconn.php и .env — должны быть закрыты правилами веб-сервера. Проверяем: curl https://site.ru/bitrix/.settings.php не должен отдавать ничего кроме 403.

SSL/TLS:

• Проверка через SSL Labs — рейтинг A или выше.
• HSTS с max-age от 31536000 (год).
• Редирект HTTP -> HTTPS на уровне Nginx, не на уровне Битрикса.

Результат аудита — отчёт с приоритетами: Critical / High / Medium / Low. Критические закрываем в первый день. Свяжитесь с нами — оценим ваш проект за 1-2 дня.

Лечение взломанных сайтов — протокол действий

Сайт уже скомпрометирован — SEO-спам, редиректы на казино, веб-шелл в /upload/. Порядок действий:

1. Изоляция — снимаем сайт, ставим заглушку. Если вредонос шифрует файлы или распространяется — каждая минута на счету.
2. Определение вектора — логи доступа (access.log), логи ошибок, b_event_log. Ищем POST-запросы к нетипичным файлам, обращения к /upload/*.php, подозрительные user-agent.
3. Поиск вредоносного кода — grep -r "eval(base64_decode" /home/bitrix/www/ — классика. Также ищем assert(, preg_replace с модификатором e, ${"_GET"}, обфусцированные переменные вида $GLOBALS['x46x65'].
4. Проверка БД — b_iblock_element_property и b_iblock_element на инъектированные скрипты и скрытые ссылки. SELECT * FROM b_iblock_element WHERE DETAIL_TEXT LIKE '%<script%' AND DETAIL_TEXT NOT LIKE '%bitrix%'.
5. Чистка или восстановление — если заражение масштабное, проще восстановить из чистого бэкапа и накатить только контентные изменения из БД.
6. Закрытие уязвимости — обновление ядра, удаление неиспользуемых модулей, правка кастомного кода.
7. Запрос пересканирования — Google Search Console → «Запросить проверку», Яндекс.Вебмастер → «Я всё исправил».

Средняя стоимость восстановления после взлома — от 40 000 до 100 000 руб., а профилактический аудит обходится в 2-3 раза дешевле. Вложив 30 000 руб. в аудит, вы можете сэкономить до 200 000 руб. на ликвидации последствий.

Как защитить сайт на Битриксе от DDoS?

• Cloudflare / DDoS-Guard / Qrator — проксирование трафика. L3/L4 атаки фильтруются на их стороне. L7 — через правила и challenge-страницы. Важно: после подключения скрыть реальный IP сервера, иначе смысл теряется.
• Rate limiting на Nginx: limit_req_zone для /bitrix/admin/, /api/, форм. Отдельные лимиты для авторизованных и анонимных пользователей.
• CAPTCHA — \Bitrix\Main\Captcha\CaptchaManager для форм Битрикса или reCAPTCHA v3 для кастомных. v3 не раздражает пользователей — работает в фоне.
• Bot management — пропускаем Googlebot, YandexBot (проверка через reverse DNS), блокируем сканеры и скрейперы по User-Agent и поведению.

Сравнение: rate limiting на Nginx в 5 раз эффективнее стандартной защиты от перебора паролей в Битриксе, так как срезает атаку до того, как она дойдёт до PHP.

Резервное копирование — последний рубеж

• Ежедневные бэкапы: файлы через rsync + дамп PostgreSQL/MySQL через pg_dump/mysqldump.
• Хранение в изолированном S3-совместимом хранилище. Ключевое слово — изолированном. Если бэкапы лежат на том же сервере, что и сайт, взломщик удалит и их.
• Ротация: daily × 7, weekly × 4, monthly × 12.
• Тестирование восстановления — раз в квартал разворачиваем бэкап на тестовом сервере. Бэкап, из которого невозможно восстановиться, — просто файл на диске.
• Мониторинг: если бэкап не прошёл — алерт в Telegram в течение часа.

Мониторинг — обнаружить до того, как позвонит клиент

• Uptime — проверка каждые 60 секунд через UptimeRobot / Zabbix / кастомный скрипт. Алерт в Telegram + звонок при даунтайме > 5 минут.
• Файловый мониторинг — inotify (Linux) или cron + md5sum по критичным директориям. Новый .php в /upload/? Алерт немедленно.
• Сканирование на малварь — AI-BOLIT или ClamAV по расписанию. Проверка и файлов, и базы.
• SSL-сертификат — предупреждение за 30/14/7 дней до истечения. Let's Encrypt обновляется автоматически через certbot, но certbot тоже может сломаться.
• Блэклисты — проверка домена и IP в Google Safe Browsing, PhishTank, Spamhaus. Попадание = потеря трафика.

152-ФЗ и персональные данные

• HTTPS everywhere — редирект на уровне Nginx.
• Шифрование в БД: пароли через \Bitrix\Main\Security\Password::hash() (bcrypt), токены — через openssl_encrypt.
• Политика конфиденциальности + cookie-баннер (модуль main поддерживает из коробки через COption::SetOptionString("main", "cookie_agreement", "Y")).
• Журналирование доступа к ПД — кто и когда просматривал данные клиентов.

Что входит в работу (deliverables)

Сроки

Работаем разово и на абоненте с фиксированным SLA. Для абонентских клиентов — выделенный инженер, который знает проект. Получите консультацию — оценим риски и составим смету за 1-2 дня.

Чек-лист: 15 пунктов, которые проверяем на каждом проекте

1. Ядро 1С-Битрикс и модули — актуальная версия, неиспользуемые модули удалены.
2. Модуль security активен, WAF в режиме «Активная реакция».
3. 2FA включена для всех учёток с доступом к админке.
4. /bitrix/admin/ закрыт по IP или за дополнительной HTTP-авторизацией.
5. Политика паролей: от 12 символов, mixed case, цифры, спецсимволы.
6. SSL/TLS: рейтинг A+ на SSL Labs, HSTS включён.
7. Служебные файлы (dbconn.php, .settings.php, .env, бэкапы, логи) — 403 из браузера.
8. Права: 644 файлы, 755 директории. Веб-сервер не owner системных файлов.
9. Security-заголовки: Content-Security-Policy, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Strict-Transport-Security, Referrer-Policy.
10. Контроль целостности файлов — ежедневная проверка через агент.
11. Бэкапы: ежедневные, изолированное хранение, проверка восстановимости.
12. b_event_log — хранение от 90 дней, регулярный просмотр.
13. PHP 8.1+, display_errors = Off, опасные функции отключены.
14. Мониторинг uptime + алерты при изменении файлов в /upload/.
15. Reverse proxy или CDN с DDoS-защитой для высоконагруженных проектов.

Оценка уязвимостей проводится в соответствии с методологией OWASP Top 10 – Web Application Security Risks (см. Wikipedia). Комплексная безопасность сайта на Битрикс — это не разовая акция, а непрерывный процесс. Закажите полный аудит безопасности сайта сегодня, чтобы завтра не тратить бюджет на экстренное восстановление. Получите консультацию — мы ответим на любые вопросы.