凌晨出现一条Failed password要不要立刻封IP如果这是员工输错了一次密码直接封禁会制造业务故障如果同一来源正在轮询几十个账号只看单条日志又会低估风险。日志研判的基本单位不应该是一行文字而应该是一个时间窗口内的行为序列。先找到正确的日志来源不同发行版和配置的SSH日志位置并不完全相同。Debian、Ubuntu常见/var/log/auth.logRHEL系传统配置常见/var/log/secure使用systemd journal的主机可以从服务日志查询。服务单元名称可能是ssh或sshd先确认本机实际名称systemctl status ssh systemctl status sshd再查看最近一小时sudo journalctl -u ssh --since 1 hour ago sudo journalctl -u sshd --since 1 hour ago两条命令通常只有一条适用。不要因为某个文件不存在就认定系统没有记录也不要同时把journal和文本日志的同一事件统计两遍。常见信号包括Failed password、Invalid user、Accepted publickey和Accepted password。不同OpenSSH版本、认证模块和本地化设置会改变字段正式分析前要先查看本机样本不能盲目依赖固定列号。单条失败的解释空间很大一条失败记录至少包含时间、来源IP、目标用户名、来源端口和认证方式。但这些字段单独看都不足以下结论。员工输错密码通常表现为来源接近正常办公出口目标账号真实存在短时间失败一两次后成功时间也符合工作行为。自动化扫描更常见的表现是频率稳定、用户名不断变化、来源分散或持续时间很长。这只是经验特征不是绝对规则。攻击者也会低频尝试办公出口也可能已经失陷。因此研判要组合多个维度。五个维度把事件串起来1. 时间密度统计1分钟、5分钟和1小时窗口内的失败次数。短时间几十次尝试与偶发一两次的风险不同持续数天的低频尝试也不能被每分钟阈值漏掉。2. 来源分布看同一IP攻击多少账号也看同一账号被多少IP尝试。前者像单点扫描后者可能是分布式口令喷洒。还应结合企业VPN出口、跳板机和已知运维地址白名单避免把共享出口误判成大量独立用户。3. 用户名模式连续出现admin、test、oracle、git等并不存在的账号通常更接近自动化枚举。只针对一个真实账号的尝试则需要结合身份系统、值班记录和账号敏感度判断。4. 失败之后是否成功最值得关注的序列之一是同一来源多次失败随后出现成功登录。还要检查成功使用的是密码还是公钥、登录账号是否具备sudo权限以及该来源过去是否出现过。失败后成功并不自动证明入侵但它值得升级调查。反过来“全部失败”也不代表无需处理因为持续扫描会消耗资源并暴露公开攻击面。5. 登录后的动作关联sudo、账号变更、计划任务、服务启动、异常下载和新网络连接。SSH只是入口真正决定事件严重度的是登录后的行为。时间线应统一时区并考虑日志延迟和主机时钟偏差。不要用脆弱的一行命令代替分析网上常见用awk固定取第9列作为IP的做法但Invalid user与Failed password for root的字段位置可能不同。更稳妥的方式是使用日志平台的解析规则或者先匹配消息类型再按对应格式提取字段。临时人工排查可以先保留原始行sudo journalctl -u sshd --since 1 hour ago \ | grep -E Failed password|Invalid user|Accepted (password|publickey)这条命令只用于缩小阅读范围不应直接作为生产告警逻辑。生产环境应保留原始日志、解析失败计数和规则版本避免OpenSSH升级后悄悄漏报。响应动作要与证据匹配确认明显自动化尝试后可以组合使用关闭不必要的公网SSH入口通过VPN、堡垒机或安全组限制来源优先使用公钥认证停用不需要的密码登录禁止root直接远程登录使用速率限制或Fail2ban降低重复尝试对成功登录和权限提升建立关联告警。封禁单个IP只是临时止血不是完整方案。攻击来源可以快速变化真正有效的是缩小暴露面、提高认证强度并完善成功登录后的监测。最后给告警加一个可解释的结论在哪个时间窗口、哪些来源、尝试了哪些账号、是否出现成功、成功后做了什么。这样的记录才能支持值班交接和后续复盘而不是留下一句“疑似爆破”。如果你正在练习蓝队运营、日志分析或应急响应可以用这五个维度给自己的实验日志建立一张研判表。对应的系统课程学习入口可在这里查看。