NetworkJutsu

Network Security Consulting Services | San Francisco Bay Area

ASA

Securing Cisco ASA SSH server

By Leave a Comment

Last year, I wrote a post about securing the Cisco IOS SSH server. It also makes sense to create one for Cisco ASA especially when my old post about enabling SSH on Cisco ASA was back in 2012. That blog post didn’t include the advanced configurations that will improve the security of the Cisco ASA SSH server. With this post, I’d like to share the minimum advanced SSH configurations that network engineers should consider adding to their ASA template.

Enabling Cisco ASA SSH server

Before we can connect to our Cisco ASA via SSH, we need to have a checklist of things we need to configure.

  1. While it’s a good idea to have enable password configured, it is optional for SSH.
  2. You must have at least one user account locally.
  3. Configure ASA’s authentication method. The authentication method can be local, RADIUS, or TACACS+.
  4. Generate RSA key pair.
  5. Configure ACL to allow a specific IP address or range(s).

Setting enable password

My old post covered how to set enable password. It’s the same command on how to set the enable password, but in the newer ASA software, it uses PBKDF2 to encrypt the password compared to the MD5-based hash in older ASA software.

ASA5506(config)# enable password strongpasswordhere
ASA5506(config)# sh run | i enable password
enable password $sha512$5000$XEBAb1W7gNRdaxFbPHiF6A==$NlSiKyjZpreT3hbRL9gBsg== pbkdf2

Generating RSA keys

As covered in my old post, to enable SSH on the ASA, we’ll need to generate RSA key pair first. Current NIST recommendation is to use 2048-bit or above. In this post, I am going to use 4096-bit key pair.

ASA5506(config)# crypto key generate rsa modulus 4096

SSH Version

Configuring the Cisco ASA SSH server to accept only version 2 is best practice. The reason for this is because SSHv1 has vulnerabilities. That said, make sure to add this to your ASA template.

ASA5506# show ssh 
Idle Timeout: 10 minutes Versions allowed: 1 and 2 
<-- Output omitted --> 

ASA5506# config t 
ASA5506(config)# ssh version 2 
ASA5506(config)# show ssh 
Idle Timeout: 10 minutes Version allowed: 2 
<-- Output omitted -->

SSH Encryption Algorithms

By default, it seems that the ASA’s encryption algorithm is configured to use the medium settings. Unfortunately, I cannot seem to verify it using the show run all command. However, the combination of show ssh and show ssh ciphers does the trick.

ASA5506# show ssh
Idle Timeout: 10 minutes
Versions allowed: 2
Cipher encryption algorithms enabled:	 aes128-cbc   aes192-cbc   aes256-cbc   aes128-ctr   aes192-ctr   aes256-ctr
<-- Output omitted -->

ASA5506# show ssh ciphers
Available SSH Encryption and Integrity Algorithms
Encryption Algorithms:
	all:	 3des-cbc     aes128-cbc   aes192-cbc   aes256-cbc   aes128-ctr   aes192-ctr   aes256-ctr
	low:	 3des-cbc     aes128-cbc   aes192-cbc   aes256-cbc   aes128-ctr   aes192-ctr   aes256-ctr
	medium:	 aes128-cbc   aes192-cbc   aes256-cbc   aes128-ctr   aes192-ctr   aes256-ctr
	fips:	 aes128-cbc   aes256-cbc
	high:	 aes256-cbc   aes256-ctr
<-- Output omitted -->

The client and server negotiate the encryption algorithm. That said, it is possible that the client would pick a weaker cipher. To avoid that, we’re going to specify the use of a safer cipher. According to this thread, the use of EAX or GCM is preferable when available. If not, the use CTR over CBC mode. By specifying the encryption algorithm, we’re telling ASA to only offer the AES-256-CTR mode to any clients that try to connect to it.

Here’s the verbose output of my SSH to a Cisco ASA using the default SSH cipher encryption.

Mac-mini:~ networkjutsu$ ssh -vvv ASA5506
OpenSSH_7.6p1, LibreSSL 2.6.2
<-- Output omitted -->

debug2: ciphers ctos: aes128-cbc,aes192-cbc,aes256-cbc,aes128-ctr,aes192-ctr,aes256-ctr
debug2: ciphers stoc: aes128-cbc,aes192-cbc,aes256-cbc,aes128-ctr,aes192-ctr,aes256-ctr
<-- Output omitted -->

Let’s configure the ASA to only use AES256 CTR mode.

A5506(config)# ssh cipher encryption custom aes256-ctr ASA5506(config)# show ssh Idle Timeout: 10 minutes Version allowed: 2 Cipher encryption algorithms enabled:  aes256-ctr Cipher integrity  algorithms enabled:  hmac-sha1    hmac-sha1-96

Here’s the verbose output of my SSH connection to a Cisco ASA device using the SSH cipher encryption configuration mentioned above.

Mac-mini:~ networkjutsu$ ssh -vvv ASA5506
OpenSSH_7.6p1, LibreSSL 2.6.2
<-- Output omitted -->

debug2: ciphers ctos: aes256-ctr
debug2: ciphers stoc: aes256-ctr
<-- Output omitted -->

SSH Integrity Algorithm

By default, it seems that the ASA’s integrity algorithm is configured to use the medium settings. Unfortunately, I cannot seem to verify it using the show run all command. However, the combination of show ssh and show ssh ciphers does the trick.

ASA5506# show ssh
Idle Timeout: 10 minutes
Version allowed: 2
Cipher encryption algorithms enabled:	 aes256-ctr
Cipher integrity  algorithms enabled:	 hmac-sha1    hmac-sha1-96
<-- Output omitted -->

ASA5506# show ssh ciphers
Available SSH Encryption and Integrity Algorithms
<-- Output omitted -->
Integrity Algorithms:
	all:	 hmac-sha1    hmac-sha1-96 hmac-md5     hmac-md5-96
	low:	 hmac-sha1    hmac-sha1-96 hmac-md5     hmac-md5-96
	medium:	 hmac-sha1    hmac-sha1-96
	fips:	 hmac-sha1
	high:	 hmac-sha1

The default setting for the ASA SSH integrity algorithm is medium. Which means, it will accept both HMAC-SHA1 and HMAC-SHA1-96. The difference between the two algorithms is the digest length. The HMAC-SHA1-96 is a truncated message digest. From my limited understanding, the HMAC-SHA1-96 is the weakened version of HMAC-SHA1 due to the shortened message digest.

Here’s the verbose output of my SSH to a Cisco ASA using the default SSH integrity algorithm.

Mac-mini:~ networkjutsu$ ssh -vvv ASA5506
OpenSSH_7.6p1, LibreSSL 2.6.2
<-- Output omitted -->

debug2: MACs ctos: hmac-sha1,hmac-sha1-96
debug2: MACs stoc: hmac-sha1,hmac-sha1-96
<-- Output omitted -->

Let’s configure the ASA to only use HMAC-SHA1.

ASA5506(config)# ssh cipher integrity custom aes256-ctr
ASA5506(config)# show ssh
Idle Timeout: 10 minutes
Version allowed: 2
Cipher encryption algorithms enabled:	 aes256-ctr
Cipher integrity  algorithms enabled:	 hmac-sha1

Here’s the verbose output of my SSH connection to a Cisco ASA device using the SSH integrity algorithm configuration mentioned above.

Mac-mini:~ networkjutsu$ ssh -vvv ASA5506
OpenSSH_7.6p1, LibreSSL 2.6.2
<-- Output omitted -->

debug2: MACs ctos: hmac-sha1,hmac-sha1-96
debug2: MACs stoc: hmac-sha1,hmac-sha1-96
<-- Output omitted -->

SSH Key Exchange

The ASA support two Diffie-Hellman key exchange methods and these are DH Group 1 (768-bit) and DH Group 14 (2048-bit). By default, the ASA is set to use Diffie-Hellman Group 1. Unfortunately, this is below what NIST recommends to use in this day and age.

Here’s a Cisco ASA with default SSH key exchange configuration. I issued the no ssh key-exchange to be sure.

ASA5506(config)# no ssh key-exchange
ASA5506(config)# sh run all | i ssh key-exchange
ssh key-exchange group dh-group1-sha1

Here’s the verbose output of my SSH connection to a Cisco ASA using the default SSH key exchange.

Mac-mini:~ networkjutsu$ ssh -vvv ASA5506
OpenSSH_7.6p1, LibreSSL 2.6.2
<-- Output omitted -->
debug1: kex: algorithm: diffie-hellman-group1-sha1
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: aes256-ctr MAC: hmac-sha1 compression: none
debug1: kex: client->server cipher: aes256-ctr MAC: hmac-sha1 compression: none
<-- Output omitted -->

Let’s configure the ASA to use DH Group 14.

ASA5506(config)# ssh key-exchange group dh-group14-sha1

Here’s the verbose output of my SSH connection to the Cisco ASA after changing the key exchange method.

Mac-mini:~ networkjutsu$ ssh -vvv ASA5506
OpenSSH_7.6p1, LibreSSL 2.6.2
<-- Output omitted -->
debug1: kex: algorithm: diffie-hellman-group14-sha1
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: aes256-ctr MAC: hmac-sha1 compression: none
debug1: kex: client->server cipher: aes256-ctr MAC: hmac-sha1 compression: none
<-- Output omitted -->

SSH ACL

Restricting remote management to a certain IP address is a best practice. It is also required to add the ACL, or we won’t be able to access the Cisco ASA via SSH. That said, I included the command here.

ssh 192.168.1.0 255.255.255.0 management

Final Words

All of the configurations covered here are what I’d say minimum security standard for all Cisco ASA devices. It is, after all, a network security device, so it is a must to secure it properly. Though this post is just a small part of protecting the management plane and network engineers must incorporate other security configurations.

Are you ready to improve your network security?

Let us answer more questions by contacting us. We’re here to listen and provide solutions that are right for you.

ENGAGE US

NetworkJutsu provides networking and network security consulting services for startups, a more established small and medium-sized business (SMB), or large business throughout the San Francisco Bay Area.

Want to learn more about ASA?

Cisco ASA: All-in-one Next-Generation Firewall, IPS, and VPN Services (3rd Edition)
Cisco ASA for Accidental Administrators: An Illustrated Step-by-Step ASA Learning and Configuration Guide

Disclosure

NetworkJutsu.com is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.com.

Enabling AAA on Cisco ASA

By 7 Comments

Enabling AAA on Cisco routers and switches were covered a while back in this guide. As previously mentioned, I am quite new to Cisco ASAs since my old environment was pure routing and switching. Firewalls were handled by IT Security and the firewalls weren’t ASAs. Having said all of that, I enjoy playing with ASAs whenever I get a chance. A couple of days ago, I started teaching myself using the CLI since I’ve always used the ASDM for making changes. I occasionally use the CLI, but not heavily since I am still a newbie in using ASAs. If you are in the same situation as I am, one of the books that are very helpful for non-full time network security engineer is Cisco ASA for Accidental Administrators: An Illustrated Step-by-Step ASA Learning and Configuration Guide. I have no experience with this book so please read through the reviews to make sure it is the one you need.

As I was teaching myself on how to configure an ASA from scratch using CLI, I decided to play around with AAA since I need to get our production ASAs to communicate to our TACACS+ server anyway. After playing around with it and reading the AAA section of Cisco ASA: All-in-One Firewall, IPS, Anti-X, and VPN Adaptive Security Appliance, I came up with a configuration that will be our standard when building ASAs.

Related: How to configure tac_plus (TACACS+ daemon) on Ubuntu Server

Without further delay, here are the steps to enable AAA on ASA using CLI:

This command enables the TACACS+ protocol and use the name TACACS+ as the AAA server group.

ciscoasa (config)# aaa-server TACACS+ protocol tacacs+

To specify the maximum number of failures that will be allowed for any server in the group before that server is deactivated. The default value is three.

aaa-server TACACS+ max-failed-attempts 3

There are two different AAA server reactivation modes in ASA: timed mode and depletion mode. The command below is the timed mode. With the timed mode, it reactivates a failed server after 30 seconds of downtime. In my limited testing, it continuously tried to reactivate the server after 30 seconds when I bring the TACACS+ server down.

ciscoasa(config-aaa-server-group)# reactivation-mode timed

With the depletion mode shown below, the failed TACACS+ server will stay down until all servers in the group are in the failed state. The default deadtime is 10 minutes.

ciscoasa(config-aaa-server-group)# reactivation-mode depletion

To check the status of the TACACS+ server on a particular ASA.

ciscoasa# show aaa-server proto tacacs | i status
Server status:   FAILED, Server disabled at 15:15:52 UTC Wed Mar 5 2012
Server status:   FAILED, Server disabled at 15:15:52 UTC Wed Mar 5 2012

This command specifies the TACACS+ server’s IP address. If you notice there’s a (inside) keyword in the command. This basically tells the ASA which interface to send the TACACS+ traffic. If the TACACS+ server is actually on the outside interface, then you just change it to outside. In this scenario, the TACACS+ is part of the inside network.

aaa-server TACACS+ (inside) host 192.168.100.200 tacacs-key timeout 3
aaa-server TACACS+ (inside) host 192.168.100.201 tacacs-key timeout 3

By issuing this command, it instructs the ASA to use the user’s enable password stored in the TACACS+ server first and then use the local enable password as a backup if the TACACS+ servers are unavailable.

aaa authentication enable console TACACS+ LOCAL

Don’t get confused with the keyword console and serial console. The serial is the actual physical console port in the ASA. If you do not issue this command, ASA will use the user local user database for authentication. Same thing as above, if TACACS+ is available then it will always use the stored account on the server before using the local account.

aaa authentication serial console TACACS+ LOCAL

This is a good idea to enable if you want to manage your ASA using ASDM. Same thing as above, if TACACS+ is available then it will always use the stored account on the server before using the local account.

aaa authentication http console TACACS+ LOCAL

This is for managing your ASA using SSH. Same thing as above, if TACACS+ is available then it will always use the stored account on the server before using the local account. If you want to manage your ASA using telnet, just change the ssh keyword to telnet. I honestly do not recommend using telnet.

aaa authentication ssh console TACACS+ LOCAL

Once the authentication part is finished, now you need to enable the authorization. This tells the ASA what commands are available for the authenticated user. To enable authorization, issue the command below. Again, if TACACS+ is available then it will always use the stored account on the server before using the local account.

aaa authorization command TACACS+ LOCAL

Once done with the authorization, you may want to monitor the commands that have been issued in the ASA. To enable accounting, issue the command below. This command will only monitor issued commands that are listed in the privilege level 15. If you want to monitor all commands, feel free to change the level to 1.

aaa accounting command privilege 15 TACACS+

There you have it, a step by step guide on how to enable AAA on Cisco ASAs. There’s no good reason to not enable AAA especially if you can get the TACACS+ server for free!

I hope this has been helpful and thank you for reading!

Are you ready to improve your network security?

Let us answer more questions by contacting us. We’re here to listen and provide solutions that are right for you.

ENGAGE US

Related blog posts:

How to build and configure tac_plus
TACACS+ (tac_plus daemon) ACL

Reference

Cisco ASA: All-in-One Firewall, IPS, Anti-X, and VPN Adaptive Security Appliance

Want to learn more about ASA?

Cisco ASA: All-in-one Next-Generation Firewall, IPS, and VPN Services (3rd Edition)
Cisco ASA for Accidental Administrators: An Illustrated Step-by-Step ASA Learning and Configuration Guide

Disclosure

NetworkJutsu.com is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.com.

Enabling SSH on Cisco ASA

By Leave a Comment

Update: Securing Cisco ASA SSH server

Enabling SSH has been covered here but it only talked about routers and switches. How about Cisco ASA? Today, I had to learn how to do it using CLI and not ASDM since I couldn’t find where the equivalent of aaa authentication ssh console LOCAL and crypto key gen rsa mod 4096  in the ASDM. Since I am really new to Cisco ASA, I am not well-versed in issuing commands under CLI. If you are in a similar situation, I suggest to buy this book. Having said that, I’ve always used ASDM when checking out rules, NATs, and etc but I can understand some of the CLI config. Without further ado, here’s how to enable SSH on a Cisco ASA.

ASA-5505# conf t
ASA-5505 (config)# enable password password_here encrypted
ASA-5505 (config)# username user_here password password_here encrypted privilege 15
ASA-5505 (config)# aaa authentication ssh console LOCAL
ASA-5505 (config)# ssh 192.168.0.10 255.255.255.0 inside
! Obviously, you can add/change IPs that you want to allow SSH from.
ASA-5505 (config)# domain-name networkjutsu.com
ASA-5505 (config)# crypto key gen rsa mod 4096
ASA-5505 (config)# ssh version 2
ASA-5505 (config)# ssh key-exchange group dh-group14-sha1

As you know, it is a good idea to enable SSH and disable Telnet. Since ASA does not enable SSH and/or Telnet by default, you have less to worry about. But if you have to choose between them, of course pick the SSH.

I hope this has been helpful and thank you for reading!

Are you ready to improve your network security?

Let us answer more questions by contacting us. We’re here to listen and provide solutions that are right for you.

ENGAGE US

Want to learn more about ASA?

Cisco ASA: All-in-one Next-Generation Firewall, IPS, and VPN Services (3rd Edition)
Cisco ASA for Accidental Administrators: An Illustrated Step-by-Step ASA Learning and Configuration Guide

Disclosure

NetworkJutsu.com is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.com.