蓝易云CDN:AI被攻击怎么办?

AI服务被攻击怎么办?实战应急与长效防护指南 🛡️

AI服务已经成为攻击者眼中的"高价值目标"。原因很简单——每一次请求都会消耗GPU算力和带宽资源,攻击成本低但破坏效果极大。一旦你的AI业务遭遇攻击,必须在最短时间内完成识别、止损和修复。下面按照时间线,从"正在被打"到"长期防住"逐步拆解。

一、紧急止血:确认攻击并快速响应 🚨

发现服务异常时,第一步不是盲目操作,而是快速判断攻击类型。登录服务器,先看连接状态:

netstat -ant | awk '{print $6}' | sort | uniq -c | sort -rn

这条命令统计当前所有TCP连接的状态分布。如果 SYN_RECV 数量达到数千甚至上万,说明正在遭受SYN Flood攻击;如果 ESTABLISHED 连接数异常暴涨,多半是CC攻击(应用层洪水)在消耗你的服务资源。

接着检查哪些IP在发起大量连接:

netstat -ant | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20

这条命令提取所有远端连接IP,按出现次数倒序排列,输出前20个最活跃的IP地址。如果某几个IP的连接数远高于正常用户(比如单IP几百上千个连接),基本可以确认是攻击源。

确认后立即用iptables临时封禁:

iptables -I INPUT -s 恶意IP地址 -j DROP

-I INPUT 在入站规则链最前面插入一条规则,-s 指定来源IP,-j DROP 表示直接丢弃该IP的所有数据包,连拒绝响应都不返回,彻底切断攻击流量。

二、核心动作:切换高防线路隐藏源站 🌐

手动封IP只能应付小规模攻击。面对真正的大流量DDoS,必须把流量牵引到高防节点进行清洗。操作步骤很明确:

第一步,确认源站IP是否已经暴露。 如果攻击者已经拿到了你的真实服务器IP,单纯接入CDN是不够的,因为攻击者可以绕过CDN直接打源站。这时需要更换源站IP。

第二步,接入高防CDN后,在源站防火墙设置白名单。 只允许CDN回源节点IP访问,拒绝其他一切直接连接:

# 先清空旧规则
iptables -F

# 只允许CDN回源IP段访问80和443端口
iptables -A INPUT -s CDN节点IP段 -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -s CDN节点IP段 -p tcp --dport 80 -j ACCEPT

# 拒绝其他所有对Web端口的访问
iptables -A INPUT -p tcp --dport 443 -j DROP
iptables -A INPUT -p tcp --dport 80 -j DROP

逐行解释: iptables -F 清除所有现有规则,避免冲突。随后两条 ACCEPT 规则放行CDN节点的回源请求。最后两条 DROP 规则将其他来源的Web请求全部丢弃。这样即使攻击者知道源站IP,也无法直接建立连接。

三、应用层加固:拦截伪装成正常请求的攻击 🔍

AI服务最头疼的其实不是暴力流量,而是"看起来像正常用户"的CC攻击。攻击者模拟真实请求反复调用你的AI接口,每次请求都会触发模型推理,迅速把后端算力耗干。

在Nginx层面建立多维度拦截:

# 按IP限制请求速率
limit_req_zone $binary_remote_addr zone=ai_api:30m rate=3r/s;

# 按IP限制并发连接
limit_conn_zone $binary_remote_addr zone=ai_conn:20m;

location /api/ {
    limit_req zone=ai_api burst=5 nodelay;
    limit_conn ai_conn 10;
    
    # 屏蔽无UA或异常UA的请求
    if ($http_user_agent = "") { return 403; }
    if ($http_user_agent ~* "python-requests|scrapy|curl") { return 403; }
    
    proxy_pass http://ai_backend;
}

rate=3r/s 限制每个IP每秒最多3次请求,对AI接口来说足够正常用户使用,但能有效遏制机器刷量。burst=5 nodelay 允许短暂突发5个请求立即处理。limit_conn ai_conn 10 限制单IP最多同时保持10个连接。

两条 if 判断拦截了空UA和常见自动化工具的特征标识。真实用户的浏览器一定会携带User-Agent,而大量攻击脚本要么不带UA,要么使用默认的工具标识。

四、系统层面:防止资源被耗尽 ⚙️

攻击期间,服务器资源消耗会急剧上升。提前调整内核参数能显著提高承压能力:

# 开启SYN Cookie,防御半连接攻击
echo 1 > /proc/sys/net/ipv4/tcp_syncookies

# 加速孤儿连接回收
echo 1 > /proc/sys/net/ipv4/tcp_orphan_retries

# 扩大文件描述符上限
ulimit -n 1048576

tcp_syncookies 在SYN队列满时启用Cookie校验机制,不为未完成的连接分配内存,从根源上化解SYN Flood。tcp_orphan_retries 设为1表示对已失去进程关联的孤儿连接只重试一次就回收,防止僵尸连接占满资源。ulimit -n 把单进程可打开的文件描述符数量提升到100万级别,确保高并发下不会因为fd耗尽而拒绝服务。

五、长效机制:从被动挨打到主动防御 🧠

应急处理只是救火,真正的安全需要建立常态化防御体系:

流量基线监控 —— 记录日常正常流量的QPS、带宽、连接数等指标,设定合理告警阈值。当指标偏离基线超过一定比例时自动触发告警,争取在攻击初期就发现异常。

TLS指纹识别 —— 通过分析JA4等TLS握手指纹,区分真实浏览器和攻击工具。大多数CC攻击工具的TLS指纹与正常浏览器有明显差异,可以在不影响用户体验的前提下精准拦截 😎

多节点容灾部署 —— AI服务不要只部署在单一节点。通过多地域部署加上智能调度,即使某个节点遭遇攻击被打瘫,流量可以自动切换到其他节点,保证业务连续性。

总结 ✅

AI被攻击的应对核心就是四个字——分秒必争。先用命令快速定位攻击类型和来源,临时封堵止血;然后接入高防清洗流量、锁定源站白名单;再在应用层和系统层做精细化防护;最后建立长期监控和自动响应机制。每一层防线都不可或缺,环环相扣才能真正守住你的AI服务。

THE END