AIP-SSM

[evraas.it]

Hello!

I have problem with configuring AIP-SSM for ASA 5520.

I have configured ASA and AIP as in the configuration guide. When I scan (made atack) the network, I see on the aip module (show events alert) information about attacks. But it doesn't work as IPS system.

I have following message via "show module":

Mod Card Type Model Serial No.

--- -------------------------------------------- ------------------ -----------

0 ASA 5520 Adaptive Security Appliance ASA5520 XXXXXXXXXXXX

1 ASA 5500 Series Security Services Module-10 ASA-SSM-10 XXXXXXXXXXXX

Mod MAC Address Range Hw Version Fw Version Sw Version

--- --------------------------------- ------------ ------------ ---------------

0 xxxx.xxxx.xxxx to xxxx.xxxx.xxxx 2.0 1.0(11)2 7.0(7)

1 xxxx.xxxx.xxxx to xxxx.xxxx.xxxx 1.0 1.0(11)2 5.1(6)E1

Mod Status Data Plane Status

--- ------------------ ---------------------

0 Up Sys Not Applicable

1 Up Up

You can see that there is not line:

Mod SSM Application Name Status SSM Application Version

--- ------------------------------ ---------------- --------------------------

1 IPS Up 5.1(6)E1

All configurations I have made via CLI. When I connect to AIP-SSM via ASDM I get warning message, that there is no license for AIP. I'm trying to update license via Cisco Connection Online, but it doesn;t work.

Please, explain me - AIP doesn't work as IPS because of license absence or something else?

Or I need license only for signatures update?

Best regards,

Nick.

[rhermes]

Nick -

It sounds like you have configured the ASA portion, but might not have configured the AIP-SSM. Log into your sensor with the "session 1" command use the default cisco/cisco password and run setup. Don't forget to add the sensing interface to the virtual sensor.

[evraas.it]

rhermes,

thanks for reply.

But I've already configured the AIP-SSM as in the manual. I even check, that module senses attacks (via command "show events alert" on the AIP-SSM). But it doesn't work as IPS although I configured the module in inline mode.

[marcabal]

The ASA can send the packets to the SSM in one of 2 modes: Promiscuous and Inline.

In Promiscuous mode the ASA makes a copy of the packet and sends the copy to the SSM.

In Inline mode the ASA sends the packet to the SSM. Once the SSM analyzes the packet it will either send it back to the ASA for the ASA to forward on, or the SSM will deny (drop) the packet.

The real difference between Promiscuous mode and Inline mode is that in Inline mode the SSM is able to deny (drop) the packet causing the attack.

However, you need to understand that the SSM will only do the deny for a limited number of signatures/attacks with the default configuration.

There is a deny-packet-inline event action that has to be configured on the signature itself, or applied through an event action override in order for the sensor to deny (drop) the packet. Without this event action the Inline sensor may appear to act just the same as a Promiscuous sensor. It is the deny-packet-inline action (and other deny actions) that really make the difference on an Inline sensor.

With the default configuraiton on the SSM there are very few signatures with the deny-packet-inline action.

NOTE: If you look at the signature configurations you might see some with a deny-packet-inline action as the default, but theses signatures are either in the Normalizer engine which is not used on an SSM, or in the AIC HTTP or AIC FTP engines that are turned Off by default. Then there are only a handfull of signatures in the 50000+ range of signature ids that haev the deny-packet-inline as a default action.

So you should not expect any denies to happen based on the default signature settings.

There is, however, a default event action override setting that WILL add deny-packet-inline actions, BUT only if the alert has a Risk Rating between 90 and 100.

When a signature gets triggered it creates an internal SigEvent and any actions configured for the signature are added to this SigEvent. A Risk Rating is then calculated for the SigEvent based on the Severity and Fidelity of the Signature, as well as the Target Value Rating and Attack Relevancy of the specific Destination Address for this triggering of the signature, as well as any Watch List ratings for the Source Address of this triggering. That Risk Rating is then compared to the Event Action Overrides. BY default there is an event action override for the deny-packet-inline event action to be added to the SigEvent IF the Risk Rating is between 90 and 100.

Something else to keep in mind, however, is that deny-packet-inline is not necessarily applicable to ALL signatures. Sweep and Flood signatures are multi-packet attacks and are generally unaffected by the deny-packet-inline action. For these types of attacks the deny-attacker-inline or other deny actions will do a better job of stopping the traffic.

SO if your Inline sensor is alerting on signatures, but not denying (dropping) the packets; then more than likely the alerts are:

1) Not one of the signatures with a default deny-packet-inline event action, and/or

2) Not having a Risk Rating between 90-100, and/or

3) You may have disabled the default event action override for deny-packet-inline, and/or

4) The signatures are one those for which deny-packet-inline is not an effective means of stopping the traffic, and/or

5) If you have created any filters you may have accidentally created a filter removing the deny actions.

[marcabal]

So look at the alerts and see if anywhere in the alert it says that a deny action was done.

If there is a line in the alert saying that the packet was dropped or denied, then the SSM likely DID drop the packet.

If there is a line in the alert saying that the deny action was Not Performed, then this means the signatrue was monitoring Promiscuously and not Inline so you need to check your ASA configuration.

If there is no line in the alert for the deny action, then check the signature configuration to see if a deny-packet-inline action was configured for the signature. You might want to add the deny-packet-inline event action, and possibly some of the other deny actions.

Also check the Risk Rating of the alert to see if it is between 90 and 100. If it is not, then you might consider increasing the range for the deny-packet-inline event action to something like 70-100 or whatever range you are comfortable with.

Also check your fitlers to ensure you don't have a filter removing the deny actions.