=============================================================================
ФРАГМЕНТ ДЛЯ ГЛАВЫ 4 «НАСТРОЙКА ТЕСТИРУЕМОГО УСТРОЙСТВА»
Вставляется после п. 4.2 «Конфигурация NGFW»
=============================================================================

Условные обозначения стилей:
  [H2]   — заголовок второго уровня (Heading 2)
  [H3]   — заголовок третьего уровня (Heading 3)
  [T]    — обычный текст (Normal)
  [CONS] — блок команд или листинг (Cons)
  [NOTE] — примечание в рамке (Note)
  [TBL]  — таблица
  <красным> — значение, подставляемое по месту (RGB 255, 51, 92)


-----------------------------------------------------------------------------
[H2] Формирование политики фильтрации

[T] Требуемое число правил фильтрации создается автоматически при помощи
генератора политики, входящего в комплект средств тестирования. Генератор
обращается к серверу управления по программному интерфейсу, создает сетевые
объекты, сервисы и политику заданного объема.

[T] Политика формируется из двух частей:

  • фоновые правила с действием «запретить», обеспечивающие требуемую
    нагрузку на подсистему фильтрации;
  • четыре итоговых разрешающих правила, пропускающих тестовый трафик
    генератора TRex.

[NOTE] Фоновые правила построены на адресах 192.168.0.0/16 и с тестовыми
сетями не пересекаются. Итоговые разрешающие правила размещаются в конце
политики, ниже всех фоновых, вследствие чего тестовый трафик обрабатывается
именно ими.

[H3] Состав итоговых разрешающих правил

[T] Итоговые правила создаются для двух пар тестовых сетей, соответствующих
двум парам портов генератора трафика. Для каждой пары формируется прямое и
обратное правило.

[TBL] Таблица. Итоговые разрешающие правила
+------------------------------------------+---------------+---------------+---------+---------+
| Наименование правила                      | Сеть-источник | Сеть-назнач.  | Зона-ист| Зона-нз |
+------------------------------------------+---------------+---------------+---------+---------+
| first_forward_final_app_protocol_match    | 16.0.0.0/8    | 48.0.0.0/8    | Trusted | DMZ     |
| first_reverse_final_app_protocol_match    | 48.0.0.0/8    | 16.0.0.0/8    | DMZ     | Trusted |
| second_forward_final_app_protocol_match   | 17.0.0.0/8    | 49.0.0.0/8    | Trusted | DMZ     |
| second_reverse_final_app_protocol_match   | 49.0.0.0/8    | 17.0.0.0/8    | DMZ     | Trusted |
+------------------------------------------+---------------+---------------+---------+---------+

[T] Параметры итоговых правил: действие «разрешить», логирование окончания
сессии включено, перечислены все поддерживаемые прикладные протоколы,
сервис — allow-any-any-tcp-udp (протоколы TCP и UDP, порты с 0 по 65535).
Зоны источника и назначения — Trusted и DMZ; в обратном правиле зоны
меняются местами вместе с сетями.

[NOTE] Зоны Trusted и DMZ должны быть созданы на тестируемом устройстве до
запуска генератора. Идентификаторы зон запрашиваются у сервера управления по
их наименованиям; при отсутствии любой из зон генератор завершает работу с
сообщением о том, какие зоны доступны.

[H3] Подготовка

[T] Установить зависимости генератора:

[CONS]
cd /home/ngfw/perf_test/policy_generator
sudo pip3 install -r requirements.txt --break-system-packages

[T] Файл корневого сертификата сервера управления разместить в каталоге
генератора.

[H3] Запуск генератора

[T] Генератор запускается одной командой; параметры передаются в командной
строке. Значения, выделенные цветом, приводятся в соответствие с параметрами
стенда:

[CONS]
python3 knbe_policy_generator.py \
  --host <10.1.1.23:8090> \
  --user <admin> \
  --password <пароль> \
  --ca <ca.pem> \
  --rules <10000>

[TBL] Таблица. Параметры командной строки
+------------------+--------------------+--------------------------------------------------+
| Параметр         | По умолчанию       | Назначение                                        |
+------------------+--------------------+--------------------------------------------------+
| --host           | —                  | Адрес и порт сервера управления                   |
| --user           | —                  | Имя пользователя                                  |
| --password       | —                  | Пароль                                            |
| --ca             | —                  | Путь к файлу корневого сертификата                |
| --rules          | —                  | Общее число правил, включая четыре итоговых       |
| --policy-name    | perf_test_policy   | Имя создаваемой политики                          |
| --threads        | 1                  | Число одновременных запросов при загрузке         |
| --keep-existing  | не задан           | Не удалять объекты предыдущих запусков            |
| --debug          | не задан           | Подробный протокол работы                         |
+------------------+--------------------+--------------------------------------------------+

[NOTE] Значение параметра --rules задает полное число правил в политике.
Четыре итоговых разрешающих правила входят в это число, остальные
распределяются поровну между тремя типами фоновых правил: с квалификаторами
уровня L4, с квалификаторами уровня L7 и со смешанными. Минимальное
допустимое значение — 4.

[T] Число правил задается в соответствии с испытываемой платформой согласно
таблице п. 4.2:

[CONS]
python3 knbe_policy_generator.py --host <10.1.1.23:8090> --user <admin> \
  --password <пароль> --ca <ca.pem> --rules 10000     # vKX-8, KX-100

[CONS]
python3 knbe_policy_generator.py --host <10.1.1.23:8090> --user <admin> \
  --password <пароль> --ca <ca.pem> --rules 20000     # KX-400, KX-1000, KX-3500

[NOTE] По умолчанию генератор удаляет политики и объекты, созданные
предыдущими запусками. Для сохранения ранее созданных объектов применяется
параметр --keep-existing.

[H3] Контроль результата

[T] По завершении работы генератор выводит число загруженных правил и время
загрузки. Созданную политику следует проверить в веб-интерфейсе сервера
управления:

  • имя политики соответствует заданному параметром --policy-name;
  • общее число правил соответствует заданному параметром --rules;
  • четыре правила с наименованиями, оканчивающимися на
    final_app_protocol_match, расположены в конце списка правил;
  • действие этих правил — «разрешить».

[T] После проверки политика назначается тестируемому устройству, и
выполняется контроль прохождения тестового трафика согласно п. 6.1.

[NOTE] Загрузка 20 000 правил занимает продолжительное время. Для ускорения
допускается увеличить число одновременных запросов параметром --threads,
контролируя при этом отсутствие ошибок в протоколе работы генератора.


=============================================================================
СПРАВОЧНО (в документ не включается)
=============================================================================

Состав каталога policy_generator:

  knbe_policy_generator.py   точка входа, разбор командной строки
  policy_generator_api.py    основной генератор: объекты, политика, правила
  rule_generator.py          формирование правил, перечень 27 протоколов
  models.py                  структуры данных и преобразование в формат API
  object_manager.py          загрузка сетевых объектов, сервисов, профилей
  policy_manager.py          создание, публикация и удаление политик
  network_generator.py       генерация адресов фоновых объектов
  services_generator.py      генерация сервисов фоновых правил
  api_client.py              клиент программного интерфейса
  requirements.txt           зависимости

Проверка распределения правил:

  --rules 4      ->      0 L4 /     0 L7 /     0 L4L7 + 4 итоговых
  --rules 10000  ->   3332 L4 /  3332 L7 /  3332 L4L7 + 4 итоговых
  --rules 20000  ->   6666 L4 /  6665 L7 /  6665 L4L7 + 4 итоговых

Создаваемые объекты и префиксы наименований:

  host-*                  сетевые объекты фоновых правил (192.168.0.0/16)
  service-*               сервисы фоновых правил
  range_client_16         16.0.0.0 - 16.255.255.255
  range_server_48         48.0.0.0 - 48.255.255.255
  range_client_17         17.0.0.0 - 17.255.255.255
  range_server_49         49.0.0.0 - 49.255.255.255
  allow-any-any-tcp-udp   сервис итоговых правил

Требования к тестируемому устройству:

  зоны Trusted и DMZ должны существовать до запуска генератора;
  зоны Trusted и Untrusted используются фоновыми правилами.

Порядок правил в политике: правила загружаются через метод insert-first,
поэтому загруженные первыми оказываются в конце политики. Итоговые
разрешающие правила отправляются раньше фоновых.
