Interacción manual con servicios

La detección automática propone un protocolo. La interacción manual comprueba qué bytes acepta el servicio, qué responde antes de autenticar y qué cambia cuando se negocia TLS o se envía un hostname. No consiste en teclear comandos al azar: cada petición debe responder una pregunta.

Esta página usa Ncat, la implementación de Netcat distribuida por el proyecto Nmap. Otros binarios llamados nc pueden ser OpenBSD netcat, GNU netcat, BusyBox o una variante del sistema. Sus opciones no son intercambiables. Comprueba primero ncat --version y nc -h.

-n evita que Ncat resuelva nombres. -v muestra información de conexión. El destino y el puerto son los dos últimos argumentos:

ncat -nv TARGET_IP PORT

Una conexión aceptada demuestra que el three-way handshake terminó desde esa posición. No identifica todavía el protocolo. Un cierre inmediato puede deberse a un servicio que espera TLS, a una ACL de aplicación, a un límite de conexiones o a un protocolo binario que rechaza texto.

UDP no establece una sesión equivalente. -u envía datagramas y la ausencia de respuesta conserva la incertidumbre:

printf 'PAYLOAD' | ncat -nvu TARGET_IP PORT

El payload debe pertenecer al protocolo. Un datagrama vacío o arbitrario puede no producir respuesta aunque el servicio esté disponible.

Algunos servicios envían una línea nada más aceptar la conexión. FTP, SMTP, POP3, IMAP y SSH son ejemplos habituales. Guarda la respuesta original:

ncat -nv TARGET_IP PORT | tee evidence/banner-TARGET-PORT.txt

El producto puede ocultar, modificar o falsear ese texto. Un balanceador también puede presentar un banner distinto del backend. Utilízalo para elegir la siguiente interacción, no como identificación definitiva.

Los protocolos de texto suelen terminar cada línea con CRLF. -C convierte los saltos de línea enviados por Ncat al formato \r\n:

printf 'COMMAND ARGUMENT\n' | ncat -nvC TARGET_IP PORT

Una tubería cierra la entrada al terminar printf. Algunos servidores responderán y cerrarán. Otros mantendrán la conexión y Ncat esperará. Añade al payload el comando de cierre propio del protocolo cuando exista.

-w SECONDS limita cuánto espera Ncat al establecer la conexión. -i SECONDS cierra después de ese periodo sin lecturas ni escrituras. El primer timeout acota la apertura. El segundo evita que un diálogo ya abierto quede bloqueado, aunque también puede cortar respuestas lentas:

printf 'COMMAND ARGUMENT\nQUIT\n' |
  ncat -nvC -w 5 -i 10 TARGET_IP PORT \
  | tee evidence/session.txt

--send-only cierra después de terminar la entrada y evita esperar datos. --recv-only impide enviar. Se usan cuando esa dirección corresponde al protocolo y a la pregunta. Un banner puede recogerse sin transmitir payload:

ncat -nv -w 10 --recv-only TARGET_IP PORT \
  | tee evidence/banner.txt

Ncat también puede conectar mediante un proxy. --proxy fija el endpoint y --proxy-type distingue http, socks4 y socks5:

ncat -nv -w 10 \
  --proxy PROXY_IP:PROXY_PORT \
  --proxy-type socks5 \
  TARGET_IP PORT

El proxy cambia origen, resolución y ruta. Una conexión que funciona por SOCKS5 y falla directamente describe dos posiciones distintas. Registra también si el proxy resuelve el hostname o recibe una dirección.

--ssl activa TLS desde el comienzo de la conexión. Esta forma corresponde a servicios como HTTPS o IMAPS, no a protocolos que empiezan en texto y ascienden mediante STARTTLS:

ncat -nvC --ssl FQDN PORT

Ncat cifra la conexión, pero no verifica el certificado por defecto. --sdoc-verify valida la cadena y el nombre cuando se conecta mediante el hostname esperado:

ncat -vC --ssl --sdoc-verify FQDN PORT

Conectar por IP puede fallar si el certificado solo contiene el FQDN. Ese fallo no demuestra que TLS esté roto. Registra el nombre utilizado, SNI, cadena, hostname esperado y resultado de la validación.

openssl s_client muestra más detalle de la negociación. -connect fija el destino y -servername envía SNI. -showcerts solicita que OpenSSL muestre la lista de certificados enviada por el servidor, no una cadena ya validada:

openssl s_client \
  -connect FQDN:PORT \
  -servername FQDN \
  -showcerts

Para STARTTLS, -starttls debe recibir el nombre del protocolo compatible:

openssl s_client \
  -connect FQDN:PORT \
  -servername FQDN \
  -starttls PROTOCOL \
  -showcerts

OpenSSL puede completar el handshake y aun mostrar un error de verificación. Separa siempre cuatro hechos: el servidor habló TLS, qué versión y cipher se negociaron, qué cadena presentó y si esa cadena validó contra el nombre y las autoridades de confianza.

-verify_return_error hace que un fallo de validación termine la negociación en vez de continuar con fines diagnósticos. -state muestra transiciones internas y -msg vuelca los mensajes del protocolo TLS. Se activan sobre un caso reducido porque el output crece con rapidez:

openssl s_client \
  -connect FQDN:PORT \
  -servername FQDN \
  -showcerts \
  -verify_return_error \
  -state \
  -msg 2>evidence/tls-debug.txt

El fichero puede contener certificados, mensajes TLS y datos suficientes para identificar la sesión. -keylogfile FILE conserva secretos de sesión en un formato que permite descifrar una captura compatible. Es material sensible y solo se activa cuando el descifrado forma parte del diagnóstico:

openssl s_client \
  -connect FQDN:PORT \
  -servername FQDN \
  -keylogfile evidence/tls.keys

Protege tls.keys con permisos restrictivos y elimínalo cuando termine el análisis. Su contenido permite descifrar esa sesión si también se dispone del tráfico.

SMB, TDS, Oracle TNS, RDP, IPMI y buena parte de SNMP no se enumeran escribiendo texto en Netcat. Ncat sigue siendo útil para confirmar TCP, TLS o un cierre, pero la siguiente petición necesita un cliente o un probe válido.

--hex-dump FILE conserva los datos enviados y recibidos en hexadecimal:

ncat -nv --hex-dump evidence/session.hex TARGET_IP PORT

Sin un payload válido, el dump solo documenta el comportamiento inicial. No sustituye Wireshark, tcpdump ni el analizador del protocolo.

La interacción manual y la automatización se complementan:

Si una herramienta devuelve «sin resultados», registra qué petición hizo. A partir de ahí se puede distinguir falta de respuesta, respuesta que la herramienta no pudo interpretar, autenticación insuficiente, limitación de frecuencia o una función que el servidor no implementa.

Conserva el comando, versión de herramienta, origen, destino, hora, bytes relevantes y código de salida. Una sesión manual puede quedar registrada como conexión, error de protocolo, negociación TLS, comando o autenticación.

No dejes sesiones abiertas ni archivos temporales. Si la interacción modificó estado, registra el objeto creado y verifica su retirada desde el mismo protocolo.

• Ncat Users’ Guide
• OpenBSD nc manual
• Ncat: SSL
• Ncat: Output Options
• OpenSSL 3.6: s_client