Skip to main content

Firewall Rules Coexistence

Many customer environments already run applications that configure or depend on the host firewall, such as:

  • Native operating system firewalls (ex: Windows defender)
  • Container applications (ex: Docker)
  • Endpoint security or monitoring agents (ex: Crowdstrike, Solarwinds)
  • Application-specific firewall rules (ex: Acquity)

The Xshield Agent requires full control of the host firewall to implement Zero Trust Security Policies. However, taking full control causes above category of applications to be impacted that results in improper working of those applications. This document describes the different situations under which the Xshield Agent can be configured to co-exist with these applications so that they can continue to work; Of course, this will not accomplish the desired Zero Trust Security Policies in some cases and is documented for customer awareness.

Xshield Zero Trust Security Principles​

Zero Trust Security Policy does not allow for co-existence of rules from other applications. This is directly driven by the Xshield agent

  • writing its rules at the highest priority in the host firewall table
  • supporting only whitelisted policies (all non-matching traffic are dropped by explicit deny rule)

The above two properties ensure that traffic cannot match the rules written by other applications and will get discarded causing impact to the application.

Since those applications require their rules to be present in the host firewall table to successfully operate, the Xshield agent needs to be able to operate in a firewall coexistence mode. This may require change to the Xshield Agent’s Zero Trust principle to accommodate the other applications.

This document will focus on the various known coexistence use cases and how it can be solved and the behavior change to the Zero Trust Security Principles.

Windows Host Firewall (WFP)​

The Xshield agent controls the Windows Host Firewall by writing rules to the Windows Filtering Platform (WFP) which is the single decision engine on the operating system. On Windows, majority of the applications will write host firewall rules using a host firewall management application known as Microsoft Defender Firewall (Defender). There are other network and security applications/tools that may write to the WFP directly.

Coexistence with Microsoft Defender Firewall​

Most of the Windows applications use the Defender to write rules on to the WFP (Microsoft Defender is also known as the Microsoft Firewall). Hence, it is very important to have a coexistence mode with the Defender so as to not impact the working of all those applications using Defender. By moving the explicit default deny rule from the Xshield’s WFP table (higher priority) to the Microsoft Defender Firewall’s WFP table (lower priority). This ensures that the packet will get a chance to match against the rules written in the Defender’s WFP table; otherwise, they eventually match the explicit default deny rule preserving the Zero Trust Security Principles.

Linux Firewall (nf_tables)​

Modern versions of Linux Operating Systems using nf_tables as the host firewall to manipulate the Netfilter kernel table, which is the single decision point in packet matching.

Newer Linux versions continue to support writing rules using ip_tables, but under the covers can convert them to nf_tables rules thereby, pushing them to the same decision point.

Older versions of Linux that use only ip_tables will continue to write directly to the kernel Netfilter table. This rule table will be separate from the rule tables created by nf_table with the nf_table’s rules getting higher priority over the ip_table rules. (Linux does honor a deny rule to have a higher priority irrespective of in which table the rule is present).

Applications using nf_tables​

docker is the most common application that falls in this category. docker uses nf_tables to write rules to allow communication (including operations such as NAT) between the docker containers. If connections within the docker environment do not match their rules, it will break the application.

If Xshield agent programs its rules on nf_tables, then it will have the highest priority (as the first INPUT/OUTPUT chain) and its default deny policy will match packets belonging to the docker connections causing disruption to that application.

Customer must identify upfront (before any enforcement) as to whether such applications are running on the Linux server. If so, they would need to enable the co-existence mode before performing any security function (including applying block template rules while in unsecure or test mode) to line up the rules so as to allow the docker application to work.

With coexistence enabled on the Xshield agent, it allows the packets belonging to the docker connections to match the rules created by the docker application. This ensures that application to work as per its requirement.

Applications using ip_tables converted to nf_table rules​

The behavior here is no different than two applications programming the nf_tables.

Applications using ip_tables​

Linux treats the nf_table and ip_tables as two separate tables and evaluates the rule results from both tables simultaneously. Packets that match rules in ip_tables will be processed accordingly. This allows for the docker application to continue to work. There is one caveat here that if the packet matches a block rule in ip_tables then that will get priority over any matching allow rule in nf_table. This may cause a traffic whitelisted on Xshield agent to be dropped (if there is a matching deny rule in ip_tables). This is very highly unlikely though.

Firewalld Application​

On Linux systems where firewalld is enabled, Xshield currently cannot enforce firewall policies without impacting existing firewalld-managed rules. We are actively working on a firewall coexistence capability that will allow Xshield to program its rules alongside firewalld without disabling it; this enhancement will be delivered in a future release.

Summary​

As evident in the above use cases, there are situations in which there are conflicts between the firewall tables created by the Xshield agent and other applications. Users must review their situation correctly and apply the recommendations so that there is no impact to their existing applications.

Appendix

Coexistence with Other Networking/Security Applications - CrowdStrike Quarantine​

Some networking or security products such as CrowdStrike program rules into the host-based firewall;

  • Crowdstrike writes rules to the host firewall when it quarantines an asset.
  • When Xshield policies are enforced, they take higher preference over those CrowdStrike rules and hence does not allow CrowdStrike's quarantine function to work.
  • Xshield supports a mode where you may configure to allow the CrowdStrike quarantine rules to take HIGHER priority over the Xshield Firewall rules.
  • This mode ensures that the CrowdStrike quarantine function works while the Xshield Zero Trust policies remain intact and continues to secure the asset.

If you have a requirement to deploy Xshield alongside other networking or security products that modify host firewall behavior, please contact Xshield Support to review the use case and determine supported options