ポートスキャン対策の要点は、スキャンそのものを止めることではなく、「スキャンされても見えるのは必要なポートだけ」という状態を作ることです。そのためには、自分のサーバーが外からどう見えているかを nmap で確認し、不要なサービスを止めるか内部向けに限定し、ファイアウォールで既定拒否にします。この記事では、nmap の基本的な使い方と結果の読み方、サーバー内部からの確認方法、ポートを閉じる手順、スキャンの検知方法を説明します。
はじめに：スキャンは自分の管理する機器だけに
nmap は広く使われている正当な管理ツールですが、他人のサーバーに許可なくスキャンを行うと、相手の利用規約違反や業務妨害を問われたり、契約しているクラウドや回線事業者の規約に反したりするおそれがあります。スキャンするのは、自分が管理しているサーバーか、書面などで許可を得た対象だけにしてください。
練習用には、Nmap プロジェクトが試験用に公開している scanme.nmap.org があります。軽いスキャンに限って使うよう案内されているので、大量のスキャンや繰り返しの実行は避けます。
nmapのインストール
主要な Linux ディストリビューションでは、パッケージマネージャーで導入できます。Windows と macOS 向けには公式サイトでインストーラーが配布されています。
# Debian / Ubuntu
sudo apt install nmap
# RHEL / AlmaLinux / Rocky Linux など
sudo dnf install nmap
# バージョンの確認
nmap --version収録されているバージョンはディストリビューションによって異なり、オプションの細かな挙動が変わることもあります（2026年10月現在）。手元の nmap --help や公式のマニュアルもあわせて確認してください。
基本的なスキャンの方法
確認したいサーバーの外側（自宅の PC や別のサーバーなど）から実行します。サーバー自身の中から自分に向けてスキャンすると、ファイアウォールの効果が見えないためです。
# よく使われる上位1000ポートをスキャン（既定の動作）
nmap example.com
# 全TCPポート（1〜65535）をスキャン
nmap -p- example.com
# 特定のポートだけ
nmap -p 22,80,443,3306 example.com
# 開いているポートで動いているサービスとバージョンを推定
nmap -sV -p 22,80,443 example.com
# ping に応答しないホストも、生きているとみなしてスキャン
nmap -Pn example.com
# 結果をファイルに保存
nmap -p- -oN scan-result.txt example.comroot 権限で実行すると、既定で SYN スキャン（-sS）になります。接続を最後まで確立しないため速く、相手のアプリケーションのログに残りにくい方法です。一般ユーザーで実行すると、通常の TCP 接続を行う -sT になります。どちらでも、開いているかどうかの判定には大きな差はありません。
UDP のサービス（DNS や NTP など）を確認するには -sU を使いますが、UDP のスキャンは応答が少ないため時間がかかります。sudo nmap -sU --top-ports 50 example.com のように範囲を絞るのが現実的です。
スキャン結果の読み方
nmap は各ポートの状態を次のように表示します。
- open：サービスが接続を受け付けている。意図したものかどうかを確認する対象です
- closed：ポートには届くが、待ち受けているサービスがない。ファイアウォールで遮断されていないことも意味します
- filtered：ファイアウォールなどで応答が遮られ、判定できない。外部に公開しないポートとしては望ましい状態です
- open|filtered：開いているか遮断されているか区別できない。UDP のスキャンでよく出ます
結果を見たら、open のポートを一つずつ「これは外部に公開する必要があるか」で判断します。Web サーバーなら 80 と 443、管理用に SSH の 22（または変更したポート）が一般的で、それ以外が open になっていれば理由を調べます。特に、MySQL・MariaDB（3306）、PostgreSQL（5432）、Redis（6379）、Memcached（11211）、Elasticsearch（9200）などのデータベースやキャッシュが外から見えている場合は、早めの対処が必要です。
サーバー内部から待ち受けポートを確認する
外からのスキャンとあわせて、サーバー内部で「どのプロセスが、どのアドレスで待ち受けているか」を確認します。
# TCP と UDP の待ち受けポートと、そのプロセスを表示
sudo ss -tulpn出力の Local Address:Port が 0.0.0.0:3306 や [::]:3306 なら、すべてのネットワークインターフェースで待ち受けています。127.0.0.1:3306 なら、サーバー内部からしか接続できません。同じサーバー内の WordPress からしか使わないデータベースなら、後者にするのが基本です。
不要なポートを閉じる手順
開いているポートを減らすには、上から順に次の方法を検討します。
- 使っていないサービスを止める：
sudo systemctl disable --now サービス名で停止と自動起動の無効化を行います。止める前に、そのサービスに依存している処理がないか確認してください。 - 待ち受けるアドレスを内部に限る：MySQL や MariaDB なら設定ファイルの
bind-address = 127.0.0.1、Redis ならbind 127.0.0.1のように指定します。設定ファイルの場所はディストリビューションとバージョンで異なります。変更後はサービスを再起動し、ss -tulpnで反映を確認します。 - ファイアウォールで既定拒否にする：必要なポートだけを許可し、それ以外は受け付けない設定にします。
# ufw の例（SSHを許可してから有効化する）
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verboseリモートで作業しているときは、SSH のポートを許可する前に有効化すると接続が切れて戻れなくなります。クラウドのコンソール接続など、締め出されたときの復旧手段を確認してから作業してください。
クラウドのサーバーでは、OS のファイアウォールに加えて、セキュリティグループなどの事業者側のファイアウォールも設定できます。両方で絞っておくと、片方の設定ミスを補えます。
Dockerのポート公開に注意する
見落としやすいのが Docker です。docker run -p 6379:6379 のようにポートを公開すると、Docker が iptables のルールを直接追加するため、ufw で拒否していても外部から接続できてしまうことがあります。
内部でだけ使うコンテナは -p 127.0.0.1:6379:6379 のようにアドレスを指定して公開するか、ポートを公開せず Docker のネットワーク内だけで通信させます。Docker を使っているサーバーでは、ufw の設定を確認するだけで安心せず、外から nmap でスキャンして実際に閉じているかを確かめてください。
スキャンを検知する方法
インターネットに公開されたサーバーは、日常的に多数のスキャンを受けています。すべてに反応する必要はありませんが、傾向を把握したい場合は次の方法があります。
- ファイアウォールのログ：ufw なら
sudo ufw logging onで拒否した通信が記録されます。ログの量が増えるので、ディスク容量に注意します - IDS（侵入検知システム）：Suricata や Snort などのネットワーク型 IDS を使うと、スキャンのパターンを検知して通知できます
- ログイン試行の遮断：スキャンの後に続く SSH などへの総当たりは、fail2ban でログをもとに送信元を一時的に遮断できます
SSH のポート番号を変える方法は、自動スキャンによるログの量を減らす効果はありますが、ポートを探す攻撃者には見つかります。鍵認証の利用やパスワード認証の無効化といった対策の代わりにはならない点を押さえておきましょう。
まとめ
- nmap でのスキャンは、自分が管理しているか、許可を得た対象だけに行う
- 外からは
nmap -p-などで全ポートを、内部からはss -tulpnで待ち受けアドレスを確認する - open のポートは一つずつ必要性を判断し、データベースやキャッシュは 127.0.0.1 で待ち受ける
- 不要なサービスの停止、待ち受けアドレスの限定、ファイアウォールの既定拒否の順に対策する
- Docker で公開したポートは ufw をすり抜けることがあるため、外からのスキャンで確かめる
- 検知にはファイアウォールのログや IDS を使い、SSH のポート変更は補助的な対策と考える