
不要なポート・サービスを閉じる棚卸し手順|壊さず一人で進める
引き継いだサーバーに入って、なんとなく ss -tulpn を打ってみる。 22、80、443……までは分かる。でもその下に、3306、6379、8080、それから見覚えのない5桁の番号がいくつも並んでいる。
「これ、全部外から見えてるんだろうか」。 気になる。でも、閉じた瞬間に何かが止まったら——そう思うと、手が止まりますよね。
ポートが増えているのは、前任者がいい加減だったからではありません。ソフトを入れると、初期設定のまま待ち受けを始めるものが多い。そして、使わなくなっても「止めて困る人がいたら怖い」ので、そのまま残る。それが何年か積み重なっただけです。この記事では、その積み重ねを、壊さずに少しずつほどいていく順番を一緒に見ていきます。
結論:やることは3つです。①内側(サーバーの中)と外側(インターネット側)の2方向から、開いているポートを洗い出す、②1ポート1行の表にして「誰が使っているか」を確かめる、③閉じるときは「外から閉じる→様子を見る→サービスを止める」の順で、いつでも戻せる形にする。いきなりアンインストールはしません。今日は洗い出すだけでも十分です。
なぜ「知らないポート」が増えていくのか
開いているポートは、放っておくと増える一方です。理由はだいたい決まっています。
- 入れただけで待ち受けるソフトが多い:DB、キャッシュ、管理画面つきのミドルウェアなど、インストールした時点で起動し、ポートを開くものがあります。
- 「全部のネットワークで待ち受け」が初期値のこともある:設定によっては、サーバー内からだけ使うつもりのDBが、外側の口でも待ち受けていることがあります。
- 使わなくなっても止めない:検証で入れたもの、移行前の旧サービス、一度だけ使った管理ツール。止める理由より、止めない理由のほうが強いのが運用の現場です。
ポートが開いていること自体が、すぐに問題になるわけではありません。ただ、外から見える入口が多いほど、パッチを当てる対象も、見張る対象も増えます。一人で守るなら、入口は少ないほうが楽です。棚卸しは、守る範囲を自分の手に収まる大きさにするための作業です。
ステップ1:内側から見る|サーバーが何を待ち受けているか
まずはサーバーの中から、待ち受け中のポートを一覧にします。読み取りだけのコマンドです。
# 待ち受け中のTCP/UDPポートと、使っているプロセス(プロセス名の表示にはroot権限が必要です)
sudo ss -tulpn
オプションの意味は、t=TCP、u=UDP、l=待ち受け中のもの、p=プロセス、n=番号のまま表示、です。古い手順書では netstat -tulpn と書かれていることがありますが、最近のディストリビューションでは ss が標準です(netstat は追加パッケージが必要なことが多いです)。
出力で、まず見てほしいのは Local Address の左側(どのアドレスで待ち受けているか) です。
| Local Address の表示 | 意味 | 外から届く可能性 |
|---|---|---|
127.0.0.1:3306 / [::1]:3306 | サーバー自身からだけ受け付ける | 基本的に届かない |
0.0.0.0:3306 / [::]:3306 / *:3306 | すべてのネットワークで受け付ける | ファイアウォール次第で届く |
10.0.1.5:3306 など特定のIP | そのIPの口でだけ受け付ける | そのネットワークから届く |
0.0.0.0 や [::] で待ち受けているものが、今日いちばん気にしたい対象です。IPv6の [::] は見落としやすいので、IPv4と分けて確認してください。
プロセス名だけでは正体が分からないときは、PIDから素性をたどります。
# そのPIDはどのsystemdサービスか
systemctl status <PID>
# 実行ユーザーとコマンドライン
ps -o pid,user,etime,cmd -p <PID>
# ソケット経由で必要なときだけ起動するもの(待ち受けているのはsystemd自身)
systemctl list-sockets
ss の結果に systemd が出てくる場合は、ソケット起動(接続が来たときだけ本体を起動する仕組み)です。サービスだけ止めても、ソケットが残っていればポートは開いたままなので、list-sockets も一緒に見ておきます。
常駐プロセスそのものの洗い出しは、cron・常駐プロセスの棚卸し手順とやることが近いので、あわせて進めると二度手間になりません。
ステップ2:外側から見る|実際に何が届いているか
内側で 0.0.0.0 だったとしても、手前のファイアウォールで止まっていれば外からは届きません。逆に「ファイアウォールで閉じているはず」が、実際には開いていることもあります。本当に外から見えているかは、外から確かめるのがいちばん確実です。
ファイアウォールの設定を読む
# Ubuntu系でufwを使っている場合
sudo ufw status verbose
# RHEL系でfirewalldを使っている場合
sudo firewall-cmd --list-all
# 実際に効いているルールの全体(nftables)
sudo nft list ruleset
クラウドのサーバーなら、サーバーの外側にあるセキュリティグループ(クラウドの管理画面で設定するファイアウォール)も必ず見てください。サーバーの中だけ見て「閉じている」と判断すると、ここを丸ごと見落とします。
ひとつ、引っかかりやすい点があります。Dockerでポートを公開(-p 8080:80 など)しているコンテナは、ufwのルールを素通りして外に見えることがあります。Dockerが自分でパケットの通り道を書き換えるためです。ufwで閉じたつもりのポートが外から見えていたら、まずここを疑ってみてください。
外から実際に叩いてみる
社外の回線(自宅の回線や、別ネットワークにある作業用サーバーなど)から、自分が管理しているサーバーに対してだけ確認します。
# 主要なポートを外から確認(-Pn はping応答がなくても続行する指定)
nmap -Pn <サーバーのグローバルIP>
# 全ポートを確認したい場合(時間がかかります)
nmap -Pn -p- <サーバーのグローバルIP>
# 特定のポート1つだけを手早く確認
nc -vz <サーバーのグローバルIP> 3306
ポートスキャンは、管理権限のあるサーバーにだけ行ってください。共用サーバーやホスティングでは規約で制限されていることもあるので、事前に契約先の決まりを確認しておくと安心です。疎通の基本的な見方は疎通しないときの切り分け手順にまとめています。
ステップ3:1ポート1行の表にする(そのまま使えるテンプレート)
内側と外側の結果を、1つの表に並べます。埋まらない欄は空欄のままで大丈夫です。
| ポート | プロセス/サービス | 待ち受けアドレス | 外から見えるか | 使っている人・システム | 判断 |
|---|---|---|---|---|---|
| 22/tcp | sshd | 0.0.0.0 | 見える | 自分・外注さん | 必要(接続元を絞る) |
| 443/tcp | nginx | 0.0.0.0 | 見える | 利用者全員 | 必要 |
| 3306/tcp | mysqld | 0.0.0.0 | 見える | 同じサーバーのアプリのみ? | 要確認 |
| 6379/tcp | redis-server | 127.0.0.1 | 見えない | アプリのセッション | 必要 |
| 8080/tcp | java(旧管理ツール?) | 0.0.0.0 | 見える | 不明 | 要確認 |
判断の欄は、必要/要確認/停止済みの3つにします。「不要」という欄はあえて作りません。決めきれないものを置いておける場所があると、無理に閉じなくて済みます。
見ていくと、よく出てくるのがこのあたりです。
- DB(3306 MySQL・5432 PostgreSQLなど):同じサーバーのアプリからしか使っていないなら、外から見える必要はないことが多いです。
- キャッシュ・検索(6379 Redis・11211 memcached・9200 Elasticsearchなど):認証なしで動いている構成もあるので、外から見えているなら優先して確かめたい対象です。
- 管理画面・アプリサーバー(8080・8443など):検証用に開けたまま、という例が多い場所です。使っているなら管理画面のアクセス制限で接続元を絞るのも一つの手です。
- メール・その他(25・111など):送信だけのサーバーなのに受信も待ち受けている、使っていないRPCが動いている、といった形で見つかります。
番号と用途の対応はあくまで「よくある例」です。同じ番号を別のソフトが使っていることもあるので、最後は必ずステップ1のプロセスで確かめてください。
ステップ4:閉じるときは「確かめる→外から閉じる→止める」の順で

「要確認」のポートを減らすときは、次の3段階で進めます。いきなりサービスを止めたりアンインストールしたりせず、間に「外から閉じて様子を見る」段階をはさむのがコツです。
① 確かめる|いま誰がつないでいるか
待ち受けているだけでなく、実際に接続が来ているかを見ます。
# 3306番に今つながっている相手(接続元のIPが分かる)
sudo ss -tnp state established '( sport = :3306 )'
接続元が 127.0.0.1 だけなら、同じサーバー内からしか使われていません。知らないIPが出てきたら、それが「使っている人」の手がかりです。一度見ただけでは分からないので、日中・夜間・月末など何回か見るか、サービス側のアクセスログで接続元を確認します。月に一度しか動かないバッチもあるので、急がないでください。
② 外から閉じる|待ち受けを内側に寄せる、またはファイアウォールで止める
外から使われていないと分かったら、まずは外から届かなくするだけにします。サービスは動いたままなので、サーバー内の利用者には影響しません。
- 待ち受けアドレスを内側に寄せる:たとえばMySQLなら設定ファイルの
bind-addressを127.0.0.1にして再起動します。ソフトごとに設定名が違うので、公式ドキュメントで確認してください。 - ファイアウォールで止める:設定ファイルに手を入れたくない場合や、すぐ戻せる形にしたい場合はこちらが手軽です。
SSHで作業しているときは、今つないでいるセッションを1本残したままファイアウォールを触ってください。22番(またはSSHのポート)を許可するルールを先に確認しておけば、自分を締め出す心配がなくなります。SSHそのものの守り方はSSHを安全にする基本にまとめています。
閉じたら、ステップ2の nmap や nc で外から本当に届かなくなったかを確かめます。設定を変えたつもりで反映されていない、はよくあることです。
③ 止める|様子を見てからサービスを無効化する
外から閉じたあと、少なくとも月次の処理が一周するくらいは様子を見ます。問い合わせもエラーも出なければ、サービスを止めて、再起動後に勝手に立ち上がらないようにします。
# 停止して、自動起動も無効にする
sudo systemctl disable --now <サービス名>
# ソケット起動のものはソケットも
sudo systemctl disable --now <名前>.socket
パッケージの削除は、さらに後で大丈夫です。止めてあるだけなら systemctl enable --now で戻せます。いつ・何を・なぜ止めたかは、変更管理台帳のつけ方の形で1行残しておくと、半年後に「これ何で止まってるんだっけ」とならずに済みます。
なお、この作業は本番サーバーの設定に関わります。読み取りのコマンドは安全ですが、設定ファイルやファイアウォールを変える段階では、事前のバックアップと作業記録を忘れずに。コマンドの挙動や設定名はディストリビューション・バージョンで異なるので、手元の環境と公式情報で確かめながら進めてください。
棚卸しをすると、何が変わるか
ポートが数個減っても、見た目には何も変わりません。効いてくるのは、そのあとです。
- パッチの優先順位がつけやすくなる:外から見えているソフトが分かっていれば、脆弱性の情報が出たときに「うちは急ぐべきか」をすぐ判断できます(CVE情報の追いかけ方と優先度のつけ方)。
- 不審なアクセスを見分けやすくなる:入口が少なければ、ログで見るべき場所も少なくなります。
- サーバー移行や引き継ぎで渡せる:作った表は、そのまま構成資料の一部になります(サーバー・サービス構成を1枚にまとめる方法)。
明日やること:内側の一覧を1ファイルに保存する
最初の一歩は、30分あれば終わります。
- サーバーに入って
sudo ss -tulpnを実行し、出力をそのまま日付つきのファイルに保存する(読み取りだけです)。 - Local Address が
0.0.0.0/[::]/*のものに印をつける。 - 印をつけたものについて、
systemctl status <PID>でサービス名を書き添える。 - クラウドなら、管理画面でセキュリティグループの許可ルールを確認して、同じファイルに書き写す。
- 外からの確認と、閉じる作業は翌日以降で大丈夫です。
不要なポート・サービス棚卸しチェックリスト
上から順に、確認できたものにチェックを入れてください。
-
ss -tulpnで待ち受け中のポートを一覧にしたか -
0.0.0.0と[::](IPv6)の両方を確認したか - 正体の分からないPIDを、サービス名までたどったか
-
systemctl list-socketsでソケット起動のものを確認したか - サーバー内のファイアウォール設定を読んだか
- クラウドのセキュリティグループも確認したか
- Dockerで公開しているポートを確認したか
- 社外の回線から、自分の管理するサーバーに対してだけ外部確認をしたか
- 1ポート1行の表にして「使っている人」の欄を埋めたか(空欄は次に調べる印として残す)
- 閉じる前に、接続元を何回か確かめたか
- SSHのセッションを1本残したまま、ファイアウォールを変更したか
- 閉じたあと、外から本当に届かないかを確かめたか
- 止めたものを、日付と理由つきで記録したか
全部そろわなくても構いません。ひとつでも「このポートは何のためにあるか」が分かれば、その分だけ守る範囲ははっきりしています。
よければ、こちらも
棚卸しの前後にやると効くものを置いておきます。
- cron・常駐プロセスの棚卸し手順:ポートを開いていない常駐プロセスや定期処理も、同じ表の考え方で洗い出せます。
- 管理画面のアクセス制限|IP制限とBasic認証の基本と使い分け:閉じられないけれど外に見せたくない入口の守り方。
- セキュリティパッチ適用の進め方|壊さず一人で回す手順:残した入口のソフトを、最新に保つために。
- EOL棚卸しの手順|サポート切れのOS・ミドルを一人で洗い出す:待ち受けているソフトのサポート期限も、あわせて確認しておくと安心です。

知らない入口を抱えたまま守るのは、鍵の数が分からない家の戸締まりをするようなものです。どこを確かめればいいか分からないから、いつも少しだけ落ち着かない。
その入口を開けたのは、あなたではありません。でも、数えて、名前をつけて、必要なものだけ残すことはできます。今日は ss -tulpn を1回打って、保存するところまで。それだけで、このサーバーの戸締まりは、あなたの目で確かめられるものになり始めています。
ほかの実務ヒントは記事一覧からどうぞ。保守運用の小さな備えを、メールでも少しずつお届けしています。