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

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

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

Любые советы или приемы, чтобы сделать его эффективным?

Спасибо.

-Аймен


person Aymen    schedule 05.03.2012    source источник


Ответы (1)


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

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

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

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

    • End of the session.
    • Через 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;)
person Kumba    schedule 11.03.2012
comment
Вы проверили предложенное правило? Выглядит хорошо, но я не знаю, почему это не работает для меня... - person Aymen; 13.03.2012
comment
Как вы сказали, #foobar - это конкретное имя канала, поэтому правило не работает для неизвестного имени канала. - person Aymen; 06.05.2012