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.
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:
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 MarysTraffic extended permit ip host 10.1.1.5 any |
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.
