Chapter 12: ASA Modules
Overview
Refer to the following sections for information about these topics:
-
12-1: Initially Configuring an ASA SSM— Explains how to provide a bootstrap configuration so that a Security Services Module (SSM) can be used in an Adaptive Security Appliance (ASA) chassis.
-
12-2: Configuring the CSC SSM— Discusses the steps needed to configure and use a Content Security and Control (CSC) module for content inspection features.
-
12-3: Configuring the AIP SSM— Describes the steps needed to configure and use an Advanced Inspection and Prevention (AIP) module for intrusion protection features.
Most of the ASA platform models offer a Security Services Module (SSM) slot that can be used to house special purpose hardware. Only the ASA 5505 and 5550 do not have an SSM slot. The slot can accept one of the following modules:
-
4GE— The 4-port Gigabit Ethernet SSM offers four 10/100/1000 TX RJ-45 ports, as well as four small form-factor pluggable (SFP) module ports.
-
AIP— The Advanced Inspection and Prevention (AIP) module acts as an in-depth Intrusion Prevention System (IPS) that inspects traffic against an extensive set of IPS signatures to classify and prevent malicious traffic from affecting resources protected by the ASA. The AIP uses the same operating system and signature database as other Cisco IPS appliances.
-
CSC— The Content Security and Control (CSC) module offers advanced content-based inspection that is offloaded from the normal ASA CPU. The CSC can provide anti-virus, anti-spyware, anti-spam, anti-phishing, mail tagging, file blocking, URL blocking and filtering, and content filtering.
The 4GE SSM offers only additional interfaces; it does not perform any advanced processing or inspection. Therefore, after you insert it into an ASA chassis, you can configure its interfaces right away, just as you would the built-in interfaces.
The AIP and CSC SSMs, however, do require additional configuration before they can be used. Each module runs its own operating system and requires a code image. In addition, the ASA that hosts the SSM must be configured to funnel traffic to the SSM for inspection. The necessary configuration steps are covered in the sections within this chapter.
The CSC SSM, in particular, is very dependent upon having connectivity to Trend Micro. The CSC’s management port is used to communicate with the Trend Micro servers over the Internet to download regular content security database updates. Updated databases can be posted at least once a day.
The AIP is also dependent upon periodic updates to its signature database. However, it can download updated files from a local server or client machine.
Both the AIP and CSC modules require a support contract to be maintained as long as they are used, so that they can be kept up-to-date with constantly changing criteria that describes constantly changing exploit schemes.
12-1: Initially Configuring an ASA SSM
When you add an AIP or CSC SSM to an ASA chassis, you need to configure the ASA with some basic features so you can communicate with the SSM. Then, the SSM requires its own configuration to control how it inspects traffic and how it reacts to malicious or undesirable activity.
Each SSM has two communication paths:
-
A 10/100 TX RJ-45 management Ethernet port
-
A backplane connection to the ASA CPU
All SSM configuration is done through the management port. The SSM can be configured through a command-line interface (CLI) or through ASDM, or even through the Cisco Security Manager (CSM) application. In any case, the CLI and Adaptive Security Device Manager (ASDM) interfaces passes configuration information through the SSM’s management port. This is important because administrative access is kept totally separate from the traffic inspection or control path.
Preparing the ASA for SSM Management Traffic
First, the ASA should be configured so that you can use ASDM to configure and monitor the AIP or CSC SSM. You must bootstrap the SSM configuration through its own management interface, but you can do the bulk of your administrative work through ASDM.
Refer to the section “ASDM/PDM Sessions” in Section “4-5: ASDM/PDM Sessions” in Section “Managing Administrative Sessions,” from Chapter 4, “Firewall Management,” for information on configuring ASDM on the ASA.
Next, you should make sure your ASA is configured to use an accurate clock source. The ASA can derive its time and date information from an internal clock or a Network Time Protocol (NTP) server on the network. Using an NTP server is usually more accurate, as the clock is kept up-to-date based on very accurate and redundant sources.
The ASA should have an accurate clock because it can generate time stamps on logging messages, maintain time-based access lists, and validate digital certificates. The CSC and AIP modules should have an accurate clock because they use time stamps and time-oriented operations in their inspection and analysis functions. Time stamps can be important when you gather forensic information about suspicious activity or in an audit trail.
Like the ASA, the CSC and AIP modules each have their own internal clocks, derived from either the ASA’s clock or an external NTP server. If you take time to configure the ASA so that it uses an accurate time source, it only makes sense to keep the CSC or AIP module in sync with the ASA’s clock. In other words, you should need to configure only one clock for both devices.
Refer to Section “10-1: Managing the Firewall Clock,” from Chapter 10, “Firewall Logging,” for complete information on setting the ASA’s clock and configuring it to use an NTP server.
Finally, you need to configure the SSM’s dedicated Ethernet management port so that it can be used to configure the module, download new code images and inspection policy databases, and generate logging messages.
Connecting and Configuring the SSM Management Interface
As soon as the module is installed in the ASA chassis, you need to connect its management port to either of the following:
-
An unprotected VLAN, along with the ASA outside interface
-
An ASA demilitarized zone (DMZ) interface by using a crossover cable or an external switch
The most straightforward way to bring up the management interface is to connect it to the outside or public side of the ASA, as shown in Figure 12-1. This allows the module to communicate with outside resources such as ASDM sessions and Trend Micro servers (CSC module only) directly, without any other firewall configuration or intervention. However, this means the management interface is not protected by the firewall at all. In fact, the Cisco SAFE architecture recommends that the management interface be kept separated or isolated from any user networks.
This also means that untrusted hosts on the Internet might be able to communicate with your SSM management interface, too—something that you might not welcome.
You could also connect the SSM management interface to the same management network used by the ASA management interface. This keeps all of the management traffic isolated from other networks. If your management network is totally isolated from the Internet, this setup will not work because the CSC must have a way to contact the Trend Micro servers over the Internet.
Connecting the SSM management interface to a DMZ, as shown in Figure 12-2, offers the most robust solution. Because the SSM management traffic must pass through the firewall to reach external resources such as Trend Micro servers over the Internet, that traffic is protected by the firewall’s stateful inspection. The firewall can also prevent outside hosts from discovering and attempting to exploit the module.
In the example from Figure 12-2, the ASA interfaces are configured with the following commands:
interface Ethernet0/0
nameif outside
security-level 0
ip address 10.1.1.1 255.255.255.0
!
interface Ethernet0/1
nameif inside
security-level 100
ip address 192.168.100.1 255.255.255.0
!
interface Ethernet0/2
nameif dmz
security-level 50
ip address 192.168.110.1 255.255.255.0
The SSM management interface will eventually be configured with IP address 192.168.110.10. This cannot be done from the ASA configuration because the AIP or CSC maintains its own management interface configuration. However, the ASA does need to be configured to support outbound connections for a CSC module to “call home” to Trend Micro for its updates. This can be done through a dynamic PAT operation, using the following ASA configuration commands:
global (outside) 1 interface
nat (dmz) 1 192.168.110.0 255.255.255.0
Here, the SSM management interface (192.168.110.10) would be translated to the outside interface address (10.1.1.1) during outbound connections. Keep in mind that you need to be able to connect to the SSM management interface to configure and monitor the module. The following ASA configuration commands enable outbound connections from a PC on the inside network toward the SSM on the DMZ network:
global (dmz) 1 interface
nat (inside) 1 192.168.100.0 255.255.255.0
One drawback to the preceding configuration is that you can only manage the SSM from the inside or DMZ networks. This is because dynamic PAT makes the SSM management interface appear as the ASA outside interface from the outside, using a dynamically assigned port number. To manage the module from the outside, the management interface must have a static address translation to an address that is reachable from the outside.
The following ASA configuration commands set up a static NAT so that the SSM appears as outside address 10.1.1.10. As well, an access list is created to permit inbound connections to the SSM management interface. With a CSC, all management connections use TCP port 8443; for an AIP, TCP port 443 would be used instead:
static (dmz,outside) 10.1.1.10 192.168.110.10 netmask 255.255.255.255
!
access-list acl_outside extended permit tcp any host 10.1.1.10 eq 8443
access-group acl_outside in interface outside
At this point, you should also consider whether you will be collecting e-mail or Syslog alerts from the SSM as it performs its functions. The CSC or AIP module itself will be configured in a later step, but the ASA should be configured separately to permit the e-mail or Syslog traffic coming from the SSM management interface address.
As an example, you can use the following ASA configuration commands to permit Syslog messages to the Syslog server located at inside address 192.168.100.15 and e-mail messages to any IP address:
access-list acl_dmz extended permit udp host 192.168.110.10 host 192.168.100.15 eq syslog
access-list acl_dmz extended permit tcp host 192.168.110.10 any eq smtp
access-group acl_dmz in interface dmz
0 comments
Post a Comment