Neat little project to needle some of the botters a bit (though I assume they'll all evolve to recognize this fairly quickly). I'd echo tyingq's comment below though:<p><i>Any tarpit has the potential to piss someone off. I'd run it on a sacrificial server with no obvious way to tie back to who is running it.</i><p>Yeah, just speculating but at least from what I've seen in the past if you successfully tarpit some script kiddie and they notice the IP their scan got stuck on there is some potential to move from "one of a billion random lowest common denominator bulk scan targets" to "paid attention to specifically some minimal amount", which is a genuinely different scenario. Even if all that amounts to is a relatively low volume revenge DDOS pointed at you for a bit it's still more of a disruption then if the auto scan had just moved on without seeing anything of note in the first place. This looks like fun on some systems, but on anything real I'm inclined to just stick to cutting down on log spam via single packet auth or a port knocker or the like. The old outrun-the-hiker-not-the-bear aphorism fits a lot of cases, just something to keep in mind before implementing something like this if you aren't directly experimenting with more active reactions.<p>Conversely as a research project I'm now actually curious what sort of extra attention even something like this could attract. Maybe these days everyone would just adapt and move on instead and the above is all obsolete?
I like this! It's tiny, simple, yet effective.<p><pre><code> 2019-03-22T19:54:06.303Z ACCEPT host=::ffff:196.52.43.xx port=50327 fd=4 n=1/4096
2019-03-22T19:54:38.838Z CLOSE host=::ffff:196.52.43.xx port=50327 fd=4 time=32.535 bytes=199
2019-03-22T19:57:12.008Z ACCEPT host=::ffff:141.98.81.xx port=53646 fd=4 n=1/4096
2019-03-22T19:57:21.118Z CLOSE host=::ffff:141.98.81.xx port=53646 fd=4 time=9.110 bytes=30
</code></pre>
The 141 bot never stays longer than 5 seconds. I'm guessing they are using 'expect' and waiting 5 seconds for a particular string.<p>The only thing missing is setting some glibc hardening options<p><pre><code> RELRO STACK CANARY NX PIE RPATH RUNPATH FORTIFY Fortified Fortifiable FILE
Partial RELRO No canary found NX enabled No PIE No RPATH No RUNPATH No 0 8 ./endlessh
</code></pre>
I modified one line in the Makefile<p><pre><code> CFLAGS = -std=c99 -Wall -Wextra -Wno-missing-field-initializers -D_FORTIFY_SOURCE=2 -O2 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -ftrapv -s -g -Wl,-z,relro,-z,now -Wl,-z,noexecstack -pipe -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -fstack-clash-protection --param ssp-buffer-size=4 -fPIE -pie -m64 -mtune=generic
</code></pre>
It's better now<p><pre><code> RELRO STACK CANARY NX PIE RPATH RUNPATH FORTIFY Fortified Fortifiable FILE
Full RELRO Canary found NX enabled PIE enabled No RPATH No RUNPATH Yes 3 4 ./endlessh</code></pre>
This is the Internet equivalent of keeping phone scammers on the line by not just refusing to hang up, but actively interacting with them until they hang up (search YouTube for "tech support scammer trolling" for some entertainment...)<p>That said, I'm a little confused even after reading the linked RFC paragraph; it claims "The primary use of this feature is to allow TCP-wrappers to display an error message before disconnecting." but I'm not familiar with that term and there are no other occurrences of the word "wrapper" in that document.<p><i>Firefox and Chrome will spin on that server for hours before giving up.</i><p>For a web browser, this behaviour makes a lot of sense: timeouts are usually based on "I've waited for X and haven't received anything", not "this connection is like collecting water from a dripping tap". As long as there is a slow but steady stream of content coming in, you wouldn't want to abort until the user gives up or an internal limit on the data collected is hit (which is probably what happened with the author's tests --- a quick search doesn't yield the maximum size of the response headers browsers will accept, but servers usually have a configurable limit of a few KB at most for the request headers alone.)
I opened up port 22 once so that it connected (without crypto) and issued the phrase,<p>YOU ARE STANDING AT THE END OF A ROAD BEFORE A SMALL BRICK BUILDING.
AROUND YOU IS A FOREST. A SMALL STREAM FLOWS OUT OF THE BUILDING AND
DOWN A GULLY.<p>><p>and if they typed in something it would continue to play the game. After hundreds of thousands of automated SSH worm probes over several months, an actual human did connect and play the game for a few minutes! But even this triumph was short lived, they did not even play it to the end to see if something interesting might be unlocked (it would have been an invitation to contact my email address).
I haven't used it in years, but Tom Liston's "Labrea" tarpit is an interesting take on this concept: <a href="https://github.com/Hirato/LaBrea" rel="nofollow">https://github.com/Hirato/LaBrea</a><p>It listens in your unused IP space and both tar-pits scanners and creates actionable intelligence about scans against your hosts.
If you don't want to waste resources and run a separate service, you can do a very similar thing with just iptables. Look for the TARPIT target.<p>> Captures and holds incoming TCP connections using no local per-connection resources. Connections are accepted, but immediately switched to the persist state (0 byte window), in which the remote side stops sending data and asks to continue every 60-240 seconds. Attempts to close the connection are ignored, forcing the remote side to time out the connection in 12-24 minutes.
This is awesome. Like the author, I run my real SSH server on a nonstandard port. Unlike the author, I run nothing on the standard SSH port.<p>I think that I'll start running this there.
On a different note, I love this other tool he wrote: Enchive<p><a href="https://nullprogram.com/blog/2017/03/12/" rel="nofollow">https://nullprogram.com/blog/2017/03/12/</a>
Wouldn’t cycling over the lines of an ASCII middle finger be more efficient and equally as useful as generating random strings? The middle finger would fit in a few cache lines at most.
Neat little tool! Since switching to Teleport I haven't had OpenSSH listening publicly for a while, just reverse proxies. Still, I'll prob spin up a small server for this to observe the patterns and IP locations.<p>Also, don't think that posting this blog article on March 22 didn't go unnoticed :)
SSH brute-force attacks still pose a significant risk. See our related paper on SSH auditing driven by attacker's attempts here <a href="https://pmcao.github.io/caudit/" rel="nofollow">https://pmcao.github.io/caudit/</a>
I wrote one of these for HTTP: <a href="https://github.com/carlmjohnson/heffalump" rel="nofollow">https://github.com/carlmjohnson/heffalump</a>
I found that disabling password authentication makes ssh probing mostly stop.<p>Attackers that are smart enough to detect and avoid pubkey only hosts will probably easily adapt to this program.
Perhaps this could be useful if you ran it on a vast number of ports. Just running it on the one doesn't seem to make an attacker's life much more difficult.
Set this up on a server last night. In 20 hours I've got 75 connections. Took a capture of trying to connect to it from my laptop:<p><a href="https://www.cloudshark.org/captures/b64150b66908" rel="nofollow">https://www.cloudshark.org/captures/b64150b66908</a><p>IP addresses have been change to protect the innocent. This is from macOS but definitely seeing some different behavior from other clients.
Assuming you run a legit SSH server on port A and an SSH tarpit on port B. What hinders an attacker to connect to port A an B at the same time? What is the advantage having an attacker connected for weeks on port B?
I can recommend setting up a server and do extensive logging. Then watch hackers as they attempt to break in. I had a server hacked last week and today i read the logs to figure out how they did. From first discovery, trying to figure out what system they're on, to gaining a shell, and figure out how to execute stuff, gaining network access. It was better then watching an actual movie. And a humbling experience. But also entertaining, watching the struggle against my hardening and even stumbled on a bug, feeling his/her frustration. And the wow feeling when they finally got a shell.
What a wonderful opportunity to rickroll ...
to prolong detection time rot13 it
or walk through all the ciphers you can get away with.<p>cause we are never going to give you up ;)
very interesting, and useful (including newbies like me who do not appreciate the complexities and dangers of having internet-accessible IP address).<p>I wonder if security-oriented OSs like openBSD could offer something like this out of the box. So that an admin can just say enable_tarpits='yes', and it would automatically enable tarpits like this for all the currently installed packages (with some default ports).
I'm not sure I like this. How secure is it? Anything you put on port 22 is going to be attacked relentlessly. I think I'd rather have OpenSSH handling those attacks than some tarpit program that may or may not have been subjected to the audits and the trial-by-fire that OpenSSH has.