For this chapter, no physical installation is required. A good understanding of basic networking protocols like UDP and TCP is necessary to fully benefit from the explanations in this chapter. It is helpful if you’ve already worked with Palo Alto Networks firewalls, but it is not required. Some experience with firewalls or web proxies in general is recommended, as this will make the subject matter more tangible.

Traditionally, when considering a firewall as an element of your network, most likely you will imagine a network design like the one in Figure 1.1, with two to four areas surrounding a box, which represents the firewall. Most of the time, whatever is placed in the north is considered dangerous as it represents the internet; the east and west are somewhat gray areas as they are the demilitarized zones (DMZs) that are partly exposed to the internet, and the south is the happy place where users do their daily tasks. All these areas will be defined as zones in the firewall:

Figure 1.1: Basic network topology

In reality, a network design may look a lot more complex due to network segmentation, remote offices being connected to headquarters via all sorts of different technologies, and the adoption of cloud vendors.

In a route-based firewall, zones are simply an architectural or topological concept that helps identify which areas comprise the global network that is used by the company; they are usually represented by tags that can be attached to a subnet object. They have no bearing on any of the security decisions made by the system when processing security policies.

The zone-based firewall, on the other hand, will use zones as a means to internally classify the source and destination in its state table.

The following diagram illustrates the phases of packet processing from the first step when the first packet of a new session enters the firewall to the last step where the packet egresses the firewall:

Figure 1.2: Phases of packet processing

Let’s look at the process workflow for initial packet processing:

1. When a packet is first received, a source zone lookup is performed. If the source zone has a protection profile associated with it, the packet is evaluated against the profile configuration. If the first packet is a TCP packet, it will also be evaluated against the TCP state where the first packet needs to be a SYN packet, and a SYN cookie is triggered if the protection profile threshold is reached.
2. Then, a destination zone is determined by checking the policy-based forwarding (PBF) rules and, if no results are found, the routing table is consulted.
3. Lastly, the NAT policy is evaluated as the destination IP may be changed by a NAT rule action, thereby changing the destination interface and zone in the routing table. This would require a secondary forwarding lookup to determine the post-NAT egress interface and zone.

After these zone lookups have been performed in the initial packet processing, the firewall will continue to the security pre-policy evaluation.

In the pre-policy evaluation, the “six-tuple” (6-tuple) is used to match an incoming session against the rule base before establishing or dropping/denying a session. At this stage, the firewall does not consider the application just yet, as this can usually not be determined by the first packet in a session. The six-tuple consists of the following elements and is used in both uni-directional flows of a session:

• Source-address
• Destination-address
• Source-port
• Destination-port
• Protocol
• Security-zone

Zones are attached to a physical, virtual, or sub-interface. Each interface can only be part of one single zone. Zones can be created to suit any naming convention and can be very descriptive in their purpose (untrust, DMZ, LAN, and so on), which ensures that, from an administrative standpoint, each area is easily identifiable.

It is best practice to use zones in all security rules, and leveraging a clear naming convention prevents misconfiguration and makes security rules very readable. Networks that are physically separated for whatever reason but are supposed to be connected topologically (for example, users spread over two buildings that come into the firewall on two separate interfaces) can be combined into the same zone, which simplifies policies.

It is important to note that there are implied rules that influence intrazone or interzone sessions. These rules can be found at the bottom of the security policy:

• Default intrazone connections: Packets flowing from and to the same zone will be implicitly allowed
• Default interzone connections: Packets flowing from one zone to a different zone are implicitly blocked

Security rules can be set to only accept traffic within the same zone, between different zones only, or both. This setting can be changed in the rule Type and is set to Universal by default. As illustrated in Figure 1.3, the Universal rule allows sessions to flow from all zones in the Source field to all zones in the Destination field, from LAN to LAN and DMZ, and from DMZ to LAN and DMZ.

Rules set to the intrazone type only allow sessions to flow inside the same zone regardless of whether multiple zones are added to the security rule: from DMZ to DMZ and from LAN to LAN, but not from LAN to DMZ or from DMZ to LAN.

Rules set to the interzone type only allow sessions to flow between different zones: from DMZ to LAN and from LAN to DMZ, but not from DMZ to DMZ or from LAN to LAN, even though both are listed in the source and destination.

This means that you can perfectly control between which interfaces traffic is allowed to flow to even if you are unable to define subnets in the source or destination, which, for traditional firewalls, means sessions will be allowed to flow everywhere.

Figure 1.3: Different security rule types and default rules

Now that we’ve seen the important role zones play while making security decisions, let’s look at the expected behavior when determining zones.

When a packet arrives on an interface, the PBF policy or routing table will be consulted to determine the destination zone based on the original IP address in the packet header.

Let’s consider the following routing table:

> show routing route
flags: A:active, ?:loose, C:connect, H:host, S:static, ~:internal, R:rip, O:ospf, B:bgp,
      Oi:ospf intra-area, Oo:ospf inter-area, O1:ospf ext-type-1, O2:ospf ext-type-2, E:ecmp, M:multicast
VIRTUAL ROUTER: default (id 1)
  ==========
destination       nexthop       metric flags  interface   
0.0.0.0/0         198.51.100.1  10A S    ethernet1/1                 
198.51.100.0/24   198.51.100.2  0      A C    ethernet1/1
198.51.100.2/32   0.0.0.0       0      A H                           
192.168.0.0/24    192.168.0.1   0      A C    ethernet1/2             
192.168.0.1/32    0.0.0.0       0      A H        
172.16.0.0/24     172.16.0.1    0      A C    ethernet1/3                
172.16.0.1/32     0.0.0.0       0      A H                         
total routes shown: 7

Let’s assume ethernet1/1 is the external interface with IP address 198.51.100.2 set to zone external, ethernet1/2 is the DMZ interface with IP address 192.168.0.1 set to zone DMZ, and ethernet1/3 is the LAN interface with IP 172.16.0.1 and set to zone LAN. The default route is going out of interface ethernet1/1 to 198.51.100.1 as a next-hop. There are a few scenarios that will influence how the zone is determined:

• Scenario 1: A packet is received from client PC 172.16.0.5 with destination IP 1.1.1.1.

The firewall quickly determines the source zone is LAN and a route lookup determines the destination IP is not a connected network, so the default route needs to be followed to the internet. The destination zone must be external because the egress interface is ethernet1/1.

• Scenario 2: A packet is received from client PC 172.16.0.5 with destination IP 1.1.1.1 but a PBF rule exists that forces all traffic for 1.1.1.1 to the next-hop IP 192.168.0.25.

As PBF overrides the routing table, the destination zone will become DMZ as the egress interface is now ethernet1/2.

• Scenario 3: A packet is received from internet IP 203.0.113.1 with destination IP 198.51.100.2. This is a typical example of what NAT looks like to the firewall: it receives a packet with its external IP address as the destination.

From the perspective of the NAT policy, the source zone will be external as the IP is not from a connected network and no static route exists, and the destination zone will also be external as the IP is connected to that interface.

From a security aspect, however, once NAT is applied, the destination zone will change to the zone that the post-NAT destination IP is connected to (usually DMZ).

In this section, we saw how the first round of security decisions relies heavily on zones, which should also reflect any rule base you create going forward: use zones in the source and destination as much as possible to fully control the flow of traffic and prevent unexpected behavior. In the next section, we’ll look at what happens in the second round, which also makes a next-generation firewall (NGFW) “next generation.”

App-ID and Content-ID are two technologies that go hand in hand and make up the core inspection mechanism. App-ID relies on decoders to identify and classify flows based on the protocol and layer 7 application. This allows more granular control over what is being allowed or blocked while ensuring an application behaves as expected. Content-ID relies on threat prevention engines to do deep inspection flows for threats, classify URL categories, and prevent data exfiltration.

How App-ID gives more control

Determining which application is contained within a specific data flow is the cornerstone of any NGFW. It can no longer be assumed that any sessions using TCP ports 80 and 443 are simply plaintext or encrypted web browsing. Today’s applications predominantly use these ports as their base transport, and many malware developers have leveraged this convergence to well-known ports in an attempt to masquerade their malware as legitimate web traffic while exfiltrating sensitive information or downloading more malicious payloads into an infected host.

The following image illustrates the steps taken by App-ID to identify applications within flows:

Figure 1.4: How App-ID classifies applications

When a packet is received, App-ID will go through several stages to identify just what something is:

1. First, the 6-Tuple is checked against the security policy to verify whether a certain source, destination, protocol, and port combination is allowed. This will take care of low-hanging fruit if all the unnecessary ports have been closed off and unusual destination ports can already be rejected.
2. Next, the packets will be checked against known application signatures and the app cache to see if the session can be rapidly identified.
3. This is followed by a second security policy check against the application, now adding App-ID to the required set of identifiers for the security policy to allow the session through.
4. If, at this time or in future policy checks, it is determined that the application is SSH, TLS, or SSL, a secondary policy check is performed to verify whether decryption needs to be applied. If a decryption policy exists, the session will go through decryption and will then be checked again for a known application signature, as the session encapsulated inside TLS or SSH may be something entirely different.
5. If, in this step, the application has not been identified (a maximum of 4 packets after the handshake, or 2,000 bytes), App-ID will use the base protocol to determine which decoder to use to analyze the packets more deeply.
6. If the protocol is known, the decoder will go ahead and decode the protocol, then run the payload against the known application signatures again. The outcome could either be a known application (like ssl or web-browsing) or an unknown generic application, like unknown-tcp. This generic application can also be controlled via a security policy to allow or block the session.
7. The session is then re-matched against the security policy to determine whether it is allowed to pass or needs to be rejected or dropped. If the protocol is unknown, App-ID will apply heuristics to try and determine which protocol is used in the session.
8. Once it is determined which protocol is used, another security policy check is performed.
9. Once the application has been identified or all options have been exhausted, App-ID will stop processing the packets for identification.

Throughout the life of a session, the identified application may change several times as more information is learned from the session through inspecting packet after packet. For example, a TCP session may be identified as SSL, which is the HTTPS application as the firewall detects an SSL handshake. The decryption engine and protocol decoders will then be initiated to decrypt the session and identify what is contained inside the encrypted session. Next, it may detect the web-browsing application as the decoder identifies typical browsing behavior such as an HTTP GET. App-ID can then apply known application signatures to identify flickr. Each time the application context changes, the firewall will quickly check whether this particular application is allowed in its security rule base.

If, at this point, flickr is allowed, the same session may later switch contexts again as the user tries to upload a photo, which will trigger another security policy check. The session that was previously allowed may now get blocked by the firewall as the sub-application flickr-uploading may not be allowed.

Once the App-ID process has settled on an application, the application decoder will continuously scan the session for expected and deviant behavior, in case the application changes to a sub-application or a malicious actor is trying to tunnel a different application or protocol over the existing session.

App-ID signatures and decoders are regularly (usually once a month around the 15^th) updated to account for changes to existing applications or protocols and adding new signatures for previously unknown applications or sub-applications to existing apps to add more depth and control (for example, Facebook chat, file sharing, or games).

App-ID, therefore, allows you to control not only which sessions are allowed to pass through the firewall but also how these applications are allowed to behave. In the next section, we will look at how threats can be prevented and malware blocked.

How Content-ID makes things safe

If the appropriate security profiles have been enabled in the security rules, the Content-ID engine will apply the URL filtering policy and will continuously, and in parallel, scan the session for threats like vulnerability exploits, virus or worm infections, suspicious DNS queries, command and control (C&C or C2) signatures, DoS attacks, port scans, malformed protocols, or data patterns matching sensitive data exfiltration. TCP reassembly and IP defragmentation are performed to prevent packet-level evasion techniques. In the following image, you can see how single-pass pattern matching enables simultaneous scanning for multiple types of threats and how URL filtering is added to the mix:

Figure 1.5: How Content-ID scans packets

All of this happens in parallel because the hardware and software were designed so that each packet is simultaneously processed by an App-ID decoder and a Content-ID stream-based engine, each in a dedicated chip on the chassis or through a dedicated process in a virtual machine (VM). This design reduces latency versus serial processing, which means that enabling more security profiles does not come at an exponential cost to performance as is the case with other firewall and IPS solutions.

Inline evaluation

To extend the signature-based evaluation that we just discussed, the firewall also comes with Inline Machine Learning (ML) and Inline Cloud Analysis capabilities that allow it to evaluate dynamic content independently without needing to wait for a signature update to start blocking malicious content. Some of these are as follows:

• WildFire is capable of evaluating portable executable (PE), executable and linked format (ELF), MS Office files, PowerShell, and shell scripts in real time by applying ML models.
• Starting from PAN-OS 11.2, certain chassis (PA-5400 and PA-VM at the time of writing) get local deep learning AI that expands the ML capabilities.
• URL Filtering can leverage local and cloud Inline ML categorization to evaluate website details to protect users from phishing variants and JavaScript exploits.
• Anti-Spyware can tap into live Inline Cloud Analysis to access five analysis engines for C&C-based threats over HTTP, HTTP2, SSL, unknown-UDP, and unknown-TCP.
• Vulnerability Protection can leverage Inline Cloud Analysis to analyze SQL and PowerShell code injection.

All cloud inline detection requires the firewall to have an active internet connection, so plan accordingly if internet access is limited for your deployment.

In this section, you learned how all the (OSI) layer 7 content inspection components work together to provide you with more visibility into which applications are traversing the firewall while blocking any malicious payload.

Hardware and VM design are focused on enabling the best performance for parallel processing while still performing tasks that cost processing power and could impede the speed at which flows are able to pass through the system. For this reason, each platform is split up into so-called planes.

There are two main planes that make up a firewall, the data plane and the management plane, which are physical or logical boards that perform specific functions. While all platforms have a management plane, larger platforms like the PA-5200 have an additional control plane and two to three data planes. The largest platforms have replaceable hardware blades (line cards) that have up to three data plane equivalents per line card and can hold up to 10 line cards. Smaller platforms like the PA-220 only have one hardware board that virtually splits up responsibilities among its CPU cores.

The management plane is where all administrative tasks happen. It serves the web interfaces used by the system to allow configuration, provide URL filtering block pages, and serve the client VPN portal. It performs cloud lookups for URL filtering and DNS security, and downloads and installs content updates onto the data plane. It also performs the logic part of routing and communicates with dynamic routing peers and neighbors. Authentication, User-ID, logging, and many other supporting functions are not directly related to processing packets.

The control plane takes on the task of facilitating communications between multiple data planes and the management plane as well as monitoring processes on the data planes.

The data plane is responsible for processing flows and performing all the security features associated with the NGFW. It scans sessions for patterns and heuristics. It maintains IPsec VPN connections and has hardware offloading to provide wire-speed throughputs. Due to its architecture and the use of interconnected specialty chips, all types of scanning can happen in parallel as each chip processes packets simultaneously and reports its findings.

A switch fabric enables communication between planes so the data plane can send lookup requests to the management plane, and the management plane can send configuration updates and content updates.

The following diagram illustrates how these components interact with each other:

Figure 1.6: Management and data planes

Now that we’ve covered the most basic functions and you have a firm grasp of how the hardware is organized, let’s look at identity-based authorization. The ability to identify users and apply different security policies based on identity or group membership is an important feature of the NGFW as it allows more dynamic security rules that don’t rely on static access lists but, instead, allow users to roam inside and outside the campus and still have all the access they need without exposing internal resources.

Frequently neglected but very powerful when set up properly is a standard (no additional license required) feature called User-ID. Through several mechanisms, the firewall can learn who is initiating which sessions, regardless of their device, operating system, or source IP. Additionally, security policies can be set so users are granted access or restricted in their capabilities based on their individual ID or group membership.

User-ID expands functionality with granular control of who is accessing certain resources and provides customizable reporting capabilities for forensic or managerial reporting.

Users can be identified through several different methods:

• Server monitoring:
  • Microsoft Active Directory security log reading for log-on and authentication events
  • Microsoft Exchange Server log-on events
  • Novell eDirectory log-on events
• The interception of X-Forwarded-For (XFF) headers, forwarded by a downstream proxy server
• Client probing using NetBIOS and WMI probes
• Direct user authentication:
  • The Captive Portal to intercept web requests and serve a user authentication form or transparently authenticate using Kerberos
  • GlobalProtect VPN client integration
• Port mapping on a multiuser platform such as Citrix or Microsoft Terminal Server where multiple users will originate from the same source IP
• The Extensible Markup Language (XML) API
• A syslog listener to receive forwarded logs from external authentication systems

You will have noticed there are many ways to leverage User-ID, so we will revisit this topic in depth in Chapter 6, Identifying Users and Controlling Access.

Now that you’ve completed this chapter, you are able to identify the strengths of using a zone-based firewall versus a route-based one. You understand how applications can be identified even though they may all be using the same protocol and port, and you understand how deep packet inspection is achieved in single-pass parallel processing. Most importantly, you have a firm grasp of which phases a packet goes through to form a session. It’s okay if this information seems a bit overwhelming; we will see more practical applications, and implications, in the next two chapters. We will be taking a closer look at how security and NAT rules behave once you start playing with zones, and how to anticipate expected behavior by simply glancing at the rules.

If you are preparing for the PCNSE exam, this chapter covered parts of the Planning and Core Concepts and Deploy and Configure domains. Make note of Figure 1.2 regarding packet processing, remember that route lookups and PBF form the basis of zoning, and take note of how App-ID and Content-ID interoperate.

In the next chapter, we will learn how to set up a firewall from scratch and get up and running in no time. We will glance over the physical and virtual components and how to configure them so traffic can flow through, and NAT can be applied where needed.