Re: [tor-relays] Filtering at Exit Node [was: Network Scan through Tor Exit Node (Port 80)]

["Fabio Pietrosanti (naif)" <lists@xxxxxxxxxxxxxxx>]

On 3/5/11 9:21 AM, Mike Perry wrote:
> Thus spake Fabio Pietrosanti (naif) (lists@xxxxxxxxxxxxxxx):
> 
>> So still my goal is to test, implement, document and create howto to:
>>
>> - Block P2P to avoid P2P related claims
> 
> Did you try doing this without doing iptables DPI? The Reduced Exit
> Policy should work fine for this by itself. 
> 
> DPI killing P2P connections is the least of my worries with your
> approach, though.. I feel like your node is a minefield of accidental
> censorship just waiting to explode on innocent users..

You are right that there's a risk of blocking traffic of innocent users.
Now it's just some early testing trying to refine the idea, i fully
agree that the approach must be as finely tuned and as precise as
possible in order just to drop the annoying things while leaving
'everything allowed'.

For example to be able to apply a transparent proxy to try to detect
bruteforce/web attacks in a effective it's required to patch TOR to be
able to bind the TOR Exit IP to a Virtual IP address.
Now there's no way to verify what's HTTP traffic on port 80 and what's
not, so if you put a transparent proxy in the middle you would break
part of the TOR node traffic.

Unfortunately i'm not that skilled at c coding, if someone would like to
do such a patch it would be cool.

Being able to bind to a dedicated IP address for TOR-Exit traffic would
allow also a TOR-maintainer to tunnel his Exit Traffic trough a VPN, or
even to route different kind of traffic trough different systems with
proper IP policy routing.



> 
>> - Block Portscan to avoid portscan related claims
> 
> I would be really surprised if this does not end up causing massive
> collateral damage to just about everything running through your exit
> node. Please keep a close eye on how often this goes off on killing
> sprees. I'm going to guess most of the time it will just end up
> censoring popular sites and dense colo facilities that happen to
> attract heavy amounts of legit Tor traffic.

Sure, now i tried it for 1 week with very bad results:
From 500k up to 1000k connection blocked per day.

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
_______________________________________________
tor-relays mailing list
tor-relays@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays