Защита хостинга от ботов: CrowdSec, BitNinja и Imunify360 на практике

На shared-хостинге боты — это фон: сканеры уязвимостей, перебор паролей к админкам, агрессивные краулеры, которые кладут сайты нагрузкой. Защищаться приходится сразу на уровне всего сервера, а не отдельного сайта. Я работал с тремя инструментами — CrowdSec, BitNinja и Imunify360. Это не сравнительный бенчмарк, а практические заметки: как каждый устроен, как с ним жить в поддержке и где подводные камни.

Домены клиентов, ключи лицензий и внутренние адреса не приводятся.

CrowdSec — «fail2ban на максималках»

Как устроен. Агент разбирает логи (SSH, веб-сервер, панели), находит атакующее поведение по сценариям и принимает решения о блокировке. Сами блокировки выполняют bouncer’ы — отдельные компоненты для файрвола, веб-сервера или облачного WAF. Главная фишка — коллективный блоклист: участники сообщества делятся IP атакующих, и вы блокируете их ещё до того, как они дошли до вас.

Установка с bouncer’ом для iptables:

curl -s https://packagecloud.io/install/repositories/crowdsec/crowdsec/script.deb.sh | sudo bash
apt install crowdsec crowdsec-firewall-bouncer-iptables
systemctl restart crowdsec
cscli bouncers list

Полезные команды:

cscli decisions list                 # кто сейчас заблокирован
cscli decisions delete --ip 1.2.3.4  # разблокировать
cscli alerts list                    # что сработало
cscli collections list               # какие наборы сценариев установлены

Где хорош: бесплатный, лёгкий, легко ставится на любой Linux-сервер, в том числе на инфраструктурные машины без панели. Отлично заменяет fail2ban.

BitNinja — централизованная защита с консолью

Как устроен. Агент на сервере плюс облачная консоль, из которой управляются все серверы сразу. Внутри — несколько модулей: файрвол с белыми и чёрными списками, WAF (работает как обратный прокси перед веб-сервером), антивирус, защита от брутфорса, captcha для подозрительных IP.

Главное удобство — централизованность: белый или чёрный список IP или целой страны добавляется в консоли и сразу применяется ко всем серверам.

Типовые задачи поддержки:

«Клиенту показывается captcha / сайт недоступен». Берём IP клиента, находим его в инцидентах консоли и удаляем из списка проверки. Если IP снова и снова попадает под блокировку, смотрим, какое правило WAF срабатывает, и отключаем это правило только для конкретного сайта — не весь WAF и не для всего сервера. В правилах сайтов важен порядок: правило выше в списке применяется первым.
«Антивирус удалил файлы сайта». Ложные срабатывания на файлах CMS случаются. Файлы восстанавливаются из карантина в разделе anti-malware, и после восстановления автоматически попадают в исключения.
«Работает ли WAF?» Быстрая проверка — запрос, похожий на LFI:

https://example.com/?test=/etc/passwd

Запрос должен быть заблокирован. Если страница открылась как обычно, WAF не встал перед веб-сервером — проверяем статус модуля:

bitninjacli --module=WAFManager --status

Подводные камни при установке:

BitNinja конфликтует с Imunify360 — перед установкой Imunify нужно удалить;
нужны redis и ipset;
если на сервере стоит CSF, проверьте параметр FASTSTART — от него зависит, как CSF взаимодействует с правилами BitNinja.

Imunify360 — защита для серверов с панелью

Как устроен. Комплекс для серверов с панелями (Plesk, cPanel): файрвол, WAF на базе ModSecurity, антивирус, защита от DoS, проактивная защита PHP. Интегрируется в интерфейс панели.

Конфигурация хранится в /etc/sysconfig/imunify360/imunify360.config, но править её рекомендуется через CLI:

imunify360-agent config update '{"MALWARE_SCAN_INTENSITY": {"cpu": 5}}'

Блокировка агрессивных ботов. Полезная возможность — блокировать IP, если с него повторяется срабатывание конкретного правила ModSecurity. Например, для правил, которые срабатывают на агрессивные краулеры:

imunify360-agent config update \
  '{"MOD_SEC_BLOCK_BY_CUSTOM_RULE":{"<ID_ПРАВИЛА>":{"check_period":120,"max_incidents":3}}}'

То есть если правило сработало 3 раза за 120 секунд с одного IP, IP уходит в серый список. Номера правил берутся из журнала инцидентов. Так можно прицельно закрыть ботов, которые не атакуют, но создают нагрузку.

DoS-защита настраивается лимитами соединений: общий лимит с одного IP и отдельные лимиты для портов. Пороги стоит подбирать под реальный трафик, иначе под блокировку попадут посетители за общим NAT.

Совет для поддержки: при обращении к вендору сразу прикладывайте вывод

imunify360-agent doctor

— это экономит пару кругов переписки.

Что выбрать

	CrowdSec	BitNinja	Imunify360
Модель	open source + коллективный блоклист	агент + облачная консоль	комплекс для панелей
Управление	CLI на каждом сервере	одна консоль для всех серверов	интерфейс панели и CLI
WAF	через bouncer’ы	встроенный обратный прокси	ModSecurity
Антивирус	нет	есть	есть
Где уместен	любые Linux-серверы, инфраструктура	парк серверов хостинга	серверы с Plesk/cPanel

Мои выводы:

Не ставьте несколько комплексных решений на один сервер — они конфликтуют за файрвол и веб-трафик.
Для инфраструктурных серверов (мониторинг, SIEM, внутренние сервисы) достаточно файрвола и CrowdSec.
Для парка хостинговых серверов решающим становится централизованное управление: списки и правила, применяемые ко всем серверам сразу, экономят часы в поддержке.
Любой WAF даёт ложные срабатывания на клиентских сайтах. Нужен понятный регламент: как быстро разблокировать IP и как отключить правило для одного сайта, не ослабляя защиту остальных.
События всех этих систем стоит отправлять в SIEM — тогда видно не только «кого заблокировали», но и какие атаки идут на парк в целом. Об этом — в статье «Шум в SIEM».