|[ LiB ]|
The devices in Table 11.1 have been tested and approved to work with Cisco IDS sensors and device management.
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 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.
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:
A DES or 3DES encryption license is required when using SSH for communications between the blocking sensor and the managed device.
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.
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.
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.
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.
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.
By default, the Sensor enforces blocking for 30 minutes. Determine the most suitable duration for your network environment.
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.
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.
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.
The four steps in the blocking process are as follows :
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 ]|