cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
793
Views
0
Helpful
13
Replies

Error Upgrading IDS 4.1 to IPS 5.0

tscislaw_2
Level 1
Level 1

Getting the following error when attempting to upgrade IDS 4.1 to IPS 5.0:

"Exception Error: Error -- Attempt to select Item, "string-tcp" failed [Item::unionItem]"

This is on an IDS-4210, sig version 4.1(5)S236

Approx 13GB free disk space.

13 Replies 13

ibanezm
Level 1
Level 1

you're running into CSCse60383.

Symptom:

First attempt to upgrade from 4.1(5) to 5.0(1b) failes due to a configuration issue. When the configuration is fixed, subsequent upgrade attempts will fail with the message "union does not have member".

Conditions:

Attempt to upgrade from 4.1(5) to 5.0(1b) fails due to configuration error, subesquent attempts to upgrade fail due to the union does not have member error.

Workaround:

Apply the next signature update to the 4.1(5) sensor and then do the 5.0(1b) upgrade OR downgrade and then reapply the current signature update and then do the 5.0(1b) upgrade.

Further Problem Description:

When the first upgrade attempt fails, the file 50Sig.tar.gz is removed from the var/updates/50sig directory, which causes the next upgrade attempt to fail. Installing a new sig update or downgrade/update restores the 50Sig.tar.gz file which allows the update to work

You need to apply the workaround.

No joy.

Tried downgrading the sig file and applying the IPS upgrade but got the same error.

Installed a newer sig file and tried again but got the same error.

Did this routine a couple of times with the same result.

Thanks.

Try this, reset all sigs to default settings then apply a sigupdate, then install 5.0(1). That should work.

An inherent bug with the converter going from 4x to 5.0 will be fixed in 4.1(6)

4.1(6)?????? When is THAT comming out?

4.x has about 6-7 weeks of usefull life left in it, why wait untill most customers have moved to 5.x to release a working signature convertsion feature.

We've gone thru hell hand tuning over a thousand 5.x signatures because there was no good converter or migration tool for converting 4.x tunings to 5.x (nor is there ANY tool for moving signature tuning at the group level between VMS Servers).

I need to correct myself. The fix will not be in 4.1(6). I am not sure at this time if and when it will be fixed. The workaround is to reset all sigs back to default, install a sigupdate, then the 5.0 upgrade should complete.

Reset all the signatures to default? Do you mean if we have certain signatures set to shun a host we need to reset it?

I've got thousands of signatures set to block malicious traffic. Resetting them would open us up to attack and take days to finish.

I appreciate your help, but I can't do this one. Maybe I'm misunderstanding what you're suggesting.

Thanks.

Yes, the workaround is to reset all sigs to default, then install a sigupdate, upgrade to 5.0. I realize the hassle of re-tuning the sigs once you're at 5.0 back to what they were in 4.x, but at this time, this is the only workaround.

Let me interject something into this discussion.

The majority of 4.x configurations WILL convert properly during an upgrade to 5.0(1) if using the latest 5.0(1c) upgrade file:

IPS-K9-maj-5.0-1c-S149.rpm.pkg

Do not use the original 5.0(1), 5.0(1a), or 5.0(1b) upgrade files.

The differences between the a,b, and c files are primarily fixes in the upgrade script on what gets brought over and converted from a 4.1 sensor into the new 5.0 sensor.

So you must use 5.0(1c) to ensure you are getting those latest fixes.

http://www.cisco.com/cgi-bin/tablebuild.pl/ips5

IF you are using IPS MC or CSM for managing the sensors then there is a corresponding 5.0(1) upgrade that corresponds with 5.0(1c). The IPS MC and CSM can not handle the "c" dsignator so the new files wind up named exactly the same as the original 5.0(1) upgrade file. So you will just need to make sure you grab the Latest 5.0(1) upgrade file for the IPS MC and CSM and replace any older 5.0(1) upgrade file you have previously downloaded.

http://www.cisco.com/cgi-bin/tablebuild.pl/ipsmc5sp

Just so you are aware 5.0(1b) had a bug. If the converter failed for some reason, then it stopped the upgrade but also unintentionally removed a file off the sensor. This file being removed prevented any second upgrade attempt from working. To correct the problem a New signature update Must be applied to the 4.1 sensor prior to attempting the update again.

The change made in 5.0(1c) will prevent the problem from happening. BUT if the sensor had already experienced an upgrade failure with 5.0(1b) you still need to apply a signature update to 4.1 before attempting the upgrade with 5.0(1c).

BUT BE AWARE THAT 5.0(1c) WILL NOT SOLVE "ALL" OF YOUR UPGRADE ISSUES.

There are some signature tunings that the converter is unable to convert to the new 5.0 style.

In many cases this is because the tuning will not be valid in a 5.0 sensor. The most common situation is using a TCP Reset action on UDP or ICMP signatures (non-TCP). 5.0 does not allow the action so it must be removed from those signatures in 4.1 before the configuration will convert properly.

The TCP Reset action may also have been added to flood or sweep signatures in 4.1. They are not valid in 5.0 and need to be removed.

NOTE: These are not converter bugs. Instead the converter is doing what it is supposed to. It was designed to prevent invalid configs from being applied to the 5.0 sensor.

Another common situation is where the valid range of setting has changed between 4.1 and 5.0. Version 4.1 would allow a "0" for some fields where 5.0 requires a minimum value of "1". Or 4.1 would allow a larger number than what 5.0 will allow. For these situations the value must be changed to within the range that 5.0 will accept as valid. The easiest thing to do is to set the value back to the original default in 4.1; then convert to 5.0, and then re-tune that value.

NOTE: These are not converter bugs. Instead the converter is doing what it is supposed to. It was designed to prevent invalid configs from being applied to the 5.0 sensor.

Please do not automatically assume that the converter will fail for your sensor config, and please do not automatically assume that you have reset all of your tunings back to default in order to get the converter to work.

Here is the steps I would recommend:

1) First be sure you are using 5.0(1c) for the upgrade.

2) If it fails the upgrade, then try applying a signature update, and then appying 5.0(1c) again. You may have run into the 5.0(1b) bug.

3) If it fails again, then you will need to modify your 4.1 config. First place to start is evaluating your use of the TCP reset event action.

Ensure it is only on TCP signatures. When in doubt remove it from the 4.1 config (you can try to add it back after the 5.0 upgrade).

4) If it fails still, then next is to look at any tunings with numbers. Try setting the number back to the default. Then try to tune it back again after the conversion to 5.0.

5. If it still fails then look closely at the errors returned from the converter. They may give you a clue as to which signature tunings is causing the converter problem.

6. If it continues to fail, then each tuning will need to be independantly analyzed to determine which is the problem.

Sometimes the errors from the converter are not easy to decipher. If you have been through steps 1 through 5 and still have problems, then it is time to contact the TAC. There have been rare cases where the converter is properly detecting a 4.1 configuration that can not be applied to a 5.0 sensor, But the converter's error messages are not clear enough for a user to determine what the problem is. In these situations a developer is often needed to diagnose the problem and determine what tuning is causing the issue.

Only in worst case scenarios should a reset of all signature configuration be necessary in order to upgrade to 5.0.

============================================

Also be aware that the 5.1(1) file has also been updated several times. So when trying to upgrade from 5.0(1) you should use 5.1(1g):

http://www.cisco.com/cgi-bin/tablebuild.pl/ips5

Or if using VMS or CSM then use the newest 5.1(1) upgrade file for VMS/CSM that corresponds to 5.1(1g):

http://www.cisco.com/cgi-bin/tablebuild.pl/mgmt-ctr-ips-51updates

I've verified that I'm using the 5.0(1c) file in the upgrade and I've tried upgrading/downgrading the sigs several times.

We're not using TCP Reset at all that I'm aware of. Way back when we first implemented the IDS were were told that since we were using a PIX we could only use Shun Host.

I'll check to see if any sig has accidentally been set to TCP Reset.

I've opened a case w/TAC but it got lost and only today did it get assigned an engineer.

Thanks.

I had the same problems with a couple of my sensors. I created a TAC case but I could tell they didn't know what was causing it. So, I opted to reimage my sensors to version 4.1 S47 and start over from scratch. I hated to do it but I tried everything I knew, which I consider to be quite a bit after working with Cisco IDS before it was Cisco. At any rate, I am fed up to the point of moving to a new vendor for IPS technology. I really hate to do it because I like Cisco and all but the empty promises of features, so many sigs with false positives, it just an admin nightmare anymore and takes way too much time for something that should be so much better given the time Cisco has contributed to it. I completely understand the complexity of developing such code, but at the same time I see others having quite a bit more success with much less effort.

Just my 2 cents after being frustrated with losing everything from a signature tuning and filter standpoint

ntrngrusr, I'm as frustrated as you.

We just got informed that Cisco will no longer support new signatures on the 4.1 version so we're forced to upgrade, yet they know of problems with the upgrade. Support ends in September and here it is August and they still don't have a fix.

Plus, we're using the IDS-4510 and I hear that it's in "end of life" and won't be supported after '07, I believe.

I've budgeted for a new one and, after this fiasco, I'm going to use that money to go with a different vendor. I'm tired of the hassle.

tscislaw_2
Level 1
Level 1

The upgrade finally worked. I had opened a ticket with TAC and they had me send them the output to "sh tech" and a copy of two files: virtualAlarm.xml and virtualSensod.xml.

They identified 11 signatures that they said needed to be set back to the default settings.

I did that and the upgrade completed successfully.

Thanks for everyone's help.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: