エグレスフィルタリングとは？マルウェアC2通信を防ぐネットワーク出口制御の実践設計

「ファイアウォールは設定済み。不正なアクセスはきちんと弾いている。それでも、感染したマルウェアが社内から外部のC2サーバーと通信し、データを送り続けているとしたら？」

多くの企業が見落としているのが、「内から外へ」向かうアウトバウンド通信の制御です。インバウンドの守りを固めるだけでは、侵入後のマルウェアが外部と自由に通信できてしまいます。

この記事では、エグレスフィルタリング（アウトバウンドフィルタリング）の仕組みと必要性、nftablesやSquidプロキシを使った実践的な設定例、DNSフィルタリングとの組み合わせ方まで、中小企業の情シス担当者でも今日から実装できるレベルで解説します。

エグレスフィルタリングとは？

エグレスフィルタリング（Egress Filtering）とは、ネットワーク内から外部インターネットへ向かうアウトバウンド通信を制御・フィルタリングする技術です。「エグレス（egress）」は「出口」を意味する英語で、「出口側のフィルタリング」と直訳できます。

一般的なファイアウォール設定は、インターネットから社内ネットワークへの「インバウンド（内向き）」の不正な通信を弾くことに主眼を置いています。しかしエグレスフィルタリングはその逆——「内から外への」通信を制御します。

なぜアウトバウンド制御が重要なのか？

マルウェアは感染後、外部のC2サーバー（Command and Control Server＝攻撃者がマルウェアを遠隔制御するサーバー）と通信して以下のような活動を行います。

・命令の受信: 「次の標的を攻撃せよ」「データを送信せよ」などの指示を受け取る
・データ漏洩: 窃取した認証情報・機密ファイルを外部に送信する
・追加モジュールのダウンロード: 別の悪意あるツールを外部から引き込む
・横展開のための通信: 感染を社内の他端末へ広げるための通信を行う

エグレスフィルタリングが機能していれば、これらの「外への通信」を遮断または検知できます。万が一侵入されても、被害の拡大を食い止める「第二の防御線」として機能するのです。

攻撃者はアウトバウンド通信をどう悪用するのか

防御を設計する前に、攻撃者がどのようにアウトバウンド制御をかわそうとするかを知っておきましょう。

1. 正規ポートを隠れ蓑にする

C2通信の多くは、HTTPSの443番ポートやHTTPの80番ポートを使います。これらは業務上必要な通信なので、単純にポートを塞ぐことはできません。攻撃者はこの事情を熟知しており、正規の業務通信に紛れ込ませます。単純な「ポート番号での許可・拒否」では対応しきれないことを前提に設計することが重要です。

2. DNSを悪用したデータ漏洩（DNSトンネリング）

DNS（ポート53）は多くのファイアウォールで許可されています。攻撃者はDNSクエリの中にデータを埋め込んで外部に送り出す「DNSトンネリング」という手口を使います。53番ポートを単純に開けたままにすると、この通信を見逃してしまいます。

3. 信頼されたクラウドサービスを踏み台にする

GitHub・Dropbox・Google ドキュメントなど、誰もが知る信頼性の高いクラウドサービスをC2通信の経由地として使う手口があります。これらのドメインをファイアウォールのホワイトリストに入れていると、気づかず通過させてしまいます。

エグレスフィルタリングの具体的な実装手順

1. 「許可する通信」を明確にする（ホワイトリスト設計）

エグレスフィルタリングの基本は「デフォルト拒否（Default Deny）」です。業務上必要な通信だけをリストアップしてホワイトリストに登録し、それ以外はすべて遮断します。

まずは社内でどんな外部サービスへの通信が必要かを棚卸しします。

・業務Webアクセス: 80/TCP・443/TCP（可能ならプロキシ経由に統一）
・メール送受信: 587/TCP（SMTP Submission）・993/TCP（IMAPS）
・DNS名前解決: 53/UDP・53/TCP（社内DNSサーバー宛のみ）
・クラウドバックアップ: 443/TCP（サービスのIPレンジのみ）
・VPN接続: 500/UDP・4500/UDP（IPsec）・1194/UDP（OpenVPN等）
・NTP時刻同期: 123/UDP（社内NTPサーバー宛のみ）

これ以外のポートや宛先への通信は、原則として遮断します。

2. nftablesでアウトバウンドルールを設定する

Linuxサーバーでのエグレスフィルタリングの設定例です。nftablesを使った基本的なアウトバウンド制御を示します。

# nftablesによるエグレスフィルタリング基本設定
# /etc/nftables.conf に追記または編集

table inet filter {
  chain output {
    type filter hook output priority 0;
    # デフォルト拒否が重要：明示許可以外はすべて遮断
    policy drop;

    # ループバック通信は許可
    oif lo accept

    # 確立済み・関連する通信は許可
    ct state established,related accept

    # DNS（社内DNSサーバー 192.168.1.1 のみ許可）
    ip daddr 192.168.1.1 udp dport 53 accept
    ip daddr 192.168.1.1 tcp dport 53 accept

    # HTTP・HTTPS（プロキシサーバー 192.168.1.10 のみ許可）
    ip daddr 192.168.1.10 tcp dport {80, 443} accept

    # NTP時刻同期（社内NTPサーバーへのみ）
    ip daddr 192.168.1.1 udp dport 123 accept

    # SMTP Submission（メールサーバーへのみ）
    ip daddr 192.168.1.5 tcp dport 587 accept

    # 拒否した通信をログに記録（調査用）
    log prefix "[EGRESS BLOCK] " limit rate 5/minute burst 10 packets
    drop
  }
}

重要なのは `policy drop` の宣言です。これにより、明示的に `accept` していない通信はすべて遮断されます。最初は `log` だけして遮断しない「モニタリングモード」で1～2週間動かし、業務に必要な通信を確認してから `drop` を有効にするのが安全な進め方です。

3. プロキシサーバーでWebアクセスを集約制御する

端末のHTTP/HTTPS通信を直接インターネットに出さず、Squidなどのフォワードプロキシを経由させることで、通信ログの一元管理と細かいアクセス制御が可能になります。フォワードプロキシの仕組みと設定方法については別記事で詳しく解説しています。

# Squidプロキシの基本的なアクセス制限
# /etc/squid/squid.conf の設定例

# 許可するドメインリストを外部ファイルで管理
acl allowed_domains dstdomain "/etc/squid/allowed_domains.txt"
acl localnet src 192.168.0.0/16

# 許可リストに含まれるドメインへのアクセスのみ許可
http_access allow localnet allowed_domains
http_access deny all

# 許可ドメインリスト例（/etc/squid/allowed_domains.txt）
# .microsoft.com
# .google.com
# .github.com
# .example-erp.com   ← 業務システム等

端末のnftablesで443/80番ポートへの直接アウトバウンドを遮断し、プロキシポート（3128番等）への通信だけを許可することで、すべてのWebトラフィックをプロキシ経由に強制できます。

4. DNSフィルタリングと組み合わせて多層防御を実現する

アウトバウンドポートの制御と並行して、DNS解決の段階で悪意あるドメインをブロックするDNSフィルタリングを組み合わせると、より強固な防御になります。

社内からのDNSクエリをすべて社内DNSサーバーに向けることで、マルウェアが外部の悪意あるDNSサーバーに直接クエリを送ることを防げます。

# 外部DNSへの直接通信を遮断するnftablesルール
# outputチェーンの許可ルール群の後、dropの直前に追加

# 外部DNSへの直接クエリを遮断（Google DNS 8.8.8.8等への直接通信を防ぐ）
udp dport 53 log prefix "[DNS BYPASS BLOCK] " drop
tcp dport 53 log prefix "[DNS BYPASS BLOCK] " drop

[BYPASS BLOCK]のログが頻発している場合、端末がハードコードされた外部DNSに直接クエリを送ろうとしている可能性があり、マルウェア感染の兆候として調査が必要です。

また、サーバーのネットワーク設定全般については、姉妹サイトLinuxMaster.JPでも詳しく解説しています。

中小企業でも今日からできること

フルのエグレスフィルタリング実装には準備が必要です。段階的に取り組みましょう。

・ステップ1（今週中）——現在の通信を把握する: NetFlow・IPFIXなどのトラフィック可視化ツールで社内から外部に向かっている通信を確認し、「業務上必要な通信」と「正体不明の通信」を分類します。

・ステップ2（来月中）——危険なポートから遮断を始める: 社内ルーターやUTMでアウトバウンドポリシーが設定されていない場合、使用頻度の低い危険なポート（Telnet:23、FTP:21、TFTP:69、NetBIOS:137～139など）から遮断を始めます。業務に影響が少ない範囲から着手するのがポイントです。

・ステップ3（3か月以内）——DNSフィルタリングサービスを採用する: Cisco Umbrella、Cloudflare Gatewayなどのクラウド型DNSフィルタリングサービスを使えば、プロキシサーバーを自前で立てなくてもDNSレベルで悪意あるサイトへのアクセスを遮断できます。設定変更のみで導入でき、コストも比較的小さく済みます。

・ステップ4（継続）——アウトバウンドDENYログを定期確認する: ファイアウォールのアウトバウンドDENYログを週次で確認します。通常業務では発生しないポートへの通信が記録されていたら、マルウェア感染の可能性として即座に調査します。

よくある誤解と注意点

【注意1】「HTTPSだから安全」と思い込まない

HTTPS通信が暗号化されているのは中身の話です。「どのドメイン・IPアドレスに接続しているか」はネットワーク上から観察できます。TLSハンドシェイク時のSNI（Server Name Indication）を見れば宛先ドメインが分かるため、宛先ベースのフィルタリングは有効です。さらに踏み込むなら、SSLインスペクション（TLSインスペクション）で中身まで検査できますが、プライバシーポリシーの整備と従業員への説明が必要です。

【注意2】ルール適用前に業務影響を必ず確認する

エグレスフィルタリングを厳しく設定しすぎると、正規の業務通信まで遮断してしまいます。まず「ログに記録するが遮断しない」モードで1～2週間様子を見て、業務に必要な通信を洗い出してからルールを適用するのが安全です。特にSaaS型のERPや在庫管理システムは予想外のポートや宛先に通信することがあるため、事前確認が重要です。

【注意3】ボットネットはP2P通信も使う

高度なボットネットの中には、特定のC2サーバーへの通信ではなく、感染端末同士がP2P（ピアツーピア）で通信する設計をとるものがあります。この場合、特定IPのブロックだけでは対処しきれません。振る舞いベースの検知（EDR・NDR）も組み合わせる多層防御が必要です。ボットネットとC2通信の仕組みについても合わせて確認しておくとよいでしょう。

【注意4】クラウドサービスのIPレンジは広大

AWSやAzureのIPレンジは広大で、正規のクラウドサービスへの通信と悪意ある通信が同じIPレンジに混在することがあります。IPアドレスだけでなく、FQDN（完全修飾ドメイン名）ベースのフィルタリングを組み合わせること、またCloudflare Gatewayのようなカテゴリベースのフィルタリングも検討してください。

本記事のまとめ

エグレスフィルタリングの要点を整理します。

「内から外への通信を制御する」という視点は、ゼロトラストセキュリティの考え方そのものです。攻撃者がすでに侵入していることを前提に、「いかに被害を封じ込めるか」というアプローチが現代のセキュリティには欠かせません。インバウンドの防御に加えて、エグレスフィルタリングで出口を塞ぐ——この両輪で、マルウェアが侵入しても被害を最小化できる体制を整えましょう。