Netcat – All you need to know | Hacker News Reader

Netcat – All you need to know

blog.ikuamike.io

351 pointstodsacerdoti45 comments

nmap not only comes with ncat, but with nping, which I used to find incredibly useful for troubleshooting when I was a network engineer. Especially with load balancing, wccp, and other things that change routes based on port. I think it was based on a program called hping, but I haven't really followed that world in a while.

Besides quickly transferring files, which is mentioned in the article, one of the most useful things I've done with netcat was when the company's cloud-based IM+email service went down and everyone in the office couldn't send messages to each other despite being in the same network. After some brief in-person discussion we used netcats for IM, and it worked quite well.

Wouldn't it have been easier to use another cloud-based service such as Slack?

No, because netcat requires no signup, no "support", no "updates", no license, no fees. It is not closed source and there is no third party company such as "Slack" that needs to be involved in private communication. Netcat is a small, fast, open source program that is easy to compile on any UNIX-like OS. Whereas IRC, and presumably Slack, requires at least two programs, a server and a client, netcat requires only one.

Bash has a /dev/tcp/$host/$port pseudo device which covers almost all use cases of Netcat just in case your machine has no Netcat installed.

I still don't understand why such a device/file is not shipped with Unix/Linux by default so it would work with any shell or program.

Good for clients, but bash can't do a listen socket. Gawk can, though it's pretty limited.

Because Linux didn't copy everything from Plan9. Unfortunately.

I wonder how hard it would be to write kernel modules to fix that.

aux/listen on Linux world? What's next? purging NFS for 9p and wireguard?

WSL uses 9p, though it seems to be a bit slow in that area.

Are you sure this is a Bash feature and not some kernel module?

It definitely is a bash feature. From the bash manpage:

       Bash handles several filenames specially when they are used in redirections, as described in the following table.  If the operating system on which bash is running provides these spe‐
       cial files, bash will use them; otherwise it will emulate them internally with the behavior described below.

              /dev/fd/fd
                     If fd is a valid integer, file descriptor fd is duplicated.
              /dev/stdin
                     File descriptor 0 is duplicated.
              /dev/stdout
                     File descriptor 1 is duplicated.
              /dev/stderr
                     File descriptor 2 is duplicated.
              /dev/tcp/host/port
                     If host is a valid hostname or Internet address, and port is an integer port number or service name, bash attempts to open the corresponding TCP socket.
              /dev/udp/host/port
                     If host is a valid hostname or Internet address, and port is an integer port number or service name, bash attempts to open the corresponding UDP socket.

It just seems confusing that bash is using the /dev namespace for this feature.

Are there circumstances where /dev/tcp/host/port might be provided by the operating system and provide the same functionality? Or is that just saying bash will stay out of the way if you are trying to access special files in /dev if they really exist?

/dev/std{in,out,err} are provided by Linux, and bash does stay out of the way there. I'm not aware of anything that provides /dev/tcp/host/port, although I think Plan 9 might have something similar. If the file happens to exist, bash will use the file rather than its own special functionality.

The old TLI/XTI alternatives to BSD sockets (pre when BSD sockets were standardized into POSIX sockets) back in the System V days provided this path/socket connection format. For a modern holdover these are still available in Solaris.

Unless the operating system decides to use bash to access some device, it's fine.

Nothing besides bash can see these. They're not really there. It's a mirage created by bash.

That’s the problem.

> Netcat having being initially written to be used on linux the variants are linux based

uh, what? the original netcat was a Unix program, not linux specefic. I don't think GNU netcat is linux specific either. And the OpenBSD variant, as its name suggests was originally written for OpenBSD, although it was ported to Linux later.

There is also a netcat inside busybox, and the Windows port from frippery.org implements it.

The busybox netcat doesn't set off all the malware alarms on my corporate desktop.

    C:\Temp>\bin\busybox64 nc 1.2.3.4 21
    220 (vsFTPd 2.0.5)
    quit
    221 Goodbye.

The Windows port is not very smart compared to the rest of the netcat family (the Linux x86-64 version has more of the common options).

    C:\Temp>\bin\busybox64 nc
    BusyBox v1.32.0-FRP-3445-g10e14d5eb (2020-04-11 10:50:47 BST) multi-call binary

    Usage: nc [-l] [-p PORT] [IPADDR PORT]

    Open a pipe to IP:PORT

        -l      Listen mode, for inbound connects
        -p PORT Local port

Yeah, that was funny to me too.

Older makefiles had targets for Ultrix, Nextstep, and even Unixware :)

https://sourceforge.net/p/nc110/git/ci/v1.10/tree/Makefile

Hobbit wrote netcat in 1995:

https://seclists.org/bugtraq/1995/Oct/28

I think they just wrote Linux to substitute for UNIX in general, as the only UNIX (derivative) that matters.

For younger devs, it's all Linux (vs Windows/MacOS/etc).

UNIX and its variants is some distant history, like Multics or VMS was to 90s devs. Even FreeBSD is some niche thing they'll seldom, if ever, encounter (much less install).

Heck, 20-something year old devs still hadn't reach puberty when SUN still mattered and was a thing.

No. Stop. There is no excuse for not knowing one’s history. Especially when making a factual claim like “X was written for Y.”

There doesn't need to be an excuse. It's enough that it's a reality. People do stuff and don't wait us to excuse them before doing them.

Um. MacOS?

If you mean "well macOS is a UNIX too", yes.

I don't mean younger devs don't use Macs.

But for younger devs it's Linux that comes to mind when the context is UNIX-like environment, not the Mac (even though the first is not a UNIX, as it doesn't come from the old UNIX code lineage, and the latter is a certified UNIX).

So, they could easily slip and say "netcat or vi was written originally for Linux" (while meaning "for UNIX") versus saying "netcat or vi was written originally for macOS" (which nobody would ever slip and say).

I think nc works out of the box in MacOS also.

More importantly, is that a figlet font simulating dripping ink? Cause it's freaking cool.

To future googlers, the font is Bloody.flf

Get it here: https://github.com/xero/figlet-fonts

Need to include that into my next command line tool.

[OpenBSD Netcat] "In addition to those enhancements it is compiled to remove a feature that is considered a gaping security hole of the application."

I wonder what feature this was? The site doesn't elaborate.

Edit: Ah I saw the thing about the -e later on but I didn't think that was it as indeed it's not really a security hole imo. Rather just a tool.

-c and -e. They're not security holes, they're useful features which like most powerful tools can be misused or abused.

The post does a poor job explaining it, but the term "gaping security hole" comes from traditional netcat's source code. In order to enable the "-e" (exec) flag, it must be compiled with "-DGAPING_SECURITY_HOLE".

I believe the reason they are called "gaping security holes" is that if nc is installed as setuid root, they allow local privilege escalation (see https://serverfault.com/questions/237584/netcat-e-the-gaping..., https://nc110.sourceforge.io/). Another explanation is that they make it trivial to create reverse shells etc. (though it is still possible to create reverse shells without -e/-c, for example using named pipes).

Ah yeah it was the security hole description that threw me off. I was expecting something more along the lines of a buffer overflow.

The article definitely did elaborate, but not as much as I would have liked.

The feature is the -e option, which is used (among other things) for reverse shells.

no mention of socat?

Indeed. Nor any mention of the busybox netcat.

busybox, a great program, but something about it's netcat will hang at the end of sending data, rather than closing the socket and exiting. Because of that I have to ^C it, and then wonder if it fully sent the last block of data.

For decades now I've used minimal rescue environments and "netcat" to copy data around. A lot of these rescue environments, especially 20 years ago, were pretty minimal. I liked being able to use the RedHat or Fedora install media as rescue, because I always had it handy.

So I fell back to this habit of, I know Python is on this system (RedHat installer), so I made a few versions of a python "netcat" program. A bigger one with more features, in case I was able to "wget" a file. Or smaller "in" and "out" programs that I could comfortably type in by hand.

But I really need to get into the habit of using socat now. I had it in mind that it's hard to remember how to use, so I'd just wget my python version and be done with it. But I need to get in the habit. socat is SO powerful.

Beware, Ubuntu 20.04 has version with a bug in TLS-based "file copy" socat usage. https://bugs.launchpad.net/ubuntu/+source/socat/+bug/1936407

Simple fix is to just "dpkg -i" the 18.04 or 21.04 .deb file, there don't seem to be any strange dependencies.

Don't forget the venerable websocat for testing and scripting websockets!

https://github.com/vi/websocat

Such a useful tool when the need arises, lifesaver.

This. So much this.

I mean, netcat as a tool still isn't as known as it deserves to be (at least in the circles I frequent), but socat deserves it even more. Along with a few other unix-y tools (sponge, for example), I really cannot understand why it isn't pre-installed everywhere.

Yeah, socat is my go-to for tcp socket scripting.

How timely. Just today I had to install netcat on my new workstation (I chose the gnu version) in order to test connectivity to an SMTP server. It was super helpful just to see the raw response from the server. Apparently GoDaddy blocks all outbound 3rd party SMTP connections... ugh.

netcat is a very useful tool, but for SMTP testing you might enjoy "swaks":

http://web.archive.org/web/20180304190350/https://debian-adm...

oh swaks seems nice. Thanks

Never trust something foolishly titled “All you need to know”

Reply on news.ycombinator.com