📠

Linuxの特権ポートと主要サービスのポート番号まとめ

に公開
Linux
インフラ
UNIX
サーバー
バックエンド
tech

LinuxやUNIX系OSでネットワークアプリを開発・運用する際、ポート番号の仕組みを理解しておくと安全かつスムーズにデプロイできます。本記事では「特権ポートとは何か」「なぜ制限されているのか」「主要サービスのポート番号」を整理します。

1. ポート番号とは

  • ポート番号はTCP/UDP通信でアプリケーションを識別する番号（0〜65535）
  • IPアドレス + ポート番号で1台のサーバー上で複数のサービスを区別できる
  • 例:
    • 192.168.0.10:80 → HTTPサーバー
    • 192.168.0.10:443 → HTTPSサーバー
    • 192.168.0.10:5432 → PostgreSQL

2. 特権ポート（0〜1023）とは

基本ルール

  • 0〜1023番は「特権ポート（Privileged Ports）」と呼ばれる
  • rootユーザーまたはCAP_NET_BIND_SERVICE capabilityを持つプロセスでしか使えない
  • 一般ユーザーがbind()しようとするとPermission deniedエラーになる
# 一般ユーザーで80番ポートを使おうとすると
$ python3 -m http.server 80
Traceback (most recent call last):
  ...
PermissionError: [Errno 13] Permission denied

3. なぜ特権ポートは制限されているのか

歴史的背景：信頼性の担保

1970年代、UNIXが開発された当初、ネットワーク上のサーバーはマルチユーザー環境で共有されていました。この環境で問題になったのが**「なりすまし」**です。

具体的な攻撃シナリオ（制限がない場合）

例：悪意あるユーザーがSSHサーバーになりすます

  1. 正規のSSHサーバー（ポート22）が動いている
  2. 管理者が一時的にSSHサーバーを停止
  3. 悪意あるユーザーAが自分のプログラムをポート22で起動
  4. 他のユーザーBがSSH接続しようとする
  5. ユーザーBのパスワードが悪意あるユーザーAに盗まれる

特権ポート制限による防御

  • 0〜1023番はroot以外使えないことで、上記のなりすましを防止
  • クライアント側は「ポート22で動いているサーバー = 管理者が起動した正規のSSHサーバー」と信頼できる
  • 重要なサービス（SSH、HTTP、メールなど）を不正なプログラムから守る

現代での意義

現代では他のセキュリティ機構（暗号化、証明書）が主流ですが、基本的な防御層として今も機能しています。

4. 代表的な特権ポート

ポート サービス 説明
20/21 FTP ファイル転送（データ/制御）
22 SSH 暗号化されたリモート接続
23 Telnet 平文リモート接続（非推奨）
25 SMTP メール送信
53 DNS ドメイン名解決
80 HTTP Web通信（暗号化なし）
110 POP3 メール受信
143 IMAP メール受信（高機能版）
443 HTTPS Web通信（暗号化あり）
993 IMAPS IMAP over SSL/TLS
995 POP3S POP3 over SSL/TLS

これらはIANA（Internet Assigned Numbers Authority）によって公式に割り当てられています。

5. データベースのポート番号

多くのデータベースは1024番以上の非特権ポートを使うため、一般ユーザー権限でも起動できます。

データベース ポート番号 由来・理由
PostgreSQL 5432 IANAに登録済み。開発者が選んだ番号で特に語呂合わせ等はない
MySQL/MariaDB 3306 IANAに登録済み。MySQL AB社が取得した番号
MongoDB 27017 開発チームが選んだ番号。IANAには未登録だが事実上の標準
Redis 6379 開発者の遊び心。「MERZ」を電話のキーパッド（6=MNO, 3=DEF, 7=PQRS, 9=WXYZ）で数字に変換
Oracle DB 1521 IANAに登録済み（SQL*Net）。Oracle社が取得した番号
SQL Server 1433 IANAに登録済み。Microsoft社が取得した番号
Elasticsearch 9200 開発チームが選んだ番号。9200-9300番台を使用
Cassandra 9042 IANAに未登録だが、Apache Cassandraのデフォルト

Node.js/開発サーバーでよく使われるポート

用途 ポート番号 理由
Node.js開発サーバー 3000 Express.jsのデフォルト。覚えやすく、他サービスと衝突しにくい
React開発サーバー 3000 Create React Appのデフォルト
Next.js 3000 デフォルト設定
Vue.js (Vite) 5173 Viteの新デフォルト（旧版は8080）
Angular 4200 Angular CLIのデフォルト
Rails開発サーバー 3000 Ruby on Railsのデフォルト

ポート番号の決め方

特権ポート（0-1023）: IANAが厳格に管理し、標準プロトコルに割り当て

非特権ポート（1024-65535）:

  • 1024-49151（登録済みポート）: IANAに申請すれば登録可能。PostgreSQL、MySQLなどはここに登録済み
  • 49152-65535（動的ポート）: 自由に使える範囲

慣習か公式か

  • PostgreSQL（5432）: IANA登録済みの公式番号。開発者が空いている番号を選んで申請した
  • MySQL（3306）: IANA登録済みの公式番号。MySQL AB社が取得
  • Redis（6379）: 慣習。「MERZ」という文字を電話キーパッドで数字変換した遊び心
  • MongoDB（27017）: 慣習。IANAに未登録だが、デファクトスタンダード化
  • Node.js系（3000）: 慣習。Express.jsが2010年頃に選んだ番号が広まった。覚えやすく、他と被りにくい

つまり「IANA登録済みの公式」と「事実上の慣習」が混在しています。

なぜNode.js系は3000番を使うのか

ポート3000は、特定のプロトコルで必須ではなく、単なる慣習です。Ruby on Railsなどのフレームワークがデフォルトとしたことで広まり、Node.js、React、その他のエコシステムへと引き継がれました。

  1. 覚えやすい: 1024番以下は通常システムレベルのサービス用に予約されており（HTTPはポート80）、開発者は衝突を避けつつ覚えやすい番号が必要でした。3000番はその条件に完璧に適合しました
  2. Rails → Node.jsへの流れ: Rails開発サーバーはデフォルトで3000番を使用し、後にExpress.js、React、Next.jsなどが踏襲
  3. 業界標準化: ドキュメント、チュートリアル、ボイラープレート、CLIツールがデフォルトとして採用し、開発者も追随。今では筋肉記憶になっています

ソース:

6. 非rootユーザーで特権ポートを使う方法

本番環境でアプリを特権ポート（80/443）で動かす方法は複数ありますが、推奨度が異なります。

方法1: リバースプロキシ経由（最も推奨）

[外部] → [Nginx:80/443(root)] → [アプリ:8080(非root)]
  • Nginx/HAProxyなどをrootで起動して80/443を受け取る
  • アプリは非rootで8080などの高いポートで動作
  • 本番環境での事実上の標準

メリット:

  • SSL終端、gzip圧縮、負荷分散をNginxに任せられる
  • アプリコードがシンプルになる
  • セキュリティ上も最も安全（アプリに証明書へのアクセス権を与えない）
  • パフォーマンスが向上（NginxはNode.jsよりSSL/gzip処理が高速）

ソース: Why should I use a Reverse Proxy if Node.js is Production-Ready?

方法2: capabilitiesを付与（限定的な用途）

# バイナリにcapabilityを付与
sudo setcap cap_net_bind_service=+ep /usr/bin/myapp

# 確認
getcap /usr/bin/myapp

用途: 小規模な環境や、リバースプロキシを使えない特殊なケース

方法3: systemdでAmbientCapabilitiesを使用（方法2の改善版）

[Service]
User=appuser
AmbientCapabilities=CAP_NET_BIND_SERVICE
ExecStart=/usr/bin/myapp

用途: systemd環境での非rootユーザー実行

実際の推奨事項

Node.jsは本番環境で動作可能ですが、Node.jsプロセスを直接Webに公開すべきではなく、リバースプロキシの背後に隠すべきです。理由は以下の通りです:

  1. SSL証明書管理: 証明書をコードベースにチェックインするのは面倒でセキュリティリスクがあり、リバースプロキシでSSL終端を行う方が良い
  2. パフォーマンス: NginxでSSL終端を行うと約16%、gzip圧縮では約50%のスループット向上
  3. コードの簡潔性: アプリはビジネスロジックに集中でき、プロトコルやプロセス管理を忘れられる

つまり、capabilitiesは技術的には可能だが、本番環境ではリバースプロキシが圧倒的に推奨されるというのが正確です。

7. 参考資料・ソース

公式ドキュメント

ポート番号の由来

  • Redisのポート6379の由来:
    • 電話キーパッドで「MERZ」（イタリアの歌手Alessia Merzの名前）を数字に変換したもの。Redis作者antirezと友人の間でのジョーク
  • Node.js/Express.jsのポート3000:
    • 特権ポートを避け、覚えやすく実験しやすい番号として選ばれた
    • Ruby on Railsで普及し、後にNode.jsエコシステムでも広く採用された

8. まとめ

  • 0〜1023番（特権ポート）: root権限が必要、重要サービスのなりすまし防止
  • 1024〜65535番（非特権ポート）: 一般ユーザーでも自由に使用可能
  • 特権ポート制限の理由: マルチユーザー環境での信頼性担保、なりすまし防止
  • データベース: 非特権ポートを使うため一般ユーザーで起動可能
  • 非root運用: capabilities、systemd、リバースプロキシなどで実現可能

モダンな運用では、アプリケーションは非rootユーザーで動かし、必要に応じてリバースプロキシやcapabilitiesを使うのが基本です。

Discussion