Network Security Fundamentals [Electronic resources] نسخه متنی

Case Study: Deployment of IDS Sensors in the Organization and Their Typical Placement

The IDS case study covers the placement of the IDS equipment in an actual situation. The case study includes the setup and configuration of IDSs in a customer's environment with a few screenshots of the customer's network under attack. This practical example shows how organizations can inspect and monitor overall network activity using IDSs to protect their assets.

Figure 10-19 and Figure 10-20 illustrate the Company XYZ network diagram for this scenario. An Internet user (cracker) is connected via a public connection to Company XYZ headquarters, with the intention of hacking into one of the web servers (WebServer1). The server has been attacked frequently before, and the network administrator wants to implement a solid solution using a network IDS configured for IP blocking.

Figure 10-20 is a closer look at parts of Figure 10-19 so that only the relevant devices for this case study are displayed.

IDS Placement on the Network Blueprint

Identifying the network location for the sensor is important for a number of reasons. As discussed earlier in this chapter, a network administrator must consider the following issues when placing a sensor: size and complexity of the network, interconnectivity with other networks, and the amount and type of network traffic. After collecting this information and knowing which information needs protection, the network administrator can determine sensor location and sensor type (based on bandwidth). The network administrator of Company XYZ decided to place the first sensor at the protected network 10.100.2.0 (DMZ network).

Because of previous attacks on this server, the network administrator placed the sensors on the DMZ network. Sensor placement on this part of the network enables the network administrator to see which users are attempting to gain access to the protected network (DMZ) and which vulnerability exploits are being used. Also, the advantage of this location is that the sensor is not overwhelmed with traffic because there is a filtering device (CampusRouter1, router with access lists) already reducing upstream traffic to the protected network.

The network administrator decided to use out-of-band management with an IDS director connected on the management network of Company XYZ.

IDS Sensor Initialization and Configuration

The first steps for configuring the network IDS involve initializing the device via a console connection and configuring the basic parameters before deployment in the network. Example 10-1 shows the output of the initial System Configuration screen. Once logged in to the sensor via the console (the default username and password are set to "cisco"), you are required to change your password immediately when logging in the first time. To do so, type the keyword

setup , which brings you to the System Configuration screen. The network administrator is required to configure some basic parameters. Once this step is completed and the sensor is connected to the network, a few alternative access methods are available.

In this case study, the administrator deploys only one sensor, but in general, it is common practice for several different sensors with one common profile to be grouped together. An IDS management station or console (often referred to as the IDS director) manages these sensors.

Example 10-1 illustrates the CampusSensor1 System Configuration screen.

Example 10-1. CampusSensor1 System Configuration Screen

sensor login: 
cisco 
Password:
***NOTICE***
This product contains cryptographic features and is subject to United States
and local country laws governing import, export, transfer and use. Delivery
of Cisco cryptographic products does not imply third-party authority to import,
export, distribute or use encryption. Importers, exporters, distributors and
users are responsible for compliance with U.S. and local country laws. By using
this product you agree to comply with applicable laws and regulations. If you
are unable to comply with U.S. and local laws, return this product immediately.
A summary of U.S. laws governing Cisco cryptographic products may be found at:
http://www.cisco.com/wwl/export/crypto
If you require further assistance please contact us by sending email to
export@cisco.com.
sensor# 
setup 
--- System Configuration Dialog ---
At any point you may enter a question mark '?' for help.
User ctrl-c to abort configuration dialog at any prompt.
Default settings are in square brackets '[]'.
Current Configuration:
networkParams
ipAddress 10.1.9.201
netmask 255.255.255.0
defaultGateway 10.1.9.1
hostname sensor
telnetOption disabled
accessList ipAddress 10.0.0.0 netmask 255.0.0.0
exit
timeParams
summerTimeParams
active-selection none
exit
exit
service webServer
general
ports 443
exit
exit
Current time: Mon Feb 23 02:22:00 2004
Setup Configuration last modified: Mon Feb 23 02:21:06 2004
Continue with configuration dialog?[yes]: 
yes 
Enter host name[sensor]: CampusSensor1
Enter IP address[10.1.9.201]: 
10.100.1.19 
Enter netmask[255.255.255.0]: 
255.255.255.0 
Enter default gateway[10.1.9.1]: 
10.100.2.1 
Enter telnet-server status[disabled]:
Enter web-server port[443]:
Modify current access list?[no]:
Modify system clock settings?[no]:
The following configuration was entered.
networkParams
ipAddress 10.100.1.19
defaultGateway 10.100.2.1
hostname CampusSensor1
accessList ipAddress 10.0.0.0 netmask 255.0.0.0
exit
timeParams
summerTimeParams
active-selection none
exit
exit
service webServer
general
ports 443
exit
exit
[0] Go to the command prompt without saving this config.
[1] Return back to the setup without saving this config.
[2] Save this configuration and exit setup.
Enter your selection[2]: 
2 
Configuration Saved.
*02:23:03 UTC Mon Feb 23 2004
Modify system date and time?[no]:
sensor#

The overall objective of deploying IDS technology in your network is to monitor IDS sensor alarms and tune out any alarms triggered by valid traffic. It is becoming obvious that reliable network management tools are required. The methods of managing the IDS sensors in the network depend on the number of sensors that are going to be deployed, unless the organization has a substantial budget allocated for an expensive management platform. Cisco offers different solutions based on different network requirements. For a very limited number of sensors in the network, the IDS sensor has a built-in web service running. The administrator is able to connect to the sensor simply by typing https://<ip_address>/.

In this example, the administrator types https://10.100.1.19/.

This web service running on the sensor is called IDS Device Manager (IDM). To keep the case study simple, the IDM is used. Figure 10-21 illustrates the output of the basic sensor configuration as configured during the initialization phase.

IDS Tuning

Once the administrator is granted access to the sensor via IDM, the IDS Event Viewer (IEV) can be downloaded from Cisco Connection Online (CCO). This application enables the administrator to analyze alarms, find ways to tune out false positives, and implement tuning of specific signatures using IDM. It is critical to identify the cause of every alarm to start eliminating false positives. This initial tuning process can seem tedious but is a mandatory step for a successful deployment of your sensors. This is an important step to guarantee detection of malicious activity.

As a reference for the case study, Figure 10-22 illustrates all the system information that the CampusSensor1 deployed at Company XYZ displays before starting to monitor network activity.

Network Under AttackIDS Event Viewer

The IEV contains a grid pane enabling the network administrator or security personnel to organize and display event records.Chapter 9, "Firewalls."

Figure 10-23 illustrates the IEV Event records display. The attack launched from 10.100.1.2 (translated into 168.17.40.2) is displayed on line 3. Double-clicking the event data provides more detailed information on the attack. As illustrated in Figure 10-24, the administrator is able to trace the attacker's IP address, signature name, destination IP address, and so on.

Based on these events, some reporting and administration mechanisms can be triggered. Launching a notification, triggering a script, or even sending an e-mail are some of the possibilities.

IDS Active Responses in ActionBlocking a Host

After a sensor detects an attack, an alarm is generated by the sensor and sent to the management station. The network IDS can shut the attacker out of the network, usually by setting access control rules on a border device such as CampusRouter1, shown in Figure 10-20. The network administrator uses the IP blocking capability in the sensor to block the session from 168.17.40.2 (cracker) to Company XYZ's WebServer1.

The sensor needs to be configured with the IP address of the blocking device (10.100.2.1) and the blocking interface using the IDM. In this case, it might be wise to select the serial interface connected to the public network. The IDM also requires the access password and enable password of CampusRouter1 to get into configuration mode and alter the access lists.

During an attack, the sensor connects to CampusRouter1 and configures an access list to block traffic originated for the offending host with IP address 168.17.40.2.

Special precautionary measures should be taken when implementing these active responses. The attacker can inappropriately deny service for authorized user traffic and start to abuse them.

Example 10-2 illustrates the CampusRouter1 configuration before the attack.

Example 10-2. CampusRouter1 Configuration

CampusRouter1#
write terminal 
Building configuration...
Current configuration : 1310 bytes
!
version 12.2
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
! hostname CampusRouter1
!
logging queue-limit 100
enable password cisco
<snip>
!
interface FastEthernet0/0
ip address 10.100.2.1 255.255.255.0
duplex auto
speed auto
!
interface Serial0/0
ip address 168.17.40.1 255.255.255.0
encapsulation frame-relay
frame-relay lmi-type ansi
!
<snip>
!
<snip>
!
line con 0
exec-timeout 0 0
password cisco
login
line aux 0
exec-timeout 0 0
password cisco
login
transport input telnet
line vty 0 4
exec-timeout 0 0
password cisco
login
transport input telnet
!
end
CampusRouter1#

Example 10-3 illustrates the CampusRouter1 configuration after the attack, when the sensor autoconfigures a new IP access list.

Example 10-3. CampusRouter1 Configuration After the Attack

CampusRouter1#
write terminal 
Building configuration...
Current configuration : 1310 bytes
!
version 12.2
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname CampusRouter1
!
logging queue-limit 100
enable password cisco
<snip>
!
interface FastEthernet0/0
ip address 10.100.2.1 255.255.255.0
duplex auto
speed auto
!
interface Serial0/0
ip address 168.17.40.2 255.255.255.0
ip access-group IDS_Serial0/0_in_0 in
encapsulation frame-relay
frame-relay lmi-type ansi
!
<snip>
!
!
ip access-list extended IDS_Serial0/0_in_0
deny ip host 168.17.40.2 any
permit ip any any
!
<snip>
!
line con 0
exec-timeout 0 0
password cisco
login
line aux 0
exec-timeout 0 0
password cisco
login
transport input telnet
line vty 0 4
exec-timeout 0 0
password cisco
login
transport input telnet
!
end
CampusRouter1#
CampusRouter1#
show access-list 
Extended IP access list IDS_Serial0/0_in_0
10 deny ip host 168.17.40.1 any
20 permit ip any any (311 matches)
CampusRouter1#

General guidelines on responses to alerts and events are very difficult to outline. But it is recommended not to use active responses during the tuning period. Shunning or blocking, as discussed earlier in the chapter, should be used only as the administrator gains experience with the traffic patterns in the network. Starting with TCP resets instead is recommended. And last but not least, keep in mind that the initial trigger packet makes it to the destination.