For this chapter, no physical installation is required; the technology is only explained. 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 the firewall as an element of your network, most likely you will imagine a network design like the one in the following image, with two to four areas surrounding a box. Most of the time, whatever is placed in the north is considered dangerous, east and west are somewhat grey areas, and the south is the happy place where users do their daily tasks. The box in the middle is the firewall.

Figure 1.1 – Basic network topology

In reality, a network design may look a lot more complex due to network segregation, segmentation, remote offices being connected to the 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 and are usually represented by tags that can be attached to a subnet object. They hold no bearing in 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. 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 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. 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. 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:

Figure 1.2 – Phases of packet processing

After these zone lookups have been performed, the firewall will continue to the security policy evaluation.

The policy evaluation then uses the 'six tuple' (6-Tuple) to match establishing sessions to security rules:

1. Source IP
2. Source Port
3. Destination IP
4. Destination Port
5. Source Zone
6. Protocol

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 intra- 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 also be set to only accept traffic within the same zone, between different zones only, or both. This way, an administrator could set a specific rule for the intrazone setting and allow all applications without inadvertently allowing this full access to be open to a different network. Adding a second zone to that same rule would allow the same access inside the new zone, but there would not be any access granted between the zones; that would require a new interzone or universal rule:

Figure 1.3 – Different security rule types and default rules

Let's now look at the expected behavior when determining zones.

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  10     A 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 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 whatever NAT action is applied.

  Important note

  Remember that NAT policy evaluation happens after the initial zones have been determined, but before the security policy is evaluated.

App-ID and Content-ID are two technologies that go hand in hand and make up the core inspection mechanism. They ensure applications are identified and act as expected, threats are intercepted and action is applied based on a configurable policy, and data exfiltration is prevented.

How App-ID gives more control

Determining which application is contained within a specific data flow is the cornerstone of any next-generation firewall. It can no longer be assumed that any sessions using TCP port 80 and 443 are simply plaintext or encrypted web browsing, as 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:

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. First, the 6-Tuple is checked against the security policy to verify whether a certain source, destination, protocol, and port combination is allowed or not. 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. Next, the packets will be checked against known application signatures and the app cache to see if the session can be rapidly identified, 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.

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.

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. 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, or an unknown generic application, like unknown-tcp. The session is then again 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. Once it is determined which protocol is used, another security policy check is performed. 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. 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 application web-browsing 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.

How Content-ID makes things safe

Meanwhile, 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:

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.

Hardware and VM design is centered on enabling the best performance for parallel processing while still performing tasks that cost processing power that 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, which we'll learn about in the next section.

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. All platforms have a management plane. Larger platforms like the PA-5200 come with 2 to 3 data planes and the largest platforms have replaceable hardware blades (line cards) that have up to 3 data plane equivalents per line card and can hold up to 10 line cards. The smaller platforms like the PA-220 only have the 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 that are not directly related to processing packets.

The data plane is responsible for processing flows and performs all the security features associated with the next-generation firewall. 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.

Another important feature is the ability to identify users and apply different security policies based on identity or group membership.

Frequently neglected but very powerful when set up properly is a standard 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 events

  --Microsoft Exchange Server log-on events

  --Novell eDirectory log-on events

• The interception of X-Forward-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 XML API
• A syslog listener to receive forwarded logs from external authentication systems

You should now understand which basic technologies make up the security ecosystem on the Palo Alto Networks firewall. It's okay if this seems a bit vague as 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.