佐藤さんがtaRgreyを公開された。
S25Rの拒否条件に引っかかる送信元にまず65秒程度のtarpitting（応答遅延）をかける。ほとんどのスパムウェアは、応答を待ちきれずに勝手に切断する。正当なメールサーバはちゃんと応答を待つので、グレイリスティングによるよりもはるかに短い遅延でメールを受信できる。tarpittingを抜けられないごく少数の正当なメールサーバは、再送してきた時にグレイリスティングで救済する。これによって、自動的に偽陽性をほぼなくすことができる。スパムの阻止率を多少犠牲にしてでも正当なメールを確実に受信すべきISPには適した方式だと思う。
ところが、いざ発表してみると、佐藤さんの元々の狙いに反して、スパムの阻止率を上げるためにtarpittingとグレイリスティングの両方をかけるという需要の方が多かったのだそうである。そこで、taRgreyでは救済重視の「taRgreyモード」と阻止率重視の「tarpit & greylistモード」が提供されている。
tarpit & greylistモードでは、S25Rの拒否条件に引っかかる送信元に対してtarpittingとグレイリスティングの両方の試練を与える。この需要が多いということは、よほどスパムを憎む人が多いのだろうか。S25Rの偽陽性率はホワイトリストなしでは約13%もある（11月29日「偽陽性率」）と知ってもなお、正当なメールサーバの13%にそこまでの試練を与えたいだろうか。私は「そこまでやる？」と思ってしまう。
S25Rの拒否条件に引っかかるホストからのメールはグレイリスティングで30分ほど遅延してもかまわない、再送のたびにIPアドレスが変わるケース（9月1日「グレイリスティングを抜けられないサイト」）は手動のホワイトリスト登録で救済すればよいという考え方なら、Rgreyを使えばよいのではないかと思うのだが。うーん、どんなものでしょうねえ。
なお、ついでに言うと、「tarpitting」は英語の辞書にないが、「tar pit」（タールの穴）が語源らしい。
（12月12日追記）
佐藤さんのブログ記事に書かれていることを見落としていた。佐世保高専の中原さんの測定によると、スパムの阻止率はtaRgreyモードで約96.5%、Rgreyで約97.0%、tarpit & greylistモードで約98.5%だそうである。やっぱりtarpit & greylistモードの阻止率は高いらしい。
金曜日, 12月 08, 2006
偶発的な逆引き失敗
12月1日「スパムは増える」で、勤務先に届くスパムをBecky!でフィルタリングして偽陽性判定は10月以来ゼロだと書いたが、嘘だった。すみません。(_"_) 逆引きできる送信元の逆引きまたはパラノイド検査が一時的に失敗してごみ箱に振り分けられたことがあったのを思い出した。
送信元ドメインのプライマリDNSサーバもセカンダリDNSサーバもあるのに、一定時間内にDNSクエリーが解決しないことがまれにある。いつも届いている相手からのメールはごみ箱に入らないものと思い込んでいてはいけない。ごみ箱に振り分けられたメールの一覧は毎日チェックする必要がある。
そういえば、自宅サイトでも同じことがあった。逆引きできて、いつもはちゃんと受け取っている送信元サーバをunknownで2回蹴って、3回目に1時間の遅延でようやく受信していた。
まあ、こういうこともある。受信できるから問題ない。遅延がいやだと思う人は、S25R方式なんか使わない方がよい。
送信元ドメインのプライマリDNSサーバもセカンダリDNSサーバもあるのに、一定時間内にDNSクエリーが解決しないことがまれにある。いつも届いている相手からのメールはごみ箱に入らないものと思い込んでいてはいけない。ごみ箱に振り分けられたメールの一覧は毎日チェックする必要がある。
そういえば、自宅サイトでも同じことがあった。逆引きできて、いつもはちゃんと受け取っている送信元サーバをunknownで2回蹴って、3回目に1時間の遅延でようやく受信していた。
まあ、こういうこともある。受信できるから問題ない。遅延がいやだと思う人は、S25R方式なんか使わない方がよい。
月曜日, 12月 04, 2006
リトライするスパムが減った
8月28日「リトライするスパムをRgreyで蹴る」で、約5分間隔で5回トライするスパムアクセスがけっこうあることを述べた。ところが、この1ヶ月、私のサイトではそのようなスパムアクセスをまったく見かけなくなった。
11月5日以降のログでは、リトライしたスパムアクセスは次の1件だけで、2回のトライで終わっていた。
Dec 1 05:59:01 adsl-70-232-22-194.dsl.irvnca.sbcglobal.net [70.232.22.194]
Dec 1 06:06:32 adsl-70-232-22-194.dsl.irvnca.sbcglobal.net [70.232.22.194]
もしかしたら、5回トライするスパムアクセスは特定のウィルスによるもので、その駆除が進んだからかもしれない。
前述の記事では、postgreyの--delayオプションに指定する遅延時間を1500秒（25分）に設定することを勧めたが、600秒（10分）程度に緩めてもよいかもしれない。
11月5日以降のログでは、リトライしたスパムアクセスは次の1件だけで、2回のトライで終わっていた。
Dec 1 05:59:01 adsl-70-232-22-194.dsl.irvnca.sbcglobal.net [70.232.22.194]
Dec 1 06:06:32 adsl-70-232-22-194.dsl.irvnca.sbcglobal.net [70.232.22.194]
もしかしたら、5回トライするスパムアクセスは特定のウィルスによるもので、その駆除が進んだからかもしれない。
前述の記事では、postgreyの--delayオプションに指定する遅延時間を1500秒（25分）に設定することを勧めたが、600秒（10分）程度に緩めてもよいかもしれない。
日曜日, 12月 03, 2006
注意点も公表
「スパム対策技術」の目次ページの先頭にS25R方式の要点を掲示しているが、これを少し書き換えた。全不正メールアクセスに対する阻止率は99%だが、宛先の正しいスパムの阻止率はやや低くて97%であること。それに、注意点として、初期の偽陽性判定率が13%と高いことも書いた。13%という値は、わずか142個のホストから算出したものなので（11月29日「偽陽性率」）精度が粗いと思うが、おそらく大規模サイトでの統計からさほどかけ離れてはいないだろう。
また、10月から、論文のページの先頭に「このページへ直接来られた方は、目次ページもご覧ください。」と書き加えている。論文だけでなく、ホワイトリスト情報、導入者の皆様の声、このブログ、ボランティアの方々による工夫などの情報を総合的に見てほしいからである。
論文の上っ面だけを読んで批判されるのも不本意だが、副作用のリスクをちゃんと理解せずに導入されるのも困る。Googleで「スパム 対策」で検索すると論文が1位にヒットするが、そこから目次ページへ誘導すれば、S25R方式をより正しく理解してくれる人が増えるだろうと期待している。
また、10月から、論文のページの先頭に「このページへ直接来られた方は、目次ページもご覧ください。」と書き加えている。論文だけでなく、ホワイトリスト情報、導入者の皆様の声、このブログ、ボランティアの方々による工夫などの情報を総合的に見てほしいからである。
論文の上っ面だけを読んで批判されるのも不本意だが、副作用のリスクをちゃんと理解せずに導入されるのも困る。Googleで「スパム 対策」で検索すると論文が1位にヒットするが、そこから目次ページへ誘導すれば、S25R方式をより正しく理解してくれる人が増えるだろうと期待している。
土曜日, 12月 02, 2006
スパムの総数が増えれば
BBSで相談を受けた。S25R方式を導入して最初のうちは効果があったのだが、すり抜けるスパムが増えてきたので、何か良い方法はないかということだった。
一日に受けたスパムが6通とのこと。送信元のFQDNを見ると、8月7日「ホスト名「nat」」で述べた方法で阻止できるものが2通、一般規則のルール1を緩めていたためにすり抜けたものが1通、残りはどうにもならないものだった。一般規則をすり抜けるホストからスパムが繰り返し来るならブラックリストに登録すればよいが、そういうことはあまりない。
すり抜けが増えたのは、単にスパムの総数が増えたからに違いない。宛先の正しいスパムの阻止率は約97%だから、100通のスパムが押し寄せれば3通、200通が押し寄せれば6通ほどがすり抜けるのはやむを得ない。8月25日「今なお阻止率99%」で述べたように、S25R方式の効果が衰えているわけではないのである。
私の自宅サイトは、S25R方式の開発期間を含めて3年以上にわたって固い防御を保っている。それで、前回述べたように、スパムの総数は増える一方なのに、着信するスパムは減少傾向にある。拒否応答を返し続けていれば、そのうち敵はだんだんあきらめるようになるだろう。
一日に受けたスパムが6通とのこと。送信元のFQDNを見ると、8月7日「ホスト名「nat」」で述べた方法で阻止できるものが2通、一般規則のルール1を緩めていたためにすり抜けたものが1通、残りはどうにもならないものだった。一般規則をすり抜けるホストからスパムが繰り返し来るならブラックリストに登録すればよいが、そういうことはあまりない。
すり抜けが増えたのは、単にスパムの総数が増えたからに違いない。宛先の正しいスパムの阻止率は約97%だから、100通のスパムが押し寄せれば3通、200通が押し寄せれば6通ほどがすり抜けるのはやむを得ない。8月25日「今なお阻止率99%」で述べたように、S25R方式の効果が衰えているわけではないのである。
私の自宅サイトは、S25R方式の開発期間を含めて3年以上にわたって固い防御を保っている。それで、前回述べたように、スパムの総数は増える一方なのに、着信するスパムは減少傾向にある。拒否応答を返し続けていれば、そのうち敵はだんだんあきらめるようになるだろう。
金曜日, 12月 01, 2006
スパムは増える
勤務先のアドレスに届いたスパムは、9月には510通、10月には847通、11月には1570通だった。なんと、2ヶ月で3倍になっている。この増加ぶりには、もう笑っちゃうしかない。
とはいえ、Becky!でのフィルタリングがうまくいっているので、ストレスは感じない。11月の見逃し数は37通（2.4%）。つまり判別率は97.6%。8月23日から9月22日までの1ヶ月間で計った判別率97.0%（9月23日「Becky!でのフィルタリング」）からほとんど変わっておらず、むしろわずかに上がっている。見逃しは一日にせいぜい数通。まったくない日もある。除外条件（ホワイトリスト）の登録は6件で、偽陽性判定は10月以来ゼロである。S25R方式を応用したフィルタリングがスパムを正確にごみ箱に放り込んでくれるのを見るのは、むしろ快感である。フィルタリングの条件の指定に正規表現を使えるBecky!のおかげである。Becky!万歳！
さて、自宅サイトの方はどうかというと、11月に不正メールを送り込もうとしたホストは7245個（うち3個からスパムが着信した）。7月には4423個だった（8月25日「今なお阻止率99%」）のに比べて、やはり増えている。
ところが、奇妙なことに、宛先の正しい不正メールの送信元ホストが7月には305個だったのが、11月には192個に減っていた。着信したスパムは、7月には8通、8月には10通だったが、9月には6通、10月には4通、11月には3通と減ってきている。勤務先での受信数の急激な増加とは対照的である。やはり、9月28日「拒絶の効果？」で述べたように、送達率を重視するスパマーが私の自宅サイトへの送信をだんだんあきらめてきているとしか思えない。S25R方式万歳！
とはいえ、Becky!でのフィルタリングがうまくいっているので、ストレスは感じない。11月の見逃し数は37通（2.4%）。つまり判別率は97.6%。8月23日から9月22日までの1ヶ月間で計った判別率97.0%（9月23日「Becky!でのフィルタリング」）からほとんど変わっておらず、むしろわずかに上がっている。見逃しは一日にせいぜい数通。まったくない日もある。除外条件（ホワイトリスト）の登録は6件で、偽陽性判定は10月以来ゼロである。S25R方式を応用したフィルタリングがスパムを正確にごみ箱に放り込んでくれるのを見るのは、むしろ快感である。フィルタリングの条件の指定に正規表現を使えるBecky!のおかげである。Becky!万歳！
さて、自宅サイトの方はどうかというと、11月に不正メールを送り込もうとしたホストは7245個（うち3個からスパムが着信した）。7月には4423個だった（8月25日「今なお阻止率99%」）のに比べて、やはり増えている。
ところが、奇妙なことに、宛先の正しい不正メールの送信元ホストが7月には305個だったのが、11月には192個に減っていた。着信したスパムは、7月には8通、8月には10通だったが、9月には6通、10月には4通、11月には3通と減ってきている。勤務先での受信数の急激な増加とは対照的である。やはり、9月28日「拒絶の効果？」で述べたように、送達率を重視するスパマーが私の自宅サイトへの送信をだんだんあきらめてきているとしか思えない。S25R方式万歳！
水曜日, 11月 29, 2006
偽陽性率
S25R方式の偽陽性率をどう評価しようかと考えた末に、正当な受信メールの送信元ホストを拾い上げてみた。2006年1月以降、11月28日までに受信したメールの送信元は142個。そのうち、S25Rの一般規則に引っかかるホストは19個だった。ここから計算した、ホワイトリストがないものと仮定した偽陽性率は13.4%である。意外な高さに今さらながら驚いた。
とはいえ、偽陽性率の高さに手を焼いているわけではまったくない。1サイトのメールマガジンを受信し損ねたことがある（8月30日「リトライを短時間でやめるサーバ」）のを除いて、以前から登録してあったホワイトリスト、新たに登録したホワイトリスト、および協力者から報告されたホワイトリストのおかげで、苦もなく受信に成功している（もちろん、メールトラフィックが少ない個人サイトだから苦労がないのだが）。正規表現によるホワイトリスト登録1件で複数のホストを救済するケースもあり、19個のホストを救済したホワイトリスト項目は14件であった。
一方、9月15日「宛先の正しいスパムの阻止率」で報告したとおり、2006年7月の統計では、宛先の正しいスパムの阻止率はトータルで97.4%であった。すなわち、偽陰性率（見逃し率）は2.6%である。
スパム判定においては、偽陰性判定よりも偽陽性判定の方が有害である。スパムの阻止に失敗するよりも、正当なメールを受けられないことの方が困る。では、偽陰性率よりも偽陽性率の方が高いS25R方式は有害な方式か。決してそんなことはない。
S25R方式では、偽陽性判定は致命的なものではなく、リトライアクセスを発見してホワイトリスト登録すればメールを受信することができる。そして、そのホストからのメールを阻止することは二度となくなる。ホワイトリスト登録が進むにつれて、偽陽性率はゼロに近付いていく。
偽陰性率は初めから十分に低い。メールの90%以上はスパムだと言われる現在、偽陰性率の低さはやはり重要である。そして、偽陽性率は、ホワイトリスト登録によって（素のS25R方式ではそのために労力はかかるものの）どんどん下がっていく。偽陽性を減らすために偽陰性率の低さを犠牲にする必要がない。つまり、スパム対策方式としての実用性が高いのである。このことこそ、S25R方式が多くの人々に支持されている理由に違いない。
とはいえ、偽陽性率の高さに手を焼いているわけではまったくない。1サイトのメールマガジンを受信し損ねたことがある（8月30日「リトライを短時間でやめるサーバ」）のを除いて、以前から登録してあったホワイトリスト、新たに登録したホワイトリスト、および協力者から報告されたホワイトリストのおかげで、苦もなく受信に成功している（もちろん、メールトラフィックが少ない個人サイトだから苦労がないのだが）。正規表現によるホワイトリスト登録1件で複数のホストを救済するケースもあり、19個のホストを救済したホワイトリスト項目は14件であった。
一方、9月15日「宛先の正しいスパムの阻止率」で報告したとおり、2006年7月の統計では、宛先の正しいスパムの阻止率はトータルで97.4%であった。すなわち、偽陰性率（見逃し率）は2.6%である。
スパム判定においては、偽陰性判定よりも偽陽性判定の方が有害である。スパムの阻止に失敗するよりも、正当なメールを受けられないことの方が困る。では、偽陰性率よりも偽陽性率の方が高いS25R方式は有害な方式か。決してそんなことはない。
S25R方式では、偽陽性判定は致命的なものではなく、リトライアクセスを発見してホワイトリスト登録すればメールを受信することができる。そして、そのホストからのメールを阻止することは二度となくなる。ホワイトリスト登録が進むにつれて、偽陽性率はゼロに近付いていく。
偽陰性率は初めから十分に低い。メールの90%以上はスパムだと言われる現在、偽陰性率の低さはやはり重要である。そして、偽陽性率は、ホワイトリスト登録によって（素のS25R方式ではそのために労力はかかるものの）どんどん下がっていく。偽陽性を減らすために偽陰性率の低さを犠牲にする必要がない。つまり、スパム対策方式としての実用性が高いのである。このことこそ、S25R方式が多くの人々に支持されている理由に違いない。
日曜日, 11月 26, 2006
DNSWLはいかが？
S25R方式は、スパムの阻止率が高い代わりに、組織サイトでは初めのうち偽陽性判定が多い。500～1000件のホワイトリスト登録が必要だと聞く。それなら、ホワイトリストデータベースを共有するようにすれば運用が楽になるのではないかという発想が出てくる。
そこで、DNSBLならぬDNSWL（DNS White List）というものが世の中にあるかどうかと思って、何気なく検索してみた。すると、そのものずばりのサイトがあった。dnswl.orgである。そのホームページにはこう説明されている（誤訳があったらご指摘ください）。
DNSBLよりも役に立つかもしれない。
ただし、おそらく、S25R方式の導入サイトがすぐに使えるものではない。S25R方式特有のルールによって阻止されるホストがかなりあるからである。S25R方式の導入サイト（それも、かなりの規模の組織サイト）の誰かがボランティアでデータを提供する必要がある。
また、これが広く使われるようになると、スパマーがスパム送信コンピュータをホワイトリスト登録するおそれがある。悪意ある者によってデータが汚されるのは、ブラックリストにせよホワイトリストにせよ、不特定の人々の共同作業で作るデータベースではどうしても生じるリスクである。
そこで、DNSBLならぬDNSWL（DNS White List）というものが世の中にあるかどうかと思って、何気なく検索してみた。すると、そのものずばりのサイトがあった。dnswl.orgである。そのホームページにはこう説明されている（誤訳があったらご指摘ください）。
| dnswl.orgとは？ dnswl.orgは、善良とわかっている送信元のIPアドレスのリストを提供します。このデータは、これらの送信元からのメールがスパムフィルタに偶然つかまったり、偶発的あるいは誤った阻止リスト登録によって阻止されたりしないことを保証するために使うことができます。 このリストは、メール管理者やスパムフィルタ管理者がホワイトリストを手動で保守する労力を最小化するのに役立ちます。dnswl.orgは共同作業です。つまり、善良な送信元を識別するのに皆さんの援助が必要です。また、リストにある送信元の一つが善良でないとわかったら、知らせてください。 データは複数のカテゴリー（財団やその他の大企業、インターネット／メールサービスプロバイダなど）について入手でき、各項目は「低」、「中」、「高」に点数付けされています。各管理者は、これらの点数をどう適用するかについて自分自身のルールを選ぶことができます。 このリストは、DNSによって、また、いくつかのダウンロードフォーマット（プレーンテキスト、rbldnsdフォーマットテキスト、コメント付きテキスト）で提供されます。 |
DNSBLよりも役に立つかもしれない。
ただし、おそらく、S25R方式の導入サイトがすぐに使えるものではない。S25R方式特有のルールによって阻止されるホストがかなりあるからである。S25R方式の導入サイト（それも、かなりの規模の組織サイト）の誰かがボランティアでデータを提供する必要がある。
また、これが広く使われるようになると、スパマーがスパム送信コンピュータをホワイトリスト登録するおそれがある。悪意ある者によってデータが汚されるのは、ブラックリストにせよホワイトリストにせよ、不特定の人々の共同作業で作るデータベースではどうしても生じるリスクである。
金曜日, 11月 24, 2006
DNSBLの利用価値はあるか？
「IPアドレスを手がかりにしてスパム判定するなら、すでにDNSBLがあるではないか」と言う人がいる。しかし私は、S25R方式の方が使いやすいと思う。
DNSBLは、スパム送信の前科のあるIPアドレスをブラックリストに登録する。しかし、前科がなくても、悪意のないインターネットユーザーのPCがウィルス感染でゾンビ化してスパムの送信元になるおそれがある。ゾンビPCが次から次へと生まれれば、ブラックリスト登録は後追いになる。S25R方式なら、前科の有無にかかわらず、エンドユーザー回線からと推定されるSMTPアクセスに対して一時的拒否応答を返すので、かなりの確度でスパムやウィルスメールを阻止することができる。
また、DNSBLでは、正当なメールサーバがスパム送信元の巻き添えを食らってブラックリストに登録されてしまうことがある。そのため、今まで届いていたメールが突然拒否されるようになるおそれがある。ブラックリストのデータが古いままで、あるいはデータベースのトラブルでデータが過去に巻き戻ってしまって、無実のメールサーバを拒絶することもあると聞く。S25R方式ではそのような心配はない。拒否や許可のルールはローカルな設定で決めるからである。初めてメールを送ってくる正当なメールサーバを誤って蹴ってしまうことはあるが、再送アクセスが来ている間にホワイトリスト登録した後は、二度と蹴ることはなくなる。
S25R方式にDNSBLを併用するという方法はどうだろうか。併用の方法には、阻止率を上げる（偽陰性を減らす）ためと、偽陽性を減らすための二通りの方法が考えられる。
阻止率を上げるためにDNSBLを併用するには、S25Rの阻止条件に引っかからなかったホストをDNSBL検査にかけることになる。しかし、これはあまり効果がないと思う。S25Rをすり抜けるスパムには、ISPのメールサーバを経由したものや、一時的に乗っ取られたサーバから送信されたと思われるものが多い。私のサイトでの観測では、サーバっぽい逆引き名の同じホストから繰り返しスパムが来たことはほとんどない。DNSBLに頼っても、阻止率は、S25Rによる阻止率（全不正メールアクセスについて99%、宛先の正しいスパムについて97%）よりもさらに大きく向上することはないだろう。むしろ、ISPのメールサーバや、乗っ取られた後に対処されたサーバがDNSBLに残り、偽陽性が増えるおそれがある。
偽陽性を減らすためにDNSBLを併用するには、S25Rの阻止条件に引っかかったホストをDNSBL検査にかけて、それに引っかからなかったホストを許可することになる。この方法では、ゾンビ化したばかりのPCからのスパムを受けてしまうおそれがある。定量的評価はしていないが、阻止率はかなり下がってしまうのではないかと思う。
結局のところ、DNSBLを使う積極的な理由は見出せない。「S25R＋グレイリスティングという対策をとっていれば、今さらDNSBLを使う必要は感じない」と言う人もいる。私もそう思う。
DNSBLは、スパム送信の前科のあるIPアドレスをブラックリストに登録する。しかし、前科がなくても、悪意のないインターネットユーザーのPCがウィルス感染でゾンビ化してスパムの送信元になるおそれがある。ゾンビPCが次から次へと生まれれば、ブラックリスト登録は後追いになる。S25R方式なら、前科の有無にかかわらず、エンドユーザー回線からと推定されるSMTPアクセスに対して一時的拒否応答を返すので、かなりの確度でスパムやウィルスメールを阻止することができる。
また、DNSBLでは、正当なメールサーバがスパム送信元の巻き添えを食らってブラックリストに登録されてしまうことがある。そのため、今まで届いていたメールが突然拒否されるようになるおそれがある。ブラックリストのデータが古いままで、あるいはデータベースのトラブルでデータが過去に巻き戻ってしまって、無実のメールサーバを拒絶することもあると聞く。S25R方式ではそのような心配はない。拒否や許可のルールはローカルな設定で決めるからである。初めてメールを送ってくる正当なメールサーバを誤って蹴ってしまうことはあるが、再送アクセスが来ている間にホワイトリスト登録した後は、二度と蹴ることはなくなる。
S25R方式にDNSBLを併用するという方法はどうだろうか。併用の方法には、阻止率を上げる（偽陰性を減らす）ためと、偽陽性を減らすための二通りの方法が考えられる。
阻止率を上げるためにDNSBLを併用するには、S25Rの阻止条件に引っかからなかったホストをDNSBL検査にかけることになる。しかし、これはあまり効果がないと思う。S25Rをすり抜けるスパムには、ISPのメールサーバを経由したものや、一時的に乗っ取られたサーバから送信されたと思われるものが多い。私のサイトでの観測では、サーバっぽい逆引き名の同じホストから繰り返しスパムが来たことはほとんどない。DNSBLに頼っても、阻止率は、S25Rによる阻止率（全不正メールアクセスについて99%、宛先の正しいスパムについて97%）よりもさらに大きく向上することはないだろう。むしろ、ISPのメールサーバや、乗っ取られた後に対処されたサーバがDNSBLに残り、偽陽性が増えるおそれがある。
偽陽性を減らすためにDNSBLを併用するには、S25Rの阻止条件に引っかかったホストをDNSBL検査にかけて、それに引っかからなかったホストを許可することになる。この方法では、ゾンビ化したばかりのPCからのスパムを受けてしまうおそれがある。定量的評価はしていないが、阻止率はかなり下がってしまうのではないかと思う。
結局のところ、DNSBLを使う積極的な理由は見出せない。「S25R＋グレイリスティングという対策をとっていれば、今さらDNSBLを使う必要は感じない」と言う人もいる。私もそう思う。
木曜日, 11月 23, 2006
土曜日, 11月 18, 2006
木曜日, 11月 09, 2006
maps_rbl_reject_code
Postfixのsample-smtpd.cfファイルに次のような記述を見つけた。
# The maps_rbl_reject_code parameter specifies the SMTP server response
# when an SMTP client request is blocked by a reject_rbl or reject_rhsbl
# restriction.
#
# Do not change this unless you have a complete understanding of RFC 821.
#
maps_rbl_reject_code = 550
デフォルトの応答コードは「550」だと読み取れるが、実際のデフォルト値をpostconfコマンドで調べてみたら…
$ postconf | grep maps_rbl_reject_code
maps_rbl_reject_code = 554
前回の記事「「5xx」で蹴るなんて」で、DNSBLを全面的に信頼して「5xx」で蹴ることが信じられないと書いたが、なんとその元凶はPostfixのデフォルト値だった。
PostfixでDNSBLを利用している人は、ぜひmain.cfファイルに
maps_rbl_reject_code = 450
を追記してほしい。sample-smtpd.cfファイルには「RFC 821を完全に理解していない限り変えるな」と書いてあるが、びびることはない。
もちろん、まめにログを監視して、正当なメールサーバからのリトライアクセスを発見したらホワイトリスト登録するように運用すべきである。リトライアクセスを発見しやすくするためには、私の拒絶ログソーティングスクリプトが使える。あるいは、グレイリスティングに回してもよいが、どうやればよいのかは知らない。
# The maps_rbl_reject_code parameter specifies the SMTP server response
# when an SMTP client request is blocked by a reject_rbl or reject_rhsbl
# restriction.
#
# Do not change this unless you have a complete understanding of RFC 821.
#
maps_rbl_reject_code = 550
デフォルトの応答コードは「550」だと読み取れるが、実際のデフォルト値をpostconfコマンドで調べてみたら…
$ postconf | grep maps_rbl_reject_code
maps_rbl_reject_code = 554
前回の記事「「5xx」で蹴るなんて」で、DNSBLを全面的に信頼して「5xx」で蹴ることが信じられないと書いたが、なんとその元凶はPostfixのデフォルト値だった。
PostfixでDNSBLを利用している人は、ぜひmain.cfファイルに
maps_rbl_reject_code = 450
を追記してほしい。sample-smtpd.cfファイルには「RFC 821を完全に理解していない限り変えるな」と書いてあるが、びびることはない。
もちろん、まめにログを監視して、正当なメールサーバからのリトライアクセスを発見したらホワイトリスト登録するように運用すべきである。リトライアクセスを発見しやすくするためには、私の拒絶ログソーティングスクリプトが使える。あるいは、グレイリスティングに回してもよいが、どうやればよいのかは知らない。
火曜日, 11月 07, 2006
「5xx」で蹴るなんて
S25R方式でメールを蹴られて困っている人がいるという情報（10月29日「大手ISPに導入されたらしいが…」）を佐藤さんから聞いたきっかけは、佐藤さんが運用するサイトがSpamhausのDNSBLに登録されてしまったという事件だった。もちろん佐藤さんのサイトがスパムを発信するわけはないのだが、近隣のIPアドレスからスパムが発信されたため、巻き添えをくらってネットマスク22ビット（1024個ブロック）で登録されてしまったらしい。そのため、佐藤さんのサイトからのメールが、Spamhausを利用しているサイトで受信拒否されてしまったのである。
何の応答コードで蹴られたかと質問したら、「5xx」だったと聞いてびっくりした。なぜそこまで他人のデータベースを信用できるのだろうか。今回のSpamhausのように、多数のIPアドレスからスパムが発信されたら、それらを含むIPアドレスブロックをまとめてリストに登録してしまうケースもある。ましてDNSBLは、登録されたIPアドレスからスパムしか発信されないと保証しているわけではない。DNSBLに登録されたIPアドレスから正当なメールが送信されることもありうるということを考慮すべきである。
DNSBLの情報に基づいてアクセスを蹴るなら、「4xx」を返して様子を見るべきである。さもないと、他サイトの善良な送信者を困らせるし、そのメールを受信するはずだった自サイトの受信者にも不利益をこうむらせることになる。
S25R方式のコンセプトで重要なことは、送信元のIPアドレスの逆引き結果に基づいて不正メールアクセスの疑いを推定するが、あくまでも推定であって、決して確信しないということである。だから、誤って阻止される正当なメールを救済する余地を残すために、応答コード「450」を返すのである（企業や学校でポルノサイトからのスパムを阻止するような場合はこの限りではないが）。
S25R方式に対して、個人サイトを排除するやり方だという批判がいまだにあるが、S25R方式のコンセプトは決してそのようなものではない。私は、ダイナミックIPアドレスの個人サーバから直接送信するのはやめてほしい、ISPのメールサーバを経由して送信するか、固定IPアドレスのサービスに乗り換えてほしいと主張してはいる（論文および7月29日「個人サーバ」）。しかし、ダイナミックIPアドレスのサーバだからといって「5xx」を返すことを勧めてなどいない。実際私は、ダイナミックIPアドレスのサーバからのメールもホワイトリスト登録して受信している。
S25R方式は正当なメールを排除するという批判は誤りである。批判されるべきは、スパムの受信が減ったことで満足してしまって、正当なメールを拒絶する副作用のリスクを省みないという、間違った運用である。それは、S25R方式を使うにせよDNSBLを使うにせよ、同じことである。
何の応答コードで蹴られたかと質問したら、「5xx」だったと聞いてびっくりした。なぜそこまで他人のデータベースを信用できるのだろうか。今回のSpamhausのように、多数のIPアドレスからスパムが発信されたら、それらを含むIPアドレスブロックをまとめてリストに登録してしまうケースもある。ましてDNSBLは、登録されたIPアドレスからスパムしか発信されないと保証しているわけではない。DNSBLに登録されたIPアドレスから正当なメールが送信されることもありうるということを考慮すべきである。
DNSBLの情報に基づいてアクセスを蹴るなら、「4xx」を返して様子を見るべきである。さもないと、他サイトの善良な送信者を困らせるし、そのメールを受信するはずだった自サイトの受信者にも不利益をこうむらせることになる。
S25R方式のコンセプトで重要なことは、送信元のIPアドレスの逆引き結果に基づいて不正メールアクセスの疑いを推定するが、あくまでも推定であって、決して確信しないということである。だから、誤って阻止される正当なメールを救済する余地を残すために、応答コード「450」を返すのである（企業や学校でポルノサイトからのスパムを阻止するような場合はこの限りではないが）。
S25R方式に対して、個人サイトを排除するやり方だという批判がいまだにあるが、S25R方式のコンセプトは決してそのようなものではない。私は、ダイナミックIPアドレスの個人サーバから直接送信するのはやめてほしい、ISPのメールサーバを経由して送信するか、固定IPアドレスのサービスに乗り換えてほしいと主張してはいる（論文および7月29日「個人サーバ」）。しかし、ダイナミックIPアドレスのサーバだからといって「5xx」を返すことを勧めてなどいない。実際私は、ダイナミックIPアドレスのサーバからのメールもホワイトリスト登録して受信している。
S25R方式は正当なメールを排除するという批判は誤りである。批判されるべきは、スパムの受信が減ったことで満足してしまって、正当なメールを拒絶する副作用のリスクを省みないという、間違った運用である。それは、S25R方式を使うにせよDNSBLを使うにせよ、同じことである。
水曜日, 11月 01, 2006
日曜日, 10月 29, 2006
大手ISPに導入されたらしいが…
佐藤さんから聞いた話。IPアドレスの割り当て1個の接続サービスを利用している会社から某大手ISPにメールを送ろうとしたら、リトライアウトでエラーリターンしたとのこと。先月（9月）のことである。そこに示されたエラーメッセージは、「may not be mail exchanger」という、私が作ったものだった。応答コードは「450」だった。
このメッセージ文で検索すると、困っている人の情報が得られると佐藤さんに言われて、検索してみた。そのISPへのメールのエラーリターンに「550」の応答コードが示されているのがさらされていた（日付はやはり9月だった）。これには驚いた。
裏を取ろうと、ダイヤルアップ接続で手動のSMTPアクセスをかけてみた。RCPT TOコマンドに対する応答コードは「250」。拒否していない。私がダイヤルアップ接続に使っているISPのダイヤルアップ用IPアドレスの逆引き名はルール5（逆引きFQDNが5階層以上で、下位2階層の名前がともに数字で終わる）に引っかかるが、もしかしたらルール5を入れていないのかもしれない。私は8個ブロックのIPアドレスをもらっていて逆引き権限の委譲を受けているので、予備サーバのIPアドレスの逆引き名を「219-163-213-19.rev.reto.jp」とS25Rに思い切り引っかかるものに変えて、予備サーバからアクセスしてみた。「450」で蹴られた。「550」を返していたという裏は取れなかった。
それにしても、正当なメールをリトライアウトさせてしまったとはどういうことだろう。通常のMTA（くだんの会社ではqmailを使っているとのこと）なら数日間リトライする。その間ずっと、ログを確認せずに放置していたのだろうか。
私は、善良な送信者や受信者をハッピーにするためにS25R方式を発表したのである。善良なユーザーを困らせてはいけない。正当なメールを「450」で蹴ってしまうというリスクをちゃんとコントロールしてくれなければ困る。正当なメールを救済することには真剣勝負の覚悟で取り組んでほしい。リトライのログを確認しやすくするために、私は拒絶ログソーティングスクリプトを提供している。まめにログを確認することができないなら、Rgreyなどでリトライアクセスの救済を自動化することを考えてほしい。それさえしないなら、S25R方式は使わないでほしい。
大手ISPでもS25R方式が導入されたとは光栄なことではあるが、正しく運用してくれているのだろうか。導入初期に失敗はあったけれども今はうまくやっていると信じたいが。
そのISPはS25R方式の導入を公表していないので、私がここで社名を公表するのは差し控える。もっとも、私が作ったメッセージ文で検索すればわかってしまうけれども。
このメッセージ文で検索すると、困っている人の情報が得られると佐藤さんに言われて、検索してみた。そのISPへのメールのエラーリターンに「550」の応答コードが示されているのがさらされていた（日付はやはり9月だった）。これには驚いた。
裏を取ろうと、ダイヤルアップ接続で手動のSMTPアクセスをかけてみた。RCPT TOコマンドに対する応答コードは「250」。拒否していない。私がダイヤルアップ接続に使っているISPのダイヤルアップ用IPアドレスの逆引き名はルール5（逆引きFQDNが5階層以上で、下位2階層の名前がともに数字で終わる）に引っかかるが、もしかしたらルール5を入れていないのかもしれない。私は8個ブロックのIPアドレスをもらっていて逆引き権限の委譲を受けているので、予備サーバのIPアドレスの逆引き名を「219-163-213-19.rev.reto.jp」とS25Rに思い切り引っかかるものに変えて、予備サーバからアクセスしてみた。「450」で蹴られた。「550」を返していたという裏は取れなかった。
それにしても、正当なメールをリトライアウトさせてしまったとはどういうことだろう。通常のMTA（くだんの会社ではqmailを使っているとのこと）なら数日間リトライする。その間ずっと、ログを確認せずに放置していたのだろうか。
私は、善良な送信者や受信者をハッピーにするためにS25R方式を発表したのである。善良なユーザーを困らせてはいけない。正当なメールを「450」で蹴ってしまうというリスクをちゃんとコントロールしてくれなければ困る。正当なメールを救済することには真剣勝負の覚悟で取り組んでほしい。リトライのログを確認しやすくするために、私は拒絶ログソーティングスクリプトを提供している。まめにログを確認することができないなら、Rgreyなどでリトライアクセスの救済を自動化することを考えてほしい。それさえしないなら、S25R方式は使わないでほしい。
大手ISPでもS25R方式が導入されたとは光栄なことではあるが、正しく運用してくれているのだろうか。導入初期に失敗はあったけれども今はうまくやっていると信じたいが。
そのISPはS25R方式の導入を公表していないので、私がここで社名を公表するのは差し控える。もっとも、私が作ったメッセージ文で検索すればわかってしまうけれども。
土曜日, 10月 21, 2006
無精者の勝利
2001年3月、sendmailから、設定の楽なPostfixに乗り換えた。
2001年8月、悪気のない未承諾広告メールを2度送ってきた業者に対して拒絶の意思を伝えようと考え、header_checksパラメータでFromヘッダをチェックしてエラーリターンさせるようにした（今にして思えば、smtpd_sender_restrictionsパラメータを使ってもよかったのだが）。これが私のスパム対策の始まりである。
2001年10月、同じ文面でFromアドレスを変えたスパムが2通来た。body_checksパラメータで、スパマーが宣伝しようとするウェブサイトのURLを引っかけてエラーリターンさせることを思い付いた。
その後1年あまり、この方法はうまくいっていた。着信するスパムがあまりに少なくなって、スパム防御策を研究しにくくなって面白くなくなった。そこで、2003年3月、見えないmailtoアンカーにおとりのアドレス（User unknownになる）を書いてホームページに仕掛けた。さっそく引っかかった奴が現れたので楽しかった。
2003年5月、着信するスパムが急に増え始めた。次々に来るスパムに防御が追い付かなくなった。また、URLに十六進文字符号を混ぜたり、本文全体をBASE64符号化したりするスパムもあった。内容チェックによる防御策に見切りを付けた。
内容チェックを高度化したベイジアンフィルタという技術があることは知らなかった（そのころすでに一般化していたのかどうか、今も知らない）。根が無精だから、世の中にどんなスパム対策技術があるのかをつぶさに調査することもしなかった。もっとも、もしベイジアンフィルタを知っていても、使いはしなかっただろう。受けてからフィルタリングする方法では、拒絶の意思をスパマーに思い知らせることができない。拒否応答を返さなければ気がすまない。悪人に対してはサディスティックなのである。
多くのスパムに共通することは何かと観察して、送信元のIPアドレスに着目した。ほとんどのスパムはエンドユーザー回線から直接送信されており、その多くは逆引きできないことがわかった。smtpd_client_restrictionsパラメータを使うことを覚え、「reject_unknown_client」を指定したら効果てきめんだった。また、逆引きできるエンドユーザー回線には逆引き名にIPアドレスを反映したものがかなりあることに気付いた。そこで、ハイフンかドットで区切られた4個の数字列が逆引き名に含まれていたら蹴るように正規表現を書いた。リトライする正当なメールサーバを救済する方法もマスターした。S25R方式の開発はここから始まった。個人サーバだから、思い切った試行錯誤ができた。
根が無精だから、楽をするためには労苦を惜しまない。たくさんの不正メールアクセスを観察しながら、なるべく多くのエンドユーザー回線を引っかけることができて（つまり、ブラックリスト作成の手間が少ない）、メールサーバを引っかけることがなるべく少ない（つまり、ホワイトリスト作成の手間が少ない）正規表現を作り上げた。この方式でよいと判断したのは、10ヶ月後の2004年3月だった。スパムだけでなくウィルスメールもほとんど阻止できる方式ができ上がった。
スパマーの立場に立って、S25R方式を破る方法も考えた。少量のスパムなら、ISPのメールサーバを経由するなどして送り込むことができるが、S25R方式の防御を破って大量のスパムを届かせることは、スパム送信コンピュータのリソース負荷が大きくなってきわめて難しいと結論付けた。簡単に破れる方式でも、大量スパムの90%以上を阻止し続けることができれば、それは勝利である。
私のような無精者が考え付くことはすでに世界の誰かが作っているのではないかと思ったが、不思議なことに、あちこち情報を検索しても見つからなかった。
もし私がベイジアンフィルタの発明者だったら…。もし私がもっと頭が良くて勤勉で、高度な数学を駆使することができて、内容チェックを高度化する道を突き進んでいたら…。宣伝文を画像化するというあまりにも簡単な方法で破られることに気付かされた時、「ああ、私の今までの努力は何だったのか」と嘆き悲しみ、絶望のあまりに憤死していたに違いない。
無精者だからできる発明もある。
2001年8月、悪気のない未承諾広告メールを2度送ってきた業者に対して拒絶の意思を伝えようと考え、header_checksパラメータでFromヘッダをチェックしてエラーリターンさせるようにした（今にして思えば、smtpd_sender_restrictionsパラメータを使ってもよかったのだが）。これが私のスパム対策の始まりである。
2001年10月、同じ文面でFromアドレスを変えたスパムが2通来た。body_checksパラメータで、スパマーが宣伝しようとするウェブサイトのURLを引っかけてエラーリターンさせることを思い付いた。
その後1年あまり、この方法はうまくいっていた。着信するスパムがあまりに少なくなって、スパム防御策を研究しにくくなって面白くなくなった。そこで、2003年3月、見えないmailtoアンカーにおとりのアドレス（User unknownになる）を書いてホームページに仕掛けた。さっそく引っかかった奴が現れたので楽しかった。
2003年5月、着信するスパムが急に増え始めた。次々に来るスパムに防御が追い付かなくなった。また、URLに十六進文字符号を混ぜたり、本文全体をBASE64符号化したりするスパムもあった。内容チェックによる防御策に見切りを付けた。
内容チェックを高度化したベイジアンフィルタという技術があることは知らなかった（そのころすでに一般化していたのかどうか、今も知らない）。根が無精だから、世の中にどんなスパム対策技術があるのかをつぶさに調査することもしなかった。もっとも、もしベイジアンフィルタを知っていても、使いはしなかっただろう。受けてからフィルタリングする方法では、拒絶の意思をスパマーに思い知らせることができない。拒否応答を返さなければ気がすまない。悪人に対してはサディスティックなのである。
多くのスパムに共通することは何かと観察して、送信元のIPアドレスに着目した。ほとんどのスパムはエンドユーザー回線から直接送信されており、その多くは逆引きできないことがわかった。smtpd_client_restrictionsパラメータを使うことを覚え、「reject_unknown_client」を指定したら効果てきめんだった。また、逆引きできるエンドユーザー回線には逆引き名にIPアドレスを反映したものがかなりあることに気付いた。そこで、ハイフンかドットで区切られた4個の数字列が逆引き名に含まれていたら蹴るように正規表現を書いた。リトライする正当なメールサーバを救済する方法もマスターした。S25R方式の開発はここから始まった。個人サーバだから、思い切った試行錯誤ができた。
根が無精だから、楽をするためには労苦を惜しまない。たくさんの不正メールアクセスを観察しながら、なるべく多くのエンドユーザー回線を引っかけることができて（つまり、ブラックリスト作成の手間が少ない）、メールサーバを引っかけることがなるべく少ない（つまり、ホワイトリスト作成の手間が少ない）正規表現を作り上げた。この方式でよいと判断したのは、10ヶ月後の2004年3月だった。スパムだけでなくウィルスメールもほとんど阻止できる方式ができ上がった。
スパマーの立場に立って、S25R方式を破る方法も考えた。少量のスパムなら、ISPのメールサーバを経由するなどして送り込むことができるが、S25R方式の防御を破って大量のスパムを届かせることは、スパム送信コンピュータのリソース負荷が大きくなってきわめて難しいと結論付けた。簡単に破れる方式でも、大量スパムの90%以上を阻止し続けることができれば、それは勝利である。
私のような無精者が考え付くことはすでに世界の誰かが作っているのではないかと思ったが、不思議なことに、あちこち情報を検索しても見つからなかった。
もし私がベイジアンフィルタの発明者だったら…。もし私がもっと頭が良くて勤勉で、高度な数学を駆使することができて、内容チェックを高度化する道を突き進んでいたら…。宣伝文を画像化するというあまりにも簡単な方法で破られることに気付かされた時、「ああ、私の今までの努力は何だったのか」と嘆き悲しみ、絶望のあまりに憤死していたに違いない。
無精者だからできる発明もある。
火曜日, 10月 17, 2006
パラノイド検査
S25R方式を導入された方から、「送信元ホストが逆引きできるのにPostfixで『unknown』になることがあるのはなぜ？」という質問を受けた。
私はすぐにパラノイド検査の結果を疑った。案の定、逆引き名を順引きしたらIPアドレスが検索されなかった。
Postfixは、逆引き名を順引きした結果が元のIPアドレスに一致するかどうかまで見る。これをパラノイド（猜疑的）検査という。逆引き名を偽造することは簡単にできるので、パラノイド検査をパスしないと逆引き名を信用しないようになっているのである。パラノイド検査をパスしなかった場合は、逆引きできなかった場合と同じく「unknown」として扱われる。sendmailもやはりパラノイド検査を行っており、逆引きできたら逆引き名はReceivedヘッダに記録するが、パラノイド検査をパスしなかったら「(may be forged)」（偽造かもしれない）と付記する。
以前、BBSで、「スパム対策のためにはパラノイド検査は不要だ」という意見を書かれた方がいる。ISPで逆引きが管理されている場合はユーザーが逆引き名を偽造することはできないし、スパマーが逆引き権限を持って逆引き名を偽造してスパムを送信した場合はIPアドレスに基づいてブロックすればよいからだという。パラノイド検査をやめた方が、世界のDNSサーバにかかる負荷を減らすことができる。確かにもっともだとは思うが、それを言ったところで、MTAのユーザーである我々としては、MTAの仕様を受け入れるしかない。
それに、もしPostfixにパラノイド検査をやめるオプションが設けられたとしても、私はそれを使わないだろう。もしかしたら、悪者が逆引き権限を持って逆引き名をたとえば「mail.microsoft.com」と偽造し、マイクロソフトからの案内であるかのように偽ってウィルスをばらまくかもしれない。Receivedヘッダに逆引き名がそのまま記載されたら、受信者には、本当にマイクロソフトから送信されたメールであるかのように見えてしまう。このやり方は詐欺メールにも使える。「unknown」と記載されるか、「(may be forged)」と付記された方が、受信者がだまされないためには安全である。
DNSサーバの負荷の問題は、さほど心配する必要はないと思う。負荷が問題になったらDNSサーバを増強すればよい。最も負荷がかかると思われるルートサーバの数も増えている。ルートサーバの名前はa.root-servers.netからm.root-servers.netまでの13個であり、これはUDPパケットの長さの制限のために増やせないのであるが、実はルートサーバの台数はもっと多い。anycast（相手任意の通信）という通信技術によって、同じ名前、同じIPアドレスのサーバを数台ずつ世界に分散配置することが可能になっているのである。
私はすぐにパラノイド検査の結果を疑った。案の定、逆引き名を順引きしたらIPアドレスが検索されなかった。
Postfixは、逆引き名を順引きした結果が元のIPアドレスに一致するかどうかまで見る。これをパラノイド（猜疑的）検査という。逆引き名を偽造することは簡単にできるので、パラノイド検査をパスしないと逆引き名を信用しないようになっているのである。パラノイド検査をパスしなかった場合は、逆引きできなかった場合と同じく「unknown」として扱われる。sendmailもやはりパラノイド検査を行っており、逆引きできたら逆引き名はReceivedヘッダに記録するが、パラノイド検査をパスしなかったら「(may be forged)」（偽造かもしれない）と付記する。
以前、BBSで、「スパム対策のためにはパラノイド検査は不要だ」という意見を書かれた方がいる。ISPで逆引きが管理されている場合はユーザーが逆引き名を偽造することはできないし、スパマーが逆引き権限を持って逆引き名を偽造してスパムを送信した場合はIPアドレスに基づいてブロックすればよいからだという。パラノイド検査をやめた方が、世界のDNSサーバにかかる負荷を減らすことができる。確かにもっともだとは思うが、それを言ったところで、MTAのユーザーである我々としては、MTAの仕様を受け入れるしかない。
それに、もしPostfixにパラノイド検査をやめるオプションが設けられたとしても、私はそれを使わないだろう。もしかしたら、悪者が逆引き権限を持って逆引き名をたとえば「mail.microsoft.com」と偽造し、マイクロソフトからの案内であるかのように偽ってウィルスをばらまくかもしれない。Receivedヘッダに逆引き名がそのまま記載されたら、受信者には、本当にマイクロソフトから送信されたメールであるかのように見えてしまう。このやり方は詐欺メールにも使える。「unknown」と記載されるか、「(may be forged)」と付記された方が、受信者がだまされないためには安全である。
DNSサーバの負荷の問題は、さほど心配する必要はないと思う。負荷が問題になったらDNSサーバを増強すればよい。最も負荷がかかると思われるルートサーバの数も増えている。ルートサーバの名前はa.root-servers.netからm.root-servers.netまでの13個であり、これはUDPパケットの長さの制限のために増やせないのであるが、実はルートサーバの台数はもっと多い。anycast（相手任意の通信）という通信技術によって、同じ名前、同じIPアドレスのサーバを数台ずつ世界に分散配置することが可能になっているのである。
火曜日, 10月 10, 2006
SQLgrey
佐藤さんのブログ記事で、SQLgreyというものがあることを知った。postgreyから派生したグレイリスティングサーバで、動的IPアドレスっぽいFQDNパターンと、メールサーバっぽいFQDNパターンを検査する正規表現が用意されていて、動的IPアドレスっぽいパターンにマッチしてメールサーバっぽいパターンにマッチしなければグレイリスティングをかけるという方式だそうである。コンセプトは佐藤さんのRgreyと同じである。
動的IPアドレスっぽいパターン：
(^|[0-9.x_-])(abo|br(e|oa)dband|cabel|(hk)?cablep?|catv|cbl|cidr|d?client2?|cust(omer)?s?|dhcp|dial?(in|up)?|d[iu]p|[asx]?dsld?|dyn(a(dsl|mic)?)?|home|in-addr|modem(cable)?|(di)?pool|ppp|ptr|rev|static|user|YahooBB[0-9]{12}|c:alnum:?{6,}(\.[a-z]{3})?\.virtua|[1-9]Cust[0-9]+|AC[A-Z][0-9A-F]{5}\.ipt|pcp[0-9]{6,}pcs|S0106:alnum:?{12,}\.[a-z]{2})[0-9.x_-]
メールサーバっぽいパターン：
^(.+[._-])*(apache|bounce|bulk|delay|d?ns|external|extranet|filter|firewall|forward|gateway|gw|m?liste?s?|(bulk|dead|mass|send|[eqw])?mail(er)?|e?mail(agent|host|hub|scan(ner)?)|messagerie|mta|v?mx|out(bound)?|pop|postfix|w?proxy|rela(is|y)|serveu?r|smarthost|v?smtp|web|www)(gate|mail|mx|pool|out|server)?[0-9]*[._-]
すげえな…
S25Rの一般規則を一つの正規表現にまとめたものと比較してみようか。
^(unknown|[^.]*[0-9][^0-9.]+[0-9]|[^.]*[0-9]{5}|([^\.]+\.)?[0-9][^.]*\.[^.]+\..+\.[a-z]|[^.]*[0-9]\.[^.]*[0-9]-[0-9]|[^.]*[0-9]\.[^.]*[0-9]\.[^.]+\..+\.|(dhcp|dialup|ppp|adsl)[^.]*[0-9])
こっちの方がずっと短い。
ついでに、9月23日の記事「Becky!でのフィルタリング」で紹介した簡易一般規則をPostfix向けに手直しすると…
^(unknown|[0-9]|[^.]*[0-9][0-9][0-9][0-9][0-9]|[^.]*[0-9]+(([a-z]|-)+|\.)[0-9])
もちろん、さらにシンプルである。これは、Postfixではさらに短く
^(unknown|[0-9]|[^.]*([0-9]{5}|[0-9]([^0-9.]+|\.)[0-9]))
とも書ける（Becky!では通用しないが）。
で、2006年7月に私のサイトへ不正メールを送り込もうとしたホスト4423個をどれだけ引っかけることができるかを比較してみた。その際、SQLgreyでの動的IPアドレスっぽいパターンの正規表現は、egrepコマンドにかかるようにするため、および「unknown」も引っかけるために、以下のように書き換えた。「:alnum:?」という書き方は謎だったが、不正メール送信の常連さんのFQDNからよきに推察して「[0-9a-f]」と書き換えた。
(unknown|(^|[0-9.x_-])(abo|br(e|oa)dband|cabel|(hk)?cablep?|catv|cbl|cidr|d?client2?|cust(omer)?s?|dhcp|dial?(in|up)?|d[iu]p|[asx]?dsld?|dyn(a(dsl|mic)?)?|home|in-addr|modem(cable)?|(di)?pool|ppp|ptr|rev|static|user|YahooBB[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]|c[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]+(\.[a-z][a-z][a-z])?\.virtua|[1-9]Cust[0-9]+|AC[A-Z][0-9A-F][0-9A-F][0-9A-F][0-9A-F][0-9A-F]\.ipt|pcp[0-9][0-9][0-9][0-9][0-9][0-9]+pcs|S0106[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]+\.[a-z][a-z])[0-9.x_-])
その結果…
SQLgrey：3781個（85.5%）
簡易一般規則：4331個（97.9%）
S25R一般規則：4344個（98.2%）
なんてこったい。SQLgreyは、ものすごい正規表現の割に、S25Rの一般規則に比べて8倍もの不正メール送信元ホストを見逃しているではないか。しかも、catv.ne.jpやadsl.ne.jpやhome.ne.jp（いずれも実在する）をドメインごと引っかけてしまう。こんなものを使うよりも、S25Rのルールを取り入れたRgreyを選ぶべきである。
自慢じゃないけど（自慢だけど）、私が作ったルールの方がはるかに簡潔でしかも効果的である。
動的IPアドレスっぽいパターン：
(^|[0-9.x_-])(abo|br(e|oa)dband|cabel|(hk)?cablep?|catv|cbl|cidr|d?client2?|cust(omer)?s?|dhcp|dial?(in|up)?|d[iu]p|[asx]?dsld?|dyn(a(dsl|mic)?)?|home|in-addr|modem(cable)?|(di)?pool|ppp|ptr|rev|static|user|YahooBB[0-9]{12}|c:alnum:?{6,}(\.[a-z]{3})?\.virtua|[1-9]Cust[0-9]+|AC[A-Z][0-9A-F]{5}\.ipt|pcp[0-9]{6,}pcs|S0106:alnum:?{12,}\.[a-z]{2})[0-9.x_-]
メールサーバっぽいパターン：
^(.+[._-])*(apache|bounce|bulk|delay|d?ns|external|extranet|filter|firewall|forward|gateway|gw|m?liste?s?|(bulk|dead|mass|send|[eqw])?mail(er)?|e?mail(agent|host|hub|scan(ner)?)|messagerie|mta|v?mx|out(bound)?|pop|postfix|w?proxy|rela(is|y)|serveu?r|smarthost|v?smtp|web|www)(gate|mail|mx|pool|out|server)?[0-9]*[._-]
すげえな…
S25Rの一般規則を一つの正規表現にまとめたものと比較してみようか。
^(unknown|[^.]*[0-9][^0-9.]+[0-9]|[^.]*[0-9]{5}|([^\.]+\.)?[0-9][^.]*\.[^.]+\..+\.[a-z]|[^.]*[0-9]\.[^.]*[0-9]-[0-9]|[^.]*[0-9]\.[^.]*[0-9]\.[^.]+\..+\.|(dhcp|dialup|ppp|adsl)[^.]*[0-9])
こっちの方がずっと短い。
ついでに、9月23日の記事「Becky!でのフィルタリング」で紹介した簡易一般規則をPostfix向けに手直しすると…
^(unknown|[0-9]|[^.]*[0-9][0-9][0-9][0-9][0-9]|[^.]*[0-9]+(([a-z]|-)+|\.)[0-9])
もちろん、さらにシンプルである。これは、Postfixではさらに短く
^(unknown|[0-9]|[^.]*([0-9]{5}|[0-9]([^0-9.]+|\.)[0-9]))
とも書ける（Becky!では通用しないが）。
で、2006年7月に私のサイトへ不正メールを送り込もうとしたホスト4423個をどれだけ引っかけることができるかを比較してみた。その際、SQLgreyでの動的IPアドレスっぽいパターンの正規表現は、egrepコマンドにかかるようにするため、および「unknown」も引っかけるために、以下のように書き換えた。「:alnum:?」という書き方は謎だったが、不正メール送信の常連さんのFQDNからよきに推察して「[0-9a-f]」と書き換えた。
(unknown|(^|[0-9.x_-])(abo|br(e|oa)dband|cabel|(hk)?cablep?|catv|cbl|cidr|d?client2?|cust(omer)?s?|dhcp|dial?(in|up)?|d[iu]p|[asx]?dsld?|dyn(a(dsl|mic)?)?|home|in-addr|modem(cable)?|(di)?pool|ppp|ptr|rev|static|user|YahooBB[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]|c[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]+(\.[a-z][a-z][a-z])?\.virtua|[1-9]Cust[0-9]+|AC[A-Z][0-9A-F][0-9A-F][0-9A-F][0-9A-F][0-9A-F]\.ipt|pcp[0-9][0-9][0-9][0-9][0-9][0-9]+pcs|S0106[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]+\.[a-z][a-z])[0-9.x_-])
その結果…
SQLgrey：3781個（85.5%）
簡易一般規則：4331個（97.9%）
S25R一般規則：4344個（98.2%）
なんてこったい。SQLgreyは、ものすごい正規表現の割に、S25Rの一般規則に比べて8倍もの不正メール送信元ホストを見逃しているではないか。しかも、catv.ne.jpやadsl.ne.jpやhome.ne.jp（いずれも実在する）をドメインごと引っかけてしまう。こんなものを使うよりも、S25Rのルールを取り入れたRgreyを選ぶべきである。
自慢じゃないけど（自慢だけど）、私が作ったルールの方がはるかに簡潔でしかも効果的である。
日曜日, 10月 08, 2006
S25Rが敗北する時は来るか？
スパマーがS25R方式の防御を突破する方法はいくつかある。
第一に、ISPのメールサーバを経由することである。防御側では、ISPのサーバをブラックリスト登録するわけにはいかない。しかし、スパムの量は抑えられる。サーバのパフォーマンスがボトルネックになるからである。それに、スパマーがサーバを過負荷にしたら、ISPも黙ってはいないだろう。
第二に、逆引きできてサーバっぽい逆引き名を持つサーバを侵害してそこからスパムをばらまくことである。私のサイトに着信するスパムには、この方法で送信されたと思われるものが多い。日本の企業や大学のサーバが乗っ取られてそこから来たスパムもあった。この場合も、おいそれとブラックリスト登録はできない。しかし、やはりスパムの量は抑えられる。乗っ取ることができるサーバは、ゾンビ化できるエンドユーザーPCに比べて非常に少ないからである。それに、乗っ取られたサーバの管理者はすぐに守りを固めるだろうから、同じサーバを長く利用し続けることはできない。
第三に、ドメインを取得してサーバっぽい逆引き名を使うことである。しかし、コストがかかるので、この方法をとれるスパマーは少ないだろう。しかも、そのホストからスパムばかりが来ることがわかれば、ブラックリスト登録によって防御できる。
第四に、まともなMTAを使うか、あるいはゾンビPCにまともなMTAと同じ動作をさせることである。つまり、「450」の拒否応答に対して何時間もリトライを続け、tarpitting（応答遅延）に対しても5分間辛抱強く待つ。スパム送信コンピュータにかかるリソース負荷が大きくなるが、技術的に不可能ではない（今の大半のスパマーがそうしていないのは、そうしなくてもスパムの送達に成功することが多いからである）。もし多くのスパム送信がそういうものになったら、S25R方式の運用は困難を極めることになるだろう。アクセス元が正当なメールサーバかスパム送信コンピュータかの区別ができなくなるからである。
しかし、そうなってもまだS25R方式は負けてはいない。受けてからフィルタリングする方法が残っている。SpamAssasinのようなフィルタリングプログラムで、送信元の逆引き名を検査し、S25Rの拒否条件に引っかかるものに「スパムの疑いあり」のマークを付けて配信すればよい。そうすれば、受信者は容易にスパムをごみ箱行きにできる（間違ってごみ箱行きになった正当なメールはごみ箱から回収すればよい）。
結局のところ、S25R方式は半永久的にスパムに敗北しないと私は考える。
もっとも、当分は、S25R方式で拒否応答を返す方法が無力化する心配はない。大多数のサイトがスパムに対して無防備な状況では、スパマーは、防御の固い少数のサイトを攻撃するためにわざわざスパム送信コンピュータに大きなリソース負荷をかけたりはしないだろう。逆説的な言い方だが、S25R方式が世界中でこぞって採用される時が来るまでは、S25R方式は安泰である。
第一に、ISPのメールサーバを経由することである。防御側では、ISPのサーバをブラックリスト登録するわけにはいかない。しかし、スパムの量は抑えられる。サーバのパフォーマンスがボトルネックになるからである。それに、スパマーがサーバを過負荷にしたら、ISPも黙ってはいないだろう。
第二に、逆引きできてサーバっぽい逆引き名を持つサーバを侵害してそこからスパムをばらまくことである。私のサイトに着信するスパムには、この方法で送信されたと思われるものが多い。日本の企業や大学のサーバが乗っ取られてそこから来たスパムもあった。この場合も、おいそれとブラックリスト登録はできない。しかし、やはりスパムの量は抑えられる。乗っ取ることができるサーバは、ゾンビ化できるエンドユーザーPCに比べて非常に少ないからである。それに、乗っ取られたサーバの管理者はすぐに守りを固めるだろうから、同じサーバを長く利用し続けることはできない。
第三に、ドメインを取得してサーバっぽい逆引き名を使うことである。しかし、コストがかかるので、この方法をとれるスパマーは少ないだろう。しかも、そのホストからスパムばかりが来ることがわかれば、ブラックリスト登録によって防御できる。
第四に、まともなMTAを使うか、あるいはゾンビPCにまともなMTAと同じ動作をさせることである。つまり、「450」の拒否応答に対して何時間もリトライを続け、tarpitting（応答遅延）に対しても5分間辛抱強く待つ。スパム送信コンピュータにかかるリソース負荷が大きくなるが、技術的に不可能ではない（今の大半のスパマーがそうしていないのは、そうしなくてもスパムの送達に成功することが多いからである）。もし多くのスパム送信がそういうものになったら、S25R方式の運用は困難を極めることになるだろう。アクセス元が正当なメールサーバかスパム送信コンピュータかの区別ができなくなるからである。
しかし、そうなってもまだS25R方式は負けてはいない。受けてからフィルタリングする方法が残っている。SpamAssasinのようなフィルタリングプログラムで、送信元の逆引き名を検査し、S25Rの拒否条件に引っかかるものに「スパムの疑いあり」のマークを付けて配信すればよい。そうすれば、受信者は容易にスパムをごみ箱行きにできる（間違ってごみ箱行きになった正当なメールはごみ箱から回収すればよい）。
結局のところ、S25R方式は半永久的にスパムに敗北しないと私は考える。
もっとも、当分は、S25R方式で拒否応答を返す方法が無力化する心配はない。大多数のサイトがスパムに対して無防備な状況では、スパマーは、防御の固い少数のサイトを攻撃するためにわざわざスパム送信コンピュータに大きなリソース負荷をかけたりはしないだろう。逆説的な言い方だが、S25R方式が世界中でこぞって採用される時が来るまでは、S25R方式は安泰である。
日曜日, 10月 01, 2006
1時間近くリトライするスパム
次のようなスパムアクセスを見つけた。
Sep 29 05:13:36 unknown [74.130.145.173]
Sep 29 05:18:43 unknown [74.130.145.173]
Sep 29 05:23:50 unknown [74.130.145.173]
Sep 29 05:57:26 unknown [74.130.145.173]
Sep 29 06:03:12 unknown [74.130.145.173]
5分余りの間隔で3回トライし、その後33分余りたってから、また5分余りの間隔で2回トライしている。8月28日の記事「リトライするスパムをRgreyで蹴る」で、最初のアクセスからアクセスを受け入れるまでの遅延時間を25分にすれば、リトライするスパムをほとんど阻止できると書いた。しかし、そのようにしても上記のアクセスはすり抜けてしまう。かといって、遅延時間をあまり長く設定するわけにもいかないだろう。
考えてみると、スパマーにとって、スパム送信コンピュータにあまりリソース負荷をかけずにRgreyを突破するのは、さほど困難ではないと思われる。「450」の拒否応答が返された宛先をアドレスリスト上でマークしておき、30分～1時間後に、送信者アドレスを変えずに再送信すればよい。
そのような手口にどう対抗するかというと、佐藤さんのStarpit（S25R+tarpitting）が有効だろう。たくさんの宛先サーバからtarpitting（応答遅延）を食らうと、プロセスが増加しすぎてリソース負荷に耐えきれなくなるので、送信を早々にあきらめてしまうと考えられるからである。
ところが、それでも安心してはいられない。佐藤さんのブログ記事によると、STRATIONウィルスは65秒のtarpittingを抜けるそうである。このことから考えると、スパマーは、たくさんのゾンビPCを操ることによって、リソース負荷の問題も克服してしまうかもしれない。
RgreyもStarpitもすり抜けるスパムが増えたらどうするか。そうなったら、通過したメールをSpamAssasinのようなフィルタリングプログラムにかけて、送信元の逆引き結果を再度検査し、S25Rの拒否条件に引っかかるものに「スパムの疑いあり」とマーキングして配信するのがよいと思う。正当なメールがマーキングされることはあっても、取りこぼす心配はない。
もっとも、上記のようなアクセスは今のところレアケースである。当分は、S25R方式やそれを応用した方式によって90%以上のスパムを排除し続けることができるだろう。それというのも、まだ大半のサイトがスパムに無防備だからである。だからスパマーは、軽いリソース負荷で、いい気になってスパムを大量配信することができるのである。強力な防御策が多くのサイトに普及した時には、スパマーは、さらにそれを破る手を打ってくるだろう。
Sep 29 05:13:36 unknown [74.130.145.173]
Sep 29 05:18:43 unknown [74.130.145.173]
Sep 29 05:23:50 unknown [74.130.145.173]
Sep 29 05:57:26 unknown [74.130.145.173]
Sep 29 06:03:12 unknown [74.130.145.173]
5分余りの間隔で3回トライし、その後33分余りたってから、また5分余りの間隔で2回トライしている。8月28日の記事「リトライするスパムをRgreyで蹴る」で、最初のアクセスからアクセスを受け入れるまでの遅延時間を25分にすれば、リトライするスパムをほとんど阻止できると書いた。しかし、そのようにしても上記のアクセスはすり抜けてしまう。かといって、遅延時間をあまり長く設定するわけにもいかないだろう。
考えてみると、スパマーにとって、スパム送信コンピュータにあまりリソース負荷をかけずにRgreyを突破するのは、さほど困難ではないと思われる。「450」の拒否応答が返された宛先をアドレスリスト上でマークしておき、30分～1時間後に、送信者アドレスを変えずに再送信すればよい。
そのような手口にどう対抗するかというと、佐藤さんのStarpit（S25R+tarpitting）が有効だろう。たくさんの宛先サーバからtarpitting（応答遅延）を食らうと、プロセスが増加しすぎてリソース負荷に耐えきれなくなるので、送信を早々にあきらめてしまうと考えられるからである。
ところが、それでも安心してはいられない。佐藤さんのブログ記事によると、STRATIONウィルスは65秒のtarpittingを抜けるそうである。このことから考えると、スパマーは、たくさんのゾンビPCを操ることによって、リソース負荷の問題も克服してしまうかもしれない。
RgreyもStarpitもすり抜けるスパムが増えたらどうするか。そうなったら、通過したメールをSpamAssasinのようなフィルタリングプログラムにかけて、送信元の逆引き結果を再度検査し、S25Rの拒否条件に引っかかるものに「スパムの疑いあり」とマーキングして配信するのがよいと思う。正当なメールがマーキングされることはあっても、取りこぼす心配はない。
もっとも、上記のようなアクセスは今のところレアケースである。当分は、S25R方式やそれを応用した方式によって90%以上のスパムを排除し続けることができるだろう。それというのも、まだ大半のサイトがスパムに無防備だからである。だからスパマーは、軽いリソース負荷で、いい気になってスパムを大量配信することができるのである。強力な防御策が多くのサイトに普及した時には、スパマーは、さらにそれを破る手を打ってくるだろう。
登録:
投稿 (Atom)