Re: [liberationtech] abuse control for Tor exit nodes
On 27 June 2013 05:07, Rich Kulawiec r...@gsp.org wrote: [ Okay, so I have a long-winded response to this. It's possible that eventually I'll wander somewhere near a point. ;-) ] ... ... My suggestion (and this is based on many other kinds of operations since I've never run a Tor exit node) is to do what everyone should do for every operation: use a bidirectional default-deny firewall. Then punch holes in it as necessary to permit desired traffic. Use netflows to detect and squash things like brute-force attacks. (In other words, if you observe a serious spike in outbound ssh connection attempts, then someone is using your node, and possibly others, to conduct an ssh brute-force attack. Rate-limit it. Or just block it for a while.) Another highly useful technique is rate-limiting based on passive OS fingerprinting of the source: one application is to provide severely limited SMTP bandwidth to anything fingerprinting as Windows. Another is to use the Team Cymru bogon list. And still another is to use the Spamhaus DROP list, since nothing good can happen by permitting traffic to/from those network ranges. The pf firewall in various BSD distributions is a good choice for implementing all this. It also has the useful feature of being rather resource-frugal: it's quite impressive how an old/slow box running it can gracefully handle large traffic volumes. This is a very well written argument, thank you. I'd love to see more discussion around the ethics of Should I or Shouldn't I put in (non-logging) abuse filtering on exit nodes. Someone can always disguise abuse. An intelligent DoS attack on an SSL website couldn't be detected by an exit node operator. But, just as moving SSH off port 22 really honest-to-god does eliminate 99% of the crap you'd get otherwise, maybe there are similar cheap wins to be had on Exit Nodes. While there are legitimate reasons to send sqlmap through Tor, I'm currently thinking if you actually want to test something, legitimately, through Tor, using sqlmap - you should be prepared to deal with exit blocking. Exit blocking that could eliminate 50%, 80%, 95% of the crap. I'd love to see people debate this back and forth more and tease out arguments for and against. On the practical side of things, a couple questions. Blacklisting connects *to* the spamhaus list, and other known spammers (as an exit operator) would really only shut down control channels, no?. Similarly, if you're an entry node, you could block connections *from*... but if spammers on the spamhaus blocklist were actually using Tor... well, they wouldn't *be on the blocklist*. I could always be wrong, but I don't see this making big wins. Shutting down SSH brute forcing would be cool. I've joked with my friends There are so many interesting thing in the world, and I have no little time to learn them all. I have to prioritize. So I decided to skip iptables and use a wrapper (shorewall).Do you have, or know of, any simple writeups for doing that, or some of the more complicated suggestions? -tom -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] abuse control for Tor exit nodes
Tom Ritter: On 27 June 2013 05:07, Rich Kulawiec r...@gsp.org wrote: [ Okay, so I have a long-winded response to this. It's possible that eventually I'll wander somewhere near a point. ;-) ] ... ... My suggestion (and this is based on many other kinds of operations since I've never run a Tor exit node) is to do what everyone should do for every operation: use a bidirectional default-deny firewall. Then punch holes in it as necessary to permit desired traffic. Use netflows to detect and squash things like brute-force attacks. (In other words, if you observe a serious spike in outbound ssh connection attempts, then someone is using your node, and possibly others, to conduct an ssh brute-force attack. Rate-limit it. Or just block it for a while.) Another highly useful technique is rate-limiting based on passive OS fingerprinting of the source: one application is to provide severely limited SMTP bandwidth to anything fingerprinting as Windows. Another is to use the Team Cymru bogon list. And still another is to use the Spamhaus DROP list, since nothing good can happen by permitting traffic to/from those network ranges. The pf firewall in various BSD distributions is a good choice for implementing all this. It also has the useful feature of being rather resource-frugal: it's quite impressive how an old/slow box running it can gracefully handle large traffic volumes. This is a very well written argument, thank you. I'd love to see more discussion around the ethics of Should I or Shouldn't I put in (non-logging) abuse filtering on exit nodes. Someone can always disguise abuse. An intelligent DoS attack on an SSL website couldn't be detected by an exit node operator. But, just as moving SSH off port 22 really honest-to-god does eliminate 99% of the crap you'd get otherwise, maybe there are similar cheap wins to be had on Exit Nodes. While there are legitimate reasons to send sqlmap through Tor, I'm currently thinking if you actually want to test something, legitimately, through Tor, using sqlmap - you should be prepared to deal with exit blocking. Exit blocking that could eliminate 50%, 80%, 95% of the crap. I'd love to see people debate this back and forth more and tease out arguments for and against. On the practical side of things, a couple questions. Blacklisting connects *to* the spamhaus list, and other known spammers (as an exit operator) would really only shut down control channels, no?. Similarly, if you're an entry node, you could block connections *from*... but if spammers on the spamhaus blocklist were actually using Tor... well, they wouldn't *be on the blocklist*. I could always be wrong, but I don't see this making big wins. Shutting down SSH brute forcing would be cool. I've joked with my friends There are so many interesting thing in the world, and I have no little time to learn them all. I have to prioritize. So I decided to skip iptables and use a wrapper (shorewall).Do you have, or know of, any simple writeups for doing that, or some of the more complicated suggestions? This argument comes up every so often on tor-relays. Censorship filters, IDS systems, and rate limiting firewalls don't belong on Tor exits anymore than they belong on the core routers of the Internet. They belong on the leaves. Censor yourself, not others. Imagine what would happen if the core routers of the Internet detected abuse with even 99% accuracy (1% false positive rate). The Internet would cease to function, due to the base rate fallacy and the relative infrequency of actual abuse: https://en.wikipedia.org/wiki/Base_rate_fallacy The same math applies to Tor exits. -- Mike Perry -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] abuse control for Tor exit nodes [was: Twitter Underground Market Research - pdf]
On Wed, Jun 05, 2013 at 10:16:23PM -0700, Andy Isaacson wrote: This is a really deeply interesting assertion. You seem to imagine a bright line of abuse that is agreed on by all parties, with a policy that can be implemented by thoughtful operators to make the abuse stop. I submit that that is not the real world, in many different dimensions. [ Okay, so I have a long-winded response to this. It's possible that eventually I'll wander somewhere near a point. ;-) ] Many people who are relatively new to the 'net haven't yet internalized parts of the fundamental ethic that has allowed it to flourish. There is an implicit social contract that's far more important than any formal legal document -- but because it's implicit and not overt, many don't realize that it exists and that it serves a critical function. One way to put it, if I might borrow a line from popular culture, is: With great power, comes great responsibility. Being connected to the Internet gives you incredible power. Not because of who *you* are -- because for all values of you (including me), you are unimportant and expendable. It gives you incredible power because of *everyone else* out there. By plugging in, you have -- whether you realize it or not, whether you acknowledge it or not -- tacitly committed yourself to living up to the responsibility that accompanies the immense power you now have. So like everyone else on the Internet -- from the tiniest single system connected via a slow dialup line, to the largest distributed operation imaginable -- you're responsible for everything your operation does to everything and everyone else. You don't get a free ride. You don't get to pass the blame along. If there's abuse coming from YOUR system on YOUR network on YOUR watch, then it's YOUR abuse. You own it. You're responsible for it. It's always been that way -- and it has to be that way, otherwise the Internet won't work because it can't work. (And if you've been paying attention during the past decade or two, you'll note that many components of the 'net that aren't working very well are struggling for precisely this reason.) Responsible and ethical operations know this and design, budget, plan, train, and staff accordingly. Irresponsible and unethical operations don't -- they just shrug their shoulders and try to slough off their incompetence and negligence on someone else, often the rhetorical they. Now...everyone is probably going to leak a small amount of abuse from time to time. Software breaks. Routers lose their minds. Users do silly things. System admins make typos. Security holes get exploited. Stuff...happens. The expectation is that such incidents should be isolated and sporadic -- and that effective remedial action (where effective remedial action may require the root password and/or wirecutters) will be taken promptly. The reality is that many such incidents are pervasive, sustained and completely unaddressed. And that is why we, for a global value of we, find ourselves defending against myriad forms of abuse, from ssh brute-force attacks to spam. NONE of that abuse just magically falls out of the sky: it all comes from somewhere...and that somewhere is mostly irresponsible, negligent, incompetent operations. Note that this results in massive but silent cost-shifting: someone has to deal with that abuse, because it doesn't just vanish. It goes somewhere. It impacts other networks, systems and people. And the people responsible for defending those need to spend their resources to deal with it, even though they had nothing to do with its origin. The costs of doing so are enormous: just look at the subindustries that exist to sell products to deal with this and consider that every single dollar/euro/yen they ever make comes from someone paying the price for others' negligence. And they're making billions upon billions. Consider, for example, that companies like Cloudflare and Prolexic probably *would not exist* if it weren't for the ongoing epidemic of abuse. Here's another way to phrase that fundamental ethic, also borrowing a line from popular culture: The needs of the many outweigh the needs of the few. No matter how big my operation or your operation or anyone's operation becomes, it will always be the few when compared to the rest of the Internet: the many. No single operation is ever more important than all operations. Not mine, not yours, not Google, not Reddit, not anything. I did say I'd try to get near a point. Alright, here goes: if you run anything, including a Tor exit node, then you are personally, fully responsible for all abuse sourced from that operation. Which means that you are responsible for figuring out how to detect it and stuff a sock in it. Maybe that's easy. Maybe that's hard. Doesn't matter: it's still your responsibility. You signed up for it, you implicitly agreed to it, when you plugged *your* operation into *our* Internet. My suggestion
