Filtering out signatures based on src or dest port

[brecore]

I am trying to reduce the amount of false positives in our IDSv4. All of the documentation I have found says in order to filter out certain signatures, filter by source or destination address. I would like to take this a step further by filtering source address and source port for any given signature.

For example, I want to say ingore SigID=4003 SrcAdd=1.1.1.1 SrcPort=53.

I am not sure how to do this. Do you have to create a custom signature for this kind of filtering? Or is it even possible?

Thanks

[ishah]

Hi,

We have used Cisco Threat response policies to achieve what you want to do in addition to reducing false alarms in general.

You can specify source and destination ports. The way it works in the sensor or sensors alarm into threat response. This then downgrades based on a range of criteria, one of which is the policy and it should do what you want.

For general info on reducing false positives see my other post in this forum but here the link for threat response

http://www.cisco.com/en/US/partner/products/sw/secursw/ps5054/products_user_guide_chapter09186a0080175387.html#1036543

Incidently it is currently free and just requires a win2k box with fast processor.

You can then use snmmp to drop the key alarms into enterprise management.

[jimmieharden]

Does this url require partner-level access?

[jimmieharden]

This is what we came up with.

set vlan 50 rspan

set security acl ip IDS deny udp host 1.1.1.1 eq 53 host 2.2.2.2

set security acl ip IDS permit ip any any

commit security acl IDS

set security acl map IDS 50

set rspan source 8/1 50 both multicast enable create

set rspan destination 8/2 50 inpkts enable learning enable create

8/1 is internet traffic. It is mirrored to vlan 50 were the VACL is applied. Normal traffic is not effected. 8/2 is the IDS monitor port. These commands are within the same switch. RSPAN has a source session limit of 1. This is my problem. I need 2 source sessions at my core. See rspan documentation.

[jimmieharden]

I just learned you can also filter at the application level. This is an answer from my post "IDS 4 exclusion mechanism to reduce false positives". It is not as granular as the VACL but is very good.

marcabal

Oct 13, 2003, 4:49pm PST

A very similar filter mechanism is available in 4.x.

You can refer to the following link on how to do this in IDM:

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

[ishah]

Hi,

Sorry the link for Threat Response without a CCO account is

http://www.cisco.com/en/US/products/sw/secursw/ps5054/products_user_guide_chapter09186a0080175387.html

This will work for both 3.X and 4.X sensors.

[jimmieharden]

Here is a variant of the my RSPAN solution from MikeH at Cisco using only VACLs.

set security acl ip IDS permit udp host 1.1.1.1 eq 53 host 2.2.2.2

set security acl ip IDS permit ip any any capture

commit security acl IDS

set security acl map IDS 50

set security acl capture-ports 8/2

Notice the traffic you want to notch out has a permit without the capture bit set. This traffic will fall out of the ACL before the next line ip any any with the capture bit set. 8/2 is the IDS monitor port. This solves my problem mentioned above.

Thanks Mike!

[darin.marais]

I am not convinced that added ACL to the switch is the real solution. You should be able to do this at the sensor.

It is not right that you should have two manage to areas to detect security alerts.

Most large cooperates have very strict change control programs regarding the switches. You can’t be adding a new line to an ACL every time you would like to filter a source or destination port for a particular signature on your nids

[klwiley]

Unfortunately we do not allow filtering by port. This is as reasonable request for a feature and we will add it to or enhancement list. Thank you for your input.