Настройки

Базовые настройки

Сбор flow

Основная задача Collector – принять и сохранить flow с сетевых устройств.

Поддерживаемые протоколы:

  • NetFlow v5
  • NetFlow v9
  • IPFIX
  • sFlow v5

Настройки Collector указываются через переменные окружения, которые задаются в .env-файле. Подробнее.

Для получения данных по каждому протоколу нужно указать порт, на который будут приходить его пакеты, через переменные окружения:

  • COLLECTOR_NETFLOW_V5_PORT – порт, используемый для принятия пакетов протокола NetFlow v5. По умолчанию 9555.
  • COLLECTOR_NETFLOW_V9_PORT – порт, используемый для принятия пакетов протокола NetFlow v9. По умолчанию 9995.
  • COLLECTOR_IPFIX_UDP_PORT – порт, используемый для принятия пакетов протокола ipfix. По умолчанию 4739.
  • COLLECTOR_IPFIX_TCP_PORT – порт, используемый для принятия пакетов протокола ipfix. По умолчанию 4739.
  • COLLECTOR_SFLOW_PORT – порт, используемый для принятия пакетов протокола sFlow v5. По умолчанию 6343.

Настройка ClickHouse

Collector сохраняет метрики из пришедших пакетов в ClickHouse, координаты которого задаются через переменные:

  • COLLECTOR_CLICKHOUSE_ADDRESS – aдрес хоста с БД ClickHouse. По умолчанию clickhouse:9000.

Интеграция с Mitigator

Настройка Grafana

Grafana используется для отображения метрик, собранных Collector. Grafana работает на порту 3000, к которому можно подключиться через браузер.

Базовый логин/пароль: admin/admin.

При первом запуске в настройках Grafana выбрать источники данных, далее выбрать Collector. В поле URL прописать хост, на котором находится ClickHouse.

Рекомендация по URL: в базовой поставке совпадает с IP хоста или clickhouse.mitigator.

Защищенное соединение

При размещении Mitigator´а и Collector´а на разных площадках рекомендуется организовать защищенное соединение, чтобы защитить следующие данные от перехвата и подделки:

  • правила маршрутизации, которые Mitigator передает Collector´у;
  • метрики и названия интерфейсов, которые Collector отправляет на Mitigator.

Чтобы убедиться в подлинности другой стороны при соединении, Collector и подсистемы Mitigator´а предъявляют друг другу сертификаты TLS, подписанные общим корневым сертификатом, то есть используют PKI (public key infrastructure).

Для облегчения первоначальной настройки по умолчанию соединение не защищается. В целях тестирования в образах поставляется встроенная PKI. При эксплуатации необходимо создать PKI из корневого сертификата и подписанных им сертификатов подсистем.

Создание PKI

Ниже создание PKI описано кратко и для целей конкретной системы. Рекомендуется изучить подробнее понятия PKI, инструменты и лучшие практики самостоятельно.

Необходимая PKI включает следующие файлы:

  • ca.key — секретный ключ корня PKI (удостоверяющего цента, root CA). Не покидает компьютера, на котором подписываются сертификаты.

  • ca.pem — корневой сертификат. Распространяется свободно, используется всеми подсистемами.

  • Секретные ключи подсистем: collector.key, collector-backend.key, fwstats.key. Каждый ключ копируется на сервер, где работает соответствующая подсистема, и доступен только ей.

  • Цепочки сертификатов подсистем: collector.chain.pem, collector-backend.chain.pem и fwstats.chain.pem. Распространяются так же, как ключи подсистем, но не являются секретными.

Корневой сертификат

Удобно зафиксировать параметры генерации сертификата в файле ca.cnf:

[req]
ts = 4096
default_md = sha256
prompt = no
encrypt_key = no
distinguished_name = dn

[dn]
C = RU
O = Customer
OU = IT
CN = Root CA

Необходимо заполнить секцию [dn]: страну (C — country), организацию (O — organization) и подразделение в ней (OU — organizational unit). Имя условного удостоверяющего центра может быть любым (CN — common name).

Команда для генерации ключа ca.key и корневого сертификата ca.pem, срок действия — 365 дней:

openssl req -x509 -config ca.cnf -keyout ca.key -outform PEM -out ca.pem -days 365

Ключ ca.key необходимо надежно хранить в секрете. Если он будет утерян или скомпрометирован, придется генерировать PKI заново.

Сертификат Collector´а

Файл конфигурации collector.cnf аналогичен корневому сертификату, кроме Common Name. Это должен быть адрес, по которому Mitigator подключается к Collector´у.

  • Обязательно использовать Subject Alt Name (SAN), включающее Common Name.

  • Рекомендуется использовать доменное имя, чтобы при смене IP-адреса не генерировать сертификат заново. Домен не нужно регистрировать в DNS, запись можно указать при настройке контейнеров, как будет показано ниже.

[req]
ts = 4096
default_md = sha256
prompt = no
encrypt_key = no
distinguished_name = dn
req_extensions = req_ext

[dn]
C = RU
O = Customer
OU = IT
CN = collector.mitigator

[req_ext]
subjectAltName = DNS:collector.mitigator

Команда генерации секретного ключа collector.key:

openssl genrsa -out collector.key 4096

На основе collector.key и collector.cnf создается запрос на подпись сертификата collector.csr (CSR — certificate singing request):

openssl req -new -config collector.cnf -key collector.key -outform PEM -out collector.csr

Команда для для подписи сертификата collector.pem удостоверяющим центром, срок действия — 365 дней:

openssl x509 -req -in collector.csr -outform PEM -out collector.pem \
    -CA ca.pem -CAkey ca.key -CAserial ca.srl -CAcreateserial \
    -days 365 -extensions req_ext -extfile collector.cnf

Распространять требуется не просто сертификат, а цепочку collector.chain.pem из сертификата Collector´а и корневого сертификата:

cat collector.pem ca.pem > collector.chain.pem

Файл ca.srl не является секретным, но его нужно хранить вместе с ca.key для генерации новых сертификатов в будущем. Этот файл один на всю PKI.

Аналогично делаются сертификаты для бекенда коллектора.

Сертификат Mitigator´а

Процедура аналогична генерации сертификата Collector´а с тем же соображениями по поводу Common Name и Subject Alt Name. Требуется создать набор файлов для fwstats (подсистема сбора метрик).

Настройка защищенных соединений

Файлы PKI нужно скопировать к соответствующим подсистемам:

  • сервер Mitigator´а, каталог /srv/mitigator: ca.pem, fwstats.key, fwstats.chain.pem;
  • сервер Collector´а [модуль: бекенд коллектора], каталог /srv/collector ca.pem, collector-backend.key, collector-backend.chain.pem.
  • сервер Collector´а [модуль: коллектор], каталог /srv/collector ca.pem, collector.key, collector.chain.pem.

Collector

Файлы ca.pem, collector.key и collector.chain.pem нужно монтировать в контейнер через docker-compose.override.yml:

Аналогично для бекенда коллектора.

version: "2.2"
services:
  collector-backend:
    volumes:
    - ./ca.pem:/app/tls/rootCA.pem:ro
    - ./collector.key:/app/tls/collector-backend.key:ro
    - ./collector.chain.pem:/app/tls/collector-backend.chain.pem:ro
  collector:
    volumes:
    - ./ca.pem:/collector/certs/rootCA.pem:ro
    - ./collector.key:/collector/certs/collector.key:ro
    - ./collector.chain.pem:/collector/certs/chain.pem:ro

После внесения изменений нужно перезапустить Collector:

docker-compose up -d collector

Подсистемы Mitigator´а

Файлы монтируются через docker-compose.override.yml аналогично тому, как это делается для Collector´а:

version: "2.2"
services:
  fwstats:
    volumes:
    - ./ca.pem:/fwstats/certs/ca.pem:ro
    - ./fwstats.key:/fwstats/certs/fwstats.key:ro
    - ./fwstats.chain.pem:/fwstats/certs/fwstats.chain.pem:ro

В отличие от Collector´а, подсистемы Mitigator´а по умолчанию не используют защищенное соединение, поэтому необходимо указать им использовать файлы PKI через .env:

FWSTATS_ROOT_CERT_PATH="/fwstats/certs/ca.pem"
FWSTATS_PRIVATE_KEY_PATH="/fwstats/certs/fwstats.key"
FWSTATS_CLIENT_CERT_CHAIN_PATH="/fwstats/certs/fwstats.chain.pem"

После внесения изменений нужно перезапустить Mitigator:

systemctl reload mitigator

Доменные имена (необязательно)

В сертификатах удобно использовать доменные имена, например, collector.mitigator. При этом DNS может не быть настроено, в этом случае можно прописать адреса через docker-compose.override.yml:

version: "2.1"
services:
  fwstats:
    extra_hosts:
    # Отдельной строкой для каждого коллектора:
    - "collector.mitigator:192.0.2.10"
    - "collector-backend.mitigator:192.0.2.10"

После внесения изменений необходимо перезапустить fwstats:

docker-compose up -d fwstats

Troubleshooting

Ошибки, связанные с PKI, отражаются в логах подсистем, например:

docker-compose logs -f collector
docker-compose logs -f collector-backend

В fwstats в режиме дебага:

docker-compose logs -f fwstats | grep collector