[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: IDS bells ringing
- To: or-talk@xxxxxxxxxxxxx
- Subject: Re: IDS bells ringing
- From: patgus <patgus@xxxxxxxxxxxxxxx>
- Date: Tue, 31 Jan 2006 22:57:09 -0600
- Delivered-to: archiver@seul.org
- Delivered-to: or-talk-outgoing@seul.org
- Delivered-to: or-talk@seul.org
- Delivery-date: Wed, 01 Feb 2006 00:00:59 -0500
- In-reply-to: <43E02BEE.5050907@eff.org>
- References: <20060131190207.409a39a3.patgus@stonewwwall.org> <928946aa0601311720m3c05d7e2oc3c23accbb398819@mail.gmail.com> <20060131193858.6ab544e2.patgus@stonewwwall.org> <43E015CC.5080809@eff.org> <20060131202140.2e80d351.patgus@stonewwwall.org> <43E02BEE.5050907@eff.org>
- Reply-to: or-talk@xxxxxxxxxxxxx
- Sender: owner-or-talk@xxxxxxxxxxxxx
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@xxxxxxx> 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.
>
>