AIP-SSM Card & CSC-SSM Card

AIP-SSM Card & CSC-SSM Card

AIP-SSM Card 

The AIP-SSM card, commonly called the IPS card, can look for a variety of attacks against
applications, protocols, operating systems, and networks. However, by default no traffic
is processed by the card: you must set up a policy first. For traffic that should be processed
by the AIP-SSM card, you can configure inline or promiscuous modes.


With inline mode, a matching packet for a policy is forwarded into the card, processed by the card, and returned to the backplane of the ASA for further processing. When the policy is in inline mode, the IPS card can drop packets itself.


In promiscuous mode, a packet matching an IPS policy is copied to the card: the original
packet stays on the backplane of the ASA and is processed further by the ASA. When the
policy is in promiscuous mode, the IPS card itself cannot drop attacks; however, it can
reset TCP connections, and it can log into the ASA and set up a shun (commonly called
a block) to block offending traffic.


Inline mode has the card be proactive, allowing it to drop offending packets, while
promiscuous mode has the card be reactive, where it can’t drop the initial offending
packets. Both have advantages and disadvantages. While traffic matching a policy is in
inline mode, the traffic must go through the card, causing delay; plus if traffic is sent to
the card that exceeds its processing capabilities, the card can be overwhelmed and drop
packets. The upside of promiscuous mode is that if the card is overwhelmed, it doesn’t
affect traffic because the original packets stay on the backplane of the ASA. Plus, you’ll
get a higher Mbps performance rate by using promiscuous mode. However, the problem
with promiscuous mode is that it can’t effectively deal with atomic (single-packet) or
Trojan horse attacks, since its reaction to the attack would typically be too little, too late.


AIP-SSM Configuration After you’ve identified what traffic you want the card to process
with a layer 3/4 class map, you can associate the AIP-SSM policy to it with the following
configuration:
ciscoasa(config)# policy-map policy_map_name
ciscoasa(config-pmap)# class class_map_name
ciscoasa(config-pmap-c)# ips {promiscuous | inline}
{fail-open | fail-close}


First, with the ips command, you must specify the mode of operation—promiscuous
or inline—for the class of traffic. And as with the CSC-SSM card, you can choose from
two options to configure that you can have the ASA perform if the IPS card is not operational:
fail-open or fail-close.


AIP-SSM Example Here’s a simple example that uses an AIP-SSM policy:
ciscoasa(config)# access-list IPSACL1 permit tcp any any
ciscoasa(config)# access-list IDSACL2 permit udp any any
ciscoasa(config)# class-map IPS_map1
ciscoasa(config-cmap)# match access-list IPSACL1
ciscoasa(config)# class-map IDS_map2
ciscoasa(config-cmap)# match access-list IDSACL2
ciscoasa(config)# policy-map outside_policy
ciscoasa(config-pmap)# class IPS_map1
ciscoasa(config-pmap-c)# ips inline fail-open
ciscoasa(config-pmap-c)# exit
ciscoasa(config-pmap)# class IDS_map2
ciscoasa(config-pmap-c)# ips promiscuous fail-open
ciscoasa(config-pmap-c)# exit


In the preceding example, two AIP-SSM policies are configured: TCP traffic is processed
by the IPS card using inline mode, and all UDP traffic is processed using promiscuous
mode.

CSC-SSM Card

The CSC-SSM card, commonly called the Anti-X card, can look for a variety of attacks
as well as set up many policies that apply to FTP, web, and e-mail traffic. However, by
default no traffic is forwarded to the card: you must set up a policy to have traffic processed
by the card. For traffic that should be processed by the CSC-SSM card, the traffic is
forwarded from the backplane of the ASA into the CSC card, processed by the card, and
then forwarded back to the backplane of the ASA for further processing (assuming that
the traffic isn’t dropped by the CSC card because of a policy violation).


It is not recommended to forward other types of traffic, because the card will probably drop these.


CSC-SSM Configuration After you’ve identified what traffic you want the card to process
with a layer 3/4 class map, you can associate the CSC-SSM policy to it with the following
configuration:
ciscoasa(config)# policy-map policy_map_name
ciscoasa(config-pmap)# class class_map_name
ciscoasa(config-pmap-c)# csc {fail-open | fail-close}


The csc command specifies that the specified traffic should be forwarded to the CSCSSM
card for further processing. Options for traffic that should be processed by the card
include


· fail-open If card is not operational, traffic bypasses the policy.
· fail-close If card is not operational, traffic is dropped.


NOTE :- The CSC-SSM card might not be operational because it is dead, missing its operating
system, or is in the process of booting up or rebooting.


CSC-SSM Example Here’s a simple example that will redirect traffic to the CSC-SSM
card:
ciscoasa(config)# access-list CSCACL permit tcp any any eq 80
ciscoasa(config)# access-list CSCACL permit tcp any any eq 443
ciscoasa(config)# access-list CSCACL permit tcp any any eq 25
ciscoasa(config)# access-list CSCACL permit tcp any any eq 110
ciscoasa(config)# class-map CSC_map
ciscoasa(config-cmap)# match access-list CSCACL
ciscoasa(config)# policy-map inside_user_policy
ciscoasa(config-pmap)# class CSC_map
ciscoasa(config-pmap-c)# csc fail-open


In the preceding example, all web (HTTP and HTTPS), SMTP, and POP3 traffic will be
processed by the CSC-SSM card. If the card is not operational, the traffic in the ACL is
allowed to bypass the policy until the card becomes operational again, at which point the
card will process the traffic. This policy allows the users to access the Internet and e-mail
when the card is booting up or rebooting—your security policy will determine if you use
fail-open or fail-close as your card policy.