Network Firewall Policy Rules and Rule Components

Learn about the rules and rule components in a network firewall policy that control how the firewall handles network traffic.

Policies contain the rules that control how the firewall inspects, allows, or denies network traffic. Each firewall is associated with a single policy, but a policy can be associated to mulitple firewalls. Within a policy, lists and maps are the objects that are used to help you express rules in a clear and concise manner.

The firewall applies rules to an incoming packet in the following order:
  1. Evaluates the decryption rules in priority list order.
  2. When a decryption rule matches the packet information, the firewall applies the specified rule action.
  3. When a rule action is applied, the firewall does not evaluate any further decryption rules.
  4. If the packet information doesn't match any decryption rules, the firewall does not decrypt the packet.
  5. Evaluates the security rules in priority list order.
  6. When a security rule matches the packet information, the firewall applies the specified rule action.
  7. When a rule action is applied, the firewall does not evaluate any further security rules.
  8. If the packet information doesn't match any security rules, the firewall drops the packet.
Warning

Oracle recommends that you update network firewall policies during a maintenance window.

When you edit a network firewall policy and then attach it to a firewall, the firewall status is temporarily reported as "updating" while the service completes the request.

While the firewall is updating, it sends a "TCP-RST" message for TCP traffic which might cause existing TCP client connections to reset. There is no impact to UDP and ICMP traffic.

To create a network firewall, you must have at least one network firewall policy that you can attach to the firewall. If you're using the console, you can create a policy as part of the workflow. If you're using the API or CLI, you must create a policy first, and then create the firewall.

Building Rules

The Create Policy workflow helps you create rule components and build rules. You don't have to use all components in a policy - including each type is optional. The components for rules are created in the workflow in this order:
  1. Lists
  2. Mapped Secrets and Decryption Profiles
  3. Rules

Rules are created last so they can use the lists, secrets, and decryption profiles you created in the first two steps.

Important

Although rules are optional, a policy must have at least one rule or any firewall that it is associated with denies all network traffic.

After you associate a policy to a firewall, the firewall begins to allow or deny traffic based on the rules in the policy. Policies that are associated to one or more firewalls cannot be deleted. If you want to delete the policy, first associate the firewall to a different policy, then delete the original policy.

You can't edit a policy that is associated with a firewall. To make changes to the firewall's policy, clone the policy and edit the clone. Then, edit the firewall to associate it to the cloned policy. See Cloning a policy.

Lists

Network firewall lists are building blocks that let you group application types, URLs, or IP addresses for use in a rule. Lists are the first resource you create when you create your policy.

All items in the list are treated the same way when they are used in a rule. For example, if you want to create a rule that denied access to known malicious URLs, you can create a URL list called "Malicious URLs". Then, you can create a rule that denies access to the entire list as a group.

Application Lists

Create application lists to allow or deny traffic to a group of applications. You can include a maximum of 25 applications in each list. Customize the definition of the applications in the list using the following criteria:

Protocol Type: TCP, UDP, ICMP, or ICMPv6
Note

TCP and UDP protocols can be combined in a list, but ICMP can't be combined with TCP or UDP.

Port Number: Used when you select TCP or UDP. Enter a port number or range. For example, "80-8080", "22-22".

ICMP Type: Used when you select ICMP. 0-Echo reply, 3-Destination unreachable, 5-Redirect, 8-Echo

ICMP Code: Used when you select ICMP. 0-Net unreachable, 1-Host unreachable, 2-Protocol unreachable, 3-Port unreachable

URL Lists

Create URL lists to allow or deny traffic to a group of URLs. You can include a maximum of 25 URLs in each list. Each URL is entered on its own line within the list. You can use wildcards like asterisks (*) and caret (^) in a URL to customize matching. Don't enter protocol information like "http://" or "https://".

Wildcard Example
*

Indicates one or more variable subdomains. The entry matches any additional subdomains at the beginning or end of the URL.

For example:

  • *.example.com matches www.example.com, www.docs.example.com, and www.example.com.ua
  • *.example.com/ matches www.example.com and www.docs.example.com but not www.example.com.ua
^

Indicates a single variable subdomain

For example:

  • mail.^.com matches to mail.example.com but not mail.example.sso.com.
Also see Examples of using wildcards in URL filtering profiles.
Here is an example of a URL list:
www.example.com
production1.example.com
production2.example.com
www.example.net
www.example.biz
[1080:0:0:0:8:800:200C:417A]:8080/index.html
1080:0:0:0:8:800:200C:417A/index.html
*.example.com

IP Address Lists

Create IP address lists to allow or deny traffic to a group of IP addresses or CIDR blocks. Both IPv4 and IPv6 addresses and CIDR blocks are acceptable. You can include a maximum of 25 IP addresses or CIDR blocks in each list. Each IP address is entered on its own line within the list.

For example:

10.0.0.0/16
10.1.0.0/24
10.2.0.0/24
10.3.0.0/24
10.4.0.0/24
10.5.0.0/24
2001:DB8::/32
2603:c020:0:6a00::/56
2603:c020:0:6aa1::/64

Mapped Secrets and Decryption Profiles

If your policy uses decryption rules that use certificate authentication, you must set up mapped secrets and decryption profiles. You can set up a maximum of 25 mapped secrets and 25 decryption profiles for each policy.

Mapped secrets and decryption profiles are the second resource you create when you create your policy.

Mapped secrets are secrets that you create in Oracle Cloud Infrastructure Vault and then map to inbound or outbound SSL keys. The secrets are used to decrypt and inspect SSL/TLS traffic with SSL Forward Proxy or SSL Inbound Inspection.

If you plan on using SSL forward proxy or SSL inbound inspection, set up your Oracle Cloud Infrastructure Vault and secrets before you begin creating your policy. See Setting Up Certificate Authentication for instructions.
Note

Only one SSL forward proxy secret is allowed for each policy.

Decryption profiles control how SSL forward proxy and SSL inbound inspection perform session mode checks, server checks, and failure checks.

The following options are available for SSL Forward Proxy decryption profiles:
  • Block expired certificate: Block sessions if the server's certificate is expired. This option prevents access to potentially insecure sites. If not selected, users can connect with and transact with potentially malicious sites and see warning messages when they attempt to connect, but the connection is not prevented.
  • Block untrusted issuer: Block 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: Block sessions if the certificate status check times out. Certificate status checks Certificate Revocation List (CRL) on a revocation server or uses 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 time out, even if the certificate is valid.
  • Block unsupported cipher: Block sessions if the SSL cipher suite specified in the SSL handshake is not supported.
  • Block unknown certificate: Block sessions if the certificate status returned as "unknown". Certificate status might be unknown for multiple reasons, so use this option in higher-security areas of the network, instead of for general security.
  • Restrict certificate extensions: Restrict extensions to key usage and extended key usage. Use this option only if your deployment requires no other certificate extensions.
  • Auto-include alternative name: Automatically append Subject Alternative Name (SAN) to the impersonation certificate if the server certificate is missing.
  • Block if no resources: Block 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.
The following options are available for SSL Inbound Inspection decryption profiles:
  • Block sessions with unsupported versions: Block sessions that have weak, unsupported version of SSL protocol.
  • Block unsupported cipher: Block sessions if the SSL cipher suite specified in the SSL handshake is not supported.
  • Block if no resources: Block 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.

Understanding Rules

Rules are a set of criteria against which a network packet is matched. Rules are configured in a policy, and the policy is then associated to a firewall. The firewall then allows or denies traffic according to the rules in its associated firewall.

Rules are the final step in creating a policy, and use the lists, mapped secrets, and decryption profiles you configured in the previous steps.

Rules are applied to a network packet using specific criteria:
  • Decryption rules are always applied before security rules.
  • Both decryption rules and security rules are applied using a priority order that you can define when you create the policy.

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 IP 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:
  • Decrypt with SSL forward proxy
  • Decrypt with SSL inspection
  • Don't decrypt the 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.

You can have a maximum of 50 decryption rules for each policy. By default, the priority order of decryption rules is their order of creation. You can change the order of priority.

Security Rules

Firewalls use security rules to determine 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 IP address, application, 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. For each match condition category, you can select up to 25 lists.
Important

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.
The rule action defines how the firewall handles the packet if it matches the specified conditions. The firewall can perform the following actions:
  • Allow traffic: The traffic is allowed to proceed.
  • Drop traffic: The traffic is dropped silently, no notification of reset is sent.
  • Intrusion detection: Logs the traffic
  • Intrusion prevention: Blocks the traffic.
    Important

    If you want to use intrusion detection and prevention, you must also enable logging. See Logs.
  • Reject traffic: The traffic is dropped and a reset notification is sent.