Cisco Ebook: Chapter 5: Managing a Cisco ASA (Part02)

4-2: Managing the Flash File System

Every Cisco firewall has a flash (nonvolatile) memory file system. Files such as the firewall operating system image, a firewall management application image, and the firewall configuration can be stored for use. This section discusses the various types of files and how to navigate and use the flash file system. The flash file system can be characterized by the following features:

The operating system for Cisco firewalls is stored in flash memory in a compressed format. In PIX 6.3 or earlier, only one image can be stored in flash at any time. FWSM allows one image to be stored in each of two flash memory partitions, although only one image can be run at any time.

The ASA release loosens this restriction, allowing multiple images; however, only one of those images can run actively at any time.
In ASA and FWSM multiple-context modes, only the system execution space can directly access and manage the flash file system. All other contexts have no knowledge of a flash file system and no means to manage one.
When a firewall boots, it uncompresses and copies an executable image from flash to RAM. The image is actually run from RAM.
While an image is being run, a different image can be copied or written into flash memory. In fact, the running image can be safely overwritten in flash, because it is run from RAM. The new image is not run until the next time the firewall reloads.

The various Cisco firewall platforms have different flash memory organization and storage capabilities. Generally, flash memory is divided into partitions, each having its own restrictions on the types of files that can be stored there. Table 4-7 summarizes the flash memory differences:

Table 4-7: Flash Memory Organization/Storage by Platform
Open table as spreadsheet
	PIX 6.3	ASA	FWSM
Flash partitions	1	2	6
File types allowed on partitions	One OS image One PDM image One crash dump	1: Open partition flash:/—OS images, ASDM images, configuration files, logging files, arbitrary files 2: Hidden partition—system startup configuration file, crash dump file	1: Maintenance image 2: Network configuration for maintenance image 3: Crash dump 4: flash:/—images (OS, ASDM, system startup configuration) 5: Alternative images 6: disk:/—security context configurations, RSA keys, arbitrary files

The operating system and ASDM or PDM images must be compatible before ASDM/PDM can be used. An ASDM/PDM image can be loaded into flash at any time without requiring a firewall reload.
An image (operating system or ASDM/PDM) can be transferred into a firewall by any of the following methods:
- TFTP at the monitor prompt
- TFTP from an administrative session (firewall console, Telnet, or SSH)
- HTTP or HTTPS from a web server
- The firewall polls an Auto Update Server (AUS) device periodically to see if a new image is available for it. If so, the image is downloaded using HTTPS (TCP port 443).

Tip

After an ASDM or PDM image is downloaded into the firewall flash memory, it can be used immediately. After an operating system image is downloaded, however, the firewall must be rebooted to run the new image. You have to manually force a reboot by using the reload EXEC command. Obviously, you can download a new OS image at any time—even while the firewall is in production. To run the new image, firewall service has to be interrupted during downtime or a maintenance window.

Navigating an ASA or FWSM Flash File System

ASA and FWSM platforms organize their flash file systems much like a traditional IOS file system, which must be formatted, and can contain a tree of directories, each containing arbitrary files. You can navigate the flash file system and manage any of its contents, as described in the following sections.

Tip

In ASA, you can use flash:/ to reference the entire flash file system.

FWSM, however, uses flash:/ to reference the flash partition that contains operating system and PDM images. You can use disk:/ to reference the flash partition that contains configuration files and other arbitrary files.

Each administrative session maintains a current placeholder or current directory where the user is positioned within the firewall file system. This is very similar to navigating a file system from within a shell on a Windows or UNIX machine.

In an administrative session, you can take the following actions:

List the files stored in a directory:
FWSM

Firewall# dir [/all] [/recursive] [disk:[path]]
ASA

Firewall# dir [/all] [/recursive] [flash:[path]]
Open table as spreadsheet
By default, an administrative session begins in the flash:/ or disk:/ root directory, for ASA or FWSM, respectively. You can specify the flash: or disk: keyword and a path to view the contents of a different directory. The path also can contain regular expressions to match specific patterns within filenames.

For example, you can use the following command on an ASA to see a list of all configuration files (having a .cfg suffix) in flash:
```
Firewall# dir flash:*.cfg
Directory of flash:/*.cfg
10     -rw-  1575        23:05:09 Sep 30 2004  old_running.cfg
12     -rw-  3134        23:30:24 Nov 08 2004  admin.cfg
13     -rw-  1401        14:12:31 Oct 20 2004  CustomerA.cfg
14     -rw-  2515        23:29:28 Nov 08 2004  border.cfg
17     -rw-  1961        13:52:22 Oct 25 2004  datacenter.cfg
```
You can use the /all keyword to list all the files in the directory and the /recursive keyword to recursively look in all nested directories and list the files found.
Display the current directory name:
FWSM

Firewall# pwd
ASA

Firewall# pwd
Open table as spreadsheet
Because you can “move around” within the flash file system hierarchy, it is easy to forget where the current directory is pointed. In the following example, the user has moved into the Syslog directory in flash:
```
Firewall# pwd
flash:/syslog/
```
Change to a different directory:
FWSM

Firewall# cd [disk:][path]
ASA

Firewall# cd [flash:][path]
Open table as spreadsheet
You can specify a directory name as path relative to the file system’s root. The keyword flash: or disk: is optional but is the default. If the cd command is used alone, the pointer is changed to the root directory in flash.

For example, the following commands move the user into the Syslog directory in flash:
```
Firewall# cd
Firewall# cd syslog
```
or
```
Firewall# cd flash:/syslog
```
Display a file’s contents:
FWSM

Firewall# more [/ascii | /binary] [disk:]path
ASA

Firewall# more [/ascii | /binary] [flash:]path
Open table as spreadsheet
The file found at filesystem:path is displayed, one page at a time, in the current administrative session. By default, the flash: or disk: file system is assumed, and the file contents are shown as plain text. For example, the following command displays the flash:/mytest text file:
```
Firewall# more mytest
hello this is a test
the end
Firewall#
```
You can also display a file to see both the hex and ASCII representations of its contents. The file can contain either ASCII text or binary data. You can use either the /binary or /ascii keyword, because they produce identical results. The following example shows the same small text file in the dual format:
```
Firewall# more /ascii mytest
00000000:  68656c6c 6f207468 69732069 73206120    hell o th is i s a
00000010:  74657374 0d0a0d0a 74686520 656e64XX    test .... the  endX
Firewall#
```

Tip

Be careful when you use the more command. If you attempt to view the contents of a large binary file, such as by using more image.bin to view the PIX image file, you could be stuck waiting a very long time while every byte is shown as a literal (and often cryptic) character to your terminal session. If you want to look at the contents of a binary file, always use the more /binary or more /ascii forms of the command.

Administering an ASA or FWSM Flash File System

An ASA platform offers two file systems—a flash file system that is accessible to administrative users, and a hidden file system that contains system-related resources that are inaccessible. On an FWSM platform, both file systems are accessible. The flash file system can contain files and directories, each under user control.

In an administrative session, you can take the following management actions on the flash file system and its contents:

Copy a file to or from flash.

You can copy files according to the basic syntax copy from to, as in the following commands:

FWSM	Firewall# copy disk:path/filename url
ASA	Firewall# copy flash:path/filename url

Open table as spreadsheet

FWSM	Firewall# copy url disk:path/filename
ASA	Firewall# copy url flash:path/filename

Open table as spreadsheet

In the flash file system, files are identified by their path, relative to the flash root directory, and their filename. You can use regular expressions in the filename to select specific files if needed.

Files can be copied to or from a URL, which can be an FTP server, a TFTP server, or another location in flash. The respective URL formats are as follows:


ftp://[user[:password]@]server[:port]/[path/]filename[;type=xy]
tftp://[user[:password]@]server[:port]/[path/]filename
flash:path/filename

If a server requires user authentication, you can specify the user ID and password in the user:password@ format.

Tip

Prior to ASA 7.2(1), the URL required an IP address; the firewall could not resolve fully qualified domain names (FQDN). If you are running ASA 7.2(1) or later, the firewall can use DNS to resolve the IP address in a URL.

Make sure you use the following commands to configure DNS resolution on a specific firewall interface, the firewall’s default domain name, and one or more DNS addresses:

Firewall(config)# dns domain-lookup if_name
Firewall(config)# dns server-group name
Firewall(config-dns-server-group)# domain-name name
Firewall(config-dns-server-group)# name-server ip_addr [ip_addr2] [...]
 [ip_addr6]
Firewall(config-dns-server-group)# retries number
Firewall(config-dns-server-group)# timeout seconds
Firewall(config-dns-server-group)# exit

Delete a file from flash:
FWSM

Firewall# delete [/noconfirm] [/recursive] [disk:][/path]filename
ASA

Firewall# delete [/noconfirm] [/recursive]
[flash:][/path]filename
Open table as spreadsheet
The file named filename is deleted from flash. You can specify the flash: or disk: keyword, as well as a path, if needed. If those are omitted, the flash file system is assumed, and the path is assumed to be the current working directory (as shown by the pwd command).

You can use the /noconfirm keyword to delete the file without being asked to confirm the action. Without this keyword, you must press the Enter key each time the firewall prompts you for confirmation. You can delete an entire directory and its contents recursively by using the /recursive keyword.

For example, suppose an old configuration file oldconfig.cfg exists in flash. First, a directory is shown to find the correct filename, and then the file is deleted using the following commands:
```
Firewall# dir flash:
Directory of flash:/
6      -rw-  4902912     17:11:35 Nov 22 2004  image.bin
10     -rw-  1575        23:05:09 Sep 30 2004  oldconfig.cfg
23     -rw-  8596996     10:12:38 Nov 12 2004  asdm.bin
Firewall# delete flash:oldconfig.cfg
Delete filename [oldconfig.cfg]
Delete flash:/oldconfig.cfg? [confirm]
Firewall#
```
Rename a file:
FWSM

Firewall# rename [/noconfirm] [disk:] [source-path] [disk:]
[destination-path]
ASA

Firewall# rename [/noconfirm] [flash:] [source-path] [flash:]
[destination-path]
Open table as spreadsheet
You can rename an existing file named source-path (a filename with an optional path) to destination-path. You can add the flash: or disk: file system keyword, but the flash memory is used by default. If you provide no other path information, the path is assumed to be the current working directory (as seen with the pwd command).

By default, the firewall prompts you for each argument as a confirmation. You can use the /noconfirm keyword to skip all the confirmation steps.

For example, the file flash:/capture1 is renamed flash:/capture2 using the following commands:
```
Firewall# rename flash:/capture1 flash:/capture2
Source filename [capture1]?
Destination filename [capture2]?
Firewall#
```
Make a new directory:
FWSM

Firewall# mkdir [/noconfirm] [disk:]path
ASA

Firewall# mkdir [/noconfirm] [flash:]path
Open table as spreadsheet
A new empty directory is created at path, which can contain a path and filename. You can add the flash: or disk: keyword, but it is assumed by default. The firewall prompts you for confirmation before creating the directory. You can use the /noconfirm keyword to skip the confirmation prompts.

For example, to create a new directory called MyStuff in the flash file system, you would use the following command sequence:
```
Firewall# mkdir flash:/MyStuff
Create directory filename [MyStuff]?
Created dir flash:/MyStuff
Firewall# dir flash:
Directory of flash:/
[output omitted]
64     drw-  0           16:02:57 Nov 23 2006  MyStuff
16128000 bytes total (2419712 bytes free)
Firewall#
```
Remove a directory:
FWSM

Firewall# rmdir [/noconfirm] [disk:]path
ASA

Firewall# rmdir [/noconfirm] [flash:]path
Open table as spreadsheet
A directory named path is removed or deleted from flash. The path can contain a directory path and filename if needed. The firewall prompts you for confirmation before removing the directory. You can use the /noconfirm keyword to skip the confirmation prompts.

A directory must be empty of files and other directories before it can be removed.
Check the flash file system’s integrity.

If you suspect that the flash file system might be corrupted, you can use the following command to check it:
FWSM

Firewall# fsck disk:
ASA

Firewall# fsck flash:
Open table as spreadsheet
The ASA flash file system has been checked in the following example. The output shows the number of orphaned files and directories that are found. These files and directories have been created but can no longer be reached in the file system because the mechanism to index or point to them is corrupt.
```
Firewall# fsck flash:
Fsck operation may take a while. Continue? [confirm]
flashfs[7]: 32 files, 6 directories
flashfs[7]: 0 orphaned files, 0 orphaned directories
flashfs[7]: Total bytes: 16128000
flashfs[7]: Bytes used: 13607936
flashfs[7]: Bytes available: 2520064
flashfs[7]: flashfs fsck took 23 seconds.
Fsck of flash:: complete
Firewall#
```
Destroy the entire flash file system:
FWSM

Firewall# format disk:
ASA

Firewall# format flash:
Open table as spreadsheet
or
FWSM

—
ASA

Firewall# erase flash:
Open table as spreadsheet

You should use the format and erase commands only in special cases, where the entire contents of flash memory (both accessible and hidden flash file systems) need to be erased. This might be desirable if a firewall is to be turned over or transferred to a different owner and the flash contents need to remain confidential.

Every file, including image files, configuration files, and licensing files, is overwritten with a 0xFF data pattern so that it is completely removed. A generic flash file system is then rebuilt.

Using the PIX 6.3 Flash File System

In PIX 6.3, the flash memory is organized as a “closed,” flat file system. Only six different files can be stored in flash. These files are not directly accessible or readable, and there is no hierarchical structure (folders or directories) to navigate. In fact, the files do not even have filenames. Instead, the firewall displays only the file index numbers it assigns automatically:

0— The operating system binary image.
1— The startup configuration commands; these are copied into the running configuration (RAM) and are executed when the firewall boots.
2— VPN and other keys and certificates.
3— The PDM image (if present).
4— A memory image saved after a firewall crash (if enabled).
5— The file size of the compressed operating system image (file 0).

In PIX 6.3, you can display the flash files with the show flashfs command, as in the following example:

Firewall# show flashfs
flash file system:  version:3  magic:0x12345679
 file 0: origin:       0 length:1949752
 file 1: origin: 2097152 length:6080
 file 2: origin: 2228224 length:1504
 file 3: origin: 2359296 length:3126944
 file 4: origin:       0 length:0
 file 5: origin: 8257536 length:308
Firewall#

Identifying the Operating System Image

In PIX 6.3 and FWSM, only one operating system image file can be stored in flash at any time. The firewall automatically allocates storage for the image and handles its creation. In PIX 6.3, the image file is always indexed as file number 0 in the flash file system, as displayed by the show flashfs command. Therefore, when the firewall boots up, that image is always loaded into RAM and executed. In an FWSM, you can see a list of files in the image or application partition with the dir flash:/ command.

The ASA code platform relaxes this restriction, allowing one or more operating system images to be stored in flash, as long as there is sufficient space to store them. Naturally, only one of the image files can run on the firewall at any time, so you must select one file for use. Use the following command to select the bootable image:

Firewall(config)# boot system flash:filename

Naturally, this command is stored in the running configuration after it is entered. It should also be written into the startup configuration so that the image can be identified during the next reload or bootup. The firewall searches for the specified file as soon as the command is entered. If the file cannot be found in flash, the command is accepted but a warning message is displayed.

You can also enter this command more than once to configure a list of image files that can be executed. The list of filenames is tried in sequence so that if one file is not found in flash, the next file is tried, and so on.

The firewall also maintains this value as an environment variable BOOT while it is running. If multiple boot system commands have been configured, the BOOT variable contains the entire sequence of values. You can display the current boot image setting with the following command:

Firewall# show bootvar

For example, two image files are stored in flash: flash:/image.bin and flash:/image-beta.bin. You can run either image on the firewall. For normal production use, image.bin is used, whereas image-beta.bin is occasionally run to test new firewall features. The following commands show the available images and then specify image.bin and image-beta.bin as the bootable image sequence:

Firewall# dir flash:
Directory of flash:/
4      -rw-  4976640     10:23:28 Apr 1 2007  image.bin
9      -rw-  5261204      4:10:17 May 6 2007  image-beta.bin
[output omitted]
Firewall# configure terminal
Firewall(config)# boot system flash:/image.bin
Firewall(config)# boot system flash:/image-beta.bin
Firewall(config)# exit
Firewall# copy running-config startup-config
Firewall#
Firewall# show bootvar
BOOT variable = flash:/image.bin
Current BOOT variable = flash:/image.bin;flash:/image-beta.bin
CONFIG_FILE variable =
Current CONFIG_FILE variable =
Firewall#

Notice that the BOOT variable has two different lines of output. The first, BOOT variable, shows the value obtained from the boot system commands at bootup time. The Current BOOT variable line shows the current value obtained by any additional boot system commands entered since bootup.

Upgrading an Image from the Monitor Prompt

If the firewall has no operating system image, you can still download one via TFTP from the monitor prompt. At this point, the firewall is not inspecting any traffic and has no running configuration. Follow these steps to download a firewall operating system image via TFTP:

Make sure a TFTP server is available.

The TFTP server should have the firewall image available for downloading.

Tip

You can obtain TFTP server software from a variety of sources:

Solarwinds.net TFTP server (http://www.solarwinds.net; free)
Kiwi CatTools 2.x, Kiwi Enterprises (http://www.kiwisyslog.com; commercial package)
Tftpd32 (http://tftpd32.jounin.net; free)
tftpd, standard on UNIX systems (free)

At one time, Cisco offered a free TFTP server on Cisco.com. However, this was limited to Windows 95 installations, so it has since been dropped from support.

Boot the firewall to the monitor prompt.

Just after booting the firewall, you can press the Esc or Break key to break the normal bootup sequence. Be sure to do this when the following output and prompt are displayed:

Cisco Systems ROMMON Version (1.0(10)0) #0: Fri Mar 25 23:02:10 PST 2005

Platform ASA5510

Use BREAK or ESC to interrupt boot.
Use SPACE to begin boot immediately.
[The ESC key was pressed here]
Boot interrupted.

Management0/0
Ethernet auto negotiation timed out.
Interface-4 Link Not Established (check cable).

Default Interface number-4 Not Up

Use ? for help.
rommon #0>

Identify the TFTP server.

Note

The parameters you assign here are used only temporarily until the firewall can download and run the new image. None of these commands is stored in a configuration; as soon as the firewall boots, they are lost.

Identify the firewall interface where the TFTP server is located:

ASA	monitor> interface name
PIX 6.3	monitor> interface number

Open table as spreadsheet

On an ASA platform, you identify the interface by its physical interface name. For example, you could use ethernet0/0, ethernet0/1, ethernet0/2, ethernet0/3, or management0/0 on an ASA 5510.

TFTP on a PIX 6.3 platform uses the interface with index number (0 to n – 1, where n is the number of interfaces installed). During the bootup sequence, the firewall lists the physical interfaces that are installed. Some models also list their MAC addresses but do not number the interfaces. Therefore, it might not be clear how they correspond to the actual connections on the firewall. In any case, the first interface shown is always index 0.

Tip

On a PIX platform, when the installed interfaces are listed during bootup, only the interfaces that are not Gigabit Ethernet are shown. This is because you cannot use a Gigabit Ethernet interface to download a software image from the monitor prompt.

If you are stuck trying to figure out what interface names are available on an ASA, you can enter a bogus value for the interface name to get the valid names listed. For example, try something like interface 0 to get the following list:

rommon #1> interface 0
Invalid interface name argument, Valid arguments are:
  Ethernet0/0
  Ethernet0/1
  Ethernet0/2
  Ethernet0/3
  Management0/0

interface   ethernet interface port
rommon #1>

Assign an IP address to the interface:
```
monitor> address ip-address
```
Here, the firewall needs just enough information to be able to contact the TFTP server. Only one physical interface can be used, so this IP address is applied to it. Because a subnet mask cannot be given, the firewall assumes a regular classful network mask (172.17.69.41 yields a Class B mask of 255.255.0.0, for example).

If your TFTP server is located on a different classful subnet, you can also specify a gateway address that can route between the firewall and the server. Use the following monitor command:
```
monitor> gateway ip-address
```
Make sure that the firewall can reach the TFTP server.

The firewall must be able to reach the server with a minimal amount of routing. You can use the following monitor command to test reachability:
```
monitor> ping ip-address
```
Define the TFTP server’s IP address:
```
monitor> server ip-address
```
Define the image filename to fetch:
```
monitor> file filename
```
The image file named filename is located in the TFTP server’s root directory. This is often called the /tftpboot directory, but it depends on how your TFTP server is configured. As long as the file can be found in the TFTP server’s root directory, you do not have to specify the directory name or path.

Copy the image from the TFTP server:

ASA	monitor> tftpdnld
PIX 6.3	monitor> tftp

Open table as spreadsheet

On an ASA, you should see exclamation points as the TFTP download is progressing. A successful TFTP download should look something like the following:

Cisco Systems ROMMON Version (1.0(10)0) #0: Fri Mar 25 23:02:10 PST 2005

Platform ASA5510

Use BREAK or ESC to interrupt boot.
Use SPACE to begin boot immediately.
Boot interrupted.

Management0/0
Ethernet auto negotiation timed out.
Interface-4 Link Not Established (check cable).
Default Interface number-4 Not Up
Use ? for help.
rommon #0> interface etherenet0/0
Ethernet0/0
Link is UP
MAC Address: 0016.c789.c8a4
rommon #1> address 172.17.69.1
rommon #2> server 172.17.69.49
rommon #3> ping 172.17.69.49
Sending 20, 100-byte ICMP Echoes to 172.17.69.49, timeout is 4 seconds:
!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (20/20)
rommon #4> file image.bin
rommon #5> tftpdnld
ROMMON Variable Settings:
 ADDRESS=172.17.69.1
 SERVER=172.17.69.49
 GATEWAY=0.0.0.0
 PORT=Ethernet0/0
 VLAN=untagged
 IMAGE=image.bin
 CONFIG=
 LINKTIMEOUT=20
 PKTTIMEOUT=4
 RETRY=20

tftp image.bin@172.17.69.49 via 0.0.0.0
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
[output omitted]
!!!!!!!!!!!!!!!!!!
Received 14487552 bytes

Launching TFTP Image...

Cisco Security Appliance admin loader (3.0) #0: Thu Mar 29 01:42:31 MDT 2007
Loading...

A PIX 6.3 platform will show periods or dots as the TFTP download is progressing. After the download completes, the firewall needs confirmation before it actually writes the new image into its flash memory. You can also enter a new license activation key at the end of this process, if needed.

A successful TFTP download looks something like this:

Cisco Secure PIX Firewall BIOS (4.0) #39: Tue Nov 28 18:44:51 PST 2000
Platform PIX-525
System Flash=E28F128J3 @ 0xfff00000
Use BREAK or ESC to interrupt flash boot.
Use SPACE to begin flash boot immediately.
Flash boot in 8 seconds.
[ESC key pressed here]
Flash boot interrupted.
0: i8255X @ PCI(bus:0 dev:14 irq:10)
1: i8255X @ PCI(bus:0 dev:13 irq:11)
Use ? for help.
monitor>
monitor> interface 0
Using 0: i8255X @ PCI(bus:0 dev:14 irq:10), MAC: 0090.2744.5e66
monitor> address 172.17.69.1
monitor> ping 172.17.69.49
Sending 5, 100-byte 0x5b8d ICMP Echoes to 172.17.69.49, timeout is 4
 seconds:
!!!!!
Success rate is 100 percent (5/5)
monitor> server 172.17.69.41
monitor> file image.bin
monitor> tftp
tftp image.bin@172.17.69.41...............................................
..........................................................................
[output omitted]
...............................................
Received 2064384 bytes.
Flash version 6.3(4), Install version 6.3(4)
Do you wish to copy the install image into flash? [n] y
Installing to flash
Serial Number: 807443449 (0x30209bf9)
Activation Key: c422440f 2eb1445a 46fb4413 74a344ee
Do you want to enter a new activation key? [n]
Writing 1941560 bytes image into flash...

Reload the firewall to run the new image:
```
monitor> reload
```
The firewall performs a reload immediately. You should see the usual bootup output on the console, followed by information about the new running image.

An ASA platform automatically reloads as soon as the code image TFTP download is finished.

Upgrading an Image from an Administrative Session

Make sure an image server is available.

The server should have the firewall image available for downloading, either by TFTP, FTP, HTTP, or HTTPS.
Make sure you have sufficient space on the flash file system.

An ASA allows one or more image files as well as other files to be stored in flash, as long as you have sufficient space to contain them all. When a new image or file is downloaded, it is stored in flash with a specific filename. A file is overwritten only if an existing file in flash has an identical filename.

You can use the following command to check the available (free) space in the flash memory:
```
Firewall# dir flash:/
```
For example, suppose a new firewall image is available on a server. The image file size is 4,995,512 bytes. First, the amount of free flash memory is checked, giving the following output:
```
Firewall# dir flash:/
Directory of flash:/
6      -rw-  4976640     10:04:50 Nov 12 2004  image.bin
10     -rw-  1575        23:05:09 Sep 30 2004  old_running.cfg
12     -rw-  3134        23:30:24 Nov 08 2004  admin.cfg
13     -rw-  1401        14:12:31 Oct 20 2004  CustomerA.cfg
14     -rw-  2515        23:29:28 Nov 08 2004  border.cfg
17     -rw-  1961        13:52:22 Oct 25 2004  datacenter.cfg
23     -rw-  8596996     10:12:38 Nov 12 2004  asdm.bin
21     drw-  704         15:06:09 Nov 22 2004  syslog
32     -rw-  205         15:06:08 Nov 22 2004  stuff
16128000 bytes total (2466816 bytes free)
Firewall#
```
Clearly, 2,466,816 bytes free is insufficient to store the new image unless the existing image (image.bin) is overwritten.

On an FWSM or a PIX 6.3 platform, only one operating system image and one PDM image can be stored in the flash file system at any time. If a new image is downloaded, it automatically overwrites an existing image in flash.
Make sure the firewall can reach the server:
```
Firewall# ping [interface] ip-address
```
The server has IP address ip-address. The firewall should already have the necessary routing information to reach the server. You can specify the firewall interface where the server is located (“outside,” for example) if the firewall cannot determine that directly. For example, this firewall can reach the server at 192.168.254.2:
```
Firewall# ping 192.168.254.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.254.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
Firewall#
```
(TFTP only) Identify a possible TFTP server:
```
Firewall(config)# tftp-server interface ip-address path
```
The TFTP server can be found at ip-address on the firewall interface named interface (outside), for example. As of FWSM 3.1(1) and ASA 7.0(1), the interface parameter is required. For prior releases, the firewall always assumes the inside interface is used for TFTP. The only way to override this assumption is by specifying a firewall interface in the tftp-server command. This interface is always used whenever files are copied to and from a TFTP server, even if the server address is different from the one configured with this command.

The image files are stored in the path directory on the TFTP server. This path is relative only to the TFTP process itself. For example, if the image files are stored in the topmost TFTP directory (/tftpboot within the server’s file system, for example), the path would be /, or the root of the TFTP directory tree.

Tip
The tftp-server command is optional because most of the TFTP parameters can be given with the copy EXEC command when the image is downloaded.
Copy the image file from the server.

With any download method, the basic command syntax is:
```
Firewall# copy source flash:[image | pdm | filename]
```
The image is downloaded and copied into flash memory as either an operating system image or a pdm image. Only one of either image type can be stored in the firewall flash, and their locations are automatically determined. In fact, PIX 6.3 restricts the image transfer to these two file types.

ASA and FWSM platforms make use of their more flexible flash file systems. From the system execution space, you can copy one or more image files into flash and then specify which image the firewall should use. You can give the destination filename as an arbitrary filename. You also can use the image or asdm keywords for backward compatibility. In that case, the firewall uses the image filename configured with the boot system or asdm image commands, respectively.

Also, you can choose TFTP, FTP, or HTTP as the copy method, as discussed in the following steps.
1. Use a TFTP server:
```
Firewall# copy tftp:[:[[//location][/pathname]] flash:[image | pdm |
 filename]
```
  The image file is located on the TFTP server at location, which can be either a hostname (already defined with a name command) or an IP address. The image file is referenced by pathname, which can include any directory structure needed within TFTP, along with the filename. (If the actual path name of the TFTP directory contains spaces, you should first define the whole path name using the tftp-server command. Spaces are not allowed in the pathname here.)
  
  If the location or pathname parameters are left out of this command, the firewall prompts you for those values.
  
  If you add a colon after the tftp keyword, the firewall picks up the remaining parameters configured with the tftp-server command.
  
  For example, suppose a new operating system image named newimage.bin is located on TFTP server 192.168.254.2. Recall that the firewall assumes that the TFTP server is located on the inside interface by default. In this case, it is located on the outside interface. You can download the new firewall image into flash memory using the following commands:
```
Firewall# configure terminal
Firewall(config)# tftp-server outside 192.168.254.2 /
Firewall(config)# exit
Firewall# copy tftp://192.168.254.2/newimage.bin flash:image
Address or name of remote host [192.168.254.2]?
Source filename [newimage.bin]?
Destination filename [image.bin]?
%Warning:There is a file already existing with this name
Do you want to over write? [confirm]
Accessing tftp://192.168.254.2/newimage.bin...!!!!!!!!!!!!!
[output omitted]
Writing file flash:/image.bin...
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!1
4976640 bytes copied in 143.380 secs (34801 bytes/sec)
Firewall#
```
2. Use an FTP server:
```
Firewall# copy ftp://[user[:password]@]server[:port]/[path/]filename
 [;type=xy] flash:[image | pdm | filename]
```
  The FTP server is known as server by either an IP address or a hostname (the host name must be preconfigured with the name configuration command). If the server requires user authentication, the username and password are given as user:password@. By default, TCP port 21 is used; you can override this by specifying port.
  
  The image file is found on the server with pathname path (relative to the user’s home directory) and filename filename. By default, the firewall uses an FTP session in binary passive mode. You can use a different FTP mode by appending the ;type=xy keyword, where x is a single letter a (ASCII) or i (image or binary) and y is a single letter p (passive) or n (normal). For example, ;type=ip is the default binary passive mode.
  
  As an example, suppose an image named newimage.bin is located on an FTP server at 192.168.254.2. The server requires authentication using username myuserid and password mypassword, and the image is stored in the Images directory. You can download the new firewall image into flash memory using the following command:
```
Firewall# copy ftp://myuserid:mypassword@192.168.254.2/Images/
 newimage.bin flash:image
Address or name of remote host [192.168.254.2]?
Source filename [newimage.bin]?
Destination filename [image.bin]?
%Warning:There is a file already existing with this name
Do you want to over write? [confirm]
Accessing ftp://myuserid:mypassword@192.168.254.2/Images/newimage.bin...
!!!!!!!!!!!!!
[output omitted]
Writing file flash:/image.bin...
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!1
4976640 bytes copied in 149.110 secs (33375 bytes/sec)
Firewall#
```
3. Use an HTTP or HTTPS server:
```
Firewall# copy http[s]://[user:password@]location[:port ]/
 http_pathname flash[:[image | pdm | filename]
```
  You can use either http (HTTP, port 80) or https (HTTPS or SSL, port 443), depending on how the web server is configured.
  
  If user authentication is required, it can be given as user:password@. The web server has a name or IP address given by location. (If a host name is used, it must also be defined in the firewall with the name command.) By default, the port number is either TCP 80 or TCP 443, according to the http or https keyword. You can override the TCP port number by giving it as port.
  
  The image file can be found on the server at the path http_pathname. The directory hierarchy is relative to the web server’s file structure.
  
  For example, a PIX operating system image named newimage.bin is stored on the web server at http://192.168.254.2 in the default directory. The server requires authentication using username myuserid and password mypassword. You can download the new firewall image into flash memory using the following command:
```
Firewall# copy http://myuserid:mypassword@192.168.254.2/newimage.bin flash:image.bin
Address or name of remote host [192.168.254.2]?
Source filename [newimage.bin]?
Destination filename [image.bin]?
%Warning:There is a file already existing with this name
Do you want to over write? [confirm]
Accessing http://192.168.254.2/newimage.bin...!!!!!!!!!!!!!!!!!
[output omitted]
Writing file flash:/image.bin...
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
[output omitted]
4902912 bytes copied in 137.730 secs (35787 bytes/sec)
Firewall#
```

Upgrading an Image Automatically

You can also configure a firewall to automatically poll a central server to see if a new image file exists. If a newer image is available, the firewall downloads it without any intervention on your part. This functionality is available with an Auto Update Server (AUS) and is discussed in detail in Section “4-4: Automatic Updates with an Auto Update Server.”

4-3: Managing Configuration Files

A firewall keeps a “startup” configuration file in flash memory. These configuration commands are not lost after a reload or power failure.

As soon as a firewall boots up, the startup configuration commands are copied to the “running” configuration file in RAM (volatile) memory. Any command that is entered or copied into the running configuration is also executed at that time.

As you enter configuration commands, be aware that they are present only in the temporary running configuration. After you have verified the operation of the new configuration commands, you should be sure to save the running configuration into flash memory. This preserves the configuration in case the firewall reloads later.

You can enter configuration commands into the firewall using the following methods:

Command-line interface (CLI), where commands are entered through a console, Telnet, or SSH session on the firewall. The configure terminal command is used for this.
A management application such as PDM or Firewall Management Center (within VMS).
Imported by a TFTP file transfer.
Imported by a web server.
An automated or forced update from an AUS.

Managing the Startup Configuration

In PIX releases 6.3 and earlier, as well as FWSM releases, a firewall has one startup configuration that is stored in flash memory. This configuration file is read upon bootup and is copied into the running configuration.

ASA platforms running 7.0 or later have the capability to maintain one or more startup configuration files in flash, provided that you have sufficient space to store them. Only one of these can be used at boot time.

This section discusses the tasks that can be used to maintain and display the startup configuration file.

Selecting a Startup Configuration File

In ASA platforms, having multiple startup configurations makes configuration rollback easy. The startup configuration contents can be saved in one file during the time that the firewall configuration is stable. If major configuration changes need to be made, the new updated running configuration can be saved to a new startup configuration file. The next time the firewall is booted, it can use this new file.

If you encounter problems with the new configuration, you can make one configuration change to force the firewall to roll back or use a previous version of the startup configuration.

By default, a firewall stores its startup configuration in a hidden partition of flash memory. That file has no usable name and can be viewed only through the show startup-configuration command.

To force the firewall to use a different startup configuration filename, you can use the following command:

Firewall(config)# boot config url

url represents the location of the startup configuration file. It can be flash:/path, disk0:/path, or disk1:/path, depending on which flash file systems the firewall platform supports. PIX models have only a flash:/ file system, whereas the ASA platforms can support flash or disk flash file systems.

Be aware that the boot config url command effectively changes an environment variable used only by the running configuration. When you use this command, be sure to save the running configuration with the copy running-config startup-config or write memory command.

At this point, the firewall uses the new url and saves the startup configuration in that file, not in the default location. If the file does not exist, a new file is created; if it does exist, the running configuration is merged with that file’s contents. The environment variable is also updated and is used during the next boot cycle to find the new startup configuration file.

You can see the startup configuration environment variable with the show bootvar command. The following example begins with the default location, signified by the empty Current CONFIG FILE variable value. When the boot config command is used, the current value is updated to show the new file location.

However, until the running configuration is saved to the new startup configuration location, the new file is not present in flash. As well, the startup configuration file used at boot time is still the default (shown by an empty CONFIG FILE variable line). After the configuration is saved, the new file is used during the next firewall boot.

Firewall# show bootvar
BOOT variable = flash:/image.bin
Current BOOT variable = flash:/image.bin
CONFIG_FILE variable =
Current CONFIG_FILE variable =
Firewall# configure terminal
Firewall(config)# boot config flash:/startup-1.cfg
INFO: Converting myconfig.cfg to flash:/startup-1.cfg
Firewall(config)# exit
Firewall# show bootvar
BOOT variable = flash:/image.bin
Current BOOT variable = flash:/image.bin
CONFIG_FILE variable =
Current CONFIG_FILE variable = flash:/startup-1.cfg
Firewall# dir flash:/
Directory of flash:/
6      -rw-  5031936     10:21:11 Dec 21 2006  image.bin
23     -rw-  8596996     10:12:38 Nov 12 2006  asdm.bin
16128000 bytes total (2450944 bytes free)
Firewall#
Firewall# copy running-config startup-config
Source filename [running-config]?
Cryptochecksum: a8885ca7 9782e279 c6794487 6480e76a
3861 bytes copied in 0.900 secs
Firewall# show bootvar
BOOT variable = flash:/image.bin
Current BOOT variable = flash:/image.bin
CONFIG_FILE variable = flash:/startup-1.cfg
Current CONFIG_FILE variable = flash:/startup-1.cfg
Firewall# dir flash:/
Directory of flash:/
6      -rw-  5031936     10:21:11 Dec 21 2006  image.bin
23     -rw-  8596996     10:12:38 Nov 12 2006  asdm.bin
20     -rw-  3861        23:12:20 Dec 30 2006  startup-1.cfg

Finally, notice that even though a new location and a new filename are used for the startup configuration, you do not have to specify those when you save the running configuration later. The firewall continues to work with the startup-config keyword, but it uses the new url to reference the actual file. In other words, copy running-config startup-config always uses the current and correct location.

Displaying the Startup Configuration

You can display the contents of the startup configuration with either of these commands:

Firewall# show startup-config

Firewall# show configuration

In PIX 6.3, the latter command is actually show configure.

In the first line of the startup configuration, you can find its time stamp. This shows when the running configuration was saved to flash the last time and who saved it. For example, the generic user enable_15 (someone in privileged EXEC or enable mode) saved this configuration:

Firewall# show startup-config
: Saved
: Written by enable_15 at 17:41:51.013 EST Mon Nov 22 2006
PIX Version 8.0(1)
names
!
interface Ethernet0
shutdown
[output omitted]

Saving a Running Configuration

You can view or save a firewall’s running configuration with one of the methods described in the following sections.

Viewing the Running Configuration

You can use the following commands to display the current running configuration:

Firewall# write terminal

Firewall# show running-config

The running configuration is displayed to the current terminal session. If the configuration is longer than your current session page length (24 lines by default), you have to press the spacebar to page through it.

However, in ASA, FWSM, and PIX 6.3 platforms, you can filter the output by using one of the following keywords at the end of the command:

Firewall# show running-config | {begin | include | exclude | grep [-v]} reg-exp

You can start the first line of output at the line where the regular expression reg-exp appears in the configuration with the begin keyword.

If you are looking for lines that contain only the regular expression reg-exp, use the include or grep keyword. You can also display only the lines that do not contain the reg-exp with the exclude or grep -v keyword.

The regular expression can be a simple text fragment or a more complex form containing wildcard and pattern-matching characters. For example, include int finds any line that contains “int” (including words such as “interface”) located anywhere in the text.

These options are very handy if you have a firewall with a large configuration. Rather than paging through large amounts of configuration output, you can instantly find what you are looking for.

Saving the Running Configuration to Flash Memory

After you make configuration changes to a firewall and they are satisfactory, you should make them permanent by saving the running configuration to flash memory. You can use the following command to accomplish this:

Firewall# write memory

All the current configuration commands are stored in the startup configuration area in flash memory. You should always run this command after making configuration changes. Otherwise, you might forget to save them later when the firewall is reloaded.

In ASA and FWSM, the write memory command is supported for backward compatibility. A new form of the copy command is also provided, using the following syntax:

Firewall# copy running-config startup-config

Tip

In multiple context mode, each context’s running configuration must be saved individually. This usually means you have to move into each context with the changeto command and then use the write memory or copy running-config startup-config command.

Beginning with ASA 7.2(1) and FWSM 3.1(1), you can save all context configurations with a single command. In the system execution space, use the following command:

Firewall# write memory all

The copy command does not have the same capability.

When the configuration is saved or displayed, the firewall also displays a cryptochecksum, or a message digest 5 (MD5) hash of the configuration file contents. This value serves as a type of fingerprint that can be used to evaluate the configuration file’s integrity. The configuration file’s size is also shown, as in the following example:

Firewall# copy running-config startup-config
Source filename [running-config]?
Cryptochecksum: 71a4cecb 97baf374 10757e38 a320cc43
2909 bytes copied in 0.520 secs
Firewall#

Tip

You can use the MD5 cryptochecksum value as a quick check to see if a firewall’s configuration has changed since it booted. First, find the MD5 hash that was saved with the startup configuration by looking at the last line of the show startup-config or show config command. Then compare that to the MD5 hash of the current running configuration, shown in the last line of the show running-config command or with the output of the show checksum command. If the two hash values differ, the configuration has changed.

Comparing the two cryptochecksum values in the following example shows that the configuration has been changed:

Firewall# show startup-config | include checksum
Cryptochecksum:3750a83d00922b80ffef78e92865b09a
Firewall# show running-config | include checksum
Cryptochecksum:a5bdac82909dc8717e494cfabc2d363d
Firewall#

Saving the Running Configuration to a TFTP Server

You can use the following steps to save the current running configuration to an external file server:

(Optional) Identify the TFTP server:

Firewall(config)# tftp-server [interface] ip-address path

The TFTP server can be found on the firewall’s interface at IP address ip-address. By default, the inside interface is assumed. The running configuration file is stored in the path directory on the TFTP server. This path is relative only to the TFTP process itself. For example, if the file is stored in the topmost TFTP directory (/tftpboot, for example), the path would be /, or the root of the TFTP directory tree.

Tip

The tftp-server command is not necessary, because all the TFTP parameters can be given with the write net or copy EXEC command when the configuration is saved. However, the firewall always assumes the inside interface will be used for TFTP. The only way to override this assumption is by specifying a firewall interface (inside or outside, for example) in the tftp-server command. This interface is always used whenever files are copied to and from a TFTP server, even if the server address is different.

Save the configuration:
```
Firewall# write net [[server-ip-address]:[filename]]
```
The TFTP server can be identified by giving its IP address here as server-ip-address. The configuration is saved in a file named filename in the TFTP root directory on the server.

If the server is not specified here, the values configured by the tftp-server command are used. You can also override the server address configured with the tftp-server command by specifying an address here.

ASA and FWSM platforms also offer the copy command, which can be used to copy the running configuration to a TFTP server. You can use the following command:
```
Firewall# copy running-config
 tftp://[user[:password]@]server[:port]/[path/]filename
```
Here, the running configuration is copied as a file with the filename filename. You can provide a path to specify where the file should be stored on the server. The path is relative to the TFTP server’s root directory. If the server requires user authentication, the user ID and password can be given in the form user:password@.

For example, the running configuration is to be saved as the file firewall.confg on the TFTP server at 192.168.208.40, located on the firewall’s dmz interface. The following commands can be used to accomplish this:
```
Firewall(config)# tftp-server dmz 192.168.208.40 /
Firewall(config)# exit
Firewall# write net 192.168.208.40:firewall.confg
```
or
```
Firewall# copy running-config tftp://192.168.208.40/firewall.confg
```

Forcing the Running Configuration to Be Copied Across a Failover Pair

During the bootup sequence, the active firewall copies its complete running configuration to the standby firewall. The active unit also copies any configuration commands to the standby unit as they are entered and executed.

Under normal conditions, the standby unit can keep its running configuration up to date and synchronized with the active unit. Sometimes it is possible for the two units to become unsynchronized. This can occur when configuration changes are made while the failover cable is disconnected, while the LAN-based failover connection is broken, or while the two units are running different OS releases. In these cases, you might see some of the logging messages in Table 4-8 generated when stateful failover cannot synchronize the two firewall units.

Table 4-8: Logging Messages Resulting from Stateful Failover Synchronization Errors
Open table as spreadsheet
Message ID	Description
%ASA-1-105020	(Primary) Incomplete/slow configuration replication.
%ASA-3-210006	Stateful failover is unable to locate a NAT group for the IP address on the standby unit.
%ASA-3-210008	Unable to find a translation slot (xlate) record for a stateful failover connection.
%ASA-3-210020	Stateful failover is unable to allocate a specific PAT address that is in use.
%ASA-3-210021	Stateful failover is unable to create a translation slot (xlate).

If you make configuration changes on the standby firewall unit, those changes are not replicated back toward the active unit. Instead, you see the following message:

*** WARNING ***
     Configuration Replication is NOT performed from Standby unit to Active unit.
     Configurations are no longer synchronized.

If you find that the running configurations are no longer identical and synchronized between the active and standby units, you can use the following command on the active unit to force a complete copy to be sent to the standby unit:

Firewall# write standby

Forcing the Startup (Nonvolatile) Configuration to Be Cleared

Sometimes you might need to begin with an empty configuration on a firewall. This might happen if you reuse an existing firewall in a different scenario or if you inherit a firewall from someone else.

The following command erases all configuration commands from the startup configuration in flash memory:

Firewall# write erase

This command does not disturb or erase the current running configuration. After the startup configuration is erased, you can use the reload EXEC command to reboot the firewall with the new, empty startup configuration.

Importing a Configuration

You can copy configuration commands into a firewall’s running configuration with one of the methods documented in the following sections.

Entering Configuration Commands Manually

You can begin entering configuration commands in a terminal session (console, Telnet, or SSH) after you use the following command:

Firewall# configure terminal

Commands are entered into the running configuration in RAM and are executed as they are entered. To end configuration mode, press Ctrl-z or enter exit.

Tip

In a failover pair of firewalls, configuration commands should be entered only on the active unit. As you enter configuration commands into the active unit, they are copied to the standby unit. Therefore, the failover configurations are automatically synchronized.

If you enter configuration commands on the standby unit, they are not replicated to the active unit. Therefore, the firewall configurations become different and are unsynchronized.

Merging Configuration Commands from Flash Memory

The commands stored in the startup configuration in flash memory can be copied over and merged into the running configuration after you issue the following command:

Firewall# configure memory

This is useful when the running configuration has been mistakenly cleared or the wrong configuration has been imported.

In ASA and FWSM platforms, you can achieve the same results with the following command:

Firewall# copy startup-config running-config

Tip

Remember that configuration commands are merged from flash into RAM. This means that commands in the running configuration are preserved, and the commands stored in flash are copied into the running configuration in RAM.

If similar commands are stored in both the startup and running configurations, the startup commands overwrite the others. In effect, this can result in a running configuration that is a mixture of startup and running configurations. It is a common misconception that the running configuration is erased before the startup configuration is copied onto it.

To erase the running configuration before the merge, use the clear configure all configuration command first. However, be aware that any existing configuration commands that provide IP addressing, routing, and administrative access are removed immediately. Unless you are connected to the firewall console, you could find that you become cut off from the newly cleared firewall.

Merging Configuration Commands from a TFTP Server

You can use the following steps to merge configuration commands from a file contained on an external TFTP server:

(Optional) Identify the TFTP server:
```
Firewall(config)# tftp-server [interface] ip-address path
```
The TFTP server can be found on the firewall’s interface at IP address ip-address. By default, the inside interface is assumed. The configuration file is copied from the path directory on the TFTP server. This path is relative only to the TFTP process itself. For example, if the file is stored in the topmost TFTP directory (/tftpboot, for example), the path would be simply a forward slash, as /, denoting the root of the TFTP directory tree.
Fetch and merge the configuration:
```
Firewall(config)# configure net [[server-ip-address]:[filename]]
```
The TFTP server can be identified by giving its IP address here as server-ip-address. The configuration is retrieved from the file named filename in the TFTP root directory on the server.

If the server is not specified here, the values configured by the tftp-server command are used. You can also override the server address configured with the tftp-server command by specifying an address here.

Although the ASA and FWSM support the legacy configure net command, they also offer the following new form of the copy command to achieve similar results:
```
Firewall# copy tftp://[user[:password]@]server[:port]/[path/]filename
 running-config
```
Here, the file named filename is found at path on the TFTP server at IP address server. If the server requires user authentication, you can give the user ID and password using the user:password@ format.

Merging Configuration Commands from a Web Server

If you have a configuration file stored on an external web server, you can use the following command to merge its contents with the running configuration:

Firewall(config)# configure http[s]://[user:password@]location[:port]/
 http-pathname

You can use either the http (HTTP, port 80) or https (HTTPS or SSL, port 443) protocol to transfer the configuration file, depending on how the web server is configured.

If user authentication is required, it can be given as user:password@. The web server has a name or IP address given by location. (If a host name is used, it must also be defined in the firewall with the name command.) By default, the port number is either 80 or 443, according to the http or https keyword. You can override the port number by giving it as port.

The configuration file can be found on the server at the path http-pathname. The directory hierarchy is relative to the web server’s file structure.

ASA and FWSM platforms also offer the following form of the copy command that achieves similar results:

Firewall# copy http[s]://[user[:password]@]server[:port]/[path/]filename
 running-config

For example, suppose a configuration file named fwtemplate.cfg is stored on the web server at 172.30.22.17. User authentication is required, using user ID fwadmin and password myadminpw. You can use the following commands to merge the file with the running configuration:

Firewall# configure https://pixadmin/myadminpw@172.30.22.17/pixtemplate.cfg

Firewall# copy https://fwadmin/myadminpw@172.30.22.17/fwtemplate.cfg
 running-config

Merging Configuration Commands from an Auto Update Server

You can use an Auto Update Server (AUS) as a platform to automatically merge a stored configuration file with the running configuration. Having the firewall pick up a new configuration file update is easier than a manual method if you have many firewalls to maintain.

The AUS feature is discussed in detail in the next section of this chapter.

4-4: Automatic Updates with an Auto Update Server

With an AUS, you can use one central location as a distribution point for the firewall image and configuration updates. This can be handy if you have many firewalls to maintain.

Ordinarily, you would have to manually transfer a new image or configuration file to each firewall individually. With AUS, each firewall can poll periodically to see if a new file is available. If a newer file is found, the firewall automatically downloads it without any further intervention.

A firewall can be configured to act as an Auto Update client, where it polls a central Auto Update Server for updates. ASA and PIX platforms can poll an AUS beginning with release 7.0(1); FWSM can poll an AUS beginning with release 3.1(1).

Traditionally, only specialized network management applications could operate as Auto Update Servers. These include Cisco Security Manager (CSM), Cisco VPN/Security Management Solution (VMS), and Resource Manager Essentials (RME, a part of CiscoWorks). Beginning with ASA 7.2(1), you can also configure an ASA platform to act as an AUS.

(refer to other document)

4-5: Managing Administrative Sessions

Administrators and firewall users can open interactive sessions with a firewall using any of the following methods:

A terminal emulator connected to the console port
Telnet
SSH
Web-based management applications such as ASDM or PDM

The following sections provide information about the configuration and use of these methods.

Console Connection

Most Cisco firewall and security appliances have a physical console connection that can be used to access a user interface. The console port is an asynchronous serial interface operating at 9600 baud. Because of its relatively slow speed, the console should be used only to initially configure the firewall or to access it over an out-of-band connection as a last resort.

Because the FWSM is integrated into a Catalyst 6500 or 7600 switch chassis, it does not have a readily accessible console port. It does have an emulated console connection you can reach from the switch user interface by specifying the FWSM module number in the following command:

Switch# session slot module processor 1

The session slot command is actually a special Telnet session to the FWSM over the Catalyst 6500 backplane. Normally, the emulated console session provides reliable access to the FWSM, even if none of its interfaces are operational.

Tip

The FWSM also has a physical console port, like any other firewall platform. However, the console is not easy to access—it is an RJ-45 jack labeled “P0”, located on the FWSM’s printed circuit board.

If you decide to use this console port, you should connect a cable while the FWSM is pulled out of the switch chassis. Then, slide the FWSM in and carefully thread the cable out through an adjacent slot.

Even if you do not connect to the onboard console port, the FWSM keeps a running 1 KB buffer that captures all of the console’s output. You can view the console buffer with the show console-output EXEC command. You can also clear the console buffer with the clear console-output EXEC command. The console buffer can be useful when you need to see the actual bootup messages from the last FWSM boot sequence.

The console port is always active and cannot be disabled. When a user connects to the console port with a terminal emulator, the firewall immediately begins at the unprivileged or user EXEC level. To use any type of administrative or configuration commands, the console user must move into privileged EXEC or enable mode.

Best practice dictates having the firewall close any user session that has been idle for a period of time. By default, console connections never idle out. You can change this behavior with the following configuration command:

Firewall(config)# console timeout minutes

Here, minutes is the idle time value from 0 (no idle timeout; the default) to 60 minutes.

Tip

Even though the FWSM does not have an easily accessible console port, the console timeout command can still be used to close an idle console session. Evidently, this command is meant for environments where the embedded console port is permanently connected to a PC or an out-of-band terminal server.

You can also configure various methods to authenticate users who connect to the console port. Chapter 5, “Managing Firewall Users,” covers these methods in greater detail.

Telnet Sessions

Remote administrators can connect to the firewall using Telnet. Telnet sessions use TCP port 23 and provide the standard firewall command-line interface. Accessing the firewall through Telnet has the following characteristics:

Up to five different Telnet sessions can be open to the firewall concurrently.
Telnet access is much more efficient than the firewall’s console port. Large amounts of output can be displayed without imposing a heavy load on the firewall CPU.
Information sent over a Telnet connection is not secure. No data encryption or authentication is used. (SSH is a more secure alternative.)
Telnet access is permitted on “internal” firewall interfaces if the firewall is configured to do so. The firewall does not permit inbound Telnet connections on its outside interface unless IPSec is configured on that interface for a secure VPN connection.

To configure Telnet operation, use the following configuration steps:

Allow incoming Telnet connections on an interface:
ASA, FWSM

Firewall(config)# telnet ip_address netmask if_name
PIX 6.3

Firewall(config)# telnet ip_address [netmask] [if_name]
Open table as spreadsheet
By default, no Telnet connections are permitted. This command permits inbound Telnet connections from the source addresses defined by ip_address and netmask. The inbound firewall interface is specified as if_name (inside or dmz, for example). You can repeat this command to define multiple Telnet sources.

PIX 6.3 allows these parameters to be optional. If no interface name is given, the firewall allows Telnet connections from the source address on all its interfaces except the outside. ASA and FWSM platforms, however, are more specific and require all the options to be given with the command.

For example, the following command permits inbound Telnet from a host at 192.168.4.13 and the subnet 192.168.177.0/24 on the inside interface:
```
Firewall(config)# telnet 192.168.4.13 255.255.255.255 inside
Firewall(config)# telnet 192.168.177.0 255.255.255.0 inside
```
(Optional) Set the Telnet idle timeout:
```
Firewall(config)# telnet timeout minutes
```
By default, Telnet sessions are automatically closed if they have been idle for 5 minutes. You can change the idle timeout period to minutes (ASA and FWSM: 1 to 1440 minutes, or 24 hours; PIX 6.3: 1 to 60 minutes).

SSH Sessions

Remote administrators can also connect to the firewall using SSH. SSH sessions use TCP port 22 and provide the standard firewall CLI. Accessing the firewall through SSH has the following characteristics:

Up to five different SSH sessions can be open to the firewall concurrently.
An SSH session offers a Telnet look and feel while offering a high level of security.
SSH can be permitted on any firewall interface, including the outside.
A firewall can support two versions of SSH: SSHv1 (beginning with PIX 6.3, ASA 7.0[1], and FWSM) and SSHv2 (beginning with ASA 7.0[1] and FWSM 3.1[1]).
SSHv2 offers data integrity and encryption that is superior to SSHv1.

Tip

SSH sessions always require a username and password for authentication. If no specific authentication method is configured other than a basic password, or if the configured AAA authentication servers are unreachable, you can use username pix and the normal EXEC-level password set with the passwd command.

Although you might not expect it, the pix username works on a PIX, ASA, or FWSM platform.

To configure SSH operation, use the following configuration steps:

Generate an RSA key pair.

An RSA key pair is needed as a part of the SSH security mechanisms. By default, no RSA keys exist in a firewall, so they must be created and saved.

Define a domain name for the firewall:
ASA, FWSM

Firewall(config)# domain-name name
PIX 6.3

Firewall(config)# domain-name name
Open table as spreadsheet
The domain name is given as name (a text string up to 63 characters). This is usually the domain name of the organization or enterprise where the firewall is located, although you can use any arbitrary name. Because the domain name is included in the RSA key pair computation, you should try to use a name that will be stable over time. Otherwise, the RSA keys must be rebuilt with any new domain name configured later.
Compute the RSA key pair:
ASA, FWSM

Firewall(config)# crypto key generate rsa general-keys [modulus modulus]
PIX 6.3

Firewall(config)# ca generate rsa key [modulus]
Open table as spreadsheet
A general-purpose RSA key pair is computed with a modulus or length of modulus bits (512, 768, 1024, or 2048; the default is 768). Generally, a greater modulus provides more security because it makes reversing the key operations more difficult. Longer keys also take longer to generate, requiring more firewall CPU resources. This is not a critical issue, however, because RSA keys are generated only once or only after long periods of time.

As a compromise, the current industry best practice recommends a modulus of 1024 bits.

If you do not define a domain name before using this command, a default domain name (ciscofwsm.com on an FWSM or ciscopix.com on a PIX or ASA) is used.

Save the RSA key information:

ASA, FWSM	-
PIX 6.3	Firewall(config)# ca save all

Open table as spreadsheet

The contents of the RSA key pair are not saved as a part of the firewall configuration. Instead, they must be saved into a private flash memory area. In an ASA or FWSM 3.1+, the RSA keys are automatically saved each time they are generated.

Tip

You can display the public portion of an RSA key pair with the following commands:

ASA, FWSM	Firewall# show crypto key mypubkey rsa
PIX 6.3	Firewall# show ca mypubkey rsa

Open table as spreadsheet

If the firewall’s domain name ever changes, the RSA key pair must be cleared and rebuilt. You can use the following commands to clear the stored key pair:

ASA, FWSM	Firewall# crypto key zeroize rsa default
PIX 6.3	Firewall# ca zeroize rsa

Open table as spreadsheet

Repeat Steps 1a through 1c to regenerate a new key pair based on the new domain name.

Allow incoming SSH connections on an interface:
ASA, FWSM

Firewall(config)# ssh ip_address netmask if_name
PIX 6.3

Firewall(config)# ssh ip_address [netmask] [if_name]
Open table as spreadsheet
By default, no SSH connections are permitted. This command permits inbound SSH connections from the source address given by ip_address and netmask on the firewall interface named if_name (inside or outside, for example).

In PIX 6.3, if the netmask is omitted, a host mask of 255.255.255.255 is assumed. If the if_name is omitted, the firewall automatically duplicates this command for each of its active interfaces.

You can repeat this command to define multiple SSH sources and source interfaces.
(Optional) Specify the supported SSH versions:
ASA, FWSM

Firewall(config)# [no] ssh version {1 | 2}
PIX 6.3

—
Open table as spreadsheet
In releases before ASA 7.0(1) and FWSM 3.1(1), SSHv1 is the only version that is supported. Beginning with ASA 7.0(1) and FWSM 3.1(1), both versions 1 and 2 are supported by default.

This command can be used to restrict SSH support to only a single version, either version 1 or 2. To return to the default where both versions are allowed, use the no ssh version command with no other arguments.

You can see what SSH versions are currently allowed by using the show ssh command. In the following example, SSH support starts with only version 1. The firewall is configured back to the default for versions 1 and 2. Then only version 2 is configured.
```
Firewall# show ssh
Timeout: 30 minutes
Versions allowed: 1
172.21.4.0 255.255.255.0 outside
172.21.6.0 255.255.255.0 outside
Firewall# configure terminal
Firewall(config)# no ssh version
Firewall(config)#
Firewall# show ssh
Timeout: 30 minutes
Versions allowed: 1 and 2
172.21.4.0 255.255.255.0 outside
172.21.6.0 255.255.255.0 outside
Firewall# configure terminal
Firewall(config)# ssh version 2
Firewall(config)#
Firewall# show ssh
Timeout: 30 minutes
Version allowed: 2
172.21.4.0 255.255.255.0 outside
172.21.6.0 255.255.255.0 outside
Firewall#
```
(Optional) Set the SSH idle timeout:
```
Firewall(config)# ssh timeout minutes
```
SSH sessions idle out after 5 minutes by default. You can change the idle timeout to minutes (1 to 60).

ASDM/PDM Sessions

You can also manage, configure, and monitor a firewall through a web-based application. ASDM and PDM are two of the supported applications. Each one runs from an image stored on the firewall itself, which was made available through an embedded web server.

The web-based management application is named differently for the various firewall platforms:

PDM 3 (PIX 500 series running PIX 6.3)
PDM 4 (FWSM)
ASDM 5.0 (ASA and PIX running 7.0), ASDM 6.0 (ASA and PIX running 8.0).

You can use the following steps to configure and prepare a firewall for PDM or ASDM use:

Identify the PDM/ASDM image to use:
ASA

Firewall(config)# asdm image device:/path
PIX 6.3, FWSM

—
Open table as spreadsheet
In releases before ASA 7.0(1), the ASDM image is always stored in a fixed location in flash memory. For example, PIX 6.3 uses flash file 3. Beginning with ASA 7.0 (1), you can specify the flash device (flash:/, disk0:/, or disk1:/) and path to the ASDM image file. If the firewall is in multiple-context security mode, you can use this command only from the system execution space.

In the following example, the ASDM image file is stored as flash:/asdm.bin (flash:/ is also disk0:/ on this platform):
```
Firewall# dir flash:/
Directory of disk0:/
10     -rw-  8688476     06:25:20 Dec 21 2006  asdm.bin
11     -rw-  5031936     06:12:14 Dec 21 2006  image.bin
62881792 bytes total (44142592 bytes free)
Firewall# configure terminal
Firewall(config)# asdm image disk0:/asdm.bin
```
Install the ASDM/PDM image file.

You can copy an ASDM or PDM image file into a firewall’s flash memory with the following commands:
ASA

Firewall# copy url device:/path
PIX 6.3, FWSM

Firewall# copy tftp[:[[//location][/pathname]]] flash:pdm
Open table as spreadsheet
Before ASA 7.0, the PDM image file was automatically stored in the correct location. Therefore, only the flash:pdm destination was needed.

Beginning with ASA 7.0(1), the ASDM image file can be stored anywhere in flash memory and can have an arbitrary filename. You can have one or more ASDM image files stored in flash at any time, provided that you have sufficient storage space, but only one of them can be used to run the application.

The source url can be one of the following:
```
ftp://[user[:password]@]server[:port]/[path/]filename[;type=xy]
tftp://[user[:password]@]server[:port]/[path/]filename
http[s]://[user[:password]@]server[:port]/[path/]filename
```
If the server requires user authentication, you can specify the user ID and password in the user:password@ format. Section “4-2: Managing the Flash File System,” provides more details about copying files into flash memory.

On an ASA, the destination must be a local flash device, such as flash:/, disk0:/, or disk1:/, in a specific path name, given by /path. On FWSM or PIX platforms, the ASDM image file is always written to a fixed location; it overwrites an existing file if one is present.

Permit incoming access.

ASDM and PDM are web-based applications. Therefore, clients must connect to an HTTP server that is embedded in the firewall.

Identify client locations:

ASA, FWSM	Firewall# http ip_address subnet_mask if_name
PIX 6.3	Firewall# http ip_address [subnet_mask] [if_name]

Open table as spreadsheet

Only source or client addresses that fall within the address range given by ip_address and subnet_mask and are located on the firewall interface named if_name (outside, for example) are allowed to connect to the firewall’s HTTP server.

On ASA and FWSM platforms, all the arguments are required and must be given in the command. Prior releases allow optional arguments. For example, if the subnet mask is omitted, a host mask of 255.255.255.255 is assumed. If the interface name if_name (outside, for example) is omitted, the inside interface is assumed.

Note

After you have configured access to the HTTP server, you do not also have to add anything to any of the firewall’s access lists. Inbound HTTP access to the firewall itself is permitted on the configured interface(s) automatically.

Enable the embedded HTTP server:
```
Firewall# http server enable
```

Starting the ASDM or PDM Application from a Web Browser

To run ASDM or PDM from a web browser, point your web browser to the following URL:


https://ip_address[/admin]

The ip_address is the address (or host name) of the firewall interface that is configured to allow HTTP server connections.

The /admin portion of the URL is applicable only to ASA platforms. If the SSL VPN feature is also enabled, the security appliance’s default web page (https://ip_address) is devoted to SSL VPN services rather than ASDM. In this case, you can differentiate between the services by using a more specific URL:

ASDM—https://ip_address/admin
SSL VPN—https://ip_address/access

Note

Your browser must allow popups from the firewall’s address, because ASDM/PDM is automatically started in a new browser window. As well, ASDM/PDM runs as a Java applet that is downloaded from the firewall. Your browser must support Java so that the applet can be run.

As ASDM or PDM begins, you need to authenticate as an administrative user. The firewall can have an authentication method that is specific to HTTP connections, configured with the aaa authentication http console command. Depending on the configuration, you need to use one of the following credentials:

Default authentication— No usernames are defined or used. Therefore, leave the username field blank and enter the enable password.
Local authentication— Usernames are used and are defined locally on the firewall with the username command. Enter a valid username that can use privilege level 15 (enable or privileged EXEC mode) and the appropriate password.
AAA authentication— Usernames are used and are defined on external AAA servers. Enter a valid username that can use privilege level 15 (enable or privileged EXEC mode) and the appropriate password.

Tip

When the ASDM or PDM application connection is initiated, the firewall sends its self-signed SSL certificate to your web browser. Sometimes a browser cannot verify the certificate because the firewall is not known as a trusted certificate authority. If this happens, you likely will see a message from the web browser.

You can choose to accept the certificate temporarily or permanently if you are comfortable that you are connecting to the correct firewall. You can check the firewall’s identity by viewing the certificate; the Common Name (CN) attribute is made up of the firewall’s host name and domain name.

You might also see an error regarding a domain name mismatch. If the firewall’s interface IP address is not registered in a DNS, the browser cannot confirm that its IP address and certificate CN (fully qualified domain name) correlate. If you are comfortable with the mismatch, you can choose to continue.

Starting ASDM from a Local Application

Beginning with ASA 7.0(1), you can run ASDM from a web browser or from a “launcher” application that has been downloaded directly to your PC. The first time you use ASDM, you should point your web browser to the following URL:


https://ip-address/admin

This brings up a web page where you can choose the ASDM access method. Figure 4-8 shows an example of this opening page.

Figure 4-8: Initial ASDM Launch Page

Running ASDM as a local application is usually better because you can use one common program on your PC to access one or more ASA devices. The application also maintains a drop-down list of firewall addresses where you have connected in the past, making it easy to select a target firewall without having to use browser bookmarks or enter URLs.

When the local application is installed, an installer file is downloaded, as shown in Figure 4-9. The installer runs automatically.

Figure 4-9: Local ASDM Application Installation

To run the ASDM launcher application, start the local Cisco ASDM Launcher program. On a Windows PC, it can be found on the Start menu under Programs > Cisco ASDM Launcher. When the launcher starts, it displays a drop-down list of firewall addresses it knows about. Select an address from the list and enter your authentication credentials. Figure 4-10 shows an example of the launcher application.

Figure 4-10: Local ASDM Launcher Application

After you have authenticated, the firewall downloads the most current ASDM application code to your PC via the launcher application. This means the local application rarely needs to be updated. Instead, the PC is always kept current with the actual ASDM software that is contained in the firewall’s ASDM image. As soon as ASDM launches, it looks like the window shown in Figure 4-11.

Figure 4-11: Sample ASDM Session

User Session Banners

You can configure a banner of text that the firewall will display to any administrative users. You can use the following three types of banners:

Message of the Day (MOTD)— An informational message that is shown before the login prompt in a Telnet, SSH, or console session. This might include network news, access policy information, or legal warnings to be presented to potential users.
Login— A message that is shown after the MOTD prompt and just before the firewall login prompt. This might be useful to show a name, location, or other access parameters.
Exec— A message that is shown just after a user successfully logs in and reaches EXEC mode. This might be useful if you need to present some final words of caution or a warning to the user who has just logged in and is about to view or change something on the firewall.

To configure one of these banners, use the following configuration command:

Firewall(config)# banner {exec | login | motd} text

Here, the banner is created one line of text at a time. Do not enclose the text in quotation marks; the text begins after the banner type keyword and ends at the end of the line. Repeat this command for subsequent lines of the banner.

You cannot edit a banner; you have to delete the entire banner with the no banner {exec | login | motd} command and re-enter it. To delete banners of all types, you can use the clear banner (PIX 6.x and FWSM 2.x) or clear configure banner (ASA and FWSM 3.x) command.

You can also customize the banner’s appearance by including the firewall’s host name or domain name. This is done automatically by inserting the token strings $(hostname) and $(domain) within the banner text. The firewall substitutes the current values configured by the hostname and domain-name commands.

Tip

If you decide to use banners on your firewall, be careful what information you include. Remember that the MOTD and login banners are displayed as soon as a Telnet or SSH session connection is opened to the firewall—whether someone can log in or not. That means if someone can initiate a Telnet session and see the login prompt, he can also see any detailed banner information that might reveal the firewall’s location, model, software version, and so on.

Also be careful when you craft a banner message. Most security and legal experts advise against using any type of “Welcome” or “Greetings” message, because this might be used against you. Malicious users might try to suggest that you welcomed them into your firewall! For some best-practice recommendations, refer to http://www.cisco.com/warp/public/707/21.html#warnin.

Monitoring Administrative Sessions

Having a console interface and network access, a firewall can allow several people to be connected at any time.

You can monitor all the active Telnet sessions on a firewall with the EXEC command who, which provides a list of Telnet session numbers along with the originating IP address, as in the following example:

Firewall# who
       1: 172.21.4.16
Firewall#

If you need to close a Telnet session that is either hung or unwanted, use the who command to find the session’s index number. Then use the kill telnet_id privileged EXEC command, where telnet_id is the session index, to terminate that session immediately and without warning. For example, the following commands could be used to end the Telnet session coming from IP address 10.6.6.6:

Firewall# who
0: From 10.10.10.71
1: From 192.168.199.4
2: From 10.6.6.6
Firewall# kill 2

You can also monitor active SSH sessions with this EXEC command:

Firewall# show ssh sessions

For example, a generic user (“pix”) has several SSH sessions open. Notice that SSH version 1 is actually shown as version 1.5. Version 1.5 is commonly used with Cisco IOS Software and has several security fixes beyond that of version 1.0.

Firewall# show ssh sessions
SID Client IP       Version Mode Encryption Hmac     State            Username
0   172.21.4.14     1.5     -    3DES       -        SessionStarted   pix
1   172.21.4.14     2.0     IN   aes256-cbc sha1     SessionStarted   pix
                           OUT  aes256-cbc sha1     SessionStarted   pix
2   172.21.4.14     1.5     -    3DES       -        SessionStarted   pix
3   172.21.4.14     1.5     -    3DES       -        SessionStarted   pix
4   172.21.4.14     1.5     -    3DES       -        SessionStarted   pix

You can disconnect an active or hung SSH session with the following command:

Firewall# ssh disconnect session-id

To display the active ASDM or PDM management application sessions, you can use the following command:

ASA, FWSM	Firewall# show asdm sessions
PIX 6.3	Firewall# show pdm sessions

Open table as spreadsheet

You can disconnect an active PDM session with the following command:

ASA, FWSM	Firewall# asdm disconnect session-id
PIX 6.3	Firewall# pdm disconnect session-id

Open table as spreadsheet

Tip

A firewall can also generate an audit trail that shows user activity. To do this, logging must be enabled on the firewall. See Chapter 10 for logging configuration details.

User authentication messages are generated at Syslog severity 6 (Informational). This also includes SSH and ASDM/PDM sessions.
User privilege level event messages are generated at Syslog severity 5 (Notification).
Firewall commands executed by users are logged at Syslog severity 5 (Notification), and show commands executed are logged at Syslog severity 7 (Debugging).

4-6: Firewall Reloads and Crashes

During a firewall’s normal operation, you might find an occasion to manually reboot or reload it. As well, the firewall might crash on its own, because of some unexpected software or hardware problem, and possibly reload itself. The following sections discuss the methods you can use to make a firewall reload and diagnose the cause of a crash.

4-7: Monitoring a Firewall with SNMP

Simple Network Management Protocol (SNMP) is a protocol that allows the exchange of information about managing a network device. Cisco firewalls can participate in SNMP as follows:

A Management Information Base (MIB) is a collection of variables stored on a network device. The device can update the variables, or they can be queried from an external source.
MIBs are structured according to the SNMP MIB module language, which is based on the Abstract Syntax Notation 1 (ASN.1) language.
An SNMP agent runs on a firewall and maintains various MIB variables. Any query of the variables must be handled through the agent.
The SNMP agent can also send unsolicited messages, or traps, to an SNMP manager. Traps are used to alert the manager of changing conditions on the firewall.
An SNMP manager is usually a network management system that queries MIB variables, can set MIB variables, and receives traps from a collection of network devices.
Cisco firewalls can use SNMP version 1 (SNMPv1), the original version. SNMPv1, based on RFC 1157, has only basic cleartext community strings for security. Access is limited to read-only requests from the IP addresses of one or more SNMP managers.
Beginning with ASA 7.0(1) or FWSM 1.1(1), firewalls can also support SNMP version 2c (SNMPv2c), an enhanced version based on RFCs 1901, 1905, and 1906. SNMPv2c improves on bulk information retrieval and error reporting but still uses only basic cleartext community strings and IP addresses to provide security. (SNMP security is available only in SNMPv3, which currently is not supported on any Cisco firewall platform.)

Tip

SNMP requests and responses are sent using UDP port 161. Notifications or traps are sent using UDP port 162. The SNMP management station can be located on any interface of a firewall, provided that the firewall has sufficient routing information to reach it.

Overview of Firewall SNMP Support

Firewalls can participate in SNMP by maintaining several MIBs. The MIB values are constantly updated with the current values that are in use. For example, one MIB parameter records the average firewall CPU load over a 5-second period. This is based on the CPU usage measurements that can also be shown from the firewall CLI.

SNMP MIBs represent data as a hierarchical tree structure; each MIB variable is referenced by its object identifier (OID). OIDs are formed by concatenating the name or number of a tree branch as the tree is followed from the root to the object’s location in dotted notation.

Figure 4-12 shows the top layers of the standard MIB tree, along with the lower layers that apply to firewalls. The root layer is unnamed. All MIB variables that are useful for network management are located under the internet subtree. Following the tree structure downward, internet is referenced as OID iso.org.dod.internet or 1.3.6.1.

Figure 4-12: SNMP MIB Structure

Tip

Your SNMP management station needs to have several firewall-specific MIBs compiled into its database. Make sure you find these MIBS: IF-MIB, RFC1213-MIB, CISCO-MEMORY-POOL-MIB, CISCO-PROCESS-MIB, ENTITY-MIB, CISCO-SMI, and CISCO-FIREWALL-MIB.

ASA also adds CISCO-IPSEC-FLOW-MONITOR-MIB, CISCO-FIPS-STAT-MIB, and ALTIGA-SSL-STATS-MIB.

These can all be obtained for free from Cisco.com at http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml.

Firewall MIBs

A firewall uses the mgmt subtree (iso.org.dod.internet.mgmt or 1.3.6.1.2) to contain several useful objects, all organized under the mib-2 subtree (1.3.6.1.2.1). These objects are defined in the RFC1213-MIB file (1.3.6.1.2.1.11). They fall into these categories:

system— Descriptions of the firewall, uptime, and network services
interfaces— Parameters and counters for each interface
ip— IP addresses, subnet masks, and broadcast addresses assigned to each interface

Many of the values maintained in the mib-2 subtree can also be seen with the show snmp-server (PIX 6.x), show running-config snmp-server (ASA), show version, and show interface EXEC commands.

The EntityMIB subtree (1.3.6.1.2.1.47) is also included. It is defined by the ENTITY-MIB file, which is based on RFC 1212. This was added to ASA 7.0(1) to support the firewall chassis and field-replaceable units (FRU) available on the ASA platforms.

The private (1.3.6.1.4) subtree contains one subtree, enterprise (1.3.6.1.4.1), where all network vendor-specific objects are located. The Cisco private MIB structure is contained in the cisco subtree (1.3.6.1.4.1.9). The set of specific MIBs that are included under the cisco MIB tree varies according to the hardware platform (router, switch, firewall, and so on).

A firewall maintains several subtrees under iso.org.dod.internet.private.enterprise.cisco.mgmt, as follows:

The ciscoMemoryPool subtree (1.3.6.1.4.1.9.9.48) has objects that are defined in the CISCO-MEMORY-POOL-MIB file. These describe the current status of firewall memory. It can also be seen with the show blocks EXEC command.
The ciscoProcess subtree (1.3.6.1.4.1.9.9.109) is defined by the CISCO-PROCESS-MIB file. These values describe the firewall’s CPU usage over 5-second, 1-minute, and 5-minute periods. The same values can be seen with the show cpu usage EXEC command.
The ciscoFirewall subtree (1.3.6.1.4.1.9.9.147) is defined by the CISCO-FIREWALL-MIB file. A number of values are maintained that describe the current memory buffer usage (cfwBufferStat) and the connection usage (cfwConnectionStat) in the firewall. These correspond to the output of the show memory and show conn count EXEC commands, respectively.
The ciscoIpSecFlowMonitorMIB subtree (1.3.6.1.4.1.9.9.171) is defined by the CISCO-IPSEC-FLOW-MONITOR-MIB file. This was added to ASA and FWSM platforms to support IPSec VPN functionality to report on tunnel statistics.
The ciscoRemoteAccessMonitorMIB subtree (1.3.6.1.4.1.9.9.392) is defined by the CISCO-REMOTE-ACCESS-MONITOR-MIB file. This was added to ASA 7.0(1) to support VPN client session statistics, but removed in ASA 8.0.
The ciscoFipsStatsMIB subtree (1.3.6.1.4.1.9.9.999999) is defined by the CISCO-FIPS-STAT-MIB file. This was added to ASA 7.0(1) to support reporting on IPSec cryptographic engine operations, but removed in ASA 8.0.
The altigaSSLstats subtree (1.3.6.1.4.1.3076.2.1.2.26) is defined by the ALTIGA-SSL-STATS-MIB file. This was added to ASA 7.0(1) to support reporting on SSL VPN session statistics.

Firewall SNMP Traps

A firewall can send notification or trap messages to SNMP management stations when certain events occur. This allows the management station to receive alerts in real time and relay them to the appropriate networking personnel.

Generic traps are sent when firewall links (interfaces) go up or down, when the firewall is reloaded (a “warm start”) or booted up (a “cold start” after power is applied) for some reason, and when an SNMP poll has been received with an incorrect community string. Syslog messages can also be sent as SNMP traps if the firewall is configured to do so.

When SNMP traps are sent, the firewall’s OID is included. This allows the SNMP management station to determine what type of device has sent the trap. Cisco firewall models use the unique OIDs shown in Table 4-9. Notice that the OIDs use most of the same tree hierarchy as SNMP MIBs. For example, 1.3.6.1.4.1.9. would lead to the private.enterprise.cisco. subtree. This is followed by .1., which points to the Cisco products subtree, which is followed by a number that uniquely identifies the firewall model.

Table 4-9: Firewall OID Values Used in SNMP Traps
Open table as spreadsheet
Firewall Model	OID
PIX 501	`1.3.6.1.4.1.9.1.417`
PIX 506	`1.3.6.1.4.1.9.1.389`
PIX 506E	`1.3.6.1.4.1.9.1.450`
PIX 515 single context mode	`1.3.6.1.4.1.9.1.390`
PIX 515 security context	`1.3.6.1.4.1.9.1.678`
PIX 515 system context	`1.3.6.1.4.1.9.1.768`
PIX 515E single context mode	`1.3.6.1.4.1.9.1.451`
PIX 515E security context	`1.3.6.1.4.1.9.1.677`
PIX 515E system context	`1.3.6.1.4.1.9.1.769`
PIX 520	`1.3.6.1.4.1.9.1.391`
PIX 525 single context mode	`1.3.6.1.4.1.9.1.392`
PIX 525 security context	`1.3.6.1.4.1.9.1.676`
PIX 525 system context	`1.3.6.1.4.1.9.1.770`
PIX 535 single context mode	`1.3.6.1.4.1.9.1.393`
PIX 535 security context	`1.3.6.1.4.1.9.1.675`
PIX 535 system context	`1.3.6.1.4.1.9.1.771`
FWSM single context mode	`1.3.6.1.4.1.9.1.522`
FWSM security context	`1.3.6.1.4.1.9.1.674`
ASA 5505	`1.3.6.1.4.1.9.1.745`
ASA 5510	`1.3.6.1.4.1.9.1.669`
ASA 5520 single context mode	`1.3.6.1.4.1.9.1.670`
ASA 5520 security context	`1.3.6.1.4.1.9.1.671`
ASA 5520 system context	`1.3.6.1.4.1.9.1.764`
ASA 5540 single context mode	`1.3.6.1.4.1.9.1.672`
ASA 5540 security context	`1.3.6.1.4.1.9.1.673`
ASA 5540 system context	`1.3.6.1.4.1.9.1.765`
ASA 5550 single context	`1.3.6.1.4.1.9.1.753`
ASA 5550 security context	`1.3.6.1.4.1.9.1.763`
ASA 5550 system context	`1.3.6.1.4.1.9.1.766`
Other (original PIX models)	`1.3.6.1.4.1.9.1.227`

The only exception is when Syslog messages are sent as SNMP traps with the logging history command. The OID used is always 1.3.6.1.4.1.9.9.41.2, regardless of the sending firewall platform.

Tip

You can find the entire list of Cisco product OIDs in the CISCO-PRODUCT-MIB file at ftp://ftp.cisco.com/pub/mibs/oid/CISCO-PRODUCTS-MIB.oid.

SNMP Configuration

You can use the following steps to configure SNMP operation so that a firewall or security appliance platform can be remotely monitored:

Define the SNMP identity.
1. Identify the firewall location:
  ASA, FWSM
  
  Firewall(config)# snmp-server location string
  
  PIX 6.3
  
  Firewall(config)# snmp-server location string
  Open table as spreadsheet
  Someone at a management station can learn of the firewall’s location by querying the location. This is given by string (a text string of up to 127 characters, including spaces).
2. Identify the firewall administrator:
  ASA, FWSM
  
  Firewall(config)# snmp-server contact string
  
  PIX 6.3
  
  Firewall(config)# snmp-server contact string
  Open table as spreadsheet
  Querying this string tells someone who to contact in case of firewall problems or issues. The contact information is given by string (a text string of up to 127 characters).

Allow SNMP access.

Permit access for a specific management station:

ASA, FWSM


Firewall(config)# snmp-server host if_name ip_addr [poll |
trap] [community commstr] [version version] [udp-port
udp_port]

PIX 6.3

Firewall(config)# snmp-server host if_name ip_addr [poll | trap]

Open table as spreadsheet

The management station can be found on the firewall interface named if_name (inside or outside, for example) at IP address ip_addr. This command can be repeated to define up to five different stations for PIX 6.3 or up to 32 stations for ASA and FWSM.

The type of access opened to the management station is given by the poll or trap keywords. With poll, the station is allowed to poll the firewall with SNMP queries. The trap keyword allows the firewall to send SNMP traps to the management station. By default, only the cold start, link up/down, and SNMP authentication failure traps are sent. On an FWSM platform, you can add the udp-port keyword to specify the UDP port that is used when sending SNMP traps.

If neither keyword is given, both poll and trap actions are permitted. Specifying poll causes traps to be denied, and specifying trap causes polls to be denied.

ASA and FWSM platforms allow additional SNMP parameters to be set on a per-server basis. You can use the community keyword to specify a community string commstr (up to 32 characters, without spaces) that is used as a weak authentication for the server. If a community string is not defined with this command, a global community string (defined in Step 2b) is automatically configured for the server. If no global string has been defined, the server entry is marked as “pending” until a valid community string is defined.

By default, SNMP version 1 is used. You can use the version keyword to specify the SNMP version that the server uses as version (1 for SNMPv1 or 2c for SNMPv2c). If the server uses something other than the default UDP port 161, you can set the UDP port to udp_port (0 to 65535).

Define an SNMP community string:

ASA, FWSM	Firewall(config)# snmp-server community key
PIX 6.3	Firewall(config)# snmp-server community key

Open table as spreadsheet

A community string acts as a shared secret password that authenticates any management station’s SNMP polls. If the string key (up to 32 characters, without spaces; the default is public) matches between the incoming polls and the firewall itself, the polls are answered. If this command is not entered, default community string public is used.

ASA and FWSM use this command to define one “global” community string that can be used for any SNMP server that is configured without one. If this command is not entered, there is no default community string. Instead, community strings can be configured on a per-host basis as part of the snmp-server host command.

Tip

Even though the SNMP community string is sent as cleartext within SNMP packets, it should still be viewed as a rudimentary password security method. Therefore, you should always change its value to something other than the default “public.”

(Optional) Define the SNMP poll UDP port:
ASA, FWSM

Firewall(config)# snmp-server listen-port port
PIX 6.3

—
Open table as spreadsheet
ASA and FWSM platforms use this command to define a “global” UDP port that can be used to listen for SNMP polls. By default, UDP port 161 is used. This can be overridden on a per-host basis with the snmp-server host command.
(Optional) Send specific trap types:
ASA, FWSM

Firewall(config)# snmp-server enable traps {all | type}
PIX 6.3

Firewall(config)# snmp-server enable traps
Open table as spreadsheet
In PIX platforms, only generic SNMP traps are sent to any management station configured for traps. This includes cold start, link up/down, and SNMP authentication failure traps.

You can also send Syslog messages as SNMP traps with this command. You can set the severity level threshold of the messages to be sent with the logging history level command.

ASA and FWSM offer more types of traps to be identified and sent. The all keyword allows all types of traps. You can specify a trap type as one of the following sets of keywords:
- firewall [security]
  
  Traps are sent for any type of firewall inspection, content inspection, attack detection, and so on, as defined in the CISCO-FIREWALL-MIB file. The security traps are assumed, whether or not the security keyword is given.
- snmp [authentication] [coldstart] [linkdown] [linkup]
  
  Generic SNMP traps are sent for SNMP authentication failures, firewall cold starts (power cycles), and interface state changes. These are defined in the SNMPv2-MIB file. If only the snmp keyword is given, all the optional keywords are assumed.
- syslog
  
  Syslog messages are sent as SNMP traps. You should also set the severity level threshold of the messages to be sent with the logging history level command.
The following trap type and keywords can be used on ASA and FWSM platforms only:
- entity [config-change] [fru-insert] [fru-remove]
  
  Traps are sent if the firewall configuration is changed or if an FRU is installed or removed (ASA platforms only). These are defined in the CISCO-ENTITY-FRU-CONTROL-MIB file. If only the entity keyword is given, all the optional keywords are assumed.
- ipsec [start] [stop]
  
  Traps are sent based on IPSec tunnel creation and deletion, as defined in the CISCO-IPSEC-FLOW-MONITOR-MIB file. If only the ipsec keyword is given, the other options are assumed.
- remote-access [session-threshold-exceeded]
  
  Traps are sent as VPN clients connect and disconnect, as defined in the CISCO-REMOTE-ACCESS-MONITOR-MIB file. Optionally, traps can be sent if the number of VPN client sessions exceeds a threshold.

FWSM	Firewall# dir [/all] [/recursive] [disk:[path]]
ASA	Firewall# dir [/all] [/recursive] [flash:[path]]

FWSM	Firewall# cd [disk:][path]
ASA	Firewall# cd [flash:][path]

FWSM	Firewall# more [/ascii \| /binary] [disk:]path
ASA	Firewall# more [/ascii \| /binary] [flash:]path

FWSM	Firewall# delete [/noconfirm] [/recursive] [disk:][/path]filename
ASA	Firewall# delete [/noconfirm] [/recursive] [flash:][/path]filename

FWSM	Firewall# rename [/noconfirm] [disk:] [source-path] [disk:] [destination-path]
ASA	Firewall# rename [/noconfirm] [flash:] [source-path] [flash:] [destination-path]

FWSM	Firewall# mkdir [/noconfirm] [disk:]path
ASA	Firewall# mkdir [/noconfirm] [flash:]path

FWSM	Firewall# rmdir [/noconfirm] [disk:]path
ASA	Firewall# rmdir [/noconfirm] [flash:]path

FWSM	Firewall# format disk:
ASA	Firewall# format flash:

ASA, FWSM	Firewall(config)# telnet ip_address netmask if_name
PIX 6.3	Firewall(config)# telnet ip_address [netmask] [if_name]

ASA, FWSM	Firewall(config)# domain-name name
PIX 6.3	Firewall(config)# domain-name name

ASA, FWSM	Firewall(config)# crypto key generate rsa general-keys [modulus modulus]
PIX 6.3	Firewall(config)# ca generate rsa key [modulus]

ASA, FWSM	Firewall(config)# ssh ip_address netmask if_name
PIX 6.3	Firewall(config)# ssh ip_address [netmask] [if_name]

ASA, FWSM	Firewall(config)# [no] ssh version {1 \| 2}
PIX 6.3	—

ASA	Firewall(config)# asdm image device:/path
PIX 6.3, FWSM	—

ASA	Firewall# copy url device:/path
PIX 6.3, FWSM	Firewall# copy tftp[:[[//location][/pathname]]] flash:pdm

ASA, FWSM	Firewall(config)# snmp-server location string
PIX 6.3	Firewall(config)# snmp-server location string

ASA, FWSM	Firewall(config)# snmp-server contact string
PIX 6.3	Firewall(config)# snmp-server contact string

ASA, FWSM	Firewall(config)# snmp-server listen-port port
PIX 6.3	—

ASA, FWSM	Firewall(config)# snmp-server enable traps {all \| type}
PIX 6.3	Firewall(config)# snmp-server enable traps

4-2: Managing the Flash File System

Navigating an ASA or FWSM Flash File System

Administering an ASA or FWSM Flash File System

Using the PIX 6.3 Flash File System

Identifying the Operating System Image

Upgrading an Image from the Monitor Prompt

Upgrading an Image from an Administrative Session

Upgrading an Image Automatically

4-3: Managing Configuration Files

Managing the Startup Configuration

Selecting a Startup Configuration File

Displaying the Startup Configuration

Saving a Running Configuration

Viewing the Running Configuration

Saving the Running Configuration to Flash Memory

Saving the Running Configuration to a TFTP Server

Forcing the Running Configuration to Be Copied Across a Failover Pair

Forcing the Startup (Nonvolatile) Configuration to Be Cleared

Importing a Configuration

Entering Configuration Commands Manually

Merging Configuration Commands from Flash Memory

Merging Configuration Commands from a TFTP Server

Merging Configuration Commands from a Web Server

Merging Configuration Commands from an Auto Update Server

4-4: Automatic Updates with an Auto Update Server

4-5: Managing Administrative Sessions

Console Connection

Telnet Sessions

SSH Sessions

ASDM/PDM Sessions

Starting the ASDM or PDM Application from a Web Browser

Starting ASDM from a Local Application

User Session Banners

Monitoring Administrative Sessions

4-6: Firewall Reloads and Crashes

4-7: Monitoring a Firewall with SNMP

Overview of Firewall SNMP Support

Firewall MIBs

Firewall SNMP Traps

SNMP Configuration

0 comments

Post a Comment

About Me

Chat Box

Google Maps

Visitor Locations

Lunar Calendar

Link URL

Followers

Lưu Trữ - Archive

Others

Posted