Protecting against gmail dot trick in Discourse

My forum just receive a large number of spaming user registration.
He/She using Gmail dot tricks ( http://www.makeuseof.com/tag/1-awesome-gmail-tip-you-dont-know-about-seriously/) to create this large number of email account.

Can you prohibid this trick ?

My discourse is using Cloudflare at a CDN and DNS provider, Discourse can’t work fine caused the IP thing.

Couldn’t you ban their IP instead?

Hum, I’m using Cloudflare for CDN, and discourse only see Cloudflare, not user’s IP. (in Wordpress, Cloudflare has an plugin to pass the user IP to website)

「いいね!」 3

At vB we used to get literally thousands of bot “seed” accounts like
aliasg.maila.ccount
alia.sgmai.laccount
ali.asg.mailacco.unt
alias.g.m.ailaccount
al.iasgmai.lacc.ount
… etc. ad nauseum

We eventually had a plugin written to deal with them

「いいね!」 1

Yeah you’re going to need to turn that off, or figure out how to get CloudFlare to send proper headers for the passthrough IP.

「いいね!」 1

Yes. I’m working on that by config Nginx.
Cloudflare actually sends user’s IP via header HTTP_CF_CONNECTING_IP

But prohibid gmail dot trick is useful too.

「いいね!」 1

You really need to get IP passed through correctly otherwise you are really screwed. That’s about the only effective way to stop spammers, if they are clever.

「いいね!」 1

While in this case banning the IP is the right thing to do, I think there is merit in being able to stop user.name@gmail.com and username@gmail.com from being both registered as two different users at any given discourse forum.

No sane administrator should allow this behaviour (from gmail) and maybe we could have an option to extend this prohibition to other email providers as well.

It would need a simple list like ‘@gmail.com’, ‘@anotherprovidder.com’ and then it would check for registered users by removing the dot or any other relevant character (could have a list as well) to avoid users that want to have two or more accounts.

Maybe a plugin with this functionality would be the best solution.

「いいね!」 5

Definitely make it optional if you do it at all. I depend on this trick for troubleshooting!

「いいね!」 3

これらの種類の登録と、それらが投稿するスパムに完全に翻弄されています。:man_supervillain:

mycoolgmailaddress4spam+unlimitedcombinationslol@gmail.com
m.ycoo.lgm.ailaddress4s.pam@gmail.com

残念ながら、私たちはこれらの登録に対して無防備です。唯一の防御策は、スキルを持つスパマーにターゲットにされないことです。

客観的に見て、これらの手口を使って、単一の Gmail アドレスから 10 万アカウントを作成する十分な IP を持つスパマーを、標準的な Discourse フォーラムでブロックする方法はありません。

スパマーが単一の Gmail アドレスで無制限のアカウントにアクセスできる場合、すべてのスパム/投稿スロットリング設定は無意味です。

当社のホスト顧客が約1,000社以上いる過去4年間で、このようなことが起きた記憶が全くないのに、貴社のサイトでこれほど深刻な問題が発生しているのは不思議です。

@codinghorror これは、この一般的なスパム手法に対する十分な防御があるからでしょうか、それともこれらのサイトがスパマーに狙われていないからでしょうか?これらのサイトは、防御によってブロックされるあらゆる種類のスパム登録の試みが定期的かつ大量に行われているのでしょうか?

これは、ニッチ、トラフィック量、そして彼らの直接反応型スパムキャンペーンに適しているかどうかによって大きく異なります。投稿リストの上位に投稿を維持できるスパマーは、実質的に極めて安価で素晴らしい広告スペースを手に入れていることになります。トップページのアbove the fold(画面内上部)の広告スペースは、ニッチやトラフィック量によって、1 日あたり数百ドルから数千ドルの価値があることが非常に一般的です。

特定のフォーラムで直接反応型キャンペーンをスパムすることで月間かなりの収益を得ているスパマーは、平均的な現地給与が極めて低い発展途上国に住んでいる場合、動機付けられる可能性があります。

私は 2015 年から 2016 年にかけて複数の Discourse フォーラムを運用していますが、狙われていないため、スパム登録やスパム投稿の問題はほとんどありません。スパマーに狙われるまでは、狙われていないことが素晴らしい防御策となります。私の知る限り、Xrumer のような市販のフォーラムスパムソフトウェアの多くは、デフォルトでは Discourse をサポートしていません。

さて、私がよく引用する規則があります。

もしあなたがモサドに個人として狙われたなら、おしまいです。

「いいね!」 5

その通りです。専任のスパマーは必ずしも突破してきます。彼らは独自にメールサーバーを立ち上げ、何千ものメールアドレスを生成することさえあります。それに対処するのは大変でしょう。

とはいえ、これらの Gmail の手口を使って重複登録を許可しないことは、合理的な予防策と言えるのではないでしょうか?

「いいね!」 2

@codinghorror - ハハハ、最高ですね。ただ、ひるんで諦めるのは嫌です。:man_cartwheeling: これは特殊なケースではないと思います。スパマーの悪用を防ぐため、多くのソーシャルサイトでは同じ Gmail アドレスでの登録を許可していません。私が知る限り、主要なサイトはほとんどがこれを禁止しています。

@bartv - はい、独自メールサーバーを持っているサイトであれば、少なくともドメインをブラックリストに追加することで、それなりに効果的な防御が可能です(ただし、ブラックリスト化される前に作成されたアカウントは引き続き使用できてしまいます)。彼らは別のドメインを取得できますが、少なくともリソースコストはかかります。Gmail の手口とは異なり、コストがかかるのです。

Gmail のこうした手口に対しては、実質的な防御策が存在しません。スパマーにとって追加のアドレス変形にはコストがかからないからです。「レーベンシュタイン距離」を用いたスパムメールの検知は、同じ Gmail アドレスをさまざまなドット(.)の組み合わせで多数回登録しようとした後にそのアドレスを禁止することで、ドット trick に対してはある程度有効です。しかし、現在では + trick に対する防御はできません。これを使えば、実質的に無制限の組み合わせが可能になるためです。

ただし、あなたを助けてくれる強力なコネがある場合は別です。それはここで Discourse 開発チーム(そしてプラグインについて考えれば、コミュニティも)です。

申し訳ありませんが、Discourse が Gmail アドレスのドットと「+」以降の部分をすべて無視するのは良いことだと思いませんか?技術的にはそれほど複雑ではないはずです。非常にシンプルな数行のコードで済みます。登録時に「@」の後に gmail.com が検出されたら→ドットと「+」以降の「@」手前までの部分をすべて削除し、そのアドレスを使用→既に使用済みか?→「メールアドレスは既に使用されています」というエラーメッセージを返す。

これで完了です。何か見落としているでしょうか?
スパマーがこの手法が Discourse で機能することを知らしめたら、彼らはこのテクニックを使って Discourse フォーラムをますます多く狙ってくるでしょう。つまり、彼らがそうしない理由があるでしょうか?

「いいね!」 2

新規ユーザーには、最初の X 回までトピックや投稿のすべてを手動承認するよう設定したところ、その問題はほぼ一夜にして解消されました。一部のユーザーは、後から投稿を編集すれば問題が解決すると考えましたが、信頼レベル 0/1 に対してもその設定を調整することで対応しました。

これは特定のドメインのトリックとは直接的な関係はありませんが、対策を回避しようとする意図的な人間の行動という根本的な問題を解決します。Gmail の「トリック」が使えなければ、彼らは別のトリックを見つけるでしょう。個人的には、「信頼レベル 1 で投稿可能になり、信頼レベル 1 になるには 5 分の読了時間が必要」といった方針を推奨します。

「いいね!」 6

さて、ここで使用できる文字は全部で何でしょうか?

一部のメールサービスでは、ローカル部分に含まれるタグをサポートしており、そのアドレスはローカル部分のプレフィックスのエイリアスとなります。例えば、joeuser+tag@example.com というアドレスは joeuser@example.com と同じ配信先を指します。RFC 5233 ではこの慣習を「サブアドレッシング」と呼んでいますが、「プラスアドレッシング」「タグ付きアドレッシング」「メール拡張」とも呼ばれます。

ベース名とタグの間に様々な区切り文字を用いるこの形式のアドレスは、Runbox(プラス)、Gmail(プラス)、Rackspace Email(プラス)、Yahoo! Mail Plus(ハイフン)、Apple の iCloud(プラス)、Outlook(プラス)、ProtonMail(プラス)、FastMail(プラスとサブドメインアドレッシング)、MMDF(イコール)、Qmail、Courier Mail Server(ハイフン)など、複数のメールサービスでサポートされています。Postfix と Exim では、合法文字セットから任意の区切り文字を設定できます。

つまり、プラス、ハイフン、イコール、ピリオド、そしてポンド/ハッシュタグがありますね。

ここで機能する可能性があるのは、メールアドレス内の A-Z a-z 0-9 以外のすべての文字を防止するという極めて厳格な設定だけです。

確かに一部のユーザーの登録を阻むことになりますが、もしあなたが…ええと…エリート・モサドのエージェントに狙われているなら、それは許容できるトレードオフかもしれませんね :male_detective:

@eviltrout、どう思いますか?

それは厳しすぎるかもしれません。ここでのポイントは、そのようなメールアドレスのバリエーションの多重利用を防ぐことであり、完全に禁止することではありません。代わりに、各アカウントに「正規化」されたメールアドレスを追加し、そこにユーザーの実際のメールアドレスをクリーンアップしたバージョンを格納することができます。新規登録時に、入力されたメールアドレスをクリーンアップしたバージョンをこの値と比較します。ただし、言うは易く行うは難しでしょう。

「いいね!」 4

はい、Bart が提案した変更の方が私は好ましいと思います。

[ ] メールアドレスの内部保存用に正規形を使用する(+ANYTHING を削除し、コメントなどを除去します)

Ruby 実装が提供されており、これを利用できるかもしれませんが、非常に非常に非常に慎重にする必要があります(例 1 はセキュリティリスクです:https://stackoverflow.com/a/52125295/17174)

EmailAddress.canonical("(test)sam.saffron(test)+100@gmail.com")
=> "test@gmail.com"
[3] pry(main)> EmailAddress.canonical("sam.saffron(test)+100@gmail.com")
=> "samsaffron(test)@gmail.com"
[4] pry(main)> EmailAddress.canonical("sam.saffron+100@gmail.com")
=> "samsaffron@gmail.com"

したがって、私たちの「正規化」処理では以下を行うことを提案します。

  1. +ANYTHING を削除

  2. 小文字化(これは既に強制しています)

  3. Gmail、Googlemail、またはカスタムホワイトリストにドメインがある場合、ドットを削除

  4. コメント (...) を削除。これらは悪用のベクトルにもなり得ます。

  5. アドレスを Unicode 正規化 します。これは技術的には Email address - Wikipedia に準拠して許可されています。

その後、ドット削除の対象となるドメインのホワイトリストを含む隠しサイト設定を追加します。

とはいえ、これを悪用する方法は数多くあります。例えば、1 万個のスパム Gmail アドレスのキャッシュを持っている人が、何らかのボットを使ってそれらすべてでサインアップしてくる可能性があります。もし標的にされているなら、しばらくはすべての新規登録を承認してしまうのも手かもしれません。これは、プラグインでサインアップ時に reCAPTCHA を導入したい数少ないケースの一つかもしれません。

「いいね!」 2