Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Configuring Security Policies

 

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. Junos OS allows you to configure security policies. Security policies enforce rules for transit traffic, in terms of what traffic can pass through the firewall, and the actions that need to take place on traffic as it passes through the firewall.

Understanding Security Policy Elements

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.

For SRX300, SRX320, SRX340, SRX345, and SRX550M devices, a factory default security policy is provided that:

  • permits all traffic from the trust zone to the untrust zone.

  • denies all traffic from the untrust zone to the trust zone.

  • allows all traffic from the trust zone to the untrust zone.

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.

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.

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.

Note

If a policy is configured with multiple applications, and more than one of the applications match the traffic, then the application that best meets the match criteria is selected.

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 is added in Junos OS Release 10.2. Support for IPv6 addresses in active/active chassis cluster configurations (in addition to the existing support of active/passive chassis cluster configurations) is 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 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 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 Unified Threat Management (UTM).

Note

Only Intrusion and Prevention (IDP) for IPv6 sessions is supported for all SRX5400, SRX5600, and SRX5800 devices. UTM for IPv6 sessions is not supported. If your current security policy uses rules with the IP address wildcard any, and UTM features are enabled, you will encounter configuration commit errors because UTM features do not yet support IPv6 addresses. To resolve the errors, modify the rule returning the error so that the any-ipv4 wildcard is used; and create separate rules for IPv6 traffic that do not include UTM features.

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.

Understanding Security Policies for Self Traffic

Security policies are configured on the devices to apply services to the traffic flowing through the device. For example UAC and UTM policies are configured to apply services to the transient traffic.

Self-traffic or host traffic, is the host-inbound traffic; that is, the traffic terminating on the device or the host-outbound traffic that is the traffic originating from the device. You can now configure policies to apply services on self traffic. Services like the SSL stack service that must terminate the SSL connection from a remote device and perform some processing on that traffic, IDP services on host-inbound traffic, or IPsec encryption on host-outbound traffic must be applied through the security policies configured on self-traffic.

When you configure a security policy for self-traffic, the traffic flowing through the device is first checked against the policy, then against the host-inbound-traffic option configured for the interfaces bound to the zone.

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.

Note

You can configure the security policy for self-traffic with relevant services only. For example, it is not relevant to configure the fwauth service on host-outbound traffic, and gprs-gtp services are not relevant to the security policies for self-traffic.

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

Note

You can use host-inbound-traffic to control incoming connections to a device; however it does not restrict traffic going out of the device. Whereas, junos-host-zone allows you to select the application of your choice and also restrict outgoing traffic. For example, services like NAT, IDP, UTM, and so forth can now be enabled for traffic going in or out of the SRX Series device using junos-host-zone.

Security Policies Configuration Overview

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

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

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

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

Best Practices for Defining Policies on SRX Series Devices

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.

Table 1 provides the policy limitations for SRX300, SRX320, SRX340, SRX345, SRX550, SRX650, SRX550M, SRX1400, SRX1500, SRX3400, SRX3600, SRX4100, SRX4200, SRX4600, SRX5400, SRX5600, and SRX5800 devices. Platform support depends on the Junos OS release in your installation.

Note

Starting with Junos OS Release 12.3X48-D15 and Junos OS Release 17.3R1, the maximum number of address objects per policy for SRX5400, SRX5600, and SRX5800 devices increases from 1024 to 4096, and the maximum number of policies per context increases from 10240 to 80,000.

Starting with Junos OS Release 17.3R1, the number of security policies and the maximum number of policies per context for SRX5400, SRX5600, and SRX5800 devices increases from 80,000 to 100,000.

Starting with Junos OS Release 15.1X49-D120, the number of address objects per policy for SRX5400, SRX5600, and SRX5800 increases from 4096 to 16,000.

Table 1: Policy Limitations for SRX Series Devices

SRX Series Devices

Address objects

Application objects

Security policies

Policy contexts (zone pairs)

Policies per context

Policies with counting enabled

SRX300

SRX320

2048

128

1024

256

1024

256

SRX340

2048

128

2048

512

2048

256

SRX345

2048

128

4096

1024

4096

256

SRX550

SRX650

1024

128

10240

2048

10240

1024

SRX550M

2048

128

10240

2048

10240

1024

SRX1400

SRX1500

1024

3072

16000

4096

16000

1024

SRX3400

SRX3600

4096

3072

40000

4096

40000

1024

SRX4100

1024

3072

60000

4096

60000

1024

SRX4200

1024

3072

60000

4096

60000

1024

SRX4600

4096

3072

80000

8192

80000

1024

SRX5400

SRX5600

SRX5800

16000

3072

100000

8192

100000

1024

Therefore, 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 device 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.

Configuring Policies Using the Firewall Wizard

The Firewall Policy Wizard enables you to perform basic security policy configuration on SRX300, SRX320, SRX340, SRX345, and SRX550M devices.. For more advanced configuration, use the J-Web interface or the CLI.

To configure policies using the Firewall Policy Wizard:

  1. Select Configure>Tasks>Configure FW Policy in the J-Web interface.
  2. Click the Launch Firewall Policy Wizard button to launch the wizard.
  3. Follow the prompts in the wizard.

The upper-left area of the wizard page shows where you are in the configuration process. The lower-left area of the page shows field-sensitive help. When you click a link under the Resources heading, the document opens in your browser. If the document opens in a new tab, be sure to close only the tab (not the browser window) when you close the document.

Example: Configuring a Security Policy to Permit or Deny All Traffic

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

Requirements

Before you begin:

Overview

In the Junos OS, security policies enforce rules for transit traffic, in terms of what traffic can pass through the device, and the actions that need to take place on traffic as it passes through the device. From the perspective of security policies, the traffic enters one security zone and exits another security zone. In this example, you configure the trust and untrust interfaces, ge-0/0/2 and ge-0/0/1. See Figure 1.

Figure 1: Permitting All Traffic
Permitting All Traffic

This configuration example shows how to:

  • Permit or deny all traffic from the trust zone to the untrust zone but block everything from the untrust zone to the trust zone.

  • Permit or deny selected traffic from a host in the trust zone to a server in the untrust zone at a particular time.

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User guide.

To configure a security policy to permit or deny all traffic:

  1. Configure the interfaces and security zones.
  2. Create the security policy to permit traffic from the trust zone to the untrust zone.
  3. Create the security policy to deny traffic from the untrust zone to the trust zone.

Results

From configuration mode, confirm your configuration by entering the show security policies and show security zones commands. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

Note

The configuration example is a default permit-all from the trust zone to the untrust zone.

If you are done configuring the device, enter commit from configuration mode.

Verification

Verifying Policy Configuration

Purpose

Verify information about security policies.

Action

From operational mode, enter the show security policies detail command to display a summary of all security policies configured on the device.

Meaning

The output displays information about policies configured on the system. Verify the following information:

  • From and to zones

  • Source and destination addresses

  • Match criteria

Example: Configuring a Security Policy to Permit or Deny Selected Traffic

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

Requirements

Before you begin:

Overview

In Junos OS, security policies enforce rules for the transit traffic, in terms of what traffic can pass through the device, and the actions that need to take place on the traffic as it passes through the device. From the perspective of security policies, the traffic enters one security zone and exits another security zone. In this example, you configure a specific security policy to allow only e-mail traffic from a host in the trust zone to a server in the untrust zone. No other traffic is allowed. See Figure 2.

Figure 2: Permitting Selected Traffic
Permitting Selected Traffic

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User guide.

To configure a security policy to allow selected traffic:

  1. Configure the interfaces and security zones.
  2. Create address book entries for both the client and the server. Also, attach security zones to the address books.
  3. Define the policy to permit mail traffic.

Results

From configuration mode, confirm your configuration by entering the show security policies and show security zones commands. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

If you are done configuring the device, enter commit from configuration mode.

Verification

Verifying Policy Configuration

Purpose

Verify information about security policies.

Action

From operational mode, enter the show security policies detail command to display a summary of all security policies configured on the device.

Meaning

The output displays information about policies configured on the system. Verify the following information:

  • From and to zones

  • Source and destination addresses

  • Match criteria

Example: Configuring a Security Policy to Permit or Deny Wildcard Address Traffic

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

Requirements

Before you begin:

Overview

In the Junos operating system (Junos OS), security policies enforce rules for the transit traffic, in terms of what traffic can pass through the device, and the actions that need to take place on the traffic as it passes through the device. From the perspective of security policies, the traffic enters one security zone and exits another security zone. In this example, you configure a specific security to allow only wildcard address traffic from a host in the trust zone to the untrust zone. No other traffic is allowed.

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit in configuration mode.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User guide.

To configure a security policy to allow selected traffic:

  1. Configure the interfaces and security zones.
  2. Create an address book entry for the host and attach the address book to a zone.
  3. Define the policy to permit wildcard address traffic.

Results

From configuration mode, confirm your configuration by entering the show security policies and show security zones commands. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

If you are done configuring the device, enter commit from configuration mode.

Verification

Verifying Policy Configuration

Purpose

Verify information about security policies.

Action

From operational mode, enter the show security policies policy-name permit-wildcard detail command to display details about the permit-wildcard security policy configured on the device.

Meaning

The output displays information about the permit-wildcard policy configured on the system. Verify the following information:

  • From and To zones

  • Source and destination addresses

  • Match criteria

Example: Configuring a Security Policy to Redirect Traffic Logs to an External System Log Server

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

Requirements

This example uses the following hardware and software components:

  • A client connected to an SRX5600 device at the interface ge-4/0/5

  • A server connected to the SRX5600 device at the interface ge-4/0/1

    The logs generated on the SRX5600 device are stored in a Linux-based system log server.

  • An SRX5600 device connected to the Linux-based server at interface ge-4/0/4

No special configuration beyond device initialization is required before configuring this feature.

Overview

In this example, you configure a security policy on the SRX5600 device to send traffic logs, generated by the device during data transmission, to a Linux-based server. Traffic logs record details of every session. The logs are generated during session establishment and termination between the source and the destination device that are connected to the SRX5600 device.

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit in configuration mode.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User guide.

To configure a security policy to send traffic logs to an external system log server:

  1. Configure security logs to transfer traffic logs generated at the SRX5600 device to an external system log server with the IP address 203.0.113.2. The IP address 127.0.0.1 is the loopback address of the SRX5600 device.
  2. Configure a security zone and specify the types of traffic and protocols that are allowed on interface ge-4/0/5.0 of the SRX5600 device.
  3. Configure another security zone and specify the types of traffic that are allowed on the interfaces ge-4/0/4.0 and ge-4/0/1.0 of the SRX5600 device.
  4. Create a policy and specify the match criteria for that policy. The match criteria specifies that the device can allow traffic from any source, to any destination, and on any application.
  5. Enable the policy to log traffic details at the beginning and at the end of the session.

Results

From configuration mode, confirm your configuration by entering the show security log command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

If you are done configuring the device, enter commit from the configuration mode.

Verification

Confirm that the configuration is working properly.

Verifying Zones

Purpose

Verify that the security zone is enabled or not.

Action

From operational mode, enter the show security zones command.

Verifying Policies

Purpose

Verify that the policy is working.

Action

From operational mode, enter the show security policies command on all the devices.

TAP Mode for Security Zones and Policies

The Terminal Access Point (TAP) mode for security zones and policy allows you to passively monitor traffic flows across a network by way of a switch SPAN or mirror port.

Understanding TAP Mode Support for Security Zones and Policies

The Terminal Access Point (TAP) mode is a standby device, which checks the mirrored traffic through switch. If security zones and policies are configured, then the TAP mode inspects the incoming and outgoing traffic by configuring the TAP interface and generating a security log report to display the number of threats detected and the user usage. If some packet gets lost in the tap interface, the security zones and policies terminates the connection, as a result no report generates for this connection. The security zone and policy configuration remains the same as non-TAP mode.

When you configure an SRX Series device to operate in TAP mode, the device generates security log information to display the information on threats detected, application usage, and user details. When the device is configured to operate in TAP mode, the SRX Series device receives packets only from the configured TAP interface. Except the configured TAP interface, other interface are configured to normal interface that is used as management interface or connected to the outside server. The SRX Series device will generate security report or log according to the incoming traffic.

The security zone and default security policy will be configured after TAP interface is configured. You can configure other zones or policies if required. If one interface is used to connect a server then the IP address, routing-interface, and security configuration also need be configured.

Note

You can configure only one TAP interface when you operate the device in TAP mode.

Example: Configuring Security Zones and Policies in TAP mode

This example shows how to configure security zones, and policies when the SRX device is configured in TAP (Terminal Access Point) mode.

Requirements

This example uses the following hardware and software components:

  • An SRX Series device

  • Junos OS Release 19.1R1

Before you begin:

Overview

In this example, you configure the SRX Series device to operate in TAP mode. When you configure the SRX Series device to operate in TAP mode, the device generates security log information to display the information on threats detected, application usage, and user details.

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide.

To configure zones in TAP mode:

  1. Configure security zone tap-zone interface.
  2. Configure security zone tap-zone application-tracking.
  3. Configure security policy that permits traffic from zone tap-zone to zone tap-zone policy tap and configure the match condition.

Results

From configuration mode, confirm your configuration by entering the show security zones and show security policies commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

If you are done configuring the device, enter commit from configuration mode.

Verification

To confirm that the configuration is working properly, perform these tasks:

Verifying Policy Configuration in TAP Mode

Purpose

Verify information about security policies.

Action

From operational mode, enter the show security policies detail command.

user@host> show security policies detail

Meaning

Displays a summary of all security policies configured on the device in TAP mode.

Dynamic Address Groups in Security Policies

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 blacklist) 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.

Note

A dynamic address entry is a group of IP addresses, not a single IP prefix. A dynamic address entry is different from the security address concepts of address books and address entry addresses.

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

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

Note

The dynamic address entry names share the same name space as legacy security address entries, so do not use the same name for more than one entry. The Junos OS commit process checks that names are not duplicated to avoid a conflict.

Dynamic address groups support the following data feeds:

  • Custom lists (whitelists and blacklists)

  • GeoIP

  • Feed Servers

Bundle Feeds

IP addresses, IP prefixes or IP ranges contained in a dynamic address entry can be updated periodically by downloading an external feed. SRX Series devices periodically initiate a connection to the feed server to download and update the IP lists which contain the updated dynamic addresses.

Starting in Junos OS Release 19.3R1, you can download a single tgz file from server and extract it into multiple children feed files. Each individual file corresponds to one feed. Let individual dynamic-addresses reference the feed inside the bundle file. The bundle file reduces the CPU overhead when too many feeds are configured, where multiple child feeds are compressed into one .tgz file

The following bundle feed modes are supported:

Archive Mode

In the archive mode, you need to compress all feed files for the SRX Series device into one tgz file. The SRX Series device downloads this file and extract all the feeds after extraction. This process is explained below:

  • When the feed server's url is a url of a file with the suffix .tgz instead of original url of folder, this means this server uses a single file to carry all its feeds for SRX Series dynamic-address deployment. In this case, feeds under this server inherit the update-interval or hold-interval from the server. Any user configuration of the update-interval or hold-interval for this feed is ignored.

  • After this change, follow the steps below to maintain server feeds as below example.

    The example below shows the steps required to maintain the server feeds:

    1. Place all feed files for the SRX Series device under the folder feeds-4-srx
    2. Generate all feed files fd1 fd2 fd3 ..fdN in the folder feeds-4-srx
    3. Add or remove the IP ranges from the feeds
    4. Access the files by running the following command: cd feeds-4-srx;tar -zcvf ../feeds-4-srx.tgz *;cd-
  • Post Step 4, the file feeds-4-srx.tgz is ready for download on the SRX Series device containing the same folder which contains the feeds-4-srx.tgz file. After the download, the extracted files are placed in the same folder as feeds-4-srx.tgz. The following example shows a samle configuration on an SRX Series device:

    [edit]
    set security dynamic-address feed-server server-4-srx url 10.170.40.50/feeds-4-srx.tgz
    set security dynamic-address feed-server server-4-srx feed-name feed1 path fd1
    set security dynamic-address feed-server server-4-srx feed-name feed2 path.fd2
    set security dynamic-address feed-server server-4-srx feed-name feed3 path fdN

The path parameter requires the relative path of the feed inside the bundle archive.

  • If the tar -zxf feeds-4-srx.tgz file generates a folder feeds-4-srx and this folder holds the feed file fd1, then use the following command to configure the feed:

    [edit]
    set security dynamic-address feed-server server-4-srx feed fd1 path feeds-4-srx/fd1
  • If the tar -zxf feeds-4-srx.tgz file extracts the file fd1 directly, then use the following command to configure the feed:

    [edit]
    set security dynamic-address feed-server server-4-srx feed fd1 path fd1

Flat File Mode

Flat file mode offers ultimate simplicity for user by introducing one syntax change in existing feed file format. The content of all the feed files are compiled into a single file, with .bundle as a suffix. This allows you to manage a single file. The SRX Series device classifies IP ranges in this bundle file into numerous feed files. You can gzip this file as .bundle.gz if you can save some bandwidth for transmission. In addition to file format defined earlier, an upper case tag FEED: followed by the feed name is introduced. The lines below this tag are regarded as IP ranges belonging to the feed. An example of the file format looks is given below:

root>cat feeds-4-srx.bundle
FEED:fd1
12.1.1.1-12.1.1.2
11.1.1.1-11.1.1.2
FEED:fd2
14.1.1.1-14.1.1.2

The configuration on an SRX Series device is similar to archive mode and is given below:

[edit]
set security dynamic-address feed-server server-4-srx url 10.170.40.50/feeds-4-srx.bundle
set security dynamic-address feed-server server-4-srx feed-name fd1 path fd1
set security dynamic-address feed-server server-4-srx feed-name fd2 path fd2

The difference between flat mode and archive mode is the file’s suffix and the layout inside the file. You can select the mode that is most convenient for you.

As the feed files are in the plaintext format, gzip can reduce the file size. If a server and an SRX Series device has WAN link in between, use a smaller sized file to be transmitted on the network, in this case, gzip the bundle file and configure the following commands:

[edit]
set security dynamic-address feed-server server-4-srx url 10.170.40.50/feeds-4-srx.bundle.gz
set security dynamic-address feed-server server-4-srx feed-name fd1 path fd1
set security dynamic-address feed-server server-4-srx feed-name fd2 path fd2

Feed Server Support for SRX Series Devices

Table 2:

Platform

Maximum Number of Feed Servers

Maximum Number of Feeds

Maximum Number of Dynamic Addresses entries

SRX300

SRX320

SRX340

SRX345

SRX550

SRX550M

SRX650

10

500

500

SRX4100

SRX4200

SRX4600

SRX5400

SRX5600

SRX5800

vSRX

vSRX 3.0

100

5000

5000

SRX1500

40

2000

2000

Release History Table
Release
Description
Starting with Junos OS Release 17.3R1, the number of security policies and the maximum number of policies per context for SRX5400, SRX5600, and SRX5800 devices increases from 80,000 to 100,000.
Starting with Junos OS Release 15.1X49-D120, the number of address objects per policy for SRX5400, SRX5600, and SRX5800 increases from 4096 to 16,000.
Starting with Junos OS Release 12.3X48-D15 and Junos OS Release 17.3R1, the maximum number of address objects per policy for SRX5400, SRX5600, and SRX5800 devices increases from 1024 to 4096, and the maximum number of policies per context increases from 10240 to 80,000.
Support for IPv6 addresses in active/active chassis cluster configurations (in addition to the existing support of active/passive chassis cluster configurations) is added in Junos OS Release 10.4.
Support for IPv6 addresses is added in Junos OS Release 10.2.