-----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/8bb0c7aa9d...
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-a...
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
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
- 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
On Tue, Nov 18, 2014 at 11:15 AM, Toralf Förster toralf.foerster@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
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.foerster@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
On 11/18/2014 05:45 PM, Zack Weinberg wrote:
On Tue, Nov 18, 2014 at 11:15 AM, Toralf Förster toralf.foerster@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
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.
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 zackw@cmu.edu:
On Tue, Nov 18, 2014 at 11:15 AM, Toralf Förster toralf.foerster@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
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
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
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).
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
On 11/18/2014 11:18 AM, Dan Rogers wrote:
Not that hard;
- pay in bitcoins
After mixing them through several independent wallets, of course ;)
The hardest part is finding hosting that allows exits for anonymous accounts :(
- 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
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
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 dan@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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Tor nodes, particularly Tor exit nodes, are high risk targets.
Also, the key is accessed from your ~/.ssh directory automatically, so it's actually easier than password auth. Just give the SSH command and you're in!
On 11/18/2014 01:41 PM, Kevin de Bie wrote:
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 <dan@holdingitwrong.com mailto:dan@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 list tor-relays@lists.torproject.org mailto: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 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 SIGNED MESSAGE----- Hash: SHA256
Password brute-forcing is still a threat with fail2ban because your username and password can be compromised without your knowledge more easily than a private key. It's discussed in this talk, which I linked earlier:
http://www.bsdcan.org/2013/schedule/events/403.en.html
On 11/18/2014 01:10 PM, 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).
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
On Tue, 18 Nov 2014 18:10:02 +0000, 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
-----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.
On 2014-11-18 18:46, Jeroen Massar wrote:
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)
Additionally - with ssh over hidden services:
HiddenServiceDir /var/lib/tor/hidden_ssh/ HiddenServicePort 22 127.0.0.1:22
there is no need to open any ssh-port. Works very well for my relay 'TorMachine'. No trouble with brute force attacks, huge logfiles and so on.
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.
-----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 <zackw@cmu.edu mailto:zackw@cmu.edu>:
On Tue, Nov 18, 2014 at 11:15 AM, Toralf Förster <toralf.foerster@gmx.de mailto:toralf.foerster@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
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.foerster@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
On Tue, 18 Nov 2014 09:40:13 -0800, Ryan Getz ryan2@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/
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.foerster@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.
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
I'd recommend fail2ban or equivalent instead.
Right, thanks. I planned on mentioning SSH-protecting daemons, but forgot. I've had better luck with SSHGuard, but fail2ban is the most common option.
On 11/18/2014 11:45 AM, Zack Weinberg wrote:
On Tue, Nov 18, 2014 at 11:15 AM, Toralf Förster toralf.foerster@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
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
- 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
On Tue, Nov 18, 2014 at 09:43:53AM -0800, Andy Isaacson wrote:
On Tue, Nov 18, 2014 at 10:09:37AM -0500, Libertas wrote:
- SSH being served on a non-standard port - something other than port
- 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".
In addition to an already safe configuration, I use non-standards ports. As you point out yourself, it keeps the log files clean, which allows me to focus on the small number of login attempts I get. This is my main reason for doing this.
In addition, if OpenSSH (or one of its dependencies) should ever be subject to a severe security issue, plenty of folks would immediately start scanning and exploiting the Internet. A non-standard port would likely give me a grace period which would allow me to shut down SSH or take other measures.
Cheers, Philipp
On 11/18/2014 08:10 PM, Philipp Winter wrote:
On Tue, Nov 18, 2014 at 09:43:53AM -0800, Andy Isaacson wrote:
On Tue, Nov 18, 2014 at 10:09:37AM -0500, Libertas wrote:
- SSH being served on a non-standard port - something other than port
- 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".
In addition to an already safe configuration, I use non-standards ports. As you point out yourself, it keeps the log files clean, which allows me to focus on the small number of login attempts I get. This is my main reason for doing this.
In addition, if OpenSSH (or one of its dependencies) should ever be subject to a severe security issue, plenty of folks would immediately start scanning and exploiting the Internet. A non-standard port would likely give me a grace period which would allow me to shut down SSH or take other measures.
+1
you can make harder/more expensive for an advisory with no additional costs for yourself
On Tue, 18 Nov 2014 10:09:37 +0000, Libertas wrote:
-----BEGIN PGP SIGNED MESSAGE-----
...
https://gist.githubusercontent.com/plsql/27e80e6dab421f8cba6c/raw/8bb0c7aa9d...
Ouch. You might run that in a few days and post the diff. :-)
Andreas
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 libertas@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/8bb0c7aa9d...
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-a...
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
- 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@lists.torproject.org
-
Andreas Krey -
Andy Isaacson -
Colin Mahns -
Dan Rogers -
Dan Thill -
Felix Buedenhoelzer -
JB -
Jeroen Massar -
Kevin de Bie -
Libertas -
Mirimir -
Niklas Kielblock -
Philipp Winter -
Ryan Getz -
Seth -
tor-exit0 -
Toralf Förster -
Tschador -
Zack Weinberg