Scanning no contexto de segurança da informação: o que é e como funciona na prática
Muita gente confunde scanning com hacking, mas são coisas diferentes. Scanning é basicamente o ato de enviar pacotes ou requisições para sistemas alvos apenas para coletar informações sobre o que existe lá. Pode ser um scanner de portas rodando em uma rede, um tool de vulnerabilidade varrendo servidores, ou até mesmo um mapeamento de serviços ativos. O objetivo inicial é sempre reconhecimento, não invasão.
O que é scanning e quais tipos existem
Scanning é o processo sistemático de sondar um alvo para mapear seus componentes. Existem vários tipos, e cada um tem um propósito distinto. O mais comum é o network port scanning, que verifica quais portas TCP ou UDP estão abertas em um host. Ferramentas como Nmap fazem isso enviando pacotes SYN, ACK, FIN, ou RST e analisando as respostas para inferir o estado de cada porta. Depois vem o vulnerability scanning, que vai além de portas abertas e verifica se há serviços desatualizados, configurações erradas, ou falhas conhecidas (CVEs) nos sistemas encontrados. Ferramentas como Nessus, OpenVAS e Qualys rodam esses checks automatizados. Também existe o web application scanning, que foca em aplicações HTTP/HTTPS procurando por XSS, SQL injection, e outras falhas da OWASP Top 10.
E o DNS e enumeração de subdomínios também contam como scanning. Coletar registros MX, NS, TXT, CNAME e descobrir subdomínios expostos é uma forma de scanning que muitas vezes é subestimada, mas pode revelar uma quantidade enorme de superfície de ataque. Na prática, a sequência que eu vejo funcionar melhor é começar pelo network scanning para mapear o terreno, depois rodar um vulnerability scan nos alvos identificados, e finalmente focar nos serviços web com ferramentas dedicadas. Tentar fazer tudo de uma vez só geralmente gera resultados ruins e muito ruído nos logs do alvo.
Como configurar um scan realista no Nmap
Eu gosto de começar com um scan discreto antes de qualquer coisa agressiva. Um comando como o que segue geralmente é suficiente para um reconhecimento inicial sem disparar muitos IDS: nmap -sS -sV -O --top-ports 1000 -T2 <alvo>
O flag -sS roda um TCP SYN scan, que é mais rápido e menos detectável que um connect scan completo. O -sV tenta identificar versões dos serviços rodando nas portas abertas. O -O ativa detecção de sistema operacional, embora eu ache que isso só funciona bem em redes onde você não está muito distante do alvo. O --top-ports 1000 limita o scan às mil portas mais comuns, o que economiza tempo significativamente. E o -T2 reduz a velocidade para algo mais sutil que o padrão -T4. Se você já sabe que o alvo usa um firewall ou WAF, o scan rápido e agresivo vai simplesmente te dar resultados incompletos ou até induzir ao erro. Nesse caso, eu uso.timing mais lento, sigo com -T1 ou até o flag --scan-delay para espalhar os pacotes ao longo de minutos. Isso aumenta o tempo de execução mas melhora drasticamente a taxa de sucesso.
Problemas reais que eu já encontrei e como contornei
Uma vez eu estava escaneando uma infraestrutura onde o scanner de vulnerabilidade reportava falsos positivos massivos em serviços de impressão e SMB. O problema era que o alvo tinha um IPS configurado com regras agressivas de signature matching, e os probes do scanner eram interceptados e respondidos com pacotes truncados, fazendo o scanner acreditar que os serviços estavam ativos quando na verdade eram apenas respostas fake do dispositivo de segurança. A solução foi cruzar os dados. Eu rodei um Nmap com -sV em modo verbose nas portas suspeitas, comparei os banners retornados com o que o vulnerability scanner indicava, e confirmei que os serviços "vulneráveis" eram apenas artfatos do IPS. Em seguida, eu fiz um check manual conectando via Telnet ou Netcat porta por porta para validar o que realmente estava rodando. Esse passo extra de validação manual eliminou cerca de 60% dos alertas do relatório final.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Outro problema comum que eu vejo repetidamente é quando pessoas escaneiam alvos externos usando a mesma máquina e a mesma IP source sem rotacionar ou usar proxies. Os provedores de nuvem e CDNs modernos têm rate limiting e blacklisting automáticos. Uma vez, um scan de 200 IPs em um bloco /24 simplesmente parou de responder pela metade do caminho porque o provedor do alvo tinha bloqueado nosso IP após 47 tentativas em 3 minutos. A workaround foi segmentar o scan em lotes de 20 IPs com delays de 30 segundos entre cada lote, o que dobrou o tempo total mas manteve o scan rodando até o fim sem bloqueios.
O que ninguém te conta sobre scanning
Primeiro: scanning não é sinônimo de comprometimento. A maioria dos scanners que você encontra no mercado operam no nível de reconnaissance passivo ou ativo limitado. Eles coletam informações, mas não exploram falhas. Se o seu objetivo é apenas entender a superfície de ataque, um scanning bem feito já responde a maior parte das perguntas. Segundo: falsos negativos são mais perigosos que falsos positivos. Um relatório dizendo que não há vulnerabilidades é muito mais arriscado do que um relatório cheio de alertas. Scanners automaticos têm limites conhecidos — eles não testam lógica de negócio, não entendem contextos específicos da aplicação, e não conseguem detectar falhas customizadas ou de integração. Se um scan retorna zero achados, o correto é assumir que o scanner limitou o que conseguiu encontrar, não que o alvo é seguro.
Terceiro: o momento do scan importa muito. Escanear um ambiente de produção durante horário comercial gera tráfego anormal que pode afetar a disponibilidade de serviços sensíveis. Eu recomendo sempre coordenar scans com a equipe de operações e preferir janelas de manutenção ou horas fora do pico. Um scan de vulnerabilidade mal planejado em um servidor de banco de dados ativo pode derrubar conexões ou sobrecarregar recursos por causa dos probes intensivos.
Alternativas quando o scanning tradicional não funciona
Se você está lidando com ambientes onde scanners tradicionais são bloqueados ou geram muito ruído, existe o scanning passivo. Nesse método, você captura tráfego de rede com ferramentas como tcpdump ou Zeek e analisa os fluxos sem enviar nenhum pacote ativo para o alvo. É mais lento porque depende do tráfego natural da rede, mas é praticamente indetectável e funciona bem em ambientes corporativos com políticas de segurança restritivas. Outra alternativa é usar APIs e dados de terceiros. Serviços como Shodan, Censys e ZoomEye indexam bilhões de serviços expostos na internet. Antes de rodar qualquer scan ativo, vale a pena verificar se essas plataformas já mapearam o alvo. Às vezes você descobre subdomínios, portas e versões de serviços que levariam horas para encontrar ativamente, e ainda evita gerar qualquer tráfego sospeitoso.
Dicas práticas para quem vai começar
Defina claramente o escopo antes de qualquer coisa. Anotar quais IPs, domínios e faixas de portas estão permitidos evita que você acabe escaneando algo que não deveria. Tenho visto gente começar um scan e perceber no meio do caminho que havia atingido infraestrutura de terceiros por erro de configuração de escopo. Isso gera problemas reais com equipes de outros departamentos. Mantenha os relatórios organizados desde o primeiro dia. Salve os resultados brutos de cada ferramenta em diretórios separados por data e alvo. Nmap salva em XML com -oX, OpenVAS exporta em PDF e XML, e o importante é ter tudo arquivado. Daqui a três meses, quando você precisar provar que um alvo foi verificado e estava limpo, vai agradecer por ter esses logs.
Não confie cegamente em nenhuma ferramenta. Um scanner é um assistente, não um oráculo. Sempre valide achados críticos com testes manuais quando possível. E lembre-se de que scanning é apenas o primeiro passo em um processo muito maior que inclui análise, priorização e mitigação. Ter um bom scan não significa ter um bom programa de segurança.
