インフラ＆ネットワーク深層学習シミュレーター | DNS・HTTPS・SSH・攻撃者視点の通信可視化ツール

Domain Name System (DNS) の仕組み

ネットワーク通信を行う際、ホスト（PCやサーバー）はパケットの宛先ヘッダーに必ず32ビットの「IPv4アドレス」または128ビットの「IPv6アドレス」を書き込む必要があります。しかし、IPアドレスは人間が覚えるのが困難なため、example.com のようなドメイン名をDNSによって名前解決します。

分散型データベースと再帰検索

DNSは単一の巨大データベースではなく、世界中に分散配置されたツリー構造をとっています。クライアントが最初にする「再帰的問い合わせ」を受けたDNSリゾルバは、ルート、TLD、権威ネームサーバーへとバケツリレー式に「反復的問い合わせ」を投げて最終解答を導き出します。

DNSセキュリティ (DNSSEC)

DNS応答パケットを途中で偽装して攻撃者のサーバーにアクセスさせる「DNSキャッシュポイズニング」への防御として、電子署名により送信元の正当性と完全性を検証する DNSSEC や、問い合わせ自体をHTTPS/TLSで暗号化する DoH (DNS over HTTPS) が普及しています。

HTTP と HTTPS (SSL/TLS 1.3) の実現方法

Webブラウザ等で最も多用される通信です。HTTPは「アプリケーション層」で直接テキストデータを流しますが、HTTPSはトランスポート層(TCP)とアプリケーション層の間に「SSL/TLS（セキュアソケットレイヤー）」を挟んで安全を保証します。

TCP 3-way Handshakeの仕様

HTTP/HTTPSは信頼性重視 of 信頼性のプロトコルであるため、下位層であるTCPレイヤーで最初に次の3段階で接続を確立します。

Client ---- [SYN] ----> Server (接続希望)

Client <-- [SYN-ACK] -- Server (承諾 & 接続希望)

Client ---- [ACK] ----> Server (了解、確立完了)

SSL/TLS 1.3 鍵交換・証明書検証

TLS 1.3では接続のオーバーヘッドを削減するため、1往復（1-RTT）で鍵交換を完了させます。

Client Hello: 利用可能な暗号スイートや鍵共有のためのパラメータを初期段階で一気に送信。
Server Hello & Certificate: サーバーが鍵共有情報を返し、自身の「サーバー証明書」を送信。
検証と復号: クライアントはCA（認証局）の署名付き証明書を検証し、接続先の正当性を担保、共有秘密から共通鍵を算出します。

SSH と SFTP サブシステムの構造

SSH (Secure Shell) は、主にサーバー管理者がCUI（キャラクターユーザーインターフェース）でリモート制御を行うために使用される安全なセッションです。内部でSFTPが動くメカニズムについて解説します。

認証とセッションチャネル

SSHは、共通鍵での暗号化トンネルが開通した後に「ユーザー認証（公開鍵認証など）」を行います。

ユーザーがサーバーにあらかじめ登録した「公開鍵」に対し、サーバーはランダムなチャレンジデータを送信。
ユーザーは自身の「秘密鍵」でチャレンジデータを署名して送り返し、サーバー側で検証。パスワードをネットワーク上に流すことなく安全に認証。

SFTP (SSH File Transfer Protocol)

SSH接続（Port 22）の中に、SFTPサブシステムという仮想チャネルを開くことで、同じ暗号化トンネルを利用したセキュアなファイル転送を実現します。後述するクラシックな「FTP」と異なり、別のポートをファイアウォールで開放する必要が一切ないため非常に安全かつ扱いやすいのが特長です。

WebSocket（リアルタイム双方向常時接続）

従来のHTTPは「クライアントからのリクエストに対してサーバーが応答する（1対1の往復）」という原則があり、サーバー発の自発的な情報送信（プッシュ通知、チャット、株価自動更新）が困難でした。これを完全に解決するのが WebSocket です。

HTTPプロトコル・アップグレードの仕組み

WebSocketは既存のWebポート（80/443）を利用してセッションを開始するため、最初に「HTTPプロトコルでのUpgrade要求」を送信します（プロトコルハンドシェイク）。

[GET /chat HTTP/1.1]

Host: example.com

Upgrade: websocket

Connection: Upgrade

Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==

サーバー側がWebSocketに対応している場合、ステータスコード 101 Switching Protocols を返し、これ以後同じTCP接続が完全に「双方向の自由なデータトンネル」に化けます。

オーバーヘッドの最小化

一度ハンドシェイクが終わると、メッセージ送信時のヘッダー情報はわずか数バイト（2〜10バイト）に激減します。毎回のHTTPヘッダー（数百〜数千バイト）を完全に排除できるため、超低遅延で高頻度なデータ転送が実現します。

FTP と SFTP の接続メカニズム比較

ファイルをサーバーに転送するために使用されるプロトコルですが、通信の実現方式や安全性の面で決定的な設計の違いがあります。

FTPの「制御」と「データ」チャネルの分離

クラシックなFTP (Active Mode) は、通信経路を次の2つに完全に切り分けます。

コントロール接続 (Port 21): コマンドやログインパスワード、応答ステータスのみを運ぶ経路。
データ接続 (Port 20): ファイル一覧や実際のファイルバイナリを送受信するため、コマンドとは別に対象データを流す.

🚨 **ファイアウォール問題**: アクティブモードでは、サーバー側からクライアントが動的に指定したポートに向けて接続を開始します。そのため、クライアント側のファイアウォール（NATなど）で弾かれてしまい、接続エラーが頻発します（これに対応するために開発されたのが「パッシブモード (PASV)」です）。

SFTPによる完全な解決

FTPのデメリット（平文パスワードによる盗聴のリスク、およびポートが2つ必要でNATを越えられない問題）を解消したのが SFTP (SSH File Transfer Protocol) です。SFTPは「SSHトンネル（Port 22）」の内部で多重化された論理チャネルとしてすべてのファイルを送信するため、単一のポートを開放するだけで安全にNATの壁を越えることができます。

盗聴(スニッフィング)と攻撃者の仮定

ネットワーク設計における大前提は、「すべての通信経路は信頼できず、悪意あるハッカー（中間者）によって常に盗聴されていると仮定する」という「ゼロトラスト」の思想です。

中間者によるパケットスニッフィング

同じWi-Fiルーター（特に公衆フリーWi-Fiなど）を使用していたり、インターネットプロバイダの経路上であったりすれば、ハッカーは Wireshark などのネットワークパケット解析ソフトを使用して、他人のデータパケットを100%の精度で取得（スニッフィング）できます。

HTTP (Port 80): パケットの中身が「平文の文字列」であるため、パスワードやクレジットカード情報が瞬時に筒抜けになります。
HTTPS (Port 443) / SSH (Port 22): データ全体が完全に難解な共通鍵（AES等）で暗号化されているため、ハッカーがいくらパケットを盗んでも中身を絶対に解読できません。

天文学的な鍵空間の強度

HTTPSやSSHの暗号で使われるAES-256ビット暗号の組み合わせ総数は $2^{256} \approx 1.15 \times 10^{77}$ 通りです。

これは宇宙に存在する全原子の総数（約 $10^{80}$ 個）に迫る規模であり、現在の世界中のスーパーコンピュータや将来の高性能量子コンピュータを総動員して総当たり攻撃（ブルートフォース）をかけたとしても、太陽系が寿命を迎える（数十億年以上）より遥かに長い時間が必要なため、数学的に事実上解読は不可能です。

サーバーとポート番号

IPアドレスが「サーバーというマンション自体の住所」だとすると、ポート番号は「個別の部屋番号」にあたります。サーバーは1つのIPアドレスの中に 0 〜 65535番 のポートを持っています。

主要ポート番号の一覧と役割

Port 21: FTP (ファイル転送・制御用)
Port 22: SSH / SFTP (セキュアシェルログイン & ファイル転送)
Port 23: Telnet (未暗号リモートシェル - 暗号化なし・危険)
Port 80: HTTP (平文Webブラウジング)
Port 443: HTTPS / SSL/TLS (暗号化Webブラウジング)

インフラ・ネットワーク深層学習シミュレーター

ステップ解説