「PCが見慣れないIPアドレスの443番ポートに接続した」というアラートが出ました。次に何を確かめますか。まず時刻、端末、プロセス、宛先を確認し、アプリケーションが何を要求したのか、なぜ注意が必要なのかを考えます。
今回は、その会話に必要なネットワークの基礎です。普段のWebリクエストを1つたどり、事実と推測を分けた通信の観察メモを作ります。面接では、ポート番号を暗記して並べるだけでなく、この小さな調査を説明できることが役立ちます。
始める前に: 第1週を終えてください。自分のWindows PC、通常のWindows PowerShell、ChromeまたはEdgeを使います。PowerShellとコマンドプロンプトは別のシェルです。スタートでWindows PowerShellを検索して開き、powershellのブロックを実行します。ネットワーク設定を変更する演習はありません。画面は教材用の模式図で、実際のインシデントの証拠ではありません。図は選択すると元のサイズで開けます。
第2回のワークブックをダウンロードしてください。記録の作成まで含め、約3時間が目安です。
1. リクエストを層ごとにたどる
https://example.com/を入力すると、ブラウザーはホスト名を読み、必要ならアドレスを調べ、接続を確立または再利用し、HTTPメッセージをやり取りします。キャッシュや既存の接続があると、毎回すべての段階で新しい通信が発生するとは限りません。
図1:調査のための見取り図です。ページを開くたびに新しい接続ができるという意味ではありません。
| 観点 | 答えられる問い | 根拠の例 |
|---|---|---|
| プロセス | どの実行中アプリが関係したか。 | プロセス名、PID、観察時刻。 |
| DNS | その名前について、どのレコードが返ったか。 | ホスト名、種類、応答、時刻。 |
| ネットワークとトランスポート | どの端点が、どの方式で通信したか。 | 送信元・宛先のアドレスとポート、TCPかUDPか。 |
| TLS | 接続はどう保護されたか。 | ブラウザーのセキュリティ情報や適切な通信記録。 |
| HTTP | 何を要求し、どの返答があったか。 | URL、メソッド、ステータス、ヘッダー。 |
これらは補い合う情報です。DNSの応答だけでは接続したことは分からず、通信一覧だけでは完全なURLは分かりません。ブラウザーの記録は、PC上のほかのすべてのプロセスを説明するものでもありません。
2. アドレス、名前、ポートを区別する
IPアドレスは、ネットワークの状況の中でインターフェースを識別します。IPv4は192.168.1.27、IPv6は2001:db8::27のように表記します。このIPv6の例は文書用の予約アドレスです。実際のPCには、複数のIPv4・IPv6アドレスがある場合があります。
アダプターはWi-Fi、Ethernet、VPNなどのインターフェースです。デフォルトゲートウェイは、より具体的な経路がない宛先への通信に使います。DNSサーバーは名前の問い合わせに答えます。家庭のネットワークで同じアドレスを使っていても、DNSサーバーとゲートウェイは別の役割です。
IPv4のプライベート範囲には10.0.0.0/8、172.16.0.0/12、192.168.0.0/16があります。/8、/12、/16は、先頭の何ビットがネットワークの範囲を示すかというプレフィックス長です。これらのプライベート範囲は多くのネットワークで再利用されるため、192.168.1.27だけでインターネット全体の1台を特定することはできません。NATは、ネットワーク間でアドレスや、多くの場合ポートも変換します。外部のサービスからは、PCのプライベートアドレスではなく、共有の公開アドレスが見えることがあります。プロキシやVPNも見え方を変えます。IPv6が同じ変換方式を使うとは限りません。
example.comはホスト名です。DNSはIPv4のA、IPv6のAAAAなどのレコードを返します。1つの名前に複数のアドレスが返ることも、複数の名前が同じ基盤を使うこともあります。後から調べたアドレスが、過去の通信先と同じとは限らないので、問い合わせた時刻を残します。
ポートは通信の端点を区別する番号です。ブラウザーでは、一時的なローカルポートから、宛先の443番などに接続します。ローカル側と宛先側を混同しないでください。
| よく使われる組み合わせ | 気づきたいこと | 番号だけでは分からないこと |
|---|---|---|
| TCP 80 | 一般にHTTPで使う。 | アプリの正体や意図。 |
| TCP 443 | 一般にHTTP/1.1やHTTP/2のHTTPSで使う。 | サイトが信頼できるか。 |
| UDP 443 | HTTP/3が使うQUICでよく使う。 | すべてのUDP 443通信がHTTP/3か。 |
| UDPまたはTCP 53 | 従来のDNSで使う。 | すべてのDNS通信が53番か。暗号化DNSには別の方式もある。 |
| TCP 22 | SSHによるリモート接続でよく使う。 | そのSSH接続が許可されたものか。 |
TCPは、順序と信頼性を備えたバイトストリームを端点間で提供し、接続の状態を管理します。UDPはデータグラムを送り、到達や順序を組み込みでは保証しません。アプリ側で機能を加えることはでき、QUICはUDP上で信頼性のあるストリームを提供します。どちらも安全性の判定にはなりません。TCPだけの表示で、すべてのアプリの通信は説明できないという点が大切です。
ポートの慣例は手掛かりとして覚え、実際の状況を確かめましょう。
3. 演習A:ネットワーク設定とDNS応答を読む
Windows PowerShellで実行します。
Get-NetIPConfiguration
Resolve-DnsName example.com -Type A
Resolve-DnsName example.com -Type AAAA
使用中のアダプター、ローカルアドレス、ゲートウェイ、DNSサーバーを確認します。複数ある場合は、どれがブラウザーの通信に使われていると考えるか、その根拠も説明します。既定では、接続中の非仮想インターフェースが表示されます。VPNなどが見つからなければGet-NetIPConfiguration -Allを使います。仮想・未接続も含むため、実際に接続しているものを区別してください。
図2:自分の設定とDNS応答は、別の行に記録します。図のDNSアドレスは説明用です。
実際のA・AAAA応答を記録し、エラーやレコードがない場合もそのまま残します。図のアドレスを写さないでください。AAAAが返っても、ブラウザーがIPv6を使ったことや、経路が使えることまでは分かりません。タイムアウトも調べるべき観測結果であり、悪意あるドメインだという証拠ではありません。
PowerShellのコマンドレットがない環境では、次のコマンドプロンプトのコマンドが基本的な代替になります。nslookupの表示や返るレコードの種類は環境によって異なります。
ipconfig /all
nslookup -type=A example.com
nslookup -type=AAAA example.com
確認ポイント: 自分のPCのアドレス、設定されたDNSサーバー、Webサイトについて返ったアドレスを区別して説明します。公開するメモでは、識別につながる情報を伏せてください。
4. 演習B:ブラウザーのリクエストを1つ読む
- ChromeかEdgeで
https://example.com/を開き、再読み込み前に検証 → Networkを開きます。 - キャッシュからの表示を避けたい場合は、開発者ツールを開いている間だけDisable cacheを選びます。PCのDNSキャッシュを消す設定ではありません。終了時に解除します。
- リクエスト一覧の列見出しを右クリックし、Protocolを表示します。再読み込みして、主なdocumentリクエストを選びます。
- HeadersでRequest URL、Request Method、Status Codeを記録します。表示されていればRemote Addressと、Protocol列も記録します。
- 観察時刻とタイムゾーンを残します。項目がなければ、推測せず「表示なし」と書きます。
図3:URL、HTTPの結果、プロトコルは別の観測です。h2はHTTP/2、h3はHTTP/3を表します。
URLにはホスト名だけでなく、スキーム、ポート、パス、クエリなどが含まれます。https://example.com/なら、httpsがスキーム、example.comがホスト名、/がパスです。ポートを明記していない場合、一般的には443番を使います。
HTTPメソッドは要求の操作を表し、GETはリソースの取得要求です。ステータスコードはHTTPの結果を表します。200はHTTPリクエストの成功、404は対象が見つからないこと、401は認証に関わる問題、403はサーバーが要求を拒否したことを示します。どれも単独で攻撃の有無を示すものではありません。HTTPの成功が、業務処理やセキュリティ確認の成功を意味するとも限りません。
TLSはHTTPS通信を経路上で保護しますが、相手の意図を保証しません。通常の接続情報では通信端点が分かっても、暗号化されたパスやクエリ、レスポンス本文までは分からないことがあります。DevToolsはブラウザー内部の情報を見られるため、接続一覧より詳しい内容を表示できます。
確認ポイント: ホスト名とIPを置き換えたり、200を安全性の判定にしたりせず、選んだリクエストを2文で説明します。今回はログイン不要のページを使います。認証済みヘッダー、Cookie、URL、HAR出力には秘密情報が含まれる場合があります。
5. 演習C:TCP通信をプロセスに対応づける
ブラウザーを開いたまま、PowerShellで実行します。
Get-NetTCPConnection -State Established |
Select-Object -First 12 LocalAddress, LocalPort, RemoteAddress, RemotePort, OwningProcess
この例は最大12行なので、ブラウザーの行が含まれないことがあります。タスクマネージャーで確認したブラウザーのPIDを調べる場合は、Get-NetTCPConnection -OwningProcess 4280の値を自分のPIDに置き換えます。
観測した行を1つ選び、タスクマネージャーの詳細でPIDを探すか、次のコマンドを使います。4280は、自分の行のOwningProcessに置き換えてください。 プロセスの終了後にはPIDが再利用されるため、近い時刻で比較します。
Get-Process -Id 4280 | Select-Object Id, ProcessName
図4:5タプルは、送信元IP・ポート、宛先IP・ポート、トランスポートの5項目です。時刻とプロセス情報も添えます。
端末の表示でのローカル・リモートは、自分のPCを基準にした呼び方です。そのラベルだけでは、どちらが接続を開始したかは分かりません。図4の送信元・宛先は、ブラウザーからの接続の例を示します。
ここで分かるのは、その時点のTCP行とプロセスの対応です。DevToolsで選んだ特定のリクエストの通信だと確定したわけではありません。 アドレス、ポート、トランスポート、時刻を比較し、結びつけるのに十分な根拠かを記録します。ブラウザーは接続を共有・再利用します。
選んだリクエストがHTTP/3なら、QUICはUDPを使うため、TCPだけの一覧にはその接続は出ません。TCP行がない理由として、接続が閉じた場合や再利用された場合も考えられます。行がないことは、この時点の表示の限界であり、安全性の証拠ではありません。PIDが終了していたり、プロセスの参照が拒否されたりした場合も、そのまま記録します。
コマンドプロンプトでは、第1週のnetstat -anoが代替になります。TCP行にはPIDが付きますが、UDP行は表示項目が異なり、TCPの接続状態はありません。同じ形式に無理に当てはめないでください。
6. アナリストとして次の問いを考える
次は架空の練習用の観察で、実際の端末の調査結果ではありません。
図5:よいトリアージでは、次に役立つ情報源を特定します。
| 観測したこと | 次に確かめること | 早合点しないこと |
|---|---|---|
| ブラウザーが新しいアドレスのTCP 443に接続した。 | リクエスト、プロセス、時刻、利用者の操作との関係。 | 「443なら安全」「知らない宛先なら悪意がある」。 |
| 名前に対してAレコードが3件返った。 | 対象の時刻に、どれに実際に接続したか。 | 返ったすべてに接続した。 |
| h3が表示され、TCP一覧に一致がない。 | 時刻と、適切なUDP・ブラウザー情報。 | 通信はなかった。 |
| リクエストが403を返した。 | リソース、認証状況、想定されるポリシー。 | サーバーが攻撃されているはずだ。 |
SOCでは、組織が承認した記録とプレイブックを使って関連情報を集めます。この個人演習では、製品ごとのクエリを書く前の考え方を身につけます。
7. 通信の観察メモを作る
問い、端末とソフトウェア、タイムゾーン、DNS応答、ブラウザーの要求、通信とプロセスについての観測を1点、解釈、不足情報を1枚にまとめます。対応づけられなかった点も明記してください。
たとえば、「h3を使うGETリクエストとHTTPの返答を観測した。別に取得したTCP一覧では、そのQUIC通信を説明できない。経路を調べるには適切なUDPまたはブラウザー情報が必要」と書けます。自分の結果が異なれば、その結果を使います。
実施後のプロジェクトの説明例は、「ブラウザーの要求をDNS、HTTP、端末の通信情報から追い、時刻・プロセス情報・対応づけの限界を記録した」です。個人演習として、情報を伏せた根拠とともに説明します。
| 面接の質問 | 答えに含めたいこと |
|---|---|
| DNSとHTTPの違いは何か。 | 名前に対するレコードと、アプリの要求・返答の違い。 |
| 通信の行になぜ2つのポートがあるか。 | ローカル側とリモート側で別の端点を持つ。 |
| DNS応答は接続の証明になるか。 | ならない。対象時刻の接続の根拠が必要。 |
| HTTP/3がTCP一覧にないのはなぜか。 | QUICはUDPを使う。観察の時刻も確認する。 |
| 調査でIPアドレスを役立てるには何が必要か。 | 時刻、出典、役割、トランスポート、周辺の操作。 |
1つのリクエストに注釈を付け、5タプルを説明し、根拠からは分からないことを1つ挙げられれば、次に進めます。第3回では、プロセスが動くOSを学びます。
出典と公開時の確認
2026年10月21日に、コマンドの構文と画面の手順をGet-NetIPConfiguration、Get-NetTCPConnection、Resolve-DnsName、Get-Process、Microsoftのipconfig、nslookup、netstat、ChromeのNetworkチュートリアルと照合しました。MDNのHTTPの概要、ステータスコード、HTTP/3のRFC 9114も参照してください。トランスポートの定義はTCPのRFC 9293とUDPのRFC 768によります。
図のIPv4宛先はRFC 5737の文書用アドレスです。Windowsのコマンドは資料と照合しましたが、公開作業環境ではWindows実機で実行していません。演習結果は読者自身の観察で確かめてください。
2026年10月21日: 日本語・英語で初版公開。全体プランに戻る。





