【図解】ウェルノウンポート主要一覧|18年プロが教えるポート設計の極意

「サーバー構築で80や443を開けたけれど、他のポート番号ってどこまで把握しておくべき?」
「パラメータシート(詳細設計書)を作成する際、ポート設定で気をつけるべきポイントは?」
こんにちは、大手SIerで18年間インフラマネージャーを務めている「もっち」です。
インフラエンジニアとして単なる「作業者」から「設計者」へとステップアップする際、必ず向き合うことになるのがポート設計(ウェルノウンポートの理解)です。
この記事では、ウェルノウンポートの基本概念から、実務でそのまま使える設計メモ付きの主要ポート一覧、さらには18年の現場経験から辿り着いた「パラメータシート作成・ポート設計でハマらないための極意」までを網羅して解説します。
この記事の想定読者
- ウェルノウンポートの基礎と主要番号を整理したいエンジニア
- パラメータシート作成やFW設計で迷う若手インフラエンジニア
- Linuxの特権ポート制限やポート設計の基本を学びたい運用者
この記事を読むことでのメリット
- 頻出ウェルノウンポートの用途と設計時の注意点が一覧で学べる
- パラメータシートにそのまま活かせる実践的なポート設計が学べる
3分でわかる!ウェルノウンポートの基本
ウェルノウンポートとは?
ウェルノウンポート(Well-Known Ports)とは、インターネット上で提供される主要なネットワークサービス(HTTP、HTTPS、SSHなど)のために、IANA(インターネット割当公社)によってあらかじめ予約されている「0 〜 1023番」のポート番号のことです。

例えるなら、サーバーという大きなビルにおける「定常的な案内窓口の番号」です。
- サーバー側(ウェルノウンポート): 「Webサイトの案内は443番窓口へどうぞ」と固定しておく
- クライアント側(エフェメラルポート): 問い合わせに訪れたPCが一時的な整理券番号(例: 51234番)を発行して通信する
ポート番号の3つの分類
ポート番号(0〜65535)は、以下の3つの領域に分類されています。
| 分類 | ポート範囲 | 主な用途・特徴 | 代表例 |
| ウェルノウンポート (Well-Known Ports) | 0 〜 1023 | 定番サービス(サーバー側)用に予約された領域 | HTTP (80) HTTPS (443) SSH (22) |
| 登録ポート (Registered Ports) | 1024 〜 49151 | 特定のアプリケーションやベンダー用に登録された領域 | MySQL (3306) PostgreSQL (5432) RDP (3389) |
| エフェメラルポート (Dynamic / Private Ports) | 49152 〜 65535 | クライアント側が通信時に動的利用する使い捨て領域 | 通信毎にOSが自動割り当て |
💡 エフェメラルポートとの「対(ペア)」の関係
通信が行われる際は、この2つのポートが必ずセット(送信元エフェメラルポート ➔ 宛先ウェルノウンポート)で指定されます。
クライアント側が使う動的ポート(エフェメラルポート)の動作仕様や、枯渇トラブル対策については以下の記事で詳しく解説しています。

【保存版】実務で使える!主要ウェルノウンポート網羅一覧
現場でパラメータシートを作成する際や、FW(ファイアウォール)のアクセスコントロールリスト(ACL)を設計する際に役立つ一覧表です。単なる名称だけでなく「設計時の注意点(設計メモ)」を添えています。
💡 ヒント: パラメータシート作成時や障害調査の際は、キーボードの Ctrl + F(Macは Cmd + F)でページ内検索を行うと、目的のポート番号やプロトコルを即座に探せます。
※実務で頻出する代表的な「登録ポート(RDPなど)」も比較対象として一部掲載しています。
Web・リモート接続・ファイル転送
| ポート | L4 | サービス名 | 標準用途 | 特権 | 設計メモ・FW設定時の注意点 |
| 20 / 21 | TCP | FTP | ファイル転送(20:データ / 21:制御) | ○ | 平文通信のため新規設計での採用は非推奨。PASVモード時のポート開放範囲に注意。 |
| 22 | TCP | SSH / SFTP | 暗号化リモート接続 / ファイル転送 | ○ | 送信元IPは管理元(踏み台サーバーや社内NW)に必ず制限する。 |
| 23 | TCP | Telnet | 平文リモート接続 | ○ | 原則使用禁止。ネットワーク機器の疎通確認テスト等でのみ一時利用。 |
| 80 | TCP | HTTP | Web通信(暗号化なし) | ○ | 原則、HTTPS(443)へのリダイレクト用としてのみ開放を検討する。 |
| 443 | TCP | HTTPS | 暗号化Web通信 | ○ | Webサーバー設計の標準。TLS証明書の適用と cipher suite の選定が必須。 |
| 3389 | TCP | RDP | Windowsリモートデスクトップ (※登録ポート) | – | インターネットへの直接公開は厳禁。VPN経由やBastion(踏み台)経由に制限。 |
名前解決・時刻・ネットワークインフラ
| ポート | L4 | サービス名 | 標準用途 | 特権 | 設計メモ・FW設定時の注意点 |
| 53 | UDP/TCP | DNS | 名前解決 | ○ | 通常問い合わせはUDP。ゾーン転送や512byte超のパケットはTCPを使用。 |
| 67 / 68 | UDP | DHCP | IPアドレス自動割り当て (67:Server / 68:Client) | ○ | L2ブロードキャスト通信を利用するため、ルーターを越える場合はDHCPリレー設定が必要。 |
| 69 | UDP | TFTP | 簡易ファイル転送 | ○ | 認証機能がない。ネットワーク機器のファームウェア更新やバックアップ時のみ一時許可。 |
| 123 | UDP | NTP | 時刻同期 | ○ | 時刻ズレはログ解析や認証(Kerberos等)に致命的。内部NTPサーバーの設計が必須。 |
| 161 / 162 | UDP | SNMP | 機器監視(161:Polling / 162:Trap) | ○ | SNMPv1/v2cのコミュニティ名初期値(public/private)は変更必須。基本はSNMPv3を推奨。 |
| 514 | UDP/TCP | Syslog | システムログ転送 | ○ | ログサーバーへの集約用。UDPは不達時の再送がないため、信頼性重視ならTCP/TLS化を検討。 |
メール・ディレクトリサービス
| ポート | L4 | サービス名 | 標準用途 | 特権 | 設計メモ・FW設定時の注意点 |
| 25 | TCP | SMTP | サーバー間メール送信 | ○ | 外部プロバイダの「Outbound Port 25 Blocking (OP25B)」に注意。 |
| 110 | TCP | POP3 | メール受信(平文) | ○ | 平文のため非推奨。暗号化された POP3S (995) を使用する。 |
| 143 | TCP | IMAP | メール受信・同期(平文) | ○ | 平文のため非推奨。暗号化された IMAPS (993) を使用する。 |
| 389 | TCP/UDP | LDAP | ディレクトリサービス | ○ | Active Directory等の認証連携用。暗号化された LDAPS (636) を推奨。 |
| 587 | TCP | Submission | メール送信(クライアント用) | ○ | AUTH(ユーザー認証)とSTARTTLS(暗号化)を組み合わせた送信ポート。 |

📘 単なる暗記を卒業!「パケットの挙動からポートを語れるプロ」になる1冊
ポート番号を丸暗記するだけでなく、TCP/IPの基本構造やパケットのやり取りまで正確に理解しておくと、現場でのトラブルシューティング速度が劇的に変わります。
実務で一生使える体系的知識を身につけたい方は、インフラエンジニアのバイブルでもあるこちらの定番書を手元に置いておくのがおすすめです。
【深掘り】プロトコル(TCP/UDP)使い分けの理由
パラメータシートを作成する際、ポート番号だけでなく「TCPかUDPか」を正確に定義する必要があります。代表的なウェルノウンポートの使い分けの背景を押さえておきましょう。
なぜDNS(53番)はUDPとTCPの両方を使うのか?
- 通常時の名前解決(UDP): パケットサイズが小さく(512バイト以下)、レスポンス速度と軽量さを優先するためUDPを使用します。
- ゾーン転送・DNSSEC(TCP): サーバー間で大量のレコード情報を転送する場合(512バイト超)や、確実にデータを届ける必要がある場合はTCPに切り替わります。
NTP(123番)やDHCP(67/68番)がUDPを使う理由
- NTP: ネットワークの遅延(オーバーヘッド)を極力減らし、精度の高い時刻同期を行うために、軽量なUDPが採用されています。
- DHCP: IPアドレスが決まっていない状態(リンクアップ直後)でブロードキャスト送信を行うため、コネクション確立を前提とするTCPは使用できません。
【18年の現場知見】特権ポート制限と「ポート設計・運用」3つの極意
18年間のインフラ構築・運用マネジメントの現場で実際に起きたトラブルをもとに、作業者から設計者へ脱却するためのポイントを解説します。
極意①:Linuxにおける「特権ポート(Privileged Ports)」の罠
Linux OSでは、1024未満のポート(ウェルノウンポート)は「root権限」を持つプロセスしかListen(待機)できないというセキュリティ仕様(特権ポート)があります。
現場でよくあるトラブル
「Webアプリケーション(Node.jsやPython等)をセキュリティの観点から一般ユーザーで起動したら、80番ポートで起動できずエラーになった」
# 一般ユーザーで80番ポートを使おうとした際のエラー例
Error: listen EACCES: permission denied 0.0.0.0:80
設計者としての正しい対処法
- リバースプロキシ(Nginx / Apache)を挟む: 80/443受信用にNginx等をrootで起動し、バックエンドのアプリには1024以上のポート(例: 8080)で転送する(推奨)。
- ケーパビリティ(
CAP_NET_BIND_SERVICE)の付与: Linuxの機能で、特定バイナリに対して非rootでも1024未満のポートをバインドできるよう権限を付与する。
💡 「動かない…」を防ぐ!自分だけの検証用サーバーを持とう
「非rootユーザーで80番ポートが開かない挙動」や「Nginxのリバースプロキシ設定」などは、実際にLinux環境を操作して手を動かすのが一番の近道です。
月額数百円から即座に作成できるクラウド・VPSを活用して、本番環境を汚さない自分専用の実験場を用意しておきましょう。

極意②:22番(SSH)のポート変更はセキュリティ対策になるか?
パラメータシートの作成時に「セキュリティを高めるために、SSHのポート番号を22から 10022 に変更する」という設計を見かけることがあります。
- 効果: 機械的・無差別に行われるポートスキャンやブルートフォース攻撃(総当たり攻撃)のログノイズを減らす効果(Security by Obscurity)はある。
- 限界: ポートスキャンツール(Nmap等)を使われれば変更先のポートは即座に判明するため、根本的な防御にはならない。
現場における本質的なセキュリティ設計
単なるポート変更に頼るのではなく、以下の「多層防御」をパラメータシートに定義するのが上流エンジニアの設計です。
- 送信元IPアドレスの制限: セキュリティグループやFirewallで、許可されたIP(社内NW・踏み台サーバー)以外からの22番アクセスを完全に遮断する。
- パスワード認証の廃止: 鍵認証(公開鍵暗号)のみを許可する。
- SSM(AWS Systems Manager)等の活用: クラウド環境ではそもそも22番ポートを開けず、Session Manager経由で接続する構成をとる。
極意③:パラメータシート作成時のFW最小権限原則と「通信の向き」
パラメータシート(ポート定義書)を作成する際は、必ず「通信の方向(送信元 ➔ 宛先)」と「最小権限原則(必要なものだけ開ける)」を徹底します。
- Inbound(受信): どのIPから、どのポート(例: 443)宛ての通信を許可するか
- Outbound(送信): サーバーから外部へ向かう不要な通信(例: 意図しない外部への22番送信等)が制限されているか
「とりあえずAny(全許可)で開けておく」という設計は、万が一サーバーが踏み台にされた際の被害を拡大させる原因になります。
本サイトでは、ポート設計を含め、実務でそのまま使えるパラメータシートの項目や書き方・レビューのコツについては、以下の記事で詳しくまとめています。

まとめ:ポート設計をマスターして設計者へステップアップしよう
ウェルノウンポート(0〜1023番)は、インフラエンジニアにとって「知っていて当たり前」の基礎知識ですが、実務の設計・運用でどう扱うかまで理解して初めて「作業者からの脱却」が果たせます。
- ウェルノウンポートは0〜1023番の予約領域(サーバー側のサービス窓口)
- 1024未満はLinuxの特権ポート(一般ユーザー起動でのバインドエラーに注意)
- ポート変更だけに頼らず、IP制限・鍵認証・最小権限のFW設計を徹底する
構築手順書通りに作業するフェーズを抜け出し、パラメータシートに意図を持ったポート設計を落とし込めるプロを目指していきましょう。
🚀 運用保守から「設計・構築フェーズ」へ本気でステップアップしたい方へ
「構築や設計などの上流工程に挑戦したいけれど、今の現場では単純作業ばかりでスキルが身につかない…」とお悩みの方は、一度インフラ専門のエージェントで自分の市場価値や選択肢を確認してみるのがおすすめです。
18年目の現役インフラマネージャー目線で、未経験・若手向けエージェントの評判や活用法を徹底検証した以下の記事もあわせて参考にしてみてください。







