クラウドストライクの障害
ken
リスナーのみなさん、こんにちは。London Tech TalkのKen Wagatsumaです。
今日はですね、ゲストの方をお二人お呼びしています。
ではまず、お一人目のゲストから紹介します。
じゃあ、坂尾さん、今日はよろしくお願いします。
Takumasa Sakao
はい、よろしくお願いします。
ken
坂尾さんはね、今日は3回目の収録になりますね。
前回はクーバコンの振り返り出てくださって、最初はオープンソースの話をしてくださいました。
Takumasa Sakao
はい、今日はガヤ芸人として来ました。よろしくお願いします。
ken
ガヤ芸人、期待します。
じゃあ、お二人目のゲストは、けいすけさん、お呼びしています。
けいすけさん、よろしくお願いします。
Keisuke
よろしくお願いします。
ken
けいすけさんも3回目ですね。
1回目がブッククラブで、2回目が eBPF のことを出てくれましたね。
Keisuke
はい、そうですね。
ken
はい、ということでですね、この座組で今日は何を話していくかということなんですけど、
ちょっと時事ネタを取り扱いたいなと思っています。
もうね、だいぶ落ち着いた感じはあるんですけど、
クラウドストライクとWindowsのブルースクリーンの話をしていこうと思うんですけど、
トムヒサさん、きっかけはですね、このトムヒサさんがTwitterで、
けいすけさんのeBPFの話を聞いた上で、
クラウドストライクのWindows障害が起こったときに、
チェンジログっていう結構有名どころの技術テックニュース的なポッドキャストがあるんですけど、
そこでそのクラウドストライクを簡単に紹介していて、
eBPFの技術を使っていたら起きていなかったのではないかと、
そこで言及されていたと。
それを受けてTwitterでちょっと感想を書いてくれていて、
簡単に読み上げると、ロンドテックトークでeBPFの話を聞いていましたが、
先週のWindows障害はeBPFの技術を使っていたら起きていなかったと聞いて納得しましたと。
Linux版ではすでにeBPFを対応を進めているし、
WindowsのeBPF対応も発表されて、
正式公開されるとそちらが用いられていくとのことを興味深いですねと感想をくれたので、
これを受けて、eBPFといえばけいすけさんがいるし、
けいすけさんと坂尾さんを呼んで合同収録したいなってずっと言ってたなと思って、
じゃあこのネタでしちゃおうかなっていう風に、
かずさんと盛り上がったのでお二人をお呼びした感じです。
問題の根本原因
ken
はい、急にね。
Keisuke
なるほど。
Takumasa Sakao
ありがとうございます。
ken
Windows障害これ見ました?
ちょっとニュースで見たぐらいですか?お二人は。
Keisuke
見ました。
話題になりましたね。
突然Twitterとかで見たらなんかすごい話題になってるってなって、
Takumasa Sakao
ちょっとオフィスがザワザワしました。
僕もTwitterで見てたぐらいですね。
Windowsマシンないから、使ってないから、
実害はこむってないんですけど。
ken
日常生活も支障なかったですか?普通に日本で。
なかったと思いますね。
Keisuke
なかったですね。
ken
世の中的には航空会社が止まったりとか見てるみたいでしたけど。
なんかちょうど夏休みの時期とかだったんで、
友人ファミリーとかが空港で足止め食らったみたいなのは結構あったんですけど、
僕は個人的にもなかったんですね。
簡単にじゃあちょっとクラウドストライクで何が起こったかっていうのを、
簡単にさまろうかなと思うんですけど、
これはクラウドストライク.comのほうで、
ポストインシデントレビューが出たんですね。
ちょっと簡単にさまると、
どうやらクラウドストライクの出している根本原因は、
マルフォームのコンフィギュレーションファイルを配布しちゃったと。
配布しちゃったミスコンフィギュレーションみたいな感じなのかな。
それによって結構アウトオブバウンドメモリーがクライアント側で起こってしまって、
それが結果としてブルースクリーンに繋がってしまったみたいなのを書いていたんですね。
なんかシンプルにソフトウェアバグを埋め込んだけれども、
ちゃんとテストフローとかステージドロールアウトとかは、
あったといえばあったっぽいんですけど、
ちょうどバリデーションをする側のデプロイメントパイプラインの一部のサブシステムにもバグがあったりとか、
割とコンプレックスシステムフェルズにコンプレックスウェイという、
複雑なシステムが複雑に壊れるみたいな現場でも言ったりするんですけど、
いろんな複合要因が相まってこの原因にブルースクリーンになってしまったんだ、
みたいなことはクラウドストライクのブログで書いてあったと理解してるんですけど。
お二人はここら辺キャッチアップとかしてました?
こんな感じのかなと思って。
Keisuke
このPodcastを撮るってなってちゃんと見てて、
設定ファイルのアップデートによって引き起こされてみたいなのは聞きまして、
そうですね、デプロイも徐々にやっていくんではなくて一気に配布されちゃったとか、
そういう配布の方法にも問題があるよみたいなことを言ってる人がいたりとか、
あとはそもそもサードパーティーのアプリがカーネルランドで動いてるのがおかしいんだとか、
いろんな意見を見ましたね。
ken
なるほどね。
これ難しいですよね、間違った設定ファイルを配ってバグ出す問題。
普通にあるあるだなと思って。
そういう経験ありますか?
Takumasa Sakao
普通にバグらせたことはあるけど、設定ファイルっていうのは色々ありますよね。
例えばフィーチャーフラグとか、フィーチャーフラグでローリングアップデートするとかそういう話とかもありそうだけど、
設定に関してはどうだろうな。
あったような気がするけど、多分嫌な記憶だから忘れちゃってますね。
ken
今回のクラウドストライクで問題となったファイルの、これバージョン番号なのかな。
チャンネルファイル291、チャンネルファイル291番みたいなのが言われていて、
これがクラウドストライクの製品の一つであるファルコンセンサーと呼ばれるものの設定ファイルだと認識していて、
これが今回、このチャンネルファイル291にミスがあったと理解してますね。
これ多分けいすけさん書いてくれたんだと思うんですけど、
このチャンネルファイル291自体の目的としては、
Windowsにおけるプロセス間コミュニケーションに使われるネームドパイプっていうのの実行評価の機能向上を目指して、
一応機能改善みたいな感じでリリースされた設定ファイルなのかなと理解してるんですけど、けいすけさんあってそうですか?
Keisuke
僕はいろいろ記事を読んで、そのように書いてあった記事を見つけて、
ネームドパイプの悪意を検知する、そういった能力の向上を目指してたっていう風に書いてましたね。
最終的にはアクセスしちゃいけないメモリー領域にアクセスしちゃって、ブルースクリーンになったということですよね。
Takumasa Sakao
ちなみに設定ファイルによってこれって機能が変わるような挙動になるんですねっていうのが思ったところなんですけど、
Keisuke
ある種フィーチャーフラグみたいなのを想定していいんですかね、こうやって。
僕はそういう風に勝手に想像してました。
設定ファイルのお書きによってアプリの機能の振る舞いが、アプリの振る舞いが変わってみたいなことかなと、想像になりますけど。
eBPFの重要性
Takumasa Sakao
ありがとうございます、なるほど。
ken
クラウドストライクの中の人とかじゃないんで、実際どれぐらいこんなもんだったのかっていうのを、
実際どういうデプロイメントパイプラインなのかってちょっと分からないんですけど、
今日の収録で深掘りたいのはどっちかというとそのメイントピックが、
EBPFなる技術でこういった似たような問題がLinuxで起きたときに、
もしくはWindowsのEBPFを使ったときに防げたのか本当にっていうところを議論していきたいなと思ってるんですよね。
いきなりそれがイエス・ノーかっていうのを聞く前に、
そもそもなぜEBPFが言及されているのかみたいなところを、
けすけ様は事前に調べてくれたと思うんで、
ちょっとこの文脈でなぜEBPFが言及されているのか、
なぜEBPFが使われていたら今回の事件は起こらなかったんじゃないかというふうに言われているのか、
簡単にさまってもらうことって可能ですか。
Keisuke
EBPFは、そもそもその機能自体はLinuxとかのKernel内のデータとかにアクセスして、
監視の向上であったり、セキュリティ的に何かを監視したりとか、
あとネットワークのルーティングとか、
そういったものに使われる、Kernelスペースで動くプログラムだと僕は思っていて、
Kernelスペースで動くってことは、
何か今回のようなクラウドストライクのようなバグがあったら、
クラッシュさせてしまう可能性があるんですけれども、
EBPFが優れているというか、
なんでこの文脈で言及されているかというところの一つに、
EBPFにはVerifierと呼ばれる機能があって、
実行されるプログラムが事前にそのVerifierによって検証されるっていうプロセスを踏んで、
そのVerifierによって安全だというふうに、
いずみつきもらったプログラムしか動かせないようになっている。
何をもって安全としているかっていう部分なんですけれども、
僕はちょっと調べた限り、
まずVerifierはEBPFのプログラムが実行したときに通る可能性のある全経路っていうのを分析して、
Zコードがないかとかループがない、
ちょっとバージョンによって異なるんですけど、
EBPFのプログラムって結構厳格にいろんな制限がありまして、
その一つにもともとはループができない、
フォーグンが書けないみたいなことがありました。
新しい目のKernelの5.3以降では制限付きのループが許可されたりとかして、
ちょっと緩和はされているんですけれども、
ループがないこととか、
実行されないコードがないことっていうのを確認したりとか、
プログラムの実行をシミュレートして、
そのレジスタ、EBPFのレジスタの状態とかを追跡して、
メモリ、境界外のメモリアクセスの防止とかをしたりだったり、
あとEBPFのプログラムでは、
Kernelによって明示的に許可されたメモリ領域にのみアクセスできるようになっていて、
任意のKernelメモリまたはユーザーメモリのアクセスが固く禁止されていると。
もう本当許可されたメモリにしかアクセスできないので、
今回クラウドストライクのKernelドライバーって
アクセスしてない、知ってはいけないところにアクセスしてブルースクリーンになったと思うので、
そういったことがそもそもできちゃうようなプログラムだったら実行できないっていうような、
そういったベリファイアっていうものがあるので、
安全になるのではないかというふうに言及されていると、
僕は理解しております。
ken
なるほどね。だからこのクラウドストライクのポストインシデントレビューを見る限り、
マルフォームの設定ファイルが結局はアウトオブバウンドメモリアクセスにつながってしまったということなんですけど、
そこがEBPFのバリファイアによって、
eBPFとバリファイアの役割
ken
その設定ファイルが実行された結果、
例えば配列のアクセスしてはいけないところにアクセスしようとしているよということで、
バリファイアからエラーが測れて、
その実行自体が止められるっていうことなのかなと。
そうです。
これユーザーアプリケーションから見るとバリファイアがこけるとどういうふうになるかってわかりますか?
ユーザーアプリケーション側でハンドルできるEBPF的なエキセプションとかが投げられる感じになるんですか?
Keisuke
僕の趣味でEBPFの使ったプログラムを書いた経験から言うと、
そのベリファイアがベリファイできない、
なんて訴訟できないプログラムっていうのはそもそも実行できなくて、
なので実行できませんよみたいなエラーが返ってきましたね。
でもプログラムがそもそも動かないというか。
Takumasa Sakao
うんうん。
ロード時点でベリファイしてくれるみたいなイメージであってますか?
Keisuke
そうですね。
ken
なるほどね。
これちょっとわかんないんですけど、
Windowsも多分基本ユーザーランドとかネルランドみたいに分かれているとは思うんだけど、
そのEBPFの普及状況っていうのはどうなんですか?
基本的にLinux、Kernelで本体として開発されているものじゃないですか。
Windows側でもそれをポートしようとか、
同じものを再実装しようみたいな動きがあるんですかね。
Keisuke
僕も今回のポッドキャストがあるのでちょっと調べたら、
MicrosoftのGitHubのオーガニゼーションにEBPF for Windowsっていうレポジトリがあって、
どうやらそこで開発してそうですと。
ken
ほんとだ。
Keisuke
一応そのReadMeに書かれているので、
一応Linux向けに書かれたソフトコードがWindowsでも使えるように、
互換性を提供するような意思があることは書かれていて、
ただLinuxとWindowsでこういう機能があるので、
100%の互換性っていうのはまた提供はしてくれないと思うんですけれど、
できる限りLinux向けに書いたソースコードも、
そのままWindows向けのEBPFでも使えるような世界を実現しようとしてくれているのかなとは、
ちょっと推測しています。
ken
なるほど。
これMicrosoft側めっちゃ大変じゃないですか。
だって基本的にはEBPFってLinux側が欲しくて、
自分たちのために作って、それが広く使われてユーザーも欲しくなったので、
Microsoft側が後追いでLinuxのAPIに合わせて作っているってことですよね。
だから多分パワーバランス的にはLinux側にあるんじゃないかなというか。
Keisuke
そうですよね。
あとMicrosoftって今回の事件で知ったんですけど、
Windows DefenderっていうMicrosoftが提供しているような、
クラウドストライクの代替製品になるようなものがあるみたいなんですけど、
それはEUと揉めて、
Microsoftのサードパーティーにそういう関連ドライブをかけるようにしなさいみたいになって、
結果的にクラウドストライクが広まっているみたいなことがあるという風に見ました。
Microsoft的には本当はWindows Defender使ってくれよって思っているのかもしれないです。
ken
まあそうですよね。
これあれですよね、多分EUってよくモノポリというか、
独占、企業が独占しようとした時に例えば買収を阻止したりとか、
医薬金払わせたりとかよくテックニュースにおにぎわせたりしますけど、
多分その一環ですよね。
MicrosoftがOSの中で全部閉じてWindows Defenderみたいな使わざるを得ない状況を作るんじゃなくて、
Windowsのセキュリティの対抗馬をサードパーティーでもユーザーが使えるようにしろよと、
独占するなよっていう風にEUから言われたっていうことですよね、多分ね。
Keisuke
そうですよね。
似たような話をAppleのApp Storeとかでも聞いたりとかしますけど、
そうですよね、はい。
ken
なるほど。
Takumasa Sakao
なかなかEBPF for Windowsのプロジェクト大変そうという匂いしかしないですけど。
大変そうですよね、これ。
っていうか初めてEBPF対応してるんだっていうの、これで初めて知りましたね、
ken
Windows向けに対応するんだっていうのは。
なんかダイアグラム見る感じ本当に似せてこようとしてるのかな、
バリファイヤーみたいなのもいて、
Keisuke
カーネルランドユーザーモードの受け渡しはメッセージパッシングみたいな感じにして。
ken
なるほどね。
だから理論上防げるってことですね。
なんか聞く感じ、僕の印象ですけどバリファイヤーやること多いなと思ったんですけど、
デメリットみたいなのあるんですかね。
Windows向けeBPFの挑戦
ken
なんていうんですか、多分。
Keisuke
ルートオフになってる部分だとは思うんですけど、
やっぱりさっきちょっと話した、
制限付きのルートが許可されてるとか、
そもそもなんか、
eBPFのプログラムで書ける、
eBPFのプログラムをコンパイルすると、
eBPFのインストラクションセットにコンパイルされるんですけど、
確かそのインストラクションセットの上限っていうのを決まっていて、
1万とかだったかな。
もともと4096とかだったと思うんですけど、
それが1万ぐらいまでに増えたりとかするんですけど、
だいたい命令数に制限があるんで、
大きなプログラムって書けないと思うんですね。
あとループが、制限付きループが許可されたりしてるものの、
制限はついてるので、
セキュリティーとか安全性を担保するのと、
ken
自由度って結構トレードオフの関係あると思う。
そうですね。
徐々に緩和する方向に向かってそうな気がしますけど。
でもね、無限に緩和できるものでもないだろうし、時間はかかるだろうし、
かといって今のすべてのコードをすぐeBPFプログラムにポートできるかというと、
それも無理だろうし、現実的に無理だろうし。
Takumasa Sakao
実行時にもやっぱりオーバーヘッドはあるわけです。
フックされて、例えば1万行のインストラクションが走っても困るし、
みたいなケースも全然ありそうですよね。
ken
ですよね。
Keisuke
ブレンダン・グレックっていうeBPF界でかなり貢献をしているエンジニアが、
どうもはブルーフライですっていうブログをクラウドストライクの事件があった後に出していて、
そこでもeBPFは確かにリソースを必要以上に使うっていうところを言及しているので、
そこは確かにeBPFを使うデメリットになり得るかなとは思いますね。
ken
そっか。
普通にeBPFに必要なインストラクションセットとかメッセージパッシングに必要なマップとかメモリは食うし、
バリファイヤーとかやり取りするのに追加でCPUサイクルも食うし。
それ実際やってみるとどれくらいのアディショナルのコストがあるのかっていうのは、
多分eBPFプログラム主体ですけど、
よくある銀の弾丸じゃないよっていう話ですね。
そっか、ブレンダー・グレッグ。
彼は今インテルでしたっけ?
Keisuke
そうだと思います。
ken
ネットフリックスの後、インテルのだいぶ上の方でプリンシパル化なんかで入ったんですよね。
もっと何だっけな。
Keisuke
なるほど。
調べてて一個面白いなと思った、今eBPFの弱点というか、
弱点?
弱点、僕が見つけたブログでは、
eBPFのベリファイヤーっていうのはもうカーネルのソースコードに完全に三つ結合っていうか、
一緒になって動かされるので、
テストとかがすごく難しいみたいなことを指摘しているブログがあって、
そのベリファイヤーだけを切り出して、
そこに対してプログラムがセーフかアンセーフかチェックしてくれるような、
ベリファイだけ切り出したものとかがあったら便利なんじゃないかみたいな、
今の状態だとLinuxカーネル丸ごと用意して、
例えばVMとかどっかでバージョンごとにインスタンスを立ち上げて、
そこでプログラムを実行してテストとかしなければならないと思うんですけれど、
それって結構パワーっていうか資金力のある会社とか、
個人では結構難しいと思うんですよね。
いろんなマシン使わないといけないし、
なんでベリファイヤーだけ切り出すみたいな個人プロジェクトなのかな、
推している人のブログを見つけて面白いなと思って読んでました。
ken
なるほど。だからバリファイヤーのエミュレート、
もうちょっとインタグレーションテストみたいな感じで、
LinuxのVMを準備してテストするよりはライトに走らせたいと。
だからユニットテストのほうがもうちょっとライトなテストを書いたときに、
バリファイヤーの挙動をエミュレートしてくれるMockか、
エミュレートしてくれるようなもっとライトなプロセスが欲しいってことですかね。
Keisuke
そうだと思います。
ken
なるほどね。難しくないですか、それ。
バリファイヤーのやることが多いのであれば、
それをバリファイヤーの進化に沿って書いていかなきゃいけないし。
Keisuke
そうですよね。多分メインのEBPFの開発者たち、
コアな開発者たちがその辺本気で考えないと、
ちょっと外の人が追従していくのには無理があるかなと思います。
実際そのブログでは書かれてなかった。
Takumasa Sakao
TOC、プルフォーブコンセプトで終わってたんで、
Keisuke
多分継続してるっていうようなふうには思ってないですかね。
GitHubのデポジトリも見たんですけど、アーカイブになってましたし。
Takumasa Sakao
アプローチとしてはどんな感じなんですか。
テスト環境の課題
Takumasa Sakao
リラックスカーネルのベリファイヤーのソースコードを引っ張ってきてとか、
そっちのアプローチなんかなって勝手に思ったんですけども、
フルスクラッチで実装みたいな感じだったんですか。
Keisuke
アプローチまでしっかりは見てなかったんですけど、
ちょっともうさらっとブログを読んだぐらいで、
デポまでしっかりは見てないのでちょっと答えられないですけど。
Takumasa Sakao
すいません。
ken
フルスクラッチだときついですよね。
テストする側のユーザー目線になったときに、
結局そういうものが提供されたとしても、
Takumasa Sakao
最終的にはやっぱり本物のVMでテストしたいってなるんじゃないかな。
そうですよね。結局そのコンパティビリティというか、
ken
どこまで正確かっていうのがめちゃくちゃ重要だと思うんで。
それだったらEBPFプログラムテスト用の環境をサークルCIみたいな
テスト環境が実行してくれるとかのコストで、
そこでコストデメリットを抑えるというかにした方がいいような気もするが、
ちょっと分かんないですね。
Takumasa Sakao
ベリファイアっていうのはちなみに、
1回走らせたらいいっていう感じなんですよね。
プログラムの更新ごとに1回走らせればいいみたいな状態っていう認識であってます?
Keisuke
そうですね。EBPFのプログラムの変更のたびに実行されるイメージですね。
EBPF技術の活用
Takumasa Sakao
ありがとうございます。
だからある種コンパイルしてそいつに通すだけだから、
そうですよね。
それこそCIとかでVM立ち上げてそこに飲ませれば終わりですもんね。
ken
ちなみにEBPF技術一般に関してなんですけど、
坂尾さんはクーバネティスの業界で結構いろいろツールも作ったりとか
カンファレンスとかも出たりしてますけど、
クーバネティスの開発者というか、
界隈にいた身としてはEBPFに関してどれくらいよく聞くものなのかとか、
そういったツールを使ったことがあったりとか、
そういったのってどうですかね。
Takumasa Sakao
そうですね。うちでも一部使ってるところはありますし、
クーバネティスのキューブコンとかでも話題としてはよく見ますよね。
EBPFのサブカンファレンスみたいな形で、
ワンデイイベントとかで話されたりしてるんですけど、
シリウムとかよく出てきますよね、名前としては。
CNIですよね。
EBPFで実装されてるCNIのシリウムとかはよく聞きますね。
あとその周辺のモニタリングツールみたいなのがいっぱいあって、
このモニタリングツールがいけてて、
こういうネットワークのモニタリングができるんだよ、でもシリウムだけどね、みたいな。
そういう話をよく聞きますね。
ken
実際に今回のクラウドストライクみたいなのが起こしたようなことを
EBPFできるんじゃないかなという上で、
すでにEBPFをレバレッジしたセキュリティベンダーはあるのかなっていうのを
今回僕も気になっていくつか調べてみたんですけど、
ありそうだなっていうのは僕の印象で、
Wizの紹介
ken
いくつか紹介してみたいんですけど、
まず一番結構真面目に調べたのが、
Wizっていうイスラエル初のセキュリティベンダーですね。
Wizって聞いたことありますか?お二人は。
Takumasa Sakao
ないです。
ken
僕もなかったんですけど、
最近Googleの買収騒ぎがあったんですよ。
Wizを買うかどうかみたいな。
その額がですね、結構大きかったんですよね。
いくらだっけかな。
日本円で3兆いってるんですよ。
200億ドル超えでの買収を検討して、
たぶん確かもうやめたんですけど、
Google買えないってなったんですけど、
Googleが3兆、4兆円で買おうとしている
イスラエル初のサイバーセキュリティ会社。
結構浅いんですよ、これ。
2020年に設立されている会社なので、
だから4年前ですよね。
たった4年のスタートアップが
Googleに3兆円超えで買われようとしている
謎のセキュリティベンダーがあるみたいな。
界隈では多分有名だったと思うんですけど、
僕は今回初めて知って。
Wizっていう会社がありますと。
そのWizっていう会社が何かというと、
マルチクラウド環境とかにおいて、
例えばいろんなプロセスが勝手に仕込まれたとか、
会社が新しいセットを入れたりとか、
OSのミスコンフィグレーションみたいな、
いろんなところで普通にハッキングされたりとか、
セキュリティリスクってあると思うんですけど、
Wizを入れるところで、
どこでセキュリティリスクにつながるような、
例えばマルウェアが走っていたりとか、
OSの設定ミスがあったりとか、
っていうのを検知して、
そこに自動で対応してくれる。
クラウド環境における統合セキュリティプラットフォームだと
理解しています。
例えば、いろんなVMとか動いているのを、
セキュリティグラフという形で、
ツリー上というかグラフ上で表現して、
例えばここのプロセスに、
今ちょっと既存のセキュリティバグが仕込まれてますよ、
みたいなのを通知してくれたりとか、
それに対してキルしたりとかっていうのをしてくれる。
そのうちの一つの、
それを支えるコンポーネントの一つに、
ランタイムセンサーっていう、
WiZランタイムセンサーっていうのがあるんですけど、
これがどうやら公式ホームページに書いてある通り読むんですけど、
Lightweight eBPF Based Agentということで、
それはこのランタイムセンサーをLinuxホストとか、
Kubernetesのクラスターにデプロイすると、
そうするとそのエージェントが、
そこで起こっている通信とか、
あとはプロセスのやり取りとかを監視して、
WiZ側に、WiZのリサーチチームが認識している、
直近の例えば脆弱性についたようなアタックであったりとか、
そういったものに対して検知したら、
吉田に対応してくれるっていうツールを、
既に提供しているっていうのがあってですね。
例えばこれをレバレッジすれば、
例えばアウトオブバウンドメモリアクセスであったりとか、
そこら辺もいい感じにやってくれるんじゃないかな、
という僕の勝手な印象で、
結構WiZっていうのがあるんだなっていうのは、
ちょっと個人的に気になり始めた感じですね。
なんかそのユースケースとしても、
いくつか紹介されてたんですけど、
Pyroosっていう、
これはPythonスクリプトを仕込んで、
Linuxに提供されているメモFD、
メモリファイルディスクリプターを悪用して、
本当は読むべきでない、読めないメモリを読んでしまう。
そこにマルフォームスクリプトを埋め込んでしまう、
みたいな脆弱性もあったりするんですけど、
そういったものもランタイムセンサーを使うと防げますよ、
みたいなマーケティングもしていて。
個人的にはGoogleの買収事件があったっていうものが、
だいぶバイアスかかってるんですけど、
なかなかイケてるプロダクトなんじゃないかなと思って、
ちょっとウォッチしていきたいなと思ってる感じですね。
アクアセキュリティのツール
ken
なんか出てきそうですよね、こういうのいろいろね。
Takumasa Sakao
なんかそうですね、
EBPFって印象として結構作るの大変じゃないですか、
すごいローレベルのところからハイレベルの情報を
取ってこないといけないから、
そうですね、
頑張ってんなっていう気持ちになりました。
ken
WiZなんか結構面白くて、
イスラエル発のスタートアップって言ったんですけど、
この立ち上げの人が3、4人かな、いるんですけど、
彼らはどこで知り合ったかというと、
イスラエルの国防軍で知り合ったらしいんですよ。
イスラエルの軍の情報部隊で知り合った人たちが、
なんかそれを辞めて、
なんかそのサイバーセキュリティスタートアップを作ったっていう、
なんかストーリーが面白そうな会社で、
結構ね、使ってる会社も多いんですよね。
そのスラックとか、あとはいわゆるそのフォーブス500だっけ、
大きい会社が使ってますよ、みたいなのは献殿しているし。
Takumasa Sakao
なんかイスラエルって結構やっぱセキュリティが厚いんですねっていうのを、
あんまり知らなかったんですけど、
確かそのアクアセキュリティとかもそうですもんね、
イスラエルだったと思う。
ken
そうなのか、確かに。
アクアセキュリティは、
また別のEBPFとかでもよくマーケティングしてたりする会社ですよね。
リズトラスの前の会社ですよね、確か。
リズっていうのは、
EBPF関連のカンファレンスによく出てくる、
エヴァンジリスト的な人がいるんですけど。
Keisuke
そうですね。
入門EBPFって最近じゃないか、
日本語訳出たあれの英語原作書いた人ですよね。
ken
うんうん。
なるほどね。
やっぱセキュリティが厚いんですね、イスラエル。
どうですか、他に名前だけでも気になっているセキュリティベンダー結構あったりしますか?
Keisuke
セキュリティベンダー。
さっき出たアクアセキュリティで言うと、
EBPFのことを勉強するときに、
アクアセキュリティが出してトレーシーっていうOSSがあるんですけど、
ken
どんなやつですか?
Keisuke
試しに使って遊んでみたことがあって、
それはEBPFで、
プロセスがコールしてるシステムコールとか、
そういうのを全部拾ってくれるっていうか、
プロセスはどんなシステムコールを呼び出してるっていうのを出してくれたりするものがあって、
似たようなもともとあるコマンドラインのツールで、
ストレースってあると思うんですけど、
あれと似たような使い勝手でしたね。
ただコンテナにも対応していて、
コンテナで動かして、コンテナアプリケーションが実行しているシステムコールとか、
みたいな指定ができたり、
ストレースにもっといろんな機能があるけど、
使ってみた感じに似てるなっていう印象でした。
ken
なるほど。
これシスコールのリストが取れて、
そこからセキュリティ検知ってどうやってつなげるんですかね。
これは多分スタンダードローのシスコール一覧が取れるみたいなツールだと思うんですけど、
膨大な量になりそう。
Keisuke
実際にどうやって活かしてるのかまではちょっと分かってない。
ken
他のデータとくっつけない。
すごいって、面白いってなっただけなんで。
Takumasa Sakao
そうですね。
アクアセキュリティで言うと、
トリビーとかコンテナの脆弱性のツールとか有名ですよね。
よく使われてる印象がある。
それはカタクト名ですか。
そうですね。トリビーっていうのがあって、
コンテナの脆弱性を診断してくれるやつなんですけど。
ken
使い勝手としてはどういうふうに使うんですか。
コンテナにプロセスを入れて自動で検知してくれる感じ?
Takumasa Sakao
そうですね。
イメージファイルを指定して実行されたみたいな印象でしたね。
ken
なるほどなるほど。
Keisuke
イメージに古い依存、
コンテナ内に入ってる古いコマンドラインとか、
脆弱性が報告されてるようなものとか、
Takumasa Sakao
そういうのを検知できるイメージでした。
作者が日本人なんですよね。
そうなんですか。
知り合いの知り合いなんですよね。
知り合いの知り合いで。
アクアセキュリティで働かれてる方ってことですか。
買収されたんですよね。
日本人がOSSで作ってアクアセキュリティに買収されたっていうすごいサクセスストーリーなんですよ。
ken
すごい。めっちゃサクセスストーリー。知らなかったです。
Keisuke
この人のブログ読んで僕も感動した覚えがありました。
すげーと思って。
ken
熱いっすねそれ。
Takumasa Sakao
熱い。
ken
それはEBPF関係ないですか。
Takumasa Sakao
これはEBPFは関係ない印象でしたね。
ken
あくまで性的に脆弱性を判断するんだろうと思ってたんで。
すごいな。なるほどね。
だからEBPFを使っていろいろツールを作れるが、
それをレバレッジしてどうセキュリティ監視につなげていくかっていうのはまた別の話なので。
なかなか難しいですね。
GVisorとサンドボックス化の重要性
Keisuke
あと全然EBPFとは関係ないんですけれど、
コンテナのランタイムでGVisorっていうのがGoogleが作ってるやつなんですけど、
これとかは結構任意のプログラムを実行することになると思うんですよ。
コンテナでアプリケーションを走らせると。
もちろんコンテナのアプリケーションに悪意のあるものがあったら何でもできちゃって、
例えばホストの源源とか掌握されちゃう可能性とかすらあるわけで、
できるだけサンドボックス化したいと思うんですね。
コンテナで実行されるアプリケーションにはあまり余計なことしてほしくないから、
ホストと隔離したいと思うんですけど。
それのアプローチの一つでGVisorはアプリケーション、
そのコンテナで動いてるアプリケーションのシステムコールをインターセプトして、
GVisorが代わりにホストカーネルと通信したりするみたいなコンテナランタイムがあるというふうに最近調べて知りまして、
面白いなと思いました。
ken
それはユーザーランドで動くいわゆるプロ機種みたいなアプリケーションってことですかね。
Keisuke
プロ機種っていうか、アプリケーションからするとシステムコールを実行してるようにしか見えないんですが、
実はGVisorが全部インターセプトしてるみたいな。
ken
GVisor側ではアプリケーションがどういうシスコールを発行してるのか全部わかるので、
そこでサンドボックス環境を作るだから、例えば危険な操作をしようと思ったりしたものは落とすってことなのかな。
Keisuke
そうだと思います。
ken
あと、実行してほしくないシスコールは拒否したりとかできるんじゃないんでしょうか。
なるほど。
Takumasa Sakao
GAEとかはこれ使ってたりとかしてた記憶がありますね。
Google App Engineですね。
ken
GKEとかも最近使えるのかな。
そっか。
ユーザーに広くアプリケーションランタイムを提供するような会社からすると、
ユーザーに悪意のあるコードとか、ブレナビリティのあるコードを実行してほしくないので、
GVisorをベースで提供することでメリットがあるということですね。
なるほど。
面白いですね。
多分シスコールを直接実行させる前に、
EBPFバリファイヤーなりGVisorなりが絡んで、
そこで色々検知するっていう仕組みとしては多分同じなんだけど、
GVisorの方がEBPF本体に実装されているバリファイヤーがバリファイできるもの以外にも、
例えばアプリケーションレイヤーでもっと任意の、
自分たちがやりたいようなバリファイの仕組みを実行できたりとかいうメリットがあるのかなと聞いてて思いました。
例えばEBPFバリファイヤーの機能を増やそうと思ったら、
多分LinuxをフォークするかAppStreamに貢献するしかないと思うんですけど、
GVisorは多分自分たちで作れるサンドボックス環境なので、
そういうメリットがあるのかな、多分。
eBPFのセキュリティ機能と利点
Keisuke
そうですね。
ken
なるほど。
これはこれで全部インターセプトするので、
パフォーマンスに対する懸念はありそうかなと思いました。
実際どうなんだろう?
Keisuke
それはセキュリティを担保しようと思ったらどうがないのかなって思ってます。
ken
確かに。
Keisuke
何層も多層防御でしたっけ?
言葉があると思うんですけど、
ディフェンスインデックスって多分それって何層もレイヤーを重ねて、
できる限り攻撃が通れないようにしようっていうアプローチだと思うんで、
そうすると絶対オーバーヘッドがあるはずなので。
ken
なるほどね。
Takumasa Sakao
今のGVisor聞いて、やっぱWasmとかも思い出しますよね。
ken
同じような感じですね。
Takumasa Sakao
確かに。
WasmはWASGっていうシステムインターフェースがあって、
それ経由でシステムコールとかを呼べるようになるみたいな感じなんで、
アプリケーション用にサンドボックスを用意するっていう意味合いでは、
GVisorと近い思想かもしれないですね。
ken
確かに。
Wasmもセキュリティのコンテキストで語れますもんね。
いわゆるサンドボックス環境の提供みたいな。
セキュリティトレンドの思索
Takumasa Sakao
そうですね。
ken
なるほど。
そこでWasmが絡んでくる。
Wasmといえば坂尾さんのWasm記事でしたね。
Takumasa Sakao
それ多すぎる。
全然詳しくない。
ken
何でしたっけ。
レイヤーで防御をするレイヤードディフェンス。
何でしたっけキーワードも。
Keisuke
ディフェンスインデプス。
ken
ディフェンスインデプスか。
なるほど。
それ初めて知りました。
知らなかったです。
ありがとうございます。
面白い。
深いなセキュリティ。
やっぱりSREとしては知っておかなきゃいけない分野なので
キャッチアップしたいなと思ってたんですけど
時事ネタを通じてEBPFをちょっと覗き見した感じで
最近のセキュリティのトレンドというのを
セキュリティベンダーを調査したりしつつ
個人的にはいろいろキャッチアップできた
いい機会だったなと思います。
ありがとうございます。
そろそろクロージングしていこうと思うんですけど
じゃあお二人から簡単に最後
何か言い残したことがあれば言ってもらって
なければ感想もしくは何か宣伝したいことがあれば
してもらおうかなと思うんですけれども
じゃあけいすけさんからお願いしていいですか。
Keisuke
今回セキュリティとか文脈で
EBPFってなんで安全なんだっけみたいなところとか調べて
ken
自分の勉強にもなっていい機会ありましたし
Keisuke
他のセキュリティベンダーのアプローチとかも見て
セキュリティはなんか最近何でしょう
業界的に盛り上がっている分野なのかなという風に
なんとなく面白いなと思いました。
ken
ありがとうございます。
坂尾さんもお願いしていいですか。
Takumasa Sakao
感想と宣伝を一つずつ
感想としてはけんさんとけいすけさんの
調べてくださったこととか
すごい勉強になって面白かったですね。
やっぱこのEBPFってちょっと前から知ってる部分も
もちろんあったんですけど
こういう実際の事例聞けて面白かったなっていう風に思いました。
宣伝としては完全に関係ない話なんですけど
今僕が作ってるBDっていうOSSがあるんですけど
それを今もともとGoで書いてたんですけど
完全にラストでフルスクラッチで書き直して
V1.0をリリースしようとしているので
これが公開される頃にはリリースされてるかな
ちょっと今実際作業中なんですけど
それをよければ使ってください。よろしくお願いします。
めっちゃいいですね。ラスト再実装。楽しそう。
ken
楽しかった。完全に楽しい駆動でしかやってないです。
ラストの勉強しようと思って始めた感じですか?
Takumasa Sakao
そうですね。ラストをずっと勉強してて
3,4年間ぐらい全然わからんと思いながら勉強して
ようやくちょっとわかるようになってきたんで
ken
書き始めた感じですね。
それも別ブランチとして開発して
バージョン上げた時にラスト実装にボンと切り替える感じですか?
それとも別のラスト実装として追加で提供する?
Takumasa Sakao
もう完全にGoのコードは消し去る予定ですね。
そういうアナウンスメントも一応出してて
同じデポジトリにバンと上げるという感じにしようとしてます。
ken
熱いプルリクが舞いされる日が来るんですね。
Takumasa Sakao
そうですね。プラス5000行とかぐらいなんですけど。
ken
楽しそう。めっちゃいいですね。
ありがとうございます。
Takumasa Sakao
収録ノートに公開されたリンク送ってください。
ken
ありがとうございます。
本日はけいすけさんとさかわさんをお呼びして
クラウドストライクのブルースクリーソードからの
EBPFとセキュリティの話題について話していきました。
ありがとうございました。
