Falco は Kubernetes のツールとして知られており、それについての手引きはほぼすべてクラスタ向けに書かれています。しかしそれはクラスタに縛られていません。システムコールを見張るのであり、サイトのある普通のサーバーでもまったく同じように働きます。ただこの場合について書く人がほとんどいないだけです。

そしてそれが役立つのは、まさに他のツールが黙っているところです。サイト上の web shell はどの権限も侵さず、失敗ログインも生まず、手書きならどのシグネチャにも一致しません。しかし Web サーバーにとって普通でない振る舞いを一つ持っています。PHP-FPM のプロセスがシェルを起動するのです。そしてそれこそ Falco が見るものです。

何を感じ取れるのか

普通のサーバーでの代表的な出来事：

  • Web サーバーや PHP のプロセスから生まれたシェル——実質的に web shell の紛れもない印です；
  • /tmp、/dev/shm、/var/tmp から起動されたプログラム；
  • それとは無関係なプロセスによる、機微なファイル（/etc/shadow、秘密鍵）の読み取り；
  • システムのバイナリファイルの変更；
  • ネットワークを使うはずのないプロセスからの外向きの接続。

インストール

肝心の選択はインストール時にあります。Falco がシステムコールをどう受け取るかです。現代的な道筋は eBPF に基づき、カーネルモジュールの構築もカーネルヘッダも必要としません。

sudo falcoctl driver config --type modern_ebpf
sudo systemctl restart falco

古典的なカーネルモジュールはヘッダを必要とし、カーネル更新のたびに作り直されます——そして更新が自動で入るサーバーでは、それがサービスの死を繰り返す原因になります。カーネルが十分に新しければ（5.8 以上）eBPF を選び、この問題は忘れてしまってください。

イベントが本当に来ていることを確かめるには：

sudo systemctl status falco
sudo journalctl -u falco -n 50

ノイズと、その片づけ方

そしてこれが主な作業です。標準のルールセットはコンテナ環境に寄っており、普通のサーバーではその目に見える部分がそもそも当てはまらないか、絶えず発火するかのどちらかです。

付属のルール（/etc/falco/falco_rules.yaml）は編集しません——更新のときにファイルごと差し替えられます。あなたの変更は /etc/falco/falco_rules.local.yaml へ入れ、望まないルールもそこで切ります。

- rule: Terminal shell in container
  enabled: false

コンテナの無いサーバーでたいてい調整が要るもの：

  • コンテナに関するルールすべて——コンテナが無ければレポートの場所を取るだけです；
  • 「Write below etc」——パッケージのインストールのたび、そしてあなたが設定ファイルを編集するたびに発火します。apt、dpkg、unattended-upgrades のための例外が必要で、無ければ出来事は洪水のように来ます；
  • 「Read sensitive file untrusted」——監視のエージェント、バックアップのツール、Lynis のような監査ツールで発火します；
  • 一時ディレクトリからの起動——正当な例外があります。アプリケーションのビルド、あるいはドライバを一時ディレクトリに開く自動化ブラウザなど。そうした出来事は不穏に見えますが説明可能であり、毎回考え直すより、その具体的なパスに対する例外をすぐ足すほうがよいのです。

妥当な順序は他のどの検知ツールとも同じです。最初の一週間は観察して例外を足すだけ、そのうえで初めて出てくる出来事を合図として扱う。そして規則は単純です——読まない出来事が定期的にレポートに載っているなら、それはあなたのために何もしていません。

出来事をどこへ送るか

出力は /etc/falco/falco.yaml で設定します。ファイル、システムのジャーナル、あるいは外部プログラムへの流し込み。一台のサーバーなら、後段のローテーションつきのファイル一つで足ります——ローテーションを忘れないでください。出来事のファイルも他のログと同じように育ちますし、既定では誰も見ていません。

そして分けるために優先度を使う価値があります。重大な出来事はすぐ目に入る場所へ、残りは後で見るために共通のジャーナルへ。

Falco と auditd は同じものではない

どちらもシステムコールを見張りますが、目的が違います。auditd は後から絵を組み直せるように、起きていることを記録します。何も評価せず何も報せず、ジャーナルを保つのです。一方 Falco は出来事の瞬間にルールを適用して「これは怪しく見える」と言います——つまり合図を出すのであって、記録ではありません。

両方持つのは理にかなっています。組み直すためのジャーナルと、反応するための合図です。一つだけ選ぶなら、事故の後に出来事の順序を組み直すことが最も重要なサーバーでは auditd のほうが役立ち、動いている採掘プログラムや web shell についての早い合図が要る場面では Falco です。

小さなサーバーで場所を取る価値があるか

正直な答えは「いつもではない」です。Falco はシステムコールを処理し、忙しいマシンではプロセッサへの影響が体感されます。サーバーにサイトが一つあるだけで、完全性の監視もまともな自動更新もまだ無いなら、ここから始めるべきではありません。

その出番は後になって来ます——基本的な作業が済み、ログが見せてくれないものがサーバーで何なのか、という問いだけが残ったときです。そして一種類の出来事については、それが他のすべてを合わせたよりよく覆ってくれます。Web サーバーのプロセスが起動したシェルです。優先度とルールで分けられた出来事がどう見えるかは、下のデモページで。