メールサーバ防御でも忘れてはならない「アリの一穴」：セキュリティ対策の「ある視点」（4）（1/3 ページ）
「千丈の堤もアリの一穴」という言葉があります。大きな穴を埋めることも重要ですが、穴になりそうなものへの対策も重要かもしれません。
第3回まではApacheに関するセキュリティ設定について紹介させていただいた。第4回となる今回は、Sendmailについてのセキュリティ設定である「バナー隠ぺいに関する3つの方法」と「メールコマンド制御による情報制限」の2点を紹介しよう。
稼働中のサービスの種類やバージョンなどを知らせるバナー情報について第1回で取り上げたところ、読者より非常に大きな反応があった。Sendmailについて解説する前に、バナー隠ぺいについての筆者の考えを述べさせていただきたい。
バナーを隠ぺいすることの狙い
「バナーを隠ぺいすることはセキュリティ設定と呼べるのかどうか？」「 バナーの隠ぺい設定は行うに値することかどうか？」
これは、かなり前からセキュリティのコミュニティだけにかかわらず各所で議論されてきた話題だろう。
第1回でも説明したように、筆者はバナー情報は隠ぺいすべきであるというスタンスを取っている。ただし、バナーを隠ぺいすることによってセキュリティ対策において完ぺきであるということをいうつもりではない。
バナー隠ぺいを行う前に行っておくことはたくさんある。「強固なパスワード設定」「アクセス制御の実施」「修正プログラムの適用」……すべて、優先度の高い対策である。バナー情報が取得できるという指摘は、ペネトレーションテストにおいて対策優先度は低めのものであり、脆弱性スキャナなどでは、「Lowリスク」や「インフォメーション」として報告されるものである。
筆者はペネトレーションテストでの報告会では以下のような報告をしている。言葉足らずの部分もあるかもしれないが、筆者の考え方、スタンスを読み取っていただければ幸いである。
報告内容（抜粋）
バナー情報を取得することにより、攻撃者がサーバアプリケーションのバージョンを知り、そこから攻撃方法を導きだす場合があります。
修正プログラムの適用やバージョンアップによりサーバプログラムを最新の状態に保つことは、最も優先度が高く、重要なことです。
ですが、運用を考慮すると、実機ではすぐさま対応できず、十分な検証に時間を要する場合もあるでしょう。
そのような場合、脆弱性を抱えたバージョンであるということを露呈し、運用し続けることは得策ではないという考えから、バナー情報を隠ぺいすることを推奨します。
現在、脆弱性を抱えていないサーバプログラムであったとしても、いつかは古くなり脆弱性が発見されることでしょう。そのことを考え対策を行っておくことが望ましいといえるでしょう。
攻撃者のパターンには大きく分けて2つあります。クラッカーやスクリプトキディのような「人」が行うパターンとウイルス、ワームと呼ばれるような自動化された「プログラム」が行うパターンです。
その2つのパターンには、それぞれ、バナー情報を調査するものもしないものもあります。
よって、バナー隠ぺいという対策がまったく効果を得られない場合もあります。極論をいえば、「しないよりは、したほうがいい」というレベルであるかもしれません。
セキュリティ対策や製品だけに限らず世の中には、100％、完ぺきというものは、ほぼ無いといっても過言ではないでしょう。
仮に攻撃者が1万人いたとして、その1％の100人に対してでも有効な対策であれば行うということがセキュリティ対策だと思います。あと、考慮するべきことは費用です。対策を行うための費用（時間、人件費）と望む効果をてんびんにかけて、プラスになると判断するならば、ぜひとも対策を行ってください
それでは、今回の本題に入ろう。
Sendmailのバナー隠蔽に関する3つの方法
Sendmailのバナー取得方法はApacheよりも多く、次の3つの経路から取得可能である。
（1）Sendmail接続時のグリーティングメッセージ
（2）HELPコマンド実行時
（3）メールヘッダの中身
取得経路が3つあるということは対策も同じく3つある。それらを順番に見ていこう。
Copyright © ITmedia, Inc. All Rights Reserved.