Oracle Linux local firewalls -- firewalld

A question that comes to me quite often is the question if local firewalls should be used in Linux. Often the question comes from administrators of the operating system who do not “like” to maintain the firewalls all locally and would like to have the network team to take care of this on a network level. This question is also often posed by DBA’s and developers who need to access the systems often and are involved in changes to the systems. Every time they need to have a port open or a new route between machines added they have to go through a change management process in relation to local firewalls and would rather see this is not implemented.

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.

Due to this the administrators and the security team have much more time to fight back against the attack and the overall security of the landscape is significantly raised.

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:

1. Unlike the iptables and ip6tables commands, using firewalld-cmd does not restart the firewall and disrupt established TCP connections.
2. 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.
3. 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

Joining a startup

Ever thought about working for a startup, ever decided not to do it because you thought it was finically a gamble and a risk considered to big? You might have done the right thing, if you are not able to take a financial risk and you have a family to support then joining a startup might not be the best choice for you. Specially considering that 90% of the startups fail and a lot of them fail before they make profit or even are able to pay a reasonable amount to the people who work for them.

However, for those who do have the option to take a financial risk and / or have an entrepreneurial way of thinking, for those who love the drive of people working at a startup, the upside can be big. Some startups become good running businesses and some, a very small amount of the remaining 10% will become very big.

Having joined a startup from the beginning and it becomes big, very big, the value per employee can skyrocket. And a large part of those companies do recognise the endless efforts the employees have put into it to make this happen.

As you can see in the above bubble chart, some companies have a very high value per employee. So, yes, working for a startup can be a risk. However, if it becomes a success it can become a very big success with a big financial gain. You should however never join a startup with this as a goal, join a startup for the fun and for the mindset that lives in such a company.