Troubleshooting the Cisco IDSM Sensor
Troubleshooting the IDSM might feel somewhat overwhelming at first, but in reality you know a lot of the procedure already. There are commands and even LEDs that we can look at to get an idea of what the problem of our broken IDSM could be. We will start with the simplest of items, the physical diagram of the IDSM. In Figure 6.16, we have a basic diagram of the IDSM.
The two most critical parts to know about are the Status LED and the shutdown button. The status LED will show three different colors, or be off completely if the power is off.
-
Green means all diagnostics have passed and the IDSM is operational.
-
Red means a diagnostic test other then an individual port test.
-
Amber means the IDSM is running through the bootup OR the IDSM is disabled.
-
Off means the IDSM power is off.
To keep from corrupting the Windows-based operating system, you need to properly shut down the IDSM before hitting the power switch. The proper way to shut down the IDSM is to use the shutdown command from the Catalyst switch console. If the shutdown command fails to work, you can use the Shutdown button to force the IDSM to shut down.
| Note | The default for the IDSM configuration is to have the direct Telnet feature of the IDSM disabled. Do not mistake this default as an error of the IDSM. |
One of the first commands to use to check a difficult IDSM sensor is the show module command. This command will let you quickly verify that the module is in the slot you think it is and what its current state is. If the module is in an "other" state, use the reset command to try and jumpstart the IDSM sensor back to life. Remember, you are dealing with Windows in version 1 and some of our favorite "features" are alive and well in the IDSM sensor, thus it does not handle errors in the configuration very well. In one system we used, an error occurred while configuring Telnet permissions, and when the IDSM sensor was rebooted, it went into a fault mode and refused to let anyone connect. The only fix was to reinstall the OS using the upgrade process discussed earlier in this chapter. In extreme cases, you might need to power off the module or, if necessary, remove the module from a live switch. To do this, use the set module power command as discussed earlier in the chapter. It's shown next:
switch> (enable) set module power down
When the module is powered down and ready to be powered back up, just reverse the command to say:
switch> (enable) set module power on
If you can not Telnet to the module or get it to reset from the switch, the last resort is to use the Shutdown button on the front of the IDSM sensor unit. This forces the system to shut down regardless of its current state.
A common problem is that the IDSM can't see the expected traffic when it is enabled. This occurs most often when the monitoring port or port 1 is not in the correct VLAN, or the access-lists are incorrect. This also holds true when you are trying to upgrade the IDSM and you can't get to the FTP server from the IDSM. Check the VLAN that the command and control port is in and verify that it is the correct VLAN. In Figure 6.17, we can see that port 4/2 is in the backbone VLAN.
 |
switch> enable
Password:
switch> (enable) show vlan
VLAN Name Status IfIndex Mod/Ports, Vlans
---- -------------------------------- --------- ------- ----------------
1 default active 5 3/15-16
3 Finance active 83
4 IDF-1 active 77 2/27-29,2/37-48
5 IDF-2 active 84
6 IDF-3 active 79
7 IDF-4 active 80
10 HR active 86
20 backup active 92 1/1-2
2/1-6,2/9-26,2/30-36
3/6-14
4/2
100 delete active 89
101 FAILOVER active 91
1002 fddi-default active 6
1003 token-ring-default active 9
1004 fddinet-default active 7
1005 trnet-default active 8
|
Figure 6.17: Sample of the show vlan Command
To verify that the correct IDSM software has been uploaded to the IDSM sensor, or to prepare for an upgrade, we need to look at how the IDSM software filename is structured. In Figure 6.18, we see the basic structure of the filename.
The filename is composed of five parts, as outlined in the following list:
-
Software type This will be one of the following:
-
Application (a) Cisco IDS engine image
-
Maintenance (m) Cisco IDS maintenance image
-
Service Packs (sp) Cisco IDS engine fixes
-
Signatures (sig) Cisco IDS signature updates
-
-
Cisco IDSM version The version number is a numeric value and is separated by the use of a decimal point. The preceding number is the major version and the later number is the minor version.
-
Service pack level This is the level to which the code has been patched to.
-
Signature level The signature version is the Cisco IDS major and minor release level.
-
Extension This can be one of the following filename extensions:
-
Exe Self-extracting executables such as signature or service packs
-
Cab A Microsoft format used for the IDSM software images
-
Lst List of cab files required for an IDSM software image
-
Dat A binary file containing information required for the installation of an IDSM image
-
For example, in previous examples we used the file IDSMk9-a-3.0-1-S4.DAT. This file is application 1 for the IDSM major version 3 and the minor version of 0. The signature is version 4 and composes the DAT file for the update.
Other useful commands to aid in troubleshooting the IDSM sensor are used from the switch prompt (switch>). These include:
-
(enable) show config This prints out the entire configuration of the IDSM
-
show span This shows us the span configuration and which ports are used
-
show security ACL This displays the current security access-list in use
From the IDSM sensor prompt, we have the following commands to aid us with troubleshooting the IDSM sensor:
-
idsm# show configuration
-
idsm(diag)# show eventfile current
The show configuration command will display the current memory statistics, the diskspace used, the sensor version, and the current IDS processes running (a key item). In a properly configured IDSM, the following processes should be running:
If any one of these processes is not running, we move onto the next command, which is show eventfile current. The show eventfile current command displays the Windows event log, which may provide clues as to what might be the issue with the IDSM sensor. In Figure 6.19, we show a sample from the eventfile log:
|
idsm(diag)# show eventfile current
4,47,2003/06/18,22:40:23,2003/06/18,14:40:23,10008,57,100,OUT,OUT,2,
3030,0,TCP/I
P,10.4.2.75,0.0.0.0,0,139,0.0.0.0,
4,48,2003/06/18,23:21:50,2003/06/18,15:21:50,10008,57,100,OUT,OUT,2,
3030,0,TCP/I
P,10.8.3.24,0.0.0.0,0,139,0.0.0.0,7
|
Figure 6.19: Sample from the Eventfile Log
To start with clear counters and to clear out the statistics, we use the diag resetcount command, as shown next:
idsm(diag)# diag resetcount
To clear out a configuration, we can use the clear config command and remove the IDS configuration. Be warned, however: this also disables the IDSM as mentioned earlier in the chapter.
idsm# clear config
We saw earlier how to apply a service pack to the IDSM, but what happens if something goes wrong with the service pack installation? In Windows, we can uninstall files and the IDSM offers something along the same lines of functionality. The remove command removes the most recently applied service pack or signature from the IDSM.
Idsm(config)# remove