我有一位用户正遭受某人或脚本的攻击，对方每天多次使用其邮箱地址访问“忘记密码”接口。这种情况已持续数天。由于该操作会发送邮件，也可能对系统造成滥用。通过分析 nginx 的 access.log，我已将部分攻击来源的 IP 地址追踪到系统中的另一位用户，并发送了警告信息，但这可能无法根本解决问题。此外，我已将该 IP 地址添加到“管理 > 日志 > 屏蔽 IP
嗨，Dan，如果你不介意的话，我先问几个问题。
- 你已暂停该用户吗？
- 你允许任何人创建账户，还是需要审核所有新账户？
你可以通过访问 admin/users/list/active 并点击违规用户的姓名来暂停该用户。进入其信息页面后，向下滚动到 权限 部分，然后点击 暂停。请确保该用户已退出登录，因为暂停可能在其退出登录后才会生效。如果他们仍保持登录状态，在该页面右上角有一个蓝色框，你可以手动将其登出。一旦他们退出登录，就无法再使用旧凭据重新登录。
如果你需要审核新账户——并且“肇事者”继续其违规行为（并且你已确定其身份）——该用户必须等待你批准其账户。既然你已经掌握了他使用的一个或多个 IP 地址，如果有新用户使用该 IP 出现，你就知道该如何处理了。
你还可以访问该用户的偏好设置，在 账户 下查看其最近使用的设备，这也会显示他们登录时使用的 IP 地址。这可能为你提供额外的 IP 地址进行筛查。
这正是需要审核账户的地方派上用场。
这个人最初是如何访问其他用户的个人资料并请求重置密码的？这才是关键问题。
2 个赞
只需访问“忘记密码”页面并输入其电子邮件地址即可。任何人都可以为任何用户执行此操作。
2 个赞
具体每天多少次？
2 个赞
好吧，“很多”是相对的。
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.5 年前。
3 个赞
如果有人代表你反复触发“忘记密码”功能，确实很烦人……但我们不能因此将用户锁定在密码重置之外，因为阻止某人进行密码重置本身也是一种恶意行为。
我认为我们在这里设置了每分钟多次的频率限制。@riking，你能否检查这段代码路径并确认它是否仍在正常运行？我们可以提高这个限制，但这无法安全地覆盖“每天几次”的情况。
此外，通过管理员界面的“日志”和“屏蔽 IP”功能封禁某个 IP 地址，应该能阻止该 IP 发起密码重置请求。我认为这一点也需要验证是否按预期工作。@riking
10 个赞
我才是那个被虚假请求 spam 的人。
这种情况每小时发生多次。
即使我启用了双因素认证（2FA）并设置了恢复密钥，也没有选项可以阻止系统向我发送密码重置邮件。
我访问过的某些网站甚至在请求密码重置之前就会显示你的 IP 地址，并声称重置链接将发送至你的邮箱。
所有这些都只是很小的烦扰，因为我很少查看这封邮箱里的任何内容。所有此类邮件都被过滤并设置为“标记为已读”，因此它们不会显示为需要我阅读。我在今年一月就设置好了该过滤器，而今天才第一次查看该文件夹（Gmail 中的标签）。
3 个赞
不错的信息。我们明天就此事取得一些进展吧 @riking
6 个赞
一个简单的变通方法是，将您的邮箱从 test@gmail.com 改为 test+SOMESECRETONLYYOUKNOW@gmail.com。
Discourse 发出的邮件仍会路由到您的常用 Gmail 邮箱，但没人能向您发送“忘记密码”请求，也无法猜测出安全的哈希值。
我认为，在实际操作中，这是目前最好的解决方案。
即使我们将此类请求的频率限制降低到每周一次，仍然会令人烦恼。而使用 + 地址功能，您可以彻底解决这个问题。
12 个赞
除了对来自特定地点的请求进行限流（该措施目前运行良好）之外，我们还可以针对特定用户的请求进行限流。是否可以在用户获得 2 个未过期的重置令牌后，再提示他们“请等待邮件”？
6 个赞
另一种方法是为密码重置邮件设置时间限制，例如在令牌之间设置 3 小时的冷却时间。如果用户在冷却期内再次请求密码重置邮件，可以显示一条简单消息：
“我们已发送密码重置邮件，请检查您的收件箱。如果 2 小时内仍未收到邮件，请联系站点管理员获取帮助：%contact_email%
2 个赞
我在论坛中将邮箱改成了 ‘email+something@gmail.com’，并在另一台浏览器的无痕模式下进行了测试。仍然通过了。这可能是因为请求始终只使用用户名，而从未使用实际的电子邮件地址。
目前所有虚假请求都已停止，因为 Dan 可能已经通过私下与相关人员沟通或其他方式解决了该问题。
如果你们能提供一个安全验证选项（可由用户自行启用），我相信这将大大减少此类请求，因为 trolls 根本无法知道答案。例如：“你最喜欢的电影是什么？”或“你最喜欢的餐厅是哪家？”。
感谢大家迅速回应并努力解决这一问题。不幸的是，这听起来像是第一次，但也希望是最后一次。
3 个赞
我想问题在于，攻击者只需爬取论坛获取用户名，然后发起“忘记密码”的洪水攻击。
或许我们可以添加一个模式，要求必须精确输入邮箱才能触发“忘记密码”功能，即“严格模式”，默认关闭？
我觉得即使每周被攻击一次也太多了，单靠限流无法解决这一问题。
11 个赞
有没有办法在强制要求准确输入之前，先提供一两次“免费”重置机会（在特定时间内）？或者，是否可以在某个账户经历多次重置后，自动对该账户启用准确输入要求，但全局默认不启用？
我们中有些人真的连今天是星期几都不知道，更不用说轻松准确地记住自己的邮箱地址了。
@Chinaski，希望你这个问题能最终且迅速得到解决。
8 个赞
感谢大家的回复。希望上述方案有效，因为目前看来这是最直接的解决办法，但我尚未进行测试，因为骚扰已经停止。（潜在的攻击用户称他已在自己的 Wi-Fi 上关闭了访客模式，但我们无法确定那是否是源头。）
2 个赞
在拥有数千名活跃用户的情况下（我们仍在迁移至 Discourse 的过程中），我完全理解您的困扰。这种情况屡见不鲜，人们常常忘记自己使用的是哪个邮箱地址等等。多年来，这一直是我们收到最多的支持请求之一，简直令人难以置信。
2 个赞
要求输入电子邮件以找回密码肯定永远不会成为默认设置。
但如果论坛像原帖中描述的那样遭受攻击，你可以将其作为一个简单的开关开启几周，以彻底消除这种烦人的攻击。
5 个赞
根据
我收紧了规则，即使在最坏的情况下，用户每天最多也只能进行 6 次重置。这应该在一定程度上限制邮件发送量。
此外，我采纳了 @riking 的建议，我们现已尊重被屏蔽的邮箱地址。因此，如果管理员屏蔽了某个 IP，该 IP 将无法再参与此操作。
这里有一个重要的遗漏（@riking），它可以在一定程度上辅助用户自助处理：当前的“密码重置”邮件并未包含发起重置请求者的 IP 地址：
@codinghorror，您认为在设置密码的邮件中加入发起者的 IP 地址如何？（我们甚至可以将其稍微隐藏起来），这将极大地改善自助处理能力。
Jane 遭到攻击
Jane 通知站点管理员，IP 12.12.12.12 持续尝试重置密码
管理员屏蔽 12.12.12.12
由于人们可以访问大量 IP 地址，这仍然可能演变成猫鼠游戏，但至少情况比以前有所改善，且限制更加严格。
Facebook 使用了这种技巧，我某种程度上支持实施该方案：
这使得他们无需在邮件中包含 IP 地址，只需在服务器端进行追踪，链接中包含数据库中的 ID。这意味着屏蔽滥用者可以变成一键操作。
作为背景补充，Facebook 要求通过邮箱进行密码重置（他们甚至没有传统意义上的密码重置功能，仅仅是通过邮箱登录）。
10 个赞
