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

「千丈の堤もアリの一穴」という言葉があります。大きな穴を埋めることも重要ですが、穴になりそうなものへの対策も重要かもしれません。

[辻 伸弘（ソフトバンク・テクノロジー株式会社），＠IT]

対策1：Sendmail接続時のグリーティングメッセージの隠ぺい

　まずは、Sendmail接続時のグリーティングメッセージを確認しておこう。グリーティングメッセージはtelnetクライアントなどでSendmailがオープンしているポートに接続することで表示される。

【隠ぺい設定を行う前のSendmailのグリーティングメッセージ取得結果】

# telnet xx.xx.xx.xx 25

220 yy.zz ESMTP Sendmail 8.13.1/8.13.1;

　このバナーを隠ぺいするには、「sendmail.cf」を生成するために必要なファイル、「sendmail.mc」に以下の1行を追加する。

【追加する行】

define('confSMTP_LOGIN_MSG','unknown')dnl

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

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

【変更前】

# SMTP initial login message (old $e macro)

O SmtpGreetingMessage=$j Sendmail $v/$Z; $b

【変更後】

# SMTP initial login message (old $e macro)

O SmtpGreetingMessage=$j unknown; $b

　この場合も、Sendmailを再起動することで設定が反映される。

　上記設定を行うことにより、前述したグリーティングメッセージが以下のようにバージョン情報を含まないものとなる。

【隠ぺい設定を行ったSendmailのグリーティングメッセージ取得結果】

# telnet xx.xx.xx.xx 25

220 yy.zz ESMTP unknown;

対策2：HELPコマンド実行時

　HELPコマンドは、Sendmail上で実行できるコマンドの1つである。よって、Sendmail接続後にHELPコマンドを実行することでバナー取得が可能なのである。

【隠ぺい設定を行う前のHELPコマンドでのバナー取得結果】

HELP

214-2.0.0 This is Sendmail version 8.13.1

214-2.0.0 Topics:

214-2.0.0 HELO EHLO MAIL RCPT DATA

214-2.0.0 RSET NOOP QUIT HELP VRFY

214-2.0.0 EXPN VERB ETRN DSN AUTH

214-2.0.0 STARTTLS

214-2.0.0 For more info use "HELP <topic>".

214-2.0.0 To report bugs in the implementation send email to

214-2.0.0 [e-mail].

214-2.0.0 For local information send email to Postmaster at your site.

214 2.0.0 End of HELP info

　このコマンドの実行結果の内容は、「/etc/mail/helpfile」に記述されているものが表示される仕組みとなっているため、バナー情報を隠ぺいするには、このファイルを直接編集すればよい。

　変更を加える個所は以下のとおりである。

【変更前】

smtp This is Sendmail version $v

【変更後】

# smtp This is Sendmail version $v

　上記のようにコメントアウトすることにより、「214-2.0.0 This is Sendmail version 8.13.1」の個所がHELPコマンド実行時に表示されなくなる。

【隠ぺい設定を行ったHELPコマンドでのバナー取得結果】

HELP

214-2.0.0 Topics:

214-2.0.0 HELO EHLO MAIL RCPT DATA

214-2.0.0 RSET NOOP QUIT HELP VRFY

214-2.0.0 EXPN VERB ETRN DSN AUTH

214-2.0.0 STARTTLS

（以下略）

　また、

214-2.0.0 [e-mail].

の個所にSendmailという文字列が含まれるということが気になるようであれば、こちらもコメントアウトしてもよいだろう。

　そもそも、HELPコマンドの実行結果を表示させる必要がないと考える場合は、HELPファイル（/etc/mail/helpfile）の中身を空のファイルと置き換えてしまうという対策もある。

【HELPファイルを空にしたHELPコマンドでのバナー取得結果】

HELP

214 2.0.0 End of HELP info

対策3：メールヘッダの中身

　メールがどのような経路で到達したのかが記述されているメールヘッダの中にSendmailのバージョン情報が表示される。攻撃者はSendmailに対して、到達しない（存在しない）メールアドレスをあて先として設定し、エラーメールを自分のところに返させることでメールヘッダの内容を確認する。

図1　攻撃者は存在しないメールアドレスにメールを送りつけ、メールヘッダ情報を取得する

　ここで表示される内容は以下のとおりである。

【隠ぺい設定を行う前のメールヘッダ】

Received: from n-tsuji ([xx.xx.xx.xx])

by yy.zz (8.13.4/8.13.4)

　これを抑制するには、「sendmail.mc」に以下の1行を改行せずに追加する。

define(`confRECEIVED_HEADER',`$?sfrom $s $.$?_($?s$|from $.$_) $.$?{auth_type}(authenticated)$.by $j(unknown)$?r with $r$. id $i$?ufor $u; $|;$.$b')dnl

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

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

【変更前】

HReceived: $?sfrom $s $.$?_($?s$|from $.$_)

$.$?{auth_type}(authenticated$?{auth_ssf} bits=${auth_ssf}$.)

$.by $j ($v/$Z)$?r with $r$. id $i$?{tls_version}

【変更後】

HReceived: $?sfrom $s $.$?_($?s$|from $.$_)

$.$?{auth_type}(authenticated$?{auth_ssf} bits=${auth_ssf}$.)

$.by $j (unknown/$Z)$?r with $r$. id $i$?{tls_version}

　上記設定を行うことにより、メールヘッダが以下のようにバージョン情報を含まないものとなる。

【隠ぺい設定を行った後のメールヘッダ】

Received: from n-tsuji ([xx.xx.xx.xx])

by yy.zz (unknown)

Webサーバだけではなく、Sendmailの対策も忘れずに

　バナー情報が外部から取得可能であることの危険性は、第1回で述べたとおりである。このSendmailのバナー対策についてペネトレーションテストの現場ではどうかということを紹介しよう。

　意外なことに、Sendmailが稼働している対象の検査を行った場合、3つすべてに対策がなされていることは、筆者が担当した中では半分にも満たない状況だった。

　グリーティングメッセージは対策が取られバナーは隠ぺいされているが、HELPコマンド実行時の対策は取られておらず容易にバナー情報を取得可能であるといったように、3つのうちいずれかが実施されていない場合が多い。

　Sendmailを運用されている方は、いま一度、3つすべてにおいて対策が取られているかの確認を行うことをお勧めする。