cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3162
Views
50
Helpful
81
Replies

ASK THE EXPERT- INTRUSION DETECTION SYSTEMS (IDS)

ciscomoderator
Community Manager
Community Manager

Welcome to the Cisco Networking Professionals Ask the Expert conversation. This is an opportunity to discuss Intrusion Detection Systems with Cisco expert Marco Caballero. Marco is a Quality Assurance Technical Lead at Cisco Systems, Inc. He specializes in the 4200 Appliances IDS Modules, Catalyst 6500 IDS Modules, and the Access Router IDS Modules. Marco joined Cisco Systems in 1998 as a result of the Wheelgroup acquisition. Feel free to post any questions relating to Intrusion Detection Systems. Remember to use the rating system to let Marco know if you’ve received an adequate response.

 

Marco 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 November 14. Visit this forum often to view responses to your questions and the questions of other community members.

 

81 Replies 81

Here is a link to more information about the parameters for 4.x signature engines:

http://www.cisco.com/univercd/cc/td/doc/product/iaabu/csids/csids10/idmiev/swappa.htm

The StorageKey is a represenation of how to group packets when analyzing that signature.

The StorageKey can have values of:

xxxx Axxx xxBx AxBx AaBb Axxb STREAM DOUBLE ZERO

The xxxx, Axxx, xxBx, AxBx, AaBb, and Axxb are referencing the different combination of Source Ip Address (A or x), Source Port (a or x), Destination Address (B or x), and Destination Port (b or x).

An x is used to say ignore that particular field.

The letter designation tells the sensor that the signature is combining packets based on that field. See the below examples.

So the xxxx is really saying to not do any storage. This is used primarily for atomic signature that fire on a single packet where no long term storage of information is needed. The sensor is not pulling information from multiple packets to fire the alarm. A good example would be the Echo Request signature 2004 in the Atomic.ICMP engine.

The Axxx is storing information based on the Source Address of the alarm. It is only used in the Atomic.Arp engine, Other engine (for some specialty sigs), and the Sweep.Host.ICMP.

A good example would be the NetSweep Echo signature 2100 in the Sweep.Host.ICMP. The sweep is coming from a single source address to multiple destination addresses.

The sensor pulls information from multiple ICMP packets where the Source Address is the same on the packets. There are no ports on an ICMP, and a sweep goes across multiple destinations so the sensor stores uniquely based on the Source Address.

The xxBx is used for alarms where the signature is looking for multiple packets to a single Destination Address. A good example would be the ICMP Smurf attack sig 2153 in the Flood.Host.ICMP engine. This is because the signature looks for echo requests from multiple machines coming to a single destination Address.

The AxBx is for signatures where packets on multiple ports are needing to be analyzed between 2 addresses.

The Sweep.Port.UDP engine signatures commonly use this Storage Key. This is because a single Source Address is scanning multiple ports on a single Destination Address.

The AaBb is primarily used for UDP based signatures. A UDP connection is made between 2 machines, and the signature is analyzing that UDP connection for an attack. Good examples would be the UDP signatures in the Service.DNS engine.

NOTE: For TCP connections, the STREAM is mainly used instead of AaBb.

AxxB is used for network sweeps across a single port. The signatures in the Sweep.Host.TCP engine are good examples. A single source address is sweeping across multiple destinations, but is doing so using a single destination port (like a port 80 sweep).

STREAM is a special form of AaBb. Not only is looking for a particular connection, but it also supports tracking of the TCP state. It will track that a valid TCP3WayHandShake was done, and that the TCP packets are being received in proper order.

The STREAM is one of the most used StorageKeys. It is used in all of the SERVICE and STATE engines where the signature is analyzing the contents of a TCP connection.

DOUBLE is a special form of AxBx (similar to how STREAM is a special form of AbBb).

DOUBLE adds additional TCP state tracking.

The Sweep.Port.Tcp engine signatures are good examples.

ZERO is kind of a default to say that no storage is needed. This has not been used. Instead xxxx should be used.

SIDE NOTE:

The Storage Key is what is used to determine how to group packets for analysis for a signature.

There is also a new Summary Key in 4.0. The Summary Key is used to designate how to group the alarms for summarization.

So a signature may be based on a STREAM so that a unique alarm will fire per TCP connection, but the Summary Key can then be Axxx so that if large numbers of alarms are seen, then the alarms can be summarized by Source Address of the alarms.

jodr
Level 1
Level 1

Access denied to IDS MC after upgrading to 4.1.2-s58 :

On Friday the 7th, I did the upgrade of four of our appliance IDS sensors. No problem. Afterwards I did the upgrade on the IDS MC and at the next logon, I did't have any access anymore to IDS MC and Security Monitor :

'You are not authorized to request the Action associated with screenID: "/s510"' or 'You are not authorized to request the Action associated with screenID: "/s550"' depending on the screen I want to access.

Now there seems to be an issue with authentication via ACS (TACACS+) in combination with fall-back to CS local authentication. However disabling fall-back or ACS doesn't solve the problem. Before this upgrade we didn't have this problem (of course).

We are talking to our supplier and a case has already been opened, but after a week, we don't have a solution yet.

This is really urgent, because we don't have any access to our events anymore.

The IDS MC still is generating reports and sending emails to us. So it's a pure access problem, I think.

Rather peculiar is that we can't change also the AAA server in the VMS (IDS MC) administration. It always wants to check with a TACACS+ server even if we configured the CS local authentication in the CS security setup.

marcabal
Cisco Employee
Cisco Employee

This is beyond my area of expertise. My area of expertise is on the sensors and modules which I test on a daily basis. I use VMS, but do not have enough VMS expertise to assist you with this problem.

I will contact the VMS team and ask for their help.

However, the Ask The Expert event ends today and they may not be able to directly apply to this email in time. (Once the event ends, users are prevented from adding additional postings).

I would recommend contacting the TAC and asking that your case be escallated. When calls are first made to the TAC they are handled by a first level of engineers. When the first level of engineers can't handle the situation then you can request that the case be escallated to a TAC team that specializes in the Security products. If that Security specialization TAC can't resolve the problem and it is a major issue like you are seeing, then you can request further escallation. The Security specialization TAC will then contact the product development team for their support.

david.d
Level 1
Level 1

Can you suggest a guideline for best practices on maintaining patches and service packs for the Event Viewer and CTR systems? I'm most concerned with IE and Service Packs. The only citation so far (not much time looking at this point) is in the IDS Event Viewer 4.1(1)S48 readme. This document indicates Windows 2000 with SP2 and I am about to install SP4.

Thanks

Talked with the CTR and IEV development teams.

Here are their responses:

As far as a CTR Server is concerned, the system should be kept up to date with all IE and Windows 2000 patches at all times.

As for IEV, the event viewer should work with the latest service packs. However, IEV has not been verified to work with each new patch and service pack as they are released. So IEV can not be guaranteed to work with each new patch. Should you choose to load the newest patches and find problems with IEV then contact the TAC and alert them to the issue. The TAC will file a DDTS which can then be prioritized for fixing in a future version.

If it were me I would backup the system (like with Norton Ghost) before upgrading the box. Update with the latest Service Pack or patches and try running the management tool.

If everything continued working fine, then great you are probably good to go.

(maybe even backup the system now with the latest patch)

If something stopped working, then gather as much detail as you can and contact the TAC.

If the tell you there is a problem with the patch then try uninstalling the patch and see if the problem resolved itself or even reload the backup image you made prior to installing the patch.

intertechusa
Level 1
Level 1

Hi Marco,

I am having a bit of trouble adding our 4235 IDS to the Management Center for IDS. When I try to add it, I wait a couple of minutes then it comes back with an error:

"This sensor is version 4.1(2)S60 which is not known to the system. Install a Signature update to the system and retry. "

I was told by TAC that this is an IDS configuration problem. My IDS right now is sending alarms to Threat Response.

At first I had an older signature on it and so I updated it to the above version. But I still get that error. I must be entering the correct info because it can detect what version it is running. (As it detectd the 4.1(1)S47 I had on it before). What could I be doing wrong? Could this be related to the ODBC test failure? I added the latest signature to MC also thinking that was the problem.

Also, is it a problem to have alarms sent to IDS MC and Threat Response? I sure hope not.

Thanks,

Darrick

I received another post very similar earlier today.

Here was my response:

http://forums.cisco.com/eforum/servlet/NetProf?page=netprof&CommCmd=MB%3Fcmd%3Dpass_through%26location%3Doutline%40%5E1%40%40.eea3f13/76#selected_message

With more than one customer reporting the problem, I am beginning to wonder if there may be a problem in the IDS MC update and will contact the IDS MC team to retest the update.

As for sending alarms to both Security Monitor (the alarm viewer in VMS, IDS MC is the corresponding configuration portion), and Threat Response: Yes this is fully supported.

You could choose to use IDS MC for configuration and monitor with both Security Monitor and Threat Response, or you could configure with IDS MC and only monitor with Threat Response.