Are tarpits still of use these days? I sort of figured that even modern script mass attackers have gotten professionalized and sophisticated enough that they can deal with trivial timeouts and the like. I could see actual honeypots still being of use for researchers or blue teams at organizations that are real targets, and ML might even open up some interesting new ways to make those more engaging for longer. But a tarpit doesn't seem like it'd cause bother for drive-by or APT, the former are all about volume so if something takes more than a few seconds just skip it (and maybe flag it as a tarpit for punishment) and an APT will instantly recognize it too.<p>For individuals and smaller orgs I've sort of felt like keeping your head down, running a wg/ssh bastion with a non-standard port maybe along with single packet auth or even plain old port knocking to reduce log spam from random drive-by is more effective and attainable for places without any sort of dedicated security or even constant in-house IT staff. Running a tarpit on a VPS seems like it'd fail to bother most these days, and running it on an actual IP seems like at best it'd have no effect and at worst if it ever actually held up a scanner and the operator noticed they might decide to direct some actual attention to that IP, or at least throw a mild ddos at it for a bit. Am I wrong or out of date on that? I'm all for sticking it to bad actors and efforts to reduce the economic incentives, but in 2020 tarpits strike me as kind of obsolete with some risk to boot.
Reminds me of the dungeon I built for web crawlers to have fun collecting email addresses at <a href="https://darkwiiplayer.com/bot-dungeon" rel="nofollow">https://darkwiiplayer.com/bot-dungeon</a> xD
I'm sure this was fun to put together and it seems like it's fun for people to talk about, but you can put this along with fail2ban, port knocking, and nonstandard SSH ports in the back of the attic and just (1) turn off password authentication entirely and (2) put SSH behind WireGuard. Even if you don't do step (2), step (1) eliminates the rationale for all the silly stuff people do to obfuscate their SSH installs.
discussion of a blog post about this tool:
<a href="https://news.ycombinator.com/item?id=19465967" rel="nofollow">https://news.ycombinator.com/item?id=19465967</a>
One I made in async Rust: <a href="https://github.com/Freaky/tarssh" rel="nofollow">https://github.com/Freaky/tarssh</a><p>I currently have 22 clients stuck it in across three machines. When I started out it was more like a thousand, so seems they've largely adapted.
I have to admit that I tried this and it was rather lackluster. Log output:<p><a href="https://pastebin.com/4FTHRF3f" rel="nofollow">https://pastebin.com/4FTHRF3f</a><p>Not a lot of activity over the time I ran it, and I know that the port gets hit more than that. I had a much better time when I ran a honeypot with Kippo:<p><a href="https://github.com/desaster/kippo" rel="nofollow">https://github.com/desaster/kippo</a><p>It was much more useful as it gave me a great list of IP's to block from all my systems ;)
The tarpit approach is a double-edged sword. Sure, you're keeping some script kiddie's machine locked up (maybe), but you're also keeping socket connections open and wasting resources on the machine they are targeting. A much more efficient approach is using fail2ban and a firewall to just drop traffic from offenders.
Hah, I love endlessh.... been running it for a few years now on one of my digital ocean droplets. Better to fuck with these bots. My personal record was somewhere around 23 days having one stuck.
What got my inspired here is, if a simple delay strategy can make attack harder, why not add this as a common feature in SSH?<p>It can be called "Initial Connection Delay": Once a new TCP connection is established, wait for an uncertain number of n seconds before read and respond to the handshake request.
One of the simplest ways to block unwanted connections is to filter on client id. I haven't seen anyone willing to change it even though I've blocked libssh, sshgo, and paprika.<p>Of course, this functionality is only available in non-standard SSH servers such as the one from Bitvise.
This is like a self-administered "slow lori attack" then - making it easier for an attacker to keep connections up until things start getting tight on port 443.
This would have been fun to put onto production machines. We had a botnet that was running ssh bruteforce with 10s requests per second with unique IPs. It stopped after we disabled password auth.