Cloudron Forum

I do agree that a Web Application Firewall is a very important security feature that Cloudron should have.

However:

• Moving to Apache/ httpd is not a good idea. nginx is miles ahead when using it as a reverse proxy.
• My experience with the OWASP ruleset is, that is produces a ton of false positives. The Comodo ruleset is a lot less time consuming to handle, as it rarely causes false positives.
• @Mastadamus' solution is way too hacky, because it requires adding a PPA and compiling the module from source. This could severely impact stability.

Looking for distributions with prebuilt nginx ModSecurity, I only found official packages for Arch Linux and FreeBSD.
However, no packages available in Debian Sid, Fedora Rawhide and OpenSUSE Tumbleweed. Thus it may take some time for them to move to their respective stable downstream releases.

Therefore I would propose to delay this issue until packages are moving into Ubuntu LTS/ other stable distributions. For Ubuntu, this will probably take some time, as Ubuntu 22.04 LTS is just around the corner.

But maybe there will be some official Docker images for nginx that will contain ModSecurity a little earlier than that. As dockerizing nginx is probably a good idea anyways, the possible earlier availability of ModSecurity would increase the benefit of looking into that.

@LoudLemur said in Silverblue - for container-based software:

@wind-gmbh Thanks! Do you think that OpenSUSE MicroOS should be a candidate for the Operating System behind Cloudron?

Big Yes and big No.

Yes, yes and yes regarding my statement that MicroOS is the best operating system for container workloads. Period.

But unfortunately No in regarding the ton of work that could be necessary to support Cloudron. Here a few aspects:

• MicroOS/ Kubic will use podman / CRI-O while Cloudron uses docker. While they are pretty much interchangeable you should expect some bumps down the road,
• MicroOS/ Kubic is based on OpenSUSE's astonishingly stable rolling release OpenSUSE Tumbleweed, with the advantage that a MicroOS host is not expected to need a lot of painful migration work and is very stable, if you put everything into containers. Cloudron however installs some things into the host itself (like nginx), that could break due to the rolling release nature of the distribution, if not containerized.
• If you come from a Debian-based distribution (like Ubuntu) or even a RHEL-like distribution, there are a few little things that are done differently and need to be adapted. Therefore it would be necessary to simultaneously maintain a lot more distribution specific code (like the installation script). People who installed Cloudron on Ubuntu will expect a supported way to upgrade to the next Ubuntu-LTS release, so two versions have to be maintained indefinitely.
• While Ubuntu LTS is as much common with beginners as it is in enterprise environments, (Open)SUSE is unfortunately not very common with beginners. So you may exclude some users, that are at a point where they are not ready to switch to an entirely different distribution family.

Could it be worth it in the long run anyway? Probably yes. Would it be a lot of work? Probably also yes.

---

If you want to understand more about MicroOS' advantages and limitations, I do recommend their Design page.

If you are interested in that approach I very much recommend OpenSUSE MicroOS (for running containers) and OpenSUSE Kubic (for running Kubernetes).

MicroOS/ Kubic is in my opinion the best way to run container workloads in production.

Silverblue is a nice similar project, but OpenSUSE has pushed the concept of an immutable operating system much further already.

I did not use MicroOS Desktop (GNOME/ KDE available) yet, so this could be something Silverblue would be doing better.

This is probably related to a feature request I have made a couple of weeks ago:

I have opened a related Feature request a few weeks ago.

I am very much in on this.

Apparent PROs:

• As would be required by Cloudron, there is an official Docker-/ OCI-Container available.
• As there is a lack of "One Click" deployment options for a containerized grommunio instance, Cloudron could easily become the go-to-solution.
• As grommunio requires a subscription for most deployments Cloudron could attract customers that are already willing to pay for open source software and are therefore more likely to pay for a Cloudron subscription as well.
• As grommunio aims to "exchange your Exchange", a lot of people frustrated by too many Microsoft Exchange annoyances – most recently Y2K22 – there are a lot of potential customers, especially if containerized hosting of it would be more straight forward. The Rainloop App is nice for simple deployments, but not for anyone that aims to do that.
• Doing a quick sweep I could not find any viable Enterprise-grade open source mail server solution that offers an officially maintained docker container image.

Apparent CONs:

• The container image is not distributed through any major container registry (that I know of), but has instead to be loaded from a tarball (like wget -qO - "https://download.grommunio.com/appliance/grommunio_Appliance.x86_64-latest.tar" | podman load),
• Running multiple instances on the same host would call for a pretty complex nginx configuration (SMTP, IMAP, POP3, WEB) or dedicated IP addresses (as I have proposed elsewhere).

---

@scooke said in Grommunio:

Looks like a cool groupware solution. Installation looks complicated though. https://grommunio.com/

At this point, the official virtual appliances are more easy to install, if you simply want to try it out. There are some useful instructions for containerized deployment as well, but I agree that at least that one isn't very straight forward.

---

At the moment I have a possible project that calls for the deployment of Nextcloud instances and E-Mail server solutions across multiple sites. I would love to use Cloudron for both tasks, but I am afraid that Cloudron's built in Mail server solution is no viable replacement for Exchange.
I will probably have to go for the virtual appliances, then; despite preferring containerizing.

@girish said in per-Application IP Address / IP Access Control:

@wind-gmbh Is the use case here that the server has multiple interfaces and one is public internet and another is private internet ?

Yes, exactly. It is basically the idea to limit the attack surface in a single-server scenario by excluding some apps from the public eye.

@girish said in per-Application IP Address / IP Access Control:

FWIW, I prefer the first config more then the second one i.e just restrict listening on the interface only in the first place.

I would say either has it's advantages:

	listen on IP	allow / deny
Network Layer	Layer 3/4 (TCP/IP)	Layer 7 (HTTP)
Works with single IP	no	yes
Network segmentation / Firewall required	yes	no
Visible Access Barrier	Not routed / dropped by Firewall	HTTP 403
Cloudron needs to keep track of assigned IP addresses	yes	no

They are differently working solutions for the same basic problem, that apply to different scenarios.

By default, a Cloudron App will be served on all Interfaces.
Therefore, if any Cloudron App is required to be reachable by the public internet, all Cloudron Apps on the host will be reachable by the public internet.

server {
    listen       443 ssl http2;
    server_name  application.cloudron-host.example.com;
    listen       [::]:443 ssl http2;
}

It would be great if it was possible to assign a dedicated IP address that an application will exclusively listen on.
That way, the application could be hidden from the public internet by restricting access to it on a network firewall.

server {
    listen       10.10.10.10:443 ssl http2;
    server_name  application.cloudron-host.example.com;
    listen       [fdea:dbee::f]:443 ssl http2;
}

Another way of achieving a similar goal on a single IP address/ all interfaces would be IP access control lists in the reverse proxy:

server {
    listen 443 ssl http2;
    server_name application.cloudron-host.example.com;
    listen [::]:443 ssl http2;
    allow 192.168.1.0/24; # Allowed Access
    deny all;
}

I know that this is probably a lot more work to implement in the front end, than in these quick examples.
But anyway, these features are probably something that possibly other users would appreciate.