Rate limiting и Fail2Ban для Битрикс: лимиты запросов и автобан на уровне сервера

Когда сайт на Битрикс начинает страдать от ботов, перебора и флуда, возникает соблазн решить всё одним инструментом: поставить готовый WAF, подключить облачную защиту или включить «режим под атакой» и забыть. На практике серебряной пули нет: разные слои защиты закрывают разные задачи и работают лучше всего вместе. Rate limiting и Fail2Ban — это базовый, дешёвый по ресурсам и очень эффективный рубеж, который должен стоять почти на любом боевом сайте, независимо от того, есть ли над ним облачная защита. Ниже разбираем, как он устроен, какие проблемы решает и где его границы.

Почему ограничение частоты работает там, где не справляется приложение

Любая защита внутри Битрикса — капча, проверка токенов, лимиты в коде — срабатывает уже после того, как запрос дошёл до PHP, поднял сессию, подключился к базе и запустил тяжёлую логику. При флуде это значит, что сервер честно тратит ресурс на обработку каждого вредного запроса, пусть даже потом он его отклонит. Rate limiting на nginx переворачивает картину: лимит частоты проверяется до запуска PHP, и лишний запрос получает отказ почти бесплатно. Именно поэтому ограничение частоты так хорошо держит флуд форм, перебор и агрессивный парсинг — оно отсекает нагрузку на самом дешёвом для сервера этапе.

Fail2Ban идёт ещё дальше и опускает защиту на уровень firewall. Когда источник опознан как нарушитель по логам, его IP банится на iptables, и следующие запросы отбрасываются ядром, не доходя даже до nginx. Это предельно дёшево по ресурсам и предельно эффективно против тех, кто долбит сайт сериями однотипных запросов: перебирает пароли, сканирует пути, выкачивает каталог. Связка ограничения частоты на nginx и автобана на iptables закрывает большую часть автоматизированного вредного трафика, который обычно и создаёт фоновую нагрузку.

Какие атаки закрывает связка, а какие нет

Честно очертим границы. Rate limiting и Fail2Ban отлично работают против перебора паролей, флуда форм и поиска, серийного сканирования путей и парсинга — всего, что исходит от ограниченного числа источников и выражается в аномальной частоте запросов. Они заметно снижают фоновую нагрузку и делают логи читаемыми. Но они не заменяют полноценную защиту от распределённого DDoS с тысяч адресов, не разбирают содержимое запросов на предмет SQL-инъекций и XSS и не фильтруют сложные прикладные атаки. Для распределённых атак и фильтрации по содержимому нужен отдельный слой, и если он вам важен, мы отдельно настраиваем WAF на ModSecurity или Cloudflare, который дополняет лимиты и автобан, а не отменяет их.

Поэтому правильный подход — слоёная оборона. Rate limiting и Fail2Ban стоят первым рубежом и снимают массовый автоматический мусор дёшево и без вашего участия. Над ними при необходимости встаёт WAF и облачная защита для распределённых атак и фильтрации по содержимому. А внутри Битрикса работает прикладная безопасность: капчи, токены, разграничение прав. Каждый слой делает свою работу, и вместе они дают результат, которого ни один из них в одиночку не даёт.

Главный риск автобана — забанить своих

У любой автоматической защиты есть оборотная сторона: чем агрессивнее пороги, тем выше шанс случайно заблокировать легитимный трафик. Менеджер, который быстро кликает по админке, обмен с 1С, который шлёт пачку запросов, мониторинг, который опрашивает сайт каждую минуту, CDN, который ходит с одного адреса за всех, платёжный шлюз, который шлёт коллбэки, — всё это может выглядеть как аномалия и попасть под бан. Поэтому белые списки и калибровка порогов для нас не формальность, а центральная часть работы. Офис, сети 1С, мониторинг, CDN и платёжные коллбэки вносятся в исключения, а пороги подбираются по реальным логам, чтобы нормальная активность не срабатывала как атака.

Чтобы исключить сюрпризы, мы обязательно проверяем поведение защиты под нагрузкой до боевого запуска и несколько дней наблюдаем за банами после. Если в журнал попадает легитимный источник, мы сразу это видим и правим — добавляем в белый список или поднимаем порог. Такой подход даёт защиту, которая бьёт точно по нарушителям и не мешает работе. Эта же аккуратность критична, когда лимиты соседствуют с другими мерами против ботов: ограничение частоты хорошо сочетается с защитой от бот-трафика и парсинга, но пороги обоих слоёв нужно согласовать, чтобы они не конфликтовали.

Почему важна специфика Битрикса

Готовый конфиг limit_req и стандартный jail из интернета часто бесполезны на Битрикс, потому что не учитывают структуру его URL и формат логов. Адреса админки, AJAX-эндпоинтов, обмена с 1С, личного кабинета и API в Битрикс устроены определённым образом, и лимиты нужно вешать именно на них, не задевая служебные запросы. Логи Битрикса и nginx тоже надо уметь читать: фильтр Fail2Ban должен опознавать именно неудачную авторизацию или серию 404, а не любую строку. Без этого защита либо не ловит атаки, либо ловит лишнее. Поэтому мы строим правила под конкретный сайт, а не накатываем универсальный шаблон.

Отдельно учитываем интеграции. Обмен с 1С, выгрузки, платёжные и логистические сервисы шлют запросы пачками и с предсказуемых адресов — их нужно знать заранее и вынести из-под лимитов и банов. Если у вас сложная интеграционная обвязка, мы согласуем правила так, чтобы внешние системы работали без сбоев, а защита при этом не превращалась в решето. Это особенно важно для проектов, где параллельно идёт поддержка nginx, Apache, PHP и MySQL: лимиты и автобан должны жить в одном контуре с общей настройкой веб-сервера и не конфликтовать с ней.

Как мы ведём настройку по шагам

Первый шаг — разбор логов и трафика. Мы смотрим, какие атаки реально идут: где брутфорс, где флуд форм, где серии 404 от сканеров, откуда парсинг, и как выглядит нормальная нагрузка в будни и в пик. Без этого пороги ставить нельзя — они получатся либо слишком мягкими, либо опасными для своих. Второй шаг — проектирование: определяем зоны лимитов и их пороги, время банов и эскалацию, составляем белые списки. Третий — настройка nginx и Fail2Ban: прописываем limit_req и limit_conn, пишем фильтры и jail под ваши логи, связываем баны с iptables и журналом срабатываний.

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

Чем настроенная защита выгоднее альтернатив

У сайта, который устал от ботов и перебора, обычно три пути. Первый — терпеть и периодически банить вручную: это съедает время админа и не масштабируется, потому что атаки идут круглосуточно. Второй — переложить всё на дорогую облачную защиту: она нужна против распределённого DDoS, но для рутинного перебора и флуда это стрельба из пушки по воробьям, к тому же она не отменяет необходимости фильтровать трафик на своём сервере. Третий — настроить rate limiting и Fail2Ban: дёшево по ресурсам, работает автоматически, закрывает самый массовый класс атак и отлично сочетается с остальными слоями.

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

Возражения, которые мы слышим чаще всего

«У нас и так стоит облачная защита, зачем ещё лимиты на сервере». Облачная защита и rate limiting закрывают разные задачи: первая отбивает распределённые атаки на подлёте, второй режет флуд и перебор уже на вашем сервере и банит конкретных нарушителей. Часть вредного трафика всегда доходит до сервера в обход облака, и хорошо, когда его там встречает лимит и автобан. Слои не конкурируют, а усиливают друг друга.

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

«Это разовая настройка или её надо вести». Базовая защита от брутфорса и флуда работает и без сопровождения. Но атаки эволюционируют: появляются новые сканеры, меняются цели перебора, растёт парсинг. Поэтому для нагруженных и заметных проектов мы предлагаем сопровождение, в рамках которого разбираем баны, правим пороги и добавляем новые jail под новые угрозы. Решение за вами — защита остаётся вашей в любом случае.

Сценарии, под которые мы настраиваем защиту

Атаки и нагрузка на разных сайтах выглядят по-разному, поэтому правила мы собираем под конкретную картину, а не по единому шаблону. Для интернет-магазина с ценным каталогом главная боль — это парсеры и переборщики, которые выкачивают товары и цены, и флуд форм оформления заказа. Здесь на первый план выходят лимиты на каталог, поиск и API и автобан агрессивных выкачивающих источников, при этом обмен с 1С и платёжные коллбэки аккуратно выносятся в белые списки. Для корпоративного сайта типичнее перебор паролей в админку и серийное сканирование уязвимых путей, поэтому ядром становится жёсткий jail на брутфорс входа и отдельное правило на серии 404 от сканеров.

Для B2B-портала с личными кабинетами и API картина сложнее: легитимные интеграции шлют много запросов, и защита не должна им мешать, но при этом нужно отсекать перебор учётных записей и выкачивание данных через API. Тут особенно важна тонкая калибровка порогов и подробные белые списки для всех внешних систем. Для медиа и сайтов с высоким трафиком на первый план выходит защита от флуда, который маскируется под обычных читателей: здесь работают мягкие, но широкие лимиты и автобан только самых явных нарушителей, чтобы не задеть массовую легитимную аудиторию. В каждом из этих случаев набор jail, зоны лимитов и пороги мы подбираем индивидуально по логам.

Что мы проверяем перед боевым запуском

Прежде чем включить защиту в бой, мы прогоняем её через проверочный чек-лист, чтобы исключить сюрпризы. Сначала тестируем поведение лимитов под нагрузкой: имитируем всплески трафика и убеждаемся, что легитимные серии запросов проходят, а равномерный флуд режется. Затем специально провоцируем срабатывания фильтров Fail2Ban и проверяем, что баны накладываются и снимаются корректно, а время бана и эскалация работают как задумано. Отдельно прогоняем сценарии своих систем: пробуем обмен с 1С, выгрузки, обращения мониторинга и платёжные коллбэки — и убеждаемся, что ни один из них не попадает под лимит или бан.

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

С чего начать

Начните с разбора логов. Пришлите нам логи nginx и Битрикса или дайте доступ к серверу — мы покажем, какие атаки реально идут на ваш сайт, какую долю трафика создают боты, перебор и флуд, и что из этого можно отсечь лимитами и автобаном. По итогам разбора предложим состав защиты под вашу нагрузку и интеграции и пришлём смету в течение рабочего дня. Аудит логов бесплатный, и даже если вы решите настраивать защиту своими силами, вы получите ясную картину угроз и приоритетов. Обсудим ваш проект — и превратим хаотичный поток ботов в управляемую и автоматически отбиваемую нагрузку.