cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
507
Views
0
Helpful
3
Replies

Putting IDS-4245 into production

bberry
Level 1
Level 1

I have a new 4215 that has been in "monitoring" mode for a while. It is monitoring the inside and outside interfaces of my PIX and I am detecting a lot of TCP SYN Host sweep from my proxy server and a bit of limewire. In regards to the TCP SYN Sweep I figure there is still more configuration that I need to do. What am I still missing? I have not told the ISD what any of my internal networks are. Is that needed?

In regards to the Limewire stuff. Can I block that?

3 Replies 3

mhellman
Level 7
Level 7

Defining "internal networks" (as event variables) does not do much by itself. If your goal is to prevent a certain false positive (like the TCP SYN Host Sweeps from a proxy), then you must create an event action filter.

proxy servers will naturally trigger false positives on a few of the sweep signatures. You might consider creating a HTTP_PROXY event variable and then creating an event action filter that subtracts the 'product alert' action for those sigs. You're likely to add other sigs over time as well.

I find that defining event variables for my networks has two primary benefits:

1) we have too many DMZ segments to memorize and it describes them nicely in the alarm (whether I use the variable in a filter or not)

2) filters are much easier to understand when using variables. plus, you don't have to modify multiple rules if something changes. You just modify the event variable.

re: limewire, don't know about that one. I would verify that it is truly limewire being detected (turn on the "log pair packets" action for that sig). If it is, and your policy is to not allow limewire, then go ahead and block it.

So is the event action filter is applied to the event that is causing the false positive?

*reading through chapter 7 of Installing and Using Cisco IPS *

It's more correct to say that event action filters are applied to signatures.

Each and every signature on your sensor can have zero or more actions associated with it. The available actions are:

Deny Attacker Inline

Deny Attacker Service Pair Inline

Deny Attacker Victim Pair Inline

Deny Connection Inline

Deny Packet Inline

Log Attacker Packet

Log Pair Packets

Log Victim Packets

Modify Packet Inline

Produce Alert

Produce Verbose Alert

Request Block Connection

Request Block Host

Request Rate Limit

Request SNMP Trap

Reset TCP Connection

The most common default action is "produce alert".

Event action filters are used to subtract actions from one or more signatures, based on the criteria entered in the filter (attacker address, attacker port, etc). I would say the most typical use for an event action filter is to prevent an alarm from firing for certain, specific hosts.

Review Cisco Networking for a $25 gift card