База знаний :: BIFIT Mitigator

Кластерная терминология

Mon, 01 Jan 0001 00:00:00 +0000

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

Функциональные возможности системы MITIGATOR

Mon, 01 Jan 0001 00:00:00 +0000

В статье перечислены основные функциональные возможности программного комплекса для защиты от DDoS-атак MITIGATOR. Защита от DDoS-атак MITIGATOR защищает от атак на уровнях от сетевого до прикладного модели OSI (объёмных, на исчерпание сессий и уровня приложений). Создание сервиса Типовая конфигурация MITIGATOR поддерживает возможность создания сервиса по защите от DDoS-атак. Работа на стандартном оборудовании MITIGATOR работает на серверах стандартной конфигурации. Не требуется приобретение специализированной аппаратной платформы, что уменьшает расходы на обслуживание. Гибкость внедрения MITIGATOR устанавливается без перестраивания сети заказчика. Способ внедрения зависит от структуры сети и задач.

Способы интеграции MITIGATOR в сеть

Mon, 01 Jan 0001 00:00:00 +0000

В MITIGATOR реализована поддержка множества сценариев встраивания в сеть заказчика. Ниже описаны основные термины и способы внедрения в сеть, а также примеры внедрения. Внешняя и внутренняя сети Логически MITIGATOR подключается к двум сетям: Внешняя сеть (external) – сеть, из которой приходит трафик, требующий очистки; Внутренняя сеть (internal) – сеть, в которой расположены защищаемые ресурсы.

Взаимодействие по BGP

Mon, 01 Jan 0001 00:00:00 +0000

Информация Статья устарела и требует актуализации. В MITIGATOR реализована поддержка множества сценариев взаимодействия по BGP. Каждый экземпляр кластера может выступать в качестве независимого BGP-спикера, анонсировать префиксы, а также рассылать и принимать FlowSpec-правила. Памятка Более подробно обо всех аспектах настройки взаимодействия ниже. Локальные параметры BGP Выполняется определение локальных параметров экземпляров кластера и для каждого экземпляра персонально разрешается установка BGP-соединения с BGP-соседями.

Быстрая настройка защиты MITIGATOR

Mon, 01 Jan 0001 00:00:00 +0000

Материалы данной статьи призваны облегчить понимание основных принципов организации защиты при помощи MITIGATOR. Далее приводится пример настройки системы в первой итерации. Одна из особенностей MITIGATOR — порядок обработки трафика. Вначале все пакеты обрабатываются в «Общей защите», затем правила маршрутизации по 5-tuple распределяют трафик по политикам защиты, а после политик трафик возвращается в «Общую защиту» на оставшиеся контрмеры. Обработка обратного трафика от защищаемого ресурса в данной статье не рассматривается.

Сигнализация по BGP

Mon, 01 Jan 0001 00:00:00 +0000

В статье описывается применение BGP в MITIGATOR в сценарии сигнализации вышестоящим операторам связи или поставщикам услуг защиты (MSSP). Задачи сигнализации Когда MITIGATOR работает как периметровая защита от DDoS-атак, он может самостоятельно подавить атаку до суммарной пропускной способности входящих каналов. Для избежания переполнения входящих каналов можно подключать грубую фильтрацию у вышестоящих операторов связи или поставщиков услуг защиты.

Чек-лист первоначальной настройки системы

Mon, 01 Jan 0001 00:00:00 +0000

Список шагов Настроить интеграцию в сеть. Указать лицензионный ключ и задать лимиты. Настроить взаимодействие по BGP. Загрузить в систему справочные базы данных GeoIP. Настроить каналы доставки уведомлений о событиях системы. Настроить рассылку уведомлений через syslog. Включить защиту. (Опционально) Загрузить логотипы и фоновые изображения для различных тем интерфейса. (Опционально) Выбрать тип темы интерфейса и стиль отображения графиков. Подробно 1. Настроить интеграцию в сеть. Настройка производится независимо для каждого экземпляра системы и зависит от организации сетевой инфраструктуры и решаемых задач. Параметры интеграции задаются на странице «Экземпляр».

Чек-лист первоначальной настройки политики защиты

Mon, 01 Jan 0001 00:00:00 +0000

Список шагов Убедиться, что заданы правила маршрутизации для политики. Настроить в политике отображение только нужных контрмер. Настроить контрмеры. Настроить автоматический захват пакетов. Настроить автодетектирование. (Опционально) Проверить влияние на легитимный трафик через тестовый режим. Включить политику защиты. (Опционально) Настроить анализатор логов. (Опционально) Закрепить графики контрмер. Подробно 1. Убедиться, что заданы правила маршрутизации для политики. На вкладке «Настройка политики» страницы «Политика защиты» убедиться, что для политики заданы правила маршрутизации.

Аппаратный байпас

Mon, 01 Jan 0001 00:00:00 +0000

MITIGATOR поддерживает аппаратный байпас сетевых адаптеров Silicom и LR-Link. Проверенные адаптеры Silicom: PE2G4BPI35LA Quad Port Copper 1G Ethernet PCIe Bypass Network Adapter (Intel i350AM4) PE2G6BPI35 Six Port Copper 1G Ethernet PCIe Bypass Network Adapter (Intel i350AM4) PE210G2BPI9 Dual Port Fiber 10G Ethernet PCIe Bypass Network Adapter (Intel 82599ES) PE310G4BPI71 Quad Port Fiber 10G Ethernet PCIe Bypass Network Adapter (Intel XL710BM1) PE340G2BPI71 Dual Port Fiber 40G Ethernet PCIe Bypass Network Adapter (Intel XL710) P4CG2BPI81 Dual Port Fiber 100G Ethernet PCIe Gen 4.0 Bypass Network Adapter (Intel E810) Проверенные адаптеры LR-Link:

Изоляция ядер для оптимизации производительности

Mon, 01 Jan 0001 00:00:00 +0000

По умолчанию ядра CPU, работающие с сетевыми портами, используются и другими подсистемами. Это может снижать производительность и вызывать всплески Input Errors pps/bps на графиках Port extX/intX. Можно снять часть нагрузки с этих ядер, запретив некритичным подсистемам выполняться на них. Для этого: В опциях ядра пропишите изоляцию ядер обработчика пакетов через параметры isolcpus=... и rcu_nocbs=.... Также рекомендуется добавить mitigations=off для отключения патчей безопасности ядра. В .env добавьте параметры: DATA_PLANE_CPUS — список ядер, выделенных под обработчик пакетов (dataplane); CONTROL_PLANE_CPUS — список ядер, выделенных под остальные подсистемы (все остальные ядра). Скачайте docker-compose.cpuisol.yml, применяющий параметр cpuset для всех подсистем:

Графики

Mon, 01 Jan 0001 00:00:00 +0000

В MITIGATOR для работы с графиками используются: ClickHouse, Graphite, Grafana, Carbon, CarbonAPI. Все перечисленное имеет возможности для более точной настройки в зависимости от требований. Статьи, описывающие различные аспекты настройки: Grafana Отдельный Graphite Конфигурация ClickHouse Внешняя Grafana Единый Graphite Время хранения метрик

Документация pgfailover

Mon, 01 Jan 0001 00:00:00 +0000

pgfailover наблюдает за состоянием кластера PostgreSQL и выступает для клиентов как TCP-прокси к текущему Primary. При смене Primary pgfailover разрывает соединения с клиентами, и они должны переподключиться. Параметры подключения задаются через переменные окружения с префиксом PGFAILOVER_: export PGFAILOVER_BIND_ADDRESS=":5432" export PGFAILOVER_SERVERS="postgres://repuser@pg0.example.com/database?sslmode=disable&connect_timeout=5 postgres://repuser@pg1.example.com/database?sslmode=disable&connect_timeout=5" ./pgfailover Роль сервера (Primary/Standby) проверяется pg_is_in_recovery() по умолчанию раз в 5 секунд (PGFAILOVER_INTERVAL), количество попыток подключения регулируется переменной PGFAILOVER_ATTEMPTS (по умолчанию 1). pgfailover может автоматически переводить локальный PostgreSQL в Primary. Адрес локальной БД задаётся переменной окружения PGFAILOVER_PROMOTION_ADDRESS и должен совпадать с хостом одной из записей PGFAILOVER_SERVERS. Когда с Primary пропадает связь, pgfailover переводит в Primary первый по порядку Standby в PGFAILOVER_SERVERS. Если PGFAILOVER_PROMOTION_ADDRESS не задан, перевод в Primary отключён.

Настройка системы для карт Mellanox (NVIDIA)

Mon, 01 Jan 0001 00:00:00 +0000

Подготовка системы Работа с картами Mellanox (NVIDIA) требует актуальной версии драйвера и прошивки устройства NVIDIA MLNX_OFED. По указанной ссылке в разделе Download в таблице Current Versions выбрать актуальную версию MLNX_OFED для нужного дистрибутива операционной системы. При отсутствии нужной версии ОС выбрать ближайшую по старшинству. При отсутствии нужной ОС в списке MLNX_OFED не устанавливать. Проверена работа на Debian 10+ и Ubuntu 20.04+.

Настройки обработчика пакетов

Mon, 01 Jan 0001 00:00:00 +0000

Обработчик пакетов настраивается через файл dataplane.conf. Файл необходимо поместить в рабочий каталог MITIGATOR и добавить в него настройки, которые требуется изменить. Для незаданных настроек используются значения по умолчанию. Комментарии задаются через #, // или /* */. Доступные параметры (указаны значения по умолчанию): # IP-адрес сокета управления приложением. control_address: 0.0.0.0 # TCP-порт сокета управления приложением. # [1, 65535] control_port: 8888 # TCP-порт отладочного сокета управления приложением. # [1, 65535] debug_port: 8889 # TCP-порт gRPC-сокета управления приложением. # [1, 65535] grpc_port: 8890 # UDP-порт сокета управления sync/web-challenger. # [1, 65535] sync_udp_port: 8891 # Количество потоков обработки запросов к порту управления. # [1, 1000] control_threads: 20 # Таймаут обработки запросов к порту управления (секунды). # [1, 10000] control_request_timeout: 15 # Таймаут обработки содержимого запросов/ответов порта управления (секунды). # [1, 10000] control_content_timeout: 300 # Включение логирования событий порта управления. control_log: false # Ограничение на максимальную длину сообщения логирования событий порта управления. # [0, 100000] control_log_limit: 100 # Количество потоков обработки синхронизации данных. # [1, 1000] sync_threads: 10 # Включение логирования событий синхронизации данных. sync_log: false # Включение дополнительных ядер для сокета управления sync/web-challenger. use_extra_service_cores: false # MAC-адрес отправляемых challenge-пакетов. challenge_mac: <не задано> # VLAN ID отправляемых challenge-пакетов. # [1, 4095] challenge_vlan_id: <не задано> # LACP system ID. # По умолчанию используется локальный MAC-адрес. lacp_system_id: <автоопределение> # Операционный ключ порта LACP. # [0, 65535] lacp_oper_key: 1000 # Период повторной отправки запросов резолвера MAC-адресов (секунды). # [1, 10000] mac_retransmit_time: 5 # Время жизни валидных записей резолвера MAC-адресов (секунды). # [1, 10000] mac_reachable_time: 30 # Время жизни протухших записей резолвера MAC-адресов (секунды). # [1, 10000] mac_stale_time: 60 # Максимально допустимое количество политик IPv4. # [1, 60000] max_policies: 100 # Максимально допустимое количество политик IPv6. # [1, 60000] max_policies6: 100 # Максимально допустимая разрядность используемых SIMD-инструкций. # [0, 512] max_simd_bitwidth: <автоопределение> # Размер пула памяти сетевых пакетов (на NUMA-ноду). # [0, 2^31] packet_mempool_size: <автоопределение> # Включение отложенного старта обработки пакетов. # Сетевые порты поднимаются только после полной инициализации приложения. # Предотвращает появление петель на сети. deferred_start: false # Включение особого режима работы с сетевыми картами с двумя портами # (для `port_direct_mode: true`). # Каждый порт карты обрабатывается на отдельном наборе ядер. # Улучшает производительность на скоростях 100G и выше, # когда используются оба порта одновременно. dual_port_nic: false # Политика разгрузки контрольной суммы для RX-пакетов: # `false` - не запрашивать разгрузку, проверять программно; # `true` - включить разгрузку для всех портов, если поддерживается. # Включает разгрузку контрольной суммы только для физических портов, если не указано. port_checksum_offload: <автоопределение> # Режим обработки I/O-очередей сетевых портов: # `false` - обрабатывать I/O-очереди портов на выделенных ядрах, # рекомендуется для небольших скоростей; # `true` - обрабатывать I/O-очереди портов на ядрах обработки пакетов, # рекомендуется для скоростей 100G и выше. port_direct_mode: <автоопределение> # Скорость сетевых портов (Мбит/с). # Отключает автосогласование скорости, если задано. # [100|1000|10000|...] или [100M|1G|10G|...] port_link_speed: <автосогласование> # Включение синхронизации состояния линка пар сетевых портов. port_lsp: false # MTU сетевых портов. # [0, 65535] port_mtu: 1500 # Размер кольцевых буферов обмена пакетами между ядрами обработки I/O-очередей сетевых # портов и ядрами обработки пакетов (для `port_direct_mode: false`). # [0, 2^20] port_ring_size: 8192 # Количество RX-дескрипторов сетевых портов. # [0, 65535] port_rx_desc: <автоопределение> # Количество TX-дескрипторов сетевых портов. # [0, 65535] port_tx_desc: <автоопределение> # Максимальное количество попыток повторной отправки сетевых пакетов в порт. # [0, 2^31] port_tx_retries: 128 # Ядра обработки I/O-очередей сетевых портов (для `port_direct_mode: false`). # Список диапазонов [0, 255] port_cores: <автоопределение> # Количество ядер обработки I/O-очередей сетевых портов (на NUMA-ноду). # [0, 256] port_cores_nr: <автоопределение> # NUMA-ноды ядер обработки I/O-очередей сетевых портов. # Список диапазонов [0, 7] или `all`: # `all` - использовать все ноды. port_nodes: <автоопределение> # Ядра обработки пакетов. # Список диапазонов [0, 255] worker_cores: <автоопределение> # Количество ядер обработки пакетов (на NUMA-ноду). # [0, 256] worker_cores_nr: <автоопределение> # NUMA-ноды ядер обработки пакетов. # Список диапазонов [0, 7] или `all`: # `all` - использовать все ноды. worker_nodes: <автоопределение> # Список сетевых портов. # Определяет сетевые порты, используемые обработчиком пакетов. # Настраивает пары портов, зоны портов и их порядок. # Формируется автоматически для всех обнаруженных портов, если не задан. # Если задан, должны быть перечислены все используемые порты. # # Формат: # <зона_порта> [ext|int] <индекс_пары> [0, 255] : # id_порта: # или <номер_порта> [0, 255] или <имя_порта> (строка). # # Пример: ext0: 01:00.0 int0: 01:00.1 ext1: 04:00.0 int1: 04:00.1 Похожие статьи Изоляция ядер для оптимизации производительности Graphite на отдельном сервере Troubleshooting Документация pgfailover Доступ к интерфейсу Grafana Изменение конфигурационных параметров ClickHouse Использование единого Graphite для нескольких кластеров MITIGATOR Настройка времени хранения метрик в Graphite Настройка системы для карт Mellanox (NVIDIA) Настройка эшелонированной защиты на базе MITIGATOR

Оптимизация производительности для платформ AMD

Mon, 01 Jan 0001 00:00:00 +0000

Настройка BIOS для платформ AMD EPYC и Ryzen Threadripper Перечислены основные настройки, требующие внимания. Названия настроек могут отличаться от указанных. Сверьтесь с документацией по настройке BIOS для вашей платформы. Режим одной NUMA-ноды на CPU. Разбивать один CPU на несколько нод не рекомендуется: NUMA Nodes Per Socket: NPS1 Включение Extended APIC. Рекомендуется для серверных CPU: Local APIC mode: x2APIC

Период обновления графиков инцидентов

Mon, 01 Jan 0001 00:00:00 +0000

Период обновления графиков инцидентов по умолчанию равен 60 секундам. Для удобства работы с графиками инцидентов может потребоваться изменить период их обновления: Создать файл incident.yml и поместить в него: services: backend: environment: INCIDENT_UPDATE_PERIOD: "30" Здесь 30 – значение периода обновления в секундах. В файле .env задать переменную incident.yml: COMPOSE_FILE=docker-compose.yml:docker-compose.override.yml:incident.yml Перезапустить MITIGATOR: systemctl restart mitigator Похожие статьи Graphite на отдельном сервере Документация pgfailover Доступ к интерфейсу Grafana Изменение конфигурационных параметров ClickHouse Изоляция ядер для оптимизации производительности Использование единого Graphite для нескольких кластеров MITIGATOR Настройка времени хранения метрик в Graphite Настройка системы для карт Mellanox (NVIDIA) Настройка эшелонированной защиты на базе MITIGATOR Настройки обработчика пакетов

Программируемый фильтр

Mon, 01 Jan 0001 00:00:00 +0000

Когда не хватает готовых контрмер, MITIGATOR позволяет добавить свои с помощью контрмеры «Программируемый фильтр» (BPF). Написание программ требует небольшой квалификации, но позволяет оперативно решить сложные задачи: Защита для приложений и протоколов, которые еще не поддержаны. Если известно, как работает приложение, как защитить его трафик, не требуется обращаться к разработчикам и ждать очередной версии. Более сложные фильтры, чем позволяют контрмеры ACL и REX. Например, можно анализировать опции TCP и IP, любые соотношения параметров пакетов, заголовки и содержимое одновременно и как угодно.

Репутационные списки с сервиса аналитики

Mon, 01 Jan 0001 00:00:00 +0000

Командой MITIGATOR формируются регулярно обновляемые репутационные списки IP-адресов, автономных систем и JA3-отпечатков (далее “фиды”). Фиды могут импортироваться в MITIGATOR в виде именованных списков и применяться в контрмерах и правилах маршрутизации. Для этого в качестве типа источника именованного списка следует указать Mitigator feeds и выбрать необходимый фид. Фиды недоступны для скачивания или просмотра содержимого, даже через Web-интерфейс MITIGATOR. Информация Доступ к фидам предоставляется по токену и дополнительно лицензируется. Для работы с фидами требуется MITIGATOR версии v23.06 или более поздней. Токен указывается в настройках системы в карточке «Сервер аналитики». Для получения токена следует обратиться к вашему аккаунт-менеджеру.

Руководство пользователя

Mon, 01 Jan 0001 00:00:00 +0000

Идет загрузка файла.

Управление BGP-анонсами при неактивности внешнего роутера

Mon, 01 Jan 0001 00:00:00 +0000

Для обеспечения бесперебойного прохождения трафика через MITIGATOR обычно требуется снимать BGP-анонсирование при потере связности с граничными маршрутизаторами. По умолчанию при схеме внедрения в сеть L3-router анонсирование по BGP может происходить только при разрешении на MITIGATOR router_mac граничных маршрутизаторов внешней и внутренней сетей. В случае потери связности с любым из них анонсы снимаются. Однако в некоторых случаях требуется продолжать BGP-анонсирование даже при падении граничных маршрутизаторов, для чего в файле docker-compose.yml следует указать:

Настройка эшелонированной защиты на базе MITIGATOR

Mon, 01 Jan 0001 00:00:00 +0000

Наибольшую эффективность при защите от DDoS-атак показывают схемы эшелонированной обороны, где тонкой очисткой трафика, поступающего в защищаемую сеть, занимается on-premise устройство на границе сети, а защитные механизмы на уровне вышестоящего оператора связи позволяют предотвратить переполнение канала. Постоянно включенная защита на стороне оператора связи может вызывать проблемы и оказывать негативное влияние на легитимный трафик, поэтому она должна активироваться только по необходимости. Для этого сценария требуется настроить взаимодействие между эшелонами защиты — облачную сигнализацию.