Правило Snort не генерирует оповещения, когда хосты отвечают одновременно

Question

alert tcp any any -> any any (msg:"PRIVMSG от подозрительного действия канала IRC"; содержимое:"PRIVMSG"; смещение: 0; глубина:7; nocase; dsize:<64; поток: установленный_сервер; тег: установленный тег: сеанс,300, секунд; класс: плохо-неизвестный; sid:2000346; rev:4;)

Вышеупомянутое правило написано для мониторинга ботов, отвечающих на сообщения ботмастеру. Правило работает нормально, но только когда один бот делает ответ, и нет оповещения или даже одного оповещения для одного хоста, когда более чем один хост отвечает одновременно. Я изменил время сеанса на 30 или 150, но не повезло.

Какие-нибудь подсказки или уловки, чтобы сделать это эффективным?

Благодарю.

-Aymen

Answer 1

Я не думаю, что полностью понимаю, что вы пытаетесь сделать с этим правилом. Не могли бы вы уточнить детали того, почему вы ищете просто PRIVMSG без названия канала (или даже псевдоним бота, если на то пошло)?

Тем не менее, несколько быстрых предложений о том, как сделать правило более эффективным. При необходимости адаптируйте:

• dsize а также flow считаются "дискретными" опциями и должны быть указаны перед любыми опциями полезной нагрузки (такими как content и его модификаторы и т. д.). Дискретные опции, как правило, проверяют специфичные для протокола поля и никогда не затрагивают полезную нагрузку, поэтому они очень быстры (уступая только быстрому сопоставлению с шаблоном). Тоесть надо сделать flow преследовать msg, а потом dsize после flow,

• Далее вы, вероятно, устанавливаете таймер для tag слишком высоко. Там есть встроенная отсечка для tag, называется tagged_packet_limitи по умолчанию это 256 пакетов. Таким образом, ваше правило перестало бы помечать тегами одно из трех возможных условий (в зависимости от того, что произойдет раньше):

  • Конец сессии.
  • Через 5 минут (300 секунд).
  • 256 пакетов помечены.

  
  seconds метрика может немного колебаться в зависимости от других факторов вашего датчика, таких как скорость канала, загрузка системы и т. д. Таким образом, правило может прекратить маркировку пакетов через 297 секунд или 303 секунды. Вероятно, лучше использовать packets метрика и установить его на действительно высокое значение, такое как 1000, Это имеет дополнительное преимущество переопределения tagged_packet_limit, Вы даже можете указать несколько метрик одновременно:

  tag:session,240,seconds,8000,bytes,1000,packets;
  

• Вы должны рассмотреть возможность использования пары flowbits контролировать, когда операция тегирования начинается и заканчивается:

  <discrete options>; flowbits:isnotset,botnet.tagged; <payload options>; flowbits:set,botnet.tagged;
  

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

• Вы должны определить переменную для общих портов IRC и использовать ее в поле портов назначения. Snort использует поле порта назначения в сочетании с быстродействующим сопоставителем шаблонов, чтобы оптимизировать, по каким правилам проверяется пакет (т. Е. HTTP-трафик не должен проверяться правилом, ориентированным на IRC). Вместо порта назначения он будет пытаться использовать порт источника (подробности об этом доступны в комментариях вверху src/pcrm.c в исходном коде). Если целевой IRC-сервер использует только один порт, используйте его вместо этого. Один порт лучше, чем группа портов, но группа портов НАМНОГО лучше, чем просто any:

  portvar IRC_PORTS [6666:6669]
  

• Наконец, вам нужно использовать уникальную строку, чтобы по-настоящему воспользоваться преимуществами быстрого сопоставления с шаблоном. PRIVMSG очень часто встречается в протоколе IRC, поэтому, если вы пытаетесь ограничить правило очень конкретным каналом, рассмотрите что-то вроде:

  content:"PRIVMSG #foobar:"; fast_pattern:only;
  

  
  fast_pattern:only; bit, доступный в snort-2.9.0 и более поздних версиях, использует только совпадение содержимого в быстром сопоставителе и не будет повторно использовать его при фактическом поиске полезной нагрузки. Побочный эффект: вы не можете использовать дополнительные совпадения контента относительно этого совпадения контента. и это совпадение выполняется без учета регистра!

  Трудно обернуть голову вокруг этого небольшого изменения при выходе из 2.8.6, но быстрый способ узнать, работает ли он для вас, таков: "Меня волнует только, найдена ли эта строка ГДЕ-ТО в пакете?", Если да, затем fast_pattern:only; сделает именно это и сэкономит вам несколько процессорных циклов. В противном случае, если вам нужно убедиться, что строка существует не только в пакете, но и на очень определенной глубине или смещении, вы можете полностью пропустить эту строку. Snort по-прежнему будет использовать самое длинное совпадение содержимого в правиле в качестве быстрого сопоставления с шаблоном (но это можно изменить, просто используя fast_pattern; без аргументов на content что вы знаете, чтобы быть самой уникальной строкой в ​​пакете).

Объединяя все это вместе:

alert tcp any any -> any $IRC_PORTS (msg:"PRIVMSG from #foobar on IRC"; flow:established,to_server; dsize:<64; flowbits:isnotset,botnet.tagged; content:"PRIVMSG #foobar:"; flowbits:set,botnet.tagged; tag:session,1000,packets; classtype:bad-unknown; sid:2000346; rev:4;)