SoylentNews is people
SoylentNews
Software engineer Chris Wellons writes about tar-pitting nefarious SSH probes. Anyone with a publicly-facing SSH server knows that it is probed from the moment it is turned on. Usually, the overwhelming majority of incoming connection attempts are malevolent in nature. There are several ways to deal with these attempts, one method is to drag out the response for as long as possible.
This program opens a socket and pretends to be an SSH server. However, it actually just ties up SSH clients with false promises indefinitely — or at least until the client eventually gives up. After cloning the repository, here’s how you can try it out for yourself (default port 2222):
[...] Your SSH client will hang there and wait for at least several days before finally giving up. Like a mammoth in the La Brea Tar Pits, it got itself stuck and can’t get itself out. As I write, my Internet-facing SSH tarpit currently has 27 clients trapped in it. A few of these have been connected for weeks. In one particular spike it had 1,378 clients trapped at once, lasting about 20 hours.
(Score: 2, Interesting) by DannyB on Monday March 25 2019, @01:57PM (14 children)
So I assume that this cannot run along side a real SSL implementation on your system?
Eg, real SSL and tarpit SSL are mutually exclusive?
The lower I set my standards the more accomplishments I have.
(Score: 2, Informative) by Anonymous Coward on Monday March 25 2019, @02:25PM (2 children)
Literally has nothing to do with SSL. SSH is a tool for logging in remotely to your machine in order to control it. SSL is a protocol for validating the trustworthyness of a server and establishing an encrypted connection.
As for it living along side proper SSH, yes it should be fine. Just move SSH off to some random port that only you know and have the tarpit running on port 22.
There is an earlier comment about possibly running out of descriptors, this is true. You could run out of descriptors using this tool and thereby be unable to connect to your own machine even with SSH off on some other port. So exercise caution.
Best solution is to disable SSH password auth and switch over to using key based auth only. Do this and SSH will instantly deny anyone trying to connect who doesn't have the proper key to do so. But the tarpit is an amusing toy to mess with script kiddies.
I used to allow auth with any username and password combo, then have it pipe all input to /dev/null and pipe /dev/random to the offender. Fun times!
(Score: 2) by DannyB on Monday March 25 2019, @03:12PM
Yes, you're right.
Not enough caffeine yet. I meant SSH. I wrote SSL.
The lower I set my standards the more accomplishments I have.
(Score: 3, Interesting) by DannyB on Monday March 25 2019, @03:13PM
I also am aware that it is possible to have both SSH and SSL on the same port.
SSLH – Share A Same Port For HTTPS, SSH, And OpenVPN
https://www.ostechnix.com/sslh-share-port-https-ssh/ [ostechnix.com]
Applicative Protocol Multiplexer (e.g. share SSH and HTTPS on the same port)
https://github.com/yrutschle/sslh [github.com]
sslh – A ssl/ssh multiplexer
http://www.rutschle.net/tech/sslh/README.html [rutschle.net]
SSLH: A SSL/SSH Multiplexer for Linux
https://www.unixmen.com/sslh-a-sslssh-multiplexer-for-linux/ [unixmen.com]
(See also: Proxytunnel)
The lower I set my standards the more accomplishments I have.
(Score: 2) by FatPhil on Monday March 25 2019, @02:33PM (8 children)
My firewall NATs 6 machines, so I just have a bank of ports 222x, one forwarded to sshd on each machine, and so this tarpit on 22 would work for me - it could be forwarded to the unimportant RasPi that doesn't run any other services. However, I use fail2ban on all the machines anyway, so I'm mostly safe from idiotic probes, this is mostly a kind of vaccination to protect others by limitting the number of attacks that can take place on the population as a whole.
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 5, Interesting) by canopic jug on Monday March 25 2019, @02:45PM (1 child)
If you use fail2ban or sshguard, you could maybe use the triggered firewall rule to route the bot to an interal port running the tar pit. Normal connections would pass through to the SSH daemon, as expected, but offending IP addresses would get routed internally to somewhere else.
Money is not free speech. Elections should not be auctions.
(Score: 2) by DannyB on Monday March 25 2019, @03:17PM
I like that approach.
The lower I set my standards the more accomplishments I have.
(Score: 3, Insightful) by DannyB on Monday March 25 2019, @03:17PM (3 children)
Sorry I wrote SSL when I meant SSH.
For SSH, I have one forwarded to a non standard port in the 3xxx range. I could forward more as you describe.
I suppose then the standard SSH port could run the tarpit.
But it would be really cool to be able to mix the tarpit with a real SSH implementation if that were possible to allow a real login to proceed.
Or another approach: something like fail2ban could redirect certain 'ssh visitors' to the tarpit once it is clear that they are nothing but a brute force attack.
The lower I set my standards the more accomplishments I have.
(Score: 2) by FatPhil on Monday March 25 2019, @03:42PM (2 children)
I did plan to write a lightweight fail2ban replacement at some point (installed size half a meg? for something that just calls notify/poll and matches a few regexps and optionally calls some scripts, that sounds like bloat to me), I'll remember to consider that kind of option when I do.
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 2) by canopic jug on Monday March 25 2019, @03:50PM (1 child)
If your needs are not complex, then the replacement can be quite short. I have one which is less than 10 lines of AWK. Though it depends on probes making specific errors, it seems to get nearly all of them quickly. I should connect it to a tar pit maybe but would want to re-write the tar pit in perl so that I don't have to add python to the mix. It looks simple enough to try.
Money is not free speech. Elections should not be auctions.
(Score: 2) by RS3 on Monday March 25 2019, @06:22PM
Some years ago I had tried fail2ban and either had trouble getting it to work or just considered it too complicated. Too many years to remember.
Have any of you tried "pam shield"?
(Score: 3, Informative) by NateMich on Monday March 25 2019, @06:00PM (1 child)
Stop using port numbers with "22" in them. Those are targeting by scans almost as much as the actual ssh port, 22 is. Trust me. Be random.
(Score: 3, Informative) by maxwell demon on Monday March 25 2019, @07:37PM
So if you've got a reason to have a real sshd on port 22, it might be a good idea to tarpit all the other ports with "22" in their number?
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by canopic jug on Monday March 25 2019, @02:36PM (1 child)
This for SSH, not SSL. As to runing both a normal SSH server and a tar pit on the same port, it might be possible to do some kind of multiplexing with sslh [github.com]. But I don't think so. Off the top of my head I'd have to say I'm not sure how it could work since both an attack and a legitimate log would be using the same start of the same protocol. Remember, this tar pit kicks in long before the encryption is even negotiated.
As mentioned by the AC, putting them on different ports definitely works.
Money is not free speech. Elections should not be auctions.
(Score: 2) by DannyB on Monday March 25 2019, @03:14PM
Sorry not enough caffeine when I wrote SSL when I meant SSH.
Yes it is possible to have SSL and SSH on the same port, see my reply a few up above.
The lower I set my standards the more accomplishments I have.