服务器被攻击后第一步应当立即查看系统登录日志与Web访问日志，重点追踪认证失败记录和异常来源IP，先确认攻击入口，再决定后续封禁和加固方案。这一步能帮你快速判断是暴力破解、漏洞利用还是Web应用层攻击，避免在错误方向浪费宝贵时间。
为什么说日志是攻击后的第一现场
服务器出事之后,很多人第一反应是杀毒、关端口、重启服务，但这些都是防御动作，真正能告诉你发生了什么、攻击者从哪里进来的，只有日志文件，系统管理员社区广泛认可一个观点：日志是服务器行为的唯一客观记录。
服务器被攻击后怎么排查访问日志,本质上是在回答三个问题：
- 攻击者通过哪个入口进来的
- 攻击者执行了什么操作
- 攻击是否还在进行中
这三个问题的答案全部藏在日志里,登录日志记录账号认证过程，访问日志记录HTTP请求的来龙去脉，前者帮你识别系统层面的入侵痕迹，后者帮你发现Web应用的攻击行为，两者配合，基本能还原攻击全貌。
第一步：先看系统登录日志，确认有没有人“进去过”
不同类型系统的日志路径不同,先别乱翻文件，直接按系统类型去对应位置找。
Linux系统的登录日志怎么看
Linux下最关键的三个文件是/var/log/secure（CentOS/RHEL系）、/var/log/auth.log（Debian/Ubuntu系）和/var/log/btmp（记录失败登录尝试）。
实际的排查思路是先看认证记录里有没有大量“Failed password”条目，如果某个IP在短时间内尝试了几十上百次密码，那就是典型的SSH暴力破解，真正的攻击往往不只有暴力破解，攻击者成功登录后会留下shell记录，所以还要检查.bash_history和用户账号列表，看看有没有新增的root权限账号。
登录日志分析实操命令如下：
last -n 20查看最近的登录记录，确认登录来源IPlastb -n 50查看失败登录尝试，定位暴力破解来源cat /var/log/secure | grep "Accepted"筛选所有成功登录的记录awk '{print $1}' /var/log/secure | sort | uniq -c | sort -nr按IP统计登录尝试次数
如果发现来自境外IP的成功登录记录,且时间点与攻击时间吻合，基本可以判定账号已被攻破，需要立刻禁用相关账号并检查系统后门。
Windows服务器的登录日志和Linux的区别
Windows的事件查看器里,事件ID 4624表示成功登录，4625表示登录失败，重点看4625事件的前后关联，攻击者通常会从某个IP发起大量连续登录尝试，然后突然有一次4624成功。
Windows日志分析还有个容易被忽视的点：计划任务日志和PowerShell操作日志，攻击者拿到权限后往往通过计划任务维持权限，通过PowerShell执行恶意命令，这部分日志在“Microsoft-Windows-TaskScheduler/Operational”和“Microsoft-Windows-PowerShell/Operational”通道下，服务器被攻击后第一步做什么，看完登录日志就要顺着时间线检查这些隐蔽入口。
第二步：分析Web访问日志，找出攻击路径和攻击手法
登录日志确认的是系统层面的疑点,但对网站服务器来说，大部分攻击发生在Web层，Nginx和Apache的访问日志记录了每一个HTTP请求，攻击者的扫描、探测、利用过程都会在这里留下痕迹。
Nginx和Apache的Web日志在哪
| 服务器软件 | 访问日志路径 | 错误日志路径 |
|---|---|---|
| Nginx | /var/log/nginx/access.log |
/var/log/nginx/error.log |
| Apache (CentOS) | /var/log/httpd/access_log |
/var/log/httpd/error_log |
| Apache (Debian) | /var/log/apache2/access.log |
/var/log/apache2/error.log |
日志中每秒的请求数、状态码异常、请求路径不合法、User-Agent可疑，这些都不是正常用户会产生的东西。
访问日志分析的基础方法是按IP维度聚合,找出访问量异常大的源IP，配合查看具体的请求路径，如果大量请求集中在某个特定接口，比如/wp-login.php、/admin.php或/api/v1/upload，就是攻击者已经在定向爆破或探测漏洞。
用日志分析工具快速定位异常IP
手动翻日志效率太低,生产环境中访问日志动辄几个GB，直接人工按行看完不现实，实际工作中更高效的服务器被攻击怎么排查访问日志的方式是借助命令做初步筛选，再结合分析工具深入排查。
先用下面的命令从原始日志中提取高频IP：
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
- 输出结果里请求量排名前十的IP,如果某个IP的请求数是第二名十倍以上，基本就是攻击源
- 接着用
grep "攻击IP" access.log筛选该IP的所有请求，逐条看请求的具体路径和参数 - 再用
tail -f access.log观察该IP是否还在继续请求，判断攻击是否还在持续
GoAccess、ELK这类日志分析平台适合攻击结束后的复盘和长期监控，但攻击发生时的第一轮排查还是命令行效率最高。
网站日志分析如何判断攻击是否成功
只看请求日志还不够,要判断攻击是否得手，需要检查响应状态码，攻击者对某个漏洞利用接口发送payload后，如果返回200，说明接口存在且请求被处理了，如果返回404，通常是扫描行为，攻击者大概率没找到相关入口。
这个判断逻辑对SQL注入和XSS攻击都适用,真正的成功利用会让服务器返回异常内容，比如数据库错误信息、命令执行结果回显、或者页面被插入恶意代码，看到这类响应，说明攻击拿到了实际效果，需要立刻进入应急响应流程，断网、隔离、取证。
第三步：结合系统日志和业务日志交叉验证攻击源
单看系统日志或单看Web日志都有盲区,系统日志里看到暴力破解，但Web日志里没有对应的异常请求，说明攻击者可能还没进入Web层，反过来，Web日志里出现大量敏感接口请求，但系统日志里没有异常登录，说明攻击走的是应用层漏洞，并没有获得系统账号权限。
行业共识认为,完整的攻击链路往往涉及多层入口，攻击者可能先通过Web漏洞上传webshell，再用webshell执行命令创建系统账号，最后通过SSH登录，攻击者的完整动作链条，需要将系统登录日志、Web访问日志、应用错误日志三类日志按照时间线对齐来看。
具体做法是取异常时间段内Web日志中的高频IP,去系统日志里查该IP有没有对应的认证记录，有认证记录且结果是Accepted，说明攻击者已经拿下系统权限，级别最高，需要立即断网处理，没有认证记录，说明攻击还停留在应用层，处理优先级相对低，可以边防御边排查。
应急防护动作：看完日志立刻要做的三件事
日志分析的目的是指引接下来的处理动作,确认攻击源和攻击方式后，不用等全部分析完成，优先做下面三件事：
- 封禁攻击IP：使用防火墙或安全组规则封禁已确认的攻击源IP，比如
iptables -A INPUT -s 攻击IP -j DROP或者直接在云控制台的安全组里添加拒绝规则 - 禁用被攻破的账号：在确认攻击者已获得某个账号权限的情况下，立即锁定该账号，清理其中的授权文件和计划任务
- 备份日志文件：把当前的登录日志、访问日志、错误日志全部复制一份到独立目录或异地存储，留存攻击证据，为后续溯源和加固做准备
对于一个使用便宜高防服务器的站点来说,攻击流量过大时高防IP能扛住一部分流量清洗，但日志分析这一步不能省，清洗的是流量，不解决漏洞本身。
常见误区：哪些日志分析方式会让你走弯路
日志分析过程中有几种高频错误做法,新手管理员经常踩坑。
- 只查访问日志不查错误日志：Nginx和Apache的error.log里记录了后端服务的异常，比如SQL语句报错、PHP执行错误，这些是攻击payload触发漏洞后留下的直接证据，比访问日志更接近攻击真相
- 只看当前时间段的日志：攻击者不会只在攻击发生时留下痕迹，可能会提前部署后门，过几天再回来，建议至少回溯攻击时间点前一两周的日志，看看有没有早期的探测行为
- 忽略日志轮转：生产环境大多配置了logrotate按月或按天切割日志，遇到攻击时间比较久远的情况，要解压查看.gz结尾的历史日志，别只盯当前文件
- 封IP一招了事：简单的IP封禁防不住分布式攻击，攻击者会换IP继续打，封了A段的IP，B段的IP跟着就来，封禁的同时要找到漏洞本身并修复，把根因解决掉
服务器安全日志分析常见问题
日志被攻击者篡改或删除，还能追查到吗
有一定难度,但不代表无迹可寻，攻击者可能会清除/var/log下的日志文件，但数据并未彻底消失，磁盘上仍可能存在残留，可以尝试用lsof | grep deleted查看已被删除但仍被进程占用的日志句柄，获取部分内存中的日志，云平台的安全组流量记录、负载均衡访问日志、数据库慢查询日志，都是独立于系统日志的记录，可以交叉对比还原部分攻击过程，事前配置远程日志服务器，让日志实时传输到独立设备，是最稳妥的防篡改方案。
为什么日志里全是扫描请求，但找不到真正的攻击行为
互联网上到处是自动化扫描脚本,日志中大量404和畸形请求属于常态背景噪音，真正需要关注的是那些复杂的业务逻辑，正常的扫描器不会尝试登录后台，更不会修改POST参数，建议对日志按请求方法分类，单独分析GET之外的POST、PUT、DELETE请求，把高频IP按请求特征分组，关注那些携带特殊参数或有明显Fuzz行为的请求。
服务器被攻击后从哪里看攻击者用什么漏洞进来的
结合三处信息交叉定位：Web日志中不正常的请求路径和方法判断应用漏洞类型，系统日志中的认证记录判断账号失陷，应用错误日志中的异常堆栈判断具体漏洞利用是否生效，这三处信息在时间线上能对上，就能精确定位漏洞名称和修复方案，对于部署了WAF的站点，WAF的拦截日志也记录了攻击payload特征，同样是重要参考。