Linux - Configuration - Disable Firewall

What the Linux firewall disabler does

This Automox Worklet™ stops the host-based firewall service on a Linux endpoint by running the native disable command for whichever firewall is installed. The Worklet probes the filesystem for /usr/sbin/ufw or /usr/bin/firewall-cmd to identify the management tool in use, then checks the current service state before taking any action.

On Ubuntu and Debian endpoints, the Worklet runs ufw disable, which clears the boot-time enablement flag and flushes the active rule set. On RHEL, CentOS, Rocky, Alma, Fedora, and SUSE endpoints, it runs systemctl stop firewalld to stop the running daemon. Endpoints that have neither tool installed (for example, hosts running a custom iptables or nftables ruleset directly) exit with a non-error status so the same policy can target a mixed Linux fleet.

Each run is safe to repeat. An endpoint that already reports the firewall as inactive returns exit code 0 with no changes applied, and any endpoint that drifts back to an active state on the next evaluation is re-flagged for remediation.

Why disable the host firewall at fleet scale

Disabling a host firewall is a deliberate posture choice, not a default. The cases where it applies are narrow: isolated lab and pre-production fleets where a perimeter firewall handles north-south filtering, application troubleshooting that requires unrestricted port access on a temporary basis, internal test rigs that need to listen on ephemeral ports without exception rules, and migrations to an alternative stack such as nftables, an eBPF-based filter, or a cloud security agent that wants exclusive control of the netfilter chain.

In each of those scenarios the risk has been documented and the operational problem becomes holding the disabled state consistent across every endpoint in scope. ufw and firewalld get re-enabled in predictable ways: an admin runs ufw enable on a single workstation to test something, a package upgrade flips firewalld back on through systemd presets, or a freshly imaged endpoint joins the policy group with the distribution default still active.

This Worklet stops the detected firewall service on every Linux host in scope and re-asserts the disabled baseline on subsequent evaluations whenever drift is detected. Repeat runs on already-inactive hosts return immediately and add no measurable load.

How firewall disabling works

1. Evaluation phase: The Worklet checks for /usr/sbin/ufw or /usr/bin/firewall-cmd to identify the firewall management tool. It then runs ufw status (parsing the first column for active or inactive) or firewall-cmd --state (which prints running or not running). If either tool reports the firewall as active or running, the endpoint is flagged non-compliant and remediation is scheduled. An endpoint with neither binary present exits 0 with a message that the system is not eligible, so the policy is safe to apply broadly.

2. Remediation phase: For ufw endpoints, the script runs ufw disable, which removes the firewall from the boot sequence and flushes runtime rules. For firewalld endpoints, it runs systemctl stop firewalld, which stops the running daemon but does not by itself prevent the service from starting at the next boot. The script captures each command's exit status and reports success or failure back to Automox; failures land in the activity log with the stderr message so the admin can diagnose them without an SSH session.

Disable firewall requirements and safety checks

• Linux endpoint with ufw (Ubuntu, Debian) or firewalld (RHEL, CentOS, Rocky, Alma, Fedora, SUSE) installed at /usr/sbin/ufw or /usr/bin/firewall-cmd

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

• Documented business justification: lab or pre-production scope, application troubleshooting window, migration to an alternative filter stack, or perimeter-only security model

• Confirmation that perimeter or network-layer controls (segmented VLAN, cloud security group, host-level WAF, or upstream firewall) handle the filtering responsibilities the host firewall was previously absorbing

• Out-of-scope target groups: production endpoints exposed to untrusted networks, remote-worker laptops outside a managed perimeter, and any system subject to a control framework that mandates a host firewall (CIS Benchmark 3.5 controls for firewalld and ufw, PCI-DSS Requirement 1, and HIPAA §164.312(e) all expect host-level filtering on in-scope systems)

• Pair this Worklet with the Enable Firewall on Linux Worklet on the same fleet, scoped to a different policy group, so you can restore the host firewall on demand without re-authoring a Worklet

Expected firewall state after remediation

On Ubuntu and Debian endpoints, ufw status returns Status: inactive, the runtime rule set is flushed, and the service no longer loads at boot. On RHEL-family and SUSE endpoints, firewall-cmd --state returns not running and systemctl status firewalld shows the unit in an inactive (dead) state. Network ports become accessible based on listening services and upstream filtering only – the host no longer applies any inbound or outbound rules of its own.

Validate from a peer host by attempting a connection to a service that was previously blocked, for example nc -vz <endpoint> <port> against a port not in the prior allow list. For audit evidence, capture the output of ufw status verbose or firewall-cmd --list-all alongside the Automox policy run identifier.

Note a behavioral difference between the two paths: ufw disable clears the boot-time enablement so the firewall stays off across reboots, while systemctl stop firewalld stops only the running daemon and leaves the unit enabled for the next boot. If your operational intent is to keep firewalld off across reboots, follow this policy with a dedicated systemctl disable firewalld Worklet so the disable step is logged and reversible from the Automox console. The recurring evaluation in this Worklet will re-stop firewalld on any RHEL-family endpoint where the service restarts after a reboot, which is the intended fleet-level enforcement behavior.