ポート番号リファレンス

TCPポート0は、ポート番号空間の中で予約されている値であり、公開サービスが通常待ち受けるためのポートではありません。実際のネットワークサービスを、クライアントが接続する固定ポートとして0番で公開するべきではありません。

ソケットプログラミングでは、port 0にbindすることに特別な意味があります。アプリケーションが0番ポートで待ち受けたいという意味ではなく、利用可能なローカルポートをOSに自動で選ばせるという意味です。bindに成功すると、実際に割り当てられたポート番号をシステムから取得できます。

この使い方は、自動テスト、ローカル開発ツール、一時的なHTTPサービス、RPCのテストプロセス、E2Eテスト環境、ポート衝突を避けたいプログラムなどでよく使われます。

ポートスキャナーがTCPポート0をopenとして表示した場合は、慎重に確認してください。多くの場合、それは実際の業務サービスではなく、スキャナー表示上のアーティファクト、特殊なプローブへの応答、ファイアウォールやプロキシの挙動、デバイスファームウェアの問題、または低レベルのネットワークスタックが特殊ポートのプローブに反応しているだけの可能性があります。

調査時は、ss、netstat、lsof、コンテナのポートマッピング、システムログ、ファイアウォールルールなどを使って、ホスト上で実際に待ち受けているソケットを確認してください。port 0で本当に待ち受けているプロセスが存在しない場合は、実際に公開された業務上の攻撃面として扱うべきではありません。

TCPポート1は、tcpmux、つまりTCP Port Service Multiplexerに割り当てられています。初期のインターネットプロトコル設計に由来するもので、固定の入口から他のTCPサービスを問い合わせたり接続したりするために想定されていました。

現代の本番環境では、tcpmuxが主流のサービスディスカバリ機構として使われることはほとんどありません。現在は、DNS、ロードバランサー、サービスレジストリ、Kubernetes Service、Consul、ZooKeeper、クラウドプラットフォームのサービスディレクトリなどが一般的です。

スキャンでポート1が開いている場合は、通常の業務サービスだと決めつけず、実際の待ち受けプロセスと応答内容をまず確認してください。古いシステム、特殊用途のデバイス、設定ミス、ハニーポット、レガシーサービス、またはスキャナーのフィンガープリント誤判定である可能性の方が高いです。

このポートは、公開向けの業務入口には適していません。明確な依存関係がない場合は閉じるべきです。レガシーな依存が残っている場合でも、許可する送信元を制限し、なぜ利用し続ける必要があるのかを文書化してください。

調査時は、システムサービス、プロセス起動パラメーター、コンテナのポートマッピング、ファイアウォールルール、資産の所有者を確認し、意図せず低価値な攻撃面を公開していないか見直してください。

TCPポート20は、FTPのアクティブモードで使われるデータ接続用ポートです。FTPは制御接続とデータ接続を分けており、ポート21がログイン、コマンド、応答を扱う一方、ポート20は主にアクティブモードでファイル内容やディレクトリ一覧を転送するために使われます。

すべてのFTP転送でポート20が使われるわけではありません。通常はアクティブモードで、サーバーが自身のローカルポート20から、クライアントが指定したデータポートへ接続する場合に関係します。パッシブモードでは向きが逆になり、クライアントがサーバー側で開かれたパッシブポート範囲へ接続します。

アクティブモードFTPは、ファイアウォール、NAT、クラウドのセキュリティグループ、コンテナネットワークと相性が悪いことがあります。サーバーからクライアントへデータ接続を開始するためです。典型的な症状はFTPログインはできるが、ディレクトリ一覧やファイル転送に失敗するです。

FTP転送失敗を調査するときは、ポート20と21だけを確認して終わらせないでください。アクティブモードかパッシブモードか、パッシブポート範囲が許可されているか、NATマッピングが正しいか、クライアント側またはサーバー側のファイアウォールがデータ接続を遮断していないかを確認してください。

平文FTPは、ユーザー名、パスワード、ファイル内容を暗号化せずに送ることが多いです。公開ネットワーク、機密ファイル、自動配布、本番ワークフローでは、SFTP、FTPS、HTTPSによるアップロード・ダウンロード、オブジェクトストレージの署名付きURL、または制御された内部ファイル交換サービスの方が安全です。

TCPポート21は、FTPの制御接続用ポートです。クライアントがポート21へ接続すると、この接続はユーザーログイン、パスワード認証、ディレクトリ移動、ファイル一覧要求、アップロード・ダウンロードのコマンド、削除、リネームなどの制御操作に使われます。

FTPの重要な特徴は、制御接続とデータ接続が分かれていることです。ポート21はコマンドを送る応答を受け取るための接続であり、実際のファイル内容やディレクトリ一覧は別のデータ接続で転送されます。

アクティブモードでは、データ接続は通常TCPポート20に関係します。パッシブモードでは、サーバーがパッシブポート範囲を開き、クライアントがそのいずれかへ接続します。そのため、ポート21に到達できることは制御チャネルが動いていることを示すだけで、ファイル転送が成功する保証にはなりません。

FTPの問題では、ログインは成功するが、ディレクトリ一覧やファイル転送に失敗するという症状がよくあります。これはポート21自体の問題ではなく、データ接続がファイアウォール、NAT、クラウドのセキュリティグループ、コンテナネットワーク、ロードバランサー、またはFTPのパッシブポート設定ミスで遮断されていることが多いです。

FTPは、レガシーシステムのファイル交換、ベンダーとのバッチ転送、産業機器のログエクスポート、ネットワーク機器の設定バックアップなどで今でも見かけます。ただし、平文FTPは認証情報や内容を暗号化せずに送信します。公開環境や機密性の高い場面では、SFTP、FTPS、HTTPSベースのファイルサービス、またはオブジェクトストレージのワークフローを優先してください。

TCPポート22はSSHの標準ポートであり、Linux、Unix、ネットワーク機器、クラウドホスト、開発マシン、運用環境で最もよく見かけるリモート管理入口のひとつです。

SSHは、暗号化されたリモートログイン、コマンド実行、ポートフォワーディング、踏み台アクセス、自動化に使われます。また、SFTPやGit over SSHもよくこの上で動きます。SFTPはSSHプロトコル上でファイルを転送し、Git over SSHはSSH鍵を使ってリポジトリ認証、fetch、pull、pushを行います。

ポート22をインターネットへ公開することが必ず間違いとは限りませんが、ほぼ確実にスキャン、総当たり、パスワードスプレーの対象になります。本番環境ではrootのパスワードログインを無効化し、鍵、証明書、またはMFAを優先し、送信元IP制限、踏み台サーバー、VPN、Fail2ban、ログイン監査、最小権限アカウントを組み合わせるべきです。

SSHを別のポートへ移すだけでは、本質的なセキュリティ対策にはなりません。カスタムポートは標準ポートへの雑なスキャンを多少減らすことはありますが、重要なのは認証強度、送信元制限、パッチ適用、権限境界、監査可能性です。

SSH接続失敗を調査するときは、sshdが動いているか、待ち受けポートが2222などのカスタムポートに変更されていないか、ファイアウォールやクラウドのセキュリティグループが接続を許可しているか、ユーザー名が正しいか、秘密鍵ファイルの権限が適切か、サーバー側でパスワードログインが無効化されていないか、社内ネットワークが外向きSSHをブロックしていないかを確認してください。

TCPポート23はTelnetの標準ポートです。Telnetは初期のリモート端末プロトコルで、クライアントがリモート機器へ接続し、コマンドを入力し、出力を確認しながら端末のようにシステムを操作できます。

Telnetの大きな問題は、現代的な暗号化を備えていないことです。ユーザー名、パスワード、入力したコマンド、応答内容が平文で送られることが多く、共有LAN、侵害されたゲートウェイ、プロキシ機器、信頼できないWi-Fiなど、通信経路を観測できる相手に見られる可能性があります。

現代の本番サーバーでTelnetを使うべき場面はほとんどありません。古いスイッチ、ルーター、シリアルコンソールサーバー、カメラ、組み込み機器、産業制御機器、研修用ラボ、一時的なプロトコル検証環境などで見つかることが多いです。

スキャンでポート23が開いている場合は、まずデフォルトの機器管理インターフェースなのか、レガシーサービスなのか、誤って有効化されたデバッグポートなのかを確認してください。Telnetの公開は高リスクです。一般的な対応としては、サービスの無効化、SSHへの移行、管理ネットワークやVPNへの限定、デフォルトアカウント・弱いパスワード・古いファームウェアの確認が必要です。

TCPポート25は、従来のSMTPメール転送ポートです。主にメールサーバー同士の配送に使われます。たとえば送信側メールサーバーは、宛先ドメインのMXレコードを調べ、その宛先メールサーバーへポート25でメッセージを配送しようとします。

ポート25は、通常のメールクライアントがメールを送信するための推奨ポートではありません。ユーザー、Webサイト、業務システムが認証済みアカウントで送信メールを投入する場合は、認証とSTARTTLSを使う587番がよく使われます。465番は暗黙的TLSによるメール送信用として一般的です。

多くのクラウドプロバイダー、ホスティング会社、ISPは、スパム送信に悪用されやすいため、外向きポート25をデフォルトで制限しています。自前のメールサーバーから外部へ送信できない場合は、SMTPサービスそのものだけでなく、プロバイダー側のポート制限、解除申請の要否、サーバーIPの迷惑メール評価も確認してください。

信頼できるメール配送には、ポート到達性だけでは不十分です。自前メールサーバーには、正しいMXレコード、PTR逆引きDNS、SPF、DKIM、DMARC、TLS、ホスト名設定、キューの再試行動作、バウンス処理も必要です。これらが不十分だと、ポート25が開いていても、メールが拒否されたり、遅延したり、迷惑メール扱いされたりします。

TCPポート53は標準的なDNSポートのひとつですが、UDP 53と役割が完全に同じではありません。通常のDNS問い合わせではUDP 53が優先されることが多く、応答が大きすぎる場合、UDP応答が切り詰められた場合、DNSSECを使っている場合、より信頼性の高い転送が必要な場合に、リゾルバーがTCP 53へフォールバックすることがあります。

TCP 53は、権威DNSサーバー間のゾーン転送にもよく使われます。たとえばAXFRやIXFRです。ゾーン転送はプライマリDNSとセカンダリDNSの同期には便利ですが、送信元制限が正しく設定されていないと、DNSゾーン全体を権限のない相手に公開してしまう可能性があります。

DNSのトラブルシューティングでは、UDP 53だけを確認してはいけません。大きなTXTレコード、メール関連レコード、DNSSEC応答、大量のレコードセット、複雑な企業DNS環境では、TCP 53がファイアウォールやセキュリティ機器で遮断されていると断続的な失敗が起こることがあります。

権威DNSサーバーでは、正当な問い合わせのためにTCP 53をインターネットから到達可能にする必要がある場合があります。ただし、ゾーン転送は信頼できるセカンダリサーバーに限定すべきです。再帰リゾルバーの場合は、TCP 53をすべての公開送信元へ開放するべきではありません。オープンリゾルバーは不要な問い合わせ、プライバシー露出、DNS増幅攻撃経路に悪用される可能性があります。

UDPポート53は、最も一般的なDNS問い合わせポートです。ブラウザ、OS、再帰リゾルバー、多くのアプリケーションは、A、AAAA、CNAME、MX、TXTなどのレコードを問い合わせるために通常このポートを使います。

UDPによるDNS問い合わせは軽量で高速なため、多くの短い応答に適しています。応答が大きすぎる場合、UDP応答が切り詰められた場合、DNSSECが有効な場合、またはより信頼性の高い配送が必要な場合には、クライアントやリゾルバーがTCP 53へ切り替えることがあります。

DNSサービスは、権威DNSなのか再帰リゾルバーなのかを分けて理解する必要があります。権威DNSサーバーは、自分が管理するゾーンに対して公開問い合わせへ応答することがあります。一方、再帰リゾルバーはすべての公開送信元へ開放すべきではありません。オープンリゾルバーは増幅攻撃、不要な問い合わせ転送、DNS挙動の調査に悪用される可能性があります。

DNSの問題を調査するときは、単にポート53が開いているかだけを見ないでください。UDPとTCPの両方が使えるか、クライアントが実際にどのリゾルバーを使っているか、キャッシュ状態、DNSSECによる応答サイズ増加、ファイアウォールやセキュリティ機器がDNSトラフィックの一部を遮断していないかを確認してください。

UDPポート67はDHCPサーバーが使用します。クライアントが初めてネットワークへ参加し、まだ利用可能なIPアドレスを持っていない場合、DHCPを通じてネットワーク設定を要求します。サーバーはポート67でその要求を受け取り、IPアドレス、サブネットマスク、デフォルトゲートウェイ、DNSサーバー、リース期間などを返します。

DHCPはネットワーク初期化の早い段階で動作します。典型的な流れはDiscover、Offer、Request、Ackです。クライアントは通常UDP 68を使い、サーバーはUDP 67を使います。クライアントがまだ完全なネットワーク設定を持っていないため、この処理はブロードキャスト通信やDHCPリレー転送に依存することがよくあります。

ポート67は通常、ルーター、L3スイッチ、ゲートウェイ、企業DHCPサーバー、PXEブート環境、プライベートクラウドネットワーク、管理されたオフィスネットワーク上にだけ現れるべきです。公開向けの業務サービス用ポートではなく、インターネットへ直接公開すべきではありません。

不正なDHCPサーバー、いわゆるrogue DHCP serverがネットワークに現れると、クライアントが誤ったゲートウェイ、誤ったDNSサーバー、不正なサブネットを受け取ったり、攻撃者が制御する経路へ誘導されたりする可能性があります。IP割り当て失敗、想定外のゲートウェイ、DNS異常、多数のクライアントの突然の切断を調査するときは、複数のDHCPサーバーが同時に応答していないか確認してください。

UDPポート68はDHCPクライアントが使用します。端末が初めてネットワークに参加したとき、まだ利用可能なIPアドレスを持っておらず、通常のアプリケーションのようにゲートウェイやDNSサーバーへアクセスできない場合があります。クライアントはDHCPでネットワーク設定を要求し、DHCPサーバーからポート68でリース情報を受け取ります。

DHCPのクライアントポートとサーバーポートは対になっています。サーバーはUDP 67を使い、クライアントはUDP 68を使います。典型的なやり取りは、クライアントがDiscoverをブロードキャストし、サーバーがOfferを返し、クライアントがRequestを送り、サーバーがAckを返す流れです。これにより、クライアントはIPアドレス、サブネットマスク、デフォルトゲートウェイ、DNSサーバー、リース期間を受け取ります。

ポート68は公開アプリケーション用のサービスポートではありません。ホストがネットワークへ参加するときに使う基本的なネットワーク初期化ポートです。ノートPC、スマートフォン、仮想マシン、コンテナホスト、PXEブート環境、オフィスネットワーク、クラウドインスタンス初期化、自動アドレス取得を行う機器でよく見られます。

クライアントがIPアドレスを取得できない、誤ったゲートウェイ・DNSサーバー・サブネットを受け取る場合、問題は通常、アプリケーションがポート68で待ち受けているかどうかではありません。DHCPブロードキャストがサーバーに届いていない、DHCPリレー設定が誤っている、VLANが一致していない、ネットワーク上に不正なDHCPサーバーがある、またはセキュリティポリシーがUDP 67/68を遮断している可能性があります。

UDPポート69はTFTP、つまりTrivial File Transfer Protocolの標準ポートです。TFTPは非常に軽量なファイル転送プロトコルで、PXEネットワークブート、スイッチやルーターの設定バックアップ、組み込み機器のファームウェア配布、ディスクレスブート、自動プロビジョニング、制御された内部デプロイ作業などでよく使われます。

TFTPはFTPやSFTPとは異なります。複雑なディレクトリ操作、ユーザーログイン、細かい権限モデルを備えておらず、プロトコル自体にも暗号化はありません。クライアントは通常、特定のファイルを読み取るか書き込むだけで、サーバー側はroot directory、ファイル権限、アクセスルールに基づいて、そのファイルを返すか受け付けるかを判断します。

TFTPは仕組みが単純なため、機器の初期起動やブートストラップ処理で便利です。たとえばクライアントがDHCPでIPアドレスを取得した後、TFTPを使ってbootloader、kernel、設定ファイル、インストールイメージをダウンロードすることがあります。このため、PXEや機器プロビジョニング環境では、UDP 69がUDP 67やUDP 68と一緒に現れることがよくあります。

本番環境では、TFTPは制御された内部ネットワーク、デプロイ用ネットワーク、管理ネットワークに限定すべきです。インターネットへ直接公開するべきではありません。また、機密設定、アカウントファイル、鍵、バックアップ、書き込み可能なディレクトリを広くアクセス可能なTFTPサービス配下に置くと、設定漏えい、ファームウェア改ざん、不正なファイル取得につながる可能性があります。

TCPポート80はHTTPの標準ポートです。ユーザーがhttp://example.comのようにポート番号を指定せずにアクセスすると、ブラウザは通常ポート80へ接続します。

現代の本番環境では、ログイン、決済、Cookie、token、個人情報などの機密データを長時間HTTPのまま扱うべきではありません。よくある構成は、ポート80で平文HTTPリクエストを受け付け、301または308リダイレクトでポート443のHTTPSへ転送する形です。

それでもポート80は広く使われ続けています。HTTPからHTTPSへのリダイレクト、ロードバランサーのヘルスチェック、リバースプロキシからオリジンへの通信、ACME HTTP-01による証明書検証、一時的なWebサービス、内部ステータスページなど、互換性や入口としての役割があるためです。

ポート80をインターネットへ公開すること自体が必ず高リスクというわけではありません。ただし、その背後で動いている実際のサービスは確認が必要です。管理画面、デバッグページ、ディレクトリ一覧、暗号化されていないログインフォーム、内部API、デフォルトvirtual host、フレームワークのエラーページが露出していないか確認してください。

ポート80へのアクセス問題を調査するときは、Webサービスが待ち受けているか、Nginx、Apache、Caddy、Ingressルールが有効か、ファイアウォールやクラウドのセキュリティグループが通信を許可しているか、ロードバランサーが正しいバックエンドへ転送しているか、サイトが443だけを設定してHTTP入口を残していないかを確認してください。

TCPポート88は、Kerberos認証で使われる標準ポートのひとつです。Active Directory、企業のシングルサインオン、ドメインログオン、サービスチケット取得のワークフローでよく見られます。

KerberosはUDPとTCPのどちらも使えます。通常はUDPが使われる場合がありますが、チケットが大きい、UDP応答が切り詰められる、ネットワークポリシー上信頼性のある転送が必要、ネットワークをまたいだ認証が不安定といった場合に、TCP 88へフォールバックすることがあります。

Windowsドメイン環境では、Kerberosは単独で完結するわけではありません。完全なドメインログオンやサービスアクセスの流れでは、DNS、NTP、LDAP、SMB、Global Catalogなどにも依存することが多いため、TCP 88だけを許可してもドメイン認証が正しく動くとは限りません。

このポートはID基盤の一部であり、インターネットへ直接公開すべきではありません。公開されていると、アカウント列挙、ドメイン情報の調査、パスワードスプレー、認証サービスのプロービング、後続の横展開に役立つ偵察につながる可能性があります。

Kerberos over TCPの問題を調査するときは、ドメインコントローラーに到達できるか、DNSが正しいドメインコントローラーを解決しているか、クライアントとドメインコントローラーの時刻が同期しているか、SPNが正しいか、チケットが大きすぎないか、UDPがブロックされていないか、関連するActive Directoryポートがファイアウォールで許可されているかを確認してください。

UDPポート88は、Kerberos認証で使われる標準ポートのひとつです。Windows Active Directory、企業のシングルサインオン、ドメインログオン、サービスチケット取得フローでよく使われます。

Kerberosの基本的な考え方は、ユーザーのパスワードを各サービスへ直接送らないことです。代わりにKDCがチケットを発行します。クライアントはまずTGTを取得し、その後サービスチケットを使ってファイル共有、データベース、HTTPサービス、その他Kerberos対応システムへアクセスします。

Kerberosは時刻に非常に敏感です。クライアント、ドメインコントローラー、アプリケーションサーバーの時刻が大きくずれていると認証に失敗するため、NTPやドメイン時刻同期はKerberos環境の重要な依存関係です。

UDP 88は比較的小さな認証交換に適していますが、チケットが大きい、グループ所属が多い、応答が切り詰められる、ネットワーク機器がUDPをうまく扱えない場合には、クライアントがTCP 88へ切り替えることがあります。認証失敗時はTCPとUDPの両方を確認してください。

UDP 88をインターネットへ自由に公開すべきではありません。これはID基盤への入口であり、不適切な公開はアカウント列挙、ドメイン情報の調査、パスワードスプレー、認証サービススキャンの攻撃面を広げます。

TCPポート110は、従来のPOP3メール受信用ポートです。このポートへ接続すると、メールクライアントはメールボックスサーバーからメッセージを読み取り、ダウンロードできます。

POP3はメールをローカル端末へ取得することを中心に設計されています。クライアントは、ダウンロード後もサーバーにコピーを残すことも、サーバー上のメッセージを削除することもできます。そのため、単一端末でのメール利用、オフライン閲覧、シンプルなアーカイブ、古いメールクライアントでよく使われてきました。

既読状態、フォルダー、下書き、移動済みメッセージ、削除操作をスマートフォン、PC、Webメール間で同期したい場合は、POP3よりIMAPの方が適していることが多いです。従来のIMAPはポート143を使い、暗号化されたIMAPは一般的にポート993を使います。

ポート110は通常、暗号化されていないPOP3を示します。ユーザー名、パスワード、メール本文がネットワーク上を平文で流れる可能性があります。本番環境でPOP3を提供し続ける場合は、ポート995のPOP3Sを優先するか、ポート110のセッションをSTARTTLSで暗号化するべきです。

メール受信トラブルを調査するときは、まず受信と送信を分けて考えてください。POP3はメール受信用で、SMTPの25、465、587は送信用です。送信はできるが受信できない場合は、POP3/POP3Sサービス、アカウント権限、TLS設定、ファイアウォールルール、メールサーバーログを確認してください。

TCPポート111は、rpcbindまたはportmapperでよく使われます。これはファイル転送サービスそのものではなく、クライアントが特定のRPCプログラムが現在どのポートで利用可能かを問い合わせてから、実際のサービスへ接続するためのRPCサービスディレクトリとして動作します。

NFS、mountd、lockd、statdなどの従来のUnix/Linuxネットワークサービスは、rpcbindを使ってポートを登録・発見することがあります。特にNFSv3環境では、ポート111、ポート2049、複数の動的ポートをまとめて確認する必要があります。

このポートは、Linux/Unixのファイル共有、NAS、バックアップシステム、仮想化基盤、レガシークラスター、内部ストレージマウントでよく見られます。通常は内部インフラ用ポートであり、公開向けの業務入口ではありません。

TCP 111がインターネットへ公開されていると、外部スキャナーがホストに登録されているRPCサービスを列挙し、NFS、mountd、その他の内部サービスが存在するかを推測できる可能性があります。実際のデータポートが公開されていない場合でも、rpcbindは有用なサービス情報を漏らすことがあります。

NFSやRPCアクセスの失敗を調査するときは、rpcbindが起動しているか、対象サービスが正しく登録されているか、ポート2049へ到達できるか、mountd、lockd、statdのポートがファイアウォールで遮断されていないか、サーバーのexportルールが現在のクライアントを許可しているかを確認してください。

UDPポート111は、rpcbindまたはportmapperが、特定のRPCサービスが現在どのポートに登録されているかをクライアントへ知らせるために使います。ファイルやアプリケーションデータを直接運ぶというより、RPCエコシステムにおけるサービスディレクトリのような役割です。

レガシーなNFSやONC RPC環境では、クライアントがまずUDP 111へ問い合わせ、プログラム番号、バージョン、実際のポートを確認してから、対象のデータサービスへ接続することがあります。ポート2049中心のNFSv4と比べると、NFSv3ではmountd、lockd、statdなど追加サービスが関わることがよくあります。

UDP 111は通常、信頼済みの内部ネットワーク、ストレージネットワーク、バックアップネットワーク、管理ネットワーク上にだけ存在するべきです。公開向けの通信経路から到達できる状態には適していません。

UDP 111がインターネットへ公開されていると、攻撃者がRPCサービスを列挙し、NFSやストレージ関連コンポーネントの存在、ホストの用途、内部サービス構成を推測できる可能性があります。UDPベースであるため、不要なスキャン、反射、異常なプローブ通信を呼び込むこともあります。

レガシーNFSのマウント失敗を調査するときは、ポート2049だけを確認しないでください。rpcbindが応答しているか、NFSバージョンがv3か、mountdなどの動的ポートが固定化されファイアウォールで許可されているか、クライアント送信元がexportsルールで許可されているか、関連するTCP/UDPトラフィックが通るかを確認してください。

UDPポート123はNTP、つまりNetwork Time Protocolの標準ポートです。サーバー、ネットワーク機器、仮想マシン、コンテナホスト、端末が、信頼できる時刻源と時計を同期するために使います。

正確な時刻は、多くのシステム動作の土台です。TLS証明書の検証、ログの時系列、データベースレプリケーション、分散ロック、スケジュールジョブ、監査記録、監視アラート、インシデント調査は、安定したシステム時刻に依存しています。

企業環境では、各ホストが直接公開NTPサーバーへ問い合わせるのではなく、管理された内部時刻源、ドメインコントローラー、クラウドプロバイダーの時刻サービス、専用NTPサーバーへ同期する構成が一般的です。

UDP 123は信頼できるクライアント向けに公開されることがありますが、保護されていない公開NTPサービスを安易に運用すべきではありません。設定の甘いNTPサーバーは、過去に反射増幅攻撃へ悪用されてきました。公開時刻サービスでは、アクセス制限、危険なレガシークエリの無効化、異常トラフィックの監視が必要です。

時刻同期の問題を調査するときは、ポート123が開いているかだけを見ないでください。ホストがchrony、ntpd、systemd-timesyncd、Windows Time、クラウドプロバイダーの時刻サービスのどれを使っているかを確認し、上流時刻源、clock offset、ネットワーク到達性、ファイアウォールポリシーも確認してください。

TCPポート135は、Microsoft RPC Endpoint Mapperの標準ポートです。Windows RPCエコシステムにおけるサービスディレクトリのように動作し、クライアントはまずポート135へ接続して、特定のRPCインターフェースが現在どのポートで利用可能かを問い合わせ、その後実際の動的サービスポートへ接続します。

DCOM、WMI、リモートサービス管理、イベントログアクセス、一部のドメイン管理ツール、バックアップソフトウェア、企業向け運用プラットフォームなど、多くのWindows管理機能が間接的にこのポートへ依存することがあります。ポート135自体が最終的な業務サービスというより、後続のRPCアクセスを見つける入口です。

このポートは、Windowsドメイン、企業内部ネットワーク、サーバー管理ネットワーク、レガシーWindowsアプリケーション連携でよく見られます。通常は信頼済みの内部ネットワークや管理境界内だけで開くべきで、インターネットへ直接公開すべきではありません。

ポート135の公開は高リスクです。外部スキャナーはこれを使ってWindows RPC機能、システムの役割、後続の動的RPCサービスを推測し、リモート管理系の攻撃面を広げ、横展開の手がかりを得る可能性があります。

WMI、DCOM、リモート管理をネットワークセグメント越しに使う必要がある場合は、VPN、踏み台サーバー、プライベートリンク、管理ネットワーク、厳格なファイアウォール許可リストを経由させるべきです。139、445、3389、Windows RPC動的ポート範囲などの関連ポートもあわせて確認してください。

UDPポート137は、NetBIOS Name Serviceで使われます。主にレガシーなWindowsローカルネットワークで、NetBIOSホスト名をIPアドレスへ解決するために使われます。

現代的なDNS、Active Directory、集中管理された名前解決が整っていない古い環境では、NetBIOS名前サービスがワークグループ、ホスト名、ファイル共有サーバー、LAN内リソースの検出に使われていました。UDP 138、TCP 139、TCP 445のSMBと一緒に現れることがよくあります。

UDP 137は、ホスト名、ワークグループ名、ドメイン環境の手がかり、ログイン中ユーザーの痕跡、内部命名規則を漏らす可能性があります。ファイル内容を直接提供するわけではありませんが、スキャナーがWindows資産の種類やネットワーク構造を推測する材料になります。

このポートは通常、管理された内部ネットワーク、レガシーシステムを支える必要があるオフィスネットワーク、古いNAS、プリンター、レガシー機器環境にだけ存在するべきです。すでにDNS、Active Directory、SMB over TCP 445を使う現代的なWindowsネットワークでは、NetBIOS over TCP/IPを無効化または厳しく制限できることが多いです。

公開スキャンでUDP 137が開いている場合は、Windowsホスト、NAS、プリンター、ルーター、レガシー機器がローカル名前サービスをインターネットへ誤って公開していないか確認し、ファイアウォールで137、138、139を信頼済み内部ネットワークに限定してください。

UDPポート138は、NetBIOS Datagram Serviceで使われます。レガシーなWindows LAN通信モデルに属し、主にコネクションレスなデータグラムメッセージ、ワークグループのブラウズ、リソース検出、ローカルブロードキャスト通知に使われます。

このポートは単独で現れることはあまりありません。レガシーなWindowsファイル共有環境では、NetBIOS名前サービスのUDP 137、NetBIOSセッションサービスのTCP 139、現代的なSMBのTCP 445と一緒に見つかることが多いです。

UDP 138は、主に管理されたローカルネットワーク内で意味を持ちます。公開アプリケーションの入口ではなく、インターネット越しに公開すべきではありません。公開されていると、ホスト名、ワークグループ、ブラウズリスト、ファイル共有の手がかり、Windowsネットワーク構成の情報が漏れる可能性があります。

現代的なWindowsファイル共有は、NetBIOS over TCP/IPよりもTCP 445上のSMBを使うことが一般的です。レガシーシステム、古いNAS、プリンター、産業機器との互換性が不要であれば、NetBIOS over TCP/IPを無効化できる場合があります。

公開スキャンでUDP 138が見つかった場合は、Windowsホスト、NAS、プリンター、ルーター、レガシー機器がNetBIOSサービスを誤って公開していないか確認し、ファイアウォールで137、138、139を信頼済み内部ネットワークに限定してください。

TCPポート139は、NetBIOS Session Serviceで使われます。レガシーなWindowsネットワーク通信のセッションチャネルを提供し、特にSMB over NetBIOSによるファイル共有と深く関係しています。

以前のWindows LANでは、UDP 137が名前解決、UDP 138がデータグラムやブラウズ通知、TCP 139がファイル共有通信のセッション確立を担っていました。この構成では、ポート139がレガシーなWindowsファイル共有の実質的な対話セッションの入口になります。

現代のWindowsファイル共有では、NetBIOS over TCP/IPに依存せず、TCP 445上でSMBを直接使う構成が一般的です。ただし、古いシステム、古いNAS、プリンター、産業機器、レガシーWindowsホスト、混在したオフィスネットワークをサポートする必要がある環境では、ポート139が残っていることがあります。

TCP 139の公開は高リスクです。ファイル共有サービス、ホスト情報、レガシー認証面、共有列挙、プロトコル互換性の問題を外部へ見せる可能性があります。セキュリティスキャナーでは、139と445はWindowsファイル共有の主要な攻撃面として一緒に扱われることがよくあります。

明確なレガシー互換性の要件がない場合は、NetBIOS over TCP/IPを無効化するか、少なくとも137、138、139を信頼済み内部ネットワークに限定してください。ファイル共有が必要な場合は、匿名アクセス、guestアカウント、共有権限、NTFS権限、SMBバージョン、パッチ状況を確認してください。

TCPポート143は、IMAP、つまりInternet Message Access Protocolの従来のポートです。メールクライアントがIMAPサービスへ接続すると、サーバー上のメッセージを閲覧、検索、移動、削除、整理できます。

IMAPはPOP3とは利用モデルが異なります。POP3はメールをローカル端末へダウンロードすることに重点がありますが、IMAPはメールボックスをサーバー上で管理する設計のため、スマートフォン、PC、Webメールを同時に使う環境に向いています。

IMAPでは、既読状態、フォルダー、下書き、送信済みメール、削除、メッセージ移動などを複数端末間で同期できます。そのため、企業メールや現代的なメールクライアントでは、POP3だけに依存するよりIMAPが選ばれることが多いです。

TCP 143は従来のIMAP入口です。平文で使われることもありますが、STARTTLSで暗号化接続へアップグレードする構成もあります。本番環境では、ユーザー名、パスワード、メール本文を長期的に平文で流すべきではありません。対応している場合は、TCP 993のIMAPSを優先するのが一般的です。

IMAPの問題を調査するときは、まずメール受信・管理とメール送信を分けて考えてください。IMAPはメールボックスの閲覧や管理に使われ、SMTPの25、465、587はメール送信に使われます。受信はできるが送信できない、またはその逆の場合は、IMAPとSMTPのサービス、アカウント権限、TLS設定、ファイアウォールルール、メールサーバーログを別々に確認してください。

UDPポート161は、SNMP、つまりSimple Network Management Protocolの標準問い合わせポートです。監視システムはこのポートを使って、スイッチ、ルーター、ファイアウォール、サーバー、UPS、プリンター、ストレージ機器、データセンター設備などから状態情報を読み取ります。

SNMPは、インターフェースのトラフィック、ポート状態、CPU、メモリ、ディスク使用量、温度、電源、ファン、エラーカウンター、機器モデル、システム名、稼働時間など、幅広い情報を公開できます。運用には便利ですが、攻撃者にとっては資産列挙や偵察の入口にもなり得ます。

SNMP v1とv2cでは、community stringがアクセス資格情報として使われることが一般的です。publicやprivateのようなデフォルト値は特に危険です。community stringが弱い、権限が広すぎる、またはインターネットから到達可能な場合、外部から内部機器の詳細情報を読み取られたり、構成によっては状態を変更されたりする可能性があります。

本番環境では、認証と暗号化を有効にしたSNMPv3を優先してください。v1またはv2cを使わざるを得ない場合は、強いcommunity string、読み取り専用権限、送信元IP許可リスト、監視ネットワーク・管理ネットワーク・信頼済み内部ネットワークへの限定が必要です。

公開スキャンでUDP 161が開いている場合は、誤って公開されたネットワーク機器、プリンター、UPS、NAS、サーバー監視エージェントがないか確認し、community string、ACL、機器ファームウェア、ファイアウォールルールを見直してください。

SNMPメトリクスが取得できない場合は、ポート161への到達性だけでなく、機器側でSNMPが有効か、SNMPバージョンが一致しているか、community stringまたはSNMPv3ユーザーが正しいか、必要なOIDやMIBに対応しているか、ACLが監視サーバーを許可しているかも確認してください。

UDPポート162は、SNMP Trapメッセージで使われます。UDP 161では監視システムが機器へ能動的に問い合わせますが、Trapでは機器側がアラート、状態変化、異常イベントを監視基盤へ自発的に送信します。

SNMP Trapは、ネットワーク機器、サーバー、UPS、ストレージ、ファイアウォール、データセンター設備などが、インターフェースのdown/up、停電、高温、リンク不安定、ディスク障害、認証失敗、機器再起動などを通知するためによく使われます。

ポート162は、通常の業務サービスではなく、監視基盤、Trap receiver、NMS、アラートゲートウェイ側で待ち受けることが多いです。無関係な送信元からの偽装アラートや大量イベント流入を防ぐため、信頼済み機器または制御されたネットワーク範囲からのTrapだけを受け付けるべきです。

Trapは通常UDPで配送されるため、送信側は受信側が実際に処理したかを必ずしも把握できません。アラートが届かない場合は、機器がTrapを送ったかだけでなく、ネットワーク経路、ファイアウォールルール、受信側の待ち受け状態、パースルールも確認してください。

UDP 162がインターネットへ公開されていると、外部から偽のTrapメッセージを送られ、アラート分析を妨害されたり、ノイズを作られたり、監視入口を推測されたりする可能性があります。本番環境では送信元IPを制限し、利用するSNMPバージョンに応じてcommunity、SNMPv3ユーザー、security level、監査ログを適切に設定してください。

Trapが届かない場合は、機器側のTrap送信先アドレス、SNMPバージョン、community stringまたはSNMPv3ユーザー、security level、ルーティング、ファイアウォールルール、NAT経路、監視基盤側のTrap解析テンプレートを確認してください。

TCPポート199は、SNMP Unix Multiplexerとして知られています。歴史的には、Unixシステムや一部のネットワーク機器で、SNMP関連通信を多重化、転送、プロキシするために使われてきました。

SNMP問い合わせで一般的なUDP 161ほど多くは使われません。また、Trap配送用のUDP 162とも異なります。TCP 199が開いている場合は、特定の実装、機器のプロキシ層、または古い監視アーキテクチャの一部として扱ってください。

このポートは、ネットワーク機器、古いUnixシステム、ベンダー製監視エージェント、特殊なSNMPプロキシ経路で見つかることがあります。通常のアプリケーション入口ではなく、公開サービス用ポートとして扱うべきではありません。

監視系ポートは、機器モデル、インターフェース詳細、システム名、稼働時間、ネットワーク構造、インフラ状態を外部へ見せる可能性があります。TCP 199が業務データを直接運ばない場合でも、誤った公開は攻撃者が資産を特定し、内部トポロジーを推測する助けになります。

スキャンでTCP 199が開いている場合は、実際の待ち受けプロセス、機器モデル、ベンダードキュメント、SNMPプロキシ経路への依存有無、アクセスが監視システムまたは管理ネットワークに限定されているかを確認してください。

本番環境では、TCP 199をUDP 161とUDP 162とあわせて管理してください。送信元を制限し、デフォルト資格情報を避け、読み取れる情報を最小化し、ログを有効化し、不要になった関連サービスは無効化してください。

TCPポート389は、LDAP、つまりLightweight Directory Access Protocolの標準ポートです。LDAPは、ディレクトリサービスへアクセスし、ユーザーアカウント、グループ、組織単位、メールアドレス、デバイスオブジェクト、権限属性、アプリケーションが必要とするID情報を問い合わせるためによく使われます。

LDAPは、Microsoft Active Directory、OpenLDAP、FreeIPA、389 Directory Server、集中認証基盤、社内アプリケーションのアカウント基盤など、企業IDシステムの一部として使われることが多いです。アプリケーションはLDAPを使って、ユーザー検索、アカウント検証、組織構造の同期、グループ所属に基づくアクセス判断を行うことがあります。

ポート389は通常、標準LDAPのポートですが、多くの環境ではこのポート上でStartTLSを使い、既存接続をTLSへアップグレードします。もうひとつの一般的な暗号化方式はポート636のLDAPSで、接続開始時点からTLSを使います。

LDAPは通常の公開アプリケーション用ポートではありません。IDディレクトリや組織情報を扱うため、不適切に公開すると、アカウント列挙、組織構造の漏えい、グループ所属の開示、パスワードスプレー、フィッシング、横展開の準備につながる可能性があります。

本番環境では、ポート389は内部ネットワーク、VPN、IDサービスセグメント、信頼済みアプリケーションサーバーに限定してください。匿名bindは無効化し、bindアカウントには最小権限を適用し、必要に応じてStartTLS、送信元制限、監査ログ、ログイン失敗監視を有効にしてください。

LDAP認証が失敗するよくある原因には、bind DNの誤り、search base DNの誤り、filterの不一致、アカウント権限不足、匿名bindの無効化、StartTLSや証明書設定の不備、アプリケーションが誤ったドメインコントローラーやディレクトリサーバーへ接続していることがあります。

TCPポート443はHTTPSの標準ポートです。ユーザーがhttps://example.comのようにポート番号を指定せずにアクセスすると、ブラウザは通常ポート443へ接続します。

HTTPSはTLSで保護されたHTTPです。Webページ、ログインセッション、Cookie、token、決済情報、APIリクエスト、モバイルアプリ通信、Webhook、管理コンソール、ブラウザが読み込むリソースを保護するために使われます。

ポート443は公開入口として使えますが、HTTPSを使っているだけで十分に安全とは限りません。証明書の有効性、TLSバージョン、HSTS、Secure Cookie属性、リバースプロキシによるHostやX-Forwarded-Protoの正しい転送などが、実際のセキュリティ状態に影響します。

現代的なアーキテクチャでは、ポート443上のTLSは、Nginx、Apache、Caddy、Envoy、Traefik、Ingress Controller、CDN、クラウドロードバランサー、API Gatewayなどで終端され、その後バックエンドアプリケーションへ転送されることがよくあります。

ポート443は従来のWebページ以外にも、HTTP/2、TLS上のWebSocket、gRPC、REST API、GraphQL、OAuth callback、SaaSコンソール、オブジェクトストレージのダウンロードリンク、モバイルアプリAPIなどを運びます。443が開いているからといって、単なるWebサイトだと決めつけないでください。

ポート443に到達できない場合のよくある原因には、期限切れ証明書、誤ったDNS向き先、ファイアウォールやセキュリティグループ、ロードバランサーリスナーの設定ミス、SNI不一致、リバースプロキシのルーティングエラー、バックエンドのヘルスチェック失敗があります。

TCPポート445は、SMB、つまりServer Message BlockをTCP上で直接扱うための中心的なポートです。現代のWindowsファイル共有、共有プリンター、ネットワークドライブ、ドメインアクセス、Group Policy関連のアクセス、多くの企業内ファイルサービスで使われます。

ポート445と139は混同されやすいです。139は古いSMB over NetBIOSのセッションポートで、445は現代的なSMB Direct Hostingのポートです。445ではNetBIOS名前解決を必要としません。

SMBでは、共有フォルダーへのアクセス、ファイルの読み書き、共有の列挙、プリンター接続、ドメイン認証や管理ワークフローへの参加ができます。不適切に公開されている場合、単なるファイルダウンロード口ではなく、Windowsファイル共有と横展開の大きな攻撃面になります。

ポート445は長年、スキャナー、ワーム、ランサムウェア、内部ネットワーク攻撃の優先的な標的になってきました。公開SMBは通常かなり高リスクで、弱いパスワード、誤った共有権限、古いSMBプロトコル、未パッチのシステム、匿名アクセスの設定ミスがよく問題になります。

本番環境では、ポート445をインターネットへ直接公開すべきではありません。拠点間や外部からのファイルアクセスが必要な場合は、VPN、専用線、ゼロトラストアクセス、SFTP、HTTPSベースのファイルサービス、オブジェクトストレージ、クラウドのプライベート管理ファイルサービスなどを検討してください。

SMBアクセスの問題を調査するときは、対象ホストでファイル共有が有効か、Windows Firewallルール、共有権限とNTFS権限の両方、SMBバージョン互換性、ドメインまたはアカウント所属、ISP・クラウド基盤・セキュリティ機器がポート445をブロックしていないかを確認してください。

TCPポート465は、暗黙的TLSによるSMTPでよく使われます。クライアントは接続直後にTLSハンドシェイクを行い、その暗号化チャネル内でSMTPセッションを開始します。

465と587はどちらも、ユーザーやアプリケーションがメールを送信するためによく使われますが、TLSの扱いが異なります。465は通常、接続開始直後からTLSを使います。一方、587はSMTPとして開始し、STARTTLSで暗号化接続へアップグレードすることが一般的です。

ポート465を25と混同しないでください。25は主にメールサーバー間配送に使われるポートで、465は認証済みのクライアントやアプリケーションがメールサーバーへ送信メールを投入する場面でよく使われます。

465で送信できない場合は、クライアントがSTARTTLSではなくSSL/TLSとして設定されているか確認してください。あわせて、アカウントのパスワードまたはアプリ専用パスワード、サーバー証明書、外向きファイアウォールルール、プロバイダーのログインポリシー、送信レート制限も確認してください。

465で接続できることは、メールが受信箱へ届くことを保証しません。業務メールの到達性は、SPF、DKIM、DMARC、バウンス処理、送信者レピュテーション、本文品質、受信側の迷惑メール対策にも左右されます。

UDPポート500は、IKE、つまりInternet Key Exchangeで使われる、IPsec VPN接続の重要なネゴシエーションポートです。保護されたIPsec通信を開始する前に、双方はIKEを使って認証方式、暗号アルゴリズム、鍵素材、セキュリティアソシエーションを取り決めます。

IKEは、拠点間VPN、リモートアクセスVPN、ファイアウォールVPN、クラウドVPNゲートウェイ、ルーター間の暗号化トンネルでよく使われます。通常のWebやアプリケーションの入口ではなく、VPNの制御プレーンの一部です。

UDP 500は通常、UDP 4500と一緒に現れます。500は初期のIKEネゴシエーションを扱い、どちらかの側でNATが検出されると、IPsecはNAT TraversalとしてUDP 4500へ切り替わることが一般的です。L2TP/IPsec構成ではUDP 1701も関係することがあります。

IPsec VPNの失敗を調査するときは、ポート500が開いているかだけを確認しないでください。事前共有鍵または証明書、IKEv1/IKEv2の互換性、cipher suite、DH group、peer address、NATの挙動、そしてポート4500にも到達できるかを確認してください。

UDP 500はVPNゲートウェイ上で公開到達可能なことがありますが、これはプライベートネットワークへのセキュリティ入口です。本番環境では、強い事前共有鍵または証明書認証、許可peerの制限、ネゴシエーション失敗ログ、未知の送信元や繰り返し試行の監視が必要です。

TCPポート515は、LPD/LPR印刷プロトコルで使われます。従来のUnix印刷システム、古いネットワークプリンター、プリントサーバー、一部のオフィスネットワーク機器で、印刷ジョブの投入や印刷キュー処理に使われます。

LPD/LPRは、IPPのようなより現代的な印刷プロトコルより古いものです。機能は比較的シンプルで、印刷ジョブの投入、キュー処理、プリントサーバーとの通信に重点があります。現代のオフィス環境では、ポート631のIPPやベンダー固有の印刷プロトコルの方がよく使われる場合があります。

印刷系ポートは通常、オフィスネットワーク、印刷ネットワーク、信頼済み端末に限定すべきです。不適切に公開すると、プリンターモデル、キュー名、内部ホスト名が見えたり、外部から不要な印刷ジョブを投入されて印刷リソースを消費されたりする可能性があります。

ポート515が公開スキャンに出てきた場合は、プリントサーバー、ネットワークプリンター、レガシー互換サービスのどれかを確認してください。ほとんどの場合、印刷サービスを信頼できないネットワークへ直接公開するのではなく、ファイアウォールで制限するべきです。

515経由の印刷を調査するときは、印刷サービスが動作しているか、キュー名が正しいか、クライアントにジョブ投入権限があるか、プリンターがオンラインか、ファイアウォールが通信を許可しているか、IPP・ベンダードライバー・管理されたプリントサーバーの方が適切ではないかを確認してください。

TCPポート587は、標準的なメッセージ送信用ポートです。主にメールクライアント、Webバックエンド、アプリケーションサーバー、自動化ジョブが、自分のメールサーバーへメールを投入するために使います。

587は25とは役割が異なります。25は主にMXレコードに基づくメールサーバー間配送に使われます。一方、587はユーザーやアプリケーションの送信用で、通常は認証が必要です。

587では一般的にSTARTTLSが使われます。クライアントはまずSMTPセッションを開始し、その後STARTTLSコマンドで接続をTLSへアップグレードします。接続確立直後からTLSを開始することが多い465とはこの点が異なります。

587で送信できない場合は、クライアントがSTARTTLSとして設定されているか、パスワードまたはアプリ専用パスワードが正しいか、サーバーが現在の送信元からのログインを許可しているか、外向きファイアウォールが587を許可しているか、メールプロバイダーがレート制限やログイン制限を適用していないかを確認してください。

業務システムにとって、587はあくまで送信投入の入口です。最終的に受信箱へ届くかどうかは、SPF、DKIM、DMARC、バウンス処理、送信者レピュテーション、本文品質、受信側の迷惑メール対策にも左右されます。

TCPポート636は、LDAPS、つまりLDAP over TLSの標準ポートです。クライアントは通常、最初にTLSで保護されたチャネルを確立し、その暗号化接続の中でbind認証、ディレクトリ検索、ID情報の参照を行います。

LDAPSは、Active Directory、OpenLDAP、FreeIPA、389 Directory Server、集中ID基盤、社内アプリケーションのアカウント基盤などでよく使われます。ユーザーアカウント、グループ、メールアドレス、組織構造、権限属性などのディレクトリ情報を通信経路上で保護します。

636と389は混同されやすいポートです。389は標準LDAPポートで、STARTTLSにより暗号化へアップグレードできます。一方、636は接続開始時点からTLSを使います。HTTPSに近い接続モデルだと考えると分かりやすいです。

ポート636はTLSを使いますが、通常の公開エンドポイントとして扱うべきではありません。ディレクトリサービスはID基盤の一部であり、誤って公開すると、アカウント列挙、組織情報の漏えい、グループ探索、パスワードスプレー、フィッシング、横展開の足がかりにつながる可能性があります。

LDAPSの失敗を調査するときは、ドメインコントローラーまたはディレクトリサーバーに正しいサーバー証明書が入っているか、証明書チェーンをクライアントが信頼しているか、証明書名が接続先アドレスと一致しているか、アプリケーションがLDAPSとして設定されているか、ファイアウォールが636を許可しているかを確認してください。

TCPポート853は、DNS over TLS、一般にDoTと呼ばれる方式で使われます。DNS問い合わせをTLSで暗号化されたチャネル内に流すことで、ローカルネットワーク、ISP、中間機器からDNS通信が平文で見られたり改ざんされたりする可能性を下げます。

DoTは、従来のポート53のDNSとは異なります。ポート53のDNSは通常、UDPまたはTCP上の平文でやり取りされます。一方、ポート853では最初にTLS接続を確立し、その暗号化セッション内でDNS問い合わせと応答を送受信します。

ポート853は、公開再帰リゾルバー、企業向け暗号化DNSサービス、プライバシー重視のDNSクライアント、ルーターのDNSフォワーダー、モバイル端末のセキュアDNS設定などでよく使われます。主な用途は再帰名前解決であり、通常のWeb APIや権威DNSのゾーン転送用ポートではありません。

企業ネットワークでは、DoTの利用にあたってプライバシーとガバナンスのバランスが必要です。暗号化DNSは問い合わせ内容を保護しますが、企業のDNSポリシー、悪性ドメインブロック、内部名前解決、コンプライアンスログを回避してしまう可能性もあります。そのため、多くの組織では承認済みDoTリゾルバーの利用を求めます。

DoTはDNS over HTTPSと混同されがちです。DoHは通常443を使い、通常のHTTPS通信に見えやすい一方、DoTは専用の853を使うため、ネットワーク層で識別・管理しやすい特徴があります。

ポート853の問題を調査するときは、クライアントでDNS over TLSが本当に有効になっているか、リゾルバー証明書が信頼されているか、サーバー名が証明書と一致しているか、外向きTCP 853が許可されているか、ファイアウォールが従来の53だけを許可していないかを確認してください。

TCPポート873は、rsync daemonモードの標準ポートです。rsyncは変更されたデータだけを効率よく転送できるため、Linux/Unixサーバー同期、ミラーサイト、ログアーカイブ、設定配布、バックアップ、大容量の差分ファイル転送で広く使われます。

rsyncには混同されやすい2つの利用形態があります。ひとつはSSH上でrsyncを実行する方式で、通常はポート22を使います。もうひとつがrsync daemonモードで、サーバーが直接ポート873で待ち受け、名前付きmoduleを通じてディレクトリを公開します。

rsync daemonでは、公開ディレクトリが1つ以上のmoduleとして整理されます。各moduleには、path、読み取り専用または書き込み許可、認証、アクセス制御、include/excludeルールを設定できます。クライアントは通常、rsync://host/module/path のような形式でアクセスします。

ポート873は制御された同期には便利ですが、安易にインターネットへ公開すべきではありません。設定ミスがあると、外部からmoduleを列挙されたり、バックアップディレクトリ、ソースコード、設定ファイルを取得されたり、書き込み可能なmoduleへ予期しない内容をアップロードされたりする可能性があります。

rsync daemonを外部へ公開する必要がある場合は、送信元アドレスを制限し、読み取り専用moduleを優先し、認証を必須にし、機密パスへの匿名アクセスを避け、バックアップ、鍵、環境ファイル、DB dump、過去世代ディレクトリ、書き込み可能パスを慎重に確認してください。

rsyncの失敗を調査するときは、まず接続がSSHモードなのかdaemonモードなのかを確認してください。SSHモードでは22番、アカウント、鍵を確認します。daemonモードでは873番、rsyncd.conf、module名、hosts allow/deny、ファイルシステム権限、ファイアウォールポリシーを確認します。

TCPポート989は、implicit TLSモードのFTPSで使われるデータ接続ポートで、通常はポート990とセットで理解します。ポート990はログイン、コマンド、セッション制御を扱い、989は暗号化されたファイル内容やディレクトリ一覧の転送に関係します。

FTPSは、FTPと同じく制御接続とデータ接続が分かれています。制御チャネルがTLSで保護されていても、実際のファイル転送には別のデータ接続が必要になるため、ファイアウォール、NAT、ロードバランサー、パッシブポート範囲の設定が転送可否に影響します。

ポート989はFTPの20番と混同されやすいです。20番は従来の平文FTPのアクティブモードデータポートであり、989はimplicit TLS版FTPSのデータチャネルに属します。どちらもデータ転送に関係しますが、前提となるセキュリティモデルが異なります。

実際の構成では、多くのFTPSサーバーが989だけに依存しているわけではありません。データ転送に設定済みのパッシブポート範囲を使うことがよくあります。ログインは成功するのにディレクトリ一覧やファイル転送に失敗する場合、問題は990の制御接続ではなくデータチャネル側にあることが多いです。

本番FTPSでは、アクティブモードとパッシブモードを明確にし、パッシブポート範囲を固定して制限し、信頼できる証明書を使い、匿名アクセスを無効化し、アカウントのディレクトリ権限を制限し、機密ファイルパスを広い送信元範囲へ公開しないようにしてください。

TCPポート990は、implicit TLSモードのFTPSで使われる制御接続ポートです。クライアントが990へ接続すると、通常はまずTLSハンドシェイクを行い、その後、暗号化チャネル内でFTP制御セッションに入り、ログイン情報、ディレクトリ操作、ファイル転送コマンドを送ります。

FTPSとSFTPは同じプロトコルではありません。FTPSは従来のFTPにTLSを追加したもので、制御接続とデータ接続が分かれたモデルを維持します。SFTPはSSH上に構築されたファイル転送プロトコルで、通常はポート22を使います。

ポート990は主にimplicit FTPSを示します。もうひとつの一般的な方式はexplicit FTPSで、クライアントがまず21番へ接続し、AUTH TLSコマンドでセッションをアップグレードします。implicit TLSとexplicit TLSを取り違えると、ハンドシェイク失敗や接続拒否が起こりやすくなります。

FTPSは、ユーザー名、パスワード、機密ファイルに対して平文FTPより安全ですが、FTP由来のデータチャネルの複雑さは残ります。実際のファイル内容やディレクトリ一覧には追加のデータ接続が必要で、989番またはサーバー側で設定されたパッシブポート範囲が関係することがあります。

FTPSでログインはできるのにディレクトリ一覧やファイル転送が失敗する場合は、アクティブ/パッシブモード、パッシブポート範囲、ファイアウォールルール、NATの挙動、ロードバランサーの扱い、TLS証明書、クライアントがFTPSのデータチャネル暗号化に対応しているかを確認してください。

本番利用では、FTPSに信頼できる証明書を使い、匿名アクセスを無効化し、アカウント権限を制限し、明確なパッシブポート範囲を定義し、必要なポートだけを公開してください。新規システムで安全なファイル転送だけが必要な場合は、SFTP、HTTPSアップロード/ダウンロード、オブジェクトストレージの署名付きURLの方が運用しやすいことがあります。

TCPポート993は、IMAPS、つまりIMAP over TLSの標準ポートです。クライアントは通常、まずTLSで暗号化されたチャネルを確立し、その後ログインして、メールの閲覧、フォルダー同期、メッセージ検索、メールボックス管理を行います。

IMAPSは、複数端末でのメールボックス同期に向いています。POP3がローカルへメールをダウンロードするモデルに近いのに対し、IMAPはメールを主にサーバー上に保持し、既読状態、フォルダー、下書き、送信済みメール、移動・削除操作をスマートフォン、PC、Webメール間で同期します。

993と143は混同されやすいポートです。143は従来のIMAPポートで、平文のまま使われる場合も、STARTTLSで暗号化へアップグレードされる場合もあります。993は接続開始時点からTLSを使うため、現代のメールクライアントでは通常こちらが推奨されます。

ポート993はメールの受信・管理用であり、送信用ではありません。ユーザーのメール送信は通常587または465を使い、サーバー間配送は主に25を使います。受信はできるが送信できないまたはその逆の問題では、まずIMAPとSMTPを分けて確認してください。

IMAPSログイン失敗のよくある原因には、メールボックス名やユーザー名形式の誤り、パスワードまたはアプリ専用パスワードの誤り、信頼されていないサーバー証明書、993をimplicit TLSではなくSTARTTLSとして設定していること、対象メールボックスでIMAPが無効化されていること、外向き993がファイアウォールで遮断されていることがあります。

本番メールサービスでは、993をユーザー向けに公開できますが、信頼できる証明書、強い認証、ログイン試行のレート制限、不審ログイン監視、アカウント保護を組み合わせるべきです。メールボックスには確認コード、リセットリンク、業務通知、機密添付ファイルが含まれることが多いため、このポートを低リスク扱いしないでください。

TCPポート995は、POP3S、つまりPOP3 over TLSの標準ポートです。クライアントは通常、まずTLSで暗号化されたチャネルを確立し、その後ログインしてメールボックスからメッセージをダウンロードします。

POP3Sは、メールをローカルへダウンロードするモデルに向いています。多くのクライアントでは、ダウンロード後もサーバーにコピーを残すことも、サーバーから削除することもできます。そのため、単一端末でのメール利用、オフラインアーカイブ、古いメールクライアント、シンプルな受信専用構成でよく使われます。

995と110の関係は、993と143の関係に似ています。995は接続開始時点からTLSを使い、110は従来のPOP3ポートで、平文のまま使われる場合も、対応していればSTARTTLSで暗号化へアップグレードされる場合もあります。

POP3SとIMAPSはどちらも暗号化されたメール受信用ポートですが、提供するワークフローが異なります。995はダウンロード中心で、993は既読状態、フォルダー、下書き、サーバー側メールボックス管理を複数端末で同期する用途に向いています。

ポート995は受信用であり、送信用ではありません。ユーザーのメール送信は通常587または465を使い、サーバー間配送は主に25を使います。トラブルシューティングでは、POP3S、IMAPS、SMTPを別々の経路として扱ってください。

POP3Sログイン失敗のよくある原因には、対象メールボックスでPOP3が無効化されていること、ポートや暗号化方式の設定ミス、ユーザー名形式の不一致、パスワードまたはアプリ専用パスワードの誤り、信頼されていないサーバー証明書、外向き995がファイアウォールで遮断されていることがあります。

TCPポート1080は、SOCKSプロキシで最もよく使われるポートです。SOCKSプロキシは、クライアントから対象サーバーへの接続を中継できます。ブラウザのプロキシ設定、開発時のデバッグ、内部ネットワークへのアクセス、トラフィック転送、クローラー用プロキシプール、リモートアクセス支援などで使われることがあります。

SOCKSプロキシは通常のWebサービスではありません。HTTPのパスやページ内容を解釈するというより、汎用的な接続中継として動作し、クライアントが別のホストやポートへ到達するための経路になります。

ポート1080のリスクは、認証、送信元制限、許可された宛先範囲によって大きく変わります。認証やアクセス制御がない場合、外部の第三者にオープンプロキシとして使われ、通信の悪用、スパムリクエスト、スキャン活動、IPアドレスのブロックリスト入り、ログの汚染、コンプライアンス上の問題につながる可能性があります。

SOCKSプロキシが内部アドレスへ到達できる場合、リスクはさらに高くなります。攻撃者はそれを使って内部サービスを探索したり、外向き通信制御を回避したり、本来プロキシサーバーからしか到達できないリソースへアクセスしたり、実際の送信元を隠したりできる可能性があります。

本番環境では、送信元アドレスを制限し、認証を必須にし、任意の宛先への接続を許可しないようにし、アクセスログを残し、オープンプロキシ化、弱い認証情報、デフォルト設定、異常な悪用トラフィックがないか定期的に確認してください。

ポート1080を調査するときは、本当にSOCKS4/SOCKS5プロキシなのか、単に別アプリケーションが同じポートを使っているだけなのかを確認してください。あわせて、プロキシアカウント、ACL、許可宛先、CONNECT相当のポリシー、ファイアウォールルール、クライアント側のプロキシ設定も確認してください。

UDPポート1194は、OpenVPNでよく使われるデフォルトポートです。OpenVPNはTLSベースのVPNソリューションで、リモートワークアクセス、拠点間接続、クラウド上のプライベートネットワークアクセス、開発・検証環境への入口、企業内部リソースへのアクセスに使われます。

OpenVPNでは、本人確認に証明書が使われることが一般的です。クライアントとサーバーはTLSハンドシェイクを通じて暗号パラメーターを交渉し、その後、ユーザー端末またはリモートネットワークを制御されたプライベートネットワークへ接続する仮想ネットワークトンネルを作成します。

OpenVPNはデフォルトでUDPを使うことが多いです。VPNトンネルの中にはTCP、UDP、その他のアプリケーショントラフィックが流れるため、トンネル全体をTCP上で動かすと、パケットロス時にTCP-over-TCPの性能問題が起こることがあります。ただしOpenVPNはTCPでも構成でき、制限の厳しいネットワークでは443で待ち受ける構成もよく使われます。

OpenVPNをインターネットへ公開することは一般的ですが、それでもプライベートネットワークへの入口です。本番環境では、証明書と鍵の強固な管理、退職者や紛失端末の証明書失効、許可送信元の制限、接続ログ、不審なログイン、繰り返しのハンドシェイク、未知のクライアント試行の監視が必要です。

OpenVPNの接続可否は、1194が開いているかだけでは判断できません。クライアントプロファイル、CA証明書、クライアント証明書、秘密鍵、tls-authまたはtls-crypt設定、ユーザー名・パスワード認証、pushされたルート、サーバー側の転送ルール、クライアントから目的の内部ネットワークへの経路を確認してください。

OpenVPNは、500/4500番のIPsec/IKEや、51820番のWireGuardと比較されることがよくあります。OpenVPNは成熟したエコシステムと広い互換性があり、WireGuardはよりシンプルで高速なことが多く、IPsecはファイアウォール、ルーター、クラウドVPNゲートウェイ間でよく使われます。

TCPポート1433は、Microsoft SQL Serverの既定インスタンスで最も一般的に使われる接続ポートです。アプリケーションサービス、SQL Server Management Studio、レポート基盤、ETLツール、同期ジョブ、業務バックエンドがSQL Serverへ接続する際によく使います。

SQL Serverには既定インスタンスと名前付きインスタンスがあります。既定インスタンスでは1433が使われることが多い一方、名前付きインスタンスでは動的ポートが使われ、クライアントが実際のポートを見つけるためにUDP 1434のSQL Server Browserサービスに依存することがあります。

ポート1433は価値の高いデータベース入口であり、インターネット上で頻繁にスキャンされます。直接公開されている場合、攻撃者はバージョン探索、弱いパスワード、既定アカウント、総当たり、未パッチの脆弱性、設定ミスの悪用を試すことがよくあります。

本番データベースでは、通常1433をインターネットへ直接公開すべきではありません。より安全な構成は、アプリケーションサーバーから内部ネットワーク、VPC、Private Link、VPN、踏み台サーバー、または制御されたデータベース管理ネットワーク経由で接続させる形です。

SQL Server接続失敗の一般的な原因には、サービス停止、TCP/IPが無効、インスタンスが1433で待ち受けていない、ファイアウォールやクラウドのセキュリティグループで遮断されている、接続文字列の誤り、認証モードの不一致、アカウント権限不足、クライアント側の暗号化要件とサーバー証明書設定の不一致があります。

SQL Serverをネットワーク越しに到達可能にする必要がある場合は、最低限、送信元IP許可リスト、強いパスワードまたは統合認証、最小権限アカウント、TLS暗号化、監査ログ、ログイン失敗監視、検証済みのバックアップ・復旧プロセスを整備してください。1433を別ポートへ変えるだけでは、データベース公開リスクの本質的な解決にはなりません。

UDPポート1434は、SQL Server Browserサービスでよく使われます。このポートはデータベースクエリそのものを運ぶわけではなく、SQL Serverの名前付きインスタンスが現在どのTCPポートで待ち受けているかをクライアントへ知らせるために使われます。

SQL Serverの既定インスタンスではTCP 1433が使われることが多い一方、名前付きインスタンスでは動的ポートが使われる場合があります。クライアントがサーバー名とインスタンス名しか知らない場合、まずUDP 1434へ問い合わせて実際の接続ポートを取得することがあります。

ポート1434は、利用可能なインスタンス、インスタンス名、接続の手がかりなど、SQL Serverの探索情報を外部へ見せる可能性があります。SQLクエリを直接実行できるわけではありませんが、公開されているとスキャナーや攻撃者がデータベース資産を特定しやすくなります。

本番環境では、1434は通常、内部ネットワーク、VPC、データベース管理ネットワーク、信頼済みアプリケーションサブネットに限定すべきです。名前付きインスタンスに固定ポートを使わせ、接続文字列でポートを明示できるなら、多くの構成ではSQL Server Browserをクライアントへ公開する必要はありません。

名前付きインスタンスへの接続失敗を調査するときは、SQL Server Browserが動作しているか、UDP 1434がファイアウォールで遮断されていないか、対象インスタンスでTCP/IPが有効か、動的ポートが変わっていないか、クライアントの接続文字列が正しいか、実際のデータポートへ到達できるかを確認してください。

TCPポート1521は、Oracle Database Listenerで最もよく使われる標準ポートです。Oracleクライアント、アプリケーションサーバー、レポート基盤、ETLツール、同期ジョブ、DBAツールは、Listenerを通じて特定のデータベースサービスを見つけて接続します。

Oracle Listenerは、単にデータベースポートを開くだけの存在ではありません。クライアント接続にはservice name、SID、またはconnect descriptorが含まれ、Listenerはその設定に基づいて、適切なデータベースインスタンスまたはサービスへ接続を受け渡します。

ポート1521は価値の高いデータベース入口であり、インターネットへ公開すると大きなリスクがあります。攻撃者はservice nameの列挙、Oracleバージョン探索、アカウント総当たり、過去の脆弱性悪用、弱い認証情報や既定設定の探索を試す可能性があります。

本番データベースでは、通常1521をインターネットへ直接公開すべきではありません。アプリケーションサーバー、踏み台サーバー、VPN、プライベートネットワーク、専用線、またはデータベース管理ネットワークからの接続だけを許可し、最小権限アカウント、監査ログ、送信元制限を組み合わせる構成が安全です。

Oracle接続失敗の一般的な原因には、Listener停止、データベースサービスがListenerへ登録されていない、接続文字列の誤り、service nameとSIDの混同、ファイアウォールやセキュリティグループでの遮断、非互換のクライアントドライバー、アカウントロック、データベースがlocalhostまたは内部アドレスでしか待ち受けていないことがあります。

Oracleへネットワーク越しにアクセスする必要がある場合は、送信元IP許可リスト、強い認証、TLS/TCPS、監査ログ、ログイン失敗監視、検証済みのバックアップ・復旧プロセスを使ってください。標準ポートを変更するだけでは、データベース公開リスクは本質的に下がりません。

UDPポート1701は、L2TP、つまりLayer 2 Tunneling Protocolで使われます。主にPPPセッションをUDPにカプセル化してレイヤー2トンネルを作るためのプロトコルで、従来型のリモートアクセスVPN、ルーターVPN、レガシー互換環境でよく見られます。

L2TP自体は強力な暗号化を提供しません。本番では通常L2TP/IPsecとして構成され、IPsecが認証、暗号化、鍵交渉を担当し、L2TPがトンネルのカプセル化を担当します。1701を開くだけではVPNは安全になりません。IPsec側も正しく構成する必要があります。

L2TP/IPsecでは、UDP 500、UDP 4500、UDP 1701がよく関係します。500はIKEネゴシエーション、4500はNAT越えのためのNAT-T、1701はL2TPトンネルそのものを運びます。

L2TP VPN失敗の一般的な原因には、事前共有鍵の不一致、アカウント認証失敗、IKEポリシーの不一致、NAT-Tが有効にならない、ファイアウォールが1701だけ許可して500や4500を遮断している、クライアント側ネットワークがIPsec関連トラフィックを許可していないことがあります。

L2TP/IPsecは、Windows、macOS、iOSの組み込みVPNクライアント、ルーター、古い企業ネットワークで今でも見かけますが、新規構成ではOpenVPN、WireGuard、IKEv2、ゼロトラストアクセスへ置き換えられることも増えています。

1701の公開は、明確なVPNゲートウェイ用途に限定し、強い認証、送信元制限、監査ログ、異常接続の監視と組み合わせてください。汎用的な低リスクUDPサービスとして扱うべきではありません。

TCPポート1723は、PPTPの制御接続で使われます。PPTPは古いVPNプロトコルで、Windows、ルーター、レガシーな企業ネットワークで広く対応していたため、以前は簡単に構成できるVPN方式としてよく使われていました。

PPTPはポート1723だけで完結しません。制御チャネルはTCP 1723を使いますが、トンネルデータは通常、通常のTCP/UDPポートではなくGREプロトコルを使います。そのため1723だけを許可してもPPTPが動かないことがあります。ファイアウォール、NAT機器、回線事業者側でもGREを通す必要があります。

現代のセキュリティ観点では、PPTPは機密性の高いワークロードには適していません。一般的に使われてきた認証・暗号化方式には歴史的に知られた弱点があり、多くの組織ではL2TP/IPsec、OpenVPN、WireGuard、IKEv2、ゼロトラストアクセスへ置き換えています。

公開スキャンで1723が開いている場合は、実際の業務でまだPPTPに依存しているか確認してください。単なるレガシー設定の残りであれば無効化すべきです。短期的に残す必要がある場合でも、送信元アドレスを制限し、強いアカウントポリシーを適用し、より安全なVPN方式への移行計画を立ててください。

PPTP接続失敗の一般的な原因には、GREがブロックされている、NAT機器がPPTP passthroughに対応していない、アカウント認証に失敗している、サーバーポリシーでレガシープロトコルが無効化されている、ファイアウォールがTCP 1723だけを許可している、クライアント側ネットワークがこのトンネル通信を許可していないことがあります。

TCPポート1883は、MQTTの標準的な平文ポートです。MQTTは、IoT機器、センサー、エッジゲートウェイ、コネクテッドカー、スマートホーム、産業テレメトリ、低帯域ネットワークでよく使われる軽量なpublish/subscribeプロトコルです。

MQTTは通常のHTTPとは動き方が異なります。クライアントは単にエンドポイントへリクエストするのではなく、brokerへ接続し、topicへpublishまたはsubscribeします。たとえば機器が sensors/room1/temperature へ温度をpublishし、バックエンドがそのtopicをsubscribeして処理するような使い方です。

ポート1883は通常暗号化されていないため、ユーザー名、パスワード、topic、メッセージ本文がネットワーク経路上で見える可能性があります。公開インターネット、モバイルネットワーク、キャリア回線、信頼できない経路をまたぐ場合は、通常ポート8883のMQTT over TLSを使う方が安全です。

MQTTの安全性は、ポートが到達可能かどうかだけでは決まりません。重要なのは、broker認証、匿名接続の可否、topicごとのread/write ACL、機器認証情報のローテーション可否、クライアントが本来見えないwildcard topicをsubscribeできないかどうかです。

MQTT brokerが誤って公開されていると、攻撃者が機器データを読み取る、制御コマンドを偽造する、topicを列挙する、brokerリソースを消費する、弱い認証情報で機器メッセージング経路へ参加する、といったリスクがあります。

MQTT接続失敗を調査するときは、brokerが1883で待ち受けているか、ファイアウォールがアクセスを許可しているか、クライアントのプロトコルバージョンが合っているか、認証情報が正しいか、clientIdが衝突していないか、ACLがsubscribeやpublishを拒否していないか、QoS、keepalive、last-will設定に矛盾がないかを確認してください。

TCPポート2049は、NFS、つまりNetwork File Systemの中心的なポートです。NFSは一度きりのアップロードやダウンロードというより、リモートディレクトリをローカルファイルシステムのようにマウントして使う仕組みに近く、Unix/Linuxサーバー、NAS、仮想化基盤、Kubernetesストレージ、バックアップシステム、計算クラスターでよく使われます。

NFSv4は通常ポート2049を中心に動作します。一方、古いNFSv3環境では、ポート111のrpcbindに加えて、mountd、lockd、statdなどの動的ポートや追加ポートに依存することがあります。マウント失敗を調査するときは、まずNFSv3かNFSv4かを確認してください。

ポート2049は価値の高いファイルアクセス入口であり、インターネットへ直接公開すべきではありません。設定ミスがあると、外部からexportを列挙されたり、共有ファイルを読み取られたり、データを書き換えられたり、バックアップ、設定ファイル、ソースコード、ログ、アプリケーションデータディレクトリへアクセスされたりする可能性があります。

NFSの安全性は、ポートが開いているかどうかだけでは決まりません。exportルール、クライアント送信元制限、読み取り/書き込み権限、root_squashまたはno_root_squash、ファイルシステム権限、Kerberos設定、mount optionを確認してください。多くのインシデントは、広すぎるexportパスやクライアントネットワーク範囲から発生します。

本番環境では、NFSは信頼済み内部ネットワーク、ストレージネットワーク、VPC、クラスター用ネットワークに限定してください。ネットワークをまたぐファイル共有では、公開NFSではなく、VPN、専用線、プライベート接続、オブジェクトストレージ、SFTP、制御されたファイルサービスを優先してください。

NFSをマウントできない場合は、2049へ到達できるか、rpcbindが動作しているか、exportされたパスが存在するか、クライアントIPが許可されているか、NFSバージョンが一致しているか、セキュリティグループとホストファイアウォールが通信を許可しているか、サーバー側のexportルールが正しいかを確認してください。

TCPポート2052は、Cloudflareプロキシが対応しているHTTPポートのひとつです。80番が使えない場合、複数のWeb入口が必要な場合、または非標準のHTTPサービスをCloudflare配下に置く場合に使われることがあります。

ポート2052自体は平文HTTPポートであり、HTTPSと同じではありません。ユーザーからCloudflareまでの接続はHTTPSにできても、Cloudflareからオリジンまでの通信が暗号化されるかどうかは、オリジン設定、SSL/TLS mode、実際のオリジンプロトコルに依存します。

このポートでは通常のWebページ、API、プロキシ背後のHTTPサービスを扱えますが、管理画面、デバッグコンソール、認証のない内部システム、機密性の高い制御プレーンを直接公開すべきではありません。Cloudflareがそのポートに対応していることは、オリジンをすべての送信元へ開いてよいという意味ではありません。

オリジンが2052を公開している場合は、Cloudflareのorigin IPまたは制御されたネットワークだけを許可し、Host処理、オリジンプロトコル、アクセス制御、ログ、レート制限、アプリケーション認証を確認してください。

2052のアクセス問題を調査するときは、DNSレコードがCloudflareでプロキシされているか、オリジンが実際に2052で待ち受けているか、Cloudflareがそのポートをサポートしているか、オリジンプロトコルが設定と一致しているか、オリジンファイアウォールがCloudflareノードを許可しているかを確認してください。

TCPポート2053は、Cloudflareプロキシが対応しているHTTPSポートのひとつです。443番を避けたい非標準HTTPS Webサービス、代替サイト入口、API、暗号化されたアクセス経路でよく使われます。

ポート2053は、通常オリジン側もTLSでサービスしていることを意味します。利用時は、オリジン証明書、SNI、Cloudflare SSL/TLS mode、オリジンプロトコル、アプリケーションの待ち受けが一致しているか確認してください。不一致があると、525エラー、526エラー、TLSハンドシェイク失敗、オリジンエラーが起こりやすくなります。

443と同様に、2053ではWebサイト、API、TLS上のWebSocket、コンソール入口などを扱えます。背後のサービスが管理システム、管理パネル、デバッグサービス、内部アプリケーションである場合、Cloudflareプロキシだけでは不十分です。Access、ID確認、送信元制限、オリジンファイアウォールルールと組み合わせてください。

本番環境では、オリジンの2053が任意の公開送信元を受け付ける状態を避けてください。より安全な構成は、Cloudflare origin IP、制御されたゲートウェイ、信頼済み管理ネットワークだけを許可することです。

2053のトラブルシューティングでは、ブラウザからCloudflareまでの証明書、Cloudflareからオリジンまでの証明書、オリジンが2053で待ち受けているか、DNSプロキシが有効か、オリジンアクセスが適切に制限されているかを確認してください。

TCPポート2082は、cPanelの平文Web管理入口としてよく使われます。cPanelでは、サイト、ドメイン、データベース、メール、ファイル、証明書、ホスティング設定を管理できるため、通常のコンテンツページではなく、権限の高い管理プレーンとして扱う必要があります。

ポート2082はCloudflareプロキシが対応しているHTTPポートのひとつでもありますが、それは無制限に公開してよいという意味ではありません。cPanelを提供している場合、アカウント侵害により、サイトファイル、メールボックス、データベース、DNS、証明書、バックアップに影響が及ぶ可能性があります。

2082は平文のため、実際の管理ログインには適していません。本番でcPanelアクセスが必要な場合は、2083のHTTPSを優先し、強いパスワード、MFA、ログイン制限、IP許可リスト、監査ログを組み合わせてください。

スキャンで2082が開いている場合は、実際にcPanelなのか、Cloudflare経由の通常HTTPサービスなのか、別アプリケーションが同じポートを再利用しているだけなのかをまず確認してください。Cloudflareが対応しているからといって、通常の公開Webポートとして扱わないでください。

基本方針としては、2082を閉じるか、2083へリダイレクトするのが望ましいです。短期的に残す必要がある場合は、VPN、踏み台サーバー、信頼済み管理アドレス、Cloudflare Accessの背後に置き、デフォルトアカウント、弱いパスワード、総当たり攻撃への露出を確認してください。

TCPポート2083は、cPanelのHTTPS管理入口としてよく使われます。管理者やサイトユーザーは、サイトファイル、ドメイン、データベース、メールボックス、証明書、バックアップ、ホスティング関連設定を管理できます。

2083と2082は混同されやすいポートです。2082は通常、平文のcPanel入口で、2083はTLSで保護されたcPanel入口です。本番でcPanelを公開する必要がある場合は、できる限り2083を使い、2082は閉じるか制限してください。

ポート2083はCloudflareプロキシが対応しているHTTPSポートのひとつでもあります。ただしCloudflareが対応していることは、制御なしに公開してよいという意味ではありません。ホスティング管理パネルを提供している場合は、高権限の管理インターフェースとして扱う必要があります。

cPanel入口が侵害されると、Webアカウントだけでなく、サイトファイル、データベース、メールアカウント、DNS、SSL証明書、バックアップに影響が及ぶ可能性があります。MFA、強いパスワード、ログイン失敗制限、IP許可リスト、ログイン通知、監査ログを有効にしてください。

2083のアクセス問題を調査するときは、サービスが実際にcPanelか、証明書が正しいか、Cloudflareプロキシ設定が意図どおりか、オリジンがCloudflareトラフィックを許可しているか、ホストファイアウォールがこのポートを許可しているか、cPanelのセキュリティポリシーがログイン元を遮断していないかを確認してください。

TCPポート2086は、WHM、つまりWebHost Managerの平文管理入口としてよく使われます。WHMは通常、複数のcPanelアカウント、ホスティングプラン、ドメイン、サービス状態、セキュリティポリシー、サーバーリソースなどを管理する、サーバーレベルのホスティング管理に使われます。

ポート2086は、通常のcPanelユーザー入口より高い権限を持つことが多いです。cPanelが単一サイトアカウント中心なのに対し、WHMはサーバー全体または複数tenantアカウントを制御できるため、権限の高い制御プレーンとして扱うべきです。

ポート2086はCloudflareプロキシが対応するHTTPポートのひとつでもありますが、Cloudflare対応だからといって無制限に公開してよいわけではありません。WHMを提供している場合、通常の公開Webページのように扱うべきではありません。

2086は平文HTTP入口のため、本番環境ではHTTPS版のWHMポートである2087を優先してください。短期的に2086を残す必要がある場合は、VPN、踏み台サーバー、信頼済み管理IP、Cloudflare Accessの背後に置いてください。

2086をレビューするときは、待ち受けサービスが本当にWHMか、デフォルトアカウント、弱いパスワード、総当たり攻撃への露出、オリジンの直接公開、Cloudflare origin制限の欠落、平文入口を無効化または暗号化入口へリダイレクトできるかを確認してください。

TCPポート2087は、WHMのHTTPS管理入口としてよく使われます。WHMはサーバーレベルのホスティング管理機能を提供し、cPanelアカウントの作成・管理、サービス設定の調整、DNS管理、リソース確認、証明書管理、複数サイトのホスティング環境の制御などに使われます。

2087と2086の関係は、HTTPSとHTTPの関係に近いです。2087は最初からTLSを使い、2086は平文です。WHMは非常に高い権限を持つため、本番環境では2087を優先し、2086は閉じるか厳しく制限してください。

ポート2087は、Cloudflareプロキシが対応しているHTTPSポートのひとつでもあります。Cloudflareを使う場合は、オリジン証明書、SSL/TLS mode、SNI、オリジンポート、アクセス制御が一貫しているか確認してください。設定がずれていると、ハンドシェイク失敗、オリジンエラー、管理画面の意図しない公開につながることがあります。

2087はHTTPSですが、それでも高リスクな管理入口です。MFA、強いパスワードポリシー、ログイン失敗制限、IP許可リスト、監査ログ、ログイン通知、適時のパッチ適用を有効にしてください。

2087のトラブルシューティングでは、WHMが起動しているか、ホストファイアウォールがポートを許可しているか、Cloudflareのプロキシ設定がオリジンと一致しているか、オリジン証明書が有効か、cPHulkなどのセキュリティポリシーがログイン元をブロックしていないかを確認してください。

TCPポート2095は、cPanel Webmailの平文入口としてよく使われます。ユーザーはブラウザからログインし、メールの閲覧、送信、フォルダー管理、基本的なメールボックス設定を行えます。

ポート2095は平文HTTP入口であり、実際のメールボックスログインには適していません。メールボックスの認証情報、セッションCookie、本文、添付ファイルは機密性が高く、平文アクセスは認証情報や内容が通信経路上で傍受されるリスクを高めます。

ポート2095はCloudflareプロキシが対応しているHTTPポートのひとつでもありますが、それだけで公開ログイン面として適切になるわけではありません。Webmailはアカウント入口であり、TLS、強いパスワード、MFA、ログインレート制限、不審ログイン通知、総当たり攻撃対策で保護すべきです。

本番環境では、Webmailには2096または443上の標準HTTPS入口を優先し、2095は閉じる、制限する、または暗号化された入口へリダイレクトするのが望ましいです。

スキャンで2095が開いている場合は、平文ログインがまだ許可されていないか、Cloudflareやリバースプロキシで保護されているか、弱いパスワードやcredential stuffingのリスクがないか、アクセスを2096へ移行できるかを確認してください。

TCPポート2096は、cPanel WebmailのHTTPS入口としてよく使われます。ユーザーはブラウザからメールボックスにアクセスし、メッセージの閲覧、メール送信、フォルダー管理、添付ファイルのダウンロード、基本的なメールボックス設定を行えます。

2096と2095は対になるポートです。2095は通常、平文のWebmail入口で、2096は暗号化されたWebmail入口です。本番環境では2096を優先し、可能な限り2095をHTTPSへリダイレクトするか制限してください。

ポート2096はCloudflareプロキシが対応しているHTTPSポートのひとつでもあります。プロキシを使う場合は、CloudflareからオリジンまでのTLS mode、オリジン証明書、Hostヘッダー処理、Webmailのログインcallback、Cookieのセキュリティ属性を確認してください。

Webmailはメールボックスアカウントへの直接入口です。HTTPSであっても、強いパスワード、MFA、ログイン失敗制限、不審ログイン通知、セッションタイムアウト、スパム・フィッシング対策と組み合わせるべきです。

2096のログイン失敗を調査するときは、証明書、Cloudflareのオリジン設定、Webmailサービスの状態、アカウントのパスワードや認可ポリシー、メールボックス容量、ログイン元制限、ブラウザのCookieやSameSite設定によるセッション破損を確認してください。

TCPポート2181は、Apache ZooKeeperのデフォルトクライアント接続ポートです。ZooKeeperは、サービスディスカバリ、設定管理、分散ロック、leader election、クラスターメタデータ、状態調整に使われる分散協調サービスです。

古いKafka構成、HBase、SolrCloud、Dubbo、Storm、初期のFlink構成、一部の独自分散システムはZooKeeperに依存していることがあります。2181へ接続するクライアントは、znodeを読み書きし、設定変更をwatchし、協調ロジックに参加できます。

ZooKeeperのデータは一般的な業務データではないこともありますが、クラスタ全体の制御プレーン状態を定義している場合があります。不適切なznode変更、メタデータ削除、広すぎるACL、信頼できないクライアントアクセスは、サービスディスカバリ失敗、設定ドリフト、クラスタ障害、誤ったleader/follower判断につながる可能性があります。

ポート2181は通常、アプリケーションネットワーク、クラスターネットワーク、管理ネットワーク内だけで開くべきです。公開インターネットへ公開したり、信頼できないクライアントが自由に読み書きできる状態にしたりしてはいけません。本番環境では認証、ACL、送信元制限、監査ログを使い、world:anyoneのような広すぎる権限を避けてください。

ZooKeeperクラスタでは、followerからleaderへの通信に2888、leader electionに3888を使うことがよくあります。トラブルシューティングでは、クライアントポート2181と内部クラスターポートを区別してください。

ZooKeeperに依存するシステムで接続失敗、セッション期限切れ、electionの不安定化、設定不整合が起きる場合は、ensembleの健全性、ACL、ディスクレイテンシ、GC停止、tickTime、session timeout、ネットワーク分断、peerポート間の接続性を確認してください。

TCPポート2222は、SSHの代替ポートとしてよく使われます。踏み台サーバー、開発マシン、コンテナSSHエンドポイント、セルフホストGitサービス、コードホスティング基盤、環境ごとに分離されたリモートログイン入口などで見かけます。

SSHを22から2222へ移しても、それだけで本質的に安全になるわけではありません。標準ポートへの雑なスキャンノイズを多少減らすことはありますが、本当のセキュリティは、鍵認証、弱いパスワードの無効化、送信元制限、MFA、踏み台アクセス、監査ログ、最小権限アカウントに依存します。

2222が非標準ポートだからといってリスクを低く見積もらないでください。背後のサービスがSSHなら、それはリモート管理入口として扱うべきです。特にrootログイン、パスワードログイン、空パスワード、古い鍵、アカウント使い回しを確認してください。

本番環境で2222を公開する必要がある場合は、送信元IPを制限するか、VPN、踏み台サーバー、ゼロトラストアクセス層の背後に置き、ログイン監査、ログイン失敗アラート、鍵ローテーションを維持してください。

トラブルシューティングでは、sshdの待ち受け設定、クラウドのセキュリティグループ、ホストファイアウォール、コンテナのポートマッピング、Gitサービス設定、クライアント側のポート指定、ユーザーのネットワークが外向きSSHをブロックしていないかを確認してください。

TCPポート2323は、Telnetの代替ポートとしてよく使われます。古いルーター、カメラ、産業制御機器、組み込みシステム、ラボ環境、ベンダーのデバッグインターフェース、古い管理方式を残している機器で見つかることがあります。

ポート2323は、ポート23より安全というわけではありません。背後のサービスがTelnetなら、ユーザー名、パスワード、コマンド、応答が平文で送信され、信頼できないネットワーク上で傍受・観測される可能性があります。

多くのIoTワームやスキャナーは、23番だけでなく2323番のTelnetも探索し、デフォルトアカウント、弱いパスワード、ベンダーのバックドア、古いファームウェア脆弱性を試します。

2323が公開インターネットに露出している場合は、まず機器種別、ファームウェアバージョン、デフォルトアカウント、管理境界、Telnetを無効化またはSSHへ置き換えられるかを確認してください。

本番環境では、Telnet系アクセスをインターネットへ公開すべきではありません。すぐに削除できない場合でも、管理ネットワーク、VPN、信頼済み送信元に限定し、デフォルトパスワード、匿名アクセス、デバッグモードを確認してください。

TCPポート2375は、暗号化されていないDocker Remote APIアクセスでよく使われます。Docker daemonがこのポートで待ち受けている場合、リモートクライアントはHTTP APIを通じて、イメージ、コンテナ、ネットワーク、ボリューム、一部のホスト関連リソースを管理できます。

ポート2375は非常に危険です。通常TLSがなく、認証なしで誤設定されていることもあります。Docker APIへアクセスできる相手は、privileged containerを作成したり、ホストディレクトリをマウントしたり、機密ファイルを読んだり、スケジュールタスクを書き込んだり、間接的にホストを制御したりできる可能性があります。

このポートは公開資産上に現れるべきではなく、通常の内部ネットワーク内でも広く到達可能にすべきではありません。開発環境であっても、暗号化されていないDocker APIは、同じネットワーク上の他の端末、悪意あるコンテナ、CIジョブ、侵害されたアプリケーションから悪用される可能性があります。

リモートDocker管理が本当に必要な場合は、Docker context over SSH、2376での相互TLS、有効なオーケストレーション基盤であるKubernetes、Nomad、CI/CDプラットフォーム経由の管理など、より安全な選択肢を検討してください。

2375が開いている場合は、dockerdの起動フラグ、daemon.json、systemd override、コンテナ基盤設定、セキュリティグループルールを直ちに確認してください。信頼できないネットワークへ露出していた場合は、想定外のコンテナ、イメージ、マウント済みボリューム、ホストファイル変更、アクセスログも調査してください。

TCPポート2376は、TLS対応のDocker Remote APIでよく使われます。2375と同じくDocker daemonをリモートから管理できますが、通常はクライアント証明書とサーバー証明書を使い、通信の暗号化と相互の身元確認を行います。

2376は暗号化されていない2375より安全ですが、それでも高権限の管理インターフェースです。有効なクライアント証明書を持つユーザーは、コンテナ作成、イメージ取得、ボリュームマウント、ネットワーク変更、コンテナ権限を通じたホストのセキュリティ境界への影響などを行えることがあります。

本番環境では、2376は制御された管理ネットワーク、CI/CDシステム、踏み台サーバー、明示的に許可された運用ノードにだけ公開してください。クライアント証明書は保護し、定期的にローテーションし、退職、端末紛失、パイプラインからの認証情報漏えいがあった場合は失効させる必要があります。

多くの環境では、Docker Remote APIを直接公開する必要はありません。Docker over SSH、KubernetesやNomadの利用、制御されたCI runner経由のビルド・デプロイの方が、監査しやすく分離もしやすいことが多いです。

2376を調査するときは、dockerdでtlsverifyが有効になっているか、サーバー証明書とクライアント証明書が対応しているか、証明書のCN/SANがアクセス先アドレスをカバーしているか、ファイアウォールがポートを許可しているか、クライアント側でDOCKER_HOST、DOCKER_TLS_VERIFY、DOCKER_CERT_PATHが正しく設定されているかを確認してください。

TCPポート2379は、etcdの一般的なクライアントAPIポートです。etcdは分散key-value storeであり、Kubernetesクラスタの状態、オブジェクトメタデータ、設定、lease、制御プレーンの協調データ、場合によっては機密情報への参照を保持します。

Kubernetes API Serverは2379を通じてetcdへアクセスします。通常の業務アプリケーションがetcdへ直接接続するべきではありません。クラスタ状態の操作は、Kubernetes API、controller、またはプラットフォームの管理インターフェースを経由するのが基本です。

2379はKubernetes制御プレーンの中でも最も機密性の高いポートのひとつです。不適切に公開されると、攻撃者がクラスタオブジェクト、サービスディスカバリ情報、設定データを読み取ったり、認証やTLS設定が不十分な場合にはクラスタ状態を書き換えたりできる可能性があります。

本番etcdでは、TLS、クライアント証明書認証、最小限の送信元アクセス制御を使い、API Server、バックアップジョブ、少数の制御された管理コンポーネントだけを許可してください。etcdのクライアントポートをnode、Podネットワーク、オフィスネットワーク、公開インターネットへ開放してはいけません。

etcdアクセスの問題を調査するときは、証明書の期限切れ、クライアント証明書の権限、endpointの整合性、quorumの健全性、ディスクレイテンシ、snapshot backup、2379が制御プレーンコンポーネントからのみ許可されているかを確認してください。

TCPポート2380は、etcdの一般的なpeer通信ポートです。主にetcdクラスタメンバー間で、Raft log replication、leader election、メンバー状態の同期、一貫性維持のために使われます。

2380は2379とは役割が異なります。2379はクライアントAPIポートで、通常はKubernetes API Server、バックアップジョブ、管理ツールからアクセスされます。一方、2380はetcdノード同士の内部通信ポートです。

2380がファイアウォールで遮断されている、高レイテンシがある、証明書設定が誤っている場合、etcdクラスタではメンバー到達不能、election失敗、書き込み不可、quorum喪失、より広いKubernetes制御プレーンの不安定化が起こる可能性があります。

このポートを公開インターネット、オフィスネットワーク、Podネットワーク、通常のnodeネットワークへ開放してはいけません。本番環境では、本物のetcdメンバー間だけに通信を許可し、peer TLS証明書、member list管理、ファイアウォールルール、ネットワーク分離と組み合わせてください。

2380を調査するときは、peer URL、証明書SAN、nodeの時刻同期、DNSまたはhostname解決、ネットワークレイテンシ、ディスクI/O、member list、Raftログ、ファイアウォールポリシーを確認してください。単にポートへ到達できるだけでは、etcdクラスタが健全だとは限りません。

TCPポート2484は、Oracle Database TCPSでよく使われます。TCPSはOracle Net over TLSであり、クライアント、アプリケーションサーバー、Oracle Listener間で暗号化されたデータベース接続を確立するために使われます。

2484は1521とあわせて理解されることが多いです。1521はOracle Listenerの一般的な標準ポートであり、2484はTLSで保護されたデータベースアクセスが有効な場合によく使われます。調査時は、接続文字列、service name、SID、wallet、証明書チェーン、listener設定を確認してください。

TCPSは通信経路を保護しますが、データベース入口をすべての公開送信元へ開いてよいという意味ではありません。データベースポートは依然として価値の高い資産入口であり、誤った公開はパスワード攻撃、サービス列挙、バージョン探索、弱い権限でのアクセス、データ漏えいにつながる可能性があります。

本番環境では、2484へのアクセスを内部ネットワーク、VPC、VPN、プライベート接続、踏み台サーバー、制御されたアプリケーションサーバーに限定し、送信元制限、最小権限アカウント、強い認証、監査ログ、ログイン失敗監視、証明書ライフサイクル管理と組み合わせてください。

2484の接続失敗を調査するときは、クライアントがTCPSで接続しているか、walletと信頼チェーンが正しいか、証明書名がアクセス先アドレスと一致しているか、listenerでTCPSが有効か、データベースサービスが登録されているか、ファイアウォールやセキュリティグループが接続を許可しているかを確認してください。

TCPポート2888は、ZooKeeperのfollowerとleaderの間の内部通信でよく使われます。ZooKeeperクライアントが接続するためのポートではありません。クライアントは通常2181へ接続します。

ZooKeeper ensembleでは、2888がnode間のレプリケーション、状態同期、通常のfollower-to-leader通信に使われ、3888はleader electionで使われることが一般的です。どちらも内部クラスターポートであり、クライアントポートと混同しないでください。

2888がファイアウォールで遮断されている、DNS解決に問題がある、node間レイテンシが高い場合、ZooKeeperノードがクラスタへ正しく参加できず、Kafka、HBase、SolrCloud、Dubbo、その他分散システムが不安定になる可能性があります。

本番環境では、2888はZooKeeperクラスタメンバー間だけに許可してください。公開インターネット、通常のアプリケーションネットワーク、無関係なホストへ開放すべきではありません。複数データセンターやVPCをまたぐ構成では、security group、ファイアウォールルール、プライベートネットワークで明示的に制御してください。

2888を調査するときは、zoo.cfgのserver list、hostname解決、node間ネットワーク、myid値、ディスクレイテンシ、JVMの健全性、バージョン互換性、2181・2888・3888がそれぞれの役割に応じて許可されているかを確認してください。

TCPポート3000は、開発、テスト、監視環境で非常によく使われます。Node.js、Express、Next.js、React/Viteの開発サーバー、NestJS、ローカルmock service、内部ツール、Grafanaなどがこのポートで待ち受けることがあります。

ポート3000には固定された意味がひとつあるわけではありません。一時的な開発サーバー、本番Grafanaダッシュボード、内部管理ページ、APIサービス、コンテナからマッピングされた入口など、さまざまな可能性があります。ポート番号だけでサービス種別を決めつけないでください。

サービスがGrafanaの場合は、認証、匿名アクセス、データソース権限、ダッシュボード内容、クエリ権限に注目してください。Grafanaはhostname、metric label、サービス構成、PromQLクエリ、内部システム状態を見せてしまうことがあります。

サービスがフロントエンドまたはNode.jsの開発サーバーの場合、通常は公開インターネットへ直接公開すべきではありません。開発用サービスには、hot reload endpoint、source path、詳細なerror stack、テスト設定、緩いproxy rule、不完全な認証ロジックが含まれることがあります。

ポート3000を調査するときは、実際の待ち受けプロセス、コンテナのポートマッピング、リバースプロキシ設定、systemd、pm2、Docker Compose、Kubernetes Service、アクセスログを確認してください。本番では通常、3000をlocalhost、コンテナネットワーク、内部ネットワークに閉じ、公開アクセスは統一された80/443入口からルーティングする方が安全です。

TCPポート3128は、SquidやHTTPプロキシの待ち受けポートとして非常によく使われます。企業の外向き通信プロキシ、キャッシュ、開発時のデバッグ、クローラー用プロキシプール、内部アクセス中継、制御されたインターネット出口などで使われることがあります。

プロキシポートのリスクは、通常のWebページのように見えることではなく、他のネットワークへ入る、または通り抜ける経路になり得る点にあります。設定を誤ると、外部ユーザーが内部リソースへ到達したり、本来の送信元を隠したり、外向き通信制御を回避したり、スキャンリクエストを中継したりできる可能性があります。

3128が公開インターネットへ露出している場合は、認証が必須になっているか、許可された宛先が制限されているか、CONNECTが任意のポートへ許可されていないか、アクセスログが保存されているか、オープンプロキシ化していないかを確認してください。

オープンプロキシは、悪用トラフィック、不要なリクエスト、IPアドレスのブロックリスト入り、コンプライアンス問題、内部リソースへのプロービングにつながる可能性があります。プロキシ自体が業務データを保存していなくても、ネットワーク境界や到達経路を間接的に露出することがあります。

本番環境では、3128はオフィスネットワーク、外向きゲートウェイ、監視ネットワーク、または制御されたクライアント範囲に限定し、認証、ACL、宛先許可リスト、監査ログ、異常トラフィック監視と組み合わせてください。

TCPポート3268は、Active Directory Global Catalogでよく使われるポートです。Global Catalogは、AD forest内のオブジェクトについて一部の属性を保持し、複数ドメインをまたいでユーザー、グループ、連絡先、その他のディレクトリオブジェクトを検索できるようにします。

通常のLDAPである389番と比べると、3268はクロスドメインのディレクトリ検索により特化しています。企業アプリケーション、メールシステム、ID基盤、ディレクトリ検索ツールは、AD forest全体から対象オブジェクトをすばやく見つけるためにこのポートを使うことがあります。

ポート3268は通常の公開入口として扱うべきではありません。アカウント、組織構造、グループ関係、メールアドレス、オブジェクト属性、ドメイン環境の手がかりを見せる可能性があり、アカウント列挙、ソーシャルエンジニアリング、後続の認証攻撃に有用な情報になります。

本番環境では、3268はドメインコントローラー、IDサービス、信頼済みアプリケーションサーバー、管理ネットワークに限定してください。検索内容の通信経路を保護する必要がある場合は、TLSで保護されたGlobal Catalogポートである3269を検討してください。

3268のトラブルシューティングでは、DNS、ドメインコントローラーへの到達性、LDAP search base、filter、アカウント権限、クロスドメイン信頼関係、ファイアウォールルール、アプリケーションが通常LDAPではなくGlobal Catalogへ接続すべきかどうかを確認してください。

TCPポート3269は、Global Catalog over SSL/TLSでよく使われます。Active Directory Global Catalogへ暗号化された接続でアクセスするためのポートです。

3269と3268の関係は、LDAPSとLDAPの関係に近いです。3268は平文のGlobal Catalog検索ポートで、3269は接続開始時点からTLSを使います。アカウント、組織構造、グループ関係、ディレクトリオブジェクト属性のような機密性のある検索内容を保護する用途に向いています。

TLSが有効であっても、3269はID基盤のポートであり、公開インターネットへ直接出すべきではありません。誤った公開は、アカウント列挙、ディレクトリ構造の漏えい、グループ関係の開示、ID攻撃面の拡大につながる可能性があります。

本番環境では、3269へのアクセスを信頼済みアプリケーションサーバー、ID基盤、メールシステム、管理ツール、ドメインコントローラー関連ネットワークに限定し、証明書管理、送信元制限、最小権限アカウント、監査ログと組み合わせてください。

3269の接続失敗を調査するときは、ドメインコントローラー証明書が有効か、クライアントが証明書チェーンを信頼しているか、アクセス先アドレスと証明書名が一致しているか、アプリケーションの接続文字列が正しいポートを使っているか、ファイアウォールが接続を許可しているかを確認してください。

TCPポート3306は、MySQLとMariaDBで最も一般的な標準接続ポートです。バックエンドアプリケーション、データベースクライアント、マイグレーションスクリプト、BIツール、管理基盤、バックアップジョブ、運用スクリプトがデータベースインスタンスへ接続するためによく使います。

ポート3306はインターネット上で頻繁にスキャンされるデータベースポートです。攻撃者は、バージョン探索、デフォルトアカウント、弱いパスワード、総当たり、未認可アクセス、公開された管理アカウント、既知脆弱性の悪用を試すことがよくあります。

本番データベースでは、通常3306をインターネットへ直接公開すべきではありません。より安全な構成は、アプリケーションサーバーから内部ネットワーク、VPC、プライベート接続、VPN、踏み台サーバー、コネクションプール、またはクラウドデータベースのプライベートエンドポイント経由で接続させる形です。

MySQL接続失敗の一般的な原因には、mysqldがネットワークアドレスで待ち受けていない、bind-addressが127.0.0.1に限定されている、アカウントがリモートログインを許可していない、ユーザー名と接続元ホストの組み合わせが一致しない、ファイアウォールやセキュリティグループで遮断されている、TLS要件が合っていない、接続文字列が誤ったインスタンスを指していることがあります。

MySQLをネットワーク越しに到達可能にする必要がある場合は、送信元IP許可リスト、強い認証、最小権限アカウント、TLS暗号化、監査ログ、slow query監視、ログイン失敗監視、バックアップ・リストア検証を使ってください。標準ポートを変えるだけでは、データベース公開リスクは大きく下がりません。

TCPポート3389は、RDP、つまりRemote Desktop Protocolの標準ポートです。Windows Server、Windowsデスクトップ、クラウドインスタンス、ジャンプ環境、グラフィカルなリモート管理でよく使われます。

RDPはコマンドラインだけでなく、完全なデスクトップセッションを提供します。ログイン後、ユーザーはGUIアプリケーションを実行したり、ファイルを操作したり、クリップボード転送を使ったり、ローカルドライブをマッピングしたり、サーバーコンソールを操作したりできるため、非常に機密性の高いリモート管理入口として扱う必要があります。

3389を公開インターネットへ露出することは高リスクです。攻撃者はRDPを常時スキャンし、弱いパスワード、パスワードスプレー、総当たり、認証情報の使い回し、過去の脆弱性、弱いリモートデスクトップ設定を試します。

本番環境では、3389をすべての公開送信元へ直接開くのではなく、VPN、踏み台サーバー、ゼロトラストアクセス、Remote Desktop Gateway、制御された管理ネットワークを優先してください。

RDPを到達可能にする必要がある場合は、Network Level Authenticationを有効化し、送信元IPを制限し、MFAまたはRemote Desktop Gatewayを使い、アカウントロックアウトポリシーを設定し、不要な管理者ログインを無効化し、ログイン失敗、異常な時間帯、想定外の送信元地域を監視してください。

RDP接続失敗を調査するときは、Remote Desktopが有効か、Windows Firewallとクラウドのセキュリティグループが接続を許可しているか、アカウントにリモートログイン権限があるか、NLA互換性があるか、サーバーのセッション数上限に達していないか、セキュリティポリシーやEDRがアクセスをブロックしていないかを確認してください。

TCPポート3478は、STUN/TURNのTCP転送経路としてよく使われます。UDPに比べると、制限の厳しいネットワーク、ファイアウォール環境、企業プロキシ環境で、WebRTC、音声、ビデオ、リアルタイム通信サービスの到達性を改善するためのフォールバックとして使われることが多いです。

STUNは、クライアントがNATによって割り当てられた公開側アドレスを知るために使われます。TURNは、直接のpeer-to-peer接続が失敗したときに、メディアやデータを中継します。TCP 3478は通常、最適なメディア経路ではありませんが、UDPがブロックされている環境では重要になります。

TCP 3478を使うと接続成功率が上がることがありますが、リアルタイム音声や映像の品質はUDPより不安定になりがちです。レイテンシ、ジッター、輻輳制御が通話品質に影響します。

TURNサービスはトラフィックを中継するため、サーバー帯域を消費します。認証、quota、送信元制限、悪用監視がない場合、オープンリレーとして悪用される可能性があります。

本番環境では、短命の認証情報を使い、relay scopeを制限し、異常トラフィックを監視し、UDP 3478、TLS 5349、443フォールバック経路とあわせて接続性を調査してください。

UDPポート3478は、STUN/TURNで最もよく使われるポートのひとつです。WebRTC、ビデオ会議、音声通話、オンライン授業、リモートコラボレーション、リアルタイム対話型アプリケーションで広く使われます。

STUNは、クライアントがNATによって割り当てられた公開アドレスとポートを知り、peer-to-peer接続を試みるために使われます。TURNは、peer-to-peer接続が失敗した場合に、メディアストリームやデータを中継するサーバーとして動作します。

会議に参加できるのに音声や映像が出ないケースの多くは、アプリケーション本体ではなく、UDP 3478、TURN relayへの到達性、メディアポート範囲、NATの挙動、ファイアウォールポリシーが原因です。

UDPは低レイテンシでオーバーヘッドが小さいため、リアルタイム音声・映像に向いています。ただし、企業ネットワーク、ファイアウォール、通信事業者、厳格なセキュリティポリシーでは制限されやすい通信でもあります。

TURNに認証、短命の認証情報、quota、悪用対策がない場合、オープンリレーとして使われ、帯域消費、コスト増加、異常トラフィックのリスクにつながります。

本番環境では、relay policyを制限し、一時的な認証情報とログを有効にし、複雑なネットワークでも接続性を確保するために、TCP 3478、TLS 5349、443などのフォールバック経路も用意してください。

TCPポート3888は、ZooKeeperのleader electionトラフィックでよく使われます。ZooKeeperノードは、このポートを使って投票、leader election、メンバー状態の調整を行います。

3888は業務クライアント用ポートではなく、通常のアプリケーションがアクセスするべきものではありません。ZooKeeperクライアントは通常2181へ接続し、follower-to-leader同期では2888、leader electionでは3888がよく使われます。

3888が遮断されている、高レイテンシがある、node間の名前解決に問題がある場合、ZooKeeperはleaderを選出できなかったり、ノードを繰り返しoffline扱いにしたり、セッション不安定や依存サービスの停止を引き起こしたりする可能性があります。

このポートはZooKeeperクラスタメンバー間だけに開くべきです。公開インターネット、オフィスネットワーク、通常のアプリケーションセグメント、無関係なホストへ公開してはいけません。誤った公開はクラスタトポロジーのプロービングや内部制御プレーン情報の漏えいリスクを高めます。

3888を調査するときは、myid値、server list、hostname解決、node間ネットワーク、ファイアウォールルール、時刻同期、ディスクレイテンシ、ZooKeeperログ、ensembleの健全性を確認してください。

TCPポート4369は、EPMD、つまりErlang Port Mapper Daemonで使われます。Erlang分散システムのポートレジストリのように動作し、ノードは起動後にEPMDへ登録し、他のノードはEPMDを使って対象ノードの実際の通信ポートを見つけます。

RabbitMQ、CouchDB、Ejabberd、Riak、その他Erlang/OTP上に構築されたシステムは、ノード探索や分散接続の確立にEPMDへ依存することがあります。

ポート4369は通常、メッセージ送受信用の業務クライアントポートではありません。たとえばRabbitMQでは、5672/5671がAMQPクライアント、15672が管理UI、25672がノード間通信によく使われ、4369はErlangノード同士が互いを見つけるための補助をします。

EPMDはクラスタ内、または制御された管理ネットワークに限定すべきです。4369を公開すると、Erlangノード名、クラスタ構造、後続の通信ポートが見える可能性があり、RabbitMQやErlangクラスタのトポロジーを攻撃者に推測されやすくなります。

RabbitMQクラスタ参加の失敗を調査するときは、4369、25672、Erlang cookie、node name、DNSまたはhostname解決、バージョン互換性、ファイアウォールルール、クラスタログを確認してください。

UDPポート4500は、IPsec NAT Traversal、一般にNAT-Tと呼ばれる仕組みで使われます。IPsec ESPトラフィックをUDPにカプセル化し、VPNクライアントやゲートウェイがNAT、家庭用ルーター、キャリア回線、クラウドネットワークの背後にあってもIPsecトンネルを確立できるようにします。

ポート4500は、UDP 500と一緒に現れることが多いです。UDP 500は最初のIKEネゴシエーションを扱い、双方がNATを検出すると、その後のIPsecトラフィックはUDP 4500へ移ることがよくあります。L2TP/IPsec構成ではUDP 1701も関係する場合があります。

IPsec VPNの失敗を調査するときは、UDP 500だけを確認しても不十分です。ネゴシエーションは始まるのにトンネルが上がらない場合、UDP 4500がファイアウォール、セキュリティグループ、NAT機器、通信事業者のポリシーで遮断されていることがあります。

UDP 4500はVPNゲートウェイ上で公開されることがありますが、プライベートネットワークへのセキュリティ境界を表します。本番環境では、強い事前共有鍵または証明書認証、許可peerの制限、ネゴシエーションログ、未知の送信元、繰り返し失敗、不審な接続試行の監視が必要です。

TCPポート5000は、開発環境でよく使われるポートです。Flaskの開発サーバー、Python API、ローカルmock service、デバッグパネル、内部ツール、コンテナからマッピングされたサービスなどが、このポートで待ち受けることがあります。

ポート5000に固定された意味がひとつあるわけではありません。ローカル開発サービス、コンテナから公開されたバックエンドAPI、モデルサービス、テストサイト、内部コンソール、一時的なトラブルシューティング用ツールなど、用途は環境によって変わります。

開発サーバーは、通常そのまま公開インターネットへ出すべきではありません。debug mode、詳細なerror trace、テストアカウント、緩いCORS設定、default secret、hot reload、production認証を迂回する内部endpointが含まれていることがあります。

本番トラフィックが本当に5000を使っている場合でも、通常はlocalhost、コンテナネットワーク、内部ネットワークに閉じ、外部公開はNginx、Ingress、API Gateway、ロードバランサー、または統一された443入口を通す方が安全です。

ポート5000を調査するときは、まず実際の待ち受けプロセス、コンテナのポートマッピング、systemd、pm2、Docker Compose、Kubernetes設定、リバースプロキシルールを確認してください。ポート番号だけでFlaskだと決めつけないでください。

TCPポート5001は、ローカルHTTPS開発サービスでよく使われます。ASP.NET Coreの開発環境では、HTTPに5000、HTTPSに5001を使うことが多く、カスタムのテストAPI、内部ツール、開発サービスでも再利用されることがあります。

ポート5001はTLSが有効なサービスを示すことが多いですが、それだけで公開本番向けに安全だとは限りません。開発用証明書、自己署名証明書、debug middleware、詳細なエラーページ、テスト設定が残っている場合があります。

公開資産で5001が見つかった場合は、まず意図された本番入口なのか、誤って公開された開発サービス、テストAPI、コンテナマッピング、内部コンソールなのかを確認してください。

本番構成では通常、5001をリバースプロキシ、ロードバランサー、Ingressの背後に置き、公開TLS、認証、ログ、レート制限は443側で扱います。5001自体は通常、localhost、コンテナネットワーク、または制御された内部ネットワークだけに向けるべきです。

5001のトラブルシューティングでは、サービスが実際にHTTPSで待ち受けているか、証明書が信頼されているか、SNIやHostヘッダーが一致しているか、ファイアウォールが接続を許可しているか、HTTP側の5000と対になっているかを確認してください。

UDPポート5060は、従来から使われているSIPシグナリングポートです。SIPはVoIP電話の登録、通話開始、通話終了、セッション交渉、内線通信、PBX、音声ゲートウェイ間のシグナリングに使われます。

SIPが扱うのはシグナリングであり、実際の音声データそのものではありません。音声や映像のメディアは通常、RTP/RTCPを使い、PBXやSBCの設定に応じて10000番台などのUDPメディアポート範囲を使います。

通話はつながるのに音声が聞こえないケースの多くは、5060自体ではなく、RTPメディアポート、ファイアウォールポリシー、NATの挙動、SBC設定、キャリアのtrunk設定、SDP内のアドレス交渉が原因です。

SIPを公開するとリスクは高くなります。攻撃者は内線番号の列挙、登録の総当たり、弱いパスワード、国際通話の不正利用、SIPスキャン、通話詐欺、登録乗っ取りを試すことがあります。

本番環境では、5060をSBC、ファイアウォールポリシー、強い認証、送信元制限、通話制限、異常通話アラート、監査ログと組み合わせて保護してください。PBXや内線登録面を、制御なしにインターネット全体へ公開すべきではありません。

TCPポート5061は、SIP over TLS、またはSIPSでよく使われます。SIPシグナリングをTLSで暗号化されたチャネルに載せ、登録、認証、通話開始、セッション交渉を保護します。

ポート5061はシグナリング層を保護しますが、音声や映像メディアそのものが必ず暗号化されるわけではありません。メディアの機密性は、SRTPを使っているか、RTPメディアポート範囲が正しく構成されているかに依存します。

5061は、企業電話システム、SBC、PBX、キャリアSIP trunk、softphone client、暗号化されたシグナリングを必要とするVoIP環境でよく見られます。

TLSを使っていても、SIPSには強い認証、送信元制限、証明書管理、通話ポリシー、登録保護、異常通話監視が必要です。TLSは通信経路を保護しますが、アカウント悪用や通話詐欺を自動的に防ぐものではありません。

5061のトラブルシューティングでは、クライアント側でTLSが有効か、証明書チェーンが信頼されているか、SNIまたはSIP domainが一致しているか、PBXまたはSBCでTLS listenerが有効か、メディアポートとSRTP設定も正しく動いているかを確認してください。

TCPポート5349は、TURN over TLSでよく使われます。TURN relay trafficをTLSで暗号化された接続に載せるためのポートで、WebRTC、ビデオ会議、音声通話、オンライン授業、リモートコラボレーション、リアルタイム通信システムでよく見られます。

TURNは、クライアント同士が直接peer-to-peer通信できない場合に、サーバーがメディアやデータストリームを中継するために使われます。UDP 3478と比べると、TCP/TLSの5349は、企業ネットワーク、厳格なファイアウォール、暗号化された外向き接続だけを許可する環境でのフォールバック経路として使われることが多いです。

ポート5349は接続成功率を高められますが、サーバー帯域とrelay capacityを消費します。TURNに認証、短命の認証情報、quota、悪用監視がない場合、外部ユーザーにオープンリレーとして悪用される可能性があります。

本番環境では、relay scopeを制限し、短期有効な認証情報とアクセス制御を使い、異常トラフィックを監視し、3478、443、設定済みメディアポート範囲とあわせてトラブルシューティングしてください。

UDPポート5353は、mDNS、つまりMulticast DNSの標準ポートです。従来のDNSサーバーに依存せず、同じローカルネットワーク上の機器同士が互いを発見し、.local 名を解決できるようにします。

mDNSは、Bonjour、AirPrint、Chromecast、NAS、プリンター、スマートホーム機器、開発ボード、IoT機器、ローカルデバッグ環境などでよく使われます。local-link discoveryのための仕組みであり、公開インターネット向けサービスではありません。

公開スキャン結果に5353が出てくる場合は、ルーター、ファイアウォール、IoT機器、プリンター、NAS、ホスト設定が、ローカル検出トラフィックを誤ってインターネットへ露出していないか確認してください。

mDNSは機器名、モデル、サービス種別、hostname、ローカル資産の手がかりを明らかにすることがあります。本番環境ではlocal linkまたは制御された内部ネットワークに限定し、公開インターネットへルーティングしないでください。

UDPポート5355は、LLMNR、つまりLink-Local Multicast Name Resolutionで使われます。DNSで名前解決できない場合、WindowsクライアントはLLMNRを使って、同じlocal link上の他のホストへ問い合わせることがあります。

LLMNRはローカルネットワークまたはlocal-link用途を想定した仕組みです。公開インターネット向けサービスではなく、hostname、domainの手がかり、内部命名規則、ネットワーク資産構造を露出する可能性があります。

企業セキュリティでは、LLMNRは名前解決のなりすましやcredential relayの攻撃経路と関連づけられることがよくあります。攻撃者が要求されたホストになりすまし、クライアントに誤った宛先へ認証を試みさせる可能性があります。

環境に信頼できるDNSとActive Directory名前解決が整っている場合、hardening baselineではLLMNRを無効化または制限することがよくあります。UDP 5355を公開境界や信頼できないネットワークで開くべきではありません。

TCPポート5432は、PostgreSQLの標準接続ポートです。バックエンドアプリケーション、psql、データベース管理ツール、BIシステム、マイグレーションスクリプト、コネクションプール、データ同期ジョブがPostgreSQLインスタンスへ接続するためによく使います。

PostgreSQLのアクセス制御は、ポートが開いているかどうかだけでは決まりません。listen_addresses、pg_hba.conf、認証方式、database role権限、SSL/TLS設定が、クライアント接続の可否に影響します。多くの接続失敗は、単純なネットワーク到達性ではなくpg_hba.confや認証設定の不一致が原因です。

ポート5432は価値の高いデータベース入口であり、すべての公開送信元へ露出すべきではありません。本番データベースは通常、内部ネットワーク、VPC、private link、VPN、踏み台サーバー、制御されたコネクションプール、またはアプリケーションサーバーからアクセスします。

PostgreSQLをネットワーク越しに到達可能にする必要がある場合は、送信元IP許可リスト、強い認証、最小権限role、TLS暗号化、監査ログ、接続数制限、バックアップ・復旧管理、異常ログイン監視を組み合わせてください。

5432のトラブルシューティングでは、postgresが想定アドレスで待ち受けているか、ファイアウォールとセキュリティグループが通信を許可しているか、pg_hba.confがクライアント送信元に一致しているか、ユーザー名とdatabase名が正しいか、SSL modeが一致しているか、接続プールが枯渇していないかを確認してください。

TCPポート5601は、Kibanaの標準Webポートです。Kibanaは通常Elasticsearchへ接続し、ログ、メトリクス、検索結果、ダッシュボード、アラート、セキュリティイベント、可視化分析を確認するために使われます。

ポート5601は、単なる静的Webサイトのポートではありません。背後では、ログ、index名、field mapping、ホスト情報、内部サービス名、検索クエリ、stack trace、セキュリティ調査データにアクセスできる場合があります。

Kibanaを公開インターネットへ直接出すのは危険です。読み取り専用に見えるダッシュボードや検索画面であっても、内部トポロジー、業務指標、ユーザー行動、エラーログ、攻撃面の手がかりが漏れる可能性があります。

本番環境では、Kibanaは集中認証、VPN、踏み台アクセス、ゼロトラストアクセス、または制御されたリバースプロキシの背後に置き、space分離、role-based権限、監査ログ、送信元制限を設定してください。

5601を調査するときは、Kibanaが起動しているか、Elasticsearchへ接続できるか、リバースプロキシとbasePath設定が正しいか、認証が必須になっているか、9200や9300などElasticsearch側のポートが誤って公開されていないかを確認してください。

TCPポート5671は、AMQP over TLSでよく使われます。RabbitMQなどのAMQPブローカーは、producer、consumer、background job、内部サービス向けに暗号化されたクライアント接続を提供するため、このポートを使うことがあります。

5671と5672の関係は、暗号化された入口と平文入口の関係に近いです。5672は通常plain AMQPで、5671は接続開始時点からTLSハンドシェイクを行います。ネットワークをまたぐ通信、クラウド間通信、ハイブリッドネットワーク、セキュリティ要件の高いメッセージング経路に向いています。

TLSは通信経路を保護するだけです。RabbitMQの権限設定の代わりにはなりません。user account、password、vhost、exchange、queue、binding、ACL、connection limit、監査ポリシーは別途正しく設定する必要があります。

このポートは通常、application server、worker、制御されたservice mesh、内部メッセージングクライアントだけが到達できるようにすべきです。公開インターネットへ直接出すべきではありません。ネットワーク越しのアクセスが必要な場合は、送信元制限、強い認証、信頼できる証明書、異常接続の監視を組み合わせてください。

5671を調査するときは、クライアントが本当にTLSを使っているか、証明書チェーンが信頼されているか、SNIまたはhostname validationが一致しているか、broker側でTLS listenerが有効か、対象vhostやqueueへアクセスする権限がクライアントにあるかを確認してください。

TCPポート5672は、AMQP 0-9-1でよく使われるポートであり、RabbitMQのデフォルトクライアント接続ポートです。producer、consumer、background worker、task queue、内部サービスが、メッセージのpublish、consume、acknowledgeを行うために使います。

ポート5672は業務メッセージトラフィックを運ぶポートであり、RabbitMQの管理コンソールではありません。アプリケーションはexchange、queue、routing key、binding、acknowledgement、prefetch、dead-letter flowなどを使って、非同期処理、task分散、event delivery、トラフィック平準化を実現します。

5672が誤って公開されていると、外部クライアントがbrokerへ接続を試み、vhostを列挙したり、messageを読み書きしたり、queueをconsumeしたり、eventを偽造したり、大量接続でbrokerに負荷をかけたりする可能性があります。

本番環境では、5672は通常、内部アプリケーションネットワーク、worker cluster、service mesh、制御されたクライアント範囲に限定すべきです。信頼できないネットワークをまたぐ場合は、TLS、SASLまたは強い認証、ACL、quota、監査ログ、送信元制限を使ってください。

5672を調査するときは、RabbitMQが待ち受けているか、vhostが存在するか、認証情報が正しいか、exchangeやqueueの権限で操作が許可されているか、connection limitに達していないか、heartbeat、prefetch、acknowledgement設定が妥当かを確認してください。

TCPポート5900は、VNCで最も一般的な基本ポートで、通常display :0に対応します。VNCはGUIデスクトップを表示・操作するために使われ、Linuxデスクトップ、仮想マシンコンソール、KVM/IPMIコンソール、ラボ環境、組み込み機器、運用ツールで見かけます。

VNCはグラフィカルなリモートデスクトップアクセスを提供するため、RDPなど他のリモート管理入口に近いリスクを持ちます。VNC実装によって、認証、暗号化、クリップボード、ファイル転送、セッション分離の挙動が大きく異なるため、パスワードがあるだけで安全だとは判断できません。

5900を公開インターネットへ露出することは高リスクです。スキャナーは弱いパスワード、空パスワード、古いプロトコル上の問題、暗号化されていないセッションをよく試します。アクセスされると、攻撃者がデスクトップを直接見たり、セッションを操作したり、管理コンソールを扱ったりできる可能性があります。

本番のリモートGUIアクセスでは、5900をインターネットへ直接公開するのではなく、VPN、踏み台サーバー、SSH tunnel、専用のリモートアクセスゲートウェイ、クラウドプロバイダーのコンソールを使う方が安全です。

5900を調査するときは、VNCサービスが起動しているか、display番号が正しいか、必要に応じてlocalhostまたは内部アドレスだけで待ち受けているか、認証と暗号化が有効か、ファイアウォールで送信元が制限されているか、5901や5902など追加セッションが意図せず公開されていないかを確認してください。

TCPポート5901は、通常VNC display :1に対応します。VNCポートは5900にdisplay番号を足して決まることが多く、:0は5900、:1は5901、:2は5902に対応します。

ポート5901は、multi-user Linux desktop、仮想デスクトップ、ラボ環境、遠隔授業用マシン、手動で起動されたvncserver session、複数インスタンスのVNC構成でよく見られます。

リスクは基本的に5900と同じです。5900から5901へ変えたからといって、セキュリティ上の影響が小さくなるわけではありません。背後のサービスがVNCなら、リモートデスクトップ管理入口として扱う必要があります。

このポートが公開されている場合は、弱いパスワード、空パスワード、暗号化されていないセッション、共有デスクトップの露出、クリップボード漏えい、管理者デスクトップへの直接アクセスがないか確認してください。

5901を調査するときは、display :1セッションが存在するか、vncserverが正しく起動しているか、desktop environmentが読み込まれているか、認証設定が正しいか、ファイアウォールが送信元を制限しているか、VPN、踏み台サーバー、SSH tunnel経由にすべきかを確認してください。

TCPポート5902は、通常VNC display :2に対応します。VNCポートは5900にdisplay番号を足して決まることが多く、5902は3つ目のグラフィカルデスクトップセッションを表すことがあります。

ポート5902は、multi-user Linux desktop、ラボ環境、仮想デスクトップ、遠隔授業用マシン、テストホスト、複数インスタンスのVNCサービスでよく見られます。実際の用途は、VNC serverの起動パラメーターとセッション設定によって決まります。

セキュリティ特性は5900や5901と同じです。隣の番号や高い番号になったからといって安全になるわけではなく、VNCが背後にあるなら通常のアプリケーションポートとして扱うべきではありません。

5902の公開は、デスクトップ画面の漏えい、リモート操作、入力中の認証情報の観測、管理ツールの直接操作につながる可能性があります。信頼済み送信元に限定し、できればVPN、踏み台サーバー、SSH tunnel経由にしてください。

調査時は、display番号、VNC session状態、認証と暗号化設定、desktop environment、待ち受けアドレス、ポートマッピング、ファイアウォールルールを確認し、一時的なテストセッションを長期間公開したままにしないよう注意してください。

TCPポート5985は、WinRM over HTTPのデフォルトポートです。PowerShell Remoting、スクリプトによる管理、リモートコマンド実行、構成管理、大規模なWindows Server運用でよく使われます。

WinRMはWindowsのリモート管理入口であり、通常のアプリケーションポートではありません。HTTPを使っていても、認証はKerberos、NTLM、証明書、domain policyに依存することがありますが、transport自体はHTTPS暗号化と同じではありません。

このポートは通常、domain、管理ネットワーク、踏み台経路、自動化プラットフォーム、または制御されたserver group内だけで開くべきです。5985の公開は、remote command execution、credential spraying、lateral movement、自動化された侵害の攻撃面を大きく広げるため、非常に危険です。

ネットワーク境界をまたいでWinRMを使う必要がある場合は、5986のHTTPSを優先し、送信元IP許可リスト、domain policy、最小権限アカウント、監査ログ、JEA、MFA、踏み台サーバーと組み合わせてください。

5985を調査するときは、WinRMサービスが有効か、listener設定が正しいか、Windows Firewallが通信を許可しているか、domain認証が機能しているか、TrustedHostsが乱用されていないか、アカウント権限が過剰でないか、不要なpublic port mappingが存在しないかを確認してください。

TCPポート5986は、WinRM over HTTPSのデフォルトポートです。TLSでWindowsリモート管理トラフィックを暗号化し、PowerShell Remoting、自動構成、リモートコマンド実行、サーバー群の運用によく使われます。

5985と比べると、5986はtransport layer encryptionを提供し、ネットワークをまたぐ管理経路や高セキュリティ要件の管理経路に向いています。ただし、認証、認可、送信元制御が誤っていれば、リスクは依然として高いままです。

このポートを通常のHTTPS Webポートのように扱わないでください。WinRMは管理コマンドの実行、システム情報の読み取り、構成変更、サービス配布が可能なため、権限境界、最小権限アカウント、監査制御が重要です。

本番環境では、5986を踏み台サーバー、自動化プラットフォーム、管理ネットワーク、信頼済み運用ノードからのみ許可してください。信頼できる証明書、強い認証、明示的なファイアウォールルール、完全なコマンド監査を使うべきです。

5986を調査するときは、HTTPS listenerが存在するか、証明書が有効か、hostnameが一致するか、クライアントが証明書チェーンを信頼しているか、認証方式が正しいか、ネットワークポリシーが対象ポートへのアクセスを許可しているかを確認してください。

TCPポート6379は、Redisの標準ポートです。Redisはキャッシュ、セッション保存、ランキング、分散ロック、rate limiting、queue、リアルタイムカウンター、インメモリデータ構造サービスとしてよく使われます。

6379の背後にあるデータは、login session、verification code、job status、business cache、token、queue内容、一時的な設定など、価値の高いruntime stateであることが多いです。無害な読み取り専用ポートではなく、不適切なアクセスは業務ロジックやデータ整合性へ直接影響する可能性があります。

古いRedis構成の多くは、Redisがprivate network内からのみ到達される前提で、弱い認証または認証なしで使われていました。そのようなインスタンスが誤ってインターネットへマッピングされたり、security groupで許可されたりすると、不正アクセス、データ漏えい、データ削除、設定改ざん、悪意あるjob injectionにつながる可能性があります。

本番Redisを公開してはいけません。private addressへbindし、authenticationとACLを有効化し、送信元IPを制限し、必要に応じて危険なcommandを無効化またはrenameし、TLSまたはprivate networkingを使い、slow query、不審なcommand、connection spikeを監視してください。

6379を調査するときは、Redisが誤って0.0.0.0で待ち受けていないか、requirepassまたはACLが有効か、protected modeが有効か、cloud security groupが制限されているか、client connection poolに異常がないか、未認証probeや不審なcommand recordがないかを確認してください。

TCPポート6380は、RedisのTLSポート、または代替Redis接続ポートとしてよく使われます。特にクラウドRedis、マネージドキャッシュ基盤、暗号化されたカスタム構成、複数インスタンス環境で見かけることがあります。

6380は、それ自体が新しいRedisプロトコルを意味するわけではありません。多くの場合、チームやクラウドプロバイダーが、暗号化接続、別インスタンス、特定環境のRedisを、標準の6379とは分けているだけです。実際に待ち受けているサービスとクライアント設定は必ず確認してください。

TLSを使っていても、Redisには認証、ACL、送信元制限、command単位の権限制御が必要です。TLSは通信経路を保護しますが、認証済みユーザーが意図した範囲を超えて重要データを読み書き・削除することまでは防ぎません。

このポートが公開インターネットから到達可能な場合は、ネットワーク越しのアクセスが本当に必要なのかを直ちに確認してください。多くの場合、Redisは公開DB入口ではなく、プライベートネットワーク、アプリケーションサブネット、または制御されたservice mesh内に置くべきです。

6380を調査するときは、クライアント側でTLSが有効か、証明書とhostnameが一致しているか、ACLが正しいか、クラウドのsecurity groupやファイアウォールが送信元を制限しているか、クライアントが誤って別のRedisインスタンスや環境へ接続していないかを確認してください。

TCPポート6443は、Kubernetes API Serverでよく使われるセキュアポートであり、クラスタ制御プレーンへの中心的な入口です。kubectl、controller、scheduler、運用プラットフォーム、CI/CDシステム、クラウド管理ツールは、このポートを通じてクラスタとやり取りすることがあります。

API Serverは通常のWeb APIではありません。Pod、Secret、ConfigMap、Service、Ingress、RBAC policy、Node、Deploymentなど、クラスタの重要リソースを読み取り・変更できます。過剰な権限を持つ認証情報でアクセスされると、実質的にクラスタ全体の制御につながる可能性があります。

6443が公開到達可能であること自体が、常に誤りとは限りません。マネージドKubernetesやリモート運用モデルではAPI Serverアクセスが必要な場合があります。ただし、強い認証、RBAC、ネットワーク許可リスト、監査ログ、証明書、OIDCまたはMFA、最小権限ポリシーで保護されている必要があります。

6443が不適切に公開されていると、攻撃者はAPIの列挙、認証情報の総当たり、弱いkubeconfigの悪用、ServiceAccount tokenの窃取や再利用、広すぎるRBAC権限を使った悪意あるworkloadの展開を試す可能性があります。

6443を調査するときは、API Server証明書、認証方式、RBACルール、監査ポリシー、admission control、anonymous accessが無効か、許可送信元が十分に絞られているか、etcd、kubelet、controller-manager、schedulerなど関連する制御プレーンポートも保護されているかを確認してください。

TCPポート6514は、Syslog over TLSでよく使われます。従来のSyslog転送にTLS暗号化を追加するもので、セキュリティ監査、集中ログ、SIEMパイプライン、ネットワーク機器、サーバー、クラウドログ転送エージェントでよく見られます。

従来のUDP 514や平文Syslogと比べると、6514はネットワーク、データセンター、組織境界をまたぐログ転送に向いています。ログ内容が通信経路上で傍受、偽造、改ざんされるリスクを下げられます。

ログデータには、hostname、account名、private address、アクセスパス、error stack、security event、業務例外の詳細などが含まれることがよくあります。業務アプリケーション用ポートではなくても、信頼できない送信元へ公開すべきではありません。

本番環境では、6514は信頼済みのログクライアント、ログエージェント、ネットワーク機器からの通信だけを受け付けるべきです。証明書検証、TLS version制御、送信元許可リスト、ログ完全性の確認、異常トラフィック監視を組み合わせてください。

6514を調査するときは、クライアント証明書とサーバー証明書が一致しているか、TLS handshakeが成功しているか、受信側基盤がログ形式をparseできているか、ネットワークポリシーが接続を許可しているか、ログ基盤側でqueue滞留やdropが起きていないかを確認してください。

TCPポート6667は、従来の平文IRC接続ポートです。IRCはチャンネルチャット、技術コミュニティ、automation bot、アラート通知、ゲームコミュニティ、一部のレガシーなリアルタイム通信システムで使われてきました。

ポート6667は通常、transport encryptionを提供しません。チャンネルメッセージ、nickname、コマンド、一部の認証データが平文で流れる可能性があります。公開利用では、6697などのIRC over TLSを使う方が一般的に安全です。

IRCサービス自体が自動的に危険というわけではありませんが、公開するとspam、bot abuse、チャンネル荒らし、弱いパスワードの試行、匿名接続の集中を受ける可能性があります。匿名アクセス、登録ポリシー、operator権限は特に重要です。

会社資産やサーバーのスキャンで6667が見つかった場合は、実際のIRCサービスなのか、内部botサービスなのか、別アプリケーションが同じポートを再利用しているだけなのかを確認してください。ポート番号だけでサービスを決めつけないでください。

本番利用では、送信元を制限し、アカウント登録とrole-based権限を有効にし、接続とチャンネル操作を記録し、可能であればTLS対応ポートへ移行してください。内部IRCやbotサービスは通常、VPN、private network、制御されたアクセス境界の背後に置く方が安全です。

TCPポート6697は、IRC over TLSでよく使われます。IRCクライアントとサーバー間の通信を暗号化するためのポートで、現代的なIRCネットワーク、コミュニティチャット、bot通知、ログイン情報を保護したいリアルタイム通信サービスで使われます。

平文IRCの6667と比べると、6697はnickname認証、チャンネルメッセージ、コマンド通信を簡単に傍受・改ざんされにくくします。ただし、アカウント権限、チャンネル運営、bot abuseの問題を自動的に解決するわけではありません。

このポートが公開されている場合は、IRCサービスが本当に公開アクセスを必要としているか、有効な証明書を使っているか、匿名接続が制限されているか、rate limit、abuse control、blacklist、operator監査が整っているかを確認してください。

6697はカスタムTLSサービスに再利用されることもあります。調査時は、TLS証明書、banner、待ち受けプロセス、アプリケーションログ、リバースプロキシ設定から実際のアプリケーションを確認してください。

本番環境では、信頼できる証明書、強い認証、最小権限のbot account、接続rate limit、完全なログを使ってください。内部IRCや自動通知サービスは通常、private networkやVPNに限定する方が安全です。

TCPポート7000には固定された意味がひとつあるわけではありません。一部のIRCネットワークが代替ポートとして使うことがありますが、Javaアプリケーション、middleware、debug service、内部プラットフォーム、カスタム業務システムが使う場合もあります。

7000が開いている場合、IRCやWebサービスだと自動的に分類しないでください。プロセス名、banner、TLS証明書、HTTP応答、アプリケーションログ、コンテナのポートマッピング、リバースプロキシルールを使って、実際のサービスを確認してください。

IRCを提供している場合の主な懸念は、匿名アクセス、平文通信、bot abuse、チャンネル権限です。アプリケーションサービスの場合は、認証のないAPI、debug mode、公開された管理画面、内部API漏えいが問題になることがあります。

ポート7000はチームが一時的に再利用することも多いです。よくある問題は、忘れられたテストサービス、誤ったコンテナマッピング、広すぎるファイアウォールルール、公開された管理インターフェース、複数サービス間での所有者不明です。

本番環境では、このポートの所有者と目的を明確にし、送信元を制限し、認証、ログ、監視を追加してください。一時的なテストサービス、開発endpoint、レガシー入口だけなら、廃止するか統一されたアクセス層の背後に移してください。

TCPポート7001は、Oracle WebLogicの代表的なデフォルトポートのひとつです。Java Webアプリケーション、WebLogic Administration Console、AdminServer、Managed Serverインスタンス、その他middleware関連サービスを提供している場合があります。

7001のリスクは、実際に何が公開されているかによって大きく変わります。管理コンソールや高権限のmiddleware入口である場合、公開露出は弱いパスワード、不正アクセス、deserialization flaw、過去のコンポーネント脆弱性、設定漏えいのリスクを大きく高めます。

WebLogicは、業務アプリケーション、データベース、メッセージキュー、内部サービスの間に位置することがよくあります。侵害されると、アプリケーションのdeployment権限、設定ファイル、data source認証情報、JNDI resource、内部ネットワーク経路へ到達される可能性があります。

本番環境では、7001を公開インターネットへ直接出すことは避けるべきです。業務トラフィックは80/443のリバースプロキシまたはロードバランサーの背後に置き、管理コンソールはVPN、踏み台サーバー、管理ネットワークに制限する構成が安全です。

7001を調査するときは、業務アプリケーションなのか管理endpointなのか、WebLogicのバージョンとpatch level、console認証、default account、JMXやT3の露出、リバースプロキシルール、アクセスログ、不要なpublic mappingがないかを確認してください。

TCPポート7002は、Oracle WebLogicのSSL/TLSアクセス用ポートとしてよく使われます。暗号化されたJava Webアプリケーション、WebLogic Administration Console、AdminServer、Managed Serverインスタンス、その他middleware関連サービスを提供している場合があります。

7001と7002はセットで見つかることがよくあります。7001は平文HTTPまたはデフォルト管理endpointとして使われることが多く、7002はHTTPSとして使われることが多いです。TLSが有効でも、高権限の管理面を公開している場合、安全に公開できるとは限りません。

7002がWebLogic Administration Consoleを指している場合、通常のWebページよりリスクはかなり高くなります。攻撃者は弱いパスワード、default account、過去の脆弱性、deserialization flaw、T3/JMX露出、設定漏えいを試す可能性があります。

本番環境では、業務トラフィックはリバースプロキシ、ロードバランサー、gatewayの背後に置く方が安全です。WebLogic管理endpointはVPN、踏み台サーバー、管理ネットワーク、明示的な送信元許可リストに限定してください。

7002を調査するときは、待ち受けプロセス、証明書設定、WebLogicのバージョンとpatch level、consoleが公開されていないか、認証が十分強いか、アクセスログが完全か、不要なpublic mappingが存在しないかを確認してください。

TCPポート8000は、開発・テスト用Webポートとして非常によく使われます。Python simple HTTP server、Django development server、静的ファイルpreview、テストAPI、内部ツール、一時的なdebug pageでよく見られます。

ポート8000に固定されたプロトコル上の意味はありません。無害なローカル開発ページのこともありますが、保護されていない管理画面、debug endpoint、Swaggerドキュメント、directory listing、テストAPI、コンテナからマッピングされた内部サービスが露出している場合もあります。

主なリスクは、開発サービスが誤って公開インターネットへ出てしまうことです。開発サーバーには、本番向けの認証、rate limit、監査、エラー隠蔽、TLS、権限分離、security headerが不足していることがよくあります。

8000が公開資産に出ている場合は、公開アクセスが本当に必要か確認してください。一時的なテストサービス、preview page、内部APIは、通常private network、VPN、統一gatewayに限定すべきです。

レビュー時は、待ち受けプロセス、framework、HTTP header、directory browsing、debug mode、環境変数漏えい、コンテナのポートマッピング、リバースプロキシルールを確認し、開発入口を本番のように長期間公開しないようにしてください。

TCPポート8053は、代替DNSポートとして使われることがあります。テスト用リゾルバー、内部DNSサービス、DNS over HTTPSやDNS over TLSゲートウェイのバックエンド、コンテナ化されたDNSコンポーネント、実験的なリゾルバーサービスで見かけることがあります。

8053は標準のクライアントDNS問い合わせポートではありません。そのため、このポートが開いている場合は、まず実際のプロトコルを確認してください。DNS問い合わせを処理している場合もあれば、単に別のアプリケーションが同じポートを再利用しているだけの場合もあります。

8053が再帰DNS解決を提供している場合は、オープンリゾルバーになっていないか特に注意してください。制限のない再帰DNSは、不正な問い合わせ、内部ドメイン名の漏えい、プライバシーリスク、より広い攻撃チェーンでの悪用につながる可能性があります。

8053が暗号化DNSゲートウェイのバックエンドポートである場合、通常は公開インターネットへ直接出すべきではありません。frontend proxy、gateway、または制御されたサービスからの通信だけを受け付ける構成にしてください。

トラブルシューティングでは、53、853、443などの関連ポートも確認し、UDP/TCPの挙動、再帰許可ポリシー、ゾーン転送制限、上流リゾルバー、アクセスログ、ファイアウォールルールをあわせて確認してください。

TCPポート8080は、最もよく使われる代替HTTPポートのひとつです。Tomcat、Jetty、Spring Boot、proxy service、内部Webアプリケーション、開発サーバー、管理ページ、コンテナのポートマッピングで頻繁に使われます。

8080の実際の意味は、待ち受けているプロセスによって変わります。通常の業務ページである場合もありますが、管理コンソール、認証なしAPI、プロキシendpoint、debug service、デフォルトのアプリケーションサーバーページ、一時的なテスト環境である可能性もあります。

多くのチームは80番の横に8080をHTTP入口として使いますが、これがセキュリティ上の抜け道になることがあります。公式の443サイトには認証や保護があるのに、8080がgateway、WAF、SSO、アクセス制御を迂回してしまうケースです。

8080が公開されている場合は、公開アクセスが本当に必要か、認証、TLS、リバースプロキシ、rate limit、アクセスログ、security headerが設定されているか、デフォルトページ、サンプルアプリ、管理コンソールが露出していないかを確認してください。

本番環境では、公開トラフィックは80/443または統一gatewayへ集約する方が安全です。8080が内部サービス、health check、debug用途だけなら、送信元アクセスを制限し、直接公開したままにしないでください。

TCPポート8081は、2つ目のHTTPサービスポートとしてよく使われます。複数インスタンスのWebアプリケーション、代替管理ページ、内部API、debug service、開発環境、コンテナ化された構成でよく見かけます。

ポート8081に固定された業務上の意味はありません。開発環境やmicroservice環境では、8080、8000、3000、5000と並んで、アプリケーション、コンテナ、サービスバージョンを分けるために使われることが多いです。

リスクは、一時的なポートがそのまま残り続けることから生まれる場合が多いです。8081には、統一認証の外にある管理画面、テストAPI、debug mode、error stack、APIドキュメント、内部サービス情報が露出していることがあります。

このポートが公開資産に出ている場合は、公式入口で使っているgateway、WAF、SSO、TLSポリシー、アクセス制御を迂回していないか確認してください。特にdefault account、認証なしendpoint、directory browsingには注意が必要です。

本番環境では、このポートの所有者と目的を明確にしてください。公開業務トラフィックは統一入口へ集約し、内部API、health check、debug serviceはprivate network、監視システム、VPN、固定送信元許可リストに限定するべきです。

TCPポート8443は、よく使われる代替HTTPSポートです。Tomcat、Jetty、Spring Boot、Kubernetes Dashboard、gateway service、管理コンソール、内部API、リバースプロキシのバックエンドで使われることがあります。

ポート8443はTLSで保護されたアクセスを示すことが多いですが、HTTPSが有効というだけで公開して安全とは限りません。背後のサービスは、通常の業務ページ、高権限の管理コンソール、クラスターダッシュボード、運用基盤、gatewayからだけ到達すべきバックエンドのどれかかもしれません。

多くの環境では、443を公式の公開入口とし、8443をアプリケーションサーバー、管理面、内部転送に使います。8443がmain gateway、WAF、SSO、アクセス制御、監査ログを迂回している場合、隠れた攻撃面になります。

このポートが公開資産に出ている場合は、公開アクセスが本当に必要か確認してください。証明書設定、認証ポリシー、デフォルトページ、管理コンソール、debug endpoint、リバースプロキシルール、送信元制限を確認してください。

本番環境では、8443はprivate network、管理ネットワーク、VPN、踏み台経路、ロードバランサーのバックエンドに置く方が安全です。公開する必要がある場合は、強い認証、強化されたTLS、rate limit、監査ログ、最小権限アクセスを使ってください。

TCPポート8883は、MQTT over TLSの標準ポートです。IoT機器、センサー、エッジゲートウェイ、モバイルクライアント、バックエンドサービスがMQTT brokerへ安全に接続するためによく使われます。

1883との関係は、暗号化あり・なしのペアに近いです。1883は平文MQTTでよく使われ、8883はTLSにより認証情報、topic subscription、message payloadを通信経路上で保護します。

TLSだけでは十分ではありません。MQTT brokerには、強いidentity check、topic単位の認可、クライアント証明書または強いパスワード、接続数制限、メッセージrate limit、監査ログが必要です。

8883を公開インターネットへ出す場合は、匿名アクセス、弱いアカウント、広すぎるtopic権限、使い回されたデバイス認証情報、不正なsubscribe、偽のpublish、message floodingの可能性を慎重に確認してください。

本番環境では、8883は制御された正当なdevice ingestion endpointになり得ますが、証明書ライフサイクル管理、ACL、デバイス分離、異常接続監視、brokerのバージョン保守と組み合わせるべきです。

TCPポート8888は、よく使われる代替HTTPポートです。開発サーバー、Jupyter Notebook、proxy tool、debug service、内部管理ページ、カスタムWebアプリケーション、一時的なテスト環境で使われることがあります。

ポート8888に固定された業務上の意味はありません。通常のWebページである場合もありますが、特権的なnotebook、open proxy、debug endpoint、directory listing、APIドキュメント、中央認証と連携していない管理画面が露出している場合もあります。

リスクは、一時的なサービスが長期的な公開面になってしまうことから生まれます。開発・debugサービスには、強い認証、TLS、rate limit、監査ログ、送信元制限が不足していることがよくあります。

8888が公開されている場合は、待ち受けプロセスと実際の目的を確認してください。認証なしアクセス、漏えいしたtoken、proxy abuse、debug mode、ファイルアクセス、command execution path、公開された内部APIに特に注意してください。

本番環境では、8888は通常private network、VPN、踏み台サーバー、統一gatewayの背後に置くべきです。一時的なテストポートでしかない場合は、利用後に閉じ、関連するファイアウォールやsecurity group ruleも削除してください。

TCPポート9000は、MinIOのオブジェクトストレージAPIでよく使われます。クライアント、SDK、バックアップジョブ、gateway、業務システムがbucketやobject dataへアクセスするために使うことがあります。

ポート9000は他のアプリケーションでもカスタムサービスポートとしてよく再利用されるため、ポート番号だけでMinIOだと判断しないでください。HTTP応答、証明書、プロセス、コンテナイメージ、起動パラメーター、request pathから実際のサービスを確認してください。

MinIO APIである場合、主なリスクはオブジェクトデータへのアクセスです。設定ミスにより、public bucket、漏えいした認証情報、広すぎるpolicy、不正なupload/download、機密ファイルの露出が起こる可能性があります。

9000が通常のアプリケーションサービスを提供している場合も、公式入口である認証、TLS、WAF、gateway routing、監査ログ、rate limitを迂回していないか確認してください。

本番環境では、MinIO APIアクセスは通常private network、専用gateway、リバースプロキシ、制御された送信元範囲に限定する方が安全です。公開が必要な場合は、強い認証、最小権限policy、TLS、アクセスログ、bucket policy review、異常なdownload監視を使ってください。

TCPポート9001は、MinIO Consoleでよく使われます。MinIO ConsoleはMinIOのWeb管理画面であり、管理者はbucket、object、user、access key、policy、設定、監視情報、クラスタ状態を確認・管理できます。

9000と9001は一緒に見つかることがよくあります。9000はオブジェクトストレージAPI、9001はブラウザベースの管理コンソールとして使われることが多いです。どちらもデータ保護に直結しますが、9001は特に管理権限まわりのリスクが集中します。

MinIO Consoleが公開インターネットへ露出している場合、攻撃者は弱いパスワード、漏えいしたaccess key、デフォルト設定、過去の脆弱性、セッション乗っ取りを試す可能性があります。Consoleへのアクセスは、bucket権限、object data、access policyに影響する場合があります。

本番環境では、9001は通常、private network、VPN、踏み台サーバー、管理ネットワーク、または統一されたidentity layerの背後に置くべきです。通常の公開入口として直接露出したままにしないでください。

このポートをレビューするときは、Consoleが本当に必要か、TLSが有効か、管理者アカウントが最小限に抑えられているか、送信元アクセスが制限されているか、監査ログが完全か、デフォルト認証情報が残っていないか、9000のAPIと9001のConsoleが両方誤って公開されていないかを確認してください。

TCPポート9090は、PrometheusのWeb UIとHTTP APIのデフォルトポートです。運用担当者はこのポートを通じてPromQLクエリを実行し、scrape target、ruleの状態、メトリクス、監視パイプラインの問題を確認します。

9090は通常、業務システムを直接制御するポートではありません。ただし、service名、instance address、label、metric名、scrape target、alert rule、クラスタ構成、runtime statusなど、内部情報を大量に公開する可能性があります。

Prometheusは可観測性には非常に有用ですが、同じメトリクスは攻撃者にとっても内部サービス構造、データベース名、middleware構成、ホスト規模、endpoint path、障害傾向を把握する手がかりになります。

公開資産で9090が見つかった場合は、本当に公開アクセスが必要かを確認してください。中央認証、VPN、踏み台アクセス、リバースプロキシ、または送信元許可リストで保護されているかも確認する必要があります。

本番環境では、9090は通常、監視利用者、運用ネットワーク、または制御されたgatewayからのみ到達できるようにし、認証、TLS、監査ログ、最小権限アクセス、Prometheus設定ファイルの安全な管理と組み合わせてください。

TCPポート9092は、Kafka brokerのクライアント接続ポートとして最もよく使われます。producer、consumer、stream processing job、一部の管理ツールは、このポートを通じてKafkaクラスタと通信します。

Kafkaは通常のWebサービスではありません。9092の背後を流れるトラフィックには、業務メッセージ、イベントストリーム、ログパイプライン、注文状態、ユーザー行動、監査データ、システム間の非同期通信が含まれることがあります。

リスクは、単にbrokerへ接続できるかどうかだけではありません。未許可のユーザーがTopicを読み書きできるか、Topic名を発見できるか、consumer groupを確認できるか、メッセージ本文へアクセスできるか、内部システム構成を推測できるかも重要です。

Kafkaの接続性はadvertised.listenersに大きく依存します。Kafkaの問題は単純なポート到達性だけではないことが多く、クライアントが最初のbrokerへ接続できても、その後に受け取ったbrokerアドレスへ実際には到達できない場合があります。

本番環境では、9092は通常、アプリケーションネットワーク、データ基盤ネットワーク、またはプライベートな通信経路に限定し、SASL、TLS、ACL、Topic単位の認可、監査ログ、送信元制限を有効にしてください。

TCPポート9093は、最も一般的にはPrometheus Alertmanagerのデフォルトポートを指します。Alertmanagerは、アラートの受信、グルーピング、silence、ルーティング、表示を行います。

Alertmanagerには、service名、alert label、instance address、障害内容、通知ルート、receiver情報、内部のon-call体制の手がかりが含まれることがあります。そのため、保護なしで公開インターネットへ露出させるべきではありません。

ポート9093はKafkaやその他のシステムで代替ポートとして使われることもあります。ポート番号だけでサービスを決めつけず、応答内容、プロセス名、コンテナイメージ、設定、ネットワーク構成から実際の用途を確認してください。

サービスがAlertmanagerの場合は、認証が有効か、誰でもsilenceを作成できないか、アラートルールや通知先が露出していないか、内部サービス命名が見えていないかを確認してください。

本番環境では、9093は監視ネットワーク、private network、VPN、踏み台サーバー、または中央認証プロキシの背後に置き、Prometheus、運用担当者、制御されたalerting componentだけが到達できるようにしてください。

TCPポート9094は、Kafkaの代替listener、TLS listener、またはmulti-listener endpointとしてよく使われます。チームは、plaintext、暗号化、internal、external、container network、cross-clusterアクセス経路を分けるために、このポートを使うことがあります。

9094はKafka専用に一意に固定されたポートではありません。実際の意味は、brokerのlistenersとadvertised.listeners設定によって決まります。

コンテナ、Kubernetes、複数ネットワークをまたぐ環境では、9094が外部クライアント、TLSクライアント、特定ネットワークセグメント向けに使われることがあります。設定を誤ると、クライアントは最初の接続に成功しても、その後broker metadataで返された到達不能なアドレスを見て失敗します。

このポートがKafkaトラフィックを運んでいる場合は、TLS、SASL、ACL、クライアント証明書、Topic権限、送信元制限が有効か確認してください。

本番環境では、9094もデータ基盤への入口として扱い、公開インターネットへ安易に露出させるべきではありません。代替ポートであっても、Kafka brokerレベルのアクセス制御と監査の対象にする必要があります。

TCPポート9100は、Prometheus Node Exporterのデフォルトポートです。Linux/UnixホストのCPU、メモリ、ディスク、ファイルシステム、ネットワーク、load、process統計、一般的なシステム健全性メトリクスを公開します。

Node Exporterは通常、ログインやコマンド実行を提供するものではありません。ただし、非常に詳細なホスト実行時情報を公開する可能性があります。攻撃者はこれらのメトリクスから、ホスト規模、ディスク構成、ネットワークインターフェース、負荷パターン、システムバージョンの手がかり、サービス挙動を推測できます。

ポート9100は、無害な公開ページではなく監視データendpointとして扱うべきです。plain textのメトリクスであっても、内部資産、キャパシティ計画、障害状態、インフラ命名規則を明らかにすることがあります。

9100が公開インターネットへ露出している場合は、まずPrometheusだけが到達できるか、ファイアウォール、リバースプロキシ制御、VPN、security groupでアクセスが制限されているかを確認してください。

本番環境では、9100は通常、監視システムのネットワークからのみ到達可能にし、TLS、認証プロキシ、ネットワーク分離、メトリクス最小化、露出最小化の原則を適用してください。

TCPポート9104は、mysqld_exporter、つまりPrometheus MySQL Exporterでよく使われます。MySQLまたはMariaDBの実行時メトリクスを、PrometheusがscrapeできるHTTPメトリクスへ変換します。

このポートは通常、データベースクエリへの直接アクセスを提供しません。ただし、接続数、slow query関連データ、レプリケーション状態、InnoDBメトリクス、table統計、バージョン情報、instance名、性能特性を公開する可能性があります。

9104の主なリスクは情報漏えいです。3306へ直接アクセスできなくても、公開メトリクスからデータベース規模、レプリケーション構成、ピーク負荷パターン、異常状態、内部命名規則を推測される可能性があります。

本番環境では、9104はPrometheusまたは制御された監視ネットワークからのみ到達できるようにし、公開インターネットへ露出させないでください。メトリクスが取得できない場合は、exporterプロセス、MySQL監視アカウント権限、3306への接続性、Prometheusのscrape設定を確認してください。

TCPポート9115は、Prometheus Blackbox Exporterでよく使われます。これは監視対象アプリケーションそのものではなく、PrometheusがHTTP、TCP、DNS、ICMPなどのtargetを能動的にprobeするために呼び出すコンポーネントです。

Blackbox Exporterの主なリスクは、監視ノードに第三者の代わりにprobeを送らせられる点です。適切なアクセス制御がない場合、外部ユーザーが内部アドレス、クラウドmetadata endpoint、制限されたサービスへのリクエストに悪用し、SSRFに似たリスクを作る可能性があります。

このポートは、probe moduleの挙動、target結果、エラー詳細、内部サービスの到達性に関する手がかりを公開することもあります。業務データを直接返さない場合でも、攻撃者がネットワーク境界や内部資産を把握する助けになります。

本番環境では、9115はPrometheusまたは制御されたスケジューリングコンポーネントからのみ到達できるようにし、probe可能なtargetの範囲を制限してください。probe失敗を調査するときは、module設定、target URL、DNS、外向きネットワーク経路、ファイアウォールルール、Prometheusのscrape parameterを確認してください。

TCPポート9187は、postgres_exporter、つまりPrometheus PostgreSQL Exporterでよく使われます。PostgreSQLの実行時情報や性能データを、Prometheusがscrapeできるメトリクスとして公開します。

ポート9187はSQLクエリの通常トラフィックを直接処理するわけではありません。ただし、接続数、トランザクション統計、ロック待ち、レプリケーション状態、データベース名、テーブル統計、インデックス情報、バージョンの手がかり、インスタンスの健全性を公開する可能性があります。

このポートが信頼できないネットワークから到達できる場合、攻撃者はデータベース規模、負荷パターン、レプリケーション構成、障害状態、内部オブジェクト命名を推測できる可能性があります。データベースexporterのメトリクス自体も、機密性のある運用データとして扱うべきです。

本番環境では、9187はPrometheusまたは監視ネットワークからのみ到達できるようにし、データベース接続には最小権限の監視アカウントを使ってください。PostgreSQL監視の問題を調査するときは、exporter本体、5432への接続性、監視アカウント権限、custom query設定、Prometheusのscrape状態を確認してください。

TCPポート9200は、Elasticsearch HTTP APIのデフォルトポートです。クライアント、アプリケーション、Kibana、運用ツール、自動化スクリプトは、このポートを使って検索、documentのindex、index管理、クラスタ状態の確認を行います。

ポート9200は通常のWebポートではなく、高リスクなデータ入口です。ログ、検索index、業務ドキュメント、ユーザー行動データ、error trace、security event、内部システム記録へアクセスできる場合があります。

認証、認可、ネットワーク制限がない場合、外部ユーザーがindex内容を読み取ったり、indexを削除したり、データを変更したり、クラスタ設定を確認したり、公開されたクラスタをより大きな影響の足がかりに使ったりできる可能性があります。

9200が公開資産で見つかった場合は、まずsecurity機能、role-based権限、TLS、送信元制限、監査ログが有効かを確認してください。分かりにくいindex名や非公開のpathに頼ることは、有効な保護とは言えません。

本番環境では、9200は通常private network、アプリケーションネットワーク、VPN、gateway、または制御されたリバースプロキシの背後に置き、公開インターネットのすべての送信元へ直接公開すべきではありません。

TCPポート9300は、Elasticsearchのtransport通信でよく使われます。主にノード間の内部通信を目的としており、通常のユーザークエリ用ポートではありません。

クラスタノードは、このポートを使ってnode discovery、cluster stateの同期、shard allocation、データレプリケーション、内部リクエスト転送を行います。Elasticsearchクラスタの安定性と一貫性にとって重要なポートです。

9300を信頼できないネットワークへ公開することは非常に危険です。攻撃者がクラスタノードをprobeしたり、ノード間通信へ干渉したり、設定ミスのある環境ではクラスタ参加、内部状態の確認、shard配置やcluster healthへの影響を試したりする可能性があります。

このポートは通常、Elasticsearchノード間だけに開くべきで、一般クライアント、オフィスネットワーク、公開インターネットから到達できる状態にすべきではありません。複数ホスト構成では、security group、ファイアウォール、private networkingでノード間アクセスを厳密に制限してください。

9300に関する問題を調査するときは、HTTP APIポートとして扱うのではなく、node discovery設定、cluster name、証明書、TLS、ノード間ネットワーク、バージョン互換性、ファイアウォールルールを確認してください。

TCPポート9418は、native Git protocolでよく使われます。通常は git://host/repo.git のようなURLでアクセスされます。Git objectを低オーバーヘッドで効率よく転送するために設計され、public repositoryの匿名cloneやfetchで使われてきました。

Git protocolは通常、transport encryptionを提供せず、認証、権限制御、監査性が必要なコードアクセスには向いていません。現代の本番環境では、Git over SSH、Git over HTTPS、またはコードホスティング基盤を通じた制御されたアクセスがより一般的です。

9418が公開インターネットへ露出している場合は、明示的にpublicでread-onlyなrepositoryだけを提供しているか確認してください。内部プロジェクト名、branch、commit history、設定ファイル、secretの痕跡、機密性のある過去コードが見えていないかも確認が必要です。

ポート番号だけでサービスを判断しないでください。待ち受けプロセス、repository root、export rule、アクセスログ、ファイアウォールポリシー、現在もこの入口に依存しているworkflowがあるかを確認してください。レガシー入口だけなら、HTTPSまたはSSHへ移行して閉じるのが望ましいです。

TCPポート9443は、HTTPSの管理endpointまたは代替HTTPSポートとしてよく使われます。gateway console、device backend、application serverの管理画面、Kubernetes関連コンポーネント、MinIO Console、カスタム運用基盤をホストしている場合があります。

9443の実際の意味は、待ち受けているプロセスに大きく依存します。普通のHTTPSに見えても、その背後には高権限の管理プレーン、設定センター、証明書管理システム、ユーザー権限コンソール、監査設定、インフラ制御パネルがあるかもしれません。

このポートが公開インターネットへ露出している場合は、認証方式、MFA、デフォルトアカウント、弱いパスワード、管理path、TLS証明書、リバースプロキシルール、送信元IP制限、監査ログを慎重に確認してください。

本番環境では、9443はVPN、踏み台サーバー、内部管理ネットワーク、または中央ID gatewayの背後に置く方が安全です。公開アクセスが避けられない場合は、強い認証、最小権限role、rate limit、alerting、明示的な送信元アクセス制御を使ってください。

UDPポート10000は、特にAsterisk、FreeSWITCH、SIP gateway、PBX、企業電話基盤で、RTP/RTCPメディアポート範囲の開始点としてよく使われます。

5060や5061のようなSIPポートは、主に登録、通話開始、セッション交渉を扱います。実際の音声や映像payloadは通常、RTPメディアポートを通ります。通話はつながるが音声が聞こえない問題の多くは、NAT、ファイアウォール、security groupによってRTPポートが遮断されていることが原因です。

10000はあくまでよくある開始点であり、VoIPシステムが単一の固定ポートだけを使うという意味ではありません。実際のメディア範囲は通常UDPポート範囲であり、PBX、SBC、carrier trunk、WebRTC/TURN設定に照らして確認する必要があります。

RTPメディアポートは必要なpeerだけを許可し、SBC、SRTP、QoS、NATポリシー、トラフィック監視と組み合わせて使うべきです。公開する場合は、probe、悪用、盗聴、予期しない帯域消費を減らすため、広すぎる許可ルールを避けてください。

TCPポート10250は、KubeletのセキュアAPIポートで、各Kubernetesノード上で動作します。コントロールプレーン、監視コンポーネント、または認可されたクライアントが、ノード状態、Pod情報、コンテナログ、runtimeメトリクスを取得し、制御された条件ではノード単位の操作を行うために使います。

このポートは非常に機密性が高いです。Kubeletはノードとコンテナ実行境界に近い位置にあり、設定を誤ると、攻撃者がコンテナ情報を読んだり、ログへアクセスしたり、workloadを調べたり、より深刻な場合にはノード上で動くコンテナへ影響を与えたりできる可能性があります。

本番環境では、10250へ到達できるのはKubernetes API Server、信頼済みの監視システム、必要なクラスタコンポーネントだけに限定すべきです。認証、認可、TLS検証を有効にし、利便性のために公開インターネットや広い内部ネットワークへ直接公開しないでください。

10250を調査するときは、kubeletの起動フラグ、証明書設定、webhook認証・認可、Node authorizer、RBAC、network policy、ファイアウォールルール、クラウドのsecurity groupを確認してください。インターネットから到達できる場合は、ただちにアクセスを制限し、不正な公開がなかったか確認してください。

TCPポート10255は、Kubeletのレガシーなread-only HTTPポートです。以前は、監視システムやトラブルシューティング用スクリプトが、ノード状態、Pod一覧、コンテナ情報、一部のruntimeメトリクスを読み取るために使うことがありました。

このポートの主な懸念は、歴史的に強い認証・認可を持たない構成が多かったことです。read-onlyであっても、node名、namespace、Pod名、image、label、環境の手がかり、内部サービス構造、workload詳細を公開する可能性があります。

現代的なKubernetes環境では、10255に依存するべきではありません。保護された10250、metrics-server、kube-state-metrics、Prometheusのscrape設定、またはKubernetes API Server経由の取得を優先してください。

10255が開いている場合、特に公開インターネットから到達できる場合は、まずkubeletのread-only-portがまだ有効になっていないか確認してください。本番では無効化するか、少なくとも信頼済み監視ネットワークだけに制限し、認証・認可されたendpointへ収集経路を移行すべきです。

TCPポート10256は、kube-proxyのhealthz endpointでよく使われます。local probe、ロードバランサー、ノード、またはクラスタコンポーネントが、kube-proxyが正しく動作しているかを確認するために使います。

kube-proxyは、iptables、IPVS、または別のdata plane実装を使い、Serviceからbackend Podへの転送ルールを維持します。ポート10256は通常のアプリケーション入口ではありませんが、ノード上のネットワークプロキシの健全性を示します。

このポートを公開インターネットへ出したり、一般ユーザーがアクセスしたりする必要は通常ありません。公開されていても直接クラスタ制御につながるとは限りませんが、コンポーネント状態を漏らし、Kubernetesノードの発見可能な攻撃面を増やします。

Serviceルーティング問題を調査するときは、10256のhealth状態に加えて、kube-proxyログ、ノードの転送ルール、CNIの健全性、NodePort範囲、ファイアウォール、security groupも確認してください。本番環境では、クラスタ内部または信頼済み監視システムからのアクセスだけを許可してください。

TCPポート10257は、kube-controller-managerのセキュアポートで、通常はKubernetesのコントロールプレーンノード上で動作します。コントロールプレーンコンポーネントや監視システム向けに、ヘルスチェック、メトリクス、controller関連の状態を公開します。

kube-controller-managerは、Node、Deployment、ReplicaSet、Endpoint、Namespace、ServiceAccountなど、多くのcontrol loopを実行します。これは中核的なコントロールプレーンコンポーネントであり、通常のアプリケーションサービスのように公開すべきものではありません。

10257は通常、直接のユーザー向けアプリケーションendpointではありませんが、それでも内部コントロールプレーンのインターフェースです。不適切に公開されると、コントロールプレーンの健全性、メトリクス、バージョンの手がかり、コンポーネント構成が見える可能性があり、スキャンや攻撃試行の対象面も増えます。

本番環境では、10257をコントロールプレーンノード、local probe、信頼済み監視システムに限定し、TLS、認証、認可、ネットワーク分離、監査を有効にしてください。公開インターネットから到達できる場合は、ただちに公開範囲を縮小し、コントロールプレーン全体の攻撃面を見直してください。

TCPポート10259は、kube-schedulerのセキュアポートで、通常はKubernetesのコントロールプレーンノード上で動作します。主にヘルスチェック、メトリクス公開、scheduler状態の確認に使われます。

kube-schedulerは、新しく作られたPodやpending状態のPodをどのノードに配置するかを決定します。resource request、affinity、taintとtoleration、topology constraint、scheduling policyなどを考慮するため、重要なコントロールプレーンコンポーネントです。

ポート10259を通常のWebポートや業務入口として扱うべきではありません。インターフェースが主にhealthやmetrics向けであっても、scheduler状態、バージョンの手がかり、コントロールプレーン構成、クラスタのruntime特性を公開する可能性があります。

本番環境では、このポートをコントロールプレーン、local probe、信頼済み監視システムに限定してください。スケジューリング問題を調査するときは、10259のhealth状態に加えて、schedulerログ、event、Podがpendingになる理由、ノードリソース、API Serverへの接続性を確認してください。

TCPポート11211は、Memcachedのデフォルトサービスポートです。アプリケーションサーバーが、session、query result、設定の一部、一時オブジェクト、頻繁に参照されるkey-valueデータをキャッシュし、データベース負荷を下げて応答速度を高めるためによく使います。

Memcachedは信頼済みプライベートネットワーク内で使うのが基本です。多くの構成では、クライアントがすでに制御された環境にいることを前提にしており、公開インターネット向けの認証付きサービスとして設計されていません。

11211が信頼できないネットワークへ露出している場合、攻撃者がキャッシュ値を列挙・読み取り、悪意あるcache entryを書き込み、cacheをflushし、cached contentから業務構造、sessionの手がかり、内部データパターンを推測する可能性があります。

本番環境では、Memcachedはprivate addressまたはloopback addressへbindし、アプリケーションサーバーからのみ到達できるようにしてください。security group、ファイアウォール、VPC rule、コンテナnetwork policy、狭い送信元範囲で制限します。公開到達可能な場合は直ちに外部アクセスを閉じ、機密データがcacheされていなかったか確認してください。

UDPポート11211は、MemcachedのUDPアクセス経路です。TCP 11211と同じキャッシュサービスに属しますが、ネットワーク上の挙動と公開時のリスクはより慎重に扱う必要があります。

このポートが特に危険なのは、Memcached over UDPが反射増幅攻撃に広く悪用されてきたためです。攻撃者は被害者のアドレスを送信元として偽装し、公開されたMemcachedサーバーに大きな応答トラフィックを被害者へ送らせることがあります。

アプリケーションが直接侵害されなくても、公開されたUDP 11211はサーバーを攻撃増幅器に変え、帯域枯渇、クラウドプロバイダーからの制限、レピュテーション低下、コンプライアンス上の問題を引き起こす可能性があります。

本番環境では、通常Memcached UDPを無効化するか、最低でも信頼済みプライベートネットワークに限定すべきです。listen address、起動フラグ、ファイアウォール、security group、コンテナのポートマッピング、クラウドロードバランサールールを確認し、誤って公開されていないことを確認してください。

TCPポート15672は、RabbitMQ Management pluginの一般的なWeb管理ポートです。管理者はqueue、exchange、binding、connection、channel、consumer、user、permission、vhost、cluster healthを確認・管理できます。

これは通常の業務メッセージングポートではなく、管理インターフェースです。誤って公開されると、queue構造、message backlog、接続元、アカウント設定、クラスタ構成が見える可能性があります。

弱いパスワード、デフォルトアカウント、過剰な権限、無制限の送信元アクセスがある場合、15672からqueueをpurgeしたり、permissionを変更したり、messageを確認したり、cluster設定へ悪影響を与えたりできる可能性があります。

本番環境では、15672をVPN、踏み台サーバー、private management network、または制御されたリバースプロキシの背後に置いてください。強いパスワード、最小権限アカウント、TLS、アクセスログ、送信元制限を使います。公開されている場合は、アカウント、権限、アクセスログを直ちに確認してください。

UDPポート19132は、Minecraft Bedrock Editionサーバーで最もよく使われるデフォルトポートです。モバイル、コンソール、Windows Bedrock、その他のBedrockクライアントがマルチプレイヤーサーバーへ接続するために使います。

このポートは通常、ゲーム接続やサーバー検出トラフィックを扱うもので、従来型の管理インターフェースではありません。公開してよいかどうかは、そのサーバーが一般公開向けなのか、ホワイトリスト制コミュニティ向けなのか、友人や家族だけの私的なプレイ用なのかによって変わります。

インターネット公開サーバーでは、アクセス制御、プレイヤーホワイトリスト、サーバーバージョン、プラグインやアドオンの安全性、DDoS対策、リソース制限、ログを確認してください。ゲーム用ポートはデータベースポートほど機密性が高いわけではありませんが、スキャン、flood、サーバー側の脆弱性の影響を受ける可能性があります。

接続トラブルを調査するときは、TCPではなくUDPが許可されているかを確認してください。あわせて、ルーターのポート転送、クラウドのsecurity group、ホストファイアウォール、サーバーのbind address、Bedrockサーバー設定、クライアントバージョンの互換性も確認してください。

TCPポート25565は、Minecraft Java Editionサーバーで最もよく使われるデフォルトポートです。プレイヤーはこのポートを使って、マルチプレイヤーサーバー、プライベートサーバー、mod入りサーバー、公開コミュニティサーバーへ接続します。

このポートは通常、OSの管理インターフェースではありませんが、ゲームサービスを直接外部へ公開します。公開すべきかどうかは、オープン参加型サーバーなのか、ホワイトリスト制なのか、少人数のプライベートグループ向けなのかによって変わります。

25565をインターネットへ公開する場合は、サーバーバージョン、プラグインやmodの入手元、RCON設定、プレイヤー権限、リソース制限、DDoS対策、ログを確認してください。多くのリスクはポート番号そのものではなく、古いサーバービルド、安全でないプラグイン、誤った権限設定から発生します。

接続できない場合は、TCP 25565が許可されているか、サーバーが正しいアドレスで待ち受けているか、ルーターまたはクラウドsecurity groupの転送先が正しいホストか、クライアントバージョン、サーバーMOTD、online-mode認証、プラグイン互換性が正常かを確認してください。

TCPポート25672は、RabbitMQクラスタノード間の内部通信でよく使われます。クラスタメンバーシップ、queueメタデータ同期、状態伝播、ノード間の協調のために、分散Erlangトラフィックを扱います。

これは通常のアプリケーションクライアント用ポートではなく、管理コンソールでもありません。アプリケーションは通常5672または5671でメッセージをpublish・consumeし、Web管理UIは一般的に15672を使います。25672は主にRabbitMQクラスタ基盤の一部です。

25672が信頼できないネットワークへ露出していると、攻撃者がRabbitMQクラスタトポロジー、Erlangノード通信面、内部デプロイ構造をprobeできる可能性があります。直接の管理アクセスがなくても、ノード間ポートの公開は攻撃面を広げます。

本番環境では、25672へ到達できるのはRabbitMQクラスタメンバー、制御されたコンテナネットワーク、またはプライベートサービスサブネットだけにしてください。ファイアウォール、security group、Kubernetes NetworkPolicy、厳密なnode naming、Erlang cookie管理で制限します。

RabbitMQノードがクラスタへ参加できない、ノード切断が頻発する、クラスタ状態が不安定な場合は、4369、25672、5672、5671、15672の接続性を確認してください。あわせてhostname解決、Erlang cookieの一致、ファイアウォールルール、コンテナのネットワークマッピングも確認してください。

UDPポート27005は、Source、GoldSrc、一部のSteamゲームクライアントのネットワーク通信でよく見られます。通常は単独の公開サーバーendpointではなく、ゲームサーバー、Steamネットワークコンポーネント、またはローカルゲームプロセスとデータをやり取りするためのクライアント側・ローカル補助ポートです。

このポートは、27015、27016、27020などのSource engine関連ポートと一緒に現れることがよくあります。27015はゲームサーバー接続やqueryに関連することが多く、27020はSourceTV、query、補助トラフィックで使われる場合があります。一方、27005はクライアント側またはローカルゲームネットワークに関係することが多いです。

セキュリティ面では、27005単体のリスクは通常低めですが、実際に待ち受けているプロセスは必ず確認してください。インターネット向けサーバー上に現れる場合は、本当にゲームクライアントコンポーネントなのか、ゲームサービスなのか、コンテナマッピングなのか、別のサービスが同じポートを再利用しているだけなのかを確認してください。

Source engineの接続問題、サーバー一覧に出ない問題、ローカルマルチプレイの不具合を調査するときは、起動パラメーター、NATマッピング、ファイアウォールルール、UDPの内向き・外向きポリシー、Steam query port、27005、27015、27016、27020などの関連ポートを確認してください。

UDPポート27015は、Source、GoldSrc、多くのSteamゲームサーバーで最もよく使われるポートのひとつです。プレイヤー接続、サーバー検出、query応答、マルチプレイヤーゲームトラフィックで頻繁に使われます。

単一のゲームサーバーでは、27015がデフォルト入口になることが多いです。複数インスタンス構成では、追加サーバーが27016、27017など隣接ポートを使うことがあります。正確な役割は、サーバー起動パラメーター、ゲーム種別、ホスティングプロバイダー設定と照らして確認してください。

このポートはプレイヤー向けに意図的に公開されることがありますが、基本的な保護は必要です。公開ゲームサーバーでは、不要な管理インターフェースを公開せず、強いRCON認証情報を使い、DDoS、query abuse、プラグイン脆弱性、悪意あるクライアント、異常トラフィックを監視してください。

プレイヤーが参加できない、またはサーバー一覧に表示されない場合は、UDP 27015が待ち受けているか、クラウドsecurity groupとホストファイアウォールが通信を許可しているか、NATまたはポート転送が正しいホストを指しているか、Steam query portが設定と一致しているか、サーバーのbind addressと起動パラメーターが正しいかを確認してください。

UDPポート27016は、2つ目のSourceまたはGoldSrcゲームサーバーインスタンス、代替インスタンス、隣接するゲームサーバーポートとしてよく使われます。多くのmulti-server構成では27015から始め、追加インスタンスに27016、27017、その周辺のポートを割り当てます。

正確な用途は、ゲームサーバーの起動パラメーターとホスティング基盤の設定に依存します。プレイヤー接続、サーバーquery、代替ゲームルーム、テストサーバー、特定インスタンスの入口などに使われることがあり、別の固定プロトコルを意味するわけではありません。

27016を公開するのは通常、プレイヤーが特定のゲームインスタンスへ到達できるようにするためですが、公開するUDPポートは必要最小限にしてください。RCON、管理パネル、ファイルマネージャー、ホスト管理サービスを一緒に公開しないでください。

複数インスタンスのゲームサーバーを調査するとき、27016でよくある問題には、ポート競合、複数インスタンスが同じポートへbindしている、NATが誤ったコンテナへ転送している、クラウドsecurity groupが27015しか許可していない、query portとgame portが一致していない、サーバーIPとポートのパラメーターが一貫して更新されていない、といったものがあります。

TCPポート27017は、MongoDBで最もよく使われるデフォルト接続ポートです。アプリケーションサービス、mongosh、データベースドライバー、管理ツールは、query、write、index管理、aggregation、通常運用のためにMongoDBインスタンスへ接続する際によく使います。

ポート27017は通常、単純なWeb endpointやhealth checkではなく、実際のデータベース入口です。背後のサービスには、ユーザー情報、注文、ログ、設定、session、分析イベント、内部システム状態が保存されている可能性があるため、通常のアプリケーションポートより慎重に扱う必要があります。

MongoDBをインターネットへ直接公開することは高リスクです。特に、認証が無効、パスワードが弱い、bindIpが広すぎる、テストDBが誤って本番化された、バックアップインスタンスがインターネットから到達できる、古いデフォルト設定が残っている、security groupが広すぎる場合は危険です。

本番環境では、27017は通常、アプリケーションサーバー、踏み台サーバー、VPN、private network、または制御されたデータベースアクセス範囲に限定すべきです。認証、TLS、最小権限ユーザー、IP許可リスト、監査ログ、バックアップポリシー、異常接続監視を有効にしてください。

接続失敗を調査するときは、ポートが開いているかだけで判断しないでください。mongodのbind address、authentication database、ユーザー権限、TLSと証明書設定、replica set名、クライアントが到達可能なreplica set memberアドレスを受け取っているか、ホストファイアウォールやクラウドsecurity groupが現在の送信元を許可しているかも確認してください。

TCPポート27018は、MongoDB sharded cluster内のshard serverでよく使われます。shardはアプリケーションデータの一部を保持し、mongos router、config server、他のshard、replica set memberと連携して、sharded database architectureの一部として動作します。

ポート27018は通常、アプリケーションが直接接続すべき主要endpointではありません。多くのアプリケーションはmongos routing layerへ接続し、mongosがshard keyとcluster metadataに基づいて正しいshardへリクエストを振り分けます。shardへ直接接続すると、本来のアクセス経路を迂回し、トラブルシューティングや権限管理が複雑になります。

27018がインターネット向け資産に現れる場合は、重大な検出として扱ってください。shard nodeには実際の業務データが含まれることが多く、公開されるとデータ読み取り、データ変更、index破損、リソース枯渇、横展開、クラスタトポロジーの漏えいにつながる可能性があります。

本番環境では、shard serverはdatabase network、Kubernetes cluster network、専用VPC、または厳しく制御されたsecurity group内に限定してください。通常、mongos、内部クラスタメンバー、バックアップシステム、必要な運用入口だけにアクセスを許可し、認証、TLS、keyFileまたはx.509による内部認証、最小権限role、監査ログを有効にします。

sharded clusterの問題を調査するときは、shard replica setの健全性、mongos routing設定、config server metadata、shard key設計、chunk migration、network latency、disk capacity、27017、27018、27019などMongoDB関連ポート間の接続性を確認してください。

TCPポート27019は、MongoDB sharded cluster内のconfig serverでよく使われます。config serverは通常のアプリケーション読み書きを主目的にするものではなく、sharding状態、chunk配置、ルーティング情報、クラスタ設定など、重要なクラスタメタデータを保持します。

このポートはsharded clusterの運用に不可欠です。mongosはconfig serverのメタデータを参照して、どのshardへリクエストを送るべきかを判断します。config serverが利用できない、またはメタデータの健全性に問題がある場合、アプリケーション側ではquery失敗、routing error、chunk migration問題、クラスタ管理操作の停止が起こることがあります。

ポート27019を公開入口として扱うべきではありません。通常のアプリケーション用データベースポートに見えない場合でも、config serverのメタデータが漏えいしたり破損したりすると、MongoDB sharded cluster全体の可用性、データルーティング、運用上の安全性に影響します。

本番環境では、config serverは厳しく制御された内部ネットワークに置き、mongos、クラスタメンバー、必要な運用・バックアップコンポーネントからのみ到達できるようにしてください。認証、TLS、内部クラスタ認証、最小権限、監査ログ、信頼できるバックアップを有効にし、通常のアプリケーションがconfig serverへ直接接続しないようにします。

27019まわりの問題を調査するときは、config server replica setの健全性、mongosからconfig serverへの到達性、クラスタメタデータの一貫性、時刻同期、ディスク容量、認証設定、shard、mongos router、config server間のバージョン互換性を確認してください。

UDPポート27020は、Source engineゲームサーバーの補助通信でよく見られます。SourceTV、観戦モード、リプレイ機能、サーバーquery、関連するゲームコンポーネントの追加ネットワークトラフィックに使われることがあります。

このポートは単独で判断するべきではありません。27015、27016、27017、27005などの近いポート、サーバー起動パラメーター、ゲーム種別、query port設定、SourceTV設定とあわせて用途を確認するのが確実です。

プレイヤーは参加できるのに、サーバー一覧、観戦モード、リプレイ、query状態だけが不安定な場合、原因はメインのゲームポートではないかもしれません。27020または関連するUDPポートが遮断されている、誤ってマッピングされている、または違うinterfaceへbindされている可能性があります。

公開ゲームサーバーでは、必要に応じてこのポートを開放できますが、許可するUDP範囲はできるだけ狭くしてください。調査時は、ホストファイアウォール、NATルール、クラウドsecurity group、コンテナのポートマッピング、実際のゲームサーバー設定を確認してください。

TCPポート29092は、KafkaのDocker Compose、Kubernetes、ローカル開発クラスタ、またはinternal listenerとexternal listenerを分ける構成でよく使われます。通常、新しいKafkaプロトコル用のポートではなく、内部・外部のアクセス経路を区別するために選ばれたbroker listenerです。

Kafkaクライアントは、最初のbootstrap addressへ接続するだけでは終わりません。brokerへ接続した後、advertised.listenersで返されるbroker metadataを読み取り、そのadvertiseされたbroker addressへ接続します。29092やadvertised.listenersの設定が誤っていると、最初の接続は成功してもproducerやconsumerが後でtimeoutすることがあります。

コンテナ化された環境では、29092がコンテナネットワーク内のlistenerを表し、9092、9093、9094がhostアクセス、TLS、SASL、外部クライアント向けに使われることがあります。実際の意味は、listeners、advertised.listeners、listener.security.protocol.map、そしてクライアントがどのネットワーク位置にいるかによって決まります。

このポートは通常、Kafkaクラスタ、アプリケーションサービス、コンテナネットワーク、private networkに限定すべきです。Kafka listenerをインターネットへ公開すると、Topic列挙、不正なmessage読み書き、consumer group情報の漏えい、データ汚染、業務イベントストリームの窃取につながる可能性があります。

Kafka接続性を調査するときは、9092、9093、9094、29092のlistener設定、DNS解決、DockerまたはKubernetesネットワーク、TLS/SASL設定、security group、client bootstrap.servers、brokerがadvertiseするアドレスがクライアントから到達可能かを確認してください。

TCPポート30000は、KubernetesのデフォルトNodePort範囲である30000-32767の開始点です。NodePortは各node IP上に固定ポートを開き、外部トラフィックをServiceとその背後のPodへ転送します。

ポート30000だけでは、特定のアプリケーションを示すわけではありません。Webサービス、API、監視endpoint、管理コンソール、データベースproxy、ゲームサーバー、クラスタ内のほぼ任意のworkloadへマッピングされている可能性があります。実際のリスクは、公開されているService、backend Pod、アクセス制御によって決まります。

NodePortは内部Kubernetesの細部だと誤解されることがありますが、実際にはnode上にネットワーク入口を作ります。node IPがインターネットから到達可能であれば、NodePortもインターネット向けになっている可能性があります。

本番環境では、任意のNodePortよりも、Ingress、LoadBalancer、gateway、private load balancer、制御されたreverse proxyを通じてServiceを公開する方が扱いやすいことが多いです。NodePortが必要な場合は、Serviceの目的を文書化し、送信元を制限し、認証を有効にし、NetworkPolicyを適用し、アクセスログを残してください。

NodePortアクセスを調査するときは、Service type、nodePort値、kube-proxy状態、node security group、ホストファイアウォール、Pod readiness、EndpointSlice、externalTrafficPolicy、トラフィックが実際にtarget Podへ届いているかを確認してください。

TCPポート32767は、KubernetesのデフォルトNodePort範囲である30000-32767の終点です。割り当て可能なNodePort値の上限を表すもので、この番号だけで固定の業務サービスを示すわけではありません。

32767が開いている場合は、まずKubernetes ServiceにこのnodePortが実際に割り当てられているか確認してください。クラスタによって、同じNodePort値がWebサービス、内部API、監視コンポーネント、管理コンソール、一時的なテストアプリなど、まったく異なるbackendを指していることがあります。

NodePortの重要なリスクは、Serviceをすべてのnode IPへbindする点です。node networkが到達可能であれば、特にsecurity group、load balancer rule、Ingress policyが揃っていない場合、外部ユーザーがbackend Serviceへ直接アクセスできることがあります。

本番クラスタでは、30000-32767範囲の開いているポートを定期的に監査し、それぞれのNodePortに明確な業務目的、所有者、アクセス制御モデル、廃止計画があるか確認してください。nodeレベルの直接公開が不要なServiceは、通常ClusterIPまたは制御されたgateway経路を使うべきです。

調査時は、Kubernetes Service manifest、kubectl get svcの出力、kube-proxy rule、nodeの待ち受けポート、firewall policy、cloud security groupから、32767がServiceへマッピングされているか、そのbackendが想定どおりかを確認してください。

TCPポート49152は、IANAのdynamic/private port範囲の開始点です。通常、固定サービスのデフォルト待ち受けポートではなく、OSが一時的なクライアント側接続のためにこの範囲からポートを選ぶことがよくあります。

この範囲のポートは、ブラウザがWebサイトへアクセスする、アプリケーションがデータベースへ接続する、サービスがAPIを呼び出す、proxyがトラフィックを転送する、コンテナが外向き接続を行う、テストプロセスがローカル通信する、といった場面でよく現れます。接続が終わると通常そのポートは解放され、後で別のプロセスに再利用されます。

スキャンで49152がopenとして表示される場合、ポート番号だけではサービスを特定できません。ホスト上の実際の待ち受けプロセス、起動引数、コンテナのポートマッピング、NATルール、ファイアウォールポリシー、通信方向を確認してください。

通常のephemeral client portとして使われているなら低リスクですが、アプリケーションが意図的にこのポートで待ち受けている場合は話が変わります。高い番号のdynamic range portだから自動的に安全だと判断せず、ephemeral rangeだからといって無視しないでください。

本番環境では、dynamic portを安定した公開入口として使うべきではないことが多いです。このポートが継続的にlistenしている場合は、実サービス、debug tool、reverse proxy backend、残ったテストプロセス、想定外のプログラムのどれなのかを確認し、必要に応じてアクセスを制限してください。

UDPポート51820は、WireGuardの待ち受けポートとしてよく使われます。WireGuardはUDP上で暗号化トンネルを構築するVPNで、リモートアクセス、拠点間VPN、クラウドサーバー間ネットワーク、自宅ネットワークへの接続、軽量なプライベートネットワークによく使われます。

WireGuardは従来型のVPNスタックと比べて構成が比較的シンプルです。ただし安全性は、公開鍵・秘密鍵の管理、peer定義、AllowedIPs、ルーティングルール、ファイアウォールポリシーに大きく依存します。ポートが開いているだけで誰でもトンネルへ入れるわけではありませんが、peer管理が甘い、経路が広すぎる、鍵が漏えいしている場合は、内部ネットワークへの到達範囲が大きく広がります。

51820は、正当なVPNクライアントのためにインターネットへ公開されることがあります。ただし、それはプライベートネットワークへの境界を公開しているという意味でもあります。本番環境では、秘密鍵を厳重に保護し、peerを定期的に見直し、AllowedIPsを必要最小限に絞り、接続状況を監視し、リモート端末から不要な内部ネットワークへ到達できないようにしてください。

WireGuardに接続できない場合のよくある原因には、UDP 51820が遮断されている、NAT転送が誤っている、クラウドのsecurity groupルールが不足している、クライアントのEndpoint設定が間違っている、AllowedIPsが競合している、IP forwardingが無効、またはホストファイアウォールがトンネルinterfaceの通信を許可していないことがあります。

インターネットスキャンで51820が開いている場合は、それが本当にWireGuardか、想定したpeerだけにサービスしているか、古い鍵や退職者・退会ユーザーのpeerが残っていないか、トンネル経由で到達できる内部ネットワークが最小権限になっているかを確認してください。

TCPポート65535は、利用可能な最大のポート番号であり、IANAのdynamic/private port範囲の上限です。通常、特定の標準サービスを表すものではなく、ephemeral connection、カスタムサービス、テスト構成、または通常とは少し違うスキャン結果として見つかることがあります。

通常のネットワーク通信では、OSがdynamic range内の高い番号のポートを、短命な外向き接続のローカルクライアントポートとして選ぶことがあります。65535という値自体は主に境界値であり、それだけで特別な業務上の意味を持つわけではありません。

ポート65535が継続的にlistenしている場合は、単なるdynamic portとして片付けず、実際のプロセスを確認してください。アプリケーション、プロキシ、debug tool、マルウェア、設定ミス、残ったテストサービスなどが、競合回避や目立ちにくさのために高い番号のポートを使うことがあります。

調査では、ss、netstat、lsof、プロセスのコマンドライン、コンテナのポートマッピング、system log、ファイアウォールルール、外部スキャン結果を組み合わせて確認してください。一時的な外向きクライアントポートなのか、他ホストから到達可能な本物の待ち受けサービスなのかを区別することが重要です。

本番環境では、通常65535を安定した公開入口として使うべきではありません。正当な業務上の理由がある場合は、目的を明確に文書化し、認証、送信元制限、監視、変更記録を追加してください。明確な用途がない場合は、listenerを閉じるか、制御されたネットワークに限定してください。