На одном из мероприятий у меня состоялась интересная дискуссия о полезности решений класса NTA (Network Traffic Analysis), которые с помощью телеметрии Netflow (или других протоколов потока), получаемой из сетевой инфраструктуры, позволяют выявлять широкий спектр атак.
.
Мои оппоненты утверждали, что при анализе заголовков и сопутствующей информации (а NTA не анализирует тело пакетных данных, в отличие от классических систем обнаружения атак IDS) многое нельзя увидеть.
В этой статье я постараюсь опровергнуть это мнение и, чтобы разговор был более предметным, приведу несколько реальных примеров, когда НТА действительно помогает выявить различные аномалии и угрозы, пропущенные на периметре или вообще обшедшие периметр.
Начну с угрозы, которая в прошлом году занимала первое место в рейтинге угроз и, думаю, останется таковой в этом году.
Мы поговорим об утечках информации и возможности их обнаружения с помощью сетевой телеметрии.
Я не буду рассматривать ситуацию с кривыми руками администраторов, которые оставили незащищенными Elastic или MongoDB при просмотре Интернета.
Давайте поговорим о целенаправленных действиях злоумышленников, как это было в нашумевшей истории с бюро кредитных историй Equifax. Напомню, что в данном случае злоумышленники сначала проникли на общедоступный веб-портал через неисправленную уязвимость, а затем проникли на внутренние серверы баз данных.
Оставаясь незамеченными в течение нескольких месяцев, они смогли украсть данные о 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 таким образом, чтобы она сразу сигнализировала при обнаружении подобных нарушений.
Это делается либо через соответствующее общее меню, либо для каждого соединения, выявленного в ходе расследования.
Вот как будет выглядеть правило обнаружения взаимодействия, источником которого являются серверы баз данных, а местом назначения — любые внешние узлы, а также любые внутренние узлы, за исключением веб-серверов.
При обнаружении такого события система анализа сетевого трафика немедленно формирует сигнал тревоги и, в зависимости от настроек, отправляет его в SIEM, используя средства связи администратору, или даже может автоматически заблокировать обнаруженное нарушение (Cisco Stealthwatch делает это через взаимодействие с Cisco ISE).
Помните, когда я упоминал случай с Equifax, я упомянул, что злоумышленники использовали зашифрованный канал для утечки данных.
Для DLP такой трафик становится невыполнимой задачей, а для решений класса NTA — нет — они отслеживают любой лишний трафик или несанкционированный обмен данными между узлами вне зависимости от использования шифрования.
Выше был показан только один случай (в следующих материалах мы рассмотрим и другие примеры использования NTA в целях информационной безопасности), но на самом деле современные решения класса Network Traffic Analysis позволяют создавать очень гибкие правила и учитывать не только основные параметры заголовка IP-пакета: 
но и провести более глубокий анализ, вплоть до привязки инцидента к имени пользователя из Active Directory, поиска вредоносных файлов по хешу (например, полученному в виде индикатора компрометации от ГосСОПКА, ФинЦЕРТ, Cisco Threat Grid).
и т. д.) и т. д. 
Это легко реализовать.
Например, так выглядит типичное правило для обнаружения всех типов взаимодействий между серверами баз данных и внешними хостами по любому протоколу за последние 30 дней.
Мы видим, что наши базы данных «общались» с внешними по отношению к сегменту СУБД узлами по протоколам DNS, SMB и порту 8088. 
Помимо табличной формы представления результатов расследования или обыска, мы можем также их визуализировать.
Для нашего сценария фрагмент блок-схемы сети может выглядеть так: 
И прямо с этой самой карты мы можем управлять политиками — блокировать соединения или автоматизировать процесс создания правил мониторинга для интересующих нас потоков.
Вот довольно интересный и живой пример использования инструментов мониторинга Netflow (и других протоколов потоков) в целях кибербезопасности.
В будущих постах я планирую показать, как можно использовать NTA для обнаружения вредоносного кода (на примере Shamoon), вредоносных серверов (на примере кампании DNSpionage), программ удаленного доступа (RAT), обхода корпоративных прокси и т.д. Теги: #информационная безопасность #cisco #cisco #утечка данных #Netflow #NTA #утечки данных #stealthwatch #stealthwatch #stealthwatch #nbad #утечки баз данных
-
Ноутбуки Dell Studio Xps 13
19 Oct, 24 -
Как Стать Хорошим Тестером Видеоигр
19 Oct, 24 -
Организация Работы Одного Программиста
19 Oct, 24 -
Клиент Всегда Прав! Или Может Не Всегда?
19 Oct, 24 -
Технологии Виртуализации
19 Oct, 24 -
Сравнение Браузеров Css3 И Html5 (V 2.0)
19 Oct, 24
