Cisco Anomaly Guard Module Configuration Guide (Software Version 6.1 and 6.1-XG)
Using Guard Module Diagnostic Tools

Table Of Contents

Using Guard Module Diagnostic Tools

Displaying the Installed Software Version Number and License Agreement

Displaying the Software License Key Information

Displaying the Guard Module Configuration

Displaying the Guard Module Zone Operating Status

Using Counters to Analyze Traffic

Displaying Counters and Average Traffic Rates

Clearing Guard Module and Zone Counters

Displaying the Zone Status

Displaying Zone Proxy Usage

Managing Guard Module Logs

Configuring the Logging Parameters

Managing Online Event Logs

Displaying Online Event Logs

Exporting Online Event Logs

Managing the Log File

Displaying the Log File

Copying the Log File to a Network Server

Clearing the Log File

Monitoring Network Traffic and Extracting Attack Signatures

Configuring the Guard Module to Automatically Record Traffic

Activating the Guard Module to Manually Record Traffic

Stopping the Guard Module from Manually Recording Traffic

Displaying Manual Packet-Dump Settings

Exporting Packet-Dump Capture Files Automatically

Exporting Packet-Dump Capture Files Manually

Importing Packet-Dump Capture Files

Displaying Packet-Dump Capture Files

Generating Attack Signatures from Packet-Dump Capture Files

Copying Packet-Dump Capture Files

Deleting Packet-Dump Capture Files

Displaying General Diagnostic Data

Displaying Flash Memory Usage

Displaying Memory Consumption

Displaying the CPU Utilization

Monitoring System Resources

Managing the ARP Cache

Displaying Network Statistics

Using Traceroute

Verifying Connectivity

Obtaining Debug Information

Displaying the Guard Module Self-Protection Configuration

Understanding the Flex-Content Filter Default Configurations


Using Guard Module Diagnostic Tools


This chapter describes how to display statistics and diagnostics on the Cisco Anomaly Guard Module (Guard module).


Note Operational and configuration differences exist between a Guard module operating at 1 Gbps and a Guard module operating at 3 Gbps. This chapter discusses the differences between the 1-Gbps operation and the 3-Gbps operation. Unless stated, the information in this chapter applies to both modes of operation. For more information, see the "Understanding the 1-Gbps and 3-Gbps Bandwidth Options" section on page 1-7.


This chapter contains the following sections:

Displaying the Installed Software Version Number and License Agreement

Displaying the Software License Key Information

Displaying the Guard Module Configuration

Displaying the Guard Module Zone Operating Status

Using Counters to Analyze Traffic

Displaying the Zone Status

Displaying Zone Proxy Usage

Managing Guard Module Logs

Monitoring Network Traffic and Extracting Attack Signatures

Displaying General Diagnostic Data

Displaying Flash Memory Usage

Displaying Memory Consumption

Displaying the CPU Utilization

Monitoring System Resources

Managing the ARP Cache

Displaying Network Statistics

Using Traceroute

Verifying Connectivity

Obtaining Debug Information

Displaying the Guard Module Self-Protection Configuration

Understanding the Flex-Content Filter Default Configurations

Displaying the Installed Software Version Number and License Agreement

You can display the software licensing agreement and the version number of the software image loaded on your Guard module. Viewing the version number allows you to verify which of the following bandwidth options your Guard module is using:

1-Gbps operation—The maximum bandwidth for traffic between the Guard module and the supervisor engine is 1 Gbps and all data traffic moves over one interface port only.

3-Gbps operation—The maximum bandwidth for traffic between the Guard module and the supervisor engine is 3 Gbps and all data traffic moves over all three interface ports. If the installed software image allows 3-Gbps operation, it will contain the XG designator in its version number (for example, Cisco Cisco Anomaly Guard Module Image version 6.0(0.39)-XG).


Note For 3-Gbps operation, you must have the associated software license key installed for the Guard module to operate (see the "Displaying the Software License Key Information" section).


To display the software version number and licensing agreement information, use the following command:

show version

Displaying the Software License Key Information

If the Guard module is using the XG version of the software image for 3-Gbps operation, then you can display information related to the license key required to activate the XG software image. Display the license key information to verify the following information:

The license key is loaded.

The license key has not expired. If the license key is a demo version, the expiration date of the demo license key displays. If the installed license key is a permanent one, then the word permanent displays as the expiration date.


Note The software image for 1-Gbps operation does not require a license key. To verify which software image is currently loaded on the Guard module, use the show version command (see the "Displaying the Installed Software Version Number and License Agreement" section).


To display the software version number and licensing agreement information, use the following command:

show license-key

Displaying the Guard Module Configuration

You can display the Guard module configuration file, which includes information about the Guard module configuration, such as interface IP addresses, default gateway addresses, and configured zones.

To display the Guard module configuration file, use the following command:

show running-config [all | guard | interfaces [interface_name[.vlan_name]] | self-protection | zones]

Table 13-1 provides the arguments and keywords for the show running-config command.

Table 13-1 Arguments and Keywords for the show running-config Command 

Parameter
Description

all

(Optional) Displays configuration files of all Guard module functions (Guard module, zones, interfaces, and self-protection).

guard

(Optional) Displays the Guard module configuration file.

interfaces

(Optional) Displays the configuration file for all of the Guard module interfaces.

interface_name

(Optional) Name of a specific interface.

For 1-Gbps operation, the valid names are as follows:

eth1

giga 2

For 3-Gbps operation, the valid names are as follows:

giga 1

giga 2

giga 3

.vlan_name

(Optional) Name of a specific VLAN. Enter a decimal point (.) followed by the name of an existing VLAN (no spaces).

self-protection

(Optional) Displays the Guard module self-protection configuration.

zones

(Optional) Displays the configuration files of all zones.


The following example shows how to display the Guard module configuration file:

user@GUARD# show running-config guard

The configuration file consists of the commands that you enter to configure the Guard module with the current settings. You can export the Guard module configuration file to a remote FTP server for backup purposes or for implementing the Guard module configuration parameters on another Guard module. See the "Displaying the Guard Module Zone Operating Status" section for more information.

Displaying the Guard Module Zone Operating Status

You can display an overview of the zones to see which zones are active and what their current status is by entering the following command in global mode:

show

Table 13-2 describes the possible operating states of a zone.

Table 13-2 Zone Status

Status
Description

Auto protect mode

Zone protection is enabled, and the dynamic filters are activated without user intervention.

The Guard module displays (+learning) next to the zone name if zone protection is enabled and the Guard module is learning zone traffic characteristics for policy threshold tuning.

Interactive protect mode

Zones are in interactive protect mode, and the dynamic filters are activated manually.

Threshold Tuning phase

Zones are in the threshold tuning phase. The Guard module analyzes the zone traffic and defines thresholds for the policies that were constructed during the policy construction phase of the learning process.

Policy Construction phase

Zones are in the policy construction phase, and the zone policies are created.

Standby

Zones are not active.


The following example shows how to display an overview of the Guard module zones:

user@GUARD# show

Using Counters to Analyze Traffic

You can display Guard module and zone counters to display information about the current traffic that the Guard module is handling, analyze zone traffic, and perform monitoring tasks.

This section contains the following topics:

Displaying Counters and Average Traffic Rates

Clearing Guard Module and Zone Counters

Displaying Counters and Average Traffic Rates

To display the zone counters, use one of the following commands:

show [zone zone-name] ratesDisplays the average traffic rates of the malicious and the legitimate counters.

show [zone zone-name] rates detailsDisplays the average traffic rates for all Guard module counters.

show [zone zone-name] rates historyDisplays the average traffic rates of the malicious and the legitimate counters for every minute in the past 24 hours.

show [zone zone-name] counters—Displays the Guard module malicious and legitimate counters.

show [zone zone-name] counters details—Displays all Guard module counters.

show [zone zone-name] counters history—Displays the values of the malicious and the legitimate counters for every minute in the past hour.

To display the Guard module counters, use the command in global or configuration mode.

To display the zone counters, use the command in one of the following command modes:

Zone configuration mode—Do not use the zone zone-name keyword and argument because you are in the specific zone configuration mode already.

Global or configuration mode—Enter the zone keyword and the zone-name argument to specify the zone name.

The rate units are in bits per second (bps) and in packets per second (pps).


Note Zone rates are available only when you enable zone protection or activate the learning process.


The counter units are in packets and in kilobits. The counters are set to zero when you activate zone protection.

Table 13-3 displays the Guard module counters.

Table 13-3 Guard Module Counters 

Counter
Description

Malicious

Malicious traffic destined to the zone. Malicious traffic is the sum of the dropped counter and the spoofed counter (which also include the zombie packets).

Legitimate

Legitimate traffic forwarded by the Guard module to the zones.

Received

Packets received and handled by the Guard module. The Received counter is the sum of the legitimate counter and the malicious counter.

Forwarded

Legitimate traffic forwarded by the Guard module to the zones.

Dropped

Packets that were identified by the Guard module protection functions (dynamic filters, flex-content filters, and rate limiter) as part of an attack and dropped.

Replied

Packets to which replies were sent to the initiating client as part of the anti-spoofing or anti-zombie functions to verify whether they are part of authentic traffic or part of an attack.

Spoofed

Packets that were identified by the Guard module as spoofed packets and not forwarded to the zone. Spoofed packets are replied packets (see the Replied counter entry in this table for more information) for which no replies were received. Zombie packets are also included in the spoofed packets counter.

Invalid zone

Traffic that is not destined to any one of the zones for which protection is enabled. This information is available for Guard module counters only (if you enter the command in global or configuration mode without using the zone keyword).


The following example shows how to display the Guard module average traffic rates:

admin@GUARD# show rates

Clearing Guard Module and Zone Counters

You can clear the Guard module or zone counters if you are going to perform testing and want to be sure that the counters include information from the testing session only. The Guard module clears the counters and the average traffic rates.

To clear the Guard module counters, use the following command in global or configuration mode:

clear counters

The following example shows how to clear the Guard module counters:

user@GUARD-conf# clear counters

To clear the zone counters, use one of the following commands:

clear counters—Use this command from the zone configuration mode.

clear zone zone-name counters—Use this command from the global or configuration mode. The zone-name argument specifies the name of the zone.

The following example shows how to clear the zone counters:

user@GUARD-conf-zone-scannet# clear counters

Displaying the Zone Status

To display an overview of the zone and its current status, use the following command in zone configuration mode:

show

The overview includes the following information:

Zone status—Indicates the operation state. The operation state can be one of the following: protect mode, protect and learning mode, threshold tuning mode, policy construction mode, or inactive.

Zone basic configuration—Describes the basic zone configuration, such as automatic or interactive protect mode, thresholds, timers, and IP addresses.

See the "Configuring Zone Attributes" section on page 6-6 for more information.

Zone filters—Includes the flex-content filter configuration, the user filter configuration, and the number of active dynamic filters. If the zone is in interactive protect mode, the overview displays the number of recommendations.

See the "Configuring Flex-Content Filters" section on page 7-4 and the "Configuring User Filters" section on page 7-14 for more information.

Zone traffic rates—Displays the zone legitimate and malicious traffic rates.

See the "Using Counters to Analyze Traffic" section for more information.

The following example shows how to display the zone status:

user@GUARD-conf-zone-scannet# show

Displaying Zone Proxy Usage

The Guard module monitors proxy usage by each of the zones. The Guard module uses the proxy IP addresses during the TCP strong authentication and Domain Name System (DNS) authentication processes. The ability of the Guard module to perform these processes is limited due to the limited number of TCP ports per proxy. When there are no available proxy ports, the Guard module can no longer open new authenticated connections, resulting in dropped connections. To prevent this problem, you can monitor the percentage of proxy ports being used by a zone.

To display the zone proxy usage information, use one of the following commands:

show zone zone-name proxy-usage—Use this command from the global mode. The zone-name argument is the name of the zone that you want to monitor for proxy usage.

show proxy-usage—Use this command from the zone configuration mode.

To display only the maximum proxy usage among active zones, use the following command from global or configuration mode:

show resources

See the "Monitoring System Resources" section for more information.

The Guard module displays the percentage of the proxy ports being used on a per Guard module port basis: 1 port for 1-Gbps operation; 3 ports for 3-Gbps operation.

To decrease the percentage of proxy ports being used by a zone, perform one of the following actions (listed in order of preference):

Increase the number of proxy IP addresses—We recommend this course of action. See the "Configuring the Proxy IP Address" section on page 3-12 for more information.

Reconfigure the zone policy thresholds—Raise the policy thresholds so that fewer source IP addresses require the strong protection level. See the "Configuring the Policy Threshold" section on page 8-15 for more information.

Make the zone a TCP_NO_PROXY zone—Recreate and reconfigure the zone using the GUARD_TCP_NO_PROXY zone template. This zone template does not use the strong protection level. See the "Creating a New Zone" section on page 6-4 for more information.

The following example shows how to display the proxy usage for the scannet zone:

user@GUARD-conf-zone-scannet# show proxy-usage

5.0% (3225/64511)

Managing Guard Module Logs

The Guard module automatically logs system activity and events. You can export and display the Guard module logs to review and track the Guard module activity.

Table 13-4 displays the event log levels.

Table 13-4 Event Log Levels 

Event Level
Numeric Code
Description

Emergencies

0

System is unusable.

Alerts

1

Immediate action required.

Critical

2

Critical condition.

Errors

3

Error condition.

Warnings

4

Warning condition.

Notifications

5

Normal but significant condition.

Informational

6

Informational messages.

Debugging

7

Debugging messages.


The log file displays all log levels. The Guard module log file includes zone events with severity levels: emergencies, alerts, critical, errors, warnings, and notifications. You can display the event log locally or from a remote server.

This section contains the following topics:

Configuring the Logging Parameters

Managing Online Event Logs

Managing the Log File

Configuring the Logging Parameters

To control the log file operations of the Guard module, you can configure the logging parameters.

To configure the logging parameters, use the following command in configuration mode:

logging {device-log size logging-size-init | facility {local0 | local1 | local2 | local3 | local4 | local5 | local6 | local7} | host remote-syslog-server-ip | trap {alerts | critical | debugging | emergencies | errors | informational | notifications | warnings} | zone-log size logging-size-init}

Table 13-5 provides the keywords and arguments for the logging command:

Table 13-5 Keywords and Arguments for the logging Command 

Parameter
Description

device-log size logging-size-init

Specifies the space allocated for all Guard module log files. The maximum amount of space is 50 MB, which is the default setting.

facility

Specifies the export syslog facility. The remote syslog server uses logging facilities to filter events. For example, the logging facility allows the remote user to receive the Guard module events in one file and use another file for events from other networking devices.

The available facilities are local0 through local7. The default is local4.

host remote-syslog-server-ip

Specifies the remote syslog server IP address to use when exporting log files. Enter the IP address and subnet mask in dotted-decimal notation (for example, an IP address of 192.168.100.1 and a subnet mask of 255.255.255.0). See the "Copying the Log File to a Network Server" for more information.

trap

Specifies the severity level of the syslog traps sent to the remote syslog. When you specify one of the lower severity levels, the event log includes the higher severity levels above it. For example, if the trap level is set to warning, then error, critical, alerts, and emergencies are also sent. The available trap levels from the highest to the lowest severity level are as follows:

emergencies

alerts

critical

errors

warnings

notification

informational

debugging

The default is notification. See Table 13-4 for more information.


Note To receive events about the addition and removal of dynamic filters, set the trap level to informational.


zone-log size logging-size-init

Specifies the space allocated for all log files of a zone. The maximum amount of space is 10 MB, which is the default setting.


To display the current settings of the logging parameters, use either of the following commands in the global or configuration modes:

show logging

show running-config

The following example shows how to allocate 6 MB of space for zone logs:

user@GUARD-conf# logging zone-log size 6

Managing Online Event Logs

This section describes how to manage the Guard module real-time logging of events and contains the following topics:

Displaying Online Event Logs

Exporting Online Event Logs

Displaying Online Event Logs

You can activate the Guard module monitoring feature and display a real-time event log, which enables you to view the online logging of the Guard module events. To display the online event logs, use the following command:

event monitor

The following example shows how to activate monitoring:

user@GUARD# event monitor

The screen constantly updates to show new events.


Note To deactivate monitoring, use the no event monitor command.


Exporting Online Event Logs

You can export the Guard module online event logs to display the Guard module operations that are registered in the log file and to display the Guard module events from a remote host while they are registered in the Guard module log file. The Guard module log file is exported using the syslog mechanism. You can export the Guard module log file to several syslog servers and specify additional servers so that if one goes offline, another is available to receive messages.

Online Guard module log export is applicable with a remote syslog server only. If a remote syslog server is not available, use the copy log command to export the Guard module log information to a file.

The following is an example of a logging event:

Sep 11 16:34:40 10.4.4.4 cm: scannet, 5 threshold-tuning-start: Zone activation completed 
successfully.

The system log message syntax is as follows:

event-date event-time Guard-IP-address software-daemon/module zone-name event-severity-level event-type event-description

To export online event logs, perform the following steps:


Step 1 (Optional) Configure the logging parameters by entering the following command in configuration mode:

logging {facility | trap}

See the "Configuring the Logging Parameters" section for more information.

Step 2 Configure the remote syslog server IP address by entering the following command:

logging host remote-syslog-server-ip

See the "Configuring the Logging Parameters" section for m ore information.

To build a list of syslog servers that receive logging messages, use the logging host command more than once.


The following example shows how to configure the Guard module to send traps with a severity level that is higher than notification. The Guard module sends the traps using the facility local3 to a syslog server with IP address 10.0.0.191:

user@GUARD-conf# logging facility local3
user@GUARD-conf# logging trap notifications
user@GUARD-conf# logging host 10.0.0.191

To display the configuration that the Guard module uses to export online event logs, use the show logging command.

Managing the Log File

This section describes how to manage the Guard module log file and contains the following topics:

Displaying the Log File

Copying the Log File to a Network Server

Clearing the Log File

Displaying the Log File

You can display the Guard module log for diagnostic or monitoring purposes. The Guard module log file includes zone events with these severity levels: emergencies, alerts, critical, errors, warnings, and notification.

To display the Guard module log, use the following command in global mode:

show log

The following example shows how to display the Guard module log:

user@GUARD# show log

You can display a zone log to display events that relate to the specified zone only.

To display the zone log, use the show log [sub-zone-name] command in zone configuration mode. The sub-zone-name argument specifies the name of a subzone that was created from the zone. See the "Understanding Subzones" section on page 10-8 for more information.

Copying the Log File to a Network Server

You can copy the Guard module log file to a network server for monitoring or diagnostics by entering one of the following commands in global mode:

copy [zone zone-name] log ftp server full-file-name [login [password]]

copy [zone zone-name] log {sftp | scp} server full-file-name login

Table 13-6 provides the arguments and keywords for the copy log command.

Table 13-6 Arguments and Keywords for the copy log ftp Command 

Parameter
Description

zone zone-name

(Optional) Specifies the zone name. Exports the zone log file. The default is to export the Guard module log file.

log

Exports the log file.

ftp

Exports the logs to an FTP network server.

sftp

Exports the logs to an SFTP network server.

scp

Exports the logs to an SCP network server.

server

IP address of the network server. Enter the IP address in dotted-decimal notation (for example, enter 192.168.10.2).

full-file-name

Complete name of the file. If you do not specify a path, the server saves the file in your home directory.

login

(Optional) Server login name. The login argument is optional when you define an FTP server. When you do not enter a login name, the FTP server assumes an anonymous login and does not prompt you for a password.

password

(Optional) Password for the remote FTP server. If you do not enter the password, the Guard module prompts you for it.



Note You can configure the Guard module to export event logs automatically by using the logging host command. See the "Exporting Online Event Logs" section for more information.


Because Secure File Transfer Protocol (SFTP) and Secure Copy Protocol (SCP) rely on Secure Shell (SSH) for secure communication, if you do not configure the key that the Guard module uses before you enter the copy command with the sftp or scp option, the Guard module prompts you for the password. See the "Configuring the Keys for SFTP and SCP Connections" section on page 4-24 for more information about how to configure the key that the Guard module uses for secure communication.

The following example shows how to export the Guard module log file to an FTP server:

user@GUARD# copy log ftp 10.0.0.191 log.txt <user> <password>

Clearing the Log File

You can clear the Guard module or zone log file if it is large or if you are going to perform testing and want to be sure that the log file includes information from the testing session only.

To clear the zone log file of all entries, use the following command in zone configuration mode:

clear log

To clear the Guard module or zone log file of all entries, use the following command in configuration mode:

clear [zone zone-name] log

The optional zone zone-name keyword and argument specify the zone name. The default is to clear the Guard module log file.

The following example shows how to clear the Guard module log:

user@GUARD-conf# clear log

Monitoring Network Traffic and Extracting Attack Signatures

You can configure the Guard module to record traffic directly from the network through nonintrusive taps and create a database from the recorded traffic. By querying the recorded traffic database, you can analyze past events, generate signatures of an attack, or compare current network traffic patterns with traffic patterns that the Guard module recorded previously under normal traffic conditions.

You can configure filters so that the Guard module records only traffic that meets certain criteria or you can record all traffic data and filter the traffic that the Guard module displays.

The Guard module records the traffic in Packet Capturing Application Program (PCAP) format, which is compressed and encoded by the gzip (GNU zip) program with an accompanying file in Extensible Markup Language (XML) format that describes the recorded data.

The Guard module can analyze recorded traffic to determine if there are any common patterns or signatures that appear in the payload of the recorded attack packets. The Guard module can extract signatures from the recorded traffic. Using the signature, you can configure a flex-content filter to block all traffic containing packet payloads that match the signature.

The Guard module can record traffic as follows:

Automatically—Continuously records traffic data in packet-dump capture files.

New packet-dump capture files replace the previous ones. To save previous packet-dump capture files, you must export them to a network server.

Manually—Records traffic in a packet-dump capture file when you activate a recording session.

New packet-dump capture files replace previous files. To save the recorded traffic, export the packet-dump capture files to a network server before you activate the Guard module to record traffic again.

You can activate only one manual packet-dump capture at a time for a zone, but you can activate the manual packet-dump capture and the automatic packet-dump capture simultaneously. The Guard module can manually record traffic for up to four zones simultaneously.

The Guard module allocates, by default, 20-MB disk space for manual packet-dump capture files of all zones and can save up to 80-MB disk space for manual and automatic packet-dump capture files of all zones. You must delete old files to free the disk space for additional packet-dump capture files.

This section contains the following topics:

Configuring the Guard Module to Automatically Record Traffic

Activating the Guard Module to Manually Record Traffic

Stopping the Guard Module from Manually Recording Traffic

Displaying Manual Packet-Dump Settings

Exporting Packet-Dump Capture Files Automatically

Exporting Packet-Dump Capture Files Manually

Importing Packet-Dump Capture Files

Displaying Packet-Dump Capture Files

Generating Attack Signatures from Packet-Dump Capture Files

Copying Packet-Dump Capture Files

Deleting Packet-Dump Capture Files

Configuring the Guard Module to Automatically Record Traffic

You can activate the Guard module to automatically record network traffic for troubleshooting network problems or analyzing attack traffic. By using packet-dump capture filters, you can configure the Guard module to record only the traffic that meets the criteria that you specify. You can also record all traffic and apply packet-dump capture filters to the recorded traffic when you view it.

The Guard module records traffic in a capture buffer during zone protection or learning. When the capture buffer size reaches 20 MB, or after 10 minutes have elapsed, the Guard module saves the buffered information to a local file in a compressed format, clears the buffer, and then continues recording traffic.


Note The Guard module can perform the packet-dump automatic capture function on a maximum of four zones concurrently. If you activate learning or zone protection for a fifth zone that has the automatic capture function enabled, the Guard module activates the zone but does not perform the capture function. It issues a syslog stating that no capture for the zone will be performed.


The Guard module can create up to three different types of capture files during the capture time period, depending on which of the following ways it handles the packets:

Forwarded: Source IP addresses of the legitimate traffic that the Guard module forwarded to the zone.

Dropped: Source IP addresses of the malicious traffic that the Guard module dropped.

Replied: Destination IP addresses of the traffic that the Guard module anti-spoofing and anti-zombie functions sent back to the source in a verification attempt.

When only a forwarded packet-dump capture file exists, it indicates that the zone was not under attack during the time of the capture. An attack on the zone is indicated when the Guard module also creates dropped and replied capture files. Within each of the three types of packet-dump capture files, the Guard module provides an IP summarization, which is a summary of the most frequently detected IP addresses (according to the volume of traffic).

The IP summarization information that the Guard module presents in a replied packet-dump capture file enables you to determine the source of a spoofed attack. The Guard module also pulls this information from the capture file and displays it in the zone attack report under the heading Replied IP Summarization (see the "Replied IP Summarizations" section on page 12-7).


Caution To ensure accurate replied IP summarization results, you must leave the packet dump capture function enabled during the length of the attack on the zone. If you disable the packet-dump capture function during the attack, the replied IP summarization information may not display or may not be accurate. The Guard module can display replied IP summarization information in the attack report only when you have the packet-dump automatic capture function enabled (no replied IP summarization information displays for manually activated packet-pump captures).


Note The IP summarization process is resource consuming. When resources become low, the Guard module suspends the process and issues a log message that appears in the zone log. The capture xml file will contain a status attribute that states that the capture file has no IP summarization information due to a failure.


The Guard module applies a naming convention to automatic packet-dump capture files that provides information about when the Guard module recorded the traffic and how it handled the traffic. Table 13-7 describes the sections of the automatic packet-dump capture filename.

Table 13-7 Sections of the Automatic Packet-Dump Capture Filename 

Section
Description

Function/Zone Name

Zone function that the Guard module was performing at the time of the packet-dump capture and the zone name. The zone functions are as follows:

protect—The Guard module recorded the traffic during zone protection.

learn—The Guard module recorded the traffic during the zone learning process or the protect and learning process.

Capture start time

Time that the Guard module started recording the traffic.

Capture end time

(Optional) Time that the Guard module finished recording the traffic. If the Guard module is currently recording the traffic to the file, the end time is not displayed.

Dispatch

Method that the Guard module used to handle the traffic. This method can be one of the following:

forwarded—The Guard module identified traffic as legitimate and forwarded it to the zone.

dropped—The Guard module identified traffic as malicious and dropped it.

replied—The Guard module sent replies to the initiating client as part of the anti-spoofing or anti-zombie functions in order to verify whether the packets are part of authentic traffic or part of an attack.


The Guard module saves one packet-dump capture file from the learning process and the following two types of packet-dump capture files when zone protection is enabled:

Traffic from the previous 10 minutes

Current traffic

When you activate zone protection or activate the Guard module to automatically record network traffic, the Guard module erases all previous packet-dump capture files that it recorded during the protection process and creates new ones.

To configure the Guard module to automatically record network traffic, perform the following steps:


Step 1 Configure the Guard module to automatically record zone traffic. Enter the following command in zone configuration mode:

packet-dump auto-capture

Step 2 (Optional) To create a packet-dump capture database, export the packet-dump capture files to a network server. New packet-dump capture files replace the previous ones. To create a packet-dump capture database, you must export the packet-dump capture files.

See the "Exporting Packet-Dump Capture Files Automatically" section.


The following example shows how to configure the Guard module to automatically record zone traffic:

user@GUARD-conf-zone-scannet# packet-dump auto-capture

To stop the Guard module from automatically capturing zone traffic data, use the no packet-dump auto-capture command.

To display the current packet-dump settings, use the show packet-dump command.

Activating the Guard Module to Manually Record Traffic

You can manually activate the Guard module to record zone traffic and create a capture file, enabling you to capture traffic during a specific period of time. You can also specify the types of traffic that the Guard module records as follows:

Forwarded: Legitimate traffic that the Guard module forwarded to the zone.

Dropped: Malicious traffic that the Guard module dropped.

Replied: Traffic that the Guard module anti-spoofing and anti-zombie functions sent back to the source in a verification attempt.

All: Forwarded, dropped, and replied traffic.

Within the forwarded, dropped, and replied types of packet-dump capture files, the Guard module provides an IP summarization, which is a summary of the most frequently detected source IP addresses (according to the volume of traffic). The Guard module does not provide an IP summarization for capture files that contain all traffic types.


Note The IP summarization process is resource consuming. When resources become low, the Guard module suspends the process and issues a log message that appears in the zone log. The capture xml file will contain a status attribute that states that the capture file has no IP summarization information due to a failure.


The Guard module stops recording traffic and saves the manual packet-dump capture to a file when the specified number of packets have been recorded or when either the learning process or zone protection have ended.

You can activate only one manual packet-dump capture at a time for a zone, but you can activate the manual packet-dump capture and the automatic packet-dump capture simultaneously. The Guard module can record manual packet-dump captures for up to 10 zones simultaneously.

To activate a manual packet-dump capture, use the following command in zone configuration mode:

packet-dump capture [view] capture-name pdump-rate pdump-count {all | dropped | forwarded | replied} [tcpdump-expression]


Note The CLI session halts while the traffic is captured. To continue working while the capture is in process, establish an additional session with the Guard module.


Table 13-8 provides the arguments and keywords for the packet-dump command.

Table 13-8 Arguments and Keywords for the packet-dump Command 

Parameter
Description

view

(Optional) Displays the traffic that the Guard module is recording in real time.

capture-name

Name of the packet-dump capture file. Enter an alphanumeric string from 1 to 63 characters in length. The string can contain underscores but cannot contain spaces.

pdump-rate

Sample rate in packets per second (pps). Enter a value from 1 to 10000.

Note The Guard module supports a maximum accumulated packet-dump capture rate of 10000 pps for all concurrent manual captures.

A packet-dump capture configured with a high sample-rate value consumes resources. We recommend that you use high-rate values cautiously because of the potential performance penalty.

pdump-count

Number of packets to record. When the Guard module finishes recording the specified number of packets, it saves the manual packet-dump capture buffer to a file. Enter an integer from 1 to 5000.

all

Captures all traffic.

Note If you enter the all keyword, the Guard module does not perform the IP summarization process on the capture file. The capture xml file contains a status attribute stating that IP summarization is not supported for this configuration of the packet-dump command.

dropped

Captures only traffic that the Guard module dropped.

forwarded

Captures only legitimate traffic that the Guard module forwarded to the zone.

replied

Captures only the traffic that the Guard module anti-spoofing and anti-zombie functions sent back to the source in a verification attempt.

tcpdump-expression

(Optional) Filter that you apply to specify the traffic to record. The Guard module captures only traffic that complies with the filter expression. The expression rules are identical to the flex-content filter TCPDump expression rules. See the "Configuring the tcpdump-expression Syntax" section on page 7-7 for more information.


The following example shows how to activate a manual packet-dump capture to record 1000 packets with a sample rate of 10 pps and display the packets that are captured:

user@GUARD-conf-zone-scannet# packet-dump capture view 10 1000 all

Stopping the Guard Module from Manually Recording Traffic

The Guard module stops a manual packet-dump capture when it records the number of packets that you specified when you activated the capture. However, you can stop a manual packet-dump capture before the Guard module records the specified number of packets by performing one of the following actions:

Press Ctrl-C in the open CLI session.

Open a new CLI session and enter the following command in the zone configuration mode of the desired zone:

no packet-dump capture capture-name

The capture-name argument specifies the name of the capture to stop.

The Guard module saves the packet-dump capture file.

Displaying Manual Packet-Dump Settings

You can display the current amount of disk space that the Guard module allocated for manual packet-dump capture files by using the show packet-dump command in configuration mode or in global mode. The Guard module allocates a single block of disk space for the manual packet-dump capture files of all zones.

The following example shows how to display the current amount of disk space that the Guard module allocated for manual packet-dump capture files:

user@GUARD-conf# show packet-dump

Table 13-9 describes the fields in the show packet-dump command output.

Table 13-9 Field Descriptions for the Manual show packet-dump Command Output 

Field
Description

Allocated disk-space

Amount of total disk space that the Guard module has allocated for manual packet-dump captures of all zones in megabytes.

Occupied disk-space

Percentage of allocated disk space consumed by manual packet-dump files from all zones.


Exporting Packet-Dump Capture Files Automatically

You can configure the Guard module to automatically export packet-dump capture files to a network server that uses FTP, SFTP, or SCP to transfer files. When you enable the automatic export function, the Guard module exports the packet-dump capture files each time that it saves the contents of the packet-dump buffer to a local file. The Guard module exports the packet-dump capture files in PCAP format, which is compressed and encoded by the gzip (GNU zip) program, with an accompanying file in XML format that describes the recorded data. The XML schema is described in the Capture.xsd file which you can download from the Software Center at http://www.cisco.com/public/sw-center/.

To configure the Guard module to export packet-dump capture files automatically, use the following command in configuration mode:

export packet-dump file-server-name

The file-server-name argument specifies the name of a network server to which you export the files that you configure using the file-server command. If you configure the network server for SFTP or SCP, you must configure the SSH key that the Guard module uses for SFTP and SCP communication. See the "Exporting Files Automatically" section on page 14-6 for more information.

The following example shows how to automatically export packet-dump capture files:

user@GUARD-conf# export packet-dump Corp-FTP-Server

Exporting Packet-Dump Capture Files Manually

You can manually export packet-dump capture files to a network server that uses FTP, SFTP, or SCP to transfer files. You can export a single packet-dump capture file or all packet-dump capture files of a specific zone. The Guard module exports the packet-dump capture files in PCAP format, which is compressed and encoded by the gzip (GNU zip) program with an accompanying file in XML format that describes the recorded data. See the Capture.xsd file that accompanies the version for a description of the XML schema. You can download the xsd files that accompany the version from www.cisco.com.

To manually export packet-dump capture files to a network server, use one of the following commands in global mode:

copy zone zone-name packet-dump captures [capture-name] ftp server remote-path [login [password]]

copy zone zone-name packet-dump captures [capture-name] {sftp | scp} server remote-path login

copy zone zone-name packet-dump captures [capture-name] file-server-name

Table 13-10 provides the arguments and keywords for the copy zone packet-dump command.

Table 13-10 Arguments and Keywords for the copy zone packet-dump Command 

Parameters
Description

zone zone-name

Specifies the name of an existing zone.

packet-dump captures

Exports packet-dump capture files.

capture-name

(Optional) Name of an existing packet-dump capture file. If you do not specify the name of a packet-dump capture file, the Guard module exports all the zone packet-dump capture files. See the "Displaying Packet-Dump Capture Files" section for more information.

ftp

Specifies FTP.

sftp

Specifies SFTP.

scp

Specifies SCP.

server

IP address of the network server. Enter the IP address in dotted-decimal notation (for example, enter 192.168.10.2).

remote-path

Complete name of the path where the Guard module saves the packet-dump capture files.

login

(Optional) Server login name. The login argument is optional when you define an FTP server. When you do not enter a login name, the FTP server assumes an anonymous login and does not prompt you for a password.

password

(Optional) Password for the remote FTP server. If you do not enter the password, the Guard module prompts you for one.

file-server-name

Name of a network server. You must configure the network server using the file-server command.

If you configured the network server using SFTP or SCP, you must configure the SSH key that the Guard module uses for SFTP and SCP communication.

See the "Exporting Files Automatically" section on page 14-6 for more information.


Because SFTP and SCP rely on SSH for secure communication, if you do not configure the key that the Guard module uses before you enter the copy command with the sftp or scp option, the Guard module prompts you for the password. See the "Configuring the Keys for SFTP and SCP Connections" section on page 4-24 for more information about how to configure the key that the Guard module uses for secure communication.

The following example shows how to manually export the packet-dump capture files of zone scannet to FTP server 10.0.0.191:

user@GUARD# copy zone scannet packet-dump captures ftp 10.0.0.191 <user> <password>

The following example shows how to manually export the packet-dump capture files of zone scannet to a network server that was defined by using the file-server command:

user@GUARD# copy zone scannet packet-dump captures cap-5-10-05 Corp-FTP-Server

Importing Packet-Dump Capture Files

You can import packet-dump capture files from a network server to the Guard module so that you can analyze past events or compare current network traffic patterns with traffic patterns that the Guard module previously recorded under normal traffic conditions. The Guard module imports the packet-dump capture files in both XML and PCAP formats.

To import a packet-dump capture file, use one of the following commands in global mode:

copy ftp zone zone-name packet-dump captures server full-file-name [login [password]]

copy {sftp | scp} zone zone-name packet-dump captures server full-file-name login

copy file-server-name zone zone-name packet-dump captures capture-name

Table 13-11 provides the arguments and keywords for the copy zone packet-dump command.

Table 13-11 Arguments and Keywords for the copy zone packet-dump Command 

Parameter
Description

ftp

Specifies FTP.

sftp

Specifies SFTP.

scp

Specifies SCP.

zone zone-name

Specifies the name of an existing zone for which the packet-dump capture files are imported.

server

IP address of the network server. Enter the IP address in dotted-decimal notation (for example, enter 192.168.10.2).

full-file-name

Complete path and filename, excluding the file extension, of the file to import. If you do not specify a path, the server copies the file from your home directory.

Note Do not specify the file extension because it will cause the import process to fail.

login

(Optional) Server login name. The login argument is optional when you define an FTP server. When you do not enter a login name, the FTP server assumes an anonymous login and does not prompt you for a password.

password

(Optional) Password for the FTP server. If you do not enter the password, the Guard module prompts you for one.

file-server-name

Name of a network server. You must configure the network server using the file-server command.

If you configured the network server using SFTP or SCP, you must configure the SSH key that the Guard module uses for SFTP and SCP communication.

See the "Exporting Files Automatically" section on page 14-6 for more information.

capture-name

Name of the file to import. The Guard module appends the name of the file to the path that you defined for the network server by using the file-server command.


Because SFTP and SCP rely on SSH for secure communication, if you do not configure the key that the Guard module uses before you enter the copy command with the sftp or scp option, the Guard module prompts you for the password. See the "Configuring the Keys for SFTP and SCP Connections" section on page 4-24 for more information about how to configure the key that the Guard module uses for secure communication.

The following example shows how to import packet-dump capture files of zone scannet from FTP server 10.0.0.191:

user@GUARD# copy ftp zone scannet packet-dump captures 10.0.0.191 
/root/scannet/captures/capture-1 <user> <password>

The following example shows how to import a packet-dump capture file from a network server:

user@GUARD# copy CorpFTP running-config capture-1

Displaying Packet-Dump Capture Files

You can display either a list of packet-dump capture files or the content of a single packet-dump capture file. By default, the Guard module displays a list of all zone packet-dump capture files.

To display packet-dump capture files, use the following command in zone configuration mode:

show packet-dump captures [capture-name [ip summarization | tcpdump-expression]]

Table 13-12 provides the keywords and arguments for the show packet-dump captures command.

Table 13-12 Keywords and Arguments for the show packet-dump captures Command 

Parameters
Description

capture-name

(Optional) Name of an existing packet-dump capture file. If you do not specify the name of a packet-dump capture file, the Guard module displays a list of all zone packet-dump capture files. See Table 13-13 for field descriptions of the command output.

If you specify the name of a packet-dump capture file, the Guard module displays the file in TCPDump format.

ip summarization

Displays the IP summary information for the recorded packets. See the "Configuring the Guard Module to Automatically Record Traffic" section for more information.

tcpdump-expression

(Optional) Filter that the Guard module uses when displaying the packet-dump capture file. The Guard module displays only the portion of the packet-dump capture file that matches the filter criteria. The expression rules are identical to the flex-content filter TCPDump expression rules. See the "Configuring the tcpdump-expression Syntax" section on page 7-7 for more information.


The following example shows how to display the list of packet-dump capture files:

user@GUARD-conf-zone-scannet# show packet-dump captures

Table 13-13 describes the fields in the show packet-dump captures command output.

Table 13-13 Field Descriptions for the show packet-dump captures Command Output 

Field
Description

Capture-name

Name of the packet-dump capture file. See Table 13-7 for a description of the automatic packet-dump capture filenames.

Size (MB)

Size of the packet-dump capture file in megabytes.

Filter

User-defined filter that the Guard module used when recording traffic. The filter is in TCPDump format. The expression rules are identical to the flex-content filter TCPDump expression rules. See the "Configuring the tcpdump-expression Syntax" section on page 7-7 for more information.


The following example shows how to display the IP summarization information of the protect/PacketDump121_Oct-25-17:18:56_Oct-25-17:28:56_forwarded packet dump:

user@GUARD-conf-zone-scannet# show packet-dump captures 
protect/PacketDump121_Oct-25-17:18:56_Oct-25-17:28:56_forwarded ip summarization

Table 13-14 describes the fields in the show packet-dump captures ip summarization command output.

Table 13-14 Field Descriptions for the show packet-dump captures ip summarization Command Output 

Field
Description

Subnet

Most frequently detected IP addresses of the recorded packet type. For forwarded and dropped packet types, the IP addresses listed are the packet source IP addresses. For replied packet types, the IP addresses are the packet destination IP addresses.

Subnet Mask

Subnet mask of the recorded packet type (forwarded, dropped, or replied).

Weight(%)

Percentage of samples recorded by the Guard module that came from the subnet IP address out of the total number of recorded samples.

Unique Addresses

Number of unique addresses belonging to the subnet.


Generating Attack Signatures from Packet-Dump Capture Files

An attack signature describes the common pattern that appears in the payload of attack packets. You can activate the Guard module to generate the signature of attack traffic and then use this information to quickly identify future attacks of the same type. This feature allows you to detect new DDoS attacks and Internet worms even before signatures are published (for example, from antivirus software companies or mailing lists).

The Guard module can generate an attack signature using the flex-content filter pattern expression syntax. You can use the attack signature in the flex-content filter pattern to filter out attack traffic. See the "Configuring Flex-Content Filters" section on page 7-4 for more information.

When you execute the attack signature generating process, you can determine the accuracy of the generated attack signature by specifying a reference packet-dump capture file containing clean (legitimate) traffic. After the Guard module generates the attack signature from the packet-dump capture file containing malicious traffic, the Guard module runs an analysis to determine how often the attack signature appears in the clean traffic of the reference packet-dump capture file. The Guard module displays the results of the analysis as a percentage of the attack signature occurrences in the reference packet-dump capture file to the number of packets in the reference file. A percentage value that is less than 10 percent indicates that the attack signature is accurate and that you can use the signature to detect malicious traffic.

A percentage value that is greater than 10 percent indicates that the signature generating process failed. Do not use the signature to detect malicious traffic because it will result in the Guard module wrongly identifying clean traffic as malicious traffic. The signature generating process may fail for the following reasons:

The packet-dump capture file that contains malicious traffic also contains valid traffic. Use a packet-dump capture file that contains malicious traffic only during the signature generating process.

The Guard module's signature generating algorithm is unable to detect a unique signature in the sample of malicious traffic.

To generate a signature of an attack, perform the following steps:


Step 1 Activate the Guard module to record traffic during the attack by using the packet-dump capture command.

See the "Activating the Guard Module to Manually Record Traffic" section for more information.

Step 2 Identify the packet-dump capture file that the Guard module recorded during the attack. To display the list of packet-dump capture files, use the show packet-dump captures command.

See the "Displaying Packet-Dump Capture Files" section for more information.

Step 3 Activate the Guard module to generate a signature of the attack traffic. Enter the following command in zone configuration mode:

show packet-dump signatures capture-name [reference-capture-name]

Table 13-15 provides the arguments for the show packet-dump signatures command.

Table 13-15 Arguments for the show packet-dump signatures Command  

Parameter
Description

capture-name

Name of an existing packet-dump capture file from which to generate a signature.

reference-capture-name

(Optional) Name of an existing packet-dump capture file that the Guard module recorded during normal traffic conditions. The Guard module runs an analysis to determine how often the attack signature appears in the reference file.



Table 13-16 describes the fields in the show packet-dump signatures command output.

Table 13-16 Field Descriptions for the show packet-dump signatures Command Output 

Field
Description

Start Offset

Offset (in bytes) from the beginning of the packet payload where the pattern begins. If you copy the pattern into the flex-content filter pattern expression, copy this offset into the flex-content filter start-offset argument.

End Offset

Offset (in bytes) from the beginning of the packet payload where the pattern ends. If you copy the pattern into the flex-content filter pattern expression, copy this offset into the flex-content filter end-offset argument.

Pattern

Signature that the Guard module generated. The Guard module generates the signature using the flex-content filter pattern expression syntax. See the "Configuring the Pattern-expression Syntax" section on page 7-9 for more information.You can copy this pattern into the flex-content filter pattern expression.

Percentage

Percentage of the attack signature occurrences in the reference packet-dump capture file to the number of packets in the reference file.


The following example shows how to generate a signature from a manual packet-dump capture file:

user@GUARD-conf-zone-scannet# show packet-dump signatures PDumpCapture

Copying Packet-Dump Capture Files

You can copy a packet-dump capture file (or a portion of a file) under a new name. When you copy an automatic packet-dump capture file or a manual packet-dump capture file, the Guard module saves them as manual files. If you want to save an existing automatic packet-dump capture file, you need to create a copy of it before the Guard module overwrites the automatic packet-dump capture file with a new one.

You must manually delete the packet-dump capture files if you need to free disk space. See the "Deleting Packet-Dump Capture Files" section for more information.

To copy a packet-dump capture file, use the following command in configuration mode:

copy zone zone-name packet-dump captures capture-name [tcpdump-expression] new-name

Table 13-17 provides the arguments and keywords for the copy zone packet-dump captures command.

Table 13-17 Arguments and Keywords for the copy zone packet-dump captures Command 

Parameters
Description

zone-name

Name of an existing zone.

capture-name

Name of an existing packet-dump capture file.

tcpdump-expression

(Optional) Filter that the Guard module uses to copy the packet-dump capture file. The Guard module copies only the portion of the packet-dump capture file that matches the filter criteria. The expression rules are identical to the flex-content filter TCPDump expression rules. See the "Configuring the tcpdump-expression Syntax" section on page 7-7 for more information.

new-name

Name of the new packet-dump capture file.

The name is an alphanumeric string from 1 to 63 characters and can contain underscores but cannot contain spaces.


The following example shows how to copy a portion of the packet-dump capture file capture-1 that complies with the capture file under the name capture-2:

user@GUARD-conf# copy zone scannet capture-1 "tcp and dst port 80 and not src port 1000" 
capture-2

Deleting Packet-Dump Capture Files

The Guard module allocates by default 20 MB of disk space for manual packet-dump capture files of all zones. It can save up to 80 MB of manual and automatic packet-dump capture files of all zones. To free disk space for additional packet-dump capture files, delete the old ones.

You can save only one manual packet-dump capture file per zone and no more than 10 packet-dump capture files on the Guard module. You must delete old manual packet-dump capture files to allow space for new files.

To delete automatic or manual packet-dump capture files, use one of the following commands:

clear zone zone-name packet-dump captures {* | name} (in configuration mode)

clear packet-dump captures {* | name} (in zone configuration mode)

Table 13-18 provides the arguments and keywords for the clear packet-dump command.

Table 13-18 Arguments and Keywords for the clear packet-dump Command 

Parameter
Description

zone zone-name

Specifies the name of an existing zone.

*

Erases all packet-dump capture files.

name

Name of the packet-dump capture file to delete.


The following example shows how to delete all manual packet-dump capture files:

user@GUARD-conf# clear packet-dump captures *

Displaying General Diagnostic Data

You can display a general summary of the diagnostic data by using the following command:

show diagnostic-info [details]

The diagnostic data consists of the following information:

Line Card Number—Identifier string for the Guard module.

Number of Pentium-class Processors—Number of the Guard module processor. The Guard module supports processor 1.

BIOS Vendor—Vendor of the BIOS on the Guard module.

BIOS Version—BIOS version on the Guard module.

Total available memory—Total memory available on the Guard module.

Size of compact flash—Size of the compact flash on the Guard module.

Slot Num—Number of the slot in which the module is inserted into the chassis (1-13 depending on the model number of your switch or router).

CFE version—CFE version number.


Note To change the CFE version, you must install a new flash version. To burn a new CFE version, use the flash-burn command. See the "Burning a New Flash Version to Upgrade the CFE" section on page 14-15 for more information.


Recognition Average Sample Loss—Calculated average packet sample loss.

Forward failures (no resources)—Number of packets that were not forwarded due to lack of system resources.


Note A high Recognition Average Sample Loss or a large number of Forward failures indicate that the Guard module is overloaded with traffic. We recommend that you install more than one Guard module in a load-sharing configuration.


Displaying Flash Memory Usage

The Guard module maintains activity logs and zone attack reports. If the disk usage is higher than 75 percent, or if a large number of zones is defined on the Guard module (over 500), we recommend that you decrease the file history parameters. When the used disk space reaches approximately 80 percent of the maximum disk capacity, the Guard module displays a warning message in its syslog.

If the Guard module displays a warning message, you can export the zone attack reports to a network server and then delete the old attack reports (see the "Exporting Attack Reports" section on page 12-14 and the "Deleting Attack Reports" section on page 12-17).

We recommend that you periodically store the Guard module records on a network server and then clear the logs.


Note When disk usage reaches 80 percent of the disk maximum capacity, the Guard module erases information to reduce used disk space to approximately 75 percent.


To display the available flash over the amount of flash installed on the Guard module, use the following command in global mode:

show flash-usage

The following example shows how to display flash memory usage:

user@GUARD# show flash-usage
2%

Displaying Memory Consumption

The Guard module displays the following information:

Memory usage in kilobytes.

Percentage of memory that the Guard module statistical engine uses as the Anomaly Detection Engine Used Memory field.

The anomaly detection engine memory usage is affected by the number of active zones and the number of services that each zone monitors.


Note If the anomaly detection engine memory usage is higher than 90 percent, we strongly recommend that you lower the number of active zones.


To display the Guard module memory consumption, use the following command:

show memory

The following example shows how to display the Guard module memory consumption:

user@GUARD# show memory
              total    used    free    shared   buffers   cached
	In KBytes:  2065188  146260  1918928    0     2360      69232

	Anomaly detection engine used memory: 0.3%


Note The total amount of free memory that the Guard module has is a sum of the free memory and the cached memory.


Displaying the CPU Utilization

The Guard module displays the percentage of CPU time in user mode, system mode, niced tasks (tasks with a nice value, which represents the priority of a process, that is negative), and idle. Niced tasks are counted in both system time and user time, so the total CPU utilization can be more than 100 percent.

To display the current percentage of CPU utilization, use the following command:

show cpu

The following example shows how to display the current percentage of CPU utilization:

user@GUARD# show cpu
Host CPU1: 0.0% user, 0.1% system, 0.1% nice, 98.0% idle

Monitoring System Resources

You can display an overview of the resources that the Guard module is using to help you analyze and monitor the system status by entering the following command in global or configuration mode:

show resources

The following example shows how to display the system resources:

user@GUARD# show resources

Table 13-19 describes the fields in the show resources command output.

Table 13-19 Field Descriptions for the show resources Command Output 

Field
Description

Host CPU1

Percentage of CPU time for CPU1 in user mode, system mode, niced tasks (tasks with a nice value, which represents the priority of a process, that is negative), and idle. Niced tasks are also counted in system time and user time so that the total CPU utilization can be more than 100 percent.

Flash space usage

Percentage of the allocated flash space that the Guard module is using.

When the flash space usage reaches approximately 75 percent of the flash maximum capacity, the Guard module displays a warning message in its syslog and sends a trap.

Note When flash usage reaches 80 percent of the flash maximum capacity, the Guard module automatically erases information to reduce used flash space to approximately 75 percent.

We recommend that you periodically store the Guard module records on a network server and delete the old records.

Flash space usage (continued)

If the flash space usage reaches 80 percent, you can export the zone attack reports to a network server and then delete the old attack reports (see the "Exporting Attack Reports" section on page 12-14 and the "Deleting Attack Reports" section on page 12-17).

Accelerator card memory usage

Percentage of memory that the accelerator card is using on a per-port basis: 1 port for 1-Gbps operation; 3 ports for 3-Gbps operation.

If the accelerator card memory usage is higher than 85 percent, the Guard module generates an SNMP trap. A high value may indicate that the Guard module is monitoring a high volume of traffic.

Accelerator card CPU utilization

Percentage of the accelerator card CPU that is being utilized on a per-port basis: 1 port for 1-Gbps operation; 3 ports for 3-Gbps operation.

If the accelerator card CPU utilization is higher than 85 percent, the Guard module generates an SNMP trap. A high value may indicate that the Guard module is monitoring a high volume of traffic.

Anomaly detection engine used memory

Specifies the percentage of memory that the Guard module statistical engine uses. The anomaly detection engine memory usage is affected by the number of active zones, the number of services each of the zones monitors, and the amount of nonspoofed traffic that the Guard module is monitoring.

If the anomaly detection engine memory usage is higher than 90 percent, we strongly recommend that you lower the number of active zones.

Dynamic filters used

Total number of dynamic filters that are active in all the zones. The Guard module displays the number of active dynamic filters and the percentage of dynamic filters that are active out of the total number of dynamic filters that the Guard module supports, which is 150,000. If the number of active dynamic filters reaches 150,000, the Guard module generates an SNMP trap with a severity level of EMERGENCY. If the number of active dynamic filters reaches 135,000, the Guard module generates an SNMP trap with a severity level of WARNING.

A high value may indicate that the Guard module is monitoring a high traffic volume of a DDoS attack.

Top proxy usage

Percentage of the proxy ports being used on a per Guard module port basis: 1 port for 1-Gbps operation; 3 ports for 3-Gbps operation. To display proxy usage by a specific zone, see the "Displaying Zone Proxy Usage" section.


For more information about the SNMP traps that the Guard module generates, see Table 4-14 on page 4-26.

Managing the ARP Cache

You can display or manipulate the Address Resolution Protocol (ARP) cache to clear an address mapping entry or to manually define an address mapping entry. To manage the ARP cache, use the following command from the configuration mode:

arp {-a [arp_hostname] | -d arp_hostname | -n [arp_hostname] | -s arp_hostname hw_addr}

Table 13-20 provides the arguments and keywords for the arp command.

Table 13-20 Arguments and Keywords for the arp Command 

Keyword
Description
-a arp_hostname

Displays the entries of the hosts in alternate (BSD) style. Enter the optional hostname to display the entry for the specified host only. You can also execute this arp command option from the global configuration mode.

-d hostname

Removes any entry for the specified host.

-n arp_hostname

Displays numerical addresses of the hosts. Enter the optional hostname to display the numerical address for the specified host only. You can also execute this arp command option from the global configuration mode.

-s arp_hostname hw_addr

Creates an ARP address mapping entry for the hostname with the hardware address set to the hw_addr class value.



Caution To configure the Guard module ARP cache, you must be familiar with the Guard module system and the network.

Displaying Network Statistics

You can display the host network connections, routing tables, interface statistics, and multicast memberships to debug network problems by entering one of the following commands:

netstat [address_family_options] [--tcp | -t] [--udp | -u] [--raw | -w] [--listening | -l] [--all | -a] [--numeric | -n] [--numeric-hosts] [--numeric-ports] [--numeric-users] [--symbolic | -N] [--extend | -e [--extend | -e]] [--timers | -o] [--program | -p] [--verbose | -v] [--continuous | -c] [delay]

netstat {--route | -r} [address_family_options] [--extend | -e [--extend | -e]] [--verbose | -v] [--numeric | -n] [--numeric-hosts] [--numeric-ports] [--numeric-users] [--continuous | -c] [delay]

netstat {--interfaces | -i} [iface] [--all | -a] [--extend | -e [--extend | -e]] [--verbose | -v] [--program | -p] [--numeric | -n] [--numeric-hosts] [--numeric-ports] [--numeric-users] [--continuous | -c] [delay]

netstat {--groups | -g} [--numeric | -n] [--numeric-hosts] [--numeric-ports] [--numeric-users] [--continuous | -c] [delay]

netstat {--masquerade | -M} [--extend | -e] [--numeric | -n] [--numeric-hosts] [--numeric-ports] [--numeric-users] [--continuous | -c] [delay]

netstat {--statistics | -s} [--tcp | -t] [--udp | -u] [--raw | -w] [delay]

netstat {--version | -V}

netstat {--help | -h}


Note If you do not specify any address families, the Guard module displays the active sockets of all configured address families.


Table 13-21 provides arguments and keywords for the netstat command.


Note You can enter the complete keyword or an abbreviation of the keyword. The abbreviated keyword is preceded by a dash (-) and the complete keyword is preceded by two dashes (--).


Table 13-21 Arguments and Keywords for the netstat Command 

Abbreviated Parameter Name
Parameter Full Name
Description

address_family_
options

 

(Optional) The address family options can be one of the following:

[--protocol={inet,unix,ipx,ax25,netrom,ddp}[,...]]

[--unix|-x] [--inet|--ip] [--ax25] [--ipx] [--netrom]

[--ddp]

-r

--route

Displays the Guard module routing tables.

-g

--groups

Displays multicast group membership information for IPv4 and IPv6.

-i iface

--interface iface

Displays a table of all network interfaces or of the optional iface value.

-M

--masquerade

Displays a list of masqueraded connections for which Network Address Translation (NAT) was used.

-s

--statistics

Displays summary statistics for each protocol.

-v

--verbose

(Optional) Displays the output in verbose.

-n

--numeric

(Optional) Displays numerical addresses.

 

--numeric-hosts

(Optional) Displays numerical host addresses but does not affect the resolution of port or usernames.

 

--numeric-ports

(Optional) Displays numerical port numbers but does not affect the resolution of host or usernames.

 

--numeric-users

(Optional) Displays numerical user IDs but does not affect the resolution of host or port names.

-c

--continuous

(Optional) Displays the selected information every second on a continuous basis.

-e

--extend

(Optional) Displays additional information. Use this option twice for maximum detail.

-o

--timers

(Optional) Displays information related to networking timers.

-p

--program

(Optional) Displays the PID and name of the program to which each socket belongs.

-l

--listening

(Optional) Displays only listening sockets. These sockets are omitted by default.

-a

--all

(Optional) Displays both listening and nonlistening sockets.

delay

 

(Optional) Netstat cycles printing through statistics every delay seconds.



Note You can enter a maximum of 13 arguments and keywords in one command.


The following example shows how to display netstat information in verbose:

user@GUARD# netstat -v
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address   Foreign Address         State
tcp        0      0 localhost:1111  localhost:32777    ESTABLISHED
tcp        0      0 localhost:8200  localhost:32772    ESTABLISHED
.
.
.
tcp        0      0 localhost:33464 localhost:8200     TIME_WAIT
tcp        1      0 localhost:1113  localhost:33194    CLOSE_WAIT
.
.
.
Active UNIX domain sockets (w/o servers)
unix  2      [ ]         STREAM     CONNECTED     928
unix  3      [ ]         STREAM     CONNECTED     890  /tmp/.zserv
.
.
.
user@GUARD#

Using Traceroute

You can determine the route that packets take to arrive at a network host to debug network problems by entering the following command:

traceroute ip-address [-F] [-f first_ttl] [-g gateway] [-i iface]
[-
m max_ttl] [-p port] [-q nqueries] [-s src_addr] [-t tos] [-w waittime] [packetlen]


Note The traceroute command displays IP addresses only, not names.


Table 13-22 provides the arguments and keywords for the traceroute command.

Table 13-22 Arguments and Keywords for the traceroute Command 

Parameter
Description

ip-address

IP address to which the route will be traced.

-F

(Optional) Sets the don't fragment bit.

-f first_ttl

(Optional) Sets the initial time-to-live (TTL) used in the first outgoing probe packet.

-g gateway

(Optional) Specifies a loose source route gateway. You can specify more than one gateway by using -g for each gateway. The maximum number of gateways is 8.

-i iface

(Optional) Specifies a network interface to obtain the source IP address for outgoing probe packets and, in most cases, is useful on a multihomed host.

-m max_ttl

(Optional) Sets the maximum time-to-live (maximum number of hops) used in outgoing probe packets. The default is 30 hops.

-p port

(Optional) Sets the base UDP port number used in probes. The default is 33434.

-q nqueries

(Optional) Sets the number of probes that are defined for the ttl value. The default is 3.

-s src_addr

(Optional) Sets the src_addr IP address as the source IP address in outgoing probe packets.

-t tos

(Optional) Sets the type-of-service in probe packets to the tos value. The default is zero.

-w waittime

(Optional) Sets the time in seconds to wait for a response for a probe. The default is 5 seconds.

packetlen

(Optional) Sets the packet length of the probe.


The following example shows how to trace the route to IP address 10.10.10.34:

user@GUARD# traceroute 10.10.10.34
traceroute to 10.10.10.34 (10.10.10.34), 30 hops max, 38 byte packets
 1 10.10.10.34 (10.10.10.34) 0.577 ms  0.203 ms  0.149 ms

Verifying Connectivity

You can send ICMP ECHO_REQUEST packets to network hosts and verify connectivity by entering the following command:

ping ip-address [-c count] [-i interval] [-l preload] [-s packetsize] [-t ttl] [-w deadline] [-F flowlabel] [-I interface]
[-
Q tos] [-T timestamp option] [-W timeout]

Table 13-23 provides arguments and keywords for the ping command.

Table 13-23 Arguments and Keywords for the ping Command 

Parameter
Description

ip-address

Destination IP address.

-c count

(Optional) Sends count number of ECHO_REQUEST packets. With a deadline option, the command waits for count ECHO_REPLY packets until the timeout expires.

-i interval

(Optional) Waits to send packets. The interval time is in seconds. The default is to wait for 1 second.

-l preload

(Optional) Sends preload packets without waiting for a reply.

-s packetsize

(Optional) Specifies the number of data bytes to send. The default is 56.

-t ttl

(Optional) Sets the IP TTL.

-w deadline

(Optional) Specifies the timeout in seconds before ping exits, regardless of how many packets have been sent or received.

-F flow label

(Optional) Allocates and sets a 20-bit flow label on echo request packets. If the value is zero, a random flow label is used.

-I interface

(Optional) Sets the source IP address to the specified interface address.

-Q tos

(Optional) Sets Type of Service (ToS)-related bits in Internet Control Message Protocol (ICMP) datagrams.

-T timestamp option

(Optional) Sets special IP time-stamp options.

-W timeout

(Optional) Time (in seconds) to wait for a response.


You can enter a maximum of 10 arguments and keywords in one command.

The following example shows how to send one ICMP ECHO_REQUEST packet to IP address 10.10.10.30:

user@GUARD# ping 10.10.10.30 -n 1

Obtaining Debug Information

If the Guard module experiences an operational problem, Cisco TAC may request that you send them a copy of the Guard module internal debug information. The Guard module debug core file contains information for troubleshooting Guard module malfunctions. The file output is encrypted and intended for use by Cisco TAC personnel only.

To extract debug information to a remote server, perform the following steps:


Step 1 Display the Guard module log file.

See the "Displaying the Log File" section for more information.

Step 2 Identify the first log message that indicates a problem to determine the time from when to extract debug information. The Guard module extracts the debug information from the time specified up to the current time.

Step 3 Extract the debug information to an FTP server by entering the following command in global mode:

copy debug-core time {ftp | scp | sftp} server full-file-name [login [password]]

Table 13-24 provides the arguments and keywords for the copy debug-core command.

Table 13-24 Arguments and Keywords for the copy debug-core Command 

Parameter
Description

time

Time of the event that triggers the need for debug information. The time string uses the format MMDDhhmm[[CC]YY][.ss] as follows:

MM—Month in numeric figures

DD—Day of the month

hh—Hour in a 24-hour clock

mm—Minutes

CC—(Optional) First two digits of the year (for example, 2005)

YY—(Optional) Last two digits of the year (for example, 2005)

.ss—(Optional) Seconds (the decimal point must be present)

ftp

Specifies FTP.

scp

Specifies SCP.

sftp

Specifies SFTP.

server

IP address of the remote server.

full-file-name

Full name of the version file. If you do not specify a path, the server saves the file in your home directory.

login

(Optional) FTP server login name. The FTP server assumes an anonymous login when you do not enter a login name. The server does not prompt you for a password.

password

(Optional) FTP server password. If you do not enter the password, the Guard module prompts you for one.



The following example shows how to extract debug information from November 9 at 06:45 a.m. of the current year to FTP server 10.0.0.191:

user@GUARD# copy debug-core 11090645 ftp 10.0.0.191 /home/debug/debug-file <user> 
<password>

Displaying the Guard Module Self-Protection Configuration

The Guard module, as a network element that has an independent IP address, is exposed to potential DDoS attacks. The default configuration of the Guard module provides protection against such attacks. You can access and modify the self-defense protection configuration.


Caution We strongly advise that you do not change the Guard module self-defense protection default configurations. Unnecessary configuration changes may seriously compromise the ability of the Guard module to protect itself.

To enter self-protection configuration mode to modify the Guard module self-defense protection configuration, use the following command in configuration mode:

self-protection

The set of commands available for the Guard module self-defense protection are identical to the commands for an ordinary zone. See the following chapters for more information:

Chapter 6, "Configuring Zones"

Chapter 7, "Configuring Zone Filters"

Chapter 8, "Configuring Policy Templates and Policies"

Chapter 11, "Using Interactive Protect Mode"

To display the Guard module self-protection configuration file, use the show running-config command. See the "Displaying the Guard Module Configuration" section for more information.

Understanding the Flex-Content Filter Default Configurations

The Guard module flex-content filter is configured, by default, to block (drop) all traffic flows unless explicitly specified.

Table 13-25 displays the flex-content filter default configuration to enable the communication that is required for proper Guard module functionality.

Table 13-25 Flex-Content Filter Default Configuration 

Service
IP-Proto
Src-port
Dst-port
Allow-SYN

ftp-control

6

21

*

no

ftp-data

6

20

*

yes

tacacs

6

49

*

yes

ssh

6

22

*

no

ssh

6

*

22

yes

https

6

*

443

yes

icmp

1

*

*

snmp

17

*

161

ssl

6

*

3220

no

ssl

6

3220

*

yes

mdm

6

*

1334

yes


The flex-content filter default configuration enables the following features:

FTP communication, initiated by the Guard module, with an FTP server, but blocks incoming FTP control SYN packets with source port 21.

TACACS communication with a TACACS+ server for authentication, authorization, and accounting, but blocks incoming SYN packets from source port 49.

Incoming and outgoing SSH communication.

Incoming HTTPS communication.

ICMP communication.

SNMP communication.

SSL communication.

Cisco MultiDevice Manager (MDM) communication.