1. 项目概述当Web.config的防线失效时如果你负责维护一个基于IISInternet Information Services的线上业务系统并且前端部署了F5 BIG-IP这类硬件负载均衡器那么“HTTP慢速攻击”对你来说可能不是一个陌生的词汇。这种攻击不追求瞬间的流量洪峰而是像“钝刀子割肉”一样通过建立并保持大量异常缓慢的HTTP连接逐渐耗尽服务器的连接池、线程池等关键资源最终导致服务拒绝响应。更让人头疼的是很多管理员的第一反应——在IIS的Web.config文件中配置请求过滤和超时限制——在F5的介入下可能会完全失效。这不是配置写错了而是流量路径变了。当请求首先到达F5时它已经扮演了“代理”或“终结者”的角色IIS接收到的连接特性已经改变基于源IP和原始TCP行为的防护规则自然就形同虚设。这篇文章就是基于我多次在混合架构中对抗此类攻击的实战经验为你梳理出三个最容易踩坑的地方并给出针对F5负载均衡场景的具体配置指南让你构建的防线真正生效。2. 核心需求与攻击原理深度解析2.1 HTTP慢速攻击的“慢”在哪里要防御必须先理解攻击是如何奏效的。HTTP慢速攻击主要分为两类Slowloris和Slow POST。它们的核心思想不是发送恶意数据包而是“合法地”占用连接。Slowloris攻击攻击者向目标服务器发起大量HTTP请求但每次只发送一个请求头并且以极慢的速度例如每30-60秒发送一行或者发送一个不完整的“结束符”如\r\n。由于HTTP协议规定请求必须以空行结束服务器会一直等待这个请求被“完整”接收从而将这个连接挂起在等待状态。攻击者用少量机器就能建立成千上万个这样的“僵尸连接”迅速占满服务器的并发连接数在IIS中体现为maxConcurrentRequestsPerCPU等限制导致正常用户无法建立新连接。Slow POST攻击攻击者发送一个合法的、带有Content-Length头的POST请求但声明了一个非常大的body长度例如10MB。随后攻击者以极其缓慢的速度如每秒几个字节发送实际的body数据。服务器会为这个请求分配缓冲区并等待所有数据上传完毕同样长时间占用一个工作线程或连接资源。这两种攻击之所以阴险是因为它们模拟了“网络状况不佳的合法用户”行为传统的基于流量阈值或特征码的WAFWeb应用防火墙规则很难精准识别和拦截。2.2 为什么Web.config的配置会“失效”这是第一个大坑也是很多混合架构运维人员的困惑点。我们通常会在Web.config的system.webServer节点下配置如下规则来防御security requestFiltering requestLimits maxAllowedContentLength52428800 / !-- 限制POST body大小 -- headerLimits add headerContent-type sizeLimit100 / /headerLimits /requestFiltering /security或者通过URL重写模块设置连接超时rewrite outboundRules rule nameSlowloris Protection match serverVariableRESPONSE_Connection pattern.* / conditions add input{HTTP_HOST} patternlocalhost negatetrue / /conditions action typeRewrite valueclose / /rule /outboundRules /rewrite这些配置在客户端直接访问IIS服务器时是有效的。然而在典型的F5 BIG-IP负载均衡架构中流量路径是这样的客户端 - F5 BIG-IP虚拟服务器VIP - 后端IIS服务器池在这种情况下F5默认会与客户端建立一个完整的TCP连接然后再与后端IIS服务器建立另一个独立的TCP连接。IIS看到的所有请求的源IP都是F5设备的内部IPTCP连接的建立和关闭行为也由F5控制。这意味着源IP失效你无法在IIS层面基于客户端真实IP进行频率限制或黑名单拦截因为所有请求都来自一两个F5的IP。连接行为改变Slowloris攻击中缓慢的TCP数据发送行为发生在客户端与F5之间。F5作为一个完整的TCP代理它可能会在自身层面设置超时或者以“正常”的速度将请求转发给IIS。IIS根本感知不到前端的“慢速”特性基于TCP层行为的防护完全失效。协议终结如果F5上配置了SSL卸载这是常见做法那么HTTPS请求在F5处就被解密成了HTTP再以明文传给IIS。此时攻击可能已经在F5的HTTPS处理层面发生IIS的HTTP模块规则同样无法触及。所以防御的主战场必须前移核心防线需要构筑在F5 BIG-IP这一层。3. F5 BIG-IP负载均衡配置实战指南既然主战场在F5我们的配置就需要围绕F5的**虚拟服务器Virtual Server和策略iRules**来展开。F5提供了强大的可编程能力允许我们深度检测并干预流量。3.1 第一个坑未启用或错误配置连接超时与空闲超时这是最基础的防线但配置不当等于没设。F5上有多个超时参数需要协同工作。配置要点调整虚拟服务器的超时设置登录F5管理界面或通过TMSH命令行找到你的HTTP/HTTPS虚拟服务器。Idle Timeout空闲超时这是最重要的参数之一。它定义了F5在收到上一个数据包后等待下一个数据包的最大时间。对于防御Slowloris这个值应该设置得比较激进。通常一个正常的HTTP请求头应该在几秒内发送完毕。你可以将其设置为10-30秒而不是默认的300秒。Client Side / Server Side Timeout确保客户端和服务器侧的超时设置合理避免等待时间过长。实操心得不要只改虚拟服务器的超时。如果F5前面还有防火墙或其他设备需要确保它们的TCP超时时间比F5的更短否则连接可能会在到达F5之前就被上游设备清掉导致F5的规则无法触发。在iRule中实现请求头接收超时这是更精细的控制。我们可以写一个iRule在请求到达时开始计时如果在一定时间内没有收到完整的请求头以空行\r\n\r\n为标志则主动断开连接。when HTTP_REQUEST { # 设置接收完整请求头的最大时间例如5秒 set header_timeout 5 # 启动定时器 set timer_id [after ${header_timeout}000 [list slowloris_detect [IP::client_addr] [TCP::client_port]]] # 将定时器ID存储在连接变量中以便在请求完成后取消 set conn_timer [HTTP::header X-Conn-Timer] if { $conn_timer ne } { after cancel $conn_timer } HTTP::header insert X-Conn-Timer $timer_id } when HTTP_REQUEST_DATA { # 当收到请求数据时检查是否已收到完整的请求头HTTP::header 已存在 # 如果收到取消定时器 set timer_id [HTTP::header value X-Conn-Timer] if { $timer_id ne } { after cancel $timer_id HTTP::header remove X-Conn-Timer } } proc slowloris_detect { client_ip client_port } { log local0. Slowloris attack detected from $client_ip:$client_port. Closing connection. # 可以选择记录日志或发送到安全事件管理系统 # 然后丢弃连接 reject }注意事项这个iRule会增加F5设备一定的处理开销。在生产环境应用前务必在测试环境进行性能评估。同时超时时间header_timeout需要根据业务实际情况调整对于某些确实需要长时间上传大文件的合法接口可能需要设置白名单。3.2 第二个坑缺乏对请求速率和异常连接数的限制单一的连接超时可能被绕过攻击者可以建立大量“合规”的短时慢速连接。因此我们需要在F5层面实施频率限制。配置要点使用F5的AFM高级防火墙管理器或经典防火墙策略可以创建一条规则限制单个源IP在单位时间内发起的HTTP新建连接数。例如限制每个IP每秒最多建立10个新连接。这能有效减缓攻击者建立僵尸连接的速度。利用iRule和表table命令进行会话跟踪F5的iRule支持使用table命令在内存中维护键值对我们可以用它来跟踪IP的行为。when CLIENT_ACCEPTED { set client_ip [IP::client_addr] # 检查该IP在过去60秒内的连接数 set conn_count [table key -count -subtable slow_conn $client_ip] if { $conn_count 50 } { # 如果超过阈值例如50个连接记录日志并拒绝 log local0. Connection flood detected from $client_ip. Count: $conn_count reject return } # 增加该IP的连接计数设置60秒过期 table set -subtable slow_conn $client_ip 1 60 60 } when CLIENT_CLOSED { # 连接关闭时减少计数可选更精确但增加开销 # 或者依赖table项的自动过期 }配置F5的DoS防护配置文件如果你的F5许可证包含AFM模块强烈建议启用并配置DoS防护。它可以基于多种维度如每秒包数、每秒连接数、源IP命中率等进行检测和缓解并且是硬件加速的性能影响远小于纯iRule实现。踩坑实录我曾经遇到一个案例仅用iRule做连接数限制在遭遇大规模分布式慢速攻击每个攻击IP连接数都不高时效果不佳。后来启用了AFM的DoS防护基于虚拟服务器总体的新建连接速率和并发连接数设置阈值才真正扛住了攻击。硬件层面的防护能力是软件脚本无法比拟的。3.3 第三个坑忽略了对POST请求body接收速率的监控针对Slow POST攻击我们需要监控请求body的传输速率。配置要点在iRule中监控HTTP_REQUEST_DATA事件该事件在F5收到请求体数据块时触发。我们可以计算数据接收的间隔和平均速率。when HTTP_REQUEST { # 仅对POST等方法检查 if { [HTTP::method] equals POST } { set content_length [HTTP::header Content-Length] if { $content_length 1048576 } { # 例如超过1MB的POST body需要监控 set start_time [clock clicks -milliseconds] set bytes_received 0 set last_receive_time $start_time # 设置最小接收速率例如10KB/秒 set min_rate 10240 } } } when HTTP_REQUEST_DATA { if { [info exists content_length] } { incr bytes_received [string length [HTTP::payload]] set current_time [clock clicks -milliseconds] set elapsed [expr {$current_time - $last_receive_time}] if { $elapsed 1000 } { # 至少每1秒计算一次速率 set current_rate [expr {($bytes_received * 1000.0) / $elapsed}] if { $current_rate $min_rate } { # 速率过低疑似Slow POST log local0. Slow POST detected from [IP::client_addr]. Rate: [format %.2f $current_rate] B/s, Expected $min_rate B/s # 可以选择断开连接或发送408超时响应 HTTP::respond 408 content htmlbodyRequest Timeout/body/html return } set last_receive_time $current_time # 重置计数进行下一轮检查或计算全局平均速率 set bytes_received 0 } } }在F5策略中限制最大POST body大小虽然IIS的Web.config里配了maxAllowedContentLength但在F5层面再加一道关卡更保险。可以在虚拟服务器的HTTP Profile中或通过iRule在转发请求前检查Content-Length头如果超过合理值如10MB直接返回413Request Entity Too Large响应。when HTTP_REQUEST { set cl [HTTP::header Content-Length] if { $cl ne $cl 10485760 } { # 10MB HTTP::respond 413 content htmlbodyPayload Too Large/body/html return } }4. 配置集成、测试与监控4.1 配置集成与优先级将上述iRule和配置应用到虚拟服务器时需要注意执行顺序。一个建议的顺序是第一道防线iRule执行频率限制连接数检查。这能最早地拒绝明显的洪水攻击。第二道防线iRule执行请求头超时检测Slowloris检测。第三道防线iRule执行POST body速率检测和大小限制Slow POST检测。底层配置确保虚拟服务器和F5系统级别的TCP/HTTP超时参数设置合理。终极防护启用并正确配置AFM的DoS防护策略。你可以将多个检测逻辑合并到一个复杂的iRule中也可以拆分成多个iRule并按顺序关联到虚拟服务器。合并有利于管理拆分则更清晰且便于单独禁用某个检测。4.2 如何测试你的防护是否生效在正式上线前必须测试。切勿直接对生产环境进行攻击测试搭建测试环境复制一份生产环境的F5和IIS配置到隔离的测试网络。使用工具模拟攻击Slowloris测试可以使用slowhttptest工具。命令示例slowhttptest -c 1000 -H -g -o slowloris_report -i 10 -r 200 -t GET -u http://测试VIP:端口/ -x 24 -p 3Slow POST测试同样使用slowhttptestslowhttptest -c 500 -B -g -o slowpost_report -i 110 -r 200 -s 8192 -t FAKEVERB -u http://测试VIP:端口/ -x 30 -p 3观察与验证在F5的日志/var/log/ltm中查看你的iRule中log local0.输出的信息。通过F5的图形界面监控虚拟服务器的“活动连接数”、“新建连接速率”等图表。在攻击开始后这些指标应被你的规则限制在一个合理范围不会持续飙升。观察后端IIS服务器的性能计数器如Current Connections,Requests/Sec应该保持相对稳定CPU和内存不会因攻击而耗尽。使用正常客户端访问测试网站确保业务功能不受防护规则影响误杀。4.3 监控与应急响应配置不是一劳永逸的需要持续监控。集中化日志将F5的local0日志包含你的iRule日志转发到SIEM安全信息和事件管理系统如Splunk、ELK等。设置告警规则当出现大量“Slowloris attack detected”或“Connection flood”日志时触发告警。仪表盘在监控系统中创建仪表盘关键指标包括F5虚拟服务器的并发连接数、新建连接速率、丢弃连接数后端IIS的请求队列长度、工作进程数。应急流程当告警触发时除了检查F5日志应立即登录F5查看实时连接数tmsh show sys connection cs-server-addr VIP是一个快速命令。如果确认攻击可以临时在F5上手动将攻击源IP加入黑名单或者快速调整iRule中的阈值参数如降低单个IP连接数限制。5. 常见问题排查与进阶思考5.1 配置后网站变慢或部分功能异常这是典型的误杀或配置过严。排查方向检查超时时间header_timeout是否太短某些前端JS框架或移动端在网络不佳时发送请求头可能较慢。可以适当延长或对已知的API网关IP、CDN节点IP设置白名单。检查连接数限制单个IP的连接数限制是否低于某些合法场景例如一个公司出口NAT后的IP可能承载数百个员工的连接。需要考虑放宽阈值或对内部网络段放行。检查POST速率限制min_rate设置是否过高对于用户确实在慢速上传大文件的情况如网盘这个规则会误杀。考虑对特定的URL路径如/api/upload禁用此规则或设置更低的速率阈值。解决方法永远采用渐进式部署。先在测试环境充分验证然后在生产环境对少量非关键业务服务器应用iRule观察一段时间无误后再逐步推广到全站。利用F5的iRule调试器tmsh下的debug命令可以单步跟踪规则执行是定位问题的利器。5.2 F5设备CPU或内存使用率异常升高复杂的iRule特别是那些频繁操作table或进行字符串运算的规则会增加F5设备的负担。排查方向登录F5使用top命令或通过图形界面查看tmm进程的CPU使用率。在攻击模拟期间观察CPU增长是否与iRule逻辑匹配。优化建议简化逻辑检查iRule中是否有不必要的循环或复杂的正则表达式。使用AFM将频率限制、DoS防护等重逻辑卸载到AFM模块利用硬件加速。采样记录非必要情况下不要对每个请求都记录完整日志log local0.可以改为每N次攻击记录一次或者仅当连接数超过一个更高阈值时才记录。评估设备性能确认当前F5设备的型号和性能规格是否足以承载你部署的安全策略。在流量巨大的场景可能需要性能更强的型号或考虑分布式防护方案。5.3 与后端IIS其他安全配置的协同F5的防护是第一道关卡后端的IIS安全配置依然重要它们负责防御不同类型的威胁。协同策略IP白名单在IIS的Web.config或防火墙中将F5设备的内部IP地址设置为唯一允许访问的来源。这样即使攻击者绕过F5直接扫描后端服务器IP也会被拒绝。请求过滤Web.config中的maxAllowedContentLength、maxQueryString等限制依然有效作为最后一道数据校验防线。动态IP限制模块虽然对F5 IP无效但如果你的架构中F5不是唯一入口例如某些管理后台直连服务器这个模块对直连流量仍有保护作用。SSL/TLS配置如果F5做了SSL卸载确保F5与IIS之间的内网通信也可以是HTTPS终端到终端加密或者至少是受信任的网络。同时在F5上配置强密码套件和协议版本禁用SSLv3, TLS 1.0等这部分安全责任就转移到了F5。5.4 云原生与容器环境下的思考如果你的后端已经不是传统的IIS服务器而是跑在Docker容器里的Java Web应用前面用Nginx做负载均衡思路依然是相通的只是工具变了。Nginx配置Nginx的client_header_timeout,client_body_timeout,keepalive_timeout等指令以及limit_conn_zone、limit_req_zone模块其作用完全对应F5的超时和限流配置。例如http { limit_conn_zone $binary_remote_addr zoneperip:10m; limit_conn_zone $server_name zoneperserver:10m; server { limit_conn perip 10; # 每个IP最多10个连接 limit_conn perserver 100; # 每个server最多100个连接 client_header_timeout 10s; client_body_timeout 10s; # 针对Slow POST限制客户端body传输速率 client_body_in_single_buffer on; client_max_body_size 10m; } }Kubernetes Ingress如果是K8s环境可以通过Annotations为Ingress Controller如Nginx Ingress配置类似的超时和限流参数。云WAF考虑使用阿里云、AWS WAF等云服务提供的速率限制规则和自定义规则它们通常能更轻松地应对应用层慢速攻击。防御HTTP慢速攻击尤其是在复杂的负载均衡架构下关键在于理解流量路径并将防御点部署在能够最早识别攻击特征的位置。对于F5IIS的组合把F5 BIG-IP作为主防线的策略是正确且高效的。通过组合连接超时、频率限制、行为分析请求头/体接收速率这三层配置并辅以严格的测试和监控你就能构建一道坚实的屏障让那些“慢吞吞”的攻击无处遁形。记住安全配置从来不是“设好就忘”持续的观察、调优和与业务发展的适配才是长治久安之道。
)
