Re: SLFS book chapter proposals

> I see nothing wrong with distributing what has been dubbed a "Hackers'
> Howto" - After all, knowlege is power.  Any hacker out there is free to
> view the bugtraq and CERT mailing lists or websites, and they are free
> to visit securityfocus - which includes exploit code, proof of concept
> code, and vulnerability bulletins. Anyone can simply open the page, grab
> a snippet of code, compile it, and execute it - poof, exploited box. The
> only possible outcome of distributing our versions, which will not
> actually include exploits for individual packages, is to educate the
> users.  If it is decided that we should include the common exploits in
> our book, then IMHO they should be in an appendix, with links in the
> book to each appendix entry.  Having that information right in the book
> will clutter it, other than in the general concepts.

Reproducing Aleph1's code (for example) should cause no harm, is minimal and 
is very educatonal (this is how I begun). It's up to the reader to realise 
the implications of this common tecnique against a SUID root binary. The 
hatorihanzo.c code is another good candidate. All these are available 
web-wide. Our mentioning them would not help even script-kiddies.

> One good example is the ptrace vulnerability. Local exploit. I am sure
> y'all know about it.  (for those who don't it basically exploits a
> kernel condition, and drops you to a root shell. Very nasty, and very
> easy. as soon as any user gets local access, they are root.)  This
> exploit could be put in the general concepts..  "Compile this little
> program as user, and run it. Notice you are now in a root shell - This
> is what happens to get here, and why. Now, patch this, rebuild this, and
> try to run the exploit code again - notice the error, your system has
> just be secured agains't this common exploit". The user has learned
> something about low level security methods....  How deep the security
> theory must run to build a secure box.
>
> But, again we are getting ahead of ourselves...  And way OT - well, I am
> anyhow ;)

OT? Why? Discussing about the contents of the book, aren't we?

> Back to the subject line.....
>
> > > <snip>
>
> I agree with the initial posting - the book should be layed out first...
> and here is my suggestion:
>
> SLFS - Secure Linux from Scratch
>
> Part I - Introduction
>
> Chapter 1 - Security?
>  What it is, what it is not, comitments on the part of the user.
> Chapter 2 - But I don't need it!
>  Who needs security, who can ignore the book. Why you DO need this book.
> Chapter 3 - About the Book
>  What the reader will accomplish by reading the book, the SLFS system
>  that he or she will have built, and what will remain for the user after
>  the book.
> Chapter 4 - Prerequisites
>  What you will need to have in place, installed, available to you before
>  beginning this book.
>
> Part II - General Concepts
>
> Chapter 1 - What exactly is a Secure Linux box?
>  Detailed description of a secure system and the different levels of
>  security implimented in SLFS.
> Chapter 2 - Proof
>  Proof that security is a concern. This chapter can include the ptrace
>  exploit, a sample code block that is exploitable, and the patched
>  version of that code that is not exploitable, and links to a few of the
>  nastier exploits released in the past year or two. ie. sshd's
>  oh-so-common remote exploit, httpd's known bugs, etc.
> Chapter 3 - The Security Model
>  Section a. Overview
>   The security models commonly in place by network administrators
>   accross
>   the globe, and the model we are going to be using for SLFS. This
>   chapter should also outline the reasons WHY we choose the model we
>   are using. What we feel are downfalls to other models (cost, manpower
>   realism, etc.)
>  Section b. Local Security Policies
>   What Local Security means to us, and how we are going to impliment it.
>   User and Group permissions, special users and groups for daemons and
>   services, default user permissions, filesystem permissions etc.
>   No specific install commands here, just the policies and procedures.
>  Section c. Remote Security Policies
>   What remote security is, and how we are going to impliment it.
>   This is NOT a firewall, but the ever-present "install only what you
>   will use" law, and the chroot methodology, assuming we are going to
>   be using that (I see no reason not to)

Providing for network security is a HUGE issue; the firewall alone (including 
theory on it) could be a book on its own. Not sure if it should be contained 
in SLFS. I think this is something to be discussed more thoroughly, i guess. 
My point is that if providing for network security, we should provide for 
every service the system might run, therefore the task quickly becomes 
daunting. The simplest scenario is to provide for a simple firewall to 
protect a home user (i.e. no services running) and this alone can be 
difficult.

>  Section d. Firewall
>   This is the section where we discuss a firewall to restrict access to
>   services internal to the network, block common exploitable ports from
>   places they should never come (ie. Windows Networking ports from the
>   internet) and how a firewall will further enhance the security of both
>   the SLFS machine, and the network is possibly protects. Also some
>   discussion here about the different types of firewall policies that
>   could be used, and the specific model we will be building.

We should focus more on general concepts here and provide only a few 
(representative, nevertheless) cases of different configurations. Showing 
principles of building firewalls should provide the reader with knowledge to 
cater for her needs.

>  Section e. Application Hardening
>   This is the section where we outline the application hardening process
>   we use to secure our entire system from possible exploits not yet
>   known. Other topics in here could be such things a propolice and other
>   tools that suppliment the hardening process. Again, this is a general
>   principals section, not a commands and codes section - we are not
>   building anything just yet.
>
> Part III - Making it happen
>
> Chapter 1 - The base system
>  Here we will detail the commands and tools and build process to get the
>  base system installed / upgraded and secured. This is a secure
>  toolchain, libraries and what not. This may be broken down into smaller
>  sections, as the Section 3 above was. This area is not yet fully
>  detailed, as we have to get the general layout done first (this email
>  should help)
> Chapter 2 - Local applications
>  Again, we could, and probably should, break this down application by
>  application. One section for each local tool - these being things like
>  the shadow password suite, PAM, and other such local processes.
> Chapter 3 - Remote Services
>  Again, broken down to applications. I am not going to go into details
>  here as we need to open up discussions on each Part, Chapter and
>  Section to decide what to include, and what to leave out. This is for
>  such things as a webserver, mailserver, ftp, dns, ssh etc. ie. the
>  Internet services. As well, such things as Samba and NFS could and
>  probably should be here.

Again, I must say that this chapter, if materialised will be vast. Books have 
already been written on each remote service, trying to replace or reproduce 
them would be futile. I would agree on a few pointers and links to sites and 
bibliography.

> Chapter 4 - The Firewall
>  This will be a big chapter. a Firewall is a big project IMHO.
>  We will have to first get the firewall tools installed, and then
>  the rules, and probably some discussion on changing the rules.
>  This section should include scripts to automate and simplify
>  the firewall process, so that the user only has to configure a few
>  system variables such as IP address, Interface names, etc. and the
>  scripts provided will use variables to setup the rules, allowing the
>  same basic script to be used for everyone. Also here should be some
>  common firewall setups - Single machine on Dialup/DSL/Cable, Small
>  NAT network behind a firewall on DSL/Cable/Dialup, Large network
>  behind dedicated line (ie, no NAT)

See my comments above. I must repeat that providing a general firewall is 
impossible as well as covering al possible cases. Theory is more important.

> Chapter 5 - Other considerations
>  This section could outline other security considerations you might want
>  to consider after the base system above is installed. Maybe things like
>  tripwire, which we might not be recommending as "required" for SLFS,
>  but might be an idea for some users, etc. - that all should go here.
>  Also here might be some mention of honeypots...  they are a common
>  countermeasure system admins use.... (This might be better off
>  somewhere else though - that can be open for discussion at a later
>  date, when we get closer to putting content in the book.)
>
> 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.
> 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.

Do not agree here. This is in no way part of building a secure system. We 
should not get involved in forensics of any kind; the purpose is to build a 
secure system, not write a book that teaches general security. I think such a 
chapter would be OT.

> 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.

Don't know...i still think we should not approach anything but *building* a 
secure system (with a bit of firewall). This is more an administrative 
subject. Imagine if the LFS book talked about *using* a freshly build system, 
or go into teaching bash scripting. I think the analogy finds practice here 
too.

> 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....

Apart from the points I commented, I agree with the rest.

Cheers

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