Virtualmin Framed Theme virtual-server-theme theme version 9.3 released

Howdy all,

The old Virtualmin Framed Theme has been updated to version 9.3 to address some bugs caused by the new Webmin/Usermin versions. The HTML in the Webmin ui-lib was updated to improve validation, which lead to a few quirks in how some forms and tables would be rendered. This update should fix those problems.

Note that we aren’t recommending this theme any long; Authentic is the recommended theme for all Webmin/Virtualmin/Cloudmin users, unless you have some reason to stick with the old one. So, we continue to support the old theme, and fix minor bugs, there will not be any major updates or enhancements to it. Authentic also needed and received updates to fix these problems, but that’s already been rolled into the Webmin and Usermin packages we provide in the Virtualmin repositories.

As always, let us know if you run into any problems.



Thanks for the update.

We still use the framed theme for 2 reasons.

  1. Is faster
  2. We got bitten hard when there was the security issue with the authentic theme, so for now, our confidence is very limited in it

If there Is there a way to HTTP protect the webmin login (e.g. with .htaccess), we will be glad to try it again. That is, if there is a second line of defense we may get back in the train.

Thanks! I also still use the old theme, it’s indeed faster and easier/clearer to navigate.

I use the old theme as well, as it is much more accessible to visually impaired individuals because it’s easier to navigate and uses simpler controls. The accessibility of the Authentic theme honestly leaves a lot to be desired but, to its credit, has been (very slowly) improving as releases continue.

Lucian took the words out of my mouth, I hope the framed theme will always be around, what Ila is doing is great as well but I find the framed theme so easy to work with.

Thanks for the feedback on accessibility in Authentic. I’d really like accessibility to be as good, or better, in everything we do in the future…but, it’s more challenging than I’d like. I’ll make sure we keep shipping the old theme until accessibility in Authentic catches up. Please don’t hesitate to file bugs about accessibility issues, if you have any specific problems with Authentic.
As an aside have you tried the old Virtualmin Mobile Theme? In the past, we’ve gotten feedback that it was better because it doesn’t use frames and has a menu-baased navigation system (where only one piece of the hierarchy is on the screen at any given time).

I actually don’t like the Virtualmin Mobile Theme as much because of the fact it only has one part of the interface on-screen at any given moment. I like the framed theme a lot because I can quickly navigate throughout the UI and the frames honestly don’t really bother me all that much. By the way, as a completely blind individual who does use a screen reader, I am more than happy to conduct accessibility testing on the Authentic theme and, if desired, aid in making accessibility changes as I am also a Web developer with extensive experience with ARIA, WCAG, etc. I am glad to hear the framed theme will continue to be available until accessibility in Authentic has been made better, as honestly I wouldn’t be able to use Virtualmin right now if Authentic were the only theme available (and by that I mean if every other theme, including the mobile theme, had been removed).

Both valid concerns.

On #1, I expect this will be a thing on the past in another couple of weeks (maybe sooner). Ilia has implemented a SPA model wherein pages are loaded via XHR, instead of loading the whole page. This reduces page load times dramatically; it may even be faster than framed theme (I haven’t tested them side-by-side yet, but it wouldn’t shock me if it were). There’s an alpha version of that on the Authentic github. That’s actually why we’ve rolled new Webmin/Usermin releases, to fix HTML bugs that the new loader triggered. So, it’s coming soon. Will be fast.

On #2, I sympathize. That was an awful security issue (and we fixed a couple of others during the following audit that were equally bad, but harder to spot). Any theme can introduce security bugs; that’s a problem of the architecture (but also true of most themeable web applications, so it’s not unique to Webmin). It’s just that Authentic is so much more ambitious than previous themes that it has a lot more surface area. I’ve been working with Ilia to push things down out of the theme and into core or into modules, so they’re subject to the same security considerations as the rest of Webmin. So, it’s on the radar.

We’ll keep maintaining the old theme for the foreseeable future. But, we’re also encouraging folks to keep letting us know about the things that keep you from using Authentic. We’ll keep fixing them, and someday, we’ll all be in agreement that Authentic is the best thing! :wink:

If there Is there a way to HTTP protect the webmin login (e.g. with .htaccess), we will be glad to try it again. That is, if there is a second line of defense we may get back in the train.

Yes, you could add additional security authentication, by running Webmin behind Apache/Nginx proxy. I would personally make a bash script that would flip Webmin configuration to use default or proxyed settings. It’s good to have Webmin run behind proxy for users, with additional security layer (.htaccess), when you’re sure that Apache is up and running. In case it’s down, you would need to fall back to default settings. The best to do, is to have an ability to change it on the fly using console.

There are other multiple security measures that you could take:

  1. Change port number and block IPs that do port scan;
  2. Limit sessions to the same client IP address;
  3. Use two factor authentication;
  4. Limit access to certain countries.

Nowadays, Authentic Theme doesn’t seem to have known security issues.

… the old theme, it’s indeed faster …

I promise, after complete re-write of Authentic Theme, starting with version 19.00+, it will be as fast as Virtualmin Framed Theme or, actually, even faster! There will be no longer an iframe and all request will load in the background, without constant page reload. It will still be possible to open each module in separate tab without having navigation menu.

It’s humongous amount of work to be done but after all - it will be stunning. You could see the developer preview version of 19.00-beta2. The new version will not be based on this example but will work familiarly. There are bugs in this version but if you have Webmin 1.844+ you could give it a safe try.



@Joe - I like the old Virtualmin mobile theme but notice that the ‘Delete Spam’ button doesn’t appear in messages even though that is set in preferences.

Thanks for the comment.

Putting a proxy will be just another overheat/overkill. Webmin is already running its own apache server, correct? Why not change it to add this first level of HTTP password before the actual theme login that caused so much security trouble?

No. Webmin runs under miniserv, a special purpose application server designed specifically for Webmin. The the only way to make something happen “before the theme” would be to make it so the theme can’t customize the login page and couldn’t customize any unauthenticated pages (of which there are several in Virtualmin, and removing those features would be pretty dramatic for many users), which isn’t really ideal, either.

Even when you run Apache or nginx in front of it, Webmin’s own web server is still running underneath; it’s possible to run Webmin directly under Apache, but it’d provide horrible performance, much weaker security (no 2 factor auth, no password timeouts, you’d have to configure any extra access controls in Apache, rather than in Webmin, etc.), and would not be themeable in a meaningful way (the application server transparently performs the path changes for themes). Running a proxy in front of Webmin might be a security win, but running Webmin directly under Apache, definitely, would not.

There are ways forward that may improve overall security on an architectural level, but they’re not simple, and we’re considering our options on those fronts. But, there is no magic bullet for security in a very large system.


Hi, http protect for webmin login page is simpler then it sounds like, just close port for webmin login page and put it behind vpn access only. pretty safe.


or close webmin port to outside world completely and use vpn to access it… :wink:


as joe mentioned earlier webmin is server independently from apache or nginx…anyway from point of security adding http simple auth on from of another login page is - pointless, it could slow down attacker but same as main login page it would not stop it. it would just make brute force worked longer and also it will slow you down if you would need it to use gui so what would be the actual point to have that?

at least allow some specific ip addresses to access login page or close webmin port to outside world and put it behind vpn (user would have to connect to vpn and then he would be able to access port 10000 for example and use webmin as normal) - that is quiet secure. Add proper offsite backup (via ssh and cron) and relax.

Got it. I don’t know why was remembering that miniserv is based on Apache. My bad.
Anyway, the idea was not to replace the current login, but add another one completely different. Thats what I do now for phpmyadmin, wordpress login. To actually get in touch with the web API, first line of deffense must be passed. Too bad is not easly configurable.

VPN will be best solutions security wise, but complicated


No need for VPN to protect any port, just use port knocking and you are fine. Actually you could use port knocking for anything what is usually the target of bruteforce attacks, e.g. webmin, ftp, ssh… and so on. With port knocking you dont even need to change any port because until you trigger the right combination the target port will stay closed.

Port knocking is an interesting idea!

Do you have a preferred tool for automating it? (It’s probably not feasible for us to use generically in Virtualmin as it requires client-side participation), but it’s an interesting thing that might be worth making an optional plugin for.

I would propose adding to WebminCore security options, such as:

  1. Suppress any messages from miniserv;
  2. Adding ability to send an email to admin or other specified addressee, when someone lands on Login Page. It would also be good to have ignore list of IPs/Networks;
  3. If GeoIP is installed provide an ability to limit access to Webmin only to certain countries.

All of this isn’t that hard to implement, especially for the one who wrote miniserv and remembers the way it’s designed.

…before the actual theme login that caused so much security trouble …

What are the actual security related problems are you aware of? At the moment, as far as I remember, and you can easily check itsession_login.cgi is just a plain copy of what Jamie did in his own code. It only adds themeable output but the logic is the same as in default code, thus, I don’t see direct security issues coming from the theme.

Saying that the first login is pointless because it will not stop but slowdown an attack, its like saying don’t close your door because will just slow down the burglar. Actually this is the point of slowing down. There is no unbreakable wall, everything is about the resources the attacker is ready to allocate. So building a defense is to slow the attack and make it more costly. Better the defense, higher the cost of the attack, but also higher the cost of the defense. At the end I want better defense for lower cost.

We already have different port. We will explore port knocking.

VPN is complicated, slow to connect, smartphone monitoring is an issue. Can be done but, not handy to use.

HTTP password is easy and I can let my browser password manager to save it (not doing it for actual webmin login), so will be transparent on client side.