Although Cisco created a new series of ASA appliances (5500-X series), there are hundreds of thousands of older Cisco ASA 5500 models installed and working in networks all over the world.

If you are one of those professionals who are considering to upgrade your older ASA5500 appliances with the new “X” models, I have prepared a comparison article for you with the most important similarities and differences between the two ASA generations.

First, let’s see what Cisco recommends as replacement models for the older ASA5500:

Next let’s discuss the similarities between the two ASA generations.

Similarities

The major similarity between ASA5500 and ASA5500-X generation is on core firewall functionality and configuration. That is, the major firewall features (NAT, Access Control Lists, VPN configuration, routing, failover configuration, traffic inspection, modular policies, file system management, VLAN and subinterfaces, authentication etc) are configured exactly the same on both ASA5500 and ASA5500-X models. In fact, the new software version 9.X runs on both ASA series.

So, if you have an existing ASA5500 model which works as a regular firewall and you don’t need any new fancy features (called “Next Generation Firewall” features) then you can stay with your current model for now. You should consider though that Cisco has announced the End-of-Sale for the 5500 models which is September 16, 2013. The last date of support for the 5500 generation is September 30, 2018.

Differences

Of course with every new generation of appliances, almost always the new models are improved in terms of both hardware and software capabilities. Let’s see the major differences in bullet form.

• The new 5500-X models provide around 4 times more firewall throughput than the older 5500 models. Also, they offer 60% higher VPN throughput.
• The new 5500-X are running on multicore 64-bit processors compared with single core 32-bit processors on older ASA models.
• The new 5500-X models support Next-Generation Firewall Services either as cloud-based services (such as Cloud Web Security and Web Security Essentials) or as software based modules which do not need additional hardware (only a license to use the software module). You should note however that the “Next-Generation Firewall Services” cost extra money in addition to the core firewall appliance. You will either need to purchase Cloud Subscription or purchase software licenses (for the IPS software module for example).
• For Intrusion Prevention functionality (IPS) you don’t need an additional hardware module like the older 5500 generation. You can enable an embedded IPS on any 5500-X model by purchasing a software license.
• More network interfaces available on the 5500-X models (up to 14 Gigabit Ethernet ports).
• On ASA5500-X models the management interface port is shared between the Firewall and the embedded IPS module. Also, the management port on ASA5500-X cannot be used as a data port. Remember that on the older 5500 models you could use the management port as a data port as well (as a regular interface). This is not supported on 5500-X models. Management port is only for management of the appliance.

These are the main differences between the two ASA generations. My new ebook which I’m working on right now (“Cisco ASA Firewall Fundamentals-3^rd Edition”) will be applicable for both ASA5500 and ASA5500-X (regarding the core firewall functionality of the appliances), and will cover also the newest ASA version 9.X.

I hope you found my article useful. Talk to you soon.

Harris Andrea

With the expansion of Cisco ASA models and the addition of new types of devices, it is inevitable to have also a confusion about which software version is supported for each model. A few years ago we had only the Cisco PIX series which were replaced by the successful Cisco ASA 5500 series firewalls. Now we have also the next generation 5500-X series and also we have ASA running on 6500 as service module and also the ASA 1000V cloud firewall. Each type has its own software version as shown below:

Denial of Service attacks (DoS) are very common these days. Especially Distributed DoS attacks (called also DDoS) can be executed quite easily by attackers who own large networks of BotNets. Thousands of malware-infected computers (which comprise the so called “BotNets”) are controlled by attackers and can be instructed to start attacks at any target.

Usually WebSites are targeted more frequently. Bringing down a website can have a negative effect to the image (in addition to any financial loss) of the company owing the site. A DDoS attack can be purely “volumetric”, which means that the attacker just sends high volume of packets as quickly as possible to flood the bandwidth of the “pipe” connecting the website to the Internet. Also, DDoS attacks can be “Application Resource Exhaustion” which means that the attacking computers create thousands of application requests (e.g HTTP Requests) to a server, thus consuming the application resources.

A Cisco ASA Firewall can not help much in a “volumetric” DDoS attack. In such an attack, a dedicated DDoS device is needed or your ISP must do some kind of rate limiting to mitigate the attack. However, for “Application Exhaustion” attacks a Cisco ASA can help to some extend with HTTP inspection using the Modular Policy Framework mechanism of ASA. This is what we are going to describe in this article.

Usually, HTTP Application DDoS attacks have a pattern or string which helps you distinguish the attacking HTTP requests from other legitimate requests. For example, HTTP attacking packets might have a common parameter or string, which can be for example the same “User-Agent” used by the attacking script, a common POST or GET URI request, some other HTTP header parameters etc. With the ASA HTTP inspection feature you can match on this common pattern in the HTTP packet thus filter-out the attacking packets and drop them.

Recently I was engaged to help mitigate a DDoS attack on a webserver. I observed from the Apache logs that the attacking HTTP requests were all targeting the website on the same URL string, such as http://www.website.com/xyz123.  The string “xyz123” was the common pattern for all malicious HTTP requests. Thus with a policy on ASA you can match on the unique string above and drop the packets that have this string in the HTTP URI.

Lets see a diagram and configuration below:

ASA Configuration:

!First create a regular expression with the unique attack string
regex attackstring xyz123

!Create an ACL to match the HTTP traffic towards the target server
access-list HTTPTRAFFIC extended permit tcp any host 1.1.1.1 eq www

!Create a regular L3/L4 class to match the traffic above
class-map attackingtraffic
 match access-list HTTPTRAFFIC

!Now create an HTTP inspection policy to match on the unique attacking string
policy-map type inspect http HTTPDOS
 parameters
 match request uri regex attackstring
  drop-connection
 match request args regex attackstring
  drop-connection

!The following policy-map will include the L3/L4 class which will include the HTTP inspection policy
policy-map BLOCKDOS
 class attackingtraffic
  inspect http HTTPDOS

!Now attach the policy-map to the ASA outside interface to inspect Inbound traffic.
service-policy BLOCKDOS interface outside

If you enable logging on the drop-connection command (use “drop-connection log“), then you will start seeing logs that the ASA is dropping packets with the matched attacking HTTP string.

One of the ways to configure authentication between two Cisco ASA firewalls having a site-to-site IPSec VPN tunnel between them is to configure a pre-shared key under the tunnel group attributes. This is actually the most common implementation of IPSEC lan-to-lan authentication that you will find in most real life networks.

The pre-shared key must be the same on both IPSEC VPN devices between which the secure tunnel is created. To configure the pre-shared key on a Cisco ASA:

tunnel-group 1.1.1.1 type ipsec-l2l
tunnel-group 1.1.1.1 ipsec-attributes
pre-shared-key key123

Now, after configuring the pre-shared key, it is stored as encrypted hash on the ASA appliance and therefore when you view the running configuration (show run) you don’t see the actual clear text key anymore (i.e instead of “key123” you will see “*”).

Ciscoasa# show run

tunnel-group 1.1.1.1 type ipsec-l2l
tunnel-group 1.1.1.1 ipsec-attributes
pre-shared-key *

The problem arises when you forget the pre-shared key after a few months and you want to change one of the VPN tunnels. This situation happened to me recently when I had to change the public IP address on one of the ASA sites which had a Lan-to-Lan tunnel with a second ASA. Therefore I had to reconfigure the tunnel group and re-enter the old pre-shared key. However, I did not have it stored in clear text anywhere. The way to recover the pre-shared key is actually simple. Use the more system:running-config command. This command shows the pre-shared key in clear text format:

Ciscoasa# more system:running-config

…..
…..
tunnel-group 1.1.1.1 ipsec-attributes
pre-shared-key key123

Cisco ASA supports two major WebVPN modes: Clientless WebVPN and Anyconnect WebVPN.

Let’s see the differences between the two WebVPN modes and I’m sure you will understand why the AnyConnect mode is much better in my opinion.

Clientless WebVPN does not require any VPN client to be installed on user’s computer. It uses a normal web browser. By pointing the browser to https://[outside address of ASA] the user authenticates with the firewall and gets access to a Web Portal. Through this Web Portal, the user can then access a limited number of internal applications. Specifically, only internal Web applications (HTTP, HTTPs), email servers (POP3, SMTP, IMAP), Windows file shares and a small number of TCP legacy applications (e.g Telnet) can be accessed. That is, there is no full network connectivity with Clientless WebVPN.