1226.book page 780 monday, december 22, 2003...

1226.book Page 780 Monday, December 22, 2003 8:40 AM

Appendix D

Operating System Security

When large numbers of computers or servers are interconnected in a corporate or enterprise-size

network, network operating system (NOS) security is of paramount importance. Security is

also a must for small business networks and home networks as well. Operating system security

includes controlling who has the authority to gain access to resources on the internal and exter-

nal network, and deciding what type of information or resources will be permitted to be accessed

internally or externally. Typically, the data that is transferred, the control of internal and external

access, and the rules that will be enforced on access and data transfer are implemented using

sophisticated Cisco routers and firewalls, which are a secure and effective first-line-of-defense

strategy. However, end-user systems and servers are subject to many threats and vulnerabilities,

both internally and externally. An entirely secure network does not end with routers and fire-

walls; rather, it includes securing access to end-user systems and servers as well.

Establishing network security has never been more important than it is today. This task is espe-

cially vital for large, high-profile companies. Although system administrators have been report-

ing possible threats and security risks for years, until recently it has been hard to convince the

people who are in charge of corporate budgets that these security risks must be addressed. These

large companies face possible threats from internal attacks in addition to external attacks. This

appendix discusses some of these possible attacks and also explains how to secure end-user sys-

tems and servers to prevent any unauthorized access in Windows and Linux operating systems.

The first part of this appendix covers Linux, and the second part covers Windows.

Linux Operating System Level SecurityThe latest releases of Windows and Linux come with many sophisticated security tools. One of

the kinds of threats that network operating systems face is attempts to compromise the filesys-

tems. A Linux system has many important files and directories that can be exploited by hackers


782 Appendix D: Operating System Security

if not properly protected. For example, if the Linux filesystem is left unprotected and a hacker

breaks in and is able to access the filesystem, the intruder could potentially upload several

programs. One such program could modify the /bin/login file and therefore enable the hacker

to have unlimited future access to the server.

Another way intruders could abuse unprotected Linux servers is to attack the various dae-

mons and processes that are running. Most of the processes running on a Linux server do so

by means of root privileges. When the running processes are exploited by hackers, they can

gain root access to the Linux server. This section discusses some of these threats and to how

secure a system against them by using security tools that are available, by using secure pass-

words, and by configuring appropriate files.

Securing Running Processes

A Linux server is capable of running many processes and daemons that hundreds or even

thousands of users rely on. If these processes and daemons are compromised, it can cost a

company hundreds or even thousands of dollars in network downtime. For example, a Linux

mail server could be compromised by a hacker. If an intruder were able to kill the Sendmail

daemon and other daemons that control a company’s e-mailing functions, valuable and possi-

bly irreplaceable e-mails, both those received and those not yet sent, could be lost. Being

without e-mailing capabilities can cripple some large corporations or companies that rely on

e-mail to conduct day-to-day business.

One method to secure running processes on a Linux system is to use the Linux Intrusion

Detection System (LIDS). Implementing LIDS on Linux servers is an effective way to pre-

vent attacks in which the root account is compromised and administrative access is granted to

an intruder. LIDS can increase a Linux server’s security by limiting the privileges that are

granted to the root account. Therefore, if the root account is compromised, the actions that a

hacker can perform are limited. LIDS has several other security features, such as security pro-

tection, incident detection, and incident-response capabilities. LIDS is capable of providing

protection for the following cases:

■ Protects files and directories from unauthorized access, regardless of what local filesys-

tem they may reside on

■ Enables an administrator to select specific files and directories that cannot be modified

by the root user in the event that the system is hacked and the root account is compromised

■ Further reduces the privileges of the root account by protecting critical processes from

being terminated by anyone, including the root account

■ Prevents I/O operations from being accessed by unauthorized programs

■ Prevents the server’s master boot record (MBR) from being damaged


Linux Operating System Level Security 783

It is almost impossible for any network to completely close off all its ports. For example,

common ports that every network needs to remain open are FTP, HTTP, and various e-mail

ports. Intruders can use port scanners to scan networks for these open ports and thus gain

unauthorized access to the server. LIDS is able to sense when an intruder is scanning the

ports with a port scanner and sends an e-mail to alert the system administrator to that fact.

LIDS is also capable of making notification and entries in security log files if any security

rules are violated. If an intrusion is detected by LIDS, the security tool can also terminate the

attacker’s remote session.

Installing LIDS on a Linux ServerLIDS security references everything from the kernel; therefore, before installing LIDS, you

must download and install the latest kernel source. After that, you need to download and

install the latest LIDS patch for the kernel source that was just installed. After the patch is

applied, the updated kernel needs to be compiled and updated. The latest kernel sources can

be found at http://www.kernel.org, and the latest LIDS patches can be found at the LIDS

project website (http://www.lids.org).

Protecting DaemonsAdditional security files that can be configured to enhance security are installed when LIDS

is installed. For example, the /etc/lids/lids.cap file is used to break down all the daemons and

processes that are run by root.

As mentioned previously, the root account can be vulnerable to attacks that can cause serious

damage. Using the etc/lids/lids.cap file, you can modify the init process, which controls impor-

tant daemon processes, so that it cannot be shut down by the root account. The etc/lids/lids.cap

file uses plus (+) and minus (–) signs to indicate which controls the root will have. A plus (+)

sign indicates that the root has the specified control, and a minus (–) sign indicates that the

root does not have the specified control.

The last line of this file is +30:CAP_INIT_KILL. To protect the init process from being killed

by the root, use a text editor to change the plus (+) sign in this line to a minus (–) sign.

After editing this file, you need to reload all the necessary changes to the LIDS configuration.

To do so, enter the following command at the shell prompt:

/sbin/lidsadm -S

Hiding Running ProcessesAnother important entry in the etc/lids/lids.cap file is the CAP_HIDDEN entry. By default,

this entry is enabled, which allows the root to hide a process from the rest of the system. For



example, to protect a Linux web server that is running the Apache server process, enter the

following command at the shell prompt:

lidsadm -A -s /usr/local/apache/bin/httpd -t -o CAP_HIDDEN -j INHERIT

This command labels the process as hidden, meaning it cannot be found by using commands

such as ps and top, and it will not even show up in the /proc filesystem.

Limiting Administrative CapabilitiesAnother easy way that LIDS can help secure a server’s running processes is by disabling sev-

eral administration tasks. The CAP_NET_ADMIN line in the etc/lids/lids.cap file is disabled

by default, which means that no administrative tasks can be run by the root, including the

following:

■ IP firewall configuration

■ Ethernet interface configuration

■ Routing table modifications

■ Setting debug option on sockets

■ Binding to addresses for transparent proxying

■ Configuring promiscuous mode

■ Clearing driver stats

■ Reading or writing device-specific registers

■ Multicasting

For a server, which must be securely maintained at all times, it is recommended that the

default setting remain permanently. If any administrative tasks need to be performed, the sys-

tem administrator can temporarily shut down LIDS to do the task. To do so, enter the follow-

ing command at the shell prompt:

/sbin/lidsadm -S -- -LIDS

Using the Immutable Flag FeatureAfter LIDS has been installed and all security files, such as the etc/lids/lids.cap file, have

been configured, the system’s processes will be significantly better protected against an

intruder compromising the root account. However, an experienced intruder that is able to take

control of the root account could easily open the etc/lids/lids.cap file and make the necessary

changes to leave the system unprotected. A feature in the ext2 and ext3 filesystems allows

files to be flagged as immutable. A file that has the immutable flag cannot be edited, renamed,

or deleted. For example, to make the etc/lids/lids.cap file immutable, enter the following

command at the shell prompt:

chattr +i etc/lids/lids.cap



However, the root user can change the immutable flag for a file by entering the following

command at the shell prompt:

chattr -i etc/lids/lids.cap

To prevent the immutable flag attribute from being removed, disable the

CAP_LINUX_IMMUTABLE capability in the etc/lids/lids.cap file.

Filesystem and Directory Security

A major part of protecting a computer system’s integrity and properly enforcing system-wide

security is understanding the filesystem, directory structure, permissions, and security tools.

Securing the running processes is only the first step in enforcing system-wide security. With-

out understanding how the filesystem is organized and how to protect sensitive files and

directories from being compromised by intruders, virtually the entire contents of the system

are vulnerable to an attack.

Almost everything that is done on a computer involves creating, accessing, configuring, or

deleting the files and directories on a computer or server. However, most people lack the

knowledge or training to effectively protect the files and directories on their own systems or

on a remote server. This ignorance can lead to a serious security liability. This section covers

some of the important security implications involved with files and directories, and it describes

some of the tools that can be used to properly secure the filesystem on a Linux server.

Setting PermissionsThe first step in managing filesystem security is to understand how permissions are assigned

and changed for files and directories, and to comprehend how file ownership works and how

to change the ownership of files and directories. Any file or directory that is created is owned,

by default, by the user who created it. The permission group is the owner’s default group.

A regular user cannot change the owner of a file or a directory, but the root can, using the

chown command. The group ownership of files can also be changed by the root only, using

the chgrp command. The permissions of any file or directory can be changed—again, by the

root only—using the chmod command.

To control security, the default permissions setting in Red Hat Linux requires that only the

user who created the file can read, edit, or delete the file. Also, by default, every user is a

member of his or her own default group, which has the same name as the username. The per-

missions are set so that other users and groups cannot read, edit, or delete the files that have

the default permissions set.

Another important method that maintains consistency of user and group permissions is to only

create, modify, or delete users and groups using the useradd, usermod, userdel, groupadd,

groupmod, and groupdel commands. It is possible to manage user and group accounts



manually by editing the /etc/group and /etc/passwd files, but doing so can result in an unse-

cured environment where user or group accounts can be vulnerable.

Ensuring Filesystem SecurityYou can take some basic measures to ensure that the filesystem of a Linux server is protected.

Such steps include defining system-wide permissions settings, identifying the world-accessi-

ble files on the server, and configuring set-UID (SUID) and set-GID (SGID) properly. (UID

stands for user identifier, and GID stands for group identifier.)

The Red Hat Linux filesystem follows the Filesystem Hierarchy Standard (FHS), which con-

sists of a set of requirements and guidelines for file and directory placement under UNIX-like

operating systems that many developers and groups have agreed to follow. (This definition is

from the FHS website, http://www.pathname.com/fhs.) One example of a FHS-mandated

filesystem security requirement is that the /usr directory needs to be read-only. However in

Red Hat Linux systems, the /usr directory is initially not read-only, because when new soft-

ware is installed, files need to be written to the /usr directory or one of its subdirectories.

Making the /usr directory read-only significantly enhances the security of a Linux server by

not allowing any of the binaries in the /usr directory or one of its subdirectories to be modified.

The process to make the /usr directory read-only is fairly simple. It involves making an edit to

the /etc/fstab file. To do so, follow these steps:

Step 1 Open the /etc/fstab file using a text editor and comment out the following line

by placing a # character in front of the line:

LABEL=/usr /usr ext3 defaults 1 2

Step 2 Create a new line, as follows:

LABEL=/usr /usr ext3 ro,suid,dev,auto,nouser,async 1 2

Defining a System-Wide Permissions SettingEstablishing a system-wide default permissions setting can further enhance security by deter-

mining the permissions setting for new files and directories that are created. This permissions

setting is called the mask value. By changing the default mask value, it is possible to manipu-

late the default permissions settings for all the files that are created on the server using the

umask command. The following lines are used to determine the umask settings for users:

If [ ‘id –gn’ = ‘id –un’ –a ‘id –u’ –gt 14 ]: then umask 002else umask 022fi

This simple code states that users with a UID greater than 14 (which includes all regular user

accounts) get a umask setting of 002, which has a default permissions setting of 775 on any

1226.book 86 Monday, December 22, 2003 8:40 AM


files and directories they create. Users with a UID less than 14 (which includes the root) get a

umask setting of 022, which has a default permissions setting of 775. Therefore, users can

read and execute files that are created by other users, and navigate to any user’s new directory.

This is a security risk. To change the default umask settings, follow these steps:

Step 1 Open the /etc/profile file with a text editor and locate the following lines in the

file:

If [ ‘id –gn’ = ‘id –un’ –a ‘id –u’ –gt 14 ]: then umask 002else umask 022fi

Step 2 Change the umask 002 value to umask 077. The new setting means that when

users create files and directories, the files will have a more restrictive 700 per-

mission mode.

Step 3 Change the umask 022 value to umask 007. The new setting means that when

users with UIDs less than 14 create files and directories, the files will have a

less restrictive 755 permission mode.

Identifying the World-Accessible FilesA world-accessible file or directory is available to any user who is authenticated to the server.

After the default system-wide permissions have been set, you should identify the world-

accessible files on the server and remove any of them that are not needed. Whether or not any

or all of these world-accessible files or directories are needed depends on what kind of server

the system is configured to be. For example, if the system is a web server or FTP server, the

world-accessible files or directories that are used to allow access to the web server or FTP

server cannot be removed.

Configuring Set-UID (SUID) and Set-GID (SGID)The set-UID (SUID) and set-GID (SGID) settings are used to allow a regular user to run an

SUID program with the privileges of another user. These settings are typically used to allow

users to run certain programs or to execute certain commands that would otherwise require

root privileges. For example, some system administrators create scripts that users can run to

automate various tasks that would otherwise confuse or be too complicated for a regular user

to implement. The system administrator can set the UID of the script to root so that regular

users can execute the script. Recall that the chmod command is used to change the set-uid bit.

For the most part, doing this for particular scripts is a safe and effective means of allowing

users to execute scripts without having to give them root privileges. However, doing so can

leave the server vulnerable to outside attacks. If a hacker were to break into the server, he or



she could scan for set-UID programs and check for ways to exploit them. The intruder could

find the set-UID scripts and examine the source code to find out why the set-UID script was

required. Then, the hacker could initiate an attack through the use of these scripts because the

scripts are written to run with root privileges. For example, some set-UID scripts are written

so that they write to the root directory. An intruder could easily examine such a script and edit

the code in the script so that it could cause serious damage to the server when it is run. For

this reason, it might be best to use another means of allowing users to run some scripts as

the root. Again, this depends on the type of server and what kind of information the server

contains.

Using TripwireTripwire is a file-and-directory integrity checker. It is used to ensure that all the files and

directories on the system are working properly, don’t contain any errors, and have not been

damaged by a hacker. Tripwire works by first creating a database of signatures for all the files

and directories on the system. It can then be run again to create a new database of signatures

or to display the current state of the files and directories on the system. It then compares the

new signatures with the old ones to determine if any discrepancies exist. If any inconsisten-

cies are found, Tripwire reports the file or directory name along with information regarding

the discrepancy. If a hacker breaks into the system, this method can be a great help in deter-

mining which files might have been damaged.

For Tripwire to ensure the security of the server’s filesystem, it needs to be installed when the

server is being built. Here are some guidelines to follow when creating a new server system:

■ Whenever a server is being built, never hook it up to the network or Internet until it is

absolutely necessary to do so. Following this guideline helps ensure that no viruses or

any other danger to the system’s security is admitted.

■ Run Tripwire to create the database of all the important system files, configuration files,

and binaries.

■ After Tripwire is run, back up the database to a removable medium, such as a Zip disk,

or burn it to a CD-R disc. Doing so prevents the original database from being corrupted.

■ Configure Tripwire to run as a cron job daily, weekly, or monthly by using the version

that was backed up to the removable media.

Where to Find TripwireA version of Tripwire should accompany the Linux installation disks. A free version can be

downloaded from the web at http://fr.rpmfind.net.



Configuring TripwireAfter downloading the latest Tripwire RPM Package Manager (RPM) and installing the

binary packages, you will need to implement some configuration for it to work properly. One

of the first configurations to be done is setting the local pass phrase, which encrypts the Trip-

wire database and report files that are created when the program is run.

The next phase of configuring Tripwire is to create the policy file—that is, to define the rules

that Tripwire uses to perform filesystem integrity checks. These rules specify which files and

directories to check and what kind of checks will be performed. Each rule that is created is

given a name and a severity level. The severity level stipulates how major or minor the prob-

lem is if the rule does not pass the integrity check. The guidelines when creating the rules for

the policy file are as follows:

■ Never create more than one rule that applies to the same directory. Use one rule per file

or directory.

■ When rules are created for subdirectories within a directory, the more specific rule is

applied. For example, if a rule is created for the /etc/rc.d/ directory, and another rule is

created for the /etc/rc.d/init.d directory, the /etc/rc.d/init.d directory uses the rule that is

applied to that directory and not the rule that is applied to the /etc/rc.d/ directory.

Creating the DatabaseThe database must be created on a server that is completely free and clear of any infections.

The best time to create a database on a server is when it is first built and not connected to the

network or Internet. To begin creating the signature database, run the following command

from the shell prompt:

/usr/sbin/tripwire --init

Running this command applies the rules that were created in the policy file located in the /etc/

tripwire/tw.pol file, and the database is created in the /var/lib/tripwire/k2.intevo.com direc-

tory. After the database is created, copy the database to a portable medium, such as a CD-R

disc, Zip disk, or floppy disk (if the database will fit on a floppy).

Protecting the Tripwire DatabaseAfter the signature database it created is needs to be protected. The integrity of the filesystem

is dependent on the integrity of the database that checks it. A hacker can modify the Tripwire

binary files or the policy file to hide any traces of the break-in. To protect the database, you

need to create a separate set of signatures to check the integrity of the Tripwire binary files

and policy file. To do so, run the following two commands from the shell prompt:

/usr/sbin/siggen –a /usr/sbin/tripwire /usr/sbin/siggen –a /etc/tripwire/tw.pol



You might also need to create a set of signatures for the siggen utility. If for some reason

Tripwire is not working or a break-in has been detected, run these commands and verify that

the Tripwire program and policy files are intact. If for some reason the signatures do not

match, replace them with new copies, which should be located on the removable media, and

proceed to investigate how the files became corrupted.

Updating the DatabaseYou need to update the Tripwire database periodically—whenever a change is made to the

filesystem, a configuration file is modified, or a file that Tripwire is monitoring in its database

is removed. If the database is not updated, it generates a violation report when it runs integ-

rity checks on files that were changed. The update can be accomplished in one of two ways:

■ Run the /usr/sbin/tripwire --init command from the shell prompt to reinitialize the

database.

■ Run the /usr/sbin/tripwire --update command from the shell prompt to update the

database.

The database also needs to be updated if any changes are made to the policy file. To update

the Tripwire policy file with out reinitializing the entire database, enter the following com-

mand at the shell prompt:

/usr/sbin/tripwire --update-policy /etc/tripwire/tw.pol.txt

Receiving Tripwire Reports AutomaticallyYou can configure Tripwire to automatically e-mail reports about any violations to the system

administrator’s e-mail account. This feature is especially helpful when there are many servers

to manage or if Tripwire is set to run integrity checks scheduled in cron jobs.

To receive e-mails when violations are detected, the emailto attribute must be added to every

rule that is created in the policy file. Next, the /etc/tripwire/twcfg.txt file must be configured

properly with the e-mail settings for the system administrator’s e-mail account; then, the file

needs to be rebuilt. To do so, enter the following command at the shell prompt:

/usr/sbin/twadmin --create-cfgfile /etc/tripwire/twcfg.txt

To send a test e-mail to confirm that the file has been configured properly, enter the following

command at the command prompt:

/usr/sbin/tripwire -m t -email your@emailaddress

Authentication Security

Linux authentication security is a vast subject. There are many ways to authenticate users in a

Linux system, and there are many authentication security techniques. Which one is best to

use? That question is best answered by first determining what kind of server is being built. If



the server is to be a Telnet or remote access server, a form of Secure Remote Password (SRP)

or OpenSSH authentication can be used. If the server is a web or FTP server, a form of

OpenSSL authentication should probably be used. If the server is a Network Information Ser-

vice (NIS) server or a file server running Samba, a form of OpenSSH or shadow password

authentication is most likely the answer. To explain all the details of how each of these

authentication security methods works is beyond the scope of this course; in fact, there are

entire books and courses related to each one of these types of authentication. This section

focuses on the main points and processes of how these authentication security methods work

to enhance server security and to prevent unauthorized access to the operating system.

Shadow PasswordsIdeally, authentication security is intended to control user-access risks. Handling authentica-

tion security in a Linux system is somewhat tricky because it involves actually creating user

accounts on the server itself, which, by definition, is security risk. Completely removing all

user access to the Linux server, which is done in Windows 2000 Server, isn’t practical for

most Linux installations. Therefore, understanding the risks involved in creating user access

is crucial. For an experienced hacker, retrieving Linux user account names and passwords is

easy; all that the intruder needs to break into the network is a sniffer program to detect IP

packets on the way in and out of the network that contain users’ account names and passwords.

The shadow password scheme prevents passwords from being stored in a world-readable file

such as /etc/passwd; instead, it stores the passwords in the /etc/shadow file in an encrypted

form. Red Hat Linux uses the shadow password scheme by default, which makes it very sim-

ple to implement.

It is important to back up the /etc/passwd and /etc/shadow files before and after making any

modifications to them. In addition, using the pwck command to check the integrity of both

files is a good idea.

Another important way to enhance authentication security is to turn off the Telnet service. In

Red Hat Linux, the Telnet service is turned on by default. Telnet uses clear-text authentication

and does not use shadow passwords, which makes the Linux server vulnerable to a hacker

using a sniffer program.

OpenSSH The FTP, Post Office Protocol (POP), and Internet Message Access Protocol (IMAP) proto-

cols send password information in an encrypted form by default. Other protocols do not, but

there are ways, to securely encrypt the passwords and even the data. One such method is to

use the Secure Shell (SSH) protocol. The SSH protocol is designed to prevent a password

from being used even if it is intercepted.



SSH provides another means of providing secure authentication to a server: SSH is capable

of storing a special key on the server and one on the client. The client uses this key, not a

password, to authenticate to the server. Although this configuration provides a secure means

of authentication, there are some security risks involved. For example, if for some reason an

intruder were to gain access to a user’s client computer, the attacker would be able to gain

access to the server.

It is also important to mention the r-commands when discussing password authentication.

The r-commands comprise the rlogin, rsh, and rcp commands. These commands allow a

user on a UNIX or Linux system to log in to, run programs on, and copy files to and from

another UNIX or Linux system without having to be authenticated. This functionality is

accomplished by creating an .rhosts file in the user’s home directory. This file contains lists of

other hosts that are trusted. The trusted hosts can gain access to a server without having to be

authenticated. Again, some security issues can arise when this form of authentication is used,

and particular care should be taken when determining which hosts will be trusted.

OpenSSLSecure Socket Layer (SSL) is another way of securing communications on the network. The

disadvantage of OpenSSL is that because it operates at the application layer, it must be sup-

ported by the user application.

OpenSSL was developed by Netscape to provide security for its web browser. It uses public/

private key encryption. Although it is often referred to as public key encryption, the more

accurate term is public/private key encryption because this type of encryption uses two keys:

one that is published and is widely available, and one that is private and known only to the

user. Both keys are required to complete the secure communication. This type of encryption

is also referred to as asymmetric encryption.

With this type of encryption, each user has both a public and a private key, called a key pair.

The following example discusses the use of public/private encryption.

Carol and Ted exchange their public keys. It does not matter if this is done in an insecure

manner, because the messages cannot be deciphered with just the public key.

Carol wants to send a message to Ted, so she encrypts the message using Ted’s public key. A

public key is associated with only one private key. To decrypt a message that was encrypted

using a public key, the associated private key is required. The reverse also applies—that is, to

decrypt a message that was encrypted using a private key, the associated public key is required.

Ted, using his private key, can decrypt the message because it was encrypted using his public

key. Notice that only Ted’s keys, public and private, were used in this encryption process.


Linux Infrastructure-Level Security 793

If Carol had encrypted the message using her private key, anyone could decrypt the message

using her public key, which is available to everyone.

Both keys of the same key pair must be used for this encryption to work, and there is no need

for anyone to know the private key of anyone else. A good way to understand this type of

encryption is to think of the two pieces of information that are required to enter a home pro-

tected by a digital combination lock. If someone wants to enter the house, both the street address

and the number sequence to enter into the locking device must be known. The address is pub-

lic information that is published in the telephone directory. It is available to anyone, just as

the user’s public encryption key is available to anyone. The lock combination is analogous to

the user’s private key. Only the owner of the house knows it. Both keys are unique to that par-

ticular home, but whereas one is made known to the public, the other is kept secret.

Linux Infrastructure-Level SecurityThis section discusses securing a Linux-based operating system at the infrastructure level,

including securing Samba, the Network File System (NFS), and the xinetd daemon. Samba is

a suite of protocols that allows Windows-based clients to access files on a Linux or UNIX-

based server. Samba works through the Server Message Block (SMB) and Common Internet

File System (CIFS) protocols to allow access to the file space and printers of the server. NFS

was created to allow systems to mount partitions that reside on remote machines as if the par-

tition were part of the local system. The xinetd daemon starts, stops, and runs many important

services that are used on a typical Linux server.

Securing Samba

There are four levels of Samba security, each of which has different methods and rules

regarding how client/server authentication occurs. The four Samba security levels are as

follows:

■ User

■ Share

■ Server

■ Domain

The security level is set using the security parameter in the global section of the smb.conf file.

User-Level SecurityUser-level security is the default security level that Samba runs in. Using this type of authen-

tication, the Samba server accepts or rejects user access based upon only a correct username



and password submission. Using this type of Samba authentication security offers no means

of controlling user access to resources located on the Samba server after the user has pro-

vided the correct username and password.

This type of Samba authentication security uses Pluggable Authentication Modules (PAM) to

authenticate a user to the Samba server, which means that users use the regular /etc/passwd or

/etc/shadow files to verify they have entered the correct username and password. In addition

to Samba, many other programs on a Linux system use PAM to handle the burden of authen-

tication instead of imposing this workload on the application itself. In the latest releases of

Linux, most of the programs that require user authentication have PAM built into them,

which allows a system administrator the ability to freely and easily use multiple types of

authentication schemes for a single application. Previously, if a system administrator wanted

to implement a different authentication scheme for a particular program, he or she would

have had to update and recompile the privilege-granting program. Using PAM, Samba can

understand the shadow password scheme it uses for authentication by calling the PAM library

to handle the user-level security authentication.

Share-Level SecurityTo configure Samba for share-level security, the security parameter in the smb.conf file needs

to be set to share. Using this type of Samba security, the clients have to enter a password for

each share that they want to access. A system administrator can use this form of security to

protect certain files or directories within the Samba file server. The users have to enter a dif-

ferent password for each shared drive that is protected with share-level security. The users do

not have to enter multiple usernames because Samba matches previously given usernames

and authenticates the users to the share using the regular /etc/passwd or /etc/shadow files to

verify that they have entered the correct username and password.

One advantage of using share-level security is that a user account does not have to be created

for each Samba user created on the server. By setting the guest account parameter to samba-guest in the smb.conf file, the system administrator could create one user account called sam-

baguest and then create passwords for the various shares to control access to certain files and

directories.

Server-Level Security When the Samba server is running server-level security, the user enters a username and pass-

word just as in user-level security mode. In fact, to the user, the session is established and

appears to run exactly the same as it does in user-level mode. However, the authentication

processes, including the checking of the username and password, are performed by an exter-

nal password server, typically a Windows 2000 server. The external server can be a Samba



server that is running in user-level security mode. This type of Samba authentication security

can be used to enhance security because actual user accounts do not have to be created on the

Samba server. Server-level security can use encrypted passwords; however, this setting must

be selected on both the Samba server and the external password server. To configure Samba

for server-level security, the security parameter in the smb.conf file needs to be set to server.

Domain-Level SecurityDomain-level security works in the same manner as server-level security, with just a few

exceptions. User authentication to the Samba is handled by an external password server; how-

ever, when the user connects, the dedicated connection is not maintained as it is in server-

level security. The Samba server connects to the remote password server for as long as it

needs to authenticate the user, and then it disconnects. Another difference is that the Samba

server can use the trusted domain feature in the event that the password server is a Windows

2000 server and a member of a Windows 2000 domain or is itself a Windows 2000 domain

controller. To configure Samba for server-level security, the security parameter in the smb.conf

file needs to be set to domain, and the Windows 2000 domain name and Samba Network

Basic Input/Output System (NetBIOS) name also need to be entered in the smb.conf file.

Additional Samba Security TasksIn addition to the four main levels of security that a Samba server can run in, several tasks can

be implemented to further enhace or control the security of a Samba server. These methods

include avoiding the use of plain-text passwords; allowing access to users from trusted Win-

dows 2000 domains; controlling Samba access by network interface, host name, or IP

address; and using OpenSSL with Samba.

Although it is the default, plain-text passwords should never be used for authenticating users

to the Samba server. It is a fairly simple process to configure the Samba server to user-

encrypted passwords instead of plain-text passwords. The first step involves uncommenting

out the encrypted passwords = yes and smb passwd file = /etc/samba/smbpasswd lines in

the smb.conf file.

The second step involves actually creating the smbpasswd file so that the encrypted pass-

words have a file in which to be stored. Keep in mind, however, that the actual passwords are

not stored in the smbpasswd file—only an encrypted version of the password is stored. To

create the smbpasswd file, follow these steps:

Step 1 Log in as the root user.

Step 2 Enter the following command to create the smbpasswd file:

cat /etc/passwd | /usr/bin/mksmbpasswd.sh > /etc/samba/smbpasswd



Step 3 Create Samba user accounts the same way you would create any other regular

user account; however, when creating the password for the Samba user, use the

smbpasswd command instead of the passwd command. Doing so creates an

encrypted password instead of a plain-text password.

To allow users from trusted domains to access the Samba server, configure the Samba server

in domain-level security mode. This type of security is helpful when a Windows 2000 domain

and the trust relationships between Windows 2000 domain controllers have already been

established. By installing Linux Samba server in one domain, users from a separate but

trusted domain can be authenticated to the Samba server using their Windows 2000 Active

Directory authentication username and password.

You can also control Samba access by network interface. This technique useful for a Samba

server that has two network interface cards (NICs). In the smb.conf file, the interfaces

parameter needs to be configured with the IP address of the interface that allows Samba

access, and the bind interfaces only parameter needs to be set to yes.

Using OpenSSL to control Samba authentication is probably the most secure way to allow

users to access a Samba server. The OpenSSL process of using public and private keys

instead of usernames and passwords for authentication was discussed earlier in this appendix.

For the Samba program to use OpenSSL, it needs to be recompiled and configured with SSL.

Securing NFS

A Linux NFS server is another way to implement a file server in a Linux network. Before

installing such a server, you need to consider several security issues. Several methods that can

be used to enhance the security of an NFS server are as follows:

■ Granting read-only access to the exported directory

■ Disabling access to certain directories

■ Secure the portmap setting

■ Limiting root privileges

Let’s take a look at each of these methods in turn.

Granting Read-Only AccessNFS shares are exported from the NFS server to an NFS client. To allow read-only access

privileges to the exported directory, the ro parameter must be applied to the filesystem or

directory that is exported to the NFS client. For example, to apply this parameter to the /www

directory for the webdev.cisco.com client, you would use the following syntax:

/www webdev.cisco.com(ro)



Disabling Access to DirectoriesWhen filesystems or directories are exported to an NFS client and certain restrictions (such as

the read-only restrictions mentioned in the previous section) are assigned, the same restric-

tions apply to all of the subdirectories. In many cases, the result is not desirable. In this

instance, it is possible to add the noaccess parameter to the directories and subdirectories that

are to remain restricted to being accessed by all the clients using the exported filesystem or

directory. For example, to apply the parameter to a subdirectory of the /www directory for the

webdev.cisco.com client, you would use the following syntax:

/www webdev.cisco.com(ro)/www/webadmin_access(noaccess)

Securing the portmap SettingYou can use the portmap setting to further control access to Linux NFS shares. By using the

ALL parameter in the portmap setting in the /etc/hosts.deny file, a system administrator can

restrict access to an exported filesystem or directory for all users. Next, use the /etc/

hosts.allow file to allow access to certain hosts from specified networks. Remember to use

only network IP addresses to specify which hosts have access because entering specific host

names can cause errors.

For example, the entry in the /etc/hosts.deny file would be:

portmap: ALL

The entry in the /etc/hosts.allow file to allow access from the 10.0.2.0/255.255.255.0 network

would be:

portmap: 10.0.2.0/255.255.255.0

Limiting Privileges of the Root AccountLimiting the privileges of the root account is always a good security measure to increase

security on any Linux server. This appendix has already discussed how much damage can be

caused if a hacker breaks into the server and compromises the root account. If such an attack

occurs, a system administrator is virtually defenseless to any attack that might occur. For this

reason, it is best to limit, restrict, or eliminate altogether any privileges that the root account

has. Two methods that can be used to limit the privileges of the root account are as follows:

■ Explicitly deny root control, which is referred to as squashing the root user

■ Use the NOSUID and NOEXEC options

By default, Linux prohibits root privileges on the NFS client from being treated as root on the

NFS server. Simply stated, this means that any file that is owned by the root on the NFS

server cannot be modified by the root user on an NFS client. However, these properties can be



enforced for any exported filesystem or directory. For example, to explicitly enforce this pol-

icy on the /admin_access directory, use the following syntax in the /etc/exports file:

/admin_folder webdev.cisco.com(rw, root_squash)

By entering this parameter on an exported filesystem or directory, the root account in the NFS

client is not able to access or to modify any exported filesystem or directory that only the root

account on the NFS server has access to or can modify.

Using the NOSUID option, a system administrator can disable set-UID programs from run-

ning on the NFS share by using the nosuid parameter in the /etc/exports file. The syntax to do

so is as follows:

/admin_folder webdev.cisco.com(rw, root_squash, nosuid)

Using the NOEXEC option prevents any files or programs from being executed on the NFS

share.

Securing the xinetd Daemon

The xinetd daemon is responsible for starting, stopping, and running many of the services for

which a typical Linux server is primarily used. For example, the xinetd daemon runs the FTP,

Apache (HTTP), Sendmail, POP3, and several other critical services. On most large net-

works, often only one of these services is running to handle the workload. Usually, one, two,

or maybe more dedicated web servers handle Internet or intranet services, or one, two, or

maybe more dedicated e-mail servers handle sending and receiving e-mail. In these cases,

where the xinetd daemon is handling the sole responsible service that the Linux server is run-

ning, it is critical to enforce effective security measures. The xinetd daemon is a common

source for intruder attacks. If the xinetd daemon is compromised, the entire server can be shut

down or severely damaged.

Some common security measures that will help protect the xinetd daemon are as follows:

■ Strengthen the default configurations.

■ Control access by host name, IP address, or time of day.

■ Take steps to reduce the risks of denial of service (DoS) attacks.

xinetd Default SettingsThe default settings of the xinetd daemon are in the file. Initially, this file has no security set-

tings at all. Typically, the rule to follow is to deny access to everyone and then to allow access

to only the users that need access. The default settings of this file, which allow access to

everyone, violate this rule entirely. One of the first steps to take to deny access to everyone is

to add the following line to this file:

no_access = 0.0.0.0/0



This IP address configuration covers the entire range of possible addresses, and the no_access attribute states that any system attempting to get access to the xinetd daemon from that IP

address will be denied. Therefore, everyone will be denied. The next step involves enabling

configuration so that access can be granted to only those users that need access.

The first recommendation is to change the interval parameter from the default value of 60 to

a more manageable number, such as 15 or 20. This parameter states how many simultaneous

connections can be made at one time. Obviously, this number might need to be adjusted

depending on how many simultaneous connections will be made to the server.

Next, add the line per_source = 10 to the /etc/xinetd.conf file. This line limits the number of

connections that one remote host can make to a service.

Lastly, it is important to disable the r* services—that is, remote access commands such as

rlogin, rsh, and rexec. These files are known for being insecure and should not be used.

These commands can be deleted by adding the following line to the /etc/xinetd.conf file:

disabled = rlogin rsh rexec

After the default settings in the /etc/xinetd.conf file are configured properly, start the xinetd

daemon. Then, using service-specific configuration files, you can enable access to users or

addresses that require access. This process will be explained in the following sections.

Filtering Access by Host Name, IP Address, or Time of DayThe xinetd daemon has a very easy means of controlling access via host name or IP address.

Previously, access had to be controlled by making entries in the /etc/hosts.allow and /etc/

hosts.deny files. This task made the process much more complicated. The xinetd daemon is

capable of handling this process internally.

Every service that xinetd controls has its own service configuration file. For example, to con-

trol who has access to the Telnet service, the /etc/xinetd.d/telnet file needs to be configured

with the appropriate settings. If a system administrator wants to restrict Telnet access to users

on the internal network that have an IP address of 10.3.2.0/24, the following lines need to be

added to the /etc/xinetd.d/telnet file:

# only allow access from the 10.3.2.0/24 subnetonly_from = 10.3.2.0/24

The only_allow attribute is used to specify which hosts, subnets, or IP address will be

allowed access. The only_allow attribute can be used to allow access from specific IP

addresses or host names as well. In this case, the exact IP address or host name of the system

that will be allowed access needs to be entered. As many entries as needed can be entered.



The no_access attribute can also be used to disable access for a particular subnet of IP

addresses, a single IP address, or a set of host names. The syntax for the no_access attribute

is as follows.

# Don’t allow access from the 192.168.1.0/24 subnetno_access = 192.168.1.0/24

Restricting access times is accomplished using the access_times attribute. When restricting

access times, keep in mind that the attribute specifies when access is allowed, not when

access is restricted. This feature can be helpful when a server needs to go down for a period

of time for maintenance, such as a system backup. There could be reasons other than security

for limiting access times to certain services. The syntax for the access_times attribute is as

follows:

# Allow access only during the following hoursaccess_times = 07:00-20:00

Reducing DoS AttacksDenial of service (DoS) attacks are a common threat that system administrators face. A typi-

cal DoS attack results in the server’s resources being so overwhelmed that the server either

locks up, crashes, or runs so slowly that legitimate access cannot be granted. The xinetd dae-

mon has several security features that can be enforced to reduce the risk of a DoS attack.

Unfortunately, it is difficult to prevent all DoS attacks, but the following methods help reduce

that risk.

As previously mentioned, a number of concurrent instances of a service can be used by a sin-

gle remote user. Reducing the amount of single instances of a service that are allowed to be

concurrently opened can reduce the chance that a DoS attack will completely consume all the

system’s resources.

Another trick to decrease the risk of a DoS attack is to limit the size of log files. Many of the

daemons that xinetd runs make entries in log files when a user accesses them. An attacker

who knows this can send many requests to a daemon that writes a lot of log file entries and

overwhelm the server. To limit the log file size of a particular log file to 10 MB and to receive

a warning when the size reaches 8 MB, use the following syntax:

log_type FILE /var/log/xxxxx.log 8388608 10485760

The xxxxx.log represents the log file that needs to be limited.

Limiting the rate of connections also helps reduce the risk of DoS attacks. Doing so limits

how many times xinetd is allowed to start per second. Two numbers need to be entered: the

first controls the frequency, and the second specifies how long xinetd will wait after the limit

has been reached. For example, let’s say that the maximum amount of servers that can be

started is 10, and the server will wait 60 seconds if this limit is reached. Requests that are


Securing Linux Network Services 801

made during this waiting period are denied, and the service is unavailable. The syntax for this

scenario is as follows:

#Only 5 connections per secondcps = 10 60

Securing Linux Network ServicesThis section discusses securing network services running on a Linux-based operating system.

Coverage includes securing of FTP, web, and mail servers.

Protecting a Linux FTP Server

Several types of FTP servers can be used on a Linux server. This appendix focuses on the

security of the wu-ftpd FTP server. The latest versions of Red Hat use this FTP server by

default, so it should already be installed. If that is not the case, the Red Hat Package Manager

(RPM) package can be downloaded at http://www.rpmfind.net.

You can enhance the security of an FTP server in one of several ways. Which method you

should use depends on who will be accessing the server and from which locations. The fol-

lowing methods for securing the wu-ftpd server are discussed in this section: restricting FTP

access by username, restricting FTP access to a particular group, using a chroot jail, and

using options in the /etc/ftpaccess file.

Restricting FTP Access by UsernameThe wu-ftpd server uses PAM to authenticate users. (Previous sections discussed the process

PAM uses to authenticate users.) The PAM authentication file that wu-ftpd uses is /etc/pam.d/ftp.

Denying FTP access to certain users is a fairly simple process. The /etc/ftpusers file is used to

explicitly deny users FTP access. User accounts that typically cause security issues if allowed

access are default entries in this file. Any username that should be denied FTP access should

be entered in this file.

Restricting FTP Access by GroupDenying access for individual users is a cumbersome task for any system administrator. It is

almost impossible to keep track of all the individual users that should not have access. Plus,

doing so violates the security code previously mentioned in this appendix—that is, deny

access to everyone and then allow access to only the users that require access. Restricting

users on an individual basis might be appropriate for a small network where a security threat

is not as great as in a large corporation. For a big network, it is easier to deny complete FTP

access and then to create groups of users that are allowed access.



To accomplish this task, you need to create a file that contains a list of only those users who

will have FTP access after everyone has been denied. To do this, follow these steps:

Step 1 Open the /etc/pam.d/ftp file with a text editor and comment out the

pam_listfile line.

Step 2 Add the following line to the /etc/pam.d/ftp file as the first line in the file:

auth required /lib/security/pam_listfile.so item=user sense=allow file=/etc/userlist.ftp onerr=fail

Step 3 Create a file named /etc/userlist.ftp. Add users and groups that will have access

to this list.

Creating a chroot JailUsing a Linux server for an FTP server is a potentially risky setup because, by default, when

users connect to the FTP server they are taken to the FTP root directory and are able to freely

move to any directory they want, including the root directory and all its subdirectories. For

many security reasons, this is not a desirable setup. This security hole can be stopped by cre-

ating a chroot jail.

A chroot jail restricts user access to the FTP server to a specified directory. This directory is

typically the user’s home directory; however, it can instead be the FTP root directory, which

is sometimes more desirable if many users will be accessing the FTP server. The FTP root

directory shows only the part of the filesystem that FTP users are intended to see.

Using the /etc/ftpaccess file to Restrict FTP AccessThe main file that wu-ftpd uses to manage security is the /etc/ftpaccess file. Several types of

settings in this file can be modified from their defaults to enhance FTP security. This section

covers these settings and how to modify them.

It is important to log everything possible for the FTP server, including inbound and outbound

traffic, file transfers, and security violations. The default settings in the /etc/ftpaccess file are

set to log only inbound and outbound traffic. To add log entries for every file that is uploaded

or downloaded from the server, modify the log transfers file by adding the following line:

log transfers anonymous, real, guest inbound.outbound

Two types of security information should be logged: security violations and commands that

are entered by users. To log security violations from all users connected to the server, modify

the log security parameter as follows:

log security anonymous, real, guest



To log all the commands that are entered by users on the FTP server, modify the log com-mands parameter as follows:

log commands anonymous, real, guest

As mentioned in the previous section, by default, users that access the FTP server are allowed

to browse all the files and directories. To restrict this access, an alternative to creating a chroot

jail is to modify the noretrieve parameter by specifying which files or directories should be

off limits. The syntax for restricting access to a file or directory is as follows:

noretrieve file | dir [class=anonymous | real | guest

For example, to restrict access to the /etc directory, add the following line to the /etc/ftpaccess

file:

noretrieve /etc

The /etc/ftpaccess file contains several other parameters that you can modify to control how

wu-ftpd allows access. You should read this file carefully to understand what these other

parameters can do.

Protecting a Linux Web Server

Before this appendix discusses various methods for enhancing web server security, you

should be familiar with some of the risks that web servers face. When the Internet originated,

the web was nothing more than simple text files that people used to share information. Today,

websites are dynamic, interactive portals that allow people to access a wealth of information.

Add to that the hundreds of thousands of business who now see the Internet as a means for

easily reaching and selling their products to audiences from around the world, and you can

see why web server security has become such a major concern.

Large corporations and small businesses have become targets for Internet hackers. One major

problem that has hampered web security is the fact that, by definition, web servers have to be

accessed by the public—or, at least some of the web server’s files do. This section focuses on

ways to enhance security for the Apache web server that Linux uses, such as creating dedi-

cated user and group accounts, using a directory structure that can be easily configured for

security purposes, and establishing permissions and index files.

Establishing Users and Groups for ApacheWhen the Apache web server is running, it does so in one of two modes: either in standalone

mode or as a service that is run by the inetd daemon. If the system is running as an inetd dae-

mon, you do not need to establish dedicated users and groups. You should define these users

and groups if it is running as an inetd daemon. Remembering these guidelines makes control-

ling security much easier because it allows an administrator to a use permission-specific



right, such as assigning only the Read permission to the Apache user group. The administra-

tor can also give the Write permission to the user group if that group needs to have a directory

in which to write CGI script data.

Creating a Safe Directory StructureThe default directory structure of Apache has four main directories:

■ ServerRoot directory (/home/webadmin)—Stores the Apache server configuration

files and binaries.

■ DocumentRoot directory (/www/htdocs)—Stores the HTML web content.

■ ScriptAlais directory (/cgi-bin)—Stores the CGI scripts.

■ CustomLog and ErrorLog directories (/www/logs)—Store various access and error

log files. These two directories can be counted as one because they can and should be

combined to store all the log files in one directory.

The recommended directory structure for these directories is as follows:

■ The four directories should be independent of each other.

■ The ServerRoot directory should be able to be accessed by the root only.

■ User and group account access for the DocumentRoot directory should have permis-

sions set so that the website administrator and the Apache user group specified in the

httpd.conf file have access.

■ The ScriptAlais directory should be accessed only by users who create scripts for the

website.

■ The CustonLog and ErrorLog directories should be able to be accessed by the root only.

This type of file structure is typically safe because each directory is independent of the others

and therefore cannot be compromised in the event that a permissions error is made.

Setting the Correct PermissionsAlthough it was mentioned previously that the DocumentRoot directory should be accessed

by only the users who provide content for Apache, in many cases other people contribute con-

tent to the website and need access. To allow this access, create a temporary group and add

the user to that group. Then change the group ownership of the DocumentRoot directory to

the new group that was created, but leave the directory ownership set to Apache. Next, the

DocumentRoot directory needs to have its permissions set so that the new group can read,

write, and execute files that members of that group place in it. This process allows you to add

temporary users to the group that was created without giving them ownership of the entire

directory.



Disabling Default AccessThe major recurring theme in this appendix is to deny access to everyone and then to config-

ure appropriate settings to allow access to only the users that need it. This principle is no dif-

ferent when it comes to controlling web server security.

To first deny everyone access to the ServerRoot directory (/home/webadmin), use the follow-

ing syntax in the httpd.conf file:

<Directory /home/webadmin> Order deny.allow Deny from all</home/webadmin>

Next, to allow only the root account to access this directory, use the following syntax:

<Directory /home/webadmin> Order deny.allow Allow from root</home/webadmin>

Protecting a Linux Mail Server

Many of the security issues that exist for web servers are also a problem for mail servers.

Today more than ever, businesses rely on sending and receiving e-mail to facilitate communi-

cation throughout a company. It is estimated that more than a billion e-mails are sent through-

out the world every day. It should come as no surprise then that some of the most notorious

viruses have been sent disguised as e-mail. This method is a quick, easy way for an attacker

to get into the network. After the virus enters the network, it can expand exponentially to

other desktops and servers. This appendix discusses some of the vulnerabilities of e-mail

servers and the steps you should take that will enhance the security of a Linux e-mail server.

Testing for VulnerabilitiesThe best way to determine if the mail server’s current configuration is vulnerable to an attack

is to run some tests to see what needs to be fixed. The most widely used e-mail protocol is

SMTP (Simple Mail Transfer Protocol). However, SMTP is not designed to handle any secu-

rity features. One of the biggest threats to e-mail servers is spam. Spam e-mail is sent via

insecure e-mail servers that do not block open mail relay. One of the first security enhance-

ments you should make is to disable the open mail relay capabilities of the mail servers. To

test how vulnerable the mail server is to open mail relay attacks, follow these steps:

Step 1 From a Linux client system or server that has Telnet client tools, run the fol-

lowing command:

nslookup –q=mx cisco.com

Note that you should substitute the appropriate domain name. The cisco.com

domain is used for demonstration purposes.



This command performs a search for all the mail exchange (MX) records in the

domain. The MX records indicate the mail servers in a domain.

Step 2 Take note of all the mail servers that are returned by this command. Run the

following command for all the mail servers that are found. Substitute the mail

server’s domain name for the one used in this example:

telnet mail.cisco.com 25

The command shown here makes a Telnet connection to the SMTP port (25)

on the mail server.

Step 3 Run the following command to have the mail server initialize the connection:

ehlo localhost

Step 4 Have the mail server send a test e-mail to an e-mail address outside the internal

network. To do so, enter the following command (but substitute an appropriate

e-mail address for the one used in this example):

mail from: [email protected]

This command is telling the e-mail server to send an e-mail from the

[email protected] e-mail account.

The mail server should return a response similar to:

250 [email protected]... Sender ok

If this command is entered correctly and the mail server does not return a

response, the server is probably configured to not allow open relay mail trans-

fers at all, which means that this part of the e-mail server is configured cor-

rectly for optimum security. If this response is sent, continue to the next step to

further determine the e-mail server’s vulnerability.

Step 5 Enter the following command to instruct the e-mail server to send that e-mail

from the [email protected] account to another external e-mail account—for

example, [email protected]. The command to do so is as follows:

rcpt to: [email protected]

The mail server should return a response similar to:

250 [email protected]... Recipient ok

Again, if the e-mail server rejects these requests, the server is properly secure against open

mail relay.

Securing Sendmail Against AttacksSendmail is the most popular mail transport agent (MTA) for UNIX and UNIX-like operating

systems, such as Linux. An MTA is an ordinary e-mail server that is configured with a


Linux Network Security and Filtering Methods 807

program such as Sendmail for the purposes of forwarding and receiving e-mail from users

within a domain. One of the first steps that should be taken to secure Sendmail is to download

and install the latest version of this program from a website such as http://www.sendmail.org.

The latest versions of this program are configured by default to not allow open mail relay

functionality.

A useful command that can be used to block mail from a specific domain or e-mail address is

the REJECT command. For example, to reject from the spamcompany.com domain, enter

the following entry in the /etc/mail/access file:

spamcompany.com REJECT

The REJECT command can also be used to deny e-mail from specified e-mail addresses

as well.

Filtering ToolsThe majority of e-mail viruses and attacks occur as a result of various e-mail attachments.

The scenario is well-known one: The e-mail message appears to be benign and instructs the

recipient to open the attachment. When the attachment is opened, the virus is spread. Linux

includes a filtering tool called procmail that can scan the header and the body of each mes-

sage for patterns based on customized rules.

You can download the latest version of the procmail rule set (that is, the rules procmail uses

to filter mail) from http://www.impsec.org/email-tools/procmail-security.html. You can

download the procmail program from http://www.rpmfind.net. (For optimal performance,

make sure to install procmail from either the distribution CD or a known site, such as http://

www.rpmfind.net.)

Before installing procmail, add the following lines to the /etc/mail/sendmail.cf file:

FEATURE(local_procmail)dnlMAILER(procmail)dnl

Linux Network Security and Filtering MethodsThis section discusses Linux-based network security and filtering methods, including cover-

age of Transmission Control Protocol (TCP) wrappers, Network Address Translation (NAT),

and firewalls and proxy services.

TCP Wrappers

TCP wrappers are used in conjunction with inetd. Keep in mind that inetd is no longer used

with Linux Mandrake or Red Hat, which both use xinetd. TCP wrappers use a program called

tcpd. Without tcpd running, a server would call another server directly with inetd. When



using the tcpd program, the inetd program calls tcpd first. The tcpd program first checks to

see if the client is authorized to access the server and, if it is, the tcpd program allows the cli-

ent to access the server.

Two files are used to configure the TCP wrappers: /etc/hosts.allow and /etc/hosts.deny. By

editing these files and adding host names to them, users can either allow or deny access to the

system. Host names entered in the hosts.allow file specify which systems are allowed to gain

access to the system. If a system with a hostname that is not entered in the hosts.allow file

attempts to access the system, it is denied access. Another way to deny access to specific host

names is to enter them in the hosts.deny file.

The hosts.allow and hosts.deny files consist of lines such as the following:

■ daemon-list: client-list—The daemon-list specifies the names of servers that appear

in /etc/services. These are the servers to which access will be either granted or denied.

The client-list specifies which clients are granted access or denied access to the server

in the corresponding daemon-list. Entries in the client-list can be by host name or by

IP address.

■ xinetd—As mentioned previously, the Mandrake and Red Hat distributions of Linux

no longer use inetd. Instead, they use xinetd. Mandrake and Red Hat control access by

editing the /etc/xinetd.conf file. These edits make calls to other files located in the /etc/

xinetd.d directory. The files in the /etc/xinetd.d directory are what control the access to

the different daemons running on the system. Configuration is done on a server-by-

server basis by using the bind, only_from, and no_access parameters:

— bind—Tells xinetd to listen to only one network interface for the service. For

example, adding the entry bind = 10.2.5.1 to the file causes a router to listen to

only that specific Ethernet card address on the network.

— only_from—Works similarly to the hosts.allow file in that the user can specify IP

addresses, network addresses, or host names on this line to allow connections

only from those particular entries listed in the file.

— no_access—Works similarly to the hosts.deny file in that entries listed on this

line are denied access to the server.

Network Address Translation

Network Address Translation (NAT) is a process that usually runs on a router or a Linux

server configured as a router. However, a Linux server can be configured to run NAT. Typi-

cally, a router acts as a gateway to the Internet. A router running NAT rewrites the addressing

information that is contained in IP packets. Administrators use NAT to alter the source

address of packets that originate from a secure LAN. Doing so allows secure LANs to be

addressed using private IP addresses.



Private IP addresses are not routed on the Internet. An outside hacker cannot directly reach a

computer with a private address. Of course, hosts with private IP addresses cannot directly

reach Internet hosts either. However, a NAT router can take a packet originating from a host

with a private address and replace the packet’s source IP address with a public, globally

routable address. The NAT router records this address translation in a table. After rewriting

the addressing information, the NAT router forwards the packet toward the destination host.

When the outside destination replies, the reply packet is routed back to the NAT router. The

NAT router then consults the translation table. Based on the entries in the table, the NAT

router rewrites the addressing information. After the address is rewritten, the packet can be

routed back to the original, privately addressed host.

NAT is often deployed in conjunction with proxy services and/or IP packet filters. It is also

becoming an important technology in homes and small offices because NAT allows hundreds

of computers to borrow a single public, globally routable IP address. This process is some-

times called “many-to-one” NAT, address overloading, or Port Address Translation (PAT).

Popular desktop operating systems include built-in NAT services, such as Microsoft Windows

Internet Connection Sharing. NAT services are also included in network operating systems.

Red Hat Linux uses the ipchains program to perform NAT. Other NAT programs include

ipmasquerade and natd.

Some experts make a distinction between NAT and a firewall. Others look at NAT as part of a

comprehensive firewall solution. Regardless, a NAT server can protect the network from an

attack because outsiders might not be able to send packets directly to inside targets or use

scanning techniques to map the internal network.

Firewalls and Proxy Services

The key defense against Internet attackers is an Internet firewall. A firewall is specialized

software, hardware, or a combination of the two. The purpose of an Internet firewall is to pre-

vent unwanted or malicious IP packets from reaching a secure network.

Over the last decade, firewall technology has evolved significantly. Early firewalls filtered

packets based on addressing information. These firewalls were built and maintained by large

organizations. Today’s desktop operating systems, such as Windows XP, include built-in fire-

wall capabilities that are geared toward the average home user. The increasing number of

hacker exploits and Internet worms make firewall technology an essential aspect of any enter-

prise network.

The term firewall is used loosely to refer to several approaches to protecting networks, as

described in the sections that follow.

A boundary router connects the enterprise LAN to its Internet service provider (ISP) or the

Internet. The boundary router LAN interface leads to a network designed for public access.



This network contains NOS servers that provide the World Wide Web, e-mail, and other ser-

vices to the public Internet. This public network is sometimes referred to as a dirty LAN or a

sacrificial LAN because public requests are allowed on the network.

The public network is also commonly called the demilitarized zone (DMZ). The DMZ acts as

a buffer area. The boundary router should include an IP filter that protects against obvious

vulnerabilities. For example, Simple Network Management Protocol (SNMP) should not be

allowed into the network from the outside. The NOS servers in the DMZ should be tightly

configured. The boundary router should allow only specific types of traffic to these servers—

that is, HTTP, FTP, mail, and DNS-related traffic.

A dedicated firewall solution, such as a Cisco Private Internet Exchange (PIX), connects the

DMZ to the protected LAN. This device performs additional IP filtering, stateful filtering,

proxy services, NAT, or a combination of these functions.

The DMZ is designed to keep the inside network clean.

A NOS such as Linux can function as part of a firewall solution by filtering packets, running

NAT, or acting as a proxy server. In low-traffic environments, such as small offices and home

networks, a NOS firewall solution is a good choice. In high-traffic environments, a special-

ized packet filtering and NAT solution is recommended. A specialized device, such as a router

or firewall appliance, is designed to switch packets and to manipulate them quickly. A NOS

running on ordinary hardware might be able to do the job; however, it cannot do so without

adding latency and overhead on the server.

Packet FiltersTypically, an Internet firewall is a host running IP packet filtering software. Most LANs run

IP packet filters on a router or a specialized host. Specialized hosts, such as Linux servers,

can also perform routing. Home users can run IP packet filtering on an end system, such as a

Linux or Windows PC.

The most basic firewall solution is an IP packet filter. To configure a packet filter, a network

administrator must define the rules that describe how to handle specified packets.

The first packet filters filtered packets based on the addressing information contained in the

packet header—namely, the source and destination IP addresses. At the time, the IP packet

header and the packet filters operated at Layer 3 of the OSI model.

Later, packet filters were designed to base decisions on information contained in the TCP or

User Datagram Protocol (UDP) header at Layer 4. Both TCP and UDP use port numbers to

address specific applications running on a host. Layer 4 access lists can be configured to per-

mit or to deny packets. This configuration is based on source or destination ports in addition



to IP address information. For example, a Layer 4 access list can be configured to permit traf-

fic destined for a specific IP address at port 80. This is a well-known port that web servers lis-

ten on.

Access Control ListsPacket filters are sometimes called access control lists (ACLs). An IP packet filter begins with

a list of rules. The rules tell the router or host how to handle packets that match the specified

criteria. For example, a packet matching a particular source address can be dropped, for-

warded, or processed in some special way. There are several aspects of common matching

criteria:

■ IP address, source, and destination

■ TCP/UDP port number, source, and destination

■ Upper layer protocol (HTTP, FTP, and so on)

A host configured with an IP packet filter checks packets that come into or out of a specified

interface or interfaces. Based on the rules defined, the host can drop the packet or accept it.

This approach is also referred to as rules-based forwarding. Using this approach, administra-

tors can configure routers to drop unwanted or potentially harmful packets. Administrators

configure the routers before the packets reach the secure LAN.

Proxy ServicesIn networking, a proxy is software that interacts with outside networks on behalf of a client

host. Typically, client hosts on a secure LAN request a web page from a server that is running

proxy services. The proxy server then goes out on the Internet to retrieve the web page. Next,

the web page is copied to the proxy server. This process is referred to as caching. Finally, the

proxy server transmits the web page to the client.

By using the services of a proxy, the client never interacts directly with outside hosts. This

setup protects clients from potential Internet threats. Administrators can configure proxy

servers to reject certain client requests or outside Internet responses. For example, schools

can use proxy servers to control which websites can be accessed. Because all web requests

are directed to the proxy, administrators have tight control over which requests are honored.

Microsoft makes available for its NOS a comprehensive proxy service called Microsoft Proxy

Server 2.0.

Proxy servers work to insulate LANs and to protect hosts from outside threats. The ability of

the proxy server to cache web pages is important. The benefit is the use of a proxy service for

HTTP. Multiple clients can access the HTTP content with significantly improved response

time. Caching the frequently accessed HTTP content on a local server is responsible for the

improved response time.



Windows 2000 Authentication SecurityThis section addresses authentication security in Windows 2000. Topics covered include the

security architecture of Windows 2000, the process involved in authenticating users, and an

explanation of Kerberos authentication.

Identifying the Security Architecture

Security in Windows 2000 is far more complex than it was in previous Windows network

operating systems. Windows 2000 security offers a completely new security model with

many new security technologies for securing access to the network, resources, and the pri-

vacy and integrity of data and communications.

Windows 2000 provides an integrated set of security services that employ such features as

support for the Kerberos authentication protocol, Encrypted File System (EFS), Active Direc-

tory service, and Internet Protocol Security (IPSec). The distributed security services are an

essential part of the operating system and address many key business requirements.

The Windows 2000 operating system’s security model provides excellent administration tools

and a solid security infrastructure that supports the enterprise and the Internet. Through the

use of trusted domain controller authentication, delegation of trust between services, and

object-based access control, Windows 2000 makes it easy for organizations to protect their

information and networked resources.

Authenticating Users in Windows 2000

In Windows 2000, security is based on a simple model of authentication and authorization.

Authentication is the process by which an entity’s identity is proven and validated. An entity

can be a user, a computer, or a service. For example, computers and services are authenticated

when they make network connections to other servers.

A principal is identified by a security identifier (SID) and uses credentials to prove its iden-

tity during the authentication process. Examples of credentials are a principal’s account

name, password, smart cards, and certificates. After the credentials are verified, authorization

takes place. Authorization is the process of determining whether an identity (plus a set of

attributes that are associated with that identity) is permitted to perform some action, such as

accessing a resource.

How Authentication WorksThere are two types of authentication:

■ Logon authentication

■ Network authentication


Windows 2000 Authentication Security 813

Logon authentication takes place when the user initially signs onto the network. Microsoft

calls the logon process a local logon or interactive logon because the user interacts with the

computer by typing a username and password. The interactive logon process begins when a

user presses the key combination Ctrl-Alt-Del. Doing so initializes Secure Attention Sequence

(SAS) on computers with a standard Windows 2000 configuration.

In response to SAS, Winlogon, a security service that provides interactive authentication,

calls the Graphical Identification and Authentication (GINA) module. The GINA component

is responsible for displaying the logon interface. After a username and password are supplied

and a domain name is selected, GINA collects the logon information, securely packages it in

a data structure, and returns it to the Winlogon service. Winlogon then passes it to the Local

Security Authority (LSA) for authentication.

The LSA is the operating system kernel component that handles user authentication. It vali-

dates credentials by comparing them with the entries in its authentication database. If the user

account was issued by the LSA, the LSA can verify a user’s information by checking its own

account database. If the account was issued by the security authority for the local domain or

a trusted domain, the LSA must contact the issuing security authority to verify the user’s

information.

A valid interactive logon results in a local logon session. Otherwise, a user is denied access.

Network authentication confirms the user’s identity to network services or resources that the

user attempts to access. Network authentication is transparent to the user because of a feature

called single sign-on, which allows network users to access all authorized network resources

on the basis of an initial authentication. During the initial authentication, a user’s credentials

are cached. When a user wants to access a Windows 2000 system that is located across the

network, the LSA on the workstation establishes an identity with the LSA on the remote

computer using the cached credentials. This identity is called an interactive logon.

The process of authentication involves verifying the identity of the user (or the identity of the

computer or service), but the step-by-step details vary according to which authentication pro-

tocol is used. Windows 2000 supports several protocols for verifying the identities of users

trying to gain access to the system. However, there are only two options for network authenti-

cation within and between Windows 2000 domains: Windows NT LAN Manager (NTLM)

and Kerberos Version 5.

NTLM is an advanced challenge/response based protocol. It is the default authentication pro-

tocol for network authentication on systems running versions of the Windows NT operating

system earlier than Windows 2000 and on standalone systems.

The Kerberos Version 5 authentication protocol is the default network authentication protocol

for computers running Windows 2000. Kerberos is a distributed security protocol that is



based on Internet standard security. It is used to provide fast, single sign-on to network ser-

vices within a domain and to services residing in trusted domains. It also provides service to

other environments that support the Kerberos protocol.

How Kerberos Authentication Works The Kerberos authentication protocol uses a ticketing system. This system uses two basic

ticket types: ticket-granting tickets (TGTs) and service or resource tickets. A Kerberos ticket

provides a way to transport a Kerberos session key, which is the basic entity Kerberos uses

for secure authentication across the network. The Kerberos authentication protocol also pro-

vides mutual authentication between resources before making a network connection by using

the Data Encryption Standard (DES) shared-secret key concept for authentication. In this

scheme, instead of sharing a password, communication partners share a cryptography key.

Each partner uses the key to verify the other’s identity. For this authentication technique to

work, the shared secret key must be symmetric, meaning that a single key must be capable of

both encryption and decryption.

In Windows 2000, a trusted third party is needed to mediate between two authenticating enti-

ties. A Key Distribution Center (KDC) serves as the mediator. Windows 2000 implements a

KDC, known as the Kerberos realm, on every domain controller. Because each domain con-

troller is a KDC, physical security is a high priority.

How Kerberos WorksWhen a user logs on to a Windows 2000 domain (or a Kerberos realm), the user is issued a

TGT by the KDC service. A TGT contains information about the user. This information is

encrypted in a key known by the KDC. The TGT serves as a user’s network authentication. At

logon and at each TGT renewal, users use their password to authenticate to the KDC. In sub-

sequent ticket requests, users have to use only their session key, which their TGT contains, to

authenticate to the KDC. As a result, the number of times a user needs to enter the password

for authentication is reduced, which in return decreases the possibility of attacks. (Note that if

a user changes his or her password during a logon session, the user must reenter his or her

user ID and password to obtain a new TGT.)

When a client wants to access a network resource or service, the client presents the TGT to a

Kerberos server and requests access to the resource/service. In response, the Kerberos service

constructs a ticket for the resource or service. In return, the ticket randomly generates a ses-

sion key, which is sent to the client and the resource/service server via the client. When a

server receives a ticket and an authenticator from the client, the server has enough informa-

tion to authenticate the client. The Kerberos protocol verifies both the identity of the user and

the identity of the network resource or service. The client authenticates to the server, and the

server authenticates to the client. As a result, a mutual authentication occurs.


Windows 2000 Operating System Level Security 815

Windows 2000 Operating System Level Security This sections covers Windows 2000 security at the local operating system level. Topics

include securing file and print resources, EFS encryption of files, and auditing of resource

access.

Securing File and Print Resources

Organizations must identify the data that they want to protect, classify this data accordingly

to its value, and implement the necessary protection. The first step in determining the appro-

priate level of security is to understand how data is stored in a Windows 2000 system.

A file system is the principal method of data storage. It is used by the operating system to

store data in a computer’s hard disk. A file system provides controls on the storing and shar-

ing of data. Windows 2000 supports the following file systems:

■ File Allocation Table (FAT or FAT16)—Commonly used in MS-DOS, Windows 3.x

and Windows 95

■ File Allocation Table 32 (FAT32)—Commonly used in Windows 98

■ New Technology Filing System 4 (NTFS4)—Commonly used in Windows NT 4.0

■ New Technology Filing System 5 (NTFS5)—Commonly used in Windows 2000

Which file system you use depends on your operating system and your needs. FAT16 is the

old MS-DOS file system. It uses 16-bit disk addresses, which limits its use to disk partitions

no larger than 2 GB. FAT32 uses 32-bit disk addresses and supports disk partitions up to 2

terabytes (TB). NTFS is a new file system developed specifically for Windows NT that car-

ried over to Windows 2000. It uses 64-bit disk addresses and can (theoretically) support disk

partitions of up to 264 bytes, although other considerations limit it to smaller sizes. Windows

2000 also supports read-only file systems for CD-ROMs and DVDs. In many cases, multiple

file system types might be available on a single system.

The FAT file system offers little security. File attributes can be set to system or read only,

which only makes it more difficult to accidentally delete a file. Therefore, Microsoft recom-

mends that you use NTFS to achieve the highest level of security in Windows 2000. NTFS

offers robust features to control access to the hard drives and their contents. It also offers sig-

nificant performance advantages over FAT file systems.

Sharing DataAn important requirement of users is the ability to share files or data across the network.

Before users can access files across the network, they must be shared. However, in Windows

2000, a file cannot directly be shared. One of the most common ways to facilitate file or data

sharing is to use shared folders. Windows 2000 shared folders or shares are a way in which



files, folders, printers, and other resources can be published for network users to access.

When a folder is shared, users can connect to the shared folder from their client computers

and access the files under the shared folder as if the files were stored in their local computers.

Because shares might contain important data, care must be taken to ensure that shared

resources are secure.

One of the benefits of the NTFS file system over the FAT file system is the ability to set per-

missions to protect resources. The NTFS file system works jointly with the Windows 2000

user account system to allow authenticated users access to resources. Permissions can be set

on shared folders, files, folders, printers, and Active Directory objects. Permissions define

what level of access a user has to a resource and what specific actions a user can perform.

To gain access to files in a shared folder, users must first be granted access to that folder. To

grant access, an administrator can set shared folder permissions. One of three permissions

can be assigned to users for a share: Read, Change, and Full Control.

Permissions for shares are additive or least restrictive, meaning the least restrictive of all the

permissions applies to the user. For example, let’s say a user belongs to one group that has

been assigned Full Control permission to the share. The user also belongs to another group

that has been assigned only a Read permission. Because Full Control is the least restrictive of

the two permissions, the user will have Full Control of the share.

Shared folder permissions can be applied to only the shared folder, not to the individual files

and subfolders that the share folder contains. In addition, share folder permissions apply only

to users who connect to the folder over the network. As a result, it does not restrict the access

of users who log on locally to a computer.

In contrast, NTFS permissions can be used to control users’ access to files and folders on the

local computer and in network shared folders. NTFS supports the following base-level file

permissions: Full Control, Modify, Read and Execute, Read, and Write. It also supports the

following base-level folder permissions: Full Control, Modify, Read and Execute, List Folder

Contents, Read, and Write. For simplicity, the file system combines the base permissions into

commonly used high-level permissions for files and for folders. Permissions for files and

folders are also least restrictive. For example, let’s say a user has been assigned a Read per-

mission to a file. The user also belongs to a group that has been assigned Full Control to the

same file. Because Full Control is the least restrictive permission, the user will have Full Con-

trol of the file.

Up to this point, we have discussed both share and NTFS permissions and how each can be

used to protect the privacy of a user’s data. Both types of permissions can be assigned to mul-

tiple groups and users for the same files or for the same share, which can cause some confusion.

However, as mentioned previously, in such cases we calculate the sum of the permissions for

files/folders and shares using the “least restrictive” rule.



How can we be certain that we are applying the correct mixture of share and NTFS permis-

sions to supply the appropriate amount of data protection? To do so, we must first understand

how share and NTFS permissions work together. Effective permissions are the permissions

for a user accessing files and folders through a share combined with the user’s NTFS permis-

sions. To ensure that the proper amount of protection is in place, we have to correctly calcu-

late the effective permissions.

The key to this calculation is to calculate first for files and folders, then separately for shares.

Both calculations are prepared using the “least restrictive” rule. Next, calculate the total effec-

tive permissions using the “most restrictive” rule to combine the two. For example, let’s say a

user’s least restrictive permission for his or her files/folders is Read. In addition, the least

restrictive permission for the share is Change. By using the most restrictive rule, we calculate

the user’s effective permissions to be Read because it is a more restrictive permission than

Change.

To summarize, use the least restrictive rule to calculate a user’s permissions to files, then use

the least restrictive rule to calculate the user’s permissions to the share. After completing

these calculations, take the most restrictive of the two.

Note that when both NTFS permissions and shared folder permissions are set for a shared

folder, the administration effort is doubled. Therefore, some companies choose to use only

NTFS permissions to control users’ access on shared data both locally and through the

network.

Sharing Printers Providing printer access is similar to providing access to files and folders. Like files and folders,

printers must be shared before users can access them across the network. Providing shares for

printers is almost identical to providing shares for files and folders, except you cannot limit

access to the print share. By default, a print share is open to everyone, and this setting cannot

be modified. However, access to print shares can be restricted by using security permissions.

In Windows 2000, printer permissions are separated into three categories: who can print,

who can manage documents or jobs, and who can manage printers. Incidentally, a user can

be assigned all of the permissions. As with files and folders, when multiple permissions are

assigned to a group of users, the least restrictive permission applies. However, when deny is

applied, it takes precedence over any permission.

Encrypted File System

The Encrypted File System (EFS) was designed to address weaknesses in NTFS by providing

file encryption capabilities on an NTFS file system. EFS runs as an integrated system service,



which makes it easy to administer and difficult to attack. EFS is based on public key encryp-

tion and uses the Data Encryption Standard X, or DESX (128 bit in North America and 40 bit

international) as the encryption algorithm.

EFS guarantees privacy of sensitive data by ensuring that only an owner of a file can access

the file. Users of EFS are issued a digital certificate with a public and private key pair that is

used for EFS operations. At a minimum, EFS requires a certificate for the file owner and a

certificate for a recovery agent account. Both are stored in the certificate store on the local

computer. If these certificates are not present when a user logs on to the network, EFS builds

them automatically. If no certificate service exists, EFS creates a key pair and generates a

self-signed certificate, which allows a user to begin using EFS without any further config-

uration. After a user has a valid certificate, the process of issuing one does not have to be

repeated. Note that EFS can use Microsoft Certificate Services to issue certificates to users

and recovery agents. EFS uses symmetric key encryption in conjunction with public key

encryption to provide confidentiality for NTFS files. Symmetric key encryption, also known

as secret key encryption, is an algorithm that requires the same secret key to be used for both

encryption and decryption. Symmetric encryption algorithms, although they are not as secure

as public key encryption, are fast and are typically used for encrypting large amounts of data.

In contrast, public key encryption, also known as asymmetric key cryptography, is very

secure. However, this method of encryption achieves its high level of security at the expense

of speed. It uses two different but complementary keys, called a key set or key pair. One key is

the private key. This is the secret half of the cryptographic key pair and is held by only its

owner. It is typically used to digitally sign data and to decrypt data that has been encrypted

with the corresponding public key. The second key is the public key. This is the nonsecret half

of the key pair and can be made available to others with whom the user needs to interact. It is

typically used to verify digital signatures or to decrypt data that has been encrypted with the

corresponding private key. A secured transaction requires both the public and the private keys

to encrypt and decrypt the data that is contained within the transaction.

The public key approach also provides the ability to “sign” encrypted data. This allows the

recipient to verify that the decrypted message actually came from the individual whose public

key was used in decrypting.

How EFS WorksEFS benefits from using both symmetric and public key encryption. As previously mentioned,

symmetric key encryption provides speed but is less secure, and public key encryption pro-

vides more security but at the expense of speed. EFS capitalizes on the strengths of each by

using a combination of both techniques.



EFS encrypts data using the faster symmetric key encryption algorithm to generate a unique

key called a file encryption key (FEK). The FEK is then encrypted using the stronger but

slower public key encryption. This combination of faster data encryption with stronger

encryption safeguards the FEK and provides the benefit of a digital signature. The encrypted

FEK can safely be included along with the encrypted file for storage and to be retrieved by

the recipient(s). When the file needs to be accessed, the private key is used to decrypt the

FEK. After the FEK has been decrypted, it is then used to decrypt the file.

To encrypt or decrypt a file or a folder, the corresponding attribute must be set. The attribute

for encryption and decryption is set in the same way that the read-only, compressed, or hidden

attribute is set. If you encrypt a folder, all files and subfolders that are created in the encrypted

folder are automatically encrypted. (Microsoft recommends encrypting at the folder level.)

When you decrypt a folder, you are presented with a choice to decrypt only the folder or to

decrypt the files and subfolders as well. If you select to decrypt only the folder, the encrypted

files and folders within the decrypted folder remain encrypted. However any new files or

folders that you create in the decrypted folder will not be encrypted unless you encrypt them

manually.

Data Recovery SystemBefore it can be used, EFS requires at a minimum a certificate for the file owner and a certifi-

cate for a recovery agent account. An EFS Encrypted Data Recovery Agent policy identifies

the data recovery agent (DRA) accounts; therefore, it must be in place before EFS can be used.

The policy should be set at the domain level (or at the local level for standalone machines). If

defined at the domain level, the policy is enforced on all computers in that domain.

A recovery agent account is used to restore data for all computers covered by the policy. For

use in data recovery operations, recovery agent accounts are issued recovery agent certificates

with both public and private keys. Recovery agents are available to access encrypted data in

catastrophic circumstances, such as the loss of an EFS private key or if a user is no longer

available. By default, the recovery agent account is the highest-level administrator account. In

a Windows 2000 domain, the domain administrator account for the first installed domain con-

troller is the default recovery agent account. In the case of a standalone machine, the local

administrator is the default recovery agent account. By modifying the EFS recovery policy,

additional recovery agents can be designated. In addition, you can configure separate recov-

ery policies for different parts of the enterprise. Note that if you configure an EFS recovery

policy with no recovery agent certificates, EFS is disabled.



How Recovery WorksIn EFS, recovering an encrypted file does not require any type of recovery utility. Therefore,

the word “recovery” is somewhat misleading. Instead, the procedure for recovering a file

works essentially the same way as the process of decrypting a file. Every time a file is

encrypted, the FEK is also encrypted with the recovery agent’s public key. This encrypted

FEK is attached to the file along with the copy of the FEK that is encrypted with the owner’s

public key. When the file needs to be recovered, all the DRA needs to do is double-click the

file icon to open the file. The recovery agent’s private key is used to decrypt the FEK. After

the FEK has been decrypted, it is then used to decrypt the file. A more appropriate term for a

DRA might be a “secondary access account.”

However, the procedure for recovering the file is not as simple as an administrator logging on

to the machine where the file resides and opening the file. To open the file, the administrator’s

or DRA’s private file recovery key must also be present on the machine where the file resides.

Remember that in a domain environment, this private key does not reside on the local machine;

it resides on the first installed domain controller in the domain. In a standalone environment,

the private key resides on the local machine of the administrator. In either instance, to recover

the file, the encrypted file and the DRA’s private key must exist on the same machine.

An encrypted file cannot be copied to another computer by anyone other than the encrypting

user. Therefore, to recover the file, the DRA must either import the DRA private key to the

computer where the file resides or move the file to a computer where you have already

imported the DRA private key.

From Certificates in Microsoft Management Console (MMC), use the Export command to

export the file recovery certificate and private key to a floppy disk. Next, use the Import com-

mand (from Certificates in MMC) on the machine where the encrypted file is located, to import

the file recovery certificate and private key into the personal store on the local machine. The

DRA can now start the recovery process.

After you have exported the recovery certificate and private key, make a copy on a floppy disk

or CD and keep it in a secure place. If the file recovery certificate or private key on your com-

puter is ever damaged or deleted, you can use the stored copy to replace the damaged or

deleted certificate and private key.

Use Backup in Windows 2000 or any backup program designed for Windows 2000 to make a

backup version of the encrypted files or folder. Backup programs designed for Windows 2000

retain the encryption of the backed-up files. Restore a user’s backup version of the encrypted

file or folder to the computer where your file recovery certificate is located. After the file is

decrypted, return the backup version of the decrypted file or folder to the user as an e-mail

attachment, on a floppy disk, or on a network share.

NOTE

If you have access through a second com-puter through a roam-ing user profile, you do not need to export and import your file encryp-tion certificate and pri-vate key because these are available on any computer that you log on to.



Auditing Resources Access

Auditing is the capability to track security events (activities of users and processes). It is a

valuable tool for helping to maintain the security of network systems. Auditing enables

administrators to proactively identify security issues and to react to the vulnerability before

an attack or lapse occurs. Auditing is a better method than manual monitoring because it

monitors the system even when you cannot. In addition, auditing maintains a record of sys-

tem access. Without auditing in place, identifying security lapses and getting the information

needed to resolve a security issue is nearly impossible.

With Windows 2000, Microsoft has improved on the auditing features found in previous ver-

sions of Windows. One of the enhanced features is the way that the auditing policy is config-

ured. Whereas Windows NT 4.0 restricts the auditing policy to a local machine (or, in the

case of domain controllers, to all controllers in the domain), in Windows 2000, audit policies

set at the domain level can also filter down to servers and workstations within the domain. In

this case, the settings made at the domain level override those set locally. Also new in Win-

dows 2000 is the capability to audit Active Directory–related events.

Setting Up AuditingAn important decision that you must make before enabling auditing is to determine what

information actually needs to be recorded. In Windows 2000, you can audit almost any action

by either the system or a user. Although auditing provides much useful information, auditing

events consumes system resources, such as memory, processing power, and disk space. The

more you audit, the more it affects system performance. In addition, the more you audit, the

more information you will need to study and review to find key patterns. The goal is to strike

a balance so that you audit enough events to be effective, yet not so many that important

information gets lost.

As is the case with EFS, an NTFS file system is required to implement auditing. Auditing by

default is not enabled when Windows 2000 Server is installed. It must be enabled on the local

computer (server or domain controller) before auditing of events can be logged. Depending

on the services installed, Windows 2000 auditing uses six possible logs:

■ Application

■ System

■ Security

■ Directory Service

■ File replication

■ DNS server



This section focuses on the Security log, which contains information related to security events.

These events range from valid and invalid logon attempts to creating, opening, or deleting

files. Such actions can be audited on a success or failure basis. For example, suppose that you

were auditing user logins. A success audit would be a situation in which a user logged in suc-

cessfully. A failure audit would be a situation in which a user tried to log in but was denied

access.

To begin auditing security events, start by configuring an auditing policy. By default, no pol-

icy is set when Windows 2000 is installed. (Note that only an administrator or a member of

the Administrators group can set up auditing.) The method used to create an audit policy var-

ies slightly depending on whether the policy is being created on a domain controller, a mem-

ber server, a workstation, or a standalone machine. However, the same basic tools are used in

each case, and the methods are not that different. All of the methods use the security-related

Microsoft Management Console snap-ins. When configuring a domain controller, a member

server, or a workstation, the Active Directory Users and Computers snap-in is used. When

configuring a system that does not participate in a domain, the Local Security Settings snap-

in is used.

Auditing can also be applied to objects. Windows 2000 object auditing can be applied in a

variety of areas: files and folders, printers, the registry and directory services. To begin the

process of auditing access to specific objects, turn on the Audit Directory Service Access cat-

egory (for auditing directory objects on a domain controller) or the Audit Object Access cate-

gory (for auditing file system, registry, or printer objects). The next step is to set auditing on

the individual objects themselves.

Auditing is only part of the process. For auditing to be a useful tool, regular review of the log

to scan events is necessary. You can use the Event Viewer console, located in the Administra-

tive Tools folder, to view all of the system’s logs. To access the Event Viewer and the Security

log, a user must be logged on with administrative privileges. To view the details of the event,

select the entry in the log. Events are listed either as an audit success, designated by a key

icon, or as a failure, designated by a padlock icon. Note that directory access audit informa-

tion appears in the Directory Service event log. The Directory Service event log appears only

in the Event Viewer on Windows 2000 domain controllers.

Windows 2000 Infrastructure-Level SecurityThis section addresses the security of Windows 2000 at the infrastructure level. Topics cov-

ered include securing Active Directory, managing security with Group Policy, and securely

updating DNS records.


Windows 2000 Infrastructure-Level Security 823

Securing Active Directory

Windows 2000 Server includes a directory service called Active Directory. The Active Direc-

tory service is a combination of a directory and services. A directory is physical storage that

contains various kinds of objects. Services enable the resources in the directory to be useful.

In Active Directory, the combination of these two elements provides a network-based object

store and service that manages resources and that makes these resources available to autho-

rized users and groups.

Active Directory provides network administrators with a single point of administration for all

network objects. It replaces the Windows NT account database as the repository for user and

machine account information. However, in addition to user and machine accounts, Active

Directory contains policy information, certificates, and an array of additional objects, includ-

ing applications, printers, and devices.

Active Directory is organized using the following logical components:

■ Objects—The actual instances of object classes that you create to define how Active

Directory is organized. Objects represent information and resources, and are organized

according to how they are used.

■ Attributes—The characteristics of an object.

In addition, four basic components make up an Active Directory structure:

■ Sites—Locations in a network that hold Active Directory servers. A site is composed of

one or more IP subnets. These subnets are tied together by high-speed, reliable connec-

tions. By defining a site as a set of subnets, administrators are able to configure Active

Directory access and the replication topology in a way that takes advantage of the phys-

ical network. When users log on to the network, Active Directory clients find the Active

Directory servers that are in the same site as the client.

■ Domains—The core units of the logical structure in Active Directory. A domain is

basically a security boundary. It is an administrator-defined logical grouping of com-

puters, servers, and other hardware that share a common directory database. A domain

provides access to the centralized user and group accounts maintained by the system

administrator.

■ Forests—Domains are arranged in a hierarchical structure called a forest. This struc-

ture starts with a domain called the forest root domain. The domain is then arranged in

a format that is similar to a family tree, with parent and child domains, and so on. These

trees share a common schema, configuration, and global catalogue.

A forest serves two main purposes:

— To simplify the management of multiple domains

— To simplify user interaction with the directory



By default, every child domain has a two-way trust with its parent. This trust, called a

transitive trust, is extended to all other domains in the forest, which helps to form the

forest as a single unit.

■ Organizational Units (OUs)—Container objects that Active Directory system admin-

istrators use to organize objects within a domain. An OU can contain objects such as

user and group accounts, servers, computers, printers, and applications.

The ability to centralize administration and the control of resources that Active Direc-

tory provides is critical to creating a secure system. Active Directory uses OUs to orga-

nize network resources in a logical hierarchy. It stores information about accounts and

resources in one location, which gives network administrators an easy way to update

that information. Users seeking access to network resources have to pass through only a

single checkpoint instead of having to log on repeatedly to access resources on differ-

ent systems.

Protecting the integrity of Active Directory is also vital to overall network security. Active

Directory provides administrators with a high degree of control over who has access to infor-

mation in Active Directory. Restricting access to Active Directory is paramount. Access to

Active Directory information can be controlled down to the object attribute level. Each object

and object attribute has a unique identifier that allows it to be individually secured.

Windows 2000 provides protection for Active Directory with the following features:

■ Discretionary access control lists (DACLs)—Determine who can see an object and

what actions are available for the user to perform. A DACL can be used for individuals

or groups and applies to object attributes and object classes.

■ Delegation—Allows administrators to delegate, to designated users, selected responsi-

bilities for OU ownership and administration.

■ Access rights—Allow the granting or denying of user rights and actions to individuals

and groups for objects or a class of objects.

■ Trust relationships—Allow users in one domain to access resources and information

in other domains.

In addition, to provide protection for Active Directory, administrators can implement policy-

based management that allows them to assign specific security controls to specific classes of

objects, all from a single location.

Managing Security with Group Policy

Group Policy provides enhanced capabilities for specifying user and computer configura-

tions. It is an administrator’s tool for defining and controlling how network resources, the

operating system, and programs operate for users and computers in an organization. With


Windows 2000 Infrastructure-Level Security 825

Group Policy, you can ensure that the machines on your network remain in a secure configu-

ration after deployment.

In an Active Directory environment, Group Policy settings are associated with an Active

Directory container, such as a site, domain, or OU. Settings are applied to users or computers

on the basis of their membership in these containers. By default, settings in a Group Policy

are inherited from a site, to a domain, and finally to the OU level. Also, a policy can be blocked

at the Active Directory site, domain, or OU level. Moreover, a policy can be enforced on a

per–Group Policy object basis.

By default, Group Policy affects all computers and users in a selected Active Directory con-

tainer. However, filters based on users’ and computers’ membership in a Windows 2000 security

group can be used within Group Policy, which can greatly simplify the process of administer-

ing users with dissimilar security requirements.

Security configurations provide preconfigured sets of security settings that can be applied as

part of Group Policy enforcement. The security areas that can be configured for computers

include:

■ Account policies—Include computer security settings for password policy, lockout

policy, and Kerberos policy in Windows 2000 domains. (Settings are effective at the

domain level only.)

■ Local policies—Include user rights, security settings for audit policy, and security

options.

■ Event log—Includes control settings for Application, Security, and System event logs.

Logs can be accessed via Event Viewer.

■ Restricted groups—Enable administrators to enforce a membership policy regarding

sensitive groups, such as Enterprise Administrators.

■ System services—Control startup mode and access permissions for system services.

■ Registry—Used to configure Registry settings.

■ File system—Used to configure security settings for file-system objects. This includes

access control, audit, and ownership.

Using Security Templates and Security Configuration and

Analysis Tools

Two tools—Security Templates and Security Configuration and Analysis—are extremely

useful in applying the network security policy and in evaluating whether individual machines

comply with the policy. With these tools, templates with specific security settings can be con-

figured. These security settings can be applied to the machines and periodically evaluated to

verify that they remain properly configured.



You can use the Security Templates tool to build templates that can be imported into Group

Policy. This process applies all the settings that are configured in the template to all of the

computers in the container that are linked to the Group Policy. In addition, you can use the

Security Configuration and Analysis tool to verify that the security settings applied with

Group Policy are actually in use and to apply the security template to the machine. However,

using the Security Configuration and Analysis tool to apply the settings allows a user to per-

manently reconfigure the settings. With Group Policy, if a user changes a security setting, the

setting is changed back to its original value the next time Windows 2000 applies the policy.

Therefore, it is better to use Group Policy for this purpose.

Securely Updating DNS Records

Active Directory follows the Domain Name System (DNS) standard for naming objects.

DNS is an industry standard name-resolution service that allows clients to locate Active

Directory services. DNS can be used for name resolution in a company, both internally and

externally.

The integration of DNS and Active Directory is a key feature of Windows 2000. Active Direc-

tory relies heavily on DNS. It uses DNS to publish the Active Directory services. As a result,

other Windows 2000 systems can easily locate these services, regardless of where they are

located in the enterprise. DNS maps host names to numerical IP addresses. DNS allows you

to assign a more meaningful name to a host. DNS is able to resolve the following: IP addresses

to host names, host names to IP addresses, and services to both host names and IP addresses.

Because DNS and Active Directory are so tightly integrated, you must treat them with equal

importance when defining your security strategy.

Name servers exposed to the Internet are especially subject to a wide variety of DNS attacks.

There are several ways in which DNS security can be provided, including the following:

■ Secure transactions—Involves securing queries, responses, and other messages that

the name server sends and receives. For example, recursion can be disabled, which puts

your name servers into passive mode. It tells the servers to never send queries on behalf

of other name servers or resolvers. Because a nonrecursive name server does not send

queries, it does not cache any data. Note that recursion cannot be disabled on a server if

any other name servers use the name server as a forwarder. The same is true if any

resolvers use the server for querying purposes. If recursion cannot be turned off on a

server, another option is to restrict queries. DNS can be configured to accept queries

from only known addresses and zones.

■ Restrict the server—Involves refusing queries, zone transfer requests, and dynamic

updates from unauthorized addresses. Restricting zone transfers prevents others from

taxing your name server. It also prevents hackers from listing contents of your zones to


Securing Windows Network Services 827

identify targets or to gain host demographic information. For example, dynamic

updates should be restricted, as much as possible, to individual addresses. Although

dynamic updates are useful, they are also dangerous. If an unauthorized person gains

access to a dynamic update, he or she can delete all the records from a zone and add

completely different records.

Additional recommendations for securing DNS are as follows:

■ Separate DNS zones by using a firewall—Two DNS zones can be created with the

same name on either side of a firewall. In this scenario, an internal DNS server with

Active Directory services maintains records and handles requests from machines on the

LAN. A second DNS server (which is not managing Active Directory services) main-

tains records and handles requests for hosts on the public network. As a result, the inter-

nal DNS server is protected from unknown hosts.

■ Run the latest name server version—Although running the newest version does not

guarantee that a name server will be protected, it can minimize the possibility of an

attack.

■ Follow relevant newsgroups and mailing lists closely—Doing so enables you to

quickly find out about vulnerabilities and any necessary reconfiguration or patches.

Securing Windows Network ServicesAs the importance and convenience of the Internet continues to grow in businesses, so does

the need for web servers in the business computing environment. To address that need, Win-

dows 2000 Server includes an updated version of Internet Information Server (IIS) called IIS

5.0. IIS 5.0 is the World Wide Web service integrated into Windows 2000 Server. IIS provides

support for standard Internet services, such as the World Wide Web, FTP, SMTP, and Net-

work News Transfer Protocol (NNTP). To ensure server security, IIS 5.0 adds support for

important industry standard security protocols, including Kerberos Version 5 authentication

protocol, Transport Layer Security Server Gated Cryptography, Digest Authentication, and

Fortezza.

The following five major security mechanisms are used to secure IIS 5.0:

■ Authentication—Allows the identity of anyone requesting access to websites to be

confirmed. IIS 5.0 supports the following authentication types: anonymous authentication,

basic FTP authentication, anonymous FTP authentication, and integrated Windows

authentication.

■ Certificates—Allows both servers and clients to authenticate each other using digital

identification documents.



■ Access control—Allows permissions to be configured for websites. IIS uses two layers

of access control:

— Web permissions—Define what HTTP verbs can be used to access server

resources.

— NTFS permissions—Define the level of access that user accounts have to direc-

tories and files on the server.

■ Encryption—Scrambles information before it is sent. Decryption unscrambles the

information after it has been received.

■ Auditing—Consists of creating auditing policies for directory and file access or server

events, and monitoring the security logs to detect security breaches.

Protecting a World Wide Web Server

The World Wide Web Service supports HTTP functionality, which provides tighter logon

security, improved transfer speed, and additional virtual hosting abilities to the default server

cababilities. This service allows users to publish content to the Internet. To share content, files

are placed in directories on the website. These files are viewed with a web browser, such as

Microsoft Internet Explorer.

A home directory is the central location for files published in a website. A default home

directory (\wwwroot) is created when you install the World Wide Web service. However, the

location of the default home directory can be changed. It is extremely important to protect the

privacy of the content in these directories. The Directory Security property sheet can be used

to configure a web server’s security features. It contains the following sections:

■ Anonymous Access and Authentication Control—Consists of three authentication

methods. One or more of these methods can be selected.

■ Allow Anonymous Access—Allows users to connect to a web server using an anony-

mous or guest account.

■ Basic Authentication—Requires a username and password when the Allow Anony-

mous option is disabled or access to the server is determined by NTFS ACLs. When

this option is enabled, the password is sent in clear text.

■ Windows NT Challenge/Response—Requires a username and password when the

Allow Anonymous option is disabled or access to the server is determined by NTFS

ACLs. When this option is enabled, the password is sent encrypted.

■ Secure Communications—Uses Key Manager to create a certificate request.

■ IP Address and Domain Name Restrictions—Allows administrators to grant or to

deny access to resources using IP addresses or Internet domain names.


Securing Windows Network Services 829

Protecting an FTP Server

FTP is the protocol used for copying files to and from remote computer systems over a TCP/

IP network. Although the World Wide Web has replaced many of the FTP functions, FTP is

still used to copy files between clients and servers over the Internet.

Both Windows 2000 security and the IIS Internet Service Manager control the security of the

FTP service. By using a combination of the two, effective security can be enforced on the FTP

server.

■ Windows 2000 Security—Security usage is similar to that of the World Wide Web. A

default home directory, \Ftproot, is created when you install the FTP service (its loca-

tion can be changed). The Home Directory and Directory Security sheets can be used to

set access privileges. For example, access can be limited to specific users or groups by

specifying IP addresses.

■ IIS Internet Service Manager (ISM)—All FTP property sheets can be accessed using

the ISM. Some of the property sheet features are connection configuration, which

enables the setting of the length of time in seconds before the server disconnects an

inactive user. Also, logging can be enabled, which records details about user activity

and creates logs in your choice of format. Another important feature is the use of secu-

rity accounts. By using security accounts, you can control users’ access to the server. In

addition, the account for anonymous client logon requests can be specified here.

There are many vulnerabilities and potential attacks for both web and FTP servers. Therefore,

it is essential that you secure these servers before putting them on the Internet. Although most

types of servers restrict access to selected users, web and FTP servers often allow unrestricted

access to their services. Unfortunately, some of the users that connect to these servers might

try to compromise or to attack the server.

Here are some additional suggestions for securing the web and FTP servers:

■ Isolate the web and FTP servers, when possible. When these systems are connected to

the rest of your network, the setup creates a door into the network.

■ Set up web and FTP servers to meet specific needs. Remove all web or FTP services

unless there is a specific purpose for having them.

■ Keep current with service packs and patches.

■ Set up alternate accounts. Anonymous logons are necessary if there is a need for the

general public to access the website. However, anonymous logons should be carefully

planned to protect the network. For example, when IIS is installed, it automatically cre-

ates a generic account named IUSER_MACHINENAME. This account name should be

changed immediately after IIS is installed.



■ Restrict or grant access to your web and FTP server by IP address.

■ Set properties for each web and FTP folder. Establish usernames and passwords to con-

trol access to parts of the website and to secure data.

Protecting a Windows Mail Server

Mail delivery has become a common component of Internet sites. The SMTP service compo-

nent, installed with IIS, facilitates the transmission of Internet mail. Microsoft SMTP Service

provides full support for SMTP and is compatible with standard SMTP mail clients. SMTP is

the protocol for sending e-mail messages between servers. The SMTP service uses the SMTP

protocol to transport and to deliver messages.

The SMTP service in IIS is completely directory based. The SMTP installation creates the

following directory structure in the \inetpub\mailroot directory:

■ BADMAIL—Stores messages that the SMTP service is unable to deliver.

■ DROP—Holds all mail for the SMTP service. Each file represents an email message.

■ PICKUP—Picks up outgoing messages that are manually created as text files and cop-

ies them to the directory. As soon as a mail message goes into this directory, the SMTP

service picks it up and either delivers it to the Drop directory or sends it to the SMTP

service for the destination domain.

■ QUEUE—Holds messages for delivery. If the SMTP service cannot deliver a message

immediately because of a network problem or other connectivity problem, the message

queues in the Queue directory. The SMTP service holds the message for a configurable

length of time, then tries to retransmit it a configurable number of times.

■ ROUTE, SORTTEMP, and MAILBOX—Sort and rearrange outgoing messages to

make delivery more efficient. If several messages are going to the same remote host, IIS

tries to send them using a single connection instead of transmitting each one individu-

ally and having to reconnect multiple times.

The SMTP service uses the following five property sheets, which can be accessed using ISM,

to configure different aspects of the service:

■ SMTP Site—Allows you to choose the name and IP address of the SMTP site, and to

configure the ports and connection settings. Logging can also be enabled.

■ Operators—Used to designate permissions for specific user accounts for the SMTP

site.

■ Messages—Sets limits for messages, including the size and the number of recipients.

■ Delivery—Used to set delivery and routing options, such as maximum retries, maxi-

mum hop count, and security options.


Windows Network Security Methods 831

■ Directory Security—Specifies the methods for anonymous access and authentication

control, and sets up a secure communication method.

Using SSL/TLS

Two of the leading general-purpose, secure web communication protocols are Secure Socket

Layer (SSL) and the open Transport Layer Security (TLS) protocol that is based on SSL. The

SSL and TLS protocols are widely used to provide secure channels for confidential TCP/IP

communication on the web. SSL and TLS guarantee the authenticity of web content while

reliably verifying the identity of users accessing restricted websites.

Other protocols, such as HTTP and Lightweight Directory Access Protocol (LDAP), run on

top of TCP/IP in the sense that they use TCP/IP to support typical application tasks, such as

running email servers or displaying web pages. The SSL protocol runs above TCP/IP and

below higher-level protocols such as HTTP. It uses TCP/IP on behalf of the higher-level pro-

tocols. TLS is a protocol that enables authentication and data encryption over insecure net-

works. It is implemented as a layer between TCP/IP and higher-level network protocols, such

as HTTP and SMTP. The TLS protocol is an updated version of the SSLv3 protocol. The two

protocols are closely related although not directly interoperable.

At the beginning of a SSL and TLS session, the client and the server try to agree on a cipher

suite, a group of cryptographic algorithms they will use for authentication and session encryp-

tion. The server chooses the strongest cryptography that is available to both the server and the

client. After the client and the server have negotiated a cipher suite, they can authenticate

each other and have the web browser generate a session key. The web browser encrypts the

session key with the server’s public key. It then sends the encrypted session key to the web

server. Using its own private key, the server decrypts the session key and establishes a secure

channel. The web server and the browser then use the session key to encrypt and decrypt all

data traffic sent between the client and the server.

Windows Network Security MethodsThe Internet offers many valuable services. A connection to the Internet allows an organiza-

tion’s staff to obtain information from an immense number of resources. In addition, an orga-

nization’s staff can use company resources from home or any remote location, allowing them

to work more effectively. As a result, the need to provide access to the Internet has increased.

However, with increased usage of the Internet comes increased risk. Services accessible from

the Internet can be misused; therefore, organizations must employ security strategies to pro-

tect the privacy of their data. Windows 2000 includes a variety of technologies to secure an

organization’s network for access to and from the Internet.



Today, many organizations have smaller networks that are a part of a larger network yet

remain separate from it. These networks are usually peer-to-peer networks. A peer-to-peer

network, also called a workgroup, is commonly used for small office/home office (SOHO)

networks. In this type of network, computers directly communicate with each other on a sin-

gle subnet and do not require a server to manage network resources. In general, a peer-to-peer

network is most appropriate where fewer than ten computers are located in the same general

area.

Windows 2000 includes two technologies that allow translated connections between the cli-

ents on the SOHO and either the Internet, the corporate network, or both:

■ Internet connection sharing (ICS)

■ Network Address Translation (NAT)

Both technologies provide translation, automatic IP addressing, and name resolution services

to all computers on a SOHO network.

Internet Connection Sharing

Internet connection sharing (ICS) is a feature of network and dialup connections that allows

multiple machines to simultaneously access the Internet with a single Internet connection.

With ICS, if a single computer is connected to the Internet, the Internet service can be shared

with other computers on the SOHO network. ICS can be configured on Windows 2000

Server, Professional, or Windows 98 Second Edition.

ICS configuration is quite simple. The computer where ICS is configured is called an ICS

host. On the ICS host, in the Network and Dial-Up Connections component, just click a sin-

gle check box—Enable Internet connection sharing for this connection—to share the dialup,

virtual private network (VPN), or incoming connection. After ICS is enabled, each computer

can use programs such as Internet Explorer and Outlook Express as if that computer were

directly connected to the Internet.

The ICS host computer requires at least two network interfaces or connections. (This setup

can be accomplished by using two network cards, or perhaps a network card and a dialup

connection.) The LAN interface connects to the computers on your SOHO network via a net-

work adapter. The Internet interface connects the SOHO network to the Internet via modem,

ISDN, digital subscriber line (DSL), or cable modem. ICS is configured on the Internet inter-

face because this is the interface that is to be shared. The Internet interface has an external IP

address. It is assigned this address either via a dialup (local ISP) or fixed network connection.

However, after ICS is enabled, the network adapter for the Internet interface is automatically

configured with a static IP address of 192.168.0.1. This address is part of the IP address range

of 192.168.0.0 to 192.168.254.254.



In addition to configuring the ICS host computer, the SOHO network users must also con-

figure Internet options for ICS on their local machines. The ICS host also acts as a mini

Dynamic Host Configuration Protocol (DHCP) server by supplying IP addresses to clients on

the SOHO network. Therefore, the client machine’s TCP/IP properties must be configured to

obtain an IP address automatically. Clients point to the 192.168.0.1 interface as their default

gateway and are assigned IP addresses in the appropriate range. The ICS host also has a DNS

proxy function, meaning that all client host name resolution requests are forwarded to the

ICS host for resolution via the configured external DNS parameters.

Note that after ICS is enabled, no other networking services, such as DHCP and DNS, are

allowed on the network. These services are all implemented by the ICS system.

Network Address Translation

NAT is a feature of routing and remote access that is similar to ICS but that is more robust

and flexible. Although it contains some of the same functionality as ICS, NAT has additional

features that make it more suitable in some environments.

NAT is used to allow multiple computers on a private network to share a single Internet con-

nection. The computer that NAT is installed on, the NAT host, can act as a network address

translator, a simplified DHCP server, a DNS proxy, and a Windows Internet Name Service

(WINS) proxy. Unlike ICS, which can be configured on multiple Windows operating sys-

tems, NAT requires, at a minimum, Windows 2000 Server.

NAT requires at least one external public IP address. All requests for Internet services or

external resources, by clients on the SOHO network, are made using this external address.

As a result, all requests for services on the Internet appear to be originating from this single

address. Consequently, a layer of obscurity is provided for the private network, therefore pro-

tecting the IP addresses of the NAT clients from hosts outside of the private network.

When a client wants to transmit information to a server on the Internet, it sends a packet. The

packet includes, in the source fields, the IP address and port of the client (or source). Also

included in the packet, in the destination fields, is the IP address and port of the server (or

destination). In this case, the destination computer is external to the network. Therefore, the

client forwards the packet to the NAT server (the default gateway).

The NAT server will create, for the packet, a port mapping. The port mapping consists of the

IP address and port of the destination server, the IP address and port of the NAT server, the

network protocol in use, and the internal IP address and port from the client. The port map-

ping is maintained in a table that is stored on the NAT server.

Before the NAT server forwards the packet to the destination server, it translates the packet.

Packet translation is accomplished by swapping the source field information that is included



in the packet. The client machine’s source field information (IP address and port) is replaced

with the NAT server’s source field information. As a result, when the destination server

receives the packet, it thinks it is communicating with a single machine, the NAT server. In

return, it addresses response packets to the external IP address and port of the NAT using its

own IP address and port in the source fields.

When the NAT server receives a response to a request, it compares the ports of the received

packet to its table of stored port mappings. It attempts to find a port mapping where the

source IP address and port, destination port, and network protocol of the incoming packet

correspond to the remote host IP address and port, external port, and network protocol. If

the NAT server finds a match, it performs a reverse translation. This time, the NAT server

replaces the external IP address and port, in the destination fields of the packet, with the client

machine’s private IP address and internal port. Then it forwards the reply to the client

machine. Note that if the NAT server does not find a matching port mapping, the incoming

packet is dropped, and the connection breaks.

Routing and Remote Access Services

Windows 2000 Routing and Remote Access (RRAS) service was first introduced in Service

Pack 4 for Windows NT Server 4.0. It is a much-enhanced version of the previous Remote

Access Service (RAS) provided in Windows NT. The earlier version of RAS provided dialup

capabilities only; routing was a completely separate service. Windows 2000 combines remote

access services with routing services on the same computer, thereby creating a Windows

2000 remote access router. This gives RRAS the ability to provide both dialup and routing

capabilities.

RoutingRouting is the term that describes the means of directing data from one network segment to

another, or for communicating with hosts outside of a LAN, if no specific or direct route is

known. It is the process of using addressing information that is present in a network packet to

determine the best path for delivery of the packet on the network. As networks increase in

size, so does the addressing complexity, which in turn increases the need for routing. Routing

is extremely valuable to a network because it provides the network with the ability to handle

increased users and data without sacrificing performance. More importantly, routing enables

the capability to filter certain traffic for security.

There are several benefits in choosing Windows 2000 Server routing capabilities over a dedi-

cated hardware router. For example, in a small- to medium-size organization (typically, fewer

than 50 network segments), the budget might not support the cost of a dedicated hardware

router. Likewise, a site might choose to build a small special-purpose LAN, in which case a

router would be a relatively large expense. Also, when a Windows 2000 system is implemented



to function as a router, it is no longer necessary for an administrator to acquire the expertise

necessary to maintain and administer a traditional router.

Windows 2000 Server offers several routing capabilities. It provides multiprotocol LAN-to-

LAN, LAN-to-WAN, VPN, and NAT services. It also supports several routable protocol

suites, including TCP/IP and Internetwork Packet Exchange (IPX) routing. These routing

options make it possible for Windows 2000 to integrate into an existing network.

In addition, Windows 2000 routing features offer the ability to secure access to network

resources by packet filtering. When packet filters are enabled on the router interfaces, detailed

rules control what traffic will be accepted or forwarded on that interface.

Remote Access ServicesAs mentioned earlier, RRAS also offers services for remote access. Medium to large net-

works need a more robust architecture for providing users with remote access. RRAS allows

remote access clients to send and to receive data more securely and efficiently by utilizing the

Internet as a data path. RRAS connects remote users to resources on the internal network as if

their computers were physically connected to the network. It provides many new features that

address the shortcomings of the Windows NT version of RAS. Although RRAS still allows

remote users to connect to the corporate network through a traditional dialup connection, it

also provides such new features as VPNs, infrared, and direct cable connections. This service

also provides several ways to maximize security.

How Remote Access WorksTo connect to the internal network from a remote location, a user first dials a remote access

server on the network. The user is granted access to the network under the following condi-

tions: The request matches one of the remote access policies defined for the server, the user’s

account has been enabled for remote access, and the user is authorized to access the network.

If authentication is successful, the user is permitted to access the network; otherwise, access

is denied.

Remote Access PoliciesWindows 2000 RRAS has many enhanced security features compared with the earlier version

of Windows NT RAS. One of the most important features in RRAS is the addition of remote

access policies. In Windows NT, user authorization was based on a simple Grant Dial-In Per-

mission to User option. Callback options were also managed on a per-user basis. In Windows

2000, user authorization is granted or denied based on the dial-in properties of a user account

and the remote access policies as designated by the administrator. Remote access policies

establish the following: whether a server accepts a request for remote access, who is allowed

(or not) to connect via remote access, the properties of the connection, which protocols are



used, and the types of authentication that are required. (Note that if no policies exist, all

remote access connection attempts to the RRAS server are denied.)

Remote access policies, whether implemented as local policies or as part of Group Policy,

can enforce the use of the authentication and encryption methods that are selected. There can

be multiple remote access policies per server. As a result, different policies can apply to dif-

ferent groups of users. The Windows 2000 RRAS service uses remote access policies to

determine whether to accept or to reject connection attempts. Authorization is based on the

evaluation of policy conditions, user permissions, and the user profile. Policy conditions are

the basic parameters that must be met in order for a connection to the server to be allowed.

It is important to note that policy conditions are evaluated according to their order in the list

of policies. For example, if a user doesn’t meet the conditions in policy one, then policy two

will be evaluated, the same for the third, fourth, and so on. However, as soon as the user

meets the conditions of a policy, that policy is the last policy that is evaluated. Therefore, in

this example, if there are ten policies and the user meets the policy conditions in policy five,

the remaining policies are evaluated. If a user does not meet the conditions of any policy,

access is denied.

After the policy conditions have been successfully evaluated and met, user account permis-

sions are evaluated. These permissions relate to the dial-in settings that can be configured for

a user account. Three permissions can be set: Allow Access, Deny Access, and Control Access

Through Remote Access Policy. The Grant Remote Access permission option and the Deny

Remote Access permission option simply grant or deny remote access to the system. The

Control Access Through Remote Access Policy option instructs the policy’s remote access

permission to override the user’s remote access permission overrides.

If a user’s permissions allow access, the final level of evaluation involves the use of profile

settings. A remote access policy profile is a set of properties that are applied to a connection

after the connection is authorized.

Internet Authentication Service and RADIUS

Windows 2000 Internet Authentication Service (IAS) is the Microsoft implementation of the

Remote Authentication Dial-In User Service (RADIUS) server. IAS implements the Internet

Engineering Task Force (IETF) standard RADIUS protocol, which enables use of a homoge-

neous or heterogeneous network of dialup or VPN equipment. RADIUS and IAS together

perform centralized connection authentication, authorization, and accounting (AAA) services

for dialup, VPN remote access, and router-to-router connections. It can also be used in con-

junction with Windows 2000 RRAS to control in a more centralized manner authentication of

users, accounting of their connection start and stop times, and authorization through the use

of remote access policies.



In large corporate networks, managing remote users’ access can be challenging. IAS offers

many features that allow corporations to manage all remote access from a single point of

administration. IAS features include:

■ Centralized user authentication—When authenticating a user, IAS actually verifies

the credentials of the client computer that is initiating the connection against an authen-

tication authority. The authentication authority is a domain controller. Authentication

can take place from any domain that is accessible to Windows 2000. This includes Win-

dows NT 4.0, Windows 2000 mixed mode and native-mode domains, in addition to as

many domains that are accessible through trust relationships.

The credentials of the client computer are sent to the domain controller using a Point-

to-Point Protocol (PPP). PPP is a set of standard authentication protocols that allow

remote access software from different vendors to interoperate. Authentication protocols

are used to determine what level of security validation the remote access server can per-

form, in addition to what is required by the server. The PPP authentication protocols

range in the level of security provided. In addition to the PPP authentication protocols,

IAS allows you to plug in arbitrary authentication methods to meet your authentication

requirements.

■ Centralized authorization—IAS determines authorization for a connection request

based on the user account properties and connection parameters. It verifies that the user

has the correct rights or permissions using the dial-in properties of a user account and

remote access policies.

A remote access policy is a set of conditions that provides flexibility in controlling who

is allowed to connect to a network. As discussed earlier in this appendix, by default,

remote access policies are stored on the server on which they are created. IAS provides

the ability to centralize the distribution of remote access policies. For example, when a

remote access server is set up as a RADIUS client, all remote access policies on the

server are ignored, and the policies configured on the IAS server are used instead. For

Windows 2000 IAS servers, remote access policies are administered from either the

RRAS administrator tool (when configured for Windows authentication) or the IAS

administrative tool.

■ Accounting services—IAS supports RADIUS accounting, which allows IAS to collect

accounting records sent by the NAS at a single point. Accounting services can be used

to track network usage for auditing and billing purposes. For example, IAS can log

information such as logon and logoff records or authentication success and rejects

records. RADIUS accounting provides a real-time collection of data that can later be

analyzed by other products to provide charge-back, performance, and exception

reports.



In addition to these features, IAS provides a graphical user interface (GUI) that can be used to

configure local and remote servers. IAS is scalable; therefore, it can be used in a variety of

network configurations of varying size.

Internet Protocol Security

Internet Protocol Security (IPSec) is an architecture that consists of a suite of protocol stan-

dards designed for data protection of network traffic. IPSec provides cryptographic security

services between two computers over an insecure network. These services allow for authenti-

cation, integrity, access control, and confidentiality. The encryption is applied at the IP net-

work layer and is transparent to most applications. Transparency is possible because

applications do not need to have knowledge of IPSec to be able to use it. Also, because these

services operate at the IP layer, any higher-layer protocols such as TCP and UDP can use

them. (Note that Microsoft and Cisco Systems, Inc. jointly developed the design and integra-

tion of IPSec services and support in Windows 2000. The agreement was made to integrate

Cisco’s ISAKMP/IKE with the IPSec kernel driver of Microsoft, and it also involved devel-

oping IPSec policy for use with Active Directory.)

IPSec consists of two separate protocols:

■ Authentication Header (AH)—Provides authentication, integrity, and antireplay.

However, AH does not encrypt data. As a result, it is used when only the connection

needs to be secure, not the data.

■ Encapsulated Security Payload (ESP)—In contrast to AH, ESP provides authentica-

tion, integrity, antireplay, and data encryption. It is used to protect both the connection

and the data. Because of its data encrypting capabilities, greater system overhead is

associated with ESP.

IPSec consists of three main components, which, in conjunction with other Windows compo-

nents such as the TCP/IP driver and cryptoAPI, provide for seamless IPSec functionality in

Windows 2000:

■ Policy Agent—A service that is loaded at system startup to retrieve an IPSec policy

from the appropriate policy store (either Active Directory or the local registry). After

the IPSec policy is obtained, the appropriate components are distributed to either the

IKE module or the IPSec driver.

■ Internet Key Exchange (IKE) module—A module that is started by the Policy Agent

service. Its function is to negotiate security associations (SAs) for both the ISAKMP

(Phase I) and IPSec (Phase II). Negotiations are based on the authentication and secu-

rity settings the module receives from the Policy Agent.


Summary 839

The SA is the negotiated set of protocols and parameters that the two computers will

use to communicate. After the computers have established a secure communications

channel, each uses its own SA to manage the channel. Computers do not share an SA.

■ IPSec driver—A driver that is responsible for exercising filters and maintaining the

stateful status of connections. It receives the active IP filter list from the IPSec Policy

Agent and then matches every inbound and outbound packet against filters in the list.

The IPSec driver uses the defined filters to determine which packets get permitted,

blocked, or secured.

Here’s an example of how the three components of IPSec work. When IPSec is implemented

on a Windows computer, the user must first create an IP security policy. The policy contains

security rules that determine how traffic is protected. A single policy contains many rules,

which contain many IP filters. Only a single policy can be activated on a computer at any

given time.

Computer A initiates communications with Computer B. Each computer first goes through

Phase I, also called IKE SA. IKA SA is the process of each computer authenticating with the

other and proving their identities using ISAKMP/IKE. The next process, Phase II, is where

IKE begins negotiation of the security protocols that will be used to set up the secure commu-

nications channel between the two computers. For example, Computer A might offer ESP and

AH as the two protocols that it will accept. Computer B might be configured to use only the

ESP protocol; therefore, it responds with only that option. At that point, an agreement is

made to use ESP, and IKE sets up the secure channel and passes the SA off to the IPSec

driver for processing.

SummaryBoth Linux-based and Windows-based operating systems have security issues that need to be

addressed. Security of network services—such as FTP, mail, and web servers—is a common

need for both operating systems. The securing of user access and file systems is another com-

mon area of concern. Each of these operating systems has infrastructure services that run

across the network.

Although these operating systems have many similar components, the implementation of

these features, and the measures that need to be taken to ensure their security, are different for

each. An administrator must have a thorough understanding of the functions of the operating

system in use to be able to design and implement a valid security policy.


1226.book page 780 monday, december 22, 2003...

Documents