0

alert tcp any any -> any any (msg:"PRIVMSG from an IRC channel suspicious act"; content:"PRIVMSG"; offset:0; depth:7; nocase; dsize:<64; flow:to_server, Established; tag:セッション、300、秒; クラスタイプ: 不明な不良; sid:2000346; rev:4;)

上記のルールは、ボットマスターへのメッセージに応答するボットを監視するために書かれています。ルールは正常に機能していますが、1 つのボットが応答し、複数のホストが同時に応答しているときにアラートがないか、1 つのホストに対してアラートが 1 つでもある場合のみです。セッション時間を 30 または 150 に変更しましたが、うまくいきません。

効率化するためのヒントやコツはありますか？

ありがとう。

-アイメン

4

1 に答える 1

2

このルールであなたが何をしようとしているのかを完全に把握しているとは思いません。チャンネル名のない PRIVMSG だけを探している理由 (さらに言えば、ボットのニックネームも) の詳細を明確にしていただけますか?

とはいえ、ルールをより効率的にするためのいくつかの簡単な提案があります。必要に応じて調整します。

  • dsizeおよびflow「個別の」オプションと見なされ、ペイロード オプション (contentおよびその修飾子など) の前に指定する必要があります。離散オプションは通常、プロトコル固有のフィールドをチェックし、ペイロードには決して触れないため、非常に高速です (高速パターンマッチャーに次ぐ)。つまり、 のflow後に来るようにしmsg、次に のdsize後にする必要がありますflow。

  • 次に、タイマーの設定がtag高すぎる可能性があります。tagには と呼ばれる組み込みのカットオフがtagged_packet_limitあり、デフォルトは 256 パケットです。したがって、ルールは、考えられる 3 つの条件のいずれか (最初に発生した方) でタグ付けを停止します。

    • セッションの終了。
    • 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;

    これにより、ルールに一致する別のパケットが送信されたときにタグ付け操作が中断されるのを防ぐことができます。これは、flowbits により、ルールがすでに一度アラートを発し、現在対象のトラフィックにタグ付けされていることが強制されるためです。

  • 一般的な IRC ポートの変数を定義し、それを宛先ポート フィールドで使用する必要があります。Snort は、高速パターン マッチャーと組み合わせて宛先ポート フィールドを使用して、パケットがチェックされるルールを最適化します (つまり、HTTP トラフィックは、IRC をターゲットとするルールによってチェックされるべきではありません)。宛先ポートの代わりに、ソース ポートを使用しようとします (詳細はsrc/pcrm.c、ソース コードの上部にあるコメントで確認できます)。ターゲット IRC サーバーが 1 つのポートのみを使用する場合は、代わりにそれを使用します。単一のポートはポートのグループよりも優れていますが、ポートのグループは単なるものよりもはるかに優れていますany。

    portvar IRC_PORTS [6666:6669]

  • 最後に、高速パターン マッチャーを真に活用するには、一意の文字列を使用する必要があります。 PRIVMSGIRC プロトコルでは非常に一般的なため、ルールを非常に特定のチャネルに制限しようとしている場合は、次のようなものを検討してください。

    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;)
于 2012-03-11T11:34:18.510 に答える