Ruben Groenewoud

Auditd を使用した Linux 検出エンジニアリング

この記事では、検出エンジニアリングに Auditd と Auditd Manager を使用する方法について詳しく説明します。

28分で読めますDetection Engineering, Enablement
Auditd を使用した Linux 検出エンジニアリング

はじめに

Unix および Linux システムは舞台裏で動作し、私たちの技術インフラストラクチャの重要な部分を静かに支えています。これらのシステムを標的とする脅威がますます複雑化しているため、セキュリティを確保することがこれまで以上に重要になっています。

Unix および Linux システム内で作業するセキュリティ検出エンジニアの武器となる基本ツールの 1 つがAuditdです。この強力なユーティリティは、システム イベントを監視および記録し、誰がいつ何をしたかの詳細な監査証跡を提供するように設計されています。これはウォッチドッグとして機能し、システムコール、ファイルアクセス、システム変更に関する詳細な情報を巡回して記録します。これはフォレンジック分析やリアルタイム監視に不可欠です。

この記事の目的は多面的です。

  1. 私たちの目的は、Auditd に関する追加情報を提供し、その機能とセキュリティ検出エンジニアリングにおける強力なパワーを紹介することです。
  2. お客様独自のシステムに Auditd を設定し、特定の監視ニーズに合わせてカスタマイズする方法を説明します。Auditd ルールを作成および変更する方法を理解することで、監視対象の正確な動作をキャプチャし、結果のログを解釈して独自の検出ルールを作成する方法を学習します。
  3. システム間での Auditd の管理を簡素化することで Auditd のユーティリティを強化する統合ツールである Auditd Manager を紹介します。

この投稿を読み終える頃には、Auditd Manager を使用して、事前に構築された検出ルールの一部をセキュリティ戦略に組み込む方法を学ぶだけでなく、Auditd の包括的な理解と、それを活用して独自の検出ルールを構築する方法も習得できるようになります。

Auditd の紹介

Auditd は、システム イベントを監視および記録し、ユーザー アクティビティ、システムの変更、セキュリティ アクセスの包括的な監査証跡を提供するように設計された Linux ツールです。Auditd は Linux カーネルにフックして動作し、発生したシステム コールやその他のシステム イベントに関する詳細情報を取得します。これらのイベントはファイルに記録され、タイムスタンプ付きの記録が提供されます。管理者は、どのイベントをログに記録するかを指定するルールを定義できるため、特定の関心領域や懸念事項に焦点を絞る柔軟性が得られます。記録されたデータは、コンプライアンス監査から詳細なフォレンジック分析まで、さまざまな目的に使用できます。

Auditd のセットアップ

Auditd を使い始めるために、Elastic はいくつかのオプションを提供しています。

この記事では、後者の 2 つに焦点を当て、 Elastic Agentを活用してログを Elasticsearch に簡単に取り込む方法について説明します。Elasticsearchを初めて使用する場合は、30日間のトライアルライセンスでElastic Cloudアカウントを簡単に作成できます。または、ローカルテストの場合は、 Elastic Container Projectをダウンロードし、.envでライセンス値をトライアルに設定できます。ファイル。

Auditbeat または Filebeat を使用して自由に実行してください。セットアップ手順については、上記のリンク先のドキュメントを参照してください。Auditd ログ統合は audit.log ファイルを解析することによって機能するため、ログを収集する Linux ホストに Auditd をインストールする必要があります。選択した Linux ディストリビューションとパッケージ マネージャーに応じて、Auditd パッケージをインストールし、Auditd サービスを開始して有効にする必要があります。Debian ベースのディストリビューションの場合:

sudo apt update
sudo apt install auditd
sudo systemctl start auditd
sudo systemctl enable auditd

/var/log/audit/audit.logファイルに Auditd ログが入力されるようになりました。次に、Auditd Logs 統合をインストールし、新しくインストールされた統合を使用して Fleet にエージェント ポリシーを作成し、Auditd がインストールされた互換性のある Elastic Agent に統合を適用する必要があります。

ほとんどのシナリオではデフォルト設定で十分です。次に、エージェント ポリシーに統合を追加し、データを収集する Elastic Agent にエージェント ポリシーを追加する必要があります。Elastic Agentはログをlogs-auditd.log-[namespace]に送信します。データストリーム。受信した Auditd ログのみに一致する新しいデータ ビューを作成できるようになりました。

取り込まれた Auditd ログを調べることができるようになりました。しかし、すぐに気付くように、Auditd はデフォルトではあまりログを記録しません。その潜在能力を最大限に引き出すには、Auditd ルールを活用する必要があります。

Auditd rules

Auditd ルールは、どのシステム アクティビティを監視およびログに記録するかを指定するために使用されるディレクティブであり、セキュリティ監査プロセスを詳細に制御できます。これらのルールは通常、 /etc/audit/audit.rulesファイルで構成されます。Auditd ルールには 3 種類あります: control 、 file 、 syscall 。詳しい情報は、こちらをご覧ください。

コントロールタイプのルール

制御タイプは、ほとんどの場合、監視するイベントを指定するのではなく、Auditd を構成するために使用されます。デフォルトでは、監査ルール ファイルには次の制御タイプの設定が含まれています。

-D
-b 8192
-f 1
--backlog_wait_time 60000
  • -D: 起動時にすべてのルールを削除します (Auditd はファイル内のルールを上から下へ解析します。起動時にすべてのルールを削除すると、クリーンな構成が保証されます。
  • -b 8192: カーネル内の既存の監査バッファの最大量を設定します。
  • -f 1: Auditd の障害モードをログに設定します。
  • --backlog_wait_time 60000: 監査バックログ制限に達した場合に監査レコードを削除する前に監査システムが待機する時間 (ミリ秒単位) を指定します。

ファイルシステムのルール

これらのデフォルトのコントロール タイプ設定に基づいて、ウォッチと呼ばれることもあるファイル システム ルールを作成できます。これらのルールにより、対象のファイルの読み取り、書き込み、変更、実行アクションを監視できます。一般的なファイル システム ルールは次のようになります。

-w [path-to-file] -p [permissions] -k [keyname]
  • -w: 監視するファイルまたはディレクトリへのパス。
  • -p: 読み取り (r)、書き込み (w)、実行 (e)、または変更 (a) 権限のいずれか。
  • -k: 監査ログをより簡単に検索するために使用できるキー識別子の名前。

/etc/shadowファイルの読み取り、書き込み、変更を監視し、そのようなイベントを shadow_access というキーで保存する場合は、次のルールを設定できます。

-w /etc/shadow -p rwa -k shadow_access

システムコールルール

Auditd の真の力は、システム コール ルールを操作するときに発揮されます。Auditd システム コール ルールは、どのシステム コール (syscalls) を監視およびログに記録するかを指定する構成であり、システム アクティビティとオペレーティング システム カーネルとのやり取りを詳細に追跡できます。各システム コールはインターセプトされ、ルールと照合されるため、関心のあるシステム コールのみをキャプチャし、可能であれば 1 つのルールで複数のシステム コールをキャプチャすることによって、この機能を慎重に活用することが重要です。典型的な syscall ルールは次のようになります。

-a [action],[filter] -S [syscall] -F [field=value] -k [keyname]

-aフラグの後にaction,filterを続けると、イベントをいつログに記録するかを選択できます。ここで、 action always (常にイベントを作成する) またはnever (イベントを作成しない) になります。

フィルターは次のいずれかになります。

  • task: タスク作成イベントをログに記録します。
  • entry: システムコールのエントリポイントをログに記録します。
  • exit: システムコールの終了/結果を記録します。
  • user: ユーザー空間のイベントをログに記録します。
  • exclude: イベントをログに記録しません。

次に、次のようになります。

  • -S: 関心のあるシステム コール (名前またはシステム コール番号)。
  • -F: 一致対象を選択するための 1 つ以上のフィルター。
  • -k: キー識別子。

上記の情報があれば、ほとんどの Auditd ルールの基本を理解できるはずです。これらのルールに追加できる値の詳細と例については、ここ をご覧ください。

組織向けの包括的かつ専用の Auditd ルール ファイルの構築とテストを始めるのは、困難に思えるかもしれません。幸いなことに、GitHub には優れた公開ルール ファイルの例がいくつかあります。個人的に気に入っているテンプレートはNeo23x0 のもので、可視性とパフォーマンスのバランスが優れています。

Auditd ログ統合を使用する場合の欠点の 1 つは、監視する各ホストに Auditd を手動でインストールし、実行中の各 Auditd インスタンスにルール ファイルを手動で適用する必要があることです。つまり、ルール ファイルを更新するたびに、すべてのホストで更新する必要があります。今日では、多くの組織がこのプロセスの時間を短縮できる管理ツールを活用しています。ただし、Elastic は Auditd Manager 統合を通じて Auditd ログを取り込む別の方法も提供しており、管理の負担が軽減されます。

Auditd Manager とセットアップの概要

Auditd Manager 統合は、Linux カーネルの一部であるLinux 監査フレームワークから監査イベントを受信します。この統合により、カーネルへのサブスクリプションが確立され、発生したイベントを受信できるようになります。Linux 監査フレームワークは、単一の監査可能なイベントに対して複数のメッセージを送信できます。たとえば、 rename()システムコールにより、カーネルは 8 つの個別のメッセージを送信します。各メッセージは、発生しているアクティビティのさまざまな側面 (システム コール自体、ファイル パス、現在の作業ディレクトリ、プロセス タイトル) を説明します。この統合により、各メッセージのすべてのデータが 1 つのイベントに結合されます。Auditd Manager に関する詳細については、こちらをご覧ください。

さらに、Auditd Manager は、 Fleetを通じて集中管理を可能にするため、管理の負担を解消します。統合の更新は、変更されたエージェント ポリシーの一部であるすべての Elastic エージェントに自動的に適用されます。

Auditd Manager の統合の設定は簡単です。サービスを停止して無効にすることで、Auditd がホスト上で実行されていないことを確認する必要があります。

sudo systemctl stop auditd
sudo systemctl disable auditd

エージェント ポリシーから Auditd Logs 統合を削除し、代わりに Auditd Manager 統合をインストール/追加できるようになりました。

統合を構成するために使用できるオプションがいくつかあります。Auditd Manager には、監査設定を不変に設定するオプション (Auditd 設定で-e 2コントロール タイプ ルールを設定するのと同様) が用意されており、権限のないユーザーが監査システムを変更できないという追加のセキュリティが提供され、悪意のあるアクティビティを隠すことがより困難になります。

ID 解決機能を利用して、UID と GID を関連付けられた名前に解決できるようになります。

Auditd ルール管理では、監査ルール セクションでルールを指定するか、ルール ファイルを活用して、このファイルを読み取るファイル パスを指定することができます。ルールの形式は、Auditd Logs 統合のルールの形式に似ています。ただし、ルール ファイルに制御フラグを指定する代わりに、統合設定でこれらのオプションを設定することもできます。

Auditd Manager は、構成で提供される新しいルールを追加する前に、既存のすべてのルールを自動的に消去するため、ルール ファイルで-Dフラグを指定する必要がありません。さらに、設定で障害モードをsilentに設定できるため、 -fフラグを指定する必要もありません。

バックログ制限も設定できます。これは、 -bフラグを設定するのと同様です。

--backlog_wait_time設定と同等の、バックプレッシャー戦略を設定するオプションもあります。

最後に、元のイベントを保存するオプションをチェックします。これにより、将来イベントをより簡単に分析できるようになります。

これで統合を保存し、Auditd ログを受信するホストのエージェント ポリシーに適用できます。

Auditdルールファイルのトラブルシューティング

Neo23x0 によって提供されるルール ファイルは、デフォルトでは Auditd Manager では機能しません。これを動作させるには、コントロール タイプ フラグの削除、デフォルトのシステムに存在しないユーザーの UID からユーザーへの変換、冗長なルール エントリなどの、いくつかの小さな調整を行う必要があります。最終的に行う必要がある変更は、環境に固有のものになります。

互換性のないファイルを Auditd Manager 統合にコピー アンド ペーストするときに生成されるエラーを識別する方法は 2 つあります。ポリシーを受信したエージェントに移動し、統合入力エラーを確認できます。エラーを一つずつ分析し、競合する行を変更または削除することができます。

また、 [検出]タブを使用して、Auditd Manger データ ビューを選択し、 auditd.warningsフィールドが存在するイベントをフィルターして、警告を 1 つずつ確認することもできます。

たとえば、エラーには「不明なルール タイプ」と表示されていますが、これは Auditd が制御ルールをサポートしていないことに関連しています。「ユーザー 'x' を数値 ID に変換できませんでした」は、ユーザーがシステムに存在しないことに関連しています。そして最後に、「ルール 'x' は 'x' の重複です」は重複ルールに関連しています。競合するエントリが削除され、エージェントのステータスが正常になったので、Auditd データの分析を開始できます。

Auditd Manager イベントの分析

これまでと同様に、Elasticsearch クラスターで Auditd Manager データが利用できるようになったので、 logs-auditd_manager.auditd*インデックスのデータビューを作成して、このデータを具体的にフィルター処理できます。実装されたルール ファイルには次のエントリが含まれています。

-w /etc/sudoers -p rw -k priv_esc

これにより、 /etc/sudoersファイルの読み取りおよび書き込みアクションがキャプチャされ、これらのイベントがpriv_escキーを使用してログに書き込まれます。cat /etc/sudoersコマンドを実行し、イベントを分析してみましょう。まず、一般的な情報が含まれるフィールドをいくつか見てみましょう。

/etc/sudoersファイルがopenat()システムコールを介して/usr/bin/catバイナリによってアクセスされたことがわかります。ファイルの所有者とグループはrootであり、このファイルへのアクセスを要求しているユーザーは UID 0 (root) ではないため、 openat()システムコールは失敗し、ログに記録されています。最後に、この特定のアクティビティにリンクされたタグが表示されます。

もう少し深く掘り下げると、イベントに関する追加情報を特定できます。

実行されたプロセス コマンド ラインと、アクティビティを開始したプロセス ID およびプロセス親 ID を確認できます。さらに、イベントが発生したアーキテクチャと、どのtty (標準入力に接続された端末) を介してコマンドが実行されたかを確認できます。

a0-3 の値を理解するには、Unix システムコールをさらに深く調べる必要があります。この時点で syscall が何であるかを認識しているはずですが、完全に理解するには、Unix syscall (システム コール) は、プログラムがファイル操作、プロセス制御、ネットワーク通信などのオペレーティング システムのカーネルからサービスを要求できるようにする基本的なインターフェイスです。

openat()システムコールを見てみましょう。open(2)マニュアル ページ (ソース) を参照すると、次の情報が表示されます。

openat() これは、 open()システムコールの進化版であり、ディレクトリファイル記述子 ( dirfd ) を基準としたファイルアクセスを可能にします。このシステムコールにより、プログラムはファイルまたはディレクトリを開くことができます。これは、多くのシステムタスクにとって重要な操作です。syscall は標準 C ライブラリの一部であり、 #include <fcntl.h> include ステートメントを通じてfcntl.hヘッダーで使用できることがわかります。

マニュアルを参照すると、 openat()システムコールの構文は次のようになります。

int openat(int dirfd, const char *pathname, int flags, /* mode_t mode */);
  • dirfd ディレクトリファイル記述子を指定します。
  • *pathname 開くファイル/ディレクトリの名前へのポインタです。
  • flags 操作モード（読み取り、書き込み、作成など）を決定します。

元のイベントに戻ると、 auditd.data.a0-a3フィールドを理解する準備が整いました。auditd ログ内のa0 ～ a3値は、syscall に渡される引数を表します。これらの引数は、システムコールの実行のコンテキストと詳細を理解するために重要です。これらの値がopenat()とどのように関連しているか、また、これまでの調査に基づいて、試行された操作について何がわかるかを分析してみましょう。

  • auditd.data.a0 ( dirfd ): a0 値ffffff9cは、操作が現在の作業ディレクトリを基準としていることを示す特別なディレクティブAT_FDCWDを示します。
  • auditd.data.a1 ( pathname ): a1値7ffd0f81871dは、ターゲット ファイルまたはディレクトリのパス名文字列を指す 16 進数のメモリ アドレスを表します。この場合は、 /etc/sudoersファイルにアクセスしようとする試みを指します。
  • auditd.data.a2 ( flags ): 0のa2値に反映され、 flags 引数はファイルにアクセスするモードを指定します。0は特別なフラグが使用されていないことを示し、デフォルトの操作（おそらく読み取り専用アクセス）を意味します。
  • auditd.data.a3 ( mode ): a3値 (0) は、ファイルが作成されるコンテキストで関連し、新しいファイルに設定される権限を決定します。

上記の分析に基づいて、Auditd Manager イベントの解釈方法を十分に理解できるようになります。

Auditd Manager イベントの意味をすぐに把握する別の方法は、Elastic の組み込みAI アシスタントを使用することです。whoamiコマンドを実行し、イベント内のauditd.messagesフィールドを見てみましょう。

Elastic AI Assistant に面倒な処理を依頼してイベントを分析すれば、その後は syscall マニュアルを参照してそれが正しいことを確認するだけで済みます。まず、Auditd ログの分析に重点を置いた、次のような新しいシステム プロンプトを作成しましょう。

新しく作成されたシステム プロンプトを活用し、追加のフォーマットなしで Auditd メッセージをそこに貼り付けると、次の応答が返されます。

生成 AI ツールは、イベントの簡単な説明を受け取るのに非常に役立ちます。しかし、生成 AI は間違いを犯す可能性があるため、このタイプの分析に AI ツールを活用することを常に意識し、生成される出力を再確認する必要があります。特に、これらのツールの出力を検出ルールの開発に活用する場合は、小さなミスが 1 つあるだけでロジックの誤りにつながる可能性があります。

Auditd Manager 検出ルールの例

前のセクションを読んだ後は、Auditd Manager ログの分析を開始するのに十分な知識が得られるはずです。現在の Elastic 検出ルールのルール セットは主にElastic Defend 統合を活用していますが、Auditd を活用するルールの数は大幅に増加しています。このセクションでは、Auditd を活用するいくつかの検出ルールについて詳しく説明し、その理由を説明し、検出ルールのクエリを作成するためのあまり使用されていないテクニックをいくつか紹介します。

UDP経由の潜在的なリバースシェル

UDP 経由の潜在的なリバース シェル ルールは、UDP ベースのリバース シェルを識別することを目的としています。Elastic Defend は現在 UDP トラフィックをキャプチャしないため、Auditd を活用してこの可視性のギャップを埋めることができます。このルールは次のロジックを活用します。

sample by host.id, process.pid, process.parent.pid
  [process where host.os.type == "linux" and event.type == "start" and event.action == "executed" and process.name : (
    "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "perl", "python*", "nc", "ncat", "netcat", "php*",
    "ruby", "openssl", "awk", "telnet", "lua*", "socat"
    )]
  [process where host.os.type == "linux" and auditd.data.syscall == "socket" and process.name : (
    "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "perl", "python*", "nc", "ncat", "netcat", "php*",
    "ruby", "openssl", "awk", "telnet", "lua*", "socat"
    ) and auditd.data.a1 == "2"]
  [network where host.os.type == "linux" and event.type == "start" and event.action == "connected-to" and
   process.name : (
    "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "perl", "python*", "nc", "ncat", "netcat", "php*",
    "ruby", "openssl", "awk", "telnet", "lua*", "socat"
    ) and network.direction == "egress" and destination.ip != null and
   not cidrmatch(destination.ip, "127.0.0.0/8", "169.254.0.0/16", "224.0.0.0/4", "::1")]

このルールは、時系列順に並べられていない一連のイベントを記述して照合するサンプル機能を活用します。これにより、同じミリ秒内にイベントが発生した場合にもシーケンスがトリガーされるようになります。さらに、ホワイトリスト方式を活用して、リバース接続を生成する可能性のある疑わしいバイナリを指定し、誤検知率を最小限に抑えることができます。

socket()システムコールに関連する Auditd データを活用して、UDP 接続を確実にキャプチャします。

a0 値はドメインを表し、 a1はタイプを表し、 a2使用されるプロトコルを表していることがわかります。私たちのルールは、UDP であるSOCK_DGRAMタイプに変換されるauditd.data.a1 == "2"構文を活用します。

最後に、ホストからの出力ネットワーク接続のみをキャプチャし、IPv4 および IPv6 ループバック アドレス、IPv4 リンク ローカル アドレスおよびマルチキャスト アドレスを除外し、イベントが同じ (親) プロセスから発生したことを確認するために、クエリをprocess.pidおよびprocess.parent.pidで順序付けます。

UDP ソケットを開いている疑わしいプロセスを探す場合は、 auditd.data.a1 == "2"を使用してすべての socket() システムコールを照会し、個別のプロセス発生数をカウントし、昇順で並べ替えて異常を見つけることができます。そのためには、次の ES|QL クエリを活用できます。

FROM logs-*, auditbeat-*
| EVAL protocol = CASE(
    auditd.data.a1 == "1", "TCP",
    auditd.data.a1 == "2", "UDP"
)
| WHERE host.os.type == "linux" and auditd.data.syscall == "socket" and protocol == "UDP"
| STATS process_count = COUNT(process.name), host_count = COUNT(host.name) by process.name, protocol
| SORT process_count asc
| LIMIT 100

結果を見ると、興味深いプロセスがいくつか浮かび上がってきており、脅威ハンティングの目的の良い出発点となるかもしれません。

潜在的なMeterpreterリバースシェル

Auditd を活用したもう 1 つの興味深いタイプのリバース接続は、 Metasploit フレームワーク 内で使用される一般的なリバース シェルである Meterpreter シェル の検出です。潜在的な Meterpreter リバース シェルルールは、Meterpreter のデフォルトのホスト列挙動作を利用して、その存在を検出します。

sample by host.id, process.pid, user.id
  [file where host.os.type == "linux" and auditd.data.syscall == "open" and auditd.data.a2 == "1b6" and file.path == "/etc/machine-id"]
  [file where host.os.type == "linux" and auditd.data.syscall == "open" and auditd.data.a2 == "1b6" and file.path == "/etc/passwd"]
  [file where host.os.type == "linux" and auditd.data.syscall == "open" and auditd.data.a2 == "1b6" and file.path == "/proc/net/route"]
  [file where host.os.type == "linux" and auditd.data.syscall == "open" and auditd.data.a2 == "1b6" and file.path == "/proc/net/ipv6_route"]
  [file where host.os.type == "linux" and auditd.data.syscall == "open" and auditd.data.a2 == "1b6" and file.path == "/proc/net/if_inet6"]

Meterpreter が起動すると、特定のシステム ファイルを読み取って、マシン、ユーザー、IP ルーティング情報などのデフォルトのシステム情報を収集します。パスがバイナリにハードコードされているため、Meterpreter ペイロードを逆コンパイルするとこの動作を確認できます。

私たちの検出ロジックは、Meterpreter の動作と一致しているため、 auditd.data.a2 == “1b6”を活用します。Meterpreter がファイル ハンドラーを開く方法を見ると、Meterpreter がこの特定のシステム コールの組み合わせを利用してファイルを読み取っていることがわかります。

参考までに、Meterpreter が読み取るその他のパスが以下のスクリーンショットに示されています。

ES|QLを活用して Meterpreter リバース シェルのセットを分析し、それらすべてがアクセスしているファイル パスを簡単に見つけることができます。

FROM logs-*, auditbeat-*
| WHERE host.os.type == "linux" and event.action == "opened-file" and process.name in ("shell-x64.elf", "JBNhk", "reverse.elf", "shell.elf", "elf") and auditd.data.a2 == "1b6"
| STATS file_access = COUNT_DISTINCT(process.name) by file.path
| SORT file_access desc
| LIMIT 100

この例では、 5 Meterpreter シェルのみを分析していますが、ES|QL を使用すると、この分析をより大きな数値に簡単に拡張できます。上記の情報に基づいて、検出ルールに選択されたパスが 5 つのサンプルすべてに存在することがわかります。

上記のロジックを組み合わせると、Linux Meterpreter ペイロードを発見できる可能性があります。

Linux FTP/RDP ブルートフォース攻撃が検出されました

Linux で使用できる FTP/RDP クライアントは非常に多く、認証ログが完全に同じように実装されているわけではないため、Auditd のauditd.data.terminalフィールドを活用して、さまざまな FTP/RDP 実装を検出できます。FTP 検出ロジックは次のようになります。

sequence by host.id, auditd.data.addr, related.user with maxspan=3s
  [authentication where host.os.type == "linux" and event.action == "authenticated" and 
   auditd.data.terminal == "ftp" and event.outcome == "failure" and auditd.data.addr != null and 
   auditd.data.addr != "0.0.0.0" and auditd.data.addr != "::"] with runs=5

  [authentication where host.os.type == "linux" and event.action  == "authenticated" and 
   auditd.data.terminal == "ftp" and event.outcome == "success" and auditd.data.addr != null and 
   auditd.data.addr != "0.0.0.0" and auditd.data.addr != "::"] | tail 1

ここでは、同じホスト、同じ IP、同じユーザーからのログイン試行の失敗 5 回とログイン試行の成功 1 を順序付けます。Unix の tail と同様に動作するtail機能を活用し、時間枠内のすべてのアラートを選択するのではなく、最後の X 個のアラートを選択します。これは SIEM 検出ルール インターフェースには影響しません。ブルート フォース攻撃によってすぐに多数のアラートが発生する可能性があるため、読みやすくするためにのみ使用されます。

vsftpdなどのさまざまな FTP ツールを活用していますが、 auditd.data.terminalエントリはツール間で類似しているため、より広範囲の FTP ブルート フォース攻撃を捕捉できます。当社の RDP 検出ルールは同様のロジックを活用しています。

sequence by host.id, related.user with maxspan=5s
  [authentication where host.os.type == "linux" and event.action == "authenticated" and
   auditd.data.terminal : "*rdp*" and event.outcome == "failure"] with runs=10
  [authentication where host.os.type == "linux" and event.action  == "authenticated" and
   auditd.data.terminal : "*rdp*" and event.outcome == "success"] | tail 1

異なる RDP クライアントのauditd.data.terminalフィールドが一致していない場合は、ワイルドカードを利用して認証イベントをキャプチャできます。

RWXメモリ領域を持つバイナリからのネットワーク接続

mprotect()システム コールは、すでに割り当てられているメモリ領域のアクセス保護を変更するために使用されます。このシステムコールにより、プロセスは仮想アドレス空間内のページの権限を変更し、それらのページに対する読み取り、書き込み、実行などの権限を有効または無効にすることができます。この検出ルールの目的は、メモリ領域の読み取り、書き込み、実行の権限が設定されたバイナリからのネットワーク接続を検出することです。システムコールを見てみましょう。

検出ルールのロジックでは、 prot値が最も重要です。protは次のアクセス フラグがあることがわかります。

前述のとおり、 protリスト内の値のビット単位の OR です。したがって、読み取り、書き込み、実行の権限については、次の int を探します。

int prot = PROT_READ | PROT_WRITE | PROT_EXEC;

これはビット演算後の値0x7に変換されるため、 auditd.data.a2 == “7”になります。このロジックを活用する 2 つの検出ルール ( RWX メモリ領域を持つバイナリの不明な実行と RWXメモリ領域を持つバイナリからのネットワーク接続)を作成しました。機能するために特定の Auditd 構成を活用する検出ルールについては、セットアップ ガイドに追加するルールに関する注意事項が記載されています。

事前学習では、 new_termsルール タイプを活用し、指定された時間枠内でこれまで不明だった用語を検出できるようにします。これにより、特定のホストで初めて確認される RWX 権限を持つバイナリを検出できると同時に、権限が過剰だが定期的に使用されるバイナリの誤検出を減らすことができます。

後者は次の検出ロジックを活用します。

sample by host.id, process.pid, process.name
[process where host.os.type == "linux" and auditd.data.syscall == "mprotect" and auditd.data.a2 == "7"]
[network where host.os.type == "linux" and event.type == "start" and event.action == "connection_attempted" and
   not cidrmatch(destination.ip, "127.0.0.0/8", "169.254.0.0/16", "224.0.0.0/4", "::1")
]

これらの RWX 権限で実行されているプロセスをサンプリングし、その後、ネットワーク接続 (ループバック、マルチキャスト、およびリンク ローカル アドレスを除く) が開始されます。

興味深いことに、Metasploit は、生成されたペイロードの特定の領域にこれらの RWX 権限を割り当てることがよくあります。たとえば、テスト スタックでこの検出ロジックをトリガーするイベントの 1 つは、Metasploit の Linux 用 Postgres ペイロードの実行に関連しています。このペイロードのソースコードを分析すると、payload_so 関数がPROT_READ 、 PROT_WRITE 、およびPROT_EXECフラグを定義していることがわかります。

その後、特定のページ サイズ0x1000を持つ特定のメモリ領域に、前述の場合と同様の方法で RWX アクセス フラグが与えられます。

ペイロードを実行し、スタックをクエリすると、Metasploit Meterpreter ペイロードに関連するヒットがいくつか返されます。

先ほど分析していた Postgres ペイロードに焦点を当てると、ビジュアル イベント アナライザーを通じて正確なペイロード実行パスを確認できます。Elastic Security では、Elastic Endpoint によって検出されたあらゆるイベントをプロセスベースのビジュアル アナライザーを使用して分析できます。このアナライザーでは、アラートに至るまでのプロセスと直後に発生したイベントのタイムラインがグラフィカルに表示されます。ビジュアル イベント アナライザーでイベントを調べることは、潜在的に悪意のあるアクティビティの発生源や、環境内で侵害される可能性のあるその他の領域を特定するのに役立ちます。また、セキュリティ アナリストは、関連するすべてのホスト、プロセス、およびその他のイベントをドリルダウンして調査に役立てることもできます。

アナライザーでは、perl を利用して /tmp ディレクトリに jBNhk ペイロード (RWX 権限付き) を作成して取り込み、リバース Meterpreter シェルを生成していることがわかります。

まとめ

この記事では、Auditd の世界を詳しく紹介し、Auditd とは何か、その目的について説明します。Auditd を起動して実行する方法、それらのログを Elasticsearch に送って Unix/Linux の可視性を高め、Linux 検出エンジニアリング スキルを向上させる方法を説明しました。特定のアクティビティを監視するための Auditd ルールを作成する方法と、それが生成するイベントを理解する方法について説明しました。作業を楽にするために、Elastic が作成した統合機能である Auditd Manager を導入しました。これにより、管理の負担が軽減されます。最後に、さまざまな検出ルールと、それらを作成するために行われた調査の一部を検討して、このデータ ソースを最大限に活用できるようにしました。

このガイドがお役に立てば幸いです。Auditd を Unix システムに組み込むことは、セキュリティの可視性を向上させるための賢明な方法です。あらかじめ構築された検出ルールを使用するか、独自のルールを作成するかに関わらず、Auditd は Unix セキュリティを強化できます。

この記事を共有する

○FacebookLinkedInRedditの