メールサーバ防御でも忘れてはならない「アリの一穴」：セキュリティ対策の「ある視点」（4）（3/3 ページ）

» 2007年10月19日 00時00分公開

メールコマンド制御による情報制限

　対策2で紹介したHELPコマンドの実行結果でTopicsに表示されているように、Sendmailではさまざまなコマンドが実行可能である。中には情報取得に用いることが可能なコマンドが存在するので、その紹介をしよう。

「VRFY」と「EXPN」

　この2つのコマンドは引数を与えることで外部から情報を取得することが可能である。取得される情報は以下のとおりである。

VRFY - 特定のユーザーのメールボックスの存在
EXPN - 特定のメーリングリストの存在

　また、スパム送信のために特定組織のメールアドレスを収集する際にこの手法が用いられることもあり、辞書ファイルを用いたユーザー列挙ツールも存在している。VRFYとEXPNは実行方法が同じであるため今回はVRFYを取り上げて解説する。以下はその実行ログである。

【辞書を用いたVRFYチェックツール（対策前）】

--------------------------------------------------

Connecting To xx.xx.xx.xx SMTP Port 25 .... connected !!!

250 yy.zz Hello yy.zz [xx.xx.xx.xx], pleased to meet you

250 2.1.5 root <root@yy.zz>

250 2.1.5 <tsuji@yy.zz>

250 2.1.5 <muman@yy.zz>

250 2.1.5 <topper@yy.zz>

250 2.1.5 <ace@yy.zz>

250 2.1.5 <zoom@yy.zz>

　　　：

　上記のようにどのような応答かが列挙される。存在するユーザーと認められたものは250が返されたことが表示される。

【関連記事】

電子メールセキュリティの基礎知識（2）

スパムメール対策――必要なメールを必要な人に

http://www.atmarkit.co.jp/fsecurity/rensai/mailsec02/mailsec01.html

メールコマンドで情報を漏らさないための対策

　それでは、対策方法を見てみよう。

　対策は、VRFYとEXPNの2つのコマンドの制御である。設定を行うファイルはバナー隠ぺいと同じく、sendmail.mcを使用する。制御を行うには以下の1行を記述する。

define(`confPRIVACY_FLAGS',`xxx')dnl

　xxxの部分にはあらかじめ用意されている文字を記述することができる。記述できるフラグは以下のとおりである。

記述	フラグの説明
authwarnings	自分と異なるユーザー名をEnvelope-Fromにセットしメールを送信した場合、“X-authentication-Warning”ヘッダが付加される。
needexpnhelo	EXPNコマンド実行前にHELOおよびHELOコマンドによる手続きがない場合は、EXPNコマンドを受け付けない。
needvrfyhelo	VRFYコマンド実行前にHELOおよびHELOコマンドによる手続きがない場合は、VRFYコマンドを受け付けない。
needmailhelo	MAILコマンド実行前にHELOおよびHELOコマンドによる手続きがない場合は、MAILコマンドを受け付けない。
noexpn	EXPNコマンドを無効にする。
needexpnhelo	VERBコマンドを無効にする。
noetrn	ETRNコマンドを無効にする。
novrfy	VRFYコマンドを無効にする。
goaway	needmailhelo、noexpn、novrfy、noverb、authwarningsなどを指定したと見なす。

表1　privacy_flagsで制限できるSMTPコマンドの抜粋
　　　（VRFY、EXPNに関係するもの）

　ほとんどの場合は、特に細かい設定を施さず、「goaway」とすることで問題ないだろう。ほかの制限と組み合わせて、細かい設定を行いたい場合は適宜、その組み合わせを記述するとよい。

　追加ができたら、sendmail.cfを再生成して、Sendmailを再起動することで設定が反映される。

　また、sendmail.cfを直接編集する場合は以下のように「PrivacyOptions」部分に変更を加える。

O PrivacyOptions=goaway

　細かく設定する場合はgoawayの部分に記述したい内容を以下のように「,」区切りで記述することとなる。

O PrivacyOptions=authwarnings,novrfy,noexpn,restrictqrun

　それでは、制限設定を行った後のチェックをしてみよう。

【辞書を用いたVRFYチェックツール（対策後）】

--------------------------------------------------

Connecting To 127.0.0.1 SMTP Port 25 .... connected !!!

250 localhost.localdomain Hello localhost.localdomain [127.0.0.1], pleased to meet you

252 2.5.2 Cannot VRFY user; try RCPT to attempt delivery (or try finger)

　　　：

　制限が反映されると上記のように、すべて、252が返されたことが表示され、ユーザーの存在の有無は確認することができないようになっていることが分かる。

セキュリティとは“鎖”のようなもの

　今回は、Sendmailについて取り上げた。読者の方の中には「バナーによる情報取得にユーザー情報の取得。Apacheの記事と同じような内容じゃないか」と感じた方は少なくないのではないだろうか。

　筆者としてはそれで問題ない。

　今回の記事を通じて知っていただきたかったことは、同じような問題は別の経路からも発生するということである。つまり、セキュリティ対策は、1つでも抜けや漏れがあっては意味がない。

　ApacheとSendmailで同じような情報取得方法があった場合、Apacheのみの対策では意味を成さないということである。

　「セキュリティは鎖のようなものである」――よく耳にする言葉ではないだろうか。鎖のどこか1つでも切れてしまえば、そこから被害は拡大し、思いもよらない事態を招く恐れがある。現にペネトレーションテストの現場で、とある経路からユーザー名が判明し、そこから芋づる式に情報が収集でき、最終的にはシステムの掌握にまで至った例も珍しくない。

　対策を行うことには、その対策で十分であるかということを吟味するところから始まっているのだろうと筆者は考えている。そのためには、さまざまな視点からシステムを見つめ直す機会を持つことが重要なのではないだろうか。

「次回」へ

「セキュリティ対策の「ある視点」」バックナンバー