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

[Jim Kinney]

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.

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.

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.

Happily, most of the people that need this access are mostly carbon-based
life forms. A few are probably part silicon and sulfur...

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.ale.org/pipermail/ale/attachments/20101224/f83cae7c/attachment-0001.html