Sommaire
Contexte
Cet été 2023 s’est déroulé le “DevSecOps Summer Challenge”, un CTF (Capture The Flag) confectionné par WeScale teinté aux couleurs du DevOps avec des challenges autour d’AWS, Terraform, Ansible, etc.
Concevoir un CTF demande de prendre en compte de nombreux aspects, que ce soit de l’organisation, de la conception, de la sécurité ou encore de la communication !
Logo du CTF WeScale: le DevSecOps Summer Party
Vision
Le 1ᵉʳ objectif de ce CTF DevOps était à la fois d’intéresser les personnes aux pratiques DevOps mais également à la sécurité, et cela, peu importe le niveau.
Le 2ᵈ de permettre aux participants de découvrir de nombreux outils DevOps.
Pour répondre à ces objectifs, nous avons souhaité développer des challenges riches et variés, que ce soit en difficulté ou en contexte. De facto, cela nous a obligé d’adapter nos infrastructures techniques en fonction.
Organisation
Chez WeScale, les Cercles sont des groupes de centres d’intérêts dont les travaux peuvent se concrétiser par des articles, des podcasts, des conférences, etc. C’est le Cercle sécurité qui s’est chargé de concevoir le CTF. Nous étions généralement 5 personnes (les participants au Cercle n’étant pas fixes) pour produire le CTF.
L’élaboration du projet a commencé début janvier et a duré jusqu’au lancement du CTF en juin. Les travaux groupés de réflexion se sont déroulés lors de nos événements WeShare, chaque mois.
Pour information : un WeShare, c’est le 1ᵉʳ lundi de chaque mois où chaque wewe est destaffé (ne travaille pas pour son client) pour assister à une journée de conférences internes. Chacun peut proposer des sujets !
Les travaux de réalisation du CTF se sont déroulés sur du temps personnel ou du temps hors de nos missions respectives.
En tout cas, ça a bien brainstormé, on vous l’assure ! Entre les choix de plateforme CTF, de plateforme de challenges, des challenges en eux-mêmes, de nombreuses questions devaient être répondues.
Choix de la plateforme CTF
Pour héberger le CTF, nous avons fait le choix de CTFd.
Logo de CTFd
Nous n’avons pas de comparatifs à proposer, le choix fut simple : la plateforme était déjà connue par certains consultants et répondait tout à fait à notre besoin.
Pour des raisons de temps, d’argent et de sécurité, nous avons préféré prendre la version SaaS. Le coût mensuel de la plateforme est dérisoire comparé au coût d’astreinte 24/7 d’un consultant et l’hébergement/sécurisation de la plateforme.
Choix de l’infrastructure des challenges
Nous avions besoin d’héberger certains challenges. Nous avons opté pour un cluster Kapsule de Scaleway.
Nous avons fait le choix d’une infrastructure simple, résiliente et efficace :
- GitHub pour héberger nos codes IaC d’infrastructure et de challenges
- Terraform pour créer le cluster
- FluxCD pour déployer automatiquement nos challenges
- ExternalDNS pour générer automatiquement les enregistrements DNS des challenges
- Cert-manager pour générer automatiquement les certificats des challenges
- UptimeRobot pour superviser notre cluster et nous alerter en cas d’indisponibilité
- Nginx ingress-controller pour diriger nos flux entrants vers nos challenges
- Docker Hub pour héberger nos images Docker
Architecture de l'infrastructure hébergeant certains challenges CTF
Vous pouvez remarquer que la plateforme semble dénuée d’outils de sécurité, alors que nous sommes allés assez loin, proposant des sessions interactives CLI pour certains challenges. Il n’y en avait pas (ou peu), tout simplement.
La sécurité était apposée au niveau des securityContexts des pods, les flux entrants étaient restreints et nous avons appliqué une politique zero-trust sur l’ensemble des éléments (notamment les jetons).
Une infrastructure peut toujours être plus sécurisée. Dans notre contexte, ce niveau était acceptable et en adéquation avec les moyens que nous avions à disposition.
Il y avait des challenges AWS. Ceux-ci étaient positionnés sur un compte dédié, restreint en droits par des Service Control Policies et monitoré budgétairement. Chaque identifiant fournit était dûment restreint.
Le saviez-vous ?
Lorsque des identifiants AWS sont poussés sur un répertoire GitHub public, GitHub notifie AWS. En conséquence, AWS notifie le propriétaire et met une politique deny sur la clé AWS en question. Et bien, c'est ce qu’il s’est passé avec le challenge “AWSsume”, vous deviez retrouver des creds AWS dans un repository GitHub. Cette divulgation d’identifiants a automatiquement déclenché ces actions…
Maintenir la plateforme debout
Qu’est-ce que serait une infrastructure sans astreinte ?
Nous pouvions être alertés par 2 biais :
- UptimeRobot : supervise et alerte en cas d’indisponibilité du site CTF et de la plateforme d’hébergement des challenges
- Communauté : un simple mail ctf@wescale.fr mis à disposition de nos joueurs pour nous contacter en cas de problème
Les 2 nous ont servi plusieurs fois. Heureusement, nous avions une communauté active et bienveillante de joueurs !
Création des challenges
Nous nous sommes posé de nombreuses questions concernant les challenges. Nous avions des contraintes de budget, de temps et d’effort.
Comme vous le savez, nous étions une petite équipe de 5 personnes sans expérience dans la création de CTF. Nous ne pouvions pas nous permettre des travaux herculéens sous peine de ne jamais voir sortir le CTF.
Nous avons pu nous reposer sur les compétences de nos membres, chacun possédant des connaissances, des compétences, des spécialités et une certaine expérience des CTF en qualité de joueur.
Nous avons essayé de concevoir un nombre raisonnable de challenges tout en respectant nos objectifs, notamment celui de faire découvrir des outils et des contextes. Bien qu’ils auraient été super, nous avons proscrit les challenges nécessitant trop de création d’infrastructure (Vault, Consul, ArgoCD). Il nous fallait être humbles dans notre capacité à produire. Chacun a aussi mis du sien en proposant des situations dans lesquelles il s’est retrouvé : un outil ou une action nécessaire, technique ou non.
L’autre élément important de nos challenges était leur idempotence et leur sécurité !
- Pour les challenges AWS, nous avons appliqué une politique zero-trust sur nos policies.
- Pour certains challenges hébergés sur nos clusters K8S, nous avons mis en place un redémarrage toutes les 15minutes, pour régénérer le stockage local (réinitialise le stockage si un petit malin a modifié/supprimé des fichiers). Nous avons également configuré des securityContexts restreints.
- Certains challenges AWS étaient réinitialisés par des AWS Lambdas
Et bien entendu, l’ingrédient secret, le fun :)
Conclusion
Tout d’abord, merci à tous nos joueurs, nous avons pris grand plaisir à recueillir vos retours constructifs, et sommes ravis que cela vous ait plu !
Créer ex-nihilo un CTF n’est pas chose facile, cependant l’aventure fut grandiose ! Ce projet nous a beaucoup apporté sur le plan technique, c’est ce type d’événement qui rend le travail fun !
Peut-être en développerons-nous une nouvelle version avec encore plus de technologies et d’outils DevOps à découvrir !
