![\"hackers](\"https:\/\/devblogs.microsoft.com\/cse\/wp-content\/uploads\/sites\/55\/2023\/01\/host-ctf-on-azure-0.png\")
<\/p>\n<\/p>\n
Our team loves a good Capture the Flag (CTF) event! Those are usually a fun way to keep team morale high while up-skilling on new technologies or freshening up the team’s existing knowledge base.<\/p>\n
Traditionally, Capture the Flag<\/a> events are cybersecurity exercises in which “flags” are secretly hidden in a program or website and competitors steal them from other competitors (attack\/defense-style CTFs), or the organizers (jeopardy-style challenges). However, more engineering practices can be taught and practiced as a CTF event and may even not use the term CTF for it, such as our team’s OpenHack<\/a> content packs which are very similar to what CTF is all about, and include topics such as AI-Powered Knowledge Mining, ML and DevOps, containers, Serverless and Azure security.<\/p>\n Open-Source CTF frameworks make it easy to turn any<\/strong> challenge into a CTF event with configurable challenge pages, leader boards, and other expected features of such an event, using zero-code.\nFor instance, OWASP’s Juice-Shop<\/a> has a CTF plugin<\/a> that supports several common CTF platforms that you can provision and run for your teams to do security training on.<\/p>\n One of the most popular open CTF platforms is CTFd<\/a>. It is easy to use, customize, and built with open-source components. It offers several plans for managed hosting and features<\/a> you may choose from, or you could deploy and maintain your environment. Managing an environment has cost and maintenance implications, but you own the data, you can integrate it with your organization’s network if required, and typically costs less. Furthermore, using Platform as a Service (PaaS), maintained by your cloud vendor, has the benefit of both worlds; Free, open-source software, and much easier maintenance and IT handling than using virtualized infrastructure components.<\/p>\n This post will help you set up a self-hosted CTFd environment using nothing but Azure PaaS, so your CTF environment is scalable, secured, and easy to maintain, regardless of your team’s size.\nCode and deployment scripts used in the post are found in this GitHub repository<\/a>, and you are encouraged to drop a discussion or an issue or contribute.<\/p>\n Let’s start by exploring the local deployment’s docker-compose<\/a> file provided in the CTFd repository and plan its translation to Azure cloud components.<\/p>\n Four services and two networks are defined:<\/p>\n Planning the Azure deployment that will host the same functionalities using platform and networking components:<\/p>\n A simpler variation of this deployment reduces the overhead of VNet and the resources required to inject Azure PaaS components to VNet (Private endpoint and its additional networking resources):<\/p>\n Let’s define the resources using Bicep<\/a>, Azure’s domain-specific language for describing and deploying resources. Using modules<\/a> for each layer, starting with the virtual network, the CTFd application server and finally the backend services.\nThe final bicep artifact should be able to deploy all submodules so that the resources are either deployed as public PaaS services, which is a more straightforward deployment, or as PaaS services in a private VNet, which is more secure.<\/p>\n The virtual network module<\/a> defines two subnets, one hosting the private endpoints of MariaDB and Redis Cache and the second hosting the VNet integration element, which handles egress into the network from the App Service.\nVisit this page<\/a> for a reference on how App Services communicates through VNet in the same way as we’re doing here.<\/p>\n The Log Analytics module<\/a> provisions a Log Analytics workspace and outputs its workspace ID for use in the next module.<\/p>\n Next, we define the CTFd application server module<\/a>, since we require its managed identity\u2019s<\/a> Service Principal ID for the next element, Azure Key Vault. That is configured using the identity property.\nThe App Service is configured with MariaDB and Redis Cache URIs using Key Vault integration<\/a> to avoid having the secrets as part of the App Service configuration.<\/p>\n VNet integration<\/a> enables the App Service to communicate with services in a VNet and is handled if the module’s input parameter for VNet is set to true by setting the Diagnostic Settings component uses Workspace ID to configure sending the container logs to Log Analytics.<\/p>\n The Azure Key Vault module<\/a> sets up an instance of Key Vault with access policy<\/a> allowing the App Service\u2019s managed identity access to list and get the keys and secrets in the vault.\nNote that no secrets are yet in the vault, as that will be handled in later modules, and that the Key Vault instance is optionally configured to grant access only from a VNet.\nDescribing the network component for integration with VNet is done using a submodule that is described later, and by setting the This module<\/a> is used by the Key Vault, MariaDB and Redis modules to define the networking components required to integrate an Azure PaaS with a virtual network.\nFor more info on defining private endpoints with bicep, visit this guide<\/a>.<\/p>\n This module<\/a> contains resource definitions for MariaDB and uses a submodule for the networking components required to connect it to a VNet, and another submodule for handling provisioning the database secret URI into the Key Vault.\nThe module’s first parameter determines if the database will be integrated with a VNet and controls the condition for deploying the submodule and the database’s publicNetworkAccess parameter setting it to Enabled (without VNet) or Disabled (with VNet).\nNote the MariaDB unique configurations, that were set in CTFd\u2019s docker compose, and are set to the service using its configuration sub-elements.\nFinally, the module builds a connection URI that includes the administrator user\u2019s login and password and provides it to the submodule that adds key vault secrets.<\/p>\n This<\/a> simple module adds a secret to Azure Key Vault.<\/p>\n This<\/a> module is very similar too the Key Vault and MariaDB bicep definitions; we define the Redis resource, and optionally integrate it to the VNet with a submodule that defines the private endpoint as shown previously and set its The Infrastructure Setup<\/h2>\n
Docker Compose Architecture<\/h3>\n
![\"docker](\"https:\/\/devblogs.microsoft.com\/cse\/wp-content\/uploads\/sites\/55\/2023\/01\/host-ctf-on-azure-1.png\")
<\/p>\n\n
Azure Deployment Architecture<\/h3>\n
![\"azure](\"https:\/\/devblogs.microsoft.com\/cse\/wp-content\/uploads\/sites\/55\/2023\/01\/host-ctf-on-azure-10.png\")
<\/p>\n\n
![\"azure](\"https:\/\/devblogs.microsoft.com\/cse\/wp-content\/uploads\/sites\/55\/2023\/01\/host-ctf-on-azure-11.png\")
<\/p>\nAzure Infrastructure as Code<\/h2>\n
Virtual Network<\/h3>\n
![\"vnet](\"https:\/\/devblogs.microsoft.com\/cse\/wp-content\/uploads\/sites\/55\/2023\/01\/host-ctf-on-azure-2.png\")
<\/p>\nLog Analytics<\/h3>\n
![\"log](\"https:\/\/devblogs.microsoft.com\/cse\/wp-content\/uploads\/sites\/55\/2023\/01\/host-ctf-on-azure-12.png\")
<\/p>\nCTF WebApp<\/h3>\n
![\"webapp](\"https:\/\/devblogs.microsoft.com\/cse\/wp-content\/uploads\/sites\/55\/2023\/01\/host-ctf-on-azure-3.png\")
<\/p>\nvirtualNetworkSubnetId<\/code> and vnetRouteAllEnabled<\/code> accordingly.\nFinally, the CTFd docker hub image is set, and the managed identity\u2019s Service Principal ID is output from the module.<\/p>\nAzure Key Vault<\/h3>\n
![\"key](\"https:\/\/devblogs.microsoft.com\/cse\/wp-content\/uploads\/sites\/55\/2023\/01\/host-ctf-on-azure-4.png\")
<\/p>\npublicNetworkAccess<\/code> parameter to Enabled (without VNet) or Disabled (with VNet).<\/p>\nPrivate Endpoint<\/h3>\n
![\"private](\"https:\/\/devblogs.microsoft.com\/cse\/wp-content\/uploads\/sites\/55\/2023\/01\/host-ctf-on-azure-5.png\")
<\/p>\nMariaDB<\/h3>\n
![\"maria](\"https:\/\/devblogs.microsoft.com\/cse\/wp-content\/uploads\/sites\/55\/2023\/01\/host-ctf-on-azure-6.png\")
<\/p>\nKey Vault Secret<\/h3>\n
![\"secret](\"https:\/\/devblogs.microsoft.com\/cse\/wp-content\/uploads\/sites\/55\/2023\/01\/host-ctf-on-azure-9.png\")
<\/p>\nRedis<\/h3>\n
![\"redis](\"https:\/\/devblogs.microsoft.com\/cse\/wp-content\/uploads\/sites\/55\/2023\/01\/host-ctf-on-azure-7.png\")
<\/p>\npublicNetworkAccess<\/code> parameter accordingly.\nAdditionally, we add the Redis URI which contains its secret, that is retrieved using the built in function listKeys()<\/a>, to the Key Vault using the key vault secret submodule.<\/p>\nPutting it all Together<\/h3>\n
![\"deployment](\"https:\/\/devblogs.microsoft.com\/cse\/wp-content\/uploads\/sites\/55\/2023\/01\/host-ctf-on-azure-8.png\")
<\/p>\n