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

[Michael H. Warfield]

On Fri, 2010-12-24 at 08:41 -0500, Jim Kinney wrote:
> 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.

That's it.

Also, after reflecting on it over night, since you seem mostly concerned
with Windows users.  If you/they are really paranoid you might consider
IronKey.

https://www.ironkey.com/

The keys are encrypted and hardware cryptographically locked.  The user
has to enter a PIN and then the USB side of the key can be accessed just
like a regular USB key, albeit a rather pricey USB key.  That much
actually works in Linux.  The entire crypto engine may be accessed over
a pkcs11 API interface in Windows, so anything that can talk to a
smart-card can use this key as a crypto engine, but they don't have
those drivers for Linux last I looked.  With that interface, you can
generate or store a limited number of private keys for PGP, SSH, or
X.509 certificates.  The private key, once stored on the IronKey, can
never be extracted from the IronKey.  It can only be used by the crypto
engine on the ironkey itself.  So it's a CSD (Crypto Storage Device) and
hardware crypto engine.  They claim it's tamper proof and will destroy
the contents if tampered with.  The enterprise version even allows
remote locking and destruction of the key in case of loss or theft.

They were eliminated from consideration purely due to the lack of the
pkcs11 API interface and drivers on Linux and we have an explicit
requirement for solution parity.  Other than that, they looked pretty
impressive.  Cost wise, the personal edition is (or was) about on parity
with a pair of good usb memory key and a good smart card style usb
crypto key.  In the later case, though, you don't have the hardware
encryption on the USB key or the crypto locking.

Regards,
Mike

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

-- 
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/c9acf8d4/attachment-0001.bin