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