Re: SLFS book chapter proposals

On Saturday 20 December 2003 08:32 am, Robert Day wrote:
> On Sat, 2003-12-20 at 07:55, Bill's LFS Login wrote:

<snip>

> Part IV - After the Build
>
> Chapter 1 - Logging
>  With any security model, monitoring of the logs is important. We need
>  a way to detect possible security risks, and investigate them. Logs are
>  the key here. A good logging method should be listed here - how to
>  setup syslogd, or another syslog daemon, belong here. As do details
>  about how to interpret log entries, and possibly some logfile analysus
>  tools.

Agreed I am quite sure that a lot of new users, myself included, have no idea 
what logging is, does, how to read the logs, how to setup the logs, and so 
on.

> Chapter 2 - Keeping up to Date
>  Very important. A system is only as secure as it is current. Anyone who
>  has ever worked in security will know this. New exploits are found
>  daily, and the user has to keep on top of it. Here we can detail the
>  common mailing lists security folk monitor to stay on top of things.
>  Such lists as CERT and bugtraq - and links to the info page for each.
> Chapter 3 - I've been Hacked!
>  Oh boy. We thought this could never happen! But it did. Someone got to
>  our system before the patch fixed the hole. Now we have a breach. Now
>  what? We detail rootkits here, common uses of a hacked box, what to
>  look for, and how to clean up the mess. (remember, not everyone wants
>  to reinstall every time they get hacked. SLFS is going to be a much
>  bigger project to undertake then LFS). Also in here should be
>  information on researching a hack, and how to trace out HOW they got
>  in and how to prevent it in the future.

Actually doing backups could be covered here although the why to backup might 
need to be covered somwhere else.

> Chapter 4 - Changing the Rules
>  This is an optional chapter if you ask me, but I wanted to be complete.
>  Changing policies, be it due to a breach, an oversight, or new ideas
>  that the admin comes across, is no easy task for a larger than one
>  network. Deciding to go from 6 character passwords to 8 character
>  passwords is a small change, but with hundreds of users, becomes a
>  large project. (yes I know, 8 should be the MINIMUM anyhow, and should
>  include both letters and numbers, or symbols) Deciding to replace
>  apache with a different webserver can become a veritable nightmare
>  if there are many v-hosts, and modules involved. Some discussion on
>  changing the rules and policies is warranted. Especially if that change
>  includes new authentication methods. If you migrate to Kerberos across
>  your network, that's a heavy change, especially if you tie that to
>  30 servers, 5000 users, and 20 applications across the network.
>
> Section V - Appendix, etc.
> No details here, just the appendix. Maybe a list of software and their
> home pages, download pages, etc. Links to security sites, further
> reading, references to sources used to gather information, etc.
> Credits even... after all, there are alot of folk who are going to
> contribute, but only a smaller handful who are going to contribute
> larger chunks of info and help. I think they deserve credit somewhere ;)
> And anything else we forgot can be tossed in here ;)  LOL
>
> I think this layout should cover all aspects of the SLFS system from the
> basic intro to the hardest hardening and securing we plan on
> implimenting, and does so in a logical step by step learning approach
> that includes the by-product of building a secure box.  Who knows, we
> may even have publishers interested in the book when it is done if we
> design it well, and include enough detail, references, and don;t have
> too many pages (if any) that are all but blank...
>
> Comments welcome, but hopefully we can take this layout, maybe some
> minor changes, and build a map from it so we can begin work on it.
>
>   Rob Day (BOFH)
>
> BTW: Apologies for the LARGE post, but it was needed....

-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-security
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page