Which actions can a promiscuous IPS take to mitigate an attack?
A.
modifying packets
B.
requesting connection blocking
C.
denying packets
D.
resetting the TCP connection
E.
requesting host blocking
F.
denying frames
Explanation:
Promiscuous Mode Event Actions
The following event actions can be deployed in Promiscuous mode. These actions are in
affect for a user- configurable default time of 30 minutes. Because the IPS sensor must send
the request to another device or craft a packet, latency is associated with these actions and
could allow some attacks to be successful.
Blocking through usage of the Attack Response Controller (ARC) has the potential benefit of
being able to perform to the network edge or at multiple places within the network.
Request block host: This event action will send an ARC request to block the host for a
specified time frame, preventing any further communication. This is a severe action that is
most appropriate when there is minimal chance of a false alarm or spoofing.
Request block connection: This action will send an ARC response to block the specific
connection. This action is appropriate when there is potential for false alarms or spoofing.
Reset TCP connection: This action is TCP specific, and in instances where the attack
requires several TCP packets, this can be a successful action. However, in some cases
where the attack only needs one packet it may not work as well. Additionally, TCP resets are
not very effective with protocols such as SMTP that consistently try to establish new
connections, nor are they effective if the reset cannot reach the destination host in time.
Event actions can be specified on a per signature basis, or as an event action override (based
on risk rating values ?event action override only). In the case of event action override, specific
event actions are performed when specific risk rating value conditions are met. Event action
overrides offer consistent and simplified management. IPS version 6.0 contains a default
event action override with a deny-packet-inline action for events with a risk rating between 90
and 100. For this action to occur, the device must be deployed in Inline mode.
Protection from unintended automated action responses
Automated event actions can have unintended consequences when not carefully deployed.
The most severe consequence can be a self denial of service (DoS) of a host or network. Themajority of these unintended consequences can be avoided through the use of Event Action
Filters, Never Block Addresses, Network spoofing protections, and device tuning. The
following provides an overview of methods used to prevent unintended consequences from
occurring.
Using Event Action Filters and Never Block
By using these capabilities, administrators may prevent a miscreant from spoofing critical IP
addresses, causing a self inflicted DoS condition on these critical IP addresses. Note that
Never Block capabilities only apply to ARC actions. Actions that are performed inline will still
be performed as well as rate limiting if they are configured.
Minimize spoofing
Administrators can minimize spoofed packets that enter the network through the use of
Unicast Reverse Path Forwarding. Administrators can minimize spoofing within their network
through the use of IP Source Guard. The white paper titled Understanding Unicast Reverse
Path Forwarding provides details on configuration of this feature. More information on IP
Source Guard is available in the document titled Configuring DHCP Features and IP Source
Guard.
Careful Use of Event Actions
By judicious use of event actions that block unwanted traffic, such as using the high signature
fidelity rating, and not using automated actions on signatures that are easily spoofed,
administrators can reduce the probability of an unintended result. For an event to have a high
risk rating, it must have a high signature fidelity rating unless the risk rating is artificially
increased through the use of Target Value Rating or Watch List Rating, which are IP specific
increases.
Tuning
By tuning the signature set to minimize false positive events, administrators can reduce the
chance of an event action that has an unintended consequence.
High Base Risk Rating Events
In most cases, events with a high base risk rating or a high signature fidelity rating are strong
candidates for automated event actions. Care should be taken with protocols that are easily
spoofed in order to prevent self DoS conditions.