Netcat: reading and writing over the network — diagnostics, data transfer, tunnels

Netcat (nc) reads and writes data over TCP and UDP connections. With one small utility it’s convenient to check a port, grab a service banner, transfer a file between machines, or create a temporary tunnel. Below — typical tasks.

There are several implementations of Netcat, and their flags differ. By default installed are:

• OpenBSD netcat — in Debian and Ubuntu (package netcat-openbsd), Fedora, Arch, Alpine. Examples below are for it;
• traditional (GNU) netcat — the old implementation, it has a -e flag to run a program on the connection, which the OpenBSD version lacks;
• Ncat from the Nmap package — a separate implementation with TLS, proxy support and handling multiple clients.

Check your version: nc -h outputs the list of supported flags.

Checking ports and services

ping uses only ICMP and doesn’t tell if the specific port is open. Netcat checks the actual connection:

nc -zv -w 3 example.ru 80 443 22

• -z — just check the connection, do not send data;
• -v — verbose output;
• -w 3 — timeout 3 seconds.

Grab a service banner — send a request and read the response:

printf 'HEAD / HTTP/1.0

' | nc -w 3 example.ru 80

Transferring files between machines

When you don’t have scp or rsync at hand. On the receiving side:

nc -l -p 9899 > backup.iso

On the sending side:

nc 192.0.2.10 9899 < backup.iso

Netcat does not encrypt data or verify integrity, so use this method only within a trusted network. For large files data is compressed on the fly:

# receive
nc -l -p 9899 | gzip -dc > backup.iso
# send
gzip -c backup.iso | nc 192.0.2.10 9899

After transfer, verify the checksum (sha256sum) on both sides.

Temporary TCP tunnel

You can forward a local port to an internal service using a named pipe:

mkfifo /tmp/backpipe
nc -l 8080 < /tmp/backpipe | nc db.internal 5432 > /tmp/backpipe

Now connections to local port 8080 go to the internal PostgreSQL. This is a one-off unencrypted solution for debugging; for persistent access use an SSH tunnel or VPN.

When netcat isn’t enough

• Ncat (package nmap) — TLS, proxy, multiple clients simultaneously, flag --exec;
• socat — bidirectional transfer between almost any sources (sockets, files, devices, TLS), syntax is more complex.

sudo apt install nmap socat

How to defend against netcat in the wrong hands

The same properties make netcat an attacker tool: having gained access to a server, an attacker can open an outbound connection to bypass an incoming firewall. What reduces the risk:

• Filter outgoing traffic. By default a server is allowed to make any outgoing connections. Allow only the necessary directions and block the rest — a reverse connection to an arbitrary port will not succeed:

# only DNS, HTTP and HTTPS out, everything else — deny
ufw default deny outgoing
ufw allow out 53
ufw allow out 80
ufw allow out 443

• Don’t keep netcat, compilers and unnecessary interpreters on a production server — their absence makes persistence harder.
• Watch for unexpected processes and connections. An outgoing connection from nc, bash or sh to an external address is a reason for concern:

ss -tnp | grep -E 'nc|bash|sh'

• Set up auditing. An auditd rule notes creation of named pipes (mkfifo, mknod) — a typical indicator of a reverse shell without the -e flag:

auditctl -a always,exit -F arch=b64 -S mknod -S mknodat -k reverse_shell

Host-based detection systems (auditd with ready rules, Falco, EDR) detect such attacks comprehensively — they see suspicious combinations like “shell process + network connection”. An outbound firewall and a minimal set of software on the server mitigate the simplest scenarios.

Summary

Netcat moves bytes from stdin to the network and back, so it composes well with ordinary shell commands — gzip, dd, pipes. It’s enough for checking ports, one-off file transfer and quick tunneling; for encryption and persistent services use Ncat, socat, SSH or a VPN.

Sources:

• man nc — OpenBSD
• Ncat Reference Guide