同じ通信を三つの位置から見る

社内端末から外部サーバへの通信を調べると、端末・ファイアウォール・NAT装置・外部サーバで送信元アドレスとポートが違って見えます。本教材はTCP・UDP・ICMPの違いを押さえ、パケットと通信ログを時刻・方向・変換前後で突き合わせ、通信成立、遮断、異常、侵害のどこまで言えるかを判断するためのSC科目B（午後）向け記事です。以下のIPアドレス、ドメイン、ログ、利用者はすべて架空で、公開側アドレスには文書用アドレスを使用します。実在のインターネットで到達する構成例ではありません。

読み進める順序は、①IP・ポートとTCP/UDPの基本、②NAT前後の対応とICMP、③端末・境界・サーバのログ照合、④障害・攻撃の切り分けと演習です。まず10.0.0.25:51514から203.0.113.80:443への一件を追い、後半の別のログ例では観測点と時刻を改めて示します。

1. 最初に追うべき一件の通信

誰が：端末10.0.0.25のどのプロセス・利用者か。IPだけで利用者は確定しない。
どこへ：宛先203.0.113.80のTCP 443番か。DNS名と実際の接続先IPは別の証跡で結ぶ。
どのプロトコルで：TCP、UDP、ICMPのどれか。同じ数値443でもTCPとUDPは異なる通信。
どこで変わったか：NAT装置が10.0.0.25:51514を192.0.2.10:40001に変換したか。
どこまで観測したか：SYN送出、SYN/ACK受信、データ転送、アプリ処理、情報流出は別の事実。

端末10.0.0.25:51514が外部Webサーバ203.0.113.80:443に接続する例を通します。社内側では10.0.0.25:51514、外側では192.0.2.10:40001として見えるようにNATが送信元を変えます。これらは二つの独立した利用者通信ではなく、NATの対応表で結ばれた同一フローです。ここではNAT機器が境界ファイアウォールも兼ねると仮定します。

同じ通信を三つの位置から見る

1. 10.0.0.25:51514 → 203.0.113.80:443
2. 192.0.2.10:40001 → 203.0.113.80:443

端末からNAT装置を経て外部サーバへ。矢印は行きの通信。応答は逆向きで、NATが宛先を戻す。

2. IP・TCP/UDP・アプリを混同しない

IPv4ヘッダの送信元・宛先IPはホスト間の配送先を示します。IPのProtocolフィールドは上位プロトコルを区別し、TCPは6、UDPは17、ICMPv4は1です。TCP・UDPヘッダには各16ビットの送信元・宛先ポートがあります。ICMPv4 EchoにはTCP/UDPのポートはなく、Type・Code・Identifier・Sequence Numberなどでメッセージを解釈します。IPv6のNext Headerでも上位プロトコルを識別し、ICMPv6は58です。

同じIPアドレスのサーバでも、TCP 443番への接続とUDP 443番への送信は別のプロトコルです。HTTPSがTCP上のTLSを使う場合もあれば、HTTP/3がUDP上のQUICを使う場合もあります。ポート番号だけでアプリや暗号化の有無を断定しないでください。通信ログの「service=https」は製品がポート番号から付けた表示や判定であり、実際のアプリ層の内容を別に検証した結果とは限りません。

2-1. フロー識別の基本

text

TCP 10.0.0.25:51514 -> 203.0.113.80:443
UDP 10.0.0.25:51514 -> 203.0.113.80:443
識別の基本 = 送信元IP・送信元ポート・宛先IP・宛先ポート・プロトコル

上の二行はポートの数値が同じでも、TCPとUDPなので別のフローです。通信方向を逆にして応答を探すときは、送信元と宛先を入れ替えます。ただし実機のセッションID、インターフェース、VRF、NAT規則、時刻の粒度なども相関に必要です。五つの値だけを永久に一意な識別子と考えてはいけません。同じ組合せは時間がたてば再利用されます。

2-2. ポート番号の読み方

ポートはアドレス内のサービス・アプリの受け口を区別する数値で、TCPとUDPに独立した番号空間がある。0〜65535の16ビット値。
IANAの区分はSystem Portsが0〜1023、User Portsが1024〜49151、Dynamic/Private Portsが49152〜65535。これは登録区分で、OSの動的送信元ポートの実際の選択範囲を必ず規定するものではない。
典型例は宛先TCP 443番のWeb、TCP 22番のSSH、UDP 53番のDNS、UDP 123番のNTP。ただしDNSはTCP 53番も使い、ポートを変更したサービスやトンネルもある。
クライアントの送信元ポートは通常一時的に選ばれる。51514はこの通信のクライアント側ポートで、端末が51514番のサーバサービスを公開している証拠ではない。
応答の宛先ポートは、行きの送信元ポートになる。NAT外側では40001、NAT内側では51514を宛先として見る。

宛先ポート443番の許可は、任意の通信が安全という意味ではありません。侵害済み端末が443番へ送信しても同じポートです。アプリ識別、宛先の評判、TLS関連情報、プロキシやサーバのログは別途要ります。反対に高番ポートが宛先でも正規の業務アプリはあり得ます。

TCP・UDP・ICMPv4の観測単位

通信ログで何を比べるか。QUICの信頼性はUDP自体ではなく上位のQUICが提供する。

3. TCPヘッダとSYN・ACKを正確に読む

TCPは順序番号を持つバイトストリームを提供し、受信済みデータに対して累積確認応答を返します。TCPヘッダには送信元・宛先ポート、Sequence Number（SEQ）、Acknowledgment Number（ACK）、制御ビット、Window、Checksumなどがあります。パケットの境界とアプリのメッセージ境界は一致しません。一つのHTTP要求が複数のTCPセグメントに分かれたり、複数の小さな書込みが一つにまとまったりします。

SYN：接続開始時にシーケンス番号を同期する。SYN自体が番号空間を1消費する。
ACKビット：Acknowledgment Numberが有効であることを示す。日常語の「了解」だけでなく、「次に受け取りたいSEQ」を数値で表す。
SEQ：このセグメントのデータ先頭の番号。SYN/FINはそれぞれ1を消費し、通常のデータは送ったバイト数だけ進む。
FIN：送信方向のデータを送り終えたことを示す。双方向が同時に即終了するとは限らない。
RST：接続を中断・拒否する制御ビット。送信元や理由はパケットの観測位置と追加ログで確かめる。
Window：受信側がこれから受け入れられる量を知らせる。ゼロウィンドウによる停止を、ネットワークの単純な遮断と混同しない。

3-1. 三者間ハンドシェイク

text

10:00:00.000 [社内側] SYN     SEQ=1000
  10.0.0.25:51514 → 203.0.113.80:443
10:00:00.012 [社内側] SYN,ACK SEQ=7000 ACK=1001
  203.0.113.80:443 → 10.0.0.25:51514
10:00:00.013 [社内側] ACK     SEQ=1001 ACK=7001
  10.0.0.25:51514 → 203.0.113.80:443

最初のSYNのSEQは1000なので、サーバのSYN,ACKは「1001を次に受けたい」と答えます。サーバのSYNのSEQは7000なので、端末はACK=7001を返します。初期SEQは実際には予測しにくい値で、この数字は説明用です。パケットキャプチャツールが「相対シーケンス番号」を表示する場合は、元のTCPヘッダの値と画面上の値が異なり得ます。

SYN・ACKとNAT対応の成立

SYNの送信元をNATで変換し、SYN/ACKの宛先を対応表で戻す。ACKを見た位置ごとのアドレスに注意。

三つのセグメントがキャプチャされたなら、その観測点でハンドシェイクが見えたと言えます。ただし、ファイアウォールの「session start」一行が三者間ハンドシェイクの完了を意味するかは製品仕様次第です。SYNだけなら接続要求を試みたこと、SYN/ACKが戻れば相手側が応答したこと、最後のACKも確認できればTCP確立の証拠が強くなります。アプリへのログイン成功やファイル送信はまだ示していません。

3-2. ACK番号・再送・順序入替

次はサーバが確認応答を送ったものの、そのACKが端末に届かなかったという架空の例です。サーバ側と端末側の観測を明示し、ACK送出とACK受信を分けて読みます。時刻は同一の時計にそろえた説明用の値です。

text

10:00:01.000 端末側  端末→サーバ  SEQ=1001 ACK=7001 payload=120 bytes
10:00:01.012 サーバ側 サーバ→端末  SEQ=7001 ACK=1121 payload=0 bytes  [送出]
                途中経路でACKが失われ、端末側には到着しない
10:00:02.000 端末側  端末→サーバ  SEQ=1001 ACK=7001 payload=120 bytes [再送]
10:00:02.012 サーバ側 サーバ→端末  SEQ=7001 ACK=1121 payload=0 bytes  [再確認]

120バイトのデータをSEQ=1001から送ると、次の期待番号は1121です。サーバ側のACK=1121は送出されましたが、端末に届かなかったため端末の再送タイマーが満了し、同じSEQのデータを再送します。サーバは既に受信した範囲を重複として扱い、ACK=1121を再び返します。

累積ACKはその前までのバイトを受け取ったことを示しますが、アプリが内容を理解・保存した証明ではありません。この例の「途中で失われた」は両端のキャプチャと経路調査によって確かめる仮定です。端末側だけにACKがないなら、キャプチャ欠落や遅延も残ります。重複ACKや再送一般についても、回線損失、順序入替、観測点でのパケット欠落、オフロード表示を分けて調べます。

3-3. FIN・RST・タイムアウト

正常な終了の典型はFINとそのACKを双方向にやり取りする形です。一方がFINした後も反対方向にはデータを送れる半閉じ状態があり、FIN一個を見て「双方とも停止」と決められません。RSTは既存接続の中断や未使用ポートへの接続拒否などでも起きます。ファイアウォールがRSTを代理送信する製品設定もあるため、RSTのIPアドレスだけで実際の発生機器を決めず、TTL、MAC、観測点、装置ログを確認します。タイムアウトは、相手の応答なし、途中の遮断、経路障害、NAT対応期限切れなど複数原因で起こります。

3-4. TCP状態をログと症状へ結びつける

TCPの状態は端末側とサーバ側がそれぞれ持ち、同じ時点で常に同名とは限りません。サーバが待受けているLISTENは個別通信のESTABLISHEDとは別です。実際のログに状態名があっても、OSのTCP状態なのかファイアウォール独自のセッション状態なのかを確認します。

LISTEN：サーバが接続要求を待つ状態。待受ポートがない場合はSYNへのRSTや無応答が起こり得るが、経路上のFWも確認する。
SYN-SENT：接続を始めた端末がSYNを送り、応答を待つ状態。滞留すればSYN再送、戻り経路、宛先の待受けを調べる。
SYN-RECEIVED：サーバがSYN/ACKを送り、最後のACKを待つ状態。短時間の存在は正常であり、大量滞留はSYN floodだけでなく損失や接続集中も候補になる。
ESTABLISHED：TCP接続が確立した状態。アプリ認証やデータ処理の成功は別に調べる。
FIN-WAIT-1/2：自分がFINを出し、相手の確認・FINを待つ状態。長い滞留では相手側と戻り経路を確認する。
CLOSE-WAIT：相手のFINを受け、自分のアプリが接続を閉じるのを待つ状態。大量に残れば、そのホストのアプリがcloseを実行しているか調べる。
LAST-ACK：自分もFINを送り、そのACKを待つ状態。TIME-WAITは遅延した旧セグメントの混入を避け、最後のACK再送にも備えて一定時間待つ状態。短時間のTIME-WAITがあるだけで障害とはしない。

text

端末: SYN-SENT      サーバ: SYN-RECEIVED  ← SYN送信後、最後のACK待ち
端末: ESTABLISHED   サーバ: ESTABLISHED  ← 双方で接続確立
端末: FIN-WAIT-2    サーバ: CLOSE-WAIT   ← 端末のFINをサーバが受信
端末: TIME-WAIT     サーバ: CLOSED       ← 双方向の終了後の典型例

たとえばサーバでCLOSE-WAITが増え続けるなら、端末からのFINが届いた後にサーバ側アプリが閉じていない可能性があります。TIME-WAITが多いときは短命接続の量、ポート再利用、接続失敗率を併せて調べます。状態は瞬間値なので、取得時刻とその前後のFIN・ACK・RSTを結びます。

4. UDPを「応答のないTCP」と考えない

UDPはポート付きのデータグラムを送る簡素なトランスポートです。UDPヘッダは送信元ポート、宛先ポート、Length、Checksumを持ちます。TCPのSYN・ACK・SEQや三者間ハンドシェイクはありません。UDP自体は到達・順序・重複排除・再送を保証しませんが、アプリ層は独自の問い合わせID、応答、再試行、暗号化、信頼性制御を持てます。QUICはUDP上で信頼性などを実現する例です。

text

10:05:00.000 UDP 10.0.0.25:53000 -> 198.51.100.53:53  DNS query id=0x4a2b
10:05:00.025 UDP 198.51.100.53:53 -> 10.0.0.25:53000  DNS response id=0x4a2b

同じ送信元・宛先の逆転に加え、DNSのトランザクションIDと問い合わせ内容を照合します。DNSの詳細は別テーマですが、「UDPなので必ず一方向」「UDP 53番なら正常なDNS」と決めないことが重要です。応答がない場合も、送信先が受け取らなかった、受け取って返さなかった、返信が途中で落ちた、NAT対応が消えた、ログが採れていない、のいずれかです。送信ログだけで配送成功や失敗を確定しません。

4-1. UDPとNATのセッション表示

NAT装置やファイアウォールはUDPを実際の接続確立なしでも「session」として状態管理できます。最初の送信で外側のIP・ポートへの対応を作り、返信可能な相手と有効時間を設定します。対応づけ（mapping）は内側のIP・ポートをどの外側IP・ポートへ写すか、フィルタリング（filtering）はどの外部送信元からの着信を通すか、という別の判断です。対応表があるから任意の外部ホストから受信できるとは限りません。実際の期限や許可条件は装置設定・実装・通信状態で変わります。

5. NAT/PATで何が、どこで変わるか

NATはネットワーク境界でIPアドレスを変換します。ここで扱うのはNAPT/PATとも呼ばれる、送信元IPとTCP/UDP送信元ポートを組で変える構成です。一つの外側IPを複数端末で共有できるよう、NAT装置は内側と外側の対応を保持します。説明上の外側192.0.2.10は文書用IPで、実運用のグローバルIPではありません。

text

行き・変換前  TCP 10.0.0.25:51514     -> 203.0.113.80:443
行き・変換後  TCP 192.0.2.10:40001   -> 203.0.113.80:443
戻り・変換前 TCP 203.0.113.80:443  -> 192.0.2.10:40001
戻り・変換後 TCP 203.0.113.80:443  -> 10.0.0.25:51514

行きはSNATにより送信元IP・ポートが変わり、宛先203.0.113.80:443はこの例では変わりません。戻りはNAT装置に届いた宛先192.0.2.10:40001を、対応表に基づいて10.0.0.25:51514へ戻します。TCPのSEQとACKは通常この変換だけでは変わらず、IP/TCPのチェックサムなどは再計算が必要です。アプリゲートウェイやプロキシが間に入ればペイロードやTCP接続そのものが別になるため、この単純な図をそのまま当てはめません。

5-1. NAT対応表を読む

text

time=10:00:00.001 session=N-731 proto=TCP zone=inside->outside
  original:   10.0.0.25:51514 -> 203.0.113.80:443
  translated: 192.0.2.10:40001 -> 203.0.113.80:443
  rule=out-web

time=10:00:00.013 session=N-731 proto=TCP zone=outside->inside
  original:   203.0.113.80:443 -> 192.0.2.10:40001
  translated: 203.0.113.80:443 -> 10.0.0.25:51514
  rule=out-web

架空の正規化ログです。製品によってoriginal/translatedは「ルール評価前後」や「送信方向」の意味が違うため、列名だけで変換方向を決めず、その機器のログ定義・インターフェース・実際のパケットキャプチャで確認します。二行目のoriginalは戻りパケットの装置到着時点で、translatedは社内送出時点です。N-731というセッションIDが同じでも、再起動やログ保存期間をまたいで永続に一意とは限りません。

5-2. 外側IPだけで端末を特定できない

text

TCP 10.0.0.25:51514 -> 203.0.113.80:443  => 192.0.2.10:40001
TCP 10.0.0.26:51514 -> 203.0.113.80:443  => 192.0.2.10:40002

二台の端末は外側の送信元IPが同じです。外部サーバのログに192.0.2.10があるだけではどちらか決められません。プロトコル、外側送信元ポート、宛先、UTCへ正規化した時刻、NAT対応の開始・終了、機器IDを照合します。同じ外側ポートは時間を置いて再利用され得るため、時刻の秒以下の精度と時計のずれも重要です。CGNATなど複数段のNATがあれば各段の対応ログを連結します。外部サーバ側がロードバランサやプロキシ越しなら、さらに対応する識別子が必要です。

5-3. DNAT・ヘアピン・対応表の期限

外部から社内公開サーバへ入る通信では、DNATにより宛先の外側IP・ポートを内側サーバIP・ポートへ変える構成があります。その場合は「行きで送信元が変わる」という上の例を機械的に逆用せず、到着側インターフェースと変換規則を確認します。内側端末が同じNAT装置の外側アドレスを使って内側公開サービスへアクセスするヘアピン通信では、SNATとDNATの両方が生じることもあります。

NAT対応表は永続ではなく、TCP状態やUDPの無通信時間、装置再起動・フェイルオーバーで消えます。対応表の期限切れ後に戻りパケットが来た場合、外側ポートが内側の元端末へ戻せないことがあります。復旧時は、単に許可ルールを再設定するだけでなく、セッション再確立、HA構成での状態同期、古い対応表の扱い、アプリ側再試行を確認します。

5-4. ステートフルFWの許可状態とNAT対応表

同じ境界装置がNATとファイアウォールを兼ねていても、二つの役割は別です。NATはアドレスやポートの変換先を記録し、ステートフルFWは許可ポリシーと通信状態に照らして通すかを決めます。変換表があるだけで通信が許可されるわけではなく、許可されていても変換が必要な経路で対応表がなければ正しい端末へ戻せません。NATなしのステートフルFWも、NATだけを行う装置も構成できます。

NATとステートフルFWの判断

一台の境界装置が両方を実行していても、変換と通過許可は異なる判断。

たとえば端末のSYNがfw-01を通り、応答のSYN/ACKだけが非対称な戻り経路でfw-02へ届くとします。fw-02に該当する通信の許可状態がなければ、製品の設定によっては不正な戻りとして破棄されます。NATも別装置に分散しているなら、fw-02に変換対応表がなく内側の宛先を復元できない場合もあります。原因を分けるには、戻りの到着インターフェース、装置ごとの状態表、NAT対応表、ルーティングとHA同期の設定を照合します。「FWが遮断した」と「NATで宛先が解けなかった」を同じログ理由として扱いません。

6. ICMPをType・Codeで読み、元の通信に結ぶ

ICMPv4はIP通信の制御・障害通知に使われ、TCP/UDPのポート番号を持ちません。代表的なEcho RequestはType 8 Code 0、Echo ReplyはType 0 Code 0です。Destination UnreachableはType 3でCodeによって原因が違い、Code 3はport unreachable、Code 4はIPv4でDFが立ったパケットについてfragmentation neededを表します。Time ExceededのType 11 Code 0は転送中にTTLが尽きた場合です。製品ログがTypeだけ示すときはCodeも取得してください。

Echo Request/Replyは到達確認の一手段。応答がなくても宛先ホストが停止したとは限らず、ICMP遮断・レート制限・経路上の問題があり得る。
Type 3 Code 3のport unreachableは、典型的には宛先側でUDPの受け口がない場合などに返される。ICMPの送信元が宛先ホストか途中の装置かを確認する。
Type 3 Code 4のfragmentation neededはIPv4のPath MTU Discoveryで手掛かりになる。ICMPを一律に捨てるとMTU問題の切り分けや通信自体に影響し得る。
Type 11 Code 0のTTL exceededは、ルータでTTLが尽きたことを示す。通信先アプリが処理した証拠ではない。
ICMPエラーには原因となった元パケットのIPヘッダと先頭部分が引用される。引用部分のプロトコル、IP、ポートを読んで元フローに結ぶ。

6-1. ICMPエラーとUDPの元パケット

架空のUDP通信では、内側10.0.0.25:53001を外側192.0.2.10:40051へ変換します。宛先198.51.100.53:9999が返すICMP port unreachableを、NATの内外それぞれで採取した例です。quoted-originalはICMPのペイロードに引用された元パケットであり、ICMP自身のポートではありません。

text

10:05:10.000 [LAN] UDP 10.0.0.25:53001 -> 198.51.100.53:9999
10:05:10.001 [WAN] UDP 192.0.2.10:40051 -> 198.51.100.53:9999
10:05:10.017 [WAN] ICMPv4 198.51.100.53 -> 192.0.2.10 type=3 code=3
  quoted-original: UDP 192.0.2.10:40051 -> 198.51.100.53:9999
10:05:10.018 [LAN] ICMPv4 198.51.100.53 -> 10.0.0.25 type=3 code=3
  quoted-original: UDP 10.0.0.25:53001 -> 198.51.100.53:9999

NATは受け取ったICMPエラーの引用元パケットから既存のUDP対応を探し、外側の引用送信元192.0.2.10:40051を内側10.0.0.25:53001へ戻します。ICMP外側IPヘッダの宛先も192.0.2.10から10.0.0.25へ直します。この例ではICMPのType=3、Code=3と、エラーを生成した送信元198.51.100.53は変わりません。対応表が失効していれば元端末へ転送できない場合があります。内側だけを見ると元UDPとエラーを結べても、外側だけを見ると40051という変換後ポートを追う必要があります。

ICMPv6ではType番号が異なります。例えばEcho Requestは128、Echo Replyは129、Packet Too Bigは2です。IPv6のPath MTU DiscoveryにICMPv6は重要です。IPv4のType 3 Code 4をIPv6へそのまま移してはいけません。IPv6でNATを使う構成も存在しますが、上記のIPv4 NAPT例と同じ前提で変換すると誤ります。

6-2. MTU・MSS・DFと大きいパケットだけ止まる障害

MTUは一つのリンクで運べるIPパケットの上限、Path MTUは経路上で最も小さいMTUです。TCPのMSSは一つのTCPセグメントに載せるデータの最大長で、SYNのオプションで各方向の受信能力として通知します。IPv4ヘッダ20バイト・TCPヘッダ20バイトでオプションがない単純な例なら、リンクMTU 1500から両ヘッダ40を引き、データ長1460バイトが目安です。トンネルやTCPオプションで実際の余裕は変わるため、MSSの数値だけから経路全体のMTUを決めません。

IPv4のDF（Don't Fragment）が立った1500バイトのIPパケットを、MTU 1400の次のリンクへルータが転送できない場合、ルータは転送をやめ、送信元へICMPv4 Type 3 Code 4（fragmentation needed）と次ホップMTUの情報を返せます。送信側がPath MTU 1400を反映し、オプションなしの同じ前提でデータ長を1360以下にして再送すれば通れる例です。ここでの1460・1360は計算例で、実際のTCPオプション、IPv6、トンネルのヘッダ長は別に計算します。

text

10:20:00.000 [端末] TCP SYN MSS=1460 -> 203.0.113.80:443
10:20:00.030 [端末] TCP接続はESTABLISHED、小さい要求・応答は成功
10:20:01.000 [経路] IPv4 total-length=1500 DF=1 -> 次リンク MTU=1400
10:20:01.002 [経路] ICMPv4 type=3 code=4 next-hop-mtu=1400 -> 端末
10:20:01.050 [端末] 経路MTUを更新し、より小さいTCPセグメントで再送

このICMPエラーが経路中のFWで遮断されると、SYNや小さいデータは通るのに大きいデータだけ再送を繰り返すPMTUDブラックホールが起こり得ます。ただし、この症状だけでICMP遮断を断定せず、ルータがエラーを送ったか、端末が受信したか、DF・パケット長・トンネルのMTU・再送SEQを観測します。対策は必要なICMPエラーを通し、経路やトンネルのMTU設定を整えることです。TCP MSSクランプを使う場合は、SYNを通る境界で値を調整して大きすぎるセグメントを抑えますが、通信方向とトンネルの実際の余裕を確認します。

7. ファイアウォール・NAT・サーバのログを一続きで読む

次のログは全て説明用に正規化した架空のログです。長いイベントは画面で追えるように複数行へ折り返し、字下げした行を直前の時刻のイベントに属させています。時刻はUTCで同期済み、境界装置はfw-01、端末はPC-25、外部サーバはweb-01です。外部の文書用IPは到達すると仮定して演習します。fw-01のpolicyログは転送許可、NATログは変換、web-01のacceptログはTCP接続受入れをそれぞれ表すという設定です。実製品のログ項目と発生時点は製品資料を確認します。

text

10:00:00.000 PC-25 pcap TCP 10.0.0.25:51514 > 203.0.113.80:443
  flags=S seq=1000
10:00:00.001 fw-01 policy session=N-731 action=allow rule=out-web
  dir=inside-out TCP 10.0.0.25:51514 > 203.0.113.80:443
10:00:00.001 fw-01 nat session=N-731
  original:   10.0.0.25:51514 > 203.0.113.80:443
  translated: 192.0.2.10:40001 > 203.0.113.80:443
10:00:00.002 fw-01 WAN pcap TCP 192.0.2.10:40001 > 203.0.113.80:443
  flags=S seq=1000
10:00:00.012 fw-01 WAN pcap TCP 203.0.113.80:443 > 192.0.2.10:40001
  flags=S,A seq=7000 ack=1001
10:00:00.013 PC-25 pcap TCP 203.0.113.80:443 > 10.0.0.25:51514
  flags=S,A seq=7000 ack=1001
10:00:00.014 PC-25 pcap TCP 10.0.0.25:51514 > 203.0.113.80:443
  flags=A seq=1001 ack=7001
10:00:00.016 web-01 conn accepted peer=192.0.2.10:40001
  local=203.0.113.80:443

PC-25の最初のSYNから、送信元10.0.0.25:51514、宛先203.0.113.80:443、TCPを記録する。
fw-01のpolicyログで許可規則out-webと内側の通信を確認する。allowは通過を許す決定で、相手が受け取った証明ではない。
同じsession=N-731のNATログで、外側192.0.2.10:40001への変換を確認する。WAN側キャプチャのSYNと結ぶ。
WAN側でSYN,ACKの戻りを、PC-25側で変換後のSYN,ACKとACKを確認する。SEQとACKの1000→1001、7000→7001は整合する。
web-01のacceptログでTCP接続の受入れを確認する。HTTP要求、TLSハンドシェイク、認証、ファイル送受信は別ログで確認する。

「allow」「accepted」「200 OK」「ファイル保存完了」はそれぞれ違う層の出来事です。上のログではTCP接続は確認できますが、HTTPSの中身やログイン成功は示していません。暗号化通信の内容を見たいなら、許可された範囲で端末・サーバ・プロキシのアプリログを確認します。パケット数・バイト数も、ヘッダを含む計数か、片方向か双方向か、圧縮や再送を含むか製品ごとに確認し、直ちに「流出データ量」としません。

7-1. ログ項目の意味と信頼境界

時刻：UTC/ローカル時刻、タイムゾーン、時計同期、ミリ秒精度、ログの記録時刻と送信時刻を分ける。ログ転送遅延で順序がずれる。
送信元・宛先：観測インターフェースとNAT前後のどちらの値かを必ず書き添える。プロキシ・ロードバランサ越しなら新しい接続として扱う。
action・rule：どのポリシーが一致したか。allowは通過許可、deny/dropはその装置での処理。途中の別経路や再試行までは示さない。
flags・state：S、S,A、A、F、RなどのTCP制御ビットと装置のセッション状態を区別する。製品の「established」はパケットキャプチャ上の三者間完了と同義とは限らない。
session ID：同じ装置の複数ログを結ぶ手掛かり。機器ごとに意味・採番・再利用条件が違う。
bytes/packets：観測範囲、方向、集計の開始・終了時点を確認する。サンプリングされたNetFlow等なら個々のパケット証跡とは異なる。
端末・サーバのログ：端末EDR、OS、DNS、プロキシ、アプリ、認証の各ログで通信主体と業務操作を結ぶ。各ログの改ざん可能性と保存期間も調べる。

7-2. deny、drop、rejectと戻りパケット

deny/dropは通常パケットを破棄しますが、製品によってはrejectでTCP RSTやICMPエラーを返すことがあります。クライアントからは、無応答のタイムアウトと即時RSTでは症状が異なります。境界ファイアウォールでのdropログが一行あっても、同じ端末が別経路で接続していないことは証明できません。送信時刻、ルーティング、別インターフェース、VPN、プロキシ経路を確認します。

7-3. 外側の接続から端末・プロセス・利用者へたどる

NATログで内側IPが分かっても、その時点の端末や利用者まで自動的に決まるわけではありません。DHCPの貸出し、端末台帳、認証・EDRログを同じUTCの時間帯で結びます。次は先ほどのTCP通信に対応する架空のログです。

text

09:00:00 DHCP lease-start ip=10.0.0.25 end=11:00:00
  mac=02:00:00:00:00:25 client-id=PC-25
09:59:58 EDR host=PC-25 user=alice process=browser.exe pid=4120
  mac=02:00:00:00:00:25
10:00:00 EDR host=PC-25 pid=4120 proto=TCP
  network=10.0.0.25:51514 -> 203.0.113.80:443
10:00:00 NAT session=N-731 proto=TCP
  inside=10.0.0.25:51514 outside=192.0.2.10:40001
  dst=203.0.113.80:443
10:00:00 WEB peer=192.0.2.10:40001 local=203.0.113.80:443

外部サーバの送信元192.0.2.10:40001、宛先203.0.113.80:443、TCPと時刻からNATのN-731を探し、内側10.0.0.25:51514を得る。
10:00:00を含むDHCP貸出期間からMACアドレスと端末IDを得る。更新・再貸出や固定IP設定、複数のDHCPサーバがないかも確認する。
端末台帳とEDRの同時刻のnetworkイベントからPC-25のpid=4120へ結び、プロセス実体・ハッシュ・親プロセス・コマンドラインを調べる。
EDRのuser=aliceがログオン主体として何を意味するか確認する。共有端末、サービスアカウント、代理実行、乗っ取られたセッションなら操作した人は別途調査する。

DHCPのMACはネットワーク上で見えた識別子であり、物理的な端末や人の本人確認を単独で保証しません。静的IP、MACの変更、VDI、VPN、同じ端末上の複数利用者、ログ改ざんも考慮します。NAT・DHCP・EDRの時計がずれていると別の貸出期間やプロセスへ誤って結ぶので、原本ログと同期状態を保存します。

8. 異常パターンを正常例との差分で切り分ける

8-1. SYNだけを何度も送る

text

10:10:00.000 inside TCP 10.0.0.25:51600 > 203.0.113.80:443 S seq=2000
10:10:01.000 inside TCP 10.0.0.25:51600 > 203.0.113.80:443 S seq=2000
10:10:03.000 inside TCP 10.0.0.25:51600 > 203.0.113.80:443 S seq=2000

同じSEQのSYNが再送され、対応するSYN,ACKもRSTも観測されない例です。端末は接続を試みていますが、相手が停止したとはまだ言えません。まず端末と境界の送出、外側の到達、相手側の受信、逆方向の応答、戻り経路とNAT対応を順に比較します。サーバにSYNが届いてSYN,ACKが返っているなら、戻り経路やフィルタに焦点を移せます。端末の一点のキャプチャだけなら、観測漏れやキャプチャフィルタを除外できません。

8-2. RSTが来た

SYNの直後に宛先を名乗るRSTが戻る場合、そのTCPポートに待受プロセスがない、装置が拒否を返す、サーバが過負荷・設定変更中などが考えられます。正常通信で確立後にRSTが来れば、アプリの異常終了やセッション期限切れも候補です。単に「攻撃で切断された」と書かず、RSTを生成した位置、直前の通信、装置とサーバのログを照合します。RSTが送信元IPを偽装され得る点も、パケットだけから発信主体を断定しない理由です。

8-3. UDPの送信だけ、またはICMP port unreachable

UDPで返信がなければ、アプリが返信しない設計か、応答前に廃棄されたか、NAT・フィルタで戻らないかを分けます。ICMP Type 3 Code 3が返っても、引用された元UDPの宛先と一致するかを確認します。ポート9999への送信とDNSポート53の応答を混ぜて原因分析してはいけません。ICMPが装置でレート制限されていれば、エラーが届かない場合もあります。

8-4. 外部接続が大量に並ぶ

侵害された端末が多くの宛先IP・ポートへSYNを試すスキャンや、一定間隔で同じ外部宛先へ短い通信を繰り返すビーコンが疑われる場合があります。攻撃の成立には、端末で通信を起こせるプロセス、ネットワーク経路、許可ルールなどが必要です。ログから分かるのは接続試行・成立・転送量までで、マルウェア感染やデータ流出は端末プロセス、DNS、TLS、プロキシ、サーバ側の証跡を加えて判断します。業務監視や更新プログラムでも似た通信は起こるため、既知の宛先・端末用途・実行ファイル・変更履歴と比較します。

8-5. SYN floodと正規の接続集中を分ける

SYN floodは、サーバに大量のSYNを送り、最後のACKが返らない接続候補を増やして待受側の資源を圧迫する攻撃です。攻撃者は送信元IPを偽装することも、実際に通信できる多数の端末を使うこともあります。成立には対象ポートへの到達、十分なSYN量、サーバ側の受入れ資源やネットワーク設備への影響が必要です。SYNの数だけで攻撃成立を断定しません。

text

12:00:00.001 srv-pcap 198.51.100.201:50001 -> 203.0.113.80:443 flags=S
12:00:00.002 srv-pcap 203.0.113.80:443 -> 198.51.100.201:50001 flags=S,A
12:00:00.003 srv-pcap 198.51.100.202:50002 -> 203.0.113.80:443 flags=S
12:00:00.004 srv-pcap 203.0.113.80:443 -> 198.51.100.202:50002 flags=S,A
12:00:01.000 srv-metric syn-received=high half-open-backlog=high
  successful-handshake=low
12:00:02.000 srv-metric application-requests=low timeout-errors=high

この架空ログではSYNとSYN/ACKは見えますが、対応する最後のACKは観測窓内にありません。SYN-RECEIVEDの増加、ハンドシェイク完了率の低下、正規利用者のタイムアウトが同時に起こるか確認します。正規のセールや一斉更新でもSYN量は増えますが、通常は完了する接続とアプリ要求も増えます。逆に正規接続でも戻り経路障害やパケット損失があれば完了率が下がるので、経路・FW・サーバ負荷・観測漏れを調べます。IPの見かけだけで攻撃者を特定しません。

対策はサーバ側のSYN cache・SYN cookies、境界や上流での適切な制限・防御サービス、受入れ容量の調整などを組み合わせます。SYN cookiesは最後のACKを受けるまで半開接続の状態保持を減らせますが、回線やアプリ層の資源不足を解消するものではなく、実装・設定によって一部TCPオプションへの影響もあります。正規利用者が多い場合に過度のレート制限をかければ可用性を損なうため、平常時の完了率・端末分布と業務予定を比較してから変更します。

不審通信を見たときの証拠と対策

1. 端末で実行：証跡 EDRのプロセス・親子関係・実行時刻／防御・対処不要な実行を制限し端末を隔離
2. 外部へ接続：証跡 SYN、NAT、FW、DNSの時系列／防御・対処必要な宛先だけ許可し異常を監視
3. データ交換：証跡双方向バイト数、プロキシ・サーバログ／防御・対処外向き通信と認証・操作を相関
4. 影響を確認：証跡端末のファイル操作、相手側の受領記録／防御・対処封じ込め後に範囲と復旧を検証

感染は仮説であり、各段階の証拠を突き合わせてから判断する。

9. 対策を適用する位置と効く理由

出口ファイアウォール：端末群から外部へのTCP/UDP宛先とポートを業務に必要な範囲へ制限する。不要な接続試行を境界で止めるが、許可された443番上の悪用は残る。
端末制御：EDR、実行制御、権限の最小化で不審プロセスの起動・通信を減らす。境界ルールだけでは社内端末の実行主体を特定できないため。
DNS・プロキシ・アプリの観測：IP:ポート以外に問い合わせ名、URL、利用者、要求結果を結ぶ。暗号化・プロキシの構成に応じて取得できる情報は異なる。
NATログ保全：外側IP・ポート・プロトコル・時刻から内側端末へ追跡できるよう、対応表と時計同期を保持する。保存期間と機器交代時のログ連続性を決める。
ICMPの運用：Echoを許すかは方針で決め、必要なエラー通知まで一律遮断しない。Path MTUに関するICMPv4/ICMPv6と監視の要件を別に設計する。
サーバ側：待受ポート、TLS設定、認証、アプリ監査ログを整える。境界のallowだけで「正しい業務処理」を保証しないため。

9-1. 変更・障害時に崩れる対応関係

ファイアウォールのHA切替、NATの外側IP追加、ポート枯渇、ルール変更、プロキシ導入、IPv6移行では、以前の「内側→外側」対応が変わります。変更前に通信一覧、正規の宛先、端末、ポート、通信量、例外利用を棚卸しします。変更中は新旧インターフェースのログと時計を確認し、ポート変換後の戻り通信、UDPの応答、ICMPエラーも試験します。障害後に旧ルールへ戻すときも、既存セッションと新規セッションで挙動が異なり得ます。

9-2. インシデントの封じ込めと再開条件

不審通信が続く場合、まず影響端末と送信元プロセスを特定し、必要なら端末隔離または該当宛先の一時遮断を行います。遮断前後のNAT・FW・EDRログと時刻を保全し、隣接端末・同じ認証情報・別の外部宛先へ波及していないか調べます。流出の可能性があるなら、ネットワークのバイト数だけでは結論せず、対象ファイルのアクセス履歴、アプリ・プロキシの送信記録、相手側の受領情報を照合します。

再開は、侵入経路や不審プロセスを除去し、必要な資格情報を更新し、同じ端末・別端末からの再接続が続いていないことを複数ログで確認して判断します。業務の正規通信がTCPの確立だけでなくアプリ処理まで通ること、NAT対応が正しく保存されること、遮断した例外通信をどの責任者が承認するかも確認します。利用者・ネットワーク担当・CSIRT・業務責任者の判断と記録を分けます。

通信異常から安全な再開まで

1. 検知：対応不審な接続を抽出／確認する証跡 FW・NAT・端末の時刻
2. 影響確認：対応主体と到達範囲を特定／確認する証跡 EDR・DNS・アプリのログ
3. 封じ込め：対応端末隔離か宛先遮断／確認する証跡遮断前後の通信と業務影響
4. 復旧：対応原因除去と正規通信試験／確認する証跡再侵入なし・アプリ処理成功
5. 監視：対応再発兆候と例外を監視／確認する証跡新旧NAT対応・端末イベント

接続ログだけでは侵害を確定せず、端末とアプリの証拠を加えて判断する。

10. 科目B（午後）の短い記述演習

演習1：外部サーバの接続元から端末を特定する

条件：外部サーバは10:00:00 UTCにTCP 192.0.2.10:40001から203.0.113.80:443への接続を記録した。NATログには10.0.0.25:51514→192.0.2.10:40001、10.0.0.26:51514→192.0.2.10:40002が同時にある。
問い：接続元端末、必要な確認、誤答の理由を答える。

解答：同じTCP通信の外側送信元ポート40001と時刻に対応する10.0.0.25が候補です。NAT装置のセッション開始・終了時刻、宛先、インターフェース、時計同期、端末の送信記録を確認します。「外側IPが同じだから二台とも接続した」はポート変換を無視しており誤りです。「10.0.0.25が攻撃者」は通信主体候補から人や侵害を飛躍して断定しています。

演習2：SYN再送の原因を狭める

条件：端末側にSYNが3回見える。境界fw-01のWAN受信直後を漏れなく採取したキャプチャには、変換後のSYNが3回見えるが、対応するSYN/ACKはない。サーバ側キャプチャには最初のSYNが到着し、宛先192.0.2.10:40001へSYN/ACKを送出した記録がある。
問い：最初にどの区間を調べ、次に何を確認するか。

解答：サーバからfw-01のWAN受信点までの戻り経路を最初に調べます。サーバ送信直後と中間ルータでのSYN/ACK、経路・ACL・戻り先192.0.2.10:40001、双方の時計とキャプチャ条件を照合し、どこまで届いたか狭めます。WANへ到着していたのにLANへ出なければ、その段階でfw-01のステートフルFW状態・NAT対応・内側への経路を調べます。今回の条件ではWANに到着した証拠がないので、まずNAT設定だけを原因と決めるのは観測点と合いません。サーバ停止も否定的ですが、戻り経路のどこで失われたか、TCP接続やアプリ処理の成否はまだ確定しません。

演習3：UDPにSYNがないこととICMPを結ぶ

条件：端末からUDP 10.0.0.25:53001→198.51.100.53:9999が送られ、ICMPv4 Type 3 Code 3が戻った。引用元パケットには同じUDP宛先9999が記録されている。
問い：何が分かり、どの対策・確認が必要か。

解答：このICMPは該当UDP送信へのport unreachable通知である可能性が高いです。送信先の待受設定、誤った宛先ポート、途中装置が返した可能性、NAT変換後の引用部分を確認します。正規サービスなら正しい宛先とポートへ設定を直します。「UDPのSYNが失敗した」はUDPにSYNがないため誤りです。「ICMPが戻ったので宛先アプリが正常に処理した」も、むしろ受け口に問題がある通知を取り違えています。

演習4：許可ログと情報流出を切り離す

条件：侵害を疑う端末のTCP 443番宛て通信がFWでallow、NATで変換され、双方向合計50 MBと記録された。
問い：侵害と流出についてどこまで言え、何を追加調査するか。

解答：通信を許可し、装置観測範囲で一定量のパケットが通ったことまで言えます。端末のプロセス・ファイル操作、DNS・プロキシ・TLSの関連ログ、サーバ側記録、計数方向とヘッダ・再送の扱い、過去の通常通信を確認します。流出の対象ファイルと受領の証拠がなければ「50 MB流出」とは断定できません。対策は状況に応じた端末隔離、通信先の一時遮断、認証情報の保護、証拠保全を並行します。

演習5：NAT切替後に戻りだけ落ちる

条件：10:30:00.000に端末がUDP要求を送信し、fw-01が10.0.0.25:53001を外側192.0.2.10:40051へ変換した。10:30:00.010にfw-01からfw-02へHA切替し、外側IP 192.0.2.10もfw-02が引き継いだが、既存のUDP状態は同期されなかった。10:30:00.020に、切替前の要求に対する応答が外側の192.0.2.10:40051へ届き、fw-02で破棄された。この間、端末は新しいUDP要求を出しておらず、fw-02には該当対応表がない。
問い：原因候補、暫定復旧、再開条件を答える。

原因と確認：切替前のfw-01だけにあったUDP対応がfw-02へ引き継がれず、戻りの宛先192.0.2.10:40051を内側端末へ対応付けられないことが候補です。装置設定と状態同期ログ、切替時刻、実際の内外パケット、FWの破棄理由を確認します。

復旧と再開：端末の新規要求でfw-02に新しい対応を作り直す場合、外側ポートが40051のままとは限らず、古い応答を復活させる処理ではありません。アプリの再試行を確認し、状態同期と切替設計を直します。正規UDP要求と新しい応答が複数端末で戻ること、古い対応の誤転送がないこと、監視が効くことを確認して再開します。

誤答の理由：「UDPにはセッションがないからNAT表も不要」は、UDP自体の接続手順とNAT装置の状態管理を混同しています。

演習6：小さい通信だけ成功する

条件：TCP接続と100バイトの要求は成功する。端末がIPv4 total-length=1500、DF=1のパケットを送ると、途中ルータはMTU=1400のリンクへ転送できずICMPv4 Type 3 Code 4を返した。境界FWはそのICMPだけをdropし、端末では同じデータ範囲の再送が続く。
問い：原因、適用位置を含む対策、復旧確認を答える。

解答：端末が経路の小さいMTUを知るためのICMPエラーを受け取れず、同じ大きさのDFパケットを再送し続けることが原因です。境界FWで関係するICMPエラーを元の通信と結びつけて許可し、必要ならトンネル側のMTUやSYNを通る位置でのMSS調整も検討します。ICMPが端末へ届き、送信パケットがPath MTUに合う大きさへ下がり、実際の大きい業務要求まで完了することを確認します。「TCPがESTABLISHEDなのでFWに問題はない」は小さいパケットの成功から大きいパケットの到達まで推論しているため誤りです。

演習7：SYNが急増したときの判断

条件：Webサーバの443番宛てSYNが急増し、SYN-RECEIVEDと利用者のタイムアウトが増えた。最後のACKは少ないが、同時刻に販促キャンペーンも始まっている。
問い：攻撃と断定できるか、何を確認し、どこに対策を置くか。

解答：この情報だけでSYN floodとは断定できません。SYN/SYN-ACK/最後のACKの組を観測点ごとに比べ、接続完了率、正常なアプリ要求数、受入れキュー、サーバ負荷、途中のパケット損失を確認します。資源枯渇が確認されればサーバのSYN防御や境界・上流での対策を検討し、正規利用者の接続完了率が回復するか監視します。「SYN数が多いので送信元を全て遮断」は正常な集中アクセスも含み、業務可用性を損ねます。