Update those ASA's guys..

To all of my past ASA students, and even those of you who aren't if you are running 5580's there were several ASA vulnerabilies posted last week. As you know the vulnerabilites have been there since the code shipped, but now the bad guys know about it and can DoS your firewalls with single malformed packets..

http://nvd.nist.gov/download/nvd-rss.xml


Also, some of the latest adobe exploits effect the Mac community now :(. When people tell me that Apple sucks, I generally just laugh internally and don't make an argument, the less people using it the better, as far as security through obscurity is concerned, looks like they are starting to become more of a target unfortunately.

ASA 8.3, Firewall Technology update (another one)

In the new version of code for 8.3, you'll notice a few changes, perhaps most obviously the new memory requirements, the 5520s and 5540's for instance now require 4 GB of ram. Besides the new RAM requirements you'll find the following changes:

Wider support for IE8 (32& 64 / win 7, vista, xp) also officially support 10.6 OSX for SSL VPN.

Licensing is now aggregate, that is if you have 100 SSL VPN licenses on your active, and 100 on standby (this is required, even though only the active can terminate connections) starting with 8.3, your active ASA will support the aggregate (200) number of licenses. If there was ever a failure, and one is shipped back to Cisco, the other will support the aggregate for 30 days. That should be plenty of time to replace your backup.

You'll now use "objects" which is your IP to name mapping (think names). You can now define a server once, Mailserver=192.168.168.50, and put that MailServer in several different ACLs and NAT rules, you can then change the mapping and it will follow within the other portions of the configuration. The goal is to move towards a more object-oriented configuration, so it's simpler to configure things and make changes system-wide.

There is a new technique, where you can do a reverse many-to-one NAT, called one-to-many NAT. The idea is that you can have a single host on the inside, that is now matching multiple IP's on the outside, perhaps two different service providers.

ACLs now use a concept called REAL-IP, the idea of REAL-IP is that when you build that ACL for the outside interface, for server 192.168.168.50 that's being mapped to 50.50.50.50, you would previously think about what the packet looks like when it arrives on the interface. So think, on the outside, the packet is destined for 50.50.50.50 (there's a static NAT to the inside host). Well, now you'll use the REAL-IP, or the actual IP of the box. While frustrating for some of the veteran users, the idea is to make it easier for the new guys coming in. They can now look at access from a higher level, and permit or deny access to a server, or host regardless of thinking about the static NAT configuration.

There is also a concept of global ACLs, if you're familiar with Modular Policy Framework, think of a Policy-map that is applied globally. So the global ACL is that you can permit or deny traffic universally, ignoring the interfaces. This is a concept available on competitors products, so Cisco wanted to support it. The traditional ACL implementation is still supported, the idea though is if you have a lot of interfaces and you want to allow access to a specific host on all of them, you can write that rule in a global ACL and not have to create the same entry on every interface. While some of this seems frustrating for the veterans, the end goal is to make our lives easier.

Smart-call-home (introduced in 8.2.2) dumps stats and config (sanitized) details to Cisco, and you can login and view details about your equipment. You can see if there are TAC advisories for your versions of code, if there are issues you can open a TAC case from there. Another fun aspect is that you're looking at spec's on the box (CPU, Memory, Interface) and can log those periodically so it's great for base-lining and if you have an issue TAC can easily see the history right there.

Upgrading to 8.3 will perform a config-conversion, meaning your CLI configuration will look completely different from how it looked prior to upgrade. There will also be a file in flash that's basically a text file that shows any errors that occured in the upgrade.(I performed an upgrade of a fairly complex configuration without any errors by the way). If you're a CLI user, it will feel like you're on a different planet, if you're an ASDM user, you may not be real sure what's different, as the look, feel,and terminology is almost identical.

Your existing config is backed-up to flash, and there is actually a downgrade command, so if you do hate it you can roll back. *note* if you do use the downgrade command, realize that you must specify the name of the file which you can find in flash. (Similar to the downgrade process that appeared when moving from 6.3 to 7.0).

As you may recall from any of my classes, you can perform a zero-downtime upgrade, by moving one ASA at a time to 8.3 from 8.2 and you can have a fail-over pair on different code, and the 8.3 is no different. This should not be used for a long period of time however, it's recommended that you move one then the other as soon as you can. While they can run side-by-side you may get a copy of the 8.3 config (completely different core commands) pushed on top of the 8.2.

You can upgrade without the memory upgrade, and the code will load, but it throws an error. As you can imagine you will be forfeiting support if you chose to do this, as when you call TAC with a problem, they're going to point this out first :)

ASA Technology Update

ASA Technology Update

For those of you who have taken the ASA course with me in the past (8.0 and earlier) this article will serve as a brief introduction to a few of the new features that Cisco has released recently that I thought you may be interested in. This may also prove helpful to those who have not taken the course but administer or are considering using the Cisco ASA 5500 series firewalls.


SNMP V3
Over the last several years when the topic of Simple Network Management Protocol (SNMP) was discussed by security engineers or auditors, the best practice was said to be disabling it. While this is not always an option due to the loss of functionality from a management perspective, it often proved to be a necessity from a security standpoint due to the lack of encryption of management traffic. While routers and switches have supported this functionality for quite some time it has just recently surfaced on the ASA.

As of version 8.2 of the ASA, SNMP V3 is supported, including support of DES, 3DES, and AES for protection of management data. This is great news to those of you who are required to support SNMP yet also expected to pass annual security audits. The only question that remains is whether or not your monitoring software supports SNMP V3.

Botnet Traffic Filter

Another very exciting feature released in the 8.2 release is the Botnet Traffic Filter. This new technology enables the ASA to monitor both inbound and outbound traffic and compare the external IP addresses and hostnames to a dynamic database of offensive IP addresses and domain names. Essentially, after purchasing the license for this feature (30 day trial available) your firewall gains insight to the latest known locations of botnet control points, SPAM distribution points, and other known hostile hosts.

The Cisco Security Intelligence Operations Group maintains this real-time blacklist. The CSIOG is comprised of hundreds of engineers and researches analyzing terabytes of data each day and building a global correlation rule set. Cisco has leveraged technologies that were originally part of the Ironport product (SenderBase) and is know referring to that technology as SensorBase

Imagine a scenario where a spear-phishing attack is used against an accountant or board-level executive. An attack that incorporates a new 0-day PDF exploit is run, which bypasses your antivirus, and the agent attempts to connect to a control point in Russia. If the control point is hosted in a known hostile net block, the ASA can prevent this connection from establishing and send a notification to the administrator of the attempted communication. This makes for a much happier ending that that of which you’ve been reading in the news stories lately.

AnyConnect Essentials

AnyConnect Essentials is a new licensing option for SSL VPN client on the ASA. With the introduction of SSL VPN, Cisco began charging “per connection fees” for remote VPN connections. This came as a shock to many of you who were accustomed to connecting as many users as the box allowed with IPSec and having never given a thought to licensing. The default WebVPN license on the ASA is 2 concurrent WebVPN users, each additional user requires additional licensing.

The traditional WebVPN licensing is a fairly cost prohibitive option for many of the customers I’ve spoken with, however it was only required if you were using WebVPN. The traditional IPSec VPN connections either site-to-site or remote access worked just as before with no licensing fees. The problem is that Cisco did not release a Windows 7 or a 64-bit windows IPSec client, which means for each remote user that has a 64 bit OS, you will need to have a license for each user if they will be connected to the ASA at the same time.

With the AnyConnect Essentials licensing you can purchase a reduced cost license that allows client-based users to build VPN connections if using the AnyConnect client. In other words, if you want to use the web portal (clientless) or support Cisco Secure Desktop you will need the traditional (more expensive) licenses. If you simply need to those 64bit Windows hosts to connect remotely while using a software client you can purchase the AnyConnect Essentials license (less expensive)

For those of you with Apple hardware running snow leopard (10.6) you will be relieved to know that even though you have a 64bit operating system there is built-in support for Cisco IPSec remote access, so you will not have to purchase any additional licensing or even install additional software as it’s built directly into the operating system (although a bit hidden). Simply add a new network interface, select VPN under interface and select CiscoIPSec under VPN Type. There is no need to launch a 3rd party application as done in the past.


Netflow (8.1)

Technically NetFlow support was introduced in 8.1, however I still consider it a very exciting, and relatively new feature. Also I’ve found that many administrators are not aware of it and it’s something I think you all should be using. As you may already know, Cisco Systems developed NetFlow as a way to export information regarding IP flows for detailed monitoring and auditing of network traffic. A flow is essentially the combination of the following pieces of information

• Source & destination IP address
• Source & destination port number
• IP protocol number
• Ingress interface
• Type of service

I like to compare NetFlow data to the detailed information that my cellular provider gives me each month on my bill. I can see whom I communicated with, how long I communicated to them, the times that the communication took place, and how Iwe communicated (whether it was a phone call or a text message). NetFlow is not a full IPlog or capture of all data, it is simply information about the flows of data. We collect these flows and then build detailed reports and statistics from data such as: when are your peak traffic hours, what are your top protocols, which are your top talkers, who’s moving the most data, which protocols or ports were seen today for the first time(botnet communication detection) etc.

NetFlow data is extremely useful to administrators, not only does it serve into a window of current network conditions, but once archived to a database you can gain insight to how long certain hosts have been communicating (days, weeks years) and how often. If there is a host that has been compromised and we see that it’s been communicating with a command & control point we can do a query against all recorded traffic and determine if other hosts are communicating with that same control point, how long this has been occurring, what data has been leaked etc.

It is my opinion that NetFlow collection could be useful to you, and while the full capabilities of NetFlow would be impossible to cover in this short article, I can only suggest you investigate these capabilities in the future. It may also be helpful to know that the ASA exports in a format called NetFlow V9 (or NetFlow Secure Event Logging). Without going into the differences in the different formats, I wanted to point out that the collector you use (central logging point) must support NetFlow V9. NetFlow V9 is not widely supported, however Plixar has a free product called Scrutinizer, which supports the ASA and NetFlow V9. I’ve used scrutinizer and I’m very happy with the results. Many of you will also be happy to know that Scrutinizer has a free version.

Network visualization with Cisco ASA

I've implemented a lot of Cisco firewalls over the years, and one common thing that was missing was a method of doing external traffic analysis beyond syslog/snmp. Fortunately in recent versions of the ASA code Cisco has added support for Netflow output.

The only catch to this is that is generates Netflow V9 output (v5 is more commonly used). The only missing piece is a netflow collector. I have setup Scrutinizer and so far I'm very pleased.

DNS rewrite on PIX / ASA firewalls, MYSTERY SOLVED!

Ok so DNS Doctoring (aka dns rewrite) on the PIX's and ASA's have stumped me for some time now. I've implemented this a number of times, and sometimes it works flawlessly, other times not at all. Today it all became clear.

First off, what is DNS rewrite? When an internal host makes a query to an external DNS server about an internal resource the IP address returned will be external (see image) . In other words the host making the query is on the same network as the webserver which is Cisco.com. When the user queries a DNS server, for instance Verizon's DNS at 4.2.2.1, the answer returned will be a public IP. If you look at the static DNS mapping, within the ASA's configuration you will see that the public IP is mapped to an internal IP. Well, DNS rewrite monitors DNS traffic, and if a DNS reply contains an IP address that is used in a static statement it will alter the DNS reply to point to the inernal IP( again see image). Therefore, the client connects to the internal resource by it's actual IP address (not the static NAT). Where is the mystery then? Well I have configurd this many times, it's straight foreward, but it doesn't always work.














It turns out that if you are using static PAT, so a single IP address on the outside, doing port forward to different servers on the inside, DNS rewrite simply does not work, it's documented here:
http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a00807968d1.shtml#req

If you have individual IP's for each server it works fine.
This has eluded me for years but became clear today :)