<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Deployment on BIFIT Mitigator</title>
    <link>https://docs.mitigator.ru/v26.04/en/tags/deployment/</link>
    <description>Recent content in Deployment on BIFIT Mitigator</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en</language><atom:link href="https://docs.mitigator.ru/v26.04/en/tags/deployment/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>Shared Non-Redundant Storage</title>
      <link>https://docs.mitigator.ru/v26.04/en/install/multi/workers/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://docs.mitigator.ru/v26.04/en/install/multi/workers/</guid>
      <description>The following steps assume that an instance of MITIGATOR has already been installed. Otherwise, perform the installation using one of the following methods.
Before setting up a cluster, you must set up a virtual network (VPN). It needs network connectivity between instances to work. Detailed information on setting up and the necessary access are described at the link.
Common databases for all MITIGATOR instances are physically stored on the server of one of them.</description>
    </item>
    <item>
      <title>Internal Fault-Tolerant Storage</title>
      <link>https://docs.mitigator.ru/v26.04/en/install/multi/failover/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://docs.mitigator.ru/v26.04/en/install/multi/failover/</guid>
      <description>The following steps assume that an instance of MITIGATOR has already been installed. Otherwise, perform installation using one of the following methods.
Before configuring a cluster, you must configure Virtual network(VPN). It needs network connectivity between instances to work. Detailed information on setting up and the necessary access are described at the link.
For fault tolerance, synchronized copies of the database must be physically stored on different servers (replicated). With this scheme, database replicas are stored on the same servers where MITIGATOR instances are running.</description>
    </item>
    <item>
      <title>External Fault-Tolerant Storage</title>
      <link>https://docs.mitigator.ru/v26.04/en/install/multi/custom/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://docs.mitigator.ru/v26.04/en/install/multi/custom/</guid>
      <description>The following steps assume that an instance of MITIGATOR has already been installed. Otherwise, install it using one of the following methods first.
Before configuring a cluster, you must configure virtual network (VPN). It needs network connectivity between instances to work. Detailed information on setting up and necessary accesses are described by the link.
This deployment scheme implies the physical storage of databases common to all MITIGATOR instances on an external server.</description>
    </item>
    <item>
      <title>MITIGATOR in Cluster Mode</title>
      <link>https://docs.mitigator.ru/v26.04/en/install/multi/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://docs.mitigator.ru/v26.04/en/install/multi/</guid>
      <description>In cluster mode, several instances of the MITIGATOR system use common databases and are centrally managed. By adding additional instances, the system allows unlimited scaling. Cluster mode allows you to process traffic independently on each instance, but manage them from a single interface. In the event of a planned or emergency shutdown of any instance, the ability to manage the rest remains.
Deployment Virtual network (VPN) is configured between instances. It needs network connectivity between instances to work.</description>
    </item>
    <item>
      <title>Hybrid Deployment Schemes</title>
      <link>https://docs.mitigator.ru/v26.04/en/install/multi/hybrid/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://docs.mitigator.ru/v26.04/en/install/multi/hybrid/</guid>
      <description>deployment schemes can be combined when building a cluster.
Example: Failover Storage with Additional Filtering Nodes With this implementation scheme, database copies are stored on different servers (replicated), but the number of database replicas is less than the number of MITIGATOR instances in the cluster. Some instances access remote databases via TCP ports: 8888, 2003, 3080, 5432. In this example, the graphite and logan are included as external modules.
For correct system operation all packet processors must have the same amount of system resources available.</description>
    </item>
    <item>
      <title>Access to the Grafana Interface</title>
      <link>https://docs.mitigator.ru/v26.04/en/kb/graphite/grafana/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://docs.mitigator.ru/v26.04/en/kb/graphite/grafana/</guid>
      <description>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.</description>
    </item>
    <item>
      <title>Graphite on a Separate Server</title>
      <link>https://docs.mitigator.ru/v26.04/en/kb/graphite/grafbase/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://docs.mitigator.ru/v26.04/en/kb/graphite/grafbase/</guid>
      <description>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).</description>
    </item>
    <item>
      <title>Изменение конфигурационных параметров ClickHouse</title>
      <link>https://docs.mitigator.ru/v26.04/en/kb/graphite/clickhouse-conf/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://docs.mitigator.ru/v26.04/en/kb/graphite/clickhouse-conf/</guid>
      <description>Конфигурационные параметры ClickHouse делятся на пользовательские и серверные. Узнать про структуру файлов и их расположение можно в официальной документации.
При конфигурации модуля хранения метрик в MITIGATOR нужно учитывать следующее:
корневой элемент конфигурационных файлов — &amp;lt;yandex&amp;gt; пользовательские файлы конфигураций следует размещать в /etc/clickhouse-server/users.d внутри контейнера clickhouse файлы конфигурации сервера следует размещать в /etc/clickhouse-server/config.dвнутри контейнера clickhouse Как сконфигурировать ClickHouse на примере ограничения используемой оперативной памяти сервером до 50Гб:
Создать файл custom.xml с необходимыми параметрами</description>
    </item>
    <item>
      <title>Подключение внешней Grafana</title>
      <link>https://docs.mitigator.ru/v26.04/en/kb/graphite/ext-grafana/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://docs.mitigator.ru/v26.04/en/kb/graphite/ext-grafana/</guid>
      <description>Чтобы внешняя Grafana могла получать данные с Graphite нужно пробросить порт 3080 из контейнера, для чего:
Cоздать, либо дополнить docker-compose.override.yml следующим: services: gateway: ports: - &amp;#34;13080:3080&amp;#34; Перезапустить MITIGATOR: docker-compose down &amp;amp;&amp;amp; docker-compose up -d В Web-интерфейсе Grafana добавить источник данных: Выбрать тип Graphite и указать внешний адрес: Related Content Graphite on a Separate Server Access to the Grafana Interface Setting the Storage Time for Metrics in Graphite Using a Single Graphite for Multiple MITIGATOR Clusters Exporting Metrics to Prometheus Изменение конфигурационных параметров ClickHouse Challenge-response Authentication Module for HTTP/HTTPS Configuration Change Configuring Tiered Protection with MITIGATOR Core Isolation for Performance Optimization </description>
    </item>
    <item>
      <title>Challenge-response Authentication Module for HTTP/HTTPS</title>
      <link>https://docs.mitigator.ru/v26.04/en/integrate/web-challenger/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://docs.mitigator.ru/v26.04/en/integrate/web-challenger/</guid>
      <description>Web Challenger (WebC) is a Docker container containing NGINX and an HTTP/HTTPS request processing module that works in tandem with the HCA countermeasure in MITIGATOR.
Possibilities The HCA countermeasure redirects HTTP/HTTPS requests from unauthenticated IP addresses to WebC, where the sender is verified. If the verification is successful, the source IP address is added to the HCA&amp;rsquo;s authenticated table. HCA can also work with third-party L7 protection devices.
Multiple packet processors can work with one WebC when working in a cluster.</description>
    </item>
    <item>
      <title>Setting the Storage Time for Metrics in Graphite</title>
      <link>https://docs.mitigator.ru/v26.04/en/kb/graphite/retention/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://docs.mitigator.ru/v26.04/en/kb/graphite/retention/</guid>
      <description>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.</description>
    </item>
    <item>
      <title>TCP Protection with ISN Synchronization</title>
      <link>https://docs.mitigator.ru/v26.04/en/integrate/syncookie/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://docs.mitigator.ru/v26.04/en/integrate/syncookie/</guid>
      <description>MITIGATOR has a TCP protection mode with ISN synchronization, in which after checking the client, the connection is not interrupted, filtering is transparent and convenient. To do this, you need to install a kernel module on the protected server, that will provide the necessary information, and a synchronization agent that will be polled by the MITIGATOR system.
Protection mode with ISN synchronization is supported in countermeasures TCP, MINE, ATLS, DNS and BPF.</description>
    </item>
    <item>
      <title>Using a Single Graphite for Multiple MITIGATOR Clusters</title>
      <link>https://docs.mitigator.ru/v26.04/en/kb/graphite/onegraphite/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://docs.mitigator.ru/v26.04/en/kb/graphite/onegraphite/</guid>
      <description>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.
Create a directory for the services:</description>
    </item>
    <item>
      <title>Web Server Log Analyzer</title>
      <link>https://docs.mitigator.ru/v26.04/en/integrate/log-analyzer/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://docs.mitigator.ru/v26.04/en/integrate/log-analyzer/</guid>
      <description>Info The log analysis functionality is additionally licensed.
Logan is a MITIGATOR functionality for analyzing logs of a protected Web server (HTTP, HTTPS), detecting anomalies and attacking addresses. Protected servers send their logs to the Logan using syslog RFC 3164 (UDP, TCP).
Logan can be located on the same server as the rest of the MITIGATOR, or separately.
Logan on MITIGATOR Instance The following steps assume that an instance of MITIGATOR has already been installed.</description>
    </item>
  </channel>
</rss>