Buy or Renew
Buy or Renew
Duo Security forums now LIVE! Get answers to all your Duo Security questions. Learn more
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
1033
Views
9
Helpful
2
Replies

(ASA) AIP-SSM 10 Inline; Promiscuos Events?

Go to solution
mlenco
Level 1
Level 1

‎02-20-2008 12:30 PM - edited ‎03-10-2019 04:00 AM

An ASA 5520 with an AIM SSM-10 is configured for inline mode but the show events past 2 hours(sensor>sh event past 2:00) from inside the sensor shows and 'entered promicuous mode', "left promicuous mode'.

This AIP SSM-10 only has a gig0/0 and gig0/1 where o/o is shutdown and a default virtual sensor (vs0) is assigned to gig0/1. I see statistics (sensor>sh statisics analysis-engine) for gig0/1 so I am collecting statistics.

If the ASA 5520 configuration has the following inline policy and the events log shows entering and leaving promiscuous mode then how do I verify if I am inspecting/collecting in inline mode?

(ASA>sh run access-list IPS)

access-list IPS extended permit ip DMZ 255.255.255.0 26.26.1.0 255.255.255.0

(ASA>sh run | b class-map)

class-map IPS

match access-list IPS

class-map inspection_default

match default-inspection-traffic

!

!

policy-map type inspect dns preset_dns_map

parameters

message-length maximum 512

policy-map global_policy

class inspection_default

inspect dns preset_dns_map

inspect ftp

inspect h323 h225

inspect h323 ras

inspect netbios

inspect rsh

inspect rtsp

inspect skinny

inspect esmtp

inspect sqlnet

inspect sunrpc

inspect tftp

inspect sip

inspect xdmcp

inspect waas

inspect icmp

class IPS

ips inline fail-open

!

service-policy global_policy global

(sensor>sh interfaces)

...

MAC statistics from interface GigabitEthernet0/1

Interface function = Sensing interface

Description =

Media Type = backplane

Default Vlan = 0

Inline Mode = Unpaired

Pair Status = N/A

Hardware Bypass Capable = No

Hardware Bypass Paired = N/A

Link Status = Up

Link Speed = Auto_1000

Link Duplex = Auto_Full

Missed Packet Percentage = 0

Total Packets Received = 95044

Total Bytes Received = 8715230

Total Multicast Packets Received = 0

Total Broadcast Packets Received = 0

Total Jumbo Packets Received = 0

Total Undersize Packets Received = 0

Total Receive Errors = 0

Total Receive FIFO Overruns = 0

Total Packets Transmitted = 95044

Total Bytes Transmitted = 9047702

Total Multicast Packets Transmitted = 0

Total Broadcast Packets Transmitted = 0

Total Jumbo Packets Transmitted = 0

Total Undersize Packets Transmitted = 0

Total Transmit Errors = 0

Total Transmit FIFO Overruns = 0

sensor>sh events last 2:00

evStatus: eventId=1203360411830836145 vendor=Cisco

originator:

hostId: ASA2_IPS

appName: kernel

appInstanceId:

time: 2008/02/20 19:01:46 2008/02/20 19:01:46 UTC

syslogMessage:

description: device ge0_1 entered promiscuous mode

evStatus: eventId=1203360411830836146 vendor=Cisco

originator:

hostId: ASA2_IPS

appName: kernel

appInstanceId:

time: 2008/02/20 19:01:53 2008/02/20 19:01:53 UTC

syslogMessage:

description: device ge0_1 left promiscuous mode

Labels:
0 Helpful
1 Accepted Solution

Accepted Solutions

Go to solution
marcabal
Cisco Employee
Cisco Employee

‎02-20-2008 01:02 PM

The entered and left promiscuous mode status events are usually generated when doing a "packet display" or "packet capture" command on the CLI of the sensor.

The packet command monitoring is promiscuous but is independant of the promiscuous or inline monitoring done by the sensor's analysis engine.

So you could be doing inline monitoring using the sensor's analysis engine.

And still do the cli's packet command for your own promiscuous monitoring of those same packets. These are 2 independant monitorings of the same packets.

If I remember right inline monitored packets always get sent back to the ASA (unless specifically denied), while promiscuous packets do not. So check the statistics on the sensors gig0/1 interface and check the transmit packet count. If the receive and transmit counts are fairly close, then the packets are being InLine monitored by the analysis engine. If the transmit count is zero or very low then the packets are likely promiscuous monitored.

With your ASA configuration you are properly configured for inline monitoring.

So I do think you are monitoring inline, and the status messages are specific to your starting and stopping the "packet" command on the CLI for your own independant promiscuous viewing of the packets.

View solution in original post

2 Replies 2

Go to solution
marcabal
Cisco Employee
Cisco Employee

‎02-20-2008 01:02 PM

The entered and left promiscuous mode status events are usually generated when doing a "packet display" or "packet capture" command on the CLI of the sensor.

The packet command monitoring is promiscuous but is independant of the promiscuous or inline monitoring done by the sensor's analysis engine.

So you could be doing inline monitoring using the sensor's analysis engine.

And still do the cli's packet command for your own promiscuous monitoring of those same packets. These are 2 independant monitorings of the same packets.

If I remember right inline monitored packets always get sent back to the ASA (unless specifically denied), while promiscuous packets do not. So check the statistics on the sensors gig0/1 interface and check the transmit packet count. If the receive and transmit counts are fairly close, then the packets are being InLine monitored by the analysis engine. If the transmit count is zero or very low then the packets are likely promiscuous monitored.

With your ASA configuration you are properly configured for inline monitoring.

So I do think you are monitoring inline, and the status messages are specific to your starting and stopping the "packet" command on the CLI for your own independant promiscuous viewing of the packets.

Go to solution
mlenco
Level 1
Level 1
In response to marcabal

‎02-20-2008 06:02 PM

Before I ran the sensor>sh statistics event last 2:00, I ran sensor>packet display GiabitEthernet0/1 to see the pings I was using to verify the SSM was looking at packets. echo/echo reply packets were traversing gig0/1 on the SSM. So, as you state that is what probably kicked off the enter/left promiscuous mode. Good catch!

Matt

0 Helpful
Getting Started

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:

Customers Also Viewed These Support Documents
Review Cisco Networking products for a $25 gift card