リソース枯渇攻撃
コンテナと仮想マシンは両方の仮想化テクノロジーであるため、類似点と大きな違いがあります。リソース制限に関しては、VMware、Virtual Box、QEMU のいずれを使用する場合でも、作成する仮想マシンの CPU、メモリ、およびハードディスクのリソースしきい値を明確に設定する必要があります。仮想マシンの内部プロセスの観点から見ると、仮想マシンは実際には独立したコンピューター内に存在しますが、デフォルトでは、コンテナー ランタイムはポッドに基づいて、コンテナーの内部プロセスのリソース使用量に制限を課しません。ユニットのコンテナ オーケストレーション管理システムも、デフォルトではユーザーが作成した Pod に CPU とメモリの使用制限を課しません。
制約がないため、クラウドネイティブ環境はリソース枯渇攻撃のリスクにさらされます。攻撃者は、コンテナ内でサービス拒否攻撃を開始して大量のホスト リソースを占有し、その結果、ホスト自体またはホスト上の他のコンテナの通常の動作に影響を与える可能性があります。ここで話しているのは、デフォルト構成ではリソース制限がないことです。これにより、コンテナーの分離がある程度失敗します (コンテナー外のシステムまたはサービスの通常の動作に影響します)。コンテナ自体に対するサービス拒否攻撃。
一般的な脆弱なリソースは次のとおりです。
1) コンピューティングリソース: CPU、メモリなど
2) ストレージリソース: ローカルハードディスクなど
3) ソフトウェアリソース: カーネルによって維持されるデータ構造など
4) 通信リソース: ネットワーク帯域幅など
CPUリソースが枯渇した
CPU リソースの大量消費がコンピューターの通常の動作に影響を与えることは間違いありません。制限がない場合、コンテナーはホスト マシン上のほぼすべてのコンピューティング能力を使用できます。
次に、ストレス テスト ツール Stress を使用してテストし、htop ツールを使用してホストの CPU の使用状況を監視しましょう。
まず、ホスト上で htop 監視を有効にし、ホスト上でコンテナを実行し、コンテナが uname -a コマンドを実行するのにかかる時間を測定すると、コマンドの実行から終了までの時間が約0.81秒
time docker run -it --rm ubuntu uname -a
ここで、大量の CPU コンピューティング能力を消費するシナリオをシミュレートし、次のコマンドを実行してストレス テスト ツール ストレスの Docker イメージを取得します。
docker pull joedval/stress
「joedval/stress」イメージに基づいてコンテナをランダムに生成し、ウェイト レベルを 512 に設定し、ストレス テストを実行します。
time docker run -it --rm -c 512 joedval/stress --cpu 1
htop を使用して、この時点でホスト マシンの CPU コアの使用率が 100% であり、費やした時間が 31 秒に達していることを表示します。
制限がなければ、悪意のあるコンテナは CPU の計算能力を使い果たし、ホストや他のコンテナの通常の動作に影響を与える可能性があることがわかります。
メモリリソースが枯渇した
メモリ枯渇のパフォーマンスも非常に明白です: アプリケーションの対話の適時性が低下し、サービスの応答時間が延長される可能性があります。制限がない場合、コンテナはホスト マシン上のほぼすべてのメモリを占有する可能性があります。
次に、ストレス テスト ツール Stress を使用してテストし、htop ツールを使用してホスト マシンのメモリ使用量を確認しましょう。
まず、ホスト上で htop モニタリングを開き、ホスト上でコンテナを実行し、コンテナの作成と uname -a コマンドの実行にかかる時間を測定すると、実行から約 0.91 秒かかっていることがわかります。コマンドは最後まで
ここで、リソース枯渇のシナリオをシミュレートし、ストレス ツールを使用して、初めて作成されたコンテナーに大量のストレージ スペースを適用し、次のコマンドを実行します。
stress --vm-bytes 800m --vm-keep -m 3
htop を見ると、この時点でホスト上のメモリ使用量が約 1.77G に近づいていることがわかりますが、この時点でコンテナの作成と uname -a コマンドの実行に必要な時間が 4.28S に変化していることがわかります。
制限がなければ、コンテナーはメモリの枯渇を通じてホストや他のコンテナーの操作に影響を与える可能性があることがわかります。
プロセステーブルが枯渇した
実際、オペレーティング システムはハードウェア リソース以外にも多くのソフトウェア リソースを提供しており、プロセス テーブルもその 1 つであり、古典的なプロセス テーブル枯渇のケース (フォーク爆弾) を使用して、このようなソフトウェア リソースが引き起こす無限の可能性を分析します。問題。オペレーティング システムのすべての動作はプロセスとして実行されます。これらのプロセスを管理するために、オペレーティング システム カーネルはプロセス テーブルを維持します。テーブルのスペースには限りがあります。テーブルが飽和すると、テーブル内のプロセスが終了しない限り、システムは新しいプログラムを実行できなくなります。
名前が示すように、フォーク ボムは、フォーク システム コールを使用して新しいプロセスを継続的に作成し、プロセス テーブルを飽和させ、最終的にシステムが正常に実行できなくなることです。最も古典的なバージョンは bash バージョンです。
: () {
: | : & } ; :
上記のコードの原理は、無限再帰の形で新しいプロセスを継続的に作成することです。たった 1 行のコードにもかかわらず、Bash の実行後、他に制約がない場合、オペレーティング システムは徐々に応答しなくなります。
図では 3 つのターミナルを示しています。左上のターミナルでは、仮想マシンにコンテナを作成し、Fork ボム コードを実行しました。下のターミナルは現在の仮想マシンの IP アドレスを示し、上のターミナルは仮想マシンの IP アドレスを示します。右上はフォーク内です。爆弾が実行されてから数分後、SSH を使用してリモートで仮想マシンにログインしてみます。この時点で仮想マシンが応答を失っていることがわかります。
このことから、関連する制限がなければ、コンテナ内のフォーク ボムがホスト マシンの通常の動作に影響を与える可能性があることがわかります。
ストレージリソースが枯渇した
ランタイム リソースに加えて、比較的静的なストレージ リソースも枯渇する可能性があります。すべての仮想化テクノロジーはエンティティに依存する必要があり、コンテナーも例外ではありません。最終的には、コンテナーに保存されているデータとファイルの実際の保存場所は依然として物理マシン上にあります。新しい 1GB ファイルがコンテナーに追加された場合、NFS に関係なく、ホスト上のディスクは 1GB 削減される必要があります。コンテナーにストレージ容量の制限がない場合、理論上、コンテナー内の攻撃者はホスト マシンのストレージ リソースを使い果たす可能性があります。
まず、df コマンドを使用してホストの利用可能なストレージ容量を確認し、次のコマンドを実行します。まだ 60G の空き容量があることがわかります。
df -h | grep /dev/sda1
次に、コンテナ内で fallocate コマンドを使用して 5 GB のファイルを作成します。
fallocate -l 5.0G ./bomb
次に、2 つの df コマンドを比較すると、作成後の使用可能なスペースが作成前より 5.0 GB 少ないことがわかりました。
このことから、ストレージ リソースを制限せずにコンテナ内で大量のディスク ストレージ領域を使用すると、ホスト マシン上の大量のディスク ストレージ領域が占有され、ホスト マシンの動作に影響を与える可能性があると推測できます。他のコンテナ