1. 项目概述：为什么CentOS服务器需要主动防御DDoS？

如果你手头有一台跑着CentOS的服务器，无论是用来托管网站、运行API接口，还是作为内部业务系统，那么“DDoS攻击”这个词，大概率已经从技术新闻里的一个概念，变成了悬在头顶的达摩克利斯之剑。我见过太多案例，一个运行平稳的业务，可能就因为某个竞争对手或者无聊的黑客脚本小子发起的一次流量洪水，瞬间陷入瘫痪，进而导致直接的经济损失和品牌信誉受损。尤其是在CentOS 7/8逐渐停止官方维护的今天，系统本身的安全更新滞后，使得服务器在应用层和系统层都变得更加脆弱，单纯依赖云服务商提供的“基础防护”往往是不够的。

DDoS，分布式拒绝服务攻击，它的核心逻辑并不复杂：利用海量受控的“肉鸡”（被控制的设备）同时向目标服务器发起请求，耗尽目标的网络带宽、连接数或计算资源，让正常的用户请求无法得到响应。这就像一家小餐馆突然涌进来成千上万个只占座不点单的人，真正的顾客根本进不来。对于CentOS服务器管理员来说，攻击可能表现为：网络卡顿、SSH连接困难、Web服务响应超时、系统负载飙升甚至直接宕机。

所以，“击退DDoS攻击”这个事，绝不能等到攻击临头再手忙脚乱。它应该是一套从架构设计、系统加固、实时监控到应急响应的完整防御体系。这篇文章，我就结合自己多年在运维一线对抗各类DDoS的经验，从CentOS系统的角度出发，拆解一套可落地、能实操的防护组合拳。我们不只讲工具怎么装，更要讲清楚每个动作背后的防御逻辑和适用场景，让你知其然，更知其所以然。

2. 防御体系构建：分层设防与核心思路拆解

对抗DDoS，最忌讳的就是“头痛医头，脚痛医脚”。一个有效的防御体系必须是分层的，就像古代的城池防御，有护城河、有城墙、有瓮城、有内城。对于一台CentOS服务器，我们可以构建四个层次的防御。

2.1 第一层：网络与带宽层防御——御敌于国门之外

这一层的目标是尽可能在流量到达你的服务器网卡之前，就将其拦截或稀释。对于个人或中小企业来说，完全靠自己扛住超大流量是不现实的。

核心策略：利用云服务商的防护服务。这是性价比最高、也是最有效的手段。各大云厂商（如阿里云、腾讯云、华为云等）都提供DDoS高防IP或原生防护服务。其原理是：你将业务的公网IP更换为高防IP，所有流量先经过高防的清洗中心。这里部署了庞大的带宽资源和智能清洗设备，能够识别并过滤掉恶意流量，只将正常的流量转发给你的源站服务器。

注意：很多用户有一个误区，认为买了云服务器，内网带宽就安全了。实际上，DDoS攻击的是你的公网IP和带宽。云厂商的“基础防护”通常有很低的阈值（比如5Gbps），一旦攻击流量超过这个阈值，就会触发“黑洞”策略，即云厂商直接屏蔽你的公网IP一段时间（如30分钟到2小时），以保证整个网络平台的稳定。所以，对于有重要业务的服务器，务必评估业务规模，考虑购买更高规格的DDoS防护包。

自建补充：调整内核参数应对连接耗尽型攻击。对于Syn Flood、ACK Flood这类旨在耗尽服务器TCP连接资源的攻击，我们可以在CentOS系统层面进行加固。通过修改/etc/sysctl.conf内核参数，优化TCP协议栈的行为。

# 编辑内核参数配置文件 sudo vi /etc/sysctl.conf # 在文件末尾添加或修改以下参数 # 启用SYN Cookies，在SYN队列满时提供防护 net.ipv4.tcp_syncookies = 1 # 减少SYN+ACK报文的重试次数，加快回收半连接资源 net.ipv4.tcp_synack_retries = 2 net.ipv4.tcp_syn_retries = 2 # 增大TCP半连接和全连接队列的最大长度（根据内存调整） net.ipv4.tcp_max_syn_backlog = 262144 net.core.somaxconn = 65535 # 快速回收TIME_WAIT状态的socket，适用于高并发短连接场景 net.ipv4.tcp_fin_timeout = 30 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_tw_recycle = 0 # CentOS 7+ 建议设置为0，避免在NAT环境下出现问题 # 减少保持在FIN-WAIT-2状态的时间 net.ipv4.tcp_fin_timeout = 30 # 使配置生效 sudo sysctl -p

实操心得：调整tcp_max_syn_backlog和somaxconn时，需要确保你的应用程序（如Nginx、Apache）的backlog参数也相应调大，否则系统参数生效了，但应用层队列还是很小，依然会丢连接。例如，Nginx中需要设置listen 80 backlog=65535;。

2.2 第二层：操作系统层防御——加固城墙

攻击流量穿过第一层网络防线后，就会到达服务器操作系统。这一层的目标是强化系统本身，减少可以被攻击利用的弱点，并限制单个攻击源的影响。

核心策略一：防火墙（FirewallD/iptables）精细化管控。CentOS 7及以上默认使用FirewallD，但底层依然是iptables。我们需要制定严格的入站规则。

1. 限制单IP连接数：这是应对CC攻击（HTTP Flood）的有效手段。我们可以用iptables的connlimit模块来限制单个IP地址到特定端口（如80、443）的并发连接数。

   # 安装iptables-services（如果使用原生iptables） sudo yum install iptables-services -y # 限制单个IP到80端口的并发连接数不超过50个 sudo iptables -A INPUT -p tcp --dport 80 -m connlimit --connlimit-above 50 -j REJECT --reject-with tcp-reset # 限制单个IP到443端口的并发连接数不超过30个 sudo iptables -A INPUT -p tcp --dport 443 -m connlimit --connlimit-above 30 -j REJECT --reject-with tcp-reset # 保存iptables规则（CentOS 7） sudo service iptables save # 或使用firewalld的direct规则（更推荐，与firewalld共存） sudo firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 0 -p tcp --dport 80 -m connlimit --connlimit-above 50 --connlimit-mask 32 -j REJECT sudo firewall-cmd --reload

   参数解释：--connlimit-above 50表示连接数超过50就触发规则。--connlimit-mask 32表示针对单个IP（32位子网掩码）。这个数值需要根据你的业务正常访问模型来设定，设置过低会影响正常用户，设置过高则失去防护意义。通常可以先观察日志，统计正常用户单IP的最大并发数，然后在此基础上增加一个安全余量。

2. 设置端口敲门（Port Knocking）：对于SSH这类管理端口，可以隐藏起来。只有按特定顺序“敲击”（尝试连接）几个封闭的端口后，防火墙才会临时开放SSH端口。这能极大减少SSH的暴力破解和扫描。实现需要用到knockd服务，配置稍复杂，但安全性提升显著。

核心策略二：禁用不必要的服务与内核调优。关闭像rpcbind、nfs等用不到的服务，减少攻击面。使用systemctl disable <service_name>来禁用。同时，可以继续优化sysctl参数，比如调整net.ipv4.ip_local_port_range来扩大本地端口范围，增加攻击者耗尽本地端口的难度。

2.3 第三层：应用服务层防御——城门守卫

流量到达具体的Web服务器（如Nginx/Apache）或应用（如MySQL）。这一层的防御最为关键，因为很多CC攻击模拟的是正常HTTP请求，网络层很难区分。

核心策略：使用Web服务器模块或专用软件进行请求频率限制和特征过滤。

1. Nginx限流配置：Nginx的ngx_http_limit_req_module和ngx_http_limit_conn_module模块是应对CC攻击的利器。

   # 在http块中定义限制区域 http { # 定义限制请求速率的共享内存区，10MB大小，平均速率限制为每秒10个请求 limit_req_zone $binary_remote_addr zone=one:10m rate=10r/s; # 定义限制连接数的共享内存区 limit_conn_zone $binary_remote_addr zone=addr:10m; server { listen 80; server_name yourdomain.com; # 应用请求速率限制 location / { # 使用‘one’区域，突发请求不超过20个，无延迟（nodelay）模式会直接拒绝超额请求 limit_req zone=one burst=20 nodelay; # 限制同一IP同时只能有10个连接 limit_conn addr 10; # 返回503状态码而非默认的503，方便监控 limit_req_status 429; limit_conn_status 429; # 你的正常代理或root配置 proxy_pass http://backend; } # 特别针对登录、提交等关键接口进行更严格的限制 location /api/login { limit_req zone=one burst=5 nodelay; limit_conn addr 3; proxy_pass http://backend; } } }

   踩坑记录：burst参数设置很重要。设置太小，正常用户的短暂请求高峰（如页面加载多个资源）也会被拒绝；设置太大，又给攻击者留了空间。最佳实践是结合日志分析，并考虑在limit_req指令后加上delay参数（如limit_req zone=one burst=20 delay=10），允许前10个突发请求被延迟处理，而不是直接拒绝，体验更好。

2. 使用Fail2ban动态封禁IP：Fail2ban是一个神器，它监控系统日志（如/var/log/nginx/access.log），当发现某个IP在短时间内有大量错误请求（如404、503）或达到你定义的恶意规则时，会自动调用防火墙（iptables/firewalld）将其IP封禁一段时间。

   # 安装Fail2ban sudo yum install epel-release -y sudo yum install fail2ban -y # 创建本地配置文件，避免升级被覆盖 sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local sudo vi /etc/fail2ban/jail.local

   在jail.local中，你可以启用并定制各种“监狱”（jail）。例如，针对Nginx的CC攻击：

   [nginx-cc] enabled = true port = http,https filter = nginx-cc logpath = /var/log/nginx/access.log maxretry = 100 # 在findtime时间内最大请求次数 findtime = 60 # 统计时间窗口，单位秒 bantime = 3600 # 封禁时间，单位秒 action = iptables-multiport[name=nginx-cc, port="http,https", protocol=tcp]

   然后，你需要在/etc/fail2ban/filter.d/下创建nginx-cc.conf过滤器，定义匹配恶意请求的正则表达式（例如，短时间内请求频率过高）。Fail2ban的灵活性极高，你可以为SSH、MySQL、甚至自定义应用日志编写过滤规则。

2.4 第四层：监控与应急响应层——瞭望塔与快速反应部队

防御体系必须有眼睛和快速反应机制。没有监控，攻击发生了你可能都浑然不知；没有预案，攻击发生时就会陷入混乱。

核心策略：建立立体监控和自动化应急脚本。

1. 基础资源监控：使用iftop、nethogs实时查看网络流量和进程流量。使用htop、vmstat监控系统负载和CPU。将这些命令集成到Zabbix、Prometheus+Grafana等监控系统中，设置告警阈值（如网卡入向流量持续>100Mbps，TCP连接数>10000）。

2. 网络连接分析：当发现异常时，立即使用netstat或ss命令分析连接。

   # 查看所有TCP连接数 ss -ant | awk '{print $1}' | sort | uniq -c | sort -rn # 查看连接到80端口最多的前10个IP netstat -ant | grep :80 | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -10

   如果发现某个IP有成千上万的连接，它很可能就是攻击源之一。

3. 准备应急脚本：提前编写Shell脚本，用于在攻击发生时快速执行“止血”操作。例如，一个简单的脚本，分析Nginx日志，将请求频率异常的IP自动加入防火墙黑名单。

   #!/bin/bash # emergency_ban.sh LOG_FILE="/var/log/nginx/access.log" # 分析过去60秒内，访问次数超过300次的IP BAD_IPS=$(tail -n 5000 $LOG_FILE | awk -vDate=`date -d'now-60 seconds' +[%d/%b/%Y:%H:%M:%S` 'Date < $4' | awk '{print $1}' | sort | uniq -c | sort -rn | awk '{if ($1 > 300) print $2}') for ip in $BAD_IPS do # 使用firewalld封禁IP firewall-cmd --permanent --add-rich-rule="rule family='ipv4' source address='$ip' reject" echo "已封禁IP: $ip" done firewall-cmd --reload

   重要提醒：此类脚本要谨慎使用，避免误封CDN节点或代理池的IP，导致正常用户无法访问。最好先手动验证，或加入IP白名单机制。

3. 实战部署：基于CentOS 7/8的一站式防护配置

理论讲完，我们动手把上面提到的关键点，在一台干净的CentOS 7/8服务器上部署起来。假设我们是一台Web服务器，运行Nginx。

3.1 系统基础加固与内核调优

首先，进行系统更新和最小化服务原则加固。

# 1. 更新系统 sudo yum update -y # 2. 禁用不必要的服务（示例，根据实际情况调整） sudo systemctl disable rpcbind sudo systemctl disable nfs-server # 查看所有开机自启服务，酌情禁用 sudo systemctl list-unit-files --type=service | grep enabled # 3. 配置防火墙基础策略（使用firewalld） sudo systemctl start firewalld sudo systemctl enable firewalld # 放行必要端口 sudo firewall-cmd --permanent --add-service=http sudo firewall-cmd --permanent --add-service=https sudo firewall-cmd --permanent --add-port=22/tcp # SSH端口，建议后续修改为非22并设置端口敲门 sudo firewall-cmd --reload # 设置默认区域为drop（激进策略，新手慎用）或更安全的public # sudo firewall-cmd --set-default-zone=drop

接着，应用我们之前讨论的内核参数优化，编辑/etc/sysctl.conf并执行sysctl -p。

3.2 Nginx防护配置实战

安装Nginx后，进行深度防护配置。

# 安装Nginx sudo yum install nginx -y sudo systemctl start nginx sudo systemctl enable nginx

编辑Nginx主配置文件/etc/nginx/nginx.conf，在http块内进行全局限流设置，并在具体的server块中应用。

user nginx; worker_processes auto; # 根据CPU核心数调整 error_log /var/log/nginx/error.log warn; pid /run/nginx.pid; # 限制每个worker进程能打开的最大文件描述符数，对应系统级连接数 worker_rlimit_nofile 65535; events { worker_connections 65535; # 增大单个worker的连接数 use epoll; # 使用高效的epoll模型 multi_accept on; # 允许同时接受多个新连接 } http { include /etc/nginx/mime.types; default_type application/octet-stream; # 关键：定义限流和限连接区域 # $binary_remote_addr 以二进制格式存储IP，更节省内存 limit_req_zone $binary_remote_addr zone=perip_req:10m rate=5r/s; limit_conn_zone $binary_remote_addr zone=perip_conn:10m; # 针对服务器总连接数也可以做限制（根据内存调整） limit_conn_zone $server_name zone=perserver_conn:10m; # 日志格式，加入请求时间，便于分析慢请求和攻击 log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for" ' 'rt=$request_time uct="$upstream_connect_time" uht="$upstream_header_time" urt="$upstream_response_time"'; access_log /var/log/nginx/access.log main buffer=32k flush=5s; # 缓冲写入，减轻磁盘IO压力 # 隐藏Nginx版本号，增加攻击者信息收集难度 server_tokens off; # 其他HTTP优化参数... sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 65; types_hash_max_size 2048; include /etc/nginx/conf.d/*.conf; # 一个具体的server块示例 server { listen 80 backlog=65535; # 与内核参数somaxconn对应 server_name www.yourdomain.com; # 应用全局连接数限制到本server limit_conn perserver_conn 1000; location / { # 应用针对单个IP的请求速率和连接数限制 limit_req zone=perip_req burst=10 nodelay; limit_conn perip_conn 20; limit_req_status 429; limit_conn_status 429; # 设置一个较短的代理超时，防止慢速攻击占用连接 proxy_connect_timeout 5s; proxy_send_timeout 10s; proxy_read_timeout 30s; proxy_pass http://your_backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } # 静态资源目录，可以放宽限制 location /static/ { limit_req zone=perip_req burst=20 delay=10; limit_conn perip_conn 50; alias /path/to/static/; expires 30d; } # 特别严格限制的管理员或API接口 location /admin/ { limit_req zone=perip_req burst=3 nodelay; limit_conn perip_conn 2; # 还可以结合HTTP Basic Auth增加一层认证 auth_basic "Admin Area"; auth_basic_user_file /etc/nginx/.htpasswd; proxy_pass http://your_backend; } } }

配置完成后，使用sudo nginx -t测试配置语法，无误后sudo systemctl reload nginx重载配置。

3.3 Fail2ban与Nginx联动部署

安装并配置Fail2ban，使其能够保护Nginx和SSH。

# 安装Fail2ban sudo yum install epel-release -y sudo yum install fail2ban -y # 创建本地jail配置 sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local sudo vi /etc/fail2ban/jail.local

在jail.local中，找到并修改以下段落：

[DEFAULT] # 封禁时间，单位秒，这里设置为1小时 bantime = 3600 # 查找时间窗口 findtime = 600 # 最大重试次数 maxretry = 5 # 使用的封禁动作（这里用firewalld） banaction = firewallcmd-rich-rules[actiontype=<multiport>] # 监听的协议 protocol = tcp # 日志文件路径（系统日志） logpath = /var/log/fail2ban.log # 启用SSH防护 [sshd] enabled = true port = ssh filter = sshd logpath = /var/log/secure maxretry = 3 # SSH尝试3次失败就封 # 新增Nginx HTTP认证防护 [nginx-http-auth] enabled = true filter = nginx-http-auth port = http,https logpath = /var/log/nginx/error.log # 认证错误通常会记录在这里 maxretry = 3 # 新增Nginx CC攻击防护（需要自定义filter） [nginx-cc] enabled = true port = http,https filter = nginx-cc logpath = /var/log/nginx/access.log maxretry = 200 # 在findtime时间内请求超过200次 findtime = 60 bantime = 1800 # 封禁30分钟 action = iptables-multiport[name=nginx-cc, port="http,https", protocol=tcp]

现在，创建自定义的nginx-cc过滤器：

sudo vi /etc/fail2ban/filter.d/nginx-cc.conf

输入以下内容：

[Definition] # 匹配Nginx访问日志中的行 failregex = ^<HOST> -.*$ # 可选：如果日志格式复杂，可以定义更精确的正则，例如匹配所有请求 # failregex = ^<HOST> -.*\"(GET|POST|HEAD).*$ ignoreregex = # 使用datepattern匹配日志中的时间 datepattern = %%d/%%b/%%Y:%%H:%%M:%%S

这个过滤器比较简单，它会把所有访问IP都计入。Fail2ban会根据maxretry和findtime来判断：如果在60秒内，同一个IP在日志中出现了200次（即请求了200次），就触发封禁。这是一个非常基础的CC防护，可能会误伤。更高级的做法是编写匹配特定攻击模式的failregex，例如短时间内大量请求不存在的URL（404）、或者大量请求耗时的动态接口。

启动并设置开机自启Fail2ban：

sudo systemctl start fail2ban sudo systemctl enable fail2ban # 查看状态 sudo fail2ban-client status # 查看具体的“监狱”状态 sudo fail2ban-client status nginx-cc

4. 高级防护与边缘策略

当基础防护部署完毕后，我们可以考虑一些更高级或边缘性的策略，以应对更复杂的攻击场景。

4.1 启用TCP Wrappers（辅助手段）

TCP Wrappers是一个历史悠久的访问控制工具，通过/etc/hosts.allow和/etc/hosts.deny文件来控制服务的访问。它作为防火墙的补充，配置简单。

# 编辑hosts.deny，默认拒绝所有 sudo vi /etc/hosts.deny # 加入一行 ALL: ALL # 编辑hosts.allow，放行信任的IP或网段 sudo vi /etc/hosts.allow # 放行SSH，仅允许来自192.168.1.0/24和特定IP的访问 sshd: 192.168.1.0/255.255.255.0 sshd: 203.0.113.5 # 放行所有对Nginx的访问（因为前面已有更精细的控制，这里可以宽松） nginx: ALL

注意：TCP Wrappers仅适用于通过libwrap库编译的服务（如sshd, vsftpd）。现代服务如Nginx默认可能不支持。使用前需用ldd $(which sshd) | grep libwrap检查服务是否支持。

4.2 使用Cloudflare等CDN服务

对于公开的Web业务，将服务器隐藏在Cloudflare、阿里云CDN等服务的背后，是性价比极高的DDoS缓解方案。这些CDN服务商拥有巨大的带宽和全球分布的清洗中心。

• 工作原理：你将域名的DNS解析指向CDN服务商提供的CNAME记录。所有用户访问首先到达CDN的全球边缘节点。CDN会缓存静态内容，并对动态请求进行代理转发。攻击流量在CDN边缘就被识别和清洗。
• 配置要点：
  1. 修改DNS：将你的域名NS服务器指向CDN服务商，或添加CNAME记录。
  2. 配置防火墙：在服务器防火墙（如firewalld）中，只允许CDN的回源IP段访问你的80/443端口，拒绝所有其他公网IP的直接访问。这能有效防止攻击者绕过CDN直接攻击你的源站IP。Cloudflare的回源IP列表可以在其官网找到。
  3. 启用CDN安全功能：在CDN控制台开启“Under Attack Mode”（挑战模式）、设置WAF规则、速率限制等。

4.3 架构层面的思考

对于核心业务，单台服务器抗DDoS的能力总是有限的。需要考虑分布式架构：

• 负载均衡：使用多台服务器组成集群，通过负载均衡器（如Nginx, HAProxy, 或云厂商的SLB）分发流量。即使单台被攻瘫，其他节点仍可提供服务。
• 异地多活/灾备：在多个地域部署服务，利用DNS智能解析或全局负载均衡（GSLB）将用户导向健康的节点。
• 微服务与弹性伸缩：将应用拆分为微服务，并结合容器化技术（如Docker+K8s）和云平台的自动伸缩组（Auto Scaling）。在遭受攻击流量激增时，可以自动扩容后端实例数量来分摊压力，攻击停止后再自动缩容以控制成本。

5. 攻击发生时的应急响应与排查实录

即使防护做得再好，也需要有应对攻击的预案。当监控告警响起，怀疑遭受DDoS攻击时，应按以下步骤冷静处理：

5.1 初步判断与影响隔离

1. 确认症状：通过监控图表，确认是否是带宽突然打满、TCP连接数飙升、CPU/内存异常、还是应用大量返回5xx错误。
2. 登录服务器：如果SSH还能连接，立即登录。如果无法连接，尝试通过云服务商提供的VNC控制台登录。
3. 快速止血：
   • 启用备用IP/域名：如果业务有备用入口，立即将流量切换过去。
   • 联系云服务商：如果攻击流量已超过基础防护阈值触发黑洞，立即联系客服，了解黑洞解封时间，并咨询升级高防服务的流程。
   • 临时扩容带宽（谨慎）：对于云服务器，临时升级带宽可能能缓解小流量攻击，但对于大流量攻击杯水车薪，且成本极高。

5.2 攻击源分析与临时封禁

在服务器上，快速使用命令分析攻击特征。

# 1. 查看实时网络流量（按流量排序） sudo iftop -nNP # 2. 查看当前活跃连接数最多的IP sudo netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n | tail -20 # 3. 分析Nginx访问日志，统计近期请求最频繁的IP（假设攻击从1分钟前开始） sudo tail -n 10000 /var/log/nginx/access.log | awk -vDate=`date -d'now-1 minutes' +[%d/%b/%Y:%H:%M:%S` '$4 > Date {print $1}' | sort | uniq -c | sort -rn | head -20 # 4. 如果发现明显的攻击源IP段，使用firewalld批量封禁（例如封禁整个/24网段） sudo firewall-cmd --permanent --add-rich-rule="rule family='ipv4' source address='1.2.3.0/24' reject" sudo firewall-cmd --reload

5.3 日志深度分析与取证

攻击缓解后，需要分析日志，了解攻击类型，为后续加固提供依据。

# 1. 分析攻击时间段的HTTP状态码分布 sudo awk '$4>="[24/Mar/2025:15:00:00" && $4<="[24/Mar/2025:15:10:00"' /var/log/nginx/access.log | awk '{print $9}' | sort | uniq -c # 2. 分析攻击请求的User-Agent（常用于识别攻击工具） sudo awk '$4>="[开始时间" && $4<="[结束时间"' /var/log/nginx/access.log | awk -F\" '{print $6}' | sort | uniq -c | sort -rn | head -20 # 3. 分析攻击请求的URL路径（常用于CC攻击） sudo awk '$4>="[开始时间" && $4<="[结束时间"' /var/log/nginx/access.log | awk -F\" '{print $2}' | awk '{print $2}' | sort | uniq -c | sort -rn | head -30

5.4 常见问题排查表

下表整理了DDoS防护中常见的问题和排查思路：

最后的个人体会是，DDoS防护没有一劳永逸的银弹。它是一场攻防成本的博弈。对于运维人员，最重要的是建立起“纵深防御”的意识，从网络边界到系统内核，再到应用层，层层设防。同时，清晰的监控和事先演练过的应急预案，往往比技术本身更重要。平时多进行压力测试，了解自己系统的瓶颈在哪里，攻击真的来临时，你才能心里有数，知道该动哪里，而不是盲目操作。把本文提到的各项配置，根据你的实际业务流量模型调整好参数并测试，你的CentOS服务器就具备了对抗常见中低强度DDoS攻击的坚实盾牌。