Configuring Security Policies

A security policy is a set of statements that controls traffic from a specified source to a specified destination using a specified service. A policy permits, denies, or tunnels specified types of traffic unidirectionally between two points.

Each policy consists of:

• A unique name for the policy.

• A from-zone and a to-zone, for example: user@host# set security policies from-zone untrust to-zone untrust

• A set of match criteria defining the conditions that must be satisfied to apply the policy rule. The match criteria are based on a source IP address, destination IP address, and applications. The user identity firewall provides greater granularity by including an additional tuple, source-identity, as part of the policy statement.

• A set of actions to be performed in case of a match—permit, deny, or reject.

• Accounting and auditing elements—counting, logging, or structured system logging.

If the SRX Series receives a packet that matches those specifications, it performs the action specified in the policy.

Security policies enforce a set of rules for transit traffic, identifying which traffic can pass through the firewall and the actions taken on the traffic as it passes through the firewall. Actions for traffic matching the specified criteria include permit, deny, reject, log, or count.

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.

Each policy is associated with the following characteristics:

• 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.

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.

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 SRX5400, SRX5600, and SRX5800 devices). Policy look up determines the destination zone, destination address, and egress interface.

When you are creating a policy, the following policy rules apply:

• 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, or reject.

• Accounting and auditing elements can be specified: count and log.

• You can enable logging at the end of a session with the session-close command, or at the beginning of the session with the session-init command.

• When the count alarm is turned on, specify alarm thresholds in bytes per second or 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 Firewalls, 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.

Enhanced policy configuration synchronization mechanism improves how policy configurations are synchronized between the Routing Engine (RE) and the Packet Forwarding Engine (PFE), enhancing system reliability and security. This mechanism ensures policies are automatically and accurately synchronized. In addition, the system effectively prevents any flow-drops during the security policy configuration change process.

For platform-specific support, see Platform-Specific Policy Configuration Synchronization Behavior.

• File-Serialization
• Prevent Flow Session Disruption During Policy Configuration Changes

• Memory and Error Handling
• Support for Logical System and Tenant System

You can configure the security policy for self-traffic to apply services to self-traffic. The host-outbound policies will work only in cases where the packet that originated in the host device goes through the flow and the incoming interface of this packet is set to local.

The advantages of using the self-traffic are:

• You can leverage most of the existing policy or flow infrastructure used for the transit traffic.

• You do not need a separate IP address to enable any service.

• You can apply services or policies to any host-inbound traffic with the destination IP address of any interface on the device.

The security policies for the self traffic are configured under the new default security zone called the junos-host zone. The junos-host zone will be part of the junos-defaults configuration, so users cannot delete it. The existing zone configurations such as interfaces, screen, tcp-rst, and host-inbound-traffic options are not meaningful to the junos-host zone. Therefore there is no dedicated configuration for the junos-host zone.

You must complete the following tasks to create a security policy:

1. Create zones. See Example: Creating Security Zones.

2. Configure an address book with addresses for the policy. See Example: Configuring Address Books and Address Sets.

3. Create an application (or application set) that indicates that the policy applies to traffic of that type. See Example: Configuring Security Policy Applications and Application Sets.

4. Create the policy. See Example: Configuring a Security Policy to Permit or Deny All Traffic, Example: Configuring a Security Policy to Permit or Deny Selected Traffic, and Example: Configuring a Security Policy to Permit or Deny Wildcard Address Traffic.

5. Create schedulers if you plan to use them for your policies. See Example: Configuring Schedulers for a Daily Schedule Excluding One Day.

The Firewall Policy Wizard enables you to perform basic security policy configuration. For more advanced configuration, use the J-Web interface or the CLI.

A secure network is vital to a business. To secure a network, a network administrator must create a security policy that outlines all of the network resources within that business and the required security level for those resources. The security policy applies the security rules to the transit traffic within a context (from-zone to to-zone) and each policy is uniquely identified by its name. The traffic is classified by matching the 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.

For the platform-specific support for the security policy objects such as addresses, number of policies and so on, see Platform-Specific Policy Objects Support Behavior. Platform support depends on the Junos OS release in your installation.

.

Note that as you increase the number of addresses and applications in each rule, the amount of memory that is used by the policy definition increases, and sometimes the system runs out of memory with fewer than 80,000 policies.

To get the actual memory utilization of a policy on the Packet Forwarding Engine (PFE) and the Routing Engine (RE), you need to take various components of the memory tree into consideration. The memory tree includes the following two components:

• Policy context–Used to organize all policies in this context. Policy context includes variables such as source and destination zones.

• Policy entity–Used to hold the policy data. Policy entity calculates memory using parameters such as policy name, IP addresses, address count, applications, firewall authentication, WebAuth, IPsec, count, application services, and Junos Services Framework (JSF).

Additionally, the data structures used to store policies, rule sets, and other components use different memory on the Packet Forwarding Engine and on the Routing Engine. For example, address names for each address in the policy are stored on the Routing Engine, but no memory is allocated at the Packet Forwarding Engine level. Similarly, port ranges are expanded to prefix and mask pairs and are stored on the Packet Forwarding Engine, but no such memory is allocated on the Routing Engine.

Accordingly, depending on the policy configuration, the policy contributors to the Routing Engine are different from those to the Packet Forwarding Engine, and memory is allocated dynamically.

Memory is also consumed by the “deferred delete” state. In the deferred delete state, when an SRX Series Firewall applies a policy change, there is transitory peak usage whereby both the old and new policies are present. So for a brief period, both old and new policies exist on the Packet Forwarding Engine, taking up twice the memory requirements.

Therefore, there is no definitive way to infer clearly how much memory is used by either component (Packet Forwarding Engine or Routing Engine) at any given point in time, because memory requirements are dependent on specific configurations of policies, and memory is allocated dynamically.

The following best practices for policy implementation enable you to better use system memory and to optimize policy configuration:

• Use single prefixes for source and destination addresses. For example, instead of using /32 addresses and adding each address separately, use a large subnet that covers most of the IP addresses you require.

• Use application “any” whenever possible. Each time you define an individual application in the policy, you can use an additional 52 bytes.

• Use fewer IPv6 addresses because IPv6 addresses consume more memory.

• Use fewer zone pairs in policy configurations. Each source or destination zone uses about 16,048 bytes of memory.

• The following parameters can change how memory is consumed by the bytes as specified:

  • Firewall authentication–About 16 bytes or more (unfixed)

  • Web authentication–About 16 bytes or more (unfixed)

  • IPsec–12 bytes

  • Application services–28 bytes

  • Count–64 bytes

• Check memory utilization before and after compiling policies.

  Note:

  The memory requirement for each device is different. Some devices support 512,000 sessions by default, and the bootup memory is usually at 72 to 73 percent. Other devices can have up to 1 million sessions and the bootup memory can be up to 83 to 84 percent. In the worst-case scenario, to support about 80,000 policies in the SPU, the SPU should boot with a flowd kernel memory consumption of up to 82 percent, and with at least 170 megabytes of memory available.

This example shows how to configure a security policy to permit or deny all traffic.

This example shows how to configure a security policy to permit or deny selected traffic.

This example shows how to configure a security policy to permit or deny wildcard address traffic.

This example shows how to configure a security policy to send traffic logs generated on the device to an external system log server.

Manually adding address entries into a policy can be time consuming. There are external sources that provide lists of IP addresses that have a specific purpose (such as a blocklist) or that have a common attribute (such as a particular location or behavior that might pose a threat). You can use the external source to identify threat sources by their IP address, then group those addresses into a dynamic address entry, and reference that entry in a security policy. Thereby you can control the traffic to and from those addresses. Each such group of IP addresses is referred to as a dynamic address entry.

The following types of IP addresses are supported:

• Single IP. For example : 192.0.2.0

• IP range. For example : 192.0.2.0- 192.0.2.10

• CIDR. For example : 192.0.2.0/24

Each entry occupies one line. Starting in Junos OS Release 19.3R1, IP address ranges do not need to be sorted in ascending order and the value of the IP entries can overlap in the same feed file. In Junos OS Releases before 19.3R1, IP address ranges need to be sorted in ascending order and the value of the IP entries cannot overlap in the same feed file.

The following are the benefits of deploying dynamic address entries in security policies:

• The network administrator has more control over the traffic to and from groups of IP addresses.

• The external server provides updated IP address feeds to the SRX Series Firewall.

• The administrator’s efforts are dramatically reduced. For example, in a legacy security policy configuration, adding 1000 address entries for a policy to reference would require some 2000 lines of configuration. By defining a dynamic address entry and referencing it in a security policy, up to millions of entries could flow into the SRX Series Firewall without much additional configuration effort.

• No commit process is required to add new addresses. Adding thousands of addresses to a configuration through a legacy method takes a long time to commit. Alternatively, IP addresses in a dynamic address entry come from an external feed, so no commit process is required when the addresses in an entry change.

Figure 3 illustrates a functional overview of how the dynamic address entry in a security policy works.

Figure 3: Functional Components of the Dynamic Address Entry in a Security Policy

A security policy references the dynamic address entry in a source address or destination address field (in much the same way that a security policy references a legacy address entry).

Figure 4 illustrates a policy that uses a dynamic address entry in the Destination-address field.

Figure 4: A Dynamic Address Entry in a Security Policy

In Figure 4, Policy 1 uses the destination address 10.10.1.1, which is a legacy security address entry. Policy 2 uses the destination address Vendor blocklist, which is a dynamic address entry named by the network administrator. Its content is the list of IP addresses retrieved from an external feed file. Packets that match all five criteria (the From-zone named untrust, the To-zone named engineer, any source address, a destination IP address that belongs to the Vendor blocklist dynamic address entry, and the mail application) are handled according to the policy actions, which are to deny and log the packet.

Dynamic address groups support the following data feeds:

• Custom lists (allowlists and blocklists)

• GeoIP

• Feed Servers
• Bundle Feeds
• Platform-Specific Policy Configuration Synchronization Behavior
• Platform-Specific Policy Objects Support Behavior
• Platform-Specific Factory-Default Support Behavior
• Platform-Specific IDP Support Behavior
• Platform-Specific Firewall Policy Wizard Support Behavior
• Platform-Specific File Feed Server Support Behavior