ICMPのセキュリティリスクと対策｜Ping悪用・ICMPフラッド攻撃・情報漏洩リスクとファイアウォール設定ガイド

「pingを打ったら応答が来た。ただそれだけのことが、攻撃者に組織のネットワーク情報を渡す第一歩になる」——そう言われても、なかなかピンと来ない方も多いのではないでしょうか。

ICMP（Internet Control Message Protocol）は、ネットワークの疎通確認やエラー通知に使われる、インフラエンジニアにとって毎日お世話になるプロトコルです。しかし攻撃者の目線では、ICMPは「偵察ツール」「DoS攻撃の弾薬」「C2通信の隠れ蓑」として悪用できる便利な道具でもあります。

この記事では、ICMPが持つセキュリティリスクの全体像と、iptables・nftables・Linuxカーネルパラメータを使った防御設定を、現場で使えるレベルで解説します。「pingを全遮断すればよい」という誤解を正し、正しいバランスで制御する方法もお伝えします。

ICMPとは？ネットワーク診断ツールが攻撃に使われる理由

ICMP（Internet Control Message Protocol）は、IPプロトコルの補助的な役割を担うネットワーク層のプロトコルです。TCP/UDPとは異なり、アプリケーションデータの転送ではなく「ネットワーク状態の伝達」を目的としています。

代表的な用途は次のとおりです。

・Echo Request / Echo Reply（タイプ8/0）: pingコマンドが使うICMPメッセージ。疎通確認の基本
・Time Exceeded（タイプ11）: tracerouteの経路表示に使われる。TTLが0になったときのエラー通知
・Destination Unreachable（タイプ3）: 宛先に到達できないことをホストに伝える
・Redirect（タイプ5）: より良い経路があるときにホストに経路変更を通知する

ICMPはネットワーク管理に欠かせない一方で、次の2つの理由から攻撃に悪用されやすいという特性があります。

第一に、多くのファイアウォールがICMPを素通ししがちであること。「pingだから大丈夫」という意識が、意図せずICMPフラッド攻撃の通路を作ってしまいます。

第二に、ICMPはヘッダーにデータを運べるということ。本来は使われないデータ部分（ペイロード）に任意のデータを埋め込めるため、暗号化されたC2通信のトンネルとして使われることがあります。

攻撃者はICMPをどう悪用するか

1. ICMPフラッド攻撃（Ping Flood・Smurf攻撃）

最もシンプルなDoS攻撃がICMPフラッドです。大量のEcho Requestを標的サーバーに送りつけ、CPU・帯域幅を枯渇させます。

特に問題になるのが「Smurf攻撃」と呼ばれる増幅型の手法です。送信元IPアドレスを標的のIPに偽装したEcho Requestを、ネットワークのブロードキャストアドレス宛に送ります。ブロードキャストアドレスを持つすべてのホストが一斉に標的に返答するため、一人の攻撃者が数百倍の増幅攻撃を実現できます。

Smurf攻撃はRFC 2644でブロードキャスト転送が禁止されて以降、現代のネットワークでは実行しにくくなりましたが、内部ネットワークの古いルーター設定が残っている環境では今でも成立しえます。

2. ネットワーク偵察（Ping Sweep・OSフィンガープリンティング）

攻撃者が最初に行う作業のひとつが「生きているホストの特定」です。Ping Sweepは、IPアドレスの範囲に対してICMP Echo Requestを送り、応答したホストを抽出する技術で、Nmapなどのツールで自動化できます。

さらに、ICMP応答の「TTL値」や「IDフィールドの生成パターン」からOSを推測できます。たとえばLinuxは初期TTLが64、Windowsは128という傾向があります。こうした情報は次の攻撃フェーズを設計するための材料になります。

3. ICMPトンネリング（C2通信の隠蔽）

ICMPパケットのデータ部分（ペイロード）に暗号化されたコマンドを埋め込み、正規のping通信に見せかけてC2（Command and Control）サーバーとやり取りする手法です。

一般的なファイアウォールがTCP/UDPの通信制御に集中している環境では、ICMPトンネリングは検知を逃れやすい。類似の手法にDNSトンネリングがあります（DNSトンネリングについてはこちらで詳しく解説しています）。

4. ICMPリダイレクト攻撃（経路操作）

ICMP Redirect（タイプ5）メッセージは、「このIPアドレス宛はあのルーターを使え」とホストに経路変更を伝えます。悪意ある第三者がこのメッセージを偽造・送信すると、標的ホストのルーティングテーブルを書き換えられます。

その結果、通信が意図しない中間ホスト（攻撃者の制御下にある機器）を経由するようになり、中間者攻撃（MITM）の足がかりとなります。Linuxは`/proc/sys/net`のパラメータでICMPリダイレクトの受け入れを制御できます。

具体的な防御手順

1. iptablesでICMPを適切に制御する

ICMPを完全に遮断するのは「やりすぎ」です。pingは障害調査やMTU Discovery（パケット断片化の最適化）に必要なメッセージを含むため、全カットすると逆にネットワーク問題の原因になります。目的は「必要なICMPタイプは許可し、不要なものを制限する」ことです。

# 外部からのICMP Echo Request（ping着信）をレート制限する
# 1秒あたり最大3パケット（burst 5）を許可。それ以上はDROP
iptables -A INPUT -p icmp --icmp-type echo-request \
  -m limit --limit 3/second --limit-burst 5 -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -j DROP

# Destination Unreachable / Time Exceeded は必ず許可（MTU Discovery等に必要）
iptables -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
iptables -A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT

# ICMPリダイレクトの着信を破棄（経路操作を防ぐ）
iptables -A INPUT -p icmp --icmp-type redirect -j DROP

# 設定を保存する（CentOS/RHEL系）
service iptables save

上記の設定はあくまでサーバー1台の例です。組織のファイアウォール（UTM・NGFW）で同等の設定を行い、エッジで制御するのが基本です。

2. nftablesでのICMP制御

最近のLinuxディストリビューションではiptablesの後継であるnftablesが標準化されています。同等の制御をnftablesで行う場合の設定例を示します。

# /etc/nftables.conf の table inet filter 内に追記する例
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;

    # 確立済みセッションは許可
    ct state established,related accept

    # ICMP Echo Request：レート制限付きで許可
    ip protocol icmp icmp type echo-request limit rate 3/second burst 5 packets accept
    ip protocol icmp icmp type echo-request drop

    # MTU Discovery / traceroute に必要なICMPタイプを許可
    ip protocol icmp icmp type { destination-unreachable, time-exceeded } accept

    # ICMPv6 は必要なものだけ許可（IPv6環境）
    ip6 nexthdr icmpv6 icmpv6 type {
      nd-neighbor-solicit, nd-neighbor-advert,
      nd-router-solicit, nd-router-advert
    } accept

    # ICMPリダイレクトは拒否
    ip protocol icmp icmp type redirect drop
  }
}

3. カーネルパラメータで追加防御する

iptables/nftablesの設定に加えて、Linuxカーネルパラメータでも多重の防御層を設けることができます。

# /etc/sysctl.conf または /etc/sysctl.d/99-icmp-security.conf に追記

# ICMPリダイレクトの受け入れを無効化（経路書き換え攻撃の防止）
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.default.accept_redirects = 0

# ICMPリダイレクトの送信を無効化（サーバーがルーターの役割を持たない場合）
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0

# セキュアなICMPリダイレクト（デフォルト経路の変更のみ受け入れる設定）も無効に
net.ipv4.conf.all.secure_redirects = 0
net.ipv4.conf.default.secure_redirects = 0

# ブロードキャストへのEcho Requestに応答しない（Smurf攻撃の踏み台にならない）
net.ipv4.icmp_echo_ignore_broadcasts = 1

# 不正なICMPエラーメッセージを無視する
net.ipv4.icmp_ignore_bogus_error_responses = 1

# 設定を即時反映
sysctl -p

これらのカーネルパラメータはサーバーをSmurf攻撃の踏み台として使われるリスクを低減し、偽造されたICMPリダイレクトによる経路操作を防ぐ効果があります。

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

「iptablesの設定まで手が回らない」という方でも、次の3つの対策はすぐに着手できます。

・外部公開サーバーのpingをレート制限する: クラウド（AWS・Azure・GCP）のセキュリティグループ・NSGでICMPのレート制限または発信元IPを絞るルールを追加する。マネジメントコンソールから数分で設定できる
・sysctl設定の適用: 上記の`/etc/sysctl.conf`設定を書き加えて`sysctl -p`で反映する。1～2分で完了し、再起動後も設定が保持される
・境界ファイアウォール（UTM）でのICMP制御を確認する: UTM・NGFWのポリシーを開き、外部からのICMP全許可になっていないか確認する。多くの製品にICMPレート制限の機能がある
・社内のping sweep検知をSIEMやログ監視に加える: 短時間に多数のIPからEcho Requestが届いている場合はスキャン活動の可能性がある。ルーターやファイアウォールのログから定期的に確認する

よくある誤解と注意点

【注意1】「ICMPをすべて遮断すれば安全」は誤り

ICMPを全ブロックすると、次のような実害が発生します。

・MTU Discovery（Path MTU Discovery）が機能しなくなり、大きなパケットが分断されずに通信が途絶えるケースがある
・tracerouteが機能せず、ネットワーク障害の切り分けが困難になる
・Destination Unreachableが届かないことで、接続タイムアウトまで無駄な再送が続きアプリケーションのレスポンスが悪化する

正しいアプローチは「全遮断」ではなく「必要なタイプを許可し、不要・過剰なものを制限する」です。

【注意2】ICMPv6を遮断してはならない

IPv6環境ではICMPv6は単なる診断ツールではなく、近隣探索プロトコル（NDP）として機能します。ICMPv6の`nd-neighbor-solicit`（タイプ135）や`nd-router-advert`（タイプ134）を遮断すると、IPv6通信が全面的に機能しなくなります。IPv6を使っている環境では、ICMPv6の必要タイプを丁寧に許可する設定が不可欠です。

【注意3】ICMPトンネリング検知はシグネチャだけでは難しい

ICMPトンネリングを行うマルウェアは、通常のICMP応答と見かけ上の差がほとんどありません。検知のヒントは「ICMPペイロードのサイズが異常に大きい」「同一ホストとの連続したICMP応答が続く」「ペイロードにランダムバイト列が続く」といったパターンです。SYNフラッドなどのネットワーク層攻撃と合わせて、ネットワーク通信の異常量やパターンをNetFlow・パケットキャプチャで継続的に把握する体制が重要です。

本記事のまとめ

ICMPのセキュリティリスクと対策をまとめます。

ICMPは「全遮断」ではなく「制御」がキーワードです。必要なメッセージタイプを許可しながら、過剰なトラフィックと危険なタイプだけを制限する。この考え方は、ネットワーク全体のセキュリティ設計にも通じる原則です。

Linuxサーバーのネットワーク設定については、姉妹サイトLinuxMaster.JPでも関連する実践的な情報を掲載しています。あわせてご参照ください。