I don’t really like “howtos” for fundamental stuff, like security. I think our priority is and has been shipping a good set of tools and defaults that works for most people.
I also think that the vast majority of exploits we hear about were not because someone didn’t setup more software, but because they didn’t keep their system up to date, they ran sloppy third-party software (often WordPress plugins or other web apps with a weak security history), or used weak passwords. Daily, I see people posting about distros that have been EOL for years. That’s how you get hacked.
We currently ship the following, often pre-configured in a way that works pretty well for most web hosting users:
- Update notifications in a very visible place. If you’re running old software, it is not because you didn’t know about it. This is the single biggest security flaw on most of our users systems.
- Multiple layers of brute-force protection. Fail2ban configured for most of the services we manage, Webmin has brute-force protection built-in (and optional 2FA) and most of the services we configure also have brute-force protection built-in. People aren’t guessing passwords for a Virtualmin system unless the passwords are extremely weak, or shared across multiple systems.
- Tools to enforce strong passwords. You can configure Webmin with password policy to insist on strong passwords, Ilia implemented a strength meter when creating passwords so you can see at a glance if you’re making a good password or not.
- A firewall, made useful by Fail2ban. Firewalls in a web server have limited utility; if you don’t need a service to be available to the world, you shouldn’t run it on a public port, so a generic static firewall does little. But, a firewall that updates based on attacks is useful. And, if you customize it (we provide UI support for that), you may also improve security of some services, by providing very specific access.
- SpamAssassin and ClamAV and greylisting. While it’s probable we need to improve the defaults here, it’s such a complicated topic and everybody has different tolerance for false positives. We mostly stick to the defaults provided by your OS package here, which is still pretty good. We provide UI support for the configurable parts of SpamAssassin, and UI to turn on or off AV and greylisting.
- Tools to help stay on top of web application updates. When technically possible/reliable, we offer upgrades to web apps we support in the Install Scripts UI, and bulk updates are also possible. Again, old software is how you’re probably going to get hacked.
(Note that chroot jails are not on that list. They are mostly cosmetic, they are not much of a security feature, though now that jailkit uses capabilities to chroot, at least on some platforms, rather than being suexec, jails are not a notable security risk as they historically were.)
Because the most likely exploits are core things, I’m hesitant to go off into the weeds of nice stuff that may or may not be useful for everyone.
There are some things I can recommend, but can’t easily automate and I’m not the best person to document: mod_security has been very helpful for us in addressing some types of DDoS (DDoS is a particular type of security issue…data is unlikely to be compromised, but it’s still annoying and costly to experience, and we have been targeted several times through the years), tools like Cloudflare may be useful for similar reasons (but also complicated and confusing for new users who don’t understand that it’s a proxy or what that means…and Cloudflare isn’t super great about making it clear, they kind of pretend like what they do is unique magic, when it’s really the same sort of proxying and edge caching that big websites have been doing for decades).
But, I remain skeptical of complicated guides to security, and I don’t want to be someone contributing to that sort of thing. Most people can’t spend hours every week on security, so if they get distracted by side quests, they’re going to drop the ball on the obvious stuff and that’s how you get got.
I also want to note that I am not an expert on every security tool and practice in the world. I can’t write a mod_security guide because I am not a mod_security expert, and there is nothing Virtualmin-specific about turning on and configuring mod_security. If you want to use mod_security, the mod_security docs are going to be better than anything I could write! Security is a big part of my job (in every job I’ve ever held, including my other current full-time job in tech where I head up a security team as part of my duties), but security in general is not my area of expertise. I learn what I need to know for the world-facing stuff I have to maintain, as best I can.
In short: If I can automate a notable security improvement in our products that works for most people most of the time, without causing a lot of breakage, I will try to do that as my development time allows. We do have some security stuff on the road map, as we always do in every new release. I’m not going to name them, as I’d feel bad about it if it doesn’t make it in. But, if I find time for writing documentation, it’s going to be spent trying to improve our general documentation, which has been neglected for quite a while, due to lack of time and resources, and difficulty getting motivated when our docs wiki was made intolerable by spammers. Ilia is fixing our docs, though, so I’ll be able to drop in on writing docs in short bursts soon. (But, again, improving core docs will be my focus. If you want security docs, go to the source!)
