测试环境下AWS负载均衡器因账户名以"Call T"开头返回403

核心结论先行 #

AWS原生负载均衡（ALB/NLB）默认不会拦截"Call T"这类特定字符串，也没有默认规则将其标记为风险内容。问题大概率出在隐藏的监听器规则、第三方安全工具，或是请求在传输过程中的异常处理。

针对疑问的逐一解答 #

1. AWS负载均衡或其他服务会拦截"Call T"吗？

   • 负载均衡本身没有内置关键词过滤逻辑，不会主动拦截。但要排查负载均衡的监听器规则——是否有人配置了基于请求内容（比如body里的AccountName字段）的匹配规则，直接返回403。
   • 未配置WAF的情况下，AWS其他核心服务（如Shield基础版、安全组）也不会针对这类字符串做拦截，安全组只管控端口和IP，不处理请求内容。

2. AWS有默认规则标记"Call T"为风险吗？

   • 没有。AWS的WAF核心规则集（CRS）、Shield等安全服务的默认规则，都不会把"Call T"这类普通字符串判定为恶意内容。

3. 如何进一步调试？

   • 开启ALB访问日志：在负载均衡器的配置页开启日志，日志会存到指定S3桶。重点看elb_status_code和target_status_code：
     • 如果elb返回403，问题在负载均衡侧，检查监听器规则、是否关联了未察觉的WAF（比如共享WAF）；
     • 如果target返回403，说明请求到了EC2但被IIS或应用拒绝，继续排查实例内部。
   • 绕开负载均衡直接测EC2：用Postman/cURL直接访问EC2的私有IP（或公网IP），发送含"Call T"的请求。如果正常，坐实负载均衡侧问题；如果还是403，检查EC2上的第三方安全软件（如杀毒软件、主机WAF插件）、IIS的URL重写模块。
   • EC2上抓包验证：用tcpdump捕获请求包，确认"Call T"是否完整传到IIS：

     tcpdump -i any port 80 -w callt_request.pcap
     

     用Wireshark打开分析，看请求体里的AccountName字段是否正确。

4. 是否有未发现的安全机制？

   • 检查是否启用了AWS Shield Advanced：虽然主打DDoS防护，但部分高级配置可能有异常请求检测，不过默认不会拦截这类字符串；
   • 排查EC2实例上的第三方安全工具：比如服务器上安装的杀毒软件、Web应用防火墙插件（如ModSecurity），这类工具可能内置关键词库，误判"Call T"；
   • 确认是否有共享的WAF资源：比如你的AWS账号是否关联了组织内的共享WAF，该WAF有自定义规则拦截相关内容。

内容的提问来源于stack exchange，提问作者Vijay Mandanka