メールサーバのセキュリティチェックをやってみた
December 13, 2007 – 9:10 pmPostfixを使ったメールサーバ構築作業が一段落した。一応、メールの送受信も正常に行われている。最終的な作業として、セキュリティ対策を含めた機能テストをやることにした。ここで書くのは、まず、このサーバの乗っ取り行為に対する脆弱性テスト（第３者中継の可能性の可否）、次にダミーウィルスを使ったウィルス検知機能テストについて、そしてテストのなかで気が付いた運用面からみた手直しと、その結果といったところだ。
第３者中継の可能性テスト。ネット上で、「メールサーバ セキュリティ対策」をキーとして、Google上で検索すると、さまざまな記事がみつかる。そのひとつに、「情報処理推進機構：セキュリティセンター」のサイトに、UBE（迷惑メール）中継対策があった。ここに、不正中継可能サイトブラックリストを公開しているRBL.JPなるサイトが紹介されている。これに、’Third Party Relay Check’なるページがある。ホスト名を入力すると第三者中継の可能性をチェックすることができるようである。こういったテスト、主催者の素性を知らないでやるわけにはいかない。このRBL.JPなるサイト、「ハートコンピュータ株式会社を幹事とするボランティアグループによるプロジェクトで、日本の技術者が構築しています」とある。ハートコンピュータのホームページを覗いてみる。レンタルサーバなどを経営しているベンチャー企業のようだ。どうしようか迷うが、情報処理推進機構が紹介しているサイトだ。信用してもいいだろうということでテスト実施。
我がホスト名を入力して、[check]ボタンを押す。即座に、１９項目のテストが行われ、そのうち、１６項目についてPASSと青字で表示される、その他３項目は、Skipとやはり青字で表示された。「青が表示された場合にはあなたのサーバは安全です。」となっている。お墨付きをもらったようだ。不安は残るが、一応、テストは終了したということにした。しかし、この種のテストサイト、情報処理推進機構など公式の組織が行なってくれればいいのにと思う。セキュリティ問題の世界、「今日の安全は明日の危険」ということで、誰も保障できませんよということか? ということで、利口な政府関連機関は手をださないということなのか？なお、情報処理推進機構は、RBL.JPを不正中継可能サイトブラックリストを公開しているサイトとして紹介しているだけで、このテストツールにお墨付を与えてはいないということは念のため。
次は、ダミーウィルスを用いて、Clamd+Amavisdによるウィルス検知性能テストだ。ネット検索のなかで、EICA:European Expert Group for IT-Security（http://www.eicar.org/）なる組織からテスト用のダミーウィルスをダウンロードできることを知った。早速、この組織のサイトにアクセスした。かなりきちんとした組織のようだ。素人の私、信頼しても良さそうな感じがする。HPの上部に「Aniti-Malware Testfile」とある。ここをクリックすると、さまざまな注意事項に引き続いて、4種類の形態でテスト用ウィルスがダウンロードできるようになっている。ここから、eicar.com、そのzipファイルeicarcom2.zipを我が家の家庭用PC（クライアントとしていつも使用しているWindowsマシン）上にダウンロードした。これを添付ファイルとしてテストメールを作成、ISP（家庭用PCはOCNに加入している）から我がメールサーバ向け、そして我がメールサーバからISPのメールサーバ充ての送受信をそれぞれ行なってみた。
まず、ISPから我がメールサーバへの送信メールについて。受信したメールの件名欄は、
***INFECTED*** Test from OCN to MyServer with two different viruses
になっており、送信時の件名に***INFECTED***が付け加えられている。本文は、
WARNING: contains virus Eicar-Test-Signature, Eicar-Test-Signature
添付ファイルの欄には、送信時のメッセージと添付ファイルが残されている（Windowsで、この受信添付ファイルを開けると、「次の添付ファイルは安全でないため、メールからのアクセスが削除されました：eicar.com」とのメッセージがだされ、ウィルスファイルeicar.comは削除されている。一方、zipファイルはそのままになっている。）
メールヘッダーの関連部分をみると、
X-Virus-Scanned: amavisd-new at myserver.com
X-Amavis-Alert: INFECTED, message contains virus: Eicar-Test-Signature,
Eicar-Test-Signature
X-Amavis-Modified: Mail body modified (defanged) by hostname.myserver.com
(注：ホスト名、ドメイン名、IPアドレスなどは、仮の名前。以下同じ)
ClamdとAmavisdによるウィルスチェックは正常に行われており、受信側も、受け取ったメールの件名、本文から、ウィルスの存在を確認することが可能になっている。
次に、我がメールサーバからISPのサーバへ送信した場合、受信したメールは（Outlook Express上で、eicar.comのアクセスが削除されたのを除いて）、見かけ上変化なし、メールヘッダーについてみると、
Return-Path: <my-account@myserver.com>
Received: from my-account-ocn@hostocn.ocn.ad.jp —-
Received-SPF: none (******.ocn.ad.jp: 192.168.100.211 is neither permitted nor
denied by domain of myserver.com) client-ip=192.168.110.215;
envelope-from=my-account@myserver.com; helo=hostname.myserver.com;
（省 略）
X-Virus-Scanned: amavisd-new at myserver.com
X-Amavis-Alert: INFECTED, message contains virus: Eicar-Test-Signature,
Eicar-Test-Signature
（省 略）
メールヘッダーの関連部分をみると、メールヘッダーを見る限り、ウィルスチェックはきちんと機能しているようだ。ただ、これでは我がメールサーバから送信されたメールを受信した側は受信メールにウィルスが含まれていることに、このヘッダーを見ない限り、認識できない。運用上、あまりいい話ではない。Amavisd-newの設定を変更する必要がありそうだ。
急遽、Amavisd-newの設定を変更、ウィルスを検知してもそのまま送受信するという形式を、ウィルスを検知した場合は、送信を拒否するという設定にしよう。そのため、/etc/amavisd.confファイルの該当部分を以下のように変更：
（変更前） $final_virus_destiny = D_PASS
（変更後） $final_virus_destiny = D_REJECT
これにより、いずれのメールサーバから送信された場合も、送信者あてに「Underlivered to Returned to Sender」とよくお目にかかる送信失敗通知メールを送付されることになった。この通知メールのなかには、ウィルスの存在を知らせる一文があり、送信者もそれに気が付く仕組みになっている。
一連のテスト作業をやるなかで、メールヘッダーにこれまで注意もしていなかったものがあることに気付く。Received SPF: none( — )というヘッダーだ。SPFをIT用語辞典で調べてみると（ここ）、SPFとはSender Policy Frameworkの略で、メールの送信元アドレスの偽装を防止する技術のひとつらしい。これを使うと、我がメールサーバから送信されるメールがスパムではなく正当なものであることを、受信者側に知らせることができそうだ。いろいろ調べてみると、送信側サーバは、DNSのTXTレコードに一行データを書き込めばいいようだ。早速、DNSのゾーンファイルで、TXTレコードを追加、データとして、次の一文を与えた。
v=spf1 mx +ip4:192.168.100.123 ~all
(ipアドレスは仮No.)
結果、我がメールサーバを送信側とし、ISPのサーバを受信側としてメールを送受信し、メールヘッダを確認すると、 Received SPF: PASS( — ) となり正常に機能、対応完了した。
以上が、我がメールサーバのテスト内容の記録、一応、メールサーバとしての機能を、それなりに「安全」に果たすことができそうである。最後に書いたSPFの話、いろいろ、興味深いことに気が付いた。長くなったので、別エントリーにて、このSPFについて思ったこと、メールのセキュリティ問題一般について考えることにしよう。
1 Trackback(s)