У сьогоднішньому швидко змінюваному середовищі загроз швидке і точне виявлення є ключовим для захисту організаційних активів. Security Onion — потужна платформа з відкритим кодом, що об’єднує інструменти для моніторингу, пошуку загроз та виявлення вторгнень, щоб підтримати аналітиків. Ця публікація зосереджена на тому, як використовувати Security Onion для виконання практичних завдань, таких як аналіз сповіщень, виявлення шкідливої діяльності та розслідування інцидентів, що допомагає ефективно керувати та пріоритетизувати загрози.
Якщо ви новачок у Security Onion і потребуєте допомоги з установкою або налаштуванням, не хвилюйтеся! Я вас підтримую. Перегляньте мою попередню публікацію, “Покрокова установка, налаштування та керування Security Onion,” де я крок за кроком роз’яснюю процес. З цим фундаментом ви будете готові максимально використати цю статтю.
Приступимо!
Архітектура
У моїй лабораторії є Metasploitable і Kali для імітації реальних атак і спостереження, як класифікуються різні сповіщення.
У цій лабораторії ми використовуємо варіант розміщення всередині периметра. Ця конфігурація розміщує сенсор Security Onion за межами фаєрвола для моніторингу внутрішнього трафіку мережі. Вона фокусується на виявленні внутрішніх загроз і руху всередині мережі, одночасно зменшуючи шум від непотрібного зовнішнього трафіку.
Переваги варіанту розміщення всередині периметра:
- Покращене виявлення внутрішніх загроз через фокус на внутрішньому трафіку.
- Зменшення шуму від зовнішнього трафіку для чіткішого аналізу.
- Ідеально для лабораторій для аналізу тестових сценаріїв без втручання зовнішніх факторів.
- Економічний варіант для малих та середніх бізнесів (SMB), що надає критичну видимість без великих вимог до ресурсів.
- Спрощена установка, без ризику для зовнішніх атак.
Ця конфігурація ідеально підходить для лабораторій та малих і середніх бізнесів, поєднуючи простоту та ефективність для моніторингу внутрішньої мережі.
Атака
У цьому розділі атаки я буду симулювати мережеве сканування та атаку брутфорсом на MySQL, щоб спостерігати, як Security Onion захоплює сповіщення. Спочатку я виконав мережеве сканування за допомогою Nmap, щоб виявити відкриті порти та сервіси, що працюють на вразливій віртуальній машині (Metasploitable). Це сканування показало важливу інформацію, таку як відкриті порти та сервіси, які потенційно можуть бути використані зловмисниками.
Це інтенсивне сканування всіх TCP портів, яке призначене для генерування сповіщень у нашому Security Onion. Однак ви малоймовірно побачите таке сканування з Інтернету, оскільки воно створює надмірний шум і легко виявляється.
На основі результатів мережевого сканування, я продовжив виконувати атаку брутфорсом на MySQL на відкритий MySQL-сервіс. Використовуючи відкритий порт, виявлений під час сканування Nmap, я спробував підібрати облікові дані MySQL за допомогою Medusa, імітуючи дії зловмисника в реальній ситуації.
Kali Linux має кілька списків слів за замовчуванням, які ми можемо використовувати для атаки брутфорсом, і одним з найбільш поширених є rockyou.txt
, який знаходиться в /usr/share/wordlists/
. Однак він за замовчуванням стислий, тому вам потрібно буде розпакувати його перед використанням.
Розпакування rockyou.txt
Фрагмент атаки брутфорсом за допомогою Medusa. Ви також можете використовувати hydra для тієї ж атаки.
Огляд інтерфейсу Security Onion
Ми почнемо з аналізу сповіщень в консолі Security Onion, також відомій як інтерфейс SOC. Наше завдання — систематично оцінити ці сповіщення, відсіюючи помилкові спрацьовування, щоб зменшити шум, одночасно визначаючи ті, що потребують подальшого розслідування.
Для сповіщень високого пріоритету ми передаватимемо їх у інструмент керування випадками (Case Management tool), що дозволяє належно документувати та спрощувати процес реагування на інциденти. З цього моменту ми зануримося у зібрані дані, щоб зрозуміти повний обсяг кожного сповіщення та зафіксувати наші висновки, демонструючи, як інструменти Security Onion інтегруються для покращення процесів виявлення та аналізу.
Щоб створити сповіщення, які можна використовувати для практики, ми відтворимо мережевий трафік на нашій тестовій інстанції Security Onion за допомогою команди so-test
. Це симулює мережеву активність і створює можливості для вдосконалення навичок триажу та аналізу. Моя віртуальна машина для аналізу підключена до сервера Security Onion через захищену SSH-сесію (ssh [username]@[host_ip_address]
), що забезпечує надійну комунікацію протягом всього процесу.
Нарешті, не всі мережеві сканування є за замовчуванням шкідливими або потребують негайної уваги, особливо якщо вони надходять з зовнішніх джерел, які намагаються атакувати систему, що виставлена в Інтернет. Однак сканування всередині мережі є більш тривожними. Якщо джерело не є машиною для керування вразливостями або хтось не виконує усунення несправностей, це слід повідомити у відповідний канал вашої організації для подальшого розслідування.
Фрагмент сповіщень, створених Security Onion з наших атак брутфорсом і сканувань портів за допомогою Nmap
Фрагмент сповіщення, яке було згенеровано після виконання команди so-test
Інтерфейс сповіщень є центральним хабом для керування сповіщеннями, створеними платформою Security Onion. Він агрегує всі сповіщення, полегшуючи аналітикам їх моніторинг та оцінку. Мета — ідентифікувати хибні спрацьовування, які можна відхилити, і пріоритезувати підозрілі або критичні сповіщення, що потребують подальшого розслідування. Цей постійний процес оцінки критично важливий для підтримки сильної безпеки та швидкої реакції на потенційні загрози.
Перед тим, як розпочати триаж, варто звернути увагу на функцію в верхній частині інтерфейсу сповіщень — меню опцій. Це випадаюче меню надає різні варіанти перегляду та фільтрації, зокрема можливість переглядати сповіщення "Підтверджені" (Acknowledged). Це сповіщення, які вже були переглянуті та відхилені, або вами, або іншим аналітиком. Вибір цієї опції покаже лише оцінені сповіщення, щоб ви могли зосередитись на не вирішених або нових сповіщеннях.
Інший важливий варіант у випадаючому меню — для перегляду "Ескалованих" сповіщень. Це сповіщення, які аналітик вважає достатньо важливими для подальшого розслідування. Такі сповіщення були переміщені в платформу керування випадками, де їх можна детально розглянути та задокументувати як частину поточного розслідування. Клацання цього перемикача дозволяє переглянути відфільтрований список усіх ескалованих сповіщень, що дозволяє зосередитись на справах високого пріоритету, які активно розслідуються.
Триаж
Тепер, коли ми створили сповіщення, перший крок — це виконати триаж. Триаж — це процес швидкої оцінки та пріоритизації сповіщень або інцидентів безпеки, щоб визначити їх серйозність та відповідну реакцію. Цей процес допомагає аналітикам зосередитись на найбільш критичних питаннях, гарантуючи ефективне використання ресурсів для вирішення потенційних загроз, водночас мінімізуючи хибні спрацьовування та низько пріоритетні відволікання.
Іноді окреме сповіщення може не здаватися важливим, але коли воно поєднується з іншими сповіщеннями, воно може стати помітним. Наприклад, просте сканування портів може не бути великим занепокоєнням.
Однак, якщо сканування портів супроводжується атакою брутфорсом MySQL, як показано в розділі атаки, і обидва ці події походять з однієї IP-адреси, це чітко вказує на те, що хтось у нашій мережі виконує розвідку та намагається закріпитися.
Якщо ми хочемо зосередитись виключно на розслідуванні сповіщень високого пріоритету, як показано в наведеному фрагменті, є два способи досягти цього. Перший метод — це клацнути на заголовок стовпця з назвою “event.severity_label” в інтерфейсі сповіщень. Це дозволить сортувати сповіщення за рівнями їх серйозності. Вибір опції “High Severity Only” відфільтрує вигляд, показавши лише найкритичніші сповіщення на початку списку, що дозволяє пріоритизувати їх для негайного розслідування.
Інший варіант зосередитись на сповіщеннях високого пріоритету — це використати іконку “high” (або іконку фільтра), розташовану поруч з деталями сповіщення. Клацнувши на цю іконку лівою кнопкою миші, з’явиться вікно, що надасть різні опції фільтрації.
У цьому вікні ви можете натиснути кнопку “Include”, щоб додати вибране сповіщення або його атрибути до рядка запиту вгорі інтерфейсу.
Цей метод гарантує, що найважливіші та потенційно небезпечні сповіщення отримають своєчасну увагу, спрощуючи робочий процес і підвищуючи ефективність реагування.
Перейдемо до сповіщень, згенерованих під час атаки брутфорсом. Якщо ми хочемо розслідувати та зібрати більше деталей про сповіщення, ми можемо клацнути на ім’я сповіщення. Потім, натиснувши на опцію «Drilldown», ми зможемо перемкнутися на детальну інформацію, пов’язану з цим конкретним сповіщенням, щоб побачити, скільки разів воно спрацювало.
Якщо ми хочемо переглянути деталі, можемо натискати на стрілку (>) для розгортання сповіщення та доступу до всієї інформації, яку Security Onion зберігає у своїй базі даних стосовно цього конкретного сповіщення.
Прокручуючи та розслідуючи сповіщення, ви знайдете цікаву інформацію, таку як вихідні та кінцеві IP-адреси, вихідні та кінцеві порти, сигнатуру або правило, яке було активовано, а також тип трафіку, що спричинив сповіщення.
Після розслідування, якщо ви визначите, що сповіщення потребує подальшої уваги, поверніться та натисніть на синій трикутник для ескалації сповіщення. Тоді Security Onion відкриє справу для подальшого аналізу та дій. У цьому випадку я повернуся до основної консолі та підтверджу сповіщення. Це забезпечить, що сповіщення буде позначено як переглянуте, що завадить майбутнім аналітикам витрачати час на безцільне розслідування того самого сповіщення. Підтвердження сповіщень — важливий крок у підтримці ефективного робочого процесу, оскільки це допомагає спростити процес розслідування для всіх, хто використовує платформу.
Крім того, якщо ви стикаєтесь з повторюваним сповіщенням у вашій мережі, яке було підтверджено як не-шкідливе, найкращою практикою є налаштування відповідного правила виявлення. Налаштування правила включає коригування його параметрів або виключень, щоб запобігти спрацьовуванню таких хибних сповіщень у майбутньому. Такий проактивний підхід не лише зменшує шум в інтерфейсі сповіщень, але й дозволяє аналітикам зосередитись на справжніх загрозах, що потребують уваги.
Створення справи
Надалі ми зосереджуємося на аналізі сповіщень, які здаються більш шкідливими та потребують подальшого розслідування.
Одне з таких сповіщень — “TrojanDownloader Win32/Harning.gen-P Reporting”.
Натискаємо на опцію «Drilldown», що перемикає фокус на відображення детальної інформації, пов’язаної з цим конкретним сповіщенням. Одне з важливих спостережень — це комунікація через порт призначення 80, що вказує на незашифрований трафік. Щоб поглибити аналіз, натискаємо на стрілку (>) для розгортання сповіщення та доступу до всієї інформації, яку Security Onion зберігає в своїй базі даних, та ретельно досліджуємо сповіщення.
Перший і найважливіший крок — це перевірити саме правило. Це дасть уявлення про характеристики трафіку, що викликали тривогу. У цьому випадку трафік походить з нашої домашньої мережі (внутрішній) і направляється до зовнішньої мережі в інтернеті. Встановлений потік включає сервер, що використовує специфічні заголовки GET
.
У розділі network.data.decoded ми бачимо розшифрований фрагмент мережевого трафіку, що спричинив сповіщення. Він показує, що трафік спрямовується до хоста acxerox.com
, що виглядає підозріло. Для подальшого розслідування можна клацнути на зміст фрагменту, вибрати Actions, а потім вибрати PCAP, щоб відкрити повний захоплення пакетів (PCAP) цього трафіку.
Крім того, при огляді основної консолі я помітив, що сповіщення “Possible Windows executable sent when remote host claims to send HTML content” також стосується того ж хоста, acxerox.com
. Ця кореляція робить справу однозначно вартою ескалації для подальшого аналізу.
TrojanDownloader Win32/Harning.gen-P Reporting
Коли заголовок GET відображається синім, а HTTP-відповідь — червоним під час аналізу PCAP, це зазвичай означає стандартну взаємодію клієнт-сервер. Синій заголовок GET вказує на запит, ініційований клієнтом, часто з вашої внутрішньої мережі та направлений до зовнішнього хоста. У той час, червона HTTP-відповідь підкреслює відповідь сервера на запит клієнта.
Possible Windows executable sent when remote host claims to send HTML content
Різні кольори та ролі трафіку, пов’язані з тим самим хостом, вказують на потенційно підозрілу двосторонню комунікацію. Це може свідчити про те, що хост або скомпрометований, або є шкідливим. Багато сповіщень, що стосуються того ж хоста, acxerox.com
, можуть бути червоним прапором для більш глибокого розслідування. Діяльність цього хоста може бути частиною більшої схеми чи кампанії, що вимагає негайної уваги. Тому ми ескалуємо справу для додаткового аналізу та дій.
Тепер, коли справа ескалована, ми повинні перейти до інтерфейсу Cases, який слугує нашим центральним реєстром для ведення справ. Клацаємо на іконку бінокля, щоб відкрити ескаловану справу. Наступний крок — призначити справу аналітику. У цьому випадку я призначу справу собі та встановлю статус In Progress.
Інтерфейс Case Interface включає два важливі протоколи:
- Traffic Light Protocol (TLP): Вказує рівень дозволеного обміну інформацією та з ким.
- Permissible Action Protocol (PAP): Визначає, наскільки уважно противник може спостерігати за вашими діями.
Для подальшої організації справи я додав категорію з позначенням Malware Trojan і залишив коментар:
“Знайдена підозріла зв'язок з хостом acxerox.com.”
Attachments: Цей розділ призначений для завантаження відповідних файлів або документів, що стосуються цієї справи.
Це можуть бути скріншоти, звіти або докази, такі як файли захоплення пакетів (PCAP), які надають додатковий контекст для розслідування.
Observable: Цей розділ відстежує індикатори компрометації (IOCs) або артефакти, виявлені під час розслідування. Прикладом можуть бути IP-адреси, доменні імена, хеші файлів або URL-адреси, пов'язані з підозрілою активністю.
Events: Цей розділ перераховує конкретні події, пов'язані зі справою. Це допомагає пов’язати сповіщення, журнали або іншу релевантну діяльність з системи моніторингу мережі зі справою для більш глибокого аналізу.
History: Розділ історії зберігає хронологічний запис усіх дій, виконаних щодо справи. Це включає зміни статусу справи, оновлення коментарів або модифікації, внесені аналітиками, що надає чіткий аудиторський слід.
Далі я перейшов до розділу Events і натиснув на іконку ока, щоб додати IP-адресу призначення та ім'я хоста як observable. Цей крок гарантує, що ці ключові індикатори будуть відслідковуватися та включені до справи для подальшого аналізу.
Продовжуючи, я повернувся до інтерфейсу Alerts і прикріпив сповіщення “Possible Windows executable sent when remote host claims to send HTML content” до існуючої справи, яку ми створили. Це рішення базується на спільному хості та підозрюваному зв'язку між двома подіями. Об’єднуючи пов’язані події в одну справу, я спрощую процес розслідування, роблячи його більш зручним для відстеження та аналізу ланцюга подій.
Висновок
У цьому посібнику ми змоделювали атаки Nmap і brute-force, щоб спостерігати, як Security Onion захоплює та аналізує трафік. Ми використали команду so-test
, щоб відтворити трафік, і виконали тріаж для ефективного аналізу та кореляції зібраних даних. Крім того, ми продемонстрували процес визнання сповіщень, які не становлять загрози для нашої мережі, що допомагає усунути помилкові спрацьовування. І на завершення, ми розглянули кроки ескалації сповіщень, створення та управління справами, а також об'єднання пов’язаних подій для спрощеного процесу розслідування в межах Security Onion.
Надалі розслідування повинно зосередитися на більш глибокому аналізі захопленого мережевого трафіку, вивченні потенційних шкідливих завантажень та кореляції з іншими пов’язаними подіями. Це вимагає використання просунутих інструментів та технік для визначення повного масштабу та впливу потенційної загрози.
Однак ці просунуті кроки розслідування виходять за межі цього посібника. Вони будуть детально розглянуті в наступному дописі, де ми дослідимо додаткові техніки тріажу та аналізу для завершення розслідування та визначення відповідних заходів реагування. Залишайтеся на зв'язку!
Перекладено з: Streamlining Threat Detection: A Guide to Using Security Onion for Triage, and Case Creation