In the first part of this article, we wrote about high-performance packet processing at the network adapter level using XDP and eBPF, and about the possibility of achieving greater throughput with lower latency, thanks to the BBR algorithm for TCP. These two new possibilities of the RHEL8 system bring benefits to everyone, regardless of the specific application and usage of the system.

The usage of Linux kernel based systems, like RHEL is very wide. From end devices, such as telephones, tablets, computers, televisions and vehicles, through service and application servers, disk and file systems, to devices processing and controlling network traffic. They fulfill the role of mail, names and files servers. They also hosts a large number of different applications, not just web-based ones. They have their place in every area of information technology. Their usage will grow with the popularization of IoT (Internet of Things) technologies as well as the digitization, computerization and automation that is currently taking place in every part of the world.

The RHEL (Red Hat Enterprise Linux) operating system is the basis of other Red Hat solutions, which include: Red Hat Virtualization, Red Hat Ansible Automation, Red Hat Satellite, Red Hat CloudForms, Red Hat OpenShift, Red Hat OpenStack, Red Hat Ceph, Red Hat Gluster, Red Hat Hyperconverged Infrastructure, Red Hat Certificate System, Red Hat Directory Server, Red Hat Identity Management or Red Hat 3Scale. This is why new release of Red Hat Enterprise Linux is so important!

Also, many Cisco Systems products operate on the RHEL. This is not the end, because on the RHEL we can also run the Storware vProtect backup solution, LINBIT SDS (Software Defined Storage), LINBIT DRBD (Distributed Replicated Block Device), NextCloud file exchange platform, office cloud packages like Collabora Productivity and ONLYOFFICE, SAP ERP, Odoo ERP, Microsoft SQL and many other products available on the market.

All this means that our entire environment can be based on one coherent platform. The RHEL system can be installed anywhere – on a physical server, in a virtualization environment, as well as in public and private cloud. This allows you to maintain a certain standard and level of compliance, which translates into easier management and more secure and stable infrastructure for services, data and applications.

In this part, we will introduce further improvements to the new version of the RHEL system, which include new support for packet classification and filtering (nftables instead of iptables, ip6tables, ebtables and arptables), greater security and automation of the DNS service (CDS/CDNSKEY, DNS Cookies and Catalog Zones), e-mail protection in accordance with the decision of the EU on 11 December 2017 (DNSSEC and DANE), greater security and easier compliance.

New support for packet classification and filtering

The new version of the system has significantly simplified the way of handling packet classification and filtering. Previously used for this purpose 4-tools (iptables, ip6tables, ebtables and arptables) have been replaced by one – nftables.

This change reduced the amount of code associated with this functionality in the Linux kernel and eliminated the need to change the system kernel each time new protocols or support for new features in already supported protocols are needed.

With nftables, support for new features and protocols will in most cases require only software updates. This was achieved thanks to a special virtual machine in the kernel, whose task is to run the pseudo-code delivered from the user space. This code is created using the nft tool, and after compilation delivered to it through a Netlink socket.

The internal structure of iptables and nftables is based on tables containing chains, which contains rules. There are no built-in tables and chains in nftables, that are always processed in iptables, whether we need them or not. In nftables we have to create needed structure ourselves.

Things that have not changed, are the hooks to which constructed chains can be attached, such as PREROUTING, INPUT, FORWARD, OUTPUT, POSTROUTING, and the Connection Tracking System (CONNTRACK), address translation engine (NAT), packet and connection logging (daemon ulogd2) and packet queuing components. In nftables we have at the input an additional hook called INGRESS, which is located in front of PREROUTING. It allows earlier, much more efficient traffic filtering, that was possible earlier only with the use of the tc tool (queuing and traffic modeling still requires the tc tool, so nftables does not replace the tc tool).

nftables uses a different command syntax, that is more similar to structure known from the tcpdump utility. The new syntax enables more efficient and functional creation of rules, which in addition to convenient aggregation and grouping, can now also accomplish more than one task/target. For example, one rule can simultaneously block and log or mark and accept traffic, which previously required the appropriate arrangement of several rules. This is just one example, because nftables allows flexible aggregation and grouping of many elements.

Despite so many changes, the RHEL8 system administrator does not need to change much. Firewalld is still the recommended configuration tool. Only what works underneath has changed (backend). This interface (frontend) can be changed using systemctl tool from firewalld to nftables or iptables. However, this will not change what works underneath, where always will work nftables.

Another advantage of nftables is the ability to make all changes atomically and quickly, regardless of whether we add/remove 1-rule or execute a long script.

In iptables you can only replace the entire rule table. Each use of the iptables command in script replaces all running rules again. Regardless of whether we add or remove only one of them, a new configuration is being built, updated with this 1-change, and then there is a switch from the old configuration to the new one. With each subsequent rule, such a change takes longer, and in addition the firewall is temporarily not fully functional – by the time the entire script will complete. Hence, the recommended way to make changes for iptables is to call iptables-restore, which changes the entire configuration when the “COMMIT” line is read. Unfortunately, in that case we do not have the functions that the scripting languages give us.

In nftables, even whole scripts support is implemented atomically. After indicating the script with the “-f” option of the nft command, it is processed in memory, where the nft configuration is built. After completing the script, the contents of the nftables configuration are changed in an atomic way.

Increased security and automation of the DNS service

The new version of the BIND name server service has features that significantly improve security, and DNSSEC and Secondary Servers automation.

The improvement of DNSSEC automation was achieved thanks to DNSSEC Key Manager, which based on the defined policy, deals with the creation of new ZSK/KSK keys.

Another automation in this area, is the usage of CDS (Child DS) and CDNSKEY (Child DNSKEY) resource records for automatic cooperation with Parent Zone in the process of changing DNSSEC keys.

In RHEL8 you can also automate the creation and removal of Secondary Servers configurations, during new zone creation or old zone removal process on a Primary Server. This is done through a special zone and the well-known AXFR/IXFR mechanism. This zone contains information about zones that should be served by Secondary Servers. This functionality is called Catalog Zones.

Another improvement is NTA (Negative Trust Anchor), which gives the possibility to disable DNSSEC validation of selected DNS zones. A very useful feature that allows you to temporarily exclude from the validation incorrectly configured DNS zones.

Finally, it is worth to not forget about DNS Cookies, which allows detection of false responses from not asked servers (off-path spoofed responses) and determining whether someone is not spoofing a legitimate client by sending false queries (spoofed-source queries).

E-mail security in line with EU decision

The RHEL8 e-mail service supports DANE (DNS-based Authentication of Named Entities).

Without proper security, a certificate for our domain can be issued by any CA (both those with the best and those with the worst reputation). Thanks to the DANE, we have the opportunity to indicate the exact certificate we want, which means that those issued by others CA’s will not be reliable.

DANE allows to indicate a valid certificate for the service in the DNS structure. Thanks to this approach, we can even sign the trusted certificate ourselves (without the need to use trusted CA services). Due to the fact that this information is stored in the DNS structure, DNSSEC (Domain Name System Security Extensions), which is also supported in RHEL8, is also required for complete security.

The email standard also does not enforce encryption. Thus, a fake MX record is able to redirect messages to a malicious server that enforces transmission without encryption. Encrypted transmission is also not completely secure, because the certificate presented by the server must match the name indicated in the MX record (in this case false). Not the domain name from the e-mail address (recipient’s domain).

That is why we need DNSSEC and DANE for complete mail security. DNSSEC ensures that DNS data are real and unmodified. DANE ensures that the transmission takes place in an encrypted manner without intermediaries.

The European Commission, in its executive decision of 11 December 2017, which is concerning the implementation of technical ICT solutions, writes about the use of, among others DNSSEC and DANE as one of the main mechanisms for protecting email. Standardization is the main goal of the 2020 strategy adopted by the European Commission. More on this topic can be found on the EUR-Lex website (EU Law)¹.

Greater security and easier compliance

In the RHEL8, it is much easier to ensure a consistent configuration policy for the algorithms and cryptographic protocols (System-wide Cryptographic Policy) and the way of handling authentication and authorization throughout the entire system.

A new tool has been built into the system, that allows central consistency in the configuration of many different services in the area of used protocols and algorithms (TLS, IPSec, SSH, DNSSEC and Kerberos). This tool is named update-crypto-policies. More about it can be found on the Red Hat blog². In addition to this, autoconfig has been replaced by authselect tool. This new tool gives the opportunity to switch profiles used by the components of the system for authentication and authorization. In addition to ready built-in profiles for NIS, Winbind and SSSD, we can also create our own.

The new version of the Red Hat system also has very extensive mechanisms for auditing system events, detecting anomalies and compliance verification with accepted security standards. The compliance with security standards is implemented through special SCAP (Security Content Automation Protocol) profiles, which can be subject to cyclic verification on each of the systems. In this way, you can save a lot on very expensive security audits. Thanks to appropriate auditing, which is built into each of the Red Hat products, you know exactly what, when and by whom it was done in the system.

Automatic compliance verification, prevention and system recovery is possible thanks to better integration of RHEL8 with Red Hat Ansible Automation, Red Hat Satellite and Red Hat CloudForms. Of course, this also applies to Red Hat Insights, which we wrote more about in the previous part of this article. The combination of these solutions allows automation and maintenance of compliance and consistency in the IT environment, which is a key element of security. This is illustrated by the movie available on the Red Hat website.

More about what’s new in RHEL8 available in:

• Why to choose Red Hat Enterprise Linux 8? – Part I,
• Web-based management interface, sessions recording. RHEL 8 part III.

Read more about Storware vProtect – a single platform that is able to backup multiple virtualization platforms to multiple backup providers.

—
¹ https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32017D2288
² https://www.redhat.com/en/blog/consistent-security-crypto-policies-red-hat-enterprise-linux-8