cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
302
Views
0
Helpful
4
Replies

IDS4x

corpsec
Level 1
Level 1

On Snort we could specify inbound and outbound traffic. Can we do the same on Cisco sensor? Is there a way to tell it to watch certain traffic only.

Thanks,

Simone.

4 Replies 4

marcabal
Cisco Employee
Cisco Employee

Yes and No,

You can't tell the sensor to only analyze one direction of traffic, BUT you can tell it NOT to alarm for traffic you don't care about.

The sensor is always going to analyze all of the traffic. The only way to prevent this would be to filter the packets out before they were even sent to the sensor. If we could tell the sensor not to analyze traffic going a particular direction then we might be able to save some performance on the sensor. The problem is that in many cases the traffic going out of the network is often analyzed looking for attacks coming into the network. So you can't just ignore the internal traffic because you need to analyze it even if you are only looking for attacks from the outside.

But you can fitler the alerts so you wind up only seeing the ones you are interested in.

Internally the sensor will generate what I will call a pre-alert. This pre-alert then goes through a set of filters that the user specifies. If the pre-alert gets filtered out by the user's filters then the alert never gets created and it is never seen by the user. If the pre-alert does not get filtered out, then it becomes and alert and the user will see it on their management station.

To do what you are asking you can place all of your internal network addresses into the "IN" variable.

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

This marks these addresses as being inside your network.

NOTE: Other variables in this same window can also be used to define other subsets of ip addresses.

Once you've designated the IN variable for your internal networks now you can use it to create filters:

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

You can create a filter with the wildcard "*" set for the SigId, SubSigID, and DestAddrs, and use $IN as the SrcAddrs. This will prevent the sensor from generating alerts where the attack originated inside your network.

By the same token you can also do filters for specific sets of signatures. You can also create filters for specific addresses instead of using a variable.

So the filters is what you are interested in learning how to use, and using the variables in the filters.

NOTE: When using a variable in the filter place a dollar sign in front of it: $IN

NOTE: When

How do I filter from {ANY source to Dest X} and from {Source Y to ANY destination} for the same signature?

I tried two filters with the same SigId and the appropriate src/dest pairs but it seems that only the first filter is matched upon and events that should be filtered out by the second are still appearing.

Is this even possible?

Yes this is possible, and should be working.

You should be able to have multiple filters for the same signature or set of signatures.

Do me a favor and check your configuration. There is a specific field in the filters that has caused some confusion. This field is "Exception". If "Exception" is set to False then the filter line would attempt to prevent those alarms from being created.

BUT if the "Exception" field is selected or set to True, then this line instead of preventing the alarm will actual force the creation of an alarm. You can consider it an override. It overrides any other filter (regardless of whether the filter appears before or after this one) where the "Exception" was set to False. The "Exception" True instead of filtering the alarm, will actually prevent the alarm from being filtered.

So is your filter line has the "Exception" set to True then your filter is telling the sensor to fire the alarm, and the simple fix is to change it to False.

------------

If Exception is set to False in all of your filter lines, then there is still a possibility that your filters are not properly matching the alarm being generated.

You can post a copy of your filter lines (from a "show conf" output) as well as a copy of the alarm still being generated (from a "show events" output).

And I can take a quick look for any errors and can try it in our lab.

If you don't want to post that information on the forum, then you can also contact the TAC and provide them the information. They can do the same checks I would do.

My bad. I had already removed the filter that didn't work the first time so I'm not sure where I went wrong but when I recreated it (and others) they worked just as you mentioned. Thanks for pointing me in the right direction!

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: