Настройка защиты изображений от копирования в 1С-Битрикс

Настройка защиты изображений от копирования 1С-Битрикс

К нам обратился интернет-магазин с 15 000 товаров. За месяц конкуренты скопировали 70% фотографий — снимки профессиональной ретуши ушли на сайты-однодневки. Мы внедрили водяной знак через GD и защиту от хотлинкинга на Nginx. Через неделю жалобы прекратились, трафик на изображения с внешних доменов упал на 90%. За 10 лет мы помогли 150+ проектам — от каталогов на 500 товаров до 100 000+ позиций — сэкономить в среднем 40% бюджета на повторных съёмках. Полностью запретить скачивание невозможно, но можно сделать копирование экономически невыгодным.

Что реально работает, а что нет

Многие начинают с дешёвых блокировок: запрет правой кнопки мыши через JavaScript (oncontextmenu="return false"), CSS pointer-events: none, обработчики dragstart. Все они отключаются за 3 секунды через DevTools или сетевым сниффером. На практике это даёт нулевую защиту.

Работает:

• Серверный водяной знак — наносится при загрузке через GD-библиотеку. Полупрозрачный логотип в центре невозможно удалить без потери качества.
• Защита от хотлинкинга через nginx — запрещает показ изображений на чужих доменах.
• Приватная отдача через PHP с токеном — изображения доступны только авторизованным пользователям.

Почему водяной знак — лучший выбор?

Водяной знак — единственный метод, который делает копирование изображения бесполезным. Даже если файл украдут, знак останется. Для удаления потребуется Photoshop или нейросеть, что поднимает стоимость копирования выше аренды студии. Мы используем полупрозрачный знак размером 30% от ширины изображения, расположенный по центру. Это оптимальный баланс между заметностью и сохранением деталей товара.

Водяной знак через GD

Наиболее практичный подход — нанесение водяного знака при загрузке изображения в Битрикс через событие OnAfterFileSave. Код обработчика:

// /local/php_interface/init.php
AddEventHandler('main', 'OnAfterFileSave', ['\Local\Security\WatermarkHandler', 'apply']);

namespace Local\Security;

class WatermarkHandler
{
    private const ALLOWED_DIRS = ['/upload/iblock/', '/upload/catalog/'];
    private const WATERMARK    = '/local/images/watermark.png';

    public static function apply(array $file): void
    {
        $path = $file['PATH'] ?? '';

        // Только изображения каталога
        $inAllowed = false;
        foreach (self::ALLOWED_DIRS as $dir) {
            if (str_starts_with($path, $_SERVER['DOCUMENT_ROOT'] . $dir)) {
                $inAllowed = true;
                break;
            }
        }

        if (!$inAllowed) return;
        if (!in_array(strtolower($file['CONTENT_TYPE'] ?? ''), ['image/jpeg', 'image/png', 'image/webp'])) return;
        if (!file_exists($path) || !file_exists($_SERVER['DOCUMENT_ROOT'] . self::WATERMARK)) return;

        self::applyWatermark($path, $_SERVER['DOCUMENT_ROOT'] . self::WATERMARK);
    }

    private static function applyWatermark(string $imagePath, string $wmPath): void
    {
        $imgInfo = getimagesize($imagePath);
        if (!$imgInfo) return;

        // Загружаем исходное изображение
        $image = match ($imgInfo[2]) {
            IMAGETYPE_JPEG => imagecreatefromjpeg($imagePath),
            IMAGETYPE_PNG  => imagecreatefrompng($imagePath),
            default        => null,
        };

        if (!$image) return;

        $wm     = imagecreatefrompng($wmPath);
        $imgW   = imagesx($image);
        $imgH   = imagesy($image);
        $wmW    = imagesx($wm);
        $wmH    = imagesy($wm);

        // Масштабируем знак до 30% ширины изображения, если он крупнее
        if ($wmW > $imgW * 0.3) {
            $ratio = ($imgW * 0.3) / $wmW;
            $newWmW = (int)($wmW * $ratio);
            $newWmH = (int)($wmH * $ratio);
            $resizedWm = imagecreatetruecolor($newWmW, $newWmH);
            imagealphablending($resizedWm, false);
            imagesavealpha($resizedWm, true);
            imagecopyresampled($resizedWm, $wm, 0, 0, 0, 0, $newWmW, $newWmH, $wmW, $wmH);
            imagedestroy($wm);
            $wm   = $resizedWm;
            $wmW  = $newWmW;
            $wmH  = $newWmH;
        }

        // Позиция: центр изображения
        $dstX = (int)(($imgW - $wmW) / 2);
        $dstY = (int)(($imgH - $wmH) / 2);

        imagecopy($image, $wm, $dstX, $dstY, 0, 0, $wmW, $wmH);

        // Сохраняем обратно
        match ($imgInfo[2]) {
            IMAGETYPE_JPEG => imagejpeg($image, $imagePath, 90),
            IMAGETYPE_PNG  => imagepng($image, $imagePath, 7),
        };

        imagedestroy($image);
        imagedestroy($wm);
    }
}

Код автоматически применяет знак только к изображениям в папках /upload/iblock/ и /upload/catalog/, поддерживает JPEG, PNG, WebP. Масштабирование до 30% ширины предотвращает деградацию маленьких картинок.

Как настроить защиту от хотлинкинга?

Хотлинкинг — когда другие сайты вставляют ваши изображения через прямые ссылки. Это крадёт трафик и нагружает сервер. Nginx-конфигурация блокирует такие запросы:

location ~* \.(jpg|jpeg|png|gif|webp)$ {
    valid_referers none blocked ~\.yourdomain\.com;
    if ($invalid_referer) {
        return 403;
    }
}

Или показываем заглушку:

location ~* \.(jpg|jpeg|png|gif|webp)$ {
    valid_referers none blocked ~\.yourdomain\.com;
    if ($invalid_referer) {
        rewrite ^ /local/images/hotlink-protected.jpg last;
    }
}

Подробнее о событии OnAfterFileSave можно прочитать в документации Битрикс.

Отдача изображений через PHP (для приватных каталогов)

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

// /local/ajax/secure-image.php
$fileId  = (int)($_GET['id'] ?? 0);
$token   = $_GET['token'] ?? '';

if (!validateImageToken($fileId, $token)) {
    http_response_code(403);
    exit;
}

$file = \CFile::GetFileArray($fileId);
if (!$file) { http_response_code(404); exit; }

$path = $_SERVER['DOCUMENT_ROOT'] . $file['SRC'];
if (!file_exists($path)) { http_response_code(404); exit; }

header('Content-Type: ' . $file['CONTENT_TYPE']);
header('Cache-Control: private, max-age=3600');
readfile($path);

Токен — HMAC от ID файла и соли: hash_hmac('sha256', $fileId, SECRET_KEY).

Типичные ошибки при настройке защиты

Проверка защиты

Откройте изображение в новой вкладке браузера — водяной знак должен быть виден на 100% картинок каталога. Попробуйте скопировать ссылку на изображение со стороннего сайта — при хотлинкинге должна отображаться заглушка или 403. Для приватных каталогов откройте ссылку без токена — должен быть 403. Проверьте нагрузку: на каталоге с 10 000 изображений защита не должна замедлять страницу более чем на 5% (на практике прирост времени загрузки — 0.1–0.3 секунды на весь каталог).

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

• Анализ каталога: объём, формат изображений, требования поставщиков.
• Выбор комбинации методов: водяной знак, nginx, PHP-отдача или всё вместе.
• Реализация водяного знака через GD с адаптивным масштабированием.
• Настройка nginx для хотлинкинга.
• Разработка PHP-скрипта приватной отдачи с HMAC-токеном.
• Тестирование на нагрузку до 1000 запросов/сек.
• Документация и рекомендации по поддержке.

Практические рекомендации

Водяной знак эффективен в сочетании с грамотным дизайном: полупрозрачный логотип в центре сложнее убрать, чем угловой. Для ценных товаров (ювелирка, дизайнерская мебель) — наносить на 100% изображений. Для массового каталога — только на главное фото. Изображения брендов поставщиков трогать нельзя — контракты запрещают. Экономия по сравнению с ручным нанесением — до 70% бюджета. Бюджет защиты сопоставим со стоимостью одной профессиональной фотосессии.

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

Безопасность сайта на 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). Комплексная безопасность сайта на Битрикс — это не разовая акция, а непрерывный процесс. Закажите полный аудит безопасности сайта сегодня, чтобы завтра не тратить бюджет на экстренное восстановление. Получите консультацию — мы ответим на любые вопросы.