-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 4/29/2014 1:31 AM, I wrote:
One VPS company has just asserted that SSH scans are being run from my Tor exit rather than another process on the VPS. Is this happening to anyone else? Does anyone know what can be done to stop it?
Robert
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Could you explain with more details? Your question is not totally clear.
If your VPS is being SSH brute forced there are many ways to protect: - - make hostbased authentication or use keys instead of password-based authentication - - install fail2ban to ban IPs after "x" wrong passwords - - make sure you put a very strong password, seriously - - disable root login via ssh - - if you have a VPS made with KVM you can disable SSH access at all and use the javaconsole from the VPS panel?
"s7r@sky-ip.org" s7r@sky-ip.org wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 4/29/2014 1:31 AM, I wrote:
One VPS company has just asserted that SSH scans are being run from my Tor exit rather than another process on the VPS. Is this happening to anyone else? Does anyone know what can be done to stop it?
Robert
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Could you explain with more details? Your question is not totally clear.
I thought his question was very clear.
If your VPS is being SSH brute forced there are many ways to protect:
- make hostbased authentication or use keys instead of password-based
authentication
- install fail2ban to ban IPs after "x" wrong passwords
- make sure you put a very strong password, seriously
- disable root login via ssh
- if you have a VPS made with KVM you can disable SSH access at all
and use the javaconsole from the VPS panel?
He stated that a VPS company (I've quoted his statement above yours, so please go back ad read it again) complained that the attacks were emanating *from his tor exit*. The VPS company is very unlikely to be moved by your suggestions. The second matter that was clear was that he has been running a tor relay without having read the documentation. If he wants to restrict what exits from his node, then he needs to read about exit policies in particular, but he also ought to read the rest of the documentation as well. More generally, people really should not be running an exit in ignorance. The tor project has done a commendable job of providing a well documented product. The documentation was intended to be read, not ignored, by those wishing to run tor, whether as a client only or as a relay.
Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at sdf.org *or* bennett at freeshell.org * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************
I beatthebastards@inbox.com wrote:
What do you suggest I missed in the documentation?
Exit policies. I wrote that in my earlier message.
Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at sdf.org *or* bennett at freeshell.org * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************
I first thought that the numerous complaints of my VPS being the source of the SSH (outgoing) attacks was that I hadn't done the things you suggested below and been 'hacked' but now one VPS business has looked at the VPS processes and said it must be coming out of Tor as I run an exit.
So I am asking whether this is rare or am I not doing something which others are doing? Is it just a matter of removing SSH from the already long list of port limitations?
Robert
Could you explain with more details? Your question is not totally clear.
If your VPS is being SSH brute forced there are many ways to protect:
- make hostbased authentication or use keys instead of password-based
authentication
- install fail2ban to ban IPs after "x" wrong passwords
- make sure you put a very strong password, seriously
- disable root login via ssh
- if you have a VPS made with KVM you can disable SSH access at all
and use the javaconsole from the VPS panel?
For what it's worth, after complaints from campus IT we also wound up blocking SSH in the CMU Tor exit's policy. It's a shame we can't help people do sysadmin stuff and whatnot anonymously, but the port scans do seem to happen quite often.
zw
On 4/28/2014 10:04 PM, Zack Weinberg wrote:
For what it's worth, after complaints from campus IT we also wound up blocking SSH in the CMU Tor exit's policy. It's a shame we can't help people do sysadmin stuff and whatnot anonymously, but the port scans do seem to happen quite often.
zw
The silly thing is that port scans happen hundreds of times per day to every internet-connected device, and Tor isn't involved in the vast majority of it. Not a single server on the 'net is made more secure by an exit node blocking a port. Will they request that port 80 be blocked because of the SQL injection and Wordpress vulnerability scans? Or that IMAP and FTP ports be blocked for attempts to brute force logins? Any open port has the potential for abuse -- blocking ports doesn't seem like a very well thought-out response to the issue.
The time people spend complaining to exit node operators would be much better spent performing any number of simple changes that would /actually/ improve security for the server(s). I think if a server is so threatened by a port scan that it invokes a human response, that server probably shouldn't be online.
/rant
-- Mike
Mike,
Yes but the goal is to have more relays, exits and bridges and if commercial server operators are very low on spine we have to keep them onside carefully.
I have just been kicked of another one after paying a year in advance. If we have no authoritative retort when they raise the first 'abuse' most of them take the lazy course and bar Tor.\ When I have said the restricted port list can be added and it has proved to be successful some have given me another chance. If SSH is open and their server is being used to attack others of course they will react defensively. So any advice to be proactive and increase the chance of one part of the Tor system surviving is advice I want to hear.
Robert
For what it's worth, after complaints from campus IT we also wound up blocking SSH in the CMU Tor exit's policy. It's a shame we can't help people do sysadmin stuff and whatnot anonymously, but the port scans do seem to happen quite often.
zw
The silly thing is that port scans happen hundreds of times per day to every internet-connected device, and Tor isn't involved in the vast majority of it. Not a single server on the 'net is made more secure by an exit node blocking a port. Will they request that port 80 be blocked because of the SQL injection and Wordpress vulnerability scans? Or that IMAP and FTP ports be blocked for attempts to brute force logins? Any open port has the potential for abuse -- blocking ports doesn't seem like a very well thought-out response to the issue.
The time people spend complaining to exit node operators would be much better spent performing any number of simple changes that would /actually/ improve security for the server(s). I think if a server is so threatened by a port scan that it invokes a human response, that server probably shouldn't be online.
/rant
Robert,
There is some good advice for exit relay operators on the Tor website that might be helpful. Included are templates you can use for responding to abuse complaints received by your ISP.
https://trac.torproject.org/projects/tor/wiki//doc/TorExitGuidelines
https://blog.torproject.org/running-exit-node
https://trac.torproject.org/projects/tor/wiki/doc/TorAbuseTemplates
Mike,
Yes but the goal is to have more relays, exits and bridges and if commercial server operators are very low on spine we have to keep them onside carefully.
I have just been kicked of another one after paying a year in advance. If we have no authoritative retort when they raise the first 'abuse' most of them take the lazy course and bar Tor.\ When I have said the restricted port list can be added and it has proved to be successful some have given me another chance. If SSH is open and their server is being used to attack others of course they will react defensively. So any advice to be proactive and increase the chance of one part of the Tor system surviving is advice I want to hear.
Robert
For what it's worth, after complaints from campus IT we also wound up blocking SSH in the CMU Tor exit's policy. It's a shame we can't help people do sysadmin stuff and whatnot anonymously, but the port scans do seem to happen quite often.
zw
The silly thing is that port scans happen hundreds of times per day to every internet-connected device, and Tor isn't involved in the vast majority of it. Not a single server on the 'net is made more secure by an exit node blocking a port. Will they request that port 80 be blocked because of the SQL injection and Wordpress vulnerability scans? Or that IMAP and FTP ports be blocked for attempts to brute force logins? Any open port has the potential for abuse -- blocking ports doesn't seem like a very well thought-out response to the issue.
The time people spend complaining to exit node operators would be much better spent performing any number of simple changes that would /actually/ improve security for the server(s). I think if a server is so threatened by a port scan that it invokes a human response, that server probably shouldn't be online.
/rant
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On Mon, Apr 28, 2014 at 11:23 PM, Michael Wolf mikewolf@riseup.net wrote:
On 4/28/2014 10:04 PM, Zack Weinberg wrote:
For what it's worth, after complaints from campus IT we also wound up blocking SSH in the CMU Tor exit's policy.
Sounds like IT is conflicted and sans balls... permits relay service, but well, doesn't. Good that you can run one, but if they're whacking you for denied stuff, plan on moving soon when they get real complaints.
people do sysadmin stuff and whatnot anonymously
Not just for anonymous... the value to real sysadmins daily of a TCP enabled IP for testing from anywhere in the world is huge.
I think if a server is so threatened by a port scan that it invokes a human response, that server probably shouldn't be online. /rant
The servers aren't the one's that shouldn't be online, it's their idiot operators who think SSH's DEFAULT SCREAMING ABOUT DENIED HACK ATTEMPTS in the logs is some kind of important, and then go reporting it to every place they can think of, each of those places staffed by more clueless idiots, etc. Grow up people, quit whining about ssh and learn to admin. Meanwhile, Theo laughs heartily at everyone.
On Tue Apr 29, 2014, grarpamp grarpamp@gmail.com wrote:
On 4/28/2014 10:04 PM, Zack Weinberg wrote:
For what it's worth, after complaints from campus IT we also wound up blocking SSH in the CMU Tor exit's policy.
Sounds like IT is conflicted and sans balls... permits relay service, but well, doesn't. Good that you can run one, but if they're whacking you for denied stuff, plan on moving soon when they get real complaints.
No. You are confusing university campuses with commercial providers, from which, as a customer, you are entitled to certain things per contract.
In that specific instance, campus IT have been extremely good sports about us running a Tor exit on our campus. They could have simply said "no;" instead, they're willing to support this. I think that is admirable: They have no incentive to do this other than an altruistic willingness to support research in that sphere. Not to put too fine a point on it, as a faculty, I pay overhead on research grants whether or not campus IT is kind to me.
Campus IT is understandably not, however, willing to spend an inordinate amount of time dealing with complaints from clueless third parties. SSH port scanning occurs unfortunately often enough it became a pretty big burden on them to deal with repeated emails from "victims." Our research group does not have the cycles to deal with these complaints either---and even if we did, I doubt we would have the authority to speak on behalf of the university.
So, given the choice between not operating an exit, and operating an exit without port 22 to avoid overburdening with red tape people who, once again, have been really good to us, what would you pick?
The servers aren't the one's that shouldn't be online, it's their idiot operators who think SSH's DEFAULT SCREAMING ABOUT DENIED HACK ATTEMPTS in the logs is some kind of important, and then go reporting it to every place they can think of, each of those places staffed by more clueless idiots, etc.
The level of intelligence of the people that receive these complaints is irrelevant. However competent you may be, if you get oodles of complaints every single day, for something that you are doing as a favor to somebody else, you will throw in the towel.
Best regards, Nicolas
On Tue, Apr 29, 2014 at 5:26 PM, Nicolas Christin nicolasc@andrew.cmu.edu wrote:
The level of intelligence of the people that receive these complaints is irrelevant.
It is, in fact, entirely relevant. Clueless recipients (and their upstream) leads directly to improper kneejerk responses, such as "pull the project". Whereas if people had a clue they'd realize this particular issue is nothing but background noise and file it in the bin.
However competent you may be, if you get oodles of complaints every single day, for something that you are doing as a favor to somebody else, you will throw in the towel.
once again, have been really good to us, what would you pick?
I've been party to large environments (R&E included) where boilerplate complaints resulted in automated canned responses, or were simply filed in the archive to be expired later. A few hours of existing work-study student time to process a days lot, fully supported by high ups.
It comes down to volume, severity, tools, responsibility and clue. If you don't have any of the latter four, sure, any amount of the first will kill you.
Being in a good environment for such things also helps too. Unfortunately that is probably not the majority of them.
grarpamp:
The servers aren't the one's that shouldn't be online, it's their idiot operators who think SSH's DEFAULT SCREAMING ABOUT DENIED HACK ATTEMPTS in the logs is some kind of important, and then go reporting it to every place they can think of, each of those places staffed by more clueless idiots, etc. Grow up people, quit whining about ssh and learn to admin. Meanwhile, Theo laughs heartily at everyone.
Often, SSH brute-force login attempts come directly from compromised machines, not Tor exit nodes. Reporting such attacks helps administrators realize a machine is compromised, which is a good thing. It could be helping protect the privacy of someone whose machine is compromised.
I'd suggest the problem is administrators treating a Tor exit node the same as a compromised machine. If the goal of an administrator is to eliminate SSH attacks emanating from Tor, they should simply block port 22 connections from Tor exit nodes.
It is a bit cynical or defeatist, I think, to say "There are a lot of these attacks, so administrators should have to just accept them." If you see someone attempting to break into cars, do you report it, or do you say "There are so many car thefts in the world, what's the point?"
Delton
On Wed, Apr 30, 2014 at 2:14 PM, Delton Barnes delton.barnes@mail.ru wrote:
I'd suggest the problem is administrators treating a Tor exit node the same as a compromised machine.
Sure, and it's part of the sometimes improper administrivia kneejerk response. And the SCREAMING involved with this one certainly incites an unbalanced response upon the less experienced/knowledgeable.
these attacks, so administrators should have to just accept them."
The operator of agnostic midpoint carriage services / relay is different than the ISP of the following two machines, and different than the targeted machine, or the attacking machine. Each has different rules of play available to them, with the midpoint carrier likely having least duty among them to do anything. It's not as if blocking exit:22 to the reporter's machine is going to do anything useful on their end given the rest of the internet they're open to, but if you want to appease them and your upstream, feel free. I wouldn't, but to each their own relay policy :)
On 14-04-30 02:14 PM, Delton Barnes wrote:
It is a bit cynical or defeatist, I think, to say "There are a lot of these attacks, so administrators should have to just accept them." If you see someone attempting to break into cars, do you report it, or do you say "There are so many car thefts in the world, what's the point?"
On the internet there is no way of "seeing" that a digital abode is abandoned or open or broken except to try entering, thus trying is simply the act of observing and exploring the digital wilderness. If no one else is prevented from using the connection, wheres the harm? If you dont want randoms entering your space, close the port or ensure the locks are functional!
Treating all Tor nodes as suspect because of some SSH probes is akin to racial profiling after seeing certain (ethnic/whatever) people looking at your car/house/etc. Maybe they are undercover police. Maybe they are admiring it or thinking about buying one of their own - why should you presume their purpose until they actually break or take something?
The original point has drifted over the horizon.
I asked what could be done, in my case, to stop SSH attacks originating FROM my VPS which is running as an exit. There was another VPS emanating SQL injection attacks.
The problem is that volunteering a cheap VPS to run as a Tor relay or exit is a very fickle process. The VPS businesses don't waste time on anything to do with them. Their reaction is nearly always absolute.
It would be smart for the Tor society to approach that situation with guidance for ordinary people to successfully get another exit or relay running most of which would have to be on VPSs to get the speed and volume. I know there are bits and piecs on this subject but they are not a coherent guide for ordinary people.
Robert
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 4/30/2014 9:01 PM, I wrote:
The original point has drifted over the horizon.
I asked what could be done, in my case, to stop SSH attacks originating FROM my VPS which is running as an exit. There was another VPS emanating SQL injection attacks.
The problem is that volunteering a cheap VPS to run as a Tor relay or exit is a very fickle process. The VPS businesses don't waste time on anything to do with them. Their reaction is nearly always absolute.
It would be smart for the Tor society to approach that situation with guidance for ordinary people to successfully get another exit or relay running most of which would have to be on VPSs to get the speed and volume. I know there are bits and piecs on this subject but they are not a coherent guide for ordinary people.
Robert
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Your points are well taken, Robert. I'm a relative newcomer to running a relay so unfortunately don't have the answers you seek, however I'm in agreement that more help and less bashing is in order if the bashers want to keep Tor alive../mini-rant
--- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com
Kurt Besig wrote
Your points are well taken, Robert. I'm a relative newcomer to running a relay so unfortunately don't have the answers you seek, however I'm in agreement that more help and less bashing is in order if the bashers want to keep Tor alive../mini-rant
Thanks Kurt.
In relation to SSH peculiarities such as a great number of outgoing SSH connections apparently involved in attacks and one SQL injection attack (outgoing) what does the collective intelligence think of this SSH rootkit: Ebury.
White Paper: http://www.welivesecurity.com/wp-content/uploads/2014/03/operation_windigo.p... Article: http://www.welivesecurity.com/2014/03/18/attack-unix-operation-windigo/
Robert
On Mon, Apr 28, 2014 at 11:23:19PM -0400, Michael Wolf wrote:
Will they request that port 80 be blocked because of the SQL injection and Wordpress vulnerability scans?
Yes, in fact we do get requests for exactly that (mostly from misguided CERT type organizations). "We support anonymity, but since we saw this SQL injection attack you must block this traffic to our servers."
-andy
On Mon, Apr 28, 2014 at 6:31 PM, I beatthebastards@inbox.com wrote:
Is this happening to anyone else?
Yes. Many relay ops effectively ignore it, as they have often positioned themselves beforehand to do so.
Does anyone know what can be done to stop it?
Block *:22 in your exit policy. Offer your vps that you will accept and respond directly to any complainants if the vps lets you keep 22 open.
I have just been kicked of another one after paying a year in advance.
They may owe you on contract for unused months, if you are not anon.
If we have no authoritative retort when they raise the first 'abuse' When I have said the restricted port list can be added and it has proved to be successful some have given me another chance.
Try to tell your future hosts what they can expect of abuse, get their approval in writing before signup and paying.
All of this, canned responses, and more are in the archives of this list, on the website, the wiki, etc.
tor-relays@lists.torproject.org
-
Andy Isaacson -
Delton Barnes -
Ed Carter -
grarpamp -
I -
krishna e bera -
Kurt Besig -
Michael Wolf -
Nicolas Christin -
s7r＠sky-ip.org -
Scott Bennett -
Zack Weinberg