|
|
This chapter contains the following sections:
The following scenario might be a fairly typical occurrence at a company deploying intrusion detection technology for the first time. Not long after purchasing and installing a network-based IDS on an internal network segment, security personnel notice a barrage of alarms on the management console. These alarms provide a frightening picture of the state of the network segment's security. Apparently, there are ping sweeps, port scans, DNS queries, registry hacks, and attempts to mount remote drives occurring on the network.
After further analysis, however, the network security personnel discover that several hosts running Windows NT and HP OpenView are the cause of the ping sweeps and "registry hacks." This is all expected behavior and does not constitute a security threat---or what is known as false positives. The IDS rules need to be tuned to minimize alarms from these sources.
The other occurrences are less benign. The port scans, DNS queries, and the drive mounting attempts are coming from outside the protected segment; in fact, from a common source across the Internet. Checking with the InterNIC, the security personnel discover that the attacking network is owned by a business competitor.
The security manager is called in to confer on possible plans of action, and no doubt, the following questions come up:
Very quickly, the security personnel begin to see the need not only for network analysis (this would have helped them identify possible false positives), but also for operational procedures in case of an incident. Intrusion detection brings new security capabilities, and along with these capabilities comes knowledge of what occurs in the data stream and the liability of having to act on the new knowledge.
Building, maintaining, and retaining a cadre of trained security personnel who can respond effectively to security incidents is a serious commitment of time and resources. For many organizations, this is too much of a commitment. Maybe the best option is to install IDS components on the network and outsource the monitoring and response functions.
As you can see, implementing intrusion detection on your network requires some forethought. This chapter seeks to address these issues and questions to better help organizations deploy intrusion detection technology.
This section discusses the following topics:
The Cisco security solution is based on an operational perspective rather than on separate products or policies. This security philosophy is reflected in the image of the Security Wheel (as shown in Figure 2-1). The premise of this philosophy is that like network management, security management is a dynamic, ever-changing process.
Step 1 Develop a strong security policy.
Step 2 Secure the network.
Step 3 Monitor the network and respond to attacks.
Step 4 Test existing security safeguards.
Step 5 Manage and improve corporate security.
The results or data obtained in Steps 2 through 5 always need to be compared to the security policy developed in Step 1 to ensure that high-level security objectives are being met.
The remainder of this chapter provides detailed explanations for each of these steps.
To develop a strong security policy, you need to take into account the following issues:
A strong security policy should be clearly defined, implemented, and documented, yet simple enough that users can easily go about their business within its parameters. A policy of strong password creation does no good if users consistently choose weak passwords and there is no system in place to validate password choices.
In many ways the security policy is a risk management plan---it documents the risk threshold an organization is willing to accept. Because no security technology provides 100 percent protection, and in most cases organizations do not have the budget to implement all the security elements required, the security policy rates assets and applies commensurable levels of security.
A critical element often overlooked is the policy on incident response. What is the official organization response if a policy is violated?
After developing a security policy, secure your network using a variety of point products (firewalls, intrusion detection, etc.). Before you can secure your network, however, you need to combine your understanding of your users, the assets needing protection, and the network's topology.
This section discusses the following topics:
To help prevent possible miscalculations in deploying and configuring an IDS, you should carefully examine these aspects of your network:
Consideration of these points will help you determine the number of sensors required, the hardware configuration for each sensor (for example, the capacity and type of network interface cards), and the number of management consoles needed.
The NetRanger 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-2.
1. In location one, the NetRanger 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.
Because many companies use a firewall to help protect a network perimeter, there are several options for placing a Sensor in relation to the firewall. 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 the network, as this traffic is behind the firewall. 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, if the firewall is configured to deny passage of ping sweeps, then the Sensor would not detect this activity or generate any alarms.
The solution is to take advantage of the Sensor's two interfaces: place the Sensor's monitoring interface (which runs in promiscuous mode without an IP address) directly in front of 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-3.
For the Sensor to effectively defend a network using the router and firewall configuration, you must do the following:
(a) Enable Telnet services on the router.
(a) Add the router to the Sensor's device management list.
(a) Configure the firewall to allow Telnet traffic from the Sensor's primary interface to the router; syslog (UDP port 514) traffic from the router to the Sensor; and NetRanger communications (UDP port 45000) between the Sensor and any Director, if the firewall comes between them.
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. Because the Sensor's monitoring NIC has no IP address, it can not be detected, nor can packets be sent to it.
2. 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.
3. 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.
4. In location four, the Sensor is monitoring an intranet connection. The protected network in this case is a research and development network containing proprietary engineering information requiring additional security.
The Cisco IOS IDS feature of the IOS Firewall Feature Set bundled on certain Cisco routers makes for an ideal, lightweight, perimeter intrusion detection defense. Because Cisco IOS IDS contains only a subset of signatures found on the NetRanger Sensor, it will not detect all attacks, but combined with strong access control lists and a firewall, it should provide a fairly robust security service.
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 and Cisco IOS IDS component maintains a security policy configured for the segment it is monitoring. These can be standard across the organization or unique for each IDS sensor device. 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 IDS sensors required to protect the desired network.
The next step in protecting your network is understanding how the NetRanger Sensor and Cisco IOS IDS component captures network traffic. We will discuss the NetRanger Sensor first, and then Cisco IOS IDS.
Each NetRanger 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 monitoring interface can currently monitor Ethernet, Fast Ethernet, FDDI, and Token Ring segments (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 NetRanger 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:
There are some fundamental differences between Cisco IOS IDS and the NetRanger Sensor. First, Cisco IOS IDS is an in-line device, and will therefore have an impact on network throughput. Second, the procedure for detecting alarms is slightly different from the NetRanger Sensor.
The Cisco IOS IDS signature-matching procedure is as follows:
1. You create an audit rule, which specifies the signatures that should be applied to packet traffic and the actions to take when a match is found. The signature list can have just one signature, all signatures, or any number of signatures in between. Signatures can be disabled in case of false positives or the needs of the network environment.
2. You apply the audit rule to an interface on the router, specifying a traffic direction (in or out).
3. If the audit rule is applied to the in direction on the interface, packets passing through the interface are audited before the inbound ACL has a chance to discard them. This allows an administrator to be alerted if an attack or information-gathering activity is underway even if the router would normally reject the activity.
4. If the audit rule is applied to the out direction on the interface, packets are audited after they enter the router through another interface. In this case, the inbound ACL of the other interface may discard packets before they are audited. This may result in the loss of IDS alarms even though the attack or information-gathering activity was thwarted.
5. Packets going through the interface that match the audit rule are audited by a series of modules, starting with IP; then either ICMP, TCP, or UDP (as appropriate); and finally, the Application level.
6. If a signature match is found in a module, then the following user-configured action(s) occur:
If there are multiple signature matches in a module, only the first match fires an action. Additional matches in other modules fire additional alarms, but only one per module.
Once the network has been secured, monitor activity on the network with the NetRanger Director, which can receive security information from NetRanger Sensors and Cisco IOS IDS.
When security incidents occur, respond appropriately. With both NetRanger and Cisco IOS IDS, you can take a variety of actions, such as logging the event, resetting the TCP connection, dropping the offending packets, and dynamically reconfiguring a router's ACLs to shun the attacker. These types of responses need to match the security policy.
Use NetSonar to periodically scan the network for new vulnerabilities. In a growing, changing network environment, new "security holes" are inevitable. Find the vulnerabilities before an attacker does. Vulnerabilities may arise because of new systems or networks. You will also need to test new security products on the network, including NetRanger Sensors, firewalls, access control lists, etc.
Analyze all the metrics you have obtained through the other parts of the security cycle and keep abreast of any new network threats by improving your network security policy. Continue implementing the Security Wheel cycle.
Posted: Wed Aug 4 09:13:13 PDT 1999
Copyright 1989-1999©Cisco Systems Inc.