アウトバウンド通信制御(egress filtering)の設計。侵入後のC2通信と持ち出しの経路を出口で絞る

ファイアウォールの設計では、外から入ってくる通信をどう絞るかに意識が向きがちです。公開するポートを最小にし、管理画面を外に出さないといった入口側の対策は多くの現場で整っています。一方で、社内から外へ出ていく通信は「業務で困らないように」という理由で、既定で全部許可のまま運用されていることが少なくありません。

この記事は、社内ネットワークやサーバー、クラウド環境を預かる運用担当に向けて、出口側の通信制御(egress filtering、アウトバウンド通信制御)を設計手順として整理します。軸に据えるのはMITRE ATT&CKの緩和策M1037(Filter Network Traffic)で、NIST SP 800-41 Rev. 1、CISAを含む6機関の共同ガイダンス、CIS Controls、NSAの暗号化DNSガイダンス、AWSの公式ドキュメントで確認できた内容に沿って書きます。出口制御でも止められない通信があることも、最後に正直に整理します。

外向き通信の既定許可が侵入後の通信を素通りさせる仕組み#

MITRE ATT&CKは、攻撃者の目的を戦術(Tactic)として分類しています。侵入した端末やサーバーを外部から操作する段階がCommand and Control(TA0011、以下C2)、盗んだデータを外部へ送り出す段階がExfiltration(TA0010、持ち出し)です。C2の代表的な手法であるApplication Layer Protocol(T1071)は、Webやメール、DNSといった普段から使われるプロトコルに指令のやり取りを紛れ込ませるものです。DNSの問い合わせと応答にデータを載せる手法はT1071.004として整理されています。

仕組みは単純です。侵入したマルウェアは内側から外へ接続を始めるため、入口のファイアウォールが受信を厳しく絞っていても関係がありません。外向きのTCP 443が全宛先に許可されていれば、指令サーバーへの接続は社員がWebサイトを閲覧する通信と同じ扱いで通過します。サーバーから外への通信が制限されていなければ、データベースサーバーが見知らぬ宛先へ大量のデータを送ることも、ネットワークの設定上は正常な通信になります。

M1037は、この層に当たる緩和策です。MITREはM1037を、ネットワーク機器やエンドポイントのソフトウェアで受信、送信、横方向の通信をフィルタリングする対策として定義しています。

MITRE ATT&CKのM1037(執筆時点でバージョン1.2、最終更新2026年5月12日)は、「Employ network appliances and endpoint software to filter ingress, egress, and lateral network traffic」と説明しています。個別の手法への適用として、T1071(Application Layer Protocol)には送信通信のフィルタリングとプロトコルに基づくフィルタリング、T1048(Exfiltration Over Alternative Protocol)にはプロキシの強制とDNSなどの専用サーバーを置いてそのサーバーだけに該当ポートの通信を許可すること、T1090(Proxy)には許可リストと拒否リストによる匿名化ネットワークやC2基盤への通信遮断が挙げられています。

ATT&CKの戦術と緩和策の読み方は、次の記事で整理しています。

あわせて読みたい

MITRE ATT&CKで攻撃を体系的に理解する。戦術と技術のマトリクスを検知・防御にどう活かすか

出口制御の方針を示す公的ガイダンス#

出口側を既定拒否にするという考え方は、新しいものではありません。NIST SP 800-41 Rev. 1(Guidelines on Firewalls and Firewall Policy、2009年9月)は、ファイアウォールは組織が必要としない通信、つまりファイアウォールポリシーで明示的に許可していない受信と送信の通信をすべて遮断すべきだとし、この方式をdeny by defaultと呼んでいます。明示的に禁止したものだけを止める方式より安全だという理由として、ホストやアプリケーションが常に変化することを挙げています。同文書は送信側のフィルタリングをegress filteringと呼び、外部のFTPサーバーの利用を止める例も示しています。

2024年12月4日には、CISA、NSA、FBI、オーストラリアのASD's ACSC、カナダのCCCS、ニュージーランドのNCSC-NZが共同で「Enhanced Visibility and Hardening Guidance for Communications Infrastructure」を公表しました。通信インフラのネットワーク防御担当と技術者に向けた文書ですが、オンプレミスの企業向け機器を持つ組織にも当てはまる場合があるとしています。受信と送信の通信を制御する厳格な既定拒否のACL戦略を実装すること、拒否したすべての通信をログに残すこと、管理機器からの外向き接続を無効化して横展開を抑えることを推奨しており、企業ネットワークの出口制御を設計する際の参考になります。

CIS Controls v8.1にも関連するSafeguardがあります。4.5はエンドユーザー端末に既定拒否のホストファイアウォールを導入して管理すること、9.2はリモートとオンプレミスを含むすべてのエンドユーザー端末でDNSフィルタリングサービスを使うこと、13.10はアプリケーション層のフィルタリングを行うことを求めています。

さらにさかのぼると、CISAがファイブアイズ各国と2020年9月に出したアドバイザリAA20-245Aは、サーバーからのWebへの送信通信を制限することを推奨し、侵害の痕跡として想定外のDNSリゾルバの利用やDNSを使った持ち出しを挙げています。プロキシのログを保全し、可能ならURIのパラメータまで記録することにも触れています。

ファイアウォールの種類や基本的なルールの考え方は、次の記事にまとめています。

あわせて読みたい

ファイアウォールが通信を許可と拒否で仕分ける仕組み

セグメントごとに出口ポリシーを分ける#

出口制御を全社で一律に設計しようとすると、端末の業務通信の多様さに引きずられて結局は広く許可することになります。通信の性質が似ている単位でセグメントを分け、それぞれに出口ポリシーを持たせる方が現実的です。

この表の前提は、セグメントの境界にファイアウォールなどの制御点があることです。セグメントが分かれていない場合は、出口制御の前にネットワーク分割から着手します。

あわせて読みたい

ネットワークセグメンテーションで侵入後の被害を広げない設計

サーバーセグメントは既定拒否と許可リストで組む#

サーバーは出口制御の効果が最も出やすい場所です。Webサーバーやデータベースサーバーが通信する外部の宛先は、OSやミドルウェアの更新を取得するリポジトリ、決済や認証などの連携先API、監視やバックアップのサービス程度に限られます。この一覧を許可リストにし、それ以外の外向き通信はすべて拒否します。

許可リストを作るときは、次の点を決めておくと運用が安定します。

• 宛先はIPアドレスだけでなく、名前(FQDN)で管理できる仕組みを選びます。更新配信やSaaSの宛先はIPアドレスが頻繁に変わるため、IPアドレスで固定すると更新のたびにルールが壊れます。名前での制御ができないファイアウォールでは、サーバー用の送信プロキシを置き、プロキシ側で宛先の名前を許可する構成が扱いやすくなります
• 各許可ルールに、用途、依頼したシステムの担当者、見直し期限を記録します。理由の分からない許可が残ることが、既定拒否を形骸化させる主な原因です
• DNSとNTPは社内のサーバーだけを宛先として許可し、サーバーから外部のDNSやNTPへ直接出られないようにします
• 管理者がサーバー上で作業のために一時的に外部へ接続する運用は、恒久的な許可にせず、期限付きの例外として扱います

サーバーからの外向き通信を絞ると、Webアプリケーションが外部のURLを取得する機能を悪用されたときの被害も小さくなります。アプリケーション側の対策と組み合わせて考えるテーマです。

あわせて読みたい

SSRFとは何か。サーバーを踏み台にする脆弱性の仕組みと許可リスト方式の防御を解説

端末セグメントはプロキシへ集約して直接の外向き通信を止める#

端末はWeb閲覧やSaaSの利用で宛先が多様なため、サーバーと同じ許可リスト方式は現実的ではありません。端末のWeb通信は社内の送信プロキシ(またはクラウド型のセキュアWebゲートウェイ)に集約し、ファイアウォールでは端末からインターネットへの直接の通信を止めます。こうすると、Web通信の宛先はプロキシのログに1か所で残り、カテゴリや評判による宛先の遮断もプロキシで行えます。

プロキシへの集約とあわせて、端末から外部への直接通信として次のようなものを止めます。

UDP 443はHTTP/3(QUIC)で使われます。Web通信をプロキシに集約する設計では、UDP 443の直接通信も対象に含めて、業務で使うアプリケーションがTCPでの接続に切り替わるかを事前に確かめます。

端末のホストファイアウォールも出口制御に使えます。CIS ControlsのSafeguard 4.5は、明示的に許可したサービスとポート以外の通信を落とす既定拒否のホストファイアウォールを端末に導入するよう求めています。送信方向の規則も管理しておけば、端末が社外のネットワークに出たときにも効く層になります。

DNSを社内リゾルバに固定する理由とDoHの扱い#

DNSは、ほぼすべての通信の前に使われるうえに、ファイアウォールで広く許可されていることが多いプロトコルです。そのため、T1071.004のように問い合わせと応答に指令やデータを載せる手法が成り立ちます。端末やサーバーが外部のリゾルバへ直接問い合わせできる状態では、社内のDNSログに記録が残らず、DNSフィルタリングによる悪性ドメインの遮断も効きません。

そこで、名前解決はすべて社内のリゾルバ(または組織が契約するDNSフィルタリングサービス)を経由させ、それ以外の宛先へのTCP、UDPの53と、DNS over TLSやDNS over QUICが使うTCP、UDPの853を拒否します。社内リゾルバだけが外部の権威サーバーやフォワーダーへ問い合わせる構成にすると、問い合わせのログが1か所に集まり、M1037がT1048の緩和策として挙げる「DNSなどの専用サーバーだけに該当ポートの通信を許可する」形になります。

難しいのは、HTTPSの上でDNSをやり取りするDNS over HTTPS(DoH)です。DoHはTCP 443を使うため、ポート番号では通常のWeb通信と区別できません。NSAが2021年1月に公表した「Adopting Encrypted DNS in Enterprise Environments」は、企業ネットワークでは指定した企業内のリゾルバだけを使い、そのリゾルバは暗号化DNSに対応させたうえで、それ以外の暗号化DNSリゾルバは無効化して遮断するよう推奨しています。実務では次の組み合わせで対応します。

• ブラウザやOSの管理ポリシーで、DoHを無効にするか、社内リゾルバだけを使う設定にします
• 送信プロキシやファイアウォールで、既知の公開DoHリゾルバの宛先を遮断します
• 端末からの直接の443通信を止めてプロキシに集約しておくと、DoHの宛先もプロキシのログで確認できます

公開DoHリゾルバの一覧は完全にはなりえないため、遮断リストだけに頼らず、端末側の設定管理と組み合わせます。DNSの仕組みとDNSを狙う攻撃は、次の記事で扱っています。

あわせて読みたい

DNSの名前解決とその安全性を支える技術

クラウドでは出口制御の部品を置き換える#

クラウドにはオンプレミスの境界ファイアウォールに当たる単一の機器がないため、同じ考え方を別の部品で実現します。AWSを例にすると、Amazon VPCのドキュメントには次の特性が書かれています。

• セキュリティグループを作成すると、受信ルールは空ですが、すべての送信を許可するルールが1つ入っています。このルールを削除して、特定の送信だけを許可するルールに置き換えることができます。送信ルールが1つもなければ、送信通信は許可されません
• セキュリティグループに書けるのは許可ルールだけで、拒否ルールは書けません。宛先にはCIDR、プレフィックスリスト、同じVPC内などの別のセキュリティグループを指定できます
• セキュリティグループでは、VPCに用意されたRoute 53 Resolverへの問い合わせを止められません。このDNS通信をフィルタリングするには、Route 53 Resolver DNS Firewallを使います

この特性を踏まえると、AWSでの出口制御は次の順に組み立てると整理しやすくなります。

1. ワークロードをプライベートサブネットに置き、インターネットへの出口をNATゲートウェイなどの限られた経路に集約します
2. 各セキュリティグループの全送信許可を外し、連携先や更新の取得先に必要な送信だけを許可します
3. 名前での許可が必要な宛先は、出口の経路に置いたマネージドのファイアウォールサービスや送信プロキシで制御します
4. DNSはRoute 53 Resolver DNS Firewallで許可するドメインと遮断するドメインを管理します

AzureやGoogle Cloudにも、ネットワークセキュリティグループやファイアウォールルール、マネージドのファイアウォールサービスがあります。既定で送信がどう扱われるかはサービスごとに違うため、利用しているクラウドの公式ドキュメントで確認してから設計します。どこまでが利用者の責任範囲かは、次の記事で整理しています。

あわせて読みたい

クラウドの責任共有モデルとガバナンス。IaaS/PaaS/SaaSで変わる責任範囲と設定ミスの所在

いきなり遮断せず段階的に絞る導入手順#

既定許可で長く運用してきた環境で急に既定拒否へ切り替えると、更新の取得や外部連携が止まり、業務の障害として出口制御そのものが撤回されがちです。現状の通信をログで把握し、影響を確かめながら絞っていきます。

拒否ログを監視に回す運用#

既定拒否に切り替えた後の拒否ログは、侵害の兆候を拾うための記録になります。CISAほかの共同ガイダンスも、拒否した通信をすべてログに残すよう推奨しています。拒否ログは、設定が効いているかの確認と、不審な通信の検知の両方に使えます。

拒否ログのうち、次のようなものは担当者に通知する対象にすると効果が出やすくなります。

• 既定拒否にしたサーバーから、許可リストにないインターネット上の宛先への接続が繰り返し拒否されている
• 端末やサーバーが、社内リゾルバ以外のDNSサーバーへ直接問い合わせようとしている
• 端末からインターネットへのSMBやRDPの接続が拒否されている
• 深夜など業務時間外に、同じ宛先への拒否が一定間隔で続いている

通知の条件は、導入直後は拒否ログの量が多いため、サーバーセグメントの拒否など意味が明確なものに絞って始めます。プロキシのログやDNSのログと突き合わせられるよう、時刻の同期と保存期間をそろえておきます。ログの集め方と保存の考え方は、次の記事で扱っています。

あわせて読みたい

ログ管理の基本。何を・どこまで・どれだけ残すか

出口制御だけでは止められない通信#

出口制御は、許可していない宛先への通信を止める仕組みです。裏返すと、許可した宛先を使う通信は止められません。設計の段階で、次の限界を関係者と共有しておきます。

• 業務で許可しているクラウドストレージやファイル共有サービスへのアップロードは、正規の利用と同じ宛先と通信になります。MITRE ATT&CKはこの手法をExfiltration to Cloud Storage(T1567.002)として整理しています
• 業務で使うSaaSやコード共有サービスなど、許可した宛先をC2の中継に使われる場合も、宛先による制御では区別できません
• 暗号化された通信の中身は、TLSの検査を行わない限り見えません。TLSの検査を導入する場合は、対象から除外する通信の範囲や、従業員への周知と社内規程での扱いを事前に決めます
• 侵入した攻撃者が端末に標準で入っているツールを使い、許可されたプロキシ経由で通信する場合、ネットワーク上の記録は正規の操作と見分けにくくなります

これらは、テナントの制限などで許可するクラウドサービスを組織のアカウントに限る設定、データの持ち出しを監視する仕組み、エンドポイントでの振る舞いの監視といった別の層で補います。標準ツールを悪用する手口は、次の記事で解説しています。

あわせて読みたい

環境寄生型攻撃(LOLBins)の仕組みと振る舞いで見つける検知設計

出口制御は、一度に完成させる対策ではありません。サーバーセグメントの既定拒否とDNSの固定から始めるだけでも、侵入後の通信が通れる経路は大きく減り、拒否ログという手がかりが残るようになります。記事の内容は執筆時点(2026年9月14日)に確認した各ガイダンスと公式ドキュメントに基づきます。製品やクラウドサービスの設定項目は更新されるため、実際の設計では利用している製品の最新のドキュメントを確認してください。