電子メールのセキュリティ問題


目次

はじめに
電子メールの設定計画

一つ前へ


はじめに

 電子メールを配送するサーバは、攻撃の対象になる可能性がもっとも高いシステムの1つです。その理由は、稼働台数が多く、しかも攻撃に成功したときの影響が大きいからでしょう。
 インターネットでは、膨大な数の電子メール配送サーバが稼働しています。ということは、攻撃対象になりうるサーバの数も膨大であり、そのぶん攻撃する側にとって都合のよい状況だといえます。
 たとえば、新しい攻撃方法をみつけた(みつかった)場合、1つの方法で多数のサーバに影響を与えることができます。つまり、"1粒で2度おいしい" どころか "1粒で10万回おいしい" のです。その攻撃の防護策(パッチなど)が開発されたとしても、それがすべてのサーバに適用されるまでにはかなりの時間がかかります。攻撃する側からいうと、適当にしらみつぶし的な(下手な鉄砲も数打ちゃ当たる式の)攻撃を繰り返せば、いつかは対策を施してないサーバが見つかる可能性があります。日本でもこの方法による sendmail への攻撃がおこなわれました。
 攻撃に成功した場合の影響が大きいのも、攻撃者の標的になりやすい要素といえます。たとえば、メール配送サーバには管理者権限での動作を要求するものがあります。このようなサーバに対する攻撃が成功すると、管理者権限が盗まれる可能性がきわめて高くなります。計算機に侵入したあと、バックドアを仕掛けるときに利用されるおそれもあります。

◆予期しないメール中継

 現在、設定の不十分なメール配送サーバを悪用する攻撃が世界的に多発しています。この攻撃はメールの配送経路を隠すためにおこなわれ、もちろん、オリジナルの発信元にも偽の情報が書かれています。その多くはおもに SPAM を配信する手段として用いられていますが、メール爆弾やいやがらせ、いたずら目的に使われることもあるようです。
 とくに SPAM については、米国では連邦議会でとりあげられたり、訴訟が起こされるなど社会問題になっています。日本ではまだそれほど深刻な事態にはなっていないようですが、このまま対岸の火事で終わるとは思えません。
  SPAM を受け取るユーザも被害者ですが、より大きな被害を受けるのはむしろ SPAM の中継に悪用された計算機とその管理者です。ほとんどの SPAM には、なんらかの宣伝文句が書かれており、しかもメールを見ただけでは精確な発信元は分かりません。せいぜい、「もしかしたら、こいつか?・・」と推測できる程度で、いわば差出人不明のダイレクトメールです。
 インターネットの電子メール規則では、そのメールが経由した経路の情報がメールヘッダに記録されることになっています。したがって、通常はその記録をみれば、メールを送信した計算機と日時、中継したサーバの情報と日時、最終的に自分のメールサーバが受信した日時が分かります。ところが、経路途中のメール配送サーバの設定が不十分だと、その記録が改竄される可能性があります。そのような設定の不十分さが SPAM 中継に悪用されてしまうのです。一般に、 SPAM では何万ないし何十万通のメールが送信されます。また、その宛先はかならずしも実在のアドレスとは限りません。すでに解約されたアドレスや、機械的に適当に生成したアドレスに送られる可能性もあります。
 サーバが SPAM 中継に悪用されると、次のような被害を受けるおそれがあります。

●CPU資源の消費
●ネットワーク資源の消費
●大量のエラーメールの受信による
     −CPU資源の消費
     −ネットワーク資源の消費
     −ディスク資源の消費
     −サーバ計算機の異常停止
     −postmaster の作業時間の浪費
●他サイトからの避難
     −SPAMメール発信者と誤解される
     −メール配送サーバの設定の甘さを指摘される
     −悪評がひろまる
     −非難メールへの対応によって、精神的なダメージを受ける

さらに、次のような被害を受けることもあります。

●実際は他サイトの計算機を悪用しているにもかかわらず、メールヘッダの From 行に自分のサイトのドメイン名を使われる
     −大量のエラーメールを受け取る
     −SPAM メールの発信者と誤解され、非難のメールを受け取る
     −悪評がひろまる
     −精神的なダメージを受ける

 たとえ SPAM メールの宛先が海外であったとしても、メール中継に利用されるサイトは送信元や送信先とは無関係です。とくに、現在はネットワーク経由でアクセス可能なメール配送サーバを起動した瞬間から攻撃される危険性があることに注意してください。
 この問題は、不正中継を防止する機能をもつサーバ・プログラムを導入し、さらに不正中継を防止する設定をおこなうことで解決できます。

◆電子メール配送プログラムへの攻撃

 サーバ・プログラムに存在するセキュリティ上の弱点が悪用され、外部から侵入されたり、計算機上のファイルを盗まれたり、最悪の場合は計算機上の管理者権限を盗まれることもあります。
 JPCERT/CC(コンピュータ緊急対応センター) から、日本でも sendmail に対する攻撃がきわめて広範囲にわたっておこなわれたという報告が出ています。この報告は、http://www.jpcert.or.jp/info/97-0001/から入手できます。
 この報告によると、攻撃は1996年末から1997年の年始にかけて、sendmail の旧いバージョンであるR5を狙って無差別におこなわれたようです。この攻撃に使われたのはまさしく "古典的" な手法の1つで、(そんなものがあるとすれば)クラッカー学校の歴史の教科書に載るようなものでした。もちろん 、その攻撃への対策も以前から公開されていますし、現在ひろく使われている sendmail8.x.x では成功しません。そのようなことがあっても被害状況の詳細は明らかではありませんが、わざわざこのような手法が使われたのですから、その程度の攻撃にさえ対処できないサイトがあるのは間違いないでしょう。さらに、古典的ではあっても、以前としてそのような手法が利用され、今後も使われ続けるであろうことは想像に難しくありません。
 この件に関して JPCERT/CC が発行した「緊急のお知らせに関する届け出件数」を見ると、日本のインターネットでも大規模な不正アクセスがおこなわれていることがはっきり分かります。これまでセキュリティに関心のなかった人たちに警鐘を鳴らす意味では、よい教訓になったかもしれません。
 sendmail については、これ以外にも過去いくつかのセキュリティ・ホールが発見されています。これらに関しては、米国の CERT/CC から下記の CERT Advisory が発行されています。なかには、攻撃に成功すると管理者権限を盗まれるものもあるので、旧いバージョンの sendmail を使用している場合は、これらの Advisory を読むことをお勧めします。

●CA-96.20.sendmail_vul
●CA-96.24.sendmail.daemon.mode
●CA-96.25.sendmail_groups
●CA-97.05.sendmail
●CA-98.10.mime_buffer_overflows

 sendmail のセキュリティ上の問題の大半は、sendmail を最新版にアップグレードすれば解決できます。



電子メールの設定計画

 電子メールを導入する前に、電子メール環境の設定について計画を立てます。

◆電子メール受信の可否

 ファイアウォール外部から内部へ電子メールの配送を許可するかどうかを決定します。
 電子メールを使うからといって、かならずしもファイアウォール内部の計算機でメールを受信する必要はありません。
 メール配送サーバを運用するには、それなりのコストとリスクが発生します。サーバ運用のコストには、サーバ計算機の運用や設定ファイルの記述・変更にともなう労力、ユーザからの苦情に対応する手間などがあります。一方、リスクとは、セキュリティ的なリスクはもちろんのこと、ハードウェア障害によるメールの消失も考えられます。
 これらのコストやリスクにみあうメリットが本当にあるのかどうかを十分に検討し、外部のネットワークからのメールを受信するかどうかを決定します。

 「自分宛のメールは自分の手許に配送してほしい」

という希望が強ければ、ファイアウォール・ホスト上でメール配送サーバを運用し、外部からのメールを受信できるようにします。そして、ファイアウォール・ホストが受け取ったメールをファイアウォール内部の計算機に再配送するように設定します。さらに、ファイアウォール・ホストから再配送されるメールを受け取るサーバを内部に設け、これを内部のメールサーバ・ホストとして設定します(図1)。

 一方、

「メール環境を自分のところで運用するのは面倒だからやめよう」

と決めた場合は、自組織のネットワークには外部からメールを受け取るサーバを設けません。ユーザは、ほかのネットワーク上の計算機にログインし、その計算機上でメールを読むことにします(図2)。この方法では、ファイアウォール・ホスト上で内部から外部への telnet を中継するプロキシー・サーバを運用する必要はありますが、作業面ではもっとも簡単です。

「Windows ユーザがいるから、ログインは無理。それに、メールのスプールはほかのネットワークにあってもいいけど、自分のメールボックスは手許にあってほしいなぁ」

という希望が強いなら、ほかのネットワーク上のメールスプール・サーバからPOP(Post Office Protocol)を用いてメールをダウンロードする方法が考えられます(図3)。

ファイアウォール・ホスト上で、POPの通信を中継するプロキシー・サーバを運用する必要がありますが、この方法も作業的には簡単です。

「セキュリティ的なリスクを負うのは嫌だけど、自分宛のメールはやっぱり手許に配送してもらわないと」

 ちょっと手間はかかりますが、この方法も実現できます。外部のメールスプール・サーバからPOPでメールをダウンロードし、そのメールを内部のメールスプールに書き込みます(図4)。

 通常のPOPクライアント・プログラムは、ダウンロードしたメールをユーザのメールボックスに書込みますが、 fetchmail や popclient を利用するとダウンロードしたメールをメールスプールに書き込むことができます。しかし、あくまでPOPなので、外部からメールが配送されるわけではありません。内部から、一定時間おきにこれらのプログラムを実行する必要があります。しかし、電子メールにはリアルタイム性を求められないので、大きな問題は生じないでしょう。この方法を利用する場合、ファイアウォール・ホスト上では、POPの通信を中継するプロキシー・サーバを運用する必要があります。
 POPを使用する方法では、外部からメールを受信する必要がありません。したがって、サーバを不正中継に利用されたり、サーバの遠隔操作による攻撃(外部からの侵入など)を受けたりする可能性がなく、かなりお勧めです。しかも、停電などで自サイトのサーバが停止している間も、外部のメールスプール・サーバがメールを受信してくれるので、MX(Mail eXchanger) がどうのこうのと心配する必要もありません。さらに、メールスプール・サーバに障害が起きても、こちらの責任ではないので堂々と文句を言うことができます。もちろん、メールスプール・サーバは、信頼のおけるところを選ばなければなりませんが、現在ではこの種のサービスを提供しているISP(Internet Service Provider) もあるようです。このようなサービスの利用も、1つの選択肢として検討する価値は十分にあるでしょう。

◆電子メール受信の可否

 電子メールの内部から外部への送信を許可するかどうかを決定します。
 メール送信にもコストとリスクが発生します。受信用のサーバと同じく、サーバ計算機の運用や設定ファイルの記述・変更にともなう労力、ユーザからの苦情に対応する手間などがあります。さらに、ユーザのミスによるエラーメールを見て、ユーザに教育的指導をおこなうなどの対処も必要です。
 リスクについては、外部へのメール送信を許可しても、システムが外部から侵入されるといった危険性は低いでしょう。むしろ情報漏洩などのリスクが高くなると考えられますが、これはメール以外の手段もたくさんあるので、電子メールだけを禁止してもあまり意味がないと思います。ただし、外部からなんらかの方法でコマンドを送り込み、内部の計算機上のファイルを外部にメールで送信するような攻撃は、From が "root" や "daemon" であることが多いので、これらのメールをフィルタリングすれば、ある程度は未然に防げる"かも"しれません(もちろん、防げない可能性もあります)。
 その他のリスクとしては、設定ミスによるメールの紛失や規格違反のメールの送信などが考えられます。メール紛失の事故はかなり時間が経ってから発覚することが多く、とくに仕事上重要なメールの場合は冷や汗ものです。おかしなヘッダが付いたメールが送信されることもあります。これは外部からの指摘で気づく場合が多いので、大恥をかくこともあります(恥だけですめばマシかもしれません)。
 ファイアウォールの内部から外部へのメール送信を許可しない場合には、当然のことながら、ユーザは外部の人にメールを送れません。このようなときは、外部のネットワーク上の計算機にアカウントを用意し、その計算機上でメールを書く方法が考えられます。
 メール送信を許可する場合は、ファイアウォール・ホスト上でメール配送サーバを運用し、内部からのメールを受信して、それを外部のサーバに再配送するように設定します。

◆メールサーバを運用する計算機

 メール送信の可否にかかわらず、ファイアウォール内部の電子メールの送受信を集中的におこなうサーバを用意します。さらに、このメールサーバが、ファイアウォール内部のドメインのMXとなるようにDNSに設定します。
 メールサーバは、ファイアウォール内部の計算機からメールを送信し、それを内部のユーザのメールスプールに書き込むか、あるいは、ファイアウォール外部に再配布します。外部へのメール送信を許可していない場合は、エラーとします。
 メールサーバは、メールの送受信という重要なサービスを提供します。ですから、誰かの端末と化している計算機や、よくリブートする計算機などではなく、安定して稼働し続ける計算機を割当てます。計算機資源に余裕があるのなら、メールサーバ専用ホストとして運用したほうがいいでしょう。
 ユーザ数や電子メールの使用方法などにもよりますが、ディスクは容量の大きいものを用意しておくとよいでしょう。とくに Windows のメール用ソフトウェアは、別のファイルを簡単にメールに取り込めるので、かなり大きなサイズのメールを送信するユーザが多いようです。メールスプールのディスクが容量不足になると、メールが受信できなくなります。容量不足は気づきにくいので、メールスプールは大きめに確保しておきましょう。

◆sendmailのコンパイル

 旧いバージョンのsendmailを使用している場合は、バージョンアップをお勧めします。sendmailのバージョンを確認するには、sendmailコマンドに下記のような引数を指定して実行します。

sendmail -bt -d0.4

 これでバージョン番号が表示されない場合は、間違いなく旧いバージョンなので、これを機にバージョンアップしましょう。
 sendmail のインストール方法については、次のURLから得られる JPCERT/CC の「sendmailバージョンアップマニュアル」を参照してください。

 ●http://www.jpcert.or.jp/tech/98-0001/


一つ前へ