汎用 Linux で考える Detection & Response – EDR 導入ありきにしない D&R 設計

セキュリティ分野では、EDR、NDR、XDR のように Detection and Response を含む用語を目にする機会が増えています。これらの言葉から D&R を考えると、D&R を実現するにはまず EDR 製品を導入する必要がある、という順序で考えてしまいがちです。

しかし、D&R は本来、特定の製品カテゴリーではありません。Detection はセキュリティ上意味のある事象を見つける能力であり、Response は検知した事象を調査し、影響を限定し、復旧や改善へつなげる能力です。EDR はその能力を実現するための有力な手段ですが、D&R そのものではありません。

特に用途が明確な Linux サーバーでは、Linux が持つ監査、強制アクセス制御、ログ、ネットワーク制御、自動化基盤を組み合わせることで、D&R に必要な能力のかなりの部分を設計できます。本稿では、EDR 導入の是非ではなく、汎用 Linux サーバーに必要な Detection and Response Capability から考えます。

D&R は製品ではなく能力である

D&R を単純化すれば、Detection と Response の二つに分けられます。ただし実際のインシデント対応は、検知と対応だけで完結しません。NIST SP 800-61 Rev. 3 は、インシデント対応を Cybersecurity Framework 2.0 全体の中に位置付け、検知、対応、復旧を含む継続的なリスク管理として扱っています。

段階	役割
Prevent	既知のリスクを減らし、攻撃が成立しにくい状態を作る
Observe	ログ、監査、ネットワーク、サービス状態を観測する
Detect	観測結果からセキュリティ上意味のある逸脱を検知する
Analyze	単発のログではなく、前後関係と影響範囲を分析する
Respond	証跡保全、通信制限、アカウント停止、復旧作業などを行う
Recover	正常な状態へ戻し、サービスと業務を再開する
Improve	検知条件、運用手順、構成管理を更新する

この流れで見ると、EDR は D&R を構成する部品の一つです。最初に問うべきなのは「Linux サーバーに EDR を入れるべきか」ではなく、「その Linux サーバーで何を検知し、何を根拠にインシデントと判断し、どこまでを自動または承認付きで対応するのか」です。

Linux サーバーは正常状態を定義しやすい

一般的な PC とサーバーでは、正常状態の定義しやすさが大きく異なります。PC では利用者が Web ブラウザー、Office 製品、開発ツール、VPN、USB デバイスなどを使い、日々の操作も多様です。一方、商用サービスを提供する Linux サーバーは用途が限定されます。

DNS サーバーであれば、DNS サービスのプロセスが動作し、TCP/UDP 53 番ポートで要求を受け付け、決められた管理ネットワークから管理され、設定変更も決められた手順で行われる、という正常状態を比較的明確に定義できます。RADIUS、DHCP、Web、DB などのサーバーでも同じです。

これは D&R にとって重要です。Detection は、単にログを集めることではなく、正常状態からのセキュリティ上意味のある逸脱を見つけることだからです。用途が固定されたサーバーでは、何が動いてよいのか、どこから管理されてよいのか、どのファイルがいつ変更されてよいのかを設計しやすくなります。

Linux には既に多くの観測点がある

Linux には、D&R の Telemetry として利用できる仕組みが以前から存在します。重要なのは、個々のログをそのままアラートにすることではありません。複数の観測点を組み合わせ、サーバーの役割から見て説明できない状態を見つけることです。

観測対象	代表的な仕組み	D&R での意味
ログイン	sshd、PAM、journald、syslog	誰が、どこから、いつ管理面へ入ったかを確認する
特権操作	sudo ログ、Linux Audit	権限昇格や管理操作の起点を追跡する
プロセス実行	Linux Audit、eBPF	通常動かないコマンドやプロセスを検知する
ファイル変更	Linux Audit、inotify、FIM	重要設定や認証情報の変更を追跡する
SELinux 違反	AVC、Linux Audit	ポリシー上許可されていない操作を検知する
サービス状態	systemd、journald	停止、再起動、異常終了を運用状態と結び付ける
パッケージ変更	rpm、dnf、apt のログ	実行環境の変更を追跡する
ネットワーク	nftables、conntrack、eBPF、Flow	通信先、通信量、管理面へのアクセスを確認する
Kernel イベント	audit、eBPF、kernel log	ユーザー空間のログだけでは見えない変化を補う

例えば、SSH ログイン、sudo 実行、シェル起動、設定ファイル変更、サービス再起動は、単独では正常な管理作業に見える場合があります。しかし、通常使われないアカウント、通常と異なる接続元、通常と異なる時間帯、事前承認のない設定変更と組み合わせれば、セキュリティ上意味のある検知条件になります。

auditd は Linux D&R の重要な観測点になる

Linux Audit は、セキュリティ上重要なイベントを記録し、誰がどの操作を行ったのかを追跡するための仕組みです。auditd によって、特定ファイルへのアクセス、System Call、プロセス実行などを監査できます。

観測対象の例	検知で見るべき点
/etc/passwd、/etc/shadow、/etc/sudoers	アカウント、認証、権限に関わる変更が正規手順と一致するか
/etc/ssh/、/etc/systemd/、/etc/audit/	管理入口、サービス定義、監査設定が意図せず変更されていないか
bash、curl、wget、nc、ssh、scp	侵入後の調査、外部取得、横展開に使われる実行がないか
chmod、chown、systemctl、useradd	権限変更、サービス操作、アカウント作成が承認された作業か

ここでも、コマンドが実行された事実だけを攻撃と見なすべきではありません。例えば、通常使用されないアカウントで SSH ログインし、sudo を実行し、外部からファイルを取得し、実行権限を付けて動かした、という連続した事象であれば、単発のログよりもはるかに強い検知条件になります。MITRE ATT&CK でも、防御機能の無効化や変更に対して、プロセス実行、System Call、設定変更、syslog など複数の Telemetry を組み合わせる Detection Strategy が示されています。

SELinux は Prevent だけではない

SELinux は、一般にはアクセス制御や Hardening の仕組みとして説明されます。しかし D&R の観点では、侵入後の行動範囲を制限し、その制限に触れた動きを観測できる点が重要です。

たとえば DNS サーバーのプロセスが脆弱性によって侵害されたとしても、適切な SELinux ポリシーが設定されていれば、そのプロセスがシステム全体へ自由にアクセスできるわけではありません。攻撃者が /etc/shadow の参照や、許可されていない領域への書き込みを試みても、ポリシーによって拒否される可能性があります。

この意味で SELinux は、侵入そのものだけを防ぐ機能ではありません。侵害後に攻撃者が取れる行動範囲を限定する Containment の機能でもあります。D&R の設計では、こうした制約を Prevent としてだけでなく、Response の前段にある影響限定の仕組みとして扱うべきです。

SELinux の拒否は Detection Signal になる

SELinux によるアクセス拒否は、AVC Denial として監査ログに記録されます。通常のファイルアクセスログは、あるプロセスがファイルへアクセスしたという事実を示すだけです。一方、AVC は、そのプロセスがセキュリティポリシー上許可されていない操作を試みたことを示します。

もちろん、AVC がすべてインシデントを意味するわけではありません。ポリシーの不足、アプリケーション更新、設定変更によって新しい AVC が出る場合もあります。それでも、正常状態を定義したサーバーで、これまで存在しなかった AVC が突然発生した場合、それは有力な Detection Signal になります。

SELinux を無効化してしまうと、アクセス制御が弱くなるだけでなく、ポリシー違反という意味の強い観測点も失われます。D&R の観点では、SELinux を単なる邪魔な制約として扱うのではなく、侵害後の行動を限定し、異常な試行を観測するための設計要素として扱う必要があります。

eBPF は EDR そのものではない

Linux では eBPF も強力な Telemetry 基盤になっています。Linux kernel の公式ドキュメントでは、eBPF が Networking、Tracing、Linux Security Modules など複数の Kernel subsystem と接続できる仕組みとして整理されています。プロセス実行、ネットワーク接続、System Call、Kernel イベントなどを低いレイヤーから観測できるため、現在の Linux 対応 EDR や Runtime Security 製品でも eBPF が利用されることがあります。

ただし、eBPF そのものが EDR なのではありません。eBPF は Telemetry を取得するための技術です。取得したイベントをどの文脈で評価し、何を異常とし、どの単位でインシデントへまとめ、どの対応へつなげるかを設計して初めて D&R になります。

層	役割
eBPF	Kernel 付近のイベントを取得する
Telemetry	プロセス、ファイル、通信、System Call などの事象を集める
Detection Logic	正常状態と脅威仮説に基づいて意味のある事象を抽出する
Alert / Incident	調査対象として扱う単位にまとめる
Investigation	前後関係、影響範囲、横展開の有無を確認する
Response	証跡保全、通信制限、アカウント停止、復旧を行う

Response も Linux の汎用技術で実現できる

D&R では Detection だけでなく Response が必要です。Linux サーバーでは、Response にも既存の運用技術を利用できます。nftables による通信制限、アカウントのロック、SSH key の無効化、systemd によるプロセス停止、証跡取得、VM Snapshot、Ansible による設定復旧、Known Good Image からの再構築などです。

段階	実施内容	自動化の考え方
検知	ログ、監査、通信、サービス状態から事象を検出する	自動化しやすい
インシデント化	複数イベントを相関し、調査単位としてまとめる	条件付きで自動化する
証跡保全	ログ、設定、プロセス、通信状態を保存する	早期自動化の価値が高い
担当者確認	誤検知、業務影響、実施可否を判断する	重要サービスでは承認を挟む
通信制限	nftables、ACL、Security Group などで範囲を絞る	影響範囲に応じて承認付きにする
復旧	Ansible、構成管理、再構築で正常状態へ戻す	再現性のある手順に限定する

商用サービスでは、セキュリティ製品による完全自動隔離が可用性上のリスクになる場合があります。DNS や RADIUS のような重要サービスを誤検知で停止すれば、攻撃以上のサービス影響を生じさせる可能性があります。そのため、観測、調査、証跡保全は自動化し、隔離や停止は承認付きにするなど、Response の段階ごとに自動化レベルを変える設計が必要です。

Linux D&R を構成要素として見る

汎用 Linux を中心に D&R を考えると、構成要素は特別な製品名ではなく、観測点、相関、インシデント化、対応手順に分解できます。製品を使う場合でも、この分解をしておかなければ、どの能力を製品に任せ、どの能力を既存運用で担うのかを判断できません。

構成要素	具体例	設計上の問い
観測点	auditd、SELinux AVC、journald、サービスログ、Flow、eBPF	何を根拠に異常を見つけるのか
収集	ログ転送、エージェント、API、メッセージ基盤	必要な Telemetry が欠落せず集まるか
相関	SIEM、独自ルール、EDR、NDR	単発ログではなく前後関係を見られるか
インシデント化	チケット、アラート、ケース管理	誰が調査し、どの単位で完了させるのか
Response	Ansible、API、nftables、アカウント制御、再構築	どこまで自動化し、どこで承認するのか
改善	検知条件、Playbook、構成管理、復旧手順	検知と対応の経験を次の設計へ戻せるか

EDR が不要という話ではない

ここまで見ると、D&R に必要な多くの部品は Linux や既存の運用技術で実現できるように見えます。しかし、そこから Linux に EDR は不要だと結論付けるのは雑です。専用 EDR には、自前で汎用技術を組み合わせる場合には得にくい価値があります。

• Detection Rule の継続的な更新
• Threat Intelligence と IOC との照合
• 攻撃チェーンの相関分析
• プロセスツリーや親子関係の可視化
• 複数ホストをまたぐ調査
• Forensics 支援
• Response 機能と管理 UI
• セキュリティベンダーによる継続的な研究

難しいのは、Telemetry を取得すること自体ではありません。大量の Telemetry から、本当にセキュリティ上意味のあるイベントを継続的に見つけることです。auditd で大量のイベントを取得しても、それだけでは運用できません。Context、Correlation、Detection Logic、Security Finding へ変換する仕組みが必要です。

EDR か自前かではなく能力から考える

Linux サーバーの D&R は、EDR か自前かという二択から始めるべきではありません。最初に定義すべきなのは Capability です。必要な能力を分解し、それぞれを Linux 標準機能、OSS、ネットワーク側の観測、SIEM、EDR、SOAR、自動化基盤のどれで実現するかを選ぶべきです。

必要な能力	実現方法の例	判断ポイント
SSH ログイン検知	sshd、journald、SIEM	管理元、時間帯、利用者を正常状態と比較できるか
特権操作監視	sudo、auditd	権限昇格と変更作業を追跡できるか
プロセス実行監視	auditd、eBPF、EDR	通常動かないコマンドを文脈付きで検知できるか
ファイル変更監視	auditd、FIM、EDR	重要ファイルの変更を手順や承認と結び付けられるか
MAC 違反検知	SELinux AVC	許可されない操作の試行を見落とさないか
ネットワーク監視	Flow、nftables、eBPF、NDR	通信先、通信量、管理面アクセスを評価できるか
イベント相関	SIEM、EDR、独自ルール	単発ログをインシデント単位へまとめられるか
Response	Ansible、API、EDR、SOAR	証跡保全、制限、復旧を再現可能に実行できるか

この整理をした上で、Linux 標準機能で十分な領域、EDR に任せる領域、ネットワーク側で見た方がよい領域、サービス側のログでなければ判断できない領域を分けます。D&R を能力として分解しておけば、製品導入も否定ではなく設計上の選択になります。

サービス固有の Detection も必要である

商用サービス基盤では、OS だけを監視すれば十分というわけではありません。DNS サーバーであれば、Linux のプロセスやファイルだけでなく、ゾーン変更、クエリー傾向、管理 API、上位の構成管理、ネットワーク経路も見る必要があります。RADIUS であれば、認証ポリシーや認証失敗の傾向、接続元装置の変化も検知対象になります。

DNS ゾーンの不正変更は、OS から見れば正規プロセスによる正常なファイル変更に見える可能性があります。RADIUS の認証ポリシー変更も同じです。仮想基盤側で VM の NIC や Security Group を変更された場合、Guest OS だけを監視していても攻撃の起点を把握できない場合があります。

観測層	見るべき内容
Host Detection	Linux のログ、監査、プロセス、ファイル、SELinux、通信
Service Detection	DNS、RADIUS、Web、DB などサービス固有の状態と操作
Identity Detection	管理者、サービスアカウント、認証元、権限変更
Network Detection	通信先、通信量、管理面、横展開、境界通過
Infrastructure Detection	VM、Kubernetes、クラウド、ネットワーク機器側の変更

ここは PC 向け EDR と大きく異なる点です。商用 Linux サーバーの D&R は、Host だけでは完結しません。サービス、ID、ネットワーク、基盤を含めて、正常状態からの逸脱を設計する必要があります。

まとめ

D&R は EDR という製品カテゴリーと同義ではありません。Linux には、Linux Audit、SELinux、journald、syslog、PAM、sudo、nftables、systemd、eBPF、各種サービスログなど、D&R に利用できる多くの仕組みがあります。用途が固定された Linux サーバーでは正常状態を定義しやすいため、これらの汎用技術を組み合わせた Detection は有効です。

一方で、Telemetry を取得できることと、D&R を運用できることは別です。何を観測するか、何を異常とするか、どう相関するか、どの時点で Incident と判断するか、何を Response するかを継続的に設計しなければなりません。この部分を継続的に提供する点で、EDR や SIEM、NDR、SOAR には大きな価値があります。

重要なのは、EDR 導入ありきでも、EDR 不要論でもありません。必要な Detection and Response Capability を定義し、それを実現するために Linux 標準機能、OSS、ネットワーク観測、SIEM、EDR、自動化基盤をどう組み合わせるかを決めることです。汎用 Linux サーバーの D&R は、製品名ではなく能力の設計から始めるべきです。

参考書籍

参考資料

• NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• Linux kernel documentation: eBPF userspace API
• MITRE ATT&CK Detection Strategy DET0062
• MITRE ATT&CK: T1685.004 Impair Defenses – Disable or Modify System Firewall
• auditd(8) – Linux manual page
• nftables project
• O'Reilly Japan: 入門 eBPF

関連する記事