Product Description

FreeBSD and OpenBSD are increasingly gaining traction in educational institutions, non-profits, and corporations worldwide because they provide significant security advantages over Linux. Although a lot can be said for the robustness, clean organization, and stability of the BSD operating systems, security is one of the main reasons system administrators use these two platforms. There are plenty of books to help you get a FreeBSD or OpenBSD system off the ground, and all of them touch on security to some extent, usually dedicating a chapter to the subject. But, as security is commonly named as the key concern for today's system administrators, a single chapter on the subject can't provide the depth of information you need to keep your systems secure. FreeBSD and OpenBSD are rife with security "building blocks" that you can put to use, and Mastering FreeBSD and OpenBSD Security shows you how. Both operating systems have kernel options and filesystem features that go well beyond traditional Unix permissions and controls. This power and flexibility is valuable, but the colossal range of possibilities need to be tackled one step at a time. This book walks you through the installation of a hardened operating system, the installation and configuration of critical services, and ongoing maintenance of your FreeBSD and OpenBSD systems. Using an application-specific approach that builds on your existing knowledge, the book provides sound technical information on FreeBSD and Open-BSD security with plenty of real-world examples to help you configure and deploy a secure system. By imparting a solid technical foundation as well as practical know-how, it enables administrators to push their server's security to the next level. Even administrators in other environments--like Linux and Solaris--can find useful paradigms to emulate. Written by security professionals with two decades of operating system experience, Mastering FreeBSD and OpenBSD Security features broad and deep explanations of how how to secure your most critical systems. Where other books on BSD systems help you achieve functionality, this book will help you more thoroughly secure your deployments.

Product Details

• Amazon Sales Rank: #596064 in Books
• Published on: 2005-03-28
• Original language: English
• Number of items: 1
• Binding: Paperback
• 350 pages

About the Author
is the Manager of Network and Security Operations for VeriSign's Mass Market's division. He manages the security for over a hundred network devices and several hundred servers. He's the founder of the Shmoo Group (www.shmoo.com), a web site for security, cryptography, and privacy professionals, and NoVAWireless (www.novawireless.org), a community-based wireless network project in Northern Virginia.

Excerpted from Mastering FreeBSD and OpenBSD Security by Bruce Potter, Yanek Korff, Paco Hope. Copyright © 2005. Reprinted by permission. All rights reserved.
CHAPTER 1 The Big Picture

First we crack the shell, then we crack the nuts inside.
—Rumble
The Transformers: The Movie

Security is hard. We have all heard this phrase as a rationale for insecure systems and poor administrative practices. What’s worse, administrators seem to have different ideas about what "security" entails. There are two common approaches to securing systems: some view security as a destination while others see it as a journey.

Those who see security as a destination tend to characterize system security in terms of black and white; either a system is secure or it is not. This implies that you can attain security. You can arrive at the end of a journey and you’ll somehow be secure; you win. One problem with this viewpoint is determining where "there" is. How do you know when you’ve arrived? Furthermore, how do you stay there? As your system changes, are you still at your secure goal? Did you move away from it, or were you not there to begin with? As you can probably tell, this is not our philosophy.

Instead of being a destination, we think security is best described as a journey—a product of ongoing risk management. Rather than trying to make your system impregnable, you continually evaluate your exposure to risks and keep the system as secure as you need it to be. An appropriate level of security is achieved when the risks facing a system balance against the level of effort spent mitigating those risks. No one buys a $5,000 vault to safeguard a pair of fuzzy slippers. You judge the value of what you’re protecting against the kinds of threats it faces and the likelihood those threats will succeed, and then you apply appropriate safeguards. This is a much more practical way to view modern day information security.

When following a risk mitigation process, you will periodically pass up the opportunity to enable certain security mechanisms, even though you’re capable of doing so. The additional effort may not be warranted given the level of risk your organization faces. You will eventually reach a point of diminishing returns where you simply accept some risks because they are too costly to mitigate relative to the likelihood of the threat or the actual damage that would occur. Sure, it may be fun to use encrypted filesystems, store all OS data on a CD-ROM, and deploy every other countermeasure you can think of, but do you really need to?

We define security in the context of risk. Risk is present as long as the system exists, and risks are constantly changing, so security cannot be a destination; it must be an ongoing process. "Doing security," then, is an iterative process of identifying and responding to risks. This is the philosophy that we encourage you to take in securing your infrastructure.

As you’ll see in the rest of this book, FreeBSD and OpenBSD are robust operating systems that offer myriad ways to maintain secure systems. Throughout the book we provide security-minded walkthroughs of software installation, configuration, and maintenance. Along the way you’ll notice that we seem to point out more security-related configuration options than you care to implement. Just because we explore options doesn’t mean that you should implement them. Come at it from the perspective of managing risk and you’ll maximize the cost-benefit of "doing security."

Before we get ahead of ourselves, however, we need to cover a few concepts and principles. In this chapter, we define system security, specifically for OpenBSD and FreeBSD systems, but also more generally. We look at a variety of attacks so that you, as an administrator, will have some perspective on what you’re trying to defend against. We’ll look at risk response and describe how exactly you can go about securing your FreeBSD and OpenBSD systems.

What Is System Security?

Security professionals break the term security into three parts: confidentiality, integrity, and availability. This "CIA Triad" is a set of security requirements; if you’re not taking into account all three of these concerns, you’re not working towards providing security. We offer a lot of recommendations in this book that should help you work towards building secure systems, but we don’t tell you how these recommendations fit in with the CIA Triad. That’s not what this book is about, and it would detract from the real message. Nevertheless, as you’re looking at building encrypted tunnels for transferring files, jailing applications, and so on, think about what part of the Triad you’re focusing on. Make sure you’ve addressed all three parts before your project is done.

Whether we’re talking about physical security, information security, network security, or system security, the CIA Triad applies. The question is, exactly how does it apply to system security?

Confidentiality

Confidentiality is all about determining the appropriate level of access to information. Confidentiality is often implemented at the most basic level on FreeBSD and OpenBSD systems by traditional Unix permissions. There are a variety of files scattered across the filesystem that are readable only by the root user. Most notable, perhaps, is /etc/master.passwd, which contains hashes for users’ passwords. The vast majority of files are readable by everyone, however. Even system configuration files like /etc/resolv.conf, /etc/hosts, and so on are world readable. Is this wrong? Not necessarily. Again, confidentiality isn’t about having to protect data from prying eyes; it’s about classifying data and making sure that information deemed sensitive in some way is protected appropriately.