Everyone in my company talks about wp-login brute force, Wordfence, Sucuri, fail2ban to protect our customer servers. All of them are all great tools for protecting the door … unless you have broken windows. All these tools only see port 80/443 and they don’t care about the other 65,000 ports on your server. What caused me to add honey traps that fully block bad guys? One of my wordpress customers installed redis to check some speed improvements. Instead of talking to us, they decided to do some testing so they used some AI tool that installed a passwordless redis. A “lucky” probe found it and the hacker executed RCE. All those in just a few minutes that their test lasted! By the time we discovered it, it was too late. Rootkit was installed and my team had to spend a lot of time wiping out the whole server and recovering from backups. The speed of the hack was amazing, but this is what you can expect from automated probes with nasty payloads. No amount of tools can beat misconfigurations and honest mistakes. I am a firm believer of processes: you can fix a process you can’t fix a person (especially developers). That’s why I decided to create the tarpit for our own use. Tarpit is effectively a personal honeypot. But instead of collecting information from attackers (not very useful to my customers) it does something else: it opens a bunch of ports that usually host legitimate software (like redis, mysql, postgres, irc, telnet, etc). When something connects to these ports, it gives you a realistic prompt and expects a reply. Then the fun starts: firstly, it delays the response… 3 seconds per character. If they’re unlucky enough to hit our honey trap, we might as well waste as much of the probe’s time as possible. Every second they spend stuck in our fake service, is a second they are not using to hit someone else (even if we don’t own the servers). Secondly, the moment they disconnect, the local firewall (whatever is available based on OS: win, mac and linux) grabs their IP and blocks them from all the services on that server for 24 hours (auto-clear). Thirdly, it shows on the dashboard map where the attack originated and keeps all the attack data. Finally, in cases where someone owns many servers (like in our case), the attack IP is propagated to all our fleet of servers: a bad IP is a bad IP - so they will never be able to hit anything else anywhere on our “micro universe”. Looking at that, I thought: I bet more people might need this and it gave me the idea of a saas product: tarpit.pro - democratization of honeypot for server protection. There is an AI layer that proposes permanent bans depending on various patterns. After running it on 5 servers for 20 days, the numbers speak for themselves: ~40k attacks, ~14k unique IPs, ~5k auto-banned. SSH gets hammered the most (14k hits), then Telnet (yes, Telnet in 2026: 3.2k hits), then SMB…. Top source countries: US, China, UK, Hong Kong, Netherlands (I’m really surprised from this list, I was expecting a completely different mix). Most tried passwords: 123456, admin, password, foobared, the same Redis default that started this whole story. The first attack showed up 90 seconds after going live. If you want to see what's hitting your servers: tarpit.pro . We offer a usable free tier for 2 servers - free forever including a web dashboard. You can use the code LAUNCH100 that will allow you to test the Pro for up to 4 servers for a month, so you can play with firewall rule propagation and all the other nice features of Pro. Templates let you quickly answer FAQs or store snippets for re-use. as well , this person and/or