Are honeypot trap systems actually worth it on a small company server?

Seeing tens of thousands of requests a day is entirely normal; it's just automated internet-wide scanning bots. Even if you set up a honeypot, these bots will hit it and tell you what you already know: bots exist on the internet. Even for a low-interaction trap, you can't leave it on the same VLAN as your production network; you'd need a separate subnet and strict firewall rules.

Edit: asked below, I wrote the answer in the second message.

Shelve the consultant's advice for now. Changing default ports, disabling password logins in favor of key files, and setting up a basic security tool to temporarily ban failed attempts will eliminate almost all of those daily scans immediately. You can fix this in two hours at zero cost.

Out of curiosity last year, we spun up an open-source ssh honeypot on a spare server. In three days, it collected over 140k login attempts and 800 different username variations. One of our devs wasted 4 hours a week combing through useless noise. We shut it down completely after a month because it didn't give us a single actionable insight.

Did the consultant mention who's going to monitor the logs after setting up this honeypot? Do you have a security operations center to manage alerts, or are you just going to set it up and forget it? What's the point of setting a trap if you haven't budgeted for analyzing reports on a weekly basis?

totally unnecessary man... that consultant is probably just trying to sell you a template from big enterprise projects. close the ssh port to the outside world or put it behind a vpn and thats enough. you dont have enough lifetimes to read through all those logs.

A honeypot is not a defense tool it is a threat intelligence and research tool. Companies with hundreds of employees that have their own security teams use it to detect new attack vectors early on. A 12-person software company simply doesn't have the operational luxury to study attacker profiles.

The matter is quite clear. A honeypot doesn't prevent an attack, it merely documents it. What you need isn't to analyze logs, but to lock the doors. The moment you close the ports to the outside and switch to key-based authentication, all these question marks will disappear.

My questions are cleared up, thanks. Processes without records never improve, because you don't know what to fix.

Forgotten test environments are more often the entry point than live systems. Good luck with that.

If I understood correctly, you're saying: The real issue isn't the number, but what it's based on.

My perspective changed after experiencing that. anyway trying to do this alone is the most expensive way.

Trying to do this alone is the most expensive way.

Let me speak from the other side; I'm on the supplier side. An automated scan report is not the same as a penetration test.

Good luck with that.

I'll try it.

I didn't know that.

don't miss this: An untested bacup is not a backup.

when maaking a decision first look at what data you have on hand... if you post the result here it will help others too.

There is something to watch out for. Start with a small trial; don't commit to everything at once.

Just leaving this note, it might be useful.

Let me summarize what's been said so far. If the notification path is long, notifications don't arrive; missing notifications mean delayed incident detection.

Good luck with that.

We need to take it step by step. The biggest time-waster for us was not knowing who had the final say.

Just leaving this note, it might be useful.

I'll argue the opposite, don't get mad. Just because everyone does it doesn't mean it's right.

Good luck with that.