The intent of this option is similar to "tls-auth" in openvpn[1]: To refuse to talk to anyone who doesn't know the shared secret. You could compare this to port knocking, in that it solves a similar problem. This also prevents RST attacks from killing an existing connection, even when attacker can sniff sequence numbers. This feature doesn't work through NAT, since the source and destination are signed. As IPv6 becomes more and more prevalent it'll become possible to use this in more and more deployments. The socket option is enabled *after* connection establishment, thus doesn't protect against SYN floods. This is because server doesn't know (in userspace) what the address of the peer is until they connect. Again because signed addresses. Setting up: * Add "TCPMD5 foorbarSecret" to sshd_config * SSH with "-oTCPMD5=foobarSecret" Patch attached, but it's an ugly patch for 7.1p. I didn't want to put too much effort into cleaning up and documenting everything if the concept itself would rejected outright. It needs formatting, portability, apply to CVS HEAD, and include file changes at least. But it works on Linux as is. Everything signed from fourth packet: 16:32:40.902764 IP 127.0.0.1.51216 > 127.0.0.1.2222: Flags [S], seq 2342692369, win 43690, options [mss 65495,sackOK,TS val 51101999 ecr 0,nop,wscale 7], length 0 16:32:40.902777 IP 127.0.0.1.2222 > 127.0.0.1.51216: Flags [S.], seq 514139093, ack 2342692370, win 43690, options [mss 65495,sackOK,TS val 51101999 ecr 51101999,nop,wscale 7], length 0 16:32:40.902789 IP 127.0.0.1.51216 > 127.0.0.1.2222: Flags [.], ack 1, win 342, options [nop,nop,TS val 51101999 ecr 51101999], length 0 16:32:40.903480 IP 127.0.0.1.51216 > 127.0.0.1.2222: Flags [P.], seq 1:22, ack 1, win 342, options [nop,nop,md5shared secret not supplied with -M, can't check - 2daa171c0c342b041da3cb79ecd1d11b,nop,nop,TS val 51101999 ecr 51101999], length 21 So, how about it? Worth cleaning up? [1] https://community.openvpn.net/openvpn/wiki/Hardening#Useof--tls-auth -- ? Thomas ? -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-working.patch Type: text/x-patch Size: 8882 bytes Desc: not available URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20160114/e8f5a553/attachment-0001.bin>
On Thu, Jan 14, 2016 at 7:20 PM, Thomas ? Habets <habets at google.com> wrote:> * Add "TCPMD5 foorbarSecret" to sshd_config > * SSH with "-oTCPMD5=foobarSecret"Have you considered making this a stand-alone tool? Something that listens and execs sshd -i on the server side and could be used as a ProxyCommand on the client side. That'd be potentially usable by other services. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.
On 14 Jan 2016, at 08:20, Thomas ? Habets <habets at google.com> wrote:> The socket option is enabled *after* connection establishment, thus > doesn't protect against SYN floods. This is because server doesn't > know (in userspace) what the address of the peer is until they > connect. Again because signed addresses.So could they exchange a secret as part of the session, obviating the need for any set up? -- Alex Bligh
Quoting Alex Bligh <alex at alex.org.uk>:> So could they exchange a secret as part of the session, obviating > the need for any set up?If by set up, you mean "the rest of the SSH authentication", then surely not. MD5 pre-shared secrets are probably fine for "port-knocking" or even RST-proofing purposes, but not for authenticating SSH sessions to servers. =M=
On 15 January 2016 at 08:48, Alex Bligh <alex at alex.org.uk> wrote:> > The socket option is enabled *after* connection establishment, thus > > doesn't protect against SYN floods. This is because server doesn't > > know (in userspace) what the address of the peer is until they > > connect. Again because signed addresses. > So could they exchange a secret as part of the session, obviating > the need for any set up?They could. Making it part of the protocol does expose more code to be vulnerable to any preauth attacks though. One of the main benefits is that if the remote end doesn't have the right key then the data won't even be parsed. IIRC this has protected OpenVPN installations with its tls-auth option when there's been OpenSSL and/or OpenVPN bugs. You could, for example, set the key to SHA256(SSH session key) or something, since a session key is already negotiated for the connection. (this is just what comes immediately to mind) It'd be hard to automate and make default though, since if done when the connection goes through NAT it will fail the connection. You could work around that by only enabling it for IPv6, and hope that nobody's doing IPv6 NAT. It'd still protect against other attacks like third parties fiddling with an already established connection, be it by RSTing because they know the accepted RST window or more sophisticated attacks. But again, only solves a subset of the problems. -- ? Thomas ?
On 14 January 2016 at 20:57, Darren Tucker <dtucker at zip.com.au> wrote:>> * Add "TCPMD5 foorbarSecret" to sshd_config >> * SSH with "-oTCPMD5=foobarSecret" > Have you considered making this a stand-alone tool? Something that > listens and execs sshd -i on the server side and could be used as a > ProxyCommand on the client side. That'd be potentially usable by > other services.No I hadn't. Good idea. I think there may be some aspects you'd be missing out on (or reimplement, or outsource to e.g. inetd), such as (account) password brute force protection. I haven't tried it, but I suspect sshd -i can't limit to 10 concurrent preauth sessions each getting one attempt per second which sshd otherwise does by default. -- ? Thomas ?