mitigator_arch: микроархитектура процессора, для которой будет загружена
оптимизированная версия обработчика пакетов: nehalem, sandybridge
или haswell (указания по выбору).
mitigator_nic_driver: драйвер сетевой карты для DPDK
(подробнее о выборе).
mitigator_nics: сетевые порты с указанием PCI-адресов и ядер
процессора. Подразумевается, что они перечислены в порядке ext0,
int0, ext1, int1 и т. д. Портов может быть нечетное количество
и даже один.
mitigator_nr_addrs: размер таблицы проверенных адресов для контрмер
DNS, HTTP, ATLS. Должен быть степенью двойки. Для физических машин
рекомендуется 16777216 (224).
mitigator_hugepage_size: размер страницы (2M или 1G);
mitigator_hugepage_nr: количество страниц.
mitigator_nr_policies: максимальное количество политик защиты.
Можно указать версию Mitigator´а
(latest по умолчанию).
При первом запуске и при mitigator_pull_images: y будет выполнена загрузка
образов Mitigator´а, для чего нужно задать логин и пароль:
mitigator_registry_user и mitigator_registry_pass.
Можно настроить прокси для Docker´а и компонент Mitigator´а.
5. Развернуть Mitigator на целевую машину mitigator.local,
куда есть доступ по SSH:
Запятая после имени хоста — не опечатка. Если имя пользователя SSH
отличается от локального, например, login, добавляется параметр -u login.
--become и --ask-become-pass используются для повышения привилегий, когда
подключение осуществляется не напрямую через пользователя root
(необходимо для выполнения части задач в процессе инсталяции).
В конце установки машина перезагрузится.
Playbook безопасно исполнять повторно в случае проблем.
Дополнение
1. Задания в роли ансибла разделены на 4 «тега»:
checks, system, hugepages, mitigator.
Задания под тегом, соответственно, предназначены для проверки конфигурации,
настройки системы, настройки hugepages и настройки непосредственно Mitigator´а.
При необходимости перезапустить роль и перенастроить установку только частично,
можно запустить playbook с необходимым набором тегов, например:
Разместить compose-файл и задать глобальные параметры системы.
Настроить использование сетевых портов и ядер ЦП обработчиком пакетов.
Автоматизировать привязку драйверов к сетевым портам и запуск Mitigator´а.
Скачать Docker-образы Mitigator´а.
3.1. Подготовка системы
Оборудование
Hyper-threading
Рекомендуется включить hyper-threading в BIOS.
При включенном HT следующая команда показывает 2:
lscpu | grep 'Thread(s) per core:'
NUMA
Многопроцессорные платформы рекомендуется использовать в NUMA-режиме с одним процессором
на NUMA-ноду. Поддерживаются платформы с одной и двумя NUMA-нодами.
Для оптимальной производительности рекомендуется разносить сетевые карты по разным
NUMA-нодам, чтобы каждый процессор работал только с портами на своей ноде.
Для сетевых карт Intel и некоторых других в системе должен быть загружен модуль ядра,
позволяющий DPDK работать с ними. Для карт Mellanox загрузка модулей ядра не требуется.
Необходимо:
Подобрать драйвер для установленных сетевых устройств
(документация DPDK):
Для просмотра состояния сетевых устройств и доступных драйверов:
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:
Если команда привязки выполнилась без сообщений об ошибках, драйвер можно
использовать. Устройство, привязанное к специальному драйверу, пропадает из системы
(вывод ip link и т.п.). Привязка работает до перезагрузки, автоматическую привязку
можно будет настроить при установке Mitigator´а.
Внимание. Устройства, отмеченные в списке **Active**, имеют IP-адрес. Обычно
это порт, через которой идет доступ к машине по SSH, поэтому скрипт не позволяет менять
драйвер таким устройствам.
Автоматическая загрузка модуля ядра
Если нужный модуль ядра не загружается по умолчанию при старте системы, его загрузку
можно включить так:
echo vfio-pci >> /etc/modules
Модуль vfio-pci
Модуль vfio-pci входит в состав ядра Linux. Необходим для работы DPDK с сетевыми
картами Intel. Требует поддержки процессором виртуализации ввода-вывода (например,
Intel VT-d). Настраивается в BIOS и в параметрах ядра через опцию iommu=on.
Для работы Mitigator´а необходимы настроенные hugepages (большие страницы памяти).
Платформой могут поддерживаться hugepages разных размеров (2 МБ, 1 ГБ), рекомендуется
настраивать страницы большего размера.
Необходимое количество hupepages зависит желаемого количества политик защиты.
Рекомендуется отводить на 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 МБ можно настраивать без перезагрузки системы.
Предполагается размещать все файлы в рабочем каталоге /srv/mitigator:
mkdir -p /srv/mitigator
cd /srv/mitigator
Примеры конфигураций подходят для системы в минимальной комплектации (4 ядра,
8 ГБ памяти, два сетевых интерфейса для данных, один для управления)
и рассчитаны на 100 политик защиты (пропускная способность зависит от типа
интерфейсов и характера трафика).
прокси для сервера лицензий
(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, описывающий параметры запуска обработчика
пакетов:
touch data-plane.conf
Файл настроек по умолчанию пустой. Править его требуется только если нужно указать
настройки, отличные от выбранных автоматически.
Описание настроек.
Выбор портов
Порты в приложении называются ext0, int0, ext1, int1 и т.д. ext — порты
внешней сети, int — порты внутренней (защищаемой) сети. Объединяются в ext-int пары по
индексу в названии. ext-int пары портов используются для маршрутизации трафика в схеме
включения «в разрыв». В схеме включения «on-a-stick» ext-int пары не используются и могут
быть любыми.
Если порты не заданы в настройках, используются все порты в системе, доступные DPDK.
В таком случае, порты перечисляются в порядке возрастания их PCI-адресов. ext-int пары
портов формируются только для портов с общей NUMA-ноды.
Если порядок перечисления портов по умолчанию не совпадает с физическим подключением
линков, либо требуется ограничить список используемых портов, порты можно настроить явно:
Для портов 40 GbE нужно 3 ядра, для портов 100 GbE — 6 ядер:
ext0: 04:00.1
cores: 1-3
На каждое ядро создается отдельная очередь приема, трафик между очередями распределяется
аппаратным RSS на сетевой карте.
Группу ядер можно назначить сразу нескольким портам. Это может быть полезно при включении
«в разрыв», когда атаки приходят на ext-порты, а нагрузка на int небольшая:
При первом запуске или обновлении нужно совершить вход в хранилище образов со своими
учетными данными:
docker login docker.mitigator.ru
Запустить Mitigator:
systemctl start mitigator
При первом запуске понадобится некоторое время для загрузки
образов. Процесс можно наблюдать в выводе docker-compose logs -f
или, для systemd:
journalctl -u mitigator -f
Спустя некоторое время, web-интерфейс Mitigator´а будет доступен
по адресу интерфейса управления.
После установки и запуска настроить систему
для её стабильной и безопасной работы.
4. Mitigator в режиме кластера
В режиме кластера несколько экземпляров системы Mitigator пользуются
едиными базами данных и управляются централизованно. За счет добавления
дополнительных экземпляров система может неограниченно масштабироваться.
Режим кластера позволяет обрабатывать трафик независимо на каждом экземпляре,
но управлять ими из единого интерфейса. При плановом или аварийном отключении
любого экземпляра сохраняется возможность управления остальными.
Между экземплярами должна быть сетевая связность, взаимодействие осуществляется
по TCP и UDP.
Существует несколько принципиальных схем внедрения.
Общее нерезервированное хранилище:
+ простота настройки; − при выключении главного экземпляра теряется управление и мониторинг; − при отказе диска главного экземпляра теряются данные.
Внутреннее отказоустойчивое хранилище:
+ отказоустойчивость за счет репликации БД; + нет потребности в дополнительном сервере для хранилища; − ресурсы экземпляров Mitigator´а расходуются на нужды хранилища; − повышенные требования к квалификации администратора; − отсутствие гибкости настройки.
Внешнее отказоустойчивое хранилище:
+ полный контроль и гибкость (отказоустойчивость, тонкая настройка); + снимается нагрузка с экземпляров Mitigator´а; − требуется квалификация администратора; − нужен дополнительный сервер для хранилища; − необходимо запускать миграцию вручную при обновлении.
После установки и запуска настроить систему
для её стабильной и безопасной работы.
Общее нерезервированное хранилище
Общие базы данных для всех экземпляров Mitigator´а физически хранятся на сервере
одного из них. К базовому экземпляру должны быть разрешены подключения
с остальных экземпляров по следующим портам TCP: 8888, 2003, 3080, 5432.
Установка базового экземпляра выполняется по шагам,
описанным в разделе «Установка».
Остальные экземпляры Mitigator´а должны обращаться к БД базового экземпляра
и поэтому сначала для них необходимо также выполнить стандартную установку.
После установки, но перед запуском, необходимо:
Если требуются дополнительные настройки, например, при использовании карт
Mellanox, поместить их в docker-compose.override.yml и добавить его
в список:
В файле .env задать переменную MITIGATOR_STORAGE_HOST=192.0.2.1.
Здесь 192.0.2.1 – адрес базового экземпляра.
В файле .env задать переменную MITIGATOR_OWN_NAME=mitigator-1.
Здесь mitigator-1 – имя экземпляра. Имя каждого экземпляра должно быть уникально.
В файле .env задать переменную MITIGATOR_OWN_ADDRESS=192.0.2.1.
Здесь 192.0.2.1 – адрес хоста для данного экземпляра.
Внутреннее отказоустойчивое хранилище
В целях отказоустойчивости синхронизированные копии БД должны физически
храниться на разных серверах (реплицироваться). При данной схеме реплики
БД хранятся на тех же серверах, где работают экземпляры Mitigator´а.
Это позволяет сэкономить ресурсы и не требует знаний по настройке PostgreSQL.
Экземпляры PostgreSQL работают в схеме потоковой репликации
active — hot standby.
Вместо подключения к PostgreSQL напрямую каждый Mitigator подключается
к локальной работающий программе pgfailover,
которая перенаправляет подключения к PostgreSQL-лидеру репликации.
Если лидер недоступен, pgfailover делает лидером одну из ведомых реплик
в заданной очередности.
Mitigator-лидер кластера и PostgreSQL-лидер репликации не обязаны совпадать.
Предполагается, что между узлами надежная связь. Если группа экземпляров
окажется отрезана от лидера репликации, среди них будет выбран новый лидер
(split-brain). После восстановления связи придется вручную удалить данные
на отрезанной части экземпляров и заново ввести их в кластер.
Метрики для графиков пишутся Mitigator´ом-лидером на все экземпляры
для сохранности. Это задается списком серверов FWSTATS_GRAPHITE_ADDRESS.
Настройка
Процесс настройки описан для двух экземпляров и одинаков на всех экземплярах,
кроме конкретных значений MITIGATOR_OWN_INDEX. Для большего количества
экземпляров нужно расширить по аналогии списки серверов pgfailover
и FWSTATS_GRAPHITE_ADDRESS.
Если требуются дополнительные настройки, например, при использовании карт
Mellanox, поместить их в docker-compose.override.yml и добавить его
в список:
В файле .env задать переменную MITIGATOR_OWN_ADDRESS=192.0.2.1.
Здесь 192.0.2.1 – адрес хоста для данного экземпляра.
В файле .env задать переменную MITIGATOR_OWN_INDEX=0.
Здесь 0 – идентификатор очередности данного экземпляра
стать Active-сервером PostgreSQL.
Должен быть уникальным и последовательно возрастающим на каждом экземпляре.
В файле .env задать переменные SERVER1=192.0.2.1 и SERVER2=192.0.2.2.
Здесь 192.0.2.1 и 192.0.2.2– внешние адреса серверов, на которых запущены
экземпляры.
Создать файл docker-compose.failover.yml и задать конфигурацию,
приведенную ниже.
Если произойдет разрыв соединения с экземпляром-лидером (базы в режиме Active),
экземпляр с базами в режиме Standby занимает его место и становится лидером.
Механизма переключения баз бывшего лидера в режим Standby не предусмотрено
штатной репликацией PostgreSQL.
Для схемы из двух баз данных это означает прекращение репликации на другой
сервер до ручной перенастройки схемы.
Поднятие Standby из бывшего Active
Для переключения бывшего Active и возвращения его в схему репликации
необходимо остановить сервис PostgreSQL, а также удалить локальные данные базы.
Остановка сервиса PostgreSQL:
docker-compose rm -fsv postgres
Удаление локальных данных базы:
docker volume rm mitigator_postgres
Инициализация Standby аналогично первой инициализации:
docker-compose run --rm postgres standby
после чего запускается как обычно:
systemctl start mitigator
Внешнее отказоустойчивое хранилище
Данная схема внедрения подразумевает физическое хранение общих для всех
экземпляров Mitigator´а баз данных на внешнем сервере. Работоспособность
и отказоустойчивость всех СУБД обеспечивается силами администратора внешнего
сервера под конкретные требования.
Все экземпляры разворачиваются как worker´ы (см. выше).
Схема взаимодействия:
Mitigator подключается к Postgres для записи и чтения настроек и журналов;
Mitigator оправляет в graphite метрики и обращается к его API;
В качестве инструмента для миграции схемы и дальнейшего управления используется
утилита SHMIG.
Миграции необходимо брать прямо из контейнера используемой версии:
Развернуть полноценный стенд
(временно закомментировать строку #COMPOSE_FILE= в файле .env).
Выполнить команду:
docker-compose create postgres
Выполнить команду:
docker cp mitigator_postgres_1:/schema schema
Выполнить команду:
docker-compose rm -sf postgres
Восстановить состояние файла .env, раскомментировав строку
#COMPOSE_FILE=.
На уровне Postgres необходимо создать базу mitigator. Скрипты миграций
создадут пользователя backend и назначат ему необходимые права. После чего
на уровне СУБД нужно разрешить подключение для этого пользователя.
Экземпляры Mitigator´а подключаются к порту 5432/tcp.
Строку подключения можно явно переопределить, по умолчанию используется:
Mitigator отправляет метрики в формате Graphite plaintext
protocol по
адресу: ${MITIGATOR_STORAGE_HOST}:2003 (TCP). Если нужно отправлять их
в несколько баз, адреса можно указать явно через запятую:
Основным изменением в интерфейсе Mitigator´а при переходе на режим кластера
стало разделение некоторых настроек на относящиеся к системе в целом и для
конкретных экземпляров.
На вкладке «Экземпляры» пользователю доступен список всех экземпляров системы.
Для каждого из них отображается текущий статус активности. Переключателями
централизованно изменяется состояние экземпляра. Нажатие на название
экземпляра переводит пользователя на страницу настройки экземпляра. Если в
системе создан только один экземпляр, то при нажатии на пункт меню «Экземпляры»
пользователь сразу попадет на страницу настройки экземпляра.
В настройках экземпляра могут быть изменены его название, признак лидера,
статус защиты и адрес обработчика пакетов для данного экземпляра.
Разделы «Интеграция в сеть» и «GRE-туннель со сторонним сервисом» теперь
также находятся на вкладке «Экземпляры», так как для корректной работы системы
следует задать параметры внедрения в сеть для каждого экземпляра.
Mitigator позволяет использовать агрегацию каналов (LAG) между устройствами
во внешней и внутренней сети. Настройки интеграции в сеть влияют на то, какие
варианты агрегации каналов могут использоваться:
в режиме «L2-прозрачность» — статический или динамический (например, LACP);
в режиме «On-a-stick» — только статический LAG.
Mitigator позволяет балансировать нагрузку между несколькими экземплярами системы
по ECMP за счет анонсирования по BGP каждым экземпляром одинаковых префиксов.
Когда один из экземпляров отключается, анонс снимается и трафик автоматически
распределяется между оставшимися экземплярами.
Карточка «Лицензия» разделена на две. В настройках системы задается
значение лицензионного ключа, а в настройках экземпляра находятся элементы
управления лицензированной полосой и сервисная информация.
В верхней панели интерфейса находится выпадающий список, позволяющий
выбрать экземпляр, для которого в системе будут показываться графики. Также
возможно отображение суммарно для всех экземпляров, если выбрано значение
«Все экземпляры».
Обновить описание службы Docker и перезапустить её:
systemctl daemon-reload
systemctl restart docker
Mitigator
Если Mitigator будет сообщаться с сервером лицензий (ls.mitigator.ru),
почтовым сервером и службой «Весточка» через прокси, нужно указать переменные
окружения. Для этого нужно создать файл docker-compose.override.yml
с таким содержимым:
При необходимости задать также NO_PROXY (адреса, к которым нужно
обращаться без прокси), требуется включать в нее .mitigator и localhost:
NO_PROXY: "<новые серверы>,.mitigator,localhost"
После этого нужно перезапустить службу бэкенда:
docker-compose up -d backend
Собственный сертификат TLS
Для замены самоподписанного сертификата cert.crt с ключом cert.key
на собственный, необходимо смонтировать сертификат и ключ через
/srv/mitigator/docker-compose.override.yml:
modprobe: FATAL: Module igb_uio not found in directory /lib/modules/4.9.0-6-amd64
при установке пакета:
Module build for kernel 4.9.0-6-amd64 was skipped since the
kernel headers for this kernel does not seem to be installed.
Необходимо установить пакет 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
Далее рекомендуется связаться с разработчиками с целью точной
диагностики и исправления, для чего им желательно иметь:
Описание ситуации, в которой произошла проблема
(действий с Mitigator´ом, входящего трафика).
Описание аппаратной конфигурации сервера:
модель ЦП и сетевых карт;
размер памяти и конфигурация hugepages;
версия ядра Linux, используемые драйвера для сетевых карт и их версии.
Файл /srv/mitigator/data-plane.conf.
Core dump (слепок памяти процесса), который по умолчанию сохраняется
в /var/lib/docker/volumes/mitigator_coredumps/_data/core. Его
размер — гигабайты, но он обычно хорошо сжимается.
В некоторых дистрибутивах (например, Ubuntu) файл core не появляется,
потому что обработка сбоев настроена иначе.
Проверить настройку можно так:
cat /proc/sys/kernel/core_pattern
По умолчанию в Linux значение core. Если оно другое:
