如何阻止对 Web API 的 hack/DOS 攻击答案

【问题标题】：How to stop hack/DOS attack on web API如何阻止对 Web API 的 hack/DOS 攻击
【发布时间】：2015-12-11 02:40:20
【问题描述】：

上周，我的网站遭受了拒绝服务/黑客攻击。攻击是在循环中使用随机生成的无效 API 密钥攻击我们的 Web API。

我不确定他们是在尝试猜测密钥（在数学上不可能作为 64 位密钥）还是尝试对服务器进行 DOS 攻击。攻击是分布式的，所以我不能禁止所有 IP 地址，因为它来自数百个客户端。

我的猜测是IP是Android应用程序，所以有人在Android应用程序中安装了一些恶意软件，并使用所有安装来攻击我的服务器。

服务器是Tomcat/Java，目前web API对无效key只响应400，缓存多次尝试无效key的IP，但对每个bad request仍然需要做一些处理。

有什么建议可以阻止攻击吗？有什么方法可以识别从 HTTP 标头发出请求的 Android 应用？

【问题讨论】：

什么是 HTTP 标头？
头部有IP，代理字符串为空
mathematically impossible as 64bit keys Wut？ a) 密钥比消息短的加密系统无法阻止攻击者获取一些隐藏信息（最坏的情况是整个明文）。这里没有“不可能”。 b) 2015 年的 64 位密钥 (DES?) 并不多。我宁愿说它很弱。
黑客试图通过随机猜测 ID 来猜测应用 ID，我们的应用 ID 是 64 位长，因此您猜测有效应用 ID 的几率约为 18,446,744,073,709,551,616 分之一。因此，如果您每秒尝试 1,000 次，则猜测有效 ID 需要大约 584,942,417 年
看看OWASP：owasp.org/index.php/Web_Service_Security_Cheat_Sheet

标签： java android http security

【解决方案1】：

防止暴力攻击：

有大量的工具和策略可以帮助您做到这一点，而使用哪种工具和策略完全取决于您的服务器实现和要求。

如果不使用防火墙、IDS 或其他网络控制工具，您无法真正阻止 DDOS 拒绝为您的应用程序提供服务。但是，您可以修改您的应用程序，使暴力攻击变得更加困难。

执行此操作的标准方法是实施锁定或渐进式延迟。如果 IP 登录 N 次失败，则锁定会阻止 IP 发出登录请求 X 分钟。渐进式延迟会使处理每个错误登录请求的延迟越来越长。

如果您使用的是 Tomcat 的身份验证系统（即您的 webapp 配置中有一个<login-constraint> 元素），您应该使用Tomcat LockoutRealm，这样您就可以轻松地将 IP 地址锁定为糟糕的要求。

如果您没有使用 Tomcat 的身份验证系统，那么您将不得不发布更多关于您正在使用的信息以获得更具体的信息。

最后，您可以简单地增加 API 密钥的长度。 64 位似乎是一个不可逾越的巨大搜索键空间，但按照现代标准，它的权重不足。许多因素可能导致其安全性远低于您的预期：

如果没有适当的保护措施，僵尸网络（或其他大型网络）每秒可能会进行数万次尝试。
根据您生成密钥和收集熵的方式，您的 de facto 键空间可能要小得多。
随着有效密钥数量的增加，需要的密钥数量试图找到一个有效的（至少在理论上）滴尖锐。

将 API 密钥长度增加到 128（或 256 或 512）不会花费太多，而且您将极大地增加任何暴力攻击的搜索空间（从而增加难度）。

缓解 DDOS 攻击：

但是，要减轻 DDOS 攻击，您需要做更多的工作。 DDOS 攻击难以防御，如果您不控制服务器所在的网络，则尤其难以防御。

话虽如此，您可以做一些服务器端的事情：

安装和配置 Web 应用程序防火墙，例如 mod_security，以拒绝违反您定义的规则的传入连接。
设置 IDS 系统，例如 Snort，以检测何时发生 DDOS 攻击并采取初步措施来缓解它
请参阅@Martin Muller's post 以获得另一个出色的选择，fail2ban
创建您自己的 Tomcat Valve，如 here 所述，以通过 User-Agents（或任何其他标准）拒绝传入请求作为最后一道防线。

然而，最终，您可以做的只有这么多，才能免费阻止 DDOS 攻击。服务器只有这么多内存、这么多 CPU 周期和这么多网络带宽；有了足够的传入连接，即使是最有效的防火墙也无法阻止您崩溃。如果您投资于更高带宽的互联网连接和更多服务器，或者如果您在Amazon Web Services 上部署您的应用程序，或者如果您购买了众多消费者和企业 DDOS 缓解产品之一（@ 987654328@)。这些选项都不是便宜、快速或简单的，但它们是可用的。

底线：

如果您依赖应用程序代码来缓解 DDOS，那么您已经输了

【讨论】：

谢谢，我考虑过延迟对错误 IP 的响应，不确定是否会花费更多的服务器时间来休眠响应线程而不是仅仅拒绝请求。也许只是拒绝请求使用最少的服务器资源，但来自黑客的请求有 20,000 个请求并且还在增长。有没有办法不回答请求，所以客户端至少会挂起一段时间？
当然。在得到响应之前，HTTP 无法知道另一端是否有人。如果您不响应，客户端将一直等到超时结束。但是，总体而言，DDOS 攻击很难防御，尤其是在您无法控制网络的情况下。我强烈建议使用较低级别的解决方案，例如正确配置的防火墙，而不是尝试将 DDOS 缓解技术融入您的应用程序。如果他们连接到您的应用并使用少量资源，那么他们就是赢家。
@James，一种较低级别的方法是编写一个 Tomcat Valve 来拒绝具有空用户代理的请求； this thread 有一些关于如何操作的好信息。
谢谢，由于攻击来自数百个/未知 IP 并且正在执行验证 Web API 请求（仅使用无效的 API 密钥），我看不出防火墙如何提供帮助。知道如何不响应 Tomcat REST 服务中的请求吗？
我们支持 Web API，并支持 Android 和 JavaScript 客户端，因此必须允许空代理。

【解决方案2】：

如果 D-DOS 攻击严重，则应用程序级别检查根本不起作用。 D-DOS 客户端将占用整个带宽，并且不会触发您的应用程序级别检查。实际上，您的 Web 服务根本不运行。

如果您必须保护您的应用程序免受严重的 D-DOS 攻击，您别无选择，只能通过付费来依赖第三方工具。根据我过去的经验，我可以依靠的清洁管道提供商之一（只发送良好的流量）工具：Neustar

如果 D-DOS 攻击在您的网站中较为轻微，您可以实施应用程序级别检查。例如，以下配置将限制来自单个 IP 的最大连接数，如 Restrict calls from single IP 中引用的那样

<Directory /home/*/public_html> -- You can change this location
    MaxConnPerIP 1  
    OnlyIPLimit audio/mpeg video
</Directory>

如需深入了解 D-DOS 攻击，请访问Wiki link。它提供了一系列预防和响应工具，包括：防火墙、交换机、路由器、基于 IP 的预防、基于 D-DOS 的防御

最后

清洁管道（所有流量都通过代理、隧道甚至直接电路等各种方法通过“清洁中心”或“洗涤中心”，这分离“坏”流量（DDoS 和其他常见的互联网攻击），只将好的流量发送到服务器）

您可以找到 12 家清洁管道经销商。

【讨论】：

谢谢，它还没有服务器，希望它不会到这个，我怀疑我买不起。
在这种情况下，您可以选择基于 IP 的预防措施、防火墙等。

【解决方案3】：

最好的方法是完全阻止那些失败的 IP 地址访问您的服务，比如说 3 次。这将占用您服务器的大部分负载，因为攻击者在 Tomcat 甚至必须为该用户启动线程之前就被阻止了。

实现此目的的最佳工具之一称为fail2ban (http://www.fail2ban.org)。它在所有主要的 linux 发行版中作为一个包提供。

您要做的基本上是将失败的尝试记录到一个文件中，并为 fail2ban 创建一个自定义过滤器。 Darryn van Tonder 在他的博客上有一个关于如何编写自己的过滤器的好例子：https://darrynvt.wordpress.com/tag/custom-fail2ban-filters/

【讨论】：

【解决方案4】：

如果它足够大，你就无法单独阻止它。您可以在应用程序级别进行所有您想要的优化，但您仍然会失败。除了用于预防的应用程序级安全性（如 FSQ 的回答），您应该使用经过验证的解决方案，将繁重的工作留给专业人员（如果您对自己的业务很认真）。我的建议是：

注册CloudFlare 或Incapsula。这是他们的日常。
考虑使用AWS API gateway 作为 API 请求的第二阶段。您将在 Amazon 规模 享受 API 的过滤、节流、安全性、自动缩放和 HA。然后您可以将有效请求转发到您的机器（亚马逊内部或外部）

Internet --> CloudFlare/Incapsula --> AWS API Gateway --> 你的 API 服务器

0,02

PS：我觉得这个问题属于Sec

【讨论】：

【解决方案5】：

对于有针对性和高度分布的 DOS 攻击，唯一实用的解决方案（除了提供吸收它的能力）是分析攻击，识别“告诉”并将该流量路由到资源不足的处理程序。

您的问题有一些迹象 - 请求无效，但确定该请求的成本可能过高。请求来自特定的网络组，并且可能是突发性的。

在您的 cmets 中，您至少告诉了我们另一个 - 用户代理为空。

在不添加任何其他组件的情况下，您可以从缓送连接开始 - 如果收到与配置文件匹配的请求，请继续验证密钥，然后让您的代码休眠一两秒钟。这将以较低的成本降低来自这些客户的请求率。

另一种解决方案是使用与告诉匹配的日志故障并使用fail2ban 实时重新配置您的防火墙，以便在一段时间内丢弃来自源地址的所有数据包。

不，您不太可能在不获取受影响设备的情况下识别应用程序。

【讨论】：

【解决方案6】：

这里有几个想法。此外还有许多策略，但这应该可以帮助您入门。还要意识到亚马逊经常受到 ddos 攻击，并且他们的系统往往有一些启发式方法可以使他们（以及您）免受这些攻击的影响，特别是如果您使用的是弹性负载平衡，无论如何您都应该使用它。

使用 CDN - 他们通常有检测和防御 ddos 的方法。 Akamai、mastery 或 amazon 拥有自己的云前端。
使用 iptables 将攻击性 ip 列入黑名单。您拥有的工具越多，阻止/解除阻止的速度就越快
使用限制机制防止大量请求
在非常大的请求到达您的应用程序之前自动拒绝它们（比如大于 1-2mb；除非您有照片上传服务或类似服务）
通过限制与系统中其他组件的连接总数来防止级联故障；例如，不要因为打开一千个连接而让您的数据库服务器过载。

【讨论】：