next up previous contents
Next: 出力の設定 Up: Snortの設定 Previous: 変数の設定

プリプロセッサの設定

プリプロセッサは文字通り監視ルールの前処理のルーチンの意味であるが、 様々なプリプロセッサを組み込めるようになっている。 通常、特に変更する必要はないであろう。

プリプロセッサの指定の書式は一般に以下のように行う。

     preprocessor  <プリプロセッサの名前>: <オプション>

  1. HTTP Decode

    HTTP リクエストにおける %XX 形式の文字の変換などを行う。
    
         preprocessor http_decode: 80 8080
    
    なお、オプションは対象となるポート番号であり、もし Unicode 文字列 や CGI の null code アタックの検知を無効にしたい場合には、更に オプション -unicode-cginull を付け加える。
    
         preprocessor http_decode: 80 8080  -unicode  -cginull
    

  2. Portscan Detector

    このプリプロセッサにおけるポートスキャンの定義は、T秒内にP個以上のポート に対して、TCP コネクションの試み、あるいはUDPパケットが届くようなような 状態を指している。 ある単一のソースIPから、単一宛先IPの複数の宛先ポートへの接続や、複数 宛先IPへのポート接続が対象である。つまり、ここでは、single->single, single->many のパターンがその対象となっている。(ちなみに、 分散ポートスキャン(distributed portscan)は次のフルリリースで対応予定 となっている。)

    
         preprocessor portscan: <ネット>  <ポートの数>  <time>  <ログファイル>
    

    ここで、 ネットは監視対象ネットワーク、ポートの数及びtimeは上記の P と T のことであり、ログファイルである。但し、ログファイルについては、 通常警報は標準警報用ファイルにも出力されるのだが、それに加えて別に ログをとると言う意味であり、通常出力に加えて、スキャン対象のIPやポート も記録される。また、ログファイルの位置はコマンドラインオプションで 与えるが、省略した場合のデフォルトは /var/log/snort/ であり、この ディレクトリは予め作成しておかなければならない。

  3. Portscan からの除外

    PortScanを設定すると、内部ネットワークでは当然あり得る通信がPortScanとして 警告される場合があり、面倒な場合はそれを予め除外する事が出来る。特に、 DNS からの UDP パケットは、ポートスキャンと間違われやすいので、ここに DNS サーバを記載しておけば良いであろう。 マスク表現も可能であるので(X.X.X.X/YY)、煩わしい場合にはネットワークごと 除外が出来るが、内部からポートスキャンされる場合もあり得るので、ホスト単位 での指定の方が良いだろう。また、複数記述したい場合には、空白で区切れば 良い。

    
         preprocessor portscan-ignorehosts: 192.168.0.17
    

  4. new IP defragmentation support

    fragmentation を起こしたIPパケットの再構築のためのプラグイン。 fragmentation attack を検知出来ます。
    
         preprocessor frag2: timeout [seconds], memcap [bytes]
    
    タイムアウト時間はデフォルトは 30 sec. 、fragment packet のために 用いるメモリ量の上限でデフォルトは 4MBytes。 デフォルトのままでも問題ないであろう。 つまり、
    
         preprocessor frag2
    
    で良い。

    IPパケットのfragmentationは、経路上で起こる事があり正常なもので あるが、これをアタックに利用される場合がある。こうした場合で 注意しなければならないのは、IP fragmentation がネットワーク層で 起こる事であり、トランスポート層(つまり、TCPやUDP)で起こるのでは ない点である。すなわち、fragment化したパケットにはIPヘッダーは あるが、TCP または UDP ヘッダーはないのである(先頭のパケットのみ が持ち、後続パケットにはない)。従って、こうしたトランスポート層 のヘッダーについて検査しようとするならば、過去の記憶を持たなければ ならず(つまりは再構築)、こうした機能のないFirewallでは検査出来ない のである。なお、ICMPについても実は同じで、IPヘッダーレベルで 起こるfragmentation は、その後に引き続く ICMP プロトコルヘッダー には何もしないのである(つまり、TCP,UDPと事情は同じ)。

  5. Stream4

    TCPストリームの再構築と、TCPのステートフルな解析のためのモジュールで、 stream4stream4_reassemble の2つの部分からなる。 通常、前者についてのみオプションを設定し、その他はデフォルトで良い。

    
         preprocessor stream4: detect_scans
         preprocessor stream_reassemble
    

    デフォルト値は以下の通りである。

    Options Default
    Timeout 30 sec.
    memcap 8Mbyte
    Stateful Inspection Active
    Stream stats InActive
    State Problem InActive
    Portscan InActive

    Options Default
    Reassemble client Active
    Reassemble server InActive
    Reassemble Ports 21 23 25 53 80 143 110 111 513
    Reassembly Alerts Active

    つまり、デフォルト値に対して、Portスキャンのみをonにしている訳である。

    また、Stream4 モジュールは更にコマンドラインのスイッチを用いて、 コントロールする部分がある。このスイッチ -z-k では 後程取り上げよう。

    この項目は、IP fragmentation と混同してはならない。TCP reassemble はTCP stream において、実際の通信データが細分化されて送られるために、 後の中身のデータに対する検査が十分に行えなくなるのを防ぐためにある。 つまり、TCP reassemble とは、オリジナルのデータパケットの細分化 ではなく(IP fragmentation の本来の原因)、元々のTCPのデータが細分化 されて送信されているものを再構成する事である。

  6. RPC Decode

    RPC のポートをオプションに与え、通常デフォルトで良い。 HTTP Decode と同じような役割を担っている。
    
         preprocessor rpc_decode: 111 32771
    

  7. Back Orifice

    Back Orifice は Windows に対するトロイの木馬プログラムで、 遠隔地からの操作を可能にするクラッキングツールである ("Cult of The Dead Cow" という集団が開発・配布している)。 この Back Orifice のprotocolを解釈するのが、このプリプロセッサで あり、通常 encrypt key に 31337 を用いる(BO のデフォルト値)。 引数は、-nobrute と上記の encript key の値であるが、 通常 -nobrute を指定しないと、BO を徹底的に探すが、かなりの CPU パワーを浪費するとして警告されている。デフォルトまたは コメントアウトしても良いであろう(BO preprocessor は Snort 1.9.x では なくなっているのと、通常ウィルス駆除ソフトで駆逐できるので)。

    
         preprocessor bo: -nobrute
    

  8. Spade

    Silicon Defence によって開発途中のプロジェクトの一部分がこの プリプロセッサである。このプロジェクトは、Spade/SPICE からなり、 後者はまだ公開されていない。Spade は、異常なパケットを発見し、 それらに anomaly value をつける(統計的に少ないものと思っても良い)。 そして、その anomaly value が一定以上になった時点で警報、あるいは レポートを出す。但し、Spade では個々の異常なパケット間の相関に ついては考えず、SPICE が相関を司るようになっている。こうした処理 は、例えば非常にゆっくりとしたポートスキャンや、あるいは乱数処理 されたポートスキャンに対しても有効であると考えられている。

    面白いプロジェクトではあるが、開発途上であり、ここでは詳しくは 取り上げない。興味ある人は以下を参照して欲しい。

    
    http://www.silicondefense.com/software/spice/
    


next up previous contents
Next: 出力の設定 Up: Snortの設定 Previous: 変数の設定
Noriyo Kanayama