Japanese - Ht

Docker Security

**htARTE（HackTricks AWS Red Team Expert）**で**ゼロからヒーローまでAWSハッキングを学ぶ** こちら！

HackTricksをサポートする他の方法:

Trickestを使用して、世界で最も先進的なコミュニティツールによってパワードされたワークフローを簡単に構築および自動化します。 今すぐアクセスを取得:

LogoAutomate OffSec, EASM, and Custom Security Processes | Trickest

基本的なDocker Engineセキュリティ

Docker EngineはLinuxカーネルのNamespacesとCgroupsを使用してコンテナを分離し、基本的なセキュリティレイヤーを提供します。Capabilities dropping、Seccomp、SELinux/AppArmorによる追加の保護により、コンテナの分離が強化されます。認証プラグインを使用すると、ユーザーのアクションをさらに制限できます。

Docker Engineへの安全なアクセス

Docker Engineは、ローカルでUnixソケットを介してまたはHTTPを使用してリモートからアクセスできます。リモートアクセスの場合、機密性、整合性、および認証を確保するためにHTTPSとTLSを使用することが重要です。

デフォルトでは、Docker EngineはUnixソケットでunix:///var/run/docker.sockでリッスンします。Ubuntuシステムでは、Dockerの起動オプションは/etc/default/dockerに定義されています。Docker APIとクライアントへのリモートアクセスを有効にするには、次の設定を追加してDockerデーモンをHTTPソケットで公開してください:

DOCKER_OPTS="-D -H unix:///var/run/docker.sock -H tcp://192.168.56.101:2376"
sudo service docker restart

ただし、DockerデーモンをHTTP経由で公開することはセキュリティ上の懸念から推奨されていません。接続を安全にするためには、HTTPSを使用することがお勧めされます。接続を保護するための主なアプローチは2つあります：

  1. クライアントがサーバーの正体を確認する。

  2. クライアントとサーバーがお互いの正体を相互認証する。

証明書はサーバーの正体を確認するために使用されます。両方の方法の詳細な例については、このガイドを参照してください。

コンテナイメージのセキュリティ

コンテナイメージは、プライベートリポジトリまたはパブリックリポジトリに保存できます。Dockerには、コンテナイメージのためのいくつかのストレージオプションがあります：

  • Docker Hub: Dockerのパブリックレジストリサービス。

  • Docker Registry: ユーザーが独自のレジストリをホストできるオープンソースプロジェクト。

  • Docker Trusted Registry: Dockerの商用レジストリオファリングで、ロールベースのユーザー認証とLDAPディレクトリサービスとの統合を提供しています。

イメージスキャン

コンテナには、ベースイメージまたはベースイメージの上にインストールされたソフトウェアのせいでセキュリティの脆弱性がある場合があります。Dockerは、コンテナのセキュリティスキャンを行い脆弱性をリストアップするプロジェクトNautilusに取り組んでいます。Nautilusは、各コンテナイメージレイヤーを脆弱性リポジトリと比較してセキュリティホールを特定します。

詳細については、こちらを読んでください。

  • docker scan

**docker scan**コマンドを使用すると、イメージ名またはIDを使用して既存のDockerイメージをスキャンできます。たとえば、次のコマンドを実行してhello-worldイメージをスキャンできます：

docker scan hello-world

Testing hello-world...

Organization:      docker-desktop-test
Package manager:   linux
Project name:      docker-image|hello-world
Docker image:      hello-world
Licenses:          enabled

✓ Tested 0 dependencies for known issues, no vulnerable paths found.

Note that we do not currently have vulnerability data for your image.
trivy -q -f json <container_name>:<tag>
snyk container test <image> --json-file-output=<output file> --severity-threshold=high
clair-scanner -w example-alpine.yaml --ip YOUR_LOCAL_IP alpine:3.5

Dockerイメージの署名

Dockerイメージの署名は、コンテナで使用されるイメージのセキュリティと整合性を確保します。以下は要約した説明です：

  • Docker Content Trust は、Notaryプロジェクトを利用し、The Update Framework (TUF) に基づいてイメージの署名を管理します。詳細については、Notary と TUF を参照してください。

  • Dockerコンテンツ信頼を有効にするには、export DOCKER_CONTENT_TRUST=1 を設定します。この機能は、Dockerバージョン1.10以降ではデフォルトでオフになっています。

  • この機能を有効にすると、署名されたイメージのみをダウンロードできます。最初のイメージプッシュでは、ルートとタグ付けキーのパスフレーズを設定する必要があり、Dockerはセキュリティを強化するためにYubikeyもサポートしています。詳細はこちらにあります。

  • コンテンツ信頼が有効な状態で署名されていないイメージを取得しようとすると、「最新の信頼データがありません」というエラーが発生します。

  • 最初以降のイメージプッシュでは、Dockerはイメージに署名するためにリポジトリキーのパスフレーズを要求します。

プライベートキーをバックアップするには、次のコマンドを使用します：

tar -zcvf private_keys_backup.tar.gz ~/.docker/trust/private

Dockerホストを切り替える際には、操作を維持するためにルートとリポジトリキーを移動する必要があります。

Trickestを使用して、世界で最も先進的なコミュニティツールによって強化されたワークフローを簡単に構築および自動化します。 今すぐアクセスしてください：

コンテナセキュリティ機能

コンテナセキュリティ機能の概要

メインプロセス分離機能

コンテナ化された環境では、プロジェクトとそのプロセスを分離することがセキュリティとリソース管理にとって重要です。以下は、主要な概念の簡略化された説明です：

ネームスペース

  • 目的: プロセス、ネットワーク、およびファイルシステムなどのリソースの分離を確保します。特にDockerでは、ネームスペースがコンテナのプロセスをホストや他のコンテナから分離します。

  • unshareの使用: unshareコマンド（またはその基礎となるシスコール）は、新しいネームスペースを作成するために使用され、追加の分離レイヤーを提供します。ただし、Kubernetesはこれを元々ブロックしませんが、Dockerはします。

  • 制限: 新しいネームスペースを作成することで、プロセスがホストのデフォルトのネームスペースに戻ることはできません。ホストのネームスペースに侵入するには、通常、ホストの/procディレクトリにアクセスし、nsenterを使用する必要があります。

コントロールグループ（CGroups）

  • 機能: プロセス間でリソースを割り当てるために主に使用されます。

  • セキュリティ面: CGroups自体は分離セキュリティを提供しませんが、release_agent機能は、誤って構成されている場合、権限のないアクセスに悪用される可能性があります。

機能の削除

  • 重要性: プロセス分離のための重要なセキュリティ機能です。

  • 機能: 特定の機能をドロップすることで、ルートプロセスが実行できるアクションを制限します。プロセスがルート権限で実行されていても、必要な機能がないため、特権アクションを実行できません。シスコールは権限が不足しているため失敗します。

これは、プロセスが他の機能をドロップした後の残りの機能です：

Current: cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap=ep

Seccomp

デフォルトでDockerに有効になっています。これはプロセスが呼び出すことができるシステムコールをさらに制限するのに役立ちます。 デフォルトのDocker Seccompプロファイルはhttps://github.com/moby/moby/blob/master/profiles/seccomp/default.jsonで見つけることができます。

AppArmor

Dockerにはアクティベートできるテンプレートがあります: https://github.com/moby/moby/tree/master/profiles/apparmor

これにより、機能の制限、システムコール、ファイルやフォルダへのアクセスが可能になります...

名前空間

名前空間はLinuxカーネルの機能で、1つのプロセスセットが1つのリソースセットを見る一方、別のプロセスセットが異なるリソースセットを見るようにカーネルリソースを分割する機能です。この機能は、一連のリソースとプロセスに同じ名前空間を持たせることで機能し、ただし、それらの名前空間は異なるリソースを参照します。リソースは複数のスペースに存在する可能性があります。

Dockerは、コンテナの分離を実現するために以下のLinuxカーネル名前空間を利用しています:

  • pid namespace

  • mount namespace

  • network namespace

  • ipc namespace

  • UTS namespace

名前空間に関する詳細情報については、次のページを参照してください:

pageNamespaces

cgroups

Linuxカーネル機能cgroupsは、一連のプロセス間でcpu、memory、io、ネットワーク帯域幅などのリソースを制限する機能を提供します。 Dockerは、リソース制御を可能にするcgroup機能を使用してコンテナを作成できます。 以下は、ユーザースペースメモリが500mに制限され、カーネルメモリが50mに制限され、CPU共有が512に、blkioweightが400に制限されたコンテナの例です。 CPU共有は、コンテナのCPU使用率を制御する比率です。デフォルト値は1024で、0から1024までの範囲があります。 CPUリソースの競合が発生した場合、CPU共有が1024の3つのコンテナがある場合、各コンテナはCPUの33%まで取得できます。 blkio-weightは、コンテナのIOを制御する比率です。デフォルト値は500で、10から1000までの範囲があります。

docker run -it -m 500M --kernel-memory 50M --cpu-shares 512 --blkio-weight 400 --name ubuntu1 ubuntu bash

コンテナのcgroupを取得するには、次のようにします:

docker run -dt --rm denial sleep 1234 #Run a large sleep inside a Debian container
ps -ef | grep 1234 #Get info about the sleep process
ls -l /proc/<PID>/ns #Get the Group and the namespaces (some may be uniq to the hosts and some may be shred with it)

機能

機能は、rootユーザーに許可される機能を細かく制御することを可能にします。Dockerは、ユーザーの種類に関係なく、コンテナ内で行われる操作を制限するためにLinuxカーネルの機能を使用します。

Dockerコンテナが実行されると、プロセスは隔離から脱出するために使用できる機密機能を削除します。これにより、プロセスが機密なアクションを実行して脱出することができないようにします：

pageLinux Capabilities

Docker内のSeccomp

これは、Dockerがコンテナ内で使用できるシステムコールを制限するセキュリティ機能です：

pageSeccomp

Docker内のAppArmor

AppArmorは、プログラムごとのプロファイルでコンテナを限られたリソースに制限するためのカーネル拡張機能です：

pageAppArmor

Docker内のSELinux

  • ラベリングシステム：SELinuxは、すべてのプロセスとファイルシステムオブジェクトに一意のラベルを割り当てます。

  • ポリシーの強制：プロセスラベルがシステム内の他のラベルに対して実行できるアクションを定義するセキュリティポリシーを強制します。

  • コンテナプロセスラベル：コンテナエンジンがコンテナプロセスを開始するとき、通常はcontainer_tという制限付きSELinuxラベルが割り当てられます。

  • コンテナ内のファイルラベリング：コンテナ内のファイルは通常、container_file_tとしてラベル付けされます。

  • ポリシールール：SELinuxポリシーは、主にcontainer_tラベルを持つプロセスがcontainer_file_tとしてラベル付けされたファイルとのみ相互作用（読み取り、書き込み、実行）できることを確認します。

このメカニズムにより、コンテナ内のプロセスが侵害された場合でも、対応するラベルを持つオブジェクトとの相互作用に制限され、そのような侵害からの潜在的な被害が大幅に制限されます。

pageSELinux

AuthZ＆AuthN

Dockerでは、認可プラグインが重要な役割を果たし、Dockerデーモンへのリクエストを許可するかブロックするかを決定します。この決定は、次の2つのキーとなるコンテキストを調査することで行われます：

  • 認証コンテキスト：これには、ユーザーに関する包括的な情報が含まれます。つまり、誰であり、どのように認証されたかなどです。

  • コマンドコンテキスト：これには、行われているリクエストに関連するすべての適切なデータが含まれます。

これらのコンテキストにより、認証されたユーザーからの正当なリクエストのみが処理され、Docker操作のセキュリティが向上します。

pageAuthZ& AuthN - Docker Access Authorization Plugin

コンテナからのDoS

コンテナが使用できるリソースを適切に制限していない場合、侵害されたコンテナが実行されているホストをDoS攻撃する可能性があります。

  • CPU DoS

# stress-ng
sudo apt-get install -y stress-ng && stress-ng --vm 1 --vm-bytes 1G --verify -t 5m

# While loop
docker run -d --name malicious-container -c 512 busybox sh -c 'while true; do :; done'

  • バンド幅 DoS

nc -lvp 4444 >/dev/null & while true; do cat /dev/urandom | nc <target IP> 4444; done

インタレスティングな Docker フラグ

--privileged フラグ

次のページで、--privileged フラグが意味するものを学ぶことができます:

pageDocker --privileged

--security-opt

no-new-privileges

低権限ユーザーとしてアクセスを取得した攻撃者がコンテナを実行している場合、誤構成された suid バイナリ があると、攻撃者はそれを悪用してコンテナ内で特権を昇格させる可能性があります。これにより、脱出することができるかもしれません。

no-new-privileges オプションを有効にしてコンテナを実行すると、この種の特権昇格を防ぐことができます。

docker run -it --security-opt=no-new-privileges:true nonewpriv

その他

#You can manually add/drop capabilities with
--cap-add
--cap-drop

# You can manually disable seccomp in docker with
--security-opt seccomp=unconfined

# You can manually disable seccomp in docker with
--security-opt apparmor=unconfined

# You can manually disable selinux in docker with
--security-opt label:disable

さらなる**--security-opt**オプションについては、https://docs.docker.com/engine/reference/run/#security-configurationを参照してください。

その他のセキュリティ考慮事項

シークレットの管理：ベストプラクティス

Dockerイメージにシークレットを直接埋め込むか、環境変数を使用することは避けることが重要です。これらの方法は、docker inspectやexecなどのコマンドを介してコンテナにアクセス権を持つ者に機密情報を公開してしまいます。

Dockerボリュームは、機密情報にアクセスするために推奨されるより安全な代替手段です。これらは一時的なメモリ内ファイルシステムとして利用でき、docker inspectやログ記録に関連するリスクを軽減します。ただし、ルートユーザーやコンテナへのexecアクセス権を持つユーザーは依然としてシークレットにアクセスできる可能性があります。

Dockerシークレットは、機密情報を取り扱うためのさらに安全な方法を提供します。イメージのビルドフェーズ中にシークレットが必要な場合、BuildKitはビルド時間シークレットをサポートする効率的なソリューションを提供し、ビルド速度を向上させ、追加の機能を提供します。

BuildKitを活用するためには、次の3つの方法でアクティブ化できます：

  1. 環境変数を介して：export DOCKER_BUILDKIT=1

  2. コマンドに接頭辞を付けて：DOCKER_BUILDKIT=1 docker build .

  3. Docker構成でデフォルトで有効にする：{ "features": { "buildkit": true } }と記述し、その後にDockerを再起動します。

BuildKitを使用すると、--secretオプションを使用してビルド時間シークレットを利用でき、これらのシークレットがイメージビルドキャッシュや最終イメージに含まれないようにします。

docker build --secret my_key=my_value ,src=path/to/my_secret_file .

コンテナで必要とされるシークレットについては、Docker ComposeとKubernetesが堅牢なソリューションを提供しています。Docker Composeは、シークレットファイルを指定するためのsecretsキーをサービス定義で利用し、docker-compose.ymlの例に示すように使用します:

version: "3.7"
services:
my_service:
image: centos:7
entrypoint: "cat /run/secrets/my_secret"
secrets:
- my_secret
secrets:
my_secret:
file: ./my_secret_file.txt

この構成では、Docker Composeを使用してサービスを起動する際にシークレットを使用できるようになります。

Kubernetes環境では、シークレットはネイティブでサポートされ、Helm-Secretsなどのツールでさらに管理できます。 KubernetesのRole Based Access Controls（RBAC）は、Docker Enterpriseと同様にシークレット管理のセキュリティを向上させます。

gVisor

gVisorは、Linuxシステムの大部分を実装するGoで書かれたアプリケーションカーネルで、ホストカーネルとアプリケーションの間の隔離境界を提供するrunscというOpen Container Initiative（OCI）ランタイムを含んでいます。 runscランタイムはDockerとKubernetesと統合されており、サンドボックス化されたコンテナを簡単に実行できます。

Kata Containers

Kata Containersは、コンテナのように感じ、パフォーマンスが高い軽量な仮想マシンを使用して、ハードウェア仮想化技術を使用してより強力なワークロード分離を提供するセキュアなコンテナランタイムを構築するために取り組むオープンソースコミュニティです。

要約のヒント

  • --privilegedフラグを使用しないか、コンテナ内にDockerソケットをマウントしないでください。 Dockerソケットを使用すると、別のコンテナを--privilegedフラグで実行するなど、ホストを完全に制御する簡単な方法になります。

  • コンテナ内でrootとして実行しないでください。異なるユーザー とユーザーネームスペース を使用してください。 コンテナ内のrootは、ユーザーネームスペースでリマップされていない限り、ホストと同じです。主にLinuxのネームスペース、機能、およびcgroupsによってわずかに制限されています。

  • すべての機能を削除 （--cap-drop=all）し、必要な機能のみを有効にしてください（--cap-add=...）。多くのワークロードには機能が必要ない場合があり、それらを追加すると攻撃の範囲が広がります。

  • プロセスが特権を取得するのを防ぐために、「no-new-privileges」セキュリティオプションを使用してください。たとえば、suidバイナリを介して特権を取得することがあります。

  • コンテナに利用可能なリソースを制限してください。リソース制限は、マシンをサービス拒否攻撃から保護できます。

  • seccomp、AppArmor **（またはSELinux）**プロファイルを調整して、コンテナで利用可能なアクションとシスコールを最小限に制限してください。

  • **公式のDockerイメージ**を使用し、署名を要求するか、それらを基に独自のイメージを構築してください。バックドアが仕込まれたイメージを継承したり使用しないでください。また、ルートキー、パスフレーズを安全な場所に保存してください。 Dockerは、UCPでキーを管理する計画を立てています。

  • イメージを定期的に再構築して、ホストとイメージにセキュリティパッチを適用してください。

  • シークレットを賢く管理して、攻撃者がアクセスしにくくしてください。

  • Dockerデーモンを公開する場合は、HTTPSを使用して、クライアントとサーバーの認証を行ってください。

  • Dockerfileでは、ADDの代わりにCOPYを使用してください。ADDは自動的にzipファイルを解凍し、URLからファイルをコピーできます。COPYにはこれらの機能がありません。可能な限りADDを使用せず、リモートURLやZipファイルを介した攻撃に対して脆弱にならないようにしてください。

  • 各マイクロサービスに別々のコンテナを使用してください。

  • コンテナ内にsshを配置しないでください。 "docker exec"を使用してコンテナにsshすることができます。

  • 小さなコンテナイメージを使用してください。

Docker Breakout / Privilege Escalation

もしDockerコンテナ内にいるか、dockerグループのユーザーにアクセス権がある場合、脱出して特権を昇格することができます:

pageDocker Breakout / Privilege Escalation

Docker Authentication Plugin Bypass

Dockerソケットにアクセス権があるか、dockerグループのユーザーにアクセス権があるが、docker認証プラグインによって制限されている場合、バイパスできるかどうかを確認してください:

pageAuthZ& AuthN - Docker Access Authorization Plugin

Dockerのハードニング

  • ツールdocker-bench-securityは、本番環境でDockerコンテナを展開する際の数十の一般的なベストプラクティスをチェックするスクリプトです。テストはすべて自動化されており、CIS Docker Benchmark v1.3.1に基づいています。 このツールを実行するには、Dockerを実行しているホストからまたは十分な権限を持つコンテナから実行する必要があります。READMEでの実行方法を見つけてください: https://github.com/docker/docker-bench-security.

参考文献

Trickestを使用して、世界で最も高度なコミュニティツールによって強化されたワークフローを簡単に構築および自動化してください。 今すぐアクセスしてください:

**htARTE（HackTricks AWS Red Team Expert）**で**ゼロからヒーローまでのAWSハッキング**を学びましょう！

HackTricksをサポートする他の方法:もし HackTricks で あなたの企業を宣伝したい か HackTricksをPDFでダウンロード したい場合は、SUBSCRIPTION PLANS をチェックしてください！公式PEASS & HackTricksグッズを入手してくださいThe PEASS Familyを発見し、独占的な NFTs のコレクションをご覧ください💬 Discordグループ に参加 または telegramグループ に参加し、Twitter 🐦 で フォロー してください @carlospolopm.ハッキングテクニックを共有する には、HackTricks と HackTricks Cloud のgithubリポジトリにPRを提出してください。

PreviousD-Bus Enumeration & Command Injection Privilege EscalationNextAbusing Docker Socket for Privilege Escalation

Last updated