|
|
This chapter provides sample scenarios in which intrusion detection technology is deployed in a variety of environments:
This section discusses the following topics:
The objective of this scenario is to configure the Cisco IOS Firewall Intrusion Detection System (Cisco IOS IDS) on a router. The protected subnet contains sensitive research and development systems. The scenario also features various modifications, including signature tuning for false positives and network redesign.
The main limitations of this scenario are throughput and coverage. Because Cisco IOS IDS is an in-line device, it inspects packets as they traverse the router's interfaces. This may impact network performance to some extent. Also, depending on the speed of the segment and the processing power of the router, some packets may not trigger signatures.
Furthermore, because Cisco IOS IDS has fewer signatures than the NetRanger Sensor appliance, it may not detect as many attacks.
A Cisco 2600, Cisco 3600, Cisco 7100, or Cisco 7200 router with the Cisco IOS Firewall Feature Set and Cisco IOS Firewall Intrusion Detection System (Cisco IOS IDS) enabled is required for this scenario. You also need a NetRanger Director to receive alarms from the Cisco IOS IDS platform.
For this scenario, use Figure 3-1 as the initial network diagram.
The following primary tasks must be taken for initial setup:
The Cisco IOS IDS acts as an in-line intrusion detection sensor, watching packets as they traverse the router's interfaces and acting upon them in a definable fashion. When a packet, or a number of packets in a session, match a signature, the Cisco IOS IDS can perform the following configurable actions:
In Example 3-1, Cisco IOS IDS is initialized. Notice that the router is set up to use two routes to communicate with the NetRanger Director. This configuration is optional, but provides extra fault tolerance for alarm notifications.
ip audit smtp spam 25 ip audit notify nr-director ip audit notify log ip audit po local hostid 55 orgid 123 ip audit po remote hostid 14 orgid 123 rmtaddress 10.1.1.99 localaddress 10.1.1.1 preference 1 ip audit po remote hostid 14 orgid 123 rmtaddress 172.16.58.99 localaddress 10.2.1.1 preference 2 ip audit name AUDIT.1 info action alarm ip audit name AUDIT.1 attack action alarm drop reset interface e0 ip address 10.1.1.1 255.255.255.0 ip audit AUDIT.1 in interface e1 ip address 10.2.1.1 255.255.0.0
Notice that the Cisco IOS IDS router is given a NetRanger Host ID of 55, and its Organization ID (orgid) matches the Director's Organization ID (123).
This NetRanger communication data must be added to the Director in order for the two components to communicate. Use nrConfigure on the NetRanger Director to add the Cisco IOS IDS router's information to the Director:
Step 1 On the Director, start nrConfigure by clicking Configure on the Security menu.
Step 2 Double-click the name of your Director machine on the displayed list.
Step 3 Double-click the currently applied configuration version (the one that is bolded).
Step 4 Double-click System Files.
Step 5 Double-click Hosts.
The Hosts dialog box opens.
Step 6 Click Add and type the host name, host ID, and organization ID for the IDS router.
Step 7 Click OK to close the Hosts dialog box.
Step 8 Double-click Routes.
Step 9 The Routes dialog box opens.
Step 10 Click Add and type in the route to the IDS router.
Step 11 Click OK.
Step 12 The Routes dialog box closes.
Step 13 Select the newly created transient version of the configuration and click Apply.
You can verify that the Director has the Cisco IOS IDS router's information by opening a terminal session on the Director and using the UNIX more command to view the actual configuration files (see Example 3-2 and Example 3-3).
$ more /usr/nr/etc/hosts 14.123 localhost 14.123 director.xyzcorp 55.123 ids2600.xyzcorp
$ more /usr/nr/etc/routes ids2600.xyzcorp 1 10.1.1.1 45000 1 ids2600.xyzcorp 2 10.2.1.1 45000 1
You can verify that Cisco IOS IDS is properly configured on the router with the show ip audit configuration command (see Example 3-4). Notice that communication route 1 has a status of established (ESTAB), while communication route 2 has a status of listen (LISTEN). If communication route 1 were to go down, then communication route 2 would automatically become established. After communication route 1 was reestablished, the router would automatically revert to using it instead of route 2.
ids2600# show ip audit configuration
Event notification through syslog is enabled
Event notification through Net Director is enabled
Default action(s) for info signatures is alarm
Default action(s) for attack signatures is alarm drop reset
Default threshold of recipients for spam signature is 25
PostOffice:HostID:55 OrgID:123 Msg dropped:0
:Curr Event Buf Size:100 Configured:100
HID:14 OID:123 S:1 A:2 H:82 HA:49 DA:0 R:0 Q:0
ID:1 Dest:10.1.1.99:45000 Loc:10.1.1.1:45000 T:5 S:ESTAB *
ID:2 Dest:172.16.58.99:45000 Loc:10.2.1.1:45000 T:5 S:LISTEN
Audit Rule Configuration
Audit name AUDIT.1
info actions alarm
attack actions alarm drop reset
You can verify which interfaces have audit rules applied to them with the show ip audit interface command (see Example 3-5).
ids2600# show ip audit interface
Interface Configuration
Interface Ethernet0
Inbound IDS audit rule is AUDIT.1
info actions alarm
attack actions alarm drop reset
Outgoing IDS audit rule is not set
Interface Ethernet1
Inbound IDS audit rule is not set
Outgoing IDS audit rule is not set
Alarms deriving from the Cisco IOS IDS platform appear on the NetRanger Director's IOS IDS submap (see Figure 3-2).
One common problem with deploying intrusion detection technologies is false positives, which is otherwise benign or expected behavior that triggers alarms.
For example, in Figure 3-3, a NetSonar device with an IP address of 10.1.1.65 is mapping out various internal subnets, and the audit rule applied to the router's Ethernet0 interface (10.1.1.1) is detecting this activity and sending alarms to the NetRanger Director.
Because the NetSonar device is set to scan the internal subnets on a regular basis, there is no need to generate alarms on this activity. To solve this problem, you can add an access control list (ACL) to the audit rule that keeps traffic originating from the NetSonar device from being audited (see Example 3-6).
ip audit smtp spam 25 ip audit notify nr-director ip audit notify log ip audit po local hostid 55 orgid 123 ip audit po remote hostid 14 orgid 123 rmtaddress 10.1.1.99 localaddress 10.1.1.1 preference 1 ip audit po remote hostid 14 orgid 123 rmtaddress 172.16.58.99 localaddress 10.2.1.1 preference 2 ip audit name AUDIT.1 info list 90 action alarm ip audit name AUDIT.1 attack list 90 action alarm drop reset interface e0 ip address 10.1.1.1 255.255.255.0 ip audit AUDIT.1 in interface e1 ip address 10.2.1.1 255.255.0.0 access-list 90 deny 10.1.1.65 access-list 90 permit any
Another way to deal with false positives is to disable the individual signatures that are being triggered. For example, you notice that the router is generating a lot of false positives for signatures 1234, 2345, and 3456. You know that there is an application on the network that is causing signature 1234 to fire, and it is not an application that should cause security concerns. This signature can be disabled, as illustrated in Example 3-7.
ip audit smtp spam 25 ip audit notify nr-director ip audit notify log ip audit po local hostid 55 orgid 123 ip audit po remote hostid 14 orgid 123 rmtaddress 10.1.1.99 localaddress 10.1.1.1 preference 1 ip audit po remote hostid 14 orgid 123 rmtaddress 172.16.58.99 localaddress 10.2.1.1 preference 2 ip audit signature 1234 disable ip audit name AUDIT.1 info list 90 action alarm ip audit name AUDIT.1 attack list 90 action alarm drop reset interface e0 ip address 10.1.1.1 255.255.255.0 ip audit AUDIT.1 in interface e1 ip address 10.2.1.1 255.255.0.0 access-list 90 deny 10.1.1.65 access-list 90 permit any
Example 3-8 shows the ACL attached to the signatures.
ip audit smtp spam 25 ip audit notify nr-director ip audit notify log ip audit po local hostid 55 orgid 123 ip audit po remote hostid 14 orgid 123 rmtaddress 10.1.1.99 localaddress 10.1.1.1 preference 1 ip audit po remote hostid 14 orgid 123 rmtaddress 172.16.58.99 localaddress 10.2.1.1 preference 2 ip audit signature 1234 disable ip audit signature 2345 list 91 ip audit signature 3456 list 91 ip audit name AUDIT.1 info list 90 action alarm ip audit name AUDIT.1 attack list 90 action alarm drop reset interface e0 ip address 10.1.1.1 255.255.255.0 ip audit AUDIT.1 in interface e1 ip address 10.2.1.1 255.255.0.0 access-list 90 deny 10.1.1.55 access-list 90 permit any access-list 91 deny host 10.1.1.155 access-list 91 deny host 10.1.1.2 access-list 91 deny 172.16.58.0 0.0.0.255 access-list 91 permit any
Other common problems are created when a company reorganizes its networks. For instance, in Figure 3-4, the company has now reorganized by adding two subnets, a serial connection to the Internet, and by placing only trusted users on the 10.2.0.0 and 10.3.0.0 networks. Audit rules have been added to the 10.2.1.1, 10.3.1.1, and 192.168.1.1 interfaces. The work done by the employees on the trusted networks must not be disrupted by Cisco IOS IDS, so attack signatures in the AUDIT.1 audit rule now will only alarm on a match.
For sessions that originate from the Internet (via the 192.168.1.1) interface, any attack signature matches (other than the false positive ones that are being filtered out) are to be dealt with in the following manner: send an alarm, drop the packet, and reset the TCP session.
This dual-tier method of signature response is accomplished by configuring two different audit specifications and applying each to a different ethernet interface, as illustrated in Example 3-9.
ip audit smtp spam 25 ip audit notify nr-director ip audit notify log ip audit po local hostid 55 orgid 123 ip audit po remote hostid 14 orgid 123 rmtaddress 10.1.1.99 localaddress 10.1.1.1 preference 1 ip audit po remote hostid 14 orgid 123 rmtaddress 172.16.58.99 localaddress 10.2.1.1 preference 2 ip audit signature 1234 disable ip audit signature 2345 list 91 ip audit signature 3456 list 91 ip audit name AUDIT.1 info list 90 action alarm ip audit name AUDIT.1 attack list 90 action alarm ip audit name AUDIT.2 info action alarm ip audit name AUDIT.2 attack alarm drop reset interface e0 ip address 10.1.1.1 255.0.0.0 ip audit AUDIT.1 in interface e1 ip address 10.2.1.1 255.255.255.0 ip audit AUDIT.1 in interface e2 ip address 10.3.1.1 255.255.255.0 ip audit AUDIT.1 in interface s0 ip address 192.168.1.1 255.0.0.0 ip audit AUDIT.2 in access-list 90 deny host 10.1.1.65 access-list 90 permit any access-list 91 deny host 10.1.1.155 access-list 91 deny host 10.1.1.2 access-list 91 deny 172.16.58.0 0.0.0.255 access-list 91 permit any
This section discusses the following topics:
This scenario illustrates the use of syslog messages to report policy violations (in other words, activity that matches an ACL's deny rule) to a NetRanger Sensor, which can then send the alarm data to a NetRanger Director.
The main limitation of this scenario is the number of packets that are denied by the router's ACL, and consequently, the number of syslog messages sent to the NetRanger Sensor.
This scenario requires that you have a Cisco router running any Cisco IOS software version from Release 10.3 through Release 12.0, and a properly installed and configured NetRanger Sensor and Director.
For this scenario, use the network diagram in Figure 3-5.
This section discusses the following topics:
For this scenario, initialize the Sensor and Director with the communication parameters listed in Table 3-1.
| Parameter | Director | Sensor |
|---|---|---|
IP Address | 10.7.1.100 10.8.1.100 | 10.7.1.50 |
Host ID | 100 | 50 |
Host Name | director | sensor |
Organization ID | 500 | 500 |
Organization Name | xyzcorp | xyzcorp |
Refer to the NetRanger User Guide for complete installation and setup information.
To verify the configuration of the Director and Sensor, see Example 3-10 through Example 3-13. Notice that because the Director is dual homed on both the 10.7.0.0 and 10.8.0.0 networks, that the Sensor can have both a primary and secondary route to the Director.
$ more /usr/nr/etc/hosts 100.500 localhost 100.500 director.xyzcorp 50.500 sensor.xyzcorp
$ more /usr/nr/etc/routes sensor.xyzcorp 1 10.7.1.50 45000 1
$ more /usr/nr/etc/hosts 50.500 localhost 50.500 sensor.xyzcorp 100.500 director.xyzcorp
$ more /usr/nr/etc/routes director.xyzcorp 1 10.7.1.100 45000 1 director.xyzcorp 2 10.8.1.100 45000 1
To set up syslog notification on the router, enter configuration mode on the router with the conf t command and type the following commands:
logging sensor_ip_address logging trap info
where sensor_ip_address is the IP address of the Sensor's command and control interface.
Exit configuration mode by pressing Ctrl+Z and make the changes permanent on the router with the wr mem command.
After setting up syslog notification, you need to manually configure the ACLs to log policy violations. In this scenario, an ACL has been applied to the router's Serial 0 interface (192.168.1.1) to deny all inbound FTP and Telnet traffic from the Internet. The ACL in question is listed in Example 3-14.
interface serial 0 ip address 192.168.1.1 255.255.0.0 ip access-group 199 in access-list 199 deny tcp any any eq 21 access-list 199 deny tcp any any eq 23 access-list 199 permit ip any any
To report violations of this ACL, append the string "log" at the end of each deny rule, as illustrated in Example 3-15.
access-list 199 deny tcp any any eq 21 log access-list 199 deny tcp any any eq 23 log access-list 199 permit ip any any
The final step in sending syslog notifications to a Sensor is to configure the Sensor to accept the syslog messages.
To configure the Sensor to accept syslogd traffic from the router, follow these steps:
Step 1 On the Director interface, click the Sensor's icon and click Configure on the Security menu.
Step 2 In the current configuration version (the folder that is bolded), double-click Intrusion Detection.
Step 3 Click the Data Sources tab.
Step 4 In the Data Sources field, ensure that the IP address and netmask of the router sending the syslog information is present.
Step 5 Click the Profile tab and ensure that Setup Method is set to Manual Configuration.
Step 6 Click Modify Sensor and scroll down to the "Security Violations" signature and click Expand.
Step 7 Click Add to add the name/number of the Cisco ACL that sends syslog data to the Sensor (in this case, 199).
Step 8 Choose an action from the list in response to the policy violation alarm, and enter the alarm's severity level for the destination (the NetRanger Director).
Step 9 Click OK on each dialog box to close them.
Step 10 Select the newly created transient version and click Apply.
When you click Apply, the NetRanger Director updates the Sensor's configuration. The Sensor can now accept syslog traffic from the router and send policy violation alarms to the Director.
A common problem with this type of scenario involves insufficient protection. For example, although FTP and Telnet traffic is being denied and logged to the Sensor, an attacker may also try to enter the network via other methods, such as rlogin, HTTP, or TFTP.
In this scenario, other alarms on unauthorized activity are all being generated by a group of hosts on a specific network (hosts 172.31.10.10-13). It seems that all the traffic (except the FTP and Telnet attempts) from these specific attackers is getting through the router's interfaces.
The easiest solution is to adjust the ACL to deny the specific hosts (see Example 3-16).
access-list 199 deny host 172.31.10.10 log access-list 199 deny host 172.31.10.12 log access-list 199 deny host 172.31.10.13 log access-list 199 deny tcp any any eq 21 log access-list 199 deny tcp any any eq 23 log access-list 199 permit ip any any
Another problem with this scenario is based largely on the amount of syslog traffic sent to the Sensor (and the subsequent alarms sent to the Director). If the amount of syslog notifications is undesirable (either for reasons of performance or alarm management), then you have two options:
1. Continue to deny traffic, but do not log the policy violations. Simply remove "log" from the end of any deny rule you no longer want logged.
2. Reconfigure the ACLs to pinpoint and deny specific traffic instead of denying all traffic of a certain type or source.
For example, instead of denying traffic from all hosts on a network, deny only certain hosts from that network.
For example, instead of disallowing all incoming FTP and Telnet traffic from the Internet, selectively deny this type of traffic from certain hosts or networks known to be hostile.
This section discusses the following topics:
The objective of this scenario is to deploy a Cisco router, firewall, and Sensor in such a way that the Sensor can dynamically update the router's ACLs to shun attackers.
For this scenario, there are two major limitations:
A Cisco router running any Cisco IOS software version from Release 10.3 through Release 12.0, a PIX Firewall, and a NetRanger Director and Sensor.
For this scenario, use Figure 3-6 as the network diagram.
This section discusses the following topics:
For this scenario, initialize the Sensor and Director with the communication parameters listed in Table 3-2.
| Parameter | Director | Sensor |
|---|---|---|
IP Address | 172.16.3.200 | 172.16.2.100 |
Host ID | 200 | 100 |
Host Name | director | sensor |
Organization ID | 500 | 500 |
Organization Name | xyzcorp | xyzcorp |
Refer to the NetRanger User Guide for complete installation and setup information.
To verify the configuration of the Director and Sensor, see Example 3-17 through Example 3-20.
$ more /usr/nr/etc/hosts 200.500 localhost 200.500 director.xyzcorp 100.500 sensor.xyzcorp
$ more /usr/nr/etc/routes sensor.xyzcorp 1 172.16.2.100 45000 1
$ more /usr/nr/etc/hosts 100.500 localhost 100.500 sensor.xyzcorp 200.500 director.xyzcorp
$ more /usr/nr/etc/routes director.xyzcorp 1 172.16.3.200 45000 1
The initial setup for the router in this scenario is illustrated in Example 3-21.
Using 906 out of 29688 bytes ! version 12.0 service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname border-router ! logging console informational enable password attack ! memory-size iomem 10 ! interface ethernet 0 ip address 172.16.2.1 255.255.0.0 ! interface ethernet 1 ip address 172.16.3.1 255.255.0.0 ! interface serial 0 ip address 192.168.1.1 255.255.0.0
In this scenario, you need to set up an ACL on the router to deny all traffic outside the 172.16.0.0 Class B network, thereby protecting the NetRanger Director from any possible outside attacker. The ACL is applied to the out direction of the router's ethernet 1 interface (see Example 3-22).
interface ethernet 1 ip address 172.16.3.1 255.255.0.0 access-group 1 out access-list 1 permit 172.16.0.0 0.0.255.255
Configure the PIX Firewall to allow the following traffic:
Device management refers to the Sensor's ability to dynamically reconfigure the filters and access control lists on a router to shun an attacker. This functionality is provided by the managed service. Shunning refers to the Sensor's ability to use a network device to deny entry to a specific network host or an entire network.
NetRanger Sensors can manage the following types of Cisco routers:
To configure device management on the Sensor, follow these steps:
Step 1 On the Director interface, click the Sensor's icon and click Configure on the Security menu.
Step 2 In the current configuration version (the folder that is bolded), double-click Device Management.
Step 3 Click the Devices tab.
Step 4 Add information about the router (such as it's IP address, username, password, and enable password).
Step 5 Click the Interfaces tab.
Step 6 Add information about each of the managed router's interfaces (such as IP address, interface name).
The IP address you enter is the IP address of the interface the Sensor uses to communicate with the router. This interface is not necessarily the same interface used for shunning.
For this scenario, the Sensor communicates with the 172.16.2.1 interface, and dynamically shuns on the 192.168.1.1 interface's in direction (s0 in).
Step 7 Click the Shunning tab.
Step 8 Add the Director, Sensor, PIX Firewall, and router to the Addresses Never to Shun list.
This keeps the Sensor from ever shunning those particular hosts.
Step 9 Add an entry for the Sensor under Shunning Servers.
Step 10 Click the General tab.
Step 11 Set the shunning ACL to 199.
The Sensor will use this ACL on the router to dynamically shun attackers. The Sensor will also use ACL 198 as the second ACL to write to whenever changes need to be made to the original ACL.
Step 12 Click OK to close the Device Management dialog box.
Step 13 Double-click the Intrusion Detection dialog box.
Step 14 Click the Profile tab.
Step 15 Select Profile-based Configuration.
Step 16 Under Signatures to Disable, you can disable individual signatures by selecting their check boxes.
Step 17 Under Response, click either Relaxed, Moderate, or Strong.
Step 18 You can view your settings in the General Signatures dialog box by clicking View Sensor.
Step 19 Click OK to close the Intrusion Detection dialog box.
Step 20 Select the newly created transient version and click Apply.
When this process is complete, the Sensor's /usr/nr/etc/managed.conf file should look something like Example 3-23.
$ more /usr/nr/etc/managed.conf FilenameOfError ../var/errors.managed NetDevice 172.16.2.1 DefaultCisco password enable NeverShunAddress 172.16.3.200 255.255.255.255 #Director NeverShunAddress 172.16.2.100 255.255.255.255 #Sensor NeverShunAddress 172.16.2.5 255.255.255.255 #Firewall--outer interface NeverShunAddress 172.16.2.4 255.255.255.255 #Firewall--inner interface NeverShunAddress 172.16.2.1 255.255.255.255 #Router ShunInterfaceCisco 192.168.1.1 Serial0 in ShunAclCisco 199 MaxShunEntries 100 FilenameOfError ../var/errors.managed FilenameOfConfig ../etc/managed.conf EventLevelOfErrors 1 EventLevelOfCommandLogs 1 EnableACLLogging 0
The NetRanger Sensor is now ready to initiate shunning by writing a dynamic ACL to the router's Serial0 interface. The next major step is to decide which signatures trigger a shun response. This type of automated response by the Sensor should only be configured for attack signatures with a low probability of false positive detection, such as an unambiguous SATAN attack. In case of any suspicious activity that does not trigger automatic shunning, you can use a Director menu function to shun manually.
To set up responses for signatures, follow these steps:
Step 1 On the Director interface, click the Sensor's icon and click Configure on the Security menu.
Step 2 In the current configuration version (the folder that is bolded), double-click Intrusion Detection.
Step 3 Click the Profile tab.
Step 4 Select Manual Configuration and click Modify Sensor.
Step 5 In the General Signatures dialog box, you can select shunning for any signature. However, the best candidates for use with shunning are known as Level 5 Signatures, and they are listed in Example 3-24.
Step 6 For this scenario, set the shun action on the following signatures:
Step 7 Click OK to close the General Signatures dialog box.
Step 8 Click OK to close the Intrusion Detection dialog box.
Step 9 Select the newly created transient version and click Apply.
The listing in Example 3-24 was filtered from the /usr/nr/etc/wgc/templates/packetd.conf file using the following UNIX command:
grep SigOfGeneral /usr/nr/etc/wgc/templates/packetd.conf | awk '{ if (($4 ~ /5/) && ($5 ~ /5/) && ($6 ~ /5/) && ($7 ~ /5/)) { print $0 } }'
This command extracts all signatures that contain the numeral 5 in each of the four destination columns of the /usr/nr/etc/wgc/templates/packetd.conf file. These signatures have been identified by Cisco to have a very low incidence of false positives; in other words, these signatures fire only on actual attacks the vast majority of the time.
SigOfGeneral 1004 0 5 5 5 5 # IP options - Loose source route SigOfGeneral 1006 0 5 5 5 5 # IP options - Strict source route SigOfGeneral 1102 0 5 5 5 5 # Impossible IP packet SigOfGeneral 1103 0 5 5 5 5 # IP fragments overlap SigOfGeneral 2101 0 5 5 5 5 # ICMP network sweep w/Timestamp SigOfGeneral 2102 0 5 5 5 5 # ICMP network sweep w/Address Mask SigOfGeneral 2154 0 5 5 5 5 # ICMP Ping Of Death SigOfGeneral 3003 0 5 5 5 5 # TCP FRAG SYN port sweep SigOfGeneral 3005 0 5 5 5 5 # TCP FIN port sweep SigOfGeneral 3006 0 5 5 5 5 # TCP FRAG FIN port sweep SigOfGeneral 3011 0 5 5 5 5 # TCP FIN High port sweep SigOfGeneral 3012 0 5 5 5 5 # TCP FRAG High FIN port sweep SigOfGeneral 3015 0 5 5 5 5 # TCP Null port sweep SigOfGeneral 3016 0 5 5 5 5 # TCP FRAG Null port sweep SigOfGeneral 3020 0 5 5 5 5 # TCP SYN FIN port sweep SigOfGeneral 3021 0 5 5 5 5 # TCP FRAG SYN FIN port sweep SigOfGeneral 3031 0 5 5 5 5 # TCP FRAG SYN host sweep SigOfGeneral 3032 0 5 5 5 5 # TCP FIN host sweep SigOfGeneral 3033 0 5 5 5 5 # TCP FRAG FIN host sweep SigOfGeneral 3034 0 5 5 5 5 # TCP NULL host sweep SigOfGeneral 3035 0 5 5 5 5 # TCP FRAG NULL host sweep SigOfGeneral 3036 0 5 5 5 5 # TCP SYN/FIN host sweep SigOfGeneral 3037 0 5 5 5 5 # TCP FRAG SYN/FIN host sweep SigOfGeneral 3050 0 5 5 5 5 # Half-open SYN attack SigOfGeneral 3107 0 5 5 5 5 # Majordomo exec bug SigOfGeneral 3108 0 5 5 5 5 # MIME overflow bug SigOfGeneral 3229 0 5 5 5 5 # WebSite win-c-sample buffer overflow SigOfGeneral 3233 0 5 5 5 5 # WWW Count Overflow SigOfGeneral 3250 0 5 5 5 5 # TCP Hijacking
SigOfGeneral 3251 0 5 5 5 5 # TCP Hijacking Simplex Mode SigOfGeneral 3300 0 5 5 5 5 # NETBIOS OOB data SigOfGeneral 3306 0 5 5 5 5 # Windows Registry Access SigOfGeneral 3307 0 5 5 5 5 # Windows RedButton SigOfGeneral 3500 0 5 5 5 5 # rlogin -froot SigOfGeneral 3525 0 5 5 5 5 # Imap Authenticate Overflow SigOfGeneral 3526 0 5 5 5 5 # Imap Login Overflow SigOfGeneral 3550 0 5 5 5 5 # Pop Overflow SigOfGeneral 3575 0 5 5 5 5 # Inn Overflow SigOfGeneral 3576 0 5 5 5 5 # Inn Control Message SigOfGeneral 3600 0 5 5 5 5 # IOS DoS SigOfGeneral 3601 0 5 5 5 5 # IOS Command History SigOfGeneral 4001 0 5 5 5 5 # UDP port scan SigOfGeneral 4053 0 5 5 5 5 # Back Orifice SigOfGeneral 4100 0 5 5 5 5 # Tftp passwd file attempt SigOfGeneral 6001 0 5 5 5 5 # Normal SATAN probe SigOfGeneral 6002 0 5 5 5 5 # Heavy SATAN probe SigOfGeneral 6100 0 5 5 5 5 # RPC port registration SigOfGeneral 6101 0 5 5 5 5 # RPC port unregistration SigOfGeneral 6110 0 5 5 5 5 # RPC RSTATD Port Sweep SigOfGeneral 6111 0 5 5 5 5 # RPC RUSERSD Port Sweep SigOfGeneral 6112 0 5 5 5 5 # RPC NFS Port Sweep SigOfGeneral 6113 0 5 5 5 5 # RPC MOUNTD Port Sweep SigOfGeneral 6114 0 5 5 5 5 # RPC YPPASSWDD Port Sweep SigOfGeneral 6115 0 5 5 5 5 # RPC SELECTION SVC Port Sweep SigOfGeneral 6116 0 5 5 5 5 # RPC REXD Port Sweep SigOfGeneral 6117 0 5 5 5 5 # RPC STATUS Port Sweep SigOfGeneral 6118 0 5 5 5 5 # RPC TTDB Port Sweep SigOfGeneral 6190 0 5 5 5 5 # statd buffer overflow SigOfGeneral 6191 0 5 5 5 5 # ttdb buffer overflow SigOfGeneral 6192 0 5 5 5 5 # mountd buffer overflow SigOfGeneral 6200 0 5 5 5 5 # Ident buffer overflow SigOfGeneral 6201 0 5 5 5 5 # Ident newline SigOfGeneral 6202 0 5 5 5 5 # Ident improper request SigOfGeneral 6300 0 5 5 5 5 # Loki ICMP tunnel SigOfGeneral 6302 0 5 5 5 5 # Modified Loki ICMP tunneling
Many security administrators implementing this scenario may prefer to have a dual-homed Director machine so that the Sensor can communicate with it directly, instead of via the PIX Firewall and router.
In Figure 3-7, the NetRanger Director is dual-homed on the 172.16.3.0 and 172.16.2.0 networks.
This slight change in configuration requires that you alter the entries in the Sensor's /usr/nr/etc/routes file; not only are you adding an entry for the 172.16.2.200 network address, you also decide to make this route the preferred route and the previous route secondary.
To implement this change, use nrConfigure:
Step 1 On the Director interface, click the Sensor's icon and click Configure on the Security menu.
Step 2 In the current configuration version (the folder that is bolded), double-click System Files.
Step 3 Double-click Routes.
Step 4 Select the second line, which indicates that the route to 172.16.3.200 is a primary route.
Step 5 Click Modify.
Step 6 Change the priority of the route to 2.
Step 7 Click OK.
Step 8 Click OK to close the Routes dialog box.
Step 9 Select the newly created transient version and click Apply.
The Sensor's routes file should now look like Example 3-25.
$ more /usr/nr/etc/routes director.xzycorp 1 172.16.2.200 45000 1 director.xyzcorp 2 172.16.3.200 45000 1
In addition, you have to add this new Director IP address to the Sensor's NeverShunAddress list:
Step 1 On the Director interface, click the Sensor's icon and click Configure on the Security menu.
Step 2 In the current configuration version (the folder that is bolded), double-click Device Management.
Step 3 Click the Shunning tab.
Step 4 Add the 172.16.2.200 IP address to the Addresses Never to Shun list.
Step 5 Click OK to close the Intrusion Detection dialog box.
Step 6 Select the newly created transient version and click Apply.
You can verify this change by looking at the /usr/nr/etc/managed.conf file (see Example 3-26).
$ more /usr/nr/etc/managed.conf FilenameOfError ../var/errors.managed NetDevice 172.16.2.1 DefaultCisco password enable NeverShunAddress 172.16.3.200 255.255.255.255 NeverShunAddress 172.16.2.200 255.255.255.255 NeverShunAddress 172.16.2.100 255.255.255.255 NeverShunAddress 172.16.2.5 255.255.255.255 NeverShunAddress 172.16.2.4 255.255.255.255 NeverShunAddress 172.16.2.1 255.255.255.255 ShunInterfaceCisco 192.168.1.1 Serial0 in ShunAclCisco 199 MaxShunEntries 100 FilenameOfError ../var/errors.managed FilenameOfConfig ../etc/managed.conf EventLevelOfErrors 1 EventLevelOfCommandLogs 1 EnableACLLogging 0
Many months later, when the corporate network is reconfigured, it is decided that outside networks should have full access to the 172.16.3.0 network. For this to occur, the ACL on the 172.16.3.1 interface must be removed (see Example 3-27). However, because there are still critical servers and systems on this subnet, it is decided that a NetRanger Sensor should be installed there for security. Figure 3-8 illustrates the new changes to the network.
interface ethernet 1 ip address 172.16.3.1 255.255.0.0
The new Sensor at 172.16.3.100 needs to be able to communicate with the Director, and vice versa. You can use nrConfigure's Add Host Wizard to add this Sensor (see the NetRanger User Guide for more information).
Use the values listed in Table 3-3 to set up the second Sensor.
| Parameter | Sensor |
|---|---|
IP Address | 172.16.3.100 |
Host ID | 300 |
Host Name | sensor2 |
Organization ID | 500 |
Organization Name | xyzcorp |
You can verify that these parameters are set on the Sensor by viewing it's configuration files. They should look like Example 3-28 and Example 3-29.
$ more /usr/nr/etc/hosts 300.500 localhost 300.500 sensor2.xyzcorp 200.500 director.xyzcorp
$ more /usr/nr/etc/routes director.xzycorp 1 172.16.3.200 45000 1 director.xyzcorp 2 172.16.2.200 45000 1
The Add Host Wizard automatically adds the Sensor as an entry to the Director's hosts and routes files. You can verify this by checking the configuration files, which should look like Example 3-30 and Example 3-31.
$ more /usr/nr/etc/hosts 200.500 localhost 200.500 director.xyzcorp 100.500 sensor.xyzcorp 300.500 sensor2.xyzcorp
$ more /usr/nr/etc/routes sensor.xyzcorp 1 172.16.2.100 45000 1 sensor2.xyzcorp 1 172.16.3.100 45000 1
This section discusses the following topics:
The objective of this scenario is to build a hierarchy of Sensor and Director systems through the use of message propagation. Instead of broadcasting events from a Sensor onto multiple hosts, information can be sent to a single Director, which can then propagate packets onto other platforms defined in its local configuration files. The Sensors will also be configured to propagate messages to more than one Director, thereby insuring fault-tolerant communication.
In addition to providing performance benefits and fault tolerance, tiered hierarchies can simplify system management. For example, local Director machines might be responsible for monitoring from 9AM to 5PM and then transfer control onto a central remote Director every evening.
Although using a tiered hierarchy provides some benefits of reduced workload, using local Director hosts to forward packets to remote Director hosts may involve delays if the links connecting the segments are slow or heavily trafficked. This may result in slight delays in alarm generation on the "top-level" Director in the tiered hierarchy.
Another limitation involves using the "top-level" Director to configure Sensors and act on the copied alarms. These and other issues are discussed in the "Common Problems and Troubleshooting" section.
This scenario involves the use of three Sensors and three Directors; however, any number of Sensors and Directors can be used.
For this scenario, use Figure 3-9 as a reference point.
For this scenario, use nrConfigure's Add Host Wizard to initialize each Sensor and Director (see the NetRanger User Guide for more information). Use the values listed in Table 3-4.
After initial configuration, configure director3 to accept the alarms it receives from director1 and director2:
Step 1 On director3's interface, click the director3 icon and click Configure on the Security menu.
Step 2 Double-click System Files.
Step 3 Double-click Organizations.
Step 4 Select the organization to which director1 and director2 belong and click OK.
Step 5 Double-click Hosts.
Step 6 Add both director1 and director2 and click OK.
Step 7 Double-click Routes.
Step 8 Add the following information about both director1 and director2:
Step 9 Click OK.
Step 10 Double-click Authorizations.
Step 11 Make sure that director1 and director2 each have the following permissions, at minimum:
Step 12 Click OK.
Step 13 Apply your changes by selecting the transient configuration and clicking Apply.
The next step is to configure director1 and director2 to forward their alarms to director3 by using nrConfigure:
Step 1 On the Director interface, click the director1 icon and click Configure on the Security menu.
Step 2 On nrConfigure, click Add Host on the File menu.
Step 3 Read the instructions and click Next.
Step 4 Select the organization name to which director3 belongs.
Step 5 Type in director3's Host name, Host ID, and Host IP address in the appropriate fields.
Step 6 Click Next.
Step 7 Select Forward alarms to secondary Director.
Step 8 Click Next.
Step 9 Click Finish.
Step 10 Repeat the preceding steps for director2.
If needed, you can configure the level of alarms sent to director3:
Step 1 On director1's interface, click Configure on the Security menu.
Step 2 Double-click Director Forwarding.
Step 3 Click the Forwarding tab.
An entry should exist for loggerd on director1 and smid for director3.
Step 4 To change the level of alarms sent to director3, select the director3 entry and click Modify.
Step 5 For Minimum Level, change the minimum alarm level.
Step 6 Click OK.
Step 7 Apply your changes by selecting the transient configuration and clicking Apply.
Step 8 Repeat the preceding steps for director2, if desired.
The preceding procedures write DupDestination entries in the /usr/nr/etc/smid.conf files for both director1 and director2 (see Example 3-32 and Example 3-33). These DupDestination tokens provide information on where to send duplicate alarm information---in this case, director3. Notice that in each case, only alarms that are level 3 or higher are being forwarded.
DupDestination director3.xyzcorp smid 3 ERRORS,COMMANDS,EVENTS,IPLOGS
DupDestination director3.xyzcorp smid 3 ERRORS,COMMANDS,EVENTS,IPLOGS
The first problem encountered in this scenario is duplicate alarms being sent to director3 (172.16.5.50). This duplication is occurring because sensor2 (10.2.1.100) is sending alarm data to both director1 and director2, which are in turn sending level three alarms and higher to director3.
The way to solve this problem is to use nrConfigure to edit sensor2's routes information:
Step 1 On the Director interface, click the sensor2 icon and click Configure on the Security menu.
Step 2 In the current configuration version, double-click System Files.
Step 3 Double-click Routes.
Step 4 Select the director2.xyzcorp entry and click Modify.
Step 5 Change the priority of the route to 2.
Step 6 Click OK.
Step 7 Select the newly created transient version and click Apply.
The secondary route for director2.xyzcorp is to be used only when the route to director1 fails.
You can verify this change by viewing the routes file on the Sensor. It should look like Example 3-34.
director1.xyzcorp 1 10.5.1.50 45000 1 director2.xyzcorp 2 10.6.1.50 45000 1
The second problem arises when security personnel try to use director3 (172.16.5.50) to act on alarm information sent to it by director1 and director2. director3, in it's role as "top-level" Director host of the tiered hierarchy, is only passively receiving alarms, and cannot act on the alarms because it has no entries in its hosts and routes files for the three Sensors. Additionally, director3 has no authority to make changes to any of these Sensors' configuration files or execute commands on them.
First, use nrConfigure to add the each Sensor's information to director3's hosts and routes files:
Step 1 On the Director interface, click the director3 icon and click Configure on the Security menu.
Step 2 In the current configuration version, double-click System Files.
Step 3 Double-click Hosts.
Step 4 Use the Add button to add the Name, Organization Name, and Host ID for sensor1, sensor2, and sensor3, one at a time.
Step 5 Click OK to close the Hosts dialog box.
Step 6 Double-click Routes.
Step 7 Use the Add button to add the Name, Connection Number, IP Address, Port Number, and Type for sensor1, sensor2, and sensor3, one at a time.
Step 8 Click OK to close the Routes dialog box.
Step 9 Select the newly created transient version and click Apply.
The hosts and routes files on director3 should look like Example 3-35 and Example 3-36.
$ more /usr/nr/etc/hosts 30.500 localhost 30.500 director3.xyzcorp 20.500 director2.xyzcorp 10.500 director1.xyzcorp 100.500 sensor1.xyzcorp 200.500 sensor2.xyzcorp 300.500 sensor3.xyzcorp
$ more /usr/nr/etc/routes director1.xyzcorp 1 10.5.1.50 45000 1 director2.xyzcorp 1 10.6.1.50 45000 1 sensor1.xyzcorp 1 10.1.1.100 45000 1 sensor2.xyzcorp 1 10.2.1.100 45000 1 sensor3.xyzcorp 1 10.3.1.100 45000 1
Next, use nrConfigure to allow director3 to execute commands and make configuration changes on each Sensor:
Step 1 On the Director interface, click the sensor1 icon and click Configure on the Security menu.
Step 2 In the current configuration version, double-click System Files.
Step 3 Double-click Authorizations.
Step 4 Click Add.
Step 5 Ensure that Get, Get Bulk, Set, Unset, and Execute are all set to Yes.
Step 6 Click OK to close the Authorizations dialog box.
Step 7 Select the newly created transient version and click Apply.
Step 8 Repeat Steps 1 through 7 for sensor2 and sensor3.
The preceding process writes entries to each Sensor's auths files (see Example 3-37).
$ more /usr/nr/etc/auths director3.xyzcorp GET,GETBULK,SET,UNSET,EXEC
The final task is to add director3 to each Sensor's hosts and routes information, using nrConfigure:
Step 1 On the Director interface, click the sensor1 icon and click Configure on the Security menu.
Step 2 In the current configuration version, double-click System Files.
Step 3 Double-click Hosts.
Step 4 Use the Add button to add the Name, Organization Name, and Host ID for director3.
Step 5 Click OK to close the Hosts dialog box.
Step 6 Double-click Routes.
Step 7 Use the Add button to add the Name, Connection Number, IP Address, Port Number, and Type for director3.
Step 8 Click OK to close the Routes dialog box.
Step 9 Select the newly created transient version and click Apply.
Step 10 Repeat Steps 1 through 9 for sensor2 and sensor3.
Posted: Tue Aug 17 19:18:40 PDT 1999
Copyright 1989-1999©Cisco Systems Inc.