ACLs - DACLs/SACLs/ACEs
Last updated
Last updated
Використовуйте Trickest, щоб легко створювати та автоматизувати робочі процеси, підтримувані найсучаснішими інструментами спільноти. Отримайте доступ сьогодні:
Список контролю доступу (ACL) складається з упорядкованого набору записів контролю доступу (ACE), які визначають захист для об'єкта та його властивостей. По суті, ACL визначає, які дії якими суб'єктами безпеки (користувачами або групами) дозволені або заборонені для даного об'єкта.
Існує два типи ACL:
Дискреційний список контролю доступу (DACL): Визначає, які користувачі та групи мають або не мають доступ до об'єкта.
Системний список контролю доступу (SACL): Регулює аудит спроб доступу до об'єкта.
Процес доступу до файлу передбачає перевірку системою дескриптора безпеки об'єкта проти токена доступу користувача, щоб визначити, чи слід надати доступ і в якій мірі, на основі ACE.
DACL: Містить ACE, які надають або забороняють права доступу користувачам і групам для об'єкта. Це, по суті, основний ACL, який визначає права доступу.
SACL: Використовується для аудиту доступу до об'єктів, де ACE визначають типи доступу, які потрібно реєструвати в журналі подій безпеки. Це може бути безцінним для виявлення несанкціонованих спроб доступу або усунення проблем з доступом.
Кожна сесія користувача асоційована з токеном доступу, який містить інформацію про безпеку, що стосується цієї сесії, включаючи ідентичності користувача, групи та привілеї. Цей токен також включає SID входу, який унікально ідентифікує сесію.
Локальний орган безпеки (LSASS) обробляє запити на доступ до об'єктів, перевіряючи DACL на наявність ACE, які відповідають суб'єкту безпеки, що намагається отримати доступ. Доступ надається негайно, якщо не знайдено відповідних ACE. В іншому випадку LSASS порівнює ACE з SID суб'єкта безпеки в токені доступу, щоб визначити право на доступ.
ACL: Визначають права доступу через DACL та правила аудиту через SACL.
Токен доступу: Містить інформацію про користувача, групу та привілеї для сесії.
Рішення про доступ: Приймається шляхом порівняння ACE DACL з токеном доступу; SACL використовуються для аудиту.
Існує три основні типи записів контролю доступу (ACEs):
ACE заборони доступу: Цей ACE явно забороняє доступ до об'єкта для зазначених користувачів або груп (в DACL).
ACE дозволу доступу: Цей ACE явно надає доступ до об'єкта для зазначених користувачів або груп (в DACL).
ACE системного аудиту: Розташований у системному списку контролю доступу (SACL), цей ACE відповідає за створення журналів аудиту при спробах доступу до об'єкта користувачами або групами. Він документує, чи був доступ дозволений або заборонений, і характер доступу.
Кожен ACE має чотири критичних компоненти:
Ідентифікатор безпеки (SID) користувача або групи (або їх ім'я суб'єкта в графічному представленні).
позначка, яка ідентифікує тип ACE (доступ заборонено, дозволено або системний аудит).
позначки успадкування, які визначають, чи можуть дочірні об'єкти успадковувати ACE від батьківського.
маска доступу, 32-бітове значення, що вказує на надані права об'єкта.
Визначення доступу проводиться шляхом послідовного перевірки кожного ACE, поки:
ACE заборони доступу явно забороняє запитувані права довіреній особі, ідентифікованій у токені доступу.
ACE дозволу доступу явно надають всі запитувані права довіреній особі в токені доступу.
Після перевірки всіх ACE, якщо будь-яке запитуване право не було явно дозволено, доступ автоматично забороняється.
Спосіб, яким ACEs (правила, що визначають, хто може або не може отримати доступ до чогось) розташовані в списку, званому DACL, є дуже важливим. Це тому, що як тільки система надає або забороняє доступ на основі цих правил, вона перестає перевіряти решту.
Існує найкращий спосіб організувати ці ACE, і він називається "канонічний порядок." Цей метод допомагає забезпечити, щоб все працювало гладко та справедливо. Ось як це виглядає для систем, таких як Windows 2000 та Windows Server 2003:
Спочатку розмістіть усі правила, які створені конкретно для цього елемента, перед тими, що походять з іншого місця, наприклад, з батьківської папки.
У цих конкретних правилах розмістіть ті, що говорять "ні" (заборонити) перед тими, що говорять "так" (дозволити).
Для правил, що походять з іншого місця, почніть з тих, що походять з найближчого джерела, наприклад, з батьківського, а потім йдіть далі. Знову ж таки, розмістіть "ні" перед "так."
Ця структура допомагає у двох великих аспектах:
Вона забезпечує, що якщо є конкретне "ні," воно поважатиметься, незалежно від інших "так" правил.
Вона дозволяє власнику елемента мати остаточне слово щодо того, хто може отримати доступ, перед тим, як будь-які правила з батьківських папок або далі вступлять у силу.
Таким чином, власник файлу або папки може бути дуже точним щодо того, хто отримує доступ, забезпечуючи, щоб правильні люди могли увійти, а неправильні - ні.
Отже, цей "канонічний порядок" полягає в тому, щоб забезпечити, щоб правила доступу були чіткими та працювали добре, ставлячи конкретні правила на перше місце та організовуючи все розумно.
Використовуйте Trickest, щоб легко створювати та автоматизувати робочі процеси, підтримувані найсучаснішими інструментами спільноти. Отримайте доступ сьогодні:
Це класична вкладка безпеки папки, що показує ACL, DACL та ACE:
Якщо ми натиснемо кнопку Додатково, ми отримаємо більше опцій, таких як успадкування:
І якщо ви додаєте або редагуєте Суб'єкт безпеки:
І нарешті, у нас є SACL на вкладці Аудит:
Коли ми керуємо доступом до ресурсів, таких як папка, ми використовуємо списки та правила, відомі як Списки контролю доступу (ACL) та Записи контролю доступу (ACE). Вони визначають, хто може або не може отримати доступ до певних даних.
Уявіть, що у вас є папка з назвою Витрати, і ви хочете, щоб усі мали доступ до неї, крім команди маркетингу. Налаштувавши правила правильно, ми можемо забезпечити, щоб команді маркетингу був явно заборонений доступ перед тим, як дозволити всім іншим. Це робиться шляхом розміщення правила заборони доступу для команди маркетингу перед правилом, яке дозволяє доступ усім.
Припустимо, Боб, директор з маркетингу, потребує доступу до папки Витрати, хоча загалом команді маркетингу не слід мати доступ. Ми можемо додати конкретне правило (ACE) для Боба, яке надає йому доступ, і розмістити його перед правилом, яке забороняє доступ команді маркетингу. Таким чином, Боб отримує доступ, незважаючи на загальне обмеження для його команди.
ACEs - це окремі правила в ACL. Вони ідентифікують користувачів або групи, вказують, який доступ дозволено або заборонено, і визначають, як ці правила застосовуються до підоб'єктів (успадкування). Існує два основних типи ACE:
Генеричні ACE: Ці правила застосовуються широко, впливаючи або на всі типи об'єктів, або розрізняючи лише контейнери (наприклад, папки) та неконтейнери (наприклад, файли). Наприклад, правило, яке дозволяє користувачам бачити вміст папки, але не отримувати доступ до файлів у ній.
Об'єктно-специфічні ACE: Ці правила забезпечують більш точний контроль, дозволяючи встановлювати правила для конкретних типів об'єктів або навіть окремих властивостей в об'єкті. Наприклад, у каталозі користувачів правило може дозволити користувачу оновити свій номер телефону, але не години входу.
Кожен ACE містить важливу інформацію, таку як те, до кого застосовується правило (використовуючи ідентифікатор безпеки або SID), що дозволяє або забороняє правило (використовуючи маску доступу) і як воно успадковується іншими об'єктами.
Генеричні ACE підходять для простих сценаріїв контролю доступу, де те саме правило застосовується до всіх аспектів об'єкта або до всіх об'єктів у контейнері.
Об'єктно-специфічні ACE використовуються для більш складних сценаріїв, особливо в середовищах, таких як Active Directory, де вам може знадобитися контролювати доступ до конкретних властивостей об'єкта по-різному.
У підсумку, ACL та ACE допомагають визначити точний контроль доступу, забезпечуючи, щоб лише правильні особи або групи мали доступ до чутливої інформації або ресурсів, з можливістю налаштування прав доступу до рівня окремих властивостей або типів об'єктів.
| Поле ACE | Опис |
|---|---|
Тип | Позначка, яка вказує тип ACE. Windows 2000 та Windows Server 2003 підтримують шість типів ACE: три загальних типи ACE, які прикріплюються до всіх об'єктів, що підлягають захисту. Три об'єктно-специфічні типи ACE, які можуть виникати для об'єктів Active Directory. |
Позначки | Набір бітових позначок, які контролюють успадкування та аудит. |
Розмір | Кількість байтів пам'яті, які виділені для ACE. |
Маска доступу | 32-бітове значення, біти якого відповідають правам доступу для об'єкта. Біти можуть бути встановлені або включені, але значення налаштування залежить від типу ACE. Наприклад, якщо біт, що відповідає праву на читання дозволів, увімкнено, а тип ACE - Заборонити, ACE забороняє право на читання дозволів об'єкта. Якщо той же біт увімкнено, але тип ACE - Дозволити, ACE надає право на читання дозволів об'єкта. Більше деталей про маску доступу з'являється в наступній таблиці. |
SID | Ідентифікує користувача або групу, доступ яких контролюється або моніториться цим ACE. |
| Біт (діапазон) | Значення | Опис/Приклад |
|---|---|---|
0 - 15 | Специфічні права доступу до об'єкта | Читати дані, Виконати, Додати дані |
16 - 22 | Стандартні права доступу | Видалити, Записати ACL, Записати власника |
23 | Може отримати доступ до безпекового ACL | |
24 - 27 | Зарезервовано | |
28 | Генеричний ВСЕ (Читати, Записати, Виконати) | Все нижче |
29 | Генеричне виконання | Усі речі, необхідні для виконання програми |
30 | Генеричний запис | Усі речі, необхідні для запису у файл |
31 | Генеричне читання | Усі речі, необхідні для читання файлу |
Використовуйте Trickest, щоб легко створювати та автоматизувати робочі процеси, підтримувані найсучаснішими інструментами спільноти. Отримайте доступ сьогодні:
Вчіться та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Вчіться та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Вчіться та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Вчіться та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
