2026年9月も、Dockerの管理API（TCP 2375番・暗号化なし、または2376番・TLS）が認証なしのままインターネットに公開され、自動スキャンで見つかって仮想通貨マイニング用の不正なコンテナを勝手に起動される被害が報告され続けています。攻撃は人手を介さず、ボットが世界中のIPを機械的に走査して空いているDocker APIを見つけ次第コンテナを作成する仕組みのため、「うちは狙われるほどの規模じゃない」は理由になりません。この記事では、自分のサーバーでDockerのAPIが外部に開いていないか、すでに不審なコンテナが動いていないかを、ss・docker ps・ps auxの3つのコマンドだけで確認する手順をまとめます。

なぜ2026年もDocker APIの無認証公開が狙われ続けるのか

DockerデーモンはデフォルトではUnixソケット（/var/run/docker.sock）経由でのみ操作できますが、リモートから管理したい・監視ツールと連携したいといった理由でTCPポートを開ける設定に変更しているサーバーが後を絶ちません。このときTLS認証を付け忘れる、あるいは検証用に一時的に無認証で開けたまま忘れる、というミスが繰り返し起きています。

無認証のDocker APIは「コンテナを自由に作成・実行できるAPI」がそのまま外部に公開されている状態と同じです。攻撃者はコンテナ経由でホストのファイルシステムをマウントして操作できるため、単なる情報漏えいではなくサーバー乗っ取りにつながります。Kasperskyが2026年9月16日に報告した攻撃グループの動きでも、Linux・ESXi環境を狙ったバックドア「GhostContainer」がcrontabへの永続化やSELinux・AppArmorの無効化を試みる事例が挙げられており、コンテナ基盤や権限まわりの設定不備が足がかりにされる構図は今も変わっていません。AppArmorの点検についてはaa-statusでAppArmor点検2026年9月版もあわせて確認しておくと安心です。

ss -tulpnでDocker APIが外部に公開されていないか確認する

ssは「今このサーバーがどのポートで待ち受けているか」を見るコマンドです（旧来のnetstatは非推奨で、Ubuntu/Debianではssが標準の代替）。

sudo ss -tulpn | grep -E '2375|2376|dockerd'
  • 実行にsudoが必要です（プロセス名を表示するため）。設定変更は一切行わない、確認だけのコマンドです。
  • Ubuntu/Debian系であれば標準でインストール済みです。他ディストリ（CentOS/RHEL系など）でもssコマンド自体は同じものが使えます。

出力例（安全な状態）：

$ sudo ss -tulpn | grep -E '2375|2376|dockerd'
(何も表示されない)

これは2375/2376番ポートを誰も使っていない、つまりDocker APIが外部に公開されていない状態です。何も出力されなければ正常と判断してかまいません。

危険な状態はこう出ます：

$ sudo ss -tulpn | grep -E '2375|2376|dockerd'
tcp   LISTEN 0  4096  0.0.0.0:2375   0.0.0.0:*   users:(("dockerd",pid=1123,fd=7))

見るべき箇所

意味

判断

0.0.0.0:2375

全ネットワークインターフェースで2375番を待ち受け

外部からもアクセスできる状態。危険

127.0.0.1:2375だった場合

サーバー自身からのみアクセス可能

外部には公開されていない。比較的安全

dockerd

そのポートを使っているプロセス名

Docker本体が直接TCP公開している証拠

0.0.0.0で2375番（無認証）が開いていた場合は、次の章の手順で必ず閉じてください。2376番（TLS）でも、証明書の設定に心当たりがなければ同様に見直しが必要です。

docker psとps auxで不審なコンテナ・プロセスを見分ける

ポートが閉じていても、過去に一度でも公開されたことがあれば不正なコンテナがすでに動かされている可能性があります。

docker ps -a

これは今動いている（または過去に停止した）コンテナの一覧を見るコマンドです。sudoはDockerグループに所属していれば不要、していなければsudoを付けます。

出力例：

$ docker ps -a
CONTAINER ID   IMAGE              COMMAND      CREATED        STATUS        NAMES
a1b2c3d4e5f6   myapp:latest       "npm start"  2 weeks ago    Up 2 weeks    myapp_web
f6e5d4c3b2a1   xmrig/xmrig:latest "xmrig -o..." 3 hours ago   Up 3 hours    determined_curie
  • 心当たりのないIMAGE名（マイニングソフトの代表格がxmrigです。名前にminerや意味不明な英単語が入る場合も要注意）
  • 自分で作った覚えのないNAMES（Dockerがランダムに割り当てるdetermined_curieのような名前は、自分で--nameを指定していないコンテナに付く既定値です）
  • CREATED（作成日時）に覚えがないもの

のいずれかがあれば不審と判断してください。

コンテナに気づかれても、ホスト側で直接マイニングプロセスが動いている場合もあるためps auxも併用します。

ps aux --sort=-%cpu | head -10

CPU使用率が高い順にプロセスを並べるコマンドです。

$ ps aux --sort=-%cpu | head -10
USER      PID  %CPU %MEM COMMAND
username  8842 97.3  1.2 /tmp/.hidden/xmrig -o pool.example:14444
username  1123  2.1  0.8 /usr/bin/dockerd

CPUが常時90%以上に張り付いているプロセス、かつ/tmpや/var/tmpなど普段プログラムを置かない場所から実行されているものは高確率でマイニングです。プロセスとコンテナの見分け方をより詳しく確認したい場合はw/ps aux --forestで不審接続を発見2026年9月も参考になります。

見つかった場合の対処とDocker APIの閉じ方

不審なコンテナ・プロセスを見つけたら、まず証拠保全のためスクリーンショットやコマンド出力をコピーしてから対処します。

  1. 不審なコンテナを止める・消す：docker stop <CONTAINER ID> のあと docker rm <CONTAINER ID>。イメージ自体も使う予定がなければ docker rmi <IMAGE> で削除します。
  2. Docker APIの無認証TCP公開を止める：/etc/docker/daemon.jsonやsystemdのUnit（/lib/systemd/system/docker.serviceのExecStart）に-H tcp://0.0.0.0:2375のような記述がないか確認し、リモート管理が本当に必要でなければ削除します。編集後はsudo systemctl daemon-reloadとsudo systemctl restart dockerが必要です。
  3. どうしてもリモートから使う必要がある場合はTLS証明書によるクライアント認証を設定し、さらにufwで接続元IPを絞ります：sudo ufw allow from 203.0.113.10 to any port 2376。設定前に必ずsudo ufw allow sshでSSH接続を許可しておかないと、自分自身が締め出されます。
  4. 元に戻す方法：daemon.json・Unitファイルはいずれも編集前にコピー（sudo cp /etc/docker/daemon.json /etc/docker/daemon.json.bak）を取っておけば、問題が起きてもcpで戻せます。ufwのルール削除はsudo ufw delete allow from 203.0.113.10 to any port 2376で取り消せます。

侵入されていた形跡があった場合、マイニングプロセスを止めるだけでは他にバックドアが仕込まれている可能性を否定できません。サーバーのカーネルやパッケージが最新か（Debianなら2026年9月12日公開の13.7でカーネル6.12.107に更新されているか）もあわせて見直してください。この点はuname -aとlivepatchでカーネル点検2026年9月で確認できます。

まとめ

Docker管理API（TCP 2375/2376番）の無認証公開は、2026年9月時点でも仮想通貨マイニングの自動スキャン被害が続いている定番の侵入経路です。sudo ss -tulpn | grep -E '2375|2376'で外部公開の有無を確認し、docker ps -aとps aux --sort=-%cpuで見覚えのないコンテナ・高CPUプロセスがないかを見る。この2つを月に一度でも実行する習慣を付けるだけで、自動スキャンによる被害のほとんどは未然に防げます。設定変更にはsudoと再起動が伴うため、変更前のバックアップを忘れずに。