jnxJsScreenMonEntry

jnxJsScreenMonTable 1

The screen option monitoring statistics entry. Each entry is uniquely identified by the zone name.

The data is collected on a per zone basis. There can be multiple interfaces bound to a particular zone. Hence, the statistics are aggregated across the interfaces on a per zone basis.

Sequence of parameters:

• jnxJsScreenZoneName
• jnxJsScreenNumOfIf
• jnxJsScreenMonSynAttk
• jnxJsScreenMonTearDrop
• jnxJsScreenMonSrcRoute
• jnxJsScreenMonPingDeath
• jnxJsScreenMonAddrSpoof
• jnxJsScreenMonLand
• jnxJsScreenMonIcmpFlood
• jnxJsScreenMonUdpFlood
• jnxJsScreenMonWinnuke
• jnxJsScreenMonPortScan
• jnxJsScreenMonIpSweep
• jnxJsScreenMonSynFrag
• jnxJsScreenMonTcpNoFlag
• jnxJsScreenMonIpUnknownProt
• jnxJsScreenMonIpOptBad
• jnxJsScreenMonIpOptRecRt—Record route option
• jnxJsScreenMonIpOptTimestamp—Timestamp option
• jnxJsScreenMonIpOptSecurity
• jnxJsScreenMonIpOptLSR—Loose source route
• jnxJsScreenMonIpOptSSR—Strict source route
• jnxJsScreenMonIpOptStream—Stream options
• jnxJsScreenMonIcmpFrag
• jnxJsScreenMonIcmpLarge
• jnxJsScreenMonTcpSynFin
• jnxJsScreenMonTcpFinNoAck
• jnxJsScreenMonLimitSessSrc—Session limit (source IP-based)

• jnxJsScreenMonLimitSessDest—Session limit (destination IP-based)
• jnxJsScreenMonSynAckAck
• jnxJsScreenMonIpFrag
• jnxJsScreenSynAttackThresh—Threshold data
• jnxJsScreenSynAttackThresh—Threshold data
• jnxJsScreenSynAttackTimeout—Threshold data
• jnxJsScreenSynAttackAlmTh—Threshold data
• jnxJsScreenSynAttackQueSize—Threshold data
• jnxJsScreenSynAttackAgeTime—Threshold data (obsolete in this release)
• jnxJsScreenIcmpFloodThresh—Threshold data
• jnxJsScreenUdpFloodThresh—Threshold data
• jnxJsScreenPortScanThresh—Threshold data
• jnxJsScreenIpSweepThresh—Threshold data
• jnxJsScreenSynAckAckThres—Threshold data

jnxJsScreenZoneName

jnxJsScreenMonEntry 1

Name of the security zone under which the statistics are collected

jnxJsScreenNumOfIf

jnxJsScreenMonEntry 2

Number of interfaces bound to this zone. Each counter contains the aggregated data of all the interfaces.

jnxJsScreenMonSynAttk

jnxJsScreenMonEntry 3

Number of SYN (TCP connection request) attacks.

A SYN attack is a common denial of service (DoS) technique characterized by the following pattern:

• Using a spoofed IP address not in use on the Internet, an attacker sends multiple SYN packets to the target machine.
• For each SYN packet received, the target machine allocates resources and sends an acknowledgement (SYN-ACK) to the source IP address. This can cause the target machine to allocate resources for more than 3 minutes to respond to just one SYN attack, subsequently wasting resources.

jnxJsScreenMonTearDrop

jnxJsScreenMonEntry 4

Number of teardrop attacks.

Teardrop attacks exploit the reassembly of fragmented IP packets. In the IP header, one of the fields is the fragment offset field, which indicates the starting position of the data contained in a fragmented packet relative to the data of the original unfragmented packet. When the sum of the offset and size of one fragmented packet differ from that of the next fragmented packet, the packets overlap. The server attempting to reassemble the packet can crash, especially if it is running an older operating system that has this vulnerability.

When this option is enabled, the security device detects this discrepancy in a fragmented packet and drops it, and counts the number of packet dropped.

jnxJsScreenMonSrcRoute

jnxJsScreenMonEntry 5

Number of either loose source route option packets or strict source route attack packets.

IP source route options can be used to hide their true address and access restricted areas of a network by specifying a different path. The security device should be able to either block any packets with loose or strict source route options set or detect such packets and then record the event for the ingress interface.

jnxJsScreenMonPingDeath

jnxJsScreenMonEntry 6

Number of ping-of-death attack packets.

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

Many ping implementations, however, allow the user to specify a packet size larger than 65,507 bytes. A grossly oversized ICMP packet can trigger a range of adverse system reactions, such as DoS, crashing, freezing, and rebooting.

When the ping-of-death option is enabled, the security device detects and rejects such oversized and irregular packet sizes, even when the attacker hides the total packet size by purposefully fragmenting it.

jnxJsScreenMonAddrSpoof

jnxJsScreenMonEntry 7

Number of address spoofing attack packets.

One method to gain access to a restricted network is to insert a bogus source address in the packet header to make the packet appear to come from a trusted source. This technique is called IP spoofing. The mechanism to detect IP spoofing relies on route table entries.

For example, if a packet with source IP address 10.1.1.6 arrives at port eth3, but the security device has a route to 10.1.1.0/24 through port eth1, IP spoofing checking notes that this address arrived at an invalid interface as defined in the route table. A valid packet from 10.1.1.6 can arrive only via eth1, not eth3. The security device concludes that the packet has a spoofed source IP address and discards it.

jnxJsScreenMonLand

jnxJsScreenMonEntry 8

Number of land attack packets.

A SYN attack combined with an IP spoof is referred to as land attack. A land attack occurs when an attacker sends spoofed SYN packets containing the IP address of the victim as both the destination and source IP address. The receiving victim responds by sending the SYN-ACK packet to itself, creating an empty connection that lasts until the idle timeout value is reached. Flooding a system with such empty connections can overwhelm the victim, causing a DoS.

jnxJsScreenMonIcmpFlood

jnxJsScreenMonEntry 9

Number of ICMP flood attack packets.

An ICMP flood typically occurs when ICMP echo requests overload a victim with so many requests that the victim expends all its resources responding to the ICMP echo requests until it can no longer process valid network traffic. With ICMP flood protection enabled and a threshold set, if the threshold is exceeded, the victim invokes the flood attack protection feature.

The default threshold value is 1000 packets per second. If the threshold is exceeded, the security device ignores further ICMP echo requests for the remainder of that second plus the next second as well.

jnxJsScreenMonUdpFlood

jnxJsScreenMonEntry 10

Number of UDP flood attack packets.

UDP flooding occurs when an attacker sends IP packets containing UDP datagrams with the purpose of slowing down the victim to the point that it can no longer handle valid connections. With UDP flood protection enabled, a threshold can be set so that when the threshold is exceeded, the system invokes UDP flood attack protection.

The default threshold value is 1000 packets per second. If the number of UDP datagrams from one or more sources to a single destination exceeds this threshold, the security device ignores further UDP datagrams to that destination for the remainder of that second plus the next second as well.

jnxJsScreenMonWinnuke

jnxJsScreenMonEntry 11

Number of NetBIOS attacks.

WinNuke is a DoS attack targeting any computer on the Internet running Microsoft Windows. The attacker sends a TCP segment, usually to NetBIOS port 139 of a host with an established connection with segment's urgent (URG) flag set. This practice introduces a NetBIOS fragment overlap, which causes many machines running Microsoft Windows to crash.

jnxJsScreenMonPortScan

jnxJsScreenMonEntry 12

Number of port scan attempt attack packets.

A port scan occurs when one source IP address sends IP packets containing TCP SYN segments to a defined number of different ports at the same destination IP address within a defined interval. The purpose of this attack is to scan the available services in the hope that at least one port will respond, thus identifying a service of the target. The security device should internally log the number of different ports scanned from one remote source.

jnxJsScreenMonIpSweep

jnxJsScreenMonEntry 13

Number of address sweep attemp attack packets.

An address sweep occurs when one source IP address sends a defined number of ICMP packets to different hosts within a defined interval. The purpose of this attack is to send ICMP packets, typically echo requests, to various hosts in the hope that at least one replies, thus uncovering an address of the target. The security device internally logs the number of ICMP packets to different addresses from one remote source.

jnxJsScreenMonSynFrag

jnxJsScreenMonEntry 14

Number of SYN fragments.

IP encapsulates a TCP SYN segment in the IP packet that initiates a TCP connection. The purpose is to initiate a connection and to invoke a SYN/ACK segment response. The SYN segment typically does not contain any data since the IP packet is small and there is no legitimate reason for it to be fragmented. A fragmented SYN packet is anomalous and is suspicious. To be cautious, it might be helpful to block such fragments from entering the protected network.

When the SYN fragmentation check is enabled, the security device detects and drops the packets when the IP header indicates that the packet has been fragmented while the SYN flag is set in the TCP header.

jnxJsScreenMonTcpNoFlag

jnxJsScreenMonEntry 15

Number of TCP packets with no flag set.

A normal TCP segment header has at least one flag control set. A TCP segment with no control flags set is an anomalous event. Operating systems respond to such anomalies in different ways. The response, or even lack of response, from the targeted device can provide a clue as to the target's OS type.

When this option is enabled, if the security device discovers such a header with a missing or malformed flags field, it drops the packet.

jnxJsScreenMonIpUnknownProt

jnxJsScreenMonEntry 16

Number of of unknown protocol IP packets.

According to RFC-1700, some protocol types in an IP header are reserved and unassigned at this time. Precisely because these protocols are undefined, there is no way to know in advance whether a particular unknown protocol is benign or malicious. Unless your network makes use of a nonstandard protocol with a reserved or unassigned protocol number, a cautious stance is to block such unknown elements from entering your protected network.

When the Unknown Protocol Protection SCREEN option is enabled, the security device drops packets when the protocol field contains a protocol ID number of 137 or greater.

jnxJsScreenMonIpOptBad

jnxJsScreenMonEntry 17

Number of IP bad option packets.

The IP protocol specifies a set of eight options that provide special routing controls, diagnostic tools, and security. These eight options can be used for malicious objectives.

Either intentionally or accidentally, attackers sometimes configure IP options incorrectly, producing either incomplete or malformed fields. The incorrect formatting is anomalous and potentially harmful to the intended recipient.

When the Bad IP Option Protection SCREEN option is enabled, the security device detects and blocks packets when any IP option in the IP packet header is incorrectly formatted.

jnxJsScreenMonIpOptRecRt

jnxJsScreenMonEntry 18

Number of IP record option packets.

The IP standard RFC-791 specifies a set of options to provide special routing controls, diagnostic tools, and security. These options appear after the destination address in an IP packet header. When they do appear, they are frequently being put to some nefarious use. The record option is one of these options that an attacker can use for reconnaissance or for some unknown but suspicious purpose

When a record IP option is received, the security device flags it as an network reconnaissance attack and records the event for the ingress interface.

jnxJsScreenMonIpOptTimestamp

jnxJsScreenMonEntry 19

Number of IP timestamp option packets.

The IP standard RFC-791 specifies a set of options to provide special routing controls, diagnostic tools, and security. These options appear after the destination address in an IP packet header. When they do appear, they are frequently being put to some nefarious use. Timestamp is one of these options that an attacker can use for reconnaissance or for some unknown but suspicious purpose.

When a timestamp IP option is received, the security device flags this as an network reconnaissance attack and records the event for the ingress interface.

jnxJsScreenMonIpOptSecurity

jnxJsScreenMonEntry 20

Number of IP security option packets.

The IP standard RFC-791 specifies a set of options to provide special routing controls, diagnostic tools, and security. These options appear after the destination address in an IP packet header. When they do appear, they are frequently being put to some nefarious use. Security is one of these options that an attacker can use for reconnaissance or for some unknown but suspicious purpose.

When a security IP option is received, the security device flags this as an network reconnaissance attack and records the event for the ingress interface.

jnxJsScreenMonIpOptLSR

jnxJsScreenMonEntry 21

Number of strict source route packets.

Attackers can use IP source route options to hide their true address and access restricted areas of a network by specifying a different path. The security device should be able to either block any packets with loose or strict source route options set or detect such packets and then record the event for the ingress interface.

jnxJsScreenMonIpOptStream

jnxJsScreenMonEntry 23

Number of IP stream option packets.

The IP standard RFC-791 specifies a set of options to provide special routing controls, diagnostic tools, and security. These options appear after the destination address in an IP packet header. When they do appear, they are frequently being put to some nefarious use. Stream is one of these options that an attacker can use for reconnaissance or for some unknown but suspicious purpose.

When a security IP option is received, the security device flags it as an network reconnaissance attack and records the event for the ingress interface.

jnxJsScreenMonIcmpFrag

jnxJsScreenMonEntry 24

Number of ICMP fragment packets.

ICMP provides error reporting and network probe capabilities. Because ICMP packets contain very short messages, there is no legitimate reason for ICMP packets to be fragmented. If an ICMP packet is so large that it must be fragmented, something is wrong. With the ICMP Fragment Protection SCREEN option enabled, the security device should be able to block any ICMP packet with the More Fragments flag set or with an offset value indicated in the offset field.

jnxJsScreenMonIcmpLarge

jnxJsScreenMonEntry 25

Number of large ICMP packets.

Because ICMP packets contain very short messages, there is no legitimate reason for ICMP packets to be fragmented.

If an ICMP packet is unusually large, something is wrong. For example, the Loki program uses ICMP as a channel for transmitting covert messages. The presence of large ICMP packets might expose a compromised machine acting as a Loki agent. It might also indicate some other kind of malicious activity.

When the the Large Size ICMP Packet Protection SCREEN option is enabled, the security device drops ICMP packets with a length greater than 1024 bytes.

jnxJsScreenMonTcpSynFin

jnxJsScreenMonEntry 26

Number of dropped TCP packets because SYN and FIN are both set.

Both the SYN and FIN control flags are not normally set in the same TCP segment header. The SYN flag synchronizes sequence numbers to initiate a TCP connection. The FIN flag indicates the end of data transmission to finish a TCP connection. Their purposes are mutually exclusive. A TCP header with the SYN and FIN flags set is anomalous TCP behavior, causing various responses from the recipient, depending on the OS.

When the blocking of TCP packets with both SYN and FIN is enabled, the security device drops the packet when it discovers such a header.

jnxJsScreenMonTcpFinNoAck

jnxJsScreenMonEntry 27

Number of TCP packets with FIN set, but without the ACK bit set.

A FIN scan sends TCP segments with the FIN flag set in an attempt to provoke a response and thereby discover an active host or an active port on a host. The use of TCP segments with the FIN flag set might evade detection and thereby help attackers succeed in their reconnaissance efforts.

jnxJsScreenMonLimitSessSrc

jnxJsScreenMonEntry 28

Number of the session connections for a source IP address that exceeds the specified limit.

Because all the virus-generated traffic originates from the same IP address (generally from an infected server), a source-based session limit ensures that the firewall can curb such excessive amounts of traffic. This amount is based on a threshold value of the number of concurrent sessions required to fill up the session table of the particular firewall.

The default maximum for a source-based session limit is 128 concurrent sessions, which can be adjusted accordingly.

jnxJsScreenMonLimitSessDest

jnxJsScreenMonEntry 29

Number of session connections for the destination source IP address that exceeds the specified limit.

The user can limit the number of concurrent sessions to the same destination IP address. An attacker can launch a distributed denial-of-service (DDoS) attack using “zombie agents.” Setting a destination-based session limit can ensure that the security device allows only an acceptable number of concurrent connection requests, no matter what the source, to reach any one host.

The default maximum for the destination-based session limit is 128 concurrent sessions.

jnxJsScreenMonSynAckAck

jnxJsScreenMonEntry 30

Number of SYN ACK ACK attacks.

When an authentication user initiates a Telnet or FTP connection, the user sends a SYN segment to the Telnet or FTP server. The security device intercepts the SYN segment, creates an entry in its session table, and proxies a SYN-ACK segment to the user. The user then replies with an ACK segment. At that point, the initial three-way handshake is complete. The security device sends a login prompt to the user. When a malicious user does not log in, but instead continues initiating SYN-ACK-ACK sessions, the firewall session table can fill up to the point at which the security device begins rejecting legitimate connection requests.

When the SYN-ACK-ACK proxy protection option is enabled, after the number of connections from the same IP address reaches the SYN-ACK-ACK proxy threshold, the security device rejects further connection requests from that IP address. By default, the threshold is 512 connections from any single IP address.

jnxJsScreenMonIpFrag

jnxJsScreenMonEntry 31

Number of block IP fragment packets.

As a packets travels, it is sometimes necessary to break the packet into smaller fragments based upon the maximum transmission unit (MTU) of each network. IP fragments might contain an attacker's attempt to exploit the vulnerabilities in the packet reassembly code of specific IP stack implementations. When the victim receives these packets, the results can range from processing the packets incorrectly to crashing the entire system.

When the block IP framentation flag is enabled, the security device blocks all IP packet fragments that it receives at interfaces bound to that zone.

jnxJsScreenSynAttackThresh

jnxJsScreenMonEntry 32

SYN attack threshold value.

The number of SYN segments to the same destination address and port number per second required to activate the SYN proxying mechanism. In order to set the appropriate threshold value, it requires a through knowledge of the normal traffic patterns at the site.

For example, if the security device normally gets 2000 SYN segments per second, the threshold value should be set at 3000 segments per second.

jnxJsScreenSynAttackTimeout

jnxJsScreenMonEntry 33

SYN attack timeout value.

The maximum length of time before a half-completed connection is dropped from the queue. The default is 20 seconds.

jnxJsScreenSynAttackAlmTh

jnxJsScreenMonEntry 34

SYN attack alarm threshold value.

The SYN attack alarm threshold causes an alarm to be generated when the number of proxied, half-completed TCP connection requests per second to the same destination address and port number exceeds its value.

jnxJsScreenSynAttackQueSize

jnxJsScreenMonEntry 35

SYN attack queue size.

The number of proxied connection requests held in the proxied connection queue before the security device starts rejecting new connection requests.

Note: The jnxJsScreenSynAttackAgeTime object is obsolete in this release.

jnxJsScreenSynAttackAgeTime

jnxJsScreenMonEntry 36

SYN flood age time

jnxJsScreenIcmpFloodThresh

jnxJsScreenMonEntry 37

ICMP attack alarm threshold value.

The security device can impose a limit on the number of SYN segments permitted to pass through the firewall per second. The default attack threshold value is 1000. The valid threshold range is 1 through 100000. When the threshold value is exceed, an alarm is triggered.

jnxJsScreenUdpFloodThresh

jnxJsScreenMonEntry 38

UDP attack alarm threshold value.

UDP flooding occurs when an attacker sends IP packets containing UDP datagrams with the purpose of slowing down the victim to the point that it can no longer handle valid connections.

The default threshold value is 1000 packets per second.

jnxJsScreenPortScanThresh

jnxJsScreenMonEntry 39

Port scan threshold value.

The port scan threshold interval is in microseconds. The default threshold value is 5000. The valid threshold range is 1000 through 1000000.

By using the default settings, if a remote host scans 10 ports in 0.005 seconds (5000 microseconds), the security device flags this occurrence as a port scan attack and rejects all further packets from the remote source for the remainder of the specified timeout period. The security device detects and drops the tenth packet that meets the port scan attack criterion.

jnxJsScreenIpSweepThresh

jnxJsScreenMonEntry 40

IP sweep threshold interval.

The IP sweep threshold interval is in microseconds. The default threshold value is 5000. The valid threshold range is 1000 through 1000000.

By using the default settings, if a remote host sends ICMP traffic to 10 addresses in 0.005 seconds (5000 microseconds), the security device flags this occurrence as an address sweep attack and rejects all further ICMP echo requests from that host for the remainder of the specified threshold time period. The security device detects and drops the tenth packet that meets the address sweep attack criterion.

jnxJsScreenSynAckAckThres

jnxJsScreenMonEntry 41

SYN-ACK-ACK alarm threshold value