After discussing Intrusion Detection Systems (IDS) in general, I wanted to take a closer look at Network Intrusion Detection Systems (NIDS). A NIDS sits on a network and monitors traffic in real-time, looking for possible malicious activity. After filtering the traffic and checking it against various signatures, an event is generated and administrators can react. That’s all well and good, but how does the IDS sensor pick up network traffic in the first place? There are various methods to suit different types of environment, budget, and agenda. While simply setting the IDS network adaptor to promiscuous mode would have been sufficient on an older Ethernet network, that doesn’t work so well in switched environments, which don’t broadcast all traffic to all network ports.

Host based

A host based NIDS is one that monitors network traffic on the IP address / switch port of the host system. This can be useful if monitoring an Internet gateway for suspicious traffic passing through the firewall or for monitoring traffic flowing to/from a particular machine. The limitation of host based NIDS is that it has a very narrow view, meaning that warning signals of ongoing reconnaissance or an impending attack may well be overlooked.

Network spanning

Most modern manageable switches give administrators the ability to use a SPAN (Switch Port ANalyser) port. The SPAN port can be configured to mirror traffic on another switch port so that administrators can monitor or analyse the traffic passing through. Depending on the switches’ manufacturer and model, the functionality may vary—I have 3Com switches, which will only allow one port to be mirrored at any one time, where as I also have a Hewlett-Packard switch that allows any number of ports to have their traffic mirrored on the SPAN port. The Netgear switches are somewhere in between, allowing two SPAN ports to be allocated—one that can mirror ports 1-24 and the second covers ports 25-48. Using spanning to mirror traffic on your router/gateway’s switch port would enable traffic to be analysed without making any modifications to the gateway itself nor any other systems—the NIDS would be placed on a spare port, which is then configured to mirror all traffic on the port used by your gateway.

While ease of deployment is a major positive when looking at NIDS implementation, it is not a realistic option for long term deployment. The first problem is that it’s very difficult to monitor more than one port. While the switch may allow spanning of more than one physical port, the amount of traffic that the switch is attempting to copy to the SPAN port can quickly overload the switch and seriously degrade its performance (especially if working in full duplex). If you imagine trying to mirror 4-5 Gigabit ports to a single Gigabit port, then you will instantly grasp the problem; it’s like trying to cut a four lane motorway down to one lane—gridlock. Another thing to consider is that the switch may attempt to correct or even drop bad packets, CRC errors, etc. These could well be crafted to exploit vulnerabilities, but due to the switch’s actions, they may be missed.

Network tapping

A network tap is a pass-through device that allows you to tap into network communications without causing any disruption to the rest of the network. The tap is a simple device (see here http://www.infosecwriters.com/hhworld/hh9/roc/node4.html) that is placed between two network segments which need to be monitored. A small network tap (to monitor one segment) would have four ports; there are in/out ports for the network traffic to flow through and then two tap ports which mirror the traffic. There are two tap ports as the tap monitors traffic in both directions. In order for the NIDS to use this output effectively and track stateful communications, the two channels must be bonded to present the IDS with one unified source. This is easily achieved in a Linux environment, but does require the IDS host to have a network card for each incoming channel.

Almost all commercial network taps fail over in an open state, meaning that if the tap suffers from any type of hardware failure, network traffic will continue to flow through the device in order to cause minimum disruption. Network taps are also passive devices, meaning that they cannot send data back to the network and therefore do not interfere with daily operations and are difficult to detect.

Overall, from the research I have carried out so far, the network tap seems to be favoured by most network admins when it comes to deploying NIDS.

Hub ‘in the middle’

Last (and also least) is the concept of inserting a hub in between network nodes to monitor traffic passing through. The theory is simple: place a standard hub in between the device (let’s say our Internet gateway) and switch. Because hubs broadcast all traffic to all ports, we can also hook a NIDS station on the hub with its interface in promiscuous mode, and it will capture all traffic passing through. This is very cheap, fast to deploy, and requires no special hardware. This configuration has major negative points to consider, however; first, if the gateway and switch are using full duplex then the collisions generated would severely degrade performance. This may be fine for monitoring communications between your Internet gateway and central switch but that depends on the average throughput.

Obviously, which of these models is used depends very much on the network environment, NIDS goals, and budget. The general opinion is that network taps provide the best way of listening in to network traffic in a switched environment, while having no negative impact on performance and reliability. In terms of cost, network taps are not too extortionate; a single link tap of 10/100 standard will set you back around £350 (681 USD) while a 10/100/1000 tap comes in at around £650 (1,265 USD).

I would be interested to hear how readers hook up their NIDS, how potential performance or reliability issues are addressed and generally how Network Intrusion Detection fits in to your infrastructure and communications environment?