Mastering Palo Alto Networks
An exciting insight into one of our best selling books...
Looking for a new book?
Check the Mastering Palo Alto Networks book by Tom Piens on Amazon! Tom will also be helping us out with supporting articles, insights, and other helpful resources in the near future, so keep your eyes peeled!
We are going to take a closer look at how security zones control how security, Network Address Translation (NAT), and routing verdicts are made. We will review the mechanics behind App-ID and Content-ID so you get a deeper understanding of how packets are processed and security decisions are made by the firewall, and we will review how User-ID contributes to a more robust security stance by applying group-based or user-based access control.
This chapter will cover the following topics:
• Understanding the zone-based firewall
• Understanding App-ID and Content-ID
• The management and data plane
• Authenticating users with User-ID
By the end of this chapter, you will have a better understanding of how the core technology is built up and will be able to apply these skills when we start building your configuration. If you’re preparing for the PCNSE exam, this chapter will also help you understand the fundamentals required to tackle some of the scenario-based questions.
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:
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 setting can be changed in the rule Type and is set to Universal by default.
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.
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 an NGFW “next generation.”
Understanding App-ID and Content-ID
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 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.
Important note
Remember that NAT policy evaluation happens after the initial zones have been
determined, but before the security policy is evaluated. This will cause outbound NAT rules to come from lan and go to external, but inbound NAT rules to match as coming from external and also going to external while the inbound security rule will use the appropriate destination zone.
Understanding the Core Technologies
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. 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. 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. 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 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. App-ID signatures and decoders are regularly (usually once a month around the 15th) 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 you can control 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
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. 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.
In this section you learned how all the 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 is focused 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.
The management and data plane
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 have an additional control plane and two to three data planes, and 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, and monitoring processes on the data planes. 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.
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 for more dynamic security rules that don’t rely on static access lists, but instead allows users to roam inside and outside the campus and still have all the access they need without exposing internal resources.
Authenticating and authorizing users with User-ID
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 events; Microsoft Exchange Server log-on events; and 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 requestsand serve a user authentication form or transparently authenticate using Kerberos; and 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 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.
Enjoy what you’ve seen so far?
Check the Mastering Palo Alto Networks book by Tom Piens on Amazon! Tom will also be helping us out with supporting articles, insights, and other helpful resources in the near future, so keep your eyes peeled!