如何处理攻击 IP 是比较高效节省资源的

2023-06-26 16:01:05 +08:00
 brader
前置:不讨论云防火墙、高防服务器这些话题,我知道有这个东西,单纯想了解技术而已。

假设 HTTP 接口有个自动拉黑超频 IP 机制,判断该 IP 在 IP 黑名单的话,接口就立马返回访问异常,虽然这样不需要继续往下走业务代码流程,立马结束了该次请求,但在实际环境应用中,我发现当攻击访问非常大量的时候,服务器的 CPU 占用其实挺高的。

这时候我就在思考一个问题,其实立马结束一个攻击请求,应该不是一个最高效节省资源的做法?我是否应该保持住这个连接?一直到它超时为止。理由是这样的:假设超时时间是 60 秒,如果我立马响应并结束请求,那这个 IP 在 60 秒内可能可以对我发起几千几万个请求,这是很可怕的,每个请求的进程创建、初始化代码、销毁等等都要消耗 CPU 资源,但是我保持住不响应它,每次可以拖着它 60 秒。

我会有这个想法的灵感是来自于云服务器防火墙,因为我发现我把自己 IP 在云防火墙拉黑后,我访问的表现特征就是等待几十秒后超时,而不是立马响应我拒绝我。

不知道我的设想有没有错误,我设想的这个做法,是否真的会比较节省服务器资源呢,欢迎懂的大佬指点一下。
3227 次点击
所在节点    程序员
50 条回复
brader
2023-06-26 17:01:06 +08:00
@ppking 但是我们普通业务开发,没有能力在很前面的地方做到自动拦截呀,如果做得到,那不是和别人做高防服务器的抢饭碗了,最终还是要买高防吧,哈哈
makelove
2023-06-26 17:02:28 +08:00
本机直接关掉这个连接,但不发任何结束信号给对方让对方自己超时,这个在 app 这边做不到吧
4kingRAS
2023-06-26 17:02:57 +08:00
你不断开连接的话,一个 ip 可以挂 65536 个连接啊,难道都等着超时吗
brader
2023-06-26 17:03:57 +08:00
@areless 不会呀,能不能排查到,主要还是看日志记录是否全面,日志检索系统是否强大,像我们之前接入的阿里云的 SLS 日志服务,就很强大,从各种维度(请求频率、请求时间、关键词、次数等等)都能检索,很容易找到的
codehz
2023-06-26 17:04:20 +08:00
@brader 云服务器防火墙那种感觉是黑洞了,可能在更底层处理的,比如直接丢弃了相关的包,表现出来就是没响应直到超时
kera0a
2023-06-26 17:04:37 +08:00
@brader 你简单点直接 iptables drop 网络层封 ip 吧,至少比你现在这样做好
c2const
2023-06-26 17:05:03 +08:00
"假设 HTTP 接口有个自动拉黑超频 IP 机制,判断该 IP 在 IP 黑名单的话,接口就立马返回访问异常,虽然这样不需要继续往下走业务代码流程,立马结束了该次请求,但在实际环境应用中,我发现当攻击访问非常大量的时候,服务器的 CPU 占用其实挺高的。"

“这时候我就在思考一个问题,其实立马结束一个攻击请求,应该不是一个最高效节省资源的做法?我是否应该保持住这个连接?一直到它超时为止”
---------------------------
不靠谱,真防御还是得永封,最终还是得在 web 服务之外就拦截,比如系统的防火墙、三方杀软的防火墙。
brader
2023-06-26 17:06:41 +08:00
@kera0a
@codehz 奥,那有点明白了,就是云防火墙默默丢弃包了也不通知客户端一声,然后客户端还在傻傻的等待,是吧
brader
2023-06-26 17:07:33 +08:00
@kera0a 兄弟,这个比 nginx 封 IP 如何,效率差别大不
opengps
2023-06-26 17:07:53 +08:00
@brader 没参与过服务器机房搭建的开发人缘或者安全防御工作的开发人员,是不会懂网络工程那套东西的。

普通开发甚至很多人连端口防御意识都没有,一上来第一件事就是关闭防火墙
brader
2023-06-26 17:08:57 +08:00
@c2const 是的,说起来是这样,只是有时候自己要实行自动化拉黑的话,好像 WEB 服务之外没有那么好实现,没有写代码那么自由
brader
2023-06-26 17:10:43 +08:00
@opengps 这个我深有体会,我身边挺多朋友,访问不了,然后就把 iptable 关了,哈哈。还好现在服务器都带厂商的云防火墙,网页操作一个个加端口,大部分人还是会遵守的
opengps
2023-06-26 17:12:29 +08:00
@4kingRAS 你这个 65535 的结论是搞反了服务端和客户端。
一个 windows 系统能对外发起的最大数量是 65535 时候是客户端用法。但你想想,作为服务端时候你是不是一个 80 或者 443 就扛起了全部的 web 业务?

其实单机承载连接数几百万裸连接完全不是问题,只是考虑到承载速度,考虑到其他逻辑处理,资源才不够用了考虑集群。
Kinnice
2023-06-26 17:17:37 +08:00
看你的场景已经上云了,就直接把攻击 IP 加到安全组的黑名单,调用相关的 api 即可
brader
2023-06-26 17:24:11 +08:00
@Kinnice 阿里云的安全组黑名单,有 API 接口可以直接调用添加吗
Kinnice
2023-06-26 17:27:59 +08:00
@brader #35 当然啦,你在云厂商页面上看到的操作百分之 99 都是有 api 的 https://help.aliyun.com/document_detail/25554.html?spm=a2c4g.25560.0.0.5a72123fzDeiAM
lysS
2023-06-26 17:37:13 +08:00
对大部分有效的,其实不需要保持连接,不需要占用句柄资源,直接不回复 tcp RST\SYN\FIN ,就行,在网络层做。但是要是 syn 攻击之类的就没办法了
brader
2023-06-26 17:43:27 +08:00
@Kinnice 嗯,还挺方便,我直接一直是导出一堆 IP ,在界面上添加
brader
2023-06-26 17:44:03 +08:00
@lysS 奥,在网络层做我就写不动了,只是个普通的业务开发而已
4kingRAS
2023-06-26 17:45:48 +08:00
@opengps 我搞反啥?我又没说服务端限制 65535 ,我说的是不封 ip ,那么 1 个 ip 就耗掉你 6 万个连接,你又在乎什么线程创建销毁,那 6 万个连接不就占着你的线程池队列?

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/951809

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX