Всем привет! Перед Новым годом мы выпустили большой апдейт нашего продукта — CrowdSec v.1.0.X, в котором содержатся значительные изменения по сравнению с предыдущей версией. Самое главное: был введен в эксплуатацию локальный REST API и проведены соответствующие архитектурные изменения. Как следствие, значительно упростился процесс создания баунсеров и повышена их устойчивость, при этом снизилось время на обслуживание системы.

В этой статье вы найдете основные материалы о том, как был переделан CrowdSec и, в целом, ее можно рассматривать как User Guide для тех, кто собирается попробовать наш продукт на своих системах.

Все компоненты CrowdSec (агенты чтения логов, cscli и баунсеры) теперь общаются между собой через REST API, что позволяет избежать множественного чтения записей БД каждым компонентом самостоятельно. Кстати, поддерживаем мы SQLite, PostgreSQL и MySQL.

Ниже мы расскажем, как накатить CrowdSec на ваш Linux Server. Всего в материале содержится четыре этапа:

Установка CrowdSec
Тестирование
Установка баунсеров
Мониторинг

Установка окружения

Для тестовой демонстрационной инсталляции CrowdSec мы используем машину на Debian 10 buster t2.medium EC2. Для полноты картины давайте накатим на нее nginx:

Для этого теста мы используем машину Debian 10 buster t2.medium EC2.

Чтобы сделать его более актуальным, давайте начнем с установки на него nginx:

$ sudo apt-get update

$ sudo apt-get install nginx

Мы настроили группы безопасности так, чтобы на ssh (tcp / 22) и http (tcp / 80) можно было постучаться из внешнего мира. Это будет полезно при дальнейшей имитации атак при проверке системы.

Установка CrowdSec

Для начала давайте установим последнюю версию CrowdSec (ну или можете забрать ее из нашего репозитория на GitHub):

$ curl -s https://api.github.com/repos/crowdsecurity/crowdsec/releases/latest | grep browserdownloadurl| cut -d '"' -f 4  | wget -i –

$ tar xvzf crowdsec-release.tgz 

$ cd crowdsec-v1.0.0/

$ sudo ./wizard.sh -i

В первую очередь, укажем, на какой машине мы работаем и что будем мониторить

Наш мастер установки позволяет выбрать сервисы для мониторинга обычными чекбоксами. Мы будем наблюдать за стандартным набором из nginx, sshd и самой Linux-системой.

Мастер установки еще и сканирует систему на ассоциированные лог-файлы и предлагает пользователю указать их для мониторинга:

Корректно подцепить логи к системе мониторинга крайне важно, потому что именно из логов CrowdSec будет черпать основную массу информации о происходящем. Если вы все сделали правильно, то мастер установки предложит вам выбрать коллекцию.

Коллекция — это специальный набор конфигураций, который разрабатывался для различных кейсов и сценариев защиты системы и всего вашего стека. Например, коллекция Crowdsecurity/sshd используется для анализа журнала sshd и обнаружения брутфорса ssh или перебора пользователей.

После того, как службы и связанные файлы журналов будут правильно идентифицированы (что очень важно, поскольку именно отсюда CrowdSec будет получать информацию), мастер предложит коллекции.

Все коллекции основываются на нашем видении того, как и по каким направлениям стоит защищать систему (то есть никто не запрещает вам заняться ручной конфигурацией периметра, это просто костыль быстрой настройки).

Последний шаг мастера установки — развертывание общих белых списков, которые не дают банить частные IP-адреса. Это важно, потому что решение о блокировки принимает администратор системы, а не CrowdSec. Мы в этом случае просто предоставляем рекомендации.

После завершения установки CrowdSec готов к работе.

Первые шаги в CrowdSec

Итак, мы накатили CrowdSec на нашу тестовую машину и готовы потестить, как он будет защищать нас от спама, атак и прочего «шума».

Имитируем атаку на наш веб-сервер через wapiti

Для начала мы смоделируем сканирование веб-приложений на nginx через wapiti с внешнего IP-адреса.

ATTACKER$ wapiti -u http://34.248.33.108/

[*] Saving scan state, please wait…

Note

========

This scan has been saved in the file /home/admin/.wapiti/scans/34.248.33.108folderb753f4f6.db

…

Теперь посмотрим на логи нашей «атаки»:

Мы видим, что мой IP запускал разные сценарии:

- Crowdsecurity / http-path-traversal-probing: обнаружил шаблонные попытки обхода в URI или параметрах GET

- Crowdsecurity / http-sqli-probbing-detection: обнаружение очевидных попыток проверки SQL-инъекций в URI или параметрах GET

И это при условии, что мы стучались на, по сути, пустой nginx-сервер, а не на настоящий сайт. Если бы мы были реальным сайтом, то сканер бы поймал еще множество других манипуляций, которые происходят при атаке на веб-сервер.

Имейте в виду, что атакованный веб-сайт является пустым сервером nginx, сканер будет выполнять множество других действий, которые приведут к дальнейшим обнаружениям, если бы это был настоящий веб-сайт.

Проверяем результаты через cscli

Один из основных инструментов взаимодействия с системой CrowdSec является cscli. Его главная фишка — визуализация текущих решений и прошлых алертов:

Если вы используете команду cscli decisions list, вы сможете увидеть все решения, принятые за время работы системы, а вызов cscli alerts list покажет список прошлых алертов (даже если срок действия решения истек или на алерт не последовало какой-либо реакции).

Чтобы получить полную информацию по какому-либо из принятого решения, можно вызвать его лог командой cscli alerts inspect -d <ID> (ID решения отображается в левой колонке, см. скриншот выше).

сscli предлагает и другие функции, но одна интересует нас прямо сейчас. Речь о возможности посмотреть, какие именно парсеры и сценарии были установлены по умолчанию:

Мониторинг

Мониторинг — это всегда ключевой момент в построении периметра безопасности и обеспечении работы систем. И кроме классического «tail the logfile» мы предлагаем использовать еще два инструмента — metabase dashboard и метрики prometheus.

Панель мониторинга

Вездесущий cscli позволяет задеплоить нашу панель на основе metabase и docker.

Для начала рекомендуем ознакомиться с официальной документацией по установке docker.

cscli dashboard setup разворачивает новую панель мониторинга metabase на докере, генерируя попутно случайный пароль. Ну а дальше все относительно понятно и красиво:

Мониторинг: Prometheus

Если вам не по душе все эти графики, кнопки и веб-интерфейсы, и вы вообще предпочитаете работать через консоль, то для вас подойдет Prometheus вместо metabase.

Один из способов получить данные, это вызвать cscli metrics:

Важно понимать, что cscli metrics раскрывают только часть потенциала Prometheus. Более подробное описание, что же можно извлечь из показателей, вы получите (внезапно!) в официальной документации по Prometheus в CrowdSec. Если провести быстрый экскурс, то с помощью Prometheus вы можете получить информацию о следующих участках системы и метриках:

- Buckets: как много было создано и какого типа, заполнились/были переполнены с момента запуска демона;

- Acquisition: сколько строк/событий было прочитано из каждого из указанных источников, были ли они проанализированы и/или перемещены позже в корзины;

- Parser: сколько строк/событий было доставлено к каждому парсеру и удалось ли ему обработать упомянутые события;

- Local API: сколько раз был использован каждый маршрут и т. д.

Но как бы не было удобно работать в консоли через cscli, этого недостаточно. Так что рекомендуем использовать Prometheus в связке с Grafana. Вот как это выглядит на практике:

Настройка защиты: баунсеры

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

Баунсеры работают через запрос к API CrowdSec, когда им надо определиться, блокировать IP или нет. Скачать готовые конфиги можно прямо сейчас из нашего хаба на официальном сайте.

Тут мы используем cs-firewall-bouncer. Он будет напрямую запрещать любой зловредный IP на уровне брандмауэра через использование iptables или nftables. Если вам нужно разблокировать адрес, воспользуйтесь командой sudo cscli solutions delete -i X.X.X.X (где X.X.X.X — IP-адрес).

Установка баунсера

Для начала давайте установим какой-нибудь баунсер из нашего репозитория на GitHub:

$ wget https://github.com/crowdsecurity/cs-firewall-bouncer/releases/download/v0.0.5/cs-firewall-bouncer.tgz

$ tar xvzf cs-firewall-bouncer.tgz

$ cd cs-firewall-bouncer-v0.0.5/

Устанавливается он простым скриптом:

Как мы говорили ранее, баунсеры общаются с системой через REST API, так что нам надо проверить, что он зацепился за него:

Командой sudo cscli bouncers list можно проверить, установился ли баунсер.

Тестирование баунсера

Прежде чем начать, убедитесь, что у вас есть запасной IP для доступа к вашей машине и вы не забаните сами себя. Согласитесь, было бы неловко. Подойдет та же точка доступа с мобильного телефона.

Теперь, когда у нас есть баунсер, давайте попробуем кого-нибудь забанить.

Создадим попытку получить доступ к серверу в конце сканирования:

ATTACKER$ curl --connect-timeout 1 http://34.248.33.108/
curl: (28) Connection timed out after 1001 milliseconds

Теперь посмотрим, как это выглядит со стороны нашей защиты:

Для однозначности стоит заметить, что cs-firewall-bouncer использует либо nftables, либо iptables. При использовании nftables (а в debian 10 он используется по умолчанию) он создает и поддерживает две таблицы с именами Crowdsec и Crowdsec6 (для ipv4 и ipv6 соответственно).

$ sudo nft list ruleset
…
table ip crowdsec {
	set crowdsec_blocklist {
		type ipv4_addr
		elements = { 3.22.63.25, 3.214.184.223,
			     3.235.62.151, 3.236.112.98,
			     13.66.209.11, 17.58.98.156, …
                        }
	}

	chain crowdsec_chain {
		type filter hook input priority 0; policy accept;
		ip saddr @crowdsec_blocklist drop
	}
}
table ip6 crowdsec6 {
	set crowdsec6_blocklist {
		type ipv6_addr
	}

	chain crowdsec6_chain {
		type filter hook input priority 0; policy accept;
		ip6 saddr @crowdsec6_blocklist drop
	}
}

Вы можете изменить настройку брандмауэра и перейти на iptables вместо mftables, к которой обращается баунсер, по /etc/crowdsec/cs-firewall-bouncer/cs-firewall-bouncer.yaml/ Напоминаем, что для работы в режиме iptables требуется ipset.

Вы можете изменить серверную часть брандмауэра, используемую вышибалой, в /etc/crowdsec/cs-firewall-bouncer/cs-firewall-bouncer.yaml, например, изменив режим с nftables на iptables (для режима iptables требуется ipset).

Ну вот и все, наш сжатый экскурс подошел к концу. Надеемся, вы попробуете CrowdSec. Ниже оставим полезные для вас ссылки:

Скачать CrowdSec v.1.0
Наш сайт
Репозиторий проекта на GitHub
А тут у нас Gitter

Быстрый туториал по установке и эксплуатации системы фильтрации IP-адресов CrowdSec v.1.0.x