Nmap no siempre envía el paquete que cree que ha pedido. Cuando los sockets raw no están disponibles, sustituye el escaneo SYN predeterminado por un escaneo TCP connect, así que una ejecución como usuario normal y otra con sudo pueden responder preguntas distintas sobre el mismo puerto. Los resultados parecen un problema de permisos, y normalmente son un cambio de método. Hacer explícito el método es la única forma de comparar ambas ejecuciones.

Dos sondeos, un puerto, rutas de código distintas

Un escaneo SYN construye la cabecera TCP por sí mismo, la envía desde un socket raw y lee la respuesta de la red antes de que la pila TCP del núcleo registre siquiera una conexión completada. Un escaneo connect pide al sistema operativo que abra un socket ordinario e informa de lo que devuelve connect(). Ambos pueden calificar un puerto como abierto, pero solo uno deja un intento semiableierto y solo uno está sujeto a la política de nivel de socket asociada al proceso emisor.

La ruta raw necesita CAP_NET_RAW, y por eso el escaneo predeterminado se degrada en silencio cuando falta esa capacidad. La propia referencia de técnicas de escaneo de Nmap documenta la sustitución: el escaneo connect es el recurso porque no necesita ningún privilegio especial. El cambio ocurre sin aviso en la mayoría de las ejecuciones, y eso es lo que lo hace tan fácil de malinterpretar. Una vez sabe que el recurso existe, “abierto como root, cerrado como usuario” deja de sonar a fallo de permisos y empieza a sonar a dos mediciones distintas.

Qué cambia realmente sudo en el escaneo

Elevar los privilegios restaura la ruta del socket raw, y eso cambia más que el veredicto. La selección del puerto de origen, el tiempo de los paquetes, el comportamiento de retransmisión y la forma de clasificar una respuesta filtrada vienen todos de código distinto. Un equipo intermedio que limita la tasa de SYN trata las dos ejecuciones de forma desigual incluso cuando el host de destino es idéntico.

El registro en el lado del destino también diverge. Un handshake completado es visible para el servicio y para cualquier contabilidad de sockets, mientras que un sondeo semiableierto reiniciado a menudo no lo es. Si compara ejecuciones contra un host cuyos registros también lee, parte de la diferencia que observa es la propia observación.

Mantenga el método constante en ambas ejecuciones

Fuerce la misma técnica en ambas invocaciones y la comparación empieza a significar algo. El indicador -sT solicita explícitamente el escaneo connect, -Pn elimina el descubrimiento de hosts, -n elimina la resolución de nombres y un único -p elimina las diferencias de lista de puertos.

nmap -sT -Pn -n -p 8443 198.51.100.77
sudo nmap -sT -Pn -n -p 8443 198.51.100.77

Cambie la dirección y el puerto por un host que tenga autorización para probar; el rango de documentación de arriba es un marcador, no un objetivo. Si las dos ejecuciones ahora coinciden, la diferencia original venía del método de escaneo. Si siguen sin coincidir, algo más está clasificando el tráfico, y la sección siguiente es donde mirar.

El contexto de la cuenta no es solo un indicador de privilegios

Un despliegue de VPN puede clasificar paquetes por UID, por cgroup o por una regla asociada al proceso que abrió el socket. Entonces el tráfico de root y el del usuario salen por tablas de enrutamiento distintas o chocan con conjuntos de reglas distintos, y ninguna disciplina de método de escaneo los concilia.

Inspeccione la política en lugar del privilegio. En Linux, nftables lo expresa con meta skuid e iptables con la coincidencia de propietario, y cualquiera de los dos puede enviar un solo UID por un túnel mientras el otro sigue usando la ruta física predeterminada.

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 el sondeo antes de comparar resultados

Antes de sacar conclusiones, demuestre qué sondeo se ejecutó. Nmap nombra la técnica en su propia salida, y --reason añade la evidencia tras cada estado, que es la parte que le dice si un handshake se completó realmente.

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

Dos ejecuciones que informan del mismo estado por razones distintas no son una contradicción, y dos ejecuciones que informan de estados distintos por la misma razón apuntan al enrutamiento o a la política, no al escaneo. Mantenga idénticos el destino, el puerto, el espacio de nombres y el tiempo, y luego cambie una variable cada vez. Ejecutar el servicio como root no es la reparación de una discrepancia de política; la reparación es expresar la política deseada mediante el propietario del servicio.

Artículos relacionados