|
|
Installing NetRanger on your network requires some planning and forethought. This chapter addresses the main steps regarding NetRanger pre-installation, and includes the following sections:
This section describes what you must know before securing a network with NetRanger, and includes the following topics:
To help prevent possible miscalculations in NetRanger deployment and configuration, you should carefully examine these aspects of your network:
Consideration of these three points will help you determine the number of Sensors required, the hardware configuration for each Sensor (for example, the size and type of network interface cards), and the number of Director workstations needed.
The Sensor is designed to monitor all traffic crossing a given network segment. With that in mind, you should consider all connections to the network you want to protect. These connections fall into four basic categories, or locations as illustrated in Figure 2-1.
In location one, the Sensor is placed to monitor traffic between the protected network and the Internet. This is commonly referred to as "perimeter protection" and is the most common deployment for a Sensor. This location can be shared with firewall protection, and is discussed in the next section.
In location two, the Sensor is monitoring an extranet connection with a business partner. Although most companies have defined policies on the use and security of this type of connection, there is no guarantee that the partner's network is adequately protected. Consequently, an outsider may enter your network through this type of connection. These extranet connections may be firewalled as well.
In location three, the Sensor is monitoring the network side of a remote access server. Although this connection may be only for employee use, it could be vulnerable to external attack.
In location four, the Sensor is monitoring an intranet connection. Department A's protected network may contain an e-commerce site where all the access types described so far are required. Department B's network may contain company-specific research and development or other engineering information and should be given additional protection.
With this information, you should now consider the network you want to protect. Determine which segments should be monitored. Keep in mind that each Sensor maintains a security policy configured for the segment it is monitoring. These can be standard across the organization or unique for each Sensor. You may consider changing your network topology to force traffic across a given monitored network segment. There are always operational trade-offs when going through this process. The end result should be a rough idea of the number of Sensors required to protect the desired network.
The next step in protecting your network is understanding how the Sensor captures network traffic.
Each Sensor comes with two interfaces. In a typical installation, one interface is used for monitoring the desired network segment, and the other interface is used for communication with the Director and other network devices. The monitoring interface is usually in promiscuous mode, meaning it has no IP address and is not visible on the monitored segment.
The Sensor captures network traffic at the IP layer. Therefore, it must understand and interpret MAC (Media Access Control) layer protocols, which most networks use to pass along data packets. The Sensor currently works with Ethernet, Fast Ethernet, FDDI, and Token Ring technologies (you must select the type of interface when you purchase a Sensor).
The control interface will always be Ethernet. This interface has an assigned IP address, which allows it to communicate with the Director or network devices (typically a Cisco router). Although this interface is "hardened" from a security perspective, it is visible on the network and must be protected.
When responding to attacks, the Sensor inserts TCP Resets via the monitoring interface and ACL changes or shunning via the control interface.
The last step in understanding how a Sensor functions is the data speed or load on the monitored network. Because the Sensor is not in the data path, it has a negligible impact on network performance. However, there are limitations on the data speeds it can monitor. Cisco currently offers a Sensor that can monitor Ethernet and Token Ring segments, and a Sensor that can monitor Fast Ethernet and Single/Dual FDDI connections.
Because the Sensor captures packets directly from the network:
You can place a Sensor in front of or behind a firewall. Each position has its benefits and drawbacks.
Placing a Sensor in front of a firewall allows the Sensor to monitor all incoming and outgoing network traffic. However, when deployed in this manner, the Sensor will not normally detect traffic that is internal to a network. An internal attacker taking advantage of vulnerabilities in network services would remain undetected by the external Sensor.
Placing a Sensor behind a firewall shields the Sensor from any policy violations that the firewall rejects. For example, in this deployment, if a firewall is configured to deny passage of ping sweeps, then the Sensor would not detect this activity and generate an alarm.
The solution is to place one of the Sensor's interfaces directly behind the firewall, and use the second Sensor interface to communicate with the Director or router through the firewall. This configuration is illustrated in Figure 2-2.
In order for the Sensor to effectively defend a network using the router and firewall configuration, you must do the following:
Essentially, the firewall implements policy filtering. The Sensor captures packets between the Cisco router and the firewall, and can dynamically update the Cisco router's access control lists to deny unauthorized activity.
This section describes device management, or the Sensor's ability to dynamically reconfigure the filters on a network device to shun an attacker, and includes the following topics:
NetRanger Sensors can manage the following types of network devices:
StorageTek devices are discussed in "NetSentry Information."
Cisco's IOS architecture relies on Access Control Lists (ACLs) tied to physical interface ports. These ACLs permit or deny passage of data packets through those physical interface ports. Each numbered ACL contains permit and deny conditions that apply to IP addresses. Cisco's software tests IP addresses against the conditions in an access list one at a time. The first match of an IP address determines whether the address is accepted or rejected. The first match is also a signal to stop testing conditions; therefore, the order of the conditions is critical. If no conditions match, then the address is rejected.
When working with ACLs, keep the following in mind:
You can bind one list of statements to a physical entry or exit port at a time. Using ACLs, you could effectively do the following:
You can configure multiple Sensors to forward shunning and unshunning commands to a single Sensor that then manages a network device. This approach avoids the problem of multiple Sensors continually overriding a network device's configuration, and works the same with either NetSentry- or Cisco IOS-based devices.
A Sensor can have as many entries in its configuration files as there are network devices that need management. The configuration file contains information regarding each router or packet filter's IP address, host name, and password. This information allows the Sensor to communicate with and control each device.
To place a Director on a network, consider the following:
The first requirement is highly recommended. Without a secure physical location, NetRanger's security could be compromised, which could compromise your network's security.
The Director is protected by standard UNIX password mechanisms and the HP OpenView application-level login mechanism.
Additionally, there must be a path between each Sensor and its Director to pass along alarm and command and control messages. If the Director is to be placed behind a proxy firewall or an address translation device that cannot forward traffic on UDP port 45000, then a NetRanger Post Office facility must be loaded onto that device for communication between Sensors and Directors to take place.
Directors can be placed in a tiered structure on your network. With just one Sensor and one Director, the Sensor sends alarms to the Director. In a tiered structure, the Director that receives the alarms sends duplicate alarms to a secondary Director.
This structure is useful for viewing high-level alarms from different points on distributed networks. In another example, Directors on different networks can collect alarms from Sensors and then forward the high-priority alarms to a central Director.
Posted: Wed Jul 19 15:21:38 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.