云主机ssh被爆破后怎么办？从告警到加固的完整思路

云主机ssh被爆破，是很多运维团队都会碰到的事。起初看起来只是日志里不断刷新的失败登录，吵归吵，业务也许还没出问题，但这类告警不能长期放着不管。处理慢了，后面可能发展成账号被撞开、挖矿程序落地、业务响应变慢，甚至把部署脚本、密钥和内网连接信息一并带走。

中小企业、个人开发者、初创团队尤其容易踩这个坑。云主机往往一台机子挂着官网、接口服务、数据库转发或者内部管理后台，SSH又直接暴露在公网。只要22端口开着，root允许直登，密码策略偏弱，没有密钥认证，也没有失败登录封禁和基础告警，攻击脚本就会一直试。很多人上线后忙着交付，很少回头看/var/log/secure或/var/log/auth.log，等发现时，攻击者可能已经进来过了。

什么是SSH爆破，为什么云主机经常被扫

SSH是Linux服务器最常用的远程管理协议。所谓爆破，通常就是攻击者用脚本配合字典库，从公网批量尝试常见用户名和密码组合，比如root、admin、ubuntu这类账户，再配合代理IP不停发起登录请求。

云主机容易成为目标，原因很现实。公网IP能被批量扫描；云环境部署快，很多机器沿用默认配置；攻击成本又低，攻击者也不需要专门盯着哪家公司，扫到能进的就够了。所以，云主机ssh被爆破不代表你被重点盯上，但它说明这台机器已经进入公开攻击面的日常扫描范围。

一个常见场景：从失败登录到挖矿驻留

有些团队会把测试环境直接放在云主机上，22端口对外开放，方便远程维护。为了省事，root密码登录一直留着，密码不算特别简单，但很久不换，也没做失败登录封禁。刚开始日志里只是零散出现失败登录，没人把这件事当成故障处理。过了一段时间，告警平台开始提示CPU长期接近100%，接口响应变慢，排查才发现问题已经不只是“有人在试密码”。

这种情况下，常见结果是攻击者在某次爆破成功后登录系统，下载并启动挖矿程序，再新增隐藏账户、写入定时任务维持驻留。如果这台主机上还放着部署脚本、环境变量或者内网连接配置，风险就会继续扩大。最后往往只能下线主机、重建环境、轮换相关密钥，恢复成本比前期做加固高得多。

麻烦的地方在于，日志很吵不一定已经失陷，但一旦成功登录，后续动作通常非常快。自动化工具几分钟内就能完成下载恶意程序、植入后门、修改计划任务这些步骤。你看到CPU飙升时，往往已经晚了一拍。

先判断：云主机ssh被爆破到了哪一步

处理这类事件，别一上来就只顾着封IP。先分级判断，后面的处置才不会跑偏。

只有失败登录，暂时没有成功记录

如果日志里大量出现“Failed password”“Invalid user”，但没有“Accepted password”“Accepted publickey”之类的成功记录，通常还停留在尝试阶段。这时重点是尽快收紧入口，把攻击面缩小，别给对方继续试的时间。

已经出现异常成功登录

看到陌生IP成功登录，尤其是非工作时段、非常用地区、非常见账号，就不要再把它当普通噪声。哪怕业务暂时正常，也应该按入侵事件处理。很多恶意程序会先潜伏，不会立刻把机器拖慢。

资源和系统状态也开始异常

如果同时出现CPU飙升、带宽异常、陌生进程、新增账户、crontab多了任务、登录历史异常，基本就能判断主机已经被利用。这时候只改SSH密码远远不够，必须把进程、账户、计划任务、启动项、授权密钥一起查。对核心业务主机来说，很多时候直接重建比在原机上“排毒”更稳。

云主机ssh被爆破后的处置顺序

实操里，顺序很重要。建议按“先止血，再确认，再清理，再加固”来做。

先止血：把入口收紧

• 立刻在云防火墙或安全组里限制22端口来源，只保留办公出口IP、VPN出口或堡垒机IP。平时谁会登录，就只给谁留入口。
• 如果业务允许，临时关闭公网SSH入口，改用控制台或带外方式登录，先把持续爆破停下来。
• 异常来源IP可以封，但别把封IP当主要方案。爆破常常是分布式的，IP会换，今天封掉一批，明天还是会来。

再确认：判断是否已经进过系统

• 查/var/log/secure或/var/log/auth.log，重点看成功登录和失败登录。失败次数能反映攻击强度，成功记录更关键。
• 用last、lastb、who、w核对近期登录来源和时间段，非工作时间的成功登录要单独拎出来看。
• 检查是否多了新用户、异常sudo记录、陌生的SSH公钥，尤其是~/.ssh/authorized_keys有没有被改。
• 顺手排查计划任务、开机启动项、可疑进程和异常网络连接。很多后门会通过计划任务反复拉起，不会只靠一个进程持续运行。

怀疑失陷时，优先保全业务和凭据

• 立即修改系统密码，并轮换和这台主机有关的数据库密码、API密钥、部署令牌。主机一旦失陷，风险不只在系统本身。
• 检查应用配置文件、脚本仓库、环境变量，看看敏感信息有没有暴露可能。很多团队把密钥直接写在配置里，这一步不能漏。
• 如果主机承载核心业务，先备份必要数据，再基于可信镜像重建实例。别把已经不可信的系统继续当生产环境用。

清理后门时，不要只盯着一个挖矿进程

看到挖矿进程就直接kill，这是常见误区。攻击者通常会留不止一个入口，比如authorized_keys、隐藏账户、cron任务、下载脚本，或者伪装成正常服务的驻留程序。你删掉一个进程，系统重启后它可能还会回来。

如果已经确认被入侵，更稳妥的做法通常是重建主机。云环境的优势就在这里：可以快速起新实例，按标准配置重新部署，再把业务切过去。和在一台可信度存疑的机器上反复清理相比，重建的风险更可控，审计边界也更清楚。

怎么从根上降低云主机ssh被爆破的风险

防护别押在单一工具上，SSH安全要靠几层措施一起做。

关闭密码登录，改用密钥认证

这一步很直接，也很有效。禁用SSH密码登录后，常见的弱口令爆破基本就失去入口了。前提是私钥要妥善保管，最好再给私钥加口令保护，不要把密钥文件随手丢在多人共用设备里。

禁止root直接远程登录

把root直登改成普通用户登录后再sudo提权，能减少高权限账号被直接命中的概率，也方便审计到底是谁做了什么操作。多人共用root，本身就不利于排查问题。

修改默认端口可以做，但别指望它挡住攻击

改SSH默认端口能过滤掉一部分低质量扫描，日志会干净些，算是降噪。可这不是主防线，扫描工具照样能找到端口。真正能拦住问题的，还是访问来源控制、密钥认证和失败登录封禁。

启用失败登录封禁机制

用Fail2ban这类工具，根据短时间内多次失败登录自动封禁IP，能明显减轻爆破强度。配合云防火墙策略一起用效果更好。这里有个提醒：封禁时间、匹配规则要结合业务设，别把正常运维误封进去，尤其是多人共用出口IP时。

SSH入口尽量只对固定来源开放

如果运维人员的网络出口固定，或者已经有VPN、堡垒机，那就没必要让SSH面向整个公网。很多企业的SSH本来就不需要任何人随时从外网直接连上去，安全组收紧后，暴露面会立刻小很多。

补上最基本的审计和告警

至少要盯住几类信号：登录失败次数突然增加、成功登录来源发生变化、CPU和带宽异常、系统新增用户、计划任务被改。很多事故前面其实已经给过信号，只是没人及时看见。

适合中小团队落地的加固清单

1. 把安全组改成仅允许固定IP访问SSH；如果办公网络不固定，就统一走VPN或堡垒机，不要继续全网开放22端口。
2. 禁用root直登，关闭密码认证，统一切到密钥登录；做变更前先留一个可验证的回退方式，避免把自己锁在门外。
3. 配置Fail2ban或同类封禁策略；上线后实际做几次失败登录测试，确认规则确实生效。
4. 定期更新系统和OpenSSH版本；补丁窗口别拖太久，测试环境和生产环境都要管，不要只盯生产。
5. 做最小化安装，清掉不用的账户和服务；机器上跑的东西越少，暴露面越小，排查也更快。
6. 把日志集中存储；主机一旦被入侵，本地日志可能被删，外部留存的日志才方便事后核查。
7. 定期轮换高权限凭据和密钥；尤其是多人接触过、曾经写进脚本或配置文件的凭据，不要长期不换。
8. 准备标准化重建脚本或镜像模板；真出事时，能快速起一台干净机器，比在故障主机上临时修补靠谱得多。

云主机ssh被爆破几乎算公网Linux主机的日常噪声，但“常见”不等于“可以忽略”。日志里的失败登录，往往会把弱口令、root直登、入口暴露过宽、缺少审计这些问题一起暴露出来。平时把SSH入口收紧，认证方式换掉，告警补上，很多风险在前面就能压住。

如果已经出现异常成功登录，就别再抱着“业务还没挂，应该问题不大”的心态。按入侵事件处理，该轮换凭据就轮换，该重建主机就重建。对运维来说，云主机ssh被爆破并不可怕，怕的是把它当成普通噪声，直到机器真的被接管才开始补救。