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(a)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)?
> 
>> +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.

OpenSSH default is 10, but this seems too high for 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.

In case a system is older than that, I doubt it can be considered secure anymore.
> 
>> +# see also: https://stribika.github.io/2015/01/04/secure-secure-shell.html
>> +KexAlgorithms curve25519-sha256(a)libssh.org,diffie-hellman-group-exchange-
>> sha256
>> +Ciphers chacha20-poly1305(a)openssh.com,aes256-gcm(a)openssh.com,aes256-ctr
>> +MACs hmac-sha2-512-etm(a)openssh.com,hmac-sha2-256-etm(a)openssh.com,
>> umac-128-etm(a)openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128(a)openssh.com
>> +
>> +# enable data compression after successful login
>> +Compression yes
> 
> Is there any research on whether this still is safe?
> 
>   See: https://bugzilla.ipfire.org/show_bug.cgi?id=11819
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.):

>     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.
> 
>> [...]>> +# EOF
By the way: https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=16c31d10040db4f175642376b284a0f98609e19e
sets 22 as default listen port for OpenSSH, so I did not include 222 anymore. Agreed?

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