皆さんこんにちは、川口です。2008年7月12日に大阪で行われたセキュリティ関連の勉強会、「第15回まっちゃ139」にお招きいただき、講演をさせていただきました。前々からまっちゃ139の存在は知っていたのですが、予定が合わず参加できずにいました。初参加がいきなり講師ということになりましたが、皆さんに積極的に参加していただいたおかげで楽しくお話しさせていただきました。
当然、懇親会にも参加して、ほかの参加者と交友を深めてきました。さまざまな立場の人と知り合って、話ができる勉強会&懇親会というのは良いですね。日本の各地でセキュリティをテーマにした勉強会が開催されているので、情報をキャッチアップされている人には特に積極的に参加してほしいと思います。
IPSは使えるのか?
このようなセミナーや勉強会などに参加するとよく聞かれる質問があります――「実際のところIPS(Intrusion Prevention System:侵入防止装置)は使えるのか?」。
これはIPSの導入を検討している人からよく聞く質問です。IPSが登場し始めた2004年くらいの話であれば「新しい技術ですから、まだまだ課題が多いですね」と答えていました。しかし、ここ数年で機能が大幅に改善しているため「ちゃんと使えば、良い感じに動きますね」と答えています。
ポイントは「ちゃんと使えば」というところです。このポイントは製品の営業資料には書いてはいません。細かい技術的な説明は書ききれませんが、少なくとも以下のような誤解を持ったまま導入しないようにしましょう。
- IPSを導入するとパッチを適用する必要がない
- IPSを導入するとすべての攻撃を止めてくれる
- IPSはIDS(Intrusion Detection System:侵入検知システム)の延長のようなものだ
この話は、最近はやりのUTM(Unified Threat Management)製品も同じであると考えていただいても差し支えありません。
IPSを盲信していませんか
IPSを入れることで、パッチ適用の代わりになると聞かされている方もいらっしゃるかもしれません。それはIPSがすべての攻撃を止められるという前提でのみ成り立ちます。残念ながら、IPS導入ですべてのパッチ適用が必要なくなるものではありません。
IPSは万能の魔法の箱ではありません。IPSに実装されているIPSシグネチャの精度は攻撃の種類や対象となる脆弱(ぜいじゃく)性によってさまざまです。第5回「ネガティブか、ポジティブか……それが問題だ」でも書いたようにフォールスポジティブ(False Positive:誤検知)とフォールスネガティブ(False Negative:見逃し)のバランスを見てIPSシグネチャを作らなければなりません。悪意のある攻撃を確実に止めようとIPSシグネチャを作ると、攻撃が回避されやすくなってしまいます。回避されないようにIPSシグネチャの精度を高めつつ、通常ネットワークで利用している通信を誤って止めないようにも配慮する必要があります。
IPSシグネチャの設定で、シグネチャに引っ掛かった通信を「遮断」するのか「検知のみ」にするのかを指定できると思いますが、すべてのIPSシグネチャを「遮断」設定にすることはお勧めできません。IPSベンダから提供されるIPSシグネチャの中には検知精度の低いものも存在します。この検知精度の低いIPSシグネチャを「遮断」設定にした場合、悪意のある攻撃を止められますが、悪意のない通信も止めてしまうことにつながります。日常的にネットワークに流れている通信によって、どのようなIPSシグネチャを「遮断」設定にするのか「遮断せずに検知だけ」設定にするのかを決めなければなりません。
IPS機器を4年にわたり運用・監視してきた経験からいうと、IPSシグネチャ名に「Generic(一般的な)」「Anomaly(例外、異例)」「Suspicious(怪しい)」と付いているIPSシグネチャは遮断設定にしない方がよいでしょう。このような名前のIPSシグネチャは第5回に出てきた「フォールスポジティブとフォールスネガティブの相関イメージ」の図の左側に寄せられて作られており、フォールスネガティブを下げるために作られたIPSシグネチャである可能性が高いからです。
また第4回「ポートスキャン、私はこう考える」で説明したポートスキャンにも注意が必要です。ポートスキャンとはホストやサービスの稼働状況を調査するための行為です。一般的には以下のように連続してパケットを送信します。
- (1)攻撃元→ホストA or ポートA
- (2)攻撃元→ホストB or ポートB
- (3)攻撃元→ホストC or ポートC ← この時点でポートスキャンと判定したと仮定
- (4)攻撃元→ホストD or ポートD
- (5)攻撃元→ホストE or ポートE
設定されたしきい値にもよりますが、ある一定数、一定量のパケットが送信された時点でポートスキャンとして判定されます(上記の場合は「3回以上のパケットが送信された時点でポートスキャンと判定」していると仮定しています)。
上記のように(3)の時点でポートスキャンとして判断された場合、(1)と(2)はすでに通過しているので、遮断できません。(4)以降のパケットを遮断できる機能が付いているものがありますが、攻撃元が送信元IPアドレスを偽装して、ポートスキャンを行っている場合、正規のホストからの通信を遮断してしまうことになるので、お勧めできません。
ポートスキャンは単なる調査行為です。IPSで防御するという考え方ではなく、適切なアクセス制御をすることで対処しましょう。
遮断できなかったものはどうするのか?
初めてIPSというコンセプトを知ったとき「これでパッチ適用の負荷が軽減される」と思ったものです。IPSシグネチャの存在によって、パッチ適用の優先度を決められるというメリットはできましたが、現実にはすべてのパッチ適用作業がなくなるわけではありませんでした。
利用者側の心理としては「そこを何とかうまく調整してよ」と思うところですが、その調整が非常に難しいのが現実です。IPSベンダとしては世界中のお客さまのネットワークを把握することはできないため、一般的なネットワーク通信や脅威、脆弱性の情報を基に作成するしかないのです。一般的な環境を想定して作られたIPSという機械をうまく使うためには、実装されているIPSシグネチャを理解し、個別の環境に合わせてチューニングしていかなければなりません。攻撃を止めつつ、攻撃ではないものを止めない設定作業、最新の脅威動向とお客さまごとの環境に合わせた最適化(チューニング作業)こそがわれわれセキュリティアナリストの腕の見せどころでもあるわけです。
その腕を駆使したとしても、「遮断」ではなく「検知」の設定をするIPSシグネチャはたくさんあります。しかし、私は遮断できないことを悲観的に考えているわけではありません。IPSシグネチャを「検知」設定にした場合、攻撃通信はIPSを通過してしまいます。しかし、「検知」設定になっているため、IPSには攻撃のログが残ります。攻撃を瞬時に止めることはできませんが、このログをわれわれセキュリティアナリストが分析することで、攻撃に早期の対応、早期の対処ができます。
もしもログを分析するセキュリティアナリストがいない場合、「検知」した通信は対処されないまま放置されるか、通信を誤遮断してしまうリスクを取って「遮断」設定を行うしかありません。セキュリティアナリストはIPSシグネチャの精度や特徴、実績から判断し、影響の大きさで「遮断」と「検知」を選択しています。危険な攻撃は「遮断」し、遮断できない攻撃は「検知」でカバーするのです。セキュリティアナリストの存在が、「攻撃への防御」と「通信への影響の低減」というIPSの難しいバランスを保っているのです。
さて、あなたのIPSシグネチャの設定はどうなっていますか? 遮断しないログはきちんと分析されていますか? もう一度確認してみてください。
「IPSはネットワーク機器」そんなことは知っているって?
多くの人がIPSの利用を考える際に「攻撃をいかに止めるか?」を考えています。攻撃や許可していない通信を止めるために利用する機械ですから、この考えは間違っていません。しかし、大事なことが忘れられている場合も多いのです。それは、
- IPSはネットワーク機器でもある
→つまりIPSの障害がネットワークの障害につながる
ということです。
IDSの延長として考えられることがあり、ネットワーク機器として考慮がされていないケースがあります。IDSの導入であれば、何か機器に障害が起こったとしても業務に直接影響を与えることはほとんどありませんでした。しかし、ネットワーク機器に障害が起これば、IPSを通る通信すべてに影響が発生します。ネットワーク機器として稼働する以上、そのIPS機器の障害はネットワークの障害に直結します。障害ポイントが1カ所増えるといってもよいでしょう。まったく壊れないハードウェアとソフトウェアというものが存在しない以上、IPSの障害も想定しておく必要があります。
IPSに障害が発生した場合には2つの動作モードがあります。それは「Fail-Open」と「Fail-Close」です。「Fail-Open」は機械が故障したときには何もせずに通信を通すモードです。このモードになった場合には、悪意のある攻撃を遮断することはできなくなりますが、ネットワークの通信自体は止まることがありません。「Fail-Close」は機械が故障した場合には完全に停止し、ネットワークの通信も止めてしまうモードです。IPSの上流で障害対策が取られている場合に利用することが多いです。どちらのモードが使えるかは機器やオプションによって異なるので注意が必要です。
IPSを利用するときに心配するのは障害だけではありません。IPSベンダは最新の脅威に対応するため、アップデートをリリースします。その多くはIPSを止めることなく適用できるものですが、中にはIPSの再起動が伴うものもあります。IPSが再起動する際にはIPSで保持されている通信セッションは破棄されます。IPSを導入する場合にはIPSのアップデートもネットワークのメンテナンス計画に含めておく必要があります。
IPSは“使える機器”。しかしそれをどう使うかを決めるのは人間だ
そのほかにも気にするべきポイントはたくさんありますが、特に気を付けてほしい点をまとめます。
- IPSはすべての攻撃を止めているわけではない
- IPSはネットワーク機器でもある
- IPSは魔法の箱ではない。大事なのはそれを使う人
やはり最終的にはそのシステムを利用する「人」が最も重要です。IPSが魔法の箱ではない以上、接続しただけではうまく機能するものではありません。そのIPSへいかに知恵を入れて、いかにうまく動かせるかということが重要です。
また、その「人」が技術だけ身に付けていたのでは、組織のリスクに対応できません。われわれセキュリティアナリストは、技術だけではなく組織全体のリスクを俯瞰(ふかん)できるようにしなければなりません。
いま、まさに私の隣に座っているセキュリティアナリストが視野を広げるべく、国際的に認められた情報セキュリティ・プロフェッショナル認証資格CISSPを取ろうと奮闘している最中です。私はセキュリティアナリストのリーダーとして、そんな彼を激励するため、彼を連れて今夜も飲みに行くのでした。
Profile
川口 洋(かわぐち ひろし)
株式会社ラック
JSOCチーフエバンジェリスト兼セキュリティアナリスト
ラック入社後、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.