Understanding IPS Blocking
The Attack Response Controller (ARC) component of the IPS is responsible for managing network devices in response to suspicious events by blocking access from attacking hosts and networks. ARC blocks the IP address on the devices it is managing. It sends the same block to all the devices it is managing, including any other main blocking sensors. ARC monitors the time for the block and removes the block after the time has expired.
Note |
ARC is formerly known as Network Access Controller. Although the name has been changed, the IPS documentation and configuration interfaces contain references to Network Access Controller, nac, and network-access. |
ARC completes the action response for a new block in no more than 7 seconds. In most cases, it completes the action response in less time. To meet this performance goal, you should not configure the sensor to perform blocks at too high a rate or to manage too many blocking devices and interfaces. We recommend that the maximum number of blocks not exceed 250 and the maximum number of blocking items not exceed 10. To calculate the maximum number of blocking items, a security appliance counts as one blocking item per blocking context. A router counts as one blocking item per blocking interface/direction. A switch running Catalyst software counts as one blocking item per blocking VLAN. If the recommended limits are exceeded, ARC might not apply blocks in a timely manner or might not be able to apply blocks at all.
For security appliances configured in multiple-context mode, Cisco IPS does not include VLAN information in the block request. Therefore you must make sure the IP addresses being blocked are correct for each security appliance. For example, the sensor is monitoring packets on a security appliance customer context that is configured for VLAN A, but is blocking on a different security appliance customer context that is configured for VLAN B. Addresses that trigger blocks on VLAN A might refer to a different host on VLAN B.
Note |
Blocking is not supported on the FWSM on the admin context in multiple-context mode. |
There are three types of blocks:
-
Host block—Blocks all traffic from a given IP address.
To configure the IPS to initiate automatic host blocks when a signature is triggered, add the Request Block Host event action to a signature, or add it to events based on risk rating using the event action override policy. See Configuring Event Action Overrides and Configuring Signatures.
-
Connection block—Blocks traffic from a given source IP address to a given destination IP address and destination port. Multiple connection blocks from the same source IP address to either a different destination IP address or destination port automatically switch the block from a connection block to a host block.
To configure the IPS to initiate automatic connection blocks when a signature is triggered, add the Request Block Connection event action to a signature, or add it to events based on risk rating using the event action override policy.
-
Network block—Blocks all traffic from a given network.
You can initiate host and connection blocks manually or automatically when a signature is triggered. You can only initiate network blocks manually. You cannot initiate network blocks from within Security Manager; use the IPS Device Manager instead.
Tip |
Connection blocks and network blocks are not supported on security appliances (firewalls). Security appliances only support host blocks with additional connection information. |
Note |
Do not confuse blocking with the ability of the sensor to drop packets. The sensor can drop packets when the following actions are configured for a sensor in inline mode: deny packet inline, deny connection inline, and deny attacker inline. |
On Cisco IOS Software devices (routers and Catalyst 6500 series switches), ARC creates blocks by applying ACLs; on Catalyst 6500/7600 devices that run the Catalyst operating system, ARC creates blocks by applying VACLs. ACLs and VACLs permit or deny passage of data packets through interface directions or VLANs. Each ACL or VACL contains permit and deny conditions that apply to IP addresses. The security appliances use the shun command instead of ACLs.
Tip |
For a list of the specific devices and operating system versions that you can configure as blocking devices, see the supported device information in the chapter “Configuring Attack Response Controller for Blocking and Rate Limiting” in the Installing and Using Cisco Intrusion Prevention System Device Manager publication for your IPS software version. These publications are available on Cisco.com at http://www.cisco.com/en/US/products/hw/vpndevc/ps4077/products_installation_and_configuration_guides_list.html |
The following topics explain more about IPS blocking:
Strategies for Applying Blocks
Blocking is performed only when an event occurs and the event includes the Request Block Connection or Request Block Host event actions. These event actions are not typically needed when you operate the IPS in inline mode, where you use Deny actions to drop undesired traffic.
The following are situations in which you might want to implement blocking actions:
-
Promiscuous mode—When running in promiscuous mode, the IPS cannot implement Deny actions. Thus, if you want to prevent traffic from a host, you must implement blocking.
-
Inline mode—In inline mode, you can implement Deny actions to immediately drop undesired traffic. However, you might want to add blocking actions to protect other segments of your network.
For example, suppose that your network consists of five subnets, A, B, C, D, and E, and that each of these segments has an inline IPS device monitoring it. If the IPS for subnet A identifies an attack, the IPS can use Deny actions to protect subnet A, but also use Request Block actions to configure the firewalls that protect B, C, D, and E to shun the attacker before the attack can target those other subnets. In this example, you would want to designate a single IPS as the main blocking sensor and have the other four IPS sensors perform blocking through the main blocking sensor.
Use the following techniques to add the request block actions to an event:
-
Event Action Override policy—Configure an event action override rule to add the action to all events based on the event’s risk rating. This is a simple approach. You could add the request block action for the same risk ratings used for adding Deny actions. For more information, see Configuring Event Action Overrides.
-
Signatures policy—You can add the request block actions to individual signatures. This requires editing each signature to add the action. This can be a time-consuming approach, but it allows you to configure blocking for just the types of events that concern you most. For more information, see Configuring Signatures.
Related Topics
Understanding Rate Limiting
Attack Response Controller (ARC) is responsible for rate limiting traffic in protected networks. Rate limiting lets sensors restrict the rate of specified traffic classes on network devices. Rate limit responses are supported for the Host Flood and Net Flood engines, and the TCP half-open SYN signature. ARC can configure rate limits on network devices running Cisco IOS 12.3 or later. Main blocking sensors can also forward rate limit requests to blocking forwarding sensors.
To add a rate limit to a signature, you must add the Request Rate Limit action. You can then edit the signature parameters to set the percentage for these signatures in the Event Actions Settings folder.
Tip |
You can also manually implement rate limits, but you cannot do so using Security Manager; use the IPS Device Manager instead. |
On the blocking device, you must not apply a service policy to an interface/direction that is configured for rate limiting. If you do so, the rate limit action will fail. Before configuring rate limits, confirm that there is no service policy on the interface/direction, and remove it if one exists. ARC does not remove the existing rate limit unless it is one that ARC had previously added.
Rate limits use ACLs, but not in the same way as blocks. Rate limits use ACLs and class-map entries to identify traffic, and policy-map and service-policy entries to police the traffic.
Understanding Router and Switch Blocking Devices
You can use routers or Catalyst 6500/7600 devices running Cisco IOS Software, or Catalyst 6500/7600 devices running the Catalyst operating system, to implement IPS blocking in your network. When you use routers or switches, Attack Response Controller (ARC) configures extended ACLs (on IOS devices) or VLAN ACLs (on Catalyst OS devices) to implement the blocks. These ACLs and VACLs are created and managed in the same way.
Rate limits also use ACLs, but not in the same way as blocks. Rate limits use ACLs and class-map entries to identify traffic, and policy-map and service-policy entries to police the traffic.
Tip |
IPS considers Catalyst 6500/7600 devices that run Cisco IOS Software to be equivalent to routers. When you add these devices as blocking devices, add them as routers. |
When you configure a router interface or switch VLAN as a blocking interface, you can optionally specify the names of pre- and post-ACLs or VACLs. Although specifying ACL or VACL names is optional, if you have configured ACLs or VACLs on the interface or VLAN, you must identify them to the IPS or ARC will remove them from your device configuration.
The pre- and post-ACL/VACL have the following uses:
-
The Pre-Block ACL/VACL is mainly used for permitting what you do not want the sensor to ever block. When a packet is checked against the ACL/VACL, the first line that gets matched determines the action. If the first line matched is a permit line from the Pre-Block ACL/VACL, the packet is permitted even though there may be a deny line (from an automatic block) listed later in the ACL/VACL. The Pre-Block ACL/VACL can override the deny lines resulting from the blocks.
-
The Post-Block ACL/VACL is best used for additional blocking or permitting that you want to occur on the same interface or direction. If you have an existing ACL on the interface or direction that the sensor will manage, that existing ACL can be used as a Post-Block ACL/VACL. If you do not have a Post-Block ACL/VACL, the sensor inserts permit ip any any at the end of the new ACL/VACL.
If you are managing the IOS Software blocking device in Security Manager, you can identify the ACL name by selecting the blocking device, then selecting Tools > Preview Config. Look for the ip access-group command in the interface configuration, and check the direction. For example, the following lines show that there is an ACL named CSM_FW_ACL_GigabitEthernet0/1 in the In direction attached to the GigabitEthernet0/1 interface.
interface GigabitEthernet0/1
ip access-group CSM_FW_ACL_GigabitEthernet0/1 in
In this example, if you configure GigabitEthernet0/1 in the In direction as a blocking interface, ensure that you specify CSM_FW_ACL_GigabitEthernet0/1 as a pre- or post-ACL. In most cases, you should specify the ACL as the post-ACL, so that the relatively short IPS blocking ACL first filters out undesirable traffic before the blocking device implements your other access rules.
Because Security Manager does not manage Catalyst OS devices, you must examine a Catalyst OS device configuration outside of Security Manager to determine VACL names. Keep in mind that a Catalyst 6500/7600 device that runs IOS Software can also have VACLs, but the IPS does not do VLAN blocking on Catalyst 6500/7600 VLANs when the device is running IOS Software.
When the sensor starts up, it reads the contents of the two ACL/VACLs. It creates a third ACL/VACL with the following entries in this order, and this combined ACL/VACL is applied to the interface or VLAN:
-
A permit line with the sensor IP address or, if specified, the NAT address of the sensor.
If you select the Allow Sensor IP address to be Blocked option on the General tab of the Blocking policy, this permit entry is not added. For more information, see General Tab, IPS Blocking Policy.
-
Pre-Block ACL/VACL, if specified.
-
Any active blocks generated by the IPS (deny statements).
-
The Post-Block ACL/VACL, if specified.
If you do not specify a Post-Block ACL/VACL, a permit ip any any entry is added to allow all unfiltered traffic. Note that this negates the normal implicit deny any that ends interface ACLs.
When using Catalyst OS, IDSM-2 inserts permit ip any any capture at the end of the new VACL.
If ARC is managing a device and you need to configure the ACL/VACLs on that device, you should disable blocking first. You want to avoid a situation in which both you and ARC could be making a change at the same time on the same device. This could cause the device or ARC to fail. If you need to modify the Pre-Block or Post-Block ACL/VACL, do the following:
-
Disable blocking on the sensor.
Because you are making a temporary change, you can disable and then reenable blocking by using the IPS Device Manager (IDM) on the device. Alternatively, you can deselect the Enable Blocking option on the General tab of the Blocking policy in Security Manager, then deploy the configuration to the IPS sensor. To reenable blocking, select the Enable Blocking option again and deploy the configuration to the IPS sensor.
-
Make the changes to the configuration of the device. For example, if you manage the blocking device in Security Manager, deploy the updated configuration and wait for the device to reload.
-
Reenable blocking on the sensor.
Understanding the Main Blocking Sensor
Multiple sensors (blocking forwarding sensors) can forward blocking requests to a specified main blocking sensor, which controls one or more devices. The main blocking sensor is the ARC running on a sensor that controls blocking on one or more devices on behalf of one or more other sensors. When a signature fires that has blocking or rate limit requests configured as event actions, the sensor forwards the block or rate limit request to the main blocking sensor, which then performs the block or rate limit.
When you add a main blocking sensor, you reduce the number of blocking devices per sensor. For example, if you want to block on 10 firewalls and 10 routers with one blocking interface/direction each, you can assign 10 to the sensor and assign the other 10 to a main blocking sensor.
You configure main blocking sensors on the Primary Blocking Sensors tab of the Blocking policy, as described in Blocking Page.
When configuring main blocking sensors, keep the following tips in mind:
-
Two sensors cannot control blocking or rate limiting on the same device. If this situation is needed, configure one sensor as the main blocking sensor to manage the devices and the other sensors can forward their requests to the main blocking sensor.
-
On the blocking forwarding sensor, identify which remote host serves as the main blocking sensor; on the main blocking sensor you must add the blocking forwarding sensors to its access list using the Allowed Hosts policy. See Identifying Allowed Hosts.
-
If the main blocking sensor requires TLS for web connections, you must configure the ARC of the blocking forwarding sensor to accept the X.509 certificate of the main blocking sensor remote host. Sensors by default have TLS enabled, but you can change this option. For more information, seePrimary Blocking Sensor Dialog Box .
-
Typically the main blocking sensor is configured to manage the network devices. Blocking forwarding sensors are not normally configured to manage other network devices, although doing so is permissible.
-
Only one sensor should control all blocking interfaces on a device.