服务器被黑后的第一步：7个必看日志揭示攻击者的一举一动

程序员晓晓

于 2025-06-19 14:33:29 发布

阅读量658

点赞数 11

CC 4.0 BY-SA版权

文章标签： web安全网络安全渗透测试计算机干货分享黑客技术编程

本文链接：https://blog.youkuaiyun.com/cxyxx12/article/details/148766092

当服务器遭遇安全事件时，第一时间的响应至关重要。无论是暴力破解尝试、错误配置的防火墙，还是更严重的入侵，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保持时间同步，这对事件关联至关重要

常见攻击模式及其日志特征

了解常见的攻击模式可以帮助您更快地识别安全事件：

攻击类型	日志特征	主要查看的日志文件
暴力破解	大量失败的登录尝试，通常针对常见用户名	auth.log/secure, faillog
权限提升	普通用户执行特权命令，SUID二进制文件的异常使用	audit.log, auth.log/secure
Web注入攻击	包含SQL语法的异常URL请求	nginx/apache access.log
恶意脚本执行	异常的cron作业，未知进程的启动	syslog/messages, auth.log
数据窃取	大量出站流量，对敏感文件的读取	audit.log, application logs