这是一个创建于 503 天前的主题，其中的信息可能已经有所发展或是发生改变。
前置：不讨论云防火墙、高防服务器这些话题，我知道有这个东西，单纯想了解技术而已。
假设 HTTP 接口有个自动拉黑超频 IP 机制，判断该 IP 在 IP 黑名单的话，接口就立马返回访问异常，虽然这样不需要继续往下走业务代码流程，立马结束了该次请求，但在实际环境应用中，我发现当攻击访问非常大量的时候，服务器的 CPU 占用其实挺高的。
这时候我就在思考一个问题，其实立马结束一个攻击请求，应该不是一个最高效节省资源的做法？我是否应该保持住这个连接？一直到它超时为止。理由是这样的：假设超时时间是 60 秒，如果我立马响应并结束请求，那这个 IP 在 60 秒内可能可以对我发起几千几万个请求，这是很可怕的，每个请求的进程创建、初始化代码、销毁等等都要消耗 CPU 资源，但是我保持住不响应它，每次可以拖着它 60 秒。
我会有这个想法的灵感是来自于云服务器防火墙，因为我发现我把自己 IP 在云防火墙拉黑后，我访问的表现特征就是等待几十秒后超时，而不是立马响应我拒绝我。
不知道我的设想有没有错误，我设想的这个做法，是否真的会比较节省服务器资源呢，欢迎懂的大佬指点一下。
假设 HTTP 接口有个自动拉黑超频 IP 机制，判断该 IP 在 IP 黑名单的话，接口就立马返回访问异常，虽然这样不需要继续往下走业务代码流程，立马结束了该次请求，但在实际环境应用中，我发现当攻击访问非常大量的时候，服务器的 CPU 占用其实挺高的。
这时候我就在思考一个问题，其实立马结束一个攻击请求，应该不是一个最高效节省资源的做法？我是否应该保持住这个连接？一直到它超时为止。理由是这样的：假设超时时间是 60 秒，如果我立马响应并结束请求，那这个 IP 在 60 秒内可能可以对我发起几千几万个请求，这是很可怕的，每个请求的进程创建、初始化代码、销毁等等都要消耗 CPU 资源，但是我保持住不响应它，每次可以拖着它 60 秒。
我会有这个想法的灵感是来自于云服务器防火墙，因为我发现我把自己 IP 在云防火墙拉黑后，我访问的表现特征就是等待几十秒后超时，而不是立马响应我拒绝我。
不知道我的设想有没有错误，我设想的这个做法，是否真的会比较节省服务器资源呢，欢迎懂的大佬指点一下。
 |
1
codehz 2023-06-26 16:09:14 +08:00
对付普通 dos 工具还是有效果的（也不排除直接 bypass ip 栈绕过 tcp 状态机处理），ddos 就没啥用了
|
 |
2
brader OP @codehz ddos 的话不考虑，其实 ddos 的肉鸡，也等同于正常用户了，我的应对就是扩容服务器加大承受能力。但是尽量避免出现比如一个 IP 客户端，却短时间发起 N 多请求消耗掉很多资源。 一个肉鸡 IP 像正常用户的频率程度访问接口服务，我能接受
|
 |
3
opengps 2023-06-26 16:11:34 +08:00
60 秒不一定是客户端试试服务端的设置，对方如果在客户端设置了 1 秒超时，那你这个就失效了
|
|
4
brader OP @opengps 那么客户端这个设置来攻击的话，又可以等同回到原来的攻击效果？对客户端的资源消耗、或者其他方面不会有比较大的局限吗
|
 |
5
520discuz 2023-06-26 16:29:21 +08:00
宝塔防火墙 N 秒内访问 N 次 自动拉黑
|
 |
6
areless 2023-06-26 16:37:55 +08:00
我这边的方法通常是所提供的服务 分页缺失 pagesize 可以无限大 等漏洞，造成返回巨大 慢的 请求。 只要以普通用户的频率攻击，就能拖垮你的服务
|
|
7
opengps 2023-06-26 16:41:53 +08:00
@brader 客户端是肉鸡，假设是这批发动攻击的肉鸡是 100 万台设备 PC ，每个只发起一条连接，那么对其客户端的资源消耗是无感知的，但对拟于服务端来说，你需要自己扛起处理百万连接的负载，所以才是“拒绝服务攻击”
|
 |
8
dqzcwxb 2023-06-26 16:45:30 +08:00
攻击者压根不会接收或者等待你的响应只是无限请求,所以你在响应上做任何动作都无意义
|
|
10
opengps 2023-06-26 16:47:08 +08:00
给你分享个案例，加深下理解：
我之前做的 gps 服务端，正常来讲就是服务器承载外边进来的上百万 tcp 连接，正常来说每个连接就是一台 gps 终端。 然而我需担心的场景是：我服务器集群全挂了，这时候我手动启动了 1 台，结果是这台必然很快就扛不住巨大的连接数挂掉。 这里最起码应该改成：在我完成整个后端几十台服务器的启动之后，再从防火墙一股脑的把连接放进来。 当然实际上的业务场景还有很多值得优化的地方，不到了具体问题面前甚至都讲不出来这些过程。 |
|
11
brader OP @opengps 额，我意思大概是这样，你有 100 万台肉鸡没问题，我就当 100 万正常用户，我要做的事情是，防止你单个设备高频发起的攻击，防止你 10 万台肉鸡，却发挥出 100 万台肉鸡的效果
|
 |
12
Aloento 2023-06-26 16:49:07 +08:00
一般都是直接丢弃请求的，不会返回
|
 |
13
finab 2023-06-26 16:49:36 +08:00
最好 TCP 那层就给拒绝掉，就算他疯狂的请求至少都比到应用层去处理强吧
|
|
14
opengps 2023-06-26 16:50:09 +08:00
@brader 10 万台肉鸡，却发挥出 100 万台肉鸡的效果，也不过才每个肉鸡发起 10 个连接。
要知道你的根本在于，不能给对方回复，因为一旦接起连接，从接起开始就已经消耗了服务器端资源，连接的建立本身，可能已经比你发送的几个字节消耗资源更大了 |
|
15
brader OP @dqzcwxb 客户端确实可以不接收和等待响应，直接起 N 多进程或者直接切断，但是我感觉应该不是完全无意义的，如果完全无意义，为什么云防火墙都是做成那种保持住连接一直到响应超时呢
|
 |
16
ppking 2023-06-26 16:56:26 +08:00
攻击者的资源相比于服务提供者来讲肯定是更充裕的，要不然也没办法对你进行 dos 攻击。这就是一场资源的比拼，你要是能用更少的资源处理掉这些攻击，那你就建立了防御的优势。
我想表达的意思是，你都打算封 ip 了，那么丢数据包的行为越往前，肯定处理成本越小。在报文进入内核协议栈之前就把拉黑 ip 的报文丢掉不更爽嘛。 |
|
17
areless 2023-06-26 16:56:47 +08:00
@brader 在瘫痪的正式环境下，通过日志很难排查这种低频率 dos 。而高频率 ddos 很容易被发现，也很容易被追究法律责任。几分钟一次的 dos ，基本很容易从法律层面圆过去
|
|
18
brader OP |
 |
19
kera0a 2023-06-26 16:58:54 +08:00 via iPhone
@brader 你这个超时可能是你本地客户端自己设置的超时，人家防火墙早把你的包给扔了，不会好心的给你返回一个让你超时的数据包的，那也就不叫超时了。
|
 |
20
xuanbg 2023-06-26 16:59:58 +08:00
你这不是凑上去让人家的攻击具备 DDOS 的效果吗？
|
|
21
brader OP @ppking 但是我们普通业务开发，没有能力在很前面的地方做到自动拦截呀，如果做得到，那不是和别人做高防服务器的抢饭碗了，最终还是要买高防吧，哈哈
|
 |
22
makelove 2023-06-26 17:02:28 +08:00
本机直接关掉这个连接，但不发任何结束信号给对方让对方自己超时，这个在 app 这边做不到吧
|
 |
23
4kingRAS 2023-06-26 17:02:57 +08:00
你不断开连接的话，一个 ip 可以挂 65536 个连接啊，难道都等着超时吗
|
|
24
brader OP @areless 不会呀，能不能排查到，主要还是看日志记录是否全面，日志检索系统是否强大，像我们之前接入的阿里云的 SLS 日志服务，就很强大，从各种维度（请求频率、请求时间、关键词、次数等等）都能检索，很容易找到的
|
 |
27
c2const 2023-06-26 17:05:03 +08:00
"假设 HTTP 接口有个自动拉黑超频 IP 机制，判断该 IP 在 IP 黑名单的话，接口就立马返回访问异常，虽然这样不需要继续往下走业务代码流程，立马结束了该次请求，但在实际环境应用中，我发现当攻击访问非常大量的时候，服务器的 CPU 占用其实挺高的。"
“这时候我就在思考一个问题，其实立马结束一个攻击请求，应该不是一个最高效节省资源的做法？我是否应该保持住这个连接？一直到它超时为止” --------------------------- 不靠谱，真防御还是得永封，最终还是得在 web 服务之外就拦截，比如系统的防火墙、三方杀软的防火墙。 |
|
28
brader OP |
|
30
opengps 2023-06-26 17:07:53 +08:00
|
|
31
brader OP @c2const 是的，说起来是这样，只是有时候自己要实行自动化拉黑的话，好像 WEB 服务之外没有那么好实现，没有写代码那么自由
|
|
32
brader OP @opengps 这个我深有体会，我身边挺多朋友，访问不了，然后就把 iptable 关了，哈哈。还好现在服务器都带厂商的云防火墙，网页操作一个个加端口，大部分人还是会遵守的
|
|
33
opengps 2023-06-26 17:12:29 +08:00
@4kingRAS 你这个 65535 的结论是搞反了服务端和客户端。
一个 windows 系统能对外发起的最大数量是 65535 时候是客户端用法。但你想想，作为服务端时候你是不是一个 80 或者 443 就扛起了全部的 web 业务？ 其实单机承载连接数几百万裸连接完全不是问题，只是考虑到承载速度，考虑到其他逻辑处理，资源才不够用了考虑集群。 |
 |
34
Kinnice 2023-06-26 17:17:37 +08:00
看你的场景已经上云了，就直接把攻击 IP 加到安全组的黑名单，调用相关的 api 即可
|
|
36
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
|
 |
37
lysS 2023-06-26 17:37:13 +08:00
对大部分有效的，其实不需要保持连接，不需要占用句柄资源，直接不回复 tcp RST\SYN\FIN ，就行，在网络层做。但是要是 syn 攻击之类的就没办法了
|
|
40
4kingRAS 2023-06-26 17:45:48 +08:00
@opengps 我搞反啥？我又没说服务端限制 65535 ，我说的是不封 ip ，那么 1 个 ip 就耗掉你 6 万个连接，你又在乎什么线程创建销毁，那 6 万个连接不就占着你的线程池队列？
|
 |
41
fangpeishi 2023-06-26 17:47:15 +08:00
想起有个 ssh 蜜罐，也是类似思路，缓慢响应，拖死扫描者。
|
 |
43
Jirajine 2023-06-26 17:54:09 +08:00
你搞错了，不是云防火墙给你等待几十秒超时，而是你的客户端发出的握手包一直没有相应等待几十秒超时。
服务器端早就把你的包丢掉了。 |
 |
44
lisxour 2023-06-26 18:06:20 +08:00
不在服务层拉黑，在上层的防火墙直接 ban 了
|
 |
46
hyq 2023-06-26 19:35:14 +08:00
如果是找漏洞的网络攻击，直接用 iptables drop 掉，就能达到让客户端超时的目的。
如果是 ddos ，用这种办法就没用了，来源 IP 多，网络流量大，甚至大部分情况都是机房主动断了你的网络，避免影响到机房的其他客户。 这种情况下，要么上高防，要么从架构上适应攻击，快速将入口切换，达到打不死的目的 |
 |
47
datocp 2023-06-26 19:50:56 +08:00 via Android
刚查了 iptables recent 模块有频率控制，平时不怎么用。倒是 recent hacker 设置扫描陷阱，直接配合 ipset drop srcip 用的多。
ddos 属于拒绝服务攻击，曾经在这里发科学就被人打了。那次之后再也无缘 ddos 。 |
 |
48
wowpaladin 2023-06-27 12:25:40 +08:00
还是 syn cookie 吧，你这边至少不要维护状态（消耗资源）；对方是否维护状态，那也不是你能控制的。
|
|
49
ppking 2023-06-27 17:00:00 +08:00
用现成的工具就行了，iptables 或者你前面没有反向代理嘛，nginx 应该有 ACL 能力的。而且现在开发这种 ACL 成本很低的，ebpf+xdp 了解一下，性能又好，开发成本又低。
|
 |
50
yagamil 2023-06-28 08:58:14 +08:00
单台机子攻击你，难道还会一次一个请求吗？多线程一次上万次请求过来，反而是你的服务端维持了一万个请求 60s 不释放，如果对方机子再多一些，能否扛得住？
|
Select Language