环境

GZCTF单实例部署在172.20.14.20、172.20.14.110、172.20.14.111三台机器的K8s集群上，使用LoadBalancer对外暴露服务，LoadBalancer IP由MetalLB分得：172.20.14.118

问题描述

2024年11月16日，2024 Redrock CTF开赛，这次比赛使用了新的比赛平台GZ::CTF - GZ::CTF Docs。

由于反向代理配置不当，导致平台在刚开赛时就因为高并发而立即崩溃，报错显示错误代码429，并且平台响应很慢，无法正常刷新。

b03f1323eec5f200d8684c9c35502050

226c63b8f33a22c1fb0d4c047c761447

排查过程

在遇到429问题后，首先是检查了配置文件中和访问限制有关的参数配置，都适当的调大，发现并没有什么改善，没有解决问题。

126925f6c7daad921c985e34c8d332fb

GZCTF是单实例部署的，为了让流量分流，我将Pod扩容，但是单实例部署与多实例部署存在差别，并且据官方介绍单实例已经能满足大部分的一般比赛（满足2000人200题），并且是官方最为推荐的部署方式。多实例部署需要配置对象存储，否则会导致数据不一致的问题。

img_v3_02gm_a97b367b-e1bb-4513-b921-79042d10b1cg

最后在咨询开发者以及在检查日志的过程中发现了问题：

配置文件中的ForwardedOptions的TrustedNetworks和TrustedProxies字段使用的是默认值，反向代理并没有生效，logs里客户端的ip全是一致的，大量的相同ip可能超过了平台的访问阈值，最后平台很容易就崩溃了。

[24-11-16 08:14:30.307 DBG] RequestLoggingMiddleware: [200]     7.10ms HTTP GET    /api/account/profile @ ::ffff:172.20.14.20 
[24-11-16 08:14:30.704 DBG] RequestLoggingMiddleware: [404]     0.22ms HTTP GET    /hub/user @ ::ffff:172.20.14.20 
[24-11-16 08:14:30.986 DBG] RequestLoggingMiddleware: [404]     1.32ms HTTP GET    /hub/user @ ::ffff:172.20.14.20

image-20241125124424828

解决

注意将ForwardedOptions的

  • TrustedNetworks值为172.20.14.20/24
  • TrustedProxies值为172.20.14.118，即GZCTF的LoadBalancer IP

整个proxy chain

172.20.14.2（网关机）-> 172.20.14.118（LoadBalancer） -> 172.20.14.20 （master1）
                                                    -> 172.20.14.110（master2）
                                                    -> 172.20.14.111 （master3）