-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Thu, 2018-08-23 at 21:37 +0200, Peter Müller wrote:
Hello Michael,
[snip]
+# limit authentication thresholds +LoginGraceTime 20s +MaxAuthTries 3
Three is definitely too little. I have three versions of my key (RSA, ECDSA and Ed25519). After my client tried all of these, a password prompt won't be shown any more.
Is 30 seconds enough (default setting in IPFire 2.x)?
Yes I think so. I don't even see that there is a huge desire in a very low limit. This only allows to brute-force a little bit faster. However, the keys should be virtually un-brute-force-able and therefore dividing the time you need to search by 10 isn't making any difference in practise.
Provided people are using SSH keys, yes. We have had that discussion.
Or very long passwords.
+MaxSessions 5
Per user? Why?
Because most users do not connect to a machine multiple times - at least not more than five times. Many active logins for one account are a clear indicator of compromise, especially if the account is only secured by a password.
Well, true. But I often use an IPFire system as a jump host and for that open multiple connections.
Hm, have you tried something like this for jumping (snip from ~/.ssh/config):
Host *.ipfire.org ProxyCommand ssh -q [proxy IP] nc %h %p
It avoids open SSH sessions on systems, which need some scheduled downtime entries in my network (paranoia...), so I am very happy with this. :-)
No.
OpenSSH default is 10, but this seems too high for me.
This sounds good to me.
All right, I will use this value.
+# limit maximum instanctes +MaxStartups 5
+# ensure proper logging +SyslogFacility AUTH +LogLevel INFO
+# always turn on strict mode +StrictModes yes
The comment explains the option, but it should explain what it does. We have discussed that before in another thread to a patch that only enabled this.
All right, comment will be adjusted in second version of this patch. This slipped my mind.
+# only allow safe crypto algorithms (may break some _very_ outdated clients)
*How* outdated? From the 90s or last year?
I successfully tested this with OpenSSH 6.6 (released 15-03-2014) and most recent PuTTY 0.70 (released 08-07-2017). This leads me to the assumption more or less up to date clients (<= 1 year for PuTTY and <= 4 years for OpenSSH) can be used.
Your first comment stated *very* outdated. One year isn't outdated.
Talking about software updates, one year is _very_ outdated. Especially if you are running Windows. Assumption here is if a client cannot use a service because it is too old to support the cryptography required, it did not receive other important updates, too.
PuTTY doesn't have an update mechanism and therefore will probably be installed once and never updated on the average admin's machine.
You are right and I gnashingly agree in case of normal distributions. Talking about a firewall system, I do not. Similar to TLS 1.2, which we enforced a few Core Updates ago, we should enforce strong cryptography for SSH.
If an admin's machine does not support that because it is outdated, I couldn't care less.
I do care here. In this order: Security, Interoperability, Usability.
In case a system is older than that, I doubt it can be considered secure anymore.
Because of? Using RSA?
Lack of updates (see above). RSA is a smaller (performance) problem in my eyes.
So if there is a reason why RSA should not be used here anymore I would agree to drop it. Now, we are just diminishing interoperability without any gain in security. There is no point in that.
Performance? How many logins do you perform a second? Thousands? This matters for HTTPS maybe with hundreds or thousands of handshakes per second but not for SSH.
If you disable RSA in your client, you will still use the new fancy crypto stuff and save a couple of nanoseconds :)
+# see also: https://stribika.github.io/2015/01/04/secure-secure-shell.html +KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange- sha256 +Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes256-ctr +MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com, umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com
+# enable data compression after successful login +Compression yes
Is there any research on whether this still is safe?
Not really. https://www.openssh.com/txt/release-4.2 states "delayed" more for compression is more secure as it avoids possible zlib vulnerabilities to unauthenticated users (Simple, but I was unaware of it.):
That is a different attack then.
ACK. Sorry for mixing things up here.
The OpenVPN issue is about a known-plaintext attack which could also be done (in theory - I think) on SSH unless they add any random padding which would increase overhead and reduce the bandwidth savings of the compression.
Added a new compression method that delays the start of zlib compression until the user has been authenticated successfully. The new method ("Compression delayed") is on by default in the server. This eliminates the risk of any zlib vulnerability leading to a compromise of the server from unauthenticated users.Compression does not seem to have security impact to a SSH connection itself. Because of the security risk described above, I'd prefer "delayed" as a setting to this in a second version of the patch.
That doesn't have anything to do with the stated attack, so I guess it doesn't make much of a difference to me.
[...]>> +# EOF
By the way: https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=16c31d10040db4f175642376... sets 22 as default listen port for OpenSSH, so I did not include 222 anymore. Agreed?
22 is now default, but of course the switch on the webUI should still work.
Okay, thanks. Will send in a second version of this patch.
Best regards, Peter Müller
[snip]--
Microsoft DNS service terminates abnormally when it recieves a response to a DNS query that was never made. Fix Information: Run your DNS service on a different platform. -- bugtraq