Розробка програми виявлення порушення прав доступу до об’єктів файлової системи

Набори структур даних, використовуваних для управління файлами. Права доступу до файлу. Монітор файлової системи Process Monitor. Управління аудитом в ОС Windows та в ОС Linux. Доступ до служби каталогів. Практичне застосування Process Monitor.

Рубрика Программирование, компьютеры и кибернетика
Вид курсовая работа
Язык украинский
Дата добавления 09.01.2014
Размер файла 695,9 K

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Размещено на http://www.allbest.ru/

РОЗРАХУНКОВО-ПОЯСНЮВАЛЬНА ЗАПИСКА

До курсової роботи з системного програмного забезпечення

Розробка програми виявлення порушення прав доступу до об'єктів файлової системи

Зміст

ВСТУП

1. ОГЛЯД ОБ'ЄКТУ ДОСЛІДЖЕННЯ

1.1 Опис предметної області

1.2 Постановка завдання

2. МОНІТОР ФАЙЛОВОЇ СИСТЕМИ PROCESS MONITOR

2.1 Опис утиліти

2.2 Практичне застосування Process Monitor

3. АУДИТ БЕЗПЕКИ В ОС WINDOWS ТА LINUX

3.1 Загальні поняття

3.2 Управління аудитом в ОС Windows

3.3 Управління аудитом в ОС Linux

ВИСНОВКИ

СПИСОК ЛИТЕРАТУРИ

ВСТУП

У широкому розумінні поняття "файлова система" включає: сукупність всіх файлів на диску, набори структур даних, використовуваних для управління файлами, такі, наприклад, як каталоги файлів, дескриптори файлів, таблиці розподілу вільного і зайнятого простору на диску; комплекс системних програмних засобів, що реалізують керування файлами, зокрема: створення, видалення, читання, запис, іменування, пошук та інші операції над файлами тощо.

У системах з декількома користувачами, одна з основних задач це захист файлів одного користувача від несанкціонованого доступу іншого користувача, а також забезпечення спільної роботи з файлами. Це питання може бути вирішено за допомогою системних утиліт, спеціалізованого програмного забезпечення або вмонтованих у операційну систему сервісів.

1. Огляд об'єкту дослідження

1.1 Опис предметної області

Файлова система

Файлова система - це частина операційної системи, призначення якої полягає в тому, щоб забезпечити користувачеві зручний інтерфейс при роботі з даними, що зберігаються на диску, і забезпечити спільне використання файлів кількома користувачами і процесами.

Типи файлів

Файли бувають різних типів: звичайні файли, спеціальні файли, файли-каталоги. Звичайні файли в свою чергу поділяються на текстові і двійкові. Текстові файли складаються з рядків символів, представлених в ASCII-коді. Це можуть бути документи, вихідні тексти програм тощо. Текстові файли можна прочитати на екрані і роздрукувати на принтері. Двійкові файли не використовують ASCII-коди, вони часто мають складну внутрішню структуру, наприклад, об'єктний код програми або архівний файл. Всі операційні системи повинні вміти розпізнавати хоча б один тип файлів - їх власні виконувані файли.

Спеціальні файли - це файли, асоційовані з пристроями вводу-виводу, які дозволяють користувачеві виконувати операції вводу-виводу, використовуючи звичайні команди запису у файл або читання з файлу. Ці команди обробляються спочатку програмами файлової системи, а потім на деякому етапі виконання запиту перетворюються ОС в команди управління відповідним пристроєм. Спеціальні файли, так само як і пристрої введення-виведення, діляться на блок-орієнтовані і байт-орієнтовані.

Каталог - це, з одного боку, група файлів, об'єднаних користувачем виходячи з деяких міркувань (наприклад, файли, що містять програми ігор, або файли, складові один програмний пакет), а з іншого боку - це файл, що містить системну інформацію про групу файлів, його складових. У каталозі міститься список файлів, що входять до нього, і встановлюється відповідність між файлами і їх характеристиками (атрибутами). У різних файлових системах можуть використовуватися в якості атрибутів різні характеристики, наприклад:

· інформація про дозволений доступ,

· пароль для доступу до файлу,

· власник файлу,творець файлу,

· ознака "тільки для читання",

· ознака "прихований файл",

· ознака "системний файл",

· ознака "архівний файл",

· ознака "двійковий / символьний",

· ознака "тимчасовий" (видалити після завершення процесу),

· ознака блокування,

· довжина запису,

· покажчик на ключове поле в записі,

· довжина ключа,часи створення,

· останнього доступу і останньої зміни,

· поточний розмір файлу,

· максимальний розмір файлу.

Каталоги можуть безпосередньо містити значення характеристик файлів, як це зроблено в файловій системі MS-DOS, або посилатися на таблиці, що містять ці характеристики, як це реалізовано в ОС UNIX (рисунок 1.1). Каталоги можуть утворювати ієрархічну структуру за рахунок того, що каталог нижчого рівня може входити в каталог більш високого рівня (рисунок 1.2).

Рисунок 1.1 Структура каталогів: а - структура запису каталогу MS-??DOS (32 байти); б - структура запису каталогу ОС UNIX.

Ієрархія каталогів може бути деревом або мережею. Каталоги утворюють дерево, якщо файлу дозволено входити тільки в один каталог, і мережа - якщо файл може входити відразу в кілька каталогів. У MS-DOS каталоги утворюють деревовидну структуру, а в Unix - мережеву. Як і будь-який інший файл, каталог має символьне ім'я і однозначно ідентифікується складовим ім'ям, що містить ланцюжок символьних імен всіх каталогів, через які проходить шлях від кореня до даного каталогу.

Рисунок 1.2 Логічна організація файлової системи - однорівнева, б - ієрархічна (дерево); в - ієрархічна (мережа).

Права доступу до файлу

Визначити права доступу до файлу - значить визначити для кожного користувача набір операцій, які він може застосувати до даного файлу. У різних файлових системах може бути визначений свій список диференційованих операцій доступу. Цей список може включати наступні операції:

· створення файлу,

· знищення файлу,

· відкриття файлу,

· закриття файлу,

· читання файлу,

· запис у файл,

· доповнення файлу,

· пошук у файлі,

· отримання атрибутів файлу,

· встановлення нових значень атрибутів,

· перейменування,

· виконання файлу,

· читання каталогу,

та інші операції з файлами і каталогами. У самому загальному випадку права доступу можуть бути описані матрицею прав доступу, в якій стовпці відповідають всім файлам системи, рядки - всім користувачам, а на перетині рядків і стовпців вказуються дозволені операції (рисунок 1.3). У деяких системах користувачі можуть бути розділені на окремі категорії. Для всіх користувачів однієї категорії визначаються єдині права доступу. Наприклад, у системі UNIX всі користувачі підрозділяються на три категорії: власника файлу, членів його групи і всіх інших.

Рисунок 1.3 Матриця прав доступу

Файлові системи з ACL

Access Control List або ACL - список контролю доступу, який визначає, хто або що може отримувати доступ до конкретного об'єкту, і які саме операції дозволено або заборонено цьому суб'єкту проводити над об'єктом.

У файлових системах для реалізації ACL використовується ідентифікатор користувача процесу (UID в термінах POSIX).

Список доступу являє собою структуру даних (зазвичайну таблицю), що містить записи, що визначає права індивідуального користувача або групи на спеціальні системні об'єкти, такі як програми, процеси або файли. Ці записи також відомі як ACE (англ. Access Control Entries) в операційних системах Microsoft Windows і OpenVMS. В операційній системі Linux і Mac OS X більшість файлових систем мають розширені атрибути, що виконують роль ACL. Кожен об'єкт в системі містить покажчик на свій ACL. Привілеї (або повноваження) визначають спеціальні права доступу, що дозволяють користувачеві читати, писати або виконувати об'єкт. У деяких реалізаціях ACE можуть визначати право користувача або групи на зміну ACL об'єкта.

Концепції ACL в різних операційних системах розрізняються, незважаючи на існуючий «стандарт» POSIX. (Проекти безпеки POSIX, .1 e і .2 c, були відкликані, коли стало ясно що вони зачіпають занадто велику область і робота не може бути завершена, але добре опрацьовані частини, що визначають ACL, були широко реалізовані і відомі як «POSIX ACLs».)

1.2 Постановка завдання

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

2. Монітор файлової системи Process Monitor

2.1 Опис утиліти

Загальні відомості

Process Monitor - програма від компанії Sysinternals для спостереження в реальному масштабі часу за діями різних процесів в середовищі операційної системи Windows. Утиліта Process Monitor, включає в себе можливості програми моніторингу звернень до реєстру Regmon і програми моніторингу звернень до файлової системи Filemon, і додатково, дозволяє отримувати більш детальну інформацію про взаємодію процесів, використання ресурсів, мережевої активності та операціях введення-виведення.

Програма працює у всіх версіях ОС Windows, не вимагає інсталяції, однак має виконуватися під обліковим записом з правами адміністратора.

Для своєї роботи, Process Monitor встановлює в системі власний драйвер PROCMON20.SYS, за допомогою якого виконується перехоплення контрольованих монітором системних функцій і збір даних підлягають моніторингу. Спостереження виконується для наступних класів операцій - звернення до файлової системи (file system), звернення до реєстру (Registry), робота з мережею (Network), і активність процесів (Process). Після старту програми Process Monitor, виводиться вікно з фільтрами для виключення з процесу спостереження подій стандартної активності системи і самого монітора (рисунок 2.1).

Після запуску виконуваного файлу procmon.exe починається збір, обробка й виведення даних про відслідковуються подіях в основному вікні програми (рисунок 2.2).

Інтерфейс програми складається з 3-х частин - рядок меню (menu bar), панель інструментів (toolbar) і область виводу даних у вигляді списку. Програма перехоплює відстежувані події, пов'язані з активністю процесів і видає дані у відповідності з заданими критеріями фільтрації та користувацькими налаштуваннями відображуваних колонок.

Рисунок 2.1 Вікно з фільтрами для виключення з процесу спостереження

Рисунок 2.2 Основне вікно програми

Кожній події, перехоплених програмою Process Monitor, відповідає один рядок у вікні виводу даних. Подвійне клацання на окремому рядку викличе вікно перегляду властивостей події (Event Properties). Порядок проходження рядків відповідає послідовності виконання операцій. Інформація у вікні виводу даних розділена на декілька стовпців, склад яких можна вибрати за допомогою контекстного меню Select Columns, що викликається правою кнопкою мишки на поле опису колонок або через головне меню - Options - Select Columns.

Рисунок 2.3 Вікно вибору колонок

Можливий виведення колонок, розбитих на 3 категорії:

Application Details - відомості про процес

Event Details - відомості про подію

Process Management - дані про батьківський процес, породжуваних потоках і контексті облікового запису безпеки досліджуваного процесу.

Встановлення фільтрів

Process Monitor запам'ятовує останній використовуваний набір фільтрів і застосовує його при наступному запуску програми. Задати умови фільтрації можна відразу після старту утиліти або викликавши вікно налаштування фільтрів (Process Monitor Filters) в будь-який момент часу з використанням меню програми або комбінації клавіш CTRL + L. Крім безпосереднього створення правил фільтрації вручну, можливе використання кнопок панелі інструментів і контекстного меню, що викликається правою кнопкою мишки.

Рисунок 2.4 Виклик контекстного меню

Меню дозволяє виконувати дії фільтрів Include, Exclude і Highlight з використанням даних вибраного події. Так, наприклад, вибір пункту меню Exclude "PTStartmon.exe" призведе до створення правила фільтру для виключення з спостереження процесу з ім'ям PTStartmon.exe. Вибір Highlight - випадаюче меню - Result викличе підсвічування всіх записів, у поле результату виконання відслідковується операції яких, буде таке ж значення, як і в поточному подію. Exclude та Category - виключити з вихідних даних події, категорія яких збігається з категорією обраної записи. Створення фільтрів вручну дозволяє отримувати більш гнучкі правила, засновані на використанні логічних виразів.

Рисунок 2.5 Фільтр що створений вручну

управління файл каталог доступ

Column (колонка) - вибираємо значення Company

Relation (вираз - можна вибрати is (дорівнює) чи, більш універсально - contain (містить)

Value (значення) - вибираємо Microsoft Corporation

Action (дія) - вибираємо Exclude - виключити.

У підсумку, одержуємо правило - "не відображати події, в полі імені компанії яких присутня значення Microsoft Corporation".

2.2 Практичне застосування Process Monitor

Одне з основних застосувань Process Monitor - визначення причин аварійного завершення додатків у разі відсутності або невірного розташування файлів, каталогів, розділів і ключів реєстру. Іноді програма використовується для дослідження роботи конкретного додатка, наприклад для визначення місцезнаходження налаштувань оглядача Mozilla Firefox. При дослідженні поведінки конкретного додатка, бажано створити такі умови фільтрації, щоб не відображалася зайва інформація і не загубилася потрібна. Як правило, налаштування додатків зберігаються або в реєстрі, або у файлі, тому, потрібно відсіяти відображення подій, не пов'язаних з даним додатком (ім'я процесу не дорівнює firefox.exe) і потрібним видом активності Event Class (виключити події мережевої активності Network і класу Profiling і включити події класів Registry і File System). Після налаштування фільтра, бажано очистити активний буфер (CTRL + X) і викликати виконання досліджуваного події - тобто перейти у вікно Firefox.exe, змінити і зберегти якусь із налаштувань. Після чого потрібно повернутися у вікно Process Monitor, зупинити процес перехоплення подій і приступити до аналізу отриманих даних. Звичайно, у випадку складної програми, кількість операцій звернення до реєстру і файлової системи може обчислюватися сотнями або навіть тисячами, і в подібних випадках, доведеться розбиратися виходячи зі здорового глузду і можливої логіки роботи програми. Так, найбільш ймовірно, що:

Налаштування будь-якого додатку не можуть зберігатися в тимчасових файлах, тому їх можна відразу виключити з аналізу. - Налаштування оглядача Firefox індивідуальні для кожного користувача, і отже, пов'язані з його профілем (каталог C:\Documents And Settings\користувач для Win2k/XP, C:\Users\Користувач для Windows Vista/7) і розділ реєстру HKEY CURRENT USER ( HKCU)).

Можна також виділити той факт, що збереження опцій - це операція запису. В результаті таких припущень, коло пошуку буде значно звужений і процес аналізу подій стане простіше. В якості відповіді для задачі пошуку місця зберігання налаштувань Firefox - для користувача налаштування зберігаються не в реєстрі, а файлі з ім'ям prefs.js. Аналіз вмісту файлу підтверджує припущення, що це саме налаштування. У перших рядках міститься текст:

# Mozilla User Preferences

/* Do not edit this file.

*

* If you make changes to this file while the application is running,

* the changes will be overwritten when the application exits.

*

* To make a manual change to preferences, you can visit the URL about:config

* For more information, see http://www.mozilla.org/unix/customizing.html#prefs

*/

З перекладу стає зрозуміло, що налаштування, внесені вручну в даний файл, при запущеному оглядачі, не будуть збережені, оскільки будуть перезаписані при його завершенні. І для ручного зміни налаштувань слід в адресному рядку Mozilla Firefox набрати about:config. За додатковою інформацією пропонується перейти по посиланню на сайт mozilla.org. А також, зрозуміло, що для збереження поточних налаштувань оглядача, можна скопіювати вміст файлу prefs.js в файл з іншим ім'ям і при необхідності, в будь-який момент, відновити їх з збереженої копії.

Можливості Process Monitor дозволяють також отримувати сумарні показники використання ресурсів системи (меню Tools -: Summary) (рисунок 2.6).

Рисунок 2.6 Приклад відображення сумарних показників використання файлової системи

При необхідності отримання даних про статистику використання окремих каталогів можна перейти на вкладку By Folder (рисунок 2.7).

Рисунок 2.7 Приклад відображення окремих каталогів

При необхідності отримання статистики використання файлів по розширенню, потрібно перейти на вкладку By Extensions (рисунок 2.8).

Рисунок 2.8 Статистики використання файлів по розширенню

відображається статистика

Total - загальне число звернень до реєстру

Opens - число виконань операцій відкриття

Closes - число виконань операцій закриття

Reads - число виконань операцій читання

Writes - число виконань операцій запису

Others - число виконань інших операцій

Paths - Шлях розділу або ключа реєстру

3. Аудит безпеки в ОС Windows та Linux

3.1 Загальні поняття

Аудит - це один з основних засобів захисту ОС. Аудит дозволяє відстежувати і реєструвати події, пов'язані з безпекою. Прикладами подій для аудиту можна назвати доступ до файлу, вхід в систему або зміна системної конфігурації.

Журнал безпеки являє собою базу даних або файл, у якому реєструються події, пов'язані з безпекою системи.

Завдяки системі аудиту, адміністратор може дізнатися, хто, яким чином і коли скористався (або намагався скористатися, але отримав відмову в доступі) цікавими для нього ресурсами.

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

Найбільш загальними типами подій для аудиту безпеки є:

· доступ до файлів і каталогів;

· управління обліковими записами користувачів і груп;

· вхід користувачів в систему і вихід з неї.

Як правило, фіксуються наступні параметри, що стосуються дій, що здійснюються користувачами:

· виконану дію;

· ідентифікатори користувачів і груп, які виконали дію;

· дата і час виконання.

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

3.2 Управління аудитом в ОС Windows

Політика аудиту

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

Налаштування політик аудиту доступна в оснащенні Групова політика. Існують наступні категорії аудиту:

· Аудит подій входу в систему відстежує події, пов'язані з входом користувача у систему і виходом з неї;

· Аудит управління обліковими записами відстежує всі події, пов'язані з управлінням обліковими записами. Записи аудиту з'являються при створенні, зміні або видаленні облікових записів користувача або групи;

· Аудит доступу до служби каталогів відстежує події доступу до каталогу Active Directory. Записи аудиту створюються кожен раз при доступі користувачів або комп'ютерів до каталогу;

· Аудит входу в систему відстежує події входу в систему або виходу з неї, а також вилучені мережеві підключення;

· Аудит доступу до об'єктів відстежує використання системних ресурсів файлами, каталогами, загальними ресурсами, і об'єктами Active Directory;

· Аудит зміни політики відстежує зміни політик призначення прав користувачів, політик аудиту або політик довірчих відносин;

· Аудит використання привілеїв відстежує кожну спробу застосування користувачем наданого йому права або привілеї,

· Аудит відстеження процесів відстежує системні процеси і ресурси, використовувані ними,

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

Розглянемо більш докладно політики які безпосередньо стосуються безпеки файлової системи.

Аудит доступу до служби каталогів

Категорія Аудит доступу до служби каталогів забезпечує низькорівневий аудит об'єктів ActiveDirectory (AD) та їх властивостей. Оскільки дана категорія має безпосереднє відношення до AD, то активувати аудит подібних подій на системах, які не є контролерами домену, не має ні найменшого сенсу.

Аудит доступу до об'єктів

Сам по собі цей параметр політики не запускає аудиту яких-небудь подій. Параметр Аудит доступу до об'єктів визначає необхідність аудиту подій доступу до об'єкта (наприклад до файлу, папки, розділу реєстру або принтеру), для якого заданий системний список управління доступом (SACL).

System Access-Control List (SACL) - список, схожий на ACL, але що відповідає не за дозвіл або заборону на доступ, а за аудит (протоколювання в журналі безпеки) успішних і безуспішних спроб доступу до об'єкта. SACL складається із записів управління доступом. Кожен запис управління доступом включає відомості трьох типів:

· учасник безпеки (користувач, комп'ютер або група), для якого буде виконуватися аудит;

· певний тип доступу, для якого буде виконуватися аудит (маска доступу);

· прапор, який вказує на необхідність аудиту подій збою доступу, успішного доступу або того й іншого виду подій.

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

При налаштуванні системних списків управління доступом організації повинні визначати тільки ті дії, які необхідно включити. Наприклад, може знадобитися включити параметр Аудит запису і додавання даних для EXE-файлів, щоб відслідковувати їх зміну або заміну, так як віруси, «черв'яки» і «троянські коні» зазвичай впливають на EXE-файли. Крім того, може знадобитися відстеження доступу до конфіденційних документів і їх зміни.

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

Події аудиту

Як уже згадувалося раніше, Windows XP реєструє в журналах відбуваються події, які відслідковуються політикою аудиту. Користуючись інформацією журналів подій, можна отримати відомості про неполадки апаратного та програмного забезпечення, а також спостерігати за подіями безпеки Windows. Управляти і переглядати вміст журналів подій можна за допомогою утиліти Перегляд подій (Event Viewer).Windows XP записує події в три журнали:

· Системний журнал (system log) містить повідомлення про помилки, попередження і іншу інформацію, витікаючу від операційної системи і компонентів сторонніх виробників. Список подій, що реєструються в цьому журналі, зумовлений операційною системою і компонентами сторонніх виробників і не може бути змінений користувачем. Журнал знаходиться в файлі Sysevent.evt.

· Журнал безпеки (Security Log) містить інформацію про успішні і невдалі спроби виконання дій, що реєструються засобами аудиту. Події, які реєструються в цьому журналі, визначаються заданою вами стратегією аудиту. Журнал знаходиться в файлі Secevent.evt.

· Журнал додатків (Application Log) містить повідомлення про помилки, попередження і іншу інформацію, що видається різними додатками. Список подій, що реєструються в цьому журналі, визначається розробниками додатків. Журнал знаходиться в файлі Appevent.evt.

Всі журнали розміщені в папці %Systemroot%\System32\Config. Журнали подій можна переглядати з будь-якого комп'ютера локальної мережі, за наявності прав адміністратора на комп'ютері, де розташований журнал. Нас буде цікавити насамперед Журнал безпеки, тому саме в ньому реєструються події аудиту безпеки.

У таблиці 1 наведені основні події безпеки, які реєструються в журналі безпеки, якщо задана політика аудиту подій доступу до об'єктів.

Таблиця 1

Код події

Опис події

560

Надано доступ до існуючого об'єкту.

562

Закрито дескриптор об'єкту.

563

Виконана спроба відкрити об'єкт з метою його видалення.

564

Вилучений захищений об'єкт.

565

Наданий доступ до існуючого типу об'єкта.

567

Використано дозвіл, пов'язане з дескриптором. Дескриптор створюється з певними дозволами (наприклад дозволами на читання і запис). При використанні дескриптора для кожного з використаних дозволів може бути створена запис аудиту.

570

Клієнт спробував отримати доступ до об'єкта. Ця подія формується при кожній спробі виконання операції над об'єктом.

У таблиці 2 наведені основні події безпеки, які реєструються в журналі безпеки, якщо задана політика аудиту подій зміни політики безпеки.

Таблиця 2

Код події

Опис події

608

Надано право користувача.

609

Вилучено право користувача.

612

Змінена політика аудиту.

618

Змінена політика відновлення зашифрованих даних.

621

Облікового запису надано доступ до системи.

622

Для облікового запису заблокований доступ до системи.

623

Політика аудиту задана для кожного користувача.

Керування аудитом

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

У мережах з мінімальним вимогам до безпеки піддавайте аудиту:

· успішне використання ресурсів, тільки в тому випадку, якщо ця інформація вам необхідна для планування;

· успішне використання важливої ??і конфіденційної інформації.

· У мережах зі середніми вимогами до безпеки піддавайте аудиту:

· успішне використання важливих ресурсів;

· вдалі і невдалі спроби зміни стратегії безпеки і адміністративної політики;

· успішне використання важливої ??і конфіденційної інформації.

· У мережах з високими вимогами до безпеки піддавайте аудиту:* вдалі і невдалі спроби реєстрації користувачів;

· вдале і невдале використання будь-яких ресурсів;

· вдалі і невдалі спроби зміни стратегії безпеки і адміністративної політики.

Журнали збоїв часто виявляються більш інформативними, ніж журнали успішного виконання операцій, тому що збої зазвичай свідчать про помилки. Наприклад, успішний вхід користувача в систему зазвичай вважається нормальним розвитком подій. Якщо хтось безуспішно намагається кілька разів увійти в систему, це може бути ознакою використання чужих облікових даних. Події, що відбуваються на комп'ютері, реєструються в журналах подій.

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

3.3 Управління аудитом в ОС Linux

В ОС Linux, починаючи з версії ядра 2.6, існує можливість реєструвати такі події безпеки, як доступ до файлів/каталогів і виконання системних викликів. Реєстрацією таких подій займається служба (демон) auditd.

Процес організації аудиту подій безпеки ОС Linux складається з наступних дій:

1. Встановлення та налаштування auditd.

2. Налаштування правил аудиту.

3. Запуск auditd.

4. Аналіз отриманих даних і створення звітів аудиту.

Примітка. Для роботи auditd, необхідно щоб ядро ??було зібрано з опціями AUDIT і AUDITSYSCALL. Це можна перевірити за допомогою команди grep AUDIT/boot/config- `uname-r`.

Для того щоб використовувати аудит, в системі повинен бути встановлений пакет auditd. Демон auditd дозволяє системному адміністраторові налаштовувати процес аудиту, а саме:

· Задавати окремий файл для журналювання подій.

· Визначати ротацію журнального файлу подій.

· Задавати оповіщення в разі переповнення журналу подій.

· Визначати рівень деталізації подій.

· Налаштовувати правила аудиту.

В процесі своєї роботи демон auditd використовує конфігураційний файл /etc/audit/auditd.conf. Нижче наведено приклад вмісту даного конфігураційного файлу.

log_file = /var/log/audit/audit.log

log_format = RAW

priority_boost = 3

flush = incremental

freq = 20

num_logs = 4

dispatcher = /sbin/audispd

disp_qos = lossy

max_log_fi1e = 5

max_log_file_action = rotate

space_left = 75

space_left_action = syslog

action_mail_acct = root

admin_space_left = 50

admin_space_left_action = suspend

disk_full_action = suspend

disk_error_action = suspend

У директиві log_file вказується файл, куди будуть записуватися події. За замовчуванням, таким файлом є файл /var/log/audit/audit.log. У директиві log_format вказується формат даних, які необхідно реєструвати. У разі зазначення значення RAW в даній директиві, події записуються в файл в тому вигляді, в якому вони поступають із ядра. У директиві flush визначається частота запису подій. Якщо для даної директиви зазначено значення INCREMENTAL, то очищення журналу визначається на основі директиви freq, в якій вказується кількість записів, які приймає демон auditd, перш ніж записати їх в журнал.

Якщо у файлі auditd.conf вказана директива max_log_file_action зі значенням ROTATE, то журнальні файли будуть обертатися, досягнувши розміру, заданого в директиві max_log_file (у Мб). У директиві num_logs визначається кількість журнальних файлів, які повинні бути збережені, перш ніж буде виконана ротація даних. У директиві dispatcher задається програма, яка обробляє всі події аудиту. Вона може використовуватися для формування звітів або конвертації журналу в формат, що розуміється іншими програмами аналізу журнальних файлів. Директива disp_qos визначає параметри взаємодії даної програми з демоном auditd. Якщо в даній директиві вказано значення lossy, то події, послані даній програмі, видаляються, якщо буфер обміну даними між демоном auditd і даною програмою повністю заповнений (за замовчуванням розмір даного буфера складає 128Кб). Запис подій як і раніше здійснюється, якщо в директиві log_format не вказано значення nolog.

У директивах space_left і space_left_action задається, відповідно, межа вільного дискового простору розділу, на якому розташовуються дані аудиту, і дія, яку потрібно виконати в разі перевищення вказаної межі. Якщо вказано значення SYSLOG, то в журнал сервісу syslog буде записано відповідне попередження. У директивах disk_full_action і disk_error_action вказуються, відповідно, дія виконується в разі заповнення дискового простору на розділі з журнальні файли аудиту, і дія виконується у разі виявлення помилки запису даних в журнальний файл або його ротації. За замовчуванням, для даних директив задано значення SUSPEND, при якому наступні події записуватися в журнальний файл аудиту не будуть, а дії, що виконуються в даний момент над журнальним фалом, завершаться.

Для налаштування правил аудиту системних викликів і стеження за файлами і каталогами використовується утиліта auditctl. Якщо сервіс auditd налаштований на автоматичне включення, то правила аудиту системних викликів і стеження за об'єктами файлової системи можна задати у файлі /etc/ udit/audit.rules. Кожне правило аудиту повинно здаватися в окремому рядку. Форма записів правил і засобів має вигляд аргументів командного рядка для команди auditctl. Демон auditd зчитує правила зверху вниз і якщо буде виявлено два конфліктуючі правила, то перевага буде віддана першого знайденого правилом.

В якості параметра auditctl вказується список подій, в який додається дане правило. На даний момент підтримуються наступні списки:

Task - використовується для ведення подій, пов'язаних зі створенням процесів;

User - використовується для ведення подій, в яких вказуються параметри користувацького простору, такі як uid, pid та gid;

Exclude - використовується для заборони аудиту зазначених в даному списку подій;

Entry - використовується для реєстрації подій системних викликів;

Exit - використовується для реєстрації подій системних викликів.

В якості параметра також вказується одне з дій, що вживаються по відношенню до вказаних в списках подіям. Доступно всього дві дії: never і always. При вказівці дії never, події не записуються в журнал аудиту. Вказівка ??дії always має протилежний ефект.

В аргументах також задаються опції, які є фільтрами, за допомогою яких можна деталізувати події аудиту. Повний список опцій можна подивитися в керівництві man для команди auditdctl. В якості опції можна задавати унікальні ідентифікатори користувача або процесу, назва системного виклику і багато іншого. При цьому, можливо використовувати логічні вирази для формування комбінованих опцій.

Додавання правил аудиту відбувається за допомогою команди auditdctl з ключем-а. При цьому правила, додаються в кінець файлу auditd.conf. Для того, щоб додати правило в початок даного файлу, необхідно використовувати ключ-А.

Розглянемо приклади додавання правил аудиту:

auditdctl-a exit, always-s open-f uid = 502-f key = 502open

auditdctl-a entry, always-s chown

У першому випадку задається правило, яке фіксує всі події, пов'язані з системним викликом open, виконуваним від користувача з ідентифікатором 502. Записи, що задовольняють даній умові, позначаються в файлі audit.log міткою 502ореn. У другому випадку задається правило, яке фіксує всі системні виклики chown. Коли задане в правилі дію буде виконано, результат його виконання заноситься в журнал /var/log/audit/audit.log.

Крім стеження за системними викликами, система аудиту ОС Linux дозволяє стежити за доступом до файлів і каталогів. Для цього у файлі audit.rules необхідно створити правило має наступний синтаксис:

-W-k

У параметрі-w вказується повний шлях до файлу або каталогу, за яким необхідно стежити. Параметр-k використовується для помітки всіх подій, пов'язаних з доступом вказаного файлу. Це дозволяє швидко знаходити потрібну інформацію в журнальному файлі. У наступному прикладі наведено два правила, в яких здійснюється стеження за файлом /etc/passwd, а також стеження за доступом до команди iptables:

auditdctl-w/etc/passwd-k passwd

auditdctl-w/sbin/iptables-k iptables-p x

У ключах-k вказуються відповідні мітки подій. Ключ-р х у другому правилі зазначеного прикладу позначає, що необхідно розглядати тільки події, пов'язані з виконанням даного файлу.

Для перегляду активних правил аудиту необхідно виконати команду auditctl-l. Для визначення статусу системи аудиту необхідно виконати команду auditctl-s.

Зазвичай журнальний файл системи аудиту подій ОС Linux можна переглядати за допомогою будь-якого текстового редактора. Однак для виконання загального аналізу подій потрібно підсумовувати окремі записи в цьому файлі, що практично нереально виконати, використовуючи тільки можливості текстового редактора. Для виконання аналізу і відображення статистики аудиту подій до складу пакету audit входять утиліти ausearch і aureport. Утиліта ausearch може виконувати пошук записів аудиту на основі різних критеріїв пошуку, таких як ім'я файлу, ідентифікатор користувача, назву системного виклику та інше. Утиліта aureport використовується для формування звітів на основі журнального файлу аудиту audit.log.

Висновки

Застосування політик аудиту істотно підвищує безпеку і цілісність системи. Практично кожна комп'ютерна система в мережі повинна бути налаштована з веденням журналів безпеки.

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

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

Список литератури

1. Такет Д., Барнет С. Специальное издание. Использование LINUX. Пер. с англ. - 4-е изд. - К.:, Н.:, СПб.: Издательский дом «Вильямс», 2009.

2. Открытый ресурс: GNU, Linux, Android [Електронний ресурс] - Режим доступу: http://desktoplinux.ru/.

3. Н. А. Олифер, В. Г. Олифер, Центр Информационных Технологий.

4. Руководство пользователя Process Monitor [Електронний ресурс] - http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx.

5. Системное программное обеспечение / А.В. Гордеев А.Ю. Молчанов. - Спб.: Питер. 2010 - 736

Размещено на Allbest.ru


Подобные документы

  • Вивчення теоретичних відомостей про Linux Mint, дистрибутива операційної системи Linux. Дослідження технології Wi-Fi. Способи об'єднання точок доступу в єдину систему. Особливості організації і управління радіоканалами. Зламування Wi-Fi точки доступу.

    курсовая работа [1,5 M], добавлен 17.05.2013

  • Захист файлів від несанкціонованого доступу в ОС FreeBSD. Атрибути та права доступу до файлу. Загальні принципи захисту для всіх існуючих варіантів системи. Значення прав доступу для різних типів файлів. Паролі, їх роль у забезпеченні безпеки системи.

    контрольная работа [33,0 K], добавлен 29.06.2010

  • Основні команди операційної системи Linux. Інтерфейс та робота в режимі командного рядка. Системи управління програмою на основі меню. Посилання в текстовому режимі. Список файлів і каталогів, зупинених і фонових завдань. Права доступу до файлів.

    лабораторная работа [196,8 K], добавлен 02.06.2011

  • Функції інформаційної системи. Аналіз функцій системи управління базами даних: управління транзакціями і паралельним доступом, підтримка цілісності даних. Аналіз системи MySQL. Елементи персонального комп’ютера: монітор, клавіатура, материнська плата.

    дипломная работа [1,2 M], добавлен 15.05.2012

  • Вміння та навички роботи з об’єктами файлової системи. Перевірка вміння учнів працювати з об’єктами файлової системи. Шкідливі комп’ютерні програми за рівнем небезпечності дій. Зменшення об'єму інформації – поняття про архівування та стиснення даних.

    конспект урока [13,7 K], добавлен 03.01.2010

  • Відомості про дискреційну політику безпеки. Модель Харрісона-Руззо-Ульмана та Take-Grant. Базова система рольового розмежування прав доступу. Права доступу до файлів в операційній системі типу Windows. Індивідуально-групове розмежування прав доступу.

    курсовая работа [53,8 K], добавлен 08.09.2012

  • Огляд Windows 95/98: загальні відомості, аналіз файлової системи. Розробка програми, що виконує всі основні функції файлового менеджера та може використовуватись як повноцінний програмний продукт даного типу. Установка та умови застосування програми.

    курсовая работа [360,6 K], добавлен 17.10.2013

  • Технології організації безпечного доступу на об’єкт. Принцип роботи мережевої системи контролю доступу. Технологія сканування відбитків пальців. Опис базових параметрів біометричного обладнання. Елементи ідентифікації в сучасних системах доступу.

    дипломная работа [4,9 M], добавлен 27.01.2012

  • Архітектура управління доступом до інформаційних ресурсів у сучасній розподіленій ІТ-інфраструктурі. Базові механізми захисту та управління, які використовуються при розмежуванні доступу в мережі. Визначення та використання менеджменту доступу.

    статья [191,6 K], добавлен 31.08.2017

  • Структура завантажувального запису, службової області FAT, елемента каталогу. Код програми файлового менеджеру. Алгоритм пошуку дисків й іменування дисків, доступу к об'єктам файлової системи, визначення зайнятого місця на розділі, зрівняння директорій.

    дипломная работа [1,5 M], добавлен 20.11.2010

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.