[ale] Shipping Real World Linux Security

[Bob's ALE Mail]

> Bob's ALE Mail wrote:
> > 
> > My new book "Real World Linux Security: Intrusion Prevention, Detection,
> > and Recovery" 

> Always like to support the local folks.  Can you tell me how it differs
> from, say:

Geoffrey, thanks for this excellent question.  I apologize that it has
taken this long to reply.  (Please disregard my previous posting on this;
I was editing when my finger slipped.)

> Linux Firewalls - Ziegler

This is a good book and gives far more details on firewalls than my book
does, though mine takes the reader through the most common firewall
configurations, including the use of a DMZ.  I recommend it in my book.
A single home Linux system has no use for a separate firewall.

It's unfortunate, though, that there has been so much hype about firewalls
that most people think they are all that you need.  In my book I explain
crackers' common techniques for "tunneling through almost all firewalls"
and ways to do "end runs" around any of them.

In the former case, most firewalls give different response to various types
of packets depending on whether or not there is a system at any specified
IP address beyond the firewall.  One usually can further determine which
ports are open (with servers running)  on said system beyond the firewall.

If there is an older FTP server on a system inside the firewall that the
firewall grants access to from the Internet, it is likely that many attacking
requests can be relayed through to vulnerable systems inside the firewall.
Remember that most companies think "We have a firewall so we don't have to
secure any of our UNIX, Linux, VMS, or Windows systems inside of it."
Big mistake!

The nmap program can do both of these types of probing and I discuss
nmap too.

Most firewalls just block specified IP addresses from accessing specified
ports (services) and protect against TCP Syn Flood attacks and similar
protocol level attacks.

I do explain how to use IP Chains to serve as a firewall, with some
complete examples.  All but the most ancient Linux systems are resistant
to these protocol level attacks and I explain how to configure a Linux
firewall to protect vulnerable Windows systems from most of them.  I
also tell how recent a kernel must be to be able to resist various
attacks.  I explain how to configure Sendmail to block the ILOVEYOU
virus (even from mail addressed to accounts on Windows boxes inside the
firewall) as an example.  I explain how to configure Snort to detect
this attack.

> Building Internet Firewalls - Zwicky, Cooper, Chapman

As I recall this is half on UNIX firewalls and half on NT firewalls.  Since
I, like many others involved in security, consider NT to be too full of
security bugs and design flaws to be taken seriously as a secure system
and because the book is on Linux and UNIX, I'm not too interested in this
book and I cannot recommend it for Linux and UNIX SysAdmins.  For those who
want to deploy NT firewalls, I hear that it is a good book.

> Maximum Linux Security - Anonymous

This certainly is direct competition for my book.  I have a copy for
my research as I do the other books mentioned and many others.

How does mine differ?

Frankly Maximum Linux Security (MLS) is mostly about how to break into
other people's systems and provides far less useful information about how a
SysAdmin can protect his system against break-in.  First and most obviously,
a large portion of MLS seems to be comprised of "fluff" or "filler", i.e.,
information that is not of any use and which I do not particularly
interesting.

For example, it has too many pages of unneeded printout, portions from
man pages, and similar information easily obtained from one's system.
In my opinion, Anonymous clearly has very limited SysAdmin experience; I
have 25 years of experience as a SysAdmin and UNIX and Linux (combined)
kernel and system programming, having learned directly from Bill Joy,
Steve Bourne, and others.  He does not take the time to research, test,
and present the command sequences necessary to accomplish many of the
things he suggests but simply says "set up shadowed passwords"; I
explain exactly how.

MLS spends many pages giving the history of passwords through the ages,
including talking about ancient Egyptians, the history of the word
"cryptography", ROT-13, the measuring of people's differing body odor
instead of using passwords (despite there being no inexpensive
technology to do this), and other items not relevant to an overworked
SysAdmin wanting to secure his system quickly.  In this section he
spends about a page just giving printouts of sample /etc/passwd and
/etc/shadow files.  I believe I give a sample line from each.

My Operating Systems class at Berkeley was designed personally by Ken
Thompson.  I helped develop Berkeley UNIX and was one of the four people
who ported UNIX to the Silicon Graphics hardware.  I've also enhanced a
C2 version of the UNIX kernel (secure UNIX).  In other words, I've learned
from the best.

I find much of MLS' advice is repetition of "conventional wisdom".  His
advice on what to do if broken into echoes that of most books on
security: restore from backups or original media (CD-ROM).  For those
with user data and production systems, that's of questionable value.

I spend 64 pages explaining how to recover, including ways that will
find all Trojans planted and other mischief in a simple-to-follow
algorithmic way.  I also explain ways to track the cracker to his
originating system and how to work with law enforcement and legal types
to prosecute.  I explain how to find out who to contact at a person's
ISP to get the cracker's account shut down, and I've been successful in
doing this.  I explain how to do "fire drills" to practice recovering from
attacks and I explain how to set up "Tiger Teams" to try to break into one's
own systems.  I've done a great deal of original research for many of the
ideas in my book.  These ideas will not be a rehash of information on
previous mailing lists, articles or books because they have never appeared
been published before.


In my book, I talk extensively about passwords as this is one of the
most important issues in Linux security.  I explain why certain classes
of passwords are bad because they can be guessed easily (names of one's
Alma Mater or SO) or which can be cracked easily by cracker programs
(any single word in the dictionary).

I explain ways to create passwords that are very hard to break and how to
safeguard them.  I explain the dangers of login simulators that can trick
you into thinking your giving your password to "login" but you're really
giving it to a cracker's simple program.  I do provide a short shell
script that does this to illustrate how easy it is.

I explain how MD5 passwords are much harder to break than the older DES
passwords because the MD5 algorithm takes 20 times the CPU and because
it allows passwords of more than 8 significant characters.  I explain
the advantage of shadowed passwords over non-shadowed passwords (ordinary
users cannot see the encrypted passwords, making them much harder to
crack).

I then explain that even recent versions of Red Hat are not enabling both
MD5 and shadowing by default.  I believe I quote version numbers.

I then take the reader step-by-step through the process of enabling these
both on Red Hat and Slackware.  I explain dangers of errors and how to
prevent getting stuck in a hole.  In almost any non-obvious thing to do,
I give step-by-step instructions.  This took time and testing to get
right.  MLS seems not to in most cases.

I explain how to cause the passwd program to check passwords for
"crackability" with cracklib and to reject easily cracked passwords.
Cracklib, unlike crack, does not have code to crack passwords but it does
know the algorithms and will analyze a known password to see if it could
be cracked with these algorithms.  In other words, if a new password that
you ask the passwd program to use for you is found in a dictionary of the
English language, it will reject it.

I do point people towards the crack program and Jack the Ripper and
recommend that SysAdmins use it to ensure passwords on their own systems
cannot be cracked easily.  However, I do not list a whole lot of
cracking programs merely to educate crackers.  The cracking techniques
I do list usually are to prove certain vulnerabilities to show why certain
defenses do not work and why other defenses that do work are important.

In the section on passwords, MLS gives a table of various attacks
leading to a cracker getting to see the data in /etc/shadow.  In other
words, ways that a cracker can see the data in /etc/shadow that normally
is protected against viewing by ordinary users.  He does this by saying
that there are two holes in imapd and one in telnet, a cracker tool that
can can search core dumps of telnet to find the portion of the dump that
has these shadow password.  He does not explain how one might take
advantage of these holes nor what versions of these programs that these
holes are in or even if the buggy versions are on Linux or some ancient
UNIX system.

While these techniques may have worked against ancient UNIX systems that
made core files readable by all, Linux core dumps only are readable by
the effective user of the program, root in all of these cases.  If the
cracker is root he can read /etc/shadow directly.  In other words, his
information is obsolete and of no use to the modern-day Linux SysAdmin.
This is typical of his book, unfortunately.


My book is organized by what one hopes to accomplish.  Chapter 1 is an
introduction (and available for viewing on Barnes & Noble's web page on
the book).  Chapter 2 is "Quick Fixes for Common Problems".  It allows a
busy SysAdmin to quickly fix the most severe security problems in a minimum
of time.  Even within this chapter and others I rate the relative risks of
different problems and their fixes with 1 to 5 skull and crossbones symbols.
In Appendix H there is a table of vulnerabilities sorted by these Danger
Levels.

Later Chapters go through each subsystem in depth covering each issue
and how to secure it or, in some case such as NFS, why you don't want to
enable it in most systems because of unfixable security problems.
I cover Sendmail 8.10, the Netscape browser, and Samba.  I don't believe
that MLS covers any of these.

I talk about how to configure your system to automatically detect most
attacks and lock out the attacking system from getting any service and
notifying the SysAdmin via pager, email, by making dramatic use of
the sound card, and by flashing the lights with the X10 system.

I explain how to do a simple kernel modification that prevents cracker
servers (Trojans listening on high numbered ports).  I provide a program
that provides a list of open network ports, similar to netstat, but which
warns of suspicious open ports.  A port is suspicious if it is the
default port of a known cracker tool or if it is a high numbered TCP
port in a listen state (which should not happen).


I explain how to disable control-alt-delete from having any effect, like
crashing your system.  MLS suggests setting ctrlaltdel to soft so that
malicious users will not be able to corrupt the system's data if they
reboot.

MLS mentions the name GNU Privacy Guard (the Free Software Foundation's
replacement for PGP, commonly called GPG.)  I spend a number of pages
taking the reader through all of the steps of downloading, installing,
and using it.  It's a wonderful tool and I find it much easier to
understand and use than PGP.

My configuration values to enable Sendmail to resist Denial of Service
(DoS) attacks come from Sendmail, Inc., headed by Eric Allman who created
Sendmail.  My section discussing them (and permission to use their
copyrighted material) was approved be Eric.

Two of my book's reviewers, Mike Warfield and Kurt Seifried, are recognized
world-class Linux security experts.  A third, Steve Friedl is a talented
security consultant.  The remaining three reviewers are Linux SysAdmins
that reviewed regarding the value of each part of the book to SysAdmins
(and they had me delete or change things they did not find useful).

Real World Linux Security's foreword was written by Eric Raymond and
Steve Bourne provided a cover quote.

I also use humor and entertaining stories throughout it to make an
otherwise dry subject fun.  Some of my technical reviewers have reported
laughing out loud while reading some passages.


But why not see for yourself?  Give Real World Linux Security a test
drive?  Go into Borders or the Engineers Bookstore across from Tech and
look at both.  Pick a critical question that you need answered and try
finding the answer in each book.

> You know the old school essay, compare and contrast.... :)
> --
> Until later: Geoffrey		esoteric at denali.atlnet.com

Bob Toxen
transam at cavu.com                       [Bob's ALE Bulk email]
book at cavu.com                          [Book-related email]
bob at cavu.com
http://www.cavu.com
http://www.realworldlinuxsecurity.com/ [My new book: Real World Linux Security]
--
To unsubscribe: mail majordomo at ale.org with "unsubscribe ale" in message body.