yohgaki’s blog – サーバシグニチャは隠すのが当たり前
http://blog.ohgaki.net/index.php/yohgaki/2007/09/04/a_ma_fa_a_ma_da_a_a_pa_me_na_a_ra_af_a_a
に対するコメントを見つけました。このブログに対するご意見は探したことがないので、たまたま見つけたこのブログが初めてくらいだと思います。「サーバシグニチャは隠さないのが当たり前」とするご意見です。
なぜサーバのバージョン情報を公開する必要があるのか。それは、クライアント側で、サーバのバグや規格解釈の相違に起因する問題を回避するためです。
「当たり前」とするには理由が弱いと思います。サーバ側はサービス提供者が自由にコントロールできる要素です。サーバがオプションとして送信する特定のヘッダを送信しようとしまいと正しく処理できるようにするのはブラウザの責任です。最悪の場合、サーバは攻撃用のヘッダを送信してくるかも知れません。サーバシグニチャが100KBもあるヘッダなどが送信されても問題が発生しないようにするのはブラウザ側の責任であるのと同じです。
クライアント側で「サーバのバグや規格解釈の相違に起因する問題を回避」している場合があるは知っていまたが決定的と言える問題ではありません。Pipelineは使えないと多少効率が落ちるだけです。（サーバ側では別にPipelineをサポートしないからといって、負荷が軽減するものでもありません。）Pipelining以前に、より多くのクライアントに安全にデータを送信するためにKeepAliveさえ無効に設定しているサイトもまだまだ多いでしょう。(i.e. HTTP Response Splitting) Pipeliningは一例かと思いますが、これを持って「サーバシグニチャは隠さないのが当たり前」とするには不十分だと思います。もしかすると私が知らない決定的な問題があるのかも知れませんが、その場合は教えていただけると有難いです。
クライアント側がユーザエージェントヘッダを「送信するのが普通」だと思いますが、送るのが「当たり前」だとは思いません。それはユーザの自由です。同じように「JavaScriptを無効」にするのもユーザの自由です。「最近JavaScriptが有効なのが当たり前」なサイトが増えていますが、全てのWebサイト開発者はWCAGをよく読むべきです。WCAGはJIS規格にも採用されています。ユーザビリティだけの問題でなく、より安全にWebを利用するためにJavaScriptを無効にするのはずいぶん当たり前になりつつあります。
画像を表示できないテキストブラウザでWebサイトを参照するのも自由で有るべきです。文字を表意しない音声ブラウザでWebサイトを参照するのも自由で有るべきです。たとえ十分に利用できない可能性があっても「あなたのブラウザでは参照できません」と門前払いをすべきではありません。
とにかく、サーバシグニチャを隠すのも、インストールされている全てのモジュールのバージョンまで含めて隠さないのもサーバ管理者の「自由」です。
http://memo.hirosiki.jp/article/54026897.html
結論：
サーバシグニチャを出さないことでは確かにウノウの言うようなセキュリティレベルの向上は“それほどは”得られないが、だからといって出さないことがクソだのタコだの言うのはバカ。
多少言葉は悪いですが、両方の意見に対してかかれたこのブログのメリット・デメリット、結論は理解できます。
サーバシグニチャに詳しいサーババージョンを書かないのはセキュリティレベルを向上させると言うよりは「犯罪者のデータベース作成に協力しない」ことが私としては1番目の目的です。この対策は役に立たないかも知れませんが、役に立つかも知れない、といった対策です。採用するかしないかは管理者（またはセキュリティポリシー）次第です。攻撃され辛くする対策は根本的なセキュリティ対策とは言えないかもしれませんが、多くの場合それで十分である事も事実です。例えば、家の玄関ドアの鍵を2つにする、割れにくい窓ガラスにする、などは泥棒（攻撃）対策に有用であるとされています。完璧なセキュリティ対策でなくても十分有効に機能する例は多くあります。
ちょっと脱線します。UserAgentを参照し、IE, Fireforxの各バージョンの脆弱性に合わせた攻撃を行い、脆弱性がないUserAngetの場合攻撃を行わないWebサイトも実存します。ブラウザのUserAgentを送信しない、または正しいUserAgentを送信しないのは普通とは言えませんが、実際にこうした攻撃が有る以上、「送信するのが当たり前でしないのはNG」とするのは問題があると思います。余計(?)なヘッダ情報は実際に攻撃に利用されているのです。
クライアント（ブラウザ）を作る人、Webアプリを作る人、はそれぞれサーバ、クライアントには「十分な自由度」があるように作らなければならないと考えています。
「うちのサイトはIEのみでVBScriptが有効なブラウザしか使えない仕様」にするのもサイト運営側の自由です。万人向けでは無いサイトを作るのも自由ですが、広く一般に公開しているサイトであるにも関わらず万人向けサイトではない無い場合、そのことを明記するべきです。特に責任ある企業のサイトなら尚更です。
話を戻しますが、Webサーバとモジュールの安全性に100%の自信があれば詳しいサーバ構成を記述したヘッダを送信することに異論はありません。 安全性に不安を持っている（100%の信頼を持っていない）システム管理者であれば「(特に懇切丁寧な）サーバシグニチャは送信しないのは当たり前」だと思っているだけです。私のブログからも分かるように私の立場は「100%信用していないのでシグニチャは隠すのが当たり前」と考えています。
最近は攻撃の高度化、ステルス化が進んでいます。昔のように手当たり次第で直ぐ分かるような攻撃は少なくなり、システム管理者が気が付かない方法で攻撃してきます。仮に自分が犯罪者でWebサーバやそのモジュールの脆弱性を利用して乗っ取れる0Day攻撃手法を発見した場合、手当たり次第に攻撃するのではなく、できるだけサーバ管理者に気づかれないように細心の注意を払って攻撃します。その攻撃に利用する重要な情報の一つがサーバシグニチャです。サーバを乗っ取った後、カーネルレベルルートキットをインストールするためにフィンがープリンティングでサーバが利用しているOSとそのバージョンも調べるでしょう。カーネルレベルルートキットをインストールすれば、ルートキットのファイル・プロセス・ネットワーク接続が参照できなくなるのでIDS/IPSをゲートウェイなどにインストールしていなければ検知するのは極めて困難になります。水際で攻撃を防止する重要性はますます増加しています。
ほとんど全てのセキュリティ対策にはメリットとデメリットがあります。セキュリティポリシーはそのバランスをどこに設定するのか決めるものです。便利なシステムを利用している以上、リスクは受け入れなければなりません。どのリスクを受け入れ、どのリスクを軽減し、どのリスクを排除するかはセキュリティポリシーで決めます。
# 正しくリスクを識別すること（リスクアセスメント）がセキュリティ対策
# では非常に重要です。リスクを識別できなければ、組織やサービスが必要
# としているセキュリティポリシーは策定できません。
# Pipelineとかは本来はプロトコルバージョンで判別できれば良い機能だと
# 考えています。現実的にはHTTP/1.1.1とかすると誤作動するソフトウェアが
# 山ほど有るので無理ですが。サーバソフトの種別で判別するべき機能ではあ
# りません。時間が解決するのでそれまでpipelineは使わなければ良いだけの
# 機能です。ブラウザにはそういった機能は山ほどあります。E4X、CSS、DOM
# とか。
# そういえば最近Citrixのおかげで筒抜けになっているサイトが多数ある、と
# 話題になっていましたね。別問題と言われるかもしれませんが、べつにどう
# でもよいサーバシグニチャを隠すくらいの気遣いをする管理者であれば、
# こんな間違いは起きなかった可能性が高かったのではないか、と思っています。
#「JavaScriptを有効にしておくくらい当たり前」とユーザに強制するのであれ
# ば「100%安全なWebサイトを提供するのが当たり前」と言われても仕方ありま
# せん。100%安全性は絶対に保証できないので「どのようなクライアントでアク
# セスしても、必要最小限はナビゲーションできて当たり前」と考えています。
# 少なくとも「このサイトはJavaScriptを利用しているのでJavaScriptを有効
# にしてください」とメッセージを表示すべきです。noscriptタグを入れるの
# が面倒だとは思えません。
「あたり前」論には少なからず主観が含まれます。「あたり前」とか「常識」は主観無しにはあり得ないからです。従って、一つの「あたり前」には反対の「あたり前」もあります。どれを「あたり前」とするか、もしくはしようとするかは個人のセンスだと思います。
書かない日記のはずがつい書きすぎてしまいました。書きたい事は山ほどある
のですが、今日はこの辺で。
