Screens Options for Attack Detection and Prevention

 

Attack detection and prevention detects and defend the network against attacks. Using Screen options, Junos security platforms can protect against different internal and external attacks, For more information, see the following topics:

Understanding Screens Options on SRX Series Devices

On all SRX Series devices, the screens are divided into two categories:

  • Statistics-based screens

  • Signature-based screens

Statistics-based screens

Table 1 lists all the statistics-based screen options.

Table 1: Statistics-Based Screen Options

Screen Option Name

Description

ICMP flood

Use the ICMP flood IDS option to protect against ICMP flood attacks. An ICMP flood attack typically occurs when ICMP echo requests use all resources in responding, such that valid network traffic can no longer be processed.

The threshold value defines the number of ICMP packets per second (pps) allowed to ping the same destination address before the device rejects further ICMP packets.

UDP flood

Use the UDP flood IDS option to protect against UDP flood attacks. A UDP flood attack occurs when an attacker sends IP packets containing a UDP datagram with the purpose of slowing down the resources, such that valid connections can no longer be handled.

The threshold value defines the number of UDP packets per second allowed to ping the same destination IP address. When the number of packets exceeds this value within any 1-second period, the device generates an alarm and drops subsequent packets for the remainder of that second.

TCP SYN flood source

Use the TCP SYN flood source IDS option to set the source threshold value. The threshold value defines the number of SYN segments to be received per second before the device begins dropping connection requests.

The applicable range is 4 through 500,000 SYN pps.

TCP SYN flood destination

Use the SYN flood destination IDS option to set the destination threshold value. The threshold value defines the number of SYN segments received per second before the device begins dropping connection requests.

The applicable range is 4 through 500,000 SYN pps.

TCP SYN flood

Use the TCP SYN flood IDS option to detect and prevent SYN flood attacks. Such attacks occur when the connecting host continuously sends TCP SYN requests without replying to the corresponding ACK responses.

TCP port scan

Use the TCP port scan IDS option to prevent the port scan attacks. The purpose of this attack is to scan the available services in the hopes that at least one port will respond, thus identifying a service to target.

TCP SYN-ACK-ACK proxy

Use the TCP SYN-ACK-ACK proxy screen option to prevent SYN-ACK-ACK attack. After the number of connections from the same IP address reaches the SYN-ACK-ACK proxy threshold, SRX Series devices running Junos OS reject further connection requests from that IP address.

ICMP IP sweep

Use the ICMP IP sweep IDS option to detect and prevent an IP sweep attack. An IP sweep attack occurs when an attacker sends ICMP echo requests (pings) to multiple destination addresses. If a target host replies, the reply reveals the target’s IP address to the attacker. If the device receives 10 ICMP echo requests within the number of microseconds specified in this statement, it flags this as an IP sweep attack, and rejects the eleventh and all further ICMP packets from that host for the remainder of the second.

The threshold value defines the maximum number of microseconds during which up to 10 ICMP echo requests from the same host are allowed into the device.

TCP SYN flood alarm

Use the TCP SYN flood alarm IDS option to set the alarm threshold value. The threshold value defines the number of half-complete proxy connections per second at which the device makes entries in the event alarm log. The range is 1 through 500,000 requests per second.

TCP SYN flood attack

Use the TCP SYN flood attack IDS option to set the attack threshold value. The threshold value defines the number of SYN packets per second required to trigger the SYN proxy response. The range is 1 through 500,000 proxied pps.

UDP udp sweep

Use the UDP udp sweep IDS option to detect and prevent UDP sweep attacks. In a UDP sweep attack, an attacker sends UDP packets to the target device. If the device responds to those packets, the attacker gets an indication that a port in the target device is open, which makes the port vulnerable to attack. If a remote host sends UDP packets to 10 addresses in 0.005 seconds (5000 microseconds), then the device flags this as a UDP sweep attack.

If the alarm-without-drop option is not set, the device rejects the eleventh and all further UDP packets from that host for the remainder of the specified threshold period.

The threshold value defines the number of microseconds for which the device accepts 10 UDP packets from the same remote source to different destination addresses.

Starting with Junos OS Release 15.1X49-D20 and Junos OS Release 17.3R1, the firewall generates only one log message every second irrespective of the number of packets that trigger the source or destination session limit. This behavior applies to flood protection screens with TCP-Synflood-src-based, TCP-Synflood-dst-based, and UDP flood protection.

Signature-based screens

Table 2 lists all the signature-based screen options.

Table 2: Signature-Based Screen Options

Screen Option Name

Description

TCP Winnuke

Enable or disable the TCP WinNuke attacks IDS option. WinNuke is a denial-of-service (DoS) attack targeting any computer on the Internet running Windows.

TCP SYN fragment

Use the TCP SYN fragment attack IDS option to drop any packet fragments used for the attack. A SYN fragment attack floods the target host with SYN packet fragments. The host caches these fragments, waiting for the remaining fragments to arrive so it can reassemble them. The flood of connections that cannot be completed eventually fills the host’s memory buffer. No further connections are possible, and damage to the host’s operating system can occur.

TCP no flag

Use the TCP tcp no flag IDS option to drop illegal TCP packets with a missing or malformed flag field. The threshold value defines the number of TCP headers without flags set. A normal TCP segment header has at least one control flag set.

TCP SYN FIN

Use the TCP SYN FIN IDS option to detect an illegal combination of flags that attackers can use to consume sessions on the target device, thus resulting in a denial-of-service (DoS) condition.

TCP land

Enable or disable the TCP land attack IDS option. Land attacks occur when an attacker sends spoofed SYN packets containing the IP address of the victim as both the destination and the source IP address.

TCP FIN no ACK

Use the FIN bit with no ACK bit IDS option to detect an illegal combination of flags, and reject packets that have this combination.

ICMP ping of death

Use the ping of death IDS option to detect and reject oversized and irregular ICMP packets. Although the TCP/IP specification requires a specific packet size, many ping implementations allow larger packet sizes. Larger packets can trigger a range of adverse system reactions, including crashing, freezing, and restarting.

Ping of death occurs when IP packets are sent that exceed the maximum legal length (65,535 bytes).

ICMP fragment

Use the ICMP fragment IDS option to detect and drop any ICMP frame with the More Fragments flag set or with an offset indicated in the offset field.

ICMP large

Use the ICMP large IDS option to detect and drop any ICMP frame with an IP length greater than 1024 bytes.

IP unknown protocol

Use the IP unknown protocol IDS option to discard all received IP frames with protocol numbers greater than 137 for IPv4 and 139 for IPv6. Such protocol numbers are undefined or reserved.

IP bad option

Use the IP bad IDS option to detect and drop any packet with an incorrectly formatted IP option in the IP packet header. The device records the event in the screen counters list for the ingress interface. This screen option is applicable to IPv4 and IPv6.

IP strict source route option

Use the IP strict source route IDS option to detect packets where the IP option is 9 (strict source routing), and record the event in the screen counters list for the ingress interface. This option specifies the complete route list for a packet to take on its journey from source to destination. The last address in the list replaces the address in the destination field. Currently, this screen option is applicable only to IPv4.

IP loose source route option

Use the IP loose source route IDS option to detect packets where the IP option is 3 (loose source routing), and record the event in the screen counters list for the ingress interface. This option specifies a partial route list for a packet to take on its journey from source to destination. The packet must proceed in the order of addresses specified, but it is allowed to pass through other devices in between those specified. The type 0 routing header of the loose source route option is the only related header defined in IPv6.

IP source route option

Use the IP source route IDS option to detect packets and record the event in the screen counters list for the ingress interface.

IP stream option

Use the IP stream IDS option to detect packets where the IP option is 8 (stream ID), and record the event in the screen counters list for the ingress interface. This option provides a way for the 16-bit SATNET stream identifier to be carried through networks that do not support streams. Currently, this screen option is applicable only to IPv4.

IP block fragment

Enable or disable the IP packet fragmentation blocking. When this feature is enabled, Junos OS denies IP fragments on a security zone and blocks all IP packet fragments that are received at interfaces bound to that zone.

IP record route option

Use the IP record route IDS option to detect packets where the IP option is 7 (record route), and record the event in the screen counters list for the ingress interface. This option records the IP addresses of the network devices along the path that the IP packet travels. Currently, this screen option is applicable only to IPv4.

IP timestamp option

Use the IP timestamp IDS option to detect packets where the IP option list includes option 4 (Internet timestamp), and record the event in the screen counters list for the ingress interface. This option records the time (in Universal Time) when each network device receives the packet during its trip from the point of origin to its destination. Currently, this screen option is applicable only to IPv4.

IP security option

Use the IP security IDS option to detect packets where the IP option is 2 (security), and record the event in the screen counters list for the ingress interface. Currently, this screen option is applicable only to IPv4.

IP spoofing

Use the IP address spoofing IDS option to prevent spoofing attacks. IP spoofing occurs when an invalid source address is inserted in the packet header to make the packet appear to come from a trusted source.

IP tear drop

Use the IP tear drop IDS option to block teardrop attacks. Teardrop attacks occur when fragmented IP packets overlap and cause the host attempting to reassemble the packets to crash. The tear drop option directs the device to drop any packets that have such a discrepancy. Teardrop attacks exploit the reassembly of fragmented IP packets.

Understanding Central Point Architecture Enhancements for Screens

Starting with Junos OS Release 15.1X49-D30 and Junos OS Release 17.3R1, on SRX5400, SRX5600, and SRX5800 devices, the central point architecture is enhanced to achieve a higher number of connections per second (CPS). Due to the enhancements, the central point session and central point packet processing have been moved from the central point to the Services Processing Unit (SPU).

Previously, the central point had a session limit and if no resources (session limit entries) were available, then the packet was always permitted by the session limit. Now, both the central point and the SPU have session limits. If there are no resources available in the central point, but resources are available in the SPU, then the central point cannot limit the sessions but the SPU can limit the sessions. So, the SPU drops the packet SPU session limit checking and only if both the central point and the SPU have no resources will the packet always be permitted.

The following scenarios describe when the central point and the SPU determine whether to permit or drop a packet.

  • When the central point has no session limit entry and the SPU has a session limit entry:

    1. If the session limit counter of the SPU is larger than the threshold value, the packet is dropped.

    2. If the session limit counter of the SPU is not larger than the threshold value, the packet is permitted.

  • When the SPU does not have a session limit entry:

    1. If the session limit counter of the SPU is larger than the threshold value, the packet is permitted.

    2. If the session limit counter of the SPU is not larger than ththreshold, the packet is permitted.

Note

An extra message is sent to the central point to maintain accurate session counts might impact the number of connections per second (CPS) for screens. This impacts the source or destination session limit.

Global traffic statistics lacking a central point might impact some global view screens. Only the SYN cookie has no global view, and the global traffic statistics are handled by the SPU, so the counter might be not accurate as before. For other statistics-based screens, handled by both the central point and the SPU, the counters are accurate.

Previously, statistics-based screens were handled only by the central point and the log and the SNMP trap could be rate-limited strictly. Now both the central point and the SPU can generate the log and the SNMP trap independently. Therefore, the log and the SNMP trap might be larger than before.

Example: Configuring Multiple Screening Options

This example shows how to create one intrusion detection service (IDS) profile for multiple screening options.

Requirements

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

Overview

In a security zone, you can apply one IDS profile to multiple screening options. In this example we are configuring the following screening options:

  • ICMP screening

  • IP screening

  • TCP screening

  • UDP screening

These screening options are assigned to an untrust zone.

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.

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 an IDS profile for multiple screening options:

  1. Configure the ICMP screening options.
  2. Configure the IP screening options.
  3. Configure the TCP screening options.
  4. Configure the UDP screening options.
  5. Attach the IDS profile to the zone.

Results

From configuration mode, confirm your configuration by entering the show security screen ids-option screen-config 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 the IDS Profile for Multiple Screening Options

Purpose

Verify that the IDS profile for multiple screening options is configured properly.

Action

Enter the show security screen ids-option screen-config Screen object status and show security zones command from operational mode.

Note

On all SRX Series devices, the TCP synchronization flood alarm threshold value does not indicate the number of packets dropped, however the value does show the packet information after the alarm threshold has been reached.

The synchronization cookie or proxy never drops packets; therefore the alarm-without-drop (not drop) action is shown in the system log.

Understanding Screen Options on the SRX5000 Module Port Concentrator

The SRX5000 line Module Port Concentrator (SRX5K-MPC) supports Junos OS screen options. Screen options secure a zone by inspecting, then allowing or denying, all connection attempts that require crossing an interface bound to that zone.

Using screen options, your security device can protect against different internal and external attacks, including SYN flood attacks, UDP flood attacks, and port scan attacks. Junos OS applies screen checks to traffic prior to the security policy processing, resulting in less resource utilization.

The screen options are divided into the following two categories:

  • Statistics-based screens

  • Signature-based screens

Statistics-Based Screens

All screen features implemented on an SRX5K-MPC are independent of Layer 2 or Layer 3 mode. The flood protections are used to defend against SYN flood attacks, session table flood attacks, firewall denial-of-service (DoS) attacks, and network DoS attacks.

The following four types of threshold-based flood protection are performed on each processor for both IPv4 and IPv6:

  • UDP-based flood protection

  • ICMP-based flood protection

  • TCP source-based SYN flood protection

  • TCP destination-based SYN flood protection

Note

If one of the two types of TCP SYN flood protections is configured on a zone, the second type of TCP SYN flood protection is automatically enabled on the same zone. These two types of protections always work together.

Each type of flood protection is threshold-based, and the threshold is calculated per zone on each microprocessor. If the flood is detected on a microprocessor chip, that particular microprocessor takes action against the offending packets based on the configuration:

  • Default action (report and drop)—Screen logging and reporting are done on an SPU, so offending packets need to be forwarded to the central point or SPU for this purpose. To protect SPUs from flooding, only the first offending packet for each screen in a zone is sent to the SPU for logging and reporting in each second. The rest of the offending packets are counted and dropped in a microprocessor.

    For example, assume UDP flooding is configured at a logical interface with a threshold set to 5000 packets per second. If UDP packets come in at the rate of 20,000 per second, then about 5000 UDP packets are forwarded to the central point or SPU each second, and the remaining packets are detected as flooding. However, only one UDP flooding packet is sent to the SPU for logging and reporting in each second. The remaining packets are dropped in the microprocessor.

  • Alarm only (alarm-without-drop)—An offending packet detected by screen protection is not dropped. It skips the rest of the screen checks and is forwarded to the central point or SPU with the screen result copied to its meta-header. It is not counted as a dropped packet.

Differences Between IOC1 and IOC2

The behavior of screens is the same whether the device has either IOC1 or an IOC2 card. However, there are differences in the threshold values for the statistics-based screens. Table 3 lists the statistics-based screen options and the behavior of the screens depending on whether the device has either IOC1 or an IOC2 card.

Table 3: Statistics-Based Screen Options

Screen Option Name

Description

IOC1

IOC2

ICMP flood

Sets the ICMP flood threshold value. The ICMP flood screen option is used to protect against ICMP flood attacks. An ICMP flood attack typically occurs when ICMP echo requests use all resources in responding, such that valid network traffic can no longer be processed.

The threshold value defines the number of ICMP packets per second allowed to ping the same destination address before the device rejects further ICMP packets.

If the Incoming traffic exceeds the threshold pps, either the packets are dropped or an alarm is raised.

On SRX5000 line devices with IOC2 card, there is a change in the screen configuration for lookup (LU) chips. There are four LU chips in each IOC2 card. If the incoming traffic exceeds the threshold value pps, the packets are dropped. For example, if the user specify the threshold value of 1000 pps, we configure 250 pps on each LU chip internally, so that the threshold value of 1000 pps gets distributed equally among the 4 LU chips. As an expected result, the user gets the overall threshold value of 1000 pps.

On SRX5000 line devices, when the IOC2 card is in services-offload mode, only one LU chip will function. If the incoming traffic rate exceeds the threshold value, the packets are dropped as a result of the expected behavior.

UDP flood

Sets the UDP flood threshold value. The UDP flood screen option is used to protect against UDP flood attacks. UDP flood attack occurs when an attacker sends IP packets containing UDP datagrams with the purpose of slowing down the resources, such that valid connections can no longer be handled.

The threshold value defines the number of UDP pps allowed to ping the same destination IP address/port pair. When the number of packets exceeds this value within any 1-second period, the device generates an alarm and drops subsequent packets for the remainder of that second.

If the Incoming traffic exceeds the threshold pps, either the packets are dropped or an alarm is raised.

On SRX5000 line devices with IOC2 card, there is a change in the screen configuration for lookup (LU) chips. There are four LU chips in each IOC2 card. If the incoming traffic exceeds the threshold value pps, the packets are dropped. For example, if the user specify the threshold value of 1000 pps, we configure 250 pps on each LU chip internally, so that the threshold value of 1000 pps gets distributed equally among the 4 LU chips. As an expected result, the user gets the overall threshold value of 1000 pps.

On SRX5000 line devices, when the IOC2 card is in services-offload mode, only one LU chip will function. If the incoming traffic rate exceeds the threshold value, the packets are dropped as a result of the expected behavior.

TCP SYN flood source

Sets the TCP SYN flood source threshold value. The threshold value defines the number of SYN segments to be received per second before the device begins dropping connection requests.

The applicable range is 4 through 500,000 SYN pps.

If the Incoming traffic exceeds the threshold pps, either the packets are dropped or an alarm is raised..

On SRX5000 line devices with IOC2 card, there is a change in the screen configuration for lookup (LU) chips. There are four LU chips in each IOC2 card. If the incoming traffic exceeds the threshold value pps, the packets are dropped. For example, if the user specify the threshold value of 1000 pps, we configure 250 pps on each LU chip internally, so that the threshold value of 1000 pps gets distributed equally among the 4 LU chips. As an expected result, the user gets the overall threshold value of 1000 pps.

On SRX5000 line devices, when the IOC2 card is in services-offload mode, only one LU chip will function. If the incoming traffic rate exceeds the threshold value, the packets are dropped as a result of the expected behavior.

TCP SYN flood destination

Sets the TCP SYN flood destination threshold value. The threshold value defines the number of SYN segments received per second before the device begins dropping connection requests.

The applicable range is 4 through 500,000 SYN pps.

If the Incoming traffic exceeds the threshold pps, either the packets are dropped or an alarm is raised.

On SRX5000 line devices with IOC2 card, there is a change in the screen configuration for lookup (LU) chips. There are four LU chips in each IOC2 card. If the incoming traffic exceeds the threshold value pps, the packets are dropped. For example, if the user specify the threshold value of 1000 pps, we configure 250 pps on each LU chip internally, so that the threshold value of 1000 pps gets distributed equally among the 4 LU chips. As an expected result, the user gets the overall threshold value of 1000 pps.

On SRX5000 line devices, when the IOC2 card is in services-offload mode, only one LU chip will function. If the incoming traffic rate exceeds the threshold value, the packets are dropped as a result of the expected behavior.

Note

On SRX5400, SRX5600, and SRX5800 line devices, the screen threshold value is set for each IOC in the DUT for the LAG/LACP and RLAG/RETH child links. When you have cross-IOC child interfaces as a part of LAG/LACP or RETH/RLAG interfaces and the ingress traffic is also traversing multiple child links across IOCs, set the threshold value to match the total number of packets passed by the screen from multiple IOCs with the expected total number of packets per second (pps) at the egress interface.

Signature-Based Screens

The SRX5K-MPC provides signature-based screen options along with sanity checks on the received packet.

Sometimes packets received by the device are malformed or invalid, and they might cause damage to the device and network. These packets must be dropped during initial stages of processing.

For both signature-based screen options and sanity checks, the packet contents, including packet header, status and control bits, and extension headers (for IPv6), are examined. You can configure the screens according to your requirements, whereas packet sanity checks are performed by default.

The packet sanity checks and screen options are performed on packets received on ingress interfaces.

The processor does sanity checks and runs some screen features to detect the malformed and malicious ingress packets received from physical interfaces. Packets that fail a sanity check are counted and dropped.

The following packet sanity checks are supported:

  • IPv4 sanity check

  • IPv6 sanity check

The following screen features are supported:

  • IP-based screen

  • UDP-based screen

  • TCP-based screen

  • ICMP-based screen

The screen features are applicable to both IPv4 and IPv6 packets, with the exception of IP options screens, which only apply to IPv4 packets. If a packet is detected by one screen option, it skips the rest of the screen checks and is forwarded to the central point or Services Processing Unit (SPU) for logging and statistics collection.

Note

On SRX5400, SRX5600, and SRX5800 devices, the first path signature screen is performed first, followed by the fast path bad-inner-header screen.

Understanding IPv6 Support for Screens

Juniper Networks provides various detection and defense mechanisms at the zone and policy levels to combat exploits at all stages of their execution. Screen options are at the zone level. Junos OS screen options secure a zone by inspecting it, and then allowing or denying all connection attempts that require crossing an interface bound to that zone.

You can configure screen options to check and filter packets based on IPv6 extension headers, packet headers, and ICMPv6 traffic. Based on your configuration, the screen can drop packets, create logs, and provide increased statistics for IPv6 traffic.

IPv6 Extension Header Checking and Filtering

You can use the ipv6-extension-header statement to selectively screen one or more extension headers. Table 4 lists common IPv6 extension headers and their type values.

Table 4: IPv6 Extension Headers and Type Values

Header Name

Header Type Value

Internet Standards

Authentication

51

RFC 2460

Encapsulating Security Payload

50

RFC 2460

Host Identify Protocol

139

RFC 5201

Destination Options

  • ILNP nonce option

  • Home address option

  • Line identification option

  • Tunnel encapsulation limit option

60

RFC 2460

Fragment

44

RFC 2460

Hop-by-Hop Options

  • CALIPSO option

  • RPL option

  • SFM DPD option

  • Jumbo payload option

  • Quick start option

  • Router alert option

0

RFC 2460

Mobility

135

RFC 6275

No next

59

RFC 2460

Routing

43

RFC 2460

Shim6

140

RFC 5533

Maximum Number of Extension Headers

You can specify the maximum number of permitted extension headers in a packet by using the ipv6-extension-header-limit statement. Although the maximum number of extension headers in a packet is not explicitly specified, the order of extension headers is recommended in RFC 2460:

  1. Hop-by-Hop Options header
  2. Destination Options header
  3. Routing header
  4. Fragment extension header
  5. Authentication header
  6. Encapsulating Security Payload header
  7. Destination Options header

Each extension header should occur at most once, except for the destination options header, which should occur at most twice (once before a routing header and once before the upper-layer protocol header).

The maximum extension header number based on RFC 2460 is 7. Other extension headers have been defined by subsequent RFCs. We recommend the maximum extension header number to be in the range of 0 through 32.

Bad Option Extension Headers

You can configure screens to detect and drop any packet with an incorrectly formatted IP option in the IP packet header (IPv4 or IPv6). The device records the event in the screen counters list for the ingress interface. Table 5 lists key criteria that the device uses to screen packets for bad options.

Table 5: Bad Option Extension Header Screening Criteria

Screening Criteria

Internet Standards

Description

Routing extension header is after fragment header

RFC 2460

The order of extension headers in a packet is defined; accordingly, the fragment extension header must be after the routing header.

Wrong router alert parameter

RFC 2711

This option is located in the hop-by-hop header and in the Junos OS implementation:

  • There can be only one option of this type per hop-by-hop header

  • The header length must be 2.

  • There can be only one router alert option in one extension header.

More than one back-to-back pad option

draft-krishnan-ipv6-hopbyhop-00

This type of traffic is screened as error packets.

Non-zero payload in PadN option

RFC 4942

The system checks that the PadN only has zero octets in its payload.

Padding beyond the next eight-octet boundary

RFC 4942

The system checks for padding beyond the next eight octet boundary. There is no legitimate reason for padding beyond the next eight octet boundary.

Jumbo payload with non-zero IPv6 header payload

RFC 2675

The payload length field in the IPv6 header must be set to zero in every packet that carries the jumbo payload option.

ICMPv6 Checking and Filtering

You can enable ICMPv6 checking and filtering. The system then checks whether the ICMPv6 packet received matches the defined criteria and performs the specified action on matching packets. Some of the key defined criteria are as follows:

  • Information message of unknown type—Many types of ICMPv6 information messages are defined, such as echo request (value 128), echo reply (value 129), and router solicitation (value 133). The maximum type definition is 149. Any value higher than 149 is treated as an unknown type and screened accordingly.

  • Does not meet the ICMPv6 ND packet format rules (RFC 4861)—There are standard rules, such as the IP Hop limit field has a value of 255, ICMP checksum must be valid, the ICMP code must be 0, and so on.

  • Malformed ICMPv6 packet filtering—For instance, the ICMPv6 packet is too big (message type 2), the next header is set to routing (43), and routing header is set to hop-by hop.

IPv6 Packet Header Checking and Filtering

You can enable the checking and filtering of IPv6 packet headers using the ipv6-malformed-header statement. Once enabled, the system verifies any incoming IPv6 packet to check if it matches any of the defined criteria. The system then performs the specified action (drop or alarm-without-drop) on matching packets. Table 6 lists key criteria that the device uses to screen packets.

Table 6: IPv6 Packet Header Screening Criteria

Screening Criteria

Internet Standards

Description

Deprecated site-local source and destination addresses

RFC 3879

The IPv6 site-local unicast prefix (1111111011 binary or FEC0::/10) is not supported.

Illegal multicast address scope values

RFC 4291

The unassigned multicast address scope values are treated as illegal.

Documentation-only prefix (2001:DB8::/32)

RFC 3849

IANA is to record the allocation of the IPv6 global unicast address prefix (2001:DB8::/32) as a documentation-only prefix in the IPv6 address registry. No end party is to be assigned this address.

Deprecated IPv4-compatible IPv6 source and destination addresses (::/96)

RFC 4291

The IPv4-compatible IPv6 address has been deprecated and is not supported.

ORCHID source and destination addresses (2001:10::/28)

RFC 5156

Addresses of the Overlay Routable Cryptographic Hash Identifiers (2001:10::/28) are used as identifiers and cannot be used for routing at the IP layer. Addresses within this block must not appear on the public Internet.

An IPv4 address embedded inside the IPv6 address (64:ff9b::/96) is an illegal, unacceptable IPv4 address

RFC 6052

The IPv6 address, 64:ff9b::/96, is reserved as “Well-known Prefix” for use in algorithmic mapping.

Understanding Screen IPv6 Tunneling Control

Several IPv6 transition methodologies are provided to utilize the tunneling of IPv6 packets over IPv4 networks that do not support IPv6. For this reason, these methods use public gateways and bypass the policies of the operator.

The security of tunneled packets is a major concern for service providers, because tunneled packets are easily accessed by attackers. Numerous IPv6 transition methodologies have evolved for sending tunneled packets through a network; however, because some of them operate on public gateways, they bypass the policies of the operator. This means that packet transmission is exposed to attackers. To overcome and secure transfer of packets, the IPv6 end nodes are required to de-capsulate the encapsulated data packets. Screen is one of the latest available technologies for blocking or allowing tunneling traffic based on user preferences.

You can configure the following screen options to check and filter packets based on IPv6 extension headers, packet headers, and Bad-Inner-Header IPv6 or IPv4 address validation. Based on your configuration, the screen can drop packets, create logs, and provide increased statistics for IP tunneling.

  • GRE 4in4 Tunnel: The GRE 4in4 Tunnel screen matches the following signature: | IPv4 outer header | GRE header | IPv4 inner header

    An outer IPv4 header must be Protocol 47 GRE Encapsulation. A GRE header must have protocol E-type 0x0800 IPv4. If these conditions are met, this packet is classified as GRE 4in4 tunnel signature.

  • GRE 4in6 Tunnel: The GRE 4in6 Tunnel screen matches the following signature: IPv6 outer main header | IPv6 extension header(s) | GRE header | IPv4 inner header

    An outer IPv6 main header or an IPv6 extension header must have a Next Header of value 47 for GRE. A GRE header must have protocol E-type 0x0800 IPv4. If these conditions are met, this packet is classified as GRE 4in6 tunnel signature.

  • GRE 6in4 Tunnel: The GRE 6in4 Tunnel screen matches the following signature: IPv4 outer header | GRE header | IPv6 inner header

    An outer IPv4 header must be Protocol 47 GRE Encapsulation. A GRE header must have protocol E-type 0x086DD IPv6 . If these conditions are met, this packet is classified as GRE 6in4 tunnel signature.

  • GRE 6in6 Tunnel: The GRE 6in6 Tunnel screen matches the following signature: IPv6 outer main header | IPv6 extension header(s) | GRE header | IPv6 inner header

    An outer IPv6 main header or an IPv6 extension header must have a Next Header of value 47 for GRE. A GRE header must have protocol E-type 0x086DD` IPv6. If these conditions are met, this packet is classified as GRE 6in6 tunnel signature.

  • IPinIP 6to4relay Tunnel : The IPinIP 6to4relay Tunnel screen matches the following signature: | IPv4 outer header | IPv6 inner header

    An outer IPv4 header must be Protocol 41 IPv6 Encapsulation. An outer header source address or destination address must be in network 192.88.99.0/24. An inner IPv6 header source address or destination address must be in network 2002:/16. If these conditions are met, this packet is classified as IPinIP 6to4relay tunnel signature.

  • IPinIP 6in4 Tunnel : The IPinIP 6in4 Tunnel screen matches the following signature: | IPv4 outer header | IPv6 inner header

    An outer IPv4 header must be Protocol 41 IPv6 Encapsulation. If this condition is met, this packet is classified as IPinIP 6in4 tunnel signature.

    Note

    Typically, when IPv6 packets need to be transported in a complete IPv4 network, the IPv6 packets utilizes a point-to-point 6in4 tunnel.

  • IPinIP 6over4 Tunnel : The IPinIP 6over4 Tunnel screen matches the following signature: | IPv4 outer header | IPv6 inner header

    An outer IPv4 header must be Protocol 41 IPv6 Encapsulation:W. An inner header source address or destination address must be in fe80::/64 network. If these conditions are met, this packet is classified as IPinIP 6over4 tunnel signature.

  • IPinIP 4in6 Tunnel : The IPinIP 4in6 Tunnel screen matches the following signature: | IPv6 outer main header | IPv6 extension header(s) | IPv4 inner header

    An outer IPv6 header or an IPv6 extension header must have a Next Header of value 04 for IPv4. If these conditions are met, this packet is classified as IPinIP 4in6 tunnel signature.

  • IPinIP ISATAP Tunnel: The IPinIP ISATAP Tunnel screen matches the following signature: | IPv6 outer main header | IPv6 inner header

    An outer IPv4 header must be Protocol 41 IPv6 Encapsulation. An inner IPv6 header source address or destination address must be in fe80::200:5efe/96 or fe80::5efe/96 network. If these conditions are met, this packet is classified as IPinIP ISATAP tunnel signature.

  • IPinIP DS-Lite Tunnel: The IPinIP DS-Lite Tunnel screen matches the following signature: | IPv6 outer main header | IPv6 extension header(s) | IPv4 inner header

    An outer IPv6 header or an IPv6 extension header must have a Next Header of value 04 for IPv4. An inner IPv4 source address or destination address must be in 192.0.0.0/29 network. If these conditions are met, this packet is classified as IPinIP DS-Lite tunnel signature.

  • IPinIP 6in6 Tunnel: The IPinIP 6in6 Tunnel screen matches the following signature: | IPv6 outer main header | IPv6 extension header(s) | IPv6 inner main header

    An outer IPv6 main header or an IPv6 extension header must have a Next Header of value 41 for IPv6. An inner IPv6 main header must be Version 6. If these two conditions are met, this packet is classified as IPinIP 6in6 tunnel signature.

  • IPinIP 4in4 Tunnel: The IPinIP 4in4 Tunnel screen matches the following signature: | IPv6 outer header | IPv4 inner header . An outer IPv4 header must have a Protocol of value 04 for IPv4. An inner IPv4 header must be Version 4.

  • IPinUDP Teredo Tunnel: The IPinUDP Teredo Tunnel matches the following signature: IPv4 outer header | UDP header | IPv6 inner header

    An outer IPv4 header must have a Protocol of 17 for UDP payload. A UDP header source or destination port must be 3544. An inner IPv6 header source address or destination address must be in network 2001:0000:/32.

  • IP Tunnel Bad Inner-Header Check: The Bad Inner Header Tunnel screen checks the tunnel traffic inner header information for consistency. The packet drops when any of the following is detected:

    • Inner header does not match outer header.

    • Inner header TTL or Hop Limit must not be 0 or 255.

    • Inner header IPv6 address checking.

    • Inner header IPv4 address checking.

    • Outer and Inner header length checks:

    • Inner header IPv4 and IPv6 TCP/UDP/ICMP header length check:

      TCP/UDP/ICMP header length must fit inside of inner IPv4/IPv6/EH6 header length when inner IP(v4/v6) is not a first, next, or last fragment.

    • TCP: The minimum TCP header size must fit in the previous encapsulation length.

    • ICMP: The minimum ICMP header size must fit in the previous encapsulation length.

    • Fragmented packets: For fragmented packets, if the tunnel information needs to be checked for a screen and is not in the first fragment, then checking is not performed except the parts of the tunnel encapsulation that are included in the first fragment. Length checks are performed on first fragment packets using the actual packet buffer length, but the length checks are ignored because the inner header is larger than the outer header.

      • When the outer header is first fragment, do not examine the past physical packet length of the fragment.

      • When the inner header is a first fragment, do not examine the past length of the fragment.

      For non-first fragment packets, checking is not performed in Bad Inner Header Tunnel screen.

    • When outer header is a non-first fragment, examine the packet for screens that only use IP header signatures, because the payload cannot be examined.

    • When inner header is a non-first fragment, do not examine the next packet.

    • The IPv4 inner header checks that IPv4 header is from 20 to 50 bytes.

Note

On all SRX Series devices, when a packet allow or drop session is established, the bad-inner-header screen is performed on every packet, because this screen is a fast path screen.

On SRX300, SRX320, SRX340, SRX345, SRX1500, SRX4100, SRX4200 devices and vSRX instances., the fast-path bad-inner-header screen is always performed first, followed by the first path signature screen.

Starting with Junos OS Release 12.3X48-D10 and Junos OS Release 17.3R1, the syslog messages RT_SCREEN_IP and RT_SCREEN_IP_LS for the IP tunneling screen have been updated. The updated messages include the tunnel screen attacks and log-without-drop criteria. The following list illustrates some examples of these new system log messages for each of the tunnel types:

  • RT_SCREEN_IP: Tunnel GRE 6in4! source: 12.12.12.1, destination: 11.11.11.1, zone name: untrust, interface name: ge-0/0/1.0, action: alarm-without-drop

  • RT_SCREEN_IP: Tunnel GRE 6in6! source: 1212::12, destination: 1111::11, zone name: untrust, interface name: ge-0/0/1.0, action: drop

  • RT_SCREEN_IP: Tunnel GRE 4in4! source: 12.12.12.1, destination: 11.11.11.1, zone name: untrust, interface name: ge-0/0/1.0, action: drop

  • RT_SCREEN_IP_LS: [lsys: LSYS1] Tunnel GRE 6in4! source: 12.12.12.1, destination: 11.11.11.1, zone name: untrust, interface name: ge-0/0/1.0, action: alarm-without-drop

  • RT_SCREEN_IP_LS: [lsys: LSYS1] Tunnel GRE 6in6! source: 1212::12, destination: 1111::11, zone name: untrust, interface name: ge-0/0/1.0, action: drop

  • RT_SCREEN_IP_LS: [lsys: LSYS1] Tunnel GRE 4in4! source: 12.12.12.1, destination: 11.11.11.1, zone name: untrust, interface name: ge-0/0/1.0, action: drop

Example: Improving Tunnel Traffic Security with IP Tunneling Screen Options

This example shows how to configure the tunnel screens to enable the screens to control, allow, or block the transit of tunneled traffic.

Requirements

This example uses the following hardware and software components:

  • An SRX Series device

  • Junos OS Release 12.3X48-D10 and later

Before you begin:

Overview

You can configure the following IP tunneling screen options to check and filter packets, based on IPv6 extension headers, packet headers, and bad-inner-header IPv6 or IPv4 address validation. Based on your configuration, the screen can drop packets, create logs, and provide increased statistics for IP tunneling. The following tunneling screen options are assigned to an untrust zone.

  • GRE 4in4 Tunnel

  • GRE 4in6 Tunnel

  • GRE 6in4 Tunnel

  • GRE 6in6 Tunnel

  • IPinUDP Teredo Tunnel

  • IPinIP 4in4 Tunnel

  • IPinIP 4in6 Tunnel

  • IPinIP 6in4 Tunnel

  • IPinIP 6in6 Tunnel

  • IPinIP 6over4 Tunnel

  • IPinIP 6to4relay Tunnel

  • IPinIP ISATAP Tunnel

  • IPinIP DS-Lite Tunnel

  • Bad Inner Header Tunnel

Configuration

To configure the IP tunneling screen options, perform these tasks:

Configuring GRE Tunnel Screens

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 GRE tunnel screen:

  1. Configure a GRE tunnel screen to check the tunnel traffic inner header information for consistency and validate the signature type screen.
  2. Configure the screens in the security zones.

Configuring an IPinUDP Teredo Tunnel Screen

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 an IPinUDP Teredo tunnel screen:

  1. Configure an IPinUDP Teredo tunnel screen to check the tunnel traffic inner header information for consistency and validate the signature type screen.
  2. Configure the screens in the security zones.

Configuring an IPinIP Tunnel Screen

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 an IPinIP tunnel screen:

  1. Configure an IPinIP tunnel screen to check the tunnel traffic inner header information for consistency and validate the signature type screen.
  2. Configure the screens in the security zones.

Configuring a Bad-Inner-Header Tunnel Screen

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.

To configure a bad-inner-header tunnel screen:

  1. Configure a bad-inner-header tunnel screen to check the tunnel traffic inner header information for consistency.
  2. Configure the screens in the security zones.

Results

From configuration mode, confirm your configuration by entering the show security screen and show security screen statistics zone untrust ip tunnel commands. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

For brevity, this show output includes only the configuration that is relevant to this example. Any other configuration on the system has been replaced with ellipses (...).

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

Verification

Confirm that the configuration is working properly.

Verifying the Security Screen Configuration

Purpose

Display the configuration information about the security screen.

Action

From operational mode, enter the show security screen ids-option screen1 command.

user@host> show security screen ids-option screen1

Meaning

The show security screen ids-option screen1 command displays screen object status as enabled.

Verifying IP Tunnel Screens in the Security Zones

Purpose

Verify that the IP tunneling screen options are configured properly in the security zones.

Action

From operational mode, enter the show security screen statistics zone untrust ip tunnel command.

user@host> show security screen statistics zone untrust ip tunnel

Meaning

The show security screen statistics zone untrust ip tunnel command displays the IP tunnel screen statistics summary.

Release History Table
Release
Description
Starting with Junos OS Release 15.1X49-D30 and Junos OS Release 17.3R1, on SRX5400, SRX5600, and SRX5800 devices, the central point architecture is enhanced to achieve a higher number of connections per second (CPS).
Starting with Junos OS Release 15.1X49-D20 and Junos OS Release 17.3R1, the firewall generates only one log message every second irrespective of the number of packets that trigger the source or destination session limit. This behavior applies to flood protection screens with TCP-Synflood-src-based, TCP-Synflood-dst-based, and UDP flood protection.
Starting with Junos OS Release 12.3X48-D10 and Junos OS Release 17.3R1, the syslog messages RT_SCREEN_IP and RT_SCREEN_IP_LS for the IP tunneling screen have been updated.