A partir desta aula, você toca no alvo. Todo o reconhecimento anterior foi observação à distância; agora começamos a interrogar os sistemas diretamente, enviando pacotes e interpretando respostas. Essa é a fase de scanning (varredura), e ela tem um objetivo preciso: transformar o mapa amplo do reconhecimento num inventário técnico detalhado de o que está vivo, o que está aberto e o que está escutando. Antes de disparar qualquer ferramenta, você precisa entender a lógica do que está acontecendo — porque scanning sem compreensão gera ruído inútil e conclusões erradas.
Três perguntas, nesta ordem
O scanning responde a três perguntas, em ordem. Primeiro: quais hosts estão vivos? (host discovery). De uma faixa de IPs, quais realmente têm uma máquina respondendo? Segundo: quais portas estão abertas em cada host vivo? (port scanning). Lembre da aula TCP/IP e o modelo OSI: como os pacotes realmente viajam — cada porta aberta é um serviço escutando, uma porta de entrada potencial. Terceiro: que serviço, e qual versão, roda em cada porta aberta? (service/version detection). Saber que a porta 80 está aberta é útil; saber que ali roda "Apache 2.4.49" é o que conecta com vulnerabilidades específicas. Cada pergunta refina a anterior, estreitando o foco do território ao alvo concreto.
Enviar um pacote e ler a resposta
Toda a mecânica do scanning se apoia no que você já aprendeu sobre TCP na aula Protocolos em ação: handshake TCP, DNS e inspeção real — o three-way handshake. Relembre a lógica, porque ela é a base de tudo: você envia um pacote a uma porta e interpreta a resposta. Se você envia um SYN e recebe um SYN-ACK, a porta está aberta (o serviço quer conversar). Se recebe um RST (reset), está fechada (nada escutando ali, mas o host respondeu). Se não recebe nada, está filtrada (algo — um firewall — está engolindo seu pacote silenciosamente). Essas três respostas — aberta, fechada, filtrada — são o alfabeto do scanning, e cada tipo de scan é apenas uma forma diferente de fazer essa pergunta e ler a resposta. Você construiu isso na mão com Scapy na aula Python para pentest II: forjando pacotes com Scapy; agora vai usar ferramentas que fazem em escala industrial.
Connect, SYN e os scans furtivos
É por isso que existem diferentes tipos de scan, cada um com um trade-off entre completude, velocidade e discrição. O TCP Connect scan completa o handshake inteiro (SYN, SYN-ACK, ACK) — é confiável e não requer privilégios especiais, mas é barulhento, pois a conexão completa costuma ser registrada nos logs do serviço. O SYN scan (stealth) envia o SYN, recebe o SYN-ACK, e corta antes do ACK final — mais discreto, pois a conexão nunca se completa, e mais rápido. Há scans para UDP, mais lentos e ambíguos (lembre da aula TCP/IP e o modelo OSI: como os pacotes realmente viajam: sem handshake, o silêncio é difícil de interpretar), mas indispensáveis, porque serviços críticos como DNS e SNMP vivem em UDP e seriam invisíveis num scan só-TCP. E há variações mais exóticas (FIN, NULL, Xmas scans) que manipulam flags de formas incomuns para tentar driblar certos firewalls. Escolher o scan certo é decisão tática, não detalhe técnico.
Agora você deixa rastros
Aqui entra uma dimensão que o reconhecimento passivo não tinha: você agora deixa rastros, e precisa decidir quão discreto ser. Um scan agressivo e completo é rápido e minucioso, mas acende alarmes — sistemas de detecção de intrusão (IDS) reconhecem padrões de varredura (muitas portas sondadas em sequência a partir de uma origem) e alertam. Um scan lento e fragmentado é mais discreto, mas leva muito mais tempo. Essa tensão entre ser minucioso e ser invisível é constante no trabalho ofensivo, e a escolha depende do objetivo: num pentest focado em cobertura, velocidade e completude importam mais; num red team engagement que testa detecção, a discrição é essencial. Não existe scan "certo" em abstrato — existe o scan adequado ao objetivo.
Autorização, ruído e método
Antes de partir para a ferramenta, três pontos de disciplina profissional. Primeiro, autorização é inegociável aqui mais do que nunca: scanning é acesso ativo, envia pacotes a sistemas alheios, e fora de escopo é o crime da aula A lei que separa a carreira do processo criminal — não existe "scan inofensivo" de sistema de terceiros. Segundo, scanning pode causar impacto: certos scans agressivos, ou scans contra sistemas frágeis (dispositivos antigos, equipamentos industriais da aula OT e ICS: quando o ciberataque afeta o mundo físico), podem derrubar serviços; por isso as Regras de Engajamento definem o que é permitido, e por isso você pratica primeiro no laboratório. Terceiro, interprete, não apenas colete: o valor do scanning não está na lista de portas, mas no que você conclui dela — cada porta aberta é uma hipótese de ataque a investigar na enumeração. Com a teoria firme, entra a ferramenta que domina esta fase há décadas e que você usará até o fim da carreira: o Nmap.
Fontes e leituras recomendadas
- Nmap Network Scanning — Gordon "Fyodor" Lyon (o criador do Nmap; a referência definitiva)
- MITRE ATT&CK — táticas Discovery e técnicas de varredura
- RFC 793 (TCP) — para revisitar o comportamento das flags
- TryHackMe — salas de introdução a scanning e Nmap, para praticar em paralelo
Exercícios
-
Quais são as três perguntas que o scanning responde, em ordem, e como cada uma refina a anterior?
✓ Resposta:(1) Quais hosts estão vivos (host discovery); (2) quais portas estão abertas nesses hosts (port scanning); (3) que serviço e versão rodam em cada porta aberta (service/version detection). Cada resposta estreita o foco: descobrem-se os hosts vivos, depois as portas abertas neles, depois os serviços por trás dessas portas.
-
Relacione as respostas SYN-ACK, RST e "sem resposta" aos estados de porta aberta, fechada e filtrada.
✓ Resposta:SYN-ACK → porta aberta (o serviço aceita conversar); RST → porta fechada (o host respondeu, mas nada escuta ali); sem resposta → porta filtrada (um firewall provavelmente descarta o pacote silenciosamente).
-
Compare o TCP Connect scan e o SYN scan em termos de completude, velocidade e discrição.
✓ Resposta:O TCP Connect completa todo o handshake: é confiável e não exige privilégios, mas é barulhento (a conexão é registrada). O SYN scan envia o SYN e corta antes do ACK final: é mais discreto (conexão nunca se completa) e mais rápido.
-
Por que scans UDP são indispensáveis apesar de mais lentos e ambíguos? Dê exemplos de serviços que os exigem.
✓ Resposta:Porque serviços críticos operam sobre UDP e ficariam invisíveis num scan só-TCP — por exemplo, DNS e SNMP. Apesar da ambiguidade (sem handshake, o silêncio é difícil de interpretar), ignorá-los deixaria lacunas graves no inventário.
-
Explique a tensão entre "ser minucioso" e "ser invisível" no scanning, e como o objetivo do engajamento influencia essa escolha.
✓ Resposta:Scans agressivos e completos são minuciosos e rápidos, mas acionam sistemas de detecção; scans lentos e fragmentados são discretos, mas demorados. Em pentests focados em cobertura, prioriza-se completude e velocidade; em red team engagements que testam detecção, prioriza-se a discrição.
