Проблема с правилами Snort для отслеживания активности IRC-серверов

alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg: «Сообщение IRC-трафика BOT, обнаруженное изменением ника»; поток: to_server, установлен; содержимое: «NICK»; без регистра; смещение: 0; глубина: 5; потоковые биты: набор, community_is_proto_irc; потоковые биты: noalert; тип класса: разная активность; sid: 100000240; версия: 3;)

alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg: «Обнаружен внутренний IRC-сервер COMMUNITY BOT»; поток: to_server, установлен; потоковые биты: isset, community_is_proto_irc; тип класса: нарушение политики; sid: 100000241; версия: 2;)

alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg: «Сообщение CHAT IRC от внутреннего бота»; поток: установлен; потоковые биты: isset, community_is_proto_irc; содержимое: «PRIVMSG»; nocase; тип класса: нарушение политики; sid: 1463; )

Приведенные выше правила написаны Дэвидом Бьянко. для отслеживания активности бота/сервера IRC на любом порту IRC. Однако приведенные выше правила работают нормально, но у меня с ними проблема. Моя проблема возникает, когда несколько IRC-серверов (некоторые из них работают на 7000, а другие работают на 6667) работают в сети, некоторые из них достигают условий правил, и Snort генерирует предупреждения, а некоторые из них (или даже один) из них) не будет выполнять эти условия, и в результате Snort не будет генерировать никаких предупреждений, связанных с определенным набором. Я думаю, что есть какое-то несоответствие. Есть предложения по этому вопросу? Я работаю над Snort 2.8.


irc snort botnet
person Aymen    schedule 06.05.2012    source источник

Ответы (2)


arrow_upward
3
arrow_downward

Эти правила IRC довольно старые и не будут (как вы видели) захватывать весь трафик IRC. Почти невозможно сказать, почему они не совпадают с захватом сети или трассировкой.

Первому правилу задается бит потока на основе правила, соответствующего трафику (на основе нечувствительного совпадения слова «NICK» со смещением 0 для глубины 5), если первое правило не соответствует трафику, тогда оно выиграет. t установить бит потока на «community_is_proto_irc». Вот старое объяснение потоковых битов — http://forums.snort.org/forums/rules/topics/flowbits.

Второе правило просто предупреждает о наличии бита потока (для трафика извне в домашний), в то время как третье правило более детализировано с соответствием содержимого (и направлением потока трафика).

Я бы порекомендовал получить pcap для несоответствующего IRC-трафика и запускать его через Snort локально, чтобы увидеть, что пропускается, а затем соответствующим образом адаптировать свои правила (snort -r test.pcap -c /etc/snort_test.conf) - http://manual.snort.org/node8.html.

ХТХ!

person Mark Hillick    schedule 10.05.2012
comment
Спасибо за ваше разъяснение, но моя проблема заключается в пометке нескольких онлайн-серверов IRC, работающих одновременно. - person Aymen; 10.05.2012
comment
Так разве этот трафик не содержит строку NICK в первых 5 байтах? - person Mark Hillick; 10.05.2012
comment
Вы сделали захват и повторно запустили его через Snort с вашим конфигурационным файлом? - person Mark Hillick; 10.05.2012
comment
Да, часть серверов захвачена, а часть нет. - person Aymen; 10.05.2012
comment
Единственное, о чем я могу думать в данный момент, это то, что они не являются частью переменной $HOME_NET в файле snort.conf.... в данный момент мне больше ничего не приходит в голову. - person Mark Hillick; 10.05.2012
comment
Все серверы находятся в $HOME_NET. Например, когда вы выполняете тест на Vmware, оба адреса 192.168.1.2 с Dst. порт 7000 и 192.168.1.3 с Dst. порт 6667 может быть захвачен, но при повторении того же теста только один из них будет захвачен этими правилами. Надеюсь, вы поняли мою точку зрения. Спасибо - person Aymen; 10.05.2012
comment
Я не уверен, что вы говорите. Где вы ищете захват? В чем-то вроде Sguil, Snorby и т.д.? Или журнал Snort сообщает о файле/каталоге? - person Mark Hillick; 11.05.2012

arrow_upward
0
arrow_downward

Слава богу, теперь проблема решена.... Причиной проблемы был конфликт между многими правилами, которые пытались срабатывать одновременно для одной и той же активности (PRIVMSG), поэтому, когда я удалил эти правила, все мысли были просто штраф за вышеуказанные правила.

person Aymen    schedule 02.06.2012
comment
Из любопытства, какие правила вы удалили? Трафик не соответствует нескольким правилам, он может соответствовать только одному, поэтому я предполагаю, что вы удалили те, которые изначально были затронуты? - person Mark Hillick; 21.06.2012
comment
В моем случае были некоторые правила, пытающиеся захватить сообщения PRIVMSG. Итак, я просто прокомментировал нежелательные, чтобы избавиться от их влияния на нужные правила. - person Aymen; 22.06.2012