CTFProxy - Your ultimate infrastructure to run a CTF, with a

项目说明

CTFProxy

Your ultimate CTF infrastructure, with a BeyondCorp-like Zero-Trust Network and simple infrastructure-as-code configuration.

This was used for UNSW's Web Application Security course (COMP6443 and COMP6843), for which we are running 50+ challenges with 100+ containers. Only a single command is used to build all the containers (written in Golang, Python, PHP, Jsonnet, etc.). We also have CI ser to perform auto linting, compiling, pushing, and deploying. We have a test en running docker-compose and a prod en running Kubernetes. All configurations live in a single monorepo and do not require manual (undeterministic) work.

Players are SSO-authenticated with either mTLS certificate or username/password. This authentication info is then passed as JWT to internal services. Inter-service communication is also authenticated via IP address and signed with JWT tokens. All challenges and infra services have a single configuration file called challenge.libsonnet that defines its domain names, service images, replicas, health check, flags, and access control policies. Access control policies are defined in Starlark, a dialect of Python to allow really fine-grained access control.

This is a fork of our original Geegle3

Infra Microservices

We are, by design, using an external MySQL database out of the cluster so that we won't risk losing the data in a container.

It's a TODO to add PostgreSQL support to isodb, so we can use the same isodb RPC interface to connect to different backends
for SQL injection challenges.

Installation

Configuration

First fork this repo!

You need to configure your domain name and container registry in config.bzl.

You also need to add a few commandline arguments to infra services as configuration. You can grep for FIXME to find them

Challenge Creation

TODO(adamyi): better documentation

Every challenge li its own directory under challenges/ with a single configuration file challenges.libsonnet

An example configuration looks like this:

This is all you need for your challenge - no need to configure CTFd manually. The challenge will be added lazily on CTFd.

The structure of your challenges are going to look very similar to the infra services under infra directory. In BUILD.bazel file, you need to define a :image target using rules_docker.

While you can still use Dockerfile (there's a dockerfile_image rule in bazel rules_docker), try using container_image instead. Unlike Dockerfile, this ensures that the building process is actually deterministic/reproduceable. Use all existing infra/challenges BUILD files as reference, also learn more about it here:

After creating your challenge, run bazel run //tools/ctflark to update challenges_list and container_bundle (this is automatic, you just need to run it)

User authentication info is passed to challenges in X-CTFProxy-JWT header. Response headers starting with X-CTFProxy-I- are only shown to staff, not to players. They also appear in ELK logs. Use this for better logging/debugging.

Please have a /healthz endpoint (this path is also configurable) on your challenge returning a 200. This is for load balancing and health checking purpose. Your instance will be killed and respawned if health check fails in k8s.

Domain Routing

Domain routing is handled automatically by CTFProxy. All you need is set up the challenge.libsonnet file. Specifically, your domain will be {ser}.{ctf_domain}. Multi-le are also supported. E.g., if my service is named de, and my ctf_domain is configured as adamyi.com. The service will live on .

It's recommended that you set up a wildcard record to CTFProxy so you don't need to worry about the rest (you get a nice error page if the domain doesn't exist). If you prefer to only ha for existing domains, we have our infra to set up AWS Route53 configuration. Just run bazel build //infra/jsonnet:route53. Please send a pull request if you added integration with other cloud pro.

TLS (HTTPS) is terminated by CTFProxy. You don't need to set up anything manually. It automatically pro your certificate using ACME protocol with Let's Encrypt. If you wish, you can also supply your own certificates by pro filepath to ctfproxy's commandline argument. Edit infra/ctfproxy/BUILD.bazel for this. Auto certs are propagated with GCS (Google Cloud Storage) among replicas.

Access Control

As mentioned above, you are using Starlark for access control policy. A more complex example would be:

In this example, we made a shared Wordpress instance's admin portal safe in a CTF en.

Specifically, you can call the following functions:

You also ha to the following :

Building

Please build using Linux AMD64. Cuz it's hard to set up cross-compiling for C programs on mac, ceebs.

Build only:

Build and tag locally (so that you can use docker-compose to boot them up):

Deploying (kubernetes, alpha)

We support both kubernetes and docker-compose!

While the recommended practice is to use k8s, docker-compose has not been deprecated yet. This means that we shouldn't introduce any breaking changes that rely solely on k8s api. E should be able to run on just docker.

The approach we adopted for COMP6443 is that we use docker-compose for local dev & testing, because it's simple to set up. Use k8s cluster for prod high-a deployment.

Rationale for Switching from Docker-Compose to K8S

Our manual approach for managing IP addresses works great, but we can only add service to the end of list so it gets a new ip range. Otherwise, we're changing ip addresses for existing docker networks and this requires a full reboot with downtime.

k8s gives us better service discovery and can maintain zero-downtime for adding and updating services. k8s also gives us rolling updates, replicas, scaling, etc. Also, for isolated challenges, we no longer need one server per student in k8s infra (this is not yet supported with k8s deployment and is a TODO).

The downside of k8s is that it's such a pain to set up a working cluster... But after it's set up, e just works (as long as you know what you're doing).

Deploying (docker-compose, legacy stable)

#### Main Server (Shared Server)

#### Team Server (Separate Isolated Server)

#### Test Server (All-in-one Server)

Coding Style

There's a nice tools/format.sh to run all commands above.

You can run tools/PRESUBMIT.sh to check if your code meets all style requirements and compiles correctly.

Contributing

You're welcome to contribute! Just send a pull request.

Author

Adam Yi

LICENSE

Open-sourced with lo Apache 2.0 License.

项目信息

开发语言：Go

Star 数：71

技术要点

该项目属于CTF思路方向的开源资源，代码结构清晰，适合安全研究人员学习参考。项目围绕Your ultimate infrastructure to run a CTF, with a BeyondCorp-like zero-trust network and simple infrastructure-as-code configuration.展开，提供了可运行的实现，对理解相关安全机制、工具原理与攻防技术具有较高的研究价值。

从技术实现角度看，此类项目的核心在于对底层原理的深入理解与工程化落地。开发者在研究过程中可以结合官方文档与社区讨论，梳理项目的初始化流程、核心模块职责与数据流转，逐步掌握其中的技术细节与设计思路。

使用与学习建议

1. 下载源码压缩包，解压到本地环境。

2. 根据项目类型准备对应的运行环境与依赖。

3. 按照 README 中的步骤完成配置与部署。

4. 在隔离的测试环境中运行验证，避免影响生产系统。

免责声明

本资源来源于开源社区，仅供安全研究、技术学习与合法授权范围内的攻防演练使用，请勿用于任何非法或侵害他人权益的用途。使用本项目产生的一切后果由使用者自行承担。