5520 IPS Service policy config assistance

Answered Question
Sep 11th, 2008

I have a 5520 running 7.2(4) (Routed, single context) with an SSM20 running 6.1(1)E2.

I am struggling a bit with the SSM setup on my 5520. I have created 2 service policies, one applied to a DMZ interface and configured as "in-line". The other applied to the inside interface and configured "promiscuous" (until I get it tuned).

It appears there is no way (on 7.2) to direct each service policy to its own virtual sensor on the SSM20. For this reason I am struggling a bit in trying to determine which Service Policy is sending the traffic that triggers a particular event. Is there anything in the SSM event log that identifies which Service Policy sent the traffic to the virtual sensor?

Thanks in advance!

David

I have this problem too.
0 votes
Correct Answer by marcabal about 8 years 3 months ago

The ASA does not tell the SSM which policy sent the packet, so the SSM can not report which policy sent it. Only whether to monitor it promiscuous or inline (and in the case of 8.0 which context it came from and which virtual sensor to use).

Other things that might help.

Look at the addresses of the alerts.

If the source address is a DMZ address, then likely the DMZ policy.

If the source address is a Inside address, then likely the Inside policy.

If the source address is a Outside address, then look at the destination address.

If the destination is a DMZ address, then likely the DMZ policy.

If the desintation is a Inside address, then likely the Inside policy.

Why?

In the case of TCP, the SYN packet will determine which policy will affect the rest of the packets.

And it is the first ips policy that matches which will determine the type of monitoring.

So a SYN packet coming FROM the DMZ TO the Internet will first be checked by the DMZ policy. So if the DMZ policy matches, then it will be inline monitored (by the DMZ policy).

Similarly a SYN packet coming FROM the DMZ TO the Inside will first be checked by the DMZ policy then it will the be checked by the Inside policy. If the DMZ policy matches then the SYN and remaining packets for the connection will be inline monitored. If the DMZ policy matches, then the Inside policy will still be checked, but it is the DMZ policy that will determine promiscuous or inline because it is the first policy matched. If the DMZ policy does NOT match the SYN packet, but the Inside policy does, then the connnection will be Promiscuously monitored by the Inside policy.

In reverse, however, a SYN packet FROM the Inside TO the DMZ will be firt matched against the Inside policy.

The inside policy matching first would cause the connection to be monitored Promiscuously. The DMZ policy woudl be checked, as well but with the Inside policy matching first it will cause the promisuous monitoring.

Only if the Inside policy is NOT matched would the a DMZ policy match cause Inline monitoring.

At least this is is how I think it worked back in 7.2. The above is how it does work in 8.0 when we tested with virtual sensors, and so I assume it worked that way back in 7.2 as well.

In your alerts above. The first alert has "Actions droppedPacket+deniedFlow+tcpOneWayResetSent " the Deny/Drop actions can only work in Inline mode, so it must have come from the DMZ policy.

The second alert has "Actions denyPacketRequestedNotPerformed+denyFlowRequestedNotPerformed " and the "NotPerformed" for the Deny/Drop actions generally only happens with Promiscuous mode. So it must have been from the Inside policy.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.5 (2 ratings)
Loading.
suschoud Thu, 09/11/2008 - 07:03

Hi,

Not sure if the options are available in 7.2.4 but in 8.x,you can specify to what virtual sensor,you want to forward traffic to in mpf config :

#########

ASA-5510-8x(config)# pol

ASA-5510-8x(config)# policy-map global_policy

ASA-5510-8x(config-pmap)# class mymap

ASA-5510-8x(config-pmap-c)# ?

MPF policy-map class configuration commands:

csc Content Security and Control service module

exit Exit from MPF class action configuration mode

help Help for MPF policy-map class/match submode commands

inspect Protocol inspection services

ips Intrusion prevention services

no Negate or set default values of a command

police Rate limit traffic for this class

priority Strict scheduling priority for this class

quit Exit from MPF class action configuration mode

ASA-5510-8x(config-pmap-c)# ip

ASA-5510-8x(config-pmap-c)# ips

ASA-5510-8x(config-pmap-c)# ips in

ASA-5510-8x(config-pmap-c)# ips inline fa

ASA-5510-8x(config-pmap-c)# ips inline fail-o

ASA-5510-8x(config-pmap-c)# ips inline fail-open v

ASA-5510-8x(config-pmap-c)# ips inline fail-open vs

ASA-5510-8x(config-pmap-c)# ips inline fail-open ?

mpf-policy-map-class mode commands/options:

sensor Specify virtual sensor

ASA-5510-8x(config-pmap-c)# ips inline fail-open sen

ASA-5510-8x(config-pmap-c)# ips inline fail-open sensor ?

mpf-policy-map-class mode commands/options:

WORD < 127 char Virtual sensor name

ASA-5510-8x(config-pmap-c)# ips inline fail-open sensor vs0

############

Do rate helpful posts.

Regards,

Sushil

davidelon Thu, 09/11/2008 - 07:36

Thank you very much for your reply Sushil!

Unfortunately, it appears that 7.2 does not support the "sensor" switch in the MPF.

Since I am unable to specify a sensor, I am wondering if something is passed from the 5520 to the SSM20 that would identify which service policy forwarded the traffic.

Thanks,

David

suschoud Thu, 09/11/2008 - 07:42

Issue :

sh service-policy

It'll give you the count ( how many packets and by which service policy ) were sent to ips.

Regards,

Sushil

davidelon Thu, 09/11/2008 - 09:00

Thanks again for taking the time to post a reply Sushil. I sincerely appreciate your efforts.

Here is an example of this issue. This is an event from the SSM that I am sure was forwarded by the "DMZ" Service Policy (which is in-line):

Event ID 1215752193899293474

Severity high

Host ID XXXXX

Application Name sensorApp

Event Time 09/11/2008 09:06:56

Sensor Local Time 08/11/2008 09:06:56

Signature ID 3136

Signature Sub-ID 3

Signature Name Netsky Virus Activity

Signature Version S81

Signature Details Netsky.P com/exe/src/pif

Interface Group vs0

VLAN ID 0

Interface GigabitEthernet0/1

Attacker IP 67.220.5.161

Protocol tcp

Attacker Port 1543

Attacker Locality OUT

Target IP xxx.xxx.xxx.xxx

Target Port 25

Target Locality OUT

Target OS learned windows-nt-2k-xp (relevant)

Actions droppedPacket+deniedFlow+tcpOneWayResetSent

Risk Rating TVR=medium ARR=relevant

Risk Rating Value 100

Threat Rating 65

Context Data From attacker:

*******

This is an event that I THINK was forwarded by the "inside" Service Policy (promiscuous mode)

Event ID 1215752193899292674

Severity high

Host ID XXXXX

Application Name sensorApp

Event Time 09/10/2008 23:08:32

Sensor Local Time 08/10/2008 23:08:32

Signature ID 5732

Signature Sub-ID 0

Signature Name Web Client Remote Code Execution Vulnerability

Signature Version S339

Signature Details Web Client Remote Code Execution Vulnerability

Interface Group vs0

VLAN ID 0

Interface GigabitEthernet0/1

Attacker IP xxx.xxx.xxx.xxx

Protocol tcp

Attacker Port 4941

Attacker Locality OUT

Target IP xxx.xxx.xxx.xxx

Target Port 445

Target Locality OUT

Target OS unknown unknown (relevant)

Actions denyPacketRequestedNotPerformed+denyFlowRequestedNotPerformed

Risk Rating TVR=medium ARR=relevant

Risk Rating Value 100

Threat Rating 100

Context Data

Packet Data

Event Summary 0

Initial Alert

Summary Type

Final Alert

Event Status New

Event Notes

While I THINK the second event was triggered by traffic forwarded by the "inside" Service Policy, I don't KNOW. This is making it difficult to verify that I have the correct ACL configured in the correct order on the Service Policies.

I was hoping that a field existed as part of the alert that would provide this information.

Thanks again for your help!

David

Correct Answer
marcabal Thu, 09/11/2008 - 09:50

The ASA does not tell the SSM which policy sent the packet, so the SSM can not report which policy sent it. Only whether to monitor it promiscuous or inline (and in the case of 8.0 which context it came from and which virtual sensor to use).

Other things that might help.

Look at the addresses of the alerts.

If the source address is a DMZ address, then likely the DMZ policy.

If the source address is a Inside address, then likely the Inside policy.

If the source address is a Outside address, then look at the destination address.

If the destination is a DMZ address, then likely the DMZ policy.

If the desintation is a Inside address, then likely the Inside policy.

Why?

In the case of TCP, the SYN packet will determine which policy will affect the rest of the packets.

And it is the first ips policy that matches which will determine the type of monitoring.

So a SYN packet coming FROM the DMZ TO the Internet will first be checked by the DMZ policy. So if the DMZ policy matches, then it will be inline monitored (by the DMZ policy).

Similarly a SYN packet coming FROM the DMZ TO the Inside will first be checked by the DMZ policy then it will the be checked by the Inside policy. If the DMZ policy matches then the SYN and remaining packets for the connection will be inline monitored. If the DMZ policy matches, then the Inside policy will still be checked, but it is the DMZ policy that will determine promiscuous or inline because it is the first policy matched. If the DMZ policy does NOT match the SYN packet, but the Inside policy does, then the connnection will be Promiscuously monitored by the Inside policy.

In reverse, however, a SYN packet FROM the Inside TO the DMZ will be firt matched against the Inside policy.

The inside policy matching first would cause the connection to be monitored Promiscuously. The DMZ policy woudl be checked, as well but with the Inside policy matching first it will cause the promisuous monitoring.

Only if the Inside policy is NOT matched would the a DMZ policy match cause Inline monitoring.

At least this is is how I think it worked back in 7.2. The above is how it does work in 8.0 when we tested with virtual sensors, and so I assume it worked that way back in 7.2 as well.

In your alerts above. The first alert has "Actions droppedPacket+deniedFlow+tcpOneWayResetSent " the Deny/Drop actions can only work in Inline mode, so it must have come from the DMZ policy.

The second alert has "Actions denyPacketRequestedNotPerformed+denyFlowRequestedNotPerformed " and the "NotPerformed" for the Deny/Drop actions generally only happens with Promiscuous mode. So it must have been from the Inside policy.

davidelon Thu, 09/11/2008 - 10:10

Thank you for the detailed response. The information on Service Policy interaction is particularly helpful.

I appreciate it.

David

Actions

This Discussion