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:
- Documentação NOPResearcher (PRINCIPAL)
- Tutorial em vídeo: CTFd set up in AWS + nginx + CloudFlare pt. 1 AWS EC2 Ubuntu Instance
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:
- Docker: mais fácil e otimizado, porém manutenção mais complexa.
- 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.pubConecte-se à instância pelo terminal local:
ssh -i ~/.ssh/chave_ctfd usuario@IP4. 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:
- Criar conta no Mailgun e obter as credenciais (domínio, usuário e senha).
- 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 mesmoMail server port: Coloque a 587Username: Normalmente é [email protected]Password: A senha é gerada uma ÚNICA VEZ
- 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 -a9. 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.