Картинка

БЛОГ про

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

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

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 

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

Налаштування QoS на пограничному маршрутизаторі Cisco

Налаштування QoS на пограничному маршрутизаторі Cisco
cisco,router,Налаштування,QoS,Налаштування Cisco

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

Чотири причини замінити брандмауер вашої філії удосконаленою захищеною SD-WAN

Чотири причини замінити брандмауер вашої філії удосконаленою захищеною SD-WAN
Aruba Networks,Блог Телесфера,Налаштування Aruba Instant,Налаштування Aruba

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

Безкомпромісна SASE: Aruba Secure SD-WAN і Netskope SSE

Безкомпромісна SASE: Aruba Secure SD-WAN і Netskope SSE
Aruba Networks,Блог Телесфера,Налаштування Aruba

Програми SaaS, робочі навантаження IaaS, розповсюдження пристроїв IoT і гібридна робоча сила продовжують спонукати підприємства переглядати свої глобальні мережі та архітектури безпеки. Традиційні технології WAN, які базувалися на жорсткій архітектурі WAN, орієнтованій на маршрутизатор, повільно реагували на потреби бізнесу, пропонували непостійну якість роботи та були складними в управлінні. SD-WAN забезпечує кращу та стабільнішу продуктивність хмарних додатків, консолідує функціональні можливості глобальної мережі та підтримує нульову довіру та структуру SASE. Минулого року IDC дослідила Північну Америку та виявила, що 72% підприємств планують перейти на SD-WAN у 2021–2023 роках (1).