深夜十二点手机连着响了好几条告警。我打开腾讯云控制台一看CPU直接干到100%带宽监控曲线几乎垂直拉满入网流量稳定在接近上限的位置。尝试SSH登录卡了好几秒才进去敲命令都有延迟感。第一反应是业务代码写挂了比如死循环或者日志刷爆但看了下业务进程流量却完全对不上——这个项目平时日活不高出入带宽加起来都到不了几兆如今却被打到上限一定是被攻击了。这篇文章我完整还原从发现问题、定位攻击类型、临时止血到事后加固的全过程。大部分内容都是我在真实服务器上操作过、验证过的命令和思路适合所有用腾讯云或者其他云服务器做业务的开发者参考尤其是那些没有专职运维开箱即用、全靠自己扛的同学。1. 确认被攻击而不是业务故障我的判断链路接到带宽告警不要急着清进程。磨刀不误砍柴工先把是不是攻击这个前提钉死。因为如果是业务自身问题你封IP、加防火墙都是白折腾反而影响正常用户访问。1.1 先看业务监控曲线我习惯先看腾讯云控制台上的三张曲线图出入带宽、CPU使用率、磁盘读写。攻击的特征是这三者往往同时飙升尤其是入带宽与CPU强相关而业务故障通常只有其中一个或者两个指标异常。如果磁盘读写不高、负载却飙高多半是CPU密集型的攻击流量如果磁盘狂写、带宽一般那才是日志或者数据库的问题。我这次的情况是这样入带宽已经到服务器配额的峰值CPU也持续接近100%但磁盘读写非常平稳没有异常的大量写入。这就基本排除了日志刷爆这类自伤问题。同时我观察到业务监控里在线人数没有暴涨API响应时间却恶化了数倍说明流量不是正常用户带来的。1.2 检查安全组和访问日志第二步我快速看了腾讯云安全组近期变更记录确认自己没有手动放通过奇怪的端口也查看了Nginx或者应用访问日志。攻击时日志往往会有很明显的特征比如同一个IP反复请求某个接口、大量404/502请求、或者User-Agent字段异常。但这些排查不一定要在登录服务器后做控制台的流量监控和负载均衡日志同样能帮你快速建立攻击画像。1.3 快速验证能否正常登录和操作如果服务器完全无法登录或者每条命令都要等好几秒说明入向流量已经耗尽带宽甚至触发了黑洞策略。这时候别慌先在控制台用VNC/管理终端登录稳定网络不依赖业务带宽能救急。我这次SSH还能通只是延迟明显说明还没到黑洞那一步还有时间排查。提示一旦云厂商检测到入流量超过一定阈值通常是配额或者DDoS防护阈值会自动触发黑洞——所有流量被丢弃公网IP直接不可访问持续几十分钟到几小时不等。如果已经黑洞了先看控制台提示不要去服务器里面瞎折腾等解封再处理。2. 登录服务器后的排查用这几组命令锁定真凶SSH连上后我没有急着kill进程而是按进程→连接→流量→日志的顺序做了一次完整的体检。因为攻击手法千奇百怪但总会留下痕迹关键在于用对的工具去看对的地方。2.1 top 先看进程和负载top -c-c参数能显示完整的命令行比默认的进程名更直观。我按CPU排序发现一个名为kworker的进程CPU占比异常高但这通常是假的——攻击者会把挖矿或者代理程序伪装成系统内核工作线程。真实的 kworker 一般不会导致单核跑满更不会长时间占用CPU。再按内存排序看看有没有异常进程。如果发现名字跟系统进程几乎一致但路径在/tmp、/dev/shm、/var/tmp这些目录下九成是恶意程序。这次我看到一个/tmp/.X11-unix目录下的二进制文件名字叫sysguard进程列表里显示-bash前缀这种就是典型的伪装木马用ls -la /proc/[PID]/exe查看真实路径就能确认。ls -la /proc/[PID]/exe如果软链接指向/tmp/.X11-unix/sysguard基本可以实锤是恶意程序。先别杀留着它观察一会儿反而能帮我们判断攻击源。2.2 用 netstat 和 ss 统计连接数带宽被占满最常见的原因是大量的TCP连接或者UDP流量。用ss命令快速查看连接状态ss -ant | awk {print $1} | sort | uniq -c | sort -rn正常服务器连接数可能几十到几百攻击时会有大量 SYN_RECV、ESTABLISHED 状态的连接。SYN_RECV 过多是典型的SYN Flood特征说明攻击者在不停地发TCP握手请求但从不完成握手ESTABLISHED 多但带宽异常则可能是CC攻击大量模拟真实用户的长连接。我进一步统计连接来源IPss -ant | awk {print $5} | cut -d: -f1 | sort | uniq -c | sort -rn | head -20这能看到哪些IP发起了最多连接。正常情况下来自同一IP的连接数不会特别夸张如果前几个IP的连接数成百上千基本都是攻击IP或者代理节点。我记录下这些IP等会儿封禁用。2.3 用 iftop 和 tcpdump 判断流量构成进程和连接都有了还得弄清楚流量是大包打满带宽还是小包高并发消耗CPU。这两个方向应对策略完全不同。iftop -n -i eth0注意网卡名要改成自己的腾讯云服务器常见的是 eth0部分新机型是 ens5。iftop实时显示流量排名我看出流量来源集中在两三个IP段且单个IP流量占到了总带宽的70%以上这进一步确认了是DDoS放大攻击而不是CC。要精确看包结构用tcpdump抓一段数据tcpdump -i eth0 -nn -c 2000 -w /tmp/attack.pcap抓下来之后用tcpdump或下载到本地用Wireshark分析重点看协议类型和包大小。如果是大量小包几十字节高频到达属于流量型DDoS如果是大包超过1000字节持续冲击则可能是UDP Flood或者DNS/NTP反射放大攻击。我的抓包结果显示约85%的流量是UDP大包来源端口443目标端口随机典型的UDP Flood特征。2.4 检查登录日志和计划任务攻击者能投递恶意程序到服务器往往意味着他们有登录渠道最常见的就是SSH暴力破解。我看了 auth 日志grep Accepted /var/log/auth.log | tail -20CentOS/腾讯云OpenCloudOS的路径是/var/log/secureUbuntu是/var/log/auth.log。如果发现有大量来自可疑IP的失败尝试或者成功登录说明服务器已经被拿下过单纯封流量不够还要排查后门。同时还检查了 crontabcrontab -l cat /etc/cron.d/* | grep -v ^#很多持久化木马会通过计划任务重新拉起清掉了进程隔几分钟又复活。这也是为什么很多人在紧急时刻杀了进程但过会儿还是被占满带宽的原因——没有断根。注意如果确认有进程异常、登录记录异常、计划任务异常你就不仅仅是面对DDoS攻击了而是服务器已经被入侵并植入后门。这时候最稳妥的方案不是手动清理而是备份数据后重装系统或使用云厂商的快照回滚到一个干净的时间点。不要嫌麻烦清不干净就是给自己埋雷。3. 腾讯云服务器被攻击的常见类型带宽是怎么被占满的判断完具体场景后我觉得有必要把带宽被占满这件事拆开讲因为很多读者问我的时候都直接说被攻击了但具体是哪一种攻击对应方案完全不一样。这里我按实际遇到的概率整理了一张对比表。攻击类型攻击特征带宽表现典型协议/手法核心影响流量型DDoS大流量直接冲击出入带宽迅速打满UDP Flood、SYN Flood、ICMP Flood、反射放大带宽耗尽正常用户无法访问应用层CC攻击模拟真实请求带宽可能打满也可能不高HTTP/HTTPS高频请求、慢速连接CPU/数据库连接被打满业务不可用入侵后门与木马外联服务器主动向外发流量出带宽异常代理、挖矿、DDoS僵尸程序带宽被用于发送攻击流量或挖矿SSH暴力破解大量登录尝试带宽往往不高SSH协议高频尝试一旦成功即等同服务器沦陷3.1 流量型DDoS最容易打满带宽流量型DDoS的目标很纯粹——把你的带宽打满让正常用户连不上。UDP Flood 是最常见的手法伪造源IP往你的服务器狂发UDP包SYN Flood 则是发送大量不完整的TCP握手请求让你的服务器在等待握手时耗光连接表表现就是连接数暴增CPU也被中断处理拖垮。反射放大攻击更恶心攻击者不需要很高的带宽就能借助互联网上的NTP、DNS、Memcached等服务器放大流量让你直接被十几倍甚至上百倍的流量灌死。这也是为什么你的服务器可能本身只买了5M带宽却看到入流量打到几Gbps的原因——云厂商在更上游就检测到并可能直接黑洞。这类攻击的典型特征入向流量巨大且瞬间到达iftop看到的是单个或者多个IP疯狂发包tcpdump抓包能看到大量特定协议的报文包长度高度一致。对付流量型DDoS靠服务器内的防火墙基本没用——流量已经到达你机房了防火墙拦不住带宽消耗。唯一的正解是使用高防IP或者CDN清洗或者老老实实等攻击结束、触发黑洞后自动缓解。3.2 应用层CC攻击带宽可能不高但CPU爆炸CC攻击的思路更像挤兑——它不追求打满带宽而是让服务器忙于处理看似合理的请求耗尽CPU、数据库连接数和应用线程池。如果你的带宽监控曲线并不算满但CPU 100%、应用响应缓慢优先考虑CC。我见过一个典型场景攻击者枚举你的API接口用大量代理IP循环请求一个耗时的数据库查询接口每个请求本身很小几KB但并发几千数据库连接池被占满所有正常用户请求全部排队。这种攻击用安全组封IP并不高效因为攻击IP数量巨大且分散需要配合应用层防护Web防火墙、限流规则和CDN缓存来缓解。CC攻击的判断方法看访问日志同一时间段内出现大量来自不同IP的相同请求路径User-Agent 或者 Referer 异常集中响应时间普遍拉长。还可以看TCP连接中 ESTABLISHED 的连接数是否远高于正常值。3.3 入侵后的外联消耗带宽被偷走了这种场景最容易被忽视。如果是出方向带宽被打满大概率不是外部DDoS而是服务器上被植入了木马、挖矿程序或者DDoS僵尸程序在持续向外发送数据。攻击者利用你的带宽作为跳板去攻击别人或者让服务器沦为矿机。我这次遇到的sysguard进程本质上就是一个代理转发程序——它把服务器变成跳板替攻击者转发恶意流量出带宽自然就被打满了。好在发现及时恶意程序的流量特征和正常业务差别明显通过nethogs或者iftop能看到是哪个进程在疯狂发包。nethogs eth0这个工具能直接看到进程级的流量占用比iftop更精准。如果确认某个未知进程在大量发包不要犹豫先下掉进程再断网继续让它跑只会加重服务器负载、加深带宽占用。3.4 SSH暴力破解前奏式攻击暴力破解本身不消耗太多带宽但它是很多后续攻击的前奏。攻击者通过爆破拿到服务器权限后再植入木马、挖矿程序然后利用你的机器做更多坏事。我建议所有服务器使用者都检查一下/var/log/secure如果每分钟都有几十上百条失败登录记录说明你的服务器早就被盯上了。这类攻击的防范最基础也最重要禁用密码登录改用密钥对修改SSH默认端口安装 fail2ban 自动封禁尝试登录的IP。后文我会详细讲具体操作。4. 应急止血实战从安全组到黑洞机制的处理过程确认是UDP Flood配合服务器被植入代理木马后我开始了止血操作。止血分三步走先用腾讯云安全组做第一道屏障再进服务器清理进程并加固网络层最后根据情况做好等待黑洞解封或购买高防的准备。4.1 安全组封禁攻击IP快、准、但不彻底登录腾讯云控制台进入该服务器绑定的安全组添加入站规则拒绝来自攻击IP的流量。如果攻击IP是一个固定IP段建议直接拒绝整个C段效率更高。# 参考规则 来源: 1.2.3.4/32 协议: 全部 端口: 全部 策略: 拒绝安全组的生效时间通常在几秒到几十秒非常快。但问题是流量型DDoS的源IP往往是海量的安全组规则有上限而且攻击者可以随时换IP靠手工封禁只能缓解一时。我在这次攻击中封了十几个IP但带宽曲线只是短暂下降随后又被新的流量打满。这时候我意识到攻击者使用的是大流量DDoS而非单纯靠少数IP发起的攻击。安全组的另一个局限是它只对入站流量生效如果你服务器上的木马在向外发包安全组规则并不能阻止出站流量——那就得进服务器内部解决。4.2 服务器内部处理iptables封禁与恶意进程清理登录服务器先用iptables做临时封禁。封禁来源IP和攻击端口iptables -I INPUT -s 1.2.3.4 -j DROP如果攻击流量是针对特定端口比如UDP 443可以直接丢弃该端口的入包iptables -I INPUT -p udp --dport 443 -j DROP但要注意如果这个端口是正常业务在用比如HTTPS盲目丢弃等于自断业务。这时候需要权衡业务可用性和服务器存活如果带宽已经被打满导致所有业务都无法访问先丢弃攻击端口保住服务器基础运行反而是更优解等攻击结束再恢复。接下来处理恶意进程。我用kill -9 [PID]杀掉了sysguard同时立即删除它的启动文件和计划任务rm -rf /tmp/.X11-unix crontab -l | grep -v sysguard | crontab -这时候带宽曲线开始回落。说明这台服务器的带宽占用主要来自木马外联而不是外部DDoS。两者叠加掩盖了真实情况——如果只封外部IP不杀木马问题永远不会解决。经验千万不要只看到外部DDoS流量就忽略服务器本机进程检查。很多攻击是内外配合的——攻击者先通过漏洞攻破服务器植入代理工具再用大流量DDoS吸引你的注意力让你忙于封IP而木马在后台悄悄转移数据。排查时流量→进程→连接→日志顺序缺一不可。4.3 面对流量型DDoS等待黑洞还是上高防清理完木马后入带宽的DDoS流量仍然存在只是权重降了很多。如果外部DDoS流量超过阈值腾讯云会触发黑洞策略。黑洞期间服务器公网IP彻底失效所有流量丢弃这是云厂商保护底层网络的必要手段。触发黑洞后控制台会显示解封时间通常几十分钟到几小时。遇到黑洞我的建议是分清轻重缓急情况应对方案业务可容忍短暂中断等待黑洞自动解封期间做好加固业务需要持续对外提供服务立即开启或购买DDoS高防IP把流量牵引到高防清洗后再回源攻击流量不大但持续时间长先用安全组防火墙封禁必要时升级带宽服务器已被入侵优先备份数据重装系统或回滚快照对于个人开发者和小团队如果业务重要且经常被打直接开高防IP或者用CDN把业务隐藏在回源IP之后。价格虽然不便宜但相比业务长时间中断造成的损失还是划算的。4.4 解封后的第一件事全面排查黑洞解除后我做的第一件事不是急着恢复业务而是再次检查服务器状态。重新执行 top、ss、日志排查确认恶意进程没有复活、没有新的异常连接、计划任务干净。同时修改所有涉及服务器的密码包括数据库密码、Redis密码和管理后台密码因为攻击者可能已经通过这台机器尝试横向渗透到内网其他资产。我还会启用腾讯云主机安全云镜/主机安全的实时防护能力开启木马查杀和异常登录告警。免费版也能提供基础的基线检查和告警能力对个人用户很实用能大幅降低被攻破后还不知道的概率。5. 长远的防御之道如何避免再次被攻击打满带宽攻击处理完只是治标真正的功课在事后。我反思这次事件发现有太多可以提前做好的防御措施。以下是我现在给所有服务器都强制执行的安全基线分享出来供大家参考。5.1 禁用密码登录使用密钥对密钥登录是性价比最高的安全措施。攻击者爆破的是密码没有密码文件爆破自然失效。腾讯云购买服务器时可以直接选择密钥对已有的服务器也可以手动配置# 在本地生成密钥对 ssh-keygen -t rsa -b 4096 -C your_emailexample.com # 将公钥拷贝到服务器 ssh-copy-id userserver_ip # 修改SSH配置 vim /etc/ssh/sshd_config # 找到并修改以下三项 PasswordAuthentication no PubkeyAuthentication yes RSAAuthentication yes # 重启SSH服务 systemctl restart sshd改完之前一定先测试新终端能登录不然自己会被关在门外。很多云厂商控制台提供VNC管理终端即使SSH进不去也能补救但最好别依赖这个。5.2 修改SSH默认端口并启用 fail2ban把SSH默认端口从22改成高位端口能直接绕过大量扫描器的默认扫描。虽然真正有耐心的攻击者依然能发现但能挡掉90%以上的自动化爆破脚本。# 修改 sshd_config Port 22222 # 别忘了在腾讯云安全组里放行新端口并移除旧的22端口配合 fail2ban 效果更好它会自动监测登录失败记录并临时封禁来源IPyum install fail2ban -y systemctl enable fail2ban systemctl start failban默认配置就能用超过5次登录失败就封禁10分钟。对暴力破解来说这个策略非常有效。5.3 做好监控告警别等用户发现你被打腾讯云控制台自带基础监控告警支持带宽、CPU、内存、磁盘等指标的阈值告警。我给所有服务器配置了以下告警规则指标告警阈值通知方式入带宽超过带宽上限的80%持续5分钟短信微信/邮件CPU使用率超过90%持续10分钟短信公网出带宽超过带宽上限的80%持续5分钟短信微信/邮件登录成功次数任何登录成功都告警邮件别轻视监控告警这次能及时发现攻击靠的就是自动告警。如果是等到用户反馈网站打不开才发现损失会大得多。5.4 定期安全巡检清单我给自己定了一个每周巡检任务不复杂但坚持下来能发现很多隐患检查登录日志中是否有异常IP成功登录grep Accepted /var/log/secure检查计划任务是否有新增项crontab -l和/etc/cron.d/检查对外开放端口是否最小化ss -tlnp不需要的端口一律不放行检查系统更新和补丁yum update或者apt update apt upgrade检查是否有未知系统用户cat /etc/passwd | grep bash检查云控制台安全组规则清理过期和过宽放行的规则这套清单做完大概10分钟但可以发现绝大多数被入侵的前兆。安全不是一锤子买卖而是一套持续运行的习惯。5.5 如果真的经常被打上高防或换架构对于攻击频率高、业务刚需持续在线的用户单纯靠服务器自身防御终究扛不住大流量DDoS。这时候可以认真考虑把业务放在腾讯云Web应用防火墙后面或者直接使用DDoS高防IP把攻击流量引流到高防节点清洗后再回源。虽然费用上来了但换来的是稳定和安心。如果预算有限还有一个思路把静态资源全部上CDN源站IP不暴露域名解析走CDN节点。这样攻击者看不到源站IP攻击只能打在CDN节点上CDN厂商本身的带宽储备足以消化绝大多数DDoS流量。缺点是动态接口无法缓存攻击者依然可以通过找出源站IP来攻击但对中小型项目来说这套组合已经很能扛了。经历了这次抗战我最深的体会是云服务器安全这件事拼的不是运气而是提前把每一道防御做实。攻击者永远在找最软的那个柿子捏你的服务器越硬被打的概率就越低。就算真的被打有了监控告警和清晰的应急流程也能在十几分钟内定位问题、控制损失而不是对着满屏报警一头雾水。最后顺手分享一个实用小技巧在腾讯云控制台的DDoS防护页面可以看到攻击流量的大小和类型分布这个数据对于判断攻击手法非常有用。如果你被打了先去看那里再决定下一步怎么处理比在服务器里瞎抓要高效得多。