В предыдущей статье мы рассказали, как запустить стабильную версию Suricata в Ubuntu 18.04 LTS. Настроить IDS на одном узле и подключить бесплатные наборы правил довольно несложно. Сегодня мы разберемся, как с помощью установленной на виртуальном сервере Suricata защитить корпоративную сеть он наиболее распространенных видов атак. Для этого нам понадобится VDS на Linux с двумя вычислительными ядрами. Объем оперативной памяти зависит от нагрузки: кому-то хватит и 2 ГБ, а для более серьезных задач может потребоваться 4 или даже 6. Плюс виртуальной машины в возможности экспериментов: можно начать с минимальной конфигурации и наращивать ресурсы по мере необходимости.
фото: Reuters
Вынос IDS на виртуальную машину в первую очередь может понадобиться для тестов. Если вы никогда не имели дела с подобными решениями, бросаться заказывать физическое железо и менять архитектуру сети не стоит. Лучше обкатать систему безопасно и без лишних затрат, чтобы определить потребности в вычислительных ресурсах. Важно понимать, что весь корпоративный трафик при этом придется пропустить через единственный внешний узел: для подключения локальной сети (или нескольких сетей) к VDS с установленной IDS Suricata можно использовать SoftEther — простой в настройке кроссплатформенный сервер VPN, обеспечивающий надежное шифрование. Офисное подключение к интернету может не иметь реального IP, потому его лучше поднять на VPS. В репозитории Ubuntu готовых пакетов нет, ПО придется качать либо с сайта проекта, либо из внешнего репозитория на сервисе Launchpad (если вы ему доверяете):
Посмотреть список доступных пакетов можно с помощью следующей команды:
Нам понадобится softether-vpnserver (сервер в тестовой конфигурации запущен на VDS), а также softether-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:
Дальше придется включить маршрутизацию пакетов между интерфейсами (ip forward), если она неактивна:
Раскомментировать следующую строку:
Сохраняем изменения в файле, выходим из редактора и применяем их с помощью следующей команды:
Дальше нам нужно определить для виртуальной сети подсеть с фиктивными IP (например, 10.0.10.0/24) и присвоить адрес интерфейсу:
Потом потребуется прописать правила Netfilter.
1. При необходимости разрешить входящие пакеты на прослушиваемые порты (фирменный протокол SoftEther использует HTTPS и порт 443)
2. Настраиваем NAT из подсети 10.0.10.0/24 на основной IP сервера
3. Разрешаем проходящие пакеты из подсети 10.0.10.0/24
4. Разрешаем проходящие пакеты для уже установленных соединений
Автоматизацию процесса при перезапуске системы с помощью скриптов инициализации оставим читателям в качестве домашнего задания.
Если вы хотите выдавать клиентам IP автоматически, придется также установить какой-нибудь сервис DHCP для локального моста. На этом настройка сервера закончена и можно перейти к клиентам. SoftEther поддерживает множество протоколов, использование которых зависит от возможностей оборудования локальной сети.
Поскольку наш тестовый роутер тоже работает под Ubuntu, установим на нем из внешнего репозитория пакеты softether-vpnclient и softether-vpncmd, чтобы воспользоваться фирменным протоколом. Нужно будет запустить клиент:
Для настройки используем утилиту vpncmd, выбрав localhost в качестве машины, на которой запущен vpnclient. Все команды делаются в консоли: потребуется создать виртуальный интерфейс (NicCreate) и учетную запись (AccountCreate).
В некоторых случаях необходимо задать способ аутентификации с помощью команд AccountAnonymousSet, AccountPasswordSet, AccountCertSet и AccountSecureCertSet. Поскольку мы не используем DHCP, адрес для виртуального адаптера задается вручную.
Кроме того нам потребуется включить ip forward (параметр net.ipv4.ip_forward=1 в файле /etc/sysctl.conf) и настроить статические маршруты. При необходимости на VDS с Suricata можно настроить проброс портов для использования установленных в локальной сети сервисов. На этом объединение сетей можно считать законченным.
Выглядеть предлагаемая нами конфигурация будет примерно так:
В предыдущей статье мы рассказывали о двух режимах работы IDS: через очередь NFQUEUE (режим NFQ) и через zero copy (режим AF_PACKET). Второй требует наличия двух интерфейсов, но отличается более высоким быстродействием — мы будем использовать именно его. Параметр задан по умолчанию в /etc/default/suricata. Также нам понадобится отредактировать раздел vars в /etc/suricata/suricata.yaml, прописав там виртуальную подсеть в качестве домашней.
Для перезапуска IDS используем команду:
Решение готово, теперь вам может потребоваться проверить его на устойчивость к действиям злоумышленников.
Сценариев боевого применения внешнего сервиса IDS может быть несколько:
Защита от атак DDoS (основное предназначение)
Реализовать такой вариант внутри корпоративной сети сложно, поскольку пакеты для анализа должны попасть на смотрящий в интернет интерфейс системы. Даже если IDS их заблокирует, паразитный трафик может положить канал передачи данных. Чтобы этого избежать, нужно заказать VPS с достаточно производительным интернет-подключением, способным пропустить весь трафик локальной сети и весь внешний трафик. Сделать это зачастую проще и дешевле, чем расширять офисный канал. В качестве альтернативы стоит упомянуть специализированные сервисы для защиты от DDoS. Стоимость их услуг сравнима со стоимостью виртуального сервера, при этом не потребуется трудоемкая настройка, но есть и недостатки — за свои деньги клиент получает только защиту от DDoS, тогда как собственную IDS можно конфигурировать как угодно.
Защита от внешних атак других типов
Suricata способна справиться с попытками эксплуатации различных уязвимостей в доступных из интернета сервисах корпоративной сети (почтовый сервер, веб-сервер и веб-приложения и т.д.). Обычно для этого IDS устанавливают внутри локалки после пограничных устройств, но и вынос наружу имеет право на существование.
Защита от внутренних злоумышленников
Несмотря на все усилия системного администратора, компьютеры корпоративной сети могут быть заражены вредоносным ПО. Кроме того в локалке иногда появляются хулиганы, которые пытаются выполнять некие неправомерные операции. Suricata способна помочь заблокировать такие попытки, хотя для защиты внутренней сети ее лучше установить внутри периметра и использовать в паре с умеющим зеркалировать трафик в один порт управляемым коммутатором. Внешняя IDS в этом случае тоже не бесполезна — по крайней мере она сможет отловить попытки живущих в ЛВС зловредов связаться с внешним сервером.
Для начала создадим еще один тестовый атакующий VPS, а на роутере локальной сети поднимем Apache с конфигурацией по умолчанию, после чего пробросим на него 80-й порт с сервера IDS. Дальше будем имитировать атаку DDoS с атакующего узла. Для этого скачаем с GitHub, скомпилируем и запустим на атакующем узле небольшую программу xerxes (может потребоваться установка пакета gcc):
Результат ее работы оказался следующим:
Suricata отсекает злодея, а страница Apache по умолчанию открывается, несмотря на нашу импровизированную атаку и довольно дохлый канал «офисной» (на самом деле домашней) сети. Для более серьезных задач стоит использовать Metasploit Framework. Он предназначен для проведения тестов на проникновение и позволяет имитировать самые разные атаки. Инструкция по установке доступна на сайте проекта. После инсталляции потребуется обновление:
Для тестирования запускаем msfconsole.
К сожалению, в последних версиях фреймворка отсутствует возможность автоматического взлома, поэтому эксплоиты придется перебирать вручную и запускать с помощью команды use. Для начала стоит определить открытые на атакуемой машине порты, например, с помощью nmap (в нашем случае его вполне заменит netstat на атакуемом узле), а потом подобрать и использовать подходящие модули Metasploit.
Существуют и другие средства проверки устойчивости IDS к атакам, включая онлайн-сервисы. Ради любопытства можно устроить стрессовое тестирование с помощью триальной версии IP Stresser. Чтобы проверить реакцию на действия внутренних злоумышленников, стоит установить специальные инструменты на одну из машин локальной сети. Вариантов масса и периодически их стоит применять не только к экспериментальному полигону, но и к рабочим системам, только это уже совсем другая история
- 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/softethervpn
sudo 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 ACCEPT
sudo iptables -A INPUT -p tcp -m tcp --dport 992 -j ACCEPT
sudo iptables -A INPUT -p tcp -m tcp --dport 1194 -j ACCEPT
sudo iptables -A INPUT -p udp -m udp --dport 1194 -j ACCEPT
sudo iptables -A INPUT -p tcp -m tcp --dport 5555 -j ACCEPT2. Настраиваем 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.1403. Разрешаем проходящие пакеты из подсети 10.0.10.0/24
sudo iptables -A FORWARD -s 10.0.10.0/24 -j ACCEPT4. Разрешаем проходящие пакеты для уже установленных соединений
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.git
cd 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. Чтобы проверить реакцию на действия внутренних злоумышленников, стоит установить специальные инструменты на одну из машин локальной сети. Вариантов масса и периодически их стоит применять не только к экспериментальному полигону, но и к рабочим системам, только это уже совсем другая история
