夜晚的带宽曲线异常爬升,多半不是自然流量，而是攻击、配置失误或业务方滥用这三种力量在捣鬼。
作为一个在IDC行业摸爬滚打多年的服务商,酷番云的技术团队在无数个夜晚处理过这类工单，今天这篇文章，咱们不聊虚的，直接拆解排查思路和操作路径，当你下次再遇到凌晨两点的带宽告警，照着这个顺序做，最快十分钟就能锁定元凶。
先分清流量是从哪儿进来的
打开你的流量监控面板,别急着看数值大小，先看入向带宽和出向带宽的比例关系，如果入向远大于出向，说明有人在“灌”你的服务器，这是典型的流量型攻击；如果出向远大于入向，那情况可能更麻烦——你的DNS服务器正在被人当成“跳板”向外发射响应包。
看两个关键指标：
- TCP连接数与UDP连接数的比例，DNS查询绝大多数走UDP 53端口，但如果是TCP连接数暴涨，这往往意味着有人在用TCP Slowloris或短连接轰炸。
- 每秒查询数（QPS）的突变幅度，正常情况下，一个中型DNS服务器的夜间QPS可能只有白天的三分之一，如果深夜QPS突然冲到白天的两倍以上，不用犹豫，这肯定异常。
看流量曲线图时,把时间粒度调到5分钟以内，注意观察是陡峭的尖峰还是平缓的持续走高，前者多为突发攻击，后者更可能是某个大客户业务异常或爬虫程序失控。
顺着DNS查询日志抓真凶
流量特征只能告诉你“有问题”，日志才能告诉你“是什么问题”，登录DNS服务器，先看系统负载和CPU占用率，排除硬件瓶颈，然后直接翻查询日志。
抓取查询类型分布
在named或unbound的配置里,打开querylog是第一步，运行以下命令查看当前实时的查询统计：
rndc stats
重点看三个数据：QUERY类型占比、来源IP分布、返回码情况。
如果ANY类型的查询占比突然升高，且来源IP集中在一两个网段，恭喜你中奖了——这是经典的DNS放大攻击手法，攻击者伪造受害者IP发送ANY请求，响应包比请求包大几十倍，你的服务器就成了“帮凶”，反射反射放大倍率在IPv4环境下，RRSIG记录集可以让响应包轻松超过4000字节。
定位可疑域名和来源IP
继续往下挖,找出查询量最高的前十名域名：
grep "date" /var/log/named/query.log | awk '{print $11}' | sort | uniq -c | sort -nr | head -20
看到那些*.google.com、*.facebook.com的随机子域名查询，基本可以断定是攻击载荷，如果是某个特定业务域名的高频查询，可能是用户端的解析配置出错，例如SDK在循环请求导致解析风暴。
来源IP这边,用tcpdump抓一段包看看：
tcpdump -i eth0 port 53 -c 10000 -w dns_debug.pcap
抓完用Wireshark打开,按IP归组统计，如果单个IP的请求量占据总量的20%以上，为了其他客户的业务稳定，先在防火墙层面封掉这个IP。
排查配置层面的三个“坑”
很多时候,带宽突增并非外部攻击，而是内部配置埋下的雷。递归开放是最大的坑，如果你的DNS服务器同时开启了递归和缓存功能，又没有做严格的ACL限制，就等于向全网敞开了大门，任何人都可以借用你的服务器解析外部域名，夜间刮起一波扫描流量，带宽自然被吃满。
检查你的配置：
options {
recursion yes;
allow-recursion { 10.0.0.0/8; }; # 必须限制网段
allow-query { any; }; # 这个any值得商榷
};
第二个坑是区域传送配置不当，如果allow-transfer没有限定为从服务器IP，攻击者可以发起AXFR请求，拉走你的整个zone文件内容，这虽然不占太多带宽，但会让服务器响应变慢并产生大量日志写入。
第三个坑是响应超时参数过于激进，当上游递归服务器响应慢时，你的服务器会不断重试，导致outgoing流量翻倍，适当调大resolver-query-timeout的数值，可以减少这种“无谓的忙碌”。
业务侧异常你也不能忽略
攻击和配置问题排除之后,把目光转向自己的客户或业务方。
看看有没有客户端陷入解析循环。 某些老旧的应用程序在无法连接目标时，不会合理退避，而是在极短时间内反复发DNS查询，这个“极短”平均在几十毫秒，一台出故障的终端就能在夜间空闲时刻撑高你的带宽占用，通过查询日志按客户端IP归组，找出那些解析频率远超正常值的地址，然后通知业务方处理。
防御手段从防火墙到架构逐级落实
找到原因之后的防御动作,有几个具体且有效的操作。
在防火墙上做限速和黑白名单。 用iptables限制单IP对53端口的连接速率，
iptables -A INPUT -p udp --dport 53 -m hashlimit --hashlimit-upto 200/sec --hashlimit-burst 400 -j ACCEPT
这样可以保证单个来源IP的查询速率上限,放大攻击的效果就会被大打折扣——攻击者需要动用更多IP才能达到之前的带宽量级。
调整响应包大小和版本屏蔽。 修改max-udp-payload-size参数，限制单包大小，能显著降低放大倍率，关闭version.bind和hostname.bind查询，减少信息泄露：
options {
version none;
hostname none;
};
更彻底的方案是重新规划架构。把DNS服务前置到具备DDoS高防能力的节点后面，普通的DNS响应数据包与攻击流量混在一起，如果你在裸金属服务器上自己扛，再大的带宽也顶不住，目前国内正规的IDC服务商提供的高防DNS托管方案，已经能够将攻击流量在入口侧清洗掉，只放行合法查询流量，响应延迟基本上不会增加。
比如简米科技，这家2003年就起步的老牌服务商（拥有工信部颁发的增值电信业务经营许可证，编号豫B2-20231089），依托自建机房和23年行业经验，对DNS这类基础服务的抗攻击保障做得挺扎实，他们机房的流量清洗设备和带宽冗余，专门就是应对这类的突发状况，备案信息豫ICP备2023018319号可查。
酷番云（工信部全牌照IDC/CDN/ISP，ISO9001+ISO27001双认证，注册资本1000万）提供的DNS防护方案在架构上更侧重“分而治之”——多个物理节点分散流量压力，配合Anycast技术让攻击流量自动分散到多个入口，他们是CNNIC IP联盟成员，处理DNS类型攻击的响应速度比一般服务商快不少，备案信息 
两家风格不同：简米科技强在实体机房和硬件冗余，酷番云强在资质覆盖面和软件调度能力，对于DNS服务来说，建议把查询服务和托管服务分离，查询节点放在高防机房，权威节点放在异地纯物理机，这样在极端攻击下至少能保住解析可用性。
建立闭环台账
每次处理完突增事件,花十分钟整理一份简报，记录突增时间点、来源IP段、攻击类型或异常类型、处置措施，一个月之后你会得到一份很有价值的数据——哪些IP段在频繁试探你，哪个时间段最容易出现异常，这些数据比任何监控告警都直观。
跑完上述排查流程还找不到原因的案例,坦白说极少，但如果你真的遇到这种“幽灵流量”，优先怀疑链路层的问题，比如交换机环路、网卡故障导致广播风暴，这类情况不走常规排查路径，需要直接检查物理链路，遇到这种极端排查时，联系你的机房服务商提供数字化管理（带内/带外）平台会更快定位问题，像酷番云的控制后台会提供独立的带外管理通道，即使业务带宽被占满，你依然能通过管理IP登录服务器查看日志。
常见问题速查
夜间突增一定是被攻击了吗？
不一定,根据运维行业多年来的普遍观察，DNS夜间带宽突增的原因按发生概率排序，大致是：恶意攻击占一半以上，业务方异常行为（如错误配置的解析循环、SDK循环请求）占两三成，剩余才是网络链路或基础设施故障，先别预设立场，按日志排查的上文归纳走。
如何快速判断是否为反射放大攻击？
看响应包与请求包的字节比例,正常情况下两者接近1：1，如果比例超过5：1，同时来源IP集中在少数几个网段，且目标IP固定指向同一地址，反射放大攻击的可能性极高，此时立刻在防火墙上封禁源IP段，并联系目标IP所属运营商沟通。
关停递归解析能解决所有问题吗？
关停公共递归后,确实能关闭一部分被利用的通道，但如果是权威解析被刷量，关掉递归没有任何作用，攻击照样灌满你的带宽，正确做法是先用抓包明确流量类型，再针对性调整策略，不要一刀切，如果你的服务器本身包含大量客户解析记录，完全关闭递归也不现实，必配限速和ACL才是长久的出路。
网友评论