Getting to Know Firewalld

Special Thanks: This article was made possible by support from Linux Professional Institute

A firewall is an important part of a security strategy, but it is only one component and is not a security panacea for reasons that will become clear later in the discussion. A host-based firewall protects the local system just as a network firewall protects an entire network or part of a network, such as a DMZ.

Firewalld is the default firewall installed on CentOS 7 and newer, Red Hat Enterprise Linux 7 and newer (RHEL), and Fedora 18 and newer. If you use a Red Hat-based distribution, then you probably have it already. If you use other distributions, it’s available via git and as a tarball from firewalld.org. Firewalld uses zones to define trust levels of network connections or interfaces. Zones are an advanced topic not covered in this article. There will be a future article that covers firewalld zones.

Firewalld Features

• IPv4 and IPv6 support
• Ethernet bridging
• IP sets
• Separate runtime and permanent configuration options
• No service or system restart required for configuration changes
• Complete D-Bus API
• Predefined Zone list
• Simple configuration options
• Flexible enough for complex zone rules
• Direct interface
• Simple log of denied packets
• Application whitelisting
• Automatic kernel module loading
• Puppet integration
• CLI and graphical configuration

NOTE: A firewall is a set of allow and deny rules that control packet flow to and from networks. A firewalld service is a combination of ports, protocols, modules, and destination addresses.

Troubleshooting firewalls

System administrators of all skill levels have wasted countless hours on troubleshooting a problem that ended up pointing to a firewall that has prevented remote access to a service. The term ‘remote’ is important. Firewalls don’t prevent access to local services. In other words, firewalls prevent access from remote systems across the network but not access from the local system itself. The point of a firewall is to deny everything from the outside except what you specifically allow in. Unfortunately, frustration with firewall rules often ends in the firewall being disabled by an otherwise well-meaning system administrator.

Troubleshooting firewall access is easy. In this example, you’ve just installed the Apache web server, NGINX, or some other web server of your choice onto a server system. You test from your workstation and you get a “This site can’t be reached” message in your browser. Here is the process of how to resolve the problem:

1. Check the system’s process list to be sure the service is running.
2. Test the service from the local system. Open a web browser (Firefox or Chrome, if you have a GUI or lynx, if not (lynx is a text-based web browser).
3. Check to see if a firewall is running.
4. Add a firewall rule to allow HTTP (TCP port 80) and HTTPS (TCP port 443) or whatever ports your web service uses. Reload the configuration to enable the rule.
5. Test from a remote system again.

This same procedure works for any service accessed over the network. To illustrate the troubleshooting procedure above, the next section is a demonstration of setting up a web server and then remotely accessing it.

Setting up http and https access

Install a web server onto your system. For my Red Hat-based system, the process is simple to install the Apache web server.

$ sudo yum -y install httpd

Enable the web server to run at startup.

$ sudo systemctl enable httpd.service

$ sudo systemctl list-unit-files | grep httpd
httpd.service    enabled

Start the httpd.service.

$ systemctl start httpd.service

Check that the httpd service is running.

$ ps -ef | grep httpd

root      1194     1  0 20:05 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
apache    1199  1194  0 20:05 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
apache    1200  1194  0 20:05 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
apache    1201  1194  0 20:05 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
apache    1202  1194  0 20:05 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
apache    1203  1194  0 20:05 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND

Test the web server locally using lynx or a graphical browser.

$ lynx http://localhost

Figure 1: Verifying Apache is running and available on the localhost using lynx.

Check that you can access the web server from a remote computer. It fails the test because the firewall is currently blocking all ports.

Figure 2: Checking access from a remote computer.

Check to see if a firewall is running.

$ sudo firewall-cmd -state
running

To allow access from remote systems, you have to enable the ports configured for your web server. In this example, it is port 80. The --permanent switch adds the allowed port to the firewall’s permanent configuration.

$ sudo firewall-cmd --permanent --add-port=80/tcp
success

Reload the firewall configuration.

$ sudo firewall-cmd -reload
success

Check access again from your remote computer. You should see a web page appear in the browser.

Figure 3: The remote computer’s web service is now accessible.

Use this same procedure to configure other ports for your services. You can also add multiple ports before reloading the firewall’s configuration.

Focusing on security

I stated in the first paragraph that firewalls are a single part of an overall security strategy and not a panacea. You have just configured a firewall exception to allow remote access to port 80 for the Apache web server. Doing so creates a vulnerability on the host system. For the moment, assume that you only allow ports 22 (SSH) and 80 (HTTP) on that server system. That’s two vulnerabilities. These are what security people call “acceptable risk.” You have to accept some risk when you allow network access to a system’s services.

The reason allowing access creates vulnerabilities is that you’re allowing computers on a network, and possibly the entire Internet, to access this system via port 80. What if the version of Apache you installed has an unpatched security flaw? Your system is exposed and vulnerable to that flaw until it’s patched. The firewall won’t protect the system because you have allowed access to that port. The door is open.

Is this a real problem? Yes, and no. It is a problem but the alternative is to have no services running on computers, which means you have no customers or employees connecting to those services. That’s not acceptable. There is some degree of risk that you have to accept to run a service. You have to practice due diligence and protect the system in other ways (encryption, application firewall, backups, and monitoring) and routinely patch the system.

Summary

You should have a host-based firewall running on every system on your network—no exceptions. A firewall, as stated previously, is not the perfect security tool, but it does help protect the system from attacks on other services that are not exposed. The same rules apply to network firewalls. This is why you must employ a multi-layered approach to security and not rely on any one technology or solution. Firewalld is installed and enabled by default on all Red Hat-based systems, which should put system administrators at ease that their systems are protected as soon as they’re placed online.

© Gino Santa Maria, Fotolia