Re: An additional-auth mechanism for SSH to protect against scanning/probing attacks
Mouse <[email protected]> Wed, 30 Nov 2022 09:28:19 -0500 (EST)
| Newsgroups | gmane.ietf.secsh |
|---|---|
| Message-ID | <[email protected]> |
> [I]t adds a shared-secret HMAC to the handshake packets so you can't > get past step 1 of any attack because you can't even start a > handshake. It's a really nice defence-in-depth measure, even > pre-auth 0day won't work any more when this is used. Well, potentially could; the attack just needs to use a hole in the (small) attack surface that's still exposed. This is just about minimizing the attack surface that's exposed to clients that haven't passed the challenge. > The simplest way to implement this would be to add a > challenge-response to the first thing transmitted, the SSH ID: > Server: "SSH-2.0-softwareversion-challenge" > Client: "SSH-2.0-softwareversion-response" I've added the necessary primitives to moussh to support the admin configuring this. My proof-of-concept implementation's banner looks like SSH-2.0-moussh-0.9.368aa66133 (id=e0565cde4c91007c1737c158424c8ad4 nonce=d92caf640c06) but it would be easy enough to put the values into the software-version instead. Indeed, if different implementations are incompatible, to some extent that acts as another layer of prefilter - provided the client(s) you want to use can be configured compatibly to the server(s) you want to use. > Cue debate over whether the challenge and response should be treated > as part of 'softwareversion' or used as the 'comments' string. I don't see any reason that needs to be standardized, except for the benefit of people who want to mix-and-match implementations between server and clients. That's worth supporting, certainly, but there's no reason a relatively private case, such as mine, couldn't use a nonstandard form (once there is a standard). > And definitely not in the optional subsequent lines of data which > causes some implementations to choke when they see them. That sounds to me like a reason to use them, not a reason to avoid them. I thought the point of this was to break attacks from disapproved clients. If you use something that breaks disapproved clients before they even _look_ at the challenge, isn't that even better? /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML [email protected] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B