Cisco ASA – How to View pre-shared keys in plain text

As engineers, you don’t always document things as well as we should OR someone you work with is always “too busy” to document their work. This little trick will show you how to recover pre-shared keys on a Cisco Pix or ASA firewall.

Normally, you use the ’show run’ command to view the running configuration. Pre-shared keys are marked with an asterisk (*). To view the password unencrypted, type ‘more system:running-config’. This will display the full configuration with unencrypted passwords.

To bad actually that the pre-shared key of an Cisco VPN Client doesn’t show up in the latest ASA software version 8.2.2. the pre-shared keys of the VPN Tunnels are showed.

Error: The VPN client agent was unable to create the interprocess communication depot.

When attempting to install the Cisco AnyConnect client for UI Anywhere access, you receive the following error message:

The VPN client agent was unable to create the interprocess communication depot.

To resolve this issue:

  1. Click the Start button.
  2. Click on Control Panel.
  3. Click on View Network Status and Tasks.
  4. Click on Change Adapter Settings.
  5. Right-click the shared connection and choose Properties
  6. Click the Sharing tab
  7. Clear the Allow other network users to connect through this computer’s Internet connection checkbox
  8. Click OK.

Traceroute Through the ASA

The Cisco ASA has some interesting characteristics when dealing with traceroute.  With most traffic, including ICMP echo, outbound traffic can be inspected to allow the incoming traffic associated with the same flow.  Inspecting “ICMP” or even “ICMP Error” does not result in traceroute functioning through the ASA.

The first thing that we need to look at is how traceroute works.  Traceroute uses two different types of ICMP packets.  Windows systems use an ICMP with incrementing TTL’s to illicit an ICMP TTL exceeded message from each hop along the way.  Linux and Cisco use a UDP port with pseudorandom destination port.  With the UDP method, an incrementing TTL is still used to illicit a message from each hop along the way.  However, the message that is produced is an “ICMP unreachable port-unreachable” message.

To understand how traceroute works, it is important to understand the function of the TTL field in the IP packet header.  This field is an 8 bit value that works with routers to keep packets from looping forever as a result of network configuration issues.  The way this is accomplished is that each router along the way decreases the value by 1.  Normal traffic may start out with a TTL of 64, 128, 255 or any other non-zero value.  As the traffic traverses a router, this TTL in the IP header is reduced by one.

When a router decreases the value to zero, it drops the packet.  When this happens the device will respond with an “ICMP TTL exceeded” if it is in response to an ICMP packet.  If it is in response to a TCP or UDP packet, it will respond with an “ICMP Unreachable Port-Unreachable”.  It is worth noting that the device can usually be configured to not respond at all.

Traceroute takes advantage of this behavior and generates a series of packets.  The first packet(s) will have a TTL of one and be dropped by the first router.  The next packet(s) will have a TTL of two and be dropped by the second router.   This is used to build a map of the network.  If there is a device configured not to respond traceroute will indicate the presence of a device, but its IP address will not be identified.

With our default ASA configuration, let’s see if traceroute will work.

Windows PC

C:\Documents and Settings\paul>tracert -d www.google.com

Tracing route to google.navigation.opendns.com [208.69.36.231]
over a maximum of 30 hops:

  1     *        *        *     Request timed out.
  2     *        *        *     Request timed out.
  3     *        *        *     Request timed out.
  4     *        *        *     Request timed out.
  5     *        *        *     Request timed out.
  6     *        *        *     Request timed out.
  7     *        *        *     Request timed out.
  8     *        *        *     Request timed out.
  9     *        *        *     Request timed out.
 10     *        *        *     Request timed out.
 11     *        *        *     Request timed out.
 12     *        *        *     Request timed out.
 13     *        *        *     Request timed out.
 14    16 ms    24 ms     7 ms  208.69.36.231

Trace complete.

As we can see, there is no intermediary information.  So we know that we are not receiving the ttl exceeded messages from the routers in the network.  The ASA requires special configuration to permit the traffic.  The first challenge is to permit these TTL exceeded and port unreachables back into the network.  This can be done only by using an ACL bound to the outside interface.

ASA Config

//create an ACL that permits the incoming ICMP
access-list outside_access_in remark ICMP type 11 for Windows Traceroute
access-list outside_access_in extended permit icmp any any time-exceeded
access-list outside_access_in remark ICMP type 3 for Cisco and Linux
access-list outside_access_in extended permit icmp any any unreachable

//bind the ACL to the outside interface
access-group outside_access_in in interface outside

Now let’s test traceroute again.

Windows PC

C:\Documents and Settings\paul>tracert -d www.google.com
Tracing route to google.navigation.opendns.com [208.69.36.230]
over a maximum of 30 hops:

  1     3 ms     3 ms     4 ms  71.30.192.1 <— Not My ASA
  2     3 ms     6 ms     3 ms  151.213.31.168
  3     4 ms     3 ms     4 ms  75.90.222.23
  4     4 ms     4 ms    15 ms  75.90.222.25
  5     6 ms     6 ms     5 ms  151.213.254.36
  6     7 ms    10 ms     7 ms  12.118.104.17
  7     7 ms     7 ms     5 ms  12.122.132.98
  8    36 ms     8 ms    28 ms  12.123.7.250
  9    10 ms     6 ms     6 ms  12.122.132.17
 10    26 ms    10 ms    14 ms  192.205.33.194
 11    27 ms    18 ms    12 ms  154.54.3.242
 12    26 ms    14 ms    11 ms  38.112.35.122
 13     8 ms     9 ms     6 ms  38.104.102.62
 14     7 ms     7 ms     6 ms  208.69.36.230

Trace complete.

Now that looks much better.  However, I can see that my ASA is not listed in the path.  That is very strange.  Upon investigation, I determine that the ASA itself does not decrease the TTL as it passes traffic.  Firewalls often play by slightly different rules than a router and this is one of those exceptions.  However, we can change this behavior using the set connection option in the modular policy framework (MPF).

ASA Config

ciscoasa(config)# policy-map global_policy
ciscoasa(config-pmap)# class class-default
ciscoasa(config-pmap-c)# set connection decrement-ttl

Now, let’s test traceroute again.

Windows PC

C:\Documents and Settings\paul>tracert -d www.google.com

Tracing route to google.navigation.opendns.com [208.69.36.231]
over a maximum of 30 hops:

  1     1 ms     *        1 ms  75.117.163.238 <— My ASA
  2     3 ms     3 ms     4 ms  71.30.192.1
  3     8 ms     3 ms     3 ms  151.213.31.170
  4    47 ms    31 ms     4 ms  75.90.222.23
  5    94 ms     4 ms     8 ms  75.90.222.25
  6     5 ms     4 ms     6 ms  151.213.254.36
  7    18 ms     5 ms     6 ms  12.118.104.17
  8     9 ms     6 ms     5 ms  12.122.133.98
  9     7 ms     7 ms     8 ms  12.123.7.110
 10     7 ms     6 ms    32 ms  12.122.133.13
 11    11 ms    11 ms    22 ms  192.205.33.194
 12    59 ms    48 ms    36 ms  154.54.3.234
 13    15 ms    12 ms    13 ms  38.112.35.122
 14    13 ms     5 ms    17 ms  38.104.102.62
 15     8 ms     6 ms     5 ms  208.69.36.231

Trace complete.

We can now see an extra hop (75.117.163.238 is an address on my ASA), but there are missing statistics (see the *). This is a result of the fact that the ASA is not responding to all of the traceroute packets.  This is due to the rate-limiting of ICMP on the ASA.  We can adjust this as well.

ASA Config

ciscoasa(config)# icmp unreachable rate-limit 10 burst-size 5

Now let’s test this one more time.

Windows PC

C:\Documents and Settings\paul>tracert -d www.google.com

Tracing route to google.navigation.opendns.com [208.69.36.230]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  75.117.163.238 <— My ASA
  2     6 ms     5 ms     4 ms  75.117.160.1
  3     5 ms     5 ms     4 ms  151.213.31.168
  4     5 ms     4 ms     6 ms  75.90.222.23
  5     9 ms     7 ms     7 ms  75.90.222.25
  6     6 ms     5 ms     8 ms  151.213.254.36
  7    10 ms     8 ms    14 ms  12.118.104.17
  8    19 ms     9 ms     8 ms  12.122.133.98
  9    12 ms     7 ms    30 ms  12.123.7.110
 10     8 ms    10 ms    29 ms  12.122.133.9
 11    38 ms    47 ms    14 ms  192.205.33.194
 12    12 ms    48 ms    32 ms  154.54.3.246
 13    15 ms    42 ms    14 ms  38.20.40.174
 14     8 ms     7 ms    26 ms  38.104.102.62
 15     9 ms     8 ms    11 ms  208.69.36.230

Trace complete.

Now we can see solid statistics on the first hop.  Now our ASA is working correctly with traceroute traffic.  I want to show one more example of a way to break traceroute.

Let’s set the IP Audit Attack policy on the outside interface.

ASA Config

ciscoasa(config)#ip audit name myattack attack action alarm drop
ciscoasa(config)#ip audit interface outside myattack

Now we can run our test again.

Windows PC

C:\Documents and Settings\paul>tracert -d www.google.com

Tracing route to google.navigation.opendns.com [208.69.36.231]
over a maximum of 30 hops:

  1     *        *        *     Request timed out.
  2    19 ms    19 ms     4 ms  75.117.160.1
 ^C

We can see the issue has resurfaced.  If we have logging enabled, we can see the IDS engine is detecting this as a “land” attack.

ciscoasa(config)# show log | inc IDS
%ASA-4-400008: IDS:1102 IP land attack from 75.117.163.238 to 75.117.163.238 on

Let’s disable just this one signature.

ASA Config

ciscoasa(config)# ip audit signature 1102 disable

Now we can retest this once again.

Windows PC

C:\Documents and Settings\paul>tracert -d www.google.com

Tracing route to google.navigation.opendns.com [208.69.36.230]
over a maximum of 30 hops:

  1     1 ms    <1 ms    <1 ms  75.117.163.238
  2    11 ms     8 ms     4 ms  75.117.160.1
  3     9 ms    13 ms    11 ms  151.213.31.168
  4     7 ms     8 ms    10 ms  75.90.222.23 
 ^C

Now you can see that we have a successful traceroute configuration on our ASA.  So if I were to receive a lab question that says to make sure traceroute will work through my ASA, that question can mean several things.  If I get such a question on the lab and it is vague, I will verify with the proctor exactly what a successful traceroute means.  I will also keep in mind that if I enable ids on the ASA that I should probably re-check the traceroute to verify it still works.

Some emails are not being sent from an Exchange Server behind a Cisco PIX or Cisco ASA firewall

On Cisco firewalls (PIX or the newer ASA), various protocol inspection engines are available. Generally, they assist in tracking connections of IP traffic through the firewall. That is, for a protocol such as FTP various additional TCP connections are made alongside the original connection, and the firewall needs to know to allow these through. The inspection engines perform simple analysis of traffic to watch for and set up these so-called pinhole ports, on demand.

Trouble is, some of the inspection engines have suffered feature creep and now try to work out, I guess, the semantics of the exchange taking place. If the engine thinks the conversation contains “illegal” requests, it’s blocked.

In particular the SMTP inspection engine (also known as a fixup in the Cisco docs) is fairly notorious for messing about with email transfer and preventing successful delivery. At best you might experience mysteriously missing attachments, at worst the remote server simply sees a TCP connection reset and has no idea why delivery failed.

Here’s how to tell if your Cisco firewall is interfering with your mail server’s operation. Telnet to the mail server (we assume the firewall sits in front of it) on the standard port of 25, and look at the “banner” response. On a regular mail server the banner looks something like this:

host:~$ telnet oxmail.ox.ac.uk 25
Trying 129.67.1.161...
Connected to oxmail.ox.ac.uk.
Escape character is '^]'.
220 relay0.mail.ox.ac.uk ESMTP Exim 4.69 Thu, 26 Nov 2009 19:28:51 +0000

However on an affected server, the banner is noticeably different:

host:~$ telnet suspectserver.example.com 25
Trying 192.0.2.1...
Connected to suspectserver.example.com.
Escape character is '^]'.
220 *****************************************************************************

Disabling the SMTP fixup (which is on by default, I believe) enables mail to flow as it should. I recommend you do this on any PIX or ASA devices in your network.

Note that the fixup seems to interfere with email going through the firewall in both directions, and problems occur regardless of the mail server software being used in the communication (after all, all servers are speaking the same SMTP protocol language).

To turn off the Mailguard feature of the PIX or ASA firewall:  

  1. Log on to the PIX or ASA firewall by establishing a telnet session or by using the console.
  2. Type enable, and then press ENTER.
  3. When you are prompted for your password, type your password, and then press ENTER.
  4. Type configure terminal, and then press ENTER.
  5. Type no fixup protocol smtp 25, and then press ENTER.
  6. Type write memory, and then press ENTER.
  7. Restart or reload the PIX or ASA firewall.

Cisco ASA 8.4 on GNS3

Configure GNS3 as following. ( I am using Ver 0.8.2 Beta 2, Also Tested 8.3 with Windows 7 64 bit which worked without any issues).  Type the code below into relevant fields

 

Qemu Options: -vnc none -vga none -m 1024 -icount auto -hdachs 980,16,32
Kernel cmd line: -append ide_generic.probe_mask=0x01 ide_core.chs=0.0:980,16,32 auto nousb console=ttyS0,9600 bigphysarea=65536
Configure the paths for Initrd and Kernel to where you have extracted the files.

 

Set the idle time out settings for RDP session

Terminal Services using RDP is great for sharing a computer among multiple users who may be dialing in from a remote location to use the resources on the network. However, if a user forgets to log out after they use the computer, the next person won’t be able to log in until the last user logs out of the system. You can make the terminal server automatically disconnect if the user does not use the system for a set period of time, thus allowing other people to log in and use the system resources.

From the remote workstation start the Group Policy Editor.
Go to Start –> Run and type mmc in the run dialog box.

Load the Group Policy Editor
From the File Menu, click Add/Remove Snap-in. Choose the Group Policy Object and load into system.

terminal1terminal2

The settings are located in Local Computer Policy\Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session\Session Time Limits

The settings you need to change are
Set time limit for disconnected sesions
Set time limit for active but idle Remote Desktop Service Sessions
Terminate session when time limits are reached.
NOTE: I do not set the Set time limit for active Remote Desktop Service Sessions value. If you set this value, the active users will be disconnected from the session after the time out value is reached.

terminal3

On Windows XP computer, the values are found in Local Computer Policy\Computer Configuration\Administrative Templates\Windows Components\Terminal Services\Sessions

terminal4