|
あぁ、大それたタイトルだ（笑）。 フリーで使用できる、結構優秀な侵入検知ソフト、snortには、いろいろなプロセッサが実装されていますが、これらについての解説が少ない、と言うお話が某所であったので、覚え書き代わりに書いてみるテストです。 テストですので、網羅できていないかも知れないし、勘違い等もあるかも知れないので、それについては、ご一報下さるととてもうれしいです。 さらに念のため言っておくと、これが元で問題が生じても責任は持ちませんし、snort-users-JPの発端にしようなんてこれっぽっちも思っていません（と牽制しておきます、笑）。 さらにさらに突っ込んでおくと、このページは当分リンク禁止です。なぜならファイル名の綴りが違うから（笑）。ご協力のほど、よろしくお願いいたします。m(__)m snortのプロセッサとは？ snortは、侵入検知を効率よく行ったりするために、取り込んだパケットを前処理します。この時、例えばポートスキャンのような様相を示しているパケットが存在する場合、前処理の段階でポートスキャンである、とアラートを発します。また、snortが、アラートやログを、ログディレクトリに保存するのですが、それ以外、例えばsyslogに保存したり、SQLサーバに転送したりすることができます。これらを実際に行っているのが、プロセッサです。つまり、前処理用のプリプロセッサ、出力用のポストプロセッサがある、と言うわけです。 なお、様々なドキュメントでは、プロセッサと呼ばず、プラグインと読んでいるものも多いのですが、このコンテンツでは、プロセッサと呼ぶこととします。また、断りない限り、snort2.0について記述するものとします。1.9.1などの方が、プロセッサの種類が多いのですが、わざわざセキュリティホールを持つバージョンを使っている人が少ないであろう事、これから使う人にとっても1.9.1について言及したものを今公開することは弊害になるであろう、と言うこともあり、原則として2.0について示します。もし旧バージョンについての言及があった場合、それは「懐古趣味」であると受け止めていただけると幸いです。 プリプロセッサ 先にも示したとおり、プリプロセッサは、snortがキャプチャしたパケットを侵入検知しやすいよう前処理したり、前処理段階でアラートをあげたりするためのプロセッサです。以下に、プリプロセッサのリストを示します。
このように、snortは多くのプリプロセッサを用いて、効率的に処理を（しようと）している事がわかります。 以降では、上記のプリプロセッサについて、役割、及びそれらに対して使用できるオプションを説明していくこととします。 arpspoof arpspoofは、名称の通り、ARP関係の確認を行うプリプロセッサです。ご存じかとは思いますので、詳細は割愛しますが、NIC（事実上ホスト）とIPアドレスを結びつけるために使われるプロトコルです。これらのパケットを監視し、異常を検知した場合にアラートを発します。検知するものは、以下の通りです。
このプリプロセッサのオプションは、「-unicast」だけです。このオプションを付けた場合、先にも示したとおり、unicastなARPパケットが飛ぶたびにアラートを発します。しかし、このオプション「だけ」をつけて運用したとしても、思った効果は得られないでしょう。それは、このプロセッサは、登録されているIPアドレス−MACアドレスについてのみ調査を行うからなのです。 その登録は、arpspoof_detect_hostで指定します。arpspoof_detect_host:IPアドレス MACアドレスという書式で登録します。この対応は１行１つなので、複数登録する場合は、この書式で順次指定していきます。これに登録した時点で、当該ホストが検知の対象となります。 さて、このプロセッサを用いる事で何が実現できるでしょうか。ひとつは、やはり許可されていないホストがネットワーク上にないか検知させる、でしょう。ホストをきちんと登録しておき、使っていないIPアドレスには、架空のMACアドレスを登録し、ネットワーク上のIPアドレスと一意のMACアドレスをもれなく登録しておきます。そうすると、もし仮にネットワーク上に登録されていない（＝許可されていない）ホストが通信を始めようとした場合、通信相手のMACアドレスを調べるために必ずARPリクエストを送信します。これはブロードキャストされるので、必ずsnortマシンにも届きます。使用されていないIPアドレスには架空の、使用されているIPアドレスには本来使用されるはずのMACアドレスが登録されるため、このARPリクエストは必ず登録内容と異なるはずです。そうなると、snortは、「(spp_arpspoof) Attempted ARP cache overwrite attack」というアラートを送信します。このアラートがあがれば、当該ネットワーク上に未知のホストがある、という事になります。 -unicastオプションを付けることで、登録ホストに関係するunicastARPリクエストがアラート対象になるのですが、こちらについてはいまいち利用法が思いつきません。というのも、このオプションを付けると、パケットが飛ぶたびにアラートを出す、と言うことになるので、少々うっとおしい事になるからです。その問題を補ってあまりある利点が思いつけば紹介したいのですが・・・・。 bo ・・・いるのか？このプロセッサ（笑）。 このプロセッサは、BackOrificeが発するトラフィックを検知するプロセッサです。これについては、ドキュメントがろくにないという状況なので、snort.confのコメント及びソースコードから機能を追っかけてみます。そもそも手元にBackOrificeインストールしてあるマシンなんてないし（笑）。 BackOrificeは、１９バイト以上のペイロードを持つUDPを使って通信を行っており、パケットの先頭８バイトにはmagic cookieがあります。magic cookieは、「*!*QWTY?」という文字列となっています。このため、magic cookieを見つけたらアラートをあげればよいのですが、この文字列を、keyから作られた文字列とXORしたものが実際のパケットに使われています。このため、boプリプロセッサは、ブルートフォースでこのmagic cookieを見つけだし、アラートを出しています。 ソースコードを見る限りでは、それ以外の判別は行っていません。 オプションもなく、ただ書いておくだけで使用可能です。ただ、何せUDPパケットを見つけるとひたすらブルートフォースを仕掛けるので、状況によってはボトルネックになってしまわないか、ちょっと気がかりです。どうなんでしょうねぇ。 conversation このプロセッサは、TCP、UDP、そしてICMPで行われている通信のトラッキングを行っています。簡単に言えば、後に説明するstream4プリプロセッサの簡易版と言っていいでしょう。また、このプロセッサは、後に説明を行う、portscan2を使っていることが必要条件となっています。 このプロセッサにできることはあまり多くなく、上記３つのプロトコルでの相互通信を許可するか、通信開始時にアラートを発するか、だけです。コメントアウトされているのも宜なるかな、と言ったところでしょうか。オプションは４つあります。
timeoutは、通信が中断してから、通信が終了したと判断するまでの時間を秒単位で指定します。 max_conversationは、相互通信の最大値を指定します。ちなみに、それを超えたとしてもそれ以上のトラッキングをしないだけです。 alert_odd_protocolsは、allowed_ip_protocolsの逆で、アラートを発するプロトコルをプロトコル番号で記述します。 stream4プリプロセッサが（曲がりなりにも）機能しているsnort2.0では、不要のプロセッサに思えるのは私だけでしょうか？ frag2 このプロセッサは、IPパケットのフラグメントを再構築します。また、フラグメンテーション攻撃（teardropなどのDoS攻撃や、64kバイト以上のフラグメント）を検出します。フラグメントパケットを的確に処理できないIDSは、どれだけ正確なルールを適用していたとしても、そのルールをかいくぐるよう、パケットをフラグメントさせてしまえば、ルールによって検知されなくなってしまいます。 もう少し、具体的に説明してみましょう。TCPヘッダは２０バイト（以上）あり、その後ろにTCPのペイロードがあります。この固まりをIPパケットとして送受信しているわけですが、２０バイトでIPフラグメンテーションさせれば、TCPヘッダとペイロードが別のパケットに格納されることになります。そうすると、例えば、ポート110番に/bin/shと言う文字列が送信されたらアラートを発する、と言うルールをかいくぐることができます。ポート110番という情報はTCPヘッダが格納されたIPパケットにしか入っていませんし、/bin/shという文字列はペイロードが格納されたIPパケットにしか格納されていないからです。 これを防ぐためにも、IDS自体がフラグメンテーションを理解し、再構築した後に検知エンジンに渡す必要があるわけです。この役目をになっているのがfrag2プリプロセッサ、という訳です。 これ以外にも、先に触れたように、teardropの様にフラグメントオフセットをオーバーラップさせることでTCP/IP処理ルーチンを混乱させてしまうような攻撃、非常に大きなIPパケットをフラグメントさせて送ることで同様の効果を得ようとする攻撃などを検知することが可能です。 このプロセッサのオプションは以下のものがあります。
memcapは、frag2が使用する最大メモリサイズをバイト単位で記述します。デフォルトは4MBです。 min_ttlは、許可する最低TTLです。デフォルトは0です。これには若干の説明が必要でしょう。もし、snortの仕掛けてあるマシンと、検知対象のホスト間にルータが存在する場合、そのルータを通過すればTTLが-1されますから、本当に検知対象に届くTTLかどうかを考えて調整すると良いかも知れません。 ttl_limitは、許容されるTTLの最大ばらつきを示します。デフォルトは5です。これ以上の差を持つTTLで、フラグメントされている場合、アラートを発生させます。これは、TTLのばらつきを利用して、IDSを回避する手法があるためです。ただし、当然の事ながら、ルーティングの経路によってTTLは変化しますから、誤検知が生じやすいので、必要に応じてデフォルト値から変化させると良いでしょう。 httpflow このプロセッサを使っている人はいるんでしょうか？（汗 このプロセッサは、HTTPヘッダの後の、HTTPサーバのレスポンスを無視するようにするものです（SnortUsersManual.pdfより）。つまり、Webトラフィックの大半を占める、サーバからのレスポンスを無視することで、処理する必要のあるトラフィックを減らし、パフォーマンスをあげる、と言うものです。これは、サーバからのレスポンスのほとんどは無害である、と言う仮定に基づいています。 ただ、snort.confのどこにもこれに関する定義が書かれていない（コメントとしても書かれていない！）のできっと使っている人は皆無、もしくはソースコードまでまともに読んだ人だけなんでしょうねぇ。かくいう私も使ってませんが(^^; オプションは、以下の通りです。ちなみに、ソースコードのコメントは大嘘つきです。はまりました・・・(>_<）
depthは、パケットペイロード先頭4バイトが「HTTP」でなかった場合（もし先頭4バイトが「HTTP」であれば、問答無用でHTTPレスポンスと見なします）、先頭から何バイト分を検査対象と見なすか、を定義します。このデフォルトは200です。 しかし、微妙にどうかと思うプロセッサに見えるのは私だけでしょうか・・・。 http_decode このプロセッサは、HTTPリクエストを正規化し（%エンコードをデコードします）UNICODEに関するアラートを発します。 オプションは以下の通りです。
unicodeは、UNICODEデコードを行うとともに、UTF-8エンコードとしてイリーガルなものがある場合、アラートを発します。 iis_alt_unicodeは、IISが許可している、風変わりなエンコーディング形式（%c0%afなど）や%uエンコーディングをデコードします。 double_encodeは、文字通り、UNICODEエンコード文字列をさらにUNICODEエンコードしている場合（%xxを%25xxとしている場合）をチェックします。 iis_flip_slashは、IIS用に、\を/に変換します。 full_whitespaceは、Tab（\t）を（\rも）スペースに変換します。これはApacheのためのものです。 ここまでは、snort.confやSnortUsersManual.pdfにも書かれていますね。 abort_invalid_hexは、許可されていない文字が送信された場合に、処理をうち切るかどうかを規定します。 drop_url_paramは、URIのパラメータ部（一般的に「?」以降）のUNICODE処理を行うかどうかを規定します。 internal_alertsは、このプロセッサが以下に示すアラートを発するかどうかを規定します。アラートは、「異常に大きなHTTPメソッド」「URIのないメソッド」「ダブルエンコード」「イリーガルなキャラクタ」「イリーガルな、長いUNICODEキャラクタ」です。 iis及びapacheは、snortが監視対象としているWebサーバがどちらかの場合、それを指定しておく、と言うものです。iisの場合、unicode、iis_alt_unicode、double_encode、iis_flip_slashが指定されます。apacheの場合、full_whitespaceが指定されます。 昔あった、UNICODE攻撃やNULLバイト攻撃のアラートを出さない、と言うオプションは見あたらないようです。しかも、snort.confにある、UNICODE攻撃やNULLバイト攻撃に関するアラートを出すようになって「いない」ように思えます。私の目が節穴なのでしょうか？ perfmonitor snortのパフォーマンスモニター用プリプロセッサです。と言っても、情報は、「アウトプットのフォーマットと引数（オプション）は予告無しに変更される」という文言とソースコードのみという状況なので、ここでもソースコードからたどっていきます。なお、文言にもあるとおり、いつ、どのように変更されるかわかりません。ここでの情報はsnort2.0を対象とし、それ以外のバージョンについては保証しません。 オプションは以下の通りです。
以降の説明は本当かどうか確信が持てないので、使ってみたい方は自分でチェックして使って下さい。m(__)m timeオプションはサンプリング時間を規定しています。どのサンプリング時間かは知りません（苦笑）。 eventsオプションを付けることで、サンプリング時間中に処理された（もしくはされなかった）イベントの統計をとります。 maxオプションはよくわかりません（藁 console、file、snortfileオプションを指定すると（file、snortfileオプションはファイル名を引数に持ちます）それぞれ統計結果をコンソール、ファイル、snortのログファイルディレクトリに保存（表示）します。 pktcntは、名前から想像するにカウントするパケット量を指定します。 ・・・・ソースコードが４つくらいに分かれているので追っかけるのが面倒なんですよねぇ。と言うことで、これはこの辺で勘弁して下さい。 portscan 今ではstream4プロセッサに代替わりしていると思うのですが、未だに使用可能なポートスキャン検知用プロセッサです。単純にしきい値以上のトラフィックがあったりした場合にアラートを出す、と言うものなので、誤検知しまくっていた曰く付きのプリプロセッサです。もちろん、いかにもポートスキャンというパケットの場合はしきい値など無視してアラートを出します。 オプションと言うより、書式（この通りでないとうまくいかないので・・・）は以下の通りです。 IPアドレス／ネットマスク ポート数 秒数 ファイル名 IPアドレス／ネットマスクは、検知対象とするアドレス範囲を入力します。ポート数と秒数は、「何秒以内にいくつのポートにアクセスがあった場合、ポートスキャンと見なす」かの値を入力します。ファイル名は、ログファイル名を入力します。 このような定義ですので、ちょっとしたことでポートスキャンと見なしてしまいます。ですから、ポート数と秒数は、あり得ないくらいの数字を入れておいた方が良いかと思います。この場合、ポートスキャンと見なされるのは、FINスキャンなどの、明らかにスキャンパケットであると見なせるパターンのみとなります。 また、例えばあまりに誤検知が多く、このホストだけは検知対象から外したい、などの場合には、portscan-ignorehostsで定義します。IPアドレス/ネットマスクをスペース区切りで指定していきます。 まぁ、今更使うか？って気もしますけど。 portscan2 こちらも現在の主流とは言えなくなってしまったポートスキャン検知用プリプロセッサです。conversationプロセッサを使用している場合のみ、このプロセッサが使用できます。２つで一組、という所でしょうか。 conversationプロセッサと組み合わせて使う、と言うことからも想像できるとおり、portscanプロセッサとの最大の違いは、ステートを考慮したディテクターとなっていることです。このため、（使ってないのでわかりませんが）portscanプロセッサに比べ、誤検知が減少しているであろう、と考えられるわけです。 オプションは以下の通りです。
targets_maxは、スキャン対象とされている可能性のあるホストを何台まで検査対象とするか、を規定します。これもデフォルトは1000ですから、たいていのネットワークで足りなくなることはないでしょう。実際に監視対象としているホストの数を勘案して数値を決めると良いかと思います。 target_limitは、スキャンであると判断するためのしきい値（何台のホストに対し、スキャンをかけているか）です。これは、ふつうの通信と区別しにくい、SYNスキャンを検知するために使用されていると思われます。 port_limitも同様にしきい値（ホストのいくつのポートに対しスキャンをかけているか）です。 timeoutは、スキャンの終わりを規定します。すなわち、ここで指定した秒数の間スキャンが行われなかったとき、スキャンが終わったと見なします。 logは、ログファイルを格納するディレクトリを指定します。 また、portscanプロセッサと同様、検知対象から外したいホストがある場合には、portscan2-ignorehostsで指定します。書式も同様に、IPアドレス／ネットマスクをスペース区切りで記述します。 まぁ、stream4プロセッサで検知させた方が何かと良い様な気もしますが、そこは好きずきでお願いします。 rpc_decode rpc_decodeプロセッサは、断片化されたRPCレコードを正規化します。これは、（SnortUsersManual.pdfによれば）後述するstream4プロセッサが有効になっている場合、クライアントサイドのトラフィックだけを正規化します。と言うことは、stream4を使っていない場合にはサーバサイドのトラフィックも正規化する、と読めるんですが、どうなのでしょうね。（ソース読め＞自分） オプションは以下の通りです。
no_alert_multiple_requestsは、一つのパケット中に複数のRPCレコードがあったとしてもアラートをあげないようにします。 no_alret_large_fragmentsは、断片化されたレコードを正規化したとき、一つのパケットサイズに収まらなかったとしてもアラートをあげないようにします。 no_alert_incompleteは、一つのレコードが、一つのパケットに収まりきらず、断片化されてしまっている場合でもアラートをあげないようにします。 まぁ、このプロセッサはどちらかと言えばLAN監視用、と言うことでしょうか。NFSなんか使っている場合などでしょうか。WindowsのRPCはどうなんでしょうねぇ。 stream4 stream4プロセッサは、ストリームを再構築するとともに、ステートフルインスペクションを行うプロセッサです。まず、ここで、「なぜストリームを再構築する必要があるのか」について簡単に説明しておきます。 といっても、簡単な例を示せば、きっと納得できると思いますので、実例で示します。 もし、ストリームを再構築していなかったら、snortのような、パケットキャプチャベースのIDSは、ひとつのTCP/UDPパケットを対象に、安全なパケットか、危険なパケットか、を判断します。 ここで、仮想の、httpサーバの脆弱性を作ります。「hoge!」とリクエストすると、バックドアが自動的に開く、というものです（もちろん、そんなばかげたサーバはこの世に存在しません）。 一般的に、「hoge!」というリクエストは非常に短い（5文字＝5バイト）ため、これならば一つのパケットに十分収まります。ですから、パケットベースのIDSは、「hoge!」（しつこいなぁ:-P）というリクエストを、パケット中から簡単に見つけることができます。 では、「hoge!」を、「ho」と「ge!」の２つに分けたら、どうなるでしょう。一つのパケットに「ho」、もう一つのパケットに「ge!」と入っているため、「hoge!」を探しても見つかりません。これでIDSをかいくぐることが可能となってしまいます。 そこで、通信内容を一つながりとしてチェックしなければならない、と言うことになります。この一つながりにする、という行為が、すなわちストリーム再構築なのです。ストリーム再構築を行うことにより、「ho」と「ge!」にわかれていた通信内容が、「hoge!」に繋がります。その上で実際にパケット内容をチェックするエンジンに渡せば、すり抜けはできません。 これが、ストリーム再構築が必要な理由です。 もうひとつの、「ステートフルインスペクション」というのは、ファイアウォールの機能説明などで見たことがあると思います。これについても、簡単に説明しておきます。 これも、簡単な説明（TCPのポートスキャン）を例に取りたいと思います。ポートスキャンには、通常の接続要求を出して、その反応を見るものもありますし、通常ではあり得ない通信を送ってみて、その反応を見るものもあります。 通常の接続要求は、3way-handshakeと呼ばれるものを確立しようとして、3wayの２つめ（サーバからの応答）がSYN-ACKであれば空いている、RSTであれば閉じている、と判断します。これを利用してポートの空き具合をチェックします。その後、つまり3wayの最後のパケットをどうするかによって、スキャンはさらに２種類に分かれます。一つはそのまま通信を確立する場合、もうひとつは、RSTパケットを送付して通信を止めてしまう場合です。前者は、通信を確立するので、ここまでの段階では、通常の通信と見分けがつきません。ただし、サーバのログに、通信開始の証拠が残ります。後者は、通信を止めてしまうので、ログには残りませんが、通常とは明らかに異なります。 通常でないものとして、FINスキャンを例に取りましょう。これは、いきなり終了の合図である、FINパケットを送りつけるのです。ポートがオープンしている場合、これはエラーパケットと見なされ、無視されますが、ポートが開いていない場合、サービス不能の意味であるRSTパケットを返します。これでポートの空き具合を見るのです。 さて、都合３種類のポートスキャンを例示しました。これをIDSの立場に立って見てみましょう。先にも示したとおり、パケットキャプチャ型IDSは、１つ１つのパケットを検査しますから、パケットの相互関係は見たくても見れません。もし、FINスキャンを検知したければ、FINパケットが通過したらアラート、というルールを作る必要があります。ところが、通信の終了の合図もFINパケットです。そうなると、通信終了のたびにアラートが発生します。それはどうかと思いますよね。また、3way-handshakeの３つ目で通信を止めてしまうようなスキャンの場合はどうでしょう。これは、３つのパケットが、SYN、SYN-ACK、RSTとなって初めてスキャンだ、とわかるのですが、相互関係を監視できない以上、これを検知できない、と言うことになります。 そこで、ステートフルインスペクションの登場です。これは、通信の流れそのものを検査する、と言うことです。先に示したとおり、通信は開始時に必ず3way-handshakeを行い、その手順は決まっています。ならば、あるホストからの最初の通信は必ずSYNパケットです。それ以外のパケットが来た場合、明らかにスキャンである、と言えるでしょう。同様に、3wayの３つ目がRSTであれば、明らかにスキャンである、と判断できるでしょう。では、3way-handshakeをまともに行うタイプのスキャンでは？通常、スキャンは一つのポートのみ、とは限りませんから、そう言った部分からも判断できるわけです。 だいぶ端折った感もありますが、これがステートフルインスペクションです。 さらに、このステートフルインスペクション機能を用いることで、もうひとつの機能をも与えてくれます。それは、いきなりアラートのあがりそうなパケットを大量に送信することで、実際の攻撃の痕跡を隠したり、ログをあふれさせようとする攻撃を無害化してくれるのです。これは、通常の通信を行っている最中に検知できた攻撃パターンのみを拾い出し、通信が確立されていないのにも関わらず、攻撃パターンを送信された場合（もちろん、これは本当の攻撃ではなく、ダミーです）でも、それにIDSが反応する事がないようにするのです。これは、snot、stickなどと言ったIDS各欄ツールの影響を最小限にすることが出来る、と言うことです。 上記の説明でもわかるとおり、パケットキャプチャ型で、１つ１つのパケットを検査するようなIDSにはできない検知手段を与えてくれる、stream4プロセッサは、snortになくてはならないものである、と言って過言ではないでしょう。 さて、このプロセッサ、多機能なだけに、プロセッサそのものも２つ（stream4とstream4_reassemble）に分かれており、また、オプションも多岐に渡ります。
気を取り直して、一つずつ見ていきましょう。 noinspectは、その名の通り、ステートフルインスペクションを行うかどうかのスイッチです。 asynchronous_linkは、マニュアルにありません。これを指定した場合、サーバ側もしくはクライアント側が、通信確立と見なせる状態になっていれば、通信確立と見なすようになります。デフォルトは、サーバ側クライアント側ともに通信確立と見なせる状態になっている場合に通信確立と見なします。（違っているかも知れない・・汗） keepstatsは、通信に関する情報を出力します。指定した場合、デフォルトでは人間が読みやすいよう整形されて出力されますが、machineおよびbinaryを指定した場合、それぞれ処理しやすいテキスト形式、バイナリ形式で出力されます（されるようです・・・汗） timeoutは、通信がまだ続いているかどうか判断する時間のしきい値で、秒単位で指定します。デフォルトは30秒です。 memcapは、stream4が使用する、セッション用のメモリ量です。これを超過した場合、アクティブでないものから順次切りつめてしまいます。なお、指定はなぜかバイト単位で、デフォルトは8MBです。 detect_scansは、文字通りポートスキャンを検知するかどうかのスイッチです。検知できるスキャンは、ステルス、フルXmas、SYN_ACK_PSH_URG、FIN、SYNFIN、NULL、nmapのXmas、vecna（なんだそれ？不勉強だ・・・萎え）、nmapのフィンガープリンティングとなっています。 log_flushed_streamsも、マニュアルにありません。これを指定した場合（かつ、tcpdump形式を指定している場合）、ストリームをフラッシュするときにログを取る、という事のようです。そうにしか読めない罠。 detect_state_problemsは、TCPのステートに問題がある場合、例えば、SYNパケットにデータが入っている、などの場合、アラートを出すかどうかのスイッチです。 disable_evasion_alertsは、チェックサムがあわない、とかTCPオーバーラップなど、TCPの仕組みを悪用して検知を回避している可能性のあるパケットに対しアラートを出さないようにするスイッチです。 ttl_limitは、TTLの最大ずれ量を規定します。これ以上TTLがずれている場合、やはり検知回避とみなし、アラートを出します。デフォルトは5となっています。 self_preservation_threshold以降は、マニュアルにありません。ソースコードが多分唯一のドキュメントでしょう。（state_protectionをググって見たけどないみたいだし、号泣）がんばっていきます。 順序が上のリストと違いますが、まず、state_protectionからいきましょう。これは、stream4が、短時間に大量のストリームを処理しなくてはならない状況に陥ったとき、snortの過負荷を抑えるようにするかどうかのスイッチ、の様に見受けられます。 self_preservation_thresholdとself_preservation_periodは、"emergency mode"に入るかどうかのしきい値を示しており、それぞれ、新しいセッションが1秒当たりいくつ発生しているか、"emergency mode"にはいってから何秒後にこのモードから復帰するか、を規定します。これらのデフォルトは、それぞれ50セッション/秒、90秒です。 次に、suspend_thresholdとsuspend_periodです。これらは、stream4を止めてしまうためのしきい値です。上と同様に過負荷対策なのでしょうか。しきい値のそれぞれの意味は上と同様で、デフォルトはそれぞれ200セッション/秒、30秒です。 止めてしまう、というのはわかりますが、"emergency mode"って、なんでしょうね。ソースコードのコメントによれば、SYNフラグから始まっているもののみを新しいセッションと見なして処理をする、と言うことなので、まともな通信と思われるもののみ処理する、と言うことのようです。とにかく、snort自体がパケットを落とすことがないようにするためのモードのようです。 ・・・・ふぅ、やっとstream4が終わりました。次はstream4_reassembleに目を向けましょう。 まず、clientonly、serveronly、bothです。これらは、どちらの通信内容を再構築するか、を示します。それぞれ、クライアント側通信、サーバ側通信、双方をそれぞれ再構築する、という事になります。デフォルトは、clientonlyです。 noalertは、このプロセッサはアラートを出さない、と言う宣言です。指定しない場合、アラートを出します。 ２つ飛ばして、portsは、どのポートを使用している通信を再構築するか、です。デフォルトでは、「21、23、25、53、80、143、110、111、513、1433となっています。 さて、favor_old、favor_newです。デフォルトでは、favor_oldが指定されたことになります。しかし、このオプション、指定はできますが、ルーチン内で使われている形跡がありません。なぜでしょう。 なお、stream4で触れた、過負荷抑制用（と思われる）パラメータ群は、こちらでも有効のようです。 さて、最後に、通信確立時のみ検査対象とする、と言う機能ですが、デフォルトではこの機能は使われていません。この機能を使うためには、コマンドラインオプションで、「-z」を付ける必要があります。これを付けている場合、snotやstickのような、大量の誤検知パケットを送信して攪乱する、と言う攻撃手法が無害化されます。 telnet_negotiation telnet_negotiationは、snort.confで指定する際のプロセッサ名をtelnet_decodeと言い、telnetのコントロール用キャラクタを正規化します。 オプションは、ポート番号だけです。また、指定しない場合は、21、23、25、そして119について、正規化を行います。 telnetのコントロールに関するキャラクタは詳しくないので、いつか説明したいな、と思っています。思うだけ。 2.0でサポートされなくなったプロセッサ（asn1_decode、fnord） 上記２つのプロセッサは、現在、snort2.0ではサポートされていません。一応、また復帰するかも知れないので、簡単な説明だけ付けておきます。わざわざソース読んでまでチェックはしていませんので、ご了承下さい。 まず、asn1_decodeはASN1プロトコルをチェックし、プロトコルを不正利用していないかどうか検知します。fnordは、シェルコードを変形させる（ポリモーフィックと呼ばれています）ことで、IDSの検知から逃れようとしているパターンを見つけだすプロセッサです。 少なくとも、fnordは、その着眼点は非常に重要なものだと思っているので、是非、いつか復活して欲しいと思っているプロセッサだったりします。ASN1プロトコルは、私は詳しくないので、こちらのデコーダは、判断を保留しておきます（汗）。 |