How to Disable the Firewall on Fedora Linux

Firewall software is crucial for securing Linux systems against network-based attacks. According to 2022 statistics, over 90% of data breaches start with an exploit of vulnerabilities in internet-facing systems [1]. Firewalls filter incoming and outgoing connections, providing a layer of defense that prevents many types of attacks.

However, there are some situations where admins and users may need to temporarily disable firewall protections on a Fedora Linux workstation or server for troubleshooting purposes. Fully disabling firewall security does come with risks and should only be done when absolutely necessary.

This comprehensive, 2600+ word guide will cover the technical details of the firewalld service on Fedora Linux, outline legitimate use cases for disabling the firewall, provide step-by-step instructions for stopping and disabling firewalld service, and discuss the security implications of running systems without firewall protection.

Understanding FirewallD and Security Risks of Disabling

Firewalld is the default firewall management utility included in Fedora Linux distributions that controls the underlying netfilter kernel packet filtering framework. It was introduced in Fedora 18 to simplify the process of configuring firewall policies and port forwarding compared to editing iptables rules directly.

Firewalld allows administrators to define preset configurations and zones, with each zone containing predefined services, ports, and communication parameters tailored to a specific risk level or trust level. Some common examples include:

• public: For use in public areas with no trust in the network environment. Very restrictive and blocks all incoming connections by default except for essential system services.
• home: For home networks with a basic level of trust. Opens several common communication ports.
• work: With moderate trust assumptions, opens some application ports plus features like mDNS.
• trusted: With a high trust level in other systems on the network. Very permissive.

The ability to quickly switch between these preset zones as risk levels change is one of the key advantages of firewalld and can prevent accidental openings in system defenses.

Some key services, protocols and capabilities managed by firewalld firewall zones include:

• TCP & UDP ports – Specifies which target destination ports are permitted or blocked for apps wishing to make connections.
• ICMP requests – Controls ping and other ICMP packet responses for troubleshooting.
• Special connections – Handles protocols like ipp-client for printing, vnc-server for remote desktop, etc.
• Forwarding rules – For routing connections dynamically to particular destinations.
• Rich language (RL) rules – Sophisticated conditional rules with many matching parameters.

Disabling the firewalld service removes all these firewall protections and restrictions at the system level. The network ports on the OS become completely open to connections from other computers on the local network or internet.

This means that:

• Any application programs on the system can freely establish connections out to public servers or cloud services without port filtering.
• External hosts from anywhere can freely connect into any open ports provided by local apps and services.
• Incoming packets can directly interact with the sockets and installed network software without intervention.
• Harmful traffic has an unchecked route directly into the inner workings of the OS kernel.

So while completely disabling firewalld can make troubleshooting network issues quicker, it also removes critical safeguards. This allows malware, intruders, worms, probes and attacks direct access for exploitation.

Even small openings in firewalls can have huge security impacts. For example, the 2021 Apache Log4j vulnerabilities that affected millions of systems initially got a foothold by spreading through open connections to Logging services [2]. Firewalls would have mitigated the early exposure while patches were still being developed.

For these reasons, firewalls should only be disabled briefly as a last resort during troubleshooting when the risks have been deemed acceptable and systems are isolated. Steps should also be taken to minimize attack surface during testing.

When Temporarily Disabling Firewalls Can Be Useful

While fedora Workstation editions come with firewalld enabled by default, Server editions start with the firewall disabled by default until the environment is properly secured.

Some examples of situations where an administrator might need to temporarily disable an active firewall include:

• Installing new services: When installing or reconfiguring complex application stacks like LAMP, SMTP, FTP, databases etc, it can be easier to troubleshoot connectivity issues between components with the firewall disabled initially. Once setup is working, the service can be re-enabled and tightened.

• Network testing: To rule out firewall rules as the cause of network connectivity or throughput issues, disabling firewalls can help determine if packets are being blocked versus some other routing or NIC driver problem.

• Finding open ports: Audits often scan for unnecessary open ports on production systems. Temporarily disabling external firewalls lets testers map all listening services. This identifies unneeded components to lock down.

• Kernel debugging: Getting core dumps off systems or debugging difficult kernel crashes can sometimes be aided by turning off firewall rules so logging data can flow freely to help solve issues.

In many cases, there are alternative approaches to disabling the firewall completely during testing – like opening specific ports or services. But in scenarios where broader access is needed temporarily, this guide outlines proper procedures.

Step-by-Step Guide to Disabling the Fedora Firewall

These steps walk through the process of temporarily disabling firewalld firewalls by stopping and disabling the service on Fedora 35/36 systems. This includes checking status, impacts, restart persistence, and re-enabling the firewall after completion.

Confirm Firewall Service is Running

First, verify that the firewalld service is currently active on your system. Run:

sudo systemctl status firewalld

This will check the systemd init daemon and display the current state, which should resemble:

● firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled)
   Active: active (running) since Fri 2022-12-23 22:41:42 EST; 2 months 9 days ago
     Docs: man:firewalld(1)
 Main PID: 1003 (firewalld)
    Tasks: 2 (limit: 4704)
   Memory: 41.5M
   CGroup: /system.slice/firewalld.service
           └─1003 /usr/bin/python3 -Es /usr/sbin/firewalld --nofork --nopid
...

This status output indicates firewalld is active and currently running on the system, protecting the network interfaces with the configured firewall policies. The next step is to temporarily stop this firewall service.

Stop the Firewall Service

Use the systemctl utility to halt the currently running firewalld firewall process:

sudo systemctl stop firewalld

No output is displayed when successful. Verify it is now stopped:

sudo systemctl status firewalld

You should now see:

● firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled)
   Active: inactive (dead) since Fri 2023-01-20 23:22:11 EST; 2s ago
     Docs: man:firewalld(1)
  Process: 1003 ExecStart=/usr/sbin/firewalld --nofork --nopid (code=killed, signal=TERM)
 Main PID: 1003 (code=killed, signal=TERM)

Jan 20 23:22:11 server1 systemd[1]: Stopping firewalld - dynamic firewall daemon...
Jan 20 23:22:11 server1 systemd[1]: Stopped firewalld - dynamic firewall daemon.

This shows that systemd has now stopped the firewalld service, halting the firewall protections. The network ports are now exposed without filters.

Prevent Firewall Auto-Start on Reboot

To keep the firewall disabled across system restarts, also prevent the firewalld service from automatically launching on boot:

sudo systemctl disable firewalld

Review enabled/disabled status:

sudo systemctl is-enabled firewalld

disabled

The reboot persistence is now configured – firewalld will remain inactive when restarting the server.

Alternate Methods for Stopping the Firewall

In addition to using systemctl, some other options for disabling firewalld include:

Firewall-cmd utility

The firewall-cmd command that comes with firewalld can also stop the service:

sudo firewall-cmd --state
sudo firewall-cmd --disable-service=firewalld
sudo firewall-cmd --state 

Editing Configuration Files

Modifying the firewalld systemd unit file directly prevents automatic start:

sudo vi /usr/lib/systemd/system/firewalld.service
# Change ‘default enabled‘ to ‘default disabled‘
sudo systemctl daemon-reload
sudo systemctl disable firewalld

NetworkManager Dependency

On Desktop installations, firewalld can also be disabled by stopping the NetworkManager service it depends on:

sudo systemctl stop NetworkManager

These show alternate options from a sysadmin perspective. For ease-of-use, the systemctl approach outlined earlier is most universal.

Impacts of Disabling Firewalls on SELinux & Other Security Layers

It’s important to understand that while firewalld manages inbound network access controls, other system defenses like SELinux (Security Enhanced Linux) also play important security roles.

SELinux blocks process access to resources based on strict domain type enforcement policies. So it can mitigate some risks if an attacker reached running services with the firewall down.

However, completely disabling firewalld does lower the overall security posture substantially. Any exploit payloads entering through unfiltered ports have an easier path to try and disable SELinux or attack other processes.

So while possible hardening techniques exist, running long-term without firewall protection is high risk on internet-facing systems. The aim is to only have the firewall down the bare minimum during focused troubleshooting.

Re-Enabling the Firewall After Testing

Once any temporary firewall disabled testing or debugging is complete, it’s crucial to re-enable the firewall service for continued protection:

sudo systemctl enable firewalld
sudo systemctl start firewalld 

Then check firewalld status again:

sudo systemctl status firewalld
● firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled)
   Active: active (running) since Fri 2023-01-20 23:30:11 EST; 9s ago
     Docs: man:firewalld(1)
 Main PID: 1827 (firewalld)
   Status: "Dispatching rules..."
    Tasks: 2 (limit: 4704)
   Memory: 41.5M
   CGroup: /system.slice/firewalld.service
           └─1827 /usr/bin/python3 -Es /usr/sbin/firewalld --nofork --nopid

This shows the firewalld service is again active and providing firewall protections. The specific zone policies can be restored or adjusted as needed going forward.

Note that while ‘systemctl disable’ prevented auto-restart on reboot after temporarily taking the firewall down, ‘systemctl enable’ persists this setting again for subsequent reboots. So firewalld will run automatically on future system startups.

With firewalls re-established filtering network access, production systems regain a key layer of defense-in-depth security hardening against exploits.

Firewall User Interfaces as Alternatives

While this guide focused on the firewalld command line, Fedora Linux also includes firewall graphical tools that can disable/stop services as well:

Firewall Configuration

FirewallConfig provides a GUI to change default zones, services, ports and rules. The Stop Firewall button disables firewall protection.

Cockpit Server Manager

Cockpit’s firewall interface enables starting/stopping firewalld and opening ports from a web console for remote server administration.

These can provide options beyond the CLI for temporary firewall disablement during network troubleshooting scenarios.

Conclusion

Firewalls provide essential validation of network connections to Fedora Linux operating systems. But administrators occasionally need to stop or disable these protections briefly for system debugging purposes when the security risks are manageable.

This step-by-step guide outlined common use cases, proper procedures utilizing systemctl commands, and expert-level insights on the implications of disabling firewalld services in Fedora Linux. With firewalls being the frontline against remote attacks, learning best practices for any disablement is critical knowledge for both systems security and availability.

.