Blocking Devices, Requirements, and Guidelines

[ LiB ]  

The devices in Table 11.1 have been tested and approved to work with Cisco IDS sensors and device management.

Table 11.1. Blocking Devices That Can Be Controlled by a Cisco IDS Sensor

Blocking Device


Cisco IOS Routers

Internetwork Operating System (IOS) Release 11.2 or later using ACLs

Catalyst 5000 switches

Cisco IOS Release 11.2(9)P or later with a Router Switch Module (RSM) or Route Switch Feature Card (RSFC), using ACLs

Catalyst 6000 switches

Cisco IOS Release 12.2(13)E or later with Multilayer Switch Feature Card 1 (MSFC1) or MSFC2 installed, using ACLs

Catalyst 6000 switch

Catalyst OS 7.5(1) or later and one of the following:

Supervisor Engine 1A (Sup1A)

Sup1A and the Policy Feature Card (PFC)

Sup1A and MSFC1

Sup1A and MSFC2 or

Sup2 and MSFC2

PIX Firewall

PIX Version 6.0 or later using the shun command and either the 501, 506E, 515E, 525, or 535 models

You can configure blocking using ACLs, VACLs, or the shun command, for IOS, Catalyst operating system (OS), and PIX, respectively. The shun command is supported in PIX versions 6.0 and later.


You can configure blocking using ACLs and VACLs for IOS and Catalyst OS; for PIX version 6.0 and later, configure blocking using the shun command.

Communications Requirements for Blocking

The Sensor also needs to be able to communicate with the managed device via IP and must either have a route to the managed device or exist on the same subnet as the managed device.

For communication with the managed device, you must enable remote network access from the Sensor to the managed device using either Telnet or Secure Shell (SSH).


For a Sensor to communicate with a managed device such as an IOS Router or PIX Firewall, you must enable and permit Telnet or SSH access on the managed device.

If using SSH, which is recommended, the managed device needs an encryption license for Data Encryption Standard (DES) or Triple DES (3DES). You also need to manually configure key exchange using the ssh host-key command. If you opt to use the less-secure option of Telnet, you need to make sure that you complete the following steps:

  1. Enable VTY (Telnet access) and assign a line password on Cisco routers.

  2. Allow Telnet access from the Sensor.

  3. Assign the enable password.


A DES or 3DES encryption license is required when using SSH for communications between the blocking sensor and the managed device.

Blocking Guidelines

You can see that blocking is potentially a very powerful tool for enforcing network security. At the same time, if you implement blocking without proper planning, the results can block legitimate traffic or even shut down critical network services. The following sections offer guidelines for the various network elements, settings, and configurations you need to consider when planning and implementing blocking.

Critical Hosts

Every network has hosts that maintain critical network services and should never be blocked. These hosts should be identified, documented, and considered for never-block ACLs.

Network Topology

Because any managed device can be instructed to block by only one blocking sensor, it is important that you determine the most efficient blocking sensor for each managed device.

Entry Points

Networks today have many entry points to allow for resiliency, redundancy, and remote access. All entry points could potentially expose your network to malicious attacks; it is therefore important that you consider both whether the connecting devices are configurable and manageable from the IDS and whether they are suitable candidates for blocking.

Signature Selection

With the broad range of Cisco IDS signatures that you can configure for blocking, it is important that you plan, manage, and maintain blocking configurations very carefully . Choosing the most appropriate signature for blocking in your network environment can simplify management and support without causing unnecessary disruption to network services. Consider, for example, if you have a server farm that only allows Hypertext Transfer Protocol (HTTP) traffic. You first select a set of Web signatures specific to your servers'operating systems and software. From this set, you narrow down your choices to signatures that, say, had a high severity level. These signatures would be suitable candidates for blocking.

Blocking Duration

By default, the Sensor enforces blocking for 30 minutes. Determine the most suitable duration for your network environment.

Device Login Information

You saw in the previous section that you must configure either Telnet or SSH access for a managed device for it to receive blocking instructions from a Sensor. You should determine all required username, password, permissions, and connection information before configuring blocking.

Interface ACL Requirements

Any given interface/direction can have only one active ACL. Therefore, if you need access control entries (ACEs) on a particular interface/direction as well as the blocking ACE, you should configure the additional ACEs as pre-block and post-block ACLs. A pre-block ACL contains all the ACEs that you want to include before the blocking ACE, whereas a post-block ACL contains all the ACEs that you want to add after the blocking ACE. When the Network Access Controller (NAC) is generating an ACL to block a device, it first includes all the entries in the pre-block ACL. Then, it adds the blocking ACEs and appends the remaining ACEs in the post-block ACL. When blocking is not in effect, the resulting ACL is simply a combination of the pre-block and post-block ACLs. Figure 11.2 shows how pre-block and post-block ACLs work with the blocking ACE.

Figure 11.2. Pre-block ACLs, post-block ACLs, and blocking ACEs. Multiple blocking ACEs are allowed.


NAC Block Actions

You saw in Chapter 5, "Cisco IDS Architecture and Communications Protocols," that the NAC controls the blocking function by starting and stopping blocking on routers, switches, and firewalls. Blocking can be initiated in one of three ways:

  • In response to an alert event when a signature is fired and the EventAction parameter is configured to block a host or connection.

  • Manually from a management interface such as the command-line interface (CLI), IDS Module (IDM), or the Management Center for IDS Sensors (IDS MC). If you initiate a block from the CLI, it can be temporary or permanent.

  • When the NAC is configured to initiate a permanent block, where a host or network address is permanently blocked. If you're using IDM, you can configure a manual block for a specific duration.

Blocking Process

The four steps in the blocking process are as follows :

  1. An event or signature trigger that has a block action associated occurs.

  2. The NAC pushes out a new set of configurations or ACLs, one for each interface/direction, to each managed device. The blocking rules are applied to all interface/directions that the NAC is configured to control.

  3. The EventStore receives an alarm while the Sensor initiates the block. The alarm and block events occur independently of one another.

  4. Finally, when the blocking event is complete, all configurations or ACLs are restored to their original pre-block configurations.


If the NAC is configured to issue a permanent block, the Telnet or SSH session between the NAC and the managed device is maintained .

You can specify a time limit for any manual block except for a permanent block, which is in effect as long as it's configured. By default, an automatic block lasts for 30 minutes before pre-block configurations are restored.


The duration of automatic blocks is set globally for signatures to a default value of 30 minutes.

[ LiB ]  

CSIDS Exam Cram 2 (Exam 642-531)
CSIDS Exam Cram 2 (Exam 642-531)
Year: 2004
Pages: 213 © 2008-2017.
If you may any questions please contact us: