Установка 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):

    • Для VirtualBox: исполнить /usr/local/bin/virtual-box_prepare.sh, либо поменять адреса сетевых портов вручную (см. ниже).

    • При обновлении:

      • перейти в рабочий каталог:
        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

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

Смена сетевых портов для VirtualBox

Гипервизоры дают разные PCI-адреса сетевым портам. Конфигурация в OVA рассчитана на VMWare, а для VirtualBox нужно изменить её:
for e in s/0b:00.0/00:09.0/ s/13:00.0/00:0a.0/; do
    for f in /etc/systemd/system/mitigator.service.d/nics.conf /srv/mitigator/data-plane.conf; do
        sed -e ${e} -i ${f}
    done
done
systemctl daemon-reload

2. Ansible

Playbook работает для Debian 9 и 10, 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:
- pci_address: "0000:0b:00.0"
  lcore: 1
- pci_address: "0000:13:00.0"
  lcore: 2
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

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

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

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

Hyper-threading

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

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

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

NUMA

Если на двухсокетной системе установлены две сетевых карты, они должны быть на разных NUMA-узлах, иначе производительность будет низкой. Узнать NUMA-узел карты по PCI-адресу любого её порта можно так:

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

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

Модули ядра

В системе должен быть загружен модуль ядра, позволяющий DPDK работать с сетевым портом. Работоспособность драйверов, то есть возможность их привязки, зависит от сетевого адаптера, версии ядра Linux и платформы (чипсета или гипервизора).

Остальные разделы на этой странице («Hugepages» и «Docker») актуальны для любого выбранного драйвера.

Необходимо:

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

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

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

Для привязки драйверов и управления устройствами можно загрузить скрипт 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-адрес можно через sysfs:

ls -l /sys/class/net | grep pci

Например, ссылка на ../../devices/pci0000:00/0000:00:1d.1/0000:04:00.0/net/eth0 означает, что eth0 связан с устройством 0000:04:00.0. Таким образом нужно выяснить адреса всех интересующих устройств.

Рекомендуется привязывать все устройства одной командной. Особенно это важно для 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, но требует поддержки процессором виртуализации ввода-вывода (например, технологии Intel(r) VT-d). Проверить поддержку (должно напечатать supported):

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

Модуль igb_uio

В Debian модуль igb_uio устанавливается отдельно:

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

Если при этом обновилось ядро, необходимо перезагрузить систему.

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

Hugepages

Большие страницы (hugepages) необходимы для работы Mitigator´а. В зависимости от процессора могут поддерживаться hugepages разных размеров, чаще всего 2 МБ или 1 ГБ. При большем размере страницы выше производительность, но не все процессоры поддерживают размер 1 ГБ.

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

1 GB hugepages

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

grep -m1 ' pdpe1gb ' /proc/cpuinfo

Hugepages размером 1 ГБ выделяются только при загрузке. В параметрах ядра необходимо указать опции (например, для 64 страниц по 1 ГБ, итого 64 ГБ):

default_hugepagesz=1G hugepagesz=1G hugepages=64

Например, при использовании GRUB это указывается в /etc/default/grub, после чего нужно вызвать update-grub и перезагрузить систему.

2 MB hugepages

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

grep -m1 ' pse ' /proc/cpuinfo

Hugepages размером 2 МБ управляются через sysctl. Например, для выделения 2048 страниц по 2 МБ (итого 4 ГБ) при загрузке системы:

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

Можно выделить двухмегабайтные hugepages без перезагрузки.

sysctl -w vm.nr_hugepages=2048

Однако из-за фрагментации памяти Mitigator может не запуститься, тогда перезагрузка необходима.

Docker

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

3.2. Установка 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

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

Выбор портов

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

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

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

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

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

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

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

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

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

ext0: 04:00.1
  cores: 1
int0: 04:00.0
  cores: 2
ext1: 84:00.1
  cores: 12
int1: 84:00.0
  cores: 13

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

ext0: 04:00.1
  cores: 1-4

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

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

port_cores: 1-2

ext0: 04:00.1 int0: 04:00.0

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

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

worker_cores: 3-11,14-23,27-35,38-47

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

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

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

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

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

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

4. Выбор версии

Новейшая: v20.08.4

Как выбрать версию по задаче?

Оценить последнюю стабильную версию

Выбор: latest или v20.08

latest означает последнюю мажорную версию со всеми исправлениями.

Мажорная версия соответствует последней минорной в своих рамках, то есть, если последняя версия v12.34.5, v12.34 тождественна ей.

Жестко зафиксировать версию

Выбор: v20.08.4

Например, если требуется проверить версию в тестовой среде, а затем развернуть точно такую же на production. Минорные версии не меняются. Первая мажорная версия обозначается нулем, например, v12.34.0.

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
    
  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:

NO_PROXY: "<новые серверы>,.mitigator,localhost"

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

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. 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