IPS Automatic update

Answered Question
Mar 10th, 2009

I configured Automatic update from Cisco.com on the IPS-SSM-20 and I have a question about how updates work. Updates are related to the Engine and the Signature only, is that correct ?

In case that a new signature is posted on Cisco.com does the automatic update does the signature update only ?

what about SW Engine in this case is just skipped ...

Correct Answer by marcabal about 7 years 11 months ago


Correct, only Signature Updates and Engine Updates will be automatically downloaded from cisco.com.

This is because both types of updates can be applied to running sensors without a reboot.

If an Inline sensor is configured for ByPass Auto, then the traffic will continue to flow through the sensor unmonitored while the update is taking place.


Major Updates, Minor Updates, Service Packs, and Patches are NOT automatically updated from cisco.com.

These updates require a reboot for installation andwill cause traffic to stop for a short period when applied. They should be applied during scheduled network down times.

(NOTE: You can set up your own ftp/scp server. Manually download these updates, and palce them on your server. Then configure your sensors to check your own ftp/scp server for these types of updates. Both cisco.com automatic updates, and automatic updates from your own server can be configured on the same sensor.)


Engine updates are only released a few times a year, while signature updates are released several times a month (even several times a week, or even several a day on occasion).


The sensor connects to cisco.com and queries the server for the names of the latest Engine and Signature updates.

It then checks to see if these updates are newer than what is currently on the sensor.


If there is a newer Engine Update (higher E level), then it downloads and installs the new Engine Update.


If the Engine Update on cisco.com is the same E level as what is already on the sensor, then it checks the S level of the latest Signature Update.


If the S level of the newest Signature Update is higher than what is on the sensor, then downloads and installs the new Signature Update.


If the E level and S level on the sensor are the same as the newest Engine Update and Signature Update, then the sensor is up to date. No files are downloaded, and the sensor just waits till the next scheduled auto update time to repeat the process.


  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
Correct Answer
marcabal Tue, 03/10/2009 - 06:54


Correct, only Signature Updates and Engine Updates will be automatically downloaded from cisco.com.

This is because both types of updates can be applied to running sensors without a reboot.

If an Inline sensor is configured for ByPass Auto, then the traffic will continue to flow through the sensor unmonitored while the update is taking place.


Major Updates, Minor Updates, Service Packs, and Patches are NOT automatically updated from cisco.com.

These updates require a reboot for installation andwill cause traffic to stop for a short period when applied. They should be applied during scheduled network down times.

(NOTE: You can set up your own ftp/scp server. Manually download these updates, and palce them on your server. Then configure your sensors to check your own ftp/scp server for these types of updates. Both cisco.com automatic updates, and automatic updates from your own server can be configured on the same sensor.)


Engine updates are only released a few times a year, while signature updates are released several times a month (even several times a week, or even several a day on occasion).


The sensor connects to cisco.com and queries the server for the names of the latest Engine and Signature updates.

It then checks to see if these updates are newer than what is currently on the sensor.


If there is a newer Engine Update (higher E level), then it downloads and installs the new Engine Update.


If the Engine Update on cisco.com is the same E level as what is already on the sensor, then it checks the S level of the latest Signature Update.


If the S level of the newest Signature Update is higher than what is on the sensor, then downloads and installs the new Signature Update.


If the E level and S level on the sensor are the same as the newest Engine Update and Signature Update, then the sensor is up to date. No files are downloaded, and the sensor just waits till the next scheduled auto update time to repeat the process.


helenio Wed, 03/11/2009 - 05:54

Thank you for the reply .. another doubt. Let assume that an S update is load on the IPS. In case of new signature, are new Signatures enabled by default ?

It can happend that some signatures enabled by the customer will be disabled after the S update ? In case of disabled S in ca be that the update will enable them ?

marcabal Wed, 03/11/2009 - 07:41

To answer this it is best if I give you a brief explanation of the internal workings of the sensor.


If you execute "show conf" on the sensor you will see multiple sections of configuration.

Each section starts with "service " or "service " and ends with an "exit" command.


The configuration is not stored on the sensor as a single file.

Instead each of these sections of "show conf" is actually a representation of an XML configuration file stored on the sensor. These XML files are the real configuration of the sensor.


The "service " and "service " are slightly different in how the configuration files are saved.


Let's first look at the "service host" section of the configuration.

If you were to log in through a service account and switch to the /usr/cids/idsRoot/etc/config directory of the sensor you would see a "host" directory.

Within that "host" directory you would several files.

The "typedefs.xml" file is a listing of all of the parameters that can be used in the host configuration, as well as what the limits are.

The "default.xml" file is a listing of any default values for any of the parameters in the "typedefs.xml" file.

The "typedefs.sig.xml" and the "default.sig.xml" are just digital signatures for the other files so the sensor can verify they have not been altered.


The "current.xml" file is where your modifications to the "service host" configuration are store3d. So your sensors IP, default gateway, etc.. are stored in this file.


When you execute "show conf" the CLI will read in this XML file, and dynamically generates CLI commands from the XML.



The "service signature-definition sig0" follows a slightly different method used for the "service " portions of the configuration.


If you went into the service account and switched to the /usr/cids/idsRoot/etc/config/signatureDefinition directory you would see a typedefs.xml, default.xml, typedefs.sig.xml, and default.sig.xml file similar to that used for the host configuraion.

BUT you would not see a current.xml file, and would instead see a instances directory.


Inside this the instances directory is the "sig0.xml" that is for the "service signature-definition sig0" portion of your configuration. If you had created a "sig1" then there would also be a "sig1.xml" file in the instances directory.


This "sig0.xml" is where all of your signature modifications are stored.



So what happens to these files when a Signature Update is installed?

The Signature Update will change the "default.xml" and "default.sig.xml" for the signature-definition section.


It will add new signatuers into that default.xml file, and will modify existing signatures in that default.xml file.


The Signature Update will NOT change the "sig0.xml" instance file.

So any tunings you have made that are seen in the "show conf" will stay the same and NOT be changed by the Signature Update.


So the Signature Update will change the default values for the signatures, but will not change anything that you have specifically set in the configuration.




marcabal Wed, 03/11/2009 - 07:41

Now lets look at some of your other questions:

Will "new" Signatures be enabled by default?

This is a determination made the signature team on a per signature basis.

MOST new signatures will be enabled (and unretired) by default.

However, there will be occasions when the signature will release a new signature that is Disabled by default (and possibly even retired).

This can happen if the signature team released a new signature for an old vulnerability that only affects a small number of customers running an old operating system inside their network.

It could also be that the signature detects normal traffic rather than attack traffic (like a signature P2P traffic). Only customers who to prevent that type of traffic would enable the signature, so it is disabled by default.


What happens if a customer enables a signature that Cisco disables in a later Signature Update.

If the change shows up in "show conf", then even though Cisco might change the default to disable it is the user setting of enable that will be used.

HOWEVER, understand that there are 2 parameters that are actually used to turn the sig ON. The signature must both be Enabled and UNRetired for it to be ON. So if in your "show conf" you have it as Enabled, if the next Signature Update both Disables and Retires the signature then the signature will be a Enabled but Retired state and will be internally turned OFF. So be sure to set the signature to both Enabled AND Unretired if you don't want future Signature Updates to turn it OFF.


NOTE: Engine Updates, Major Updates, Minor Updates, and Service Packs also contain Signature Updates within them. They generally operate the same as the Signature Update and do not change the "sig0.xml" of signature-definitions and "current.xml" of the other service configurations. So your tunings are kept in place during the upgrade.

HOWEVER, there are situations where the updates sometimes DO have to Convert the sig0.xml and current.xml files to work with the new version. On occasion a parameter has to be inside the configuration or the parameter name is changed. In these cases the upgrade script will automatically convert your old configuration to work with the new configuration. The conversion will attempt to keep all of your previous configuration, and only in very rare cases would something from your old configuration be removed.

NOTE: It is always best to save your sensor configuration before doing these types of upgrades.



Actions

This Discussion