-
Features of the ASA, including the operating system, security algorithm, redundancy, and others
-
The hardware of the ASA product line, including the models, supported hardware modules (cards), and licensing
ASA Features
Cisco’s ASA is a set of stateful security appliances ranging from the model 5505, which is designed for Small Office, Home Office (SOHO) environments, to the 5580, which is designed for large enterprise networks and ISP sites. All of these products use the same operating system and management tools, easing your implementation and monitoring tasks. Because all the security appliances use the same operating system, the major differences between the models primarily concern scalability and performance.
The ASA family of products (and their older siblings, the PIX products) can best be described as hybrid firewalls. Cisco, however, does not like to use the term “firewall” to describe the ASA and PIX product family. Instead, Cisco prefers using the term “security appliance,” mainly because the ASA products and the products they replaced, the PIX products, are not just stateful firewalls; they also support many other security features, including
-
Secure, real-time, proprietary operating system
-
Stateful firewall using the Cisco Security Algorithm (SA)
-
Sequence Number Randomization (SNR) to secure TCP connections
-
Cut-through Proxy (CTP) for authenticating telnet, HTTP, and FTP connections
-
Default security policies to ensure maximum protection, as well as the ability to customize these policies and build your own policies
-
Virtual private network (VPN) abilities: IPSec, SSL, and L2TP
-
Intrusion detection and prevention systems (IDS and IPS)
-
Address translation using dynamic and static network and port address translation
-
Stateful redundancy of connections and VPNs between two security appliances
-
Virtualization of policies using contexts
This is just a small list of some major features of the security appliances. The following sections provide an overview of some of these features. The features that I don’t briefly cover in this chapter are covered in subsequent chapters.
| Note | Throughout the book, whenever the terms “security appliance” or “appliance” are used, they refer to both the ASA and PIX products unless otherwise noted. |
Operating System
The operating system (version 7 and later) you currently see on the ASA appliances and on the PIX 515 and higher appliances is based on the PIX Finesse Operating System (FOS). The FOS is a proprietary, stand-alone operating system. It implements the actual security functions that the security appliance hardware performs. In this sense, it is somewhat similar to the Internetwork Operating System (IOS) of Cisco routers and switches, or what the Microsoft Windows XP or Linux operating systems are to PCs. Cisco no longer uses the term FOS to describe the operating system, though. Starting in version 7 and later, Cisco refers to the security appliance operating system as just the “operating system.”
| Note | Even though Cisco’s PIX appliances are no longer for sale, which Cisco denotes as end-of-sale (EOS), the PIX 515s and higher support the same operating system as the ASAs. The main difference between the PIXs and ASAs is that the lower-end PIX 501 and 506E do not support version 7 and later of the OS, and none of the PIXs supports SSL VPNs. This book focuses on the use of the ASAs; however, the topics discussed can be equally applied to the PIXs in most situations. |
Firewall Applications
Some firewall products run on top of an operating system; these solutions are commonly called firewall applications. One disadvantage that firewall applications have compared with a proprietary operating system is that the firewall vendor must deal with two software products in creating a firewall: the operating system and the firewall application. This process can often lead to a less secure system. This is especially true when you consider all the security threats that have been directed specifically at UNIX and Microsoft operating systems.
An example of a firewall product that uses firewall applications is Check Point. This is not to say that Check Point’s firewall is a worse solution than a firewall product that uses a proprietary operating system. However, a firewall vendor like Check Point will have to do many more things to ensure that the firewall application and operating system provide a secure solution. (Note that Check Point’s next-generation product, SecurePlatform 1, is moving away from this approach and moving toward an integrated solution.)
The main problem with a firewall application solution is that the vendor not only has to provide a secure firewall application, but must also secure the operating system it runs on. However, firewall applications do provide two advantages:
-
They tend to be easy to install and maintain.
-
They run on a wide variety of PC/server platforms.
Proprietary Operating System
Proprietary operating systems provide a security advantage over firewall applications—a proprietary operating system vendor has to be concerned about only one system, instead of two, in providing a secure firewall solution. Another huge advantage of proprietary operating systems is scalability. Because a proprietary operating system can be customized to a specific hardware platform, this firewall system can provide extremely fast packet filtering abilities and security capabilities.
Off-the-shelf operating systems like UNIX and Microsoft Windows are general-purpose operating systems that were developed to perform many tasks, not all of which are performed at an optimal level. Using a general operating system decreases the performance of the packet filtering and firewall functions of the firewall application. To provide for scalability, you must load your firewall application on very expensive server platforms.
Using a proprietary operating system in a firewall solution also makes it much more difficult for hackers to penetrate the firewall. Attackers are familiar with the functions of common operating systems like UNIX and Microsoft products, which makes it a little bit easier for them to attack the firewall application. However, when vendors use a proprietary operating system to implement their firewall solution, an attacker will have little or no knowledge about the functions and processes of the operating system, making it very difficult for the attacker to compromise the firewall solution.
Using a proprietary operating system has some disadvantages. First, because the operating system is proprietary, your security personnel will have to learn the new system. Many of your personnel will already have experience with UNIX or Microsoft Windows, and thus their learning curve in implementing the solution will be shortened.
| Note | When you are using an underlying proprietary operating system such as Cisco’s security appliances, the administrator is unable to interact with the underlying OS. |
Also, because firewall applications are developed for a specific operating system platform like UNIX or Microsoft Windows, your security personnel will already be familiar with the interface that is employed by the firewall. A good example of this is Check Point’s firewall solution—it has a very good, intuitive GUI interface, which makes configuration easy and also reduces the likelihood of making mistakes and opening up unintended holes in your firewall system.
Here are some of the main advantages of using proprietary OSs for firewalls:
-
They tend to be more secure than firewall applications.
-
They provide for better scalability and packet filtering speeds because the operating system is customized directly to work with specific hardware.
ASA Management
Because the security appliances use the same operating system, the configuration of Cisco’s ASAs and PIXs is simplified. You have a choice of three methods to configure your security appliance:
-
Adaptive or Appliance Security Device Manager (ASDM)
-
Cisco Secure Manager (CSM), which is the replacement for the Cisco Works product
The CLI implemented on the security appliances is somewhat similar to Cisco’s IOS-based router CLI. As you will see in later chapters, however, the CLIs of both platforms differ in many ways. The ASDM interface is a Java-based graphical user interface (GUI) tool that allows you to remotely manage a security appliance with a web browser. CSM is a complete management package that allows you to manage the security policies and configurations for Cisco firewalls (ASAs, PIXs, and IOS-based routers), Cisco IPS devices (4200s, AIP-SSM cards, IDMS2 cards, and AIM-IPS cards), Cisco VPN devices (ASAs, PIXs, IOS-based routers, and the 3000 concentrators), and Cisco host IPS implementations (Cisco Security Agent [CSA]).
As you can see, you have many options available to configure your security appliance and to implement your security policies. This book primarily focuses on using the CLI, but Chapter 27 covers the ASDM GUI.
Security Algorithm
One main function the security appliances perform is a stateful firewall. A stateful firewall adds and maintains information about a user’s connection(s). In version 6 and earlier of the operating system, the Adaptive Security Algorithm (ASA) implemented the stateful function of the PIX firewall by maintaining connection information in a state table, referred to as a conn table. When Cisco introduced the ASA hardware platform in version 7, it dropped the term “adaptive” and now just refers to the process that handles the security functions as the “security algorithm.” The security appliances use the conn table to enforce the security policies for users’ connections.
Here is some of the information that a stateful firewall keeps in its state table:
-
Source IP address
-
Destination IP address
-
IP protocol (like TCP or UDP)
-
IP protocol information, such as TCP/UDP port numbers, TCP sequence numbers, and TCP flags
| Note | The security appliances provide a stateful process for TCP and UDP traffic only, by default. Starting in version 7, ICMP can also be treated statefully, but this is disabled by default. |
Stateful Firewall Explanation
Figure 1-1 is a simple example that illustrates the stateful process performed by a stateful firewall. These are the steps shown in Figure 1-1:
-
A user (PC-A) inside your network performs an HTML request to a web server outside your network.
Figure 1-1: A stateful firewall adds a connection to its connection table. -
As the request reaches the stateful firewall, the firewall takes the user’s information, for example, the source and destination address, the IP protocol, and any protocol information (such as the source and destination port numbers for TCP), and places this data in the state or connection table.
-
The firewall forwards the user’s HTTP request to the destination web server.
Figure 1-2 shows the returning traffic from the HTTP server. These are the steps as the traffic returns from the web server:
-
-
-
If a match is found in the connection table, the returning packet(s) are permitted.
-
If a match is not found in the connection table, the returning packet(s) are dropped.
-
Figure 1-2: The stateful firewall checks the returning traffic against the information in the connection table.
A stateful firewall maintains this connection table. If it sees a connection teardown request between the source and destination, the stateful firewall removes the corresponding connection entry. If a connection entry is idle for a period, the entry will time out, and the stateful firewall will remove the connection entry.
Stateful vs. Packet Filtering Firewalls
The example in the previous section shows the difference between a stateful firewall and a packet firewall. A stateful firewall is aware of the connections that pass through it. Packet firewalls, on the other hand, don’t look at the state of connections, but just at the packets themselves.
A good example of a packet filtering firewall is the extended access control lists (ACLs) that Cisco IOS routers use. With these ACLs, the router will look only at the following information in each individual packet:
-
Source IP address
-
Destination IP address
-
IP protocol information, like TCP/UDP port numbers or ICMP message types
At first glance, because the information is the same that a stateful firewall examines, it looks like a packet filtering firewall performs the same functions as a stateful firewall. However, a Cisco IOS router using ACLs doesn’t look at whether this is a connection setup request, an existing connection, or a connection teardown request—it just filters individual packets as they flow through the interface.
| Note | Cisco IOS routers, however, do support two features that implement stateful firewall functions like the security appliances: Context-Based Access Control (CBAC) and its replacement, Zone-Based Firewalls (ZBF). |
Some people might argue that the established keyword with Cisco’s extended ACLs implements the stateful function found in a stateful firewall; however, this keyword only looks for certain TCP flags like FIN, ACK, RST, and others in the TCP segment headers and allows them through. Again, the router is not looking at the state of the connection itself when using extended ACLs, just information found inside the layer 3 and layer 4 headers.
Sequence Number Randomization
The security appliances include a security feature called Sequence Number Randomization (SNR), which is implemented by the security algorithm. SNR is used to protect you against reconnaissance and TCP session hijacking attacks by hackers. One problem with the TCP protocol is that most TCP/IP protocol stacks use a fairly predictable method when using sequence numbers—a sequence number in a TCP segment indicates the number of bytes sent. With many connection types, a hacker can use this information to make predictions concerning the next set of data to be sent, and thus the correct sequence number. Sophisticated hackers will then use this information to hijack the session.
The security appliance’s SNR feature addresses this problem by randomizing the TCP sequence numbers that the TCP/IP application places in the TCP segment header. The security appliance will place the old sequence number as well as the new sequence number in its conn table. As traffic is returned from the destination, through the appliance, back to the source, the appliance looks for this information and changes it back for acknowledgment purposes.
For example, a TCP segment might pass through the security appliance where the sequence number is 578 in the segment, as shown in Figure 1-3. The SNR changes this sequence number to a random number and places it in the state table (992 in this case), and forwards the segment to the destination. The destination is unaware of this change and acknowledges to the source the receipt of the segment, using an acknowledgment number of 993. The appliance, upon receiving the reply, undoes the SNR process by changing the 993 value to 579, so that the source device is not confused. Remember that the TCP acknowledgement process has the destination increase the sequence number by one and uses this as the acknowledgment number.
Cut-through Proxy
As you saw in the previous section, the security algorithm implements many security features of the operating system besides the stateful firewall functions of the appliances. Another security algorithm enhancement is the Cut-through Proxy (CTP) feature. CTP allows the appliances to intercept incoming and/or outgoing connections and authenticate them before they are permitted. CTP is typically used in situations where the end-server the user is connecting to can’t perform authentication itself.
The user connections are not typically authenticated by the appliance itself, but by an external security server, such as the Cisco Secure Access Control Server (CSACS). Cisco supports both the TACACS+ and RADIUS protocols for authentication. The CTP feature on an appliance can authenticate the following connection types:
- FTP
- HTTP and HTTPS
- Telnet
When the security algorithm is configured for CTP, it first authenticates connections before permitting them through the firewall. Figure 1-4 illustrates the steps that occur for CTP:
- User Pong initiates an FTP to 200.200.200.2.
- The appliance intercepts the connection and checks for an entry in its conn table—if the entry exists, the appliance permits the connection (step 4A). In this case, the user has previously been authenticated.
- If the appliance does not find an entry in the conn table, it will prompt the user Pong for a username and a password, and forward this information to the security server for authentication.
Figure 1-4: The basic steps of the Cut-through Proxy feature - The security server examines its internal authentication table for the username and password and what service this user is allowed access to—the security server sends either an allow or deny message to the appliance.
- If the appliance receives an allow message, it adds the user’s connection information to the conn table and permits the connection.
- If the appliance receives a deny message, it drops the user’s connection, or, possibly, reprompts the user for another username/password combination.
-
Once the user has been authenticated, all traffic will be processed by the appliance primarily at layers 3 and 4 of the OSI Reference Model, since the user’s connection is placed in the conn table. This is different from your traditional Application layer proxy, where all traffic, from the authentication phase to the user’s actual data traffic, is processed at layer 7 of the OSI Reference Model. With CTP, the authentication phase is processed at layer 7, but data traffic is, for the most part, processed at layers 3 and 4.
| Note | |
The CTP feature is susceptible to eavesdropping because the username and password are sent across the network in clear text; this can be alleviated by using HTTPS instead of telnet, FTP, or HTTP, since HTTPS uses SSL for encryption. If a hacker happened to be eavesdropping on a clear-text connection while the username and password were being transferred to the appliance, the hacker could use this information to gain unauthorized access to your internal network. You could remove this weakness either by using one-time passwords (OTPs) or by using a smartcard system where the smartcard-generated key is only valid once. Another problem with the CTP process is that the user might have to authenticate twice: once via CTP, and then again at the actual end-server the user is attempting to access. CTP is discussed in Chapter 8.
Policy Implementation
The security algorithm is responsible for implementing and enforcing your security policies. The algorithm uses a tiered hierarchy that allows you to implement multiple levels of security. To accomplish this, each interface on the appliance is assigned a security level number from 0 to 100, where 0 is the least secure and 100 is the most secure. The algorithm uses these security levels to enforce its default policies. For example, the interface connected to the public network should have the lowest security level, whereas the interface connected to the inside network should have the highest security level. Here are the four default security policy rules for traffic as it flows through the appliance:
- Traffic flowing from a higher-level security interface to a lower one is permitted by default.
- Traffic flowing from a lower-level security interface to a higher one is denied by default.
- Traffic flowing from one interface to another with the same security level is denied by default.
- Traffic flowing into and then out of the same interface is denied by default.
Figure 1-5 shows a simple example of what is and is not allowed. In this example, the internal user who initiates a connection to a web server on the Internet is permitted out. Also, the security algorithm adds a connection in its conn table so that the returning traffic from the external web server will be permitted back to the user. Once the user terminates the connection, the entry will be removed from the conn table. At the bottom of Figure 1-5, a user on the Internet is trying to access a web server on the inside of the network. The algorithm rules on the appliance automatically drop this traffic by default.
The rules in the previous list are the default rules. You can create exceptions to these rules for the security algorithm, which generally fall into two categories:
- Allowing access based on a user account
- Allowing access based on a filter
For example, a user from the Internet who is trying to access an FTP server on the inside of your network is by default denied the connection. You could use a couple of methods to open a small hole in the firewall to allow this connection:
- Set up CTP to allow the user’s connection.
- Use an access control list (ACL) to open a temporary hole.
If only a handful of outside users need access to the FTP server, CTP is an excellent method to use. However, if this is a public FTP server where people from the Internet are constantly accessing files in the server, and these people could be anyone in the world, CTP doesn’t provide a scalable solution.
Instead, you can use an ACL to open a temporary hole in the security algorithm to allow FTP traffic to the specific FTP server inside your network. In this sense, you are creating an exception to the appliance’s default security policy, which is to deny all inbound traffic by default. Both of these exception rules are discussed in Chapters 6 (ACLs) and 8 (CTP).
| Note | |
Redundancy
Cisco’s security appliances support two forms of redundancy:
- Type Hardware and stateful failover
- Implementation Active/standby and active/active
Not all appliances support failover. For failover to function properly, you need to meet the following requirements:
- For the PIXs, use a model 515/515E, 525, or 535. For the ASAs, use the ASA 5505 or higher.
- Use identical hardware models and cards running the same version of software.
- Connect the security appliances together with a failover cable.
The following sections will briefly introduce the two types and two implementations of failover. Chapter 23 will cover failover in more depth.
Failover Types
This section will introduce the two types of failover: hardware and stateful failover.
Hardware Failover
With hardware failover, only chassis redundancy is provided: if the primary security appliance in the failover configuration fails, the standby appliance will begin processing traffic. The only item replicated between the two appliances is the configuration used. This type of failover is disruptive for communications that were being transported by the primary appliance because the necessary table information to maintain connections, like the state table, the translation table, and the VPN tables, is not synchronized between the primary and standby appliances. Therefore, this type of failover is not stateful—users have to reestablish their connections when a failover occurs. The top part of Figure 1-6 shows an example of a non-stateful (chassis) failover setup.
Stateful Failover
A stateful failover configuration performs the same functions as a hardware failover—the two main differences are that a stateful failover setup requires a dedicated Fast or Gigabit Ethernet connection between the primary and standby unit, and the state information on the primary is synchronized with the standby across this connection. A LAN connection is used to synchronize the primary’s state, translation, and VPN tables with the standby unit.
As with a chassis failover, the standby unit monitors the primary unit, and when it sees that the primary is not functioning correctly, the standby unit promotes itself to the primary role. When it does this, the cutover should be completely transparent to the users and their connections because the state table on the standby is the same as that on the primary. An example of a stateful failover setup is shown in the bottom part of Figure 1-6.
| Note | |
Failover Implementations
This section will introduce the two failover implementations: active/standby and active/active.
Active/Standby Failover
Up through version 6 of the operating system, only active/standby failover was supported. Both hardware and stateful failover are supported in this configuration. With the active/standby failover implementation, the primary security appliance assumes the active role, and the secondary appliance assumes the standby role. When an appliance is in an active state, it forwards traffic between interfaces; this is not true of the standby unit. An appliance in a standby state only monitors the active unit, waiting for a failover to take place and then cutting over to an active role. These two roles are shown in Figure 1-7.
Active/Active Failover
Starting in version 7 of the operating system, Cisco added a new failover implementation called active/active failover. Both hardware and stateful failover are supported in this configuration. With active/active failover, both security appliances can be processing traffic, basically taking advantage of the money you spent on both appliances as well as the bandwidth of the Ethernet cables connected to them.
Active/active failover is demonstrated in Figure 1-8. Use of active/active failover requires the use of two contexts, commonly called virtual firewalls (contexts are discussed in the “Advanced Features of the Operating System” section). On a security appliance, for one context the appliance will perform the active role, and for the other context the standby role. On the other security appliance, the roles for the two contexts are reversed. Of the appliances that supported failover, only the ASA 5505 doesn’t support the active/active failover implementation, since it doesn’t support contexts.
| Note | The ASA 5505 does not support active/active failover. |
Advanced Features of the Operating System
As I mentioned earlier, Cisco doesn’t use the term “firewall” when referring to the ASAs and PIXs since these products are multifunction security devices. This section will introduce some of the advanced features that will be discussed throughout the book.
Address Translation
Few people realize the importance of the next statement, but the PIX was originally designed as an address translation solution: PIX actually stands for “Private Internet Exchange.” Only later were security features built into the product. Therefore, one of security appliance’s main strengths is its address translation abilities. It can perform the following types of address translation:
- Dynamic network address translation (NAT) and port address translation (PAT)
- Static NAT and PAT
- Identity address translation: commonly referred to as translation exemption or NAT 0
- Policy address translation: controlling when translation should take place based on the source and destination addresses involved
Address translation is discussed in Chapter 5.
Traffic Filtering
ACLs are the most common method of allowing traffic to travel from a lower to higher interface, as well as restricting traffic from a higher to a lower interface. ACLs are made up of two components: creating a list of filtering statements and applying the statements to an interface. To help with the implementation of ACLs, in version 6.2 of the operating system, Cisco introduced a concept called object groups. Basically an object group is a group of objects of a similar type, like IP addresses and network numbers, TCP and/or UDP port numbers, IP protocols, and ICMP message types. You can create an object group and then reference it in a single ACL statement.
For example, if you need to allow web traffic to three different servers, without object groups, you would need three individual ACL statements. Instead, you can create an object group that contains the three addresses, and in a single ACL statement, reference the object group. Object groups thus greatly simplify the maintenance and understanding of ACL policies. ACLs and object groups are discussed in Chapter 6.
Cisco also supports the filtering of HTTP and FTP content, including ActiveX scripts, Java applets, and web URLs. The last is only supported when used in combination with a web proxy server. Currently only Websense and Smartfilter are supported as proxy servers. With a traditional proxy, the user establishes a connection to the proxy, and the proxy connects to the actual destination, requiring the proxy to maintain two connections to transmit the data. With Cisco’s solution, the security appliance passes the URL to the proxy server, the proxy determines whether it is allowed, and the result is passed back to the appliance, which implements the policy. This approach greatly increases throughput and supports more connections since the user’s connection isn’t being proxied in the traditional sense.
Routing and Multicasting
Originally the appliances supported static routing. Starting in version 6 of the operating system, passive RIP and then OSPF were added. With passive RIP, the appliance can learn routes from neighboring RIP routers, but can only pass a default router to other RIP routers. With OSPF, the security appliance is a full functioning OSPF router, having almost all the same abilities as a Cisco IOS router running OSPF.
Starting in version 8 of the operating system, Cisco enhanced the appliance’s RIP implementation to include a full functioning RIP routing process. Cisco also added the support for their proprietary TCP/IP routing protocol, EIGRP.
Prior to version 6.2, the security appliances could not process multicast traffic: only unicast traffic would be transmitted between interfaces. Originally, to solve this problem, a router was placed on each side of the security appliance, and the multicast traffic was tunneled using the GRE TCP/IP protocol, which uses unicasts. The problem with using GRE is that it adds overhead to the transmission process: longer packets and increased delay. Starting in version 6.2, Cisco added some multicast capabilities to the appliances: they can proxy IGMP messages from user devices to an IGMP router, and they can route multicast traffic using static multicast routes or Cisco’s proprietary PIM routing protocol. Routing and multicasting are discussed in more depth in Chapter 4.
IPv6 Traffic
Starting in version 7 of the operating system, IPv6 support was added. Today, you can process both IPv4 and IPv6 on the same interfaces. IPv6 support includes the following features, which are discussed in Chapter 9:
- IPv6 addressing, including dual stacking of IPv4 and IPv6 addresses on interfaces
- Default and static IPv6 routes
- Filtering IPv6 packets
- IPv6 neighbor discovery: static and dynamic
Contexts
Contexts, commonly called virtual firewalls, are a new feature introduced in version 7 of the operating system. Contexts are not the same as a product like VMware, where multiple operating systems and their applications can be running on one device. Instead, contexts allow you to have multiple policies for different groups of people or traffic. When you’re using contexts, all contexts use the same operating system and share the resources of the appliance; however, each context can have its own security policies and its own dedicated or shared resources (RAM, interfaces, and so on). Two common examples where contexts are used include
- Active/active failover implementation: two contexts are needed on the appliance to implement active/active failover.
- Two firewalls, geographically close to each other, with different policies: instead of purchasing two firewalls, purchase a security appliance with two contexts, reducing your overall equipment costs.
Contexts are discussed in more depth in Chapter 22.
Transparent Firewall
Another featured added in version 7 is the transparent firewall feature. Up through version 6, the security appliances were layer 3, or routed, devices; you had to assign IP addresses on the interfaces and route between them. Now you have the option of running your appliance in transparent mode, where it can behave similarly to a layer 2 or transparent bridge or switch. As you will see in Chapter 21, when running in transparent mode, the security appliance will not behave exactly as a true transparent bridge. For example, you can still apply policies on your appliance that allow you to examine the payloads of packets (layer 7 of the OSI Reference Model). Two advantages that transparent mode provides include
-
You can insert a security device into an existing LAN segment or VLAN without having to readdress the devices.
-
The appliance transparently bridged interfaces don’t have IP addresses on them, thus restricting access to the appliance, which greatly reduces the likelihood of an access attack.
Virtual Private Networks (VPNs)
Cisco has supported VPN functionality on the security appliances since version 5 of the operating system. Originally the only VPN solution supported was IPSec, with PPTP and L2TP added later. When version 7 was rolled out, PPTP and L2TP support were discontinued; however, because of customer demand, L2TP support was added back starting in version 7.2. Another major add-on for VPNs in version 7 was SSL VPNs. Cisco’s SSL VPN implementation is WebVPN and supports clientless, thin client, and network client connection methods. Currently only the ASAs support SSL VPNs.
Implementing IPSec is discussed in these chapters:
-
Chapter 15: Configuring IPSec Phase 1 policies and parameters
-
Chapter 16: Configuring IPSec site-to-site connections
-
Chapter 17: Configuring an IPSec remote access (Easy VPN) server
-
Chapter 18: Configuring an ASA 5505 as a remote access client WebVPN is discussed in these chapters:
-
Chapter 19: Implementing clientless mode with WebVPN
-
Chapter 20: Implementing network mode with WebVPN
The configuration of L2TP is not discussed in this book.
Anti-X Capabilities
The Cisco ASA 5500 Series Content Security Edition is provided by the Content Security and Control (CSC) Security Services Modules (SSM), or CSC-SSM for short. The CSC-SSM is technology developed by Trend Micro and integrated into Cisco’s ASA hardware platform. Trend Micro’s technology includes antivirus, antispyware, URL filtering, antiphishing, and antispam. Because of the term “anti” in many of its features, the card is commonly called the Anti-X card. Basically this card allows you to centralize these capabilities and policies on the ASA for small companies that don’t want to manage these technologies on individual user desktops. These cards are managed through the use of ASDM and are not supported on the PIX appliances. The cards are discussed in more depth in Chapter 25.
Intrusion Detection and Prevention Systems
All the security appliances implement a very basic form of intrusion detection and prevention systems (IDS and IPS respectively). The ASAs, however, support a full-blown implementation of IDS/IPS with the add-on Advanced Inspection and Prevention (AIP) SSM modules (AIP-SSM for short). These cards support the full functionality of Cisco’s 4200 series sensors, including the detection and prevention of the following:
- Application and operating system attacks, including web, e-mail, and DNS attacks
- External attacks from hackers
- Internal attacks from disgruntled employees
- Zero-day exploits
- Internet worms (through the use of anomaly detection techniques)
The AIP-SSM cards are discussed in more depth in Chapter 25.
Network Attack Prevention
The security appliances support a handful of network attack prevention features:
- Threat detection
- TCP normalization
-
Connection limits and timeouts
-
IP spoofing prevention
With threat detection, the appliance monitors the rate of dropped packets and security events, which can be caused by matches on ACL deny statements, receiving invalid packets, exceeding connection limits (total connections and TCP connections that don’t complete the initial three-way handshake), detecting denial of service attacks, receiving suspicious ICMP packets, overloading interfaces, detecting a reconnaissance scan, and many other factors. When a threat is detected, a log message is generated.
The TCP normalization feature lets you specify matching criteria that identify abnormal TCP packets, which the security appliance drops when detected. TCP normalization is implemented using the Modular Policy Framework (MPF, discussed in Chapter 10). TCP normalization can identify and prevent inconsistent TCP retransmissions by validating TCP checksums, allowing or dropping TCP segments that exceed the maximum segment size (MSS), limiting the number of out-of-order packets for a connection, dropping SYN segments with data, and handling many other abnormalities with TCP transmissions.
Cisco supports a TCP Intercept feature that allows you to place limits on the number of complete and/or half-open connections. A half-open connection is one that has not completed the initial three-way handshake: SYN, SYN/ACK, and ACK. This feature can be used to defeat or greatly limit the effect of a TCP SYN flood attack.
IP spoofing, where the source address has been changed, can be detected and prevented using ACLs. However, Cisco supports a feature called Reverse Path Forwarding (RPF) that provides a more efficient process, where the appliance does a reverse-route lookup—examines the source address and compares it with the routing table entries—to determine if the source address is coming from an interface it is expected to be connected to.
