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.
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.
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.
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):
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".
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.)
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