LinuxでのMicrosoft Defender for Endpointに eBPF ベースのセンサーを使用する

LinuxのMicrosoft Defender for Endpoint用の拡張されたバークレイ パケット フィルター (eBPF) は、Linux オペレーティング システムの補足イベント データを提供します。 eBPF は、AuditD イベント プロバイダーで見られるいくつかの種類の問題に対処するのに役立ち、パフォーマンスとシステムの安定性の分野で有益です。

主な利点を以下に示します。

• システム全体の AuditD 関連のログ ノイズの削減
• 最適化されたシステム全体のイベント ルールが、それ以外の場合はアプリケーション間の競合を引き起こします
• ファイル イベント (ファイルの読み取り/開く) 監視のオーバーヘッドが削減されました
• イベント レートのスループットの向上とメモリ占有領域の削減
• 特定の構成のパフォーマンスの最適化

eBPF のしくみ

eBPF では、AuditD イベント プロバイダーから以前に取得したイベントが eBPF センサーからフローするようになりました。 これにより、システムの安定性が向上し、CPU とメモリの使用率が向上し、ディスク使用量が削減されます。 eBPF は、カスタム規則が不要なアプリケーション間の競合の可能性を減らすのに役立ちます。 eBPF に関連するデータは、/var/log/microsoft/mdatp/microsoft_defender_core.log ファイルにログインします。

さらに、eBPF センサーは、システムの安定性を高めるのに役立つカーネル モジュールを使用することなく、Linux カーネルの機能を使用します。

システムの前提条件

eBPF センサーには、バージョン 101.23082.0006 以降の Linux 用 Defender for Endpoint エージェントが必要です。 続行する前に、エンドポイントがサポートされているエージェントのバージョンに更新されていることを確認します。

eBPF センサーは、次の最小ディストリビューションおよびカーネル バージョンでサポートされています。

eBPF センサーを有効にして構成する

eBPF センサーは、 101.23082.0006 以降のエージェント バージョンに対して、既定ですべての顧客に対して自動的に有効になります。 この機能を利用するには、サポートされているバージョンに更新する必要があります。 エンドポイントで eBPF センサーが有効になっている場合、Linux 上の Defender for Endpoint は supplementary_events_subsystem を ebpf に更新します。

eBPF 補助イベント・プロバイダーを有効または無効にするには、次のコマンドを実行します。

sudo mdatp config ebpf-supplementary-event-provider --value [enabled/disabled]

または、 ebpfSupplementaryEventProvider を mdatp_managed.json ファイル内の disabled に設定して、eBPF 補助イベント・プロバイダーを使用不可にすることもできます。

{
    "features": {
        "ebpfSupplementaryEventProvider": "disabled"
    }
}

JSON ファイルの詳細なサンプルについては、Linux でのMicrosoft Defender for Endpointの設定に関するページを参照してください。

また、Microsoft Defender ポータルで高度なハンティングを使用して、linux エンドポイントで eBPF の状態 (有効または無効) をチェックすることもできます。 手順は次のとおりです。

1. Microsoft Defender ポータルに移動し、サインインします。

2. ナビゲーション ウィンドウで、[ ハンティング>Advanced ハンティング] に移動します。

3. 高度なハンティング で、Defender 脆弱性管理 に移動します。

4. 次のクエリを実行します: DeviceTvmInfoGathering。

5. 出力の [ その他のフィールド ] 列で [ 詳細を表示] を選択し、 EBPF STATUS: true を探します。

AuditD の不変モード

不変モードで AuditD を使用しているお客様の場合、Microsoft Defender for Endpointによって追加された監査規則をクリアするには、eBPF の有効化後に再起動が必要です。 この要件は、AuditD の不変モードの制限であり、ルール ファイルが固定され、編集/上書きが禁止されます。 再起動すると、auditd が不変モードのため削除できない Microsoft Defender for Endpoint の監査ルールがクリアされます。

再起動後、現在の AuditD 規則を一覧表示して、エンドポイント監査規則のDefenderが正常にクリアされたことを確認します。

% sudo auditctl -l

前のコマンドの出力には、ルールまたはユーザーが追加したルールは表示されません。 ルールが削除されなかった場合は、次の手順を実行して監査ルール ファイルをクリアします。

1. ebpf モードに切り替えます。

2. ファイル /etc/audit/rules.d/mdatp.rulesを削除します。

3. マシンを再起動します。

トラブルシューティングと診断

mdatp正常性コマンドを実行して、エージェントの正常性状態をチェックできます。 カーネルのバージョンが システムの前提条件に記載されている eBPF センサーの要件を満たしていることを確認するには、次のコマンドを実行して、現在のカーネル のバージョンを確認します。

uname -a

既知の問題

Linux で eBPF センサーを使用する場合は、次の既知の問題に注意してください。

1. 警告: SAP を使用する RHEL 8.1 では、eBPF を有効にするとカーネル パニックが発生する可能性があります。 この構成で eBPF を有効にする前に、次のいずれかの軽減手順を実行します。

   • RHEL 8.1 より高いディストリビューション バージョンを使用します。
   • RHEL 8.1 バージョンを使用する必要がある場合は、AuditD モードに切り替えます。

2. カーネル バージョン 5.15.0-0.30.20.el8uek.x86_64 で Oracle Linux 8.8 を使用すると、5.15.0-0.30.20.1.el8uek.x86_64カーネル パニックが発生する可能性があります。 この問題を軽減するには、次のいずれかの手順を実行します。

   • eBPF を補助サブシステム プロバイダーとして使用する場合は、Oracle Linux 8.8 で 5.15.0-0.30.20.el8uek.x86_64、5.15.0-0.30.20.1.el8uek.x86_64 より高いまたはそれより低いカーネル バージョンを使用します。 Oracle Linux の最小カーネル バージョンは RHCK 3.10.0 で、Oracle Linux UEK は 5.4 です。

   • 同じカーネル バージョンを使用する必要がある場合は、AuditD モードに切り替えます

     sudo mdatp config  ebpf-supplementary-event-provider  --value disabled
     

   • 次の 2 つのデータ セットは、潜在的な問題を分析し、最も効果的な解決オプションを決定するのに役立ちます。

     1. 次の手順を使用して、クライアント アナライザー ツールから診断パッケージを収集します。LinuxでのMicrosoft Defender for Endpointのパフォーマンスの問題のトラブルシューティングを行います。

     2. Defender for Endpoint が高いリソースを利用している場合は、次の手順を使用してデバッグ診断パッケージを収集します:Linux リソースに対するMicrosoft Defender for Endpoint。

3. ksplice がライブ カーネルのパッチ適用に使用されている場合、Linuxの Defender を実行している Oracle Linux 7.9 でシステムがハングします。

   • ksplice のパッチを自動インストールすると、エンドポイントに cron ジョブが追加されます。
   • ハングの問題を軽減するために、最初に mdatp サービスを停止し、ksplice ベースのパッチ適用を適用してからサービスを開始する cron ジョブを作成できます。
   • カーネルパッチは数秒のアクティビティであるため、セキュリティの面では大きな露出はありません。

パフォーマンスの問題のトラブルシューティング

エンドポイントでMicrosoft Defenderによってリソース消費量が増加する場合は、CPU/メモリ使用率の大部分を引き起こしているプロセス/マウント ポイント/ファイルを特定することが重要です。 その後、必要な除外を適用できます。 可能なウイルス対策の除外を適用した後、 wdavdaemon (親プロセス) がまだリソースを使用している場合は、ebpf-statistics コマンドを使用して上位のシステム呼び出し数を取得します。

sudo mdatp diagnostic  ebpf-statistics

次の出力例は、上位のファイル パス、イニシエーター プロセス、システム呼び出し ID など、20 秒間の監視間隔で収集された eBPF 統計を示しています。

Monitor 20 seconds
Top file paths:
/var/log/microsoft/mdatp/microsoft_defender.log : 10
/var/log/microsoft/mdatp/rotated/microsoft_defender.log00001 : 2
/var/log/microsoft/mdatp/rotated/microsoft_defender.log : 1
/home/gargank/tmp-stress-ng-rename-13550-31/stress-ng-rename-13550-31-374993 : 1
/home/gargank/tmp-stress-ng-rename-13550-31/stress-ng-rename-13550-31-374991 : 1
/home/gargank/tmp-stress-ng-rename-13550-31/stress-ng-rename-13550-31-374989 : 1
/home/gargank/tmp-stress-ng-rename-13550-31/stress-ng-rename-13550-31-374987 : 1
/home/gargank/tmp-stress-ng-rename-13550-31/stress-ng-rename-13550-31-374985 : 1
/home/gargank/tmp-stress-ng-rename-13550-31/stress-ng-rename-13550-31-374983 : 1
/home/gargank/tmp-stress-ng-rename-13550-31/stress-ng-rename-13550-31-374981 : 1

Top initiator paths:
/usr/bin/stress-ng : 50000
/opt/microsoft/mdatp/sbin/wdavdaemon : 13

Top syscall ids:
82 : 1699333
90 : 10
87 : 3

mdatp diagnostic ebpf-statistics出力では、stress-ng は多数のイベントを生成する最上位プロセスであり、パフォーマンスの問題が発生する可能性があります。 ほとんどの場合、stress-ng は ID 82 でシステム呼び出しを生成しています。 Microsoft でチケットを作成して、このプロセスを除外できます。

AuditD に適用された除外を eBPF に移行またはコピーすることはできません。 ノイズの多いログ、カーネル パニック、ノイズの多い syscall などの一般的な懸念事項は、eBPF によって内部的に既に処理されています。 さらに除外を追加する場合は、Microsoft に連絡して、必要な除外を適用します。

FAQ - eBPF への移行

1. eBPF への移行を検討する必要があるのはなぜですか?

LinuxのMicrosoft Defender for Endpoint用に拡張されたバークレイ パケット フィルター (eBPF) は、AuditD の効率的な代替手段として機能し、AuditD イベント プロバイダーに関連するさまざまな課題に対処すると同時に、パフォーマンスとシステムの安定性の面で大きな利点を提供します。 主な利点の一部は次のとおりです。

• パフォーマンス: eBPF は、AuditD と比較してシステム リソースのオーバーヘッドを削減することで、パフォーマンスを大幅に向上させます。

• リソース効率: eBPF では使用するリソースが少ないため、負荷の高い条件下でもシステムの安定性を維持できます。

• スケーラビリティ: eBPF のアーキテクチャはスケーラビリティが高く、ワークロードが増加または複雑な環境に適しています。

• 最新のテクノロジ: eBPF は、将来のLinuxカーネル開発に合わせて最新の将来を見据えたテクノロジを表し、長期的なサポートを向上させます。

2. AuditD を引き続き使用する方法

AuditD を引き続き使用する場合:

• サポートされているバージョン: Linux バージョン 101.24072.0000 では Defender for Endpoint に残ることができます。これは、ビルドの有効期間中に AuditD をサポートします。これは約 9 か月です。 これにより、eBPF への移行を計画するのに十分な移行期間が提供されます。 有効期限は、Linux サーバーでコマンド mdatp healthを実行することで確認できます。

• Long-Term 計画: 101.24072.0000 ビルドを維持することがオプションですが、最新のセキュリティとパフォーマンスの向上の恩恵を受け、継続的なサポートを受けるために、この期間内に eBPF への移行を計画することをお勧めします。

つまり、eBPF をプライマリ イベント プロバイダーとして使用する移行を計画することをお勧めします。

3. 一部のシナリオで eBPF がサポートされていない場合はどうなりますか?

eBPF がサポートされていない場合:

• Netlink フォールバック: システムは Netlink イベント プロバイダーの使用にフォールバックします。 Netlink は引き続きプロセス イベント ( exec、 exit、 fork、 gid、または tid) をキャプチャしますが、ファイル システム関連のイベント ( rename、 unlink など) やソケット イベントはサポートされません。

• 影響: ワークロードは中断されませんが、eBPF がキャプチャする特定のファイルおよびソケット関連のイベントを見逃す可能性があります。

4. 更新されたバージョンで除外を管理するにはどうすればよいですか?

AuditD の除外を配置する一般的な理由を次に示します。

• 一部の syscall またはプロセスが大量のノイズを生成している場合のパフォーマンス

• カーネルパニック、特にネットワーク/ファイルシステム呼び出しの多くがカーネルパニックを起こした場合があります。

• 監査ログがディスク領域を使い切っているノイズの多いログ。 お客様は、ログ サイズを小さくするために、ノイズの多いプロセスの除外を行いました。

eBPF では、最初の 2 つのユース ケースが移行の候補です。 ログは eBPF の問題ではなくなりました。 最初の 2 つのユース ケースでは、次のオプションから選択できます。

• サポートに問い合わせる: Microsoft に問い合わせて、バックエンドからの除外を適用します。

• グローバル除外: Linuxの Defender for Endpoint の更新されたバージョンでは、グローバル除外を使用して除外を管理できます。 グローバル除外はウイルス対策と EDR の両方に適用され、現在マネージド json を使用して構成できます。 詳細については、「Linux 用の Microsoft Defender for Endpoint の除外を構成および検証する」 を参照してください。

5. 問題が発生した場合はどうすればよいですか?

• サポートに問い合わせる: eBPF への移行中または移行後に問題が発生した場合は、テクニカル サポートにお問い合わせください。 Microsoft はスムーズな移行を確保することに取り組んでおり、お客様が直面する可能性のある課題の解決に役立ちます。

• サポート チャネル: Microsoft Defender ポータルからサポートにお問い合わせください。 さらに、サポート情報およびコミュニティ フォーラムは、一般的な問題のトラブルシューティングに役立つ貴重なリソースです。

関連するコンテンツ

Linux 上のエンドポイントのDefenderのトラブルシューティングとリソース管理の詳細については、次の記事を参照してください。

• LinuxでのMicrosoft Defender for Endpointのパフォーマンスに関する問題のトラブルシューティング
• Linux 向け Microsoft Defender for Endpoint の関連リソース