Security

Overview​

Security is a core feature. App packages, services, and the platform are constantly updated to address vulnerabilities and improve security.

The goal is security out of the box. Users don't need to read fine print or various manuals to secure their installation - it's secure by default without manual configuration.

Privacy & control​

Complete data ownership and control:

• No remote access - There is no mechanism to access your server remotely unless you explicitly grant permission.
• Autonomous operation - Your server and apps continue running if the App Store goes down. You can't install new apps during downtime, but existing apps keep working.
• Self-hosted - All backend and frontend code runs on your server. No CDNs, analytics, or external cloud services are used.
• Local notifications - All notifications are sent from your server, not from cloudron.io.
• No data collection - No user or app information is collected. No incoming requests are made to your server from cloudron.io. Only outgoing requests to api.cloudron.io for package information.

HTTPS​

• All apps are only accessible via https. HTTP requests automatically redirect to HTTPS.
• Admin dashboard has a CSP policy that prevents XSS attacks.
• Security headers are set across all apps: X-XSS-Protection, X-Download-Options, X-Content-Type-Options, X-Permitted-Cross-Domain-Policies, X-Frame-Options.
• Apps have a default Referrer-Policy of same-origin.

SSL/TLS​

• HTTPS is enforced across all apps. HTTP requests automatically redirect to HTTPS. All certificates are EC certs.
• Let's Encrypt wildcard certificates are supported to hide app subdomains.
• Certificates are automatically installed and renewed. Admins receive notifications if certificate installation fails.
• The Strict-Transport-Security header (HSTS) protects against downgrade attacks and cookie hijacking.
• A+ rating from SSL Labs.
• Certificate transparency: Let's Encrypt submits all certificates to Certificate Transparency Logs. With non-wildcard certificates, installed apps will be listed in public logs (crt.sh, Google transparency report). Use wildcard certificates to avoid this.

App isolation​

• Apps are completely isolated using Docker. One app cannot access another app's database or files.
• Apps run with read-only rootfs, preventing tampering with application code.
• Apps connect to addons (databases, LDAP, email) using authentication only.
• Apps run with an AppArmor profile that disables many system calls and restricts access to proc and sys filesystems.
• All apps run as non-root user. Only in exceptional cases where the situation warrants it do apps run as root.
• Each app runs in its own subdomain (not sub-paths). This prevents XSS vulnerabilities in one app from compromising other apps.
• Process capabilities like NET_RAW are dropped.

Updates​

Signed releases​

Platform updates are signed and verified using GPG. Releases are signed by a team member using a GPG key. Installations download packages and verify signatures before applying updates.

GPG keys for signing releases are maintained offline. This means installations won't be compromised even if cloud infrastructure is compromised.

OS updates​

Ubuntu automatic security updates are enabled. Recent CVEs are listed here.

The system is automatic and requires no manual intervention. If in doubt:

• systemctl status unattended-upgrades - Check upgrade service status
• sudo apt update && sudo apt list --upgradable | grep security - List pending security updates
• /var/log/unattended-upgrades/unattended-upgrades.log - View automatic upgrade logs
• sudo unattended-upgrades - Apply pending security updates immediately

Rate limits​

Rate limits prevent password brute force attacks:

• Password verification - 10 requests/second per IP
• HTTP/HTTPS requests - 5000 requests/second per IP
• SSH/SFTP - 5 connections per 10 seconds per IP
• Email access (Ports 25, 465, 587, 993, 4190) - 50 connections/second per IP/App
• Database addons - 5000 connections/second per app (128 byte passwords)
• Email relay - 500 connections/second per app
• Email receive - 50 connections/second per app
• Auth addon - 500 connections/second per app

Password requirements​

• User passwords require 1 uppercase, 1 number, and 1 symbol
• 8-256 characters long
• Individually salted and hashed using PBKDF2 (RFC 2898 Section 5.1)

Backups​

Backups can be optionally encrypted with AES-256-CBC.

Activity log​

The Activity view shows the activity on your Cloudron. It includes information about who is using the apps on your Cloudron and also tracks configuration changes.

Firewall​

The server's OS firewall (iptables) is automatically configured as required. Avoid modifying iptables with iptables, ufw, or other tools. Instead, use the firewall provided by your VPS provider. For example, use security group settings on AWS or firewall settings on Digital Ocean.

Inbound ports​

Outbound ports​

Leave all outbound ports open. Some providers (AWS EC2, Google Cloud, Digital Ocean) block outbound port 25 to reduce email spam. Request your provider to unblock this port or set up an Email relay.

Securing SSH access​

Disable password-based access to your server. Online attackers brute force passwords, but SSH key-based authentication is equivalent to a 634-character random password. Brute forcing SSH keys is not possible with modern technology. Use EdDSA instead of RSA keys.

Disable root login via SSH and use a sudo user instead. First, ensure you have a sudo user (typically ubuntu has sudo access).

# If you set this to 'no', store SSH keys in sudo user (e.g /home/ubuntu/.ssh/authorized_keys)
# If you set this to 'prohibit-password', store SSH keys in /root/.ssh/authorized_keys
PermitRootLogin no             # Can also be 'prohibit-password' to only allow root login with keys.

Disable password authentication for all accounts and only use SSH keys. Check for the following line in /etc/ssh/sshd_config:

PasswordAuthentication no      # Make sure ssh keys are in place for the root or the sudo user!

By default, SSH runs on port 22. Moving this to port 202 prevents brute force attacks. Be careful not to lock yourself out.

To change the SSH port, modify /etc/ssh/sshd_config:

Port 202   # Do not use any other port. Only this port is not blocked by the firewall

Restart the SSH service: systemctl restart ssh. On Ubuntu 24, you might need to restart the server for changes to take effect. Connect with: ssh -p 202 root@ip

Fail2Ban​

Fail2Ban reads app log files and automatically blocks IPs. It works partially on Cloudron because most apps don't log failed authentication attempts in a parseable format. However, Fail2Ban can block brute force SSH logins:

apt install fail2ban

2FA​

Set up Multi-Factor Authentication for SSH by following this guide.

Email​

See Email security