An attack can be a single packet designed to cause a system to fail or hang. An attack can also consist of multiple packets designed to consume a limited resource, which causes a network, system, or application to be unavailable to its intended users (denial of service). You can use intrusion detection services (IDS) attack policy to activate attack detection for one or more categories of attacks independently of each other. In general, the types of actions that you can specify for an attack policy are event logging, statistics gathering, packet tracing, and discarding of the attack packets. Most attack checking is performed for inbound packets to a stack.
IDS includes the following categories of attacks:
Many attacks are designed to cause the protocol stack of a system to fail by providing incorrect or partial header information. These packets are always discarded when they are received, regardless of IDS policy. The source IP address is rarely reliable for these attacks. This type of attack applies to both IPv4 and IPv6 packets.
You can use IDS policy to provide notification of malformed packet attacks.
Many attacks are the result of fragment overlays in the IP or transport header. You can use this support to detect fragmentation overlays that change the data in a packet, including changes to the length of the packet. This type of attack applies to both IPv4 and IPv6 packets.
You can use IDS policy to provide notification of suspicious fragments, and optionally to discard them.
Although there are 256 possible values that can be specified in the protocol field of the IP header, only a handful are commonly used. You can protect your system against future attacks by prohibiting those values that you are not actively and intentionally using.
You can use IDS policy to provide notification of a packet with a restricted IP protocol value, as well as to discard the packet.
The IPv6 header and any subsequent extension headers include a next header field. The value in the next header field identifies the next header in the packet, either an upper layer protocol header (such as a TCP or UDP header) or an extension header (such as a fragmentation or routing header). Although there are 256 possible values that can be specified as a next header value, only a small number are commonly used. You can protect your system by prohibiting next header values in inbound packets that you are not actively and intentionally using.
You can use IDS policy to provide notification of an inbound packet with a restricted next header value, as well as to discard the packet.
As with IP protocols, there are 256 possible values that can be specified as IP options in received packets, with only a small number currently in common use. You can prevent misuse of values that you are not intentionally using. A check for restricted IP options is performed on all inbound packets, including those that are forwarded to another system.
You can use IDS policy to provide notification of a packet with a restricted IP option, as well as to discard the packet.
Although there are 256 possible values that can be specified as IPv6 destination options in received packets, only a small number of values are currently defined. You can prevent misuse of values that you are not intentionally using.
You can use IDS policy to provide notification of a packet with a restricted value for an IPv6 destination option, as well as to discard the packet.
Although there are 256 possible values that can be specified as IPv6 hop-by-hop options in received packets, only a small number of values are currently defined. You can prevent misuse of values that you are not intentionally using. A check for restricted IPv6 hop-by-hop options is performed on all inbound packets, including those that are forwarded to another system.
You can use IDS policy to provide notification of a packet with a restricted value for an IPv6 hop-by-hop option, as well as to discard the packet.
Some UDP applications unconditionally respond to every datagram that is received. In some cases, such as Echo, CharGen or TimeOfDay, this is a useful network management or network diagnostic tool. In other cases, an application might send error messages in response to incorrectly formed requests. If a datagram is inserted into the network with one of these applications as the destination and another one of these applications spoofed as the source, the two applications will respond to each other continually. Each inserted datagram results in another perpetual echo conversation between them. You can use IDS policy to define the application ports that exhibit this behavior. This type of attack applies to both IPv4 and IPv6 packets.
You can use IDS policy to provide notification of a perpetual echo packet, as well as to discard the packet.
ICMP redirect packets and ICMPv6 redirect packets can be used to modify your routing tables. You can use IDS policy to provide notification of attempts to modify your routing tables in this manner. You can also use IDS policy to ignore ICMP redirect packets and ICMPv6 redirect packets.
Most network attacks require the ability to create packets that would not typically be built by an appropriate protocol stack implementation. You can use IDS policy to detect and prevent many of these attempts so that your system is not used as the source of attacks on other systems. As a part of this checking, you can restrict the IP protocols that are allowed in an outbound raw packet.
You can use IDS policy to provide notification of an outbound raw packet that is considered an attack, as well as to discard the packet.
Most network attacks require the ability to create packets that would not normally be built by an appropriate protocol stack implementation. You can use IDS policy to detect and prevent many of these attempts so that your system is not used as the source of attacks on other systems. As a part of this checking, you can restrict the protocols that are allowed in an outbound raw packet for IPv6 traffic.
You can use IDS policy to provide notification of an outbound IPv6 raw packet that is considered an attack, as well as to discard the packet.
Two types of floods are currently detected:
A popular denial of service attack is to flood a public server with connection requests from incorrect or nonexistent source IP addresses. The intent is to use up the available slots for connection requests and thereby deny legitimate access from completing. z/OS® CS provides protection from this attack regardless of IDS policy.
If a large number of discards are occurring in proportion to the number of inbound packets, a malicious user might be attempting a denial of service attack. If this percentage of discards for an interface exceeds a specified percentage, this is considered an interface flood. The default percentage of discards used is 10%. You can override this default by specifying the interface flood percentage parameter.
To prevent the false detection of an interface flood condition when there is a low volume of inbound traffic on an interface, a minimum number of discards must occur in a one minute period to qualify as a flood. The default minimum is 1000 discards per minute. You can override this default by specifying the interface flood minimum discard parameter.
When an interface flood condition is reported for an interface, the discard rate for the interface is evaluated for each subsequent 1-minute interval. An interface flood condition end is reported when the number of discards for the 1-minute interval falls below the interface flood minimum discard parameter value or the discard percentage falls below 50% of the interface flood percentage parameter value.
If the interface flood continues for more than 5 minutes and logging was requested by policy, an interface flood continues record is logged at 5 minute intervals while the interface flood conditions exist. This log data contains additional information about the discarded packets for the interface.
Because it can be difficult to distinguish between a malicious user trying to flood a system, unusual spikes in traffic, and problems that can be caused by setup problems, it is possible for an interface flood condition to be reported when the source of the problem is not actually a flood. For example, if enough storage is not configured to handle the inbound traffic, a large percentage of the inbound packets might be discarded and cause the interface flood percentage to be exceeded.
This type of attack applies to both IPv4 and IPv6.
You can use IDS policy to provide notification of an attack so that you can address the situation with your network administrators and service providers in a timely manner. Notification of a flood can include flood start and flood end event messages and tracing of the first 100 packets discarded due to the flood.
Malformed packets for EE can be designed to disrupt the TCP/IP and SNA protocol stacks. These packets might have incorrect information in the IP and UDP headers, and the received packet might be too short or too long depending on the Logical Data Link Control (LDLC) command present. Any packet received that is not a valid EE command is flagged as malformed.
You can use the IDS policy option to discard malformed packets or to forward them to VTAM® for further processing. You can use IDS policy to provide notification of the EE malformed packets. You can code an exclusion list in the policy to exclude packets from certain IP addresses from the malformed packet checks.
This type of attack applies to both IPv4 and IPv6 packets.
EE architecture defines five ports that map to SNA data priorities. The lowest port, usually 12000, is used for signaling data. If signaling data is received on any of the other ports, it is suspicious. If the EE LDLC check attack type is enabled, receiving signaling data on any of the other ports is detected as an attack. This type of attack can be a denial of service (DoS) attack designed to keep resources busy, so that SNA LUs are not able to start sessions with applications on this host.
IDS policy gives you the option of discarding these packets or forwarding them to VTAM for further processing. You can configure the policy to provide notification of the LDLC events. You can code an exclusion list in the policy to exclude packets from certain IP addresses from the LDLC checks.
This type of attack applies to both IPv4 and IPv6 packets.
You can use IDS policy to check the source and destination ports in the UDP header of received EE packets. The port values are expected to be the same; for example, both source and destination port are 12000 in a received packet. If the port values are not the same, this packet is considered an attack packet.
IDS policy gives you the option of discarding these packets or forwarding them to VTAM for further processing. You can configure the policy to provide notification of the port detection events. You can code an exclusion list in the policy to exclude packets from certain IP addresses from the port checks. For example, some products send the null XID using an ephemeral source port value, but expect the reply to be sent to the EE signaling port.
This type of attack applies to both IPv4 and IPv6 packets.
A flood of XIDs can consume all available EE lines, causing additional EE connection requests to fail. You can enable the EE XID flood attack type to receive notification when an XID flood is occurring for a specific VIPA.
An XID flood is detected when a large number of XID exchanges time out. No discard action exists for this attack type. You can code an exclusion list in the policy to exclude XID exchanges that time out from being counted toward the XID flood if the peer's IP address is in the exclusion list.
This type of attack applies to both IPv4 and IPv6 packets.
This type of attack applies to both IPv4 and IPv6 packets.
You can use IDS policy to provide notification of a suspicious packet that might contain hidden data, as well as to discard the packet.
You can use IDS policy to detect when the send, receive, or out-of-order queue for a TCP connection becomes constrained. A queue can be constrained due to the amount of data on the queue or due to the age of the data on the queue. When a designated amount of data that is configured in policy remains on the queue for at least 30 seconds, the queue becomes constrained. When any data remains on the queue for at least 60 seconds, the queue becomes constrained. Optionally, you can reset the TCP connection when a constraint is detected. If you do not reset the TCP connection, IDS continues to monitor the queue and detect when it becomes unconstrained. This type of attack applies to both IPv4 and IPv6 connections.
A TCP connection might have data queued on the send queue for a long period of time for a legitimate reason. For example, a TCP connection that is associated with a printer that has run out of paper can remain in a persist state while waiting for paper to be loaded. To exclude a device, such as a printer, from TCP send queue size checking, you can configure an exclusion specifying the IP address, and optionally the port, of the device.
You can use IDS policy to provide notification of a constrained send, receive, or out-of-order queue, as well as to reset the connection.
There are attacks designed to consume system resources by creating many TCP connections and causing them to stall, making them unable to send data. This support detects a global TCP stall condition for a TCP/IP stack when at least 50% of the active TCP connections are stalled and at least 1000 TCP connections are active. Optionally, you can reset the stalled connections. This type of attack applies to both IPv4 and IPv6 connections.
For each attack category (for example, restricted IP protocol) the single highest priority rule is mapped at policy change.
One or more notification options can be specified in the action to provide the wanted documentation of detected attacks.
For IDS attack policy, the notification options enable attack events to be logged to syslogd and to the system console. The console messages provide a subset of the information provided in the syslogd messages.
For all attack categories except flood, EE XID flood, TCP queue size, and global TCP stall, a single packet triggers an event. To prevent message flooding to the system console, you should use the maximum event message parameter to specify the maximum number of console messages to be logged per attack category within a 5-minute interval. To prevent message flooding to syslogd, a maximum of 100 event messages per attack category are logged to syslogd within a 5-minute interval. Specify the syslogd detail parameter with the global TCP stall attack type to request that a syslogd message be generated for each stalled connection when a global TCP stall is detected.
For IDS attack policy, the statistics action provides a count of the number of attack events detected during the statistics interval. The count of attacks is kept separately for each category of attack (for example, malformed packet events) and a separate statistical record is generated for each. If you want to receive statistics for attacks, you should specify exception statistics. With exception statistics, a statistical record is generated for the category of attack only if the count of attacks is nonzero. If you request normal statistics, a record is generated for every statistics interval regardless of whether an attack has been detected during that interval.
If you want to provide overrides to the interface flood parameters (interface flood minimum percentage parameter and interface flood minimum discard parameter), you should not use exception statistics. In this case, use normal statistics for a period for the flood attack category to collect data to help determine the appropriate policy parameter values. After you determine the appropriate values, specify exception statistics.
For IDS attack policy, the trace data and trace record size parameters indicate whether packets associated with attack events are to be traced. For all attack categories except flood, EE XID flood, TCP queue size, and global TCP stall, a single packet triggers an event and the packet is traced. To prevent trace flooding, a maximum of 100 attack packets per attack category are traced within a 5-minute interval.
For all attack categories except EE XID flood, TCP queue size, and global TCP stall, you can specify that packets associated with attack events should be discarded. However, malformed and flood packets are always discarded regardless of this setting.
For the TCP queue size attack category, you can specify that connections associated with attack events should be reset.
For the global TCP stall attack category, you can specify that stalled connections should be reset when a global TCP stall condition is detected.
The EE XID flood attack category monitors the number of XID exchange timeouts. There is no associated packet to discard or connection to reset.
An action can be unique to a specific category of attack (for example, malformed) or shared by one or more categories of attacks. If an action is shared, statistical data is still kept separately for each type of attack. Also, the maximum console message limit is enforced individually for each category of attack.