Stateful Inspection Firewall
This post will focus on the stateful firewall and stateful inspection firewall. We will briefly touch on basic packet filtering, firewall traffic flow, reflexive access list, and where they fit in the world of the stateful firewall. Firstly, what is a stateful firewall? In short, firewalls are network functions specifically tailored to inspect network traffic. Upon inspection, the firewall will decide to carry out specific actions, such as forwarding or blocking it according to some criteria. In such a way, we can see firewalls as security network entities with several different firewall types.
The different firewall types will be used in other network locations in your infrastructure, such as distributed firewalls at a hypervisor layer. You may have a stateful firewall close to workloads while a packet-filtering firewall is at the network’s edge. As identity is now the new perimeter, many opt for a stateful inspection firewall nearer to the workloads. With virtualization, you can have a stateful firewall per workload, commonly known as virtual firewalls.
- Highlighting a stateful firewall
A stateful firewall is a form of firewall technology that monitors incoming and outgoing network traffic and keeps track of the state of each connection passing through it. It acts as a filter, allowing or denying traffic based on configuration. Stateful firewalls are commonly used to protect private networks from potential malicious activity.
They can be combined with other security measures, such as antivirus software and intrusion detection systems. Stateful firewalls can be configured to be both restrictive and permissive and can be used to allow or deny certain types of traffic, such as web traffic, email traffic, or FTP traffic. They can also control access to web servers, databases, or mail servers. Additionally, stateful firewalls can detect and block malicious traffic, such as files, viruses, or port scans.
Before you proceed, you may find the following helpful post for pre-information:
Stateful Inspection Firewall
- A key point: Video on stateful firewall inspection.
In the following video, we will address stateful firewall inspection. Generally, we interact directly with the application layer and have networking and security devices working at the lower layers. So when host A wants to talk to host b, it will go through several communication layers with devices working at each layer. A device that works at one of these layers is a stateful firewall that can perform the stateful inspection.
- A key point: Back to basics with the firewall concept
The term “firewall” comes from a building and automotive construction concept of a wall built to prevent the spread of fire from one area into another. This concept was then taken into the world of network security. The firewall’s assignment is to set all restrictions and boundaries described in the security policy on all network traffic that passes the firewall interfaces. Then we have the concept of firewall filtering that compares each packet received to a set of rules that the firewall administration configures.
These exception rules are derived from the organization’s security policy. The firewall filtering rules state that the contents found in the packet are either allowed or denied. Therefore, based on firewall traffic flow, it continues to its destination if the packet matches an allowed rule. If the packet matches a deny rule, the packet is dropped.
Firewall filtering rules
Firewall filtering rules help secure a network from unauthorized access and malicious activity. These rules provide a layer of protection by controlling traffic flow in and out of the network. Firewall filtering rules can allow or deny traffic based on source and destination IP addresses, ports, and protocols.
Firewall filtering rules should be tailored to the specific needs of a given network. Generally, it is recommended to implement a “deny all” rule and then add rules to allow only the specific traffic that is necessary. This helps to block any malicious activity while legitimate traffic is allowed. When creating firewall filtering rules, it is essential to consider the following:
- Make sure to use the most up-to-date protocols and ports.
- Be aware of any potential risks associated with the traffic being allowed.
- Use logging to monitor traffic and ensure that expected behavior is occurring.
- Ensure that the rules are implemented consistently across all firewalls.
- Ensure that the rules are regularly reviewed and updated as needed.
What Is a Stateful Firewall?
The stateful firewall examines Layer 4 headers and above, analyzing firewall traffic flow and enabling support for Application-aware inspections. Stateful inspection keeps track of every connection passing through their interfaces by analyzing packet headers and additional payload information.
Stateful Firewall Operation
You can see how filtering occurs at layers 3 and 4 and that the packets are examined as a part of the TCP session.
The topmost part of the diagram shows the three-way handshake, which takes place before the commencement of the session and is explained as follows.
- Syn refers to the initial synchronization packet sent from one host to another; in this case, the client to the server.
- The server sends an acknowledgment of the syn, and this known as syn-ack
- The client again sends an acknowledgment of this syn-ack, thereby completing the process and initiation of the TCP session.
- Both parties can end the connection anytime by sending a FIN to the other side. This is similar to a telephone call where the caller or the receiver could hang up.
State and Context.
The two important terms to understand are state and context information. Filtering is based on the state and context information the firewall derives from a session’s packets. The firewall will store state information in its state table, updated regularly. For example, in TCP, this state is reflected in specific flags such as SYN, ACK, and FIN. Then we have the context. This includes source and destination port, IP address, and sequence numbers of any metadata. The firewall also stores this information and updates regularly based on traffic flowing through the firewall.
Firewall state table
A firewall state table is a data structure that stores information about the connection state of a network firewall. For example, it determines which packets are allowed to pass through the firewall and which are blocked. The table contains entries for each connection, including source and destination IP addresses, port numbers, and other related information.
The firewall state table is typically organized into columns, with each row representing an individual connection. Each row contains the source and destination IP address, the port numbers, and other related information. For example, the source IP address and port number indicate the origin of the connection, while the destination IP address and port number indicate the destination of the connection. Additionally, the connection’s state is stored in the table, such as whether the connection is established, closed, or in transit.
The state table also includes other fields that help the firewall understand how to handle the connection, such as the connection duration, the type of connection being established, and the protocol used.
So whenever a packet arrives at a firewall to seek permission to pass through it, the firewall checks from its state table if there is an active connection between the two points of source and destination of that packet. The endpoints are identified by something known as sockets. A socket is similar to an electrical socket at your home which you use to plug your appliances into the wall.
Similarly, a network socket consists of a unique IP address and a port number and is used to plug in one network device to the other. The packet flags are matched against the state of the connection to which it belongs, which is allowed or denied based on that. For example, if a connection already exists and the packet is a Syn packet, it must be denied since Syn is only required at the beginning.
Stateful Firewall and Interface Configuration
It would be best to consider the interfaces in firewall terms when considering a stateful inspection firewall. For example, some interfaces are connected to protected networks, where data or services must be secured. Others connect to public or unprotected networks, where untrusted users and resources are located.
The top portion of the diagram below shows a stateful firewall with only two interfaces connecting to the inside (more secure) and outside (less secure) networks. The bottom portion of the figure shows the stateful inspection firewall with three interfaces connected to the inside (most secure), DMZ (less secure), and outside (least secure) networks. The firewall has no concept of these interface designations or security levels; these concepts are put into play by the inspection processes and policies configured.
So you need to explain to the firewall which interface is at what security level. And this will effect the firewall traffic flow. Some traffic will be denied by default between specific interfaces with default security levels.
Interface configuration specific to ASA
Since version 7.0 of the ASA code, configuring interfaces in the firewall appliance is very similar to configuring interfaces in IOS-based platforms. If the firewall connection to the switch is an 802.1q trunk (the ASA supports 802.1q only, not ISL), you can create sub-interfaces corresponding to the VLANs carried over the trunk. Do not forget to assign a VLAN number to the sub-interface. The native (untagged) VLAN of the trunk connection maps to the physical interface and cannot be assigned to a sub-interface.
Stateful Inspection and full state of active network connections
So we know that the stateful firewall monitors the full state of active network connections and constantly analyses the complete context of traffic and data packets. Then we have the payload to consider. The payload is part of transmitted data that is the intended message, along with the headers and metadata sent only to enable payload delivery.
Payloads offer transaction information, which can protect against some of the most advanced network attacks. For example, deep packet inspection configures the stateful firewall to deny specific Hypertext Transfer Protocol ( HTTP ) content types or specific File Transfer Protocol ( FTP ) commands, which may be used to penetrate networks.
Stateful inspection and Deep Packet Inspection (DPI)
The following diagram shows the OSI layers involved in the stateful inspection. As you can see, Stateful inspection operates primarily at the transport and network layers of the Open Systems Interconnection (OSI) model for how applications communicate over a network. However, it can also examine application layer traffic, if only to a limited degree. Higher up in the OSI layers is called Deep Packet Inspection (DPI).
DPI is considered to be more advanced than stateful packet filtering. It is a form of packet filtering that locates, identifies, classifies, and reroutes or blocks packets with specific data or code payloads that conventional packet filtering, which examines only packet headers, cannot detect. Many firewall vendors will have stateful inspection and DPI on the same appliance. However, a required design may require a separate appliance for compliance or performance reasons.
Stateful Inspection Firewall
What is a stateful firewall?
A stateful firewall keeps track of and monitors the state of active network connections while analyzing incoming traffic and looking for potential traffic and data risks. The state is a process or application’s most recent or immediate status. In a firewall, the state of connections is stored, providing a list of connections against which to compare the connection a user is attempting to make. Stateful packet inspection is a technology stateful firewalls use to determine which packets to allow through the firewall. It works by examining the contents of a data packet and then comparing them against data about packets that have previously passed through the firewall.
Stateful Firewall Feature
Stateful firewall and packet filters
The stateful firewall contrasts packet filters that match individual packets based on their source/destination network addresses and transport-layer port numbers. Packet filters have no state or check the validity of transport layer sessions such as sequence numbers, Transmission Control Protocol ( TCP ) control flags, TCP acknowledgment, or fragmented packets. The critical advantage of packet filters is that they are fast and processed in hardware. Reflexive access lists are closer to a stateful tool than packet filters. Whenever TCP or User Datagram Protocol ( UDP ) session permits, matching return traffic is automatically added.
The disadvantage of reflexive access lists is they cannot detect / drop-malicious fragments or overlapping TCP segments. Transport layer session inspection goes beyond reflexive access lists and addresses fragment reassembly and transport-layer validation. Application-level gateways ( ALG ) add additional awareness. They can deal with FTP or Session Initiation Protocol ( SIP ) applications that exchange IP addresses and port numbers in the application payload. These protocols operate by opening additional data sessions and multiple ports.
Simple packet filters for a perfect world
In a perfect world where most traffic exits the data center, servers are managed with regular patching, servers listen on standard TCP or UDP ports, and designers could get away with simple packet filters. But in the real world, each server is a distinct client, has multiple traffic flows to and from the data center and back-end systems, and unpredictable source TCP or UDP port number makes using packet filters impractical.
Instead, implement additional control with deep packet inspection for unpredictable scenarios and poorly managed servers. Stateful firewalls keep state connections and allow traffic to return dynamically. Return traffic is permitted if the already state for that flow is in the connection table. The traffic needs to be part of a return flow. If not, it’s dropped.
- A stateless firewall – predefined rule sets
A stateless firewall uses a predefined set of rules. If the arriving data packet conforms to the rules, it is considered “safe.” The data packet is allowed to pass through. With this approach to firewalling, traffic is classified instead of inspected. The process is less rigorous compared to what a stateful firewall does. Remember that a stateless firewall does not differentiate between certain kinds of traffic, such as Secure Shell (SSH) versus File Transfer Protocol (FTP). A stateless firewall may classify these as “safe” and allow them to pass through, which can result in potential vulnerabilities.
A stateful firewall holds context across all its current sessions rather than treating each packet as an isolated entity, as with a stateless firewall. With stateless inspection, lookup functions impact the processor and memory resources much less, resulting in faster performance even if traffic is heavy.
The Stateful Firewall and Security Levels
Regardless of the type of firewall mode, or single or multiple contexts, Adaptive Security Appliance ( ASA ) permits traffic based on a concept of security levels configured per interface. And is an important point to note for ASA failover and how you design your failover firewall strategy. The configurable range is from level 0 to 100. Every interface on ASA must have a security level.
The security level allows configured interface trust-ability and can range from 0, which is the lowest, to 100, which is the highest—offering ways to control traffic flow based on security level numbering. The default security level is “0”, configuring the name on the interface “inside” without explicitly entering a security level; then, the ASA automatically sets the security level to 100 ( highest ).
By default, based on the configured nameif, ASA assigns the following implicit security levels to interfaces:
- 100 to a nameif of inside.
- 0 to a nameif of outside.
- 0 to all other nameifs.
Without any configured access lists, ASA implicitly allows or restricts traffic flows based on the security levels:
Securty Levels and Traffic Flows
Firewall traffic flow between security levels
By default, traffic can flow from highest to lowest without explicit configuration. Also, interfaces on the same security level cannot directly communicate, and packets cannot enter and exit the same interface. Override the defaults, permit traffic by allowing high to low; explicitly configure ACLs on the interface or newer version use-global ACL. Global ACL affects all interfaces in all directions.
Firewall traffic flows
Inter-Interface communication ( Routed Mode only ); enter the command “same-security-traffic permit inter-interface” or permit traffic explicitly with an ACL. This will give design granularity and allows the configuration of more-communicating interfaces. Intra-Interface communication; configured for traffic hair-pining ( leaves on the outside interface and goes back out the outside interface ). Useful for Hub and Spoke VPN deployments; traffic enters an interface and routes back out the same interface – Spoke to Spoke communication. To enable Intra-Interface communication, enter the command “same-security-traffic permit intra-interface.”
Default inspection and Modular Policy Framework ( MPF )
ASA implements what is known as Modular Policy Framework ( MPF ). MPF controls WHAT traffic is inspected, such as Layer 3 or Layer 4 inspection of TCP, UDP, ICMP, an application-aware inspection of HTTP, or DNS. It also controls HOW traffic is inspected based on connection limits and QoS parameters.
ASA inspects TCP / UDP from the inside (higher-security level ) to the outside ( lower-security level ). This cannot be disabled. No traffic inspection from outside to inside unless it is from an original flow. An entry is created in the state table, so when flows return, it checks the state table before it goes to implicit deny ACL. The state is created during traffic leaves, so it checks the specific connection and application data when the return flows come back. It does more than Layer 3 or 4 inspections and depends on the application.
It does not, by default, inspect ICMP traffic. Enable ICMP inspection with a global inspection policy or explicitly allow with an interface or Global ACLs. ASA global policy affects all interfaces in all directions. The state table is checked before any ACL. A good troubleshooting tool, Packet Tracer, goes through all inspections and displays the order the ASA is processing.
Main Checklist Points To Consider
- DMVPN - May 20, 2023
- Computer Networking - April 7, 2023
- eBOOK – SASE Capabilities - April 6, 2023
Great article! Thanks for sharing.