Scott, What do you suggest I missed in the documentation? Robert

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?

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

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 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

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 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?

-----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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTYlFoAAoJEJQqkaGlFNDPaH0IALEBZd4RgcvdJt1z4HnyIYIk Imw71M+WUyg88wr/DDS8JBRrjw0SXIcgGiMn+fGm4xVHyAqumFcxukupWCrozqPt YI1M/pcmgl5ZBgjFidOAxKYDBk7mfQ+qkBL9fCg7XsHNJZVnppxisQMADN6T3PhZ l8HntabRSm0fH/cRJYVaCrsAoLxclChA/N179sEa19U1gyCbftpxwi4UzdY5Ttbn z25eKgNSFwtYz4DEFkf9MB5MLzDjbXiV/RG6gghHUvBzjCabV4DCM9zlwXBEv8Sr dG1As2GIgLz6dIs6KaDTHdd03xbxOqzps072JW83mJ8tZl7RSkbEZeErLTOpT2s= =H+C/ -----END PGP SIGNATURE----- --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com

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