A Guide To IDS Placement (or, How Your IDS Salesperson Has Lied To You)
There is a common belief, even a well-known and accepted “truth” that there is a legitimate reason to place multiple IDS sensors on both sides of a firewall. The wisdom behind this conception is that by doing so, you get a good idea of how well the firewall is working, and good statistical information regarding attacks that don’t make it into the internal networks and servers. This concept is, almost without fail, patently false.
Take a look at a typical IDS deployment scenario:
In this very typical configuration, separate IDS sensors are deployed in front of and behind the firewall, with the hope of catching more information and attacks This approach, on the surface, appears to make perfect attacks. After all, in this configuration the firewall will prevent the majority of attacks on the servers, and these would be completely silent and undetected unless we put a sensor outside the firewall to detect them, right?
Actually, this is not the case, and an IDS outside the firewall provides minimally more information that the IDS behind the firewall. Most of the signatures that IDS can detect rely on TCP, which is a connection-oriented protocol requiring a minimum of three packets to be exchanged before the attack is even possible. In Snort, and open-source IDS, over 1700 of the 2000 signatures are TCP-based. In order for any of these signatures to trip, the firewall must pass the traffic, at which point the inside and outside IDS sensors have the exact same view of the traffic.
So why is this belief so commonly held?
First, there are some attacks that the firewall can prevent that will be detected by the outside sensor. These attacks are based on UDP or ICMP. However, these attacks are much rarer and typically much less likely to be successful than TCP-based attacks, as very few Internet services rely on UDP, and ICMP should typically be limited to a subset of available service types at the firewall. The only major service on the Internet that uses UDP is DNS, and again for these attacks to be successful, the firewall would allow traffic to the known DNS hosts located in the DMZ, where the internal IDS would catch any attacks that have a chance of success.
The second major reason this belief is so common is that most organizations do not monitor their firewall, and use this as a method to try to determine its effectiveness. This falls short on many fronts. If you are interested in what the firewall is dropping, a better place to get that information is from the firewall. An IDS will be able to detect some portscans and other malicious activity that will be stopped at the firewall, but an analysis of the firewall logs makes it possible to detect every attack that the firewall stopped. An IDS must rely on algorithms and passive state tables to determine if a host is being port scanned, and many scans will be missed while many detected scans may actually be due to a down or slow internal host. The firewall has the ability to give a thorough report of any dropped packets, and doesn’t have to try to divine this information off the wire using some half-art/half-science approach. In short, if you want to know what the firewall is doing, ask it.
When does an External IDS Make Sense?
There are times when the ideal placement of an IDS sensor is outside the firewall. If there are many interfaces off the firewall separating traffic into multiple subnets, segments, and VLANs, the outside may be the ideal place for an IDS sensor. This will allow a single sensor to catch all of the traffic that may otherwise require several interfaces, span ports, network taps, etc., this providing a savings of equipment and overall complexity. In this case, however, any traffic between hosts on different DMZ segments will be missed, which may make the detection of a compromised machine more difficult.
What About SSL Traffic?
If the majority of your network traffic is SSL-based, IDS is most likely a waste of money. Several times I’ve seen customers with 100% of their traffic going to an encrypted e-commerce server, and an IDS deployed that has zero value in their organization. When the traffic is encrypted, there is no chance of a signature match, thus negating the need for an IDS at all. In these cases, the customer can deploy either an SSL-aware IDS with a copy of the server’s private certificate or an SSL accelerator to decrypt the traffic before going to the server, and let the IDS monitor the unencrypted traffic. In most cases, the best option is to analyze the server logs directly, as even unencrypted traffic often provides little direct value for custom applications. Only by examining the server log files can non-signature-based attacks be detected (i.e. application attacks, brute-force password attacks, etc.). And in the more complex environments, it is not possible to place IDS sensors in enough locations to catch all of the server traffic. Again, log monitoring is the key to the deficiencies of the IDS technology.