1. Visão Geral

A plataforma Green Team Hacker Club CTF foi criada para:

  • Reduzir a dependência de plataformas externas (picoCTF, TryHackMe, HackTheBox etc.), pois:

    • Considere-se que essas plataformas (menos o picoCTF) geram custos para ter acesso total
    • Plataformas muito conhecidas existem diversos Write-ups públicos que podem comprometer o aprendizado. Vale lembrar que os Write-ups são essenciais para os estudos em hacking.
  • Promover eventos internos entre membros e servir como parte do processo seletivo da entidade.

  • Estimular o engajamento da comunidade com a criação contínua de CTFs.

  • Integrar diferentes frentes do GTHC:

    • Web: suporte no desenvolvimento de desafios de Web com frontend.
    • Dados: fornecimento de amostras reais para desafios de SQL/Oracle.
    • Low Level: colaboração em engenharia reversa e pwn (exploração binária).
  • Organizar eventos para a comunidade universitária, tanto interna (na UFABC) quanto externa.

  • Aprimorar conhecimentos em DevOps, criação de desafios de segurança e entre outros.

  • Aumentar visibilidade e reputação do GTHC na comunidade de segurança.

2. Hospedagem e Deploy (com e2-small)

A plataforma está hospedada no Google Cloud Platform (GCP), seguindo os passos de:

Observação: Parte da configuração inicial na instância e do serviço de e-mails seguiu o vídeo Configuração no GCP & Mailgun.

Atualmente, existem duas formas de rodar o CTFd localmente:

  1. Docker: mais fácil e otimizado, porém manutenção mais complexa.
  2. Deploy em Python: configuração inicial mais detalhada, mas manutenção simplificada.

Como o tráfego esperado não é elevado na maior parte do tempo, optou-se pelo deploy em Python sem Docker.

Recomendo fortemente consultar também a documentação do CTFd: Documentação CTFd

Observação: Adicionalmente, foi criado manualmente também um servidor MySQL e Redis para o CTFd. Estou comentando isso porque os vídeos/documentção não citam essa parte. O MySQL era essencial porque funções de backup do CTFd precisam NECESSARIAMENTE dele. Além do mais, para ter acesso as senhas do usuário CTFd e root contatar um administrador da infraestrutura.

3. Acesso à Instância via SSH com Chave Pública/Privada (acredito ser mais conveniente)

Recomenda-se gerar um par de chaves usando ssh-keygen:

# Gerar par de chaves (2048 bits)
ssh-keygen -t rsa -b 2048 -f ~/.ssh/chave_ctfd
 
# Instalar a chave pública no GCP (Compute Engine > Metadados > Chaves SSH)
# A chave pública estará em ~/.ssh/chave_ctfd.pub

Conecte-se à instância pelo terminal local:

ssh -i ~/.ssh/chave_ctfd usuario@IP

4. Configuração do NGINX

  • O NGINX foi instalado como proxy reverso e balanceador de carga (mesmo rodando em um único servidor), garantindo:

    • Encaminhamento de requisições HTTP/HTTPS ao CTFd.
    • Possibilidade de expansão futura para múltiplas instâncias.

Em caso de criação de CTF web, pode adicionar a nova rota como subdomínio que deseja através do NGINX. Um exemplo de configuração será adicionada mais pra frente na documentação.

5. Domínio

  • Registrado no Registro.br, validade de 2 anos (expira em abril/2027).
  • Configuração: apontamento de A record para o IP público da instância. (Essa config o próprio Google fornece pra gente, basta copiar e colar)

6. Configuração de E-mails

Para recursos de verificação de e-mail e recuperação de senha, utilizamos Mailgun:

  1. Criar conta no Mailgun e obter as credenciais (domínio, usuário e senha).
  2. Inserir as variáveis de ambiente no CTFd:
    • Mail from address: E-mail que enviará mensagens para o usuário (que seja do seu domínio)
    • Mail server address: Sempre é o mesmo
    • Mail server port: Coloque a 587
    • Username: Normalmente é [email protected]
    • Password: A senha é gerada uma ÚNICA VEZ
  3. Adicionar registro TXT no Registro.br para validação de domínio e SPF/DKIM.

7. Implementação do SSL/TLS

Parte bem easy.

Basta seguir essa documentação de alguns passos: Documentação CertBot com NGINX + Ubuntu

8. Comandos úteis

# Restart no NGINX (caso você mude alguma configuração)
sudo systemctl restart nginx
 
# Restart no CTFd
sudo systemctl restart ctfd
 
# Acompanhar em tempo real os logs do CTFd
tail -f /var/log/CTFd/CTFd/logs/access.log
tail -f /var/log/CTFd/CTFd/logs/error.log
 
# Listagem dos containers rodando na máquina
sudo docker ps -a

9. Possíveis Melhorias

  • Implementar CI/CD com Terraform e Kubernetes (“Nossa, mas por quê?” O fato de implementar uma infraestrutura IaaC, nos da a liberdade de financeirização com a plataforma de CTF para outras universidades, empresas privadas, instituições, pois, a qualquer momento conseguiremos subir uma infraestrutura completa em pouco minutos, tanto AWS, GCP, Azure e etc. Obviamente teríamos que ter um grau de maturidade muito grande para isso acontecer.)
  • Criar um arquivo de automatização como centralizador de gerenciamento dos nossos CTFs, como restart, health checker, disable e etc.
  • Se a demanda da plataforma aumentar, podemos dar um upgrade na instância de e2-small para e2-medium.
  • Criar CTFs por meio de Kubernetes (ou no GCP com o GKE). Dessa forma, fazemos com que os CTFs sejam inicializados por demanda e únicos para cada usuário. Além de conseguir fazer flags dinâmicas. Existem plugins do CTFd que fazem isso, como CTFd Whale, Chall-Manager e etc, entretanto, como o nosso tráfego não é muito alto e a plataforma é para dezenas pessoas, acaba que não é prioridade máxima construir pools com o docker.