内容简介:互联网时代的鏖战,未必看得见烟火,但却同样让人抓狂。本文的作者,以记叙文的方式,亲自诉说了自己是如何在午夜凌晨,花了几个小时攻克掉黑客的DDoS攻击。而这件事中所展露出来的作者的极客精神,值得我们学习。作者 | Sergio Mattei
互联网时代的鏖战,未必看得见烟火,但却同样让人抓狂。本文的作者,以记叙文的方式,亲自诉说了自己是如何在午夜凌晨,花了几个小时攻克掉黑客的DDoS攻击。而这件事中所展露出来的作者的极客精神,值得我们学习。
作者 | Sergio Mattei
译者 | 弯月
责编 | 胡巍巍
出品 | CSDN(ID:CSDNnews)
漆黑的夜色,笼罩着朦朦胧胧的雾气。上了一天的课,又熬夜写代码,此刻漫长的一天终于结束了,我躺在温暖舒适的床上,很快就进入了梦乡。
突然,一阵铃声将我吵醒。我爬到床的另一边,一把抓起了放在写字台上的手机。
原来是有人打电话给我,是Makerlog的人打来的电话。
当我看到来电人的名字时,就知道出事了,而且肯定不是什么好事。
于是,我与分布式拒绝服务攻击展开了长达两个小时的鏖战。
我睡眼惺忪地开始了工作
除了那通电话外,还有很多人通过各种社交媒体尝试联系我,初步看来情况不简单。我想我知道发生了什么事情:一个简单的SPAM攻击(通过发送大量垃圾请求进行的攻击),导致服务器崩溃。
得出这个初步的结论一点也不难。Makerlog的API是非常开放的,人们很容易(有意或无意地)向服务器发送SPAM请求。
我可以立即制止这些攻击(而且也很容易)。无非就是进入管理面板,停用一些Token,并禁掉IP。前一天就发生过一次这样的攻击,不是什么大问题。
我蜷缩在被窝里,一边在心里盘算:进入管理面板,挥动几下正义之锤,然后就回去睡觉。
没想到,意外发生了。
噩耗
没想到,我根本打不开管理面板。甚至连/health都打不开。这就很奇怪了,因为Gunicorn + Uvicorn是一个超级稳定的组合,连以前的SPAM攻击都未能攻克这个网站。
由于我无法访问后台的API面板,所以我一边打电话,一边头脑逐渐清醒过来。
我问社区在这个网站发生故障之前,是否有过任何SPAM的任务。但是,令我惊讶的是,他们说没有。没有人发送垃圾邮件。
这次的情况就不妙了。
我掀开被子,打开了灯(我可怜的小鱼也被我吵醒了)。
尝试重启:
我还没有意识到问题的严重性,我想着也许是服务器挂掉了,也许是内存泄漏。
这时,我已经完全清醒了。我坐在床边,在手机上打开了JuiceSSH,想弄清楚状况。
Makerlog运行在Dokku之上,所以我的第一反应是重启受影响的应用容器。Dokku对 Docker 的抽象可以非常巧妙地管理基础设施,因此重启很容易(请忽略下图中的错误,当时我睡着了!)
过了一会儿,容器重启完成。我终于能够访问管理面板了,这次的攻击也可以得到解决了。
等等……
重启没管用,问题仍在继续。我重启了整个服务器,还是没用。
我打开了错误日志,尝试查找容器内是否有任何问题。但日志只是在不断地显示async/await协程的错误,所以我认为这就是问题所在。
我尝试重启了几次容器,看看能否干掉我想象中的进程死锁,但无济于事。
我终于意识到问题的严重性了。
反复观察错误后,我发现了希望:
我跳下床,打开笔记本电脑,打开了SSH,试图找出问题所在。
我盯着服务器日志来回查看,却毫无头绪。
在反复观察了这些错误后,我认为这是服务器的错误。Makerlog运行在使用了ASGI的Uvicorn之上,因此很容易出现与async / await相关的错误。这个错误涉及协同程序,所以我开始朝着这个方向展开了调查。
首先,我查看了网站上的异步代码,想看看能否找到错误。我剖析了WebSockets和数据库的查询代码,但依然一无所获。
然后,突然之间……我想起我完全忽略了一种可能性。
是不是有人在做DDoS攻击?
这也不是什么新鲜事。以前我就处理过一些SPAM攻击某个API。虽然Makerlog大约有2.3万名成员,但仍然算是相对较小且低调的服务。我不会招惹太多麻烦。
这就是一次DDoS攻击:
我错了。在看了Nginx日志后,情况就很明朗了。有人正在攻击我们的站点并在反复访问 / products/ 这个API。
这个漏洞很简单:由于一些历史原因,Makerlog的/products/ API端点从未真正支持过分页。
自网站上线以来,我从未想过Makerlog会发展到现在的规模,所以我从来也没有真正考虑过分页。
因此,请求该API端点会引发一个巨大的 SQL 请求,在获取数据并序列化成JSON数据时导致服务器停止响应(Django REST框架的性能弱点之一)。
这种攻击很完美,他们可以通过这种方法,让CPU的使用率达到极限,并导致整个服务器崩溃(该服务器还托管了其他正在开发中的应用)。
以前我一味地添加新功能和炫酷的东西,却没有修复服务的基本功能。一切看似无恙……直到有一天它们反咬你一口。
今天,我就反受其害了。
解决方法之一:禁用
当有人得知自己的生产服务器遭到了DDoS攻击时,都会陷入恐慌。但是我没有慌,我决定用强大的禁用,轻轻挥一挥手指,就可以打败这些攻击者。
于是,我通过Reliable禁掉了违规的IP地址。
结果:不管用
等等……不管用。即使反复检查了UFW之后,我仍然能看到我禁掉的几个IP发来的请求。攻击仍在继续。噩梦并没有结束。
解决方法之二:推送补丁
经过一番思考,我认为目前最好的解决方案是阻止漏洞。通过一个包含分页的新API,我可以从根本上防止这个API消耗大量的CPU,并缓和攻击,但代价是一些使用API的应用会遭到破坏,而且网站上的产品页面将无法正常工作。
我知道这是一个非常简单的改动,所以,我很快在Makerlog的/products/ API上打上了补丁,并推送到Dokku,然后耐心地等待部署完成。结果:奏效了!
这个小小的改动之后,服务器的负载明显减少了,站点暂时恢复了。
然而,这场胜利只是短暂的。
解决方法之三:转移到CloudFlare
同时,在得到了社区的一些建议之后,我决定转移到CloudFlare上。转移的过程很快,如果我将API设置为“受攻击”模式,CloudFlare就会对可疑的地址进行严格的核实。
结果:奏效了!
CloudFlare的效果很难凭经验判断,但根据我对攻击后的分析,我可以说CloudFlare对于缓解攻击有很大的帮助,并减轻了服务器上的负载。我大力支持CloudFlare(免费的套餐就很好)!
问题得到了解决!我们安全了!对吗?
现在问题得到了解决!我们安全了!对吗?
并没有。不一会儿,我发现Nginx日志出现了奇怪的情况……攻击者们紧张起来了,他们开始抓取所有API,他们在寻找可利用的API......
很快,他们就找到了一个。Discussion的API也有同样的问题,因此改正这个API很容易(因为我现在知道原因了)。于是,我推送了一个补丁,攻击基本上就停止了。
攻击终于停止了,我长长地呼出了一口气。
整个攻击持续了大约2个小时,从凌晨3点到凌晨5点。
出现这种状况的原因
整个问题都是由于我的经验不足造成的。
Makerlog从一开始就非常开放。API一直处于欢迎所有人的状态,因为我们希望开发人员在此基础上构建新功能,但这是一把双刃剑:一方面,我们建立了一个充满激情的开发人员社区,为Makerlog构建了优秀的工具;另一方面,这种做法滋生了今晚这样的攻击。
由于开放性,Makerlog在很大程度上依赖于对用户的信任和严格的审核。我完全信任我的用户。这不是第一次有人故意利用API发起攻击,却是第一次造成严重持久的伤害。
信任因素不是唯一的原因。我迟迟没有修复分页的问题,因为我优先考虑了改善现状的方向和愿景。
我错了。
随着网站的发展,有一些不法分子也混了进来,所以现在必须采取另外一种方法了。
得到的教训
如今,我打算采用新的方法。今天,我采取了一些措施来防止将来再发生这类的攻击。
我会做的事情:
-
改Bug的优先度高于新功能。
-
实现新的限制和访问控制功能,以防止这些攻击。
-
采取新的API安全措施,从信任优先模型转变为预防措施。
我不会做的事情:
-
过度封锁API——我们的开发社区非常有价值!
-
轻易放过这些攻击。
-
让不法分子得逞!
下面,让我们来详细谈谈。
优先改Bug:
最近Makerlog发生了很多变化。我最近推出了Wellness更新,而且我们确实做了大量工作。
然而,我采取了一个让我很后悔的做法:我优先考虑了新功能,而忽略了改Bug,这导致了此次攻击的发生。我知道分页是一个问题,但是我从来没有打这个补丁,因为我觉得这不算大问题。
现在我要重申一件重要的大事:我保证今后一定及时修复明显的Bug和漏洞。我非常重视用户的信任和安全,我绝不允许发生任何可怕的事情。
Makerlog上从来没出现过任何严重的漏洞——大多数都是访问控制的问题(比如编辑其他人的任务等等)。而且这样的问题我用一只手就能数得过来。
你的数据在我这里是安全的。我重视你的信任和隐私,这一点不需要任何怀疑。
我为这个工作优先级的问题道歉,我保证以后不会再发生这样的事情。
实现访问控制的功能:
随着用户群和覆盖面的增长,不法分子与好人的比例也在增长。
如上所述,Makerlog一直采用关于API访问的信任优先模型。这种过度的用户信任会导致滥用,今后我会转向采用“预防措施优先”的方法。
Makerlog的开发社区非常优秀。新的Makerlog集成不断涌现,这是我最喜闻乐见的事情。
但是,在经历了这次事件之后,我将实施更严格的控制。我不会完全锁定API,但是会采取限制措施和其他预防措施来防止未来再发生这样的攻击。
感谢
在这里,对James Ivings和Mubaris NK等朋友表示衷心的感谢,感谢他们帮助我应对了这次攻击,并找到了根本原因。此外,还要感谢社区,感谢你们在艰难时期也能提供支持。
总结
昨晚,我在网上遭遇了不法分子。
我很荣幸地说,作为一个社区,我们已经征服了。
这是一次值得借鉴的教训。我会从这次事件中吸取教训,并转化为积极学习的动力——因为这才是我们和公司发展的途径。
原文:https://sergiomattei.com/posts/handling-the-jerks/
作者:Sergio Mattei
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:- 美女黑客疯狂披露 Windows 0day,微软忙修复!
- 黑客披露了未修复的Windows 0-day漏洞
- Adobe已修复漏洞疑遭印尼黑客组织AnoaGhost滥用
- 亚马逊修复智能家居13个漏洞:防止黑客完全控制设备
- 研究称黑客可通过漏洞劫持裸金属服务器 IBM将修复
- BUF早餐铺 | 泄露德国政客信息的黑客被捕;微软一月修复日修复50多个漏洞;美国四大主要运营商仍在...
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。