IDS 4215 config questions

[kdamisch]

Customer currently has a PIX 501 with an IDS 4215 (and only using IEV). We are replacing the PIX 501 with an ASA 5510. They have a T1 coming into a Cisco router, then a hub which has the PIX and sensing interface of the IDS connected to it for monitoring the traffic outsdie the firewall. The inside of the PIX and the managment interface of the IDS are connected to some 3Com switches for the internal data network which has about 50 PCs and 6 servers. Has anyone ever enabled all signatures? If so, what is the performance hit by doing so? By default, Cisco makes a general config of certain signatures being enabled/disabled, and wasn't sure how much to go past it. Its a fairly basic network with an internal mail server, and the only inbound traffic are ports 25 for mail, 80 for outlook web access, and the ports for the Cisco VPN client.

The IDS is running the lastest 4.x software and latest signatures. We haven't upgraded to 5.x yet since they don't have the license for it yet. How does the signature updates work if you install the 5.x code without a license? Is it automated, or manual updates?

Thanks,

Kevin

[mkirbyii]

I have never enabled all sigs. You should be fine with the default enabled sigs. Your challenge will be assigning actions (reset, Block, etc). As for 5.x without a license you cannot apply updates. You can request a temp license which is good for 3 months. After that sig updates cannot be applied. I believe sig updates are manual.

M

[mhellman]

With version 5.x, I enabled all signatures. Never tried this on version 4.x. There are some significant differences between 4.x and 5.x though so YMMV. The most obvious being that many 5.x signatures are RETIRED. I don't have a real good understanding of why and what this means yet...but I do know it means that many of the signatures I intended to enable are not actually working. Also, The only way I could successfully enable all signatures was to first disable the sensing interface.

I hope your goal is to actually tune the sensors after this action though, as you'll be swamped with false positives.

I read on this forum that there is automated updates with the latest version of VMS. The 5.x sensors themselves can be configured to point to an autoupdate server. We have a couple test sensors that point to a test directory. Put the files in the test directory first and if all goes well...move into the prod directory. IMHO, this is only to be used for signatures updates. The autoupdate simply does not work correctly for patches.

[wsulym]

Lets see if I can help you with disabled vs. retired. When a signature is disabled, the signature regex is still cached and the signature still "fires" but the alert is silenced. So the signature is still there, it still takes up some memory, we just stop the alert from firing. When we take and retire a signature, we remove it from the regex cache - it's not there anymore. A retired signature doesn't take up any memory, and traffic is never inspected against it.

Why we might retire a signature ... One reason is going to be that the signature triggers on a vulnerability that's old and is of little to no practical use anymore. For example, sigID 2155 - Modem DoS, a series of 3 pluses (+) sent in an icmp packet ... little to no practical use anymore. Another reason is that we've rewritten the signature (in going from 4.x to 5.x code) to take advantage of newer and better engines. So for example sigID 2158 - Nachi Worm ICMP Echo Request. Looking at a 5.x sensor, you'll see that 2156-0 and 2158-0 carry the exact same. They are the same signature from a detection point of view, but 2156 was written in string-icmp and is now retired, replaced by 2158 written in atomic-ip. The description for 2158 states that as well. Most of the retired signatures fall into one of these two categories.

Don't go and unretire signatures just because you can, there's generally a good reason why it's retired.

Hope that helps.

[mhellman]

Thanks for the excellent explanation.

"Don't go and unretire signatures just because you can, there's generally a good reason why it's retired."

Any chance Cisco has document why they've chosen to

1) disable signatures

2) retire signatures

The real problem I have with both default disabled and retired signatures is that I can't provide a reasonable explanation to an auditor who asks me "why are these disabled?".

"Because the vendor said they should be" is not the answer most auditors are looking for.

[kdamisch]

What is the easiest way using IDS Device Manager to edit multiple (or all) signatures in a category such as viruses or spyware/adware to set the action for all of them at once.

For example, if I wanted to simply setup notifications on all attempts to use file sharing programs like eDonkey, Kazaa, etc, or if I wanted to reset connections whenever any virus traffic was detected, how would I change them at once instead of going into each one. I tried to edit multiple ones at once and it says I must do that at the category level. Well, I don't want to edit the whole Attack category, just the individual subcategories underneath Attack.

Thanks,

Kevin

[wsulym]

IDM -> Signature Definition -> Signature Configuration. Select something from the "Select By:" dropdown box then further refine the search with something from the dropdown box just to the right of the Select By box.You can select multiple signatures and enable/disable or change the actions for the selected.

So for example

Select By: Attack

Select Attack:General Viruses/Worms/Trojans

[kdamisch]

I'm using 4.x. I don't see the "Select By:" dropdown. Are you talking about 5.x?

[wsulym]

Yes, I was refering to 5.x. It's not quite that easy in 4.x, but you can come close. Configuration->Sensing Engine->Signature Configuration Mode->click on a top level category (ex. Attack)->click on the attack type (ex. Viruses/Worms/Trojans)->you'll need to change the rows per page to disaply more->select what you want by clicking on the check boxes ... all you can do is then enable/disable.

[wsulym]

No, there is no document out there that explains our rationale for disabled/retired at this time. That said, I'll try to provide some insight. Keep in mind that Cisco's the vendor and we have numerous end customers who use the IPS devices whose main business is not all the same.

Ok, so the signature set that ships enabled/disabled by default is what we feel is a suitable starting spot for the majority of end users across all industry. It's not a perfect fit for everyone everywhere, but it's a good place to start from. You still have to tune the sensor to your environment which is why you can enable/disable signatures, exclude ip address ranges, tweak signature settings etc. etc.

For instance, signature 3537-0 released in S193 - MailEnable HTTP Authorization Buffer Overflow. It's on a very popular port, exploits exist, it's easy and reliable to get remote code execution, and I think at the time the software vendor did not have a fix for it. All this adds up to a really bad vulnerability, *but* there's not much widespread use of the software package itself. We shipped that signature disabled by default. There's nothing to stop anyone from enabling it. If you ran the vulnerable version of software, it would make sense to enable it, however if you didn't, it's basically of no use to you.

We might also choose to disable a signature if there's a fairly good chance of false positives (lots of noise). For instance 5642-0 DirectShow Overflow. The 4.x version ships disabled, the 5.x version ships enabled by default. We chose to disable the 4.x version because there's a very good chance it'll false positive and can be overwhelmingly noisy (it still catches exactly what the 5.x version does, but since we don't have some of 5.x's nice features, it's not nearly as exact). *But* the tool is there if you want to use it.

There's not neccessarily a hard and fast answer to this, it's not an exact science and numerous factors weight in on the decision - I've touched on a couple. Think of it as a toolbox - not everyone needs the tools, but they're there if you do and the most common tools most people are going to use, we've put in easy reach.

As to the retired signatures, I think most if not all fall into the "old vulnerability" or "there's a replacement signature" category.