[ale] SSH attempts

[Bob Toxen]

On Mon, Sep 19, 2011 at 12:30:45PM -0400, Michael B. Trausch wrote:
> 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.
EVERY i86 BIOS I have seen has this feature.  Boot into the BIOS and
go through the screens looking for an option to set the password,
sometimes called the "supervisor password".  Just don't forget it.
(Yes, it can be erased by those who know how.)

...

> 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.
Yes, each security feature protects against different attacks.

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

1. Bootloader password protects against "init=/bin/bash" to evade the
   system's normal password system.

2. BIOS password protects against from booting from removable media.
   ALSO adjust BIOS settings to ONLY boot from your normal non-removable
   disk!

3. Encrypted file systems protects against someone stealing the system
   or disks and extracting information.  Once the system is powered off,
   nobody can get information from the encrypted file systems without
   the passphrase.

4. Encrypted network communications (ssh, https, etc.) protects against
   someone sniffing the network for data.

5. Guarding against physical access (locks on the server room, etc.)
   protects against various physical access including sniffing, stealing
   disks with UNencrypted file systems, etc.

6. There are more layers of protection that should be done, of course.

> 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

Bob Toxen
bob at verysecurelinux.com               [Please use for email to me]
http://www.verysecurelinux.com        [Network&Linux security consulting]
http://www.realworldlinuxsecurity.com [My book:"Real World Linux Security 2/e"]
Quality Linux & UNIX security and SysAdmin & software consulting since 1990.
Quality spam and virus filters.

"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond where
the shadows lie...and the Eye is everwatching"
-- The Silicon Valley Tarot Henrique Holschuh with ... Bob