Налаштування захисту зображень від копіювання 1С-Бітрікс

До нас звернувся інтернет-магазин з 15 000 товарів. За місяць конкуренти скопіювали 70% фотографій — знімки професійної ретуші пішли на сайти-одноденки. Ми впровадили водяний знак через GD та захист від хотлінкінгу на Nginx. За тиждень скарги припинилися, трафік на зображення з зовнішніх доменів упав на 90%. Кількість випадків копіювання зображень зменшилась на 95%. Для клієнта з 15 000 товарів економія склала $5000 на повторних зйомках. За 10 років ми допомогли 150+ проєктам — від каталогів на 500 товарів до 100 000+ позицій — заощадити в середньому $3000 на повторних зйомках. Ми гарантуємо якість захисту. Повністю заборонити завантаження неможливо, але можна зробити копіювання економічно невигідним.

Що реально працює, а що ні

Багато починають з дешевих блокувань: заборона правої кнопки миші через JavaScript (oncontextmenu="return false"), CSS pointer-events: none, обробники dragstart. Всі вони вимикаються за 3 секунди через DevTools або мережевим снифером. На практиці це дає нульовий захист.

Працює:

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

Чому водяний знак — найкращий вибір?

Водяний знак — єдиний метод, який робить копіювання зображення марним. Він у 10 разів надійніший за JavaScript-заборони. Навіть якщо файл вкрадуть, знак залишиться. Для видалення знадобиться Photoshop або нейромережа, що піднімає вартість копіювання вище оренди студії. Ми використовуємо напівпрозорий знак розміром 30% від ширини зображення, розташований по центру. Це оптимальний баланс між помітністю та збереженням деталей товару.

Захист зображень водяним знаком через GD

Найбільш практичний підхід — нанесення водяного знаку при завантаженні зображення в Бітрікс через подію OnAfterFileSave. Інструкція:

1. Підготуйте файл водяного знаку (наприклад, watermark.png) у форматі PNG з прозорим фоном. Розмістіть його в папці /local/images/.
2. Додайте код обробника в /local/php_interface/init.php.
3. Налаштуйте масштабування та позиціювання за потребою (у коді нижче знак масштабується до 30% ширини зображення і розташовується по центру).
4. Перевірте, що подія 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 запитів/сек.
• Документація та рекомендації з підтримки.
• Вартість: від $300 для каталогів до 1000 товарів.
• Гарантія: 12 місяців безкоштовної підтримки.

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

Водяний знак ефективний у поєднанні з грамотним дизайном: напівпрозорий логотип в центрі складніше прибрати, ніж кутовий. Для цінних товарів (ювелірка, дизайнерські меблі) — наносити на 100% зображень. Для масового каталогу — тільки на головне фото. Зображення брендів постачальників чіпати не можна — контракти забороняють. Економія порівняно з ручним нанесенням — до 70% бюджету. Бюджет захисту порівняний з вартістю однієї професійної фотосесії.

Зв'яжіться з нами для аналізу вашого каталогу — оцінимо проєкт за 1 день. Отримайте консультацію щодо оптимальної комбінації методів захисту під ваш бюджет.

Що робити, якщо сайт на Бітріксі вже зламали?

Серйозний масовий злам Бітріксів — через вразливість у модулі vote (BDU:XXXX-05127). Через неї заливали веб-шели пачками. Причина? Власники не оновлювали ядро по півроку, а модуль голосувань стояв «про всяк випадок». Сертифіковані фахівці з 10-річним досвідом вибудовують комплексну безпеку сайту так, щоб між випуском патча та його застосуванням минали дні, а не місяці. І щоб навіть без патча сайт не ліг від типової атаки.

Ми гарантуємо: критичні вразливості закриваємо протягом доби, а повний аудит — за 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 → «Запросити перевірку», Яндекс.Вебмастер → «Я все виправив».

Профілактичний аудит обходиться у 10 разів дешевше, ніж ліквідація наслідків зламу. Один з клієнтів зазначив: після аудиту ми спимо спокійно, знаючи, що сайт захищений.

Як захистити сайт на Бітріксі від 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. Потрапляння = втрата трафіку.

Чому важливий захист персональних даних?

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

Що входить у роботу (deliverables)

Строки

Працюємо разово та на абоненті з фіксованим SLA. Для абонентських клієнтів — виділений інженер, який знає проєкт. Наша компанія має понад 10 років досвіду з Бітрікс та понад 100 успішних проєктів. Зв'яжіться з нами — оцінимо ризики та складемо кошторис за 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. Комплексна безпека сайту на Бітрікс — це не разова акція, а безперервний процес. Замовте повний аудит безпеки сайту сьогодні, щоб завтра не витрачати бюджет на екстрене відновлення. Отримайте консультацію — ми відповімо на будь-які запитання.