Глава 9. Применение анализа поведения и выявление аномалий

Просмотр сетевого обмена может выполняться несколькими способами, например, такими:

Давайте рассмотрим сведения, которые мы способны получать от каждого из них:

Хотя некоторые и считают SNMP устаревшим, он по- прежнему остаётся наиболее популярным инструментом управления сетевой средой. SNMP основан на модели управляющий - агент, в которой система управления (в терминологии SNMP менеджер) отслеживает устройства, получая сведения от агента SNMP, взаимодействующего с устройством коммуникации.

Существуют два способа, которыми менеджеры SNMP (система управления) получает информацию от конкретного агента, контурно, это:

Для обоих вариантов применения имеются некоторые настройки для улучшения нашей сетевой безопасности.

 

Опрос SNMP - что настраивать

При опросе SNMP система управления периодически опрашивает своих отслеживаемых агентов, снабжая нас статистическими сведениями по параметрам мониторинга. Отслеживаемыми параметрами могут быть показатели обмена, такие как биты/ пакеты/ ошибки /сек (в секунду) интерфейса, данные оборудования, например, загрузка ЦПУ (central processing unit), использование памяти, жизнеспособность устройства питания, температура и прочее.

Перечислим рекомендуемые для отслеживания параметры:

Давайте взглянем на следующую схему:

В этой сетевой среде мы отслеживаем тот интерфейс в своём центральном офисе, который развёрнут в сторону подразделений (удалённых офисов) - то есть интерфейс WAN-VRF (wide-area network - virtual routing and forwarding, глобальной сети - виртуальной маршрутизации и перенаправления).

В этом интерфейсе мы наблюдаем что имеются внезапные скачки в обмене, исходящем из центра обработки данных (ЦОД) в сторону удалённых офисов. Это отображено на снимке экрана ниже:

Мы видим, что на этом графике за два дня имеется небольшой обмен исходящий из данного интерфейса (розовая линия), в то время как 1/12 (1 Декабря по европейской нотации) в 19:30, когда наши удалённые офисы закрыты, обмен возрастает до 18 Mbps (Мегабит в секунду) на короткий промежуток времени.

Увеличивая на этом графике масштаб, мы видим, что этот пик происходит через несколько минут после 19:30, причём этот обмен слегка превышает 18 Mbps, что иллюстрирует наш следующий снимок экрана:

В своём следующем разделе мы рассмотрим как мы можем обнаружить что его вызывает.

 

Ловушки SNMP - что настраивать

Ловушки это инициируемые устройством взаимодействия при определённом событии сообщения. Ловушки способны вырабатываться различными категориями событий (в зависимости от реализации производителя), например, такие:

Для дополнительных сведений относительно SNMP вы можете ознакомится с разделом Атаки брутальной силой против паролей SNMP (общих строк) из Главы 7, Поиск атак на основе устройства.

Для настройки ловушки аутентификации в Juniper отсылаем вас к их документации. То же самое для Cisco.

После SNMP давайте взглянем на следующий метод, при помощи которого вы способны получать сведения по нестандартному обмену, который способен вызывать подозрения.

NetFlow это введённая в середине 90-х Cisco функциональная возможность, которая применяется для сбора сведений Уровня 3 и Уровня 4. Применяя протокол NetFlow, соответствующий маршрутизатор собирает сведения Уровня 3 (то есть IP адреса источника и получателя) и Уровня 4 (или номера портов источника и получателя TCP - Transmission Control Protocol либо UDP - User Datagram Protocol) и отправляет эту информацию в коллектор NetFlow системы управления, в котором вы можете наблюдать статистические данные длительного периода времени для общения данного конкретного интерфейса маршрутизатора.

Позднее были предложены некоторые иные аналогичные NetFlow протоколы: JFlow от Juniper Networks, SFlow для мониторинга коммуникаторов Уровня 2 и некоторые прочие. Сам по себе NetFlow был опубликован в качестве RFC (Request for Comments, Приглашения к обсуждению) в RFC 3954: Cisco Systems NetFlow Services Export Version 9, позднее заменённом протоколом IPFIX, который основывался на версии 9 NetFlow и поддерживаемый большинством ведущих производителей для сбора сведений Уровня 3 и Уровня 4. Приводимый ниже снимок экрана отображает график обмена NetFlow:

Сосредотачиваясь на обмене между двумя сторонами (то есть на взаимодействии между ними), мы можем обнаружить, что 1 Декабря 2020 года, между 19:15 и 19:30 мы имели отправленными от 23.221.29.227 к 172.30.131.1 190 MB (мегабайт) и 34 MB отправленными с 82.102.180.147 тому же получателю.

Теперь, ознакомившись со всем этим, пришло время проверить что выступает теми серверами, с которых внутренние хосты скачивают данные. Давайте взглянем:

Проверяя IP адрес 23.221.29.227, с которого шёл самый интенсивный обмен, мы видим, что он поддерживается Akamai, а проверка того что он занесён в сайты чёрных списков не возвращает никаких уведомлений, поэтому с ним нет никаких проблем.

Аналогичным образом вы можете проверять любой прочий вызывающий подозрения обмен.

Wireshark это самый знаменитый в мире анализатор сетевого протокола. В Wireshark имеются различные средства, которыми можно пользоваться для выявления аномалий. Давайте взглянем на них.

 

Оконечные устройства и переговоры

Одним из самых первых подлежащих выполнению моментов заключается в просмотре того кто общается в вашей сетевой среде. Мы можем выполнять это из меню Endpoints или Statistics. Давайте взглянем на приводимый ниже образец:

То что мы наблюдаем, это перечень адресов IP и список пакетов, которые были отправлены с них или к ним. Разрешая их и проверяя их имена DNS (Domain Name System) покажет нам что они обозначены как подозрительные (suspect) или же что всё прекрасно. Мы также видим номера портов UDP и TCP, а потому мы сосредоточимся на них в окне Conversations.

Для разрешения полученных адресов мы можем воспользоваться стандартной службой разрешения https://www.findip-address.com/ или аналогичной, к тому же вы обладаете средством разрешения адресов в пакета . В нашем следующем примере я пользуюсь инструментом с https://www.nirsoft.net/. То что я получил отражено на приводимом далее снимке экрана (частичный список):

Из Рисунка 9.7 мы можем видеть, что все разрешённые адреса происходят от таких служб как Google, Amazon и Microsoft OneDrive. Cloudfront.net, служба распространения веб содержимого, это также площадка Amazon; из https://main.whoisxmlapi.com/ мы можем обнаружить, что это сервер Amazon, физически располагающийся в Тель Авиве, Израиль.

В меню Conversations из меню Statistics мы можем обнаружить кто с кем общается и по каким номерам портов они это осуществляют. Давайте взглянем на следующий пример:

На Рисунке 9.8 мы видим - к примеру - большое число соединений от 192.168.1.136 по различным портам, подключающимися к 192.168.1.159 по порту 52235. Поиск в Google для этого порта показывает, что это служба представления видео. Ничего удивительного в этом нет.

 

Иерархия протокола

Одним из наиболее важных предоставляемых нам Wireshark инструментов для выявления аномалий сетевого обмена выступает средство Protocol Hierarchy из меню Statistics. Просматривая те протоколы, которые исполняются в нашей сетевой среде, мы можем удостоверяться в том, какие из них должны присутствовать, а какие нат и можем применять эти сведения для обнаружения аномалий. Давайте взглянем на следующий образец:

Взглянув на этот простой пример, мы можем обнаружить некоторые знакомые протоколы, чьё присутствие дома или в среде небольшого офиса объяснимо. Это QUIC (Quick UDP Internet Connections), который применяется при подключениях к Google Drive; NetBIOS (Network Basic Input/Output System) и SMB (Server Message Block), которые являются распространёнными протоколами, используемыми для служб обнаружения и совместного использования файлов; а также TLS (Transport Layer Security) и HTTP (HyperText Transfer Protocol), задействованные для браузеров.

Двумя протоколами, которые не применяются широко дома и малых сетях это Virtual System Simulator (VSS) Monitoring и STUN (Session Traversal Utilities for NAT).

Для VSS Monitoring кликните правой кнопкой по строке со STUN в окне Protocol Hierarchy, что даст вам такие пакеты:

На Рисунке 9.10 мы видим, что 192.168.1.190 отправляет пакеты 192.168.1.136 и Wireshark распознаёт эти пакеты как HTTP.

Чтобы разобраться с данным сеансом, мы кликнем правой кнопкой по этим пакетам HTTP и выберем Follow TCP Stream. Это предоставит нам весь поток данных, с самого начала до конца, что поможет нам разобраться с тем, что здесь происходит. На совём следующем снимке экрана мы наблюдаем полученные результаты:

На приводимом далее снимке экрана мы видим что происходит в этом потоке от начала до конца:

Здесь мы видим, что одно устройство в нашей локальной сети, 192.168.1.190, соединяется с другим устройством, 192.168.1.136. Из соответствующих MAC адресов мы определяем, что это устройство от производителя с названием Advanced, а разрешая его MAC адрес, мы обнаруживаем, что этим производителем является Advanced Digital Broadcast SA, Шведский производитель, который выпускает программное обеспечение и устройства для Платного- ТВ (телевидения на основе подписки). Это выглядит так, что данное кабельное телевидение пытается подключаться к моему ноутбуку, а мой ноутбук отвергает его применение.

Второй протокол, который запущен здесь без разумного на то основания это STUN. Заглядывая в окно Protocol Hierarchy, мы обнаруживаем, что у нас имеются STUN поверх TCP, а также STUN поверх UDP.

STUN это применяемый для сетевых клиентов позади устройства NAT (network address translation) дабы сообщать некому внешнему серверу VoIP (Voice over IP) значение их внешнего IP адреса. Для получения сеансов STUN мы кликаем в окне Protocol Hierarchy по STUN с тем, чтобы мы наблюдали все пакеты STUN (поверх TCP или UDP), затем мы выбираем некий пакет, кликаем по нему правой кнопкой и выбираем Follow TCP Stream либо (Follow UDP Stream). Мы можем наблюдать на приводимом ниже примере снимка экрана:

Проверка того, с каким сервером я общаюсь (а именно, IP адрес 18.230.160.38), показывает мне, что это сервер Amazon в Сан Пауло, Бразилия, Amazon, ладно - я не могу себе представить причину, по которой мой ноутбук мог бы соединяться с сервером в Сан Пауло, не уведомляя меня о том.

В этом разделе мы обсудили те средства, которые мы можем применять. В своём следующем разделе мы окунёмся глубже с в причины этого.

 

Просмотр перехвата пакетов

Всегда хорошо начинать с первого взгляда на сам перехват пакета. Некоторые начальные указатели сразу взведут флаг что что-то не так. Перечислим часть из этого:

В данном разделе мы обсудили средства и методы сбора, применяемые для коллекции сведений, которые помогут нам при построении базового уровня. В своём следующем разделе мы рассмотрим базовые уровни и то как их создавать.

Установление базового уровня это необходимая для выполнения вами задача. Это может казаться очень сложным, но очень просто когда вы знаете свою сетевую среду. В данном разделе мы обсудим распространённые протоколы, а также мы рассмотрим их типичные шаблоны обмена.

Общие для корпоративных сетевых сред протоколы могут быть подразделены на различные группы следующим образом:

Давайте рассмотрим некоторые типичные файлы перехвата и выясним что нам следует видеть в сетевых средах организации.

На приводимом ниже снимке экрана мы наблюдаем типовую иерархию протоколов некоторого подключённого к сети организации пользователя. Давайте рассмотрим подробности:

Для Internet Protocol Version 6 мы видим несколько протоколов сетвых операций, причём без реального происходящего между ними обмена. В большинстве сетевых сред организации не существует потребности в IPv6, а потому давайте просто запретим его в ПК и серверах. Когда необходим IPv6, требуется включить такие протоколы:

Для Internet Protocol Version 4 мы наблюдаем UDP и TCP. Для начала давайте рассмотрим протоколы для UDP:

Для TCP у нас имеются такие распространённые протоколы:

В самом конце своего окна Protocol Hierarchy мы также наблюдаем IGMP (Internet Group Management Protocol) и ARP (Address Resolution Protocol), причём оба являются сетевыми протоколами.

Другим приложением Wireshark является окно Statistics | Conversations, в особенности для протоколов TCP и UDP. Это мы наблюдаем на следующем снимке экрана:

В этом окне статистических данных сеансами TCP слева и с сеансами UDP справа, мы наблюдаем соответствующие переговоры. Мы видим что имеются подключёнными большое число вебсайтов, к которым мы подключены на регулярной основе, причём большое число запросов DNS к соответствующему маршрутизатору/ межсетевому экрану, которые также действуют как сервер DNS. Всё это обычная практика. Теперь давайте рассмотрим что мы можем ожидать в сетевых средах большого и среднего размеров.

На приводимом далее по тексту снимке экрана мы видим некий перехват по порту межсетевого экрана ЦОД, или обмен от пользователей организации к серверам своего ЦОД. Прежде всего, мы рассматриваем обмен, проводимый UDP на следующем примере:

В этих статистических данных мы сосредоточимся на обмене поверх UDP мы наблюдаем такие протоколы:

Для SIP, когда мы кликнем правой кнопкой по нему, и выберем Apply as Filter | Selected, мы получим такое окно:

Проверяя сайт разрешения имён (я проверял по whatismyipaddress.com, но имеется множество аналогичных веб площадок, которыми вы можете воспользоваться), мы видим, что наш внешний адрес относится к Partner Communications, который выступает ISP (internet service provider, Поставщиком Интернет услуг). Кликая по Check Blacklist Status, убеждаемся что он OK, как вы можете наблюдать на приводимом ниже снимке экрана:

Следующим моментом для проверки является то, какое приложение запущено на этом локальном устройстве и применяет ли оно SIP. Убедитесь что вы знаете что это. Вы можете сделать это просто нажав Ctrl + Alt + Del и изучив запущенные в вашем ПК приложения и процессы. В случае Linux вы можете осуществить это при помощи ps -a.

В части окна TCP мы наблюдаем такие протоколы:

Здесь мы видим такие виды обмена:

Теперь давайте посмотрим как мы сосредотачиваемся на конкретном сеансе. Скажем, мы желаем найти подробности локальной безопасной авторизации, которая происходит под DCE/RPC в нашем протоколе TCP. Мы наблюдаем это на следующем примере:

Чтобы получить сведения сеанса, следуйте этим шагам:

Теперь давайте сосредоточимся на некоторых образцах вызывающих подозрение шаблонов.

Вирусы, Трояны, черви, программное обеспечение (ПО) вымогателей и прочие типы вредоносного ПО могут быть запущенными в оконечных пунктах - именно против них нацелены ПО безопасности оконечного оборудования и системы защиты, но с ними имеются две основные проблемы.

Первая проблема состоит в том, что когда такое вредоносное ПО захватывает ваше оконечное устройство, оно сражается на своих подступах - то есть, скажем, вы боретесь с ним, когда оно уже достигло ваших устройств. В большинстве ситуаций вы победите в такой войне, однако если это не так, зло проникло в ваш дом.

Во- вторых, более распространённая проблема заключается в том, что не все устройства могут быть защищены стандартными системами безопасности оконечных устройств. У вас нет возможности устанавливать антивирус на свой датчик IoT; некоторое используемое ПО обладает открытым исходным кодом, что не даёт никаких гарантий и, хотя система NAC (network access control, сетевого контроля доступа) предоставляет некие гарантии пользователям, когда они подключаются к своей сетевой среде, вы никогда не можете быть на 100% уверенными что частный телефон или ноутбук не заражены.

По этой причине одним из новых подходов в сетевой безопасности выступает мониторинг вашей сетевой среды и проверка рисков прежде чем будут заражены оконечные устройства, основная цель состоит в выявлении подозрительного обмена и блокирования его источника прежде чем произойдут какие- то разрушения. Именно этим мы занимаемся в данном разделе.

Шаблоны подозрительного обмена могут иметь много разновидностей. Это могут быть шаблоны сканирований, при которых вы наблюдаете нечто сканирующее вашу сетевую среду, неизвестные адреса, которые появляются в вашей сетевой среде, незнакомые номера портов TCP и UDP, неизвестные строки, появляющиеся при обмене и многое иное. Давайте рассмотрим всё это поближе.

Шаблоны сканирования могут быть разных типов. Мы пройдёмся по ним от простейших к наиболее сложным.

 

Сканирования ARP и ICMP

Сканирования ARP и ICMP (Internet Control Message Protocol) это простейшие сканирования и они достаточно просто выявляются. Мы обсуждали это в Главе 6, Атаки на основе анализа сетевой среды, сетевых устройств и обмена. При подобных сканированиях вы обнаружите большое число пакетов ICMP без какой бы то ни было причины на их присутствие, или же большое число пакетов ARP, охватывающих вашу сетевую среду. Проверьте источник таких пакетов и ту причину, по которой они отсылались.

 

Сканирования TCP

Сканирования TCP отправляются с целью открыть TCP порты мишени и, при их обнаружении, будут применяться иные средства для эксплуатации таких уязвимостей и прорыва в них. Сканирования TCP обладают простым видом. Давайте ближе рассмотрим их на своём следующем снимке экрана:

То что мы наблюдаем, так это то, что хост 192.168.1.101 отправляет пакеты TCP/ SYN по различным портам 192.168.1.101, а он блокирует их при помощи TCP/SYN/RST.

 

Сканирования HTTP

Сканирования HTTP, как правило, применяют команды HTTP GET и PUT, которые отправляются к некому серверу HTTP для получения сведений от этого сервера или записи в него информации. На приводимом ниже снимке экрана вы можете наблюдать типичное сканирование HTTP:

Вы видите, что 10.0.0.1 безуспешно пытается получить содержимое от 54.154.213.203. Когда это реальный запрос GET HTTP от реального клиента и сервера, мы бы наблюдали запросы и отклики, а не запросы GET HTTP произвольных страниц.

Иной тип сканирования можно лицезреть на приводимом ниже снимке экрана. То что привлекло моё внимание, так это значение числа пакетов SYN, которые отправляются без получения отклика различным адресам IP назначения по порту 8080 TCP (веб прокси):

При фильтрации некоторых потоков (после правого клика по некому пакету и выбору Follow TCP Stream), я обнаруживаю следующее:

Что примечательно, так это то, что наблюдаемые запросы для открытия соединения POST отправлялись с одной и той же строкой /83736aa6/806782973 ко всем получателям, к которым осуществлялась попытка TCP, причём в некоторых ситуациях успешно.

Поэтому я выполнил поиск Google данной строки и не был удивлён обнаружив следующее:

Похоже, что кто- то нашёл это раньше меня. Это ботнет — сокращение от roBOT NETwork, сеть компьютеров, заражённых вредоносным ПО, находящаяся под контролем одной атакующей стороны.

 

Атаки грубой силой

В разделе Атаки в плоскости управления и как обороняться от них из Главы 7, Поиск атак на основе устройства, мы уже видели, что такие атаки перебором пользуются допущениями для попытки прорыва в вычислительные или сетевые устройства. По этой причине имеется возможность наблюдать такие пакеты когда они поступают из сетевой среды. Давайте рассмотрим некоторые примеры. Один из представляемых здесь это атака грубой силой, имеющая целью сервер DNS с попыткой получения IP адресов серверов организации:

Здесь мы наблюдаем как злоумышленник пытается обнаружить серверы в corrm.co.il (это не реальное имя, а потому оно не даст вам шансов для атаки этих целей). Злоумышленник пробует обнаружить нечто, отвечающее по www.corrm.co.il, по sql.corrm.co.il и так далее. Когда что- то отвечает, этот злоумышленник может двинуться далее в своей атаке. Что может сделать злоумышленник с этими сведениями? Мы рассмотрим это в последующих главах, когда обсудим протоколы более подробно.

 

Проблемы электронной почты

При обмене электронной почтой мы как правило наблюдаем электронные письма, которые вы не ожидали получить. На приводимом ниже образце вы можете наблюдать нечто подобное:

Вы можете видеть здесь письма, получаемые с адресов в cl (Chile - Чили), пользователя, от которого мы не ожидаем каких бы то ни было электронных писем. К тому же, имеются сотни электронных писем (естественно, то что вы наблюдаете на Рисунке 9.29, это лишь пример), появляющихся от неизвестных имён и адресов.

Когда вы рассмотрите обмен по этому подключению POP, вы также можете обнаружить, что нечто лишено смысла. На приводимом графике I/O (input/ output, ввода/ вывода), отображаемого на следующем снимке экрана, вы видите подключение, длящееся 80 секунд, причём с сотнями пакетов, распространяемых за это время. Обычно вы наблюдаете отправляемые или получаемые от отдельного пользователя электронные письма за значительно менее короткое время:

Суммируя данный раздел, именно это подразумевает некий базовый уровень. Когда данный пользователь выгружает электронную почту за несколько секунд, нет никаких причин для того, чтобы обмен длился 80 секунд по одному и тому же соединению. Если мы привыкли наблюдать почтовые соединения длящимися несколько секунд, нет никакого смысла в продолжающихся 80 секунд соединениях.

В данной главе мы обсудили обнаружение подозрительных шаблонов обмена в сетевой среде. Наиболее значимый вывод из данной главы заключается должно состоять в том, чтобы знать свои сетевые среды и поведение приложений и тогда вы будете иметь возможность распознавать необычную активность.

В этой главе мы изучили те средства, которые вы можете применять для создания базового уровня, как устанавливать базовый уровень и разбираться с тем обменом, который протекает в вашей сетевой среде, а также подозрительные/ необычные активности, о которых следует знать.

В своей следующей главе мы начнём получать более подробные сведения по протоколам для выявления атак на основе устройств, рассматривая ARP, IP и TCP/UDP.

Итак, давайте проведём ревизию изученного нами на данный момент.

Вот некоторые вопросы для проверки вашего понимания материалов данной главы: