Default behavior of IPS

[NAVIN PARWAL]

Folks,

I have a 4250 series IPS box that i have recently configured, I have a few questions, i would highly appreciate if some one could assit me.

1) What is the default behavior of the IPS for critical alerts or signatures. Meaning if it sees a signature that is defined as critical, what is the default behaviour (out of the box), would it shun it, block it or log it.

2) Also, please correct me if i am wrong, the IPS unit is capable of doing either of the 3.

a) Shun (Tcp reset)

b) Blocking

c) Logging

My question is that can an IPS unit achieve Blocking on its own or does it still need a router or pix firewall to achieve this.

Thanks, I will make sure i post this thread.

[travis-dennis_2]

1) If memory serves the default behavior for critical events is "log". You have to tell it when to take any action above and beyond that.

2) IPS is capable of doing all 3

3) The 4250 can be an inline device and shun, drop, reset, log, etc. on its own but only if you have the 4FE (4 port) interface. It can also control a PIX or IOS router to do the same.

Take a look here

http://www.cisco.com/en/US/products/sw/secursw/ps2113/products_configuration_guide_chapter09186a0080459225.html

and here

http://www.cisco.com/en/US/products/hw/vpndevc/ps4077/products_data_sheet0900aecd801e6a45.html

Hope this helps.

Please remember to rate all replies

Travis

[marcabal]

Depends on whether you are running version 4.1 or 5.0.

A quick comment before we begin.

In version 4.1 the Logging action is often mistaken as the creation of an alert. This is incorrect. The Logging action is actually the logging of additional packets After the alert has already been created. The action was expanded to multiple actions in 5.0 and renamed to logpackets actions to better specify it is the logging of packets.

The creation of the alert in version 4.1 was implied by just enabling the signature. In version 5.0 we no longer simply imply that the alert will be created, and instead created a specific action for this: produceAlert.

Here is the list of actions supported in version 5.0:

produce-alert write evIdsAlert to Event Store.

produce-verbose-alert include an encoded dump (possibly truncated) of the

offending packet in the evIdsAlert.

deny-attacker-inline INLINE ONLY: do not transmit this packet and future

packets from the attacker address for a specified

period of time.

deny-connection-inline INLINE ONLY: do not transmit this packet and future

packets on the TCP Flow.

deny-packet-inline INLINE ONLY: do not transmit this packet

log-attacker-packets start IPLOGGING packets containing the attacker

address.

log-pair-packets start IPLOGGING packets containing the

attacker-victim address pair.

log-victim-packets start IPLOGGING packets containing the victim

address.

request-block-connection request NAC to shun this connection

request-block-host request NAC to shun this attacker host

request-snmp-trap send request to Notification App to perform Snmp

action.

reset-tcp-connection send TCP RESETS to hijack and terminate the TCP

Flow.

!) Default bahaviour:

For almost all signatures the default behaviour (if the sig is enabled) is produceAlert. (Implied in 4.1, and specifically set as an action in 5.0).

In 4.1 there are no additional actions by default.

In version 5.0, most signatures do not have additional actions by default. The exception to this are some of our normalizer signatures. The normalizer signatures detect problems in the base IP or TCP protocol. These packets should not be allowed on the network. So on an InLine sensor some of these signatures are also configured with a default action of denyPacketInLine (and on some we even removed the default produceAlert action).

(See the follow on post for how to quickly add the denyPacketInLine action for all high risk alerts)

2) Which actions:

IN version 4.1 the sensor is capable of doing all 3 of the actions listed.

In version 5.0 the sensor is capable of doing the equivalent actions as well several additional actions.

3) Can the IPS do Blocking on it's own.

Blocking is a specific term we use for managing ACLs on Another Network Device. Because of that definition, the IPS must need a another device to do Blocking.

What I think are really asking is if the Sensor itself can Drop the malicious packets.

For version 4.0 the answer to that is No. The 4.0 sensor can only deployed in promiscous mode which only receives a copy of the packet.

Continued on next post:

[marcabal]

For version 5.0 the answer is YES. The 5.0 sensor supports the 4.0 style promiscuous mode, BUT it also supports a new InLine mode. In InLine mode, the actual packets have to pass through the sensor. In this mode, you can configure signatures to have Deny actions (denyPacketInLine, denyConnectionInLine, denyAttackerInLine) that will drop the offending packet(s). So the Deny actions can be thought of as the sensor doing the blocking on itself. But we try to differentiate the 2 actions by using 2 different terms: Deny for the local dropping of packets on the sensor itself, and Blocking for the configuring of a device to do the dropping.

Just some additional information:

Though most signatures (even the high severity ones) do not contain the Deny actions by default, it is very easy to add those and any other actions in 5.0.

In version 5.0 we have a new feature called Risk Rating. It takes the Severity of the Signatures, the Fidelity of the Signature (fidelity is a measure of how acccurate is the detection and how much it causes false positives), and the Target Value Rating (how important is to protect the end system) and puts the values through a formula to come up with a number between 0 and 100.

The higher the number the bigger the Risk for that particular event detected.

We then have what we call Event Action OverRides. The OverRides let you add additional actions based simply on the Risk Rating of the event.

So if you are running 5.0 in InLine mode and you want the sensor to Deny any event with a high Risk Rating, you simply configure the Event Action OverRides to add the denyPacketInLine action to any event with a Risk Rating of say 85.

85 has been a good starting point for the denyPacketInLine action. If you want to be more strict then decrease the number in increments of 5 or 10 until you think it is blocking as much as you are willing to let it.

(Of course you can still go to each individual signature and add the specific action as well. You can even do this in conjunction with using the Event Action OverRides)

[NAVIN PARWAL]

Thanks for the response. Please correct me if i am wrong. If i use the Event Action Overrides, I only have to do it at 1 place? means if i lets say configure risk rating to 85, the IDS will reset connections matching signatures(critical + high risk + high target value rating) which has a value of greater than 85?

[marcabal · Accepted solution]

Your wording is Off, but I think you get the general idea.

If you configure the Event Action OverRide for the TCP Reset action to a Risk Rating Range of 85-100. Then any alert with a Risk Rating between 85 and 100 will automatically have a TCP Reset action added to it.

This way you can configure it in one place instead of having to go to every alert and add the TCP Reset action.