Настройки

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

Сбор flow

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

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

  • NetFlow v5
  • NetFlow v9
  • sFlow v5

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

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

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

Настройка ClickHouse

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

  • COLLECTOR_CLICKHOUSE – aдрес хоста с БД ClickHouse. По умолчанию clickhouse.
  • COLLECTOR_CLICKHOUSE_PORT – порт, на который будут пересылаться метрики. По умолчанию 9000.

Интеграция с 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, backend.key, fwstats.key. Каждый ключ копируется на сервер, где работает соответствующая подсистема и доступен только ей.

  • Цепочки сертификатов подсистем: collector.chain.pem, 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´у. Рекомендуется использовать доменное имя, чтобы при смене IP-адреса не генерировать сертификат заново, но обычный IP-адрес также подходит. Домен не обязательно регистрировать в DNS, запись можно указать при настройке контейнеров, как будет показано ниже.

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

[dn]
C = RU
O = Customer
OU = IT
CN = 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 -CA ca.pem -CAkey ca.key -CAserial ca.srl -CAcreateserial -outform PEM -out collector.pem -days 365

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

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

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

Сертификаты подсистем Mitigator´а

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

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

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

  • сервер Mitigator´а, каталог /srv/mitigator: ca.pem, backend.key, backend.chain.pem, fwstats.key, fwstats.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:
    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:
  backend:
    volumes:
    - ./ca.pem:/backend/certs/ca.pem:ro
    - ./backend.key:/backend/certs/backend.key:ro
    - ./backend.chain.pem:/backend/certs/backend.chain.pem:ro
  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:

BACKEND_ROOT_CERT_PATH="/backend/certs/ca.pem"
BACKEND_PRIVATE_KEY_PATH="/backend/certs/backend.key"
BACKEND_CLIENT_CERT_CHAIN_PATH="/backend/certs/backend.chain.pem"

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:
  backend:
    extra_hosts:
    - "collector.mitigator:192.0.2.10"
  fwstats:
    extra_hosts:
    - "collector.mitigator:192.0.2.10"

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

Troubleshooting

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

docker-compose logs -f collector