Deploy relays using hidden exit IP's?
Shouldn't some exit relays (funded or not) be deployed to use an exit IP that is different from it's advertised exit IP in order to prevent a simplistic form of blocking based on scraping the descriptor set? I think this can happen if the default route is out another interface or secondary address. Something of that nature.
Excerpts from grarpamp's message of 2012-10-30 10:20:03 +0100:
Shouldn't some exit relays (funded or not) be deployed to use an exit IP that is different from it's advertised exit IP in order to prevent a simplistic form of blocking based on scraping the descriptor set? I think this can happen if the default route is out another interface or secondary address. Something of that nature.
There are a few exits that do that, IIRC, however, please correct me if I'm wrong, it causes https://check.torproject.org/ to tell the user that they aren't using Tor for their connection. It's one thing having a green onion in your browser bar, another to get confirmation from a service dedicated to only check if the connection is coming from the Tor network ... There's potential for people being quite confused by such a setup. From a usability standpoint, I think it's a bad idea at this point. In regards to solutions for this, I'm wondering if there could be some sort of callback that would drop the connection if it didn't come from a check.torproject.org request? Michael -- http://niij.org/
On Tue, 30 Oct 2012 05:20:03 -0400 grarpamp <grarpamp@gmail.com> wrote:
Shouldn't some exit relays (funded or not) be deployed to use an exit IP that is different from it's advertised exit IP in order to prevent a simplistic form of blocking based on scraping the descriptor set? I think this can happen if the default route is out another interface or secondary address. Something of that nature.
it is part of the system design to make the exit list public: https://www.torproject.org/docs/faq#HideExits
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Shouldn't some exit relays (funded or not) be deployed to use an exit IP that is different from it's advertised exit IP in order to prevent a simplistic form of blocking based on scraping the descriptor set? I think this can happen if the default route is out another interface or secondary address. Something of that nature.
Actually I think this is a great idea and allows Tor to be used when it wasn't possible or painful before. How does the Torproject and the major Tor network operators think about it? -----BEGIN PGP SIGNATURE----- iF4EAREKAAYFAlCws6QACgkQyM26BSNOM7YoUwEAtsrq4+zcKVDMM1mrAz1Up/rC YH6UhTVI3i2bWUQsRxYA/iMVMYJscqKlQgVVVdJcUkkg5T29yIQCD8CWoLHRlaAG =89ZU -----END PGP SIGNATURE-----
On 24.11.2012 12:46, tagnaq wrote:
Shouldn't some exit relays (funded or not) be deployed to use an exit IP that is different from it's advertised exit IP in order to prevent a simplistic form of blocking based on scraping the descriptor set?
I don't think it's a good idea. People are always thankful when I can point them to the bulk exit list and torDNSel. I point out that Tor has a lot of users and not all of them are bad, and urge for a temporary block. Most admins seem to follow that advice. https://check.torproject.org/cgi-bin/TorBulkExitList.py https://www.torproject.org/projects/tordnsel.html.en -- Moritz Bartl https://www.torservers.net/
On Sat, Nov 24, 2012 at 4:24 AM, Moritz Bartl <moritz@torservers.net> wrote:
On 24.11.2012 12:46, tagnaq wrote:
Shouldn't some exit relays (funded or not) be deployed to use an exit IP that is different from it's advertised exit IP in order to prevent a simplistic form of blocking based on scraping the descriptor set?
I don't think it's a good idea. People are always thankful when I can point them to the bulk exit list and torDNSel. I point out that Tor has a lot of users and not all of them are bad, and urge for a temporary block. Most admins seem to follow that advice.
But in the light of "an IP address is not identity" -- is it reasonable to block every user of an IP because one person (or bot) is up to no good? Why do people insist on "stopping" problem behavior at the network layer? --Aaron
https://check.torproject.org/cgi-bin/TorBulkExitList.py https://www.torproject.org/projects/tordnsel.html.en
-- Moritz Bartl https://www.torservers.net/ _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On Sat, 24 Nov 2012 07:44:48 -0800 Aaron <aagbsn@extc.org> wrote:
On Sat, Nov 24, 2012 at 4:24 AM, Moritz Bartl <moritz@torservers.net> wrote:
I don't think it's a good idea. People are always thankful when I can point them to the bulk exit list and torDNSel. I point out that Tor has a lot of users and not all of them are bad, and urge for a temporary block. Most admins seem to follow that advice.
But in the light of "an IP address is not identity" -- is it reasonable to block every user of an IP because one person (or bot) is up to no good? Why do people insist on "stopping" problem behavior at the network layer?
What else do you propose? You have a service which is costing money to run, some idiot is abusing it to the detriment of your genuine users, and the only correlation you can see between connections is that they originate from Tor exit nodes (remember, the point of Tor is that you *can't* establish identity). Sure, you may be able to develop an application level defence against the attack, but that takes time and resources which may not be immediately available. Meanwhile, of course you block the originating network! It's just the same as if you're being flooded by abusive requests all from the same /24: you might not want to permanently block the whole subnet, but you certainly want to mitigate the immediate threat. Sysadmin 101: If you don't do something *now*, you'll regret it tomorrow. Julian -- 3072D/F3A66B3A Julian Yon (2012 General Use) <pgp.2012@jry.me>
What else do you propose? You have a service which is costing money to run, some idiot is abusing it to the detriment of your genuine users, and the only correlation you can see between connections is that they originate from Tor exit nodes (remember, the point of Tor is that you *can't* establish identity). Sure, you may be able to develop an application level defence against the attack, but that takes time and resources which may not be immediately available. Meanwhile, of course you block the originating network! It's just the same as if you're being flooded by abusive requests all from the same /24: you might not want to permanently block the whole subnet, but you certainly want to mitigate the immediate threat. Sysadmin 101: If you don't do something *now*, you'll regret it tomorrow.
they -should- indeed develop an application level defense to the problem. any defense that relies on layer 3 being accurate "identification" is just plain -wrong- (and probably designed by the same dusty nerds that still think smtp is a good idea to keep around ;) if you want to but can't tell your users appart by some other means but the ip address they connect from, your protocol/service sucks and isn't suitable for use on the real internet and needs to go back to the drawing board. its not just "tor" you know, back in the days you just took a dialup number in venezuela and all was fine :P (and you can still do that today ;) as for "attacks" i'd distinguish between actual network attacks (where i don't give a crap if its spoofed or not, just DROP it :P and lets say, people (or bots) using a service "on top" of the actual internet (lets say an online banking system). NOW if your online banking system has such CRAPPY authentication that you need to fall back to ip based blocking them, your online banking system does not belong on the internet in the first place. and the same goes for forum spam, "virusses" (basically crappy written software products (ie: windows) which refuse to fix the exploits ;) etc. tor does one thing: it kinda like urges them to fix their crap :P (now if only there were more exit nodes ;) i'd say, bring on some more protocols like tor and lets have a shakeout of the crap that should not be on the internet/market in the first place. (smtp, windows and other highly vulnerable operating systems and software, crappy forum software, crappy online banks and creditcard systems which think a static username (or even email) and password is hell of a good idea, etc ;) zomg, they use tor to commit fraud/spam/send virusses: no they don't. your own service is at fault there for not being designed with hostile networks like the internet in mind. (and usually the ones spending all their time complaining about it could just fix it with 10 lines of code ;) so yeah, let them all go to hell for all i care :P -- CB3ROB LTD. ======================== DEDICATED SERVER FARMS IP TRANSIT SERVICES DATACENTER FACILITIES ======================== SKYPE: CB3ROB ========================
Julian
-- 3072D/F3A66B3A Julian Yon (2012 General Use) <pgp.2012@jry.me>
On Tue, Nov 27, 2012 at 1:58 AM, Sven Olaf Kamphuis <sven@cb3rob.net> wrote:
What else do you propose? You have a service which is costing money to run, some idiot is abusing it to the detriment of your genuine users, and the only correlation you can see between connections is that they originate from Tor exit nodes (remember, the point of Tor is that you *can't* establish identity). Sure, you may be able to develop an application level defence against the attack, but that takes time and resources which may not be immediately available. Meanwhile, of course you block the originating network! It's just the same as if you're being flooded by abusive requests all from the same /24: you might not want to permanently block the whole subnet, but you certainly want to mitigate the immediate threat. Sysadmin 101: If you don't do something *now*, you'll regret it tomorrow.
That certainly seems like a reasonable way to handle abuse in the short term.
they -should- indeed develop an application level defense to the problem. any defense that relies on layer 3 being accurate "identification" is just plain -wrong- (and probably designed by the same dusty nerds that still think smtp is a good idea to keep around ;)
Indeed, especially as IPv6 hands a user near infinite "identification" at layer 3.
if you want to but can't tell your users appart by some other means but the ip address they connect from, your protocol/service sucks and isn't suitable for use on the real internet and needs to go back to the drawing board.
its not just "tor" you know, back in the days you just took a dialup number in venezuela and all was fine :P (and you can still do that today ;)
as for "attacks" i'd distinguish between actual network attacks (where i don't give a crap if its spoofed or not, just DROP it :P
and lets say, people (or bots) using a service "on top" of the actual internet (lets say an online banking system).
NOW if your online banking system has such CRAPPY authentication that you need to fall back to ip based blocking them, your online banking system does not belong on the internet in the first place.
and the same goes for forum spam, "virusses" (basically crappy written software products (ie: windows) which refuse to fix the exploits ;) etc.
tor does one thing: it kinda like urges them to fix their crap :P (now if only there were more exit nodes ;)
well, only as much as any obvious attack would.
i'd say, bring on some more protocols like tor and lets have a shakeout of the crap that should not be on the internet/market in the first place.
You don't need Tor or any proxies to break stuff. Blocking Tor won't stop this from happening, and it's already happening.
(smtp, windows and other highly vulnerable operating systems and software, crappy forum software, crappy online banks and creditcard systems which think a static username (or even email) and password is hell of a good idea, etc ;)
zomg, they use tor to commit fraud/spam/send virusses: no they don't. your own service is at fault there for not being designed with hostile networks like the internet in mind.
(and usually the ones spending all their time complaining about it could just fix it with 10 lines of code ;)
so yeah, let them all go to hell for all i care :P
even legacy protocols could be protected by rate limiting the requests handled per address. With only ~1000 exit addresses, the Tor network is far smaller than commercially available off-the-shelf botnets. An attack that degrades service to your users and costs you money would run much better on a botnet, because botnets don't provide membership lists (Tor does). So any service that takes itself seriously ought to consider how good their systems are if they can't even handle random sketchoids abusing Tor. and yes, you do lose users when you block Tor, --Aaron
--
CB3ROB LTD. ======================== DEDICATED SERVER FARMS IP TRANSIT SERVICES DATACENTER FACILITIES ======================== SKYPE: CB3ROB ========================
Julian
-- 3072D/F3A66B3A Julian Yon (2012 General Use) <pgp.2012@jry.me>
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On Tue, 27 Nov 2012 01:58:40 +0000 (UTC) Sven Olaf Kamphuis <sven@cb3rob.net> wrote:
[Utopian fantasy]
Meanwhile, back in the Real World, ancient protocols like SMTP dominate the Internet (oh look, you used it to post to this list) and people do what they have to in order to keep their services running. Perhaps you've never worked on a project large enough that network ops and development are handled by separate teams, but in such an environment a sysadmin who allowed the servers to fall over because they believed it was dev's responsibility would quickly find herself out of a job. Tor won't benefit from that person's career suicide. Whereas giving admins the power to implement an easy kill switch (by blocking the exits when they need to) makes Tor a much less attractive prospect for those who would abuse the network. If you can run your attack over Tor, knowing you can be blocked easily, or over some botnet, which would you choose? This means more bandwidth for the rest of us, and fewer abuse complaints for exit operators. I'd say that's a win. Of course, some organisations (I'm looking at Wikipedia) have a problem with Tor that is due to policy, not technology. Is their policy right? Of course not - the impressive level of vandalism that happens anyway proves that (although CluebotNG has an equally impressive catch rate, it has to be said). But unless you're the one paying for and running the infrastructure of that free-as-in-beer service, what right do you have to say “let them all go to hell”? Do you say the same about people who run relays whose exit policies don't allow your traffic? Do you curse at your neighbour whose unencrypted wireless network doesn't allow connections to your favourite porn site? Seriously, get some perspective. Nobody's going to listen if you're rude to/about them. They're more likely to just dig in their heels and erect another barrier. People do what they feel they must to protect what they (are being paid to) care about. Being open about where the exits are is one way of saying “look, we're all friends”. Conversely, making a serious effort to circumvent their blocks by using unpublished exit addresses will simply create another game of Cat & Mouse, just like the one being played with bridge relays. Sites like Wikipedia, who have made at least some token efforts to come to a solution which works for Tor, will stop trying at all because it will no longer be possible to distinguish Tor exit traffic from other non-authenticated connections. As you can see I've made the effort to write in real sentences, use capital letters and avoid “zomg”. I won't do so a second time, because if I haven't convinced you by now I'm not going to. By all means continue daydreaming, just remember that's what it is. If you want your utopia to eventually exist, you have to start with reality. You can't just will it into existence. Julian -- 3072D/F3A66B3A Julian Yon (2012 General Use) <pgp.2012@jry.me>
I have a real world example of this. My forum was being abused by several users all originating from the Tor network, so the first thing I did (and any sane admin would do) was block Tor access (with a note) for a few hours while I figured out what to do. I ended up unbloacking the network and showing Tor users a low-fi version of the forum, and not letting them sign in without captcha (a simple qualitative question) - reducing load and spam. But something must be done temporally, I agree that Tor users shouldn't be blocked permanently but quiet is needed in order to implement a solution and to get that quiet you need to block at network level, then you can begin a more permanent mitigation plan.
I have the opposite problem in a way. I use geocaching.org frequently. But because they have had a problem in the past with Tor users they block Tor nodes. As I run a Relay, not Exit, this means that I have to ask for an exception every time my IP changes Happily that doesn't happen very often but it is surly a pain when it does. Is there a way for someone to distinguish real and exit IPs? If so I'll try to educate them. Bill W On Tue, Nov 27, 2012 at 1:15 PM, Daniel Case <danielcase10@gmail.com> wrote:
I have a real world example of this. My forum was being abused by several users all originating from the Tor network, so the first thing I did (and any sane admin would do) was block Tor access (with a note) for a few hours while I figured out what to do. I ended up unbloacking the network and showing Tor users a low-fi version of the forum, and not letting them sign in without captcha (a simple qualitative question) - reducing load and spam.
But something must be done temporally, I agree that Tor users shouldn't be blocked permanently but quiet is needed in order to implement a solution and to get that quiet you need to block at network level, then you can begin a more permanent mitigation plan.
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On Tue, 27 Nov 2012 18:42:56 -0500 Bill Waggoner <ctgreybeard@gmail.com> wrote:
I have the opposite problem in a way. I use geocaching.org frequently. But because they have had a problem in the past with Tor users they block Tor nodes. As I run a Relay, not Exit, this means that I have to ask for an exception every time my IP changes Happily that doesn't happen very often but it is surly a pain when it does.
Is there a way for someone to distinguish real and exit IPs? If so I'll try to educate them.
Yes. As per Moritz's contribution to this thread:
People are always thankful when I can point them to the bulk exit list and torDNSel. I point out that Tor has a lot of users and not all of them are bad, and urge for a temporary block. Most admins seem to follow that advice.
https://check.torproject.org/cgi-bin/TorBulkExitList.py https://www.torproject.org/projects/tordnsel.html.en
If they want to implement blocking of Tor exit relays, these tools can help them to do that. Julian -- 3072D/F3A66B3A Julian Yon (2012 General Use) <pgp.2012@jry.me>
It would just seem really frustrating for users who want to participate in account based sites (and really, what sites aren't) to find themselves kneejerk blocked at the network level. Tor is slow, there's really no claim to be made that Tor is capable of literally DoSing a site. Only one for cranks and spam and abuse. For which higher layer filters/moderation can work, as does simply closing the offending account. So when a way of running an exit appears, such as perhaps this one, that might mitigate against the kneejerk for those 'good' users that care to find them... myself, I'd tend to give the world the benefit of the doubt and run one [1]. It's not like anyone who already disbelieves in Tor/anon/etc enough to block it is going to donate to Tor for providing a nice [DNS/consensus] blocklist or stand up amongst their peers and say 'Tor is some really nice guys'. As a site admin, Tor is but a speck of trouble compared to the rest of the IP space. Put yourself in the shoes of a public service... Facebook, Gmail, forum, whatever... though Tor might bring some rarer serious issues, that's nothing compared to the ticket counts of the general moronic public. [1] Caveat testing to be done regarding proof for those needing it via Exonerator, etc.
Also related, has anyone tried operating an exit behind a VPN/NAT/proxy service? As opposed to having secondary interfaces/routes on the local machine.
participants (10)
-
Aaron -
Bill Waggoner -
Daniel Case -
grarpamp -
Julian Yon -
k e bera -
Michael Zeltner -
Moritz Bartl -
Sven Olaf Kamphuis -
tagnaq