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

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

00c68f9e2de40aed8a1448bd591ca4f7

В этой статье вы найдете основные материалы о том, как был переделан 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

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

49d26bd4491cc3950f24a6007a274ffd

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

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

291ea26f47777e13a2c96b4da514eead

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

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

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

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

d42d4a266e8c48cfe47b038707e12b7a

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

b6e6dc969aa5a2474b17df1dba42cd36

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

ce2b0918d2efe3399ce88a2557fea863

Первые шаги в 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

…

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

b2112f90c5bf78d2c874166d9880178e

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

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

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

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

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

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

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

762ff7495a20058caadfe433281e44f5

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

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

d624f7be57a4cf5402ceb0c12e4483d5

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

2f8b2be3e0b40de26aa8707dfe22caf1

Мониторинг

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

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

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

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

fab9099ab00f4a1e08cd197cfccd5deb

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

62db608d0be023322f34c0713c9e575ac605dab9b661b509af049e03c22a9c726bbbaacac67b106a471390bcfe566d06a03fd74e2d30bdf2abd98969f223510a

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

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

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

3ebd39e3457ede6cb4fa20c8686daeeb

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

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

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

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

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

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

268c589872ca5cb1d6b658778c6662c36a19b66ca1e59b20dcb386064a01545f

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

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

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

3413edef4ca6eacdbe34ea68138a7bee

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

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

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

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

c57e249f79b4541244834596609b5477

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

15483e1cb7eae844032ed76450213220

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

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

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

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

a77fcd187844406d52c2e2ebc66a15ca

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

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

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

d0000756b2a25f44cc2e3217b5486679

Для однозначности стоит заметить, что 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. Ниже оставим полезные для вас ссылки:

© Habrahabr.ru