云服务器被攻击后的安全加固关键动作，从源头大幅降低二次被黑风险2026

摘要生成中

AI生成，仅供参考

赶到现场（其实就是自己的出租屋电脑桌前），先拉了控制台的远程桌面和临时跳板，然后用阿里云的一键网络隔离先把它和主负载均衡器断开，这是最紧急的一步——不能让攻击蔓延到其他集群，也不能让异常流量再耗我们的带宽和算力费。当时慌得一批，差点把快照隔离搞成彻底停机备份，幸好前几天刷同行社群的时候看到过有人踩过这个坑，彻底停机后要恢复快照得走审核流程，至少半小时，中小团队哪耗得起这个。

这次攻击排查下来，发现入侵路径特别简单——root账号没有禁用密码登录，用的还是3年前机房淘汰下来的通用密码“server2023”，有不少端口（比如22、3306、8080的备用管理端口）直接暴露在公网0.0.0.0上，甚至连fail2ban都没装。说实话，刚入行的时候我自己也犯过一半的错，root用通用密码就算了，还懒得改ssh端口，熬了整整一个通宵扫后门查日志，最后发现是弱口令被扫中的。

这次加固完集群节点，我整理了几个真的能从源头掐断二次入侵的动作，不是网上随便搜的那种凑数的100项加固，只挑生产环境里入侵概率最高、落地最快的来：

第一个动作是永久禁用root的远程密码登录，换成ssh密钥对登录+普通用户提权。具体操作的话，先在本地用ssh-keygen生成一对RSA 4096位的密钥（别用2048位了，2026年很多安全扫描工具已经把弱密钥（包括RSA 2048）列为潜在风险），然后用ssh-copy-id把公钥传到服务器的普通用户下，比如我们常用的devops用户。传完后记得测试一下能不能用密钥登录，别直接就禁用了密码和root远程。没问题的话，编辑/etc/ssh/sshd_config文件，把PermitRootLogin改成no，PasswordAuthentication改成no，PubkeyAuthentication改成yes，然后重启sshd服务，systemctl restart sshd。重启完再试一下能不能用root密码或者公钥以外的方式登录，应该直接拒绝了。

第二个动作是只允许白名单IP访问非业务端口，比如22、3306。中小团队没有硬件防火墙的话，直接用云服务商的安全组就行，这个操作比iptables简单，而且不容易写错。阿里云的话，就是在ECS实例的安全组里，删除原来的0.0.0.0/0访问22、3306的规则，然后添加自己公司的固定公网IP（比如用curl cip.cc查出来的公司网关IP）、家里的动态公网IP（如果是电信或者联通的话，可以申请免费的DDNS，比如花生壳或者阿里云DDNS，避免IP变了登不上）、还有负载均衡器的内网IP访问3306的规则，其他非必须的端口全部关闭。如果是自建机房没有安全组的话，才用iptables或者firewalld。

第三个动作是每天凌晨自动更新系统高危漏洞补丁，同时安装fail2ban暴力破解防护工具。自动更新补丁的话，CentOS 7可以用yum-cron，Ubuntu可以用unattended-upgrades，只更新security级别的补丁就行，别更新全量的，容易导致业务依赖的库出问题。以CentOS 7为例，先安装yum-cron，yum install -y yum-cron，然后编辑/etc/yum/yum-cron.conf文件，把update_cmd改成security，update_messages改成yes，download_updates改成yes，apply_updates改成yes，然后启动yum-cron服务，systemctl start yum-cron && systemctl enable yum-cron。fail2ban的话，CentOS 7需要先安装epel-release，yum install -y epel-release，然后再安装fail2ban，yum install -y fail2ban，默认配置就可以，默认是10分钟内尝试5次登录失败就封禁IP 10分钟，封禁的时间和次数可以自己在/etc/fail2ban/jail.local里改。

对了，还有一个新手特别容易忽略的避坑提醒，就是加固之前一定要先给服务器做一个全量快照，而且要给快照加个保留期，比如保留3天，加固过程中如果不小心删了什么配置或者改坏了什么文件，可以直接回滚快照。上个月刚处理过另一个公司的求助，就是新手加固的时候直接把sshd_config的配置改坏了，重启sshd服务失败，又没有快照，最后只能通过云服务商的救援模式进去修复，折腾了快2小时。

还有一个避坑提醒，就是加固之后一定要定期（比如每周）检查一下服务器的安全状态，用云服务商的安全体检工具（比如阿里云的安骑士基础版）扫一下漏洞和后门，看看有没有陌生的进程在运行，看看/var/log/secure日志里有没有异常的登录尝试，看看fail2ban有没有封禁到大量的IP。别以为加固完就万事大吉了，黑客的手段每天都在变。

说实话，中小团队的运维资源本来就少，不可能像大厂那样做全链路的安全防护，但只要把这几个关键动作做好，90%以上的常见入侵都能防住，从源头大幅降低二次被黑的风险。

你们在运维工作中有没有遇到过类似的弱口令被黑或者端口暴露的坑？欢迎在评论区分享你的排查经验和加固方法。