Linux - Configuration - Enable Firewall

What the Linux host firewall enabler does

This Automox Worklet™ enables the recommended host-based firewall on Linux endpoints and keeps the service active after every evaluation. The Worklet reads /etc/os-release to detect the distribution, installs the right firewall package when it is missing, and starts the service when it is installed but inactive. Endpoints that already report ufw active or firewalld running pass evaluation and burn no remediation cycles, so a daily policy lands as a no-op on the hosts that pass and only installs a package on the hosts that fail.

On Ubuntu, the Worklet checks for /usr/sbin/ufw and runs ufw status to see whether the Uncomplicated Firewall is active. When ufw is missing, the remediation phase installs it with apt install ufw -y and turns it on by piping y into ufw enable. On RHEL, CentOS, Rocky, Alma, Fedora, SUSE, and Debian, the Worklet checks for /usr/bin/firewall-cmd and queries firewall-cmd --state. If firewalld is not installed, the remediation phase falls back through yum install firewalld -y or apt install firewalld -y, then runs systemctl enable firewalld and systemctl start firewalld.

The evaluation phase is idempotent. Once the firewall is active, every subsequent run exits 0 without restarting the service, so the policy can be scheduled daily as a drift control. When a build script, configuration management tool, or admin error disables the firewall, the next Automox run catches the regression and restores the service automatically.

Why enable the host firewall on Linux endpoints

A disabled host firewall is one of the most common findings on a Linux compliance scan. CIS Benchmark control 3.4.x calls for an active host firewall on every endpoint, NIST 800-53 SC-7 (Boundary Protection) treats the host firewall as a primary control, and PCI-DSS 1.x requires firewalling on systems in scope. Many cloud images, golden builds, and developer workstations ship with firewalld or ufw installed but inactive, which leaves SSH, RDP forwarders, Docker exposed ports, and management daemons reachable from any host on the same network segment. The Worklet enforces the boot-time state of the firewall service across RHEL, CentOS, Rocky, Alma, Fedora, SUSE, Debian, and Ubuntu.

Build hosts, container hosts, and developer endpoints often ship with firewalld or ufw installed but inactive. A weekly evaluation against your Linux server and workstation groups holds the firewall service active on every cycle and reverts the regression when an image refresh, automation script, or third-party configuration tool turns the service back off, so CIS 3.4.x, NIST SC-7, and PCI-DSS 1.x baselines hold without manual remediation against each endpoint.

How host firewall enablement works

1. Evaluation phase: The Worklet sources /etc/os-release to read the NAME field. On Ubuntu, it checks for /usr/sbin/ufw and parses the first line of ufw status to capture either active or inactive. On every other distribution, it checks for /usr/bin/firewall-cmd and reads firewall-cmd --state, which returns running or not running. An endpoint exits 0 when the firewall is installed and active. It exits 1 when the firewall is missing entirely, when ufw reports inactive, or when firewalld reports not running, which schedules the remediation phase.

2. Remediation phase: On Ubuntu, the script runs apt install ufw -y when the binary is missing, then pipes y into ufw enable to activate the service and persist it across reboots. On RHEL, CentOS, Fedora, SUSE, and Debian, the script runs yum install firewalld -y with an apt install firewalld -y fallback, followed by systemctl enable firewalld and systemctl start firewalld. If the service is already installed but inactive, the script restarts it with systemctl restart firewalld or ufw enable. A final state check re-runs firewall-cmd --state or ufw status and exits 0 on success or non-zero with a message in stderr when the service refuses to start.

Host firewall enablement requirements

• Linux endpoint running RHEL, CentOS, Rocky, Alma, Fedora, SUSE, Debian, or Ubuntu with systemd available

• Root or sudo privileges for the Automox agent (the default agent context already meets this)

• Network reachability to yum, dnf, or apt repositories when firewalld or ufw needs to be installed

• An existing inbound rule allowing SSH on port 22 before activating ufw on a remote Ubuntu host; ufw enable can drop the active SSH session if SSH is not explicitly allowed first

• A pre-defined firewalld zone (typically public) in /etc/firewalld/zones/ that permits the management traffic you require, such as SSH and the Automox agent

• No conflicting firewall stack already in use (iptables-services, nftables direct rules, or a third-party agent firewall) that would race with firewalld or ufw at boot

Expected state after firewall enablement

After remediation, the host firewall service is active and enabled at boot. On Ubuntu, ufw status returns Status: active and ufw status verbose shows the default policy (deny incoming, allow outgoing). On RHEL, CentOS, Fedora, SUSE, and Debian, firewall-cmd --state returns running, systemctl is-enabled firewalld returns enabled, and firewall-cmd --get-default-zone returns the configured zone, usually public. The zone configuration under /etc/firewalld/zones/public.xml drives which services and ports are open on the endpoint.

Validate by attempting an inbound connection on a port that should be blocked, such as nc -zv <endpoint> 9999 from another host, and confirming the connection is refused. Capture firewall-cmd --list-all or ufw status numbered as audit evidence for CIS 3.4 control mapping. Subsequent Automox policy runs report the endpoint compliant without applying remediation again, because the evaluation phase finds the firewall already active. If an administrator stops the service later (or a config-management tool replaces the unit file), the next firewall-cmd --state or ufw status check returns not running or inactive, and the remediation phase calls systemctl start or ufw enable on the next policy cycle.