通常，这种防御类型的回报几乎为零。也有例外，但即便如此，这种技术也只能提供少量的安全性。

对随机选择的主机进行详尽的漏洞扫描提供的扫描资源回报极低。相反，成功的攻击者通常会选择以下两个选项之一来增加他们的几率：

1. 检查大量主机上的极少数漏洞
   这包括常见服务（如 SSH、POP3、cPanel、Wordpress、Joomla 等）的错误密码。如果您的 root 密码是“root”或您的站点管理员密码是“admin”，那么您可能会很快陷入其中一个漂移网。

2. 从单个已知漏洞开始，使用搜索技术将目标列表缩小到最有可能的受害者。
   通常这从常见的漏洞数据库之一开始。他找到了一个最近的候选人，并确定了一些在易受攻击的主机上常见的字符串。这通常是“Powered by”行或登录链接或特定的 URL 模式。然后，他使用他最喜欢的搜索引擎检索遵循该模式的网站列表。

重要的一点是，在这两种情况下，攻击者都不会在给定站点上进行多次尝试。他们要么立即成功，要么继续前进。

这并不是说您不会看到偶尔的持续攻击者。总是有一些乐观的人在运行Nessus以对抗 /16，但这种攻击本质上是自我限制的，而且很少成功，因为绝大多数攻击的目标是给定服务器甚至不运行的软件。

这样的攻击能成功吗？是的。它曾经发生过吗？我平均每天处理几台受感染的服务器，到目前为止，我还没有看到有一台来自nessus式的全谱扫描。但概率并不完全为零。在随机攻击的世界中，统计数据和概率非常重要。

例外情况是攻击不是随机的。如果您经营一个高价值或高知名度的网站，您将特别吸引大量针对您的直接攻击。Facebook、Twitter、Hotmail 等网站的攻击流量非常大。如果您处理此类网站，您可能已经非常重视安全性，并且没有寻求建议。

关于 SQL 注入的说明：这种类型的攻击确实需要一些改进；在粗略扫描中捕获 SQL 错误消息后，攻击者可能会向给定服务器发送数十个查询以使位居中。所以从理论上讲，压制响应可能会阻止这种攻击......但可能不会，因为他可能只是使用不同的 IP 返回。由于他已经在您的服务器上收到警报，因此他不会被黑名单吓倒。更好的建议是不要运行蹩脚的软件。今天没有理由使用非参数化查询。

支持列入黑名单的论据：可能会使攻击者的生活更加艰难。虽然这不是一个强大的防御，但它可能会提供一些额外的时间来调查攻击并建立更强大的防御。

反对列入黑名单的论点：在动态 IP 地址的情况下，将它们列入黑名单可能最终会阻止其他良性用户。您可能永远不知道您正在阻止其他良性用户，或者它可能会导致将来难以诊断的错误。此外，管理黑名单还存在一些潜在的配置复杂性。

如果攻击者试图通过超载来破坏站点（以发起拒绝服务攻击），那么阻止 IP 地址可能是正确的答案。一个临时块可能就足够了。

如果攻击者只是探测或扫描，我不太愿意将他们的 IP 地址列入黑名单，但您可以在每种情况下考虑权衡，并就最有意义的事情做出明智的决定。

这显然取决于您的网站所做的事情、阻止 IP 的不利因素（您是否会无意中阻止真正的非攻击性客户）以及某些内容可能受到损害的风险（是否可能某些用户在网站上的密码很弱？）

短期块似乎完全合理，从 5 分钟到一天不等。这可能允许攻击者每天尝试约 1000 次尝试，而在线攻击中每秒尝试约 1000 次。当然，您需要确保不会阻止忘记密码的合法用户。

例如，就我个人而言，我在为本地企业运营的网站上屏蔽了来自中国/俄罗斯的大量 IP 地址。我观察到该网站的 ssh 服务器有几千次尝试使用不存在的用户名登录。虽然他们并没有接近猜测我的用户名，更不用说我的随机高熵密码，但我对这些尝试感到不舒服，所以没有理由让他们继续。所以我用宽松的设置安装了fail2ban（五次登录失败= 30分钟禁令；我的静态IP的白名单——所以如果需要我仍然可以登录——我也有95%的时间使用RSA密钥登录，所以一次失败的登录是稀有的）。我还从 22 更改了 ssh 端口，是的，这只是默默无闻的安全性，很容易被端口扫描打败（尽管我可以为此设置一个蜜罐；但没有），但那 如果它是纵深防御的一部分，那没关系。实施这些更改导致过去一个月的攻击次数下降到零（早在日志开始之前）。

编辑：这个答案不考虑登录暴力，只是试图利用系统漏洞的攻击。当然，暂时禁止在 5 分钟内尝试 30 次登录的 IP 对我来说似乎是合法的。/编辑。

如果您没有适当的自动系统来检查和阻止请求，请不要禁止试图入侵您的服务的 IP 地址。如果你阻止他们，他们就不能再提出请求，你也不会知道是否有泄漏。攻击日以继夜地进行，而且在尝试攻击时，您通常不会查看日志。现在阻止攻击，总有一天会有人发现漏洞。

当然，阻止攻击 IP 是一种预防措施，有助于您的安全。这不是真正的安全，但它可能只是在给你预警的同时抵御攻击。

当您返回默认响应（如 HTTP-200 响应）时，以自动化方式执行此操作可能会有优势，这样自动化工具就不会检测到该块。如果您继续记录请求，您可以稍后检查是否有任何尝试成功。

但这也有一些问题：

• 攻击可能来自僵尸网络、被黑服务器或动态 IP。迟早，您将阻止良性用户。至少暂时禁止该 IP，直到您确定攻击不会成功。
• 检查检测到的攻击的所有请求需要做大量工作，特别是因为有如此多的自动攻击工具会发出数百个请求。
• 您可能会开始以某种方式依赖检测系统。这种预防措施会让您感觉更安全，从而使您在配置系统（或编写代码）时更少考虑安全性。
• 您仍然需要不时检查日志文件，以确保您的检测系统没有遗漏任何内容。
• 可能会出现误报。一个简单的示例是，当检测 POST 数据中的撇号（攻击工具可能会尝试检测 SQL 注入）时，您可以阻止尝试在其密码中使用撇号的用户。这可以通过验证码解决，但有针对性的攻击也将解决验证码。

总的来说，我不会阻止任何未遂攻击。在某些情况下，这是一个好主意（也许在高度安全的环境中，例如对于拥有数百万访问者的银行或网站），但总的来说，我认为它不会真正有帮助，甚至可能会给你一个错误的安全感。

唯一的例外是 DoS 攻击。这里没有安全风险，唯一被利用的是处理时间或带宽，所以没有理由不阻止它。尽管即便如此，也只是暂时限制或禁止：这些攻击很可能来自僵尸网络，从而使您阻止用户的 IP。