Технологія виявлення кіберінцидентів (кібератак)

1.

ВІЙСЬКОВИЙ ІНСТИТУТ ТЕЛЕКОМУНІКАЦІЙ ТА ІНФОРМАТИЗАЦІЇ
імені ГЕРОЇВ КРУТ
viti.edu.ua
«ТЕХНОЛОГІЇ ПОБУДОВИ ЕЛЕМЕНТІВ
ТА СИСТЕМ КІБЕРЗАХИСТУ»
Групове заняття
Тема № 3: Технологія виявлення кіберінцидентів (кібератак).
Заняття № 5: «Інтерпретація подій в середовищі сучасних операційних
систем.»
Київ 2022

2.

Системний опис кіберінцидентів
Навчальні питання:
Вступна частина.
1.
Windows Event Log Analysis.
2.
Kayditd (auditd).
Заключна частина
2

3.

Вступна частина
3
Моніторинг журналу подій Windows
Більшість основних порушень безпеки даних відбувається через внутрішніх працівників, проте
організації не виконують моніторинг діяльності внутрішніх мереж достатньо ефективно.
Моніторинг діяльності внутрішніх мереж став основною вимогою для організацій — великих
чи малих. Щоб захистити мережу від порушень і загроз, організаціям необхідно вжити
активних заходів для безпеки своєї мережі та даних. Моніторинг даних журналу подій є
найбільш точним способом виявлення аномалій мережі, спроб порушення даних та відстеження
втручань у мережу.
Пом'якшення внутрішніх загроз шляхом моніторингу даних журналу подій
Більшість організацій мають мережеве середовище, що включає сервери і робочі станції
Windows. Операційні системи Microsoft Windows генерують різноманітні журнали подій, і такі
журнали, якщо вони відстежуються, можуть допомогти адміністраторам мережі захистити
мережу від внутрішніх загроз і провести експертизу журналу. Журнали подій містять критично
важливу інформацію, як-от невдала реєстрація, невдалий вхід, невдалі спроби доступу до
захищених файлів, втручання в журнал безпеки тощо. Це допомагає захистити вашу
організацію від загроз мережі.
Журнали подій генеруються у форматах EVT і EVTX. Версії серверів і робочих станцій
Windows NT, XP, 2000 і 2003 підтримують формат журналу EVT, а версії Windows Vista і Server
2008 використовують формат журналу EVTX. Моніторинг цих подій журналу Windows (у
форматах EVT та EVTX) у різних версіях Windows стає проблемою для адміністраторів мережі,
і ручний моніторинг даних журналу подій є громіздким і трудомістким.

4.

1. Windows Event Log Analysis.
4
EventLog Analyzer автоматизує моніторинг журналу подій
EventLog Analyzer — це програмне забезпечення моніторингу журналу подій, що
забезпечує повний моніторинг журналів подій. Аналізатор збирає, аналізує, генерує звіти
та архівує дані журналу подій, створені серверами і робочими станціями вашої
корпоративної мережі Windows. Це програмне забезпечення моніторингу журналу подій
підтримує усі сумісні формати журналів подій Windows (EVT і EVTX), створені різними
операційними системами Windows, як-от:
•Windows 2003 Server
•Windows 2008
•Windows NT
•Windows 2000
•Windows XP
•Windows Vista
•Windows 7
•Усі інші операційні системи Windows
Дані журналу подій збираються за допомогою технології «без агента» з усіх ваших
пристроїв Windows. Дані журналу подій контролюються та аналізуються централізовано
— у головному комп'ютері EventLog Analyzer. Це програмне забезпечення моніторингу
журналу Windows здатне відстежувати журнали подій на всіх серверах і робочих станціях
Windows у вашій мережі і попереджає вас у режимі реального часу за допомогою SMS
або електронної пошти, коли в мережі трапляються аномалії.

5.

1. Windows Event Log Analysis.
5
EventLog Analyzer - Переваги інструменту моніторингу журналу подій:
•Збір журналів без використання агента — це можливість збирати, впорядковувати,
контролювати, аналізувати, генерувати звіти та архівувати файли журналу подій у форматі
журналів Windows EVT та EVTX
•Аналізує дані журналу подій і генерує звіти для аудиту відповідності нормативним
документам
•Центральне сховище даних журналу подій Windows
•Виявлення подій безпеки мережі, як-от невдала реєстрація, доступ до об'єктів, очищення
журналів аудиту тощо.
•Засіб кореляції подій, який виявляє шаблони атак з усіх пристроїв Windows та інших
пристроїв мережі та сповіщає вас у режимі реального часу.
•Вбудований аналіз загроз для виявлення та запобігання втручань в мережу, а також
обробник даних про загрози STIX/TAXII для сповіщення про зловмисні IP-адреси, URLадреси та домени
•Моніторинг рішень аналізу зовнішніх загроз
•Підтримується усіма версіями Windows: Windows 2003 і 2008 Server, Windows NT,
Windows 2000, Windows XP, Windows 7 і Windows Vista
•Отримуйте сповіщення в режимі реального часу, коли мережеві аномалії трапляються в
мережі Windows.
•Прості та розширені параметри пошуку необробленого журналу у даних журналів подій
Windows

6.

1. Windows Event Log Analysis.
Функції моніторингу журналів подій EventLog Analyzer
• Збір і моніторинг журналів подій
Моніторинг журналу подій для відповідності нормативним
документам
Експертиза журналу та пошук необроблених журналів у даних
журналу подій
Створення звітів з серверів і робочих станцій Windows
Налаштуйте сповіщення в реальному часі на серверах і робочих
станціях Windows
Інші функції
6

7.

1. Windows Event Log Analysis.
7
Збір і моніторинг журналів подій
Для збору журналів подій це програмне забезпечення моніторингу журналів подій
не вимагає встановлення окремого агента на кожному комп'ютері, з якого
збираються журнали. EventLog Analyzer застосовує технологію без використання
агента для збору даних журналів подій Windows.
Зібрані журнали подій доступні на приладній дошці, що містить підрахунки,
засновані на помилках, попереджувальних повідомленнях та інших певних подіях.
Використовуючи ці підрахунки, можна організовано переглядати дані журналу
Windows в томах і легко використовувати його для детальної та швидкої
діагностики проблем, які виникли в операційних системах Windows.

8.

1. Windows Event Log Analysis..
8
Моніторинг журналу подій для відповідності нормативним документам
Нормативна відповідність стала найвищим пріоритетом для ІТ-адміністраторів. Надзвичайно
важливо, щоб організації дотримувалися рекомендацій з аудиту відповідності нормативним
вимогам, оскільки невідповідність нормативним стандартам може призвести до жорстких штрафів.
EventLog Analyzer дає змогу ІТ-адміністраторам виконувати нормативні вимоги відповідності
шляхом моніторингу та аналізу журналів подій з серверів і робочих станцій Windows в режимі
реального часу.
За допомогою EventLog Analyzer можна генерувати попередньо визначені або готові звіти про
відповідність для журналів подій, щоб виконати вимоги аудиту, як-от HIPAA, GLBA, PCI DSS,
SOX, FISMA, ISO ISO 27001/2 тощо. Це програмне забезпечення для звітування про відповідність
журналу подій також надає функцію додавання вартості, яка дає змогу створювати власний звіт для
нової відповідності, щоб допомогти виконувати нові регуляторні акти у майбутньому.

9.

1. Windows Event Log Analysis.
9
Експертиза журналу та пошук необроблених журналів у даних журналу подій
EventLog Analyzer робить експертизу журналу подій дуже простою, дозволяючи вам
використовувати його потужну пошукову систему для пошуку як в необроблених, так і в
форматованих журналах подій, і миттєво генерувати звіти експертизи на основі результатів пошуку.
Адміністратори мережі тепер можуть виконувати пошук необроблених журналів подій і точно
визначати запис журналу, який спричинив певну активність системи безпеки, знайти точний час,
коли відбулася відповідна подія безпеки, хто ініціював діяльність, а також місце початку діяльності.
Ця функція пошуку програми моніторингу журналу подій допоможе вам швидко відстежити
зловмисника в мережі і є дуже корисною для здійснення правоохоронними органами судової
експертизи. Зробіть свій пошук більш точним за допомогою надійної функції пошуку журналу подій
EventLog Analyzer, яка пропонує простий пошук, заснований на ідентифікаторах конкретних подій,
що відносяться до політики компанії або певного типу події: помилки, попередження, відмови або
інші категорії. Заархівовані журнали Windows можуть бути імпортовані, а збір відомостей про
інциденти безпеки може здійснюватися шляхом пошуку в необроблених журналах подій.

10.

1. Windows Event Log Analysis.
10
Створення звітів з серверів і робочих станцій Windows
Аналізатор EventLog включає кілька попередньо визначених або готових звітів на основі
журналів подій, отриманих від серверів і робочих станцій Windows. У цих звітах
відображаються такі відомості, як невдала реєстрація, помилки входу через неправильні
паролі, блокування облікового запису, невдалі спроби доступу до захищених файлів,
порушення безпеки журналу, тенденції подій тощо. За допомогою цих звітів адміністратори
можуть легко визначати порушників і несправні комп'ютери, тим самим зменшуючи цикл
усунення несправностей.
EventLog Analyzer дає змогу використовувати різні критерії для створення користувацьких
звітів на основі даних журналу подій Windows, згенерованих вашим комп'ютером. Критеріями
є: повідомлення журналу, користувач, ідентифікатор події та тип/серйозність події.

11.

1. Windows Event Log Analysis.
11
Налаштуйте сповіщення в реальному часі на серверах і робочих станціях Windows
EventLog Analyzer генерує сповіщення в реальному часі стосовно журналів подій,
завдяки чому адміністратори можуть дізнаватися, коли генерується подія, що
відповідає певному критерію. Сповіщення допомагає адміністраторам контролювати
критичні сервери та процеси в мережі Windows в режимі реального часу.
Можна визначати, які сервери чи робочі станції Windows або групу пристроїв Windows
потрібно відстежити. Також можна викликати попередження для подій, створених із
використанням певного типу журналу, ідентифікатора події, повідомлення журналу або
важливості. Сповіщення про події надсилаються в режимі реального часу за допомогою
електронної пошти, SMS-повідомлень і спеціальних програм

12.

1. Windows Event Log Analysis.
12
Інші функції
Керування сервером системного журналу
EventLog Analyzer збирає та аналізує дані журналу з серверів Linux/Unix для надання оперативних звітів,
які допомагають виявляти підозрілу поведінку, аномальну діяльність системного журналу тощо.
Аналіз журналів програм
Аналізуйте журнали програм з веб-серверів IIS і Apache, баз даних Oracle і MS SQL, програм DHCP
Windows і Linux тощо. Пом'якшуйте атаки на безпеку програм за допомогою повідомлень та сповіщень
у реальному часі.
Моніторинг журналів Active Directory
Виконуйте моніторинг всіх типів даних журналу з інфраструктури Active Directory. Відстежуйте
інциденти в реальному часі та створюйте власні звіти, щоб контролювати певні події Active Directory,
які вас цікавлять.
Моніторинг привілейованих користувачів
Виконуйте моніторинг та відстежуйте дії привілейованих користувачів з метою задоволення вимог
PUMA. Отримуйте готові звіти про критично важливу діяльність, наприклад, про помилки входу,
причини помилки входу і багато іншого.
Керування сервером друку
Виконуйте моніторинг і аудит сервера друку за допомогою докладних звітів про друковані документи,
спроби роздрукувати документи без належного дозволу, невдалі завдання друку та їх причини тощо
Керування IT-відповідністю
Виконуйте жорсткі вимоги регуляторних наказів, як-от PCI DSS, FISMA, HIPAA та багатьох інших, за
допомогою попередньо визначених звітів та сповіщень. Налаштуйте існуючі звіти або створюйте нові
звіти, щоб задовольнити внутрішні потреби безпеки.

13.

Питання 2: Kayditd (auditd).
Налаштування auditd
інформаційної безпеки
для
виявлення
та
розслідування
13
інцидентів
Однією з важливих складових інформаційної безпеки інфраструктури компанії є
SIEM – система управління подіями та інформацією безпеки. Таку систему можна
умовно поділити на дві основні частини - підсистему збору подій та підсистему
аналізу отриманих подій. Правильне налаштування першої допоможе виявити
вторгнення на ранніх етапах проникнення, полегшить написання подій тривоги
(алертів), а якщо вас таки зламали, то дозволить розібратися, як і чому це сталося,
які дії виконували зловмисники. Основним інструментом для збору системних
подій у лінукс-системах є auditd. На основі цього інструменту створені й інші,
наприклад, auditbeat, go-audit, які доповнюють основний функціонал auditd.

14.

Питання 2: Kayditd (auditd).
14
Загальний опис auditd
auditd (скорочення від Linux Audit Daemon) — нативний інструмент, призначений для
моніторингу подій операційної системи та запису їх у журнали подій, що розробляється
та підтримується компанією RedHat. Був створений для тісної взаємодії з ядром
операційної системи – під час своєї роботи спостерігає за системними викликами та
може записувати події – читання, запис, виконання, зміна прав – пов'язані з файлами
ОС. Таким чином, за його допомогою можна відстежувати практично будь-які події, що
відбуваються в операційній системі.
Плюси auditd:
- працює на низькому рівні моніторингу – відстежує системні виклики та дії з файлами;
- має непоганий набір утиліт у комплекті для зручності роботи;
- постійно розвивається та оновлюється;
- Безкоштовний і легко встановлюється.
Мінуси auditd:
- більшість подій, що виникають при атаках характерних для конкретної програми,
практично неможливо відстежувати, оскільки на рівні системних викликів і роботі з
файлами важко відрізнити злом від нормальної роботи програми. Такі події краще
відстежувати лише на рівні самих додатків;
- auditd може уповільнювати роботу ОС. Це з тим, що підсистемі аудиту необхідно
проводити аналіз системних викликів;
- не дуже гнучкий у налаштуванні правил;
- на даний момент це не найкращий інструмент для роботи з контейнерами.

15.

Питання 2: Kayditd (auditd).
15
Файли конфігурації та синтаксис
Розглянемо основні приклади налаштувань та параметрів, які будуть
використовуватись далі. Більш повний посібник з auditd ви можете
знайти тут . Основну інформацію можна знайти в мануалах до auditd та його
інструментів.
Файли конфігурації зберігаються у /etc/audit/. Правила бажано зберігати в
/etc/audit/rules.d/*.rules, за промовчанням доступ до цієї директорії лише
root'а. Зверніть увагу, що файл з правилами в цій директорії повинен мати назву
*.rules, інакше auditd не прочитає його без явної вказівки. Якщо ви вирішили
зберігати правила в іншому місці, то власник файлу має бути root. Крім цього
рекомендую виставити групу файлу root і права 600, щоб ніхто крім root'а було
працювати з файлом конфігурації auditd, т.к. знаючи, що логується, атакуючий може
уникнути виявлення. Те саме стосується файлів з правилами для інших
інструментів.
Правила
для
логування
можна
додавати
такими
способами:
- записати його у файл(и) /etc/audit/rules.d/<ім'я файлу>.rules та перезапустити сервіс;
- записати у файл довільним шляхом і вказати його явно: auditctl -R <путь к файлу>;
- Додати правило утилітою auditctl [-A,-a] <правило>.

16.

Питання 2: Kayditd (auditd).
16
Синтаксис
Детальний опис синтаксису російською мовою можна переглянути тут .
-D - Видалити всі правила. Зазвичай використовується на початку файлу, щоб
уникнути несподіванок;
-a [list,action],[action,list] - додає правило до кінця списку правил. Списки та дії
розглянемо далі.
Основні варіанти списків:
exit – Додати правило до списку, що відповідає за точки виходу із системних
викликів. Цей список застосовується, коли необхідно створити подію для аудиту,
прив'язану до точок виходу із системних викликів.
exclude - Додати правило до списку, який відповідає за фільтрацію подій певного
типу. Цей список використовується для відфільтрування непотрібних
подій. Наприклад, якщо ви не бажаєте бачити avc повідомлення, ви повинні
використовувати цей список. Тип повідомлення задається в полі msgtype .
Варіанти дій:
always – встановити контекст аудиту. Завжди заповнювати його під час входу до
системного виклику і завжди генерувати запис під час виходу із системного виклику;
never - аудит не генеруватиме жодних записів. Це можна використовувати для
придушення генерації подій. Зазвичай необхідно придушувати генерацію зверху
списку, а чи не внизу, т.к. подія ініціюється першому збіглому правилі.

17.

Питання 2: Kayditd (auditd).
17
-A list, action - додати правило початку списку. Наприклад, для зручності читання
правило знаходиться нижче, ніж має бути за логікою налаштувань, тоді можна
використовувати цей параметр.
-F [n = v | n! = V | n<v | n>v | n<=v | n> = v | n&v | n&=v]- Задати поле порівняння для
правила. Атрибути поля такі: об'єкт, операція, значення. Ви можете поставити до 64
полів порівняння в одній команді. Кожне нове поле повинне починатися з -F. Аудит
генеруватиме запис, якщо збігся з усіма полями порівняння. Допустимо
використання одного з наступних 8 операторів: одно, не дорівнює, менше, більше,
менше або одно, більше або одно, бітова маска (n&v) та бітова перевірка
(n&=v). Бітова перевірка виконує операцію and над значеннями і перевіряє, чи рівні
вони. Бітова маска просто виконує операцію and. Поля, що оперують з
ідентифікатором користувача, також можуть працювати з ім'ям користувача —
програма автоматично отримає ідентифікатор користувача з його імені. Те саме
можна сказати і про ім'я групи.

18.

Питання 2: Kayditd (auditd).
18
Поля порівняння та їх опис:
•a0, a1, a2, a3 - перші 4 аргументи системного виклику відповідно;
•arch - оскільки система орієнтується на номери (не назви) системних дзвінків, а для
багатьох системних дзвінків номери відрізняються для 32 і 64 розрядних систем,
необхідно вказувати для якої архітектури ми пишемо правило;
•auid – ID користувача, з яким він увійшов до системи. Системні послуги, як правило,
мають auid=-1 (або 4294967295);
•dir – директорія, за якою необхідно спостерігати. Будуть залоговані та всі події пов'язані
з файлами та піддиректоріями у зазначеній директорії рекурсивно;
•euid – дійсний ідентифікатор користувача;
•exe - повний шлях до виконуваного файлу. Може використовуватись тільки з exit;
•exit - значення, яке повертається системним викликом при виході;
•key – встановлення поля для фільтра. Додає поле із заданим ім'ям у подію, що полегшує
пошук подій у журналах;
msgtype – тип події. Весь список подій можна подивитися тут ;
path - повний шлях до файлу, за яким необхідно стежити, може використовуватись тільки
з exit;
perm - те, що і параметр -p, буде розглянутий нижче;
success - якщо значення, що повертається системним викликом, більше чи дорівнює 0,
цей об'єкт дорівнюватиме «true/yes», інакше «false/no». При створенні правила
використовуйте 1 замість true/yes і 0 замість false/no;
18
uid – ідентифікатор користувача;

19.

Питання 2: Kayditd (auditd).
19
Замість числових ідентифікаторів користувачів можна вказувати імена (wwwdata, mail, irc), так що вам не доведеться враховувати їх числові відмінності
на різних серверах.
-p - [r|w|x|a] - визначає дозвіл доступу файлу за яким потрібно стежити:
читання, запис, виконання або зміна прав доступу відповідно;
-w <path> - встановлює спостереження за директорією (рекурсивно) чи
файлом;
-W <path> - виключає спостереження за зазначеною директорією чи
файлом.
Варто згадати про вбудовані інструменти аналізу отриманих подій: ausearch,
aureport. З їхньою допомогою зручно тестувати правила "на місці". Багато
цікавих прикладів правил можна подивитися тут .
19

20.

Питання 2: Kayditd (auditd).
20
При написанні правил auditd необхідно враховувати наступне:
1.Для кожної події відпрацьовує лише те відповідне правило, яке зустрілося першим. Тому
спочатку пишуться фільтри і лише потім правила. Те саме стосується і вибору між
кількома правилами - вище розміщувати варто те правило, яке важливіше враховувати.
2.Писати правила краще від часткового до загального. Допустимо, ви хочете журналувати
дії в директорії /etc/. Щоб потім у логах не шукати прикладними утилітами (grep, sed або
засобами SIEM) всі події, пов'язані, наприклад, з ssh, sudoers, passwd і т.д., спочатку
вказуєте правила для моніторингу конкретних директорій/файлів /etc/ і тільки після цього
розміщуєте правило самої директорії /etc/.
3.Auditd має правила і іноді виникають ситуації, коли вони спрацьовують і наші правила не
враховуються. Тому кожне правило краще попередньо тестувати окремо.
4.Якщо ви хочете написати правила з метою виявлення конкретної нагоди (атаки, ситуації),
то краще визначити загальну ланку і написати правило для неї. Так, наприклад, для
виявлення запуску інтерактивних шеллів можна використовувати звернення /dev/tty,
/dev/pts/. Чим краще ви розумієте, як працює ваша операційна система, тим
краще. Використовуючи такий підхід, зловмиснику важче уникнути виявлення.
5.Для однієї й тієї ж дії з погляду користувача може існувати кілька системних
викликів. Так для відкриття файлу можна використовувати: open, openat, creat,
open_by_handle_at. Про це варто пам'ятати при створенні правил на базі вибіркових
системних викликів.
6.Якщо ви написали правило і бачите безліч помилкових спрацьовувань, можливо, замість
20
написання безлічі фільтрів, слід вибрати інший підхід до визначення події логування.

21.

Зміст завдання самостійної роботи
21
Самостійна робота
1. Порівняльний аналіз Засоби аналізу подій в
сучасних операційних системах.

22.

ВІЙСЬКОВИЙ ІНСТИТУТ ТЕЛЕКОМУНІКАЦІЙ ТА ІНФОРМАТИЗАЦІЇ
імені ГЕРОЇВ КРУТ
viti.edu.ua
ДЯКУЮ ЗА УВАГУ!