...
...
|
Особенности работы
 В правилах NGFW могут использоваться списки IP, geo IP и списки доменных имен. Эти списки представляют из себя разные сущности и обрабатываются в правилах по-разному. В общем случае правила обработки выглядят так: 1. условия объединяются по ИЛИ, если указаны несколько списков IP-адресов и/или доменов; 2. условия объединяются по И, если указаны GeoIP и списки IP-адресов и/или доменов. В устройствах UserGate для корректной работы сервисов при наличии виртуальных маршрутизаторов (VRF) введены некоторые ограничения на доступ к сервисам зон. Примечание Данные ограничения введены для следующих сервисов: SNMP, Кластер, VRRP, DNS, Агент авторизации, RIP, SNMP-прокси, SSH-прокси, NTP сервис.
Пакет будет пропущен к сервису, если он поступил на интерфейс зоны, в которой разрешена работа данного сервиса. Если затем, в результате внутренней маршрутизации, пакет был перенаправлен на интерфейс другой зоны (например, запрос из одной зоны осуществляется по IP-адресу, находящемуся в другой зоне), то такой пакет будет заблокирован даже несмотря на наличие доступа к сервису обоих зон.
В данном разделе рассмотрены некоторые особенности обработки трафика межсетевым экраном UserGate NGFW. Запрещающие правила UG NGFW в целях безопасности имеют некоторые особенности в обработке пакетов — это, в свою очередь, может приводить к ситуации с не очевидной блокировкой пакетов. В качестве примера рассмотрим следующую ситуацию:
ПримечаниеПараметр fw_established выключен
В этом примере доступ из сети Trusted не будет работать, поскольку, несмотря на то, что при создании второго правила, автоматически будет добавлено разрешающее правило для входящих пакетов уже установленного соединения, эти пакеты будут заблокированы, поскольку запрещающие правила межсетевого экрана блокируют любой пакет попадающий под их условия, в т.ч. и пакеты уже установленных сессий. Соответственно, ответные пакеты для разрешенных правилами ниже сессий будут также заблокированы, поскольку сначала попадут под действие запрещающего правила. Таким образом, для корректной работы межсетевого экрана: Первый вариант: необходимо размещать запрещающие правила ниже разрешающих, чтобы сначала отработали разрешающие правила, в т.ч. по пакетам уже установленных соединений, а уже потом вступали в работу запрещающие правила.
В данном случае, все будет работать правильно, поскольку сначала отработают разрешающие правила, и лишь потом будет заблокирован трафик, который не попадет под действие этих правил Второй вариант: начиная с 6 версии возможно через cli установить значение fw_established в true – это создаст общее разрешающее правило для пакетов уже установленной сессии, выше всех правил FW. ПримечаниеЭтот вариант является менее предпочтительным, поскольку это может привести к проблемам в журналировании всех пакетов и некорректной работе блокировки по приложениям.
ПримечаниеВариант с fw_established обычно имеет смысл при большом количестве правил, и только в том случае если вышеуказанные проблемы являются для вас несущественными.
В списки URL добавляются записи, соответствующие стандарту, описанному в RFC 1738. ПримечаниеРегистр букв имеет значение в URL при указании пути, в названии домена – нет.
1. Для доменов: регистр букв не имеет значение (определён в RFC 1035), т.е. при указании test.ru, также будут заблокированы домены Test.ru, TEST.ru и т.п. 2. Для URL: регистр букв не имеет значения при указании имени хоста, но учитывается в URI (адресе ресурса на веб-сервере; определено RFC 3986). ПримечаниеЕсли запись, начинается с http://, https://, ftp:// или содержит один или более символов косой черты (/), то такая запись считается URL.
URL применяются только для HTTP(S)-фильтрации. Имя домена применяется и для DNS-фильтрации, и для HTTP(S)-фильтрации. Например, настроено правило контентной фильтрации, блокирующее список URL, содержащий запись http://test.ru/example. В этом случае:
Блокировка расширений возможна только через списки URL. Например, для блокировки файла с расширением .exe необходимо добавить следующие записи (необходимо учесть всевозможные комбинации): /*exe$, /*EXE$, /*Exe$, /*eXe$, /*exE$, /*EXe$, /*ExE$, /*eXE$. В данном разделе в общем будут рассмотрены алгоритмы аутентификации пользователей на UserGate и условия применения политик. Аутентификация локальных пользователейЕсли на UserGate настроена аутентификация локальных пользователей, то возможны следующие случаи: 1. Аутентификация по явно указанному IP-адресу. IP-адрес указывается во вкладке Статические IP/MAC/VLAN свойств пользователя в разделе Пользователи и устройства ➜ Пользователи. В этом случае пользователь считается аутентифицированным на UserGate. 2. Аутентификация по логину/паролю. При получении от неизвестного клиента HTTP-запроса UserGate перенаправляет его на страницу аутентификации captive-портала. Политики применятся к локальным пользователям автоматически. Аутентификация на серверах RADIUS, TACACS+При получении от неизвестного клиента HTTP-запроса UserGate перенаправляет его на страницу аутентификации captive-портала. Пользователь вводит логин/пароль, а UserGate отправляет данные на сервер (RADIUS или TACACS+) для проверки их корректности. Аутентификация через LDAP-коннектор1. LDAP-коннектор с загруженным keytab. При получении от неизвестного клиента HTTP-запроса UserGate перенаправляет его на страницу аутентификации captive-портала. Пользователь вводит логин/пароль, UserGate получает Kerberos-тикет для данного пользователя и расшифровывает его с помощью загруженного keytab-файла. 2. LDAP-коннектор без загруженного keytab. При получении от неизвестного клиента HTTP-запроса UserGate перенаправляет его на страницу аутентификации captive-портала. Пользователь вводит логин/пароль, UserGate посылает LDAP-запрос на сервер аутентификации для проверки корректности введённых логина и пароля. ПримечаниеПользователи должны состоять в группе Domain Users (идентификатор группы: 513).
Аутентификация Kerberos
При получении от неизвестного клиента HTTP-запроса UserGate отправляет клиенту сообщение HTTP 401 или HTTP 407 с требованием аутентификации. При явно указанном прокси, получая от клиента HTTP-запрос, UserGate отвечает сообщением HTTP 407 (Proxy Authentication Required). При прозрачном проксировании UserGate перехватывает HTTP-запрос от клиента и отправляет сообщение HTTP 302, указывая в Location auth домен captive-портала. При получении от клиента GET на auth домен captive-портала UserGate отвечает сообщением HTTP 401 (Unauthorized). Получив ответ от UserGate, пользователь обращается в центр распределения ключей своей сети (KDC) с целью получения для своих учётных данных Kerberos-тикета. Затем полученный Kerberos-тикет пользователь отправляет на сервер UserGate, который расшифровывает его с помощью загруженного keytab. UserGate записывает в базу данных имя и IP-адрес пользователя и просматривает группы LDAP, указанные в тикете. Если указанные группы LDAP используются в политиках UserGate, то UserGate добавит эти группы к информации о пользователе, если нет, то информация об этих группах не будет записана в базу данных. Аутентификация NTLM
При получении от неизвестного клиента HTTP-запроса UserGate отправляет клиенту сообщение HTTP 401 или HTTP 407 с требованием аутентификации. При явно указанном прокси, получая от клиента HTTP-запрос, UserGate отвечает сообщением HTTP 407 (Proxy Authentication Required). При прозрачном проксировании UserGate перехватывает HTTP-запрос от клиента и отправляет сообщение HTTP 302, указывая в Location auth домен captive-портала. При получении от клиента GET на auth домен captive-портала UserGate отвечает сообщением HTTP 401 (Unauthorized). Получив ответ от UserGate, пользователь отправляет данные для аутентификации на сервер UserGate. UserGate пересылает их на контроллер домена. В случае корректности логина/пароля считаем пользователя аутентифицированным. Применение политик к пользователям, проходящим аутентификацию через LDAP-коннектор и по NTLMДля применения политик (в случаях добавления новой LDAP-группы или пользователя в группу, создания правила и применения его к группе LDAP) к пользователям, аутентифицирующимся через LDAP-коннектор или NTLM, необходимо: 1. Выполнить logout на UserGate. Для выполнения logout пользователю необходимо перейти на страницу Logout captive-портала и нажать Выйти/Logout. Сбросить аутентификацию всех пользователей можно в разделе Пользователи и устройства ➜ Серверы аутентификации (кнопка Сбросить аутентификацию всех пользователей) веб-интерфейса UserGate. Также можно сбросить сессии отдельных пользователей с помощью интерфейса командной строки (CLI); для выполнения команды необходимо знать IP-адрес пользователя (<IP-address>):
2. Очистить кэш LDAP-записей на UserGate. Очистка доступна через интерфейс командной строки (CLI), используйте команду:
3. Пройти аутентификацию на UserGate. Применение политик к пользователям, проходящим аутентификацию по KerberosДля применения политик (в случаях добавления новой LDAP-группы или пользователя в группу, создания правила и применения его к группе LDAP) к пользователям, аутентифицирующимся по Kerberos, необходимо: 1. Выполнить logout на UserGate. Для выполнения logout пользователю необходимо перейти на страницу Logout captive-портала и нажать Выйти/Logout. Сбросить аутентификацию всех пользователей можно в разделе Пользователи и устройства ➜ Серверы аутентификации (кнопка Сбросить аутентификацию всех пользователей) веб-интерфейса UserGate. Также можно сбросить сессии отдельных пользователей с помощью интерфейса командной строки (CLI); для выполнения команды необходимо знать IP-адрес пользователя (<IP-address>):
2. Получить новый Kerberos-тикет с обновлённым списком LDAP-групп. Для обновления тикета необходимо, например, повторно аутентифицироваться на клиентском компьютере. 3. Очистить кэш LDAP-записей на UserGate. Очистка доступна через интерфейс командной строки (CLI), используйте команду:
4. Пройти аутентификацию на UserGate. В данной статье приведён общий порядок действий для настройки защиты почтового трафика. ПримечаниеНеобходимо придерживаться данного порядка выполнения действий.
ПримечаниеНаличие лицензии KAS обязательно; без неё защита почтового трафика работать не будет. Лицензия KAS входит в подписку модуля Mail Security.
Для проверки наличия лицензии KAS обратитесь в службу технической поддержки UserGate.
ПримечаниеВ случае повторного включения правила DNAT, также необходимо выключить и включить правило защиты почтового трафика, т.к. после выключения правила DNAT модуль защиты почтового трафика не будет видеть его.
Рассмотрим случаи, когда страница блокировки будет или не будет отображена. UserGate работает в режиме Transparent Proxy Mode:
UserGate работает в режиме Explicit Proxy Mode:
UserGate не производит аутентификацию пользователей при каждом HTTP-запросе, т.к. это привело бы к неоправданному увеличению объёма сетевого трафика, задержкам при загрузке HTTP-ресурсов и, в случаях использования внешних источников учётных записей пользователей, повышению нагрузки на серверы аутентификации. В UserGate реализована периодическая аутентификация пользователей. В случае успешной аутентификации UserGate сопоставляет идентификатор пользователя и его IP-адрес и записывает в базу данных информацию о пользователе. Пока пара идентификатор/IP-адрес хранится в базе пользователь считается авторизованным (Known) и UserGate не требует его повторной авторизации. Срок хранения данных об авторизации пользователя определяется двумя параметрами профиля авторизации UserGate:
Значение по умолчанию составляет 86400 секунд, т.е. 24 часа. Данное значение оптимально, если рабочие места в организации являются персональными, в противном случае рекомендуется использовать профиль авторизации с меньшим временем жизни авторизованного пользователя, например, 900 секунд (15 минут).
Значение по умолчанию составляет 900 секунд, т.е. 15 минут. ПримечаниеСовременные операционные системы и ПО постоянно ведут некоторую фоновую сетевую активность, поэтому данный таймер не будет срабатывать, если рабочее место пользователя не выключено, а, например, заблокировано.
|
