定期检查系统日志是发现可疑访问与提权痕迹最直接、成本最低的手段，没有之一，与其依赖事后救火，不如每天花十分钟“翻旧账”，把攻击者的脚印堵在萌芽期。
日志文件就像服务器的“黑匣子”，记录着每一次登录、每一条命令、每一次权限变更，攻击者哪怕手法再高明，只要触碰过系统，就必然留下痕迹，问题在于，多数运维人员要么不看日志，要么不知道看什么，今天咱们就聊聊，怎么把日志变成你的“哨兵”。
日志到底藏在哪儿，先搞清楚“案发现场”
不同系统的日志存放路径和命名规则差异很大,但核心思路一致：先找认证日志，再看系统事件，最后翻应用记录。
Linux系统日志路径速查
- 认证与登录日志：
/var/log/auth.log（Debian/Ubuntu）或/var/log/secure（CentOS/RHEL），这里记录着所有ssh登录、su切换、sudo提权行为，是排查提权痕迹的第一现场。 - 系统运行日志：
/var/log/messages或/var/log/syslog，涵盖内核信息、服务启停、防火墙拦截等。 - 计划任务日志：
/var/log/cron，专门记录crontab任务的执行情况，攻击者常在这里植入持久化后门。 - 登录记录：
/var/log/wtmp和/var/log/btmp，前者记录成功登录，后者记录失败尝试，注意这俩是二进制文件，得用last和lastb命令查看。
Windows系统日志路径速查
Windows的日志集中在“事件查看器”里，右键“开始”菜单就能打开，或者运行 eventvwr.msc，重点看三类：
- 安全日志：记录登录成功/失败、账号权限变更、对象访问，提权行为通常会在这里留下ID为4672（分配特殊权限）、4720（创建用户）、4728（将成员添加到启用安全的全局组）等事件。
- 系统日志：记录服务启动失败、驱动加载异常等，攻击者加载内核驱动时必留痕迹。
- 应用程序日志：记录应用层错误，比如数据库提权漏洞利用后的异常报错。
我的习惯是：Linux优先查 /var/log/auth.log，Windows优先筛安全日志中的“事件ID 4720”和“事件ID 4672”，这两个位置覆盖了八成以上的提权线索。
如何查看服务器登录日志，揪出“不请自来的客人”
找到了日志文件,下一步是知道怎么读，别一上来就 cat 整个文件，那等于大海捞针，咱们按“异常登录”和“异常命令”两条线来排查。
第一步：筛选失败登录，锁定爆破源
暴力破解是最常见的入侵方式,用下面这行命令，直接看谁在反复尝试登录：
grep "Failed password" /var/log/auth.log | awk '{print $11}' | sort | uniq -c | sort -nr | head -20
这条命令会统计所有失败登录的IP地址,按次数降序排列，如果某个IP出现几十次甚至上百次，基本可以断定是扫描器或爆破程序。
先封IP，再溯源，别手软。
第二步：检查成功登录，找出“隐形人”
失败登录能防住大部分脚本小子,但真正的高手会直接拿下合法账号，所以成功登录的记录更要仔细看：
grep "Accepted" /var/log/auth.log | awk '{print $9, $11}'
重点核对几个信息：登录时间是不是凌晨三点？登录IP是不是从来没见过的国外地址？登录用户是不是root或高权限账号？ 三者中任意一个异常，都要立刻查这个账号的历史操作。
第三步：追查sudo提权记录，看谁动了“蛋糕”
提权最直接的方式就是sudo,Linux下每次sudo执行都会留下记录：
grep "sudo" /var/log/auth.log | grep "COMMAND"
这行命令能列出所有通过sudo执行的命令,如果发现 sudo su -、sudo useradd、sudo visudo 这类操作，但对应时间点你没有安排过运维任务，那大概率是出了内鬼或者被拿下了一个高权限账号。
提权痕迹深度排查，别让“潜伏者”蒙混过关
登录日志只是冰山一角,攻击者拿到低权限账号后，通常会通过内核漏洞、SUID提权、sudo配置错误、数据库udf等方式获取root权限，这些操作同样会在日志中留下蛛丝马迹。
排查异常用户与用户组
攻击者提权后第一件事往往是创建后门账号,用以下命令列出所有带登录Shell的用户，逐一核对是否认识：
grep -E "/bin/bash|/bin/sh" /etc/passwd
正常情况下,这个列表里应该只有root、普通运维账号和系统服务账号。如果出现 test、backup、sysadmin 这种一看就是临时起的名字，立刻锁定并禁用。
同时检查 /etc/sudoers 文件，看是否有多出的提权配置，行业共识认为，sudoers被篡改是提权攻击中最隐蔽也最致命的手法之一。
检查计划任务和后门文件
攻击者为了持久化,会在crontab里写入定时任务，比如每隔五分钟执行一次反弹shell脚本，检查方式：
crontab -l # 查看当前用户计划任务 ls /etc/cron.d/ # 查看系统级计划任务
重点看有没有 wget、curl、base64 -d 这类命令组合，以及 /tmp 目录下有没有近期新增的可执行文件。很多攻击者喜欢把脚本扔在/tmp目录，因为权限宽松且容易被忽略。
审查历史命令与日志篡改痕迹
如果你发现 ~/.bash_history 文件被清空，或者文件大小为0，这本身就是重大异常，正常运维人员不会频繁清空历史命令，同样，如果auth.log文件在某个时间点之后戛然而止，或者中间有大段空白，说明日志可能被删改过。
业内专家指出,检查日志文件是否被篡改，可以用 ls -l /var/log/auth.log 看文件修改时间，再对比日志内容里最后一条记录的时间，两者应该大致吻合，如果不吻合，说明日志被手工处理过。
linux系统日志分析命令，这些“兵器”要顺手
除了上面用到的 grep 和 awk，还有几个命令能提升排查效率，掌握它们，你就能在几分钟内完成一轮基础巡检。
last与lastb：快速查看登录历史
last -20：显示最近20条成功登录记录，包含登录终端、IP和时间。lastb -20：显示最近20条失败登录记录，同样包含IP。
这两个命令直接读wtmp和btmp文件,输出格式清晰，比手动解析日志省事得多。建议每天上班第一件事先跑一遍 last -10，看看昨晚有没有陌生IP登录。
journalctl：集中式日志管理利器
如果你的系统使用systemd,可以完全用journalctl替代直接查看日志文件：
journalctl -u sshd --since "yesterday" # 查看sshd服务昨天的所有日志 journalctl -k -p err # 查看内核错误级别日志
journalctl支持按时间、服务、优先级过滤，比grep整个日志文件高效不少，但注意，journald的日志是循环存储的，默认占用系统盘空间的10%，磁盘紧张时旧日志会被自动清理。
日志轮转与留存策略
日志不是越大越好,留存时间太短查不到历史记录，太长又占磁盘空间，一般建议：
- 系统日志保留90天以上。
- 安全相关日志（认证、提权）保留180天以上。
- 定期归档到独立存储或对象存储,防止被攻击者连日志一起删掉。
配置Linux日志轮转在 /etc/logrotate.d/ 目录下，比如新建一个sshd专用规则：
/var/log/auth.log {
daily
rotate 180
compress
missingok
notifempty
}
windows安全日志查看方法，别在事件查看器里迷路
Windows日志量巨大,直接翻事件查看器能翻到怀疑人生，正确做法是用PowerShell精准筛选。
快速筛选提权相关事件
打开PowerShell（管理员），执行以下命令筛选出最近24小时的安全日志中与权限变更相关的事件：
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4672,4728,4732; StartTime=(Get-Date).AddDays(-1)} | Format-Table TimeCreated, Id, Message -Wrap
这组事件ID分别对应“分配特殊权限”“将成员添加到安全组”“将成员添加到本地组”。任何一条记录都需要你确认是不是管理员本人操作。
登录事件与异常会话排查
查看最近的登录成功事件：
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624; StartTime=(Get-Date).AddDays(-1)} | Select-Object TimeCreated, @{n='Account';e={$_.Properties[5].Value}}, @{n='LogonType';e={$_.Properties[8].Value}}
重点关注登录类型为3（网络登录）和10（远程交互登录）的事件，如果某个账号在凌晨频繁通过远程登录，而且来源IP不在公司网段内，基本可以判定异常。
用wevtutil导出日志备用
排查完毕后,建议把安全日志导出留存：
wevtutil epl Security C:\Security-Archive.evtx
这样即使原日志被覆盖,你手里还有一份历史备份。日志不备份等于白查。
巡检日志的常见误区和应对思路
日志排查最大的误区是“只看一次就完事”，攻击者可能潜伏数月，单次检查很难发现问题。建立固定巡检节奏比一次深度排查更重要。
只看登录日志，不看应用日志
Web应用、数据库、中间件的日志同样关键，SQL注入提权往往会在数据库日志里留下异常查询记录，WebShell访问会在Nginx或Apache访问日志里留下特征，建议每周至少抽一次时间，把 /var/log/nginx/access.log 和数据库慢查询日志也过一遍。
只查不封，发现异常IP却不断开
查日志的目的是为了处置,发现可疑IP后，立即用防火墙封禁：
iptables -A INPUT -s 可疑IP -j DROP
封完再继续溯源,别让攻击者一边看着你查日志一边继续挖矿。
账号权限不收口，查了也白查
日志排查只能发现已知攻击,权限收口才是根治之道，具体操作包括：
- 禁用root直接ssh登录,改用普通用户+sudo。
- 定期清理超过90天未登录的僵尸账号。
- sudo授权精确到具体命令,别给
sudo ALL。
常见的服务器入侵排查问题，这几个坑你踩过吗
Q：日志显示有陌生IP登录成功，但对方没做任何操作，这是误报吗？
A：不是，攻击者登录后可能先建立代理隧道，或者只读取了配置文件和数据库连接信息就退出。未执行命令不代表未入侵，立即强制该用户下线、修改密码、检查该IP是否还在其他服务器上登录过，并全面排查敏感文件是否被读取。
Q：日志文件被删了，还能找回入侵痕迹吗？
A：部分可以，如果攻击者使用 shred 或 dd 覆盖了日志，物理磁盘层面很难恢复，但通常攻击者只会删除部分日志，/var/log/messages、应用日志、进程记录等可能还有残留，历史登录记录 last 命令的输出、Shell历史命令、进程审计记录（如果开启了auditd）都可能保留线索。这就是为什么强调日志要异地备份。
Q：哪些日志文件改动迹象最值得警惕？
A：优先级排序是：认证日志文件大小异常缩小或清零、/etc/passwd 或 /etc/sudoers 修改时间异常、计划任务目录出现新文件、.bash_history 被清空，任何一个迹象都值得你花半小时深挖，这半小时可能省下后续数据被勒索的巨额损失。
日志巡查不是IT部门的形式主义,而是安全体系里的最后一道防线。每天花十分钟看一眼登录记录，每周花半小时过一遍权限变更，这比安装再贵的防火墙都管用。 毕竟，最懂服务器的人是你自己，不是安全厂商。