Tweet

今日は一日メールサーバーがパンク状態になっていた。

JRA-NETのメールサーバーをご利用の皆様には接続しにくい状況が続き、大変ご迷惑をお掛けしましたことをお詫び申し上げます。

今日のパンクの原因は大量のスパムだった。
ここ最近は数が減ってきていて安心していたが、何故か今日は嵐のごとく大量のスパムが届いている。
サーバーにSSHで入ってログファイルをtailすると画面上は残像しか見えない．．．

届いているスパムは実在するメールアドレス宛ではなく「kkvvbmdraqtdhcr＠jra….」といった機械的にアカウント名部分を生成して送りつけてきているモノが90％以上なので、実際にメールボックスへ届くメールは非常に少ない。

しかし、SMTPサーバーはせっせとDBにメールアドレスが正しいか問い合わせて、結果を接続元に返している。
大量のアクセスが集中するのでDBへのコネクションが限界を超えてビジーが発生し、結果としてSMTPサーバーは動作が停滞。停滞しているのに次から次へとアクセスが入ってくるので待ちが待ちを呼ぶ形になりパンクしてしまっていた。

改めてエラーの状況を詳細に見てみると行儀の悪いスパムと行儀のいいスパムが居る事が解った。
行儀のいい奴はエラーを返すとサッサと接続を切って居なくなる。
しかし、行儀の悪い奴はエラーを返してもお構いなしにメールを送りつけようとしてくる。
具体的には RCPT TO で6件程の宛先を通知してくるが、全てエラーを返しているのに DATA を送ってくる。
応答コードなんかお構いなしで我が道を行くって感じ。
もう少しインテリジェンスに作って欲しい。

あと、RCPT TOに対してエラーを返すとフリーズする奴もいる。
250 OK が返ってこないと何をしていいのか解らないらしい (^_^;
結局タイムアウトで接続を切っているが、それまでフリーズしてやがるからタチが悪い。
エラー処理はちゃんと入れておいて欲しいもんだ。

で、こんな奴らが大量に来るのを捌かなければいけない。
結局やった事はDBコネクションのパフォーマンス改善。
まずはPostgreSQL側の同時接続数を可能な限り増やしてやる。
ただ、サーバーはそれなりに古いのでメモリーはそんなに多くない。（と言うかマザーボードが対応しきれない）
と言う事でシェアードメモリーがそんなに確保できないので、たいして同時接続数は増やせなかった。

困った．．．

続いて考えたのはPostfix側が適宜接続を切ってくれないかなという事。
Postfixのsmtpdはプロセスがデフォルトで100個まで立ち上がる。
こいつらがコネクションプールを使ってPostgreSQLと繋がったままで居ようとするので溢れてきてしまう。
ただ、大量にメールが届く状況でコネクションのOPENとCLOSEを繰り返すのはオーバーヘッドが大きいだろうから現実的では無さそうだし、いちいち接続を切るような設定が出来そうにもなかった。

とりあえず急場しのぎでプロセスの最大数を減らしてみたが効果は薄かった。

あれこれ対応策を探しているうちにPostfixにPROXYMAPなる機能が有る事が分かった。
PROXYMAPを使うとプロセス一個一個がDBに接続するのではなくPROXYMAPが一括してDBに接続してクエリーを実行し、それぞれのプロセスに結果を返してくれるのでDBへの同時接続数を劇的に減らしてくれるらしい。

と言う事で設定をしてみた。
元々
virtual_mailbox_maps = pgsql:/etc/postfix/pgsql-virtual_maps.cfとなっている所を
virtual_mailbox_maps = proxy:pgsql:/etc/postfix/pgsql-virtual_maps.cfとするだけでOK。
PROXYMAPを使って動かしてみると、プロセス数のMAXはデフォルトの100個になっていてもPostgreSQLへの接続は10個くらいが動いているだけ。
それでも問題なく捌いてくれている。
相変わらずログをtailするともの凄い勢いで流れていて文字は判読できないけど．．．

と言う事で、これで解決かなと思っている。
（2時間程流しているけどビジーは出てない）

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は逆引きの設定をしていない所が多いので、不明リストに埋もれているだけかもしれないが．．．

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