Objectives:
- Display and manage security policy rules
- Describe the difference between implicit and explicit rules
- Create a security policy
- Describe the difference between source and destination NAT
- Configure source NAT
- Configure destination NAT port forwarding
Controlling Network Traffic
All traffic flowing through the data plane of the Palo Alto firewall is checked against a security policy.
The traffic matching does not include any traffic originating from the management interface of the firewall as it does not pass through the data plane of the firewall.
Security rules can be defined on the firewall using various criteria such as zones, applications, IP addresses, ports, users, and host information profiles.
Sessions and Flows
The Palo Alto firewal is a stateful firewall. A stateful firewall matches all traffic passing through the firewall against a session with a I.D. number. Each session is then checked against a security policy rule.
Each session is idenitfied by a six tuple consisting of:
- Source and destination IP address
- Source and destination port numnber, For non-UDP/TCP traffic, different protocol fields are used
- Protocol
- Source security zone
The end point where the traffic was initiated will always be identified as the client. The endpoint where the traffic from the client is destined too is known as the server.
When security policy rules are defined, only the direction of the client to the server should be considered. Return traffic is automatically permitted by the Palo Alto firewall.
Security Policy Rule Types
Three different tyypes of rules can be defined within a security policy.
The rule type specifies whether a rule applies to traffic within a zone, between zones, or both.
Intrazone applies all traffic within a specific zone. A destination zone can not be applied for an intrazone rule
If multiple source zones were applied, the rule apply to traffic with a source and destination of the same specific zone
An interzone rule applies to all matching traffic between the specified source and destination zones, but not traffic within the same zone.
A universal rule applies to all matching interzone and intrazone traffic in the specified source and destination zones.
Implict and Explict Rules
The firewall implictly allows intrazone traffic and denies interzone traffic.
Explict rules must be created to control all other traffic, above the order of the two implict rules.
The interzone default rule saves the need for the network administrator to create a rule that blocks all traffic not defined by a security policy.
The intrazone and interzone rules do not log traffic, however the Palo Alto recommendation is to log all traffic. So it is recommended to turn on logging for the implict security rules
Note, a placement of an explict deny all rule at the end of the explict rules may negatively effect firewall performance. The reasoning behind this is a explict deny all rule would be above in order to the implict permit between intrazone rule.
Security Policy Match
Security Policy rules are evaluted for a match from top to bottom.
The policy rules themselves are unidirectional, from source zones to destination zones. So if traffic is intended to be initiated in both directions it is recommended to have two policy rules
It is recommended to reduce the use of ‘any’ when defining security rules
Policy Rule Hit Count
An administrator should regularly review, identify, and determine rules that are being used freqently and what rules are unused and are to be removed.
Hit counts can be reset to validate the usage of an existing rule over a given period of time.
Hit count data also incluides the number of traffic matches, timestamps, number of applications seen, and the number of days with no new applications seen.
Rule Shadowing
Rule shadowing is when an above rule casts a shadow over further rules in the evaluation order, ethier by casting too wide a net for further rules to ever be evaluted for traffic matching
Universally Unique Identifers (UUID)
UUIDs are created when a security policy rule is made. The UUID helps to provide a complete audit trial that keens a history of the entire operational history of a rule from the time of its creation.
UUIDs were created since previous to PAN-OS 9.0, if a rule was renamed it’s history was lost forever.
The UUID allows history regarding the firewall rule to be kept no matter how many changes are made to it.
Finding Unused Security Policy Rules
Administrators from time to to time should inspect their security policy rulebase, cleaning up unused rules.
This can be performed easily by checking the ‘Highlight Unused Rules’ checkbox in the Security Policies section of the fireewall.
This option can also be used when it comes to troubleshooting a firewalls security policy.
Tag-Based Rule Groups
In PAN-OS 9.0 the tag browser is replaced with the ability to assign rules to tag groups.
Once rules are assigned to a tag-group, the rulebase can be viewed as a tag group to visually group rules based on the tagging structure created.
When the rule base is viewed as groups, operational procedures such as adding, deleting, or movement of the rules can be carried out within the tag group for easier management of the rule base
Rule tag groups are displayed in the same order as rules in the rule base. A single tag group may appear multiple times throughout the rule base to preserve rule hierarchy.
Using Global Find
The candidate configuration and content databases can be searched for a particular string when using global find
This can include IP addresses, Object names, Policy rule names, Threat IDs, and Application names.
The global find does not search dynamic content such as logs, addresses ranges, or allocated DHCP addresess.
It also does not search individual username or group names that are identified by User-ID.
Rule Changes Archive
Clicking the Audit Comment Archieve link in the properties of a security policy rule, allows the administrator to view audit comment history and configuration log history between commits.
Configuration versions can be compared to allow the administrator to see what has been changed in the security policy.
Test Policy Functionality
Policy rules and managed device configurations can be tested to ensure that candidate configurations are correctly securing the network, and connectivity can be checked to ensure network resources can be reached.
The test security policy match allows a set of test criteria to be entered, and it is evaluated against the current security policy for a match or not.
NAT Types
Source NAT
Source NAT is used for private users to access the public internet, outbound traffic
Destination NAT often is used to provide hosts on the public internet access to private servers.
For source and destination NAT, the firewall maintains the mapping of pre-NAT to post-NAT IP addresses
Source NAT
Source NAT changes the source address of the packets that match the NAT policy as the packets go through the firewall.
Source NAT is used to allow host devices configured with private IP addressing to send and receive traffic on the publicaly address internet
Source NAT Types
Static IP
Static IPs are a 1 to 1 fixed translation.
It changes the source IP address, leaving the source port unchanged.
The static IP NAT type supports the implicit bidirectional rule feature
Dynamic IP
1 to 1 translations of a source IP address only, no port number.
Private source addresses are translated to the next available address in the public IP range.
Dynamic IP and Port
Allows multiple clients to use the same public IP addresses with different source port numbers.
The assigned address can set to an interface address or a translated address.
Dynamic IP and Port Oversubscription
The TCP protocl recognises around a maximum of around 64,512 available ports, subtracing 65,536 from 1024 well known ports.
Some PAN-OS platforms support DIPP NAT oversubscription, allowing the use of port numbers by using the destination IP address as an additional identifier for the NAT session.
The NAT oversubscription rate can be configured up the maximum rate supported by the hardware platform
Destination NAT
Destination NAT translates an original destination IP address to an alternative destination IP address.
Destination NAT attribututes
Static IP mapping with optional port forwarding
1 to 1 fixed translation, enabled by static source NAT with the bi-directional option set. This changes the destination IP address whilst leaving the destination port unchanged.
Dynamic IP address support for destination NAT
The translated address can be a FQDN, address object or group.
The translated original IP address can be set to a destination host with a DHCP assigned address.
Each FQDN can support up to 32 IPv4, or IPv6 addresses
Configuring Destination NAT
Destination NAT uses the original packet tab to define the source and destination zones of hte packets that the firewall will translate, and specifies the destination interface and type of service
NAT rules must be configured ot the use the zone associated with the pre-NAT ip addresses configured in the policy.
Traffic subjected to NAT must be permitted explicity by the security policy when that traffic traverses multiple zones.
Leave a Reply