Linux 应急响应实战:一文讲透 secure、auditd、cron 与用户日志排查
01前言在日常的应急处理过程中,要结合系统各种日志来排查该告警是真实告警还是误报。本篇文章就来看看linux中常见的一些日志,以及其作用,目的是为了在应急响应时可以快速的找到排查目标02linux中常
01前言
在日常的应急处理过程中,要结合系统各种日志来排查该告警是真实告警还是误报。本篇文章就来看看linux中常见的一些日志,以及其作用,目的是为了在应急响应时可以快速的找到排查目标
02linux中常见的日志
目前linux的大部分系统日志都是在目录/var/log/中,常用的日志有下面的这些
/var/log/messages — 包括整体系统信息,其中也包含系统启动期间的日志。此外,mail,cron,daemon,kern和auth等内容也记录在var/log/messages日志中。
/var/log/dmesg — 包含内核缓冲信息(kernel ring buffer)。在系统启动时,会在屏幕上显示许多与硬件有关的信息。可以用dmesg查看它们。
/var/log/boot.log — 包含系统启动时的日志。
/var/log/dpkg.log – 包括安装或dpkg命令清除软件包的日志。
/var/log/lastlog — 记录所有用户的最近信息。这不是一个ASCII文件,因此需要用lastlog命令查看内容。
/var/log/maillog /var/log/mail.log — 包含来着系统运行电子邮件服务器的日志信息。例如,sendmail日志信息就全部送到这个文件中。
/var/log/user.log — 记录所有等级用户信息的日志。
/var/log/alternatives.log – 更新替代信息都记录在这个文件中。
/var/log/btmp – 记录所有失败登录信息。使用last命令可以查看btmp文件。例如,”last -f /var/log/btmp | more“。
/var/log/cups — 涉及所有打印信息的日志。
/var/log/anaconda.log — 在安装Linux时,所有安装信息都储存在这个文件中。
/var/log/yum.log — 包含使用yum安装的软件包信息。
/var/log/cron — 每当cron进程开始一个工作时,就会将相关信息记录在这个文件中。
/var/log/secure — 包含验证和授权方面信息。例如,sshd会将所有信息记录(其中包括失败登录)在这里。
/var/log/wtmp或/var/log/utmp — 包含登录信息。使用wtmp可以找出谁正在登陆进入系统,谁使用命令显示这个文件或信息等。
/var/log/faillog – 包含用户登录失败信息。此外,错误登录命令也会记录在本文件中。
/var/log/audit/ - 包含命令执行,文件操作等的审计日志
接下来我们看一下linux系统中常见的一些系统日志,以及他们在排查中的作用
03安全日志:/var/log/secure
该日志文件专门聚焦于身份验证和权限变更的环节,主要涵盖以下事件:
- 用户登录与注销:无论是通过 SSH、本地控制台还是其他方式,登录的成功与失败尝试都会被记录。
- 权限提升(提权):使用
sudo或su切换到高权限用户(尤其是 root)的行为,其执行的具体命令会被完整记录。 - 账户状态变更:账户的锁定、解锁,以及密码修改等操作。
- PAM 相关事件:由可插拔认证模块(PAM)产生的错误和警告信息。
- 其他安全事件:如
useradd创建新用户、groupadd创建新用户组等。 - 出于安全考虑,默认仅 root 用户可读
它记录的是认证与授权事件,而不是“访问”或“代码执行”事件。只要攻击者没有通过系统的认证机制(如 SSH、本地终端、su/sudo登录)获得一个“登录会话”,/var/log/secure中就不会出现任何与之相关的记录,也就是命令执行和反弹shell获取到shell是不会记录的
常见的日志格式
/var/log/secure遵循标准的 syslog 格式,每一行通常由四列构成:
- 时间戳:事件发生的日期和时间(如
Oct 10 10:00:01)。 - 主机名:产生日志的服务器主机名。
- 服务/程序名[PID]:产生事件的程序及其进程 ID(如
sshd[12345]、sudo:)。 - 事件具体信息:日志的核心内容,描述了具体发生了什么。
| 事件类型 | 日志示例(节选) | 解读要点 |
|---|---|---|
| SSH 登录成功 | sshd[12345]: Accepted password for username from 192.168.1.100 port 12345 ssh2 |
用户username从 IP192.168.1.100通过密码成功登录。若使用密钥,则显示Accepted publickey |
| SSH 登录失败 | sshd[12346]: Failed password for username from 192.168.1.100 port 12346 ssh2 |
上述用户从同一 IP 尝试密码登录失败。若用户不存在,会显示invalid user |
sudo 提权 | sudo: username : TTY=pts/0 ; PWD=/home/username ; USER=root ; COMMAND=/bin/ls /root | 用户username在终端pts/0下,以 root 身份执行了/bin/ls/root命令。 COMMAND字段是关键线索。 |
||
| 会话打开 | pam_unix(sshd:session): session opened for user root by (uid=0) |
用户root的会话被成功打开,通常紧随登录成功日志出现。 |
| 用户/组创建 | useradd[1661]: new user: name=bb, UID=501, GID=501... |
系统中新建了一个名为bb的用户,UID 为 501。 |
在应急排查中的核心作用
/var/log/secure是判断系统是否遭遇账户入侵和暴力破解的首要证据来源。其排查逻辑通常围绕以下场景展开:
场景一:确认是否遭受 SSH 暴力破解
攻击的典型特征是短时间内出现大量来自同一或不同 IP 的“Failed password”记录。
1. 统计攻击源 IP(找出“凶手”)
示例 · BASH
bash
grep "Failed password" /var/log/secure | awk '{print $(NF-3)}' | sort | uniq -c | sort -nr | head
命令解读:提取所有失败登录记录中的 IP 地址字段($(NF-3)或$11均可),排序后统计频次,列出尝试次数最多的 IP。输出结果可能显示某个 IP 尝试了数十万次登录。
2. 检查是否有爆破成功的迹象(最关键的一步)
在确认存在大量失败记录后,必须立即检索是否有来自同一攻击源的成功登录。这是判断系统是否已被攻陷的转折点。
示例 · BASH
bash
grep "Accepted" /var/log/secure | grep "<攻击源IP>"
如果上述命令有输出,意味着攻击者已经成功猜解出密码或密钥,系统应被视为已失陷,需立即启动入侵响应流程。
3. 确认攻击的时间范围与目标账户
示例 · BASH
# 查看爆破的起止时间
grep "Failed password" /var/log/secure | head -1
grep "Failed password" /var/log/secure | tail -1
# 统计被尝试爆破的用户名
grep "Failed password" /var/log/secure | grep -oP 'for \K[^ ]+' | sort | uniq -c | sort -nr
这有助于了解攻击的持续时间和攻击者针对的账户(如 root 或常见系统账户)。
场景二:审计异常权限提升(sudo)行为
攻击者在获得初始立足点后,通常会尝试提权。/var/log/secure中的sudo记录可以揭示这一点。
排查要点:
- 异常用户提权:一个平时不使用的服务账户突然出现
sudo成功记录。 - 异常命令执行:
COMMAND字段显示执行了敏感操作,如cat /etc/shadow、useradd、修改authorized_keys等。 - 异常时间与终端:提权发生在非运维时段,或来自不常见的
TTY(如非交互式的?)。
示例 · BASH
# 快速查看所有成功的 sudo 命令执行记录
grep "sudo:.*COMMAND=" /var/log/secure
场景三:发现攻击者的持久化与账户操作痕迹
攻击者为了维持访问,可能会创建后门账户或修改认证配置。
示例 · BASH
# 检查是否有新增用户
grep "new user" /var/log/secure
# 检查是否有用户被添加到特权组(如 wheel, sudo)
grep -E "new group|added to group" /
# web安全 # 企业安全
免责声明
1.一般免责声明:本文所提供的技术信息仅供参考,不构成任何专业建议。读者应根据自身情况谨慎使用且应遵守《中华人民共和国网络安全法》,作者及发布平台不对因使用本文信息而导致的任何直接或间接责任或损失负责。
2. 适用性声明:文中技术内容可能不适用于所有情况或系统,在实际应用前请充分测试和评估。若因使用不当造成的任何问题,相关方不承担责任。
3. 更新声明:技术发展迅速,文章内容可能存在滞后性。读者需自行判断信息的时效性,因依据过时内容产生的后果,作者及发布平台不承担责任。
已在FreeBuf发表 0 篇文章
本文为 独立观点,未经授权禁止转载。
如需授权、对文章有疑问或需删除稿件,请联系 FreeBuf 客服小蜜蜂(微信:freebee1024)
被以下专辑收录,发现更多精彩内容
+ 收入我的专辑
+ 加入我的收藏
相关推荐
- 0 文章数
- 0 关注者

文章目录
01前言
02linux中常见的日志
03安全日志:/var/log/secure
- 常见的日志格式
- 在应急排查中的核心作用
- 场景一:确认是否遭受 SSH 暴力破解
- 1. 统计攻击源 IP(找出“凶手”)
- 2. 检查是否有爆破成功的迹象(最关键的一步)
- 3. 确认攻击的时间范围与目标账户
- 场景二:审计异常权限提升(sudo)行为
- 场景三:发现攻击者的持久化与账户操作痕迹
- 场景四:按照时间点排查登录的记录
04系统调用层面记录:/var/log/audit/
- 规则配置
- 文件监控
- 账户与认证文件
- 持久化位置
- SSH 密钥(攻击者常留后门的位置)
- 系统调用监控
- 命令执行(必配)—— 捕获 execve,还原攻击者敲了什么
- 权限变更(发现提权路径)
- 网络连接(捕获反弹 shell 的外连,需内核支持)
- 日志格式:多记录构成一个“事件”
- 应急响应中最关键的几类记录与字段
- 在应急排查中的核心用法:ausearch与 aureport
- 场景一:定位入口与锚定追踪线索(AUID)
- 1. 查找用户登录事件,确定 auid
- 2. 围绕 auid拉出该会话的全部行为
- 场景二:还原命令执行(追踪 EXECVE)
- 1. 查看某个 auid下执行过的所有命令
- 2. 快速筛查反弹 shell 或下载行为的关键词
- 场景三:文件访问与持久化排查
- 1. 查询对关键文件的访问(依赖预先配置的 watch 规则)
- 场景四:统计概览(使用 aureport)
- 按用户统计事件(快速发现哪个 auid/uid行为异常频繁)
- 按可执行文件统计(快速发现异常程序)
- 查看所有失败事件
定时任务日志:/var/log/cron
- 日志格式
- 在应急排查中的核心用法:追踪持久化
- 场景一:快速筛查可疑的调度命令
- 场景二:定位“谁”在调度可疑任务
- 场景三:确认任务是否“真的”在运行
- 场景四:与配置源交叉验证
当前与历史登录:wtmp / btmp / lastlog / utmp
- 应急排查中的核心用法:
- 1. 快速判断某个账户是否“活着”
- 2. 排查暴力破解的成功突破点
- 3. 发现“幽灵会话”
- 4. 追溯系统重启时间线
命令历史:~/.bash_history(及其他 *_history)
- 感谢阅读