1.1. Настройка UserGate с одним интерфейсом¶

Подключите интерфейс eth0 UserGate к коммутатору локальной сети, подключите монитор и клавиатуру (в случае аппаратной платформы) и включите питание.

При первом включении UserGate подтвердите начальную инициализацию.

При наличии в сети DHCP-сервера выделенный адрес интерфейса будет отображён в веб-консоли, при отсутствии DHCP-сервера задайте адрес интерфейса командой CLI-консоли:

UTM> iface config -name eth0 -ipv4 A.B.C.D/M -enabled true -mode static

где A.B.C.D/М - выделенный адрес и маска локальной сети.

С компьютера локальной сети откройте в браузере в веб-консоль по ссылке https://A.B.C.D:8001/ где A.B.C.D - назначенный или выделенный адрес интерфейса UserGate.

При первом подключении к веб-консоли выберите язык, часовой пояс и задайте логин/пароль администратора (всё это можно будет позже изменить).

В веб-консоли проверьте настройки Шлюза по умолчанию и DNS (Главная консоль - Сеть - Шлюзы и DNS соответственно), при необходимости задайте.

Зарегистрируйте продукт для чего кликните по надписи "Незарегистрированная версия" в верхней части экрана и введите необходимую информацию.

Успешная регистрация является подтверждением правильных настроек параметров сети.

На странице Зоны веб-консоли (Главная консоль - Сеть - Зоны) откройте свойства зоны Trusted и на вкладке Контроль доступа отметьте чек-бокс Консоль администрирования, после чего в свойствах интерфейса eth0 на вкладке Общие выберите зону Trusted.

Перейдите на страницу Главная консоль - Политики сети - Межсетевой экран, в свойствах предустановленного правила Allow trusted to untrusted на вкладке Назначение очистите чек-бокс Untrusted и включите правило.

На странице Главная консоль - Политики сети - NAT и маршрутизация откройте свойства предустановленного правила NAT from Trusted to Untrusted и на вкладке Назначение измените зону с Untrusted на Trusted.

Настройка параметров сети UserGate выполнена, для фильтрации трафика пользователей вы можете указать адрес UserGate как HTTP-прокси (по умолчанию порт 8090) или как шлюз по умолчанию.

1.2. Настройка UserGate с двумя интерфейсами.¶

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

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

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

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

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

• Задать IP-адреса для каждого из физически скоммутированого интерфейса

• Задать настройки маршрутизации

• Задать настройки Domain Name Services (DNS).

Для настройки IP-адресов, необходимо определить, какие физические интерфейсы скоммутированы. Номера интерфейсов на устройстве, либо в виртуальной машине напрямую соответствуют интерфейсам в консоли администратора. Например, интерфейс “0” на устройстве, будет соотнесен с интерфейсом “Eth0” в консоли администратора.

Подключите интерфейс eth0 UserGate к коммутатору локальной сети, к интерфейсу eth1 подключите кабель от провайдера, подключите монитор и клавиатуру (в случае аппаратной платформы) и включите питание.

При первом включении UserGate подтвердите начальную инициализацию.

При наличии в локальной сети DHCP-сервера выделенный адрес интерфейса будет отображён в веб-консоли, при отсутствии DHCP-сервера задайте адрес интерфейса командой CLI-консоли:

UTM> iface config -name eth0 -ipv4 A.B.C.D/M -enabled true -mode static

где A.B.C.D/М - выделенный адрес и маска локальной сети.

С компьютера локальной сети откройте в браузере в веб-консоль по ссылке https://A.B.C.D:8001/ где A.B.C.D - назначенный или выделенный адрес интерфейса UserGate.

При первом подключении к веб-консоли выберите язык, часовой пояс и задайте логин/пароль администратора (всё это можно будет позже изменить).

На странице Интерфейсы (Главная консоль - Сеть - Интерфейсы) в свойствах интерфейса eth1 задайте IP-адрес и маску и включите интерфейс, сконфигурируйте Шлюз по умолчанию и DNS (Главная консоль - Сеть - Шлюзы и DNS соответственно).

При наличии двух или более шлюзов возможны 2 варианта работы:

• Балансировка трафика между шлюзами. Установить флажок Балансировка и указать Вес каждого шлюза. В этом случае весь трафик в интернет будет распределен между шлюзами в соответствии с указанными весами (чем больше вес, тем большая доля трафика идет через шлюз).

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

Зарегистрируйте продукт для чего кликните по надписи "Незарегистрированная версия" в верхней части экрана и введите необходимую информацию.

Успешная регистрация является подтверждением правильных настроек параметров сети.

На странице Зоны веб-консоли (Главная консоль - Сеть - Зоны) откройте свойства зоны Trusted и на вкладке Контроль доступа отметьте чек-бокс Консоль администрирования, после чего в свойствах интерфейса eth0 на вкладке Общие выберите зону Trusted.

Перейдите на страницу Главная консоль - Политики сети - Межсетевой экран, включите предустановленное правило Allow trusted to untrusted.

Настройка параметров сети UserGate выполнена, на компьютерах пользователей вы можете указать адрес интерфейса локальной сети UserGate как HTTP-прокси (по умолчанию порт 8090) или как шлюз по умолчанию.

1.3. Router on a Stick¶

Router-on-a-stick — это термин, часто используемый для описания настройки, которая состоит из маршрутизатора (в нашем случае — устройства UserGate) и коммутатора, подключенных с помощью одного канала Ethernet, настроенного как TRUNK-канал. В этой настройке порты коммутатора принадлежат различным VLAN, и UserGate выполняет всю маршрутизацию между различными сетями/VLAN. Иными словами, на единственном порту UserGate настраиваются подинтерфейсы, которые принадлежат разным VLAN и имеют разные IP адреса. По сути это соответствует способу внедрения UserGate с двумя интерфейсами, описанному выше, только в качестве интерфейсов используются саб-интерфейсы.

Для конфигурации данной архитектуры произведите следующие настройки.

1. В веб-консоли администратора, зайдите в настройки сетевых интерфейсов. Главная консоль \\ Сеть \\ Интерфейсы.

2. Нажмите на кнопку Добавить и из выпадающего меню выберите опцию Добавить VLAN.

3. В открывшемся окне, в пункте Тип интерфейса, установите значение Layer 3.

4. Укажите корректный номер VLAN в пункте Тег VLAN.

5. Выберите интерфейс, который вы скоммутировали для работы.

6. В пункте Зона укажите зону, к которой будет принадлежать создаваемый виртуальный интерфейса.

7. Активируйте интерфейс, поставив галку в пункте Вкл.

Повторите описанные действия для других виртуальных интерфейсов.

1.4. прозрачный мост¶

Сетевой мост работает на канальном уровне сетевой модели OSI (L2), при получении из сети кадра сверяет MAC-адрес последнего и, если он не принадлежит данной подсети, передает (транслирует) кадр дальше в тот сегмент, которому предназначался данный кадр; если кадр принадлежит данной подсети, мост ничего не делает.

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

При выборе режима Layer 2 создаваемому мосту не нужно назначать IP-адрес и прописывать маршруты и шлюзы для его корректной работы. В данном режиме мост работает на уровне MAC-адресов, транслируя пакет из одного сегмента в другой. В этом случае невозможно использовать правила Контентной фильтрации и Mail security.

Если мост создается в ПАК UserGate, в котором используется сетевая карта, поддерживающая режим байпас, то можно объединить 2 интерфейса в байпас-мост. Байпас-мост автоматически переключает два выбранных интерфейса в режим байпас (закорачивает их, пропуская весь трафик мимо UserGate) в случаях если:

• Электропитание ПАК UserGate отключено

• Система внутренней диагностики обнаружила проблему в работе ПО UserGate.

Более подробно о сетевых интерфейсах, поддерживающих режим байпас смотрите в спецификации на оборудование ПАК UserGate.

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

1. В веб-консоли администратора, зайдите в настройки сетевых интерфейсов. Главная консоль \\ Сеть \\ Интерфейсы.

2. Нажмите на кнопку Добавить и из выпадающего меню выберите опцию Добавить мост.

3. В открывшемся окне, в пункте Тип интерфейса, установите значение Layer 2.

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

5. В разделе Интерфейсы моста выберите два интерфейса, которые вы скоммутировали для работы в данном режиме.

Если ваше оборудование поддерживает режим работы Байпас-моста, в разделе Интерфейсы байпас моста, выберите соответствующие интерфейсы

Активируйте мост, поставив галку в пункте Вкл.

1.5. прозрачный мост¶

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

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

Если мост создается в ПАК UserGate, в котором используется сетевая карта, поддерживающая режим байпас, то можно объединить 2 интерфейса в байпас-мост. Байпас-мост автоматически переключает два выбранных интерфейса в режим байпас (закорачивает их, пропуская весь трафик мимо UserGate) в случаях если:

• Электропитание ПАК UserGate отключено

• Система внутренней диагностики обнаружила проблему в работе ПО UserGate.

Более подробно о сетевых интерфейсах, поддерживающих режим байпас смотрите в спецификации на оборудование ПАК UserGate.

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

8. В веб-консоли администратора, зайдите в настройки сетевых интерфейсов. Главная консоль \\ Сеть \\ Интерфейсы.

9. Нажмите на кнопку Добавить и из выпадающего меню выберите опцию Добавить мост.

10. В открывшемся окне, в пункте Тип интерфейса, установите значение Layer 3.

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

12. В разделе Интерфейсы моста выберите два интерфейса, которые вы скоммутировали для работы в данном режиме.

13. Если ваше оборудование поддерживает режим работы Байпас-моста, в разделе Интерфейсы байпас моста, выберите соответствующие интерфейсы

14. В закладке Сеть, выберите предпочитаемый метод назначения сетевых параметров для моста – DHCP либо Статический. При выборе статического назначения параметров, задайте сетевые параметры вручную.

Активируйте мост, поставив галку в пункте Вкл.

1.6. WCCP, Виртуально в разрыв¶

Протокол Web Cache Communication Protocol (WCCP) является разработанным Cisco протоколом, который позволяет определенным маршрутизаторам Cisco и коммутаторам прозрачно перенаправлять трафик на кеширующее устройство (прокси), такое как устройство UserGate . В этой главе описываются концепции WCCP, которые необходимо понять для развертывания WCCP на устройствах UserGate.

Когда устройство UserGate не находится в физическом пути клиентов и серверов, оно должно полагаться на внешнее устройство—либо коммутатор уровня 4 (L4), либо маршрутизатор с поддержкой WCCP, для перенаправления пакетов к нему для прозрачного проксирования. Этот тип развертывания известен как развертывание виртуально в разрыв. WCCP рекомендуется использовать для схемы виртуально в разрыв, поскольку он обеспечивает следующие преимущества:

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

Безопасность — вы можете защитить группу служб WCCP паролем, чтобы к ней могли присоединиться только авторизованные устройства. Кроме того, можно настроить списки управления доступом (ACL) на маршрутизаторе, чтобы ограничить доступ только к определенным устройствам UserGate.

Отказоустойчивость — в случае отсутствия устройств UserGate, доступных для перенаправления трафика, маршрутизатор перенаправляет трафик на исходный адрес назначения.

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

В развертываниях прозрачных прокси клиент не знает, что он взаимодействует с UserGate, а не с конечным сервером (КС). Таким образом, пакет от клиента адресован КС. Маршрутизатор проверяет трафик на интерфейсах с поддержкой WCCP (входящий или исходящий в зависимости от конфигурации) и определяет, следует ли перенаправлять его на основе правил, согласованных маршрутизатором и устройствами UserGate.

Процесс работает следующим образом:

1. Клиент отправляет пакет, адресованный для КС.

2. Маршрутизатор с поддержкой WCCP перенаправляет пакет на UserGate.

3. UserGate определяет, что с ним делать на основе политик, настроенных для данного типа трафика. Если он не может обслуживать запрос локально (например, возвращая страницу из своего локального кэша), он отправляет запрос указанному КС от имени клиента.

4. Ответ КС направляется (или перенаправляется в зависимости от конфигурации) обратно в UserGate.

5. Затем UserGate пересылает ответ обратно клиенту.

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

1. В веб-консоли администратора, зайдите в настройки сетевых интерфейсов. Главная консоль \\ UserGate \\ Настройки.

2. В разделе Настройка WCCP произведите следующие конфигурации:

   • Укажите IP-адрес WCCP-сервера в параметре Адрес сервера WCCP.

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

   • Если вам требуется инспектировать HTTPS трафик, активируйте передачу этого трафика установив параметр Поддержка WCCP в режим Вкл.

   • По умолчанию, клиент WCCP на устройстве UserGate сконфигурирован на прием сервис группы с индексом 0, что соответствуют HTTP трафику. Обратитесь к документации производителя вашего сетевого оборудования за дополнительной информацией.

   • Активируйте функцию WCCP клиента установив параметр WCCP в режим Вкл.

1.7. Policy Based Routing, виртуально в разрыв¶

Маршрутизация на основе политик (policy based routing, PBR) позволяет маршрутизировать трафик на основании заданных, на вашем сетевом оборудовании, политик. Когда пакеты достигают UserGate, используя PBR, IP-адрес назначения пакетов-это адрес целевого сервера, но MAC-адрес назначения-это адрес принимающего UserGate. В данной конфигурации UserGate выступает в качестве одного их последующих хопов маршрутизации на пути пакета от клиента к серверу в Интернете.

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

1.8. Явный веб-прокси¶

Вы можете настроить каждую клиентскую рабочую станцию в своей сети для направления веб-запросов на устройство UserGate. Этот тип развертывания называется явным прокси. После того как клиент настроен для явного прокси, все пользовательские веб-запросы отправляются на устройство, а не на целевой сервер. При этом клиентское ПО, в котором прокси сервер не настроен в явном виде, либо приложения не обладающие возможностью работать через прокси, будут отправлять запросы минуя Usergate – напрямую на шлюз по умолчанию. Затем UserGate определяет, разрешить или запретить запрос на основе политики веб-доступа.

За исключением стандартных процедур определения IP-адресов сетевых портов, настроек DNS, маршрутов сети, необходимо обратить внимание на несколько следующих параметров:

1. В стандартных настройках решения, единственное активированное правило Межсетевого экрана - «Блокировать все». Таким образом после первоначальной конфигурации устройства, трафик не будет отсылаться в сеть Интернет. Необходимо разрешить транзитный трафик.

2. Порт прокси сервера по-умолчанию указываются в разделе UserGate \\ Настройки \\ HTTP(S)-прокси порт

3. Зона, назначенная на интерфейс, который будет принимать запросы пользователей, должна быть настроена на прием HTTP(S)-запросов. Чтобы убедиться, в корректной конфигурации зоны необходимо перейти в раздел Сеть \\ Зоны, выбрать необходимую зону, перейти в закладку Контроль доступа и убедиться, что настройка HTTP(S)-прокси активирована.

1.9. Мониторинг Mirror-порта¶

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

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

Чтобы сконфигурировать UserGate, в режиме СОВ на Mirror-порте, произведите следующие настройки:

1. В веб-консоли администратора, зайдите в настройки сетевых интерфейсов. Главная консоль \\ Сеть \\ Интерфейсы.

2. Выберите интерфейс, нажмите на кнопку Редактировать. В открывшемся окне, в закладке Общие, в пункте Тип интерфейса, установите значение Mirror.

3. Активируйте интерфейс, поставив галку в пункте Вкл.

Конфигурация Зоны, для этого порта значения не имеет.

1.10. Настройка подключения отказоустойчивого кластера к двум провайдерам¶

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

В данной схеме, устройства Usergate настроены в режиме отказоустойчивого кластера по схеме active-pasive.

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

Далее нужно активировать подсистему “Проверка сети” и указать узел в интернете, который система будет периодически проверять на предмет доступности. Когда ресурс перестанет быть доступным, система переключится на следующий в списке шлюз и будет использовать его по-умолчанию:

На следующем рисунке, обратите внимание, что основной шлюз по-умолчанию стал недоступен (красная точка – индикатор доступности адреса):

Кластер переключился на запасной шлюз:

2.1. Авторизация с помощью Kerberos¶

Авторизация Kerberos позволяет прозрачно (без запроса имени пользователя и его пароля) авторизовать пользователей домена Active Directory. При авторизации через Kerberos сервер UserGate работает с контроллерами домена, которые выполняют проверку пользователя, который получает доступ в интернет.

1. Создадим DNS записи для сервера UserGate. Необходимо создавать записи типа A, не создавайте записи типа CNAME.

Где 10.1.10.21 IP адрес интерфейса UserGate подключенного в зону Trusted.

2. Создадим пользователя в домене AD, например kerb@kraftec.net с опцией password never expires (срок действия пароля не ограничен). Установим пароль пользователю kerb.

3. Создадим keytab файл на контроллере домена. Выполним следующую команду из-под администратора (команда в одну строку!):

ktpass.exe /princ HTTP/auth.kraftec.net@KRAFTEC.NET /mapuser kerb@KRAFTEC.NET /crypto ALL /ptype krb5_NT_PRINCIPAL /pass * /out C:\utm.keytab

Введем пароль пользователя kerb.

auth.kraftec.net — DNS — запись, созданная для сервера UserGate в пункте 1.

KRAFTEC.NET — Kerberos realm domain, обязательно большими буквами.

kerb@KRAFTEC.NET — имя пользователя в домене, созданное в пункте 2, имя realm-домена обязательно большими буквами.

4. В разделе DNS — Системные DNS серверы укажем IP-адреса контроллеров домена.

5. Настроим синхронизацию времени с контроллером домена.

В разделе Настройки → Настройка времени сервера, установим Основной NTP-сервер — IP адрес контроллера домена. В качестве запасного — опционально — укажем IP адрес другого контроллера домена.

6. Изменим адрес домена Auth Captive-портала.

В разделе Настройки →Модули, изменим названия Доменов на созданные доменные имена в пункте 1.

7. Создадим LDAP - коннектор для получения информации о пользователях и группах Active Directory и загрузим в него keytab - файл.

Перейдем в раздел Пользователи и устройства → Серверы авторизации, нажмем кнопку Добавить → Добавить LDAP коннектор.

В свойствах коннектора LDAP внесем следующие настройки:

Вкладка Настройки

Название: произвольное название LDAP - коннектора.

Доменное имя LDAP или IP-адрес: IP-адрес сервера контроллера домена.

Bind DN («логин»): внесем доменного пользователя в формате DOMAIN\username или username@domain для подключения к серверу LDAP. Данный пользователь уже должен быть заведен в домене.

Пароль: пароль пользователя для подключения к домену.

Вкладка Домены LDAP

Нажмем кнопку Добавить и внесем доменное имя LDAP

Вкладка Домены LDAP

Нажмем кнопку Загрузить keytab файл и выберем файл, созданный в пункте 3.

После внесения настроек нажмем на кнопку Проверить соединение. Если настройки внесены верно, получим сообщение об успехе.

Сохраним настройки LDAP коннектора нажав на кнопку Сохранить.

8. Создадим профиль авторизации для Kerberos.

В разделе Пользователи и устройства → Профили авторизации, нажмем кнопку Добавить.

Вкладке Общие.

Название: произвольное название профиля авторизации.

Вкладка Методы аутентификации

Нажмем кнопку Добавить и выберем Аутентификация Kerberos.

Сохраним настройки профиля авторизации нажав на кнопку Сохранить.

9. Создадим Captive-профиль.

В разделе Пользователи и устройства → Captive-профили, нажмем кнопку Добавить.

Вкладка Общие

Название: произвольное название captive — профиля.

Профиль авторизации: выберем ранее созданный профиль авторизации.

Сохраним настройки Captive-профиля нажав на кнопку Сохранить.

10. Создадим правило Captive-портала для авторизации Kerberos.

В разделе Пользователи и устройства → Captive-портал, нажмем кнопку Добавить.

Вкладка Общие

Название: произвольное название правила captive-портала.

Captive-профиль: выберем ранее созданный captive-профиль.

Сохраним настройки правила Captive-портала нажав на кнопку Сохранить.

11. Разрешить доступ к сервису HTTP(S) для зоны.

В разделе Зоны разрешить доступ к сервису HTTP(S)-прокси для зоны, к которой подключены пользователи, авторизующиеся с помощью Kerberos.

12. Произведем настройки на компьютере пользователя.

Настройка прокси-сервера для авторизации в стандартном режиме.

Панель управления → Свойства браузера → Подключения → Настройка сети → Прокси-сервер и указать FQDN (полное имя) и порт интерфейса UserGate, к которому будут подключены пользователи.

Настройка авторизации в прозрачном режиме.

Панель управления → Свойства браузера →безопасность → выберите зону Интернет → Уровень безопасности → Другой → Проверка подлинности пользователя и установите Автоматический вход в сеть с текущим именем пользователя и пароля.

2.2. Проверка корректности выпуска keytab-файла для Kerberos авторизации¶

В случае не корректной работы Keytab файла или Kerberos в целом, необходимо выполнить проверку по следующей инструкции:

1. Необходимо установить Ubuntu 14.04.5

2. Необходимо выполнить обновления - в терминале выполнить:

sudo apt-get update

3. Установить необходимый пакет для использования команды kinit - в терминале выполнить:

sudo apt-get install krb5-user

4. Переименовать созданный на контроллере домена Keytab файл в krb5.keytab

5. Поместить данный krb5.keytab файл в директорию /etc/

6. Выполнить проверку Keytab файла следующей командой - в терминале выполнить

kinit -k HTTP/example_utm.entensys.ru

где example_utm.example.ru - DNS-запись сервера UserGate), ошибок быть не должно (пустая строка

7. Получить результат можно выполнив команду klist в терминале, пример вывода ниже

Ticket cache: FILE:/tmp/krb5cc_1000Default principal: HTTP/example_utm.example.loc@EXAMPLE.LOC

Valid starting Expires Service principal08/08/2017 00:53:02 08/08/2017 10:53:02 krbtgt/EXAMPLE.LOC@EXAMPLE.LOC renew until 08/09/2017 00:53:02

8. На этом проверка закончена Keytab файл создан корректно.

Дополнительно:

На контроллере домена команда: "setspn.exe -X" проверяет уникальность PRINCIPAL-записей.

2.3. Авторизация с помощью NTLM¶

Авторизация NTLM позволяет прозрачно (без запроса имени пользователя и его пароля) авторизовать пользователей домена Active Directory. При авторизации с помощью NTLM сервер UserGate работает с контроллерами домена, которые выполняют проверку пользователя, который получает доступ в интернет.

1. Создадим LDAP - коннектор для получения информации о пользователях и группах Active Directory.

Перейдем в раздел Пользователи и устройства → Серверы авторизации, нажмем кнопку Добавить → Добавить LDAP коннектор.

В свойствах коннектора LDAP внесем следующие настройки:

Вкладка Настройки

Название: произвольное название LDAP - коннектора.

Доменное имя LDAP или IP-адрес: IP-адрес сервера контроллера домена.

Bind DN («логин»): внесем доменного пользователя в формате DOMAIN\username или username@domain для подключения к серверу LDAP. Данный пользователь уже должен быть заведен в домене.

Пароль: пароль пользователя для подключения к домену.

Вкладка Домены LDAP

Нажмем кнопку Добавить и внесем доменное имя LDAP

После внесения настроек нажмем на кнопку Проверить соединение. Если настройки внесены верно, получим сообщение об успехе.

Сохраним настройки LDAP коннектора нажав на кнопку Сохранить.

2. Создадим NTLM — сервер авторизации.

В разделе Пользователи и устройства → Серверы авторизации, нажмем кнопку Добавить → Добавить NTLM-сервер.

Название: произвольное название сервера авторизации.

IP-адрес: IP адрес контроллера домена.

Домен Windows: доменное имя.

Сохраним настройки NTLM сервера нажав на кнопку Сохранить.

3. Создадим профиль авторизации для NTLM сервера.

В разделе Пользователи и устройства → Профили авторизации, нажмем кнопку Добавить.

Вкладке Общие.

Название: произвольное название профиля авторизации.

Вкладка Методы аутентификации

Нажмем кнопку Добавить и выберем ранее созданный NTLM сервер.

Сохраним настройки профиля авторизации нажав на кнопку Сохранить.

4. Создадим Captive-профиль.

В разделе Пользователи и устройства → Captive-профили, нажмем кнопку Добавить.

Вкладка Общие

Название: произвольное название captive — профиля.

Профиль авторизации: выберем ранее созданный NTLM профиль.

Сохраним настройки Captive-профиля нажав на кнопку Сохранить.

5. Создадим правило Captive-портала для NTLM авторизации.

В разделе Пользователи и устройства → Captive-портал, нажмем кнопку Добавить.

Вкладка Общие

Название: произвольное название правила captive-портала.

Captive-профиль: выберем ранее созданный captive-профиль.

Сохраним настройки правила Captive-портала нажав на кнопку Сохранить.

6. Настроим синхронизацию времени с контроллером домена.

В разделе Настройки → Настройка времени сервера, установим Основной NTP-сервер — IP адрес контроллера домена.

7. Создадим DNS записи для сервера UserGate.

Где 10.1.10.21 IP адрес интерфейса UserGate подключенного в зону Trusted.

8. Изменим адрес домена Auth Captive-портала.

В разделе Настройки →Модули, изменим названия Доменов на созданные доменные имена в предыдущем разделе.

9. Разрешить доступ к сервису HTTP(S) для зоны.

В разделе Зоны разрешить доступ к сервису HTTP(S)-прокси для зоны, к которой подключены пользователи, авторизующиеся с помощью NTLM.

10. Произведем настройки на компьютере пользователя.

Настройка прокси-сервера для авторизации в стандартном режиме.

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

Настройка авторизации в прозрачном режиме.

Панель управления → Свойства браузера →безопасность → выберите зону Интернет → Уровень безопасности → Другой → Проверка подлинности пользователя и установите Автоматический вход в сеть с текущим именем пользователя и пароля.

Панель управления → Свойства браузера →Безопасность → установить. Разрешить встроенную проверку подлинности Windows.

2.4. Настройка браузера Firefox для авторизации Kerberos¶

Для корректной авторизации пользователей, использующих браузер Firefox, с помощью Kerberos необходимо в браузере перейти по адресу about:config и указать значение вашего домена Active Directory в следующих конфигурационных параметрах:

network.negotiate-auth.trusted-uris

network.negotiate-auth.delegation-uris

На картинке ниже показаны измененные значения этих параметров для домена AD lab.demo:

2.5. Настройка браузера Firefox для авторизации NTLM¶

Для корректной авторизации пользователей, использующих браузер Firefox, с помощью NTLM необходимо в браузере перейти по адресу about:config и указать значение вашего домена Active Directory в следующих конфигурационных параметрах:

network.automatic-ntlm-auth.trusted-uris

На картинке ниже показаны измененные значения этих параметров для домена AD lab.demo:

2.6. Настройка браузера Chrome на Linux для авторизации Kerberos/Captive portal¶

Для авторизации пользователей доменных компьютеров удобно использовать автоматическую авторизацию Kerberos. Для пользователей, чьи компьютеры не входят в домен, авторизация Kerberos работать не будет. Удобным вариантом в этом случае будет использование двух методов авторизации - в качестве первого метода авторизации Kerberos, а в качестве второго - Captive portal. На компьютерах с ОС Windows такой вариант работает хорошо, пользователям, не сумевшим пройти авторизацию Kerberos, будет предложено ввести авторизационные данные на странице Captive-портала. Для пользователей Linux с установленным браузером Chrome необходима дополнительная настройка.

Проблема:

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

Заголовок:

HTTP/1.1 407 Authorization Required

Содержимое страницы

<html> <!-- please auth via kerberos/NTLM --> </html>

Решение:

Для подробной информации по работе с политиками в браузере, обратитесь к документации по адресу: https://www.chromium.org/administrators/linux-quick-start

1. В соответствии с инструкцией, нужно создать json-файл в директории managed:

touch /etc/opt/chrome/policies/managed/test_policy.json

Содержимое файла должно быть следующего вида:

{

"AuthServerWhitelist": "*.usergate.demo",

"AuthSchemes": "ntlm,negotiate"

}

“usergate.demo” необходимо заменить на доменное имя вашего домена.

2. В браузере Chrome открыть страницу политик about:policy.

Вы должны увидеть настройки прописанные в файле на открытой странице:

Если этих строк нет, значит браузеру не удалось загрузить политики из созданного файла. Проверьте права доступа, и другие возможные причины. Обратите внимание, различные браузеры имеют особенности в загрузке политик. Например браузер Chromium на Kali Linux автоматически не загружает описанные политики.

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

2.7. Мультифакторная аутентификация с подтверждением через email¶

Рассмотрим пример настройки двухфакторной аутентификации с подтверждением (второй фактор аутентификации), отсылаемым пользователю на его email адрес.

1. Для отправки сообщения у каждого пользователя должен быть указан адрес электронной почты в его локальной учетной записи в UserGate или в доменной учетной записи в Active Directory.

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

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

2. Создадим профиль оповещения по электронной почте, для этого перейдем в Библиотеки - Профили оповещения, нажмем кнопку Добавить - Добавить профиль оповещения SMTP и в свойствах профиля SMTP внесем следующие настройки:

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

Если проверочное письмо дошло на указанный адрес, сохраним настройки нажав на кнопку Сохранить.

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

Добавим сервер авторизации.

Перейдем в раздел Пользователи и устройства - Серверы авторизации, нажмем кнопку Добавить - Добавить LDAP коннектор.

В свойствах коннектора LDAP внесем следующие настройки:

Вкладка Настройки

Название - произвольное название сервера авторизации.

Доменное имя LDAP или IP-адрес - IP-адрес сервера контроллера домена.

Bind DN («логин») - внесем доменного пользователя в формате DOMAIN\username или username@domain для подключения к серверу LDAP. Данный пользователь уже должен быть заведен в домене.

Пароль - пароль пользователя для подключения к домену.

Вкладка Домены LDAP

Нажмем кнопку Добавить и внесем доменное имя LDAP:

После внесения настроек нажмем на кнопку Проверить соединение. Если настройки внесены верно, получим сообщение об успехе:

Сохраним настройки LDAP коннектора нажав на кнопку Сохранить.

4. Создадим профиль для мультифакторной аутентификации.

Перейдем в раздел Пользователи и устройства - Профили MFA нажмем на кнопку Добавить - MFA через email и в свойствах профиля MFA внесем следующие настройки:

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

Профиль отправки MFA - выберем ранее созданный профиль оповещения по электронной почте.

От - внесем адрес электронной почты пользователя, указанного в профиле оповещения MFA

Тема - Тема в письме

Содержимое - Тело письма.

Сохраним настройки профиля MFA нажав на кнопку Сохранить.

5. Создадим профиль авторизации.

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

Название - внесем произвольное название профиля авторизации.

Профиль MFA - Выберем ранее созданный профиль MFA.

Добавим ранее созданный LDAP коннектор, нажмем на кнопку Добавить - Сервер LDAP/Active Directory: kraftech.ru

Сохраним настройки профиля авторизации нажав на кнопку Сохранить.

6. Создадим профиль для Captive-портала.

Мультифакторная авторизация возможна только с методами аутентификации, позволяющими ввести пользователю одноразовый пароль, то есть только те, где пользователь явно вводит свои учетные данные в веб-форму страницы авторизации. В связи с этим, мультифакторная авторизация невозможна для методов аутентификации kerberos и NTLM.

Перейдем в раздел Пользователи и устройства - Captive-профили, нажмем на кнопку Добавить и в свойствах captive-профиля внесем следующие настройки:

Название - внесем произвольное название captive-профиля.

Шаблон страницы авторизации - Выберем шаблон «Captive portal user auth (RU)».

Метод идентификации - Выберем запоминать IP-адрес.

Профиль авторизации - Выберем ранее созданный профиль авторизации.

Если для авторизации пользователей мы используем LDAP коннектор, можно активировать свойство «Предлагать выбор домена AD/LDAP на странице авторизации».

Сохраним настройки captive-профиля нажав на кнопку Сохранить.

7. Создадим правило Captive-портала.

Перейдем в раздел Пользователи и устройства - Captive-портал, нажмем на кнопку Добавить и в свойствах правила captive-портала внесем следующие настройки:

Название - внесем произвольное название captive-портала.

Captive-профиль - выберем ранее созданный Captive-профиль.

Вкладки Источник, Назначение, Категории, URL, Время, можно настраивать для задания дополнительных условий выполнения правила. Правила применяются сверху вниз в том порядке, в котором совпали условия, указанные в правиле. Для срабатывания правила необходимо, чтобы совпали все условия, указанные в параметрах правила.

Сохраним настройки правила captive-портал нажав на кнопку Сохранить.

8. Настоим DNS для доменов auth.captive и logout.captive.

Служебные доменные имена auth.captive и logout.captive используется UserGate для авторизации пользователей. Если клиенты используют в качестве DNS-сервера сервер UserGate, то ничего делать не надо. В противном случае необходимо прописать в качестве IP-адреса для этих доменов IP-адрес интерфейса сервера UserGate, который подключен в клиентскую сеть.

9. Проверим работу мультифакторной авторизации.

В браузере пользователя перейдем на сайт ya.ru. Появилась страница авторизации captive-портала:

После ввода логина и пароля появится окно для ввода дополнительного кода аутентификации, который придет на электронную почту, указанную в свойстве профиля пользователя:

После ввода кода в окне авторизации, откроется запрошенный сайт - ya.ru

2.8. Мультифакторная аутентификация с подтверждением через одноразовые временные пароли (TOTP)¶

Рассмотрим пример настройки двухфакторной аутентификации с подтверждением (второй фактор аутентификации) кодом TOTP.

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

Добавим сервер авторизации.

Перейдем в раздел Пользователи и устройства - Серверы авторизации, нажмем кнопку Добавить - Добавить LDAP коннектор.

В свойствах коннектора LDAP внесем следующие настройки:

Вкладка Настройки

Название - произвольное название сервера авторизации.

Доменное имя LDAP или IP-адрес - IP-адрес сервера контроллера домена.

Bind DN («логин») - внесем доменного пользователя в формате DOMAIN\username или username@domain для подключения к серверу LDAP. Данный пользователь уже должен быть заведен в домене.

Пароль - пароль пользователя для подключения к домену.

Вкладка Домены LDAP

Нажмем кнопку Добавить и внесем доменное имя LDAP:

После внесения настроек нажмем на кнопку Проверить соединение. Если настройки внесены верно, получим сообщение об успехе:

Сохраним настройки LDAP коннектора нажав на кнопку Сохранить.

2. Создадим профиль для мультифакторной аутентификации.

Перейдем в раздел Пользователи и устройства - Профили MFA нажмем на кнопку Добавить - MFA через TOTP и в свойствах профиля MFA внесем следующие настройки:

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

Инициализация TOTP - выберем для примера Показать ключ на странице captive-портала

Показывать QR-код - для возможности сканирования кода.

Сохраним настройки профиля MFA нажав на кнопку Сохранить.

3. Создадим профиль авторизации.

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

Название - внесем произвольное название профиля авторизации.

Профиль MFA - Выберем ранее созданный профиль MFA.

Добавим ранее созданный LDAP коннектор, нажмем на кнопку Добавить - Сервер LDAP/Active Directory: kraftech.ru

Сохраним настройки профиля авторизации нажав на кнопку Сохранить.

4. Создадим профиль для Captive-портала.

Мультифакторная авторизация возможна только с методами аутентификации, позволяющими ввести пользователю одноразовый пароль, то есть только те, где пользователь явно вводит свои учетные данные в веб-форму страницы авторизации. В связи с этим, мультифакторная авторизация невозможна для методов аутентификации kerberos и NTLM.

Перейдем в раздел Пользователи и устройства - Captive-профили, нажмем на кнопку Добавить и в свойствах captive-профиля внесем следующие настройки:

Название - внесем произвольное название captive-профиля.

Шаблон страницы авторизации - Выберем шаблон «Captive portal user auth (RU)».

Метод идентификации - Выберем запоминать IP-адрес.

Профиль авторизации - Выберем ранее созданный профиль авторизации.

Если для авторизации пользователей мы используем LDAP коннектор, можно активировать свойство «Предлагать выбор домена AD/LDAP на странице авторизации».

Сохраним настройки captive-профиля нажав на кнопку Сохранить.

5. Создадим правило Captive-портала.

Перейдем в раздел Пользователи и устройства - Captive-портал, нажмем на кнопку Добавить и в свойствах правила captive-портала внесем следующие настройки:

Название - внесем произвольное название captive-портала.

Captive-профиль - выберем ранее созданный Captive-профиль.

Вкладки Источник, Назначение, Категории, URL, Время, можно настраивать для задания дополнительных условий выполнения правила. Правила применяются сверху вниз в том порядке, в котором совпали условия, указанные в правиле. Для срабатывания правила необходимо, чтобы совпали все условия, указанные в параметрах правила.

Сохраним настройки правила captive-портал нажав на кнопку Сохранить.

6. Настоим DNS для доменов auth.captive и logout.captive.

Служебные доменные имена auth.captive и logout.captive используется UserGate для авторизации пользователей. Если клиенты используют в качестве DNS-сервера сервер UserGate, то ничего делать не надо. В противном случае необходимо прописать в качестве IP-адреса для этих доменов IP-адрес интерфейса сервера UserGate, который подключен в клиентскую сеть.

7. Проверим работу мультифакторной авторизации.

В браузере пользователя перейдем на сайт ya.ru. Появилась страница авторизации captive-портала:

После ввода логина и пароля появится окно для ввода дополнительного кода аутентификации:

Получить этот код можно установив специальное приложение либо расширение в браузер, которое умеет генерировать код на основе алгоритма TOTP. Для примера мы установим расширение «Авторизация» в браузер Google Chrome:

Добавим в расширение ключ инициализации TOTP:

Расширение браузера Chrome «Авторизация» нам выдаст временный код для авторизации на портале.

После ввода кода в окне авторизации, откроется запрошенный сайт ya.ru

Для повторной авторизации на Captive портале необходимо снова воспользоваться расширением «Авторизация» где будет уже сгенерированный новый код для нашего TOTP.

2.9. Авторизация пользователей SSL VPN портала по сертификату¶

Дополнительно к авторизации пользователей SSL VPN портала по логину и паролю существует возможность настроить "прозрачную" авторизацию этих пользователей по SSL сертификату.

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

1. Для каждого пользователя выпустить SSL сертификат, в котором указаны следующие параметры применения ключа - Digital Signature, Key Encipherment и Data Encipherment.

Если для выпуска сертификата используется приложение XCA, достаточно выбрать в нём и применить шаблон HTTPS_client.

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

В том числе работают и самоподписанные сертификаты.

2. Импортировать в браузер каждого пользователя, выписанный для него сертификат вместе с закрытым ключём (обычно, формат файла .p12).

3. Импортировать в UserGate сертификаты всех пользователей (без закрытого ключа, обычно, формат файла .cer).

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

4. В настройках SSL VPN портала произвести следующие изменения:

• поставить галочку напротив настройки Авторизация пользователя по сертификату;

• убедиться, что Имя хоста SSL VPN портала указано в виде FQDN, а не IP адреса;

• использовать для самого SSL VPN портала сертификат "Автоматически", либо любой другой, зарегистрированный на UserGate и имеющий базовый тип использования Центр Сертификации.

2.10. Установка и настройка агента терминального сервера UserGate¶

Для пользователей, работающих на операционной системе Windows, существует еще один

способ идентификации - использовать специальный агент авторизации. Агент представляет

собой сервис, который передает на сервер UserGate информацию о пользователе, его имя и

IP-адрес, соответственно, UserGate будет однозначно определять все сетевые подключения

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

3.1. Развертывание образа UserGate на Hyper-V¶

К нам часто обращаются с вопросами по настройке UserGate для среды виртуализации Microsoft Hyper-V, надеюсь, что эта статья снимет множество вопросов по развертыванию нашего продукта для этой системы.

1. Первым делом необходимо скачать образ с нашего официального сайта.

2. Затем распакуем файл utm-hyperv.zip.

3. Проверим сетевые интерфейсы на хостовой машине с Hyper-V.

4. После чего создадим виртуальные коммутаторы для интерфейсов, которые нам нужны.

По умолчанию в UserGate имеются четыре зоны Management, Trusted, Untrusted и DMZ.

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

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

6. Создадим новую виртуальную машину.

7. Задаем имя виртуальной машины и папку, в которой будут храниться данные.

8. Увеличьте размер оперативной памяти виртуальной машины. Используя свойства виртуальной машины, установите минимум 8Gb и добавьте по 1Gb на каждые 100 пользователей.

9. Указываем подключение к первому созданному нами виртуальному коммутатору.

10. Выбираем виртуальный жесткий диск из папки, в которую мы распаковали скачанный файл utm-hyperv.zip.

11. Виртуальная машина создана осталось ее настроить.

12. Установим два виртуальных процессора (Количество процессоров определяем в зависимости от количества пользователей и ресурсов вашего сервера)

13. Создадим четыре сетевых адаптера и подключим их к созданным ранее виртуальным коммутаторам.

14. Увеличьте размер диска виртуальной машины. Размер диска по умолчанию составляет 20Gb, что недостаточно для хранения всех журналов и настроек. Используя свойства виртуальной машины, установите размер диска в 100Gb или более. Рекомендованный размер - 300Gb.

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

16. Теперь виртуальная машина настроена, и мы запускаем ее, нажав на Start.

За стартом можно наблюдать, подключившись к виртуальной консоли.

17. Во время первой загрузки выполнится процедура Factory reset. Во время этого шага UserGate настраивает сетевые адаптеры и увеличивает размер раздела на жестком диске до полного размера диска, увеличенного в предыдущих пунктах.

18. После перезагрузки, если в сети, подключенной к первому виртуальному коммутатору (Management) и соответственно интерфейсу eth0 есть DHCP сервер, в приглашении мы увидим адрес и порт, для управления через веб-консоль.

19. Если DHCP сервера нет, то необходимо через консоль в командной строке задать адрес для интерфейса. Заходим под логином Admin, пароль utm. С помощью команды

iface config -name eth0 -ipv4 192.168.30.66/24 -enabled true -mode static

присваиваем адрес интерфейсу eth0, который подключен первому виртуальному коммутатору (Management) и соответственно к первому сетевому адаптеру.

20. Дальнейшую настройку производим, подключившись через веб консоль по заданному адресу. На предупреждение о небезопасном соединении нажимаем на ADVANCED. Здесь приведен пример для браузера Chrome английская версия, для других браузеров картинка немного измениться.

Затем нажимаем на Proceed.

21. Выбираем язык установки и часовой пояс

22. Принимаем Лицензионное соглашение.

23. Задаем логин и пароль для администратора.

И перед нами открывается веб-консоль продукта.

24. Настраиваем доступ в интернет для последующей регистрации и работы продукта.

Интерфейс eth0 у нас уже имеет IP-адрес и ему назначена зона Management.

25. Назначаем IP-адрес для интерфейса eth1, устанавливаем зону Trusted и включаем интерфейс eth1.

26. Назначаем IP-адрес для интерфейса eth2, устанавливаем зону Untrusted и включаем интерфейс eth2. Для интерфейса eth2 укажем получение адреса по DHCP

27. Назначаем IP-адрес для интерфейса eth3, устанавливаем зону DMZ и включаем интерфейс eth3.

28. Задаем шлюз по умолчанию для интерфейса, через который будет выход в интернет. В нашем случае для выхода в интернет будет использоваться интерфейс eth2, адрес которому и шлюз присвоены по DHCP.

Для интерфейса eth0 также адрес и шлюз выданы DHCP сервером. В итоге мы видим, что у нас два шлюза.

29. Чтобы была возможность подключаться через интерфейс eth0 для управления UserGate с компьютеров в сети 192.168.30.0/24 необходимо сначала добавить маршрут в эту сеть через шлюз, который был выдан для интерфейса eth0 DHCP сервером.

30. Оставляем один шлюз по умолчанию для выхода в интернет.

31. Устанавливаем адрес DNS сервера.

32. Проверяем корректность сетевых настроек подключившись через виртуальную CLI консоль и набрав команду ping ya.ru. Если команда выполняется ping проходит, значит мы все правильно настроили и можно приступать к регистрации продукта.

33. Регистрируем продукт, для этого нажимаем на "незарегистрированная версия", вводим Пин-код продукта и заполняем регистрационные данные (латинскими буквами).

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

34. Посмотреть версию баз и ход обновления можно на вкладке Дашборд. Нажмем кнопку проверить обновления.

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

4.1. Создание сертификатов компании с помощью программы XCA¶

Для создания сертификатов будем использовать бесплатную программу управления сертификатами XCA.

Скачать данную программу можно с сайта https://www.hohnstaedt.de/xca/

Запустим XCA и создадим базу данных для хранения наших сертификатов Файл → Новая база данных.

1. Создадим сертификат удостоверяющего центра (УЦ) нашей компании.

Создадим закрытый ключ для сертификата УЦ нашей компании. Вкладка Закрытые ключи → Новый ключ.

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

Создали закрытый ключ. Теперь перейдем во вкладку Сертификаты и создадим сертификат УЦ нашей компании.

Нажмем кнопку новый сертификат

Вкладка Первоисточник

Алгоритм подписи — SHA 256

Шаблон для нового сертификата — выберем шаблон по умолчанию для УЦ (CA – Certificate authority)

Нажимаем кнопку Применить всё.

Вкладка Субъект.

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

Вкладка Расширение.

Выберем тип базового контейнера — Центр Сертификации.

Вкладка Область применения ключа.

В разделе X509v3 Key Usage должны быть включены параметры Certificate Sign и CRL Sign

Вкладка Netscape.

Можно убрать выбранные типы шаблона CA

Нажимаем кнопку Ok для создания сертификата.

Во вкладке Сертификаты появился сертификат УЦ.

Экспортируем данный сертификат для импорта в UserGate.

Экспортируем закрытый ключ.

Импортируем сертификат CA в UserGate. Для этого перейдем в UserGate → вкладка Сертификаты и нажмем кнопку импорт.

В окне импорта сертификата запишем название сертификата, загрузим сертификат и закрытый ключ УЦ. Затем нажмем кнопку сохранить.

Назначим сертификату роль SSL дешифрование.

Импортируем на рабочих станциях сертификат УЦ в доверенные корневые центры сертификации.

2. Создадим SSL сертификат captive-портала.

Создадим новый закрытый ключ. Процесса создания закрытого ключа аналогичен созданию ключа для УЦ.

Создадим запрос на получение сертификата, во вкладке Запрос на получение сертификата → Новый запрос.

Вкладка Первоисточник.

Шаблон для нового сертификата — HTTPS_server.

Алгоритм подписи — SHA 256.

Нажмем на кнопку - Применить Всё.

Вкладка Субъект

Заполним персональные данные субъекта и выберем закрытый ключ созданный для этого сертификата. В поле commonName введем одно из имен домена captive.

Вкладка Расширение.

В поле X509v3 Subject Alternative Name нажмем кнопку Редактировать.

Добавим записи с типом DNS доменов captive-портала.

Check box Copy Common Name скопирует в альтернативные имена домен auth.kraftech.ru

Для сохранения введенных имен нажмем кнопку Применить.

Вкладка Область применения ключа.

В разделе X509v3 Key Usage должны быть включены параметры Digital Signature, Non Repudiation и Key Encipherment.

Вкладка Netscape.

Оставляем значения пустыми.

После введенных значений для создания сертификат нажмем кнопку ОК.

У нас появился запрос

Выберем запрос и в контекстном меню нажмем Подписать.

Во вкладке Первоисточник → Подписание → Использовать этот сертификат для подписи выберем наш сертификат УЦ.

Для подписания сертификата нажмем кнопку ОК.

Во вкладке Сертификаты появился новый сертификат подписанный нашим УЦ.

Экспортируем этот сертификат и его закрытый ключ.

Импортируем в UserGate данный сертификат и его закрытый ключ по аналогии с импортом сертификата УЦ и назначим ему роль SSL captive-портала.

3. Создадим SSL сертификат веб-консоли.

Создадим новый закрытый ключ. Процесса создания закрытого ключа аналогичен созданию ключа для УЦ.

Создадим запрос на получение сертификата, во вкладке Запрос на получение сертификата → Новый запрос.

Вкладка Первоисточник.

Шаблон для нового сертификата — HTTPS_server.

Алгоритм подписи — SHA 256.

Нажмем на кнопку - Применить Всё.

Вкладка Субъект

Заполним персональные данные субъекта и выберем закрытый ключ созданный для этого сертификата. В поле commonName введем FQDN имя сервера UserGate.

Вкладка Расширение.

Многие браузеры сертификат сайта и доменное имя сопоставляют по Subject Alternative Name для этого устанавливаем значение DNS:copycn в Subject Alternative Name

Вкладка Область применения ключа.

В разделе X509v3 Key Usage должны быть включены параметры Digital Signature, Non Repudiation и Key Encipherment.

Вкладка Netscape.

Оставляем значения пустыми.

После введенных значений для создания сертификат нажмем кнопку ОК.

У нас появился запрос

Выберем запрос и в контекстном меню нажмем Подписать.

Во вкладке Первоисточник → Подписание → Использовать этот сертификат для подписи выберем наш сертификат УЦ.

Для подписания сертификата нажмем кнопку ОК.

Во вкладке Сертификаты появился новый сертификат подписанный нашим УЦ.

Экспортируем этот сертификат и его закрытый ключ.

Импортируем в UserGate данный сертификат и его закрытый ключ по аналогии с импортом сертификата УЦ и назначим ему роль SSL веб-консоли.

4.2. Создание сертификатов с помощью программы OpenSSL¶

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

# mkdir /root/ca

# cd /root/ca

# mkdir certs crl newcerts private

# chmod 700 private

# touch index.txt

2. Сгенерируем приватный ключ.

# openssl genrsa -out /root/ca/private/ca_key.pem 2048

3. Создадим сертификат CA для этого приватного ключа

# openssl req -new -x509 -days 3650 -key /root/ca/private/ca_key.pem -out /root/ca/certs/ca.crt

Вывод команды

You are about to be asked to enter information that will be incorporated

into your certificate request.

What you are about to enter is what is called a Distinguished Name or a DN.

There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter '.', the field will be left blank.

Country Name (2 letter code) [AU]:RU

State or Province Name (full name) [Some-State]:NSO

Locality Name (eg, city) []:Novosibirsk

Organization Name (eg, company) [Internet Widgits Pty Ltd]:Kraftec

Organizational Unit Name (eg, section) []:

Common Name (e.g. server FQDN or YOUR name) []:www.kraftec.net

Email Address []:dit@kraftec.net

Для создания сертификата SSL для Captive портала и Веб-консоли необходимо создать файл конфигурации

Создадим конфигурационный файл для OpenSSL.

# touch /root/ca/openssl.cnf

Добавим в данный файл следующие блоки

[ ca ]

default_ca = CA_default

[ CA_default ]

dir = /root/ca

certs = $dir/certs

crl_dir = $dir/crl

database = $dir/index.txt

new_certs_dir = $dir/newcerts

certificate = $certs/ca.crt

private_key = $dir/private/ca_key.pem

serial = $dir/serial

crlnumber = $dir/crlnumber

crl = $dir/crl/crl.pem

RANDFILE = $dir/private/.rand

x509_extensions = usr_cert

name_opt = ca_default

cert_opt = ca_default

crl_extensions = crl_ext

default_days = 365

default_crl_days= 30

default_md = sha256

preserve = no

policy = policy_match

[ policy_match ]

countryName = match

stateOrProvinceName = match

organizationName = match

organizationalUnitName = optional

commonName = supplied

emailAddress = optional

[ req ]

default_bits = 2048

distinguished_name = req_distinguished_name

x509_extensions = v3_ca

string_mask = utf8only

[ req_distinguished_name ]

countryName = Country Name (2 letter code)

countryName_default = RU

countryName_min = 2

countryName_max = 2

stateOrProvinceName = State or Province Name (full name)

stateOrProvinceName_default = NSO

localityName = Locality Name (eg, city)

localityName_default = Novosibirsk

0.organizationName = Organization Name (eg, company)

0.organizationName_default = Kraftec

organizationalUnitName = Organizational Unit Name (eg, section)

#organizationalUnitName_default =

commonName = Common Name (e.g. server FQDN or YOUR name)

commonName_max = 64

emailAddress = Email Address

emailAddress_max = 64

[ usr_cert ]

basicConstraints=CA:FALSE

nsCertType = server

keyUsage = nonRepudiation, digitalSignature, keyEncipherment

subjectKeyIdentifier=hash

authorityKeyIdentifier=keyid,issuer

subjectAltName=DNS:auth.kraftec.net, DNS:logout.kraftec.net, DNS:block.kraftec.net, DNS:ftpclient.kraftec.net, DNS:sslvpn.kraftec.net

[ v3_ca ]

subjectKeyIdentifier=hash

authorityKeyIdentifier=keyid:always,issuer

basicConstraints = critical,CA:true

keyUsage = nonRepudiation, digitalSignature, keyEncipherment

[ crl_ext ]

authorityKeyIdentifier=keyid:always

Сгенерируем ключ для SSL сертификата Captive портала

# openssl genrsa -out /root/ca/private/Captiv_key.pem 2048

Сгенерируем ключ для SSL сертификата Веб-консоли

# openssl genrsa -out /root/ca/private/Web_key.pem 2048

Сгенерируем запрос на SSL сертификат Captive портала

# openssl req -new -key /root/ca/private/Captiv_key.pem -config /root/ca/openssl.cnf -out /root/ca/Captive.csr

Вывод команды

You are about to be asked to enter information that will be incorporated

into your certificate request.

What you are about to enter is what is called a Distinguished Name or a DN.

There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter '.', the field will be left blank.

Country Name (2 letter code) [RU]:

State or Province Name (full name) [NSO]:

Locality Name (eg, city) [Novosibirsk]:

Organization Name (eg, company) [Kraftec]:

Organizational Unit Name (eg, section) []:

Common Name (e.g. server FQDN or YOUR name) []:auth.kraftec.net

Email Address []:dit@kraftec.net

Подпишем полученный запрос с помощью сертификата УЦ.

# openssl x509 -req -days 365 -CA /root/ca/certs/ca.crt -CAkey /root/ca/private/ca_key.pem -extfile /root/ca/openssl.cnf -extensions usr_cert -in Captive.csr -out Captive.crt

Вывод команды

Signature ok

subject=/C=RU/ST=NSO/L=Novosibirsk/O=Kraftec/CN=auth.kraftec.net/emailAddress=dit@kraftec.net

Getting CA Private Key

Сгенерируем запрос на SSL сертификат Веб-консоли

Предварительно исправим конфигурационный файл в расширении usr_cert изменим параметр на subjectAltName=DNS:utm.kraftec.net

# openssl req -new -key /root/ca/private/Web_key.pem -config /root/ca/openssl.cnf -out /root/ca/Web.csr

Вывод команды

You are about to be asked to enter information that will be incorporated

into your certificate request.

What you are about to enter is what is called a Distinguished Name or a DN.

There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter '.', the field will be left blank.

Country Name (2 letter code) [RU]:

State or Province Name (full name) [NSO]:

Locality Name (eg, city) [Novosibirsk]:

Organization Name (eg, company) [Kraftec]:

Organizational Unit Name (eg, section) []:

Common Name (e.g. server FQDN or YOUR name) []:utm.kraftec.net

Email Address []:dit@kraftec.net

Подпишем полученные запросы с помощью сертификата УЦ.

# openssl x509 -req -days 365 -CA /root/ca/certs/ca.crt -CAkey /root/ca/private/ca_key.pem -extfile /root/ca/openssl.cnf -extensions usr_cert -in Web.csr -out Web.crt

Вывод команды

Signature ok

subject=/C=RU/ST=NSO/L=Novosibirsk/O=Kraftec/CN=utm.kraftec.net/emailAddress=dit@kraftec.net

Getting CA Private Key

Импортируем данные сертификаты и приватные ключи в UserGate в раздел сертификаты.

Сертификату ca.crt назначим роль SSL дешифрование

Сертификату Captive.crt назначим роль SSL captive-портала

Сертификату Web.crt назначим роль SSL веб-консоли

На компьютеры пользователей установим сертификат ca.crt в хранилище Доверенные корневые центры сертификации.

4.3. Создание сертификата, подписанного в Active Directory Certification Authority¶

1. B консоли Usergate Создать Новый CSR

2. С помощью кнопки Экспорт скачать файл запроса

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

В качестве последнего параметра укажите файл CSR, который вы создали в консоли usergate.

Файл будет создан в формате PEM – PKCS#7.

Альтернативный вариант - создать этот файл через web-приложение центра сертификации Microsoft Active Directory:

Тип сертификата может быть любой – DER или PEM.

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

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

6. В веб-консоли Microsoft CA выбрать и скачать сертификаты (публичные ключи) для самого Удостоверяющего Центра:

7. С помощью кнопки Импорт загрузить скачанные на предыдущем шаге сертификаты Удостоверяющего Центра:

Процедура закончена.

4.4. Распространение сертификатов UserGate на клиентские компьютеры с помощью групповой политики¶

Следующую процедуру можно использовать для принудительной отправки соответствующих SSL (сертификатов SSL) (или эквивалентных сертификатов, связанных с доверенным корневым) на каждый клиентский компьютер в лесу.

Минимальным требованием для выполнения этой процедуры является членство в группе "Администраторы домена" или "Администраторы предприятия" или аналогичным образом в домен Active Directory Services (AD DS). Просмотрите сведения об использовании соответствующих учетных записей и членства в группах в локальной среде и группах домена по умолчанию (http://go.Microsoft.com/fwlink/? LinkId=83477).

5.1. Пример настройки пропускной способности для разных зон и пользователей¶

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

Пример реализации.

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

Есть зона DMZ, в которой расположены различные сервера компании, используемые для предоставления ресурсов пользователям

локальной сети.

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

1. Создаем правило с полосой пропускания 100Kbps для требуемой группы пользователей и в качестве Зоны назначения указываем Trusted.

Весь трафик, как из зоны Untrusted, так из зоны DMZ в зону Trusted будет ограничиваться данным правилом.

2. Для того, чтобы трафик от серверов компании в зоне DMZ к данной группе пользователей из зоны Trusted не ограничивался, в данном правиле в качестве Адреса источника указываем список IP-адресов серверов и в правиле ставим галочку инвертировать.

6.1. Как разрешить работу клиента Yandex.Disk.¶

Для организации работы клиента Яндекс.Диск необходимо создать новое правило дешифрования (например, "Не расшифровывать Яндеск.Диск") и установить его в начало списка правил дешифрования.

В поле Действие этого правила необходимо указать Не расшифровывать, а в поле Домены создать и добавить новый список URL, содержащий следующие сайты:

clck.yandex.ru

push.yandex.ru

webdav.yandex.ru

downloader.disk.yandex.ru

cloud-api.yandex.ru

cloud-api.yandex.net

*storage.yandex.net

*.disk.yandex.net

report.appmetrica.yandex.net

oauth.yandex.ru

6.2. Как разрешить работу клиента Dropbox.¶

6.3. Как настроить обновление "нового" Microsoft Edge (на базе Chromium) через¶

Для того, что бы браузер Mocrosoft Edge (версия на базе Chromium) мог получать обновления при доступе в Интернет через UserGate, необходимо создать дополнительное правило дешифрования.

Например "No decrypt for MS Edge (Chromium-based) updates".

В поле Действие этого правила необходимо указать Не расшифровывать, а в поле Домены создать и добавить новый список URL, содержащий сайт msedge.api.cdp.microsoft.com .

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

6.4. Исправление авторизации на сайте Авито (разблокировка гугл-капча)¶

Проблема проявляется при входе на сайт avito.ru.

1. Нажимаем Вход и Регистрация, вводим имя и пароль, нажимаем войти, ноничего не происходит.

2. В журнале веб-доступа находим сработавшее правило Веб-безопасности, вносим в исключения URL www.avito.ru из поля Реферер (отмечен на скриншоте):

3. Повторяем п.1

4. В журнале веб-доступа находим сработавшее правило Веб-безопасности, вносим в исключения URL www.google.com/recaptcha/ из поля Реферер:

5. Повторяем п.1 - вход успешный.

Исключение из правила блокировки рекламы делается в самом правиле, пример на присоединённом скриншоте, названия листов соответствуют содержимому:

7.1. Публикация FTP-сервера¶

Данная статья описывает перечень шагов, необходимых для публикации FTP-сервера с помощью DNAT.

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

1. В разделе Библиотеки - Сервисы создаём сервис FTP_PASV в настойках которого указываем протокол TCP и диапазон портов назначения соответствующий диапазону TCP-портов пассивного режима, указанных в конфигурации FTP-сервера (диапазон портов задаётся через дефис), поле порты источника оставляем пустым.

2. Создаём в разделе NAT и маршрутизация правило типа DNAT со следующими параметрами:

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

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

в. Сервис - укажите сервисы FTP (предустановленный) и FTP_PASV, созданный на шаге 1.

г. DNAT - укажите локальный IP-адрес публикуемого сервера. Если нужен доступ к серверу из локальной сети, то отметьте чек-бокс SNAT.

Публикация завершена.

7.2. Публикация сервиса с помощью портмаппинга (изменение порта публикуемого сервиса)¶

Допустим, есть задача предоставить доступ к серверу, который подключен к Интернету через UserGate. Пусть это будет сервер SSH, который надо опубликовать, изменяя при этом порт сервиса с TCP 22 на 2222.

Имеем сервер UserGate с интерфейсами:

Сервер в локальной сети, к которому нужно предоставить доступ:

IP адрес 10.1.10.15/24

gateway 10.1.10.1

сервер DNS 10.1.10.1

Компьютер, с которого мы будем подключаться к серверу

IP адрес 192.168.110.17

gateway 192.168.110.1

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

Во вкладке Источник выберем Зону, в которой UserGate будет обрабатывать запросы на подключение к Серверу.

В Адресе источника можно указать список доверенных IP-адресов, которым будет разрешен доступ.

Во вкладке Назначение можно выбрать IP адрес интерфейса UserGate на котором будет предоставляться доступ на подключение к серверу, для этого в Адресе назначения добавим список с таким IP-адресом. Это необходимо, например, если UserGate подключен к нескольким провайдерам и подключение к Серверу нужно предоставлять через одного из них.

Во вкладке Порт-форвардинг нажмем кнопку Добавить и укажем следующие настройки:

Для установки соединения с сервером по протоколу SSH мы будем использовать порт 2222, его будет слушать UserGate и перенаправлять на сервер на стандартный порт 22.

Во вкладке DNAT необходимо указать ip адрес сервера, к которому нам необходимо предоставить доступ.

Если на сервере разрешен доступ по протоколу SSH с IP адресов только из локальной сети, необходимо включить SNAT.

После завершения настройки правила, необходимо нажать кнопку Сохранить.

Пробуем подключиться к серверу

В качестве IP-адреса необходимо указать IP-адрес UserGate, назначенному интерфейсу зоны Untrusted, и порт 2222, указанный для перенаправления во вкладке Порт-форвардинг.

После установки соединения получаем приглашение аутентификации удаленного сервера – публикация работает.

8.1. Настройка Remote Access VPN на ОС Linux¶

Чтобы настроить VPN на ОС Linux, вам потребуется установить пакеты для поддержки L2TP VPN. На примере Ubuntu, выполните следующие команды:

sudo add-apt-repository ppa:nm-l2tp/network-manager-l2tp

sudo apt update

sudo apt install network-manager-l2tp network-manager-l2tp-gnome

После этого в вашем интерфейсе для работы с сетевыми подключениями появится возможность добавлять L2TP VPN-подключения:

Далее настройте параметры подключения и укажите данные для аутентификации:

В настройках IPSec укажите Preshared ключ, а параметры конфигурации Phase1 и Phase2 укажите, как

Phase1 algorithms: aes128-sha1-modp1024!

Phase2 algorithm: aes128-sha1!

В настройках PPP, в качестве метода аутентификации укажите PAP, и отключите все виды компрессии:

9.1. Перенос учетных данных пользователей с UserGate Proxy & Firewall на UserGate 5.0.¶

Скрипт написан на языке Python, поэтому для его запуска, необходимо скачать и установить интерпретатор с официального сайта https://python.org/downloads/ (в среде Windows)

В среде Linux откройте консоль (ctrl+alt+t). Введите в консоли:

python3

Если увидите приветствие вида:

Python 3.4.3 (default, Nov 17 2016, 01:08:31)

[GCC 4.8.4] on linux

Type "help", "copyright", "credits" or "license" for more information.

>>> 

значит пакет уже установлен. Если же нет, то необходимо его установить, для этого выполните команду:

sudo apt-get install python3

Для корректной работы скрипта, приложенного к данной заметке, в него необходимо внести изменения. Откройте файл любым текстовым редактором.

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

!Внимание: часть скрипта ниже только пример.

configuration options ####################################

UTM_SERVER = '192.168.30.134' - ip адрес

UTM_ADMIN = 'Admin' - логин

UTM_PASSWORD = 'хххххх' - пароль

STOP_LOGINS = ['NETWORK SERVICE', 'LOCAL SERVICE', 'SYSTEM']

После внесения изменений, сохраните скрипт. В ту же директорию необходимо положить файл "C:\programdata\entensys\usergate6\config.cfg", который необходимо скопировать с компьютера, на котором установлен UserGate Proxy & Firewall.

Перед запуском скрипта необходимо открыть разрешение для управления доступом к XML-RPC на зонах

После этого в свойствах зоны назначенной интерфейсу, адрес которого указываем в скрипте открываем доступ XML-RPC

Запускаем скрипт:

root@nn:~/temp$ python3 users-migration.py

В случае успешной работы скрипта:

Skipping user NETWORK SERVICE

Skipping user LOCAL SERVICE

Skipping user SYSTEM

All done.

root@nn:~/temp$

После выполнения скрипта необходимо на зоне запретить доступ к XML-RPC

Если в скрипт были внесены не корректные данные, то будут ошибки вида:

FATAL: XML-RPC error: <Fault 3: 'Invalid method format'> - не корректные данные пользователя, либо

OSError: [Errno 113] No route to host - не корректный IP адрес хоста UserGate.

9.2. Настройка SNMP мониторинга с помощью ZABBIX¶