1. 项目缘起一个“钓鱼”式防御的奇思妙想前几天在服务器日志里看到一个挺有意思的现象有个扫描器在孜孜不倦地请求我服务器上各种可能的压缩包路径比如/backup.zip、/wwwroot.rar、/database.tar.gz之类的。这显然是自动化攻击工具在寻找网站备份文件一旦被它找到后果不堪设想。大多数人的做法是直接返回404或者用防火墙规则屏蔽掉这些IP。但当时我就在想能不能玩点不一样的既然它这么想要“大礼包”那不如就送它一个——一个永远下载不完的“惊喜”。这个想法的核心就是利用Nginx的配置让对特定压缩文件如.zip.rar的请求直接返回一个301或302跳转但这个跳转的目标不是一个真实的网页而是一个指向服务器本地超大文件比如一个50GB的虚拟文件或设备的链接。当扫描器遵循这个跳转去“下载”时就会陷入一个漫长的、几乎不可能完成的下载过程中大量消耗其带宽、连接数和线程资源从而起到干扰和延缓攻击的作用。这算不上一种硬防御更像是一种带有恶作剧性质的“软对抗”或资源消耗策略。2. 核心原理拆解空链接、跳转与无限响应要实现这个“惊喜大礼包”我们需要理解几个关键的技术点是如何串联起来的。2.1 空链接Dummy Link与301/302跳转首先什么是“空链接”在这里它并不是指一个href”#”的HTML标签而是指在服务器端我们为一个不存在的文件路径例如/fake_download/bigfile.zip配置了特殊的处理规则。当Nginx接收到对/backup.zip的请求时我们并不去磁盘上查找这个文件而是直接生成一个HTTP响应这个响应的状态码是301 Moved Permanently或302 Found并在响应头Location字段中指定跳转的目标URL也就是我们的“空链接”地址。为什么用301而不是302从语义上讲301是永久重定向。对于扫描器这类自动化工具一旦它收到301响应并记录下这个跳转关系下次它可能就会直接跳过初始请求尝试请求最终目标这反而可能减轻我们源站的压力。而302是临时重定向扫描器每次都可能重新走一遍完整的请求流程。在这个“消耗战”场景下使用302可能更能持续地消耗对方资源。不过许多简陋的扫描器可能并不严格区分两者都会直接跟进。我们可以根据实际情况选择。2.2 指向大文件/dev/zero与limit_rate的妙用跳转的目标需要是一个“大文件”。在Linux服务器上我们当然可以准备一个真实的50GB文件但这太浪费磁盘空间。更优雅的方案是使用特殊设备文件例如/dev/zero或/dev/urandom。/dev/zero: 这是一个能提供无限个空字符\0的虚拟设备。读取它会源源不断地得到0x00字节流。/dev/urandom: 这是一个提供随机数据的虚拟设备。我们可以让Nginx将跳转后的请求代理到或者直接以静态文件的方式处理这些特殊设备。当客户端扫描器开始下载时Nginx就会尝试从/dev/zero读取数据并发送这个过程理论上是无限的。但这里有个关键问题如果直接全速发送可能会很快占满我们服务器的上行带宽伤敌一千自损八百。因此必须引入limit_rate指令。这个指令可以限制Nginx向单个客户端发送响应的速率例如limit_rate 50k;表示限速为每秒50KB。这样我们就可以控制资源消耗的程度让扫描器慢速地“下载”这个无限大的文件长时间占用其一个连接线程而我们自身的带宽占用则在一个可控的、很低的水平。2.3 应对HEAD请求扫描器的常见伎俩一个成熟的扫描器不会傻到直接去下载它认为的“备份文件”。为了效率它通常会先发送一个HEAD请求来探测目标。HEAD方法与GET类似但服务器只返回响应头不返回响应体。通过检查响应头中的Content-Length如果存在扫描器就能知道文件大小如果发现文件巨大比如50GB它可能直接放弃下载从而让我们的陷阱失效。因此我们的配置必须能够识别并特殊处理HEAD请求。对于HEAD请求我们不能让它也陷入慢速下载流而是应该“正常”地返回一个包含虚假Content-Length头的响应比如告诉它这个文件大小是5368709120050GB的字节数然后立即结束连接。这样扫描器会认为这是一个真实存在的大文件更有可能在后续步骤中发起真正的GET请求来下载从而落入我们的流量消耗陷阱。3. Nginx配置实战从零搭建“陷阱”服务器下面我将手把手展示如何配置一个Nginx服务器实现针对.zip和.rar文件请求的“惊喜大礼包”跳转。假设我们的网站域名为example.com。3.1 基础环境与Nginx安装首先确保你有一台Linux服务器如CentOS 7/8或Ubuntu 20.04/22.04。使用包管理器安装Nginx是最快的方式# CentOS/RHEL sudo yum install epel-release sudo yum install nginx # Ubuntu/Debian sudo apt update sudo apt install nginx安装后启动Nginx并设置开机自启sudo systemctl start nginx sudo systemctl enable nginxNginx的主配置文件通常位于/etc/nginx/nginx.conf而站点配置文件通常在/etc/nginx/conf.d/目录下或以sites-available/sites-enabled的形式组织Ubuntu常见。我们将在/etc/nginx/conf.d/trap.conf创建一个新的配置文件。3.2 核心配置代码解析创建并编辑配置文件sudo vim /etc/nginx/conf.d/trap.conf将以下配置内容写入。我会逐段进行解释server { listen 80; server_name example.com; # 替换为你的域名 root /var/www/html; # 你的网站根目录按需修改 # 核心陷阱匹配常见的压缩文件请求 location ~* \.(zip|rar|tar\.gz|7z|sql)$ { # 默认返回404这是安全基线。我们将在后面覆盖它。 # 这里先注释掉实际使用时应保留一个安全的默认行为。 # return 404; # 定义跳转目标路径这是一个虚拟路径不对应真实文件 set $trap_url /trap_file.bin; # 处理HEAD请求返回一个虚假的大文件头信息 if ($request_method HEAD) { add_header Content-Type application/octet-stream; add_header Content-Length 53687091200; # 50 GB add_header X-Accel-Redirect $trap_url; # 内部标记非必须 return 200; } # 处理GET请求进行302跳转到陷阱地址 if ($request_method GET) { return 302 $trap_url; } # 其他请求方法如POST直接返回405或404 return 405; } # 陷阱目标地址的处理逻辑 location /trap_file.bin { internal; # 重要标记为内部位置只能由Nginx内部重定向访问防止直接访问 # 使用 /dev/zero 作为数据源无限的空字节流 # 也可以使用 /dev/urandom (无限随机数据)但可能增加CPU负担 alias /dev/zero; # 关键限制向客户端发送数据的速率单位是字节/秒 # 这里设置为每秒50KB (50 * 1024 51200)这是一个温和的消耗值 limit_rate 50k; # 设置一个超长的超时时间让连接保持足够久 proxy_read_timeout 3600s; # 1小时 proxy_send_timeout 3600s; # 设置响应头让它看起来像一个普通的二进制文件下载 add_header Content-Type application/octet-stream; # 注意这里不设置Content-Length因为/dev/zero是无限的 # 浏览器或下载工具会显示为“未知大小”或持续增长的下载 } # 你网站正常的其他处理逻辑放在这里 location / { try_files $uri $uri/ 404; # ... 你的PHP、静态文件等配置 } }配置要点与避坑指南internal指令至关重要location /trap_file.bin中的internal意味着这个路径不能通过外部的URL直接访问例如用户直接访问http://example.com/trap_file.bin会得到404。它只能通过Nginx内部的return 302或rewrite等指令来访问。这避免了陷阱被意外触发或探测。alias与root我们使用alias /dev/zero;而不是root。alias会将定义的路径/trap_file.bin完全映射到指定的文件系统路径/dev/zero。如果使用rootNginx会去/dev/zero/trap_file.bin找文件这显然是错误的。limit_rate的位置limit_rate指令放在location块中对所有匹配的请求生效。这是控制带宽消耗的生命线。数值需要根据你的服务器带宽和想要达到的“消耗”强度来调整。50k50KB/s是一个起始值对于消耗扫描器资源来说已经足够且对服务器影响极小。HEAD请求的欺骗性在HEAD请求的处理中我们手动添加了Content-Length: 53687091200。这个数字就是50 * 1024 * 1024 * 1024。虽然我们返回了200状态码但因为HEAD请求不接收body连接会立即关闭不会触发慢速下载。这个虚假的大小信息是诱使扫描器发起GET下载的关键。安全性考量最初的location ~* \.(zip|rar...)$块里我注释掉了return 404。在实际部署时你应该保留一个安全的默认行为。一个更严谨的做法是先默认返回404然后通过特定的条件比如来自某些IP段或User-Agent的请求才触发陷阱。可以使用geo模块或map模块结合if来实现条件化触发避免误伤正常用户或搜索引擎爬虫。3.3 配置测试与生效编写完配置后首先检查语法是否正确sudo nginx -t如果显示syntax is ok和test is successful就可以重载Nginx使配置生效sudo nginx -s reload # 或者使用 systemctl sudo systemctl reload nginx现在你可以进行测试了。注意不要用浏览器直接测试陷阱URL因为internal指令会阻止而应该测试跳转逻辑。测试HEAD请求使用curl命令。curl -I http://example.com/backup.zip你应该看到类似以下的响应头特别注意Content-Length和状态码200HTTP/1.1 200 OK Server: nginx/1.20.1 Date: ... Content-Type: application/octet-stream Content-Length: 53687091200 Connection: keep-alive测试GET请求触发跳转同样使用curl但跟随跳转 (-L) 并限制只输出头信息 (-I) 来观察。curl -I -L http://example.com/backup.zip你会先看到一个302 Found响应Location头指向/trap_file.bin。然后curl会跟随跳转发起第二个请求。由于第二个请求是GET/trap_file.bin它会开始接收数据流。因为加了-Icurl会在收到头后断开但你可能会观察到连接持续了一小会儿因为Nginx开始发送数据了。如果不加-Icurl会一直下载下去直到你手动中断CtrlC。4. 高级玩法与防御增强基础的陷阱已经搭建完成但我们可以让它更智能、更隐蔽同时加强自身防御。4.1 动态陷阱与日志分析静态的压缩文件路径如backup.zip可能被很快识别。我们可以结合Nginx的map指令或Lua模块如OpenResty动态生成陷阱路径。例如使用map将一个变量映射到随机的陷阱路径map $request_uri $trap_path { default 0; ~*\.(zip|rar|tar\.gz) 1; } server { ... location ~* \.(zip|rar|tar\.gz)$ { if ($trap_path) { # 生成一个随机的陷阱文件名增加识别难度 set_md5 $random_trap $remote_addr$http_user_agent; set $trap_url /trap_${random_trap}.bin; return 302 $trap_url; } return 404; } ... }同时在陷阱的location中我们可以记录详细的访问日志包括客户端IP、User-Agent、下载持续时间、传输字节数等用于后续分析攻击源。location /trap_file.bin { internal; alias /dev/zero; limit_rate 50k; access_log /var/log/nginx/trap_access.log trap_format; ... } # 在http块中定义日志格式 log_format trap_format $remote_addr - $remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent $http_x_forwarded_for TrapHit:1 Duration:$request_time;4.2 结合WAF与速率限制单纯的消耗陷阱可能不足以应对高级攻击。应该将其作为纵深防御的一环。前置WAFWeb应用防火墙使用ModSecurity、NAXSI或云WAF服务可以拦截更复杂的攻击载荷陷阱主要对付简单的目录/文件扫描。Nginx原生速率限制使用limit_req_zone和limit_req对特定URL路径如包含.zip的请求进行请求频率限制。超过频率的请求直接返回429Too Many Requests这能有效减缓扫描速度。http { limit_req_zone $binary_remote_addr zonescanner:10m rate1r/s; server { location ~* \.(zip|rar)$ { limit_req zonescanner burst5 nodelay; # ... 原有的陷阱或404逻辑 } } }Fail2ban联动分析Nginx的陷阱日志或错误日志。如果一个IP地址在短时间内多次触发陷阱或返回404可以通过Fail2ban调用iptables或firewalld临时封禁该IP一段时间。4.3 针对扫描器特征的优化一些扫描器有特定的User-Agent或行为模式。我们可以利用这些特征进行更精准的“投喂”。User-Agent过滤在触发陷阱的条件中增加对常见扫描器User-Agent的判断如包含niktosqlmapacunetix等。if ($http_user_agent ~* (nikto|sqlmap|acunetix|wpscan)) { set $trap 1; } if ($request_uri ~* \.(zip|rar|sql)$) { set $trap ${trap}1; } # 如果$trap变量等于11则说明同时满足扫描器UA和压缩文件路径两个条件 if ($trap 11) { return 302 $trap_url; } **注意**这种方法可能产生误判且扫描器可以轻易伪造User-Agent。它更适合作为辅助判断条件。 * **响应延迟**除了慢速下载还可以在跳转前加入随机延迟模拟大型文件服务器响应慢的情况进一步拖慢扫描节奏。这可以使用Nginx的 echo_sleep 模块需额外安装或通过代理到一个小型延迟服务来实现。 ## 5. 伦理、法律与风险考量 在实施此类“主动防御”或“欺骗性防御”措施前必须清醒认识到其潜在风险。 1. **法律边界**消耗他人网络资源可能在某些司法管辖区被认定为“拒绝服务攻击”的协助行为或本身即构成违法。你的意图虽然是防御但手段上是对他方资源扫描器的带宽、连接数的主动消耗。**在实施前务必咨询法律专业人士并确保你的行为符合所在地及服务器所在地的法律法规以及你的服务提供商如云厂商的可接受使用政策AUP**。大多数云服务商明确禁止发起任何形式的DoS/DDoS攻击即使你是“反击”。 2. **伦理问题**这是一种“以攻代守”的思路。安全社区对此存在争议。一种观点认为对无差别的自动化攻击进行温和的反制是合理的另一种观点则认为防御方不应主动出击而应专注于加固自身。你需要做出自己的判断。 3. **可能引发的升级**如果你的陷阱被一个由真人操控的、更高级的攻击者识别他可能会将你的服务器标记为“有挑衅性”从而发起更猛烈、更复杂的攻击。 4. **资源反噬风险**如果配置不当例如limit_rate设置过高或陷阱被大量IP同时触发可能会消耗你服务器自身的资源带宽、连接句柄、CPU。务必通过严格的速率限制limit_req和并发连接数限制limit_conn来控制风险。 5. **误伤正常用户**如果正常用户意外访问了这些压缩文件路径比如输错了URL也会被跳转到无限下载页面导致其浏览器挂起体验极差。因此**强烈建议将陷阱的触发条件设置得尽可能严格**例如只针对来自特定可疑IP段、或请求频率异常的访问者并且要有清晰的日志记录来监控和评估误伤情况。 **一个更负责任且安全的建议是将这种“陷阱”仅作为一种日志记录和攻击者画像的工具而非资源消耗工具。** 即当检测到扫描行为时依然返回404或一个无害的错误页面但在日志中详细记录这次访问并可能触发一个警报。这样既能收集威胁情报又完全避免了法律和伦理风险。 ## 6. 监控、评估与迭代 部署了“惊喜大礼包”后工作并未结束。 1. **监控日志**定期检查陷阱的访问日志 (/var/log/nginx/trap_access.log)。观察有哪些IP中招它们的User-Agent是什么下载持续了多久。这些数据是宝贵的威胁情报。 2. **评估效果**通过日志分析估算被消耗的扫描器连接时长。结合服务器本身的资源监控如网络流量、并发连接数评估陷阱对自身服务器的影响是否在可控范围内。 3. **迭代规则**攻击者的工具和模式在变化。定期根据日志分析结果更新陷阱匹配的路径模式例如增加新的备份文件后缀 .bak, .old、扫描器特征库等。 4. **设置熔断机制**在Nginx配置中可以为陷阱location设置一个最大的输出数据量。虽然 /dev/zero 是无限的但我们可以用 limit_rate_after 配合 limit_rate或者在达到一定时间后通过 proxy_read_timeout 断开连接防止单个连接无休止。 最后我想强调的是技术是一把双刃剑。这个“压缩文件空链接跳转大文件”的方案展示了Nginx配置的灵活性和在安全对抗中的一种创造性思路。它更像是一个“趣味实验”或“概念验证”揭示了自动化攻击工具某些层面的脆弱性。但在实际生产环境中**加固服务器及时更新、最小化服务、强密码、配置正确的防火墙规则、使用可靠的WAF、以及定期进行安全审计才是构筑安全防线的根本。** 这个“惊喜大礼包”或许可以当作防线后的一道趣味篱笆但绝不能替代那些坚实的地基和围墙。