At 08:38 PM 4/21/00 -0400, Derek Martin wrote:
> > Are you guys gonna write a HOW-TO ?
>
>First of all, I had neither intended to post my phone number to the list,
>nor to suggest that Ken and I are some kind of security gods or something.
>In fact I'm sure there are people on this list who know more about
>security than I do; I just don't know who they are. :)
I whole-heartedly have to agree with this. I currently work in
computer/network security, and I have learned one very important thing: The
more I learn, the more I learn that I have a lot more to learn! I am in no
way a guru, expert, or anything else. What I am is paranoid and anal.
>Second, besides never having enough free time, the howto's are already
>written. Some of them are disguised a little, but the info's all there.
>The problem is that securing a Unix system is a very broad, far-reaching
>topic with voluminous material written about it. Good places to start are
>the firewall howto, the ipchains howto, the ethernet howto, the linux
>sysadmin guide, the DNS howto, the NIS howto (though that comes under the
>heading of lack-of-security howto) and many others. All of these are
>available from the LDP website.
Not to mention the Security-HOWTO ;-)
>If you want an all-encompasing howto, what you're going to end up with are
>a stack of books about as tall as me. Some good references are O'Reilly's
>Practical Unix Security, Evi Nemeth's Unix System Administration Handbook,
>Maximum Security - a hacker's guide to securing unix systems (anonymous),
>and tons and tons of others.
Building Internet Firewalls, Linux Unleashed, yadda yadda yadda..... There
are hundreds of really good books out there, and no single book could
possibly cover every single aspect of security.
>Ken tells me the same author has written a Linux-specific version of the
>book too... so you may want to check that out.
Great book. And it has a CD with it that has some pretty nice utilities,
too ;-)
>As a final comment, I'll offer that the reason Unix is so difficult to
>secure is that much of the OS and various services that were written to
>run on it were originally designed to make it EASY to share data, which is
>counter to our task at hand. As Paul likes to say, if people would just
>be nice, none of this would be necessary...
>
>Sigh. So much for idealism.
While I agree with that 100%, there are also other things to be considered.
What I personally feel is a major factor in securing a system/network is
the buddy rule. It's a fairly simple rule to follow: ALWAYS have a buddy
look at it and/or test if when you think your done. The reason that this is
so important is because, quite simply, one can rarely, if ever, correct
themselves. For example, if I write an ipchains script, I can re-read it
hundreds of times and never see what I did wrong. I wrote it, and if I
didn't get it right the first time, then chances are, I won't think that
it's wrong. I always have someone look over something like that before
deploying it.
One of my biggest mistakes when I started out with Linux was
simple ignorance. If I was installing a system or recompiling a kernel and
I saw a package/module was selected and I didn't know what it was or why it
was there, I left it alone. I was afraid that I would mess something up and
I assumed that the defaults would be correct. Of course, this led to many
headaches and even more crashed systems. It is really quite simple: If you
don't know what it is or what it does.... FIND OUT! Don't take anything for
granted, and never assume that it is secure.
Security is a never ending process. You have to keep up with the
latest exploits and bugs, and you have to monitor your system. You can't
build it, "secure" it, and walk away. Trust me... If you build it, they
WILL come. If you ignore it, they WILL crack it.
Maybe I should write a HOWTO (or even a book): "Stupid mistakes
that I have made (and there have been a LOT)".
Kenny
**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************
