As I do work on Linux (and other operating systems) regularly in a changing role I do sympathies with the statements and do understand the questions and reasons behind this. From one of my roles as a security consultant and architect I do however not agree with the statement that security should be managed by the network team and local firewalls are nothing more than an annoyance.
A recent post on a mailing list around a different subject gave me the opportunity to again come back to my topic of defending the use of local firewalls.
“I am particularly interested in confirming that low-risk servers can’t be used as a stepping stone to attack a high-risk server, or as a means of unauthorised data egress.”
The above quote is out of context due to sharing restrictions, however, the full mail started a discussion on the topic of local firewalls. Taking the above quote already provides some clues on why local firewalls are important.
If we take the below architecture deployment for a “standard” implementation of an Oracle based landscape. The landscape is using Oracle Linux and hosts Oracle software.
Most implementations are based upon the above principle, they will have a DMZ which hosts the external facing services and those machines will connect to the back-end of the application which in our case is an Oracle RAC database implementation in combination with an Oracle NoSQL Key-Value store.
In principle nothing is wrong with this picture, if all is done correctly the external facing ports will only allow traffic on the ports that are needed and the firewall will block all other traffic. The same will be applicable for the firewall between the DMZ and the back-end systems. However, in case that an attacker is able to gain access to one of the hosts on the DMZ you will have the situation that the external firewall is not protecting you against communication between the compromised host and the other hosts in this specific VLAN. The attacker will be able to communicate extremely more easy between the hosts by making use of the lack of a firewall between those hosts.
The below implementation is showing a more rigid model in which all host have a local firewall, in case one of the hosts in compromised the ability of an attacker is limited to that host only and the options to connect to other hosts is extremely limited.
Many people opt against implementing local firewall rules due to the fact that it introduces a management overhead. In my personal opinion the use of local firewalls should however be promoted as a standard and only being considered to not implement by exception rather than the other way around. Currently you see that the default is to not implement it and only in some exceptional cases customers decide to implement it.
Now, if you implement local firewalls on Linux the most common solution to look for is iptables. However, as from Oracle Linux 7 the default firewall is no longer iptables anymore, it will be using a firewalld firewall instead. Firewalld is using the well known netfilter solution. Netfilter is the packet filtering framework inside the Linux 2.4.x and later kernel series. A netfilter kernel component consisting of a set of tables in memory for the rules that the kernel uses to control network packet filtering.
Oracle states the following about firewalld-based firewalls within the OL7 documentation:
The firewalld-based firewall has the following advantages over an iptables-based firewall:
- Unlike the iptables and ip6tables commands, using firewalld-cmd does not restart the firewall and disrupt established TCP connections.
- firewalld supports dynamic zones, which allow you to implement different sets of firewall rules for systems such as laptops that can connect to networks with different levels of trust. You are unlikely to use this feature with server systems.
- firewalld supports D-Bus for better integration with services that depend on firewall configuration.
Especially the point about dynamic zones is very interesting if you need to maintain a large set of firewalls. You can create zones and apply them for the systems where they are needed, however ship all your installations with it. For example a default installation could contain a set of rules (zones) for a number of situations in your enterprise footprint, you activate them where they are appropriate.
To configure the settings of firewalld you can make use of a GUI by calling firewall-config or you can use the CLI by calling firewall-cmd