Донецкий техникум промышленной автоматики

Відображення атак на AD

  1. Захист від злому паролів і інших поширених загроз Багато підприємств використовують AD в якості загального...
  2. Запобігання атаки № 1
  3. АТАКА № 2. Злом паролів за даними попередньої аутентифікації Kerberos
  4. Запобігання атаки № 2
  5. Атака № 3. Підвищення привілеїв за допомогою вразливості SIDHistory
  6. Запобігання атаки № 3
  7. Атака № 4. Виклики відмови в обслуговуванні (DoS) при масовому створенні об'єктів AD
  8. Запобігання атаки № 4
  9. АТАКА № 5. Відмова в обслуговуванні (DoS-атака) з використанням уразливості MaxTokenSize
  10. Запобігання атаки № 5
  11. По всіх фронтах
  12. Служби реєстрації та активації
Захист від злому паролів і інших поширених загроз

Багато підприємств використовують AD в якості загального корпоративного каталогу для інформаційної інфраструктури на базі Windows. AD стала важливим елементом більшості підприємств, а такі активи повинні бути надійно захищені.

AD може піддаватися багатьом видам атак, в цій статті ми розглянемо п'ять основних видів і способи захисту від них. Перші три види атак націлені на підвищення привілеїв атакуючого в AD. Четвертий і п'ятий види спрямовані на працездатність служби AD в мережевій інфраструктурі підприємства. За відсутності іншої домовленості, інформація в даній статті ставиться до версій AD Windows Server 2003 і Windows Server 2000.

Звичайно, всі види атак на 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, створений для пароль для 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, якщо при завданні паролів користувачі будуть дотримуватися таких правил.

АТАКА № 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/ID/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:

Додаткові відомості про використання 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). [email protected]

Служби реєстрації та активації

Використання політик безпеки 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, і якщо клієнт не зможе цього зробити, то весь трафік від нього буде блокований.

Com/?
Com/?
Com/?
Com/?
Com/?
Aspx?
Aspx?