先找成功登录，再核对账号和来源
# Alpine 常见日志位置；实际路径以 syslog 配置为准 grep -E 'sshd.*(Accepted password|Accepted publickey|Failed password)' /var/log/messages # 使用 systemd 日志的环境，服务单元名称可能是 ssh 或 sshd journalctl -u sshd --since '2026-11-05 00:00:00' --no-pager
上面的日期只是查询示例，应按主机实际暴露期和日志保留情况扩展；补丁发布日期不是最早可能遭遇异常的时间。还要检查轮转日志、集中日志、云审计和堡垒机记录，并统一时区。重点关注不应使用密码的账号却出现成功密码登录、未知来源的成功登录，以及随后出现的 doas、sudo 或账号权限变化。失败记录不代表入侵成功，没有记录也不能证明安全。Alpine 官方调查提示
发现可疑成功登录后
- 保留必要的管理通道，在网络侧隔离可疑实例并保全日志、快照与时间线。
- 核对账户、授权密钥、定时任务、启动项和服务配置，结合发布记录区分合法变更。
- 如确认凭据可能泄露，从可信设备撤销旧凭据并轮换相关密钥或令牌。无法证明原实例可信时，从修复后的干净镜像重建，只迁移经检查的数据。
- 记录异常账号、来源、时间、受影响资产、修复版本和新连接验证结果，供后续复查。
先分级，决定先补丁还是先隔离
| 现场发现 | 下一步 |
|---|---|
| 服务端未满足受影响条件，且有供应商或配置证据 | 记录依据，保留例行更新与监控 |
| 条件满足、曾暴露，但暂未发现异常成功登录 | 收紧入口或维护窗口修补，同时扩大日志回溯范围 |
| 无密码账号出现异常成功密码登录，或伴随未经授权的提权与持久化 | 按疑似失陷处理：隔离、保全证据、核对影响范围，避免原地清理覆盖痕迹 |
判断先从历史状态做起：当时是否使用受影响软件包、是否启用密码认证、账号状态是否变化、监听端口对谁开放。今日配置已经改好，只能说明当前状态，不能回答前几天的暴露情况。
保全证据：先记录时间和范围，再提取日志
记录告警时间、主机时区、实例 ID、管理入口、负责人和变更历史。优先从集中日志、堡垒机和云控制面取证，再保存主机上仍可获取的轮转日志。将证据放到受控存储，避免通过可疑主机把敏感日志上传到公共工具。下面是只读查看示例，命令可用性随系统而异。
date -u ps -ef # 有 ss 的环境 ss -tnp # 查看当前与历史会话；部分精简系统未记录 wtmp who last -i # 分别查看当前日志及轮转文件，再按实际文件名查询 ls -l /var/log/messages* /var/log/auth.log* 2>/dev/null grep -E 'sshd.*Accepted (password|publickey)' /var/log/messages
如果确需磁盘快照，记下获取时间和快照 ID。快照通常不会保存内存和临时连接状态；涉及高影响资产时，由应急人员决定易失性证据的采集顺序。不要先清空日志、删除账号或重启主机，再尝试还原时间线。
把一条可疑登录串成时间线
- 提取成功登录的账号、时间、来源 IP、目标端口和认证方法。通过堡垒机或 NAT 时，对照跳板审计、代理日志和云流量记录，不直接把最后一跳认作真实来源。
- 核实该账户在当时是否允许正常密码登录、是否有已知变更、是否平时只用公钥。可疑的成功记录比失败爆破记录更值得优先查。
- 将前后几分钟的提权、服务启动、计划任务和外连事件对齐，随后扩展到该账号可访问的其他机器、服务账号和存储。没有关联记录时写明日志缺口。
逐项检查持久化和横向影响
-
账户与密钥：对照配置仓库、可信备份和 IAM 变更记录检查新增用户、组、sudo/doas 规则及
authorized_keys。实际授权路径以有效的AuthorizedKeysFile等设置为准。 - 启动与计划任务：核对 OpenRC 服务、cron、systemd 单元及容器入口脚本，尤其关注与变更窗口不符的新增配置。
- 应用与数据：对照发布产物和镜像，确认异常文件是否为合法部署。文件时间戳可被修改，只作为线索。复核可疑账户能读取的数据库、部署凭据、对象存储和其他主机。
- 保全与处置分开：先保存发现的可疑文件及其关联日志，再按事件流程处理。不要在可疑主机上执行来路不明的清理或复现脚本。
从可信镜像恢复，并按条件轮换凭据
不能证明原机可信时，从可信且已修复的镜像重建。先重建管理链路与访问控制，再迁移经核验的数据和配置；不要把旧机的可执行文件、启动项或整套授权密钥原样搬回。若有凭据泄露可能，从干净终端撤销旧访问并轮换受影响凭据，同时检查是否存在其他依赖旧凭据的任务。怀疑主机密钥泄露时，发布可验证的新指纹并通知运维侧更新信任。
恢复上线前后怎么验收
上线前，核对修复包、有效认证配置、已撤销凭据、新连接和关键自动化；从日志端验证新登录确实可见。上线后继续盯成功密码登录、异常提权、新建用户、未知外连及其他节点同类迹象。把事件结论分成“已确认”“未观察到”“因日志缺口无法判断”，不要用“未发现”替代“确认未失陷”。
