Docker APIを無防備に公開していませんか？実例から学ぶ設定チェック

こんにちは、かつコーチです。

前回の記事で、AIエージェントを使った自動攻撃について紹介しました。
今回はその中でも触れた「Docker APIの公開設定」について、具体的に掘り下げます。

Docker APIとは何か

Docker APIは、コンテナーの作成・起動・停止といった操作を、コマンドラインやツールから行うための管理用インターフェースです。
通常はdockerコマンドを使うときに、ローカルのUnixソケット経由で裏側で使われています。

このAPIをネットワーク越しに使えるようにする設定（TCPで公開する設定）自体は、リモートからコンテナーを管理したい場合などに用意されている機能です。
問題は、認証の設定をしないまま、このAPIをインターネットに公開してしまうケースがあることです。

セキュリティ企業のThreatDownは2026年9月22日、「CARBONATO」と呼ばれる攻撃について報告しています。
認証なしで公開されたDocker APIを侵入口にし、侵害後の操作にAIエージェントを使う、という仕組みが説明されています。

この事例のポイントは、AIツールを使っていない組織も被害の対象になり得るという点です。
攻撃者がAPIに接続できてしまえば、新しいコンテナーを起動してホスト上で任意のコマンドを実行する、といったことも可能になります。

Docker APIのデフォルトポートは2375番（非暗号化）・2376番（TLS）です。
サーバーのファイアウォール設定で、これらのポートが外部（0.0.0.0など）からアクセスできる状態になっていないか確認しましょう。

# 開いているポートを確認する例（Linuxサーバー上で実行）
sudo ss -tulnp | grep -E '2375|2376'

Dockerデーモンの設定ファイル（/etc/docker/daemon.json）で、TCPソケットを認証なしで待ち受ける設定になっていないか確認します。

{
  "hosts": ["tcp://0.0.0.0:2375", "unix:///var/run/docker.sock"]
}

上記のように、認証なしのTCP待ち受けが含まれている場合は注意が必要です。

リモートからの管理が不要なら、TCP公開自体をやめる（ローカルのUnixソケットのみで運用する）
リモート管理が必要な場合は、TLSクライアント証明書による相互認証を設定する
ファイアウォールで2375・2376番ポートを外部に公開しない（必要な接続元IPのみ許可する）
可能であれば、SSH経由でDockerコンテキストを切り替えて操作する（docker context機能を使うと、TCP公開なしでリモート操作ができます）

動作確認のために一時的にTCP公開を有効にし、確認が終わった後にそのまま放置してしまうケースは少なくありません。
検証用の設定変更は、終わったタイミングで元に戻す運用を徹底しましょう。

/var/run/docker.sockのパーミッションを安易に緩めてしまうと、サーバー上の別のプロセスやユーザーからDocker操作ができてしまう場合があります。
必要最小限のユーザー・グループにのみアクセスを許可する設定を心がけましょう。

次回は「ファイルアップロード機能、拡張子チェックだけで安全と思っていませんか？」を紹介します。