Introduction

With the support of NFS V4, availability of various virtualization features and support for IBM General Parallel Filesystem makes AIX V6.1 a good candidate for being extensively used as a file server in various storage and data cloud offerings. Typically, end users over heterogeneous UNIX® systems access the files exported by the NFS-based AIX file servers through their NFS clients. Among others, SUSE Linux Enterprise Server (SLES) is one Linux offering that is used extensively in the industry and has a compatible NFS client with AIX.

While centrally managing of data using file servers is a popular approach, it is very important to consider securing data at rest, not only to meet various regulatory compliance issues, but also for users' assurance over the safety of their data that resides in a virtual central repository. There are many different ways and methods to achieve secure data at rest. AIX V6.1 provides Encrypted File System for securing data at rest, but it currently limits its usage over the NFS protocol. SUSE Linux Enterprise Server provides Encrypted File System, which uses various options to aid securing data at rest (see Resources). This article demonstrates how administrators and users can secure their remote files hosted by AIX over the NFS protocol and can exploit the Encrypted File System features provided in SLES. The article considers a sample manifestation and explains in detail the various steps involved.

Scenario: Secure data exported by AIX, accessed by SLES

Figure 1 indicates the example setup, which has an AIX system serving as a file server exporting with the NFS protocol. The SLES system is configured as a NFS client to the AIX system from where the end users access their files. As an administrator, you are required to ensure that all the files being accessed by users using the SLES machine have their data securely stored over the remote AIX-based file server.

Back to top

AIX 6.1 as file server: Export using NFS

AIX V6.1's features are rich with virtualization features, storage management functionalities, as well as support for clustered file systems like GPFS and distributed file systems like NFS V4. This makes AIX systems highly suitable for hosting and serving file export capabilities. In this manifestation, export a directory named "/storage/enduser" using the NFS protocol. This setup has JFS2 (Enhanced Journaled File System) as the underlying file system, but it can be easily replaced by a GPFS-like file system managing a cluster of storage boxes. For additional information on GPFS, as well as NFS V4 support on AIX, refer to Resources.

Back to top

Export a directory using the NFS protocol from AIX

Step 1: Create the directory to be exported

							
# hostname
fsaix010

# mkdir /storage

# mkdir /storage/enduser

						

Step 2: Export the created directory

Now export the created directory so that all users have read-write permissions and the machine (with an IP address of 9.122.118.153 and a hostname as linux-r4pv) that is going to mount this share has root permissions, and then check whether the corresponding entry is created in /etc/exports.

							
# hostname
fsaix010

#  mknfsexp -d /storage/enduser -t rw -r 9.122.118.153

# cat /etc/exports
/:/testdir -vers=3,rw,root=punter.in.ibm.com
/:/user_new -vers=2,rw,root=punter.in.ibm.com
/storage/enduser -rw,root=9.122.118.153
						

Step 3: Set up the NFS service

The NFS service is typically started automatically while booting. However, if it is not started, the following step starts the NFS server. If the service is already started, the following step takes no action.

							
# hostname
fsaix010

# mknfs
0513-029 The portmap Subsystem is already active.
Multiple instances are not supported.
Starting NFS services:
0513-029 The biod Subsystem is already active.
Multiple instances are not supported.
exportfs: /:/testdir: No such file or directory
exportfs: /:/user_new: No such file or directory
0513-029 The nfsd Subsystem is already active.
Multiple instances are not supported.
0513-029 The rpc.mountd Subsystem is already active.
Multiple instances are not supported.
0513-029 The rpc.statd Subsystem is already active.
Multiple instances are not supported.
0513-029 The rpc.lockd Subsystem is already active.
Multiple instances are not supported.
Completed NFS services.
0513-095 The request for subsystem refresh was completed successfully.
						

Step 4: Check whether the export was successful and the share is visible

The exportfs command lets you know which paths are exported and the user permissions assigned to them. You can again confirm the success of the export using the showmount command, which gives the export list for the machine whose address is specified.

							
# hostname
fsaix010

# exportfs
/storage/enduser -rw,root=9.122.118.153

# showmount -e localhost
export list for localhost:
/storage/enduser (everyone)
						

Back to top

Import on SLES using NFS

SLES also supports the NFS protocol and inter-operates with AIX NFS. Typically, the exported share from AIX can be mounted at any directory in your file system. Mount the share under "/mnt/remote_storage".

Importing using NFS on SLES

							
linux-r4pv:~ # hostname
linux-r4pv

linux-r4pv:~ # mount -t nfs 9.182.192.250:/storage/enduser/ /mnt/remote_storage/

						

In the previous command, -t nfs specifies the protocol to be used or the file system type to be mounted. The server address is the IP address (or FQDN) of the server (in this case, it is 9.182.192.250 or fsaix010) exporting the NFS share. The exported path, /storage/enduser/, is the local path of the server that is being exported as a NFS share, and the destination path, /mnt/remote_storage/, to mount is the local path of the client machine where the NFS share is mounted.

Note that a fully qualified domain name (FQDN) is mandatory only if the two machines (the server and the client) are in different domains. If the machines are in the same domain, even the shortname/hostname would be sufficient. However, the IP address as well as FQDN can be used in both the cases.

You can now check whether the mount operation is successful or not using the mount command, which lists all the mounted shares as well as their type and their paths.

							
linux-r4pv:~ # hostname
linux-r4pv

linux-r4pv:~ # mount
/dev/hda2 on / type reiserfs (rw,acl,user_xattr)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
debugfs on /sys/kernel/debug type debugfs (rw)
udev on /dev type tmpfs (rw)
devpts on /dev/pts type devpts (rw,mode=0620,gid=5)
securityfs on /sys/kernel/security type securityfs (rw)
/dev/hdc on /media/SLED100_001 type iso9660 (ro,nosuid,nodev,utf8,uid=0)
9.182.192.250:/storage/enduser/ on /mnt/remote_storage type nfs
(rw,addr=9.182.192.250)
						

Use of Encrypted File Container on SLES

The objective is to ensure that all the user files that are created on the NFS-mounted system shared over the SLES machine will be secured. This is to ensure that files created by the end user using the SLES system are ensured of secure data at rest. SUSE Linux Enterprise Server provides different ways to secure data by encrypting partitions and files. Among other options, SLES allows you to set up an Encrypted File System (EFS) to create encrypted partitions during installation or on a running system or to create an Encrypted File as a Container (for more details, refer to Resources).

Out of these three options, the first two can be used to seamlessly secure the data, but you have to dedicate a partition for this setup. Partitioning the disks include formatting them, with resulting loss to existing data. Also, its operation over the distributed file system is questionable. Instead, without the need for re-partitioning, you can use the Encrypted File as a Container feature for to seamlessly secure data by simply creating a container file. This file will in turn be holding all the encrypted data so that it can act as a container for the new files and directories created. Hence, if you have an already-running system, all that is required is to create a new container file and start using it as a new file system, which will secure data before actually writing to the disk. Hence, for this manifestation, use Encrypted File as a Container over NFS to help secure the remote data.

Back to top

Configure the Encrypted File Container

The following are the detailed steps used to configure the Encrypted File Container on SLES, which you will use to secure data over the NFS share.

Step 1: Create a directory (for example, /mnt/encrypt) that we will mount our Encrypted File Container

The Encrypted File Container forms a loop device, which you will mount on /mnt/encrypt. Now, when you create new files under this path, all the data will actually be encrypted and stored in the File Container, which is residing on the NFS-exported share. Hence, no data block will be stored under the local file system, but all the data blocks are stored on the NFS mounted share (/mnt/remote_storage, which maps to /storage/enduser on the AIX machine). Thus, the data is actually residing on the remote AIX machine in an encrypted form.

							
linux-r4pv:~ # hostname
linux-r4pv

linux-r4pv:~ # mkdir /mnt/encrypt
						

Step 2: Create the Container File using the YaST tool

Create the Container File using the YaST tool, which is described in the SLES documentation (see Resources). Typically, in order to start the YaST tool, go to Computer->Control Center. Select the System group and then double-click the YaST icon. It will ask for the root password. Enter the root password and click Continue. In the tool window, select System from the left-hand sidebar. Double-click the Partitioner icon and select Yes in response to the warning. Once the Expert Partitioner window opens, select Create Crypt File from the "Crypt File" drop-down box located at the bottom of the window.

In the Create New Device Loop Setup Window, as shown in Figure 2, we have to enter the path of the container file that will contain the encrypted data. Since you have mounted the AIX JFS2 share through NFS on the /mnt/remote_storage directory, specify the path of the container file as /mnt/remote_storage/secure_container. This file need not be explicitly created at that location; it will be automatically done. Check the option Create Loop File. Enter the size in MB of the container file you want to create. This is the capacity of the container file and it will not hold data larger than that. Select the Format radio button and select the file system type to be used on the container file. The example shown has selected Ext2 File System. Also, check the checkbox for Encrypt file system. Specify the mount point as the directory that you created previously (/mnt/encrypt). You can change the Fstab options as well as options for the file system, but it is not recommended for novice users. On selecting the OK button, a new window pops up asking for the password to be used for encrypting and decrypting the data. Enter the password (the length must be eight or more characters) in both the text boxes and select the OK button to close the window.

Please make sure to remember this password.

A new entry will appear in the table with the device name as /dev/loop0, as shown in Figure 3. The configuration is now complete, but the changes are not reflected until you click Apply on this window. After selecting Apply, it will ask for confirmation to apply changes, as shown in the Figure 4. Once you select Apply again, the changes are made permanent and the Encrypted File Container is ready to use.

Once the changes are applied, the new file-based loop device will be mounted at the aforementioned mount point. You can check this by executing the mount command as follows:

							

linux-r4pv:~ # hostname
linux-r4pv

linux-r4pv:~ # mount
/dev/hda2 on / type reiserfs (rw,acl,user_xattr)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
debugfs on /sys/kernel/debug type debugfs (rw)
udev on /dev type tmpfs (rw)
devpts on /dev/pts type devpts (rw,mode=0620,gid=5)
securityfs on /sys/kernel/security type securityfs (rw)
/dev/hdc on /media/SLED100_001 type iso9660 (ro,nosuid,nodev,utf8,uid=0)
9.182.192.250:/storage/enduser/ on /mnt/remote_storage type nfs
(rw,addr=9.182.192.250)
/dev/loop0 on /mnt/encrypt type ext2 (rw) 
						

You first mounted AIX-exported data on the SLES machine using NFS and then you mounted an Encrypted File Container created on this NFS share on a local directory. So all the files created within this local directory (/mnt/encrypt) are actually residing in the Encrypted File Container in an encrypted form, which is in turn residing on the remote AIX machine, achieving secure data at rest.

Back to top

Test the set up

You have now successfully configured your set up such that all the files created by users on the SLES machine over the mounted device (/mnt/encrypt) will be securely stored on the AIX-exported NFS share, thus ensuring secure data at rest. All the files that will be created on the mounted device will be securely stored by the Encrypted File Container in the /mnt/remote_storage/secure_container file. Let's test the set up.

							

linux-r4pv:~ # hostname
linux-r4pv

linux-r4pv:~ # cd /mnt/remote_storage/

linux-r4pv:/mnt/remote_storage # ll
total 1024
-rw-r--r-- 1 root root 1048576 Jul 28 21:27 secure_container
						

							

linux-r4pv:/mnt/remote_storage # hostname
linux-r4pv

linux-r4pv:/mnt/remote_storage # cd /mnt/encrypt/

linux-r4pv:/mnt/encrypt # ll
total 12
drwx------ 2 root root 12288 Jul 29 02:47 lost+found

linux-r4pv:/mnt/encrypt # echo Hello,This is a test file>test.txt

linux-r4pv:/mnt/encrypt # ll
total 13
drwx------ 2 root root 12288 Jul 29 02:47 lost+found
-rw-r--r-- 1 root root    26 Jul 29 02:54 test.txt
						

							

linux-r4pv:/mnt/encrypt # hostname
linux-r4pv

linux-r4pv:/mnt/encrypt # cat test.txt
Hello,This is a test file
						

							

linux-r4pv:/mnt/encrypt # hostname
linux-r4pv

linux-r4pv:/mnt/encrypt # cd /mnt/remote_storage/

linux-r4pv:/mnt/remote_storage # ll
total 1024
-rw-r--r-- 1 root root 1048576 Jul 28 21:34 secure_container

linux-r4pv:/mnt/remote_storage # cat secure_container
<garbage output>
	
						

The secure_container file is in an encrypted format and just has garbage data. Since the file size is 1MB, the actual output of the cat secure_container command is not shown. However, there is no trace in the output that this is a container file and it contains a file named test.txt in an encrypted format.

# hostname
fsaix010

# cd /storage/enduser

# ls
secure_container

# cat secure_container
<garbage output>
						

Thus, you have successfully stored your data at rest seamlessly at a remote location managed by AIX in an encrypted format secured by a password using a SLES Encrypted File Container.

For usage of the Encrypted File Container in a production environment, refer to SLES documentation and release notes.

Back to top

Conclusion

This article demonstrated how to secure data at rest exported by AIX and consumed by SLES via the NFS protocol using the Encrypted File Container feature provided with SLES.

Resources

Learn

• The IBM Redbook Implementing NFS Version 4 in the Enterprise Planning and Migration Strategies provides methods for implementing NFS Version 4 in the enterprise and extensive coverage of methods for how it can potentially be used as a migration target for legacy AFS- and DCE/DFS-based enterprise file systems.
  
  
• Refer documentation over Encrypting Partitions and Files in SLES 10 for detailed understanding.
  
  
• Learn more about "IBM General Parallel File System" .
  
  
• The IBM Redbook Securing NFS in AIX: An Introduction to NFS Version 4 in AIX 5L Version 5.3 provides a broad understanding of NFS Version 4 and specific AIX NFS Version 4 implementation details.
  
  
• AIX and UNIX : Want more? The developerWorks AIX and UNIX zone hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials.
  
  
• developerWorks technical events and webcasts: Stay current with developerWorks technical events and webcasts.
  
  
• AIX Wiki: Visit this collaborative environment for technical information related to AIX.
  
  

Get products and technologies

• AIX 5L Expansion Pack and Web Download Pack: Start downloading now.
  
  
• AIX Toolbox for Linux Applications.
  
  

Discuss

• Participate in the AIX and UNIX forums:
  • AIX Forum
  • AIX Forum for developers
  • Cluster Systems Management
  • IBM Support Assistant Forum
  • Performance Tools Forum
  • Virtualization Forum
  • More AIX and UNIX Forums
  
  
• Follow developerWorks on Twitter.
  
  
• Get involved in the My developerWorks community.
  
  

About the authors

Sandeep Ramesh Patil is an Advisory Software Engineer for the IBM India System and Technology Lab. His professional experience has been on distributed technology and security products such as the IBM Network Authentication Services (IBM Kerberos). He is an IBM developerWorks Professional Author with most of his articles on information security. He also plays a active role in IP generation. Sandeep holds a BE degree in computer science and engineering from the University of Pune, India. You can contact him at rsandeep@in.ibm.com .

Bhushan Pradip Jain is a Associate Software Engineer working for the IBM India Software Labs. He has published a technology named as "Policy-Driven File Encryption Explorer Based on OpenPGP" under alphaWorks and is currently working on IBM Unified Scalable Storage. He has also worked for developing Intrusion Detection System and implementation of part of the operating system for a multi-antenna telescope. Bhushan has completed his B.Tech. in Computer Engineering from College of Engineering, Pune(COEP). You can contact him at bhujain1@in.ibm.com.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• Scenario: Secure data exported by AIX, accessed by SLES
• AIX 6.1 as file server: Export using NFS
• Export a directory using the NFS protocol from AIX
• Import on SLES using NFS
• Use of Encrypted File Container on SLES
• Configure the Encrypted File Container
• Test the set up
• Conclusion
• Resources
• About the authors
• Comments

Next steps from IBM

WebSphere Portal can help your small and midsize business achieve better website security, along with faster time to value with easily deployable and customizable example Web sites.

---

• Try: Download a free trial version of IBM WebSphere Portal Express V6.1, which offers collaboration, document management, and secure Web content management.
• Article: This article provides an overview of the WebSphere Portal security architecture, including internet security, and secure connections between clients.
• Tutorial: This tutorial take you through the steps to develop and test your first portlet WebSphere Portal Test Environment.
• Demo: These demos show Web 2.0 features available today within WebSphere Portal, as well as several features planned for the future.
• Buy: IBM WebSphere Portal Express

My developerWorks community

Dig deeper into AIX and UNIX on developerWorks

Calling all developers

Download no charge Lotus Domino Designer

Special offers