Familiarizing Yourself with firewalld

The firewalld service provides packet filtering and user interfaces for the GUI environment and the command line. It offers support for IPv4 as well as IPv6, and much more. You can find additional details from the firewalld official website at https://www.firewalld.org/.

This firewall service is called the dynamic firewall daemon because you can change an ACL rule without needing to restart the service. The rules are loaded instantaneously via its D-Bus interface.

A central part of firewalld is zones. Network traffic is grouped into a predefined rule set, or zone. Each zone has a configuration file that defines this rule set, also called a trust level. The traffic grouping can be a system’s network interface or a source address range, which identifies traffic from other systems. Each network connection can be a member of only one zone at a time.

By default, firewalld zone configuration files are stored in the /usr/lib/firewalld/ zones/ directory. Customized or user-created zone configuration files are stored in the /etc/firewalld/zones/ directory. Table 18.1 shows the predefined zones on a system employing firewalld. The zones are listed in the order of the least trusted to the most trusted network connections.

The firewall-cmd utility allows you to view and interact with various firewalld configuration settings. For example, to see all the predefined zones on a system, use the --get-zones option, as shown on a CentOS distribution in Listing 18.1.

Listing 18.1: Viewing the predefined zones with the firewall-cmd command

$ firewall-cmd ––get-zones
block dmz drop external home internal public trusted work
$
$ ls /usr/lib/firewalld/zones
block.xml  drop.xml      home.xml      public.xml   work.xml
dmz.xml    external.xml  internal.xml  trusted.xml
$

NetworkManager is also integrated with firewalld. Thus, when a new network device is added via NetworkManager, firewalld automatically assigns it to the default zone. The default zone is typically preset to the public zone, but it can be customized via the firewall-cmd utility. You can view the system’s current default zone as shown in Listing 18.2.

Listing 18.2: Viewing the default zone with the firewall-cmd command

$ firewall-cmd --get-default-zone
public
$

If you need a different default zone, you can alter it. Just use super user privileges and employ the ––set-default-zone=zone option.

You can also view all the currently active zones as well as their traffic grouping. Just employ the ––get-active-zones switch as shown in Listing 18.3.

Listing 18.3: Viewing the active zones with the firewall-cmd command

$ firewall-cmd ––get-active-zones
public
  interfaces: enp0s8
$

Besides zones, firewalld also employs services. A service is a predefined configuration set for a particular offered system service, such as DNS. The configuration information may contain items such as a list of ports, protocols, and so on. For example, the DNS service configuration set denotes that DNS uses both the TCP and UDP protocols on port number 53. Listing 18.4 shows a snipped listing of the various predefined services on a CentOS distro.

Listing 18.4: Viewing the predefined services with the firewall-cmd command

$ firewall-cmd ––get-services
[...]
amanda-client amanda-k5-client bacula bacula-client
[...]
dhcp dhcpv6 dhcpv6-client dns docker-registry
[...]
$
$ ls -1 /usr/lib/firewalld/services
amanda-client.xml
amanda-k5-client.xml
bacula-client.xml
bacula.xml
[...]
dhcp.xml
dns.xml
[...]
$

Using a firewalld service allows easier firewall configurations for a particular offered system service, because you can simply assign them to a zone. An example is shown in Listing 18.5.

Listing 18.5: Assigning the DNS service to the dmz zone

# firewall-cmd --add-service=dns --zone=dmz
success
#
# firewall-cmd --list-services --zone=dmz
ssh dns
#

When you modify the firewalld configuration, by default you modify the runtime environment. The runtime environment is the configuration actively employed by the firewalld service.

The other firewalld environment is the permanent environment. This environment is the firewall configuration stored within the configuration files. It is loaded when the system boots (or when firewalld is restarted or reloaded) and becomes the active runtime environment.

Both of these firewalld environments have their place. The permanent environment is useful for production, whereas the runtime configuration is useful for testing firewall setting changes.

If you have tested firewall configuration changes in the runtime environment and wish to make them permanent, it is easily done. Just issue the firewall-cmd --runtime-to-permanent command using super user privileges. If you feel confident that your runtime environment configuration modifications are correct, you can tack on the --permanent option to the firewall-cmd command. This adds the changes to both the runtime and permanent environment at the same time. See the man pages for the firewall-cmd command for more information.

Investigating iptables

The iptables firewall service uses a series process called chains to handle network packets that enter the system. The chains determine the path each packet takes as it enters the Linux system to reach the appropriate application. As an application sends packets back out to the network to remote clients, these chains are also involved. Figure 18.1 shows different chains involved with processing network packets on a Linux system.

Notice in Figure 18.1, that there are five separate chains to process packets:

• PREROUTING handles packets before the routing decision process.
• INPUT handles packets destined for the local system.
• FORWARD handles packets being forwarded to a remote system.
• POSTROUTING handles packets being sent to remote systems, after the forward filter.
• OUTPUT handles packets output from the local system.

Each chain contains tables that define rules for handling the packets. There are five table types:

• filter applies rules to allow or block packets from exiting the chain.
• mangle applies rules to change features of the packets before they exit the chain.
• nat applies rules to change the addresses of the packets before they exit the chain.
• raw applies a NOTRACK setting on packets that are not to be tracked.
• security applies mandatory access control rules.

Implementing network address translation (NAT) requires using the nat table to alter the packets’ address in the OUTPUT chain. Implementing a firewall is a little trickier, as you apply filter tables to the INPUT, OUTPUT, and FORWARD chains in the process. This provides multiple locations in the process to block packets.

Each chain also has a policy value. The policy entry defines how a packet is handled by default for the chain, when no rules apply to the packet. There are two different policy values:

• ACCEPT: Pass the packet along to the next chain.
• DROP: Don’t pass the packet to the next chain.

The tool you use to view and alter the chains and filters in the iptables service is the iptables command. Table 18.2 shows the commonly used iptables command-line options.

To quickly view the filter table’s chains and rules, use super user privileges and the -L option on the iptables command. A snipped example on a Fedora system is shown in Listing 18.6.

Listing 18.6: Viewing the filter table’s chains and rules

$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     udp  ––  anywhere             anywhere             udp dpt:domain
[...]
Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     udp  ––  anywhere             anywhere             udp dpt:bootpc
OUTPUT_direct  all  ––  anywhere             anywhere
$

Notice that the -t filter option is not needed in this case. This is because the iptables command applies commands to the filter table by default.

If you want to block all packets leaving your Linux system, you would just change the default OUTPUT chain to a DROP policy. Be careful here, because if you are using ssh to enter your system, this will cause your connection packets to be dropped as well! Listing 18.7 shows a snipped example of blocking all outbound packets on a Fedora system. Notice how the ping command operation is no longer permitted after this modification.

Listing 18.7: Employing the iptables command to drop all outbound packets

$ sudo iptables -P OUTPUT DROP
$
$ ping -c 3 192.168.0.105
PING 192.168.0.105 (192.168.0.105) 56(84) bytes of data.
ping: sendmsg: Operation not permitted
[...]
$ sudo iptables -P OUTPUT ACCEPT
$
$ ping -c 3 192.168.0.105
PING 192.168.0.105 (192.168.0.105) 56(84) bytes of data.
64 bytes from 192.168.0.105: icmp_seq=1 ttl=64 time=0.062 ms
[...]
$

In Listing 18.7, after the default OUTPUT chain is changed back to an ACCEPT policy, the ping packets are permitted.

To change chain rules, you need to use some additional command-line options in the iptables command. These rule options are shown in Table 18.3.

The -j option in Table 18.3 needs a little more explanation. This is the actual rule applied to the identified packets. The most commonly used different target values are as follows:

• ACCEPT: Pass the packet along to the next chain.
• DROP: Don’t pass the packet to the next chain.
• REJECT: Don’t pass the packet, and send a reject notice to the sender.

Putting a rule together and adding it to a chain is a little tricky, so an example will help. In snipped Listing 18.8, an Ubuntu system at IP address 192.168.0.104 is shown successfully sending a ping to a remote Fedora system, whose IP address is 192.168.0.105.

Listing 18.8: Sending a ping to a remote system successfully

$ ip addr show | grep 192.168.0.104
    inet 192.168.0.104/24 brd 192.168.0.255 [...] enp0s8
$
$ ping -c 1 192.168.0.105
PING 192.168.0.105 (192.168.0.105) 56(84) bytes of data.
64 bytes from 192.168.0.105: icmp_seq=1 ttl=64 time=0.305 ms
--- 192.168.0.105 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.305/0.305/0.305/0.000 ms
$

Now on the Fedora system, using super user privileges, the following command is issued:

sudo iptables -I INPUT 1 -s 192.168.0.104 -j REJECT

This new rule will be inserted (-I) into the INPUT chain’s filter table at index 1 (first rule in the chain). Any packets coming from the source (-s) address of 192.168.0.104 (the Ubuntu system) will be rejected (REJECT). Now that this rule is in place, when the Ubuntu system tries to ping the Fedora system, it will fail, as shown snipped Listing 18.9.

Listing 18.9: Blocking a ping to a remote system that blocks the packets

$ ping -c 1 192.168.0.105
PING 192.168.0.105 (192.168.0.105) 56(84) bytes of data.
From 192.168.0.105 icmp_seq=1 Destination Port Unreachable
--- 192.168.0.105 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
$

While you don’t need to reload the iptables service to have new or modified rules take effect, these rules have no persistency. In other words, if the system was rebooted or the iptables service restarted, you would lose all those new or modified ACL rules.

As long as the iptables service is enabled to start at system boot, Red Hat and Red Hat–based distributions, such as Fedora and CentOS, will automatically load iptables rules stored in these files:

• IPv4 rules: /etc/sysconfig/iptables
• IPv6 rules: /etc/sysconfig/ip6tables

Debian and Debian-based distributions, such as Ubuntu, need an additional software package, iptables-persistent, installed and enabled. The files this package uses to load persistent rules are as follows:

• IPv4 rules: /etc/iptables/rules.v4
• IPv6 rules: /etc/iptables/rules.v6

If you need to save the current iptables rules, employ the iptables-save command. This utility needs its output redirected to a file because by default, it sends the rules to STDOUT.

To restore saved iptables rules, employ the iptables-restore command. This utility needs its input redirected from a file. So, if you were testing an ACL change that was not working well, you could quickly restore the iptables’ original rules. On an older Fedora distribution, you use super user privileges and issue the iptables-restore < /etc/sysconfig/iptables command to restore all the original IPv4 rules.

Understanding UFW

The Uncomplicated Firewall (UFW) is the default firewall service on Ubuntu distributions. It is configured with the ufw command-line utility or Gufw for the GUI.

There are several UFW commands that control the firewall’s state as well as view its status. These commands are shown in Table 18.4. Each one requires super user privileges.

To view the current state of the UFW service, use sudo ufw status verbose, if you need more information than just status provides. Enabling the UFW firewall service and viewing its current state is shown snipped in Listing 18.10.

Listing 18.10: Enabling UFW and viewing its status

$ sudo ufw enable
[...]
Firewall is active and enabled on system startup
$
$ sudo ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip
$

Viewing the verbose status of the UFW firewall provides information that helps to explain its configuration:

• Status: UFW service is running and will start on system boot (active), or the services stopped and a system boot does not change this (disabled).
• Logging: The service’s logging feature can be set to off; log all blocked packets (low), which is the default; log all blocked, invalid, no-policy-match, and new connection packets (medium) with rate limiting; log medium-log-level packets and all other packets (high) with rate limiting; and log everything with no rate limits (full).
• Default: Shows the default policy for incoming, outgoing, and routed packets, which can be set to either allow the packet, drop (deny) the packet, or reject the packet and send a rejection message back.
• New profiles: Shows the default policy for automatically loading new profiles into the firewall, which can be set to ACCEPT, DROP, REJECT, or SKIP, where ACCEPT is considered a security risk.

The various default UFW policies are stored in the /etc/default/ufw configuration file. When first installed, these settings allow all outgoing connections and block all incoming connections. You can make modifications to the firewall as needed using the ufw command and its various arguments. A few of the more common arguments are shown in Table 18.5.

When creating new UFW rules, you can use either simple or full syntax. Simple syntax involves designating the rule using only the port number or its service name. You can also add the protocol to the port number as shown in Listing 18.11.

Listing 18.11: Using ufw simple syntax to add an ACL rule

$ sudo ufw allow 22/tcp
Rule added
Rule added (v6)
$
$ sudo ufw status
Status: active
To                         Action      From
--                         ------      ----
22/tcp                     ALLOW       Anywhere
22/tcp (v6)                ALLOW       Anywhere (v6)
$

Notice that when the rule is added, that two rules were applied—one for IPv4 and one for IPv6 packets. With full syntax, there are many options. For example, you can employ settings such as those listed in Table 18.6.

You can specify a rule via a service name (e.g., telnet) with the ufw command. When doing this, ufw checks the /etc/services file to determine the appropriate port and protocol information for that service.

An example of using the UFW full syntax is shown in Listing 18.12. In this case, network packets coming from any systems in the 192.168.0.0 class C subnet will be denied access to port 80 on this system.

Listing 18.12: Using ufw full syntax to add an ACL rule

$ sudo ufw deny from 192.168.0.0/24 to any port 80
Rule added
$
$ sudo ufw show added
Added user rules (see 'ufw status' for running firewall):
ufw allow 22/tcp
ufw deny from 192.168.0.0/24 to any port 80
$$

View any user-added rules using the ufw show added command as shown in Listing 18.12. The UFW rules are stored in the /etc/ufw/ directory, and user-added rules are placed into the user.rules file within that directory, as shown in Listing 18.13.

Listing 18.13: Displaying the /etc/ufw/ directory’s contents

$ ls /etc/ufw/
after6.rules  applications.d  before.rules  user6.rules
after.init    before6.rules   sysctl.conf   user.rules
after.rules   before.init     ufw.conf
$

If you need to delete a rule, it’s easiest to do it by the rule number. First view the rules via their numbers and then employ the ufw delete command as shown in Listing 18.14.

Listing 18.14: Deleting a rule via its number

$ sudo ufw status numbered
Status: active
     To                         Action      From
     --                         ------      ----
[ 1] 22/tcp                     ALLOW IN    Anywhere
[ 2] 80                         DENY IN     192.168.0.0/24
[ 3] 22/tcp (v6)                ALLOW IN    Anywhere (v6)
$
$ sudo ufw delete 2
Deleting:
 deny from 192.168.0.0/24 to any port 80
Proceed with operation (y|n)? y
Rule deleted
$

UFW uses profiles for common applications and daemons. These profiles are stored in the /etc/ufw/applications.d/ directory. Use the ufw app list command to see the currently available UFW application profiles. An example is shown snipped in Listing 18.15.

Listing 18.15: Viewing the available UFW application profiles

$ sudo ufw app list
Available applications:
  CUPS
  OpenSSH
$
$ sudo ufw app info OpenSSH
Profile: OpenSSH
Title: Secure shell server, an rshd replacement
Description: OpenSSH is a free implementation[...]
Port:
  22/tcp
$

You can also view detailed information on these profiles as also shown in Listing 18.15. The profiles not only provide application documentation, they allow you to modify the ports and protocols used by the applications as well as create non-typical application profiles for your system’s needs.

Once you have created a new profile or updated an old one, use the ufw app update all command to update UFW on the profile changes. Also, when using a profile to specify a rule’s ports and protocols, you must employ app instead of port within your syntax for creating new rules.

DenyHosts

The DenyHosts application is a Python script, which helps protect against brute-force attacks coming through OpenSSH. The script can be run as a service or as a cron job. It monitors sshd log messages in the distribution’s authentication log files, such as /var/log/secure and /var/log/auth.log. If it sees repeated failed authentication attempts from the same host, it blocks the IP address via the /etc/hosts.deny file.

To configure DenyHosts you modify its /etc/denyhosts.conf file. You also need to have the TCP Wrappers files, /etc/hosts.allow and /etc/hosts.deny, ready to go.

Fail2ban

The Fail2ban service also monitors system logs, looking for repeated failures from the same host. If it detects a problem, Fail2ban can block the IP address of the offending host from accessing your system. While DenyHosts works only with TCP Wrappers, Fail2ban can work with TCP Wrappers, iptables, firewalld, and so on.

The fail2ban-client program monitors both system and application logs looking for problems. It monitors common system log files such as the /var/log/pwdfail and /var/log/auth.log log files, looking for multiple failed login attempts. When it detects a user account that has too many failed login attempts, it blocks access from the host the user account was attempting to log in from.

A great feature of Fail2ban is that it can also monitor individual application log files, such as the /var/log/apache/error.log log file for the Apache web server. Just as with the system log files, if Fail2ban detects too many connection attempts or errors coming from the same remote host, it will block access from that host.

The /etc/fail2ban/jail.conf file contains the Fail2ban configuration. It defines the applications to monitor, where their log files are located, and what actions to take if it detects a problem.

IPset

An IPset is a named set of IP addresses, network interfaces, ports, MAC addresses, or subnets. By creating these sets, you can easily manage the groupings through your firewall and any other application that supports IPsets.

The ipset utility is used to manage IPsets and requires super user privileges. When you create an IPset, you need to first determine what name you will give it. After that, decide how you want the IPset to be stored. Your storage choices are bitmap, hash, or list. There are two ways to create an IPset via the ipset command:

ipset create IPset-Name  storage-method:set-type
ipset -N IPset-Name  storage-method:set-type

An example of creating a subnet IPset and adding members to it on a CentOS distribution is shown in Listing 18.17.

Listing 18.17: Creating and populating a subnet IPset

# ipset create BadGuyNets hash:net
#
# ipset add BadGuyNets 1.1.1.0/24
# ipset -A BadGuyNets 2.2.0.0/15
#

Once you have completed your IPset population, you can review your handy work. Just employ the ipset list command as shown snipped in Listing 18.18.

Listing 18.18: Viewing a subnet IPset

# ipset list
Name: BadGuyNets
Type: hash:net
[...]
Members:
1.1.1.0/24
2.2.0.0/15

Once it’s created and populated, block the IPset in either your iptables or firewalld ACL rules. To make the IPset persistent, you save it via the ipset save command and redirect its STDOUT to the /etc/ipset.conf file or use the -f option.

You can delete a single item from your named IPset via the ipset del command. To remove the entire IPset, you’ll need to destroy it as shown in Listing 18.19.

Listing 18.19: Deleting a subnet IPset

# ipset destroy BadGuyNets
#
# ipset list
#