From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter =?utf-8?q?M=C3=BCller?= To: development@lists.ipfire.org Subject: Re: [PATCH 1/2] add hardened SSH server configuration Date: Mon, 20 Aug 2018 17:06:28 +0200 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0137841649261203431==" List-Id: --===============0137841649261203431== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Michael, > Hey, >=20 > On Sun, 2018-08-19 at 20:41 +0200, Peter M=C3=BCller 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=C3=BCller >> --- >> 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 >=20 > 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 sh= own > any more. Is 30 seconds enough (default setting in IPFire 2.x)? >=20 >> +MaxSessions 5 >=20 > 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. >=20 >> +# limit maximum instanctes >> +MaxStartups 5 >> + >> +# ensure proper logging >> +SyslogFacility AUTH >> +LogLevel INFO >> + >> +# always turn on strict mode >> +StrictModes yes >=20 > 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 sli= pped my mind. >=20 >> +# only allow safe crypto algorithms (may break some _very_ outdated clien= ts) >=20 > *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 (<=3D 1 year for PuTTY and <=3D 4 years for OpenSS= H) can be used. In case a system is older than that, I doubt it can be considered secure anym= ore. >=20 >> +# see also: https://stribika.github.io/2015/01/04/secure-secure-shell.html >> +KexAlgorithms curve25519-sha256(a)libssh.org,diffie-hellman-group-exchang= e- >> sha256 >> +Ciphers chacha20-poly1305(a)openssh.com,aes256-gcm(a)openssh.com,aes256-c= tr >> +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 >=20 > Is there any research on whether this still is safe? >=20 > See: https://bugzilla.ipfire.org/show_bug.cgi?id=3D11819 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.=20 > The new method ("Compression delayed") is on by default in the=20 > server. This eliminates the risk of any zlib vulnerability=20 > 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. >=20 >> [...]>> +# EOF By the way: https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommit;h=3D16c31d1= 0040db4f175642376b284a0f98609e19e sets 22 as default listen port for OpenSSH, so I did not include 222 anymore.= Agreed? Best regards, Peter M=C3=BCller >=20 > -Michael > --=20 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 --===============0137841649261203431== Content-Type: application/pgp-signature Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" MIME-Version: 1.0 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KCmlRSXpCQUVCQ2dBZEZpRUV2UDRTaUdoRVlE SnlyUkxrMlVqeUQzMTduMmdGQWx0NjJQc0FDZ2tRMlVqeUQzMTcKbjJoWktnLzlGZEt1SHUwdEk3 ZnlZaE5EQ1UzbWt2NVRsNTFycWl5QjRnUjM3VFdocTVNWHNVbjc2aXg3K1JOdgpGM2xOSjBhOFp3 Vk5sR3NQRFpFeVI5UnRUNzJpUk1Ubjl2anl1UEVjZWd0bGowbElXM0l4d0toYThjUXk4a0VqCjNl cG1Jb25nMnJrVzVnclR4RnRsZUJqWVFIUUtSRzdFRitLTkp4YTMvZzUyMmpTUkxqcUxRdHpvNmZL QkZoUVQKUGFkREZYWmlaMmM5MXdqVVp2T3R2ODR3QWIzUGlxeUhYWjdNR2tUVW5iSVBBQVJ4MEZG dTFLVk1ETVhMZ28vMwp4aEhkSmc5N1BKWnl3cHp1RlV3TU51WHJ4cWNFVVdNbFZSN2tmSzhoRE0y OVp1WnJEdVZNUXVrcUhlbEpUcnBmCjVZNWlnNVRzOGZNb3g1TzFQelZid2VkR2RjdUN0YUwzdGtx Zm1tZ2N3bkJydmNyNksvTEFJU1RZTGtGcWdNMDQKZmw5NUtWQVIwUDhQUUtLblhpSnNxM3QyRm9x Wlhock9zNkpSdVZXYVY5TTEzSXJlZWFsSkw5M3VvYndOUXhCKwo1Q25jZFB4WHB5QUZkZG5ROEtz N28xa3dRYnVxVGhFZ2JWNHVTaldLVUFTTEI1dXovRnNSYU05NHFvbHhoTUpQCnJKUFhIWXpldHQ3 UVB4MzhBMnlVRi8rKzBNU01HbGN6Z2tsMXB3aHNZMXFTSkQrQ1duV2NPRHRXUFEyaEtEcHQKQnd1 UUhMUjlzL1kxWmx2dUtKVER0QUZQQWJBN3piUjJDY2d1QU10RGtoRGhvOTR3WGwrTjNtc2dxVGNn ei92Uwp3bnhEcmhidWZvZ2RDdlcreDlscEZJRTYwSHpRZGxLUDNOU204bnczL2RFQWdyYU5zRHc9 Cj1ocGpXCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQo= --===============0137841649261203431==--