我的网站被攻击了：120G流量耗尽与持续对抗全记录——一名PHP开发者的深度反思与实战报告

摘要： 本文详细记录了笔者负责的一个PHP技术博客网站遭遇的一次持续大规模流量攻击事件。攻击导致单日120GB流量耗尽，服务间歇性中断。报告将从攻击发生时的现象入手，逐步深入分析DDoS/CC攻击的原理，详述从发现、诊断、应急响应到技术反制的全过程。文章将重点探讨在PHP应用层面、Web服务器层面、架构层面及云平台层面可采取的具体防御策略，并最终引申出对现代Web应用安全体系建设的深度思考。本报告旨在为PHP开发者及运维人员提供一套从实战中总结的、行之有效的大流量攻击应对方案。

关键词： DDoS攻击、CC攻击、PHP安全、流量清洗、CDN、WAF、Nginx配置、应急响应、云安全

第一章：事件序幕——风暴前的平静与第一声警报

时间：凌晨4点30分。我的手机发出刺耳的警报声，不是闹钟，而是来自云监控平台的短信：“【流量告警】您的云服务器 [Web-Server-01] 出网带宽使用率已连续5分钟超过95%，当前使用率98.7%。”

作为一名有多年经验的PHP开发者，我对自己网站的流量模式了如指掌。凌晨时段通常是访问谷底，绝无可能产生如此高的带宽占用。瞬间清醒，我意识到——出事了。

初步症状：

网站访问极慢： 通过手机4G网络尝试打开首页，耗时超过30秒，最终超时。
服务器资源异常： 登录云控制台，发现CPU使用率持续100%，网络出带宽持续跑满。
用户反馈中断： 团队群和用户群里开始有人反馈网站无法访问。

第一反应：

紧急扩容带宽（临时止血）： 为避免服务完全不可用，我立即将服务器公网带宽从5Mbps临时升级到100Mbps。此举立竿见影，网站暂时恢复访问。但这只是权宜之计，成本高昂且未解决根本问题。
登录服务器进行分析： 通过SSH登录服务器（庆幸22端口未被直接打满），开始寻找问题根源。

本章思考： 建立有效的监控告警系统是安全防御的第一道生命线。对CPU、内存、磁盘I/O、网络带宽、连接数等关键指标设置阈值告警至关重要。

第二章：深度诊断——揪出流量黑洞的元凶

面对持续跑满的带宽，必须快速定位是正常流量还是恶意流量。

2.1 网络连接分析

使用 netstat、ss等命令分析网络连接状态。

# 统计TCP连接状态
netstat -nat | awk '{print $6}' | sort | uniq -c | sort -n

# 查看当前连接数最多的IP排名
netstat -anlt | grep :80 | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -20

发现： 命令结果显示，有数千个ESTABLISHED状态的连接指向Nginx的80端口。前几个IP地址的连接数高达数百个，且这些IP段非常集中，极不正常。

2.2 Web服务器日志分析

Nginx的访问日志是分析攻击的宝库。我立即使用一系列命令进行实时和离线分析。

# 1. 实时查看当前访问日志（发现海量异常请求）
tail -f /var/log/nginx/access.log

# 2. 统计访问最频繁的IP（前20名）
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -20

# 3. 统计最常被访问的URL（攻击者可能在扫描或攻击特定漏洞）
awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -20

# 4. 分析指定可疑IP的访问行为
grep "123.456.789.100" /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -nr

关键发现：

攻击模式确认： 大量的请求来自相对固定的几百个IP地址。
攻击目标： 请求并非针对首页，而是集中指向几个特定的、消耗资源的URL：
- /api/v1/search?keyword=random_string：一个基于数据库搜索的API接口。
- /wp-login.php：尽管我们不是WordPress，但攻击者仍在盲目扫描。
- /index.php/Admin/Login：尝试攻击后台登录入口。
- 大量请求针对不存在的静态资源（如 .jpg, .zip），可能是为了消耗服务器I/O。
User-Aident： 大量请求携带伪造或异常的User-Agent，如“Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)”。
状态码： 服务器大量返回 200（对于静态文件）、404（对于不存在的路径）和 503（因为PHP-FPM资源耗尽）。

2.3 PHP-FPM进程池分析

检查PHP-FPM状态，发现子进程数达到最大值，全部处于“繁忙”状态，导致新的PHP请求无法被处理，出现502 Bad Gateway错误。

sudo systemctl status php8.1-fpm
sudo tail -f /var/log/php8.1-fpm.log

结论： 这是一次典型的CC攻击。CC攻击的核心是模拟大量正常用户请求，但集中攻击消耗服务器资源的应用层端点（如数据库查询、复杂运算），旨在耗尽服务器的CPU、内存或PHP-FPM子进程等资源，从而达到拒绝服务的目的。120G的流量正是这些海量请求及其响应所产生。

本章思考： 熟练运用Linux网络诊断工具和Web日志分析技巧，是快速定位攻击类型和来源的关键。CC攻击区别于DDoS流量洪泛，它更“聪明”，更针对应用弱点。

第三章：紧急响应与战术反制——PHP层面的短兵相接

在等待云平台防护生效的同时，我立即在服务器和应用层面进行了一系列紧急配置，以缓解攻击压力。

3.1 Nginx层面限流与封禁

Nginx的强大在于其灵活的配置，可以快速实现访问控制。

封禁恶意IP段： 在 nginx.conf的 http块中，创建黑名单。geo $blocked_ips { default 0; # 将分析得到的恶意IP段加入此处 123.456.789.0/24 1; 111.222.333.0/24 1; # ... 更多IP段 }
限制单个IP的连接数和请求速率： 在 nginx.conf的 http块中定义限制区。http { # 定义限制区，每秒允许10个请求，突发不超过20 limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s; limit_req_zone $server_name zone=perserver:10m rate=100r/s; # 定义连接数限制区 limit_conn_zone $binary_remote_addr zone=addr:10m; }在具体的 server或 location块中应用：server { listen 80; server_name example.com; # 应用黑名单 if ($blocked_ips) { return 444; # 直接关闭连接 } # 全站限制每个IP每秒10个请求 limit_req zone=perip burst=20 nodelay; limit_conn addr 20; # 限制每个IP最多20个连接 # 对特别耗资源的API接口进行更严格的限制 location /api/ { limit_req zone=perip burst=5 nodelay; limit_conn addr 5; # ... 其他配置 } # 保护后台登录入口，直接拒绝非指定IP访问 location /admin/ { allow 192.168.1.100; # 你的办公IP allow 203.0.113.50; # 你的家庭IP deny all; return 403; } }重启Nginx后，服务器负载立竿见影地开始下降。

3.2 PHP应用层加固

禁用高危函数： 检查 php.ini，确保 disable_functions中包含 system, exec, passthru, shell_exec等，防止攻击者利用其他漏洞执行系统命令。
优化PHP-FPM池配置： 调整 www.conf，避免子进程被无限消耗。; 防止子进程过多，根据服务器配置设置合理值 pm.max_children = 50 ; 设置单个请求的最大执行时间，避免脚本无限循环 request_terminate_timeout = 60s ; 防止请求参数过大被用于攻击 php_value[memory_limit] = 128M php_value[post_max_size] = 20M php_value[upload_max_filesize] = 10M
编写简单防护脚本（谨慎使用）： 在入口文件（如 index.php）最开头，加入简单的IP封禁逻辑。注意，这种方式在高并发下对性能有影响，仅作为最后手段。<?php // emergency_block.php $blacklist = ['123.456.789.100', '111.222.333.444']; $client_ip = $_SERVER['REMOTE_ADDR']; if (in_array($client_ip, $blacklist)) { header('HTTP/1.1 403 Forbidden'); exit('Access Denied'); } // 然后引入真正的入口文件 require_once 'index_main.php';
验证码强化： 对所有用户交互环节，特别是登录、搜索、提交评论等，强制启用验证码（如Google reCAPTCHA），有效抵御自动化脚本。

本章思考： 在应用层进行防御是成本最低、响应最快的方式。通过Web服务器和PHP的配置，可以迅速过滤掉大部分低级攻击流量，为后续防护争取时间。但这属于“被动防御”，治标不治本。

第四章：战略升级——借助云平台与专业防护体系

服务器层面的单点防御有其极限，当攻击流量超过服务器带宽上限时，必须将防线外移。

4.1 启用CDN（内容分发网络）

我立即将网站的域名解析记录由直接指向服务器IP（A记录），改为指向一个CDN服务商提供的CNAME。

原理： CDN通过分布在全球的边缘节点缓存静态内容。用户请求先到达边缘节点，节点如有缓存则直接返回，无需回源服务器。这极大地减少了源站压力。
效果：
- 隐藏源站IP： 攻击者只能看到CDN的节点IP，无法直接攻击我的服务器。
- 流量吸收： CDN网络带宽巨大，能有效吸收和分散流量攻击。
- 缓存加速： 正常的静态资源请求被缓存，访问速度更快。

4.2 启用WAF（Web应用防火墙）

现代CDN服务通常集成WAF功能，这是对抗CC攻击的利器。

核心规则：
- IP信誉库： 自动封禁已知恶意IP。
- 频率控制： 在CDN边缘节点设置更精细的CC防护规则，如单个IP在特定时间内对特定URL的请求频率阈值。
- 智能识别： 通过分析User-Agent、请求头、行为模式等，识别和拦截恶意爬虫、扫描器、CC攻击工具。
自定义规则： 我根据第2章的分析结果，在WAF中设置了自定义规则：
- 对 /api/v1/search路径，设置更低的频率阈值。
- 拦截所有包含特定攻击特征的请求（如SQL注入、XSS payload）。
- 对来自特定国家/地区的访问（如果业务不涉及）进行封禁或验证码挑战。

4.3 启用云平台的“流量清洗”服务

对于超过CDN和WAF处理能力的、更接近网络层的DDoS攻击，我联系云服务商，启用了高防IP/流量清洗服务。

原理： 所有访问流量先经过高防机房，在这里进行实时分析。正常流量被转发到源站，而异常流量（如SYN Flood, UDP Flood）被直接丢弃。
效果： 我的源服务器接收到的只剩下“干净”的流量，带宽和CPU使用率迅速恢复正常。

本章思考： 对抗大规模网络攻击，必须依靠云平台或专业安全公司提供的分布式防御能力。将安全边界从自己的服务器扩展到整个网络边缘，是现代Web安全的必然选择。“靠自己硬抗”在真正的攻击面前是徒劳且昂贵的。

第五章：架构反思与长效防御机制建设

经历此次攻击，我对网站架构进行了彻底的反思和改造。

5.1 架构优化

动静分离与对象存储： 将网站所有静态资源（图片、CSS、JS、视频）全部迁移至云对象存储（如AWS S3, 阿里云OSS）。这彻底消除了静态资源请求对Web服务器的压力，也便于CDN缓存。
核心业务微服务化： 将最容易被攻击的、消耗资源的业务（如全文搜索）独立出来，部署为单独的微服务。即使该服务被攻击，也不影响网站核心内容的展示。并为该微服务设置独立的、更严格的防护策略。
引入队列异步处理： 对于非实时性的操作（如发送邮件、生成报表），将其放入消息队列（如Redis, RabbitMQ）异步处理，避免HTTP请求被长时间阻塞，提升整体吞吐量。

5.2 安全监控与自动化

日志集中分析： 使用ELK Stack或Graylog搭建集中式日志平台，实时分析Nginx、PHP-FPM日志，建立攻击行为画像，实现更早的预警。
安全信息与事件管理： 部署SIEM系统，将各类日志、监控指标关联分析，实现自动化威胁检测和响应。
自动化封禁脚本： 编写脚本，定期分析Nginx日志，自动将异常IP加入到Nginx或防火墙的黑名单中。

5.3 建立安全应急响应预案

明确流程： 制定详细的应急响应checklist，包括：谁负责、第一步做什么、如何沟通、升级流程等。
定期演练： 定期模拟攻击事件，检验预案的有效性和团队的响应速度。

本章思考： 安全不是一个功能，而是一个过程。它必须融入系统的架构设计、开发流程和运维体系中。高可用、可扩展的架构本身也具有更好的抗攻击能力。

第六章：总结与致开发者同仁

这次消耗120G流量的攻击，是一次代价高昂但极具价值的“压力测试”。它让我深刻认识到：

没有绝对的安全： 无论你的代码写得多么严谨，只要服务在互联网上公开，就必然暴露在威胁之下。
防御需要纵深： 单一层面的防御是脆弱的。必须构建从网络、服务器、应用到运维管理的多层次、纵深防御体系。
善用专业服务： 在云计算时代，不要试图重复造轮子。CDN、WAF、高防IP等云安全服务是性价比极高的投资。
监控是眼睛，预案是大脑： 没有监控就是在“裸奔”；没有预案，遇事只会手忙脚乱。

致所有的PHP开发者同仁：我们不仅是代码的创造者，也应是系统稳定性的守护者。在追求功能实现和性能优化的同时，请务必把安全提升到战略高度。从今天起，检查你的php.ini配置，优化你的Nginx规则，为你的网站套上CDN和WAF的“铠甲”。因为，攻击可能发生在任何时间，而最好的应对方式，就是在它到来之前，我们已经做好了万全的准备。

（报告完）

附录：

推荐工具列表： Fail2ban、ModSecurity、Prometheus+Grafana、ELK Stack。
安全资源： OWASP Top 10、PHP官方安全手册、云服务商安全白皮书。

{{userData.name}}已认证