IDS bells ringing

[patgus]

 OK.

 As far as the IDS field - I think they do have their place. and if they were more directed at blocking & disregarding a lot of garbage & known attacks instead of trying to report everything, then a lot more data analysis could be performed on the remainder in order to find the "needle in the haystack".
 I am not aware of the amounts of false positives resulting on other larger networks, although in my experience on a small network the number of false positives has been "almost" 0 Most are practically worthless at detecting unknown attacks, unless you have the analyst as you mentioned. 

On Tue, 31 Jan 2006 19:33:02 -0800
Chris Palmer <chris at eff.org> wrote:

> patgus wrote:
> 
> > For instance, a solution similar to hogwash
> 
> Incorporating an IDS into Tor (or just running one alongside Tor) has 
> been proposed before. Nothing can stop Tor server operators from running 
> an IDS on the Tor traffic.
> 
> But doing so has its problems, such as when the Tor exit policy is not 
> the same as that of the IDS (or firewall) the Tor server is subject to. 
> In that case, a server may be falsely advertising its capabilities, to 
> the detriment of the Tor network.
> 
> There is also this comment in the technical FAQ wiki:
> 
> http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#head-ebe87162a46f267eb697e23fb77e85e4cf643dd0
> 
> "Adding an Intrusion Detection System to handle exit policies would 
> increase the security complexity of Tor, and would likely not work 
> anyway, as evidenced by the entire field of IDS and counter-IDS papers. 
> Many potential abuse issues are resolved by the fact that Tor only 
> transports valid TCP streams (as opposed to arbitrary IP including 
> malformed packets and IP floods), so exit policies become even _more_ 
> important as we become able to transport IP packets. We also need to 
> compactly describe exit policies in the Tor directory, so clients can 
> predict which nodes will allow their packets to exit -- and clients need 
> to predict all the packets they will want to send in a session before 
> picking their exit node!"
> 
> I have not read all the literature, but from what I've seen the entire 
> IDS field is close to being discredited. (I could be wrong.) Like spam 
> filtering, automated source code auditing and virus scanning, it's an 
> AI-hard problem. Now, that doesn't mean you can't get good results, but 
> it does mean you need to be a statistics genius with lots of free time, 
> patience, and a very closely specified task domain.
> 
> The cost of failure when applying such tools to transport and network 
> layer data is very high.
> 
> > At least then we could say that we were doing as much as is possible
> > to prevent this and probably as much as any business in the industry.
> 
> I think we already are pretty close to doing as much as is reasonable. 
> Yes, it's *possible* to apply network, transport, content and other 
> layer filters, but it's not at all clear they're worth the cost, 
> complexity, and entertaining new failure modes.
> 
> Tor's exit policies in the hands of a responsible operator, together 
> with reasonable and polite negotiation, have been enough so far. At 
> least they have been in my experience.
> 
> > lol, most risks in the computer industry need to be litigated, not
> > mitigated. 'Tis a bit of a situation though, how do you hold
> > Microsoft responsible without crushing Debian?
> 
> And/or legislated, as the argument goes. This is also a highly 
> problematic proposition. Perhaps you could have some sort of vendor 
> liability law providing a cause of action for when software fails, but 
> with some kind of carve-out for FOSS software. That's a whole can of 
> worms I don't want to get into, but if you want to know some of the 
> potential problems, read up on anti-spyware legislation and proposals 
> for legislation.
> 
>