应用层缓慢拒绝服务攻击_如何保护您的应用程序免受拒绝服务攻击

应用层缓慢拒绝服务攻击

by Akash Sant

通过Akash Sant

I wrote this post not to describe how to use certain technologies, but rather to provide insights into the lessons we learned while mitigating a Denial of Service (DoS) attack on a web based service we built.

我写这篇文章不是要描述如何使用某些技术，而是要提供对我们所学到的教训的见解，同时减轻对我们构建的基于Web的服务的拒绝服务(DoS)攻击。

We’ll start with a bit of a background for context.

我们将从上下文的背景开始。

For the past year, my friends and I believed that inter-city transportation needed a serious upgrade.

在过去的一年中，我和我的朋友们认为城际交通需要进行认真的升级。

We started noticing that something didn’t seem right here. We are all busy students, and waiting in such long lines for public transportation is just not worth our time. Inter-city transportation lacked the elements of reliability, efficiency, and simplicity. We decided that going forward, this needed to change.

我们开始注意到这里似乎不存在某些东西。 我们都是忙碌的学生，在如此长的队伍中等待公共交通根本不值得我们花费时间。 城际交通缺乏可靠性，效率和简单性的要素。 我们认为，向前迈进，这需要改变。

POOL简介-#MadeWithLove (Introducing POOL - #MadeWithLove)

For the past few months, a team of four Software Engineers and I have been working on a simple, fast, and easy to use car pooling application for Android and iOS.

在过去的几个月中，我和四个软件工程师组成的团队一直致力于为Android和iOS开发一个简单，快速且易于使用的汽车拼车应用程序。

I recall the day when we first met to brainstorm the idea for the project. Our notes were filled with the challenges we would be facing while executing an idea of such scale. Challenges that were related to the reliability of users, trust between drivers and riders, and trip scheduling issues.

我记得那天我们第一次见面时就该项目的想法进行了集思广益。 我们的笔记充满了在执行如此规模的想法时我们将面临的挑战。 与用户可靠性，驾驶员与骑手之间的信任以及行程安排问题相关的挑战。

The current number of members on Waterloo carpooling and ride sharing groups on Facebook is approximately 40,000. We knew we would have to build fast and scalable services. We started our first prototype as an Android application, which lead to a port to React Native to make it cross-platform.

Facebook上滑铁卢拼车和乘车共享小组的现有成员人数约为40,000。 我们知道我们将必须构建快速且可扩展的服务。 我们以Android应用程序开始了我们的第一个原型，这导致了React Native移植到跨平台。

On March 7th, 2018, we announced an official release of version 1.0.

2018年3月7日，我们宣布了1.0版的正式发布。

Within two hours, 40+ users had signed up and 14+ drivers had offered their services. Everything was going as planned. However, it wouldn’t really be a party without a party crasher, would it?

在两个小时内，有40多个用户注册了，有14多个驱动程序提供了他们的服务。 一切都按计划进行。 但是，如果没有聚会失败者，那真的不是聚会吗？

拒绝服务攻击 (The Denial of Service Attack)

Denial of Service (DoS) attacks aim to flood the victim servers with fake requests, thus preventing them from serving legitimate users.

拒绝服务(DoS)攻击旨在向虚假请求泛滥成灾服务器，从而阻止它们为合法用户提供服务。

Three hours after we launched, we received a support email from a user with the message that, “The nearby trips just keeps on displaying the loading symbol”. I felt slightly excited to know that someone cared enough to send us a support email, but my excitement was short lived after I decided to have a look at the server logs. I couldn’t believe what I was seeing.

发射三小时后，我们收到了一封来自用户的支持电子邮件，内容为：“附近的旅行一直在显示装载符号”。 得知有人足够关心向我们发送支持电子邮件时，我感到有些兴奋，但是当我决定查看服务器日志后，我的激动之情短暂了。 我简直不敢相信自己所看到的。

The servers were getting overwhelmed by a flood of ~600 requests per second. We were under attack, and instantly knew this was not legitimate traffic.

每秒约600个请求的泛滥使服务器不堪重负。 我们受到攻击，立即知道这不是合法流量。

My first instinct was to put the servers in maintenance mode and hope that the attacker would go away. But as soon as we restored the server back from maintenance mode, the attacks resumed. At this point, we realized that our app was getting more traction than we had assumed and I was completely confused as to where to start with implementing a fix.

我的第一个本能是将服务器置于维护模式，并希望攻击者能够走开。 但是，只要我们将服务器从维护模式恢复回原来的状态，攻击就会恢复。 在这一点上，我们意识到我们的应用程序比我们想象的更具吸引力，而我对于从何处开始实施修订完全感到困惑。

Project SOS-保护我们的服务 (Project S.O.S - Securing our Services)

All the core team members were alerted, and we assembled to put our brains together to mitigate the attack. We used a number of different methods, which I’ll describe below.

所有核心团队成员都收到了警报，我们齐心协力以减轻攻击。 我们使用了许多不同的方法，下面将对其进行介绍。

限速 (Rate-limiting)

When the attacks continued, I knew we needed to slow them down by implementing some kind of rate-liming on our APIs.

当攻击持续进行时，我知道我们需要通过在API上实施某种速率限制来降低攻击速度。

Rate-limiting is essentially limiting the number of requests (per minute) to a given IP from a specific source (which in our case was the Internet). After applying the rate limit, only a specific number of requests would be accepted by the server.

速率限制本质上是限制从特定来源(在我们的情况下是Internet)到给定IP的请求(每分钟)数量。 应用速率限制后，服务器将仅接受特定数量的请求。

The rate-limiting algorithm must be fast so that it doesn’t just queue all of the incoming requests, but rather rejects all the attacker’s requests as quickly as possible.

限速算法必须快速，以便它不仅可以将所有传入请求排队，还可以尽快拒绝所有攻击者的请求。

This was a start, but it was definitely not enough to stop the attacker for good.

这只是一个开始，但绝对不足以永远阻止攻击者。

端点特定的速率限制 (Endpoint specific Rate-limiting)

Next, due to rate limiting, flooding the servers and causing request queuing was not feasible for the attacker. So the attacker slightly changed their strategy. Instead, they now targeted POST endpoints on the server in order to post fake data to the server. This meant that they could create N trips every minute (based on the previous rate-limiting step).

接下来，由于速率限制，使服务器泛滥并导致请求排队对于攻击者而言是不可行的。 因此，攻击者略微改变了他们的策略。 相反，他们现在将服务器上的POST端点作为目标，以便将虚假数据发布到服务器。 这意味着他们可以每分钟创建N次旅行(基于先前的速率限制步骤)。

In a couple of hours, the server had 100s of dummy trips created by the attacker. This called for rate-limiting the POST endpoints with a stricter limit. Rate-limiting our POST endpoints to about two requests per hour did the trick. Even if the attacker now created dummy trips, we would have enough time to catch them and clean-up our datastore.

在几个小时内，服务器就有了数百次由攻击者创建的虚拟行程。 这要求使用更严格的限制来限制POST端点的速率。 将我们的POST端点的速率限制为每小时大约两个请求就可以了。 即使攻击者现在创建了虚拟行程，我们也有足够的时间来捕获它们并清理我们的数据存储。

下次好运！ (Better luck next time!)

During the next few hours of monitoring, the attacker tried again. However no damage was done and the application was successfully live throughout the attack. So the rate-limiting strategies had done the trick! Now it was time to focus on finding who it was.

在接下来的几个小时的监视中，攻击者再次尝试。 但是，没有造成任何损害，并且该应用程序在整个攻击过程中均成功运行。 因此，限速策略就成功了！ 现在是时候专注于找到谁了。

Monitoring and tracking our server logs allowed us to retrieve the IP address for the origin of the attacks.

监视和跟踪我们的服务器日志使我们能够检索攻击源的IP地址。

The request path and the attacker’s forward IP address have been redacted for privacy reasons. The logs were recorded during maintenance mode. If you inspect the logs more closely, you’ll notice the id field in the request. This represents the fake account that the user had created on our services to be able to gain access to the app.

由于隐私原因，已经删除了请求路径和攻击者的转发IP地址。 在维护模式下记录日志。 如果您仔细检查日志，则会在请求中注意到id字段。 这代表用户在我们的服务上创建的伪帐户，以便能够访问该应用。

Pool uses Facebook authentication, meaning the attacker had created a fake Facebook account to sign-up with Pool. Using the local id (recorded in the logs) we were able to find the Facebook id for the user and issue an account ban.

Pool使用Facebook身份验证，这意味着攻击者创建了一个虚假的Facebook帐户来注册Pool。 使用本地id (记录在日志中)，我们能够找到用户的Facebook id并发出帐户禁令。

Our team then used https://www.whois.com/whois/ to perform a domain lookup on this IP address.

然后，我们的团队使用https://www.whois.com/whois/在此IP地址上执行域查找。

With more digging around, we noticed that the requests were originating from an EC2 instance on Amazon Web Services. At this point we realized that we could have just reported the IP address to AWS, but what’s the fun in taking the easy way out?

随着更多的挖掘，我们注意到请求来自Amazon Web Services上的EC2实例。 在这一点上，我们意识到我们可以将IP地址报告给AWS，但是采取简单的方法有什么乐趣呢？

还没有结束... (It doesn’t end just yet…)

Following these measures, before the account ban could take affect, the attacker decided to use the Google Cloud Platform API keys (formerly exposed on client side) to use all the Google API quota. An estimated 4 million requests had hit the servers in under an hour.

通过这些措施，在帐户禁令生效之前，攻击者决定使用Google Cloud Platform API密钥(以前在客户端公开)使用所有Google API配额。 不到一个小时，估计有400万个请求到达了服务器。

But this just required a simple fix.

但这仅需要简单的修复。

1. We first prevented the attacker’s attempt to steal the Google API quota by adding app-level restrictions to the API keys. Meaning, only the requests made from the application would get through.
   我们首先通过向API密钥添加应用程序级限制来阻止攻击者企图窃取Google API配额。 意思是，只有来自应用程序的请求才能通过。
2. We added a more permanent fix by moving the Google API calls on the server side, thus hiding the API keys on the server. It is usually a secure practice to hide the key behind an environment variable on the server.
   通过在服务器端移动Google API调用，从而在服务器上隐藏API密钥，我们添加了更永久的修复程序。 将密钥隐藏在服务器上的环境变量后面通常是安全的做法。

如果您想击败黑客，则必须像黑客一样思考！ (If you intend to defeat a hacker, you must think like a hacker!)

If I was the attacker using the EC2 instance to flood the servers with requests, I would want to check for an HTTP request error code to know when the services went down to save up on resources. Rate limiting submits an error code of 429 - Too Many Requests, whereas a successful connection request would return a 200 - OK.

如果我是使用EC2实例向服务器发送请求的服务器的攻击者，我想检查HTTP请求错误代码以了解服务何时关闭以节省资源。 速率限制提交错误代码429-太多请求，而成功的连接请求将返回200-确定。

I was able to configure this on the server side to return 200 - OK instead of the rate limiting “too many requests” error code. This prevented the attacker’s scripts from knowing when they were being rate-limited and constantly used up their resources.

我能够在服务器端将此配置为返回200-OK，而不是限制速率的“太多请求”错误代码。 这阻止了攻击者的脚本知道何时对其进行速率限制并不断消耗其资源。

While monitoring the server logs, we noticed that the requests from the attacker were coming in and getting rejected by the server through rate-limiting.

在监视服务器日志时，我们注意到来自攻击者的请求正在进入并通过速率限制被服务器拒绝。

结论 (Conclusion)

After fighting the attacks for 30 hours, our services were finally impenetrable to a DOS attack from this attacker. They made many attempts before finally giving up. At each step during the attack, a small and simple measure was taken to mitigate the DOS. Together these simple tactics proved to be highly effective.

经过30个小时的攻击，我们的服务终于变得不容易受到该攻击者的DOS攻击。 在最终放弃之前，他们做了很多尝试。 在攻击过程中的每一步，都采取了小型且简单的措施来缓解DOS。 这些简单的策略一起被证明是非常有效的。

At the end of the day, simplicity and perseverance goes a long way and failures are just the stepping stones to success.

归根结底，简单和毅力大有帮助，失败只是成功的垫脚石。

翻译自: https://www.freecodecamp.org/news/how-we-handled-a-denial-of-service-attack-a-simple-security-lesson-8cdd542d4def/

应用层缓慢拒绝服务攻击