Speed is not the issue, but sneaking past it is …
Encrypted and encoded traffic has always been one of the troubles for IDS/IPS systems to handle. A vulnerability was disclosed last week, related to the encoding issue, affecting many systems that does some sort of content inspection of the HTTP-protocol. From the advisory:
Full-width and half-width encoding is a technique for encoding Unicode characters. Various HTTP content scanning systems fail to properly scan full-width/half-width Unicode encoded HTTP traffic. By sending specially-crafted HTTP traffic to a vulnerable content scanning system, an attacker may be able to bypass that content scanning system
Systems affected by the vulnerability includes most commercial and “free” IDS/IPS systems, including Snort, Bro, TippingPoint and ISS - and disables their detection/protection for attacks mounted in HTTP-sessions.
Interop (as in: “just another vendor conference”) is currently running at the other side of the pond. This is a conference were its common for vendors to release their new silver-bullet products - and IDS/IPS vendors is not an exception. The strange thing with many of the vendors of IDS/IPS-products, is that they seem to focus on relatively irrelevant features - not on these kind of issues that could increase their ability to detect and actually prevent intrusions. They seem to think that the biggest issue with their technology, or the greatest improvement, is to increase the speed at which the devices can inspect and block traffic. ISS is battling Tippingpoint, who can currently operate their IPS at 5 gbit speeds, with a system that can now run at 15 gbit (which in reality means more like 6 gbit). Still, no body with the intention of buying and IDS/IPS for getting increased security should let speed be deciding factor. These people might just as well look at a an firewall with some sort of novel deep inspection.
22. May 2007 at 19:41
Göran, I thought high speed meant that the IDS does not drop any data. Thus it can detect more intrusions. Is this not the case?
22. May 2007 at 22:41
Well, it depends. In a normal IPS deployment, which is inline, you would typically design the network so that it suits the speeds of the IPS. If the IPS can do 100 mbit, your surrounding network equipment would be configured with 100 mbit full duplex too. This would mean that the sensor would never face traffic above its limit. A good IPS installation as such doesn’t have packet drops. However, if the sensor gets traffic that is over its capacity it is usually a configuration choice between beginning to skipp packets (often indicated as “drops” by the sensor engine), or begin to que packets and eventually drop them at the TCP/IP-level.
When running in IDS mode, passively connected to a tap or a mirrored span port, you don’t have the option of queing packets, which means that its easier to make the sensor skip packets, since you could mirror multiple 100 mbit port to a single 100 mbit-port, or gigabit port.
So basically, supporting higher speeds can guarantee that the sensor doesn’t begin skipping packets (and as such missing attacks). But this shouldn’t be an issue for a correctly placed IDS/IPS. Instead, the increased bandwidth is a sales argument for placement of the sensor in segments where its usually high bandwidths - for instance in the core, between server segments etc. It isn’t obvious that placing the sensor closer to the core enables the IPS to detect or prevent attacks more efficently either…
23. May 2007 at 08:56
OK, maybe it is easier to increase the speed than to increase the number of detected intrusions… And if two vendors have the same product but one of them is faster then it is a sales argument. Maybe it is also easier to show the high speed than other features.