请选择 进入手机版 | 继续访问电脑版

3A资讯网

 找回密码
 立即注册
搜索
热搜: 活动 交友 discuz
查看: 94|回复: 0

记第一次抵御黑客攻击

[复制链接]

3020

主题

3020

帖子

9060

积分

网站编辑

Rank: 8Rank: 8

积分
9060
发表于 前天 14:24 | 显示全部楼层 |阅读模式
作者:Alphagu
      10月17日,周六,临近中午正准备去吃饭。突然用户群有人反馈APP全部报502,无法使用。

      心里一惊,又来了!这已经是近几天里的第N次报故障,而这个故障又不是必现,每次都是几分钟之后就自动恢复了,所以不好排查。

      来不及多想,赶紧查了一下SLB,网关日志,发现没有正常请求进来,偶尔会看到一个上传文件的接口报错:

UT005023: Exception handling request to /workorder/file/upload

java.lang.RuntimeException: java.io.IOException: UT000128: Remote peer closed connection before all data could be read

        at io.undertow.servlet.spec.HttpServletRequestImpl.parseFormData(HttpServletRequestImpl.java:834)

开始以为只是故障期间的正常报错,所以没有在意,最后由于SLB日志没有开启,一直无法找到线索,大概7-8分钟后,服务自动恢复正常。无奈,只能先去吃饭。

      吃完午饭后,回去想到那个报错,觉得是唯一的线索,所以就登录日志系统,查了一下报错规律:



然后惊人的发现这个报错跟用户反馈502问题完全吻合!这个接口不是常用接口,正常一天能有100次访问就算多了,但是居然在短时间内就有3588次访问,下意识感觉我们的网站被攻击了!

      进一步分析日志,发现对方居然是每隔70秒就在一秒内发送256次请求过来,如此有规律的请求,更加确定这就是黑客恶意攻击:



      所以赶紧研究了一下这个报错:

IOException: UT000128: Remote peer closed connection before all data could be read

       发现网上说是数据还没有接收完,就被客户端取消了请求。所以赶紧用POSTMAN来模拟攻击我们的系统,但是无论我点多快,都无法重现这个报错。最后想到把Content-Length这个header设置成一个很大的值,一试果然发现请求在POSTMAN上卡住了,然后点击取消,网关层就报了一个同样的错误!

       到这一步,也就明白,对方是利用了Content-Length大于实际文件大小这个漏洞,来把我们的连接全部占用,来达到攻击目的。

  事后查到发现有这样一个文章讲解了这个攻击: https://www.zhihu.com/question/41152999

      原理:因为HTTP 1.1支持TCP长连接,当服务器接收请求时需要获取头中的content-length ,从而确定接下来还需要获取的body长度,使得可以切分同一个连接上的不同请求。如果伪造Content-Length 使其大于实际body长度,会导致服务器一直在等待还未接收到的字节流。

        问题确认之后,马上找到了公司同事一起攻关。一开始手足无措,因为之前没有被黑客攻击过,不清楚如何处理。后面冷静下来后,思路也渐渐清晰,开始分析问题的原因,还有我们的架构设计。

       我们的服务部署在阿里云,架构图如下:

       域名->slb->zuul gateway

       而报错就发生在zuul gateway,但是因为还没进到业务层,所以在代码里想处理也无用武之地。

       所以第一反应就是,需要在slb与zuul gateway之间加一层nginx,并做一些防刷处理。

       然后就进行了一下分工:

1)一部分擅长写脚本的同事,开始写脚本在测试环境模拟攻击我们的系统,以重现问题;

2)一部分同事开始在测试环境部署NGINX转发,并将SLB转向指到NGINX

       最后通过Jemter脚本成功在测试环境模拟攻击成功,出现了502报错。然后就将SLB请求切到NGINX层,再次模拟攻击,发现不会在报502的错;后面再切回到原来的架构,继续模拟复现,如此往复再三确认,添加NGINX层可以解决这个问题,最后在生产环境部署了这一套框架,验证功能正常;

       此时已经是晚上将近11点了,其实到此时我依然不太敢确认真的有人在攻击我们,因为我们的SLB层日志没有开启,没有看到对方的IP,一切都是臆想出来的。

       直到第二天早上8点多,我起来查看日志,发现又有一批攻击进来了。一秒钟内,攻击了300多次:



查了IP地址:



      到这一刻,才真正证实我们的猜想是正确的。而加了NGINX之后,估计是NGINX有对Content-Length进行校验,所以全部攻击都是400返回。

      接下来就是看看是否真的成功防住了,还有对方是否会继续攻击其他漏洞。

     复盘一下整个问题:

    原架构:slb->zuul gateway

    这相当于是把自己暴露在互联网上,没有任何安全防护,对方利用http 1.1的Content-Length这个漏洞进行攻击

    改造后:slb->nginx->zuul gateway  nginx做了保护

    总结:NGINX太牛逼了

               
原文地址:http://mp.weixin.qq.com/s?src=11&timestamp=1603002420&ver=2651&signature=KocObqydvtGR0G0UHIdUU37z1myNaSE7h-X-Xp4tdA5kHIwwzROKx825TMfZLVXobk-CitHBQgS0BS31EOyXwJ2TBhNivEFSFcvVND91DBoYZpwOocGGJZAIti6r3vwj&new=1

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

手机版|小黑屋|三艾云

GMT+8, 2020-10-20 11:10 , Processed in 0.065482 second(s), 19 queries .

Powered by Discuz! X3.4

© 2001-2017 Comsenz Inc.

快速回复 返回顶部 返回列表