Vérifier les hypothèses réseau de manière reproductible

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.

Prérequis

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 :

• bash
• ssh
• nmap
• dig/kdig
• testssl
• et toutes les autres dépendances installées par le rôle Ansible.

Sur 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.

Fonctionnement

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.

Démarrage rapide

1. 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.

2. Copiez l'inventaire exemple en tant que inventories/test/.

3. Dans cet inventaire test :

   1. modifiez 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 à sonder
   2. modifiez le fichier hosts, en configurant votre nœud sondeur prober.example.com dans la section [prober-nodes] ; disons que vous définissez sur .

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.

Configuration

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.

Zones

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
• clés regex (commençant nécessairement par un caractère "^") correspondant à plusieurs FQDN
• une clé pour chaque FQDN nécessitant une configuration explicite

La 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) est une abréviation de : Les types de service TLS sont ceux supportés par pour l'option , pour un test HTTPS (y compris les en-têtes), ou "" pour un test TLS générique. : les tests TLS ne sont exécutés à moins que le port ne soit également marqué comme ouvert dans la clé "".

Vous pouvez voir un exemple de configuration ici.

Les valeurs par défaut globales sont définies dans probers.yml. Pour chaque hôte sondé, elles sont ensuite combinées avec les valeurs par défaut de la zone concernée, puis avec les clés regex correspondant à un nom d'hôte donné, et enfin avec les paramètres spécifiques de l'hôte.

Cela signifie que les paramètres d'hôtes spécifiques dans une zone donnée ont priorité sur les paramètres des clés regex correspondantes, qui à leur tour sont prioritaires sur les valeurs par défaut de la zone, qui à leur tour sont prioritaires sur les valeurs par défaut globales.

La clé ports est traitée un peu spécialement : si certains ports sont répertoriés quelque part dans la chaîne d'héritage de configuration, il est impossible de les retirer plus bas dans la chaîne, seulement d'ajouter des numéros de port supplémentaires, ou de "skip" (ignorer) les tests pour tous les ports d'un protocole donné.

Les fichiers de zone sont sélectionnés en fonction de la variable tested_zone définie pour chaque nœud sondeur.

Tests par IP vs tests par nom d'hôte

Certains tests ont du sens dans le contexte d'adresses IP individuelles, indépendamment du nombre de domaines/noms d'hôte qui y résolvent ; par exemple, vérifier si certains ports sont ouverts. Par exemple, disons que a.example.com et b.example.com pointent vers la même adresse IP. Avec la configuration de l'exemple ci-dessus, cela signifie que les ports 8080/tcp et 8443/tcp sont censés être ouverts, et que HTTPS est attendu sur le port 8443/tcp.

Certains tests ont du sens dans le contexte de combinaisons spécifiques domaine/nom d'hôte et adresse IP ; par exemple, si le certificat TLS présenté pour un nom de domaine particulier sur une adresse IP particulière est valide.

Ces deux types de tests sont implémentés en générant deux listes séparées de cibles :

• liste par IP, où chaque élément est de la forme :
  <ip-address> <hostname1> (<hostname2> <hostname3> ... <hostnameN>)
  Les adresses IP ne doivent pas se répéter dans cette liste ;
• liste par nom d'hôte, où chaque élément est de la forme :
  <ip-address> <hostname>
  On peut s'attendre à ce que les adresses IP se répètent dans cette liste.

Certains fichiers de test sont ensuite générés uniquement pour les cibles de la première liste (par exemple, les tests de ports ouverts), et d'autres uniquement pour les cibles de la seconde liste (par exemple, liés au TLS).

Ports et tests

Certains tests n'ont pas de sens si certains ports ne sont pas ouverts. Les tests liés au TLS sont générés pour un hôte donné uniquement si des ports TCP pertinents sont configurés comme open dans la zone donnée.

Par défaut, si l'un des ports TLS bien connus est configuré comme ouvert dans la clé ports.tcp, des tests TLS seront générés pour eux. La liste des ports TLS bien connus est définie dans la variable default_host_settings.

FAQ

En général, la différence entre Prober et de nombreux autres outils ou services similaires se résume généralement à une combinaison de :

• être auto-hébergé, avec des nœuds Prober déployables dans n'importe quel emplacement à l'intérieur ou à l'extérieur de votre infrastructure ;
• l'accent mis sur des scans réguliers et reproductibles qui vérifient des hypothèses bien définies et configurables ;
• vous donner le contrôle sur le calendrier des exécutions de test, et l'accès aux résultats bruts des scans.

En quoi est-ce différent de Shodan ?

Shodan parcourt Internet pour trouver des systèmes exposés. Prober parcourt votre propre infrastructure pour vérifier vos hypothèses à son sujet, depuis autant de points de vue que nécessaire. Il se concentre sur la reproductibilité des résultats via des tests bien définis et des exécutions régulières et programmées, et tente de fournir un résultat booléen "réussite/échec" pour chacune des hypothèses testées (avec les données complètes des résultats de scan disponibles pour inspection).

En quoi est-ce différent de BitSight ?

BitSight vérifie leur idée des hypothèses raisonnables sur votre infrastructure, sans vous donner le contrôle ni d'informations sur le moment exact où un scan aura lieu, ni fournir les données brutes de scan. Prober vérifie vos hypothèses sur votre infrastructure, le fait selon votre calendrier et fournit les données brutes complètes du scan pour inspection.

En quoi est-ce différent de Natlas ?

Natlas semble plus proche de Shodan (parcourir pour trouver des hôtes exposés, afficher les résultats en réponse à des requêtes), mais avec la capacité d'être auto-hébergé (et donc aussi d'exécuter l'agent Natlas dans différents endroits à l'intérieur et à l'extérieur de votre infrastructure, comme les nœuds Prober). Prober exécute des scans réguliers de votre infrastructure pour vérifier vos propres hypothèses à son sujet, telles qu'exprimées dans la configuration.

Grandes questions

• passer à un système de test plus puissant ?
  • BATS a des limitations ennuyeuses, par exemple : il n'y a aucun moyen de faire des tests conditionnels (« si le test A échoue, alors ignorer le test B », etc.)
  • abandonner complètement le système de test ?
    • https://docs.ansible.com/ansible/latest/reference_appendices/test_strategies.html
    • https://github.com/benwebber/ansible-tap
• Les scans complets de blocs IPv6 sont impossibles à terminer en un millénaire
  • fournir un moyen de configurer l'heuristique de sélection des IP à scanner (aléatoire, démarrer par le bas avec un « pas » configuré, etc.) ?

Remerciements

Logo basé sur Magnifying Glass par verry obito, ID ; CC-By et Network par Creative Stall, PK ; CC-By, via the Noun Project.