isnic/proberCadre de test de sécurité réseau automatisé et reproductible utilisant Ansible et BATS pour vérifier le DNS, la disponibilité des hôtes, les ports ouverts et la configuration TLS depuis plusieurs points de vue.
Ce projet utilise Ansible pour générer des fichiers de test BATS vérifiant les hypothèses de sécurité concernant l'infrastructure réseau. Les tests sont exécutés à partir de machines sonde (« nœuds sondeurs ») sur lesquelles Prober est déployé.
Cet outil est destiné aux tests automatisés et reproductibles de vos propres réseaux. Il prend en charge plusieurs nœuds sondeurs exécutant des tests, chacun ayant une vue différente du réseau sondé — par exemple, une vue depuis la zone externe, une vue depuis une zone interne, et une vue depuis l'intérieur de la DMZ.
Utiliser Prober pour sonder des réseaux pour lesquels vous n'êtes pas autorisé pourrait être illégal.
Sur le maître Ansible utilisé pour déployer les tests vers les nœuds sondeurs :
ansible (évidemment !)python*-netaddr (sur GNU/Linux) / py*-netaddr (sur FreeBSD)Sur les nœuds sondeurs eux-mêmes :
bashsshnmapdig/kdigtestsslSur un système où vous examinez les résultats (fichiers *.tap), vous pouvez installer tappy. Les résultats sont conservés sur chaque nœud sondeur, dans des dépôts git locaux (par défaut, dans /var/run/prober/results/, voir ci-dessous pour les options de configuration), avec des commits étiquetés avec la date de fin de chaque exécution de scan, pour un historique et une comparaison faciles.
Ansible est utilisé pour générer des tests vers les nœuds sondeurs. Un nœud sondeur peut être n'importe quel hôte FreeBSD ou GNU/Linux, à condition qu'il soit possible d'installer les dépendances de Prober. Il n'a pas besoin d'être dédié aux tests, mais c'est recommandé — un scan d'un réseau de taille raisonnable prendra des heures, utilisera beaucoup de CPU et générera pas mal de trafic.
Il est logique de déployer Prober sur plusieurs machines différentes pour vérifier l'apparence de votre réseau depuis différents points de vue (par exemple : réseau interne, DMZ, Internet).
Dans le répertoire de test sur les nœuds sondeurs, un script run-tests.sh est créé pour faciliter l'exécution des tests. Les tests sont exécutés de manière à garantir que <simultaneous_tests_count> tests s'exécutent simultanément en permanence — cette variable est le principal moyen de contrôler les ressources utilisées par un scan de sondage et la bande passante nécessaire.
Les résultats des tests sont ensuite sauvegardés dans un dépôt git local, avec des commits étiquetés avec la date à laquelle une exécution donnée s'est terminée (qui peut être différente de la date de début pour certains longs scans de sondage).
Si vous gérez une infrastructure plus grande que quelques hôtes, il peut être judicieux d'utiliser un outil comme Mitogen pour accélérer considérablement la génération des tests.
Préparez un serveur Debian ou FreeBSD pour l'utiliser comme nœud sondeur (appelons-le prober.example.com), assurez-vous d'avoir un accès SSH et de pouvoir sudo dessus.
Copiez l'inventaire exemple en tant que inventories/test/.
Dans cet inventaire test :
group_vars/all.yml et définissez zone_nameserver, zone_domains, address_blocks selon vos besoins ; supposons que vous ajoutiez example.com comme seul domaine à sonderhosts, en configurant votre nœud sondeur prober.example.com dans la section [prober-nodes] ; disons que vous définissez tested_zone sur test.Copiez la configuration de zone exemple en tant que data/<tested_zone>.yml (donc dans notre cas : data/test.yml) et modifiez-la ; au minimum, la clé tested_zone_settings.name doit contenir la tested_zone (donc test).
Exportez votre zone DNS et sauvegardez-la sous data/<dns_zone>.zone (dans notre cas : example.com).
Exécutez le playbook :
ansible-playbook prober.yml -i inventories/test/ -vvv
Cela générera les tests sur le nœud sondeur et configurera une tâche cron pour les exécuter chaque nuit à 01h00.
Vous pouvez maintenant vous connecter en ssh au nœud sondeur et inspecter les tests générés dans /opt/prober/. Une fois satisfait, vous pouvez les exécuter avec : /opt/prober/run_tests.sh. Les résultats seront sauvegardés dans /var/run/prober/results.
Variables de configuration (définies dans probers.yml) :
tests_directory (par défaut : /opt/prober) :
répertoire sur les nœuds sondeurs où les fichiers de test (fichiers *.bats) sont générés.
results_repo_directory (par défaut : /var/run/prober/results) :
répertoire du dépôt pour les résultats des tests (fichiers *.tap) ; un dépôt git est
initialisé là et un sous-répertoire tap/ est créé pour les résultats réels ;
les résultats sont commités dans le dépôt git, les commits sont étiquetés avec une date
au format aaaa-mm-jj (le commit contenant les résultats d'un test qui s'est terminé le 19 mars 2020
est étiqueté 2020-03-19, par exemple).
simultaneous_tests_count (par défaut : 20) :
nombre de tests exécutés simultanément.
prober_dev (par défaut : non défini) :
ignorer certaines tâches qui n'ont pas de sens sur une machine de développement
(comme configurer cron ou zabbix).
Les zones sont définies dans les fichiers ./data/<zone_name>.yml avec la clé racine étant la chaîne "tested_zone_settings", qui contient ensuite les clés :
name : le nom de la zone, correspondant au nom de fichier (sans extension) ; par exemple : "internal", "external", "dmz"default (optionnel) : les paramètres par défaut pour tous les hôtes de cette zone^") correspondant à plusieurs FQDNLa clé default, chaque clé regex et chaque clé de domaine peuvent à leur tour contenir ces clés :
resolve : l'hôte doit-il résoudre l'adresse IP correspondante (booléen true/false, ou la chaîne "skip")ping : l'hôte doit-il répondre au ping (booléen true/false, ou la chaîne "skip")ports : liste des ports TCP et UDP autorisés à être ouverts (sous-clés "tcp" et "udp", contenant chacune un tableau d'entiers définissant les ports autorisés à être ouverts, ou la chaîne "skip"), et ports TLS activés pour une inspection plus approfondie (la sous-clé tls, contenant un dictionnaire avec les numéros de port comme clés, et le type de service TLS ou le mot "skip" comme valeur)ports: "skip" est une abréviation de :
ports:
tcp: "skip"
udp: "skip"
tls: "skip"
testssl.sh pour l'option -t/--starttls, "https" pour un test HTTPS (y compris les en-têtes), ou "tls" pour un test TLS générique.tcp".skip : si l'hôte doit être complètement ignoré (booléen)Vous pouvez voir un exemple de configuration ici.