Securing Cisco ASA

• Tweet

• Tweet

Cisco is by far THE most trusted name in networking security; Cisco devices like the PIX and ASA have been securing small and large businesses alike for years. The Cisco ASA in particular is a great addition to the security systems of any budding startup or big business, and a very attractive option to any network professional looking to add a first line of defense to their networking infrastructure.

An ASA, however, is only as good as its configuration, and Cisco’s IOS can be a headache to configure and maintain properly. That said, there are a few basic steps that any network professional might forget or simply not know: these helpful steps can enable you to secure your Cisco ASA more effectively!

(Note: All commands here are to be run in config mode, as per standard Cisco IOS configuration commands)

Disable Telnet / Set Up SSH

transport input ssh
crypto key generate rsa 1024
ssh {ip} {netmask} {inside|outside}

In this example, the code generates a crypto key and enables ssh access to the specified ip / netmask on the specified interface.

Restrict Access

Encrypted communication is certainly a step up from Telnet, but that still leaves vulnerabilities: someone with your password could feasibly log in from their machine or the outside world and wreak havoc with your firewall configuration. To avoid this, when enabling SSH, it’s best to restrict access to only those IP addresses that need it.

This idea is contested by some network administrators, and a common setup for ASAs is to allow access from any IP on the inside interface and disable access from the outside. Many argue this is a safe option because machines on the inside can be trusted, and the convenience of accessing your ASA from any IP on the network outweighs the meager security boost you receive from restricting access only to certain IPs.

To this, I can only respond that you should never trust all the machines on your network. Restrict access to only known static IPs on the inside, and never, ever allow SSH or ASDM access from the outside.

Disallow same-security-inter-interface communication

Unless entirely necessary, disallow same-security-inter-interface communication. In older versions of the Cisco IOS, like on the Cisco PIX, inter-interface communication was permanently disabled; it was enabled in the ASA IOS for special circumstances, like two DMZs. Barring any special circumstances of your own, however, it is best to disable it; your network should be mapped out in such a way that all interfaces have different security levels and traffic flows from higher to lower security interfaces in a logical manner, with ACLs directing traffic the other way around. To disallow:

no same-security-traffic permit inter-interface

Reserve memory for a console session

This isn’t a security feature per-se, but it is very handy to reserve memory for a console session in case your ASA is overloaded; oftentimes it can help attack analysis immensely to have an open console session while your firewall is being bombarded. Too often, network administrators forget that this command even exists. It’s a rare command that’s not often mentioned, and it can sometimes mean the difference between effective forensic defense and downtime while you re-configure the ASA and sort through logs. To reserve memory:

memory reserve console 4096

Disable all unnecessary services

This one may seem like a no-brainer, but there are quite a few services running on your Cisco ASA that you may not even know about, each one a potential security risk (not to mention a resource hog). At a prompt, run “show service summary” and take note of all the services you need to use, and disable the ones you don’t. Take special care to really ensure that you don’t need that service, though; you can save a very great many headaches by doing a bit of research before you switch off something like http. To disable a service:

no service [x]

Prevent IP Spoofing

Make sure to enable reverse route verification; by default, Cisco ASAs do not verify this and as such as vulnerable to IP spoofing. To be perfectly honest, I’m not sure why this isn’t enabled by default, as I can’t think of any out-of-the-box situations that would be aided by not having verification:

ip verify reverse-path interface inside
ip verify reverse-path interface outside

These simple commands tell the ASA to check to make sure the source IP address of each packet checks out against the source IP of the interface in the routing table. This is especially useful for protecting against run-of-the-mill denial of service attacks, as the ASA will simply drop the packets that have a forged source IP.

And there you have it – a few simple tricks that many administrators don’t know / forget. While they seem simple, they are an important step in the baseline configuration of a Cisco ASA and one that new administrators should never forget to implement!