Verificar suposições de rede de forma reproduzível

Este projeto usa Ansible para gerar arquivos de teste BATS que verificam suposições de segurança sobre a infraestrutura de rede. Os testes são executados a partir de máquinas de sondagem ("nós prober") para as quais o Prober é implantado.

Esta ferramenta é destinada a testes automatizados e reproduzíveis de redes próprias. Ela suporta múltiplos nós prober executando testes, cada um com uma visão diferente da rede sondada — por exemplo, uma visão da zona externa, e de uma zona interna, e uma visão de dentro da DMZ.

Usar o Prober para sondar redes para as quais você não está autorizado pode ser ilegal.

Requisitos

No mestre Ansible usado para implantar testes nos nós prober:

• ansible (obviamente!)
• python*-netaddr (no GNU/Linux) / py*-netaddr (no FreeBSD)

Nos próprios nós prober:

• bash
• ssh
• nmap
• dig/kdig
• testssl
• e quaisquer outras dependências que são instaladas pela role do Ansible.

Em um sistema onde você está revisando os resultados (arquivos *.tap), talvez queira instalar o tappy. Os resultados são mantidos em cada nó prober, em repositórios git locais (por padrão, em /var/run/prober/results/, veja abaixo as opções de configuração), com commits marcados com a data de cada execução de varredura concluída, para registro histórico e fácil comparação.

Operação

Ansible é usado para gerar testes nos nós prober. Um nó prober pode ser qualquer host FreeBSD ou GNU/Linux, desde que seja possível instalar as dependências do Prober. Não precisa ser dedicado a testes, mas é recomendado — uma varredura de uma rede de tamanho razoável levará horas, usará muita CPU e gerará bastante tráfego.

Faz sentido implantar o Prober em várias máquinas diferentes para verificar como sua rede se parece de diferentes pontos de vista (por exemplo: rede interna, DMZ, a Internet).

No diretório de teste nos nós prober, um script run-tests.sh é criado para facilitar a execução dos testes. Os testes são executados de forma a garantir que <simultaneous_tests_count> testes estejam sendo executados simultaneamente o tempo todo — esta variável é a principal forma de controlar quantos recursos uma varredura de sondagem usa e quanta largura de banda ela precisa.

Os resultados dos testes são então salvos em um repositório git local, com commits marcados com a data em que uma determinada execução terminou (que pode ser diferente da data de início para algumas execuções de sondagem longas).

Se estiver lidando com uma infraestrutura maior do que apenas alguns hosts, pode fazer sentido usar uma ferramenta como Mitogen para acelerar drasticamente a geração de testes.

Início rápido

1. Prepare um servidor Debian ou FreeBSD para uso como nó prober (vamos chamá-lo de prober.example.com), certifique-se de ter acesso SSH a ele e poder usar sudo nele.

2. Copie o inventário de exemplo como inventories/test/.

3. Nesse inventário test:

   1. edite group_vars/all.yml e defina zone_nameserver, zone_domains, address_blocks conforme sua preferência; vamos supor que você adicione example.com como o único domínio a ser sondado
   2. edite o arquivo hosts, configurando seu nó prober prober.example.com na seção [prober-nodes]; digamos que você defina o como .

Agora você pode usar ssh para acessar o nó prober e inspecionar os testes gerados em /opt/prober/. Depois de satisfeito, pode executá-los com: /opt/prober/run_tests.sh. Os resultados serão salvos em /var/run/prober/results.

Configuração

Variáveis de configuração (definidas em probers.yml):

• tests_directory (padrão: /opt/prober):
  diretório nos nós prober onde os arquivos de teste (arquivos *.bats) são gerados.

• results_repo_directory (padrão: /var/run/prober/results) diretório do repositório para resultados de testes (arquivos *.tap); um repositório git é inicializado lá e um subdiretório tap/ é criado para os resultados reais; os resultados são confirmados no repositório git, os commits são marcados com uma data no formato yyyy-mm-dd (o commit com resultados de um teste que terminou em 19 de março de 2020 é marcado como 2020-03-19, por exemplo).

• simultaneous_tests_count (padrão: 20):
  quantos testes são executados simultaneamente.

Zonas

As zonas são definidas em arquivos ./data/<zone_name>.yml com a chave principal sendo a string "tested_zone_settings", que contém as chaves:

• name: o nome da zona, correspondendo ao nome do arquivo (sem extensão); por exemplo: "internal", "external", "dmz"
• default (opcional): as configurações padrão para todos os hosts nesta zona
• chaves de regex (necessariamente começando com um caractere "^") correspondendo a múltiplos FQDNs
• chave para cada FQDN que precisa de configuração explícita

A chave default, cada chave de regex e cada chave de domínio por sua vez podem conter estas chaves:

• resolve: se o host deve resolver para o endereço IP relevante (booleano true/false, ou a string "skip")
• ping: se o host deve responder ao ping (booleano true/false, ou a string "skip")
• ports: lista de portas TCP e UDP permitidas para estar abertas (sub-chaves "tcp" e "udp", cada uma contendo um array de inteiros definindo portas permitidas para estar abertas, ou a string "skip"), e portas habilitadas para TLS para inspeção mais profunda (a sub-chave tls, contendo um dicionário com números de porta como chaves, e o tipo de serviço TLS ou a palavra "skip" como valor) é uma abreviação de: Os tipos de serviço TLS são os que o suporta para a opção , para teste HTTPS (incluindo cabeçalhos), ou "" para teste TLS genérico. : Testes TLS são executados a menos que a porta também esteja marcada como aberta na chave "".

Você pode ver a configuração de exemplo aqui.

Os padrões globais são definidos em probers.yml. Para cada host sondado, estes são então combinados com os padrões de zona relevantes, depois com chaves de regex que correspondem a um determinado hostname, e finalmente com as configurações específicas do host.

Isso significa que as configurações específicas de hosts em uma determinada zona têm prioridade sobre as configurações de chaves correspondidas por regex, que por sua vez têm precedência sobre os padrões de zona, que por sua vez têm prioridade sobre os padrões globais.

A chave ports é tratada de forma um pouco especial: se certas portas estão listadas em algum lugar na cadeia de herança de configuração, é impossível removê-las mais abaixo na cadeia, apenas adicionar números de porta adicionais, ou "skip" testes para todas as portas de um determinado protocolo por completo.

Os arquivos de zona são selecionados com base na variável tested_zone definida para cada nó prober.

Testes por IP vs. testes por hostname

Alguns testes fazem sentido no contexto de endereços IP individuais, independentemente de quantos domínios/hostnames resolvem para eles; por exemplo, verificar se certas portas estão abertas. Por exemplo, digamos que a.example.com e b.example.com apontam para o mesmo endereço IP. Com a configuração do exemplo acima, isso significa que as portas 8080/tcp e 8443/tcp devem estar abertas, e que HTTPS é esperado na porta 8443/tcp.

Alguns testes fazem sentido no contexto de combinações específicas de domínio/hostname e endereço IP; por exemplo, se o certificado TLS apresentado para um nome de domínio específico em um endereço IP específico é válido.

Esses dois tipos de testes são implementados gerando duas listas separadas de alvos:

• lista por IP, onde cada elemento tem a forma:
  <ip-address> <hostname1> (<hostname2> <hostname3> ... <hostnameN>)
  Endereços IP não devem se repetir nesta lista;
• lista por hostname, onde cada elemento tem a forma:
  <ip-address> <hostname>
  Endereços IP podem se repetir nesta lista.

Alguns arquivos de teste são então gerados apenas para alvos da primeira lista (por exemplo, teste de portas abertas), e alguns apenas para alvos da segunda lista (por exemplo, relacionados a TLS).

Portas e testes

Alguns testes não fazem sentido se certas portas não estiverem abertas. Testes relacionados a TLS são gerados para um determinado host apenas se alguma porta TCP relevante estiver configurada como open na zona em questão.

Por padrão, se alguma das portas conhecidas habilitadas para TLS estiver configurada como aberta na chave ports.tcp, testes TLS serão gerados para elas. A lista de portas conhecidas habilitadas para TLS está definida na variável default_host_settings.

FAQ

Em geral, a diferença entre Prober e muitas outras ferramentas ou serviços similares geralmente se resume a alguma combinação de:

• ser auto-hospedado, com nós Prober implantáveis em qualquer local dentro ou fora da sua infraestrutura;
• foco em varreduras regulares e reproduzíveis que verificam suposições bem definidas e configuráveis;
• dar a você controle sobre o cronograma das execuções de teste e acesso aos resultados brutos da varredura.

Como isso é diferente do Shodan?

O Shodan varre a Internet para encontrar sistemas expostos. O Prober varre sua própria infraestrutura para verificar suas suposições sobre ela, a partir de quantos pontos de vista você precisar. Ele foca na reprodutibilidade dos resultados por meio de testes bem definidos e execuções regulares e agendadas, e tenta fornecer um resultado booleano "passa/falha" para cada uma das suposições testadas (com os dados completos do resultado da varredura disponíveis para inspeção).

Como isso é diferente do BitSight?

O BitSight verifica a ideia deles de suposições razoáveis sobre sua infraestrutura, sem dar a você controle ou informações sobre quando exatamente uma varredura ocorrerá, nem fornecer os dados brutos da varredura. O Prober verifica suas suposições sobre sua infraestrutura, faz isso no seu cronograma e fornece dados brutos completos da varredura para inspeção.

Como isso é diferente do Natlas?

O Natlas parece ser mais próximo do Shodan (varrendo para encontrar hosts expostos, mostrando resultados em resposta a consultas), mas com a capacidade de auto-hospedagem (e, assim, também executar o Agente Natlas em diferentes locais dentro e fora da sua infraestrutura, como nós Prober). O Prober executa varreduras regulares da sua infraestrutura para verificar suas próprias suposições sobre ela, conforme expresso na configuração.

Grandes questões

• mudar para um sistema de teste mais poderoso?
  • BATS tem limitações irritantes, por exemplo: não há como fazer testes condicionais ("se o Teste A falhar, pule o Teste B", etc)
  • abandonar o sistema de teste completamente?
    • https://docs.ansible.com/ansible/latest/reference_appendices/test_strategies.html
    • https://github.com/benwebber/ansible-tap
• Varreduras completas de bloco IPv6 são impossíveis de concluir em um milênio
  • fornecer uma maneira de configurar a heurística de seleção de IPs para varredura (aleatório, começar de baixo com um "passo" configurado, etc)?

Agradecimentos

Logotipo baseado em Magnifying Glass por verry obito, ID; CC-By e Network por Creative Stall, PK; CC-By, via the Noun Project.