Our external scanners are complainging out us telling the world the
exact version of sshd we are running.

The common arguments are:
1) Script kiddies don't test versions anyway.
2) It helps clients work around bugs.
3) Security through obscurity
4) It makes it harder for a sysadm to verify the version that is
running.


My concern is the real information this is disclosing is our internal
update policy. It lets outsiders know how quickly or how slowly
we are to patch systems and I think reviling that is a valid security
concern.


Comments about the common arguments:
1) Seems to be mostly correct with today's bot driven attack vectors.

2) The current code (openssh-5.0p1/compat.c) lists OpenSSH_3.1* as
the last version where it has to do anything special.

3) We know security through obscurity doesn't work but there is an
argument to not lay all the cards on the table due to that whole
rings of security concept even if some of the rings are mostly
porous. Also it can revel other information like how long it
takes my change mangment system to roll out a patch to production.

4) sshd -v currently just outputs SSH_VERSION which is commonly
hacked to hide the version resulting in no useful command line to
verify the correct version. A solution to this could be to do a
hash of something in sshd_config and the real version number and
append that to the current minor/major version:

telnet 0 22:
SSH-2.0-OpenSSH_5.0

using "HashHello MySecret" in sshd_config could result in:
telnet 0 22:
SSH-2.0-05e484f05ab1930f2b14f00ca980457b
(which could be the result of echo "MySecretOpenSSH_5.0" | md5 if
a weak hash was used)

That would result in the ability to remote managment system to
detect out of date versions and the secrecy of the version info is
left to the sysadmin. The protocol limits this to about 100
characters so maybe just a checksum or truncated hash suffice.

Does the protocol send the version string at some other point along
the protocol negotiation?

Comments?

-tim
http://web.abnormal.com