D03 - ネットワークセグメンテーションとファイアウォール
昔の世界ではインフラストラクチャやネットワークチームにより管理されるセキュアな DMZ (非武装地帯) があり、フロントエンドサーバーのサービスだけがインターネットから到達可能であることを確保していました。そして一方では、このサーバーはミドルウェアやバックエンドとセキュアに通信でき、他とは何もできませんでした。シリアルコンソールやベースバンド管理コントローラからの管理インタフェースは厳密なアクセス制御を備えた専用の管理 LAN に配置されていました。
これは基本的にネットワークエンジニアがネットワークセグメンテーションやファイアウォールと呼んでいるものです。マイクロサービスのネットワークを計画する際には、基本的にはこのような考え方になるはずです。
脅威シナリオ
コンテナの世界ではネットワークも変わります。予防措置がなければ、コンテナがデプロイされているネットワークは厳密なファイアウォール/ルーティングルールで必ずしもセグメントに分割されているとは限りません。最悪の場合それはフラットでさえあり、どのマイクロサービスも基本的に管理バックプレーン (オーケストレーションツールやたとえばホストのサービスなど) を含む他のすべてのマイクロサービスと通信できます。
コンテナごとに一つのマイクロサービスを持つパラダイムはネットワークセキュリティの観点からは容易ではありません。一部のマイクロサービスは相互に通信する必要がありますが、セキュリティの観点からはそうすべきではありません。
最大の問題はオーケストレーションツールのインタフェースをインターネットに公開することです。それについての研究 [1] といくつかの驚くべき発見 [2] がありました。ログインで保護されている場合でも、攻撃者が環境全体を制御できるようになる一つのステップにすぎないことに注意してください。
脅威:
インターネットに公開されたオーケストレーションツールのフロントエンド/API 1)
LAN/DMZ に公開されたオーケストレーションツールのフロントエンド/API 1)
マイクロサービスからホストのサービスへのアクセス
LAN/DMZ に不必要に公開された同じアプリケーション (トークン) の LAN のマイクロサービス
LAN/DMZ に不必要に公開された従来のサービス (NFS/Samba, CI/CD アプライアンス, DB)
同じネットワークを共有することによるテナント間での 100% ネットワーク分離不可
最初のシナリオを除いて、脅威は攻撃者がローカルネットワーク (LAN/DMZ) にアクセスすることです。たとえば、危殆化したフロントエンドサービス (インターネット) を介して、このネットワーク内を移動します。
どうすれば防ぐことができるのか？
要約すると、昔の世界のように多層ネットワーク防御を持ち、ホワイトリストベースの通信のみを許可します。必要なポートのみをネットワークに公開します。これには特に管理サービスとホストサービスが含まれます。
事前に適切なネットワーク計画を立てます。
環境に適したネットワークドライバを選択する
DMZ を適切にセグメント化する
複数のテナントが同じネットワークを共有しない
必要な通信を定義する
管理フロントエンド/API を保護する。それらをインターネットに公開しない。どうしても必要な場合には、必要な信頼できる IP のみを許可する。
DMZ でもそれらを公開しない。これは管理バックプレーンである。厳密なホワイトリストベースのネットワーク保護が必要である。
同じ方法でホストサービスを保護する
オーケストレートされた環境では以下のことを確認する
最初に適切な着信ネットワークとルーティングポリシー
次に適切な発信ネットワークポリシー (インターネットからのダウンロードを可能な限り制限する)
それからどのコンテナの相互通信が必要であり脅威をもたらす可能性があるかを決定する
どうすれば見つけ出せるのか？
まず、オーケストレーションツールの管理インタフェースのいずれかがインターネットに公開されているかどうかを確認する必要があります。ランダムなインターネット IP から自分自身をスキャン [3] して、これが当てはまらないことを確認します。環境が揮発性である場合は、外部から定期的にスキャンを実行して何も起こらないことを確認することも悪くありません。また、少なくともそれが発生した場合には、通知を受け取り、アクションを実行できます。
次に、これを攻撃者の視点から見る必要があります。もしコンテナを完全に制御できるようになった場合、攻撃者は何ができますか？攻撃者がコンテナから a) オーケストレーション管理インタフェース b) 価値があるほかの何か (たとえば LAN 内のファイルサーバーや攻撃者が "話す" 必要のない他のコンテナなど) に到達できないことを確認します。貧者の解決策はコンテナに侵入し netcat/nc を使用してチェックすることです。もう一つのオプションは nmap を含む docker コンテナを手動で作成することです。
前提としてネットワークを理解する必要があります。最近のオーケストレーション環境でネットワークを自分で構築していない場合、それは容易ではないかもしれません。これをセットアップした人に尋ねるか、自ら把握する必要があります。簡潔な方法はありません。最初にホストからの外部および内部ネットワークインタフェースが何であり、どこにあるかを理解する必要があります。 ip a / tp ro があなたの友達です。同様のことをコンテナに対しても行うことができます。コンテナ内でそれらのコマンドを実行するか、ホストから for n in $(docker network ls --format="{{.ID}}"); do docker inspect $n; done などでリストします。
おそらくさまざまなネットワークからスキャンしたいかもしれません。最初の選択肢はホストと同じ LAN からです。ホスト上でコンテナをターゲットとするのは良いアイデアかもしれません (例 nmap -sTV -p1-65535 $(docker inspect $(docker ps -q) --format '{{.NetworkSettings.IPAddress}}') ) 。同じことをコンテナから繰り返して、攻撃者の手の届く範囲を確認することもよいかもしれません。
参考情報
[3] ネットワークのスキャンと検出のためのツールは nmap です。
コマーシャル
[2] RedLock: Lessons from the Cryptojacking Attack at Tesla, Arstechnica: Tesla cloud resources are hacked to run cryptocurrency-mining malware.
1) それは資格情報を必要とするものでも必要としないものでもかまいません。両者の例: etcd, dashboards, kubelet, ...
Last updated