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

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.

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) è un'abbreviazione di: I tipi di servizio TLS sono quelli supportati da per l'opzione , per il test HTTPS (incluse le intestazioni), o "" per il test TLS generico. : I test TLS vengono eseguiti a meno che la porta non sia anche contrassegnata come aperta nella chiave "".

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.

Ciò significa che le impostazioni specifiche degli host in una determinata zona hanno la priorità sulle impostazioni delle chiavi regex corrispondenti, che a loro volta hanno la precedenza sui valori predefiniti della zona, che a loro volta hanno la priorità sui valori predefiniti globali.

La chiave ports viene trattata in modo leggermente speciale: se determinate porte sono elencate da qualche parte nella catena di ereditarietà della configurazione, è impossibile rimuoverle più in basso nella catena, solo aggiungere ulteriori numeri di porta o "skip" (saltare) i test per tutte le porte di un determinato protocollo.

I file di zona vengono selezionati in base alla variabile tested_zone impostata per ciascun nodo prober.

Test per IP vs. test per nome host

Alcuni test hanno senso nel contesto di singoli indirizzi IP, indipendentemente da quanti domini/nomi host risolvono a essi; ad esempio, verificare se determinate porte sono aperte. Ad esempio, supponiamo che a.example.com e b.example.com puntino allo stesso indirizzo IP. Con la configurazione dell'esempio sopra, ciò significa che le porte 8080/tcp e 8443/tcp dovrebbero essere entrambe aperte e che HTTPS è atteso sulla porta 8443/tcp.

Alcuni test hanno senso nel contesto di combinazioni specifiche di dominio/nome host e indirizzo IP; ad esempio, se il certificato TLS presentato per un particolare nome di dominio su un particolare indirizzo IP è valido.

Questi due tipi di test sono implementati generando due elenchi separati di target:

• elenco per-ip, dove ogni elemento è della forma:
  <indirizzo-ip> <nomehost1> (<nomehost2> <nomehost3> ... <nomehostN>)
  Gli indirizzi IP non devono ripetersi in questo elenco;
• elenco per-nomehost, dove ogni elemento è della forma:
  <indirizzo-ip> <nomehost>
  Ci si può aspettare che gli indirizzi IP si ripetano in questo elenco.

Alcuni file di test vengono quindi generati solo per i target del primo elenco (ad esempio, test delle porte aperte), e alcuni solo per i target del secondo elenco (ad esempio, relativi a TLS).

Porte e test

Alcuni test non hanno senso se determinate porte non sono aperte. I test relativi a TLS vengono generati per un dato host solo se alcune porte TCP pertinenti sono configurate come open nella zona data.

Per impostazione predefinita, se una delle porte note abilitate TLS è configurata come aperta nella chiave ports.tcp, verranno generati test TLS per esse. L'elenco delle porte note abilitate TLS è definito nella variabile default_host_settings.

FAQ

In generale, la differenza tra Prober e molti altri strumenti o servizi simili di solito si riduce a una combinazione di:

• essere auto-ospitato, con nodi Prober distribuibili in qualsiasi posizione dentro o fuori la tua infrastruttura;
• concentrarsi su scansioni regolari e riproducibili che verificano ipotesi ben definite e configurabili;
• darti il controllo sulla pianificazione delle esecuzioni di test e l'accesso ai risultati grezzi delle scansioni.

In cosa differisce da Shodan?

Shodan esplora Internet per trovare sistemi esposti. Prober esplora la tua infrastruttura per verificare le tue ipotesi su di essa, da quanti punti di osservazione desideri. Si concentra sulla riproducibilità dei risultati tramite test ben definiti ed esecuzioni regolari programmate, e cerca di fornire un risultato booleano "superato/non superato" per ciascuna delle ipotesi testate (con i dati completi dei risultati della scansione disponibili per l'ispezione).

In cosa differisce da BitSight?

BitSight verifica la loro idea di ipotesi ragionevoli sulla tua infrastruttura, senza darti il controllo o informazioni su quando esattamente avverrà una scansione, né fornendo i dati grezzi della scansione. Prober verifica le tue ipotesi sulla tua infrastruttura, lo fa secondo i tuoi orari e fornisce i dati grezzi completi della scansione per l'ispezione.

In cosa differisce da Natlas?

Natlas sembra più vicino a Shodan (esplorazione per trovare host esposti, mostrando risultati in risposta a query), ma con la possibilità di auto-ospitalità (e quindi di eseguire anche l'Agente Natlas in diverse posizioni all'interno e all'esterno della tua infrastruttura, come i nodi Prober). Prober esegue scansioni regolari della tua infrastruttura per verificare le tue stesse ipotesi su di essa, come espresso nella configurazione.

Grandi domande

• passare a un sistema di test più potente?
  • BATS ha limitazioni fastidiose, ad esempio: non c'è modo di fare test condizionali ("se il test A fallisce, salta il test B", ecc.)
  • abbandonare del tutto il sistema di test?
    • https://docs.ansible.com/ansible/latest/reference_appendices/test_strategies.html
    • https://github.com/benwebber/ansible-tap
• Le scansioni di blocchi IPv6 completi sono impossibili da completare in un millennio
  • fornire un modo per configurare l'euristica di selezione degli IP da scansionare (casuale, partire dal basso con un "passo" configurato, ecc.)?

Riconoscimenti

Logo basato su Lente d'ingrandimento di verry obito, ID; CC-By e Rete di Creative Stall, PK; CC-By, tramite the Noun Project.