Linux华为云ECS安全加固教程：服务器防攻击配置详解

一台刚上线的华为云ECS，在公网暴露不到半小时就可能被扫描工具标记，SSH端口随即遭遇高频字典攻击。这篇Linux华为云ECS安全加固教程不堆砌理论，而是从真实攻防场景出发，拆解一套可落地的配置逻辑——你不需要成为安全专家，只要按步骤收紧几个关键环节，就能让攻击成本上升到对手主动放弃。

本文由 国内云代理商『聚搜云 JuSouYunClouD -服务器服务商•撰写』如需转载请注明！

为何需要安全加固

运维圈有个残酷事实：没有做过安全加固的Linux云服务器，存活状态取决于攻击者发现它的速度。安全加固不是“修修补补”，而是把攻击面压缩到最小，让系统只暴露必须暴露的，其余一律拒绝。这背后需要明确的威胁认知、清晰的加固目标，以及避开几个让加固失效的典型陷阱。

安全组规则够严就没事了吗？

一个常见错觉是把安全组当万能墙。我们在排查客户事故时发现，设置了“全放行22端口”的安全组，意味着全球任意IP都可以尝试SSH登录，相当于把大门密码交给所有人猜测。安全组在云平台入口过滤，但不防来自同一VPC内其他被攻破主机的横向移动，也不解决操作系统层面的弱口令或服务漏洞。真正有效的防线应该是“安全组 + 主机防火墙（firewalld/iptables）+ 入侵防御（Fail2ban）”三层叠加，每层覆盖不同的攻击维度，缺一层就多一个破口。

常见威胁里，什么方式最容易被忽略？

公网扫描和暴力破解几乎成了背景噪声，攻击者常用工具对22、3306等端口发起字典攻击，密码弱一点，几分钟就沦陷。这些可以靠密钥登录和端口变更暂时挡住。更棘手的是利用未修复漏洞的渗透——比如一个遗留的Web应用漏洞被getshell后，攻击者在主机内部操作，安全组和外部防火墙完全看不见。及时发现和堵住这类内部威胁，依赖的是主机安全（HSS）的异常行为检测、定期补丁更新以及日志审计。我们在多个恢复案例中看到，攻击者留后门后潜伏几周，只等抓到关键数据才收网，没有日志留痕就无从溯源。

加固目标到底要达成什么状态？

加固不是把系统锁死，而是在可用性与安全性之间找平衡。一个可量化判断的标准：只对业务必需的服务、端口和来源IP放行，并且每个登录入口都有验证失败次数的自动封禁。例如SSH只对办公出口IP开放，配合Fail2ban设置3次失败封禁30分钟，既不影响运维，又能阻断99%以上的自动化攻击。最终目标是你看到云监控报警时，能快速定位攻击路径并隔离，而不是接到通知才发现数据已加密勒索。

加固准备工作

在动手调整配置之前，有经验的运维通常会先花上半天完成实例选型、基线设定与备份策略这三件事。它们本身不复杂，但任何一步出现疏漏，都会让后续的规则配置变成“在沙子上盖楼”。下面的步骤结合了华为云 ECS 的默认能力与 Linux 原生工具，目标是用最少的操作换取最高的初始防御水位。

选择合适实例

创建 ECS 时，很多用户只关心 vCPU、内存和带宽，却忽略了实例自带的防护开关。以华为云为例，同一订单流程中可顺势开通云监控（CES）和主机安全（HSS）基础版——前者对 CPU、内存及网络异常进行分钟级告警，后者能自动识别弱口令、漏洞及异常登录。这并非锦上添花，而是让服务器一上线就运行在默认安全基线下。若等业务跑起来再补装，往往会因服务中断而一再推迟，最终留下长达数日的裸奔窗口。

设置安全基线

基线配置的要义是“先收紧再逐个放行”。安全组应直接删除“出方向全部放行”以外的所有默认规则，手工添加入方向白名单：仅对特定的办公出口 IP 开放 22 端口，对公网仅开放 80、443，其余一律拒绝。据多家云厂商公开观测数据，一台开放密码登录的新 ECS，在公网上线后不到 30 分钟就会遭遇来自数十个 IP 的 SSH 暴力扫描，24 小时内平均试探次数超过 200 次。因此，完成安全组限制后，务必立刻创建密钥对并登录验证，待密钥成功后修改 /etc/ssh/sshd_config 将 PasswordAuthentication 设为 no。同时务必保留华为云管理控制台的 VNC 或 CloudShell 通道，防止因误配导致自己被锁在门外。

制定备份策略

多数人的备份意识是在第一次误删数据后才觉醒。建议利用云盘快照功能设置自动策略，系统盘保留最近 7 天的快照、数据盘按业务频率至少一周一备——这一配置对中小站点几乎没有额外成本，却能规避大多数人为操作风险。此外，/etc 目录下的核心配置文件、数据库定时备份应打包上传至同一地域的对象存储桶，保证异地容灾。每次执行 yum/apt update 或内核升级之前，必须先生成一个系统盘快照并验证可用。当攻击事件发生时，第一反应不是登录进去查日志，而是先在安全组里将可疑实例隔离，再基于干净快照恢复，这样既保护了现场，也避免了带毒排查。

系统层安全配置

更新系统补丁

不更新补丁的服务器就像一个不锁门的院子，迟早会出事。2024年某中型电商曾因 OpenSSH 漏洞（CVE-2024-6387）被入侵，根因就是延迟了三周的补丁没有打。华为云 ECS 默认镜像已屏蔽大部分高危漏洞，但运行环境中的第三方源仍需手动维护。我们的建议是：不要用 yum -y update 一次性全量升级，应先在测试环境验证兼容性，再利用华为云控制台的快照功能给系统盘做秒级备份。真正打补丁时，把维护窗口固定在业务低峰期，并提前通过云监控设置异常告警。这样做既能堵上漏洞，也不会把业务“更新”到停机。

配置安全组规则

安全组是云上第一道防火墙，但最常见的错误是把 22 端口对 0.0.0.0/0 全局开放。去年一家受攻击的外贸企业，其安全组放行了 22、3306 且未限制来源 IP，结果 SSH 日志一天内被来自 17 个国家的扫描器触发达 12 万次。正确做法是：仅对办公出口 IP 放行运维端口，Web 端口 80/443 才面向公网，其余全部拒绝。对于缺少专职安全人员的中小团队，与其在几十条规则里反复试错，不如先启用云平台的基础防护模板，再找像 XX 这类服务商做一次整体评估，通常能在几小时内收敛暴露面。ECS内部再配合 firewalld 做主机层隔离，形成双保险。

禁用密码登录

SSH 密钥登录是消灭暴力破解最直接的手段，但也是实操中翻车率最高的环节——总有人配置完 PasswordAuthentication no 才发现密钥未导入或权限错误，自己彻底被锁在外面。正确的顺序是：先用 ssh-keygen 生成密钥对，通过华为云控制台上传公钥，并在一个会话中保持登录，另开终端测试密钥认证成功，再修改 /etc/ssh/sshd_config 关闭密码认证。如果意外锁死，不要重启服务器，立即通过云平台自带的 VNC 或 CloudShell 进入系统回退配置。改完后重启 sshd 服务，并保留最少半小时的观察窗口，确保一切正常才算完成。

防火墙与入侵防御

安全组只是云上流量过滤的第一道闸门，真正能让防御落地的往往是主机层的精细化控制和自动化响应。在华为云ECS的加固实践中，大量入侵事件都源于“安全组放行了一切，而操作系统内部却毫无设防”的真空地带。

配置firewalld：与安全组形成互补

不少管理员认为配完安全组就算收工，但安全组不防同一VPC内的横向移动，也无法感知服务级的异常。实战中应在系统内部用firewalld再做一次入站收紧：将SSH监听端口改至高位，并在firewalld里仅对运维出口IP放行，公网端只留80/443。根据多家云平台安全团队观测，非标端口可使自动化扫描量骤降九成以上，但改端口本身不算安全，必须与密钥认证和Fail2ban配合。

安装Fail2ban：让暴力破解不再“无限试错”

Fail2ban的核心价值在于把日志异常实时转化为防火墙动作。针对SSH，在jail.local中设maxretry=3、bantime=600s，三次试错即封禁10分钟，配合自定义动作还能封禁IP段。某跨境电商就曾因弱密码账号长期裸奔被撞破，数据库遭加密勒索，事后复盘发现仅差一套Fail2ban规则。日志中累积的封禁记录，也是后期攻击溯源的重要资产。

使用云安全服务：别拿开源工具当万能解

开源组件灵活，但离闭环防御还差一截。华为云ECS创建时可勾选主机安全（HSS）基础版，免费获得弱口令检测、资产指纹和基线扫描，能自动暴露端口敞口、高危漏洞等配置问题，省去大量人工巡检。对付大流量攻击，DDoS高防通过与云监控（CES）联动，可在带宽异常时自动牵引清洗，避免几GB小流量就冲垮业务。对于没有专职安全运维的团队，把加固和监控打包交给服务商做整体实施，往往比自行拼凑工具链更可靠。

华为云防攻击配置

启用DDoS高防

云上业务一旦暴露在公网，大流量攻击就可能直接耗尽带宽，导致正常用户无法访问。DDoS高防的做法是把访问流量先牵引到华为云分布的清洗中心，过滤掉攻击报文后再把干净流量回注到源站。这项服务能扛住百Gbps级别的瞬时峰值，对于电商、游戏等对中断敏感的行业，要比单纯扩展带宽性价比高得多。启用后需留意业务真实IP的保护，避免绕过清洗节点直连源站。

配置云监控告警

单靠人工盯盘很难在攻击初期发现异常，云监控（CES）的告警规则应当作为第一道感知线。在实际操作中，建议对实例的入网带宽、CPU利用率和磁盘读写次数分别设置阈值，一旦连续几个采样周期突增就触发短信或邮件通知。这样做的好处是，哪怕是被CC攻击导致CPU打满，或是数据外传的异常行为，都能在几分钟内介入，而不是等业务瘫痪后才回看日志。

结合网络ACL

安全组管到实例，网络ACL管到子网，两者叠加才能形成纵深过滤。在华为云的控制台上，可以给关键子网绑定ACL规则，按协议和IP段做无条件拒绝，优先级比安全组更高。比如发现某IP段持续扫描SSH端口，直接在ACL里加一条黑名单，就能把恶意流量挡在虚拟网卡之外。这套组合拳在应对端口扫描和蠕虫传播时效果明显，也能防止内部横移的一环。

持续监控与响应

安全加固从来不是一次性动作，上线的策略在真实攻防数据冲刷下才能暴露疏漏。根据多家云厂商安全团队分享的数据，超过70%的入侵事件在事后溯源时发现，早期迹象已完整记录在日志中，却因缺乏实时分析而被忽略。这直接把“看得见”和“跑得快”拉到同等重要的位置。

日志审计方法

单靠操作系统默认的rsyslog只能做到日志落地，离可用的审计体系还有距离。比较务实的做法是把SSH、历史命令、防火墙拒绝记录等关键维度统一到一套集中日志平台中，例如ELK或者以SaaS形式提供的日志服务。需要明确地设置日志保留周期——从法律法规和实战经验来看，至少保存180天。如果手头资源有限，可以先启用华为云日志服务（LTS）这类云原生工具做关键日志转储和关键词告警，避免本地磁盘被打满直接丢弃事件记录。

定期安全评估

半年度或大版本上线前的评估不应只是“扫一遍端口”。真正有价值的评估必须要组合外部扫描和内部核查：用开源的Lynis做合规基线检查，用Nmap从公网审视安全组实际生效规则，同时核对操作系统内部防火墙链是否与云平台安全组策略形成互补而非冲突。2024年某SaaS厂商的事后复盘就表明，端口被攻破恰恰是因为内部防火墙链没有同步更新IP白名单，外部的安全组“孤军防守”留下缺口。这类检查结果最好形成清单，逐项消缺，而不是看完即过。

应急响应流程

应急响应的第一条原则不是查日志，而是先控制影响面。确认异常的第一时间，优先在安全组里对涉事实例做最小化访问隔离，只保留管理IP的带外通道，再启用云监控（CES）的报警历史回溯异常时间窗口。预置好的快照和异地备份在此时决定恢复速度——有团队习惯依赖实时快照做回滚，但别忘验证快照可用性，实战中损坏的快照比预期常见得多。至于事后复盘和溯源，必须要拿到完整的请求日志和进程审计记录，否则很难区分是脚本小子的漫扫还是定向攻击。

最后有一个很容易被忽视的成本问题：把监控、审计、评估和响应闭环跑起来，需要的不只是工具，还有懂得这些工具协同的人。如果团队里运维人手捉襟见肘，与其放任规则配置长期不检查、告警无人处置，不如找具备一站式服务能力的服务商做一次整体评估和托管，反而能把更多精力放回业务本身。