1. 从一次线上故障排查说起为什么我们需要追溯用户操作去年我负责维护的一个线上服务突然出现性能雪崩CPU使用率飙升到90%以上导致部分业务接口响应超时。登录服务器一看几个核心进程的负载高得吓人。第一反应是代码有内存泄漏或者死循环但最近并没有发布新版本。正当团队焦头烂额准备重启服务时我多问了一句“最近有谁在这台机器上操作过吗” 一位同事小声说他半小时前登录上去想手动清理一下日志文件。问题瞬间清晰了。他使用了类似find /var/log -name “*.log” -exec rm {} \;的命令但路径写得不精确加上通配符使用不当意外地递归删除了大量正在被进程写入的日志文件导致某些进程陷入异常状态进而引发连锁反应。如果当时能快速、清晰地看到“谁、在什么时候、执行了什么命令”我们至少能节省一个多小时的无效排查时间直接定位到操作者并询问其操作细节。这个经历让我深刻体会到在一个多用户、多角色的Linux服务器环境尤其是像Ubuntu这样的生产或开发服务器中清晰地掌握用户登录及操作历史不是系统管理员的“选修课”而是保障系统安全、进行故障排查、落实责任审计的“生命线”。无论是追踪恶意行为、复盘误操作还是简单地了解服务器负载变化前有哪些人为动作这些历史记录都是最直接、最可靠的证据链。今天我们就以Ubuntu系统为例抛开那些华而不实的理论直接上干货系统地梳理一下如何查看用户登录及操作历史。我会从最基础的命令讲起深入到各种日志文件的关联分析并分享一些我在实践中总结的增强监控与审计的心得技巧。无论你是刚接触Linux的开发者还是需要管理服务器集群的运维工程师这些内容都能帮你构建起一套有效的用户行为追踪能力。2. 用户登录记录谁在什么时候进来了用户登录是用户与系统交互的起点。在Ubuntu中记录登录行为的信息分散在几个关键的文件和命令里它们各有侧重结合起来才能拼出完整的画面。2.1 实时与近期登录who,w,last,lastlog这几个命令是快速了解当前和近期登录情况的瑞士军刀无需深入日志文件结果直观。who与w命令看看现在谁在线上who命令列出当前所有登录到系统的用户会话信息非常轻量快捷。who典型的输出如下ubuntu pts/0 2024-05-10 14:30 (192.168.1.100) jenkins pts/1 2024-05-10 13:15 (10.0.0.5)第一列ubuntu, jenkins登录用户名。第二列pts/0, pts/1用户使用的终端标识。pts伪终端通常代表通过SSH等远程方式登录tty代表直接连接的控制台。第三列2024-05-10 14:30登录时间。第四列(192.168.1.100)登录来源的主机名或IP地址。这对于判断登录是否来自可信网络至关重要。w命令可以看作是who的增强版它除了显示登录用户还会额外显示用户当前正在执行的命令WHAT以及系统负载LOAD AVERAGE。w输出示例14:35:10 up 15 days, 2:30, 2 users, load average: 0.08, 0.03, 0.01 USER TTY FROM LOGIN IDLE JCPU PCPU WHAT ubuntu pts/0 192.168.1.100 14:30 5.00s 0.05s 0.00s w jenkins pts/1 10.0.0.5 13:15 1:20m 0.02s 0.00s tail -f /var/log/syslogWHAT列非常有用它能直接告诉你用户正在做什么。比如上面可以看到jenkins用户正在跟踪系统日志。IDLE列显示用户空闲时间对于清理长期不活动的会话有参考价值。JCPU和PCPU反映了该终端关联进程和当前进程的CPU时间消耗。实操心得在应急响应时我第一个敲的命令往往是w。因为它不仅能快速确认入侵者是否还在线看FROM的IP是否陌生还能看到他正在执行什么破坏性命令WHAT列为立即中断其会话提供依据。last命令翻阅系统的“登录日记”last命令用于查询系统自创建以来所有的登录、注销、重启记录。它读取的是/var/log/wtmp二进制日志文件。# 查看所有历史登录记录 last # 查看特定用户如ubuntu的登录历史 last ubuntu # 查看最近10条记录 last -n 10输出示例ubuntu pts/0 192.168.1.100 Fri May 10 14:30 still logged in jenkins pts/1 10.0.0.5 Fri May 10 13:15 still logged in reboot system boot 5.4.0-42-generic Fri May 10 13:00 - 14:36 (01:36) ubuntu pts/0 192.168.1.100 Thu May 9 09:20 - crash (103:40)每一行代表一次登录会话或系统事件。still logged in表示该会话目前仍处于活动状态。reboot行记录了系统重启事件这对于排查因重启导致的服务中断非常关键。末尾的(01:36)表示会话持续时长或系统运行时长。lastlog命令检查所有用户的“最后登录”时间lastlog命令格式化输出/var/log/lastlog文件显示系统中所有用户最近一次登录的时间。lastlog输出示例Username Port From Latest root **Never logged in** ubuntu pts/0 192.168.1.100 Fri May 10 14:30:30 0800 2024 jenkins pts/1 10.0.0.5 Fri May 10 13:15:15 0800 2024 mysql **Never logged in**这个命令对于账户审计特别有用。你可以快速发现哪些系统账户如mysql,www-data从未登录过这通常是正常现象以及哪些用户账户长期未登录可能已成僵尸账户存在安全隐患。如果发现一个本该活跃的用户账户显示“从未登录”或者一个普通用户从异常地点登录那就需要警惕了。2.2 深入日志文件/var/log/auth.log与securesyslog命令行工具虽然方便但其背后的数据源才是根本。对于登录、认证、授权等安全相关事件Ubuntu 系统主要将其记录在/var/log/auth.log文件中在某些其他发行版中可能是/var/log/secure。这个文件是纯文本格式由rsyslog或syslog服务管理内容非常详尽。我们使用grep,tail,less等工具来查看。# 实时跟踪认证日志在另一个终端窗口执行用于监控 sudo tail -f /var/log/auth.log # 查看包含“Accepted password”或“Accepted publickey”的行即成功的登录 sudo grep “Accepted” /var/log/auth.log # 查看包含“Failed password”的行即失败的登录尝试暴力破解迹象 sudo grep “Failed password” /var/log/auth.log # 查看特定用户如ubuntu的所有认证日志 sudo grep “ubuntu” /var/log/auth.logauth.log中的一条成功SSH登录记录通常如下May 10 14:30:30 ubuntu-server sshd[12345]: Accepted password for ubuntu from 192.168.1.100 port 54322 ssh2 May 10 14:30:30 ubuntu-server sshd[12345]: pam_unix(sshd:session): session opened for user ubuntu by (uid0)第一段May 10 14:30:30 ubuntu-server时间戳和主机名。第二段sshd[12345]产生日志的进程sshd守护进程及其PID。第三段具体事件描述。“Accepted password”表示密码认证成功“Accepted publickey”表示密钥认证成功。后面紧跟用户名和来源IP。第四段session opened表示系统为该用户创建了一个新的会话。一条失败的登录尝试记录如下May 10 14:29:15 ubuntu-server sshd[12344]: Failed password for invalid user hacker from 203.0.113.5 port 6667 ssh2invalid user hacker表明攻击者尝试了一个不存在的用户名hacker。如果短时间内出现大量来自同一IP的“Failed password”记录这是非常明显的暴力破解攻击信号。避坑指南/var/log/auth.log文件默认会轮转logrotate旧日志会被压缩成auth.log.1.gz,auth.log.2.gz等。当你需要调查几天甚至几周前的登录事件时别忘了去检查这些压缩文件。可以使用zcat或zgrep命令直接查看压缩内容例如zgrep “Accepted” /var/log/auth.log.2.gz。3. 用户操作历史进来之后做了什么知道谁登录了还不够更重要的是知道他做了什么。这里主要依赖两个机制Shell历史记录和进程审计日志。3.1 Shell命令历史.bash_history与history命令这是最直接、最常用的用户操作记录。当用户在Bash ShellUbuntu默认Shell中执行命令时这些命令会被记录在内存的历史列表中并在退出Shell时或达到HISTSIZE限制时写入到用户家目录下的.bash_history隐藏文件中。查看当前用户的命令历史# 查看当前会话中执行过的所有命令包括序号 history # 查看最近20条命令 history 20 # 执行历史记录中的第101条命令 !101 # 搜索包含“grep”的历史命令 history | grep grep查看其他用户的命令历史文件每个用户的命令历史独立保存在其家目录~/.bash_history中。需要具有相应权限通常是root才能查看。# 查看用户‘ubuntu’的命令历史 sudo cat /home/ubuntu/.bash_history # 或 sudo less /home/ubuntu/.bash_historyShell历史记录的局限性及增强配置默认的.bash_history机制有几个明显的缺陷在安全审计场景下需要特别注意会话隔离性默认配置下命令只在Shell正常退出时才写入文件。如果用户通过kill -9强制结束终端或者系统突然崩溃那么该会话中的所有命令历史都会丢失。时间戳缺失默认的.bash_history文件只记录命令不记录命令执行的时间。这在追溯“某个命令是何时执行的”时非常无力。易被篡改或清除用户有权清空自己的.bash_history文件history -c并history -w或者直接删除该文件从而抹去操作痕迹。为了强化审计我强烈建议在全局或特定用户的 Bash 配置中/etc/bash.bashrc或用户家目录的~/.bashrc添加以下配置# 将以下行添加到 ~/.bashrc 或 /etc/bash.bashrc 的末尾 # 设置历史记录格式包含时间戳 export HISTTIMEFORMAT“%F %T ” # 强制每条命令执行后立即写入历史文件而不是等退出时 shopt -s histappend export PROMPT_COMMAND“history -a;$PROMPT_COMMAND” # 设置历史记录文件大小和条数可调整 export HISTSIZE10000 export HISTFILESIZE20000 # 忽略重复命令和空格开头的命令以空格开头的命令不会被记录 export HISTCONTROLignorebothHISTTIMEFORMAT这是关键。设置后使用history命令会显示每条命令的执行时间。PROMPT_COMMAND这个技巧让Bash在每次显示命令提示符前都执行history -a命令将当前内存中的历史记录追加到历史文件中实现了“实时写入”解决了会话隔离问题。HISTCONTROLignoreboth忽略重复的连续命令和以空格开头的命令。后者是一个小技巧如果用户不想让某条敏感命令被记录可以在输入命令前加一个空格。配置生效后source ~/.bashrchistory的输出会变成1001 2024-05-10 14:35:10 ls -la 1002 2024-05-10 14:35:15 cd /var/log 1003 2024-05-10 14:35:20 sudo tail -f auth.log时间和命令一一对应审计价值大大提升。经验之谈在调查安全事件时如果发现用户的.bash_history文件异常干净或只有几条无关紧要的命令这本身就是一个巨大的红色警报。攻击者入侵后往往会第一时间清空历史记录。此时你需要转向下一节更底层的审计工具。3.2 系统级进程审计auditd框架当.bash_history不可信或被绕过时比如用户使用其他Shell或通过非交互式脚本执行命令我们就需要更底层的监控手段。Linux Audit Daemon (auditd) 是内核级别的审计框架它可以记录系统调用和文件访问功能极其强大是专业安全审计的基石。安装与启动 auditd在Ubuntu上auditd通常不是默认安装的。sudo apt update sudo apt install auditd audispd-plugins -y sudo systemctl enable --now auditd配置审计规则监控关键命令的执行auditd的威力在于其灵活的规则系统。规则可以通过命令行临时添加或永久写入配置文件/etc/audit/rules.d/audit.rules。假设我们要监控所有用户对rm,mv,cp命令的执行以及对/etc/passwd,/etc/shadow等关键文件的访问。使用auditctl命令添加临时规则# 监控‘rm’命令的执行监控execve系统调用且路径匹配*/bin/rm sudo auditctl -a always,exit -F archb64 -S execve -F path/bin/rm -k “delete_cmd” # 监控‘passwd’文件的任何写属性更改 sudo auditctl -w /etc/passwd -p wa -k “passwd_change”-a always,exit在系统调用退出时总是记录。-F archb64针对64位系统。-S execve监控执行程序的系统调用。-F path...指定要监控的程序路径。-w ...监控文件路径。-p wa监控文件的写w和属性更改a操作。-k为这条规则打上一个“关键词”标签方便后续搜索。永久规则配置 将上述规则去掉auditctl写入/etc/audit/rules.d/audit.rules文件然后重启auditd服务 (sudo systemctl restart auditd) 即可永久生效。查询审计日志审计日志默认存储在/var/log/audit/audit.log是二进制格式需要使用专用工具ausearch或aureport来查看。# 查看所有日志内容非常详细 sudo ausearch -i # 查看带有特定关键词的日志如我们上面设置的‘delete_cmd’ sudo ausearch -k delete_cmd -i # 查看今天的所有审计事件 sudo ausearch -ts today -i # 使用aureport生成汇总报告更友好 sudo aureport --summary # 事件摘要 sudo aureport -x --summary # 可执行文件调用报告 sudo aureport -f --summary # 文件操作报告一条典型的ausearch输出经过-i解释后如下typeSYSCALL msgaudit(2024-05-10 14:40:00.123:456) : archx86_64 syscallexecve successyes exit0 a00x7ffc12345678 a10x7ffc12345690 items2 ppid5678 pid9012 auidubuntu uidubuntu gidubuntu euidubuntu suidubuntu fsuidubuntu egidubuntu sgidubuntu fsgidubuntu ttypts0 commrm exe/usr/bin/rm keydelete_cmd这条记录告诉我们在指定时间用户ubuntuauid是审计用户ID通常等于登录uid在终端pts0上成功执行了/usr/bin/rm命令进程PID是9012父进程PPID是5678并且这条记录关联着我们定义的delete_cmd关键词。高级技巧与避坑auditd功能强大但配置复杂日志量也可能非常庞大。在生产环境中务必规则要精确避免使用过于宽泛的规则如监控所有execve否则日志会瞬间爆炸影响性能且难以分析。应该针对关键命令、关键文件和关键用户进行监控。关注auidauditd记录的auid审计用户ID是用户登录时的原始ID即使用户后续通过su或sudo切换了身份auid也不会变。这为追踪操作的最终责任人提供了可靠依据而uid可能只是当前进程的有效用户ID。日志轮转与归档配置好/etc/audit/auditd.conf中的max_log_file和num_logs参数并考虑将重要的审计日志实时同步到远程的日志服务器SIEM上防止攻击者本地擦除。4. 关联分析与进阶排查拼凑完整的证据链在实际的故障排查或安全事件响应中我们很少只依赖单一来源的信息。通常需要将登录记录、操作历史和系统其他日志如应用日志、系统消息日志关联起来形成一条完整的时间线。4.1 时间线重建一个模拟案例假设我们在auth.log中发现一条可疑的深夜成功登录记录May 10 02:15:10 server sshd[22222]: Accepted publickey for deploy from 198.51.100.77 port 12345 ssh2用户deploy从IP198.51.100.77登录。我们需要知道这个用户登录后做了什么。第一步检查该用户的命令历史sudo cat /home/deploy/.bash_history如果历史记录被清空或内容可疑进行下一步。第二步使用last确认登录会话last deploy确认在May 10 02:15左右确实有一个来自该IP的登录会话并记下其终端号例如pts/3。第三步搜索系统日志 (/var/log/syslog) 中该时间点附近、与该终端或用户相关的活动sudo grep “May 10 02:1[5-9]” /var/log/syslog | grep -E “(deploy|pts/3)”可能会发现该用户启动了某个服务或者修改了某个配置文件。第四步如果配置了auditd搜索该时间段的审计日志sudo ausearch -ts 05/10/2024 02:15:00 -te 05/10/2024 02:30:00 -ua deploy -i这能列出该用户在该时间段内所有的系统调用事件可能包括执行了哪些二进制文件、访问了哪些敏感路径。第五步检查进程记账如果启用Ubuntu 还可以通过acct包启用进程记账功能它会记录所有进程的详细信息谁、何时、执行了何命令、消耗多少资源。# 安装进程记账 sudo apt install acct sudo systemctl enable --now psacct # 使用 lastcomm 查看所有执行过的命令记录 sudo lastcomm # 查看特定用户执行过的命令 sudo lastcomm deploy # 查看特定命令如find的执行历史 sudo lastcomm findlastcomm的输出包含用户、终端、命令、执行时间、退出状态等是.bash_history的强力补充。通过这样多维度、交叉验证的分析我们就能相对清晰地还原出用户deploy在登录后的一系列操作判断其行为是正常的运维操作还是恶意的入侵行为。4.2 可视化与集中式日志管理对于服务器数量众多的环境逐台登录去查日志是不现实的。成熟的运维体系会建立集中式的日志管理平台例如使用ELK Stack (Elasticsearch, Logstash, Kibana)或Grafana Loki。其基本工作流是在每台服务器上部署一个日志收集器如Filebeat,Fluentd,Promtail。收集器实时读取本地的auth.log、audit.log、应用日志等。将日志发送到中央的索引和存储系统如 Elasticsearch 或 Loki。通过可视化界面Kibana 或 Grafana进行统一的搜索、分析和仪表盘展示。在这种架构下你可以在一个界面中全局搜索某个IP地址在所有服务器上的登录尝试。设置告警规则当某台服务器出现多次“Failed password”日志时自动发送告警通知。绘制用户登录热力图直观展示异常时间的登录活动。个人体会搭建集中日志系统初期有一定成本但一旦建成对于安全监控和运维效率的提升是颠覆性的。它让“追溯用户行为”从一个被动的、手动的、基于单机的排查动作变成了一个主动的、自动的、全局的可观测性能力。即使资源有限我也建议至少将关键服务器的auth.log通过rsyslog转发到一台专用的日志服务器上实现简单的集中存储和防篡改。5. 安全加固与最佳实践让历史记录更可靠了解了查看方法我们更要思考如何让这些记录本身变得更可靠、更难以被篡改。以下是一些关键的最佳实践配置安全的 Bash History如前文所述强制在/etc/profile或/etc/bash.bashrc中为所有用户设置HISTTIMEFORMAT和实时写入 (PROMPT_COMMAND)并设置足够大的HISTSIZE。设置日志文件的不可更改属性Immutable Flag对于 root 用户可以通过chattr命令为关键日志文件添加iimmutable属性防止被意外或恶意修改、删除。注意这可能会影响正常的日志轮转需谨慎操作或配合脚本临时解除属性sudo chattr i /var/log/auth.log sudo chattr i /var/log/audit/audit.log # 解除属性使用 chattr -i启用并合理配置auditd对于重要的生产服务器务必安装和配置auditd。规则应聚焦于监控特权命令/bin/su,/usr/bin/sudo,/usr/bin/passwd。监控敏感文件/etc/passwd,/etc/shadow,/etc/sudoers, 网站根目录等。监控管理用户如root,ubuntu, 以及所有具有sudo权限的用户的所有执行操作。远程日志记录Syslog Forwarding配置rsyslog将auth.log和audit.log实时发送到一台受保护的、独立的日志服务器。这样即使攻击者攻陷了业务服务器并清除了本地日志在远程服务器上依然留有证据。在/etc/rsyslog.conf中添加如*.* remote-log-server-ip:514的配置即可实现。使用sudo并记录详细日志强制所有管理操作通过sudo进行。在/etc/sudoers文件中确保存在Defaults logfile”/var/log/sudo.log”和Defaults log_input, log_output这样的配置。log_input和log_output会记录sudo会话中所有的输入和输出提供了极其详细的审计追踪但会占用大量磁盘空间请根据需求启用。定期审计与审查建立制度定期如每周审查关键日志关注异常登录时间、异常来源IP、失败登录暴增、特权命令的使用等情况。可以将审查工作自动化通过脚本扫描日志并生成报告。用户行为的历史记录是Linux系统安全与运维的“黑匣子”。从简单的last和history到强大的auditd框架再到集中式的日志分析平台工具链的深度决定了你审计能力的强度。对于个人开发者或小型团队掌握前两节的基础命令足以应对日常绝大部分需求。而对于负责关键基础设施的工程师深入理解auditd和构建集中日志体系则是迈向专业运维和安全管理的必经之路。记住这些日志不仅是出问题后的“调查工具”更是震慑潜在不当行为、提升整体系统安全水位的“预防性措施”。花时间配置好它们在真正需要的时候你会感谢自己当初做的这些工作。