身份验证日志有助于解释登录尝试、权限变化和会话活动。它们是安全敏感的证据，但单独一行很少能够证明用户意图或确认账户已被入侵。
日志 · 第 5 课
身份验证日志
学习如何查找、解读并安全关联 Linux 身份验证记录。
查找身份验证记录
Debian 系的 syslog 配置通常将身份验证事件路由到 /var/log/auth.log，Red Hat 系配置则通常使用 /var/log/secure。systemd journal 可以连同单元和进程元数据保留相同事件，而集中式日志系统也可能保存权威副本。
应查明本地目的地并查询相关服务，例如：
$ sudo journalctl -u ssh.service --since '1 hour ago'
$ sudo less /var/log/auth.log
SSH 单元可能名为 ssh.service 或 sshd.service。这些记录会暴露账户和访问详情，因此其权限通常受到限制。
Linux 身份验证事件必须始终存储在哪里？
解读事件
传统记录可能包含：
Jan 31 10:37:50 icebox pkexec: pam_unix(polkit-1:session): session opened for user root by (uid=1000)
该记录标明时间、主机、发出消息的程序、PAM 模块和服务、请求的会话用户以及来源 UID。它本身无法识别 UID 1000 背后的具体人员，也不能证明该操作具有恶意。应根据事件发生时有效的账户记录解析 UID，并关联终端、远程地址、会话和周边事件。
该记录中的 uid=1000 能确定什么？
调查成功与失败事件
在限定的时间范围内同时搜索已接受和已拒绝的尝试。对于 SSH，还应检查连接来源、身份验证方式、目标账户、会话打开和关闭，以及服务重启。反复失败可能源于用户错误、使用过期凭据的自动化任务、扫描或攻击；仅凭频率无法判断原因。
last 和 lastb 可以汇总系统维护的 wtmp 和 btmp 记录，但这些二进制数据库也有自己的保留和完整性限制。应将其与 journal、syslog 记录及集中式来源相互核对。
反复失败的登录应与哪些信息关联？
保存证据与响应
如果怀疑发生安全事件，应记录主机时间和时区，保留原始日志及元数据，并保护所有导出副本。不要就地编辑证据。锁定账户、更改防火墙和终止会话可能中断合法访问或惊动攻击者，因此要遵循事件响应流程并保留恢复通道。
调查期间应如何处理身份验证证据？
课程已完成
你已完成 身份验证日志
现在，你可以检查身份验证事件，而不会过度解读单条记录所能证明的内容。
查明本地配置的身份验证日志目的地。
结合上下文解读身份、服务、方式和会话字段。
在保留的多个来源中关联失败与成功活动。
保存证据，并协调可能造成中断的响应操作。