But, there is a downside.
The downside is any site you put it on will be flagged and attacked 100x more since it registers as a vulnerable destination. After turning it off, the deluge of attacks for the site continues and I ended-up rigging a fail2ban setup to just deny if a destination port is hit. (See >> https://mergy.org/2019/08/setting-up-a-killswitch-for-attack...)
But, it is fun and interesting to see. Highly recommend but know the legacy on that as well.
For a while, I gathered attempted usernames. I created accounts for all the usernames, set a null password on my chroot sftp server. I was really hoping they would try to upload something interesting. Nope. If they can't get a standard shell, they just keep retrying in a loop, forever. I've had the same bots hitting my server every few minutes for several years. No harm, no foul, I let them have at it.
Before you get too excited, I would say that a common mistake of inexperienced sysadmins is assuming all those brute-force attempts in the logs are results of those "hackers" and "crackers", it's not, not even a scriptkid.
All you can get by running a honeypot, like this one, is pretty boring activities by soulless, ancient worms and viruses, or automatic global Internet scanners running 24x7, not humans. Most of those are not even worth your time to block (e.g. if you only use strong password or pubkey, there are few reasons to fail2ban).
It's nothing personal. Any machine will be port scanned, vuln probed, brute forced, blindly hit with ancient "1 shot" exploits (e.g. ?file=../../../etc/passwd ). This is how the Internet works.
Another lesson is: never run any unsecured webserver/service on the public Internet, never ever, not even for debugging, period. Don't listen 0.0.0.0:80 if you have just installed your PHP management system, don't reset your forgotten MySQL password by disabling privilege checking before turning off networking first, if you just installed a new VPS with root password 123456 in a morning, don't wait until afternoon, change it immediately, etc.
The reason is exact the opposite, not because of "hackers" but those stupid worms. Ordinary life is boring: if you run a webserver with password 123456 (e.g. for debugging an issue on a disposable server - just for 20 minutes, you think, then you forgot it), you won't (or unlikely) to see someone hacking into your system, but it's a certainty that one of those stupid worms/viruses would infect your machine within hours, sometimes it's as quick as having your lunch. And it probably won't do much damage, but you would spend your time to reinstall the system again...
Don't use passwords. Disable passwords. It's tempting to say "Oh we'll require 20 character long random strings, it'll be fine". If you've dotted every I and crossed every T that would work, but such passwords aren't memorable so they're no better than a private key - you'll need to store them somewhere and make sure to generate them properly, you might as well use keys.
More often something will go wrong. Maybe it will be a local policy failure. "Oh I didn't realise devops needed those goofy passwords too, I thought that was just the backend team - we've been setting them all to pass1234, should I change them or is it too late now?". Maybe it will be in the password checking code, as it has happened way too often already on a broad spectrum of operating systems. Just use pubkey auth everywhere all the time.
But I have to agree with you, the suggestion "use strong password" itself is prone to failures, thus bad, and should be avoided.
/etc/docker/daemon.json (check your OS, for Mac use the GUI)
"ip" : "127.0.0.1"
On the other hand, don't lock your users up because of perceived notions of end-user privacy and security. (See for example how badly a certain famous browser named after a metal blocked adblockers)
Not disagreeing with you at all, I'm all for strict TLS defaults, just ranting about the fact that so many restrictions meant for control and domination are marketed as "security", it hurts the public support of actual security. Many people I've read online cannot distinguish Google's push of secure TLS and Google's push of artificial control, one decided to run the website on plaintext HTTP diehardly. And many others still see ALL hardware security modules as evil DRM / mandatory code-signing scheme. How unfortunate it is, even more unfortunate is that their estimation has a better chance to be correct.
Rarely did I ever get an interactive shell show someone trying to move through the process. When I did, it was fun to watch. I would say automated 1-2 sec script attacks outnumbered human logins 1000 to 1.
After writing my own honeypot to get up to speed with some SSH details and satisfy curiosity I was kind of disappointed by that fact tbh. Though I expected the level of automation and boring stuff, I let a similar fake environment run for weeks in the hope of some human "coming back" for details but it honestly did not reveal more exciting information than you get from honeypots that make their data public.
Nobody else ever got to see the forced little ncurses chat I've built in to talk to the human on the other side, shutting that down was not the happiest of moments. But yeah, fun to watch it was.
On the other hand, I heard that running sandboxes to obtain the latest samples of IoT viruses and tracking their evolution is fun.
It doesn't help too much, but I generally move even my SSH port and tunnel everything not meant to be public through that, or over a full VPN. It's a shame that you have to do this now.
This is why Ubuntu's "ease of setup" policy of listening on interfaces with things running on installation is such a poor choice. It may not be terrible on a workstation, but it's awful on servers.
 Actually, it is.
Turns out, it only got infested with x86 malware (as far as I can tell anyways) - None of which worked on rasppi, obviously. Various malwares attempted to connect, and once they succeeded, they uploaded their payload, and repeatedly tried (without success) to run it.
Also hilarious: Various attacks tried to write to the same file location, resulting in neither of the payloads being successful. `mktemp` is your friend kids.
When I stopped working there, they were still assigning everything an ipv4 address, no firewall. Great for running game servers in dorms, not as great for getting your printer hacked.
YOU ARE STANDING AT THE END OF A ROAD BEFORE A SMALL BRICK BUILDING.
AROUND YOU IS A FOREST. A SMALL STREAM FLOWS OUT OF THE BUILDING AND
DOWN A GULLY.
In a year and a half I had logged over a million probes. No humans at all. I would have known because they would have typed something to do with the game or tried to play it. So I must conclude no one is checking the logs of the worms either.
If he had his telnet service return something that looked interesting (and no, not Crowther & Woods interesting), then he'd have a lot of people connecting.
There is great value in the doggedly determined engineering of yesteryear, and there are some among the young who continue to carry the torch. Check this out if you have not seen it,
Apollo Guidance Computer Restoration
One downside to running software like cowrie is that generally speaking crawlers like shodan will be able to figure out that you are running a honeypot, and will have you fingerprinted in a hurry.
A better strategy for increasing the cost of an attack is actually implementing something i read about on HN called a ssh tarpit, where one can "hang" an incoming ssh connection indefinitely. A lot of the attacks on honeypots are automated, so instead of having a 3 second attack, one can waste the attackers time for about 30s to 1m on average as these scripts have very generous timeouts (and sometimes no timeouts at all).
I have endlessh running on my internet-facing server. Here's the current suckers:
I think all those have stayed connected for some days. But a lot scanners don't fall for it anymore. Since July 17th, I've had 60868 ssh connections, mean 195.817 sec, median 19.124 sec, max 886283.605 sec. The distribution is skewed much shorter than 10 days, however. Half the connections last less than 20 seconds, by eye around 15. 25% of the connections last between 30 and 40 seconds, and about 10% last around 50 seconds.
Interesting, like slow request attacks in reverse? Is that actually useful for something? It seems like that would just needlessly burn resources on your end. The majority of attacks on my instance seem to have come from other infected routers/devices/etc. that pretty much perform these attacks for free.
You might have a point, and maybe i should try to turn these subjective feelings into harder metrics in terms of cost, but we have figured at this point it has a net good. If we slow the scanning down by a magnitude, in my opinion its a good thing!
I've been running honey pots or tar pits for years out of a belief that anyone who can has an ethical duty to do so, to slow down the attacks on those who can't.
In my experience, honeypots and tarpits are not the same sort of thing, and fufill different goals. Tarpits get you more utilitarian good, honeypots get you more representative threat intel.
To illustrate: I've been giving the people that staff robocaller's "service centers" a hard time for years. I believe that my phone number is in some of their systems as a "bad actor" - I've occasionally heard an audible, computer-generated voice telling the "service rep" that this is a known troublesome number. They also occasionally hang up on me a sentence in to the script. I usually tell them I'm Edward Snowden, but you can call me Ed. That gets a hangup maybe 5% of the time. So giving them a hard time wastes their resources enough that at least a few boiler room/"service centers" put effort towards avoiding me, and the few others like me. What proportion of resource-wasters would it take to make them quit?
Didn‘t know you visit HN - I‘m a great fan of your book!
Just curious about what these look like
About the only interesting thing I've seen on mine was login attempts using a single compromised key instead of the old brigade of admin/admin password attempts. Although I guess that might just be some known backdoor of some popular network equipment that I was not aware of at the time.
Toying around was exactly my plan. See if any interesting sessions show up. I have a couple ideas like trying to automatically group or classify them but there are way too many things on my "would be cool to try" todo list already..