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

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

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

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

Спасибо.

-Aymen

1 Ответ

2 голосов
/ 11 марта 2012

Я не думаю, что полностью понимаю, что вы пытаетесь сделать с этим правилом.Не могли бы вы уточнить детали того, почему вы ищете просто 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;, доступный в 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;)
...