— це аналітичне рішення в галузі ІБ, яке забезпечує всебічний моніторинг загроз у розподіленій мережі. В основі роботи StealthWatch лежить збір NetFlow та IPFIX з маршрутизаторів, комутаторів та інших мережних пристроїв. В результаті мережа стає чутливим сенсором і дозволяє адміністратору заглянути туди, куди не можуть дістатися традиційні методи захисту мережі, наприклад Next Generation Firewall.
У минулих статтях я вже писав про StealthWatch: , а також . Зараз пропоную рухатися далі та обговорити, як слід працювати з алармами та розслідувати інциденти безпеки, які генерує рішення. Буде наведено 6 прикладів, які, я сподіваюся, дадуть гарне уявлення про корисність продукту.
Спершу слід сказати, що у StealthWatch присутній деякий розподіл спрацьовувань на алгоритми та фіди. Перші - це різного роду аларми (сповіщення), при спрацьовуванні яких можна виявити підозрілі речі в мережі. Другі – це інциденти безпеки. У цій статті будуть розглянуті 4 приклади спрацьовувань алгоритмів та 2 приклади фідів.
1. Аналіз найоб'ємніших взаємодій усередині мережі
Початковим кроком налаштування StealthWatch є визначення хостів та мереж по групах. У веб-інтерфейсі вкладка Configure > Host Group Management слід рознести мережі, хости, сервери за відповідними групами. Групи можна створювати свої. До речі, аналіз взаємодій між хостами в Cisco StealthWatch досить зручний, тому що можна не тільки зберігати фільтри пошуку потоками, але й самі результати.
Для початку у веб-інтерфейсі варто зайти у вкладку Analyze > Flow Search. Потім слід встановити такі параметри:
- Search Type - Top Conversations (найпопулярніші взаємодії)
- Time Range - 24 hours (проміжок часу, можна використовувати інший)
- Search Name - Top Conversations Inside-Inside (будь-яке зрозуміле ім'я)
- Subject — Host Groups → Inside Hosts (джерело — група внутрішніх вузлів)
- Connection (можна вказати порти, програми)
- Peer – Host Groups → Inside Hosts (призначення – група внутрішніх вузлів)
- У Advanced Options додатково можна вказати колектор, з якого виглядають дані, сортування виводу (за байтами, потоками та інше). Я залишу за замовчуванням.
Після натискання на кнопку Пошук видається список взаємодій, які вже відсортовані за обсягом переданих даних.
У моєму прикладі хост 10.150.1.201 (сервер) у межах лише одного потоку передав 1.5 Гб трафіку на хост 10.150.1.200 (клієнт) за протоколом MySQL. Кнопка Керування стовпцями дозволяє додати більше стовпців у дані, що виводяться.
Далі на розсуд адміністратора можна створити кастомне правило, яке спрацьовуватиме постійно на такого роду взаємодії і повідомлятиме по SNMP, email або Syslog.
2. Аналіз найповільніших клієнт-серверних взаємодій усередині мережі щодо затримок
Мітки SRT (Server Response Time), RTT (Round Trip Time) дозволяють з'ясувати затримки серверів та загальні затримки в мережі. Цей інструмент особливо зручний, коли слід швидко знайти причину скарг користувачів на додаток, що повільно працює.
Примітка: практично всі Netflow експортери не вміють відправляти мітки SRT, RTT, тому найчастіше, щоб бачити такі дані на FlowSensor, потрібно налаштувати відправку копію трафіку з мережевих пристроїв. FlowSensor своєю чергою віддає розширений IPFIX на FlowCollector.
Дану аналітику зручніше проводити в java програмі StealtWatch, яка встановлюється на комп'ютер адміністратора.
Правою клавішею миші на Inside Hosts і переходимо у вкладку Таблиця витрат.
натискаємо на фільтр та встановлюємо необхідні параметри. В якості прикладу:
- Date/Time — For the last 3 days
- Performance - Average Round Trip Time >=50ms
Після виведення даних слід додати цікаві для нас RTT, SRT поля. Для цього слід натиснути на колонку на скріншоті та правою клавішею миші вибрати Керування стовпцями. Далі прокликати параметри RTT, SRT.
Після обробки запиту, я відсортував RTT average і побачив найповільніші взаємодії.
Щоб провалитися в детальну інформацію, слід натиснути правою кнопкою миші на потік і вибрати Quick View for Flow.
Ця інформація говорить про те, що хост 10.201.3.59 з групи Продажі та маркетинг за протоколом NFS звертається до DNS серверу протягом хвилини та 23 секунд і має просто жахливу затримку. У вкладці інтерфейси можна дізнатись, з якого Netflow експортера даних інформація отримана. У вкладці таблиця зображено докладнішу інформацію про взаємодію.
Далі слід дізнатися, які пристрої надсилають трафік на FlowSensor і проблема швидше за все криється там.
Більше того, StealthWatch унікальний тим, що проводить дедуплікацію даних (об'єднує одні й самі потоки). Отже, можна збирати практично з усіх пристроїв Netflow і не боятися, що буде багато даних, що повторюються. Навпаки, у цій схемі це допоможе зрозуміти, на якому саме хопі найбільші затримки.
3. Аудит криптографічних протоколів HTTPS
ETA (Encrypted Traffic Analytics) — технологія, розроблена Cisco, що дозволяє виявляти шкідливі підключення у зашифрованому трафіку без його розшифрування. Більше того, ця технологія дозволяє “розбирати” HTTPS на версії TLS та криптографічні протоколи, які використовуються при з'єднаннях. Цей функціонал є особливо корисним, коли потрібно виявити мережні вузли, які використовують слабкі криптостандарти.
Примітка: попередньо слід встановити network app на StealthWatch ETA Cryptographic Audit.
Переходимо у вкладку Dashboards → ETA Cryptographic Audit та вибираємо групу хостів, яку планується проаналізувати. Для загальної картини оберемо Inside Hosts.
Можна спостерігати, що виводяться версія TLS та відповідний криптостандарт. За звичною схемою у колонці Дії переходимо в View Flows та запускається пошук у новій вкладці.
З висновку видно, що хост 198.19.20.136 впродовж 12 годин використовував HTTPS з TLS 1.2, де алгоритм шифрування AES-256 та хеш-функція SHA-384. Таким чином, ЕТА дозволяє знайти слабкі алгоритми у мережі.
4. Аналіз аномалій у мережі
Cisco StealthWatch вміє розпізнавати аномалії трафіку в мережі, використовуючи три інструменти: Основні події (Події безпеки), Relationship Events (події взаємодій між сегментами, вузлами мережі) та поведінковий аналіз.
Поведінковий аналіз, своєю чергою, дозволяє з часом будувати модель поведінки у тому чи іншого хоста чи групи хостів. Чим більше трафіку проходить через StealthWatch, тим точнішими будуть спрацьовування завдяки цьому аналізу. Спочатку система багато неправильно тригеріт, тому правила слід "підкручувати" руками. Рекомендую перші кілька тижнів не звертати уваги на такі події, оскільки система сама підлаштовується, або ж додавати у винятки.
Нижче наведено приклад встановленого правила Аномалія, в якому йдеться, що подія спрацює без аларма, якщо хост у групі Inside Hosts взаємодіє з групою Inside Hosts і за 24 години трафік перевищить 10 мегабайт.
Для прикладу візьмемо аларм Data Hoardingщо означає, що якийсь хост джерела/призначення завантажив/завантажив аномально велику кількість даних з групи хостів або хоста. Натискаємо на подію і провалюємося в таблицю, де вказуються хости, що тригерять. Далі вибираємо хост, що цікавить нас, у колонці Data Hoarding.
Виводиться подія, що говорить про те, що виявлено 162к "окулярів", а за політикою дозволено 100к "окулярів" - це внутрішні метрики StealthWatch. У колонці Дії натискаємо View Flows.
Ми можемо спостерігати, що даний хост вночі взаємодіяв із хостом 10.201.3.47 з відділу Продажі і Маркетинг за протоколом HTTPS і скачав 1.4 Гб. Можливо цей приклад не зовсім вдалим, але детектування взаємодій і кілька сотень гігабайт здійснюється точно так само. Отже подальше розслідування аномалій може призвести до цікавих результатів.
Примітка: у веб-інтерфейсі SMC дані у вкладках Панелі виводяться лише за останній тиждень та у вкладці монітор за останні 2 тижні. Щоб проаналізувати події старішої давності і для генерації звітів потрібно працювати з java консоллю на комп'ютері адміністратора.
5. Знаходження внутрішніх сканувань мережі
Тепер розглянемо кілька прикладів фідів-інцидентів ІБ. Цей функціонал цікавий більше для безпечних.
Попередньо встановлених типів подій сканування в StealthWatch кілька:
- Port Scan – джерело сканує безліч портів вузла призначення.
- Addr tcp scan - джерело сканує цілу мережу по тому самому TCP порту, змінюючи при цьому IP адресу призначення. При цьому джерело отримує TCP Reset пакети або не отримує відповіді зовсім.
- Addr udp scan - джерело сканує цілу мережу по тому самому UDP порту, змінюючи при цьому IP адресу призначення. При цьому джерело отримує ICMP Port Unreachable пакети або не отримує відповіді зовсім.
- Ping Scan - джерело посилає ICMP запити на цілу мережу з метою пошуку відповідей.
- Stealth Scan tсp/udp — джерело використовувало той самий свій порт для підключення до безлічі портів на вузлі призначення одночасно.
Для зручнішого знаходження відразу всіх внутрішніх сканерів існує network app для StealthWatch - Visibility Assessment. Перейшовши у вкладку Dashboards → Visibility Assessment → Internal Network Scanners Ви побачите інциденти безпеки, які стосуються сканування, за останні 2 тижні.
Натиснувши кнопку ПОДРОБИЦІ, буде видно початку сканування кожної мережі, тренд трафіку та відповідні аларми.
Далі можна “провалитися” у хост із вкладки на попередньому скріншоті та побачити події безпеки, а також активність за останній тиждень для цього хоста.
Як приклад проаналізуємо подію Сканування портів з хоста 10.201.3.149 на 10.201.0.72, натиснувши на Actions > Associated Flows. Запускається пошук потоків і виводиться релевантна інформація.
Як ми бачимо цей хост з одного свого порту 51508/TCP сканував 3 години тому хост призначення по портах 22, 28, 42, 41, 36, 40 (TCP). Деякі поля не відображають інформацію або тому, що не всі поля Netflow підтримуються експортером Netflow.
6. Аналіз завантажених зловредів за допомогою CTA
CTA (Cognitive Threat Analytics) - Хмарна аналітика Cisco, яка чудово інтегрується з Cisco StealthWatch і дозволяє доповнити безсигнатурний аналіз сигнатурним. Тим самим стає можливим детектування троянів, мережевих черв'яків, шкідливих речовин нульового дня та інших зловредів та їх поширення всередині мережі. Також раніше згадана технологія ЕТА дозволяє аналізувати такі шкідливі комунікації та у зашифрованому трафіку.
Буквально на першій вкладці у веб-інтерфейсі є спеціальний віджет Cognitive Threat Analytics. Коротке зведення говорить про виявлені погрози на користувальницьких хостах: троян, шахрайське ПЗ, настирливе рекламне ПЗ. Слово “Encrypted” якраз і свідчить про роботу ЕТА. Натиснувши на хост, по ньому випадає вся інформація, події безпеки, у тому числі логи по СТА.
Наводячи кожний етап СТА, події виводиться докладна інформація про взаємодії. Для повної аналітики варто натиснути View Incident Details, і ви потрапите в окрему консоль Cognitive Threat Analytics.
У верхньому правому куті фільтр дозволяє відобразити події за рівнем критичності. Наводячи на конкретну аномалію, у нижній частині екрана з'являються логи з відповідним таймлайн праворуч. Тим самим, спеціаліст відділу ІБ чітко розуміє, який заражений хост після яких дій почав виконувати якісь дії.
Нижче наведено ще один приклад — банківський троян, яким був заражений хост 198.19.30.36. Цей хост почав взаємодіяти зі шкідливими доменами, а в логах зображено інформацію про потоки цих взаємодій.
Далі одне з найкращих рішень, яке може бути, — закинути хост у карантин завдяки нативній з Cisco ISE для подальшого лікування та аналізу.
Висновок
Рішення Cisco StealthWatch є одним із лідерів серед продуктів моніторингу мережі як з погляду аналізу мережі, так і інформаційної безпеки. Завдяки йому можна виявляти нелегітимні взаємодії всередині мережі, затримки програм, найактивніших користувачів, аномалії, зловредів та APT. Більш того, можна знаходити сканування, пентестери, проводити криптоаудит HTTPS трафіку. Ще більше use cases ви можете знайти по .
Якщо у вас з'явилося бажання перевірити, наскільки у вас у мережі все гладко та ефективно працює, надішліть .
Найближчим часом ми плануємо ще кілька технічних публікацій з різних продуктів ІБ. Якщо вам цікава дана тематика, слідкуйте за оновленнями в наших каналах (, , , )!
Джерело: habr.com