configuration :: Tag :: BIFIT Mitigator

Configuration Change

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

Apply changes to any configuration files in /srv/mitigator: systemctl reload mitigator This may restart the relevant MITIGATOR components. After changing network ports (editing file /etc/systemd/system/mitigator.service.d/nics.conf) run: systemctl daemon-reload && \ systemctl restart mitigator This will turn the MITIGATOR completely off and on again. Related Content Access to the Grafana Interface Administrator Tasks Backup Configuring Tiered Protection with MITIGATOR Core Isolation for Performance Optimization Graphite on a Separate Server Incident Chart Update Period Packet Processor Settings Pgfailover Documentation Previous Version Restore

Core Isolation for Performance Optimization

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

By default, the CPU cores that work with network ports are also used by other subsystems. This can degrade performance and cause Input Errors pps/bps spikes on Port extX/intX graphs. You can take some of the load off these cores by preventing non-critical subsystems from running on them. To do so: Specify isolation of the packet processor cores in the core options through the isolcpus=... and rcu_nocbs=... parameters. It is also recommended to add mitigations=off to disable core security patches.

Access to the Grafana Interface

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

MITIGATOR comes with Grafana which can be used to create custom dashboards. See the Grafana documentation to understand exactly how to do this. To gain access to the Grafana web interface, you need to set up the service, which is disabled by default. You can temporarily do this with the following command: docker-compose up -d --scale grafana=1 grafana To enable grafana permanently, you need to change scale from 0 to 1 in docker-compose.yml.

Incident Chart Update Period

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

The default update period for incident graphs is 60 seconds. For the convenience of working with incident charts, you may need to change the period for their update: Create a file incident.yml and put following in it: services: backend: environment: INCIDENT_UPDATE_PERIOD: "30" Where 30 is the update period value in seconds. In the .env file, set the incident.yml variable: COMPOSE_FILE=docker-compose.yml:docker-compose.override.yml:incident.yml Restart MITIGATOR: systemctl restart mitigator Related Content Access to the Grafana Interface Configuration Change Configuring Tiered Protection with MITIGATOR Core Isolation for Performance Optimization Graphite on a Separate Server Packet Processor Settings Pgfailover Documentation Setting the Storage Time for Metrics in Graphite System Setup for Mellanox (NVIDIA) Adapters Using a Single Graphite for Multiple MITIGATOR Clusters

Packet Processor Settings

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

The packet processor is configured through the dataplane.conf file. Put the file into the MITIGATOR working directory and set the required parameters. Other parameters will have the default values. Comments are specified with #, // or /* */. Available parameters (with default values): # Control socket bind address. control_address: 0.0.0.0 # Control socket TCP port. # [1, 65535] control_port: 8888 # Debug control socket TCP port. # [1, 65535] debug_port: 8889 # gRPC control socket TCP port. # [1, 65535] grpc_port: 8890 # Sync/web-challenger control socket UDP port. # [1, 65535] sync_udp_port: 8891 # Number of control socket processing threads. # [1, 1000] control_threads: 20 # Control socket request timeout (seconds). # [1, 10000] control_request_timeout: 15 # Control socket request/response content timeout (seconds). # [1, 10000] control_content_timeout: 300 # Enable control socket event log. control_log: false # Control socket event log message length limit. # [0, 100000] control_log_limit: 100 # Number of sync task threads. # [1, 1000] sync_threads: 10 # Enable sync task log. sync_log: false # Enable additional cores for sync/web-challenger control socket. use_extra_service_cores: false # MAC address of emitted challenge packets. challenge_mac: # VLAN ID of emitted challenge packets. # [1, 4095] challenge_vlan_id: # LACP system ID. # Set to local MAC address if not specified. lacp_system_id: # LACP port operational key. # [0, 65535] lacp_oper_key: 1000 # MAC resolver request retransmit delay (seconds). # [1, 10000] mac_retransmit_time: 5 # MAC resolver entry validity period (seconds). # [1, 10000] mac_reachable_time: 30 # MAC resolver stale entry cleanup timeout (seconds). # [1, 10000] mac_stale_time: 60 # Maximum allowed number of IPv4 policies. # [1, 60000] max_policies: 100 # Maximum allowed number of IPv6 policies. # [1, 60000] max_policies6: 100 # Maximum allowed SIMD instruction bitwidth. # [0, 512] max_simd_bitwidth: # Size of network packet memory pool (per NUMA node). # [0, 2^31] packet_mempool_size: # Enable deferred start of packet processing. # Starts ports only after full application initialization. # Prevents network traffic loops. deferred_start: false # Enable special processing mode of dual-port NICs (for `port_direct_mode: true`). # Process each port on a separate set of cores. # Improves performance for 100G or larger ports when both ports are used. dual_port_nic: false # RX checksum offloading policy: # `false` - do not request the offloading, force software checksum verification. # `true` - enable the offloading for all ports if supported. # Enables offloading only for physical ports if not specified. port_checksum_offload: # Processing mode of network port I/O queues: # `false` - process port I/O queues on dedicated cores, # recommended for low speeds. # `true` - process port I/O queues on worker cores, # recommended for 100G or higher speeds. port_direct_mode: # Network port link speed (Mb/s). # Disables speed autonegotiation if enabled. # [100|1000|10000|...] or [100M|1G|10G|...] port_link_speed: # Enable link state propagation of port pairs. port_lsp: false # Network port MTU. # [0, 65535] port_mtu: 1500 # Size of packet ring buffers between network port I/O queue processing cores # and worker cores (for `port_direct_mode: false`). # [0, 2^20] port_ring_size: 8192 # Number of network port RX descriptors. # [0, 65535] port_rx_desc: # Number of network port TX descriptors. # [0, 65535] port_tx_desc: # Maximum number of retry attempts of network port packet TX. # [0, 2^31] port_tx_retries: 128 # Network port I/O queue processing cores. # Range list [0, 255] port_cores: # Number of network port I/O queue processing cores (per NUMA node). # [0, 256] port_cores_nr: # NUMA nodes of network port I/O queue processing cores. # Range list [0, 7] or `all`: # `all` - use all nodes. port_nodes: # Worker cores. # Range list [0, 255] worker_cores: # Number of worker cores (per NUMA node). # [0, 256] worker_cores_nr: # Worker core NUMA nodes. # Range list [0, 7] or `all`: # `all` - use all nodes. worker_nodes: # Network port list. # Defines network ports used by packet processor. # Configures port pairs, port zones and their order. # Auto-configured for all detected ports if not specified. # If specified, all used ports must be listed. # # Format: # [ext|int] [0, 255] : # port_id: # or [0, 255] or (string). # # Example: ext0: 01:00.0 int0: 01:00.1 ext1: 04:00.0 int1: 04:00.1 Related Content Core Isolation for Performance Optimization Access to the Grafana Interface Configuration Change Configuring Tiered Protection with MITIGATOR Graphite on a Separate Server Incident Chart Update Period MITIGATOR Installation Pgfailover Documentation Setting the Storage Time for Metrics in Graphite System Setup for Mellanox (NVIDIA) Adapters

System Setup for Mellanox (NVIDIA) Adapters

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

System preparation Working with Mellanox (NVIDIA) cards requires the latest driver and device firmware NVIDIA MLNX_OFED. Using the provided link select the latest version of MLNX_OFED for the required distribution of the operating system in the table Current Versions of the Download section. Select the closest version of the OS if the required version is missing. Skip MLNX_OFED installation if the required OS is missing in the list. Tested to work on Debian 10+ and Ubuntu 20.04+.

Graphite on a Separate Server

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

Moving Graphite to a separate server allows you to split the load between two servers. Until the metrics archive is transferred, only new graphs can be viewed in the MITIGATOR interface. Further in the text Server1 is the server with MITIGATOR, Server2 is the server to which the transfer is being performed. It is assumed that Server2 already has Docker and docker-compose installed and has a way to deliver the filebase from Server1 to Server2 (the amount of data can be more than 100 GB depending on the number of policies).

Изменение конфигурационных параметров ClickHouse

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

Конфигурационные параметры ClickHouse делятся на пользовательские и серверные. Узнать про структуру файлов и их расположение можно в официальной документации. При конфигурации модуля хранения метрик в MITIGATOR нужно учитывать следующее: корневой элемент конфигурационных файлов — пользовательские файлы конфигураций следует размещать в /etc/clickhouse-server/users.d внутри контейнера clickhouse файлы конфигурации сервера следует размещать в /etc/clickhouse-server/config.dвнутри контейнера clickhouse Как сконфигурировать ClickHouse на примере ограничения используемой оперативной памяти сервером до 50Гб: Создать файл custom.xml с необходимыми параметрами 50000000000 Создать либо дополнить docker-compose.override.yml

Подключение внешней Grafana

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

Чтобы внешняя Grafana могла получать данные с Graphite, нужно пробросить порт 3080 из контейнера, для чего: Cоздать, либо дополнить docker-compose.override.yml следующим: services: gateway: ports: - "13080:3080" Перезапустить MITIGATOR: docker-compose down && docker-compose up -d В Web-интерфейсе Grafana добавить источник данных: Выбрать тип Graphite и указать внешний адрес:

Setting the Storage Time for Metrics in Graphite

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

MITIGATOR stores graph data in Graphite-ClickHouse. Fresh data is stored with a smaller sparsity, then thinned out: Term Sparcity Less than a day 5 seconds day to week 10 seconds week to month 1 minute month to 145 days 5 minutes Over 145 days 10 minutes The retention times are not cumulative, i.e. data for the last day of the last week is stored at a 5 second spacing, and the next 6 days (not 7) are stored at a 10 second spacing. Unlike the standard Graphite storage, ClickHouse continues to store the metrics with the highest sparsity given and beyond the configured time limit (with default settings after 145 days).

Configuring Tiered Protection with MITIGATOR

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

The most effective approach to DDoS protection is a tiered defense architecture, in which surgical filtering of traffic entering the protected network is performed by an on-premise device at the network border, while mitigation mechanisms at the upstream telecom operator level prevent the channel from being saturated. Always on protection at the upstream telecom operator side can cause problems and negatively affect legitimate traffic, so it should be activated only when necessary. For this scenario it is needed to configure interaction between the defense layers - cloud protection.

Pgfailover Documentation

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

pgfailover monitors the state of a PostgreSQL cluster and acts as a TCP proxy for clients, directing them to the current Primary. When the Primary changes, pgfailover terminates client connections, and they must reconnect. Connection parameters are specified via environment variables with the PGFAILOVER_ prefix: 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 The server role (Primary/Standby) is checked using pg_is_in_recovery(), by default every 5 seconds (PGFAILOVER_INTERVAL), with the number of connection attempts controlled by the PGFAILOVER_ATTEMPTS environment variable (default: 1).

Using a Single Graphite for Multiple MITIGATOR Clusters

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

Using a single Graphite for several MITIGATOR instances makes it possible to reduce the load on the computing resources of traffic processing complexes, simplify administration and set up complex monitoring. Set up The setup is similar to migration of Graphite to a separate server. If you have a host with Graphite configured, you must skip to the Configuring MITIGATOR to work with External Shared Graphite step.