Re: SLFS book chapter proposals

On Sat, 2003-12-20 at 07:55, Bill's LFS Login wrote:

> >
> > I dont' know exactly how feasible it would be to show common examples of
> > code that lead to the vulnerabilities mentioned in that chapter, but
> > it'd be nice to see exactly what to look for in the code to find these
> > vulnerabilities, also what not to do when writing your own programs.
> 
> IIRC, examples are shown and publicly available on sites dedicated to
> security. I don't have the URLs availabe ATM, but they could be included
> in the book to provide that info. IIRC, one of the standard procedures
> on these sites requires proof of the weakness, including code that
> exploits the vulnerability.
> 
It is, IMHO, a minor detail to show examples. We're not talking about
showing exploits to apache here, just the common buffer overflow
methods, and other such normal backdoors that hackers would use. Nothing
really application specific here, more like conceptual stuff.

> >
> > > Another could explain the purpose of every package installed in addition to
> > > the standard LFS. Thus, if the reader has understood the build procedure of
> > > the LFS, he/she should also come closer to the solutions presented in the
> > > book. Why do we install propolice? Show him/her how to compile a program with
> > > an unpatched gcc (probably the one of the host system's) and demostrate a
> > > simple buffer overflow. Then do the same thing with the patched gcc. Voila,
> > > in front of his/her eyes the system is more secure.
> > >
> >
> > I personally would like to see this for each type of exploit mentioned
> > in the fundamental knowledge chapter.  Someone had mentioned in another
> > thread that this might be a 'hacker's howto' of sorts.  This seems
> > dangerous, but at the same time, how can you fix a vulnerability if you
> > don't understand how the exploit works in the first place?
> 
> If the code samples I mentioned above really do exist, there is no
> increase in risk, just maybe a wider distribution if the book points to
> those items.
> 
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.

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 ;)

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