我对网络安全相当陌生，我刚刚了解了可用于自动漏洞检测/预防的 Fail2Ban 框架。它说您可以通过设置一个规则来保护自己免受 DOS 攻击，该规则将在配置的时间内尝试配置的次数后自动阻止其 IP，方法是将其添加到 IPTables。我的问题是，如果您所做的只是拒绝他们的请求，那么他们仍然可以尝试在该端口上发送信息。他们还能不能因为请求而使您的服务器过载？
我已经对此进行了一些研究，我能找到的唯一潜在原因是，对于 DOS 攻击，它们受到上传带宽的限制，几乎可以保证小于你的下载带宽，所以即使他们试图如果您阻止他们的 IP 并且不对信息进行任何处理，那么他们会用请求尽可能地打击您，那么他们实际上是在向那里的砖墙扔鹅卵石。这个对吗？使用这种方法可以保护您免受 DOS 攻击的其他原因是什么？
我的问题是，如果您所做的只是拒绝他们的请求，那么他们仍然可以尝试在该端口上发送信息。他们还能不能因为请求而使您的服务器过载？
是的，一部分攻击者可以。如果他们的带宽大于您的带宽，或者他们找到了一种比他们更快地使用您的带宽来抵消差异的方法，那么您将缺乏带宽并且合法流量无法通过。
这实际上在任何时候都是真实的，attacker_effective_bandwidth + legal_bandwidth > server_bandwidth，因此它不仅取决于攻击者的资源，还取决于您过度配置的程度。
另请注意，fail2ban 专注于您记录或监控的访问尝试和漏洞利用。某些拒绝服务攻击依赖于可能未记录的通信（例如 ICMP 回显请求），并且可能不会触发 fail2ban。
如果您阻止他们的 IP 并且不对信息进行任何处理，那么他们实际上是在向那里的砖墙扔鹅卵石。这个对吗？
仅当您保留的资源是 CPU 时才正确，并且如果 fail2ban 将根据导致 CPU 使用的所有流量来观察 /trigger。丢弃数据包确实需要大量的 CPU，但它比尝试用它们做任何其他事情要小得多。
使用这种方法可以保护您免受 DOS 攻击的其他原因是什么？
我不明白这个问题，但我认为 fail2ban 是您可能使用的一种工具，而且是一种合理的工具。但是，如果您的网站宕机成本高于获取和维护防止宕机所需工具的成本，您应该考虑添加其他工具。
要回答您的问题，是的，阻止攻击者对您的服务器进行 DoS 攻击的 IP 是一种有效的缓解措施。这是出于两个基本原因：
原因 #1： 假设，如果攻击者使用基于泛洪的基本攻击，其目的是用带宽（比如上传文件？）淹没服务器，阻止他们的 IP 将显着降低他们的攻击带宽对您的服务器有任何影响（只要您的服务器不是在驱动 Raspberry Pi 的轮子上运行的仓鼠）。
应该注意的是，#1 是 DoS 攻击的一种罕见的攻击策略，因为实际上，单个攻击节点不具备通过泛滥请求来使服务器崩溃的带宽能力。比较常见的情况是
原因 2： 应用程序级别的 DoS 攻击更加有效。例如，假设您的网站有一个登录页面，该页面对提供的密码进行服务器端加密散列。聪明的攻击者可以尝试通过将 DoS 攻击集中在该登录请求上来使服务器崩溃，从而在典型负载轻得多时使服务器计算成百上千的同时登录。在这种情况下，您描述的 Fail2Ban 框架应该可以完美运行，因为它可以过滤掉攻击者的虚假登录请求。
整个缓解策略可以通过在攻击者的笔记上频繁轮换一个欺骗性的 IP 地址来规避，但这变成了一个奇怪的 DDoS/DoS 混合体，并且您特别询问了旧式 DoS。因此，答案成立。简单地阻止攻击 IP 应该是足够的防御。
这里可能最重要的是，在缓解方面，如今区分 DoS 和 DDoS 攻击几乎没有用。不再有来自单个固定 IP 源的真实世界拒绝服务攻击。
唯一明显的例外是攻击者生成特制数据包以利用具有 DoS 潜力的漏洞（例如，数据包处理代码中某处的null指针取消引用；这是此类漏洞的示例）。但是阻止运行漏洞利用的源 IP 地址并不是缓解这种情况的好方法。修补易受攻击的系统是。
理论上，处理简单的 DoS 攻击比处理分布式攻击更容易。但是，由于这些太容易缓解，它们现在大多已灭绝，而且您所询问的工具 (Fail2Ban) 并不能帮助抵御已灭绝的攻击，它是在考虑实际应用程序的情况下编写的。
考虑到这一点，仅当同时满足两个条件时，阻止 IP 地址（使用 Fail2Ban 或手动）才有意义：
对于典型的 HTTPS 服务器，您可以使用 IP 范围阻塞来对抗，例如TCP 连接泛洪、SSL/TLS 握手泛洪、POST 泛洪、Slowloris等（除了简单泛洪之外，很难对第 7 层攻击进行分类），这在大多数情况下都满足这两个要求。
请注意，虽然，例如，足够大的 POST 洪水实际上可能会影响服务器前面的网络传输，但 IP 阻塞仍然可以帮助您，因为它可以防止建立底层 TCP 连接，而恶意机器人不会随后能够向您的服务器发送大型 POST 正文。这有效地将剩余的恶意传入流量限制为在大多数情况下易于处理的低速率 SYN 泛洪。
此外，基于 HTTP 的洪水对您的网络传输造成的主要影响是由于您的服务器在响应中生成的出站流量（在今天的 HTTP 中可能是入站流量的 11-12 倍），并且阻塞了由于上述原因，HTTP 泛洪的 IP 源也消除了这种情况。
同时，IP 阻塞对于ICMP 泛洪、SYN 泛洪、UDP 泛洪等至少不满足要求 2 的攻击大多无用；以及针对在大多数情况下在入站流量方面非常强大以至于它们不满足要求#1 的放大攻击。
请注意，无法验证 SYN 洪水中的源 IP 地址这一事实并不一定意味着它是被欺骗的。但是，阻止可能被欺骗的 IP 地址范围可能会导致合法用户无法访问您的服务。事实上，攻击者的意图可能是诱使您开始自动（例如通过上述 Fail2Ban 工具）阻止基于数据包的洪水的源 IP 地址，而流量中只有少数来源，然后欺骗重要的IP 地址范围，例如您所在国家/地区最大的 ISP 的 IP 范围，甚至全球约 40 亿个地址的 IPv4 地址范围，以每秒 100 Mbit 的任意泛洪速率，都可以在大约一个小时内枚举——我实际上已经在我的生活中看到过几次。