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: Thu, 23 Aug 2018 21:37:25 +0200 Message-ID: <9990ba87-9274-03f1-fd67-bab04643b14e@link38.eu> In-Reply-To: <8290e4283649d0fa5ccad2b0ba34ecfd6b798336.camel@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4776762050819479725==" List-Id: --===============4776762050819479725== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Michael, > [snip] >>>> + >>>> +# limit authentication thresholds >>>> +LoginGraceTime 20s >>>> +MaxAuthTries 3 >>> >>> Three is definitely too little. I have three versions of my key (RSA, ECD= SA and >>> Ed25519). After my client tried all of these, a password prompt won't be = shown >>> any more. >=20 >> Is 30 seconds enough (default setting in IPFire 2.x)? >=20 > 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. >=20 >>> >>>> +MaxSessions 5 >>> >>> Per user? Why? >=20 >> Because most users do not connect to a machine multiple times - at least n= ot 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. >=20 > 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. :-) >=20 >> OpenSSH default is 10, but this seems too high for me. >=20 > This sounds good to me. All right, I will use this value. >=20 >>> >>>> +# 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 h= ave >>> discussed that before in another thread to a patch that only enabled this. >=20 >> 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 cli= ents) >>> >>> *How* outdated? From the 90s or last year? >=20 >> 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 m= ore >> or less up to date clients (<=3D 1 year for PuTTY and <=3D 4 years for Ope= nSSH) >> can be used. >=20 > 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. >=20 > 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. >=20 >> In case a system is older than that, I doubt it can be considered secure a= nymore. >=20 > Because of? Using RSA? Lack of updates (see above). RSA is a smaller (performance) problem in my eye= s. >=20 >>> >>>> +# see also: https://stribika.github.io/2015/01/04/secure-secure-shell.h= tml >>>> +KexAlgorithms curve25519-sha256(a)libssh.org,diffie-hellman-group-excha= nge- >>>> 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)openss= h.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=3D11819 >=20 >> 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.): >=20 > That is a different attack then. ACK. Sorry for mixing things up here. >=20 > 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. >=20 >>> 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. >=20 >> Compression does not seem to have security impact to a SSH connection itse= lf. >=20 >> Because of the security risk described above, I'd prefer "delayed" as a >> setting to this in a second version of the patch. >=20 > That doesn't have anything to do with the stated attack, so I guess it > doesn't make much of a difference to me. >=20 >>> >>>> [...]>> +# EOF >=20 >> By the way: https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommit;h=3D16c3= 1d10040db4f175642376b284a0f98609e19e >> sets 22 as default listen port for OpenSSH, so I did not include 222 anymo= re. Agreed? >=20 > 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=C3=BCller > [snip]--=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 --===============4776762050819479725== Content-Type: application/pgp-signature Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" MIME-Version: 1.0 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KCmlRSXpCQUVCQ2dBZEZpRUV2UDRTaUdoRVlE SnlyUkxrMlVqeUQzMTduMmdGQWx0L0RQVUFDZ2tRMlVqeUQzMTcKbjJqdUdRLzlFdlVEMCsyN283 WGhpdnQvYlkxaUxUbUZueHB0UWY0bm1pS04vblVXZDZsY2N4bFJqY0hkT0JTRApQb1JNUzViMnZG ZWhMSE9iWkVXU3hJbjJlMG9xL1dWSHFOd3hXQ2FEWm1PRUdXeXNxdEVxTUtkcHQ3V2djR2FpCmJP YWM4WjZhV2NuZkVQZytiK0lEV0tBanlPcG45blBNMzhhUGFRdUtEVGpWWmoxSXR2WXgzb2NvTnRH QXVSOXoKNS9HUVVqZVNKd3Y3WDJGVnFOOVRJUTU3MkxsZ1h0U0tRTm8rWTZrSmVRSCtycW1HK1h4 QXB5ZkxLdDZEcTlLbQpaeWZRQTBzM0MxeVg0dFExNnkwbVNvMFBRS2tuZlpuYnhHTjhFLy9UQ1Fa ZVNUQXVTakgxR2VVTkt3SHF4UytDClh0anZoa292QzBrWUZSZzNCcWVyZVBHVTFYYVJ5WFJyTW9o ajlXZVBXSUtud2hsd2lhUXBZc0VnQVFoaEg1aGQKQU8rTFZkMlNjdVBKYVJJYVZuU2szZ0hlczBY WE9OSFRHbDdiVGs4bHhlV2ZZZFV4Z2tWclQ1dWNHU3RXZzhFbwoxVmY3b0tmWmMzRldJRlZiQTNF QVRNWUprcVNmR1ZiMDJZNnZOM3VSdVpwNnFCL1NhekZRU2p3Y21haWtWNlNVCmc4dk9IaS92aGRw NHhueERmOG1relZBcUtLL3JxSGlJYk5Ua3lJYWxaWmo2TGVsaXE2U0V0dzVBeCtIeThsLzMKeXpS VnZ3N3UyQXhPalV4SjVFQTlaNGZRbUhPemQvRnFFK0NyNzZMNWM1Rkw4QzZtcWhkTmJSeWk0S0Mr ZFNOUwo1UnhRcHV2VlA0RFBBQlE1a0pIanVmK0piSlByWHo0ZlRCS3pMS3I5alpreWxhSnN0cHM9 Cj05MFVRCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQo= --===============4776762050819479725==--