土曜日, 2月 28, 2009

ホワイトリスト情報の報告が減った

 2007年9月30日に、ホワイトリスト情報の報告が増えたことを述べた。ホワイトリスト情報を寄せてくださる人が増えたのは、S25R方式を導入する人の総数が増えたからに違いない。
 しかし、最近では報告が減った。2009年に入ってからは、1月に1件寄せられただけで、2月には1件も寄せられていない。これはもちろん、善意の協力者が減ったからではなくて、公開ホワイトリストが安定してきたからだろう。
 現在、公開ホワイトリストの登録数は353件である。大規模サイトでは1000件以上になると聞いているが、それには遠く及ばない。それは、報告してくださるのは素のS25R方式を使っている小規模サイトや個人サイトの方がほとんどだからであろう。大規模サイトでは、Rgrey、Starpit、あるいはtaRgreyでホワイトリスティングを自動化していることが多いだろうし、ホワイトリスト情報を報告しようにも数が多すぎて報告が大変だろう。
 とはいえ、公開ホワイトリストが安定してきたということは、メジャーなサイトはほとんど収録できて、小規模サイトにはほぼ十分なものになったと言える。大規模サイトでも、偽陽性判定の頻発を防ぐにはかなり役立つだろう。
 公開ホワイトリストのおかげで、S25R方式はますます使いやすいものになった。ご協力くださった皆様に心から感謝する。
 なお、Rgrey、Starpit、あるいはtaRgreyでホワイトリスティングを自動化する場合も、公開ホワイトリスト(少なくとも、その中のメジャーなサイト)は組み込んだ方がよいと思う。グレイリスティングあるいはタールピッティングによる送達遅れを減らすことができるからである。公開ホワイトリスト中の特にメジャーなサイトとしては、hotmail.com、data-hotel.net、yahoo.com、google.comなどがある。

木曜日, 2月 26, 2009

逆引き名設定サービスが広まってほしい

 固定IPアドレス1個割り当ての接続サービスの場合、逆引き名はISPによって管理されていて、ホスト名に連番を含み、S25Rに引っかかることが多いようである。そのような接続サービスを使ってメールサーバを運用している人にとって、S25R方式はいまいましいものであろう。送信先サイトがS25R方式を採用しているとブロックされてしまう。送信先がS25R方式を正しく運用していればメールがエラーリターンすることはないが、送達が遅延する。送信先がホワイトリスト登録すればそれ以後は遅延しないが、S25R方式を採用する別のサイトへ送る時にはまたブロックされてしまう。に申し出ていただけば公開ホワイトリストに掲載させていただくが、それで送達遅れがなくなるとは限らない。
 自分のサーバがS25Rに引っかかっても、自分が使ったらスパムの阻止にものすごく効果的なS25R方式。それがわかると、人は気持ちが落ち着かなくなるかもしれない。いまいましいけどありがたい――アンビバレントな気持ちという。
 この問題を解決してみんながハッピーになる方法は、ISPがユーザーの希望する逆引き名を設定してあげるサービスを提供することである。それも、追加料金なしで提供されることが望ましい。アクセス元がメールサーバかエンドユーザーコンピュータかを逆引き名から推定する方法がスパム対策として実用的であることは、S25R方式が多くの人たちに支持されることで実証されている。逆引きは設定されていればよいというものではなく、サーバにはサーバらしい逆引き名を付けることが、受信側に警戒されずにただちに信用してもらうためには好都合である。だから、固定IPアドレス1個割り当ての接続サービスでも、ISPが割り振る連番入りの逆引き名でなくユーザー所有のドメイン名を使った逆引き名を名乗りたいというのは、当然のユーザーニーズであろう。ISPには、そのようなユーザーニーズに応えることを考慮してほしい。
 自分のサーバがS25Rに引っかかり、S25R方式をいまいましいと思っている人は、S25R方式に不平を言うよりもむしろ、ISPに対して逆引き名設定サービスを要求して声を上げてほしい。S25R方式は、メールが誤って再送要求でブロックされて不快になる人たちよりも多くの人たちをスパム問題から救った。今さらS25R方式の採用をやめてくれと言っても、採用するサイトの増加は止めようがないのである。
 もしISPが逆引き名設定サービスの提供を検討してくれないなら、それを提供しているISPに乗り換えることを考えてもよい。調べてみたところ、インターリンク逆引きサービスを無料で提供している。

土曜日, 2月 14, 2009

「4xx」は迷惑か?

 「迷惑メール対策サービス「+abmail」」のページに、私への謝辞が書かれている。スパム対策ソフトウェアabmailは、Receivedヘッダを解析してスパム判定する仕組み。送信元がメールサーバかエンドユーザーコンピュータかは逆引き名からかなりの確度で推定できると私が実証したことが活かされているのが、謝辞の理由なのだろうと思う。S25R方式そのものを使うのでなくても、私のアイデアがこうして別の工夫の基礎として役立っていることをうれしく思う。

 ところで、そのページからリンクされている「+abmail — 迷惑メール対策サービス ~ 迷惑メール判定プログラム「abmail」の導入について~」という資料(PDF)には、私とは異なる考え方が述べられている。

 詐称が行い難い箇所とは、主にIPアドレスやその逆引きであるドメイン名ですが、エンドユーザ空間であれば通常ある範囲の動的アドレスであるので、そういったアドレス空間には正当なMTAが設置されていることは稀で、むしろ、ウイルスでボットと化したパソコン、スパマーとの相関が極めて高いことが判っています。こうした点に注目してMTAコネクションで対策を施す手法が既に提案されています。エンドユーザ空間であることをドメイン名から推定して、そこからのメールを拒否応答してしまうのがS25R(Selective Port 25 Rejection)、正当なMTAか否かを判定すべく、再送要求するのがRgrey(S25R & greylisting)、応答遅延するのがStartpit(S25R & tarpitting)、応答遅延と再送要求するのがtaRgrey(tarpitting, S25R & greylisting)という対策方式です。
 このS25R派生の方式は、スパム排除に効果的であることが知られていますが、正当なMTAであることを判定するための資源を正当なMTAに託す、いささか他者に迷惑な方式であることが問題視されています。

 2006年8月8日「リソース負荷」で述べたとおり、送信側が正当なメールサーバであるかどうかを判断できるまで「4xx」(再送要求)を返して(あるいは応答を遅らせて)送信を多少待ってもらうことは罪悪でもモラル違反でもないというのが私の考えである。
 そもそも、「4xx」を返すと送信側に迷惑をかけると考える人は、自サイトから送信したメールに「4xx」を返されたら迷惑だと思うのだろうか。自サイトから送信したメールがすぐにキューから掃けなかったら、自分のサーバのディスク領域がしばらく使われ続けたと怒るのだろうか。再送のためにCPUやメモリが使われたと怒るのだろうか。送信メールがすぐに掃けずに再送を余儀なくされるのは、相手のインターネット接続回線の故障か工事、相手のサーバの故障かメンテナンス、相手サイトの停電などが原因のこともある。その場合も、迷惑を受けたと思うのだろうか。もしそうだとしたら、ずいぶん狭量である。
 「4xx」を返されて迷惑だと思う人は、確かにいるかもしれない。S25Rに引っかかるメールサーバの運用者が、メールを送信した後神経質にログを見て、いつ送達するのだろうかとやきもきするようなケースである。不快になるのは、メールが送達するかどうか心配になるからであって、自分のサーバにリソース負荷がかかったからではないだろう。そのリソース負荷には何の実害もないのだから。そのような人には、私は「のんびり待ってください」と言う。受信側サイトにも都合があるのだから、メールの送達が遅れることはあって当たり前。最終的にリトライアウトした時に対処を考えればよい。
 片や「受信側は、送信側に負荷をかけないように、送信側で発生したメールをただちに吸い込んであげるべきだ」とする“送信側優先”のポリシー、片や「『4xx』で送信が多少待たされるのは許容し合おう」という“相互許容”のポリシー。インターネットの世界でどちらかのポリシーを合意するとすれば、どちらがよいだろうか。送信側優先のポリシーだと、すべてのスパムを吸い込むためにディスク領域をたくさん使う。スパムの可能性が高いと判断しても、万一正当なメールだった場合に送信側に再送を強いないためには、ことごとく受信しなければならないからである。相互許容のポリシーでは、自サイトからの送信メールが送信キューに滞留することがあるが、そのために使われるディスク領域はわずかで済む。一方、スパムの可能性があるアクセスに対して「4xx」を返すことによってほとんどのスパムを受信せずに済むので、受信キューのディスク領域も少なくて済む。つまり、相互許容のポリシーを合意した方が経済的なのである。
 送信側優先のポリシーと相互許容のポリシー。インターネットの世界での合意とまではいかないまでも、どちらが主流となるか。それは明らかに相互許容のポリシーである。相互許容のポリシーを前提としたS25R方式は、付加ソフトウェアが不要で実装も運用も簡単で効果が高いため、送信側優先のポリシーを主張する人よりも圧倒的多数の人たちに支持されているからである(もちろん、Rgrey、Starpit、taRgreyの利用者も合わせればもっと多い)。
 私は、送信側優先のポリシーに立脚してすべてのメールを吸い込むスパム対策システムにも反対しない。しかし、正当な送信側メールサーバに「4xx」を返して負荷をかけるべきではないとする主張にはこう反論する。「あなたは、工夫によって抑制できる不正なトラフィックも無差別に受け入れることによって、インターネットユーザーの共有リソースであるインターネット中継回線に無駄な負荷をかけているのですよ」と。

 なお、「そこからのメールを拒否応答してしまうのがS25R」という書き方は誤解を招く。
「エンドユーザ空間であることをドメイン名から推定して、そこからのメールに対して再送要求を返して受信拒否するのがS25R、再送するメールサーバを自動的に許可するのがRgrey、…」
と書いてくれた方が、より正確である。

 ついでに…

(S25R派生の方式は)また、正当なMTAと同等な応答の実装を、もしスパマーが実現した暁には破綻してしまうことは明らかで、現にそういったウイルスが出現しています。こうした敵に気付かれる手法では、スパマーに次の手を考える余地をすぐさま与えてしまうので、有効性の寿命は短いと言わざるを得ません。
 一方、本手法はそういったスパムと相関の高いエンドユーザ空間からのメールであっても、正当なメールと同様に受信します。設定によってはそのまま棄ててしまうことも可能ですが、スパムである可能性が極めて高いメールを振り分けてしまうという方式を採っていますので、スパマーは徐々に収益が低下していくことしか知り得ないでしょう。

 私の経験では、スパムに対して拒否応答を返し続けた方が、敵がだんだんあきらめてスパムアクセスが減るので得策である。私の自宅のアドレスはwhoisデータベースに露出している。勤務先のアドレスは、過去にwhoisデータベースに露出していたことがあるが、今は露出していない。それにもかかわらず、自宅の正しいアドレスに押し寄せるスパムアクセスは、スパム対策をしていない勤務先に届くスパムより少ない。これは、自宅サイトではスパムが増え始めたころから拒否応答を返し続けてきたことの効果としか思えない。このことは、2006年9月28日「拒絶の効果?」で述べた。
 また、2008年7月20日「信じられない阻止率」で、私の息子へのスパムの着信が2008年3月をピークにその後減ったことを述べた。今では、息子宛のスパムアクセスは月10回ほどと少なくなっている。これも、拒否応答を返し続けたことの効果だろう。
 当然ながら、スパムアクセスの総数が減れば、防御をすり抜けるスパムも減る。それだけユーザーはハッピーになる。
 スパムアクセスに対して「450 S25R check, be patient」という拒否応答を返すのは“敵に気付かれる手法”ではあろうが、当分は気にする必要はない。敵がS25Rを攻略するには、メールサーバを経由するか、脆弱なサーバを侵害するか、ボットに長時間リトライさせるしかなく、いずれにしても大量スパム配信にはコスト高な方法をとらざるを得ないからである。

金曜日, 2月 13, 2009

日本語のスパムをbody_checksでブロック

 「洗練された英文ライティングを実現!」という文で始まる日本語のスパムが2通着信した。2通目の着信は2月10日11時13分。前回述べた、多数のボットからの連続するスパムアクセスと時を同じくしていた。それらの連続するスパムアクセスの送信者アドレスのユーザー名は、「Sakuma.Mako」、「gotou.masato」など日本人の名前だったので、着信したのと同じ文面の日本語のスパムを送り込もうとしたものと思われた。
 この調子では、多数のスパムアクセスが来るうちにまたS25Rがすり抜けられそうだと思ったので、body_checksでブロックすることにした。
 着信した2通のスパムは、送信者アドレスはもちろん、サブジェクトも異なっていた。また、HTMLパートが付いていたが、そこに含まれるURLも異なっていた。変わらないのは本文の文章だった。サーバに残したままのメールを、サーバにログインしてmailコマンドで見てみたら、最初の「洗練された英文ライティングを実現!」という文が次のようにquoted-printableエンコーディングで符号化されていることがわかった。

=1B$B@vN}$5$l$?1QJ8%i%$%F%#%s%0$r<B8=3D=1B(B!

 main.cfファイルには

body_checks = regexp:/etc/postfix/body_checks

と書いておき、body_checksファイルに次のように書き込む。正規表現で特別な意味を持つ記号の前に「\」(JISローマ文字セットでは円記号)を挿入すればよい。

/=1B\$B@vN\}\$5\$l\$\?1QJ8%i%\$%F%#%s%0\$r<B8=3D=1B\(B!/ REJECT

 quoted-printableエンコーディングはあまりメジャーではなく、たいていのメーラーでは7bitエンコーディングで送信される。だから、誰かがこのスパムを引用して「こんなメールを受けたんですけど」と問い合わせるメールを送ってきたとしても、上記の拒否条件にマッチするおそれはあまりない。
 この作戦は見事成功。S25Rに引っかからないホストからのスパムを2通ブロックした。

Feb 12 02:04:11 reject: body            =1B$B@vN}$5$l$?1QJ8%i%$%F%#%s%0$r<B8=3D=1B(B! from wireless.netibr.com.br[200.195.40.69]; from=<MeshizukaHimiko@***.info> to=<deo@gabacho-net.jp> proto=SMTP helo=<[200.195.40.69]>: 5.7.1 message content rejected

Feb 12 02:13:01 reject: body            =1B$B@vN}$5$l$?1QJ8%i%$%F%#%s%0$r<B8=3D=1B(B! from cmi.milacron.com[216.68.248.2]; from=<Sugita.Anna@***.org.ua> to=<deo@gabacho-net.jp> proto=SMTP helo=<cmi.milacron.com>: 5.7.1 message content rejected

水曜日, 2月 11, 2009

手ごわいスパム攻撃

 受信拒否されたら別のボットから送信を試みるというやり方と思われるスパムアクセスを、2004年ころに何度か発見したことがある。このことは、2007年10月1日「スパマーは進歩しているのか?」で述べた。
 最近ではこのようなスパムアクセスは観測されていなかったが、久しぶりに現れた。拒絶ログソーティングスクリプトでソーティングした結果を示す。

Feb 10 10:31:33 unknown [190.84.120.208]
Feb 10 10:48:35 unknown [190.84.120.208]
Feb 10 11:15:37 unknown [190.84.120.208]

Feb 10 10:32:49 host60.190-228-65.telecom.net.ar [190.228.65.60]
Feb 10 10:50:01 host60.190-228-65.telecom.net.ar [190.228.65.60]
Feb 10 11:17:53 host60.190-228-65.telecom.net.ar [190.228.65.60]

Feb 10 10:33:56 unknown [118.91.2.38]
Feb 10 10:50:57 unknown [118.91.2.38]
Feb 10 11:17:58 unknown [118.91.2.38]

Feb 10 10:35:11 ppp-58-10-74-55.revip2.asianet.co.th [58.10.74.55]
Feb 10 10:52:12 ppp-58-10-74-55.revip2.asianet.co.th [58.10.74.55]
Feb 10 11:19:13 ppp-58-10-74-55.revip2.asianet.co.th [58.10.74.55]

 1分前後の間隔で異なるホストからアクセスが来ており、しかも、同一ホストから17~27分の間隔でリトライしている。アクセスはこれで止まらず、多数のボットからのアクセスが12時47分まで続いていた。これでは、DNSBLは簡単に突破されるだろうし、グレイリスティングも突破されてしまう。
 とはいえ、リトライの継続時間は1時間未満なので、素のS25R方式を使っていればブロックを破られるおそれは少ない。もしメールサーバと同じように何時間もリトライするボットが現れたら、S25R方式でも防御が困難になるだろう。もっとも、ボットに何時間もリトライさせることは、スパマーにとってはコスト高な方法である。スパマーはそこまでやるだろうか。今後、スパマーの戦略がどうなるか、観察を続けようと思う。

日曜日, 2月 01, 2009

IPv6アドレスを引っかけないようにルール1を変更

 BBSのゲストのJE3KMZさんから、IPv6アドレスのホストからのアクセスがルール1で蹴られてしまうという申告をいただいた。
 IPv6アドレスの表記は、「2001:2f8:0:100::153」(f.dns.jpの例)のような形である。Postfixは、まずFQDNを正規表現と照合して、どれともマッチしなければ、次にIPアドレスの表記を正規表現と照合する。だからIPv6アドレスがことごとくルール1に引っかかってしまうのだと気付いた。
 そこで、ルール1を次のように変更した。

/^[^.]*[0-9][^0-9.]+[0-9]/ 450 S25R check, be patient

/^[^.]*[0-9][^0-9.]+[0-9].*\./ 450 S25R check, be patient

 正規表現の末尾の「\.」はドットにマッチする。これにより、ドットを含まないIPv6表記は引っかからなくなる。
 これで解決したとの報告をいただいたので、論文を修正した。