凌晨一点四十七分我的手机连着震了三次。腾讯云App的告警推送显示我那台4核8G的云服务器出带宽从平时的几Mbps一路冲到了接近打满监控图上几乎是一条直线顶在顶部。好多年前我第一次遇到这种情况时第一反应是怀疑自己中了挖矿木马登录上去top一看CPU根本没异常后来才明白这不是机器本身的问题而是有人正冲着这台服务器的带宽下手。如果你也跑着腾讯云的服务器突然有一天发现带宽被打满、网站打不开、SSH卡到怀疑人生这篇文章就是为你写的。我会完整还原我从发现异常、定位攻击类型、紧急处置、恢复业务到事后加固和溯源的全过程包括每一步为什么这么做、用什么命令、控制台上怎么点以及我踩过的坑。1. 事发当夜先别慌花十分钟搞清楚现状1.1 第一现场告警、登录和直觉判断我当时的服务器配置在腾讯云里算很标准的一档4核8G内存、5Mbps固定带宽、系统盘50G跑着一个个人项目站点、两个API接口还顺手给朋友搭过一台rtmp推流测试机。日常出带宽峰值也就2到3Mbps入带宽基本可以忽略。所以当告警提示出带宽拉满、入带宽也异常增高时我心里已经基本确认不是正常业务流量。第一件事不是瞎查而是先确认自己还能不能登录。带宽被打满时最常见的情况是SSH压根连不上去或者连上了敲命令都卡顿。我试了一次SSH果然连握手都困难。这时候千万别反复重试而是改走腾讯云控制台的VNC登录方式只要控制台还在就能绕过网络层直接操作操作系统这是我们保住操作入口的关键一步。登录进去后我按顺序快速做了三个动作uptime确认系统没重启过运行时间正常说明不是被入侵后重启。free -h和df -h看内存和磁盘排除内存耗尽和日志把盘写满的情况。top看CPU和进程列表确认没有可疑进程在跑。这三个动作都是排除法。攻击分很多种有些是打系统漏洞有些是打应用层的有些就是纯粹打带宽。CPU、内存、磁盘都正常进程列表里也没有陌生的东西那基本可以锁定这是一场针对带宽的攻击也就是典型的DDoS流量型攻击。1.2 用四类命令快速定位流量从哪来确认是带宽型攻击后接下来要把攻击流量看明白才知道怎么堵。我建议你按照下面这套顺序来排查都是最常用的工具如果系统里没有就先装一下# 安装常用网络排查工具CentOS/Rocky用yumUbuntu/Debian用apt apt install -y iftop nload sysstat tcpdump # 或 yum install -y iftop nload sysstat tcpdump第一类命令是看实时带宽和网卡流量。iftop -i eth0 -nNB和nload可以直观看到当前哪个IP在大量占用带宽。注意先把网卡名确认清楚ip addr看一下腾讯云服务器网卡可能是eth0也可能是ens5名字搞错了命令就直接报错。第二类命令是查TCP连接状态。netstat -antp | awk {print $6} | sort | uniq -c | sort -rn可以看到所有连接的分布正常服务器连接数可能只有几百被打时你会发现同一状态的数量异常大比如几千个SYN_RECV、几万个ESTABLISHED或不正常的TIME_WAIT。第三类命令是抓包。tcpdump -i eth0 -nn port 80 -c 200抓200个包看看载荷能快速判断是SYN包、UDP包还是确实在发HTTP请求。这里的细节很关键不同攻击类型在tcpdump里的表现完全不一样。第四类命令是看系统整体网络统计sar -n DEV 1 5连续采样几次能看出入方向还是出方向被打以及是哪个网卡在扛压力。1.3 判断攻击类型的三个关键特征我把这次排查中判断攻击类型的经验总结成三个特征这三个特征几乎是通用的第一个特征是连接状态分布。如果SYN_RECV数量暴增大概率是SYN Flood攻击者发大量不完成握手的SYN包把你的半连接队列塞满如果是ESTABLISHED大量堆积且后续请求都没响应有可能是TCP连接耗尽或者应用层CC攻击。第二个特征是端口和协议分布。理论上UDP流量占比突然变得非常高往往是UDP Flood攻击者随机向服务器端口发垃圾UDP包如果80或者443端口上流量特别大那可能是针对Web服务的攻击。第三个特征是来源IP的规律。netstat -antp | grep :80 | awk {print $5} | cut -d: -f1 | sort | uniq -c | sort -rn | head -20可以直接列出最活跃的来源IP。如果排名靠前的只有少数几个IP那就是少数源头在打如果来源IP成千上万且非常分散那基本是僵尸网络发起的分布式攻击这种单靠封IP是封不完的后续必须上流量清洗。我这次的情况是入带宽持续跑满UDP流量占了大头来源IP极为分散。结论非常明确UDP Flood而且是分布式的服务器本身没被打穿但带宽已经被垃圾流量吃干净了。2. 带宽为什么会瞬间失守常见攻击与影响链路2.1 带宽耗尽型攻击的底层逻辑很多人第一次遇到被攻击时的困惑是我服务器CPU还好好的内存也好好的为什么网站就是打不开要理解这个问题得先搞清楚带宽在云服务器里扮演的角色。云服务器的带宽可以理解为一条水管你的业务流量正常通过水管流动用户请求进来、响应出去都靠它在走。而带宽耗尽型攻击的本质就是在水管里灌满垃圾水。当入带宽被垃圾流量占满正常用户的请求包就进不来服务自然就断了当出带宽被打满即使服务器处理完了请求响应也发不出去。这就是为什么DDoS攻击里有一大类叫带宽耗尽型攻击它不关心你服务器的CPU有多强、内存有多大它只关心你的带宽有多大。哪怕你用的是64核高性能实例只要带宽是5Mbps对方用超过5Mbps的流量打进来你就断了。云服务器和传统物理机的差别在于它的出入口带宽是在云厂商侧限定的超过配置值之后流量要么被丢弃、要么触发黑洞所以带宽被打满这个状态在云上特别明显也特别好用。2.2 主流攻击流量的特征对比实际操作中你会遇到各种各样的攻击流量我把最常见的几种整理成了对照表方便你按特征去判断攻击类型攻击目标特征表现判断方法SYN FloodTCP半连接队列SYN_RECV数量暴增netstat统计连接状态UDP Flood带宽入带宽打满UDP包猛涨iftop/tcpdump看协议和端口ICMP Flood带宽/CPU大量ping包tcpdump看到大量ICMPCC攻击(HTTP Flood)应用层/带宽80/443大量真实HTTP请求Web日志里请求暴增、UA异常DNS Query FloodDNS服务DNS端口流量异常专门针对DNS服务器的场景这次我的服务器遇上的就是第二类UDP Flood。它的特点就是量大、粗暴、不需要维护连接状态攻击者用脚本生成海量随机端口的UDP包发给你你的网卡接收缓冲区瞬间被塞满。而且UDP无法通过三次握手来识别真伪服务器几乎无法单方面拒绝所以特别难缠。2.3 黑洞机制与腾讯云基础防护阈值说到DDoS防御必须聊一聊黑洞。腾讯云为每台云服务器默认开启了基础DDoS防护但这部分防护是有额度的。当攻击流量超过免费额度之后云平台为了保护整个物理网络不被拖垮会触发黑洞策略直接把这个IP的流量全部丢弃持续时间通常以小时计。很多新手第一次遇到黑洞时以为是服务器坏了其实不是。黑洞触发是有告警的进入控制台看到被封堵状态就明白了。这里有个非常实际的经验基础带宽越小被小流量打爆的风险越高但这些小流量又达不到触发免费清洗的量级所以你会发现带宽被打满时腾讯云并没有自动清流因为攻击流量还没到它开始贴心照顾你的量级。这不代表云厂商不作为而是免费防护的阈值设计就是这样的。我自己在处置过程中的感受是理解了带宽和黑洞的这层逻辑之后处置方案就清晰了。要么临时把带宽降下来并尽快接受断我几分钟的现实要么直接上付费的流量清洗服务。后者是要花钱的但业务连续性优先的话这钱不省。3. 应急处置从控制台到命令行的完整操作记录3.1 优先用VNC保住操作入口如果此刻你还没被攻击到SSH掉线只是有点卡那我建议你先开一个tmux或者screen会话再操作防止命令执行到一半连接断开导致半途而废。如果已经被打到我当初那种状态SSH基本连不上就直接去腾讯云控制台云服务器实例那页的登录按钮里有VNC登录这是独立于外网带宽的通道即使公网打满也能进去。进系统后我先做了一次快照不是装样子而是真心建议攻击过程中产生的包和日志是很好的分析材料但系统状态是动态的先拍快照可以避免后续误操作把现场搞丢。有需要的话之后还能在快照里翻出更早的日志来对比。我这次进去之后先用下面这套命令把网络情况完整记录了一遍等于给攻击现场拍照# 记录连接状态分布 netstat -antp | awk {print $6} | sort | uniq -c | sort -rn # 记录与80/443端口相关的活跃来源IP ss -antp | grep -E :(80|443) | awk {print $5} | cut -d: -f1 | sort | uniq -c | sort -rn | head -20 # 记录UDP连接概况 ss -uanp | head -30 # 抓200个包看流量特征保留成文件供后续分析 tcpdump -i eth0 -nn -c 200 -w /var/tmp/attack_dump.pcap这些输出我都用重定向存到了文件里。当时觉得麻烦后来溯源时发现这些记录帮了大忙攻击结束后很多状态就没了有pcap文件在可以反复分析。3.2 安全组紧急封禁先阻断再深挖控制台里最立竿见影的处置动作不是改服务器内部配置而是改安全组。安全组是腾讯云在虚拟机外层的防火墙流量到达系统之前就会在这里被过滤所以它是成本最低、速度最快的阻断手段。我当时的思路分两条腿走第一条腿是封来源。如果查出来攻击源IP是少数几个固定的IP直接在安全组加一条拒绝规则来源填对应IP协议和端口选全部策略选拒绝优先级放到最前面。注意安全组规则是有顺序匹配的从上到下第一条命中的规则生效所以拒绝规则必须放在放行规则前面。第二条腿是封端口。对于UDP Flood这种无差别攻击通常攻击都打在某些特定端口上如果你对外业务不需要UDP端口可以直接在安全组里把对应UDP端口全部拒绝。比如我这次UDP流量大量集中在随机高位端口我就先加了一条拒绝全部UDP入站的规则。这一步做完服务器的压力立刻降了不少至少SSH能顺畅用了。这里有个经验教训不要贪心把安全组规则删光来清净更不要在没确认自己IP的情况下把自己IP也封了。我第一次搞安全组时把自己当前IP顺手加进了拒绝列表结果VNC回不去、SSH也连不上折腾了十几分钟才意识到问题。改安全组之前先确认自己的出口IP是什么加完规则后留一个VNC窗口在控制台别关防止操作失误被锁在门外。3.3 临时止血后如何恢复业务安全组封掉UDP后我的SSH恢复了但业务还没有完全恢复因为安全组规则的生效存在一点时间差而且之前堆积的连接还在。这时候我在服务器内部又做了一层快速的iptables加固作为双保险。注意iptables规则是立刻生效的如果稍后改了安全组也不冲突。# 丢弃所有入站UDP包根据实际业务自行调整如果业务本身用UDP则不能这么干 iptables -I INPUT -p udp -j DROP # 限制单个IP对本机80端口的并发连接数缓解可能存在的连接耗尽 iptables -I INPUT -p tcp --dport 80 -m connlimit --connlimit-above 200 -j REJECT这一步做完之后带宽监控曲线开始明显回落。我建议你在确认攻击高峰过去之后花几分钟观察一下不要急着把所有规则撤掉。你得先确认业务恢复正常了再去慢慢放开限制每一步改动都小步快跑观察几分钟再动下一步。恢复业务还有一个容易被忽略的点DNS和缓存。如果你的域名之前解析到的IP被攻击了即使攻击停了部分地区的DNS缓存可能还指向旧IP。我自己当时在腾讯云控制台把DNS记录刷新了一下同时等了几分钟让运营商DNS缓存自然过期全国的访问就逐渐恢复了。如果你是自建DNS或者用了多级CDN这一步更要注意。3.4 高防与流量清洗什么情况必须花钱安全组和iptables能挡一部分攻击但挡不住大流量DDoS因为UDP Flood的流量在到达服务器之前就已经把你的带宽占满了安全组在流量进到VPC之后才生效等于说垃圾流量已经在你的网络里跑了一遍带宽已经消耗了。真要防住这种攻击必须把清洗动作放在云厂商的骨干网络上完成也就是购买DDoS高防产品。腾讯云的方案我实际对比过大概两条路一条是DDoS高防IP。你买一个高防IP把域名的解析切到高防IP上所有流量先经过高防机房的流量清洗清洗干净之后正常流量再转发到你原来的服务器IP。这种方式效果最好缺点是会引入转发延迟而且配置域名切换也需要一点时间。另一条是DDoS高防包。直接给现有IP叠加防护能力不用换IP配置比较简单。我当时考虑过但后来分析发现我这种小流量攻击用高防包有点大材小用而且按年付费也是一笔开销就没有立马上。但如果你跑的是正式业务或者被攻击的频率已经超过一周一次我的建议是别犹豫直接上高防IP。跟停机损失比起来防护成本真的不高。这次攻击量级其实不算大属于那种很烦但不至于搞挂云平台的级别所以我临时用安全组和iptables顶住了后面再做的加固动作才是真正让攻击成本变高的核心。4. 事后加固让下一次被攻击的成本变高4.1 SSH与登录层的三条硬规则每次被攻击之后我都会顺手检查一下服务器的登录暴露面因为攻击者不会平白无故盯上一台机器很多时候是因为扫描到了你的SSH端口是默认的22密码强度又不够先试探性地爆破一波爆破不成就顺手报个攻击让你焦头烂额。所以第一项加固就是SSH。三条硬规则缺一不可修改SSH默认端口。把/etc/ssh/sshd_config里的Port 22改成比如Port 2222改完重启sshd服务。这个动作能挡掉90%以上的扫描流量因为绝大多数自动化攻击脚本只会扫默认端口。禁用密码登录改用密钥登录。先在本地执行ssh-keygen -t ed25519生成密钥对然后把公钥内容追加到服务器~/.ssh/authorized_keys里确认密钥登录没问题后再把PasswordAuthentication设为no。这一步是挡暴力破解最狠的招没有密码可猜攻击者再怎么做字典都没用。限制root远程登录。日常操作用一个普通用户加sudo来管理PermitRootLogin设为prohibit-password只在需要时通过密钥以非root身份登录。这能大幅降低一旦密钥泄露后的破坏范围。改配置之前我强烈建议多开一个SSH窗口或者先起一个tmux会话再改因为如果配置写错、密钥没配好你在新端口上连不上又因为禁用了密码登录可能连sshd都起不来那只能VNC进去抢救了。我经历过一次很痛苦别重蹈覆辙。4.2 安全组与防火墙的精细化收敛解封应急规则后不能又把所有端口敞开恢复原样否则就是白加固了。精确到端口的收敛原则是只放行业务真正需要的端口其他全部默认拒绝。我最终的安全组规则大概长这样方向来源协议端口策略说明入站我的固定IPTCP 2222允许SSH管理端口只对自己的IP开入站0.0.0.0/0TCP 80/443允许Web服务端口入站0.0.0.0/0TCP 1935允许rtmp推流测试端口入站0.0.0.0/0ICMP拒绝防止ping探测和ICMP Flood入站0.0.0.0/0UDP ALL拒绝非业务需要直接全拒服务器内部的iptables规则也和这个对齐了做到双层防护。这里有个细节安全组是平台层的iptables是系统层的两者不冲突但某种程度上是冗余关系。为什么要双层因为有些攻击会绕过一层防御打在另一层上双保险能显著提高拦截率。4.3 监控告警的补课提前发现异常被攻击的第一个告警来自云监控说明我之前的告警策略是有的但粒度太粗了只有出带宽超过5Mbp持续5分钟这一条。等到这个告警出来时其实攻击已经开始一段时间了所以我又补了几个更早的告警点入带宽超过正常值持续3分钟。SSH登录失败次数出现突刺比如1分钟内超过10次。安全组被修改后触发操作审计通知。主机CPU或内存使用率异常飙升。腾讯云控制台的云监控-告警策略里都能配置按实例选好维度、填好阈值、选上通知渠道就行。我自己的习惯是把告警阈值设置得比正常峰值高一点点宁可偶尔误报也好过毫无知觉地被小流量打到服务不可用。另外我还在服务器本地装了fail2ban针对SSH做暴力破解防护。它会在一定时间内统计某个IP的登录失败次数超过阈值就自动拉黑。这个工具在腾讯云上可以直接apt/yum安装配置默认就够了我建议每个跑公网的服务器都装上。5. 攻击溯源与复盘到底是谁在打我5.1 从系统日志里翻出攻击源攻击结束后我花了不少时间做溯源分析。首先要有一个认知对于UDP Flood这种没有连接的攻击你很难真正追溯到幕后黑手能追到的只是攻击流量来源的IP而这些IP大多是僵尸网络成员或被伪造了源地址。但即使如此日志分析依然有价值它能告诉你攻击发生的时间线、流量特征、可能的攻击工具防止下一次被打个措手不及。看系统日志的重点是SSH认证记录。CentOS/Rocky系统的/var/log/secure、Ubuntu/Debian系统的/var/log/auth.log里记录了所有登录企图# 统计登录失败次数最多的IP grep Failed password /var/log/secure | awk {print $(NF-3)} | sort | uniq -c | sort -rn | head -20跑完这个命令你会发现一些非常有趣的规律。我这次在日志里看到攻击发生前约两小时就有几个IP在持续尝试SSH登录虽然不是主流攻击流量但把时间线串起来之后基本能判断这不是随机扫描而是有人先把靶机名单整理好、先做了一轮试探随后才发起的流量型攻击。这些IP和UDP Flood来源IP并不重合说明流量攻击大概率用了代理或僵尸网络做跳板。5.2 从Web日志还原攻击行为除了系统日志Web服务的访问日志也非常重要。我跑的是Nginx日志在/var/log/nginx/access.log攻击当天这文件膨胀了好几倍。先看请求量变化# 统计某一天的请求总数 awk {print $4} /var/log/nginx/access.log | cut -d: -f1 | sort | uniq -c再按IP和路径统计请求分布# 定义攻击时间段统计来源IP Top 10 grep 2025-06 /var/log/nginx/access.log | awk {print $1} | sort | uniq -c | sort -rn | head -10 # 统计请求最多的URL识别是否被针对特定接口打 awk {print $7} /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10如果攻击是CC类型日志里能看出UA非常随机、请求频率极高、路径集中在某个API上。如果只是流量型攻击Web日志反而不会太夸张因为大部分攻击流量根本没进入Web层就被带宽挡在外面了。我这次的情况属于后者所以Nginx日志信息量有限真正的证据都在pcap抓包里。5.3 一次实战复盘得到的三个经验复盘这件事我个人认为比处置本身更重要所以专门留了一节来说。经过这次被攻击我总结了三条经验可以说每条都是用时间和流量换来的第一基础防护额度不够用的时候不要硬扛。我当时纠结了很久要不要买高防觉得只是个人项目没必要花钱结果下一次攻击又来了还是要面对。如果你的业务有收入、有用户、有稳定流量请把DDoS高防当作基础设施成本的一部分和服务器费用一样正常。第二提前把运维手册写好省得半夜慌乱。我这次能在一小时内完成从发现到基本止血很大程度上是因为平时积累了一些排查命令和处置流程。建议你把自己的服务器情况梳理一份简单的SOP放在本地或云端笔记里告警响起时直接照着执行省去现场思考的时间。第三攻击并不可怕被同一块石头绊倒两次才可怕。每次攻击都留下了日志和抓包文件建议归档到本地或对象存储里命名带上日期和攻击类型。下次再发生类似情况先翻旧资料对比往往几分钟就能判断出攻击手法的相同点和变化处置效率会高非常多。写到这里这场带宽保卫战算是阶段性结束了。我个人的体会是服务器被攻击这件事在云时代几乎每个站长或运维都会遇到一次它不是末日而是一次很有价值的安全演练。关键是别慌、按流程走、事后认真加固和复盘。如果你也被攻击打过一次希望你看到这篇文章时能少走一些弯路睡得更安稳一点。