Por que uma varredura de portas muda quando é executada com sudo
Quando os sockets raw não estão disponíveis, o Nmap troca silenciosamente a varredura SYN por uma varredura TCP connect, então root e um usuário comum medem caminhos diferentes.
O Nmap nem sempre envia o pacote que você acha que pediu. Quando os sockets raw não estão disponíveis, ele substitui a varredura SYN padrão por uma varredura TCP connect, então uma execução como usuário comum e outra com sudo podem responder a perguntas diferentes sobre a mesma porta. Os resultados parecem um problema de permissões, e normalmente são uma mudança de método. Tornar o método explícito é a única forma de comparar as duas execuções.
Duas sondas, uma porta, caminhos de código diferentes
Uma varredura SYN constrói o cabeçalho TCP sozinha, envia-o de um socket raw e lê a resposta da rede antes que a pilha TCP do kernel registre uma conexão concluída. Uma varredura connect pede ao sistema operacional para abrir um socket comum e relata o que connect() retorna. Ambas podem rotular uma porta como aberta, mas só uma deixa uma tentativa meio aberta e só uma está sujeita à política de nível de socket ligada ao processo emissor.
O caminho raw exige CAP_NET_RAW, e é por isso que a varredura padrão degrada em silêncio quando essa capacidade falta. A própria referência de técnicas de varredura do Nmap documenta a substituição: a varredura connect é o recurso porque não exige nenhum privilégio especial. A troca acontece sem aviso na maioria das execuções, e é isso que a torna tão fácil de interpretar errado. Depois que você sabe que o recurso existe, “aberta como root, fechada como usuário” deixa de soar como um bug de permissões e começa a soar como duas medições diferentes.
O que o sudo realmente muda na varredura
Elevar os privilégios restaura o caminho do socket raw, e isso muda mais do que o veredito. A escolha da porta de origem, o tempo dos pacotes, o comportamento de retransmissão e a forma de classificar uma resposta filtrada vêm todos de código diferente. Um equipamento intermediário que limita a taxa de SYN trata as duas execuções de forma desigual mesmo quando o host de destino é idêntico.
O registro no lado do destino também diverge. Um handshake concluído é visível para o serviço e para qualquer contabilidade de sockets, enquanto uma sonda meio aberta reiniciada muitas vezes não é. Se você compara execuções contra um host cujos logs também lê, parte da diferença que observa é a própria observação.
Mantenha o método constante nas duas execuções
Force a mesma técnica nas duas invocações e a comparação começa a significar algo. A flag -sT pede explicitamente a varredura connect, -Pn remove a descoberta de hosts, -n remove a resolução de nomes, e um único -p remove diferenças na lista de portas.
nmap -sT -Pn -n -p 8443 198.51.100.77
sudo nmap -sT -Pn -n -p 8443 198.51.100.77
Troque o endereço e a porta por um host que você tem autorização para testar; o intervalo de documentação acima é um exemplo, não um alvo. Se as duas execuções agora concordam, a diferença original vinha do método de varredura. Se ainda discordam, algo mais está classificando o tráfego, e a próxima seção é onde olhar.
O contexto da conta não é apenas um sinalizador de privilégios
Uma implantação de VPN pode classificar pacotes por UID, por cgroup ou por uma regra associada ao processo que abriu o socket. Então o tráfego de root e o do usuário saem por tabelas de roteamento diferentes ou atingem conjuntos de regras diferentes, e nenhuma disciplina de método de varredura os reconcilia.
Inspecione a política em vez do privilégio. No Linux, o nftables expressa isso com meta skuid e o iptables com a correspondência de proprietário, e qualquer um dos dois pode enviar um único UID por um túnel enquanto o outro continua usando a rota física padrão.
sudo nft list ruleset | grep -n skuid
sudo iptables-save | grep -n uid-owner
ip rule show
ip route get 198.51.100.77
Confirme a sonda antes de comparar resultados
Antes de tirar conclusões, prove qual sonda foi executada. O Nmap nomeia a técnica na própria saída, e --reason acrescenta a evidência por trás de cada estado, que é a parte que lhe diz se um handshake realmente foi concluído.
nmap --reason -sT -Pn -n -p 8443 198.51.100.77
sudo nmap --reason -sS -Pn -n -p 8443 198.51.100.77
getcap "$(command -v nmap)"
capsh --print | grep -i net_raw
Duas execuções que relatam o mesmo estado por razões diferentes não são uma contradição, e duas execuções que relatam estados diferentes pela mesma razão apontam para o roteamento ou a política, não para a varredura. Mantenha destino, porta, espaço de nomes e tempo idênticos, e depois mude uma variável por vez. Executar o serviço como root não é a reparação de uma divergência de política; a reparação é expressar a política pretendida através do proprietário do serviço.