-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Mon, 2018-08-20 at 17:06 +0200, Peter Müller wrote:
Hello Michael,
Hey,
On Sun, 2018-08-19 at 20:41 +0200, Peter Müller wrote:
In order to harden OpenSSH server in IPFire, using the upstream default configuration and edit it via sed commands in LFS file is error-prone and does not scale.
Thereof we ship a custom and more secure OpenSSH server configuration which is copied into the image during build time.
Fixes #11750 Fixes #11751 Partially fixes #11538
Signed-off-by: Peter Müller peter.mueller@link38.eu
config/ssh/sshd_config | 68 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 68 insertions(+) create mode 100644 config/ssh/sshd_config
diff --git a/config/ssh/sshd_config b/config/ssh/sshd_config new file mode 100644 index 000000000..7acf48109 --- /dev/null +++ b/config/ssh/sshd_config @@ -0,0 +1,68 @@ +# ultra-secure OpenSSH server configuration
+# only allow version 2 of SSH protocol +Protocol 2
+# listen on these interfaces and protocols +AddressFamily any +ListenAddress 0.0.0.0 +ListenAddress ::
+# 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.
+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.
OpenSSH default is 10, but this seems too high for me.
This sounds good to me.
+# 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.
PuTTY doesn't have an update mechanism and therefore will probably be installed once and never updated on the average admin's machine.
In case a system is older than that, I doubt it can be considered secure anymore.
Because of? Using RSA?
+# 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.
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.
- -Michael
Best regards, Peter Müller
-Michael
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