ssh security

Wed Jan 4 02:30:51 UTC 2006

On Tue, 2006-01-03 at 18:47 -0600, Jeff Vian wrote:
> On Tue, 2006-01-03 at 11:26 -0500, Michael H. Warfield wrote:
> > On Tue, 2006-01-03 at 13:44 +0000, James Wilkinson wrote:
> > > Jeff Vian wrote:
> > > > http://www.csc.liv.ac.uk/~greg/sshdfilter/
> > > > 
> > > > I use it on several servers and it works really well to detect and block
> > > > attacks.
> > > > With it an attempt to login with an unknown account gets instantly
> > > > blocked, and with a known account (root or some other user) they only
> > > > get 6 attempts before it is blocked.
> > 
> > > That sounds worthwhile for a computer that only has SSH open to the
> > > network.
> > 
> > > However, do be aware that this can confirm to attackers that an account
> > > is "valid", which could be useful knowledge in other attacks.
> > 
> > 	Agreed!  That, in an of itself, is a security hole!  It can reveal, to
> > unauthenticated connections, what are valid accounts and what are not.
> > I've published security advisories on just those sorts of "information
> > disclosure" vulnerabilities.  It's considered axiomatic that security
> > systems should NEVER disclose that level of information, even to the
> > point of not giving a different error (message or code) for invalid
> > password vs invalid account.  Even timing (responding too quickly if the
> > account doesn't exist compared to wrong password) is considered a
> > SERIOUS no-no.  I would have to consider that sshdfilter a security
> > vulnerability, not a security tool.  Where this something in common
> > distribution, it would probably end up being a featured subject on
> > BugTraq or FullDisclosure.  :-/
> > 
> If this system had many user accounts I would worry about that.
> However, the only valid accounts that are ever hit are the standard
> system accounts (and over 99.9% are root, which does not get ssh access
> anyway)

	Wrong thinking...  You've still revealed to them what you have and what
you don't have (meaning what not to try)...  Do they need to know that
information?  Do you want them to have that information?  You are
disclosing information to them.  To what advantage and to who?

> Besides, a script kiddie (or even a determined attacker) will give up
> quickly if the passwords are strong and they only get 6 tries in every 3
> days (or longer)

	You're thinking is about least 5 years out of date.  You're still
thinking in the "snot nosed hippy hacker" model and what we have now is
the "Automated, Russian Mafia, Organized Crime" model.  It's all
automated and computers don't "give up".  There's no PFY (Pimply Face
Youngster) sitting at a keyboard thinking "what password do I try
next..."  Even they've used automated scripts for years now, IAC...
There are even some bots and apps that attack you from different IP
addresses if you use IP based defenses, or can result in a denial of
service attack by locking accounts if you use account lockouts.

> I acknowledge the flaws, but it is better than leaving ssh open for
> repeated attempts by the script kiddies.

	No, actually, it's not.

	You haven't enumerated a single advantage to this system, short of some
minor bandwidth issues and, maybe, some minor noise in your logs.  You
haven't enhanced your ssh security at all.  I can't see any advantage
here at all.

	If there is no account there, then having them hammer on sshd does no
harm (and even slows them down in the attempts).  Hell, I could care
LESS if they are hammering on "demo" (one of the popular ones, for some
reason, ATM...) if there is no "demo" on the system.  All you get is log
noise telling you someone is knocking on the door.  Shrug...  Yawn...
"grep -v"...

	If there is an account there, it still makes no difference.  You've
still got the same authentication limits as before from sshd.  You don't
need a script for that.  The "unauthenticated" holes in ssh/sshd have
been far and few between (and, YES, as the Senior Researcher and Fellow
on the X-Force at Internet Security Systems, I WAS involved in the
issues that resulted in OpenBSD changing their page from "no remote
holes in xxx years" to "only one remote hole in default install in xxx
years" over ssh, so you could say I know a little bit about this sort of
thing with ssh).  You want some real security, you might try "port
knocking" (which I am NOT advocating) or IPv6 (which I use on all my
servers).  The average, run-of-the-mill, brute force attacks on ssh I've
been tracking over the last several years are nothing more than amusing
automated noise.

	So...  No advantage if the account isn't present and no advantage if
the account is present...  Not a lot left for a domain of applicability
here.

	What you HAVE done is indicated what accounts are present on your
system and what accounts are not.  You've given them information (which
CAN be automatically logged, if recognized) which they DO NOT NEED TO
KNOW.  Even if it's only "gee, he only has some system accounts", it's
still telling them something (like what not to try).  In fact, the only
thing you've done is tell them something you don't want them to know
(what accounts you do or do not have on the system) AND you've made it
more efficient for them (fast rejects and no retries).

	At this point, your only saving grace is that none of the automated
bots and mass-autorooters will take any notice at all of your filtering.
It actually WOULD take some snot-nosed liveware looking at the results
from hitting your system and thinking "That's weird.  It shouldn't act
like that...  Maybe I should look at these clowns closer...  They don't
seem very smart."  Fortunately, those, now-a-days, are VERY few and far
between.

	You say it's better than...  Ok...  Describe your threat model where
the attacker stands a better chance of breaking into your system without
that filter.  I would argue that he stands a better chance of breaking
into your system WITH that filter because it reduces the effort he has
to go to in order to determine the accounts which he may be able to
attack on the system.  You've reduced his search space and reduced his
work effort.  I see no threat model which this filter addresses and
improves your security.

> > > Hope this helps,
> > 
> > > James.
> > > -- 
> > > E-mail address: james | Say it with flowers, send a triffid.
> > > @westexe.demon.co.uk  | 
> > 
> > 	Mike

	Mike
-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471        | possible worlds.  A pessimist is sure of it!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-list/attachments/20060103/4a519802/attachment-0001.sig>