Анализ сетевого трафика — актуальная на сегодня проблема, особенно учитывая условия удалённой работы, навязанные пандемией. Современные вредоносные программы успешно используют техники обхода белых списков и качественно скрывают свои действия в системе. Как подойти к этой непростой задаче — сетевому мониторингу? Попробуем разобраться.
- Введение
- Как обстоят дела с сетевым мониторингом
- Используем Open Source
- 3.1. Обнаружение
- 3.2. Расследование
- Выводы
Введение
Сегодня, в то время как политические ИТ-границы становятся всё более явными (государства создают целые экосистемы, включающие свой независимый интернет, свои сервисы, своё ПО), в корпоративной среде процесс прямо противоположен: периметры организаций всё сильнее растворяются в инфосфере, обеспечивая изрядную головную боль безопасникам. Тут и тяготы «удалёнки» с её недоверенной средой, и энтропия теневой инфраструктуры (Shadow IT), а на другой стороне баррикад — всё более изощрённые методы из цепочки угроз (kill chain) и тщательное сокрытие своего присутствия. Стандартные средства ИБ-мониторинга не могут дать полную картину происходящего, что побуждает искать дополнительные источники информации — и в первую очередь анализировать сетевой трафик.
На смену концепции «Bring Your Own Device» (личные устройства в корпоративной среде) внезапно пришла «Work From Your Home Device» (корпоративная среда на личных устройствах), чему немало поспособствовала пандемия. Доступ к виртуальному рабочему месту, почта и второй фактор аутентификации для доступа к VPN на личном телефоне, корпоративный ноутбук в недоверенной / домашней сети на расстоянии нуля переходов до заражённых компьютеров или IoT — всё это заставляет безопасников менять «религию» и уходить в «Zero Trust-радикализм».
Никуда не делся (а с приходом микросервисов — только усилился) и рост разношёрстных Shadow IT вкупе с их трансформацией. В организациях не успевают покрывать антивирусами / средствами обнаружения и обработки угроз на конечных точках (EDR) легитимные рабочие станции и следить за этим покрытием, а уж тёмный уголок инфраструктуры становится настоящим «Доном», откуда «нет выдачи» событий из области ИБ, заражённых объектов и вообще каких-либо сведений для мониторинга информационной безопасности. Такая область неопределённости, безусловно, мешает реагированию на возникающие инциденты.
Головокружение от SIEM прошло. У всех, кто хочет понимать, что у них происходит с информационной безопасностью, SIEM стал краеугольным камнем и «всевидящим» оком одновременно. Кавычки у слова «всевидящее» обусловлены как Shadow IT, так и тем, что SIEM из-за ресурсных и логических лимитов видит только те журналы, которые ему присылает ограниченное количество источников (к тому же подверженных отключению злоумышленниками).
Наблюдается рост количества установщиков вредоносного содержимого, использующих цепочки вызовов легальных утилит, уже расположенных на хосте: rgsvr32.exe, wmic.exe, hh.exe и многих других, исполняющих код, который был передан им либо через командную строку напрямую, либо как интернет-ссылка, либо через файл, приведённый как аргумент.
В результате процесс установки вредоносной программы происходит в несколько итераций, чередующихся с вызовами легальных утилит, поэтому автоматические средства детектирования не успевают объединить их в целую цепочку установки опасного объекта в систему. Есть немало примеров обхода белых списков за счёт этой технологии.
Всё чаще после закрепления на поражённой рабочей станции злоумышленники весьма «ответственно» подходят к сокрытию своих действий в системе. В частности, они «умно» работают с журналированием — например, не просто чистят протоколы, а перенаправляют их во временный файл, выполняют вредоносные действия и после этого возвращают поток логов на старое место. Так им удаётся избежать срабатывания на SIEM сценария «Файл журнала очищен». При этом сетевых логов, которые могли бы помочь в обнаружении инцидентов, может и не быть, т. к. все объекты находились в одной подсети.
С помощью киберразведки (Threat Intelligence) невозможно выявлять все каналы взаимодействия с командными (C2) серверами. Для целевой атаки формируется новый атакующий «фронт» (инфраструктура) с уникальными, нигде ранее не засвеченными IP- и URL-адресами, перекомпилируются вредоносные программы. Кроме того, зачастую в потоки данных об угрозах («фиды») попадают одноразовые индикаторы атак с использованием IoT — в этом случае фид бесполезен.
Как обстоят дела с сетевым мониторингом
В настоящее время у организаций есть несколько вариантов реализации мониторинга сетевой активности: это и «навороченный» NGFW или UTM-комбайн, в составе которого может быть модуль по обнаружению атак (IDS), и различные события по сетевой активности, которые отдаются в SIEM.
В каждом из вариантов остро встаёт вопрос производительности. В NGFW и UTM из-за высокой нагрузки IDS-модуль часто попросту отключают. Кроме того, при обсуждении средств выявления атак зачастую имеется в виду именно сигнатурный анализ, а современные злоумышленники, как мы определили выше, уже умеют обходить такие меры. В большинстве платформ Ransomware-as-a-Service (программа-вымогатель как услуга) эта опция идёт «из коробки». В случае с SIEM, которая и так обрабатывает значительное количество событий в секунду (EPS) от несетевых источников, зачастую приходится жертвовать некоторыми правилами корреляции или кратно увеличивать стоимость аппаратных ресурсов.
Эти причины подводят нас к мысли о необходимости обособленного решения по обеспечению сетевого мониторинга и анализа сетевой активности как на периметре, так и в сегментах корпоративной сети. При этом основные направления ИБ, нуждающиеся в таком решении, — это обнаружение атак и цифровая криминалистика.
Используем Open Source
Сегодня есть как минимум три решения с открытым исходным кодом (Open Source), с помощью которых можно проверить гипотезу об эффективности мониторинга сетевой активности.
- Система обнаружения вторжений (IDS): Suricata, высокопроизводительный сетевой инструмент IDS и IPS, а также механизм мониторинга сетевой безопасности. Suricata разрабатывается организацией Open Information Security Foundation (OISF) и поддерживающими её поставщиками.
- Глубокая проверка пакетов (DPI): Zeek, система анализа трафика и выявления сетевых вторжений, ранее распространявшаяся под именем Bro. Zeek 3.0.0 представляет собой платформу для анализа трафика, ориентированную в первую очередь на отслеживание событий, связанных с безопасностью, но не ограничивающуюся этим применением. Предоставляются модули для анализа и разбора различных сетевых протоколов уровня приложений, учитывающие состояние соединений и позволяющие формировать подробный журнал (архив) сетевой активности. Предлагается предметно-ориентированный язык для написания сценариев мониторинга и выявления аномалий с учётом специфики конкретных инфраструктур. Система оптимизирована для использования в сетях с большой пропускной способностью. Предоставляется API для интеграции со сторонними информационными системами и обмена данными в режиме реального времени.
- Высокомасштабируемая система для захвата сетевых пакетов (Large Scale Packet Capture System): Moloch. Способна разбирать (парсить) и индексировать миллиарды сетевых сессий, предоставляя чрезвычайно быстрое и простое веб-приложение для навигации по обширным коллекциям PCAP-файлов, заключающих в себе IP / GeoIP / ASN / hostname / URL и т. д. Может использоваться для захвата трафика в реальном времени, а также в качестве сетевого криминалистического (forensic) инструмента при расследовании инцидентов.
Рассмотрим три примера, которые попытаемся переложить на Open Source.
Обнаружение
Задачи выявления злонамеренной активности делятся по типу используемых злоумышленником инструментов. Приведём несколько примеров.
Известные хакерские утилиты
Это, в частности, — эксплойты для уязвимости RDP Windows CVE-2019-0708 (Blue Keep), которая эксплуатируется в легитимных процессах. Обнаружить их по событиям в SIEM можно только косвенно — а с помощью сигнатурного анализа проходящего трафика (IDS, Suricata) выявить эксплуатацию известных уязвимостей вполне реально.
Модифицированные вредоносные программы со своими протоколами
Для выявления вредоносных программ нужно использовать алгоритмы определения скрытых DNS-, HTTP-, SMTP- и ICMP-туннелей, которые злоумышленники используют для кражи данных, связи между командным сервером и агентом, а также для сокрытия своей активности от средств защиты. Кроме поиска скрытых туннелей сетевое СЗИ должно иметь возможность создания и использования собственных алгоритмов определения схожести вкупе со статистическими методами — например, как это делается в Zeek.
Инструменты удалённого администрирования (RAT) и протоколы управления — RDP, SSH
Зачастую злоумышленники используют легитимные утилиты удалённого администрирования, которые в системе разрешены, пусть и только администраторам. Есть ещё необходимость контролировать использование VPN-туннелей, TOR, прокси-серверов, мессенджеров — всего того, что обычно запрещено политиками ИБ в крупных компаниях. Эта задача осложняется тем, что для выявления аномальной активности и использования неспецифичного ПО для пользователей хотелось бы реализовывать профилирование активности, чего нет ни в одной опенсорс-системе.
Расследование
Кроме реагирования на компьютерные атаки в режиме реального времени остаётся ещё большой пласт препятствий при расследованиях компьютерных инцидентов. Квалифицированные злоумышленники не пренебрегают очисткой журналов и скрытием своих действий после проведения операции (или своего присутствия в инфраструктуре жертвы).
Требуется новый источник данных для расследований или подтверждения существующих гипотез, и всё чаще он находится внутри сетевого трафика. Исходя из нашего опыта, для проведения расследования нужно средство, которое может взять существующие PCAP, быстро развернуться в инфраструктуре заказчика, заранее накапливать весь трафик, проходящий внутри сети, и быстро дать информацию о том, что происходило — например, граф связи, но в более практичном виде. Такую функциональность удобнее реализовывать в LSPCS Moloch.
Для проведения оперативных мероприятий в области криминалистики очень хочется иметь возможность писать диссекторы / плагины, например для ретроспективной расшифровки команд управления во втором примере из раздела «Обнаружение».
Говоря о расследовании инцидентов, нельзя не отметить, что для субъектов ГосСОПКА — в соответствии с п. 8.6.3 «Методических рекомендаций по созданию Центров ГосСОПКА» — при передаче информации о компьютерной атаке центр ГосСОПКА должен обеспечить хранение трафика, в котором была обнаружена компьютерная атака, а также всех событий по информационной безопасности средств защиты и средств ГосСОПКА на срок не менее 6 (шести) месяцев.
Для компаний финансовой сферы, в свою очередь, актуальны следующие требования из ГОСТ Р 57580.1-2017:
- РИ.17 Обеспечение возможности доступа к информации об инцидентах защиты информации в течение трёх лет;
- РИ.18 Обеспечение возможности доступа к информации об инцидентах защиты информации в течение пяти лет.
Выводы
Ввиду описанных выше проблем становится ясно, что для обнаружения действий злоумышленников внутри периметра нужны инструменты уровня EDR, но для сети — т. е. NDR, которые не только содержат правила Suricata из 90-х годов, но и отвечают современным требованиям по обнаружению угроз (в том числе по комбинации методов их выявления), глубокому анализу трафика, хранению данных для расследования и ретроспективного изучения.
Такой набор функций можно реализовывать самостоятельно: построить систему на приведённых здесь решениях с открытым исходным кодом, поддерживать её и получить тем самым функциональность, которая объединена в относительно новом классе СЗИ под названием «средства анализа сетевого трафика» (Network Traffic Analysis, NTA). Gartner называет этот класс решений одним из краеугольных камней современного SOC, наряду с SIEM и EDR.
Если брать наши реалии, то NTA закрывает сразу несколько мер защиты из 239-го приказа ФСТЭК России:
VII. Предотвращение вторжений (компьютерных атак) (СОВ)
ЗИС.3 Эшелонированная защита информационной (автоматизированной) системы ЗИС.19 Защита информации при её передаче по каналам связи ЗИС.28 Исключение возможности отрицания отправки информации ЗИС.29 Исключение возможности отрицания получения информации ЗИС.31 Защита от скрытых каналов передачи информации
ИНЦ.1 Выявление компьютерных инцидентов ИНЦ.6 Хранение и защита информации о компьютерных инцидентах
ДНС.5 Анализ возникших нештатных ситуаций и принятие мер по недопущению их повторного возникновения
Внедрение системы NTA — закономерный и естественный процесс, но он требует серьёзной квалификации, которую, учитывая усиливающийся кадровый голод, часто неоткуда брать даже в SOC и департаментах ИБ высокого уровня зрелости. Классическим выходом может стать получение NTA по MSSP-модели или долгосрочный проект по трансляции экспертизы.
