たった2行でできるWebサーバ防御の「心理戦」
@ITより、バナー情報隠蔽に関する記事。記事の中ではいわゆる根本的対策*1をした上で、保険的対策*2としてバナー隠蔽をした方がよいとしている。
今や常識的な話だと思えるのだが、バージョン隠蔽に関しては昔から議論が分かれることがある。この記事に関してはTarikiさんが反論している。
実際、以前*3あるMLでバナー隠蔽の議論になった。私は記事の筆者と同じ考えで、ある方がバナー隠蔽なんか意味がないとおっしゃっているので、何通か議論をしたことがある。そのときは、バナーをみて攻撃する人やバナー情報を判断して適切なexploitを打ち込んでくるワームの例をあげて説明したが、結局は議論は収束せず平行線のままだった。
そもそも攻撃者やサーバ運用者側の想定が違うのでMLで議論するには、大変だとあきらめたんだが、今になってblogでセキュリティ技術者同士で似たような状態になっているので、ビックリ。
Tarikiさんの反論を読んでみたところ、昔MLで議論した相手と意見がそっくりなので、ちょっとだけ思うことを書いてみる。
バージョン情報を隠す前に、まずは問題の無いデーモンでサービスを提供するようにメンテナンスを行うべきだ。
正論なんだけど、性質の違う2つを天秤にかけてもしょうがない。バージョン情報の隠蔽は1度行えば済む事で構築時に設定しておけば、運用期間中バナー隠蔽に関しては何もしなくて良い。それに対して常にセキュリティ問題のない状態にしておくには、運用期間中ずっと運用体制を整えておかなければいけない。運用開始時にセキュリティ問題がない状態にした上でバナー隠蔽しておけば、運用中にセキュリティ問題が発覚しても、どちらか迷う必要なんてない。
まずはパッチをあてろ。そうすれば、バナーなんぞどうでもいい。
パッチをすぐに当てられる環境であればこのような考え方で問題ない。しかし、世の中にはパッチをすぐに当てたくても当てられないシステムもたくさんある。Webアプリケーションとミドルウェアが密に連携したシステムや高可用性を求められる銀行のシステムでは、1つのパッチが出たからといって、すぐにメンテナンス出来るわけではない。そういった根本的対策が取れないケースがあるからこそ、あまり意味がないかもしれない保険的対策でも、いろいろ積み上げて少しでもリスクを小さくするのである。
記事の筆者はパッチとバナー隠蔽の2択でバナー隠蔽をしろと言っているのではないし、被害を防げない可能性が高いと思われるバナー隠蔽であっても1度設定するだけのことなんだから、是非やっておくべきだと思う。
