这是一个创建于 196 天前的主题，其中的信息可能已经有所发展或是发生改变。
好久之前面试被问到，同一时间段有大量恶意请求打到系统，可以做什么措施，这些 ip 都是不固定的，系统负载有限，影响到正常请求了。
这个应该从什么方面回答？ 我只能想到事前做好限流降级，但是这个也没办法保证正常的使用吧？ 还有 ip 黑名单感觉也没办法用上。 验证码这个倒是可以使用。
麻烦各位巨佬指导下
25 条回复 • 2024-04-28 16:06:49 +08:00
 |
1
gongxuanzhang 196 天前
ddos?除了钞能力有解吗
|
 |
2
muzi996 196 天前
云服务有自带的 doss 防火墙，本地的话好像只有加机器了
|
 |
3
huali70531 196 天前
如果要保证服务不中断：
硬件上花钱购买 WAF 防火墙 加验证码，检测来源请求头，IP 地址判断是否是常用客户 IP 地区拦截请求。增加 IP 计数，对于高频 IP 地址，拉黑整个 IP 网段。 临时提升服务器硬件和带宽 如果可以保证服务中断： 关服务器。 如果说不想花钱还想保证服务不中断，当对面是吃素长大的吗？ |
 |
4
dapang1221 196 天前
什么请求，TCP 还是 UDP 还是 ICMP ，TCP 的话是规则的 http 报文还是恶意 payload ，什么叫打到系统，打到什么系统，请求的 API 接口还是渲染的网页还是静态资源。不同级别有不同级别的应对方式
|
|
5
dapang1221 196 天前  7
UDP 的 ddos：上硬件防火墙，从机房清洗，或者上高防做转发
http 报文：接口限速熔断、增加校验、加签名、时间戳、登录校验，防止重放 恶意 payload/cc：上 waf ，软硬都行 网页：做静态化 静态资源：cdn 分流 能想到的基本都在这了 |
 |
6
waytodelay OP @huali70531 他说 ip 都是不固定的，没有什么明显特征
|
|
7
waytodelay OP |
 |
8
jsjejejdjdjhh 196 天前 via iPhone 1
我来回答你，这个不是 ddos ，属于 cc 攻击，用脚本发起的攻击，用虚拟 ip 模仿真实用户访问，然后目的就是消耗服务器资源，cpu 和带宽，这种还是上防护解决比较好，你单纯设置策略防不住的，现在 cc 攻击模仿的和真人没什么区别了，策略做不好还会把真实用户误封了。
|
|
9
jsjejejdjdjhh 196 天前 via iPhone
防护可以考虑上 cf ，但是国内电商的话可能延迟会有点问题，但是大厂不推荐。
|
 |
10
cdlnls 196 天前 via Android 1
这里应该指的是 cc 攻击，如果是 ddos 的话，可能直接被黑洞了。
解决方法估计只能加钱，上 waf 上高防 加机器硬抗。不加钱的方案，配置个频率控制来限流，可能能用但是作用也有限。 加验证码应该不太行，别人其他的不刷，就刷你获取验证码的接口，这样压力可能也不小。 要想降低影响，可以看情况把服务分开部署，被攻击的时候不至于影响到其他业务。 |
 |
11
lcy630409 196 天前
加验证码 用第三方的 比如极验 阿里云之类的 ，把压力转移
 |
 |
12
Lixiaobai233 196 天前
顶个验证码，加个 waf ，大厂有很多现成的方案，加钱就是了。
当然，关机也不是不行。 |
 |
13
cus 196 天前
开摆
|
 |
14
zdking08135 196 天前 2
分两种情况，一种是对着 IP 瞎鸡儿发包，一种是尝试构造异常请求。
如果是瞎鸡儿发包这种，设计的比较完善的交互协议，本身就有做强校验的。一般是在分两种情况。 如果是自有的二进制协议，适用于 app 请求场景，这种本身伪造的难度就很高。 一般是发到网络的请求包就带加密了，伪造协议无法正常交换密钥，在接入层解密的时候就会失败。 如果是公开协议，比如 http ，这一类很容易通过脚本构造请求包， 这类解决方式一般是在前端代码中混淆嵌入密钥和算法，然后给请求生成签名。 计算签名时，携带时间戳和随机数，然后接入层校验的时候就能拦截掉。 这类校验逻辑无上下文状态，节点很容易 scaling 。 实际业务中，除非是对内部实现有了解的人，否则很难通过非端环境构造合法报文。 大的系统都有专门的接入层，只负责协议加解密转发之类的，节点数远多于业务节点数，请求进接入层之前还要走 LB 。真正打垮接入层很难，成本极高。 如果是异常请求，但是通过了校验，比如别人拿了客户端代码改了直接发包。 这种就只能上验证码之类的了。 |
 |
15
epiphyllum 196 天前 1
不知道这段文字有什么问题，看图片吧（希望它能正常显示
 |
 |
16
fatigue 196 天前
@waytodelay 电商系统下单需要账号吧，他账号够多就随他下呗，现在账号都绑定手机号啥的
|
 |
17
inktiger 196 天前
两种方式，
1 、第一种网络无授权的 url 请求，使用钞能力，上防御，加机器。 2 、下单的大量请求，肯定要依托账号，对账号做限制，下单使用图形验证码。控制虚拟手机号的购买。 |
 |
18
codegenerator 196 天前 1
这个问题太笼统了，可以分很多种情况
当然也有可能面试官希望你能主动跟他交流 |
 |
19
xuanbg 195 天前
能区分就上流量清洗，无法区分就上机器硬扛
|
 |
20
leaflxh 195 天前
加验证码（手势/物体识别/数字字母）
会损失一部分用户体验 可以考虑先对高风险 IP 进行限制，比如国外 IP ，访问频率过高的 IP |
 |
22
wanguorui123 195 天前
Cloudflare 验证码
|
 |
23
mengzhuo 195 天前 1
不知道面啥，架构的话应该是，韧性和高可用啊
按层解，IP/TCP/HTTP ，防火墙什么的前面楼层说了很多了 按系统解，横向，降级，标记限流，分流 按业务解，根据业务、用户、服务重要性优先级提供服务 |
|
24
huali70531 194 天前
@waytodelay 加钱！！！
|
|
25
waytodelay OP @fatigue 只是打个比方，他也没说是什么系统。而且感觉他问的有点太笼统了
|
Select Language