Slashdot Mirror

Everyone who uses a IDS should be required to read: paper

It seems like an interesting product. Doesn't seem overly useful for environments where folks are installing lots of new stuff. But for a production server environment where stuff doesn't change without multiple levels of approval it seems like a cool product. I don't believe the "virtually eliminates false positives" stuff, but I haven't used the product. Just a lot of other IDS' and they all claim to reduce false positives.

It appears to still have the fundamental problem with all IDS' (see this). In summary, without the IDS being aware of minutae of the protocol stack of the target machine, it can't actually detect intrusions, not to mention IDS' can easily be overwhelmed. IMHO IDS' are dangerous, IT folks develop a sense of invulnerability. While they're useful for the run of the mill crap that most kids spew, someone who's committed can open a can and the IDS will just stand around and look dumb. If you're the IT guy who told everyone that they could sleep at night because the IDS was taking care of business, then you look dumb.

> A protocol built on top of UDP could interpret lost packets however it chose to.

The problem is that you'd nevetheless have to use some form of congestion control - i.e., to lower your sending rate when buffers in routers are overflowed. If a major application didn't use congestion control, the Internet would go into congestion collapse as it did in the 80's.


TCP uses packet drops as a sign of congestion. This works well in wired networks where packets seldom are dropped due to bit errors on the links and almost all packets are dropped by routers who's buffers are full. Wireless links on the other hand may have masses of bit errors from time to time, which makes TCP's assumption turn out pretty bad. Of course, it does not matter that it is TCP that makes this assumption; any application using UDP would have to make the same assumption.


The real problem is that there is bad feedback from the network. The end-points cannot know that a packet was dropped due to congestion or to bit errors. ECN (Explicit Congestion Notificaton) is a way to add active congestion feedback, and there are other proposals to add stuff like ELN (Explicit Loss Notification) to the Internet, or at least to add it in those parts of the Internet where wireless links are used.

> A protocol built on top of UDP could interpret lost packets however it chose to.

The problem is that you'd nevetheless have to use some form of congestion control - i.e., to lower your sending rate when buffers in routers are overflowed. If a major application didn't use congestion control, the Internet would go into congestion collapse as it did in the 80's.


TCP uses packet drops as a sign of congestion. This works well in wired networks where packets seldom are dropped due to bit errors on the links and almost all packets are dropped by routers who's buffers are full. Wireless links on the other hand may have masses of bit errors from time to time, which makes TCP's assumption turn out pretty bad. Of course, it does not matter that it is TCP that makes this assumption; any application using UDP would have to make the same assumption.


The real problem is that there is bad feedback from the network. The end-points cannot know that a packet was dropped due to congestion or to bit errors. ECN (Explicit Congestion Notificaton) is a way to add active congestion feedback, and there are other proposals to add stuff like ELN (Explicit Loss Notification) to the Internet, or at least to add it in those parts of the Internet where wireless links are used.

More more details on tests to verify what's happening, see http://www.aciri.org/tbit

- Fzz

In some cases, the problem results from buggy Cisco equipment. They put out a fix to their PIX and Local Director products. More details, including links to Cisco fix, are available on the TBIT homepage.

In some cases, the problem results from buggy Cisco equipment. They put out a fix to their PIX and Local Director products. More details, including links to Cisco fix, are available on the TBIT homepage.

ECN does not require universal adaptation to be helpful: every packet that is marked instead of dropped helps. However, it does require that firewalls stay out of the way to be successful.

The overwhelming majority of network intrusion detection solutions cannot make these claims. They are misuse-detectors --- IDS parlance for systems that do deep analysis of traffic looking for known signatures of misuse. The techniques for detecting these signatures are in fact more intrusive than those for detecting keywords in mail messages. Some IDS tools go so far as to ADVERTISE their utility for monitoring employees and copying email.

The fact that misuse-detectors don't even work (against savvy attackers) doesn't improve the situation (Tim Newsham and I wrote a well-known paper on this, you can find it at Vern Paxson's mirror). The only interesting work in intrusion detection and response is being done at the backbone level, in macro-analysis, using statistical profiling and anomaly detection.

Arbor Networks appears to be leading the pack on the analysis end. There are other interesting companies in this space too --- Asta Networks (tech lead by the inimitable Stefan Savage) appears to be doing direct traceback, and Mazu Networks (the Click Router group from PDOS@MIT, more insanely smart people) appear to be doing edge-based detection and filtering.

Traceback, backbone traffic analysis, and edge-based IP-level traffic/misuse detection are going to be the deployed solution for this problem. Get used to it. Network admins have had many of these capabilities for ages --- these startups are just focussing and optimizing them. You should be more afraid of ISPs deploying RealSecure or NetRanger (privacy-violating point-product misuse systems) than about them guarding their networks with traffic analysis information they could get from their routers already.

PS: Note to Linux geeks --- many of these companies, particularly Mazu, are doing large-scale in-kernel traffic monitoring. They are publishing their code (and some of it, like the Click router, is amazing) and making a HUGE PR contribution to the usefulness of the operating system.

Prior to Guardent's discovery, it was believed that TCP sessions were sufficiently protected from attacks by the random generation of initial sequence numbers. It is now known that these numbers are guessable on many platforms, with a high degree of accuracy.

---
Civilians: Someone set up us the bomb.

The following contains pointers to some of the current work being done to help combat and detect the current forms of DDOS as seen today. In an open and non "patent-pending" manner, too. :)

http://www.aciri.org/pushback/

------------------------------------------------ ------------

1. RFC 2309
describes the need for some kind of proactive congestion control to
deal with protocols that do not implement any kind of backoff. This
proposal spawned a whole lot of research into testing for fairness.
Sally Floyd, one of the authors of the RFC, has the slides (PS) for a
talk which gives a good basic overview of the issues.

2. A standard for congestion control is proposed in RFC 2481. It is easy
to spot abuse by end users who claim to comply with this proposal.

I'll ask about the blacklisting and post here when I have some
references.