サービス停止の原因はいろいろあるだろうが、少なくとも原因がはっきりしない場合、サービスの再開は難しい。サイバー攻撃に詳しいラックのサイバーリスク総合研究所で所長を務める西本逸郎氏は「被害の拡大を防止できるか分からないままサービスを再開してしまうのでは、法律的責任はまだないものの、道義的責任が問われる」と指摘する。

ある日突然、オンラインストアに大量のアクセスが

　原因を特定しないままサービス再開に踏み切ると、情報を漏えいさせてしまったり、人に危害を与えてしまうことにつながるからだ。Webサイトを改ざんする攻撃者の狙いは、アクセスしてきた訪問者のパソコンに悪意のあるプログラムを仕込み、訪問者のIDやパスワードを盗み見たり、自分の意のままに訪問者のパソコンを操ることにある。

　あるメーカーではこんな事件に遭遇した。海外の顧客から「オンラインストアにまったくアクセスできない」との問い合わせが入った。さっそく調べてみると、自社で運営する外国向けオンラインストアに対して、まるでDoS攻撃のような大量のアクセスがあることが観測されたのである。奇妙なことに大量のアクセスは丸1日続いて止み、数日経つとまた始まる、ということを繰り返した。

見つけられない攻撃の痕跡

　管理担当者らは懸命に調査してみたのだが、Webサーバーのログにも、IDSのログにもこのタイプの攻撃を裏付ける痕跡を見つけることはできなかった。攻撃に対する明確なログが取れていなかったために、ログのフィルタリングさえできなかった。

　結局、1週間ほどこのWebサイトは閉鎖されることになり、およそ5000万円の損失が出てしまった。管理担当者らは「せめてトラフィックのログだけでも取っておけばよかった」と悔やんだ。

　この会社では、一般に取るべきとされているログは取っていた。サーバー側のsysログはすべて取っていたし、auditログや、Solaris Basic Security Moduleで監査のためのイベントログも取っていた。ファイアウォールやIDSのログも、もちろん取っていた。

原因は「SYNフラッド攻撃」か ?

ラック サイバーリスク総合研究所 西本逸郎氏所長

　残念だったのは、サーバーOSとしてSolarisの古いバージョンを使用しいたために、特定の条件下では特定のログが残らないという、カーネルのバクが存在していたことが災いしたかも知れなかった。管理担当者らは、おそらく「SYNフラッド攻撃」を受けたのではないかと推測している。

　ご存じのように、TCP接続を確立する際、クライアントはまずサーバーに「SYNパケット」を送信し、それを受け取ったサーバーはクライアントに「ACKパケット」を返信する。そして最後にクライアントがサーバーにACKパケットを返信する。このような3度のやり取りを経てTCP接続は確立される。

　「SYNフラッド攻撃」は、3度目のACKパケットをサーバーに故意に送らず、サーバーを待ちぼうけ状態にする。攻撃者は大量のSYNパケットを何度も送りつけ、サーバーをクライアントからの応答待ちでいっぱいの状態にして、サーバーを機能停止に追い込む攻撃として知られている。

　ちなみに、大量のアクセスが発生した過去の類似ケースとしては、証券会社の例があった。デイトトレーディングが盛り上がり始めた頃、証券会社は独自に開発したトレード用ソフトウェアを顧客に配布したが、このツールがサーバーに情報を取得しにアクセスしてきた際にDoS攻撃と同じような状態になったらしい。

　「なったらしい」と断定できないのは、誰がいつツールを使ったというログがなかったために、ツールが原因であると特定することができなかったからである。アクセスが集中し、サーバーに高い負荷がかかり、やがてリソースを食い尽くしてサービス停止に至る。DoS攻撃と同じことだ。

　さて、今回ご紹介したオンラインストアにおけるサービス停止事件だが、実はいまだに問題の解決には至っていない。ロードバランスなど、いろいろと試してみたがうまく回避することはできなかったという。ついに、メーカーの管理担当者らは、根本的な対策を施すことはあきらめ、大量のアクセスが発生した場合、サーバーがパンクしてしまう前にケーブルを抜くという、かなりアナログな対策で回避している。事件の闇は深い。