始める前に
- ラボでは、Google Cloud プロジェクトとリソースを一定の時間利用します
- ラボには時間制限があり、一時停止機能はありません。ラボを終了した場合は、最初からやり直す必要があります。
- 画面左上の [ラボを開始] をクリックして開始します
Examine a custom rule in Suricata
/ 1
Trigger a custom rule in Suricata
/ 1
Examine eve.json output
/ 1
Examine a custom rule in Suricata
/ 1
Trigger a custom rule in Suricata
/ 1
Examine eve.json output
/ 1
これまでに、パケット分析について、また侵入検知システム(IDS)のシグネチャとルールの基本的な構文と要素について学びました。さらに、オープンソースの侵入検知システム / 侵入防止システム / ネットワーク分析ツールである Suricata で、事前作成済みのシグネチャとログ出力を調べる方法についても学びました。
このラボのアクティビティでは、ルール作成の一般的なプロセスを含め、Suricata のアラートとログについて詳しく確認します。
Suricata ツールはネットワーク インターフェースをモニターし、インターフェースを通過するパケットにルールを適用します。Suricata は、各パケットでアラートを生成するかどうか、および各パケットをドロップするか、拒否するか、インターフェースの通過を許可するかを決定します。
送信元ネットワークと宛先ネットワークを Suricata 構成で指定する必要があります。カスタムルールを作成して、処理すべきトラフィックを指定できます。
ルールを調べ、Suricata を使用してネットワーク トラフィックでアラートをトリガーする処理を実践します。また、fast.log や eve.json ファイルなどのログ出力を分析します。これは、Suricata が生成するアラートとログを理解するうえで役立ちます。
それでは Suricata を使ってみましょう。
このシナリオでは、セキュリティ アナリストとして勤務先のネットワークのトラフィックをモニターします。Suricata を構成し、それを使用してアラートをトリガーする必要があります。
方法は次のとおりです。まず、Suricata のカスタムルールの詳細を確認します。次に、Suricata を実行してカスタムルールをトリガーし、fast.log ファイル内の出力ログを調べます。最後に、Suricata が標準の eve.json ログファイルに生成する追加の出力を調べます。
このラボのアクティビティで行うテストのために、sample.pcap ファイルと custom.rules ファイルが用意されています。これらはホームフォルダにあります。
このラボのアクティビティで使用するファイルの定義を示します。
sample.pcap ファイルは、ネットワーク トラフィック データのサンプルを含むパケット キャプチャ ファイルです。Suricata のルールをテストするために使用します。これにより、ネットワーク トラフィックをモニターする演習をシミュレートして繰り返すことができます。
custom.rules ファイルには、ラボのアクティビティを開始する際のカスタムルールが含まれています。このファイルにルールを追加し、sample.pcap ファイルのネットワーク トラフィック データに適用します。
fast.log ファイルには、Suricata が生成するアラートが記録されます。ラボの開始時には、fast.log は空です。サンプル ネットワーク トラフィック データでルールまたはルールセットをテストするたびに、いずれかのルールの条件がすべて満たされると、Suricata は新しいアラート行を fast.log ファイルに追加します。fast.log ファイルは、Suricata の実行後に /var/log/suricata ディレクトリで確認できます。fast.log ファイルは非推奨の形式と見なされているため、インシデント対応や脅威探査タスクでは推奨されませんが、簡単なチェックや品質保証関連のタスクには使用できます。
eve.json ファイルは、Suricata が生成するイベントの主要な標準のデフォルトログです。トリガーされたアラートやその他のネットワーク テレメトリーのイベントの詳細な情報が JSON 形式で記録されます。eve.json ファイルは Suricate が実行されると生成されます。このファイルも /var/log/suricata にあります。
新しいルールを作成したら、期待どおりに機能するかどうかを確認するためにテストする必要があります。fast.log ファイルを使用すると、Suricata を実行して sample.pcap ファイルでシグネチャをテストするたびに生成されるアラートの数を簡単に比較できます。
それでは始めましょう。
analyst というユーザー アカウントで Bash シェルにログイン済みの状態で始まります。つまり、[ラボを開始] ボタンをクリックするとすぐにタスクから始めることができます。
資料にアクセスするには、まずラボを開始する必要があります。ラボを開始するには、画面上部にある緑色の [ラボを開始] ボタンをクリックします。
[ラボを開始] ボタンをクリックするとシェルが表示され、以降の手順はここで進めます。次のようなシェルが表示されます。
タスクをすべて終えたら、ラボの終了に関するセクションを参照し、ラボの終了手順をご確認ください。
/home/analyst ディレクトリにはネットワーク トラフィック ルールを定義した custom.rules ファイルがあり、Suricata はこのルールを取得します。
このタスクでは、custom.rules ファイルで定義されている Suricata ルールの構成を調べます。
cat コマンドを使用して、custom.rules ファイル内のルールを表示します。less コマンドを使用して、ファイルの内容を 1 ページずつ表示することもできます。これは出力が長い場合に便利です。
このコマンドは、シェルの出力としてルールを返します。
このルールは、アクション、ヘッダー、ルール オプションという 3 つの要素で構成されています。
各要素をさらに詳しく見てみましょう。
シグネチャの最初の部分は、アクションです。これは、条件がすべて満たされた場合に行うアクションを決定します。
アクションはネットワーク侵入検知システム(NIDS)のルール言語によって異なりますが、一般的なアクションとしては alert、drop、pass、reject があります。
このラボの例では、ファイルにアクションとして alert が 1 つ記載されています。alert キーワードは、選択されたネットワーク トラフィックでのアラートの発行を指示します。IDS はトラフィック パケットを検査し、一致した場合はアラートを発行します。
なお、drop アクションもアラートを生成しますが、トラフィックをドロップします。drop アクションは、Suricata が IPS モードで動作している場合にのみ発生します。
pass アクションは、トラフィックがネットワーク インターフェースを通過することを許可します。pass ルールを使用すると、他のルールをオーバーライドできます。pass ルールを使用して、drop ルールの例外を作成できます。たとえば、次のルールは前の例とほぼ同じですが、特定の IP アドレスを選んでそのアドレスからのトラフィックのみの通過を許可する点が異なります。
reject アクションはトラフィックの通過を許可しません。代わりに TCP リセット パケットが送信され、Suricata は一致するパケットをドロップします。TCP リセット パケットは、メッセージの相互送信を停止するようコンピュータに伝えます。
このラボのアクティビティでは、主に alert ルールを使用します。
シグネチャの次の部分は、ヘッダーです。ヘッダーはシグネチャのネットワーク トラフィックを定義します。これには、プロトコル、送信元と宛先の IP アドレス、送信元と宛先のポート、トラフィック方向などの属性が含まれます。
アクション キーワードの次のフィールドは、プロトコル フィールドです。このラボの例では、プロトコルは http であり、ルールが HTTP トラフィックのみに適用されることを規定します。
プロトコル フィールド http のパラメータは、$HOME_NET any -> $EXTERNAL_NET any です。矢印は、$HOME_NET から発信されて宛先 IP アドレス $EXTERNAL_NET に向かうトラフィックの方向を示しています。
$HOME_NET は、/etc/suricata/suricata.yaml で定義されている Suricata 変数です。組織内のシステムとやり取りされるトラフィックを識別するために、ローカル ネットワークまたはホーム ネットワークのプレースホルダとして、ルール定義内で使用できます。
このラボでは、$HOME_NET は 172.21.224.0/20 サブネットとして定義されています。
any は、$HOME_NET ネットワークで定義されている任意のポートからのトラフィックを Suricata が捕捉することを意味します。
$ 記号は変数の開始を示します。変数は、値を格納するプレースホルダとして使用されます。
以上から、このシグネチャは、ホーム ネットワークから外部ネットワークに向かう任意の http トラフィックを検出したときにアラートをトリガーすることがわかります。
多くのルール オプションを利用できるため、追加のパラメータでシグネチャをカスタマイズできます。ルール オプションを構成すると、ネットワーク トラフィックを絞り込みやすくなり、探しているトラフィックを正確に見つけられます。一般的に、ルール オプションはこの例のように丸かっこで囲み、セミコロンで区切ります。
この例のルール オプションを詳しく見てみましょう。
msg: オプションはアラート テキストを規定します。この例では、アラートは “GET on wire” というテキストを出力します。これはアラートがトリガーされた理由を示します。flow:established,to_server オプションは、クライアントからサーバーに向かうパケットと一致する必要があることを指定します(この例では、サーバーは、最初の SYN パケットに SYN-ACK パケットで応答するデバイスとして定義されています)。content:"GET" オプションは、パケットの http.method 部分で GET という単語を探すよう Suricata に伝えます。sid:12345(シグネチャ ID)オプションは、ルールを識別する一意の数値です。rev:3 オプションはシグネチャのリビジョンを示します。これは、シグネチャのバージョンを識別するために使用されます。この例では、リビジョン バージョンは 3 です。まとめると、ホーム ネットワークから外部ネットワークに向かう HTTP パケットで、HTTP メソッドとしての GET というテキストを Suricata が見つけるたびに、このシグネチャはアラートをトリガーします。
[進行状況を確認] をクリックして、このタスクが正しく完了したことを確認します。
Suricata のカスタムルールの構成について理解したので、次はこのルールをトリガーして Suricata が生成するアラートログを調べる必要があります。
/var/log/suricata フォルダ内のファイルをリストします。なお、Suricata を実行する前は、/var/log/suricata ディレクトリ内にファイルはありません。
custom.rules ファイルと sample.pcap ファイルを使用して、suricata を実行します。このコマンドにより、Suricata アプリケーションが起動し、custom.rules ファイル内のルールを使用して sample.pcap ファイルが処理されます。Suricata が処理したパケットの数を示す出力が返されます。
sudo を使用する必要がありますが、実際の環境では使用しなくてよい場合があります。
コマンドのオプションを詳しく見てみましょう。
-r sample.pcap オプションは、ネットワーク トラフィックを模倣した入力ファイルを指定します。この場合、sample.pcap ファイルです。-S custom.rules オプションは、custom.rules ファイルで定義されているルールを使用するよう Suricata に指示します。-k none オプションは、すべてのチェックサム チェックを無効にするよう Suricata に指示します。おさらいすると、チェックサムとは、パケットが転送中に変更されたかどうかを検出する方法です。ここではサンプル パケット キャプチャ ファイルからのネットワーク トラフィックを使用しているため、Suricata でチェックサムの整合性をチェックする必要はありません。
Suricata は、いずれかのルールの条件がすべて満たされた場合、/var/log/suricata/fast.log ファイルに新しいアラート行を追加します。
/var/log/suricata フォルダ内のファイルをもう一度リストします。Suricata の実行後、/var/log/suricata ディレクトリには 4 つのファイル(fast.log ファイルと eve.json ファイルを含む)があることになります。これらのファイルを詳しく調べましょう。
cat コマンドを使用して、Suricata が生成した fast.log ファイルを表示します。出力では、ログのアラート エントリが返されます。
fast.log ファイルの各行(エントリ)は、Suricata がアラート生成ルールの条件を満たすパケットを処理したときに生成したアラートに対応しています。各アラート行には、アラートをトリガーしたルールを識別するメッセージと、トラフィックの送信元、宛先、方向が記載されています。
[進行状況を確認] をクリックして、このタスクが正しく完了したことを確認します。
このタスクでは、Suricata が eve.json ファイルに生成する追加の出力を調べる必要があります。
前述のように、このファイルは /var/log/suricata/ ディレクトリにあります。
eve.json ファイルは主要な標準の Suricata ログファイルであり、fast.log ファイルよりも多くのデータを含んでいます。このデータは JSON 形式で格納されるため、他のアプリケーションで分析と処理を行う際に非常に役立ちます。
cat コマンドを使用して、eve.json ファイルのエントリを表示します。出力では、ファイルの未加工の内容が返されます。この形式ではわかりづらいデータが多数返されることがわかります。
jq コマンドを使用して、よりわかりやすい形式でエントリを表示します。less コマンドを終了し、コマンドライン プロンプトに戻ります。cat コマンドの出力とは対照的に、今回の出力はかなり読みやすいはずです。
jq ツールは JSON データの処理に非常に役立ちますが、機能の詳しい説明はこのラボでは取り扱いません。
解答: 最初のアラートの重大度プロパティの値は 3 です。
jq コマンドを使用して、eve.json ファイルから特定のイベントデータを抽出します。jq コマンドは、角かっこで囲まれたリストで指定されているフィールドを JSON ペイロードから抽出します。選択されているフィールドは、タイムスタンプ(.timestamp)、フロー ID(.flow_id)、アラートのシグネチャまたは msg(.alert.signature)、プロトコル(.proto)、宛先 IP アドレス(.dest_ip)です。
解答: 宛先 IP アドレスは 142.250.1.102 です。
解答: eve.json ファイルの最初のイベントには、アラート シグネチャとして "GET on WIRE" が記載されています。
jq コマンドを使用して、eve.json ファイルから特定の flow_id に関連するイベントログをすべて表示します。flow_id 値は 16 桁の数であり、ログエントリごとに異なります。X を、前のクエリで返された flow_id 値のいずれかに置き換えてください。flow_id を割り当てます。ネットワーク フローのログはすべて同じ flow_id を共有します。したがって、flow_id フィールドは、同じネットワーク フローに属するネットワーク トラフィックの相互関係を知るために役立ちます。
[進行状況を確認] をクリックして、このタスクが正しく完了したことを確認します。
おつかれさまでした。
このアクティビティでは、Suricata を使用してネットワーク トラフィックのアラートをトリガーする方法を習得しました。
Suricata を使用して以下の作業を行う実践的な経験を積みました。
fast.log と eve.json の出力を調べるセキュリティ アナリストになるうえで重要なスキルを身に付けました。
すべてのタスクが問題なく完了したことを確認してから、以下の手順に沿ってラボを終了してください。
このコンテンツは現在ご利用いただけません
利用可能になりましたら、メールでお知らせいたします
ありがとうございます。
利用可能になりましたら、メールでご連絡いたします
1 回に 1 つのラボ
既存のラボをすべて終了して、このラボを開始することを確認してください
ラボを開始するには、この簡単な手順を完了してください。