ASK THE EXPERT – INTRUSION PREVENTION SYSTEMS

[ciscomoderator]

Welcome to the Cisco Networking Professionals Ask the Expert conversation. This is an opportunity to discuss with Cisco expert Charlie Stokes about Intrusion Prevention Systems. Charlie works as an Intrusion Prevention Systems (IPS) technical marketing engineer and has been a network security specialist for over eight years. Charlie came to Cisco as part of the Wheelgroup acquisition in 1998 that brought Intrusion Detection Systems (IDS) technology into Cisco. After the acquisition, he worked in the Technical Assistance Center (TAC) for two years covering the Security and VPN products. Since 2000, Charlie has been covering IDS/IPS products as the lead technical marketing engineer.

Remember to use the rating system to let Charlie know if you have received an adequate response.

Charlie might not be able to answer each question due to the volume expected during this event. Our moderators will post many of the unanswered questions in other discussion forums shortly after the event. This event lasts through February 10, 2006. Visit this forum often to view responses to your questions and the questions of other community members.

[vxnguyen]

Charlie, this is the heart of my issue. We work in a government classified area that requires we lock all hard disks (that contains classified data) in a safe at night. Unfortunately, this includes Compact Flash drives on IPS 4255 & PIX 525 devices. These drives contains contents of packets that are considered classified (and not just packet header data). My questions are the following:

1) How do I scrub the compact flash drives completely? I know you can remove or erase the image on the IPS. Does this really scrub all residual data? How do we confirm that the data is in fact removed?

2. How can we prevent packet contents (excluding packet headers) from storing on the compact flash drives in the first place? Is there a way to direct all ip logs, event stores, and alerts to another system such as a syslog server or a CiscoWorks box?

3. Finally, is it feasible to physically remove the Compact Flash Drives from the IPS 4255 and the Pix 525 devices and place it in a safe? Would this break the warranty? This solution would allow us to just simply put the compact flash into a safe.

[cstokes]

I don't understand this at all. You lock up hard drives? On network security devices? You do understand these devices need to run at all times?

1) I am not an expert on persistence of data on magnetic media nor would Cisco ever make any statements regarding such a matter.

2) By config, you can never produce a verbose alert or an IP log (log Attacker/etc). This doesn't solve the whole problem though as the IPS does record what is called context data for all alarms that have it (TCP stream based sigs). This context data is the contents of the tcp datagram up to the point the sig fired. There is no way to prevent that.

3) No, it is not really feasible. It requires powering down, unracking, and opening the box in an ESD supported area (Multiple screws to remove the top cover). Then removing the compact flash device from it's interior bracket. Then reverse the procedure in the morning.

I do not really understand this requirement as wouldn't it be simpler to just have physical protection around the area where you have the network "SECURITY" gear deployed versus tearing down the gear each night and rebuilding it in the morning? Does the gear not need to run at night? Is the rest of the network powered off as well?

[darin.marais]

Hi Charlie, when sniffing vlans with an nids sensor, it is possible to receive duplicate instances of the same packet since the vlan may include both the ingress and egress ports and both are copied to the span port.

My question is; will this circumstance cause signatures such as fragment overwrite, fragment overlay etc, to trigger a false positive event?

[cstokes]

Yes. Duplicate packets can be seen.

There should be no such events as the packets should be exactly the same, and the sensor will treat them as duplicate packets in the same flow and discard them. Only when data in the packet changes would the sensor trigger some type of event.

[ovt]

Hi Charlie,

Could you please explain the following note from

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

Yesterday I didn't follow this procedure and upgraded my sensor directly from 4.1(4)S91 to 5.0(1)S149 (Major update) and then to 5.0(5) Service Pack.

Will this create any problems? How can I verify that everything is ok with the sensor?

IMPORTANT NOTE: If you are upgrading from IDS version 4.X to IPS version 5.0(4) or later you must follow this upgrade path:

1. Install the 5.0(1) major upgrade,

2. Install the S207 or later signature update*,

3. Install the 5.0(4), 5.0(5) or 5.1(1) update.

*If you do not install the S207 or later signature before upgrading to 5.0(4) or later, the sensor may not operate correctly. Please refer the the INSTALLATION and INSTALLATION CAVEATS sections of the 5.0(1), 5.0(5), and 5.1(1) readme files for more detailed information.

[mhellman]

Where are you seeing this documented? It isn't in the 5.0(5) readme, and it certainly should be if it's true.

[m-hansson]

Hi mhellman

It's stated at the following page:

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

/Mattias

[mhellman]

Interesting. It doesn't effect me becase I had to rebuild all mine from 5.x code thanks to the buggy 5.1 upgrade. sigh...but i digress.

I see what they've done. They've only bothered to update the 5.0.1 upgrade readme. smooth. Good luck with that. Hopefully the worse-case scenario is you have to revert to 5.0.1, apply the sig patch, and reapply 5.0.5.

[marcabal]

The problem only started with S206 and higher.

So if you were between 4.1(4)S91 through 4.1(4)S204 you would not run into this issue.

So if you upgraded from 4.1(4)S91 to 5.0(1)S149 to 5.0(5)S149 you are OK.

The issue began with S205 because S205 corresponded with the 5.1(1) release and corresponding changes to all 5.0 versions so that all 5.0 and 5.1 versions could be sync'd to the same set of signature definitions.

The typedefs file that explains what parameters are available per engine was updated in S205, and all 5.0 versions had to be modified to understand and load the new typedefs file to understand the new sets of parameters available to each engine.

The simple test to see if everything is OK is to just generate some simple signatures.

If the sensor is generating alerts then you are most likely OK.

If the sensor is NOT generating alerts, then look through the error events on the sensor. If you see some errors about not recognizing typedefs and not loading engines and signatures, then you are likely hitting this issue. The sensor is not recognizing the new typedefs and so won't load the signatures for those engines where parameters changed.

And this problem is only seen with the 4.1 to 5.0 upgrades. Starting with a 5.0 installed from a System image or from CD won't cause this issue.

[ovt]

Excellent explaination! Just to make sure, if I reimage my 4215 with IPS-4215-K9-sys-1.1-a-5.0-2.img (the only image file available on CCO) this will install SP2, so I should probably install SP5 next and then latest Sig update, right? Are there any caveats in doing this?

Also, so far as I understood, starting with S205 Sig updates contain new signature parameters which are ignored by 5.0 sensors if they are set in CLI/GUI. Could you please provide me a list (or point me to a document) of such parameters?

Thank you!

[marcabal]

You are correct that you can go from 5.0(2) to 5.0(5) to the latest sig and should have no problem.

As for what parameters are seen in S205 and later on a 5.0 sensor that are only used with a 5.1 sensor.

Engine Multi-String (This is a new engine for 5.1)

Adress Filters in Sweep Engines: specify-src-addr-filter and specifiy-dst-addr-filter (These were new parameters to an exsiting engine so customers can limit sweeps to look only at specific addresses. The feature was added in 5.1)

SSH Version in the SSH Engine (This is a new parameter expanding on the SSH engine so it could monitor SSH V2 connections. New for 5.1, but may also have been supported in one of the 5.0 Service Packs)

Deny-attacker-service-pair-inline, deny-attacker-victim-pair, and request-rate-limit event action options (New options for the event-action parameter that are new for 5.1)

[NAVIN PARWAL]

Charlie,

Can you please give me a small real world example so that i can understand how the rating system works in an IPS, i know it uses three variables to calculate the final number, but i am always confussed about how it does it, is there a formula it uses?

Thanks

[cstokes]

http://www.cisco.com/en/US/products/hw/vpndevc/ps4077/products_white_paper0900aecd80191021.shtml

This whitepaper on CCO should help explain Risk Rating.

[ovt]

Hi,

Are there any plans to enhance protection against password guessing attacks on IPS 5.x sensors? I see the following problems with "service authentication" "attemptLimit" parameter:

- even administrator account can be disabled if an attacker makes more attempts than specified with this parameter;

- even console access is blocked for this account. This creates possibility for DoS attacks to the sensor itself;

- statistics in "show statistics authentication" is incorrect (always 0);

- administrator is able to see warnings in "show events status" output, but this is inconvinient -- there are hundreds of messages there.

[NAVIN PARWAL]

I am totally confussed about how the IPS decides what to do with the packet once it sees it. what is the default behavior?

1) If the sevrinity level is over 90 will it drop the packet? what is the default for the IPS to drop the packet.

what other factors influence its decision to drop the packet. any simplified explanation would be highly appreciated.

Thanks