Zitat von
mpca am 12. Mai 2021, 7:16 Uhr
https://community.sophos.com/sophos-xg-firewall/f/recommended-reads/122357/life-of-a-packet---sophos-xg-v18-0
Introduction
Sophos XG Firewall is a next-generation firewall based on Xstream architecture.
The architecture is available from SFOS 18.0 and later versions.
XG Firewall processes traffic from layer 2 to layer 7 of the OSI model, securing the network, endpoints, as well as data in transit using advanced networking, application, and user controls.
Xstream architecture enables XG Firewall to offload trusted traffic to FastPath after inspecting the initial packets in a connection. FastPath processes layer 2 and higher traffic, delivering packets at wire speed.
Generally, most firewall stack processing is stateless and applies in full on each packet, using more processing cycles than necessary. Offloading enables XG Firewall to minimize processing cycles. The following architecture and offloading mechanisms deliver high-speed processing:
The architecture uses the following mechanisms:
- Separates the firewall stack’s layer 2 and layer 3 processing from layer 4 and layer 7 security processing by the DPI engine, delivering high network performance.
- Leverages both hardware and software components to deliver processing efficiency.
Offloading uses the following mechanisms to deliver processing efficiency:
- Offloads some or all processing to FastPath, minimizing CPU load and packet latency, and maximizing packet throughput.
- Eliminates the need to cache or buffer packets, or to apply full firewall processing on every packet in the connection, minimizing the use of processing cycles.
- Performs stream processing with deep packet inspection. The processing delivers packets at wire speed with high levels of protection.
The policies and settings you configure determine the firewall stack processing and the DPI engine’s security policy enforcement. You can configure policies to offload trusted packets at each level of protection.
You can use the advanced protection settings and security policies, including SSL/TLS inspection, IPS, web filtering, application control, and full antivirus scanning for traffic that requires the complete protection XG Firewall offers.
Xstream architecture
Xstream architecture minimizes CPU usage by the firewall stack, maximizing CPU availability for deep packet inspection. It provides the hardware and software platform to offload packet processing throughout the connection's lifetime.
The data plane uses both hardware and software components, delivering high levels of processing efficiency. It contains the following domains:
Firewall stack: The firewall stack (kernel space) enforces layer 2 and layer 3 decisions in the ingress and egress stages.
DPI engine: The deep packet inspection engine located in the user space, applies layer 4 to layer 7 security policies.
Other user space modules: The user space runs applications and contains application software, programs, libraries, and processes. In XG Firewall, it contains the DPI engine, proxy applications and WAF, malware scanning, anti-spam, and SSL VPN engines.
FastPath: The data plane offloads trusted traffic to FastPath from the firewall stack and the DPI engine throughout a connection's lifetime.
Firewall stack processing
Traffic flows in the stateful firewall mode initially. The processing flow for the firewall stack is SlowPath processing and is as follows:
Ingress stage: The firewall stack performs stateful inspection of the initial packet of a connection. It enforces DoS and spoof protection, threat protection, authentication, firewall and NAT rules, and implements VPN, bridging, routing, forwarding, and QoS decisions.
Transfer to the DPI engine: After the firewall stack processes the first ingress packet, it transfers the packet to the DPI engine. The DPI engine enforces security policy decisions and transfers the packet back to the firewall stack.
Egress stage: The firewall stack implements source NAT (SNAT), VPN, and QoS policies, and then the packet is forwarded to its destination.
Offload to FastPath: After processing one packet from both directions for a connection, the firewall stack caches the classification decisions it has taken. Subsequent packets in the connection are offloaded to FastPath.
After the offload, the firewall stack continues to manage the connection, requiring the CPU to handle the connection rate. If traffic can’t be offloaded for any reason, the firewall stack continues to process the packets in the connection.
Ingress stage
After reassembling packets received on the SFOS interface, the firewall stack drops malformed packets, including those with TCP/IP protocol anomalies, such as malformed headers and those that don’t meet specifications, such as TCP time-outs, maximum segment size, and retransmissions.
The firewall stack then implements the following processing in the ingress stage:
RED traffic
The firewall stack allows incoming packets from existing RED tunnels. These are connections from XG Firewall to a Remote Ethernet Device (RED) or site-to-site connections between two XG Firewall devices using a layer 2 tunnel.
RED devices connect remote offices through encrypted tunnels over the WAN zone. The XG Firewall in the head office and the RED device in the remote office contain a RED core engine, which processes the RED traffic. Static routes determine RED traffic routing from the branch office to the head office.
The RED core engine in XG Firewall decrypts traffic from the remote office to the head office and transfers it to the firewall stack to implement firewall and NAT rules.
For outgoing traffic from the head office to the remote office, the firewall stack implements firewall and NAT rules and then transfers the traffic to the RED core engine for encryption. After encrypting the traffic, the RED core engine forwards traffic to the remote office. RED traffic isn't offloaded to FastPath.
DoS & spoof protection
The firewall stack applies DoS (Denial of Service) and spoof protection policies on all traffic, including traffic that bypasses stateful firewall inspection through connection bypass ACLs created on the command-line interface. Traffic crossing the SYN, UDP, TCP, and ICMP flood thresholds specified in DoS settings is dropped.
Traffic bypasses DoS protection checks for exceptions specified in DoS bypass rules.
Threat protection
The firewall stack checks IP addresses based on the advanced threat protection (ATP) database. If XG Firewall is configured as the DNS server, the firewall stack also checks the domain names with the ATP database. If it finds the IP addresses or domain names in the database, it takes the action specified in the ATP module.
Lookups
The firewall stack looks up the following rules and parameters matching the traffic criteria:
- Destination NAT rule: For incoming traffic, the firewall stack looks up the destination NAT rule matching the packet's original source, destination, and service, and the inbound and outbound interfaces. It tags the packet with the DNAT rule ID. Address translation is done later in the processing. The translated destination’s zone is identified as the destination zone for firewall rule lookup and processing. For example, if the translated destination IP address of the web server belongs to the DMZ zone, the firewall stack tags the packet with DMZ as the destination zone.
- SD-WAN policy routing: SD-WAN policy routes are matched with users and applications in addition to the 5-tuple criteria. The firewall stack obtains the source and destination IP addresses, service, inbound interface, and the user ID for the first connection. The destination IP address is the translated destination IP address in the DNAT lookup.
The packet is tagged with the matching policy route for processing later in the flow. The SD-WAN policy route determines the destination interface based on the specified gateway.
After the application module in the DPI engine identifies the application, the firewall stack matches an SD-WAN policy route for subsequent connections to the same application.
Route lookup also identifies system-destined traffic.
- Security Heartbeat: If Synchronized Security is turned on, the Security Heartbeat engine shares the endpoint’s Heartbeat status (health status) along with the source IP address.
- Users: The firewall stack looks up the user ID associated with the source IP address of the packet. It also determines the groups to which the user belongs.
Firewall rule lookup and processing
The firewall stack matches a firewall rule based on the following traffic criteria:
| Type |
Lookup criteria |
| Network criteria |
- Source port and IP address
- Source zones
- Destination port and IP address
- Destination zones
- Services
|
| User identity |
- Users (based on the source IP address)
- Groups
- Unknown users
|
| Heartbeat status |
|
If none of the firewall rules match the criteria, the default "Drop all" rule (ID 0) applies, and the packets are dropped. Traffic is blocked if the matching firewall rule has its action set to drop or reject.
For traffic with the firewall rule action set to accept, the connection is tagged with the firewall rule ID and the security policies specified in the rule, such as web filter, application filter, IPS, and QoS policies. The firewall stack also flags logging and antivirus scanning, if specified in the firewall rule.
If the user identity remains unknown, the connection is dropped, and the captive portal is shown to the user. After the user signs in through the captive portal, the user identity becomes available, and the firewall stack processes the initial packet.
Routing processing
The default routing precedence in XG Firewall is static route, SD-WAN policy route, VPN route.
- Static routing: If the default precedence is retained, the firewall stack first applies static routes. These refer to directly connected networks, dynamic routing protocols, and unicast routes.
- SD-WAN policy routing: If a static route doesn't match the traffic, the firewall stack implements the SD-WAN policy route identified earlier in the process and routes traffic through the gateway specified in the route. Based on the specified settings, it performs failover between the primary and backup gateways with fallback to the default WAN link manager load balancing.
If an application object is specified in the SD-WAN policy route, an SD-WAN policy route without application criteria are matched for the first connection. For subsequent connections, an application-based SD-WAN policy route is applied.
- VPN routes: If traffic doesn't match the above two routes, the firewall stack matches VPN routes. These apply to IPsec traffic to be decapsulated and decrypted by the XFRM stack.
- Default route(WAN link load balance): If traffic doesn't match any of these routes, the firewall stack applies the default route, which is WAN link load balancing among the gateways specified in the WAN link manager.
IPsec VPN
IPsec connections are used for site-to-site and remote access tunnels.
For incoming traffic that's encrypted, the firewall stack identifies the matching IPsec connection rule based on the source and destination IP addresses and the IP protocol field (ESP) in the outer header.
The firewall stack then transfers VPN traffic to the XFRM stack. The XFRM stack looks up the SPI (Security Parameter Index) value in the ESP header to match the encryption and authentication settings. It then identifies the IPsec policy associated with the SPI value.
The XFRM stack decrypts the packet based on the policy. It does a route lookup on the decapsulated packet and transfers the decrypted traffic back to the firewall stack. The packet then goes through the firewall stack processes from DoS and spoof protection to routing.
Egress stage
After the DPI engine enforces security policies, egress traffic is handed over to the firewall stack. The firewall stack then processes traffic exiting XG Firewall. The processing flow in the egress stage is as follows:
- Source NAT
- IPsec VPN
- QoS (Quality of service)
Source NAT
The firewall stack applies the matching SNAT rule to outgoing traffic. It applies SNAT to IPsec VPN packets if NAT settings are specified in the configured IPsec connection. If translation isn't specified, the default SNAT rule applies, masquerading the source IP address.
IPsec VPN
After routing, the firewall stack transfers packets egressing towards the VPN zone through IPsec0 (IPsec virtual interface) to the XFRM stack. The XFRM stack uses the packet's source and destination IP addresses and ports, the protocol, and listening interface to match the IPsec connection and policy. Based on the policy criteria, the XFRM stack encrypts and encapsulates the traffic. It then transfers the packet to the firewall stack for egress processing.
QoS
The firewall stack implements traffic shaping based on the policy specified in the firewall rule and sends the packets to layer 2 for transmission outside the network. The packets then exit XG Firewall through the egress interface.
After the first packet of every connection flows through the firewall stack, a classification decision is made. Traffic that doesn’t require DPI engine processing is offloaded to FastPath.
SlowPath: Basic firewall stack flow
User space modules
The user space contains the following modules:
- Proxies and WAF
- Malware scanning
- Anti-spam
- SSL VPN
- DPI engine
The module details are as follows:
Proxies and WAF
This component contains the web proxy, FTP, email, and WAF engines.
Web proxy
The web proxy operates in the user space, but not in the DPI engine. If web proxy filtering (instead of the DPI engine) is specified in the firewall rule, traffic is handed over to the web proxy engine. The engine decrypts HTTPS traffic on the standard port 443, identifies the category, and enforces the specified web policy.
Web content scanning takes place in the antivirus engine in real-time or batch mode based on the scanning settings configured in the web module. Even when web proxy is selected, web content filtering over non-standard ports takes place in the DPI engine.
However, if web proxy isn't selected in the firewall rule, the DPI engine implements web filtering, including HTTPS decryption based on SSL/TLS inspection rules. It also enforces web policy settings and content scanning.
FTP protection
Protection for file transfers takes place here. You set the FTP scanning settings in the firewall rule.
Email protection
The firewall stack forwards SMTP/S, POP/S, and IMAP/S traffic to the email engine. The engine processes emails in both MTA (Mail Transfer Agent) and transparent proxy modes. Depending on the mode in which XG Firewall is deployed, it applies SMTP and POP-IMAP policies for spam and malware.
The engine encrypts outgoing traffic based on the SPX encryption template and decrypts incoming traffic based on the email settings. The email engine sends packets to the antivirus engine for malware processing and to the anti-spam engine for spam check.
WAF (Web server protection)
The reverse proxy processes incoming connections to web applications hosted within the network.
The firewall stack identifies the WAF rule based on the port and destination IP address, which is a WAN interface or public IP address, and transfers the packets to the WAF engine. The WAF engine communicates with the database and applies the settings and modifications specified in the WAF rule, such as an HTML rewrite. It then sends a response to the client (browser).
If form-based authentication is configured, the WAF engine shows a sign-in page, performing reverse proxy authentication. After the user is authenticated, the WAF engine performs the modifications specified.
If the domain name isn't configured in WAF, the engine shows an error page. An error page is also shown when the WAF engine blocks requests based on malware scan or common threat filter (CTF) results. WAF traffic isn't offloaded to FastPath.
Malware scanning
This component contains antivirus and Sandstorm scanning.
Antivirus
Antivirus scanning takes place for web, FTP, email, and WAF traffic. XG Firewall performs streaming antivirus scanning. If the DPI engine passes a verdict that the traffic is safe, antivirus scanning doesn't take place for traffic flowing through the DPI engine.
Sandstorm
Files are sent for detonation to a Sandstorm data center in the cloud over a secure connection based on your settings. You can exclude specific file types in email attachments and web downloads from Sandstorm analysis.
Anti-spam
Packets are sent to the anti-spam module for spam scanning based on the settings in the SMTP policies.
SSL VPN
XG Firewall listens on the default port 8443 over TCP and UDP protocols for SSL VPN packets. The local service ACL must allow SSL VPN access for the packet's source and destination zones. XG Firewall implements SSL/TLS-based VPN using OpenVPN, which runs in the user space.
For incoming SSL VPN traffic, OpenVPN decrypts the packet and sends it to the firewall stack using the TUN interface. Decrypted packets then go through the regular firewall stack processing.
For outgoing SSL VPN traffic, the firewall stack routes packets to the Tun0 interface based on the routing entry added for the destination when the SSL VPN tunnel came up. Packets are transferred through the Tun0 interface to OpenVPN in the user space. The OpenVPN stack encrypts the packets and transfers them to the firewall stack for encapsulation and QoS implementation.
DPI engine
After the ingress stage, the DPI engine enforces security policies based on the tagging performed during the firewall rule lookup. The engine is in the user space and enforces the following security rules and policies:
- SSL/TLS inspection
- Application identification and control
- Intrusion Prevention
- Web filtering with the DPI engine
The DPI engine inspects traffic from layer 4 to 7 using stream processing. Offloading decisions are taken at each stage of security processing based on the verdicts passed by the security modules.
The firewall stack transfers the first packet to the DPI engine to enforce security policies and categorize the traffic. For subsequent packets, which are offloaded to FastPath, FastPath transfers the packets to the DPI engine.
Packet transfer takes place through the DAQ (Data Acquisition) layer. After applying security policies, the DPI engine transfers the traffic back through the DAQ layer to the firewall stack or FastPath, depending on the system that sent the packets.
The DAQ layer provides a direct path for the hardware to write packet buffers into the DPI engine address space, ensuring zero-copy buffers. It also provides I/O multiplexing and routing of shared packet buffers among the DPI engine components so that packets are moved in and out of the DPI engine rapidly.
Application identification and control
The initial packets of a connection are delivered to the DPI engine for application identification. The engine classifies the application after approximately eight packets and gives a policy verdict for application control.
The verdict may also include new forwarding behavior, which is implemented on subsequent connections that contain the identified application. The verdict may also include new QoS parameters, which are implemented on the current connection. The DAQ layer communicates these decisions to the firewall stack.
Offload to FastPath after application identification
Intrusion prevention
IPS may pass a verdict to stop security processing based on factors, such as a safe signature or verdict from SophosLabs, earlier verdicts, or a matching IPS policy with a bypass session rule attached to it. For files that need antivirus scanning, packets are shared with the antivirus module.
SSL/TLS inspection
SSL/TLS inspection must be turned on to enforce inspection and decryption. For unencrypted traffic, the SSL/TLS module informs the DAQ layer that SSL/TLS processing isn't required for the flow.
For encrypted traffic, the DPI engine modifies the traffic to perform man-in-the-middle inspection. The engine continues to modify traffic throughout the connection lifetime to ensure the connection isn't dropped because of the modification. After decryption, the other modules in the DPI engine perform security processing.
Web filtering with DPI engine
The DPI engine applies the web policy and allows or blocks web traffic based on the scanning results and the web category, URL group, file type, and user activity specified in the web policy. When the DPI engine is selected in the firewall rule, the engine performs web content filtering over standard and non-standard ports. When web filtering applies to the traffic, web traffic scanning continues until the end of the flow, depending on the HTTP responses that are returned. The packets are transferred to the antivirus module for scanning.
The traffic is then offloaded to FastPath. Traffic may not be fully offloaded because of SSL/TLS inspection and web filtering. Fully offloaded traffic attains cutoff from the SlowPath.
Full offload to FastPath: Cutoff from SlowPath
How FastPath works
The first packet of every connection flows through the firewall stack. After the first packet from each direction passes through the firewall stack, the firewall stack fully classifies the flow. The data plane then offloads some or all processing of subsequent packets from the CPU to FastPath throughout the connection's lifetime. These packets don't require further processing to verify their identity and destination.
For security processing, the initial packet from the firewall stack and the offloaded packets from FastPath are handed over to the DPI engine through the DAQ layer. FastPath provides an efficient, zero-copy path into the DPI engine. The ability to deliver packets directly to the DPI engine’s buffers eliminates the need to retain copies in the kernel memory.
The DPI engine processes approximately eight packets before it determines the traffic to be safe. After it passes a verdict that the traffic is safe, the data plane offloads some or all security processing of subsequent packets to FastPath, completing the offload process for the connection.
On the offloaded packets, FastPath implements the classification decisions taken by the firewall stack and the DPI engine.
The data plane uses the hardware to cache the classification decisions, such as encapsulation, decapsulation, routing and switching decisions, and security policy verdicts. The data plane programs a connection cache, containing the classification decisions, with FastPath. FastPath acts only based on these classification decisions.
Some or all processing of packets in the connection is offloaded to FastPath from the x86 general-purpose CPUs. Offloading lightens the load on the x86 hardware. FastPath applies the classification decisions to subsequent packets in the connection. FastPath supports programmable network processors that can carry out the data plane operations at line rate.
FastPath can statefully track individual connections, processing the packets fully, without consuming PCIe bandwidth, x86 CPU cycles, and memory bandwidth. The offload lightens the load on the hardware and accelerates security processing.
To take advantage of wire speed FastPath processing, see How to use rules and policies to leverage FastPath.
https://community.sophos.com/sophos-xg-firewall/f/recommended-reads/122357/life-of-a-packet---sophos-xg-v18-0
Introduction
Sophos XG Firewall is a next-generation firewall based on Xstream architecture.
The architecture is available from SFOS 18.0 and later versions.
XG Firewall processes traffic from layer 2 to layer 7 of the OSI model, securing the network, endpoints, as well as data in transit using advanced networking, application, and user controls.
Xstream architecture enables XG Firewall to offload trusted traffic to FastPath after inspecting the initial packets in a connection. FastPath processes layer 2 and higher traffic, delivering packets at wire speed.
Generally, most firewall stack processing is stateless and applies in full on each packet, using more processing cycles than necessary. Offloading enables XG Firewall to minimize processing cycles. The following architecture and offloading mechanisms deliver high-speed processing:
The architecture uses the following mechanisms:
- Separates the firewall stack’s layer 2 and layer 3 processing from layer 4 and layer 7 security processing by the DPI engine, delivering high network performance.
- Leverages both hardware and software components to deliver processing efficiency.
Offloading uses the following mechanisms to deliver processing efficiency:
- Offloads some or all processing to FastPath, minimizing CPU load and packet latency, and maximizing packet throughput.
- Eliminates the need to cache or buffer packets, or to apply full firewall processing on every packet in the connection, minimizing the use of processing cycles.
- Performs stream processing with deep packet inspection. The processing delivers packets at wire speed with high levels of protection.
The policies and settings you configure determine the firewall stack processing and the DPI engine’s security policy enforcement. You can configure policies to offload trusted packets at each level of protection.
You can use the advanced protection settings and security policies, including SSL/TLS inspection, IPS, web filtering, application control, and full antivirus scanning for traffic that requires the complete protection XG Firewall offers.
Xstream architecture
Xstream architecture minimizes CPU usage by the firewall stack, maximizing CPU availability for deep packet inspection. It provides the hardware and software platform to offload packet processing throughout the connection's lifetime.
The data plane uses both hardware and software components, delivering high levels of processing efficiency. It contains the following domains:
Firewall stack: The firewall stack (kernel space) enforces layer 2 and layer 3 decisions in the ingress and egress stages.
DPI engine: The deep packet inspection engine located in the user space, applies layer 4 to layer 7 security policies.
Other user space modules: The user space runs applications and contains application software, programs, libraries, and processes. In XG Firewall, it contains the DPI engine, proxy applications and WAF, malware scanning, anti-spam, and SSL VPN engines.
FastPath: The data plane offloads trusted traffic to FastPath from the firewall stack and the DPI engine throughout a connection's lifetime.
Firewall stack processing
Traffic flows in the stateful firewall mode initially. The processing flow for the firewall stack is SlowPath processing and is as follows:
Ingress stage: The firewall stack performs stateful inspection of the initial packet of a connection. It enforces DoS and spoof protection, threat protection, authentication, firewall and NAT rules, and implements VPN, bridging, routing, forwarding, and QoS decisions.
Transfer to the DPI engine: After the firewall stack processes the first ingress packet, it transfers the packet to the DPI engine. The DPI engine enforces security policy decisions and transfers the packet back to the firewall stack.
Egress stage: The firewall stack implements source NAT (SNAT), VPN, and QoS policies, and then the packet is forwarded to its destination.
Offload to FastPath: After processing one packet from both directions for a connection, the firewall stack caches the classification decisions it has taken. Subsequent packets in the connection are offloaded to FastPath.
After the offload, the firewall stack continues to manage the connection, requiring the CPU to handle the connection rate. If traffic can’t be offloaded for any reason, the firewall stack continues to process the packets in the connection.
Ingress stage
After reassembling packets received on the SFOS interface, the firewall stack drops malformed packets, including those with TCP/IP protocol anomalies, such as malformed headers and those that don’t meet specifications, such as TCP time-outs, maximum segment size, and retransmissions.
The firewall stack then implements the following processing in the ingress stage:
RED traffic
The firewall stack allows incoming packets from existing RED tunnels. These are connections from XG Firewall to a Remote Ethernet Device (RED) or site-to-site connections between two XG Firewall devices using a layer 2 tunnel.
RED devices connect remote offices through encrypted tunnels over the WAN zone. The XG Firewall in the head office and the RED device in the remote office contain a RED core engine, which processes the RED traffic. Static routes determine RED traffic routing from the branch office to the head office.
The RED core engine in XG Firewall decrypts traffic from the remote office to the head office and transfers it to the firewall stack to implement firewall and NAT rules.
For outgoing traffic from the head office to the remote office, the firewall stack implements firewall and NAT rules and then transfers the traffic to the RED core engine for encryption. After encrypting the traffic, the RED core engine forwards traffic to the remote office. RED traffic isn't offloaded to FastPath.
DoS & spoof protection
The firewall stack applies DoS (Denial of Service) and spoof protection policies on all traffic, including traffic that bypasses stateful firewall inspection through connection bypass ACLs created on the command-line interface. Traffic crossing the SYN, UDP, TCP, and ICMP flood thresholds specified in DoS settings is dropped.
Traffic bypasses DoS protection checks for exceptions specified in DoS bypass rules.
Threat protection
The firewall stack checks IP addresses based on the advanced threat protection (ATP) database. If XG Firewall is configured as the DNS server, the firewall stack also checks the domain names with the ATP database. If it finds the IP addresses or domain names in the database, it takes the action specified in the ATP module.
Lookups
The firewall stack looks up the following rules and parameters matching the traffic criteria:
- Destination NAT rule: For incoming traffic, the firewall stack looks up the destination NAT rule matching the packet's original source, destination, and service, and the inbound and outbound interfaces. It tags the packet with the DNAT rule ID. Address translation is done later in the processing. The translated destination’s zone is identified as the destination zone for firewall rule lookup and processing. For example, if the translated destination IP address of the web server belongs to the DMZ zone, the firewall stack tags the packet with DMZ as the destination zone.
- SD-WAN policy routing: SD-WAN policy routes are matched with users and applications in addition to the 5-tuple criteria. The firewall stack obtains the source and destination IP addresses, service, inbound interface, and the user ID for the first connection. The destination IP address is the translated destination IP address in the DNAT lookup.
The packet is tagged with the matching policy route for processing later in the flow. The SD-WAN policy route determines the destination interface based on the specified gateway.
After the application module in the DPI engine identifies the application, the firewall stack matches an SD-WAN policy route for subsequent connections to the same application.
Route lookup also identifies system-destined traffic.
- Security Heartbeat: If Synchronized Security is turned on, the Security Heartbeat engine shares the endpoint’s Heartbeat status (health status) along with the source IP address.
- Users: The firewall stack looks up the user ID associated with the source IP address of the packet. It also determines the groups to which the user belongs.
Firewall rule lookup and processing
The firewall stack matches a firewall rule based on the following traffic criteria:
| Type |
Lookup criteria |
| Network criteria |
- Source port and IP address
- Source zones
- Destination port and IP address
- Destination zones
- Services
|
| User identity |
- Users (based on the source IP address)
- Groups
- Unknown users
|
| Heartbeat status |
|
If none of the firewall rules match the criteria, the default "Drop all" rule (ID 0) applies, and the packets are dropped. Traffic is blocked if the matching firewall rule has its action set to drop or reject.
For traffic with the firewall rule action set to accept, the connection is tagged with the firewall rule ID and the security policies specified in the rule, such as web filter, application filter, IPS, and QoS policies. The firewall stack also flags logging and antivirus scanning, if specified in the firewall rule.
If the user identity remains unknown, the connection is dropped, and the captive portal is shown to the user. After the user signs in through the captive portal, the user identity becomes available, and the firewall stack processes the initial packet.
Routing processing
The default routing precedence in XG Firewall is static route, SD-WAN policy route, VPN route.
- Static routing: If the default precedence is retained, the firewall stack first applies static routes. These refer to directly connected networks, dynamic routing protocols, and unicast routes.
- SD-WAN policy routing: If a static route doesn't match the traffic, the firewall stack implements the SD-WAN policy route identified earlier in the process and routes traffic through the gateway specified in the route. Based on the specified settings, it performs failover between the primary and backup gateways with fallback to the default WAN link manager load balancing.
If an application object is specified in the SD-WAN policy route, an SD-WAN policy route without application criteria are matched for the first connection. For subsequent connections, an application-based SD-WAN policy route is applied.
- VPN routes: If traffic doesn't match the above two routes, the firewall stack matches VPN routes. These apply to IPsec traffic to be decapsulated and decrypted by the XFRM stack.
- Default route(WAN link load balance): If traffic doesn't match any of these routes, the firewall stack applies the default route, which is WAN link load balancing among the gateways specified in the WAN link manager.
IPsec VPN
IPsec connections are used for site-to-site and remote access tunnels.
For incoming traffic that's encrypted, the firewall stack identifies the matching IPsec connection rule based on the source and destination IP addresses and the IP protocol field (ESP) in the outer header.
The firewall stack then transfers VPN traffic to the XFRM stack. The XFRM stack looks up the SPI (Security Parameter Index) value in the ESP header to match the encryption and authentication settings. It then identifies the IPsec policy associated with the SPI value.
The XFRM stack decrypts the packet based on the policy. It does a route lookup on the decapsulated packet and transfers the decrypted traffic back to the firewall stack. The packet then goes through the firewall stack processes from DoS and spoof protection to routing.
Egress stage
After the DPI engine enforces security policies, egress traffic is handed over to the firewall stack. The firewall stack then processes traffic exiting XG Firewall. The processing flow in the egress stage is as follows:
- Source NAT
- IPsec VPN
- QoS (Quality of service)
Source NAT
The firewall stack applies the matching SNAT rule to outgoing traffic. It applies SNAT to IPsec VPN packets if NAT settings are specified in the configured IPsec connection. If translation isn't specified, the default SNAT rule applies, masquerading the source IP address.
IPsec VPN
After routing, the firewall stack transfers packets egressing towards the VPN zone through IPsec0 (IPsec virtual interface) to the XFRM stack. The XFRM stack uses the packet's source and destination IP addresses and ports, the protocol, and listening interface to match the IPsec connection and policy. Based on the policy criteria, the XFRM stack encrypts and encapsulates the traffic. It then transfers the packet to the firewall stack for egress processing.
QoS
The firewall stack implements traffic shaping based on the policy specified in the firewall rule and sends the packets to layer 2 for transmission outside the network. The packets then exit XG Firewall through the egress interface.
After the first packet of every connection flows through the firewall stack, a classification decision is made. Traffic that doesn’t require DPI engine processing is offloaded to FastPath.
SlowPath: Basic firewall stack flow
User space modules
The user space contains the following modules:
- Proxies and WAF
- Malware scanning
- Anti-spam
- SSL VPN
- DPI engine
The module details are as follows:
Proxies and WAF
This component contains the web proxy, FTP, email, and WAF engines.
Web proxy
The web proxy operates in the user space, but not in the DPI engine. If web proxy filtering (instead of the DPI engine) is specified in the firewall rule, traffic is handed over to the web proxy engine. The engine decrypts HTTPS traffic on the standard port 443, identifies the category, and enforces the specified web policy.
Web content scanning takes place in the antivirus engine in real-time or batch mode based on the scanning settings configured in the web module. Even when web proxy is selected, web content filtering over non-standard ports takes place in the DPI engine.
However, if web proxy isn't selected in the firewall rule, the DPI engine implements web filtering, including HTTPS decryption based on SSL/TLS inspection rules. It also enforces web policy settings and content scanning.
FTP protection
Protection for file transfers takes place here. You set the FTP scanning settings in the firewall rule.
Email protection
The firewall stack forwards SMTP/S, POP/S, and IMAP/S traffic to the email engine. The engine processes emails in both MTA (Mail Transfer Agent) and transparent proxy modes. Depending on the mode in which XG Firewall is deployed, it applies SMTP and POP-IMAP policies for spam and malware.
The engine encrypts outgoing traffic based on the SPX encryption template and decrypts incoming traffic based on the email settings. The email engine sends packets to the antivirus engine for malware processing and to the anti-spam engine for spam check.
WAF (Web server protection)
The reverse proxy processes incoming connections to web applications hosted within the network.
The firewall stack identifies the WAF rule based on the port and destination IP address, which is a WAN interface or public IP address, and transfers the packets to the WAF engine. The WAF engine communicates with the database and applies the settings and modifications specified in the WAF rule, such as an HTML rewrite. It then sends a response to the client (browser).
If form-based authentication is configured, the WAF engine shows a sign-in page, performing reverse proxy authentication. After the user is authenticated, the WAF engine performs the modifications specified.
If the domain name isn't configured in WAF, the engine shows an error page. An error page is also shown when the WAF engine blocks requests based on malware scan or common threat filter (CTF) results. WAF traffic isn't offloaded to FastPath.
Malware scanning
This component contains antivirus and Sandstorm scanning.
Antivirus
Antivirus scanning takes place for web, FTP, email, and WAF traffic. XG Firewall performs streaming antivirus scanning. If the DPI engine passes a verdict that the traffic is safe, antivirus scanning doesn't take place for traffic flowing through the DPI engine.
Sandstorm
Files are sent for detonation to a Sandstorm data center in the cloud over a secure connection based on your settings. You can exclude specific file types in email attachments and web downloads from Sandstorm analysis.
Anti-spam
Packets are sent to the anti-spam module for spam scanning based on the settings in the SMTP policies.
SSL VPN
XG Firewall listens on the default port 8443 over TCP and UDP protocols for SSL VPN packets. The local service ACL must allow SSL VPN access for the packet's source and destination zones. XG Firewall implements SSL/TLS-based VPN using OpenVPN, which runs in the user space.
For incoming SSL VPN traffic, OpenVPN decrypts the packet and sends it to the firewall stack using the TUN interface. Decrypted packets then go through the regular firewall stack processing.
For outgoing SSL VPN traffic, the firewall stack routes packets to the Tun0 interface based on the routing entry added for the destination when the SSL VPN tunnel came up. Packets are transferred through the Tun0 interface to OpenVPN in the user space. The OpenVPN stack encrypts the packets and transfers them to the firewall stack for encapsulation and QoS implementation.
DPI engine
After the ingress stage, the DPI engine enforces security policies based on the tagging performed during the firewall rule lookup. The engine is in the user space and enforces the following security rules and policies:
- SSL/TLS inspection
- Application identification and control
- Intrusion Prevention
- Web filtering with the DPI engine
The DPI engine inspects traffic from layer 4 to 7 using stream processing. Offloading decisions are taken at each stage of security processing based on the verdicts passed by the security modules.
The firewall stack transfers the first packet to the DPI engine to enforce security policies and categorize the traffic. For subsequent packets, which are offloaded to FastPath, FastPath transfers the packets to the DPI engine.
Packet transfer takes place through the DAQ (Data Acquisition) layer. After applying security policies, the DPI engine transfers the traffic back through the DAQ layer to the firewall stack or FastPath, depending on the system that sent the packets.
The DAQ layer provides a direct path for the hardware to write packet buffers into the DPI engine address space, ensuring zero-copy buffers. It also provides I/O multiplexing and routing of shared packet buffers among the DPI engine components so that packets are moved in and out of the DPI engine rapidly.
Application identification and control
The initial packets of a connection are delivered to the DPI engine for application identification. The engine classifies the application after approximately eight packets and gives a policy verdict for application control.
The verdict may also include new forwarding behavior, which is implemented on subsequent connections that contain the identified application. The verdict may also include new QoS parameters, which are implemented on the current connection. The DAQ layer communicates these decisions to the firewall stack.
Offload to FastPath after application identification
Intrusion prevention
IPS may pass a verdict to stop security processing based on factors, such as a safe signature or verdict from SophosLabs, earlier verdicts, or a matching IPS policy with a bypass session rule attached to it. For files that need antivirus scanning, packets are shared with the antivirus module.
SSL/TLS inspection
SSL/TLS inspection must be turned on to enforce inspection and decryption. For unencrypted traffic, the SSL/TLS module informs the DAQ layer that SSL/TLS processing isn't required for the flow.
For encrypted traffic, the DPI engine modifies the traffic to perform man-in-the-middle inspection. The engine continues to modify traffic throughout the connection lifetime to ensure the connection isn't dropped because of the modification. After decryption, the other modules in the DPI engine perform security processing.
Web filtering with DPI engine
The DPI engine applies the web policy and allows or blocks web traffic based on the scanning results and the web category, URL group, file type, and user activity specified in the web policy. When the DPI engine is selected in the firewall rule, the engine performs web content filtering over standard and non-standard ports. When web filtering applies to the traffic, web traffic scanning continues until the end of the flow, depending on the HTTP responses that are returned. The packets are transferred to the antivirus module for scanning.
The traffic is then offloaded to FastPath. Traffic may not be fully offloaded because of SSL/TLS inspection and web filtering. Fully offloaded traffic attains cutoff from the SlowPath.
Full offload to FastPath: Cutoff from SlowPath
How FastPath works
The first packet of every connection flows through the firewall stack. After the first packet from each direction passes through the firewall stack, the firewall stack fully classifies the flow. The data plane then offloads some or all processing of subsequent packets from the CPU to FastPath throughout the connection's lifetime. These packets don't require further processing to verify their identity and destination.
For security processing, the initial packet from the firewall stack and the offloaded packets from FastPath are handed over to the DPI engine through the DAQ layer. FastPath provides an efficient, zero-copy path into the DPI engine. The ability to deliver packets directly to the DPI engine’s buffers eliminates the need to retain copies in the kernel memory.
The DPI engine processes approximately eight packets before it determines the traffic to be safe. After it passes a verdict that the traffic is safe, the data plane offloads some or all security processing of subsequent packets to FastPath, completing the offload process for the connection.
On the offloaded packets, FastPath implements the classification decisions taken by the firewall stack and the DPI engine.
The data plane uses the hardware to cache the classification decisions, such as encapsulation, decapsulation, routing and switching decisions, and security policy verdicts. The data plane programs a connection cache, containing the classification decisions, with FastPath. FastPath acts only based on these classification decisions.
Some or all processing of packets in the connection is offloaded to FastPath from the x86 general-purpose CPUs. Offloading lightens the load on the x86 hardware. FastPath applies the classification decisions to subsequent packets in the connection. FastPath supports programmable network processors that can carry out the data plane operations at line rate.
FastPath can statefully track individual connections, processing the packets fully, without consuming PCIe bandwidth, x86 CPU cycles, and memory bandwidth. The offload lightens the load on the hardware and accelerates security processing.
To take advantage of wire speed FastPath processing, see How to use rules and policies to leverage FastPath.
SlowPath: Basic firewall stack flow
Offload to FastPath after application identification
Full offload to FastPath: Cutoff from SlowPath