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 Firewalls, the screens are divided into two categories:
- Statistics-based screens
- Signature-based screens
- Understanding Central Point Architecture Enhancements for Screens
- Implementation of Screen Options on SRX Series Devices
Statistics-based screens
Table 1 lists all the statistics-based screen options.
Screen Option Name |
Description |
|---|---|
|
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 be send to the same destination address before the device rejects further ICMP packets. |
|
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 be send to 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. |
|
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. |
|
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. |
|
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. |
|
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. |
|
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 Firewalls running Junos OS reject further connection requests from that IP address. |
|
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. |
|
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. |
|
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. |
|
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 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.
Screen Option Name |
Description |
|---|---|
|
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. |
|
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. |
|
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. |
|
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. |
|
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. |
|
Use the FIN bit with no ACK bit IDS option to detect an illegal combination of flags, and reject packets that have this combination. |
|
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). |
|
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 |
|
Use the ICMP large IDS option to detect and drop any ICMP frame with an IP length greater than 1024 bytes. |
|
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. |
|
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. |
|
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. |
|
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. |
|
Use the IP source route IDS option to detect packets and record the event in the screen counters list for the ingress interface. |
|
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. |
|
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. |
|
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. |
|
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. |
|
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. |
|
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. |
|
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.
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:
If the session limit counter of the SPU is larger than the threshold value, the packet is dropped.
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:
If the session limit counter of the SPU is larger than the threshold value, the packet is permitted.
If the session limit counter of the SPU is not larger than ththreshold, the packet is permitted.
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.
Implementation of Screen Options on SRX Series Devices
The below table lists all the screen options implemented on SRX Series Firewalls and are supported on all SRX Series Firewalls.
Screens |
Implemented on NP/CP/SPU |
Support in Hash mode |
Support in SOF mode |
|---|---|---|---|
|
NP |
Yes |
Yes |
|
NP |
Yes |
Yes |
|
NP |
Yes |
Yes |
|
CP+SPU |
Yes |
Yes |
|
CP+SPU |
Yes |
Yes |
|
CP+SPU |
Yes |
Yes |
|
CP+SPU |
Yes |
Yes |
|
CP+SPU |
Yes |
Yes |
|
SPU |
Yes |
NO |
|
SPU |
Yes |
Yes |
|
NP |
Yes |
Yes |
|
NP |
Yes |
Yes |
|
SPU |
Yes |
Yes |
|
NP |
Yes |
Yes |
|
NP |
Yes |
Yes |
|
NP |
Yes |
Yes |
|
NP |
Yes |
Yes |
|
NP |
Yes |
Yes |
|
NP |
Yes |
Yes |
|
NP |
Yes |
Yes |
|
NP |
Yes |
Yes |
|
NP |
Yes |
Yes |
|
NP |
Yes |
Yes |
|
NP |
Yes |
Yes |
|
NP |
Yes |
Yes |
|
NP |
Yes |
Yes |
|
NP |
Yes |
Yes |
|
NP |
Yes |
Yes |
|
NP |
Yes |
Yes |
|
NP |
Yes |
Yes |
|
CP+SPU |
Yes |
Yes |
|
SPU |
Yes |
Yes |
|
NP |
Yes |
Yes |
|
CP+SPU |
Yes |
Yes |
|
SPU |
Yes |
No |
|
SPU |
Yes |
No |
|
SPU |
Yes |
No |
|
SPU |
Yes |
No |
|
SPU |
Yes |
No |
|
SPU |
Yes |
No |
|
SPU |
Yes |
No |
All the screen functionalities supported on the IOC1 card are supported on the IOC2 and IOC3 cards. On the SRX5000 line of devices and on the SRX4600 device, the Network Processor Unit (NPU) in an IOC2 card is replaced by the Lookup Unit (LU).
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.
set security screen ids-option screen-config icmp ip-sweep threshold 1000 set security screen ids-option screen-config icmp fragment set security screen ids-option screen-config icmp large set security screen ids-option screen-config icmp flood threshold 200 set security screen ids-option screen-config icmp ping-death set security screen ids-option screen-config ip bad-option set security screen ids-option screen-config ip stream-option set security screen ids-option screen-config ip spoofing set security screen ids-option screen-config ip strict-source-route-option set security screen ids-option screen-config ip unknown-protocol set security screen ids-option screen-config ip tear-drop set security screen ids-option screen-config tcp syn-fin set security screen ids-option screen-config tcp tcp-no-flag set security screen ids-option screen-config tcp syn-frag set security screen ids-option screen-config tcp port-scan threshold 1000 set security screen ids-option screen-config tcp syn-ack-ack-proxy threshold 500 set security screen ids-option screen-config tcp syn-flood alarm-threshold 500 set security screen ids-option screen-config tcp syn-flood attack-threshold 500 set security screen ids-option screen-config tcp syn-flood source-threshold 50 set security screen ids-option screen-config tcp syn-flood destination-threshold 1000 set security screen ids-option screen-config tcp syn-flood timeout 10 set security screen ids-option screen-config tcp land set security screen ids-option screen-config tcp winnuke set security screen ids-option screen-config tcp tcp-sweep threshold 1000 set security screen ids-option screen-config udp flood threshold 500 set security screen ids-option screen-config udp udp-sweep threshold 1000 set security zones security-zone untrust screen screen-config
Enter commit from configuration mode.
Procedure
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:
Configure the ICMP screening options.
[edit security screen ids-option screen-config] user@host# set icmp ip-sweep threshold 1000 user@host# set icmp fragment user@host# set icmp large user@host# set icmp flood threshold 200 user@host# set icmp ping-death
Configure the IP screening options.
[edit security screen ids-option screen-config] user@host# set ip bad-option user@host# set ip stream-option user@host# set ip spoofing user@host# set ip strict-source-route-option user@host# set ip unknown-protocol user@host# set ip tear-drop
Configure the TCP screening options.
[edit security screen ids-option screen-config] user@host# set tcp syn-fin user@host# set tcp tcp-no-flag user@host# set tcp syn-frag user@host# set tcp port-scan threshold 1000 user@host# set tcp syn-ack-ack-proxy threshold 500 user@host# set tcp syn-flood alarm-threshold 500 user@host# set tcp syn-flood attack-threshold 500 user@host# set tcp syn-flood source-threshold 50 user@host# set tcp syn-flood destination-threshold 1000 user@host# set tcp syn-flood timeout 10 user@host# set tcp land user@host# set tcp winnuke user@host# set tcp tcp-sweep threshold 1000
Configure the UDP screening options.
[edit security screen ids-option screen-config] user@host# set udp flood threshold 500 user@host# set udp udp-sweep threshold 1000
Attach the IDS profile to the zone.
[edit] user@host# set security zones security-zone untrust screen screen-config
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.
[edit]
user@host# show security screen ids-option screen-config
icmp {
ip-sweep threshold 1000;
fragment;
large;
flood threshold 200;
ping-death;
}
ip {
bad-option;
stream-option;
spoofing;
strict-source-route-option;
unknown-protocol;
tear-drop;
}
tcp {
syn-fin;
tcp-no-flag;
syn-frag;
port-scan threshold 1000;
syn-ack-ack-proxy threshold 500;
syn-flood {
alarm-threshold 500;
attack-threshold 500;
source-threshold 50;
destination-threshold 1000;
timeout 10;
}
land;
winnuke;
tcp-sweep threshold 1000;
}
udp {
flood threshold 500;
udp-sweep threshold 1000;
}
[edit]
user@host# show security zones
security-zone untrust {
screen screen-config;
}
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.
user@host> show security screen ids-option screen-config
Screen object status:
Name Value
ICMP flood threshold 200
UDP flood threshold 500
TCP winnuke enabled
TCP port scan threshold 1000
ICMP address sweep threshold 1000
TCP sweep threshold 1000
UDP sweep threshold 1000
IP tear drop enabled
TCP SYN flood attack threshold 500
TCP SYN flood alarm threshold 500
TCP SYN flood source threshold 50
TCP SYN flood destination threshold 1000
TCP SYN flood timeout 10
IP spoofing enabled
ICMP ping of death enabled
TCP land attack enabled
TCP SYN fragment enabled
TCP no flag enabled
IP unknown protocol enabled
IP bad options enabled
IP strict source route option enabled
IP stream option enabled
ICMP fragmentation enabled
ICMP large packet enabled
TCP SYN FIN enabled
TCP SYN-ACK-ACK proxy threshold 500
user@host> show security zones
Security zone: untrust
Send reset for non-SYN session TCP packets: Off
Policy configurable: Yes
Screen: screen-config
Interfaces bound: 0
Interfaces:On all SRX Series Firewalls, 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
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 4 lists the statistics-based screen options and the behavior of the screens depending on whether the device has either IOC1 or an IOC2 card.
Screen Option Name |
Description |
IOC1 |
IOC2 |
|---|---|---|---|
|
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. |
|
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. |
|
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. |
|
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. |
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.
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
- Maximum Number of Extension Headers
- Bad Option Extension Headers
- ICMPv6 Checking and Filtering
- IPv6 Packet Header Checking and Filtering
IPv6 Extension Header Checking and Filtering
You can use the ipv6-extension-header statement to
selectively screen one or more extension headers. Table 5 lists common IPv6
extension headers and their 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
|
60 |
RFC 2460 |
Fragment |
44 |
RFC 2460 |
Hop-by-Hop Options
|
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:
Hop-by-Hop Options header
Destination Options header
Routing header
Fragment extension header
Authentication header
Encapsulating Security Payload header
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 6 lists key criteria that the device uses to screen packets for bad options.
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:
|
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 7 lists key criteria
that the device uses to screen packets.
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 headerAn 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 headerAn 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 headerAn 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 headerAn 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 headerAn 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 headerAn 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 headerAn 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 headerAn 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 headerAn 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 headerAn 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 headerAn 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 headerAn 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.
On all SRX Series Firewalls, 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, SRX380, SRX1500, SRX4100, SRX4200 devices and vSRX Virtual Firewall 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-dropRT_SCREEN_IP: Tunnel GRE 6in6! source: 1212::12, destination: 1111::11, zone name: untrust, interface name: ge-0/0/1.0, action: dropRT_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: dropRT_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-dropRT_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: dropRT_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 Firewall
Junos OS Release 12.3X48-D10 and later
Before you begin:
Understand the IPv6 Tunneling control. See Understanding Screen IPv6 Tunneling Control.
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
- Configuring an IPinUDP Teredo Tunnel Screen
- Configuring an IPinIP Tunnel Screen
- Configuring a Bad-Inner-Header Tunnel Screen
- Results
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.
set security screen ids-option screen1 ip tunnel gre gre-4in4 set security screen ids-option screen1 ip tunnel gre gre-4in6 set security screen ids-option screen1 ip tunnel gre gre-6in4 set security screen ids-option screen1 ip tunnel gre gre-6in6 set security zones security-zone untrust screen screen1
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:
Configure a GRE tunnel screen to check the tunnel traffic inner header information for consistency and validate the signature type screen.
[edit security screen ids-option screen1 ip tunnel gre] user@host# set gre-4in4 user@host# set gre-4in6 user@host# set gre-6in4 user@host# set gre gre-6in6
Configure the screens in the security zones.
user@host#set security zones security-zone untrust screen screen1
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.
set security screen ids-option screen1 ip tunnel ip-in-udp teredo set security zones security-zone untrust screen screen1
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:
Configure an IPinUDP Teredo tunnel screen to check the tunnel traffic inner header information for consistency and validate the signature type screen.
[edit security screen ids-option screen1 ip tunnel] user@host# set ip-in-udp teredo
Configure the screens in the security zones.
user@host# set security zones security-zone untrust screen screen1
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.
set security screen ids-option screen1 ip tunnel ipip dslite set security screen ids-option screen1 ip tunnel ipip ipip-4in4 set security screen ids-option screen1 ip tunnel ipip ipip-4in6 set security screen ids-option screen1 ip tunnel ipip ipip-6in4 set security screen ids-option screen1 ip tunnel ipip ipip-6in6 set security screen ids-option screen1 ip tunnel ipip ipip-6over4 set security screen ids-option screen1 ip tunnel ipip ipip-6to4relay set security screen ids-option screen1 ip tunnel ipip isatap set security zones security-zone untrust screen screen1
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:
Configure an IPinIP tunnel screen to check the tunnel traffic inner header information for consistency and validate the signature type screen.
[edit security screen ids-option screen1 ip tunnel ipip] user@host# set dslite user@host# set ipip-4in4 user@host# set ipip-4in6 user@host# set ipip-6in4 user@host# set ipip-6in6 user@host# set ipip-6over4 user@host# set ipip-6to4relay user@host# set ipip-isatap
Configure the screens in the security zones.
user@host# set security zones security-zone untrust screen screen1
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.
set security screen ids-option screen1 ip tunnel bad-inner-header set security zones security-zone untrust screen screen1
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:
Configure a bad-inner-header tunnel screen to check the tunnel traffic inner header information for consistency.
[edit security screen ids-option screen1 ip tunnel] user@host# set bad-inner-header
Configure the screens in the security zones.
user@host# set security zones security-zone untrust screen screen1
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 (...).
[edit]
user@host# show security screen
...
ids-option screen1 {
ip{
tunnel {
gre {
gre-4in4;
gre-4in6;
gre-6in4;
gre-6in6;
}
ip-in-udp {
teredo;
}
ipip {
ipip-4in4;
ipip-4in6;
ipip-6in4;
ipip-6in6;
ipip-6over4;
ipip-6to4relay;
isatap;
dslite;
}
bad-inner-header;
}
}
}
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 show security screen ids-option screen1: Name Value IP Tunnel Bad Inner Header enabled IP Tunnel GRE 6in4 enabled IP Tunnel GRE 4in6 enabled IP Tunnel GRE 6in6 enabled IP Tunnel GRE 4in4 enabled IP Tunnel IPinUDP Teredo enabled IP Tunnel IPIP 6to4 Relay enabled IP Tunnel IPIP 6in4 enabled IP Tunnel IPIP 6over4 enabled IP Tunnel IPIP 4in6 enabled IP Tunnel IPIP 4in4 enabled IP Tunnel IPIP 6in6 enabled IP Tunnel IPIP ISATAP enabled IP Tunnel IPIP DS-Lite enabled
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 IP Tunnel Screen statistics: IDS attack type Statistics IP tunnel GRE 6in4 0 IP tunnel GRE 4in6 0 IP tunnel GRE 6in6 0 IP tunnel GRE 4in4 0 IP tunnel IPIP 6to4 relay 0 IP tunnel IPIP 6in4 0 IP tunnel IPIP 6over4 0 IP tunnel IPIP 4in6 0 IP tunnel IPIP 4in4 0 IP tunnel IPIP 6in6 0 IP tunnel IPIP ISATAP 0 IP tunnel IPIP DS-Lite 0 IP tunnel IPinUDP Teredo 0 IP tunnel bad inner header 0
Meaning
The show security screen statistics zone untrust
ip tunnel command displays the IP tunnel screen statistics summary.
Change History Table
Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.
TCP-Synflood-src-based, TCP-Synflood-dst-based, and UDP flood protection.RT_SCREEN_IP and RT_SCREEN_IP_LS for the IP tunneling
screen have been updated.