[buug] Great Links re. Internet/Linux Security

[Nicolai Rosen]

On Sun, 6 Aug 2000, Rick Moen wrote:
> Here's part of what's bothering me, Zeke (and I hope this doesn't strike
> you as just ill temper):  _How_ can you decide that something is a
> "great link regarding Internet/Linux security", before having a good
> grasp of that topic?

Oooh, that's a burn!

> Anyhow:  The notion of password-protecting the boot process presupposes
> that random people are going to be allowed physical access to the
> console (keyboard & monitor) and (usually) also the system box that
> has the drives and motherboard in it.
> 
> Give the public physical access to the system box, and the game is over.
> You then have no system security -- if only because the bad guys can
> extract your hard drives and take them home.  You can play cat and mouse 
> with the public, by password-protecting LILO, setting the BIOS so it
> will not boot from removable media, password-protecting the BIOS, etc.,
> but you've really already lost, if you allow physical access.

No. The world isn't black and white. There are many different levels of
physical security. Should you lose all physical security, then you're
screwed (with a few exceptions). However, there are a lot of situations
where you have partial physical security, semisupervised computers,
i.e. computer labs, colo (unless you're talking nice, expensive shit in
which case you've got almost complete physical security, cages, lockers
*drool* *drool*.. ah, but any way, I digress. I'll take computer labs as
my example. Many places, i.e. libraries, schools, etc.. have computers in
areas where people are. You could somewhat easily compromise security if
you made sure nobody was really paying attention to you (I know, I've done
it). You can't open up computers (especially when additional bolted down
type physical security is provided) without becoming very noticable. While
it's still possible to get around that sort of thing it's much harder and
a completely higher level of a breech. So in many circumstances, those
extra measures go the extra mile in stopping what amounts to mostly script
kiddies from screwing with stuff you want to keep as is.

> And so it goes.  Anyhow, getting back to my overall point, just as with
> the "tip" about /etc/services, you can't just assume that this source of 
> information is "good" just because it's there and you can follow it.

This is true. While there a great deal of intuitive information out there,
some of it's not quite so obvious and the unix community has spent decades
learning this sort of thing the hard way. It's usually a good idea
(especially in the realm of security) to check your information by going
to a few different sources that are vastly different and of course by
checking what the experts/authorities say.

> If can't find much wrong with the rest of those two pages except for a
> mild Red Hat bias and the fact that Dave Wreski (the author) didn't
> mention that the Tripwire security-auditing package he recommends is
> proprietary software.  The publisher says it intends to open-source it
> later this year, but has not done so yet.  There's already an
> open-source (GPLed) equivalent by Rami Lehti of Finland, "AIDE", 
> http://www.cs.tut.fi/~rammer/aide.html .

Ugh, my commentary on this will have to wait until I get a chance to read
it. For now though, I really must get off to work. It's past 3 & I'm not
even done getting dressed.

Nicolai Rosen, nick at netaxs.com
http://www.netaxs.com/~nick/

i am the truth from which you run
	-nine inch nails, mr self destruct