Golang works well for this application because it can easily cope with very large numbers of idle goroutines.
What the author may be missing is that golang also works well for bots and scanners, for exactly the same reason. Attackers' time isn't being "wasted" by this, their goroutines are just sitting idle for longer.
I think it still works. You have two scenarios where the attacker is efficiently using goroutines; (1) you also use goroutines or (2) you do not. In the latter, the attack is more expensive for you.
Another detail is that an attacker with many idle connections to your host might not instantiate any new ones.
Of course, in the scenarios where the attacker is not using goroutines then you have the upper hand as well.
This isn't a real ssh server, so the "cost" to you of the attack isn't really relevant. You can choose not to run this software at all, and the additional cost to you is zero.
Though for a large amount of HTTP bots, the authors don't even bother changing the default Python User-Agent. I'd assume a large proportion of these bots still can't run concurrently.
The original endlessh hints at this, but doesn't go further into details, and the endlessh-go's README doesn't mention it at all. Am I suppose to have endlessh run on port 22 and then have my real SSH server run on an obscure port? In none of the examples does it run on port 22. I feel like I'm missing something obvious, that the READMEs simply take for granted I know.
I run endlessh on the port 2222 and I configured fail2ban to redirect the source ip addresses who did X failed attempts from the dest port 22 to the dest port 2222 transparently.
I use the table NAT and prerouting to achieve that, you can use ipset to match the source ip addresses.
Isn't the point of a honeypot that it's not a real server? What guarantees are there that there won't be an exploit that allows escaping the honeypot into the real data? Personally, I do not believe anything is 100% secure. So inviting the vampire into your facade home, and then getting upset when the vampire sees the charade and walks into your real home is just one of those "well of course that happened" situations.
if you use port knocking, the first hit on your honeypot, can be the trigger to lockdown or redirect, a lot of other ports to somewhere away from your actual.
But they don't scan every port. I've been running my SSH server on a non-standard port for a long time, it took four years until I had the first bot with login attempts. About a year ago I changed the port and haven't seen any bots since then.
The more targeted/sophisticated ones will, but there's a crapload of bots that just scan all publicly addressable IPs for port 22 and attempt to connect. If your goal is to trap as many bots as possible in the tarpit, you'll get a lot more if you run on port 22.
Following the SSH hardening guide stops 99% of bots and scanners because they can't negotiate a cipher using whatever ancient ones their SSH implementation is set up to use.
This, and a handful of simple firewall rules in the raw table can block about 90%+ of that remaining 1% just looking at the spoofable banner that none of the bots seem to spoof I assume due to being lazy like me.
In the raw table:
-A PREROUTING -i eth0 -p tcp -m tcp --dport 22 -d [my server ip] -m string --string "SSH-2.0-libssh" --algo bm --from 10 --to 60 -j DROP
-A PREROUTING -i eth0 -p tcp -m tcp --dport 22 -d [my server ip] -m string --string "SSH-2.0-Go" --algo bm --from 10 --to 60 -j DROP
-A PREROUTING -i eth0 -p tcp -m tcp --dport 22 -d [my server ip] -m string --string "SSH-2.0-JSCH" --algo bm --from 10 --to 60 -j DROP
-A PREROUTING -i eth0 -p tcp -m tcp --dport 22 -d [my server ip] -m string --string "SSH-2.0-Gany" --algo bm --from 10 --to 60 -j DROP
-A PREROUTING -i eth0 -p tcp -m tcp --dport 22 -d [my server ip] -m string --string "ZGrab" --algo bm --from 10 --to 60 -j DROP
-A PREROUTING -i eth0 -p tcp -m tcp --dport 22 -d [my server ip] -m string --string "MGLNDD" --algo bm --from 10 --to 60 -j DROP
-A PREROUTING -i eth0 -p tcp -m tcp --dport 22 -d [my server ip] -m string --string "amiko" --algo bm --from 10 --to 60 -j DROP
Adding the server IP minimizes risks of also blocking outbound connections as raw is stateless
I rarely do this any more given they rotate through so many LTE IP's. Instead I get the bot operators to block me by leaving SSH on port 22 and then giving them a really long VersionAdendum that seems to get the bots feeling broken, sticky and confused. There are far fewer SSH bot operators than it appears. They will still show up in the logs but that can be filtered out using drop patterns in rsyslog.
VersionAddendum " just put in a really long sentence in sshd_config that is at least 320 characters or more"
Try it out on a test box that you have console access to just in case your client is old enough to choke on it. Optionally use offensive words for the bots that log things to public websites. Only do this on your hobby nodes, not corporate owned nodes unless legal is cool with it, in writing.
I don't know if this is still the case, but -m string used to be resource intensive, because it has to parse each packet for the string before passing it on to other rules.
Endlessh periodically sends data so the read timeout won't trigger. Specifically, it draws out the crypto negotiation stage indefinitely by exploiting a feature of the SSH protocol.
(Of course, the bot author could detect that behaviour too.)
You're understanding perfectly. The way this works is that it sends a slow drip of junk before the SSH version banner string. A scanner running at any real scale is going to have an overall timeout beyond which it doesn't bother waiting any longer for the banner string.
This is going to very slightly irritate some of the extremely low-level actors. Is setting up a tool to do that a good use of time?
If you want to effectively deter attackers using a sand-trap approach, you need to find some kind of task with asymmetric cost in your favour. This isn't that.
At the same time it's much easier to write code that just died the bare minimum. Imagine you're a bot herder, if your bot net consists of stolen CPU cycles what difference does it make if your bots are slowed down. It doesn't cost you money.
> if your bot net consists of stolen CPU cycles what difference does it make if your bots are slowed down. It doesn't cost you money.
This is wrong. It does cost you money - either directly, because you paid money to use someone else's botnet, or as an opportunity cost, in that you can't use your bots on as many targets.
Funny but my first thought wasn't wasting their time at all, that's easily fixed with a few code adjustments on their client end. My thought was to harvest their IPs and publish them in blocklists.
I think you could employ the same tactics that advanced fuzzers do with these tarpits: then mutate the responses randomly, to try get "new" responses from the attackers, instead of new coverage in the code as in the fuzzer. Unless they are using static scripts, which would be boring.
I have understood that most attacks are super-simple sort of, so probably not much to learn there. But an interesting project!
Readit News
What the author may be missing is that golang also works well for bots and scanners, for exactly the same reason. Attackers' time isn't being "wasted" by this, their goroutines are just sitting idle for longer.
Another detail is that an attacker with many idle connections to your host might not instantiate any new ones.
Of course, in the scenarios where the attacker is not using goroutines then you have the upper hand as well.
In over 10 years I've never had a single probe on that port with ssh.
In the raw table:
Adding the server IP minimizes risks of also blocking outbound connections as raw is statelessI rarely do this any more given they rotate through so many LTE IP's. Instead I get the bot operators to block me by leaving SSH on port 22 and then giving them a really long VersionAdendum that seems to get the bots feeling broken, sticky and confused. There are far fewer SSH bot operators than it appears. They will still show up in the logs but that can be filtered out using drop patterns in rsyslog.
Try it out on a test box that you have console access to just in case your client is old enough to choke on it. Optionally use offensive words for the bots that log things to public websites. Only do this on your hobby nodes, not corporate owned nodes unless legal is cool with it, in writing.Or am I misunderstanding this?
(Of course, the bot author could detect that behaviour too.)
There's more info from the author of Endlessh: https://nullprogram.com/blog/2019/03/22/
This is going to very slightly irritate some of the extremely low-level actors. Is setting up a tool to do that a good use of time?
If you want to effectively deter attackers using a sand-trap approach, you need to find some kind of task with asymmetric cost in your favour. This isn't that.
At the same time it's much easier to write code that just died the bare minimum. Imagine you're a bot herder, if your bot net consists of stolen CPU cycles what difference does it make if your bots are slowed down. It doesn't cost you money.
This is wrong. It does cost you money - either directly, because you paid money to use someone else's botnet, or as an opportunity cost, in that you can't use your bots on as many targets.
Deleted Comment
Please do, it would mean good karma.
I have understood that most attacks are super-simple sort of, so probably not much to learn there. But an interesting project!