39360.zip
拡張性と効率性を備えたオープンソースのネットワーク侵入検知システム (NIDS) は、明確に定義された一連のルールを使用してネットワーク上で異常なパケットを検出します。 これらのルール セットを維持することで、システムの有効性が劇的に向上します。 ルール管理のテクニックをいくつか紹介すると、Snort IDSのメンテナンスに役立ちます。 まず、変数の定義を厳密化し、Snortのルールを整備することで、アラートの過負荷を防ぐことができます。 また、ルールセットのアップグレード時にカスタムルールを持続させることもできます。
デフォルトでは、図1に示すように、Snortには、タイプ別に整理された約50のテキスト ファイル内に1900以上のストック ルールが含まれています。 これらのルールは、Windows、UNIX、およびMicrosoft IIS、Apache、Microsoft SQL Server、Oracle SQLなどの広く使用されているアプリケーションに関する多くの既知の脆弱性攻撃に対する応答トリガを定義しています。 また、このルールは、ネットワーク スキャンやSNMPのデフォルト コミュニティ文字列をブロードキャストしているマシンを警告するための偵察データおよび可能な構成警告をSnortが提供するのに役立ちます。 想像できるかもしれませんが、Snortは膨大な数のアラートを生成することができます。 ストック ルールのノイズを減らすため、Snortのデフォルト設定では、デフォルトで約1300のル ールのみを有効にし、ポリシー、チャット、ウイルスなどのルール タイプ全体をデフォルトで 無効にします。 (ルール タイプは通常、独自のテキスト ファイルに含まれているため、ウイルス タイプのルールは virus.rulesというファイルに含まれています。)
ルールを整理する
Snortがデフォルトで無効にしている多くのルールでも、Snort IDSシステムは多くのアラートを生成する可能性があります。 これらのアラートをすべて無視すると、本当に疑わしいトラフィックに対する感覚が鈍る可能性があります。 Snortを環境にインストールしたら、ルールを整理して、環境に関係ないものや 関心のないものを削除してください。 たとえば、HTML埋め込み型のスクリプト言語であるPHPがない場合。 ハイパーテキスト・プリプロセッサー)がインストールされていない環境では、web-php.rules ルール・ファイルを無効にすることができます。 ただし、どのルールを無効にするかを決める際には、自分のマシンにさまざまなソフトウェアが入っている可能性のあるユーザーのことを考慮してください。 たとえば、Snortセンサーの1つが、VPN接続を介して、感染した自宅のマシンから不審なパケットを拾うかもしれません。 先ほどの例でいえば、会社のコンピュータにPHPがインストールされていなくても、エンドユーザーの1人が自宅にPHPをインストールしている可能性があるということです。 もし、その自宅のコンピューターが PHP の脆弱性を利用して侵入された場合、攻撃者は、侵入されたコンピューターが (VPN などで) 企業ネットワークにリモート接続している間に企業ネットワークにアクセスすることができるかもしれません。
ほとんどの警告およびレポートシステムは、簡単に参照できるように各規則の名前と SID を表示しています。 有効なルールのリストをさらに削減するには、システムを監視し、不要なルールの名前またはSIDを書き留めてから、それらのルールを無効にします。 Snortルールを手動で無効にするには、ルール ファイルを開き、ルールの前にシャープ記号 (#)を挿入します。 ルールのクラス全体を無効にするには、Snort設定ファイルのルールファイル名の前にパ ウンド記号を追加します。 変更したルールを読み込むには、Snortを再起動する必要があります。
ルールを定期的に見直し、ネットワークに適用されないルールを削除し続けることで、Snortが生成するアラートの数が劇的に減少し、本当に疑わしいパケットの発見と識別が容易になります。
Keep Rules Current
Snort.org では、2 つのバージョンの Snort ルールが公開されています: snortrules-stable と snortrules-current で、それぞれ Snort 2.0x と Snort 1.9x で使用できます。 新しいルールには、シグネチャの追加や、拡張変数を使用するための既存のルールの更新が含まれています。 たとえば、バージョン2.0.0のルールでは、特定のマシン機能を具体的に示す変数を定義しています(たとえば、変数HTTP_SERVERSやHTTP_PORTSは、Webサービスを実行しているコンピュータを特徴付け、Webサービス攻撃を受ける可能性がある)。 これらの新しい変数は、新しいルールの中で、入ってくる攻撃をさらに選別するために機能します。 従来のルールでは、ネットワーク上の任意のコンピュータを対象とした疑わしいHTTPリクエストを警告することができましたが、新しいルールでは、HTTP_SERVERS変数が定義するWebサーバーを対象とした場合のみ、同じ攻撃を検索します。 この分類プロセスは、誤報を減らすのに役立ちます。
Snort.org は、新しいエクスプロイトの発見に合わせて、ルール セットを頻繁に更新しています。 最新の状態を維持するには、定期的に新しいルールをチェックし、ダウンロードして、自分の環境に有用なものを適用します。 ただし、新しいルールをダウンロードするたびに、新しいルールを含むテキストファイルは古いルールを含むものを上書きすることに注意してください。 ルール ファイルを更新するたびに、すべての未使用ルールをコメントアウトするのは負担が大きいことがすぐにわかるでしょう。
Oinkmaster to the Rescue
幸い、いくつかのオープン ソース ツールがこの問題の克服に役立ちます。 Oinkmaster という Perl スクリプト プログラムは、http://www.algonet.se/~nitzer/oinkmaster からダウンロードでき、新しいルールのダウンロードを自動化し、無効または修正されたルールを管理します。 UNIXシステム用に調整されたこのPerlスクリプトは、スクリプトが実行されるたびに、wget、tar、およびgzipツールを使用して新しいルールを取得し、展開します。 これらのツールのほとんどは、UNIXシステムにインストールされていますが、Windows用のツールをダウンロードすることもできます。 オープンソースのソリューションは、専用のサポートが限られているため、問題や質問がある場合は、オンラインで解決方法を探してください。 オープンソース・ソフトウェア(OSS)コミュニティには、有用な情報が豊富にあります。 手始めとして、Snortのメーリングリストに参加するのもよいでしょう。メーリングリストはhttp://www.snort.org/lists.html.
.
で登録できます。 基本的な Oinkmaster のインストール手順は、oinkmaster.pl と oinkmaster.conf ファイルを Snort ディレクトリ(または指定したディレクトリ)に展開し、次に oinkmaster.conf を使用して Oinkmaster を設定します。
oinkmaster.conf を開き、インラインコメントに従ってツールを設定します。 まず、更新したルールの場所をWebアドレスで確認します(例:http://www.snort.org/dl/signatures/snortrules.tar.gz)。 特に、ルールを自動的にダウンロードしてインストールすることを選択した場合は、信頼できる評判の良いサイトを Oinkmaster に指定するようにしてください。 さもなければ、IDS を危険にさらす可能性のある破損した (またはさらに悪いことに改ざんされた) ルールをダウンロードする危険があります。
次に、スキップ、変更、および無効化するファイルを指定します。 デフォルトでは、Oinkmaster は local.rules と snort.conf を処理しません (つまり、スキップします)。
スクリプトの modifysid 機能により、新しくダウンロードしたルールを修正できます。modifysid は、SID で識別する特定のルールに対する検索および置換機能だと考えてください。 このコマンドを使用すると、特定のルールのテキストを修正することができます。 たとえば、modifysid を使用して、デフォルトで無効になっているルールを有効にすることができます。 これを行うには、有効にしたいルールを特定する新しいmodifysidコマンドを追加し、コメント文字(#)を削除するように指示します。 新しいルールセットがダウンロードされるたびに、Oinkmasterがそのルールを解析するときに、このコメント文字が削除されます。 また、modifysidを使用して、ルールのアクションタイプを昇格させることができます。 たとえば、コマンド
modifysid 2003 "alert" | "sev1"
は、SIDが2003のアラートを、カスタムアクションタイプのsev1に昇格させます。 Oinkmasterは、”alert “を検索し、”sev1 “に置き換えることでこれを実行します。
Oinkmaster の最後の、そして最も人気のある機能である disablesid は、選択したルールを無効にすることができます。 無効にしたままにしたいすべてのルールの SID を指定します。 たとえば、ネットワークスキャンの警告を無効にするには、
disablesid 469, 615, 618, 620
のようなエントリで始めるかもしれません。新しいルールのセットをダウンロードして解析した後、Oinkmaster は指定した SID を探して、ルールをコメントアウトします。 Oinkmaster がルールを管理する限り、ルールはルールセットの更新があっても無効なままです。
ルールを更新したいときはいつでも手動でスクリプトを実行します。 大胆にも、定期的にスクリプトを実行し、ルールを更新するようにスケジュールを設定することができます。 Oinkmaster はルールを取得し、それらを展開し、センサーのルールディレクトリにコピーします。 ほとんどの OSS と同様に、Oinkmaster は慎重に使用し、まずそれが何を行うのか、そしてそれが自分の環境にどのような影響を与えるのかを学びます。 たとえば、ルールを本番環境に展開する前に、Snort をセルフテスト モードで実行して (snort -T とその他のパラメータを使用して) 新しいルール セットをテストします。
Oinkmaster では、古いルールをバックアップするオプションと、コンソールに動作のログを提供することにより、疑わしい更新をダウンロードするリスクを回避することができます。 Oinkmaster が正常にタスクを完了したことを確認し、Oinkmaster が変更したルールを確認するために、削除されたルール、変更されたアクティブなルール、ルール以外のリビジョン、および新しいファイルを示すこの出力を確認してください。 Oinkmaster が自動的に実行されるようにスケジュールを設定する場合、図 2 が示すように、レビューが容易になるように結果を電子メールで送信することを検討してください。 次の例は、Linuxのcrontabコマンド(crontabはLinuxでジョブをスケジュールすることができます)を使用して、毎日午前6時15分にOinkmasterを実行するようにスケジュールする方法を示しています:
15 6 * * * /home/snort/oinkmaster.pl -o /home/snort/rules -b /home/snort/backup 2>&1 | mail -s "Oinkmaster"
Oinkmasterパラメータは、規則ディレクトリ(-o)、バックアップ規則ディレクトリ(-b)、所有者に結果を電子メールで送信するコマンドを指定しています。 コマンド2>&1は、StdErr出力をメール アプリケーションに送信する前にStdOut(コンソール)に送信します。
Snortルールを見る
純正ルールを無効化または基本的に変更することに加えて、独自のルールを作成して、さらに自分の環境に直接Snortルールを調整することが可能です。 たとえば、ファイアウォールの内側と外側のトラフィックを監視するセンサーの配備を考えてみましょう。 ファイアウォールがどれだけのワーム攻撃を防いだかを知ることも重要ですが、それらの攻撃がネットワーク内部から発生したものであるかどうかを知ることは、より重要な関心事でしょう。 最近、Snortのルールには、上記の例のような「調整済み」ルールが含まれていますが、同様にカスタマイズしたいルールが多く残されています。 リスト1は、SQL Slammer(別名Sapphire)ワームを検出したときに警告を発する標準的なルールを示しています。 早速、このルールを分解してみましょう。 (ルールを定義するすべての利用可能なパラメータの詳細については、http://www.snort.org/docs/writing_rules/chap2.html#tth_sec2.3.26にあるSnortルールのドキュメントを参照してください。)
すべてのルールは1行に存在し、ルール アクションで始まる必要があり、この場合は
alert
ルール アクションは、トリガーされた場合にSnortがルールにどう応答するのかを定義しています。 ルールの種類を変更して(たとえば、’sev1’などの文字列に)、カスタム処理(たとえば、一致した場合にアクションをエスカレートさせる)を提供することができます。 このステップは、Oinkmaster を使用して既存のルールの警告タイプを変更した前の例とは異なります。この例では、既存のルールをテンプレートとして使用して新しいルールを作成しています。
The set of parameters
udp $EXTERNAL_NET any -> $HOME_NET 1434
provided the protocol, IP address, port information, and traffic direction for the rules. このルールは、ネットワーク ソース(変数$EXTERNAL_NETで定義)からポート1434の変数$HOME_NETに移動しようとするUDPパケットを検出するようにSnortに指示します。 ほとんどのデフォルトのルールでは、主に$EXTERNAL_NETと$HOME_NETという変数を使用します。 しかし、一部のルールでは、より具体的な変数を使用します。 たとえば、DNSサーバーに関連するルール(dns.rulesファイル内)では、$DNS_SERVERSという変数を使用します。 これらの変数は、Snort設定ファイル(通常はsnort.conf)で定義します。 オプションとして、トポロジーを反映するため(例:$MAIL_SERVERS)、およびカスタム ルールで使用するために独自の変数を作成することも可能です。 変数名を使用して変数を定義し(例:var MAIL_SERVERS=192.168.0.20/30)、変数の前にドル記号($-例:$MAIL_SERVERS)を付けて参照し ます。
ルールオプションは、疑わしいパケット (および疑わしいパケットのみ) が応答を引き起こすように、ルールをさらに洗練します。 推測されるように、これらのシグネチャは非常に詳細になり、単純なポートマッチングをはるかに超えて拡張することができる。 たとえば、この Slammer ルールが単に UDP ポート 1434 トラフィックを警告した場合、偽陽性が生じることを想像してみてください。
The msg オプション
msg:"MS-SQL Worm propagation attempt"
は、警告および報告活動で使用するための警告の簡単な説明を提供します。 content オプション
content:"|04|"; depth:1; content:"|81 F1 03 01 04 9B 81 F1 01|";content:"sock"; content:"send";
には、ASCII または 16 進値 (16 進値をパイプ文字 | で囲む) で、大文字と小文字を区別するペイロードパターン一致文字列が含まれます。 コンテンツオプションは複数指定可能です。 depthオプションは、各コンテンツオプションの後に続き、指定されたコンテンツをペイロードの何バイト目まで検索するかを指定します。 この例では、パケットは、最初のバイトに16進数値04が含まれているか、ペイロードのどこかに残りのコンテンツが含まれていると、応答をトリガーします。
ダウンロードしたルールには、疑わしい悪用やルール作成の理由に関する詳細情報への参照が含まれていることがよくあります。 一部のレポート システムでは、この情報への直接リンクを提供することにより、参照オプションをサポートしています。
reference:bugtraq,5310; reference:bugtraq,5311;reference:url,vil.nai.com/vil/content/v_99992.htm;
Snort はルールをクラスに割り当て、これらのクラスに高、中、または低の優先度を割り当てます。 現在、tempted-admin、trojan-activity、tempted denial of service、network-scan など、30 以上のクラスが存在します。 この例では、分類は
classtype:misc-attack
Snortは検出された侵入の応答優先度を記録します。 外部ツールやスクリプトを使用して、この優先度をさらに解析し、レポート アプリケーションで対応することができます。
最後のセグメントでは、
sid:2003; rev:2;
sidは固有のSnortルールを表し、revは改訂番号を表します。 これらのプロパティは、ルールを一意に識別します。
ルールの調整
このルールを変更して、内部感染ホストを検出したときにエスカレートした警告を提供する方法を検討しましょう。 元のルールと同じエクスプロイトを扱っているため、ルールのコンテンツ定義は同じままです。 IPアドレスとトラフィック方向のみを変更する必要があります。 次のように、ソースIPアドレスを$HOME_NETに変更します。
udp $HOME_NET any -> $EXTERNAL_NET 1434
Snort.conf では$EXTERNAL_NETを「any」と定義しているため、このルールでも内部ホストを標的とした破損パケットを検出します(元のルールと同じです)。 しかし、内部ソースIPアドレスのみを追跡する専用のルールがあるため、アクション タイプをエスカレーション アラートをトリガーするカスタム アクション タイプに変更できます。
現在のSnortルールには、デフォルト ルールセットにこのアウトバウンドSlammerワーム検出ルールが含まれています。 しかし、新しいワーム、ウイルス、またはその他の悪用が広がり始めたら、特定の侵入を強調する新しいルールを作成することを検討してください。
ルールを作成する
既存のルールや修正または作成できるカスタム ルールに加えて、他のソースから取得したルールを含めるとよいでしょう。 たとえば、新しいワームのニュースがインターネット上で広まると、セキュリティ サイトやニュースグループが、新しいワームを検出する単発のSnortルールをすばやく公開します。 これらの新しいルールをlocal.rulesファイルに貼り付けてからSnortを再起動すると、新しいルールが有効になります。
Snortは、安価でカスタマイズ可能なIDSのフレームワークを提供します。 コミュニティがサポートするルール セットにより、Snort は柔軟で効果的なシステムであり続けています。 ルールを最新の状態に保つことで、警戒を強化し、効果のない警告に起因するノイズを低減することができます。 他のオープンソースプロジェクトと同様に、時間をかけてその仕組みを理解し、コミュニティが開発したアドオンに慣れることで、システムを快適に使用できるようになり、環境における有効性が高まります。