Windows Server 2016でアクセスしたIPアドレスを確認する方法｜ファイアウォール監視・ログ・PowerShell

Windows Server 2016で「このサーバーがどのIPアドレスへ通信したか」を調べたい場面は、障害調査や不正アクセス対策でよくあります。ただしWindowsは標準状態では“通信履歴をすべて保存”していません。今見える範囲の確認方法と、今後に備えてログを残す設定を具体的に解説します。

結論：標準状態で「過去の通信先IPを時系列で一覧」にはできない

Windows Server 2016 では、ブラウザの履歴のように「サーバーがアクセスしたIPアドレスの履歴」を自動で無制限に保存しているわけではありません。確認できるのは大きく分けて次の3パターンです。

• いま確立している（または直近の）接続を確認する（例：netstat、PowerShell など）
• IPsec/接続セキュリティに関係する通信を「監視」画面で確認する（Windows ファイアウォールの詳細設定）
• 将来に備えてログを有効化して蓄積し、後から検索できる状態にする（ファイアウォールログ／イベントログ／Sysmon 等）

目的	おすすめ手段	確認できること	弱点・注意点
いま接続している相手先IPを知りたい	netstat / Get-NetTCPConnection / リソースモニター	接続先IP・ポート、プロセス（PID）	過去の履歴は残らない
IPsecの通信先IPを確認したい	Windows ファイアウォール（詳細設定）→［監視］→ セキュリティの関連付け	IPsec/接続セキュリティに紐づく接続情報	「すべての通信」の一覧ではない
後から「いつ・どこへ・何が通信したか」を追いたい	ファイアウォールログ（pfirewall.log）／監査ログ（5156等）／Sysmon	時系列、宛先IP・ポート、許可/遮断、アプリ情報（手法による）	ログ量が増える／保存設計が必要

運用で失敗しないための前提：送信（Outbound）と受信（Inbound）を切り分ける

「アクセスしたIPアドレス」を調べるとき、現場では送信（Outbound）と受信（Inbound）が混ざって混乱しがちです。例えば、外部からサーバーに来た通信（受信）を「アクセスされた」と表現する人もいれば、サーバーから外部へ出て行った通信（送信）を「アクセスした」と表現する人もいます。

本記事で主に扱うのはサーバーが外部（または別サーバー）へ接続した宛先IP＝送信の通信先IPです。調査の最初に、どちらを追いたいのかを明確にしておくと、ログの取り方がブレません。

見たいもの	例	見るべき場所
送信（Outbound）の宛先IP	更新サーバー、API、外部Web、メール送信先など	Get-NetTCPConnection / pfirewall.log / 5156 / Sysmon
受信（Inbound）の接続元IP	RDP接続元、Webアクセス元、SMB接続元など	IISログ、RDPログ、セキュリティログ、pfirewall.log など

まず確認したい：「現在/直近」の接続先IPアドレスを調べる

方法A：Windows ファイアウォール（詳細設定）の［監視］で見える範囲

ご質問にある通り、Windows標準機能として「Windows ファイアウォールの詳細設定」の監視機能から、通信先IPを確認できるケースがあります。

操作手順（日本語環境イメージ）

1. 「スタート」→ 検索で wf.msc を実行し、「Windows ファイアウォールの詳細設定」を開く
2. 左ペインで［監視］を選択
3. 監視の中から［セキュリティの関連付け］（英語UIでは Security Associations）を開く
   • 表示される項目例：メインモード／クイックモード（環境により表示が異なります）
4. 中央ペインに、確立している相手先のIPアドレス等が一覧表示される

ポイント

• ここで見えるのは主にIPsec/接続セキュリティ ルールに基づく通信など、一部の通信に限られます。
• 「セキュリティの関連付け」が空だったり表示が少ない場合、IPsec が使われていない、またはタイミング的にセッションが存在しない可能性があります。
• サーバーがアクセスした通信先を網羅する用途には向きませんが、IPsec周りの調査では最短で役立つことがあります。

方法B：netstatで「いま接続している宛先IP」を確認する（標準コマンド）

「アクセスしたIPアドレス」をいまの接続（Established）として確認するなら、netstat が最も手軽です。管理者権限のコマンドプロンプトで実行します。

netstat -ano

出力の見方は以下の通りです。

• Foreign Address：接続先（宛先）のIPアドレスとポート
• State：TCPの状態（例：ESTABLISHED / TIME_WAIT）
• PID：通信しているプロセスID

PIDから「どのアプリがそのIPに接続したか」を特定するには、tasklist を組み合わせます。

tasklist /FI "PID eq 1234"

さらに、特定の宛先IPに絞って確認したい場合は findstr が便利です。

netstat -ano | findstr 203.0.113.10

注意：netstat は「いま/直近」の情報です。数日前の通信先を遡る用途には向きません。

方法C：PowerShellで「宛先IP＋プロセス名」を一覧化する

Windows Server 2016 では PowerShell で現在の接続をかなり見やすくできます。特にGUIを触れない運用（リモート作業、サーバーコア）では強力です。

# TCPの接続先を、プロセス名付きで一覧化（管理者権限推奨）
Get-NetTCPConnection |
  Where-Object { $_.State -eq 'Established' -and $_.RemoteAddress -ne '::' -and $_.RemoteAddress -ne '0.0.0.0' } |
  Select-Object LocalAddress,LocalPort,RemoteAddress,RemotePort,State,OwningProcess,
    @{Name='ProcessName';Expression={(Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue).ProcessName}} |
  Sort-Object RemoteAddress,RemotePort

上記で出てくる RemoteAddress が「アクセス先IP」です。アプリ名（ProcessName）まで分かるので、原因究明が一気に進みます。

方法D：リソースモニターでGUI確認（RDPでの一次調査向け）

RDPでGUI操作できるなら、リソースモニター（Resource Monitor）も直感的です。

1. 「ファイル名を指定して実行」→ resmon
2. ［ネットワーク］タブ → 「TCP接続」
3. プロセスごとに、リモートアドレス（宛先IP）とポートを確認

「何日前にアクセスしたIP」を追いたい場合に知っておくべき制限

インシデント調査では「先週このサーバーがどこへ通信したのか」を追いたくなります。しかし標準状態の Windows Server 2016 では、次の理由で難しいことが多いです。

• 接続情報はセッションが切れると消える（netstat や監視画面は“いま”が中心）
• ファイアウォールや監査ログも、明示的に有効化しないと詳細が残らない
• ログを有効にしても、保存容量・上書き・ローテーション設計がないと必要な期間が残らない

つまり「過去の通信先を確実に追う」には、今後のためにログを仕込むのが現実解です。ここからは、Windows Server 2016で実務的に効果が高い順に紹介します。

本格的にログを残す方法：Windows ファイアウォールログ（pfirewall.log）

ファイアウォールログで何が分かる？

Windows Defender Firewall（Windows ファイアウォール）のログを有効にすると、送受信の許可/遮断の記録がファイルに残ります。通信先IP（宛先IP）も含まれるため、「このサーバーがどのIPに通信したか」を後から検索できるようになります。

項目	内容	実務での使いどころ
ログ形式	テキスト（既定：pfirewall.log）	検索が速い。ログ基盤に取り込みやすい
宛先IP	dst-ip（Destination IP）として記録	「どこに通信したか」を確認できる
宛先ポート	dst-port として記録	HTTP/HTTPS など用途の推測がしやすい
許可/遮断	action（ALLOW / DROP など）	ブロック原因の切り分けに便利
プロセス名	基本は残りにくい（環境/設定次第）	「どのアプリが」は別手段（監査/Sysmon）と併用

ファイアウォールログを有効にする前に：適用プロファイルを確認する

Windows ファイアウォールのログは、ドメイン/プライベート/パブリックのプロファイルごとに設定が分かれています。設定したのにログが増えない場合、別のプロファイルが適用されていることが原因のケースがよくあります。

# どのプロファイルが適用されているか確認
Get-NetConnectionProfile | Select-Object InterfaceAlias, NetworkCategory, IPv4Connectivity, IPv6Connectivity

表示された NetworkCategory（DomainAuthenticated/Private/Public）に対応するプロファイルでログ設定を行うのが基本です。

有効化手順（Windows ファイアウォールの詳細設定）

ファイアウォールログは、プロファイル（ドメイン/プライベート/パブリック）ごとに設定します。サーバーの用途に合わせて、まずは実際に適用されているプロファイルから設定してください。

1. wf.msc を開く
2. 左ペインで最上位の「Windows ファイアウォールの詳細設定」を右クリック → ［プロパティ］
3. ［ドメイン プロファイル］/［プライベート プロファイル］/［パブリック プロファイル］のいずれかで、［ログのカスタマイズ］（または［設定］→ ログ）を開く
4. 次を設定する
   • ログファイルのパス（既定は %systemroot%\\system32\\logfiles\\firewall\\pfirewall.log）
   • ログの最大サイズ（必要期間が残るサイズに）
   • ドロップされたパケットをログに記録する：まずはオン推奨
   • 成功した接続をログに記録する：必要ならオン（ログ増加に注意）

運用のコツ

• 最初は「ドロップのみ」で開始し、必要になったら「成功した接続」もオンにする方が安全です（ログ爆発を避けやすい）。
• 「成功した接続」までオンにするなら、ログ最大サイズの増加や定期的な退避（ローテーション）がほぼ必須です。

ログ保存設計：必要な期間を残すための現実的な考え方

「ログを有効化する」だけでは、いざという時に必要な期間の記録が残っていないことがよくあります。特に“成功した接続”を記録する場合は、ログが想像以上に増えることがあります。

最低限押さえるチェックリスト

チェック項目	目安	理由
保存場所	OS領域とは別ドライブ/別ボリュームも検討	Cドライブ逼迫で障害を起こさないため
最大サイズ	「必要保持日数 × 1日あたりの増加量」から逆算	上書きされる前に期間を確保するため
ローテーション	日次/週次で退避・圧縮	ログが上書きされる、消える問題を防ぐ
集約	イベント転送（WEF）/SIEM/ログサーバー	検索性と保全性（改ざん耐性）を上げる
アクセス制御	ログ閲覧/削除できる権限を最小化	インシデント時の証跡性を確保

簡易ローテーション例（pfirewall.logを日次でコピー退避）

まずは「上書きで消える」を避けたいだけなら、タスクスケジューラで日次実行するだけでも効果があります（環境に合わせてパスは調整してください）。

# 例：pfirewall.log を日付付きで退避（コピーのみ。元ログはファイアウォールの設定に従って上書き）
$src = "$env:windir\\System32\\LogFiles\\Firewall\\pfirewall.log"
$dstDir = "D:\\FirewallLogs"
New-Item -ItemType Directory -Path $dstDir -Force | Out-Null
$dst = Join-Path $dstDir ("pfirewall_{0:yyyyMMdd}.log" -f (Get-Date))
Copy-Item $src $dst -Force

「一定期間を確実に残す」「改ざんされないようにする」まで考えるなら、ログ集約（イベント転送/SIEM）まで含めて設計するのが理想です。

pfirewall.log の主要フィールド（見方）

pfirewall.log は先頭に # で始まるヘッダ行があり、フィールド順が書かれています。代表的なフィールドを押さえておくと調査が速くなります。

フィールド	意味	確認ポイント
date / time	日時	問題が起きた時間帯に絞り込む
action	ALLOW / DROP など	通信できない原因が遮断かどうか
protocol	TCP/UDP/ICMP など	アプリの挙動や用途推定に使う
src-ip / src-port	送信元IP/ポート	複数NICのサーバーで有効
dst-ip / dst-port	宛先IP/ポート	「アクセスしたIPアドレス」＝ dst-ip
path	アプリのパス（記録される場合）	プロセス特定のヒントになることも

ログから「特定の宛先IP」を検索する例

テキストログなので、まずは単純検索が強いです。PowerShell で特定の宛先IPを探す例です。

# 例：宛先IP 203.0.113.10 が含まれる行を抽出
Select-String -Path "$env:windir\\System32\\LogFiles\\Firewall\\pfirewall.log" -Pattern "203.0.113.10"

「日時で絞る」「宛先ポートで絞る」など条件を増やすと、より実務向きになります。

イベントログで宛先IPを残す：監査（Windows Filtering Platform）を使う

監査ログのメリット

ファイアウォールログは便利ですが、ケースによっては「どのプログラムが通信したか」「どのユーザー権限で動いていたか」をもう一段深く追いたいことがあります。その場合に有力なのが、セキュリティイベントログのWindows Filtering Platform（WFP）関連の監査です。

イベントID例	意味	得られる情報のイメージ
5156	WFPが接続を許可	宛先IP/ポート、アプリケーション情報など（イベント詳細に記録）
5157	WFPが接続をブロック	ブロックされた宛先IP/ポート、ルール情報の手がかり

※イベント内容は監査設定や環境により出方が変わります。ログ量も増えやすいため、サーバーの役割（AD/SQL/Web等）と相談して有効化範囲を決めましょう。

監査を有効にする手順（ローカル）

1. 「ファイル名を指定して実行」→ secpol.msc（ローカル セキュリティ ポリシー）を開く
2. ［詳細監査ポリシーの構成］ → ［オブジェクト アクセス］ を開く
3. 「フィルタリング プラットフォーム接続の監査」（または同等の項目）を成功/失敗で有効にする
4. イベント ビューアー → ［Windows ログ］→［セキュリティ］ に記録されることを確認する

ドメイン参加サーバーでは、グループポリシーで統制した方が設定漏れを防げます（GPO：コンピューターの構成 → ポリシー → Windows の設定 → セキュリティの設定 → 詳細監査ポリシー）。

イベントログから宛先IPを抽出する例（PowerShell）

セキュリティログは量が多いので、まずはイベントIDと期間で絞るのが基本です。

# 直近24時間の「接続許可（5156）」を取得（環境により時間がかかる場合があります）
$start = (Get-Date).AddHours(-24)
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=5156; StartTime=$start} |
  Select-Object TimeCreated, Id, Message |
  Select-Object -First 20

実務では、Message から宛先IP（Remote Address）や宛先ポート（Remote Port）を拾う、あるいはイベントのXMLから必要フィールドだけを抜く方法がよく使われます。ログ収集基盤（SIEM/ログサーバー）があるなら、検索性はさらに上がります。

「どのプロセスがどこへ通信したか」を確実に残す：Sysmonの活用

標準機能だけだと「宛先IP」は追えても、プロセス名まで一貫して残すのは難しい場面があります。そこで、サーバー監査で定番の選択肢が Sysmon（Sysinternals） です。追加導入は必要ですが、ネットワーク接続のイベント（例：Event ID 3）で、宛先IP/宛先ポート/プロセス/ユーザーまで記録できます。

Sysmon運用のポイント

• 導入前にログ量の見積もりを行う（Webサーバーやプロキシは特に増えやすい）
• 設定（config）で不要な通信を除外し、調査したい通信だけ残す
• 単体サーバーに溜め込むより、イベント転送（WEF）やログ基盤に集約すると調査が楽

「過去の宛先IPを追える状態にしたい」という目的に対して、Sysmonは非常に相性が良いので、インシデント対応や監査要件がある環境では検討価値があります。

ネットワーク機器・プロキシのログも重要（“最終的な宛先”が見えない場合）

サーバー側で宛先IPを確認しても、環境によっては本当のアクセス先が見えないことがあります。代表例は次の通りです。

• 社内プロキシ経由：サーバーから見える宛先は「プロキシのIP」。外部の最終宛先（Webサイト等）はプロキシログに残る
• NAT/ゲートウェイ経由：外部から見える送信元IPはゲートウェイ。端末単位の追跡は内部ログが必要
• CDN/クラウド：同じFQDNでも宛先IPが頻繁に変わる（DNS負荷分散）

「どの端末が、どのFQDN（サービス）に、いつアクセスしたか」を確実に残すには、UTM/ファイアウォールアプライアンス/プロキシ/クラウドの監査ログと組み合わせるのが王道です。

調査を速くする実践テクニック

IPアドレスを名前に引き戻す（逆引きDNS・whois）

ログに残るのは基本的にIPアドレスです。相手が何者かを素早く把握するには、まずDNSで名前が引けるか確認します。

# 逆引き（PTR）が設定されていれば名前が返る
nslookup 203.0.113.10

逆引きできないことも多いので、その場合は「そのIPがどの組織に割り当てられているか」を調べる（whois）など、別の手段も併用します。社内のセキュリティ運用としては、不審な宛先IPのリスト化や許可先の棚卸し（ホワイトリスト運用）を進めると、調査コストが下がります。

IPv6の表示に注意する

Windows Server 2016 では IPv6 が有効なことが多く、netstat や PowerShell で :: や IPv6 アドレスが混ざって見えます。調査対象がIPv4のみなら、フィルタ条件を付けて見やすくしましょう（例：RemoteAddress がIPv4形式のものだけ抽出）。

ログが膨大で追えないときの対処

ログを有効にした途端に「量が多すぎて見られない」というのはよくある失敗です。次の順番で対処すると、必要な情報だけ残しやすくなります。

1. 期間を絞る：障害発生時刻の前後だけ
2. 宛先ポートを絞る：例：443、80、25、53 など
3. 宛先IP（または宛先レンジ）を絞る：不審なIPだけ
4. プロセス単位に絞る：Sysmon/監査ログで実現
5. 保存設計を見直す：ログサイズ、ローテーション、集約先

目的別のおすすめ構成（迷ったらこの組み合わせ）

目的	まずやること	継続的にやること	備考
いまの通信先を把握したい	Get-NetTCPConnection / netstat	必要ならファイアウォールログを有効化	障害調査の初動に強い
遮断されている通信先を知りたい	ファイアウォールログ（DROP）を有効化	ルール設計（送信規則）を見直す	「成功した接続」は後から検討でOK
不審通信を後追いできるようにしたい	監査（5156/5157）の有効化	Sysmon＋ログ集約（WEF/SIEM）	運用設計が重要（ログ量/保管）
最終的なWebアクセス先まで追いたい	サーバー側の宛先IP確認	プロキシ/UTM/クラウド監査ログを併用	サーバー側だけでは限界がある

まとめ

• Windows Server 2016 では、標準状態で「過去の通信先IPを全部保存」しているわけではない。
• 手早く確認するなら、netstat / Get-NetTCPConnection / リソースモニターで「いま接続している宛先IP」を見る。
• ご質問の方法として、「Windows ファイアウォールの詳細設定」→［監視］→［セキュリティの関連付け］で一部の通信先IPを確認できるが、主にIPsec等に関係する範囲であり網羅的ではない。
• 「いつ・どのIPにアクセスしたか」を継続的に把握したいなら、ファイアウォールログ（pfirewall.log）や監査ログ（5156/5157）、必要に応じてSysmonを有効化し、保存と検索の設計を行うのが現実的。