[tor-relays] List of Relays' Available SSH Auth Methods
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, everyone. Linked below is a list of relays that were live last night along with the SSH authentication methods they support: https://gist.githubusercontent.com/plsql/27e80e6dab421f8cba6c/raw/8bb0c7aa9d22b8c959834e9db8c80b6511bdf093/gistfile1.txt If no auth methods are listed, the SSH connection to the relay failed (more on that below). I used this script to generate it: https://github.com/plsql/ssh-auth-methods The purpose of this is to alert relay operators that are still allowing password authentication. 2,051 relays offered password auth, and many more likely offer similarly insecure methods or were missed for reasons discussed below. Generally, it is far more secure to allow only public key auth. The Ubuntu help pages have a good guide on setting up key-based auth: https://help.ubuntu.com/community/SSH/OpenSSH/Keys Be sure to disable password authentication after you get key-based auth working! https://help.ubuntu.com/community/SSH/OpenSSH/Configuring#disable-password-authentication To test whether password auth is still supported, use my script (the README is pretty thorough) or try SSHing from a machine that doesn't have access to your private key. In the latter case, you should get the response 'Permission denied (publickey).' immediately. If you're having issues, make sure that you've restarted sshd since the last time you changed the config. Be sure to back up the node's secret key or your SSH private key, but only somewhere safe! For example, store it in a password manager database on Tarsnap or a USB. This script doesn't attempt any kind of authentication or unauthorized access, so it's about as benign as network scanning scripts come. Regardless, let me know if you have any concerns. It made successful SSH connections with 2839 / 6551 relays. Reasons for failure include: * SSH being served on a non-standard port - something other than port 22. This is a good idea, as many brute-force attackers will only bother trying port 22. The script I wrote could have used an alternate port number supplied from nmap, but this would run much slower and would potentially get my VPS blocked before it could even get the SSH information. * The server only allowing SSH connections from certain IP addresses. This is also commonly recommended, although it can be a little rigid if you don't have a VPN with a static IP (what if your server goes down while you're away from home?). * The server going down between when I downloaded the consensus and when I ran the script. * My VPS's IP address getting added to a shared blacklist that the server uses. * etc. If I gave any poor advice or got anything wrong, please let me know. Libertas -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJUa2ExAAoJELxHvGCsI27Np8IP/2duANtd55hs5L9IskFD2REe 9x5TR+uwZ54GhYLiFc+qiX3JnfoxfurZW7vi++D4R3E9L7nGo5weEZd0b88yJ6kx fUT9QG8gq2RFYdG+RQgYoEI9mLNObK/uc6J9qV3Y7dLOE/may6t6BDWpQTh7g5BJ 8fOnhrqjs0JdfTldc6xzrHT+m1dKBpylWus/WwGaJBReKOx6v7FoMEY53qowK0iA Vb5QS4idYb5WWF+K3Uzqk56v6sUzds/LTTlVc/R6mxjdse4AiMXO3DZsEffhI95W 8xSuw45e/Cfv/j80njsm4O1gFnrqyv/KcGwmL7vNPmtH4+i6dijTbBRroVElm1o3 LQBgCdUmQLz7njeprKnw8xdKT9X3oht4p9VZDfqWogXGiqRRdEtQCVUVhJp+ZrPA KrJBtV/IbYxyndhzC5cMAcTQUff0SOvDtzFnC4cxUbxSemtuO1NMwnIZtv3aGmG5 NEfXS3RjaUlZeZPZuymBDL1CnFqki6+eBDvka8ZOhL1/BgmDqcgT7nRWhlC5MtCG wBAfuJWB8BZl2PHg66VUN9X05TeHbVmrlyuRXaZO6SZof0Wp5vPjzJ1mKD6AyTlt Y/7liLapWgCVSYldohvbLB016iO/aHyGf3oTvZqUyG3NyD267aRQCDQ+sZZq7Cdz +eQO5eJLW/gFNXEptaJz =alRk -END PGP SIGNATURE- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] List of Relays' Available SSH Auth Methods
On 2014-11-18 16:09, Libertas wrote: [..] https://github.com/plsql/ssh-auth-methods The purpose of this is to alert relay operators that are still allowing password authentication. 2,051 relays offered password auth, and many more likely offer similarly insecure methods or were missed for reasons discussed below. Excellent run! And thanks for bringing this up on this list. Now to hope that folks actually fix their setups though. [..] * SSH being served on a non-standard port - something other than port 22. This is a good idea, as many brute-force attackers will only bother trying port 22. The script I wrote could have used an alternate port number supplied from nmap, but this would run much slower and would potentially get my VPS blocked before it could even get the SSH information. Try 2022, it is a general alternative. People should realize though that it is not 'safer' in any way running SSH on another port. SSH readily shows itself as being SSH and nmap and other tools easily recognize it on other ports. * The server only allowing SSH connections from certain IP addresses. This is also commonly recommended, although it can be a little rigid if you don't have a VPN with a static IP (what if your server goes down while you're away from home?). Actually it is not 'a little rigid' it is the best thing to do: Only allow certain prefixes access If you do not have a static IP address, at minimum limit access to the prefix of your ISP (whois your own IP address and check the 'route' object); though be warned you might change outside that block too. Possibly better, set up IPv6 at home and on the server by getting a free IPv6 tunnel (effectively just also a VPN) from many places around the world (see Wikipedia IPv6 Tunnel Broker List). Then just allow access over the static IPv6 address you have. As there are no SSH scanners on IPv6 you could even opt to not having a filter if you don't publish the address of the endpoint anywhere. Greets, Jeroen ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] List of Relays' Available SSH Auth Methods
On 11/18/2014 04:28 PM, Jeroen Massar wrote: People should realize though that it is not 'safer' in any way running SSH on another port. But it is (slightly) more expensive - which counts, or ? -- Toralf pgp key: 0076 E94E ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] List of Relays' Available SSH Auth Methods
On Tue, Nov 18, 2014 at 11:15 AM, Toralf Förster toralf.foers...@gmx.de wrote: On 11/18/2014 04:28 PM, Jeroen Massar wrote: People should realize though that it is not 'safer' in any way running SSH on another port. But it is (slightly) more expensive - which counts, or ? In my limited experience, moving SSH to another port made no apparent difference to the number of random attempts to break in. I'd recommend fail2ban or equivalent instead. zw ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] List of Relays' Available SSH Auth Methods
On 11/18/2014 05:45 PM, Zack Weinberg wrote: On Tue, Nov 18, 2014 at 11:15 AM, Toralf Förster toralf.foers...@gmx.de wrote: On 11/18/2014 04:28 PM, Jeroen Massar wrote: People should realize though that it is not 'safer' in any way running SSH on another port. But it is (slightly) more expensive - which counts, or ? In my limited experience, moving SSH to another port made no apparent difference to the number of random attempts to break in. I'd recommend fail2ban or equivalent instead. Well, I do have an alternate port and my ip tables shows me this : $ wc /proc/net/xt_recent/FAILED_SSH_* 4 61 643 /proc/net/xt_recent/FAILED_SSH_ALT_LOGIN 149 1284 12182 /proc/net/xt_recent/FAILED_SSH_LOGIN These are the iptables rules : # block brute force attacks against ssh, fake the 22 # $IPT -t filter -A INPUT -p tcp --destination-port 22 --match conntrack --ctstate NEW --match recent --name FAILED_SSH_LOGIN --set $IPT -t filter -A INPUT -p tcp --destination-port 22 --match conntrack --ctstate ESTABLISHED --match recent --name FAILED_SSH_LOGIN --update --seconds 300 --hitcount 2 -j REJECT --reject-with tcp-reset $IPT -t filter -A INPUT -p tcp --destination-port snip --match conntrack --ctstate NEW --match recent --name FAILED_SSH_ALT_LOGIN --set $IPT -t filter -A INPUT -p tcp --destination-port snip --match conntrack --ctstate ESTABLISHED --match recent --name FAILED_SSH_ALT_LOGIN --update --seconds 300 --hitcount 2 -j DROP -- Toralf pgp key: 0076 E94E ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] List of Relays' Available SSH Auth Methods
This is all just too much risk and admin on my production server on Linode. Abacustard relay is down until I can move my production server, downgrade the current linode and relegate it to backup functionality and Tor exit node. Cheers for now, JB On 18/11/2014 18:45, Zack Weinberg wrote: On Tue, Nov 18, 2014 at 11:15 AM, Toralf Förster toralf.foers...@gmx.de wrote: On 11/18/2014 04:28 PM, Jeroen Massar wrote: People should realize though that it is not 'safer' in any way running SSH on another port. But it is (slightly) more expensive - which counts, or ? In my limited experience, moving SSH to another port made no apparent difference to the number of random attempts to break in. I'd recommend fail2ban or equivalent instead. zw ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] List of Relays' Available SSH Auth Methods
Fail2Ban works really well. Shifting to a non standard port only stops the scriptkids from having too much automated options and does not do anything for actual security. For this reason I personally never bothered with that. Non standard username and password auth with fail2ban makes brute forcing practically impossible, this is usually how I have things configured. Op 17:46 di 18 nov. 2014 schreef Zack Weinberg za...@cmu.edu: On Tue, Nov 18, 2014 at 11:15 AM, Toralf Förster toralf.foers...@gmx.de wrote: On 11/18/2014 04:28 PM, Jeroen Massar wrote: People should realize though that it is not 'safer' in any way running SSH on another port. But it is (slightly) more expensive - which counts, or ? In my limited experience, moving SSH to another port made no apparent difference to the number of random attempts to break in. I'd recommend fail2ban or equivalent instead. zw ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] List of Relays' Available SSH Auth Methods
On Tue, Nov 18, 2014 at 10:09:37AM -0500, Libertas wrote:
Hi, everyone. Linked below is a list of relays that were live last night
along with the SSH authentication methods they support:
[snip]
Generally, it is far more secure to allow only public key auth.
This is great advice, and thanks for doing this scan! But I have one
question about another piece of advice:
* SSH being served on a non-standard port - something other than port
22. This is a good idea, as many brute-force attackers will only
bother trying port 22.
I don't understand why, for a system that has gotten any security review
at all, moving ssh to another port is a good idea.
If your ssh config is secure against password brute forcing, then it
simply doesn't matter that botnets are crashing against the gate, and
change your port or run fail2ban seem pointless. The only
difference is the amount of logspew that is generated.
If your ssh config is insecure (PasswordAuthentication Yes and you have
a bruteforceable password) then moving to another port, or running
fail2ban, does not help the situation much against any determined
attacker; the real attackers have millions of compromised hosts to
bruteforce from (or entire ASes to spoof from), and if your config is
sufficiently insecure that root/b4mb1 is going to work, you're not
likely to install fail2ban *either*.
So for my systems, I set passwords to be [a-zA-Z0-9]{10} from urandom,
and I generally (but not always) turn off PasswordAuthentication, and I
keep sshd up-to-date, but I don't change from port 22 nor do I ever run
fail2ban.
-andy
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] List of Relays' Available SSH Auth Methods
On 2014-11-18 18:38, Kevin de Bie wrote: Fail2Ban works really well. Shifting to a non standard port only stops the scriptkids from having too much automated options and does not do anything for actual security. For this reason I personally never bothered with that. Non standard username and password auth with fail2ban makes brute forcing practically impossible, this is usually how I have things configured. Just changing it to key-based authentication stops ALL password-guessing attacks. You will then be left with the logs though. Hence lets make a little list for clarity in order of should at least do: - Use SSH Authentication - Disable Password Authentication - Use Fail2ban - Restrict on IP address (no need for fail2ban then) Greets, Jeroen ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] List of Relays' Available SSH Auth Methods
On Tue, Nov 18, 2014, at 11:45 AM, Zack Weinberg wrote: On Tue, Nov 18, 2014 at 11:15 AM, Toralf Förster toralf.foers...@gmx.de wrote: On 11/18/2014 04:28 PM, Jeroen Massar wrote: People should realize though that it is not 'safer' in any way running SSH on another port. But it is (slightly) more expensive - which counts, or ? In my limited experience, moving SSH to another port made no apparent difference to the number of random attempts to break in. I'd recommend fail2ban or equivalent instead. zw I definitely agree with this. I don't have hard metrics to share but in my time working for a hosting provider, I saw very limited benefit to changing the default port. Yes, some scanners and software won't scan you if you aren't running on port 22 but the amount of scanning that also covered non-standard ports made it mostly a moot point. However, you're mileage may vary based on your provider (certain ip blocks are hit harder/more frequently than others). Fail2ban generally provides better protection that strictly using a different port as far as I've seen. As, Libertas said, pub key auth is generally best... or even for some, disabling SSH altogether may be possible. If your relay is a VPS and you have access to a (java) console or some form of IPMI/drac/iLo management, you may not even need ssh access but these could open up additional security issues (particularly old firmware for out of band management). Regards, Ryan ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] List of Relays' Available SSH Auth Methods
On Tue, Nov 18, 2014, at 10:45 AM, Zack Weinberg wrote: On Tue, Nov 18, 2014 at 11:15 AM, Toralf Förster toralf.foers...@gmx.de wrote: On 11/18/2014 04:28 PM, Jeroen Massar wrote: People should realize though that it is not 'safer' in any way running SSH on another port. But it is (slightly) more expensive - which counts, or ? In my limited experience, moving SSH to another port made no apparent difference to the number of random attempts to break in. I'd recommend fail2ban or equivalent instead. In my equally limited experience, my piddly middle relay went from about 100 SSH related fail2bans/day to zero when I changed the port. I fully recognize changing the port is mere obfuscation (I use public key anyways), but I just got tired of seeing the same list of abusers (China, Russia) in the logs every single day. Now if only those open proxy scanners would stop hitting port 80 on my tor-project mirror--24hr bans don't seem to have any impact. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] List of Relays' Available SSH Auth Methods
IMO there could occasionally be reasons not to use key logins (although I do normally disable pwd login). E.g. if I have a key, I then have evidence somewhere (USB/HD), whereas a secure password can be kept only in my head (until they waterboard me). Especially in countries (e.g. the UK) that can force you to hand over encryption keys. I'd rather have an insecure Tor node than get arrested (although tbh with fail2ban installed I don't think pwd bruteforcing is a threat). On 18/11/14 17:46, Jeroen Massar wrote: On 2014-11-18 18:38, Kevin de Bie wrote: Fail2Ban works really well. Shifting to a non standard port only stops the scriptkids from having too much automated options and does not do anything for actual security. For this reason I personally never bothered with that. Non standard username and password auth with fail2ban makes brute forcing practically impossible, this is usually how I have things configured. Just changing it to key-based authentication stops ALL password-guessing attacks. You will then be left with the logs though. Hence lets make a little list for clarity in order of should at least do: - Use SSH Authentication - Disable Password Authentication - Use Fail2ban - Restrict on IP address (no need for fail2ban then) Greets, Jeroen ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays -- Dan Rogers +44 7539 552349 skype: dan.j.rogers gpg key https://secure.techwang.com/gpg/public_key.txt linkedin http://www.linkedin.com/in/danrogerslondon | twitter http://twitter.com/danjrog | spotify http://open.spotify.com/user/bonkbonkonk | music http://holdingitwrong.com ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] List of Relays' Available SSH Auth Methods
This only applies if you're able to rid your hardware of all evidence of ever connecting to your node, and have no record of ownership of that node whatsoever. I find that a fairly unlikely scenario, to be honest. On 18/11/14 19:10, Dan Rogers wrote: IMO there could occasionally be reasons not to use key logins (although I do normally disable pwd login). E.g. if I have a key, I then have evidence somewhere (USB/HD), whereas a secure password can be kept only in my head (until they waterboard me). Especially in countries (e.g. the UK) that can force you to hand over encryption keys. I'd rather have an insecure Tor node than get arrested (although tbh with fail2ban installed I don't think pwd bruteforcing is a threat). ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] List of Relays' Available SSH Auth Methods
Not that hard; - pay in bitcoins - only login to node using Tor / Tails On 18/11/14 18:16, Niklas Kielblock wrote: This only applies if you're able to rid your hardware of all evidence of ever connecting to your node, and have no record of ownership of that node whatsoever. I find that a fairly unlikely scenario, to be honest. On 18/11/14 19:10, Dan Rogers wrote: IMO there could occasionally be reasons not to use key logins (although I do normally disable pwd login). E.g. if I have a key, I then have evidence somewhere (USB/HD), whereas a secure password can be kept only in my head (until they waterboard me). Especially in countries (e.g. the UK) that can force you to hand over encryption keys. I'd rather have an insecure Tor node than get arrested (although tbh with fail2ban installed I don't think pwd bruteforcing is a threat). ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays -- Dan Rogers +44 7539 552349 skype: dan.j.rogers gpg key https://secure.techwang.com/gpg/public_key.txt linkedin http://www.linkedin.com/in/danrogerslondon | twitter http://twitter.com/danjrog | spotify http://open.spotify.com/user/bonkbonkonk | music http://holdingitwrong.com ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] List of Relays' Available SSH Auth Methods
On Tue, 18 Nov 2014 09:40:13 -0800, Ryan Getz ry...@getzmail.com wrote: As, Libertas said, pub key auth is generally best... or even for some, disabling SSH altogether may be possible. If your relay is a VPS and you have access to a (java) console or some form of IPMI/drac/iLo management, you may not even need ssh access but these could open up additional security issues (particularly old firmware for out of band management). Another option is to install ZeroTier One and configure the SSH daemon to listen only on the zt0 device for your private network. https://www.zerotier.com/ -- Seth I 3 nicely trimmed email replies ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] List of Relays' Available SSH Auth Methods
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Here's an interesting and relevant talk on SSH security: http://www.bsdcan.org/2013/schedule/events/403.en.html On 11/18/2014 12:38 PM, Kevin de Bie wrote: Fail2Ban works really well. Shifting to a non standard port only stops the scriptkids from having too much automated options and does not do anything for actual security. For this reason I personally never bothered with that. Non standard username and password auth with fail2ban makes brute forcing practically impossible, this is usually how I have things configured. Op 17:46 di 18 nov. 2014 schreef Zack Weinberg za...@cmu.edu mailto:za...@cmu.edu: On Tue, Nov 18, 2014 at 11:15 AM, Toralf Förster toralf.foers...@gmx.de mailto:toralf.foers...@gmx.de wrote: On 11/18/2014 04:28 PM, Jeroen Massar wrote: People should realize though that it is not 'safer' in any way running SSH on another port. But it is (slightly) more expensive - which counts, or ? In my limited experience, moving SSH to another port made no apparent difference to the number of random attempts to break in. I'd recommend fail2ban or equivalent instead. zw _ tor-relays mailing list tor-relays@lists.torproject.__org mailto:tor-relays@lists.torproject.org https://lists.torproject.org/__cgi-bin/mailman/listinfo/tor-__relays https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJUa5HOAAoJELxHvGCsI27NllcP/jSI6085xPNOea7IKyfY4QX3 AMssZQq+AP75Bozz3oQAsZuwcRvWI5Umtrjm8Z/1lxQ2yv/SBs7q71Sw3zpsDkta UPwH7XSvsKthTUnH8q1EJ9yymcASPtpUJ12xbZpSEX6A+0g7DVXOcYyeWHWLW14u wlUCuf3OgoB7xD3BXkPL/tBh+0e3PbWCED4jT/mQOWrqA1PoOmTmLYbZV1Qf9SK0 Oufl3dlBe8sydfanO69bs9qH4HutlA4tuYmSc0Cp67dzHvMMZeiGqreJhYBxaRcD 2SnrojVfOPWXcH4ftsGiqiiNWKl7qo5RD6xfga9D5gBWSsW3ZgRFfbry7RpjUdGL hWwtGWiWqCzMq0kYT8jrXZNVVo664GH8ikPiHqvbyI8KSxlBYSpI1Lv6MBV2yxcW AgeI/YTqhfFFBBq9LFvczqNMpJ/2hP37oDeuaCb60hBefWeY9zHwlN/q8HRQEiTU VkhI03M2c4tx1fQXDKHdxYc3seEY+RxMj4GXYgOtUOqwytfzSSs4wbh2Cqo0E2dH vL9hfgjhBl7DOTjf8JXp6P+t5vA0dtjpp6DfuKm0DPmUfdNDTgeXkbHdaj6PviRf zcwePS63ZVR0fevetCST+1smkOU5byOefyT/KkuXxLhmPqiqsmEzDPUYy8VuyLg2 j8irgydAPonUQwjq/4PU =Z/nm -END PGP SIGNATURE- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] List of Relays' Available SSH Auth Methods
You could also just want on the spot access to your box without needing some key. I personally believe a proper un/pw combination used in conjunction with fail2ban is sufficiently secure for pretty much anything that is not a high risk target. Op 19:10 di 18 nov. 2014 schreef Dan Rogers d...@holdingitwrong.com: IMO there could occasionally be reasons not to use key logins (although I do normally disable pwd login). E.g. if I have a key, I then have evidence somewhere (USB/HD), whereas a secure password can be kept only in my head (until they waterboard me). Especially in countries (e.g. the UK) that can force you to hand over encryption keys. I'd rather have an insecure Tor node than get arrested (although tbh with fail2ban installed I don't think pwd bruteforcing is a threat). On 18/11/14 17:46, Jeroen Massar wrote: On 2014-11-18 18:38, Kevin de Bie wrote: Fail2Ban works really well. Shifting to a non standard port only stops the scriptkids from having too much automated options and does not do anything for actual security. For this reason I personally never bothered with that. Non standard username and password auth with fail2ban makes brute forcing practically impossible, this is usually how I have things configured. Just changing it to key-based authentication stops ALL password-guessing attacks. You will then be left with the logs though. Hence lets make a little list for clarity in order of should at least do: - Use SSH Authentication - Disable Password Authentication - Use Fail2ban - Restrict on IP address (no need for fail2ban then) Greets, Jeroen ___ tor-relays mailing listtor-relays@lists.torproject.orghttps://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays -- Dan Rogers +44 7539 552349 skype: dan.j.rogers gpg key https://secure.techwang.com/gpg/public_key.txt linkedin http://www.linkedin.com/in/danrogerslondon | twitter http://twitter.com/danjrog | spotify http://open.spotify.com/user/bonkbonkonk | music http://holdingitwrong.com ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] List of Relays' Available SSH Auth Methods
On Tue, Nov 18, 2014 at 10:09:37AM -0500, Libertas wrote: Hi, everyone. Linked below is a list of relays that were live last night along with the SSH authentication methods they support: [snip] Generally, it is far more secure to allow only public key auth. Nobody has mentioned using single packet authentication via fwknopd. I get the warm fuzzies when one must pass this this challenge before a sensitive port is opened for your sourcing ip and for only X number of seconds before it's closed. Spa has more to offer than simple port knocking and there are plenty of client options available. Is there a reason more relay operators aren't using it? It also seems that fail2ban is more favored than csf although the features of additional login notifications and some password brute force protection are similar. Are there reasons that a person would favor one over the other? I'd like to mention that it seems the brute force protection doesn't offer a lot of protection if the attack is distributed and only 1 attempt is ever seen from a given ip. Still better than nothing and all simply an additional layer with single packet authentication enabled. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] List of Relays' Available SSH Auth Methods
Great work Libertas! Glad to see my relay didn't come up with any results :) Colin On November 18, 2014 10:09:37 AM EST, Libertas liber...@mykolab.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, everyone. Linked below is a list of relays that were live last night along with the SSH authentication methods they support: https://gist.githubusercontent.com/plsql/27e80e6dab421f8cba6c/raw/8bb0c7aa9d22b8c959834e9db8c80b6511bdf093/gistfile1.txt If no auth methods are listed, the SSH connection to the relay failed (more on that below). I used this script to generate it: https://github.com/plsql/ssh-auth-methods The purpose of this is to alert relay operators that are still allowing password authentication. 2,051 relays offered password auth, and many more likely offer similarly insecure methods or were missed for reasons discussed below. Generally, it is far more secure to allow only public key auth. The Ubuntu help pages have a good guide on setting up key-based auth: https://help.ubuntu.com/community/SSH/OpenSSH/Keys Be sure to disable password authentication after you get key-based auth working! https://help.ubuntu.com/community/SSH/OpenSSH/Configuring#disable-password-authentication To test whether password auth is still supported, use my script (the README is pretty thorough) or try SSHing from a machine that doesn't have access to your private key. In the latter case, you should get the response 'Permission denied (publickey).' immediately. If you're having issues, make sure that you've restarted sshd since the last time you changed the config. Be sure to back up the node's secret key or your SSH private key, but only somewhere safe! For example, store it in a password manager database on Tarsnap or a USB. This script doesn't attempt any kind of authentication or unauthorized access, so it's about as benign as network scanning scripts come. Regardless, let me know if you have any concerns. It made successful SSH connections with 2839 / 6551 relays. Reasons for failure include: * SSH being served on a non-standard port - something other than port 22. This is a good idea, as many brute-force attackers will only bother trying port 22. The script I wrote could have used an alternate port number supplied from nmap, but this would run much slower and would potentially get my VPS blocked before it could even get the SSH information. * The server only allowing SSH connections from certain IP addresses. This is also commonly recommended, although it can be a little rigid if you don't have a VPN with a static IP (what if your server goes down while you're away from home?). * The server going down between when I downloaded the consensus and when I ran the script. * My VPS's IP address getting added to a shared blacklist that the server uses. * etc. If I gave any poor advice or got anything wrong, please let me know. Libertas -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJUa2ExAAoJELxHvGCsI27Np8IP/2duANtd55hs5L9IskFD2REe 9x5TR+uwZ54GhYLiFc+qiX3JnfoxfurZW7vi++D4R3E9L7nGo5weEZd0b88yJ6kx fUT9QG8gq2RFYdG+RQgYoEI9mLNObK/uc6J9qV3Y7dLOE/may6t6BDWpQTh7g5BJ 8fOnhrqjs0JdfTldc6xzrHT+m1dKBpylWus/WwGaJBReKOx6v7FoMEY53qowK0iA Vb5QS4idYb5WWF+K3Uzqk56v6sUzds/LTTlVc/R6mxjdse4AiMXO3DZsEffhI95W 8xSuw45e/Cfv/j80njsm4O1gFnrqyv/KcGwmL7vNPmtH4+i6dijTbBRroVElm1o3 LQBgCdUmQLz7njeprKnw8xdKT9X3oht4p9VZDfqWogXGiqRRdEtQCVUVhJp+ZrPA KrJBtV/IbYxyndhzC5cMAcTQUff0SOvDtzFnC4cxUbxSemtuO1NMwnIZtv3aGmG5 NEfXS3RjaUlZeZPZuymBDL1CnFqki6+eBDvka8ZOhL1/BgmDqcgT7nRWhlC5MtCG wBAfuJWB8BZl2PHg66VUN9X05TeHbVmrlyuRXaZO6SZof0Wp5vPjzJ1mKD6AyTlt Y/7liLapWgCVSYldohvbLB016iO/aHyGf3oTvZqUyG3NyD267aRQCDQ+sZZq7Cdz +eQO5eJLW/gFNXEptaJz =alRk -END PGP SIGNATURE- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] List of Relays' Available SSH Auth Methods
On Tue, 18 Nov 2014 18:10:02 +, Dan Rogers wrote: IMO there could occasionally be reasons not to use key logins (although I do normally disable pwd login). E.g. if I have a key, I then have evidence somewhere (USB/HD), Oh, that ssh key? That is for accessing my home server on DSL. You need to clean your .ssh/known_hosts with password auth just as well. Andreas -- Totally trivial. Famous last words. From: Linus Torvalds torvalds@*.org Date: Fri, 22 Jan 2010 07:29:21 -0800 ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] List of Relays' Available SSH Auth Methods
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11/18/2014 01:10 PM, Dan Rogers wrote: if I have a key, I then have evidence somewhere (USB/HD), whereas a secure password can be kept only in my head (until they waterboard me). Why not just encrypt your home directory? It's very easy in most *nix OSs. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJUa6bnAAoJELxHvGCsI27N7pAP/2eWbaStlGToipRU9/atYrd8 og8p8WkgtW0wdBOZVOwohcFtAPo0rSAP0eKHaVQ1LBMI0kc0ciAlcFAPOgKCTxzF I5bhaunecCdOc7xZTReJHl+SVSNq8wquk4ia3AEnSc8Larf/4dn7YWzv7K+tLb3j 9svYsB38VkY5cvRETmQz/axm8UwNgDCiIiVEyVoXLVEnex7S36Y6pldMjE+FvgEO GsrgsWS7f78a9IXzhO50je3QfI+dmshco41CG8G37AjWhQ9GElkNRUZIlbkwOvcr rjAw0c5yQckDbTikakdebcqmSTgDg5MXURaVD7tKgC2SfXoJzlF0QVpv2MPGBfU3 3ouo5OftxPGmE4L/LbA76uzpalrcSGFdEijLevMcGvjWZtz2Ga34sO1+1Kvtg2uO 1/cQxEr4yz3KBFRdNV0B3LsWWiUFSXpTUXa9q1atK1F+I4Mtsiy6PpDicXqbbMD8 Hopv8pv9gnf2OxctQEqS+UpI1+kZFYrfvIHEo7J9VvRgLyV5KPQbE2YWJPjQQ6uh k5q1xNUhKEpLIF/vJ/gTnR6bvlE8MtHenRhLWKdAHZ4Ls63CdQgs8VUGiHCRTtli HwRx+lmfK1bmB1XXYhwpeXJYAhR3ymKNkkMhf1ds/YzHtZF2SolU2wtIWUVvtkkS IN5pDG+Hdcca1yxPQaXb =tvwz -END PGP SIGNATURE- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] List of Relays' Available SSH Auth Methods
On 18.11.2014 18:40, Dan Thill wrote: In my equally limited experience, my piddly middle relay went from about 100 SSH related fail2bans/day to zero when I changed the port. I fully recognize changing the port is mere obfuscation (I use public key anyways), but I just got tired of seeing the same list of abusers (China, Russia) in the logs every single day. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays A good option to avoid bruteforces from these special countries is to combine sshd with geo-IP based blocking. I am using a python based script to block countrys based on their two-letter countrycode. Just block all the countries you don’t live/work/travel in combine it with fail2ban, disable root login and you are probably as safe as with key based logins. BR Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] List of Relays' Available SSH Auth Methods
One of the reasons I'd love to see a MirageOS port (or, rather, reimplementation) of little-t tor is, it wouldn't *need* any administrative access. It'd be a black box that speaks the cell protocol. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
