“縁”を感じた北海道
皆さんこんにちは、川口です。
2009年6月下旬に北海道出張に行ってきました。4月にせきゅぽろに参加して、わずか2カ月で北海道に再上陸することになりました。今回は人の縁を感じる出張となりました。せきゅぽろでお会いしたサイバートラストの志賀さんやせきゅぽろの蒲田さんとの再会、会社の元先輩との再会もありました。特に先輩には在職中に大変お世話になっていたこともあり、1年ぶりにお会いした今回の出会いには、思わずテンションが上がってしまいました。お元気なようで安心しました。たくさんの方にお会いできる縁をこれからも大切にしたいと思った北海道出張でした。
DoS攻撃に悩まされる
北海道出張から帰ってきて落ち着く暇もなく、Apacheの脆弱性への攻撃に続き、アメリカと韓国へのDDoS/DoS攻撃に振り回されています。
【関連記事】
Apacheに新たな脆弱性発見 - スラッシュドット・ジャパン
http://slashdot.jp/security/09/06/23/0455215.shtml
米韓へのDDoS攻撃、発信源は国内にも
http://www.atmarkit.co.jp/news/200907/10/ddos.html
米韓の政府系サイトなどにDDoS攻撃が発生
http://www.itmedia.co.jp/news/articles/0907/09/news014.html
米韓へのDoS攻撃はありふれた手口、都合のいい解決策は見当たらず
http://www.itmedia.co.jp/enterprise/articles/0907/10/news019.html
これらの攻撃は同じように「DoS攻撃」と表現されますが、それぞれ手法が異なります。Apacheの場合は「ソフトウェアの脆弱性」を狙って「特殊な攻撃リクエスト」を送るのに対し、アメリカと韓国への攻撃の場合は「リソース」を狙って「通常のリクエスト」を送ります。
このように攻撃手法や攻撃の対象は異なりますが、セキュリティ対策製品のカタログでは、どちらも同じ「DoS攻撃」と表記されているため、カタログを確認する際には注意が必要です。カタログ確認の際には「○×表の真実:『検知できる』ってどういうこと?」を参考にしてください。
さて、今回はリソースの消費を狙ったDoS攻撃についてのお話です。なお、複数のマシンから行われるDDoS攻撃という攻撃もありますが、攻撃を行うパソコンの数の違いを表現しただけであるため、今回のコラムに限ってはDoS攻撃に含めさせていただきます。
攻撃者はDoS攻撃によって、システムのリソース全体を狙ってきます。システムはルータ、スイッチ、ファイアウォール、Webサーバなどが攻撃対象となります。そしてこれらのCPU、メモリ、セッション数などのリソースを大量のアクセスによって枯渇させます。DoS攻撃は古典的な手法であるにもかかわらず、防ぐことが非常に難しい攻撃です。正確にいうと「正常なサービスに影響を与えずに」攻撃を防ぐことが難しい攻撃です。
DoS攻撃の検知
DoS攻撃を防ぐためにはまずDoS攻撃が発生していることを検知できなければなりません。@ITのセキュリティ用語辞典には、DoS攻撃とは
サービス妨害攻撃またはサービス不能攻撃などと呼ばれる、インターネット経由での不正アクセスの1つ。大量のデータや不正パケットを送りつけるなどの不正な攻撃を指す。
であると記載してあります。ポイントは「大量のデータ」です。以下のグラフはあるネットワークのトラフィック量を示したものですが、どれがDoS攻撃を示したグラフでしょうか。
実はこの4つのグラフ、どれもDoS攻撃ではなく日常の通信を示しています。このグラフを見たときに「それは対象のシステムの環境によって判断が分かれるだろう」と思った方、鋭いです。まさにその「対象システム」がDoS攻撃を見分けるポイントになるのです。
DoS攻撃として認定されるかは、システムの環境によって異なります。あるシステムでは1時間に10回のアクセスでも「大量」と判断するかもしれませんし、またあるシステムでは1秒間に1万回のアクセスでも「普通」と判断するかもしれません。極端な表現をすると、DoS攻撃と認定されるのは「システムに異常をきたしたとき」なのです。システムに異常をきたしていない限り、それはDoS攻撃として認定されないともいえます。
システムに異常をきたす前にDoS攻撃を検知する手法として、一般的にはしきい値の設定が行われます。CPU負荷、メモリ使用量、セッション数が一定のしきい値に到達した時点で、DoS攻撃を受けたとする手法です。簡単な手法ではあるのですが、これらのしきい値は時間帯や曜日によって異なるため、実際の運用では過剰なアラートが発生するか、まったくアラートが発生しないという極端な状況になってしまいます。
この問題を解決する手法として、「学習型」の手法を取り入れたシステムがあります。これは時間帯や曜日によって異なる変化を学習し、ベースラインを作成します。一定の学習モードを終えて、運用モードに入ると学習した値からの乖離(かいり)度によってアラートを発生させます。
しかし、この手法も万全ではありません。学習モードによって学習した変化はあくまで過去のものであり、現在未来のビジネスの動きを学習したものではありません。新製品の発表によるWebアクセス、テレビで紹介されることによるWebアクセス、メールマガジンの配信、毎月恒例のWindows Updateなどビジネスの動きによってトラフィックは不規則に変化するため、その変化を知らないシステムは無用なアラートを上げてくることになります。
DoS攻撃を正確に見つけるためには、システムの特徴、ビジネスの動きと外部からの誘導行為を把握する必要があります。そしてそのすべてを常に把握することは難しいため、DoS攻撃の検知は難しいのです。
DoS攻撃の防御
DoS攻撃の検知が難しいと説明してきましたが、仮にDoS攻撃を検知できた場合、どうやって防げばいいのでしょうか。例えば、大量のIPアドレスからWebサーバのトップページへのGETリクエストが発生し、トップページの閲覧に問題が発生している場合に、取れる方法を想定してみましょう。
- (1)攻撃対象となったシステムを停止する
- (2)攻撃リクエストそのものを止める
- (3)システムを増強する
- (4)何もしない
(1)は、ファイアウォールやWebサーバを停止すれば、サービスを停止させるという攻撃者の目的が達成されてしまいます。多くの組織がビジネスでインターネットを利用している現在では、このような対応を取る組織は少ないでしょう。
(2)ができれば理想的ですが、攻撃者のリクエストと通常のユーザーのリクエストを選別することが大変難しいです。1つ1つのリクエストには差異がないとすると、選別する基準は一定時間当たりのリクエスト数の差になります。例えば「1秒間に100リクエストをするユーザーを一時的に拒否する」という設定を有効にする場合、同様のアクセスをするかもしれない通常のユーザーもアクセスできなくなる覚悟が必要です。この方法を選択する場合、DoS攻撃を検知・防御するシステム、もしくはサービスの導入が必要です。
(3)の方法は通常のユーザーを拒否することがない対策ですが、システムの増強には少なからずコストが発生します。システムを追加購入する必要がなく、チューニングで一定の効果が見込める場合もありますが、攻撃元のIPアドレスを増やされてしまえば、物理的な増強がすぐに必要になるでしょう。
(4)の対策は何もせず攻撃が終わるのをじっと耐える方法です。当然、攻撃が続いている間はサービスの提供に支障が継続します。DoS攻撃を台風のようにどうしようもないことだと割り切って耐え忍び、台風(DoS攻撃)が過ぎ去ったあとに壊れた部分を改修(ユーザーへのフォローなど)します。
いずれの方法も、システムが利用できないことによる売り上げやブランドの損失と、掛かるコストを比較して検討することになります。DoS攻撃に見舞われた組織ではサービスが止まることで、一時的には「何とかして対策すべし」という雰囲気にはなるものの、発生確率と導入費用を比較した結果、(4)の選択肢を取っている組織が多いようです。
私は、費用をかけてでも対策したい方には、キャリアが用意しているDDoS対策サービスをお勧めしています。サービスインフラ側での対策は機器の購入、運用費、維持費などが必要になるため、月額費用のみでキャリア側でフィルタしてもらえるサービスが良いでしょう。IIJ、OCN、ソフトバンクテレコムなどの大手キャリアがサービスを用意しているので必要な方は担当営業に問い合わせてください。
そして費用をかけてまで対策をすることを心配する方からのご相談には、大変失礼な話ではありますが、以下のようにお話ししています。
- Webサーバが止まれば誰かが発見します
- お金をかけてまで検知させる必要がありますか?
- 止める手段を持たないのに、検知することに頑張る価値がありますか?
このニュアンスは「○×表の真実:『検知できる』ってどういうこと?」を事前に説明しておかないと誤解されるので注意が必要です。それでも「大量アクセスによってリソースの枯渇でWebサーバが停止した」という事実を把握することが重要なことはいうまでもないですが、「コストをかけてまでやることか」ということはよく考えてほしいと思います。
アメリカと韓国へのDoS攻撃は、ボットを踏み台にして行われているものと推測します。5番目の対策として「世界中のボット感染パソコンを撲滅する」という方法も入れることができるかもしれません。ボットに感染したパソコンがなくなれば、攻撃者は自分の資金で購入したシステムで攻撃を行うことになります。そうなると、攻撃者の資金力を防御側の資金力が上回ることになり、DoS攻撃に勝つことができるでしょう。世界中のすべてのボットを駆除するには気の遠くなる時間が必要ですが、まずはわれわれが加害者にならないようにしなければなりません。
日本のWebサイトには……
2009年7月10日の時点では、日本のWebサイトはDoS攻撃の対象になっていないようです。攻撃者の狙いによっては日本のWebサイトを対象にしてくることも十分考えられます。日本のWebサイトが狙われると、われわれの生活で利用しているサービスに支障が発生することになり、私もいま以上に対応に追われることになるでしょう。いまのうちに準備できることをやったら、あとは攻撃者との我慢比べです。
大規模な組織が攻撃している可能性もありますが、われわれにはそれ以上の、さまざまな“縁”による総合力があります。この総合力で立ち向かえば怖いものはありません。私は北海道で感じた“縁”を強化するため、今夜も飲みにいくのでした。
Profile
川口 洋(かわぐち ひろし)
株式会社ラック
JSOCチーフエバンジェリスト兼セキュリティアナリスト
CISSP
ラック入社後、IDSやファイアウォールなどの運用・管理業務をへて、セキュリティアナリストとして、JSOC監視サービスに従事し、日々セキュリティインシデントに対応。
アナリストリーダとして、セキュリティイベントの分析とともに、IDS/IPSに適用するJSOCオリジナルシグネチャ(JSIG)の作成、チューニングを実施し、監視サービスの技術面のコントロールを行う。
現在、JSOCチーフエバンジェリスト兼セキュリティアナリストとして、JSOC全体の技術面をコントロールし、監視報告会、セミナー講師など対外的な活動も行う。
- 「DNS通信」記録していますか?――万一に備えたDNSクエリログの保存方法
- Web広告からのマルウエア感染「Malvertising」にどう対処すべきか
- 中の人が振り返る「Hardening 10 ValueChain」――学びにつながった「トラブルの数々」とは
- 無慈悲な専門家チーム「kuromame6」の暗躍に負けず勝利をつかんだチームは?
- 外部リソースの活用もポイントに、「Hardening 10 MarketPlace」開催
- Hardening Projectから派生した「MINI Hardening Project」に行ってみた!
- 「これさえしておけば助かったのに……」を避けるため、今すぐ確認すべき7項目
- アップデート機能を悪用した攻撃に対抗セヨ!
- 工夫、工夫そして工夫――Hardening 10 APAC“運営”レポート
- ウイルスとは言い切れない“悪意のあるソフトウェア”
- 2013年のセキュリティインシデントを振り返る
- ここが変だよ、そのWeb改ざん対応
- きっかけは不正侵入――私がセキュリティ業界に足を踏み入れたワケ
- CMSが狙われる3つの理由
- FacebookやApple、MSまで……Javaの脆弱性を狙う攻撃の手口
- Hardening One、8時間に渡る戦いの結果は?
- そのときStarBEDが動いた――「Hardening One」の夜明け前
- ロシアでわしも考えた
- 実録、「Hardening Zero」の舞台裏
- ちょっと変わったSQLインジェクション
- 官民連携の情報共有を真面目に考える
- アプリケーションサーバの脆弱性にご注意を
- IPv6、6つの悩み事
- スパムが吹けば薬局がもうかる
- JSOCに飛び込んできた不審なメール――これが標的型攻撃の実態だ
- 東日本大震災、そのときJSOCは
- ペニーオークションのセキュリティを斬る
- 2010年、5つの思い出――Gumblarからキャンプまで
- 9・18事件にみる7つの誤解
- 曇りのち晴れとなるか? クラウド環境のセキュリティ
- Webを見るだけで――ここまできたiPhoneの脅威
- 不安が残る、アドビの「脆弱性直しました」
- ともだち373人できるかな――インターネットメッセンジャーセキュリティ定点観測
- 実録・4大データベースへの直接攻撃
- Gumblar、いま注目すべきは名前ではなく“事象”
- Gumblarがあぶり出す 「空虚なセキュリティ対策」
- 新春早々の「Gumblar一問一答」
- 実はBlasterやNetsky並み?静かにはびこる“Gumblar”
- ECサイトソフトウェアはなぜ更新されないのか
- 狙われるphpMyAdmin、攻撃のきっかけは?
- 学生の未来に期待する夏
- 米韓へのDoS攻撃に見る、検知と防御の考え方
- 分かっちゃいるけど難しい、アカウント情報盗用ボット対策
- 狙われる甘〜いTomcat
- 表裏一体、あっちのリアルとこっちのサイバー
- 世間の認識と脅威レベルのギャップ――XSSは本当に危ないか?
- 急増したSQLインジェクション、McColo遮断の影響は
- ○×表の真実:「検知できる」ってどういうこと?
- ところで、パッケージアプリのセキュリティは?
- レッツ、登壇――アウトプットのひとつのかたち
Copyright © ITmedia, Inc. All Rights Reserved.