Установка Mitigator

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

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

Примеры конфигураций подходят для системы в минимальной комплектации (4 ядра, 8 ГБ памяти, два сетевых интерфейса для данных, один для управления) и рассчитаны на 100 политик защиты (пропускная способность зависит от типа интерфейсов и характера трафика).

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

    В нем можно задать:

    • версию системы;
    • микроархитектуру процессора для лучшей производительности;
    • максимальное количество политик защиты;
    • прокси для сервера лицензий (ls.mitigator.ru), почтовых уведомлений и службы «Весточка»;
    • часовой пояс;
    • токен взаимодействия бэкенда и подсистемы детектирования.

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

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

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

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

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

ARCH=haswell

Доступные варианты: nehalem, sandybridge, haswell. Если не указана ARCH, используется nehalem — самая ранняя и неэффективная.

Свой процессор можно найти в каталоге Intel, микроархитектура указана в строке Code Name. Если в перечне доступных нет нужной, воспользуйтесь диаграммой, например, для Xeon E5-2680 v4 (Broadwell) оптимальна haswell.

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

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

wget https://docs.mitigator.ru/dist/data-plane.conf

Комментарии между /* и */ игнорируются.

Строку require(library config.click); редактировать не нужно.

Количество проверенных IP

Количество адресов, которые могут одновременно считаться обработчиком пакетов проверенными (размер таблицы адресов), указывается так:

define($tcp_flood_cache_size 131072);

Это должна быть степень двойки, количество адресов будет 75 % от указанного. На адрес нужно 16 байтов. Минимальная конфигурация использует таблицу размером 217 записей (2 МБ), то есть на 100 тыс. адресов. Рекомендуется 16 млн. записей (224 = 16777216).

Таблица расходует память, отведенную на hugepages.

Выбор портов

Нужно указать по PCI-адресам, какие порты будут использоваться. Названия должны быть вида extN и intN и перечисляться парами «внешний, внутренний», например:

ext0::Port(04:00.1);
int0::Port(04:00.0);
ext1::Port(84:00.1);
int1::Port(84:00.0);

Если порт всего один, он называется ext0.

Даже если планируется схема включения «on-a-stick», на уровне этого файла деление на внешние и внутренние порты все равно должно быть.

Распределение нагрузки по ядрам

Предварительная информация:

  • Номера ядер на каждом NUMA-узле (на примере двухпроцессорной системы):

    $ lscpu | grep NUMA
NUMA node(s):        2
NUMA node0 CPU(s):   0-11,24-35
NUMA node1 CPU(s):   12-23,36-47

    Команда likwid-topology -g (пакет hwloc в Debian) отображает топологию процессора в наглядном виде.

  • NUMA-узлы, к которым относятся сетевые карты:

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

Если логическое ядро отведено для чтения трафика из порта (IO-ядро), hyperthread-парное ему логическое ядро не должно быть нагружено.

Ядро 0 зарезервировано для управления и далее не используется, как и парное ему ядро 24.

Для портов 10 GbE достаточно по одному ядру на порт с того же NUMA-узла:

Lcore(1, ext0);
Lcore(2, int0);
Lcore(12, ext1);
Lcore(13, int1);

Для портов 40 GbE нужно 4 ядра, для портов 100 GbE — 6 ядер:

Lcore(1-4, ext0);

На каждое ядро создается отдельная очередь приема, трафик между очередями распределяется аппаратным RSS на сетевой карте.

Группу ядер можно назначить сразу нескольким портам. Это может быть полезно при включении «в разрыв», когда атаки приходят на ext-порты, а нагрузка на int мала (в пакетах):

Lcore(1-2, ext0, int0);

Портам 1—2 парными являются 25—26, портам 12—13 — порты 36—37 (см. вывод lscpu), поэтому для обработки пакетов не используются все восемь.

Оставшиеся ядра, то есть все, кроме 0 и 24, 1—2 и 25—26, 12—13 и 36—37, используются для обработки трафика:

Lcores(3-11,14-23,27-35,38-47);

Рекомендуется оставить комментарий, аналогичной /* Lcore map... */ в примере, чтобы распределение ядер было удобно читать.

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

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

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

  • Загрузить скрипт привязки и сделать его исполняемым:

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

  • Создать каталог /etc/systemd/system/mitigator.service.d:

    mkdir -p /etc/systemd/system/mitigator.service.d

    В нем разместить файл nics.conf такого вида:

    [Service]
ExecStartPre=/usr/local/bin/dpdk-devbind -b vfio-pci 0000:06:00.3 0000:06:00.2

    В нем запуск утилиты для привязки интерфейсов к драйверу. В параметрах драйвер и PCI-адреса. Их нужно заменить на актуальные драйвер и PCI-адреса.

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

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

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

  • Разместить файл службы Mitigator´а:

    wget https://docs.mitigator.ru/dist/mitigator.service \
    -O /etc/systemd/system/mitigator.service

  • Настроить автозапуск Mitigator´а:

    systemctl enable mitigator

  • При первом запуске или при необходимости выполнить обновление нужно совершить вход в хранилище образов со своими учетными данными:

    docker login docker.mitigator.ru

  • Запустить Mitigator:

    systemctl start mitigator

    При первом запуске некоторое время понадобится для загрузки образов. Процесс можно наблюдать в выводе docker-compose logs -f или, для systemd:

    journalctl -u mitigator -f

    Спустя некоторое время, web-интерфейс Mitigator´а будет доступен по адресу интерфейса управления.