nccgroup/cowcloudSolution 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_timeextra_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). |
À 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.