Приветствуем! На протяжении всего времени нашей работы с решениями компании Fortinet, а в частности с межсетевым экраном нового поколения FortiGate, одним из самых интересующих вопросов является контроль и отслеживание трафика отдельных пользователей или групп пользователей. Сегодня мы хотим подробно рассказать о механизме прозрачной аутентификации пользователей на межсетевом экране FortiGate с помощью технологии Fortinet Single Sign-On. Данная статья будет посвящена именно теоретическому аспекту FSSO, поскольку в данном случае без теории тяжело разобраться, что происходит на практике.
Single Sign-On (SSO) - механизм, позволяющий идентифицированным пользователям получать доступ к различным ресурсам в сети без повторной аутентификации. При работе с межсетевым экраном FortiGate, SSO реализуется с помощью FSSO (Fortinet Single Sign On) - комплекса программных агентов, который позволяет устройству FortiGate идентифицировать пользователей сети и тем самым контролировать их доступ к ресурсам сети, а также отслеживать трафик различных пользователей. Когда пользователь аутентифицируется в домене, FSSO агент отправляет на FortiGate имя пользователя, его IP адрес, а также список групп, к которым данный пользователь принадлежит. FortiGate использует данную информацию для того, чтобы разрешить или запретить данному пользователю доступ к сетевым ресурсам. FSSO обычно используется со службами каталогов, такими как Windows Active Directory или Novell eDirectory. Работа FSSO зависит от используемой службы каталогов. В данной статье мы будем рассматривать FSSO для Windows Active Directory (AD).
FSSO для Windows AD использует коллектор агента. Агенты для контроллеров домена (DC агент) также могут использоваться, в зависимости от режима работы коллектор агента. Существует два основных режима работы: DC Agent Mode (режим, в котором используются DC агент) и Polling Mode (в этом режиме используются только коллектор агенты). Также на FortiGate может использоваться Polling режим, который не требует установки сторонних агентов на сервера. Однако, данный вариант подходит только для простых сетей с минимальным количеством пользователей.
Для начала рассмотрим режим DC Agent Mode. Данный режим является рекомендованным для FSSO. Для него требуется:
DC агент, установленный на каждый контроллер домена - если в сети имеется несколько контроллеров домена, агент должен быть установлен на каждый из них;
Коллектор агент - второй компонент FSSO, установленный на сервер Windows, являющийся членом домена. Он собирает события, полученные с агентов для контроллеров домена, и перенаправляет их на FortiGate. Также он отвечает за верификацию групп и проверку рабочих станций на предмет выхода пользователя из системы. Коллектор агент может отсылать на FortiGate информацию о локальных группах безопасности, организационных подразделениях, а также о глобальных группах безопасности. Также коллектор агент можно настроить для выполнения DNS запросов.
Схема работы FSSO в режиме DC Agent Mode представлена на рисунке ниже:
При аутентификации пользователя DC агент перехватывает запись о входе на контроллере домена.
Затем DC агент выполняет DNS запрос для определения IP адреса пользователя и передает полученную информацию на коллектор.. После того, как коллектор получает информацию, он снова выполняет DNS запрос для того, чтобы определить, был ли изменен IP адрес пользователя.
После этого, вся информация о пользователе передается на FortiGate.
После того, как коллектор передал всю информацию о пользователе, FortiGate знает этого пользователя, его IP адрес и группы, к которым он принадлежит. Когда пользователь пытается получить доступ к интересующим его сетевым ресурсам (в том числе и к Интернету), FortiGate сравнивает IP адрес источника с IP адресами, находящимися в списке активных FSSO пользователей. Поскольку пользователь уже авторизован в домене, и FortiGate содержит информацию о нем, пользователь не будет авторизовываться повторно. Вместо этого, доступ данного пользователя к интересующему ресурсу будет разрешен или запрещен в зависимости от политики безопасности, под которую попадает трафик данного пользователя.
Перейдем ко второму режиму - Collector Agent-Based Polling Mode. Данный режим не требует установки DC агентов на контроллеры домена. Однако, требования к установке коллектор агентов на сервер или сервера, принадлежащие домену, остаются. В таком случае коллектор агент периодически опрашивает контроллеры домена на предмет наличия событий log-on пользователей. Для этого могут использоваться различные методы:
NetAPI: Агент обращается к временным сессиям, созданным на контроллере домена в момент входа пользователей в домен, и вызывает функцию NetSessionEnum. Данный метод работает быстрее остальных, однако он может пропустить некоторые события входа при высокой нагрузке контроллера домена. Это связано с тем, что при высокой нагрузке сессии могут удаляться из оперативной памяти до того, как агент успеет к ним обратиться и передать информацию на FortiGate.
WinSecLog: Агент обращается ко всем логам событий безопасности в контроллере домена. В таком случае, он не пропустит ни одного события входа пользователя, поскольку логи событий безопасности обычно не удаляются. Однако, при передаче информации на FortiGate возможны задержки - главными причинами являются большой объем сети, а также медленная скорость записи логов. Данный метод является самым распространенным.
WMI: Агент с помощью Windows API получает системную информацию с контроллера домена. Контроллер домена по запросу возвращает все требуемые события входа пользователей в домен. Данный способ позволяет уменьшить нагрузку канала между коллектор агентом и контроллером домена.
Схема работы Collector Agent-Based Polling режима представлена на рисунке ниже:
Пользователь аутентифицируется в домене, предоставляя свои учетные данные на контроллер домена;
Коллектор агент периодически (раз в несколько секунд) опрашивает контроллер домена на предмет наличия событий входа пользователей в домен;
Коллектор агент посылает полученную информацию на FortiGate;
Поскольку пользователь уже авторизован в домене, и FortiGate содержит информацию о нем, пользователь не будет авторизовываться повторно. Вместо этого, доступ данного пользователя к интересующему ресурсу будет разрешен или запрещен в зависимости от политики безопасности, под которую попадает данный трафик.
И третий режим, который мы сегодня рассмотрим - Agentless Polling Mode. Процесс его работы схож с предыдущим режимом, однако вместо использования коллектор агента, FortiGate опрашивает контроллер домена самостоятельно. Из-за этого присутствует ряд ограничений:
Требуется больше системных ресурсов;
Происходит опрос только двух событий - ID 4768 и ID 4769. Для этого используется протокол SMB;
Отсутствуют дополнительные возможности, которые можно использовать при наличии коллектор агента, например - проверка конечных станций.
Схема работы данного режима представлена на рисунке ниже.
FortiGate опрашивает контроллер домена для получения событий входа пользователей в систему.
После аутентификации пользователя на контроллере домена, FortiGate получает это событие во время следующего опроса в совокупности со следующей информацией: имя пользователя, имя машины, IP адрес. Затем, он запрашивает группы пользователей, о которых получил информацию.
Когда пользователь пытается получить доступ к сетевому ресурсу, FortiGate уже имеет всю необходимую информацию о данном пользователе, и пользователю не нужно аутентифицировать повторно. Вместо этого, доступ данного пользователя к интересующему ресурсу будет разрешен или запрещен в зависимости от политики безопасности, под которую попадает трафик данного пользователя.
Подведем итоги, выделив основные отличия в режимах DC Agent Mode и Polling Mode:
FSSO в режиме DC Agent Mode сложнее в инсталяции. Он требует установки коллектор агента, а также DC агента на каждый контроллер домена, в котором мониторятся события входа в систему. Но в то же время этот режим является более масштабируемым, поскольку работа по захвату событий входа реализуется DC агентами, которые и передают данную информацию на коллектор агент.
В Polling Mode коллектору необходимо опрашивать каждый контроллер домена раз в несколько секунд. При увеличении числа контроллеров домена, число запросов также растет. Даже если использовать несколько коллектор агентов - каждый из них должен опрашивать все контроллеры домена самостоятельно.
Также, в режиме DC Agent Mode необходимые события собираются один раз и отправляются на привязанные коллектор агенты. Поэтому, события входа пользователей не упускаются. А в режиме Polling Mode, некоторые события входа могут быть пропущены, или при их передаче может возникнуть задержка.
Для удобства, основные отличия в режимах были сведены в таблицу:
DC Agent Mode | Polling Mode | |
Инсталяция | Сложная - одна инсталяция на один контроллер домена. Требуется перезагрузка. | Простая - одна инсталляция или настройка на FortiGate |
Требуется ли DC агент | Да | Нет |
Масштабирование | Высокий уровень масштабирования | Низкий уровень масштабирования |
Уровень захвата событий | Захватываются все события | Некоторые события могут быть пропущены (NetAPI) или могут быть переданы с задержкой (WinSecLog) |
На этом теоретическая часть, посвященная технологии FSSO, закончена. В следующий раз мы осветим именно практические аспекты данной технологии. Чтобы не пропустить новых материалов, следите за новостями на наших каналах:
ded_Pihto
А каким пользователем определиться обращение с ПК, на который который пользователь залогинился под user1, не разлогиниваясь сделал switch user и залогинился под user2? а в фоне задача запущенная под user1 продолжает генерить трафик… только при такой логике от имени уже user2.
А под кем будет обращение, когда пользоватль потворно сделает switch user в user1? события logon во втором случае точно не будет.
ColdSUN
Будет использоваться имя пользователя из последнего logon события. Кстати, когда пользователь сделает switch обратно, событие на контроллер домена всё равно придёт.
Возможно, если на такой компьютер установить terminal агента, то трафик от каждого пользователя будет считаться отдельно. Terminal агент записывает pool портов для исходящих соединений для каждого отдельного пользователя. Таким образом можно разделять трафик между пользователями для терминальных серверов.
enliven89
В checkpoint подобное событие в 77.30 приводило к тому, что user2 получал привелегии user1.
Не знаю, исправили ли потом.