Всем привет! 2 часть цикла статей по разбору устройства работы IDS/IPS решения Suricata.

Обращу Ваше внимание на весь 8 раздел документации. Он состоит из подразделов протоколов и других настроек suricata. В каждом подразделе можно найти определенные настройки. Просто так проходиться по каждому подразделу – смысла не вижу. Попробуем научиться сразу на практике. Будем искать интересные pcap-ы и для них напишем правила suricata. Тем самым будем разбирать ключевые и часто необходимые модификаторы для написания правил.

Начнем с DNS-а. Скачиваем и изучаем его в wireshark.

Остановимся на 7-10 фремах. У нас есть 2 DNS-резолва. Давайте напишем правило, запустим его и посмотрим результат:

Если каким-то образом после запуска проверки правила у вас не отображается вкладка “Alert Debug”, то можно найти информацию по алертам, например на какой фрейм пришли сработки, во вкладке “EVE JSON” (представлено ниже на скрине). Если бы мы запускали suricata напрямую через командную строку, то результаты бы выводились в заданную директорию в определенные файлы. Чем удобен Далтон, так это тем что не нужно постоянно открывать файлы, чистить и так далее. Красиво и удобно в веб-интерфейсе можно работать.

 У нас 2 алерта на 7 и 9 фреймы:

Давайте разбирать правило. Мы написали, что нужно взвести алерт на соединение по протоколу udp c домашней подсети к любому хосту (почему получателя мы не обозначили из внешней сети? Потому что в пкапе днс-сервер находится в одной подсети с инициатором. В инфраструктуре может быть локальный DNS-сервер и через него могут быть запросы к нелегитимным ресурсам.) по порту 53 (DNS). Говорим, что искать через контент «www.www.com» днс запрос, игнорируя регистр (nocase) и искать по вхождению подстроки в запросе (dns.query). 

Content – один из самых важных параметров, которые мы будем использовать не раз. В Content мы можем вставлять текстовые значения, как в примере выше, а можем и hex значения. Давайте попробуем: перепишем наше правило: alert udp $HOME_NET any -> any 53 (msg:"Dns resolve to www.www.com in HEX"; content:"|77 77 77 03 77 77 77 03 63 6f 6d|"; sid:11;). Запустим проверку и увидим, что у нас также сработки на 7 и 9 фрейм, НО мы убрали «dns.query» и «nocase» потому что выполняется байтовый поиск по всей полезной нагрузке. Можно комбинировать: alert udp $HOME_NET any -> any 53 (msg:"Dns resolve to www.www.com in HEX"; content:"www|03|www|03|com"; sid:12;). Тут также будет выполняться побайтовый поиск и если использовать модификатор «dns.query», то правило работать не будет. Но если хотите, можете попробовать. Но почему так? Потому что согласно документации буффер для модификатора «dns.query» хранит нормализованную строку.

Можно написать правило на поиск респонсов урла www.www.com нашего, у которых код ответа NOERROR: «alert udp any 53 -> $HOME_NET any (msg:"Dns answer from www.www.com"; dns.response.rrname; content:"www.www.com"; dns.rcode:0; nocase; sid:13;)». dns.response.rrname – здесь мы использовали эту переменную, благодаря которой будет выполнятся поиск по всем записям в dns-респонсе. А dns.rcode ищет код ответа 0. Вы можете проанализировать пакеты в ваершарке и найти все паттерны, которые мы ищем:

Давайте теперь рассмотрим классическую icmp-flood атаку. Скачиваем пкап и смотрим – 12 035 icmp echo запросов. Тип запросов 8. Можно написать правило которое будет детектировать нам эту атаку. Определили, что у нас трафик по протоколу icmp – соответственно идем в документацию в раздел с возможными настройками. А у нас много что можно сделать! Давайте возьмем параметр itype и  icode. 8 тип запроса с кодом 0 – это эхо запросы (более подробно о типах запросов можно почитать здесь)

Пишем правило «alert icmp any any -> any any (msg:"icmp-flood attack"; itype:8; icode:0; sid:14;)»,  запускаем. Ииииии:

Застрелиться можно. Сколько же алертов….. Давайте поразмышляем. У нас в пкапе icmp-flood – просто какой-то нехороший человек решил пингами атаковать хост. Мы написали правило на обычный эхо запрос. Представьте, если бы наша суриката работала в Компании в реальной инфраструктуре, где постоянно кто-то кого-то пингует. Это же не атака. Icmp-flood будет в том случае, если пришло n-ое количество icmp-запросов на целевой хост за единицу времени. Нам нужно доработать правило так, чтобы оно срабатывало, например, на 300 запросов в минуту. На такой случай есть threshold.

Остановимся и немножко поговорим о трешхолде. Синтаксис:
threshold: type <threshold|limit|both|backoff>, track <by_src|by_dst|by_rule|by_both|by_flow>, count <N>, <seconds <T>|multiplier <M>>
Типы трешхолда:
threshold – алерт взведется тогда, когда количество совпадений будет равно счетчику (count <N>). Время можно не указывать, но если указать, то сработает алерт когда за такое-то время (<seconds <T>) будет установленное количество совпадений (count <N>).
limit – этот тип помогает предотвратить флуд алертов. Им можно ограничить количестов алертов в единицу времени.
both – этот тип комбинирует «threshold» и «limit» для контроля и количества алертов, и количество совпадений. Если в «threshold» у нас суриката работает по счетчику, то есть посчитала 10 совпадений и сразу считает следующие. В «limit» считаются количество алертов, а потом на время прекращает анализировать по этому правилу. «both» - некая золотая середина этой истории. Мы можем установить счетчик количества совпадений и ограничить алерты в единицу времени. Например, при 10 (count 10) совпадений в 5 минут (seconds 600) взведется 1 алерт. То есть если в первые 30 секунд придут первые 10 пакетов, совпавших с нашими условиями, то более по истечению 5 минут алертов по этому правилу не придет.
backoff – этот тип ограничивает взведение алертов, используя механизм задержки (backoff) между оповещениями. Его можно использовать только для by_flow. Для меня этот параметр новый, так что попробуем разобрать в дальнейшем.

Track:

Для детектирования icmp-flood-а предлагаю модернизировать наше правило следующим образом:
alert icmp any any -> any any (msg:"icmp-flood attack"; itype:8; icode:0; threshold:type both,track by_src,count 300,seconds 60; sid:15;)
Запускаем и видим 1 алерт. Таким образом, данный алерт говорит нам что с хоста-инициатора за минуту зафиксировано минимум 300 icmp-запросов, что может предполагать об атаке icmp-flood.

И еще разберем пкап c атакой SYN-ACK Flood. Суть этой атаки состоит в том, что на целевой сервер посылаются в большом количестве syn-ack пакеты, содержащие ложные данные об отправителях. Атакуемый сервер тратит свои ресурсы на поиск информации о syn пакетах, об отправителях и в конечном итоге возможна перегрузка сервера.

красивую картинку нашел здесь.
Идем в подраздел, смотрим какие параметры мы можем использовать. Далее смотрим на пкап:

Обратим внимание на флаги. Мы их обязательно укажем в условии правила. Размер окна у нас разный, но я бы не сказал, что достаточно разные и непредсказуемые значения встречаются, однако можно обратить на MSS (Maximum segment size). Думаю следующее правило будет подходящим:
alert tcp $EXTERNAL_NET 80 -> any any (msg:"SYN-ACK attack"; tcp.flags:SA; tcp.mss:1400; threshold:type both,track by_dst,count 300,seconds 60; sid:16;)

Сетевые сканеры имеют свои паттерны сетевой активности. У сетевых обращений от сканера NMAP есть характерные признаки в TCP-заголовках. Например, размер окна, флаги, содержимое полезной нагрузки и другие. Важно понимать, что детектирования SYN-ACK атаки только по количеству обращений, будет давать большое количество ложных срабатываний. Чем больше признаков мы сможем записать в suricata-правила, тем лучше правило будет детектировать нелегитимную активность.

Изучите как сформированы сигнатурные правила, которые ищут паттерны NMAP-сканера в правилах с sid: 2000537, 2000536, 2000538, 2000540, 2000543, 2000544, 2000546 - здесь.

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