The implementation of network intrusion detection systems involves many subtleties and design elements that must be considered to make the project successful.
One of the most important factors in determining IDS effectiveness is the placement of the sensor interface. In general, the sensor should be placed in a location where the largest amount of suspicious traffic will be seen. In practice, however, the placement of the sensor often faces several challenges:
As such, great care must be taken to ensure the proper position in the network is being monitored, but the risks inherent with any network change are well understood.
Additionally, many customers are often left unprotected with either the spanning fails or when the network topology is adjusted to facilitate troubleshooting (i.e. plug in a Sniffer to troubleshoot a network problem), and it is not restored to its prior state. As such, Solutionary recommends a continual check of the effectiveness of the sensor to ensure it is monitoring the appropriate traffic.
There should be no IP address configured on the sensor port to limit the possibility of compromise of this interface. There are instances where this is not possible, due to incompatibility issues in Ethernet autosense and speed/duplex negotiation. If the sensor port does not link up to the hub/switch, the interface should be configured with a non-routable address[1] not used at the organization, and have a 30-bit mask configured. To force the card to link, simply ping the other host IP on the subnet, forcing the system to send an arp packet to the switch and allowing the autosense to complete.
The location of the management port should be considered a very sensitive decision as well. With the recent Snort vulnerability[2] and the possibility of compromise of the sensor through the sensor port, the location and restrictions placed on the monitor port are more important than ever. If possible, a separate, security management segment should be utilized to isolate the management and alert traffic generated by the sensor. As the sensor also provides the ability to troubleshoot network issues (through the use of Ethereal or other tools), having the management network on a separate physical switch provides an out-of-band connection to troubleshoot and diagnose problems that may be affecting the internal network as a whole (i.e. DDoS attacks, SQLSlammer, etc.). Filtering the traffic inbound to the sensor interface is not nearly as important as filtering traffic coming from the sensor, as the primary concern is limiting the exposure to internal resources should the sensor be compromised.
Inbound filters to the management port should be limited to source IP’s and subnets responsible for management of the device, and only on the necessary protocols/ports. If possible, encrypted communications should always be used (SSHv2, for example). For outbound access from the IDS, filters should be as restrictive as possible, only sending data to the central event collection device.
The tuning of an IDS, and the lengths to which this should be conducted, often generate an almost religious response from network security individuals. The approach Solutionary recommends depends on the scenario involved. There are two main factors involved in the tuning of an ids:
With these two thoughts in mind, Solutionary recommends the following steps when performing IDS tuning:
Many IDS’s offer the option of automatically shunning or blocking traffic as attacks are detected. There are many issues with the implementations of these technologies, and many opportunities for legitimate traffic to be blocked as the result of a malicious attack. In effect, many of these methods make a network susceptible to a denial-of-service attack caused by the IDS itself.
Essentially, the issue comes into detecting a stateful attack. If border routers are blocking IP packets with the source-route flags set, it can be assumed that a source address cannot be spoofed for a connection-based attack. Many IDS’s, however, do not require nor do they track state information when determining if a state-based attack (i.e. TCP-based) has occurred. As a result, it is possible to spoof an address and have that offending address added to the list of ‘non-talkers’, thus causing a denial of legitimate traffic.
In order for automatic blocking to work effectively, the IDS must sit behind a stateful-inspection firewall (i.e. Firewall-1, PIX, etc.) to ensure the traffic is valid, and a spoofed source is not occurring. Otherwise, the dangers of these actions far outweigh the ability of an IDS to respond to and thwart an attack.
As a side note, as the IDS’s are mostly signature-based, applying the necessary patches to the Internet-visible servers provides even better protection than that afforded by auto-blocking techniques.
In order for any IDS data to be useful, it must be consolidated into a single location for analysis. This becomes even truer with multiple sensors in place, especially if different vendors are used. Where possible, syslog provides an inexpensive method for collecting these events, but there are many issues related to syslog that must be considered.
If at all possible, use syslog-ng[3] and TCP-based connections to improve the reliability of event transmission. Regardless of the syslog server used, it is important to disable file sync on the IDS event file, as some OS and file systems can impose a significant overhead when syncing a large file. Additionally, ensure DNS resolution is disabled for inbound IDS messages, or the event consolidator is only configured to use a local hosts file, as DNS lookups are a blocking operation in many syslog implementations and can cause events to be missed.