A NIDS consists of sensors, or monitors, placed at strategic locations in a network. These sensors can send information about the network back to a central management system. When placed properly, a NIDS can provide visibility into all network activity.
Placement of sensors
Traditionally, NIDS sensors have not been fast enough to be placed inline. In other words, network traffic forced to flow through an NIDS on its way to a target device is likely to experience significant latency. So, NIDS sensors are typically connected to a network through the use of Switched Port Analyzer (SPAN) connections or taps.
A switch sends non-broadcast packets out the port to which the target device is attached. If you simply plug a sensor into a switch port, or to a hub connected to the port, it will only see the packets sent out that port. To correct this, you can configure one of the ports as a SPAN port. Copies of all packets traveling through the switch will be forwarded out the SPAN port and available to the sensor.
A problem with SPAN ports is the possibility that the bandwidth of the configured port may not be sufficient to handle all the traffic passing through the switch. For example, if you are using a 24 port, 100 Mbps Ethernet switch, the SPAN port will likely be able to handle a maximum of 100 Mbps. So what happens if the other 23 ports are only 10% utilized? That's 230 Mbps of traffic attempting to squeeze through a 100 Mbps pipe. The switch is likely to drop packets, resulting in the sensor presenting an incomplete picture of switch traffic.
One solution to the bandwidth problem is the use of a 1 Gbps switch port as the SPAN port. Another solution is to configure multiple SPAN ports. Then aggregate data ports to each SPAN port in a way that guarantees sufficient bandwidth.
If you're only interested in analyzing packets passing through a single switch port, a tap might be the answer. A tap is a device placed inline with the packets you want to analyze. In a very simple implementation, a hub can be a tap. Since all packets entering a hub are sent out all the hub's ports, connecting a sensor to one of the ports results in all packets traveling to the sensor for analysis. The problem with using a hub is the lack of resiliency. If the hub in Figure 1 fails, all traffic traveling between the router and the switch will stop until the hub is repaired or replaced.
A device designed specifically to serve as a tap can provide the resiliency most business networks require. You can configure it to fail open. In other words, packets will continue to flow between the router and switch even if the tap fails.
Whether you use a tap or a SPAN port, you have to decide what it is you plan to monitor. Some placement ideas include:
- Placing a sensor outside your perimeter firewall. This provides visibility into the types of attacks hitting your perimeter. An analysis of these attack characteristics can assist you in assessing and minimizing your vulnerabilities.
- Placing a sensor in your DMZ. An analysis of traffic in your DMZ can help detect attack attempts that have penetrated the outer perimeter before they have the opportunity to gain access to your internal network.
- Placing a sensor at the entrance to a network segment. It's a good idea to understand whether unusual traffic is moving in or out of the network segments that contain your most sensitive data.
Once you've placed your sensors, they can use signature detection, anomaly detection, or both to identify attacks against your information assets.
When using signature detection, a NIDS looks for byte patterns in packets or packet sequences that are common to known attacks. When there is a signature match, the NIDS logs the event. In most cases, companies set up the NIDS to send an alert when a possible attack is logged.
The key advantage of signature detection methods is the ease with which signatures can be developed if you know what you're looking for. In addition, signature detection might require less overhead on your monitoring devices; this depends on the number of signatures you want to analyze. NIDS vendors normally provide a means to select whether you want to check for all or just specific attacks.
Because signatures must be developed for each known attack, there is usually a delay between the time an attack is released into the wild and the time a signature is provided by your NIDS vendor. This is a disadvantage when defending against attacks during the first few hours or days after their release. Another disadvantage is the potential for a high number of false positives. A false positive results when a NIDS logs an attack, but an attack is not actually occurring. In some cases, signature patterns related to known attacks might appear regularly in perfectly normal traffic. Finally, in today's malware environment, threat agents, both human and malware, are capable of changing their characteristics both between and during attacks.
These disadvantages shouldn't stop you from deploying signature based detection methods. However, you should consider supplementing them with anomaly detection.
Using a NIDS for anomaly detection starts with a baseline of your network's behavior. Comparing later traffic to the baseline, the NIDS looks for statistical deviations from the network's normal operation. It also looks for unusual or incorrect packet configurations. Since anomaly detection methods are not dependent on attack signatures, they can detect attacks well before your NIDS or anti-malware vendors release an update to combat a new threat.
One disadvantage of anomaly detection is the difficulty often experienced in setting up rules the NIDS uses to assess what is and what is not characteristic of an attack. Although many devices are shipped with some predefined rules, it's rare that an organization implementing a NIDS doesn't have to tweak them a little. Each network is unique. Another disadvantage is the number of false negatives that can result when attacks do not cause a significant change to network behavior.
If you decide to implement a NIDS, it's a good idea to consider using both detection methods to analyze network traffic. One method helps to mitigate the weaknesses in the other.
Current NIDS technology is capable of blocking attacks. One way to quickly react to detected attacks is to cause your NIDS to build packets intended to drop the connection over which the attack is occurring. Another method is to configure your NIDS to automatically reconfigure a router or firewall to prevent the flow of packets from the identified source of an attack. The advantage of using these methods is the elimination of the delay inherent in human reaction to NIDS attack alerts. This might reduce business impact, but criminals have figured out how to use these methods against you.
The right combination of specially formed packets sent by an attacker can cause your NIDS to view traffic coming from valid sources as attacks. If your NIDS is configured to do so, it will shut down all traffic associated with these sites; this effectively results in a denial of service attack. This doesn't mean you shouldn't consider using this technology; just be sure you understand its possible shortcomings.
So why use NIDS?
Although NIDS may not be the best answer for preventing intrusions into your network, it can offer a low cost solution for identifying the who, what, when, where, and how of an attack. Armed with this information, you can take steps to either eliminate or mitigate the probability of another attack as well as the level of business impact. Two ways to accomplish this are sanctions and control modification.
An effective security program includes well-defined sanctions and controls. Knowing who is responsible for intentional or unintentional network incidents allows management to deal with the human factor through additional training, counseling, or other more stringent means. Knowing what happened, when it happened, and how the attack was initiated can assist in strengthening appropriate administrative, physical, or logical controls.