
Solution AWS serverless pour répartir les charges de travail de reconnaissance et d'analyse de vulnérabilités. Soumettez les tâches via l'interface web ; les workers EC2 exécutent des scripts Python personnalisés avec des outils comme Nmap.
CowCloud a été créé à l'origine pour exécuter des outils de reconnaissance et des scans de vulnérabilités de manière distribuée ; par exemple, un cas d'usage pourrait être celui des chasseurs de bug bounty. Cette solution vise à abstraire les utilisateurs finaux du travail sous-jacent nécessaire pour distribuer des charges de travail dans AWS. CowCloud fournit aux utilisateurs une interface web conviviale pour visualiser et créer de nouvelles tâches qui sont ensuite consommées par le code Python s'exécutant sur les nœuds de travail (instances EC2). Il est prévu que le code Python ainsi que les AMI EC2 soient personnalisés.
À titre d'exemple, disons que vous souhaitez exécuter des scans Nmap. Dans ce cas, vous pouvez simplement choisir une AMI dans le catalogue d'AMI et mettre à jour le champ image_id dans Terraform/ec2_module/ec2_module.tf. Ensuite, le fichier ec2py/template.py devra être mis à jour pour personnaliser les arguments du scan Nmap (-Pn, -p 443, etc.). Enfin, le champ user_data dans le fichier de configuration Terraform/ec2_module/ec2_module.tf devra être mis à jour pour installer Nmap et ses dépendances.
Une autre option consiste à installer et exécuter plusieurs outils commerciaux ; dans ce cas, vous voudrez peut-être créer votre propre instance EC2 ou snapshot. Dans ce cas, vous installerez toutes les dépendances et activerez les licences afin de pouvoir utiliser cette AMI comme image de référence (gold image) pour vos nœuds de travail.

CowCloud peut être décomposé en trois composants principaux :
Voici les fonctionnalités clés :
autoscalingStrategy.py)retention_time
À la suite de l'exécution de Terraform, un nouveau fichier est créé (config.js) ; celui-ci contient la configuration requise pour que l'application React JS s'authentifie auprès du répertoire du user pool Cognito. Une fois l'infrastructure déployée, vous devez compiler l'application React et téléverser le dossier build. De plus, vous devez téléverser le code Python dans un bucket S3 qui agit comme référentiel de code. Ce processus est automatisé dans deux scripts setup.bat et setup.sh afin que vous n'ayez pas à vous en soucier ; ceci est uniquement pour résumer cette étape.
L'infrastructure est déployée dans la région us-east-1 par défaut, bien que cela puisse être modifié dans le fichier locals.tf au sein du dossier Terraform.
Étapes :
variables.tf ; la variable ami doit pointer vers une AMI EC2 existante, qui peut être votre AMI dorée ou une AMI du catalogue EC2aws configure. Vérifiez que la configuration est correcte en exécutant cette commande : aws sts get-caller-identity ; lorsqu'elle est correctement configurée, cette commande ne doit pas renvoyer d'erreuraws ec2 create-key-pair –key-name cowCloud –query “cowCloud” –output text > ec2_module/cowCloud.pemgit clone [email protected]:nccgroup/cowcloud.git
# Deploy the infra
cd cowcloud
cd Terraform
terraform init
terraform plan
terraform apply --auto-approve
Vous êtes maintenant prêt ! Inscrivez-vous, connectez-vous et créez une nouvelle tâche !
Une fois que tout est déployé et que le front-end est accessible, vous devez suivre ces étapes :
CowCloud\ec2py> python .\decypt_file.py 2e8cf87c-5389-11ec-abec-d6d1f378b18d
La personne chargée de déployer l'infrastructure et de la maintenir doit correctement assainir et valider les entrées des utilisateurs finaux fournies via l'application web. En d'autres termes, il faut s'assurer que le code dans ec2py/template.py n'est pas vulnérable à l'injection de commandes OS.
Ce point est souligné car c'est l'aspect le plus critique du système. Un soin particulier a été apporté pour limiter le périmètre des permissions et l'exposition des nœuds de travail, réduisant ainsi les risques associés. Néanmoins, il incombe à l'administrateur de prendre en charge cet aspect de la sécurité du système.
Les politiques de rôle attachées au profil des instances EC2 sont répertoriées dans le fichier readme.md à l'intérieur du dossier Terraform
workers_manager.py qui est appelée par l'outil ec2py pour effectuer des actions plus privilégiées. Ces actions ont été déplacées vers une fonction Lambda afin de limiter le risque en cas de compromission de la clé d'accès du rôle attaché au profil EC2. Elle fonctionne néanmoins avec IMDSv2.
Les politiques de rôle attachées à la fonction Lambda workers_manager.py sont répertoriées dans le fichier readme.md à l'intérieur du dossier TerraformSi vous souhaitez capturer la sortie standard (stdout) et l'afficher via l'interface web pendant l'exécution de la tâche, allez dans ec2py/template.py et suivez ces étapes :
extra_docker_params contient les informations requises pour que vos conteneurs Docker envoient la sortie standard aux groupes de journaux CloudWatch. Vous devrez inclure cette variable dans la ligne de commande lorsque vous voulez voir la sortie standard via le front-end.cmd = f"docker run {extra_docker_params} --rm -v {tmp_folder}target.txt:/root/Tools/reconftw/target.txt -v {tmp_folder}reconftw.cfg:/root/Tools/reconftw/reconftw.cfg -v {tmp_folder}Recon/:/root/Tools/reconftw/Recon/ six2dez/reconftw:main -l target.txt -w".split(' ')
Vous pouvez détruire l'infrastructure en exécutant cette simple commande : terraform destroy --auto-approve. Cela supprimera toutes les ressources existantes.
Remarque : n'interrompez pas ce processus, car cela pourrait laisser certains éléments dans le cloud que vous devriez ensuite identifier et supprimer manuellement.


terraform destroy --auto-approve -target module.gateway_module.aws_api_gateway_deployment.lambdaterraform apply --auto-approve -target module.gateway_moduleextra_docker_params dans le fichier template.py (ceci est expliqué dans la section Administrateur/mainteneur ci-dessous)| variable | valeur par défaut | description |
|---|
eipenable | false | Si la valeur est true, la solution alloue un pool d'adresses IP élastiques associées aux nœuds de travail lors de leur création. Le nombre d'EIP à réserver est calculé à l'aide de la formule sum([var.max_workers, var.maximum_number_of_terminating_machines]) |
cidr_whitelist | [] | La liste blanche CIDR pour autoriser uniquement certaines plages d'adresses IP dans le pare-feu. Par ex. ["195.95.131.0/24"] |
max_workers et max_queued_tasks_per_worker | max_workers: 3, max_queued_tasks_per_worker: 10 | Ces deux paramètres déterminent quand réduire (scale in) ou étendre (scale out) la capacité, par ex. max_workers 3, max_queued_tasks_per_worker 10. Cela signifie que si le nombre de tâches dépasse dix, une nouvelle instance EC2 sera créée. S'il y a plus de vingt tâches, un maximum de trois instances EC2 sera disponible pour distribuer les charges de travail (consultez l'algorithme dans le script Terraform/dynamodb_module/autoscalingTool/autoscalingStrategy.py). |
maximum_number_of_terminating_machines | 2 | Ceci définit le nombre d'instances qui sont marquées pour être terminées mais qui sont en attente jusqu'à ce que le processus/scan termine la tâche. |
heartbeat_timeout | 900 | Ceci définit le temps pendant lequel ces nœuds de travail sont en attente. Une fois ce temps écoulé, le nœud de travail sera terminé de force. |
instance_type | t2.micro | https://aws.amazon.com/ec2/instance-types/ |
ami | null | https://aws.amazon.com/es/amazon-linux-ami/ |
retention_time | 7 | Définit la durée de conservation (en jours) des journaux et l'expiration des éléments de la table d'archive (tâches terminées). |