0672328755 Bonus Overview

161 Pages·2006·1.08 MB·English

by  Adair, Gary

0672328755_Bonus_Overview.qxd 6/27/06 5:09 PM Page 1
FreeBSD 6 Unleashed
Michael Urban
Brian Tiemann
ISBN: 0-672-32875-5
Copyright © 2006 by Sams Publishing
www.samspublishing.com
BONUS CONTENT
Chapter 30
Network Security PDF:799
Chapter 31
Virtual Private Networks (VPNs) PDF:845
Chapter 32
The Domain Name Server PDF:861
Chapter 33
The Network Filesystem (NFS) PDF:883
Chapter 34
File and Print Sharing with Microsoft Windows PDF:895
Chapter 35
Dynamic Host Configuration Protocol (DHCP) PDF:911
Appendix A
Command Reference and Configuration File Reference PDF:921
Appendix B
Hardware Compatibility Lists PDF:929
Appendix C
Troubleshooting Installation and Boot Problems PDF:945
Appendix D
Sources for More Information PDF:951
36_0672328755_ch30.qxd 5/9/06 4:51 PM Page 799
30
CHAPTER
IN THIS CHAPTER
Network Security •Choosing a Security Model
Based on Your Security Risks
•Security Models
S •The Security Risks You Face
ystem security is arguably the most important part of
any administrator’s job, whether it applies to a Windows •Password Policies
server, a commercial UNIX system, Linux, or FreeBSD. More
•Avoiding Problems with
books have probably been written about security issues
Clear-Text Services
than about any other topic—and with good reason. It’s an
immensely complex subject, but one that’s crucially impor- •Securing Terminal Traffic (SSH)
tant to the success of a networked system. Although this
•Securing Email Services (POP3
chapter can’t cover every facet of system security, it offers a
and IMAP)
good, general overview of the topic and includes informa-
tion on all critical aspects of the topic. •Securing FTP
This chapter helps you develop a security policy for your
•Securing Apache
FreeBSD system based on the risk factors it faces in its role
as a server or workstation. This chapter will give you the •System Security Profiles and
tools you need to monitor your system’s perimeter, keep on Kernel Security (Securelevels)
top of alerts that are raised in the field, patch your system
•Using a Firewall
in response to those alerts, and make sure the services you
provide to your users are not opening your system up to •Preventing Intrusions and
attack. It also gives you some idea of what you can do to Compromises
recover when—not if—your machine is hacked.
•Denial of Service (DOS)
Attacks
Choosing a Security Model Based on
Your Security Risks •Physical Security
The Internet today is not an especially friendly place for •Other Security Resources
servers, and as an administrator you must always fear and
prepare for the worst. The proliferation of “rootkit” tools—
prepackaged weapons that attackers can use to gain super-
user access to your system—and published attack scripts
provides unfortunate fodder for countless individuals with
nothing better to do than pursue destructive hobbies. You
must assume that your system is being probed for security
weaknesses at all times and expect the situation to grow
more dangerous with each new published exploit. Your
36_0672328755_ch30.qxd 5/9/06 4:51 PM Page 800
800 CHAPTER 30 Network Security
only defense is to keep your system as up to date as possible, act on new security advi-
sories as soon as they’re released, run only what services are necessary, and be educated
about the real dangers that threaten your system and where the greatest risks lie.
Security Models
You can adopt one of several models of security for your system, based on your system’s
setup and use patterns and your philosophy toward the security needs the system
presents. The security model you choose will dictate how careful you must be about
certain administrative duties, such as password policies, open services, encrypted traffic,
and so on. Here’s a short list of some security models, each defined by a general statement
that sums up the administrator’s assessment of security risks:
• I trust everybody on the Internet.Most certainly an inadvisable model under any
circumstances, this is nonetheless the philosophy that guides the lack of security
safeguards surrounding many amateur servers, and the administrators of those
systems—who seldom maintain them properly—ultimately pay the price for it.
Often found on university systems, especially those that have been around since
before the Internet became so rich in hacker activity, systems administered with this
philosophy have many open services, don’t require encrypted logins, have loose
account and password policies, and are easy targets for hack attacks.
• I trust anybody on my system’s network.This philosophy is common in small enter-
prise networks where the server is protected from the general Internet by a firewall
or NAT router, and the internal network is made up of employees of a single
company or department at a university. In this model, malicious users on the inter-
nal network are rare, especially if the organization is small, so the system can afford
to provide unencrypted services, give accounts to anybody who asks for them, and
even have disabled login security and passwords.
Unfortunately, in large organizations, it has become the case that attacks on servers
maintained under this model—attacks from withinthe network, by people who are
supposed to be trustworthy—are more frequent than attacks from outside. If your
organization is large, you must assume that you cannottrust everybody on your
system’s network, and instead choose a different security model.
• I trust my local users.Administrators who maintain this philosophy tend to be more
paranoid than administrators of the systems described previously in this list’s first
two models. This security model is characterized by a tight network security policy:
screening of users before new accounts are granted, encrypted network services
(either required or encouraged), unnecessary services turned off, and crack-resistant
passwords. However, local users are allowed to access internal services and see sensi-
tive information (such as encrypted password strings). The idea is that once users
are approved and given accounts, they can have the run of the system, and betrayal
of that trust is grounds for removal from the system. This model is appropriate for
hobbyist systems that serve a “low-risk” audience (for example, a fan website or
community email service), or for high-profile commercial Internet servers where
only a few trusted people actually have user accounts.
36_0672328755_ch30.qxd 5/9/06 4:51 PM Page 801
The Security Risks You Face 801
• I trust only myself and other administrators.The model favored by the most paranoid
system administrators, this model not only has tight network security as in the
preceding model, but tight local security as well. Regular users are denied access to
system configuration files and server-side program code through carefully crafted
permissions, Access Control Lists, and even Mandatory Access Control (MAC) labels
(an advanced mechanism for controlling user access to files, sockets, and processes
throughout the system). The administrator must watch each user carefully to make
sure nothing unauthorized is being done, and special measures (such as custom
shells, chrootjails, and the disabling of certain commands) are often taken to
restrict each user’s access to the system’s resources. This model is useful for high-
profile servers that provide email or web hosting services to hundreds or thousands
of users from indeterminate or anonymous backgrounds.
After you’ve decided what model is appropriate for you and your system for network and
user-level security, you need to decide where the risk areas are for that model and what
you can do to combat the exploitability of those areas.
The Security Risks You Face
“Perfect security”is a myth; only superhuman effort can keep a system so completely
buttoned up that no attack can ever get through. The next best thing, however, is to
know which areas of your system are at greatest risk and how those risks can be
combated.
Security risks for a network server can be grouped into three major categories:
• Root compromise—An attacker takes advantage of unencrypted transmissions or
known programming weaknesses in server software (most commonly buffer
overflows, or weaknesses in input boundary checking in server software) to gain
super-user access to the system. He then installs tools of his own to conceal his pres-
ence from your system-monitoring tools (such as lastand ps) and can steal any of
your critical data or use your system as a base point for further hacking activities.
• Privacy compromise—If network traffic to and from your system is not encrypted
(scrambled), an attacker can view any of it, including passwords (potentially leading
to root compromise) or any user’s critical or private communications.
• Denial of service—An attacker (or a widespread network of attackers, often comprised
of unwitting “zombies”) uses brute-force methods such as flooding your server with
large amounts of legitimately constructed traffic, thus swamping its ability to serve
3
traffic to normal clients and potentially crashing the system. 0
Within each of these categories of security risks, the most common threats result from
these specific security weaknesses:
• Insecure (weak) passwords—Passwords that can be guessed by software using common
words and sequences.
36_0672328755_ch30.qxd 5/9/06 4:51 PM Page 802
802 CHAPTER 30 Network Security
• Clear-text services—Services in which passwords and other sensitive information can
be obtained just by “sniffing” the unencrypted data packets on the wire.
• Unnecessary and exploit-prone services—If you don’t need to provide a service, don’t. It
can only cost you in the end.
• Open SMTP relaying—Allowing spammers to use your SMTP server as an open relay
for broadcasting junk mail.
• Unfiltered network access—Run a firewall to prevent unauthorized or undesirable
traffic from getting to your machine.
• Outdated and vulnerable software—The older a piece of software is, the greater the
chances someone has found a way to break in through it.
Each of these weaknesses is a potential problem on FreeBSD in its default configuration.
The sections that follow show you how to close these security gaps and find the necessary
tools to maintain a system that will stand up to the inevitable hacker (or, more properly,
“cracker”) attacks that will be leveled against it.
NOTE
Marcus Ranum outlines the Six Dumbest Ideas in Computer Security at http://www.ranum.com/
security/computer_security/editorials/dumb/. Consider it required reading!
Password Policies
If yourusers have insecure passwords, all the other security measures you might take may
well be moot. Probably the most responsible thing you can do as the administrator of a
FreeBSD system is to institute a password policy, requiring (or at least encouraging) your
users to use passwords that cannot be easily guessed or decoded.
Users frequently find passwords inconvenient, and strict password policies doubly so. If
allowed, a user will try to use his username, his telephone number, the server’s hostname,
a word such as “password,” or strings of convenient-to-type characters, such as repeated
letters or numbers. If you choose to expire users’ passwords after some period, the first
thing a user will try, when prompted to choose a new password, is to reuse the password
from the previous period. However, an axiom of security is that “convenience and secu-
rity are mutually exclusive,” meaning that to increase one, you must sacrifice the other.
Increased convenience brings about decreased security. There’s no easy way around that
fact for you or for your users.
When a user chooses a password using the system’s passwdprogram or a script that calls
the same routines that passwduses, a few loose checks are performed. By default, pass-
words must be at least six characters in length, but that’s about the only built-in measure
that prevents people from choosing weak passwords. You can use the following tech-
niques to take your password policy to the next level.
36_0672328755_ch30.qxd 5/9/06 4:51 PM Page 803
Password Policies 803
TIP
An ideal password is at least eight characters long (the longer the better, actually), and contains
a mixture of capital and lowercase letters, numbers, and punctuation marks or meta-characters.
To keep your system security strong, you must ensure that users follow these guidelines when
picking a password with the passwdprogram in FreeBSD.
Although the only password security measure currently enforced by the default passwdprogram
is that passwords must be at least six characters long, the FreeBSD development community is
working to incorporate further weak-password checks into the passwdprogram. You learn how
to use the login.confprogram to set a minimum password length and to require periodic
password updates in “Forcing Password Expiration,” later in this chapter.
Enforcing Secure Passwords with Crack
The first priority in maintaining secure user password practices is to prevent users from
choosing insecure passwords in the first place. As of this writing, the best way to make
sure your users aren’t using easily guessable passwords is to periodically try to guess them
yourself. A tool called Crack, available in the ports collection at /usr/ports/security/
crack, helps you do just that. Although it may appear to be a “hacker” tool, Crack is
primarily intended as a security-auditing tool for system administrators, allowing you to
perform “dictionary” attacks (trying a plethora of English words as potential passwords) as
well as a number of other commonly used “convenience” passwords: repeated strings, the
user’s login name, groups of numbers, and so on. Crack helps you determine which of
your users are using insecure passwords. You can then contact these users directly and ask
them to adhere to the password rules you set.
You can build and install the Crack port using the instructions in Chapter 16, “Installing
Additional Software.” The new /usr/local/crackdirectory’s permissions enable only root
to list its contents or run any of its programs. To check your system’s user database for
weak passwords, go into /usr/local/crackand run the Crack program like this (note the
capitalization):
# ./Crack -fmt bsd /etc/master.passwd
The Crack program builds some utilities, compiles some dictionaries, and then launches
its arsenal against /etc/master.passwd. Cracksends its output into runtime files that you
can analyze with the Reporter program, as shown here:
# ./Reporter -quiet
---- passwords cracked as of Sun Jan 14 12:17:41 EST 2001 ----
3
0
979693112:Guessed frank [frank] Frank Jones [/etc/master.passwd /bin/tcsh]
979693187:Guessed joe [password] Joe User [/etc/master.passwd
➥/usr/local/bin/bash]
---- done ----
36_0672328755_ch30.qxd 5/9/06 4:51 PM Page 804
804 CHAPTER 30 Network Security
Crack reports only the users whose passwords were successfully guessed. In the sample
output, the cracked passwords are shown in the first set of brackets; Frank’s password is
frank, and Joe’s password is password—both very weak passwords that can be guessed by
an attacker with little effort. You can then contact these users and remind them of the
password policy, requiring them to change to stronger passwords.
After you’re done running Crack, clean up the runtime tools and output files with the
following two commands:
# make tidy
# rm run/F-merged
NOTE
As FreeBSD continues to develop, it’s highly likely that there will be support in the passwd
program for automatic password-strength checking such as that done manually by Crack; in
fact, the libraries that Crack uses are available at /usr/ports/security/cracklib. On systems
such as Linux, cracklibhas been developed into a Pluggable Authentication Module (PAM), a
mechanism that FreeBSD supports as well (see man pam), but FreeBSD doesn’t have cracklib
support fully integrated into PAM as of this writing. For now, though, if you’re an adventurous
sort willing to work with source code and experimental software, and you’re interested in
incorporating the cracklibroutines into the passwdprogram, you can learn how at
http://www.kearneys.ca/~brent/FreeBSD/passwd42.html.
TIP
A tool similar to Crack, but with more extensive checking and faster operation, is John the
Ripper (/usr/ports/security/john). It can be very useful in conjunction with Crack or on
itsown.
Forcing Password Expiration
By default, passwords in FreeBSD do not expire. However, one common part of a secure
password policy is to require users to change their passwords every so often, with the
expiration interval chosen by you.
To do this in FreeBSD, you need to modify the /etc/login.conffile. This file controls
system capabilities and behaviors, such as the number of allowed processes, the
maximum allowed process size, the allowed number of simultaneous open files, and
certain shell behaviors (learn more about this file in man login.conf). Each of these
controls can be assigned to a “class” of users; you can assign users to classes with the chfn
command (as you have seen in the “The /etc/passwdand /etc/master.passwdFiles”
section of Chapter 13, “Users, Groups, and Permissions”). By default, users aren’t associ-
ated with any particular class, so the values in the defaultclass apply to everybody:
36_0672328755_ch30.qxd 5/9/06 4:51 PM Page 805
Password Policies 805
default:\
:passwd_format=md5:\
:copyright=/etc/COPYRIGHT:\
:welcome=/etc/motd:\
:setenv=MAIL=/var/mail/$,BLOCKSIZE=K,FTP_PASSIVE_MODE=YES:\
:path=/sbin /bin /usr/sbin /usr/bin /usr/games /usr/local/sbin
➥/usr/local/bin /usr/X11R6/bin ~/bin:\
:nologin=/var/run/nologin:\
:cputime=unlimited:\
:datasize=unlimited:\
:stacksize=unlimited:\
:memorylocked=unlimited:\
:memoryuse=unlimited:\
:filesize=unlimited:\
:coredumpsize=unlimited:\
:openfiles=unlimited:\
:maxproc=unlimited:\
:sbsize=unlimited:\
:priority=0:\
:ignoretime@:\
:umask=022:
The backslash (\) characters “escape” the line breaks, allowing you to specify all these
properties on different lines, thus keeping the file readable.
To set a password expiration date, you put an extra line into the defaultclass, specifying
the passwordtimeproperty. The line can go into the block at any point, but the easiest
place to add it is right at the top, between the class name and the first existing property
line:
default:\
:passwordtime=90d:\
:passwd_format=md5:\
:copyright=/etc/COPYRIGHT:\
:welcome=/etc/motd:\
This example sets passwords to expire after 90 days. You can also use time values such as
2y(2 years), 6w(6 weeks), and 24h(24 hours). Now, because /etc/login.confis a data-
base that must be compiled into a hash table (as with the tables in /etc/mail, which
3
youlearned about in “Configuring Basic Email Services with Sendmail,” in Chapter 25,
0
“Configuring Email Services,” and as with the /etc/master.passwdfile and its corre-
sponding hash table of user accounts), you must run the cap_mkdbprogram to generate
the hash table and enable your changes:
# cap_mkdb /etc/login.conf
36_0672328755_ch30.qxd 5/9/06 4:51 PM Page 806
806 CHAPTER 30 Network Security
From now on, the login procedures will require users to choose a new password every 90
days. Note that when the passwordtimeproperty is set, passwdwrites the time of the last
password change into the sixth field of /etc/master.passwd:
frank:$1$LXZkCuzD$7Oa8LyRf5jYOb.XrXiB3d.:1060:100::999066364:0::
➥/home/frank:/bin/tcsh
TIP
You can also use login.confto alter the default minimum password length. This is done with
the minpasswordlenvalue:
:minpasswordlen=8:\
This sets the minimum acceptable password length to eight characters.
Assigning Initial Passwords
Whenyou’re setting up a new user’s account, it can be tempting to set a simple initial
password, such as Temp123or ChangeThis. This seemingly innocuous practice, however,
can seriously compromise your system’s security—especially if you use the same tempo-
rary password for every new user you add.
Fortunately, the adduserscript provides you with the ability to assign randomly gener-
ated, nearly unguessable passwords to each new user you add to the system. In its default
configuration, adduserwill ask you during its questionnaire procedure what kind of pass-
word you want it to create; but you can specify that it should generate a random pass-
word for each user by adding the following line to your /etc/adduser.conffile:
passwdtype=random
Alternatively, invoke the addusercommand with the -w randomoption. When you use
either of these techniques, a run of the adduserprogram (as you saw in Chapter 13) ends
with output similar to the following:
adduser: INFO: Successfully added (joe) to the user database.
adduser: INFO: Password for (joe) is: cwwqAuSpwd0rYG
Add another user? (yes/no): no
Goodbye!
There’s little to no chance that a casual password-cracking program will guess the pass-
word cwwqAuSpwd0rYG. Now, however, your task is to make sure that Joe doesn’t turn right
around and set his password to “joe” or something equally trivial. One way to enforce
this policy is to require onetime passwords that are good only for a single login session.
TIP
A tool for generating random passwords on demand is pwgen2, available in the ports in the
sysutilscategory. It allows you to change users’ passwords at any time, rather than just at user
creation time, and gives you many flexible options for how the passwords should be created.
36_0672328755_ch30.qxd 5/9/06 4:51 PM Page 807
Password Policies 807
Onetime Passwords with S/Key
If you’re really serious about password security, you can do what they do at government
offices and super-secure businesses: You can assign onetime passwords to your users, shift-
ing part of the security burden from your own shoulders onto those of your users. The
idea is that each user gets a set of passwords (or a means to generate one on-demand),
each of which are only good for a single login attempt. Onetime passwords are generated
by the keyprogram, which has variants on all major platforms, and there’s even a plat-
form-agnostic Java key calculator at http://www.cs.umd.edu/~harry/jotp/src.html.
(FreeBSD uses MD4 for its calculations.)
When the user attempts to log in, the server presents him with a “challenge” phrase and
a number. The user then uses the keyprogram and those input values to generate a pass-
word for that one login attempt and enters that password. This password is then never
used again; at the next login attempt, he must generate a new password using the new
number presented in the server’s challenge.
Onetime passwords are good candidates for use on systems in which you don’t obligate
your users to use SSH instead of Telnet (as we will discuss shortly). Because a new pass-
word has to be generated by the user with the keyprogram on a local system, with the
user feeding into it the server’s challenge phrase and the user’s own secret password,
which is never transmitted over the wire (except during initial key setup), an eavesdrop-
per can never get any useful data by sniffing the connection. Once the password is used
once, it can’t be used again. The user can transmit his onetime password in clear text
without fear.
NOTE
S/Key is as much a tool for a security-conscious user as it is a way for the administrator to enforce
good security practices. Many parts of S/Key setup (for example, the keyinitprogram) are the
user’s responsibility to maintain. If a user feels strongly about keeping her passwords private, she
might choose to use onetime passwords, even if she has the option to do otherwise. However,
this also means that a user is free to choose not to use onetime passwords if she doesn’t have to.
Let’s say you want to make it so that the user Frank cannot log in with his usual UNIX
password from a remote host but instead must use S/Key onetime passwords. While
logged in to the server (preferably securely, as with SSH), he must use the keyinit
program to set up S/Key authentication:
# keyinit
Adding frank: 3
0
Reminder - Only use this method if you are directly connected.
If you are using telnet or rlogin exit with no password and use keyinit -s.
Enter secret password:
Again secret password:
ID frank s/key is 99 st28077
COL APT HELM TAB DRY TRIM