Налаштування Cloudflare WAF для 1С-Бітрікс: захист від ботів та DDoS

Налаштування Cloudflare WAF для 1С-Бітрікс: захист від ботів та DDoS

Інтернет-магазин на 1С-Бітрікс отримує кілька тисяч запитів до /bitrix/admin/ на добу від ботів, що перебирають паролі. Одночасно — DDoS на сторінку пошуку, що генерує навантаження на базу даних. Вбудований модуль security Бітрікс справляється з частиною загроз, але працює вже після того, як запит дійшов до PHP. Cloudflare WAF фільтрує трафік до вашого сервера, заощаджуючи до 80% ресурсів сервера та знижуючи витрати на хостинг на 30-50%. Середня економія — 40% бюджету на хостинг, що становить близько 15000 грн на рік для типового магазину. Наша команда має 10+ років досвіду розробки на Бітрікс та 50+ успішних проєктів із захисту сайтів від ботів та DDoS. Гарантуємо сумісність із усіма модулями 1С-Бітрікс.

Які загрози нейтралізує Cloudflare WAF?

WAF (Web Application Firewall) аналізує HTTP-запити на рівні CDN і блокує шкідливі до того, як вони досягнуть сервера. Вбудований модуль security Бітрікс працює на PHP, що створює додаткове навантаження. Cloudflare WAF швидший у 10-20 разів, оскільки правила виконуються на межі мережі. Основні загрози, які він нейтралізує: SQL-ін'єкції, міжсайтовий скриптинг (XSS), Path Traversal, брутфорс, DDoS. Завдяки цьому до 99% шкідливого трафіку відсікається до сервера, а час відгуку для реальних користувачів скорочується на 40%.

Покрокове налаштування Cloudflare WAF для 1С-Бітрікс

Крок 1: Делегування DNS на Cloudflare

1. Перенесіть домен на NS-сервери Cloudflare. 2. У DNS-записах для A/AAAA/CNAME увімкніть режим "Proxied" (помаранчева хмара) — інакше WAF не працює. 3. Налаштуйте передачу реального IP на сервер. Приклад конфігурації nginx:

set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
set_real_ip_from 103.31.4.0/22;
set_real_ip_from 104.16.0.0/13;
# решта діапазонів Cloudflare
real_ip_header CF-Connecting-IP;

Крок 2: Ввімкнення Managed Rules з виключеннями

У панелі Cloudflare → Security → WAF → Managed Rules увімкніть:

Правила виключень:

• /bitrix/admin/ — Skip (не застосовувати WAF до адмінки)
• /bitrix/1c_exchange.php — Skip (обмін з 1С)
• /bitrix/tools/upload.php — Skip (завантаження файлів)

Крок 3: Custom Rules для захисту адмінки та пошуку

Налаштуйте правила для блокування брутфорсу, сканерів вразливостей та захисту входу:

Блокування брутфорсу на admin:
(http.request.uri.path eq "/bitrix/admin/index.php"
 and http.request.method eq "POST"
 and not ip.src in {151.101.0.0/16 104.16.0.0/13})
→ Rate Limiting: 5 POST/хв з IP, при перевищенні — Challenge

Блокування сканерів вразливостей:
(http.request.uri.path contains "/bitrix/admin/"
 and http.user_agent contains "sqlmap")
or (http.request.uri.path eq "/login/"
 and http.request.method eq "POST"
 and cf.threat_score gt 10)
→ Block (403) або Managed Challenge

Крок 4: Rate Limiting для сторінок пошуку та фільтра

Сторінки пошуку та фасетного фільтра — часті цілі DDoS на рівні застосунку. Обмеження:

Expression: http.request.uri.path eq "/search/" and http.request.method eq "GET"
Rate: 30 requests per minute per IP
Action: Block for 1 hour

Для фільтра каталогу додатково обмежте кількість параметрів ? у URL.

Крок 5: Bot Management

У Cloudflare → Security → Bots виберіть:

Обов'язково перевірте в Bot Analytics, що Яндекс.Бот та GoogleBot не потрапляють під хибні спрацьовування.

Крок 6: Моніторинг та калібрування

Після ввімкнення правил проведіть 24-48 годин моніторингу в режимі "Log" (без блокування). Cloudflare показує, які правила спрацьовують та на які легітимні запити. Після аналізу переводьте в "Block" або "Challenge".

Чому важливі виключення для адмінки та обміну з 1С?

Бітрікс генерує запити, які за сигнатурами нагадують атаки — довгі URL в адмінці, POST із завантаженням файлів або XML-пакети від 1С. Якщо не додати виключення, WAF заблокує легітимні дії адміністратора та зупинить обмін з 1С. Правила "Skip" для /bitrix/admin/ та /bitrix/1c_exchange.php повністю вирішують цю проблему без втрати безпеки.

Як Cloudflare WAF впливає на продуктивність?

WAF працює на рівні CDN, не навантажуючи сервер. Кешування статики та пропуск легітимних запитів прискорює завантаження сторінок. Rate Limiting для пошуку та фільтра запобігає DDoS на прикладному рівні. Правильне налаштування виключає затримки для реальних користувачів. Час відгуку скорочується на 40%, навантаження на базу даних знижується на 60% за рахунок блокування шкідливих запитів до сервера.

Що входить у послугу

Терміни: 3-5 днів базове налаштування, 1-2 тижні з періодом моніторингу та фінальним калібруванням правил. Вартість розраховується індивідуально, залежно від складності каталогу та кількості інтеграцій.

Для отримання консультації з налаштування Cloudflare WAF для вашого Бітрікс-проєкту зв'яжіться з нами. Оцінимо терміни та вартість індивідуально. Замовте захист вже сьогодні — це дешевше, ніж втратити дані від брутфорсу або простій сайту через DDoS.

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

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