Re: Unable to update CSPM signatures (s7)

csimpson · ‎09-06-2001

I have attempted to use the CSPM 2.3.2i Signature Update Wizard to update the signatures on the sensor. Unfortunately, it is not updating them and it doesn't give me an error message saying that anything went wrong. Can anyone give me any advice on this?

Should I update the signatures directly on the sensor?

marcabal · ‎09-06-2001

There has been some confusion on what the Signature Update Wizard in CSPM does. The Signature Update Wizard does not update the sensors, instead it only detects if a sensor has been updated, and will allow you to update the CSPM itself if a sensor has a higher signature level than what CSPM knows about.

So the proper steps to follow would be:

1) Install the S7 Signature Update directly on each sensor individually (Or use the idsapply to have the sensor update utself on a schedule basis).

Once the sensors have been updated then you can use the wizard.

2) In the wizard select the sensors and have the wizard check the sensor versions.

3) If CSPM itself has not been updated with the S7 signatures then it will prompt you for the S7 Signature Update for the CSPM box.

NOTE: The S7 Signature Update file for the CSPM box is a different file than the S7 Signature Update file for the sensors.

4) Once the CSPM box has been updated, then you can press the Save button.

5) Now make any changes you want to the new signature settings.

6) Press the Update button, and CSPM will now generate new configuration files. For the sensors that have had the S7 update loaded the new configuration files will contain the new S7 signatures.

7) Approve the sensor configurations, so CSPM will push the new configurations to the sensors.

NOTE: When S7 was loaded on the sensors their configuration files had the new S7 signatures added so it is only necessary to push new configurations at this time if you changed the settings for the new S7 signatures.

giovanni · ‎09-07-2001

> 1) Install the S7 Signature Update directly

> on each sensor individually (Or use the

> idsapply to have the sensor update utself on

> a schedule basis).

I can find no documentation about the idsapply command.

What is it supposed to do and how? How do I configure it?

Thanks,

Giovanni

marcabal · ‎09-07-2001

My error. The command is idsupdate and not idsapply.

Refer to the Configuration Note for 3.0:

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

giovanni · ‎09-11-2001

A couple of questions about idsupdate:

- I updated a S6 sensor to S7. This seemed to work, the new sigs are there and nrvers reports 3.0(1)S7, but the header of packetd.conf says the file is version S6.

- How do I uninstall a sig update installed via idsupdate? Running a copy of IDSk9-sig-3.0-1-S7.bin with the -U switch doesn't work.

A note to others who try this: do not put the updates in the root directory of the ftp server, you must use a subdirectory else it doesn't work. I don't know if this is documented.

Thanks,

Giovanni

marcabal · ‎09-11-2001

The header in packetd.conf is just a comment placed there by CSPM.

The S7 sensor update doesn't do anything with the comment lines, so the CSPM comment is not changed.

The S7 Signature Update should be able to be uninstalled with the -U option even when auto installed by idsupdate. Could you provide a screen dump of the output where the -U option doesn't work? I tried it here in our lab and did not have a problem.

As for the placing of the updates is in the root directory, I have verified that it works.

When specifying the URL you must use /./ to state the directory:

giovanni · ‎09-13-2001

The header in packetd.conf was later updated by CSPM later, so you're 100% correct.

After this it was also possible to uninstall manually the S7 sig pack, and I am not able to reproduce my earlier problem, sorry.

As for the ftp root path, I was using / which looked more intuitive than /./ No big deal, I was just trying to help others to not waste time investigating this 'problem'.

Thanks a lot,

Giovanni

teperjesi · ‎09-12-2001

Hi!

I upgrade my Sensor from 2.2.1.x to 3.0(1)S7 and the CSPM 2.3.2i to S7 and I have some problem after that!

1, On the Sensor is no nr.configd any more, but the CSPM looks for that, and sends "Service Unstartable!" message

2, If the CSPM wants to generate the Command, it sends a :

ERROR MESSAGES

unable to realize parameter set - Not a supported sensor version "3.0(1)S7"

Unable to realize sensor's parameters

3, On the Sensor stops the packet capturing(the current log.* doesn't grow)! errors.packetd contains the following:

09/12/2001 16:51:12UTC W Warning - Unable to open signature file: ../etc/SigUser.conf

09/12/2001 16:51:16UTC E Traffic flow has started for fastethernet interface.

W Warning - Unable to open signature file: ../etc/SigUser.conf

4, My automatic transfer from the log files to a Ftp server doesn't work properly. messages.sapd contains this message:

Wed Sep 12 16:27:46 GMT 2001 FtpTransfer: log.200109121406

sapx:(log.200109121406,0,0) FTP Transfer

ftp> open 193.68.36.141

Connected to 193.68.36.141.

220 3Com 3CDaemon FTP Server Version 2.0

Name (193.68.36.141:netrangr): sensor

331 User name ok, need password

Password:

230 User logged in

ftp> E prompt seen with unknown nextState: 3

Forcing process [586] to close

sapx: ERROR: Unknown error code

I have a NR-2E-DM Sensor!

Thanks!

marcabal · ‎09-12-2001

You've presented a couple of issues:

1) nr.configd error

nr.configd was removed beginning in version 2.5 of the sensor as it was no longer necessary.

Once valid 3.0(1)S7 configuration files are pushed you shouldn't receive this error anymore.

2) CSPM not recoginzing the 3.0(1)S7 version of the sensor

I have seen this when CSPM became confused on the sensor version.

Verify that Help->About on CSPM shows 2.3.2(build2450)

Verify that when you double click on the sensor the Sensor Version in the Properties/Identification Tab shows 3.0(1)S7. If it does not then select 3.0(1)S7 and select OK. If 3.0(1)S7 is not an available option then it is possible that the S7 update for CSPM was not successful.

Select Update to ensure that the Database has been updated and generates new files based on the 3.0(1)S7 version.

Then once the files are generates try approving them again.

If this still presents the same error, you can try to

a) Delete the sensor from the topology

b) Select Update

c) Re-Add the sensor to the topology and select the check box to verify the sensor's address. The Add Sensor should properly detect the sensor version of 3.0(1)S7.

If you still have a problem after this I would call the TAC for further assistance.

3) current log.* file doesn't grow

2 things to consider: By default loggerd is not started by CSPM. You have to go to the logging tab and check the bix to enable logging on the sensor itself. Checking this bix places loggerd in the /usr/nr/etc/daemons file on the sensor. You can type nrvers on the sensor, if loggerd does not report a version then this is likely the problem.

The other thing to consider is that the log files changed back in 2.5. We went to memory mapped files. So when loggerd opens a log file it will open the maximum size of hte log file and claim all

of the disk space for the file, and then slowly fill in the disk space as it receives alarms. So you can not use the size of the file to judge if new alarms are coming in, or use commands like "tail -f" to see if new alarms are coming in. Instead try using "strings log.*" and look closely at the last line it shows, then execute "strings log.*" again and see if any more alarms came in after the last alarm you saw before.

Errors.packetd warnings:

09/12/2001 16:51:12UTC W Warning - Unable to open signature file: ../etc/SigUser.conf

09/12/2001 16:51:16UTC E Traffic flow has started for fastethernet interface.

W Warning - Unable to open signature file: ../etc/SigUser.conf

The signature file warnings "Unable to open signature file: ../etc/SigUser.conf" let you know that packetd is not seeing the new configuration file that comes in 3.0. This configuration file si generated when you use the commmand SigWizMenu to create Custom Signatures. So if you have not used SigWizMenu then you can ignore this error, but if you have used SigWizMenu to create Custom Signatures then this is indicative of a problem since the Custom Signatures are configured in that file.

As for the "Traffic flow has started for fastethernet interface." this is simply informational to let you know that packetd is seeing traffic on the sniffing interface.

4) This ftp problem sounds familiar. We have had situations where our automated ftp client did

not recognize the responses from certain types of ftp servers. We have fixed a few issues like this.

It is possible that this is a new problem in 3.0, or it may have been fixed in 2.2.1 and we neglected to pull the fix into 3.0??

Was this working back with your 2.2.1 sensors? Did you have to get a special build for your 2.2.1 sensors to get it to work?

If you can answer these 2 questions then I can get an engineer to take a look and respond on this forum to you.

stleary · ‎09-12-2001

Concerning ftp problem #4.

This issue is still outstanding with nr.sapd. I know it exists in 3.0, but don't know

about earlier versions. Try using a Solaris ftp server. If that is not possible, try

other unix ftp servers, until we fix this problem.

teperjesi · ‎09-13-2001

Sensor Issue: After you answer guessed, that my sensor works properly after the upgrade(except the ftp issue).

Cspm Issue: I tried all of your advices, but my cspm didn't generate the command for the sensor. So I uninstall the software and reinstall it again and import the topology from a cpm file. And it works properly!

FTP Issue: Answer to your question is NO! It didn't work on my 2.2.1 Sensor, but I heard, that it will be fixed in the 2.5 version. Now I try some Ftp Server.

Thanks for the help!