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.
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.
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 ?
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.
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.
DocumentationCode download linksGoalRequirementLimitationsSupported ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and UCS-E Blades:Step by Step ConfigurationConfigure one of the connectivity options to access the Cisco IMC from the n...
Firepower Threat Defense (NGFWv) on UCS E-series - Transparent Mode in HA
DocumentationCode download linksGoalRequirementLimitationsSupported ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and UCS-E Blades:Step by Step ConfigurationCo...
I am currently unable to specify "crypto keyring" command when configuring VPN connection on my cisco 2901 router.
The following licenses have been activated on my router :