1. 项目概述从日志中“听”到攻击的脚步声做运维或者搞网站开发的朋友对“我们的系统检测到您的计算机网络中存在异常流量”这类提示肯定不陌生。很多时候这背后就是一场或大或小的DDoS攻击。服务器就像一家24小时营业的店铺正常访客络绎不绝但突然涌进来几百个彪形大汉他们不买东西就堵在门口大声喧哗让真正的顾客进不来——这就是DDoS攻击最形象的比喻。Nginx作为我们最常用的Web服务器和反向代理它的访问日志access.log就是店铺的监控录像完整记录了每一个“访客”的到访时间、意图和行为。能否从海量的、看似正常的日志条目里快速、准确地揪出那些“彪形大汉”是保障服务稳定性的第一道也是至关重要的一道防线。这个项目的核心就是教会你如何成为一名合格的“日志侦探”。我们不依赖昂贵的商业安全产品而是深入Nginx日志的细节通过一系列特征分析和命令行工具比如grep,awk,sort手动构建一套轻量但高效的异常流量识别体系。无论是运行在阿里云、腾讯云虚拟机还是自建物理机上的服务这套方法都能帮你快速定位问题为后续的封禁、限流等操作提供精准的数据支持。你会发现很多攻击的蛛丝马迹就明明白白地写在日志里只看你有没有一双会发现的眼睛。2. DDoS攻击特征与Nginx日志的映射关系要识别异常首先得知道正常是什么样子以及攻击通常会伪装或呈现出哪些异常。DDoS攻击种类繁多但反映在Nginx访问日志上主要有以下几类特征它们就像是攻击者留下的不同“脚印”。2.1 流量规模异常请求频率与并发连接数这是最直观的特征。正常用户访问一个页面会产生对HTML、CSS、JS、图片等有限数量资源的请求。而DDoS攻击尤其是HTTP Flood攻击旨在耗尽服务器资源其典型表现是单一IP的请求频率RPS急剧升高一个IP在一秒内发出数十、上百甚至上千个请求这远远超出了人类或正常爬虫的行为模式。总并发连接数暴增Nginx需要同时处理大量TCP连接导致worker_connections限制被快速占满新的合法用户无法建立连接。流量带宽激增如果攻击伴随大流量如UDP Flood、ICMP Flood虽然可能不直接体现在应用层日志但会导致服务器或虚拟机出口带宽被打满。在日志中的体现你需要统计每个$remote_addr客户端IP在单位时间如每秒、每分钟内的请求行数。一个在1分钟内出现数千条记录的IP嫌疑极大。2.2 请求模式异常URL、User-Agent与参数攻击者为了提高攻击效率或绕过简单的频率限制会使用工具构造请求。固定或随机攻击URL集中攻击某个耗时高的动态接口如/api/search或随机请求大量不存在的静态资源如图片、文件以消耗磁盘I/O和404处理逻辑。畸形或特殊的User-Agent大量请求使用相同的、伪造的或明显为工具生成的User-Agent字符串例如空User-Agent、包含“bot”、“scan”、“hack”等关键词或是极其冗长怪异的字符串。非常规HTTP方法频繁出现POST、PUT、DELETE等方法尤其是向静态资源发起这类请求或者大量使用HEAD方法进行侦查。重复或无效的查询参数参数值异常长、包含大量特殊字符或尝试进行注入攻击的Pattern。在日志中的体现你需要关注$request字段包含方法、URL和协议以及$http_user_agent字段。大量相似的、非常规的请求模式是重要线索。2.3 响应状态码分布异常正常网站的HTTP状态码分布有一定规律例如200成功和304未修改占绝大多数404未找到占一小部分。DDoS攻击会扭曲这个分布大量4xx状态码如果攻击目标是随机不存在的URL会导致404状态码比例异常高。如果攻击包含恶意参数可能触发400错误请求或413请求体过大。大量5xx状态码当攻击导致服务器资源如数据库连接池、内存耗尽无法正常处理请求时会产生大量的502网关错误、503服务不可用或504网关超时。这既是攻击的结果也是需要紧急告警的信号。异常比例的200状态码对于针对缓存或静态页面的攻击服务器可能仍能返回200但请求本身是恶意的。在日志中的体现$status字段是关键。快速分析不同状态码的计数和占比能立刻发现服务是正在被“探针”扫描4xx激增还是已经被“打挂”5xx激增。2.4 连接行为异常请求时长与连接状态即使请求频率不高一些慢速攻击如Slowloris也会通过保持长时间连接来耗尽服务器连接资源。请求处理时间request_time异常正常请求的处理时间应在几百毫秒以内。如果大量请求的request_time长达数秒甚至数十秒可能是后端应用被拖慢也可能是攻击者故意发送慢速请求。连接建立时间异常这需要更底层的网络监控但反映在应用层可能表现为TCP连接建立缓慢。注意要获取$request_time你需要在Nginx的log_format中明确定义并记录它。默认的combined格式不包含此字段。3. 实战基于命令行工具的日志特征分析理论说再多不如动手敲一行命令。我们假设你的Nginx日志格式是标准的combined路径为/var/log/nginx/access.log。下面将演示如何用Linux命令行这把“瑞士军刀”逐项提取上述攻击特征。3.1 识别高频攻击IP这是最常用、最有效的第一步。我们统计每个IP的请求数并排序。# 统计总访问次数前10的IP awk {print $1} /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -10 # 统计最近5分钟内访问次数前10的IP (假设日志时间格式为[day/month/year:hour:minute:second]) awk -v d1$(date --date-5 min [%d/%b/%Y:%H:%M:%S) -v d2$(date [%d/%b/%Y:%H:%M:%S) $4 d1 $4 d2 {print $1} /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -10输出示例2874 114.114.114.114 1567 203.0.113.5 892 198.51.100.23 123 192.0.2.1 ...如果发现某个IP在短时间内如5分钟产生了成千上万次请求它极有可能是攻击源。3.2 分析异常状态码分布状态码是服务健康度的晴雨表。# 统计所有状态码的出现次数和比例 awk {print $9} /var/log/nginx/access.log | sort | uniq -c | sort -nr # 单独查看404状态码的请求并统计来源IP TOP 10 awk $9 404 {print $1} /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -10 # 单独查看5xx状态码的请求服务器错误 awk $9 ~ /^5[0-9][0-9]$/ {print $1, $7, $9} /var/log/nginx/access.log | head -20实操心得突然激增的404可能意味着扫描器或目录爆破工具在活动。而502/503的频繁出现往往意味着后端应用如PHP-FPM、Tomcat或数据库已经因资源耗尽而崩溃需要立即扩容或重启服务同时查找攻击源。3.3 揪出可疑的请求模式和User-Agent攻击工具常常会留下“指纹”。# 1. 查找请求次数最多的URL$7通常是请求的路径 awk {print $7} /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -20 # 2. 查找频繁出现的特定攻击模式URL例如大量请求phpMyAdmin、wp-login等管理后台 grep -E (phpmyadmin|wp-login|admin|login\.php|api/v1) /var/log/nginx/access.log | awk {print $1} | sort | uniq -c | sort -nr | head -10 # 3. 分析User-Agent找出非浏览器或可疑的客户端 # 先列出所有User-Agent并统计日志中$12以后是User-Agent位置取决于log_format awk -F\ {print $6} /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -20 # 更精准地查找空User-Agent或包含特定关键词的请求 grep -i agent.- /var/log/nginx/access.log | wc -l # 统计空User-Agent grep -iE (bot|scan|spider|hack|python|curl|wget) /var/log/nginx/access.log | awk {print $1} | sort | uniq -c | sort -nr | head -10注意不能一概而论地将Python或curl的User-Agent判定为攻击很多合法的API调用和监控脚本也会使用。这里的关键是“异常频繁”和“伴随其他攻击特征”。需要结合IP、频率和请求路径综合判断。3.4 将异常流量单独归档grep命令的进阶用法正如热搜词里提到的我们可以利用grep将特定状态的请求如所有404或来自某个嫌疑IP的请求单独提取出来存入独立文件便于后续深度分析和取证。# 将今天所有状态码为404的请求单独存储到一个文件 grep HTTP/1\.[01] 404 /var/log/nginx/access.log /tmp/nginx_404_$(date %Y%m%d).log # 将来自特定嫌疑IP(如114.114.114.114)的所有请求单独存储 grep ^114\.114\.114\.114 /var/log/nginx/access.log /tmp/nginx_attack_ip_114.114.114.114.log # 结合日期和时间范围进行筛选 (例如筛选今天上午10点到11点的日志) awk -v d1[$(date %d/%b/%Y):10: -v d2[$(date %d/%b/%Y):11: $4 d1 $4 d2 /var/log/nginx/access.log /tmp/nginx_log_10am_11am.log这样做的好处原始日志文件得以保全所有可疑流量被浓缩到小文件中文件大小可能只有几MB方便你用less、vi仔细查看攻击者的完整行为链条或者打包发送给安全团队进行分析。4. 构建自动化监控与告警脚本手动分析是基础但真正的防御需要自动化。我们可以将上面的命令封装成Shell脚本定期如每分钟执行并设置阈值触发告警。4.1 脚本示例监控每分钟高频IP创建一个脚本/usr/local/bin/ddos_detect.sh#!/bin/bash LOG_FILE/var/log/nginx/access.log THRESHOLD500 # 阈值1分钟内请求超过500次视为异常 ALERT_FILE/tmp/ddos_alert.log LAST_MINUTE$(date -d 1 minute ago [%d/%b/%Y:%H:%M) # 分析上一分钟的日志找出超过阈值的IP awk -v d$LAST_MINUTE $4 ~ d {print $1} $LOG_FILE | sort | uniq -c | while read count ip; do if [ $count -gt $THRESHOLD ]; then echo $(date): 检测到高频请求IP: $ip, 请求次数: $count (阈值: $THRESHOLD) $ALERT_FILE # 这里可以添加自动封禁IP的命令例如 # iptables -A INPUT -s $ip -j DROP # 或者调用云服务商的API进行封禁 fi done # 检查是否有5xx错误激增 (例如每分钟超过100个5xx错误) FIVEXX_COUNT$(awk -v d$LAST_MINUTE $4 ~ d $9 ~ /^5[0-9][0-9]$/ {count} END{print count0} $LOG_FILE) if [ $FIVEXX_COUNT -gt 100 ]; then echo $(date): 警告上一分钟5xx错误数激增: $FIVEXX_COUNT $ALERT_FILE fi然后通过Crontab设置每分钟执行一次* * * * * root /usr/local/bin/ddos_detect.sh4.2 脚本示例监控异常状态码比例再创建一个监控状态码分布的脚本#!/bin/bash LOG_FILE/var/log/nginx/access.log ALERT_FILE/tmp/status_alert.log LAST_5MIN_START$(date -d 5 minutes ago [%d/%b/%Y:%H:%M) # 统计过去5分钟的总请求数和404数 TOTAL_REQUESTS$(awk -v d$LAST_5MIN_START $4 d {total} END{print total0} $LOG_FILE) NOT_FOUND_COUNT$(awk -v d$LAST_5MIN_START $4 d $9 404 {count} END{print count0} $LOG_FILE) if [ $TOTAL_REQUESTS -gt 0 ]; then NOT_FOUND_RATIO$(echo scale2; $NOT_FOUND_COUNT * 100 / $TOTAL_REQUESTS | bc) # 如果404比例超过20%则告警 if [ $(echo $NOT_FOUND_RATIO 20 | bc) -eq 1 ]; then echo $(date): 过去5分钟404状态码比例异常: ${NOT_FOUND_RATIO}% (总数: $TOTAL_REQUESTS, 404: $NOT_FOUND_COUNT) $ALERT_FILE fi fi注意事项阈值需要调优THRESHOLD500和NOT_FOUND_RATIO 20只是示例起点。你需要根据自己网站的正常流量基线来调整。一个日均PV百万的网站和一个日均PV一万的网站阈值天差地别。自动封禁需谨慎在脚本中直接执行iptables -A INPUT -s $ip -j DROP非常危险可能导致误封真实用户例如来自公司NAT出口或CDN节点的IP。建议初期只告警人工确认后再封禁。或者可以将嫌疑IP写入一个文件由另一个更安全的脚本有白名单机制来处理封禁。日志轮询如果你的Nginx配置了日志轮询如logrotate要确保脚本处理的是正确的当前日志文件。有时可能需要同时分析access.log和access.log.1。5. 云环境下的特殊考量与增强监控在阿里云、腾讯云等虚拟机环境中你除了分析Nginx日志还应关注云平台提供的监控指标它们能从更高维度帮你确认攻击。5.1 结合云监控控制台网络流入流量如果遭遇UDP/ICMP Flood等流量型攻击在Nginx应用层日志可能看不出端倪但云监控中的“网络流入带宽”会直接飙升至实例规格上限。CPU使用率即使连接数不多但每个请求都消耗大量CPU如CC攻击针对计算密集型接口会导致CPU持续100%。连接数监控云监控通常提供TCP连接数指标。如果连接数突然暴涨与Nginx日志中的活跃请求数对不上可能是有大量半连接或慢速连接攻击。操作建议为关键监控指标如公网带宽、CPU使用率、连接数设置告警。当Nginx日志分析提示异常同时云监控也触发告警时基本可以断定正在遭受攻击需要立即启动应急预案。5.2 宿主机与虚拟机的流量关联对于有自建物理机宿主机并虚拟化出虚拟机的情况监控需要两层进行宿主机层面监控物理网卡的总流量。如果总流量打满但各个虚拟机的流量监控显示不高可能是某个虚拟机遭受了大流量攻击但监控Agent异常或者存在虚拟机逃逸等更严重问题概率极低但需排查。虚拟机层面即我们上面主要讨论的在Guest OS内部分析Nginx日志和系统资源。排查思路当虚拟机内发现异常但资源使用率不高时可以登录宿主机使用iftop、nethogs等工具查看具体是哪个虚拟网卡vnet*流量异常从而定位到问题虚拟机。6. 常见问题排查与应急响应实录在实际对抗DDoS的过程中你会遇到各种现象。下面是一些典型场景和我的处理思路。6.1 场景一带宽突然打满但Nginx日志请求数看起来正常现象云监控告警公网带宽100%使用但登录服务器查看access.log请求频率并没有异常暴涨。分析这很可能不是应用层HTTP/HTTPS攻击而是传输层或网络层的流量攻击如UDP Flood、SYN Flood、ICMP Flood。这些攻击包不会到达Nginx因此不会被记录在access.log中。排查使用iftop或nethogs命令实时查看网络流量和具体进程。如果是UDP Flood可能会看到大量不明UDP连接。使用netstat -an | grep -i syn查看是否存在大量的SYN_RECV状态连接半连接。应急立即联系云服务商启用其提供的DDoS高防服务如阿里云DDoS高防、腾讯云大禹。这类流量攻击在机房入口进行清洗最为有效靠虚拟机自身几乎无法防御。6.2 场景二大量5xx错误服务器负载极高现象用户反馈网站打不开监控显示服务器CPU/内存爆满Nginx日志中大量502 Bad Gateway或504 Gateway Timeout。分析这是典型的资源耗尽型攻击如CC攻击生效的表现。攻击可能指向一个特别消耗资源的API接口导致后端应用PHP、Java进程全部卡死或崩溃Nginx无法获取响应。排查快速定位攻击源使用awk命令快速找出当前返回5xx错误的请求主要来自哪些IP和URL。awk $9 ~ /^5[0-9][0-9]$/ {print $1, $7} /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -20检查后端服务检查PHP-FPM、Tomcat等后端进程的状态和日志。通常会发现“连接池耗尽”、“内存不足”或“执行超时”等错误。应急临时扩容如果云服务器支持临时升级CPU和内存。紧急限流/封禁在Nginx层面或系统防火墙iptables层面紧急封禁上一步找出的TOP攻击IP。Nginx可以使用limit_req_zone和limit_conn_zone做频率限制但紧急情况下直接封IP见效最快。重启后端服务重启PHP-FPM或Java应用快速释放资源恢复服务。但这只是缓兵之计需同时进行封禁。6.3 场景三日志中频繁出现来自云服务商IP的“攻击”现象分析出的高频IP是100.100.100.100阿里云内网DNS或161.117.233.1某个CDN节点。分析这很可能不是攻击。云服务内部组件如阿里云的Metadata服务器、内网DNS、云监控Agent等会定期访问实例产生固定模式的请求。CDN回源如果你使用了CDN所有用户请求都会先到达CDN边缘节点再由CDN节点以少量IP回源到你的服务器。因此高频IP可能是CDN的回源IP它代表了成千上万真实用户的聚合流量。处理切勿直接封禁这些IP否则会导致云服务异常或CDN功能失效。你需要做的是将这些已知的云平台内部IP和CDN回源IP段加入你的分析脚本的白名单列表避免误告警。通过请求头判断。如果使用了CDN通常CDN会添加X-Forwarded-For或X-Real-IP这样的头部来传递用户真实IP。你应该在Nginx配置中使用$http_x_forwarded_for或$http_x_real_ip作为日志和限流判断的真实客户端IP而不是$remote_addr。6.4 一个实用的复合排查命令当告警响起你需要一个快速综合查看当前情况的命令。我常用的一个“快照”命令组合如下echo 过去60秒TOP 10 IP awk -v d[$(date %d/%b/%Y:%H:%M:%S -d 60 seconds ago) $4 d {print $1} /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -10 echo echo 过去60秒状态码分布 awk -v d[$(date %d/%b/%Y:%H:%M:%S -d 60 seconds ago) $4 d {print $9} /var/log/nginx/access.log | sort | uniq -c | sort -nr echo echo 当前系统连接数统计 netstat -ant | awk {print $6} | sort | uniq -c | sort -nr echo echo 当前服务器负载 uptime free -m这个命令组合能在30秒内给你一个关于网络层连接、应用层请求和系统负载的概览帮助你快速判断攻击类型和严重程度。日志分析是安全运维的基石它不能阻止所有攻击但能让你在攻击发生时不再盲目。通过将本文的方法融入日常监控和应急流程你能建立起对自身流量模式的深刻认知从而更敏锐地捕捉到那些细微的异常。真正的安全来自于对“正常”的了如指掌以及对“异常”的快速反应。
Nginx日志分析实战：基于命令行工具识别DDoS攻击特征
1. 项目概述从日志中“听”到攻击的脚步声做运维或者搞网站开发的朋友对“我们的系统检测到您的计算机网络中存在异常流量”这类提示肯定不陌生。很多时候这背后就是一场或大或小的DDoS攻击。服务器就像一家24小时营业的店铺正常访客络绎不绝但突然涌进来几百个彪形大汉他们不买东西就堵在门口大声喧哗让真正的顾客进不来——这就是DDoS攻击最形象的比喻。Nginx作为我们最常用的Web服务器和反向代理它的访问日志access.log就是店铺的监控录像完整记录了每一个“访客”的到访时间、意图和行为。能否从海量的、看似正常的日志条目里快速、准确地揪出那些“彪形大汉”是保障服务稳定性的第一道也是至关重要的一道防线。这个项目的核心就是教会你如何成为一名合格的“日志侦探”。我们不依赖昂贵的商业安全产品而是深入Nginx日志的细节通过一系列特征分析和命令行工具比如grep,awk,sort手动构建一套轻量但高效的异常流量识别体系。无论是运行在阿里云、腾讯云虚拟机还是自建物理机上的服务这套方法都能帮你快速定位问题为后续的封禁、限流等操作提供精准的数据支持。你会发现很多攻击的蛛丝马迹就明明白白地写在日志里只看你有没有一双会发现的眼睛。2. DDoS攻击特征与Nginx日志的映射关系要识别异常首先得知道正常是什么样子以及攻击通常会伪装或呈现出哪些异常。DDoS攻击种类繁多但反映在Nginx访问日志上主要有以下几类特征它们就像是攻击者留下的不同“脚印”。2.1 流量规模异常请求频率与并发连接数这是最直观的特征。正常用户访问一个页面会产生对HTML、CSS、JS、图片等有限数量资源的请求。而DDoS攻击尤其是HTTP Flood攻击旨在耗尽服务器资源其典型表现是单一IP的请求频率RPS急剧升高一个IP在一秒内发出数十、上百甚至上千个请求这远远超出了人类或正常爬虫的行为模式。总并发连接数暴增Nginx需要同时处理大量TCP连接导致worker_connections限制被快速占满新的合法用户无法建立连接。流量带宽激增如果攻击伴随大流量如UDP Flood、ICMP Flood虽然可能不直接体现在应用层日志但会导致服务器或虚拟机出口带宽被打满。在日志中的体现你需要统计每个$remote_addr客户端IP在单位时间如每秒、每分钟内的请求行数。一个在1分钟内出现数千条记录的IP嫌疑极大。2.2 请求模式异常URL、User-Agent与参数攻击者为了提高攻击效率或绕过简单的频率限制会使用工具构造请求。固定或随机攻击URL集中攻击某个耗时高的动态接口如/api/search或随机请求大量不存在的静态资源如图片、文件以消耗磁盘I/O和404处理逻辑。畸形或特殊的User-Agent大量请求使用相同的、伪造的或明显为工具生成的User-Agent字符串例如空User-Agent、包含“bot”、“scan”、“hack”等关键词或是极其冗长怪异的字符串。非常规HTTP方法频繁出现POST、PUT、DELETE等方法尤其是向静态资源发起这类请求或者大量使用HEAD方法进行侦查。重复或无效的查询参数参数值异常长、包含大量特殊字符或尝试进行注入攻击的Pattern。在日志中的体现你需要关注$request字段包含方法、URL和协议以及$http_user_agent字段。大量相似的、非常规的请求模式是重要线索。2.3 响应状态码分布异常正常网站的HTTP状态码分布有一定规律例如200成功和304未修改占绝大多数404未找到占一小部分。DDoS攻击会扭曲这个分布大量4xx状态码如果攻击目标是随机不存在的URL会导致404状态码比例异常高。如果攻击包含恶意参数可能触发400错误请求或413请求体过大。大量5xx状态码当攻击导致服务器资源如数据库连接池、内存耗尽无法正常处理请求时会产生大量的502网关错误、503服务不可用或504网关超时。这既是攻击的结果也是需要紧急告警的信号。异常比例的200状态码对于针对缓存或静态页面的攻击服务器可能仍能返回200但请求本身是恶意的。在日志中的体现$status字段是关键。快速分析不同状态码的计数和占比能立刻发现服务是正在被“探针”扫描4xx激增还是已经被“打挂”5xx激增。2.4 连接行为异常请求时长与连接状态即使请求频率不高一些慢速攻击如Slowloris也会通过保持长时间连接来耗尽服务器连接资源。请求处理时间request_time异常正常请求的处理时间应在几百毫秒以内。如果大量请求的request_time长达数秒甚至数十秒可能是后端应用被拖慢也可能是攻击者故意发送慢速请求。连接建立时间异常这需要更底层的网络监控但反映在应用层可能表现为TCP连接建立缓慢。注意要获取$request_time你需要在Nginx的log_format中明确定义并记录它。默认的combined格式不包含此字段。3. 实战基于命令行工具的日志特征分析理论说再多不如动手敲一行命令。我们假设你的Nginx日志格式是标准的combined路径为/var/log/nginx/access.log。下面将演示如何用Linux命令行这把“瑞士军刀”逐项提取上述攻击特征。3.1 识别高频攻击IP这是最常用、最有效的第一步。我们统计每个IP的请求数并排序。# 统计总访问次数前10的IP awk {print $1} /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -10 # 统计最近5分钟内访问次数前10的IP (假设日志时间格式为[day/month/year:hour:minute:second]) awk -v d1$(date --date-5 min [%d/%b/%Y:%H:%M:%S) -v d2$(date [%d/%b/%Y:%H:%M:%S) $4 d1 $4 d2 {print $1} /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -10输出示例2874 114.114.114.114 1567 203.0.113.5 892 198.51.100.23 123 192.0.2.1 ...如果发现某个IP在短时间内如5分钟产生了成千上万次请求它极有可能是攻击源。3.2 分析异常状态码分布状态码是服务健康度的晴雨表。# 统计所有状态码的出现次数和比例 awk {print $9} /var/log/nginx/access.log | sort | uniq -c | sort -nr # 单独查看404状态码的请求并统计来源IP TOP 10 awk $9 404 {print $1} /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -10 # 单独查看5xx状态码的请求服务器错误 awk $9 ~ /^5[0-9][0-9]$/ {print $1, $7, $9} /var/log/nginx/access.log | head -20实操心得突然激增的404可能意味着扫描器或目录爆破工具在活动。而502/503的频繁出现往往意味着后端应用如PHP-FPM、Tomcat或数据库已经因资源耗尽而崩溃需要立即扩容或重启服务同时查找攻击源。3.3 揪出可疑的请求模式和User-Agent攻击工具常常会留下“指纹”。# 1. 查找请求次数最多的URL$7通常是请求的路径 awk {print $7} /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -20 # 2. 查找频繁出现的特定攻击模式URL例如大量请求phpMyAdmin、wp-login等管理后台 grep -E (phpmyadmin|wp-login|admin|login\.php|api/v1) /var/log/nginx/access.log | awk {print $1} | sort | uniq -c | sort -nr | head -10 # 3. 分析User-Agent找出非浏览器或可疑的客户端 # 先列出所有User-Agent并统计日志中$12以后是User-Agent位置取决于log_format awk -F\ {print $6} /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -20 # 更精准地查找空User-Agent或包含特定关键词的请求 grep -i agent.- /var/log/nginx/access.log | wc -l # 统计空User-Agent grep -iE (bot|scan|spider|hack|python|curl|wget) /var/log/nginx/access.log | awk {print $1} | sort | uniq -c | sort -nr | head -10注意不能一概而论地将Python或curl的User-Agent判定为攻击很多合法的API调用和监控脚本也会使用。这里的关键是“异常频繁”和“伴随其他攻击特征”。需要结合IP、频率和请求路径综合判断。3.4 将异常流量单独归档grep命令的进阶用法正如热搜词里提到的我们可以利用grep将特定状态的请求如所有404或来自某个嫌疑IP的请求单独提取出来存入独立文件便于后续深度分析和取证。# 将今天所有状态码为404的请求单独存储到一个文件 grep HTTP/1\.[01] 404 /var/log/nginx/access.log /tmp/nginx_404_$(date %Y%m%d).log # 将来自特定嫌疑IP(如114.114.114.114)的所有请求单独存储 grep ^114\.114\.114\.114 /var/log/nginx/access.log /tmp/nginx_attack_ip_114.114.114.114.log # 结合日期和时间范围进行筛选 (例如筛选今天上午10点到11点的日志) awk -v d1[$(date %d/%b/%Y):10: -v d2[$(date %d/%b/%Y):11: $4 d1 $4 d2 /var/log/nginx/access.log /tmp/nginx_log_10am_11am.log这样做的好处原始日志文件得以保全所有可疑流量被浓缩到小文件中文件大小可能只有几MB方便你用less、vi仔细查看攻击者的完整行为链条或者打包发送给安全团队进行分析。4. 构建自动化监控与告警脚本手动分析是基础但真正的防御需要自动化。我们可以将上面的命令封装成Shell脚本定期如每分钟执行并设置阈值触发告警。4.1 脚本示例监控每分钟高频IP创建一个脚本/usr/local/bin/ddos_detect.sh#!/bin/bash LOG_FILE/var/log/nginx/access.log THRESHOLD500 # 阈值1分钟内请求超过500次视为异常 ALERT_FILE/tmp/ddos_alert.log LAST_MINUTE$(date -d 1 minute ago [%d/%b/%Y:%H:%M) # 分析上一分钟的日志找出超过阈值的IP awk -v d$LAST_MINUTE $4 ~ d {print $1} $LOG_FILE | sort | uniq -c | while read count ip; do if [ $count -gt $THRESHOLD ]; then echo $(date): 检测到高频请求IP: $ip, 请求次数: $count (阈值: $THRESHOLD) $ALERT_FILE # 这里可以添加自动封禁IP的命令例如 # iptables -A INPUT -s $ip -j DROP # 或者调用云服务商的API进行封禁 fi done # 检查是否有5xx错误激增 (例如每分钟超过100个5xx错误) FIVEXX_COUNT$(awk -v d$LAST_MINUTE $4 ~ d $9 ~ /^5[0-9][0-9]$/ {count} END{print count0} $LOG_FILE) if [ $FIVEXX_COUNT -gt 100 ]; then echo $(date): 警告上一分钟5xx错误数激增: $FIVEXX_COUNT $ALERT_FILE fi然后通过Crontab设置每分钟执行一次* * * * * root /usr/local/bin/ddos_detect.sh4.2 脚本示例监控异常状态码比例再创建一个监控状态码分布的脚本#!/bin/bash LOG_FILE/var/log/nginx/access.log ALERT_FILE/tmp/status_alert.log LAST_5MIN_START$(date -d 5 minutes ago [%d/%b/%Y:%H:%M) # 统计过去5分钟的总请求数和404数 TOTAL_REQUESTS$(awk -v d$LAST_5MIN_START $4 d {total} END{print total0} $LOG_FILE) NOT_FOUND_COUNT$(awk -v d$LAST_5MIN_START $4 d $9 404 {count} END{print count0} $LOG_FILE) if [ $TOTAL_REQUESTS -gt 0 ]; then NOT_FOUND_RATIO$(echo scale2; $NOT_FOUND_COUNT * 100 / $TOTAL_REQUESTS | bc) # 如果404比例超过20%则告警 if [ $(echo $NOT_FOUND_RATIO 20 | bc) -eq 1 ]; then echo $(date): 过去5分钟404状态码比例异常: ${NOT_FOUND_RATIO}% (总数: $TOTAL_REQUESTS, 404: $NOT_FOUND_COUNT) $ALERT_FILE fi fi注意事项阈值需要调优THRESHOLD500和NOT_FOUND_RATIO 20只是示例起点。你需要根据自己网站的正常流量基线来调整。一个日均PV百万的网站和一个日均PV一万的网站阈值天差地别。自动封禁需谨慎在脚本中直接执行iptables -A INPUT -s $ip -j DROP非常危险可能导致误封真实用户例如来自公司NAT出口或CDN节点的IP。建议初期只告警人工确认后再封禁。或者可以将嫌疑IP写入一个文件由另一个更安全的脚本有白名单机制来处理封禁。日志轮询如果你的Nginx配置了日志轮询如logrotate要确保脚本处理的是正确的当前日志文件。有时可能需要同时分析access.log和access.log.1。5. 云环境下的特殊考量与增强监控在阿里云、腾讯云等虚拟机环境中你除了分析Nginx日志还应关注云平台提供的监控指标它们能从更高维度帮你确认攻击。5.1 结合云监控控制台网络流入流量如果遭遇UDP/ICMP Flood等流量型攻击在Nginx应用层日志可能看不出端倪但云监控中的“网络流入带宽”会直接飙升至实例规格上限。CPU使用率即使连接数不多但每个请求都消耗大量CPU如CC攻击针对计算密集型接口会导致CPU持续100%。连接数监控云监控通常提供TCP连接数指标。如果连接数突然暴涨与Nginx日志中的活跃请求数对不上可能是有大量半连接或慢速连接攻击。操作建议为关键监控指标如公网带宽、CPU使用率、连接数设置告警。当Nginx日志分析提示异常同时云监控也触发告警时基本可以断定正在遭受攻击需要立即启动应急预案。5.2 宿主机与虚拟机的流量关联对于有自建物理机宿主机并虚拟化出虚拟机的情况监控需要两层进行宿主机层面监控物理网卡的总流量。如果总流量打满但各个虚拟机的流量监控显示不高可能是某个虚拟机遭受了大流量攻击但监控Agent异常或者存在虚拟机逃逸等更严重问题概率极低但需排查。虚拟机层面即我们上面主要讨论的在Guest OS内部分析Nginx日志和系统资源。排查思路当虚拟机内发现异常但资源使用率不高时可以登录宿主机使用iftop、nethogs等工具查看具体是哪个虚拟网卡vnet*流量异常从而定位到问题虚拟机。6. 常见问题排查与应急响应实录在实际对抗DDoS的过程中你会遇到各种现象。下面是一些典型场景和我的处理思路。6.1 场景一带宽突然打满但Nginx日志请求数看起来正常现象云监控告警公网带宽100%使用但登录服务器查看access.log请求频率并没有异常暴涨。分析这很可能不是应用层HTTP/HTTPS攻击而是传输层或网络层的流量攻击如UDP Flood、SYN Flood、ICMP Flood。这些攻击包不会到达Nginx因此不会被记录在access.log中。排查使用iftop或nethogs命令实时查看网络流量和具体进程。如果是UDP Flood可能会看到大量不明UDP连接。使用netstat -an | grep -i syn查看是否存在大量的SYN_RECV状态连接半连接。应急立即联系云服务商启用其提供的DDoS高防服务如阿里云DDoS高防、腾讯云大禹。这类流量攻击在机房入口进行清洗最为有效靠虚拟机自身几乎无法防御。6.2 场景二大量5xx错误服务器负载极高现象用户反馈网站打不开监控显示服务器CPU/内存爆满Nginx日志中大量502 Bad Gateway或504 Gateway Timeout。分析这是典型的资源耗尽型攻击如CC攻击生效的表现。攻击可能指向一个特别消耗资源的API接口导致后端应用PHP、Java进程全部卡死或崩溃Nginx无法获取响应。排查快速定位攻击源使用awk命令快速找出当前返回5xx错误的请求主要来自哪些IP和URL。awk $9 ~ /^5[0-9][0-9]$/ {print $1, $7} /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -20检查后端服务检查PHP-FPM、Tomcat等后端进程的状态和日志。通常会发现“连接池耗尽”、“内存不足”或“执行超时”等错误。应急临时扩容如果云服务器支持临时升级CPU和内存。紧急限流/封禁在Nginx层面或系统防火墙iptables层面紧急封禁上一步找出的TOP攻击IP。Nginx可以使用limit_req_zone和limit_conn_zone做频率限制但紧急情况下直接封IP见效最快。重启后端服务重启PHP-FPM或Java应用快速释放资源恢复服务。但这只是缓兵之计需同时进行封禁。6.3 场景三日志中频繁出现来自云服务商IP的“攻击”现象分析出的高频IP是100.100.100.100阿里云内网DNS或161.117.233.1某个CDN节点。分析这很可能不是攻击。云服务内部组件如阿里云的Metadata服务器、内网DNS、云监控Agent等会定期访问实例产生固定模式的请求。CDN回源如果你使用了CDN所有用户请求都会先到达CDN边缘节点再由CDN节点以少量IP回源到你的服务器。因此高频IP可能是CDN的回源IP它代表了成千上万真实用户的聚合流量。处理切勿直接封禁这些IP否则会导致云服务异常或CDN功能失效。你需要做的是将这些已知的云平台内部IP和CDN回源IP段加入你的分析脚本的白名单列表避免误告警。通过请求头判断。如果使用了CDN通常CDN会添加X-Forwarded-For或X-Real-IP这样的头部来传递用户真实IP。你应该在Nginx配置中使用$http_x_forwarded_for或$http_x_real_ip作为日志和限流判断的真实客户端IP而不是$remote_addr。6.4 一个实用的复合排查命令当告警响起你需要一个快速综合查看当前情况的命令。我常用的一个“快照”命令组合如下echo 过去60秒TOP 10 IP awk -v d[$(date %d/%b/%Y:%H:%M:%S -d 60 seconds ago) $4 d {print $1} /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -10 echo echo 过去60秒状态码分布 awk -v d[$(date %d/%b/%Y:%H:%M:%S -d 60 seconds ago) $4 d {print $9} /var/log/nginx/access.log | sort | uniq -c | sort -nr echo echo 当前系统连接数统计 netstat -ant | awk {print $6} | sort | uniq -c | sort -nr echo echo 当前服务器负载 uptime free -m这个命令组合能在30秒内给你一个关于网络层连接、应用层请求和系统负载的概览帮助你快速判断攻击类型和严重程度。日志分析是安全运维的基石它不能阻止所有攻击但能让你在攻击发生时不再盲目。通过将本文的方法融入日常监控和应急流程你能建立起对自身流量模式的深刻认知从而更敏锐地捕捉到那些细微的异常。真正的安全来自于对“正常”的了如指掌以及对“异常”的快速反应。
