この記事は、 「ネットワーク上級編｜要件定義・設計・クラウド・自動化へ進む」 の第50回です。
第5章「セキュリティ」の最後として、 セキュリティインシデントが発生したときに、 ネットワークのログやパケットから 「誰が・いつ・どこへ・どのような通信を行ったのか」 を整理する方法を学びます。
インシデント発生時の通信調査｜ログ・パケットから侵害範囲を特定する方法
「不審な外部通信が検知された」「端末がマルウェアに感染した可能性がある」 といったセキュリティインシデントでは、 ファイアウォールログ、DNSログ、VPNログ、通信フロー、 パケットキャプチャなどを組み合わせて事実を確認します。 本記事では、通信調査を時系列で進める方法を実務形式で解説します。
セキュリティインシデントの通信調査で重要なのは、 怪しいIPアドレスを見つけることだけではありません。
発生時刻、通信元、通信先、通信方向、プロトコル、通信量、 他端末への展開有無などを整理し、 何が起きたのかを証拠に基づいて説明できる状態 にする必要があります。
この記事を読み終えるとできること
- インシデント時の通信調査の目的を説明できる
- 最初に確認すべき通信情報を整理できる
- FW・DNS・VPN・Flow・PCAPの役割を使い分けられる
- 不審通信を時系列で整理できる
- NATやプロキシを考慮して通信元を追跡できる
- 調査結果を影響範囲と根拠付きで報告できる
インシデント発生時の通信調査とは
インシデント発生時の通信調査とは、 ネットワーク上に残されたログや通信データを分析し、 発生事象・通信経路・影響範囲を事実として明らかにする作業です。
たとえば、監視システムから次のようなアラートが発生したとします。
検知内容：
社内端末 10.10.20.45 から、
通常利用していない外部IPアドレスへの通信を継続的に検知した。
この時点では、 「不審な通信があった」ことしか分かりません。
実際の調査では、さらに次の点を確認します。
- 10.10.20.45 はどの端末か
- 誰が利用していた端末か
- いつ通信を開始したか
- どの外部IP・ドメインへ接続したか
- TCP/UDPのどちらか
- 宛先ポートは何番か
- 通信は成功しているか
- 送受信されたデータ量はどの程度か
- 同じ宛先へ通信している端末が他にもないか
- 社内の別端末へ横展開した形跡がないか
通信調査では「推測」と「確認できた事実」を分けます。
「マルウェアだと思う」ではなく、 「10:15から10:45まで、端末Aから外部IP BへTCP/443で 30秒間隔の通信を確認した」のように整理します。
通信調査で明らかにすること
インシデント対応では、主に次の5つを明らかにします。
何が起きたか
外部接続、スキャン、ファイル転送、 認証通信など、観測された通信内容を整理します。
いつ起きたか
最初の通信、継続時間、 最後に確認された時刻を特定します。
どの端末が関係したか
IPアドレス、MACアドレス、 DHCP・VPN・認証ログなどから端末を特定します。
どこまで影響したか
同一宛先への通信、 社内端末間通信などから影響範囲を確認します。
何を止めるべきか
端末隔離、宛先IP遮断、ドメイン遮断など、 被害拡大防止策を検討します。
通信調査だけですべての原因を確定できるとは限りません。 必要に応じて、端末ログ、EDR、OSログ、 認証ログ、サーバーログなどと組み合わせて判断します。
インシデント通信調査の全体フロー
INCIDENT NETWORK ANALYSIS｜通信調査の基本フロー
アラート・申告
ログ・PCAP保存
5W1H整理
類似通信検索
隔離・遮断
根拠・影響・対応
- アラート内容を確認する 検知時刻、対象IP、検知ルール、 宛先など、調査開始点となる情報を確認します。
- 必要なログを保存する ログローテーションやセッション消失に備え、 調査対象期間のデータを確保します。
- 通信元と通信先を特定する IPアドレスだけでなく、 端末・利用者・ネットワークセグメントまで確認します。
- 通信内容と時系列を整理する ポート、プロトコル、通信量、 開始・終了時刻を確認します。
- 同様の通信を横断検索する 他端末や他拠点にも同じ兆候がないか確認します。
- 必要な封じ込めを実施する 端末隔離やアクセス制御を関係者と調整します。
- 調査結果を記録する 事実、推測、未確認事項を分離して報告します。
最初に確認する7つの情報
通信調査では、いきなり大量のログを眺めるのではなく、 最初に調査軸を決めます。
| 確認項目 | 確認内容 | 例 |
|---|---|---|
| 時刻 | いつ通信したか | 2026/08/16 10:15:23 |
| 送信元 | どこから通信したか | 10.10.20.45 |
| 宛先 | どこへ通信したか | 203.0.113.80 |
| プロトコル | TCP・UDP・ICMPなど | TCP |
| ポート | どのサービスを利用したか | 443 |
| 通信方向 | 内部→外部、外部→内部、内部→内部 | 社内→インターネット |
| 通信量 | 送受信されたデータ量 | 送信120MB／受信4MB |
この7項目を整理するだけでも、 「何を追加調査すべきか」がかなり見えやすくなります。
通信調査に使用するログ・データ
ネットワーク調査では、 一つのログだけで判断せず、複数の情報を突き合わせます。
| データ | 分かること | 主な用途 |
|---|---|---|
| ファイアウォールログ | 送信元、宛先、ポート、許可・拒否、通信量 | 外部通信の確認 |
| DNSログ | どのドメインを名前解決したか | アクセス先ドメインの確認 |
| Proxyログ | URL、利用者、HTTP通信など | Webアクセス調査 |
| VPNログ | 利用者、接続元IP、接続時刻 | リモートアクセス確認 |
| DHCPログ | IPアドレスを使用していた端末 | 端末特定 |
| NetFlow等 | 通信元・宛先・ポート・通信量・継続時間 | 大量通信の傾向分析 |
| パケットキャプチャ | 通信をパケット単位で詳細確認 | 通信成立状況やプロトコル解析 |
ファイアウォールログの例
このログから少なくとも、 10.10.20.45から203.0.113.80のTCP/443へ通信が許可された ことが確認できます。
ただし、TCP/443だからといって 「安全なHTTPS通信」と断定することはできません。 ポート番号は調査の手掛かりの一つです。
パケットキャプチャの確認ポイント
パケットキャプチャを取得できる場合は、 Wiresharkなどで通信を詳細に確認できます。
まず通信相手で絞り込む
ip.addr == 10.10.20.45特定の宛先との通信だけを確認する場合は、 次のように絞り込みます。
ip.addr == 10.10.20.45 && ip.addr == 203.0.113.80TCPポートで確認する
tcp.port == 443DNS通信を確認する
dns特定端末のDNSだけ確認する
ip.addr == 10.10.20.45 && dnsTCP接続
SYN → SYN/ACK → ACK が成立しているか確認し、 宛先とのTCP接続が成立したか判断します。
DNS
接続直前にどのドメインを問い合わせているか確認します。
通信間隔
一定間隔で繰り返しているか、 突発的な通信なのかを確認します。
データ量
送信量と受信量を比較し、 大量の外向きデータがないか確認します。
TLSなどで暗号化されている場合、 パケットキャプチャから通信内容そのものを確認できないことがあります。 その場合でも、接続先、通信時刻、通信量、 TLS関連情報などから調査できる項目があります。
不審通信で確認したい代表的なパターン
1回の通信だけでは判断しにくいため、 通信パターンを見ることが重要です。
一定間隔の外部通信
数十秒・数分ごとなど、 一定間隔で同じ宛先へ接続していないか確認します。
大量の外向き通信
通常より極端に多いデータが外部へ送信されていないか確認します。
多数宛先への接続
短時間で多数のIPアドレスやポートへ接続していないか確認します。
通常利用しないポート
業務上利用していないポートへの通信が発生していないか確認します。
異常なDNS問い合わせ
普段アクセスしないドメインや、 非常に大量の名前解決が発生していないか確認します。
内部端末間の横方向通信
侵害された可能性のある端末から、 他端末へ急に通信が増えていないか確認します。
「不審に見える通信＝攻撃」とは限りません。
バックアップ、資産管理、監視、 ソフトウェア更新などが大量通信や定期通信を発生させることがあります。 正常時の通信や業務要件と比較して判断します。
NAT・プロキシ環境で通信元を追跡するときの注意点
インターネット側のログだけを見ると、 社内端末のIPアドレスが分からない場合があります。
NAT環境での通信追跡
10.10.20.45
アドレス変換
198.51.100.10
203.0.113.80
外部サービス側では、
送信元として 198.51.100.10 しか見えないことがあります。
そのため、次の情報を組み合わせます。
- NAT変換ログ
- 送信元ポート番号
- 通信時刻
- DHCPログ
- 認証ログ
- VPNログ
IPアドレスだけでは利用者を特定できない場合があります。
DHCP、NAT、VPNなどでアドレスが変化する環境では、 「その時刻に誰がそのIPアドレスを使用していたか」を追跡します。
プロキシ環境も同じ考え方
Proxy経由の通信では、 外部から見るとProxyサーバーが通信元になります。
この場合はProxyログから、 利用者、内部IP、URL、時刻などを追跡します。
時刻を合わせてインシデントのタイムラインを作る
インシデント調査では、 時刻の整合性が非常に重要です。
たとえば次のログがあるとします。
- DNSログ：端末Aが特定ドメインを名前解決
- Firewall：端末Aから外部IPへのTCP/443を許可
- パケット：TCPセッション成立
- Flowログ：一定間隔で外部通信を継続
- Firewall：端末Aから社内サーバーへの通信増加
このように時系列で並べることで、 単独では意味が分かりにくかったログ同士の関連が見えてきます。
機器間の時刻差に注意する
Firewall、サーバー、PCなどの時刻がずれていると、 誤った順番で事象を判断してしまう可能性があります。
そのため、平常時からNTPなどを利用し、 ログの時刻基準を統一しておくことが重要です。
通信遮断と証拠保全をどう考えるか
明らかに危険な通信が継続している場合、 被害拡大を防ぐために通信遮断が必要になることがあります。
ただし、 「すぐ設定を変更する」ことだけが正解ではありません。
| 対応 | 例 | 考慮事項 |
|---|---|---|
| 端末隔離 | 対象PCをネットワークから切り離す | 業務影響、調査継続可否 |
| IP遮断 | FWで特定宛先を拒否 | 正規サービスとの共有有無 |
| ドメイン遮断 | DNS・Proxy等で制御 | 関連ドメイン、CDN等 |
| セグメント隔離 | 特定VLANからの通信を制限 | 影響範囲が大きい |
| アカウント停止 | 侵害が疑われる認証情報を無効化 | 認証基盤との連携が必要 |
対応を行う前に可能な範囲で、 対象ログ、設定情報、パケットキャプチャ、 アラート情報などを保存します。
実際のインシデント対応では、 組織のCSIRT・SOC・セキュリティ担当者や インシデント対応手順に従って判断してください。
調査結果をどう報告するか
通信調査が終わったら、 技術情報をそのまま大量に報告するのではなく、 事実・影響・対応に整理します。
報告に入れたい内容
1．検知内容
いつ、どのアラートを起点として調査を開始したか。
2．対象
IP、端末名、利用者、セグメントなど。
3．確認できた通信
宛先、ポート、時間帯、通信量など。
4．影響範囲
他端末にも同様の通信があるか。
5．実施済み対応
端末隔離、通信遮断など。
6．未確認事項
追加調査が必要な項目を明確化します。
報告例
調査結果：
10:13から10:40まで、端末PC-045（10.10.20.45）から
外部IPアドレス203.0.113.80へのTCP/443通信を確認しました。
通信は約30秒間隔で継続しており、 Firewallログ上では接続が許可されています。 現時点で同一宛先へ通信している他端末は確認されていません。
対象端末はネットワークから隔離済みです。 現在、端末側ログと通信データを追加確認しており、 情報流出の有無については未確定です。
事実と推測を分ける
| 悪い例 | 改善例 |
|---|---|
| マルウェアが外部へ情報を送信しました。 | 端末Aから外部IPへの通信と約120MBの送信を確認しています。 送信データの内容については現在調査中です。 |
| 他端末への感染はありません。 | 現時点のFirewallログでは、 同一宛先へ通信した他端末は確認されていません。 |
インシデント報告では、 確認できたこと・確認できていないこと・次に確認すること を明確にすると、関係者が判断しやすくなります。
インシデント通信調査で使われる英語表現
よく使われる単語
| 英語 | 意味 |
|---|---|
| Security incident | セキュリティインシデント |
| Network traffic | ネットワーク通信 |
| Source IP address | 送信元IPアドレス |
| Destination IP address | 宛先IPアドレス |
| Packet capture | パケットキャプチャ |
| Suspicious traffic | 不審な通信 |
| Outbound traffic | 外向き通信 |
| Inbound traffic | 内向き通信 |
| Containment | 封じ込め |
| Evidence | 証拠 |
| Timeline | 時系列・タイムライン |
| Scope of impact | 影響範囲 |
海外ベンダーへの問い合わせで使える表現
We detected suspicious outbound traffic from the affected host.
対象端末から不審な外向き通信を検知しました。
The communication started at approximately 10:13 JST.
通信は日本時間10時13分頃に開始しました。
We are currently investigating the scope of impact.
現在、影響範囲を調査しています。
The affected endpoint has been isolated from the network.
影響を受けた端末はネットワークから隔離済みです。
理解度チェック
通信調査の考え方を理解できているか、 5問で確認しましょう。
問題1．インシデント通信調査で最初に行うこととして、 最も適切なものはどれですか。
- すべての外部通信を停止する
- 対象機器を初期化する
- 検知時刻・送信元・宛先など調査起点を整理する
- 原因をマルウェアと決める
解答を見る
まずアラート情報や通信情報を整理し、 調査対象と期間を明確にします。
問題2．外部から見えるグローバルIPから 実際の社内端末を追跡する際に重要なログはどれですか。
- NAT変換ログ
- ディスプレイ設定
- プリンター設定
- CPU温度ログのみ
解答を見る
NAT環境では、 NAT変換時刻、内部IP、外部IP、 ポートなどを確認して端末を追跡します。
問題3．TCP/443への通信が確認できました。 この事実だけから「安全なHTTPS通信」と判断できますか。
解答を見る
ポート番号だけでは通信の安全性を確定できません。 宛先、時刻、頻度、通信量、DNS、 パケットなどを組み合わせて確認します。
問題4．複数機器のログを時系列で比較するときに 特に重要なネットワークサービスは何ですか。
解答を見る
機器ごとの時刻がずれていると、 インシデントの発生順序を誤って判断する可能性があります。
問題5．インシデント報告で 「確認できた事実」と「推測」を分ける必要があるのはなぜですか。
解答例を見る
未確認の情報を確定事項として伝えると、 誤った遮断や業務判断につながる可能性があるためです。 調査済み・未調査・推測を明確に区別します。
実践演習：不審な外部通信を調査する
あなたは企業ネットワークのセキュリティ担当です。 SOCから次の連絡を受けました。
SOCからの連絡
社内端末 10.10.20.45 から 外部IP 203.0.113.80 への 不審な通信を検知しました。
Firewallログ
DNSログ
追加調査結果
- 10.10.20.45はPC-045に割り当てられている
- 約30秒間隔で同じ外部IPへ通信している
- 他の社内端末から同じ宛先への通信は現時点で未検知
- 対象端末では通常利用しない通信先である
課題1．確認できた事実を整理する
宛先：＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
プロトコル／ポート：＿＿＿＿＿＿＿＿＿＿
通信開始時刻：＿＿＿＿＿＿＿＿＿＿＿＿＿
特徴：＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
解答例を見る
- 送信元：10.10.20.45（PC-045）
- 宛先：203.0.113.80
- プロトコル／ポート：TCP/443
- 通信開始確認時刻：10:13:05
- 約30秒間隔で同一宛先への通信を継続
- 直前にupdate-check.exampleを名前解決している
課題2．次に確認すべき情報を5つ考える
2．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
3．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
4．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
5．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
解答例を見る
- 通信がいつまで継続していたか
- 送受信した総データ量
- PC-045の利用者
- 対象端末から社内他端末への不審通信
- 同じドメイン・IPへの過去の通信履歴
- 端末のEDR・OS・プロセスログ
- 対象ドメインへのアクセスが業務上必要か
課題3．上司への一次報告を作る
原因がまだ確定していない状態で、 100〜200文字程度の一次報告を書いてください。
報告例を見る
10:13頃から、PC-045（10.10.20.45）より 外部IP 203.0.113.80へのTCP/443通信を約30秒間隔で確認しています。 同一宛先への通信は現時点で他端末からは確認されていません。 対象端末の隔離要否をセキュリティ担当と確認しつつ、 通信継続時間・通信量・端末ログを追加調査しています。
課題4．タイムラインを作る
DNSログとFirewallログを使い、 時系列で発生事象を整理してください。
10:13:05 ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
10:13:35 ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
10:14:05 ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
解答例を見る
- 10:13:02：update-check.exampleをDNS問い合わせ
- 10:13:02：203.0.113.80を名前解決
- 10:13:05：203.0.113.80へのTCP/443通信を確認
- 10:13:35：同一宛先への通信を再度確認
- 10:14:05：同様の通信を継続して確認
自分の言葉で説明する課題
後輩エンジニアから、 「セキュリティインシデントが起きたら、 ネットワーク担当は何を調べるんですか？」 と質問されました。
1分程度で説明してください。
説明例を見る
インシデント発生時は、 Firewall、DNS、VPN、パケットキャプチャなどを確認し、 いつ、どの端末から、どこへ、 どのような通信が行われたかを整理します。
さらに同じ通信が他端末にもないか確認し、 影響範囲を特定します。 調査結果は事実と推測を分け、 必要に応じて端末隔離や通信遮断につなげます。
まとめ
- インシデント通信調査では、 ログやパケットから発生事象・通信経路・影響範囲を整理する
- 最初に時刻、送信元、宛先、プロトコル、 ポート、方向、通信量を確認する
- Firewall、DNS、Proxy、VPN、DHCP、 Flow、PCAPなどを組み合わせて調査する
- 一定間隔通信、大量送信、多数宛先通信、 内部端末間通信などのパターンを見る
- NAT環境では変換ログやポート番号、 時刻から実際の内部端末を追跡する
- 複数ログを時系列で比較するために 時刻同期が重要
- 封じ込めを行う際は業務影響と証拠保全を考慮する
- 報告では「確認できた事実」「未確認事項」 「次の対応」を分けて伝える
インシデント対応で重要なのは、 「怪しい」と判断することではなく、 「どのログを根拠に、何が起きたと言えるのか」を 説明できることです。
上級編では、要件定義・基本設計・BGP・クラウド・ セキュリティ・自動化・設計レビュー・顧客提案までを 順番に学びます。
コメント