LUX 263 - Linux System Administration III

Lesson 7: Chapter 25, firewalld and iptables

Objectives:

This lesson discusses setting up a firewall in Linux. Objectives important to this lesson:

1. firewalld
2. iptables
3. Using firewall-config
4. Using firewall-cmd
5. firewalld zones
6. Runtime and permanent configurations

Concepts:

Chapter 25

firewalld is both the name of a service and the name of the daemon concerned with providing that service. It is a replacement for iptables service, which needs to be reloaded every time it changes. Connections are broken during the iptables reload. The text tells us that this is a problem, because iptables has to be reloaded each time a virtual server is brought up or down. firewalld does not have this drawback.  No doubt, iptables is an acceptable solution for networks that rarely change, but the problem that comes from using virtuals makes firewalld a better choice.

Feature comparison:

• iptables requires that firewall rules be stored in tables which must be loaded
• firewalld can be updated live
• iptables can be managed with a GUI (system-config-firewall) or a CLI (iptables).
• firewalld can be managed with a GUI (firewall-config) or a CLI (firewall-cmd).
• Although both systems use rules tables, iptables cannot be used to manage firewalld rules.
  
• Both systems update the netfilter service, which runs in the kernel. It manages network traffic with rules from its tables.
• The text notes that netfilter runs in kernelspace, but the four management interfaces named above run in userspace.
  

The text devotes several pages to each of the two firewall services. We should concentrate on the firewalld service, the newer of the two, as the chapter does.

It is important to know that you can implement a change in firewalld in the running configuration, in the configuration files read at startup, or both. This allows you to change the system without a reload or a reboot, change it at the next reload/reboot, or make sure that today's change will be in effect at the next reload/reboot as well.

Page 899 introduces network zones. The text lists nine default zone types, each of which can be configured differently from the others in terms of what connections are designated as allowed. You would not need to use all zone types in any network.

• drop - drop all packets from this zone; no notification is returned to the sender
  
• block - reject all packets from this zone;  an ICMP message is sent to the sender that their address is prohibited; this is not recommended if we think attackers are probing our location for live ports and addresses
  
• public - do not trust; by default, accept only ssh, mdns (DNS), and dhcp services
  
• external - do not trust; accept selected connections
• dmz - for computers that are meant to provide public access; only allow authorized connections
  
• work - mostly trust: accept selected connections
• home - mostly trust: accept selected connections
• internal - mostly trust: accept selected connections
• trusted - completely trust; accept all connections

The text takes a moment to confuse us on page 899, telling us that a service is defined as a combination of one or more ports, and one or more protocols. Some texts call this a socket when it is combined with the name of a device. Defining the port and protocol to be used enables the potential for connection to the service.

The text tells us that firewalld can use a lockdown whitelist, but does not clearly explain what that is. Follow the link in the previous sentence to see that it is an XML file which may list a SELinux context, may list allowed commands, and should list users who are allowed to run the listed commands. The users are identified by either their user IDs or their user names.

To use firewalld, make sure that firewalld and firewall-config are both installed on your system. The text tells us they are installed by default. Remember that the text was written about Fedora and RHEL, so check other versions before proceeding.

If it is installed, firewalld may be running by default. To check, to reload it, to stop it, and to start it, the text gives us one command with four different arguments (note that reload, stop, and start all require root privileges):

• systemctl status firewalld.service - to check whether the service is running
  
• systemctl reload firewalld.service - to reload the config files while the service is running
  
• systemctl stop firewalld.service - to stop the service
  
• systemctl start firewalld.service - to start the service
  

Note that the commands in the list above can also be given with the firewall-cmd command. The next point shows an example of using it.

The text provides a command to stop all traffic through the firewall: su -c "firewall-cmd --panic-on".
This command is meant to be used when the network is being attacked from outside. The author points out that stopping all traffic through the firewall will probably also stop you if you are administering the network remotely. To reverse the command, give it again, but change the panic-on to panic-off.

Page 902 presents a short exercise to allow http traffic. First, we should know what protocols to use on what port. The text advises us that we want to allow TCP (protocol) on port 80. (His instructions, shown below, do not agree.) The author presents a seven step procedure that should be eight steps. His first step should have been to start the GUI interface for firewalld, which is firewall-config. His other steps depend on having done this. (For a lesson that uses firewall-cmd, look at this web site which has a long lesson about setting up firewalld on CentOS.)

1. Open the Configuration drop-down, and select Permanent. (This will change the startup files.)
2. In the main tabs, select Zones.
3. In the list on the left, select Public, which should be your default active zone.
4. In the secondary tabs, select Services.
5. Find the service you want to allow in the list of services. In the exercise, it is http. Put a check in the box next to it.
   
6. To make this change effective immediately, open the Configuration drop-down again, and select Runtime.
7. Repeat steps 2 through 5, to allow http service in the runtime (live) configuration.
   

At the bottom of page 902, the author remembers to tell us we used firewall-config in the exercise above. As long as it is open, he spends a few pages on a discussion of some of its features.

On page 906, the text begins a discussion about using firewall-cmd. You should note that this is less of an interface than firewall-config, but it is more granular. It can quickly accomplish tasks that you perform on a regular basis, and unlike using a GUI, these actions can be stored in a script.

On page 908, the text shows us how to open a port with firewall-cmd. Note that we have to specify a port number and a protocol, which the text warned us about having to know. In firewall-config, knowing the service was fine, but this command requires more details.

The text devotes several pages in the chapter to iptables, an alternative firewall solution that creates and runs packet filtering rules in the kernel. This subject has reportedly come up in cyber-defense competitions, so some knowledge of it may be useful for those who are ready for that subject area. Note that a system can run firewalld or iptables, but not both, so an administrative decision must be made about which to run on your server. Having imposed a firewalld solution on us for this many pages, we should consider advising the author to move the discussion that starts on page 908 to an earlier spot in the chapter, from which point we might choose the appropriate sub-section to continue the lesson. The section on iptables continues through page 928.

In this poorly worded, but otherwise well intentioned Tecmint article, you will find instructions for stopping and masking iptables. These instructions are missing from our text. You should know them, should you have to convert a system from one technology to the other.