金曜日, 5月 29, 2015

数字だけのサイトドメイン名のホストの挙動

 前回、スパムを送ってくる、サイトドメイン名が数字だけから成る様々なドメインを挙げた。いずれも末端ホスト名はS25Rに引っかからない、英字だけから成る名前なので、ISPに直結したPCがボット化したものとは思われず、スパマーがドメインを多数取得してスパム送信用コンピュータを運用しているものと思われる。
 しかしその挙動は、まともに再送信するメールサーバのそれではなく、ボットそっくりである。拒絶ログソーティングスクリプトの表示形式で示す。

May 22 20:27:53 C alone.000086.net [69.12.83.148] from=<m***@mail.com> to=<w***@gabacho-net.jp> helo=<alone.000086.net>

1回きりの送信で、再送信していなかった。

May 25 12:34:41 C dove.150686.com [89.35.134.136] from=<m***@yandex.com> to=<w***@gabacho-net.jp> helo=<dove.150686.com>
May 25 13:34:46 C dove.150686.com [89.35.134.136] from=<m***@yandex.com> to=<w***@gabacho-net.jp> helo=<dove.150686.com>

1時間後に1回だけ再送信したように見える。しかし、2通のスパムを再送信なしで送信したものという可能性もある。

May 29 13:21:27 C right.68706.net [199.180.255.251] from=<d***@yandex.com> to=<w***@gabacho-net.jp> helo=<right.68706.net>

May 29 13:50:16 C right.68706.net [199.180.255.251] from=<q***@yandex.com> to=<w***@gabacho-net.jp> helo=<right.68706.net>
May 29 16:26:05 C right.68706.net [199.180.255.251] from=<q***@yandex.com> to=<w***@gabacho-net.jp> helo=<right.68706.net>

前回挙げた中にない新しいホストである。送信者アドレスは2件で、2件目は再送信したように見えるが、時間間隔は2時間半以上。まともなメールサーバにはまずない挙動である。
 こんな挙動だから、

/^(.+\.)?[0-9]{5}[^.]*\.(com|net)$/ 450 domain check, be patient

という設定はお勧めだと思う。

月曜日, 5月 25, 2015

数字で始まるサイトドメイン名――今までに見つかったもの

 5月1日の記事で紹介した

/^(.+\.)?[0-9]{5}[^.]*\.(com|net)$/ 450 domain check, be patient

という拒否条件は、「トップレベルドメインがcomかnetで、サイトドメイン名は5桁以上連続する数字列で始まる」という条件である。これに引っかかるホストは、すでに着信してしまったものと阻止に成功したものとを併せて、これだけある。

coco.27838.net [103.1.149.180]
july.7819888.com [104.171.113.11]
rain.828873.com [162.244.79.167]
west.488859.com [107.179.86.53]
yamoy.9001888.com [178.251.230.21]
gonna.135328.com [198.144.181.6]
alone.000086.net [69.12.83.148]
dove.150686.com [89.35.134.136]

けっこうよく効く拒否条件のようである。
 惜しくもこれに引っかからないものには

pizza.89mt.com [216.107.147.253]
chu.0530ok.com [192.254.79.254]

があったが、サイトドメイン名の数字列の条件を「5桁以上」よりも短くすることまではしていない。

 それと、3qbo.netというドメインは見るからに怪しいとまでは言えないが、mta3.3qbo.netやmta44.3qbo.netなど配下の多くのホストから<otori1@gabacho-net.jp>というおとりのアドレス(2003年にスパムの研究のためにホームページに仕掛けたもので、とっくにuser unknownになるようにしている)に宛てて何度もスパムアクセスがある。まともなウェブサイトが組まれていないようだということもあるし、怪しいドメインかな?

金曜日, 5月 22, 2015

本文チェックによるブロック――続編

 5月19日「本文チェックによるブロックに成功」で、

/@aliyun\.com/ REJECT

という本文チェックでスパムのブロックに成功したことを述べた。
 過去に着信したスパムを調べたところ、「***@tom.com」というメールアドレスが本文に書かれたスパムも2月25日から5月20日にかけて7通あったことに気付いた。そこで、

/@tom\.com/ REJECT

というチェックも加えた。
 その成果は3回あった。日付と送信元は以下のとおりである。

May 21 00:07:05 jelly.juiceupcleanse.net[103.41.176.17]
May 21 02:08:42 jelly.juiceupcleanse.net[103.41.176.17]
May 22 21:28:03 mar.xzmp4.com[103.41.176.16]

 今気付いたんだが、送信元の逆引き名のドメインは全然違うけど、IPアドレスは隣なんだな。

 なお、aliyun.comもtom.comもウェブサイトを持っていて、中国のサイトだとわかった。これらのサイトがスパムに一枚噛んでいるとも考えられるが、連絡先アドレスを単に利用されているかかたられている可能性も否定できないと思った。そこで、該当するどのスパムでもこれらのメールアドレスの前に「Email:」または「Contact:」という語があったことを考慮して、無実のメールが誤ってブロックされるリスクを減らすために、body_checksの記述を次のように変更した。

/(E-?mail|Contact):.+@tom\.com/ REJECT
/(E-?mail|Contact):.+@aliyun\.com/ REJECT

火曜日, 5月 19, 2015

hinet.net

 2003年にS25R方式の開発を始めてから2004年の発表の数年後までの時期にスパム発信の常連さんだったドメインの多くは、スパムの発信源になることがほぼなくなった。逆引きをまともに設定しているISPの多くにOP25Bが普及したからだろう。
 しかし、その中でhinet.netは、相当大規模なISPにもかかわらず未だにOP25Bの導入を拒んでいると見える。5月に入ってからもこーんなにある。

May  1 14:30:42 114-45-24-226.dynamic.hinet.net
May  1 18:08:11 118-161-243-204.dynamic.hinet.net
May  3 16:17:56 118-161-243-52.dynamic.hinet.net
May  3 18:03:58 118-166-215-6.dynamic.hinet.net
May  3 18:35:41 118-161-245-200.dynamic.hinet.net
May  4 16:00:05 111-243-59-212.dynamic.hinet.net
May  5 14:39:57 118-165-146-172.dynamic.hinet.net
May  8 06:50:46 118-166-236-82.dynamic.hinet.net
May  8 16:50:42 118-166-251-85.dynamic.hinet.net
May 12 13:08:20 36-224-128-84.dynamic-ip.hinet.net
May 14 09:01:55 114-37-190-188.dynamic.hinet.net
May 15 15:54:46 111-243-60-50.dynamic.hinet.net
May 18 09:40:41 114-43-245-162.dynamic.hinet.net
May 19 02:39:04 1-160-126-37.dynamic.hinet.net
May 19 06:18:22 36-225-28-13.dynamic-ip.hinet.net

 なぜかここのところ、hinet.netからはことごとく第三者中継を目論むアクセスなのだが、正しいアドレスに宛てたスパムだろうと、S25Rに引っかかるから全然やっかいではない。かつて私は、「受信側対策としてのS25Rがあれば、送信側対策としてのOP25Bはやってくれなくても全然かまわない」と思っていた。
 しかし今は、OP25Bの普及はつくづくありがたいと思っている。スパムアクセスの総数が非常に減ったからという理由もあるが、最も大きな理由は、「動的IPアドレスのメールサーバの存在を無視するS25Rはけしからん」という批判ができなくなったことである。「正当なメールは、送信側エンドユーザーコンピュータ(特に動的IPアドレスのもの)からは受信側メールサーバへ直送せず、送信側メールサーバで中継する」という具合にメール配送ルートに秩序を持たせるというコンセプトにおいて、S25RとOP25Bには共通性があるのである。

こんなドメインあるんだねえ

 2015年4月24日に、第三者中継を目論むこんなアクセスがあった。

Apr 24 09:16:49 reject: RCPT from ip98.ip-5-135-192.eu[5.135.192.98]: 554 5.7.1 <***@gmail.com>: Relay access denied; …
Apr 24 09:16:51 reject: RCPT from ip98.ip-5-135-192.eu[5.135.192.98]: 554 5.7.1 <***@gmail.com>: Relay access denied; …
Apr 24 09:16:52 reject: RCPT from ip98.ip-5-135-192.eu[5.135.192.98]: 554 5.7.1 <***@gmail.com>: Relay access denied; …

 euは欧州連合の国ドメインである。トップレベルドメインの直下がIPアドレスの上位3オクテットをそのまま反映したドメイン名になっているなんて初めて見た。
 第三者中継はS25Rチェックよりも先にチェックするように設定しているので「Relay access denied」で蹴っているが、この送信元の逆引きFQDNは一般規則のルール4に引っかかる。ルール3はsmtp.246.ne.jp(実在)を蹴らないように、ルール5はmail1.number1.co.jp(ホスト名は架空、ドメイン名は実在)を蹴らないように上位3階層を検査から除外するようにしていて、ルール4もmail1.1-2-3.co.jp(ホスト名は架空、ドメイン名は実在)を蹴らないようにしようかと検討したのだが、wbar9.chi1-4-11-085-222.dsl-verizon.netやm226.net81-66-158.noos.fr(2003年のS25R開発時に発見されたスパム送信元の実例)を蹴れるように、ルール4についてはその偽陽性回避策を採らなかったからである。

本文チェックによるブロックに成功

 本文に共通点のあるスパムが最近4件着信していた。日付、送信元、サブジェクトを示す。

2015/04/03 july.7819888.com "we can bring you buyers"
2015/04/09 rain.828873.com "need pics retouching?"
2015/04/16 pizza.89mt.com "need email marketing?"
2015/05/06 boo.bianmingdai.com "find new customers"

 本文の共通性というのは、
Contact: ***@aliyun.com
または
Email: ***@aliyun.com
という文が入っていることである。メールアドレスのユーザー名は毎回違っていたが、aliyun.comは一定。これはスパマーがコンタクトを受けるためのドメインだと推測した。ユーザー名をいくつでも用意するのは簡単だろうが、ドメインはそうそういくつも用意できないだろう。そこで、body_checksに

/@aliyun\.com/ REJECT

と設定していた。
 これで5月15日に1件、送信元chu.0530ok.comからのスパムのブロックに成功していた。送信者アドレスのドメインはyahoo.comで、送信元はyahoo.comのSPFと一致しないので、蹴飛ばして問題なかっただろう。
 なお、4月11日の記事にも書いたとおり、このようなブロッキングは、個人サイトか、ユーザー全員の了解を得ることができる小規模サイトでなければお勧めしない。私がこれを書いているのは、あくまでも自分の活動日誌として、また、閲覧者への単なる参考のためである。対策なしでは一日200通ほどのスパムを受けていた人も、S25Rによってスパムの受信は一日数通(グレイリスティングなどで偽陽性判定からの自動救済をしていてもおそらく10通程度)と、仕事を邪魔されない程度にまではなっているはずだから、業務でメールシステム管理をしている人は、こんな趣味的なブロッキングにうつつを抜かすべきではない。

火曜日, 5月 12, 2015

サブジェクトでの拒否が突き抜けられた

 4月11日の記事

/Subject: .*(photo|image|pic|picture)s? +(retouching|editing|clipping|cut ?out)/ REJECT

という拒否条件を設定したことを述べたが、今日(5月12日)、「image solutions」というサブジェクトで突き抜けられた(送信元はlondon.weisim.net)。拒否条件を次のように変更した。

/Subject: .*(photo|image|pic|picture)s? +(retouching|editing|clipping|cut ?out|solution)/ REJECT

今回は「solutions」と複数形だったが、単数形でも引っかかるようにした。もちろん、後続の文字の条件は指定していないので複数形でも引っかかる。

日曜日, 5月 03, 2015

迷惑電話対策

 迷惑メールでなく迷惑電話の話。
 我が家の固定電話に、出たらすぐに切れてしまうという変な電話がかかってくることが時々あった。かつて使っていたISDNとは違って、ひかり電話では発信番号通知がデフォルトではないので、追加で契約した。
 出たらすぐに切れてしまうのは番号非通知のコールだとわかった。電話機に「ヒツウチ」と表示された時にはほったらかしてみたら、決まって呼び出し音10回で切れた。何のためにかけてくるのか、わけわからん。
 電話機に、番号非通知のコールに対して「番号を通知してかけ直せ」とアナウンスを返して切る機能があったので、ナンバーリクエストサービスを追加契約しなくても対策ができた。reject_unknown_clientのようなものだな。ちょっと違うけど。
 ひかりルータのログを見ると、番号非通知のコールは2014年12月に2回、2015年1月に1回、2月に1回、3月に9回、4月に2回あった。最も新しい記録は4月25日である。敵はまだあきらめてはいないものと見える。

 それで思い出したのだが、NTTの発信番号通知サービスの開始がアナウンスされたころ、タモリさんがラジオ番組で「かけ手側では番号の通知を(184をダイヤルして)拒否できる?でも受け手側では番号非通知の電話を拒否できる?わけわからん」という意味のことを言っていた。一見相対立するポリシーだが、かけ手が悩み事相談などで自分のプライバシーを守りたい時には番号通知を拒否できるし、受け手が「いのちの電話」や事業者ならば番号非通知のコールも拒否しない、一方、一般家庭では身元を隠すかけ手からのコールを拒否したいと思えばできるということである。ユーザーのポリシーで選択できるということで、それは言い換えれば、ユーザーは自分のために最も良いサービスの選択を自分で判断しなければならない、選択の自由度が高まれば選択の責任は自分が負うということである。今は広く理解されていることだと思うが、当初は一般ユーザーにはなかなか理解しにくかったようである。

金曜日, 5月 01, 2015

サブジェクトで拒否&数字だけのサイトドメイン名――続編

 前回、サブジェクトの拒否条件を紹介した。header_checksに設定している条件は次のとおり。

/Subject: .*(photo|image|pic|picture)s? +(retouching|editing|clipping|cut ?out)/ REJECT

これでまた成果があった。日付、送信元ホスト、サブジェクトを示す。

2015/04/29 beijing.china-fxcm.com "pics editing solutions"

これの前の4月9日に着信したスパムのサブジェクトは「need pics retouching?」だったのだが、さらに語を変えてきたのをうまく撃退できた。

 それと、4月16日に「need email marketing?」というサブジェクトのスパムがpizza.89mt.comから着信したので、header_checksに

/Subject: .*email +marketing/ REJECT

を加えておいたら、4月20日に「email marketing」というサブジェクトのスパム(送信元はkim.dq95.com)をブロックできた。その後、「email」を「e-mail」と変えてきてもブロックできるように、

/Subject: .*e-?mail +marketing/ REJECT

と変更している。

 数字だけのサイトドメイン名に対する警戒策の成果は、その後2件あった。拒絶ログソーティングスクリプトの表示形式で示す。いずれもリトライはなかった。

Apr 21 23:52:10 C yamoy.9001888.com [178.251.230.21] from=<***@mail.com> to=<***@gabacho-net.jp> helo=<yamoy.9001888.com>

Apr 23 19:36:16 C gonna.135328.com [198.144.181.6] from=<***@mail.com> to=<***@gabacho-net.jp> helo=<gonna.135328.com>

 その後、拒否条件を次のように変更している。

/\.[0-9]+\.(com|net)$/ 450 domain check, be patient

/^(.+\.)?[0-9]{5}[^.]*\.(com|net)$/ 450 domain check, be patient

理由は、ニッポン放送の1242.comのような真っ当なドメインはあるが(これはメール用であって逆引き名には使われていないかもしれないけれども)、スパムを送ってきた数字だけのサイトドメイン名はいずれも数字5桁以上であること、サイトドメイン名が数字で始まって数字が5桁以上続いたら、あとは英字が含まれていても不自然な名前として警戒してよいだろうと考えたこと、それと、末端ホスト名が省略された逆引き名であっても引っかけようと考えたからである。