Olá, estudante, seja bem-vindo ao curso de Pentest (teste de invasão) de Infraestrutura.
Me chamo Rafael Raugi Machado, tenho 30 anos e serei o instrutor de vocês durante todo o curso.
Audiodescrição: Rafael é uma pessoa de pele clara, 30 anos, cabelos escuros e olhos castanhos.
Uma breve apresentação: atualmente, atuo como analista de segurança sênior em equipe de Red Team (equipe vermelha) e Pentest (teste de invasão).
Tenho especialidade em Pentest (teste de invasão) de Infraestrutura, Active Directory (Diretório Ativo) e Web Exploitation (exploração web).
Algumas certificações que possuo são: OSWE (Offensive Security Web Expert), eCPPT (eLearnSecurity Certified Professional Penetration Tester) e DCPT (Desec Certified Penetration Tester) da empresa Desec Security.
Caso tenha interesse, pode entrar em contato diretamente comigo pelo meu perfil no LinkedIn (LinkedIn).
Neste curso, vamos detalhar o que aprenderemos e como aprenderemos.
O curso está organizado em aulas que abordam:
Durante o curso, seguiremos uma metodologia que enfatiza conceitos, com ênfase na prática, o uso de ferramentas adotadas atualmente pelo mercado e uma visão sobre a análise de segurança ofensiva no mercado.
Nosso objetivo é concluir este curso em condições de atuar como analistas de segurança ofensiva em pentestes de infraestrutura.
Pessoal, tudo bem?
Rafael aqui mais uma vez, dando continuidade ao nosso curso de Pentest (teste de intrusão) de Infraestrutura.
Iremos iniciar hoje o nosso primeiro assunto: mapeamento de redes corporativas.
Na nossa primeira aula, o tema será descoberta e identificação de ativos.
Um ponto importante antes de iniciarmos: durante o teste de intrusão interno, toda atividade de varredura deve ser previamente autorizada. O inventário gerado nesta aula é a base para todas as etapas seguintes do Pentest (teste de intrusão). Portanto, esta aula é muito importante. Execute essas técnicas apenas em ambientes autorizados de laboratório ou com o escopo formal aprovado. Essa orientação é essencial.
Temos sempre em mente que todos os atos de uma pessoa Pentester (profissional de testes de intrusão) em uma ação de Pentest (teste de intrusão) de Infraestrutura devem estar devidamente autorizados e previstos em contrato. Qualquer ação não autorizada pode trazer problemas para a pessoa Pentester (profissional de testes de intrusão). Assim, é fundamental que todas as nossas ações estejam sempre previstas e autorizadas em contrato.
Para o nosso ambiente de aula, considerando a questão de autorização, estaremos utilizando um repositório do GitHub. Podemos acessá-lo posteriormente. O repositório é "lab_Pentest_Infraestrutura". Esse laboratório foi montado especificamente para o nosso curso de Pentest (teste de intrusão) de Infraestrutura. Com ele, faremos toda a parte prática.
Nós apenas copiamos o endereço e executamos o comando git clone. Podemos até dar um overview (visão geral) sobre o conteúdo. Depois, executamos git clone com a URL do repositório. Teremos uma imagem pronta para uso. Podemos, claro, analisar toda a documentação e ler com calma para entender o que vamos realizar. O script automatiza os laboratórios com Docker. Para quem já tem mais facilidade com Docker, vale conferir a documentação.
Um ponto importante, antes de simplesmente clonar e executar, é preparar a nossa máquina virtual. No meu ambiente de estudo, você pode ter algo similar; não precisa ser exatamente o mesmo. Nós nos adaptamos de acordo com os meios disponíveis. Neste ambiente, estou utilizando o virtualizador VMware Workstation 17. Antigamente, o VMware era pago; hoje já é gratuito. Conseguimos obter o instalador .exe para uso corporativo. Isso não impede que utilizemos o VirtualBox, ou até um Manjaro Linux, um Debian, ou o próprio Kali Linux nativamente na máquina.
Para quem tem um hardware (equipamento) mais antigo — por exemplo, um notebook (laptop) de 10 a 12 anos — é possível executar o laboratório. Nesse caso, é interessante utilizar o sistema operacional nativo da máquina.
Esta máquina virtual, em específico, consegue subir o laboratório como um todo. Primeiro, concedemos permissão de execução ao laboratório com chmod +x lab.sh. Em seguida, ao executar ./lab.sh status... na verdade, primeiro executamos apenas ./lab.sh para verificar como o laboratório funciona. Assim, visualizamos as opções e argumentos disponíveis.
Para isso, executamos o seguinte comando para conceder permissão de execução ao script do laboratório:
chmod +x lab.sh
Na sequência, rodamos o script sem argumentos para visualizar as opções e ajuda:
./lab.sh
Por fim, podemos consultar o status atual do laboratório para confirmar o que está em execução:
./lab.sh status
Temos algumas opções:
labup: sobe a aula, o alvo específico ou o ambiente como um todo. Ao executar labup sem filtros, praticamente todos os hosts (máquinas) e contêineres Docker sobem.labdown: com labdown, por exemplo labdown **Aula 1** ou labdown **Aula 2**, tudo é derrubado conforme o escopo indicado.status: serve para avaliarmos se já está tudo pronto. Como executamos um labup, todas as aulas ficam em execução.net: recria a rede quando há algum problema de comunicação ou alguma máquina não funciona.clean: além de derrubar o Docker, remove os recursos quando não vamos mais utilizar. Isso é importante para quem estiver utilizando máquinas virtuais com menos recursos.No meu caso de estudo, em VM > Settings (especificamente no VMware), verifico que a minha máquina virtual está com 4 vCPUs (4 cores) e 8 GB de RAM. Essa configuração consegue executar todo o laboratório sem problemas. Se, durante os estudos, a resposta ficar lenta ou complexa, podemos melhorar o hardware (equipamento) da máquina virtual ou ajustar por aqui: em vez de subir todas as aulas, subimos apenas a Aula 1 ou apenas a Aula 2. Não há problema.
Com o laboratório apresentado, podemos seguir para a nossa primeira aula de fato.
O objetivo da nossa aula de hoje é a descoberta de hosts (máquinas) em redes corporativas. O foco é localizar hosts (máquinas) ativos com o mínimo de ruído e priorizar o que importa.
Algumas estratégias para conduzir essa descoberta:
Dentro do Pentest (teste de intrusão), mesmo sendo de infraestrutura, podemos partir do meio externo. No meio externo, utilizamos outras ferramentas. Isso já entra na distinção entre descoberta ativa e passiva, na qual utilizamos ferramentas como Shodan e WHOIS. Essas ferramentas operam no ambiente externo.
Quando falamos de ambiente interno, utilizamos outras ferramentas para esse tipo de reconhecimento. Abordaremos mais sobre essas ferramentas nas próximas aulas.
Sobre evitar ruído excessivo: precisamos montar estratégias para minimizar alertas em sistemas de detecção, ajustando a velocidade e o volume de pacotes enviados. Ao pensar em evitar ruído, consideramos a existência de um SOC (Centro de Operações de Segurança) e de um Blue Team (equipe defensiva) na rede. Precisamos evitar que detectem nossa atividade. Assim, é necessário diferenciar um Red Team Assessment (avaliação de equipe ofensiva) de um Pentest (teste de intrusão). Um Pentest (teste de intrusão), de fato, é autorizado e de conhecimento do SOC (Centro de Operações de Segurança) e do Blue Team (equipe defensiva), para evitar falsos positivos nos registros. Logo, evitar ruído excessivo significa não atrapalhar o trabalho dessas outras equipes.
Durante um Pentest (teste de intrusão) de infraestrutura, usualmente estamos em um ambiente de produção e não em um ambiente de homologação.
Nossas ações tendem a acionar regras e alertas no SOC (Centro de Operações de Segurança). Se tivermos essas atividades previamente autorizadas e comunicadas, não haverá problema. Ainda assim, precisamos evitar ruído excessivo, pois nossas ações podem ofuscar ou esconder alguma atividade realmente maliciosa. Portanto, devemos planejar e executar tudo de forma a minimizar ruídos, com alinhamento prévio e todas as partes cientes do que está acontecendo.
Por se tratar de um ambiente de produção, consideremos um exemplo: um servidor web oferecendo uma intranet para colaboradores de uma empresa, onde podem acessar e verificar informações internas. Se, durante o nosso Pentest (teste de invasão), realizarmos algum tipo de scan (varredura) ou enumeração de diretórios nesse servidor, dependendo da ferramenta utilizada e do horário do teste, isso pode causar um DoS (negação de serviço, Denial of Service), isto é, interromper ou degradar o acesso normal. Por isso, no contrato que define como o teste será executado, precisamos amarrar pontos como janela de execução, escopo e tipo de Pentest, especificando se ele pode gerar ruído ou não. Tudo deve estar muito bem definido.
Sobre descoberta ativa e descoberta passiva, já comentamos que a diferença está no contato direto com o alvo. Na descoberta ativa, interagimos diretamente com o host (anfitrião). Por exemplo, podemos realizar um banner grabbing (coleta de banner) para entender que tipo de serviço está em execução, ou estabelecer uma conexão direta da nossa máquina ou do nosso proxy (servidor intermediário) até o alvo.
Na descoberta passiva, utilizamos informações do ambiente que nos trazem indícios sem contato direto. Um exemplo é quando temos acesso a um servidor com Windows Server (servidor Windows) e verificamos a tabela ARP (Protocolo de Resolução de Endereços) desse host (anfitrião), ou mesmo de um host Linux. A tabela ARP mantém o registro do MAC address (endereço MAC) associado ao IP que entrou em contato com nossa máquina. Essa é uma forma de descoberta passiva de ativos que existiam ou existem e que, por algum motivo, não conseguimos encontrar com outras técnicas.
Também é essencial a identificação de ativos críticos. Em testes de infraestrutura, podemos nos deparar com ambientes com centenas, milhares ou dezenas de milhares de ativos. Precisamos identificar quais são realmente críticos e merecem nossa atenção. Em um ambiente com dezenas de milhares de dispositivos (por exemplo, 10 mil ou 20 mil), o que é prioritário? Em um ambiente com Active Directory (Diretório Ativo), o mais importante é o Domain Controller (controlador de domínio). Em um ambiente de banco de dados, é o host onde estão as tabelas e onde realizamos as requisições com as informações sensíveis.
Partindo para a parte prática, vamos verificar quais técnicas podemos utilizar para a descoberta. No painel “Lab Status” (status do laboratório), observamos que o ambiente já está disponível. Vamos focar no Lab 1 (Laboratório 1), que corresponde à Aula 1, e notamos que todos estão no segmento 172.30.0.0. Vamos trabalhar nessa rede.
Como primeira ação, utilizamos o comando ip -br a para verificar o nome da interface de rede. Para acompanhar o que está acontecendo, preferimos usar o tcpdump. É necessário executá-lo com permissão de superusuário para observar o tráfego na interface. Podem existir ruídos, com outros tráfegos de rede e pacotes em trânsito. Por exemplo, podemos observar tráfego do 172.30.0.61 para a rede 172.30.0.0/24. Essa é uma técnica de descoberta passiva: sem contatar diretamente nenhum IP na rede, já conseguimos inferir a existência de 172.30.0.60 e 172.30.0.61. Vemos também o endereço de broadcast (difusão) e confirmamos que há comunicação envolvendo 172.30.0.61. Esse é um exemplo claro de descoberta passiva.
Primeiro listamos as interfaces de rede em formato resumido:
ip -br a
Em seguida, executamos o tcpdump na interface observada, com privilégios de superusuário:
sudo tcpdump -i br-2ec8b61c6b62
Para uma técnica ativa, podemos utilizar o protocolo ICMP (Internet Control Message Protocol), por meio do utilitário de linha de comando ping (ping, envio de eco ICMP). Se o IP da nossa máquina é 172.30.0.1, ao executar ping para 172.30.0.1, testamos a própria conectividade local e confirmamos que está correta. Ao tentar 172.30.0.2, podemos não obter retorno; isso não garante a inexistência do host, mas indica que não há comunicação naquele momento. Considerando o reconhecimento passivo prévio, podemos testar 172.30.0.60 e 172.30.0.61 com ping para confirmar que esses hosts existem e respondem. Assim, combinamos descoberta passiva e ativa.
Testamos a conectividade local:
ping 172.30.0.1
Na sequência, tentamos um endereço adjacente que pode não responder:
ping 172.30.0.2
Com base no que já inferimos passivamente, validamos os alvos observados:
ping 172.30.0.61
ping 172.30.0.60
Se estivermos em uma rede /24, o espaço de endereços é grande para testar IP a IP. Em uma rede /16, maior ainda — e podemos lidar com múltiplas redes, como quatro ou cinco, todas /16. Para automatizar e facilitar, gostamos de trabalhar com um one-liner (comando de uma linha), por exemplo, um loop (laço) de 1 a 20 usando echo, apenas para validar o funcionamento do one-liner. Em seguida, integramos o ping nesse fluxo. Ao realizar ping em 172.30.0.60, comparamos o comportamento de um IP existente com o de um IP que não responde, verificando a diferença de saída entre sucesso e falha.
Primeiro, validamos o laço simples:
for i in {1..20}; do echo $i; done
Em seguida, comparamos o comportamento do ping em um IP que sabemos existir:
ping 172.30.0.60
Verificamos que estamos realizando um echo request (requisição de eco) e não recebemos um echo reply (resposta de eco). Isso significa que o host não está respondendo.
Para diferenciar melhor esse comportamento, procuramos alguma string (cadeia de caracteres) na resposta. Preferimos utilizar o TTL, que é o time to live (tempo de vida). Vamos compreender o TTL com mais detalhes adiante.
Ao realizarmos um ping para um endereço específico e filtrarmos a saída com um pipe (|) para grep ttl, verificamos que conseguimos uma resposta. Se, em outro endereço (por exemplo, terminando em .59), aplicarmos o mesmo procedimento, observamos que a informação deixa de ser exibida na tela. Com isso, já começamos a limpar a saída do nosso script.
Aplicamos o filtro ao ping em um IP que responde:
ping 172.30.0.60 | grep ttl
E repetimos o procedimento em um IP que não deve responder:
ping 172.30.0.59 | grep ttl
Com isso em mente, podemos encaixar essa lógica dentro do nosso script em linha única (one-liner). Em vez de utilizar echo dentro do laço, passamos a utilizar ping. Ainda assim, desse modo não fica ideal. Ao dispararmos ping para os endereços terminados em .1, .2, .3 e assim por diante, o comando trava no primeiro endereço consultado. Em algum momento, precisamos encerrar o comando; se usarmos Ctrl+C, ele avança para o .2; outro Ctrl+C, avança para o .3; e assim sucessivamente, até chegar ao .20. Não é esse o comportamento desejado.
Substituímos o echo por ping dentro do laço para testar a lógica:
for i in {1..20}; do ping 172.30.0.$i; done
O que podemos fazer? Ao consultar ping --help, verificamos algumas opções úteis. Preferimos utilizar a opção -c, que interrompe o envio de echo request assim que a resposta é recebida. Com -c 1, o ping para a execução assim que recebe o primeiro reply. Por exemplo, ao testar no endereço terminado em .60 com -c 1, após receber a primeira resposta o comando já encerra e não executa novamente.
Primeiro, conferimos as opções disponíveis:
ping --help
Aplicamos então a opção -c 1 em um alvo que responde:
ping 172.30.0.60 -c 1
Inserindo essa opção no nosso script, observamos que o primeiro endereço responde; no segundo, a resposta pode indicar que o destino não foi alcançado (“Destination Host Unreachable”), e então o fluxo segue para o próximo. Percebemos, porém, que isso ainda introduz alguma lentidão.
Aplicamos a mesma opção dentro do laço:
for i in {1..20}; do ping 172.30.0.$i -c 1; done
Podemos ajustar adicionando um tempo de espera pela resposta, isto é, o parâmetro de time to wait for response (tempo de espera pela resposta). Utilizamos -W 1 para aguardar até 1 segundo por resposta. Ao testar no endereço terminado em .60, verificamos que o tempo de resposta é bem baixo (inferior a um milissegundo). Já ao comparar com o Google Public DNS (8.8.8.8), o tempo tende a ser maior. Precisamos sempre adaptar o script ao nosso ambiente.
Testamos a combinação -c 1 com -W 1 em um IP que responde:
ping 172.30.0.60 -c 1 -W 1
Assim, combinamos -c 1 com -W 1. Se testarmos no endereço terminado em .59, observamos que o comando aguarda um segundo e encerra, o que é condizente com o que desejamos.
E testamos também em um IP que não responde:
ping 172.30.0.59 -c 1 -W 1
Outro ponto importante é realizar mais uma limpeza na saída dentro do nosso script em linha única. Não queremos ver “ruído” na tela. Podemos adicionar um redirecionamento para /dev/null, de modo que todo o stdout (saída padrão) indesejado seja descartado e não apareça na tela.
Aplicamos a combinação no laço para todo o intervalo:
for i in {1..20}; do ping 172.30.0.$i -c 1 -W 1; done
Ao testar, vemos que o endereço terminado em .1 já foi, o .2 ainda retorna algo, mas sem aplicarmos grep não teremos o filtro funcionando como esperado. É necessário configurar corretamente para obter o resultado correto. Assim, adicionamos um grep ttl e aguardamos. Notamos uma melhoria significativa: vemos apenas as respostas relevantes.
Primeiro, reduzimos o “ruído” redirecionando a saída padrão:
for i in {1..20}; do ping 172.30.0.$i -c 1 -W 1 > /dev/null; done
Em seguida, adicionamos o filtro com grep para exibir somente as respostas com TTL:
for i in {1..20}; do ping 172.30.0.$i -c 1 -W 1 | grep ttl; done
Com isso, o script passa a exibir somente os endereços que respondem. Por exemplo, identificamos que o 172.30.0.31 está funcionando. Em seguida, capturamos também os IPs terminados em .11, .12, .13 e .14. Verificamos, portanto, que nosso script em linha única funcionou como esperado.
A partir daqui, já conseguimos identificar quais IPs estão respondendo. É claro que podemos evoluir isso criando um arquivo .sh e melhorando de diversas maneiras. Este é apenas um exemplo do que podemos automatizar para realizar a análise da rede.
É importante lembrar que essa análise é apenas uma fotografia do ambiente. Isso não significa que, em algum momento, o 172.30.0.12 não possa desaparecer, nem que o 172.30.0.17 não possa surgir. Por isso, é interessante capturar fotografias periódicas do ambiente para validar se um host previamente encontrado ainda existe e se algum host novo apareceu. Com isso, começamos a entender o comportamento da rede.
Podemos, inclusive, avaliar se essa rede trabalha com DHCP, na qual, ao desligarmos ou ligarmos a máquina, ela obtém o IP a partir de um pool (conjunto). Nesse processo, precisamos coletar alguns fingerprints (assinaturas) e começar a montar o mapa da rede.
Para a aula de hoje, é isso. Nas próximas aulas, verificaremos algumas ferramentas que já automatizam esse processo e entregam tudo pronto. Ainda assim, é fundamental entender como realizar essas etapas sem ferramentas, compreender como o ambiente funciona e distinguir entre uma técnica ativa e uma técnica passiva.
Olá, pessoal. Tudo bem?
Dando continuidade ao nosso curso de Pentest (teste de invasão) de infraestrutura, iniciamos agora a Aula 2, Nmap em rede interna.
O objetivo desta aula é usar o Nmap (Network Mapper, mapeador de rede) para varrer e identificar serviços e versões em escala.
Essa ferramenta é praticamente o canivete suíço de pentesters, portanto, faremos algumas observações importantes.
Alguns pontos sobre varreduras com o Nmap:
Existem diversos tipos de varredura. Destacamos dois:
Esse comportamento torna o escaneamento muito mais rápido e menos ruidoso. Conseguimos verificar com o tcpdump que, ao fechar a conexão com alguma porta no TCP Connect Scan, ocorre toda a comunicação do Three-Way Handshake. No SYN Scan, não; ele é mais rápido, envia menos pacotes e é menos barulhento. A desvantagem é que, para conseguirmos utilizar esse tipo de escaneamento com o Nmap, é necessária a permissão de superusuário (root).
Recursos avançados do Nmap:
Temos a descoberta de serviços e versões, quando utilizamos a flag -sV como argumento na execução do Nmap. Nesse caso, o Nmap busca a versão exata do serviço. Em um escaneamento, podemos verificar, por exemplo, que existe um possível servidor SSH em determinada porta. Quando usamos -sV, o Nmap executa scripts por trás para tentar fazer um banner grabbing (coleta de banner) e identificar qual é a versão de fato que está em execução.
Isso é muito interessante, principalmente para servidores web. Quando tratamos de Apache, Tomcat e Nginx, precisamos verificar a versão para entender se esse versionamento possui algum tipo de vulnerabilidade já conhecida, um exploit público ou algo do tipo.
Outro recurso é o NSE (Nmap Scripting Engine). São scripts que o Nmap já tem integrados em seu banco de dados e que facilitam a enumeração. Por exemplo, em uma verificação de um servidor FTP, ao utilizarmos os scripts do NSE, o próprio Nmap pode verificar se esse servidor FTP permite acesso por usuário anônimo. É um script pronto que executa a checagem e já nos retorna essa informação. Para acionarmos os scripts, utilizamos a opção --script (podemos confirmar a sintaxe consultando nmap --help).
O Nmap é interessante para varredura em larga escala. Podemos utilizar arquivos de entrada: em vez de solicitar a varredura de um IP específico, indicamos um arquivo contendo IPs ou redes para o Nmap processar.
Vamos à parte prática no Kali Linux.
Já temos o diretório "Aula 2". Criamos esse diretório para darmos seguimento à nossa aula, e ele está limpo.
Faremos um vínculo com a primeira aula, quando montamos um script em linha de comando para verificar quais IPs ainda estavam respondendo. Vamos utilizar esse mesmo script para gerar um arquivo. A partir desse arquivo, faremos a sanitização dos dados para que possamos utilizá-los no Nmap.
Antes disso, ao executar nmap --help, verificamos diversas possibilidades de uso do Nmap.
Para conferir as opções diretamente no terminal, utilize:
nmap --help
Na especificação de alvos (targets), há a opção de trabalhar com arquivo de entrada, conforme mencionamos. Também existe a opção -iR para definir um alvo aleatório. Podemos excluir IPs específicos, o que é muito útil em um penteste de infraestrutura quando o Blue Team, por exemplo, indica que determinado host funciona como um honeypot (isca), documentando que o IP 172.30.0.234 é um honeypot e não deve ser escaneado. Quem escanear pode cair em uma lista de bloqueio. Esses são mecanismos de segurança da rede que, caso exista um Blue Team, serão informados ao time de penteste, para que possamos excluir esses IPs e evitar falsos positivos, como gerar um alerta no SOC (Security Operations Center, centro de operações de segurança) sobre um possível scan (varredura) de rede. O Nmap já está preparado para atender esse tipo de demanda.
Retomando o SYN Scan, como comentado, fazemos a interrupção do pacote no Three-Way Handshake.
Podemos utilizar também a opção -Pn, que trata todos os hosts como online. Por quê? Podemos atingir um host que, porventura, não responda a ping (não faça echo reply). Quando não passamos esse parâmetro, o Nmap primeiro faz um ping no IP; em varreduras de rede (e não em um IP específico), se o IP não responde ao ping, o Nmap não realiza o escaneamento. Como alguns hosts podem ser configurados para não responder a ping, ao utilizarmos -Pn, o Nmap considera que todos os hosts estão ativos, não faz o ping e segue diretamente para o escaneamento, independentemente de o host responder ou não ao ping.
Podemos especificar portas no Nmap para ganhar tempo. Sobre a opção -sV, que realiza a detecção de versões, e a opção -sC, que executa os scripts padrão, podemos inclusive definir quais scripts queremos executar. É interessante também a verificação de sistema operacional.
A questão da velocidade é fundamental para não gerar muito ruído na rede e não chamar atenção. Por padrão, o Nmap utiliza -T3, e a escala vai de -T0 até -T5. Quanto maior a velocidade, mais threads (linhas de execução) são executadas, o que pode ocasionar um DoS (negação de serviço) ou gerar tráfego excessivo na rede. Precisamos sempre avaliar isso nos nossos pentestes. Há ainda a questão de firewall (firewall) e muitos outros parâmetros; é uma ferramenta bastante completa. Recomendamos estudar melhor a documentação, utilizando, por exemplo, o comando man nmap, que apresenta descrições e exemplos de execução.
Para explorar a documentação diretamente no terminal:
man nmap
Entre os exemplos do manual, temos o uso de -A com -T4. A opção -T4 aumenta a velocidade, enquanto -A ativa o modo agressivo: ele tenta identificar o sistema operacional, verificar versões com -sV e executar scripts (roteiros). É um modo bem mais agressivo. Porém, para o foco desta aula, utilizaremos o Nmap de maneira mais simples.
Como primeiro passo, vamos criar um arquivo hosts_descobertos-1-20 contendo os IPs do intervalo de 1 a 20. Poderíamos varrer toda a rede, excluindo o endereço de broadcast (difusão). Ao redirecionar a saída, não imprimiremos na tela; caso queiramos imprimir e salvar ao mesmo tempo, podemos substituir a dupla redireção por tee. Aqui utilizaremos apenas a redireção tradicional para arquivo.
Para gerar esse arquivo de IPs respondendo a ping no intervalo 1..20, podemos usar:
for i in {1..20}; do ping 172.30.0.$i -c 1 2>/dev/null | grep ttl >> hosts_descobertos-1-20 ; done
Enquanto aguardamos, podemos executar o tcpdump para verificar a comunicação que ocorre por trás. Observamos as requisições do tipo ARP Request (requisição ARP) e as respostas ICMP Echo Reply (resposta de eco ICMP), acompanhando o que está sendo trafegado.
Para observar os pacotes na interface de rede utilizada, execute:
sudo tcpdump -i br-3bc635c9a062
Ao abrir o arquivo hosts_descobertos-1-20, percebemos que o conteúdo veio “sujo” para uso direto no Nmap. Precisamos sanitizá-lo, focando apenas no IP. Podemos utilizar o cut com delimitador espaço para capturar a quarta coluna; como ainda vem acompanhada de dois pontos, aplicamos um novo corte para separar e ficar apenas com o endereço. Em seguida, gravamos o resultado em hosts_sanitizados. Assim, obtemos uma lista bem mais limpa para realizar a varredura.
Um pipeline que realiza essa sanitização fica assim:
cat hosts_descobertos-1-20 | cut -d " " -f 4 | cut -d ":" -f 1 > hosts_sanitizados
Podemos utilizar o Nmap informando diretamente um IP e executar a varredura. Observamos que ele roda rapidamente porque estamos em rede próxima, dentro do Docker (Docker), em um container (contêiner), o que reduz a latência.
Para uma varredura padrão em um host específico:
nmap 172.30.0.11
Para observar o “barulho” que o Nmap pode fazer, executamos primeiro a varredura padrão e percebemos que ele escaneia muitas portas rapidamente. Ajustando a velocidade com -T2, a varredura fica mais lenta, diferentemente do caso anterior, que levou algo em torno de 0,25 segundos. Se executarmos com -T0, veremos que fica muito mais devagar: ele espera mais e praticamente não envia pacotes no início. Portanto, a configuração de velocidade deve ser usada com parcimônia. Ao testar a velocidade máxima com -T5, praticamente não há ganho em relação a -T3 neste cenário, já que estamos dentro de Docker (Docker).
Para comparar as diferentes políticas de tempo:
nmap -T2 172.30.0.11
nmap -T0 172.30.0.11
nmap -T5 172.30.0.11
Outro parâmetro útil é -p. Podemos escanear todas as portas com -p-, ou especificar portas e intervalos, como -p 22,8080 ou -p 1-65535. Ao colocar todas as portas, a execução tende a demorar mais; ainda assim, neste ambiente, o Nmap conseguiu efetuar uma varredura de praticamente todas as portas em cerca de 1,80 segundos.
Para varrer todas as portas de um host:
nmap -p- 172.30.0.11
Se executarmos a varredura do tipo -sS (SYN scan), o ideal é utilizar sudo ou executar como usuário root. Aqui ela funcionou porque já havíamos utilizado sudo anteriormente neste terminal. Não observamos ganho de velocidade neste ambiente por estarmos dentro de um container (contêiner) e bem próximos do host (máquina) alvo; entretanto, em um cenário envolvendo VPN (rede privada virtual) e hosts (máquinas) remotos, essa diferença de tempo provavelmente seria significativa.
A sequência abaixo ilustra o uso do SYN scan sem e com privilégios elevados:
nmap -sS 172.30.0.11
sudo nmap -sS 172.30.0.11
Fazer a varredura IP por IP consome tempo. No nosso caso, encontramos um conjunto de hosts sanitizados e precisaríamos escanear manualmente vários endereços, com o risco de incluir o nosso próprio IP. Para evitar varrer o nosso próprio endereço, podemos excluí-lo da lista. Em vez de executar comando por comando para cada IP, podemos utilizar a opção -iL apontando para o arquivo hosts_sanitizados, realizando a varredura de todas as portas em todos os hosts que descobrimos até agora.
Podemos acionar o Nmap com lista de alvos assim:
nmap -iL hosts_sanitizados
Observamos que esse procedimento leva um certo tempo. Em um teste, a execução demorou 8,39 segundos. Acreditamos que, com um SYN scan, não deva demorar muito mais. Notamos também a mesma situação recorrente: sempre que executamos, o Nmap refaz a varredura. Para registrar o resultado enquanto acompanhamos a execução, podemos usar redirecionamento ou um pipe com tee, salvando e imprimindo na tela simultaneamente. Assim, acompanhamos o que está acontecendo e identificamos rapidamente possíveis erros. Em seguida, podemos visualizar o arquivo gerado com cat, por exemplo scan_hosts_descobertos.
Para salvar a saída enquanto visualiza no terminal:
nmap -iL hosts_sanitizados | tee scan_hosts_descobertos
E para inspecionar o arquivo salvo:
cat scan-hosts-descobertos
O Nmap é uma ferramenta bem completa e oferece opções de output (saída). Podemos utilizar -oA para gerar, de uma só vez, os três formatos: o modo normal (-oN), o XML (-oX) e o formato “grepable” (-oG). Isso se ajusta bem à ideia de automação. Podemos criar um parser (analisador) ou um script de parseamento para capturar as informações e já gerar um arquivo específico, como em JSON, a fim de tratá-las com outra ferramenta. Vamos construindo nossas ferramentas e nos adaptando ao que for melhor para o nosso pentest. Caso contrário, repetiremos procedimentos manualmente o tempo todo. Investimos tempo para estruturar isso, e quanto mais automatizado, melhor — especialmente considerando que hoje contamos com inteligência artificial, a qual pode ajudar bastante na automatização.
No nosso caso, já temos o arquivo. Podemos executar cat no scan-hosts-descobertos. Verificamos que é possível fazer a varredura de todas as portas ou focar em um conjunto específico. Se a quantidade de informações ainda estiver limitada, podemos aprofundar.
Por exemplo, podemos focar no host terminado em .11; porém, vamos concentrar no .14, pois identificamos um serviço web nas portas 80 e 443. Ainda não sabemos se é Nginx, Apache ou Tomcat. Para obter mais detalhes, utilizamos a varredura agressiva com -A e restringimos as portas com -p 80,443. Para facilitar o acompanhamento e o registro, podemos novamente empregar tee, salvando um arquivo como scan-detalhado-14 para o alvo 172.30.0.14. Essa execução tende a demorar mais, justamente por ser uma varredura agressiva.
Para rodar essa verificação detalhada e registrar a saída:
nmap -A -p 80,443 172.30.0.14 | tee scan-detalhado-14
O resultado retornou que, na porta 80, está em execução o Nginx na versão 1.24, junto de outras informações relevantes. Isso reforça a vantagem de não refazer a varredura continuamente: documentamos o que foi encontrado e, ao automatizar, podemos orquestrar o fluxo completo. Após coletar informações de toda a rede, executamos o Nmap, capturamos as portas abertas e, em seguida, rodamos a varredura agressiva nos alvos. Ao final, teremos um relatório pronto com tudo o que foi descoberto na rede.
Para esta aula, é isso. É claro que o Nmap tem uma capacidade muito maior do que apresentamos. Sempre vamos adaptar o uso às nossas necessidades.
O curso Pentest de Infraestrutura: identificação, exploração e mitigação de vulnerabilidades possui 449 minutos de vídeos, em um total de 58 atividades. Gostou? Conheça nossos outros cursos de Red Team & Pentest em Cibersegurança, ou leia nossos artigos de Cibersegurança.
Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:
O Plano Plus evoluiu: agora com Luri para impulsionar sua carreira com os melhores cursos e acesso à maior comunidade tech.
2 anos de Alura
Matricule-se no plano PLUS 24 e garanta:
Jornada de estudos progressiva que te guia desde os fundamentos até a atuação prática. Você acompanha sua evolução, entende os próximos passos e se aprofunda nos conteúdos com quem é referência no mercado.
Back-end, Dados, Front-end, DevOps, Mobile, Gestão & Negócios, UX & Design, Cibersegurança, Cloud, Inteligência Artificial
Formações com mais de 1500 cursos atualizados e novos lançamentos semanais, em Programação, Inteligência Artificial, Front-end, UX & Design, Data Science, Mobile, DevOps e Inovação & Gestão.
A cada curso ou formação concluído, um novo certificado para turbinar seu currículo e LinkedIn.
Acesso à inteligência artificial da Alura.
No Discord, você participa de eventos exclusivos, pode tirar dúvidas em estudos colaborativos e ainda conta com mentorias em grupo com especialistas de diversas áreas.
Catálogo de tecnologia para quem é da área de Marketing
Faça parte da maior comunidade Dev do país e crie conexões com mais de 120 mil pessoas no Discord.
Acesso ilimitado ao catálogo de Imersões da Alura para praticar conhecimentos em diferentes áreas.
Explore um universo de possibilidades na palma da sua mão. Baixe as aulas para assistir offline, onde e quando quiser.
20% de desconto na Pós Tech
Luri Vision chegou no Plano Pro: a IA da Alura que enxerga suas dúvidas, acelera seu aprendizado e conta também com o Alura Língua que prepara você para competir no mercado internacional.
2 anos de Alura
Todos os benefícios do PLUS 24 e mais vantagens exclusivas:
Acesso ao catálogo da Casa do Código e leitura dentro da plataforma
Modo entrevista - Pratique situações reais e evolua com feedback personalizado
Envie imagens para a Luri e ela te ajuda a solucionar problemas, identificar erros, esclarecer gráficos, analisar design e muito mais.
Aprenda um novo idioma e expanda seus horizontes profissionais. Cursos de Inglês, Espanhol e Inglês para Devs, 100% focado em tecnologia.
Para quem quer atingir seus objetivos mais rápido: Luri Vision ilimitado, vagas de emprego exclusivas e mentorias para acelerar cada etapa da jornada.
2 anos de Alura
Todos os benefícios do PRO 24 e mais vantagens exclusivas:
Envie imagens para a Luri e ela te ajuda a solucionar problemas, identificar erros, esclarecer gráficos, analisar design e muito mais de forma ilimitada.
Lives CareerUp: eventos exclusivos com foco em empregabilidade e carreira
Mentorias de carreira: 2 encontros individuais com mentores do Talent Lab
Conecte-se ao mercado com mentoria individual personalizada, vagas exclusivas e networking estratégico que impulsionam sua carreira tech para o próximo nível.
