Cloud Servers
Cloud Server Firewall and Security Management
Every KapsuleHost Server ships with a managed firewall that denies inbound traffic by default, plus brute-force protection, a web application firewall and automatic security patching, all controlled from one page in KPanel.
The defaults are chosen so a brand new server is safe before you have touched anything. What you add on top is usually just the ports your own application needs. This guide walks through the whole Server management page, because the firewall is one section of it and the other sections are what stop you needing the firewall in the first place.
Opening the Management Page
- Sign in to KPanel.
- Click Cloud Servers in the left sidebar, then click your server.
- Click Management in the action buttons at the top of the page.
The direct address is /cloud-servers/<server-id>/management. The page describes itself as "Firewall, OS patches, fail2ban, and ModSecurity. Changes apply over SSH within seconds."
If a banner reads "Live apply unavailable. Changes will save to the next provisioning run but won't take effect immediately", the panel cannot reach the server right now. Your settings are still saved, they just are not applied yet. Check the server is running and reachable.
The Default Firewall Policy
The Firewall (UFW) section states the policy in one line: "Default-deny inbound. SSH (22) is always open. App-stack ports open automatically. Add custom rules below."
In practice that means:
- Nothing can reach your server from the internet unless a rule allows it.
- Port 22 is always open, so a firewall change can never lock you out of the machine.
- The ports your app stack needs, such as 80 and 443 for a web application, are opened for you.
- Outbound traffic from the server is not restricted.
With no custom rules, the section shows "No custom rules. Defaults: SSH + app-stack ports." That is a healthy state, not a missing configuration.
Adding a Custom Rule
Add a rule when you run something on a port the default policy does not cover: a Node application on 3000, a database you need to reach directly on 5432, a game or media server on a UDP port.
- Open the Firewall (UFW) section.
- Type the Port number into the first field. Valid values are 1 to 65535.
- Choose TCP or UDP.
- Choose Allow or Deny.
- Click Add.
The rule appears in the list with an ALLOW or DENY badge and the port and protocol, for example 3000/tcp. It is pushed to the server over the management connection within seconds.
To remove a rule, click the X at the end of its row. Removing an Allow rule closes that port again immediately.
Exposing a database port to the whole internet is one of the most common ways a server gets compromised. Before you allow 3306, 5432, 6379 or 27017, ask whether the thing connecting could reach the database over the server's own loopback interface or a private network instead. If it genuinely must be reachable from outside, make sure the service itself requires strong authentication and encryption.
Add the rule first, then start the service. A service that comes up behind a closed port looks broken in exactly the same way as a service that failed to start, and you can waste a long time debugging the wrong layer.
App Stacks
The App stack section tells the platform what kind of application this server runs, so the hardening preset can be tuned to it. Installing an application through the panel sets this for you.
The recognised stacks are WordPress, WooCommerce, Ghost, Nextcloud, GitLab, Mattermost, Generic web, and No app stack. The section explains itself as: "The hardening preset is tuned to your app. Installing an app from the marketplace auto-sets this."
The stack affects which ports open automatically and how the other protections are tuned, most visibly in fail2ban.
fail2ban
fail2ban watches authentication attempts and bans addresses that keep failing. It is on by default and the page describes it as: "Bans IPs that brute-force SSH. For WordPress sites, adds wp-login.php protection too."
Leave it on. It is the single cheapest protection on the page, it costs nothing in performance, and it turns a constant background noise of password-guessing attempts into nothing at all. On a WordPress or WooCommerce stack it also protects the login form, which is where most attacks against WordPress actually land.
ModSecurity, the Web Application Firewall
ModSecurity inspects HTTP requests against the OWASP Core Rule Set and flags the ones that look like attacks. On a KapsuleHost server it starts in detection-only mode: "OWASP Core Rule Set in DetectionOnly mode by default. Logs suspicious traffic without blocking; flip to active mode in your server once tuned."
Detection-only is the right starting point. The Core Rule Set is thorough, and on a real application some legitimate requests will match a rule. Run it in detection-only for a while, read the logs, work out which rules your own traffic trips, and only then switch to blocking inside the server.
Turning on blocking without tuning first can break your own site. Form submissions with rich text, file uploads, and API clients with unusual payloads are the usual casualties. Check your logs before you switch.
OS Auto-Patching
Security updates are applied for you. The section explains the safety net: "Security updates applied automatically. Snapshot-protected: a server snapshot is taken before each run, with automatic rollback if the server becomes unreachable after reboot."
Two settings sit under the toggle:
- Allow automatic reboot when a kernel update needs it (only during quiet hours below). Kernel updates only take effect after a reboot. If you leave this off, kernel patches are installed but not active until you reboot yourself.
- Quiet window (UTC), a start and end hour. Reboots only happen inside it. Set it to the quietest hours for your audience, and remember the field is in UTC, not your local time.
Leave auto-patching on. The overwhelming majority of compromised servers are running software with a patch that was published weeks earlier. A pre-patch snapshot with automatic rollback means the usual objection, that an update might break something, is already handled.
Patch History and Running a Patch Now
The Patch history section lists each run with a status of RUNNING, SUCCESS, ROLLED_BACK, FAILED or SKIPPED, the number of packages updated, whether the server rebooted, and the time it started.
To patch immediately rather than wait for the schedule, click Run patch now. The confirmation reads: "A snapshot is created first. The server stays online except for a brief reboot if a kernel update needs it."
A ROLLED_BACK entry means the safety net did its job: the server did not come back cleanly after a reboot, so the pre-patch snapshot was restored. See Cloud Server Snapshots for how those snapshots work.
A Sensible Baseline
For most servers, this is the whole security configuration:
| Setting | Recommended |
|---|---|
| Firewall | On, default rules, plus only the ports your app needs |
| fail2ban | On |
| ModSecurity | On, detection-only until you have read the logs |
| OS auto-patching | On, with reboots allowed in a quiet window |
| SSH authentication | Keys, not passwords |
The last row is not on this page but matters more than the rest combined. See Connecting to Your Cloud Server With SSH.
Troubleshooting
"Could not load management config." The panel could not read the settings for this server. Reload, and check the server exists and is provisioned.
"Port must be 1-65535." The port field takes a whole number in that range. Ranges and service names are not accepted here.
My rule saved but nothing changed. Look for the "Live apply unavailable" banner. If it is showing, the change is stored but not yet pushed to the server.
I can reach my service from one network but not another. That is usually your own outbound firewall, not the server's. Test from a different connection before changing rules here.
A patch run shows FAILED. Read the error message on the row. A full disk is the most common cause. Free some space and click Run patch now.
Legitimate traffic started getting blocked. If you switched ModSecurity to blocking mode, put it back to detection-only, read the logs, and identify the rule before trying again.
If a firewall rule refuses to apply, or you are locked out of a service you have allowed, email support@kapsulehost.com with the server name, the port, and what you expect to reach it.