Said website is a GitLab repo without a release artifact in sight, so I guess “downloadable” means you can download the source code, compile it yourself, and figure out how to set it up on your own.
Sure makes it easy to join...
The authors of the tools they use may try to implement honeypot detection, but that's fruitless cat & mouse game, and to what end?
Assuming "honeypot" based on latency is a fool's errand because many legitimate things can induce latency.
Bots doing initial discovery won't figure it out. I have the same bots trying to log into my SFTP server today that have been trying for years. It's not even a honeypot. I literally create accounts for all the bots with a null password in hopes they one day upload something neat.
It's fairly difficult to detect a well-made honeypot.
>even just detect latency from their connection being proxied elsewhere
Not if the attacker is legitimately placed far away from you. Also, from my experience these bots have very large timeouts set.
Honeypots are high maintenance, or easy detectable.
Better example (disclaimer, I might have had something to do with this when it was being developed) is the DT Honeypot initiative.
Website: https://sicherheitstacho.eu/start/main
Code (Deutsche Telekom AG Honeypot Project on 01 Apr 2019): https://dtag-dev-sec.github.io/
Providers like Crowdstrike https://www.crowdstrike.com/ already aggregate results of malware scans for customers.
This is different because it is National CSIRT of the Czech Republic and because it is a honeypot, it will let the attacker use more commands.
Some of the comments here around usability echo our early customer feedback very much - which is why we want to be as smooth on the plug and play side as possible.
Won't they see the packets hopping to other devices via a command like 'traceroute'?
