by 
Once it was our impenetrable castle. Later it just became like a wall. Then, it transformed into a fence. I am talking about firewalls. After all this ordeal of evolution, it again tries to gain a central role in security even at the dawn of the software-defined networks (SDN). And this role is based on controlling access. But do we really understand firewalls, what are they and what are they supposed to be?
Without exception, everybody in the security industry self-assuredly expresses their understanding of firewalls. For some, it is not even an important component! Some do not consider it in terms of Internet-facing applications by just thinking of replacing it with software-based access controls. All of these and similar perspectives show us the signs of misunderstandings due to lack of knowledge and hands-on practices on firewalls.
It is a fact that in recent years the security industry, firms and specialists tend to intensify their resources towards software-defined networks (SDN), network functions virtualization (NFV), zero trust, serverless architecture, containers and of course artificial-intelligence and/or machine learning technologies. In the light of these new advances progressing at an unprecedented pace, our security paradigms must evolve accordingly too. But some technical approaches and concepts cannot change even if you want to force change. Here I am going to try to explain some basics which are misunderstood, overestimated, underestimated and/or unchangeable about firewalls.
Firewall as a Filtering Device
Firewalls do just a filtering job according to a source, destination or port. And also user-based filtering is used in next-generation firewalls. But firewalls do not protect a network from any attack or problem in the allowed access. That is, if you allow a port for a specific source-destination pair, firewalls do not inspect or tamper connection particularly in allowed access but next-generation firewalls do to some extent. So, next-generation firewalls inspect its connections like an IPS with respect to known malicious patterns or attack signatures. But firewalls only protect you from disallowed access or ports and they do not protect you for open ports. At this point, you must be cautious about additional layered protections because an open port means an open gate. In this case, of course, firewalls’ firmware vulnerabilities are out of this post’s scope.
Firewall as a Superman
Besides filtering, using firewalls simultaneously as a multitasking security tool like IPS, DDoS protection, gateway antivirus, SSL VPN or web proxy may turn out a single-point-of-failure unless you plan any redundancy. These type of firewalls were used to be known as UTM (Unified Threat Management) systems but nowadays they have evolved into NGFW (next-generation firewall) systems which have more capabilities, throughput and so on.
A large enterprise should avoid using an NGFW as a multipurpose security guard. NGFWs should just be used for firewall-aimed tasks and the remaining tasks should be done with other tools in their related layer. But if we are talking about SMEs (Small Medium Enterprise) whose budget is not enough for multiple security tools, they can use UTM or NGFW as a multitasking tool as long as a good redundancy plan is met.
Firewall as a Software Application
There are a dozen software-based firewall applications. A software firewall is a software application that can be installed on a standard physical and/or virtual server. Hence, a standard server can transform into a hardware-like firewall. But using software firewalls is not an actual replacement for hardware firewalls. At this point, a virtualized firewall concept in cloud services should not be confused with a software-firewall that is installed on a standard server.
Hardware firewalls have their customized circuits, processors, chips, rams, storages, logic and firmware whereas software firewalls depend on the standard resources of the servers on which they are installed. And hardware firewalls are completely adjusted for handling a connection in accordance with their resources. For example, a processor type is a very important component of hardware firewalls to handle a connection carefully.
However, a firewall as a software application which is installed on a standard server relies on its server’s resources and/or virtual machine environment. So, you could not consider software firewalls independently of the server resources such as power, processor, CPU, ram and so on. This situation also affects firewalls performance and its security perceptiveness too.
If you manage an enterprise-grade network, you need an enterprise-level hardware firewall and you should not use software-based firewall applications. And if you offer an internet-faced service, you should never use a software firewall application to protect your network. If you would like to use virtualized firewall service on the cloud, you should be aware of its resources and environment configurations. And it must be completely dedicated to firewall-type customization.
Firewall as a Software-Defined Network (SDN) Controller
Before diving into firewall related issues in a software-defined network (SDN), we need to briefly express the concept of SDN as an emerging technology. SDN is a software-defined and software-controlled network infrastructure which offers virtualized functions and centralized controls for more automation, flexibility and orchestration. It mainly utilizes OpenFlow protocol but there are also other protocols. And the most critical thing in SDN is to replace firewalls with SDN switches or controllers, aka SDN firewall. But this is where the problem arises. SDN firewalls are not able to behave like the firewalls as we know.
The foremost de facto standard of today’s firewall is its ‘stateful’ feature. Even when you do not need the stateful feature, it is a must. Also, it is not wrong to entitle today’s firewalls as a “stateful firewall“.
A stateful firewall inspects and handles the connections passing through it by following the entire session or connection from the beginning to where the packages are destined to. During this end-to-end traffic controlling, a stateful firewall can follow routes, paths and the fate of connection (sync, open, close, reset, establish, acknowledge etc) and can implement some functions by following its settings. It stores a state table for implementing security policies. All of these ensure patroling unauthorized, spoofed or forged connections by operating on the Layer 3-4 of the OSI. So, it is very important to set Layer 3 (Network) as a fixed security base.
SDN provides a software-based network system by separating its control and data plane. The separation of the control and data planes complicates security services such as a firewall. Since SDN switches only send a connection’s initial packets to their controllers, it will become impractical as a stateful firewall due to using the SDN solutions’ switches as packet filtering by depending on SDN controllers.
OpenFlow protocol’s forwarding plane works almost in a stateless-manner and it provides very limited access to packet-level information in the controller. Due to this situation, it can not monitor the flow of connection without help of the controller. Hence, you will encounter a stateful packet inspection problem in SDN firewalls. This causes a significant amount of workload for the controller and increases state held across multiple controllers. Even more, OpenFlow uses connection states in which is formulated into time-bound flow rules. That is, rather than dealing with traditional session establishment state, the switches use a defined time-out for connections which means the gate is left open until the expiration. Consequently, an attacker can then use the switches’ renewal time-out to finish the attack.
And SDN firewalls, switches and/or controllers operates generally on Layer-4-to-7 of the OSI. So, from the perspective of network layer security, you probably encounter losing the ability to block in that Layer 3 of the OSI. Since they run above Layer 3 of the OSI, they will become more dependent on application-layer and/or software control.
Because SDN switches are not necessarily stateful and many of SDNs may work in a stateless-manner, they can not provide the same level of protection as a stateful firewall. For additional stateful firewall protection, you must use the SDN policies to steer the traffic with service-chaining toward a stateful packet inspection Network Functions Virtualization (NFV) firewall.
You should be careful about SDN systems and be prepared to change your all policies, standards and security approach accordingly. This is state-of-the-art!
Firewall as a Poorly Managed Security Tool
When you treat firewalls as a simple security tool, soon after some configurations, rules and policies begin to be overlooked. This simplistic perspective damages security posture overall. The easiest rule or policy can turn into an Achilles’ heel at the end of the day. So, some vital practices may save you during your administration of firewalls:
- ANY port rule: none of your rules in policy needs an “ANY port” rule. Otherwise, this means there is no firewall, too. For example, an ANY port rule between different network segments, IP addresses and/or interfaces causes losing of visibility and expanding of attack surface consequently.
- ANY destination rule: inside a network, you should be very careful when you write a rule which includes “ANY destination”. A source headed to “any destination” can lead to any catastrophic results. These type of rules must be minimum and kept under control with other security measures.
- Servers under the same IP segment and/or network: Firewalls operate according to their network interfaces. For example, a network interface or segment means up to 254 usable IPs (with CIDR “/24”). All machines or servers under this specific network can talk to each other without visibility of the firewall. So, if you need more granular segmentation and visibility, you must deploy micro-segmentation for your networks. This resolves blindness for security monitoring of the same network segment (lateral) movements.
The featured image credit: Jakub Hałun via Wikimedia Commons
