Hello, here they are:
Ebtables is blocking indiscriminately on Cloudmin Pro: on two fresh installs, CentOS 7 latest from scratch and the like, I found that the source of my (2 weeks!) problems was ebtables. There are 2 private tickets about this with bunch of details. No connectivity with KVM in vms, created from my images, your images or simply fresh installs, once you set the Cloudmin IP range and IP spoofing, even if the ebtables seemed OK to my poor knowledge. Why would it block a VM (all?) with the same IPs assigned in them and in Cloudmin? Lucky me I have a /24 and didn't fill the full range and by chance assigned one outside the range; just worked. There is some non-sense erratic behavior there, ebtables style.
Cloudmin backups: just search here for problems with those; they never (ever) worked for me, I am using images in case of problems which is a pain. One public ticket.
Cloudmin ancient and buggy images and a request: of course one can update, but still it is weird to see lots of CentOS 6. Who would start a fresh system with that, a VM moreover where there aren't constraints like HP raid controllers not working? Ubuntu is also old, Debian latest KVM only - even if I don't care for them but I am testing stuff once in a while. Said to myself "ah, a 7.0 with XFS" but the one dubbed "CentOS 7.0 64-bit XFS KVM instance with base OS" just boots into dracut... Also no KVM Virtualmin image with a decent 7.x seems like an oversight; one with Webmin too. Those are your products, come on :)
A firewalld rule is inserted by the Virtualmin install script that opens all ports above 1025 or something till the end of 65k-something. That is not a sane default at all, this is a problem. I didn't have that before running the script, just the standard post CentOS 7 install, ssh and dhcpv6.
The documentation should be updated to reflect that ports 10000 - 10100 should be opened, and not only 10000 - 10010. I am sorry now I don't have the time to find it, but there were a couple of places I found this.
Please document that it is recommended to do a fresh install without LVM if Cloudmin needs take a look at fstab, grub etc. Else will throw pages of errors when imaging for example. If they are benign, say so in documentation, or just don't display them if seems feasible to you.
Authentic, File Manager: the Save configuration button spins endlessly giving the impression of a freeze.
Authentic, File Manager: where is the upload file progress bar, this one I remember I had it? Was there a download one? It would be nice, not to just sit there, not knowing what is happening, wondering if it is working. Another feature would be hash a sha256 function to check the integrity of files? And another one - what about some easy way to copy the path, (sorry if there is one already?).
Authentic, File Manager, purely aesthetic and personal opinion: the yellowish/gnomish icons in the pane should go away, and match the clean ones in the tree?
And now this is kind of a big problem, but totally improperly tested by me, I didn't have the time but saw it at a few ocasions (can't say that with the latest version, too few updated): when I open a few Webmin instances in Chromium (openSUSE Leap 15.0) with Virtualmin/Cloudmin, the very useful Terminal, the overlay-ed transparent one seems to be cross talking to say the least between the tabs, different servers. I mean once in a while for example it grabs the history (upper arrow, it behaves erratic too, please check it out) from another tab. I just have to witness it again.
Thanks, have nice week-end!
PS: watching AVP... What a POS, am I the only one feeling betrayed in my love for Alien and Predator old flicks? :D
Comments
Number 4. I think opening high ports is a reasonable default (and it is done on most default firewalls). I had removed that rule accidentally for a while when we switched to firewalld, but the number of problems that came up with it was, well, problematic. High ports are expected to be open for FTP (it's possible to specify a range in the ProFTPd config, so we could tighten it down if we decide to go that route), but also many many many examples of web app server deployments use high ports, and having them closed by default would make those not work...and the user would need to figure out why when they follow, say, Node.js/Ruby on Rails/Django/etc. examples on a Virtualmin system, they can't connect.
I'm open to discussing the specifics of what the firewall ought to look like. Maybe open a new ticket and we can sort it out specifically. At the moment, I lean toward keeping high ports open, by default. What are the arguments for closing them by default? (We aren't starting any services that listen on public interfaces on the high ports, except Webmin and Usermin, so there won't be anything up there to protect on a fresh Virtualmin installation.)
Number 5. Can you point to the specific docs you mention in 5. I'll be happy to update them.
Number 10. Oh, that sounds annoying! I'll look into it. There's probably something on the backend that isn't taking session into account.
Also, opening a ticket for each issue, instead of a shotgun single issue, will help us sort them out and track when they are fixed.
Thanks for the interest guys!
@KitchM 1, 2, 4 & 10 are not little things in my opinion. Especially ten, if you read between the lines, a security researcher would probably scare you to death with such a thing :) I am not one, so just saying.
@Joe now I understand the reasoning behind this, even if I would prefer all the high ports closed. Yeah, because it is a hosting panel, makes sense to open ports for services. For services that exist that is, not future services; you assume that people would run something on them. But most don't and you don't know what will people install on their servers, or already is - you risk exposing something for the internet. Simple example: Netdata - I sure don't want people to just peek at my server in all it's glory. Or you are mining on a few cores, on your test server; and you think the interface of the miner is protected cause it's only on a and you can access this only on your lan; enter Virtualmin, bang, all the dudes are brute forcing you, and you didn't even bother to setup Fail2ban because ports were closed.
And best in class firewalls drop everything by default, look at pfsense.
With FTPS... this the only thingy that should support opening all the ports; but as I wrote (a post of mine that just burst in flames so I don't link it, pls search the forum for "Drop FTP(S) and use SFTP by default in Virtualmin") - I am a SFTP guy.
I can easily close/open my ports, it was just the first time I saw it and it hit me.
PS: I'll look to see if I remember where I saw it about the 10k ports