Трохи про те, як не треба захищати облікові записи Active Directory

Написати цей текст мене спонукало періодична поява на Хабре статей адміністраторів Windows, автори яких, на мій погляд, не дуже добре розуміють, що роблять. Останній з таких посад — про захист службових облікових записів.

Перш за все хочеться сказати наступне, шановні колеги, захист облікових записів — хоча і типова, але ні в якому разі НЕ просте завдання, особливо для середнього системного адміністратора, який не є фахівцем з інформаційної безпеки. Якщо вам пощастило і ви потрапили в організацію, де всі регламенти та процеси розроблені до вас — вам, звичайно, буде досить просто скористатися плодами чужої праці. Але якщо все, що у вас є на руках — свежеподнятый (або, що ще гірше, піднятий не зрозумій ким і як) домен AD і гугл, не варто підходити до задачі в стилі «прочитаю Best practices, зроблю як там пишуть, і все буде пучком».

Як приклад, чому будь-які загальні рекомендації треба застосовувати з обережністю, розглянемо класичний варіант з блокуванням облікових записів за кількістю невдалих спроб входу, згаданий в статті вище. Багато необґрунтовано вважають, що Best practice тут — включати блокування. Це дійсно може бути корисною мірою, якщо ви з якихось причин впевнені, що зловмисник зможе дізнатися імена лише невеликої кількості учеток.

На жаль, у цього способу є один недолік — якщо зловмисник отримав доступ до списку облікових записів, він зможе заблокувати їх всі. Тут, зокрема, слід пам'ятати про одну річ — будь обліковий запис в домені ОГОЛОШЕННЯ може надсилати запити до служби каталогів і за замовчуванням має права на читання практично всіх її розділів. На практиці це означає, що, якщо зловмисник дізнається логін-пароль хоч одного користувача, він з допомогою простого LDAP-запита зможе отримати список ВСІХ (так, зовсім всіх облікових записів в домені. І, якщо у вас включена політика блокування учеток, він зможе все їх заблокувати. Уявіть собі наслідки і спробуйте придумати, що ви будете робити, якщо вас спіткає подібна доля.

До слова, запропонований автором варіант рішення з автоматичною розблокуванням учеткі і відправкою повідомлення адміністратору насправді не є рішенням — якщо на запис дійсно ведуть атаку перебору паролів автоматизованими засобами, вона з високою ймовірністю просто буде тут же знову заблокована.

Як можна не вистрілити собі в ногу? Наприклад, задуматися над питанням, а чи потрібна взагалі блокування записів, і чи не краще буде відслідковувати невдалі спроби входу самі по собі, благо штатними засобами Windows можна повісити алерти на що потрапили в Event Log події і обробляти ці події так, як вам потрібно (а не просто шляхом «три невдалі спроби — постріл»). При цьому, однак, варто пам'ятати, що учетка може авторизуватися на контролер домену в мережі, і кожен КД треба моніторити окремо. Можна згадати, що в більш-менш сучасних версіях Windows політик безпеки може бути кілька. Отже, можна більш акуратно підійти до питання, які учеткі блокувати, а які — ні. По-третє, можна навіть зайнятися питанням, яким звичайний адміністратор Windows ніколи не займається, а саме обмеженням даних користувача за замовчуванням прав AD (зауважу, що це може мати сенс і поза контекстом захисту саме учеток).

Таким чином, навіть одна з найбільш частих і типових завдань для успішного рішення (а не видно рішення) вимагає досить уважного підходу і може вимагати заглиблення у питання, про яких переважна більшість адміністраторів Windows просто не замислюється.

Далі, коли ми переходимо до захисту службових (а не призначених для користувача облікових записів, автор вважає, що ці записи «не захищені від перебору і з роками не меняемым паролем». Залишимо осторонь питання з Managed Service accounts — по моєму особистому досвіду місць, де можна їх застосувати, куди менше, ніж місць, де не можна. Однак необхідно пам'ятати про дві речі — по-перше, паролі службових учеток не зобов'язані відповідати вимозі зручності для людини, і, отже, можуть бути куди більш сильними, по-друге, в Windows, як не дивно, є засоби автоматизації, що дозволяють змінювати паролі — простий приклад. Зрозуміло, що автоматизація тут не завжди можлива (і взагалі зміна пароля в ряді випадків може представляти квест, який абсолютно не хочеться проходити без крайньої необхідності), але, тим не менш, пам'ятати про це треба.

Автор також згадує про обмеження на локальний вхід для службових учеток загальної доменної політикою. В деяких випадках це може бути корисно, однак треба розуміти, що заборона на локальний вхід може не означати взагалі нічого, особливо в досить часто зустрічається разі, коли службова учетка володіє розширеними правами в домені або на окремих комп'ютерах. Обмеження списку машин, на які учетка взагалі може заходити — річ більш сильна, але застосовувати його треба з обережністю.

І, зрозуміло, це далеко не всі питання, про які можна поговорити як стосовно до критикованої статті, так і до теми взагалі.

Підводячи деякі підсумки:

1. Не слід ставитися навіть до базових моментів ІБ як до «простому» питання. Думайте, думайте добре, особливо якщо ви — новачок.
2. Ілюзія захищеності, яку може створити слідування не дуже добре продуманим радам — гірше, ніж розуміння, що у тебе є проблема і недостатньо знань для вирішення.
3. Якщо ви хочете писати статтю на тему, а не просто діліться власним досвідом в стилі «я зробив так, що ви про це думаєте?» — будь ласка, як слід вивчіть тему, за якою ви пишете. Некомпетентність в світі і так більш ніж достатньо, не варто її примножувати, попутно ризикуючи створити великі проблеми з тим, кому ви, ймовірно, хочете допомогти.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.