commands starting with show ip. Next, the
administrator will verify the configuration by entering and
viewing the available commands. When a user enters the CLI
view, an indication message appears. Apart from the commands
enable and exit that are available in all views,
the only two commands that are visible in the CLI view are
configure and show. Figure shows a sample output
of the enable command. To further verify the view
configuration, the user looks at the available options of the
show command. The available options include
parser, which is always available, and the configured
keywords ip and version. Next, the user verifies
that all sub-options of the show ip command are
available in the view as shown in Figure .
Content
5.6 Configuring Role-Based CLI
5.6.7 Secure Configuration Files A great
challenge for network operators is to deal with the total
downtime experienced after a router has been compromised and
operating software and configuration data erased from the
router’s persistent storage. The operator must retrieve an
archived copy (if a copy exists) of the configuration and a
working image to restore the router. Recovery must then be
performed for each affected router, adding to the total network
downtime. The Cisco IOS Resilient Configuration feature enables
a router to secure and maintain a working copy of the running
image and configuration so that those files can withstand
malicious attempts to erase the contents of persistent storage
in NVRAM and flash. The Cisco IOS Resilient Configuration
feature is intended to speed up the recovery process. The
feature maintains a secure working copy of the router image and
the startup configuration at all times. These secure files
cannot be removed by the user. This set of image and router
running configuration is referred to as the primary bootset.
The design of Cisco IOS Resilient Configuration considered the
following factors, which are summarized in Figure : -
The configuration file in the primary bootset is a copy of the
running configuration that was in the router when the feature
was first enabled.
- The feature secures the smallest
working set of files to preserve persistent storage space. No
extra space is required to secure the primary Cisco IOS image
file.
- The feature automatically detects image or
configuration version mismatch.
- Only local storage is
used for securing files, eliminating scalability maintenance
challenges from storing multiple images and configurations on
TFTP servers.
- The feature can be disabled only
through a console session.
Restrictions for Cisco
IOS Resilient Configuration
The Cisco IOS Resilient
Configuration feature is available only on platforms that
support a Personal Computer Memory Card International
Association (PCMCIA) Advanced Technology Attachment (ATA) disk.
There must be enough space on the storage device to accommodate
at least one Cisco IOS image and a copy of the running
configuration. It may be possible to forcefully remove secured
files using an older version of Cisco IOS software that does
not contain file system support for hidden files. Cisco IOS
Resilient Configuration can be disabled only by using a console
connection to the router. With the exception of the upgrade
scenario, feature activation does not require console access.
Secured files do not appear in the output of a dir
command from the executive shell prompt. ROMMON mode does not
have any such restriction and can be used to list and boot
secured files. The running image and running configuration
archives will not be visible in the Cisco IOS dir
command output. Instead, you must use the show secure
bootset command to verify archive existence. Securing
Configuration Files
To secure the running image and the
startup configuration file, use the commands secure
boot-image and secure boot-config in the
configuration mode as shown in Figure . To verify the status of
the resilience feature and the primary bootset filename, use
the show secure bootset command. Cisco IOS Resilient
Configuration Feature Verification
The example printout
in Figure shows a sample output of the show secure
bootset command. The printout shows the status of the
resilience feature and the primary bootset filename (both the
startup configuration and the running image). Secure
Configuration Files Recovery
When a router is
compromised, you may have to reload it to start the recovery
procedure. Reloading is not always necessary and may depend on
the circumstances. You can use the reload command in the
router privileged mode to restart the router and interrupt the
boot sequence to enter the ROMMON mode. In the ROMMON, use the
dir and boot commands shown in Figure to view the
contents of the file system and select a secure image to boot
the router from. When the router recovery process starts in the
ROMMON mode, you can view the contents of the file system with
the dir command to identify the image that the router
should boot from. Then use the boot command to load the
specified secured image. After the router boots and if the
startup configuration was deleted, the router prompts you for
interactive configuration input. You should decline to enter an
interactive configuration session in setup mode if you secured
the configuration file. Instead, use the secure
boot-config restore command to recover the secured startup
configuration and save the configuration under a specified
filename (slot0:rescue in Figure ). Finally, copy the
recovered file to the running configuration to resume normal
operations.
Content 5.7 Mitigating Threats and
Attacks with Access Lists 5.7.1 Overview of
Cisco ACL The Cisco ACL is probably the most commonly used
object in Cisco IOS software. The ACLs are not only used for
packet filtering (a type of firewall) but also for selecting
types of traffic that you want to analyze, forward, or
influence in some way. An ACL is a list of statements. Each
statement defines a pattern that would be found in an IP
packet. As each packet comes through an interface with an
associated ACL, the list is scanned from top to bottom and in
the exact order in which the list was entered, for a pattern
that matches the incoming packet. A permit or deny rule
associated with the pattern determines what happens to that
packet. Cisco routers use ACLs as packet filters to decide
which packets can access a router service or which packets can
be allowed through an interface. Packets that are allowed
across an interface are called permitted packets. Packets that
are not allowed across an interface are called denied packets.
ACLs contain one or more rules or statements that determine
which data is to be permitted or denied across an interface.
ACLs are designed to enforce one or more corporate security
policies. For example, a corporate security policy may allow
only packets that use source addresses from within the trusted
network to access the Internet. Once this policy is written,
you can develop an ACL that includes certain statements which,
when applied to a router interface, can implement the policy.
Cisco router security depends upon well-written ACLs to
restrict access to router network services and to filter
packets as the packets traverse the router. Cisco routers
support three types of IP ACLs: standard, extended, and
enhanced IP ACLs. The examples in Figure describe two types:
- Standard IP ACLs: A standard ACL only allows
you to permit or deny traffic from specific IP addresses. The
destination of the packet and the ports that are involved do
not matter. The first example in Figure allows traffic from all
addresses in the range 192.168.3.0 to 192.168.3.255.
-
Extended IP ACLs: An IP extended ACL is a list of
statements that are created in global mode. This list can
filter IP packets based on several attributes (protocol type,