Physical Connectivity of ASA AIP-SSM

Answered Question
Aug 28th, 2008

How should the physical connectivity of ASA AIP-SSM be in case of inline interface mode inspection for all the firewall interfaces. ?

Rgds.

Correct Answer by marcabal about 8 years 5 months ago

Assuming "interface_policy" has "ips inline" within the policy, then yes your configuration is correct.

Keep in mind that the "GigabitEthernet0/1" being assigned to vs0 is the backplane interface of the SSM itself, and should not be confused with the GigabitEthernet0/1 external interface of the ASA.

As for using multiple virtual sensors, this is a personal choice.

When using an ASA with just a single context, then usually a single virtual sensor is enough. It is only when you want different monitoring for traffic coming from different firewall interfaces (or different classes of traffic) would you want to use multiple virtual sensors.

However, when using an ASA with multiple security contexts, then it is usually a good idea to go ahead and use a separate virtual sensor per ASA context.

If you choose to use multiple virtual sensors, you need to understand that the GigabitEthernet0/1 backplane interface will still only be assigned to just 1 of the virtual sensors.

Here is an explanation of how the other virtual sensors would get traffic:

When packets are sent from the ASA to the SSM for monitoring, the ASA includes a special header as part of each packet. That special contains information such as the ASA context where the packet came from, the real and NAT/PAT addresses of the packet, and a few other things. One important field in that header is for the virtual sensor. It tells the SSM which virtual sensor should monitor that packet.

When the ASA is configured without using virtual sensor names, then that virtual sensor field in the packet header is left blank. If the SSM sees a packet with this field left blank it will check the SSM configuration to see which virtual sensor the SSM's GigabitEthernet0/1 has been assigned, and will send that packets to that virtual sensor.

If the ASA was configured to send the packet to a specific virtual sensor (either by adding the virtual sensor name to the end of the "ips inline" configuration entries, or by using the "allocate ips" configuration entries in the system context configuration) then the ASA will include the virtual sensor in the packet header. The SSM will read in that field, and instead of sending it to the virtual sensor where Gig0/1 was assigned, it will instead send it to specified virtual sensor from the packet header.

It in effect overrides the Gig0/1 assignment and will instead direct to what ever virtual sensor was specified by the ASA configuration.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
rhermes Thu, 08/28/2008 - 12:59

The AIP-SSM module has one physical interface GigE0/0 and that is used only for Command and Control. The In-Line IPS interface is GigE0/1 and it is connected to the backplane of the ASA. The backplane interface is reachable via the ASA configuration to either be placed inline with the traffic flow on an interface, or promiscious mode passive traffic sniffing.

Connect the ASA like you would a firewall, declare inside and outside interfaces, then assign the IPS function to one or more interfaces.

new_networker Thu, 08/28/2008 - 21:59

So is the GigE0/1 assigned by the following in AIP configuration

-> virtual-sensor vs0

-> physical-interface GigabitEthernet0/1

And is the interface to be monitored on the ASA defined by

-> service-policy interface_policy interface DMZ

In general, is there a need to define more than one virtual sensor on the backplane interface GigE0/1.

Thanks.

Correct Answer
marcabal Fri, 08/29/2008 - 06:01

Assuming "interface_policy" has "ips inline" within the policy, then yes your configuration is correct.

Keep in mind that the "GigabitEthernet0/1" being assigned to vs0 is the backplane interface of the SSM itself, and should not be confused with the GigabitEthernet0/1 external interface of the ASA.

As for using multiple virtual sensors, this is a personal choice.

When using an ASA with just a single context, then usually a single virtual sensor is enough. It is only when you want different monitoring for traffic coming from different firewall interfaces (or different classes of traffic) would you want to use multiple virtual sensors.

However, when using an ASA with multiple security contexts, then it is usually a good idea to go ahead and use a separate virtual sensor per ASA context.

If you choose to use multiple virtual sensors, you need to understand that the GigabitEthernet0/1 backplane interface will still only be assigned to just 1 of the virtual sensors.

Here is an explanation of how the other virtual sensors would get traffic:

When packets are sent from the ASA to the SSM for monitoring, the ASA includes a special header as part of each packet. That special contains information such as the ASA context where the packet came from, the real and NAT/PAT addresses of the packet, and a few other things. One important field in that header is for the virtual sensor. It tells the SSM which virtual sensor should monitor that packet.

When the ASA is configured without using virtual sensor names, then that virtual sensor field in the packet header is left blank. If the SSM sees a packet with this field left blank it will check the SSM configuration to see which virtual sensor the SSM's GigabitEthernet0/1 has been assigned, and will send that packets to that virtual sensor.

If the ASA was configured to send the packet to a specific virtual sensor (either by adding the virtual sensor name to the end of the "ips inline" configuration entries, or by using the "allocate ips" configuration entries in the system context configuration) then the ASA will include the virtual sensor in the packet header. The SSM will read in that field, and instead of sending it to the virtual sensor where Gig0/1 was assigned, it will instead send it to specified virtual sensor from the packet header.

It in effect overrides the Gig0/1 assignment and will instead direct to what ever virtual sensor was specified by the ASA configuration.

Actions

This Discussion