セキュリティベンダーはLog4j脆弱性攻撃にどう対応したか 舞台裏からゼロデイ攻撃対策を再考する：「見えないWeb攻撃」──情報漏えい対策の盲点（2/2 ページ）

[中西一博，ITmedia]

　これは一般的には「IPレピュテーション」と呼ばれる仕組みで、高リスクの攻撃元（ソースIPアドレス）からのアクセスを制御する。アカマイでは、世界中のWebサイトに提供しているサービスのログから得たビッグデータを常時解析。過去攻撃に利用された履歴を基に、各IPアドレスに10段階のリスクスコアを与え1時間ごとに更新している。

　この値を参照すれば、例えば「ソースIPのリスクスコアが9以上なら、攻撃に使われている可能性の高いIPアドレスと見なしてWebサイトへのアクセスを一律でブロック」といった対応ができる。

　下記は、後から展開されたWAFルールによってLog4j脆弱性への攻撃（Log4Shell攻撃）を行っていることが分かった、あるIPアドレスのリスクスコアの変化を記録したグラフだ。

Log4Shellゼロデイ攻撃でみるIPレピュテーションの効果

　このIPアドレスはLog4j脆弱性への攻撃を、脆弱性の公開直後から始めた。しかし、過去に別の攻撃をしていたことから、リスクスコアが最高リスク値の10まで上昇していたので、アクセス制御により攻撃を阻止できていたことが分かる。

　この仕組みはWAFの検知ルールに依存せず、新たな脆弱性に対応したルールの更新を待つ必要もない。ほぼリアルタイムで更新される情報に基づき、攻撃の影響を自動的に軽減できることから、すでに国内でも多くのWebサイトが利用している。

　今回のLog4jへの攻撃への対処では、他にもAPIのタイプを自動判定して検知ルールを適用する機能や、決められた型以外のAPIリクエストをブロックする機能、「Bese64多重エンコード」のような手の込んだバイパス攻撃を自動でデコードして検知する機能なども、実際の攻撃に対して効果を発揮した。

　WAFルールの自動更新機能も、休日を前にした対処や、亜種に対応したWAFルールのマイナーなブラッシュアップへの追随、多数のサイトで保護漏れを防ぐうえで効果を示している。

　一方で、従来のWAFの検知ルールでゼロデイ攻撃を阻止できるケースもあった。3月30日に、JavaベースのWebアプリケーションでも広く使われている「Spring Framework」の脆弱性とエクスプロイト（脆弱性実証コード）が明らかになった。

　その直後からアカマイではゼロデイ攻撃の試行を観測している。本エクスプロイトの公開から、脆弱性修正版の公開までタイムラグが生じたが、アカマイWAFでは既存のルール「コマンドインジェクション攻撃用ルール」で検知し、この間に起きたゼロデイ攻撃を阻止できている。

　ただし、この脆弱性攻撃でも亜種を観測しているので、詳しい対応についてはWAFベンダーに確認をとるのがよいだろう。

ゼロデイ攻撃の最前線で得た教訓は？

　ゼロデイ攻撃を完全に防ぐことは原理的には難しい。しかし、防御側の能力も着実に進化している。その中から有効だった能力や運用サービスを見極め、多層的な防御に加えていく試行錯誤が、圧倒的に防御側が不利な戦局をひっくり返せる、唯一無二の戦術だ。

　言うまでもないが、WAFの運用の基本は「検知したらアラートのみ」のモードではなく、Deny化（検知した攻撃のブロック）が前提であることを忘れてはならない。

　今回は、Log4j脆弱性への攻撃を題材に、舞台裏での攻防の一部と実際に効果のあった対策を取り上げてみた。最後に、最前線で攻撃と対峙したアカマイのエンジニアに、今回の攻撃の対応で得た最大の教訓を聞いてみた。

　「大きな攻撃がない時に、正常な状態のサイトの特性を理解し、攻撃を見分けるための準備を用意しておけたか、が重要だった。その備えがあれば、いざというとき、押し寄せる攻撃に対して、十分な余裕をもって戦いに挑むことができる」

　国際情勢が不安定さを増す中、インターネットに面したWebのゼロデイ脆弱性は企業や組織への攻撃の橋頭保（きょうとうほ、敵地へ侵攻するために設ける拠点）を築くために悪用されやすい。

　目に見える大きな攻撃によるノイズが沈静化している時こそが、見えていなかった小さなほころびに目を凝らして、防衛力を高める絶好の機会ではないだろうか。