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

How to stop hack/DOS attack on web API

提问by James

My website has been experiencing a denial of service/hack attack for the last week. The attack is hitting our web API with randomly generated invalid API keys in a loop.

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

I'm not sure if they are trying to guess a key (mathematically impossible as 64bit keys) or trying to DOS attack the server. The attack is distributed, so I cannot ban all of the IP address, as it occurs from hundreds of clients.

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

My guess is that it is an Android app by the IPs, so someone has some malware in an Android app, and use all the installs to attack my server.

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

Server is Tomcat/Java, currently the web API just responds 400 to invalid keys, and caches IPs that have made several invalid key attempts, but still needs to do some processing for each bad request.

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

Any suggestions how to stop the attack? Is there any way to identify the Android app making the request from the HTTP header?

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

回答by F. Stephen Q

Preventing Brute-Force Attacks:

防止暴力攻击：

There is a vast array of tools and strategies available to help you do this, and which to use depends entirely on your server implementation and requirements.

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

Without using a firewall, IDS, or other network-control tools, you can't really stop a DDOS from, well, denying service to your application. You can, however, modify your application to make a brute-force attack significantly more difficult.

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

The standard way to do this is by implementing a lockoutor a progressive delay. A lockout prevents an IP from making a login request for X minutes if they fail to log in N times. A progressive delay adds a longer and longer delay to processing each bad login request.

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

If you're using Tomcat's authentication system (i.e. you have a <login-constraint>element in your webapp configuration), you should use the Tomcat LockoutRealm, which lets you easily put IP addresses on a lockout once they make a number of bad requests.

如果您使用 Tomcat 的身份验证系统（即您<login-constraint>的 webapp 配置中有一个元素），您应该使用Tomcat LockoutRealm，一旦 IP 地址发出大量错误请求，您就可以轻松地将 IP 地址置于锁定状态。

If you are not using Tomcat's authentication system, then you would have to post more information about what you are using to get more specific information.

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

Finally, you could simply increase the length of your API keys. 64 bits seems like an insurmountably huge keyspace to search, but its underweight by modern standards. A number of factors could contribute to making it far less secure than you expect:

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

• A botnet (or other large network) could make tens of thousands of attempts per second, if you have no protections in place.
• Depending on how you're generating your keys and gathering entropy, your de factokeyspace might be much smaller.
• As your number of valid keys increases, the number of keys that need to be attempted to find a valid one (at least in theory) drops sharply.

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

Upping the API key length to 128 (or 256, or 512) won't cost much, and you'll tremendously increase the search space (and thus, the difficulty) of any brute force attack.

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

Mitigating DDOS attacks:

减轻 DDOS 攻击：

To mitigate DDOS attacks, however, you need to do a bit more legwork. DDOS attacks are hardto defend against, and its especially hard if you don't control the network your server is on.

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

That being said, there are a few server-side things you can do:

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

• Installing and configuring a web-application firewall, like mod_security, to reject incoming connections that violate rules that you define.
• Setting up an IDS system, like Snort, to detect when a DDOS attack is occurring and take the first steps to mitigate it
• See @Martin Muller's postfor another excellent option, fail2ban
• Creating your own Tomcat Valve, as described here, to reject incoming requests by their User-Agents(or any other criterion) as a last line of defense.

• 安装和配置 web 应用程序防火墙，如mod_security，以拒绝违反您定义的规则的传入连接。
• 设置 IDS 系统，如Snort，以检测何时发生 DDOS 攻击并采取第一步缓解它
• 请参阅@Martin Muller 的帖子，了解另一个极好的选择，fail2ban
• 创建你自己的Tomcat Valve，如所描述这里，拒绝通过其进入的请求User-Agents（或任何其他标准）作为防御的最后一道防线。

In the end, however, there is only so much you can do to stop a DDOS attack for free. A server has only so much memory, so many CPU cycles, and so much network bandwidth; with enough incoming connections, even the most efficient firewall won't keep you from going down. You'll be better able to weather DDOS attacks if you invest in a higher-bandwidth internet connection and more servers, or if you deploy your application on Amazon Web Services, or if you bought one of many consumer and enterprise DDOS mitigation products (@SDude has some excellent recommendations in his post). None of those options are cheap, quick, or easy, but they're what's available.

然而，到最后，你能做的只有这么多来免费阻止 DDOS 攻击。一台服务器只有这么多内存、这么多 CPU 周期和这么多网络带宽；有了足够的传入连接，即使是最高效的防火墙也不会阻止您关闭。如果您投资于更高带宽的互联网连接和更多服务器，或者如果您在Amazon Web Services上部署您的应用程序，或者如果您购买了许多消费者和企业 DDOS 缓解产品之一（@ SDude 在他的帖子中有一些很好的建议）。这些选择都不便宜、快捷或容易，但它们是可用的。

Bottom Line:

底线：

If you rely on your application code to mitigate a DDOS, you've already lost

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

回答by joseldn

If it's big enough you just can't stop it alone. You can do all the optimisation you want at the app level, but you'll still go down. In addition to app-level security for prevention (as in FSQ's answer) you should use proven solutions leaving the heavy lifting to professionals (if you are serious about your business). My advise is:

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

1. Sign-up for CloudFlareor Incapsula. This is day to day for them.
2. Consider using AWS API gatewayas the second stage for your API requests. You'll enjoy filtering, throttling, security,auto-scaling and HA for your API at Amazon scale. Then you can forward the valid requests to your machines (in or outside amazon)

1. 注册CloudFlare或Incapsula。这对他们来说是日复一日的。
2. 考虑使用AWS API 网关作为 API 请求的第二阶段。您将享受Amazon 规模的 API 过滤、节流、安全、自动扩展和 HA 。然后您可以将有效请求转发到您的机器（在亚马逊内部或外部）

Internet --> CloudFlare/Incapsula --> AWS API Gateway --> Your API Server

互联网 --> CloudFlare/Incapsula --> AWS API 网关 --> 你的 API 服务器

0,02

0,02

PS: I think this question belongs to Sec

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

回答by Martin Müller

The best way is to prevent the access to your services entirely for those IP addresses who have failed let's say 3 times. This will take most of the load from your server as the attacker gets blocked before Tomcat even has to start a thread for this user.

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

One of the best tools to achieve this is called fail2ban (http://www.fail2ban.org). It is provided as a package in all major linux distributions.

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

What you have to do is basically log the failed attempts into a file and create a custom filter for fail2ban. Darryn van Tonder has a nice example on how to write your own filter on his blog: https://darrynvt.wordpress.com/tag/custom-fail2ban-filters/

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

回答by Pranav

Here are a couple ideas. There are a number of strategies in addition, but this should get you started. Also realize that amazon gets ddos'd on a frequent basis and their systems tend to have a few heuristics that harden them (and therefore you) from these attacks, particularly if you are using Elastic load balancing, which you should be using anyway.

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

• Use a CDN -- they often have ways of detecting and defending against ddos. Akamai, mastery, or amazons own cloud front.
• Use iptables to blacklist offensive ips. The more tooling you have around this, the faster you can blok/unblock

• Use throttling mechanisms to prevent large numbers of requests

• Automatically deny requests that are very large (say greater than 1-2mb; unless you have a photo uploading service or similar) before they get to your application

• Prevent cascading failures by placing a limit on the total number of connections to other components in your system; for example, dont let your database server become overloaded by opening a thousand connections to it.

• 使用 CDN——他们通常有检测和防御 ddos​​ 的方法。Akamai、mastery 或 amazons 自己的云前沿。
• 使用 iptables 将攻击性 ip 列入黑名单。您拥有的工具越多，您可以更快地阻止/解除阻止

• 使用节流机制防止大量请求

• 在它们到达您的应用程序之前自动拒绝非常大的请求（比如大于 1-2mb；除非您有照片上传服务或类似服务）

• 通过限制与系统中其他组件的连接总数来防止级联故障；例如，不要因为打开一千个连接而让您的数据库服务器过载。

回答by Ravindra babu

If D-DOS is attack is severe, application level checks does not work at all. Entire bandwidth will be consumed by D-DOS clients and your application level checks won't be triggered. Practically your web service does not run at all.

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

If you have to keep your application safe from severe D-DOS attacks, you do not have any other option except relying on third party tools by paying money. One of the Clean pipe provider ( who sends only good traffic) tools I can bank on from my past experience : Neustar

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

If D-DOS attack is mild in your website, you can implement application level checks. For example, below configuration will restrict maximum number of connections from single IP as quoted in Restrict calls from single IP

如果您网站中的 D-DOS 攻击较轻，您可以实施应用程序级别检查。例如，下面的配置将限制来自单个 IP 的最大连接数，如限制来自单个 IP 的呼叫中所述

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

For more insight into D-DOS attack, visit Wiki link. It provides list of preventive & responsive tools which includes : Firewalls, Switches, Routers, IPs Based Prevention, D-DOS based defences

有关 D-DOS 攻击的更多见解，请访问Wiki 链接。它提供了一系列预防和响应工具，其中包括：防火墙、交换机、路由器、基于 IP 的预防、基于 D-DOS 的防御

and finally

最后

Clean pipes(All traffic is passed through a "cleaning center" or a "scrubbing center" via various methods such as proxies, tunnels or even direct circuits, which separates "bad" traffic (DDoS and also other common internet attacks) and only sends good traffic beyond to the server)

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

You can find 12 distributors of Clean pipes.

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

回答by symcbean

For a targeted and highly distributed DOS attack the only practical solution (other than providing the capacity to soak it up) is to profile the attack, identify the 'tells' and route that traffic to a low resource handler.

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

Your question has some tells - that the request is invalid, but presumably there is too much cost in determining that. That the requests originate from a specific group of networks and that presumably they occur in bursts.

您的问题有一些说明 - 该请求无效，但大概确定该请求的成本太高。请求来自特定的网络组，并且可能是突发的。

In your comments you've told us at least one other tell - the user agent is null.

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

Without adding any additional components, you could start by tarpitting the connection - if a request matching the profile comes in, go ahead and validate the key, but then have your code sleep for a second or two. This will reduce the rate of requests from these clients at a small cost.

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

Another solution would be to use log failures matching the tell and use fail2banto reconfigure your firewall in real time to drop all packets from the source address for a while.

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

No, its unlikely you will be able to identify the app without getting hold of an affected device.

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