Установка BIFIT Mitigator

Системные требования

Поддерживается как физические, так и виртуальные машины (KVM, VMWare).

Поддержка

1. Виртуальная машина

Образ подходит для VirtualBox, VMWare ESXi 6.5 и выше.

  1. Скачать OVA-файл.

  2. Импортировать OVA:

    • VMWare ESXi: Virtual Machines → Create/Register VM → Deploy a virtual machine from an OVF or OVA file
    • VirtualBox: File → Import Appliance
  3. Выбрать сети:

    • Management network — сеть управления;
    • External network — внешняя сеть с клиентами и атакующими;
    • Internal network — внутренняя сеть с защищаемыми ресурсами.
  4. После первого запуска и при обновлении (учетная запись: root:mitigator):

    • Только при обновлении:

      • перейти в рабочий каталог:
        cd /srv/mitigator
      • скачать актуальный Compose-файл:
        wget https://docs.mitigator.ru/dist/docker-compose.yml
      • скачать базовый файл переменных:
        wget https://docs.mitigator.ru/dist/env -O /srv/mitigator/.env
    • docker login docker.mitigator.ru

    • systemctl restart mitigator

    Подробней о назначении файлов можно почитать в инструкции по ручной установке.

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

2. Ansible

Playbook работает для Debian 9+, Ubuntu 16.04+, CentOS 7.2+. Необходим доступ от целевой машины к репозитариям дистрибутива.

1. Установить Ansible (пример для Debian/Ubuntu):

sudo apt-get --yes install ansible tar wget

2. Установить Docker и Docker-Compose:

Следуя официальной документации по установке для вашей ОС:

Если в системе отсутствует /etc/docker/daemon.json, будет установлен следующий:

{
    "log-driver": "json-file",
    "log-opts": {
      "max-size": "50m",
      "max-file": "2"
    }
}

Существующий файл изменен не будет, в этом случае следует совместить конфигурации вручную.

3. Скачать и распаковать необходимые файлы:

wget https://docs.mitigator.ru/ansible/mitigator.tar -O- | tar -x
wget https://docs.mitigator.ru/ansible/config.yml -O mitigator/config.yml

4. Отредактировать mitigator/config.yml (параметры по умолчанию годятся для минимальной конфигурации):

---
mitigator_arch: "nehalem"
mitigator_nic_driver: vfio-pci
mitigator_nics:
- 0b:00.0
- 13:00.0
mitigator_nr_addrs: 131072
mitigator_hugepage_size: "2M"
mitigator_hugepage_nr: 1536
mitigator_nr_policies: 100

#mitigator_version: latest

mitigator_registry_user: guest
mitigator_registry_pass: mitigator
mitigator_pull_images: y

#mitigator_http_proxy: ""
#mitigator_https_proxy: ""
#mitigator_no_proxy: ""

5. Развернуть MITIGATOR на целевую машину mitigator.local, куда есть доступ по SSH:

ansible-playbook --become --ask-become-pass \
    -i mitigator.local, mitigator/mitigator.yml

Запятая после имени хоста — не опечатка. Если имя пользователя SSH отличается от локального, например, login, добавляется параметр -u login.

--become и --ask-become-pass используются для повышения привилегий, когда подключение осуществляется не напрямую через пользователя root (необходимо для выполнения части задач в процессе инсталяции).

В конце установки машина перезагрузится.

Playbook безопасно исполнять повторно в случае проблем.

Дополнение

1. Задания в роли ансибла разделены на 4 «тега»: checks, system, hugepages, mitigator.

Задания под тегом, соответственно, предназначены для проверки конфигурации, настройки системы, настройки hugepages и настройки непосредственно MITIGATOR. При необходимости перезапустить роль и перенастроить установку только частично, можно запустить playbook с необходимым набором тегов, например:

ansible-playbook --become --ask-become-pass \
    --tags "system,hugepages" \
    -i mitigator.local, mitigator/mitigator.yml

2. Конфигурацию GRUB2 под UEFI на RHEL/CentOS необходимо дополнительно перегенерировать вручную:

grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg

Для CentOS redhat заменить на centos

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

3. MITIGATOR в режиме кластера

В режиме кластера несколько экземпляров системы MITIGATOR пользуются едиными базами данных и управляются централизованно. За счет добавления дополнительных экземпляров система допускает неограниченное масштабирование. Режим кластера позволяет обрабатывать трафик независимо на каждом экземпляре, но управлять ими из единого интерфейса. При плановом или аварийном отключении любого экземпляра сохраняется возможность управления остальными.

Развертывание

Между экземплярами настраивается виртуальная сеть (VPN) Для ее работы нужна сетевая связность между экземплярами. Подробные сведения по настройке и необходимым доступам описаны по ссылке.

Существует несколько принципиальных схем внедрения.

Управление через web-интерфейс

Основным изменением в интерфейсе MITIGATOR при переходе на режим кластера стало разделение некоторых настроек на относящиеся к системе в целом и для конкретных экземпляров.

Вкладка «Система»

На вкладке «Экземпляры» пользователю доступен список всех экземпляров системы. Для каждого из них отображается текущий статус активности. Переключателями централизованно изменяется состояние экземпляра. Нажатие на название экземпляра переводит пользователя на страницу настройки экземпляра. Если в системе создан только один экземпляр, то при нажатии на пункт меню «Экземпляры» пользователь сразу попадет на страницу настройки экземпляра.

Страница «Экземпляры»

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

Страница «Экземпляр»

Разделы «Интеграция в сеть» и «GRE-туннель со сторонним сервисом» теперь также находятся на вкладке «Экземпляры», так как для корректной работы системы следует задать параметры внедрения в сеть для каждого экземпляра.

Mitigator позволяет использовать агрегацию каналов (LAG) между устройствами во внешней и внутренней сети. Настройки интеграции в сеть влияют на то, какие варианты агрегации каналов могут использоваться:

Mitigator позволяет балансировать нагрузку между несколькими экземплярами системы по ECMP за счет анонсирования по BGP каждым экземпляром одинаковых префиксов. Когда один из экземпляров отключается, анонс снимается и трафик автоматически распределяется между оставшимися экземплярами.

Карточка «Лицензия» разделена на две. В настройках системы задается значение лицензионного ключа, а в настройках экземпляра находятся элементы управления лицензированной полосой и сервисная информация.

В верхней панели интерфейса находится выпадающий список, позволяющий выбрать экземпляр, для которого в системе будут показываться графики. Также возможно отображение суммарно для всех экземпляров, если выбрано значение «Все экземпляры».

Выбор экземпляра для показа графиков

3.1. Сеть между экземплярами

Принцип работы

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

Взаимодействие между экземплярами устроено через Wireguard. Между экземплярами создается виртуальная сеть (VPN).

Каждый экземпляр имеет ключевую пару: приватный ключ и публичный ключ. Приватный ключ хранится только на своем экземпляре в vpn-private.conf. Публичные ключи всех экземпляров перечислены в vpn-public.conf, который должен быть одинаков на всех экземплярах. В нем же указаны адреса экземпляров и их адреса в VPN.

Адрес экземпляра в VPN также указывается как MITIGATOR_VPN_ADDRESS в .env.

За организацию VPN отвечает компонент gateway. Когда кластеризация не применяется, он не создает VPN. При кластеризации он настраивает VPN в соответствии с vpn-private.conf, vpn-public.conf, MITIGATOR_VPN_ADDRESS.

Если нужно поменять настройки gateway, кроме *.conf, нужно полностью перезапустить экземпляр (docker-compose down && docker-compose up -d).

Специальную команду для обновления конфигурации VPN см. ниже.

Подготовка системы

Модуль ядра

Ubuntu 20.04 LTS включает Wireguard в базовой поставке. Дополнительные действия не нужны.

В Debian 10 (Buster) требуется установить портированный пакет:

echo deb http://deb.debian.org/debian buster-backports main > /etc/apt/sources.list.d/buster-backports.list
apt-get update
apt-get install linux-headers-amd64 wireguard-dkms

Проверить поддержку можно командной modprobe wireguard. Если ничего не печатается в ответ, модуль доступен. В этом случае достаточно настроить его автоматическую загрузку. Иначе требуется перезагрузка.

Для добавления wireguard в автоматическую загрузку:

echo wireguard >> /etc/modules

Инструменты

Установить утилиту wg:

apt-get install wireguard-tools

Настройка экземпляра

Все файлы создаются в каталоге /srv/mitigator.

Если настраивается не первый экземпляр, файл vpn-public.conf нужно взять с любого из настроенных экземпляров, чтобы дополнять его.

  1. Создать приватный ключ (пример результата: yDPg5doavYH7fdD86nt+cOzSBL4znVZcrcrJwjY/Xmw=):

    wg genkey
    
  2. Записать ключ в vpn-private.conf:

    [Interface]
    ListenPort = 4567
    PrivateKey = yDPg5doavYH7fdD86nt+cOzSBL4znVZcrcrJwjY/Xmw=
    

    Указанный порт 4567 должен быть открыт для UDP-трафика.

  3. Получить из приватного ключа публичный (пример результата: acfzxE6ZsiYE4jIqsBicOt7oT8ZuKhxBvuz0+6JxiEc=):

    echo 'yDPg5doavYH7fdD86nt+cOzSBL4znVZcrcrJwjY/Xmw=' | wg pubkey
    
  4. Добавить в vpn-public.conf секцию с публичным ключом и адресами экземпляра (создать файл, если это первый экземпляр):

    [Peer]
    PublicKey = acfzxE6ZsiYE4jIqsBicOt7oT8ZuKhxBvuz0+6JxiEc=
    AllowedIPs = 10.8.3.1/32
    Endpoint = 192.0.2.1:4567
    

    10.8.3.1 — адрес экземпляра внутри VPN. Должен быть уникальным среди всех экземпляров. Все адреса должны быть внутри одной сети /24 (по умолчанию).

    192.0.2.1:4567 — внешний адрес экземпляра и настроенный выше порт. На этот адрес и порт другие экземпляры будут отправлять UDP-пакеты.

  5. Создать файл docker-compose.vpn.yml в точности такого содержания:

    version: "2.2"
    services:
      gateway:
        environment:
          GATEWAY_ADDRESS: "${MITIGATOR_VPN_ADDRESS:-10.8.3.1}/${MITIGATOR_VPN_PREFIX:-24}"
        volumes:
        - ./vpn-public.conf:/srv/public.conf:ro
        - ./vpn-private.conf:/srv/private.conf:ro
    
  6. Добавить этот файл в список конфигураций Docker Compose в .env:

    COMPOSE_FILE=docker-compose.yml:docker-compose.vpn.yml
    

    Если используется больше файлов, например, docker-compose.override.yml, их все нужно перечислить через двоеточия.

  7. Добавить в .env адрес экземпляра внутри VPN:

    MITIGATOR_VPN_ADDRESS=10.8.3.1
    

    Он должен совпадать с настроенным в vpn-public.conf. Также этот адрес должен быть указан в настройках экземпляра в web-интерфейсе MITIGATOR.

  8. Перезапустить MITIGATOR:

    docker-compose down && docker-compose up -d
    

Настройка кластера после добавления экземпляра

После добавления нового экземпляра в файл vpn-public.conf нужно внести изменения на всех экземплярах.

На каждом экземпляре нужно обновить конфигурацию VPN без перезапуска:

docker-compose exec gateway reconfigure

3.2. Общее нерезервированное хранилище

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

Перед настройкой кластера необходимо настроить виртуальную сеть (VPN). Для ее работы нужна сетевая связность между экземплярами. Подробные сведения по настройке и необходимым доступам описаны по ссылке.

Общие базы данных для всех экземпляров MITIGATOR физически хранятся на сервере одного из них. К базовому экземпляру должны быть разрешены подключения с остальных экземпляров по следующим портам TCP: 8888, 2003, 3080, 5432.

Общее нерезервированное хранилище

Если кластер собирается из экземпляров MITIGATOR, которые ранее уже работали независимо, то в ходе интеграции могут возникнуть конфликты. Поэтому на всех экземплярах кроме будущего лидера необходимо выполнить команду:

docker-compose down -v
При выполнении данной команды будут удалены настройки контрмер, журнал событий, графики и другая информация, хранимая в базах данных этих экземпляров. Если данные нужно сохранить, следует предварительно сделать резервную копию.

Установка базового экземпляра выполняется по шагам, описанным в разделе «Установка».

Остальные экземпляры MITIGATOR должны обращаться к БД базового экземпляра и поэтому сначала для них необходимо также выполнить стандартную установку. После установки, но перед запуском, необходимо:

  1. Скачать docker-compose.worker.yml:

    wget https://docs.mitigator.ru/dist/multi/docker-compose.worker.yml \
        -O docker-compose.worker.yml
    
  2. В файле .env задать переменную COMPOSE_FILE так:

    COMPOSE_FILE=docker-compose.yml:docker-compose.worker.yml
    

    Если требуются дополнительные настройки, например, при использовании карт Mellanox, поместить их в docker-compose.override.yml и добавить его в список:

    COMPOSE_FILE=docker-compose.yml:docker-compose.override.yml:docker-compose.worker.yml
    
  3. В файле .env задать переменную MITIGATOR_STORAGE_HOST=192.0.2.1. Здесь 192.0.2.1 – адрес базового экземпляра.

  4. В файле .env задать переменную MITIGATOR_OWN_NAME=mitigator-1. Здесь mitigator-1 – имя экземпляра. Имя каждого экземпляра должно быть уникально.

  5. В файле .env задать переменную MITIGATOR_HOST_ADDRESS=192.0.2.1. Здесь 192.0.2.1 – адрес хоста для данного экземпляра.

3.3. Внутреннее отказоустойчивое хранилище

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

Перед настройкой кластера необходимо настроить виртуальную сеть (VPN). Для ее работы нужна сетевая связность между экземплярами. Подробные сведения по настройке и необходимым доступам описаны по ссылке.

В целях отказоустойчивости синхронизированные копии БД должны физически храниться на разных серверах (реплицироваться). При данной схеме реплики БД хранятся на тех же серверах, где работают экземпляры MITIGATOR. Это позволяет сэкономить ресурсы и не требует знаний по настройке PostgreSQL.

Внутреннее отказоустойчивое хранилище

Если кластер собирается из экземпляров MITIGATOR, которые ранее уже работали независимо, то в ходе интеграции могут возникнуть конфликты. Поэтому на всех экземплярах кроме будущего лидера необходимо выполнить команду:

docker-compose down -v
При выполнении данной команды будут удалены настройки контрмер, журнал событий, графики и другая информация, хранимая в базах данных этих экземпляров. Если данные нужно сохранить, следует предварительно сделать резервную копию.

Экземпляры PostgreSQL работают в схеме потоковой репликации active — hot standby. Вместо подключения к PostgreSQL напрямую каждый Mitigator подключается к локальной работающий программе pgfailover, которая перенаправляет подключения к PostgreSQL-лидеру репликации.

Отказоустойчивая БД на двух узлах

Если лидер недоступен, pgfailover делает лидером одну из ведомых реплик в заданной очередности. MITIGATOR-лидер кластера и PostgreSQL-лидер репликации не обязаны совпадать.

Предполагается, что между узлами надежная связь. Если группа экземпляров окажется отрезана от лидера репликации, среди них будет выбран новый лидер (split-brain). После восстановления связи придется вручную удалить данные на отрезанной части экземпляров и заново ввести их в кластер.

Метрики для графиков пишутся MITIGATOR-лидером на все экземпляры для сохранности. Это задается списком серверов FWSTATS_GRAPHITE_ADDRESS.

Настройка

Процесс настройки описан для двух экземпляров и одинаков на всех экземплярах, кроме конкретных значений MITIGATOR_OWN_INDEX. Для большего количества экземпляров нужно расширить по аналогии списки серверов pgfailover и FWSTATS_GRAPHITE_ADDRESS.

  1. В файле .env задать переменную MITIGATOR_HOST_ADDRESS=192.0.2.1. Здесь 192.0.2.1 – адрес хоста для данного экземпляра.

  2. В файле .env задать переменную MITIGATOR_OWN_INDEX=0. Здесь 0 – идентификатор очередности данного экземпляра стать Active-сервером PostgreSQL. Должен быть уникальным и последовательно возрастающим на каждом экземпляре.

  3. В файле .env задать переменные SERVER1=10.8.3.1 и SERVER2=10.8.3.2. Здесь 10.8.3.1 и 10.8.3.2– адреса серверов внутри VPN, на которых запущены экземпляры. Также эти адреса должны быть указаны в настройках экземпляров в web-интерфейсе MITIGATOR.

    Если используются адаптеры Mellanox, вместо адресов серверов внутри VPN следует

указывать реальные адреса экземпляров.

  1. Создать docker-compose.failover.yml на базе шаблона:

    wget https://docs.mitigator.ru/dist/multi/docker-compose.failover.yml
    

    Редактирование нужно, если используется больше двух экземпляров. Расширение делается по аналогии с двумя имеющимися в шаблоне.

  2. В файле .env задать переменную COMPOSE_FILE так:

    COMPOSE_FILE=docker-compose.yml:docker-compose.failover.yml
    

Использование

Если произойдет разрыв соединения с экземпляром-лидером (базы в режиме Active), экземпляр с базами в режиме Standby занимает его место и становится лидером. Механизма переключения баз бывшего лидера в режим Standby не предусмотрено штатной репликацией PostgreSQL. Для схемы из двух баз данных это означает прекращение репликации на другой сервер до ручной перенастройки схемы.

Восстановление Standby из Active

Для переключения бывшего Active и возвращения его в схему репликации необходимо остановить сервис PostgreSQL, а также удалить локальные данные базы.

  1. Остановка сервиса PostgreSQL:

    docker-compose rm -fsv postgres

  2. Удаление локальных данных базы:

    docker volume rm mitigator_postgres

  3. Инициализация Standby аналогично первой инициализации:

    docker-compose run -e PGPORT=15432 postgres standby

    после чего запускается как обычно:

    docker-compose up -d

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

В случае split brain в каждой изолированной части кластера будет выбран свой лидер репликации, то есть кластер распадется на несколько меньших (возможно, из единственной машины).

После восстановления связности pgfailover всех меньших кластеров обнаружат, что есть несколько серверов PostgreSQL, работающих как лидеры репликации. В каждом из кластеров сработает оповещение об этой ситуации, будет создано событие журнала «Возник конфликт лидерства экземпляров».

В логах каждого бэкенда-лидера (docker-compose logs backend) будет сообщение такого вида:

time="2021-03-03T19:32:47+03:00" level=error msg=multi-conflict data="{\"primary\":0,\"rivals\":[1],\"sender\":0}" hook=on-multi-conflict

В поле data:

Необходимо проанализировать такие записи в логах всех экземпляров, выбрать, какой будет лидером, а остальные сделать standby.

3.4. Внешнее отказоустойчивое хранилище

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

Перед настройкой кластера необходимо настроить виртуальную сеть (VPN). Для ее работы нужна сетевая связность между экземплярами. Подробные сведения по настройке и необходимым доступам описаны по ссылке.

Данная схема внедрения подразумевает физическое хранение общих для всех экземпляров MITIGATOR баз данных на внешнем сервере. Работоспособность и отказоустойчивость всех СУБД обеспечивается силами администратора внешнего сервера под конкретные требования.

Внешнее отказоустойчивое хранилище

Все экземпляры разворачиваются как worker´ы (см. выше).

Если кластер собирается из экземпляров MITIGATOR, которые ранее уже работали независимо, то в ходе интеграции могут возникнуть конфликты. Поэтому на всех экземплярах кроме будущего лидера необходимо выполнить команду:

docker-compose down -v
При выполнении данной команды будут удалены настройки контрмер, журнал событий, графики и другая информация, хранимая в базах данных этих экземпляров. Если данные нужно сохранить, следует предварительно сделать резервную копию.

Схема взаимодействия:

Настройка Postgres

В качестве инструмента для миграции схемы и дальнейшего управления используется утилита SHMIG.

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

  1. Развернуть полноценный стенд (временно закомментировать строку #COMPOSE_FILE= в файле .env).

  2. Выполнить команду:

    docker-compose create postgres
    
  3. Скопировать скрипты миграции:

    docker cp mitigator_postgres_1:/schema schema
    
  4. Выполнить команду:

    docker-compose rm -sf postgres
    
  5. Восстановить состояние файла .env, раскомментировав строку #COMPOSE_FILE=.

На уровне Postgres необходимо создать базу mitigator. Скрипты миграций создадут пользователя backend и назначат ему необходимые права. После чего на уровне СУБД нужно разрешить подключение для этого пользователя.

Экземпляры MITIGATOR подключаются к порту 5432/tcp. Строку подключения можно явно переопределить, по умолчанию используется:

services:
  backend:
    environment:
      BACKEND_DATABASE_URI: "postgres://backend@${MITIGATOR_STORAGE_HOST}/mitigator?sslmode=disable"

Настройка Graphite

MITIGATOR отправляет метрики в формате Graphite plaintext protocol по адресу: ${MITIGATOR_STORAGE_HOST}:2003 (TCP). Если нужно отправлять их в несколько баз, адреса можно указать явно через запятую:

services:
  fwstats:
    environment:
      FWSTATS_GRAPHITE_ADDRESS: "${MITIGATOR_STORAGE_HOST}:2003,another-host:2003"

Mitigator обращается к Graphite API по URL: http://${MITIGATOR_STORAGE_HOST}:3080/render/.

Настройка ClickHouse

Только если ClickHouse используется в качестве бэкенда Graphite.

  1. Развернуть полноценный стенд (закомментировать строку #COMPOSE_FILE= в файле .env).

  2. Выполнить команду:

    docker-compose create clickhouse
    
  3. Выполнить команды:

    docker cp mitigator_clickhouse_1:/etc/clickhouse-server/config.d clickhouse-config
    docker cp mitigator_clickhouse_1:/etc/clickhouse-server/users.d clickhouse-users
    docker cp mitigator_clickhouse_1:/docker-entrypoint-initdb.d clickhouse
    
  4. Выполнить команду:

    docker-compose rm -sf clickhouse
    
  5. Восстановить состояние файла .env, раскомментировав строку #COMPOSE_FILE=.

  6. В файле .env задать переменную MITIGATOR_OWN_NAME=mitigator-1. Здесь mitigator-1 – имя экземпляра. Имя каждого экземпляра должно быть уникально.

  7. В файле .env задать переменную MITIGATOR_HOST_ADDRESS=192.0.2.1. Здесь 192.0.2.1 – адрес хоста для данного экземпляра.

Полученные настройки являются рекомендованными, но могут быть при необходимости изменены, например, см. раздел «Настройка времени хранения метрик в Graphite».

3.5. Гибридные схемы внедрения

При сборке кластера схемы внедрения могут быть скомбинированы.

Пример: Отказоустойчивое хранилище с дополнительными узлами фильтрации

При такой схеме внедрения копии БД хранятся на разных серверах (реплицируются), но количество реплик БД меньше, чем количество экземпляров MITIGATOR в кластере. Часть экземпляров обращается к удаленным базам по портам TCP: 8888, 2003, 3080, 5432. В данном примере подсистемы graphite и acceslog подключены как внешние модули.

Настройка

  1. Настройка экземпляров, на которых хранятся БД выполняется по инструкции для Внутреннего отказоустойчивого хранилища.

  2. Далее к кластеру подключаются дополнительные экземпляры, на которых не должны храниться реплики БД.

  3. В кластер добавляется внешний accesslog.

  4. Graphite переносится на отдельный сервер.

4. Вручную

Установка вручную

Для опытных администраторов, нестандартных случаев и желающих разобраться.

Подготовка системы

Нужно обеспечить:

Настройка и запуск Mitigator

  1. Разместить compose-файл и задать глобальные параметры системы.
  2. Настроить использование сетевых портов и ядер ЦП обработчиком пакетов.
  3. Автоматизировать привязку драйверов к сетевым портам и запуск MITIGATOR.
  4. Скачать Docker-образы MITIGATOR.

4.1. Подготовка системы

Оборудование

Hyper-threading

Рекомендуется включить hyper-threading в BIOS.

При включенном HT следующая команда показывает 2:

lscpu | grep 'Thread(s) per core:'

NUMA

Многопроцессорные платформы рекомендуется использовать в NUMA-режиме с одним процессором на NUMA-ноду. Поддерживаются платформы с одной и двумя NUMA-нодами.

Для оптимальной производительности рекомендуется разносить сетевые карты по разным NUMA-нодам, чтобы каждый процессор работал только с портами на своей ноде.

Узнать NUMA-ноду устройства по его PCI-адресу:

$ cat /sys/bus/pci/devices/0000:04:00.0/numa_node
0

Модули ядра

Для сетевых карт Intel и некоторых других в системе должен быть загружен модуль ядра, позволяющий DPDK работать с ними. Для карт Mellanox загрузка модулей ядра не требуется.

Необходимо:

  1. Подобрать драйвер для установленных сетевых устройств (документация DPDK):

    • Карты Mellanox работают только со специальным драйвером.
    • vfio-pci: стандартный, рекомендуется по умолчанию;
    • uio_pci_generic: стандартный, используется вместо vfio-pci для платформ без VMX/SVM (см. ниже);
    • virtio-pci: нужен для виртуальных адаптеров QEMU/KVM;
    • igb_uio: нестандартный, нужен только если остальные драйвера не работают (см. ниже).
  2. Настроить загрузку драйвера при запуске системы.

Управление драйверами

Привязка устройств к нужному драйверу производится через скрипт dpdk-devbind (документация DPDK).

Его можно скачать по ссылке:

wget https://docs.mitigator.ru/dist/dpdk-devbind \
    -O /usr/local/bin/dpdk-devbind
chmod +x /usr/local/bin/dpdk-devbind

Для просмотра состояния сетевых устройств и доступных драйверов:

dpdk-devbind --status-dev=net

В списке Network devices using DPDK-compatible driver перечислены устройства, привязанные к совместимому с DPDK драйверу. В списке Network devices using kernel driver — устройства со стандартными драйверами ядра. Доступные драйвера указываются для каждого устройства в поле unused=, например unused=i40e. Отображаются только драйвера, загруженные в системе.

Для загрузки драйвера vfio-pci:

modprobe vfio-pci

Сопоставить имя устройства (например, eth0 или enp3s0f0) и его PCI-адрес можно через поле if= в выводе dpdk-devbind.

Рекомендуется привязывать все устройства одной командной dpdk-devbind. Для работы с vfio-pci все порты одной карты должны быть привязаны к одному драйверу.

Для привязки устройств 0000:06:00.0 и 000:06:00.1 к драйверу vfio-pci:

dpdk-devbind --bind vfio-pci 0000:06:00.0 0000:06:00.1

Если команда привязки выполнилась без сообщений об ошибках, драйвер можно использовать. Устройство, привязанное к специальному драйверу, пропадает из системы (вывод ip link и т.п.). Привязка работает до перезагрузки, автоматическую привязку можно будет настроить при установке MITIGATOR.

Внимание. Устройства, отмеченные в списке **Active**, имеют IP-адрес. Обычно это порт, через которой идет доступ к машине по SSH, поэтому скрипт не позволяет менять драйвер таким устройствам.

Автоматическая загрузка модуля ядра

Если нужный модуль ядра не загружается по умолчанию при старте системы, его загрузку можно включить так:

echo vfio-pci >> /etc/modules

Модуль vfio-pci

Модуль vfio-pci входит в состав ядра Linux. Необходим для работы DPDK с сетевыми картами Intel. Требует поддержки процессором виртуализации ввода-вывода (например, Intel VT-d). Настраивается в BIOS и в параметрах ядра через опцию iommu=on.

Проверить поддержку:

grep 'vmx\|svm' /proc/cpuinfo >/dev/null && echo supported || echo not supported

Модуль igb_uio

Модуль igb_uio устанавливается отдельно:

apt-get -y install linux-headers-amd64 dpdk-igb-uio-dkms

Hugepages

Для работы MITIGATOR необходимы настроенные hugepages (большие страницы памяти). Платформой могут поддерживаться hugepages разных размеров (2 МБ, 1 ГБ), рекомендуется настраивать страницы большего размера.

Необходимое количество hugepages зависит желаемого количества политик защиты. Рекомендуется отводить на hugepages 50-75% от общего объема памяти.

1 GB hugepages

Рекомендуется использовать hugepages размером 1 ГБ, если поддерживаются платформой. Их можно выделить только при загрузке системы.

Проверить поддержку:

grep -m1 pdpe1gb /proc/cpuinfo

Настраивается опциями в параметрах ядра. Пример для выделения 64-х 1 ГБ страниц:

default_hugepagesz=1G hugepagesz=1G hugepages=64

2 MB hugepages

Hugepages размером 2 МБ можно настраивать без перезагрузки системы.

Пример для выделения 2048-х 2 МБ страниц:

sysctl -w vm.nr_hugepages=2048

Пример для выделения при загрузке системы:

echo 'vm.nr_hugepages = 2048' > /etc/sysctl.d/hugepages.conf

Docker

Установка Docker Compose (подробная инструкция по установке).

`apt install docker-compose` — Debian, Ubuntu \
`yum install docker-compose` — CentOS

Если доступ к https://docker.mitigator.ru ведется через прокси, нужно настроить Docker.

4.2. Установка MITIGATOR

Предполагается размещать все файлы в рабочем каталоге /srv/mitigator:

mkdir -p /srv/mitigator
cd /srv/mitigator

1. Docker Compose

  1. Поместить базовую конфигурацию Docker Compose в рабочий каталог:

    wget https://docs.mitigator.ru/dist/docker-compose.yml
    
  2. Скачать базовый файл переменных и сохранить его под именем .env:

    wget https://docs.mitigator.ru/dist/env -O /srv/mitigator/.env
    
  3. В файле .env задать:

    • Версию системы (VERSION).
    • Микроархитектуру процессора из списка указанных в файле-примере (ARCH).
    • Максимальное количество политик защиты (DATA_PLANE_NR_POLICIES).
    • Имя экземпляра в кластере (MITIGATOR_OWN_NAME, обязательно).
    • Внешний адрес MITIGATOR (MITIGATOR_HOST_ADDRESS, обязательно).
    • Прокси для сервера лицензий (ls.mitigator.ru), почтовых уведомлений и службы «Весточка».
    • Часовой пояс (TZ).
    • Токен взаимодействия бэкенда и подсистемы детектирования (TOKEN). В файле .env задано значение TOKEN по умолчанию. Обязательно смените его.

Подробно эти настройки описаны внутри файла-примера.

2. Обработчик пакетов

Архитектура процессора

Для максимальной производительности MITIGATOR нужно использовать сборку, оптимизированную под архитектуру и набор инструкций процессора целевой машины.

В файле .env должна быть строка вида:

ARCH=haswell

Доступные варианты:

Свой процессор можно найти в каталоге Intel, микроархитектура указана в строке Code Name. Для большинства современных процессоров подойдет haswell.

Параметры обработки

Необходимо создать файл data-plane.conf, описывающий параметры запуска обработчика пакетов:

touch data-plane.conf

Файл настроек по умолчанию пустой. Править его требуется только если нужно указать настройки, отличные от выбранных автоматически. Описание настроек.

Выбор портов

Порты в приложении называются ext0, int0, ext1, int1 и т.д. ext — порты внешней сети, int — порты внутренней (защищаемой) сети. Объединяются в ext-int пары по индексу в названии. ext-int пары портов используются для маршрутизации трафика в схеме включения «в разрыв». В схеме включения «on-a-stick» ext-int пары не используются и могут быть любыми.

Если порты не заданы в настройках, используются все порты в системе, доступные DPDK. В таком случае, порты перечисляются в порядке возрастания их PCI-адресов. ext-int пары портов формируются только для портов с общей NUMA-ноды.

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

ext0: 04:00.1
int0: 04:00.0
ext1: 84:00.1
int1: 84:00.0

3. Привязка драйверов к сетевым портам

Перед запуском MITIGATOR отведенные ему сетевые порты должны быть под управлением драйвера, выбранного при подготовке системы.

Для систем под управлением systemd предлагается выполнять привязку перед запуском службы MITIGATOR (см. следующий пункт).

4. Загрузка образов и запуск

MITIGATOR запускается командой docker-compose up -d.

Для систем под управлением systemd предлагается настроить готовую службу:

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

5. Расширенные настройки

Работа через прокси

Docker

Если доступ к https://docker.mitigator.ru ведется через прокси, необходимо настроить Docker.

В системах под управлением systemd предлагается:

  1. Создать drop-in к службе Docker´а с указанием прокси в окружении (детали подключения к прокси заменить на актуальные):

    mkdir -p /etc/systemd/system/docker.service.d
    cat >/etc/systemd/system/docker.service.d/proxy.conf <<END
    [Service]
    Environment=HTTP_PROXY=http://user:password@proxy.local:1234
    Environment=HTTPS_PROXY=http://user:password@proxy.local:1234
    Environment=NO_PROXY=docker.local
    END
    
  2. Добавить сертификат прокси в доверенные для Docker´а (/path/to/proxy.crt заменить на путь к сертификату прокси):

    mkdir -p /etc/docker/certs.d/docker.mitigator.ru
    cp /path/to/proxy.crt /etc/docker/certs.d/docker.mitigator.ru/ca.crt
    
  3. Обновить описание службы Docker и перезапустить её:

    systemctl daemon-reload
    systemctl restart docker
    

MITIGATOR

Если MITIGATOR будет сообщаться с сервером лицензий (ls.mitigator.ru), почтовым сервером и службой «Весточка» через прокси, нужно указать переменные окружения. Для этого нужно создать файл docker-compose.override.yml с таким содержимым:

version: "2.2"

services: backend: environment: HTTP_PROXY: "http://user:password@proxy.local:3128" HTTPS_PROXY: "http://user:password@proxy.local:3128"

При необходимости задать также NO_PROXY (адреса, к которым нужно обращаться без прокси), требуется включать в нее .mitigator, localhost, 127.0.0.0/8, 10.0.0.0/8, 192.168.0.0/16 и 172.16.0.0/12:

NO_PROXY: "<новые серверы>,.mitigator,localhost,127.0.0.0/8,10.0.0.0/8,192.168.0.0/16,172.16.0.0/12"

После этого нужно перезапустить службу бэкенда:

docker-compose up -d backend

Собственный сертификат TLS

Для замены самоподписанного сертификата cert.crt с ключом cert.key на собственный, необходимо смонтировать сертификат и ключ через /srv/mitigator/docker-compose.override.yml:

version: "2.2"
services:
    nginx:
        volumes:
        - example.com.crt:/etc/nginx/cert.crt:ro
        - example.com.key:/etc/nginx/cert.key:ro

После этого нужно перезапустить службу Nginx:

docker-compose up -d nginx

6. Troubleshooting

Не загружаются драйверы (modprobe)

Симптомы:

Необходимо установить пакет linux-headers-amd64 (Debian) и убедиться, что загружена версия ядра, соответствующая версии этого пакета, после чего выполнить:

dkms autoinstall

Не работает docker и docker-compose

По умолчанию эти команды работают только для пользователей группы docker и для root. Это стандартная мера безопасности Docker. Решение:

sudo usermod -aG docker $USER
newgrp docker

Обработчик пакетов недоступен

Такое сообщение появляется в web-интерфейсе, если обработчик пакетов не запустился или остановился. Диагностика (из /srv/mitigator):

docker-compose logs data-plane

Ниже приводятся некоторые типовые проблемы и характерные сообщения.

EAL: Cannot get hugepage information.

Сообщение:

EAL: No free hugepages reported in hugepages-2048kB
EAL: No free hugepages reported in hugepages-1048576kB
EAL: FATAL: Cannot get hugepage information.
EAL: Cannot get hugepage information.
EAL: Error exiting with code: 1
  Cause: DPDK init error: 1

Причина: не выделены или полностью заняты hugepages.

Нужно проверить наличие свободных hugepages и убедиться, что значения HugePages_Total и Hugepagesize совпадают с настроенными, а HugePages_Free равно HugePages_Total (или отличается не более, чем на несколько страниц):

grep Huge /proc/meminfo

no port found with PCI address BB:DD.F

Сообщение:

/data-plane/config.click:12: no port found with pci address '04:00.0'

Нужно убедиться, что адрес устройства 04:00.0 соответствует действительности, и что устройство привязано к драйверу для DPDK точно так же, как при подготовке системы.

Аварийное завершение

При просмотре логов docker-compose logs data-plane сообщение:

Segmentation fault (core dumped)

Чтобы незамедлительно восстановить работу, можно дать команду:

docker-compose up -d data-plane

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

  1. Описание ситуации, в которой произошла проблема (действий с MITIGATOR, входящего трафика).

  2. Описание аппаратной конфигурации сервера:

    • модель ЦП и сетевых карт;
    • размер памяти и конфигурация hugepages;
    • версия ядра Linux, используемые драйвера для сетевых карт и их версии.
  3. Файл /srv/mitigator/data-plane.conf.

  4. Файл сlick.stacktrace, который по умолчанию сохраняется в /var/lib/docker/volumes/mitigator_coredumps/_data/click.stacktrace.

  5. Core dump (слепок памяти процесса), который по умолчанию сохраняется в /var/lib/docker/volumes/mitigator_coredumps/_data/core. Его размер — гигабайты, но он обычно хорошо сжимается.

    В некоторых дистрибутивах (например, Ubuntu) файл core не появляется, потому что обработка сбоев настроена иначе. Проверить настройку можно так:

    cat /proc/sys/kernel/core_pattern
    

    По умолчанию в Linux значение core. Если оно другое:

    1. Запомнить исходное значение:

      cat /proc/sys/kernel/core_pattern > /tmp/old_core_pattern
      
    2. Заменить его на core:

      echo core | sudo tee /proc/sys/kernel/core_pattern
      
    3. Воспроизвести проблему, получить файл core по указанному выше пути.

    4. Восстановить оригинальное значение:

      cat /tmp/old_core_pattern | sudo tee /proc/sys/kernel/core_pattern