Applying different IPS policies to specific flows with the AIP-SSM

Blog

Fri, 08/26/2011 - 09:35
Apr 13th, 2011
User Badges:
  • Silver, 250 points or more

Introduction


You may find it necessary to apply separate inspection policies to different traffic flows. Applying separate firewall protocol inspections on a per flow basis is done simply by appropriately configuring the Modular Policy Framework (MPF) on the Adaptive Security Appliance (ASA). The decision of which policy to apply is made on a per flow basis and based on IP, port, and protocol.


Traffic classifications are made via class-maps and policy actions are defined via policy-maps. The same MPF structural logic can be applied to enforce separate IPS policies on specific traffic flows. This is done by using virtualized sensor configurations on the AIP-SSM. This example shows how to complete specific policy application on an AIP-SSM which resides inside of an ASA. The same concept can be applied to the new 5585-X platform, which hosts the IPS SSP.



Case Study


Let's say you have two users, Bill and Mary. Bill has been known to download malicious executables via BitTorrent quite often. Last month, he downloaded the latest version of SuperAwesomeFlashGameExtreme, which surreptitiously attempted to test your web server's pages for SQL injection vulnerabilities. Mary is a network security engineer. She can be trusted not to put the network at risk. You would still like to monitor Mary's actions, but not inhibit her work.


Bill_and_Mary_1.png



When the topology above was implemented in your network, sensor virtualization was not considered. You have one virtual sensor (VS) configured on the AIP-SSM, which means that the same IPS policy will be applied to both Bill and Mary. Your configuration is currently as below.


class-map ips_class
   match any
!
policy-map global_policy
  class inspection_default
   inspect ftp
   inspect h323 h225
   inspect h323 ras
   inspect rsh
   inspect rtsp
   inspect esmtp
   inspect sqlnet
   inspect skinny
   inspect sunrpc
   inspect xdmcp
   inspect sip
   inspect netbios
   inspect tftp
  class ips_class
    ips inline fail-open
!
service-policy global_policy global



Revisiting the configuration requirements - you would like to highly restrict Bill's ability to download files via BitTorrent and his computer's ability to execute SQL injection attempts on your company's web server. You would like to monitor Mary's traffic for the same two behaviors, but not carry out any preventative actions as she routinely runs tests that will trigger these events.


Cisco IPS has several signatures that can assist with preventing Bill from wreaking havoc on the network. We will be working with two:


Signature 11020/1: BitTorrent Client Activity - Detects various BitTorrent tracker, payload file transfer, and .torrent download behaviors.

Signature 5930/0: Generic SQL Injection


In order to define your more specific customized policies, we'll need to add Bill and Mary's IP addresses to the diagram:


Bill_and_Mary_2.png


To prepare for our new ASA configuration, which will direct each user's traffic to a different virtual sensor, we'll preemptively create two additional signature-definitions on the IPS. We'll then create two new virtual sensors and assign the respective signature-definitions.


AIP-SSM(config)# service signature-definition sig1
Editing new instance sig1.
AIP-SSM(config-sig)# exit
Apply Changes?[yes]:
AIP-SSM(config)# service signature-definition sig2
Editing new instance sig2.
AIP-SSM(config-sig)# exit
Apply Changes?[yes]:
AIP-SSM(config)# service analysis-engine
AIP-SSM(config-ana)# virtual-sensor vs1
AIP-SSM(config-ana-vir)# signature-definition sig1
AIP-SSM(config-ana-vir)# exit
AIP-SSM(config-ana)# virtual-sensor vs2
AIP-SSM(config-ana-vir)# signature-definition sig2
AIP-SSM(config-ana-vir)# exit
AIP-SSM(config-ana)# exit
Apply Changes?[yes]:
AIP-SSM(config)#



Back on the ASA, we'll work through the steps to configure the appropriate MPF for Bill and Mary specifically.


Step 1: Define the interesting traffic.


access-list BillsTraffic extended permit ip host 10.1.1.3 any
access-list BillsTraffic extended permit ip any host 10.1.1.3

access-list MarysTraffic extended permit ip host 10.1.1.5 any
access-list MarysTraffic extended permit ip any host 10.1.1.5
!
class-map BillsTraffic
  match access-list BillsTraffic
!
class-map MarysTraffic
  match access-list MarysTraffic


Step 2: Define what actions to take with the traffic - We will send each set of traffic to a different virtual sensor.


policy-map global_policy
  class BillsTraffic
   ips inline fail-close sensor vs1
  class MarysTraffic
   ips promiscuous fail-open sensor vs2


Step 3: Move the original ips_class class-map to the bottom of the global_policy so that the new virtual sensors are matched first and all additional traffic falls to the default vs0.


ASA# conf t
ASA(config)# policy-map global_policy
ASA(config-pmap)# no class ips_class
ASA(config-pmap)# class ips_class
ASA(config-pmap-c)# ips inline fail-open sensor vs0



Bill's traffic is now flowing through virtual sensor 1, and Mary's traffic is now flowing through virtual sensor 2. All other traffic is flowing through virtual sensor 0. On the ASA, connections that were pre-existing to a configuration change will continue to experience the same inspection that was configured when they were built. In order to immediately force all of Bill and Mary's traffic through the appropriate virtual sensors, clear their local-host entries on the ASA.


ASA# clear local-host 10.1.1.3
ASA# clear local-host 10.1.1.5



Now, on to satisfying the inspection requirements that we outlined. Note that in Step 2 above, Mary's traffic is being monitored promiscuously and Bill's traffic is being monitored inline. Additionally, should the IPS fail, Bill's traffic will suddenly cease to flow and Mary's traffic will flow through the ASA uninhibited. This configuration is inherently more stringent on Bill's activities than on Mary's. Let's continue to the final step and appropriately configure the signatures in Bill and Mary's respective virtual sensors.


If Bill fires Signature 11020 or 5930 we want to immediately deny the connection before any harm is done. We also want to be notified of his activity.


AIP-SSM(config)# service signature-definition sig1
AIP-SSM(config-sig)# signatures 5930 0
AIP-SSM(config-sig-sig)# engine service-http
AIP-SSM(config-sig-sig-ser)# event-action produce-alert|deny-attacker-victim-pair-inline
AIP-SSM(config-sig-sig-ser)# exit
AIP-SSM(config-sig-sig)# exit
AIP-SSM(config-sig)# signatures 11020 1
AIP-SSM(config-sig-sig)# engine service-http
AIP-SSM(config-sig-sig-ser)# event-action produce-alert|deny-attacker-victim-pair-inline
AIP-SSM(config-sig-sig-ser)# exit
AIP-SSM(config-sig-sig)# exit
AIP-SSM(config-sig)# exit
Apply Changes?[yes]:
AIP-SSM(config)#



If Mary fires either signature, we would like to know about it, but we do not wish to affect her traffic. The default configuration for Signatures 11020 and 5930 already satisfies this requirement.


Note


The singular users, Bill and Mary, were used in this example to specifically describe the application of a signature-definition to a particular flow. Under normal operation, when dealing with single users, or a small subset of users, it is often easier to apply Event Action Filters to exclude some signature actions. In the example above, you could configure both signatures, in a single virtual-sensor, with the produce-alert and deny-attacker-victim-pair-inline actions. You could then configure an Event Action Filter to remove the deny-attacker-victim-pair-inline action for Mary's traffic.

Loading.
prmadan Wed, 06/08/2011 - 16:37
User Badges:
  • Cisco Employee,

Well documented Christopher.

Much appreciated effort.


Prateek

Christopher Dreier Sun, 06/12/2011 - 12:34
User Badges:
  • Silver, 250 points or more

Thank you, Prateek. I hope you found the information useful.


Blayne (Christopher)

Lisa Latour Mon, 07/18/2011 - 23:26
User Badges:
  • Silver, 250 points or more

Blayne, were you able to find a GUI config from this blog post?

Christopher Dreier Tue, 07/19/2011 - 09:58
User Badges:
  • Silver, 250 points or more

Thanks for the bump, Lisa. I missed Rajeswaran's original post. I'll need to cover the GUI steps in a separate post due to the number of screenshots that will be required.


For reference, this configuration can be performed from ASDM/IDM by using the AIP-SSM Startup Wizard or the MPF and signature configuration sections.



Thank you,

Blayne Dreier

Cisco TAC Escalation Team


**Please check out our Podcasts**

TAC Security Show: http://www.cisco.com/go/tacsecuritypodcast

TAC IPS Media Series: https://supportforums.cisco.com/docs/DOC-12758

Bethuelle Tue, 08/16/2011 - 23:55
User Badges:

Hi Blayne,


Please I'll like to know if the ASA doesn't need to be in a multiple contexte mode for this to work.

Christopher Dreier Fri, 08/19/2011 - 13:18
User Badges:
  • Silver, 250 points or more

Hello Damdjo,


The ASA does not need to be in multiple context mode to support traffic redirection to multiple virtual sensors. However, similar configuration is supported in multiple context mode if that is what you prefer.


Thank you,

Blayne Dreier

Cisco TAC Escalation Team


**Please check out our Podcasts**

TAC Security Show: http://www.cisco.com/go/tacsecuritypodcast

TAC IPS Media Series: https://supportforums.cisco.com/docs/DOC-12758

Bethuelle Fri, 08/26/2011 - 03:19
User Badges:

Hello Blayne,


While testing the above set-up on an ASA 5520 in single mode, I used the clear local-host all command and it caused the ASA to reboot. Is that normal?

Actions

This Blog

Related Content