Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements
You may experience some slow load times, errors, and slight inconsistencies. We ask for your patience as we finalize the launch. Thank you.

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

CSPM 2.3.3i S11 / IDSM 3.0(2) S10 Blocking

We are having problems getting blocking working with CSPM 2.3.3i and IDSM 3.0(S10). If I view the block list in event viewer I do indeed see a list of hosts that are being blocked, however there are NO ACL's being generated on our blocking router which is 6500 MSFC. We have tried two different interfaces for blocking. Strangely enough, this worked for a total of about one hour last Friday, but then the ACL stopped being updated and hasn't been updated since. I have removed the ACL it created and it will not create a new one. I have tried moving the ACL to a different interface with no success either. All in all I am seeing A LOT of problems using blocking with the IDSM and CSPM. Has anyone experienced this and if so has anyone resolved this? In addition to this what do the Pre-shun ACL and Post-shun ACL fields mean when setting up the blocking device in the sensor config? Anyone have any good CCO links concerning blocking with the CSPM and IDSM? I can't find much on that particular subject.

Jason Fletcher

  • Other Security Subjects
7 REPLIES
Cisco Employee

Re: CSPM 2.3.3i S11 / IDSM 3.0(2) S10 Blocking

In order to diagnose what is happening you will need to look in the managed.conf file and ensure that your router is listed along with the necessary interface names.

Then also check the errors.managed files to see if managed is generating any errors.

Also look at the show conf output to see if managed is running.

A quick way to gather all the information is the "report systemstatus" command under the diag menu.

It will generate an html file that will be ftp'd to an ftp server you designate when running the command.

Then you can open the html file with netscape or internet explorer.

If you can not determine what is wrong then it sometimes help to have a sniffer watch the connection between the module and the router. You would have to attach the sniffer to a span port on the switch and span the command and control port (port 2) of the module. You shouls see the module telnet to the MSFC and login. Then it will run through several commands. Look through the sniffer trace and see if the router is sending back any errors to commands being executed by the sensor module.

As for more information on the blocking feature you can refer to the Appliance Config Note. The managed

daemon which does the blocking is the same for both the appliance and the module.

http://www.cisco.com/univercd/cc/td/doc/product/iaabu/csids/csids6/12216_02.htm#xtocid1115831

PreShun ACL -> The name of an existing ACL on the router. Managed will read in the contents of the acl that matches the name you place in this field, and when it creates the new acl it will place the contents of the PreShunACL prior to placing in the deny lines to block the addresses.

PostShun ACL -> Similar to PreShun ACL except that the ACL contents will be placed after the deny lines tha block the addresses.

If you already have an ACL applied to the interface that you want the sensor to block on then put that ACL name in the PostShun ACL field. Managed will read in the ACL into memory, create a new ACL, and apply the new ACL to the interface. Your ACL will no longer be applied to the interface because only one ACL can be applied at a time, but your ACL'S contents should be in the sensor's ACL.

NOTE: Your ACL should not be removed from the router, because managed will reread this ACL to refresh it's memory every time the sensor is restarted or reconfigured.

New Member

Re: CSPM 2.3.3i S11 / IDSM 3.0(2) S10 Blocking

Thanks for this information. I had my suspicions about the pre-shun and post-shun ACL's but just wanted to verify exactly what they were looking for in those fields. This is what I have found on the blocking issue:

1. I verified the managed.conf file on the sensor does include my MSFC and the POS3/0/0 interface that we want to use to block. The IP address is also correct.

2. Managed is running on the sensor.

3. The following errors are being generated by managed but I have no idea what is up yet:

(several at beginning of error log)

E Error: Could not determine net device type at IP [our MSFC's IP address]

(fills the rest of the log)

E Comm timeout for [our MSFC's IP address]. No recovery action will be taken at this time.

5. We have a NAM in the switch so I will see what kind of traffic I can capture between our IDSM management interface and the MSFC.

6. Another item that I wanted to bring up is that during the few hours ACL generation and blocking was working, the MSFC would perform a write mem every single time the ACL was updated. Is there a way to prevent this from happening?

Again, thanks for the quick replies to these post, you are a great help to people like me who are pretty new to the world of intrusion detection.

Jason Fletcher

Cisco Employee

Re: CSPM 2.3.3i S11 / IDSM 3.0(2) S10 Blocking

The error "Could not determine device type" occurs when nr.managed does not recieve a message from the network device that identifies its type. Some routers have been observed to do this. To recover, set the device type to "Cisco" in managed.conf. Right now, it is probably "CiscoDefault".

Nr.managed always performs a write mem when updating the ACL. In the current version there is no workaround for it. Is this causing an undesirable result on the MSFC?

Sean Leary

stleary@cisco.com

New Member

Re: CSPM 2.3.3i S11 / IDSM 3.0(2) S10 Blocking

Sean, that fixed the problem. BUT, every time I use update on the CSPM to save everything it must see this as an error and it changes it back to CiscoDefault. Any way around that? Also, as far as the write mem issue, the only "problem" is that we get a "Card removed from slot 3 interfaces disabled" trap in Openview everytime a write mem takes place. This trap is being generated by our second MSFC that is in standby mode in the same chassis.

Jason Fletcher

Cisco Employee

Re: CSPM 2.3.3i S11 / IDSM 3.0(2) S10 Blocking

Here is a possible workaround to the CSPM problem you are seeing:

NOTE: I have not tested this in our lab, so I can't guarantee it will work.

On the CSPM machine edit the following file (be sure to make a backup in another diretory before editing):

C:\Program Files\Cisco Systems\Cisco Secure Policy Manager\bin\templates\idsm-3.0\etc\managed.conf.template

Look for the line that begins with:

<<:MANAGEDROUTERS30EXPANDED eachrow="NetDevice <<</p><p></p><p>Change the paremeter that reads:</p><p><<StringParameter::DeviceType>></p><p>To be simply:</p><p>Cisco</p><p></p><p>The <<StringParameter::DeviceType>> pulls CiscoDefault from the CSPM Database, by changing it we are telling CSPM not to pull that parameter from the database, but instead to just put the word Cisco.</p><p></p><p>NOTE0: The above change will only have an affect after the Update button has been hit in CSPM to create new configuration files for the sensors, and the Approve has been used to push the configurations to the sensors.</p><p>NOTE1: The above workaround is writen specifically for managed running on a 3.0 IDSM, changing if for the appliance would require changing the managed.conf.template in the directory for the appliance.</p><p>NOTE2: This change will wind be applied to ALL of your 3.0 IDSMS, so be carefull.</p><p>NOTE3: This change will ensure managed works Cisco Routers, but if you IDSM is also managing PIX Firewalls and/or Cat 6000s using VACLS then this will cause problems, and the workaround can not be used.</p><p>NOTE4: Because of the other NOTES I would retest each of my sensors being able to manage their designated routers/firewalls/switches after the change has been made in CSPM.</p><p></p><p></p></body>">

Cisco Employee

Re: CSPM 2.3.3i S11 / IDSM 3.0(2) S10 Blocking

To make the 'write mem' command optional, you can open a TAC case and request this

as an IDS enhancement.

Cisco Employee

Re: CSPM 2.3.3i S11 / IDSM 3.0(2) S10 Blocking

The Forum web page interprets the brackets in my previous message as html tags, so I am reposting the message.

In the following lines the "less than" and "greater than" symbols which were being interpretted as html tags are replaced with "{" and "}" for my example:

On the CSPM machine edit the following file (be sure to make a backup in another diretory before editing):

C:\Program Files\Cisco Systems\Cisco Secure Policy Manager\bin\templates\idsm-3.0\etc\managed.conf.template

Look for the line that begins with:

{{TableParameter::ManagedRouters30Expanded eachRow="NetDevice {{

Change the paremeter that reads:

{{StringParameter::DeviceType}}

To be simply:

Cisco

The {{StringParameter::DeviceType}} pulls CiscoDefault from the CSPM Database, by changing it we are telling CSPM not to pull that parameter from the database, but instead to just put the word Cisco.

NOTE0: The above change will only have an affect after the Update button has been hit in CSPM to create new configuration files for the sensors, and the Approve has been used to push the configurations to the sensors.

NOTE1: The above workaround is writen specifically for managed running on a 3.0 IDSM, changing if for the appliance would require changing the managed.conf.template in the directory for the appliance.

NOTE2: This change will wind be applied to ALL of your 3.0 IDSMS, so be carefull.

NOTE3: This change will ensure managed works Cisco Routers, but if you IDSM is also managing PIX Firewalls and/or Cat 6000s using VACLS then this will cause problems, and the workaround can not be used.

NOTE4: Because of the other NOTES I would retest each of my sensors being able to manage their designated routers/firewalls/switches after the change has been made in CSPM.

103
Views
0
Helpful
7
Replies