No subject


Mon Feb 21 22:58:58 UTC 2011


Unfortunately this method is absolutely not good, i disabled it.

The issue of detecting and blocking outgoing portscan remain open and
till now i am not able to block it with iptables.

Question to the list:
How to implement some hackish techniques to block outgoing portscan from
the exit node?
I tried everything with iptables but without success!

> 
>> - Block web attacks to avoid web attacks related claims
> 
> I think that Mortiz is right, you're unlikely to stop most of the
> annoying web shit you get with snort. By complaint volume, it's mostly
> comment spam. I suppose there are worm probes and such it might catch,
> but snort seems unlikely to stop very dumb attacks, nor very
> sophisticated ones.
> 
> It does seem likely to censor random docs about computer security, as
> well as computer security mailinglists. I suppose it depends on which
> rules you enable, though.

Maybe snort will not be the right tool, but eventually some other
approach like using modproxy+modsecurity with a transparent proxy for
web attacks and properly finely tuned rules.

Detecting brute force, known attack pattern related to SQL injection
should be easier.

Detecting comment spam sounds a little bit more complex, but it would be
also very useful for tor-exit node maintainer.
Any idea on which tricks to try to implement comment spamming filters?

> 
>> - Block traffic going to the country where i live to avoid stupid
>> prosecutor causing me 5-10 years of legal trouble
> 
> Tor actually does have some slightly more sophisticated machinery
> already in place to communicate this sort of filtering to clients..
> Tor nodes can send "EXITPOLICY" reason codes when they close streams
> that got created to them despite being forbidden by their exit policy.
> Clients would then automatically retry on a different circuit.
> 
> This would work for your country blocking. It would make Italian sites
> slower for Tor users who chose your node, but at least it wouldn't
> effectively censor them.
> 
> However, it is not possible to do this EXITPOLICY rejection code once
> data has already begun flowing on the tcp stream, because at that
> point it is up to the application to retry, not Tor. In otherwords,
> this technique won't work for DPI.

I know that the DPI approach it's not clean, but still it's not possible
with current TOR to do country black/whitelisting.

To properly implement this we would really need to be able to:
a) OR load-up ExitPolicy with 3-5k lines
b) OR implement some geo-ip logic in the cached-descriptors

It will not be in both case a perfect implementation (i have an italian
registered netblock configured on a swiss provider in switzerland) but
still provide a good level of protection for who can stay in such kind
of conditions.

> 
>> Yes, i understand that this is outside the concept of *perfect freedom*
>> related to TOR, but still it would be an answer to the many persons that
>> would be happy to run an Exit Node to support freedom of speech limiting
>> their risks, personal feeling and effort for maintance and running a TOR
>> node.
> 
> I think you're right, and we should suport this idea where we can.
> However, we *must* find ways to do this that are 100% transparent to
> users. If a user experiences censorship because of this, we're doing
> it wrong, and such a node should be BadExited.
> 
> I think your approaches here are going to lead to situations where
> users who try to view legitimate content are going to become randomly
> censored through your node and not understand why. I don't think this
> is acceptable.

Fully agree.
The methods being implemented now are very rough and the most important
improvement would come when i'll be able to cleanly transparent proxy
the TOR web traffic.

For example on the basis of your idea maybe it would be also possible to
inject some javascript that connect to ControlPort and issue a NewNym to
automatically allow the Client to go trough another node while telling
to the client what's happening, or instead of blocking just
re-tunnelling the request inside TOR (doubling the latency of such
specific circuit/request) ?

Again there's no simple idea, i will try to rationalize all such
discussion on a Wiki one of those days.

It would be fine to try to collect all the consideration (good and bad)
related to filtering at TOR exit node.

> It might be *barely* acceptable if it didn't happen very often, and
> when it did, you somehow redirected users to a web page that gave them
> instructions on how to use the "New Identity" button to avoid your
> exit.. I doubt this is possible in all cases, and I'm still not
> sure it's a valid solution.
> 
> 
> P.S. Is your contact email correct for the node? Otherwise, as soon as
> the Tor Exit Scanner notices anything fishy from your node, you will be
> BadExited without notice.

Sure, everything properly setup, just now i have the node hibernated
that should resurrect today (i have a 1TB/month bandwidth with weekly
quota configured).

Which are the kind of control applied by Tor Exit Scanner?
I mean, my node is not doing SSL MITM or stuff like that, the traffic
"blocked" is very reduced compared to the amount of traffic that get trough.

-naif
http://infosecurity.ch


More information about the tor-relays mailing list