On 3/5/11 9:21 AM, Mike Perry wrote:
Thus spake Fabio Pietrosanti (naif) (lists@infosecurity.ch):
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