When downloading a new signature pack, I follow the instructions in the readme.txt meticulously.
I first update CSPM and reboot.... all is well.
Then I highlight all of my sensors, query them, generate signature files for them, save and update, and then approve the command sets to be sent to the sensors.
Sure thing.... but why is it that the sensors still report the old version?
When the next signature update comes out, and I query the sensors, they all report an old version.
Okay fine for now perhaps, but what about in the future where the 'minimum' signature level for a patch is now too low?
<rant on>One thing that drives me crazy about this entire Cisco IDS solution is that nothing is ever easy about it. Seems that any decent question can only be answered by opening a TAC case, or, thank heaven, posting it in this forum<rant off>
Our experience has been the same. It seems if you keep trying (worst case reboot the CSPM server multiple times and maybe the sensors (4230's), the sensor update will eventually work for no apparent reason. We now examine the Packetd.conf on the sensors as part of the update routine to be sure our updated signatures are actually there. If the time and date on the packetd.conf file on the sensor is not current with your last "Approve Now" you do not have the updated signatures on the sensor.
I have been trying to answer this question myself. The only way I have found to update the version is to actually do a seperate upgrade on the Sensors, for example:
Step - 1 Update the CPSM signature file, then re-boot.
Step - 2 Update the Sensor signature file i.e FTP the .bin file to the sensor and then run the ./.bin -I command. Once complete do a nrvers to verify the version running.
Step - 3 On the CPSM carry on with the procedure i.e generate signature file then approve.
It seems that Cisco recognise that this product clearly does not function properly and is not user friendly ... Let's hope that Cisco will resolve this in the new Security/Device Manager Product which seems to a rumour at this moment in time.
For clarification, are you actually updating the sensor itself? I read where you said that you follow the readme.txt instructions meticulously, but where you summarized your steps, there's no mention of actually updating the sensor.
Excuse me if you're already aware..., when you perform the CSPM sig update for a sensor, you're updating CSPM so it knows about the new sigs for that sensor. This process doesn't update the sensor itself with the new sigs. You still have to perform the sig update on the sensor.
"This process doesn't update the sensor itself with the new sigs. You still have to perform the sig update on the sensor"
Oh I see. I understood fromt the readme.txt documentation that the second step (after updating CSPM and rebooting) was to generate signature files for the sensors. Does it actually generate the signature binary file also?
If not, it would appear that I have a packetd.conf file on my sensor with reference to signatures it does not actually know about?
If that is the case, then I was not aware of this. So even though CSPM is being used to manage the sensors, I still need to run idsupdate on the sensors themselves?
If that is the case, is the purpose for generating 'sensor files' only to generate an appropriate packetd.conf that can be sent out to the sensors?
I will hold off on configuring idsupdate on each of my sensors for now.
The sensors must each be independantly updated with the sensor update file.
The CSPM must also be updated with the CSPM update file.
The sensor update will make all the necessary binary changes for the new signatures.
It will also add these new signatures to the packetd.conf file, signature file, and other internal configuration files.
So if you install the sensor update, the sensor is now monitoring for the new signatures without any changes being made to CSPM.
The sensor update can be installed manually with the "-I" option, or you can setup idsupdate which will on a scheduled basis download new sensor updates from an ftp server and execute the updates itself with the "-I" option.
The CSPM update, adds configuration files to CSPM so it knows about the new signatures. This is so that the Event Viewer can put the proper name to the signatures, and CSPM can generate packetd.conf files with the new signatures.
Immediately after the update the sensor will start monitoring for the new signatures and generating alarms if it sees any. If you type nrvers on the sensor you will see that the new signature version is running. CSPM will receive the alarms, but the Event Viewer in CSPM won't be able to put a name to them, and you won't be able to select the alarm and look up a description in the NSDB.
BUT the next time you may make a change in CSPM and hit the Approve button, CSPM will come back and tell you that the versions do not match. You have the option of pushing the configuration even though the versions don't match. The problem is that CSPM has generated a new packetd.conf without these new signatures. So as soon as you hit approve and that packetd.conf file is sent across, the sensor will STOP alarming for those new signatures, and you might as well not have applied the signature update to the sensor.
What if I apply the signature update to CSPM, but not my sensors?
CSPM now knows about the new signatures.
Each sensor has a version field in CSPM.
You should always try to keep this in sync with what is actually loaded on the sensor, it does not change what is loaded on the sensor.
- If the version field in CSPM for that sensor is correct for the sensor (let's say S15), and we have a newer version (let's say S17) on CSPM itself then CSPM will be smart enough to know to create a packetd.conf file that only has signatures the sensor will know about (S15 sigs in this example), it will not place in sigs that the sensor does not know about (S16 and S17 sigs in this example).
- If the version field in CSPM for that sensor(let's say has S15) , however, is changed to match the latest version of sigs on CSPM (let's say S17), but the update was not loaded on the sensor (S17 not loaded on sensor) then you wind up in a weird situation. If you hit update and approve a new configuration for the sensor then CSPM will generate a packetd.conf file with the new signatures (S16 and S17) that the sensor does not actually know about. CSPM will warn you , but will let you push that configuration to the sensor. The sensor will IGNORE these new sigs (S16 and S17 sigs), and may even create errors in errors.packetd. The sensor will not monitor these new signatures unles it has had it's binaries upgraded to deal with the new signatures.
1) Install the CSPM updates on CSPM. ( Refer to CSPM signature update installation steps 1-6 of the readme)
2) Install the sensor updates on the sensors. (Refer to CSPM signature update installation step 7, which actually means to run all stpes for the sensor update installation or use the idsupdate automatic update utility)
3) Now sync CSPM up with your sensors so that the sensor version field in CSPM for each sensor matches what is actually on the sensors.
(You can do step 3 manually by going to each sensor in CSPM and selecting the correct version that matches what is actually installed on the sensor, or you can do CSPM signature update installation step 8)
This queries each sensor to find out what version is installed and then automatically changes the version field in CSPM for each sensor to match what is installed on each sensor.
optional 4) If you want you can then Update and approve each sensor. The new signatures are already on each sensor if you have independantly updated each sensor (which you should have done), but by approving ech sensor you are just ensuring that the sensor configuration is in sync with what you see in CSPM. You could have also made changes prior to updating and approving such as changing severities or filters for the new signatures.
So you see, CSPM does not actually update the sensor. It just pushes configuration files. It's your job to update the sensors (or use idsupdate to help do it automatically), and then sync CSPM with the updated sensors. Then CSPM can push out configurations that match what is loaded on the sensors.
Many people thought the CSPM actually pushed signature updates out to the sensors, but unfortunately it can not. But rest assured that this customer requirement has been documented as an enhancment to our IDS management products. I can't comment on whether or not it will be fulfilled in the next version since I don't work on the IDS management products team (I work on the IDS sensor product team).
Login to the FXOS chassis manager.
Direct your browser to https://hostname/, and log-in using the user-name and password.
Go to Help > About and check the current version:
Check the current version availa...
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...