Netcat is a nifty tool to have for diagnosing or testing connections.

While telnet is more ubiquitous, it's not really suitable for communication that's not purely ASCII based, as it could mangle the data due to it being designed for the RFC 854 "Telnet" protocol. Netcat however, it's primarily a clean 8-bit TCP (and optionally, UDP) connection tool for the commandline.

Netcat is also relatively commonly found in many systems. Even if it's not as common as telnet, it's still more easily found than other tools such as socat. So it's still useful to be familiar with it.

See here for the manual page: https://man.openbsd.org/nc.1

Note that the traditional netcat command is nc, which is not to be confused with ncat, a rewrite as part of the larger nmap toolset, which although compatible with nc parameters, adds a bunch of extra functionality.

Testing / troubleshooting the connection to a service

Note that by default netcat will attempt to stablish a TCP connection, if you want to test a UDP service, add the -u option as additional parameter.

Below an example on how to execute a test for the HTTP connection to a server.

# request http://man.openbsd.org/nc.1 via netcat
printf "GET /nc.1 HTTP/1.1\r\nHost: man.openbsd.org\r\n\r\n" | nc man.openbsd.org 80

You won't be able to make proper requests for protocols that use a SSL/TLS encryption layer (such as HTTPS). If you need to do that you might however consider alternatively using the ncat tool (included with nmap) that does offer a --ssl option for it.

printf 'GET /nc.1 HTTP/1.1\r\nHost: man.openbsd.org\r\n\r\n' | ncat --ssl man.openbsd.org 443

Port Scanning

Netcat is also useful for simple and quick scanning where nmap or similar more advanced tools aren't available.

We can even provide a port range, as in the example below:

nc -z -v 192.168.178.1 20-443 2>&1 | grep succeeded

This will skip the "Connection refused" errors and show only the connections that succeded. With the -z option no data will be sent (and instead it would simply stablish, then close, the connection).

Transferring files (or general data) through arbitrary ports

This of course would require the connection to be reachable on both ends (ie. it might not work through a firewall).

It relies on a listening port being open on the receiving end through netcat, being piped to tar or similar tools that can decode and unpack the data into a file structure.

# Receiving end
nc -l 5555 | tar xzvf -

On the sending device, we can pipe the output of the tar tool (to pack the folder or file) to netcat that would be stablish connection to the given receiving IP (or domain, if configured) using the port that we previously set as listening.

tar czvf - /path/to/dir | nc receiving-host.com 5555

Netcat Port Forwarding

Many implementations of Netcat also support forwarding requests through multiple netcat processes, as a form of proxy or relay node.

Listener-to-Listener Netcat Proxying

# Listener-to-Listener Proxy
nc -l -p 2222 0<mypipe | nc -l -p my_test_host.com 443 | tee mypipe

Listener-to-Client Netcat Proxying

# Listener to Client Proxy
nc -l -p 8080 0<mypipe | nc my_test_host.com 80 | tee mypipe

Client-to-Client Netcat Proxying

# Client to Client Proxy
nc host_1 port_1 0<mypipe | nc host_2 port_2 | tee mypipe