Microsoft Distributed File System (DFS) continue...

Creating a DFS Root

Creating a DFS tree is not a complicated task when using a graphical interface such as the one provided by the MMC and by the wizards that walk you through setting up your file system. To create a new DFS root, use the following steps:

1. Click Start, Programs (All Programs for Windows Server 2003), Administrative Tools, Distributed File System.
2. When the management console appears, select New Root from the Action menu. A wizard pops up. Click Next.
3. You can select to create a file system that makes use of the Active Directory for storing the DFS configuration information. You can also select to not use the Active Directory. For the purposes of this example, I've chosen to not use the Active Directory. After making the selection, click Next.
4. The next dialog box prompts you to enter the name of the server that will host the distributed file system. The default is usually the server on which you are running the wizard. Use the default or enter another server. Click Next to continue.
5. The wizard next prompts you to enter the name of the new root DFS file system. Note that what you enter here shows up in the field Share to Be Used at the bottom of the dialog box. You can use the name of an existing share in the Root Name field, or create the share to be used after you complete this wizard.

6. If you entered a share that does not yet exist, you can now choose the folder to share by entering it in the field or by using the Browse button.

7. Finally, the wizard displays a summary of the information you have entered. Click the Finish button to complete the process of creating the new DFS root.

Adding Links to the DFS Root

After you've created the initial root for your file system, you can add one or more links. Links, as yo will recall, are actual directories (or folders, depending on which terminology you prefer) that will be accessible from your DFS root.

DFS is a domain-wide file system. You can easily browse a file share located on another server in the domain. Thus, you can hide the physical location of files from users. Instead of having to remember servers and share names, the user only has to remember the share name. Because the share name is domain-wide, you can't use the same share name on one server that you do on another. Users can then simply connect to the share \ \domainname\share. They don't need to know the server names on which the actual folders in this share are located.

You can use the Action menu to add or delete a DFS root. You can also use the Action menu to manage links and replication.

DFS does not add any additional security features to the file system. Instead, the usual rights and permissions that are already in place on the server are used when evaluating a client's access to a file or directory in the DFS tree.

One major difference between NFS and DFS is that DFS is built using SMB messaging techniques for the most part and is not compatible with all NFS servers. If you have a mixed-environment network in which most of your data files are offered via NFS on Unix servers, it would be more economical to acquire PC-based NFS client software than it would be to replace all your existing servers with NT DFS servers.

Using a Shadow Password File of Unix and Linux

To plug the password security hole presented by the / etc / passwd file, a technique called a shadow password file is usually used. This file contains the actual passwords, also in encrypted format. However, the shadow password file is not world-readable, and permissions are set so that only the root account can access this file.

On many systems, the name of the shadow password file is /etc/shadow. Check your documentation to determine the exact path on your system. Also note that on some older systems (and a few current ones), you'll have to load an extra component to install the shadow password file capabilities. Keep up-to-date by consulting your vendor's Web site.

The contents of this file also can vary from one system to another. However, the following format contains the fields used in most implementations:

username:password:last:may:must:warn:expire:disable:reserved

The following list describes these fields:

• username—This field is used for the same purpose as it is in the /etc/ pa s swd file. It is the login name for this user's account.

• password—The user account password stored in encrypted format.

• last—The number of days, since January 1, 1970, that the password for this account was changed.

• may—The number of days that must pass before the password for this account can be changed.

• must—The number of days after which the password for this account must be changed.

• warn—The number of days before the password expires to warn the user about the upcoming password expiration.

• expire—The number of days that must pass before the account password expires and the account becomes disabled.

• disable—The number of days, since January 1, 1970, that the account has been disabled.

• reserved—This field is reserved for future use.

As you can see, using a shadow password file gives you additional control over accounts, such as setting password expiration values. It also gives you informational fields (such as last and disable that can be used when managing user accounts.

The /etc/groups File

This file contains a list of user groups and a numerical value used to identify the group. The syntax for entries in this file is as follows:

groupname:grouppassword:groupID:username1,username2

• groupname—A name associated with the group. Using a meaningful name can help you simplify user administration.

• grouppassword—Yes, you can place a password on a group, but this is generally not done. Instead, this field is usually left blank.

• groupID—This is the group's ID number, which is used by the operating system to identify the group. It is often referred to as the GID. This number can range from 0 to 32,767, and the numbers 0 to 10 are generally reserved for system groups. For example, in most Unix implementations, the root user has a GID of zero.

• usernamel,username2 . . . —This is a comma-delimited list of members of the group. Separate each using a comma.

Users can be members of more than one group. If this is the case, the first group is the user's primary group, and the GID of this group is used when files are created or saved. Users can use the groups command to view the group(s) of which they are a member. The command chgrp can be used to change the current default group.

Printing Protocols and Printing Languages

A printer language is not the same as a printer protocol. For example, PostScript and PCL (Printer Control Language) are languages that describe how a document is to be rendered into the final printed product by the printer. When a printer is directly connected to a printer port on a computer, the printer language is important and is used by the software driver to format the information being sent to the printer.

A printer protocol, however, is used to send the formatted job, both data and instructions compiled using the printer language, to the print device. A few protocols will be detailed here that are more specific in their use and implementation; that is, they generally are used for communicating with a printer.

Several protocols are used for network printing. Some are proprietary protocols used by only one computer or network operating system (NOS). Others, such as 1pr/lpd—which was first developed for use on Unix systems—have been implemented in many environments. Data Link Control (DLC) is an IBM protocol that has been adapted for use on many printers although it is not used much today.

Also covered is the newest printing protocol: the Internet Printing Protocol (IPP), which was created by a working committee of the Internet Engineering Task Force (IETF). Development is underway for standards to further define this new protocol. You will find, however, that both Windows 2000/2003/XP and NetWare 6.x already support IPP. Novell even sells its iPrint as a separate product that can be used in a non-NetWare environment.

Using Ipr/lpd and the TCP Stream Protocols

TCP/IP was originally developed for the Unix operating system (OS), of which there are several flavors. Depending on the version of Unix (as well as Linux) running on a workstation or server, you will find that TCP/IP printing falls into one of two major types:

• BSD (Berkeley System Distribution) Spooling System
• SVR4 (System V, Release 4) Printing System

The BSD system uses the 1pr (line printer remote) program to send files to printers. The printers can be connected to a network, or to a computer. Whichever way, the 1pd (line printer daemon) receives these print requests and interacts with the Ipr to send the print job to the printer. The / et c/ p r int cap text file is used to set up characteristics for each printer. The SVR4 Unix system uses the 1p (line printer) program and the 1psched daemon (printer scheduler) to print files. Although the SVR4 system is considered more sophisticated because it has several utility commands for managing the system, the BSD system probably is easier to manage in a networked environment.

When using either of these methods, the actual print commands and data are sent to the printer in the payload section of a TCP/IP packet.

Although all Unix and Linux systems support TCP/IP printing, many support other protocols as well. For example, Red Hat Linux can also be configured to use SMB (Server Message Block) to connect to a Windows server (or a Unix/Linux computer configured to offer printing services using SMB).

The 1pr/lpd protocols work well, but are mostly used by older operating systems.

TCP/IP stream sockets the Unix provide yet another way to use TCP/IP to connect to a printer. Streams are a two-way communication TCP/IP session between the computer (or print server). When using TCP/IP streams, you need to specify a port (also known as a socket in Windows terminology). Thus the address of the networked printer, paired with a port number, provides a unique address so that the data exchange can be accomplished.

Data Link Control Protocol (DLC)

For all practical purposes, DLC is rarely found anymore within today's networks, although it might still be found on legacy systems. This IBM protocol was widely used during the early days of networked printing, as well as for other applications. However, more robust protocols, such as TCP/IP, have made this protocol a less desirable solution for network printing.

The DLC protocol was developed by IBM primarily for use in connecting to mainframe computers as part of its Systems Network Architecture (SNA) specifications. DLC can also be used to establish terminal sessions with AS/400 computers. In addition to the HP Jet Direct card, you will find that other vendors also make network cards for printers that can use DLC. For example, the Brother NC-600X and NC-2010h network cards both can be used for this purpose. However, you'll find that DLC no longer is present in Windows systems starting with Windows) XP.

System Daemons and Services continue…

Delegating Authority

In a network of any size other than a simple workgroup, it is usually necessary to delegate authority to other administrators or middle-level management personnel. When you find that you must create accounts that have privileges to perform administrative functions, do not give carte blanche access to every account. Keep track of the exact functions an account will be used for, and grant only the access rights and permissions needed.

For example, if an operator will be performing backup functions on a server, he does not need to have full rights and privileges on the server. Under Windows Servers, you can place the user's account into the Backup Operators user group to give him the capabilities he needs, without compromising all files on the system. If you have users who must be able to add or modify user accounts, check the operating-system documentation and give the users access only to the resources and data files they need.

User Accounts

Generic accounts might seem like a good idea at first thought, but they provide nothing in the way auditing. If you simply let one or more users share the root account on a Unix system, or the Administrator account on a Windows server, you will have no way of determining tracking, and resolving who did what when something goes wrong. Indeed, because you can grant the same capabilities to any new account you can create, why not do so?

Give each user who requires elevated capabilities her own account, and grant the necessary privileges to the account. This way you can track each user to be sure she does not abuse her account or use it in a way you do not expect.

When you have more than one user using the same account, there is also the likelihood that the password will be compromised and someone who is not authorized to use the account will do so.

Application Servers, Print Servers, and Web Servers

One particularly common error you can make is to put all your eggs in one basket. Instead of using one server to provide print services or file services or Web services, many administrators use one server to provide all three. This is not necessarily a good idea.

Specialized servers can limit the damage that can be done by intruders and also can make it easier to delegate authority so that a particular administrator can concentrate on a limited set of functions for a certain server. Web servers are particularly prone to attempts by hackers to intrude onto your network. New applications and technologies are being developed and deployed all the time, and the newer they are, the more likely it is that they will have bugs or other loopholes that make them more risky than other applications that run on the network.

Placing sensitive data files on a Web server simply because it is convenient to use the machine's resources is not a good idea if it is also being used as a Web server. Make it more difficult to get at these files by dedicating a file server computer to them instead.

Delegating servers is almost like delegating authority to users. When you divide up resources and partition them into manageable groups, you make it less likely that an attack on one object will result in damage to all objects.

Denial of Service (DoS) attacks are very common on networks now. This kind of attack can be done by a malicious person who takes advantage of a known weakness in a protocol or an implementation of a particular service. One common mistake that administrators make when setting up an FTP site is to place it on an ordinary server.

For example, you might want to have an FTP server that allows customers to log in to your system and download information, patches, or other files. You also might want to be able to let them upload files or messages to your site. If you are going to allow anonymous FTP access, be absolutely sure that the service is configured so that it can access only a dedicated disk or set of disks. Do not allowanonymous access to an FTP service that writes to a system disk or a data disk that is important in your network. It is quite easy for an outsider to simply fill up the disk with meaningless data, causing a system to lock up or crash, depending on the operating system. If an important data disk becomes full, it can cause an extended period of downtime, putting employees out of work for hours while yo try to first determine the cause and then remedy it!

System Daemons and Services

Windows servers have background processes that perform many functions, called services. Unix systems also have background processes that work in a similar manner that are called daemons. Regardless of what you call them, these processes, which are called background because they do not require interaction with the keyboard but instead execute on the computer waiting to perform some function, can introduce security problems when they are not needed.

You should become familiar with the background processes on any servers in your network and disable those that are not needed. For example, on Unix systems, there are many background daemons associated with the TCP/IP suite of protocols. Some systems might need all of these, whereas some might need just a few or none of them. It might be that you do need these services. It might be that they need to be configured properly prevent their misuse. You should read the dumentation that comes with your Unix or Linux system to determine the capabilities that these daemons provide and disable them on systems that do no need them.

For example, tftp (the trivial ftp transport application) is a stripped-down version of FTP. It is com and usually can be easily implemented in an EPROM. For this reason, it is useful in some devices need to download operating software from a host. However, note that unlike FTP, tftp has no acc control mechanisms. This means that a username and password are not used. Because there is no authentication, this can be a real security problem if it is not configured properly, such that it can used only for its intended purpose.

On Windows servers, you can use two programs that are provided with the Resource Kits to install or run almost any executable program or batch file as a service. These are INSTRV.EXE, which can be used to install an executable, and SRVANY.EXE, which can be used to make other kinds of files into services. On a server that has several users logging in frequently, you might want to make it a regular part of your routine maintenance to review the services running on the machines and disable or remove those that are not installed by the initial operating-system installation or those that did not come from products you have applied to the system.

To do this, you will need to keep an inventory of what runs on each server, but this kind of inventory information can be useful for other purposes, such as when you need to reinstall a server that has been destroyed by a catastrophic failure.

Removing Dead Wood

Every operating system comes with default options installed that you might not be aware of unless you have read the documentation carefully. For example, default user accounts might be created

when you install the OS or later install a product. For example, the GUEST account in Windows operating systems is installed by default. You should always disable or remove this account. The Administrator account is also a vulnerable target because it is present on all Windows Server computers from Windows NT through Server 2003. You cannot delete this account, but you can rename it so that the hacker's job becomes more difficult. Also, you shouldn't use the Administrator account on a regular basis. Instead, create individual administrative user accounts for each system administrator trusted to perform these high-level tasks. Then put them into the Domain Admins group to allow these users to exercise administrator privileges, while maintaining an audit trail of the actual users who performed certain actions. You should always use separate administrative accounts for your domain administrators. Never use the same account for domain administration as is used for regular user functions. Administrators should be logged in with administrative accounts only when performing activities that require elevated permissions. You can also use group policies to further restrict what each user can do.

Regularly review the user accounts that exist on the network. Use the auditing features provided to determine when an account has not been in use for a long period, and if you can find no reason for its existence, disable it. Maybe someone in another department did not notify you when a user was terminated, or maybe an account was created for an expected new employee or contractor who later changed his mind and did not come on board. New accounts such as these are typically created with a simple password and can leave gaping security holes in your network.

Old programs and files that are no longer needed, or the use for which you are not sure, are also easy targets to cause security problems. As a rule of thumb, if it's not needed, back it up to tape and delete it! If a user finds that something she needs is missing, she will tell you!

When installing a new application product for a user, be sure you know the capabilities of the application. Don't install unneeded optional features that will not normally be used. Read the documentation!

Physical Security Measures continue...

Novell NetWare provides this functionality by giving the user a logon to the network that is controlled by the Novell Directory Services. Each user is represented in the directory by a User object, the properties of which specify information about passwords and connections.

The Unix operating system does not use the concept of a domain. Instead, each Unix host maintain a password file that stores information about each user, including an encrypted password. To access resources on other network hosts, the Unix user must either log on when accessing the computer or use a proxy mechanism. TCP/IP utilities such as FTP and Telnet often send user passwords across the network in clear-text format and are easy targets for interception.

The Unix remote utilities, usually called r-commands because they all start with the letter r, are use to perform ordinary network functions such as copying or printing files or logging in to a remote s tern. This is very useful in the network environment in which a user performs functions on many( ferent machines. These utilities are not necessarily good when looked at from a security standpoint however. Although the user must have a valid user account on the remote hosts on which these co mands execute, the user does not have to provide the password.

Instead, an entry in the /etc/hosts .equv file or the. rhosts file on a remote computer is what deter mines access. The remote machine trusts the computer on which the user executes an r-command if can find an entry in either of these files for it. Each entry in the /etc/hosts . equiv file contains a hostname and a username, to identify users and the hosts that are allowed to execute these commands without providing a password. The assumption is that if you have logged in to the remote host, you have already been authenticated. The . rhosts file works in a similar manner but resides in user's home directory. The remote users entered in this file can perform functions based on the account associated with that user.

Although this sounds a lot like the Windows NT/2000/Server 2003/XP trust mechanism, it is not. It is quite easy to impersonate a remote node and gain entry into a Unix/Linux system by using the r-commands.

Resource Protections

After a user has been authenticated by the erating system, the next step to access a resource is for check to be done to see whether the resource has any access controls placed on it. Typically, an open rating system will grant access to a resource, such as a file, by granting users the right to do the folioing:

• lRead the file

• Write to the file

• Execute the file

• Take ownership of the file

• Delete the file

These concepts also can be extended to resources such as printers and modems. When granting these rights, most operating systems also enable you to specify which rights are applied to users or groups of users. For example, Windows NT enables you to group users into local or global groups. When you set the access controls on a file, you can specify the access rights by group. Using this method, one group of ordinary users might be able to read a file, while a group of users that manages the filemight be granted read and write access, as well as delete access to the file. To prevent programs from being run by unauthorized users, the execute right can be granted or denied to a user or a group of users.

It is important to understand the features of your operating system that pertain to granting rights or permissions. Rights generally enable a user to perform an action. Permissions are placed on resources and define who can access and what kind of access can be made of a resource.

After the Fact: Auditing Use

As you may be aware, there are auditing tools you can use to keep track of resource use, both attempted and successful logon attempts. Here it is important only to note that it is not enough to organize users into groups and grant them resource permissions throughout the network. A large user base, combined with multiple servers that hold valuable resources, makes it difficult at times for an administrator who is not familiar with the information resources provided by a specific server to understand the permissions needed. For example, a new user in the accounting department might or might not need access to accounts receivable files or accounts payable files. They might need access to one or the other or maybe both files. A manager in thatdepartment would probably be the likely person to make the decision about what files the usershould be able to access.

However, if the user is placed into a group, which is generally done to make administration easier,, compromises sometimes happen, and the user might be granted access through the group to resources that they do not need to access. Another reason is that sometimes mistakes are made. It is a fact of life that no one is perfect and that no system for allocating resources is going to get it right 100% of the time. When users are granted the capability to read a file, you can be sure, if the data contained in it is interesting enough, that they will do so.

Indeed, even if a user does not have appropriate access rights to a file, sometimes the user will try to get at interesting information anyway.

For these reasons, a good operating system provides auditing controls that enable you to look back after a security breach to try to determine who did what and where they did it. Unix (and its variants, such as Linux), Windows NT/2000/Server 2003, and Novell all provide features that enable you to record both successful and failed attempts to access resources. They all do it in different ways, and many of these auditing and security features are not enabled out-of-the-box; so if you have multiple operating systems on the network, it will be important that you understand each of them so that you can best enable and use these capabilities.