SigWizMenu

[ktimm]

Is it necessary to use SigWizMenu for sig creation in newer code ? Can I just write strings matches and distribute those in packetd files ? I have noticed some log messages before when certain files associated with SigWiz are not created.

[marcabal]

The Custom String Match signatures available in older version are still completely supported in the latest versions of the sensor, and packetd.conf files are still used to distribute those.

So if the new signature is just a string match then the old method of Custom String Matches can still be used or the new method of Custom Signatures can be used.

If the new signature is for web servers then I recommend using Custom Signatures because when the STRING.HTTP engine is used the url request is deobfuscated (undoes something hackers do to hide their attacks) before attempting to match the regular expression of the signature, unlike Custom String Matches which would miss the attack if it was obfuscated by the attacker.

If the new signature requires specific packet headers then Custom Signatures are what is needed.

As for the error log messages created, these can be safely ignored is you have not entered anything through SigWizMenu. The only time to worry is if you have entered information in SigWizMenu and still receive the error because then your changes are not being read.

[ktimm]

Is there a way to get the benifits of deobfuscaion without having to manually log into each sensor and run SigWizMenu ?

[klwiley]

If you are using the Unix Director to manage your sensors you may use the custom signature development interface that is included with it. If you are using CSPM the procedure is a bit more complex.

First you will create a SigUser.conf and SigSettings.conf through SigWizMenu on a single sensor.

Second you will need to cut and paste the signature definition line out of the SigSettings.conf file into the prologue window on CSPM.

Third you must cut and paste the SigOfGeneral lines out of the SigSettings.conf file into the prologue window on CSPM.

Finally you can apply the new configuration to the sensors in CSPM.

[waynepua]

Hi klwiley,

After applying the new config to sensor in CSPM using Command Approval, do u get to see those new signature defined in SigWizMenu under Sensor Signature Menu, such as under General Signature or String Signature tab ?

[marcabal]

There are two types of user generated signatures:

1) Custom String Signatures - which has been around for a few years. This is configurable through CSPM on the string signature tab.

2) Custom Signatures - these are new in 3.0. They are not configurable in CSPM. SigWizMenu is a program on the sensor that can be used to help users create these new Custom Signatures. It creates two new configuration files on the sensor for packetd: SigUser.conf and SigSettings.conf.

These configurations could have been in packetd.conf, but CSPM deletes and rewrites packetd.conf when new configurations are pushed from CSPM so we had to create new configuration files to hold the configuration so CSPM wouldn't delete them.

If a user is using CSPM to manage multiple sensors and doesn't want to have to telnet to each sensor to create the Custom Signatures then they can:

1) Create the Custom Signature on one sensor using SigWizMenu

2) Copy the correct lines from SigUser.conf and SigSettings.conf that pertain to that signature.

3) Add them to the epilogue in CSPM for each sensor.

In version 2.2.0 of CSPM, if a new configuration parmater was created for packetd, which CSPM didn't know about, then the user couldn't use the new configuration. In version 2.3.3 the CSPM now has an Epilogue feature where this new configuration that CSPM doesn't know about can be put. The lines are then added to the packetd.conf file on the sensor.

So now CSPM pushes the new configuration for these new signatures, but all the configuration has to be done in plain text in the Epliogue window, instead of CSPM's nice GUIs for editing the standard Cisco signatures.

[waynepua]

Should these additional config copied from Sensor SigSetting.conf and SigUser.conf files be placed into CSPM epilogue or prologue window ? Functionally, is there any difference ?

[marcabal]

Epilogue will place the configurations at the bottom of packetd.conf, while Prologue will place the configurations at the top of packetd.conf.

For these configuration settings packetd won't care whether they are at the top or bottom of the packetd.conf file.

Packetd treats the contents of SigSettings.conf and SigUser.conf as if they were part of packetd.conf; so placing the tokens in packetd.conf is the same to packetd as if they had been in SigSettings.conf or SigUser.conf.

The only difference is that the SigWizMenu program will only read configurations from SigSettings.cong and SigUser.conf.

NOTE: I am not aware of any special configuration settings that have to go in Prologue and not Epilogue, or in Epilogue and not Prologue. But there may be in the future.