<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Knowledge Base on BIFIT Mitigator</title>
    <link>https://docs.mitigator.ru/v26.04/en/kb/</link>
    <description>Recent content in Knowledge Base on BIFIT Mitigator</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en</language><atom:link href="https://docs.mitigator.ru/v26.04/en/kb/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Ways to Integrate MITIGATOR into the Network</title>
      <link>https://docs.mitigator.ru/v26.04/en/kb/deploy/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://docs.mitigator.ru/v26.04/en/kb/deploy/</guid>
      <description>Terminology and methods for implementing the MITIGATOR DDoS protection system into the network.
External and Internal Networks Logically MITIGATOR is connected to two networks:
External network (external) – the network from which the traffic that needs cleaning comes; Internal network (internal) – the network in which the protected resources are located. Traffic from the external network – traffic coming to MITIGATOR from the external network. Consists of attack traffic and legitimate traffic.</description>
    </item>
    <item>
      <title>BGP Interaction</title>
      <link>https://docs.mitigator.ru/v26.04/en/kb/bgp/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://docs.mitigator.ru/v26.04/en/kb/bgp/</guid>
      <description>Info Update coming soon.
MITIGATOR supports various BGP communication scenarios. Each cluster instance can function as an independent BGP speaker, announce prefixes and send and receive FlowSpec rules.
Memo Information about all aspects of BGP interaction settings is given below.
Local BGP Parameters Local BGP parameters should be defined for each cluster instance and each instance must be given permission to establish BGP connections with its BGP neighbors.
BGP Neighbors MITIGATOR instances can establish BGP connections with other network devices defined in the system as BGP neighbors.</description>
    </item>
    <item>
      <title>MITIGATOR Protection Quick Setup</title>
      <link>https://docs.mitigator.ru/v26.04/en/kb/quick-setup/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://docs.mitigator.ru/v26.04/en/kb/quick-setup/</guid>
      <description>The materials in this article are intended to facilitate understanding of the protection organizing basic principles using MITIGATOR. Below is an example of setting up the system in the first iteration.
First, all packets are processed in &amp;ldquo;General Protection&amp;rdquo;, then 5-tuple routing rules distribute traffic to protection policies, and after the policies, the traffic returns to &amp;ldquo;General Protection&amp;rdquo; for the remaining countermeasures.
Processing of back traffic from the protected resource is not considered in this article.</description>
    </item>
    <item>
      <title>BGP Signaling</title>
      <link>https://docs.mitigator.ru/v26.04/en/kb/bgp-signaling/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://docs.mitigator.ru/v26.04/en/kb/bgp-signaling/</guid>
      <description>The article describes how MITIGATOR uses BGP for signaling upstream telecom operators or security service providers (MSSP).
Signaling Goals When MITIGATOR works as a perimeter protection against DDoS attacks, it can independently mitigate an attack up to total incoming bandwidth. To prevent the inbound channels from being saturated, coarse filtering can be enabled at upstream telecom operators or protection service providers.
MSSP use REST API, BGP, BGP FlowSpec and closed proprietary protocols for clients&amp;rsquo; signaling.</description>
    </item>
    <item>
      <title>Checklist for Initial System Setup</title>
      <link>https://docs.mitigator.ru/v26.04/en/kb/system-checklist/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://docs.mitigator.ru/v26.04/en/kb/system-checklist/</guid>
      <description>List of steps Set up network integration. Specify a license key and set limits. Set up interaction via BGP. Upload GeoIP databases into the system. Set up delivery channels for system event notifications. Set up notifications via syslog. Enable protection. (Optional) Upload logos and background images for various interface themes. (Optional) Select the interface theme type and graph display style. Details 1. Set up network integration. The configuration is performed independently for each instance of the system and is based on the composition of the network infrastructure and the tasks to be solved.</description>
    </item>
    <item>
      <title>Checklist for Initial Configuration of the Protection Policy</title>
      <link>https://docs.mitigator.ru/v26.04/en/kb/policy-checklist/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://docs.mitigator.ru/v26.04/en/kb/policy-checklist/</guid>
      <description>List of steps Make sure the routing rules for the policy are set. Configure the policy to display only the necessary countermeasures. Set up countermeasures. Set up automatic packet capture. Set up autodetection. (Optional) Check the effect on legitimate traffic via the test mode. Enable protection policy. (Optional) Configure the log analyzer. (Optional) Pin countermeasure graphs. Details 1. Make sure the routing rules for the policy are set. Make sure that the routing rules are set for the policy on the &amp;ldquo;Policy Setup&amp;rdquo; tab of the &amp;ldquo;Protection policy&amp;rdquo; page.</description>
    </item>
    <item>
      <title>Core Isolation for Performance Optimization</title>
      <link>https://docs.mitigator.ru/v26.04/en/kb/isolcpus/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://docs.mitigator.ru/v26.04/en/kb/isolcpus/</guid>
      <description>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.</description>
    </item>
    <item>
      <title>Hardware Bypass</title>
      <link>https://docs.mitigator.ru/v26.04/en/kb/bypass/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://docs.mitigator.ru/v26.04/en/kb/bypass/</guid>
      <description>MITIGATOR supports hardware bypass of Silicom and LR-Link adapters.
Tested Silicom adapters:
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.</description>
    </item>
    <item>
      <title>Configuring Tiered Protection with MITIGATOR</title>
      <link>https://docs.mitigator.ru/v26.04/en/kb/echelon/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://docs.mitigator.ru/v26.04/en/kb/echelon/</guid>
      <description>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.</description>
    </item>
    <item>
      <title>Graphs</title>
      <link>https://docs.mitigator.ru/v26.04/en/kb/graphite/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://docs.mitigator.ru/v26.04/en/kb/graphite/</guid>
      <description>In MITIGATOR for working with graphs are used: ClickHouse, Graphite, Grafana, Carbon, CarbonAPI.
All of the above have the ability to be fine-tuned depending on requirements.
Articles describing various set up aspects:
Access to the Grafana Interface Graphite on a Separate Server Setting the Storage Time for Metrics in Graphite Using a Single Graphite for Multiple MITIGATOR Clusters </description>
    </item>
    <item>
      <title>Incident Chart Update Period</title>
      <link>https://docs.mitigator.ru/v26.04/en/kb/incidents/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://docs.mitigator.ru/v26.04/en/kb/incidents/</guid>
      <description>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: &amp;#34;30&amp;#34; 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 </description>
    </item>
    <item>
      <title>Managing BGP Announcements When the External Router is Inactive</title>
      <link>https://docs.mitigator.ru/v26.04/en/kb/bgp-state/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://docs.mitigator.ru/v26.04/en/kb/bgp-state/</guid>
      <description>To ensure uninterrupted traffic through the MITIGATOR, it is usually necessary to remove the BGP announcements when connectivity with bordering routers is lost.\
By default, with the L3-router network deployment scheme, announcement via BGP can only occur if the bordering routers of the external and internal networks are allowed on MITIGATOR router_mac. In case of loss of connectivity with any of them, announcements are removed.
However, in some cases it is required to continue BGP announcements even if bordering routers fail, for which following should be specified in the docker-compose.</description>
    </item>
    <item>
      <title>Packet Processor Settings</title>
      <link>https://docs.mitigator.ru/v26.04/en/kb/dataplane.conf/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://docs.mitigator.ru/v26.04/en/kb/dataplane.conf/</guid>
      <description>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.</description>
    </item>
    <item>
      <title>Performance Optimization for AMD Platforms</title>
      <link>https://docs.mitigator.ru/v26.04/en/kb/amd/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://docs.mitigator.ru/v26.04/en/kb/amd/</guid>
      <description>BIOS Setup for AMD EPYC and Ryzen Threadripper Platforms Mentioned only essential options that require attention. Option names may differ from listed. Refer to the BIOS configuration manual for your platform.
Set one NUMA node per CPU. Use of multiple nodes per CPU is not recommended:
NUMA Nodes Per Socket: NPS1
Enable Extended APIC. Recommended for server CPUs:
Local APIC mode: x2APIC
Virtualization support:
SVM: Enabled IOMMU: Enabled
Maximum CPU performance mode:</description>
    </item>
    <item>
      <title>Pgfailover Documentation</title>
      <link>https://docs.mitigator.ru/v26.04/en/kb/pgfailover/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://docs.mitigator.ru/v26.04/en/kb/pgfailover/</guid>
      <description>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=&amp;#34;:5432&amp;#34; export PGFAILOVER_SERVERS=&amp;#34;postgres://repuser@pg0.example.com/database?sslmode=disable&amp;amp;connect_timeout=5 postgres://repuser@pg1.example.com/database?sslmode=disable&amp;amp;connect_timeout=5&amp;#34; ./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).</description>
    </item>
    <item>
      <title>Programmable Filter</title>
      <link>https://docs.mitigator.ru/v26.04/en/kb/bpf/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://docs.mitigator.ru/v26.04/en/kb/bpf/</guid>
      <description>&amp;ldquo;Programmable filter&amp;rdquo; (BPF) may be used to create custom countermeasures if the existing ones are not sufficient.
Writing programs requires basic programming skills, but allows to solve complex tasks quickly:
Protection for applications and protocols that are not supported yet. There’s no need to contact developers and wait for the next release if one understand how an application works and how to protect its traffic.
More complex filters than the ACL and REX countermeasures allow.</description>
    </item>
    <item>
      <title>Reputational Lists From the Analytics Service</title>
      <link>https://docs.mitigator.ru/v26.04/en/kb/ss-feeds/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://docs.mitigator.ru/v26.04/en/kb/ss-feeds/</guid>
      <description>The MITIGATOR team generates regularly updated reputational lists of IP addresses, autonomous systems and JA3 fingerprints (hereinafter referred to as “feeds”).
Feeds can be imported into MITIGATOR as named lists and used in countermeasures and routing rules. To do this you need to specify Mitigator feeds as a source type. To do this, specify Mitigator feeds as the named list source type and select the required feed.
Feeds cannot be downloaded or viewed, even through the MITIGATOR Web interface.</description>
    </item>
    <item>
      <title>System Setup for Mellanox (NVIDIA) Adapters</title>
      <link>https://docs.mitigator.ru/v26.04/en/kb/mellanox/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://docs.mitigator.ru/v26.04/en/kb/mellanox/</guid>
      <description>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.</description>
    </item>
  </channel>
</rss>