Windows Server 2016 から 184.xx.xx.xx（Akamai系）へ 443/TCP の通信が延々と続くと、不正通信ではと疑ってしまいます。多くは Windows Update や Defender 定義更新などの正規動作ですが、原因プロセスを特定し、安全に止めるための手順を整理します。
まず結論：184.*（Akamai系）への通信は「異常とは限らない」
観測されている 184.xx.xx.xx（例：184.26.245.154:443 / 184.27.112.92:443）のようなIPは、AkamaiのCDN（コンテンツ配信ネットワーク）で使われることが多く、Windows Server 2016 が外部コンテンツを取得する過程で到達するケースがあります。
CDNは、更新ファイル・定義ファイル・画像・スクリプトなどの配布物を「利用者に近い拠点」にキャッシュして高速に配布する仕組みです。そのため、通信先がMicrosoft本体のドメインではなく、AkamaiなどのCDNのエッジIPになっていても不自然ではありません。
重要なのは、IPアドレスだけを見て一律に遮断しないことです。CDNのIPは共有されやすく、同じIPが複数サービスに使われたり、配布拠点の切替でIPが頻繁に変わります。無造作に止めると、更新・ダウンロード・証明書検証などが壊れ、結果としてセキュリティや可用性を落とすことがあります。
それでも「止めたい」理由を整理する
通信を止めるべきかどうかは、サーバーの置かれた環境・役割で判断が変わります。まずは目的を言語化すると、対策の選択肢が絞れます。
| 目的 | よくある背景 | おすすめの進め方 |
|---|---|---|
| 不正通信の疑いを払拭したい | 見覚えのないIPへ継続接続、監査・SOCから指摘 | まずPID/プロセス特定→署名/パス確認→ログで裏取り |
| インターネット向け送信をゼロにしたい | 閉域網、厳格なセキュリティ要件、DMZ | 出口設計（プロキシ/FW）＋WSUS等の代替経路を用意 |
| 通信量やセッション数を減らしたい | 回線が細い、コスト増、機器のセッション逼迫 | Windows Update/Defenderの運用見直し（スケジュール化） |
| 業務影響を最小にして部分的に止めたい | 特定アプリだけ外に出したくない | Windows Defender ファイアウォールの送信規則をアプリ/サービス単位で制御 |
止める前に必ず行う切り分け
「184.*へ通信している」という事実だけでは、原因も危険度も分かりません。最短で結論に近づくために、次の観点で切り分けます。
その通信は本当にサーバー自身が発生させているか
- 境界ファイアウォールやL3機器のログで、送信元がサーバーIPになっているか確認する
- NAT配下の場合、NAT後のIPだけ見て「サーバーが送信している」と誤認しない（内部IP/ポートの対応表も確認）
通信は「誰が」「いつ」「どれくらい」発生しているか
後工程の判断材料になるので、最低限この3点をメモします。
- 宛先：184.xx.xx.xx:443 のどれか（複数か、固定か）
- 頻度：常時か、一定間隔（例：数分/数時間/毎日）か
- データ量：数KB程度か、MB/GB単位か
通信元プロセスを特定する方法
「止める」ためには、通信しているプロセス（実行ファイル）を特定するのが最短ルートです。IPを丸ごと止めるより、原因プロセスにピンポイントで対処できます。
GUIで確認する
- リソース モニター：タスクマネージャーから「リソース モニター」→「ネットワーク」→「TCP接続」でPIDと接続先を確認
- Sysinternals TCPView：どのプロセスがどのIP/ポートに接続しているかをリアルタイム表示（管理者として実行推奨）
- Process Explorer：PIDからプロセスのパス、署名、親子関係まで追える
コマンドで確認する（まずはこれで十分）
まずは netstat でPIDを取り、プロセス名へ紐づけます。
netstat -ano | findstr ":443" | findstr "184\."
出てきたPIDをプロセス名に変換します。
tasklist /fi "PID eq 1234"
もしプロセスが svchost.exe の場合、svchost配下の「どのサービス」が通信しているかが重要です。次でサービス名まで落とします。
tasklist /svc /fi "PID eq 1234"
PowerShellで一覧化する（継続監視に向く）
PowerShellで「184.*へ接続中のセッション」を抽出できます。
# 184.* へ接続しているTCPセッションを表示
Get-NetTCPConnection -State Established |
Where-Object { $_.RemoteAddress -like "184.*" -and $_.RemotePort -eq 443 } |
Select-Object -Property LocalAddress,LocalPort,RemoteAddress,RemotePort,OwningProcess |
Sort-Object RemoteAddress
OwningProcess（PID）を基にプロセス名を引きます。
# PIDからプロセス名を取得
Get-Process -Id 1234 | Select-Object Id,ProcessName,Path
よくある「原因」と「止め方」の方向性
184.*（Akamai系）へ向かう通信は、OSの基盤機能・セキュリティ機能が発生源になりがちです。以下は現場で遭遇しやすいパターンです（必ずしもAkamai限定ではありません）。
| 通信元としてよく出るもの | 目的の例 | 止め方の考え方 | 止めるリスク |
|---|---|---|---|
| svchost.exe（wuauserv / BITS） | Windows Update、更新プログラム取得 | WSUSへ切替、更新タイミングの管理、最終手段でサービス単位ブロック | パッチ適用が止まり脆弱性が放置される |
| MsMpEng.exe 等（Defender） | 定義ファイル更新、クラウド保護 | 定義更新の経路を統制（WSUS/オフライン）、クラウド機能の見直し | 検知精度低下、ゼロデイ対応が遅れる |
| svchost.exe（CryptSvc） | 証明書失効確認（CRL/OCSP）、ルート証明書更新 | 必要性を評価してから。閉域網では社内PKI/配布設計が必要 | TLS接続失敗、アプリの通信が不安定化 |
| WerFault.exe / WerSvc | エラーレポート送信 | ポリシーで無効化、送信制限 | 障害解析の情報が減る |
| Office/Edge/ブラウザ系 | 更新、拡張機能、コンテンツ配信 | 製品更新の制御、プロキシ経由、アプリ単位ブロック | 脆弱性放置、機能不具合 |
推奨アプローチ：IPを止めるより「原因機能」を止める
結論として、184.*のようなCDNのIP帯を丸ごとブロックする設計は、運用負荷と副作用が大きくなりやすいです。代わりに、次の優先順位で制御すると安全です。
| 優先度 | 制御方法 | メリット | 注意点 |
|---|---|---|---|
| 高 | 更新/定義の取得先を社内へ寄せる（WSUS、社内ミラー、プロキシ） | セキュリティを維持しつつ外向き通信を削減 | サーバー/運用の用意が必要 |
| 中 | アプリ/サービス単位で送信を制御（Windows Defender ファイアウォール） | 影響範囲が狭く、原因に直撃できる | svchost配下はサービス特定が必須 |
| 低（最終手段） | 宛先IP（184.*）をブロック | 手っ取り早い検証ができる | IP変動で抜ける/巻き込む、長期運用に不向き |
WSUSでWindows Update通信を抑える（閉域網・厳格環境で特に有効）
もし原因が Windows Update 系（wuauserv/BITS）で、外部への更新取得を止めたいなら、WSUS（Windows Server Update Services）の導入が王道です。サーバーは社内WSUSだけを参照し、インターネット上の配布先（CDN）へ直接出ていかなくなります。
グループポリシーでWSUSを指定する
- 「コンピューターの構成」→「管理用テンプレート」→「Windows コンポーネント」→「Windows Update」
- 「イントラネットのMicrosoft更新サービスの場所を指定する」を有効化し、WSUSのURLを指定
- あわせて更新の適用タイミング（自動/通知/スケジュール）を決める
インターネットのWindows Updateへ接続させたくない場合
ポリシーの名称は環境で表記ゆれがありますが、意図としては「インターネット上のWindows Updateの場所へ接続しない」方向に寄せます。閉域網では、この設定がないと一部操作で外部へ出ようとすることがあります。
Windows Defender関連の通信を抑える（定義更新・クラウド保護）
Defenderが原因の場合、やみくもに止めるより「何を止めるのか」を分けるのがポイントです。
- 定義更新：マルウェア定義の更新。止めると検知が古くなる
- クラウドベースの保護：疑わしい挙動の照会など。要件次第では無効化されることもある
- サンプル自動送信：組織ポリシーで止めることが多い
厳格環境では、定義更新だけはWSUSやオフライン配布で維持し、クラウド機能はポリシーで制限する、という落としどころが現実的です。
Windows Defender ファイアウォールで送信通信を止める
原因プロセスが特定できたら、Windows Defender ファイアウォールの送信規則で「止める」ことができます。ポイントは、宛先IPを止める前に、まずアプリ/サービス単位で止めることです。
管理GUIで送信規則を作る手順
- 「wf.msc」（セキュリティが強化されたWindows Defender ファイアウォール）を開く
- 「送信の規則」→「新しい規則」
- 基本は「プログラム」を選び、対象EXE（例：不審なツール、特定アプリ）を指定
- 「接続をブロックする」を選択
- 適用するプロファイル（ドメイン/プライベート/パブリック）を選択
- 分かりやすい名前（例：Block outbound for XXX）で保存
svchost.exe配下を止めたい場合（サービス単位で絞る）
Windowsの基盤通信はsvchost.exeに集約されるため、svchost.exe自体を止めるのは危険です。サービス単位で絞り込みます（GUIでも指定可能）。
PowerShellでも作成できます。
# 例：Windows Update（wuauserv）だけ送信をブロック（検証用途）
New-NetFirewallRule `
-DisplayName "Block outbound - Windows Update service" `
-Direction Outbound `
-Action Block `
-Program "%SystemRoot%\\System32\\svchost.exe" `
-Service "wuauserv" `
-Protocol TCP `
-RemotePort 443 `
-Profile Any
同様に、BITSなど原因のサービスが判明している場合は置き換えます。
どうしてもIP（184.xx.xx.xx）をブロックしたい場合
検証目的で「観測したIPだけ」止めるなら、次のように作れます。ここでいきなり 184.0.0.0/8 のような巨大レンジを止めるのは避けてください。
# 例：観測されたIPのみブロック（短期検証向け）
New-NetFirewallRule `
-DisplayName "Block outbound - Akamai observed IPs" `
-Direction Outbound `
-Action Block `
-RemoteAddress 184.26.245.154,184.27.112.92 `
-Protocol TCP `
-RemotePort 443 `
-Profile Any
この方法は「原因特定の補助」には使えますが、長期運用ではIP変更に追従できず、抜けや巻き込みが起きやすい点に注意してください。
ファイアウォールログで効果を確認する
ルールを入れたら、必ず「止まったか」「別の通信に置き換わったか」「業務影響が出たか」を確認します。Windows Defender ファイアウォールのログを有効にすると、ブロック/許可の痕跡が追いやすくなります。
# 例：ドメインプロファイルでログ出力を有効化（環境に合わせて）
Set-NetFirewallProfile -Profile Domain `
-LogAllowed True `
-LogBlocked True `
-LogFileName "%SystemRoot%\\System32\\LogFiles\\Firewall\\pfirewall.log" `
-LogMaxSizeKilobytes 16384
「IPアドレス遮断」が難しい理由をもう一歩だけ深掘り
AkamaiのようなCDNは、利用者に近いエッジにコンテンツを置き、DNS応答や経路によって最適な拠点へ誘導します。つまり、同じサービスへアクセスしていても、接続先IPが日々変わることがあります。
さらに、CDNのエッジIPは「同居（マルチテナント）」が一般的です。特定の184.*を遮断した結果、Microsoftの更新だけでなく、別の正規サービスまで巻き込む可能性があります。逆に、観測した2つのIPを止めても、別IPに切り替わって通信が続くこともあります。
通信先の正体をより確実に掴む方法
「184.*に繋がっている」から一歩進んで、どのホスト名（ドメイン）に対して通信しているのかが分かると判断が早くなります。すべてのケースで簡単に分かるわけではありませんが、試せる手段を並べます。
逆引き（PTR）を確認する
IPにPTRレコードが設定されていれば、逆引きでヒントが得られます（設定がないことも多いです）。
nslookup 184.26.245.154
TLSのSNIを見てドメインを推測する
443/TCP（HTTPS）でも、TLSの初期ハンドシェイクに含まれるSNI（Server Name Indication）から接続先ドメインが分かる場合があります。Wiresharkなどでキャプチャし、Client HelloのSNIを確認します。環境によっては暗号化拡張（ECH）で見えにくい場合もありますが、サーバー用途ではまだSNIが見えることが多いです。
ETW/トレースで発生源を固める
原因プロセスが曖昧な場合は、netsh traceで短時間だけトレースを取り、どのプロセスがどのタイミングで外向き通信を起こしたかを突き止めます。解析は手間がかかるため、まずはPID特定→svchostのサービス特定まで進めてから使うのがおすすめです。
どうしても「外向き通信ゼロ」が必要なサーバーの設計
監査要件や閉域網の方針で、サーバーからインターネットへ一切出したくないことがあります。その場合は「遮断する」だけではなく、代替ルートを用意して運用が回るようにするのが現実解です。
| 機能 | 外向き通信が必要になりやすい理由 | 代替案 |
|---|---|---|
| Windows Update | セキュリティ更新の取得 | WSUS、オフラインカタログ、管理端末で取得して配布 |
| Defender定義更新 | 新しいマルウェアに追随 | WSUS、定義ファイルの社内配布、スケジュール配布 |
| 証明書（CRL/OCSP） | TLS接続の信頼性維持 | 社内PKI、失効情報の配布、アプリ側の設計見直し |
| 時刻同期 | 認証やログ整合性 | 社内NTP、PDCエミュレーター設計 |
不審な通信の可能性があるときのチェックリスト
「Akamaiっぽいから大丈夫」と決め打ちせず、次のチェックで不正プロセスの可能性を潰しておくと安心です。
- プロセスのパスが不自然でないか（Temp配下、ユーザープロファイル直下、ランダム名などは要注意）
- デジタル署名が正しいか（Process Explorerで確認）
- 同じPIDが異常に大量の宛先へ接続していないか
- タスクスケジューラ、サービス、Runキーなどに見覚えのない永続化がないか
- サーバー上で突然の高負荷、未知のユーザー、管理共有への不審アクセスなど、他の兆候がないか
Sysmonでネットワーク接続をログ化する
原因がつかみにくい場合、Sysinternals Sysmonを導入し、ネットワーク接続（イベントID 3）をログとして残すと、後追いが簡単になります。導入ポリシーやログ量の設計が必要なので、本番では保存期間・転送先（SIEM等）もあわせて検討してください。
トラブルシューティング：止めたら何が起きる？
送信ブロックは強力ですが、意図せず副作用が出ます。代表的な症状と見直しポイントをまとめます。
| 症状 | 起きがちな原因 | 確認ポイント | 対処の方向性 |
|---|---|---|---|
| Windows Updateが失敗する | wuauserv/BITSの送信遮断、WSUS未設定 | WindowsUpdate.log、イベントログ | WSUS設定、必要通信の許可、適用タイミングの見直し |
| Defenderの定義が古いまま | Defender更新通信の遮断 | 定義のバージョン、更新履歴 | 社内配布へ切替、更新だけ許可するルール設計 |
| 一部HTTPS通信が遅い/失敗 | CRL/OCSP到達不可、証明書検証がタイムアウト | アプリのログ、証明書検証設定 | 失効情報の配布、検証経路の設計、必要宛先の許可 |
| 通信先IPが変わって止まらない | CDNのエッジ切替、別IPへフェイルオーバー | 最新の接続先一覧 | IPではなく原因プロセス/機能に対処する |
現場向け：最短で原因を突き止めて止める手順
最後に、調査から対策までの「迷わない流れ」を1つにまとめます。時間がないときはこの順番で進めると、遠回りしにくくなります。
- netstat / Get-NetTCPConnection で 184.*:443 のPIDを取る
- tasklist / Get-Process でプロセス名・パスを確認する
- svchost.exeなら tasklist /svc でサービス名まで落とす
- そのサービス/機能が正規か（Windows Update、Defender等）を判断する
- 正規なら「代替運用（WSUS/プロキシ）」を検討し、可能ならそちらへ寄せる
- どうしても止めるなら、アプリ/サービス単位で送信規則を作り、段階的に適用する
- ファイアウォールログと業務影響を確認し、ルールを最小化・文書化する
まとめ：Akamai（184.*）を止めたいときの最適解は「原因の特定」と「影響最小の制御」
- 184.*はAkamai系であることが多く、通信自体は通常動作の可能性が高い
- 一律遮断ではなく、まずPID/プロセス/サービスを特定して原因を確定させる
- 更新や定義の取得は、WSUSや社内経路へ寄せると安全に外向き通信を減らせる
- 止めるなら、Windows Defender ファイアウォールでアプリ/サービス単位の送信規則が現実的
- IPブロックは短期検証向け。長期運用は「抜け」と「巻き込み」を前提に設計が必要
コメント