当服务器遭遇安全事件时，第一时间的响应至关重要。无论是暴力破解尝试、错误配置的防火墙，还是更严重的入侵，Linux系统的日志文件都记录着事件的真相。本文将介绍在Ubuntu和Red Hat服务器上调查可疑安全事件时，应立即检查的7个关键日志文件。
为什么日志分析如此重要？
安全事件发生后的第一小时被称为"黄金时间"。在这段时间内，攻击者可能仍在系统中活动，或者刚刚离开，留下了鲜活的痕迹。正确分析日志不仅能帮助我们了解发生了什么，还能提供关键线索来：
-
确定攻击的来源和方法 -
评估受影响的系统范围 -
收集用于取证的证据 -
防止类似事件再次发生
现在，让我们深入了解这7个关键日志文件，看看它们能告诉我们什么。
1. 身份验证日志：/var/log/auth.log (Ubuntu) / /var/log/secure (Red Hat)
这些文件记录了所有与身份验证相关的事件，是检测未授权访问的第一站。
追踪内容：
-
SSH登录尝试（成功和失败） -
sudo命令使用记录 -
权限提升活动 -
用户切换操作
实用命令：
# 检查失败的登录尝试
grep "Failed password" /var/log/auth.log
# 查看成功的登录
grep "Accepted password" /var/log/auth.log
# 检查特定IP的登录尝试
grep "sshd.*[IP地址]" /var/log/auth.log
实例分析：
看到以下日志行时应警惕：
Jun 10 15:23:15 server sshd[12345]: Failed password for root from 192.168.1.100 port 54321 ssh2
Jun 10 15:23:20 server sshd[12346]: Failed password for root from 192.168.1.100 port 54322 ssh2
Jun 10 15:23:25 server sshd[12347]: Failed password for root from 192.168.1.100 port 54323 ssh2
分析要点：短时间内多次尝试以root身份登录失败，且来源IP和端口变化规律，这是典型的暴力破解攻击特征。
2. 系统日志：/var/log/syslog (Ubuntu) / /var/log/messages (Red Hat)
这些是系统的"黑匣子"，记录了从内核到应用层的各种事件。
追踪内容：
-
系统启动和关闭 -
服务崩溃和重启 -
异常的守护进程活动 -
内核警告和错误
实用命令：
# 查看最近的系统事件
tail -n 100 /var/log/syslog
# 检查特定时间段的日志
grep "Jun 10 15:" /var/log/syslog
# 查找服务异常
grep -i "error|fail|critical" /var/log/syslog
实例分析：
可疑的服务日志示例：
Jun 10 15:30:12 server systemd[1]: ssh.service: Main process exited, code=killed, status=9/KILL
Jun 10 15:30:13 server systemd[1]: ssh.service: Unit entered failed state
Jun 10 15:30:15 server systemd[1]: ssh.service: Started OpenBSD Secure Shell server.
分析要点：SSH服务被终止（可能是攻击者为了清除当前会话）然后迅速重启，这可能是攻击者在尝试掩盖行踪。
3. 登录失败日志：/var/log/faillog
这个日志提供了每个用户的登录失败尝试汇总，是快速识别异常活动的有力工具。
追踪内容：
-
按用户名统计的失败登录次数 -
最后一次失败尝试的时间 -
失败尝试的终端
实用命令：
# 查看所有用户的失败登录统计
faillog
# 重置特定用户的失败计数
faillog -u username -r
实例分析：
使用faillog命令后可能看到类似输出：
Username Failures Maximum Latest
root 50 0 06/10/22 15:23:45 +0800
admin 30 0 06/10/22 15:24:10 +0800
www-data 0 0 Never logged in
分析要点：root和admin用户有大量失败尝试，而且最后尝试时间接近，这表明攻击者可能正在尝试针对常见管理账户的暴力破解。
4. 审计日志：/var/log/audit/audit.log（需安装AuditD）
AuditD是Linux的审计系统，提供了对系统调用和文件访问的详细跟踪。
追踪内容：
-
文件访问和修改 -
系统调用 -
命令执行 -
用户权限变更
实用命令：
# 查看用户执行的命令和认证
ausearch -m USER_CMD,USER_AUTH
# 查看对特定文件的访问
ausearch -f /etc/passwd
# 检查特定时间段的审计事件
ausearch -ts today -te now
实例分析：
可疑的审计日志：
type=USER_CMD msg=audit(1654848300.452:3145): pid=12345 uid=0 auid=1000 ses=1 msg='cwd="/home/user" cmd="cat /etc/shadow" terminal=pts/0 res=success'
分析要点：非root用户（auid=1000）执行了需要root权限的命令（cat /etc/shadow），这可能表明权限提升攻击成功。
国内环境提示：在中国的服务器环境中，AuditD并非默认安装。如果你的服务器处于敏感行业（如金融、政府），强烈建议安装此工具以满足等级保护要求。
5. Web服务器日志：/var/log/nginx/access.log / /var/log/apache2/access.log
对于运行Web服务的服务器，这些日志记录了所有HTTP请求，是识别Web攻击的关键。
追踪内容：
-
HTTP请求方法和URL -
响应状态码 -
客户端IP和User-Agent -
请求处理时间
实用命令：
# 查找可疑的SQL注入尝试
grep -i "select|union|insert" /var/log/nginx/access.log
# 检查大量404错误（可能是目录扫描）
grep " 404 " /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -nr
# 查找异常的User-Agent
grep -i "curl|wget|python|go-http|sqlmap" /var/log/nginx/access.log
实例分析：
可疑的Web请求模式：
192.168.1.100 - - [10/Jun/2022:15:40:12 +0800] "GET /wp-admin/install.php HTTP/1.1" 404 0 "-""sqlmap/1.5.12#stable"
192.168.1.100 - - [10/Jun/2022:15:40:15 +0800] "POST /wp-login.php HTTP/1.1" 200 1234 "-""Mozilla/5.0"
分析要点：第一行显示使用sqlmap工具（一种SQL注入测试工具）尝试访问WordPress安装页面，随后是对登录页面的POST请求，这可能是攻击者在尝试利用WordPress漏洞。
6. 最后登录日志：/var/log/lastlog
这个日志显示每个用户最后一次成功登录的时间和位置，有助于识别异常登录模式。
追踪内容：
-
用户的最后登录时间 -
登录的终端或IP -
长期未活动的账户突然被使用
实用命令：
# 查看所有用户的最后登录记录
lastlog
# 检查特定用户的最后登录
lastlog -u username
实例分析：
lastlog命令输出示例：
Username Port From Latest
root pts/0 192.168.1.100 Wed Jun 10 15:45:12 +0800 2022
admin pts/1 192.168.1.101 Never logged in
backup pts/2 192.168.1.102 Sat Jan 01 00:00:00 +0800 2022
分析要点：backup用户在长时间不活动后突然登录，而admin用户显示从未登录过却有活动，这些都是值得调查的异常情况。
7. 系统消息缓冲区：/var/log/dmesg
内核环缓冲区捕获硬件问题或低级别警报，这些警报可能不会出现在其他地方。
追踪内容：
-
内存警告 -
I/O错误 -
驱动程序异常 -
硬件相关的安全问题
实用命令：
# 查看完整的dmesg日志
dmesg | less
# 查找可疑的内存访问
dmesg | grep -i "memory|segfault"
# 检查异常的USB设备连接（可能是恶意设备）
dmesg | grep -i "usb"
实例分析：
可疑的内核消息：
[12345.678901] general protection fault: 0000 [#1] SMP
[12345.678902] Process bash (pid: 1234, stack limit = 0x00007ffabcd0e000)
[12345.678903] RIP: 0033:0x7f98765432ba
分析要点：程序崩溃可能是缓冲区溢出攻击的结果，特别是如果这发生在关键系统进程或服务中。
日志分析的最佳实践
在处理这些日志时，以下是一些专业建议：
-
建立基线：在正常情况下了解您的系统日志是什么样子的，这样异常情况更容易被发现 -
使用日志聚合工具：考虑使用ELK Stack（Elasticsearch、Logstash、Kibana）或Graylog等工具集中管理日志 -
设置日志轮转：确保日志文件不会无限增长，但也要保留足够长的历史记录用于调查 -
实施完整性监控：使用AIDE或Tripwire等工具监控系统文件的变化 -
时间同步：确保所有服务器使用NTP保持时间同步，这对事件关联至关重要
常见攻击模式及其日志特征
了解常见的攻击模式可以帮助您更快地识别安全事件：
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
安全事件响应流程
当您通过日志发现可疑活动时，建议按照以下流程进行处理：
-
识别和确认：确认是否确实存在安全事件，收集初步证据 -
遏制：采取措施防止事件扩大，如断开网络连接或停止受影响的服务 -
根除：移除恶意软件，修复被利用的漏洞 -
恢复：恢复系统到正常运行状态，确保安全措施到位 -
总结经验：分析事件原因，更新安全策略和防御措施
结语
当安全事件发生时，每一秒都至关重要。日志是揭示真相的关键，知道在哪里查找能够让您快速明确问题，并在事态扩大前解决根本原因。
养成定期检查这些关键日志的习惯，不仅能帮助您在安全事件发生时迅速响应，还能帮助您了解系统的正常行为，从而更容易识别异常情况。记住，最好的防御始于了解您正在保护的系统。
您的服务器安全事件处理经验是怎样的？有没有通过日志分析成功阻止过安全威胁？欢迎在评论区分享您的经验和见解！
关注我们的公众号，并给本文点赞，点个推荐支持一下吧！您的每一个小红心，都是我坚持创作优质内容的最大动力
原文始发于微信公众号（SecLab安全实验室）：服务器被黑后的第一步：7个必看日志揭示攻击者的一举一动
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论