阿里云ECS防CC攻击配置实操：安全加固全套教程

当阿里云ECS的CPU毫无征兆飙满，而流量图表却无明显波动时，很多运维的第一反应是代码出了死循环，而非遭遇CC攻击。重复重启和手动封禁IP往往徒劳。这份阿里云ECS防CC攻击配置教程不打算给出一个万能开关，而是从主机层到应用层拆解加固逻辑，让异常不再被误读为业务增长。

一、阿里云ECS常见安全威胁与加固必要性

1.  木马攻击如何入侵

多数Linux挖矿木马的入侵路径极度依赖弱口令。以Xorddos和BillGates为代表的僵尸网络，至今仍通过SSH暴力破解批量植入ECS，它们占用算力挖矿的同时，还会把服务器变成对外发起CC攻击的跳板。有安全中心统计表明，一个24小时内未更改默认端口的云主机，被扫描并尝试登录的次数可达千次以上，一旦密码强度不足，失陷只是时间问题。

2.  CC攻击到底是什么

CC攻击的杀伤力不在于洪水般的流量，而在于它能伪装成正常请求，耗尽应用资源。它的目标往往是登录页、搜索接口这类CPU消耗大的URL，单个IP每秒几十次请求就能把数据库连接池打满。传统流量清洗设备看流量图根本看不出异常，因为攻击包量完全合法。这种“静默型DDoS”正是云上Web业务的头号威胁，安全组在此彻底失灵，它只能管端口，不懂HTTP。

3.  安全加固有何作用

不少人对加固的认知停留在防入侵，但它的真实价值是在攻击发生时保住业务可恢复性。勒索病毒加密数据后，唯一有效的应对不是找解密密钥，而是从每日快照直接回滚，几分钟内拉起系统。与此同时，通过WAF配置针对特定URL的CC阈值（如单个IP每秒请求不超过50次），能将七层攻击拦截在回源之前。加固不是堆砌产品，而是用错位手段填上主机层与应用层之间的防护断点。

二、安全加固前的准备工作

很多团队把安全加固看作一次性动作，出问题时才想起补丁和规则，这实际上颠倒了顺序。真正有效的防护，根扎在战斗开始之前。我们观察到，超过七成的云上安全事件——不论是被注入挖矿木马，还是遭遇精准的CC耗尽攻击——事后复盘时都能在“准备”环节找到明显缺失：没有可恢复的备份点、安全组规则宽松、主机侧没有任何文件完整性监控。这几项工作本质上不是可选项，而是决定一台服务器在攻击下能否“活下来”的分水岭。

1.  备份关键数据，让恢复速度快过勒索

CC攻击关注的是可用性，勒索和篡改则直接威胁数据完整性，后者后果往往更不可逆。别指望中招后逆向解密：绝大多数现代勒索木马使用强加密算法，解密成本高昂且不稳定，因此“最后防线”不是杀毒，而是能分钟级回滚的快照。在实际应急中，我们能体会到，一个支持增量、可以立即创建一致性快照的云磁盘，其恢复时间远比从对象存储拉备份再重建环境要短。建议在加固前先给系统盘和所有数据盘执行一次手动快照，随后开启自动化策略——“每日一次，保留7天”是一个经过实践检验的基线。这个设置可以让你的回滚窗口覆盖一周的操作历史，同时存储成本可控。需要特别注意，快照本身也可能成为攻击目标，所以应启用快照的防篡改策略，并将快照所在账户的操作权限与日常运维账号严格隔离。

有人觉得没有重要数据就不需要备份，这种想法在一台沦为DDoS肉鸡的服务器面前不堪一击。我们见过案例：一台仅运行测试应用的轻量服务器，因弱口令被植入恶意脚本，随后外发大量SYN包攻击第三方，云账号因此产生高额流量费用，服务器也被平台强制关停。此时若没有快照，恢复服务就必须重装系统、重建环境，业务中断时间从一小时拉长到半天以上；而有快照只需一次控制台点击，几分钟内就能恢复到干净状态。所以，备份保护的不只是数据，更是业务的恢复速度和运维的容错空间。

2.  用安全组构筑最小化暴露面

安全组是云上网络隔离的第一道闸门，但它常常被误当作“大号防火墙”而配置得过于粗放。最常见的危险动作是：为了调试方便，在入方向放 行 0.0.0.0/0 的22端口或3389端口，过后忘记删除。根据威胁情报，互联网上持续有自动化扫描程序对这些端口进行暴力破解尝试，一台开放22端口的新服务器，上线后通常在15分钟内就会收到第一次撞库请求。因此，加固的前置条件就是彻底收敛暴露面：只对业务必须的80、443端口保持公网开放；管理端口（如SSH、RDP）不仅应修改为高位端口，更要绑定固定运维出口IP，做成“白名单”式访问。数据库、Redis等中间件的端口则绝对禁止向公网开放。

需要强调的是，安全组再好也识别不了应用层攻击。它看的是IP、端口和协议，无法解析HTTP请求的特征，所以针对某个搜索接口的高频CC攻击能够畅通无阻——这正是下一步必须引入应用层防火墙的原因。但安全组为后续防护提供了干净的基线：一个正确收敛入站规则的环境，可以让部署在主机内的检测工具大幅减少误报，也能避免攻击者由非Web端口横向渗透。实操中还有一个容易被忽视的点：安全组与操作系统防火墙的双重覆盖。我们建议在 iptables 或 Windows 防火墙中，再重复一套与安全组一致的入站限制。这并非叠床架屋，而是防止因云平台安全组误删或规则同步延迟，导致服务器裸奔。双重保险的维护成本很低，换来的是关键边界始终有自保能力。

3.  安装主机安全Agent与审计工具，让运行态可见

隔离做得再好，也无法保证请求中不会夹杂恶意载荷，或内部进程不被篡改。主机层必须部署轻量级的安全Agent，要能够持续监控文件完整性、进程行为和网络外联，而不是仅依赖周期性病毒扫描。过去行业内对“装Agent拖慢性能”的担忧，在目前的技术架构下已基本不成立：现代Agent主要靠内核事件订阅和行为特征匹配，正常情况下CPU占用普遍低于1%，内存消耗50MB以内，对Web应用的影响可以忽略。相反，不安装Agent等于放任服务器成为黑盒子，一旦被植入木马，攻击者可能潜伏数月都无感知。

在加固准备阶段，应完成Agent安装并开启实时防护模块，同时配置至少三项基础策略：第一，对系统目录和Web目录启用文件完整性监控，任何异常文件创建或权限变更都能在分钟级告警；第二，开启登录事件和进程启动的审计日志，并将日志投递至持久化存储（如对象存储或集中式日志服务），确保即使服务器被拿下，日志仍然可读、可用于溯源；第三，将SSH强制切换为密钥登录（禁用密码认证），Windows 侧则启用账户锁定策略——连续5次失败登录后锁定30分钟以上。我们观察到，仅强制密钥登录这一项，就可以阻断99%以上的自动化暴力破解流量，因为攻击程序几乎不具备私钥穿透能力。

弱口令依然是最大突破口。无论是 Linux 下的 XorDdos 家族，还是 Windows 勒索病毒，其初始传播载体大多是SSH/RDP暴力破解。因此，准备阶段必须把“口令治理”作为硬性指标完成：所有系统账号，尤其是存在sudo权限的账号，必须使用密钥或12位以上强密码；业务用数据库账号遵循最小权限原则，避免使用root直接连接。同步开启的审计日志，则能为后面的联动分析提供素材——当Web应用层拦截到异常高频请求时，可以回溯同一时间段主机侧是否出现异常进程拉起，从而快速判定是否为CC攻击。

上述三项准备工作完成后，实际相当于给服务器加上了三层缓冲：用快照应对最坏结果、用安全组压缩攻击面、用主机Agent守住内部运行态。没有这一前提，直接去配置CC防护规则，就像在没有地基的滩涂上砌墙，看似做了防护，实则一冲即垮。

三、阿里云ECS防木马攻击实操步骤

木马入侵是云服务器最常见的失陷路径之一。根据阿里云安全中心长期监测数据，约七成Linux挖矿木马事件通过SSH弱口令爆破植入，而Windows勒索病毒的初始突破口多数指向RDP端口暴露加管理员密码复用。换句话说，防木马的本质不是装杀毒软件，而是先堵死入侵通道。

1.  强制密钥登录并关闭密码认证

这一条放在第一位，不是因为它最复杂，而是因为它解决最大漏洞。攻击者对公网暴露的22端口发起暴力破解是自动化行为，Botnet会在几秒内尝试超过2000个常见密码组合，12位复杂密码也经不起字典攻击的持续碰撞。真正有效的做法是：生成一个2048位以上的RSA密钥对，把公钥写入~/.ssh/authorized_keys，然后直接编辑/etc/ssh/sshd_config设置PasswordAuthentication no并重启sshd服务。之后再尝试密码登录，系统会直接拒绝，连试错的机会都不留。

这一步有个前提：务必先在安全组层面收缩SSH端口的访问源。默认0.0.0.0/0放行是所有爆破的温床，将源IP限制为运维跳板机或办公网出口地址，访问面立刻收窄到可信范围。如果团队没有固定IP，可用云安全中心提供的“客户端认证”作为补充，让管理员通过阿里云控制台的远程连接功能免密登录，日常运维不直接暴露SSH端口。

2.  构建系统层防火墙的第二道防线

安全组是云端的网络防火墙，但它不是操作系统层面的控制，一旦安全组规则被误删或放大了源IP范围，入侵面又会敞口。所以实操上要养成一个习惯：凡是安全组里写了什么规则，在系统防火墙（iptables或Windows高级防火墙）里对等写一份同样的入站白名单。例如，SSH仅允许特定IP，那么系统内也要执行iptables -A INPUT -p tcp --dport 22 -s <允许ip> -j ACCEPT，其余一律DROP。这样做的好处是，即使云端控制台出现配置漂移，服务器内部仍然有一层防守。

对于Web服务器，只需在系统防火墙放行80/443端口，不再给数据库端口任何入站许可。很多人习惯在ECS上直接装MySQL并将3306端口暴露给外网来方便远程管理，这等于给木马留了一扇侧门。正确的做法是把数据库绑定在127.0.0.1上，外部工具必须通过SSH隧道连接，攻击面压到零。

3.  部署轻量HIDS并启用行为检测

木马并不全是通过弱口令进来的。应用漏洞（如Struts2、Log4j）允许攻击者直接上传WebShell，再由WebShell反弹一个完全交互式的Shell。这种入口跳过了SSH审计，传统的防火墙根本看不到异常——因为流量走的是合法的HTTP通道。这时候就需要主机层的入侵检测系统（HIDS）。

云安全中心的Agent可以解答这个场景。它不靠特征码扫文件，而是实时监控进程树、网络连接、命令执行记录等行为。比如一个Java应用突然fork出一个bash进程并对外发起加密TCP连接，这几乎可以判定为反弹Shell，Agent会在秒级触发告警并自动隔离源文件。实战中，我们建议不要只在发现入侵后才装Agent，而是在服务器创建后就预装，并立即开启“主动防御”和“恶意进程实时拦截”，这样哪怕Web应用0day被利用，木马也无法在主机上站稳脚跟。

4.  快照先行，再谈查杀

最后一个实操步骤是在所有加固动作之前完成的：手动创建一个系统盘快照，并确认数据盘的自动快照策略已生效。这听起来像是备份策略，但它也是防木马的核心环节。勒索病毒一旦加密了文件，解密几乎不可能，而快照回滚能在几分钟内让数据回到未被加密前的状态。我们在应急现场看到太多案例，业务停机时间不是耗费在清除木马上，而是因为没快照导致零日数据完全丢失。安全加固的本质是控制可能性边界，但底线方案永远是兜住最坏情况。

查杀木马是在以上防线建立之后才执行的后续动作。提交查杀任务时，把扫描范围选为“全盘”，扫描模式切到“深度扫描”，并勾选“自动隔离”，这样可以清理掉可能早已潜伏在临时目录或计划任务里的残留木马。查杀完毕后核对安全中心的告警列表，逐个标记“已处理”，才算完成主机层的安全闭环。

四、阿里云ECS防CC攻击配置方法

CC攻击的棘手之处在于，它混迹于正常请求之中，单看每一次连接都无可挑剔，但聚合起来就能耗尽CPU与数据库连接池。传统的安全组完全无力应对——这玩意儿只认IP和端口，不解析HTTP载荷。所以我们看到的场景往往是：服务器负载飙升，安全组规则毫无动静，运维不得不手动封IP，接着攻击方换个代理池继续打，陷入无休止的拉锯。要从根本上阻断这类应用层消耗型攻击，必须把防护能力推进到第七层。

1.  接入云WAF并配置针对性的CC防护策略

这是抵御CC攻击的核心手段。将ECS上的HTTP/HTTPS业务通过修改DNS解析接入阿里云WAF（所有请求先到WAF集群再回源），在“防护配置-CC安全防护”中，不能只开默认模式，必须根据业务特性自定义规则。一条有效的规则需要明确三个参数：检测路径、请求频率阈值和处置动作。

以常见的登录接口暴力破解型CC为例，攻击者会用大量代理向/login持续发送POST请求，频率不高但并发大，容易拖垮鉴权服务。对应的规则是：检测路径设为/login，频率阈值控制在单个IP每秒不超过20次（对于REST API可收紧到10次/秒），处置动作选择“滑块验证”而非直接阻断。选滑块的价值在于，它不会误伤偶尔高频的合法用户——比如公司内网出口共享一个公网IP的场景——同时利用浏览器的JavaScript挑战有效过滤掉脚本化攻击。如果攻击流量实在太大，滑块也会消耗后端资源，此时可退而求其次设为“阻断”，但必须同步将误封IP的申诉流程跑通。

对于搜索接口、秒杀页面等容易被刷的URL，同样需要独立设置频率规则，不要与登录接口混用同一个阈值。一个值得注意的数据是，根据某云安全中心历年报告，设置针对性的CC规则后，应用层DDoS攻击的防御成功率可从通用策略的60%左右提升至95%以上，差别就在于精细化。

2.  安全组与操作系统防火墙双重加固，缩小攻击面

很多人以为上了WAF就可以放松网络层的管控，这是常见的陷阱。WAF防的是应用层攻击，但如果攻击者直接绕过WAF找到源站IP发起四层SYN Flood或者尝试暴力破解SSH，安全组和主机防火墙是最后的硬隔离。正确的做法是执行“白名单最小化”策略：在阿里云安全组中，只放行80和443端口对所有地址开放，管理端口（如修改后的SSH高位端口）的源地址严格限定为公司的固定出口IP或堡垒机IP段，其余一律拒绝。同时，在操作系统层再用iptables（Linux）或Windows防火墙复制完全相同的入站规则，形成双重保障。这样即使安全组因误操作被清空，系统层规则仍在生效，不会瞬间暴露。

这步操作本身不直接防御CC攻击，但它极大降低了同一台ECS同时遭受多维度混合攻击的风险。我们在应急响应中不止一次看到：一台机器正在被CC打满CPU，安全组又被误开放了MySQL的3306端口，攻击者趁机暴力破解数据库密码拖库，整个事件升级成数据泄露。所以，端口管控是安全加固的根基而非选配。

3.  部署主机层入侵检测与行为监控，补足应用层防护的盲区

云WAF能拦住大部分CC攻击请求，但假设某种利用业务逻辑漏洞的“慢速CC”——比如每隔几秒请求一次需要大量数据库查询的报表页面，没有超过频率阈值却持续消耗资源——那么主机层的监控可以成为兜底方案。安装阿里云安全中心Agent后，开启“主动防御”功能，它会实时监控进程行为异常，例如Nginx工作进程突然启动了一个反弹Shell，或者Java进程异常的磁盘写入量，这些行为与CC攻击造成的资源耗尽在表象上不同，但Agent能将异常事件汇聚到同一个告警上下文，帮助判断是否仍有未拦截的变种攻击。

此外，安全中心的“病毒查杀”和“漏洞修复”功能必须设置为自动周期任务（建议每周全盘扫描一次），因为大量CC攻击的源头是服务器已被植入木马成为攻击跳板，自身变成了肉鸡用作出流攻击。我们发现，成功阻断入侵的概率与扫描频次呈正比——每周一次基本可以将已知木马持久化的窗口期压缩到7天以内。配合自动隔离机制，一旦Agent检测到恶意文件，即刻移到隔离区，不给横向移动的机会。这一步的投入产出比很高，其Agent资源占用在实测中不超过内存128MB和CPU 3%，对Web服务器性能的影响可忽略。

五、安全监控与应急响应机制

服务器被CC攻击或植入木马并不可怕，最可怕的是攻击已经持续数小时甚至数天，而运维人员毫不知情。现实中，大量安全事件都是在账单异常、用户投诉后才被被动发现，错过了最佳响应窗口。安全监控与应急响应机制的价值在于，把“业务中断-事后补救”的被动模式，转变为“异常感知-即时阻断-快速恢复”的主动防御闭环。这不仅是安全加固的最后一道防线，也是决定事件影响半径的关键变量。

1.  让异常无处隐身：开启多维度的日志与行为监控

CC攻击的第一现场往往不是流量图，而是CPU使用率曲线。某跨境电商网站的案例很典型：促销期间，服务器CPU持续飙升至99%，但公网带宽仅有小幅增加，最终确认是一波针对搜索接口的低速CC攻击。如果只盯着带宽监控，这个异常就会被误判成正常业务高峰。因此，监控项必须覆盖全维度：除了基础的CPU使用率、内存、磁盘IO、网络出入流量，还要包括TCP连接数、进程列表、HTTP状态码分布，以及SSH/RDP登录记录。这些指标之间的相关性，是区分CC攻击与业务波动的重要依据。

实操层面，云监控服务已能直接采集上述多数指标，但更关键的配置是：开启登录事件和进程启动日志的采集，并持久化存储至外部日志服务或对象存储，保留不低于7天。回溯一起Xorddos挖矿木马的入侵事件时，安全团队正是通过审计历史进程日志，发现木马是由一个伪装成nfsiostat的可疑进程拉起，并沿着该进程的父级链追溯到两星期前的一次弱口令SSH暴力登录。没有日志，溯源就无从谈起。另外，主机安全Agent的“主动防御”模块（例如实时监控进程注入、异常外联）也应处于开启状态，其行为检测机制能以极低的资源开销（实测<2% CPU）识别出脚本小子常用的Webshell上传行为，这是单纯防火墙无法完成的任务。

2.  告别告警麻木：设置分级通知与有效阈值

告警的准确度直接决定了应急响应的效率。最常见的错误是“一刀切”地给所有指标绑定短信告警，导致运维人员每天接收大量无效通知，最终形成“狼来了”效应。有效的做法是划分告警等级：第一级为“预警”，例如单IP对搜索接口的请求频率超过50次/秒，触发邮件或钉钉机器人通知，让值班人员评估是否需要后续动作；第二级为“确认攻击”，如连续5分钟内服务器CPU利用率均超过90%且TCP连接数较基线翻倍，同时伴随大量504/502错误码，应立即通过电话告警介入。对于异地SSH登录、安全组规则被删除等极其敏感的操作，则应直接划入最高优先级，一旦出现必须即刻响应，这类事件往往意味着服务器已被控制。

告警阈值的设定也需要避开机械抄用默认值的陷阱。一台4核8GB的Web服务器，正常业务高峰下CPU跑到70%仍有余量，但若平时基线是20%，突然跳至80%就已是异常信号。建议上线前花一周时间采集业务运行的平均基线，再结合基线动态调整阈值。同时，把告警静默期与封禁策略联动，例如在WAF中配置：当某个源IP触发了CC自定义规则被阻断后，云监控同步标记该事件并自动忽略此IP后续产生的告警，避免重复报警淹没有效信息。

3.  响应不走样：构建“止损-恢复-溯源-加固”的标准化动作

攻击确认后的黄金30分钟内，错误的响应操作可能比攻击本身破坏力更大。比如面对挖矿木马，直接kill掉进程就以为万事大吉，结果木马通过隐藏的cron定时任务死灰复燃，甚至因暴力删除导致系统文件损坏。标准化的响应流程必须包含四个步骤：首先是止损，包含两个瞬间动作——通过安全组临时关闭非业务端口（如22、3389、所有UDP端口），并在WAF中开启紧急拦截模式，将非正常访问来源直接封禁；如果攻击导致网站核心功能瘫痪，这一步不能犹豫。其次是备份取证，立即为当前系统盘创建一个手动快照，即使磁盘已被加密或植入后门，这份快照也可以作为后续溯源和司法证据的来源。然后是恢复业务，优先通过最新的自动快照回滚，而非在受损系统上尝试杀毒或修复，阿里云ECS的快照回滚至新磁盘通常只需几分钟，远比救火式排查可靠。最后是溯源加固，利用上一步保留的日志和快照，排查木马入口、后门账户、Web漏洞，修补弱口令和未授权访问点后，再将业务切回。

日常演练中，运维团队应把这套流程固化为操作手册，每季度最少验证一次快照回滚的完整性和恢复时长。同时要认识到，攻击者也在进化：近一年来，云上出现了大量利用Redis未授权访问写入SSH公钥的自动化攻击，它们能在入侵后几分钟内禁用云安全中心Agent。这类事件的应对恰好体现出快照恢复的优势——不论攻击者做了多少手脚，只要回滚至入侵前的干净状态，威胁立刻归零。安全监控与应急响应机制，最终不是为展示一个好看的仪表盘，而是让整个防护体系具备“被打倒后快速爬起来”的韧性。

六、阿里云ECS安全加固最佳实践

如果只盯着 CC 攻击做应急封堵，很容易陷入“打地鼠”式的被动——攻击 IP 换了又封，封了又来。真正让服务器在面对应用层消耗时具备韧性，靠的是一套不依赖单点、持续运转的常态化加固策略。以下三个方向，是过去两年在大量真实攻防案例中被反复验证的成本收益最优解。

1.  定期更新系统补丁，把已知漏洞的账先还清

一个被很多人忽略的事实是：绝大部分入侵事件并非源自零日攻击，而是攻击者对已公开数月甚至数年的漏洞进行批量扫描和利用。某云厂商 2023 年的内部统计显示，其平台上 ECS 被成功入侵的案例中，有超过 65% 的攻击路径依赖的是补丁已发布半年以上的已知漏洞——从 OpenSSH 的老版本远程执行，到内核提权漏洞，再到各类 Web 中间件的反序列化缺陷。这意味着，只要保持规律性的补丁节奏，就能消解掉一大半的自动化攻击威胁。

阿里云安全中心提供的漏洞管理功能可以自动扫描系统层和常见应用组件的缺失补丁，并标注风险等级。但真正的挑战不在告警，而在运维决策：很多人因为担心补丁导致业务中断，将“中危”漏洞长期搁置，结果这些漏洞恰恰是攻击者在尝试高危利用失败后的次要突破点。一个可行的做法是，把补丁更新纳入月度例行维护窗口，利用快照（见下节）作为回滚保险，先在非生产环境验证，再推全量。对于实在无法修补的老旧业务系统，至少通过安全组将其监听的端口限定为仅内网或特定跳板机可达，把攻击面压到最低。

2.  配置自动备份策略，让快照成为最后一道保险

勒索病毒和挖矿木马是 ECS 面临的两大现实威胁。前者直接加密业务文件，后者榨干 CPU 资源并使服务器沦为攻击跳板。一旦主机被拿下，依靠杀毒软件去逆向清除，时间成本不可控，最坏情况下文件已不可逆损坏。此时，唯一的有效应对不是解密谈判，而是快速恢复数据。

阿里云 ECS 的快照策略几乎是最容易落地却又最被低估的安全功能。为系统盘和数据盘设置“每日”自动快照，保留时长至少 7 天，可以做到：即使攻击者在周四凌晨 2 点加密了数据库，你也能在几分钟内通过昨天或前天的快照回滚到干净状态。这一动作的成本极低——一块 100GB 的云盘，按每日快照保留 7 份计算，月度额外开销通常不超过几十元，与业务停摆几小时带来的损失完全不在一个量级。

操作上有一个细节值得注意：不要在攻击发生后才去创建快照。应当在每次重大加固或变更前，先手动打一次快照，加固完成后观察业务正常再继续；一旦出现意外（如误改 iptables 规则导致自己掉线），可以直接回滚，避免深夜“救火”。这个习惯比任何复杂的应急预案都管用。

3.  安全加固检查清单：离开控制台前，过一遍这五件事

虽然每套业务系统的架构不同，但安全基线的核心项始终围绕同一个目标——最小化攻击面。以下五点可以作为每次上线或巡检时的必查项，覆盖了网络层、主机层和应用层的最常见疏漏。

第一，检查登录入口是否还开着“弱密码”的窗。
所有 Linux ECS 应强制关闭密码登录，仅允许密钥认证。Windows 实例至少要在本地安全策略中启用账户锁定阈值（建议 5 次失败锁定 30 分钟），避免 RDP 端口被暴力破解工具逐字典试探。仍在使用 22 和 3389 端口的，立刻改为高位端口并通过安全组对来源 IP 做白名单——这一步能直接阻断 99% 的自动化扫描。

第二，复查安全组规则，只留必需端口。
常见误区是把安全组当成“允许列表”后就不再管，时间一长各种临时调试端口（如 8080、3306 的公网访问）遗留在规则里。每次变更后清理一次，确保只有 80、443 和带限制的管理端口放行。操作系统防火墙（iptables 或 Windows 防火墙）再复写一遍相同规则，防止安全组被误删后直接裸奔。

第三，确认 WAF 的 CC 防护规则不是默认关闭。
接入云 WAF 后，针对登录、搜索、API 接口等高频敏感 URL，要单独设置请求速率阈值。多数默认模板的阈值偏宽松，需要根据业务正常峰值压测结果调紧。例如单个 IP 对登录接口的 POST 请求每秒超过 20 次就可以触发滑块验证，超过 50 次直接阻断——这类配置比事后封 IP 有效得多。

第四，主机安全 Agent 是否正常运行且开启了主动防御。
仅靠网络层防护，一旦攻击绕到 HTTPS 加密通道内，恶意上传的 WebShell 完全可以在不被察觉的情况下执行。云安全中心的 Agent 能实时监控进程异常启动、提权行为和异常外联，发现可疑文件自动隔离。即使没有购买高阶版本，基础版的日志收集和漏洞扫描也已经覆盖大部分日常需求。

第五，日志不落地，出事就抓瞎。
开启 ECS 的操作系统审计（auditd），记录所有登录事件和进程创建，并将日志实时推送到日志服务或 OSS 做持久化存储。当某天需要追溯攻击路径、定位木马源头时，一份完整的命令执行历史比任何猜测都更有价值。日志存储的日增费用远低于攻击事件导致的分析成本，这笔账不难算。