Connection-rate filtering is a countermeasure tool you can use in your incident-management program to help detect and manage worm-type IT security threats received in inbound IP traffic. Major benefits of this tool include:
-
Behavior-based operation that does not require identifying details unique to the code exhibiting the worm-like operation.
-
Handles unknown worms.
-
Protects network infrastructure by slowing or stopping IP traffic from hosts exhibiting high connection-rate behavior.
-
Allows network and individual switches to continue to operate, even when under attack.
-
Provides Event Log and SNMP trap warnings when worm-like behavior is detected
-
Gives IT staff more time to react before the threat escalates to a crisis.
|
|
|
![[NOTE: ]](images/note.gif) |
NOTE: When configured on a port, connection-rate filtering is triggered by IPv4 traffic received inbound with a relatively high rate of IP connection attempts. |
|
|
|
|
|
|
|
NOTE: As stated previously, connection-rate filtering is triggered by inbound IP traffic exhibiting a relatively high-incidence of IP connection attempts from a single source. |
|
|
Connection-rate filtering enables notification of worm-like behavior detected in inbound IP traffic and, depending on how you configure the feature, also throttles or blocks such traffic. This feature also provides a method for allowing legitimate, high connection-rate traffic from a given host while still protecting your network from possibly malicious traffic from other hosts.
In the default configuration, connection-rate filtering is disabled. When enabled on a port, connection-rate filtering monitors inbound IP traffic for a high rate of connection requests from any given host on the port. If a host appears to exhibit the worm-like behavior of attempting to establish a large number of outbound IP connections in a short period of time, the switch responds in one of the following ways, depending on how connection-rate filtering is configured:
-
Notify only (of potential attack): While the apparent attack continues, the switch generates an Event Log notice identifying the offending host's source IP address and (if a trap receiver is configured on the switch) a similar SNMP trap notice).
-
Throttle: In this case, the switch temporarily blocks inbound IP traffic from the offending host source IP address for a "penalty" period and generates an Event Log notice of this action and (if a trap receiver is configured on the switch) a similar SNMP trap notice. When the "penalty" period expires the switch re-evaluates the traffic from the host and continues to block this traffic if the apparent attack continues. (During the re-evaluation period, IP traffic from the host is allowed.)
-
Block: This option blocks all IP traffic from the host. When a block occurs, the switch generates an Event Log notice and (if a trap receiver is configured on the switch) a similar SNMP trap notice. Note that a network administrator must explicitly re-enable a host that has been previously blocked.
The switch includes a global sensitivity setting that enables adjusting the ability of connection-rate filtering to detect relatively high instances of connection-rate attempts from a given source.
For the most part, normal network traffic is distinct from the traffic exhibited by malicious agents. However, when a legitimate network host generates multiple connections in a short period of time, connection-rate filtering can generate a "false positive" and treat the host as an infected client. Lowering the sensitivity or changing the filter mode can reduce the number of false positives. Conversely, relaxing filtering and sensitivity provisions lowers the switch ability to detect worm-generated traffic in the early stages of an attack, and should be carefully investigated and planned to ensure that a risky vulnerability is not created. As an alternative, you can use connection-rate ACLs (access control lists) or selective enabling to allow legitimate traffic.
This option involves applying connection-rate filtering only to ports posing a significant risk of attack. For ports that are reasonably secure from attack, then there can be little benefit in configuring them with connection-rate filtering.
The basic connection-rate filtering policy is configured per-port as notify-only, throttle, and block. A connection-rate ACL creates exceptions to these per-port policies by creating special rules for individual hosts, groups of hosts, or entire subnets. Thus, you can adjust a connection-rate filtering policy to create and apply an exception to configured filters on the ports in a VLAN. Note that connection-rate ACLs are useful only if you need to exclude inbound traffic from your connection-rate filtering policy. For example, a server responding to network demand can send a relatively high number of legitimate connection requests. This can generate a false positive by exhibiting the same elevated connection-rate behavior as a worm. Using a connection-rate ACL to apply an exception for this server allows you to exclude the trusted server from connection-rate filtering and thereby keep the server running without interruption.
|
|
|
|
|
NOTE: Use connection-rate ACLs only when you need to exclude an IP traffic source (including traffic with specific UDP or TCP criteria) from a connection-rate filtering policy. Otherwise, the ACL is not necessary. |
|
|
-
Connection-rate filtering is triggered by inbound IP traffic exhibiting high rates of IP connections to new hosts. After connection-rate filtering has been triggered on a port, all traffic from the suspect host is subject to the configured connection-rate policy (
notify-only,throttle, orblock). -
When connection-rate filtering is configured on a port, the port cannot be added to, or removed from, a port trunk group. Before this can be done, connection-rate filtering must be disabled on the port.
-
Where the switch is throttling or blocking inbound IP traffic from a host, any outbound traffic destined for that host is still permitted.
-
Once a throttle has been triggered on a port—temporarily blocking inbound IP traffic—it cannot be undone during operation: the penalty period must expire before traffic is allowed from the host.
A hostblocked by connection-rate filtering remains blocked until explicitly unblocked by one of the following methods:
-
Using the
connection-rate-filter unblockcommand, see Listing currently-blocked hosts. -
Disabling connection-rate filtering using the
no connection-rate-filtercommand.
A host sending legitimate traffic can trigger connection-rate filtering in some circumstances. If you can verify that such a host is indeed sending valid traffic and is not a threat to your network, you can want to configure a connection-rate ACL (access control list) that allows this traffic to bypass the configured connection-rate filtering.
A connection-rate ACL is an optional tool that consists of one or more explicitly configured Access Control Entries (ACEs) used to specify whether to enforce the configured connection-rate policy on traffic from a particular source.
Use of connection-rate ACLs provides the option to apply exceptions to the configured connection-rate filtering policy. This enables you to allow legitimate traffic from a trusted source, and apply connection-rate filtering only to inbound traffic from untrusted sources. For example, where a connection-rate policy has been configured, you can apply a connection-rate ACL that causes the switch bypass connection-rate policy filtering on traffic from:
-
A trusted server exhibiting a relatively high IP connection rate due to heavy demand
-
A trusted traffic source on the same port as other, untrusted traffic sources.
The criteria for an exception can include the source IP address of traffic from a specific host, group of hosts, or a subnet, and can also include source and destination TCP/UDP criteria. This allows you to apply a notify-only, throttling, or blocking policy while allowing exceptions for legitimate traffic from specific sources. You can also allow exceptions for traffic with specific TCP or UDP criteria.
For more information on when to apply connection-rate ACLs, see Application options.
|
|
|
|
|
NOTE: Connection-rate ACLs are a special case of the switch ACL feature. If you need information on other applications of ACLs or more detailed information on how ACLs operate, see IPv4 Access Control Lists (ACLs). |
|
|
A connection-rate ACL applies to inbound traffic on all ports configured for connection-rate filtering in the assigned VLAN, and creates an exception to the connection-rate filter policy configured on each port. A connection-rate ACL has no effect on ports in the VLAN that are not configured for connection-rate filtering.
A connection-rate ACL accepts inbound, legitimate traffic from trusted sources without filtering the traffic for the configured connection-rate policy. You can configure an ACL to assign policy filtering (filter) for traffic from some sources and no policy filtering (ignore) for traffic from other sources. However, the implicit filter invoked as the last entry in any connection-rate ACL ensures that any traffic not specifically excluded from policy filtering (by the ignore command) is filtered by the configured policy for the port on which that traffic entered the switch.
-
A connection-rate ACL allows you to configure two types of ACEs (Access Control Entries):
-
This ACE type directs the switch to permit all inbound traffic meeting the configured
<source-criteria>without filtering the traffic through the connection-rate policy configured on the port through which the traffic entered the switch. For example,ignore host 15.45.120.70tells the switch to permit traffic from the host at 15.45.120.70 without filtering this host's traffic through the connection-rate policy configured for the port on which the traffic entered the switch. -
This ACE type does the opposite of an
ignoreentry. That is, all inbound traffic meeting the configuredsource-criteriamust be filtered through the connection-rate policy configured for the port on which the traffic entered the switch. This option is most useful in applications where it is easier to usefilterto specify suspicious traffic sources for screening than to useignoreto specify exceptions for trusted traffic sources that don't need screening. For example, if the host at 15.45.127.43 requires connection-rate screening, but all other hosts in the VLAN do not, you would configure and apply a connection-rate ACL withfilter ip host 15.45.127.43as the first ACE andignore ip anyas the second ACE. In this case, the traffic from host 15.45.127.43 would be screened, but traffic from all other hosts on the VLAN would be permitted without connection-rate screening.
-
-
A connection-rate ACL includes a third, implicit
filter ip anyACE which is automatically the last ACE in the ACL. This implicit ACE does not appear in displays of the ACL configuration, but is always present in any connection-rate ACL you configure. For example, assume that a port is configured with a connection-rate policy and is in a VLAN configured with a connection-rate ACL. If there is no match between an incoming packet and the ACE criteria in the ACL, then the implicitfilter ip anysends the packet for screening by the connection-rate policy configured on that port. To preempt the implicitfilter ip anyin a given connection-rate ACL, you can configureignore IP anyas the last explicit ACE in the connection-rate ACL. The switch then ignores (permit) traffic that is not explicitly addressed by other ACEs configured sequentially earlier in the ACL without filtering the traffic through the existing connection-rate policy. -
Active instances of throttling or blocking a client that is generating a high rate of connection requests uses internal routing switch resources that are shared with several other features. The routing switch provides ample resources for all features. However, if the internal resources become fully subscribed, new instances of throttling or blocking cannot be initiated until the necessary resources are released from other uses. (Event Log messages and SNMP traps are not affected.) For information on determining current resource availability and usage, see the appendix titled "Monitoring Resources" in the Management and Configuration Guide for your switch.
You can use Classless Inter-Domain Routing (CIDR) notation to enter ACE masks. The switch interprets the bits specified with CIDR notation as the IP address bits in an ACE and the corresponding IP address bits in a packet. The switch then converts the mask to inverse notation for ACE use.
CIDR notation for masks
| IP address used in an ACL with CIDR notation | Resulting ACL mask | Meaning |
|---|---|---|
| 10.38.240.125/15 | 0.1.255.255 | The leftmost 15 bits must match; the remaining bits are wildcards. |
| 10.38.240.125/20 | 0.0.15.255 | The leftmost 20 bits must match; the remaining bits are wildcards. |
| 10.38.240.125/21 | 0.0.7.255 | The leftmost 21 bits must match; the remaining bits are wildcards. |
| 10.38.240.125/24 | 0.0.0.255 | The leftmost 24 bits must match; the remaining bits are wildcards. |
| 10.38.240.125/32 | 0.0.0.0 | All bits must match. |