[ LiB ] |
The service command gives you access to one of many different Level 3 items in the CLI. Services are like separate programs that you can tune and configure. For example, the service WebServer command takes you to a level 3 mode that allows configurations to the WebServer on the IDS sensor. Listing 7.7 displays the different services you can configure in services mode.
sensor# config t sensor(config)# service ? alarm-channel-configuration Enter configuration mode for the alarm channel Authentication Enter configuration mode for user authentication options Host Enter configuration mode for node configuration Logger Enter configuration mode for debug logger NetworkAccess Enter configuration mode for the network access controller SshKnownHosts Enter configuration mode for configuring SSH known hosts TrustedCertificates Enter configuration mode for configuring trusted certificates virtual-sensor-configuration Enter configuration mode for the virtual sensor WebServer Enter configuration mode for the web server application
The services host configuration mode locates you in a Level 3 portion of the CLI that allows administrators to configure general host parameters such as those listed in Table 7.3. The networkParams is one of the primary services you need to configure for any basic sensor configuration, so make sure that you know your way around this level.
Options | Description and Options |
---|---|
timeParams | Configures time settings such as time zones. |
optionalAutoUpgrade | Sets the IP address, password, and directory where automatic updates can be found; schedules the IDS uses to download those upgrades. |
networkParams | Configures several sensor networking settings, such as the following: ipAddress Sets the IP address of the command and control interface. defaultGateway Sets the IP address of the command and control console. telnetOption Enables and disables the Telnet server on the sensor. hostname Sets the sensor's hostname. accessList Sets the IP address of the trusted host allowed to Telnet or SSH into the sensor. Most of networkParams settings are applied to the command and control interface. |
Table 7.4 displays the services host prompts that appear for each associated command.
Command | Location and Prompt |
---|---|
service host | sensor(config-Host)# |
networkParams | sensor(config-Host-net)# |
optionalAutoUpgrade | sensor(config-Host-opt)# |
timeParams | sensor(config-Host-tim)# |
Listing 7.8 demonstrates using the services host networkParams mode to configure the sensor's IP address, subnet mask, and default gateway.
sensor# config t sensor(config)# service host sensor(config-Host)# networkParams sensor(config-Host-net)# ipaddress 172.31.8.69 sensor(config-Host-net)# netmask 255.255.255.0 sensor(config-Host-net)# defaultGateway 172.31.8.254
Listing 7.9 demonstrates using the services host networkParams mode to enable Telnet with the TelnetOption command, adding the 172.31.8.70 host to the access list. The listing also displays the removal of the 10.0.0.0 network from the same access list. Note, the access list is a list of trusted hosts and/or networks allowed access to the sensor via Telnet or SSH.
sensor# config t sensor(config)# service host sensor(config-Host)# networkParams sensor(config-Host-net)# TelnetOption enable sensor(config-Host-net)# accessList ipaddress 172.31.8.70 netmask 255.255.255.255 sensor(config-Host-net)# no accesslist ipaddress 10.0.0.0 netmask 255.0.0.0
Listing 7.10 uses the show settings command at the services host networkParams mode to display current settings. The listing also demonstrates using the exit command to save and pply changes to the sensor.
sensor(config-Host-net)# show settings networkParams ----------------------------------------------- ipAddress: 172.31.8.69 netmask: 255.255.255.0 default: 255.255.255.0 defaultGateway: 172.31.8.254 hostname: sensor telnetOption: enabled default: disabled accessList (min: 0, max: 512, current: 2) ----------------------------------------------- ipAddress: 172.31.8.70 netmask: 255.255.255.255 default: 255.255.255.255 ----------------------------------------------- ----------------------------------------------- ----------------------------------------------- sensor(config-Host-net)# exit sensor(config-Host)# exit Apply Changes:?[yes]: yes
When at the networkParams prompt of sensor(config-Host-net)# , to save any settings that you have changed, just type the command exit and answer yes to the "apply changes" question. |
You can use the accessList command to create trusted host lists for both Telnet and SSH hosts. |
The alarm-channel-configuration feature is a configurable grouping of eventFilters. You use eventFilters to prevent alarms from being generated by specific hosts or signature combinations throughout your network.
For example, if you have an IP address (source) that's triggering false alarms, you can create an eventFilter to block logging of those alarms. The next time the eventFilter match is made, no alarms or alerts are generated. An administrator might use the eventFilter this way when he or she needs to run a ping sweep tool but doesn't want the sensor to record alarms when the sensor detects the sweeping of the network. You can define the following in an eventFilter:
Source IP address
Destination IP address
Signature ID
Subsignature ID
Exception
You use eventFilters to block the logging of alarms, not the alarms themselves . In addition, eventFilters do not improve performance because the alarms are still detected , just not logged. |
EventFilters can also use predefined systemVariables . They allow you to enter values into variables ; for example, you can use systemVariables to enter an IP address into a variable called USER-ADDRS1 . When creating an eventFilter, instead of hardcoding the IP address, you can just use the variable named USER-ADDRS1 .
Chapter 5, "Cisco IDS Architecture and Communications Protocols," discusses more on virtual alarm channels, including the default virtualAlarm. |
Cisco has announced that future releases of its IDS software will enable the administrator to create multiple virtual alarm channels; each of these channels can host its own list of specific eventFilters.
The virtual alarm channels are then attached to an interface group. When the sensing interfaces within that group have alarms that match eventFilters, nothing is recorded. However, at the moment, Cisco supports only a single alarm channel called virtualAlarm , and it is the only alarm channel for which you can create eventFilters. The virtualAlarm also is the only alarm channel that you can use by interface group 0.
The next several listings display the syntax to configure a systemVariable and use it inside an eventFilter.
Listing 7.11 displays how to navigate to the virtual alarm channel called virtualAlarm and uses the help command to display the possible commands that you can use at this mode.
sensor# config t sensor(config)# service alarm-channel-configuration virtualAlarm sensor(config-acc)# tune-alarm-channel sensor(config-acc-virtualAlarm)# ? EventFilter Configuration for the Event Filters. exit Exit service configuration mode show Display system settings and/or history information systemVariables User modifiable system variables
Listing 7.12 displays how to navigate to the systemVariables mode and configure USER-ADDRS1 with two IP addresses.
sensor(config-acc-virtualAlarm)# systemVariables sensor(config-acc-virtualAlarm-sys)# USER-ADDRS1 172.31.8.70,172.31.8.71 sensor(config-acc-virtualAlarm-sys)# exit
Listing 7.13 displays how to use the systemVariable USER-ADDRS1 inside an eventFilter. In addition, notice the variable name must start with a $ sign. This sign tells the filter command to expect a systemVariable.
sensor(config-acc-virtualAlarm)# eventFilter sensor(config-acc-virtualAlarm-Eve)# filter SourceAddrs $USER-ADDRS1 sensor(config-acc-virtualAlarm-Eve)# exit
Listing 7.14 uses the show settings command to display current variable settings and then exits the mode to save the changes.
sensor(config-acc-virtualAlarm)# show settings systemVariables ----------------------------------------------- OUT: 0-255.255.255.255 <protected> IN: DMZ1: DMZ2: DMZ3: USER-ADDRS1: 172.31.8.70,172.31.8.71 USER-ADDRS2: USER-ADDRS3: USER-ADDRS4: USER-ADDRS5: SIG1: SIG2: SIG3: SIG4: SIG5: ----------------------------------------------- EventFilter ----------------------------------------------- version: 4.0 <protected> Filters (min: 0, max: 5000, current: 1) ----------------------------------------------- DestAddrs: * <defaulted> Exception: False <defaulted> SIGID: * <defaulted> SourceAddrs: $USER-ADDRS1 default: * SubSig: * <defaulted> ----------------------------------------------- ----------------------------------------------- ----------------------------------------------- sensor(config-acc-virtualAlarm)# exit Apply Changes:?[yes]: yes
Cisco IDS version 4.0 software currently only supports a single virtualAlarm called virtualAlarm. |
The virtual-sensor-configuration level allows you to fine-tune signature settings or even create custom signatures. This level also allows you to reset all signatures back to default settings. Listing 7.15 displays resetting the signature engine String.TCP back to its default settings. If you need to actually tune individual values in signatures, we recommend using one of the Web interface options such as IDM or IDS MC.
sensor# config t sensor(config)# service virtual-sensor-configuration virtualSensor sensor(config-vsc)# ? end Exit configuration mode and return to exec mode exit Exit configuration mode and return to global configuration mode reset-signatures Reset signatures settings back to the default configuration show Display system settings and/or history information tune-micro-engines Enter micro-engine tuning mode sensor(config-vsc)# reset-signature STRING.TCP all Warning: Executing this command will reset all specified signatures back to default. Continue with reset-signatures? [yes]: yes Processing config: \
As with the alarm channel, the current IDS software supports only one virtual sensor called virtualSensor. All signature tuning and custom signatures created are linked to this virtualSensor group. This grouping is then attached to the interface group 0. Look in later releases for the ability to create multiple virtual sensors.
The NetworkAccess service lets you configure managed devices. For example, if you want to manage a PIX Firewall from the sensor, then you must be located at the NetworkAccess level. This level allows you to define the managed device and to determine how communication is established (through Telnet or SSH). Note that managed devices receive access control list (ACL) or shun commands from the IDS sensor to assist in blocking hosts or network connections. Listing 7.16 displays some of the available commands of the NetworkAccess levels by using the ? help command.
sensor# config t sensor(config)# service NetworkAccess sensor(config-NetworkAccess)# ? cat6k-devices Settings for CAT 6K routers controlled by NAC. exit Exit service configuration mode general General NAC Configuration. no Remove an entry or selection setting pix-devices Settings for the PIX firewalls controlled by NAC router-devices Settings for routers controlled by NAC. show Display system settings and/or history information shun-device-cfg Settings for device access. sensor(config-NetworkAccess)# general sensor(config-NetworkAccess-gen)# ? allow-sensor-shun Flag indicating if CIDS IP can be blocked. default Set the value back to the system default setting enable-acl-logging Flag indicating if ACL logging should be enabled. exit Exit general configuration submode master-blocking-sensors List containing sensors for forwarding blocks. never-shun-hosts List specifying never block host parameters. never-shun-networks List specifying never block network parameters no Remove an entry or selection setting show Display system settings and/or history information shun-enable Flag indicating if blocking should be enabled shun-hosts List specifying blocked hosts. shun-max-entries Maximum number of active blocks. shun-networks List specifying blocked networks.
Managed devices need to have several items set up to allow the sensor to control them. You should know the following list of items needed on the managed device to allow a sensor to Telnet to it:
|
Although Cisco suggests making the VTY line and enable passwords the same, it is not recommended you do so in secure configurations. However, for the test, we suggest following Cisco's recommendation of making them the same. |
The WebServer service location allows configuration of the Hypertext Transfer Protocol/Secure HTTP (HTTP/HTTPS) cidwebServer application.
You use it to host the IDM Web pages and provide communication with other applications such as IEV and the Security Monitor tools that use HTTPS to encrypt the Remote Data Exchange Protocol (RDEP) data that they are pulling. Listing 7.17 displays the different commands the sensor offers.
sensor# config t sensor(config)# service webServer sensor(config-WebServer)# ? exit Exit service configuration mode general General cidwebserver configuration show Display system settings and/or history information sensor(config-WebServer)# general sensor(config-WebServer-gen)# ? default Set the value back to the system default setting enable-tls Determines whether encryption (TLSv1 and SSLv3) is enabled exit Exit general configuration submode ports List of the ports on which the web server listens for connections server-id The value the web server returns in the HTTP Server header show Display system settings and/or history information sensor(config-WebServer-gen)#
The default WebServer port is 443, which is a standard for most Secure Socket Layer/ Transport Layer Security (SSL/TLS) communications and the enable-tls setting defaults to true . Clients need to use SSL or TLS to connect via HTTP. |
If you are not using any monitoring programs, it is advisable to leave the HTTP/HTTPS WebServer disabled. |
[ LiB ] |