Table Of Contents
IDS Device Manager Configuration Tasks
Configuring Interfaces
Enabling and Disabling Sensing Interfaces
Adding Interfaces to an Interface Group
Configuring Signatures
Explaining Signatures
Configuring Alarm Channel System Variables
Configuring Alarm Channel Event Filters
Configuring Virtual Sensor System Variables
Configuring Signatures Through Virtual Sensor Signature Configuration Mode
Working with Virtual Sensor Signature Configuration Mode
Tuning Built-in Signatures
Creating Custom Signatures
Introducing the Signature Wizard
Creating Custom Signatures Through the Signature Wizard
Sample HTTP Request
Regular Expression Syntax
Configuring IP Fragment Reassembly
Configuring TCP Stream Reassembly
Configuring IP Logging
Identifying Traffic Oversubscription
Configuring Blocking
Configuring Blocking Properties
Configuring Addresses Never to Block
Setting Up Logical Devices
Configuring Blocking Devices
Configuring Router Blocking Device Interfaces
Configuring Catalyst 6K Blocking Device Interfaces
Configuring a Master Blocking Sensor
Configuring Automatic Updates
Configuring Automatic Updates
Supported FTP Servers
Obtaining Cisco IDS Software
Applying for a Cisco.com Account with Cryptographic Access
Active Update Notification
Network Security Database
Restoring Default Settings
IDS Device Manager Configuration Tasks
After configuring system information, you are ready to assign interfaces, configure signatures, set up blocking, set up automatic signature updates, and restore defaults.
The following sections describe how to configure these options through the Configuration tab:
•
Configuring Interfaces
•Configuring Signatures
•Configuring Blocking
•Configuring Automatic Updates
•Restoring Default Settings
Configuring Interfaces
A sniffing interface (monitoring) must be both part of Group 0 and be enabled for the sensor to monitor that interface.
Caution Sensors with factory-installed Cisco IDS version 4.1 are shipped with all sniffing interfaces added to Interface Group 0 and disabled. You must enable the sniffing interfaces that you want the sensor to monitor. If you do not enable the sniffing interfaces, the sensor cannot monitor your networks.
•Enabling and Disabling Sensing Interfaces
•Adding Interfaces to an Interface Group
Enabling and Disabling Sensing Interfaces
There is only one command and control interface per sensor. You can set up to 5 sniffing (monitoring) interfaces depending on the type of sensor you have. The Sensing Interface page lists the known sensing interfaces and allows you to enable or disable them.
For the sensor to monitor the network traffic, make sure the sniffing interfaces are part of Group 0 (see Enabling and Disabling Sensing Interfaces) and are enabled.
Note You do not need to enable all interfaces. Only enable those interfaces that you want to monitor.
Caution Upgrades from version 4.0 to 4.1 may leave some interfaces enabled that are not assigned to a group. Either disable these interfaces or add them to Group 0 to prevent inconsistencies in reporting to the sensor.
To enable sensing interfaces, follow these steps:
Step 1 Select Configuration > Sensing Engine > Interfaces.
The Sensing Interface page appears.
The following information is displayed: the interface name, the device name, whether the interface is enabled or disabled, whether the interface is command and control or sniffing, and which type of interface it is (SX, TX).
Step 2 Select the check box next to the interface that you want to enable or disable.
Note To reset the form, click Reset.
Step 3 Click Enable or Disable.
You can only enable an interface if the interface belongs to an interface group. You receive the following error if the interface is not part of a group:
This operation is illegal because interface, int0, does not belong to an interface group.
See Adding Interfaces to an Interface Group, for more information on interface groups.
You receive the following message while the configuration is taking place:
Configuration update is in progress. This page will be unavailable for a few minutes.
The Sensing Interface page appears again and displays your changes.
Adding Interfaces to an Interface Group
An interface group provides a way to group sniffing interfaces into one logical virtual sensor. Only one interface group, 0, is supported. More than one sniffing interface may be assigned to the interface group at any given time.
Note You cannot assign the command and control interface to the interface group.
For the sensor to monitor the sniffing interfaces, the sniffing interfaces must be added to Group 0 and be enabled (see Enabling and Disabling Sensing Interfaces).
Caution For the IDS-4250-XL, interface 0 (int0) cannot be a sensing interface, because it is used for sending TCP resets.
To add an interface to an interface group and to enable an interface group, follow these steps:
Step 1 Select Configuration > Sensing Engine > Interface Groups.
The Interface Groups page appears.
The following information is displayed:
•Group Number—The logical number associated with the group. You must use 0 for this release.
Note Only one group number (0) is supported.
•Virtual Sensor—Specifies the virtual sensor you assigned to this group. You must use "virtualSensor" for this release.
Note Only one virtual sensor (virtualSensor) is supported.
•Alarm Channel—Specifies the Alarm Channel to this group. You must use "alarmChannel" for this release.
Note Only one alarm channel (alarmChannel) is supported.
•Sensing Interfaces—Defines the interfaces that belong to a group. There is no default.
•Enabled—Defines whether a group is enabled or disabled. The default is Yes.
Step 2 Select the check box next to the group interface you want to enable or disable.
Step 3 Click Enable or Disable.
Step 4 Select the check box next to the group interface you want to edit.
Step 5 Click Edit.
The Editing page appears.
Step 6 You can select one or more sensing interfaces to add to the group.
Note For this release, the only option you can edit is the Sensing Interfaces option. To select multiple interfaces, press the Ctrl key while selecting each additional interface.
Caution Selecting the command and control interface results in an invalid configuration. Do not select the command and control interface as a sensing interface. The command and control interface is int1 on most sensors, but is int0 on the router network module.
Note To reset the form, click Reset.
Step 7 To save and apply your changes, select Apply to Sensor.
The following message appears:
Configuration update in progress. This page will be unavailable for a few minutes.
Step 8 Select Configuration > Sensing Engine > Interface Groups to display the Group Interfaces page showing any changes you made.
Configuring Signatures
You can configure system variables and event filters, and tune and create signatures through the Sensing Engine.
The following sections describe how to configure signatures through the Sensing Engine:
•Explaining Signatures
•Configuring Alarm Channel System Variables
•Configuring Alarm Channel Event Filters
•Configuring Virtual Sensor System Variables
•Configuring Signatures Through Virtual Sensor Signature Configuration Mode
•Introducing the Signature Wizard
•Configuring IP Fragment Reassembly
•Configuring TCP Stream Reassembly
•Configuring IP Logging
•Identifying Traffic Oversubscription
Explaining Signatures
Attacks or other misuses of network resources can be defined as network intrusions. Network intrusions can be detected by sensors that use a signature-based technology. A signature is a set of rules that your sensor uses to detect typical intrusive activity, such as denial of service (DoS) attacks. As sensors scan network packets, they use signatures to detect known attacks and respond with actions that you define.
The sensor compares the list of signatures with network activity. When a match is found, the sensor takes an action, such as logging the event or sending an alarm to IDS Event Viewer. Sensors allow you to modify existing signatures and define new ones.
Signature-based intrusion detection can produce false positives because certain normal network activity can be misinterpreted as malicious activity. For example, some network applications or operating systems may send out numerous ICMP messages, which a signature-based detection system might interpret as an attempt by an attacker to map out a network segment. You can minimize false positives by tuning your sensors.
To configure a sensor to monitor network traffic for a particular signature, you must enable the signature. By default, the most critical signatures are enabled when you install IDS Device Manager. When an attack is detected that matches an enabled signature, the sensor generates an alert event (formerly known as an alarm), which is stored in the sensor's event store. The alert events, as well as other events, may be retrieved from the event store by web-based clients. By default the sensor logs all Informational alarms or higher. If you have added IDS Event Viewer as a destination, the alarm is sent to the IDS Event Viewer database and you can view the alarm in IDS Event Viewer.
Some signatures have subsignatures, that is, the signature is divided into subcategories. When you configure a subsignature, changes made to the parameters of one subsignature apply only to that subsignature. For example, if you edit signature 3050 subsignature 1 and change the severity, the severity change applies to only subsignature 1 and not to 3050 2, 3050 3, and 3050 4.
Built-in signatures are known attack signatures that are included in the sensor software. You cannot add to or delete from the list of built-in attack signatures. You also cannot rename them. You can tune built-in signatures by adjusting several signature parameters. Built-in signatures that have been modified are called tuned signatures.
You can create signatures, which are called custom signatures. Custom signature IDs begin at 20000. You can configure them for any number of things, such as matching of strings on UDP connections, tracking of network floods, and scans. Each signature is created using a signature engine specifically designed for the type of traffic being monitored.
Configuring Alarm Channel System Variables
You use the system variables when configuring alarm channel event filters. When you want to use the same value within multiple filters, use a variable. When you change the value of a variable, the variables in all the filters are updated. This saves you from having to change the variable repeatedly as you configure alarm filters. See Configuring Alarm Channel Event Filters, for more information.
Alarms are sent to the alarm channel, where they are filtered and aggregated. You cannot select the alarm channel, because only one alarm channel is supported.
You can change the value of an alarm channel system variable, but you cannot add variables or delete variables. You also cannot change the name, type, or constraints of a variable.
Note For all Sensing Engine pages, you must click the Save Changes icon on the Activity bar to apply your new configuration.
For example, if you had an IP address space that applied to your engineering group and there were no Windows systems in that group, and you were not worried about any Windows-based attacks, you could set up a USER-ADDR1 to be the engineering group's IP address space. You could then use this variable on the Event Filters page to set up the filter to ignore all Windows-based attacks for USER-ADDR1.
Here are some examples for designating the 192.168.1.0 network with a 255.255.255.0 netmask:
•192.168.1.0-192.168.1.255
This designates the network as a range of single IP addresses.
Note The "-" indicates the range of IP addresses between any two given IP addresses.
•192.168.1.0/24
This designates the network using the numerical bit masking.
•192.168.1.
This designates the network by leaving off the last octet.
Note The sensor treats IP addresses with missing octets as networks (unlike ping which tries to resolve it into a single IP address).
•192.168.1
This designates the network by leaving off the last octet (but without the trailing ".").
You can also designate multiple IP addresses and networks for a single variable by placing a comma between the entries. The following example, 10.20,20-50, results in the following networks:
•10.20 = Network 10.20.0.0 with netmask 255.255.0.0
•20-50 = 31 different networks 20.0.0.0 255.0.0.0, 21.0.0.0 255.0.0.0, 22.0.0.0 255.0.0.0, and so forth ending with 50.0.0.0 255.0.0.0
Each network address begins with either:
–20,21,22,23,24,25,26,27,28,29,
–30,31,32,33,34,35,36,37,38,39,
–40,41,42,43,44,45,46,47,48,49,
–or 50 for the total of 31 networks being designated.
To define alarm channel system variables, follow these steps:
Step 1 Select Configuration > Sensing Engine > Alarm Channel Configuration > System Variables.
The System Variables page appears.
Step 2 Select the check box next to the system variable you want to edit, and then click Edit.
The Editing page appears for the variable that you chose.
Note You can edit only one variable at a time. You can adjust the page view using the Rows per page list box at the bottom of the page, or you can move to additional pages of variables by selecting a page from the Page list box.
Step 3 Fill in the following values for the following system variables (according to the one that you are editing, the example above shows the USER-ADDRS1):
Note You can use commas as delimiters. Make sure there are no trailing spaces after the comma. Otherwise, you receive a Validation failed error.
•OUT
OUT is defined as anything that is not included in IN. You cannot edit this variable. The default is 0-255.255.255.255.
•IN
IN is a list of all internal IP address spaces. Enter your internal IP addresses.
•DMZ1, DMZ2, and DMZ3
You can use DMZ to define any valid IP address. These are named DMZ for you to use with filtering signatures that pertain to firewalls.
•USER-ADDRS1, USER-ADDRS2, USER-ADDRS3, USER-ADDRS4, and USER-ADDRS5
You can use USER-ADDR to define any valid IP address. You can set up a USER-ADDR variable to apply to any group of IP addresses that you want to use a filter on.
•SIG1, SIG2, SIG3, SIG4, and SIG5
You can use SIG to define popular signatures that you like to exclude for certain addresses.
Note To reset the form, click Reset.
Step 4 Click Ok.
Note To undo your changes, click the Undo Changes icon on the Activity bar.
Step 5 Click the Save Changes icon in the Activity bar to save your system variables.
The following message appears:
Configuration update in progress. This page will be unavailable for a few minutes.
In a few minutes, click Alarm Channel Configuration > System Variables again to see the edited variable in the list.
The new value appears in the Value column.
Step 6 Repeat Steps 2 though 5 to edit additional system variables.
Configuring Alarm Channel Event Filters
You can configure event filters that are based on source and destination addresses for specified signatures. You can use the alarm channel system variables that you defined on the Alarm Channel System Variables page to group addresses for your filters.
Note You must preface the variable with "$" to indicate that you are using a variable rather than a string. Otherwise, you receive the Bad source and destination error.
Note For all the Sensing Engine pages, you must click the Save Changes icon on the Activity bar to apply your new configuration.
To configure alarm channel event filters, follow these steps:
Step 1 Select Configuration > Sensing Engine > Alarm Channel Configuration > Event Filters.
The Event Filters page appears.
Step 2 Click Add to add an event filter.
The Adding page appears.
Step 3 In the SIGID field, enter the signature IDs of the events to which this filter should be applied (the above example uses the signature 7101 and the $USER-ADDRS1 system variable).
You can use a list (2001, 2004), or a range (2001-2004), an asterisk (*) for all signatures, or one of the SIG variables if you defined them on the Alarm Channel System Variables page. Preface the variable with $.
Step 4 In the SubSig field, enter the subsignature IDs of the events to which this filter should be applied.
Step 5 In the Exception field, enter the exception (Boolean) to the event filter.
Note If the filter describes an exception to an event filter, you can create a "general case" exclusion rather than adding more specific information. For example, the event filter prevents a group of signatures from firing, but the exception drills into an existing filter to allow a subset of the signatures to fire anyway.
Step 6 In the SrcAddrs field, enter the source addresses of events to which this filter should be applied.
You can use one of the DMZ or USER-ADDR variables if you defined them on the Alarm Channel System Variables page. Preface the variable with $.
Step 7 In the DestAddrs field, enter the destination addresses of events to which this filter should be applied.
You can use one of the DMZ or USER-ADDR variables if you defined them on the Alarm Channel System Variables page. Preface the variable with $.
Note To reset the form, click Reset.
Step 8 Click Apply to Sensor.
Note To undo your changes, click the Undo Changes icon on the Activity bar.
Step 9 Click Saves Changes on the Activity bar to save your changes.
The following message appears:
Configuration information is not available at this time. Try again in a few minutes.
After a few minutes, click Event Filters again to see the filter you added.
The filtered signature appears on the Event Filters page.
Step 10 To remove the filter, select the check box next to the signature and click Remove.
Step 11 To edit the filter, select the check box next to it and click Edit.
The Editing page appears.
Step 12 Make your change and click OK.
Configuring Virtual Sensor System Variables
When you want to use the same value within multiple signatures, use a variable. When you change the value of a variable, the variables in all the signatures are updated. This saves you from having to change the variable repeatedly as you configure signatures.
You can change the value of a system variable but you cannot add variables or delete variables. You cannot change the name or type of a variable. You cannot select the virtual sensor, because only one virtual sensor is supported.
Note For all the Sensing Engine pages, you must click the Save Changes icon on the Activity bar to apply your new configuration.
To configure the virtual sensor system variables, follow these steps:
Step 1 Select Configuration > Sensing Engine > Virtual Sensor Configuration > System Variables.
The System Variables page appears.
Step 2 Select the system variable that you want to edit and click Edit.
The Editing page appears.
Step 3 Fill in the value of the system variable that you want to edit (the example above shows Ports1):
Note You can edit only one system variable at a time. You can adjust the page view using the Rows per page list box at the bottom of the page, or you can move to additional pages of variables by selecting a page from the Page list box.
•WEBPORTS—WEBPORTS has a predefined set of ports where web servers are running, but you can edit the value. This variable affects all signatures that have web ports. The default is 80, 3128, 8000, 8010, 8080, 8888, 24326.
•Ports1, Ports2, Ports3, Ports4, Ports5, Ports6, Ports7, Ports8, Ports9—You can set up a list of ports to apply to particular signatures.
•IPReassembleMaxFrags—You can define the total number of fragments you want the system to queue. You can define a number between 1000 and 50,000. The default is 10,000.
Note To reset the form, click Reset.
Step 4 Click OK.
Note To undo your changes, click the Undo Changes icon on the Activity bar.
Step 5 Click the Save Changes icon on the Activity bar to save your system variables.
The following message appears:
Configuration update in progress. This page will be unavailable for a few minutes.
After a few minutes, click Virtual Sensor Configuration > System Variables to see the edited variable.
The new value appears in the Value column.
Step 6 Repeat Steps 2 though 5 to edit additional system variables.
Configuring Signatures Through Virtual Sensor Signature Configuration Mode
The Signature Configuration Mode page displays a list of top level categories of signature groups for the virtual sensor. You can see all signatures in the list or you can see signatures that are grouped according to their signature engine type. Certain signatures are enabled by default to provide you immediately with a certain level of security. When you modify a built-in signature, it becomes a tuned signature. You can also create signatures, which are called custom signatures.
You cannot select the virtual sensor, because there is only one virtual sensor.
You can display all individual signatures at once by clicking All Signatures. If you are looking for a particular signature, click All Signatures, and use the browser's search option to find the string you are looking for—the signature ID or the signature name.
You can display the signature list within a group by clicking the group name. Each group displays its enable level (the disabled, partially enabled, or enabled icon). You can enable or disable one, some, or all signatures within the group. To select the signature for enabling or disabling, select the signature check box.
You can tune built-in signatures. To tune a signature, select the check box and click Edit. Some signatures have subsignatures, which you can edit individually to have more control over the signature. See Tuning Built-in Signatures, for the procedure.
You can create custom signatures, and then delete one, some, or all custom signatures. To create a custom signature, choose the correct signature engine, and then click Add and configure the signature parameters. For more information on signature engines and their parameters, see Working With Signature Engines.
Note You can also use the Signature Wizard, which walks you through the process of creating custom signatures.
A signature can be in multiple groups. Editing a signature in one group affects it in all groups. For example, if you enable all general attack signatures in the Attack category, it will enable 7107. If you disable the ATOMIC.ARP signature in the Engine category, 7107 will be disabled. The last edit that you make is the one that is applied.
This section contains these topics:
•Working with Virtual Sensor Signature Configuration Mode
•Tuning Built-in Signatures
•Creating Custom Signatures
Working with Virtual Sensor Signature Configuration Mode
On the Signature Configuration Mode page, you can enable and disable signature groups or signatures, you can view all signatures, and you can restore defaults to signatures that you have tuned. When a signature is enabled, it sends an alarm.
You can click any signature ID number and see the description of the signature in the NSDB. See Network Security Database for more information on the NSDB.
To enable, disable, view, or restore defaults to signatures, follow these steps:
Step 1 Select Configuration > Sensing Engine > Virtual Sensor Configuration > Signature Configuration Mode.
The Signature Groups page appears.
Step 2 To enable or disable all signatures in a group, select the check box next to the signature group, and then click Enable or Disable.
Note A clear circle indicates that no signatures in that signature group are enabled. A solid circle indicates that all signatures are enabled. A partial circle indicates that at least one signature in that group is enabled.
You receive the following message:
Selected Signatures have been enabled. To commit the changes please click the save changes
icon in the Activity Bar.
Step 3 Either save your changes by clicking the Save Changes icon or select the check box next to the signature group and click Restore Defaults to return the group to its default settings.
Step 4 To enable or disable a single signature, do one of the following:
•Click All Signatures to display all the IDS signatures.
Note You can select signatures by range in the Page list box. If you select All in the Rows per page list box, it can take some time for all signatures to be displayed.
The All Signatures page appears.
You can click any signature ID number and see the description of the signature in the NSDB. See Network Security Database, for more information on the NSDB.
•Click a signature group name:
–Click, for example, Attack Signatures.
The Attack page appears.
–Click the Attack signature group you want to enable or disable, for example, DoS:
Step 5 Select the check boxes next to the signature(s) that you want to enable or disable and click Enable or Disable.
Caution Signatures can belong to more than one group. Enabling or disabling signatures in one group also affects those signatures that belong to other groups.
You receive the following message:
Selected Signatures have been enabled. To commit the changes please click the save changes
icon in the Activity Bar.
Step 6 Either save your changes by clicking the Save Changes icon or select the check boxes next to the signatures and click Restore Defaults to return the signatures to their default settings.
Note After you are at the single signature level, you can edit (tune) signatures. See Tuning Built-in Signatures, for the procedure.
Step 7 Select the check boxes next to the signatures that you want to delete and click Delete.
Note You cannot delete built-in or tuned signatures, only custom signatures.
See Creating Custom Signatures, for the procedure for creating custom signatures.
Step 8 Click the Save Changes icon on the Activity bar to save your changes.
The following message appears:
Configuration update in progress. This page will be unavailable for a few minutes.
Step 9 Click Virtual Sensor Configuration > Signature Configuration Mode to return to the Signature Configuration Mode page.
Step 10 Click All Signatures or the relevant signature group to see the enabled or disabled signature in the list.
Tuning Built-in Signatures
To tune a signature, you must get to the level of a single signature and click Edit. A list of the possible parameters for that signature appears. You can edit any of the parameters, but you must have a value for the ones marked with a red asterisk. Some parameters have menu lists you can choose from; for others you must add text. You can pass your mouse over the parameters to see what the valid values are for each one. For more information on signature engines and parameters, see Working With Signature Engines.
To tune signatures, follow these steps:
Step 1 Select Configuration > Sensing Engine > Virtual Sensor Configuration > Signature Configuration Mode.
The Signature Groups page appears.
Step 2 Click All Signatures to display all IDS signatures or click a signature group name.
In this example, use the All Signatures page.
The All Signatures page appears.
Note If you select All in the Rows per page list box, it can take some time for all signatures to display.
Step 3 Select the check box next to the signature that you want to edit (in this example, Signature 993 from the Other engine), and click Edit.
Note You can edit only one signature at a time. You can adjust the page view using the Rows per page list box at the bottom of the page, or you can move to additional pages of variables by selecting a page from the Page list box. Click Back to go to the previous page.
The Editing page appears.
Step 4 Make your changes to the signature's parameters, for example, change the Alarm Severity from Informational to Medium.
Pass your mouse over the parameters for descriptions of each parameter. See Working With Signature Engines for a detailed description of signature engines and parameters.
Note To generate IP logs, set the EventAction to log. When the sensor detects an attack based on this signature, it automatically creates an IP log. See Configuring IP Logging, page 5-4 and Downloading IP Logs, page 4-1 for more information.
Step 5 Click Ok to save the changes you made to the built-in signature.
You receive the following message:
Signature has been updated. To commit the changes please click the save changes icon in
the Activity bar.
The page is redisplayed showing that the Alarm Severity has changed from Informational to Medium. The Type is now changed from Built-in to Tuned, because you have edited this signature.
Note You can use the Back button at the bottom of the page to move through the signature pages.
Step 6 Click the Save Changes icon on the Activity bar to save your changes.
The following message appears:
Configuration update in progress. This page will be unavailable for a few minutes.
Step 7 Click Virtual Sensor Configuration > Signature Configuration Mode to return to the Signature Configuration Mode page.
Step 8 Click All Signatures or the relevant signature group to see the tuned signatures in the list.
Creating Custom Signatures
You can create custom signatures, and then delete one, some, or all custom signatures. To create a custom signature, choose the correct signature engine, and then click Add and configure the signature parameters. For more information on signature engines and their parameters, see Working With Signature Engines.
You cannot select the virtual sensor, because there is only one virtual sensor.
To create custom signatures, follow these steps:
Step 1 Select Configuration > Sensing Engine > Virtual Sensor Configuration > Signature Configuration Mode.
The Signature Configuration Mode page appears.
Step 2 Click Engines on the Signature Groups page.
The Engines page appears.
Step 3 Click the engine you want to use to create a custom signature, for example, TRAFFIC.ICMP.
The TRAFFIC.ICMP page lists the built-in signatures.
Step 4 Click Add.
The Adding TRAFFIC.ICMP page appears.
Step 5 Fill in the parameters that you want, and then click Ok.
Pass your mouse over the categories for descriptions of each category. See Working With Signature Engines, for a detailed description of signature engines and categories.
Note To generate IP logs, set the EventAction to log. When the sensor detects an attack based on this signature, it automatically creates an IP log. See Configuring IP Logging, page 5-4 and Downloading IP Logs, page 4-1, for more information.
Note Custom signature IDs are in the range of 20000 to 50000.
The following message appears:
Signature has been added. To commit the changes please click the save changes icon in the
Activity bar.
The TRAFFIC.ICMP page shows the new signature with the Type as Custom.
Step 6 Click the Save Changes icon on the Activity bar to save your changes.
The following message appears:
Configuration update in progress. This page will be unavailable for a few minutes.
Step 7 Click Signature Configuration Mode to return to the Signature Configuration Mode page.
Step 8 Click All Signatures or the relevant signature group to see the custom signature in the list.
Introducing the Signature Wizard
The Signature Wizard guides you through the process of creating custom signatures so that you do not have to have detailed knowledge of all the signature engines and their parameters.
The Signature Wizard consists of six tasks:
•Choosing the signature type (Signature Type).
•Identifying the signature (Signature Identification).
•Setting the engine-specific parameters (Engine-Specific Parameters).
•Setting the alert response (Alert Response).
•Setting the alert behavior (Alert Behavior).
•Completing the custom signature (Finish).
Some signature parameters are common to all signatures. These Master Engine parameters are organized into the following groups: identity, alert behavior, and alert response parameters. After you choose the Signature Type (Web, single packet, string), you configure the parameters that are specific to that type of signature.
Note After you create custom signatures, you are encouraged to test them by enabling the Dropped Packet Count signature (993). See Identifying Traffic Oversubscription, for more information.
This section contains the following topics:
•Creating Custom Signatures Through the Signature Wizard
•Sample HTTP Request
•Regular Expression Syntax
Creating Custom Signatures Through the Signature Wizard
The Signature Wizard provides a step-by-step procedure for configuring custom signatures. Once you are more familiar with the process, you can also configure custom signatures through Virtual Sensor Configuration Mode. See Creating Custom Signatures, for the procedure.
See Working With Signature Engines, for more information on signature engines and their parameters.
To create custom signatures using the Signature Wizard, follow these steps:
Step 1 Select Configuration > Sensing Engine > Virtual Sensor Configuration > Signature Wizard.
The Signature Wizard main page appears.
Note After you create custom signatures, you are encouraged to test them by enabling the Dropped Packet Count signature (993). See Identifying Traffic Oversubscription, for more information.
Step 2 Click Start the Wizard.
Step 3 Complete the first wizard task by selecting one of the following Signature Types and then clicking Next:
•Web Server Signatures—Capture regular expressions in web URL requests and check arguments URI, length, and other parameters. These signatures only search traffic directed to web services or HTTP requests. Return traffic cannot be inspected using these signatures. In each signature you can specify separate web ports of interest.
See Sample HTTP Request, for sample HTTP request.
•Packet Signatures (TCP, UDP, or IP)—Inspect traffic by port and protocol (also known as Atomic signatures).
•Stream Signatures (TCP, UDP, or ICMP)—Perform simple stateful expression-matching based on protocol.
Step 4 Complete the second wizard task by filling in the Signature Identification fields.
a. Enter a number in the Signature ID field.
Custom signatures are in the range of 20,000 to 50,000.
b. Enter a number in the SubSignature ID field.
The default is 0.
You can assign a subsignature ID if you are grouping signatures together that are similar.
c. Enter a name in the Signature Name field.
By default the signature engine (according to the signature type that you chose in Step 3) appears in the Signature Name field. Change it to a name that is more specific for your custom signature.
Note The signature name, along with the signature ID and subsignature ID are reported to the IDS Event Viewer when an alert is generated.
d. Enter text in the Alert Notes field (optional).
You can add text to be included in alarms associated with this signature. These notes are reported to the IDS Event Viewer when an alert is generated.
e. Enter text in the User Notes field (optional).
You can add any text that you find useful here. This field does not affect the signature or alert in any way.
f. Click Next.
g. If you are creating a web server signature, enter which ports you want the signature to monitor in the Web Server Service Ports field, and then click Next.
Note By default, this signature monitors HTTP requests specified in the WEBPORTS virtual sensor system variable. WEBPORTS is a list of web ports to be used for standard HTTP signatures. See Configuring Virtual Sensor System Variables, for more information. The default web ports are 80, 3128, 8000, 8010, 8080, 8888, and 24326.
Step 5 Complete the third wizard task by configuring the engine-specific parameters.
For web server signatures, see Step 6. For packet signatures, see Step 7. For stream signatures, see Step 8.
Step 6 Configure the engine-specific parameters for the web server signatures:
Web server signatures allow you to match regular expressions to strings from an entire incoming HTTP request, the HTTP header, the URI, or the argument list. Or you can check for potential buffer overflow conditions in these fields. The signature does not fire unless all specified conditions are met.
a. Enter the number of bytes in the following Web Server Buffer Overflow Checks fields to detect attempted buffer overflows:
•Maximum Length of HTTP Request field—Specifies a maximum length for the entire HTTP request.
•Maximum Length of HTTP Header—Specifies a maximum length for the entire HTTP header.
•Maximum Length of HTTP URI field—Specifies a maximum length for the HTTP URI.
•Maximum Length of HTTP Arguments—Specifies a maximum length for the HTTP argument list.
b. Enter any regular expressions you want to match in the Web Server Regular Expressions fields:
You can match regular expressions to strings from an entire incoming HTTP request, the HTTP header, the URI, or the argument list.
Note Click the icon next to the regular expression field to see the Regular Expression Builder for help in creating regular expressions. See Regular Expression Syntax, for a table listing the IDS version 4.1 regular expression syntax.
•HTTP Request Regular Expression—Specifies a regular expression that matches text in the entire HTTP request.
•Minimum HTTP request length—Specifies a minimum length for the request before the regular expression will match it.
Note You can only set the minimum length if your request regular expression contains a * or + regular expression operator.
•HTTP Header Regular Expression—Specifies a regular expression that matches text in the HTTP header.
•HTTP Header URI Regular Expression—Specifies a regular expression that matches text in the HTTP header URI.
•HTTP Header Argument Name Regular Expression—Specifies a regular expression that matches an HTTP header argument name.
•HTTP Header Argument Value Regular Expression—Specifies a regular expression that matches an HTTP header argument value.
c. Click Next.
Step 7 Configure the engine-specific parameters for packet signatures and then click Next.
a. For TCP Packet Signatures:
Note TCP packet signatures examine individual TCP packets. They check for a regular expression, TCP flags, or traffic on specified ports. The signature does not fire unless all specified conditions are met.
•TCP Packet Regular Expression—Specifies the regular expression used to check for matches to a regular expression in the text of a single TCP packet.
Note Click the icon next to the TCP Packet Regular Expression field to see the Regular Expression Builder for help in creating regular expressions. See Regular Expression Syntax, for a table listing the IDS version 4.1 regular expression syntax.
•Source Port—Checks for matching source ports in TCP packets.
The value is 0 to 65535.
•Range of Source Ports—Checks for traffic sent from all ports, low ports (0-1023), or high ports (1024-65535).
The values are all ports=0, low ports=1, or high ports=2.
•Destination Port—Checks for matching destination ports in TCP packets.
The value is 0 to 65535.
•Range of Destination Ports—Checks for traffic sent to all ports, low ports (0-1023), or high ports (1024-65535).
The values are all ports=0, low ports=1, or high ports=2.
•TCP Flags—Checks for matching values in TCP packets.
The values are: True, False, Do Not Care. True means that the signature fires if the flag is not set (that is, the sensor expects the flag to be true). False means the signature fires if the flag is set, and a value of Do Not Care means the flag is not inspected.
•TCP SYN Flag
•TCP RST Flag
•TCP PSH Flag
•ACK PSH Flag
•ACK URG Flag
•TCP FIN Flag
•Source IP Address—Indicates the IP address for the source host or network.
•Source IP Mask—Indicates the netmask for the source host or network.
•Destination IP Address—Indicates the IP address for the destination host or network.
•Destination IP Mask—Indicates the netmask for the destination host or network.
b. For UDP Packet Signatures:
Note UDP packet signatures examine individual UDP packets. They check for traffic on specified ports and packet size. The signature does not fire unless all specified conditions are met.
•Source Port—Checks for matching source ports in UDP packets.
•Destination Port—Checks for matching destination ports in UDP packets.
•Minimum UDP Packet Length—Checks for a minimum length for the UDP packet.
•Short UDP Packet Length—Checks for an IP data length that is less than the UDP Header Length.
•Source IP Address—Indicates the IP address for the source host or network.
•Source IP Mask—Indicates the netmask for the source host or network.
•Destination IP Address—Indicates the IP address for the destination host or network.
•Destination IP Mask—Indicates the netmask for the destination host or network.
c. For IP Packet Signatures:
Note IP packet signatures examine individual IP packets. The signature does not fire unless all specified conditions are met.
•Examine ICMP Packets only—Examines ICMP packets only.
•Impossible Packets—Fires the signature only if the source and destination addresses are equal.
•Local Host only—Fires the signature if the local host (127.0.0.1) address is seen in the packet.
•Overrun Packets—Fires the signature if a fragment overrun occurs.
•Reserved Packets—Fires the signature if a reserved IP address as specified in RFC1918 is used.
•Maximum Data Length—Sets a maximum allowable length for the data length of an IP packet.
•Maximum Inspection Length—Specifies the maximum number of bytes to inspect.
•Maximum Time To Live (TTL)—Specifies the maximum number of seconds to inspect a logical stream.
•Maximum Protocol Number (0-255)—Specifies the maximum allowable protocol number.
•Minimum IP Data Length—Sets a minimum allowable length for the data length of a IP packet.
•IP Protocol Number—Specifies the signature to fire if the packet uses a specific protocol.
•IP Protocol Name—Specifies the signature to fire if the packet uses a specific protocol name. The values are FRAG, IP, TCP, UDP, ICMP, ARP, CROSS, CUSTOM, and ZERO.
•Minimum IP Protocol Number (0-255)—Sets a minimum allowable protocol number.
•Maximum Protocol Number (0-255)—Sets a maximum allowable protocol number.
•Source IP Address—Indicates the IP address for the source host or network.
•Source IP Mask—Indicates the netmask for the source host or network.
•Destination IP Address—Indicates the IP address for the destination host or network.
•Destination IP Mask—Indicates the netmask for the destination host or network.
Step 8 Configure the engine-specific parameters for stream signatures (TCP, UDP, and ICMP):
Note Stream signatures examine individual packets for a specified string. The signature does not fire unless all specified conditions are met.
Note See Regular Expression Syntax, for a table listing the IDS version 4.1 regular expression syntax.
•Regular Expression—Specifies a regular expression to be matched in single packets.
•Service Ports—Specifies a list or range of destination ports to check.
•Direction—Specifies whether to inspect packets going to or from the destination ports. The values are To Port and From Port.
•Offset in Packet to Examine (bytes)—Limits this signature to only fire if the regular expression occurs at a specified offset in the stream (optional).
•Minimum Matching String Length—Limits this signature to only fire if the matching string is at least this size (optional).
Step 9 Complete the fourth wizard task by selecting the Alert Response Actions.
a. Select the severity to be reported by the IDS Event Viewer when the sensor sends an alert:
•High
•Informational
•Low
•Medium
b. Select an action for the sensor to take in addition to firing the alert:
Note Some Event Action options do not appear for all signatures. This is determined by the signature engine.
•Log—The sensor logs the traffic that caused the alert.
•Reset—The sensor sends a TCP reset to the attacker to break the connection.
•Shun Host—The sensor dynamically configures a network device to block all packets from the attacker to the local network.
•Shun Connection—The sensor dynamically configures a network device to block packets from the attacker that are directed specifically at a victim IP address and port.
•ZERO—The sensor takes no action (default).
c. Choose whether to swap the source and destination addresses that are reported in the alert when this signature fires:
•Yes—Swaps the address
•No—Does not swap the address.
d. Chose whether to include the packet that caused the signature to fire in the alert:
•True—Includes the packet.
•False—Does not include the packet.
e. Click Next.
Step 10 Complete the fifth wizard task by defining the Alert Behavior.
a. Click Next to accept the default behavior.
b. Click Advanced to fine tune the alert behavior.
Note You can control how often this signature fires. For example, you may want to decrease the volume of alerts sent out from the sensor. Or you may want the sensor to provide basic aggregation of signature firings into a single alert. Or you may want to counter anti-IDS tools such as "stick," which are designed to send bogus traffic so that the IDS produces thousands of alerts in a very short time period.
See Steps 11 though 15 for the procedure to configure advanced alert behavior.
Step 11 To send an alert each time the signature fires:
a. Select Alert Each Time and then click Next.
b. To change the response, select Dynamic Response.
When the alert rate exceeds a specified number of signatures in a specified number of seconds, the sensor changes from sending a single alert for each signature to sending a single global summary alert. When the rate during the interval drops below this threshold, the sensor reverts to its configured alert behavior. A global summary counts signature firings on all attacker IP addresses and ports and all victim IP addresses and ports.
c. Enter the threshold signature firing rate in the Threshold field.
The default is 100.
d. Enter the interval in seconds in the Interval field.
The default is 30 seconds.
e. Click Next.
f. Choose one of the following address sets to use to count the number of signatures during the interval:
•All address fields—Summarizes and inspects based on the attacker IP address and attacker port, victim IP address and victim port.
•Attacker IP address—Summarizes and inspects based on the attacker IP address.
•Victim IP address—Summarizes and inspects based on the victim IP address.
•Attacker and Victim IP addresses—Summarizes and inspects based on the attacker IP address and victim IP address.
Step 12 To send an alert each time the signature fires, but to tell the sensor not to continue inspecting for this alert for a specified number of seconds after it fires:
a. Select Fire Alert One Time and click Next.
b. To change the response, click Dynamic Response.
c. Enter the threshold signature firing rate in the Threshold field.
The default is 100.
d. Enter the interval in seconds in the Interval field.
The default is 30 seconds.
e. Click Next.
f. Choose one of the following address sets to use to count the number of signatures during the interval:
•All address fields—Summarizes and inspects based on the attacker IP address and attacker port, victim IP address and victim port.
•Attacker IP address—Summarizes and inspects based on the attacker IP address.
•Victim IP address—Summarizes and inspects based on the victim IP address.
•Attacker and Victim IP addresses—Summarizes and inspects based on the attacker IP address and victim IP address.
Step 13 To send the first alert for each address set, and then a summary of all the alerts that occur on this address set over a given interval of time:
a. Select Summary Alert and then click Next.
b. Enter the number of seconds for the summary interval in the Summary Interval field and then click Next.
The default is 30 seconds.
c. To change the response, click Dynamic Response.
d. Enter the threshold signature firing rate in the Threshold field.
The default is 100.
e. Enter the interval in seconds in the Interval field.
The default is 30 seconds.
f. Click Next.
g. Choose one of the following address sets to use to count the number of signatures during the interval:
•All address fields—Summarizes and inspects based on the attacker IP address and attacker port, victim IP address and victim port.
•Attacker IP address—Summarizes and inspects based on the attacker IP address.
•Victim IP address—Summarizes and inspects based on the victim IP address.
•Attacker and Victim IP addresses—Summarizes and inspects based on the attacker IP address and victim IP address.
h. Click Next.
Step 14 To send the first alert, and then a global summary of all the alerts that occur on all address sets over a specified interval of time:
Note if you choose this option, you will not be able to configure the sensor to dynamically change its behavior based on signature firing frequency.
a. Select Global Summary and the click Next.
b. Enter the number of seconds for the global summary.
The default is 15 seconds.
Step 15 To send an alert if the signature fires a specified number times in a specified number of seconds:
Note If you choose this option, you will not be able to configure the sensor to dynamically change its behavior based on signature firing frequency.
a. Select Fixed Rate and Interval and then click Next.
b. Enter the number of times the signature must fire over the time interval.
The default is 1.
c. Enter the interval in seconds.
d. Choose one of the following address sets to use to count the number of signatures during the interval:
•All address fields—Summarizes and inspects based on the attacker IP address and attacker port, victim IP address and victim port.
•Attacker IP address—Summarizes and inspects based on the attacker IP address.
•Victim IP address—Summarizes and inspects based on the victim IP address.
•Attacker and Victim IP addresses—Summarizes and inspects based on the attacker IP address and victim IP address.
Step 16 Click Create to create the custom signature.
You receive this message:
You have successfully created the signature. Click Apply Changes on the main page when you
are ready to commit the changes.
Step 17 Click OK on the message window.
Step 18 Click OK on the Wizard Completed page.
You are returned to the main Signature Wizard page.
Step 19 Click the Save Changes icon in the activity bar to save your custom signature.
Sample HTTP Request
Web server signatures enable you to match regular expressions to strings from an entire incoming HTTP request, the HTTP header, the URI, or the argument list. Or you can check for potential buffer overflow conditions in these fields. The signature will not fire unless all specified conditions are met.
This is a sample HTTP request:
POST /eng/Tech/projectB/foobar.html?name=john&last=doe HTTP/1.0
<CRLF>
Accept: text/html
User-Agent: Mozilla
Host: 10.1.20.55
Content-Length: 45
<CRLF>
<CRLF>
Argument1=td&Argument2=foobar&middlename=levi&<CRLF>
In this example, the HTTP URI begins immediately after the HTTP method up to and including the first LF or argument delimiter (?&):
/eng/Tech/projectB/foobar.html
If the URI contains an argument delimiter "&" or "?," the arguments start immediately following the delimiter up to the first LF. If the POST method is used, the arguments also include all data in the entity-body as defined by the Content-Length header field. The Arguments section may be empty if neither of these cases is true. In the case of a POST, the entity body may be inspected before the arguments in the URI request line.
name=john&last=doe
Argument1=td&Argument2=foobar&middlename=levi
The HTTP header starts immediately after the first LF up to the double <CRLF><CRLF>:
Accept: text/html User-Agent: Mozilla Host:
10.1.20.55 Content-Length: 45
The HTTP request consists of the entire request, undivided:
POST /eng/Tech/projectB/foobar.html?name=john&last=doe HTTP/1.0<CRLF>
Accept: text/html
User-Agent: Mozilla
Host: 10.1.20.55
Content-Length: 45
<CRLF><CRLF>
Argument1=td&Argument2=foobar&middlename=levi<CRLF>
Regular Expression Syntax
Regular expressions (Regex) are a powerful and flexible notational language that enable you to describe text. In the context of pattern matching, regular expressions allow a succinct description of any arbitrary pattern.
Table 3-1 lists IDS version 4.1 Regex syntax.
Table 3-1 Regular Expression Syntax
Metacharacter
|
Name
|
Description
|
?
|
Question mark
|
Repeat 0 or 1 time.
|
*
|
Star, asterisk
|
Repeat 0 or more times.
|
+
|
Plus
|
Repeat 1 or more times.
|
{x}
|
Quantifier
|
Repeat exactly X times.
|
{x,}
|
Minimum quantifier
|
Repeat at least X times.
|
.
|
Dot
|
Any one character except new line (0x0A).
|
[abc]
|
Character class
|
Any character listed.
|
[^abc]
|
Negated character class
|
Any character not listed.
|
[a-z]
|
Character range class
|
Any character listed inclusively in the range.
|
( )
|
Parenthesis
|
Used to limit the scope of other metacharacters.
|
|
|
Alternation, or
|
Matches either expression it separates.
|
^
|
caret
|
The beginning of the line.
|
\char
|
Escaped character
|
When char is a metacharacter or not, matches the literal char.
|
char
|
Character
|
When char is not a metacharacter, matches the literal char.
|
\r
|
Carriage return
|
Matches the carriage return character (0x0D).
|
\n
|
New line
|
Matches the new line character (0x0A).
|
\t
|
Tab
|
Matches the tab character (0x09).
|
\f
|
Form feed
|
Matches the form feed character (0x0C).
|
\xNN
|
Escaped hexadecimal character
|
Matches character with the hexadecimal code 0xNN (0<=N<=F).
|
\NNN
|
Escaped octal character
|
Matches the character with the octal code NNN (0<=N<=8).
|
All repetition operators match the shortest possible string as opposed to other operators that consume as much of the string as possible thus giving the longest string match.
Table 3-2 lists examples of Regex patterns.
Table 3-2 Regex Patterns
To Match
|
Regular Expression
|
Hacker
|
Hacker
|
Hacker or hacker
|
[Hh]acker
|
Variations of bananas, banananas, banananananas
|
ba(na)+s
|
foo and bar on the same line with anything except a new line between them
|
foo.*bar
|
Either foo or bar
|
foo|bar
|
Either moon or soon
|
(m|s)oon
|
Configuring IP Fragment Reassembly
You can configure the sensor to reassemble a datagram that has been fragmented over multiple packets. You can specify boundaries that the sensor uses to determine how many datagrams and how long to wait for more fragments of a datagram. The goal is to ensure that the sensor does not allocate all of its resources to datagrams that cannot be completely reassembled, either because the sensor missed some frame transmissions or because an attack has been launched that is based on generating random fragment datagrams.
To configure IP fragment reassembly, follow these steps:
Step 1 Select Configuration > Sensing Engine > Virtual Sensor Configuration > IP Fragment Reassembly.
The IP Fragment Reassembly page appears.
Step 2 Select the operating system you are using from the IP Reassemble Mode list box:
•NT
•Solaris
•Linux
•BSD
Step 3 Enter the number of fragments that you want the sensor to try to reassemble in the Maximum Reassemble Fragments field.
The default is 10000.
Step 4 Enter the maximum number of seconds that can elapse before the sensor stops keeping track of a particular exchange for which it is trying to reassemble a fragment in the IP Reassemble Timeout field.
The default is 120 seconds.
Note To reset the form, click Reset.
Step 5 Click Ok to save your changes.
The following message appears:
IP Fragment Reassembly configuration has been updated. To commit the changes please click
the save changes icon in the Activity bar.
Configuring TCP Stream Reassembly
You can configure the sensor to monitor only TCP sessions that have been established by a complete three-way handshake. You can also configure how long to wait for the handshake to complete, and how long to keep monitoring a connection where no more packets have been seen. The goal is to prevent the sensor from creating alarms where a valid TCP session has not been established. There are known attacks against IDS systems that try to get the IDS to generate alarms by simply replaying pieces of an attack. The TCP session reassembly feature helps to mitigate these types of attacks against the IDS.
To configure TCP stream reassembly, follow these steps:
Step 1 Select Configuration > Sensing Engine > Virtual Sensor Configuration > TCP Stream Reassembly.
The TCP Stream Reassembly page appears.
Step 2 To specify that the sensor track only sessions for which the three-way handshake is completed, select Enable TCP Three Way Handshake.
Step 3 Select the mode of reassembly in the TCP Reassemble Mode list box:
•strict—If a packet is missed for any reason, all packets after the missed packet are be processed.
•loose—Use in environments where packets might be dropped.
Step 4 In the TCP Open Established Timeout field, enter the number of seconds that can elapse before the sensor frees the resources allocated to a fully established TCP connection when no more packets are being seen for that connection.
The value is between 15 and 3600. The default is 900.
Step 5 In the TCP Embryonic Timeout field, enter the number of seconds that can elapse before the sensor frees the resources allocated for an initiated, but not fully established, TCP session.
Note A session is considered embryonic if it has not completed the three-way handshake.
The value is between 11 and 128 seconds. The default is 15 seconds.
Step 6 In the TCP Max Queue Size field, enter the number of packets that enter the queue.
The default is 32.
Note To reset the form, click Reset.
Step 7 Click Apply to Sensor to save your changes.
The following message appears:
TCP Stream Reassembly configuration has been updated. To commit the changes please click
the save changes icon in the Activity bar.
Configuring IP Logging
You can configure a sensor to generate an IP session log when the sensor detects an attack. When IP logging is configured as a response action for a signature and the signature is triggered, all packets to and from the source address of the alarm are logged for a specified period of time. You can set the number of minutes events are logged.
Note You only have to enter one of the values (Step 2, 3, or 4). IP logging will stop at the first condition met. If you do not specify any values, there is a automatic time default of 10 minutes.
To configure IP logging, follow these steps:
Step 1 Select Configuration > Sensing Engine > Virtual Sensor Configuration > IP Log.
The IP Logs page appears.
Step 2 Enter the number of packets you want logged in the IP Log Packets field.
Step 3 Enter the number of minutes you want IP logging to be done in the IP Log Time field.
The value is 1 to 60 minutes. The default is 30 minutes.
Step 4 Enter the number of bytes you want logged in the IP Log Bytes field.
Step 5 Click Ok to save your changes.
The following message appears:
IP Log configuration has been updated. To commit the changes please click the save changes
icon in the Activity bar.
Identifying Traffic Oversubscription
Signature 993 alarms tell you if the sensor is dropping packets and the percentage dropped to help you tune the traffic level you are sending to the sensor. For example, if the alarms show that there is zero or a very small percentage of dropped packets, the sensor is able to monitor the quantity of traffic being sent.
If you are seeing 993 alarms with a higher percentage of dropped packets, your sensor is oversubscribed. When a sensor gets oversubscribed, it can have difficulty in detecting alarms in TCP streams in a nonlinear fashion. The percentage of streams that are affected by the dropped packets is not easy to predict. If you find that you are operating your sensor in an environment where it is oversaturated and you need to continue operating it in that environment, we recommend disabling the TCP3WayHandshake and setting TCPReassemblyMode to loose so that best security is ensured.
Signature 993, which is part of the signature engine OTHER, has the following configuration parameters:
•MpcTimeout in seconds 5 <= MpcTimeout <= 2500 (default = 30)
MpcTimeout is the interval between alarms.
•MpcPercentThreshold in percent 0 <= MpcPercentThreshold <= 100 (default = 0)
MpcPercentThreshold is the percentage of missed packets that must be exceeded to trigger an alarm. A value of 100 percent disables this threshold.
If the MpcPercentThreshold is exceeded, the alarm is triggered.
Note If signature 993 is firing with 100 percent packet loss, the sensor is not generating alarms and there is a problem. Make sure that you have the most recent version of the sensor. If you have the most recent version, contact TAC to report the problem.
See OTHER Engine, for more information on the OTHER signature engine.
Configuring Blocking
You can configure a sensor to block an attack by generating ACL rules for publication to a Cisco IOS router, or a Catalyst 6500 family switch, or by generating shun rules on a PIX Firewall.
The following sections describe how to set up blocking:
•Configuring Blocking Properties
•Configuring Addresses Never to Block
•Setting Up Logical Devices
•Configuring Blocking Devices
•Configuring Router Blocking Device Interfaces
•Configuring Catalyst 6K Blocking Device Interfaces
•Configuring a Master Blocking Sensor
Configuring Blocking Properties
You set up global blocking properties for the Network Access Controller (NAC) on the Blocking Properties page. The NAC controls blocking actions on managed devices.
To configure blocking properties, follow these steps:
Step 1 Select Configuration > Blocking Properties.
The Blocking Properties page appears.
Step 2 Select the Enable Blocking check box.
Step 3 Do not select the Allow the Sensor IP to be Blocked check box unless necessary.
Caution We suggest that you do not allow the sensor to block itself, because it may stop communicating with the managed device. You can select this option if you can ensure that if the sensor creates a rule to block its own IP address, it will not prevent the sensor from accessing the blocking device.
Step 4 In the Maximum Block Entries field, enter how many blocks are to be maintained simultaneously (0 to 250).
Note We do not recommend or support setting the maximum block entries higher than 250.
The default value is 100.
Note The number of blocks will not exceed the maximum block entries. If the maximum is reached, new blocks will not occur until existing blocks time out and are removed.
Step 5 In the Block Time field, enter the amount of time you want the block to last.
The default is 30 minutes.
Note If you change the default block time, you are changing a signature parameter, which affects all signatures. The update may take a while. You receive the following message: Configuration update in progress. This page will be unavailable for a few minutes.
Step 6 Click Apply to Sensor to save your changes.
Note To reset the form, click Reset.
Configuring Addresses Never to Block
You must tune your sensor to identify hosts and networks that should never be blocked, not even manually, because you may have a trusted network device whose normal, expected behavior appears to be an attack. Such a device should never be blocked, and trusted, internal networks should never be blocked. Properly tuning signatures reduces the number of false positives and helps ensure proper network operations. Tuning and filtering signatures prevents alarms from being generated. If an alarm is not generated, the associated block does not occur.
If you specify a netmask, this is the netmask of the network that should never be blocked. If no netmask is specified, only the IP address you specify will never be blocked.
To set up addresses never to be blocked by blocking devices, follow these steps:
Step 1 Select Configuration > Never Block Addresses.
The Never Block Addresses page appears.
Step 2 Click Add to add addresses that should never be blocked.
The Adding page appears.
Step 3 In the IP Address field, enter the IP address of the host that should never be blocked.
Step 4 In the Network Mask field, enter the network mask of the network that should never be blocked.
Note To reset the form, click Reset.
Step 5 Click Apply to Sensor to save your changes.
Setting Up Logical Devices
You must set up logical devices for the other hardware that the senor will manage. For example, routers that all share the same passwords and usernames can be under one logical device name.
To set up logical devices, follow these steps:
Step 1 Select Configuration > Logical Devices.
The Logical Device Configuration page appears.
Step 2 Click Add to add the logical devices that the sensor will manage.
The Adding page appears.
Step 3 In the Name field, enter the name of the logical device.
Step 4 In the Enable Password field, enter the enable password for the logical device (1 to 16 characters).
Note If there is no enable password, enter none.
Step 5 In the Password field, enter the Telnet or SSH password for the logical device (1 to 16 characters).
Note If there is no password, enter none.
Step 6 In the Username field, enter the username for the logical device.
Note If there is no username, enter none.
Note To reset the form, click Reset.
Step 7 Click Apply to Sensor to save your changes.
Configuring Blocking Devices
You can configure your sensor to block an attack by generating ACL rules for publication to a Cisco IOS router, or a Catalyst 6500 switch, or by generating shun rules on a PIX Firewall. The router, switch, or firewall is called a blocking device.
To configure blocking devices, follow these steps:
Step 1 Select Configuration > Blocking Devices.
The Blocking Devices page appears.
Caution A single sensor can manage multiple devices, but multiple sensors cannot be used to control a single device. In this case, use a master blocking sensor. See
Configuring a Master Blocking Sensor, for more information.
Step 2 Click Add to add a blocking device.
The Adding page appears.
Step 3 In the IP Address field, enter the IP address of the blocking device.
Step 4 In the NAT Address field, enter the NAT address of the blocking sensor.
Step 5 Select an option from the Apply Logical Device list box.
Note The same logical device can be used for multiple blocking devices. You must have a logical device set up. The default option None indicates that you do not have a logical device set up. See Setting Up Logical Devices, for more information.
Step 6 From the Device Type field, select the type of device that will do the blocking:
•Cisco Router
•Catalyst 6000 VACL
•PIX Firewall
Step 7 From the Communication field, select the type of secure communications you want to enable between the sensor and the blocking device:
•SSH 3DES
•SSH DES
•Telnet
Note If you select SSH 3DES or SSH DES, go to Step 8.
Step 8 If you select SSH 3DES or SSH DES, you must add the host to the known hosts list:
Note If you select SSH 3DES or SSH DES, the blocking device must have a feature set or license that supports the desired DES/3DES encryption.
a. Telnet to your sensor and log in to the CLI.
Note You must have administrator privileges.
b. Enter configure terminal mode:
sensor# configure terminal
c. Obtain the public key:
sensor(config)# ssh host-key blocking_device_ip_address
You are prompted to confirm adding the public key to the known hosts list:
Would you like to add this to the trusted certificate table for this host?[yes]:
d. Enter yes.
e. Exit configuration terminal mode:
f. Exit the CLI:
Step 9 Click Apply to Sensor to save your changes.
Configuring Router Blocking Device Interfaces
You must configure the blocking interfaces on the router in the IDS Device Manager and specify the direction of traffic you want blocked.
You create and save Pre-Block and Post-Block ACLs in your router configuration. These ACLs must be extended IP ACLs, either named or numbered. See your router documentation for more information on creating ACLs.
Enter the names of these ACLs that are already configured on your router in the Pre-Block ACL Name and Post-Block ACL Name fields.
The Pre-Block ACL is mainly used for permitting what you do not want the sensor to ever block. When a packet is checked against the ACL, the first line that gets matched determines the action. If the first line matched is a permit line from the Pre-Block ACL, the packet is permitted even though there may be a deny line (from an automatic block) listed later in the ACL. The Pre-Block ACL can override the deny lines resulting from the blocks.
The Post-Block ACL is best used for additional blocking or permitting that you want to occur on the same interface or direction. If you have an existing ACL on the interface or direction that the sensor will manage, that existing ACL can be used as a Post-Block ACL. If you do not have a Post-Block ACL, the sensor inserts a permit ip any any at the end of the new ACL.
When the sensor starts up, it reads the contents of the two ACLs. It creates a third ACL with the following entries:
•A permit line for the sensor's IP address.
•Copies of all configuration lines of the Pre-Block ACL.
•A deny line for each address being blocked by the sensor.
•Copies of all of the configuration lines of the Post-Block ACL.
The sensor applies the new ACL to the interface and direction that you designate.
Note When the new ACL is applied to an interface or direction of the router, it removes the application of any other ACL to that interface or direction.
To configure the blocking interfaces on a router, follow these steps:
Step 1 Select Configuration > Router Blocking Device Interfaces.
The Router Blocking Device Interfaces page appears.
Step 2 Click Add to configure the blocking interfaces on the router.
The Adding page appears.
Step 3 From the IP Address field, select the IP address of the router that will be used to block.
Step 4 In the Blocking Interface field, enter the interface on the router that will be used for blocking (1 to 32 characters).
Step 5 From the Blocking Direction list box, select the direction of traffic through the interface that should be blocked (In, Out).
Step 6 In the Pre-Block ACL Name field, enter the name of the Pre-Block ACL (1 to 64 characters).
Step 7 In the Post-Block ACL Name field, enter the name of the Post-Block ACL (1 to 64 characters).
Note To reset the form, click Reset.
Step 8 Click Apply to Sensor to save your changes.
Configuring Catalyst 6K Blocking Device Interfaces
You must configure the blocking interfaces on the Catalyst switch and specify the VLAN interface for blocking.
To configure the blocking interfaces on a Catalyst switch, follow these steps:
Step 1 Select Configuration > CAT 6K Blocking Device Interfaces.
The CAT 6K Blocking Device Interfaces page appears.
Step 2 Click Add to configure the blocking interfaces on the router.
The Adding page appears.
Step 3 From the IP Address field, select the IP address of the Catalyst switch that will be used to block.
Step 4 In the VLAN field, enter the VLAN number that the sensor will configure for blocking.
Step 5 In the Pre-Block VACL Name field, enter the name of the Pre-Block VACL (1 to 64 characters).
Step 6 In the Post-Block VACL Name field, enter the name of the Post-Block VACL (1 to 64 characters).
Note To reset the form, click Reset.
Step 7 Click Apply to Sensor to save your changes.
Configuring a Master Blocking Sensor
Multiple sensors (blocking forwarding sensors) can forward blocking requests to a specified master blocking sensor, which controls one or more devices. On the blocking forwarding sensor, use Configuration > Blocking > Master Blocking Sensor to identify which remote host serves as the master blocking sensor; on the master blocking sensor you must add the blocking forwarding sensors to its allowed host configuration.
Note Typically the master blocking sensor is configured to manage the network devices. Blocking forwarding sensors are not normally configured to manage network devices, although doing so is permissible.
To set up blocking forwarding sensors and a master blocking sensor, follow these steps:
Step 1 Open up another browser to connect to the master blocking sensor:
https://master_blocking_sensor_ip_address
Step 2 Select Device > Sensor Setup > Allowed Hosts.
The Allowed Hosts page appears.
Step 3 Click Add to add the IP address and netmask of the blocking forwarding sensor(s).
The Adding page appears.
Step 4 In the IP Address field, enter the IP address of the blocking forwarding sensor.
Step 5 In the Netmask field, enter the netmask of the blocking forwarding sensor.
Note To reset the form, click Reset.
Step 6 Click Apply to Sensor to save your changes.
Step 7 Repeat Steps 2 through 6 for each sensor you want to allow as a blocking forwarding sensor.
Step 8 Open up another browser to connect to the blocking forwarding sensor:
https://blocking_forwarding_sensor_ip_address
Step 9 Select Configuration > Blocking > Master Blocking Sensor.
The Master Blocking Sensor page appears.
Step 10 Click Add to add a master blocking sensor.
The Adding page appears.
Step 11 In the IP Address field, enter the IP address of the master blocking sensor.
Step 12 Enter the port number that the master blocking sensor is using.
The port number is the same port number that the master blocking sensor is using for IDS Device Manager connections.
Note For example, if you are connecting using https, it is port 443 by default.
Step 13 In the User Name field, enter your IDS Device Manager administrator username.
Step 14 In the Password field, enter your IDS Device Manager administrator password.
Note To reset the form, click Reset.
Step 15 If you select Use TLS, follow these steps:
a. Access the blocking forwarding sensor's CLI.
Note You must have administrator privileges.
b. Enter configuration mode:
sensor# configure terminal
c. Add the trusted host:
sensor(config)# tls trusted-host ip-address master-blocking_sensor_ip_address
You are prompted to confirm adding the trusted host:
Would you like to add this to the trusted certificate table for this host?[yes]:
d. Enter yes.
e. Exit configuration terminal mode:
f. Exit the CLI:
Step 16 Click Apply to Sensor to save your changes.
The Master Blocking Sensor page appears showing your entry:
Step 17 Repeat Steps 8 through 16 for each sensor you want to identify as a master blocking sensor.
Step 18 To edit an entry, select the check box next to the entry you want to edit and click Edit.
The Editing page appears.
Step 19 Make your changes and click Apply to Sensor.
Configuring Automatic Updates
You can schedule automatic updates of IDS service packs and signature updates.
•Configuring Automatic Updates
•Supported FTP Servers
•Obtaining Cisco IDS Software
•Applying for a Cisco.com Account with Cryptographic Access
•Active Update Notification
•Network Security Database
Configuring Automatic Updates
You can configure automatic service pack and signature updates, so that when service pack and signature updates are loaded on a central FTP or SCP server, they are downloaded and applied to your sensor. The timeout default is 5 minutes.
Note The sensor cannot automatically download service pack and signature updates from Cisco.com. You must download the service pack and signature updates from Cisco.com to your FTP or SCP server, and then configure the sensor to download them from the FTP or SCP server. See Obtaining Cisco IDS Software, for the procedure for obtaining service packs and signature updates.
Caution After you download an update from Cisco.com, you must take steps to ensure the integrity of the downloaded file while it resides on your FTP or SCP server.
See Supported FTP Servers, for a list of supported servers.
To configure automatic updates, follow these steps:
Step 1 Select Configuration > Auto Update.
The Auto Update page appears.
Step 2 Select the Enable Auto Update check box to enable automatic updates.
Step 3 In the IP Address field, enter the IP address of the server to poll for updates.
Step 4 In the Directory field, enter the path to the directory on the server where the updates are located (1 to 128 characters).
Step 5 In the Username field, enter the username to use when logging in to the server (1 to 16 characters).
Step 6 In the Password field, enter the username password on the server (1 to 16 characters).
Step 7 In the File Copy Protocol list box, select either SCP or FTP.
Step 8 For hourly updates, select Hourly, and follow these steps:
a. In the Start Time field, enter the time you want the updates to start (hh:mm:ss).
b. In the Frequency field, enter the hour interval at which you want every update to occur (1 to 8760).
For example, if you enter 5, every 5 hours the sensor looks at the directory of files on the server. If there is an available update candidate, it is downloaded and installed. Only one update is installed per cycle even if there are multiple available candidates.
Step 9 For calendar updates, select Calendar, and follow these steps:
a. In the Start Time field, enter the time you want the updates to start (hh:mm:ss).
b. In the Day field, select the day(s) you want to download updates.
Note To reset the form, click Reset.
Step 10 Click Apply to Sensor to save your changes.
Supported FTP Servers
The following FTP servers are supported for service pack and signature updates:
•Sambar FTP Server Version 5.0 (win32).
•Web-mail Microsoft FTP Service Version 5.0 (win32).
•Serv-U FTP-Server v2.5h for WinSock (win32).
•Solaris 2.8.
•HP-UX (HP-UX qdir-5 B.10.20 A 9000/715).
•Windows 2000 (Microsoft ftp server version 5.0).
•Windows NT 4.0 (Microsoft ftp server version 3.0).
Note The sensor cannot download service pack and signature updates from Cisco.com. You must download the service pack and signature updates from Cisco.com to your FTP server, and then configure the sensor to download them from your FTP server.
Obtaining Cisco IDS Software
You can find IDS Event Viewer, signature updates, service pack updates, BIOS upgrades, Readmes, and other software updates on the Software Center on Cisco.com at the following URL: http://www.cisco.com/kobayashi/sw-center/ciscosecure/ids/crypto/
Note You must be logged in to Cisco.com to access the Software Center.
Periodic signature updates, which also contain Network Security Database (NSDB) updates, are posted to Cisco.com approximately every two weeks. Service packs are posted to Cisco.com as needed.
You need a Cisco.com password to download updates. See the Applying for a Cisco.com Account with Cryptographic Access, for information on obtaining a Cisco.com account with cryptographic access.
Check Cisco.com regularly for the most recent signature and service pack updates.
To access Software Center on Cisco.com, follow these steps:
Step 1 Go to Cisco.com.
Step 2 Log in to Cisco.com.
Step 3 Select Technical Support > Software Center.
Step 4 Under Software Products & Downloads, click Cisco Secure Software.
Step 5 Under Cisco Secure Software, click Cisco Intrusion Detection System (IDS).
Step 6 Under Version 4.X, locate your sensor, and then click Latest Software.
Step 7 On the Software Download page, select the update you need.
Step 8 Follow the instructions in the Readme to install the update.
If for some reason the sensor is unusable after installing a signature update or service pack, see Recovering the Sensor Software Image in the Cisco Intrusion Detection System Appliance and Module Installation and Configuration Guide Version 4.1 for more information.
Note Major version upgrades, minor version upgrades, service packs, and signature updates are the same for all sensors. Recovery and application files are unique per platform.
Applying for a Cisco.com Account with Cryptographic Access
To download software updates, you must have a Cisco.com account with cryptographic access.
To apply for cryptographic access, follow these steps:
Step 1 If you have a Cisco.com account, skip to Step 2. If you do not have a Cisco.com account, register for one by going to the following URL: http://tools.cisco.com/RPF/register/register.do
Step 2 Go to the following URL: http://www.cisco.com/pcgi-bin/Software/Crypto/crypto_main.pl
The Enter Network Password dialog box appears.
Step 3 Log in with your Cisco.com account.
The Encryption Software Export Distribution Authorization Form page appears.
Step 4 Select your software from the list box and click Submit.
The Encryption Software Export Distribution Authorization Form appears.
Step 5 Review and complete the Encryption Software Export Distribution Authorization form and click Submit.
The "Cisco Encryption Software: Crypto Access Granted" message appears.
Note It takes approximately 4 hours to process your application. You cannot download the software until the entitlement process is complete. You will not receive notification.
Active Update Notification
You can subscribe to Cisco IDS Active Update Notifications on Cisco.com to receive e-mails when signature updates and service pack updates occur.
To receive notification about signature updates, follow these steps:
Step 1 Go to the following URL: http://www.cisco.com/warp/public/779/largeent/it/ids_news/subscribe.html
Step 2 Enter your e-mail address in the E-mail Address field.
Step 3 Enter your password in the Password box.
Step 4 Retype your password in the Password box.
Step 5 Click Submit.
You will receive e-mail notifications of signature updates when they occur and instructions on how to obtain them.
Network Security Database
The Network Security Database (NSDB) is Cisco's HTML-based encyclopedia of network vulnerability information. You can access the NSDB by clicking NSDB in the upper right bar of IDS Device Manager.
You can also access the page for a particular signature by selecting Configuration > Sensing Engine > Virtual Sensor Configuration > Signature Configuration Mode >All Signatures and then clicking on the ID number of the signature.
A typical NSDB entry contains the following critical security information:
•Signature Name—Specifies the name of the signature, which appears at the top of the entry.
•ID—Specifies the unique ID for the signature.
•Sub ID—Specifies the optional subsignature ID for the signature.
•Recommended Alarm Level—Specifies the alarm level that we recommend you set for that signature.
•Signature Type—Indicates what the signature type affects. There are two types:
–Network—Categorizes a vulnerability as being network-based.
–Host—Categorizes a vulnerability as being host-based.
•Signature Structure—Defines how many packets it takes for the sensor to positively identify an alarm condition on the network. There are two types:
–Atomic signature—Requires only one packet to be inspected to identify an alarm condition.
–Composite signature—Requires multiple packets to be inspected to identify an alarm condition.
•Implementation—Shows that this signature examines the packet headers to identify an alarm condition. There are two implementation types:
–Content-based signature—Examines the payload and headers of a packet to identify an alarm condition.
–Context-based signature—Evaluates the packet headers to identify an alarm condition.
•Release Version—Indicates in which release this signature originated.
•Description—Explains the signature and what exploits it detects.
•Benign Trigger(s)—Explains any "false positives" that may appear to be an exploit but are actually normal network activity.
•Recommended Signature Filter—Provides any filter that you should use.
•Data Field Information Tag—Provides a bit of the information used to create a signature, such as an example URL.
•Related Vulnerabilities—Indicates that each signature can have zero or more related vulnerabilities. Each vulnerability information page provides background on the vulnerability and a link to any available countermeasures.
•User Notes—Specifies the user-defined notes page in which you can fill in security information customized to your network security environment.
Restoring Default Settings
You can restore the default configuration to your sensor.
Warning Clicking Apply to Sensor removes the current application settings and restores the default settings. Your network settings also return to the defaults and you immediately lose connection to IDS Device Manager and the CLI.
To restore the default configuration, follow these steps:
Step 1 Select Device > Configuration > Restore Defaults.
The Restore Defaults page appears.
Step 2 Click Apply to Sensor to restore the default configuration.
The IP address, netmask, default gateway, allowed hosts, password, and time will not be reset. Manual and automatic blocks also remain in effect.
Feedback
