[ale] SSH attempts

[Michael B. Trausch]

On Mon, 2011-09-19 at 12:10 -0400, Bob Toxen wrote:
> This is why it is critical to have both a bootloader (grub or lilo)
> password and also a BIOS password.  They can be set so that the
> password is needed ONLY when booting other than the default device
> (BIOS) or default kernel environment (bootloader). 

I have seen that functionality in a bootloader, but never before in a
BIOS.  What systems come with a BIOS that has that feature, do you know?
That would be a nice feature to have.  Then again, I'm not sure that it
would matter: physical access means that you can wipe the BIOS password,
and then we're back at square one, being able to pwn the box.

This is also why it'd be critical to do things like encrypt the
partition so that one must be able to provide a separate password (pass
phrase) to be able to boot the system.  If the binaries on the disk
can't be read, then passing init=/path/to/any/bloody/thing simply cannot
work.  Of course, that won't prevent someone from overwriting the entire
drive and installing something else on it, but again: physical access
trumps all.

This is why layers of security are so important, actually.

Guard against physical access to the system in order to ensure that
unauthorized people cannot do things like override the system's boot-up
commands as well as physical theft.

If the previous precaution fails and physical access to the system is
gained, the worst that ought to be the case is that a bit of time and
money are lost.  The attacker should be unable to copy data off of the
system because all of the partitions on the system should be encrypted
(including the root filesystem).  The encryption makes the data on the
system worthless to the attacker, and now the box only has its natural
economic value because the data is worthless.  Even the password
database is hopelessly encrypted!

Of course, encryption isn't going to stop an employee that knows the
encryption passphrase.  This is why you would want to take advantage of
a proxy key.  If I'm not mistaken, LUKS has this capability; the actual
encryption key for a volume is itself encrypted.  Passphrases can be
added to or removed from the volume.  Each pass phrase can be used to
decrypt the real key, which is then used to perform the access to the
disk.  That'd mean that you can give passwords to people that you trust,
and if for some reason down the line you stop being able to trust them,
you just remove their passphrase from the system.

Then again, this could get very long: eventually, you'll find that you
only have trust in people that work with your systems because you have
to have some trust in someone, somewhere, or you'd never get anything
done.  But you have to at least try.  And the more layers it gets, the
more compartmentalized things are, and the more cooperation that is
required to successfully pwn a box drastically lowers the possibility
that it will happen in the first place.  After all, most of the people
in the world are after the low-hanging fruit.  Once you successfully
guard against low-hanging fruit attacks, the only other thing that you
have to really guard against are directed attacks... simple, right?  :-)

	--- Mike

-- 
A man who reasons deliberately, manages it better after studying Logic
than he could before, if he is sincere about it and has common sense.
                                  --- Carveth Read, “Logic”