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.
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.
But the bots can easily detect these, cant they? As long as there is a timeout on socket read, this shouldn't waste that much of the scanners time.
Or am I misunderstanding this?
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!
For other usecases there is an ipfilter target TARPIT, that does a similar thing on the TCP level.
But why? Just hide your ssh port. And port knock in. Or put it @ tor/wg/whatever.
Does it matter, though? You can easily scan out the correct SSH port.
> Unfortunately the wonderful original C implementation of endlessh only provides text based log, but I do not like the solution that writes extra scripts to parse the log outputs, then exports the results to a dashboard, because it would introduce extra layers in my current setup and it would depend on the format of the text log file rather than some structured data. Thus I create this golang implementation of endlessh to export Prometheus metrics and a Grafana dashboard to visualize them.
" I didn't like the logging, so I re-implemented the entire thing."
I'm not mocking, I just see this often (and have done it myself!). It's interesting the things we do to get around the little things we don't like.
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.