security - 最好的分布式蛮力对策是什么？

Question

首先，一点背景知识:我正在为 CodeIgniter 实现一个 auth+auth 系统已经不是什么 secret 了，到目前为止我赢了(可以这么说)。但是我遇到了一个非常重要的挑战(大多数身份验证库完全错过了这个挑战，但我坚持正确处理它):如何智能地处理 大规模、分布式、可变用户名暴力攻击 .

我知道所有常用的技巧:

限制每个 IP/主机的失败尝试次数 并拒绝违规者访问(例如 Fail2Ban) - 这不再有效 since botnets have grown smarter

将上述内容与 相结合已知“坏”IP/主机的黑名单 (例如 DenyHosts) - 依赖于排名第一的僵尸网络，which they increasingly don't

IP/主机白名单结合传统身份验证(可悲的是，对于动态 IP 用户和大多数网站的高流失率毫无用处)

设置 全站限制在 N 分钟/小时的时间内尝试失败的次数，并在此之后的几分钟/小时内限制(暂停)所有登录尝试(DoS 攻击你的问题变成了僵尸网络的 child 的游戏)

必填 数字签名 (公钥证书)或 RSA 硬件 token ，适用于没有登录/密码选项的所有用户(毫无疑问，这是一个坚如磐石的解决方案，但仅适用于封闭的专用服务)

强制执行 超强密码方案 (例如，> 25 个带有符号的无意义字符 - 同样，对于临时用户来说太不切实际了)

最后，验证码 (在大多数情况下可以工作，但对用户和 virtually useless 对 determined, resourceful attacker 来说很烦人)

现在，这些只是理论上可行的想法。有很多垃圾想法使网站大开眼界(例如针对琐碎的 DoS 攻击)。我想要的是更好的东西。更好的是，我的意思是:

它必须是安全的 (+) 以抵御 DoS 和蛮力攻击，并且不会引入任何可能允许稍微狡猾的机器人继续在雷达下运行的新漏洞

它必须是自动化的。如果它需要人工运算符(operator)来验证每次登录或监控可疑事件，那么它在现实世界中是行不通的

它必须适用于主流 Web 使用(即非程序员可以执行的高流失率、高容量和开放注册)

它不能妨碍用户体验，以至于临时用户会感到恼火或沮丧(并可能放弃网站)

它不能涉及小猫，除非它们是真正安全的小猫

(+) 通过“安全”，我的意思是至少与偏执用户保密密码的能力一样安全

所以——让我们听听吧!你会怎么做？你知道我没有提到的最佳实践吗(哦，请说你知道)？我承认我确实有自己的想法(结合 3 和 4 的想法)，但在让自己尴尬之前，我会让真正的专家发言；-)

Answer 1

好吧，拖得够久了；这是我到目前为止想出的

(抱歉，前面的帖子太长了。勇敢点， friend ，这趟旅程是值得的)

将原始帖子中的方法 3 和 4 组合成一种“模糊”或动态白名单，然后 - 这就是诀窍 - 不阻止未列入白名单的 IP，只是将它们节流到 hell 然后返回。

Note that this measure is only meant to thwart this very specific type of attack. In practice, of course, it would work in combination with other best-practices approaches to auth: fixed-username throttling, per-IP throttling, code-enforced strong password policy, unthrottled cookie login, hashing all password equivalents before saving them, never using security questions, etc.

关于攻击场景的假设

如果攻击者的目标是可变用户名，我们的用户名限制不会触发。如果攻击者使用僵尸网络或可以访问较大的 IP 范围，我们的 IP 节流将无能为力。如果攻击者预先抓取了我们的用户列表(通常在开放注册 Web 服务上可能)，我们将无法根据“未找到用户”错误的数量检测到正在进行的攻击。如果我们在系统范围内强制执行限制性(所有用户名、所有 IP)限制，任何此类攻击都会在攻击持续时间加上限制期间对我们的整个站点进行 DoS。

所以我们需要做一些其他的事情。

第一部分对策:白名单

我们可以相当肯定的是，攻击者无法检测和动态欺骗我们数千名用户 (+) 的 IP 地址。这使得白名单变得可行。换句话说:对于每个用户，我们存储用户先前(最近)登录的(散列)IP 列表。

因此，我们的白名单方案将起到一扇锁定的“前门”的作用，用户必须从其公认的“好”IP 之一连接到其中才能登录。对这个“前门”进行蛮力攻击几乎是不可能的(+)。

(+) 除非攻击者“拥有”服务器、我们所有用户的盒子或连接本身——在这些情况下，我们不再有“身份验证”问题，我们有一个真正的特许经营规模的拉取-plug FUBAR情况

对策的第二部分:对无法识别的 IP 进行全系统限制

为了使白名单适用于用户频繁切换计算机和/或从动态 IP 地址连接的开放注册 Web 服务，我们需要为从无法识别的 IP 连接的用户打开“猫门”。诀窍是设计那扇门，让僵尸网络陷入困境，让合法用户尽可能少地受到打扰。

在我的方案中，这是通过设置一个非常严格的未批准 IP 登录尝试失败的最大次数来实现的，例如 3 小时(根据服务类型使用更短或更长的时间段可能更明智)，并且做出限制 全局 ，即。对于所有用户帐户。

使用这种方法，即使是缓慢的(两次尝试之间 1-2 分钟)蛮力也会被检测到并快速有效地阻止。当然，一个非常慢的蛮力仍然可能不被注意，但是太慢的速度会破坏蛮力攻击的目的。

我希望通过这种节流机制实现的是，如果达到最大限制，我们的“猫门”会砰地关上一段时间，但我们的前门仍然对通过常规方式连接的合法用户开放:

通过从他们认可的 IP 之一连接

或者通过使用持久登录 cookie(从任何地方)

在攻击期间唯一会受到影响的合法用户 - 即。当限制被激活时 - 将是没有持久登录 cookie 的用户，他们从未知位置或使用动态 IP 登录。在限制结束之前，这些用户将无法登录(这可能需要一段时间，如果攻击者在限制下保持其僵尸网络运行)。

为了让这一小部分用户挤过原本密封的猫门，即使机器人仍在攻击它，我也会使用带有 CAPTCHA 的“备份”登录表单。因此，当您显示“抱歉，您目前无法从此 IP 地址登录”消息时，请包含一个链接，内容为“ 安全备份登录 - 仅限人类(机器人:不说谎) ”。抛开玩笑，当他们点击该链接时，给他们一个经过 reCAPTCHA 验证的登录表单，绕过站点范围的限制。这样，如果他们是人类并且知道正确的登录名+密码(并且能够阅读验证码)，他们将 从不 被拒绝服务，即使他们是从未知主机连接而不使用自动登录 cookie。

哦，澄清一下:由于我确实认为 CAPTCHA 通常是邪恶的，“备份”登录选项将 只有节流处于事件状态时出现。

不可否认，像这样的持续攻击仍然会构成 DoS 攻击的一种形式，但是在所描述的系统到位后，它只会影响我怀疑的一小部分用户，即不使用“记住我” cookie 并且碰巧在攻击发生时登录并且没有从他们的任何常用 IP 登录并且无法读取验证码。只有那些可以对所有这些标准说不的人——特别是机器人和非常不幸的残疾人——才会在机器人攻击期间被拒之门外。

EDIT: Actully, I thought of a way to let even CAPTCHA-challenged users pass through during a 'lockdown': instead of, or as a supplement to, the backup CAPTCHA login, provide the user with an option to have a single-use, user-specific lockdown code sent to his email, that he can then use to bypass the throttling. This definitely crosses over my 'annoyance' threshold, but since it's only used as a last resort for a tiny subset of users, and since it still beats being locked out of your account, it would be acceptable.

(另外，请注意 无 如果攻击没有我在此处描述的讨厌的分布式版本那么复杂，就会发生这种情况。如果攻击来自仅几个 IP 或仅攻击几个用户名，它会更早地被阻止，并且会产生 没有 站点范围的后果)

所以，这就是我将在我的身份验证库中实现的对策，一旦我确信它是合理的并且没有我错过的更简单的解决方案。事实是，在安全方面有很多微妙的方法可以做错事，我不会做出错误的假设或无可救药的有缺陷的逻辑。因此，请高度赞赏任何和所有反馈、批评和改进、微妙之处等。