denyPacketRequestedNotPerformed + denyFlowRequestedNotPerformed

Similar Questions

• denyPacketRequestedNotPerformed?

  The answer seems obvious, but these "measures" mean?

  denyPacketRequestedNotPerformed, denyFlowRequestedNotPerformed

  Why a requested action could not be performed?

  These actions are generally seen on a sensor of promiscuity.

  In order to refuse the connection or the package, the sensor must be deployed online.

  When in promiscuous mode, the sensor is not able to refuse and drop the actual packets because it receives a copy of the packages. What is this action lets you know that if you had deployed it in a mode online rather than in "Promiscuous" mode then the sensor would have protected you from the attack.

  The main objective of putting this in the alert was to help users who would test the sensor in "Promiscuous" mode before you deploy the sensor in inline mode in their network. They would be able to determine what would have been denied. If the alert was a false positive, then he would have refused if they had put online valid traffic on their network. They are therefore able to right a filter for that traffic to ensure that it will not be denied before moving the detector of promiscuity Inline within their network.

• Config Service IPS 5520 policy assistance

  I have a 5520 running 7.2 (4) (Routed, unique context) with a SSM20 running 1.0000 E2.

  I'm struggling a bit with DFS configuration on my 5520. I created 2 service policies, one applied to a DMZ interface and configured as 'in-line '. Others applied within the interface and set up "promiscuous" (until I get it tuned).

  It seems that there is no way (about 7.2) to run each service its own virtual sensor on the SSM20 strategy. That's why I'm fighting a little trying to determine what political Service sends the traffic that triggers a particular event. Is there something in the SSM event log that identifies which Service policy sent traffic to the virtual sensor?

  Thanks in advance!

  David

  The ASA does not say the SSM what policy sent the package, so that the SSM cannot declare what policy sent him. Only if we monitor the promiscuity or inline (and in the case of 8.0 what context it comes and which virtual sensor to use).

  Other things that might help.

  Look at the addresses of alerts.

  If the source address is an address DMZ, then probably the DMZ policy.

  If the source address is an address to the inside, then probably domestic politics.

  If the source address is an address from the outside, then watch the address of destination.

  If the destination is an address DMZ, then probably the DMZ policy.

  If the desintation is an address to the inside, then probably domestic politics.

  Why?

  In the case of TCP SYN packet will determine what policy will affect the rest of the packages.

  And it's the first corresponding ips policy that will determine the type of monitoring.

  If a packet coming FROM the DMZ to Internet SYN will be first checked by the DMZ policy. If the DMZ policy is, then it will be inline monitored (by the DMZ policy).

  Similarly a SYN from the DMZ TO the Interior package will check first of all by the DMZ policy, then it will it be controlled by domestic politics. If the DMZ policy match then the SYN and the rest of the packets for the connection will be guarded inline. If corresponds to the policy of the DMZ, then domestic politics will be always checked, but it is the policy of the DMZ that determines the promiscuity or inline because it's the first policy matched. If the DMZ policy does NOT match the SYN packet, but is domestic politics, then the connection will be histocompatibility by domestic politics.

  Conversely, however, a package SYN FROM inside the DMZ will be firt compared to domestic politics.

  Inside corresponding to the first policy would cause the connection to monitor histocompatibility. Politics of the DMZ would be verified, as well, but with the domestic policy corresponding to the first, it will track promisuous.

  If domestic politics does NOT match would be the a political DMZ was filled with online monitoring.

  At least that's how I think that it worked in 7.2. The above, this is how it works in 8.0 when we tested with virtual probes and so I guess it worked that way in 7.2 as well.

  In your alerts above. The first alert was 'Actions droppedPacket + deniedFlow + tcpOneWayResetSent' Deny/Drop actions cannot run in Inline mode, so it must come from the DMZ policy.

  The second alert was 'Actions denyPacketRequestedNotPerformed + denyFlowRequestedNotPerformed' and 'NotPerformed"to Deny/Drop actions usually only happens with the Promiscuous mode. So, he had to be domestic policy.