Автор: Miroslav Stampar

URL: https://github.com/stamparm/maltrail

Перевод официальной документации Maltrail — системы обнаружения вредоносного трафика.

Введение

Maltrail — система обнаружения вредоносного трафика на Python, используя общедоступные (черные) списки, содержащие вредоносные или подозрительные ссылки, вместе со статическими списками, собранными из различных отчетов AV и определяемых пользователем, где ссылка может быть чем-либо от доменного имени (например, zvpprsensinaix.com для вредоносного программного обеспечения Banjori), URL (например, http://109.162.38.120/harsh02.exe для известной вредоносной исполнимой программы), IP-адрес (например, 185.130.5.231 для известного атакующего) или значение заголовка HTTP User-Agent (например, sqlmap для автоматической инжекции SQL). Кроме того, maltrail использует дополнительные усовершенствованные эвристические механизмы, которые могут помочь в открытии неизвестных угроз (например, новое вредоносное программное обеспечение).

Архитектура

Maltrail имеет трехзвенную архитектуру: сенсор <-> сервер <-> клиент.  Сенсор — автономный компонент, запущенный на контролирующем узле, который  «снифает» проходящий трафик на наличие в нем  подозрительных элементов (таких как. доменные имена, url или ip). В случае положительного совпадения сенсор отправляет детали события на сервер, где они сохраняются в лог (LOG_DIR, описанный в разделе Configuration). Когда сенсор выполняется на той же машине где и сервер (конфигурация по умолчанию), логи сохранеяются непосредственно в локальный каталог , иначе, они отправляются с помощью сообщений UDP на удаленный сервер (LOG_SERVER, описанный в разделе Configuration).

 

Основная задача сервера сохранить детали события и предоставить поддержку бэкэнда для веб-приложения создания отчетов. В конфигурации по умолчанию сервер и датчик будут работать на той же машине. Для того, чтобы предотвратить потенциальные разрушения в действиях сенсора, часть создания отчетов фронтэнда основывается на архитектуре «толстого клиента» (т.е. вся последующая обработка данных делается в экземпляре веб-браузера клиента). События (записи в журнале) в течение выбранного (24 часового) периода передаются клиенту, где веб-приложение создания отчетов исключительно ответственно за часть представления. Данные отправляются к клиенту в сжатых блоках, где они обрабатываются последовательно. Итоговый отчет создается в высоко сжатой форме, практически позволяя показывать неограниченное количество событий.

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

Быстрый старт

Следующий набор команд выполнит установку и запуск  Maltrail (в системах основанных на debian) с настройками по умолчанию и контролирующий все сетевые интерфейсы.

sudo apt-get install git python-pcapy

git clone https://github.com/stamparm/maltrail.git

cd maltrail

sudo python sensor.py

Чтобы запустить сервер на той же машине, откройте новую вкладку терминала и выполните следующее:

[[ -d maltrail ]] || git clone https://github.com/stamparm/maltrail.git

cd maltrail

python server.py

Для проверки  работоспособности сделайте следующее:

ping -c 1 136.161.101.53

cat /var/log/maltrail/$(date +»%Y-%m-%d»).log

Для просмотра отчета (клиент), откройте в вашем веб-браузере (там где запущен maltrail) http://127.0.0.1:8338 (учетные данные по умолчанию: admin:changeme!)

Administrator’s guide

 Сенсор

Конфигурация сенсора находиться в файле maltrail.conf в секции [Sensor] :

Если опция USE_MULTIPROCESSING установлена в true, тогда все ядра CPU будут использоваться. Одно ядро будет использоваться только для пакетного получения, в то время как другие ядра будут использоваться для пакетной обработки. Иначе, все будет выполнено на одном ядре.

Опция USE_FEED_UPDATES может использоваться, чтобы выключить обновления списков. Опция UPDATE_PERIOD содержит число секунд между каждым автоматическим обновлением (примечание: значение по умолчанию установлено в 86400 (т.е. один день)) Опция CUSTOM_TRAILS_DIR может использоваться пользователем, чтобы обеспечить расположение каталога, содержащего пользовательские списки (*.txt) файлы.

Опция USE_HEURISTICS включает эвристические механизмы

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

Опция MONITOR_INTERFACE содержит имя интерфейса для прослушивания. Если значение опции any, слушается на всех интерфейсах (если ОС поддерживает это).

Опция CAPTURE_FILTER должна содержать фильтр, чтобы пропустить неинтересные пакеты и упростить процесс получения. Фильтр онснованный на синтаксисе tcpdump.

Опция SENSOR_NAME содержит имя, которое должно появляться в событиях sensor_name , таким образом, событие от одного сенсора можно было отличить от другого.

Если опция LOG_SERVER установлена, то все события отправляются удаленно на сервер, иначе они сохраняются непосредственно в лог, опция LOG_DIR, которая может быть найдена в разделе  [All] файла maltrail.conf.

В случае, если опция UPDATE_SERVER установлена, тогда все списки, скачиваются с данного сервера.

Когда сенсор (sudo python sensor.py)  запускается впервые или после длительного периода простоя, он автоматически обновит списки. После инициализации сенсор начнет контролировать сконфигурированный интерфейс (опция MONITOR_INTERFACE в maltrail.conf) и запишет события в лог (опция LOG_DIR в разделе [All] файла maltrail.conf) или отправит удаленно на сервер (опция LOG_SERVER).

Обнаруженные события сохранены в логе (опция LOG_DIR в разделе maltrail.conf файла [All]) в формате CSV (примечание:  ‘ ‘ используется в качестве разделителя) как однострочные записи, состоящие из:

time sensor src_ip src_port dst_ip dst_port proto trail_type trail trail_info

(например, «2015-10-19 15:48:41.152513» beast 192.168.5.33 32985 8.8.8.8 53 UDP DNS 0000mps.webpreview.dsl.net malicious siteinspector.comodo.com):

Сервер

Конфигурация сервера может быть найдена в разделе [Server] файла maltrail.conf :

Опция HTTP_ADDRESS содержит адрес, который слушает веб-сервер (примечание: использование 0.0.0.0, для подключения с  любого интерфейса).

Опция HTTP_PORT содержит порт на котором будет работать веб-сервер.

Значения порта по умолчанию  8338.

Если опция USE_SSL будет установлена в true тогда,  SSL/TLS будет использоваться для доступа к веб-серверу (например, https://192.168.6.10:8338/). В этом случае опция SSL_PEM должна указывать на  файл с сертификатом.

Подсекция USERS содержит параметры конфигурации пользователя.

Каждая пользовательская запись состоит из

username:sha256 (пароль):UID:filter_netmask(s).

UID значения представляет уникальный идентификатор пользователя, где рекомендуется использовать значения ниже, чем 1000 для административных учетных записей, в то время как более высокое значение для неадминистративных учетных записей. Часть filter_netmask(s) представляет собой ip адрес с маской, который может использоваться, чтобы фильтровать отображение событий в зависимости от учетной записи пользователя. Запись по умолчанию следующие:

Опция UDP_ADDRESS содержит адрес прослушки для сбор логов,  (примечание: используют 0.0.0.0, чтобы послушать во всех интерфейсах), в то время как опция UDP_PORT содержит значение порта . Если включено, и используется в сочетании с опцией LOG_SERVER, то можно использовать для многократной Sensor <-> Server архитектуры.

Так же как и сенсор, при выполнении сервера (python server.py) впервые или после  длительного периода простоя, если опция USE_SERVER_UPDATE_TRAILS установлена в true, будет автоматическое обновление.  Основная задача сохранить записи в логи (т.е. опция LOG_DIR в разделе [All] файла maltrail.conf) и обеспечить веб-интерфейс создания отчетов для представления записей конечному пользователю (примечание: нет никакой потребности установки сторонних пакетов веб-сервера как Apache):

User’s guide

Интерфейс отчетов

При входе на сервер (через адрес, определенный опциями HTTP_ADDRESS и HTTP_PORT), вы увидите следующее диалоговое окно аутентификации. Надо ввести надлежащие учетные данные, которые были установлены администратором сервера в конфигурационном файле maltrail.conf (примечание: учетные данные по умолчанию — admin:changeme!):

После входа, вы увидите следующий интерфейс отчетов:

Верхняя часть содержит скользящую временную шкалу (примечание: активируется после щелчка по метке текущей даты или календарному значку Calendar), где пользователь может выбрать логи  прошедших событий (примечание: щелчок мыши по событию инициирует дисплей подсказки с приблизительным количеством событий для текущей даты). Даты сгруппированы месяцами, где 4-месячный период данных выведен на экран в самом виджете. Однако при помощи ползунка пользователь может легко получить доступ к событиям с предыдущих месяцев.

Щелчок по дате, загрузит все события и отобразит веб-браузером клиента. В зависимости от числа событий и скорости сетевого соединения, загрузка и отображение зарегистрированных событий можеть занять время от нескольких секунд, до нескольких минут (например, загрузска 100000 событий занимает приблизительно 5 секунд).

Средняя часть содержит сводку выведенных на экран событий. Пиктограмма Events представляет общее количество событий в выбранный 24-часовой период, где красная строка представляет основанные на IP события, синяя строка представляет основанные на DNS события, и желтая строка представляет основанные на url события. Пиктограмма Sources представляет число событий за период в форме многослойной столбчатой диаграммы с общим количеством источников на вершине. Пиктограмма Threats представляет процент главных угроз в форме круговой диаграммы (примечание: серая область содержит все угрозы, имеющие каждой меньше 1% в общих событиях), с общим количеством угроз на вершине. Пиктограмма Trails представляет процент главных “следов” в форме круговой диаграммы (примечание: серая область содержит все следы, имеющие каждого мение 1% от общих событий), с общим количеством следов на вершине. Каждая из этих пиктограмм активна,  щелчок по любой из них откроет более подробный график.

Нижняя часть отображает сжатое представление зарегистрированных событий в форме нумерованной  таблицы. Каждая строка содержит детали для единственной угрозы (примечание: однозначно определенная пара (src_ip, след) или (dst_ip, след), если src_ip совпадает со следом, как в случае аттаки идущей снаржу инфраструктуры):

Столбец threat содержит уникальный идентификатор угрозы (например, 85fdb08d) и цвет, столбец sensor содержит имя  сенсора, где событие произошло (например, blitvenica), столбец  events  содержит общее количество событий для текущей угрозы, столбец severity содержит оцененную серьезность угрозы, столбец first_seen содержит время первого события в выбранный (24 часовой) период (например, 06-е 8:21:54),столбец  last_seen содержит время последнего события в выбранный (24 часовой) период (например, 06-е 15:21:23), столбец sparkline содержит небольшой  график, представляющий действие угрозы в выбранный период, столбец src_ip содержит ip, c которого была угроза (например, 99.102.41.102), столбец src_port содержит исходный порт(ы) (например, 44556, 44589, 44601), столбец dst_ip содержит целевой ip (например, 213.202.100.28), столбец dst_port содержит порт(ы) назначения (например, 80 (HTTP)), первичный протокол(ы)  (например. TCP), столбец trail содержит помещенную в черный список запись, которая инициировала событие,столбец info  содержит больше информации об угрозе(cледе) (например, известный атакующий для IP-адресов известного атакующего, или ipinfo для известной информационной службы IP, обычно используемой вредоносным программным обеспечением во время запуска),столбец reference содержит источник помещенной в черный список записи (например, (статичный) для статических следов или myip.ms для динамического канала, полученного из того же самого источника), и столбец tags  содержит определяемые пользователем теги для данного следа (например, APT28).

Когда мы наведем курсор мыши на src_ip или dst_ip записям таблицы, во всплываюем окне будет выведена информационная подсказка с подробным обратным DNS, и информацией WHOIS

Детали события (например, src_port, dst_port, протокол, и т.д.), которые различны в той же угрозе, скомпонованы в форме облачного значка. Это сделано для того, чтобы получить интерфейс создания отчетов с настолько меньшим количеством строк насколько возможно. Наведя курсор мыши на такой значок приведет к отображению информационной подсказки со всеми сохраненными элементами (например, всеми номерами портов, отсканированными атакующим):

Щелчок по одному такому значку откроет новое диалоговое окно, содержащее все сохраненные элементы (примечание: в их несжатой форме)  из которого можно скопировать данные для дальнейшего анализа:

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

Реальные случаи

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

Массовые сканирования

Массовые сканирования — довольно общее явление, когда люди дают себе право отсканировать целый 0.0.0.0/0 диапазон IP (т.е. целый Интернет) ежедневно с правовой оговоркой, где они говорят, что, если вам не нравится что вас сканируют, тогда, вы должны связаться с ними конфиденциально, чтобы вас исключили из будущих сканирований.

Такие  организации как, Shodan и ZoomEye дают свои результаты  в свободный доступ (другим потенциальным атакующим) через их поисковую систему. В следующем примере вы будете видеть детали сканирований Shodan. С reverse DNS и WHOIS адресом «атакующего»:

При удержании указателя мыши над содержанием столбца  trail (IP-адрес) вы увидете результаты поиска от DuckDuckGo, где можно будет  найти больше информации об «атакующем» (т.е. Shodan):

В столбце dst_ip, вы увидите список ваших отсканированных IP-адресов.

В столбце dst_port вы увидите все порты, которые были отсканированы такими массовыми сканированиями.

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

Еще одно общее поведение сканирования целого 0.0.0.0/0 диапазона IP (т.е. Интернет) в поисках одного определенного порта (например, порт TCP 443). В следующем примере, такой случай для ранее помещенного в черный список атакующего (в этом случае alienvault.com)  и сканированием порта UDP 5060 (SIP) в поисках неправильно сконфигурированных устройств VoIP:

Анонимные атакующие

Чтобы разыскать потенциальных атакующих, исользующих Tor, maltrail использует общедоступные списки узлов выхода Tor. В следующем примере вы увидите случай, где потенциальный атакующий использовал сеть Tor, чтобы получить доступ к веб-цели (по HTTP) в диапазоне нашей организации подозрительным способом (171 запрос на установление соединения в течении10 минут):

Атака на сервисы

Частый случай в дополнение к предыдущему примеру — когда ранее помещенный в черный список нападавший пытается получить доступ к конкретным сервисам (например, не HTTP(s)) в диапазоне нашей организации довольно подозрительным способом (т.е. 1513 полноценные попытки установить соеденение в течение 15 минут):

Мы можем отфильтрофать события по сервису например по ssh, тогда мы увидим все подобные случаи в течение дня, в этом случае для порта 22 (SSH):

Вредоносное программное обеспечение

В случае попыток подключения, которые идут из компьютеров в нашей организации к уже известным серверам C&C, можно счесть угрозой, и предположить заражение компьютеров, как в следующем примере (в этом случае Beebone):

В случае запросов DNS, содержащих известные доменные имена DGA, угроза будет показана в следующем примере (в этом случае Necurs):

Если мы введем определенное вредоносное имя (в этом случае Ramnit) в поле Filter, то будут отображены угрозы согласно фильтру .

Более общий фильтр, если мы введем malware в поле Filter, будут отображены  все угрозы, которые были найдены как вредоносные (например, IP-адреса):

Подозрительные загрузки файла

Maltrail отслеживает все подозрительные попытки загрузки исполняймых файлов (например, .apk, .exe и .scr). Возможно много ложных срабатываний, но в конечном счете может помочь в реконструкции цепочки при заражении

Подозрительные запросы HTTP

В случае подозрительных запросов, идущих снаружи, так же при использовании сканеров безопасности веб-приложений (например, ищущих SQLi, XSS, LFI, и т.д. уязвимости) или когда пользователь внутри сети предпринимает вредоносные попытки к неизвестным веб-сайтам, показаны в следующем примере (реальный случай атакующих, пытающихся использовать Joomla! CMS CVE-2015-7297, CVE-2015-7857, и CVE-2015-7858 уязвимости):

В следущем примере сканирование уязвимости веб-приложения было отмечено как «подозрительное»:

В следующем примере выполнение популярного инструмента sqlmap, так же может быть найдено в логах:

Сканирование портов

В случае множества попыток подключения к  различным портам TCP/UDP maltrail предупредит о потенциальном сканировании портов. В следующем примере мы можем видеть  такое предупреждение  при выполнения популярного инструмента сканирования портов nmap:

 

Заключение:

После длительного использования в «продакшене», можно сделать следующие выводы:
в целом, очень интересный и полезный инструмент, в качестве вспомогательного инструмента мониторинга сетевой активности:

Особенности которые хотелось бы отметить:

Легковесное, опенсорсное по. Если инфраструктура позволяет (SPAN, TAP или есть возможность запустить его на GW), то софт «заводится» за минуты;
стабильное, «пока не падало». Вначале было желание «демонизировать» sensor.py, но сенсор работает стабильно, не потребовалось. Последний аптайм сенсора более 50 дней;
хорошо определяет сканы, сканеры и «хакерский» софт; не нашли(наверное плохо искали) возможности управления активными правилами. Пока отфильтровываем «неинтересное» в SIEM’ке, по-хорошему, планируем немножко допилить их код, не все сообщения достаточно информативны, но тут вопрос к поставщикам чёрных списков;
если на объекте защиты эксплуатируются торренты, тор и т.п. то лог будет ломиться от событий категорий «known attacker» и «tor exit node»;
«локальная специфика» — срабатывает на домены .su, .kz и т.п. как на подозрительные. С User-Agent так же, срабатывает на яндекс.браузер и т.п.;

Важное замечание: Логи, как и логи от любого СЗИ, надлежит блюсти.  Потому что в них попадает масса «критичной» информации.  Так как ПО регистрирует массу валидных запросов к веб сервисам, в логи попадаест большое количество ключей, идентификаторов сессий, токенов, логинов а иногда и паролей.

Выводы:
на «взрослое» решение не претендует, но как вспомогательный инструмент вполне хорошо.
Даёт много «еды» параноику. Позволяет обнаруживать разные аномалии и вирусную активность.