Example 10-1. CampusSensor1 System Configuration Screen

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:///.

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.

Figure 10-21. Sensor Configuration Using IDM



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.

Figure 10-22. System Information CampusSensor1



Network Under AttackIDS Event Viewer

The IEV contains a grid pane enabling the network administrator or security personnel to

organize and display event records.

The Internet user or cracker on the private network 10.100.3.0/24 launches a web WinNT

cmd.exe access attack. The RemoteAccessRouter1 is configured for Network Address

Translation (NAT), resulting in a source IP address 168.17.40.2 for the cracker's

workstation.

NOTE

Network Address Translation (NAT) and Port Address Translation (PAT) are discussed

in 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.



Figure 10-23. IEV Event Display



Figure 10-24. Event Record Details



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



!

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

!



!





!

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



!

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

!



!

!

ip access-list extended IDS_Serial0/0_in_0



deny ip host 168.17.40.2 any

permit ip any any

!



!

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.



Conclusion

It is hard to tell which IDS method is best. The choice depends on what you are trying to

achieve as network administrator. The Cisco philosophy to date has been to combine the

use of pattern matching, stateful-pattern matching, protocol decodes, and heuristic-based

signatures.

Cisco and other vendors continue to research and monitor developments in the IDS arena

and incorporate new techniques as they become efficient, practical, and commercially

feasible.