IDSの取りこぼしを防ぐ動的サンプリング研究XNET

ネットワーク監視の現場には、あまり語られない前提があります。IDS（侵入検知システム）は、流れてくるパケットを全部は見ていないということです。回線速度が装置の処理能力を超えると、パケットは静かに捨てられます。しかもその捨て方はランダムなので、通信量が少ないもの——つまりマルウェアのC2（指令）通信のような、いちばん見つけたいもの——ほど消えてなくなります。

2026年8月18日にarXivで公開された論文「XNET」は、この問題に正面から取り組んだ研究です。LinuxのXDPという仕組みを使い、「セキュリティ上の価値」に応じてパケットの残し方を変える動的サンプリングにより、実ネットワークでトラフィックを最大84%削減しながらパケットロスゼロ、IDSの検知率99.6%を報告しています。なお本論文は査読前のプレプリントであり、結果は今後変わりうる点を最初にお断りしておきます。

この記事でわかること

  • 高速回線でIDSが「取りこぼす」仕組みと、それがなぜ危険なのか
  • XNETが提案する動的サンプリングの考え方と、報告された数値
  • 自社のIDS/NDRが実際に何%落としているかを今日確認する方法
  • この研究の限界と、鵜呑みにしてはいけない点

そもそも「サンプリング」「XDP」とは何か

サンプリングとは、流れる通信を全部記録せず、一部だけを抜き取って観測することです。NetFlowやsFlowで「1/1000サンプリング」といった設定を見たことがある方も多いはずです。全量を処理する計算資源もストレージも足りないため、間引くこと自体は現実的な選択です。問題はその間引き方にあります。

XDP（eXpress Data Path）とは、Linuxカーネルのネットワークドライバ直後——通常のネットワークスタックに入る手前——でパケットを高速処理する仕組みです。Linuxカーネルに標準で組み込まれている機能で、専用の高価なハードウェアを買わずに、汎用サーバで高速なパケット処理を実現する手段として使われます。XNETはこのXDPを土台にしています。「特別な装置を買わなくても、手元のLinuxサーバでできる」という点が、この研究の実務的な意味の半分を占めています。

どんな研究か

ひとことで言えば、「セキュリティ的に価値の高い通信を優先して残し、価値の低い通信を大胆に間引くことで、監視装置に流し込む量を減らしつつ見逃しを減らす」という研究です。従来の確率的サンプリング（どのパケットも等確率で抜き取る）が、量の多い通信を厚く、量の少ない通信を薄くしか観測できないのに対し、XNETはパケットをXDPの層で分類し、設定したポリシーに沿ってサンプリング率を変えます。

著者らは実際の大規模ネットワークに汎用ハードウェアのみで導入し、次の結果を報告しています。

観点 報告された結果
トラフィック削減率 最大84%削減
パケットロス ゼロ（no packet loss）
低レート通信の可視性 約5倍に向上
スケーラビリティ ストレステストで100Gbpsまで確認
IDS適用時の検知率 99.6%
使用ハードウェア 汎用（commodity）機器のみ

なぜ低レートのC2通信ほど見逃されるのですか？

ランダムに間引くと、もともと少ない通信は「1本も残らない」確率が高くなるからです。たとえば1/1000サンプリングの環境で、1日に数十パケットしか出さない静かなC2通信があったとします。統計上、そのセッションはまるごと観測から消えます。一方、大量に流れるバックアップ通信や動画配信は、間引かれてもなお十分な量が残ります。結果として、監視ログには「見なくてよいもの」が濃く、「見たいもの」が薄く残る——これが論文の指摘する構図です。APT（標的型攻撃）の常套手段が「目立たない少量の通信」であることを考えると、この歪みは軽視できません。

自社のIDS/NDRは、いま何%落としているか

この論文を読んで最初にやるべきことは、製品の検討ではありません。手元の監視装置が実際にどれだけ取りこぼしているかを数字で確認することです。多くの現場で、この数字は一度も見られないまま運用されています。代表的な確認箇所を挙げます。

製品・箇所 見るもの 意味
Suricata stats.log の capture.kernel_drops と capture.kernel_packets ユーザ空間に渡された数と、渡されずに捨てられた数。既定では8秒間隔で出力される
Suricata tcp.reassembly_gap（TCPデータギャップ） TCPストリームの欠落。理想は0。ただしパケットロス以外（チェックサム不正・ストリームエンジンのメモリ枯渇）でも増える
Zeek capture_loss.log の percent_lost TCPシーケンス番号のギャップから推定した損失率。「0.41」は0.41%であって41%ではない（読み違えが多い）
NIC / OS 受信ドロップカウンタ（ethtool -S 等） カーネルより手前、ハードウェア側での取りこぼし。Suricataのcapture.kernel_dropsだけを見ていると気づけない
スイッチ ミラー（SPAN）ポートの送信ドロップ ミラー元の合計帯域がミラー先ポートの速度を超えると、スイッチ側で捨てられる。監視装置のログには一切残らない

とくに最後のミラーポートは盲点です。1Gbpsのポート複数本を1Gbpsのミラー先に集約している構成は珍しくありませんが、同時に混み合えば物理的に入りきりません。IDSのダッシュボードが平穏なのは、平穏だからではなく、混雑した時間帯のパケットが届いていないから——という可能性を、一度は疑う価値があります。

現場目線の所感

正直なところ、IDSやNDRは「導入したこと」が成果として扱われやすく、導入後に「ちゃんと見えているか」を測る文化が根づいている組織は多くありません。アラートが出れば対応するし、出なければ平和だと思う。限られた人員でSOC運用まで手が回らない現場では、無理もない話です。

しかし、この研究が突きつけているのは「検知ロジックの良し悪し以前に、そもそも入力データが欠けている」という、もっと手前の問題です。どれだけ優秀な検知エンジンを導入しても、パケットが届いていなければ検知率はゼロです。ドロップ率の定点観測は、新しい製品を買うより先にできて、しかも費用がかからない改善だと感じます。閑散期と繁忙期、業務時間帯と夜間バッチの時間帯で数字を比べるだけでも、「見えていない時間帯」が浮かび上がることがあります。

限界と、鵜呑みにしてはいけない点

  • 査読前のプレプリントです。第三者による検証を経ていないため、報告値をそのまま製品比較の根拠にはできません。
  • 84%削減・検知率99.6%は「著者らが導入した特定のネットワークでの結果」です。トラフィックの構成が違えば数字は変わります。自社に当てはめて期待値を語るのは危険です。
  • 成否はポリシー設計に依存します。「何をセキュリティ価値が高い通信とみなすか」を人間が定義する以上、その定義から漏れた通信は今度は意図的に薄くなります。攻撃者が「価値が低い」と分類される通信に紛れる可能性も、当然に考える必要があります。
  • 暗号化された通信の中身は見えません。これはXNETに限らずネットワーク監視全般の制約で、エンドポイント側の監視（EDR等）と組み合わせる前提は変わりません。

情シスとしてどう動くか

研究の内容そのものは、すぐに導入判断をする類のものではありません。持ち帰るべきは「監視の入力が欠けていないかを測る」という運用の観点です。そのうえで、ログをどう集め、何を見るかについては、自前でチェックリストを作るより公的機関の指針に沿うのが確実です。

関連記事

まとめ

  1. 高速回線でのランダムなサンプリングは、量の少ない通信を優先的に消す。C2通信のような「いちばん見つけたいもの」ほど観測から漏れやすいという、構造的な歪みがある。
  2. XNETはXDPを使った動的サンプリングで、汎用機器のみで最大84%のトラフィック削減とIDS検知率99.6%を報告した（査読前のプレプリント。数値は特定環境での結果であり一般化はできない）。
  3. 今日できるのは、自社のドロップ率を数字で確認すること。Suricataのcapture.kernel_drops、Zeekのpercent_lost、そしてスイッチのミラーポートのドロップまで見る。監視装置のログに残らない取りこぼしが最も危ない。

出典

タイトルとURLをコピーしました