CHAPTER 16

Firewall and Security Settings

9 sections · 15 min read · SimpleVM 10.1

SimpleVM includes a host firewall and a layered security model that together control how the SimpleVM host communicates with the management network, virtual machine networks, storage and cluster peers, and the outside world. This chapter explains the security concepts most administrators need first — what the firewall is protecting and the principle of least privilege — and then shows how to review firewall zones, confirm which services are allowed, add a service safely, and undo the change if it causes a problem. The firewall is managed from the Networking page and its Firewall detail page, which is a different task from configuring the host interfaces themselves (covered in Chapter 15, Managing Host Networking).

The goal is not to turn every administrator into a firewall engineer, and it is not to teach you to switch the firewall off. The firewall stays Enabled in normal deployments. The goal is to help you confirm that required communication works, understand which services are open and in which zone, and make any necessary change deliberately — opening only the service that is needed, only in the zone that needs it, and only for the source that needs it.

Cross-reference: For signing in to the management interface, see Section 6.5, Sign In with Administrative Access; for the management URL, see Section 6.3, Management URLs. For the host interfaces the firewall zones are bound to, see Chapter 15, Managing Host Networking; for the networks VMs attach to, see Chapter 14, Managing Virtual Networks. For user accounts and administrative access, see Chapter 17, User Access and Administrative Tasks. For the full cluster firewall procedure, see Section 22.6, Networking Requirements and Section 22.7, Shared Storage Requirements for High Availability. For running recovery commands from the browser, see Section 19.4, Web Terminal Overview. For step-by-step firewall diagnosis, see Section 25.7, Firewall Issues. For a consolidated ports-and-services list, see Section 26.13, Firewall Services and Ports.

This chapter at a glance. The sections below move from understanding security to reviewing and changing the firewall safely:

• Understand the model — the layered security model and least privilege (Section 16.1), and how the zone-based firewall works (Section 16.2).
• Observe before you change — review the firewall zones and the services allowed in each (Section 16.3).
• Change a service — add an allowed service, verify it, and revert it (Section 16.4).
• Cluster and VM exposure — cluster firewall intent (Section 16.5) and VM network exposure (Section 16.6).
• Harden and maintain — the hardening baseline (Section 16.7) and security best practices (Section 16.8).
• Troubleshoot — work firewall and access problems layer by layer (Section 16.9).

16.1 Security Overview

Overview

Security in SimpleVM is layered. No single setting protects the platform; instead, the host operating system, the management interface, the firewall, virtual networks, storage permissions, user accounts, and administrative access each contribute to the overall security posture. Understanding the layers helps you decide where a change belongs — a connectivity problem solved at the firewall is different from one solved by changing a VM’s network or an account’s privileges.

The layers you will work with across this guide are:

• Host security — the SimpleVM host itself: the installed baseline, services, updates (see Chapter 18, Software Updates), and local administrative permissions.
• Management-interface security — who can reach the web console on TCP 9090 and from which networks. Keep it on trusted networks; see Section 16.6 and Chapter 17, User Access and Administrative Tasks.
• Firewall security — which inbound services are allowed to reach the host, and the network context (zone) each applies to (Sections 16.2–16.4).
• VM network security — how guests communicate with the host, other VMs, and external networks (Section 16.6 and Chapter 14, Managing Virtual Networks).
• Storage and account security — file permissions and SELinux labeling on VM and image storage, and the named accounts used to administer the host (Chapter 17).

The principle of least privilege

For day-to-day administration, the single most useful principle is least privilege: allow only the access a task requires, keep management access limited to trusted networks and users, and avoid exposing host-level services to networks that do not need them. Every firewall decision in this chapter is an application of that principle — a service belongs in the narrowest zone that satisfies the requirement, scoped to the smallest set of sources that need it.

16.2 Firewall Overview

Overview

The SimpleVM host firewall is zone-based. A zone represents a trust level for a network interface or a range of allowed addresses; services are then allowed within the appropriate zone. This model is easier to manage than opening individual ports everywhere because it ties each allowed service to the network context where it is actually needed. Underneath the product layer the firewall is firewalld, but you rarely need to think in those terms — the interface presents zones and services directly.

Firewall status appears on the Networking page (under System), in the Firewall section: an Enabled toggle, a link showing how many zones are active (“3 active zones” in the reference build), and Edit rules and zones, which opens the firewall detail page (URL /network/firewall). The detail page states the default posture plainly at the top: “Incoming requests are blocked by default. Outgoing requests are not blocked.” In other words, the host blocks inbound traffic except for the services you explicitly allow, while the host’s own outbound connections are permitted.

Before you begin

• You are signed in to the SimpleVM management interface with administrative access. See Section 6.5, Sign In with Administrative Access.
• You know which interface is carrying host management traffic. See Section 15.2, Viewing Network Interfaces.
• You have console or out-of-band access available before making any change that could affect remote management.

Procedure

To review the firewall status:

1. In the left-navigation menu, under System, open Networking.
2. Locate the Firewall section.
3. Confirm that the firewall is Enabled.
4. Review the active-zones link to see how many zones are in effect (“3 active zones” in the reference build).
5. Select Edit rules and zones to open the firewall detail page and review zones and services.

Verification

• The Firewall section shows the firewall Enabled.
• The detail page lists the active zones and the services allowed in each.
• The cockpit service (TCP 9090) remains allowed in the zone serving your management network, so the interface stays reachable.

If you prefer to confirm the firewall state from the command line, the web terminal opens as svmadmin, so prefix privileged commands with sudo:

16.3 Firewall Zones

Overview

Firewall zones separate traffic by trust level. A management bridge, a physical interface, a virtual-machine network, and a cluster peer network each have different security requirements, so assigning them to appropriate zones prevents a service intended for one network from being exposed everywhere. The firewall detail page shows each zone, the interfaces or allowed addresses assigned to it, and the services currently allowed; Add new zone creates a new zone, and each zone has its own Add services action.

Confirmed default zones

The reference build ships with three default zones. Interface names and addresses are environment-specific; use this table to recognize the kinds of entries you will see and the role each zone plays, not as values to reproduce on your own host.

Before you begin

• You are signed in with administrative access (Section 6.5), and you have a recovery path to the host.

Procedure

To review the active zones:

1. Open Networking, then select Edit rules and zones.
2. Review each zone name and the interfaces or allowed addresses assigned to it.
3. For each zone, review the allowed services and confirm they match the zone’s role.
4. Confirm that management, VM networking, cluster traffic, and any storage traffic are separated according to your network design.

Verification

• Each active interface appears in the expected zone.
• Allowed address ranges match the intended management, cluster, storage, or VM network.
• No zone allows services that are unnecessary for that network role.

To confirm the same information from the command line:

16.4 Allowed Services

Overview

An allowed service is a named firewall rule that opens the ports a specific service requires. Using a named service is usually safer and clearer than opening individual ports by number, because the service definition already describes the expected protocol and ports — cockpit, ssh, dhcp, and dns in the default zones are examples. Allow only the services the host actually needs, and add each one to the narrowest zone that satisfies the requirement. A service should not be opened simply because it appears in the list.

Before you begin

• You are signed in with administrative access (Section 6.5).
• You know which zone should receive the service and which source network needs it.
• You have console or out-of-band access in case the change affects management connectivity.

Procedure

To add an allowed service from the management interface:

1. Open Networking, then select Edit rules and zones.
2. Find the zone that should receive the service.
3. Select Add services for that zone.
4. Select the named service that matches the workflow you are enabling.
5. Confirm the service.
6. Return to the zone and confirm the new service appears under the intended zone — not under an unrelated one.

Verification

• The service appears under the intended zone.
• The service is reachable only from the expected network or allowed address range.
• Existing management access remains available after the change.

Revert this change

If the service is no longer needed or the change caused a problem, remove it:

• Open Networking, then select Edit rules and zones.
• Find the zone where the service was added.
• Open the service’s action menu and select the remove or delete action.
• Confirm the service no longer appears under the zone, and that management access is intact.

The equivalent command-line workflow adds and removes a service permanently, then reloads the firewall. Replace the placeholders with the correct zone and service for your environment:

16.5 Cluster Firewall Requirements

Overview

Cluster firewall settings let trusted SimpleVM hosts communicate for live VM migration and high availability. These rules should be more restrictive than normal management rules, because cluster communication should be available only between known SimpleVM hosts. The confirmed cluster zone in the reference build demonstrates the intent exactly: it is scoped to the peer host address (10.0.0.54) and allows only ssh (TCP 22) for host-to-host administration and qemu-nbd (TCP 49152–49215) for migration data — the same services the clustering procedure defines, which independently validates the design.

This section explains the security intent so you can recognize a correct cluster firewall layout. It does not replace the full cluster build. When you create or change a cluster, follow Section 22.6, Networking Requirements and Section 22.7, Shared Storage Requirements for High Availability.

The cluster firewall principles are:

• Use a dedicated cluster zone so cluster services are not exposed to general management or guest networks.
• Scope to known peer addresses rather than broad subnets wherever practical.
• Allow only required cluster services — ssh and qemu-nbd in the confirmed build — and nothing more.
• Treat shared storage carefully, because high availability depends on storage all cluster hosts can reach safely and consistently. Never start the same shared-storage VM on two hosts at once.

For reference, the confirmed cluster firewall preparation — run per host, for each peer — matches the live cluster zone. It is reproduced here so the security intent is concrete; the authoritative procedure remains in Chapter 22:

16.6 VM Network Security Considerations

Overview

A virtual machine’s exposure depends on the network it connects to, not on the host firewall alone. The host firewall protects services on the host; it does not, by itself, govern traffic between a VM and the outside world once the VM is on a bridged network. Review where each VM is connected and treat its exposure accordingly.

• Default NAT network — useful for isolated or basic connectivity. VMs sit behind the host on virbr0; still review DHCP ranges and any static host entries. See Chapter 14, Managing Virtual Networks.
• Bridge networking — places VMs directly on the host’s physical network. Treat a bridged VM like any other host on that network and secure it accordingly. See Section 15.5, Bridge Networking.
• Management network — should not be used as a general-purpose guest network unless the design intentionally requires it.
• Storage and cluster networks — should not carry general VM traffic unless that is part of a documented design.

Procedure

To review a VM’s network exposure:

1. Open Virtual machines and select the VM to review.
2. Review the VM’s network interface on the VM detail page. See Section 10.1, Viewing VM Network Interfaces.
3. Open Networking and review the host interface or bridge the VM’s network uses. See Chapter 15, Managing Host Networking.
4. Review the virtual network configuration. See Chapter 14, Managing Virtual Networks.
5. Confirm the VM is connected to the intended network and that firewall rules match the intended exposure level.

16.7 Security Hardening Overview

Overview

SimpleVM is delivered with best-practice security hardening pre-applied as part of the installed platform. The safest production posture is to preserve that baseline — keep the firewall enabled, limit host access, apply updates, and document any exception rather than relaxing the defaults broadly.

• Keep the firewall enabled unless you are performing controlled troubleshooting with another protection layer in place.
• Keep SELinux enabled. Do not disable SELinux as a general fix; if it blocks a workflow, investigate the denial, file context, or label. See Section 5.10, Review SELinux Status.
• Use administrative access intentionally and avoid leaving elevated sessions open longer than needed (Chapter 17).
• Apply updates on a planned schedule and reboot when a kernel or security update requires it. See Chapter 18, Software Updates.
• Protect management access by limiting the web console, ssh, and administrative credentials to trusted users and networks.
• Document exceptions — who requested the change, why it was needed, what changed, and how to revert it.

16.8 Security Best Practices

Use the following as a baseline for production SimpleVM hosts, adapting it to your organization’s security policy, compliance requirements, and network design.

16.9 Troubleshooting Firewall and Security Settings

Overview

Firewall problems usually appear as connection failures: a management interface you can no longer reach, a VM that cannot reach the network, a cluster peer that cannot communicate, or a newly allowed service that still does not work. Begin by identifying what changed, which network path is affected, and whether the problem is on the host, a VM, or between hosts. Work the problem in layers rather than changing settings at random while a production host is affected.

Useful command-line checks (run from the web terminal as svmadmin, with sudo for privileged commands):