Защита от взлома паролей и других распространенных угроз
Многие предприятия используют AD в качестве общего корпоративного каталога для информационной инфраструктуры на базе Windows. AD стала важным элементом большинства предприятий, а такие активы должны быть надежно защищены.
AD может подвергаться многим видам атак, в этой статье мы рассмотрим пять основных видов и способы защиты от них. Первые три вида атак нацелены на повышение привилегий атакующего в AD. Четвертый и пятый виды направлены на работоспособность службы AD в сетевой инфраструктуре предприятия. Если не оговорено иное, информация в данной статье относится к версиям AD Windows Server 2003 и Windows 2000 Server.
Конечно, все виды атак на AD невозможно рассмотреть в рамках одной статьи, здесь я хочу только продемонстрировать администраторам необходимость организации многоуровневой защиты AD от всевозможных угроз.
АТАКА № 1. Подбор пароля на основе хеша LM
Подбор пароля заключается в переборе возможных паролей с использованием того же алгоритма хеширования, который применяется операционной системой, и последующем сравнении полученного значения с хешем пароля, сохраняемым операционной системой. Взлом пароля может занять немало времени, часто программам подбора паролей требуется перебрать большое количество возможных вариантов (иногда все). Существуют свободно распространяемые средства типа John the Ripper и LCP, которые выполняют автоматический перебор паролей. Последняя версия John the Ripper доступна для загрузки с сайта http://www.openwall.com/john, новую версию LCP можно загрузить с http://www.lcpsoft.com/english/index.htm. Особенно эффективно эти программы взламывают пароли в средах AD, использующих простой протокол аутентификации NTLM (NT LAN Manager). Протокол NTLM применяется по умолчанию в сетях Windows NT 4.0 и поддерживается в сетях Windows 2000 и более поздних из соображений обеспечения совместимости сверху вниз. В свою очередь, NTLM включает два протокола — LM и NTLM. Они используют различные алгоритмы хеширования. Эти алгоритмы хеширования называются также LM и NT (или Unicode).
Метод, используемый Windows для формирования хеша LM, имеет слабое место, что позволяет значительно сократить перебор при взломе пароля. Во-первых, LM ограничивает длину пароля 14 символами. Кроме того, при формировании хеша LM преобразует все символы к верхнему регистру. В довершение всего, LM использует для формирования хеша не алгоритм хеширования, а шифрование симметричным ключом.
|
| Рисунок. Формирование хеша LM |
На рисунке представлен хеш LM, созданный для пользовательского пароля hpinvent1. Во-первых, пароль преобразован к верхнему регистру: получается HPINVENT1, затем полученная строка разбивается на две подстроки по 7 (или менее) символов HPINVEN и T1*****, при этом вторая строка дополняется справа нулевыми символами до 7 символов. Полученные две строки используются в качестве ключа для шифрования константы с использованием стандартного симметричного DES, а не хеша. Полученные в результате зашифрованные DES строки склеиваются вместе для получения хеша LM.
Предотвращение атаки № 1
Для исключения рисков, связанных с хранением хешей паролей LM, необходимо отключить кэширование паролей LM в AD, включить использование более надежного протокола аутентификации NTLMv2 или обеспечить политику использования сложных паролей.
Для отключения хранения хешей паролей LM в AD для Windows 2003, Windows XP и более поздних платформ можно воспользоваться групповыми политиками (GPO, Group Policy Object) или локальной политикой (Network security: Do not store LAN Manager hash value on next password change). В Windows 2000 включение этой политики не приводит к удалению хешей LM из AD и SAM (локальная база данных подсистемы безопасности), а только предотвращает сохранение новых паролей после смены пароля пользователем. Поэтому после установки данной политики необходимо, чтобы пользователь поменял пароль. В Windows 2003 и XP при включении этой политики происходит автоматическое удаление пароля из локальной базы SAM.
Для операционных систем Windows 2003, XP и Windows 2000 SP2 и более поздних версий кэширование паролей LM можно отключить, установив в реестре значение параметра HKEY_LOCAL_MACHINESYSTEM CurrentControlSetControlLsa olmhash (REG_DWORD) равным 1.
При выполнении этой настройки в домене AD необходимо выполнить данную процедуру на всех контроллерах домена (DC). Эту настройку не следует производить, если в сети до сих пор работают компьютеры с Windows 9x, на которых не установлен клиент службы каталога (подробнее этот вопрос будет рассмотрен позже). Эти клиенты могут использовать только аутентификацию LM. Более подробно применение параметра nolmhash описано в статье базы знаний Microsoft «How to prevent Windows from storing a LAN manager hash of your password in Active Directory and local SAM databases» по адресу http://support.microsoft.com/?kbid=299656.
При включении nolmhash в кластерной среде Windows 2003 или Windows 2000 следует убедиться, что пароль службы Cluster имеет длину не менее 15 символов, в противном случае могут возникнуть проблемы при работе с Cluster Administrator. Более подробно это описано в статье базы знаний Microsoft «Cluster service account password must be set to 15 or more characters if the NoLMHash policy is enabled» по адресу http://support.microsoft.com/?kbid=828861.
Перед запуском NTLMv2 необходимо включить поддержку этого протокола аутентификации на компьютерах, использующих старые версии Windows. Для Windows 9x необходимо установить клиент службы каталога, который можно загрузить с http://download.microsoft.com/download/0/0/a/00a71 61e-8da8-4c44-b74e-469d769ce96e/dsclient9x.msi. Поддержка NTLMv2 включена в Windows NT начиная с SP4 и присутствует во всех более поздних версиях Windows 2000, XP и Windows 2003.
Для принудительного использования NTLMv2 в среде AD Windows 2003 или Windows 2000 можно задействовать групповую политику Network Security: LAN Manager Authentication Level GPO setting to the value Send NTLMv2 response only, refuse LM. Того же эффекта можно добиться, установив значение параметра реестра HKEY_LOCAL_MACHINESYSTEMCurrent ControlSetControlLsa lmcompatibilitylevel (REG_DWORD) равным 4. Этот параметр реестра и его возможные значения описаны в статье базы знаний Microsoft «LmCompatibilityLevel» по адресу http://www.microsoft.com/resources/documentation/ Windows/2000/server/reskit/en-us/regentry/76052.asp.
Наконец, Windows не будет генерировать хеши паролей LM, если при задании паролей пользователи будут соблюдать следующие правила.
- Использовать пароли длиной более 14 символов.
- Использовать в паролях ALT-коды, приведенные в таблице. Для ввода этих ALT-кодов следует, держа нажатой клавишу ALT, ввести код из четырех цифр.
|
| Таблица. ALT-коды, предотвращающие формирование хеша LM |
АТАКА № 2. Взлом паролей по данным предварительной аутентификации Kerberos
Мы привыкли считать, что при использовании стандартного провайдера Kerberos в Windows 2003, XP и 2000 все пароли надежно защищены от прямого перебора, что было описано в предыдущем разделе. Однако в конце 2002 года, через два года после выпуска Windows 2000, появилась программа KerbCrack. В действительности KerbCrack состоит из двух инструментов, kerbsniff и kerbcrack, которые позволяют осуществить успешный подбор пароля на основе перехваченных сетевых пакетов Kerberos. Kerbsniff перехватывает пакеты Kerberos, а kerbcrack выполняет подбор паролей полным перебором на основании перехваченных данных. Эти программы можно загрузить с http://www.ntsecurity.nu/tools/kerbcrack. Описание работы аналогичных инструментов можно найти в статье http://www.hut.fi/~autikkan/kerberos/docs/phase1/pdf/ LATEST_password_attack.pdf.
Предварительная аутентификация (preauthentication) — это новая функция, введенная в Kerberos 5.0. Клиент использует данные предварительной аутентификации, чтобы подтвердить знание собственного пароля службе распределения ключей Kerberos Key Distribution Center (KDC), выполняющейся на каждом контроллере домена Windows 2003 и Windows 2000. Предварительная аутентификация необходима для выдачи клиенту билета TGT (Ticket Granting Ticket). Эти атаки на Kerberos используют зашифрованную отметку времени (timestamp), которая содержится внутри передаваемых данных предварительной аутентификации. Отметка времени шифруется пользовательским мастер-ключом (т. е. ключом, основанным на пользовательском пароле).
Предотвращение атаки № 2
Существует два способа противодействия атакам на данные предварительной аутентификации Kerberos. Во-первых, использование смарт-карт для регистрации в сети, во-вторых, шифрование сетевого трафика между клиентом Kerberos и контроллером домена с помощью протокола IPsec. Регистрация с помощью смарт-карт использует расширение Kerberos PKINIT, которое применяет для шифрования данных не мастер-ключ пользователя, а его секретный пароль. Более подробную информацию о PKINIT можно найти в статье «Public Key Cryptography for Initial Authentication in Kerberos», доступной на странице http://www.ietf.org/proceedings/03mar/I-D/draft-ietf-cat-kerberos-pk-init-16.txt. В настоящее время считается невозможным осуществить взлом полным перебором пакетов, которые зашифрованы криптографическими средствами открытого-закрытого ключа. Сведения о настройке IPsec можно найти во врезке «Использование политик безопасности IP для защиты серверов».
Атака № 3. Повышение привилегий с помощью уязвимости SIDHistory
Атрибут SIDHistory был добавлен к учетной записи пользователя в AD в Windows 2000. SIDHistory предназначен для обеспечения доступа к ресурсам при переносе учетной записи пользователя между доменами и для обеспечения перемещения учетной записи пользователя внутри леса. Например, при миграции пользовательской учетной записи из домена Windows NT 4.0 в домен Windows 2000, Windows автоматически заполняет атрибут SIDHistory для только что созданной учетной записи в домене Windows 2000 значением SID соответствующего пользователя в домене NT 4.0. При регистрации данные авторизации пользователя (членство в группах и т. п.) заполняются в домене Windows 2000, и контроллер домена добавляет старый SID пользователя в данные авторизации. При этом заново предоставлять доступ к ресурсам в старом домене (их списки ACL не обновляются) не требуется, и пользователь автоматически получает доступ к ним с новой учетной записью.
В принципе недобросовестный администратор AD может попытаться изменить атрибут SIDHistory учетной записи пользователя для повышения уровня привилегий. Например, при наличии доверительных отношений между доменами можно попытаться добавить SID учетной записи администратора доверяющего домена в атрибут SIDHistory пользовательской учетной записи в доверенном домене.
В первых выпусках Windows 2000 контроллеры доверяющего домена не выполняли проверку данных аутентификации, передаваемых вместе с запросом на доступ к ресурсу, полученным из доверенного домена. Доверяющий домен автоматически предполагал, что запросы содержат только те SID, которые были успешно авторизованы контроллерами доверенного домена.
Хотя подмена атрибута SIDHistory для учетной записи пользователя AD — процедура не совсем простая (и может быть выполнена только, когда AD находится в автономном режиме), но все же осуществимая. Доступны программы, которые помогут администратору целенаправленно изменить атрибут SIDHistory. Одну из таких программ — SHEdit — можно загрузить по адресу http://www.tbrio.com/projects/shedit/index.htm.
Атака этого типа может быть осуществлена при любой конфигурации доверительных отношений между доменами: между доменами одного леса или между доменами, связанными внешними или доверительными отношениями между лесами. В случае одного леса, например, обиженный администратор или обычный пользователь, имеющий доступ к контроллеру домена, может попытаться воспользоваться уязвимостью SIDHistory и получить права группы Enterprise Administrators.
Предотвращение атаки № 3
Для минимизации рисков, связанных с возможностью атаки с использованием атрибута SIDHistory, в первую очередь следует особо тщательно выбирать лиц, которым предоставляются права групп Enterprise Admins и Domain Admins. Необходимо также обеспечить высокий уровень физической защиты контроллеров домена, чтобы никто не смог отключить контроллер домена от сети и воспользоваться данной уязвимостью.
Для предотвращения редактирования атрибута SIDHistory администратором можно включить фильтрацию SID для доверительных отношений между различными листами. Фильтрация SID позволяет администраторам установить карантин для своего домена. При включении фильтрации SID контроллер доверяющего домена будет проверять, относятся ли переданные доверенным доменом в запросе на доступ к ресурсу данные авторизации к доверяющему домену. В этом случае контроллер доверяющего домена будет автоматически удалять посторонние SID, не относящиеся к доверяющему домену. При этом автоматически будут удалены все данные, передаваемые в атрибуте SIDHistory. Другими словами, атрибут SIDHistory и фильтрация SID есть вещи взаимоисключающие.
Фильтрация SID введена в Windows 2000 SP2 и реализована в последующих версиях. Для включения или отключения этого режима можно воспользоваться утилитой командной строки netdom.exe. Чтобы включить фильтрацию SID в Windows 2000, следует воспользоваться параметрами trust и filtersids, как описано в статье базы знаний Microsoft «MS02-001: Forged SID could result in elevated privileges in Windows 2000», доступной по адресу http://support.microsoft.com/?kbid=289243. В Windows 2003 используются параметры trust и quarantine, причем по умолчанию фильтрация SID включена для внешних отношений и доверительных отношений между лесами.
Не следует использовать фильтрацию SID для доверительных отношений внутри леса, поскольку она приведет в этом случае к разрыву репликации AD и транзитивных доверительных отношений. Если требуется использовать карантин для определенного домена, нужно поместить его в отдельный лес.
Атака № 4. Вызовы отказа в обслуживании (DoS) при массовом создании объектов AD
Пользователь, обладающий полномочиями администратора, может провести DoS-атаку на домен AD путем создания большого количества объектов AD. Авторизованный пользователь может, к примеру, вывести сервер AD из строя, создав такое количество объектов, что на сервере будет исчерпано дисковое пространство. Другой тип атаки — авторизованный пользователь может выполнить добавление нескольких тысяч членов в группу, выполнив всего одну команду добавления.
Предотвращение атаки № 4
Для защиты от атак такого рода необходимо предельно осторожно предоставлять права создания объектов AD. Следует также использовать квоты объектов AD. Этот механизм появился только в Windows 2003, но и в Windows 2000 имелись некоторые средства, позволяющие установить ограничения на объекты.
Квоты объектов AD позволяют ограничить число объектов, принадлежащих принципалу безопасности в контексте именования AD или разделе каталога. Квотирование объектов AD может настраиваться индивидуально для каждого контекста именования или раздела, но нельзя определить квоты для контекста именования схемы. Можно задать квоту по умолчанию для каждого контекста именования и раздела; если же этого не сделать, квота по умолчанию будет без ограничений.
Метки на удаление объектов (tombstone) AD, принадлежащие принципалу безопасности, расходуют квоту данного принципала. Метки на удаление представляют собой временные объекты AD, создаваемые при удалении объекта AD. AD использует их для поддержания целостности данных, принадлежащих удаленным объектам на контроллерах домена. Для каждого контроллера и раздела можно задать весовой коэффициент, с которым метка учитывается при расчете расходования квоты. Так, если коэффициент в данном разделе или контексте именования установлен равным 25, то метки на удаление будут учитываться с коэффициентом 0,25. По умолчанию коэффициент равен 100, т. е. метки на удаление учитываются так же, как и обычные объекты.
Можно назначить квоты для каждого принципала безопасности — учетной записи пользователя, компьютера, группы, а также принципалов inetOrg-Person. Принципалу может соответствовать множество квот, например, может быть назначена квота учетной записи пользователя, при этом пользователь может входить в группу безопасности, которой в свою очередь назначена другая квота. В этом случае квота принципала будет равна максимальной из применяемых квот. На членов групп Domain Admins и Enterprise Admins квотирование не распространяется.
Квоты объектов AD хранятся в контейнере NTDS Quotas контекста именования AD как объекты класса msDS-QuotaControl. Чтобы для пользователя Joe в домене Accounting установить квоту AD равной 10, следует ввести следующую команду Dsadd:
Dsadd quota -part DC=Accounting,DC=COM -acct AccountingJoe -qlimit 10 -desc "Quota for Joe"
Для установления коэффициента квоты для меток на удаление в домене Accounting равным 25 используется команда Dsmod:
Dsmod partition DC=Accounting,DC=COM -qtmbstnwt 25
Чтобы установить квоту объектов по умолчанию в домене Accounting равной 0, используется команда:
Dsmod partition DC=Accounting,DC=COM -qdefault 0
Устанавливать квоты может только контроллер домена, работающий под Windows 2003. Квоты применяются лишь при выполнении операций над каталогом, но не при операциях репликации. Для эффективного использования квот объектов AD в разделе домена необходимо, чтобы все контроллеры домена работали под Windows 2003 (другими словами, все домены и лес должны быть Windows 2003 с уровнем функциональности 2). Обратите внимание, что возможность использования квотирования объектов AD не связана с уровнем функциональности и будет работать на любом контроллере домена с Windows 2003. Если в домене Windows 2003 определены квоты и при этом еще имеются контроллеры Windows 2000, пользователи смогут обойти ограничения квотирования благодаря старым контроллерам домена.
В Windows 2000 поддерживается весьма ограниченная модель квотирования — администраторы могут ограничить количество учетных записей компьютеров, создаваемых одним пользователем. Для этого используется атрибут ms-DS-MachineAccountQuota объекта домена AD. В Windows 2000 квотирование не распространяется на членов административных групп Domain Admins и Account Operators. Атрибут ms-DS-MachineAccountQuota поддерживается в Windows 2003 (имеет значение по умолчанию, равное 10). Чтобы запретить пользователям добавление учетных записей компьютеров, следует сделать этот атрибут равным 0.
Аналогичного эффекта можно добиться, отняв право Add worksttions to domain у группы Authenticated Users (по умолчанию это право предоставляется группе Authenticated Users и в Windows 2003, и в Windows 2000).
АТАКА № 5. Отказ в обслуживании (DoS-атака) с использованием уязвимости MaxTokenSize
Разработчики Microsoft расширили базовый протокол Kerberos, чтобы разрешить включение в аутентификационный билет Kerberos данных авторизации. Билеты Windows Kerberos и TGT (Ticket Granting Ticket) содержат специальное поле PAC (Privilege Attribute Certificate), позволяющее протоколу Kerberos передавать внутри билета аутентификации данные авторизации, например права и членство пользователя в группах.
Билет Kerberos имеет фиксированный размер, что в свою очередь ограничивает и размер PAC. Если пользователь является членом большого числа групп (скажем, более 100), объем данных может превысить предоставляемый билетом размер, что может привести к отказу в аутентификации Windows или сбою обработки групповых политик. Пользователи, обладающие в AD правами создания и изменения групп, могут воспользоваться этой уязвимостью для организации DoS-атаки на учетные записи администраторов. В результате такой атаки администраторы не смогут регистрироваться в сети.
Предотвращение атаки № 5
Для предотвращения описанной атаки следует в первую очередь с особой осторожностью подходить к делегированию административных полномочий управления группами AD. Необходимо также максимально ограничить членство в административных группах. Настройки разрешений AD по умолчанию затрудняют подобное разграничение, поскольку при делегировании административных прав «доверенным» администраторам не требуются дополнительные разрешения для добавления любых учетных записей пользователей в локальные и универсальные группы, правами на управление которыми эти администраторы обладают. Поэтому учетные записи Enterprise Administrator и Domain Administrators следует поместить в отдельную организационную единицу, причем делегированные администраторы не должны обладать правом чтения этой организационной единицы
Кроме того, имеется возможность настройки размера билета Kerberos с помощью параметра реестра HKEY_LOCAL_MACHINESYSTEMCurrentControlSet ControlLsaKerberosParametersMaxTokenSize. Использование параметра Max TokenSize описано в статье базы знаний Microsoft «New resolution for problems that occur when users belong to many groups» по адресу http://support.microsoft.com/?kbid=327825).
Параметр MaxTokenSize (REG_DWORD) должен быть настроен на всех компьютерах, где пользователи задействуют протокол Kerberos для регистрации в домене. В Windows 2000 по умолчанию размер MaxTokenSize равен 8000 байт. В Windows 2000 SP2 и более поздних версиях размер MaxTokenSize увеличен до 12 000 байт.
Для сокращения размера PAC Microsoft начиная с Windows 2000 SP4 использует новый способ хранения данных авторизации в PAC. Кратко новый способ хранения данных авторизации можно описать следующим образом.
- Для локальных групп, а также для групп из других доменов весь SID группы (т. е. -1-5-21-1275210071-789336058-1957994488-3140) хранится в PAC.
- Если глобальная или универсальная группа, в которую входит пользователь, - локальная для домена, членом которого данный пользователь является, сохраняется только относительный идентификатор группы (RID), т. е. 3140.
Во время авторизации Windows использует специальный алгоритм преобразования RID обратно в формат SID на стороне клиента и на стороне сервера. Следует иметь в виду, что необходимость настройки значения MaxTokenSize может возникнуть даже на тех платформах, где используется новый метод хранения данных PAC в билете авторизации. Альтернативный способ — ограничить число групп, членами которых могут быть пользователи.
Для сокращения требований к размеру поля PAC в билете Kerberos следует удалить атрибут SIDHistory из учетных записей AD. Этот атрибут возникает при переносе учетных записей домена Windows NT 4 в среду Windows 2003 или Windows 2000. Процедура удаления SIDHistory достаточно подробно рассматривается в статье базы знаний Microsoft «How To Use Visual Basic Script to Clear SidHistory» по адресу http://support.microsoft.com/?kbid=295758.
Для борьбы с проблемами недостаточного размера билета Kerberos разработчики Microsoft создали утилиту Tokensz, которая доступна для загрузки со страницы http://www.microsoft.com/downloads/details.aspx?familyid=4a303fa5-cf20-43fb-9483-0f0b0dae265c&displaylang=en. Приведенная ниже команда позволяет определить текущее значение MaxTokenSize и размер текущего билета.
tokensz /compute_tokensize /package:negotiate /use_delegation /target_server:< MachineName >
Дополнительные сведения об использовании Tokensz можно найти в статье «Troubleshooting Kerberos Errors» по адресу http://www.microsoft.com/downloads/details.aspx?familyid=7dfeb015-6043-47db-8238-dc7af89c93f1&displaylang=en
По всем фронтам
Описанные в этой статье атаки подчеркивают важность многоуровневого подхода к обеспечению защиты инфраструктуры AD. Помимо технологических аспектов и решений, необходимо позаботиться о мерах физической безопасности и организационных процедурах. Важно обеспечить защиту от несанкционированного физического доступа контроллеров домена, сетевой инфраструктуры и зданий своей организации. Организационные меры включают в себя разработку политик безопасности, операционных процедур, регулярное выполнение аудита безопасности инфраструктуры AD с привлечением независимых специалистов, а также постоянное обучение администраторов и пользователей мерам безопасности и анализ передового опыта. Обеспечение защиты AD — одна из важнейших задач, для решения которой следует создать команду профессионалов, которые позаботятся о технической, физической и организационной защите.
Жан де Клерк - Член Security Office компании HP. Специализируется на управлении идентификационными параметрами и безопасности в продуктах Microsoft. Автор книги Windows Server 2003 Security Infrastructures (издательство Digital Press). jan.declercq@hp.com
Службы регистрации и активации
Использование политик безопасности IP для защиты серверов
Перед компаниями, которые связываются со своими партнерами по бизнесу по каналам WAN, часто встает вопрос защиты серверов от несанкционированного внешнего доступа. Настройки серверов Windows позволяют предоставлять доступ только клиентам из определенных IP-подсетей и не использовать брандмауэр.
Правила доступа реализуются с помощью политик безопасности IP Security Policies на системах Windows 2000 Server и Windows Server 2003. IP Security Policies — не совсем то же самое, что и IP Security (IPSec). Windows реализует IPSec с помощью IP Security Policies, т. е. IPSec есть только часть политик безопасности IP.
IP Security Policies позволяют фильтровать трафик по-IP адресам, протоколам или номеру порта. В зависимости от ситуации отфильтрованному пакету можно предоставить доступ, блокировать его или установить соединение IPSec для защиты пакета. Можно, например, создать политику безопасности IP из одного правила, по которому фильтр будет отбирать все пакеты с исходным IP-адресом, принадлежащим указанным подсетям. Все остальные пакеты будут блокироваться. Настроить сразу все серверы на использование данной политики можно путем создания соответствующего объекта Group Policy Object (GPO), применяемого к серверам. Конечно же, фильтрация на основе IP-адреса источника может быть недостаточной, поскольку не устраняет угроз, связанных с подменой IP-адреса, но в большинстве случаев данный подход вполне способен обеспечить безопасность.
Для более надежной защиты следует реализовать поддержку IPSec на важных серверах для аутентификации. Вместо политики, блокирующей пакеты от неизвестных подсетей, можно создать политику с фильтром, перехватывающим весь трафик и требующим аутентификации. Встроенная политика безопасности IP, называемая Secure Server (Require Security), реализует указанный фильтр. Также потребуется включить политику IP Security Policy Client (Respond Only) на всех клиентах данных серверов. Только пользователи, регистрирующиеся в лесу, смогут пройти аутентификацию, поскольку стандартные политики IP Security используют аутентификацию IPSec и Kerberos и подразумевают, что оба компьютера имеют учетные записи в одном лесу.
После включения IPSec на сервере при любом подключении клиента сервер отправит ему запрос на установление соединения IPSec, и если клиент не сможет этого сделать, то весь трафик от него будет блокирован.