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.
- 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 does not evaluate any further decryption rules.
- If the packet information doesn't match any decryption rules, the firewall does not decrypt the packet.
- 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 does not evaluate any further security rules.
- If the packet information doesn't match any security rules, the firewall drops the packet.
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
Rules are created last so they can use the lists, secrets, and decryption profiles you created in the first two steps.
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:
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:
|
| ^ |
Indicates a single variable subdomain For example:
|
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.comIP 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::/64Mapped 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.
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.
- 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.
- 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.
- 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.
- 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.
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, 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.
Next Steps
-
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.
- Create a policy.
- Create a network firewall.
- Troubleshoot network firewalls and policies.