[ale] Shipping Real World Linux Security

[Dow Hurst]

Y'all may remember how I posted that many of our systems were cracked a
week ago.  We've hired Bob to help out and it is working out very well. 
I have his book and have been looking thru it.  Interestingly, we would
never had this problem if I had just read Chapters 1-2 and followed the
procedures there.  Procrastination, poor passwds, an example of code to
hack a non-chrooted ftp, I am learning quite a bit here.  I highly
recommend it for any Unix user, since everyone using a system needs to
understand security.  I wonder if there is an equivalent book for MS
products?

It is kind of neat, in a way, that people like me, who don't have years
of experience or lot's of knowledge can get to talk with some of the
best people in the business.  I had no idea who Bob Toxen and Michael
Warfield were except that I always liked their answers on ALE.  After
awhile, I always noticed who was answering a question and then might
zero in on their comments even if the question was not one I would
normally look at.  I really enjoy reading and participating in ALE.
Dow

Bob's ALE Mail wrote:
> 
> > 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.

-- 
__________________________________________________________
Dow Hurst                   Office: 770-499-3428
Systems Support Specialist  Fax:    770-423-6744
1000 Chastain Rd.
Chemistry Department SC428  Email:dhurst at kennesaw.edu
Kennesaw State University         Dow.Hurst at mindspring.com
Kennesaw, GA 30144
*********************************
*Computational Chemistry is fun!*
*********************************
--
To unsubscribe: mail majordomo at ale.org with "unsubscribe ale" in message body.