CrowdSec: коллективная защита от атак на SSH и веб

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

Как работает CrowdSec

CrowdSec — открытый агент, написанный на Go. Его логику удобно разделить на четыре слоя. Агент читает журналы: файлы вроде /var/log/auth.log, поток journald или логи контейнеров. Парсеры вытаскивают из строки IP, пользователя, порт и код ответа. Сценарии оценивают события по правилам: например, пять неудачных попыток SSH за минуту с одного адреса. Local API (LAPI) слушает на 127.0.0.1:8080, хранит решения в SQLite и отдаёт их bouncer’ам. Bouncer — небольшой демон или модуль веб-сервера, который добавляет адрес в nftables либо отвечает 403.

Решения бывают трёх видов: ban, captcha и throttle. В Central API уходят только IP, имя сценария и служебные метаданные, содержимое логов не передаётся. Коллективный обмен включён по умолчанию, но его можно выключить в config.yaml, если сервер должен оставаться полностью автономным.

Установка агента

Пакеты есть для Debian, Ubuntu, RHEL-совместимых систем и Alpine. На Debian и Ubuntu проще подключить официальный репозиторий, чем собирать вручную.

curl -s https://install.crowdsec.net | sudo sh
sudo apt update
sudo apt install crowdsec
sudo systemctl status crowdsec --no-pager
sudo cscli version

Скрипт добавляет репозиторий и ключ, после чего пакет ставится обычным apt. Служба запускается сразу и при первом старте создаёт базу и локальный API. Команда cscli работает только от root: он читает конфигурацию и базу. Если status показывает failed, смотрите journalctl -u crowdsec: чаще всего дело в занятом порту 8080.

Коллекции и сценарии

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

sudo cscli hub update
sudo cscli collections install crowdsecurity/linux
sudo cscli collections install crowdsecurity/sshd
sudo cscli collections install crowdsecurity/nginx crowdsecurity/base-http-scenarios
sudo cscli collections list

Коллекция linux добавляет базовые парсеры syslog и авторизации, sshd — сценарии перебора, nginx и base-http-scenarios — разбор веб-логов и типовые атаки вроде сканирования и подбора файлов. Если сервер пишет в journald, укажите источник journalctl: нужный парсер уже входит в коллекцию. После установки перезапустите службу и проверьте cscli metrics. Пустые значения в таблицах означают, что агент не видит лог или выбрал не тот тип источника.

Bouncer: блокировка на уровне сети

Агент только выносит решения, применяет их bouncer. Для обычного сервера без балансировщика достаточно firewall-bouncer на nftables или iptables.

sudo apt install crowdsec-firewall-bouncer-iptables
sudo cscli bouncers add firewall-bouncer
sudo systemctl enable --now crowdsec-firewall-bouncer
sudo cscli bouncers list

Команда bouncers add печатает API-ключ один раз. Скопируйте его в конфигурацию /etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml:

api_url: http://127.0.0.1:8080/
api_key: ВСТАВЬТЕ_КЛЮЧ
mode: iptables

Поле mode зависит от пакета: для nftables укажите nftables. После правки перезапустите bouncer и убедитесь, что в cscli bouncers list у записи свежий last pull. Если bouncer не может достучаться до LAPI, в journalctl -u crowdsec-firewall-bouncer будет ошибка авторизации или connection refused.

Защита веб-сервера

Веб-часть отличается обилием решений: сканеры перебирают сотни путей и легко попадают под сценарии. Создайте отдельный файл в /etc/crowdsec/acquis.d/, чтобы не править основной acquis.yaml.

source: file
filenames:
  - /var/log/nginx/access.log
  - /var/log/nginx/error.log
labels:
  type: nginx

Для journald источник выглядит иначе: source: journalctl, journalctl_filter с «_SYSTEMD_UNIT=nginx.service» и те же labels. После reload проверьте cscli metrics и отправьте в лог тестовый запрос с кавычкой и UNION в параметре. Если сценарий сработал, в cscli alerts list появится запись. Тестируйте на отдельном стенде.

Разбор решений и диагностика

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

sudo cscli explain --log "Failed password for invalid user admin from 203.0.113.10 port 51022 ssh2" --type sshd
sudo cscli alerts list --limit 10
sudo cscli decisions list
sudo cscli decisions add --ip 203.0.113.50 --duration 24h --reason "manual block"

Сверяйте поток: alerts list показывает срабатывания, decisions list — активные баны. Если алерты есть, а решений нет, проверьте, не отключён ли bouncer и не попал ли адрес в белый список. Ручное решение добавляйте, когда атака идёт с адреса, который пока не попал в сценарий, например при медленном распределённом переборе. Через сутки запись исчезнет сама.

Белый список

Ложные срабатывания чаще всего связаны с мониторингом, офисным NAT и health-check балансировщика. Исключения задаются отдельным парсером-обогатителем, а не правкой сценариев.

name: local/whitelist
description: "доверенные сети"
whitelist:
  reason: "офис и мониторинг"
  ip:
    - "198.51.100.0/24"
    - "192.0.2.15"

Файл кладётся в /etc/crowdsec/parsers/s02-enrich/, имя любое с расширением yaml. После перезапуска проверьте, что парсер загрузился: cscli parsers list и поиск по слову whitelist. Белый список отменяет не только баны, но и отправку сигналов по этим адресам. Это важно, если из офиса выходят сотни пользователей.

Чек-лист внедрения

• LAPI слушает только loopback, порт 8080 закрыт снаружи.
• Установлены коллекции под все сервисы, которые пишут логи.
• cscli metrics показывает рост разобранных строк, а не нули.
• Bouncer активен и обновляет решения без ошибок.
• Доверенные сети и мониторинг добавлены в белый список.
• Настроен алерт на резкий рост числа решений.
• Проверено, как снять ложный бан и вернуть доступ.

Итог

CrowdSec не заменяет ключи, обновления и минимальный набор служб, но закрывает разрыв между локальным логом и реальной картиной атак. Начните с коллекций sshd и nginx, поставьте firewall-bouncer, неделю наблюдайте за alerts list и только потом включайте агрессивные сценарии. Такой порядок даёт предсказуемый результат: ложные баны видны сразу, а коллективные данные начинают работать на вас, не ломая доступ.