Картинка

БЛОГ про

все цікаве у світі телекомунікацій

Кейси для застосування засобів аналізу мережевих аномалій: виявлення витоків

2020-02-14
Автор: Телесфера

На одному із заходів зав'язалася у мене цікава дискусія на тему корисності рішень класу NTA (Network Traffic Analysis), які за отриманою з мережевої інфраструктури телеметрії Netflow (чи інших flow-протоколів) дозволяє виявляти широкий спектр атак. Мої опоненти стверджували, що при аналізі заголовків і супутньої інформації (а NTA не займається аналізом тіла даних пакетів на відміну від класичних систем виявлення атак, IDS) не можна побачити багато. У даній статті я спробую спростувати цю думку і щоб розмова була більш предметною, наведу кілька реальних прикладів, коли NTA дійсно допомагає виявляти різні аномалії і загрози, пропущені на периметрі або взагалі оминули периметр. А почну я з загрози, яка вийшла на перші місця в рейтингу загроз минулого року і, думаю, залишиться такою в цьому році. Йтиметься про витік інформації і можливості їх виявляти по мережевий телеметрії.

Я не буду розглядати ситуацію з кривими руками адмінів, які залишили незахищені Elastic або MongoDB, що дивляться в Інтернет . Поговоримо про цілеспрямовані дії зловмисників, як це було в гучній історії з бюро кредитних історій Equifax. Нагадаю, що в цьому кейсі зловмисники спочатку проникли через непатчену вразливість на публічний Web-портал, а потім вже і на внутрішні сервера баз даних. Залишаючись протягом декількох місяців непоміченими вони змогли вкрасти дані по 146 мільйонам клієнтів бюро кредитних історій. Чи можна було виявити такий інцидент за допомогою DLP-рішень? Швидше за все ні, так як класичні DLP НЕ заточені під задачу моніторингу трафіку з баз даних за специфічними протоколами, та ще й при умові, що цей трафік зашифрований. А ось рішення класу NTA може досить легко виявити такого роду витік по перевищенню якогось порогового значення обсягу інформації, яка скачується з бази даних. Далі я покажу як це все налаштовується і виявляється за допомогою рішення Cisco Stealthwatch Enterprise.

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

Після того, як ми маємо інформацію про всі сервери баз даних, ми починаємо розслідування з метою з'ясувати, чи не здійснюється у нас витік великих обсягів даних з потрібної групи вузлів. Ми бачимо, що в нашому випадку БД найбільш активно спілкуються з DHCP-серверами і контролерами доменів.

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

У групі DHCP-серверів виявляється, що це вузол з адресою 10.201.0.15, на взаємодію з яким доводиться близько 50% всього трафіку від серверів баз даних.

Наступне логічне запитання, яке ми собі задаємо в рамках розслідування: "А що це за вузол такий 10.201.0.15? З ким він взаємодіє? Як часто? За якими протоколами?"

З'ясовується, що вузол, чкий нас цікавить, спілкується з різними сегментами і вузлами нашої мережі (що не дивно, оскільки це DHCP-сервер), але при цьому питання викликає зайва активна взаємодія з термінальним сервером з адресою 10.201.0.23. Чи нормально це? У наявності явно якась аномалія. Не може DHCP-сервер настільки активно спілкуватися з термінальним сервером - 5610 потоків і 23,5 ГБ даних.

І взаємодія ця здійснюється через NFS.

Робимо наступний крок і намагаємося зрозуміти, з ким взаємодіє наш термінальний сервер? Виявляється, що у нього достатньо активне спілкування йде із зовнішнім світом - з вузлами в США, Великобританії, Канаді, Данії, ОАЕ, Катарі, Швейцарії і т.п.

Підозра викликав факт P2P-взаємодії з Пуерто-Ріко, на яке довелося 90% всього трафіку. Причому наш термінальний сервер передав понад 17 ГБ даних в Пуерто-Ріко по 53-му порту, який у нас пов'язаний з протоколом DNS. Ви можете собі уявити, щоб у вас такий обсяг даних передавався по DNS? А я нагадаю, що згідно з дослідженнями Cisco, 92% шкідливих програм використовують саме DNS для приховування своєї активності (завантаження оновлень, отримання команд, зливу даних).

І якщо на МСЕ DNS-протокол не просто відкритий, але і не інспектується, то ми маємо величезну діру в нашому периметрі.

Якщо вже вузол 10.201.0.23 викликав у нас такі підозри, то давайте подивимося з ким він ще спілкується?

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

Отже, ми провели розслідування і з'ясували наступну картину. Дані з сервера баз даних "зливалися" на DHCP-сервер з подальшою їх передачею по NFS на термінальний сервер всередині нашої мережі, а потім на зовнішні адреси в Пуерто-Ріко по протоколу DNS. Це явне порушення політик безпеки. При цьому термінальний сервер також взаємодіяв з однією з робочих станцій всередині мережі. Що послужило причиною цього інциденту? Вкрадений обліковий запис? Інфікований пристрій? Ми не знаємо. Це вимагатиме продовження розслідування, основу якого заклало рішення класу NTA, що дозволяє аналізувати аномалії мережевого трафіку.

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

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

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

Згадаймо, коли я згадував кейс з Equifax, то згадав, що зловмисники використовували зашифрований канал для зливання даних. Для DLP такий трафік стає нерозв'язним завданням, а для рішень класу NTA немає - вони відстежують будь-яке перевищення трафіку або недозволену взаємодію між вузлами, незалежно від використання шифрування.

Вище був показаний лише один кейс (в наступних матеріалах ми розглянемо інші приклади використання NTA з метою ІБ), але насправді сучасні рішення класу Network Traffic Analysis дозволяють вам створювати дуже гнучкі правила і враховувати не тільки базові параметри заголовка IP-пакету:

але і проводити більш глибокий аналіз, аж до прив'язки інциденту до імені користувача з Active Directory, пошуку шкідливих файлів по хешу (наприклад, отриманого у вигляді індикатора компрометації від, Cisco Threat Grid і т.п.) і т.п.

Реалізується це нескладно. Наприклад, ось так виглядає звичайне правило для виявлення всіх видів взаємодії серверів баз даних із зовнішніми вузлами з будь-якого протоколу за останні 30 днів. Ми бачимо, що наші бази даних «спілкувалися» з зовнішніми по відношенню до сегменту СУБД вузлами по протоколам DNS, SMB і порту 8088.

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

І відразу з цієї ж карти ми можемо управляти політиками - блокувати з'єднання або автоматизувати процес створення правил моніторингу для потоків, які нас цікавлять.

Ось такий, досить цікавий і живий приклад використання інструментів з моніторингу Netflow (і інших flow-протоколів) для цілей кібербезпеки. У наступних замітках я планую показати, як можна використовувати NTA для виявлення шкідливого коду (на прикладі Shamoon), шкідливих серверів (на прикладі кампанії DNSpionage), програм віддаленого доступу (RAT), обходу корпоративних проксі і т.п.

Джерело: https://habr.com/ru/company/cisco/blog/487346/


Про компанію Телесфера Інтеграція.

Телесфера Інтеграція заснована в 2012 році та являється інтегратором новітніх технологічних рішень для бізнесу.  Ми розробляємо рішення, що роблять Ваш бізнес успішним.

Основні напрямки роботи компанії:

  • Побудова локальних обчислювальних мереж;
  • Налаштування мережевого обладнання передових виробників (Cisco Systems, Aruba Networks та інших);
  • Продаж телекомунікаційного обладнання;
  • Аудит локальних обчислювальних мереж;

e-mail: office@telesphera.net
Телефон: (093) 198-11-82 

КОММЕНТАРІ ДО СТАТТІ

Оптимізація хмарних сервісів в AnyConnect VPN тунелі на Cisco ASA

Оптимізація хмарних сервісів в AnyConnect VPN тунелі на Cisco ASA
Cisco,Блог Телесфера,Продуктивність,Налаштування Cisco,Cisco Network

Багато компаній переходять на використання хмарних сервісів в своєму бізнесі по всьому світу, це і офісні додатки, сервіси BigData, чат/відео/аудіо комунікація з метою проведення мітингів/навчання і багато інших. Однак з огляду на масове переведення на віддалену роботу співробітників так чи інакше потрібно отримувати доступ до корпоративної мережі (якщо звичайно замовник не повністю працює на хмарній платформі), для того щоб зробити доступ безпечним, як правило, використовуються сервіси типу Remote-Access VPN.

Cisco має намір спростити кібербезпеку хмарної інфраструктури за допомогою SecureX

Cisco має намір спростити кібербезпеку хмарної інфраструктури за допомогою SecureX
Cisco,Cisco Wi-Fi,cisco,cisco безпека,Налаштування,Налаштування Cisco,новини

Компанія Cisco представила хмарну платформу кібербезпеки Cisco SecureX, яка, як заявлено, радикально спрощує роботу з усіма продуктами компанії в області інформаційної безпеки (ІБ) і вирішує проблему зайвої складності систем, що стала однією з пріоритетних для директорів з кібербезпеки.

Cisco запропонує більше рішень для малого бізнесу

Cisco запропонує більше рішень для малого бізнесу
Cisco,Cisco Network,cisco,cisco безпека,Налаштування,Налаштування Cisco,новини

Малий бізнес займає суттєвий відсоток світового ринку ІТ: на його частку припадає 44% всіх ІТ-витрат, при цьому за темпами зростання він перевершує корпоративний сегмент. І зараз, в процесі цифрової трансформації бізнес-моделей, малому бізнесу як ніколи потрібна гнучкість.