junos® os attack detection and ... - juniper networks · understandinglandattacks|112...

Junos® OS

Attack Detection and Prevention UserGuide for Security Devices

Published

2019-12-12

Juniper Networks, Inc.1133 Innovation WaySunnyvale, California 94089USA408-745-2000www.juniper.net

Juniper Networks, the Juniper Networks logo, Juniper, and Junos are registered trademarks of Juniper Networks, Inc. inthe United States and other countries. All other trademarks, service marks, registered marks, or registered service marksare the property of their respective owners.

Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the rightto change, modify, transfer, or otherwise revise this publication without notice.

Junos® OS Attack Detection and Prevention User Guide for Security DevicesCopyright © 2019 Juniper Networks, Inc. All rights reserved.

The information in this document is current as of the date on the title page.

YEAR 2000 NOTICE

Juniper Networks hardware and software products are Year 2000 compliant. Junos OS has no known time-relatedlimitations through the year 2038. However, the NTP application is known to have some difficulty in the year 2036.

END USER LICENSE AGREEMENT

The Juniper Networks product that is the subject of this technical documentation consists of (or is intended for use with)Juniper Networks software. Use of such software is subject to the terms and conditions of the EndUser License Agreement(“EULA”) posted at https://support.juniper.net/support/eula/. By downloading, installing or using such software, youagree to the terms and conditions of that EULA.

ii

https://support.juniper.net/support/eula/

Understanding Screen IPv6 Tunneling Control | 47

Example: Improving Tunnel Traffic Security with IP Tunneling Screen Options | 51

Denial of Service Attacks2DoS Attack Overview | 63

Firewall DoS Attacks Overview | 63

Understanding Firewall Filters on the SRX5000 Module Port Concentrator | 63

Firewall DoS Attacks | 64

Understanding Session Table Flood Attacks | 65

Understanding Source-Based Session Limits | 65

Example: Setting Source-Based Session Limits | 66

Understanding Destination-Based Session Limits | 69

Example: Setting Destination-Based Session Limits | 70

Understanding SYN-ACK-ACK Proxy Flood Attacks | 73

Protecting Your Network Against a SYN-ACK-ACK Proxy Flood Attack | 73

Network DoS Attacks | 76

Network DoS Attacks Overview | 77

Understanding SYN Flood Attacks | 77

SYN Flood Protection | 78

SYN Flood Options | 79

Protecting Your Network Against SYN Flood Attacks by Enabling SYN Flood Protection | 81

Example: Enabling SYN Flood Protection for Webservers in the DMZ | 84

Understanding Whitelists for SYN Flood Screens | 91

Example: Configuring Whitelists for SYN Flood Screens | 92

Understanding Whitelists for UDP Flood Screens | 94

Example: Configuring Whitelists for UDP Flood Screens | 94

Understanding SYN Cookie Protection | 97

SYN Cookie Options | 100

Detecting and Protecting Your Network Against SYN Flood Attacks by Enabling SYN CookieProtection | 101

Understanding ICMP Flood Attacks | 104

Protecting Your Network Against ICMP Flood Attacks by Enabling ICMP Flood Protection | 106

Understanding UDP Flood Attacks | 108

Protecting Your Network Against UDP Flood Attacks by Enabling UDP Flood Protection | 109

iv

Understanding Land Attacks | 112

Protecting Your Network Against Land Attacks by Enabling Land Attack Protection | 113

OS-Specific DoS Attack | 116

OS-Specific DoS Attacks Overview | 116

Understanding Ping of Death Attacks | 117

Example: Protecting Against a Ping of Death Attack | 118

Understanding Teardrop Attacks | 119

Understanding WinNuke Attacks | 120

Example: Protecting Against a WinNuke Attack | 121

Suspicious Packets3Suspicious Packet Attributes Overview | 127

ICMP and SYN Fragment Attacks | 127

Understanding ICMP Fragment Protection | 128

Example: Blocking Fragmented ICMP Packets | 128

Understanding Large ICMP Packet Protection | 130

Example: Blocking Large ICMP Packets | 130

Understanding SYN Fragment Protection | 132

Example: Dropping IP Packets Containing SYN Fragments | 133

IP Packet Protection | 134

Understanding IP Packet Fragment Protection | 135

Example: Dropping Fragmented IP Packets | 136

Understanding Bad IP Option Protection | 137

Example: Blocking IP Packets with Incorrectly Formatted Options | 138

Understanding Unknown Protocol Protection | 139

Example: Dropping Packets Using an Unknown Protocol | 140

v

Network Reconnaissance4Reconnaissance Deterrence Overview | 145

IP Address Sweep and Port Scan | 145

Understanding Network Reconnaissance Using IP Options | 146

Uses for IP Packet Header Options | 146

Screen Options for Detecting IP Options Used for Reconnaissance | 149

Example: Detecting Packets That Use IP Screen Options for Reconnaissance | 149

Understanding IP Address Sweeps | 153

Example: Blocking IP Address Sweeps | 154

Understanding TCP Port Scanning | 156

Understanding UDP Port Scanning | 157

Enhancing Traffic Management by Blocking Port Scans | 158

Operating System Identification Probes | 162

Understanding Operating System Identification Probes | 162

Understanding Domain Name System Resolve | 162

Understanding TCP Headers with SYN and FIN Flags Set | 163

Example: Blocking Packets with SYN and FIN Flags Set | 164

Understanding TCP Headers With FIN Flag Set and Without ACK Flag Set | 167

Example: Blocking Packets With FIN Flag Set and Without ACK Flag Set | 168

Understanding TCP Header with No Flags Set | 171

Example: Blocking Packets with No Flags Set | 171

Attacker Evasion Techniques | 174

Understanding Attacker Evasion Techniques | 175

Understanding FIN Scans | 175

Thwarting a FIN Scan | 175

Understanding TCP SYN Checking | 176

Setting TCP SYN Checking | 178

Setting TCP Strict SYN Checking | 178

Understanding IP Spoofing | 179

Example: Blocking IP Spoofing | 179

Understanding IP Spoofing in Layer 2 Transparent Mode on Security Devices | 181

Configuring IP Spoofing in Layer 2 Transparent Mode on Security Devices | 182

vi

show security screen ids-option | 257

show security screen statistics | 264

show security screen status | 278

show security screen white-list | 279

ix

About the Documentation

IN THIS SECTION

Documentation and Release Notes | xi

Using the Examples in This Manual | xi

Documentation Conventions | xiii

Documentation Feedback | xvi

Requesting Technical Support | xvi

Use this guide to configure the screen options in JunosOS on the SRX Series devices to detect and preventinternal and external attacks, including SYN flood attacks, UDP flood attacks, and port scan attacks.

Documentation and Release Notes

To obtain the most current version of all Juniper Networks® technical documentation, see the productdocumentation page on the Juniper Networks website at https://www.juniper.net/documentation/.

If the information in the latest release notes differs from the information in the documentation, follow theproduct Release Notes.

Juniper Networks Books publishes books by Juniper Networks engineers and subject matter experts.These books go beyond the technical documentation to explore the nuances of network architecture,deployment, and administration. The current list can be viewed at https://www.juniper.net/books.

Using the Examples in This Manual

If you want to use the examples in this manual, you can use the load merge or the load merge relativecommand. These commands cause the software to merge the incoming configuration into the currentcandidate configuration. The example does not become active until you commit the candidate configuration.

If the example configuration contains the top level of the hierarchy (or multiple hierarchies), the exampleis a full example. In this case, use the load merge command.

xi

https://www.juniper.net/documentation/

https://www.juniper.net/books

If the example configuration does not start at the top level of the hierarchy, the example is a snippet. Inthis case, use the loadmerge relative command. These procedures are described in the following sections.

Merging a Full Example

To merge a full example, follow these steps:

1. From the HTML or PDF version of the manual, copy a configuration example into a text file, save thefile with a name, and copy the file to a directory on your routing platform.

For example, copy the following configuration to a file and name the file ex-script.conf. Copy theex-script.conf file to the /var/tmp directory on your routing platform.

system {scripts {commit {file ex-script.xsl;

}}

}interfaces {fxp0 {disable;unit 0 {family inet {address 10.0.0.1/24;

}}

}}

2. Merge the contents of the file into your routing platform configuration by issuing the load mergeconfiguration mode command:

[edit]user@host# load merge /var/tmp/ex-script.confload complete

xii

Merging a Snippet

To merge a snippet, follow these steps:

1. From the HTML or PDF version of the manual, copy a configuration snippet into a text file, save thefile with a name, and copy the file to a directory on your routing platform.

For example, copy the following snippet to a file and name the file ex-script-snippet.conf. Copy theex-script-snippet.conf file to the /var/tmp directory on your routing platform.

commit {file ex-script-snippet.xsl; }

2. Move to the hierarchy level that is relevant for this snippet by issuing the following configurationmodecommand:

[edit]user@host# edit system scripts[edit system scripts]

3. Merge the contents of the file into your routing platform configuration by issuing the load mergerelative configuration mode command:

[edit system scripts]user@host# load merge relative /var/tmp/ex-script-snippet.confload complete

For more information about the load command, see CLI Explorer.

Documentation Conventions

Table 1 on page xiv defines notice icons used in this guide.

xiii

https://www.juniper.net/techpubs/content-applications/cli-explorer/junos/

Table 1: Notice Icons

DescriptionMeaningIcon

Indicates important features or instructions.Informational note

Indicates a situation that might result in loss of data or hardwaredamage.

Caution

Alerts you to the risk of personal injury or death.Warning

Alerts you to the risk of personal injury from a laser.Laser warning

Indicates helpful information.Tip

Alerts you to a recommended use or implementation.Best practice

Table 2 on page xiv defines the text and syntax conventions used in this guide.

Table 2: Text and Syntax Conventions

ExamplesDescriptionConvention

To enter configuration mode, typethe configure command:

user@host> configure

Represents text that you type.Bold text like this

user@host> show chassis alarms

No alarms currently active

Represents output that appears onthe terminal screen.

Fixed-width text like this

• A policy term is a named structurethat defines match conditions andactions.

• Junos OS CLI User Guide

• RFC 1997, BGP CommunitiesAttribute

• Introduces or emphasizes importantnew terms.

• Identifies guide names.

• Identifies RFC and Internet drafttitles.

Italic text like this

xiv

Table 2: Text and Syntax Conventions (continued)


Configure the machine’s domainname:

[edit]root@# set system domain-namedomain-name

Represents variables (options forwhich you substitute a value) incommands or configurationstatements.

Italic text like this

• To configure a stub area, includethe stub statement at the [editprotocols ospf area area-id]hierarchy level.

• The console port is labeledCONSOLE.

Represents names of configurationstatements, commands, files, anddirectories; configuration hierarchylevels; or labels on routing platformcomponents.

Text like this

stub <default-metric metric>;Encloses optional keywords orvariables.

< > (angle brackets)

broadcast | multicast

(string1 | string2 | string3)

Indicates a choice between themutually exclusive keywords orvariables on either side of the symbol.The set of choices is often enclosedin parentheses for clarity.

| (pipe symbol)

rsvp { # Required for dynamic MPLSonly

Indicates a comment specified on thesame line as the configurationstatement to which it applies.

# (pound sign)

community name members [community-ids ]

Encloses a variable for which you cansubstitute one or more values.

[ ] (square brackets)

[edit]routing-options {static {route default {nexthop address;retain;

}}

}

Identifies a level in the configurationhierarchy.

Indention and braces ( { } )

Identifies a leaf statement at aconfiguration hierarchy level.

; (semicolon)

GUI Conventions

xv

Table 2: Text and Syntax Conventions (continued)


• In the Logical Interfaces box, selectAll Interfaces.

• To cancel the configuration, clickCancel.

Represents graphical user interface(GUI) items you click or select.

Bold text like this

In the configuration editor hierarchy,select Protocols>Ospf.

Separates levels in a hierarchy ofmenu selections.

> (bold right angle bracket)

Documentation Feedback

We encourage you to provide feedback so that we can improve our documentation. You can use eitherof the following methods:

• Online feedback system—Click TechLibrary Feedback, on the lower right of any page on the JuniperNetworks TechLibrary site, and do one of the following:

• Click the thumbs-up icon if the information on the page was helpful to you.

• Click the thumbs-down icon if the information on the page was not helpful to you or if you havesuggestions for improvement, and use the pop-up form to provide feedback.

• E-mail—Send your comments to [email protected]. Include the document or topic name,URL or page number, and software version (if applicable).

Requesting Technical Support

Technical product support is available through the Juniper Networks Technical Assistance Center (JTAC).If you are a customer with an active Juniper Care or Partner Support Services support contract, or are

xvi

https://www.juniper.net/documentation/index.html

https://www.juniper.net/documentation/index.html

mailto:[email protected]?subject=

covered under warranty, and need post-sales technical support, you can access our tools and resourcesonline or open a case with JTAC.

• JTAC policies—For a complete understanding of our JTAC procedures and policies, review the JTACUserGuide located at https://www.juniper.net/us/en/local/pdf/resource-guides/7100059-en.pdf.

• Productwarranties—For productwarranty information, visit https://www.juniper.net/support/warranty/.

• JTAC hours of operation—The JTAC centers have resources available 24 hours a day, 7 days a week,365 days a year.

Self-Help Online Tools and Resources

For quick and easy problem resolution, Juniper Networks has designed an online self-service portal calledthe Customer Support Center (CSC) that provides you with the following features:

• Find CSC offerings: https://www.juniper.net/customers/support/

• Search for known bugs: https://prsearch.juniper.net/

• Find product documentation: https://www.juniper.net/documentation/

• Find solutions and answer questions using our Knowledge Base: https://kb.juniper.net/

• Download the latest versions of software and review release notes:https://www.juniper.net/customers/csc/software/

• Search technical bulletins for relevant hardware and software notifications:https://kb.juniper.net/InfoCenter/

• Join and participate in the Juniper Networks Community Forum:https://www.juniper.net/company/communities/

• Create a service request online: https://myjuniper.juniper.net

To verify service entitlement by product serial number, use our Serial Number Entitlement (SNE) Tool:https://entitlementsearch.juniper.net/entitlementsearch/

Creating a Service Request with JTAC

You can create a service request with JTAC on the Web or by telephone.

• Visit https://myjuniper.juniper.net.

• Call 1-888-314-JTAC (1-888-314-5822 toll-free in the USA, Canada, and Mexico).

For international or direct-dial options in countries without toll-free numbers, seehttps://support.juniper.net/support/requesting-support/.

xvii

https://www.juniper.net/us/en/local/pdf/resource-guides/7100059-en.pdf

https://www.juniper.net/support/warranty/

https://www.juniper.net/customers/support/

https://prsearch.juniper.net/

https://www.juniper.net/documentation/

https://kb.juniper.net/

https://www.juniper.net/customers/csc/software/

https://kb.juniper.net/InfoCenter/

https://www.juniper.net/company/communities/

https://myjuniper.juniper.net

https://entitlementsearch.juniper.net/entitlementsearch/

https://myjuniper.juniper.net

https://support.juniper.net/support/requesting-support/

1CHAPTER

Overview

Attack Detection and Prevention Overview | 21

Screens Options for Attack Detection and Prevention | 21

Attack Detection and Prevention Overview

Juniper Networks provides various detection and defense mechanisms at the zone and policy levels tocombat exploits at all stages of their execution:

Attack detection and prevention, also known as stateful firewall, detects and prevents attacks in networktraffic. An exploit can be either an information-gathering probe or an attack to compromise, disable, orharm a network or network resource. In some cases, the distinction between the two objectives of anexploit can be unclear. For example, a barrage of TCP SYN segments might be an IP address sweep withthe intent of triggering responses from active hosts, or it might be a SYN flood attack with the intent ofoverwhelming a network so that it can no longer function properly. Furthermore, because an attackerusually precedes an attack by performing reconnaissance on the target, we can considerinformation-gathering efforts as a precursor to an impending attack—that is, they constitute the first stageof an attack. Thus, the term exploit encompasses both reconnaissance and attack activities, and thedistinction between the two is not always clear.

• Screen options at the zone level.

• Firewall policies at the inter-, intra-, and super-zone policy levels (super-zone heremeans in global policies,where no security zones are referenced).

To secure all connection attempts, Junos OS uses a dynamic packet-filtering method known as statefulinspection. Using this method, Junos OS identifies various components in the IP packet and TCP segmentheaders—source and destination IP addresses, source and destination port numbers, and packet sequencenumbers—and maintains the state of each TCP session and pseudo UDP session traversing the firewall.(Junos OS also modifies session states based on changing elements such as dynamic port changes orsession termination.)When a responding TCP packet arrives, JunosOS compares the information reportedin its header with the state of its associated session stored in the inspection table. If they match, theresponding packet is allowed to pass the firewall. If the two do not match, the packet is dropped.

Junos OS screen options secure a zone by inspecting, then allowing or denying, all connection attemptsthat require crossing an interface bound to that zone.

ScreensOptions for AttackDetection and Prevention

IN THIS SECTION

Understanding Screens Options on SRX Series Devices | 22


21

Understanding Screen Options on the SRX5000 Module Port Concentrator | 36

Understanding IPv6 Support for Screens | 43

Understanding Screen IPv6 Tunneling Control | 47

Example: Improving Tunnel Traffic Security with IP Tunneling Screen Options | 51

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 3 on page 22 lists all the statistics-based screen options.

Table 3: Statistics-Based Screen Options

DescriptionScreen Option Name

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

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

ICMP flood

22

Table 3: Statistics-Based Screen Options (continued)


Use the UDP flood IDS option to protect against UDP flood attacks. A UDP flood attackoccurs when an attacker sends IP packets containing a UDP datagramwith the purposeof 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 thesame destination IP address. When the number of packets exceeds this value withinany 1-second period, the device generates an alarm and drops subsequent packets forthe remainder of that second.

UDP flood

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

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

TCP SYN flood source

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

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

TCP SYN flood destination

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

TCP SYN flood

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

TCP port scan

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-ACKproxy threshold, SRX Series devices running JunosOS reject further connection requestsfrom that IP address.

TCP SYN-ACK-ACK proxy

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

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

ICMP IP sweep

23



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

TCP SYN flood alarm

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

TCP SYN flood attack

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

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

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

UDP udp sweep

Starting with Junos OS Release 15.1X49-D20 and Junos OS Release 17.3R1, the firewall generates onlyone log message every second irrespective of the number of packets that trigger the source or destinationsession 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 4 on page 24 lists all the signature-based screen options.

Table 4: Signature-Based Screen Options


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

TCPWinnuke

24

Table 4: Signature-Based Screen Options (continued)


Use the TCP SYN fragment attack IDS option to drop any packet fragments used forthe 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 itcan reassemble them. The flood of connections that cannot be completed eventuallyfills the host’s memory buffer. No further connections are possible, and damage to thehost’s operating system can occur.

TCP SYN fragment

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

TCP no flag

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

TCP SYN FIN

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

TCP land

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

TCP FIN no ACK

Use the ping of death IDS option to detect and reject oversized and irregular ICMPpackets. Although the TCP/IP specification requires a specific packet size, many pingimplementations allow larger packet sizes. Larger packets can trigger a range of adversesystem 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 ping of death

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

ICMP fragment

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

ICMP large

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

IP unknown protocol

25



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

IP bad 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 ingressinterface. This option specifies the complete route list for a packet to take on its journeyfrom source to destination. The last address in the list replaces the address in thedestination field. Currently, this screen option is applicable only to IPv4.

IP strict source routeoption

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 ingressinterface. This option specifies a partial route list for a packet to take on its journeyfrom 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 0routing header of the loose source route option is the only related header defined inIPv6.

IP loose source routeoption

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

IP source route 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 optionprovides a way for the 16-bit SATNET stream identifier to be carried through networksthat do not support streams. Currently, this screen option is applicable only to IPv4.

IP stream option

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 thatare received at interfaces bound to that zone.

IP block fragment

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

IP record route option

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

IP timestamp option

26



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

IP security option

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

IP spoofing

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

IP tear drop

Understanding Central Point Architecture Enhancements for Screens

Starting with Junos OS Release 15.1X49-D30 and Junos OS Release 17.3R1, on SRX5400, SRX5600, andSRX5800 devices, the central point architecture is enhanced to achieve a higher number of connectionsper second (CPS). Due to the enhancements, the central point session and central point packet processinghave 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 havesession limits. If there are no resources available in the central point, but resources are available in theSPU, 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 determinewhether to permit or dropa packet.

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

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

b. 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:

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

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

27

NOTE: An extra message is sent to the central point to maintain accurate session counts mightimpact the number of connections per second (CPS) for screens. This impacts the source ordestination session limit.

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

Previously, statistics-based screens were handled only by the central point and the log and the SNMP trapcould be rate-limited strictly. Now both the central point and the SPU can generate the log and the SNMPtrap 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 devices and are supported on allSRX series devices.

Table 5: Screen Options Implemented on SRX Series Devices

Support in SOFmode

Support in Hashmode

Implemented onNP/CP/SPUScreens

YesYesNPicmp-flood

YesYesNPudp-flood

YesYesNPwinnuke

YesYesCP+SPUtcp-port-scan

YesYesCP+SPUudp-port-scan

YesYesCP+SPUaddress-sweep

YesYesCP+SPUtcp-sweep

YesYesCP+SPUudp-sweep

NOYesSPUtear-drop

YesYesSPUsyn-flood

28

Table 5: Screen Options Implemented on SRX Series Devices (continued)

Support in SOFmode

Support in Hashmode


YesYesNPsyn-flood-src

YesYesNPsyn-flood-dst

YesYesSPUip-spoofing

YesYesNPping-of-death

YesYesNPip-option-src-route

YesYesNPland

YesYesNPsyn-fragment

YesYesNPtcp-no-flag

YesYesNPunknown-protocol

YesYesNPip-option-bad

YesYesNPip-option-record-route

YesYesNPip-option-timestamp

YesYesNPip-option-security

YesYesNPip-option-loose-src-route

YesYesNPip-option-strict-src-route

YesYesNPip-option-stream

YesYesNPicmp-fragment

YesYesNPicmp-large-pkt

YesYesNPsyn-fin

YesYesNPfin-no-ack

29

Table 5: Screen Options Implemented on SRX Series Devices (continued)

Support in SOFmode

Support in Hashmode


YesYesCP+SPUsrc-session-limit

YesYesSPUsyn-ack-ack-proxy

YesYesNPblock-fragment

YesYesCP+SPUdst-session-limit

NoYesSPUipv6-ext-header

NoYesSPUipv6-ext-hbyh-option

NoYesSPUipv6-ext-dst-option

NoYesSPUipv6-ext-header-limit

NoYesSPUipv6-malformed-header

NoYesSPUicmpv6-malformed-packet

NoYesSPUip-tunnel-summary

NOTE: All the screen functionalities supported on the IOC1 card are supported on the IOC2and IOC3 cards. On the SRX5000 line of devices and on the SRX4600 device, the NetworkProcessor Unit (NPU) in an IOC2 card is replaced by the Lookup Unit (LU).

Example: Configuring Multiple Screening Options

IN THIS SECTION

Requirements | 31

Overview | 31

30

Configuration | 31

Verification | 35

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

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 areconfiguring the following screening options:

• ICMP screening

• IP screening

• TCP screening

• UDP screening

These screening options are assigned to an untrust zone.

Configuration

CLI Quick ConfigurationTo quickly configure this example, copy the following commands, paste them into a text file, remove anyline breaks, change any details necessary to match your network configuration, copy and paste thecommands 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 1000set security screen ids-option screen-config icmp fragmentset security screen ids-option screen-config icmp largeset security screen ids-option screen-config icmp flood threshold 200set security screen ids-option screen-config icmp ping-deathset security screen ids-option screen-config ip bad-optionset security screen ids-option screen-config ip stream-optionset security screen ids-option screen-config ip spoofingset security screen ids-option screen-config ip strict-source-route-option

31

set security screen ids-option screen-config ip unknown-protocolset security screen ids-option screen-config ip tear-dropset security screen ids-option screen-config tcp syn-finset security screen ids-option screen-config tcp tcp-no-flagset security screen ids-option screen-config tcp syn-fragset security screen ids-option screen-config tcp port-scan threshold 1000set security screen ids-option screen-config tcp syn-ack-ack-proxy threshold 500set security screen ids-option screen-config tcp syn-flood alarm-threshold 500set security screen ids-option screen-config tcp syn-flood attack-threshold 500set security screen ids-option screen-config tcp syn-flood source-threshold 50set security screen ids-option screen-config tcp syn-flood destination-threshold 1000set security screen ids-option screen-config tcp syn-flood timeout 10set security screen ids-option screen-config tcp landset security screen ids-option screen-config tcp winnukeset security screen ids-option screen-config tcp tcp-sweep threshold 1000set security screen ids-option screen-config udp flood threshold 500set security screen ids-option screen-config udp udp-sweep threshold 1000set security zones security-zone untrust screen screen-config

Enter commit from configuration mode.

Step-by-Step ProcedureThe following example requires you to navigate various levels in the configuration hierarchy. For instructionson 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.

[edit security screen ids-option screen-config]user@host# set icmp ip-sweep threshold 1000user@host# set icmp fragmentuser@host# set icmp largeuser@host# set icmp flood threshold 200user@host# set icmp ping-death

2. Configure the IP screening options.

[edit security screen ids-option screen-config]user@host# set ip bad-optionuser@host# set ip stream-optionuser@host# set ip spoofinguser@host# set ip strict-source-route-option

32

user@host# set ip unknown-protocoluser@host# set ip tear-drop

3. Configure the TCP screening options.

[edit security screen ids-option screen-config]user@host# set tcp syn-finuser@host# set tcp tcp-no-flaguser@host# set tcp syn-fraguser@host# set tcp port-scan threshold 1000user@host# set tcp syn-ack-ack-proxy threshold 500user@host# set tcp syn-flood alarm-threshold 500user@host# set tcp syn-flood attack-threshold 500user@host# set tcp syn-flood source-threshold 50user@host# set tcp syn-flood destination-threshold 1000user@host# set tcp syn-flood timeout 10user@host# set tcp landuser@host# set tcp winnukeuser@host# set tcp tcp-sweep threshold 1000

4. Configure the UDP screening options.

[edit security screen ids-option screen-config]user@host# set udp flood threshold 500user@host# set udp udp-sweep threshold 1000

5. Attach the IDS profile to the zone.

[edit]user@host# set security zones security-zone untrust screen screen-config

ResultsFrom configuration mode, confirm your configuration by entering the show security screen ids-optionscreen-config and showsecurity 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-configicmp {

33

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 zonessecurity-zone untrust {screen screen-config;

}

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

34

Verification

Verifying the IDS Profile for Multiple Screening Options

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

ActionEnter the show security screen ids-option screen-config Screen object status and show security zonescommand 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

35

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:

NOTE: On all SRX Series devices, the TCP synchronization flood alarm threshold value does notindicate the number of packets dropped, however the value does show the packet informationafter 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 ScreenOptions on the SRX5000Module Port Concentrator

The SRX5000 line Module Port Concentrator (SRX5K-MPC) supports Junos OS screen options. Screenoptions secure a zone by inspecting, then allowing or denying, all connection attempts that require crossingan 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 totraffic 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. Theflood protections are used to defend against SYN flood attacks, session table flood attacks, firewalldenial-of-service (DoS) attacks, and network DoS attacks.

36

The following four types of threshold-based flood protection are performed on each processor for bothIPv4 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 secondtype of TCP SYN flood protection is automatically enabled on the same zone. These two typesof protections always work together.

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

• Default action (report and drop)—Screen logging and reporting are done on an SPU, so offending packetsneed to be forwarded to the central point or SPU for this purpose. To protect SPUs from flooding, onlythe first offending packet for each screen in a zone is sent to the SPU for logging and reporting in eachsecond. 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 5000packets per second. If UDP packets come in at the rate of 20,000 per second, then about 5000 UDPpackets are forwarded to the central point or SPU each second, and the remaining packets are detectedas flooding. However, only one UDP flooding packet is sent to the SPU for logging and reporting in eachsecond. The remaining packets are dropped in the microprocessor.

• Alarm only (alarm-without-drop)—An offending packet detected by screen protection is not dropped. Itskips the rest of the screen checks and is forwarded to the central point or SPU with the screen resultcopied 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, thereare differences in the threshold values for the statistics-based screens. Table 6 on page 38 lists thestatistics-based screen options and the behavior of the screens depending on whether the device haseither IOC1 or an IOC2 card.

37

Table 6: Statistics-Based Screen Options

IOC2IOC1DescriptionScreen Option Name

On SRX5000 line deviceswith IOC2 card, there is achange in the screenconfiguration for lookup(LU) chips. There are fourLU chips in each IOC2 card.If the incoming trafficexceeds the threshold valuepps, the packets aredropped. For example, ifthe user specify thethreshold value of 1000pps, we configure 250 ppson each LU chip internally,so that the threshold valueof 1000 pps getsdistributed equally amongthe 4 LU chips. As anexpected result, the usergets the overall thresholdvalue of 1000 pps.

On SRX5000 line devices,when the IOC2 card is inservices-offloadmode, onlyone LU chip will function.If the incoming traffic rateexceeds the thresholdvalue, the packets aredropped as a result of theexpected behavior.

If the Incoming trafficexceeds the threshold pps,either the packets aredropped or an alarm israised.

Sets the ICMP floodthreshold value. The ICMPflood screen option is usedto protect against ICMPflood attacks. An ICMPflood attack typically occurswhen ICMP echo requestsuse all resources inresponding, such that validnetwork traffic can nolonger be processed.

The threshold value definesthe number of ICMPpackets per second allowedto ping the samedestination address beforethe device rejects furtherICMP packets.

ICMP flood

38






Sets the UDP floodthreshold value. The UDPflood screen option is usedto protect against UDPflood attacks. UDP floodattack occurs when anattacker sends IP packetscontaining UDP datagramswith the purpose of slowingdown the resources, suchthat valid connections canno longer be handled.

The threshold value definesthe number of UDP ppsallowed to ping the samedestination IP address/portpair. When the number ofpackets exceeds this valuewithin any 1-second period,the device generates analarm and dropssubsequent packets for theremainder of that second.

UDP flood

39





If the Incoming trafficexceeds the threshold pps,either the packets aredropped or an alarm israised..

Sets the TCP SYN floodsource threshold value. Thethreshold value defines thenumber of SYN segmentsto be received per secondbefore the device beginsdropping connectionrequests.

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

TCP SYN flood source

40






Sets the TCP SYN flooddestination threshold value.The threshold value definesthe number of SYNsegments received persecond before the devicebegins dropping connectionrequests.

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

TCP SYN flood destination

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

41

Signature-Based Screens

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

Sometimes packets received by the device are malformed or invalid, and they might cause damage to thedevice 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 screensaccording 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 maliciousingress 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 thescreen checks and is forwarded to the central point or Services Processing Unit (SPU) for logging andstatistics collection.

NOTE: OnSRX5400, SRX5600, and SRX5800 devices, the first path signature screen is performedfirst, followed by the fast path bad-inner-header screen.

42

Understanding IPv6 Support for Screens

IN THIS SECTION

IPv6 Extension Header Checking and Filtering | 43

Maximum Number of Extension Headers | 44

Bad Option Extension Headers | 45

ICMPv6 Checking and Filtering | 46

IPv6 Packet Header Checking and Filtering | 46

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

You can configure screen options to check and filter packets based on IPv6 extension headers, packetheaders, and ICMPv6 traffic. Based on your configuration, the screen can drop packets, create logs, andprovide 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 7 on page 43 lists common IPv6 extension headers and their type values.

Table 7: IPv6 Extension Headers and Type Values

Internet StandardsHeader Type ValueHeader Name

RFC 246051Authentication

RFC 246050Encapsulating Security Payload

RFC 5201139Host Identify Protocol

43

Table 7: IPv6 Extension Headers and Type Values (continued)

Internet StandardsHeader Type ValueHeader Name

RFC 246060Destination Options

• ILNP nonce option

• Home address option

• Line identification option

• Tunnel encapsulation limit option

RFC 246044Fragment

RFC 24600Hop-by-Hop Options

• CALIPSO option

• RPL option

• SFM DPD option

• Jumbo payload option

• Quick start option

• Router alert option

RFC 6275135Mobility

RFC 246059No next

RFC 246043Routing

RFC 5533140Shim6

Maximum Number of Extension Headers

You can specify the maximum number of permitted extension headers in a packet by using theipv6-extension-header-limit statement. Although the maximum number of extension headers in a packetis 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

44

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 shouldoccur 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 beendefined by subsequent RFCs. We recommend the maximum extension header number to be in the rangeof 0 through 32.

Bad Option Extension Headers

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

Table 8: Bad Option Extension Header Screening Criteria

DescriptionInternet StandardsScreening Criteria

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

RFC 2460Routing extension header isafter fragment header

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

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

• The header length must be 2.

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

RFC 2711Wrong router alertparameter

This type of traffic is screened as error packets.draft-krishnan-ipv6-hopbyhop-00More than one back-to-backpad option

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

RFC 4942Non-zero payload in PadNoption

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

RFC 4942Padding beyond the nexteight-octet boundary

45

Table 8: Bad Option Extension Header Screening Criteria (continued)

DescriptionInternet StandardsScreening Criteria

The payload length field in the IPv6 header mustbe set to zero in every packet that carries thejumbo payload option.

RFC 2675Jumbo payload withnon-zero IPv6 headerpayload

ICMPv6 Checking and Filtering

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

• Information message of unknown type—Many types of ICMPv6 information messages are defined, suchas echo request (value 128), echo reply (value 129), and router solicitation (value 133). The maximumtype 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 theIP Hop limit field has a value of 255, ICMP checksum must be valid, the ICMP code must be 0, and soon.

• Malformed ICMPv6 packet filtering—For instance, the ICMPv6 packet is too big (message type 2), thenext 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-headerstatement. Once enabled, the system verifies any incoming IPv6 packet to check if it matches any of thedefined criteria. The system then performs the specified action (drop or alarm-without-drop) on matchingpackets. Table 9 on page 46 lists key criteria that the device uses to screen packets.

Table 9: IPv6 Packet Header Screening Criteria

DescriptionInternetStandardsScreening Criteria

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

RFC 3879Deprecated site-local source anddestination addresses

The unassigned multicast address scope values aretreated as illegal.

RFC 4291Illegal multicast address scope values

46

Table 9: IPv6 Packet Header Screening Criteria (continued)

DescriptionInternetStandardsScreening Criteria

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

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

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

RFC 4291Deprecated IPv4-compatible IPv6source and destination addresses (::/96)

Addresses of the Overlay Routable Cryptographic HashIdentifiers (2001:10::/28) are used as identifiers andcannot be used for routing at the IP layer. Addresseswithin this blockmust not appear on the public Internet.

RFC 5156ORCHID source and destinationaddresses (2001:10::/28)

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

RFC 6052An IPv4 address embedded inside theIPv6 address (64:ff9b::/96) is an illegal,unacceptable IPv4 address

Understanding Screen IPv6 Tunneling Control

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

The security of tunneled packets is a major concern for service providers, because tunneled packets areeasily accessed by attackers. Numerous IPv6 transition methodologies have evolved for sending tunneledpackets through a network; however, because some of them operate on public gateways, they bypass thepolicies of the operator. This means that packet transmission is exposed to attackers. To overcome andsecure 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 userpreferences.

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, thescreen can drop packets, create logs, and provide increased statistics for IP tunneling.

47

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

An outer IPv4 headermust be Protocol 47GREEncapsulation. A GRE headermust have protocol E-type0x0800 IPv4. If these conditions are met, this packet is classified as GRE 4in4 tunnel signature.

• GRE 4in6 Tunnel: The GRE 4in6 Tunnel screenmatches the following signature: IPv6 outermain 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 headermust have protocol E-type 0x0800 IPv4. If these conditions aremet, this packet is classifiedas 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 headermust be Protocol 47GREEncapsulation. A GRE headermust have protocol E-type0x086DD IPv6 . If these conditions are met, this packet is classified as GRE 6in4 tunnel signature.

• GRE 6in6 Tunnel: The GRE 6in6 Tunnel screenmatches the following signature: IPv6 outermain 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 isclassified as GRE 6in6 tunnel signature.

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

An outer IPv4 header must be Protocol 41 IPv6 Encapsulation. An outer header source address ordestination address must be in network 192.88.99.0/24. An inner IPv6 header source address ordestination address must be in network 2002:/16. If these conditions are met, this packet is classifiedas 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 isclassified 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 outerheader | IPv6 inner header

48

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

• IPinIP 4in6 Tunnel : The IPinIP 4in6 Tunnel screen matches the following signature: | IPv6 outer mainheader | 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. Ifthese 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 outermain header | IPv6 inner header

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

• IPinIP DS-Lite Tunnel: The IPinIP DS-Lite Tunnel screen matches the following signature: | IPv6 outermain 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. Aninner IPv4 source address or destination address must be in 192.0.0.0/29 network. If these conditionsare 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 mainheader | 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 classifiedas 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 IPv4header must be Version 4.

• IPinUDPTeredoTunnel: The IPinUDPTeredo 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 destinationport must be 3544. An inner IPv6 header source address or destination address must be in network2001:0000:/32.

• IP Tunnel Bad Inner-Header Check: The Bad Inner Header Tunnel screen checks the tunnel traffic innerheader 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.

49

• 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 innerIP(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 ascreen and is not in the first fragment, then checking is not performed except the parts of the tunnelencapsulation that are included in the first fragment. Length checks are performed on first fragmentpackets using the actual packet buffer length, but the length checks are ignored because the innerheader is larger than the outer header.

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

• 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 headersignatures, 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, thebad-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 vSRXinstances., the fast-path bad-inner-header screen is always performed first, followed by the firstpath signature screen.

Starting with Junos OS Release 12.3X48-D10 and Junos OS Release 17.3R1, the syslog messagesRT_SCREEN_IP and RT_SCREEN_IP_LS for the IP tunneling screen have been updated. The updatedmessages include the tunnel screen attacks and log-without-drop criteria. The following list illustratessome 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 GRE6in6! source: 1212::12, destination: 1111::11, zone name: untrust, interfacename: ge-0/0/1.0, action: drop

50

• 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, zonename: 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, zonename: untrust, interface name: ge-0/0/1.0, action: drop

Example: Improving Tunnel Traffic Security with IP Tunneling ScreenOptions

IN THIS SECTION

Requirements | 51

Overview | 52

Configuration | 52

Verification | 57

This example shows how to configure the tunnel screens to enable the screens to control, allow, or blockthe 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:

51

• Understand the IPv6 Tunneling control. See “Understanding Screen IPv6 Tunneling Control” on page 47.

Overview

You can configure the following IP tunneling screen options to check and filter packets, based on IPv6extension headers, packet headers, and bad-inner-header IPv6 or IPv4 address validation. Based on yourconfiguration, 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 6over4 Tunnel

• IPinIP 6to4relay Tunnel

• IPinIP ISATAP Tunnel

• IPinIP DS-Lite Tunnel

• Bad Inner Header Tunnel

Configuration

IN THIS SECTION

Configuring GRE Tunnel Screens | 53

Configuring an IPinUDP Teredo Tunnel Screen | 53

Configuring an IPinIP Tunnel Screen | 54

Configuring a Bad-Inner-Header Tunnel Screen | 55

Results | 56

52

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

Configuring GRE Tunnel Screens


set security screen ids-option screen1 ip tunnel gre gre-4in4set security screen ids-option screen1 ip tunnel gre gre-4in6set security screen ids-option screen1 ip tunnel gre gre-6in4set security screen ids-option screen1 ip tunnel gre gre-6in6set security zones security-zone untrust screen screen1

Step-by-Step ProcedureThe following example requires you to navigate various levels in the configuration hierarchy. For instructionson 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 consistencyand validate the signature type screen.

[edit security screen ids-option screen1 ip tunnel gre]user@host# set gre-4in4user@host# set gre-4in6user@host# set gre-6in4user@host# set gre gre-6in6

2. Configure the screens in the security zones.

user@host#set security zones security-zone untrust screen screen1

Configuring an IPinUDP Teredo Tunnel Screen


set security screen ids-option screen1 ip tunnel ip-in-udp teredo

53

set security zones security-zone untrust screen screen1


To configure an IPinUDP Teredo tunnel screen:

1. Configure an IPinUDP Teredo tunnel screen to check the tunnel traffic inner header information forconsistency and validate the signature type screen.

[edit security screen ids-option screen1 ip tunnel]user@host# set ip-in-udp teredo


user@host# set security zones security-zone untrust screen screen1

Configuring an IPinIP Tunnel Screen


set security screen ids-option screen1 ip tunnel ipip dsliteset security screen ids-option screen1 ip tunnel ipip ipip-4in4set security screen ids-option screen1 ip tunnel ipip ipip-4in6set security screen ids-option screen1 ip tunnel ipip ipip-6in4set security screen ids-option screen1 ip tunnel ipip ipip-6in6set security screen ids-option screen1 ip tunnel ipip ipip-6over4set security screen ids-option screen1 ip tunnel ipip ipip-6to4relayset security screen ids-option screen1 ip tunnel ipip isatapset security zones security-zone untrust screen screen1

Step-by-Step Procedure

54

The following example requires you to navigate various levels in the configuration hierarchy. For instructionson 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 consistencyand validate the signature type screen.

[edit security screen ids-option screen1 ip tunnel ipip]user@host# set dsliteuser@host# set ipip-4in4user@host# set ipip-4in6user@host# set ipip-6in4user@host# set ipip-6in6user@host# set ipip-6over4user@host# set ipip-6to4relayuser@host# set ipip-isatap



Configuring a Bad-Inner-Header Tunnel Screen


set security screen ids-option screen1 ip tunnel bad-inner-headerset security zones security-zone untrust screen screen1

Step-by-Step ProcedureThe 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 forconsistency.

[edit security screen ids-option screen1 ip tunnel]user@host# set bad-inner-header

55



Results

From configuration mode, confirm your configuration by entering the show security screen and showsecurity screen statistics zone untrust ip tunnel commands. If the output does not display the intendedconfiguration, 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 otherconfiguration 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;

}}

}


56

Verification

IN THIS SECTION

Verifying the Security Screen Configuration | 57

Verifying IP Tunnel Screens in the Security Zones | 58

Confirm that the configuration is working properly.

Verifying the Security Screen Configuration

PurposeDisplay the configuration information about the security screen.

ActionFrom 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 IPinUDP Teredo enabled

IP Tunnel IPIP 6to4 Relay enabled

IP Tunnel IPIP 6in4 enabled

IP Tunnel IPIP 6over4 enabled




IP Tunnel IPIP ISATAP enabled

IP Tunnel IPIP DS-Lite enabled

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

57

Verifying IP Tunnel Screens in the Security Zones

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

ActionFrom 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 IPIP 6to4 relay 0

IP tunnel IPIP 6in4 0

IP tunnel IPIP 6over4 0




IP tunnel IPIP ISATAP 0

IP tunnel IPIP DS-Lite 0

IP tunnel IPinUDP Teredo 0

IP tunnel bad inner header 0

MeaningThe show security screen statistics zone untrust ip tunnel command displays the IP tunnel screen statisticssummary.

58

Release History Table

DescriptionRelease

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 highernumber of connections per second (CPS).

15.1X49-D30

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

15.1X49-D20

Starting with Junos OS Release 12.3X48-D10 and Junos OS Release 17.3R1, the syslogmessages RT_SCREEN_IP and RT_SCREEN_IP_LS for the IP tunneling screen have beenupdated.

12.3X48-D10

59

2CHAPTER

Denial of Service Attacks

DoS Attack Overview | 63


Network DoS Attacks | 76


DoS Attack Overview

The intent of a denial-of-service (DoS) attack is to overwhelm the targeted victim with a tremendousamount of bogus traffic so that the victim becomes so preoccupied processing the bogus traffic thatlegitimate traffic cannot be processed. The target can be the firewall, the network resources to which thefirewall controls access, or the specific hardware platform or operating system of an individual host.

If a DoS attack originates from multiple source addresses, it is known as a distributed denial-of-service(DDoS) attack. Typically, the source address of a DoS attack is spoofed. The source addresses in a DDoSattack might be spoofed, or the actual addresses of compromised hosts might be used as “zombie agents”to launch the attack.

The device can defend itself and the resources it protects from DoS and DDoS attacks.

Firewall DoS Attacks Overview

The intent of a denial-of-service (DoS) attack is to overwhelm the targeted victim with a tremendousamount of bogus traffic so that the victim becomes so preoccupied processing the bogus traffic thatlegitimate traffic cannot be processed.

If attackers discover the presence of the Juniper Networks firewall, theymight launch a DoS attack againstit instead of the network behind it. A successful DoS attack against a firewall amounts to a successful DoSattack against the protected network in that it thwarts attempts of legitimate traffic to traverse the firewall.

An attacker might use session table floods and SYN-ACK-ACK proxy floods to fill up the session table ofJunos OS and thereby produce a DoS.

Understanding Firewall Filters on the SRX5000Module Port Concentrator

The SRX5000 line Module Port Concentrator (SRX5K-MPC) for the SRX5400, SRX5600, and SRX5800supports a firewall filter to provide filter based forwarding and packet filtering at logical interfaces includingthe chassis loopback interface. A firewall filter is used to secure networks, to protect Routing Engines andPacket Forwarding Engines, and to ensure class of service (CoS).

The firewall filter provides:

• Filter-based forwarding at logical interfaces

• Protection of a Routing Engine from DoS attacks

• Blocking of certain types of packets to reach a Routing Engine and packet counter

63

The firewall filter examines packets and performs actions according to the configured filter policy. Thepolicy is composed of match conditions and actions. The match conditions cover various fields of Layer 3packet and Layer 4 header information. In association with the match conditions, various actions aredefined in the firewall filter policy, and these actions include accept, discard, log counter, and so on.

After configuring the firewall filter, you can apply a logical interface to the firewall filter in the ingress oregress, or in both directions. All packets passing through the logical interface are checked by the firewallfilter. As part of the firewall filter configuration, a policer is defined and applied to the logical interface. Apolicer restricts the traffic bandwidth at the logical interface.

NOTE: Firewall filtering on an SRX5K-MPC does not support aggregated Ethernet interfaces.

NOTE: On SRX5400, SRX5600 and SRX5800 devices with an SRX5K-MPC, applying a policerat the loopback (lo0) interface ensures that the Packet Forwarding Engine discards certain typesof packets and prevents them from reaching the Routing Engine.

RELATED DOCUMENTATION



Firewall DoS Attacks

IN THIS SECTION

Understanding Session Table Flood Attacks | 65

Understanding Source-Based Session Limits | 65

Example: Setting Source-Based Session Limits | 66

Understanding Destination-Based Session Limits | 69

Example: Setting Destination-Based Session Limits | 70

Understanding SYN-ACK-ACK Proxy Flood Attacks | 73

Protecting Your Network Against a SYN-ACK-ACK Proxy Flood Attack | 73

64

DoS attack protection leverages stateful inspection to look for and then allow or deny all connectionattempts that require crossing an interface on their way to and from the intended destination, For moreinformation, see the following topics:

Understanding Session Table Flood Attacks

A successful DoS attack overwhelms its victim with such a massive barrage of false simulated traffic thatit becomes unable to process legitimate connection requests. DoS attacks can take many forms—SYNflood, SYN-ACK-ACK flood, UDP flood, ICMP flood, and so on—but they all seek the same objective, whichis to fill up their victim's session table.

When the session table is full, that host cannot create any new sessions and begins rejecting new connectionrequests. The source-based session limits screen option and the destination-based session limit screenoption help mitigate such attacks.

Understanding Source-Based Session Limits

In addition to limiting the number of concurrent sessions from the same source IP address, you can alsolimit the number of concurrent sessions to the same destination IP address. One benefit of setting asource-based session limit is that it can stem an attack such as the Nimda virus (which is actually both avirus and a worm) that infects a server and then begins generating massive amounts of traffic from thatserver. Because all the virus-generated traffic originates from the same IP address, a source-based sessionlimit ensures that the firewall can curb such excessive amounts of traffic. See Figure 1 on page 65.

Figure 1: Limiting Sessions Based on Source IP Address

Another benefit of source-based session limiting is that it can mitigate attempts to fill up the firewall'ssession table if all the connection attempts originate from the same source IP address.

65

Determiningwhat constitutes an acceptable number of connection requests requires a period of observationand analysis to establish a baseline for typical traffic flows. You also need to consider themaximum numberof concurrent sessions required to fill up the session table of the particular Juniper Networks platform youare using. To see the maximum number of sessions that your session table supports, use the CLI commandshow security flow session summary, and then look at the last line in the output, which lists the numberof current (allocated) sessions, the maximum number of sessions, and the number of failed sessionallocations:

userhost# show security flow session summaryUnicast-sessions: 0

Multicast-sessions: 0

Failed-sessions: 0

Sessions-in-use: 0

Valid sessions: 0

Pending sessions: 0

Invalidated sessions: 0

Sessions in other states: 0

Maximum-sessions: 2097152

The default maximum for source-based session limits is 128 concurrent sessions, a value that might needadjustment to suit the needs of your network environment and the platform.

NOTE: Junos OS supports source-based session limits for both IPv4 and IPv6 traffic.

Example: Setting Source-Based Session Limits

IN THIS SECTION

Requirements | 67

Overview | 67

Configuration | 67

Verification | 68

This example shows how to limit the amount of sessions based on source IP.

66

Requirements


Overview

The following example shows how to limit the number of sessions that any one server in the DMZ and inzone a can initiate. Because the DMZ contains only webservers, none of which should initiate traffic, youset the source-session limit at the lowest possible value, which is one session. On the other hand, zone acontains personal computers, servers, printers, and so on, many of which do initiate traffic. For zone a,you set the source-session limit to a maximum of 80 concurrent sessions.

Configuration


set security screen ids-option 1-limit-session limit-session source-ip-based 1set security zones security-zone dmz screen 1-limit-sessionset security screen ids-option 80-limit-session limit-session source-ip-based 80set security zones security-zone zone_a screen 80-limit-session


1. Specify the number of concurrent sessions based on source IP for the DMZ zone.

[edit security]user@host# set screen ids-option 1-limit-session limit-session source-ip-based 1

2. Set the security zone for the DMZ to the configuration limit.

[edit security]user@host# set zones security-zone dmz screen 1-limit-session

3. Specify the number of concurrent sessions based on source IP for the zone a zone.

[edit security]user@host# set screen ids-option 80-limit-session limit-session source-ip-based 80

67

4. Set the security zone for zone a to the configuration limit.

[edit security]user@host# set zones security-zone zone_a screen 80-limit-session

ResultsFrom configuration mode, confirm your configuration by entering the show security screen and showsecurity zones commands. If the output does not display the intended configuration, repeat the configurationinstructions in this example to correct it.

[edit]user@host# show security screenids-option 1-limit-session {limit-session {source-ip-based 1;}

}ids-option 80-limit-session {limit-session {source-ip-based 80;}

}

[edit]user@host# show security zonessecurity-zone dmz {screen 1-limit-session;

}security-zone zone_a {screen 80-limit-session;

}


Verification

Verifying Source-Based Session Limits

PurposeVerify source-based session limits.

Action

68

Enter the showsecurity screen ids-option1-limit-session , showsecurity screen ids-option80-limit-session,and show security zones commands from operational mode.

user@host> show security screen ids-option 1-limit-sessionScreen object status:

Name Value

Session source limit threshold 1

user@host> show security screen ids-option 80-limit-sessionScreen object status:

Name Value


user@host> show security zonesSecurity zone: dmz



Screen: 1-limit-session

Interfaces bound: 0

Interfaces:

MeaningThe sample output shows the source session limit values for DMZ zone and zone a.

Understanding Destination-Based Session Limits

In addition to limiting the number of concurrent sessions from the same source IP address, you can alsolimit the number of concurrent sessions to the same destination IP address. A wily attacker can launch adistributed denial-of-service (DDoS) attack. In a DDoS attack, themalicious traffic can come from hundredsof hosts, known as “zombie agents,” that are surreptitiously under the control of an attacker. In additionto the SYN, UDP, and ICMP flood detection and prevention screen options, setting a destination-basedsession limit can ensure that Junos OS allows only an acceptable number of concurrent connectionrequests—no matter what the source—to reach any one host. See Figure 2 on page 70.

69

Figure 2: Distributed DOS Attack

The default maximum for destination-based session limits is 128 concurrent sessions, a value that mightneed adjustment to suit the needs of your network environment and the platform.

Example: Setting Destination-Based Session Limits

IN THIS SECTION

Requirements | 71

Overview | 71

Configuration | 71

Verification | 72

This example shows how to set the destination-based session limits.

70

Requirements


Overview

In this example, you limit the amount of traffic to a webserver at 1.2.2.5. The server is in the DMZ. Theexample assumes that after observing the traffic flow from the external zone to this server for a month,you have determined that the average number of concurrent sessions it receives is 2000. Also, you setthe new session limit at 2000 concurrent sessions. Although traffic spikes might sometimes exceed thatlimit, the example assumes that you are opting for firewall security over occasional server inaccessibility.

Configuration


set security screen ids-option 2000-limit-session limit-session destination-ip-based 2000set security zones security-zone external_zone screen 2000-limit-session

Step-by-Step ProcedureThe following example requires you to navigate various levels in the configuration hierarchy. To set thedestination-based session limits:

1. Specify the number of concurrent sessions.

[edit]user@host# set security screen ids-option 2000-limit-session limit-session destination-ip-based 2000

2. Set the security zone for the external zone.

[edit]user@host# set security zones security-zone external_zone screen 2000-limit-session


71

[edit]user@host# show security screenids-option 2000-limit-session {limit-session {destination-ip-based 2000;}

}

[edit]user@host# show security zonessecurity-zone external_zone {screen 2000-limit-session;

}


Verification

Verifying Destination-Based Session Limits

PurposeVerify destination-based session limits.

ActionEnter the show security screen ids-option 2000-limit-session and show security zones commands fromoperational mode.

user@host> show security screen ids-option 2000-limit-sessionnode0:

--------------------------------------------------------------------------


Name Value

Session destination limit threshold 2000

Value

user@host> show security zonesSecurity zone: external_zone



Screen: 2000-limit-session

72

Interfaces bound: 0

Interfaces:

MeaningThe sample output shows the destination session limit values for external zone.

Understanding SYN-ACK-ACK Proxy Flood Attacks

When an authentication user initiates a Telnet or an FTP connection, the user sends a SYN segment tothe Telnet or FTP server. Junos OS intercepts the SYN segment, creates an entry in its session table, andproxies a SYN-ACK segment to the user. The user then replies with an ACK segment. At this point, theinitial three-way handshake is complete. Junos OS sends a login prompt to the user. If the user, withmalicious intent, does not log in but instead continues initiating SYN-ACK-ACK sessions, the firewallsession table can fill up to the point where the device begins rejecting legitimate connection requests.

To prevent such an attack, you can enable the SYN-ACK-ACK proxy protection screen option. After thenumber of connections from the same IP address reaches the SYN-ACK-ACK proxy threshold, Junos OSrejects further connection requests from that IP address. By default, the threshold is 512 connectionsfrom any single IP address. You can change this threshold (to any number between 1 and 250,000) tobetter suit the requirements of your network environment.

NOTE: Junos OS supports SYN-ACK-ACK proxy protection for both IPv4 and IPv6 addresses.

Protecting Your Network Against a SYN-ACK-ACK Proxy Flood Attack

IN THIS SECTION

Requirements | 74

Overview | 74

Configuration | 74

Verification | 75

73

This example shows how to protect your network against a SYN-ACK-ACK proxy flood attack.

Requirements


Overview

In this example, you enable protection against a SYN-ACK-ACK proxy flood. The value unit is connectionsper source address. The default value is 512 connections from any single address.

Configuration


set security screen ids-option 1000-syn-ack-ack-proxy tcp syn-ack-ack-proxy threshold 1000set security zones security-zone zone screen 1000-syn-ack-ack-proxy

Step-by-Step ProcedureThe following example requires you to navigate various levels in the configuration hierarchy. To protectagainst a SYN-ACK-ACK proxy flood attack:

1. Specify the source session limits.

[edit]user@host# set security screen ids-option 1000-syn-ack-ack-proxy tcp syn-ack-ack-proxy threshold 1000

2. Set the security zone for zone screen.

[edit]user@host# set security zones security-zone zone screen 1000-syn-ack-ack-proxy


74

[edit]user@host# show security screenids-option 1000-syn-ack-ack-proxy {tcp {syn-ack-ack-proxy threshold 1000;}

}

[edit]user@host# show security zonessecurity-zone zone {screen 1000-syn-ack-ack-proxy;

}


Verification

Verifying SYN-ACK-ACK Proxy Flood Attack

PurposeVerify SYN-ACK-ACK proxy flood attack.

ActionEnter the show security screen ids-option 1000-syn-ack-ack-proxy and show security zones commandsfrom operational mode.

user@host> show security screen ids-option 1000-syn-ack-ack-proxynode0:

--------------------------------------------------------------------------


Name Value

TCP SYN-ACK-ACK proxy threshold 1000

user@host> show security zonesSecurity zone: zone



Screen: 1000-syn-ack-ack-proxy

Interfaces bound: 0

Interfaces:

75

MeaningThe sample output shows that there is no attack from SYN-ACK-ACK-proxy flood.



Network DoS Attacks

IN THIS SECTION


Understanding SYN Flood Attacks | 77

Protecting Your Network Against SYN Flood Attacks by Enabling SYN Flood Protection | 81

Example: Enabling SYN Flood Protection for Webservers in the DMZ | 84

Understanding Whitelists for SYN Flood Screens | 91

Example: Configuring Whitelists for SYN Flood Screens | 92

Understanding Whitelists for UDP Flood Screens | 94

Example: Configuring Whitelists for UDP Flood Screens | 94

Understanding SYN Cookie Protection | 97

Detecting and Protecting YourNetwork Against SYNFloodAttacks by Enabling SYNCookie Protection | 101

Understanding ICMP Flood Attacks | 104

Protecting Your Network Against ICMP Flood Attacks by Enabling ICMP Flood Protection | 106

Understanding UDP Flood Attacks | 108

Protecting Your Network Against UDP Flood Attacks by Enabling UDP Flood Protection | 109

Understanding Land Attacks | 112

Protecting Your Network Against Land Attacks by Enabling Land Attack Protection | 113

A network attack consists of three major stages. In the first stage, the attacker performs reconnaissanceon the target network. This reconnaissance might consist of many different kinds of network probes, Formore information, see the following topics:

76

Network DoS Attacks Overview

A denial-of-service (DoS) attack directed against one or more network resources floods the target withan overwhelming number of SYN, ICMP, orUDPpackets orwith an overwhelming number of SYN fragments.

Depending on the attackers' purpose and the extent and success of previous intelligence gathering efforts,the attackers might single out a specific host, such as a device or server or they might aim at random hostsacross the targeted network. Either approach has the potential of upsetting service to a single host or tothe entire network, depending on how critical the role of the victim is to the rest of the network.

Understanding SYN Flood Attacks

IN THIS SECTION

SYN Flood Protection | 78

SYN Flood Options | 79

A SYN flood occurs when a host becomes so overwhelmed by SYN segments initiating incompleteconnection requests that it can no longer process legitimate connection requests.

Two hosts establish a TCP connection with a triple exchange of packets known as a three-way handshake:A sends a SYN segment to B; B responds with a SYN/ACK segment; and A responds with an ACK segment.A SYN flood attack inundates a site with SYN segments containing forged (spoofed) IP source addresseswith nonexistent or unreachable addresses. B responds with SYN/ACK segments to these addresses andthen waits for responding ACK segments. Because the SYN/ACK segments are sent to nonexistent orunreachable IP addresses, they never elicit responses and eventually time out. See Figure 3 on page 78.

77

Figure 3: SYN Flood Attack

By flooding a host with incomplete TCP connections, the attacker eventually fills the memory buffer ofthe victim. Once this buffer is full, the host can no longer process new TCP connection requests. The floodmight even damage the victim's operating system. Either way, the attack disables the victim and its normaloperations.

This topic includes the following sections:

SYN Flood Protection

Junos OS can impose a limit on the number of SYN segments permitted to pass through the firewall persecond. You can base the attack threshold on the destination address and ingress interface port, thedestination address only, or the source address only. When the number of SYN segments per secondexceeds the set threshold, Junos OS will either start proxying incoming SYN segments, replying withSYN/ACK segments and storing the incomplete connection requests in a connection queue, or it will dropthe packets.

SYN proxying only happens when a destination address and ingress interface port attack threshold isexceeded. If a destination address or source address threshold is exceeded, additional packets are simplydropped.

In Figure 4 on page 79, the SYN attack threshold for a destination address and ingress interface port hasbeen exceeded and Junos OS has started proxying incoming SYN segments. The incomplete connectionrequests remain in the queue until the connection is completed or the request times out.

78

Figure 4: Proxying SYN Segments

SYN Flood Options

You can set the following parameters for proxying uncompleted TCP connection requests:

• Attack Threshold—This option allows you to set the number of SYN segments (that is, TCP segmentswith the SYN flag set) to the same destination address per second required to activate the SYN proxyingmechanism. Although you can set the threshold to any number, you need to know the normal trafficpatterns at your site to set an appropriate threshold for it. For example, if it is an e-business site thatnormally gets 20,000 SYN segments per second, you might want to set the threshold to 30,000 persecond. If a smaller site normally gets 20 SYN segments per second, you might consider setting thethreshold to 40.

• Alarm Threshold—This option allows you to set the number of proxied, half-complete TCP connectionrequests per second after which Junos OS enters an alarm in the event log. The value you set for analarm threshold triggers an alarm when the number of proxied, half-completed connection requests tothe same destination address per second exceeds that value. For example, if you set the SYN attackthreshold at 2000 SYN segments per second and the alarm at 1000, then a total of 3000 SYN segmentsto the same destination address per second is required to trigger an alarm entry in the log.

79

For each SYN segment to the same destination address in excess of the alarm threshold, the attackdetection module generates a message. At the end of the second, the logging module compresses allsimilar messages into a single log entry that indicates how many SYN segments to the same destinationaddress and port number arrived after exceeding the alarm threshold. If the attack persists beyond thefirst second, the event log enters an alarm every second until the attack stops.

• Source Threshold—This option allows you to specify the number of SYN segments received per secondfrom a single source IP address—regardless of the destination IP address—before Junos OS beginsdropping connection requests from that source.

Tracking a SYN flood by source address uses different detection parameters from tracking a SYN floodby destination address. When you set a SYN attack threshold and a source threshold, you put both thebasic SYN flood protection mechanism and the source-based SYN flood tracking mechanism in effect.

• Destination Threshold—This option allows you to specify the number of SYN segments received persecond for a single destination IP address before Junos OS begins dropping connection requests to thatdestination. If a protected host runs multiple services, you might want to set a threshold based ondestination IP address only—regardless of the destination port number.

When you set a SYN attack threshold and a destination threshold, you put both the basic SYN floodprotection mechanism and the destination-based SYN flood tracking mechanism in effect.

Consider a case where Junos OS has policies permitting FTP requests and HTTP requests to the sameIP address. If the SYN flood attack threshold is 1000 packets per second (pps) and an attacker sends999 FTP packets and 999 HTTP pps, Junos OS treats both FTP and HTTP packets with the samedestination address as members of a single set and rejects the 1001st packet—FTP or HTTP—to thatdestination.

• Timeout—This option allows you to set themaximum length of time before a half-completed connectionis dropped from the queue. The default is 20 seconds, and you can set the timeout from 1–50 seconds.You might try decreasing the timeout value to a shorter length until you begin to see any droppedconnections during normal traffic conditions. Twenty seconds is a very conservative timeout for athree-way handshake ACK response.

NOTE: Junos OS supports SYN flood protection for both IPv4 and IPv6 traffic.

80

ProtectingYourNetworkAgainst SYNFloodAttacks by Enabling SYNFloodProtection

IN THIS SECTION

Requirements | 81

Overview | 81

Configuration | 81

Verification | 83

This example shows how to protect your network against SYN flood attacks by enabling SYN floodprotection.

Requirements


Overview

In this example, you enable the zone-syn-flood protection screen option and set the timeout value to 20.You also specify the zone where the flood might originate.

Configuration


set security screen ids-option zone-syn-flood tcp syn-flood source-threshold 10000set security screen ids-option zone-syn-flood tcp syn-flood destination-threshold 10000set security zones security-zone untrust screen zone-syn-flood


81

The following example requires you to navigate various levels in the configuration hierarchy. For instructionson how to do that, see Using the CLI Editor in ConfigurationMode in the CLI User Guide. To enable SYN floodprotection:

1. Specify the screen object name.

[edit]user@host# set security screen ids-option zone-syn-flood tcp syn-flood source-threshold 10000user@host# set security screen ids-option zone-syn-flood tcp syn-flood destination-threshold 10000

2. Set the security zone for the zone screen.

[edit]user@host# set security zones security-zone untrust screen zone-syn-flood


[edit]user@host# show security screenids-option zone-syn-flood {tcp {syn-flood {source-threshold 10000;destination-threshold 10000;timeout 20;

}}

}

[edit]user@host# show security zonessecurity-zone untrust {screen zone-syn-flood;interfaces {ge-0/0/1.0;

}}

82


Verification

Verifying SYN Flood Protection

PurposeVerify SYN flood protection.

ActionEnter the show security screen ids-option zone-syn-flood and show security zones commands fromoperational mode.

user@host> show security screen ids-option zone-syn-floodnode0:

--------------------------------------------------------------------------


Name Value






user@host> show security zonesSecurity zone: untrust



Screen: zone-syn-flood

Interfaces bound: 1

Interfaces:

ge-0/0/1.0

MeaningThe sample output shows that SYN flood protection is enabled with source and destination threshold.

83

Example: Enabling SYN Flood Protection for Webservers in the DMZ

IN THIS SECTION

Requirements | 84

Overview | 84

Configuration | 87

Verification | 91

This example shows how to enable SYN flood protection for webservers in the DMZ.

Requirements


Overview

This example shows how to protect four webservers in the DMZ from SYN flood attacks originating in theexternal zone, by enabling the SYN flood protection screen option for the external zone. SeeFigure 5 on page 85.

NOTE: We recommend that you augment the SYN flood protection that JunosOS provideswithdevice-level SYN flood protection on eachwebserver. In this example, thewebservers are runningUNIX, which also provides some SYN flood defenses, such as adjusting the length of theconnection request queue and changing the timeout period for incomplete connection requests.

84

Figure 5: Device-Level SYN Flood Protection

Untrustzone

DMZzone

Webservers

Internet

Firewall

SYN floodHTTP

ethernet21.2.2.1/24

ethernet31.1.1.1/24

1.2.2.10 1.2.2.20 1.2.2.30 1.2.2.40 ex_S

YN

_flo

od

SRX Series device

To configure the SYN flood protection parameters with appropriate values for your network, you mustfirst establish a baseline of typical traffic flows. For example, for one week, you run a sniffer onethernet3—the interface bound to zone_external—tomonitor the number of new TCP connection requestsarriving every second for the four webservers in the DMZ. Your analysis of the data accumulated fromone week of monitoring produces the following statistics:

• Average number of new connection requests per server: 250 per second

• Average peak number of new connection requests per server: 500 per second

85

NOTE: A sniffer is a network-analyzing device that captures packets on the network segmentto which you attach it. Most sniffers allow you to define filters to collect only the type of trafficthat interests you. Later, you can view and evaluate the accumulated information. In this example,you want the sniffer to collect all TCP packets with the SYN flag set arriving at ethernet3 anddestined for one of the four webservers in the DMZ. You might want to continue running thesniffer at regular intervals to see whether there are traffic patterns based on the time of day,day of the week, time of the month, or season of the year. For example, in some organizations,traffic might increase dramatically during a critical event. Significant changes probably warrantadjusting the various thresholds.

Based on this information, you set the following SYN flood protection parameters for zone_external asshown in Table 10 on page 86.

Table 10: SYN Flood Protection Parameters

Reason for Each ValueValueParameter

This is 25% higher than the average peak number of new connectionrequests per second per server, which is unusual for this networkenvironment. When the number of SYN packets per second for anyone of the four webservers exceeds this number, the device beginsproxying new connection requests to that server. (In other words,beginning with the 626th SYN packet to the same destination addressin one second, the device begins proxying connection requests to thataddress.)

625 ppsAttack threshold

When the device proxies 251 new connection requests in one second,it makes an alarm entry in the event log. By setting the alarm thresholdsomewhat higher than the attack threshold, you can avoid alarm entriesfor traffic spikes that only slightly exceed the attack threshold.

250 ppsAlarm threshold

86

Table 10: SYN Flood Protection Parameters (continued)

Reason for Each ValueValueParameter

When you set a source threshold, the device tracks the source IPaddress of SYN packets, regardless of the destination address. (Notethat this source-based tracking is separate from the tracking of SYNpackets based on destination address, which constitutes the basic SYNflood protection mechanism.)

In the oneweek of monitoring activity, you observed that nomore than1/25 of new connection requests for all servers came from any onesource within a one-second interval. Therefore, connection requestsexceeding this threshold are unusual and provide sufficient cause forthe device to execute its proxying mechanism. (Note that 25 pps is1/25 of the attack threshold, which is 625 pps.)

If the device tracks 25 SYN packets from the same source IP address,then, beginning with the 26th packet, it rejects all further SYN packetsfrom that source for the remainder of that second and for the nextsecond as well.

25 ppsSource threshold

When you set a destination threshold, the device runs a separatetracking of only the destination IP address, regardless of the destinationport number. Because the four webservers receive only HTTP traffic(destination port 80)—no traffic to any other destination port numberreaches them—setting another destination threshold offers no additionaladvantage.

4000 ppsDestinationthreshold

The default value of 20 seconds is a reasonable length of time to holdincomplete connection requests.

20 secondsTimeout

Configuration


set interfaces ge-0/0/0 unit 0 family inet address 1.2.2.1/24set interfaces fe-1/0/0 unit 0 family inet address 1.1.1.1/24set security zones security-zone zone_dmz interfaces ge-0/0/0.0set security zones security-zone zone_external interfaces fe-1/0/0.0set security zones security-zone zone_dmz address-book address ws1 1.2.2.10/32

87

set security zones security-zone zone_dmz address-book address ws2 1.2.2.20/32set security zones security-zone zone_dmz address-book address ws3 1.2.2.30/32set security zones security-zone zone_dmz address-book address ws4 1.2.2.40/32set security zones security-zone zone_dmz address-book address-set web_servers address ws1set security zones security-zone zone_dmz address-book address-set web_servers address ws2set security zones security-zone zone_dmz address-book address-set web_servers address ws3set security zones security-zone zone_dmz address-book address-set web_servers address ws4set security policies from-zone zone_external to-zone zone_dmz policy id_1 match source-address anydestination-address web_servers application junos-http

set security policies from-zone zone_external to-zone zone_dmz policy id_1 then permitset security screen ids-option zone_external-syn-flood tcp syn-flood alarm-threshold 250 attack-threshold 625source-threshold 25 timeout 20

set security zones security-zone zone_external screen zone_external-syn-flood

Step-by-Step ProcedureTo configure SYN flood protection parameters:

1. Set interfaces.

[edit]user@host# set interfaces ge-0/0/0 unit 0 family inet address 1.2.2.1/24user@host# set interfaces fe-1/0/0 unit 0 family inet address 1.1.1.1/24user@host# set security zones security-zone zone_dmz interfaces ge-0/0/0.0user@host# set security zones security-zone zone_external interfaces fe-1/0/0.0

2. Define addresses.

[edit]user@host# set security zones security-zone zone_dmz address-book address ws1 1.2.2.10/32user@host# set security zones security-zone zone_dmz address-book address ws2 1.2.2.20/32user@host# set security zones security-zone zone_dmz address-book address ws3 1.2.2.30/32user@host# set security zones security-zone zone_dmz address-book address ws4 1.2.2.40/32user@host# set security zones security-zone zone_dmz address-book address-setweb_servers addressws1user@host# set security zones security-zone zone_dmz address-book address-setweb_servers addressws2user@host# set security zones security-zone zone_dmz address-book address-setweb_servers addressws3user@host# set security zones security-zone zone_dmz address-book address-setweb_servers addressws4

3. Configure the policy.

[edit]

88

user@host# set security policies from-zone zone_external to-zone zone_dmzpolicy id_1match source-addressany

user@host# set security policies from-zone zone_external to-zone zone_dmz policy id_1 matchdestination-address web_servers

user@host# set security policies from-zone zone_external to-zone zone_dmz policy id_1 match applicationjunos-http

user@host# set security policies from-zone zone_external to-zone zone_dmz policy id_1 then permit

4. Configure the screen options.

[edit]user@host# set security screen ids-option zone_external-syn-flood tcp syn-flood alarm-threshold 250user@host# set security screen ids-option zone_external-syn-flood tcp syn-flood attack-threshold 625user@host# set security screen ids-option zone_external-syn-flood tcp syn-flood source-threshold 25user@host# set security screen ids-option zone_external-syn-flood tcp syn-flood timeout 20user@host# set security zones security-zone zone_external screen zone_external-syn-flood

ResultsFrom configuration mode, confirm your configuration by entering the show interfaces, show securityzones, show security policies, and show security screen commands. If the output does not display theintended configuration, repeat the configuration instructions in this example to correct it.

For brevity, this show command 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 interfacesge-0/0/0 {unit 0 {family inet {address 1.2.2.1/24;}

}}fe-1/0/0 {unit 0 {family inet {address 1.1.1.1/24;}

}}...

89

[edit]user@host# show security zones...security-zone zone_dmz {

address-book {address ws1 1.2.2.10/32;address ws2 1.2.2.20/32;address ws3 1.2.2.30/32;address ws4 1.2.2.40/32;address-set web_servers {address ws1;address ws2;address ws3;address ws4;}

}interfaces {ge-0/0/0.0;}

}security-zone zone_external {screen zone_external-syn-flood;interfaces {fe-1/0/0.0;

}}[edit]user@host# show security policiesfrom-zone zone_external to-zone zone_dmz {policy id_1 {

match {source-address any;destination-address web_servers;application junos-http;}

then {permit;}}

}[edit]user@host# show security screen

...ids-option zone_external-syn-flood {

90

tcp {syn-flood {alarm-threshold 250;attack-threshold 625;source-threshold 25;timeout 20;

}}

}


Verification

Verifying SYN Flood Protection for Webservers in the DMZ

PurposeVerify SYN flood protection for webservers in the DMZ.

ActionFrom operational mode, enter the show interfaces, show security zones, show security policies, and showsecurity screen ids-option zone_external-syn-flood commands.

Understanding Whitelists for SYN Flood Screens

Junos OS provides the administrative option to configure a whitelist of trusted IP addresses to which theSYN flood screen will not reply with a SYN/ACK. Instead, the SYN packets from the source addresses orto the destination addresses in the list are allowed to bypass the SYN cookie and SYN proxy mechanisms.This feature is needed when you have a service in your network that cannot tolerate proxied SYN/ACKreplies under any condition, including a SYN flood event.

Both IP version 4 (IPv4) and IP version 6 (IPv6) whitelists are supported. Addresses in a whitelist shouldbe all IPv4 or all IPv6. In each whitelist, there can be up to 32 IP address prefixes. You can specify multipleaddresses or address prefixes as a sequence of addresses separated by spaces and enclosed in squarebrackets.

A whitelist can cause high CPU usage on a central point depending on the traffic level. For example, whenno screen is enabled, the connections per second (cps) is 492K; when the screen is enabled and thewhitelistis disabled, the cps is 373K; and when both the screen and the whitelist are enabled, the cps is 194K. Afterenabling the whitelist, the cps drops by 40 percent.

91

Example: Configuring Whitelists for SYN Flood Screens

IN THIS SECTION

Requirements | 92

Overview | 92

Configuration | 92

Verification | 94

This example shows how to configure whitelists of IP addresses to be exempted from the SYN cookie andSYN proxy mechanisms that occur during the SYN flood screen protection process.

Requirements

Before you begin, configure a security screen and enable the screen in the security zone. See “Example:Enabling SYN Flood Protection for Webservers in the DMZ” on page 84.

Overview

In this example, you configure whitelists named wlipv4 and wlipv6. All addresses are IP version 4 (IPv4)for wlipv4, and all addresses are IP version 6 (IPv6) for wlipv6. Both whitelists include destination andsource IP addresses.

Multiple addresses or address prefixes can be configured as a sequence of addresses separated by spacesand enclosed in square brackets, as shown in the configuration of the destination addresses for wlipv4.

Configuration


set security screen ids-option js1 tcp syn-flood white-list wlipv4 source-address 1.1.1.0/24set security screen ids-option js1 tcp syn-flood white-list wlipv4 destination-address 2.2.2.2/32set security screen ids-option js1 tcp syn-flood white-list wlipv4 destination-address 3.3.3.3/32set security screen ids-option js1 tcp syn-flood white-list wlipv4 destination-address 4.4.4.4/32set security screen ids-option js1 tcp syn-flood white-list wlipv6 source-address 2001::1/64

92

set security screen ids-option js1 tcp syn-flood white-list wlipv6 destination-address 2002::1/64


To configure the whitelists:

1. Specify the name of the whitelist and the IP addresses to be exempted from the SYN/ACK.

[edit security screen ids-option js1 tcp syn-flood]user@host# set white-list wlipv4 source-address 1.1.1.0/24user@host# set white-list wlipv4 destination-address [2.2.2.2 3.3.3.3 4.4.4.4]user@host# set white-list wlipv6 source-address 2001::1/64user@host# set white-list wlipv6 destination-address 2002::1/64

ResultsFrom configuration mode, confirm your configuration by entering the show security screen command. Ifthe output does not display the intended configuration, repeat the configuration instructions in this exampleto correct it.

[edit]user@host# show security screenids-option js1 {tcp {syn-flood {white-list wlipv4 {source-address 1.1.1.0/24;destination-address [2.2.2.2/32 3.3.3.3/32 4.4.4.4/32];

}white-list wlipv6 {source-address 2001::1/64;destination-address 2002::1/64;

}}

}}


93

Verification

Verifying Whitelist Configuration

PurposeVerify that the whitelist is configured properly.

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

Understanding Whitelists for UDP Flood Screens

Junos OS provides the administrative option to configure a whitelist of trusted IP addresses on UDP flood.When UDP flood is enabled, all the UDP packets that are above the threshold value will be dropped. Someof these packets are valid and should not be dropped from the traffic. When the whitelist is configuredon UDP flood screen, the source addresses or to the destination addresses in the list are allowed to bypassthe UDP flood detection. This feature is needed when all traffic from addresses in the whitelist groupsshould bypass UDP flood check.

Both IPv4 and IPv6 whitelists are supported. Addresses in a whitelist should be all IPv4 or all IPv6. In eachwhitelist, there can be up to 32 IP address prefixes. You can specify multiple addresses or address prefixesas a sequence of addresses separated by spaces and enclosed in square brackets. You can configure singleaddress or subnet address.

NOTE: UDP flood screen whitelist is not supported on SRX5400, SRX5600, and SRX5800devices.

Example: Configuring Whitelists for UDP Flood Screens

IN THIS SECTION

Requirements | 95

Overview | 95

Configuration | 95

Verification | 97

94

This example shows how to configure whitelists of IP addresses to be exempted fromUDP flood detectionthat occur during the UDP flood screen protection process.

Requirements

Before you begin, configure a security screen and enable the screen in the security zone.

Overview

In this example, you configure whitelists namedwlipv4 andwlipv6. All addresses are IPv4 forwlipv4, andall addresses are IPv6 for wlipv6. Both whitelists include destination and source IP addresses.

Multiple addresses or address prefixes can be configured as a sequence of addresses separated by spacesand enclosed in square brackets, as shown in the configuration of the destination addresses for wlipv4and wlipv6.

Configuration


set security screen white-list wlipv4 address 198.51.100.10/24set security screen white-list wlipv4 address 198.51.100.11/24set security screen white-list wlipv4 address 198.51.100.12/24set security screen white-list wlipv4 address 198.51.100.13/24set security screen white-list wlipv6 address 2001:db8::1/32set security screen white-list wlipv6 address 2001:db8::2/32set security screen white-list wlipv6 address [2001:db8::3/32]set security screen white-list wlipv6 address [2001:db8::4/32]set security screen ids-options jscreen udp flood white-list wlipv4set security screen ids-options jscreen udp flood white-list wlipv6


To configure the whitelists:

1. Specify the name of the whitelist and the IPv4 addresses to bypass UDP flood detection.

[edit security screen]

95

user@host# set white-list wlipv4 address 198.51.100.10/32user@host# set white-list wlipv4 address 198.51.100.11/32user@host# set white-list wlipv4 address 198.51.100.12/32user@host# set white-list wlipv4 address 198.51.100.13/32

2. Specify the name of the whitelist and the IPv6 addresses to bypass UDP flood detection.

[edit security screen]user@host# set white-list wlipv6 address 2001:db8::1/32user@host# set white-list wlipv6 address 2001:db8::2/32user@host# set white-list wlipv6 address 2001:db8::3/32user@host# set white-list wlipv6 address 2001:db8::4/32

3. Set the UDP flood whitelist option.

[edit security screen]user@host# set ids-option jscreen udp flood white-list wlipv4user@host# set ids-option jscreen udp flood white-list wlipv6


[edit]user@host# show security screenids-option jscreen {udp {flood {white-list [ wlipv4 wlipv6 ];

}}

}white-list wlipv4 {address [ 198.51.100.11/32 198.51.100.12/32 198.51.100.13/32 198.51.100.14/32 ];

}white-list wlipv6 {address [ 2001:db8::1/32 2001:db8::2/32 2001:db8::3/32 2001:db8::4/32 ];

}


96

Verification

Verifying Whitelist Configuration

PurposeVerify that the whitelist is configured properly.

ActionFrom operational mode, enter the show security screen white-list wlipv4 and show security screenids-option jscreen command.

user@host> show security screen white-list wlipv4

Screen white list:

198.51.100.10/32

198.51.100.11/32

198.51.100.12/32

198.51.100.13/32

user@host> show security screen ids-option jscreen

Name Value

……

UDP flood threshold ##

UDP flood white-list wlipv4

UDP flood white-list wlipv6

Understanding SYN Cookie Protection

SYN cookie is a stateless SYN proxy mechanism you can use in conjunction with other defenses againsta SYN flood attack.

As with traditional SYN proxying, SYN cookie is activatedwhen the SYN flood attack threshold is exceeded.However, because SYN cookie is stateless, it does not set up a session or policy and route lookups uponreceipt of a SYN segment, and it maintains no connection request queues. This dramatically reduces CPUand memory usage and is the primary advantage of using SYN cookie over the traditional SYN proxyingmechanism.

97

When SYN cookie is enabled on Junos OS and becomes the TCP-negotiating proxy for the destinationserver, it replies to each incoming SYN segment with a SYN/ACK containing an encrypted cookie as itsinitial sequence number (ISN). The cookie is an MD5 hash of the original source address and port number,destination address and port number, and ISN from the original SYN packet. After sending the cookie,Junos OS drops the original SYN packet and deletes the calculated cookie from memory. If there is noresponse to the packet containing the cookie, the attack is noted as an active SYN attack and is effectivelystopped.

If the initiating host responds with a TCP packet containing the cookie +1 in the TCP ACK field, Junos OSextracts the cookie, subtracts 1 from the value, and recomputes the cookie to validate that it is a legitimateACK. If it is legitimate, Junos OS starts the TCP proxy process by setting up a session and sending a SYNto the server containing the source information from the original SYN.When JunosOS receives a SYN/ACKfrom the server, it sends ACKs to the server and to the initiation host. At this point the connection isestablished and the host and server are able to communicate directly.

NOTE: The use of SYN cookie or SYN proxy enables the SRX Series device to protect the TCPservers behind it from SYN flood attacks in IPv6 flows.

Figure 6 on page 99 shows how a connection is established between an initiating host and a server whenSYN cookie is active on Junos OS.

98

Figure 6: Establishing a Connection with SYN Cookie Active

99

SYN Cookie Options

You can set the following parameters for incomplete TCP proxy connection requests:

• Attack Threshold—This option allows you to set the number of SYN segments (that is, TCP segmentswith the SYN flag set) to the same destination address and port number per second required to activatethe SYN proxy mechanism. Although you can set the threshold to any number, you need to know thenormal traffic patterns at your site to set an appropriate threshold for it. For example, for an e-businesssite that normally gets 2000 SYN segments per second, you might want to set the threshold to 30,000SYN segments per second. The valid threshold range is 1 to 1,000,000. For a smaller site that normallygets 20 SYN segments per second, you might consider setting the threshold to 40 SYN segments persecond.

• Alarm Threshold—This option allows you to set the number of proxied, half-complete TCP connectionrequests per second after which Junos OS enters an alarm in the event log. The alarm threshold valueyou set triggers an alarm when the number of proxied, half-completed connection requests to the samedestination address and port number per second exceeds that value. For example, if you set the SYNattack threshold at 2000 SYN segments per second and the alarm at 1000, then a total of 3001 SYNsegments to the same destination address and port number per second is required to trigger an alarmentry in the log. The valid threshold range is 1 to 1,000,000 and the default alarm threshold value is 512.

• Source Threshold—This option allows you to specify the number of SYN segments received per secondfrom a single source IP address—regardless of the destination IP address and port number—before JunosOS begins dropping connection requests from that source.

When you set a SYN attack threshold and a source threshold, you put both the basic SYN flood protectionmechanism and the source-based SYN flood tracking mechanism in effect. The valid threshold range is4 to 1,000,000 and the default alarm threshold value is 4000.

• Destination Threshold—This option allows you to specify the number of SYN segments received persecond for a single destination IP address before Junos OS begins dropping connection requests to thatdestination. If a protected host runs multiple services, you might want to set a threshold based ondestination IP address only—regardless of the destination port number. The valid threshold range is 4to 1,000,000 and the default alarm threshold value is 4000.

When you set a SYN attack threshold and a destination threshold, you put both the basic SYN floodprotection mechanism and the destination-based SYN flood tracking mechanism in effect.

• Timeout—This option allows you to set themaximum length of time before a half-completed connectionis dropped from the queue. The default is 20 seconds, and you can set the timeout from 0 to 50 seconds.Youmight try decreasing the timeout value to a shorter length until you begin to see dropped connectionsduring normal traffic conditions.

When either a source or destination threshold is not configured, the systemwill use the default thresholdvalue. The default source and destination threshold value is 4000 pps.

100

Detecting and Protecting Your Network Against SYN Flood Attacks byEnabling SYN Cookie Protection

IN THIS SECTION

Requirements | 101

Overview | 101

Configuration | 101

Verification | 103

This example shows how to detect and protect your network against SYN flood attacks by enabling theSYN cookie protection.

Requirements


Overview

In this example, you set the external-syn-flood timeout value to 20 and set the security zone for externalscreen to external-syn-flood. Also, you set the protection mode to syn-cookie.

NOTE: The SYN cookie feature can detect and protect only against spoofed SYN flood attacks,minimizing the negative impact on hosts that are secured by Junos OS. If an attacker uses alegitimate IP source address, rather than a spoofed IP source, then the SYN cookie mechanismdoes not stop the attack.

Configuration


101

set security screen ids-option external-syn-flood tcp syn-flood timeout 20set security zones security-zone external screen external-syn-floodset security flow syn-flood-protection-mode syn-cookie

Step-by-Step ProcedureThe following example requires you to navigate various levels in the configuration hierarchy. For instructionson how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide. To enable the SYNcookie protection:

1. Specify the external-syn-flood timeout value.

[edit]user@host# set security screen ids-option external-syn-flood tcp syn-flood timeout 20

2. Set the security-zone for external screen.

[edit]user@host# set security zones security-zone external screen external-syn-flood

3. Set the protection mode.

[edit]user@host# set security flow syn-flood-protection-mode syn-cookie

ResultsFrom configurationmode, confirm your configuration by entering the show security screen, show securityzones, and show security flow commands. If the output does not display the intended configuration, repeatthe configuration instructions in this example to correct it.

[edit]user@host# show security screenset security flow syn-flood-protection-mode syn-cookie {tcp {syn-flood {source-ip-based 1;}

}}

102

[edit]user@host# show security zonessecurity-zone external {screen external-syn-flood;

}[edit]user@host# show security flowsyn-flood-protection-mode syn-cookie;


Verification

Verifying SYN Cookie Protection

PurposeVerifying SYN cookie protection.

ActionEnter the show security screen ids-option external-syn-flood and show security zones commands fromoperational mode.

user@host> show security screen ids-option external-syn-floodnode0:

--------------------------------------------------------------------------


Name Value






user@host> show security zonesSecurity zone: external



Screen: external-syn-flood

Interfaces bound: 0

Interfaces:

103




Screen: external-syn-flood

Interfaces bound: 0

Interfaces:

MeaningThe sample output shows that SYN cookie protection is enabled with a source and destination threshold.

Understanding ICMP Flood Attacks

An ICMP flood typically occurs when ICMP echo requests overload the target of the attack with so manyrequests that the target expends all its resources responding until it can no longer process valid networktraffic.

NOTE: ICMP messages generated in flow mode are limited to 12 messages every 10 seconds.This rate limit is calculated on a per-CPU basis. Once the threshold is reached, no furtheracknowledgement messages are sent to the device.

When enabling the ICMP flood protection feature, you can set a threshold that, once exceeded, invokesthe ICMP flood attack protection feature. (The default threshold value is 1000 packets per second.) If thethreshold is exceeded, Junos OS ignores further ICMP echo requests for the remainder of that secondplus the next second as well. See Figure 7 on page 105.

NOTE: An ICMP flood can consist of any type of ICMP message. Therefore, Junos OS monitorsall ICMP message types, not just echo requests.

104

Figure 7: ICMP Flooding

NOTE: Junos OS supports ICMP flood protection for both IPv4 and IPv6 traffic.

105

Protecting Your Network Against ICMP Flood Attacks by Enabling ICMPFlood Protection

IN THIS SECTION

Requirements | 106

Overview | 106

Configuration | 106

Verification | 107

This example shows how to protect your network against ICMP flood attacks by enabling ICMP floodprotection.

Requirements

No special configuration beyond device initialization is required before enabling ICMP flood protection.

Overview

In this example, you enable ICMP flood protection. The value unit is ICMP packets per second, or pps. Thedefault value is 1000 pps. You specify the zone where a flood might originate.

Configuration


set security screen ids-option 1000-icmp-flood icmp flood threshold 1000set security zones security-zone zone screen 1000-icmp-flood


106

The following example requires you to navigate various levels in the configuration hierarchy. For instructionson how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide. To enable ICMPflood protection:

1. Specify the ICMP flood threshold value.

[edit]user@host# set security screen ids-option 1000-icmp-flood icmp flood threshold 1000


[edit]user@host# set security zones security-zone zone screen 1000-icmp-flood


[edit]user@host# show security screenids-option 1000-icmp-flood {icmp {flood threshold 1000;}

}

[edit]user@host# show security zonessecurity-zone zone {screen 1000-icmp-flood;

}


Verification

Verifying ICMP Flood Protection

PurposeVerify ICMP flood protection

107

ActionEnter the show security screen ids-option 1000-icmp-flood and show security zones commands fromoperational mode.

user@host> show security screen ids-option 1000-icmp-floodnode0:

--------------------------------------------------------------------------


Name Value

ICMP flood threshold 1000




Screen: 1000-icmp-flood

Interfaces bound: 0

Interfaces:

MeaningThe sample output shows that ICMP flood protection is enabled and threshold is set.

Understanding UDP Flood Attacks

Similar to an ICMP flood, a UDP flood occurs when an attacker sends IP packets containing UDP datagramswith the purpose of slowing down the victim to the point that the victim can no longer handle validconnections.

After enabling the UDP flood protection feature, you can set a threshold that, once exceeded, invokes theUDP flood attack protection feature. (The default threshold value is 1000 packets per second, or pps.) Ifthe number of UDP datagrams from one or more sources to a single destination exceeds this threshold,Junos OS ignores further UDP datagrams to that destination for the remainder of that second plus thenext second as well. See Figure 8 on page 109.

NOTE: The SRX5400, SRX5600, and SRX5800 devices do not drop the packet in the next second.

108

Figure 8: UDP Flooding

NOTE: Junos OS supports UDP flood protection for IPV4 and IPv6 packets.

Protecting Your Network Against UDP Flood Attacks by Enabling UDPFlood Protection

IN THIS SECTION

Requirements | 110

Overview | 110

109

Configuration | 110

Verification | 111

This example shows how to protect your network against UDP flood attacks by enabling UDP floodprotection.

Requirements

No special configuration beyond device initialization is required before enabling UDP flood protection.

Overview

In this example, you enable UDP flood protection. The value unit is UDP packets per second, or pps. Thedefault value is 1000 pps. You specify the zone where a flood might originate.

Configuration


set security screen ids-option 1000-udp-flood udp flood threshold 1000set security zones security-zone external screen 1000-udp-flood

Step-by-Step ProcedureThe following example requires you to navigate various levels in the configuration hierarchy. For instructionson how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide. To enable UDPflood protection:

1. Specify the UDP flood threshold value.

[edit]user@host# set security screen ids-option 1000-udp-flood udp flood threshold 1000

2. Set the security zone for external screen.

110

[edit]user@host# set security zones security-zone external screen 1000-udp-flood


[edit]user@host# show security screenids-option 1000-udp-flood {udp {flood threshold 1000;}

}

[edit]user@host# show security zonessecurity-zone external {screen 1000-udp-flood;

}


Verification

Verifying UDP Flood Protection

PurposeVerify UDP flood protection.

ActionEnter the show security screen ids-option 1000-udp-flood and show security zones commands fromoperational mode.

user@host> show security screen ids-option 1000-udp-floodnode0:

--------------------------------------------------------------------------


Name Value


111




Screen: 1000-udp-flood

Interfaces bound: 0

Interfaces:

MeaningThe sample output shows that UDP flood protection is enabled and threshold is set.

Understanding Land Attacks

Combining a SYN attack with IP spoofing, a land attack occurs when an attacker sends spoofed SYNpackets containing the IP address of the victim as both the destination and the source IP address.

The receiving system responds by sending the SYN-ACK packet to itself, creating an empty connectionthat lasts until the idle timeout value is reached. Flooding a system with such empty connections canoverwhelm the system, causing a denial of service (DoS). See Figure 9 on page 113.

112

Figure 9: Land Attack

When you enable the screen option to block land attacks, Junos OS combines elements of the SYN flooddefense and IP spoofing protection to detect and block any attempts of this nature.

NOTE: Junos OS supports land attack protection for both IPv4 and IPv6 packets.

Protecting Your Network Against Land Attacks by Enabling Land AttackProtection

IN THIS SECTION

Requirements | 114

Overview | 114

Configuration | 114

Verification | 115

113

This example shows how to protect your network against attacks by enabling land attack protection.

Requirements

No special configuration beyond device initialization is required before enabling land attack protection.

Overview

This example shows how to enable protection against a land attack. In this example, you set the securityscreen object name as land and set the security zone as zone.

Configuration


set security screen ids-option land tcp landset security zones security-zone zone screen land

Step-by-Step ProcedureThe following example requires you to navigate various levels in the configuration hierarchy. For instructionson how to do that, seeUsing the CLI Editor in ConfigurationMode in the CLI User Guide. To enable protectionagainst a land attack:


[edit]user@host# set security screen ids-option land tcp land

2. Set the security zone.

[edit]user@host# set security zones security-zone zone screen land


114

[edit]user@host# show security screenids-option land {tcp {land;}

}

[edit]user@host# show security zonessecurity-zone zone {screen land;

}


Verification

Verifying Protection Against a Land Attack

PurposeVerify protection against a land attack.

ActionEnter the show security screen ids-option land and show security zones commands from operationalmode.

user@host> show security screen ids-option landnode0:

--------------------------------------------------------------------------


Name Value

TCP land attack enabled




Screen: land

Interfaces bound: 0

Interfaces:

115

MeaningThe sample output shows that protection against a land attack is enabled.



OS-Specific DoS Attack

IN THIS SECTION


Understanding Ping of Death Attacks | 117

Example: Protecting Against a Ping of Death Attack | 118

Understanding Teardrop Attacks | 119

Understanding WinNuke Attacks | 120

Example: Protecting Against a WinNuke Attack | 121

OS-specific DoS attack focuses on one-packet or two-packet kills. These attacks include the Ping of Deathattack, the Teardrop attack, and the WinNuke attack. The Junos OS has the capability to mitigate theseattacks, For more information, see the following topics:

OS-Specific DoS Attacks Overview

If an attacker not only identifies the IP address and responsive port numbers of an active host but also itsoperating system (OS), instead of resorting to brute-force attacks, the attacker can launch more elegantattacks that can produce one-packet or two-packet “kills.”

OS-specific denial-of-service (DoS) attacks, including ping of death attacks, teardrop attacks, andWinNukeattacks, can cripple a system with minimal effort. If Junos OS is protecting hosts susceptible to theseattacks, you can configure Junos OS to detect these attacks and block them before they reach their target.

116

Understanding Ping of Death Attacks

OS-specific DoS attacks, such as ping of death attacks, can cripple a system with minimal effort.

The maximum allowable IP packet size is 65,535 bytes, including the packet header, which is typically 20bytes. An ICMP echo request is an IP packet with a pseudo header, which is 8 bytes. Therefore, themaximum allowable size of the data area of an ICMP echo request is 65,507 bytes (65,535 - 20 - 8 =65,507).

However, many ping implementations allow the user to specify a packet size larger than 65,507 bytes. Agrossly oversized ICMP packet can trigger a range of adverse system reactions such as denial of service(DoS), crashing, freezing, and rebooting.

When you enable the ping of death screen option, JunosOS detects and rejects such oversized and irregularpacket sizes evenwhen the attacker hides the total packet size by fragmenting it. See Figure 10 on page 117.

NOTE: For information about IP specifications, see RFC 791, Internet Protocol. For informationabout ICMP specifications, see RFC 792, Internet ControlMessage Protocol. For information aboutping of death attacks, see http://www.insecure.org/sploits/ping-o-death.html.

Figure 10: Ping of Death

NOTE: Junos OS supports ping of death protection for both IPv4 and IPv6 packets.

117

http://www.insecure.org/sploits/ping-o-death.html

Example: Protecting Against a Ping of Death Attack

IN THIS SECTION

Requirements | 118

Overview | 118

Configuration | 118

Verification | 119

This example shows how to protect against a ping-of-death attack.

Requirements


Overview

In this example, you enable protection against a ping-of-death attack and specify the zonewhere the attackoriginates.

Configuration

Step-by-Step ProcedureTo enable protection against a ping of death:


[edit]user@host# set security screen ids-option ping-death icmp ping-death


[edit]user@host# set security zones security-zone zone screen ping-death

3. If you are done configuring the device, commit the configuration.

118

[edit]user@host# commit

Verification

To verify the configuration is working properly, enter the show security screen ids-option ping-death andshow security zones commands in operational mode.

Understanding Teardrop Attacks

OS-specific denial-of-service (DoS) attacks, such as teardrop attacks, can cripple a system with minimaleffort.

Teardrop attacks exploit the reassembly of fragmented IP packets. In the IP header, one of the fields isthe fragment offset field, which indicates the starting position, or offset, of the data contained in afragmented packet relative to the data of the original unfragmented packet. See Figure 11 on page 119.

Figure 11: Teardrop Attacks

When the sum of the offset and size of one fragmented packet differ from that of the next fragmentedpacket, the packets overlap, and the server attempting to reassemble the packet can crash, especially if itis running an older OS that has this vulnerability. See Figure 12 on page 120.

119

Figure 12: Fragment Discrepancy

Imag

e33

The second fragment purports to begin20 bytes earlier (at 780) than the firstfragment ends (at 800). The offset offragment #2 is not in accord with thepacket length of fragment #1. Thisdiscrepancy can cause some systemsto crash during the reassembly attempt.

Fragmentedpacket #1

Fragmentedpacket #2

IP Header Data

IP Header Data

20 Bytes 800 Bytes

20 Bytes

Offset = 0

Length = 820

More Fragments = 1

600 Bytes

Offset = 780

Length = 620

More Fragments = 0

After you enable the teardrop attack screen option, whenever Junos OS detects this discrepancy in afragmented packet, it drops it.

NOTE: Junos OS supports teardrop attack prevention for both IPv4 and IPv6 packets.

Understanding WinNuke Attacks

OS-specific denial-of-service (DoS) attacks, such as WinNuke attacks, can cripple a system with minimaleffort.

WinNuke is a DoS attack targeting any computer on the Internet running Windows. The attacker sends aTCP segment—usually to NetBIOS port 139 with the urgent (URG) flag set—to a host with an establishedconnection (see Figure 13 on page 121). This introduces a NetBIOS fragment overlap, which causes manymachines running Windows to crash. After the attacked machine is rebooted, the following messageappears, indicating that an attack has occurred:

An exception OE has occurred at 0028:[address] in VxD MSTCP(01) +000041AE. This was called from 0028:[address] in VxD NDIS(01) +00008660. It may be possible to continue normally.Press any key to attempt to continue.Press CTRL+ALT+DEL to restart your computer. You will lose any unsaved information in all applications.Press any key to continue.

120

Figure 13: WinNuke Attack Indicators

If you enable theWinNuke attack defense screen option, JunosOS scans any incomingMicrosoft NetBIOSsession service (port 139) packets. If Junos OS observes that the URG flag is set in one of those packets,it unsets the URG flag, clears the URG pointer, forwards the modified packet, and makes an entry in theevent log noting that it has blocked an attempted WinNuke attack.

NOTE: Junos OS supports WinNuke attack protection for both IPv4 and IPv6 traffic.

Example: Protecting Against a WinNuke Attack

IN THIS SECTION

Requirements | 122

Overview | 122

Configuration | 122

Verification | 122

121

This example shows how to protect against a WinNuke attack.

Requirements


Overview

In this example, you enable protection against a WinNuke attack and specify the zone where the attackoriginates.

Configuration

Step-by-Step ProcedureTo enable protection against WinNuke attack:

1. Specify the screen name.

[edit]user@host# set security screen ids-option winnuke tcp winnuke

2. Associate the screen with a security zone.

[edit]user@host# set security zones security-zone zone screen winnuke



Verification

To verify the configuration is working properly, enter the show security screen ids-option winnuke andshow security zones commands in operational mode.



122


123

3CHAPTER

Suspicious Packets

Suspicious Packet Attributes Overview | 127

ICMP and SYN Fragment Attacks | 127


Suspicious Packet Attributes Overview

Attackers can craft packets to perform reconnaissance or launch denial-of-service (DoS) attacks. Sometimesit is unclear what the intent of a crafted packet is, but the very fact that it is crafted suggests that it isbeing put to some kind of insidious use.

The following topics describe screen options that block suspicious packets that might contain hiddenthreats:

• Understanding ICMP Fragment Protection on page 128

• Understanding Large ICMP Packet Protection on page 130

• Understanding Bad IP Option Protection on page 137

• Understanding Unknown Protocol Protection on page 139

• Understanding IP Packet Fragment Protection on page 135

• Understanding SYN Fragment Protection on page 132

ICMP and SYN Fragment Attacks

IN THIS SECTION

Understanding ICMP Fragment Protection | 128

Example: Blocking Fragmented ICMP Packets | 128

Understanding Large ICMP Packet Protection | 130

Example: Blocking Large ICMP Packets | 130

Understanding SYN Fragment Protection | 132

Example: Dropping IP Packets Containing SYN Fragments | 133

An ICMP flood typically occurs when ICMP echo request messages overload the victim, causing resourcesto stop responding to valid traffic. A fragmented SYN packet is anomalous, and as such, it is suspect.Whena victim receives these packets, the results can range from processing packets incorrectly to crashing theentire system, For more information, see the following topics:

127

Understanding ICMP Fragment Protection

Internet ControlMessage Protocol (ICMP) provides error reporting and network probe capabilities. BecauseICMPpackets contain very shortmessages, there is no legitimate reason for ICMPpackets to be fragmented.If an ICMP packet is so large that it must be fragmented, something is amiss.

When you enable the ICMP fragment protection screen option, Junos OS blocks any ICMP packet thathas the More Fragments flag set or that has an offset value indicated in the offset field. SeeFigure 14 on page 128.

Figure 14: Blocking ICMP Fragments

NOTE: Junos OS supports ICMP fragment protection for ICMPv6 packets.

Example: Blocking Fragmented ICMP Packets

This example shows how to block fragmented ICMP packets.

128

Requirements

Before you begin, Understand ICMP fragment protection. See “Suspicious Packet Attributes Overview”on page 127.

Overview

When you enable the ICMP fragment protection screen option, Junos OS blocks any ICMP packet thathas the more fragments flag set or that has an offset value indicated in the offset field.

In this example, you configure the ICMP fragment screen to block fragmented ICMP packets originatingfrom the zone1 security zone.

Configuration

Step-by-Step ProcedureTo block fragmented ICMP packets:

1. Configure the screen.

[edit]user@host# set security screen ids-option icmp-fragment icmp fragment

2. Configure a security zone.

[edit]user@host# set security zones security-zone zone1 screen icmp-fragment



Verification

To verify the configuration is working properly, enter the show security screen statistics zone zone-namecommand.

129

Understanding Large ICMP Packet Protection

Internet ControlMessage Protocol (ICMP) provides error reporting and network probe capabilities. BecauseICMP packets contain very short messages, there is no legitimate reason for large ICMP packets. If anICMP packet is unusually large, something is amiss.

See Figure 15 on page 130.

Figure 15: Blocking Large ICMP Packets

When you enable the large size ICMP packet protection screen option, Junos OS drops ICMP packets witha length greater than 1024 bytes.

NOTE: Junos OS supports large ICMP packet protection for both ICMP and ICMPv6 packets.

Example: Blocking Large ICMP Packets

This example shows how to block large ICMP packets.

130

Requirements

Before you begin, Understand large ICMP packet protection. See “Suspicious Packet Attributes Overview”on page 127.

Overview

When you enable the large ICMP packet protection screen option, Junos OS drops ICMP packets that arelarger than 1024 bytes.

In this example, you configure the ICMP large screen to block large ICMP packets originating from thezone1 security zone.

Configuration

Step-by-Step ProcedureTo block large ICMP packets:


[edit]user@host# set security screen ids-option icmp-large icmp large


[edit]user@host# set security zones security-zone zone1 screen icmp-large



Verification


131

Understanding SYN Fragment Protection

The IP encapsulates a TCP SYN segment in the IP packet that initiates a TCP connection. Because thepurpose of this packet is to initiate a connection and invoke a SYN/ACK segment in response, the SYNsegment typically does not contain any data. Because the IP packet is small, there is no legitimate reasonfor it to be fragmented.

A fragmented SYN packet is anomalous, and, as such, it is suspect. To be cautious, block such unknownelements from entering your protected network. See Figure 16 on page 132.

Figure 16: SYN Fragments

When you enable the SYN fragment detection screen option, JunosOS detects packets when the IP headerindicates that the packet has been fragmented and the SYN flag is set in the TCP header. Junos OS recordsthe event in the screen counters list for the ingress interface.

132

NOTE: Junos OS supports SYN fragment protection for both IPv4 and IPv6 packets.

Example: Dropping IP Packets Containing SYN Fragments

This example shows how to drop IP packets containing SYN fragments.

Requirements

Before you begin, Understand IP packet fragment protection. See “Suspicious Packet Attributes Overview”on page 127.

Overview

When you enable the SYN fragment detection screen option, JunosOS detects packets when the IP headerindicates that the packet has been fragmented and the SYN flag is set in the TCP header. Also, Junos OSrecords the event in the screen counters list for the ingress interface.

In this example, you configure the SYN fragment screen to drop fragmented SYN packets originating fromthe zone1 security zone.

Configuration

Step-by-Step ProcedureTo drop IP packets containing SYN fragments:


[edit]user@host# set security screen ids-option syn-frag tcp syn-frag

2. Configure the security zone.

[edit]user@host# set security zones security-zone zone1 screen syn-frag


133


Verification




IP Packet Protection

IN THIS SECTION

Understanding IP Packet Fragment Protection | 135

Example: Dropping Fragmented IP Packets | 136

Understanding Bad IP Option Protection | 137

Example: Blocking IP Packets with Incorrectly Formatted Options | 138

Understanding Unknown Protocol Protection | 139

Example: Dropping Packets Using an Unknown Protocol | 140

Some attackers can abuse the IP option fields, the original intent of which was (and still is) to providespecial routing controls, diagnostic tools, and security. By misconfiguring these options, attackers produceeither incomplete or malformed fields within a packet. Attackers can use these malformed packets tocompromise hosts on the network, For more information, see the following topics:

134

Understanding IP Packet Fragment Protection

As packets traverse different networks, it is sometimes necessary to break a packet into smaller pieces(fragments) based upon themaximum transmission unit (MTU) of each network. IP fragmentsmight containan attacker's attempt to exploit the vulnerabilities in the packet reassembly code of specific IP stackimplementations. When the victim receives these packets, the results can range from processing thepackets incorrectly to crashing the entire system. See Figure 17 on page 135.

Figure 17: IP Packet Fragments

When you enable Junos OS to deny IP fragments on a security zone, it blocks all IP packet fragments thatit receives at interfaces bound to that zone.

NOTE: Junos OS supports IP fragment protection for both IPv4 and IPv6 packets.

In IPv6 packets, fragment information is not present in the IPv6 header. The fragment information ispresent in the fragment extension header, which is responsible for IPv6 fragmentation and reassembly.The source node inserts the fragment extension header between the IPv6 header and the payload headerif fragmentation is required. See Figure 18 on page 135.

Figure 18: IPv6 Packet

The general format of the fragment extension header is shown in Figure 19 on page 136.

135

Figure 19: Fragment Extension Header

Example: Dropping Fragmented IP Packets

This example shows how to drop fragmented IP packets.

Requirements

Before you begin, Understand IP packet fragment protection. See “Suspicious Packet Attributes Overview”on page 127.

Overview

When this feature is enabled, Junos OS denies IP fragments on a security zone and blocks all IP packetfragments that are received at interfaces bound to that zone.

In this example, you configure the block fragment screen to drop fragmented IP packets originating fromthe zone1 security zone.

Configuration

Step-by-Step ProcedureTo drop fragmented IP packets:


[edit]user@host# set security screen ids-option block-frag ip block-frag

2. Configure the security zone.

[edit]user@host# set security zones security-zone zone1 screen block-frag

136



Verification


Understanding Bad IP Option Protection

The IP standard RFC 791, Internet Protocol, specifies a set of eight options that provide special routingcontrols, diagnostic tools, and security. Although the original, intended uses for these options servedworthy ends, people have figured out ways to twist these options to accomplish less commendableobjectives.

Either intentionally or accidentally, attackers sometimes configure IP options incorrectly, producing eitherincomplete or malformed fields. Regardless of the intentions of the person who crafted the packet, theincorrect formatting is anomalous and potentially harmful to the intended recipient. SeeFigure 20 on page 137.

Figure 20: Incorrectly Formatted IP Options

137

When you enable the bad IP option protection screen option, Junos OS blocks packets when any IP optionin the IP packet header is incorrectly formatted. Additionally, Junos OS records the event in the event log.

NOTE: Junos OS supports bad IP option protection for both IPv4 and IPv6 packets.

Example: Blocking IP Packets with Incorrectly Formatted Options

This example shows how to block large ICMP packets with incorrectly formatted options.

Requirements

Before you begin, Understand bad IP option protection. See “Suspicious Packet Attributes Overview” onpage 127.

Overview

When you enable the bad IP option protection screen option, Junos OS blocks packets when any IP optionin the IP packet header is incorrectly formatted. Additionally, Junos OS records the event in the event log.

In this example, you configure the IP bad option screen to block large ICMP packets originating from thezone1 security zone.

Configuration

Step-by-Step ProcedureTo detect and block IP packets with incorrectly formatted IP options:


[edit]user@host# set security screen ids-option ip-bad-option ip bad-option

NOTE: Currently this screen option is applicable only to IPv4.


138

[edit]user@host# set security zones security-zone zone1 screen ip-bad-option



Verification


Understanding Unknown Protocol Protection

Based on the latest IANA protocol numbers document, the protocol types with ID numbers of 143 orgreater are reserved and undefined at this time. Precisely because these protocols are undefined, there isno way to know in advance if a particular unknown protocol is benign or malicious.

Unless your network makes use of a nonstandard protocol with an ID number of 143 or greater, a cautiousstance is to block such unknown elements fromentering your protected network. See Figure 21 on page 139.

Figure 21: Unknown Protocols

IPHeader

If the ID number of theprotocol is 143 or greater,the security device blocksthe packet.

VersionHeaderLength

Type ofService

Identification

Time to Live (TTL) Protocol

O MD Fragment Offset

Total Packet Length (in Bytes)

Header Checksum

Source Address

Destination Address

Options

Payload

139

When you enable the unknown protocol protection screen option, Junos OS drops packets when theprotocol field contains a protocol ID number of 143 or greater by default.

NOTE: When you enable the unknown protocol protection screen option for IPv6 protocol,Junos OS drops packets when the protocol field contains a protocol ID number of 143 or greaterby default.

Example: Dropping Packets Using an Unknown Protocol

This example shows how to drop packets using an unknown protocol.

Requirements

Before you begin, Understand unknown protocol protection. See “Suspicious Packet AttributesOverview”on page 127.

Overview

When you enable the unknown protocol protection screen option, Junos OS drops packets when theprotocol field contains a protocol ID number of 137 or greater by default.

In this example, you configure the unknown protocol screen to block packets with an unknown protocoloriginating from the zone1 security zone.

Configuration

Step-by-Step ProcedureTo drop packets that use an unknown protocol:

1. Configure the unknown protocol screen.

[edit]user@host# set security screen ids-option unknown-protocol ip unknown-protocol


[edit]

140

user@host# set security zones security-zone zone1 screen unknown-protocol



Verification



Suspicious Packet Attributes Overview | 127

141

4CHAPTER

Network Reconnaissance

Reconnaissance Deterrence Overview | 145




Reconnaissance Deterrence Overview

Attackers can better plan their attack when they first know the layout of the targeted network (which IPaddresses have active hosts), the possible entry points (which port numbers are active on the active hosts),and the constitution of their victims (which operating system the active hosts are running). To gain thisinformation, attackers must perform reconnaissance.

Juniper Networks provides several screen options for deterring attackers' reconnaissance efforts andthereby hindering them from obtaining valuable information about the protected network and networkresources.




IP Address Sweep and Port Scan

IN THIS SECTION

Understanding Network Reconnaissance Using IP Options | 146

Example: Detecting Packets That Use IP Screen Options for Reconnaissance | 149

Understanding IP Address Sweeps | 153

Example: Blocking IP Address Sweeps | 154

Understanding TCP Port Scanning | 156

Understanding UDP Port Scanning | 157

Enhancing Traffic Management by Blocking Port Scans | 158

An address sweep occurs when one source IP address sends a predefined number of ICMP packets tovarious hosts within a predefined interval of time. Port scanning occurs when one source IP address sendsIP packets containing TCP SYN segments to a predefined number of different ports at the same destinationIP address within a predefined time interval, For more information, see the following topics:

145

Understanding Network Reconnaissance Using IP Options

IN THIS SECTION

Uses for IP Packet Header Options | 146

Screen Options for Detecting IP Options Used for Reconnaissance | 149

The IP standard RFC 791, Internet Protocol, specifies a set of options for providing special routing controls,diagnostic tools, and security.

RFC 791 states that these options are “unnecessary for themost common communications” and, in reality,they rarely appear in IP packet headers. These options appear after the destination address in an IP packetheader, as shown in Figure 22 on page 146. When they do appear, they are frequently being put to someillegitimate use.

Figure 22: Routing Options

This topic contains the following sections:

Uses for IP Packet Header Options

Table 11 on page 147 lists the IP options and their accompanying attributes.

146

Table 11: IP Options and Attributes

Nefarious UseIntended UseLengthNumberClassType

None.Indicates the end of one or moreIP options.

000*End ofOptions

None.Indicates there are no IP optionsin the header.

010NoOptions

Unknown. However, because it isobsolete, its presence in an IPheader is suspect.

Provides a way for hosts to sendsecurity, TCC (closed user group)parameters, and HandlingRestriction Codes compatiblewith Department of Defense(DoD) requirements. (This option,as specified in RFC 791, InternetProtocol, and RFC 1038, RevisedIP Security Option, is obsolete.)

Currently, this screen option isapplicable only to IPv4.

11 bits20Security

Evasion. The attacker can use thespecified routes to hide the truesource of a packet or to gainaccess to a protected network.

Specifies a partial route list for apacket to take on its journey fromsource to destination. The packetmust proceed in the order ofaddresses specified, but it isallowed to pass through otherdevices in between thosespecified.

Varies30LooseSourceRoute

Reconnaissance. If the destinationhost is a compromised machinein the attacker's control, he or shecan glean information about thetopology and addressing schemeof the network throughwhich thepacket passed.

Records the IP addresses of thenetwork devices along the paththat the IP packet travels. Thedestination machine can thenextract and process the routeinformation. (Due to the sizelimitation of 40 bytes for both theoption and storage space, this canonly record up to 9 IP addresses.)


Varies70RecordRoute

147

Table 11: IP Options and Attributes (continued)

Nefarious UseIntended UseLengthNumberClassType

Unknown. However, because it isobsolete, its presence in an IPheader is suspect.

(Obsolete) Provided away for the16-bit SATNET stream identifierto be carried through networksthat did not support the streamconcept.


4 bits80StreamID

Evasion. An attacker can use thespecified routes to hide the truesource of a packet or to gainaccess to a protected network.

Specifies the complete route listfor a packet to take on its journeyfrom source to destination. Thelast address in the list replaces theaddress in the destination field.


Varies90StrictSourceRoute

Reconnaissance. If the destinationhost is a compromised machinein the attacker's control, he or shecan glean information about thetopology and addressing schemeof the network throughwhich thepacket has passed.

Records the time (in coordinateduniversal time [UTC]***) wheneach network device receives thepacket during its trip from thepoint of origin to its destination.The network devices areidentified by IP address.

This option develops a list of IPaddresses of the devices alongthe path of the packet and theduration of transmission betweeneach one.


42**Timestamp

* The class of options identified as 0 was designed to provide extra packet or network control.

** The class of options identified as 2 was designed for diagnostics, debugging, and measurement.

*** The timestamp uses the number of milliseconds since midnight UTC. UTC is also known as Greenwich Mean Time(GMT), which is the basis for the international time standard.

148

Screen Options for Detecting IP Options Used for Reconnaissance

The following screen options detect IP options that an attacker can use for reconnaissance or for someunknown but suspect purpose:

• Record Route—Junos OS detects packets where the IP option is 7 (record route) and records the eventin the screen counters list for the ingress interface. Currently, this screen option is applicable only toIPv4.

• Timestamp—Junos OS detects packets where the IP option list includes option 4 (Internet timestamp)and records the event in the screen counters list for the ingress interface. Currently, this screen optionis applicable only to IPv4.

• Security—Junos OS detects packets where the IP option is 2 (security) and records the event in thescreen counters list for the ingress interface. Currently, this screen option is applicable only to IPv4.

• Stream ID—Junos OS detects packets where the IP option is 8 (stream ID) and records the event in thescreen counters list for the ingress interface. Currently, this screen option is applicable only to IPv4.

If a packet with any of the previous IP options is received, Junos OS flags this as a network reconnaissanceattack and records the event for the ingress interface.

Example:Detecting Packets ThatUse IP ScreenOptions for Reconnaissance

IN THIS SECTION

Requirements | 149

Overview | 150

Configuration | 150

Verification | 151

This example shows how to detect packets that use IP screen options for reconnaissance.

Requirements

Before you begin, understand how network reconnaissance works. See “Understanding NetworkReconnaissance Using IP Options” on page 146.

149

Overview

RFC 791, Internet Protocol, specifies a set of options for providing special routing controls, diagnostic tools,and security. The screen options detect IP options that an attacker can use for reconnaissance, includingrecord route, timestamp, security, and stream ID.

In this example, you configure an IP screen screen-1 and enable it in a security zone called zone-1.

NOTE: You can enable only one screen in one security zone.

Configuration

CLI Quick ConfigurationTo quickly detect packets with the record route, timestamp, security, and stream ID IP screen options,copy the following commands and paste them into the CLI.

[edit]set security screen ids-option screen-1 ip record-route-optionset security screen ids-option screen-1 ip timestamp-optionset security screen ids-option screen-1 ip security-optionset security screen ids-option screen-1 ip stream-optionset security zones security-zone zone-1 screen screen-1


To detect packets that use IP screen options for reconnaissance:

1. Configure IP screen options.

NOTE: Currently, these screen options support IPv4 only.

[edit security screen]user@host# set ids-option screen-1 ip record-route-optionuser@host# set ids-option screen-1 ip timestamp-optionuser@host# set ids-option screen-1 ip security-optionuser@host# set ids-option screen-1 ip stream-option

150

2. Enable the screen in the security zone.

[edit security zones ]user@host# set security-zone zone-1 screen screen-1


[edit][user@host]show security screenids-option screen-1 {ip {record-route-option;timestamp-option;security-option;stream-option;

}}

[edit][user@host]show security zoneszones {security-zone zone-1 {screen screen-1;

}}


Verification

IN THIS SECTION

Verifying the Screens in the Security Zone | 152



151

Verifying the Screens in the Security Zone

PurposeVerify that the screen is enabled in the security zone.

ActionFrom operational mode, enter the show security zones command.

[edit]


Security zone: zone-1



Screen: screen-1

Interfaces bound: 1

Interfaces:

ge-1/0/0.0



ActionFrom operational mode, enter the show security screen ids-option screen-name command.

[edit]

user@host> show security screen ids-option screen-1


Name Value

IP record route option enabled

IP timestamp option enabled

IP security option enabled

IP stream option enabled

152

Understanding IP Address Sweeps

An address sweep occurs when one source IP address sends a defined number of ICMP packets sent todifferent hosts within a defined interval (5000 microseconds is the default). The purpose of this attack isto send ICMP packets—typically echo requests—to various hosts in the hopes that at least one replies,thus uncovering an address to target.

Junos OS internally logs the number of ICMP packets to different addresses from one remote source.Using the default settings, if a remote host sends ICMP traffic to 10 addresses in 0.005 seconds (5000microseconds), then the device flags this as an address sweep attack and rejects all further ICMP packetsfrom that host for the remainder of the specified threshold time period. See Figure 23 on page 153.

Figure 23: Address Sweep

Consider enabling this screen option for a security zone only if there is a policy permitting ICMP trafficfrom that zone. Otherwise, you do not need to enable the screen option. The lack of such a policy deniesall ICMP traffic from that zone, precluding an attacker from successfully performing an IP address sweepanyway.

153

NOTE: Junos OS supports this screen option for ICMPv6 trafffic also.

Example: Blocking IP Address Sweeps

IN THIS SECTION

Requirements | 154

Overview | 154

Configuration | 154

Verification | 155

This example describes how to configure a screen to block an IP address sweep originating from a securityzone.

Requirements

Before you begin:

• Understand how IP address sweeps work. See “Understanding IP Address Sweeps” on page 153.

• Configure security zones. See Security Zones Overview.

Overview

You need to enable a screen for a security zone if you have configured a policy that permits ICMP trafficfrom that zone. If you have not configured such a policy, then your system denies all ICMP traffic fromthat zone, and the attacker cannot perform an IP address sweep successfully anyway.

In this example you configure a 5000-ip-sweep screen to block IP address sweeps originating in the zone-1security zone.

Configuration


154

To configure a screen to block IP address sweeps:

1. Configure a screen.

[edit]user@host# set security screen ids-option 5000-ip-sweep icmp ip-sweep threshold 5000


[edit]user@host# set security zones security-zone zone-1 screen 5000-ip-sweep



Verification

IN THIS SECTION







[edit]


155




Screen: 5000-ip-sweep

Interfaces bound: 1

Interfaces:

ge-1/0/0.0




[edit]

user@host> show security screen ids-option 5000-ip-sweep


Name Value


Understanding TCP Port Scanning

A port scan occurs when one source IP address sends IP packets containing TCP SYN segments to 10different destination ports within a defined interval (5000 microseconds is the default). The purpose ofthis attack is to scan the available services in the hopes that at least one port will respond, thus identifyinga service to target.

Junos OS internally logs the number of different ports scanned from one remote source. Using the defaultsettings, if a remote host scans 10 ports in 0.005 seconds (5000 microseconds), then the device flags thisas a port scan attack and rejects all further packets from the remote source, regardless of the destinationIP address, for the remainder of the specified timeout period. See Figure 24 on page 157.

156

Figure 24: Port Scan

NOTE: Junos OS supports port scanning for both IPv4 and IPv6 traffic.

Understanding UDP Port Scanning

UDP port scan gives statistical information on a session threshold. As the incoming packets traverse thescreen, the sessions are established. The number of sessions threshold enforced is based on zone, sourceIP, and the threshold period and does not allow more than 10 new sessions in the configured thresholdperiod, for each zone and source IP address. The UDP port scan is disabled by default. When the UDPport scan is enabled, the default threshold period is 5000 microseconds. This value can be manually setto a range of 1000-1,000,000 microseconds. This feature protects some exposed public UDP servicesagainst DDoS attacks. See Figure 25 on page 158.

157

Figure 25: UDP Port Scan

Enhancing Traffic Management by Blocking Port Scans

IN THIS SECTION

Requirements | 159

Overview | 159

Configuration | 159

Verification | 160

158

This example shows how to enhance traffic management by configuring a screen to block port scansoriginating from a particular security zone.

Requirements

Before you begin, understand how port scanning works. See “Understanding TCP Port Scanning” onpage 156.

Overview

You can use a port scan to block IP packets containing TCP SYN segments or UDP segments sent todifferent ports from the same source address within a defined interval. The purpose of this attack is toscan the available services in the hopes that at least one port will respond. Once a port responds, it isidentified as a service to target.

In this example, you configure a 5000 port-scan screen to block port scans originating from a particularsecurity zone and then assign the screen to the zone called zone-1.

Configuration


set security screen ids-option 5000-port-scan tcp port-scan threshold 5000set security screen ids-option 10000-port-scan udp port-scan threshold 10000set security zones security-zone zone-1 screen 5000-port-scan


To configure a screen to block port scans:


[edit security]user@host# set security screen ids-option 5000-port-scan tcp port-scan threshold 5000user@host#set security screen ids-option 10000-port-scan udp port-scan threshold 10000


159

[edit security]user@host# set security zones security-zone zone-1 screen 5000-port-scan

ResultsFrom configuration mode, confirm your configuration by entering the show security screen ids-option5000-port-scan and show security zones commands. If the output does not display the intendedconfiguration, repeat the configuration instructions in this example to correct it.

[edit]user@host# show security screen ids-option 5000-port-scantcp {port-scan threshold 5000;

}udp {port-scan threshold 10000;

}

[edit]user@host# show security zonessecurity-zone zone-1 {screen 5000-port-scan;

}


Verification

IN THIS SECTION






160


[edit]





Screen: 5000-port-scan

Interfaces bound: 0

Interfaces:

MeaningThe sample output shows that the screen for zone-1 is enabled for port scan blocking.


PurposeVerify the configuration information about the security screen.


[edit]

user@host> show security screen ids-option 5000-port-scan


Name Value


UDP port scan threshold 10000

MeaningThe sample output shows that the port scan blocking is operational with TCP and UDP threshold.

SEE ALSO


161

Operating System Identification Probes

IN THIS SECTION

Understanding Operating System Identification Probes | 162

Understanding Domain Name System Resolve | 162

Understanding TCP Headers with SYN and FIN Flags Set | 163

Example: Blocking Packets with SYN and FIN Flags Set | 164

Understanding TCP Headers With FIN Flag Set and Without ACK Flag Set | 167

Example: Blocking Packets With FIN Flag Set and Without ACK Flag Set | 168

Understanding TCP Header with No Flags Set | 171

Example: Blocking Packets with No Flags Set | 171

Prior to launching an exploit, an attacker might probe the targeted host, trying to learn its operating system.Various operating systems react to TCP anomalies in different ways. With that knowledge, an attackercan decide which further attack might inflict more damage to the device, the network, or both, For moreinformation, see the following topics:

Understanding Operating System Identification Probes

Before launching an exploit, attackers might try to probe the targeted host to learn its operating system(OS). With that knowledge, they can better decide which attack to launch and which vulnerabilities toexploit. Junos OS can block reconnaissance probes commonly used to gather information about OS types.

Understanding Domain Name System Resolve

Prior to JunosOS Release 12.1X47, DNS resolutionwas performedwith only UDP as a transport.Messagescarried by UDP are restricted to 512 bytes; longer messages are truncated and the traffic class (TC) bit isset in the header. The maximum length of UDP DNS response messages is 512 bytes, but the maximumlength of TCP DNS response messages is 65,535 bytes. A DNS resolver knows whether the response iscomplete if the TC bit is set in the header. Hence, a TCP DNS response can carry more information thana UDP DNS response.

162

There are three types of DNS resolve behaviors:

• UDP DNS resolve

• TCP DNS resolve

• UDP/TCP DNS resolve

NOTE: A policy uses UDP/TCP DNS resolve to resolve IP addresses. In UDP/TCP DNS resolve,UDP DNS resolve is first used, and when it gets truncated TCP DNS resolve is used.

NOTE: A Routing Engine policy supports a maximum of 1024 IPv4 address prefixes and 256IPv6 address prefixes that can be sent to the PFE. If themaximumnumber of IPv4 or IPv6 addressprefixes exceeds the limits, the addresses over the limitations will not be sent to the PFE and asyslogmessage is generated. Themaximumnumber of addresses in a TCPDNS response is 4094for IPv4 addresses and 2340 for IPv6 addresses, but only 1024 IPv4 addresses and 256 IPv6addresses are loaded to the PFE.

Understanding TCP Headers with SYN and FIN Flags Set

Both the SYN and FIN control flags are not normally set in the same TCP segment header. The SYN flagsynchronizes sequence numbers to initiate a TCP connection. The FIN flag indicates the end of datatransmission to finish a TCP connection. Their purposes are mutually exclusive. A TCP header with theSYN and FIN flags set is anomalous TCP behavior, causing various responses from the recipient, dependingon the OS. See Figure 26 on page 164.

163

Figure 26: TCP Header with SYN and FIN Flags Set

An attacker can send a segment with both flags set to seewhat kind of system reply is returned and therebydetermine what kind of OS is on the receiving end. The attacker can then use any known systemvulnerabilities for further attacks.

When you enable this screen option, Junos OS checks if the SYN and FIN flags are set in TCP headers. Ifit discovers such a header, it drops the packet.

NOTE: Junos OS supports TCP header with SYN and FIN flags set protection for both IPv4 andIPv6 traffic.

Example: Blocking Packets with SYN and FIN Flags Set

IN THIS SECTION

Requirements | 165

Overview | 165

Configuration | 165

Verification | 166

164

This example shows how to create a screen to block packets with the SYN and FIN flags set.

Requirements

Before you begin, understand how TCP headers with SYN and FIN flags work. See “Understanding TCPHeaders with SYN and FIN Flags Set” on page 163.

Overview

The TCP header with the SYN and FIN flags set cause different responses from a targeted device dependingon the OS it is running. The syn-fin screen is enabled for the security zone.

In this example, you create a screen called screen-1 in a security zone to block packets with the SYN andFIN flags set.

Configuration

Step-by-Step ProcedureTo block packets with both the SYN and FIN flags set:


[edit]user@host# set security screen ids-option screen-1 tcp syn-fin


[edit ]user@host# set security zones security-zone zone-1 screen screen-1



165

Verification

IN THIS SECTION







[edit]





Screen: screen-1

Interfaces bound: 1

Interfaces:

ge-1/0/0.0




[edit]


166


Name Value

TCP SYN FIN enabled

Understanding TCP Headers With FIN Flag Set andWithout ACK Flag Set

Figure 27 on page 168 shows TCP segments with the FIN control flag set (to signal the conclusion of asession and terminate the connection). Normally, TCP segments with the FIN flag set also have the ACKflag set (to acknowledge the previous packet received). Because a TCP header with the FIN flag set butnot the ACK flag is anomalous TCP behavior, there is no uniform response to this. The OS might respondby sending a TCP segment with the RST flag set. Another might completely ignore it. The victim's responsecan provide the attacker with a clue as to its OS. (Other purposes for sending a TCP segment with the FINflag set are to evade detection while performing address and port scans and to evade defenses on guardfor a SYN flood by performing a FIN flood instead.)

NOTE: Vendors have interpreted RFC793,TransmissionControl Protocol, variouslywhen designingtheir TCP/IP implementations. When a TCP segment arrives with the FIN flag set but not theACK flag, some implementations send RST segments, while others drop the packet withoutsending an RST.

167

Figure 27: TCP Header with FIN Flag Set

When you enable this screen option, Junos OS checks if the FIN flag is set but not the ACK flag in TCPheaders. If it discovers a packet with such a header, it drops the packet.

NOTE: Junos OS supports TCP header with SYN and FIN flags set protection for both IPv4 andIpv6 traffic.

Example: Blocking Packets With FIN Flag Set and Without ACK Flag Set

IN THIS SECTION

Requirements | 169

Overview | 169

Configuration | 169

Verification | 169

This example shows how to create a screen to block packets with the FIN flag set but the ACK flag notset.

168

Requirements

Before you begin, understand how TCP headers work. See “Understanding TCP Headers With FIN FlagSet and Without ACK Flag Set” on page 167.

Overview

The TCP segments with the FIN flag set also have the ACK flag set to acknowledge the previous packetreceived. Because a TCP header with the FIN flag set but the ACK flag not set is anomalous TCP behavior,there is no uniform response to this. When you enable the fin-no-ack screen option, Junos OS checks ifthe FIN flag is set but not the ACK flag in TCP headers. If it discovers a packet with such a header, it dropsthe packet.

In this example, you create a screen called screen-1 to block packets with the FIN flag set but the ACKflag not set.

Configuration

Step-by-Step ProcedureTo block packets with the FIN flag set but the ACK flag not set:


[edit ]user@host# set security screen ids-option screen-1 tcp fin-no-ack



Verification

IN THIS SECTION



169





[edit]





Screen: screen-1

Interfaces bound: 1

Interfaces:

ge-1/0/0.0




[edit]



Name Value

TCP FIN no ACK enabled

170

Understanding TCP Header with No Flags Set

A normal TCP segment header has at least one flag control set. A TCP segment with no control flags setis an anomalous event. Because different operating systems respond differently to such anomalies, theresponse (or lack of response) from the targeted device can provide a clue as to the type of OS it is running.See Figure 28 on page 171.

Figure 28: TCP Header with No Flags Set

When you enable the device to detect TCP segment headers with no flags set, the device drops all TCPpackets with a missing or malformed flags field.

NOTE: JunosOS supports TCP header with no flags set protection for both IPv4 and IPv6 traffic.

Example: Blocking Packets with No Flags Set

IN THIS SECTION

Requirements | 172

Overview | 172

171

Configuration | 172

Verification | 173

This example shows how to create a screen to block packets with no flags set.

Requirements

Before you begin, understand how a TCP header with no flags set works. See “Understanding TCP Headerwith No Flags Set” on page 171.

Overview

A normal TCP segment header has at least one flag control set. A TCP segment with no control flags setis an anomalous event. Because different operating systems respond differently to such anomalies, theresponse (or lack of response) from the targeted device can provide a clue as to the type of OS it is running.

When you enable the device to detect TCP segment headers with no flags set, the device drops all TCPpackets with a missing or malformed flags field.

In this example, you create a screen called screen-1 to block packets with no flags set.

Configuration

Step-by-Step ProcedureTo block packets with no flags set:


[edit ]user@host# set security screen ids-option screen-1 tcp tcp-no-flag




172


Verification

IN THIS SECTION







[edit]





Screen: screen-1

Interfaces bound: 1

Interfaces:

ge-1/0/0.0



Action

173

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

[edit]



Name Value

TCP no flag enabled



Attacker Evasion Techniques

IN THIS SECTION

Understanding Attacker Evasion Techniques | 175

Understanding FIN Scans | 175

Thwarting a FIN Scan | 175

Understanding TCP SYN Checking | 176

Setting TCP SYN Checking | 178

Setting TCP Strict SYN Checking | 178

Understanding IP Spoofing | 179

Example: Blocking IP Spoofing | 179

Understanding IP Spoofing in Layer 2 Transparent Mode on Security Devices | 181

Configuring IP Spoofing in Layer 2 Transparent Mode on Security Devices | 182

Understanding IP Source Route Options | 184

Example: Blocking Packets with Either a Loose or a Strict Source Route Option Set | 187

Example: Detecting Packets with Either a Loose or a Strict Source Route Option Set | 189

174

An attacker might use the SYN and FIN flags to launch the attack. The inset also illustrates the configurationof Screen options designed to block these probes, For more information, see the following topics:

Understanding Attacker Evasion Techniques

Whether gathering information or launching an attack, it is generally expected that the attacker avoidsdetection. Although some IP address and port scans are blatant and easily detectable, more wily attackersuse a variety of means to conceal their activity. Techniques such as using FIN scans instead of SYNscans—which attackers knowmost firewalls and intrusion detection programs detect—indicate an evolutionof reconnaissance and exploit techniques for evading detection and successfully accomplishing their tasks.

Understanding FIN Scans

A FIN scan sends TCP segments with the FIN flag set in an attempt to provoke a response (a TCP segmentwith the RST flag set) and thereby discover an active host or an active port on a host. Attackers might usethis approach rather than perform an address sweep with ICMP echo requests or an address scan withSYN segments, because they know that many firewalls typically guard against the latter two approachesbut not necessarily against FIN segments. The use of TCP segments with the FIN flag set might evadedetection and thereby help the attackers succeed in their reconnaissance efforts.

Thwarting a FIN Scan

To thwart FIN scans, take either or both of the following actions:

• Enable the screen option that specifically blocks TCP segments with the FIN flag set but not the ACKflag, which is anomalous for a TCP segment:

user@host#set security screen fin-no-ack tcp fin-no-ackuser@host#set security zones security-zone name screen fin-no-ack

where name is the name of the zone to which you want to apply this screen option .

• Change the packet processing behavior to reject all non-SYN packets that do not belong to an existingsession. The SYN check flag is set as the default.

175

NOTE: Changing the packet flow to check that the SYN flag is set for packets that do notbelong to existing sessions also thwarts other types of non-SYN scans, such as a null scan(when no TCP flags are set).

Understanding TCP SYN Checking

By default, Junos OS checks for SYN flags in the first packet of a session and rejects any TCP segmentswith non-SYN flags attempting to initiate a session. You can leave this packet flow as is or change it sothat JunosOS does not enforce SYN flag checking before creating a session. Figure 29 on page 176 illustratespacket flow sequences both when SYN flag checking is enabled and when it is disabled.

Figure 29: SYN Flag Checking

When Junos OS with SYN flag checking enabled receives a non-SYN TCP segment that does not belongto an existing session, it drops the packet. By default, Junos OS does not send a TCP RST to the sourcehost on receiving the non-SYN segment. You can configure the device to send TCP RST to the source hostby using the set security zones security-zone trust tcp-rst command. If the code bit of the initial non-SYNTCP packet is RST, the device does not send a TCP-RST.

Not checking for the SYN flag in the first packets offers the following advantages:

• NSRPwithAsymmetric Routing—In an active/activeNSRP configuration in a dynamic routing environment,a host might send the initial TCP segment with the SYN flag set to one device (Device-A), but the

176

SYN/ACKmight be routed to the other device in the cluster (Device-B). If this asymmetric routing occursafter Device-A has synchronized its sessionwith Device-B, all is well. On the other hand, if the SYN/ACKresponse reaches Device-B before Device-A synchronizes the session and SYN checking is enabled,Device-B rejects the SYN/ACK, and the session cannot be established. With SYN checking disabled,Device-B accepts the SYN/ACK response—even though there is no existing session to which itbelongs—and creates a new session table entry for it.

• Uninterrupted Sessions—If you reset the device or even change a component in the core section of apolicy and SYN checking is enabled, all existing sessions or those sessions to which the policy changeapplies are disrupted and must be restarted. Disabling SYN checking avoids such disruptions to networktraffic flows.

NOTE: A solution to this scenario is to install the device with SYN checking disabled initially.Then, after a few hours—when established sessions are running through the device—enableSYN checking. The core section in a policy contains the following main components: sourceand destination zones, source and destination addresses, one or more services, and an action.

However, the previous advantages exact the following security sacrifices:

• Reconnaissance Holes—When an initial TCP segment with a non-SYN flag—such as ACK, URG, RST,FIN—arrives at a closed port, many operating systems (Windows, for example) respond with a TCPsegment that has the RST flag set. If the port is open, then the recipient does not generate any response.

By analyzing these responses or lack thereof, an intelligence gatherer can perform reconnaissance onthe protected network and also on the Junos OS policy set. If a TCP segment is sent with a non-SYNflag set and the policy permits it through, the destination host receiving such a segment might drop itand respond with a TCP segment that has the RST flag set. Such a response informs the perpetrator ofthe presence of an active host at a specific address and that the targeted port number is closed. Theintelligence gatherer also learns that the firewall policy permits access to that port number on that host.

By enabling SYN flag checking, Junos OS drops TCP segments without a SYN flag if they do not belongto an existing session. It does not return a TCP RST segment. Consequently, the scanner gets no repliesregardless of the policy set or whether the port is open or closed on the targeted host.

• Session Table Floods—If SYN checking is disabled, an attacker can bypass the Junos OS SYN floodprotection feature by flooding a protected network with a barrage of TCP segments that have non-SYNflags set. Although the targeted hosts drop the packets—and possibly send TCP RST segments inreply—such a flood can fill up the session table of the Juniper Networks device. When the session tableis full, the device cannot process new sessions for legitimate traffic.

By enabling SYN checking and SYN flood protection, you can thwart this kind of attack. Checking thatthe SYN flag is set on the initial packet in a session forces all new sessions to begin with a TCP segmentthat has the SYN flag set. SYN flood protection then limits the number of TCP SYN segments per secondso that the session table does not become overwhelmed.

177

If you do not need SYN checking disabled, Juniper Networks strongly recommends that it be enabled (itsdefault state for an initial installation of Junos OS). You can enable it with the set flow tcp-syn-checkcommand. With SYN checking enabled, the device rejects TCP segments with non-SYN flags set unlessthey belong to an established session.

Setting TCP SYN Checking

With SYN checking enabled, the device rejects TCP segments with non-SYN flags set unless they belongto an established session. Enabling SYN checking can help prevent attacker reconnaissance and sessiontable floods. TCP SYN checking is enabled by default.

To disable SYN checking:

user@host#set security flow tcp-session no-syn-check

Setting TCP Strict SYN Checking

With strict SYN checking enabled, the device enables the strict three-way handshake check for the TCPsession. It enhances security by dropping data packets before the three-way handshake is done. TCP strictSYN checking is disabled by default.

NOTE: The strict-syn-check option cannot be enabled if no-syn-check or no-syn-check-in-tunnelis enabled.

NOTE: When you enable strict-syn-check the SYN packets carrying data are dropped.

To enable strict SYN checking:

user@host#set security flow tcp-session strict-syn-check

178

Understanding IP Spoofing

One method of attempting to gain access to a restricted area of the network is to insert a false sourceaddress in the packet header to make the packet appear to come from a trusted source. This technique iscalled IP spoofing. The mechanism to detect IP spoofing relies on route table entries. For example, if apacket with source IP address 10.1.1.6 arrives at ge-0/0/1, but JunosOS has a route to 10.1.1.0/24 throughge-0/0/0, a check for IP spoofing discovers that this address arrived at an invalid interface as defined inthe route table. A valid packet from 10.1.1.6 can only arrive via ge-0/0/0, not ge-0/0/1. Therefore, JunosOS concludes that the packet has a spoofed source IP address and discards it.

NOTE: Junos OS detects and drops both IPv4 and IPv6 spoofed packets.

Example: Blocking IP Spoofing

IN THIS SECTION

Requirements | 179

Overview | 179

Configuration | 180

Verification | 180

This example shows how to configure a screen to block IP spoof attacks.

Requirements

Before you begin, understand how IP Spoofing works. See “Understanding IP Spoofing” on page 179.

Overview

One method of attempting to gain access to a restricted area of a network is to insert a bogus sourceaddress in the packet header to make the packet appear to come from a trusted source. This technique iscalled IP spoofing.

179

In this example, you configure a screen called screen-1 to block IP spoof attacks and enable the screen inthe zone-1 security zone.

Configuration

Step-by-Step ProcedureTo block IP spoofing:


[edit ]user@host# set security screen ids-option screen-1 ip spoofing


[edit]user@host# set security zone security-zone zone-1 screen screen-1



Verification

IN THIS SECTION






Action

180

From operational mode, enter the show security zones command.

[edit]





Screen: screen-1

Interfaces bound: 1

Interfaces:

ge-1/0/0.0




[edit]



Name Value

IP spoofing enabled

Understanding IP Spoofing in Layer 2TransparentModeonSecurityDevices

In an IP spoofing attack, the attacker gains access to a restricted area of the network and inserts a falsesource address in the packet header to make the packet appear to come from a trusted source. IP spoofingis most frequently used in denial-of-service (DoS) attacks. When SRX Series devices are operating intransparent mode, the IP spoof-checking mechanism makes use of address book entries. Address books

181

only exist on the Routing Engine. IP spoofing in Layer 2 transparent mode is performed on the PacketForwarding Engine. Address book information cannot be obtained from the Routing Engine each time apacket is received by the Packet Forwarding Engine. Therefore, address books attached to the Layer 2zones must be pushed to the Packet Forwarding Engine.

NOTE: IP spoofing in Layer 2 transparent mode does not support DNS and wildcard addresses.

When a packet is received by the Packet Forwarding Engine, the packet’s source IP address is checked todetermine if it is in the incoming zone’s address-book. If the packet’s source IP address is in the incomingzone’s address book, then this IP address is allowed on the interface, and traffic is passed.

If the source IP address is not present in the incoming zone’s address-book, but exists in other zones’, thenthe IP address is considered a spoofed IP. Accordingly, actions such as drop and logging can be takendepending on the screen configuration (alarm-without-drop).

NOTE: If the alarm-without-drop option is configured, the Layer 2 spoofing packet only triggersan alarm message, but the packet is not dropped.

If a packet’s source IP address is not present in the incoming zone’s address book or other zones’, thenyou cannot determine if the IP is spoofed or not. In such instances, the packet is passed.

Junos OS takes into account the following match conditions while it searches for source IP addresses inthe address book:

• Host-match—The IP address match found in the address-book is an address without a prefix.

• Prefix-match—The IP address match found in the address-book is an address with a prefix.

• Any-match—The IP address match found in the address-book is “any”, “any-IPv4”, or “any-IPv6”.

• No-match—No IP address match is found.

Configuring IP Spoofing in Layer 2 Transparent Mode on Security Devices

You can configure the IP spoof-checking mechanism to determine whether or not an IP is being spoofed.

To configure IP spoofing in Layer 2 transparent mode:

1. Set the interface in Layer 2 transparent mode.

182

[edit]user@host# set interfaces ge-0/0/1 unit 0 family ethernet-switching

2. (Optional) Set the zone in Layer 2 transparent mode.

[edit]user@host# set security zones security-zone untrust interfaces ge-0/0/1.0

3. Configure the address book.

[edit]user@host# set security address-book my-book address myadd1 10.1.1.0/24user@host# set security address-book my-book address myadd2 10.1.2.0/24

4. Apply the address book to the zone.

[edit]user@host# set security address-book my-book attach zone untrust

5. Configure screen IP spoofing.

[edit]user@host# set security screen ids-option my-screen ip spoofing

6. Apply the screen to the zone.

[edit]user@host# set security zones security-zone untrust screen my-screen

7. (Optional) Configure the alarm-without-drop option.

[edit]user@host# set security screen ids-option my-screen alarm-without-drop

183

NOTE: If the alarm-without-drop option is configured, the Layer 2 spoofing packet only triggersan alarm message, but the packet is not dropped.

Understanding IP Source Route Options

Source routing was designed to allow users at the source of an IP packet transmission to specify the IPaddresses of the devices (also referred to as “hops” ) along the path that they want an IP packet to takeon its way to its destination. The original intent of the IP source route options was to provide routingcontrol tools to aid diagnostic analysis. If, for example, the transmission of a packet to a particular destinationmeets with irregular success, you might first use either the record route or the timestamp IP option todiscover the addresses of devices along the path or paths that the packet takes. You can then use eitherthe loose or the strict source route option to direct traffic along a specific path, using the addresses youlearned from the results that the record route or timestamp options produced. By changing device addressesto alter the path and sending several packets along different paths, you can note changes that eitherimprove or lessen the success rate. Through analysis and the process of elimination, you might be able todeduce where the trouble lies. See Figure 30 on page 185.

184

Figure 30: IP Source Routing

Although the uses of IP source route options were originally benign, attackers have learned to put themtomore devious uses. They can use IP source route options to hide their true address and access restrictedareas of a network by specifying a different path. For an example showing how an attacker can put bothdeceptions to use, consider the following scenario as illustrated in Figure 31 on page 186.

185

Figure 31: Loose IP Source Route Option for Deception

JunosOS only allows traffic 2.2.2.0/24 if it comes through ethernet1, an interface bound to zone_external.Devices 3 and 4 enforce access controls but devices 1 and 2 do not. Furthermore, device 2 does not checkfor IP spoofing. The attacker spoofs the source address and, by using the loose source route option, directsthe packet through device 2 to the 2.2.2.0/24 network and from there out device 1. Device 1 forwards itto device 3, which forwards it to the Juniper Networks device. Because the packet came from the 2.2.2.0/24subnet and has a source address from that subnet, it seems to be valid. However, one remnant of theearlier chicanery remains: the loose source route option. In this example, you have enabled the deny IPsource route screen option for zone_external. When the packet arrives at ethernet3, the device rejects it.

You can enable the device to either block any packets with loose or strict source route options set ordetect such packets and then record the event in the counters list for the ingress interface. The screenoptions are as follows:

• Deny IP Source Route Option—Enable this option to block all IP traffic that employs the loose or strictsource route option. Source route options can allow an attacker to enter a networkwith a false IP address.

• Detect IP Loose Source Route Option—The device detects packets where the IP option is 3 (LooseSource Routing) and records the event in the screen counters list for the ingress interface. This optionspecifies a partial route list for a packet to take on its journey from source to destination. The packetmust proceed in the order of addresses specified, but it is allowed to pass through other devices inbetween those specified.

• Detect IP Strict Source RouteOption—The device detects packets where the IP option is 9 (Strict SourceRouting) and records the event in the screen counters list for the ingress interface. This option specifiesthe complete route list for a packet to take on its journey from source to destination. The last addressin the list replaces the address in the destination field. Currently, this screen option is applicable to IPv4only.

186

Example: Blocking Packets with Either a Loose or a Strict Source RouteOption Set

IN THIS SECTION

Requirements | 187

Overview | 187

Configuration | 187

Verification | 188

This example shows how to block packets with either a loose or a strict source route option set.

Requirements

Before you begin, understand how IP source route options work. See “Understanding IP Source RouteOptions” on page 184.

Overview

Source routing allows users at the source of an IP packet transmission to specify the IP addresses of thedevices (also referred to as “hops” ) along the path that they want an IP packet to take on its way to itsdestination. The original intent of the IP source route options was to provide routing control tools to aiddiagnostic analysis.

You can enable the device to either block any packets with loose or strict source route options set ordetect such packets and then record the event in the counters list for the ingress interface.

In this example you create the screen called screen-1 to block packets with either a loose or a strict sourceroute option set and enable the screen in the zone-1 security zone.

Configuration

Step-by-Step ProcedureTo block packets with either the loose or the strict source route option set:


[edit ]

187

user@host# set security screen ids-option screen-1 ip source-route-option





Verification

IN THIS SECTION







[edit]





Screen: screen-1

188

Interfaces bound: 1

Interfaces:

ge-1/0/0.0




[edit]



Name Value

IP source route option enabled

Example: Detecting Packets with Either a Loose or a Strict Source RouteOption Set

IN THIS SECTION

Requirements | 190

Overview | 190

Configuration | 190

Verification | 191

This example shows how to detect packets with either a loose or a strict source route option set.

189

Requirements

Before you begin, understand how IP source route options work. See “Understanding IP Source RouteOptions” on page 184.

Overview

Source routing allows users at the source of an IP packet transmission to specify the IP addresses of thedevices (also referred to as “hops” ) along the path that they want an IP packet to take on its way to itsdestination. The original intent of the IP source route options was to provide routing control tools to aiddiagnostic analysis.

You can enable the device to either block any packets with loose or strict source route options set ordetect such packets and then record the event in the counters list for the ingress interface.

In this example, you create two screens called screen-1 and screen-2 to detect and record, but not block,packets with a loose or strict source route option set and enable the screens in zones zone-1 and zone-2.

Configuration

Step-by-Step ProcedureTo detect and record, but not block, packets with a loose or strict source route option set:

1. Configure the loose source screen.

[edit]user@host# set security screen ids-option screen-1 ip loose-source-route-option

2. Configure the strict source route screen.

[edit]user@host# set security screen ids-option screen-2 ip strict-source-route-option

NOTE: Currently, this screen option supports IPv4 only.

3. Enable the screens in the security zones.

[edit]user@host# set security zones security-zone zone-1 screen screen-1user@host# set security zones security-zone zone-2 screen screen-2

190



Verification

IN THIS SECTION







[edit]





Screen: screen-1

Interfaces bound: 1

Interfaces:

ge-1/0/0.0




Screen: screen-2

Interfaces bound: 1

191

Interfaces:

ge-2/0/0.0




[edit]




Name Value

IP loose source route option enabled

[edit]




Name Value

IP strict source route option enabled




192

attack-thresholdSyntax

attack-threshold number;

Hierarchy Level

[edit security screen ids-option screen-name tcp syn-flood]

Release InformationStatement modified in Junos OS Release 9.2.

DescriptionDefine the number of SYN packets per second required to trigger the SYN proxy response.

Optionsnumber —Number of SYN packets per second required to trigger the SYN proxy response.

Range: 1 through 500,000 per secondDefault: 200 per second

NOTE: For SRX Series devices, the applicable range is 1 through 1.000,000 per second.

Required Privilege Levelsecurity—To view this statement in the configuration.security-control—To add this statement to the configuration.





195

bad-inner-headerSyntax

bad-inner-header;

Hierarchy Level

[edit security screen ids-option ids-option-name ip tunnel]

Release InformationStatement introduced in Junos OS Release 12.3X48-D10.

DescriptionEnable IP tunnel bad inner header IDS option.




196

description (Security Screen)Syntax

description text;

Hierarchy Level

[edit security screen ids-option screen-name]

Release InformationStatement introduced in Junos OS Release 12.1.

DescriptionSpecify descriptive text for a screen.

NOTE: The descriptive text should not include characters, such as “<”, “>”, “&”, or “\n”.

Optionstext—Descriptive text about a screen.

Range: 1 through 300 characters

NOTE: The upper limit of the description text range is related to character encoding, and istherefore dynamic. However, if you configure the descriptive text length beyond 300 characters,the configuration might fail to take effect.





197

destination-ip-basedSyntax

destination-ip-based number;

Hierarchy Level

[edit security screen ids-option screen-name limit-session]


DescriptionLimit the number of concurrent sessions the device can direct to a single destination IP address.

Optionsnumber —Maximum number of concurrent sessions that can be directed to a destination IP address.

Range: 1 through 1,000,000Default: 128

NOTE: For SRX Series devices, the applicable range is 1 through 8,000,000.





198

destination-thresholdSyntax

destination-threshold number ;

Hierarchy Level



DescriptionSpecify the number of SYN segments received per second for a single destination IP address before thedevice begins dropping connection requests to that destination. If a protected host runs multiple services,you might want to set a threshold based only on the destination IP address, regardless of the destinationport number.

Optionsnumber —Number of SYN segments received per second before the device begins dropping connectionrequests.

Range: 4 through 1,000,000 per secondDefault: 4000 per second





attack-threshold | 195

199

fin-no-ackSyntax

fin-no-ack;

Hierarchy Level

[edit security screen ids-option screen-name tcp]


DescriptionEnable detection of an illegal combination of flags, and reject packets that have this combination.





200

flood (Security ICMP)Syntax

flood {threshold number;

}

Hierarchy Level

[edit security screen ids-option screen-name icmp]


DescriptionConfigure the device to detect and prevent Internet Control Message Protocol (ICMP) floods. An ICMPflood occurs when ICMP echo requests are broadcast with the purpose of flooding a systemwith so muchdata that it first slows down, and then times out and is disconnected. The threshold defines the numberof ICMP packets per second allowed to ping the same destination address before the device rejects furtherICMP packets.

Optionsthreshold number —Number of ICMP packets per second allowed to ping the same destination addressbefore the device rejects further ICMP packets.

Range: 1 through 1,000,000 per secondDefault: 1,000 per second

NOTE: For SRX Series devices the applicable range is 1 through 4,000,000 per second.





201


202

flood (Security UDP)Syntax

flood {threshold number;

}

Hierarchy Level

[edit security screen ids-option screen-name udp]


DescriptionConfigure the device to detect and prevent UDP floods. UDP flooding occurs when an attacker sendsUDP packets to slow down the system to the point that it can no longer process valid connection requests.

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

Optionsthreshold number —Number of UDP packets per second allowed to ping the same destination addressbefore the device rejects further UDP packets.

Range: 1 through 1,000,000 per secondDefault: 1,000 per second

NOTE: For SRX series devices the applicable range is 1 through 4,000,000 per second.




203



greSyntax

gre {gre-4in4;gre-4in6;gre-6in4;gre-6in6;

}

Hierarchy Level



DescriptionConfigure IP tunnel GRE IDS option.

Optionsgre-4in4— Enable IP tunnel GRE 4in4 IDS option.

gre-4in6— Enable IP tunnel GRE 4in6 IDS option.






204

icmp (Security Screen)Syntax

icmp {flood {threshold number;

}fragment;icmpv6-malformed;ip-sweep {threshold number;

}large;ping-death;

}

Hierarchy Level



DescriptionConfigure ICMP intrusion detection service (IDS) options.

OptionsThe remaining statements are explained separately. See CLI Explorer.





205

https://www.juniper.net/documentation/content-applications/cli-explorer/junos/

ids-optionSyntax

ids-option screen-name {alarm-without-drop;description text;icmp {flood {threshold number;

}fragment;icmpv6-malformed;ip-sweep {threshold number;

}large;ping-death;

}ip {bad-option;block-frag;ipv6-extension-header {AH-header;ESP-header;HIP-header;}destination-header {ILNP-nonce-option;home-address-option;line-identification-option;tunnel-encapsulation-limit-option;user-defined-option-type <type-low> to <type-high>;

}fragment-header;hop-by-hop-header {CALIPSO-option;RPL-option;SFM-DPD-option;jumbo-payload-option;quick-start-option;router-alert-option;user-defined-option-type <type-low> to <type-high>;

}

206

mobility-header;no-next-header;routing-header;shim6-headeruser-defined-option-type <type-low> to <type-high>;

}ipv6-extension-header-limit limit;ipv6-malformed-header;loose-source-route-option;record-route-option;security-option;source-route-option;spoofing;stream-option;strict-source-route-option;tear-drop;timestamp-option;unknown-protocol;tunnel {gre {gre-4in4;gre-4in6;gre-6in4;gre-6in6;

}ip-in-udp {teredo;


}bad-inner-header;

}}

207

limit-session {destination-ip-based number;source-ip-based number;

}tcp {fin-no-ack;land;port-scan {threshold number;

}syn-ack-ack-proxy {threshold number;

}syn-fin;syn-flood {alarm-threshold number;attack-threshold number;destination-threshold number;source-threshold number;timeout seconds;white-list name {destination-address destination-address;source-address source-address;

}}syn-frag;tcp-no-flag;tcp-sweep {threshold threshold number;

}winnuke;

}udp {flood {threshold number;

}port-scan {threshold number;

}udp-sweep {threshold threshold number;

}}

}

208

}

Hierarchy Level

[edit security screen][edit tenant tenant-name security screen]

Release InformationStatement introduced in Junos OS Release 8.5.Support for the description option added in Junos OS Release 12.1.UDP supports port-scan option starting from Junos OS Release 12.1X47-D10.The tenant option is introduced in Junos OS Release 18.3R1.

DescriptionDefine screens for the intrusion detection service (IDS). An ids-option can be used for enabling the screenprotection on the SRX Series devices. One ids-option can be associated with several zones. However eachzone can be linked with only one ids-option.

209

Optionsdescription text—Descriptive text about a screen.

alarm-without-drop—Direct the device to generate an alarm when detecting an attack but not block theattack.

icmp—Configure the ICMP ids options.

ip—Configure the IP layer ids options.

limit-session—Limit the number of concurrent sessions the device can initiate from a single source IPaddress or the number of sessions it can direct to a single destination IP address.

tcp—Configure the TCP Layer ids options.

udp—Configure the UDP Layer ids options.

loose-source-route-option—The device detects packets where the IP option is 3 (Loose Source Routing)and records the event in the screen counters list for the ingress interface. This option specifies a partialroute list for a packet to take on its journey from source to destination. The packet must proceed in theorder of addresses specified, but it is allowed to pass through other devices in between those specified.

source-route-option—Enable this option to block all IP traffic that employs the loose or strict source routeoption. Source route options can allow an attacker to enter a network with a false IP address.

strict-source-route-option—The device detects packets where the IP option is 9 (Strict Source Routing)and records the event in the screen counters list for the ingress interface. This option specifies the completeroute list for a packet to take on its journey from source to destination. The last address in the list replacesthe address in the destination field. Currently, this screen option is applicable to IPv4 only.

NOTE: Loose source route option and strict source route option will only alarm and will not bedroppedwhen there is overflow of traffic.When only IP source option is configured, the attackedpackets are dropped.

The remaining statements are explained separately. See CLI Explorer.


210





211

ipipSyntax

ipip {ipip-4in4;ipip-4in6;ipip-6in4;ipip-6in6;ipip-6over4;ipip-6to4relay;isatap;dslite;

}

Hierarchy Level



DescriptionConfigure IP tunnel IP-IP IDS options.

Optionsdslite— Enable IP tunnel IP-IP DS-Lite IDS option.

ipip-4in4— Enable IP tunnel IP-IP 4in4 IDS option.




ipip-6over4— Enable IP tunnel IP-IP 6over4 IDS option.

ipip-6to4relay— Enable IP tunnel IP-IP 6to4 Relay IDS option.

isatap— Enable IP tunnel IP-IP ISATAP IDS option.


212



213

ip (Security Screen)Syntax

ip {bad-option;block-frag;ipv6-extension-header {AH-header;ESP-header;HIP-header;destination-header {ILNP-nonce-option;home-address-option;line-identification-option;tunnel-encapsulation-limit-option;user-defined-option-type <type-low> to <type-high>;

}fragment-header;hop-by-hop-header {CALIPSO-option;RPL-option;SFM-DPD-option;jumbo-payload-option;quick-start-option;router-alert-option;user-defined-option-type <type-low> to <type-high>;

}mobility-header;no-next-header;routing-header;shim6-headeruser-defined-option-type <type-low> to <type-high>;

}ipv6-extension-header-limit limit;ipv6-malformed-header;loose-source-route-option;record-route-option;security-option;source-route-option;spoofing;stream-option;strict-source-route-option;tear-drop;

214

timestamp-option;unknown-protocol;tunnel {gre {gre-4in4;gre-4in6;gre-6in4;gre-6in6;

}ip-in-udp {teredo;


}bad-inner-header;

}}

Hierarchy Level


Release InformationStatement introduced in Junos OS Release 8.5. Support for IPv6 bad-option extension header screensadded in Junos OS Release 12.1X46-D10.

DescriptionConfigure IP layer IDS options.

215

Options• bad-option—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 isapplicable to IPv4 and IPv6.

• block-frag—Enable IP packet fragmentation blocking.

• loose-source-route-option—Detect packets where the IP option is 3 (loose source routing), and recordthe event in the screen counters list for the ingress interface. This option specifies a partial route list fora packet to take on its journey from source to destination. The packet must proceed in the order ofaddresses specified, but it is allowed to pass through other devices in between those specified. The type0 routing header of the loose source route option is the only related header defined in IPv6 .

• record-route-option—Detect packets where the IP option is 7 (record route), and record the event inthe screen counters list for the ingress interface. Currently, this screen option is applicable only to IPv4.

• security-option—Detect packets where the IP option is 2 (security), and record the event in the screencounters list for the ingress interface. Currently, this screen option is applicable only to IPv4.

• source-route-option—Detect packets, and record the event in the screen counters list for the ingressinterface.

• spoofing—Prevent spoofing attacks. Spoofing attacks occur when unauthorized agents attempt to bypassfirewall security by imitating valid client IP addresses. Using the spoofing option invalidates such falsesource IP address connections.

The default behavior is to base spoofing decisions on individual interfaces.

• stream-option—Detect packets where the IP option is 8 (stream ID), and record the event in the screencounters list for the ingress interface. Currently, this screen option is applicable only to IPv4.

• strict-source-route-option—Detect packets where the IP option is 9 (strict source routing), and recordthe event in the screen counters list for the ingress interface. This option specifies the complete routelist for a packet to take on its journey from source to destination. The last address in the list replacesthe address in the destination field. Currently, this screen option is applicable only to IPv4.

• tear-drop—Block the teardrop attack. Teardrop attacks occur when fragmented IP packets overlap andcause the host attempting to reassemble the packets to crash. The teardrop option directs the deviceto drop any packets that have such a discrepancy.

• timestamp-option—Detect packets where the IP option list includes option 4 (Internet timestamp), andrecord the event in the screen counters list for the ingress interface. Currently, this screen option isapplicable only to IPv4.

• unknown-protocol—Discard all received IP frames with protocol numbers greater than 137 for IPv4 and139 for IPv6. Such protocol numbers are undefined or reserved.


216




217

ip-sweepSyntax

ip-sweep {threshold number;

}

Hierarchy Level



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

Optionsthreshold number—Maximum number of microseconds during which up to 10 ICMP echo requests fromthe same host are allowed into the device. More than 10 requests from a host during this period triggersan IP Sweep attack response on the device during the remainder of the second.

Range: 1000 through 1,000,000 microsecondsDefault: 5000 microseconds





218

ip-in-udpSyntax

ip-in-udp {teredo;

}

Hierarchy Level



DescriptionConfigure IP tunnel IPinUDP IDS option.

Optionsteredo— Enable IP tunnel IPinUDP Teredo IDS option.




219

landSyntax

land;

Hierarchy Level



DescriptionEnable prevention of Land attacks by combining the SYN flood defense with IP spoofing protection. Landattacks occur when an attacker sends spoofed IP packets with headers containing the target’s IP addressfor the source and destination IP addresses. The attacker sends these packets with the SYN flag set toany available port. The packets induce the target to create empty sessions with itself, filling its sessiontable and overwhelming its resources.





220

largeSyntax

large;

Hierarchy Level



DescriptionConfigure the device to detect and drop any ICMP frame with an IP length greater than 1024 bytes.


221

limit-sessionSyntax

limit-session {destination-ip-based number;source-ip-based number;

}

Hierarchy Level



DescriptionLimit the number of concurrent sessions the device can initiate from a single source IP address or thenumber of sessions it can direct to a single destination IP address.






222


no-syn-checkSyntax

no-syn-check;

Hierarchy Level

[edit security flow tcp-session]


DescriptionDisable checking of the TCP SYN bit before creating a session. By default, the device checks that the SYNbit is set in the first packet of a session. If the bit is not set, the device drops the packet.





223

no-syn-check-in-tunnelSyntax

no-syn-check-in-tunnel;

Hierarchy Level



DescriptionDisable checking of the TCP SYN bit before creating a session for tunneled packets. By default, the devicechecks that the SYN bit is set in the first packet of a VPN session. If the bit is not set, the device drops thepacket.





224

ping-deathSyntax

ping-death;

Hierarchy Level



DescriptionConfigure the device to detect and reject oversized and irregular ICMP packets. Although the TCP/IPspecification requires a specific packet size, many ping implementations allow larger packet sizes. Largerpackets can trigger a range of adverse system reactions, including crashing, freezing, and restarting.





225

port-scanSyntax

port-scan {threshold number;

}

Hierarchy Level



DescriptionPrevent port scan attacks. A port scan attack occurs when an attacker sends packets with different portnumbers to scan available services. The attack succeeds if a port responds. To prevent this attack, thedevice internally logs the number of different ports scanned from a single remote source. For example, ifa remote host scans 10 ports in 0.005 seconds (equivalent to 5000 microseconds, the default thresholdsetting), the device flags this behavior as a port scan attack, and rejects further packets from the remotesource.

Optionsthreshold number —Number of microseconds during which the device accepts packets from the sameremote source with up to 10 different port numbers. If the number of ports during the threshold periodreaches 10 or more, the device rejects additional packets from the source.






226

screen (Security Zones)Syntax

screen screen-name;

Hierarchy Level

[edit security zones functional-zone management],[edit security zones security-zone zone-name]


DescriptionSpecify a security screen for a security zone.

Optionsscreen-name —Name of the screen.





227

source-ip-basedSyntax

source-ip-based number;

Hierarchy Level

[edit security screen ids-option screen-name limit-session ]


DescriptionLimit the number of concurrent sessions the device can initiate from a single source IP address.

Optionsnumber —Maximum number of concurrent sessions that can be initiated from a source IP address.

Range: 1 through 1,000,000Default: 128

NOTE: For SRX Series devices the applicable range is 1 through 8,000,000.





228

source-thresholdSyntax

source-threshold number;

Hierarchy Level



DescriptionSpecify the number of SYN segments that the device can receive per second from a single source IP address(regardless of the destination IP address and port number) before the device begins dropping connectionrequests from that source.

Optionsnumber—Number of SYN segments to be received per second before the device starts dropping connectionrequests.

Range: 4 through 500,000 per secondDefault: 4000 per second

NOTE: For SRX Series devices the applicable range is 4 through 1,000,000 per second.





229

strict-syn-checkSyntax

strict-syn-check;

Hierarchy Level



DescriptionEnable the strict three-way handshake check for the TCP session. It enhances security by dropping datapackets before the three-way handshake is done. By default, strict-syn-check is disabled.





230

syn-ack-ack-proxySyntax

syn-ack-ack-proxy; {threshold number,

}

Hierarchy Level


Release InformationStatement introduced in Junos OS Release 8.5; support for IPv6 addresses added in Junos OS Release10.4.

DescriptionPrevent the SYN-ACK-ACK attack, which occurs when the attacker establishes multiple telnet sessionswithout allowing each session to terminate. This behavior consumes all open slots, generating adenial-of-service (DoS) condition.

Optionsthreshold number — Number of connections from any single IP address.

Range: 1 through 250,000Default: 512





231

syn-check-requiredSyntax

syn-check-required;

Hierarchy Level

[edit security policies from-zone zone-name to-zone zone-name policy policy-name then permit tcp-options]


DescriptionEnable sync check per policy. The syn-check-required value overrides the global value no-syn-check.





232

syn-finSyntax

syn-fin;

Hierarchy Level



DescriptionEnable detection of an illegal combination of flags that attackers can use to consume sessions on the targetdevice, thus resulting in a denial-of-service (DoS) condition.





233

syn-floodSyntax

syn-flood {alarm-threshold number;attack-threshold number;destination-threshold number;source-threshold number;timeout seconds;white-list name {destination-address destination-address;source-address source-address;

}}

Hierarchy Level



DescriptionConfigure detection and prevention of SYN flood attacks. Such attacks occur when the connecting hostcontinuously sends TCP SYN requests without replying to the corresponding ACK responses.





234


syn-flood-protection-modeSyntax

syn-flood-protection-mode (syn-cookie | syn-proxy);

Hierarchy Level

[edit security flow]

Release InformationStatement introduced in Junos OS Release 8.5; support for IPv6 addresses added in Junos OS Release10.4.

DescriptionEnable SYN cookie or SYN proxy defenses against SYN attacks. SYN flood protection mode is enabledglobally on the device and is activated when the configured syn-flood attack-threshold value is exceeded.

Options• syn-cookie—Uses a cryptographic hash to generate a unique Initial Sequence Number (ISN). This isenabled by default.

• syn-proxy—Uses a proxy to handle the SYN attack.

Required Privilege Levelsecurity—To view this in the configuration.security-control—To add this to the configuration.

235

syn-fragSyntax

syn-frag;

Hierarchy Level



DescriptionEnable detection of a SYN fragment attack and drops any packet fragments used for the attack. A SYNfragment 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 thatcannot be completed eventually fills the host’s memory buffer. No further connections are possible, anddamage to the host’s operating system can occur.


236

tcp (Security Screen)Syntax

tcp {fin-no-ack;land;port-scan {threshold number;

}syn-ack-ack-proxy {threshold number;

}syn-fin;syn-flood {alarm-threshold number;attack-threshold number;destination-threshold number;source-threshold number;timeout seconds;white-list name {destination-address destination-address;source-address source-address;

}}syn-frag;tcp-no-flag;tcp-sweep {threshold threshold number;

}winnuke;

}

Hierarchy Level



DescriptionConfigure TCP-layer intrusion detection service (IDS) options.

237





tcp-no-flagSyntax

tcp-no-flag;

Hierarchy Level



DescriptionEnable the device to drop illegal TCP packets with a missing or malformed flag field.


238


tcp-sweepSyntax

tcp-sweep {threshold number;

}

Hierarchy Level



DescriptionConfigure the device to detect and prevent TCP sweep attack. In a TCP sweep attack, an attacker sendsTCP SYN packets to the target device as part of the TCP handshake. If the device responds to thosepackets, the attacker gets an indication that a port in the target device is open, which makes the portvulnerable to attack. If a remote host sends TCP packets to 10 addresses in 0.005 seconds (5000microseconds), then the device flags this as a TCP sweep attack.

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

Optionsthreshold number—Maximum number of microseconds during which up to 10 TCP SYN packets from thesame host are allowed into the device. More than 10 requests from a host during this period triggers TCPSweep attack response on the router during the remainder of the second.






239

timeout (Security Screen)Syntax

timeout seconds;

Hierarchy Level



DescriptionSpecify the maximum length of time before a half-completed connection is dropped from the queue. Youcan decrease the timeout value until you see any connections dropped during normal traffic conditions.

Optionsseconds —Time interval before a half-completed connection is dropped from the queue.

Range: 1 through 50 secondsDefault: 20 seconds





240

traceoptions (Security Screen)Syntax

traceoptions {file {filename;files number;match regular-expression;size maximum-file-size;(world-readable | no-world-readable);

}flag flag;no-remote-trace;

}

Hierarchy Level

[edit security screen]


DescriptionConfigure screen tracing options.

To specify more than one tracing option, include multiple flag statements.

Options• file—Configure the trace file options.

• filename—Name of the file to receive the output of the tracing operation. Enclose the name withinquotation marks. All files are placed in the directory /var/log. By default, the name of the file is thename of the process being traced.

• files number—Maximum number of trace files.When a trace file named trace-file reaches its maximumsize, it is renamed to trace-file.0, then trace-file.1, and so on, until the maximum number of trace filesis reached. The oldest archived file is overwritten.

If you specify a maximum number of files, you also must specify a maximum file size with the sizeoption and a filename.

Range: 2 through 1000 files

Default: 10 files

241

• match regular-expression—Refine the output to include lines that contain the regular expression.

• sizemaximum-file-size—Maximum size of each trace file, in kilobytes (KB), megabytes (MB), or gigabytes(GB).When a trace file named trace-file reaches this size, it is renamed trace-file.0. When the trace-fileagain reaches its maximum size, trace-file.0 is renamed trace-file.1 and trace-file is renamed trace-file.0.This renaming scheme continues until the maximum number of trace files is reached. Then the oldesttrace file is overwritten.

If you specify a maximum file size, you also must specify a maximum number of trace files with thefiles option and a filename.

Syntax: x K to specify KB, xm to specify MB, or x g to specify GB

Range: 10 KB through 1 GB

Default: 128 KB

• world-readable | no-world-readable—By default, log files can be accessed only by the user whoconfigures the tracing operation. The world-readable option enables any user to read the file. Toexplicitly set the default behavior, use the no-world-readable option.

• flag—Trace operation to perform. To specify more than one trace operation, include multiple flagstatements.

• all—Trace all screen events

• configuration—Trace screen configuration events

• flow—Trace flow events

• no-remote-trace—Set remote tracing as disabled.

Required Privilege Leveltrace—To view this statement in the configuration.trace-control—To add this statement to the configuration.




242

trapSyntax

trap {interval trap interval;

}

Hierarchy Level

[edit security screen trap][edit tenant tenant-name security screen]

Release InformationStatement introduced in Junos OS Release 12.3X48-D20.The tenant option is introduced in Junos OS Release 18.3R1.

DescriptionTraps are unsolicited messages sent from an SNMP agent to remote network management systems ortrap receivers. Many enterprises use SNMP traps as part of a fault-monitoring solution, in addition tosystem logging. In Junos OS, SNMP traps are not forwarded by default. You can use the SNMP traps byconfiguring a trap-group.

You can create and name a group of one or more types of SNMP traps and then define which systemsreceive the group of SNMP traps. The name of the trap group is embedded in SNMP trap notificationpackets as one variable binding (varbind) known as the community name.

Optionsinterval—Configure the trap interval.

Range: 1 through 3600 secondsDefault: 2 seconds


243

tunnel (Security Screen)Syntax

tunnel {gre {gre-4in4;gre-4in6;gre-6in4;gre-6in6;

}ip-in-udp {teredo;


}bad-inner-header;

}

Hierarchy Level

[edit security screen ids-option ids-option-name ip]


DescriptionEnable IP tunnel IDS options.

OptionsThe remaining options are explained separately. See CLI Explorer.


244




udp (Security Screen)Syntax

udp {flood {threshold number;

}udp-sweep {threshold threshold number;

}}

Hierarchy Level



DescriptionSpecify the number of packets allowed per second to the same destination IP address/port pair. Whenthe number of packets exceeds this value within any 1-second period, the device generates an alarm anddrops subsequent packets for the remainder of that second.






245


udp-sweepSyntax

udp-sweep {threshold number;

}

Hierarchy Level

[edit security screen ids-option screen-name udp]


DescriptionConfigure the device to detect and prevent UDP sweep attack. In a UDP sweep attack, an attacker sendsUDP packets to the target device. If the device responds to those packets, the attacker gets an indicationthat a port in the target device is open, which makes the port vulnerable to attack. If a remote host sendsUDP packets to 10 addresses in 0.005 seconds (5000 microseconds), then the device flags this as an UDPsweep attack.

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

Optionsthreshold number—Maximum number of microseconds during which up to 10 UDP packets from the samehost are allowed into the device. More than 10 requests from a host during this period triggers an UDPSweep attack response on the device during the remainder of the second.






246

white-listSyntax

white-list name {destination-address [address];source-address [address];

}

Hierarchy Level

[edit security screen ids-option screen-name tcp syn-flood][edit security screen ids-option screen-name udp flood][edit tenants tenant-name security screen]

Release InformationStatement introduced in Junos OS Release 12.1.Statement for UDP flood screen whitelist introduced in Junos OS Release 17.4.The tenant option is introduced in Junos OS Release 18.3R1.

DescriptionConfigure awhitelist of IP addresses that are to be exempt from the SYN cookie and SYNproxymechanismsthat occur during the SYN flood screen protection process.

Configure a whitelist of IP addresses to bypass UDP flood detection.

NOTE: UDP flood screen whitelist is not supported on SRX5400, SRX5600, and SRX5800devices.

Both IP version 4 (IPv4) and IP version 6 (IPv6) whitelists are supported. Addresses in a whitelist must beall IPv4 or all IPv6. Each whitelist can have up to 32 IP address prefixes.

Options• name—The name of the white-list.

• destination-address address—Destination IP address or an address prefix. You can configure multipleaddresses or address prefixes separated by spaces and enclosed in square brackets.

• source-address address—Source IP address or an address prefix. You can configure multiple addressesor address prefixes separated by spaces and enclosed in square brackets.

Required Privilege Level

247

security—To view this statement in the configuration.security-control—To add this statement to the configuration.




winnukeSyntax

winnuke;

Hierarchy Level



DescriptionEnable detection of attacks onWindows NetBios communications. Packets are modified as necessary andpassed on. Each WinNuke attack triggers an attack log entry in the event alarm log.





248

6CHAPTER

Operational Commands

clear security screen statistics | 251



show security screen ids-option | 257


show security screen status | 278

show security screen white-list | 279

clear security screen statisticsSyntax

clear security screen statistics<node ( node-id | all | local | primary)>

Release InformationCommand introduced in Junos OS Release 9.0.

DescriptionClear intrusion detection service (IDS) security screen statistics on the device.

Optionsnode—(Optional) For chassis cluster configurations, clear security screen statistics on a specific node.

• node-id —Identification number of the node. It can be 0 or 1.

• all —Clear all nodes.

• local —Clear the local node.

• primary—Clear the primary node.

Required Privilege Levelclear




List of Sample Outputclear security screen statistics node 0 on page 252

Output FieldsThis command produces no output.

251

Sample Output

clear security screen statistics node 0

user@host> clear security screen statistics node 0

252

clear security screen statistics interfaceSyntax

clear security screen statistics interface interface-namelogical-systemroot-logical-systemtenant

Release InformationCommand introduced in Junos OS Release 8.5.The node option is added in Junos OS Release 9.0.The tenant option is introduced in Junos OS Release 18.3R1.

DescriptionClear intrusion detection service (IDS) security screen statistics for an interface under one specific logicalsystem or a tenant system.

Optionsinterface-name—Name of the interface on which to clear security screen statistics.

logical-system—Name of the logical system.

root-logical-system—(Default) Displays root logical system as default.

tenant—The name of the tenant system.





List of Sample Outputclear security screen statistics interface fab0 on page 254clear security screen statistics interface fab0 node 0 on page 254clear security screen statistics tenant all interface ge-10/0/1 on page 254

Output FieldsWhen you enter this command, you are provided feedback on the status of your request.

253

Sample Output

clear security screen statistics interface fab0

user@host> clear security screen statistics interface fab0

node0:

--------------------------------------------------------------------------

IDS statistics has been cleared.

node1:

--------------------------------------------------------------------------


Sample Output

clear security screen statistics interface fab0 node 0

user@host> clear security screen statistics interface fab0 node 0

node0:

--------------------------------------------------------------------------


clear security screen statistics tenant all interface ge-10/0/1

user@host> clear security screen statistics tenant all interface ge-10/0/1


254

clear security screen statistics zoneSyntax

clear security screen statistics zone <zone-name>logical-systemroot-logical-systemtenant

Release InformationCommand introduced in Junos OS Release 8.5.The node option is added in Junos OS Release 9.0.The tenant option is added in Junos OS Release 18.3R1.

DescriptionClear IDS security screen statistics for a security zone under all or a specific logical systems or tenantsystems.

Optionszone <zone-name>—Name of the security zone.








List of Sample Outputclear security screen statistics zone abc node all on page 256clear security screen statistics node 0 zone my-zone on page 256clear security screen statistics tenant TN1 zone trust on page 256clear security screen statistics tenant all zone trust on page 256

Output FieldsWhen you enter this command, you are provided feedback on the status of your request.

255

Sample Output

clear security screen statistics zone abc node all

user@host> clear security screen statistics zone abc node all

node0:

--------------------------------------------------------------------------


node1:

--------------------------------------------------------------------------


Sample Output

clear security screen statistics node 0 zone my-zone

user@host> clear security screen statistics node 0 zone my-zone

node0:

--------------------------------------------------------------------------


clear security screen statistics tenant TN1 zone trust

user@host> clear security screen statistics tenant TN1 zone trust


clear security screen statistics tenant all zone trust

user@host> clear security screen statistics tenant all zone trust


256

show security screen ids-optionSyntax

show security screen ids-optionscreen-namelogical-systemroot-logical-systemtenant

Release InformationCommand introduced in Junos OS Release 8.5. Support for UDP port scan added in Junos OS Release12.1X47-D10.Support for node option added in Junos OS Release 9.0.Support for IPv6 extension header screens added in Junos OS Release 12.1X46-D10.The tenant option is introduced in Junos OS Release 18.3R1.

DescriptionDisplay the configuration information about the specified security screen. You can configure a ids-optionto enable screen protection on the SRX Series devices.

Options• screen-name —Name of the screen.

• logical-system—Name of the logical system.

• root-logical-system—Displays root logical system as default.

• tenant—Name of the tenant system.

Required Privilege Levelview


ids-option | 206


List of Sample Outputshow security screen ids-option jscreen on page 260show security screen ids-option jscreen (IPv6) on page 261show security screen ids-option jscreen1 node all on page 262show security screen ids-option jscreen tenant TN1 on page 262

257

show security screen ids-option jscreen tenant all on page 263

Output FieldsTable 12 on page 258 lists the output fields for the show security screen ids-option command. Outputfields are listed in the approximate order in which they appear.

Table 12: show security screen ids-option Output Fields

Field DescriptionField Name

Number of microseconds for which the device accepts 10 TCP packets from thesame remote source to different destination addresses.

TCP address sweep threshold

Number of microseconds during which the device accepts packets from the sameremote source with up to 10 different port numbers.

TCP port scan threshold

Number of microseconds during which up to 10 ICMP echo requests from thesame host are allowed into the device.

ICMP address sweep threshold

Number of UDP packets per second allowed to ping the same destination addressbefore the device rejects further UDP packets.

UDP flood threshold

Number of microseconds during which the device accepts packets from the sameremote source IP with up to 10 different destination port numbers.

UDP port scan threshold

Enable or disable the detection of TCP WinNuke attacks.TCP winnuke

Number of SYN packets per second required to trigger the SYN proxy response.TCP SYN flood attack threshold

Number of half-complete proxy connections per second at which the devicemakesentries in the event alarm log.

TCP SYN flood alarm threshold

Number of SYN segments to be received per second before the device beginsdropping connection requests.

TCP SYN flood source threshold

Number of SYN segments received per second before the device begins droppingconnection requests.

TCP SYN flood destinationthreshold

Maximum length of time before a half-completed connection is dropped from thequeue.

TCP SYN flood timeout

Number of proxy connection requests that can be held in the proxy connectionqueue before the device begins rejecting new connection requests.

TCP SYN flood queue size

Enable or disable the detection of any ICMP frame with an IP length greater than1024 bytes.

ICMP large packet

258

Table 12: show security screen ids-option Output Fields (continued)


Number of microseconds for which the device accepts 10 UDP packets from thesame remote source to different destination addresses.

UDP address sweep threshold

Enable or disable the IPv6 extension routing screen option.IPv6 extension routing

Enable or disable the IPv6 extension shim6 screen option.IPv6 extension shim6

Enable or disable the IPv6 extension fragment screen option.IPv6extension fragment/IPblockfragment

Enable or disable the IPv6 extensionAuthenticationHeader Protocol screen option.IPv6 extension AH

Enable or disable the IPv6 extension Encapsulating Security Payload screen option.IPv6 extension ESP

Enable or disable the IPv6 extension mobility screen option.IPv6 extension mobility

Enable or disable the IPv6 extension Host Identify Protocol screen option.IPv6 extension HIP

Enable or disable the IPv6 extension no-next screen option.IPv6 extension no next

Enable or disable the IPv6 extension user-defined screen option.IPv6 extension user-defined

Enable or disable the IPv6 extension HbyH jumbo screen option.IPv6 extension HbyH jumbo

Enable or disable the IPv6 extension HbyH RPL screen option.IPv6 extension HbyH RPL

Enable or disable the IPv6 extension HbyH router screen option.IPv6 extensionHbyH router alert

Enable or disable the IPv6 extension HbyH quick-start screen option.IPv6 extension HbyH quick start

Enable or disable the IPv6 extension HbyH Common Architecture Label IPv6Security Screen option.

IPv6 extension HbyH CALIPSO

Enable or disable the IPv6 extension HbyH Simplified Multicast Forwarding IPv6Duplicate Packet Detection screen option.

IPv6 extension HbyH SMF DPD

Enable or disable the IPv6 extension HbyH user-defined screen option.IPv6 extension HbyHuser-defined

Enable or disable the IPv6 extension distributed (network) storage tunnelencapsulation limit screen option.

IPv6 extension Dst tunnel encaplimit

259

Table 12: show security screen ids-option Output Fields (continued)


Enable or disable the IPv6 extension DST home address screen option.IPv6 extensionDst homeaddress

Enable or disable the IPv6 extension DST Identifier-Locator Network Protocolnonce screen option.

IPv6 extension Dst ILNP nonce

Enable or disable the IPv6 extension DST line-ID screen option.IPv6 extension Dst line-id

Enable or disable the IPv6 extension DST user-defined screen option.IPv6 extension Dst user-defined

Threshold for the number of IPv6 extension headers that can pass through thescreen.

IPv6 extension header limit

Enable or disable the IPv6 malformed header screen option.IPv6 malformed header

Enable or disable the ICMPv6 malformed packet screen option.ICMPv6 malformed header

Whitelist of IP addresses to bypass UDP flood detection.UDP flood white-list

Limit the number of concurrent sessions the device can initiate from a single sourceIP address or the number of sessions it can direct to a single destination IP address.

Session source limit threshold

Name of the logical system or tenant system.Logical system/Tenant

Sample Output

show security screen ids-option jscreen



Name Value


UDP port scan threshold 10000


260

Sample Output

show security screen ids-option jscreen (IPv6)



Name Value

ICMP ping of death enabled

……

IPv6 extension routing enabled

IPv6 extension shim6 enabled

IPv6 extension fragment enabled

IPv6 extension AH enabled

IPv6 extension ESP enabled

IPv6 extension mobility enabled

IPv6 extension HIP enabled

IPv6 extension no next enabled

IPv6 extension user-defined enabled

IPv6 extension HbyH jumbo enabled

IPv6 extension HbyH RPL enabled

IPv6 extension HbyH router alert enabled

IPv6 extension HbyH quick start enabled

IPv6 extension HbyH CALIPSO enabled

IPv6 extension HbyH SMF DPD enabled

IPv6 extension HbyH user-defined enabled

IPv6 extension Dst tunnel encap limit enabled

IPv6 extension Dst home address enabled

IPv6 extension Dst ILNP nonce enabled

IPv6 extension Dst line-id enabled

IPv6 extension Dst user-defined enabled

IPv6 extension header limit 20

IPv6 Malformed header enabled

ICMPv6 malformed packet enabled

261

Sample Output

show security screen ids-option jscreen1 node all

user@host> show security screen ids-option jscreen1 node all

node0:

--------------------------------------------------------------------------


Name Value


TCP winnuke enabled






TCP SYN flood queue size 1024


node1:

--------------------------------------------------------------------------


Name Value


TCP winnuke enabled






TCP SYN flood queue size 1024


show security screen ids-option jscreen tenant TN1

user@host> show security screen ids-option jscreen tenant TN1


Name value


UDP flood white-list a1

262


show security screen ids-option jscreen tenant all

user@host> show security screen ids-option jscreen tenant all

Logical system: root-logical-system


Name value




IP block fragment enabled


Tenant: TN1


Name value




263

show security screen statisticsSyntax

show security screen statistics <zone zone-name | interface interface-name>logical-system <logical-system-name | all>root-logical-systemtenant <tenant-name >

Release InformationCommand introduced in Junos OS Release 8.5.The node option added in Junos OS Release 9.0.The logical-system all option added in Junos OS Release 11.2R6.Support for IPv6 extension header screens added in Junos OS Release 12.1X46-D10.The tenant option is introduced in Junos OS Release 18.3R1.

DescriptionDisplay intrusion detection service (IDS) security screen statistics.

Options• zone zone-name—Display screen statistics for this security zone.

• interface interface-name —Display screen statistics for this interface.

• logical-system-name—Display screen statistics for the named logical system.

• root-logical-system—(Optional) Display screen statistics for the master logical system only.

• tenant—Display the name of the tenant system.



clear security screen statistics | 251




List of Sample Outputshow security screen statistics zone scrzone on page 267show security screen statistics zone untrust (IPv6) on page 268

264

show security screen statistics interface ge-0/0/3 on page 269show security screen statistics interface ge-0/0/1 (IPv6) on page 270show security screen statistics interface ge-0/0/1 node primary on page 270show security screen statistics zone trust logical-system all on page 271show security screen statistics zone trust tenant TN1 on page 274show security screen statistics zone trust tenant all on page 275

Output FieldsTable 13 on page 265 lists the output fields for the show security screen statistics command. Output fieldsare listed in the approximate order in which they appear.

Table 13: show security screen statistics Output Fields


Internet Control Message Protocol (ICMP) flood counter. An ICMP flood typicallyoccurs when ICMP echo requests use all resources in responding, such that validnetwork traffic can no longer be processed.

ICMP flood

User Datagram Protocol (UDP) flood counter. UDP flooding occurs when anattacker sends IP packets containing UDP datagrams with the purpose of slowingdown the resources, such that valid connections can no longer be handled.

UDP flood

Number of Transport Control Protocol (TCP) WinNuke attacks. WinNuke is adenial-of-service (DoS) attack targeting any computer on the Internet runningWindows.

TCP winnuke

Number of TCP port scans. The purpose of this attack is to scan the availableservices in the hopes that at least one port will respond, thus identifying a serviceto target.

TCP port scan

Number of ICMP address sweeps. An IP address sweep can occur with the intentof triggering responses from active hosts.

ICMP address sweep

Number of teardrop attacks. Teardrop attacks exploit the reassembly of fragmentedIP packets.

IP tear drop

Number of TCP SYN attacks.TCP SYN flood

Number of IP spoofs. IP spoofing occurs when an invalid source address is insertedin the packet header to make the packet appear to come from a trusted source.

IP spoofing

ICMP ping of death counter. Ping of death occurs when IP packets are sent thatexceed the maximum legal length (65,535 bytes).

ICMP ping of death

265

Table 13: show security screen statistics Output Fields (continued)


Number of IP source route attacks.IP source route option

Number of TCP address sweeps.TCP address sweep

Number of land attacks. Land attacks occur when an attacker sends spoofed SYNpackets containing the IP address of the victim as both the destination and sourceIP address.

TCP land attack

Number of TCP SYN fragments.TCP SYN fragment

Number of TCP headers without flags set. A normal TCP segment header has atleast one control flag set.

TCP no flag

Number of IPs.IP unknown protocol

Number of invalid options.IP bad options

Number of packets with the IP record route option enabled. This option recordsthe IP addresses of the network devices along the path that the IP packet travels.

IP record route option

Number of IP timestamp option attacks. This option records the time (in UniversalTime) when each network device receives the packet during its trip from the pointof origin to its destination.

IP timestamp option

Number of IP security option attacks.IP security option

Number of IP loose source route option attacks. This option specifies a partialroute list for a packet to take on its journey from source to destination.

IP loose source route option

Number of IP strict source route option attacks. This option specifies the completeroute list for a packet to take on its journey from source to destination.

IP strict source route option

Number of stream option attacks. This option provides a way for the 16-bitSATNET stream identifier to be carried through networks that do not supportstreams.

IP stream option

Number of ICMP fragments. Because ICMP packets contain very short messages,there is no legitimate reason for ICMP packets to be fragmented. If an ICMP packetis so large that it must be fragmented, something is amiss.

ICMP fragment

Number of large ICMP packets.ICMP large packet

266

Table 13: show security screen statistics Output Fields (continued)


Number of TCP SYN FIN packets.TCP SYN FIN

Number of TCP FIN flags without the acknowledge (ACK) flag.TCP FIN no ACK

Number of concurrent sessions that can be initiated from a source IP address.Source session limit

Number of TCP flags enabled with SYN-ACK-ACK. To prevent flooding withSYN-ACK-ACK sessions, you can enable the SYN-ACK-ACK proxy protectionscreen option. After the number of connections from the same IP address reachesthe SYN-ACK-ACK proxy threshold and SRX Series devices running Junos OSreject further connection requests from that IP address.

TCP SYN-ACK-ACK proxy

Number of IP block fragments.IP block fragment

Number of concurrent sessions that can be directed to a single destination IPaddress.

Destination session limit

Number of UDP address sweeps.UDP address sweep

Number of packets filtered for the defined IPv6 extension headers.IPv6 extension header

Number of packets filtered for the defined IPv6 hop-by-hop option types.IPv6 extensionhopbyhopoption

Number of packets filtered for the defined IPv6 destination option types.IPv6extensiondestinationoption

Number of packets filtered for crossing the defined IPv6 extension header limit.IPv6 extension header limit

Number of IPv6 malformed headers defined for the intrusion detection service(IDS).

IPv6 malformed header

Number of ICMPv6 malformed packets defined for the IDS options.ICMPv6 malformed packet

Sample Output

show security screen statistics zone scrzone

user@host> show security screen statistics zone scrzone

267

Screen statistics:


ICMP flood 0

UDP flood 0

TCP winnuke 0

TCP port scan 91

ICMP address sweep 0

TCP sweep 0

UDP sweep 0

IP tear drop 0

TCP SYN flood 0

IP spoofing 0

ICMP ping of death 0

IP source route option 0

TCP land attack 0

TCP SYN fragment 0

TCP no flag 0

IP unknown protocol 0

IP bad options 0

IP record route option 0

IP timestamp option 0

IP security option 0

IP loose source route option 0

IP strict source route option 0

IP stream option 0

ICMP fragment 0

ICMP large packet 0

TCP SYN FIN 0

TCP FIN no ACK 0

Source session limit 0

TCP SYN-ACK-ACK proxy 0

IP block fragment 0

Destination session limit 0

Sample Output

show security screen statistics zone untrust (IPv6)

user@host>show security screen statistics zone untrust

Screen statistics:

268


ICMP flood 0

UDP flood 0

TCP winnuke 0

……

IPv6 extension header 0

IPv6 extension hop by hop option 0

IPv6 extension destination option 0


IPv6 malformed header 0

ICMPv6 malformed packet 0

Sample Output

show security screen statistics interface ge-0/0/3

user@host> show security screen statistics interface ge-0/0/3

Screen statistics:


ICMP flood 0

UDP flood 0

TCP winnuke 0

TCP port scan 91


TCP sweep 0

UDP sweep 0

IP tear drop 0

TCP SYN flood 0

IP spoofing 0



TCP land attack 0

TCP SYN fragment 0

TCP no flag 0


IP bad options 0





269


IP stream option 0

ICMP fragment 0

ICMP large packet 0

TCP SYN FIN 0

TCP FIN no ACK 0



IP block fragment 0


Sample Output

show security screen statistics interface ge-0/0/1 (IPv6)

user@host> show security screen statistics interface ge-0/0/1

Screen statistics:


ICMP flood 0

UDP flood 0

……







Sample Output

show security screen statistics interface ge-0/0/1 node primary

user@host> show security screen statistics interface ge-0/0/1 node primary

node0:

--------------------------------------------------------------------------

270

Screen statistics:


ICMP flood 1

UDP flood 1

TCP winnuke 1

TCP port scan 1


TCP sweep 1

UDP sweep 1

IP tear drop 1

TCP SYN flood 1

IP spoofing 1



TCP land attack 1

TCP SYN fragment 1

TCP no flag 1


IP bad options 1






IP stream option 1

ICMP fragment 1

ICMP large packet 1

TCP SYN FIN 1

TCP FIN no ACK 1



IP block fragment 1


Sample Output

show security screen statistics zone trust logical-system all

user@host> show security screen statistics zone trust logical-system all


Screen statistics:

271


ICMP flood 0

UDP flood 0

TCP winnuke 0

TCP port scan 0


TCP sweep 0

UDP sweep 0

IP tear drop 0

TCP SYN flood 0

IP spoofing 0



TCP land attack 0

TCP SYN fragment 0

TCP no flag 0


IP bad options 0






IP stream option 0

ICMP fragment 0

ICMP large packet 0

TCP SYN FIN 0

TCP FIN no ACK 0



IP block fragment 0


Logical system: ls1

Screen statistics:


ICMP flood 0

UDP flood 0

TCP winnuke 0

TCP port scan 0


TCP sweep 0

272

UDP sweep 0

IP tear drop 0

TCP SYN flood 0

IP spoofing 0



TCP land attack 0

TCP SYN fragment 0

TCP no flag 0


IP bad options 0






IP stream option 0

ICMP fragment 0

ICMP large packet 0

TCP SYN FIN 0

TCP FIN no ACK 0



IP block fragment 0


Logical system: ls2

Screen statistics:


ICMP flood 0

UDP flood 0

TCP winnuke 0

TCP port scan 0


TCP sweep 0

UDP sweep 0

IP tear drop 0

TCP SYN flood 0

IP spoofing 0



TCP land attack 0

TCP SYN fragment 0

273

TCP no flag 0


IP bad options 0






IP stream option 0

ICMP fragment 0

ICMP large packet 0

TCP SYN FIN 0

TCP FIN no ACK 0



IP block fragment 0


show security screen statistics zone trust tenant TN1

user@host> show security screen statistics zone trust tenant TN1

Screen statistics:


ICMP flood 0

UDP flood 0

TCP winnuke 0

TCP port scan 0

UDP port scan 0


TCP sweep 0

UDP sweep 0

IP tear drop 0

TCP SYN flood 0

SYN flood source 0

SYN flood destination 0

IP spoofing 0



TCP land attack 0

TCP SYN fragment 0

TCP no flag 0

274


IP bad options 0






IP stream option 0

ICMP fragment 0

ICMP large packet 0

TCP SYN FIN 0

TCP FIN no ACK 0



IP block fragment 0








IP tunnel summary 0

show security screen statistics zone trust tenant all

user@host> show security screen statistics zone trust tenant all


creen statistics:


ICMP flood 0

UDP flood 0

TCP winnuke 0

TCP port scan 0

UDP port scan 0


TCP sweep 0

UDP sweep 0

IP tear drop 0

TCP SYN flood 0

SYN flood source 0

275


IP spoofing 0



TCP land attack 0

TCP SYN fragment 0

TCP no flag 0


IP bad options 0






IP stream option 0

ICMP fragment 0

ICMP large packet 0

TCP SYN FIN 0

TCP FIN no ACK 0



IP block fragment 0








IP tunnel summary 0

Tenant: TN1

Screen statistics:


ICMP flood 0

UDP flood 0

TCP winnuke 0

TCP port scan 0

UDP port scan 0


TCP sweep 0

UDP sweep 0

IP tear drop 0

276

TCP SYN flood 0

SYN flood source 0


IP spoofing 0



TCP land attack 0

TCP SYN fragment 0

TCP no flag 0


IP bad options 0






IP stream option 0

ICMP fragment 0

ICMP large packet 0

TCP SYN FIN 0

TCP FIN no ACK 0



IP block fragment 0








IP tunnel summary 0

277

show security screen statusSyntax

show security screen status

Release InformationCommand introduced in Junos OS Release 12.3X48-D20.

DescriptionShow screen status data.


List of Sample Outputshow security screen status on page 278

Sample Output

show security screen status

user@host> show security screen status

Screen status:

Screen trap interval : 2 second(s)

278

show security screen white-listSyntax

show security screen white-list<wlist-name>logical-systemroot-logical-systemtenant

Release InformationStatement introduced in Junos OS Release 12.1.Statement for UDP flood screen whitelist introduced in Junos OS Release 17.4.The tenant option is introduced in Junos OS Release 18.3R1.

DescriptionDisplay a set of IP addresses for whitelist. Whitelists allows users to download files that are known to besafe. Whitelists can be added to in order to decrease false positives.

Optionswlist-name—The name of the whitelist.






white-list | 247


List of Sample Outputshow security screen white-list a1 tenant TN1 on page 280show security screen white-list a1 tenant all on page 280

Output FieldsTable 12 on page 258 lists the output fields for the show security screen ids-option command. Outputfields are listed in the approximate order in which they appear.

279

Table 14: show security screen ids-option Output Fields


Name of the logical system.Logical system

Name of the tenant system.Tenant

Display the whitelist of IP addresses.Screen white list

Sample Output

show security screen white-list a1 tenant TN1

user@host> show security screen white-list a1 tenant TN1

Screen white list:

21.23.24.25/32

21.23.24.251/32

Sample Output

show security screen white-list a1 tenant all

user@host> show security screen white-list a1 tenant all


Screen white list:

2001::2/128

2001::23/128

Tenant: TN1

Screen white list:

21.23.24.25/32

21.23.24.251/32

280

junos® os attack detection and ... - juniper networks · understandinglandattacks|112...

Documents