Paranoid Penguin - Samba Security, Part I

It recently occurred to me that in the eight years or so I've been writing this column, I've never covered file servers. I've covered secure file transfer, for example, via scp, rsync and vsftpd, which certainly is important. But, I've not covered file serving, specifically, allowing users to mount persistent “network volumes” that let them use networked server disk space as though it were a local disk. This has all sorts of productivity- and operations-related benefits: it's (usually) easy for end users to use, and it makes data easier to access from multiple systems and locations and easier to back up and archive.

As it happens, there's a rich toolkit available to Linux users for building, securing and using file servers, mainly in the form of Jeremy Allison and Andrew Tridgell's Samba suite of dæmons and commands, plus various graphical tools that supplement them. For the next few columns, I'm going to show you how to build a secure Samba file server using both command-line and GUI tools.

Does that sound like a good Paranoid Penguin project? Good enough, I hope, to forgive me for ignoring file servers for so long. (So many things to secure, so little time!)

Obviously, no series of articles can cover everyone's file server needs or wants. So, before I begin, let's agree on some requirements of my choosing (hopefully, some or all of these coincide with yours). It seems reasonable to focus on the following: security, convenience and cross-platform compatibility.

It goes without saying that in a security project, security is foremost among my preoccupations. With a file server, I'm going to pay particular attention to protecting the data itself: the integrity, availability and confidentiality of my files, while at rest on the server and in transit over the network. I also want to protect the server itself, both to protect the data and to prevent the server from being misused in other ways.

The trio of goals I listed above (confidentiality, integrity and availability) is part of classic information security dogma. In just about any information security scenario you can think of, C, I and A are important one way or another.

The goal of simply preventing a system from being used in unexpected or unwanted ways by unauthorized persons though, is what I like to call exclusivity. If I go to the trouble of building and maintaining a file server, even if the data itself is 100% boring and useless (please do not insert a joke about Paranoid Penguin column archiving here), I want such a server to be used exclusively by me and the users I specifically designate.

Even if it's some sort of public file server (for which, by the way, asynchronous file transfer technologies, such as FTP, HTTP and rsync are much more securable than Samba), I still want that server to be used exclusively for that purpose. I don't want it being used as someone's pirate IRC server, warez repository or proxy for attacking other systems.

I just mentioned that the type of file server I'm talking about (the kind to which you can “map drives”) isn't suitable for public file serving. This is because the two dominant tools for this, Samba and NFS, historically have relied on RPC, a protocol that involves the dynamic assigning of TCP and UDP listening ports on a per-client, per-connection basis, which requires a large range of ports to be opened through any firewalls that might be in the way. Alas, opening UDP and TCP ports 1025 through 65,534 in both directions through a firewall is an awful lot like not using a firewall at all, even if you limit source or destination IP addresses.

On the one hand, more current versions of NFS (versions 3 and 4) allow the server/dæmon to use a single TCP port for all connections by concurrent users. However, much of the world seems to be stuck on NFS v2. Worse still for our purposes here, there never has been good support for NFS outside the world of UNIX and UNIX-like platforms.

And, this brings us to our other two requirements: convenience and cross-platform compatibility. I want to be able to map network drives/volumes, because this is much, much more convenient than manually copying files to and from the file server every time one changes, even automatically via some script. I want a file share that allows me to “work” on files that “reside” in a central location; I don't want working copies of my files being maintained on umpteen different systems.

I've alluded to the fact that NFS allows you to map network volumes in a very similar way as with Samba. However, I have to acknowledge the ugly reality that I am sometimes required to operate Windows systems. My job requires it and so does my video-gaming habit. So, I need a file server that supports both Linux and Windows clients. (As it happens, the one we're going to build also will support FreeBSD, NetBSD, Solaris, Mac OS X and practically the entire rest of the *nix world!)

To summarize, we're going to build our file server with Samba, because it's convenient and it supports different client platforms. And, we're going to build it as securely as possible.