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..
- 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.
- 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.
- 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.
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.
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.