Если вы привыкли к классической связке «лог-фильтр + firewall» для SSH и веба, то CrowdSec — это следующий шаг. Он анализирует логи, использует поведенческие сценарии и коллективную репутацию источников атак, а затем применяет решения (ban, captcha/throttle для HTTP) через «bouncers». В итоге безопасность на VDS перестает зависеть от ручных regex и устаревших шаблонов: система развивается вместе с атакующей экосистемой.
Что такое CrowdSec и чем он отличается от fail2ban
Идеология CrowdSec — не просто искать повторяющиеся ошибки аутентификации, а оценивать поведение. Для SSH это распознавание bruteforce через поддерживаемые сценарии. Для веба — обнаружение сканеров, парсеров, грубых переборов форм и других подозрительных паттернов. Главное отличие от классических инструментов вроде fail2ban — централизованный «хаб» сценариев, автоматические обновления и механизм обмена репутацией IP (бан по репутации). В результате вы получаете удобную альтернативу, которая проще поддерживается и лучше масштабируется.
Архитектура: агент читает логи и выносит решения, а «bouncer» их применяет — в firewall (nftables/iptables), на уровне Nginx (nginx bouncer), в приложении или на внешнем уровне. Управление — через консольный инструмент cscli.
Архитектура на практике
Роли компонентов простые:
- Агент CrowdSec анализирует логи (SSH, Nginx, почта, БД, системные), держит локальный API (LAPI), хранит парсеры/сценарии и отдает решения.
- Bouncers применяют решения: firewall-блокировщик добавляет IP в наборы nftables/iptables, а nginx bouncer может возвращать бан/капчу/троттлинг в реальном времени.
- Hub/репутация: можно включить подписку на community blocklist, чтобы заранее отсекать регулярно замеченные в атаках адреса.
Целевой план для VDS
Настроим связку: анализ логов SSH и Nginx, принятие решений агентом, мгновенные блокировки на уровне firewall для SSH bruteforce и поведенческую защиту HTTP (через детектирование по access.log). При желании позже добавим nginx bouncer, чтобы выдавать капчу/бан-страницы без ожидания firewall-триггера.
Предпосылки
- Linux на VDS (Debian/Ubuntu или RHEL-класс).
- Nginx с access.log и error.log (по умолчанию — /var/log/nginx/access.log).
- SSH пишет в journald или /var/log/auth.log.
- Права root/sudo.
Если вы управляете сервером через панель, посмотрите свежий обзор, чтобы понимать ограничения и интеграции: панели управления для VDS в 2025.
Установка CrowdSec
На большинстве систем достаточно поставить агент из официального репозитория. Быстрый способ — установщик, который сам добавит репозиторий и ключи. После установки появятся бинарь cscli, служба crowdsec и дефолтная конфигурация.
curl -s https://install.crowdsec.net | sudo bash
sudo apt-get update
sudo apt-get install crowdsec
Для RHEL/AlmaLinux/Rocky используйте менеджер пакетов дистрибутива:
curl -s https://install.crowdsec.net | sudo bash
sudo dnf install crowdsec
Запускаем и добавляем в автозапуск:
sudo systemctl enable --now crowdsec
Проверяем статус и метрики:
sudo systemctl status crowdsec
sudo cscli metrics
Подключение логов: SSH и Nginx
По умолчанию агент на Debian/Ubuntu уже читает системные журналы и распознает попытки входа по SSH. Убедитесь, что journalctl показывает события авторизации.
Для Nginx создадим файл в acquis.d, указав путь к access.log и тип источника. Это подключит стандартные парсеры HTTP.
sudo mkdir -p /etc/crowdsec/acquis.d
sudo tee /etc/crowdsec/acquis.d/nginx.yaml > /dev/null <<'EOF'
filenames:
- /var/log/nginx/access.log
labels:
type: nginx
EOF
sudo systemctl restart crowdsec
sudo cscli metrics
Важно: если перед вашим Nginx стоит обратный прокси или CDN, включите восстановление реального адреса клиента (real_ip в Nginx). Иначе в логах вместо IP атакующего окажется адрес прокси, и firewall может заблокировать не того. Сначала исправляем real_ip, потом включаем детектирование.
Сценарии и коллекции: что включить
Обновим хаб и добавим наиболее полезные коллекции под SSH и HTTP. Коллекции — это наборы парсеров и сценариев.
sudo cscli hub update
sudo cscli collections install crowdsecurity/linux
sudo cscli collections install crowdsecurity/ssh
sudo cscli collections install crowdsecurity/nginx
sudo cscli collections install crowdsecurity/http-cve
sudo cscli collections install crowdsecurity/community-blocklist
sudo systemctl restart crowdsec
sudo cscli hub list | grep -E 'ssh|nginx|http|community'
С этого момента агент начнет распознавать типовые веб- и SSH-атаки, а также применять бан по репутации из community-blocklist. Продолжительность и тип решений управляются профилями.
Профили решений (profiles.yaml)
Файл профилей определяет, какое решение выносится и на какой срок, исходя из уровня доверия и гравитации поведения. Например: SSH bruteforce — ban на 4 часа; агрессивный сканер HTTP — ban на 1 час; для слабых индикаторов — мягче. Проверьте и при необходимости подправьте дефолтный профиль под свои требования.
Firewall-блокировщик: мгновенные баны для SSH и HTTP
Для остановки bruteforce и шумных сканеров лучше всего подходит firewall-bouncer: он хранит актуальные IP-решения в наборах nftables/iptables и блокирует трафик до прикладного уровня.
sudo apt-get install crowdsec-firewall-bouncer-nftables
# Если nftables недоступен, установите bouncer для iptables
# sudo apt-get install crowdsec-firewall-bouncer-iptables
sudo systemctl enable --now crowdsec-firewall-bouncer
sudo systemctl status crowdsec-firewall-bouncer
Проверим, что санкции применяются. Внесем тестовый бан и посмотрим, как он попал в наборы firewall:
sudo cscli decisions add --ip 203.0.113.10 --duration 4h --reason test-block
sudo cscli decisions list
sudo nft list ruleset | grep -i crowdsec
После установки firewall-блокировщика SSH-брюты будут отстреливаться автоматически. Как только агент распознает шаблон bruteforce по логам SSH, IP попадет в сет блокировок и будет отрезан до истечения TTL решения. Это же касается и HTTP-источников при нарушении сценариев веб-коллекций.
Nginx bouncer: поведенческий антибот на уровне HTTP
Firewall отлично режет злонамеренные источники, но HTTP-уровень дает дополнительные опции: показать капчу или замедлить трафик до «жесткого» бана. Для этого используется nginx bouncer, который общается с локальным API агента и на каждый запрос определяет: обычный ответ, капчу или запрет.
- Установите nginx-bouncer из репозитория CrowdSec.
- Сгенерируйте API-ключ: sudo cscli bouncers add nginx-bouncer.
- Пропишите ключ и адрес LAPI в конфиге bouncer; подключите сниппет в Nginx для нужных локаций.
- Перезагрузите Nginx и проверьте журналы bouncer и access.log.
Начните с защиты «чувствительных» локаций (панели админок, формы логина, API-эндпойнты) и отладочного режима, чтобы убедиться, что легитимный трафик не страдает.
Выбор между firewall-блокировщиком и nginx bouncer
- SSH — всегда firewall. Это быстрее и надежнее.
- Публичный HTTP без интерактива — firewall плюс детектирование на основе логов.
- Нужны капчи/тонкая логика по путям/методам — добавляйте nginx bouncer поверх.
Проверка работы: быстрые тесты
SSH: несколько раз ошибитесь паролем по SSH с внешнего IP и наблюдайте за решениями.
ssh user@your-vds.example
# Несколько неправильных попыток
sudo cscli decisions list
sudo journalctl -u crowdsec -n 100 --no-pager
Nginx: сгенерируйте аномально высокую частоту запросов к одной локации или имитируйте «вредные» пути. Проверьте, появился ли IP в решениях и применился ли бан.
ab -n 1000 -c 50 https://site.example/
sudo cscli decisions list
sudo tail -n 100 /var/log/nginx/access.log
Тонкая настройка: whitelists, профили и исключения
Whitelists нужны, чтобы не банить офисные сети, мониторинговые узлы и доверенные бэкенды. На практике полезно иметь два уровня:
- Белые адреса на уровне Nginx/сервера (allow для служебных сетей, запрет остальным на критичные локации).
- Белые адреса внутри CrowdSec (исключения для источников, которые не нужно анализировать, или для которых решения не должны выноситься).
Профили решений позволяют варьировать длительность банов, в том числе в зависимости от повторности нарушений. Например, первый инцидент — 30 минут, повтор в течение суток — 12 часов. Сценарии и коллекции регулярно обновляются, поэтому разумно раз в неделю делать обновление хаба.
sudo cscli hub update
sudo cscli upgrade
sudo cscli hub list -a
Работа за обратным прокси/CDN
Это частая причина ложных банов. Прежде чем включать детектирование по access.log, убедитесь, что в логе пишется реальный клиентский IP. Для этого настройте real_ip в Nginx под ваш CDN/прокси и проверьте, что в access.log виден ваш настоящий адрес, а не IP CDN. Только после этого подключайте acquis для Nginx и сценарии HTTP.
Если вы сначала включили CrowdSec, а потом real_ip, агент мог временно забанить адреса прокси. Восстановить доступ поможет удаление решений и очистка наборов firewall.
sudo cscli decisions delete --all
sudo systemctl restart crowdsec-firewall-bouncer
При переходе на HTTPS и ужесточении политики HSTS дополнительно пригодится чек-лист: перенос сайта на новый домен без потери SEO: 301 редиректы, HSTS и SSL.
Наблюдаемость и аудит
Команды для повседневной диагностики:
- Список инцидентов и решений: cscli alerts list, cscli decisions list.
- Статус парсеров/сценариев: cscli metrics.
- Версии и обновления: cscli hub update, cscli upgrade.
- Отладка источников логов: временно включайте повышенную детализацию логирования в конфиге CrowdSec и смотрите journalctl.
Безопасные практики эксплуатации
- Синхронизируйте время (chrony/systemd-timesyncd), иначе TTL решений будет работать непредсказуемо.
- Следите за логротейтом: access.log и auth.log должны ротироваться без потери чтения. При смене inode перезапускайте агент, если логридер не подхватил новый файл.
- Периодически обновляйте хаб и сам софт, так как сценарии быстро эволюционируют.
- Не включайте слишком агрессивные сценарии на старте. Начните с дефолтных SSH и базовых HTTP и постепенно расширяйте.
- Храните ключи bouncer в отдельных файлах с ограниченными правами и не допускайте их утечки.
Сравнение с классическими подходами
В роли защиты от bruteforce SSH и простого веб-шумоподавления CrowdSec работает похоже на fail2ban, но выигрывает за счет централизованного хаба, стандартизированных сценариев и механизма репутации. Для HTTP у него есть плюс — интеграции уровня приложения (nginx bouncer), где можно не только банить, но и предъявлять капчу/замедлять. Это делает набор инструментов гибким для публичных сервисов и API.
Чек-лист внедрения на VDS
- Установить агент CrowdSec, запустить и проверить метрики.
- Подключить источники логов SSH и Nginx через acquis.d.
- Включить коллекции: linux, ssh, nginx, community-blocklist.
- Поставить firewall-bouncer (по возможности nftables).
- Проверить бан: тестовый decision и наборы firewall.
- Настроить real_ip, если есть прокси/CDN, и только потом включать HTTP-сценарии.
- Опционально: внедрить nginx bouncer для капчи/троттлинга.
- Настроить whitelists для доверенных сетей и мониторинга.
- Включить регулярные обновления хаба и мониторинг журнала CrowdSec.
Итоги
CrowdSec закрывает две важные задачи на VDS: мгновенная и автоматическая ssh защита от переборов паролей с помощью firewall-блокировщика и поведенческий антибот для веба (через HTTP-детектирование и при необходимости nginx bouncer). Добавьте к этому бан по репутации, регулярные обновления сценариев и стандартизованный cscli — и вы получите «щит», который работает не только по шаблонам, но и по реальной динамике злоумышленников. Начните с базовой схемы, аккуратно включайте дополнительные сценарии и не забывайте про whitelists и real_ip — такой подход дает максимальный эффект без ложных срабатываний.
