Trellis NAS Bridge Appliance (TNBA) Security Information

0. What is the purpose of this document?

The purpose of this document is to provide TNBA administrators with the background they require to effectively administer a TNBA. This document focuses on two things: 1) the underlying security models of the individual components and 2) best practices that must be used if the TNBA is to be used securely.

1. What should I be aware of to use the TNBA securely?

The following bullet points list potential security concerns associated with the TNBA. Administrators must be aware of these concepts. More information about each item can be found in later sections of this document. Access to the Web GUI should be restricted. Users with Web GUI access have the ability to change public/private keys for all users. Login access to the appliance should be restricted. The appliance only accepts SSH connections to the root account. A user with root access to the appliance will also have access to all users' SSH Agents. Additionally, since SSH Agents store private keys in memory, and VMWare may swap memory to the host system's swap file, access to the host system's swap file should be restricted. TNBA login passwords are saved to the appliance hard disk in plaintext. This design decision was inherited from FreeNAS. We are looking into more secure ways of storing user passwords. Users with read access to the appliance's virtual hard disk files may be able to extract user passwords. It is recommended that read access to the appliance's files be restricted. In version 1.0 of the appliance, passwords to remote CIFS servers are stored in plaintext on the appliance's hard disk. Login access to the appliance as well as access to the appliance's virtual hard disk files should be restricted to prevent an unauthorized party from extracting these passwords. Version 1.0.1 of the appliance uses a simple encryption scheme to protect these passwords. Due to the NFS security model, workstations that are clients of the appliance should have root access restricted, or users with root access must be trusted. Best practices associated with traditional NFS installations apply to the TNBA. The TNBA does not support multiple writers to the same file. If multiple users modify the same file at the same time only one set of modifications will remain.

2. What is the security status of the TNBA?

Understanding the security of the TNBA requires understanding the security of its components. The TNBA uses the following components: Samba (http://www.samba.org) Secure Shell (http://www.openssh.org) A User-space NFS server (ftp://linux.mathematik.tu-darmstadt.de/pub/linux/people/okir/) The Trellis File System Library (http://www.cs.ualberta.ca/~paullu/Trellis/) Mini-HTTPD (http://cryp.to/mini-httpd/) PHP (http://www.php.net) The security status of the above components will be described in the following sections. Component Port Samba 139, 445 (TCP and UDP) Secure Shell 22 (TCP) Userspace NFS 2049 (UDP), mountd uses a portmap assigned port The Trellis FS Library None Mini-HTTPD 80, 443 (TCP) PHP None The TrellisNBA uses the following network ports:

3. Samba

Samba is an open-source implementation of the CIFS protocol. Samba is used in both the front-end and the back-end of the TNBA. In the front-end, clients of the TNBA can use the CIFS protocol. In the back-end, the TNBA can connect to remote CIFS servers. CIFS uses a password-based challenge-response system to authenticate users. When authenticating over the Internet, a hashed value based on your password, not the password itself, is sent over the Internet. In order for the TNBA to authenticate with a remote CIFS server, the TNBA must have access to the user's password. The TNBA, as of version 1.0.1, stores these passwords in encrypted form on the TNBA hard disk. The current encryption scheme is simple and could be be broken be an experienced user. It is recommended that only the TNBA administrator have access to the appliance's hard disk. Version 1.0 of the TNBA stores Samba passwords in plain text on the virtual hard disk. It is recommended that users of version 1.0 switch to version 1.0.1 or higher.

4. OpenSSH

The Secure Shell uses public/private key pairs for authentication. In a typical use-case, a user will place the public key part of their key pair in the authorized_keys file on the server. The private key part is loaded in to a program called ssh-agent. The SSH Agent will perform authentication challenge-responses on behalf of the users. The SSH Agent uses a Unix domain socket and Unix file system permissions to prevent unauthorized users from accessing a user's SSH Agent. In the TNBA, user's private keys are loaded into SSH Agents running in the appliance. There are two potential security risks associated with SSH Agents. Since the private key resides in the Appliance's RAM, an experienced user could recover the private key from a core file if the appliance crashes, or from the swap file if the memory associated with the agent is swapped to disk. The Samba and NFS servers run with root privilege inside the appliance. It is recommended that login access to the appliance be restricted to prevent security risks associated with SSH private keys.

5. The User-space NFS Server

Understanding the security of the TNBA's NFS server requires an understanding of NFS security, particularly the AUTH_SYS flavour of NFS authentication. NFS is designed to operate in an environment where access to root privilege on both the clients and the server is restricted. User authentication between the client and the server happens in two phases, server-enforced host authentication and client-enforced user authentication. The TNBA will only allow clients listed in the NFS exports list to access the server. Clients are added through the web GUI. After the TNBA allows a client to connect, the server authenticates users only based on the client reported user id (specifically, the Unix UID). The NFS security model means that a user with root access on a client can gain access to all user files for any user of the TNBA. It is strongly recommended that only trusted users are given NFS access to the TNBA.

6. The Trellis File System Library

The TNBA uses the Trellis File System Library (TFS Library) to cache file data inside the server. When a file is opened, a copy is placed on the appliance hard disk, when the file is closed, and if it was modified, it is copied back to the remote server. It is possible for a third party to modify the file after it is opened and before it is closed. In this case, the third party changes will be overwritten when the file is closed. It is up to the user to make sure that at any given time only one party is modifying a file.

7. Mini-HTTPD

The TNBA web server uses SSL to protect data that is passed between the web browser and the TNBA. SSL protects SSH passphrases and Samba passwords from being sent in plaintext across the network. When connecting to the TNBA web server, it is normal to see the following dialog: The above dialog appears because the SSL certificate we generated is not signed by an official Certificate Authority (CA). Never-the-less, the encryption is secure. CA signing is designed to solve the key distribution problem, but since we are distributing the SSL certificate with the appliance, TNBA is not affected by the key distribution problem. If you have your own CA signed SSL certificate, you can load it into the TNBA using the web GUI. It is also normal to see the following dialog: SSL certificates have the domain name of the server encoded in them. Since the TNBA uses DHCP, we cannot predict ahead of time what the domain name of the TNBA will be. It is safe to click OK. Installing your own SSL certificate and correctly configuring your DHCP server will eliminate this dialog. Internet Explorer users will see the following dialog: This dialog should be expected, and it is OK to select "Yes".