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

[Michael H. Warfield]

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).

> 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.

> 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!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
Url : http://mail.ale.org/pipermail/ale/attachments/20101224/0770f7b9/attachment.bin