0. 前書き
メールサーバが順調に動き出してくると、何処から臭いを嗅ぎ取ったのか、挙動不審なアクセスが次第に増えてくる。 幾らブログを書こうとも、なかなか読者は増えないものだが、餌食になるものを探す捕食者は、個人宅の奥の奥に潜んでいるメールサーバを割り出すのであるから、大したものである（苦笑）
今日などは、サーバログの流れを追ってみると、特定の IP アドレスから、どうも、「良くあるユーザ名リスト」 的なものを使用したチャレンジ要求が頻繁に入ってきている。「何故解かるのか？」 と言えば人名がアルファベット順だからである（爆笑）
しばらくすると、アドレスが他に切り替わったりするが、人名は引き継がれる。しばらく前までは 「laura」 「luis」 「julia」 でここのところは 「marco」 に 「maria」。その後しばらく休止していたと思ったら今度は 「martin」 に 「melissa」♪
まあ、デバッグモードで垂れ流しているから、ここまでの情報が見えるわけであるが、そうでなければ見えるのは、auth の Info として吐き出される unknown user だけ…（苦笑）
こんな状況に直面すると、そのまんま東でなくても、やはり 「どげんかせんとあかん！」 となるものである。
一般に 「スパマー（spammer）」 とは、スパムメール（迷惑メール）を送信する連中を指す。確かに迷惑メールの送信は、受信者に取っては迷惑千万であるが、普通こういった連中は、何処からか集めた迷惑メール送信先リストに基づいて送っているだけである。しかし 「悪どい spammer」 ともなると、ブラックリストに載ることを回避するために、他人のメールサーバを不正中継してメールを送信したり、中には、他人のパソコンに不正侵入してスパムメールを配信したりする連中 がいるのである。
迷惑メールを極力刈り取ることも重要であるが、それ以上に脅威なのは、こういうシステムの盲点なり欠陥を探し歩いている連中なのである。今回、筆者が遭遇した連中も、ユーザ ID リストに基づいてアカウントをスキャンし、アカウントの存在が確認出来れば、次はパスワードクラックを企てるのは火を見るより明らか。スパマーというよりは、既にクラッカー (cracker) なのである。
筆者の今回の記事の目的は、前者ではなく、あくまでも後者である。「スパムメール対策」 というと前者のイメージが強いことから、そういうニュアンスで、タイトルも 「スパマーからの防御」 としている。
1. 奴らは、いったい何者？
早速、Whois データベースで調べてみると、そのアドレスの先は、ES（スペイン）であったり、US（米国）であったり、RS（セルビア）だったり、いろいろである。多分、これらのマシンは単なる踏み台だろうから、そこから先は、相手のマシンに入り込むなり、マシン周辺のトラフィックの状況が掴めない限りは如何ともし難い。
では 「常習犯？」 と思い、「DNSBL .Info の Spam Database Lookup」 で、これらの IP アドレスを検索してみると、ほんの一部分ではあるが、幾つかのデータベースで重複的にヒットするのが確認できる。一番良くヒットするのが dnsbl-1.useprotect.net と psbl.surriel.com これに続き ips.backscatterer.org に cbl.abuseat.net が続く。各データベース毎に得意な悪事の専門性が異なるようである。
単純に考えれば、不正中継が可能なメールサーバを探しているようにも見えるが、それならば、ユーザ名のリストベースで総スキャンなど掛ける意味がない。ユーザ名でスキャンを掛けることによって、少なくとも、そのメールサーバで有効なメールアドレスを知ることが出来るが、ウイルスなどを打ち込むためならば、スキャンするまでもなく、root や postmaster あるいは webmaster などを攻めれば足りるはずである。
そう考えると、まずは総当りで、メールアカウントを保有するユーザ名を特定し、特定できたアカウントに対し、今度はパスワードクラックを試みるつもりなのだろう。
そのメールサーバが Unix アカウントベースである場合は、そのマシンにログイン可能なアカウントに一致する可能性も高い。彼等にとって、お宝が出るかどうかはあくまでも、こういった地道な探索の結果なのだろう。
スキャンは実に緩慢である。が、しかし牛歩であってもチャレンジの手を緩めないというのは、これはこれで厄介な話である。弱みが見つかれば、別の手を仕掛けてくる可能性もあるためである。
http サーバに対するロボットの巡回スキャンも気味が悪いが、smtp サーバに対するスキャンは、今回のケースだけを見ても、悪質度はずっと高い。
そういう訳で、ちょっと真面目に smtp サーバの保護手段を検討することにした。
2. 保護対策のあれこれ
2.1 ブラックリスト掲載のサイトからのブロック
Postfix では、RBL （Realtime Blackhole Llist） と呼ばれるブラックリストを使い、これらのデータベースに掲載されている ウイルスやスパムメール配信に関連しているサイトからのアクセスを排除することができる。ブラックリストは、RBL や DNSBL と呼ばれるサイトで運用されており、先に説明した DNSBL.Info にも多くの運営サイトが掲載されている。
Postfix における、これらのデータベースとの照合は、smtpd_client_restrictions ディレクティブに reject_rbl_client 句を使って定義する。以下に例を示す：
smtpd_client_restrictions = permit_mynetworks,
reject_rbl_client dnsbl-1.uceprotect.net, …①
reject_rbl_client rbl.spamcannibal.org, …①
reject_rbl_client psbl.surriel.com, …①
check_client_access hash:/etc/postfix/reject_client, …②
reject_unknown_client, …③
permit
RBL・DNSBL は smtpd_client_restrictions ディレクティブ中で、reject_rbl_client 句 ① で指定されている。
② は、自らのローカル DB にアクセスを許可・拒否するクライアントを規定し、ローカルに排除するメカニズムである。/etc/postfix/reject_client に、スペースをデリミタとして、対象サイトの IP アドレスとフラグ（REJECT又はOK）を記述 (下記例 ④ 参照) した後 postmap コマンドを実行 (例： postmap reject_client) すると reject_client に対応した reject_client.db が作成される。
#/etc/postfix/reject_client
93.62.189.162 REJECT …④
201.151.139.103 REJECT
この方式の難点は、これらのデータベースの照合は DNS 経由で行われており、あまり多くのデータベース参照を行うと性能劣化の要因となることである。このため、比較的アクセス頻度の高いメールサーバの場合は、rsync 等で同期を取りつつ、照合自体はローカルマシンで行うのが望ましい。
また、利用している RBL・DNSBL の稼動状況やデータベースの対象あるいは特徴が現状とマッチしているかについても、定期的に見直すことが望ましい。
このため、ここでは、rbldnsd を導入し、bind9 の named 経由で利用する方法を記しておく。
(1) rbldnsd のインストール
筆者が使用している CentOS6.5 の場合は、pkgs.org でバイナリの rpm ファイル (rbldnsd-0.996b-6.el6.x86_64.rpm) が見つかったので、これをそのままインストールして使用。
(2) ブラックリストのダウンロード
rsync コマンドで、ダウンロードするブラックリストを指定する。rsync は redhat 系のコマンドで、二つの異なるディレクトリ（他ホストも可）間で同期を取るコマンドであり、これを用いてブラックリストの更新を行う。rbldnsd で利用するブラックリストDB の置き場所は自由であるが、ここでは /etc/db 下に rbldnsd のディレクトリを作り、そこに RBL サイト毎に作成する：
rsync -tvPz rsync-mirrors.uceprotect.net::RBLDNSD-ALL/dnsbl-1.uceprotect.net /var/db/rbldnsd/dnsbl-1.uceprotect.net
rsync -tvPz rsync.spamcannibal.org::zonefiles/bl.spamcannibal.org.in.ip4set.rbl /var/db/rbldnsd/bl.spamcannibal.org.in.ip4set.rbl
rsync -tvPz psbl-mirror.surrier.com::psbl/psbl.txt /var/db/rbldnsd/psbl.surrier.com
(3) rbldnsd の設定 （/etc/sysconfig/rbldnsd）
設定定義ファイル (/etc/sysconfig/rbldnsd) を編集し、事前にダウンロードした二つのブラックリストを反映させる：
RBLDNSD="dsbl -r /var/db/rbldnsd -b 127.0.0.1/530 \
dnsbl-1.uceprotect.net:ip4set:dnsbl-1.uceprotect.net \
rbl.spamcannibal.org:ip4set:bl.spamcannibal.org.in.ip4set.rbl \
psbl.surriel.com:ip4set:psbl.surriel.com "
※ rbldnsd は bind とポート530 を通して接続して使用。
(4) bind のゾーン設定
bind9 (named) の構成定義ファイル (/etc/named.conf) に各RBL・DNSBL のゾーンを新たに設定する。bind はポート 53 を使用しているため、bind から rbldnsd との接続はポート 530 を用いるように設定する。例を以下に示す：
zone "dnsbl-1.uceprotect.net" IN {
type forward;
forward first;
forwarders {
127.0.0.1 port 530;
192.168.1.101 port 530;
};
};
zone "bl.spamcannibal.org" IN {
type forward;
forward first;
forwarders {
127.0.0.1 port 530;
192.168.1.101 port 530;
};
};
zone "psbl.surriel.com" IN {
type forward;
forward first;
forwarders {
127.0.0.1 port 530;
192.168.1.101 port 530;
};
};
※ 必要に応じて、options にあるデフォルトの記述の中にある dnssec-enable と dnssec-validation （いずれもデフォルトは yes に設定） を no に修正する。これは、rbldnsd が RRSIG を扱えないためか原因は定かではないが、validation が実行されると、この部分が ”セキュアではない” としてエラー終了する場合があるためである。エラーの場合、ログより、"named: error (no valid RRSIG) resolving '<zone name>/DS/IN': <ip address>#<port> … validating … SOA: got insecure response; parent indicates it should be secure" のようなメッセージが出力される。
※ bind の動作を ipv4 に限定するために bind のオプション定義ファイル (/etc/sysconfig/named) に OPTIONS="-4" を追加しておく。
(5) プログラムの起動・再起動
上記のプログラムを起動あるいは再起動する。rbldnsd や bind (named) が正常に起動されたかどうか。また、正常にブラックリストの読み込みが終了したかや、ゾーン設定が正常に設定されたかどうかは message ログ (/var/log/message) に出力される。
アクセス権限に問題があったり、ブラックリストが破壊されているような場合は rbldnsd から unable open file: Permission denied などのメッセージが出力されているので、その辺りを見直す。この場合は、ゾーンのリロードが頻繁に行われている筈である。アクセス権に問題がない場合は、ブラックリストが不完全である場合も考えられるので、rsync コマンドで再度同期を取り直すか、あるいは、エラーの出ているブラックリストを使用を排除する。
正常に読み込まれている場合は、"ip4set: <rbl・dnsbl name>: … zones reloaded. time … sec, mem arena=xxx free=xx, mmap=xxxx Kb" といった情報が出力されている。
(6) 動作確認テスト (rbldnsd)
上記のプログラムを起動あるいは再起動する。
bind 経由で rbldnsd の検索が出来るかどうか、ドメイン情報探索に使用される dig コマンドを使用する。RBL・DNSBL ゾーン名が dsnbl-1.uceprotect.net の中に、IP アドレス（201.151.139.103）があるかどうかを確認（検索）する場合は次のように入力する （ここで @ 以降は DNS の稼動しているホスト名。-p はポートの指定である。rbldnsd は DNS を元に開発されているため、多分、dig コマンドが利用できるものと推測される）：
dig 103.139.151.201.dsnbl-1.uceprotect.net @127.0.0.1 -p 530
この結果、次のような ANSWER SECTION が表示される場合は、問い合わせた IP アドレスがリスト上にあったことを示す。なお、ヒットしない場合は、ANSWER SECTION が表示されない：
;; ANSWER SECTION:
103.139.151.201.dnsbl-1.uceprotect.net. 2100 IN A 127.0.0.2
上記が正常であれば、bind9 経由でのアクセスに問題がない限りは、Postfix の reject_rbl_client の記述に従って、rbl・dnsbl の検索が動く筈である。実際のスパマの捕捉テストは、出来れば、ブラックリストに実際に掲載されているクライアントであることが望ましい。
その意味でも、この RBL 設定をする場合は、まず、執拗に smtp サーバアクセスしてくる相手が、どのリストに掲載されているかを、先に紹介した DNSBL.Info といった検索サイト等で、そのスパマがヒットする RBL・DNSBL リストを見つけ、それを実装してみるのが一番得策であろうと思われる。
3. その他の保護対策
上記の対策は、不正中継やウイルスの配信、あるいは、スパム配信に適した脆弱なサイトの乗っ取りを画策している悪意のあるアクセスの防止を主眼としているが、これ以外にも、自メールサーバの利用者に対して個別に送信されるスパムのブロックや、自メールシステムが使用しているシステムのバージョンやリビジョン等、悪意のある者からの不正侵入や攻撃に利用可能な詳細情報・付加情報を外部から出来るだけ見えなくすることによって、耐性を高めることも重要になる。
3.1 メールユーザ（クライアント）に対するスパムのブロック
メッセージヘッダやメッセージボディの内容を正規表現その他でスキャンをし、スパムメールを判定する header_checks や body_checks がある。この他に、パターンを重み付けすることで判別する方法があるが、これらは Spamassassin として独立した記事を書く予定であるため、本稿では省略する。
(1) メールヘッダのチェック
(2) メールボディのチェック
3.2 システム詳細情報の隠蔽
(1) SMTP のシステム情報 (Postfix のバージョン表示) を削除する
例： smtpd_banner = $myhostname ESMTP $mail_name
$mail_name を削除すれば Postfix 表示も排除できる。 smtpd のシステム名やバージョン等を見て、処理を切り分けるようなことが（クライアントメーラで）一般的でない限りは、Postfix などのシステム表示は害があれこそすれ無意味。
(2) SMTP の VRFY コマンドの抑止
利用者の存在有無の確認が出来る VRFY コマンドを抑止することで、SMTP セション確立後の 「利用者探索」 を出来ないようにする。disable_vrfy_command = yes に設定する。
(3) O25B (Outbound port 25 Blocking) 対策
これは多くのプロバイダで行われた施策であるので、（仕方なく？）ご存知の方も多いと思われる。旧来 smtp に基づくメールの送信には 25 番ポートが使用されてきたが、これは、自ドメイン外のメールサーバとのやり取り（自サーバと他のメールサーバ間での転送）手段の他、自メールサーバの利用者がメールサーバにメールをアップロードする（サーバ・クライアント通信）手段として用いられてきた。
この O25B 施策において新たに設置された 587 番ポートを、サブミッション（英語では 「提出」 とか、「発信」 「発行」 の意）用のポートとして設置しているが、これは後者を目的とするもの。
サーバ・クライアント間の smtp 通信は（利用するネットワークが様々であることを考慮して）個人認証で発信元を特定すると共に、クライアント・サーバ間でのセキュアな認証手段と通信を確保することを狙っており、もう一方の従来の 25 番ポートは、サーバ間 smtp 通信として、相手のドメインの信頼度や送信メールの送出範囲などの評価や検証を重点的に行うことで、これらが混在することによって複雑に絡む問題を整理したものと言える。
4. 参考
「Postfix のセキュリティ対策 / Server-Config」
「DNSBL server for Postfix」
「Postfix セキュリティ関連設定」
「DNSBL.Info SPAM DATABASE LOOKUP」
「CentOS6 サーバ構築 / Postfix」
補足
(1) uceprotect.net の rbl /dnsbl の取得
rsync による取得が困難である場合には、http://wget-mirrors.uceprotect.net/rbldnsd-all/dnsbl-1.uceprotect.net でアクセスすることにより同様の情報取得が可能。