RBLとDCCを使ってスパムを排除する
RBLは、既知のスパム発信元およびその疑いのある発信元のIPアドレスを集めたリストである。RBLのサービスを提供するプロバイダは、Spamhaus、Spamcop、DNSRBLなど数多い。RBLにはブラックリスト、ブロッキングリストなどの別名もある。メールサーバは、RBLサーバに接続してIPアドレスをチェックできる。
RBLプロバイダは、次の条件に該当するIPアドレスをRBLに追加する。
- 既知のスパム発信元
- スパムを送信するメールサーバによって悪用されうるオープンなSMTPリレー
- DSLまたはダイヤルアップのユーザの動的割り当てIPアドレスのうち、ユーザのコンピュータがスパム発信の踏み台にされうるもの
- 大量メール送信ウイルスやトロイの木馬に感染したコンピュータのIPアドレス
RBLプロバイダは、IPアドレスのリストを作成する際に、他のさまざまなパラメータも考慮に入れる。IPアドレスの収集には、RBLプロバイダごとに独自のノウハウがある。大量のIPアドレスを積極的にチェックして、疑わしいIPアドレスを抽出するようなことも行われる。
RBLに載せられたIPアドレスが永遠にリストに留まるわけではない。一部のRBLプロバイダでは、一定の期間が過ぎたIPアドレスを自動的にリストから削除する。また、IPアドレスの所有者から削除を要求された場合、リストに追加した理由が既に解消されたと判断されればIPアドレスをリストから外すこともある。簡単にリストから外せるかどうかは、プロバイダによって違う。ときには面倒な手続きになる。
RBLシステムの仕組み
RBLプロバイダでは、リストに記載すべきIPアドレスを見つけると、対応するレコードをDNSデータベースに設定する。たとえば、IPアドレス192.168.1.1をSpamhausのRBLに追加する必要があると判断した場合、擬似ホスト1.1.168.192.zen.spamhaus.orgのDNSレコードを追加する。こうすることで、クライアントはDNSプロトコルを使ってこのIPアドレスを簡単にルックアップできる。
RBLの一種にRight Hand Side Black List（RHSBL）がある。RHSBLは、IPアドレスではなくホスト名のリストである。このリストが便利なのは、スパマーがIPアドレスの異なる複数のコンピュータを使っているが、ホスト名が同じ場合である。一般にプロバイダがRBLとRHSBLの両方を提供することはないため、RBLに加えてRHSBLのルックアップも使う場合は、複数のルックアップを行うことになる。
IPアドレスまたはホスト名をチェックする必要があるSMTPサーバは、txt型レコードのDNSクエリを、適切に記述されたホスト名（例:1.1.168.192.zen.spamhaus.org）に対して実行する。応答として返されるレコードには、リストの詳細情報があるURLが格納されている（例:1.1.168.192.zen.spamhaus.org text = "http://www.spamhaus.org/query/bl?ip=192.168.1.1"）。SMTPサーバは、この情報を利用し、適切なエラーメッセージを使って接続を拒否できる。レコードが返されない場合は、該当するエントリがリストに存在しないということであり、SMTPサーバは接続を受け付けることができる。
私は、PostfixでRHSBL/RBLルックアップを設定するために、次の行を/etc/postfix/main.cfに追加した。
smtpd_recipient_restrictions =
reject_rhsbl_client blackhole.securitysage.com,
reject_rhsbl_sender blackhole.securitysage.com,
reject_rbl_client zen.spamhaus.org,
reject_rbl_client bl.spamcop.net
この設定では、Postfixサーバは受信接続のホスト名とIPアドレスを4つのRBLにルックアップし、該当するエントリがある場合に接続を拒否する。
上記のコードをPostfixサーバに実装したところ、RBLルックアップの結果に基づいて全接続の約75%が拒否されるようになった。
メールサーバの管理者にとって福音のようだが、この方式には負の側面もあり、警戒を怠ってはならない。IPアドレスがRBLに記載される理由はさまざまだ。記載されるべきでないIPアドレスが含まれていることもある。このような事態が起こるのは、たとえばRBLプロバイダが個々のIPアドレスではなく一定の範囲のIPアドレス（アドレスブロック）を一括して追加したようなケースだ。これは、その範囲内の多数のIPアドレスがリスト記載の条件を満たす場合に起こりうる。メールサーバの管理者は、このような可能性を常に念頭に置いて、サイトのポリシーに基づいて十分に検討を行い、RBLのみに基づいてSMTP接続レベルでIPアドレスをフィルタ処理するかどうかを決める必要がある。
SpamAssassinを使ったRBLルックアップ
SpamAssassinは、利用者の多いスパム撃退アプリケーションで、GPLライセンスに基づいて配布されている。SpamAssassinでは、多数のローカルベースおよびネットワークベースのチェックに基づいて電子メールメッセージを評価し、スコアを付ける。管理者は、このスコアを基にメールをスパムとして扱うかどうかを判断し、適切な措置（メールの破棄、スパムのマーク付け、別のフォルダへの転送など）をとることができる。
RBLルックアップを評価ルーチンの一部として実行するようにSpamAssassinを設定できる。この方法は、RBLのヒットのみを根拠にSMTP接続を拒否する方法よりも穏当である。
そのためには、RBLルックアップを以下のようにSpamAssassinの設定ファイル（/etc/mail/spamassassin/local.cf）に追加する。
skip_rbl_checks 0 # This is the default and enables lookups rbl_timeout 15 # Timeout for lookups in seconds
また、SpamAssassinでは、RBLルックアップで一致するエントリがあった場合、それを示すヘッダーがメッセージに追加される。メールがスパムであることを示すため、[SPAM]などのタグが件名に追加される。ユーザは、このようなメッセージをIMAPサーバまたはメールクライアントの別のフォルダに振り分けることができる。
Distributed Checksum Clearinghouse
メールサーバ管理者にとって残念なのは、スパマーがいつも同じホストを使ってスパムメッセージを送信するとは限らないため、RBLルックアップが空振りに終わる場合があることだ。しかし、SpamAssassinでは、Distributed Checksum Clearinghouse（DCC）と呼ばれるネットワークベースのルックアップを使って、メッセージが大量に出回っている既知のメールかどうかを識別できる。
DCCサーバは、特定のメッセージがデータベースでルックアップされた回数をカウントする。サーバにはメッセージ全体ではなくメッセージのチェックサムだけが保存される。クライアントは、ルックアップするメッセージのチェックサムを生成し、これをDCCサーバにクエリする。DDCサーバは、そのチェックサムがルックアップされた回数を返す。クエリの回数がしきい値を超えると、カウントは”多数”に分類される。DCCの仕組みにおいて、クライアントはデータに積極的に寄与する。転送されるのはチェックサムだけなので、通信のプライバシーが侵害されることはなく、ルックアップのオーバーヘッドは最小になる。
DCCは、ほとんどのアンチスパムツールに統合できる。SpamAssassinのlocal.cfに次の行を追加する。
use_dcc 1 dcc_home /var/dcc dcc_path /usr/local/bin/dccproc add_header all DCC _DCCB_: _DCCR_
特定のアドレスやドメインからのメールをチェックの対象外にする場合は、次の行をlocal.cfに追加すればホワイトリストを作成できる。
whitelist_from somebody@example.com somebodyelse@example.com whitelist_from *@example.com
RBLとDCC以外にも、スパムに対抗する手段はある。メールコンテンツに既知のパターンを探すとか、メールヘッダの特徴を分析するなどの方法でもスパムを検出できる。
メールサーバやSpamAssassinのアンチスパム設定は、一度やってそれで終わりとはいかない。管理者は、新しい脅威を迎え撃つために常に警戒し、コース修正に努める必要がある。
