Understanding the Cisco IDSM Sensor
The IDSM sensor module differs from other,
more conventional IDS sensors from Cisco by being a blade- or module-based
solution. Unlike the 4230 sensor that uses a form of Solaris as the OS and runs
on a dual Pentium PC in a box, the first generation of IDSM blades uses an
embedded form of Windows, while the second generation uses Red Hat Linux as the
OS. In both types of sensor, there is a complete PC on a card with hard drive,
memory, ports, and the OS. The IDSM card occupies one slot on a Cisco Catalyst
6000/6500 series switch. You have to stack the IDSM sensors in the switch to
aggregate the throughput of the IDSM which until recently was 250 Mbps of
traffic. Figure 6.1 shows an architectural view of the IDSM.
Notice how traffic flows through the switch, and how the IDSM can see the
traffic.
This architecture is one of the reasons the Cisco IDSM is so
little understood. The fact that the IDSM sensor actually sits in the switch as
a blade and directly connects to the switch backplane confuses many people.
Contributing to the confusion is the difficulty in finding any information on
installing and configuring the IDSM sensor. The Cisco IDSM sensor is not a cheap
device and, as a result, there are not very many IDSM sensors installed. This
cost is multiplied when you consider that you first need the Catalyst 6000/6500
chassis before installing and using the IDSM sensor. The cost of the Catalyst
switch chassis alone precludes having one of the IDSM sensors in your home lab
or even in most commercial Cisco labs.
As we mentioned, the IDSM sensor has a processor, RAM, BIOS, and a
hard drive, which is typical of a PC-like architecture. Unlike a PC, however,
there are two ports. The first port is the monitoring port, while the second is
called a Control Port. The monitoring port is port 1 and is set up to
automatically trunk all VLANs by default. Port 1 uses 802.1q as the trunking
protocol. The control port is port 2, which will have an IP address assigned to
it through which the ISDM sensor is managed.
The older IDSM v1 sensor was much more limited in what it could,
and could not, do relative to the IDS appliance. For example, the older IDSM
sensor could not offer TCP resets, command-line management, Web-based
management, or IP logging. The new IDSMv2 sensor offers all of these
improvements and more, such as not having to use the Cisco Postoffice protocol
to communicate between sensors or the director. Since the new IDSM-2 sensor can
run 4.0 and newer code, the sensor can use a new protocol called Remote Data
Exchange or RDEP. This new protocol is not available to the IDSM-1 since the
IDSM-1 code development stopped at version 3.1. However, with version 3.0 and
3.1 code, the port number used for the Cisco Postoffice Protocol can now be
specified to whatever the administrator would like the port number to be.
The IDSM-1 sensor can monitor up to 100 Mbps of traffic based
on a minimum packet size of 64 bytes, while the IDSM-2 sensor can monitor up to
600 Mbps of traffic. In both IDSM sensor units, the traffic is captured directly
off the switch backplane. It is possible to use more then one IDSM sensor to
scale the monitoring ability of the IDSM sensor and switch combination. If the
Cisco switch has a Policy Feature Card (PFC), the switch can be configured to
use VACLs to capture the traffic. All supported Cisco switches can use the
Switch Port Analyzer (SPAN) option. If the switch has an MSFC, it can use MLS IP
to capture traffic. The IDSM differs from the conventional IDS in that it can
monitor multiple VLANs simultaneously by having the monitoring port configured
as a trunk. Since the IDSM sensor sits on the backplane of the switch and has
direct access to the data flow, it does not impact the switch performance. The
signatures and attacks that the IDSM can detect mirror those used by the 4200
series of sensors.
Sections
Comments (0 posted)
Syndication
