IETF-SSH archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: An additional-auth mechanism for SSH to protect against scanning/probing attacks
> [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 mouse%rodents-montreal.org@localhost
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Home |
Main Index |
Thread Index |
Old Index