Linux登录审计：last与lastlog命令实战与排查流程-北京尧图网络

在 Linux 运维和服务器安全排查中有一类问题非常典型某个服务突然异常、某台机器上出现了陌生进程、某个配置被改过排查到一半却卡在同一个问题上——这段时间到底有哪些账号登录过这台机器如果平时没有做过登录记录留存和审计习惯这个问题的答案往往是“不知道”而last和lastlog就是把这个问题从“不知道”变成“可查证”的两个基础工具。这篇文章围绕 Linux 用户管理中的登录信息查询展开重点拆解last和lastlog两个命令的工作原理、参数用法、输出字段含义以及在实际审计场景中怎么把它们组合成一套可落地的排查流程。文章面向有一定 Linux 命令行基础、需要做服务器运维或安全巡检的读者也适合刚接触 Linux 用户管理、想搞明白/var/log/wtmp这类文件到底存了什么的新手。看完之后你应该能够独立完成一次登录记录回溯并且知道在哪些环节容易踩坑。1. 登录审计的底层逻辑与命令定位1.1 一个常见场景引出的需求假设一台对外提供 SSH 服务的 Linux 服务器某天运维同学发现/etc/ssh/sshd_config被人改动过或者某个定时任务里多了一条陌生的 crontab 记录。此时第一反应通常是查history但history只对当前登录的 shell 有效而且默认只保留有限条数用户退出后还可能被清空甚至连不同会话之间都不共享。更要命的是如果是通过scp、sftp或者非交互式 SSH 命令进来的history里根本不会留下痕迹。这时候真正可靠的信息源是系统层面的登录记录。Linux 从 Unix 继承了一套“记账”机制把每次登录、登出、系统启动、关机这些事件以二进制结构写入固定文件再配套提供读取工具。这套机制的特点是写入由系统调用完成普通用户很难在不被发现的情况下篡改因为文件权限受控而且它记录的是“事件”不依赖用户是否开了 shell。last和lastlog就是这套机制的两个读取入口前者看的是“登录事件流水”后者看的是“每个账号最后一次登录的快照”。1.2 三个二进制日志文件的分工在讲命令之前必须先把这几个文件的关系理清楚否则后面的输出会看得一头雾水。Linux 登录审计相关的文件主要有三个它们的职责边界很清晰文件路径记录内容对应读取命令典型权限/var/log/wtmp成功的登录、登出、系统重启、运行级别切换last0664 root:utmp/var/log/btmp失败的登录尝试lastb0600 root:utmp/var/log/lastlog每个用户最后一次登录的时间、来源、终端lastlog0664 root:utmp需要特别强调的是这三个文件全部是二进制格式不是文本日志。用cat、tail、grep去读它们得到的会是一堆乱码或者看起来像乱码的字符这不是文件损坏而是设计如此。正因为是二进制结构体数组读写效率才高才能支撑高并发登录场景。要查看内容必须用配套的命令。这三个文件的权限设计也很有意思btmp因为记录了失败登录可能包含密码尝试的账号信息默认只有 root 可读所以lastb必须以 root 身份执行而wtmp和lastlog允许utmp组读取一些发行版会把普通用户也放进这个组方便用户自己查看“我最近什么时候登录过”。这个权限差异在实际排查时经常被忽略导致出现“命令没输出”却误以为是日志丢了的误判。1.3 last 与 lastlog 的本质区别很多人会把这两个命令混着用实际上它们回答的是完全不同的问题。last回答的是“按时间顺序这台机器上发生过哪些登录事件”它读的是事件流水所以同一用户可以出现很多次而且能精确到“几点几分登录、几点几分登出、持续了多久”。lastlog回答的是“每个账号最近一次登录是什么时候”它是一个用户维度的快照表每个账号最多只有一行没登录过的账号显示从未登录。这个区别决定了使用场景怀疑有异常登录、需要还原时间线、要排查某个时间段谁在线用last做账号治理、找长期不登录的僵尸账号、确认某个账号是否被启用过用lastlog。两者结合才能既看到全局时间线又看到账号维度的活跃度画像。2. 环境准备与工具来源确认2.1 系统环境与命令归属last、lastb、lastlog这三个命令在主流发行版上都由util-linux这个基础包提供它不是需要额外安装的第三方工具而是系统自带的底层工具集之一。你可以用下面的命令确认它们是否存在以及来自哪个包# 确认命令路径 which last lastb lastlog # 查看命令由哪个软件包提供Debian/Ubuntu 系 dpkg -S $(readlink -f $(which last)) # 查看命令由哪个软件包提供RHEL/CentOS/Rocky 系 rpm -qf $(which last)输出大致会是/usr/bin/last、/usr/bin/lastb、/usr/bin/lastlog分别指向util-linux的软链接或实体文件。如果提示command not found说明系统极简安装时裁掉了这个包需要重新安装util-linux。这里要注意不同发行版的util-linux版本不同last支持的部分参数比如-F完整时间、-p呈现指定时间在线用户在较老的版本上可能不存在本文示例以常见发行版的现代版本为例如果你的环境参数报invalid option先跑一下last --help看实际支持范围。本文不绑定具体的版本号因为util-linux在不同发行版上差异较大写死版本反而会误导。重点是掌握“读什么文件、参数控制什么行为”这套思路具体参数以你机器上last --help的输出为准。2.2 日志文件是否存在与权限检查命令能不能跑取决于目标文件在不在。第一件事是确认文件状态ls -l /var/log/wtmp /var/log/btmp /var/log/lastlog典型输出如下-rw-rw-r--. 1 root utmp 26112 Mar 10 09:15 /var/log/btmp -rw-rw-r--. 1 root utmp 29184 Mar 10 09:20 /var/log/lastlog -rw-rw-r--. 1 root utmp 85248 Mar 10 09:20 /var/log/wtmp如果某个文件不存在last会直接提示wtmp begins ...之前什么都没有或者报last: /var/log/wtmp: No such file or directory。文件不存在的常见原因有两个一是极简镜像或容器环境本身没有启用这套记账机制二是系统用了systemd的 journal 方案某些发行版的 PAM 配置不再写wtmp。容器环境尤其要注意容器内的/var/log/wtmp通常是空的或者不存在因为登录事件发生在宿主机上容器本身没有 tty 登录。权限方面用普通用户执行lastb大概率会看到lastb: /var/log/btmp: Permission denied这不是命令坏了而是设计上的最小可见原则。涉及失败登录的排查请使用sudo。2.3 时区与语言环境的前置确认这一点经常被忽略但影响很大。last输出里的时间是按系统本地时区渲染的如果你的服务器时区是UTC而你在Asia/Shanghai看到的时间会差 8 小时很容易误判“这个登录发生在凌晨”其实只是时区问题。排查前先确认timedatectl 2/dev/null || cat /etc/timezone date同时lastlog的输出在中文语言环境下会把表头和“从未登录”翻译成中文这会影响后面的awk、grep文本处理。做脚本化分析时建议统一加LC_ALLC前缀强制英文输出保证字段位置稳定、匹配规则可靠。这是写审计脚本时最基本的一条经验后面实战部分的脚本都会带上它。3. last 命令核心用法拆解3.1 默认输出的字段含义先看一个最朴素的调用last -n 5输出类似这样root pts/0 192.168.10.21 Mon Mar 10 09:12 still logged in deploy pts/1 10.0.3.55 Mon Mar 10 08:47 - 09:05 (00:18) root tty1 Mon Mar 10 08:30 - 08:45 (00:15) reboot system boot 5.10.0-28-amd64 Mon Mar 10 08:20 still running root pts/0 192.168.10.21 Sun Mar 9 22:10 - 22:35 (00:25)从左边数起各列含义分别是用户名、终端设备、来源主机IP 或主机名、登录时间、登出时间、持续时长。有几个细节值得单独说明。终端列里的pts/N表示伪终端通常对应 SSH 或终端模拟器会话ttyN表示本地虚拟控制台也就是直接在机器前面接显示器键盘登录的那种。所以当你看到一个tty1的登录记录而服务器放在机房里根本没人碰过这就是一个需要重点核查的信号。来源主机列如果为空一般表示本地登录不走网络。如果是:0这类形式通常是图形界面本地会话。如果是 IP可以用-i参数强制以数字形式显示避免 DNS 反解带来的延迟和不确定性。最后一列的still logged in表示该会话当前仍然在线没有对应的登出记录(00:18)这种括号里的值是本次会话持续的时长still running出现在reboot条目上表示系统自那次启动后一直运行至今。3.2 常用参数与场景对照last的参数不少但真正高频的就那么几个。下面按使用场景整理场景命令写法说明只看最近 N 条last -n 20等价于last -20控制输出行数显示完整日期时间last -F输出年月日时分秒适合精确对时IP 强制数字显示last -i避免 DNS 反解导致的卡顿关闭主机名解析last -R只输出 IP 或用空值速度更快只看某时间之后last -s 2025-03-01 00:00:00起点过滤只看某时间之前last -t 2025-03-05 23:59:59终点过滤可与-s组合查看关机重启记录last -x增加shutdown、runlevel等系统级条目只看重启记录last reboot快速确认机器是否异常重启过读取历史归档last -f /var/log/wtmp.1日志轮转后的旧文件回溯查看指定时刻在线用户last -p 2025-03-10 09:00还原某时刻的在线状态其中-F和-i在排查中建议默认加上前者避免“同一天多次登录分不清先后”后者避免内网 DNS 反解失败时命令卡住几十秒。-x则是在怀疑“机器是不是被重启过”时的第一选择因为默认输出里reboot记录只在特定条件下出现加上-x才能稳定看到系统级事件。关于时间参数的格式-s和-t支持两种写法YYYYMMDDHHMMSS紧凑格式或者YYYY-MM-DD HH:MM:SS带引号的格式。带空格的写法必须加引号否则 shell 会把时间拆成两个参数传给命令导致解析失败。这个错误非常常见报错信息却往往只提示“无效的时间格式”不太好定位。3.3 特殊条目reboot、shutdown 与 wtmp beginslast的输出里除了普通用户还有几类特殊条目读懂它们对还原时间线很关键。reboot system boot 内核版本时间表示一次系统启动。如果有对应的still running说明这是当前这次运行如果有- 08:45 (00:15)这样的区间说明那次启动只持续了 15 分钟就又重启了这通常意味着异常崩溃、内核 panic 或者有人手动重启。shutdown system down 内核版本时间表示一次正常关机需要-x才会显示。runlevel (to lvl 5)和runlevel (to lvl 3)是运行级别切换记录同样需要-x。运行级别发生变化往往对应着有人手动切了图形界面或者调整了启动模式。位于输出末尾的wtmp begins Mon Mar 03 10:22:15 2025是整份日志的时间起点。这个值非常重要它告诉你“这份日志最早只能追溯到什么时候”。如果它显示的是三天前而你正在排查一周前的事件那就说明日志已经被轮转覆盖或者被截断过继续在wtmp里找是没有意义的必须去翻归档文件或者别的日志源。3.4 时间窗口过滤与历史文件回溯真实排查中很少需要看全部记录更多是锁定一个时间窗口。假设怀疑问题发生在 3 月 10 日上午 8 点到 10 点之间可以这样查last -F -i -s 2025-03-10 08:00:00 -t 2025-03-10 10:00:00如果wtmp已经被轮转旧数据会落到/var/log/wtmp.1这样的归档文件里。很多发行版默认配置了 logrotate 对wtmp做按月轮转保留若干份。回溯时可以直接指定文件# 列出所有归档文件 ls -l /var/log/wtmp* # 读取上一份归档 last -F -i -f /var/log/wtmp.1 # 读取第二份归档 last -F -i -f /var/log/wtmp.2这里有一个容易被忽略的点logrotate 对wtmp的处理方式和普通文本日志不同。普通文本日志通常是“重命名新建”而wtmp这类二进制记账文件如果只是重命名正在运行的进程仍然持有原文件句柄新事件会继续写进被重命名的旧文件里导致归档文件“越写越新”、新文件“一直是空的”。所以wtmp的标准轮转方式是copytruncate或者配合postrotate脚本具体配置在/etc/logrotate.conf里能看到。如果你发现wtmp.1的修改时间比wtmp还新基本就是这个原因排查时需要额外注意数据的完整性问题。4. lastlog 命令核心用法拆解4.1 输出格式与“从未登录”的含义lastlog的默认输出是一个用户列表LC_ALLC lastlog输出类似Username Port From Latest root pts/0 192.168.10.21 Mon Mar 10 09:12:33 0800 2025 daemon **Never logged in** bin **Never logged in** deploy pts/1 10.0.3.55 Mon Mar 10 08:47:11 0800 2025 nginx **Never logged in**四列分别是用户名、终端、来源、最后登录时间。表头那行Username Port From Latest需要跳过。凡是显示**Never logged in**的账号说明自lastlog文件创建以来从未成功登录过。这里必须提醒一个认知上的坑lastlog记录的是“系统账号最后一次登录”的快照但它不记录登录事件本身所以它没法告诉你“这个账号一共登录过几次”。而且它的更新时机是在登录会话建立时由 PAM 模块写入的如果某个服务比如某些 FTP 配置、部分数据库的内置认证不走 PAM它的登录行为就不会反映到lastlog里。所以看到某个服务账号显示“从未登录”时不能直接断定它没有被使用过只能说“没有通过 PAM 会话登录过”。另一个高频现象是在某些较新的发行版上lastlog输出为空或者直接报The specified file /var/log/lastlog does not exist。这不是命令坏了。部分发行版出于精简考虑默认不再生成/var/log/lastlog或者 PAM 配置里没有启用对应的记录模块。遇到这种情况先确认文件是否存在见 2.2 节再检查 PAM 配置里是否有pam_lastlog相关的行。如果确实没有lastlog就无法工作此时应改用last或者集中式日志方案不要在这上面死磕。4.2 参数详解与典型组合lastlog的参数比last少但有几个非常实用参数作用典型场景-u LOGIN只查指定用户核查单个账号-t DAYS只显示最近 DAYS 天内登录过的用户看活跃账号-b DAYS只显示 DAYS 天之前登录过的用户找长期不活跃账号-C清除某用户的最后登录记录慎用修改日志-S将某用户的最后登录记录设为当前时间慎用修改日志--help查看本机实际支持的参数版本差异确认最常用的组合是查单个账号和查找长期未登录账号# 查看 root 的最后登录信息 LC_ALLC lastlog -u root # 查看最近 7 天内登录过的用户 LC_ALLC lastlog -t 7 # 查看 90 天之前登录过含从未登录的用户 LC_ALLC lastlog -b 90-b 90的语义需要特别说清楚它是“最后一次登录发生在 90 天之前的用户”并不包含“从未登录”的用户。从未登录的账号在lastlog里时间是空的不会被时间条件命中。所以在做账号清理时必须把“从未登录”和“长期未登录”两类分别捞出来才能覆盖完整。-C和-S属于写入操作会实际修改/var/log/lastlog的内容。这两个参数在生产环境应该被视为高危操作-C会把某个用户的最后登录记录抹掉导致后续审计失去依据-S会把时间改成当前制造出“刚登录过”的假象。除非你在做测试环境的数据构造或者有明确的合规要求并已获得授权、做过文件备份否则不要碰这两个参数。4.3 数据来源与刷新机制lastlog的数据来自/var/log/lastlog这个文件的结构比较特殊它按 UID 偏移存储每个 UID 对应固定长度的一条记录。这意味着文件大小通常等于“系统里最大 UID × 每条记录大小”所以你会看到一个几十 MB 甚至更大的lastlog文件但里面绝大部分是空洞稀疏文件。这也是为什么ls -l看到的大小和du -h看到的大小差异巨大不用惊讶这是正常现象。记录写入发生在登录成功的那一刻。以 SSH 登录为例sshd完成认证后会通过 PAM 调用pam_lastlog模块把登录信息写进去。如果认证方式绕过了 PAM或者 PAM 配置里把这一行注释掉了就不会有记录。有些加固规范会出于“避免泄露上次登录信息”的考虑主动关闭pam_lastlog的显示功能这时候要区分“不显示”和“不记录”是两回事需要看具体配置。还有一个容易误解的点如果用户通过su或sudo切换到别的账号lastlog里目标账号的记录是否更新取决于具体配置和 PAM 栈。一般不建议把这类切换行为当作“登录”来看待审计时应该结合last的pts会话记录和sudo日志一起判断。5. 完整实战一次登录审计的落地流程5.1 需求拆解与执行顺序把前面的知识串起来做一次完整的登录审计。假设的需求是核查一台 SSH 服务器近期的登录情况找出长期未登录的可疑账号、异常时间段的登录记录以及是否存在暴力破解迹象。执行顺序建议如下先做整体概览再按时间窗口细分然后做账号维度统计最后交叉验证失败登录。每一步都用命令留下可复现的输出方便后续对比。第一步整体概览确认日志覆盖范围和数据完整性# 确认日志起点和最新状态 LC_ALLC last -F -i | head -30 LC_ALLC last -F -i | tail -5head看最近的登录事件tail看日志的起点wtmp begins。这两条命令先跑能快速判断“我手上这份数据能不能支撑排查”。第二步按时间窗口锁定可疑区间# 假设关注 3 月 9 日到 3 月 10 日 LC_ALLC last -F -i -s 2025-03-09 00:00:00 -t 2025-03-10 23:59:59第三步账号维度扫描# 从未登录的账号 LC_ALLC lastlog | awk NR 1 $2 **Never {print $1} # 超过 90 天未登录的账号 LC_ALLC lastlog -b 90第四步失败登录排查# 需要 root 权限 sudo LC_ALLC lastb -F -i -n 50这四步跑完基本的画像就有了。下面把常用的统计逻辑整理成脚本方便重复执行。5.2 登录审计脚本实现把前面零散的命令固化成脚本是让审计可重复的关键。下面这个脚本覆盖了“统计每个用户登录次数”“列出从未登录账号”“列出长期未登录账号”三个能力可以直接保存后执行#!/bin/bash # 文件路径/usr/local/sbin/login_audit.sh # 用途Linux 登录情况审计快照 # 注意只读取日志不做任何写入操作 set -euo pipefail export LC_ALLC echo echo 登录审计报告生成时间: $(date %Y-%m-%d %H:%M:%S) echo echo echo [1] wtmp 日志覆盖范围 last -F | tail -1 echo echo [2] 最近 20 条登录事件 last -F -i -n 20 echo echo [3] 各用户成功登录次数统计Top 15 last -i | awk NF 0 $1 ! reboot $1 ! shutdown $1 ! wtmp {count[$1]} END {for (u in count) printf %-20s %d\n, u, count[u]} \ | sort -k2 -nr | head -15 echo echo [4] 从未登录过的账号 lastlog | awk NR 1 $2 **Never {print $1} echo echo [5] 超过 90 天未登录的账号 lastlog -b 90 echo echo [6] 最近 20 条失败登录记录 if [ $(id -u) -eq 0 ]; then lastb -F -i -n 20 || echo btmp 为空或不可读 else echo 当前非 root 用户跳过 btmp 检查请使用 sudo 执行 fi echo echo echo 报告结束 echo 赋权并执行sudo chmod 750 /usr/local/sbin/login_audit.sh sudo /usr/local/sbin/login_audit.sh脚本里有几个处理细节值得说明。set -euo pipefail保证任何一步失败都能及时暴露而不是带着空数据往下跑export LC_ALLC保证awk的字段切分符合预期第 [3] 段用awk做计数后按次数倒序排能直观看出哪个账号登录最频繁——如果某个平时不用的服务账号排在第一那就要重点核查了第 [6] 段做了 root 判断避免普通用户执行时因为权限不足中断整个脚本。需要提醒的是第 [3] 段的过滤条件里排除了reboot、shutdown、wtmp这几个特殊条目的首字段。这是因为last的输出中这些行也会占一行不排除会污染统计结果。如果你的系统上还有其他特殊条目比如runlevel需要-x才出现也要一并排除。这种过滤逻辑没有绝对通用的写法建议先跑一遍last看看本机实际有哪些特殊行再调整脚本。5.3 异常登录的交叉验证单看last或lastlog都不够真正的判断需要交叉验证。举几个具体的组合思路。如果last里出现了陌生的来源 IP先确认这个 IP 是否属于公司出口或者跳板机范围再去看这个 IP 对应的会话持续了多久、有没有对应的登出记录。如果一个会话持续了十几个小时且没有登出still logged in而账号本人说早就下班了那就需要进一步核查。如果lastlog -u someuser显示的最后登录时间和last | grep someuser的第一条记录对不上比如lastlog显示的是三天前但last里有今天的记录这说明记录链路有问题——可能是pam_lastlog被改动过也可能是有人动过日志文件。这种“对不上”本身就是重要线索。如果lastb里出现大量针对同一个账号的失败记录且来源 IP 集中这就是典型的暴力破解特征。此时应该结合sshd日志journalctl -u sshd或者/var/log/secure、/var/log/auth.log确认是否有成功登录紧随其后。只看lastb只能知道“被尝试了”不能判断“是否被攻破”这个边界必须守住。如果发现某次reboot记录的间隔异常短比如十分钟内重启了三次那可能是有人在反复尝试修改配置并重启服务也可能是硬件或内核问题。这时候应该去看journalctl -b -1上一次启动的日志确认原因而不是停留在last层面。5.4 结果解读与结论输出审计的最终产物应该是一份能让别人看懂的报告而不是一堆命令输出。建议至少包含四个部分日志覆盖范围起止时间说明这次审计的结论只在这个范围内有效、登录事件摘要按时间线列出关键节点、异常项清单每条都附上对应的证据命令和输出片段、待确认事项需要业务方或账号负责人确认的内容。这里有个原则值得坚持只陈述事实不下过度结论。比如“账号 deploy 于 3 月 10 日 08:47 从 10.0.3.55 登录09:05 登出持续 18 分钟”是事实“这个登录很可疑”是判断需要额外的上下文支撑。把事实和判断分开写报告才经得起复核。6. 常见问题与排查思路实际使用中遇到的问题大多集中在“命令没输出”“输出看不懂”“记录缺失”这三类。下面把高频问题整理成表每条都给出从现象到根因的排查路径。问题现象常见原因解决思路last无任何输出只报wtmp beginswtmp为空或刚被轮转清空容器环境无登录事件用ls -l /var/log/wtmp*查归档容器内改用宿主机的记录last: /var/log/wtmp: No such file or directory文件被删除极简系统未启用记账手动创建空文件并设权限touch /var/log/wtmp chmod 664 /var/log/wtmp chgrp utmp /var/log/wtmplastb: Permission denied/var/log/btmp权限为 0600仅 root 可读使用sudo lastb不要为了图方便放宽文件权限输出的时间是“错误”的和实际差几小时服务器时区与本地时区不一致timedatectl确认时区必要时统一调整或换算命令卡住几十秒才出结果来源 IP 触发了 DNS 反解且超时加-i参数强制数字显示或加-R关闭主机名解析lastlog报文件不存在发行版默认不生成/var/log/lastlog确认 PAM 是否启用pam_lastlog或改用last作为替代方案lastlog输出全为**Never logged in**登录未经过 PAM或账号确实从未登录结合last交叉验证检查服务的认证方式脚本里awk匹配不到预期字段中文 locale 导致表头和提示被翻译脚本开头加export LC_ALLC-s参数报时间格式无效时间含空格但没加引号写成-s 2025-03-10 08:00:00wtmp.1比wtmp还新logrotate 对二进制记账文件处理方式不当检查/etc/logrotate.conf中 wtmp 的轮转配置表格里最后一条值得展开说。很多人在排查“日志去哪了”时发现归档文件的时间戳很新以为是文件系统出了问题实际上是因为进程持有的文件句柄指向了被重命名的 inode新事件继续写入旧文件。要根治这个问题轮转策略应该改成copytruncate或者配置postrotate在轮转后重新打开文件。改logrotate配置属于生产变更务必先在测试环境验证并确认改动后轮转周期内数据不丢。另一个需要反复强调的点是不要因为排查方便就去放宽/var/log/btmp的权限。把0600改成0644看起来能让普通用户也执行lastb但失败登录记录里包含账号名和尝试信息属于敏感数据放宽权限会让低权限账号获得攻击面的情报。正确做法是通过sudo授权特定运维人员执行而不是改文件权限。7. 最佳实践与工程建议7.1 日志保留周期与轮转策略wtmp和btmp默认的保留周期通常不长很多发行版只有几周。对于有审计要求的场景这个周期明显不够。建议显式检查并调整/etc/logrotate.conf中相关段落的rotate和monthly/weekly配置把保留份数调整到满足合规要求的水平比如保留 12 份月度归档覆盖一年。调整时要注意两点一是磁盘空间wtmp在高并发登录的机器上增长很快保留过多份会占空间建议配合du -sh /var/log/wtmp*定期评估二是轮转方式前面已经说过copytruncate的必要性改配置后一定要等一个完整周期验证新文件确实在增长而不是想当然地认为改完就好了。7.2 权限设计与最小可见原则wtmp涉及全员登录信息btmp涉及失败尝试lastlog涉及个人登录历史三者敏感度不同权限也应该分级。建议的做法是btmp严格保持0600 root:utmpwtmp和lastlog按需授予utmp组读取但不要把普通业务账号加进这个组审计执行统一走sudo白名单并在sudo日志里留下“谁在什么时候执行了审计命令”的记录。这套设计的意义在于审计本身也应该被审计。如果任何人都能随意读取登录记录那记录的价值和可信度都会打折扣。在合规场景下还需要考虑把审计命令的执行记录纳入集中日志形成闭环。7.3 与集中式日志和审计框架的配合单机日志的天然缺陷是“可以被本地修改”。如果攻击者拿到了 root理论上可以篡改wtmp。所以对于安全要求较高的环境本地的last/lastlog只能作为快速排查的第一手材料真正的证据链应该依赖集中式日志把sshd的认证日志、sudo日志实时转发到独立的日志服务器同时把wtmp、btmp定期归档同步过去。这样即使本机被清理远端仍有副本。更进一步的做法是引入auditd对关键文件包括/var/log/wtmp、/var/log/btmp、/etc/passwd、/etc/ssh/sshd_config配置写入监控记录“谁在什么时间用哪个进程改了这些文件”。auditd记录的是系统调用级别的行为和last的登录事件形成互补一个看“人什么时候进来”一个看“进来之后动了什么”。7.4 账号生命周期治理lastlog最大的价值不在应急排查而在日常治理。建议建立定期巡检机制比如每月执行一次lastlog -b 90把结果和账号清单比对系统账号如daemon、bin、nobody显示从未登录是正常的不用管业务账号超过 90 天未登录就应该走确认流程判断是禁用、锁定还是删除。执行账号清理时务必遵守三条底线先备份再操作、先锁定再删除usermod -L观察一段时间再userdel、删除前确认该账号没有被定时任务、服务配置、文件属主引用。userdel默认不删除家目录如果确认要清理需要显式加-r但这会连带删除该用户的所有文件属于不可逆操作必须慎之又慎。8. 继续深入的方向与常用命令速查把last和lastlog吃透之后往下走有几个自然的方向。一是补齐同族命令who看当前在线、w看在线的同时看负载、users看登录用户名列表、lastb看失败尝试这几个配合起来能覆盖大部分日常场景。二是深入PAM配置搞清楚登录信息是在认证流程的哪一步被写入的这样在遇到“记录缺失”时才有能力定位到具体模块。三是接触集中式日志方案理解日志从产生、传输、存储到检索的完整链路这是从单机运维走向体系化运维的必经一步。最后附一份高频命令速查方便贴到自己的笔记里# ---- last 相关 ---- last -n 20 # 最近 20 条登录事件 last -F -i # 完整时间数字 IP last -x # 包含关机、运行级别等系统事件 last reboot # 只看重启记录 last -s 2025-03-01 00:00:00 -t 2025-03-10 23:59:59 # 时间窗口 last -f /var/log/wtmp.1 # 读取归档文件 last -p 2025-03-10 09:00 # 指定时刻在线用户 # ---- lastlog 相关 ---- LC_ALLC lastlog # 全量快照 LC_ALLC lastlog -u root # 指定用户 LC_ALLC lastlog -t 7 # 最近 7 天登录过 LC_ALLC lastlog -b 90 # 90 天前最后登录 # ---- 失败登录 ---- sudo lastb -F -i -n 50 # 最近 50 条失败尝试 # ---- 配套排查 ---- who # 当前在线用户 w # 在线用户负载 journalctl -u sshd --since 2025-03-10 # SSH 服务日志这些命令看起来简单但真正决定排查质量的是两件事一是提前确认数据覆盖范围每次排查先看wtmp begins避免在已经失效的数据上耗时间二是交叉验证任何单一命令的输出都只是线索登录时间线要和 SSH 日志对齐、失败尝试要和成功登录对齐、账号活跃度要和业务归属对齐。把这两点变成习惯last和lastlog才不只是两个查历史的命令而是一套可复用的排查方法论。

Linux登录审计：last与lastlog命令实战与排查流程

相关推荐

无人机俯拍行人检测数据集：小目标、多尺度、强鲁棒性训练实战

IDEA数据库表一键生成Spring Boot+MyBatis完整代码

Linux文件与目录rwx权限详解：从Permission denied到安全配置

更多资讯

企业级数据可视化BI 仪表板数据中台监控平台的选择分析

抖音合集批量下载 3 步跑起来：douyin-downloader 无水印保存完整指南

JPG如何转PNG？推荐三个方法，无损画质还免费！

PAS技能建模法：用问题-动作-结果重构个人能力操作系统

VLAN间通信技术：单臂路由与三层交换对比

Seedance 2.5拟真人像提示词四层架构解析

今日更新

MATLAB缩进快捷键与批量格式化实战指南

用Poco实现Qt风格信号与槽的跨平台C++方案

ESXi裸机虚拟化安装指南：从硬件兼容到虚拟机部署

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？