Free Trial

Safari Books Online is a digital library providing on-demand subscription access to thousands of learning resources.

  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint
Share this Page URL
Help

Introduction

Introduction

Most security books demand only moderate sales, and thus Maximum Security II's success was a pleasant surprise. Even more surprising, though, were the reader responses I received. Not only did readers like the material, but they were anxious to see more. This left me wondering what type of book I should write next.

I spoke with my editors, and they reiterated a point that many readers had made: Maximum Security II was good, but what about a book that focused on a specific operating system? I agreed that this was a good idea in principle, but the question remained: Which operating system? In the end we chose Linux, and I'd like to explain why.

For many years Linux was a dark horse, an iconoclastic choice for folks seeking alternatives to Microsoft. In those early days, the Linux life was a lonely one. I remember conversations with friends who were dissatisfied with their own operating systems. They didn't have the source code, they resented paying high prices for development tools, and so on. In response, I always offered the same advice: Get Linux. Inevitably, they'd hem and haw, citing a dozen different reasons why they couldn't (with lack of technical support topping the list).

Today, those same folks ring me up to share their latest Linux experiences. Some have learned Perl, while others are now deeply entrenched in Expect programming. Times certainly do change. In the interim, Linux did more than grow; it grew up. Once a system expressly for hackers, Linux is now being installed in corporate environments on a daily basis.

These developments are due in large part to Linux's track record. Over time, Linux has proven to be stable and enterprise-worthy. In fact, there are precious few barriers to keep Linux from being installed on mission-critical servers of every variety.

There is one such barrier, though, and it often rears its ugly head at technical meetings: Linux security. I struggle with this beast myself whenever clients ask those familiar questions: "But is Linux really secure?" "Wouldn't we be safer with NT?" "Our people at least know NT." Perhaps the most common complaint is that there simply aren't enough Linux security books available.

So, my reasons for writing Maximum Linux Security were to demonstrate that Linux is secure and to provide a useful Linux security text. I hope that this book fulfills those aims.

This Book's Organization

Over the course of writing several books, I've learned much about structure and organization. Armed with this knowledge, I've examined my earlier works and found serious shortcomings that may have prevented readers from quickly locating important information. To prevent that from happening again, I wrote this book with a new approach.

In particular, Maximum Linux Security is exceptionally well cross-referenced, and is therefore a more cohesive resource. Such cross-referencing inevitably leads to better indexing, too, a critical point that's often overlooked in otherwise superb books.

This book's most valuable facet, in fact, may be how I cross-referenced it. Let's briefly cover that issue now.

How This Book Is Cross-Referenced

Authors of books like this one generally enjoy certain advantages. For example, imagine if this book's title was Maximum NT Security. I could write it swiftly, cover to cover, secure in the knowledge that Windows NT users have years of experience (if not with NT, then with Windows 3, 3.1, 3.11, 95, and 98). Indeed, my readers would quickly understand and implement every suggestion and tip.

But this book is a special case. Although Linux users now number 10 million, the majority of them have used Linux for less than one year. In fact, many are just now getting their bearings. Additionally, although excellent Linux security documentation is available online, there are few hardcopy books on the subject. Again, this is in contrast to Windows NT.

Worse still, many Linux security applications are rooted in command-line mode and span several files. That is, often you must be familiar with multiple configuration files and commands to perform a single task. This sets Linux apart from GUI-dependent operating systems.

To demonstrate the difference, I created a make-believe Windows-based security application called the Acme Ace Firewall Tool, which is depicted in Figure 1.1.

Notice that Acme Ace wraps all security functions into a tidy interface. From it, you can

  • Manage hosts

  • Manage logging

  • Apply filters and encryption

This is certainly convenient. However, it's also static—you can't go beyond the programmer's confines—and it's dependent on a windowing system. With rare exception, Linux security tools don't work this way.

Figure I.1. The Acme Ace Firewall Tool.


Instead, Linux developers often break up essential functions into separate commands or files, or both. A good example is the tcpd system, which allows you to accept or deny network connections from specified hosts or host hierarchies. To skillfully employ tcpd, you must be familiar with several commands and files:

  • /etc/hosts.allow—A table of host access rules

  • /etc/hosts.deny—A table of host denial rules

  • hosts_access—A system and language for establishing access rules

  • hosts_options—An extension to hosts_access

  • tcpd—The TCP daemon

  • tcpdchk—A tool that verifies your tcpd-centric configuration

  • tcpdmatch—A tool that interactively demonstrates your rules

These arrangements can be frustrating and confusing for first-time Linux users. They may get discouraged, believing that they'll never properly configure all those commands and files. This understandably contributes to Linux's reputation as a difficult-to-configure operating system.

Finally, Linux conforms to the axiom most commonly attributed to Perl programmers: There's more than one way to do it. Linux often has several commands that perform the same (or substantially the same) function.

My chief aim in writing Maximum Linux Security was to impart a holistic understanding of Linux security, especially to new users. To do that, I needed a way to clearly identify and cross-reference

  • Groups of commands and files that must be used in concert

  • Groups of commands that perform similar tasks

I settled on something that I call clusters. These are maps that point to required commands and files and related or similar tools. This has resulted in a level of context-sensitive cross- referencing rarely seen in retail technical books. Let's look at an example.

Chapter 4, "Basic Linux System Administration," will cover basic system administration tasks such as adding and deleting users. One tool you can use for this purpose is usercfg. usercfg's cluster provides a basic summary about the tool:

Application: usercfg

Required: usercfg + python

Config Files: /usr/lib/rhs/control-panel/usercfg.init, /usr/lib/rhs/usercfg, /usr/lib/rhs/usercfg/usercfg.py, usr/lib/rhs/usercfg/usercfg.pyc.

Security History: An ancient security hole (Python-related in a 1996 release) allowed attackers to gain read access to /etc/shadow. The exploit is here: http://safenetworks.com/Linux/shadow.html.

Notes: usercfg is a standalone account management tool but to use it, you must have the python language and libraries. (If you performed a full installation, you shouldn't have a problem. However, if you selectively chose your development tools, excluded usercfg, and excluded Python, install them now). usercfg is located in /usr/bin. (Note that usercfg's graphical interface may vary. In some cases, it's X-based. In others, it runs through dialog-driven LISA through a shell or from a command-prompt).

New users will benefit from this approach because they can quickly see the relationships between different commands or files. This is especially important when the main tool is associated with many separate configuration files, as in the case of tcpd.

But that's not all. This sort of bidirectional, context-sensitive cross-referencing (even without cluster maps) occurs throughout the book. Wherever possible, when discussing one tool, I cross-reference similar or associated tools that are discussed elsewhere. These associative trails lead not simply to relevant chapters, sections, and man pages, but to supplementary information online.

Here's an example from Appendix A, "Linux Security Command Reference":

amadmin

Description: Administrative interface to control Amanda backups.

Security Relevance: Use amadmin to configure the amanda backup system. For more information, please see Chapter 21, "Disaster Recovery," amanda, amcheck, and amcleanup in this appendix, the amadmin manual page, or http://www.cs.umd.edu/projects/amanda/amanda.html.

This double-barreled approach has led to a tight book that you can use to instantly find the information you want in great detail and depth.

Using This Book

To implement the examples in this book, you'll need the following:

  • Linux (Craftworks, Debian, Delix DLD, Eagle Group, Eurielec, Kheops, Linux Universe, MNIS, OpenLinux, Red Hat, S.U.S.E, SlackWare, Stampede Linux, TransAmeritech, TurboLinux, Yggdrasil, and so on)

  • A full installation, including standard TCP/IP clients and servers, C, and Perl

Note

Examples are often either dependent on Linux or an application version. For instance, some tools demand recent versions of Perl, some demand gtk, some demand a.out support, and many demand ELF (Executable and Linking Format) support. Ideally, you'll have a recent Linux distribution that satisfies these requirements. (Examples were generated with Caldera OpenLinux 1.3 and Red Hat Linux 5.1.)


Internet connectivity is not strictly required. Instead, many examples can be replicated with a local Web server on a single networked machine. However, I strongly recommend that you use an intranet at the very least. Certain examples require multiple machines, such as testing firewall rules.

With few exceptions, examples focus on achieving security without using the proprietary tools sometimes included in commercial Linux distributions. I took this approach to ensure that the material would be relevant to all versions of Linux. Additionally, this approach will ensure that new users understand not only how to implement security solutions, but also why they work.

Finally, I wrote this book with the notion that many readers are experienced enough to install and use Linux, but have little or no security experience. This may try the patience of more experienced users, but I'm afraid it was a necessary evil.

Odds and Ends

Finally, a few notes:

  • Links and home pages. In earlier books I linked to binary files directly, often bypassing vendor or author home pages. In this book, I've done things differently. If a vendor requires that you register prior to downloading their tool, I provide the registration URL. Also, when I link to a software author's page, I link only to the page and not to the specific file. This is fair, I think, because often these folks have much to say and sometimes have other valuable tools or papers on their site. Moreover, they frequently change filenames—especially when distributing updates. For example, the location http://www.mysite.org/mytool.tgz may later become http://www.mysite.org/mytool.version2.tgz. By taking this new approach, I hope to eliminate many 404 errors.

    In most cases, I do provide an adequately drilled-down URL. This will save you time. For example, when I point to a tool, I don't simply suggest that you go to the vendor's home page. Instead, I provide a link to the viewable page on which that tool can be downloaded. This obviates the need for you to drill down yourself.

    Note

    The exception to this rule is when the site creates URLs on-the-fly via CGI. Because these URLs are dynamic—and often depend on your Web client's state, address, and such—they're unreliable. In such instances, I reference static URLs if possible.


  • About products mentioned in Maximum Linux Security. I mention many products in this book—some commercial, some not—but I'm not affiliated with any of them. If I mention a tool, I do so purely because it's useful or because an example was generated with it. That said, I'd like to thank those developers that provided technical support on their products. Their help was greatly appreciated.

  • Mistakes and such. If you find that your product has been mentioned and the information was incorrect, please contact Sams.

Summary

So, that covers it. I hope you enjoy Maximum Linux Security and find it useful. While the book is not exhaustive, it does cover essential Linux security tasks. Also, the accompanying CD-ROM and many online references will provide you with indispensable tools and additional information sources. These combined elements should put you well on your way to securing your Linux system.

Please mail your comments and criticisms to maxlinsec@altavista.net.

  • Safari Books Online
  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint