Настройка устройства
 
Общие настройки

Раздел Общие настройки определяет базовые установки UserGate NGFW:

Наименование

Описание

Часовой пояс

Часовой пояс, соответствующий вашему местоположению. Часовой пояс используется в расписаниях, применяемых в правилах, а также для корректного отображения времени и даты в отчетах, журналах и т.п.

Язык интерфейса по умолчанию

Язык, который будет использоваться по умолчанию в консоли.

Режим аутентификации веб-консоли

Способ аутентификации пользователя (администратора) при входе в веб-консоль управления. Возможны следующие варианты:

  • По имени и паролю. Администратор должен ввести имя и пароль для получения доступа к веб-консоли.

  • По X.509-сертификату. Для аутентификации по сертификату необходимо иметь сертификат пользователя, подписанный сертификатом удостоверяющего центра веб-консоли и установленный в браузер. При включении этого режима аутентификации режим аутентификации по имени и паролю отключается. Вернуть режим аутентификации по имени и паролю можно с помощью команд CLI.

  • Профиль сертификата пользователя. Аутентификации посредством сертификатов (PKI) использует профиль пользовательского сертификата, это позволяет управлять сертификатами для обеспечения безопасности и подтверждения подлинности в сетевых соединениях.

Профиль SSL для веб-консоли

Выбор профиля SSL для построения защищенного канала доступа к веб-консоли. Подробно о профилях SSL смотрите в главе Профили SSL.

Профиль SSL для страниц блокировки/авторизации

Выбор профиля SSL для построения защищенного канала для отображения страниц блокировки доступа к веб-ресурсам и страницы авторизации Captive-портала. Подробно о профилях SSL смотрите в главе Профили SSL.

Таймер автоматического закрытия сессии (мин.)

Настройка таймера автоматического закрытия сессии в случае отстуствия активности администратора в веб-консоли.

Профиль SSL конечного устройства

Выбор профиля SSL для построения защищенного канала общения NGFW и конечных устройств UserGate Client. Подробно о профилях SSL смотрите в главе Профили SSL.

Сертификат конечного устройства

Сертификат, который будет использоваться для построения защищённого канала связи между NGFW и конечными устройствами UserGate Client.

Важно! Конечные устройства запоминают сертификат, поэтому при изменении необходимо распространить корневой сертификат удостоверяющего центра (Root CA) на подключенные конечные устройства; сертификат должен быть установлен в хранилище доверенных корневых центров сертификации локального компьютера.

Настройка времени сервера

Настройка параметров установки точного времени.

  • Использовать NTP — использовать сервера NTP из указанного списка для синхронизации времени.

  • Основной сервер NTP — адрес основного сервера точного времени. Значение по умолчанию — pool.ntp.org.

  • Запасной сервер NTP — адрес запасного сервера точного времени.

  • Время на сервере — позволяет установить время на сервере. Время должно быть указано в часовом поясе UTC.

Модули

Позволяет настроить модули NGFW:

  • HTTP(S)-прокси порт — позволяет указать нестандартный (дополнительный) номер порта, который будет использоваться для подключения к встроенному прокси-серверу. По умолчанию используется порт TCP 8090; при изменении порт продолжает функционировать.

    Важно! Нельзя использовать следующие порты, поскольку они используются внутренними сервисами NGFW: 2200, 8001, 4369, 9000-9100.

  • Домен auth captive-портала — служебный домен, который используется NGFW при авторизации пользователей через Captive-портал. Необходимо, чтобы пользователи могли резолвить указанный здесь домен в IP-адрес интерфейса UserGate, к которому они подключены. Если в качестве DNS-сервера у пользователей указан IP-адрес NGFW, то разрешение адресов (resolving) настроено автоматически. По умолчанию используется имя auth.captive, которое может быть изменено на другое доменное имя, принятое в организации.

  • Домен logout captive-портала — служебный домен, который используется пользователями NGFW для окончания сессии (logout). Необходимо, чтобы пользователи могли резолвить указанный здесь домен в IP-адрес интерфейса NGFW, к которому они подключены. Если в качестве DNS-сервера у пользователей указан IP-адрес NGFW, то разрешение адресов (resolving) настроено автоматически. По умолчанию используется имя logout.captive, которое может быть изменено на другое доменное имя, принятое в организации.

  • Домен страницы блокировки — служебный домен, который используется для отображения страницы блокировки пользователям. Необходимо, чтобы пользователи могли резолвить указанный здесь домен в IP-адрес интерфейса NGFW, к которому они подключены. Если в качестве DNS-сервера у пользователей указан IP-адрес NGFW, то резолвинг настроен автоматически. По умолчанию используется имя block.captive, которое может быть изменено на другое доменное имя, принятое в организации.

  • FTP поверх HTTP — включение или отключение модуля, позволяющего получать доступ к содержимому FTP-серверов из пользовательского браузера.

    Требуется явное указание прокси-сервера для протокола FTP в браузере пользователя.

    Администратор может ограничивать доступ к ресурсам FTP с помощь правил контентной фильтрации (только по условиям Пользователи и URL).

  • FTP поверх HTTP домен — служебный домен, который используется для предоставления пользователям сервиса FTP поверх HTTP. Необходимо, чтобы пользователи могли резолвить указанный здесь домен в IP-адрес интерфейса NGFW, к которому они подключены. Если в качестве DNS-сервера у пользователей указан IP-адрес сервера UserGate, то резолвинг настроен автоматически. По умолчанию используется имя ftpclient.captive, которое может быть изменено на другое доменное имя, принятое в организации.

  • Зона для инспектируемых туннелей — включение/выключение модуля инспектирования туннелей и указание зоны для их инспектирования.

  • Пароль агентов терминального сервиса — настройка пароля для подключения агентов авторизации терминальных серверов.

  • Настройка LLDP — настройка использования протокола канального уровня Link Layer Discovery Protocol (LLDP), который позволяет сетевому оборудованию, работающему в локальной сети, оповещать устройства о своём существовании, передавать им свои характеристики, а также получать от них аналогичную информацию. При настройке необходимо задать значения:

    • Transmit delay — задержка передачи, указывается время ожидания устройства перед отправкой объявлений соседям после изменения TLV в протоколе LLDP или состояния локальной системы, например, изменение имени хоста или адреса управления. Может принимать значения от 1 до 3600; задаётся в секундах.

    • Transmit hold — значение мультипликатора удержания; произведение значений transmit delay и transmit hold определяет время жизни (TTL) пакетов LLDP. Может принимать значения от 1 до 100.

Настройка кэширования HTTP

Настройка кэша прокси-сервера:

  • Включен/Выключен — включение или отключение кэширования.

  • Исключения кэширования — список URL, которые не будут кэшироваться.

  • Максимальный размер объекта, Мбайт — объекты с размером более, чем указано в данной настройке, не будут кэшироваться. Рекомендуется оставить значение по умолчанию — 1 Мбайт.

  • Размер RAM-кэша, Мбайт — размер оперативной памяти, отведенный под кэширование. Не рекомендуется ставить более 20% от объема оперативной памяти системы.

Log Analyzer

Настройки модуля LogAn:

  • Локальный сервер/Внешний сервер. Выберите внешний сервер, если у вас есть внешний сервер LogAn, в противном случае выберите локальный сервер.

  • Состояние — показывает текущее состояние сервиса статистики.

Важно! При указании внешнего LogAn обработка и экспорт журналов, создание отчётов и обработка других статистических данных производятся сервером LogAn.

Web-портал

Настройки для предоставления доступа к внутренним ресурсам компании с помощью веб-портала (SSL VPN). Подробное описание данных настроек смотрите в главе Веб-портал.

Настройка PCAP

Настройка записи трафика при срабатывании сигнатур системы обнаружения вторжений. Настройка захвата пакетов:

  • Без захвата.

  • Один пакет.

  • Предшествующие пакеты (от 4 до 30 пакетов).

  • Предшествующие и последующие пакеты (предшествующие: от 4 до 30; последующие: от 2 до 15).

Важно! Большой размер PCAP может вести к значительному замедлению обработки данных.

Настройка учета изменений

При включении данной опции и создания Типов изменений любое изменение в конфигурацию, вносимое администратором через веб-консоль, будет требовать указание типа изменения и описания вносимого изменения. В качестве типов изменения могут быть, например, указаны:

  • Распоряжение.

  • Приказ.

  • Регламентные работы, и т.д.

Количество типов изменений не ограничено.

Агент UserGate Management Center

Настройки для подключения устройства к центральной консоли управления (UGMC), позволяющей управлять парком устройств UserGate из одной точки; для подключения к серверу UGMC используются порты TCP 2022 и TCP 9712.

  • Включен/Выключен — включение или отключение управления с помощью UGMC.

  • Адрес UserGate Management Center — адрес сервера в формате IPv4-адреса или FQDN (возможно использование IDN-адреса).

  • Код устройства — токен, требуемый для подключения к UGMC.

UGMC может использоваться как источник обновления ПО и сигнатур.

Расписание скачивания обновлений

Настройки для управления скачиванием обновлений программного обеспечения UserGate (UGOS) и обновляемыми библиотеками, предоставляемыми по подписке (база категорий URL-фильтрации, СОВ, списки IP-адресов, URL, типов контента и другие).

  • Обновления ПО — настройка расписания проверки наличия новых обновлений UGOS и скачивания обновлений.

  • Обновления библиотек — настройка расписания проверки наличия новых обновлений библиотек и скачивания библиотек. Чекбокс Единое расписание для всех обновлений применяет расписание ко всем библиотекам, иначе для каждой библиотеки необходимо настроить собственное расписание.

При задании расписания возможно указать следующие варианты:

  • Отключено. Проверка наличия обновлений для выбранного элемента производиться не будет.

  • Ежедневно.

  • Еженедельно.

  • Ежемесячно.

  • Каждые … часов.

  • Каждые … минут.

  • Задать вручную.

При задании вручную необходимо использовать crontab-подобный формат, при котором строка выглядит как шесть полей, разделенных пробелами. Поля задают время в следующем виде: (минуты: 0-59) (часы: 0-23) (дни месяца: 1-31) (месяц: 1-12) (день недели: 0-6, 0-воскресенье). Каждое из первых пяти полей может быть задано следующим образом:

  • Звездочка (*) — обозначает весь диапазон (от первого до последнего).

  • Дефис (-) — обозначает диапазон чисел. Например, "5-7" будет означать 5,6 и 7.

  • Списки. Это числа (или диапазоны), разделенные запятыми. Например, "1,5,10,11" или "1-11,19-23".

  • Звездочка или диапазон с шагом. Используется для пропусков в диапазонах. Шаг указывается после косой черты. Например, "2-10/2" будет значить "2,4,6,8,10", а выражение "*/2" в поле "часы" будет означать "каждые два часа.

Вышестоящий прокси

Настройки параметров вышестоящего прокси-сервера для перенаправления пользовательского трафика. В качестве параметров указывается тип вышестоящего прокси-сервера (HTTP(S), SOCKS5), IP-адрес и порт вышестоящего прокси-сервера, логин и пароль при необходимости для аутентификации на вышестоящем прокси-сервере.

Управление устройством

Раздел Управление устройством определяет следующие настройки NGFW:

  • Кластеризация.
  • Настройки диагностики.
  • Операции с сервером.
  • Резервное копирование.
  • Экспорт и импорт настроек.

Диагностика

В данном разделе задаются параметры диагностики сервера, необходимые службе технической поддержки UserGate при решении возможных проблем.

Наименование

Описание

Детализация диагностики

  • Off — ведение журналов диагностики отключено.

  • Error — журналировать только ошибки работы сервера.

  • Warning — журналировать только ошибки и предупреждения.

  • Info — журналировать только ошибки, предупреждения и дополнительную информацию.

  • Debug — максимум детализации.

Рекомендуется установить значение параметра Детализация диагностики в Error (только ошибки) или Off (Отключено), если техническая поддержка UserGate не попросила вас установить иные значения. Любые значения, отличные от Error (только ошибки) или Off (Отключено), негативно влияют на производительность NGFW.

Журналы диагностики

  • Скачать журналы — скачать диагностические журналы для передачи их в службу поддержки UserGate; для скачивания доступны журналы веб-консоли и/или журналы системы. Для скачивания необходимо выбрать журналы и нажать Начать архивирование журналов; после архивирования журналы будут доступны для скачивания (кнопка Скачать).

  • Очистить журналы — очистить содержимое журналов.

Удаленный помощник

  • Включено/Отключено — включение/отключение режима удаленного помощника. Удаленный помощник позволяет инженеру технической поддержки UserGate, зная значения идентификатора и токена удаленного помощника, произвести безопасное подключение к серверу UserGate для диагностики и решения проблем. Для успешной активации удаленного помощника NGFW должен иметь доступ к серверу удаленного помощника по протоколу SSH.

  • Идентификатор удаленного помощника — полученное случайным образом значение. Уникально для каждого включения удаленного помощника.

  • Токен удаленного помощника — полученное случайным образом значение токена. Уникально для каждого включения удаленного помощника.

Операции с сервером

Данный раздел позволяет произвести следующие операции с сервером:

Наименование

Описание

Операции с сервером

  • Перезагрузить — перезагрузка NGFW.

  • Выключить — выключение NGFW.

Обновления

Выбор канала обновлений ПО UserGate

  • Стабильные — проверка наличия стабильных обновлений ПО.

  • Бета — проверка наличия экспериментальных обновлений.

Обновления сервера

Индикация имеющихся обновлений NGFW.

Запуск процесса обновления сервера с возможностью создания точки восстановления.

Просмотр списка изменений ПО в обновлении.

Офлайн обновления

Загрузка файла для офлайн обновления.

Настройки вышестоящего прокси для проверки лицензий и обновлений

Настройка параметров вышестоящего HTTP(S) прокси-сервера для обновления лицензии и обновления ПО NGFW.

Необходимо указать IP-адрес и порт вышестоящего прокси сервера. При необходимости указать логин и пароль для аутентификации на вышестоящем прокси-сервере.

Команда UserGate постоянно работает над улучшением качества своего программного обеспечения и предлагает обновления продукта UserGate в рамках подписки на модуль лицензии Security Update (подробно о лицензировании смотрите в разделе Лицензирование). При наличии обновлений в разделе Управление устройством ➜ Операции с сервером отобразится соответствующее оповещение. Обновление продукта может занять довольно длительное время, рекомендуется планировать установку обновлений с учетом возможного времени простоя NGFW.

Для установки обновлений необходимо выполнить следующие действия:

Наименование

Описание

Шаг 1. Создать файл резервного копирования

Создать резервную копию состояния NGFW, как это описано в разделе Системные утилиты. Данный шаг рекомендуется всегда выполнять перед применением обновлений, поскольку он позволит восстановить предыдущее состояние устройства в случае возникновения каких-либо проблем во время применения обновлений.

Шаг 2. Установить обновления

В разделе Управление устройством при наличии оповещения Доступны новые обновления нажать на ссылку Установить сейчас. Система установит скачанные обновления, по окончании установки NGFW будет перезагружен.

Управление резервным копированием

Данный раздел позволяет управлять резервным копированием NGFW: настройка правил экспорта конфигурации, создание резервной копии, восстановление NGFW.

Для создания резервной копии необходимо выполнить следующие действия:

Наименование

Описание

Шаг 1. Создать резервную копию

В разделе Управление устройством ➜ Управление резервным копированием нажать Создание резервной копии. Система сохранит текущие настройки сервера под следующим именем:

backup_PRODUCT_NODE-NAME_DATE.gpg, где:

PRODUCT — тип продукта: NGFW, LogAn, MC;

NODE-NAME — имя узла UserGate;

DATE — дата и время создания резервной копии в формате YYYY-MM-DD-HH-MM; время указывается в часовом поясе UTC.

Процесс создания резервной копии может быть прерван нажатием кнопки Остановить. Запись о создании резервной копии отобразится в журнале событий устройства.

Для восстановления состояния устройства необходимо выполнить следующие действия:

Наименование

Описание

Шаг 1. Восстановить состояние устройства

В разделе Управление устройством ➜ Управление резервным копированием нажать Восстановление из резервной копии и указать путь к ранее созданному файлу настроек для его загрузки на сервер. Восстановление будет предложено в консоли tty при перезагрузке устройства.

Дополнительно администратор может настроить сохранение файлов на внешние серверы (FTP, SSH) по расписанию. Для создания расписания выгрузки настроек необходимо выполнить следующие действия:

Наименование

Описание

Шаг 1. Создать правило экспорта конфигурации

В разделе Управление устройством ➜ Управление резервным копированием нажать кнопку Добавить, указать имя и описание правила.

Шаг 2. Указать параметры удаленного сервера

Во вкладке правила Удаленный сервер указать параметры удаленного сервера:

  • Тип сервера — FTP или SSH.

  • Адрес сервераIP-адрес сервера.

  • Порт — порт сервера.

  • Логин — учетная запись на удаленном сервере.

  • Пароль/Повторите пароль — пароль учетной записи.

  • Путь на сервере — путь на сервере, куда будут выгружены настройки.

В случае использование SSH-сервера возможно использование авторизации по ключу. Для импорта или генерации ключа необходимо выбрать Настроить SSH-ключ и указать Сгенерировать ключи или Импортировать ключ.

Важно! При повторном создании ключа существующий SSH-ключ будет удален. Публичный ключ должен находиться на SSH-сервере в директории пользовательских ключей /home/user/.ssh/ в файле authorized_keys.

При первоначальной настройке правила экспорта резервного копирования по SSH обязательна проверка соединения (кнопка Проверить соединение); при проверке соединения fingerprint помещается в known_hosts, без проверки файлы не будут отправляться.

Важно! Если сменить сервер SSH или его переустановить, то файлы резервного копирования будут недоступны, так как fingerprint изменится — это защита от спуфинга.

Шаг 3. Выбрать расписание выгрузки

Во вкладке правила Расписание указать необходимое время отправки настроек. В случае задания времени в crontab-формате, задайте его в следующем виде:

(минуты:0-59) (часы:0-23) (дни месяца:1-31) (месяц:1-12) (день недели:0-6, 0-воскресенье)

Каждое из первых пяти полей может быть задано следующим образом:

  • Звездочка (*) — обозначает весь диапазон (от первого до последнего).

  • Дефис (-) — обозначает диапазон чисел. Например, "5-7" будет означать 5,6 и 7.

  • Списки. Это числа (или диапазоны), разделенные запятыми. Например, "1,5,10,11" или "1-11,19-23".

  • Звездочка и тире используются для пропусков в диапазонах. Шаг указывается после косой черты. Например, "2-10/2" будет значить "2,4,6,8,10", а выражение "*/2" в поле "часы" будет означать "каждые два часа".

Экспорт и импорт настроек

Администратор имеет возможность сохранить текущие настройки NGFW в файл и впоследствии восстановить эти настройки на этом же или другом NGFW. В отличие от резервного копирования, экспорт/импорт настроек не сохраняет текущее состояние всех компонентов комплекса, сохраняются только текущие настройки.

ПримечаниеЭкспорт настроек является кластерной функцией, т.е. экспортируется конфигурация всех узлов кластера. При импорте конфигурации будет предложен выбор нужного узла кластера для восстановления.
ПримечаниеЭкспорт/импорт настроек не восстанавливает состояние кластера и информацию о лицензии. После окончания процедуры импорта необходимо повторно зарегистрировать NGFW с помощью имеющегося ПИН-кода и заново создать кластер, если это необходимо.
ПримечаниеВ случае использования мультифакторной аутентификации через TOTP, ключи TOTP не сохраняются; необходима повторная инициализация.

Имеется возможность сделать экспорт всех настроек (за исключением вышеперечисленных), либо сделать только экспорт сетевых настроек. При экспорте только сетевых настроек сохраняется информация о:

  • Настройки DNS.

  • Настройки DHCP.

  • Настройки всех интерфейсов, включая туннели.

  • Настройки шлюзов.

  • Настройки виртуальных маршрутизаторов (VRF).

  • Настройки WCCP.

  • Настройки зон.

Для экспорта настроек необходимо выполнить следующие действия:

Наименование

Описание

Шаг 1. Экспорт настроек

В разделе Управление устройством ➜ Экспорт и импорт настроек нажать на ссылку Экспорт ➜ Экспортировать все настройки или Экспортировать сетевые настройки. Система сохранит текущие настройки сервера под именем

utm-utmcore@nodename_version-YYYYMMDD_HHMMSS.bin, где:

nodename — имя узла NGFW

version — версия UGOS

YYYYMMDD_HHMMSS — время выгрузки настроек в часовом поясе UTC, например:

utm-utmcore@heashostatot_6.1.1.10462R-1_20210511_095942

Для применения созданных ранее настроек необходимо выполнить следующие действия:

Наименование

Описание

Шаг 1. Импорт настроек

В разделе Управление устройством ➜ Экспорт и импорт настроек нажать Импорт и указать путь к ранее созданному файлу настроек. Указанные настройки применятся к серверу, после чего сервер будет перезагружен.

ПримечаниеДля корректного импорта правил, использующих обновляемые списки UserGate (приложения, категории URL и т.п.), необходимо наличие лицензии на модули SU и ATP, а также загруженных списков UserGate.

Дополнительно администратор может настроить сохранение настроек на внешние серверы (FTP, SSH) по расписанию. Для создания расписания выгрузки настроек необходимо выполнить следующие действия:

Наименование

Описание

Шаг 1. Создать правило экспорта

В разделе Управление устройством ➜ Экспорт и импорт настроек нажать кнопку Добавить, указать имя и описание правила.

Шаг 2. Указать параметры удаленного сервера

Во вкладке правила Удаленный сервер указать параметры удаленного сервера:

  • Тип сервера — FTP или SSH.

  • Адрес сервераIP-адрес сервера.

  • Порт — порт сервера.

  • Логин — учетная запись на удаленном сервере.

  • Пароль/Подтверждение пароля — пароль учетной записи.

  • Путь на сервере — путь на сервере, куда будут выгружены настройки.

Шаг 3. Выбрать расписание выгрузки

Во вкладке правила Расписание указать необходимое время отправки настроек. В случае задания времени в CRONTAB-формате, задайте его в следующем виде:

(минуты:0-59) (часы:0-23) (дни месяца:1-31) (месяц:1-12) (день недели:0-6, 0-воскресенье)

Каждое из первых пяти полей может быть задано следующим образом:

  • Звездочка (*) — обозначает весь диапазон (от первого до последнего).

  • Дефис (-) — обозначает диапазон чисел. Например, "5-7" будет означать 5,6 и 7.

  • Списки. Это числа (или диапазоны), разделенные запятыми. Например, "1,5,10,11" или "1-11,19-23".

  • Звездочка и тире используются для пропусков в диапазонах. Шаг указывается после косой черты. Например, "2-10/2" будет значить "2,4,6,8,10", а выражение "*/2" в поле "часы" будет означать "каждые два часа.

Управление доступом к консоли UserGate NGFW

Доступ к веб-консоли UserGate NGFW регулируется с помощью создания дополнительных учетных записей администраторов, назначения им профилей доступа, создания политики управления паролями администраторов и настройки доступа к веб-консоли на уровне разрешения сервиса в свойствах зоны сети. Дополнительной мерой усиления безопасности доступа к консоли может быть включение режима авторизации администраторов с использованием сертификатов.

ПримечаниеПри первоначальной настройке NGFW создается локальный суперпользователь Admin.

Для создания дополнительных учетных записей администраторов устройства необходимо выполнить следующие действия:

Наименование

Описание

Шаг 1. Создать профиль доступа администратора.

В разделе Администраторы ➜ Профили администраторов нажать кнопку Добавить и указать необходимые настройки.

Шаг 2. Создать учетную запись администратора и назначить ей один из созданных ранее профилей администратора.

В разделе Администраторы нажать кнопку Добавить и выбрать необходимый вариант:

  • Добавить локального администратора — создать локального пользователя, задать ему пароль доступа и назначить созданный ранее профиль доступа.

  • Добавить пользователя LDAP — добавить пользователя из существующего домена. Для этого должен быть корректно настроен LDAP-коннектор в разделе Серверы авторизации. При входе в консоль администрирования необходимо указывать имя пользователя в формате user@domain. Назначить созданный ранее профиль.

  • Добавить группу LDAP — добавить группу пользователей из существующего домена. Для этого должен быть корректно настроен LDAP-коннектор в разделе Серверы авторизации. При входе в консоль администрирования необходимо указывать имя пользователя в формате user@domain. Назначить созданный ранее профиль.

  • Добавить администратора с профилем авторизации – создать пользователя, назначить созданный ранее профиль администратора и профиль авторизации (необходимы корректно настроенные серверы авторизации).

При создании профиля доступа администратора необходимо указать следующие параметры:

Наименование

Описание

Название

Название профиля.

Описание

Описание профиля.

Разрешения для API

Список объектов, доступных для делегирования доступа при работе через программный интерфейс (API). Объекты описаны документации API. В качестве доступа можно указать:

  • Нет доступа.

  • Чтение.

  • Чтение и запись.

Разрешения для веб-консоли

Список объектов дерева веб-консоли, доступных для делегирования. В качестве доступа можно указать:

  • Нет доступа.

  • Чтение.

  • Чтение и запись.

Разрешения для CLI

Позволяет разрешить доступ к CLI. В качестве доступа можно указать:

  • Нет доступа.

  • Чтение.

  • Чтение и запись.

Администратор NGFW может настроить дополнительные параметры защиты учетных записей администраторов, такие, как сложность пароля и блокировку учетной записи на определенное время при превышении количества неудачных попыток авторизации.

Для настройки этих параметров необходимо:

Наименование

Описание

Шаг 1. Настроить политику паролей.

В разделе Администраторы ➜ Администраторы нажать кнопку Настроить.

Шаг 2. Заполнить необходимые поля.

Указать значения следующих полей:

  • Сложный пароль — включает дополнительные параметры сложности пароля, задаваемые ниже, такие как — минимальная длина, минимальное число символов в верхнем регистре, минимальное число символов в нижнем регистре, минимальное число цифр, минимальное число специальных символов, максимальная длина блока из одного и того же символа.

  • Число неверных попыток аутентификации — количество неудачных попыток аутентификации администратора, после которых учетная запись заблокируется на Время блокировки.

  • Время блокировки — время, на которое блокируется учетная запись.

Администратор может указать зоны, с которых будет возможен доступ к сервису веб-консоли (порт TCP 8001).

ПримечаниеНе рекомендуется разрешать доступ к веб-консоли для зон, подключенных к неконтролируемым сетям, например, к сети интернет.

Для разрешения сервиса веб-консоли для определенной зоны необходимо в свойствах зоны в разделе Контроль доступа разрешить доступ к сервису Консоль администрирования. Более подробно о настройке контроля доступа к зонам можно прочитать в разделе Настройка зон.

Дополнительной мерой усиления безопасности доступа к консоли может быть включение режима авторизации администраторов с использованием сертификатов.

Для включения данного режима необходимо выполнить следующие действия (в качестве примера используется утилита openssl):

Наименование

Описание

Шаг 1. Создать учетные записи дополнительных администраторов.

Произвести настройку, как это описано ранее в этой главе, например, создать учетную запись администратора с именем Administrator54.

Шаг 2. Создать или импортировать существующий сертификат типа УЦ (удостоверяющего центра) авторизации веб-консоли.

Создать или импортировать существующий сертификат удостоверяющего центра (достаточно только публичного ключа) в соответствии с главой Управление сертификатами.

Важно! Существующий сертификат удостоверяющего центра — сертификат, которым непосредственно подписаны сертификаты администраторов, а не корневой.

Например, для создания eудостоверяющего центра с помощью утилиты openssl требуется выполнить команды:

openssl req -x509 -subj '/C=RU/ST=Moscow/O= MyCompany /CN=ca.mycompany.com' -newkey rsa:2048 -keyout ca-key.pem -out ca.pem -nodes
openssl rsa -in ca-key.pem -out ca-key.pem

В файле ca-key.pem будет находиться приватный ключ сертификата, в ca.pem — публичный ключ. Импортировать публичный ключ в NGFW.

Шаг 3. Создать сертификаты для учетных записей администраторов.

С помощью средств сторонних утилит (например, openssl) создать сертификаты для каждого из администраторов. Необходимо, чтобы поле сертификата Common name в точности совпадало с именем учетной записи администратора, как она была создана в NGFW.

Для openssl и пользователя Administrator54 команды будут следующими:

openssl req -subj '/C=RU/ST=Moscow/O= MyCompany /CN=Administrator54' -out admin.csr -newkey rsa:2048 -keyout admin-key.pem -nodes

Шаг 4. Подписать сертификаты администраторов, созданным на шаге 2 сертификатом удостоверяющего центра.

С помощью средств сторонних утилит (например, openssl) подписать сертификаты администраторов сертификатом удостоверяющего центра веб-консоли.

Для openssl команды будут следующими:

openssl x509 -req -days 9999 -CA ca.pem -CAkey ca-key.pem -set_serial 1 -in admin.csr -out admin.pem
openssl pkcs12 -export -in admin.pem -inkey admin-key.pem -out admin.p12 -name 'Administrator54 client certificate'

Файл admin.p12 содержит подписанный сертификат администратора.

Шаг 5. Добавить подписанные сертификаты в ОС, с которой администраторы будут авторизоваться в веб-консоль.

Добавить подписанные сертификаты администраторов (admin.p12 в нашем примере) в ОС (или в браузер Firefox, если он используется для доступа к консоли), с которой администраторы будут авторизоваться в веб-консоль. Более подробно смотрите руководство по используемой вами ОС.

Шаг 6. Переключите режим авторизации веб-консоли в авторизацию по сертификатам x.509.

В разделе Настройки поменяйте Режим авторизации веб-консоли на По X.509 сертификату.

ПримечаниеПереключить режим авторизации веб-консоли можно с помощью команд CLI.

В разделе Администраторы ➜ Сессии администраторов отображаются все администраторы, выполнившие вход в веб-консоль администрирования NGFW. При необходимости любую из сессий администраторов можно сбросить (закрыть).

Кластеризация и отказоустойчивость

UserGate NGFW поддерживает 2 типа кластеров:

  1. Кластер конфигурации. Узлы, объединенные в кластер конфигурации, поддерживают единые настройки в рамках кластера.

  2. Кластер отказоустойчивости. До 4-х узлов кластера конфигурации могут быть объединены в кластер отказоустойчивости, поддерживающий работу в режиме Актив-Актив или Актив-Пассив. Возможно собрать несколько кластеров отказоустойчивости.

Кластер конфигурации

Ряд настроек уникален для каждого из узлов кластера, например, настройка сетевых интерфейсов и IP-адресация. Список уникальных настроек:

Наименование

Описание

Настройки, уникальные для каждого узла

Настройки Log Analyzer.

Настройки диагностики.

Настройки интерфейсов.

Настройки шлюзов.

Настройки DHCP.

Маршруты.

Настройки OSPF.

Настройки BGP.

Для создания кластера конфигурации необходимо выполнить следующие шаги:

Наименование

Описание

Шаг 1. Выполнить первоначальную настройку на первом узле кластера.

Смотрите главу Первоначальная настройка.

Шаг 2. Настроить на первом узле кластера зону, через интерфейсы которой будет выполняться репликация кластера.

В разделе Зоны создать выделенную зону для репликации настроек кластера или использовать существующую (Cluster). В настройках зоны разрешить следующие сервисы:

  • Консоль администрирования

  • Кластер

Не используйте для репликации зоны, интерфейсы которых подключены к недоверенным сетям, например, к интернету.

Шаг 3. Указать IP-адрес, который будет использоваться для связи с другими узлами кластера.

В разделе Управление устройством в окне Кластер конфигурации выбрать текущий узел кластера и нажать на кнопку Редактировать. Указать IP-адрес интерфейса, входящего в зону, настроенную на шаге 2.

Шаг 4. Сгенерировать Секретный код на первом узле кластера.

В разделе Управление устройством нажать на кнопку Сгенерировать секретный код. Полученный код скопировать в буфер обмена. Данный секретный код необходим для одноразовой авторизации второго узла при добавлении его в кластер.

Шаг 5. Подключить второй узел в кластер.

Подключиться к веб-консоли второго узла кластера, выбрать язык установки.

Указать интерфейс, который будет использован для подключения к первому узлу кластера и назначить ему IP-адрес. Оба узла кластера должны находиться в одной подсети, например, интерфейсам eth2 обоих узлов назначены IP-адреса 192.168.100.5/24 и 192.168.100.6/24. В противном случае необходимо указать IP-адрес шлюза, через который будет доступен первый узел кластера.

Указать IP-адрес первого узла, настроенный на шаге 3, вставить секретный код и нажать на кнопку Подключить. Если IP-адреса кластера, настроенные на шаге 2, назначены корректно, то второй узел будет добавлен в кластер и все настройки первого кластера реплицируются на второй.

Состояние узлов кластера конфигурации можно определить по цветовой индикации напротив названия узла UserGate в разделе UserGate ➜ Управление устройством ➜ Кластер конфигурации:

  • Зелёный: узел доступен.

  • Жёлтый: происходит синхронизация между узлами кластера конфигурации.

  • Красный: связь до узла потеряна, узел недоступен.

Шаг 6. Назначить зоны интерфейсам второго узла.

В веб-консоли второго узла кластера в разделе Сеть ➜ Интерфейсы необходимо назначить каждому интерфейсу корректную зону. Зоны и их настройки получены в результате репликации данных с первого узла кластера.

Шаг 7. Настроить параметры, индивидуальные для каждого узла кластера (опционально).

Настроить шлюзы, маршруты, параметры OSPF, BGP, индивидуальные для каждого из узлов.

До четырех узлов кластера конфигурации можно объединить в отказоустойчивый кластер. Самих кластеров отказоустойчивости может быть несколько, например, в кластер конфигурации добавлены узлы A, B, C и D на основе которых создано 2 кластера отказоустойчивости — A-B и C-D.

Поддерживаются 2 режима кластера отказоустойчивости — Актив-Актив и Актив-Пассив. Состояние узлов кластера можно определить по цвету индикатора около названия узла NGFW в разделе UserGate ➜ Управление устройством ➜ Кластеры отказоустойчивости:

  • Красный: нет связи с соседними узлами конфигурации.

  • Жёлтый: кластер отказоустойчивости не запущен на узле.

Отсутствие индикатора напротив названия узла говорит о доступности узла кластера.

Кластер отказоустойчивости Актив-Пассив

В режиме Актив-Пассив один из серверов выступает в роли Мастер-узла, обрабатывающего трафик, а остальные — в качестве резервных. На каждом из узлов кластера выбираются сетевые интерфейсы, которым администратор назначает виртуальные IP-адреса. Между этими интерфейсами передаются VRRP-объявления (ADVERTISEMENT) — сообщения, с помощью которых узлы обмениваются информацией о своем состоянии.

ПримечаниеРежим Актив-Пассив поддерживает синхронизацию пользовательских сессий, что обеспечивает прозрачное для пользователей переключение трафика с одного узла на другой, за исключением сессий, использующих прокси-сервер, например, трафик HTTP/S.

При переходе роли мастер на резервный сервер на него переносятся все виртуальные IP-адреса всех кластерных интерфейсов. Безусловный переход роли происходит при следующих событиях:

  • Запасной сервер не получает подтверждения о том, что главный узел находится в сети, например, если он выключен или отсутствует сетевая доступность узлов.

  • На узле настроена проверка доступа в интернет (смотрите раздел Настройка шлюзов), и доступ в интернет отсутствует через все имеющиеся шлюзы.

    Если хост, указанный в свойствах проверки сети, недоступен на всех узлах кластера, то кластер отказоустойчивости будет отключен.

  • Сбой в работе ПО UserGate.

Отключение одного или нескольких сетевых интерфейсов, на которых назначены виртуальные IP-адреса понижает приоритет узла, но не обязательно приведет к изменению роли сервера. Переход на запасной узел произойдет, если приоритет запасного узла окажется выше, чем мастер-узла. По умолчанию приоритет узла, назначенный мастер-узлу, равен 250, приоритет резервного узла равен 249. Приоритет узла уменьшается на 2 для каждого кластерного интерфейса, у которого отсутствует физическое подключение к сети. Соответственно, для кластера отказоустойчивости, состоящего из двух узлов, при пропадании физического подключения к сети одного интерфейса на мастер-узле, роль мастера переместится на запасной сервер, если на запасном сервере все кластерные интерфейсы подключены к сети (приоритет мастер-сервера будет равен 248, приоритет резервного — 249). При восстановлении физического подключения на первоначальном мастер-узле роль мастера вернется обратно на него, поскольку его приоритет вернется в значение 250 (справедливо для случая если виртуальные адреса сконфигурированы на двух и более интерфейсах. Если на одном, то роль мастера не возвращается).

Отключение одного или нескольких кластерных сетевых интерфейсов на запасном узле, понижает приоритет узла, тем не менее данный запасной узел может стать мастер-узлом при безусловном переходе роли, или в случае, когда приоритет мастер узла станет меньше, чем приоритет данного запасного узла.

ПримечаниеЕсли кластерные IP-адреса назначены VLAN-интерфейсам, то отсутствие подключения на физическом интерфейсе будет трактоваться кластером отказоустойчивости как потеря соединения на всех VLAN-интерфейсах, созданных на данном физическом интерфейсе.

ПримечаниеДля уменьшения времени, требуемого сетевому оборудованию для перевода трафика на запасной узел при переключении, NGFW посылают служебное оповещение GARP (Gratuitous ARP), извещающий сетевое оборудование о смене MAC-адресов для всех виртуальных IP-адресов. Пакет GARP отсылается NGFW каждую минуту и при переезде роли мастера на запасной сервер.

Ниже представлена пример сетевой диаграммы отказоустойчивого кластера в режиме Актив-Пассив. Интерфейсы настроены следующим образом:

  • Зона Trusted: IP1, IP2, IP3, IP4 и IP cluster (Trusted).

  • Зона Untrusted: IP5, IP6, IP7, IP8 и IP cluster (Untrusted).

  • Зона Cluster: IP9, IP10, IP11, IP12, IP13, IP14. Интерфейсы в зоне Cluster используются для репликации настроек.

Оба кластерных IP-адреса находятся на узле UG1. Если узел UG1 становится недоступным, то оба кластерных IP-адреса перейдут на следующий сервер, который станет мастер сервером, например, UG2.

Отказоустойчивый кластер в режиме Актив-Пассив

Кластер отказоустойчивости Актив-Актив

В режиме Актив-Актив один из серверов выступает в роли Мастер-узла, распределяющего трафик на все остальные узлы кластера. На каждом из узлов кластера выбираются сетевые интерфейсы, которым администратор назначает виртуальные IP-адреса. Между этими интерфейсами передаются VRRP-объявления (ADVERTISEMENT) — сообщения, с помощью которых узлы обмениваются информацией о своем состоянии.

Виртуальные IP-адреса всегда находятся на интерфейсах Мастер-узла, поэтому Мастер-узел получает ARP-запросы клиентов и отвечает на них, последовательно отдавая MAC-адреса всех узлов отказоустойчивого кластера, обеспечивая равномерное распределение трафика на все узлы кластера, учитывая при этом необходимость неразрывности пользовательских сессий.

ПримечаниеРежим Актив-Актив поддерживает синхронизацию пользовательских сессий, что обеспечивает прозрачное для пользователей переключение трафика с одного узла на другой, за исключением сессий, использующих прокси-сервер, например, трафик HTTP/S.

При переходе роли мастер на резервный сервер на него переносятся все виртуальные IP-адреса всех кластерных интерфейсов. Безусловный переход роли происходит при следующих событиях:

  • Запасной сервер не получает подтверждения о том, что главный узел находится в сети, например, если он выключен или отсутствует сетевая доступность узлов.

  • На узле настроена проверка доступа в интернет (смотрите раздел Настройка шлюзов), и доступ в интернет отсутствует через все имеющиеся шлюзы.

  • Сбой в работе ПО NGFW.

Отключение одного или нескольких сетевых интерфейсов мастер-узла, на которых назначены виртуальные IP-адреса, понижает приоритет узла, но не обязательно приведет к изменению роли сервера. Переход на запасной узел произойдет, если приоритет запасного узла окажется выше, чем мастер-узла. По умолчанию приоритет узла, назначенный мастер-узлу, равен 250, приоритет резервного узла равен 249. Приоритет узла уменьшается на 2 для каждого кластерного интерфейса, у которого отсутствует физическое подключение к сети. Соответственно, для кластера отказоустойчивости, состоящего из двух узлов, при пропадании физического подключения к сети одного интерфейса на мастер-узле, роль мастера переместится на запасной сервер, если на запасном сервере все кластерные интерфейсы подключены к сети (приоритет мастер-сервера будет равен 248, приоритет резервного — 249). При восстановлении физического подключения на первоначальном мастер-узле роль мастера вернется обратно на него, поскольку его приоритет вернется в значение 250.

Отключение одного или нескольких кластерных сетевых интерфейсов на запасном узле, понижает приоритет узла, а также исключает данный узел из балансировки трафика. Тем не менее данный запасной узел может стать мастер-узлом при безусловном переходе роли, или в случае, когда приоритет мастер узла станет меньше, чем приоритет данного запасного узла.

ПримечаниеЕсли кластерные IP-адреса назначены VLAN-интерфейсам, то отсутствие подключения на физическом интерфейсе будет трактоваться кластером отказоустойчивости как потеря соединения на всех VLAN-интерфейсах, созданных на данном физическом интерфейсе.

Примечание

Для уменьшения времени, требуемого сетевому оборудованию для перевода трафика на запасной узел при переключении, NGFW посылает служебное оповещение GARP (Gratuitous ARP), извещающий сетевое оборудование о смене MAC-адресов для всех виртуальных IP-адресов. В режиме Актив-Актив пакет GARP отсылается NGFW только при переходе роли мастера на запасной сервер.

Ниже представлен пример сетевой диаграммы отказоустойчивого кластера в режиме Актив-Актив. Интерфейсы настроены следующим образом:

  • Зона Trusted: IP1, IP2, IP3, IP4 и IP cluster (Trusted).

  • Зона Untrusted: IP5, IP6, IP7, IP8 и IP cluster (Untrusted).

  • Зона Cluster: IP9, IP10, IP11, IP12, IP13, IP14. Интерфейсы в зоне Cluster используются для репликации настроек.

Оба кластерных IP-адреса находятся на узле UG1. Если узел UG1 становится недоступным, то оба кластерных IP-адреса перейдут на следующий сервер, который станет мастер сервером, например, UG2.

Отказоустойчивый кластер в режиме Актив-Актив

ПримечаниеДля корректной обработки трафика необходимо, чтобы обратный трафик от сервера к клиенту вернулся через тот же узел NGFW, через который он был инициирован от клиента, то есть, чтобы сессия пользователя всегда проходила через один и тот же узел кластера. Самое простое решение данной задачи – это использование NAT из сети клиента в сеть сервера (NAT из Trusted в Untrusted).

Для создания отказоустойчивого кластера необходимо выполнить следующие шаги:

Наименование

Описание

Шаг 1. Создать кластер конфигурации.

Создать кластер конфигурации, как это описано на предыдущем шаге.

Шаг 2. Настроить зоны, интерфейсы которых будут участвовать в отказоустойчивом кластере.

В разделе Зоны следует разрешить сервис VRRP для всех зон, где планируется добавлять кластерный виртуальный IP-адрес (зоны Trusted и Untrusted на диаграммах выше).

Шаг 3. Создать кластер отказоустойчивости.

В разделе Управление устройством ➜ Кластер отказоустойчивости нажать на кнопку Добавить и указать параметры кластера отказоустойчивости.

Шаг 4. Указать виртуальный IP-адрес для хостов auth.captive, logout.captive, block.captive, ftpclient.captive.

Если предполагается использовать авторизацию с помощью Captive-портала, то необходимо, чтобы системные имена хостов auth.captive и logout.captive, которые используются процедурами авторизации в Captive, резолвились в IP-адрес, назначенный в качестве кластерного виртуального адреса. Более детально эти параметры описаны в разделе Общие настройки.

Параметры отказоустойчивого кластера:

Наименование

Описание

Включено

Включение/отключение отказоустойчивого кластера.

Название

Название отказоустойчивого кластера.

Описание

Описание отказоустойчивого кластера.

Режим кластера

Режим отказоустойчивого кластера:

  • Актив-Актив — нагрузка распределяется на все узлы кластера.

  • Актив-Пассив — нагрузка идет на Мастер-узел и переключается на запасной узел в случае недоступности Мастер-узла.

Синхронизировать сессии

Включает режим синхронизации пользовательских сессий между всеми узлами, входящими в кластер отказоустойчивости. Включение данной опции делает переключение пользователей с одного устройства на другое прозрачным для пользователей, но добавляет существенную нагрузку на платформу UserGate. Имеет смысл только для режима кластера Актив-Пассив.

Мультикаст идентификатор кластера

В одном кластере конфигурации может быть создано несколько кластеров отказоустойчивости. Для синхронизации сессий используется определенный мультикастовый адрес, определяемый данным параметром. Для каждой группы кластеров отказоустойчивости, в которой должна поддерживаться синхронизация сессий, требуется установить уникальный идентификатор.

Идентификатор виртуального роутера (VRID)

Идентификатор виртуального роутера должен быть уникален для каждого VRRP-кластера в локальной сети. Если в сети не присутствуют сторонние кластеры VRRP, то рекомендуется оставить значение по умолчанию.

Узлы

Выбираются узлы кластера конфигурации для объединения их в кластер отказоустойчивости. Здесь же можно назначить роль Мастер-сервера одному из выбранных узлов.

Виртуальные IP-адреса

Назначаются виртуальные IP-адреса и их соответствие интерфейсам узлов кластера.

Синхронизация UDP/ICMP

Управление режимом синхронизации пользовательских сессий:

  • Синхронизовать все сессии — включение/отключение режима синхронизации всех пользовательских сессий, включая UDP/ICMP сессии. В случае, если этот параметр не активирован, а настройка Синхронизировать сессии во вкладке Общие активирована, синхронизироваться будут только TCP сессии.  

  • Исключенные из синхронизации IP — указание IP-адресов, с которыми не будут синхронизироваться пользовательские cессии. 

Upstream Proxy

Описание

Upstream Proxy — это функциональность NGFW, позволяющая перенаправлять входящий HTTP(S) трафик на другой прокси-сервер, благодаря чему возможно создание каскадной иерархии, когда трафик с одного прокси-сервера передается на следующий в цепочке прокси-серверов. Подобное каскадирование обычно используется для обеспечения конфиденциальности коммуникаций или для организации доступа к контенту с региональными ограничениями. Также благодаря технологии каскадирования упрощается встраивание новых региональных офисов в существующую иерархию глобальной сети компании.

Upstream Proxy работает только если NGFW используется в режиме явного прокси-сервера (Explicit Proxy). На стороне клиента в веб-браузере или в других приложениях в явном виде указывается адрес и порт прокси-сервера NGFW .

При запросе клиентом внешнего ресурса формируется две TCP-сессии:

  • Первая сессия: Клиент — NGFW. Обращение от клиента происходит непосредственно к NGFW и начинается с сообщения HTTP Connect.

  • Вторая сессия: В отличие от классического сценария с явным прокси, сессия устанавливается не между NGFW и конечным сервером, а между NGFW и последующим (вышестоящим) прокси-сервером. Трафик от NGFW до вышестоящегог прокси-сервера является транзитным для блока Firewall. Необходимо понимать, что в режиме Upstream proxy адресом назначения становится IP-адрес вышестоящего прокси-сервера. Если ранее было настроено запрещающее правило по IP-адресам назначения, то такое правило работать не будет.

Алгоритм обработки трафика (packet flow) аналогичен алгоритму обработки в режиме явного прокси-сервера.

Поступая на интерфейс, пакеты проходят проверку соответствия правилам зоны в блоке DoS, Spoofing. Для корректной работы функциональности Upstream Proxy в NGFW необходимо в настройках зоны разрешить сервис HTTP(s)-прокси, иначе пакеты будут отброшены.

Далее пакеты обрабатываются в блоке Gateways, PBR, в котором маркируются для дальнейшего использования в правилах маршрутизации.

Затем пакеты без изменений проходят в блок с условным названием CHECK, где весь трафик проходит проверку соответствия условиям правил инспектирования, контентной фильтрации, а также принадлежности сервисам ICAP, reverse-прокси, веб-портала, АСУ ТП и защиты почтового трафика. Проверка осуществляется путём поэтапного анализа трафика в соответствие с параметрами алгоритма блока CHECK (подробнее в статье UserGate NGFW packet flow). После обработки в блоке CHECK трафик будет направлен в блоки License, Routing и далее.

Сценарии использования

Proxy forwarding (без классификации трафика)

Весь входящий на NGFW HTTP трафик, прошедший через правила фильтрации на NGFW, перенаправляется на следующий (вышестоящий) прокси-сервер по цепочке. В качестве вышестоящего прокси-сервера может быть любой HTTP(S) или SOCKS5 прокси-сервер. Поддерживается опциональный режим с аутентификацией на вышестоящем прокси-сервере по логину/паролю.

Журналирование перенапрявляемого на вышестоящий прокси-сервер трафика производится в Журнале веб-доступа, но в качестве IP-адреса назначения указывается IP-адрес вышестоящего прокси-сервера.

Этот сценарий может использоваться для обеспечения доступа к контенту с региональными ограничениями, для интеграции сети регионального офиса с существующей глобальной сетевой иерархией компании, для обеспечения конфиденциальности внешних коммуникаций компании.

Update via proxy

Активация лицензии или обновление ПО узлов UserGate (NGFW, MC, LogAn) проходит через внешний прокси-сервер. В качестве такого прокси может быть любой HTTP(S) прокси-сервер. Поддерживается опциональный режим с аутентификацией на внешнем прокси-сервере по логину/паролю.

Журналирование событий лицензирования или обновления ПО через внешний прокси-сервер производится в Журнале событий. В описании каждого такого обновления добавляется тег proxy с адресом и портом прокси-сервера. Например, proxy: https://10.10.0.1:3128

Активация лицензий или ПО через внешний прокси-сервер может производиться на NGFW, UGMC, LogAn, SIEM.

Одним из примеров использования такого сценария может быть случай, когда оборудование UserGate (например, UGMC, LogAn) находится внутри организации с закрытым контуром, без прямого выхода в интернет для обновления ПО.

ПримечаниеНастройки функциональности Upstream Proxy для NGFW, LogAn могут прописываться в соответствующих шаблонах на UGMC и применяться к управляемым узлам через UGMC.

Настройки Upstream Proxy 

Настройка Upstream Proxy в консоли администратора

Настройка сценария перенаправления трафика на вышестоящий прокси-сервер производится в разделе UserGate —>Настройки —> Вышестоящий прокси.

Необходимо указать режим работы вышестоящего прокси-сервера (HTTP(S)) или SOCKS5), его IP-адрес и порт. Если для доступа к вышестоящему прокси-серверу требуется аутентификация, необходимо указать соответствующий логин и пароль.

Сценарий обновления лицензии или ПО узла UserGate через внешний прокси-сервер имеет одинаковую сквозную настройку для активации лицензии и для обновления ПО. Настройку можно сделать либо в разделе Лицензия в Дашборде, либо в разделе Управление устройством в Настройках. Параметры, установленные в одном из этих разделов, будут отображаться и во втором.

Настройки в Дашборде:

Перейти в раздел Дашборд → Лицензия и нажать на строку регистрации. В окне активации нажать на строку настройки вышестоящего прокси.

В открывшемся окне настройки необходимо указать IP-адрес и порт внешнего HTTP прокси-сервера. Если для доступа к внешнему прокси-серверу требуется аутентификация, необходимо указать соответствующий логин и пароль.

Настройки в разделе Управление устройством:

Перейти в раздел UserGate → Управление устройством → Операции с сервером и нажать Настроить для операции настройки вышестоящего прокси для проверки лицензий и обновлений.

В открывшемся окне настройки необходимо указать IP-адрес и порт внешнего HTTP прокси-сервера. Если для доступа к внешнему прокси-серверу требуется аутентификация, необходимо указать соответствующий логин и пароль.

Настройка Upstream Proxy в CLI

Описание настроек Upstream Proxy в интерфейсе командной строки (CLI) смотрите в разделе Настройка Upstream Proxy

Управление сертификатами

Общие сведения

UserGate NGFW использует защищенный протокол HTTPS для управления устройством, может перехватывать и дешифровать транзитный трафик пользователей, передаваемый по протоколу SSL (HTTPS, SMTPS, POP3S), а также может производить авторизацию администраторов в веб-консоль на основе их сертификатов.

Для выполнения данных функций NGFW использует различные типы сертификатов:

Наименование

Описание

SSL веб-консоли

Используется для создания безопасного HTTPS-подключения администратора к веб-консоли NGFW.

SSL Captive-портала

Используется для создания безопасного HTTPS-подключения пользователей к странице авторизации Captive-портала, для отображения страницы блокировки, для отображения страницы Logout Captive-портала и для работы ftp-прокси. Этот сертификат должен быть выпущен со следующими параметрами:

  • Subject name — значение, установленное для домена Домен Auth captive-портала, определенного на странице Настройки.

  • Subject Alternative names — необходимо указать все домены, для которых используется данный сертификат, как они заданы на странице Настройки:

    • домен Auth сaptive-портала.

    • домен Logout сaptive-портала.

    • домен страницы блокировки.

    • домен FTP поверх HTTP.

    • домен для веб-портала, указанный в настройках веб-портала.

По умолчанию используется подписанный с помощью сертификата инспектирование SSL сертификат, выпущенный для домена auth.captive, со следующими параметрами:

  • Subject name = auth.captive

  • Sunject alternative names = auth.captive, logout.captive, block.captive, ftpclient.captive, sslvpn.captive

Если администратор не загрузил свой собственный сертификат для обслуживания этой роли, то NGFW самостоятельно в автоматическом режиме перевыпускает данный сертификат при изменении администратором одного из доменов на странице Настройки (домены для auth.captive, logout.captive, block.captive, ftpclient.captive, sslvpn.captive).

Примечание Если администратор использует отдельный сертификат для домена Captive-портала, то он обязательно должен в сертификате в расширении Subject Alternative name добавить не только свой домен Auth captive-портала, но также и фиксированный домен cert.captive. Если cert.captive не добавить, то при аутентификации через сертификат в браузере будет выдаваться ошибка безопасности.

SSL инспектирование

Сертификат класса удостоверяющего центра. Он используется для генерации SSL-сертификатов для интернет-хостов, для которых производится перехват HTTPS, SMTPS, POP3S трафика. Например, при перехвате HTTPS-трафика сайта yahoo.com оригинальный сертификат, выданный:

Subject name = yahoo.com

Issuer name = VeriSign Class 3 Secure Server CA — G3,

подменяется на

Subject name = yahoo.com

Issuer name = компания, как она указана в сертификате центра сертификации, заведенного в NGFW.

Данный сертификат также используется для создания сертификата по умолчанию для роли SSL Captive-портала.

SSL инспектирование (промежуточный)

Промежуточный сертификат в цепочке удостоверяющих центров, которая использовалась для выдачи сертификата для инспектирования SSL. Для корректной работы необходим только публичный ключ сертификата.

SSL инспектирование (корневой)

Корневой сертификат в цепочке удостоверяющих центров, которая использовалась для выдачи сертификата для инспектирования SSL. Для корректной работы необходим только публичный ключ сертификата.

Пользовательский сертификат

Сертификат, который назначается пользователю NGFW. Пользователь может быть, как заведен локально, так и получен из LDAP. Сертификат может быть использован для авторизации пользователей при их доступе к опубликованным ресурсам с помощью правил reverse-прокси.

УЦ для авторизации в веб-консоли

Сертификат удостоверяющего центра для доступа к веб-консоли. Для успешной авторизации сертификат администратора должен быть подписан сертификатом этого типа.

SAML server

Используется для работы NGFW с сервером SSO SAML IDP. Подробно о настройке работы NGFW с сервером авторизации SAML IDP смотрите в соответствующем разделе руководства.

Веб-портал

Сертификат, используемый для веб-портала. Если данный сертификат не указан явно, то NGFW использует сертификат SSL Captive-портала, выпущенный сертификатом для инспектирования SSL. Подробно о настройке веб-портала смотрите в соответствующем разделе руководства.

Сертификатов для SSL веб-консоли, SSL Captive-портала и сертификатов SSL-инспектирования может быть несколько, но только один сертификат каждого типа может быть активным и использоваться для выполнения своих задач. Сертификатов типа УЦ для авторизации в веб-консоли может быть несколько, и каждый из них может быть использован для проверки подлинности сертификатов администраторов.

Для того чтобы создать новый сертификат, необходимо выполнить следующие действия:

Наименование

Описание

Шаг 1. Создать сертификат

Нажать на кнопку Создать в разделе Сертификаты.

Шаг 2. Заполнить необходимые поля

Указать значения следующих полей:

  • Название — название сертификата, под которым он будет отображен в списке сертификатов.

  • Описание — описание сертификата.

  • Страна — страна, в которой выписывается сертификат.

  • Область или штат — область или штат, в котором выписывается сертификат.

  • Город — город, в котором выписывается сертификат.

  • Название организации — название организации, для которой выписывается сертификат.

  • Common name — имя сертификата. Рекомендуется использовать только символы латинского алфавита для совместимости с большинством браузеров.

  • E-mail — email вашей компании.

Шаг 3. Указать, для чего будет использован данный сертификат

После создания сертификата необходимо указать его роль в NGFW. Для этого необходимо выделить необходимый сертификат в списке сертификатов, нажать на кнопку Редактировать и указать тип сертификата (SSL веб-консоли, инспектирование SSL, УЦ для авторизации в веб-консоли). В случае, если вы выбрали SSL веб-консоли, NGFW перезагрузит сервис веб-консоли и предложит вам подключиться уже с использованием нового сертификата. Сертификат инспектирования SSL начинает работать немедленно после того, как его выбрали. Более детально об инспектировании HTTPS смотрите в главе Инспектирование SSL.

NGFW позволяет экспортировать созданные сертификаты и импортировать сертификаты, созданные на других системах, например, сертификат, выписанный доверенным удостоверяющим центром вашей организации.

Для экспорта сертификата необходимо:

Наименование

Описание

Шаг 1. Выбрать сертификат для экспорта

Выделить необходимый сертификат в списке сертификатов.

Шаг 2. Экспортировать сертификат

Выбрать тип экспорта:

  • Экспорт сертификата — экспортирует данные сертификата в der-формате без экспортирования приватного ключа сертификата. Используйте файл, полученный в результате экспорта сертификата для инспектирования SSL, для установки его в качестве локального удостоверяющего центра на компьютеры пользователей. Подробнее об этом читайте в приложении Установка сертификата локального удостоверяющего центра.

  • Экспорт CSR — экспортирует CSR сертификата, например, для подписи его удостоверяющим центром.

ПримечаниеРекомендуется сохранять сертификат для возможности его последующего восстановления.

ПримечаниеВ целях безопасности UserGate не разрешает экспорт приватных ключей сертификатов.

ПримечаниеПользователи могут скачать себе для установки сертификат инспектирования SSL с UserGate по прямой ссылке: http://UserGate_IP:8002/cps/ca

Для импорта сертификата необходимо иметь файлы сертификата и — опционально — приватного ключа сертификата и выполнить следующие действия:

Наименование

Описание

Шаг 1. Начать импорт

Нажать на кнопку Импорт.

Шаг 2. Заполнить необходимые поля

Указать значения следующих полей:

  • Название — название сертификата, под которым он будет отображен в списке сертификатов.

  • Описание — описание сертификата.

  • Файл сертификата: загрузите файл, содержащий данные сертификата.

  • Приватный ключ: загрузите файл, содержащий приватный ключ сертификата.

  • Пароль для приватного ключа, если таковой требуется.

  • Цепочка сертификатов – файл, содержащий сертификаты вышестоящих центров сертификации, которые участвовали в создании сертификата. Необязательное поле.

Использование корпоративного УЦ для создания сертификата инспектирования SSL

Если в компании уже существует внутренний УЦ или цепочка удостоверяющих центров, то можно указать в качестве сертификата для инспектирования SSL сертификат, созданный внутренним УЦ. В случае, если внутренний УЦ является доверяемым для всех пользователей компании, то перехват SSL будет происходить незаметно, пользователи не будут получать предупреждение о подмене сертификата.

Рассмотрим более подробно процедуру настройки NGFW. Допустим, что в организации используется внутренний УЦ на базе Microsoft Enterprise CA, интегрированный в Active Directory. Структура УЦ следующая:

Пример структуры корпоративного УЦ

Необходимо выписать с помощью Sub CA2 сертификат для NGFW и настроить его в качестве сертификата для инспектирования SSL. Необходимо выписать сертификат UserGate SSL decrypt в качестве удостоверяющего центра.

Важно! В качестве сертификата для инспектирования SSL могут быть использованы только те импортированные сертификаты, которые соответствуют двум требованиям ниже: 

  1. Сертификат класса удостоверяющего центра (CA):

  • В расширении X509v3 Basic Constraints (RFC 5280) сертификата должен быть атрибут CA:TRUE.

  • В разделе UserGate ➜ Сертификаты консоли администратора такие сертификаты помечаются иконкой Файл сертификата УЦ слева от названия сертификата.

  1. Ограничение использования сертификата не установлено или в его назначении в явном виде указаны атрибуты Digital signature и Certificate signing.

  • В сертификате не использованы никакие атрибуты расширения X509v3 Key Usage (RFC 5280). 

    • В столбце Назначение сертификата раздела UserGate ➜ Сертификаты консоли администратора для такого сертификата будет указано Отсутствует

  • Если в сертификате используется расширение X509v3 Key Usage, то для инспектирования SSL обязательно должны присутствовать атрибуты digitalSignature и keyCertSign. 

    • В столбце Назначение сертификата раздела UserGate ➜ Сертификаты консоли администратора для такого сертификата будет указано Digital signature и Certificate signing

ПримечаниеUserGate не поддерживает алгоритм подписи rsassaPss. Необходимо, чтобы вся цепочка сертификатов, которая используется для выписывания сертификата для инспектирования SSL, не содержала данного алгоритма подписи.

Для выполнения этой задачи следует выполнить следующие шаги:

Наименование

Описание

Шаг 1. Создать CSR-запрос на создание сертификата в NGFW.

Нажать на кнопку Создать ➜ Новый CSR. Заполнить необходимые поля и создать CSR. Будет создан приватный ключ и файл запроса. С помощью кнопки Экспорт скачать файл запроса.

Шаг 2. Создать сертификат на основе подготовленного CSR.

В Microsoft CA создать сертификат на основе полученного на предыдущем шаге CSR-файла с помощью утилиты certreq:

certreq.exe -submit -attrib "CertificateTemplate:SubCA" HTTPS_csr.pem

или с помощью веб-консоли Microsoft CA, указав в качестве шаблона «Подчиненный центр сертификации». Обратитесь к документации Microsoft за более подробной информацией. По окончании процедуры вы получите сертификат (публичный ключ), подписанный УЦ Sub CA2.

Шаг 3. Скачать полученный сертификат.

Из веб-консоли Microsoft CA скачать созданный сертификат (публичный ключ).

Шаг 4. Загрузить сертификат в созданный ранее CSR.

В NGFW выбрать созданный ранее CSR и нажать кнопку Редактировать. Загрузить файл сертификата и нажать Сохранить.

Шаг 5. Указать тип сертификата – инспектирование SSL.

В NGFW выбрать созданный ранее CSR и нажать кнопку Редактировать. В поле Используется указать SSL инспектирование.

Шаг 6. Скачать сертификаты для промежуточных УЦ (Sub CA1 и Sub CA2).

В веб-консоли Microsoft CA выбрать и скачать сертификаты (публичные ключи) для УЦ Sub CA1 и Sub CA2.

Шаг 7. Загрузить сертификаты Sub CA1 и Sub CA2 в NGFW.

С помощью кнопки Импорт загрузить скачанные на предыдущем шаге сертификаты для Sub CA1 и Sub CA2.

Шаг 8. Установить тип — инспектирование SSL (промежуточный) для сертификатов Sub CA1 и Sub CA2.

В UserGate выбрать загруженные сертификаты и нажать кнопку Редактировать. Указать в поле ИспользуетсяИнспектирование SSL (промежуточный) для обоих сертификатов.

Шаг 9. Загрузить сертификат Root CA в UserGate (опционально).

С помощью кнопки Импорт загрузить корневой сертификат организации в NGFW. С помощью кнопки Редактировать указать в поле ИспользуетсяИнспектирование SSL (корневой).

Профили клиентских сертификатов

Профиль клиентского сертификата позволяет управлять сертификатами для обеспечения безопасности и подтверждения подлинности в сетевых соединениях. В профиле указываются сертификаты УЦ, методы проверки актуальности пользовательских сертификатов, методы выбора имени пользователя для аутентификации. 

Профиль клиентского сертификата используется для валидации предоставленного клиентом сертификата. Сертификат клиента проверяется на валидность для каждого сертификата УЦ из списка.

При выборе режима аутентификации посредством сертификатов (PKI) указывается сконфигурированный ранее профиль клиентского сертификата, который в дальнейшем можно будет использовать в различных подсистемах NGFW, например, Captive-портал, VPN, web-портал, reverse proxy.

Чтобы создать профиль клиентского сертификата, необходимо в разделе Настройки ➜ UserGate ➜ Профили клиентских сертификатов  нажать на кнопку Добавить и указать необходимые параметры:

Наименование

Описание

Название

Название профиля клиентских сертификатов.

Описание

Опциональное описание профиля.

Получать имя пользователя из

Выбор поля в сертификате, по которому определяется имя пользователя, используемое при аутентификации:

  • Common-name —  доменное имя или имя хоста в поле Subject, для которых предназначен сертификат.

  • Subject altname email — для определения имени пользователя используется параметр с префиксом email в расширении SAN (Subject Alternative Name).

  • Principal name — для определения имени пользователя используется параметр Universal Principal Name (UPN), содержащийся в поле otherName в расширении SAN.

Если в полях расширения SAN сертификата указано несколько имен UPN или несколько адресов email, берется первый, указанный в сертификате.

Сертификаты УЦ

Сертификаты УЦ, назначаемые профилю.

Список сертификатов удостоверяющих центров. Используется для валидации предоставленного клиентом сертификата. Сертификат клиента проверяется на валидность для каждого сертификата УЦ из списка. Перебор списка идет сверху вниз.

Проверка отозванных сертификатов

В списках отзыва сертификатов (CRL) содержатся сертификаты, которые были отозваны и больше не могут использоваться. В этот список входят сертификаты, срок действия которых истек или они были скомпрометированы.

Параметр для проверки состояния отзыва сертификатов:

  • Не проверять — не проверять ни один сертификат.

  • Вся цепочка — проверять все сертификаты в цепочке и требовать, чтобы они все были валидными.

  • Сертификат пользователя  — проверять только сертификат клиента.

  • Считать валидным, если статус неизвестен — если проверить CRL не удалось по какой-то причине, то он считается валидным (при этом он он всё равно проверяется и может вернуть статус invalid, если сертификат есть в списке отозванных).

Тайм-аут проверки

Интервал времени, по истечению которого NGFW перестает ожидать ответа от службы списков отзыва сертификатов.

Расширение системного раздела

Для расширения системного раздела с сохранением конфигурации и данных узла UserGate необходимо выполнить следующие шаги:

Наименование

Описание

Шаг 1. Добавить дополнительный виртуальный диск.

Средствами гипервизора добавить новый диск необходимого размера в свойствах виртуальной машины UserGate.

Шаг 2. Расширить размер раздела в системных утилитах.

В меню загрузки узла UserGate войти в раздел Support menu.

В открывшемся разделе выбрать Expand data partition и запустить процесс расширения раздела.

Шаг 3. Проверить размер системного раздела.

После завершения процесса расширения загрузить узел и в разделе Дашборд  Диски проверить размер системного раздела.

Примечание Расширение системного раздела путем увеличения размера имеющегося диска виртуальной машины возможно только при сбросе узла до заводских настроек, т.е. при выполнении операции factory reset.