Hp NETSTORAGE 6000 File Sharing Security

File Sharing Security
on the
hp surestore
netstorage 6000
White Paper
Copyright © 2000 Hewlett-Packard Company Page 1 of 28 All Rights Reserved
1 Introduction__________________________________________________ 4 2 Security on UNIX Networks ______________________________________ 4
2.1 General Overview ___________________________________________ 4
2.2 Restricting User Access ________________________________________ 5
2.3 Restricting Host Access ________________________________________ 6
2.4 Considerations for the HP NetStorage 6000 _________________________ 6
2.4.1 Trusted Hosts __________________________________________________________6
2.4.2 The /etc Directory ______________________________________________________7
2.4.3 The /etc/approve File ___________________________________________________7
3 Security on Windows Networks ___________________________________ 8
3.1 General Overview ___________________________________________ 8
3.2 Share Level Security __________________________________________ 9
3.3 User Level Security ___________________________________________ 9
3.3.1 NT Domains __________________________________________________________ 10
3.3.2 User Authentication _____________________________________________________ 12
3.3.3 Password Maintenance and Encryption _____________________________________ 13
3.3.4 Security Descriptors_____________________________________________________ 14
3.4 Considerations for the HP NetStorage 6000 ________________________ 16
3.4.1 Share Level Security ____________________________________________________ 16
3.4.2 User Level Security _____________________________________________________ 16
3.4.3 DOS attributes ________________________________________________________ 17
4 Security on Mixed (UNIX/Windows) Networks_______________________ 17
4.1 General Overview __________________________________________ 17
5 File Sharing Configuration ______________________________________ 18
5.1 File Volume Permissions _______________________________________ 18
5.2 Mapping Strategies _________________________________________ 19
5.2.1 User Mapping_________________________________________________________ 20
5.2.2 Group Mapping_______________________________________________________ 20
6 Mapping Clients _____________________________________________ 20
6.1 Mapping Files _____________________________________________ 21
6.2 Establishing a Windows Client__________________________________ 22
6.3 Establishing a UNIX Client_____________________________________ 24
Copyright © 2000 Hewlett-Packard Company Page 2 of 28 All Rights Reserved
7 Examples___________________________________________________ 24
7.1 Client with both UNIX and Windows Account________________________ 24
7.2 UNIX File Accessed by Windows Clients ___________________________ 25
7.3 Windows File Accessed by UNIX Clients ___________________________ 26
8 File Format Details ____________________________________________ 27
8.1 HP NetStorage 6000 Files - passwd, group, users.map, group.map_________ 27
8.2 UNIX Files - passwd.nis and group.nis _____________________________ 28
9 Acronyms __________________________________________________ 28
Copyright © 2000 Hewlett-Packard Company Page 3 of 28 All Rights Reserved
1 Introduction
One of the most important aspects of serving data to clients over a network is the security mechanisms employed by the server to protect the data from accidental or malicious tampering. The HP NetStorage 6000 is a (NAS) Network Attached Storage Device with capabilities to serve files to Windows clients and UNIX/Linux clients using the native file serving protocol of each client. The HP NetStorage 6000 server has extensive security features built-in that leverage or extend the security mechanisms detailed in the specifications of each of these file serving protocols. In addition, the HP NetStorage 6000 is capable of mapping the security features of one protocol to the other. This feature allows files to be safely accessed through both protocols.
On a network of UNIX clients, the HP NetStorage 6000 provides a native interface to the files on the NAS device through the Network File System (NFS). The NFS protocol is the native file serving protocol of UNIX networks and integrates seamlessly with the established features of UNIX security and file locking. The HP NetStorage 6000 is capable of serving files via NFS to a variety of UNIX and Linux clients.
On a network of Windows clients, the HP NetStorage 6000 provides a native interface to the data on the server through the Common Internet File System (CIFS). This protocol is also commonly known as Server Message Block (SMB). The HP NetStorage 6000 offers a mature and robust implementation of the CIFS protocol, complete with the security mechanisms normally found on Windows servers. The HP NetStorage 6000 is capable of securing file access to Windows clients in a variety of ways, depending on the security requirements of the network.
The HP NetStorage 6000 is capable of serving the same files over either the NFS or CIFS protocol. File servers that can serve multiple protocols are commonly referred to as “Heterogeneous File Servers”. This capability adds a new dimension to the security issue in the nature of mapping the security parameters from one file system protocol to another. Although NFS and CIFS are both designed to serve files over a network, the methods by which they protect their data from unauthorized access are very different. The HP NetStorage 6000 addresses this issue by mapping the access information as needed, to determine the appropriate access to grant the user.
This document describes the general security aspects of the NFS and CIFS file serving protocols, including special considerations on how they are implemented on the HP NetStorage 6000. In addition, the security issues involved with offering files through both protocols on a server are covered in detail. Finally, the solutions implemented on the HP NetStorage 6000 to address the multi-protocol security problems are presented.
2 Security on UNIX Networks
2.1 General Overview
UNIX users gain access to remote resources on a network by mounting remote file systems (using the ‘mount’ command). Accessing remote file systems is accomplished over the network via the Network File System (NFS) protocol. Remote file systems attach themselves to the directory tree of the local file system at a specified location. The user interacts with the remote file system in the same way as the local file system.
There are two methods for restricting access to remote file systems on UNIX Networks. The first method involves restricting access to individual resources (files and directories) to specific users or groups of users on the network. The second method involves restricting resources to specific hosts (computers) or groups of hosts on the network.
Copyright © 2000 Hewlett-Packard Company Page 4 of 28 All Rights Reserved
2.2 Restricting User Access
All users on UNIX systems must perform a logon sequence before gaining access to the system. The logon involves entering an appropriate name and password at the logon prompt. Once the logon data is entered, the system searches the local passwd file for a matching entry. If a match is found, then the user is granted access, and is assigned two 16 bit numeric identifiers that are associated with the user. These identifiers are referred to as the UID (user ID), to specifically identify the user, and the GID (group ID) to specifically identify the group that the user belongs to.
The UID and GID of a user governs all access to files and directories available to the user, including remote file systems that the user mounts for access via the NFS protocol. All files and directories on UNIX style file systems contain a small amount of metadata that identify who has access rights to the file. This metadata that is associated with file security is defined as follows:
UID This is the identifier of the owner of the file
GID This is the identifier of the group owner of the file
Permission bits These bits identify the read, write and execute (rwx) privilege for the file’s owner, the
file’s group and anyone else who is not the owner or in the group (referred to as other).
For example, a typical UNIX file permission might appear as follows in a directory listing:
-rwxr-x--x 1 Wilson Engineering 611 Nov 11 11:09 testfile
In this case ‘Wilson’ is the UNIX account that the file belongs to. Even though the metadata of the file stores the UID of the owner, the Operating System was able to map the UID to the user name ‘Wilson’ in the passwd file for display. The file also belongs to the group ‘Engineering’. The first field in the entry displays the permission bits. In this case, the owner, ‘Wilson’, has read, write and execute (rwx) permissions. Users that belong to the group ‘Engineering’, have read and execute (r-x) permission. All other users have execute only (--x) permission.
When a user attempts to access a file, the file system first categorizes the user as either owner, group, or other, based on matching the file UID and GID to the users UID and GID. Once the user is categorized, then the permission bits of the category are examined to determine the allowed access.
An extension of this security system is the Network Information Services (NIS). The NIS service automatically distributes centrally maintained system files to all of the host systems on the network. This allows security files, such as the passwd file, to be maintained centrally. Using this service, users need not create and maintain a separate account on each host. In fact, security can be enhanced by preventing users from creating and managing local accounts on each host. NIS also prevents the same UID number being assigned to several different users, which could be problematic in network file storage.
One of the weaknesses of this security system is that individuals on other UNIX host systems, that have root access to their own system, can easily create local accounts that can have any UID they desire. Thus, unscrupulous users can impersonate other accounts when accessing remote resources. To address this security weakness, a second mechanism may be employed that restricts host access to remote resources.
Copyright © 2000 Hewlett-Packard Company Page 5 of 28 All Rights Reserved
2.3 Restricting Host Access
Since NFS servers do not distinguish between computers that are part of a secure network infrastructure (complete with NIS centralized administration), and computers that exist outside of the sphere of administrator control, a mechanism is needed to protect servers from unauthorized access. In typical UNIX installations, NFS mount points on servers are listed in the /etc/exports file. The mount points listed in the /etc/exports file may also contain restrictions on the clients that can mount the file system. This mechanism can be used to supply added protection to resources on NFS servers.
2.4 Considerations for the HP NetStorage 6000
The HP NetStorage 6000 utilizes an internal file system that is native to UNIX environments. As such, it has UNIX security mechanisms built-in, that may be leveraged when serving files over the NFS protocol. All resources stored on the file system contain the security metadata noted in the previous sections.
The HP NetStorage 6000 does not support the concept of the /etc/exports file for managing mount points. Instead, the NAS device automatically creates a single mount point at the root of all volumes created on the system. Since the NAS device is specifically designed to share files, the exporting of mount points has been automated.
The root directory of the mount points on the HP NetStorage 6000 are given special permissions to facilitate appropriate access to users. The owner and group of this directory are root (UID = 0, GID = 0), and the permissions are read, write, and execute to owner, group and other (rwxrwxrwx). One consequence of this setting is that all users can delete any file in the root of the mount point. Therefore, administrators are encouraged to avoid storing files in the root of the mount point.
The group assignment to files created in a file volume on UNIX can be performed in a variety of ways. On the HP NetStorage 6000, when a new file is created, the group assignment is inherited from the directory where the file is created. For example, if the group owner for directory /acct/usr is accountants (GID = 501), then all files created in that directory will be assigned a group owner of accountants (GID = 501).
2.4.1 Trusted Hosts
All UNIX clients that mount to file systems on the HP NetStorage 6000 use the UID and GID of their account, when accessing files. A special case is the root user (UID = 0). In UNIX, the root user is a Super User, with full access to all files and directories in the file system. Due to the extensive rights provided to the root user, and the extensive damage that can be done by a malicious root user, the HP NetStorage 6000 does not trust them by default. Clients that attach with root privilege are given access as user ‘nobody’ (UID = 60001), with no special rights or privileges.
The administrator can override this default behavior by declaring a particular client to be a Trusted Host. A root user mounting a HP NetStorage 6000 file system from a client that is a Trusted Host will be given root privilege (UID = 0) to the file system. This feature allows administration of the file system by a root user, while at the same time, protecting the file system from other root users that should not have privileged access to the HP NetStorage 6000 file systems.
Copyright © 2000 Hewlett-Packard Company Page 6 of 28 All Rights Reserved
The administrator may declare Trusted Hosts using the web based administration tool, or the telnet administration tool of the HP NetStorage 6000.
2.4.2 The /etc Directory
It is necessary to maintain a number of system files on the HP NetStorage 6000 in an accessible place for administrative purposes. Some of the more common files found in this directory are as follows:
hosts Host name resolution group Define local group accounts passwd Define local user accounts hostgrps Define groups of host computers approve Restrict host access
These files are all stored in the /etc directory on the first volume created on the system. The files in the /etc directory are for system management purposes and cannot be deleted. If the volume that stores the /etc directory is ever deleted, then the system moves the contents of this directory to another available volume.
Of the files listed above, the hosts file, the group file and the passwd file may be edited through the web based user interface, or the telnet interface of the HP NetStorage 6000. In some cases, it is necessary to edit these files directly using a text editor. By default, all files in the /etc directory belong to the root user, and may only be edited by the root user. Therefore, the only way to edit these files directly (using a text editor) is to mount the file system as the root user from a Trusted Host (discussed in the previous section).
Important Note: The HP NetStorage 6000 does NOT authenticate UNIX accounts and thus does not use the passwd file, the group file, or the equivalent security files from NIS for authentication or account name resolution. The only reason to store and maintain these files is to map UNIX users to NT users. If the NAS device is not used for NT access, or if the storage for NT users and the storage for UNIX users are kept separate, then there is no need to maintain these files.
2.4.3 The /etc/approve File
Since the HP NetStorage 6000 does not support the /etc/exports file, support has been added for a file named /etc/approve. This file can be used to restrict NFS access to particular clients on the network.
Currently, the administrator has a limited ability to indirectly edit the /etc/approve file using the web based administration tool. Each volume on the server allows general UNIX access settings of No Access, Read Only or Read/Write. These settings apply to all clients accessing any resource on the volume.
In order to restrict individual clients and groups of clients to specific resources on the HP NetStorage 6000, the /etc/approve file must be edited manually. Entries in the /etc/approve file have four fields. These fields are defined as follows:
class This field specifies the class of object to protect. In all cases, the object is ‘files’.
specifier This field specifies the resources on the HP NetStorage 6000 to protect. For example,
‘/engineering’, applies to all files and directories in the /engineering file system.
Copyright © 2000 Hewlett-Packard Company Page 7 of 28 All Rights Reserved
host pattern This field has the name of a host or group of hosts that have access rights. Host names must be
resolvable through the local /etc/hosts file, the NIS hosts file, or through DNS. Groups of hosts are specified in the /etc/hostgrps file. If the host pattern is the name of a group, then it must be preceded by the @ symbol. The wildcard character ( * ) may be used to specify all hosts.
rights This field specifies the access limits to apply. The entry in this field can be one of the following:
access=rw Allow read and write access to the resources access=ro Allow read only access to the resources access=none Deny all access to the resource
Following is a list of example entries in the /etc/approve file:
#class specifier host pattern rights files /acct/usr @executive access=rw files /acct/etc it1 access=rw files /acct/etc it2 access=rw files / @untrusted access=none files /acct/usr/theList.txt guest access=ro
The first entry allows read/write access to all client systems defined in the ‘executive’ group (listed in the /etc/hostgrps file) to all files and directories under the /acct/usr directory. The second and third entry allows read/write access to the machines ‘it1’ and ‘it2’ to all files and directories in the /acct/etc directory. The fourth entry denies all access on all file systems to any machine in the ‘untrusted’ group. The last entry grants specific read only access to a single file for any user on the ‘guest’ machine.
Note that the file is searched sequentially for a match. Once an entry is found that matches the host and the resource to restrict, then all other entries are ignored.
3 Security on Windows Networks
3.1 General Overview
Two distinct mechanisms are used on Windows networks to provide security for resources. They are known as “Share Level Security” and “User Level Security”.
The simplest and least secure mechanism is known as Share Level Security. This security mode allows each network share to be protected with a password. Although the mechanism is very limited, it is useful on small networks that utilize peer-to-peer networking. Share Level Security is the default security mode of Windows for Workgroups, Windows 95 and Windows 98.
User Level Security is more complex to implement, but is easier for the end user, and more flexible in terms of what can be protected and how. In this mode, each user is provided a logon account, and must be authenticated on that account before gaining access to resources on a computer. This security mode is most appropriate in client-server based networks. User Level Security is the default security mode of Windows NT and Windows 2000.
Copyright © 2000 Hewlett-Packard Company Page 8 of 28 All Rights Reserved
The following sections explain these security modes in more detail.
3.2 Share Level Security
Share Level security is the simplest SMB security mode to use, but offers the least security. In this mode, each share may be protected by a password. When the server administrator defines a new share, a password is specified to protect the share from unauthorized access. When a user first accesses the share, the user is prompted for the password. Once the password is entered and verified, then the user has full access to all files on the share. Share Level security is the default security mode for Windows for Workgroups and Windows 95.
Share Level security may be implemented to allow both Read/Write access, as well as Read Only access to shares. Each share may be protected by one Read/Write password and one Read Only password. The access allowed on the share (Read/Write or Read Only) is dictated by the password entered by the user.
This mechanism is sufficient in small networking environments. However, in large environments, the model breaks down. If a different password is used to protect each share, and if many shares are defined on a network, then managing and remembering all those passwords becomes extremely difficult. In addition, the granularity of protection extends only to the share. Any user that has access to the share, has access to all of the files in the share. There is no way to limit access to individual files within a share.
In most cases, when a user enters a password to access a share, the client system creates a session with the server that may extend beyond the expected interval. For example, if a user accesses a share via Network Neighborhood (and providing the correct password), closes the Explorer window, and then returns to the share at a later time, the user may not be prompted again for the password, since the original session is still active. In addition, the client system may cache the password, and submit it again automatically on behalf of the user when a session is ended and a new one is activated with the same share. To summarize, users should not expect to have to enter in the password to a share more than once in a typical Windows session.
3.3 User Level Security
User Level Security offers the superior flexibility and ease of use on networks with a significant number of users and/or resources. In this mode, each user is provided a logon account to a computer or network. The user only has to remember the credentials for this one account, instead of numerous passwords for network shares. Resources can be protected with a much finer granularity. Not only can shares be protected, but directories and individual files may be protected as well. Also, each resource may be protected on a user by user basis that allows almost infinite permutations of access restrictions of users and groups of users. User Level Security is the default security mode of Windows NT systems.
The user accounts may be either local machine accounts for access to a single computer, or they may be accounts that apply to all computers attached to the network. If a computer is attached to a network, then local machine accounts are of little value, since the user of that account may only access resources on that computer, and not any other computer on the network. On the other hand, network wide accounts allow users to access resources on other computers on the network. In addition, these accounts allow the user to logon to any computer on the network.
On NT networks, the network wide user accounts are managed through NT domains. The architecture of NT domains is discussed in the next section.
Copyright © 2000 Hewlett-Packard Company Page 9 of 28 All Rights Reserved
Loading...
+ 19 hidden pages