cxray で falco のルールを生成する

以前 は BPF を使ってコンテナの中のイベントを取得する cxray を作った話を書いた。 cxray で現在取得できるイベントは次の4つ。 起動したプロセス 開かれたファイル TCPv4 での接続先 TCPv4 での network listener cxray のユースケースとして、生成されたイベントをホワイトリストとして定義し、別のモニタリングツールのルールなどに利用することを想定している。 ここではシンプルな Rails 環境を動かし、falco のルールを作るところまでやってみる。 環境 次のような docker-compose.yml を用意し、rails が起動するところまでのイベントを取得する。 version: "3" services: app: build: . ports: - "3000:3000" environment: - "DATABASE_HOST=db" - "DATABASE_PORT=5432" - "DATABASE_USER=postgres" - "DATABASE_PASSWORD=password" links: - db volumes: - "./:/app" stdin_open: true db: image: postgres:10.1 ports: - "5432:5432" environment: - "POSTGRES_USER=postgres" - "POSTGRES_PASSWORD=password" cxray を起動し、 docker-compose up する。

Semaphore CI で BPF を使ったプログラムのテストをする

BPF を使うプログラムはコンテナで動かすには特権が必要であったり、Linux カーネルの特定のコンフィグが ON になっていないと(CONFIG_BPF=yとか)動かないなどあり、Circle CI や Travis CI のような有名どころの CI では十分にテストすることができない。 Semaphore CI は CI 環境として VM が提供されるので、Docker などの実行が可能である。 ただ、VMが使えるだけでは Linux カーネルのコンフィグ問題は解決しないのだが、rkt の KVM Stage1 が使える。 自前でビルドした Stage1 Image を KVM で動かし、その上で Pod を動かすことができる。 この方法は https://kinvolk.io/blog/2017/02/using-custom-rkt-stage1-images-to-test-against-various-kernel-versions/ に書いてある。 上記ブログでは ACI のビルドをしているが、 stage1-builder で作成されたイメージがあるので、それを使うのが楽。 カーネルのヘッダは /lib/modules/${kernel_version}-kinvolk-v1/source/include などにあるため、それを C_INCLUDE_PATH に追加しておく。あとは、ホスト側にあるリポジトリのパスをマウントしてあげれば良い。 --environment=C_INCLUDE_PATH="${kernel_header_dir}/arch/x86/include:${kernel_header_dir}/arch/x86/include/generated:/lib/modules/${kernel_version}-kinvolk-v1/include" \ また、使う Docker Image で bcc がソースからビルドされている場合は BCC_KERNEL_MODULES_SUFFIX を source にしておく必要がある。 ref : https://github.com/iovisor/bcc/pull/430/files 困っているのは、たまに rkt から名前解決ができないことがあり、依存パッケージのダウンロードに失敗してしまうということ。 これはどういう問題なのだろうな… というのを調べるために、手元で環境を作って再現するまでがちょっと面倒。 cxray だと、こんな感じで CI 上でのビルドとテストができた。

Profiling Event in Container With Cxray

前回は bcc を使ってコンテナ内の execve を取得する方法について書きました。 最近 falco などを使い、Kubernetes の Pod の安全性を高めているのですが、そのルールを定義するのが難しいと感じていました。 例えば NIST の Application Container Security Guide の 4.4.4 節では次のイベントが発生することを検知できるようにしたほうが良いと書かれています。 Invalid or unexpected process execution, Invalid or unexpected system calls, Changes to protected configuration files and binaries, Writes to unexpected locations and file types, Creation of unexpected network listeners, Traffic sent to unexpected network destinations, and Malware storage or execution. ref : https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-190.pdf 「期待していないプロセス」「期待していない通信先」などと言われても列挙するのは難しいと思います。 そこで、BPF を使って特定のシステムコールを取得すれば、ある程度ホワイトリスト化できるのではないかと思い、 cxray というツールを作りはじめました。