Network Security Using Firewalls
Firewall software helps protect your Linux server from unwanted network access. They use access control lists (ACLs) to define what network connections can be allowed and which ones should be blocked.
The core system of creating and maintaining firewall ACLs in Linux is iptables. With iptables you define chains of rules that the kernel follows to determine if an inbound or outbound packet should be allowed or denied. However, defining rules in iptables can get a bit complicated, as it uses a somewhat arcane method of defining hosts and ports. To make life easier for administrators, a few different Linux firewall programs use easy-to-read commands to create the rules needed for the kernel to allow or deny packets. The two most popular seem to be the following:
firewalld—Installed by default on Red Hat-based distributions
ufw—Installed but not activated on Ubuntu distributions
Firewall protection is especially important when running Linux servers. You need the ability to block unwanted intruders from accessing the server applications while allowing your customers to access them freely. This section describes the firewalld program and shows how you can use it to help protect your Red Hat server on different types of networks.
Red Hat Firewall Concepts
The firewalld software uses the concept of zones to define protection for the network interfaces on your Red Hat server. A zone defines the type of network the interface is connected to and what type of network traffic should be allowed or blocked. Different types of network connections require different levels of protection. For example, take the network shown in FIGURE 11-1.
FIGURE 11-1 A Linux server connected to two networks.
In Figure 11-1, the Linux server has two network interfaces. Network card A is connected to a home network, which includes other network devices that need to connect to the Linux system. Network card B in the server is connected to the Internet. You most likely will want to define different ACL rules for each network interface, Network card A should allow the local clients to connect to server resources, such as shared files, printers, and possibly even establish SSH connections to login.
However, Network card B needs extra security protections so that unknown attackers lurking on the Internet can’t gain access to your server. With a myriad of different network applications and protocols, you can see how it would quickly become difficult to keep things straight on the system.
The solution is to implement zone-based ACL rules. The firewalld program allows you to define multiple zones and assign each zone a different set of rules to control network access. Typically, each network interface on the server is assigned to a specific zone, based on the network requirements. The firewalld program applies the zone rules to the network interface.
By default, the Red Hat server defines ten zones. You can list the currently defined zones using the firewall-cmd command:
TABLE 11-1 provides a basic description of what each these default zones are used for.
TABLE 11-1 The default firewalld zones.
| ZONE | DESCRIPTION |
|---|---|
| block | Rejects all incoming network connections and sends an ICMP prohibited message. Only outgoing network connections are allowed |
| dmz | Only selected incoming connections are accepted. |
| drop | Rejects all incoming network connections with no reply message. Only outgoing network connections are allowed. |
| external | Enables masquerading feature to hide the server’s true IP address. Only specified incoming connections are accepted. |
| home | Allows only specified incoming connections, but all outgoing connects are allowed. |
| internal | Allows only specified incoming connections are accepted. |
| nm-shared | Special zone defined for sharing on the network. |
| public | For use on untrusted networks, only select incoming connections are accepted. |
| trusted | All network connections are accepted. |
| work | For use on mostly trusted networks, only select incoming connections are accepted. |
Each zone has a different set of default rules assigned to it, controlling what network traffic can come in or go out from network interfaces assigned to that zone. To manage the access on a network interface you just assign it to a specific zone.
Besides zones, firewalld uses ACL rules. The ACL rules define what network connections should be allowed or blocked. With firewalld you can define the rules using two different methods:
Defining the service name
Defining the protocol port
By using service names, you can allow or block connections by application, such as FTP, SSH, or HTTP. By using ports you can allow or block connections based on TCP or UDP port numbers.
The following sections show how to use firewalld in your Red Hat server environment.
Checking the Firewall Status
While the firewalld program uses standard text configuration files, you can use the firewall-cmd command-line command for most of the things you need to do. To check if firewalld is running, just use the --state option:
You can check what zone a specific interface is currently in by using the --get-zone-of-interface option:
Or if you have multiple network interface cards you can use the --get-active-zones option to list all zones that are currently active on network interfaces:
You can see the current configuration for a zone by using the --list-all option and specifying the zone name using the --zone option:
The output shows the features and what items are allowed through the firewall for that zone. The target feature defines the action for the zone:
default—Rejects all packets not matching the zone rules, but sends an ICMP packet to the client indicating why
ACCEPT—Accepts packets not matching the zone rules
DROP—Drop packets not matching the zone rules
%%REJECT%%—Rejects all packets not matching the zone rules
The sources, services, ports, and protocols features define the rule items that are either allowed or blocked, based on the target setting. In this example, the Red Hat web cockpit service, the DHCPv6 client service, and the openSSH service are all allowed. Likewise, traffic on TCP port 631 (the CUPS application, used for printing) is allowed.
Working with Zones
Besides the default zones you can create your own zones to help customize your server’s network environment. The --new-zone option of the firewall-cmd command defines the zone name:
The --permanent option is required to make the change permanent in the configuration files. Before you can use the zone, you must tell firewalld to reload the configuration file so it knows about the new zone:
Then you can list the zones to see if the new zone exists:
Once you’ve created the zone you can move a network interface to the zone using the --add-interface option:
Be careful though, as the new zone doesn’t have any ACL rules applied to it:
If you add the network interface that you’re currently connected to the server through, this will cause your connection to drop, and possibly be a problem! The next section shows how you can add rules to the zones.
Working with Firewall Rules
ACL rules are the core of the firewall. They define what type of network traffic is allowed or blocked by the network interface. Mistakes when adding or removing rules can be costly, especially if you’re remotely connected to the server!
The firewalld program is very robust in how it allows you to define rules. You can define rules to allow or block access based on a well-known application service name by using the --add-service option:
Notice again that you should add the --permanent option to ensure the new rule applies when the system reloads.
You can also specify rules as TCP or UDP port values:
The firewalld program also uses what it calls rich rules, which allow you to customize a rule to specify a specific object, such as a single IP address and a port or service:
This rich rule example accepts SSH packets (port 22) coming from a specific source address, 192.168.1.70. The command applies this rich rule to the mytest zone. You can then check if the rule was applied:
With the firewalld program you can lock down your Red Hat server as tight as you need, only opening it up to specific network clients.