[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[linux-security] Re: RedHat 5.X Security Book




On Sun, 12 Jul 1998, Rogier Wolff wrote:

> The problem is that if you give directions like
> 
>        edit /etc/inetd.conf and put a "#" before "finger". 
> 
> you'll have a slighly more secure site, but for how long? You're
> helping to create a set of machines that are closed off for a specific
> set of services/holes, but they may remain open on others. As long as
> those doing the daily maintenance don't actually understand what they
> are doing, you can consider their machines wide open.
> 
> The person writing the book or keeping the web site uptodate suddenly
> has the burdon of having to update it within hours from publication
> on bugtraq. No more vacations. New editions for the book every week. 
>
> To get people going, a few remarks like "you can disable services by
> removing them from inetd.conf, but make sure that your system doesn't
> start a permanently running deamon from the boot scripts" will help. 
> 
> However besides that, you need to create an understanding in the
> audience. Line-by-line howtos don't help if they are a week
> out-of-date.

I agree that giving someone a fish isn't as good as teaching them how to
fish...  and links to frequently updated security should definitely be a
part of the picture.  Brief explanations of the checklist points (perhaps
with links to more informative outside sources) would also be a good idea. 
But I have to echo the idea that a checklist isn't a bad idea *simply
because it is a checklist*. 

Since the example of seifried.org uses Red Hat, I can't help but think of
Red Hat's own Errata listings.  People use this as a checklist to make
sure they are running the most recent / patched versions of software that
RH has made available.  The errata lists are version specific.  The
security "checklist" at seifried.org are also geared specifically towards
RH 5.  Checklists are beneficial, as tools... and it just needs to be made
clear that they are tools, not warranties.  

The goal isn't to make the linux newbie a security guru.  A linux newbie
is easily overwhelmed by detailed discussions of bugs, exploits, and
patches...  is it better that they remain overwhelmed and ignorant and do
nothing?  Or is it OK for them to be ignorant of the technical hows and
whys, yet patch their machines in a systematic, clear, step-by-step manner
while being introduced to the resources that can help them, perhaps,
eventually, someday, begin to understand it all.  Newbies often want to be
taken by the hand and shown the way.  But if they are serious about
learning, they won't always need the same level of hand-holding that they
need to get started.  

No, it won't solve all the problems.  But having systems that are
completely open doesn't benefit anyone, except perhaps the script kiddies.
Putting together resources which help people patch their system *to a
given level*, with references to other resources, is a step in the right
direction.  



--jenni baier
jenni coiinc com



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]