Предполагается размещать все файлы в рабочем каталоге /srv/mitigator
:
mkdir -p /srv/mitigator
cd /srv/mitigator
Примеры конфигураций подходят для системы в минимальной комплектации (4 ядра, 8 ГБ памяти, два сетевых интерфейса для данных, один для управления) и рассчитаны на 100 политик защиты (пропускная способность зависит от типа интерфейсов и характера трафика).
Поместить базовую конфигурацию Docker Compose в рабочий каталог:
wget https://docs.mitigator.ru/dist/docker-compose.yml
Скачать базовый файл переменных и сохранить его под именем
.env
:
wget https://docs.mitigator.ru/dist/env -O /srv/mitigator/.env
В нем можно задать:
Подробно эти настройки описаны внутри файла-примера.
Для максимальной производительности 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);
редактировать не нужно.
Количество адресов, которые могут одновременно считаться обработчиком пакетов проверенными (размер таблицы адресов), указывается так:
define($tcp_flood_cache_size 131072);
Это должна быть степень двойки, количество адресов будет 75 % от указанного. На адрес нужно 16 байтов. Минимальная конфигурация использует таблицу размером 217 записей (2 МБ), то есть на 100 тыс. адресов. Рекомендуется 16 млн. записей (224 = 16777216).
Таблица расходует память, отведенную на hugepages.
Нужно указать по PCI-адресам, какие порты будут использоваться.
Названия должны быть вида ext
N
и int
N
и перечисляться парами
«внешний, внутренний», например:
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... */
в примере,
чтобы распределение ядер было удобно читать.
Перед запуском 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 uio_pci_generic 0000:06:00.3 0000:06:00.2
В нем запуск утилиты для привязки интерфейсов к драйверу. В параметрах драйвер и PCI-адреса. Их нужно заменить на актуальные драйвер и PCI-адреса.
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´а будет доступен по адресу интерфейса управления.