遇到攻击先别急着重启服务或批量封IP，第一步应该打开Web访问日志、系统认证日志和网络连接日志，先锁定攻击时间窗口与异常来源IP，范围会快速收缩。下面按排查顺序说明哪些日志优先看、怎么看。
服务器被攻击怎么查日志：先确定时间点再翻三类文件
攻击排查最怕没有时间锚点，先问自己：业务异常从什么时候开始？监控告警最早出现在哪一分钟？把这个时间点作为中心，前后各扩15到30分钟,基本能覆盖大多数攻击动作。
Linux服务器被攻击日志在哪里看：先记住这几个目录
- Web访问日志：Nginx通常在
/var/log/nginx/access.log，Apache在/var/log/apache2/access.log或/var/log/httpd/access_log - 系统认证日志：CentOS/RHEL系看
/var/log/secure，Debian/Ubuntu系看/var/log/auth.log - 系统消息日志：
/var/log/messages或/var/log/syslog - 登录失败记录：命令
lastb可查看SSH暴力破解失败记录，last看成功登录 - 当前网络连接：
ss -antp比旧的netstat更快，能直接看到进程名和PID
先用一条命令捞出异常IP
进入日志目录后，按访问量聚合IP是最快的方式，Nginx日志默认格式下,第一条字段是客户端IP：
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -20
如果某个IP请求次数明显高于其他地址，且User-Agent像扫描器或者请求路径集中在/wp-admin、/login、/.env,基本可以判定为攻击源。
网站被攻击后如何快速定位问题：按请求特征反查攻击类型
网站被攻击后如何快速定位问题，核心不是看谁来了，而是看它做了什么，访问日志里的请求行、状态码、User-Agent三个字段,基本能还原攻击路径。
从状态码判断攻击结果
- 大量
404：多数是目录扫描或漏洞探测，攻击者在找后台、备份文件、测试路径 - 大量
500或502：可能已经触发应用错误，优先检查应用日志和数据库连接 - 大量
200但请求路径重复：可能是CC攻击或刷接口，需要进一步看请求频率和来源分布 - 大量
401/403：说明有人尝试访问未授权资源，认证日志要同步看
从请求路径识别攻击意图
下面这些路径出现频率突然升高，基本不用犹豫,直接按攻击处理：
-
/wp-login.php、/xmlrpc.php：WordPress暴力破解或漏洞利用 /.env、/.git/config、/backup.zip：敏感文件探测/api/下某个接口被高频调用：可能是撞库、刷短信、遍历数据- 含
union select、sleep(、<script>等字符的请求：SQL注入或XSS探测
可以用一条命令过滤可疑路径：
grep -E "wp-login|xmlrpc|.env|.git|union|select|sleep" /var/log/nginx/access.log | tail -50
网站日志分析查找攻击源时别忘了Referer和UA
真实用户和自动化攻击在User-Agent上有明显差异，Python脚本、sqlmap、Nmap等工具都有独特UA特征,把UA聚合一下：
awk -F'"' '{print $6}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -20
如果出现大量以python-requests、sqlmap、curl/开头的UA,直接封禁对应IP或UA即可。
被攻击后先查Web日志还是系统日志：优先级排序
不同攻击类型对应的第一优先级日志不同，被攻击后先查哪个日志文件,可以用下面这个表快速对应。
| 攻击现象 | 优先查的日志 | 关键字段 | 排查目标 |
|---|---|---|---|
| 网站打不开、响应慢 | Web访问日志 | 状态码、请求路径、IP | 判断CC攻击还是资源耗尽 |
| 服务器CPU/内存突然飙升 | 系统消息日志、进程列表 | 异常进程、外联IP | 确认是否被植入挖矿或后门 |
| 后台登录失败提醒增多 | 系统认证日志 | 登录用户、来源IP、失败次数 | 发现暴力破解和撞库 |
| 服务器主动外联陌生IP | 网络连接日志、DNS日志 | 目的IP、端口、进程 | 定位Webshell或C2通信 |
| 数据库查询变慢 | 数据库慢查询日志 | SQL语句、执行时间 | 发现拖库或恶意查询 |
Web日志永远是第一优先级
行业共识认为，多数互联网攻击都会在HTTP层留下痕迹，无论最终目标是拿到服务器权限还是拖走数据，攻击者几乎都要通过Web入口进来，所以先看Web访问日志,通常能在几分钟内找到异常请求。
系统日志补充主机侧行为
Web日志只能告诉你“对方做了什么请求”，系统日志能告诉你“这个请求是否成功变成了系统动作”，比如Web日志里出现
/upload路径的POST请求，系统日志里同时出现www-data用户创建新进程,那基本可以确认文件上传漏洞被利用。
从边界到主机：日志排查顺序决定效率
很多运维一上来就翻系统日志，结果被海量SSH扫描记录淹没，更高效的顺序是从边界到主机,逐层收缩。
第一步：看边界设备或负载均衡日志
如果前面有CDN、WAF、Nginx反代，先看它们的访问日志，因为这里能拿到真实攻击源，也能过滤掉大量静态资源请求，避免干扰，国内云服务器上的网站攻击排查，日志路径和自建机房略有不同，云平台通常提供安全组日志和VPC流日志,能直接看到来源IP和端口。
第二步：看应用服务日志
确认问题请求进了哪台后端、哪个应用，Tomcat的catalina.out、Node的PM2日志、PHP-FPM的慢日志,都在这个环节查看。
第三步：看主机系统日志
只有确认攻击已经影响到主机层，或者怀疑被植入后门，才深入/var/log/secure、/var/log/audit/audit.log这类系统日志，此时通常要配合ps aux、crontab -l、systemctl status一起排查。
一条时间线串联所有日志
业内专家指出，日志排查最容易忽略的是时间同步，如果Web服务器、应用服务器、数据库服务器之间时间不同步，跨日志关联会非常痛苦，先用date命令确认各节点时间一致，再把所有日志按时间轴对齐,攻击路径会清晰很多。
常见攻击场景下的日志排查实操
SSH暴力破解：看认证日志和失败记录
CentOS下直接：
grep "Failed password" /var/log/secure | awk '{print $(NF-3)}' | sort | uniq -c | sort -nr | head
Ubuntu下换成/var/log/auth.log，这条命令能列出尝试SSH登录失败最多的来源IP，多数暴力破解来自境外VPS或扫描网络，看到几十次以上的失败记录,直接在防火墙封禁即可。
CC攻击：看Web日志请求频率
CC攻击的特点是大量真实HTTP请求打向同一个URL，状态码可能都是200,这时按IP加URI聚合：
awk '{print $1, $7}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -20
如果某个IP对同一个接口请求成千上万次，且时间间隔极短，就是CC攻击，可以在Nginx层配置limit_req或直接封禁该IP。
Webshell排查：看Web日志中的POST请求和系统进程
Webshell访问通常表现为对某个非正常路径的POST请求，且返回200，比如
/upload/shell.php、/images/x.jsp，在Web日志里用grep POST过滤出非登录接口的POST请求,再和当前时间点出现的异常进程交叉比对。
grep "POST" /var/log/nginx/access.log | grep -v "/login" | tail -100
同时用ls -lt /tmp /var/tmp /dev/shm查看最近修改的可执行文件,Webshell常藏在这些可写目录。
日志排查的三个常见误区
- 只看当前日志不看历史日志：很多攻击在爆发前有数天甚至数周的探测行为，历史日志里往往能找到最早的踩点记录，日志轮转后记得查
access.log.1、access.log.gz - 只封单IP不分析攻击模式：攻击者通常使用代理池或云函数切换IP，单纯封一个IP解决不了问题，要分析请求特征，比如固定UA、固定路径、固定参数，按特征封禁更有效
- 忽略应用层日志：Nginx日志正常不代表应用没被攻击，很多慢查询、逻辑漏洞、越权操作只体现在应用日志和数据库慢查询日志里
锁定攻击范围的关键不是日志数量，而是先有明确时间锚点，再按Web日志、系统认证日志、网络连接日志的顺序交叉验证，先查Web访问日志，再查系统登录行为，最后看网络外联,这套顺序多数情况下能把定位时间压缩到半小时以内。
Q&A：服务器被攻击日志排查常见问题
被攻击后先查哪个日志文件能最快定位？
优先查Web访问日志，路径通常是/var/log/nginx/access.log或/var/log/apache2/access.log，如果业务异常集中在网站访问，这个文件能在几分钟内给出异常IP和请求路径，Web日志没有异常时，再查系统认证日志/var/log/secure或/var/log/auth.log。
网站日志里怎么判断是CC攻击还是普通扫描？
CC攻击的典型特征是同一IP或同一组IP对某个URL高频请求，状态码多为200，请求路径固定，扫描行为则是路径五花八门，大量404，请求间隔不规律，用awk按IP加URI聚合,看请求次数和路径集中度就能区分。
服务器被攻击后日志被删了怎么办？
先检查日志服务是否还保留远程备份，再查看/var/log目录下是否有轮转文件或压缩包，如果攻击者清理了本地日志，可以通过网络设备日志、云平台流日志、WAF日志等外部日志重建攻击时间线，多数云厂商会保留一定周期的安全审计记录,可以直接在控制台导出。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/654327.html
