ポート27017は MongoDB の標準ポートです。インターネットから接続できる状態になっているなら、MongoDB の待ち受けアドレス（bindIp）をローカルに限り、認証を有効にし、ファイアウォールとクラウドのセキュリティグループで外部からの接続を遮断する、という3段階で閉じます。この記事では、公開されているかの確認方法、それぞれの設定手順、Docker で動かしている場合の注意点、すでに公開していた場合の対処を説明します。
まず公開状態を確認する
サーバー内で待ち受けアドレスを見る
sudo ss -tlnp | grep 27017結果の4列目が 127.0.0.1:27017 ならローカルからの接続だけを受け付けています。0.0.0.0:27017 や *:27017、[::]:27017 なら、すべてのネットワークインターフェースで待ち受けている状態です。この場合、ファイアウォールで止めていなければ外部から接続できます。
外部から接続できるかを見る
自分の管理するサーバーに対して、別のネットワークから確認します。他人のサーバーへのポートスキャンは行わないでください。
# 自宅や別のサーバーなど、外部のネットワークから実行する
nmap -Pn -p 27017 （サーバーの公開IPアドレス）open と表示されれば外部から到達できる状態、filtered ならファイアウォールなどで遮断されている状態、closed なら到達はするが待ち受けていない状態です。
誰が使っているかを確認する
閉じる前に、どのアプリケーションが MongoDB に接続しているかを確認しておきます。WordPress 本体は MySQL か MariaDB を使うため、27017 を閉じても WordPress には影響しません。ただし、同じサーバーやネットワークで動く別のアプリケーションが接続している可能性があります。
sudo ss -tnp state established '( sport = :27017 )'接続元のIPアドレスが表示されます。ここにサーバー外のアドレスがあれば、そのアプリケーションの接続方法を先に決めておかないと、閉じた時点で止まります。
手順1：bindIp をローカルに限る
MongoDB の設定ファイル（Linux のパッケージでは多くの場合 /etc/mongod.conf）で、待ち受けるアドレスを指定します。変更前に設定ファイルを控えておいてください。
net:
port: 27017
bindIp: 127.0.0.1同じサーバーのアプリケーションだけが使うなら、127.0.0.1 だけで足ります。別のサーバーのアプリケーションから接続する必要がある場合は、127.0.0.1,10.0.1.5 のように、プライベートネットワーク側のアドレスを加えます。公開IPアドレスや 0.0.0.0 は指定しないようにします。
sudo systemctl restart mongod
sudo ss -tlnp | grep 27017再起動後、待ち受けアドレスが変わったことを確認します。設定ファイルの書式（YAMLのインデント）を誤ると mongod が起動しなくなるため、起動しない場合は sudo journalctl -u mongod -n 50 でエラーを確認します。
手順2：認証を有効にする
ネットワークで遮断しても、同じネットワーク内の別のサーバーが侵害されれば接続される可能性があります。認証は有効にしておきます。
認証を有効にする前に、管理用のユーザーを作成します。パスワードはコマンドに直接書かず、passwordPrompt() で入力すると、シェルの履歴に残りません。
// mongosh で接続して実行する
use admin
db.createUser({
user: "siteAdmin",
pwd: passwordPrompt(),
roles: [
{ role: "userAdminAnyDatabase", db: "admin" },
{ role: "readWriteAnyDatabase", db: "admin" }
]
})続いて、設定ファイルに認証の項目を加え、再起動します。
security:
authorization: enabledアプリケーションには、必要なデータベースだけを操作できるユーザーを別に作り、そのユーザーで接続させます。管理用のユーザーをアプリケーションに使い回さないことで、アプリケーションが侵害されたときの影響を小さくできます。
手順3：ファイアウォールで遮断する
ufw の場合
# 現在の規則を番号付きで確認する
sudo ufw status numbered
# 27017 を許可している規則があれば削除する
sudo ufw delete allow 27017/tcp
# 特定のアプリケーションサーバーからだけ許可する場合
sudo ufw allow from 10.0.1.20 to any port 27017 proto tcp受信の既定が拒否（default deny incoming）になっていれば、許可規則を消すだけで外部からの接続は止まります。SSH の許可規則を消さないように、作業中は番号と内容をよく確認してください。
firewalld の場合
sudo firewall-cmd --list-all
sudo firewall-cmd --permanent --remove-port=27017/tcp
sudo firewall-cmd --reloadクラウドのセキュリティグループ
AWS のセキュリティグループや Azure の NSG などで 27017 を 0.0.0.0/0 に開けていないかを確認し、許可する場合はアプリケーションサーバーのアドレスやセキュリティグループに限ります。サーバー内のファイアウォールとクラウドの設定は別々に効くため、両方を確認します。
Docker で動かしている場合の注意
Docker で -p 27017:27017 のようにポートを公開すると、Docker が iptables の規則を直接追加するため、ufw の規則とは関係なく外部から接続できる状態になることがあります。ufw で拒否しているのに nmap で open と出る場合は、まずこれを疑います。
同じホストのアプリケーションだけが使うなら、ポートを公開しないか、ローカルアドレスに限って公開します。
# docker-compose.yml の例
services:
mongo:
image: mongo:7
ports:
- "127.0.0.1:27017:27017"アプリケーションも Compose で動かしているなら、ports を書かずに同じネットワーク内のサービス名（この例では mongo）で接続させるほうが安全です。
すでに外部公開していた場合の対処
認証なしで公開していた期間がある場合は、閉じたあとに次の点を確認します。
- データベースの一覧に見覚えのないものがないか、データが消されていないか。公開された MongoDB のデータを消して身代金を要求する攻撃が知られています。
- ユーザーの一覧に作った覚えのないものがないか（
db.getUsers()）。 - MongoDB のログに、知らないIPアドレスからの接続が記録されていないか。
被害が疑われる場合は、バックアップから復元し、パスワードと、データベースに保存していた API キーなどの秘密情報を変更します。個人情報を保存していた場合は、法令や社内規程に沿った対応が必要になることもあります。普段から mongodump などでバックアップを取り、復元できることを確かめておくと、こうした場面で判断が早くなります（MongoDB のバージョンごとの細かな既定値は2026年10月現在のドキュメントで確認してください）。
外部から管理作業をしたい場合は、27017 を開ける代わりに SSH のポートフォワーディングを使う方法があります。
まとめ
ss -tlnpで待ち受けアドレスを、外部からのnmapで到達性を確認し、閉じる前に接続中のアプリケーションを把握します。- bindIp をローカルかプライベートアドレスに限り、管理用とアプリケーション用のユーザーを分けて認証を有効にします。
- ufw・firewalld とクラウドのセキュリティグループの両方で 27017 を遮断し、許可は必要な接続元だけにします。
- Docker のポート公開は ufw を迂回することがあるため、
127.0.0.1に限って公開するか、公開しない構成にします。 - 公開していた期間があれば、データ・ユーザー・ログを確認し、必要に応じて復元と秘密情報の変更を行います。