All Cisco-Network Study Notes: Initializing the Sensor

Initializing the Sensor

Initializing the sensor is where the rubber meets the road, so to speak. Besides physically installing the sensor into a rack and cabling, this is the basic process for getting your sensor up and running. Two accounts are created by default when the sensor software is installed: root and netrangr. These should be the only accounts needed to log in to the sensor and perform administrative tasks. In fact, certain commands can only be performed as root or netrangr, so it's best to become familiar with them.

Listed next are several ways to gain management access of the sensor:

Console Port This requires a RS232 cable and a program such as Hyperterm or Teraterm.
Monitor and keyboard This requires connecting a monitor and keyboard directly to the sensor.
Telnet This requires an IP address to be configured to the command and control interface.
Secure Shell (SSH) This also requires an IP address and an SSH client application.
Cisco IDS Device Manager (IDM) This requires an IP address and uses a Web browser.
Cisco Secure Policy Manger (CSPM) An IP address is required along with a mail server for the PostOffice protocol to communicate with.
Cisco IDS Director for Unix The Director requires HP OpenView and runs on an HP or Solaris platform.

The easiest way to initialize the sensor for the first time is either through a directly connected keyboard and monitor, or by using the COM port connected to a workstation via a null-modem cable.

There are several ways to connect to the IDS sensor: Telnet to the sensor, connect a keyboard and monitor directly to the sensor, or connect a workstation to the sensor utilizing the COM ports. Some functions—such as Updating signatures, troubleshooting, and even running the sysconfig-sensor utility—cannot be performed via a management application and thus require you to log in directly..

In order to connect, you will need a null-modem cable with DB-9 female connectors on both ends. If you have a sensor right out of the box, a cable should accompany the sensor. In the event it is not provided, you can either purchase one or make it yourself. (The pinout for this cable is shown in Figure 3.3.) Connect the cable to the COM port of the IDS sensor and to the workstation using the COM 1 port. The COM port settings on the workstation should look like those in Figure 3.4.

Figure 3.3: Null Modem Pinout Chart

Figure 3.4: Com Port Settings

Using your communications software, attempt to call the sensor. If you are successful, log in as netrangr and su to root if needed.

What Is the root User?

The user root on the sensor is used strictly for configuration of the operating system. It is not used for daily administrative tasks. The main function root is used for is sysconfig-sensor, explained in detail later in this chapter. The root account is used for the following tasks:

Bootstrapping the sensor by executing the sysconfig-sensor command
For certain system level commands, such as snoop
When installing signature updates or service packs
When starting or stopping the IDM web services

The snoop command is a handy one to remember since you can use it to verify that the sensor can see the traffic you are interested in. snoop captures packets from the network and displays their contents to the screen. It can be saved to a file if needed. If snoop cannot see the traffic, neither can the IDS sensor monitor interface. snoop examines the raw traffic on your network and can be executed to look at any interface.

For example:

# snoop -d spwr0 port 45000
 
Using device /dev/spwr (promiscuous mode)
 
 10.0.0.8 -> 10.0.0.4 UDP D=45000 S=45000 LEN=52
 
 10.0.0.8 -> 10.0.0.4 UDP D=45000 S=45000 LEN=52
 
 10.0.0.8 -> 10.0.0.4 UDP D=45000 S=45000 LEN=52
 
 10.0.0.8 -> 10.0.0.4 UDP D=45000 S=45000 LEN=52

The preceding output is an example of the sensor 10.0.0.8 sending packets on UPD 45000, but no packets are received. If the two devices were communicating properly, the snoop output would look like the following:

# snoop -d spwr0 port 45000
 
Using device /dev/iprb (promiscuous mode)
 
10.0.0.4 -> sensor1         UDP D=45000 S=45000 LEN=56
 
       sensor1 -> 10.0.0.4 UDP D=45000 S=45000 LEN=56
 
172.18.124.142 -> sensor1         UDP D=45000 S=45000 LEN=56
 
       sensor1 -> 172.18.124.194 UDP D=45000 S=45000 LEN=56

Notice traffic is flowing on UDP 45000 in both directions.

Note

If both sides are sending and receiving UDP 45000 packets and the output of the command idsconns says that a connection has not been established, go back and troubleshoot the postoffice parameters on the sensor and the management device.

The architecture is set up in a way that certain commands work specifically with root but not for user netrangr. root is used to initialize the sensor and make configuration changes as needed down the road. Even when telneting into the sensor, netrangr is used and the user must su to root in order to perform root tasks for configuration, or to modify a setting or permission in the Unix architecture.

What Is the netrangr User?

To perform administrative of IDS-level functions on the sensor, you will need to log in as netrangr. All the commands discussed later in this chapter are executed using this account, with the exception of sysconfig-sensor. They include idsstatus, idsvers, idsstop, idsstart, and cidServer.

Note

An important item to remember with all the Cisco IDS operating systems is that the user IDs of root and netrangr both have a default password of attack. The first login into the system forces you to change the password.

What Is sysconfig-sensor?

Once you have logged into the sensor as root and changed the password, sysconfig-sensor is the next command performed in order to configure the sensor. This is commonly known as bootstrapping the sensor.

Note

Passwords are case-sensitive and can be up to eight characters in length. Any password longer than eight characters is truncated.

Configuring the Sensor

Configuring the sensor is a fundamental step in deploying an IDS infrastructure. The first step in configuring the sensor is running the sysconfig-sensor command and going through each option, filling in the required information along the way. Any of the options that pertain to addressing—options 1–5—will require a reboot if modified.

Execute the command sysconfig-sensor. The configuration utility menu is shown in Figure 3.5

Figure 3.5: sysconfig-sensor
Select option 1, IP Address. Figure 3.6 shows the screen for entering the sensor's IP address. The sensor comes out of the box with a default IP address of 10.1.9.201. Change this address to reflect your network. Remember the address! You will be prompted to write the information. Check your entry and select yes or no.

Figure 3.6: The IP Address

Note
Options 1–6 must be configured for the sensor to communicate properly.
Select option 2, IP Netmask. For option 2 of the sysconfig-sensor menu, you must enter the subnet mask of your network, as shown in Figure 3.7. The subnet mask defines boundaries that can vary depending on the extent of the subnetting being implemented. If it is entered incorrectly, the sensor may not communicate properly with the management host or the rest of the network. Check with the network engineers in your organization.

Figure 3.7: The IP Netmask
Select option 3, IP Host Name. The default host name for the sensor is sensor, shown in Figure 3.8. Add a unique name for your sensor here. It would be wise to enter a name that can easily be identified on the network. The example shows sensor1. If you add other sensors, increment the number to reflect the number of sensors on the network.

Figure 3.8: The IP Host Name

Note
The IP Host Name of the sensor can be up to 256 alphanumeric characters in length with no spaces. "-" and "_" are valid special characters, and case is important.
Select option 4, Default Route. The default route tells the sensor what path to take to reach other hosts in the IDS infrastructure. This setting is usually a router or a firewall interface. Enter the default route for your network, as shown in Figure 3.9. Again, check with your network engineers to verify your route.

Figure 3.9: The Default Route
Select option 5, Access Control List. The Access Control List (ACL) is imperative if you are not able to physically access the sensor. Figure 3.10 shows a default access list of the entire 10. network. Enter a network address or the individual IP addresses of hosts that should have access to the sensor. The ACL works via a standard TCP wrapper application. The TCP connection is automatically closed if a host attempts to log in to the sensor without the host's IP in the ACL.

Figure 3.10: The Access Control List

Note
Cisco's best practices tell us that we should be as specific as possible and only enter the IP addresses that will be able to connect to the sensor.

Select option 6, Communications Infrastructure. The configurations in option 6 (shown in Figure 3.11) are critical for proper communication between the sensor and IDS Manager. Make sure to verify each setting and document them. Table 3.1 shows the values for each field. Several of the settings have already been configured in previous steps. Those settings are in brackets and can be kept by pressing Enter during that specific configuration step.

Figure 3.11: Communications Infrastructure

Table 3.1: Communications Infrastructure Values
Field	Input
Sensor Host ID	1–65535
Sensor Organization ID	1–65535
Sensor Host Name	256 alphanumeric characters; no spaces; "-" and "_" are okay
Sensor Organization Name	256 alphanumeric characters; no spaces; "-" and "_" are okay
Sensor IP Address	Valid IP address
IDS Manager Host ID	1–65535
IDS Manager Organization ID	1–65535
IDS Manager Host Name	256 alphanumeric characters; no spaces; "-" and "_" are okay
IDS Manager Organization Name	256 alphanumeric characters; no spaces; "-" and "_" are okay
IDS Manager IP Address	Valid IP address

The sensor host ID and the IDS manager host ID must be unique, as well as all subsequent sensors and devices added to the IDS infrastructure. This number can be any number between 1 and 65535. The organization ID should be the same for all devices in the infrastructure. This organization ID is used to group sensors and management devices together and can be between 1 and 65535. The organization name should also be the same for all devices. This is typically the location where you work, or where it is installed. Once all settings have been made, the sensor will prompt you to create the configuration file.

Cisco says you should use only lowercase letters to define organization names. The host and organization name are case-sensitive with regards to how postoffice processes audit events on the local host. Host and organization names are not passed between different postoffice clients, only the host and organization IDs. The /usr/nr/etc/hosts file is where this information is listed for the Cisco IDS infrastructure. The syntax is as follows:

[host ID]. [organization ID] [host name].[organization name]
 
8.100 localhost
8.100 sensor1.security
4.100 ids-mgr.security

The preceding sample is what the hosts file entries look like on the sensor. Notice there are two entries for the sensor itself: localhost and sensor1.security.

You now need to write the configuration. Verify all of the settings on the screen (shown in Figure 3.12) and type y to accept the settings. If any of the settings are incorrect, type n to discard the settings and repeat the configuration steps. A message is displayed once all the configuration files have been written to successfully. Once the configuration files have been written, you should get the message, shown in Figure 3.13, telling you that all configuration files were written successfully.

Figure 3.12: sysconfig-sensor Settings

Figure 3.13: The sysconfig-sensor Success Message
You now need to set the date, time, and time zone for your organization. Use the Date/Time and Time Zone section, shown in Figure 3.14, to synchronize the sensor with the rest of the network. You have the option of entering a specific date, time, and time zone, or, entering a host to synchronize with, such as a time server on the network.

Figure 3.14: Date/Time and Time Zone
You can now change/set your passwords as needed. Use the Passwords option, shown in Figure 3.15, to change the root or netrangr passwords. Once the password has been changed the old password is not saved on the system anywhere. It is important to remember the new passwords.

Figure 3.15: The Passwords

You now need to configure your Secure Communications. The secure communications menu shown in Figure 3.16 is used to define configuration settings for encrypted communications between the sensor and the IDS Management device. Before we get into configuring the secure communication, it is important to remember IPSec is used mainly for connection to CSPM or the Director, and not the IDS Event Viewer, which is used with the IDS Manager.

Figure 3.16: Secure Communications

Note

IPSec is supported on sensors running version 2.5 or later, Unix Directors running version 2.2.2 or later, and version 2.3.i or later for CSPM. SSH is supported on sensors running version 3.0.

Using SSH provides a command and control (C & C) interface that allows you to administer the Sensor remotely without exposing plain-text usernames and passwords to the network connecting you to the Sensor.

To configure secure communications, you have two options:

IPSec Communications
Secure Shell Communications

Option 1: IPSec Communications

To use IPSec communications, follow these steps:

Select suboption 1 in Secure Communication, IPSec Communications. You will see the IPSec Communications window.
Select option 1, Session Keys. Here you have the option of accepting the default keys or creating custom keys. For default keys, proceed with step 3. For custom keys, skip to step 5.
Select option 1 to access the Set Up Default Keys screen.
Enter the inbound and outbound Security Port Index (SPI) values. (Refer to Table 3.2 for SPI values.) Once this is done, proceed to step 7.
Select option 2 to access the Set Up Custom Keys screen.
Enter the key values. (Refer to Table 3.2 for key value options.)
Exit back to the IPSec Communications screen.

Table 3.2: IPSec Communications Field Values
Key	Value
Cipher	8-byte hexadecimal string
Authentication	16-byte hexadecimal string
SPI	Value 0x100 - 0xffff ffff (numeric)

The other option in the IPSec Communications menu is to enable NAT. Only use this if NAT is set up between the management device and the sensor. If NAT is enabled, the result is encryption of IDS traffic only. TCP traffic is unencrypted. For added security, use SSH communications when NAT is enabled.

Some of the benefits from using IPSec are as follows:

Secure communications between the management device and the sensor
Traffic is encrypted between the nodes
Authentication, confidentiality, and nonrepudiation protection for IDS communications

Option 2: Secure Shell Communications

To use Secure Shell Communications, follow these steps:

Select option 2 on the IPSec Communications menu to access the Secure Shell Communications screen. This screen allows you to select up to three levels of security.
Select options 1-High (Telnet and FTP disabled), 2-Medium (Telnet disabled), or 3-Low (insecure services available).
Exit to return to the Secure Shell screen.
Select option 2 to access the Manage Secure Shell Known Hosts screen. The SSH client keeps a list of hosts it has connected to. Keys become invalid when keys are moved to different IP address or regenerated. The invalid information needs to be purged for further communication.
Choose a user with a known_hosts file.
Exit to return to the Secure Shell screen.
Select option 3 to access the Host Key Operations screen.
Here you have two options, 1-Delete host key and generate a new one, or 2-Delete host key. Make your selection. With key pairs, you need a public and a private key. The encrypted messages can only be decrypted with the proper key. The server generates the host key pair when the server is first started. Regenerate the key if it becomes suspect. If the key is regenerated, all the hosts that have communicated with the server will have to have the old key pair cleared from their cache in order to communicate in the future.
Exit and reboot.

Note
IPSec is resource-intensive on the sensor. Excessive processing due to IPSec can cause intrusion alarms to go undetected and ultimately unreported.

The Display

The display in Figure 3.17 allows you to toggle back and forth between VGA and terminal settings. This is a setting that everybody needs to get familiar with because inevitably it will be forgotten. VGA/Terminal mode allows the VGA and terminal port to be used to log in to the sensor. Boot messages are suppressed on the terminal port and sent only to the VGA port.

Figure 3.17: The Display

The Terminal mode disables the VGA display and only displays output to a terminal connected to the COM1 port. This sends boot messages to the terminal port COM1. With the Terminal only mode configured, you cannot log in to the sensor by connecting a keyboard and monitor.

Once the sysconfig-sensor options have been completed, the system will need to be rebooted. Modifying options 1 through 5 require a reboot. Options 6 through 8 do not require a reboot. One exception is changing the time zone in option 7. If the time zone is changed, a reboot is required