Fundamentos de redes para pentest

Você pode aprender dezenas de ferramentas de hacking, mas sem entender como os pacotes viajam pela rede, cada resultado de scan será apenas ruído. Redes são a fundação de qualquer teste de invasão: é por elas que o tráfego flui, que os serviços expõem portas e que as vulnerabilidades se tornam alcançáveis. Este guia cobre os fundamentos de TCP/IP, portas e protocolos que todo pentester precisa dominar antes de digitar o primeiro comando.

Por que redes importam para o pentest

Um pentest é, em essência, uma conversa com máquinas remotas. Você envia pacotes, observa respostas e infere o estado do alvo a partir desse comportamento. Se você não entende o que é um pacote SYN ou por que uma porta aparece como filtered, você não consegue interpretar o que sua ferramenta está dizendo.

Esse entendimento aparece em todas as etapas. Durante o reconhecimento (recon), você mapeia faixas de IP e identifica hosts vivos. Durante o scanning com Nmap, você traduz respostas de pacotes em uma lista de serviços. E ao longo de toda a metodologia de pentest, o modelo mental de rede orienta quais ataques fazem sentido contra cada serviço.

Há uma diferença fundamental entre rodar uma ferramenta e entender o que ela faz. Um script kiddie aponta o scanner e copia a saída; um profissional sabe por que aquela porta respondeu daquele jeito, o que o resultado esconde e qual a próxima pergunta a fazer ao alvo. Essa diferença mora inteiramente nos fundamentos de rede.

O modelo TCP/IP em camadas

A comunicação na internet é organizada em camadas, cada uma responsável por uma parte do trabalho. O modelo TCP/IP, mais prático que o modelo OSI de sete camadas, divide tudo em quatro:

Para o pentester, o ponto-chave é que cada camada adiciona um cabeçalho ao redor dos dados. Quando você inspeciona tráfego no Wireshark, está literalmente desempacotando essas camadas: Ethernet, depois IP, depois TCP, depois o protocolo de aplicação.

Visualmente, um pacote HTTP encapsulado fica mais ou menos assim, do mais externo ao mais interno:

[ Cabeçalho Ethernet | Cabeçalho IP | Cabeçalho TCP | Dados HTTP ]
        MAC origem/destino   IP origem/destino  portas   GET /index.html

Entender esse encapsulamento explica fenômenos práticos. Um firewall de camada 3/4 decide com base nos cabeçalhos IP e TCP (endereços e portas), sem olhar o conteúdo HTTP; já um WAF (firewall de aplicação) precisa "subir" até a camada de aplicação para inspecionar o GET. Saber em que camada cada defesa atua orienta como contorná-la ou testá-la.

Endereços IP, sub-redes e CIDR

Todo host na rede tem um endereço IP. Em IPv4, são 32 bits divididos em quatro octetos, como 192.168.1.10. Entender sub-redes é essencial porque, no recon, você raramente ataca um único IP — você varre uma faixa.

A notação CIDR expressa faixas de forma compacta. O sufixo indica quantos bits identificam a rede:

192.168.1.0/24   → 256 endereços (192.168.1.0 a 192.168.1.255)
10.0.0.0/8       → ~16,7 milhões de endereços
172.16.5.0/28    → 16 endereços

A regra mental rápida: quanto maior o número após a barra, menor a faixa. Um /32 é um único host; um /24 é a clássica "rede de 256 endereços" de uma LAN doméstica; um /16 cobre 65.536 endereços. Saber estimar o tamanho de uma faixa de cabeça evita que você dispare um scan que levaria dias quando o cliente esperava horas.

Você também deve reconhecer faixas privadas (RFC 1918), que não roteiam na internet pública: 10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16. Encontrar IPs privados durante um teste externo geralmente sinaliza um vazamento de informação interna — por exemplo, um cabeçalho HTTP ou uma mensagem de erro que revela o IP interno de um servidor por trás de um balanceador.

Vale também conhecer o IPv6. Cada vez mais redes o habilitam, e um host pode estar firewallado em IPv4 mas totalmente exposto em IPv6 porque o administrador esqueceu de replicar as regras. Ignorar IPv6 no escopo é um ponto cego comum.

TCP versus UDP: a diferença que define o scan

A camada de transporte oferece dois protocolos principais, e a escolha entre eles muda completamente como você scaneia.

TCP (Transmission Control Protocol) é orientado a conexão e confiável. Antes de trocar dados, cliente e servidor executam o famoso three-way handshake:

Cliente  → SYN →      Servidor
Cliente  ← SYN/ACK ←  Servidor
Cliente  → ACK →      Servidor

Esse handshake é a base do scan TCP. Quando uma porta está aberta, ela responde ao SYN com SYN/ACK. Quando está fechada, responde com RST. Quando um firewall descarta o pacote silenciosamente, você não recebe resposta — e a ferramenta marca a porta como filtered.

Essa mecânica explica o SYN scan (também chamado "half-open"), o modo padrão e mais furtivo do Nmap. Em vez de completar o handshake, o scanner envia o SYN, lê a resposta para determinar o estado da porta e, em vez de mandar o ACK final, envia um RST que aborta a conexão. Como a conexão nunca se completa, muitas aplicações nem registram a tentativa nos seus logs:

Porta aberta:    SYN → ... ← SYN/ACK ... → RST (scanner aborta)
Porta fechada:   SYN → ... ← RST
Porta filtrada:  SYN → ... (silêncio)

UDP (User Datagram Protocol) não tem handshake nem garantias. Você envia um datagrama e talvez receba algo de volta. Isso torna o scan UDP mais lento e ambíguo: a ausência de resposta pode significar porta aberta ou pacote filtrado. Na prática, scanners marcam essas portas como open|filtered justamente por essa ambiguidade. Ainda assim, serviços críticos como DNS (53), SNMP (161) e DHCP rodam sobre UDP e não podem ser ignorados — um SNMP mal configurado, por exemplo, costuma despejar a topologia inteira da rede.

A lição prática: escanear só TCP é metade do trabalho. Muitos pentests medíocres deixam passar serviços UDP valiosos por preguiça, já que o scan UDP é lento e exige paciência.

Portas e serviços: o mapa do alvo

Uma porta é um número de 16 bits (0 a 65535) que identifica um serviço dentro de um host. Combinada com o IP, ela forma um socket — o endereço completo de um ponto de comunicação.

As portas se dividem em três faixas:

Memorizar as portas mais comuns acelera muito a análise. Algumas essenciais:

| Porta | Protocolo | Serviço | |-------|-----------|---------| | 21 | TCP | FTP | | 22 | TCP | SSH | | 25 | TCP | SMTP | | 53 | TCP/UDP | DNS | | 80 | TCP | HTTP | | 110 | TCP | POP3 | | 143 | TCP | IMAP | | 161 | UDP | SNMP | | 443 | TCP | HTTPS | | 445 | TCP | SMB | | 3306 | TCP | MySQL | | 3389 | TCP | RDP | | 5432 | TCP | PostgreSQL | | 6379 | TCP | Redis |

Como observa Lyon (2009), enumerar portas abertas e identificar os serviços por trás delas é o coração da fase de scanning — cada porta aberta é uma superfície de ataque em potencial.

Um cuidado importante: a porta padrão é uma convenção, não uma garantia. Um SSH pode rodar na porta 2222 e um servidor web na 8080. Por isso, identificar o serviço pela porta apenas é um palpite; confirmar pela resposta real do serviço (service detection) é o que dá certeza. É a diferença entre "provavelmente é HTTP porque é a 80" e "é HTTP porque o servidor respondeu com cabeçalhos HTTP".

Banner grabbing e fingerprinting

Identificar a porta aberta é só o começo; você quer saber qual software e qual versão está atrás dela, porque vulnerabilidades são específicas de versão. O banner grabbing consiste em ler a apresentação que muitos serviços enviam ao conectar. No nível mais cru, dá para fazer manualmente:

# Lê o banner de um serviço SSH
nc alvo.exemplo.com 22

# Resposta típica:
# SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.5

Esse banner revela OpenSSH 8.2p1 num Ubuntu — informação suficiente para cruzar com bases de CVE e descobrir se aquela versão tem falhas conhecidas. Ferramentas como o Nmap automatizam isso com sondas mais sofisticadas, comparando respostas contra uma base de assinaturas para deduzir o serviço mesmo quando o banner é omitido ou falsificado.

Protocolos de aplicação que todo pentester encontra

Conhecer a camada de transporte não basta; você precisa entender os protocolos que rodam sobre ela, porque é neles que residem a maioria das vulnerabilidades web.

O HTTP é provavelmente o protocolo mais importante para testes de aplicações. Ele define métodos (GET, POST, PUT, DELETE), códigos de status e cabeçalhos que carregam tokens, cookies e informações de sessão. Por ser textual e sem estado, cada requisição precisa carregar sozinha o contexto de quem é o usuário — daí a importância de cookies e tokens, que se tornam alvos diretos. Se você quer fundamentos sólidos, vale revisar o que é HTTP e como a web conversa.

O DNS traduz nomes em IPs e, no recon, costuma vazar subdomínios, registros de e-mail (MX) e infraestrutura interna. Transferências de zona mal configuradas (AXFR) são um achado clássico: com um único comando, o atacante baixa o mapa completo de nomes de uma organização. Técnicas de enumeração de subdomínios também ampliam a superfície de ataque ao revelar ambientes esquecidos (dev, staging, old).

Já o TLS protege o HTTP, transformando-o em HTTPS. Entender o handshake TLS, certificados e versões de protocolo permite identificar configurações fracas, como cifras obsoletas, protocolos depreciados (SSLv3, TLS 1.0) ou certificados expirados. Curiosamente, o próprio certificado é fonte de recon: o campo Subject Alternative Name costuma listar vários domínios e subdomínios do alvo. Para aprofundar, veja o que é TLS e como o HTTPS protege suas conexões.

Outros protocolos que aparecem com frequência: SMB (compartilhamento de arquivos Windows, fonte histórica de falhas graves), SSH (acesso remoto, alvo de força bruta e chaves fracas) e SMTP (e-mail, sujeito a relay aberto e enumeração de usuários).

Firewalls, NAT e por que portas "somem"

Nem tudo que você não vê está fechado. Firewalls inspecionam pacotes e podem descartá-los sem resposta, criando o estado filtered. NAT (Network Address Translation) faz vários hosts internos compartilharem um único IP público, o que mascara a topologia real.

Para o pentester, isso significa que os resultados de um scan refletem o que o firewall permite ver, não necessariamente a realidade interna. Técnicas como variar flags TCP, usar fragmentação ou scanear via UDP existem justamente para sondar como esses dispositivos reagem. O padrão PTES (PTES Team, 2014) reforça que a interpretação correta desses resultados — e não apenas a coleta — é o que diferencia um teste profissional de um scan automatizado cego.

Há também os IDS/IPS (sistemas de detecção e prevenção de intrusão), que observam padrões de tráfego e podem bloquear ou alertar quando detectam um scan agressivo. Por isso, o ritmo (timing) do scan importa: varreduras lentas e fragmentadas são mais furtivas, enquanto um scan barulhento à velocidade máxima acende todos os alarmes. Em engajamentos furtivos (red team), controlar esse ritmo é parte do ofício.

Colocando tudo junto: do pacote ao plano de ataque

Na prática, os fundamentos de rede se encadeiam assim durante um engajamento:

Cada passo depende do anterior, e todos dependem de você entender o que está acontecendo no nível do pacote. Um exemplo de como esse encadeamento aparece em comandos reais:

# 1-2. Descoberta de hosts vivos numa faixa
nmap -sn 192.168.1.0/24

# 3. SYN scan rápido nas portas mais comuns dos hosts ativos
nmap -sS --top-ports 100 192.168.1.0/24

# 4. Detecção de serviço e versão nas portas encontradas
nmap -sV -p 22,80,443 192.168.1.10

Repare que cada comando consome a saída do anterior: você não escaneia versões de portas que ainda não sabe se existem. Essa disciplina de afunilar — do amplo e barato para o específico e caro — é o que mantém o teste eficiente.

Erros comuns de quem está começando

Perguntas frequentes

Preciso decorar todas as portas? Não. Decore as 15 a 20 mais comuns, que cobrem a esmagadora maioria dos casos, e consulte uma referência para o resto. O importante é reconhecer rapidamente os serviços de alto valor (SSH, SMB, RDP, bancos de dados) quando aparecem.

TCP ou UDP primeiro? Comece pelo TCP, que é mais rápido e cobre a maior parte da superfície web. Faça o UDP em paralelo ou em seguida, focado em portas-chave (53, 161, 123, 500), já que um scan UDP completo é proibitivamente lento.

Por que minha porta aparece como filtered em vez de open ou closed? Porque algo no caminho — tipicamente um firewall — descartou o seu pacote silenciosamente, sem enviar nem o SYN/ACK (aberta) nem o RST (fechada). A ausência de resposta é a assinatura de filtragem.

Wireshark serve para quê num pentest? Para enxergar o que realmente trafega. Quando um scan dá resultado estranho, capturar os pacotes mostra exatamente o que foi enviado e recebido, dissipando suposições. É também a melhor ferramenta para aprender protocolos, vendo os cabeçalhos de verdade em vez de só ler sobre eles.

Conclusão

Redes não são um detalhe técnico opcional para o pentester — são a linguagem em que todo o teste acontece. Dominar TCP/IP, a diferença entre TCP e UDP, o mapa de portas e os protocolos de aplicação transforma resultados crípticos de ferramentas em decisões claras de ataque. Some a isso a leitura de banners, a consciência sobre firewalls e ritmo, e a disciplina de afunilar do amplo para o específico, e você deixa de ser alguém que aponta ferramentas para se tornar alguém que entende alvos. Com essa base sólida, você está pronto para avançar para o scanning com Nmap e aplicar esse conhecimento dentro de uma metodologia de pentest estruturada. Estude os fundamentos primeiro; as ferramentas farão muito mais sentido depois.

Referências