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