Falco入門｜eBPFでLinuxのランタイム脅威を検知する実践設定ガイド

Linuxサーバーで root が突然 bash を起動した。/etc/shadow が怪しいプロセスに読まれた。そういう事象が起きたとき、あなたは何秒後に気づけますか？

syslog や auditd でも後追い調査はできますが、「異常が起きた瞬間にアラートを受け取る」仕組みにはなっていません。リアルタイムで検知するには、カーネルレベルでシステムコールを監視する専用ツールが必要です。

この記事では、CNCF（Cloud Native Computing Foundation）が管理するオープンソースのランタイムセキュリティツール Falco について、インストールから基本ルールの設定・アラートの読み方まで、現場で使えるレベルで解説します。コンテナ環境がなくても、素のLinuxサーバーに導入して活用できます。

Falcoとは？なぜ今注目されているのか

Falco（ファルコ）は、Linux カーネルのシステムコールをリアルタイムで監視し、疑わしい操作が起きた瞬間にアラートを上げるランタイムセキュリティツールです。2016年に Sysdig 社が開発し、現在は CNCF のプロジェクトとして開発が続いています。

特に以下のような操作を検知するのが得意です。

・機密ファイル（/etc/shadow・/etc/sudoers・SSHキー）への不審なアクセス
・root や特権プロセスによる予期しないシェル起動
・コンテナ内でのインタラクティブシェル起動
・予期しない外部ネットワーク接続（C2通信の疑い）
・設定ファイルへの書き込み

auditd との違いを整理する

監視という意味では auditd に似た役割を持ちますが、設計思想が大きく違います。

Falco は auditd の置き換えではなく、auditd が苦手なリアルタイム検知・アラートを補う役割を担います。両者を組み合わせると、検知と証跡記録を両立した多層防御が構成できます。

eBPF ドライバとは何か

Falco はカーネルのシステムコールを傍受するために、カーネルモジュールまたはeBPF（Extended Berkeley Packet Filter）を使います。

eBPF とは、カーネル内で安全に動作する小さなプログラムを実行する仕組みです。カーネルのソースコードを変更せずに、ネットワーク通信やシステムコールの傍受が可能で、近年セキュリティツールへの採用が急速に広がっています。カーネルモジュール方式と比べて、カーネルクラッシュのリスクが低く、SELinux や AppArmor が有効な環境でも動かしやすいのが特長です。

Falco のインストール手順

1. RHEL / Rocky Linux / AlmaLinux 系

# Falco公式GPGキーを登録
sudo rpm --import https://falco.org/repo/falcosecurity-packages.asc

# リポジトリファイルを設置
sudo curl -s -o /etc/yum.repos.d/falcosecurity.repo \
  https://falco.org/repo/falcosecurity-rpm.repo

# eBPFビルドに必要なカーネルヘッダーを先にインストール
sudo dnf install -y kernel-devel-$(uname -r)

# Falcoをインストール
sudo dnf install -y falco

2. Ubuntu / Debian 系

# 前提パッケージ
sudo apt-get install -y curl gnupg

# GPGキーを登録
curl -fsSL https://falco.org/repo/falcosecurity-packages.asc | \
  sudo gpg --dearmor -o /usr/share/keyrings/falco-archive-keyring.gpg

# リポジトリを追加
echo "deb [signed-by=/usr/share/keyrings/falco-archive-keyring.gpg] \
  https://download.falco.org/packages/deb stable main" | \
  sudo tee -a /etc/apt/sources.list.d/falcosecurity.list

sudo apt-get update -y
sudo apt-get install -y falco

インストール中にドライバ選択が求められます。クラウド環境や SELinux が有効な環境では eBPF probe を選択してください。オンプレミスで管理権限がある環境なら kernel module でも問題ありません。

3. サービスの起動と確認

# サービスを起動
sudo systemctl start falco

# 自動起動を有効化
sudo systemctl enable falco

# 動作確認
sudo systemctl status falco

Active: active (running) と表示されていれば、Falco がカーネルのシステムコールを監視し始めています。

Falco のルール構造を理解する

Falco のルールは YAML 形式で記述します。デフォルトルールは /etc/falco/falco_rules.yaml に格納されており、カスタムルールは /etc/falco/falco_rules.local.yaml に追記するのが基本です（デフォルトファイルを直接編集すると、アップデート時に上書きされます）。

# ルールの基本構造
- rule: ルール名（英語が慣習）
  desc: このルールが何を検知するかの説明
  condition: evt.type = execve and proc.name = bash and user.name = root
  output: "root が bash を起動 (user=%user.name proc=%proc.name parent=%proc.pname)"
  priority: WARNING
  tags: [linux, shell, privilege]

各フィールドの意味：

・condition: 検知条件（Falco 独自の条件記述言語。イベントタイプ・プロセス名・ユーザー名・ファイル名などを組み合わせる）
・output: アラートのメッセージテンプレート（%変数名 で動的な値を埋め込める）
・priority: 重要度（DEBUG / INFO / NOTICE / WARNING / ERROR / CRITICAL）
・tags: 分類タグ（フィルタリングに使える）

デフォルトルールで検知できる主な脅威

Falco にはインストール直後から有効なルールが多数含まれています。特に重要なものを紹介します。

【検知ルール1】機密ファイルへの不審なアクセス

/etc/shadow・/etc/passwd・SSH秘密鍵・SSL証明書などへのアクセスを、信頼されていないプロセスが行った場合に検知します（Read sensitive file untrusted）。

攻撃者がサーバーに侵入した後、真っ先に読もうとするのがこれらのファイルです。通常の運用でアクセスするプロセス以外がこれらに触れた場合、WARNING が上がります。

【検知ルール2】コンテナ内でのシェル起動

Docker や Podman のコンテナ内でインタラクティブなシェル（bash・sh 等）が起動された場合に検知します（Terminal shell in container）。

コンテナはアプリケーションが決まった処理だけを実行するのが前提です。コンテナ内でシェルが起動されるのは、本番環境ではほぼ異常な事象です。

【検知ルール3】/etc 配下への書き込み

/etc/sudoers や /etc/cron.d/ など、設定ファイル群への書き込みを検知します（Write below etc）。

攻撃者が権限昇格や永続化のために設定ファイルを改ざんしようとするケースに対応します。

【検知ルール4】予期しない外部ネットワーク接続

Web サーバーや DB サーバーといった特定のプロセスが、通常の通信先とは異なる外部 IP へ接続しようとした場合を検知します。マルウェアが C2（指令サーバー）と通信しようとするシナリオで有効です。

アラートの確認方法と読み方

Falco のアラートはデフォルトで /var/log/falco.log に記録され、journald 経由でもリアルタイムに確認できます。

# リアルタイムでアラートを確認
sudo journalctl -fu falco

# ログファイルを直接確認
sudo tail -f /var/log/falco.log

# 重要度 WARNING 以上だけ絞る場合
sudo journalctl -u falco | grep "Warning\|Error\|Critical"

アラートの出力はこのような形式です。

14:22:35.881304785: Warning Sensitive file opened for reading by non-trusted program
(user=www-data user_loginuid=-1 program=curl
file=/etc/shadow parent=bash gparent=sshd ...)

この例では、www-data ユーザーで動いている curl プロセスが /etc/shadow を読もうとした事実が記録されています。Web アプリの脆弱性を突かれてシェルを取られ、パスワードファイルを盗もうとしている可能性が高い状態です。

カスタムルールの作成例

自分の環境に合わせたルールは /etc/falco/falco_rules.local.yaml に追加します。

# カスタムルール例: Webサーバーがドキュメントルート外に書き込んだ場合に検知
- rule: Web server writes outside web root
  desc: nginx/apache がドキュメントルート(/var/www)外にファイルを書き込もうとした
  condition: >
    (proc.name = nginx or proc.name = apache2 or proc.name = httpd)
    and evt.type = write
    and not fd.name startswith /var/www
    and not fd.name startswith /tmp
    and not fd.name startswith /run
  output: >
    Webサーバーが予期しない場所へ書き込み
    (user=%user.name proc=%proc.name file=%fd.name parent=%proc.pname)
  priority: ERROR
  tags: [web, linux, custom]

ルール追加後は Falco を再起動して反映します。

# ルール構文チェック（エラーが出なければOK）
sudo falco -c /etc/falco/falco.yaml --validate /etc/falco/falco_rules.local.yaml

# Falco再起動
sudo systemctl restart falco

中小企業でも今日からできること

Falco の導入は難しそうに見えますが、最低限なら3ステップで始められます。

・ステップ1: インストールしてデフォルトルールのまま1週間動かし、どんなアラートが上がるかを観察する
・ステップ2: 誤検知（正常な操作に対するアラート）が多いルールは falco_rules.local.yaml で例外（exception）を追加して絞り込む
・ステップ3: アラートを既存の通知チャンネル（syslog 経由でメール・Slack 等）に転送して、担当者に即座に届く仕組みを整える

予算ゼロの環境でも、デフォルトルールのままで「/etc/shadow への不審アクセス」「/etc/sudoers の改ざん」「コンテナ内シェル起動」を自動検知できます。それだけでも、気づかなかった侵害の初動を大幅に早められます。

Linuxサーバーのログ監視基盤については、Linuxログ監視入門｜syslog・journald・auditdで証跡を残すもあわせて参照してください。Falco と組み合わせることで、リアルタイム検知と長期証跡保存を両立した多層防御が実現できます。

侵害が起きた後の詳細な調査手法については、auditdログから侵入痕跡を見抜く実践ガイドを参照してください。Falco が「何か起きた」を知らせ、auditd のログで「何が起きたか」を詳細に追う、という役割分担が効果的です。

よくある誤解と注意点

【誤解1】「Falco を入れれば攻撃を防げる」

Falco はあくまで「検知」ツールです。firewalld や WAF のように攻撃を遮断する機能はありません。検知したあとの対応手順（インシデントレスポンスのフロー）を事前に整備しておくことが重要です。

【誤解2】「デフォルトルールはそのまま使える」

デフォルトルールは汎用的に設計されているため、環境によっては正常な運用操作が誤検知されることがあります。導入直後は1週間程度アラートを観察して、自社環境に合わせた例外設定を行いましょう。

【注意1】カーネルアップデート後の確認

カーネルモジュール方式で運用している場合、カーネルをアップデートするとモジュールの再ビルドが必要になります。eBPF 方式を選択しておけばこのリスクを軽減できます。カーネル更新後は systemctl status falco で正常動作を確認する運用ルールを設けることを推奨します。

【注意2】パフォーマンスへの影響

Falco はシステムコールをすべて傍受するため、高負荷環境では一定のオーバーヘッドが発生する場合があります。本番環境への導入前にステージング環境で負荷テストを実施してください。通常の Web サーバー程度の負荷では、体感できるほどの影響は出ないケースがほとんどです。

本記事のまとめ