This paper studies network file system's security requirements, and focuses on .... piece of information. In order to prevent this, digital signature is used. Digital.
Security Issues in Network File Systems Antonio Izquierdo, Jose María Sierra, Julio César Hernández, and Arturo Ribagorda Universidad Carlos III de Madrid Avda. de la Universidad 30, Leganés 28911, Madrid, Spain {aizquier, sierra, jcesar, arturo}@inf.uc3m.es
Abstract. This paper studies network file system's security requirements, and focuses on security performance constraints. We review security implementations in both, distributed file systems and pure network-based file systems, focusing on security services included in NFSv4's proposed standard. Finally, we evaluate the tools being used to preserve data confidentiality, integrity and availability in computer communications, in order to evaluate whether they would be suitable for their use in network file systems.
1 Introduction File systems, or file services, as they are also known, are mechanisms used by the operating system to provide data storage. They are an abstraction of the physical storage device in order to provide homogeneous access to the running applications. As file systems are the last layer of abstraction before physically accessing the storage devices, security is an important issue for these services, as they could provide full control over data to an attacker who had unlimited access to the file system. Over the last 25 years many security mechanisms have been proposed to ensure data privacy, integrity and confidentiality in computer file systems, but as computer internetworking has become more and more popular, and data sharing between computers has led to the development of special file systems known as network file systems, new security requirement have risen. These requirements have not always been satisfied, sometimes due to excessive performance penalty, sometimes due to lack of standards or tools that could be used for this emerging environment. In this paper we will analyze two different approaches of data sharing in a networking environment: a distributed file system, similar to a RAID file system [15] that expands over several network hosts, and a pure network file system, implemented as an application service over the local file system. Finally, we review the security mechanisms used to provide security requirements to establish whether they would be suitable to be used in network file systems.
2 Security in Network File Systems In this section we will study security mechanisms used in currently available approaches for sharing data over a network: distributed file systems and network file A. Laganà et al. (Eds.): ICCSA 2004, LNCS 3043, pp. 812–820, 2004. © Springer-Verlag Berlin Heidelberg 2004
Security Issues in Network File Systems
813
systems. We will study network file systems with an in-depth analysis of the most popular one: NFS. 2.1 Security in Distributed File Systems In this section we will analyze security mechanisms and requirements found in distributed file systems [2], [5] and [6]. Distributed file systems are another technology used to share storage of data among networked computers. They work at kernel level, just as a normal file system would do, but files are not stored in the local machine. Instead, files are split into several blocks, and those blocks are sent to remote storage servers in the network, as shown in Fig. 1. Distributed file systems operate as a networking RAID: there are several storage servers and each shared file is divided into blocks and spread among these servers. This kind of storage allows real parallel access to the same file (as long as clients are accessing different blocks)
Fig. 1. File being stored in a distributed file system. File is divided in blocks and each block is stored independently in one or more servers across the network. Operations are made at kernel level and after the division a “write” performed on a file has turned on several “write” performed on several blocks.
As distributed file system clients access the storage servers by passing system calls through the network without using other services, no security mechanisms are used. This means that communication encryption, authentication or integrity are not present (unless encryption is provided by other means). Traditionally, the reason for doing this has been due to performance restrictions, but attending to growing computing and network capabilities this statement should be reviewed.
814
A. Izquierdo et al.
2.2 NFS Basics Sun Microsystem’s Network File System was introduced in 1985, and was the first network file system being a commercial product. To encourage the adoption of this file system as a standard instead of one of the many academic and research file systems that had been developed, Sun placed the definitions of the key interfaces in the public domain, so other vendors could develop their own products, making NFS today’s de facto standard [1], [3] and [4]. NSF provides transparent access to remote files for client programs by creating a virtual file system that interacts with the real file system, so the client real file system sets as a subdirectory the data exported by the server file system, as shown in Fig. 2 [8], [9] and [10]
Fig. 2. NFS works as a service over the real file system, so it works with files instead of working with blocks, as distributed file system do. In the figure, the server (left) exports its “export” directory, and clients mount it in a directory of their choice. After mounting the share, both clients can work with files and directories stored in server’s shared file system.
2.3 NFS Security Considerations NFS has had several security flaws that have progressively led to redesign their authentication and access control method. Up to NFSv3 there were two flavors of NFS user authentication: no authentication or authentication against the local operating system, which led to the problem of UNIX UIDs and GIDs: as server’s file system’s metadata (including UID, GID and permissions for any given file) are exported along with data, each client will inherit that metadata information. This enforces clients and servers to share the same UID and GID mappings in order to provide seamless file service. Besides, NFS communications between server and clients are not encrypted and this could give potential attackers information about
Security Issues in Network File Systems
815
valid UIDs and GIDs in both servers and clients. Furthermore, as early NFS server implementations forced clients to send requests using a source port lower than 1024, information flowing around the network included credentials of root or administrator [11], [12] and [13]. By capturing this information an attacker could import the shared file system and perform data collection. In some cases, it could be possible for the attacker to log into the client system with administrator or root’s privileges. Furthermore, NFS uses machine-based authentication for importing a shared file system. This authentication is done by the RPC portmapper, which relies on the RPC services in order for authentication to work properly. This means that if a system has got permissions to import a file system from a server, any user in that system can import it, although he would be still restricted by file permissions. Additionally, as the RPC service does not use strong authentication machine’s credentials could easily be impersonated [11] and [12]. 2.4 NFSv4 Security Design In order to respond to those vulnerabilities, NFSv4 proposed standard [8], includes an important section dedicated to security, and addresses some of the problems mentioned in this document. One of the most important issues is the switch from machine-based authentication for importing the shared file system to principal-based authentication. Anyways, it is still possible to use machine-based authentication to provide backwards compatibility. The other important addition to the standard is the use of different authentication flavors, including no authentication, operating system, Diffie-Hellmann, Kerberos V4 or RPCSEC_GSS authentication [14]. The use of RPCSEC_GSS gives the possibility of addressing strong authentication at RPC layer, and its use is mandatory, while all the other ones are optional. RPCSEC_GSS provides an API that allows the use of multiple “security triples”. Security triples specify the authentication mechanism to be used, the quality of protection measured by the length of the key and the algorithm used, and the service that is protected by the triple. Examples of the authentication mechanisms supported by the proposed standard are Kerberos V5, LIPKEY or SPKM-3. Each one can operate using several different algorithms and key lengths, and the second field of the triple specifies which one should be used: the quality of protection. Examples of valid “qualities” for Kerberos V5 are MD5 or 56 bits DES. LIPKEY and SPKM-3 also provide the possibility of using the algorithm that has been negotiated to establish communication between both systems. Finally, the service being protected by the triple can be one or more of authentication, integrity and privacy. One example of valid triple would be using Kerberos V5 (the method) with 56-bit DES, MAC and MD5 for integrity and 56-bit DES for privacy. Some other security proposals are the mutual authentication between server and client and the use of strings as principal’s credentials to address the UID/GID problems. This would also permit using alternative authentication credentials that not rely on local representations of principals, such as LDAP-based strings, or X.509 certificates.
816
A. Izquierdo et al.
3 Applicability of Network Security Techniques in Network File Systems Next we will review the techniques used in computer communications to preserve information properties, and we will analyze their suitability for a network file system. We have to keep in mind that one of the most important requirements that we will face (and the reason why there have not been more secure implementation of these file systems) is speed: as we are working at file system level, operations must be performed and requests replied as fast as possible [5], [6] and [7]. 3.1 Confidentiality Confidentiality refers to limiting access to information to a set of authorized principals, as well as preventing access by unauthorized ones. As we can see, there are three steps that are needed to take in order to achieve information confidentiality: − First we have to assure the principal’s identity. − Then we must check if that principal may access the information. − Finally we must protect the information from unauthorized principals. The most popular mechanisms used to prove someone’s identity is through an authentication process. This authentication process has to be a suitable for a networked environment, similar to those used by remote services. An especially suitable model is a centralized model like Kerberos V5, where principal’s credentials are kept in a central repository. While this is a convenient model, it is not feasible to check against the repository in a operation-based basis, so it could be possible for the server to keep a cache of the most recently used credentials or the ones of the principals that are currently using the service. The mostly spread technique used for checking if a principal (that has been authenticated) may access a resource is the use of Access Control Lists (ACL). These lists may be real lists that take care of each possible combination of principal – resource – access method, and provide permissions (true/false, yes/no) for that kind of request. These lists quickly become too big, so Role Based Access Control (RBAC) is used instead [18]. Once we have assured the principal’s identity, and that we can tell if that principal can access the information that has requested, we must provide a mean of making the information unavailable for unauthorized users. Traditionally, cryptography has been the mechanism that has been used to protect stored information as well as information sent through the network. However, cryptographic operations have a high computational cost, so its use is usually limited to highly sensitive data. When talking about network and distributed file systems we have to consider who should encrypt the data: clients just before they send data over the network, or server as soon as they receive it. If data in encrypted by the clients, there would be no need to encrypt communications, as data being transmitted is already encrypted. It would also reduce the problem of performance and provide the file system with better scalability, as clients are the ones doing the hardest computational operations. In
Security Issues in Network File Systems
817
addition, this option would provide us with an encrypted file system, as files would be stored without being decrypted by the server. Conjunction of some or all of these tools could provide network file systems with confidentiality. Besides, it could be possible to establish several security levels, so the most computational-expensive operations only apply to files that really need it. 3.2 Integrity Integrity provides principals with means of detecting whether third parties have altered information being received, but it does not avoid the modification. Integrity has been used as a method for detecting communication errors as well as intrusion reports. Integrity in communications is being provided by means of cryptographic hash functions and digital signature. Cryptographic hash functions compute a fix-length value from the data being transmitted, so the receiver can compute again the value and check them for alterations. These hash functions have several properties that make them very good for this purpose: − A slightly change in the source data makes the computed value to change in about the 50% of the bits (avalanche effect) − These functions are very fast to compute, so they can be used in high load services without being a serious penalty. However, these values can be altered by an attacker, who would have to modify the data being transmitted, compute the new hash value and send them both as any other piece of information. In order to prevent this, digital signature is used. Digital signature is somehow associated with authentication and confidentiality, as the credentials used are usually the same, although with a different use. The process would involve calculating the hash value of the data and encrypting that value in a way that can be assured that the sender’s identity can be checked as shown in [2]. The problem that we have to face is the loss of performance associated with this process, as there are several cryptographic operations involved. In network file systems integrity is provided by the real file system that physically stores the files, and by communications cryptographic protocols (in case that we are using one of them and that it can provide integrity). The most important aspect about data integrity in distributed file systems is whether it should be done at block level or at file level. If we apply integrity at file level we are forced to read the whole file before we can perform any operation with it, so we lose the benefit of having the file split in several storage devices. On the other hand, we could apply integrity at block level, but in order to search for corrupted files in the file system we would have to check each file’s block against their integrity values, and then check if a given file has a corrupt block. In order to decide which one of those possibilities should we implement, data access method and purpose has to be identified, so we can decide which one to use (e.g. a large database that access blocks where information requested is saved could use block-level integrity). An ideal system would give the opportunity of using any or both of them on a per-file basis, so application requirements could be met.
818
A. Izquierdo et al.
Another issue we must take into account is whether there is data encryption in storage (as it could be if we had used client encryption as stated in section 4.1), because most of the modern algorithms provide plain-text integrity and can be associated to digital signature, and we would already have block integrity. We should analyze if the integrity level provided meets our expectatives and choose between the possibilities of ciphering, ciphering and hashing or just hashing. 3.3 Availability Availability refers to the possibility of accessing the information requested when requested by those who need it. Availability relies in hardware, software, operating system, application services, etc., and it is not easily guaranteed. Some of the latest Internet worms and attacks have been DoS and DDoS attacks, which address the availability of services to legitimate users. The techniques being used in communications to provide availability are based in service replication (load balanced servers) and traffic filtering. Probably, the most popular recent examples of availability breakdowns have been attacks being held against DNS root servers [16] and the effects of Blaster virus on Microsoft’s Windows Update web service [17]. Service replication is not a complete solution for availability in networked file systems, as we would have to face the problems of consistency, and integrity between servers, so we would be back to the beginning of our problem. We could replicate our network file system, but it would take an extra effort to make it work properly, and we would have to apply all the security mechanisms we need in both of them. On the other hand, traffic filtering can help us to avoid DoS and DDoS attacks, because network file systems are usually available to a well known addresses range (usually the LAN range), so any traffic from these services flowing from or to addresses outside this range is not authorized traffic. Besides, additional measures can be taken at the service layer, such as dropping connections from sources that have failed to connect too many times for a period of time. However, as we evolve towards mobile and ubiquitous systems where principal’s network addresses may change, together with network mechanisms like proxies and NAT, and considering the ease of network address spoofing, network addresses are no longer valid authentication mechanisms. Cryptography can play an important role in this requirement, because used as authentication mechanism it can be a tool to quickly decide if a request comes from a legitimate principal or from an attacker. Similarly, the use of cryptography in communications at network level (e.g. using IPSec) provides the tools needed by the file system service and the network devices to discriminate authorized traffic from malicious one. A point against security techniques mentioned previously in this document is the computational cost of operations like message encryption and decryption, credentials inspection, access control checks, etc. If all these techniques are implemented concurrently, server hardware requirements will be quite higher than before, so performance of the file system does not fall drastically. An extreme situation could lead to a self-DoS attack, where legitimate users cannot access the file system due to the server’s processors high load. One more step towards data integrity would be the facility for hiding the real data structure in server’s storage device, so in case an attacker could get access to the
Security Issues in Network File Systems
819
system he would not be able to identify where sensible shared information relies. This would not help in case the attacker decided to delete the full contents of the server, but it would be useful in case the attacker were looking for some specific files. Techniques that can be useful to provide these directory hiding can be the use of hash values of the names instead of the real names, or the use of symbolic links to avoid replicating the whole directory structure in each server.
4 Conclusions and Future Works As has been exposed, there are plenty of techniques and mechanisms that can be used to provide security properties to networked file systems. These techniques are the same that are being used for communications security: cryptography, access control lists, role-based access controls, etc. However, as we are working at file system’s level, there are higher performance requirements than in any other network communication. These requirements have been the traditional reason for not implementing security services in file systems, although computational capabilities have heavily increased during past years. It is time to review those assertions and decide whether to implement them now. Some steps have been taken in NFSv4 proposed standard, but no real implementation uses the new security flavors. We have review the techniques used to preserve data confidentiality, integrity and availability, and we have found the growing need for preserving them in networked environments. Data confidentiality can be preserved using cryptography to authenticate principals and store data in servers, combined with access control lists. Integrity can be provided by cryptographic hash values digitally signed, to avoid undetected modification of those hash values. To provide data availability, service replication and traffic filtering are being used, and other tools such as strong authentication can be used to obtain better results. As for the future works, investigation on low requirement encryption algorithms that can be used along with digital signature will be needed, probably in conjunction with those taken for mobile and wireless devices.
References 1. 2. 3. 4. 5.
nd
Satyanarayanan, M.: “Distributed Systems, 2 Edition”. Addison-Wesley – ACM Press (1995), 353-383 Needham, R. M. and Schroeder, M.D.: Using Encryption for Authentication in Large Networks of Computers, Communications of the ACM (1978), 23-35 Sandberg, R., Goldberg, D., Kleiman, S., Walsh, D. and Lyon, B.: Design and Implementation of the SUN Network File System, Proceedings of the Summer Usenix Conference (1986) Satyanarayanan, M. Integrating Security in Large Distributed Systems, ACM Transactions on Computer Systems (1989) Coulouris, G., Dollimore, J. and Kindberg, T.: Distributed Systems: Concepts and Design, nd 2 Edition. Addison-Wesley (1994), 197-249
820 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18.
A. Izquierdo et al. Anderson, R.: Security Engineering: A Guide to Building Dependable Distributed Systems. Wiley & Sons (2001), 51-71, 115-133 nd Schneier, B.: Applied Cryptography, 2 Edition. Wiley & Sons (1996) Shepler S., Callaghan B., Robinson D., Thurlow R., Beame C., Eisler M. and D. Noveck, Network File System (NFS) version 4 Protocol – Proposed Standard. RFC 3530 (2003) Eisler M.: NFS Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5, RFC 2623 (1999) Callaghan B., Pawlowski B. and Staubach P., NFS Version 3 Protocol Specification, RFC 1813 (1995) ® ® CERT Coordination Center, CERT Advisory CA-1994-15 NFS Vulnerabilities, http://www.cert.org/advisories/CA-1996-09.html, (1997) SANS Institute, The Twenty Most Critical Internet Security Vulnerabilities, Version 4.0, http://www.sans.org/top20/, (2003) AusCERT: “UNIX Security Checklist v2.0”, http://www.auscert.org.au, (2001) Eisler M., Chiu A., Ling L.: “RPCSEC_GSS Protocol Specification”, RFC 2203 (1997) Patterson, D., Gibson, G., Katz, R.: “A Case for Redundant Arrays of Inexpensive Disks (RAID)”. Proceedings of the International Conference on Management of Data, (1988) Bridis, T.: “Powerful attack cripples majority of key Internet computers”. http://www.securityfocus.com/news/1400 (2002) Knowles, D., Perriot F., Szor, P.: “W32.Blaster.Worm Security Response”, http://securityresponse.symantec.com/avcenter/venc/data/w32.blaster.worm.html (2003 Ferraiolo, D., Kuhn, R.: “An Introduction to Role-Based Access Control”, http://csrc.nist.gov/rbac/NIST-ITL-RBAC-bulletin.html. NIST/ITL Bulletin (1995)
