Verifica le ipotesi di rete in modo riproducibile

Questo progetto utilizza Ansible per generare file di test BATS che verificano le ipotesi di sicurezza sull'infrastruttura di rete. I test vengono eseguiti da macchine di probe ("nodi prober") su cui viene distribuito Prober.

Questo strumento è pensato per test automatici e riproducibili delle proprie reti. Supporta più nodi prober che eseguono test, ciascuno con una diversa visuale della rete sondata — ad esempio, una visuale dalla zona esterna, una da una zona interna, e una dall'interno della DMZ.

Usare Prober per sondare reti di cui non si è autorizzati potrebbe essere illegale.

Requisiti

Sul master Ansible utilizzato per distribuire i test sui nodi prober:

• ansible (ovvio!)
• python*-netaddr (su GNU/Linux) / py*-netaddr (su FreeBSD)

Sui nodi prober stessi:

• bash
• ssh
• nmap
• dig/kdig
• testssl
• e qualsiasi altra dipendenza installata dal ruolo Ansible.

Su un sistema in cui si esaminano i risultati (file *.tap), potrebbe essere utile installare tappy. I risultati vengono conservati su ciascun nodo prober, in repository git locali (per impostazione predefinita, in /var/run/prober/results/, vedere sotto per le opzioni di configurazione), con commit taggati con la data di completamento di ogni esecuzione di scansione, per una registrazione storica e un facile confronto.

Funzionamento

Ansible viene utilizzato per generare test sui nodi prober. Un nodo prober può essere qualsiasi host FreeBSD o GNU/Linux, purché sia possibile installare le dipendenze di Prober. Non deve essere dedicato ai test, ma è consigliato — una scansione di una rete di dimensioni ragionevoli richiederà ore, consumerà molta CPU e genererà molto traffico.

Ha senso distribuire Prober su un certo numero di macchine diverse per verificare come appare la tua rete da diversi punti di osservazione (ad esempio: rete interna, DMZ, Internet).

Nella directory dei test sui nodi prober viene creato uno script run-tests.sh per facilitare l'esecuzione dei test. I test vengono eseguiti in modo da garantire che <simultaneous_tests_count> test siano in esecuzione contemporaneamente in ogni momento — questa variabile è il modo principale per controllare quante risorse utilizza una scansione di probe e quanta larghezza di banda necessita.

I risultati dei test vengono quindi salvati in un repository git locale, con commit taggati con la data in cui una determinata esecuzione è terminata (che potrebbe essere diversa dalla data di inizio per alcune esecuzioni di probe lunghe).

Se si tratta di un'infrastruttura più grande di pochi host, potrebbe avere senso utilizzare uno strumento come Mitogen per accelerare notevolmente la generazione dei test.

Avvio rapido

1. Prepara un server Debian o FreeBSD da utilizzare come nodo prober (chiamiamolo prober.example.com), assicurati di avere accesso SSH e di poter usare sudo su di esso.

2. Copia l'inventario di esempio come inventories/test/.

3. In quell'inventario test:

   1. modifica group_vars/all.yml e imposta zone_nameserver, zone_domains, address_blocks a tuo piacimento; supponiamo che tu aggiunga example.com come unico dominio da sondare
   2. modifica il file hosts, configurando il tuo nodo prober prober.example.com nella sezione [prober-nodes]; diciamo che imposti tested_zone a test.

4. Copia la configurazione di zona di esempio come data/<tested_zone>.yml (quindi nel nostro caso: data/test.yml) e modificala; come minimo, la chiave tested_zone_settings.name deve contenere tested_zone (quindi, test).

5. Esporta la tua zona DNS e salvala come data/<dns_zone>.zone (nel nostro caso: example.com).

6. Esegui il playbook:

   ansible-playbook prober.yml -i inventories/test/ -vvv
   

   Questo genererà i test sul nodo prober e configurerà un cronjob per eseguirli ogni notte alle 01:00.

Ora puoi connetterti via ssh al nodo prober e ispezionare i test generati in /opt/prober/. Una volta soddisfatto, puoi eseguirli lanciando: /opt/prober/run_tests.sh. I risultati verranno salvati in /var/run/prober/results.

Configurazione

Variabili di configurazione (definite in probers.yml):

• tests_directory (predefinito: /opt/prober):
  directory sui nodi prober in cui vengono generati i file di test (file *.bats).

• results_repo_directory (predefinito: /var/run/prober/results) directory del repository per i risultati dei test (file *.tap); viene inizializzato un repository git e viene creata una sottodirectory tap/ per i risultati effettivi; i risultati vengono committati nel repository git, i commit sono taggati con una data nel formato yyyy-mm-dd (ad esempio, il commit con i risultati di un test terminato il 19 marzo 2020 è taggato come 2020-03-19).

• simultaneous_tests_count (predefinito: 20):
  quanti test vengono eseguiti contemporaneamente.

• prober_dev (predefinito: non definito):
  salta alcune attività che non hanno senso su una macchina di sviluppo
  (come configurare cron o zabbix).

Zone

Le zone sono definite nei file ./data/<nome_zona>.yml con la chiave principale che è la stringa "tested_zone_settings", che a sua volta contiene le chiavi:

• name: il nome della zona, che corrisponde al nome del file (senza estensione); ad esempio: "internal", "external", "dmz"
• default (opzionale): le impostazioni predefinite per tutti gli host in questa zona
• chiavi regex (che iniziano necessariamente con un carattere "^") che corrispondono a più FQDN
• chiave per ogni FQDN che necessita di configurazione esplicita

La chiave default, ciascuna chiave regex e ciascuna chiave di dominio possono a loro volta contenere queste chiavi:

• resolve: se l'host deve risolversi all'indirizzo IP corrispondente (bool true/false, o la stringa "skip")
• ping: se l'host deve rispondere al ping (bool true/false, o la stringa "skip")
• ports: elenco delle porte TCP e UDP consentite per essere aperte (sotto-chiavi "tcp" e "udp", ciascuna contenente un array di interi che definiscono le porte consentite per essere aperte, o la stringa "skip"), e porte abilitate TLS su cui fare un'ispezione più approfondita (la sotto-chiave tls, contenente un dict con i numeri di porta come chiavi e il tipo di servizio TLS o la parola "skip" come valore)
  ports: "skip" è un'abbreviazione di:

  ports:
    tcp: "skip"
    udp: "skip"
    tls: "skip"
  

  I tipi di servizio TLS sono quelli supportati da testssl.sh per l'opzione -t/--starttls, "https" per il test HTTPS (incluse le intestazioni), o "tls" per il test TLS generico.
  NOTA: I test TLS non vengono eseguiti a meno che la porta non sia anche contrassegnata come aperta nella chiave "tcp".
• skip: se l'host deve essere saltato del tutto (booleano)

Puoi vedere la configurazione di esempio qui.

I valori predefiniti globali sono definiti in probers.yml. Per ogni host sondato, questi vengono poi combinati con i valori predefiniti della zona pertinente, poi con le chiavi regex che corrispondono a un determinato nome host e infine con le impostazioni specifiche dell'host.