Содержание статьи
Snort уже давно стал лидером среди опенсорсных сетевых IDS. Оставаясь практически единственным доступным и в то же время простым в настройке и работе решением, он получил заслуженное признание. Но в последнее время все больше стали говорить об альтернативе — проекте Suricata, в котором реализуются все современные тенденции IDS/IPS.
Зачем нам еще одна IDS?
Статистика говорит, что трафик пользователей увеличивается каждый год на 50%. К такой нагрузке следует быть готовым заранее. В том числе к обработке большого сетевого потока должны быть готовы маршрутизаторы, файрволы и системы обнаружения/предотвращения атак. С коммерческими аппаратными решениями вопросов обычно не возникает, их мощность заранее рассчитана и проверена, а внедрением занимаются специалисты. Поэтому можно легко предусмотреть запас, но вот стоят они недешево. Альтернативой служат open source решения, зарекомендовавшие себя с хорошей стороны и при этом не требующие отчислений за софт. Но все вопросы по внедрению ложатся на плечи сисадмина.
Популярный Snort начал разрабатываться в 1998 году, когда для обработки сетевого трафика обычно использовался сервер с одним 32-битным процессором. Поэтому и была использована единственно актуальная в то время single-threaded архитектура — другая не имела смысла. За это время Snort применяет около 300 тысяч зарегистрированных пользователей, и почти сто поставщиков используют его в своих продуктах. Сама компания-разработчик Sourcefire была выкуплена Cisco (вместе со Snort, ClamAV и Razorback), а к работам над Snort подключились инженеры этой корпорации.
За более чем 17 лет разработок много изменилось в компьютером мире: появились многоядерные процессоры, IPv6, увеличилось количество пользовательских приложений, и, главное, стал большим трафик. Это все нашло отражение в Snort: поддержка IPv6, возможность инспектирования уровня приложений (из последних — препроцессор OpenAppID), универсальный модуль доступа к данным DAQ и многое другое. Но базовый движок, хотя и научился работать с несколькими ядрами, так и остался однопоточным. И фактически Snort оказался не готов к переходу на настоящий multi-threading. Так как ядро Linux на переключение между нитями затрачивает несколько ms, при старых алгоритмах обработки увеличение количества процессоров даже замедляло работу. Выходом из такой ситуации было ограничение ядер в параметрах загрузки maxcpus=2. То есть мы имели мощные серверы, а использовать их на полную не могли.
Когда Snort не справлялся с нагрузкой, то просто увеличивалась мощность CPU или использовалось несколько экземпляров с балансировкой нагрузки между ними (этакий multitasking) с помощью DAQ-модуля для PF_RING. Но проблемы это не решает, поэтому и возникли проекты вроде Gnort, задача которого — повысить эффективность обнаружения атак Snort за счет переноса на GPU кода, отвечающего за проверку регулярных выражений. Это позволило добиться почти двукратного увеличения пропускной способности Snort. Но проблема многопоточности требует полной модернизации всех важных компонентов внутри Snort.
Глобальным решением стали два проекта, стартовавших практически одновременно. Это Snort 3.0, развивающийся уже более пяти лет, но находящийся до сих пор в альфе, то есть пока застряли на экспериментальной стадии и заняты тестированием оптимальных алгоритмов. И герой статьи Suricata, написанный с нуля.
Проект Suricata
В 2009 году несколько частных компаний и US Department of Homeland Security создали организацию Open Information Security Foundation (OISF), основной из задач которой было финансирование и разработка многопоточной альтернативы Snort, получившей название Suricata. Работа над новой IDS/IPS шла гораздо быстрее, чем со Snort 3.0, и бета-версия появилась уже в декабре 2009-го, а первый официальный релиз — летом 2010-го. Разработка ведется с активным привлечением сообщества, поэтому темп очень высок. Код распространяется под лицензией GPLv2, но финансовые партнеры имеют доступ к не GPL-версии движка, которую они могут брать для своих продуктов.
Suricata изначально работает в многопоточном режиме, позволяющем оптимально использовать несколько CPU. До релиза 1.3 были некоторые проблемы с масштабируемостью, например количество ядер больше четырех не давало в тестах прироста скорости. Теперь все проблемы решены и Suricata вполне эффективно работает с 24 и более процессорами. Кроме того, Suricata может использовать вычисления на стороне GPU (CUDA и OpenCL, параметр при сборке –enable-cuda). В итоге эта IDS спокойно справляется на обычном оборудовании с потоками до 10 Гбит/с.
Как и Snort, Suricata состоит из нескольких модулей (захвата, сбора, декодирования, обнаружения и вывода), по умолчанию до декодирования захваченный трафик идет одним потоком, это оптимально с точки зрения детектирования, но больше нагружает систему. Но в отличие от Snort настройками можно переопределять такое поведение и буквально одной установкой в конфиге разделить потоки сразу после захвата, а другой указать, как будут распределяться потоки по процессорам. Это дает широкие возможности для оптимизации обработки трафика на конкретном оборудовании в конкретной сети.
Имеются развитые средства инспектирования HTTP-трафика на основе библиотеки HTP, созданной Иваном Ристиком (Ivan Ristic), автором ModSecurity. Поддерживается извлечение и проверка переданных по HTTP файлов, разбор сжатого контента, возможность идентификации по URI, cookie, заголовкам, user-agent, телу запроса и ответа. Эту возможность Suricata, кстати, в некоторых сетях используют для протоколирования HTTP-трафика без детектирования. Контент в потоке можно выделять за маской и при помощи регулярных выражений, идентификация файлов возможна по имени, типу или контрольной MD5-суммой.
Изначально поддерживается декодирование IPv6, в том числе и туннели IPv4-in-IPv6, IPv6-in-IPv6, Teredo и некоторые другие. Модульная компоновка движка дает возможность быстро подключить новый элемент для захвата, декодирования, анализа или обработки пакетов. Для перехвата трафика используется несколько интерфейсов — NFQueue, IPFRing, LibPcap, IPFW, AF_PACKET, PF_RING. Режим Unix Socket позволяет автоматически анализировать PCAP-файлы, предварительно захваченные другой программой (снифером, например).
В Snort режим IPS появился не сразу, а вот в Suricata режим блокировки вредоносного трафика реализован из коробки и производится средствами штатного пакетного фильтра ОС. В Linux, например, используется два режима IPS: через очередь NFQUEUE, которая может обрабатываться на уровне пользователя, и через zero copy режим AF_PACKET (появился с версии 1.4). Режим AF_PACKET обладает большим быстродействием, но требует наличия двух сетевых интерфейсов, система должна работать в качестве шлюза. Если пакет блокируется, он просто не пересылается на второй интерфейс. В случае с NFQUEUE алгоритм прост. После попадания пакета в iptables он направляется в очередь NFQUEUE, где прогоняется по правилам. Результатом может быть три действия: NF_ACCEPT, NF_DROP и NF_REPEAT. Последний позволяет маркировать пакеты и в дальнейшем прогнать их по следующим таблицам/правилам iptables.
Главная особенность Suricata — то, что, кроме своих уникальных наработок, он использует практически все, что уже наработано для Snort. Так, подходят все Snort-овские рулсеты — Sourcefire VRT, OpenSource Emerging Threats (ETOpen) и коммерческие Emerging Threats Pro. Унифицирован вывод (Unified2), поэтому результат можно анализировать при помощи привычных бэкендов — Barnyard2, Snortsnarf, Snorby, Aanval, BASE, FPCGUI, NSM-система Sguil и Squert. Возможен вывод в PCAP, Syslog, файлы и подобное. Например, Suricata ведет журнал ключей и сертификатов, фигурирующих в TLS/SSL-соединениях. В последних релизах появился Eve log, формирующий вывод событий в формате JSON для предупреждений. Наличие JSON существенно упрощает интеграцию Suricata со сторонними приложениями, включая и системы мониторинга и визуализации логов (вроде Kibana).
Вcе настройки Suricata и правил производятся в файлах формата YAML, он более нагляден и упрощает автоматическую обработку.
Одно из преимуществ Suricata заключается в обработке 7-го уровня OSI, что повышает его способность обнаруживать вредоносные программы для приложений. Движок автоматически определяет и парсит протоколы (IP, TCP, UDP, ICMP, HTTP, TLS, FTP, SMB, SMTP и другие), поэтому в правилах можно строго не привязываться к номеру порта, как это сделано в Snort, достаточно указать протокол и действие. Дальше модули Suricata сами уже разберутся с трафиком и обнаружат протокол, даже если используется нестандартный порт.
Собственный формат rules внешне напоминает снортовский. Правило содержит компоненты: действие (pass, drop, reject или alert), заголовок (IP/порт источника и назначения) и описание (что искать). В текущей поставке родных правил мало, и некоторые к тому же отключены (закомментированы) в самих файлах, поэтому пока следует больше ориентироваться на снортовские рулсеты.
Иногда между узлами открывается не одно, а несколько TCP-соединений. Некоторые IDS не видят картину в целом и обрабатывают каждый поток отдельно. Правила Suricata широко используют концепцию flowbits. Для отслеживания количества срабатываний правил используются различные переменные сессии (например, с помощью flowint), позволяющие создавать счетчики и флаги, а затем проверять их. Такой подход легко справляется с попыткой подбора пароля. В версии 2.1 появится возможность простого отслеживания в правилах связки IP источника — IP назначения (xbits), что позволит еще проще обнаруживать вредоносный трафик, распределенный по нескольким соединениям.
В последних релизах появилась подсистема IP Reputation, загружающая и использующая в правилах данные из различных БД, содержащих списки репутации хостов. Специальный механизм обеспечивает быстрый поиск и сопоставление с IP-адресами.
Установка Suricata в Ubuntu
Поддерживается установка Suricata на Linux, BSD, OS X и Win. Проект предлагает исходные тексты и несколько репозиториев Ubuntu (suricata-stable, suricata-beta и дневной срез suricata-daily), также пакеты Suricata добавлены в Debian Backports. Хотя лучшее решение для простого развертывания и поддержки Suricata, вероятно, именно Ubuntu. В пакетах для Ubuntu IPS-режим реализован через NFQUEUE, если нужен именно AF_PACKET, а также поддержка CUDA и прочего, придется пакет собирать самостоятельно.
Сборка и установка в различных дистрибутивах подробно расписана в Wiki проекта, хотя вот последующие настройки в документации освещены несколько запутанно, а многие параметры и подпараметры разобраны не совсем внятно, и их действительно много.
$ sudo add-apt-repository ppa:oisf/suricata-stable
$ sudo apt-get update
$ sudo apt-get install suricataВместе с текущей версией правил, поставляемых с Suricata, по ходу будут скачаны и установлены в /etc/suricata/rules последняя версия рулсетов ETOpen. Для дальнейшего автоматического обновления правил, в том числе и VRT, следует установить и настроить Oinkmaster. В /var/log/suricata будут образованы три подкаталога certs, core и files. Смотрим параметры сборки:
$ suricata -build-info
Xakep #197. Социальная инженерия
Конфигурационный файл Suricata
Все основные настройки работы производятся в конфигурационном файле suricata.yaml, параметров здесь очень много. Большинство переменных и параметров, касающихся обнаружения, по названию и назначению совпадает с используемым в Snort, это упрощает знакомство для тех, кто ранее работал с этой IDS. Отличается лишь синтаксис, здесь нужно признать, что у Suricata файл читается действительно легче. В поставке имеется готовый, преднастроенный пример с комментариями (размером почти 50 Кб). Поэтому можно запускать то, что есть из коробки, с минимумом адаптации, а в последующем донастраивать по мере знакомства. Например, секция outputs отвечает за сохранение событий (настройки журналирования в logging), в файле уже прописаны все 15 возможных вариантов вывода плюс показаны их установки. Большинство из них отключено (enabled: no). По умолчанию активны только fast, eve-log (JSON), unified2-alert и http-log.
Поэтому обязательно следует внимательно изучить установки и включить те, которые действительно нужны. Готовые примеры из интернета не всегда работают и не всегда хорошо подходят для конкретной ситуации. При необходимости настройки выносятся во внешние файлы, которые подключаются при помощи include или !include. Восклицательный знак во втором варианте не означает, как это принято считать, отрицание. !include используется для хранения информации в файле определенного раздела или параметра. Например, все настройки вывода вынесены в отдельный файл outputs.yaml:
outputs: !include outputs.yamlВ конфиге много всего плюс комментарии, для просмотра текущих установок и переменных удобно использовать параметр --dump-config:
$ suricata --dump-config
Перед первым запуском следует проверить значение переменных, определенных в разделе vars, по названию они полностью совпадают со снортовскими:
vars:
address-groups:
HOME_NET: "[192.168.0.0/16,10.0.0.0/8,172.16.0.0/12]"
EXTERNAL_NET: "!$HOME_NET"
...
port-groups:
HTTP_PORTS: "80"
SHELLCODE_PORTS: "!80"
SSH_PORTS: 22
...Параметр host-mode определяет режим работы IDS/IPS. По умолчанию установлен в auto, но в зависимости от конфигурации и задач, возможно, следует перестроить на router (IPS-режим AF_PACKET) или sniffer-only (IDS). Также рекомендуется установить оптимальное значение default-packet-size, указав MTU своей сети. Кроме этого, проверяем подключенные правила. Здесь все просто. Смотрим, что есть в /etc/suricata/rules, и прописываем, что нужно:
default-rule-path: @e_sysconfdir@rules
rule-files:
- drop.rules
- emerging-activex.rules
- emerging-attack_response.rules
....Политики для определенных ОС:
host-os-policy:
windows: [0.0.0.0/0]
linux: [10.0.0.0/8, 192.168.1.100]Контроль протоколов:
app-layer:
protocols:
tls:
enabled: yes
detection-ports:
dp: 443
…Список настроенных для проверки протоколов уровня приложения можем получить при помощи --list-app-layer-protos:
$ suricata --list-app-layer-protos
Желательно перед запуском прогнать Suricata в режиме тестирования, проверить, нет ли ошибок в конфигурационном файле и правах доступа к ним:
$ sudo suricata -cT /etc/suricata/suricata.yaml
Если все в порядке, то получим только сообщение о версии движка. Иначе перед запуском в работу следует разобраться с ошибками. Разработчики пакета предоставляют init-скрипт, но первый запуск стоит произвести в интерактивном режиме, чтобы наглядно видеть происходящее и не искать проблемы в логах:
$ sudo suricata -c /etc/suricata/suricata.yaml -i eth0Стоит внимательно отнестись ко всем предупреждениям, полученным в процессе запуска. Может, текущие настройки захвата не совсем подходят. Проверим нашу IDS:
$ cd /var/log/suricata
$ sudo tail -f fast.log http.log
$ wget www.testmyids.comВ журналах появляется запись:
==> http.log <==
04/22/2015-19:46:19.566412 www.testmyids.com [**] / [**] Wget/1.15 (linux- gnu) [**] 192.168.1.137:57535 -> 82.165.177.154:80
==> fast.log <==
04/22/2015-19:46:19.809340 [**] [1:2100498:7] GPL ATTACK_RESPONSE id check returned root [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 82.165.177.154:80 -> 192.168.1.137:57535Можем посмотреть информацию о трафике в логах:
$ sudo tail /var/log/suricata/stats.log -f | grep capture
capture.kernel_packets | RxPcapeth01 | 1179
capture.kernel_drops | RxPcapeth01 | 0
capture.kernel_ifdrops | RxPcapeth01 | 0Настройки производительности Suricata
Кроме собственно настроек работы движка обнаружения, в файле следует обратить внимание на установки, влияющие на производительность. Их здесь предостаточно: threading, detect-thread-ratio, defrag, stream, runmode и другие. Первые два имеют отношение больше к железу (в частности, числу CPU), defrag и stream к сетевой нагрузке, а runmode влияет на алгоритм запуска потоков, очередей, нитей. Список и характеристики runmode можно просмотреть с помощью параметра --list-runmodes.
$ suricata --list-runmodesВ настоящее время реализовано четыре режима: auto, autofp (по умолчанию, от auto flow pinning, является усовершенствованным auto), workers и single.
Настройки по умолчанию оптимизированы для лучшего детектирования, но требуют больше ресурсов. В варианте autofp до выхода из модуля декодера потоки идут вместе, затем каждый сетевой поток обрабатывается отдельным потоком CPU (stream > detect > output). При помощи дополнительного параметра autofp-scheduler можно изменить балансировщик нагрузки. По умолчанию используется оптимальный active-packets, при котором вначале производится проверка занятости потока CPU, после чего ему уже назначается захваченное сетевое соединение. Это приводит к вполне адекватному распределению потоков и пакетов.
runmode: autofp
autofp-scheduler: active-packetsВариантами может быть round-robin или hash (используется хеш-таблица, фактически более случайное распределение, был по умолчанию до версии 1.2.1). В случае workers каждый поток обрабатывается отдельно от захвата до логирования, при single вся обработка идет одним потоком. Но только autofp и workers гарантируют, что сетевое соединение будет всегда направлено по одному и тому же потоку.
Suricata может быть использована для журналирования HTTP, DNS и подобных запросов. Модуль обнаружения, забирающий много ресурсов, можно отключить при сборке (постоянно) или временно в строке запуска (параметр --disable-detection).
Выводы
Итак, Suricata — это более быстрый, чем Snort, движок, умеющий по максимуму использовать возможности современных процессоров и GPU, при этом полностью совместимый со Snort по правилам и бэкендам. Минус — большое количество настроек и недостаточно внятная в некоторых вопросах документация. Хотя после установки нормально работает с настройками по умолчанию, а с тонкой настройкой опытный админ без проблем разберется.
