Re: TOR on Academic networks (problem)

[Mike Perry <mikepery@xxxxxxxxxx>]

Thus spake Tor User (toruser@xxxxxxxxxxxxxx):

> I am not sure if the following would work, but it is what I would try 
> first..
> With a bit of luck someone else can suggest a better solution, or at least
> warn you if mine has an obvious fatal flaw. Anyway, as long as you don't
> mind that it is Linux-specific, and FWIIW:
> 
> You could use iptables to overwrite the destination address to that of a
> local webserver. It would require a large number of rules but might be OK
> for a small amount of traffic. You might put the rules in OUTPUT or
> POSTROUTING, using something along the lines of
> 
> iptables -t nat -A POSTROUTING -p tcp -d <ip of journal> --dport 80 -j DNAT
> --to-destination <ip of you webserver>
> 
> Obviously, the webserver would have to be configured to return the error
> page no matter what the requested URL. You can either implement this on the
> machine running the exit node if it uses linux, or you could put a linux box
> between that machine and the rest of internet.

I would really consider trying to make <ip of your webserver> be
instead <non-trusted IP that will forward traffic> like Anthony
suggested. It shouldn't have to be a very fast IP, since I would guess
journal accesses though your node would be infrequent.

Consider the case where someone needs to do anonymous research using
one of these journal sites, has obtained a pay acccount (or simply
uses bugmenot.. for a while bugmenot had a few Lexis academic accounts
available and may still get new ones on occasion), but then hits your
goofy warning page. It is a massive inconvienience for this person to
have to manually find another exit that might work, or to list your
node as an ExcludeNodes...

At the very least the warning page needs to provide very clear,
newbie-ready instructions, and probably also a link to a torrc they
can download that blocks your exit node from being used (along with
clear instructions on where to put the file).

Still, I would also agree that rejecting *:80 would be the best until
this IP as authentication issue is resolved.

-- 
Mike Perry
Mad Computer Scientist
fscked.org evil labs