Context-Aware Firewall

Context- aware firewall enhances visibility at the application level and helps to override the problem of application permeability. Visibility at the application layer helps you to monitor the workloads better from a resource, compliance, and security point of view.

Firewall rules cannot consume application IDs. Context-aware firewall identifies applications and enforces a micro-segmentation for EAST-WEST traffic, independent of the port that the application uses. Context-aware or application-based firewall rules can be defined by defining Layer 7 service objects. After defining Layer 7 service objects in rules, you can define rules with specific protocol, ports, and their application definition. Rule definition can be based on more than 5-tuples. You can also use Application Rule Manager to create context-aware firewall rules.

Context-aware firewall is supported starting in NSX Data Center for vSphere 6.4.

All host clusters in an existing infrastructure managed by NSX Data Center for vSphere must be upgraded to NSX Data Center for vSphere 6.4.0 or later.

Types of Firewall

Firewall takes action based on one or a combination of different L2, L3, L4, and L7 packet headers that are added to the data as it moves through each layer of the TCP/IP model.

In layer 3 or layer 4 firewall, the action is taken solely based on source/destination IP, port, and protocol. The activity of network connections is also tracked. This type of firewall is known as a stateful firewall.

Layer 7 or context-aware firewall can do everything that the layer 3 and layer 4 firewall do. Also, it can intelligently inspect the content of the packets. For example, a layer 7 firewall rule can be written to deny all HTTP requests from a specific IP address.

Rule Definition and Packet Capture

You can create more than 5-tuples rules for context-aware firewall. You can keep adding as many tuples as required to create the correct rule. Protocol and user are the only attributes supported, and you can have either user or protocol per rule. These can be in the standard SRC/DEST fields, or added at the end for extra attributes.

There are 7-tuples in the following rule:

Source	Destination	Service	Direction	Action	Attributes
location-set-1	Iport-set-1	HTTPS	INOUT	Allow	TLS-V10

Figure 1. Packet Processing in the Context-Aware Firewall

When a context-aware firewall is configured for the virtual machine, the Distributed Deep Packet Inspection (DPI) attributes must also be matched with the 5-tuples. This is where rules are processed and validated again and the correct rule is found. Depending on the action, a flow is created or dropped.

Here is how a rule is processed for an incoming packet:

1. Upon entering a DFW filter, packets are looked up in the flow table based on 5-tuple.
2. If no flow/state is found, the flow is matched against the rule-table based on 5-tuple and an entry is created in the flow table.
3. If the flow matches a rule with a Layer 7 service object, the flow table state is marked as “DPI In Progress”
4. The traffic is then punted to the DPI engine. The DPI Engine determines the APP_ID.
5. Once the APP_ID has been determined, the DPI Engine sends down the attribute which is inserted into the context table for this flow. The ”DPI In Progress” flag is removed and traffic is no longer punted to the DPI engine.

6. The flow (now with APP-ID) is reevaluated against all rules that match the APP_ID, starting with the original rule that was matched based on 5-tuple, and ensuring that no matching L4 rules take precedence. The appropriate action is taken (allow/deny) and the flow table entry is updated accordingly.

It is possible to have a context-aware firewall rule exactly like an L3 or L4 rule, without really defining the context. If that is the case, the validation step might be performed to apply the context, which might have more attributes.

Context-Aware Firewall Workflow