[ale] any suggestions on an automated method for blocking repeated failed ssh login attempts?

[Jim Kinney]

On Fri, Dec 24, 2010 at 12:59 AM, Michael H. Warfield <mhw at wittsend.com>wrote:

> On Fri, 2010-12-24 at 00:21 -0500, Jim Kinney wrote:
> > Here's a scenario:
>
> > multiple rings of security with the innermost having FBI background
> checks
> > and security clearances, vault doors, dedicated fiber lines, treason
> > convictions etc. I work with the stuff outside of that arena and it has
> two
> > layers: non-classified but sensitive and/or export controlled, and
> > non-classified and not export controlled. Certain groups of people are
> not
> > allowed to connect except to the outermost , unsecured network.
>
> Yeah, pretty much standard fare.
>
> > People need to be able to ssh into the controlled arena to "do things".
> The
> > laptops are currently not full drive encrypted (windows is a problem and
> the
> > Mac systems have a different issue - no one is use Linux laptops which
> don't
> > have a problem with drive encryption). So the need to keep ssh keys
> > encrypted is high.
>
> > In general, people are lazy. If they can find a way to remove the
> encryption
> > from the key, they will. Thus the need to find a way to test if a users
> key
> > is _still_ encrypted.
>
> What you have just described, to me, screams "smart keys".  Putty,
> Absolute telnet, et al ssh clients support these things and this is the
> only really effective way to deal with this.  The keys are on a USB
> smart-key (NOT a USB memory key or SSD) or a smart card w/ reader and
> you don't need to worry about this.  They CANNOT screw it up.  They have
> to enter a PIN and get it right.  No intruder, NO INTRUDER, can extract
> that private key.  The gov has these keys now.  I forget the acronym but
> it's something like UAC (Universal Access Control) or some such.  This
> is a solved problem and ssh works with it very well.  I have keys on my
> Aladden smart key for ssh access.  You would have to steal the key and
> beat the PIN out of me (3 failures locks the key and requires a security
> officer key to reactivate).
>

Ah ha! CAC. I've seen this acronym around. crypto-access-card maybe.  I will
start the push for more info on those and some details on usage.

>
> > the only reason I have for keeping keys in the vault is for back checking
> in
> > the event of a breach. The key hash is more important to me as it can be
> > sent around and used to check if a key is encrypted or not. It the new
> key
> > has matches the original bare key hash, bad times are in order.
> >
> > The pub key in ldap gives a way to quickly add/remove access for a key
> user.
> > I wish it was a standard thing in sshd.
> >
> > I see your point about access keys and no need for escrow. I need to look
> at
> > auditd logs a bit more but I think they don't have that level of detail
> > during a connections authentication section.
> >
> > These remote machine are OS controlled by me and the others I work with
> so
> > it's possible to add in an sshd that allows a connection back triggered
> by a
> > connection to my network. That back connect can run a hash on the
> connected
> > user's priv key and compare it to the one hash of the unecrypted key
> stored
> > earlier.
>
> > This would be easier if ssh had a patch that allowed a compile flag
> > requiring a password on keys.
>
> This is intrinsicly and inherently impossible.  It would violate a very
> principle of cryptography.  Such a thing could only be enforced at the
> client but the server would have to depend on the client and the client
> must be assumed to be NOT trustworthy, only the key is the key and to be
> the determining factor.  Therein you have a conflict.  How does the
> server validate that the client truthfully enforces the policy that
> allows or disallows the keys.  This can not be.  Such schemes can not
> work.
>

It would be the ssh client side thing only.

>
> > Happily, most of the people that need this access are mostly carbon-based
> > life forms. A few are probably part silicon and sulfur...
>
> :-P
>
> > On Thu, Dec 23, 2010 at 11:50 PM, Michael H. Warfield <mhw at wittsend.com
> >wrote:
> >
> > > Hello,
> > >
> > > Good to have triggered some interesting discussion on this.  I can see
> > > that I'll have a VERY lively session if I do my ssh talk at ALE.  Aaron
> > > and I can work out the scheduling details later but I think this will
> > > have to go on the calendar for some upcoming month.  Probably later
> that
> > > sooner, unfortunately, but we'll make it happen.
> > >
> > > On Thu, 2010-12-23 at 16:02 -0500, Jim Kinney wrote:
> > > > On Thu, Dec 23, 2010 at 3:29 PM, Michael H. Warfield <
> mhw at wittsend.com
> > > >wrote:
> > > >
> > > > >
> > > > >
> > > > > I know I'm doing my IPv6 talk next month for ALE.  Maybe I need to
> > > > > schedule my talk on "Securing the Secure Shell" some time in the
> next
> > > > > few months as well.  I gave that talk in front of AUUG a while back
> but
> > > > > I don't think I've delivered it at ALE before.
> > > > >
> > > > > I am all for hearing it! Aaron please contact MHW ASAP before he
> > > changes
> > > > his mind! :-)
> > >
> > > > At work, I'm prepping an ssh-key repository to ensure that all keys
> use a
> > > > good password.
> > >
> > > I'm not totally sure I perceive the threat vectors you hope to address
> > > or where they stand on an attack tree here, but...  Ok...  Lets work
> > > with this and see where it leads.  Yes, I can see some similarity
> > > between strong passwords on PGP keys and this but the similarity is
> > > somewhat superficial since they keys are used for totally different
> > > things and other environmental factors come into play.
> > >
> > > > The repository will generate the ssh keys for the users and
> > > > archive the original, no password key in a vault (literal, steel
> vault
> > > with
> > > > key as text on paper with a barcode for fast input, placed there buy
> > > someone
> > > > with a firearms license at the federal level), then the user must
> enter a
> > > > password to encrypt the key.
> > >
> > > As a cryptographer, any system generating keys for a user stands the
> > > hair up on the back of my neck.  It also runs contrary to a number of
> > > strong crypto systems which would preclude it to some extent or
> another.
> > > To use my analogy a bit further, the idea of generating PGP keys for
> > > users would be totally abhorrent and unacceptable to me and violates
> > > many of the basic PGP principles.  But, these are not the same thing
> and
> > > this very thing is common in X.509 client certificates where a site
> > > generates a complete PKS12 key and cert pair (which I also think is an
> > > abomination but that's grist for another rant on another day) for a
> > > client and then E-Mails it to them with a transport passphrase (sigh).
> > >
> > > > That encrypted key is then copied to their
> > > > thumb drive and the original unencrypted is hashed, wiped and the
> hash
> > > > stored. Their pub key is placed in the ldap server.The sshd is a
> modified
> > > > one that locates ssh pub keys from ldap. It is also configured to
> never
> > > > allow a password entry.
> > >
> > > That sounds sort of reasonable but I'm not sure of the value-add in the
> > > complexity of this is unless the real goal is an escrow or backup of
> the
> > > private keying material.  If that private keying material is intended
> > > primarily for authentication, then I have to feel this is all a bad
> > > idea.  Having a backup for a key used to protect data at rest, such as
> > > PGP keys, is generally a good idea.  Having a backup of private keying
> > > material primarily used for authentication is almost always a very bad
> > > idea.  You don't gain anything by it.  If someone loses an
> > > authentication key, you simply replace the authentication key and reset
> > > the public keys for the authentication and nothing is lost.  If you
> lose
> > > a key for data at rest, the data is lost.  That's not the case with an
> > > authentication key, like this, though.  I don't see the value in the
> > > keystore and this complicated handoff.
> > >
> > > > The complicated (and unwritten) stage is to devise a method that
> checks
> > > the
> > > > connecting users priv key for being still password locked once they
> log
> > > in.
> > > > If it's NOT locked, they are kicked out and the pub key is removed
> from
> > > > ldap. Not sure yet on how to do this.
> > >
> > > I would have to say this is just about impossible and should be
> > > impossible, even in principle, on several levels.  How do you deal with
> > > the case of ssh-agent where the keys have been loaded and cached?  What
> > > if they are hosted on an unlocked smart-card?  How do you detect if
> they
> > > were originally password protected or not?
> > >
> > > What about if they are forwarded using authentication forwarding?  This
> > > is actually an incredibly powerful facility allowing remote system to
> > > remote system authenticated key access while never hosting private
> > > keying materials on any remote server.  How would you deal with
> > > automated processes (not all of this is run by a carbon based life form
> > > pounding  at a keyboard)?
> > >
> > > Example...  From an lbb (Little Black Box) located somewhere, a cron
> job
> > > runs a process that begins a process on a remote server.  The key
> > > required for that process is stored on the lbb and loaded into an
> > > ssh-agent process for the duration of this operation.  More so, the
> > > ssh-agent uses a script to validate each authentication request using
> > > the request acknowledgment hooks.  The remote system, with no private
> > > keying material present, at some point initiates a connection to yet
> > > another remote server for, say, backup transfers.  The connection is
> > > authenticated via ssh auth forwarding back to the lbb while the
> > > acknowledgment script confirms the authentication occurs at the correct
> > > times and the correct number of times during the process (and raises
> > > alarms if something takes place out of step or too many times).  When
> > > the processes are complete, the connections are broken down and the
> > > first server has no way to authenticate to the second server, since it
> > > has no private keying materials present.  No passwords are required,
> > > since the keys are stored on a system to which no remote login is
> > > permitted and which exists behind strict security barriers.  You can
> > > build a complete state machine and engine based on this model using
> > > multiple keys to control highly complex interactions between multiple
> > > remote systems and keep them all secure with NO passwords and NO
> private
> > > key material present on the external sites and NO password on the
> > > private key on a highly secured staging engine.
> > >
> > > Second example...  My laptop incorporates full hard drive (partition)
> > > encryption via LUKS (and has for years).  All of my private keying
> > > material exists only on encrypted drives (or encrypted drive images).
> > > Passwords are merely static encryption on the keys.  But, anyone with
> > > the ability to access those keys when the drives are unlocked (system
> > > running) would have the ability to trojan binaries or otherwise capture
> > > my passwords on those keys.  I am required to have this level of
> > > encryption on my drives now for totally external reasons regardless of
> > > my use of ssh auth keys.  I fail to see any value-add here at all where
> > > other, stronger, encryption prevails and dominates.
> > >
> > > In most environments I can envision where you would find this
> > > complicated scheme of insuring strong passwords on keys (even if that
> > > were possible) I would expect, just from a pure regulatory compliance
> > > standpoint, you would first require file system or drive encryption to
> > > protect other valuable private information.  So, either you are not
> > > providing any value add with this additional layer of complexity or you
> > > are leaving other sensitive material exposed.  I'm not sure I'm
> > > comfortable with that decision.
> > >
> > > This scheme also fails when you take into account hardware crypto
> > > devices such as smart cards and things like the tpm present on most
> > > decent laptops nowadays.  These these are crypto devices that can store
> > > keys and even generate keys and can lock them in a way that they can
> not
> > > be retrieved from the device, protected only by a PIN, which is in no
> > > way shape or form going to comply with your idea of a strong password.
> > > Yet, this is vastly superior to a scheme of requiring strong passwords
> > > on ssh keys.  If you are going to this much trouble, buy these people
> > > some OpenPGP smart-keys/smart-cards and save yourself a lot of time,
> > > expense, and headaches.  You'll be more secure and your users will be
> > > one hell of a lot happier with strong security that's actually
> > > convenient and easy to use!  Imagine that.
> > >
> > >
> > > So...  I'd like to hear more about the requirements for this system
> > > you're working on.  I've seen too many of these systems which are
> really
> > > designed to make the user's life more difficult but make them "feel
> > > secure" because it's an inconvenience being imposed on them rather than
> > > real security that is transparent and convenient but gains nobody any
> > > accolades and doesn't impress anyone that you're doing something to
> make
> > > them secure.  A LOT of what I learn is from people in unique situations
> > > I never anticipated with problem requiring unique solutions I had not
> > > considered before.  This sounds like one of them and I'm intrigued.
> > >
> > >
> > > > --
> > > > --
> > > > James P. Kinney III
> > > > I would rather stumble along in freedom than walk effortlessly in
> chains.
> > >
> > > Regards,
> > > 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: 0x674627FF        | possible worlds.  A pessimist is sure of
> it!
> > >
> >
> >
> >
> > --
> > --
> > James P. Kinney III
> > I would rather stumble along in freedom than walk effortlessly in chains.
> >
>
> --
> 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: 0x674627FF        | possible worlds.  A pessimist is sure of it!
>



-- 
-- 
James P. Kinney III
I would rather stumble along in freedom than walk effortlessly in chains.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.ale.org/pipermail/ale/attachments/20101224/472647e7/attachment-0001.html