あるユーザーが、そのメールアドレスを使用して、1 日に何度も「パスワードを忘れた場合」のエンドポイントを誰か、あるいはスクリプトから攻撃されているという状況です。これは数日間続いています。メールが送信されるため、システムへの悪用も懸念されます。nginx のアクセスログから、一部の時間帯の IP アドレスをシステム上の別のユーザーに特定し、警告メッセージを送信しましたが、それでは効果がないかもしれません。また、その IP アドレスを「管理 > ログ > スクリーニング済み IP」に追加しましたが、これが一時的なログイン防止以外の効果があるかどうかは確信が持てません。IP アドレスは変更可能であり、実際に変更もされています。おそらく動的アドレスですが、VPN を切り替えて再び始める可能性もあります。
この問題に対処する方法について、ご提案はありますか？
こんにちは、Dan さん。もしよろしければ、まず数点お伺いしてもよろしいでしょうか。
ユーザーを停止するには、admin/users/list/active にアクセスし、問題のあるユーザーの名前をクリックしてください。ユーザー情報ページに移動したら、*Permissions（権限）*までスクロールし、*Suspend（停止）*をクリックします。ユーザーがログアウトしていることを確認してください。ログアウトするまで停止が反映されない場合があります。もしまだログインしている場合は、同じページの右上にある青いボックスから手動でログアウトさせることができます。ログアウトすれば、以前の認証情報では再度ログインできなくなります。
新規アカウントの承認を行っている場合、その「犯人」が引き続き不正行為を繰り返す（そしてあなたが犯人だと確信している）なら、そのユーザーはアカウントを承認してもらうまで待たなければなりません。すでに彼が使用した IP アドレスが 1 つ（または複数？）わかっているので、同じ IP で新しいユーザーが現れたら、どうすべきかおわかりでしょう。
また、ユーザーの設定ページで*Account（アカウント）*セクションを開き、最近使用されたデバイスを確認することもできます。そこにはログインに使用された IP アドレスも表示されるはずです。これにより、さらにスクリーニングすべき IP アドレスが見つかるかもしれません。
ここで、アカウントの承認が必要になる設定が役立ちます。
そもそも、この人物は他のユーザーのプロフィールにアクセスしてパスワードリセットを要求できたのでしょうか？それが重要な問いです。
「パスワードをお忘れの方」ページにアクセスし、メールアドレスを入力することで可能です。誰でも、どのユーザーのためにもこれを行うことができます。
具体的に 1 日に何回ですか？
はい、「多い」は相対的なものです。
root@forum-app:/var/log/nginx# zgrep -c forgot_password access.log
214
root@forum-app:/var/log/nginx# zgrep -c forgot_password access.log.1
147
root@forum-app:/var/log/nginx# zgrep -c forgot_password access.log.2.gz
181
root@forum-app:/var/log/nginx# zgrep -c forgot_password access.log.3.gz
140
root@forum-app:/var/log/nginx# zgrep -c forgot_password access.log.4.gz
134
root@forum-app:/var/log/nginx# zgrep -c forgot_password access.log.5.gz
251
root@forum-app:/var/log/nginx# zgrep -c forgot_password access.log.6.gz
110
root@forum-app:/var/log/nginx# zgrep -c forgot_password access.log.7.gz
100
root@forum-app:/var/log/nginx# zgrep -c forgot_password access.log.8.gz
gzip: access.log.8.gz: No such file or directory
0
root@forum-app:/var/log/nginx# zgrep -c forgot_password access.log.9.gz
1
root@forum-app:/var/log/nginx# zgrep -c forgot_password access.log.10.gz
0
root@forum-app:/var/log/nginx# zgrep -c forgot_password access.log.11.gz
0
root@forum-app:/var/log/nginx# zgrep -c forgot_password access.log.12.gz
0
root@forum-app:/var/log/nginx# zgrep -c forgot_password access.log.13.gz
0
root@forum-app:/var/log/nginx# zgrep -c forgot_password access.log.14.gz
0
明らかに、この検索では正当なリクエストを除外できていません。今日と昨日を手動で確認したところ、いくつかの正当なリクエスト（反復される IP アドレスではないもの）がありました。大部分は数日ごとに変わる反復される IP アドレスからのものです。システムへの影響はあまり大きくありませんが、受け取るユーザーにとっては深刻です。私にできることは、nginx で IP アドレスごとに拒否設定をすることくらいだと思いますが、IP が変わるため… 1〜2 週間手動で確認して更新すれば、相手はしばらくは試みをやめるかもしれませんが、おそらくそれは一時的なものでしょう。被害者は、この問題は約 1 年半前に初めて発生したと話しています。
誰かがあなたの代わりに「パスワードを忘れた」を繰り返しトリガーするのは確かに迷惑ですが、パスワードリセットからユーザーをロックアウトすることは、それ自体が一種の荒らし行為でもあるため、それに基づいてロックアウトすることはできません。
ここには1分間に数回というオーダーのレートリミットがかかっていると思いますが、このコードパスを確認して、まだ機能しているか確認してもらえますか @riking？これを増やすこともできますが、「1日に数回」というレベルを安全にカバーすることはできません。
また、管理者権限で「Logs」→「Screened IPs」からIPアドレスを禁止すれば、そのIPアドレスからのパスワードリセット発行は防止できるはずです。これも期待通りに機能しているか確認をお願いします @riking。
偽のリクエストがスパムとして届いているのは私の方です。
1時間に何度も発生します。
2FA（二段階認証）を有効にしており、リセットキーも設定しているのに、パスワードリセットのメール送信を無効にするオプションがありません。
パスワードリセットを要求する前に、あなたのIPアドレスを表示し、それがメールに送信されると明記しているウェブサイトもあります。
この件は非常に小さな迷惑で、私はこのメールをほとんど確認しません。すべてのメールはフィルタリングされ、「既読としてマーク」するように設定されているため、未読として表示されません。私は1月にこのフィルタを設定し、今日初めてそのフォルダ（Gmailのラベル）を確認しました。
1 回目の返信で含められなかった画像です。
Gmail は同じ件名のメッセージを複数受け取ると、それらをグループ化します。
おそらく、同じものが 100 件を超えると、次の 100 件のメッセージへ移るのだと思います。
良い情報ですね。明日、これについて少し進めましょう @riking
簡単な回避策があります。test@gmail.com を test+SOMESECRETONLYYOUKNOW@gmail.com に変更してください。
Discourse からのメールは通常の Gmail に届きますが、パスワードリセットのメールを送られることもなく、安全なハッシュを推測されることもありません。
実際には、この場合、これが最善の対応だと思います。
この機能を週 1 回に制限しても、まだ面倒です。+ アドレス指定を使うことで、この問題を完全に解消できます。
特定の場所からのリクエスト（現在非常に効果的に機能している制限）に加えて、特定のユーザー向けにリクエストをレート制限することも可能です。リセットトークンの有効期限が切れる前に、最大2回までトークンを発行し、その後「メールをお待ちください」と伝えるのはどうでしょうか？
別のアプローチとして、パスワードリセットメールの送信をトークンごとに例えば3時間制限に設定する方法があります。この場合、クールダウン期間中にパスワードリセットメールの送信がリクエストされた場合は、以下のシンプルなメッセージを表示します：
「パスワードリセットメールはすでに送信されています。受信トレイをご確認ください。メールが2時間以内に届かない場合は、%contact_email%までお問い合わせください。」
フォーラムでメールを ‘email+something@gmail.com’ に変更し、別のブラウザでシークレットモードでテストしました。それでも通過してしまいました。おそらく、リクエストは常に送信元ユーザー名のみで行われ、実際のメールアドレスは使われないためでしょう。
現時点では、Dan が個人に対して非公開で対応したか、他の手段で問題を解決したため、偽の要求はすべて停止しています。
もしユーザーレベルで有効化できるセキュリティ質問オプションがあれば、トロールが正解を知らなくなるため、すべての要求を減らせるはずです。「好きな映画は何ですか？」や「好きなレストランはどこですか？」といった質問です。
この問題の解決に迅速に対応いただき、ありがとうございました。残念ながらこれが最初のケースであり、最後となることを願っています。
問題はおそらく、フォーラムをクロールしてユーザー名を収集し、パスワード再設定リクエストを乱発して荒らすことができる点にあるでしょう。
「パスワード再設定」機能に、メールアドレスを正確に入力しないとリセットできない「厳格モード」を追加するのはどうでしょうか。デフォルトではオフにします。
週に一度でも荒らされるのは多すぎると思います。この問題に対しては、レート制限だけで対処するのは不可能です。
一定時間内に、正確な入力を強制する前に、1〜2回の「無料」リセットを提供する方法はありますか？あるいは、特定のアカウントに対してはリセット回数が一定に達してから正確入力義務を適用し、それ以外は自動的にグローバルに適用するといった仕組みはいかがでしょうか？
私たちの中には、今日が何曜日かさえも実際にわからない人がおりまして、ましてやメールアドレスを間違えずに正確に思い出すことなど到底できません。
@Chinaski さん、この問題が迅速かつ最終的に解決されることを願っています。
皆様のご回答、ありがとうございます。上記の方法が現時点で最も直接的な対策のようですが、荒らしが収まった後なので実際にテストは行っていません（攻撃の可能性があるユーザーは「ゲスト機能を Wi-Fi で無効にした」と言っていますが、それが原因かどうかは確信が持てません）。
アクティブユーザーが数千人に達している現在（Discourseへの移行は進行中です）、お気持ち痛いほどわかります。自分が使用したメールアドレスを忘れるといった問題は非常に頻繁に発生しており、長年にわたり最も多いサポート問い合わせの一つとなっています。これは本当に驚くべきことです。
パスワード再設定時のメールアドレス入力を必須とする機能は、絶対にデフォルト設定にはなりません。
ただし、OP のケースのようにフォーラムが攻撃を受けている場合は、この厄介なハッキングを封じるために、数週間だけこの機能をオンにする簡単な切り替えが可能かもしれません。
こんにちは
ルールを強化しました。最悪の場合でも、ユーザーは1日に最大6回のリセットしか行えなくなります。これで、メールの件数をある程度制限できるはずです。
また、@riking さんのアドバイスに従い、スクリーニングされたメールアドレスを尊重するようにしました。つまり、管理者が特定の IP アドレスをブロックした場合、その IP アドレスはこの「パーティ」に参加できなくなります。
@riking さん、ここで見落としている大きな点があります。それは、「パスワードリセット」メールにリセットを要求した人の IP アドレスが含まれていないことです。これにより、自己対応が少し難しくなっています。
@codinghorror さん、パスワードリセットメールに要求者の IP アドレスを追加することについてどうお考えですか（少し隠すことも可能です）。これにより、自己対応が大幅に改善されるはずです。
Jane が攻撃を受ける
Jane はサイト管理者に「12.12.12.12 がパスワードをリセットし続けている」と報告する
管理者は 12.12.12.12 をブロックする
ユーザーは多数の IP アドレスにアクセスできるため、まだ猫とネズミのゲームの側面は残りますが、少なくとも以前よりはマシであり、制限も強化されています。
Facebook はこの手法を採用しており、私も導入に賛成です。
これにより、メールに IP アドレスを含める必要がなくなります。サーバー側で追跡し、リンクにはデータベース内の ID が含まれるだけです。つまり、悪用者をブロックする操作がワンクリックで済むようになります。
参考までに、Facebook はパスワードリセットにメールを必須としています（従来の意味でのパスワードリセット機能はなく、メール経由でのログインのみです）
