Creating and Managing Firewall Policies
Create firewall policies to store the firewall policy rules you create to control how a firewall inspects, allows, or denies network traffic.
Create firewall policies before creating firewalls. Every firewall must have at least one firewall policy associated with it.
When you create a firewall policy, usual Network Firewall service limits and restrictions apply.
About firewall policy rule components
After you create a firewall policy, start preparing to create firewall policy rules. With firewall policy rule components, you can create lists to group applications, services, URLS, or addresses to use in a firewall policy rule. All items in a list are treated the same way when they're used in a rule. The list can then be referenced in a rule.
A rule component can also include decryption profiles. Create a decryption profile with a mapped secret to control how SSL forward proxy and SSL inbound inspection perform session mode checks, server checks, and failure checks.
About firewall policy rules
A firewall policy rule is a set of criteria you define for a firewall policy to allow or deny network traffic with a firewall. You can create the following types of firewall policy rules:
- Decryption rules to decrypt traffic
- Security rules to allow or block traffic
- Tunnel inspection rules to inspect traffic
If you create a firewall policy and don't define any firewall policy rules, then all network traffic will be denied.
- Decryption rules are always applied before security rules.
- Decryption rules and security rules are applied using a priority order that you can define
- The firewall evaluates the decryption rules in priority list order.
- When a decryption rule matches the packet information, the firewall applies the specified rule action.
- When a rule action is applied, the firewall doesn't evaluate any further decryption rules.
- If the packet information doesn't match any decryption rules, the firewall doesn't decrypt the packet.
- The firewall evaluates the security rules in priority list order.
- When a security rule matches the packet information, the firewall applies the specified rule action.
- When a rule action is applied, the firewall doesn't evaluate any further security rules.
- If the packet information doesn't match any security rules, the firewall drops the packet.
Rules are optional, but if the policy that you use with a firewall doesn't have at least one rule specified, the firewall denies all network traffic.
By default, each new rule that you create becomes the first in the priority list. You can change the priority order at any time.
About decryption rules
Decryption rules decrypt traffic from a specified source, destination, or both. The specified source and destination match condition for the traffic consists of address lists that you configure in the policy before you construct the rule.
When the specified source and destination match condition is met, the firewall takes the rule action. You can choose to take the following actions:
- Decrypt traffic with SSL forward proxy
- Decrypt traffic with SSL inbound inspection
- Don't decrypt traffic.
If you choose to decrypt, you then choose a decryption profile and mapped secret to apply when decrypting traffic. You configure decryption profiles and mapped secrets in the policy before you construct the rule. By default, the priority order of decryption rules is their order of creation. You can change the priority order.
- Maximum number of decryption rules for each policy: 1,000
Secrets and profiles for decryption rules
If a firewall policy uses decryption rules that use certificate authentication, you must set up mapped secrets and decryption profiles.
Mapped secrets are secrets that you create in the Vault service and then map to inbound or outbound SSL keys. The secrets are used to decrypt and inspect SSL/TLS traffic with SSL forward proxy and SSL inbound inspection.
If you plan to use SSL forward proxy or SSL inbound inspection, set up a vault and secrets before you begin configuring a policy with rules. See Setting Up Network Traffic Decryption and Inspection.
Decryption profiles control how SSL forward proxy and SSL inbound inspection perform session mode checks, server checks, and failure checks.
- Block expired certificate: Blocks sessions if the server's certificate is expired. This option prevents access to potentially insecure sites. If this option isn't selected, users can connect and transact with potentially malicious sites and see warning messages when they try to connect, but the connection isn't prevented.
- Block untrusted issuer: Blocks sessions if the server's certificate is issued by an untrusted certificate authority (CA). An untrusted issuer might indicate a man-in-the-middle attack, a replay attack, or other attack.
- Block timeout certificate: Blocks sessions if the certificate status check times out. Certificate status checks use the Certificate Revocation List (CRL) on a revocation server or use Online Certificate Status Protocol (OCSP) to see if the CA that issued the certificate has revoked it. Revocation servers can be slow to respond, which can cause the session to timeout, even if the certificate is valid.
- Block unsupported cipher: Blocks sessions if the SSL cipher suite specified in the SSL handshake isn't supported.
- Block unsupported version: Blocks sessions if the SSL version specified in the SSL handshake isn't supported.
- Block unknown certificate: Blocks sessions if the certificate status is returned as "unknown." Certificate status might be unknown for many reasons, so use this option in higher-security areas of the network instead of for general security.
- Restrict certificate extensions: Restricts extensions to key usage and extended key usage. Use this option only if deployment requires no other certificate extensions.
- Auto-include alternative name: Automatically appends a Subject Alternative Name (SAN) to the impersonation certificate if the server certificate is missing.
- Block if no resources: Blocks sessions if not enough processing resources are available. If you don't use this option, encrypted traffic enters the network still encrypted, risking potentially dangerous connections. Using this option might affect the user experience by making sites temporarily unreachable.
- Block sessions with unsupported versions: Blocks sessions that have a weak, unsupported version of SSL protocol.
- Block unsupported cipher: Blocks sessions if the SSL cipher suite specified in the SSL handshake isn't supported.
- Block if no resources: Blocks sessions if not enough processing resources are available. If you don't use this option, encrypted traffic enters the network still encrypted, risking potentially dangerous connections. Using this option might affect the user experience by making sites temporarily unreachable.
- Maximum number of mapped secrets for each policy: 300
- Maximum number of SSL inbound mapped secrets for each policy: 300
- Maximum number of SSL forward proxy mapped secrets for each policy: 1
- Maximum number of decryption profiles for each policy: 500
To create a mapped secret, see Create a Mapped Secret.
To create a decryption profile, see Create a Decryption Profile.
About security rules
Firewalls use security rules to decide what network traffic is allowed or blocked. Each rule contains a set of criteria that packet information must match to apply the rule. This is called the rule match condition.
You can configure a security rule to match based on source and destination address, application, service, or URL. The specified source and destination match condition for the traffic consists of lists that you configure in the policy before you construct the rule.
If no match criteria are defined in the security rule (an empty list is specified for the rule), then the rule matches to wildcard ("any") criteria. This behavior applies to all traffic examined in the rule.
- Allow traffic: The traffic is allowed to proceed.
- Drop traffic: The traffic is dropped silently, and no notification of reset is sent.
- Reject traffic: The traffic is dropped and a reset notification is sent.
- Intrusion detection: The traffic is logged.
- Intrusion prevention: The traffic is blocked.
- Maximum number of security rules for each policy: 10,000
About tunnel inspection rules
Use tunnel inspection rules to inspect traffic mirrored to an Oracle resource using the Virtual Test Access Point service. Traffic captured at the Virtual Test Access Point (VTAP) source is encapsulated in VXLAN and then sent to the VTAP target.
You can mirror all traffic, or use a capture filter to only mirror traffic you're interested in.
When the specified source and destination match condition is met, the firewall applies a default Palo Alto Networks® tunnel inspection profile. The profile has the following characteristics, and isn't editable:
- Protocol: VXLAN
- Maximum Tunnel Inspection Levels: One level of encapsulation is inspected
- Return scanned VXLAN tunnel to source: True. Returns the encapsulated packet to the originating VXLAN tunnel endpoint (VTEP).
The Tunnel Inspection log provides information on mirrored VXLAN traffic passing through the firewall.
- Maximum number of tunnel inspection rules for each policy: 500