Understanding Security Policy Rules

The security policy applies the security rules to the transit traffic within a context (from-zone to to-zone). Each policy is uniquely identified by its name. The traffic is classified by matching its source and destination zones, the source and destination addresses, and the application that the traffic carries in its protocol headers with the policy database in the data plane.

• A source zone
• A destination zone
• One or many source address names or address set names
• One or many destination address names or address set names
• One or many application names or application set names

These characteristics are called the match criteria. Each policy also has actions associated with it: permit, deny, reject, count, log, and VPN tunnel. You have to specify the match condition arguments when you configure a policy, source address, destination address, and application name.

You can specify to configure a policy with IPv4 or IPv6 addresses using the wildcard entry any. When flow support is not enabled for IPv6 traffic, any matches IPv4 addresses. When flow support is enabled for IPv6 traffic, any matches both IPv4 and IPv6 addresses. To enable flow-based forwarding for IPv6 traffic, use the set security forwarding-options family inet6 mode flow-based command. You can also specify the wildcard any-ipv4 or any-ipv6 for the source and destination address match criteria to include only IPv4 or only IPv6 addresses, respectively.

When flow support for IPv6 traffic is enabled, the maximum number of IPv4 or IPv6 addresses that you can configure in a security policy is based on the following match criteria:

• Number_of_src_IPv4_addresses + number_of_src_IPv6_addresses * 4 <= 1024
• Number_of_dst_IPv4_addresses + number_of_dst_IPv6_addresses * 4 <= 1024

Thr reason for the match criteria is that an IPv6 address uses four times the memory space that an IPv4 address uses.

Note: You can configure a security policy with IPv6 addresses only if flow support for IPv6 traffic is enabled on the device.

If you do not want to specify a specific application, enter any as the default application. To look up the default applications, from configuration mode, enter show groups junos-defaults | find applications (predefined applications). For example, if you do not supply an application name, the policy is installed with the application as a wildcard (default). Therefore, any data traffic that matches the rest of the parameters in a given policy would match the policy regardless of the application type of the data traffic.

The action of the first policy that the traffic matches is applied to the packet. If there is no matching policy, the packet is dropped. Policies are searched from top to bottom, so it is a good idea to place more specific policies near the top of the list. You should also place IPsec VPN tunnel policies near the top. Place the more general policies, such as one that would allow certain users access to all Internet applications, at the bottom of the list. For example, place deny-all or reject-all policies at the bottom after all of the specific policies have been parsed before and legitimate traffic has been allowed/count/logged.

Note: Support for IPv6 addresses added in Release 10.2 of Junos OS and support for IPv6 addresses in active/active chassis cluster configurations (in addition to the existing support of active/passive chassis cluster configurations) has been added in Junos OS Release 10.4.

Policies are looked up during flow processing after firewall filters and screens have been processed and route look up has been completed by the Services Processing Unit (SPU) (for high-end SRX Series devices). Policy look up determines the destination zone, destination address, and egress interface.

• Security policies are configured in a from-zone to to-zone direction. Under a specific zone direction, each security policy contains a name, match criteria, an action, and miscellaneous options.
• The policy name, match criteria, and action are required.
• The policy name is a keyword.
• The source address in the match criteria is composed of one or more address names or address set names in the from-zone.
• The destination address of the match criteria is composed of one or more address names or address set names in the to-zone.
• The application name in the match criteria is composed of the name of one or more applications or application sets.
• One of the following actions is required: permit, deny, reject, count, or log.
• When logging is enabled, the system logs at session close (session-close) time by default. To enable logging at session creation, use the session-init command.
• When the count alarm is turned on, you can, optionally, specify alarm thresholds in bytes per second and kilobytes per minute.
• You cannot specify global as either the from-zone or the to-zone except under following condition:

  Any policy configured with the to-zone as a global zone must have a single destination address to indicate that either static NAT or incoming NAT has been configured in the policy.

• In SRX Series Services Gateways, the policy permit option with NAT is simplified. Each policy will optionally indicate whether it allows NAT translation, does not allow NAT translation, or does not care.

• Address names cannot begin with the following reserved prefixes. These are used only for address NAT configuration:

  • static_nat_
  • incoming_nat_
  • junos_
• Application names cannot begin with the junos_ reserved prefix.

Understanding Wildcard Addresses

Source and destination addresses are two of the five match criteria that should be configured in a security policy. You can now configure wildcard addresses for the source and destination address match criteria in a security policy. A wildcard address is represented as A.B.C.D/wildcard-mask. The wildcard mask determines which of the bits in the IP address A.B.C.D should be ignored by the security policy match criteria. For example, the source IP address 192.168.0.11/255.255.0.255 in a security policy implies that the security policy match criteria can discard the third octet in the IP address (symbolically represented as 192.168.*.11). Therefore, packets with source IP addresses such as 192.168.1.11 and 192.168.22.11 conform to the match criteria. However, packets with source IP addresses such as 192.168.0.1 and 192.168.1.21 do not satisfy the match criteria.

The wildcard address usage is not restricted to full octets only. You can configure any wildcard address. For example, the wildcard address 192.168. 7.1/255.255.7.255 implies that you need to ignore only the first 5 bits of the third octet of the wildcard address while making the policy match. If the wildcard address usage is restricted to full octets only, then wildcard masks with either 0 or 255 in each of the four octets only will be permitted.

Note: The first octet of the wildcard mask should be greater than 128. For example, a wildcard mask represented as 0.255.0.255 or 1.255.0.255 is invalid.

A wildcard security policy is a simple firewall policy that allows you to permit, deny, and reject the traffic trying to cross from one security zone to another. You should not configure security policy rules using wildcard addresses for services, such as Intrusion Detection and Prevention (IDP), Unified Threat Management (UTM), and IP Security (IPsec).

Configuring wildcard security policies on a device affects performance and memory usage based on the number of wildcard policies configured per from-zone and to-zone context. Therefore, you can only configure a maximum of 480 wildcard policies for a specific from-zone and to-zone context.

Note: IPv6 wildcard address configuration is not supported in this release.

For detailed information on the wildcard address configuration syntax and options, see the Junos OS CLI Reference Guide.