Tweet

いよいよメールサーバー入れ替え実験も最終局面へ。
前回、PostfixがPostgreSQLで管理されたアカウント情報でメールを受信できるようになったので、残るはDovecotでもPostgreSQLで管理されたアカウント情報でPOP3/IMAP4を使ったメール受信とSMTP認証を可能にしてやる事にする。

Dovecotの設定サンプルにSQLを使った認証のものが用意されているのでコピーして使う
# cp /usr/local/etc/dovecot-sql-example.conf /usr/local/etc/dovecot-sql.conf
コピーしたファイルの編集内容は
driver = pgsql
connect = dbname=postfix user=postfix password=*******
default_pass_scheme = PLAIN
password_query = SELECT login_id AS user, password FROM virtual_maps WHERE login_id = '%u' AND status_flag = 1
user_query = SELECT '/var/mail/' || maildir AS home, 10000 AS uid, 10000 AS gid FROM virtual_maps WHERE login_id = '%u' AND status_flag = 1といった感じ。

default_pass_scheme を PLAIN にしたのは理由がある。
通常はここをmd5などにしておいて、認証時に暗号化したパスワードでクライアントとサーバ間の通信をさせたいが、DB上のパスワードが暗号化されていると同じ暗号化方式の認証しか利用できなくなり汎用性が低くなる。
しかし、DB上のパスワードを平文で保存しておくことで通信時の暗号化方式に幅が出て、多くのクライアントと通信が可能になる。
パスワードの通信方法を制限したい場合はdovecot.confの認証メカニズム指定で制限をかける方が現実的だ。
また、Outlook ExpressはSMTP認証にLOGIN認証しか使えなかったりするのでcram-md5しか使えなくなると接続できない。
まぁ既に開発が終わってサポートも無くなるソフトなんで使わない方がいいのだが、古いWindowsは未だに現役だししょうがない。
Windowsメールになるとmd5を使った暗号化にも対応しているので、乗り換えが進むといいのだが。

続いて /usr/local/etc/dovecot.conf の編集を行う。
auth default {
　mechanisms = plain login cram-md5 apop
　passdb sql {
　　# Path for SQL configuration file, see doc/dovecot-sql-example.conf
　　args = /usr/local/etc/dovecot-sql.conf
　}
　userdb sql {
　　# Path for SQL configuration file, see doc/dovecot-sql-example.conf
　　args = /usr/local/etc/dovecot-sql.conf
　}
}編集箇所を抜粋するとこんな感じ。

パスワードとユーザー情報の確認にSQLを使えるようにしたのと、認証メカニズムにcram-md5とapopを追加した。
cram-md5とapopはDBで管理するユーザーについてのみ有効なことに注意。
OSのユーザー情報のパスワードはhashで暗号化されている。hashは不可逆な暗号化方式なのでmd5で暗号化されたパスワードと比較が出来ないのでOSのアカウントで管理されているユーザーはPLAINかLOGIN認証でしか認証できない。
パスワードの安全性を考えるならメールアカウントはOSのアカウントと分離して管理し、パスワードを暗号化して送信させるか、POPやIMAPの通信自体をSSLで暗号化するのが良いだろう。

Dovecotを再起動し、POP3、IMAP4でメールが受信できることと、SubmissionポートでSMTP認証が使えることを確認できれば完了。

Tweet

実運用に向けて実験を行っているが、アカウント管理などの正規ユーザーのアクセスに対する実験の目処が立ってきたので、そろそろとスパムメール対策など招かざる客の扱いについても調べ始めた。

Postfixの初期設定は中々良くできていて、不正中継に利用されるようなことは殆ど無い。
実際に不正中継のテストが出来るサイトを使ってテストを行ってみたが、全てのテストをパスしたので、この後間違った設定をしない限り自サイトが悪用されることは無いだろう。

次に問題になるのは自らが管理するドメイン宛に送られてくるメールで、受け取る必要のないスパムメールに対する対策である。
現在運用中のSendmailでは、悪質と思われるサイトからのアクセスを個別に接続拒否するようにしているが、まぁブラックリストのメンテが大変だったりする。

Postfixでのアクセス制御について調べてみると、接続時→HELOコマンド→MAIL FROMコマンド→RCPT TOコマンドと、それぞれの段階でチェックが実施できるようになっている。
ブラックリストを作ったり、正規表現を使ったパターン認識を行ったりと柔軟な設定が可能なようなので、うまく組み合わせをして対策を行っていくようにしたい。

で、対策を施すには敵を知ることも大事なので、今のアクセス状況を調べてみた。
それも、Postfixのテストを行っているサーバのアクセス状況を。
Postfixのテストを行っているサーバは、当サイトのドメインでもある jra.net のセカンダリメールサーバになっている。
通常のMTAであればプライマリサーバが正常に動作していればプライマリサーバへアクセスしてメールを送ってくるが、ちょっと賢いスパムメールの送信者はセカンダリサーバへ送ってくる事が多い。
理由はセカンダリサーバは中継を行うだけでアカウントが存在するかなどチェックを行わない（行えない）から高速にメールが送れるからだ。（他にも理由はいくつかあるがスパム送信を助長させてもしょうがないので詳しくは書かないことにする）

だから、プライマリサーバが正常稼働している時にセカンダリサーバにアクセスしてくる奴は、かなり高い確率でずる賢いスパム送信者だと見ていい。

実際に、ある一日のPostfixのログから接続情報を拾ってみた。
まず、1日の間に何回接続要求があったかというと 23,709回 の接続要求があった。結構多い・・・
サーバのリソースが無駄に消費されている事がよく分かる。

接続元のドメインを調べていくと、流石にOP25Bが普及している日本国内からの接続要求は少ない。
日本国内からの接続要求は固定IPが割り振られていると思われるホストからのアクセスが殆どなので、どちらかというとスパム送信を生業としている人達だろう。

ホスト別の接続回数を集計してみると面白い傾向が見られた。
まず、スパムを送信しているホストの数は15,000程あった。
その内、一つのホストから大量に送信しているのは、なんと2つしかない。
この2つのホストはスパムの送信を自ら行っている可能性が高い。
と言うのも、上位2サイトは100回ほど接続してきているのに対して、他のサイトは殆ど1～5回程度しか接続していない。
そして、どんなに接続回数が多くても30回を超えていない。
きれいに30回で止まっている。30回接続してきたホストの数は70程だった。
これは、かなり良くできたスパム送信のためのボットネットによる送信だと考えられる。

ボットネットはウイルス感染したパソコンを利用し、スパムの送信やDoS攻撃などを行うためのモノ。
ボットネットに対して動作の指示を送る指令者が特定しにくいことから、非常に厄介な存在だったりする。
以前、知り合いから最近パソコンが妙に遅くなったので見て欲しいと言われ見に行ったら、見事ボットウイルスに感染していてパソコンが勝手にスパムメールをせっせと送信していたという事があった。

接続元になっているホストはウイルス感染したパソコンである可能性が高いので、TLDを調べてどこの国が多いのか調べてみた。
まず、半数はDNSの逆引きが設定されなかったので不明となったが、ccTLDが分かった中では一位がブラジルだった。
TLDが判明したホストの約25％がブラジルでダントツのトップだ。
次のccTLDはタイで約7％、後は差が少ないがロシアも比較的多い方で新興国と言われる地域が多い印象。
パソコンやインターネットが普及してきて、比較的高性能なPCと高速なインターネット接続回線があることがウイルス感染を広めているのではないだろうか。

あと、ホスト数が多いのはヨーロッパ、イタリアやドイツが上位に入っている。
先進国ではセキュリティー対策がしっかりしているかと思ったが、案外とそうでもないようだ。

意外だったのは中国がとても少ないこと。
TelnetやSSHへのアタックのログを見ると圧倒的に中国からのアクセスが多いのに、スパムについては少なかった。
ただ、中国のISPは逆引きの設定をしていない所が多いので、不明リストに埋もれているだけかもしれないが．．．

とりあえずは面白い結果と共に、接続元のパターンが見えてきたので対策の参考にしよう。