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, 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.
People today are educated enough to repeat what they are taught but not to question what they are taught.
(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)
People today are educated enough to repeat what they are taught but not to question what they are taught.