Suricata

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



Позволяющих защитить ИТ-инфраструктуру компании продвинутых средств существует множество. Сегодня мы поговорим о системах обнаружения и предупреждения вторжений с открытым исходным кодом, внедрить которые можно без покупки дорогостоящего оборудования и программных лицензий.

Классификация IDS/IPS

IDS (Intrusion Detection System) предназначенная для регистрации подозрительных действий в сети или на отдельном компьютере система. Она ведет журналы событий и уведомляет о них ответственного за информационную безопасность сотрудника. В составе IDS можно выделить следующие элементы:

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

Изначально IDS классифицировались по месту расположения: они могли быть ориентированы на защиту отдельных узлов (host-based или Host Intrusion Detection System HIDS) или защищать всю корпоративную сеть (network-based или Network Intrusion Detection System NIDS). Стоит упомянуть т.н. APIDS (Application protocol-based IDS): они отслеживают ограниченный набор протоколов прикладного уровня для выявления специфических атак и не занимаются глубоким анализом сетевых пакетов. Такие продукты обычно напоминают прокси и используются для защиты конкретных сервисов: веб-сервера и веб-приложений (например, написанных на PHP), сервера баз данных и т.д. Типичный представитель этого класса mod_security для веб-сервера Apache.

Нас больше интересуют универсальные NIDS, поддерживающие широкий набор коммуникационных протоколов и технологии глубокого анализа пакетов DPI (Deep Packet Inspection). Они мониторят весь проходящий трафик, начиная сканального уровня, и выявляют широкий спектр сетевых атак, а также попытки неавторизованного доступа к информации. Часто такие системы отличаются распределенной архитектурой и могут взаимодействовать с различным активным сетевым оборудованием. Отметим, что многие современные NIDS являются гибридными и объединяют несколько подходов. В зависимости от конфигурации и настроек они могут решать различные задачи например, защиту одного узла или всей сети. К тому же функции IDS для рабочих станций взяли на себя антивирусные пакеты, которые из-за распространения направленных на кражу информации троянов превратились в многофункциональные брандмауэры, решающие в том числе задачи распознавания и блокирования подозрительного трафика.

Изначально IDS могли только обнаруживать действия вредоносного ПО, работу сканеров портов, или, скажем, нарушения пользователями корпоративных политик безопасности. При наступлении определенного события они уведомляли администратора, но довольно быстро стало понятно, что просто распознать атаку недостаточно ее нужно заблокировать. Так IDS трансформировались в IPS (Intrusion Prevention Systems) системы предотвращения вторжений, способные взаимодействовать с сетевыми экранами.

Методы обнаружения

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

• Сигнатурные IDS/IPS выявляют в трафике некие шаблоны или отслеживают изменения состояния систем для определения сетевой атаки или попытки заражения. Они практически не дают осечек и ложных срабатываний, но не способны выявить неизвестные угрозы;
• Выявляющие аномалии IDS не используют сигнатуры атак. Они распознают отличающееся от нормального поведение информационных систем (включая аномалии в сетевом трафике) и могут определить даже неизвестные атаки. Такие системы дают довольно много ложных срабатываний и при неграмотном использовании парализуют работу локальной сети;
• Основанные на правилах IDS работают по принципу: if ФАКТ then ДЕЙСТВИЕ. По сути дела это экспертные системы с базами знаний совокупностью фактов и правил логического вывода. Такие решения трудоемки в настройке и требуют от администратора детального понимания работы сети.

История развития IDS

Эпоха бурного развития Интернета и корпоративных сетей началась в 90-е годы прошлого века, однако продвинутыми технологиями сетевой безопасности специалисты озадачились чуть раньше. В 1986 году Дороти Деннинг и Питер Нейман опубликовали модель IDES (Intrusion detection expert system), ставшую основой большинства современных систем обнаружения вторжений. Она использовала экспертную систему для определения известных видов атак, а также статистические методы и профили пользователей/систем. IDES запускалась на рабочих станциях Sun, проверяя сетевой трафик и данные приложений. В 1993 году вышла NIDES (Next-generation Intrusion Detection Expert System) экспертная система обнаружения вторжений нового поколения.

На основе работ Деннинга и Неймана в 1988 году появилась экспертная система MIDAS (Multics intrusion detection and alerting system), использующая P-BEST и LISP. Тогда же была создана основанная на статистических методах система Haystack. Еще один статистический детектор аномалий W&S (Wisdom & Sense) годом позже разработали в Лос-Аламосской Национальной лаборатории. Развитие отрасли шло быстрыми темпами. К примеру, в 1990 году в системе TIM (Time-based inductive machine) уже было реализовано обнаружение аномалий с использованием индуктивного обучения на последовательных паттернах пользователя (язык Common LISP). NSM (Network Security Monitor) для обнаружения аномалий сравнивал матрицы доступа, а ISOA (Information Security Officers Assistant) поддерживал различные стратегии обнаружения: статистические методы, проверку профиля и экспертную систему. Созданная в AT&T Bell Labs система ComputerWatch использовала для проверки и статистические методы и правила, а первый прототип распределенной IDS разработчики Университета Калифорнии получили еще в 1991 году DIDS (Distributed intrusion detection system) по совместительству являлась и экспертной системой.

Поначалу IDS были проприетарными, но уже в 1998 году Национальная лаборатория им. Лоуренса в Беркли выпустила Bro (в 2018 году она была переименована в Zeek) систему с открытым исходным кодом, использующую собственный язык правил для анализа данных libpcap. В ноябре того же года появился использующий libpcap сниффер пакетов APE, который через месяц был переименован в Snort, а позднее стал полноценной IDS/IPS. Тогда же начали появляться и многочисленные проприетарные решения.

Snort и Suricata

Во многих компаниях отдают предпочтение бесплатным IDS/IPS с открытым исходным кодом. Долгое время стандартным решением считалась уже упомянутая нами Snort, но сейчас ее потеснила система Suricata. Рассмотрим их преимущества и недостатки чуть подробнее. Snort комбинирует преимущества сигнатурного метода с возможностью обнаружения аномалий в реальном времени. Suricata также позволяет использовать другие методы помимо распознавания атак по сигнатурам. Система была создана отделившейся от проекта Snort группой разработчиков и поддерживает функции IPS, начиная с версии 1.4, а в Snort возможность предотвращения вторжений появилась позднее.

Основное различие между двумя популярными продуктами заключается в наличии у Suricata возможности использования GPU для вычислений в режиме IDS, а также в более продвинутой IPS. Система изначально рассчитана на многопоточность, в то время как Snort продукт однопоточный. Из-за своей давней истории и унаследованного кода он не оптимально использует многопроцессорные/многоядерные аппаратные платформы, тогда как Suricata на обычных компьютерах общего назначения позволяет обрабатывать трафик до 10 Гбит/сек. О сходствах и различиях двух систем можно рассуждать долго, но хотя движок Suricata и работает быстрее, для не слишком широких каналов это не имеет принципиального значения.

Варианты развертывания

IPS необходимо разместить таким образом, чтобы система могла наблюдать за подконтрольными ей сегментами сети. Чаще всего это выделенный компьютер, один интерфейс которого подключается после пограничных устройств и смотрит через них в незащищенные сети общего пользования (Интернет). Другой интерфейс IPS подключается на вход защищаемого сегмента, чтобы весь трафик проходил через систему и анализировался. В более сложных случаях защищаемых сегментов может быть несколько: скажем, в корпоративных сетях часто выделяют демилитаризованную зону (DMZ) с доступными из Интернета сервисами.



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

Часто корпоративные сети подвергаются распределенным атакам, направленным на отказ в обслуживании (DDoS). Хотя современные IDS умеют с ними бороться, приведенный выше вариант развертывания здесь едва ли поможет. Система распознает вредоносную активность и заблокирует паразитный трафик, но для этого пакеты должны пройти через внешнее интернет-подключение и попасть на ее сетевой интерфейс. В зависимости от интенсивности атаки, канал передачи данных может не справиться с нагрузкой и цель злоумышленников будет достигнута. Для таких случаев мы рекомендуем разворачивать IDS на виртуальном сервере с заведомо более производительным интернет-соединением. Подключить VPS к локальной сети можно через VPN, а затем потребуется настроить через него маршрутизацию всего внешнего трафика. Тогда в случае DDoS-атаки не придется гонять пакеты через подключение к провайдеру, они будут заблокированы на внешнем узле.

Проблема выбора

Выявить лидера среди бесплатных систем очень сложно. Выбор IDS/IPS определяется топологией сети, нужными функциями защиты, а также личными предпочтениями админа и его желанием возиться с настройками. Snort имеет более давнюю историю и лучше документирован, хотя и по Suricata информацию также нетрудно найти в сети. В любом случае для освоения системы придется приложить определенные усилия, которые в итоге окупятся коммерческие аппаратные и аппаратно-программные IDS/IPS стоят достаточно дорого и не всегда помещаются в бюджет. Жалеть о потраченном времени не стоит, потому что хороший админ всегда повышает квалификацию за счет работодателя. В этой ситуации все остаются в выигрыше. В следующей статье мы рассмотрим некоторые варианты развертывания Suricata и на практике сравним более современную систему с классической IDS/IPS Snort.

В предыдущей статье мы рассказали, как запустить стабильную версию Suricata в Ubuntu 18.04 LTS. Настроить IDS на одном узле и подключить бесплатные наборы правил довольно несложно. Сегодня мы разберемся, как с помощью установленной на виртуальном сервере Suricata защитить корпоративную сеть он наиболее распространенных видов атак. Для этого нам понадобится VDS на Linux с двумя вычислительными ядрами. Объем оперативной памяти зависит от нагрузки: кому-то хватит и 2 ГБ, а для более серьезных задач может потребоваться 4 или даже 6. Плюс виртуальной машины в возможности экспериментов: можно начать с минимальной конфигурации и наращивать ресурсы по мере необходимости.

^{фото: Reuters}

• Snort или Suricata. Часть 1: выбираем бесплатную IDS/IPS для защиты корпоративной сети
• Snort или Suricata. Часть 2: установка и первичная настройка Suricata

Объединяем сети

Вынос IDS на виртуальную машину в первую очередь может понадобиться для тестов. Если вы никогда не имели дела с подобными решениями, бросаться заказывать физическое железо и менять архитектуру сети не стоит. Лучше обкатать систему безопасно и без лишних затрат, чтобы определить потребности в вычислительных ресурсах. Важно понимать, что весь корпоративный трафик при этом придется пропустить через единственный внешний узел: для подключения локальной сети (или нескольких сетей) к VDS с установленной IDS Suricata можно использовать SoftEther простой в настройке кроссплатформенный сервер VPN, обеспечивающий надежное шифрование. Офисное подключение к интернету может не иметь реального IP, потому его лучше поднять на VPS. В репозитории Ubuntu готовых пакетов нет, ПО придется качать либо с сайта проекта, либо из внешнего репозитория на сервисе Launchpad (если вы ему доверяете):

sudo add-apt-repository ppa:paskal-07/softethervpnsudo apt-get update

Посмотреть список доступных пакетов можно с помощью следующей команды:

apt-cache search softether

Нам понадобится softether-vpnserver (сервер в тестовой конфигурации запущен на VDS), а также softether-vpncmd утилиты командной строки для его настройки.

sudo apt-get install softether-vpnserver softether-vpncmd

Для настройки сервера используется специальная утилита командной строки:

sudo vpncmd

Подробно рассказывать о настройке мы не будем: процедура довольно несложная, она хорошо описана в многочисленных публикациях и непосредственно к теме статьи не относится. Если вкратце, после запуска vpncmd нужно выбрать пункт 1, чтобы перейти в консоль управления сервером. Для этого необходимо ввести имя localhost и нажать enter вместо ввода имени хаба. В консоли задается администраторский пароль командой serverpasswordset, удаляется виртуальный хаб DEFAULT (команда hubdelete) и создается новый с именем Suricata_VPN, а также задается его пароль (команда hubcreate). Дальше нужно перейти в управляющую консоль нового хаба с помощью команды hub Suricata_VPN, чтобы создать группу и пользователя с помощью команд groupcreate и usercreate. Пользовательский пароль задается с помощью userpasswordset.

SoftEther поддерживает два режима передачи трафика: SecureNAT и Local Bridge. Первый представляет собой фирменную технологию построения виртуальной частной сети с собственным NAT и DHCP. SecureNAT не требует TUN/TAP, а также настройки Netfilter или другого файрвола. Маршрутизация не затрагивает ядра системы, а все процессы виртуализированы и работают на любом VPS/VDS вне зависимости от использующегося гипервизора. Это приводит к повышенной нагрузке на процессор и снижению скорости по сравнению с режимом Local Bridge, соединяющим виртуальный хаб SoftEther с физическим сетевым адаптером или устройством TAP.

Настройка в этом случае усложняется, поскольку маршрутизация происходит на уровне ядра при помощи Netfilter. Наши VDS построены на Hyper-V, поэтому на последнем шаге мы создаем локальный мост и активируем устройство TAP командой bridgecreate Suricate_VPN -device:suricate_vpn -tap:yes. После выхода из консоли управления хабом мы увидим в системе новый сетевой интерфейс, которому еще не присвоен IP:

ifconfig

Дальше придется включить маршрутизацию пакетов между интерфейсами (ip forward), если она неактивна:

sudo nano /etc/sysctl.conf

Раскомментировать следующую строку:

net.ipv4.ip_forward = 1

Сохраняем изменения в файле, выходим из редактора и применяем их с помощью следующей команды:

sudo sysctl -p

Дальше нам нужно определить для виртуальной сети подсеть с фиктивными IP (например, 10.0.10.0/24) и присвоить адрес интерфейсу:

sudo ifconfig tap_suricata_vp 10.0.10.1/24

Потом потребуется прописать правила Netfilter.

1. При необходимости разрешить входящие пакеты на прослушиваемые порты (фирменный протокол SoftEther использует HTTPS и порт 443)

sudo iptables -A INPUT -p tcp -m tcp --dport 443 -j ACCEPTsudo iptables -A INPUT -p tcp -m tcp --dport 992 -j ACCEPTsudo iptables -A INPUT -p tcp -m tcp --dport 1194 -j ACCEPTsudo iptables -A INPUT -p udp -m udp --dport 1194 -j ACCEPTsudo iptables -A INPUT -p tcp -m tcp --dport 5555 -j ACCEPT

2. Настраиваем NAT из подсети 10.0.10.0/24 на основной IP сервера

sudo iptables -t nat -A POSTROUTING -s 10.0.10.0/24 -j SNAT --to-source 45.132.17.140

3. Разрешаем проходящие пакеты из подсети 10.0.10.0/24

sudo iptables -A FORWARD -s 10.0.10.0/24 -j ACCEPT

4. Разрешаем проходящие пакеты для уже установленных соединений

sudo iptables -A FORWARD -p all -m state --state ESTABLISHED,RELATED -j ACCEPT

Автоматизацию процесса при перезапуске системы с помощью скриптов инициализации оставим читателям в качестве домашнего задания.

Если вы хотите выдавать клиентам IP автоматически, придется также установить какой-нибудь сервис DHCP для локального моста. На этом настройка сервера закончена и можно перейти к клиентам. SoftEther поддерживает множество протоколов, использование которых зависит от возможностей оборудования локальной сети.

netstat -ap |grep vpnserver

Поскольку наш тестовый роутер тоже работает под Ubuntu, установим на нем из внешнего репозитория пакеты softether-vpnclient и softether-vpncmd, чтобы воспользоваться фирменным протоколом. Нужно будет запустить клиент:

sudo vpnclient start

Для настройки используем утилиту vpncmd, выбрав localhost в качестве машины, на которой запущен vpnclient. Все команды делаются в консоли: потребуется создать виртуальный интерфейс (NicCreate) и учетную запись (AccountCreate).

В некоторых случаях необходимо задать способ аутентификации с помощью команд AccountAnonymousSet, AccountPasswordSet, AccountCertSet и AccountSecureCertSet. Поскольку мы не используем DHCP, адрес для виртуального адаптера задается вручную.

Кроме того нам потребуется включить ip forward (параметр net.ipv4.ip_forward=1 в файле /etc/sysctl.conf) и настроить статические маршруты. При необходимости на VDS с Suricata можно настроить проброс портов для использования установленных в локальной сети сервисов. На этом объединение сетей можно считать законченным.

Выглядеть предлагаемая нами конфигурация будет примерно так:

Настраиваем Suricata

В предыдущей статье мы рассказывали о двух режимах работы IDS: через очередь NFQUEUE (режим NFQ) и через zero copy (режим AF_PACKET). Второй требует наличия двух интерфейсов, но отличается более высоким быстродействием мы будем использовать именно его. Параметр задан по умолчанию в /etc/default/suricata. Также нам понадобится отредактировать раздел vars в /etc/suricata/suricata.yaml, прописав там виртуальную подсеть в качестве домашней.



Для перезапуска IDS используем команду:

systemctl restart suricata

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

Моделируем атаки

Сценариев боевого применения внешнего сервиса IDS может быть несколько:

Защита от атак DDoS (основное предназначение)

Реализовать такой вариант внутри корпоративной сети сложно, поскольку пакеты для анализа должны попасть на смотрящий в интернет интерфейс системы. Даже если IDS их заблокирует, паразитный трафик может положить канал передачи данных. Чтобы этого избежать, нужно заказать VPS с достаточно производительным интернет-подключением, способным пропустить весь трафик локальной сети и весь внешний трафик. Сделать это зачастую проще и дешевле, чем расширять офисный канал. В качестве альтернативы стоит упомянуть специализированные сервисы для защиты от DDoS. Стоимость их услуг сравнима со стоимостью виртуального сервера, при этом не потребуется трудоемкая настройка, но есть и недостатки за свои деньги клиент получает только защиту от DDoS, тогда как собственную IDS можно конфигурировать как угодно.

Защита от внешних атак других типов

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

Защита от внутренних злоумышленников

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

Для начала создадим еще один тестовый атакующий VPS, а на роутере локальной сети поднимем Apache с конфигурацией по умолчанию, после чего пробросим на него 80-й порт с сервера IDS. Дальше будем имитировать атаку DDoS с атакующего узла. Для этого скачаем с GitHub, скомпилируем и запустим на атакующем узле небольшую программу xerxes (может потребоваться установка пакета gcc):

git clone https://github.com/Soldie/xerxes-DDos-zanyarjamal-C.gitcd xerxes-DDos-zanyarjamal-C/gcc xerxes.c -o xerxes./xerxes 45.132.17.140 80

Результат ее работы оказался следующим:



Suricata отсекает злодея, а страница Apache по умолчанию открывается, несмотря на нашу импровизированную атаку и довольно дохлый канал офисной (на самом деле домашней) сети. Для более серьезных задач стоит использовать Metasploit Framework. Он предназначен для проведения тестов на проникновение и позволяет имитировать самые разные атаки. Инструкция по установке доступна на сайте проекта. После инсталляции потребуется обновление:

sudo msfupdate

Для тестирования запускаем msfconsole.



К сожалению, в последних версиях фреймворка отсутствует возможность автоматического взлома, поэтому эксплоиты придется перебирать вручную и запускать с помощью команды use. Для начала стоит определить открытые на атакуемой машине порты, например, с помощью nmap (в нашем случае его вполне заменит netstat на атакуемом узле), а потом подобрать и использовать подходящие модули Metasploit.

Существуют и другие средства проверки устойчивости IDS к атакам, включая онлайн-сервисы. Ради любопытства можно устроить стрессовое тестирование с помощью триальной версии IP Stresser. Чтобы проверить реакцию на действия внутренних злоумышленников, стоит установить специальные инструменты на одну из машин локальной сети. Вариантов масса и периодически их стоит применять не только к экспериментальному полигону, но и к рабочим системам, только это уже совсем другая история