cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2163
Views
10
Helpful
23
Replies

Updates From MC Not Taking On NIDS

ryan.brennan
Level 1
Level 1

We have 2 4235 NIDS devices that are run by a Security Monitor VMS server. Up until version S128 we were able to upgrade both devices through the MC, however this function has stopped working. The subsequent updates (S129 thru S135) appear to have worked, and even running a version report on the MC shows both sensors at S135. However when you manually telnet into each of the two sensors and do a show ver, both sensors are still back on the old S128 code. Any suggestions as to what has failed in the interim, or what service/process could have stopped/failed to stop updates between the Sec Mon and the sensors from happening?

23 Replies 23

Any news on the TAC explanation? We had this issue, but it seemed that overwriting the S125 with two signature upgrades 'fixed' the problem. I have a before and after sh ver on what did not and what did work.

sh ver (not working)

* IDS-sig-4.1-4-S125 16:05:23 UTC Sat Nov 06 2004

IDS-sig-4.1-4-S134.rpm.pkg 15:52:10 UTC Wed Dec 20 2004

(but the signatures did not show in the sensor's config.)

!!!!!!!!!!!!!!!!!!!!

sh ver (this works)

* IDS-sig-4.1-4-S134 15:52:10 UTC Wed Dec 29 2004

IDS-sig-4.1-4-S135.rpm.pkg 18:49:04 UTC Tue Jan 04 2005

I am still working with TAC on the problem. I verified that I can updated the signatures on the NIDS directly, so it appears to be an MC problem rather than a sensor problem. As part of the process, I applied a couple of patches to the IDS MC, and now it no longer incorrectly reports patch levels. On the negative side, it doesn't push the updates out to my sensors either.

Jason, did you receive any tip from TAC on fixing this issue; we're having the same problem as well. I upgrades all our IDS devices to the latest patch and our MC version is 1.2.3 , VMS 2.2 with all updated patches installed. We can update our NIDS directly and the MC seems to be able to query the latest version but it won't push updates out to the devices.

I got a couple of suggestions yesterday, but they did not work for me. I replaced the expired Cert on my MC, but that did not fix it. Also, my MC is not Dual homed, so the second suggestion really is not applicable. On the off chance that they work for you, I have pasted them below...

ADDITIONAL POSSIBLE CAUSES

CERT EXPIRED:

1. Stop CiscoWorks Daemon Manager (from Windows Services control panel) 2. Open DOS window and cd to $BASE\cscopx\mdc\apache\conf\ssl 3. create temp directory and copy all file to temp directory, there should be 4 files: openssl.conf, server.cert, server.csr, and server.key.

4. run "keytool -printcert -file server.cert" and capture output. This should show something like below

D:\Program Files\CSCOpx\MDC\Apache\conf\ssl>keytool -printcert -file server.cert

........

Valid from: Mon Oct 07 23:22:20 CDT 2002 until: Tue Oct 07 23:22:20 CDT 2003 Certificate fingerprints:

......

Note the expiration of "Tue Oct 07 23:22:20 CDT 2003"

5. run "..\..\gencert" you should see something like....

D:\Program Files\CSCOpx\MDC\Apache\conf\ssl>..\..\gencert

Loading 'screen' into random state - done Generating a 1024 bit RSA private key .................................................++++++

.....++++++

writing new private key to

'd:\PROGRA~1\CSCOpx\MDC\Apache\conf\ssl\server.key'

-----

unable to get 'req_attributes' section

problems making Certificate Request

Loading 'screen' into random state - done Signature ok .....

Getting Private key

6. run "keytool -printcert -file server.cert" again. Now you should see something like...

D:\Program Files\CSCOpx\MDC\Apache\conf\ssl>keytool -printcert -file server.cert

......

Valid from: Thu Nov 13 13:37:29 CST 2003 until: Fri Nov 12 13:37:29 CST 2004 Certificate fingerprints:

......

Note the expiration date "Fri Nov 12 13:37:29 CST 2004" (of course you will see a slightly different date, but at the least,a year ahead)

7. restart CiscoWorks Daemon Manager.

8. Now try upgradinng sensor

Another POSSIBLE ISSUE

MULTI HOMED VMS BOX

#######

Multi-Homed Machines

A multi-homed machine is a machine that has multiple NIC cards, each configured with different IP addresses. To run CiscoWorks Common Services on a multi-homed machine, there are two requirements.

* First, all IP addresses must be configured in DNS.

* Second, because of restrictions with CORBA, only one IP address can be used by the client / browser to access the server. You must select one IP address as the external address, with which the client will login to the CiscoWorks server.

To select an IP address, modify the gatekeeper file located in NMSROOT\lib\vbroker\gatekeeper.cfg. Replace every instance of external-IP-address with the external IP address you choose, and remove the "#" character, from the following:

* #vbroker.gatekeeper.backcompat.callback.host=external-IP-address

* #vbroker.se.exterior.host=external-IP-address

* #vbroker.se.iiop_tp.host=external-IP-address

* #vbroker.se.interior.host=external-IP-address

After modifying the gatekeeper file, restart the Daemon Manager by entering

net start crmdmgtd.

#######################

Here are some things to check that cause signature updates to fail.

1. Did the ip address of the IDSMC change since install?

The IDSMC has to tell the sensor where the update package lives.

Here's what to do when the IP address changes:

Stop daemon manager

Modify the following files:

CSCOpx/MDC/etc/ids/xml/SystemConfig.xml

Change value

Copy this file to CSCOpx/MDC/Tomcat/vms/ids-config/web-inf/classes/com/cisco/nm/mdc/ids/common/SystemConfig.xml

Copy this file to CSCOpx/MDC/Tomcat/vms/ids-monitor/web-inf/classes/com/cisco/nm/mdc/ids/common/SystemConfig.xml

CSCOpx/PostOffice/etc/routes

Change Host name and IP address

Restart daemon manager

NOTE: If you have any sensors in the system, you will need to modify each and every sensor. The Configuration->Settings->Communications->Remote Hosts page will need to be modified so that your new IP address is listed, instead of your old IP address.

2: Can the sensor/IDSM2 contact the IDSMC using HTTPS?

If the sensor is between a firewall and the VMS server, the address cannot be NAT'ed. The IDSMC ssh's into the devices and issues the upgrade command with the ip address of the VMS box. It uses the ipaddress of the VMS box from VMS perspective (this is a bug). Make sure the sensor is not NAT'ed. Also make sure that HTTPS traffic is enabled between the sensor and VMS. You can diagnose this problem by trying the upgrade manually.

First let's log onto the sensor.

type show settings

make sure all processes are running.

Then type

config t

tls trusted-host ip-address 10.10.111.222 port 443

upgrade https:///vms/sensorupdate/IDS-sig-4.1-1-S137.rpm.pkg

Use the IDS MC ip address instead of 10.10.111.222.

Use what ever the pkg name is if it is not as listed above.

You'll have to answer yes to some of the above commands.

3. Check the time on the sensor and VMS server

Another thing that can cause the certificate to be valid is the time.

Make sure the time set on the sensor is reasonably close to the time on the VMS server.

Certificates are bad and the hosts are not trusted if the time is off.

ryan.brennan
Level 1
Level 1

I have just been able to upgrade both of my sensors manually through ftp from each sensor's CLI.

I performed all of the recertification steps as mentioned in this thread, which may have allowed the devices to be updated today...however I'm not sure. The true test will be when signature S138 comes out and I try pushing out the sigs through the MC. Hopefully this is no longer an issue. For reference, here are the steps I performed for the certificate experation issue:

1. From console on the VMS/MC server, go to a command prompt and navigate to the c:\progra~1\cscopx\mdc\apache directory. Launch 'gencert.bat'

(this generates a new certificate that is good for one year...unless you go into the batch file and change the days from 365 to 1000, which is what I did.

2. Go to administrative tools/services and stop the CiscoWorks Daemon Manager service. Once stopped, restart it.

3. Go out to the CLI of your sensor and type tls generate-key.

4. Then go to conf t. Type no tls trusted-host ip-address .

5. Then type tls trusted-host ip-address .

You might be asked if this sensor is trusted and able to receive a certificate. Just say yes through the prompts.

After all this was complete I downloaded a free ftp server program and installed it on the VMC/MC server. It's my understanding that the traditional .zip signature files will not work this way. Work your way through Cisco tac and find the signature files that end in .rpm.pkg. Put this file on the root directory you established when launching the ftp server.

Go out to the sensor CLI and use the following syntax from a conf t prompt:

sensor(config): upgrade ftp://anonymous@///

The ftp server will upload the new sig to the sensor and will install and restart the sensor service on it's own. No reboot is required.

To verify, go back to your MC and check the identification setting for each sensor you have. Click the 'query sensor' button to verify if the manual upgrade took.

Now let's keep our fingers crosed when sig S138 comes out.

I followed the same steps to regenerate the certificate on my MC, and I was able to update my sensors from 136 to S137 via the MC. Just make sure you allow long enough for the MC to complete the update...it takes considerably longer than the CLI method, which I also successfully used from another ftp server. I also upgraded from MC 1.2.1 to 1.2.3. Hopefully, this will not break my update ability!

Ryan,

Thanks!! 100% perfect!! Generated a new server cert. and then did the discovery with each sensor and now we're back in business having successfully tested S138 yesterday.

Key were those two steps. Gen. new cert. and then sync up sensors with it. Both CLI operations.

Wouldn't a expiration notification be a nice thing?

Well I'm putting it on my Dec. 05 calendar. :-).

Best regards,

Tom

ryan.brennan
Level 1
Level 1

The new S138 sig came out yesterday and I was able to update both of my sensors via the MC with no issues. Everything is back to normal.

It appears that the certificate expiration issue is the culprit.

Review Cisco Networking for a $25 gift card