Network filtering in EuroLinux 8 – firewalld

Network filtering in EuroLinux 8 – firewalld

A firewall is what ensures the protection of systems of a broad availability. It allows a precise setup of trust, thus in the context of networking it’s also about access control, for domains. Today we’ll discuss the concepts and inner workings of the network filter that EuroLinux 8 uses – firewalld.

A firewall is what ensures the protection of systems of a broad availability. It allows a precise setup of trust, thus in the context of networking it’s also about access control, for domains. Today we’ll discuss the concepts and inner workings of the network filter that EuroLinux 8 uses – firewalld.

In the era of global communication, almost every individual or institution connects to a network so they can exchange data, work or simply have fun. However, it’s closely related to being responsible. Connectivity is also about a wider perspective of risks, such as attempts of attacks performed by unauthorized individuals. A smart approach is to utilize network filter software to reduce the aforementioned danger. This is especially important in critical environments, where a stress or a complete denial of service would make a negative impact on a company’s operation.

It’s worth noting that in the context of networking a firewall is the first line of defense from external attacks. That’s why one should approach this aspect with responsibility. EuroLinux, providing the highest level of business-class security, delivers a ready-to-use firewall, which aspects and real-world use cases we’ll describe below.

firewalld in EuroLinux 8

EuroLinux 8 provides firewalld version 0.8.2. A natural conclusion is that nftables is used as a backend of the firewall. It’s a replacement of the previous engines such as iptables and others. The result is an enhanced operation, e.g. due to faster rule updates or the architecture that allows to support new protocols independently of a system kernel.

At this moment we need to explain the terminology in firewalld. Since it’s a network security suite with rules applied against packets, let’s start with the concept of zones.

A zone (area, realm) is a generalized set of firewall rules – a set that is applied to a specific situation. We can imagine an employee with their mobile workstation, who connects both via a cable in an office and remotely through Wi-Fi as well. They can bind each connection to a different zone, so they don’t need to worry about potential external attacks when working remotely and have all the trust at work for other machines in an office.

Firewalld provides a few default zones and thus a few predefined levels of trust and security. Furthermore, a program that gets installed can add its own zone, what we can see in the listing below:

$ firewall-cmd --get-zones
block dmz drop external home internal libvirt nm-shared public trusted work

As we can see, we have 11 zones at our workstation. That’s due to me using NetworkManager and libvirt, among others, that added their own zones. Since it’s impossible to discuss every existing configuration out there that additional software can create, we’ll describe only the most widely used, that would be provided with a minimal, fresh EuroLinux 8 installation. These are the zones with a short explanation and a certain application:

  • drop – implicitly reject incoming connections
  • block – implicitly reject incoming connections with an ICMP message of the rejection
  • public – no trust for devices in neighborhood with the possibility to accept certain connections. Used by default, unless another one has been specified
  • external – typical settings for a gateway from the outside – limited trust, masquerade enabled, only SSH allowed
  • internal – typical settings for a gateway from the inside – considerable trust for devices in the internal network. Thus there’s more services that are allowed, such as Cockpit, Samba or mDNS.
  • dmz – typical settings for a DMZ (demilitarized zone) – these settings are almost like the ones for the external zone, with the exception that masquerade is disabled
  • work – since this is a preset for machines at a workplace, it’s natural that machines in the network are of a high trust. Typical administrative services such as Cockpit i SSH are allowed
  • home – settings for a home network – the trust for devices is even higher. The services allowed are almost the same as these for the internal zone
  • trusted – trust for all neighborhood devices with no restrictions.

Naturally one can have a need to check a full configuration for a given zone, especially in the case of defining one’s own ones, which we’ll discuss further in the article. Since our test workstation is used as a laboratory, where virtualization is being utilized, let’s take a look at the libvirt zone details:

$ sudo firewall-cmd --list-all --zone=libvirt
libvirt (active)
  target: ACCEPT
  icmp-block-inversion: no
  interfaces: virbr0 virbr1 virbr2
  sources:
  services: dhcp dhcpv6 dns ssh tftp
  ports:
  protocols: icmp ipv6-icmp
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:
        rule priority="32767" reject

As we can see, we have 3 network interfaces bound to this zone, which checks out with the fact that this workstation is used for:

  • typical libvirt virtual machines created through virt-manager
  • Vagrant with EuroLinux images
  • a dedicated network for a certain internal project in my company.

Since these machines are treated as trusted and used as part of a laboratory, we allow them to ping each other (ICMP protocol) and connect via SSH, among others.

More advanced examples

Since this article is about practical or laboratory cases of applying a firewall, we won’t be discussing the basics of firewalld. Instead we will demonstrate its practical application. For this example let’s imagine a person who uses their mobile workstation to work both remotely, as well as on-site.

1. We want to reduce the increased risk when working remotely, so we change the aforementioned default public zone to the drop zone this way:

# firewall-cmd --set-default-zone=drop

This change takes effect immediately – both temporarily and permanently – in accordance with firewalld documentation in EuroLinux 8.

2. Next, when connecting through a cable in an office, we want to create a new zone as part of an R&D laboratory. It’s worth remembering that the workstation utilizes NetworkManager and that it controls the network. Therefore, binding an interface to another zone will be performed on NetworkManager’s layer with the `nmcli` command, rather than firewall-cmd:

# firewall-cmd --permanent --new-zone=lab
# firewall-cmd --reload
# nmcli conn modify Wired\ connection\ 1 connection.zone lab

 

If we’re using EuroLinux 8.X, it’s worth noticing that EuroLinux 9 is coming big steps. Release no. 9 does not contain the network-scripts package and what comes with this fact, there are no previous network scripts available. Therefore, instead of writing ZONE=lab to a configuration file in the directory /etc/sysconfig/network-scripts/, a long-term vision is worth implementing and thus a unified network management interface is worth applying for EuroLinux 8 and 9.

3. At last, we want to turn off temporarily (not permanently) the ability for a certain coworker computer to connect via SSH to our workstation.

We can invoke the following command:

# firewall-cmd --zone=lab --add-rich-rule='rule family="ipv4" source address="10.0.0.101" service name="ssh" accept'

This way the workstation has been configured to work for both remote work in conditions of limited trust and to a dedicated company project.

Summary

We presented the concepts and operation of our network filter, as well as a simple but practical workstation configuration guide. The process is intuitive and can be applied similarly to newer EuroLinux releases due to high compatibility between versions 8 and 9. An additional, more advanced firewall configuration will be presented in the future in the context of extensive network infrastructure design.

Authors

The blog articles are written by people from the EuroLinux team. We owe 80% of the content to our developers, the rest is prepared by the sales or marketing department. We make every effort to ensure that the content is the best in terms of content and language, but we are not infallible. If you see anything that needs to be corrected or clarified, we'd love to hear from you.