(Mastodon)スパマーとの終わりなき戦い #2

前回の記事では、スパマーの流入経路、傾向、またサーバを存続していくためのスパム対策の重要性について書きました。

また、この記事では、一ヶ月の間に観測したスパマーの詳細情報について掲載しました。

当記事はそれを踏まえた第2弾です。

スパマーを完全に排除することはできない

いきなりお前は何を言っているんだと言われるかもしれませんが、これは間違いないと思っています。

というのも、2020年7月分の分析傾向から分かる通り、アクセス元が世界中に分散しており、特定することはできません。
そのため、一ヵ所のアクセス元を封じたとしても、また別の場所からアクセスされ、まさにいたちごっこです。

極端な話、首謀者を捕まえて投獄なりなんなりすればいいというのもなくはないですが、それも新たなスパマーが出現するだけで、いたちごっこに変わりがありません。

そのため、「排除」はできません。しかし、何かしらの対策を講じることで「軽減」することは可能です。

スパマーの登録手法の分析から分かった（当面の）対応方法

スパマーの傾向分析から、どうやら人力ではなく、機械的に行っているものが大半のようです。

そのため、効果的と思われる対策は「CAPTCHA」です。
Googleが提供している「reCAPTCHA」などは有名ですね。

機械的な登録を阻止できるだけでなく、手動による登録にも一定の効果があるものと期待しています。
(スパマーはCAPTCHAによって手間が増えるのを嫌うはずです)

しかしこのCAPTCHA、Mastodonオフィシャルでサポートされておらず、今後もサポートされる見通しがないように感じています。
（Mastodonの開発コンセプトが、GoogleやYahooといった大手に依存せずサービスを提供できることを目指しているため）

もちろん、ソースコードに手を加えて、自前で実装してしまうというのもアリですが、それも割と敷居が高いです。

Cloudflareを使って、ソースコードに手を加えず、CAPTCHAを導入する方法

これは実際に運用中のサーバに実装している方法の紹介です。

1. サーバへのアクセスをCloudflare経由にする

DNSネームサーバの設定をCloudflareに変更し、プロキシステータスを「プロキシ済み」にします。

また、SSL/TLS設定は「フレキシブル」としておきます。

本来は「フル」「フル（厳密）」の方が好ましいと思われますが、取り急ぎ混在状態でもアクセスしたいので「フレキシブル」を選択します。

「フル」「フル（厳密）」に切り替える場合は、ネームサーバの設定が伝搬するまで時間がかかるので、ネームサーバ設定のTTLに設定された時間以上待ってからにします。

2. CloudflareのWebAccessFirewall を設定する

「ファイアウォールルール」で、以下のように設定します。
（ルール名は任意です）

上記例は「"/auth"にアクセスしてきたら問答無用でCAPTCHAを表示」という設定です。
追加の条件として、IPレンジや国なども指定できるので、たとえば「日本以外からのアクセスにはCAPTCHAを表示」のようなルールも作れます。

設定はこれだけです。

実際に「/auth」（ユーザ登録確認画面）にアクセスすると、CAPTCHAチャレンジが表示されるようになります。

3. 制限事項

Cloudflareでプロキシを噛ませた状態では、certbotによるLet's Encrypt証明書の取得・更新ができません。
そのため、SSL/TLSモードをCloudflareの自己証明書を使った「フル」「フル（厳密）」にすることを検討してください。

WebSocketのパススルーにも対応していますが、無料プランだと接続数？に制限があるようです。
小規模なら大丈夫かもしれませんが、大規模サーバに適用する場合は有料プランへのグレードアップも検討しないといけません。

これで戦いに終止符を打てるか？

Cloudflareの設定をして1か月程度経ちましたが、今のところ登録スパムを完全に排除することに成功しています。

といっても、8月からスパマーの活動が下火になり、もともとの件数が激減しているため、この設定による効果なのかいまいち分かりませんが…

引き続き、運営をしていく中で変化があれば書き記していきたいと思います。

（了）