09-11-2008 05:45 AM - edited 03-10-2019 04:17 AM
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
Solved! Go to Solution.
09-11-2008 09:50 AM
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.
09-11-2008 07:03 AM
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
09-11-2008 07:36 AM
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
09-11-2008 07:42 AM
Issue :
sh service-policy
It'll give you the count ( how many packets and by which service policy ) were sent to ips.
Regards,
Sushil
09-11-2008 09:00 AM
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
09-11-2008 09:50 AM
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.
09-11-2008 10:10 AM
Thank you for the detailed response. The information on Service Policy interaction is particularly helpful.
I appreciate it.
David
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: