I’m using it on all of my servers. And, it can operate side-by-side with fail2ban, if you don’t trust it (and you probably shouldn’t fully trust it before testing it for each of your services on your specific OS, as it hasn’t been broadly tested across all services and such, as my servers run a limited set of things and are all some EL variant).
So, if you want to help us knock out any bugs before it becomes part of Virtualmin, you should try it. If you want a production-ready thing that is extremely well-tested on all of our supported distros and for all Virtualmin-managed services, you’ll want to wait another couple/few weeks.
This weekend I’m rebuilding the backend service and servers that run it to get it ready for actual production use (so the backend is currently offline, but will be back by the end of the weekend), so the crowd-sourced block lists should be in fighting form by the end of the weekend. But, you don’t need the backend to use it. It includes all the important features of fail2ban without any cloud support; only crowd-sourced data and central management/monitoring of many hosts needs the cloud service.
And, reading back over that thread, I think it covers everything I want to warn you about, so it’s worth a read if you are going to deploy minsec. It’s mostly all still true. Though I’ve fixed a few things since that was posted, it’s still true that because minsec is crazy paranoid about security, it needs more scaffolding to work for every service…it will never introduce a new vector of attack, as any of the existing tools do.
Because all the other tools are running as root and interacting with things that are potentially attacker controlled (most services you’ll run alongside Virtualmin have sanitized logs with decades of hardening and bugfixes, but some custom app you run might not be so careful), using them introduces a new risk. minsec isn’t running as root, so everything it needs to see needs to explicitly be granted to it via ACL or some other mechanism.
Running as root means those other tools can just read all the logs. In a world of machines running 24/7 looking for ways to exploit systems, and capable of wildly complex exploits, things that seemed incredibly unlikely (like an attacker exploiting a log analyzer via specially crafted requests to some service that end up in the log) begin to seem more plausible. It’s still quite unlikely, and I’m not suggesting running fail2ban is risky, but running minsec is less risky by virtue of not running as root and only having read access.
Thanks for taking the time to answer in detail. I run Rocky on my servers. I have some less critical/personal projects so I’ll try to find some time next week to give it a go, and report back.
What I’m hoping for, is something that can be setup easily, and with minimal configuration and resource usage or babysitting just run in the background and monitor logs (mostly apache access logs I suppose) and quickly temp block anything rapidly scanning (e.g 100+ requests/sec from a data center in Asia) or repeatedly probing (/xmlrpc.php etc).
The goal with minsec is minimalism: Minimal configuration, minimal maintenance, minimal resource usage, while still doing pretty much everything the alternatives do (and more, the crowd-sourced features are not in most current tools in this space, except Crowdsec, which I ruled out for other reasons).
It still needs a lot of rules to be implemented (and the necessary ACLs to be able to read the logs) to be a complete drop-in replacement, but the core functionality is all there, and it supports all the common Virtualmin-managed services and Virtualmin itself.