Re: [PATCH 1/2] add hardened SSH server configuration

[Michael Tremer <michael.tremer@ipfire.org>]

[-- Attachment #1: Type: text/plain, Size: 7014 bytes --]

-----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(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)?

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(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.):

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=16c31d10040db4f175642376b284a0f98609e19e
> 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
> 
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE5/rW5l3GGe2ypktxgHnw/2+QCQcFAlt+u/oACgkQgHnw/2+Q
CQcDGBAAgBF/b0WDpQ1Lds+KDTKlvEKo2+WInK1+0ZGKeB88+CFL40RAkwLjG1VT
0k7DJ4+cnHn+114qhnrqxJ9LXzxchIE+BIJFcfD+dDhWueNjPZUWSCXznPPxJatO
iXZm8ILlKwUkSKgL5apUvBxMe4Sk68zdwV0vSMCUh3PziRgAHA/d7txp0391oZU1
BhWD4mKYGo9ZVYywIk0oXyttLB0CNK+YT0WYP3rwy7/K5yj+iC9d8lqHLj00YwYB
iNfswwPG+E/MbKxsJdqMfu4Glco8KL+MAs/7Nke4Ms1vWGktmAzHR1dIk9Z6A+59
MtkcvojVfoOJ6pI5AVDKIQ66tn08X1dEo8vnHuG6OlZcrtyC6wWAXGn6BqiX/IJS
rCYoBteiCV8EJI0SZgk2hUSyLAfPpkt4KBko42FIgO4oHsASofe51ALYceKOSHp1
6TJBQ1JdWpPc1cl0lQxhRGcGXQ9n7gfE6mXY2NdNEFh9V5M8kTO/CafGgcwwHdF/
RF7cjYGw3BAei5B9e11qiIzqIe5SV7EB0xMjDfzQeloIOl+6SQQdzv0U3Kl/PNg5
WXraj6HuRM5KYLmSW5BXtV3ujBqnaVRH8YZ9/Hij7MFKN7eK6Kt8yzFqtLUiPywP
9lClzdt6No5g/YBB97eKMYBgFuHnTM9d/uTmtR/RBk6ItmRCgXc=
=+HiS
-----END PGP SIGNATURE-----