Paranoid Penguin - Samba Security, Part I
Samba over the Internet?
If Samba is so very convenient, you may wonder, why not use IPsec or some other VPN/encryption tool to secure its use on the Internet? This is actually possible. As it's been a while since I covered IPsec in this space, and in the intervening years, IPsec support has been added to the Linux kernel, I just may end this series with a quick tutorial on doing Samba over IPsec.
However, Samba is a very “chatty” protocol—it generates a lot of packets even if you're using it only for small files or shares. This causes problems not so much for your Internet link as for Samba performance: Samba can be very sensitive to dropped or delayed packets, which is more likely in your modestly sized Internet uplink than over your exponentially bigger Local Area Network (LAN) fabric.
So, trying to get Samba working over IPsec may or may not be worth your time, and it may or may not warrant my covering it in this series of columns. Have no fear, one way or another, you can expect me to provide a tutorial on using the Linux kernel's IPsec functionality in a future Paranoid Penguin column.
I've explained in gory detail why Samba, firewalls and the Internet don't go well together. So, how do you secure Samba for LAN use?
Samba security is a surprisingly complex topic, which is why this is a multipart article. You've got many choices to make if you want to use Samba securely. Is your Samba server also going to be an NT domain controller, or will it participate in an existing domain or workgroup? Will you permit guest access, or will all users of every share need to be authenticated first? Or, will you allow both private and public shares?
Don't worry if the previous questions make little sense to you. That's why the Paranoid Penguin is here. For most of the rest of this article, I discuss these concepts in detail. Only then will you be ready to explore the mysteries of smb.conf and the NMB dæmon.
First, let's get some definitions out of the way:
SMB: the Server Message Block protocol, the heart of Samba. SMB is the set of messages that structure and use file and print shares.
CIFS: short for the Common Internet File System, which in practical terms is synonymous with SMB.
NetBIOS: the API used to pass SMB messages to lower-level network protocols, such as TCP/IP.
NBT: the specification for using NetBIOS over TCP/IP.
WINS: Microsoft's protocol for resolving NBT hostnames to IP addresses; it's the MS world's answer to DNS.
Workgroup: a peer-to-peer group of related systems offering SMB shares. User accounts are decentralized—that is, maintained on all member systems rather than on a single central server.
NT domain: a type of group consisting of computers, user accounts and other groups (but not other domains). It is more complex than a workgroup, but because all domain information is maintained on one or more domain controllers rather than being distributed across all domain members, domains scale much better than workgroups.
Active Directory: Microsoft's next-generation domain system. Samba can serve as an Active Directory client via Kerberos, but you can't control an Active Directory tree with a Samba server as you presently can do with NT Domains. Active Directory server support will be introduced in Samba v4.
User-mode security: when a Samba server's shares are authenticated by local workgroup user names and passwords.
Share-mode security: when each share on a Samba server is authenticated with a share-specific password that isn't explicitly associated with a user name.
Guest access: when a Samba server allows anonymous connections to a given share via a shared guest account with no password.
Here's what you need to take away from that list of definitions.
First, the protocols. SMB, aka CIFS, is the protocol that defines the network filesystem—its structure and its use. NetBIOS provides an API through which SMB messages may be transmitted over networks, and which may be used by servers to “advertise” services and by clients to “browse” those services. NetBIOS can use any of a number of lower-level network protocols as its transport, but the most important of these is TCP/P; NetBIOS over TCP/IP is called NBT. WINS provides centralized name services (mappings of hostnames to IP addresses), where needed.
Next, server roles. A Samba server can authenticate its transactions either on a per-share basis, using share-specific passwords and inferred/implicit user names, or on a per-user basis, using either a dedicated local user database (in user-mode security) or some networked authentication scheme, such as LDAP, NIS, NT Domains or Active Directory. The server can be in a workgroup, in which case it needs to maintain its own database of all the workgroup's user information, or it can be in an NT Domain or an Active Directory, in which all user information is managed centrally.
When you want to share data with maximum convenience and minimum security, for example, read-only files containing nonsensitive data, you can put it on a share with guest access. Users connecting to such a share will not be prompted for any user name or password.
The bad news is that this is only a fraction of what you need to know in order to understand SMB/Samba services. The good news is, NT Domains and Active Directory are out of scope for this series of articles. We're going to focus on using workgroups for our secure Samba file server.
Workgroups don't scale well, because each server in a workgroup needs to maintain all user information for the entire workgroup, and you must somehow keep this information (passwords and so forth) consistent across all workgroup members (except where only guest access or share-mode access is permitted).
However, for the usage scenario I've described—creating a file share or two I can reach from anywhere in my house—I'm not going to have very many users or even more than one server, necessarily, and the simplicity of setting up a standalone/workgroup server trumps the complexity-laden power that comes with NT Domains. If your needs differ, hopefully this series of articles nonetheless will make it easier for you to figure out Samba's NT Domain support on your own, if that's what you really need instead.
So, to express our project in the terms I've just defined, in subsequent articles, I'm going to walk through the process of configuring a standalone (workgroup) Samba server operating with user-mode security, using a dedicated local user database. Our example server will host a combination of guest shares, read-only shares restricted by user and shares that can be read by only some users, but that can be written to (changed) by others.
First though, we have to make sure you've got the software you need in order to pull that off.