Years back, I moved sshd onto a non-standard port. It was one of the best things I ever did. Hack attempts went from more than I cared to count per hour and day, to zero.
This ssh tarpit seems like a fantastic idea to slow down bad people even more. Awesome project and submission.
I always wondered… This is a cute thing to do, but I never really bothered even changing the SSH port on my servers after the first one or two I set up. I can see all of the failed logins on the logs, but it doesn’t seem worth trying to mitigate. I already switch to pubkey-only auth with my custom username and disable root login entirely as the first thing to do on server setup, so nobody should be getting in. I suppose sshd may not be perfect, but it’s probably some of the most well-tested software in the world at preventing unauthorized logins, and I haven’t lost any servers yet.
I agree, i don’t see the point on changing port either, if some is looking to get in they can just nmap and test all the ports in no time at all. Security through obscurity is never good. Set it up properly in the first place.
The major benefit of a different port is that now every entry in the auth log is targeted, not the result of somebody running a password dump over the entire Internet. That’s information which is both useful, and impossible to extract from from a default-port auth log.
A minor benefit is that SSH isn’t spending your server’s resources evaluating and rejecting undirected blanket attacks.
(I still run my SSH server on the default port. I don’t find either of those benefits worth keeping track of the alternate port—222? 2222?—or the extra typing to put it in the SSH command.)
One could perhaps argue that then you have to carry your ssh config around with you, but if you’re connecting from a system without your ssh config you probably don’t have a known_hosts entry for it either, and a host key fingerprint hash is a lot more to remember than a port number.
This is cute! I was concerned that sending random lines would slowly siphon off entropy but it looks like the “random” values are actually generated by a small PRNG seeded with the program’s startup time.
I was thinking it’d be fun to send silly song lyrics or something…
We’re no strangers to love
[…ten seconds of silence…]
You know the rules
[…ten more seconds…]
And so do I
[etc.]
Unlikely to be seen very often (if ever), but could perhaps provide a mild auto-trolling of a bot operator in the event they happen to notice and investigate. Or if not, at least we have computers reciting poetry to each other, which, aesthetically, I like.
I agree. If a bot is smart enough to recognize that it’s just receiving “hello world” over and over again, it’s probably also smart enough to give up after ten minutes if it hasn’t received the SSH- line.
There is no such thing as ‘siphoning off entropy’ [sic]; this idea is a remnant of 90s-era crypto thinking (and is why Linux’s random subsystem is so broken). Once you have a single random 256-bit value, you can generate effectively infinite (2^256) unpredictable values from it as:
That’s within a few orders of magnitude as many random values as there are particles in the universe. If you really care, you can use 512 bits and have many, many more orders of magnitude more values than there are particles in the universe. There’s no reason to worry about ‘using up’ entropy.
This is a pretty good idea! It reminds me of spamd, which does the same for SMTP.
Instead of sending bunch of random bytes, it waits a lot between each character.
That could be another way to trap attackers with ssh
Years back, I moved sshd onto a non-standard port. It was one of the best things I ever did. Hack attempts went from more than I cared to count per hour and day, to zero.
This ssh tarpit seems like a fantastic idea to slow down bad people even more. Awesome project and submission.
I was thinking coroutines would be a perfect fit for this, and sure enough Python’s asyncio was mentioned at the end! Anyway, nice idea.
I always wondered… This is a cute thing to do, but I never really bothered even changing the SSH port on my servers after the first one or two I set up. I can see all of the failed logins on the logs, but it doesn’t seem worth trying to mitigate. I already switch to pubkey-only auth with my custom username and disable root login entirely as the first thing to do on server setup, so nobody should be getting in. I suppose sshd may not be perfect, but it’s probably some of the most well-tested software in the world at preventing unauthorized logins, and I haven’t lost any servers yet.
I agree, i don’t see the point on changing port either, if some is looking to get in they can just nmap and test all the ports in no time at all. Security through obscurity is never good. Set it up properly in the first place.
The major benefit of a different port is that now every entry in the auth log is targeted, not the result of somebody running a password dump over the entire Internet. That’s information which is both useful, and impossible to extract from from a default-port auth log.
A minor benefit is that SSH isn’t spending your server’s resources evaluating and rejecting undirected blanket attacks.
(I still run my SSH server on the default port. I don’t find either of those benefits worth keeping track of the alternate port—222? 2222?—or the extra typing to put it in the SSH command.)
One could perhaps argue that then you have to carry your ssh config around with you, but if you’re connecting from a system without your ssh config you probably don’t have a known_hosts entry for it either, and a host key fingerprint hash is a lot more to remember than a port number.
This is cute! I was concerned that sending random lines would slowly siphon off entropy but it looks like the “random” values are actually generated by a small PRNG seeded with the program’s startup time.
Does it even need to be random? Seems like it could just send “<insert expletives here>” over and over as long as it doesn’t start with “SSH-”
I was thinking it’d be fun to send silly song lyrics or something…
We’re no strangers to love
[…ten seconds of silence…]
You know the rules
[…ten more seconds…]
And so do I
[etc.]
Unlikely to be seen very often (if ever), but could perhaps provide a mild auto-trolling of a bot operator in the event they happen to notice and investigate. Or if not, at least we have computers reciting poetry to each other, which, aesthetically, I like.
Welp guess I’m writing up a tiny server impl then. Would be fun for a CTF maybe…
Thanks for the idea! I used this weekend to write a golang implementation that will do just that: https://github.com/magikid/gosshtar.
I agree. If a bot is smart enough to recognize that it’s just receiving “hello world” over and over again, it’s probably also smart enough to give up after ten minutes if it hasn’t received the
SSH-line.There is no such thing as ‘siphoning off entropy’ [sic]; this idea is a remnant of 90s-era crypto thinking (and is why Linux’s random subsystem is so broken). Once you have a single random 256-bit value, you can generate effectively infinite (2^256) unpredictable values from it as:
That’s within a few orders of magnitude as many random values as there are particles in the universe. If you really care, you can use 512 bits and have many, many more orders of magnitude more values than there are particles in the universe. There’s no reason to worry about ‘using up’ entropy.
This is a pretty good idea! It reminds me of spamd, which does the same for SMTP. Instead of sending bunch of random bytes, it waits a lot between each character. That could be another way to trap attackers with ssh