Welcome to the 4th article in this series of the CCNA Security Certification exam. As we all know, even though our focus is on the CCNA Security certification, the topics we discuss and the depth we go to here spread across real-world implementations of these technologies. In the last article, we began our discussions on the Cisco ASA and saw how the ASA uses security levels, how the default traffic flows through the ASA and how to override this default behavior using ACLs.

CCNA Training – Resources (Intense)

In this post, we will look at remote management of the ASA, touch a little on NAT and also see how to configure the ASA using a GUI – the ASDM. We will continue using our network diagram from the last post.

Remote Management of the ASA

The ASA can be managed through three methods: Telnet, SSH and HTTPS (via the ASDM). Here, we see another difference between the ASA and IOS devices: remote access is not configured under line settings. In fact, nowhere on the ASA is there a “line vty” configuration. You configure it globally and specify both the IP addresses that are allowed to connect and through what interface they can connect through.

Let’s begin with Telnet. The command is as follows: telnet <source_IP_addr> <source_mask> <source_interface>. One of the ways you can set the telnet password is through the passwd <password> command.

The command shown above can be interpreted as: Allow telnet connection from the subnet 10.0.0.0/24 connecting through the inside interface. We can test this by initiating a telnet session from Inside_Rtr.

Since I have not set an enable password on the ASA, once I telnet in with the password, I only have to enter the “enable” command and hit the Enter key without typing any password and I will be placed in enable mode. This is unlike Cisco IOS devices which refuse enable mode if there is no enable password or enable secret configured. You can enter an enable password on the ASA using the enable password <string> command.

It’s time for another tip. We will configure Telnet on the outside interface allowing Outside_Rtr to telnet in.

Now let’s try to Telnet from Outside_Rtr to the ASA.

That’s right, it will fail. Why? The ASA does NOT allow Telnet from the interface that has the lowest security level (which is the outside in our case).

Now that you know that, let’s continue. We will configure SSH. The same command is used as in telnet but you specify “ssh” instead of “telnet”. I know right: that’s not rocket science. Lol.

If you remember, SSH requires a username and password combination. Before ASA software version 8.4, there was a default username of “pix” or “asa” that can be used with the password configured using the passwd command. From version 8.4 and later however, if you want to use username and password combinations in the local database of the ASA, you must specify those username and password combinations and also tell the ASA to use its local DB for authentication.

As we will see when we get to AAA later in this series, we can specify external authentication servers using TACACS+ or RADIUS. For now, we will limit it to the local database.

Let’s test from Outside_Rtr.

Oops. What went wrong? Let’s check the logs on the ASA.

Yes, you are right- SSH requires that the device has RSA keys for SSH sessions to be terminated.

Remember that SSH version 2 requires a key size of 768 bits and above. Although the ASA supports SSH version 1, version 2 is much more secure.

Now we are in. In configuring SSH, we have also seen how to enable AAA on the security appliance. Let’s take a look at the possible options.

Now for the shocker that I mentioned in the last post: if you use the telnet command to specify who can telnet TO the ASA, what command do you use to telnet FROM the ASA? You cannot initiate a remote session (telnet or SSH) from the ASA! It means if you are on the ASA and maybe you just want to telnet to your upstream router, sorry, you can’t. I guess if you look at it, it’s a form of security mechanism so that if an attacker gains access to the firewall, he won’t be able to hop off the firewall to other devices.

Before we move on to management via ASDM, let’s consider NAT briefly on the ASA. At this moment, when the inside users connect to the outside (and DMZ), their real IP addresses are revealed.

Most of the time, you want to hide the IP addresses of your internal hosts. This is even more important when they are connecting to the Internet since Public IP addresses would be needed for each internal host if NAT is not done. Of course, these are just two applications of NAT and there are more reasons to use NAT. I will not cover NAT in its entirety here but this is just to give you an idea.

What we would like to achieve is this: when inside users connect to the outside, they should appear as having an IP address of 192.168.10.100. If you are familiar with NAT terminology, you know this is PAT since only one address will be shared among the whole subnet.

Like I said, I won’t go into details but only an explanation of the above: I configured a network object-group to match the 10.0.0.0/24 network and specified that when those IP addresses are going from the inside to the outside (inside, outside), then they should appear as an IP address of 192.168.10.100.

You can check the translation on the ASA using the show xlate command as shown below.

Configuring the ASA through the Adaptive Security Device Manager (ASDM)

Before you can configure the ASA through the device manager, there are some settings that must be in place, such as having the ASDM image on your ASA, telling the ASA what ASDM image to use, and allowing HTTPS access by specifying who can connect through what interface and what IP address.

I have altered our network diagram a little by adding a host system to the Gi3 interface of the ASA. We will use this interface for ASDM configuration.

Now let’s login through our host system. Go to the web browser and enter https://<ip-address>/ in the address bar.

You will probably get a certificate error page since the certificate of the ASA was self-generated and is not trusted by your system. If however you are using a trusted certificate, you won’t get this page. I trust it so let’s continue.

There are two options of running the ASDM: either you install the ASDM Launcher on your system or you use the Java Web Start application, which is a run-once kind of application and is not installed on your system. You will be redirected to the Oracle (formerly SUN) site to download Java Web Start if you don’t have it. Let’s go with the first option. We will be asked for our credentials which are checked against the local DB of the ASA based on our configuration.

If your authentication is successful, the dm-launcher.msi file is downloaded. Go ahead and install it. Once the installation is done, you will be presented with a dialog box such as the one shown below:

Once you login, you may be presented with a warning about the certificate error again; just click Continue.

When ASDM is done updating the software, the GUI pops up and it tries to retrieve the most recent configuration on the ASA.

Let’s familiarise ourselves a little with the ASDM interface. In the top left corner, you have tabs like Home, Configuration and Monitoring as shown below:

On the left, you have the Device List. This means you can view and configure more than one ASA device using the ASDM.

The Home display shows a lot of reports and traffic analysis like the Device information, Interface status, VPN sessions, and so on.

You can play around the ASDM to get to know it properly. Now we will focus on the Configuration tab. There are five sub-tabs under this Configuration tab:

  • Device setup: Basic settings of the ASA including interfaces, clock settings and Routing.
  • Firewall: This is where you configure features like NAT, AAA and access rules.
  • Remote Access VPN: Configure VPNs for telecommuters here.
  • Site-to-Site VPN: You can configure VPNs between two networks using this tab
  • Device Management: You use the links under this table to configure things like management access, licensing and system image and configuration.

Let’s take a basic interface configuration and enable interface GigabitEthernet4 with the following settings: name- dmz2, security-level- 40, ip address- 172.17.10.1/24. We do this under Configuration » Device Setup » Interfaces.

You may get a warning about changing the security level of your ASA interface; just continue. Your configuration will look something like below:

Every change you make is still in the ASDM and not yet added to the running configuration of the ASA so you have to remember to click the “Apply” button at the bottom of the screen. If you try to navigate without saving, you will get a dialog similar to the one shown below:

Before we apply our configuration, let’s change a setting first. Go to Tools in the menu bar and select Preferences. I’d like to see the configuration that the ASDM wants to apply to the ASA device. You can select this option as shown in the diagram below:

Check that box, click the OK button and now we can apply our changes.

If you choose to send this configuration, it will be written to the running configuration of the ASA. You may also choose to save the configuration to a file. Once you select ‘Send‘, a dialog box like the one below appears.

Now keep in mind that the configuration you make and send to the ASA device is added to the running configuration and not the start-up configuration, so you must remember to save it. Let’s confirm this.

The ASDM provides different options of places to save the running configuration, one of which is to Flash. This is the one we need to save the running configuration to the start-up configuration. The command is basically “write memory“.

One last thing before we conclude this article on the ASA and with it the first part of the series in Cisco Firewall Technologies. Let’s talk about the Cisco ASDM Packet Tracer. This is a really cool tool (also available on the CLI) that you can use for troubleshooting purposes. It lets you simulate traffic through the ASA and determine if such traffic will be allowed or dropped and also why it will be dropped. It is located under Tools » Packet Tracer.

Let’s do a test. Will HTTP traffic from an IP address on the outside be permitted to 172.16.10.2 on the DMZ? (We know this will be permitted because we configured it in the last article.)

Notice that the interface we select is the source interface – the interface from which the packet is coming from. If you also look at the source port, we are not exactly concerned with that in this case because the device will use a port that is >1024. We click ‘Start‘ and after some seconds of animation (if you didn’t uncheck Show animation), we see the result as shown below.

Let’s simulate one that will be denied and find out why it will be denied. HTTP to 172.16.10.3 will be denied. The great thing about Packet Tracer is that even though there’s no device with that IP address on our network, we can still simulate the traffic.

The equivalent of doing this in the CLI is packet-tracer input outside tcp 192.168.10.2 1025 172.16.10.3 80.

Summary

This brings us to the end of the Cisco Firewall Technologies part of this CCNA Security Certification Exam series. In these posts, we have looked at two firewall technologies from Cisco: The Cisco IOS Zone-based Policy Firewall and the Cisco Adaptive Security Appliance (ASA). While we mostly covered almost all parts of the Cisco IOS ZFW (except deep inspection with parameter maps), we have barely scratched the surface of the Cisco ASA, but this surface is just about enough for the CCNA Security certification prep.

In the next article, we will move to another topic in this series – Securing the control, data, and management plane; Syslog Reporting. Till then, success in your studies.

Reference and Further Reading