Network Intrusion Detection Systems Placement

NIDSs should be located where they can most effectively monitor critical traffic. This doesn’t necessarily mean that NIDSs should be placed where they can monitor the mosttraffic. In Figure 1, an example network is diagrammed. This network consists of a single Internet connection, a DMZ (demilitarized zone), and three internal VLANs, configured for voice users, workstations, and servers. The circular network symbols signify routers or layer 3 switches, while the square network symbols signify layer 2 switches. The five NIDSs are shown as arrowed rectangular boxes.

 
Figure 1: NIDS Locations

In this figure, an NIDS is located on the external side of the firewall to monitor all inbound and outbound Internet traffic. NIDSs are located on internal layer 2 switches in the voice and server VLANs, and on the layer 3 switch that is used to truck these connections. An additional NIDS is situated in the DMZ. In this architecture, the NIDSs will have access to all the network traffic, but are they all really necessary?

Frankly, no. Several of the NIDSs are either redundant or will report so many events as to be meaningless. The external NIDS is unnecessary since it is exposed to the Internet. Even those of you with broadband connections realize that your single IP address is constantly bombarded with exploit probes and port scans. The following is a sample from 30 minutes of scans against a typical home system.

- # tail -f /var/log/messages | egrep -v "repeated"
Oct  3 00:27:33 nsl /kernel: Connection attempt to TCP 192.168.20.20:135 from
24.193.208.77:2258 flags : 0x02
Oct  3 00:30:26 nsl /kernel: Connection attempt to TCP 192.168.20.20:901 from
211.172.40.72:4896 flags : 0x02 swat
Oct  3 00:30:27 nsl /kernel: Connection attempt to TCP 192.168.20.20:901 from
211.172.40.72:4896 flags : 0x02 swat
Oct  3 00:30:58 nsl /kernel: Connection attempt to TCP 192.168.20.20:445 from
83.37.160.160:3400 flags : 0x02
Oct  3 00:31:00 nsl /kernel: Connection attempt to TCP 192.168.20.20:135 from
24.199.122.40:3829 flags : 0x02
Oct  3 00:31:01 nsl /kernel: Connection attempt to TCP 192.168.20.20:135 from
24.199.122.40:3829 flags:0x02,
Oct  3 00:31:01 nsl /kernel: Connection attempt to TCP 192.168.20.20:445 from
83.37.160.160:3400 flags : 0x02
Oct  3 00:31:01 nsl /kernel: Connection attempt to TCP 192.168.20.20:135 from
24.199.122.40:3829 flags : 0x02
Oct  3 00:31:43 nsl /kernel: Connection attempt to UDP 192.168.20.20:137 from
66.63.173.19:1316           netbios-ns
Oct  3 00:31:47 nsl /kernel: Connection attempt to UDP 192.168.20.20:137 from
66.63 .173.19:1316
Oct  3 00:31:54 nsl /kernel: Connection attempt to TCP 192.168.20.20:1433 from
212.33.102.36:2784 flags:0x02 mssql/slammer
Oct  3 00:32:03 nsl /kernel: Connection attempt to UDP 192.168.20.20:137 from
66.63.173.19:1316
Oct  3 00:32:27 nsl /kernel: Connection attempt to UDP 192.168.20.20:137 from
66.63.173.19:1316
Oct  3 00:33:01 nsl /kernel: Connection attempt to UDP 192.168.20.20:137 from
66.63.173.19:1316
Oct  3 00:43:18 nsl /kernel: Connection attempt to TCP 192.168.20.20:445 from
24.199.80.94:1831 flags : 0x02
Oct  3 00:47:55 nsl /kernel: Connection attempt to TCP 192.168.20.20:5000 from
24.84.67.76:4593 flags:0x02 UPnP backdoor
Oct  3 00:47:58 nsl /kernel: Connection attempt to TCP 192.168.20.20:135 from
24.84.67.76:3254 flags : 0x02
Oct  3 00:48:50 nsl /kernel: Connection attempt to TCP 192.168.20.20:4899 from
69.60.111.98:1361 flags:0x02 Radmin exploit
Oct  3 00:49:26 nsl /kernel: Connection attempt to TCP 192.168.20.20:135 from
24.199.105.227:3192 flags : 0x02
Oct  3 00:52:19 nsl /kernel: Connection attempt to TCP 192.168.20.20:5000 from
24.199.230.130:4456 flags : 0x02
Oct  3 00:52:22 nsl /kernel: Connection attempt to TCP 192.168.20.20:135 from
24.199.230.130:4276 flags : 0x02
Oct  3 00:52:22 nsl /kernel: Connection attempt to TCP 192.168.20.20:135 from
24.199.230.130:4276 flags : 0x02
Oct  3 00:55:37 nsl /kernel: Connection attempt to UDP 192.168.20.20:1029 from
203.21.20.30:30065 ICQNuke98
Oct  3 00:55:42 nsl /kernel: Connection attempt to TCP 192.168.20.20:135 from
24.199.105.227:4103 flags : 0x02
Oct  3 00:56:17 nsl /kernel: Connection attempt to TCP 192.168.20.20:135 from
24.167.27.37:2995 flags : 0x02

As you can see, most of this traffic is the result of automated scanning by worms and viruses, or by simple automated scanning tools. In an enterprise environment, where IDS and log data accumulates in copious amounts, these external data can be ignored. It is more important to focus on the events that occur within the firewall perimeter.

The NIDS situated on the layer 2 switches can also be eliminated since this traffic can be monitored at the central layer 3 switch. In addition, the management connection passes through the firewall and may allow an attacker to piggyback into the network if the sensor is compromised. Although there are no hard and fast rules for deploying NIDS, most system administrators deploy them on uplinks and at devices where many VLANs are trunked so that the fewest number of NIDSs can monitor the most traffic. In our sample network, two NIDSs are suitable to monitor most of the network traffic—one NIDS in the DMZ, and one on the central layer 3 switch.

Note that on the layer 3 switch, there are two interesting and separate traffic flows—one on the uplink between the switch and the firewall, and one port that trunks inter VLAN traffic. The choice of how to monitor both traffic flows depends on how the switch-NIDS connection is configured. Two common methods for allowing NIDS access to network traffic are port mirroring (spanning) and the insertion of a tap (we recommend NetOptics taps because they have two power connections and a wide choice of physical interfaces; check them out at www.netoptics.com). Port mirroring, depending upon its configuration, can enable the NIDS to inspect all of the traffic traversing the switch, and is an inexpensive option. However, some vendor’s switches or OS revisions break when port mirroring is enabled. Be sure to check this with your vendor before connecting an NIDS. The second option, a network tap, is more expensive but offloads the mirroring to a separate device. In this simple example network setting, two network taps would have to be used to visualize all of the traffic—one on the uplink, and one on an inter VLAN port.