モーグルとカバとパウダーの日記

モーグルやカバ(EXカービング)山スキー(BC)などがメインの日記でした。今は仕事のコンピュータ系のネタが主になっています。以前はスパム対策関連が多かったのですが最近はディープラーニング関連が多めです。

メールアカウント盗られてこっそり受信されている例が結構ある話

ここのところサブミッションスパムが出されることが一定の頻度で続いていて最悪なのですが、そのことを調べていた時にちょっとイヤな例を見つけました。

サブミッションスパムで使われたアカウントがあり、ふとそのアカウントでメールの受信は来てるのかな?と確認しました。
すると、日本国内からのアクセスはないのに mail.ru ドメインからのアクセスがだいたい1時間に1回と定期的に来ていたのを見つけました。

mail.ru はロシアでメールサービスやっているところのドメインで、VPSのようなサービスもやっているところです。
なのでそこのWebメールサービスにアカウントが登録されていて、そこから受信が行われている、という可能性は考えられます。

ですが、その接続があった付近のIPで検索すると、他にも同様にアクセスされているアカウントがいくつもありました。
そしてそのうち一つは、その少し前にサブミッションスパムが出されていたものでした。
アカウント数を数えてみると、これまでサブミッションスパムで利用されてしまったよりも数倍多くありました。

あくまで状況証拠からですが、クラックされたアカウントが定期的に受信がされている、と考えるのが自然と思います。

状況まとめると

  • 外部からこっそり受信のみが行われているアカウントが結構ある
  • それらは1時間に1度くらいの頻度でメールが覗かれている

となります。

つまり、アカウント情報のもれたメールアカウントのメールを監視している大規模なネットワークが存在しているということなのです。

例えば、アカウント設定の再送をメールで行ったりしたのをフックして、そのアカウントも盗ってしまうとか、そういうのを自動でやってるのかなあ、と想像します。

これのなにが恐ろしいって、メール受信されていることをユーザは全く感知できない、ということです。

これ、大手ISPなんかだと、GoogleやLINEみたいに、普段の接続ではないIPからメール受信されました、みたいなアラート上げたりしてるんだろうか…?

こういうのって最近のセキュリティ界隈では結構知られていることなのでしょうかね?

(追記)

mail.ruのPOPしてくるIPからであること確認できたので、mail.ruに受信確認の設定がされているのだと思います。

またスマホから一つのメールアプリでまとめて読むために、mail.ruを使われる需要が結構あるようで、それように普通に設定していた可能性も高いです。

ただ、サブミッションスパムで利用されたアカウントとの重複率がだいぶ高いため、なんらかの理由で相関があるのだと思います。

例えば、そのようなユーザは他にもmail.ruのようなメール一括受信アプリを試している場合が多く、そこから漏れた or アカウント取得を主目的としたマルウェアを使ってしまった、などです。

このあたりは完全にこう、というのは結論づけることはできなそうですが。

身に覚えのないDNSBL登録の理由

これは「メール Advent Calendar 2018」のために書かれたエントリです。

スパムが出てないのにDNSBLに登録されてしまう

DNSBLというDNSを用いた公開ブラックリストサービスがあります。SORBSやSpamCopあたりが有名です。
DNSBLは、正しくはスパマーの使っているbot等のIPアドレスだけが登録されているべきなのですが、誤って通常のメールサーバがDNSBLに登録されてしまう場合があります。
最近では、サブミッションスパムによりそのメールサーバから大量スパムメールが出されて、登録されてしまう場合が多いです。

しかし時々、全くそのような大量スパムメールが出されたわけではないのにDNSBLに登録されてしまう場合がありました。

そういうなにもしていないのに登録されている場合、近隣のIPでスパムを出したサーバがあったとき、IPアドレス帯でまきこまれて登録されてしまうことが多いです。

DNSBLではたいてい、そのIPアドレスブラックリストに登録されているか確認出来るようになっています。
その情報を確認すると、IPアドレス帯で登録されたわけではなく、確かにそのメールサーバから出されたメールが原因で登録されたものでした。

届いたスパムをエラーメールで返したもので登録されている

DNSBLによっては、どのメールが引き金となって登録されたのか確認出来るようになっています。

またDNSBLでは、ハニーポットという「おとり」のメールアドレスを使って、そこにメールが届いた場合、その発信元IPをブラックリストに入れてしまうものがあります。
ハニーポットのメールアドレスがスパマーにバレてしまうと、そのメールアドレスを避けて送るようにされてしまう可能性があるため、どのメールアドレスかは秘匿して運用されています。
そのため、どのメールにより登録されたかという情報は、日時を範囲にしたり、メールアドレスは一部をマスクしたりして、ハニーポットのメールアドレスがわからないように提示されています。

該当のブラックリスト登録情報を確認したところ、日時は前後5分内ということでぼかされており、メールアドレスは下記のようにマスクされていました。

dov**********************-0@************

ただ、非常に特徴的なメールアドレスだったため、ログから確認すると、宛先のスプールがいっぱいのため dovecot がエラーメールを返したものだと確定することが出来ました。

また、そのエラーメールの元となったメールのfromメールアドレスを確認すると、下記のようなメールアドレスでした。(一部マスクしています)

yvfks****+err22****139@ksulde.com

このドメインでぐぐってみたところ、下記のような日本語スパムであることがわかりました。

【本日限り】2択クイズ正解で総額1億円プレゼント
⇒ http : //ksulde.com/qow/swmc8.php?tb=****

いつもメールをお読みくださりありがとうございます。

今日は、いつも仲良くさせて頂いているGive to Win運営事務局の馬場さんから
スペシャルなプレゼント企画がある」ということで、ご案内を頂きました。
(以下略)

【誰でも1億円!】ミリオネアクイズ開催中!???: 気まぐれ日記

つまり、届いた日本語スパムをエラーメールで返したところ、それを理由としてDNSBLに登録されてしまった、ということになります。

(itochanさんのブックマークコメントいただいた件で補足追記)

このスパムは、日本語スパムでよくある、適当なドメインを大量取得して、そのドメインでWebとメールサーバとを動かしているタイプのものです。
なのでスパムに対して返信するとちゃんとメールが届くようになっています。
fromメールアドレスにはシリアル値が付加されているため、どのメールアドレスに送った返事なのかもわかるようになっていると考えられます。

スパマーDNSBLへ通報されている

そこで、なぜdovecotのエラーメールでブラックリスト登録されてしまうのか、考えてみました。

  1. エラーメールの返した先がDNSBLハニーポットだった
  2. エラーメールを受け取ったところがスパム判定してDNSBLに通報した

最初、届いていたスパムが日本語スパムだと気が付かなかったので、【1】のbotDNSBLハニーポットのメールアドレスを騙ってきているのでは、と考えました。なんていやらしいことしてくるんだ、と。

が、日本語スパムの場合、そんな手の込んだことをしてくるとは思えず、そうすると【2】のエラーメールが返ってきたものを、スパムフィルタにより自動でDNSBLへ通報してしまったのではないか、と考えました。
例えばSpamAssassinだと、スパム判定したものを自動でSpamCopにレポートするプラグインがあります。
Mail::SpamAssassin::Plugin::SpamCop - perform SpamCop reporting of messages

たぶんこちらのほうがありそうでしょう。
出会い系などの日本語スパムは、スパムに返信されてきたら人力でテンプレの返答を返して、ユーザ登録なりなんらかの振り込みをさせるよう誘導します。
でも当然大量にエラーメール等も届くはずで、それをなんらかのフィルタで選り分けている可能性は高いと思います。
そこでスパムフィルタが効いていると、自分が送ったメールの内容でスパム判定され、そのエラーメールの送り元=スパムの送り先メールサーバを自動通報してしまっている、というわけです。

非常にげんなりしてしまう話ですが、まったく身に覚えのないDNSBL登録にあったら、この可能性も考えてみるといいでしょう。

サブミッションスパムの手法変遷

これは「メール Advent Calendar 2018」のために書かれたエントリです。

また元ネタは今年の6月に開かれたNSEGという長野の勉強会で発表した内容の後半にあります。

NSEG 勉強会 #101 / メールとコミュニケーションツール - connpass
スパム対策お焚き上げ

今北産業

  • サブミッションスパムはここ2,3年ですごい増えた
  • アカウントはサブミッションポートへの辞書攻撃で取られるようになった
  • ばれないようにちょっとづつ送ったりするようにもなった

はじめに

今から6年半前の2012/5頃に、サブミッションスパムというあたらしいタイプのスパム送信方法で送られたスパムにより、各ISPのメールサーバに障害起きたりする事例がありました。

「サブミッションスパム」による5/15〜16のメール障害の解説と対策

これは、クラックしたアカウントを使い、サブミッションポートでユーザ認証したアカウントからスパムを出されたことから、そう名前を付けたものです。

その後自分は、tarpittingを利用したサブミッションスパムへの対策方法などのエントリも書いたりしています。

Postfixでのサブミッションスパムの簡易対策方法

一時は下火となっていたサブミッションスパムでしたが、ここ2,3年くらいで再度増えてきており、その手法が細かなところで違ってきているため、その説明をします。

アカウントの取得方法の変化

2012/5当時のエントリーでは

どうやってアカウントを取得したか
どうやってユーザのアカウントを取得したかは、具体的な証拠はありませんが、状況からみて以前に該当ユーザのPCにウイルスを感染させて取得した可能性が高いと考えられます。

「サブミッションスパム」による5/15〜16のメール障害の解説と対策

と書いていました。

これは使われたアカウントがバラバラでパスワードも脆弱とは考えにくいもので、またPOP3やSubmissionポートへの辞書攻撃らしいアクセスも残っていなかったためでした。

最近サブミッションスパムでやられているアカウントを調査すると、サブミッションポートに対して辞書攻撃が行われているようで、同一アカウントに対して複数の海外IPから認証が行われ、パスワードのエラーが起きていることが確認できます。
そしてそのIPからの認証が通ってしまうと、数時間後に別のIPからサブミッションでの認証が行われ、スパムの大量送信が行われます。ちなみにこの送信時には、動的IPではなくてクラウドサーバが使われていることが多いようです。

サブミッションポートに対してのエラー数をカウントしてみました。

f:id:stealthinu:20181211154252p:plain

ここ数年で急激にサブミッションポートに対しての辞書攻撃が増えていることがわかります。

これはサブミッションでなくPOP3などでもよいはずですが、サブミッションのほうが狙われているようです。
この手のブルートフォースに対してPOP3よりサブミッションのほうが対策されていない可能性が高いからでは、と推測しています。

こっそり送る

クラックされたアカウントを事前に検知できないか調査していて、おもしろいことに気が付きました。

サブミッションスパム送信元と同じクラウドサーバのIPから送信が行われているのに、大量メール送信ではなくてちょっとづつ(10件程度とか)をときどき送信しているものがあるのです。
送信しているメールの内容を確認できないため、スパムが送られているのかどうかはわかりませんが、送信先などから考えてもほぼ間違いなくスパムが送られていると考えられました。

これまでサブミッションスパムは、クラックしたアカウントで一気に大量のスパムを出して、メールサーバ管理者に見つかってアカウントを止められる、という運用のされ方でした。
それが、監視ツールのアラートが上がらない程度に「こっそり」と送ることで、息が長くアカウントを使えるようにしているものもある、ということです。

サブミッションスパムはつらい

サブミッションスパムによる大量スパム送信はサーバに負荷がかかります。
メールスプールに大量にメールが溜まったり、エラーメールが大量に返ってきたりするためです。
一番つらいのがDNSBLへ登録されてエラーで弾かれるようになって、他のユーザからメールが届かなくなったと言わることです。
先日の迷惑メールカンファレンスでもサブミッションスパムの件がよくネタに出てきていました。ほんとなんとかならんもんでしょうかね。

botからのスパム送信の推移とSMTPセッションフィルタの終焉

これは「メール Advent Calendar 2018」のために書かれたエントリです。

元ネタは今年の6月に開かれたNSEGという長野の勉強会で発表した内容です。
勉強会の動画も上がってますので興味持たれた方はこちらもぜひ。

NSEG 勉強会 #101 / メールとコミュニケーションツール - connpass
スパム対策お焚き上げ

今北産業

  • botnetから送られるスパムが激減した
  • SMTPセッションフィルタでのスパム対策は不要になりつつある
  • 諸行無常

はじめに

自分は2006年頃から taRgrey というスパム対策手法を提案しています。

taRgrey - S25R + tarpitting + greylisting (tarpit + greylist policy server)

これはSMTPセッション中のクライアントの特徴を利用するフィルタをいくつか組み合わせた手法で、 S25Rtarpittinggreylisting を組み合わせて、誤検出や副作用をなるべく少なくすることを狙ったものです。

ただ、近年スパムの数も徐々に減ってきており、また徐々に効果が少なくなってきたと感じていました。

そこでSMTPセッションフィルタがどの程度効果が出ているのか、2010年から2018年にかけての推移を確認しました。

2010年当時のスパム状況

2010年当時はまだスパム全盛期でまだ増えていく感じがありました。
特にbotnetというウイルスに感染したPCを大量に遠隔で操作し、そこから大量にスパムを出すのが主な手法でした。
ただ、OP25Bの広まりやSNS等の他の連絡手段の普及もあり、徐々に変化が起こりつつあった状況でした。

  • スパム率70%~80%程度という感じで年々増えていた
  • 97%前後がbotnetから出されたスパムだった
  • 日本発のスパムはOP25Bにより激減していた

下記表は、2010年当時の実測スパム比率と、S25Rのマッチ率≒botからのスパム送信率、tarpitting(遅延)を掛けた場合のスパム駆除(あきらめて切断される)率、同taRgreyでの駆除率です。
9割以上がbotから出されており、そのためbotに対してのスパム判定がうまくいけば高い比率で対策となっていたことがわかります。

スパム率 69%
S25Rのスパムマッチ率 93%
tarpittingでの駆除率 91%
taRgreyでの駆除率 85%

2012~2018年の状況推移

あるメールサーバで、メールの受信数や各スパムフィルタでのスパム判定数から、botからのスパムメール送信数推移を定点観測しました。

メール総数とスパム数

まず基本となるメール総数とスパム数の推移です。1メールアドレスあたりの月平均受信数です。
スパムが減っているため、メール総数が減っていることがわかります。

アカウントあたり 2014年まで 2018年現在
メール数 2,500通/月ほど 1,000通/月弱
スパム数 2,000通/月ほど 500通/月ほど

f:id:stealthinu:20181204160446p:plain

スパム率

スパム比率の推移をグラフにしました。
ここ数年で一気にスパム比率が少なくなったことがわかります。(と言ってもまだ半分がスパムですが)

f:id:stealthinu:20181204160459p:plain

  • 2014年くらいまでずっと75%くらいだった
  • その後徐々に低下し2018年には50%を切る

メール総数とハム数

正常なメール(ハム)の数は意外に減っておらず、横ばいでほぼ変わっていないことがわかります。
メールマガジンなど、DMの需要はまだ減っていないのだろうと思われます。

f:id:stealthinu:20181204160441p:plain

減ったスパムの種類

スパムはここ3,4年で大きく減っており、意外に普通のメール流量は減っていないことがわかりました。

それではどんなスパムが減ったのでしょうか。

動的IPからと推測される接続推移

S25Rに引っかかるような、逆引き名が動的IPっぽい接続はbotからである可能性が高いと推測でき、それらbotからと思われる接続はここ数年で激減していることがわかります。
またtarpittingで切断された件数も同様に減少しています。

f:id:stealthinu:20181205180721p:plain

  • S25Rに掛かる接続元は70%減程度に激減
  • tarpittingで切断されたメール数も合わせて減少

tarpittingでの切断率推移

動的IPからと思われる接続でtarpittingで切断された率も急激に減少しています。

f:id:stealthinu:20181204155731p:plain

  • 2014年くらいまでずっと80%程度だった
  • その後2018年には30%にまで急激に低下

S25Rに引っかかるものすべてがbotなわけではなく、メールマガジンの大量発信やクラウドサーバから出されているものが誤検出している場合があります。
それらはtarpittingを抜けるため、botが減ったことで相対的にそちらの比率があがり、切断率が下がったのではないかと考えられます。

tarpittingを抜けれなかったものだけがbotと考えると、botからの接続は最盛期より10%程度にまで減ったと考えられます。

SMTPセッションフィルタの有効度推移

このサーバではメールの中身で判定するコンテンツフィルタも利用でき、その場合はSMTPセッションフィルタを抜けてきたものをフィルタしています。
どちらのフィルタでどれだけスパムが落とされたかで、各フィルタの有効性がどう推移してきたかを見てみます。

コンテンツフィルタとSMTPセッションフィルタの効果推移

f:id:stealthinu:20181204160503p:plain

  • コンテンツフィルタは30%減程
  • tarpittingは85%も激減

tarpittingの1次フィルタの効果

f:id:stealthinu:20181204160510p:plain

  • 2015年頃まではずっと70%~80%維持
  • 以降急激に低下しついに30%程度に

SMTPセッションレベルでのフィルタの効果が減少してあまり意味をなさなくなっていることがわかります。

結論

botnetからの送信が大幅に減ったため、botのクセを利用してスパムを排除するSMTPセッションフィルタも効果をなさなくなりつつあることがわかりました。
スパム(botnet)はすでにメールではなく、より効果の高いSNSなどを狙ったり、メールを使う場合でもより効率の高いフィッシングなどに使われるようになったと考えられます。

このことから、taRgreyはもう導入する意味がないといえます。これはgreylistingなど他のSMTPセッションフィルタも同様です。
考案者としては複雑な心境ですが、そもそもスパムがなければスパムフィルタは不要なわけで、だから喜ぶべき話だと思います。

NSEG勉強会#101

先月末6/30(土)に「メールとコミュニケーションツール」というお題でNSEG勉強会が開かれて参加してきました。

勉強会は参加エントリ書くまでが勉強会、と思ってるのにずっと放置してしまってました…


NSEG 勉強会 #101 / メールとコミュニケーションツール - connpass

NSEG 第101回勉強会 / メールとコミュニケーションツール #nseg - Togetter

NSEG 101 - YouTube


今回、bounceHammerやSisimaiという、エラーで返ってきたメール(バウンスメール)を解析するオープンソースのツールを開発されてる @azumakuniyuki さんと、DebianUbuntuのメンテナなど色々と活動されてる @henrich さんが遠方から来られたため、@suno88 さんとともに前日から歓迎の飲み会&次の日も午前中からお昼すぎまで観光やら温泉やら巡るなどして、大変楽しく交流することができました。


あずまさんの講演「Email is Slack」は、メールやバウンスメール解析ツールSisimaiの開発を実例としつつ、どんな開発コンセプトでサービスやツールを作るべきか、というお話でした。
「Email is Slack」のSlackは、チャットサービスのほうのSlackではなくて「活気がない」「ゆるい」という元の英語の意味の方の話です。
メール以外のSNSだとかのコミュニケーションツールは伸びてて、メールは伸びてはいないものの停滞しているということが資料から説明されました。
そして本業のエラーメールのバウンスメール解析の話につながり、バウンスメールの形式が雑でゆるいために、いろんなものがあるということでした。
そこから、現在のバウンスメール解析ライブラリであるSisimaiへの歩みがどんな感じだったかの話になりました。
そしてそこが本題で、最終的にはUNIX哲学にしたがって、小さく、堅く、一つのことだけを速くやる、というツールにしたほうが、結局使いやすい良いものになる、という話でした。
これが最初に紹介のあった本「UNIXという考え方」につながるわけですね。
あずまさんはLTもお話いただいて、実は長野すごい来てるんだってことがわかりました。


やまねさんのLT「Let's look into debootstrap」は、いかにしてdebootstrapのバグフィックス等改善していったか、という事例を話すことで、オープンソースへの取り組み、貢献をどうやって始めたり続けたりするのか、という話になっていたと思います。
僕はこの話を聞くまで、debootstrapのこと知らなかったのですが、すごい面白いツールで、特にdocker環境とかで有用だろうなと思いました。
で、動機だったdocker環境で動かしたい件についてどうなったのか、が最後のオチに出てきます。


とみたさんのLT「メールの文字化け」は、流石「文字化けソムリエ」だけある内容でした。
特にMIMEが絡んだエンコーディングのつらみがなんで起きるのか、RFC通りには実装されてないものデコードしないといけないこととか、メールならではの問題と絡んだ理由で説明され、とても楽しめました。
最初のタイトルへの持ってき方がずるいくらい面白い。


鍋太郎さんのLT「LINE の bot を作ってみた」は、LINEに通知を流せるbotを作るために、どんな(LINEに対しての)手続きやコードが必要かを実際の例から説明するものでした。
地区の連絡用に必要に迫られて、というのが良い感じです。
直接の実用性という意味では一番参考になると思いました。


自分は「スパム対策お焚き上げ」という題で、自分が以前考案して運用しているtaRgreyというスパムフィルタ手法と、そのログから最近のスパムがどのような状況となっているか、を説明する内容となっています。

スパム対策お焚き上げ

これ前半は、8年前にNSEG #10で話した下記内容を一部簡略化したものがベースとなっています。

taRgreyでコストを掛けずにスパム削減

僕にとっては実はちょっとせつない内容なんですが、そこそこウケてもらえたかな〜と思っています。
これは後でエントリー化したいと思っています。

SNS時代のスパム手法

この記事はNSEGアドベントカレンダーの24日目の記事です。


…といいつつ新規に作ったものではなく、これは去年の11月にとあるセキュリティ系の講演で喋った内容のプレゼン資料です。

今、スパマーたちはメールによるスパムから、SNSを使ったスパムへと軸足を移しており、SNSのスパム手法はどんなものがあってどうやって広めたりマネタイズしているのか、を紹介したものです。


https://dl.dropboxusercontent.com/u/4412680/naganoispbouhan/snsspam.html

今のスパムの特徴が

  • SNSを使う
  • ソーシャルハック重視
  • アカウント乗っ取り

であること、そして今後はより

  • システムの穴より人間の穴を狙う
  • SNSファースト・スマホファースト
  • 低率で大量配信より標的型で高率に
  • 「サービス」と「スパム」の差があいまいに

という方向へむかうであろうこと、を解説しています。

postscreenってどんなもの?

これはPostfix Advent Calendar 2014の18日目の記事です。こちらも大変遅くなってしまってすみません…


Postfixには2.8以降からpostscreenという機能があります。が、あまり知られていないと思います。

これはひとことで言うと、超軽量簡易スパムフィルタです。


Postfixにはsmtpd_*_restrictionsをはじめ、policydやfilterなど色々とスパムをフィルタするための仕組みが用意されています。
にもかかわらずpostscreenが用意された理由は、postscreenは超軽量のためフィルタをすることで負荷も下げることが出来るからでしょう。

やまやさんPostfix Postscreen Howto - どさにっきで「トリアージ」と表現されているのですが、まさにそんな感じで、postscreenで怪しいメールだけをより詳しいチェックへと回してやり、大丈夫そうなメールは通常の処理で行う、という大まかなよりわけが行えるというものです。


PostfixSMTPセッション毎に一つsmtpdのプロセスが立ち上がるため、例えばtarpittingでのフィルタを掛けると、スパムによりsmtpdの同時起動数が増えてしまい、メモリ消費量などが増えてしまうという問題がありました。(そのため、接続が切れたら即smtpdプロセスが死ぬようなパッチを書いたりしました)

これに対してpostscreenでは、smtpdの前段に位置して1プロセスで処理を行うため、大量のスパムからの接続があってもプロセスの爆発が起こらずにフィルタすることが出来るようになっています。


postscreenで使えるフィルタは下記Howtoページから確認することが出来ます。
2.8.2のころから使えるフィルタは増えていないので、日本語訳の情報がそのまま使えます。


公式のPostscreen Howto

Postfix Postscreen Howto


Postfix-2.8.2のものですが、やまやさんによるPostscreen Howtoの日本語訳。

Postfix Postscreen Howto


マニュアルにpostscreenではどんなフィルタが利用できるのかが書いてありますが、どんなものかざっとわかるように短くまとめてみました。

  • Pregreet test

以前pregreet detectionでエントリーを書いたのですが、「220-server.example.com ESMTP Postfix」みたいに嘘のグリーティングメッセージを返して、答えを返しちゃったら負け、という手法。

  • DNS White/blacklist test

複数の(DNSBL毎に重み付けした)DNSBLでマッチさせトータルが閾値以上になったかどうかを見る。

  • Command pipelining test

SMTPにはpipeliningをアナウンスされていなければ一応答ごとに一コマンドしか受け付けないのだが、スパムはそれを無視して連続してコマンドを送ってくる場合が多いため、それで判断する。

  • Non-SMTP command test

オープンプロキシを使って送ってくるbotだと、例えばHTTPで使われるCONNECTのようなSMTPには存在しないコマンドを使ってくることがあるため、そのようなコマンドで検知する。

  • Bare newline test

SMTPでは行が「CR LF」で終了することになっているのだが、単に「LF」だけで送ってくるものを引っ掛ける。


こうやって見るとどれも結構トリッキーなもので引っ掛けているなと感じるのではないかと思いますが、結構な確度でbotが引っ掛けられるのではと思います。


ほとんど、昔やまやさんが書かれたものをまとめただけ、というエントリーになってしまいましたが、これでpostscreenの認知度が少しでもあがればいいなと思います。


(参考)

Postfix Postscreen Howto
Postfix manual - postscreen(8)
2010年11月17日(水) Postfix Postscreen Howto - どさにっき
2011年4月8日(金) Postfix Postscreen Howto - どさにっき
Postfix Postscreen HowtoPostfix 2.8.2 に同梱の POSTSCREEN_README の翻訳)

pregreet detection - モーグルとカバとパウダーの日記

Postfixでのサブミッションスパムの簡易対策方法

これは Postfix Advent Calendar 2014 の11日目の記事です。


サブミッションスパムという、盗んだアカウントを使って、botから送信認証を行ってスパムを出すというスパム送信手段があります。

これをされると、自分のメールサーバから大量のスパムが出されるため、各種DNSBLに登録されてしまい、このメールサーバからのメールが届かなくなったり、メールキューが爆発したり、バウンスメールが大量に届いてスプールが爆発したり、とろくなことがありません。

2年半前にこれがすごい流行った時があり、メールサーバ管理者の方には、痛い目にあった方も結構いるのではないでしょうか。


その時にサブミッションスパムについての解説を書いたエントリーです。

「サブミッションスパム」による5/15〜16のメール障害の解説と対策 - モーグルとカバとパウダーの日記


さて、2年半前に起きてその後どうなったか、というと、その後はその時のようにそこらじゅうでこれの問題が発生する、ということは起こっていません。

でも、無くなったわけじゃなく、忘れた頃に時々またやられるのです。

すると、ぶつくさ言いながら該当アカウントを停止して、DNSBLに解除申請をし、ユーザーからの問合せに対応しなければならなくなります。


この手法に対しての普遍的な対策をしようと思うとなかなか難しく、policydのようなものを使ってスロットリングするしかないかと思います。

が、このサブミッションスパムを使ってくるスパマーは限られており、その癖がだいたい決まっているので、実は小手先の手法でもそこそこ対策が可能です。

このスパマーはsasl認証が通ったら、こちらの返信を全く待たずに即送信をしてきていました。 (0秒でpipeliningで送ってくる)
なので、1秒でも遅延を掛ければ落とすことが出来ます。
が、通信遅延などで通ってしまう場合もあり、これまでの知見からは海外からであれば5秒くらい、jpドメインからなら1秒の遅延とするとだいたい良い感じになるようです。

実は先のエントリーでもこのことを書いているのですが、具体的な設定方法についてまでちゃんと提示していませんでしたので、今回は具体的な設定を書きたいと思います。(つまり… 過去エントリーの焼き直しですね。すみませんっっ _o_)


サブミッションの設定をしているところに設定を行いますので、master.cfの設定を確認します。
元々は下記のようにsubmission設定がされていたとします。

/etc/postfix/master.cf(元)

submission inet n       -       -       -       -       smtpd
    -o smtpd_etrn_restrictions=reject
    -o smtpd_sasl_auth_enable=yes
    -o smtpd_client_restrictions=permit_sasl_authenticated,reject


これに接続元逆引き名でのチェックを追加してやります。
ルールはmaster.cfだけでは書けないため、main.cfへの追記と遅延のルール用のファイルも新規で作成します。
「.jp」ドメインからなら1秒、その他からは5秒遅延を掛けます。

/etc/postfix/master.cf(変更後)

submission inet n       -       -       -       -       smtpd
    -o smtpd_etrn_restrictions=reject
    -o smtpd_sasl_auth_enable=yes
    -o smtpd_client_restrictions=$tarpit_submission_spam
    -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject

/etc/postfix/main.cf(追記)

tarpit_submission_spam =
    check_client_access    regexp:$config_directory/tarpit_submission_spam

/etc/postfix/tarpit_submission_spam(新規)

/\.jp$/ sleep 1
/.*/    sleep 5


「-o」で設定を追加する場合にはパラメータを渡すことが出来ないので、main.cfにルールを書いてそれを呼び出す形にしていることに注意してください。
また、同じsmtpd_client_restrictionsで送信認証と遅延のルールを書いてしまうと意図通りにならないため、smtpd_client_restrictionsとsmtpd_recipient_restrictionsの2回に分けて行っています。

巧妙化するパクツイbotとキュレーションサービスとの境目

パクツイbotとは、以前バズったツイートや2chの過去の書き込みなどをパクってツイートして人を集めるプログラムのことです。

なんでわざわざそんなことするの?と思うでしょうが、基本的には金です。時々アフィリエイト誘導する広告ツイートなんかを混ぜて稼ぐわけです。


パクツイBOT問題について
http://malpoison.blogspot.jp/2013/05/bot.html


自分はtwitterで、友人のリストを作ってあってそこのツイートは確認するようにしてるんですが、そのTLに、あるパクツイbotのツイートがRTで流れていました。


恋人いません。 (no_amour_)
https://twitter.com/no_amour_

最近Twitterで、ある女の子と仲良くなった。生活習慣が同じなのか「飯なう」と書くと「あたしも><」とリプライがくる。ある日、大好物のトンカツが食卓に並んだので「うまい!」と写真付きで投稿したら「ありがとう」とリプが来た。目の前には満面の笑みの母。背筋が冷たくなった。


実は最初、RTしそうになったのですが、なんか見たことあるかも… と思い調べてみたのです。

このRTだけみると、単に面白いネタツイートなだけに感じてしまうのではないかと思います。
そしてこのbotのアカウントを確認すると、ツイート数は少なめなので1日1個とかそれ以下なので、その時点でもbotっぽさをあまり感じないと思うのです。
ただ、あまりにもおもしろいネタが揃いすぎてるため、疑り深い人はそこですでに違和感を感じるかと思います。


パクツイの場合、特徴のありそうな部分、例えばこの場合だと『生活習慣が同じなのか「飯なう」』あたりでぐぐるとすぐにいくつか出てきます。
ただ、元ツイートがここで、RTされたりパクツイされた後の場合もあるため、より古いものをさがしていくと元ネタが割れます。


上記パクツイの元ツイートはこれでした。

いのほんさんはTwitterを使っています 最近Twitterで、ある女の子と仲良くなった。…
https://twitter.com/inohohon/status/127944365531336704


これを調べた後、パクツイbotの元ツイートも表示しようと思ってとっといてたのですが、すでに削除されていました。

実は、このパクツイbotは1日に多数ツイートしてます。が、ある程度以上RTされなかったものとかは消していくみたいなのです。
それで、1日に1個程度のツイートになるよう調整しているようです。


他に、現時点(2014/9/2)で存在しているツイートで、パクツイ元を調べたものを2件ほどあげておきます。


レプスさんはTwitterを使っています 「遊ぼう」って言うと「もっと若いヤツと遊べよ」って言う。…
https://twitter.com/reps_/status/136093355221323776


石上翔太さんはTwitterを使っています さっき電車のなかに高校生カップルがいた。…
https://twitter.com/gesugami0624/status/222691332110561280


パクツイの問題は、今話題になってるバイラルメディア問題と同じく、他人の著作をパクって儲けてるというところです。

ただ、こういうのはキュレーションサービスとの境目が曖昧になってきてる、とも感じます。
このパクツイbotは恋愛ネタを中心としたおもしろいツイートを探してきて流してくれてる、とも言えると思います。


また、このパクツイbotが広告ツイートを流しているのはまだ観測していません。
なので単におもしろいツイートをパクツイしているだけ、という可能性もあります。

(追記)
美容系のアフィリエイト流している模様。ただその頻度は低く、時間が経つとツイートから消すようにしているため、アフィ目的のボットとは気づかれにくくなっていると思われます。
もっと調べたい方は「4Mq_cIYD」あたりで検索してみると良いかと。
(/追記)


もしこのパクツイbotがちゃんと公式RT使って流していて、自己紹介でも「恋愛ネタのおもしろいツイートをRTするよ」とかだったら責められないのじゃないかな、と思うのです。

例えばパクツイbotに対抗するため、そのパクツイbotの元ツイートを自動で探してきて公式RTを使ったbotを提供してるサービスなんかもあったりします。


無断転載じゃないワロスbotを作ってみた → @1000favs_RT, @1000Retweets_RT - rambling talk
http://d.hatena.ne.jp/nickle/20130123/1358944432


ここに時々広告ツイート流すようにすると… ちょっと叩かれそうな気もしますが、ギリセーフな気もしないでもない。
というかそれってキュレーションサービスのページに広告付いてるのとどう違うの?という感じになってくると思うのです。


このあたり、線引がだいぶあやふやになってくる感じです。
ただやはり最低限、パクツイではなくRTにすべきだろうなと思います。
ここまで「サービス」に近づいてきてるんだから、もうちょっとだけ頑張ってちゃんと「サービス」になってしまえばいいのに、と思うのでした。

Twitterの新スパム対策と誤検出の可能性について

Twitterで新しいスパム対策フィルタが実装され、よりスパムが排除されるようになったとのこと。


Twitter、スパムに“秒速で”対処する新システム「BotMaker」でスパムの40%削減に成功 - ITmedia ニュース
http://www.itmedia.co.jp/news/articles/1408/21/news082.html

Scarecrowが見逃したイベントに機械学習技術で対処する「Sniper(狙撃者)」

場合によってはスパムがユーザーの目に触れる前に削除できるようになった。

と書かれていることから、一旦TLに表示されたスパムtweetに対して、機械学習でスパムと判断されたものは後から削除(削除リクエストが発行され再表示タイミングで消える)が行われるのではないか、と推測しました。


ところで、掲示板スパム等の対策では、サーバ側が「スパム判定した」と相手に知らせないほうがより効果が高いです。
その場で「スパム判定した」と知られると、スパマー側はすり抜けるための対策を取りやすくなるためです。
特に、スパムというよりも「荒らし」のように一つの掲示板に粘着して攻撃される場合、そのユーザから見たらちゃんと表示されているけども、実は他のユーザにはその書き込みは見えないようになっている、というような実装にしておくと、効果的だと思います。


さて、ここ最近のtwitterで、どうも友人のtweetが歯抜けになってる?みたいな件を見かけることがちょこちょこありました。
フォローしてる人のtweetなのに他の人がRTしたものだけ表示されたり、話がつながらないからおかしいなと思って聞いてみたら、一つ前のtweetがあったはず、みたいな状況です。
昔のtwitterではそんなこともよくあった気がするので、それほど気に留めてなかったのですが、この新スパム対策導入のエントリーを読んで、これの影響だったのかも、と思ったのでした。


スパム対策、特にメールのスパム対策だと、検出率を上げるよりも、誤検出率を下げることのほうが重要になります。
でも掲示板スパムとか、多数の人が見るもので、それほど誤検出が致命的でないような場合、多少誤検出が起きてもすり抜けるスパムが出ないようにするようにチューニングしたほうが実用的です。


投稿者側には気がつかないようにフィルタされてるとすると、スパムが減っただけじゃなく実は結構誤検出も起きてるんじゃね?と思ったのでした。