С точки зрения обеспечения кибербезопасности перед нами обычно стоит всего три основные задачи, которые, конечно, потом разбиваются на более мелкие подзадачи и проекты, но, немного утрируя, по-крупному, задач всего три:
Какие бы решения мы не рассматривали они укладываются в эти три задачи, которые мы должны реализовывать в любом месте корпоративной сети. Вот этот жизненный цикл борьбы с угрозами (ДО — ВО ВРЕМЯ — ПОСЛЕ) и положен в основу деятельности службы ИБ компании Cisco. Причем обращу внимание, что так как в компании Cisco отсутствует понятие периметра, то мы стараемся реализовать описанные выше три задачи везде — в ЦОДах, в облаках, в сегменте Wi-Fi, на мобильных устройствах сотрудников, в точках выхода в Интернет и, конечно же, в нашей внутренней сети, о мониторинге которой мы сегодня и поговорим.
У нас ведь такой вопрос не возникает относительно периметра (почему у нас нет периметра, я расскажу как-нибудь в другой раз), где мы ставим и МСЭ, и IDS, и средства контентной фильтрации, множество других средств сетевой безопасности. Почему же внутренняя сеть должна быть исключением? Что, в нее нельзя попасть извне, минуя периметр? Да кучей способов. Через незащищенный собственный Wi-Fi или через точку доступа соседней “Шоколадницы”, к которой автоматически подключаются мобильные устройства ваших сотрудников, привыкших в кафе перехватить чашку горячего кофе или пообедать. Через взломанный домашний ноутбук или планшет/смартфон руководства, которое притащило его в офис, чтобы “айтишники разобрались”. Через подброшенную к офису флешку, на которой залит нетектируемый вредоносный код. Через зашифрованный канал клиент-серверного приложения, которое разрабатывали без учетов вопросов безопасности. Да через уязвимости в периметр в конце концов (не будем же мы считать, что наш МСЭ абсолютно неуязвим). То есть внутренняя сеть нуждается в такой же защите, как и периметр, на котором многие организации неоправданно часто фокусируют свои усилия по защите, напрочь забывая про истину о самом слабом звене.
Как предотвращаются угрозы во внутренней сети Cisco я уже рассказывал — мы используем для этого Cisco Identity Service Engine (ISE), который выполняет функцию распределенного МСЭ, превращающего каждый коммутатор или маршрутизатор, а у нас только последних свыше 40 тысяч, в часть внутреннего средства разграничения доступа, работающего на динамических политиках. Но одного разграничения и предотвращения нам недостаточно. Мы должны также контролировать активность в рамках разрешенных внутри соединений, а также отслеживать любые нарушения установленных правил внутреннего доступа (все мы люди, всем нам свойственно ошибаться). На периметре бы мы поставили систему обнаружения вторжений (IDS) и решили бы эту проблему. Во внутренней сети ставить IDS непросто, хотя Cisco была бы рада продать как можно больше сенсоров нашей Cisco NGIPS, тем более что мы в очередной раз стали лидером этого рынка по версии Gartner. Но это зачастую невозможно (исключая некоторые места внутри сети типа ЦОДов или отдельных сегментов). Невозможно и с точки зрения архитектуры — не на каждый порт коммутатора можно поставить сенсор IDS, не каждый транковый или span-порт, к которому часто подключается IDS, потянет трафик со всех портов коммутатора, не всегда span-порт свободен. Невозможно и с точки зрения финансов — очень уж дорого покупать высокопроизводительные сенсоры на каждый коммутатор или маршрутизатор. Даже в Cisco, несмотря на то, что мы сами и производим NGIPS, мы не можем тратить немалые средства на мониторинг с помощью IDS нашей внутренней сети — это достаточно накладно. Даже если попробовать применить разветвители (tap), то они не решат всех проблем ни с точки зрения архитектуры, ни с точки зрения финансов. Кроме того, если на периметре безопасники еще как-то научились жить с айтишниками (сетевиками), то во внутренней сети конфликт продолжает тлеть. Есть ли у нас альтернатива классическим сетевым IDS для решения той же задачи?
Ответ будет положительным и зовется он Netflow. Это протокол, который был первоначально разработан компанией Cisco для целей обнаружения проблем в сети (troobleshooting), который затем стал стандартом де-факто для многих сетевых производителей, которые либо поддерживали в своем оборудовании Netflow, либо создавали его клоны — Cflow, sFlow, Jflow, NetStream, Rflow и т.п. Но поскольку мы сегодня говорим о том, как мониторится внутренняя сеть Cisco, а у нас используется наше же сетевое оборудование, то мы сконцентрируемся только на протоколе Netflow, который есть сегодня почти на любой нормальной сетевой “железке” корпоративного уровня (от всяких “домашних” устройств ждать поддержки Netflow не стоит — дома она просто не нужна и только утяжелит и удорожит решение).
Итак, Netflow на сетевом оборудовании, через которое проходит весь трафик, требующий контроля, есть. Это значит, что мы можем попробовать использовать его не только для обнаружения каких-либо проблем в сети, но и для целей информационной безопасности. Кроме того, поддержка Netflow сетевым оборудованием позволяет нам не строить отдельную, наложенную сеть для целей мониторинга, а позволяет уже используемое сетевое оборудование задействовать и под задачи ИБ. Это с одной стороны защищает уже сделанные инвестиции и удешевляет решение по мониторингу, а с другой, делает его более простым с точки зрения и архитектуры и внедрения — не надо пытаться правильно направить нужные нам потоки на десятки или сотни сенсоров IDS, которые в противоположном случае мы бы вынуждены были поставить в своей сети. Работа с Netflow дает нам и еще одно, не сразу видимое преимущество. В случае с установкой обычных IDS мы должны решить задачу направления трафика или его копии на сенсоры системы защиты. Если по каким-то причинам этого не произойдет (например, по причине смены топологии или нехватка пропускной способности у сенсора), то мы ровном счетом ничего не увидим и будем думать, что никаких атак в интересующем нас трафике нет. Сам сенсор же работает — только не получает и не анализирует нужный трафик. С Netflow это не проходит — мы видим все, что протекает через сетевое устройство, в качестве которого может выступать не только маршрутизатор или коммутатор (в том числе и виртуальные), но и, например, межсетевой экран (например, Cisco ASA поддерживает функцию NSEL, Netflow Security Event Logging, которая позволяет транслировать сетевые потоки в виде Netflow для анализа соответствующим средством мониторинга).
Пора сделать пару замечаний относительно Netflow, которые получили в результате эксплуатации Netflow для целей безопасности в сети Cisco. Во-первых, надо знать, что Netflow бывает несемплированный и семплированный. Отличия между ними такие же, как если читать полную книгу “от корки до корки” или пролистывать ее, останавливаясь только на каждой десятой странице. Многие сетевые устройства поддерживают Netflow, но только семплированный, который не подходит для целей безопасности, так как мы видим только малую часть всего трафика, который нам нужен для мониторинга. Поэтому обращайте внимание на то, какой Netflow у вас поддерживается. Семплированный для целей ИБ не подходит. Во-вторых, надо знать, что обработка Netflow, особенно несемплированного создает нагрузку на процессор сетевого устройства, что необходимо учитывать при планировании сети и выстраивании системы мониторинга ИБ на базе Netflow. Если ваши коммутаторы или маршрутизаторы работают уже на пределе своих сил и загрузка их ЦПУ достигает 80-90% в обычном режиме работе, то стоит десять раз подумать, включать ли на них Netflow, из-за которго производительность устройство точно просядет еще больше. Решений в данной ситуации два — обновление сетевой инфраструктуры (все равно рано или поздно это пришлось бы делать) и использование устройств генерации Netflow. Мы в Cisco использовали оба варианта. В тех случаях, где мониторинг Netflow был критичной задачей и пришло время для апгрейда, мы установили новые коммутаторы и марщратизаторы с аппаратной обработкой Netflow, ненагружающее ЦПУ. В других случаях мы воспользовались решением под названием FlowSensor, которое пропускаемый через себя трафик (аналог разветвителя, tap) транслировало в Netflow, передаваемый дальше для анализа нашей службой безопасности.
Существует несколько версий протокола Netflow, самыми распространенными из которых сегодня являются 5-я и 9-я. На основе последней была разработана открытая спецификация IPFIX. 5-я версия протокола позволяет собирать следующую информацию о сетевом трафике:
9-я версия поддерживает дополнительные поля, связанные с IPv6, MPLS, BGP. Также существуют и расширенные версии Netflow, тот же IPFIX, Flexible Netflow, которые поддерживают и пользовательские поля.
Эта информация на первый взгляд поверхностна и отражает только то, что находится в заголовках сетевых сессий, но на самом деле, как мы уже видели в рассказе о технологии анализа зашифрованного трафика (ETA), для классификации и распознавания трафика этого во многих случаях достаточно. Например, избыточно большое число пакетов или байт может характеризовать DoS, большое количество адресов назначения за ограниченный интервал времени может означать сканирование сети и т.п. С помощью Netflow можно профилировать узлы и отслеживать отклонения от их стандартного поведения.
Первоначально в Cisco для мониторинга использовались бесплатные решения nfdump (https://github.com/phaag/nfdump) и OSU FlowTools (OSU — это аббревиатура от Ohio State University), позволяющие работать с Netflow — фильтровать, делать выборку и производить другие операции над сетевыми потоками. Оба решения достаточно быстры (могут обрабатывать несколько десятков гигабайт потоков в день), просты в использовании для тех, кто уже имеет опыт работы с классическими утилитами типа tcpdump, гибки в фильтрации. Но есть у этих инструментов и проблемы, которые можно разбить на три части. Во-первых, это недостатики самих утилит, которые не позволяли, например, нормально агрегировать потоки, что зачастую приводит к их дублированию (представьте, что один и тот же поток проходит через 5 сетевых устройств — утилиты их также увидят и запишут 5 раз). Кроме того, nfdump и Flow Tools не позволяли отслеживать потери потоков, что приводило к чувству ложной защищенности (перефразируя классическую фразу из фильма “ДМБ”, “ты думаешь ты видишь поток, а на самом деле нет”). В небольшой сети это не столь критично, но в такой распределенной как в Cisco, это стало создавать большие сложности по мере расширения внедрения системы мониторинга на новых площадках. Во-вторых, у любого open source проекта есть сложности, связанные с поддержкой, добавлением новых фич, расширением числа поддерживаемых версий Netflow и т.п. Ну и наконец, работа с nfdump и OSU Flow Tools требовали не только высокой квалификации от персонала, но и немалых усилий по автоматизации типовых и рутинных задач, связанных с расследованием инцидентов и реагированием на них.
Например, для обнаружения зараженных внутренних машин, коммуницирующих с командными серверами, необходимо создать и поддерживать в актуальном состоянии соответствующий список в формате Cisco ACL, а потом подать его на вход утилит flow-filter, которая применет его к собранным потокам Netflow.
Понятно, что для эффективной работы вам нужно поддерживать в актуальном состоянии множество заранее созданных списков — атакующих, C&C-серверов, внутренних узлов, сегментированных по различным критериям и т.п. При этом последний список сам по себе будет постоянно меняться ввиду изменичивости динамической инфраструктуры Cisco.
Еще одной проблемой применения nfdump и OSU Flow Tools является неумение распознавать, кто инициировал то или иное соединение (это важно при расследовании), так как потоки однонаправленные. Приходится проводить допонительную работу для того, чтобы понять, кто был первым в клиент-серверных соединениях. Наконец, мы наткнулись и еще на одну тонкость, связанную с работой названных утилит. Они записывают только завершенные потоки, что может привести к невозможности оперативно отследить атаки, происходящие в реальном времени. Например, злоумышленник уже провел сканирование сети, компрометацию узла и проникновение на него, а ни nfdump, ни Flow Tools еще об этом не знают, так как сетевой поток ими не зафиксирован.
После полученного опыта работы с nfdump и OSU Flow Tools и по мере перехода на IPv6 и Netflow 9-й версии мы стали искать инструмент, лишенный недостатков, с которыми мы столкнулись. Им стало решение Stealthwatch компании Lancope, которую мы позже приобрели и она стала частью Cisco. Stealthwatch построен по классической для любого анализатора архитектуре “сенсор — коллектор — анализатор”.
В качестве сенсоров мы используем нашу сетевую инфраструктуру, которая пропуская через себя весь внутренний сетевой трафик, транслирует его в Netflow и передает на коллекторы для анализа. Как я уже писал выше, не всегда сетевое оборудование поддерживает Netflow или способно его эффективно обрабатывать. Для этой задачи мы используем отдельные аппаратные или виртуальные FlowSensor (всего их у нас 13). Учитывая территориально-распределенную инфраструктуру Cisco мы сводим все потоки не на один или два коллектора, а целый распределенный кластер из 21 FlowCollector, которые обрабатывают около 20 миллиардов потоков Netflow каждый день в поисках вредоносной активности в нашей корпоративной магистрали и ЦОДах. А консолей у нас всего две — к ним имеют доступ сотрудники службы реагирования на инциденты Cisco в соответствие со своими ролями
Пожалуй, основным препятствием к эффективному применению open source инструментов мониторинга Netflow в нашей сети (да ив ообще) послужило отсутствие у них нормальной аналитики. Они обладают гибкими средствами фильтрации и выборки, но без человека они не способны принять решение о наличии или отсутствии проблемы в сетевых потоках. Stealthwatch был лишен этого недостатка — ключевым его достоинством было наличие встроенной базы алгоритмов, позволяющих оценивать Netflow и распознавать в нем различные нарушения безопасности — сканирование сети, DoS, распространение вредоносного кода, утечка информации и т.п.
Ключевые сценарии, в которым мы задействуем Stealthwatch (на самом деле их больше):
Netflow — идеальный источник информации при расследовании инцидентов, который содержит всю необходимую информацию о том, кто и что, когда и какие действия осуществлял. При этом вся эта информация хранится в базе данных и сотрудники службы реагирования могут делать необходимые запросы к ней, осуществляя фильтрацию и выборку по нужным полям, быстро находя ответы на свои вопросы. Интеграция с Cisco ISE дает информацию не только с привязкой к IP-адресам узлов, участвующих в инциденте, но и с привязкой к учетным записям пользователей компании в Active Directory. Последняя возможность является не только удобной, но и существенно сокращает время на сопоставление имени пользователя с его динамическим IP-адресом, который был у него в интересующий момент времени. Сокращение времени — это критический фактор успеха в расследовании инцидентов.
Вторым кейсом, который показывает мощь Stealthwatch, является обнаружение взаимодействия с командными серверами ботнетов и вредоносных программ. Казалось бы, это может быть сделано и на периметре, но давайте вспомним то, с чего начиналась эта заметка. Атаковать пользователя сегодня можно кучей разных способов и далеко не всегда через периметр. Что, если шифровальщик пробрался внутрь сети через незащищенный Wi-Fi и через него же происходит утечка информации или получение обновлений для вредоносного кода? Зафиксировать это можно только путем мониторинга внутреннего сетевого трафика и Stealthwatch тут незаменим. Раньше мы эту задачу осуществляли с помощью nfdump, но у него было одно ограничение — приходилось в ручном режиме обновлять список IP-адресов командных серверов, собирая его из разных источников. В случае с Stealthwatch эта задача решается автоматически — он сам регулярно подгружает обновленные индикаторы компрометации, содержащие информацию о серверах управления. Полезность этой функции еще и в том, что она отслеживает устаревание адресов из списка и удаляет их по мере необходимости. В случае с nfdump приходилось делать это вручную, что отнимало драгоценное время.
Обнаружение атак “отказ в обслуживании” — еще один популярный use case, который мы применяем у себя в сети. Нельзя сказать, что такие инциденты происходят регулярно, но бывает. “Наводнения”, “шторма”, “лавины” запросов по различным сетевым и прикладным протоколам достаточно легко детектируются с помощью Stealthwatch.
Решения класса Network Traffic Analysis, к которым относится и Stealthwatch, не обладают DLP-функционалом и не способны мониторить содержание переписки по различным протоколам. Однако при этом они способы бороться с утечками информации, для чего используется немного иной принцип. Учитывая, что в рамках Netflow можно отслеживать объем передаваемой информации, то мы можем для каждого узла или пользователя установить некие усредненные значения объема информации по разным протоколам, которые может загрузить из Интернет или выгрузить в Интернет пользователь. Допустим, для протокола HTTP эта цифра будет равна 100 Мб в сутки.
Соответственно превышение этого значения будет считаться аномалией, а существенное превышение, например, в 5 раз и более, явным нарушением политики ИБ. Выгрузка больших объемов данных в облачные хранилища может означать, что пользователь пытается украсть конфиденциальную информацию. Разумеется, я не зря использую слово “может”, так как это может быть и признаком вполне легальной активности, например, пользователь передает через облако новый дистрибутив ПО или набор документов или видео-тренинг. В любом случае срабатывание тригера на превышение пороговых значений данных должно стать причиной для проведения расследования.
Еще одним сценарием, который мы активно используем в своей сети применительно к Stealthwatch, является проверка настройки правил разграничения доступа для отслеживания неразрешенного между сегментами трафика. Сегментация — один из полезнейших инструментов в арсенале служб ИБ, который позволяет существенно снизить площадь атаки, локализовывать проблемы, оперативно проводить расследования и т.п. У нас в сети сегментация активно используется на базе сетевого оборудования, а управляет ею Cisco ISE. С помощью Stealthwatch мы проверяем корректность настроек сегментации и видим трафик, который не должен появляться в том или ином сегменте.
Эта же возможность позволяет проверять и корректность настроек межсетевых экранов, стоящих на периметре и, возможно, пропускающих какой-то неразрешенный трафик. По сути Stealthwatch в данном use case превращается в дополнительный инструмент контроля действий администраторов.
Stealthwatch является решением, которое хотя и может применяться сетевиками и айтишниками, но предназначено для безопасников. В Cisco им занимается служба реагирования на инциденты Cisco CSIRT. Мы собираем данные с 180 ключевых сетевых устройств, установленных в центрах обработки данных, крупных корпоративных хабах и в DMZ, получая примерно 180 тысяч потоков в секунду.
В одной из прошлых заметок я уже писал о наличии API в наших продуктах. Такой API есть и в Stealthwatch и он очень активно используется нашей службой реагирования на инциденты. В частности именно через API мы обновляем информацию об узлах, включенных в те или иные группы.
Именно через API мы обновляем информацию о новых вредоносных узлах, взаимодействие с которыми отслеживается с помощью Stealthwatch. С помощью API мы интегрируем Stealthwatch с используемой у нас open source платформой Threat Intelligence CRiTS. Это позволяет нам при получении данных о новых индикаторах компрометации раздать эту информацию по всем средствам защиты, интегрированным с CRiTS через API.
API же позволяет собирать из Stealthwatch нужные нам события и потоки для передачи их в Splunk, который является основным средством мониторинга в Cisco, в том числе и для проведения более детальных расследований.
Интересным опытом, который я пока больше нигде не встречал, является концепция мобильного SOC (Security Operations Center), который мы используем для мониторинга ИБ на удаленных площадках, покупаемых нами компаний, новых заводах, партнерах или при проведении расследований на площадках, которые не подключены на центральную систему мониторинга. Мобильный SOC — это перевозимая стойка с ИБ-оборудованием, которое включает в себя не только Stealthwatch, но и Netflow Generation Appliance, Splunk, Firepower, Web Security Appliance и т.п.
Мы не останавливаемая на достигнутом и планируем достаточно активно развивать применение Stealthwatch в нашей инфраструктуре. Среди первоочередных планов:
В целом надо признать, что анализ Netflow с помощью Stealthwatch помогает нашей службе ИБ обнаруживать больше инцидентов, чем обычный набор средств защиты, используемый на периметре корпоративной сети. Можно отследить динамику изменения источников данных об инцидентах, которые у нас происходят. Если раньше это было преимущвестенно сигнатуры атак от IDS, то сегодня на этот источник приходится только пятая часть всех инцидентов. Еще одна пятая часть приходится на поведенческий анализ, 40% на индикаторы компрометации. Обнаружение оставшихся 20% инцидентов базируется именно на Netflow.
— история успеха «Stealthwatch в Cisco» (англ.)
— рассказ о применении Stealthwatch в Cisco от руководителя CSIRT (видео, англ.)
— страница Stealthwatch на сайте Cisco
- предотвращение угроз
- обнаружение угроз
- реагирование на угрозы.
Какие бы решения мы не рассматривали они укладываются в эти три задачи, которые мы должны реализовывать в любом месте корпоративной сети. Вот этот жизненный цикл борьбы с угрозами (ДО — ВО ВРЕМЯ — ПОСЛЕ) и положен в основу деятельности службы ИБ компании Cisco. Причем обращу внимание, что так как в компании Cisco отсутствует понятие периметра, то мы стараемся реализовать описанные выше три задачи везде — в ЦОДах, в облаках, в сегменте Wi-Fi, на мобильных устройствах сотрудников, в точках выхода в Интернет и, конечно же, в нашей внутренней сети, о мониторинге которой мы сегодня и поговорим.
Зачем нужно мониторить внутреннюю сеть?
У нас ведь такой вопрос не возникает относительно периметра (почему у нас нет периметра, я расскажу как-нибудь в другой раз), где мы ставим и МСЭ, и IDS, и средства контентной фильтрации, множество других средств сетевой безопасности. Почему же внутренняя сеть должна быть исключением? Что, в нее нельзя попасть извне, минуя периметр? Да кучей способов. Через незащищенный собственный Wi-Fi или через точку доступа соседней “Шоколадницы”, к которой автоматически подключаются мобильные устройства ваших сотрудников, привыкших в кафе перехватить чашку горячего кофе или пообедать. Через взломанный домашний ноутбук или планшет/смартфон руководства, которое притащило его в офис, чтобы “айтишники разобрались”. Через подброшенную к офису флешку, на которой залит нетектируемый вредоносный код. Через зашифрованный канал клиент-серверного приложения, которое разрабатывали без учетов вопросов безопасности. Да через уязвимости в периметр в конце концов (не будем же мы считать, что наш МСЭ абсолютно неуязвим). То есть внутренняя сеть нуждается в такой же защите, как и периметр, на котором многие организации неоправданно часто фокусируют свои усилия по защите, напрочь забывая про истину о самом слабом звене.
Разве IDS недостаточно?
Как предотвращаются угрозы во внутренней сети Cisco я уже рассказывал — мы используем для этого Cisco Identity Service Engine (ISE), который выполняет функцию распределенного МСЭ, превращающего каждый коммутатор или маршрутизатор, а у нас только последних свыше 40 тысяч, в часть внутреннего средства разграничения доступа, работающего на динамических политиках. Но одного разграничения и предотвращения нам недостаточно. Мы должны также контролировать активность в рамках разрешенных внутри соединений, а также отслеживать любые нарушения установленных правил внутреннего доступа (все мы люди, всем нам свойственно ошибаться). На периметре бы мы поставили систему обнаружения вторжений (IDS) и решили бы эту проблему. Во внутренней сети ставить IDS непросто, хотя Cisco была бы рада продать как можно больше сенсоров нашей Cisco NGIPS, тем более что мы в очередной раз стали лидером этого рынка по версии Gartner. Но это зачастую невозможно (исключая некоторые места внутри сети типа ЦОДов или отдельных сегментов). Невозможно и с точки зрения архитектуры — не на каждый порт коммутатора можно поставить сенсор IDS, не каждый транковый или span-порт, к которому часто подключается IDS, потянет трафик со всех портов коммутатора, не всегда span-порт свободен. Невозможно и с точки зрения финансов — очень уж дорого покупать высокопроизводительные сенсоры на каждый коммутатор или маршрутизатор. Даже в Cisco, несмотря на то, что мы сами и производим NGIPS, мы не можем тратить немалые средства на мониторинг с помощью IDS нашей внутренней сети — это достаточно накладно. Даже если попробовать применить разветвители (tap), то они не решат всех проблем ни с точки зрения архитектуры, ни с точки зрения финансов. Кроме того, если на периметре безопасники еще как-то научились жить с айтишниками (сетевиками), то во внутренней сети конфликт продолжает тлеть. Есть ли у нас альтернатива классическим сетевым IDS для решения той же задачи?
Как мониторить внутреннюю сеть без IDS?
Ответ будет положительным и зовется он Netflow. Это протокол, который был первоначально разработан компанией Cisco для целей обнаружения проблем в сети (troobleshooting), который затем стал стандартом де-факто для многих сетевых производителей, которые либо поддерживали в своем оборудовании Netflow, либо создавали его клоны — Cflow, sFlow, Jflow, NetStream, Rflow и т.п. Но поскольку мы сегодня говорим о том, как мониторится внутренняя сеть Cisco, а у нас используется наше же сетевое оборудование, то мы сконцентрируемся только на протоколе Netflow, который есть сегодня почти на любой нормальной сетевой “железке” корпоративного уровня (от всяких “домашних” устройств ждать поддержки Netflow не стоит — дома она просто не нужна и только утяжелит и удорожит решение).
Итак, Netflow на сетевом оборудовании, через которое проходит весь трафик, требующий контроля, есть. Это значит, что мы можем попробовать использовать его не только для обнаружения каких-либо проблем в сети, но и для целей информационной безопасности. Кроме того, поддержка Netflow сетевым оборудованием позволяет нам не строить отдельную, наложенную сеть для целей мониторинга, а позволяет уже используемое сетевое оборудование задействовать и под задачи ИБ. Это с одной стороны защищает уже сделанные инвестиции и удешевляет решение по мониторингу, а с другой, делает его более простым с точки зрения и архитектуры и внедрения — не надо пытаться правильно направить нужные нам потоки на десятки или сотни сенсоров IDS, которые в противоположном случае мы бы вынуждены были поставить в своей сети. Работа с Netflow дает нам и еще одно, не сразу видимое преимущество. В случае с установкой обычных IDS мы должны решить задачу направления трафика или его копии на сенсоры системы защиты. Если по каким-то причинам этого не произойдет (например, по причине смены топологии или нехватка пропускной способности у сенсора), то мы ровном счетом ничего не увидим и будем думать, что никаких атак в интересующем нас трафике нет. Сам сенсор же работает — только не получает и не анализирует нужный трафик. С Netflow это не проходит — мы видим все, что протекает через сетевое устройство, в качестве которого может выступать не только маршрутизатор или коммутатор (в том числе и виртуальные), но и, например, межсетевой экран (например, Cisco ASA поддерживает функцию NSEL, Netflow Security Event Logging, которая позволяет транслировать сетевые потоки в виде Netflow для анализа соответствующим средством мониторинга).
Пора сделать пару замечаний относительно Netflow, которые получили в результате эксплуатации Netflow для целей безопасности в сети Cisco. Во-первых, надо знать, что Netflow бывает несемплированный и семплированный. Отличия между ними такие же, как если читать полную книгу “от корки до корки” или пролистывать ее, останавливаясь только на каждой десятой странице. Многие сетевые устройства поддерживают Netflow, но только семплированный, который не подходит для целей безопасности, так как мы видим только малую часть всего трафика, который нам нужен для мониторинга. Поэтому обращайте внимание на то, какой Netflow у вас поддерживается. Семплированный для целей ИБ не подходит. Во-вторых, надо знать, что обработка Netflow, особенно несемплированного создает нагрузку на процессор сетевого устройства, что необходимо учитывать при планировании сети и выстраивании системы мониторинга ИБ на базе Netflow. Если ваши коммутаторы или маршрутизаторы работают уже на пределе своих сил и загрузка их ЦПУ достигает 80-90% в обычном режиме работе, то стоит десять раз подумать, включать ли на них Netflow, из-за которго производительность устройство точно просядет еще больше. Решений в данной ситуации два — обновление сетевой инфраструктуры (все равно рано или поздно это пришлось бы делать) и использование устройств генерации Netflow. Мы в Cisco использовали оба варианта. В тех случаях, где мониторинг Netflow был критичной задачей и пришло время для апгрейда, мы установили новые коммутаторы и марщратизаторы с аппаратной обработкой Netflow, ненагружающее ЦПУ. В других случаях мы воспользовались решением под названием FlowSensor, которое пропускаемый через себя трафик (аналог разветвителя, tap) транслировало в Netflow, передаваемый дальше для анализа нашей службой безопасности.
Что нам может рассказать Netflow?
Существует несколько версий протокола Netflow, самыми распространенными из которых сегодня являются 5-я и 9-я. На основе последней была разработана открытая спецификация IPFIX. 5-я версия протокола позволяет собирать следующую информацию о сетевом трафике:
- Адрес источника
- Адрес назначения
- Порт источника для UDP и TCP
- Порт назначения для UDP и TCP
- Тип и код сообщения для ICMP
- Номер протокола IP
- Сетевой интерфейс (параметр ifindex SNMP)
- Значение Type of Service
- Временные параметры
- Объем переданных байт и пакетов
- Значения флагов TCP
- Маршрутную информацию
- Информацию об автономных системах.
9-я версия поддерживает дополнительные поля, связанные с IPv6, MPLS, BGP. Также существуют и расширенные версии Netflow, тот же IPFIX, Flexible Netflow, которые поддерживают и пользовательские поля.
Эта информация на первый взгляд поверхностна и отражает только то, что находится в заголовках сетевых сессий, но на самом деле, как мы уже видели в рассказе о технологии анализа зашифрованного трафика (ETA), для классификации и распознавания трафика этого во многих случаях достаточно. Например, избыточно большое число пакетов или байт может характеризовать DoS, большое количество адресов назначения за ограниченный интервал времени может означать сканирование сети и т.п. С помощью Netflow можно профилировать узлы и отслеживать отклонения от их стандартного поведения.
Как мы мониторили нашу сеть раньше?
Первоначально в Cisco для мониторинга использовались бесплатные решения nfdump (https://github.com/phaag/nfdump) и OSU FlowTools (OSU — это аббревиатура от Ohio State University), позволяющие работать с Netflow — фильтровать, делать выборку и производить другие операции над сетевыми потоками. Оба решения достаточно быстры (могут обрабатывать несколько десятков гигабайт потоков в день), просты в использовании для тех, кто уже имеет опыт работы с классическими утилитами типа tcpdump, гибки в фильтрации. Но есть у этих инструментов и проблемы, которые можно разбить на три части. Во-первых, это недостатики самих утилит, которые не позволяли, например, нормально агрегировать потоки, что зачастую приводит к их дублированию (представьте, что один и тот же поток проходит через 5 сетевых устройств — утилиты их также увидят и запишут 5 раз). Кроме того, nfdump и Flow Tools не позволяли отслеживать потери потоков, что приводило к чувству ложной защищенности (перефразируя классическую фразу из фильма “ДМБ”, “ты думаешь ты видишь поток, а на самом деле нет”). В небольшой сети это не столь критично, но в такой распределенной как в Cisco, это стало создавать большие сложности по мере расширения внедрения системы мониторинга на новых площадках. Во-вторых, у любого open source проекта есть сложности, связанные с поддержкой, добавлением новых фич, расширением числа поддерживаемых версий Netflow и т.п. Ну и наконец, работа с nfdump и OSU Flow Tools требовали не только высокой квалификации от персонала, но и немалых усилий по автоматизации типовых и рутинных задач, связанных с расследованием инцидентов и реагированием на них.
Например, для обнаружения зараженных внутренних машин, коммуницирующих с командными серверами, необходимо создать и поддерживать в актуальном состоянии соответствующий список в формате Cisco ACL, а потом подать его на вход утилит flow-filter, которая применет его к собранным потокам Netflow.
[mynfchost]$ head bot.acl
ip access-list standard bot permit host 69.50.180.3
ip access-list standard bot permit host 66.182.153.176
[mynfchost]$ flow-cat /var/local/flows/data/2007-02-12/ft* | flow-filter -S bot.acl
Start End Sif SrcIPaddress SrcP DIf DstIPaddress DstP
0213.08:39:49.911 0213.08:40:34.519 58 10.10.71.100 8343 98 69.50.180.3 31337 0213.08:40:33.590 0213.08:40:42.294 98 69.50.180.3 31337 58 10.10.71.100 83 Понятно, что для эффективной работы вам нужно поддерживать в актуальном состоянии множество заранее созданных списков — атакующих, C&C-серверов, внутренних узлов, сегментированных по различным критериям и т.п. При этом последний список сам по себе будет постоянно меняться ввиду изменичивости динамической инфраструктуры Cisco.
Еще одной проблемой применения nfdump и OSU Flow Tools является неумение распознавать, кто инициировал то или иное соединение (это важно при расследовании), так как потоки однонаправленные. Приходится проводить допонительную работу для того, чтобы понять, кто был первым в клиент-серверных соединениях. Наконец, мы наткнулись и еще на одну тонкость, связанную с работой названных утилит. Они записывают только завершенные потоки, что может привести к невозможности оперативно отследить атаки, происходящие в реальном времени. Например, злоумышленник уже провел сканирование сети, компрометацию узла и проникновение на него, а ни nfdump, ни Flow Tools еще об этом не знают, так как сетевой поток ими не зафиксирован.
Что мы используем сейчас?
После полученного опыта работы с nfdump и OSU Flow Tools и по мере перехода на IPv6 и Netflow 9-й версии мы стали искать инструмент, лишенный недостатков, с которыми мы столкнулись. Им стало решение Stealthwatch компании Lancope, которую мы позже приобрели и она стала частью Cisco. Stealthwatch построен по классической для любого анализатора архитектуре “сенсор — коллектор — анализатор”.
В качестве сенсоров мы используем нашу сетевую инфраструктуру, которая пропуская через себя весь внутренний сетевой трафик, транслирует его в Netflow и передает на коллекторы для анализа. Как я уже писал выше, не всегда сетевое оборудование поддерживает Netflow или способно его эффективно обрабатывать. Для этой задачи мы используем отдельные аппаратные или виртуальные FlowSensor (всего их у нас 13). Учитывая территориально-распределенную инфраструктуру Cisco мы сводим все потоки не на один или два коллектора, а целый распределенный кластер из 21 FlowCollector, которые обрабатывают около 20 миллиардов потоков Netflow каждый день в поисках вредоносной активности в нашей корпоративной магистрали и ЦОДах. А консолей у нас всего две — к ним имеют доступ сотрудники службы реагирования на инциденты Cisco в соответствие со своими ролями
Use case
Пожалуй, основным препятствием к эффективному применению open source инструментов мониторинга Netflow в нашей сети (да ив ообще) послужило отсутствие у них нормальной аналитики. Они обладают гибкими средствами фильтрации и выборки, но без человека они не способны принять решение о наличии или отсутствии проблемы в сетевых потоках. Stealthwatch был лишен этого недостатка — ключевым его достоинством было наличие встроенной базы алгоритмов, позволяющих оценивать Netflow и распознавать в нем различные нарушения безопасности — сканирование сети, DoS, распространение вредоносного кода, утечка информации и т.п.
Ключевые сценарии, в которым мы задействуем Stealthwatch (на самом деле их больше):
- проведение расследований
- обнаружение взаимодействия с C&C
- обнаружение DoS-атак
- обнаружение утечек данных
- проверка настройки правил разграничения межсетевого доступа.
Netflow — идеальный источник информации при расследовании инцидентов, который содержит всю необходимую информацию о том, кто и что, когда и какие действия осуществлял. При этом вся эта информация хранится в базе данных и сотрудники службы реагирования могут делать необходимые запросы к ней, осуществляя фильтрацию и выборку по нужным полям, быстро находя ответы на свои вопросы. Интеграция с Cisco ISE дает информацию не только с привязкой к IP-адресам узлов, участвующих в инциденте, но и с привязкой к учетным записям пользователей компании в Active Directory. Последняя возможность является не только удобной, но и существенно сокращает время на сопоставление имени пользователя с его динамическим IP-адресом, который был у него в интересующий момент времени. Сокращение времени — это критический фактор успеха в расследовании инцидентов.
Вторым кейсом, который показывает мощь Stealthwatch, является обнаружение взаимодействия с командными серверами ботнетов и вредоносных программ. Казалось бы, это может быть сделано и на периметре, но давайте вспомним то, с чего начиналась эта заметка. Атаковать пользователя сегодня можно кучей разных способов и далеко не всегда через периметр. Что, если шифровальщик пробрался внутрь сети через незащищенный Wi-Fi и через него же происходит утечка информации или получение обновлений для вредоносного кода? Зафиксировать это можно только путем мониторинга внутреннего сетевого трафика и Stealthwatch тут незаменим. Раньше мы эту задачу осуществляли с помощью nfdump, но у него было одно ограничение — приходилось в ручном режиме обновлять список IP-адресов командных серверов, собирая его из разных источников. В случае с Stealthwatch эта задача решается автоматически — он сам регулярно подгружает обновленные индикаторы компрометации, содержащие информацию о серверах управления. Полезность этой функции еще и в том, что она отслеживает устаревание адресов из списка и удаляет их по мере необходимости. В случае с nfdump приходилось делать это вручную, что отнимало драгоценное время.
Обнаружение атак “отказ в обслуживании” — еще один популярный use case, который мы применяем у себя в сети. Нельзя сказать, что такие инциденты происходят регулярно, но бывает. “Наводнения”, “шторма”, “лавины” запросов по различным сетевым и прикладным протоколам достаточно легко детектируются с помощью Stealthwatch.
Решения класса Network Traffic Analysis, к которым относится и Stealthwatch, не обладают DLP-функционалом и не способны мониторить содержание переписки по различным протоколам. Однако при этом они способы бороться с утечками информации, для чего используется немного иной принцип. Учитывая, что в рамках Netflow можно отслеживать объем передаваемой информации, то мы можем для каждого узла или пользователя установить некие усредненные значения объема информации по разным протоколам, которые может загрузить из Интернет или выгрузить в Интернет пользователь. Допустим, для протокола HTTP эта цифра будет равна 100 Мб в сутки.
Соответственно превышение этого значения будет считаться аномалией, а существенное превышение, например, в 5 раз и более, явным нарушением политики ИБ. Выгрузка больших объемов данных в облачные хранилища может означать, что пользователь пытается украсть конфиденциальную информацию. Разумеется, я не зря использую слово “может”, так как это может быть и признаком вполне легальной активности, например, пользователь передает через облако новый дистрибутив ПО или набор документов или видео-тренинг. В любом случае срабатывание тригера на превышение пороговых значений данных должно стать причиной для проведения расследования.
Еще одним сценарием, который мы активно используем в своей сети применительно к Stealthwatch, является проверка настройки правил разграничения доступа для отслеживания неразрешенного между сегментами трафика. Сегментация — один из полезнейших инструментов в арсенале служб ИБ, который позволяет существенно снизить площадь атаки, локализовывать проблемы, оперативно проводить расследования и т.п. У нас в сети сегментация активно используется на базе сетевого оборудования, а управляет ею Cisco ISE. С помощью Stealthwatch мы проверяем корректность настроек сегментации и видим трафик, который не должен появляться в том или ином сегменте.
Эта же возможность позволяет проверять и корректность настроек межсетевых экранов, стоящих на периметре и, возможно, пропускающих какой-то неразрешенный трафик. По сути Stealthwatch в данном use case превращается в дополнительный инструмент контроля действий администраторов.
Кто и где использует Stealthwatch?
Stealthwatch является решением, которое хотя и может применяться сетевиками и айтишниками, но предназначено для безопасников. В Cisco им занимается служба реагирования на инциденты Cisco CSIRT. Мы собираем данные с 180 ключевых сетевых устройств, установленных в центрах обработки данных, крупных корпоративных хабах и в DMZ, получая примерно 180 тысяч потоков в секунду.
В одной из прошлых заметок я уже писал о наличии API в наших продуктах. Такой API есть и в Stealthwatch и он очень активно используется нашей службой реагирования на инциденты. В частности именно через API мы обновляем информацию об узлах, включенных в те или иные группы.
Именно через API мы обновляем информацию о новых вредоносных узлах, взаимодействие с которыми отслеживается с помощью Stealthwatch. С помощью API мы интегрируем Stealthwatch с используемой у нас open source платформой Threat Intelligence CRiTS. Это позволяет нам при получении данных о новых индикаторах компрометации раздать эту информацию по всем средствам защиты, интегрированным с CRiTS через API.
API же позволяет собирать из Stealthwatch нужные нам события и потоки для передачи их в Splunk, который является основным средством мониторинга в Cisco, в том числе и для проведения более детальных расследований.
Интересным опытом, который я пока больше нигде не встречал, является концепция мобильного SOC (Security Operations Center), который мы используем для мониторинга ИБ на удаленных площадках, покупаемых нами компаний, новых заводах, партнерах или при проведении расследований на площадках, которые не подключены на центральную систему мониторинга. Мобильный SOC — это перевозимая стойка с ИБ-оборудованием, которое включает в себя не только Stealthwatch, но и Netflow Generation Appliance, Splunk, Firepower, Web Security Appliance и т.п.
Планы развития
Мы не останавливаемая на достигнутом и планируем достаточно активно развивать применение Stealthwatch в нашей инфраструктуре. Среди первоочередных планов:
- Продолжение интеграции с ISE не только для получения контекстной информации об узлах и пользователях, участвующих в инциденте, но и для реализации функции блокирования. В перспективе через ISE должна быть реализована связка Stealthwatch на уровне сети и AMP4E на уровне ПК, что позволит оперативнее локализовывать проблемы с ИБ.
- По мере перехода на новую версию Stealthwatch автоматически появится функций Encrypted Traffic Analytics, позволяющая детектировать вредоносный код в зашифрованном трафике.
- Внедрение Stealthwatch Cloud для мониторинга облачных платформ IaaS и PaaS, которые активно используются в Cisco.
- Интеграция с AnyConnect, который внедрен у каждого сотрудника Cisco на его ноутбуке, смартфоне или лэптопе, для того, что получать данные об активности пользователей и приложений в формате Netflow и корреляции этой информации с Netflow на сетевом уровне.
В целом надо признать, что анализ Netflow с помощью Stealthwatch помогает нашей службе ИБ обнаруживать больше инцидентов, чем обычный набор средств защиты, используемый на периметре корпоративной сети. Можно отследить динамику изменения источников данных об инцидентах, которые у нас происходят. Если раньше это было преимущвестенно сигнатуры атак от IDS, то сегодня на этот источник приходится только пятая часть всех инцидентов. Еще одна пятая часть приходится на поведенческий анализ, 40% на индикаторы компрометации. Обнаружение оставшихся 20% инцидентов базируется именно на Netflow.
Дополнительная информация:
— история успеха «Stealthwatch в Cisco» (англ.)
— рассказ о применении Stealthwatch в Cisco от руководителя CSIRT (видео, англ.)
— страница Stealthwatch на сайте Cisco
