All MIBs › JUNIPER-JS-SCREENING-MIB
Organization: Juniper Networks, Inc.
Last Updated: 2014-04-02
Category: Domain: Security, VPN and Security, Vendor: Juniper
Description: Defines managed objects for screen (DoS/DDoS attack screening) statistics on Juniper Networks SRX and J-series security devices.
Start monitoring vendor-neutral, standards-based MIB, any SNMPv3-capable network device (SNMP engine identity/boot/clock status) with a free 30-day trial of IPNetwork Monitor. Import MIBs, browse SNMP OIDs, create custom SNMP monitors, configure alerts, and monitor any SNMP-enabled network device from a single console.
What Is JUNIPER-JS-SCREENING-MIB?
JUNIPER-JS-SCREENING-MIB is a Juniper Networks enterprise MIB covering the "screen" security feature of Juniper Enterprise Firewall functionality on SRX and J-series security devices. It defines objects related to detection of denial-of-service (DoS) and distributed denial-of-service (DDoS) activity, including generic network-level attacks, operating-system-specific attacks, and packet-fragmentation-based attacks. Rather than classic environmental sensors, it is used to monitor the software-level security status of the firewall — the state and activity of its threat-screening defenses — giving operators visibility into ongoing or blocked attack attempts against the device. It builds on Juniper's broader enterprise MIB and firewall/zone configuration model, per the module's own recommendation to consult Juniper documentation for full context. It is typically deployed on Juniper SRX/J-series firewalls positioned at network or datacenter perimeters where active DoS/DDoS defense is required, monitored via the JUNIPER-JS-SCREENING-MIB MIB's screen counters.
IPNetwork Monitor allows you to monitor SNMP objects defined in JUNIPER-JS-SCREENING-MIB. Use the built-in SNMP Monitoring Browser to explore available variables, view their current values and descriptions, and select the objects you want to monitor. You can then create SNMP monitors, configure thresholds, and receive alerts when monitored values change.
Supported Devices
- Juniper SRX and J-series security appliances/firewalls
Monitoring Examples
No sample object names were provided for this MIB, so specific table/object identifiers cannot be confirmed; per the module description, the MIB is expected to expose counters and configuration state for firewall DoS attack screening, network-level DoS screening, OS-specific attack screening, and fragmentation-attack screening. In practice an operator would poll such attack-detection counters to see spikes that correlate with an active DoS/DDoS attempt against the firewall, but the exact object names cannot be verified from the given data.
What Can Be Monitored
- DoS/DDoS attack detection activity
- OS-specific attack detection
- packet fragmentation attack detection
- screen (firewall defense) configuration state
This MIB depends on
Related MIBs
Imported Objects
From IF-MIB
| ifName | OBJECT-TYPE |
From JUNIPER-JS-SMI
| jnxJsScreening | OBJECT-IDENTITY |
From SNMPv2-SMI
| Counter64 | |
| Integer32 | |
| MODULE-IDENTITY | |
| NOTIFICATION-TYPE | |
| OBJECT-TYPE |
From SNMPv2-TC
| DisplayString |
How to Use in IPNetwork Monitor
Example using jnxJsScreenMonIpOptTimestamp OID:
Select a Juniper SRX/J-series security appliance (DoS/DDoS screen defenses) as the target host to create a monitor — the SNMP service should be up and running on it. Click New Monitor, then check SNMP Custom on the Favorites tab, click Next, and confirm the host. On the next page, click Select... to open the built-in SNMP MIB Browser and type jnxJsScreenMonIpOptTimestamp into the Find box to locate it in the OID tree, then select it and click OK. The IP standard RFC 791 specifies a set of options to provide special routing controls, diagnostic tools, and security. On the monitor's Main parameters page you can set the target's SNMP port (default 161), credentials, polling interval, and other settings — see the SNMP Monitor help for details. On the State conditions and Alerting tabs, configure when the monitor should change state and trigger an alert; since this is a Counter64-type OID, Value bounds is the most useful condition here — trigger an alert if the counter increases between polls, since a rising count of errors, failures, or discards often points to a real underlying problem. Click Finish to create the monitor; you can adjust any parameter later.
OIDs
| OID symbolic | OID numeric | Type | Access | Description |
|---|---|---|---|---|
| NTF jnxJsScreenAttack | 1.3.6.1.4.1.2636.3.39.1.8.1.0.1 | A per min bytes exceed trap signifies that the number of bytes per minutes has exceeds the specified threshold. jnxJsScreenZoneName: the zone name under which the attack is occuring. ifName the interface at which the attack is occuring. jnxJsScreenAttackType: type of attack. jnxJsScreenAttackCounter: the number of attacks recorded based on the particular screening options enabled. The value of this counter is the aggregated statistic of all the interfaces bound to the mentioned zone. jnxJsScreenAttackDescr: a general text description of the this attack or the trap. | ||
| I32 jnxJsScreenAttackCounter | 1.3.6.1.4.1.2636.3.39.1.8.1.2.2 | Integer32 | accessible-for-notify | The threshold value that triggers the trap to be generated. |
| STR jnxJsScreenAttackDescr | 1.3.6.1.4.1.2636.3.39.1.8.1.2.3 | DisplayString | accessible-for-notify | The description pertinent to the attack trap. |
| INT jnxJsScreenAttackType | 1.3.6.1.4.1.2636.3.39.1.8.1.2.1 | INTEGER | accessible-for-notify | The type of attacks that the device support. |
| NTF jnxJsScreenCfgChange | 1.3.6.1.4.1.2636.3.39.1.8.1.0.2 | The screening configuration change trap signifies that an screening option has been changed(enabled or disabled). A disable feature may implies a security hole. jnxJsScreenZoneName is the zone at which the changed option is applicable to. jnxJsScreenAttackType the screen feature. jnxJsScreenCfgStatus: either enabled or disabled | ||
| INT jnxJsScreenCfgStatus | 1.3.6.1.4.1.2636.3.39.1.8.1.2.4 | INTEGER | accessible-for-notify | The screening option configuration status: enabled or disabled. |
| I32 jnxJsScreenIcmpFloodThresh | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.37 | Integer32 | read-only | ICMP flooding occurs when an attacker sends IP packets containing ICMP datagrams with the purpose of slowing down the victim to the point that it can no longer handle valid connections. This attributes display the ICMP attack alarm threshold value. |
| I32 jnxJsScreenIpSweepThresh | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.40 | Integer32 | read-only | The IP sweep threshold interval is in microseconds. The default threshold value is 5000. The valid threshold range is 1000-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 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 device detects and drops the tenth packet that meets the address sweep attack criterion. This attribute holds the UDP attack alarm threshold. |
| I32 jnxJsScreenIpv6ExtNumLim | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.48 | Integer32 | read-only | IPv6 extension header number limit value. |
| jnxJsScreenMIB | 1.3.6.1.4.1.2636.3.39.1.8.1 | This module defines the MIB for Juniper Enterprise Firewall screen functionality. Juniper documentation is recommended as the reference. Juniper Security Firewall provides various detection methods and defense mechanisms to combat exploits at all stages of the path of execution. These includes: Setting screen options Firwall DOS attacks Network DOS attack OS specific DOS attack Fragment reassembly | ||
| C64 jnxJsScreenMonAddrSpoof | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.7 | Counter64 | read-only | 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 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 only arrive via eth1, not eth3. The device concludes that the packet has a spoofed source IP address and discards it. This attribute records the address spoofing attack packets. |
| jnxJsScreenMonEntry | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1 | not-accessible | 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 zones. Hence, the statistics are aggregated across the interfaces on a per zone basis. | |
| C64 jnxJsScreenMonIcmpFlood | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.9 | Counter64 | read-only | An ICMP flood typically occurs when ICMP echo requests overload its victim with so many requests that it expends all its resources responding until it can no longer process valid network traffic. With the ICMP flood protection feature enabled, and a threshold set. If the threshold exceeded, the system 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. This attribute records the ICMP flood attack packets. |
| C64 jnxJsScreenMonIcmpFrag | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.24 | Counter64 | read-only | ICMP provides error reporting and network probe capabilities. 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 has gone amiss. With the ICMP Fragment Protection SCREEN option enabled, the 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. This attribute counts the ICMP fragment packets. |
| C64 jnxJsScreenMonIcmpLarge | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.25 | Counter64 | read-only | 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 shifty activity. When the the Large Size ICMP Packet Protection SCREEN option is enabled, the device drops ICMP packets with a length greater than 1024 bytes. This attribute records the detection of large ICMP packets. |
| C64 jnxJsScreenMonIcmpMalIcmpv6 | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.47 | Counter64 | read-only | One ICMPv6 packets may contain malformed content, the device tries to block these packets to protect downstream devices. When the malformed ICMPv6 screen is enabled, the device screens ICMPv6 packets with malformed content. The attribute counts the number of block malformed ICMPv6 packets. |
| C64 jnxJsScreenMonIpFrag | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.31 | Counter64 | read-only | As packets travels, it is sometimes necessary to break a 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 device blocks all IP packet fragments that it receives at interfaces bound to that zone. This attribute counts the number of block IP fragment packets. |
| C64 jnxJsScreenMonIpMalIpv6 | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.46 | Counter64 | read-only | One IPv6 packets may contain malformed header, the device tries to block these packets to protect downstream devices. When the malformed IPv6 screen is enabled, the device screens IPv6 packets with malformed header. The attribute counts the number of block malformed header IPv6 packets. |
| C64 jnxJsScreenMonIpOptBad | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.17 | Counter64 | read-only | 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 misconfigure IP options, producing either incomplete or malformed fields. The misformatting 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. This attributes records the detection of the IP bad option packets. |
| C64 jnxJsScreenMonIpOptLSR | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.21 | Counter64 | read-only | 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. This attribute records the detection of loose source route packets. |
| C64 jnxJsScreenMonIpOptRecRt | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.18 | Counter64 | read-only | 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. Record option is one of these options that an attacker can use for reconnaissance or for some unknown but suspicious purpose When record IP option is received, the security device flags this as an network reconnaissance attack and records the event for the ingress interface. This attribute records the detection of IP record option packets. |
| C64 jnxJsScreenMonIpOptSecurity | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.20 | Counter64 | read-only | 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 the security IP option is received, the security device flags this as an network reconnaissance attack and records the event for the ingress interface. This attribute records the detection of IP security option packets. |
| C64 jnxJsScreenMonIpOptSSR | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.22 | Counter64 | read-only | 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. This attribute records the detection of strict source route packets. |
| C64 jnxJsScreenMonIpOptStream | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.23 | Counter64 | read-only | 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 the security IP option is received, the security device flags this as an network reconnaissance attack and records the event for the ingress interface. This attribute records the detect of IP stream option packets. |
| C64 jnxJsScreenMonIpOptTimestampEx | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.19 | Counter64 | read-only | 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 timestamp IP option is received, the security device flags this as an network reconnaissance attack and records the event for the ingress interface. This attribute records the detection of IP timestamp option packets. |
| C64 jnxJsScreenMonIpSweep | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.13 | Counter64 | read-only | 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 device internally log the number of ICMP packets to different addresses from one remote source. This attributes records the address sweep attemp attack packets. |
| C64 jnxJsScreenMonIpTunnelBadInnerHeader | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.56 | Counter64 | read-only | When an IP Tunnel Bad Inner Header packet meets the attack criteria specified by current configuration, it will be counted in this statisitic. This attribute records the IP Tunnel Bad Inner Header attempt attack packets. |
| C64 jnxJsScreenMonIpTunnelGre4in4 | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.54 | Counter64 | read-only | When an IP GRE 4in4 Tunnel packet meets the attack criteria specified by current configuration, it will be counted in this statisitic. This attribute records the IP GRE 4in4 Tunnel attempt attack packets. |
| C64 jnxJsScreenMonIpTunnelGre4in6 | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.52 | Counter64 | read-only | When an IP GRE 4in6 Tunnel packet meets the attack criteria specified by current configuration, it will be counted in this statisitic. This attribute records the IP GRE 4in6 Tunnel attempt attack packets. |
| C64 jnxJsScreenMonIpTunnelGre6in4 | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.51 | Counter64 | read-only | When an IP GRE 6in4 Tunnel packet meets the attack criteria specified by current configuration, it will be counted in this statisitic. This attribute records the IP GRE 6in4 Tunnel attempt attack packets. |
| C64 jnxJsScreenMonIpTunnelGre6in6 | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.53 | Counter64 | read-only | When an IP GRE 6in6 Tunnel packet meets the attack criteria specified by current configuration, it will be counted in this statisitic. This attribute records the IP GRE 6in6 Tunnel attempt attack packets. |
| C64 jnxJsScreenMonIpTunnelIpInUdpTeredo | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.55 | Counter64 | read-only | When an IPinUDP Teredo Tunnel packet meets the attack criteria specified by current configuration, it will be counted in this statisitic. This attribute records the IPinUDP Teredo Tunnel attempt attack packets. |
| C64 jnxJsScreenMonIpTunnelIpIp4in4 | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.61 | Counter64 | read-only | When an IP Tunnel IPinIP 4in4 packet meets the attack criteria specified by current configuration, it will be counted in this statisitic. This attribute records the IP Tunnel IPinIP 4in4 attempt attack packets. |
| C64 jnxJsScreenMonIpTunnelIpIp4in6 | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.60 | Counter64 | read-only | When an IP Tunnel IPinIP 4in6 packet meets the attack criteria specified by current configuration, it will be counted in this statisitic. This attribute records the IP Tunnel IPinIP 4in6 attempt attack packets. |
| C64 jnxJsScreenMonIpTunnelIpIp6in4 | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.58 | Counter64 | read-only | When an IP Tunnel IPinIP 6in4 packet meets the attack criteria specified by current configuration, it will be counted in this statisitic. This attribute records the IP Tunnel IPinIP 6in4 attempt attack packets. |
| C64 jnxJsScreenMonIpTunnelIpIp6in6 | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.62 | Counter64 | read-only | When an IP Tunnel IPinIP 6in6 packet meets the attack criteria specified by current configuration, it will be counted in this statisitic. This attribute records the IP Tunnel IPinIP 6in6 attempt attack packets. |
| C64 jnxJsScreenMonIpTunnelIpIp6over4 | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.59 | Counter64 | read-only | When an IP Tunnel IPinIP 6over4 packet meets the attack criteria specified by current configuration, it will be counted in this statisitic. This attribute records the IP Tunnel IPinIP 6over4 attempt attack packets. |
| C64 jnxJsScreenMonIpTunnelIpIp6to4relay | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.57 | Counter64 | read-only | When an IP Tunnel IPinIP 6to4 relay packet meets the attack criteria specified by current configuration, it will be counted in this statisitic. This attribute records the IP Tunnel IPinIP 6to4 relay attempt attack packets. |
| C64 jnxJsScreenMonIpTunnelIpIpDsLite | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.64 | Counter64 | read-only | When an IP Tunnel IPinIP DS-Lite packet meets the attack criteria specified by current configuration, it will be counted in this statisitic. This attribute records the IP Tunnel IPinIP DS-Lite attempt attack packets. |
| C64 jnxJsScreenMonIpTunnelIpIpIsatap | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.63 | Counter64 | read-only | When an IP Tunnel IPinIP ISATAP packet meets the attack criteria specified by current configuration, it will be counted in this statisitic. This attribute records the IP Tunnel IPinIP ISATAP attempt attack packets. |
| C64 jnxJsScreenMonIpUnknownProt | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.16 | Counter64 | read-only | According to RFC 1700, some protocol types in IP header are reserved and unassigned at this time. Precisely because these protocols are undefined, there is no way to know in advance if a particular unknown protocol is benign or malicious. Unless your network makes use of a non-standard protocol with 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 by default. This attribute records the detection of Unknown protocol IP packets. |
| C64 jnxJsScreenMonIpv6DstOpt | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.44 | Counter64 | read-only | In one IPv6 destination option extension header, it carries a variable number options. User can screen any one or several options. When the destination option screen is enabled, the device screens all IPv6 packets with specific option type. The attribute counts the number of block IPv6 option type packets. |
| C64 jnxJsScreenMonIpv6ExtHdr | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.42 | Counter64 | read-only | In one IPv6 packet, one or more extension headers may appear before the encapsulated payload after the mandatory header. User can screen any one or several extension headers. When the extension header screen is enabled, the device screens all IPv6 packets with specific header. The attribute counts the number of block IPv6 extension packets. |
| C64 jnxJsScreenMonIpv6ExtLimit | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.45 | Counter64 | read-only | In one IPv6 packet, one or more extension headers may appear before the encapsulated payload. User can screen IPv6 packets if their extension header number is larger than one limit. When the extension header limit screen is enabled, the device screens IPv6 packets with more than one limit extension headers. The attribute counts the number of block IPv6 packets. |
| C64 jnxJsScreenMonIpv6HopOpt | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.43 | Counter64 | read-only | In one IPv6 hop by hop option extension header, it carries a variable number options. User can screen any one or several options. When the hop by hop option screen is enabled, the device screens all IPv6 packets with specific option type. The attribute counts the number of block IPv6 option type packets. |
| C64 jnxJsScreenMonLand | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.8 | Counter64 | read-only | A combined SYN attack with 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 system 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 system, causing a DoS. This attribute records the land attack packets. |
| C64 jnxJsScreenMonLimitSessDest | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.29 | Counter64 | read-only | The user can limit the number of concurrent sessions to the same destination IP address. A wily attacker can launch a distributed denial-of-service (DDoS) attack using 'zombie agents'. Setting a destination-based session limit can ensure that device allows only an acceptable number of concurrent connection requests, no matter what the source, to reach any one host. The default maximum for destination-based session limit is 128 concurrent sessions. This attribute records the number of session connection based on the destination source IP address that exceeds the specified limit. |
| C64 jnxJsScreenMonLimitSessSrc | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.28 | Counter64 | read-only | All the virus-generated traffic originates from the same IP address (generally from a infected server), a source-based session limit ensures that the firewall can curb such excessive amounts of traffic. Based on a threshold value, if the number of concurrent sessions required to fill up the session table of the particular firewall. The default maximum for source-based session limit is 128 concurrent sessions, which can be adjusted to accordingly. This attribute records the number of the session connection based on the source IP that exceeds the specified limit. |
| C64 jnxJsScreenMonPingDeath | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.6 | Counter64 | read-only | 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. However, many ping implementations 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 denial of service (DoS), crashing, freezing, and rebooting. When the Ping Death option is enabled, the device detects and rejects such oversized and irregular packet sizes even when the attacker hides the total packet size by purposefully fragmenting it. This attributes counts the ping of death attack packets. |
| C64 jnxJsScreenMonPortScan | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.12 | Counter64 | read-only | 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 device should internally log the number of different ports scanned from one remote source. This attribute records the port scan attempt attack packets. |
| C64 jnxJsScreenMonSrcRoute | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.5 | Counter64 | read-only | 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. This attribute records either the loose source route option or strict source route attack packets. |
| C64 jnxJsScreenMonSynAckAck | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.30 | Counter64 | read-only | When an authentication user initiates a Telnet or FTP connection, the user sends a SYN segment to the Telnet or FTP server. The 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 3-way handshake is complete. The device sends a login prompt to the user. When a malicisou user does not log in, but instead continue initiating SYN-ACK-ACK sessions, the firewall session table can fill up to the point where the 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 device rejects further connection requests from that IP address. By default, the threshold is 512 connections from any single IP address. The attribute records the detection of SYN ACK ACK attack. |
| C64 jnxJsScreenMonSynAttk | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.3 | Counter64 | read-only | The SYN (TCP connection request) 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 i SYN attack, hence wasting resources. This attribute records the number of SYN attacks. |
| C64 jnxJsScreenMonSynFloodDst | 1.3.6.1.4.1.2636.3.39.1.8.1.1.2.1.6 | Counter64 | read-only | The number of concurrent sessions to the same destination IP address. |
| C64 jnxJsScreenMonSynFloodSrc | 1.3.6.1.4.1.2636.3.39.1.8.1.1.2.1.5 | Counter64 | read-only | The number of concurrent sessions from the same source IP address. |
| C64 jnxJsScreenMonSynFrag | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.14 | Counter64 | read-only | 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 suspectful. To be cautious, it might be helpful to block such these fragments from entering the protected network. When the syn fragmentation check is enable, 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. This attributes records the detection of the SYN fragments. |
| jnxJsScreenMonTable | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1 | not-accessible | Juniper security Firewall can allow DI protection on each of the device's physical interface. This table collects the screen attributes that monitor the various attacks. The screen options can be enabled at security zone bounded to a interface or interfaces. When these options apply to traffic reaching the device through interfaces (via a zone), they offers protection against malicious information gathering probe or an attack to compromise, disable, or harm a network or network resources. | |
| C64 jnxJsScreenMonTcpFinNoAck | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.27 | Counter64 | read-only | 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 the attacker succeed in his or her reconnaissance efforts. This attributes records the detection of the TCP fin set without ack bit set packets. |
| C64 jnxJsScreenMonTcpNoFlag | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.15 | Counter64 | read-only | 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 device discovers such a header with a missing or malformed flags field, it drops the packet. The attribure records the detection of TCP without flag set packets. |
| C64 jnxJsScreenMonTcpSweep | 1.3.6.1.4.1.2636.3.39.1.8.1.1.3.1.3 | Counter64 | read-only | The number of TCP sessions dropped due to TCP sweeping attack. |
| C64 jnxJsScreenMonTcpSynFin | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.26 | Counter64 | read-only | 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 block both syn and fin option is enable, the device drops the packet when it discovers such a header This attribute records the TCP syn fin both set packet dropped. |
| C64 jnxJsScreenMonTearDrop | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.4 | Counter64 | read-only | Teardrop attacks exploit the reassembly of fragmented IP packets. In the IP header, one of the fields is the fragment offset field, which indicates one of the fields is the fragment offset field. It 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 this attribute counts the number of packets dropped. |
| jnxJsScreenMonThreshEntry | 1.3.6.1.4.1.2636.3.39.1.8.1.1.2.1 | read-only | Syn Flood and Session Limit thresholds and counts. | |
| jnxJsScreenMonThreshTable | 1.3.6.1.4.1.2636.3.39.1.8.1.1.2 | not-accessible | This table is a read-only table that augments the jnxJsScreenMonTable. The purpose of this table is to keep threshold and counter information about Syn Flood and Session Limit. | |
| C64 jnxJsScreenMonUdpFlood | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.10 | Counter64 | read-only | 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 the UDP flood protection feature enabled, a threshold can be set which once exceeded, the system invokes the UDP flood attack protection feature. 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, security device ignores further UDP datagrams to that destination for the remainder of that second plus the next second as well. This attribute records the UDP flood attack packets. |
| C64 jnxJsScreenMonUdpPortScan | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.50 | Counter64 | read-only | A UDP port scan occurs when one source IP address sends UDP packets 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 device should internally log the number of different ports scanned from one remote source. This attribute records the UDP port scan attempt attack packets. |
| C64 jnxJsScreenMonUdpSweep | 1.3.6.1.4.1.2636.3.39.1.8.1.1.3.1.4 | Counter64 | read-only | The number of UDP packets dropped due to UDP sweeping attack. |
| C64 jnxJsScreenMonWinnuke | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.11 | Counter64 | read-only | WinNuke is a DoS attack targeting any computer on the internet running Windows. The attacker sends a TCP segment, usually to NetBIOS port 139 with the urgent (URG) flag set, to a host with an established connection. This introduces a NetBIOS fragment overlap, which causes many machines running Windows to crash. This attributes counts the netbios attack. |
| jnxJsScreenNotifications | 1.3.6.1.4.1.2636.3.39.1.8.1.0 | |||
| I32 jnxJsScreenNumOfIf | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.2 | Integer32 | read-only | Number of interfaces bound to this zone. Each counter contains the aggregated data of all the interfaces |
| jnxJsScreenObjects | 1.3.6.1.4.1.2636.3.39.1.8.1.1 | |||
| I32 jnxJsScreenPortScanThresh | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.39 | Integer32 | read-only | The port scan threshold interval is in microseconds. The default threshold value is 5000. The valid threshold range is 1000-1000000. By using the default settings, if a remote host scans 10 ports in 0.005 seconds (5000 microseconds), the device flags this as a port scan attack, and rejects all further packets from the remote source for the remainder of the specified timeout period. The device detects and drops the tenth packet that meets the port scan attack criterion. This attribute displays the port scan threshold value. |
| I32 jnxJsScreenSessLimitDstThresh | 1.3.6.1.4.1.2636.3.39.1.8.1.1.2.1.4 | Integer32 | read-only | The security device can impose a limit on the number of SYN segments permitted to a single destination IP address. |
| I32 jnxJsScreenSessLimitSrcThresh | 1.3.6.1.4.1.2636.3.39.1.8.1.1.2.1.3 | Integer32 | read-only | The security device can impose a limit on the number of SYN segments permitted from a single source IP address. |
| jnxJsScreenSweepEntry | 1.3.6.1.4.1.2636.3.39.1.8.1.1.3.1 | not-accessible | TCP/UDP sweep thresholds and counters. | |
| jnxJsScreenSweepTable | 1.3.6.1.4.1.2636.3.39.1.8.1.1.3 | not-accessible | This table is a read-only table that augments the jnxJsScreenMonTable. The purpose of this table is to add counters and thresholds for TCP/UDP sweep feature. | |
| I32 jnxJsScreenSynAckAckThres | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.41 | Integer32 | read-only | SYN ack ack alarm threshold value. |
| I32 jnxJsScreenSynAttackAgeTime | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.36 | Integer32 | read-only | SYN flood age time. This object has been deprecated. |
| I32 jnxJsScreenSynAttackAlmTh | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.34 | Integer32 | read-only | The syn attack alarm threshold causes an alarm to be generated when the number of proxied, half-complete TCP connection requests per second requests to the same destination address and port number exceeds its value. This attribute display the SYN attack alarm threshold value. |
| I32 jnxJsScreenSynAttackQueSize | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.35 | Integer32 | read-only | The number of proxied connection requests held in the proxied connection queue before the device starts rejecting new connection requests. This attribute displays the SYN attack queue size. This object has been deprecated. |
| I32 jnxJsScreenSynAttackThresh | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.32 | Integer32 | read-only | 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 site For example, if the security device normally gets 2000 SYN segments per second, the threshold value should be set at 3000/second. This attribute displays the configured SYN attack threshold value. |
| I32 jnxJsScreenSynAttackTimeout | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.33 | Integer32 | read-only | The maximum length of time before a half-completed connection is dropped from the queue. The default is 20 seconds. This attributes display the SYN attack timeout value. |
| I32 jnxJsScreenSynFloodDstThresh | 1.3.6.1.4.1.2636.3.39.1.8.1.1.2.1.2 | Integer32 | read-only | The number of SYN segments received per second from a single destination IP address before the security device begins dropping connection requests to that destination. If a protected host runs multiple services, you might want to set a threshold based on destination IP address only - regardless of the destination port number. |
| I32 jnxJsScreenSynFloodSrcThresh | 1.3.6.1.4.1.2636.3.39.1.8.1.1.2.1.1 | Integer32 | read-only | The number of SYN segments received per second from a single source IP - regardless of the destination IP address and port number - before the security device begins dropping connection requests from that source. |
| I32 jnxJsScreenTcpSweepThresh | 1.3.6.1.4.1.2636.3.39.1.8.1.1.3.1.1 | Integer32 | read-only | The TCP sweep threshold interval is in microseconds. The default threshold value is 5000. The valid threshold range is 1000-1000000. By using the default settings, if a remote host initiates TCP connection to 10 addresses in 0.005 seconds(5000 microseconds), the security device flags this as an TCP sweep attack, and rejects all further new TCP connections initiated from that host for the remainder of the specified threshold time period. This attribute holds the TCP sweep attack threshold. |
| jnxJsScreenTrapVars | 1.3.6.1.4.1.2636.3.39.1.8.1.2 | |||
| I32 jnxJsScreenUdpFloodThresh | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.38 | Integer32 | read-only | 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. This attribute displays the UDP attack alarm threshold value. |
| I32 jnxJsScreenUdpPortScanThresh | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.49 | Integer32 | read-only | The UDP port scan threshold interval is in microseconds. The default threshold value is 5000. The valid threshold range is 1000-1000000. By using the default settings, if a remote host scans 10 ports in 0.005 seconds (5000 microseconds), the device flags this as a udp port scan attack, and rejects all further packets from the remote source for the remainder of the specified timeout period. The device detects and drops the tenth packet that meets the port scan attack criterion. This attribute displays the UDP port scan threshold value. |
| I32 jnxJsScreenUdpSweepThresh | 1.3.6.1.4.1.2636.3.39.1.8.1.1.3.1.2 | Integer32 | read-only | The UDP sweep threshold interval is in microseconds. The default threshold value is 5000. The valid threshold range is 1000-1000000. By using the default settings, if a remote host has UDP connection to 10 addresses in 0.005 seconds(5000 microseconds), the security device flags this as an UDP sweep attack, and rejects all further new UDP connections from that host for the remainder of the specified threshold time period. This attribute holds the UDP sweep attack threshold. |
| STR jnxJsScreenZoneName | 1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.1 | DisplayString | accessible-for-notify | The name of the security zone under which the statistics are collected. |
RFC description
Provides security screening and firewall statistics for Juniper Enterprise Firewall DOS protection.
Start monitoring Juniper SRX/J-series security appliance (DoS/DDoS screen defenses) with a free 30-day trial of IPNetwork Monitor. Import MIBs, browse SNMP OIDs, create custom SNMP monitors, configure alerts, and monitor any SNMP-enabled network device from a single console.