Paranoid Penguin - Samba Security, Part I

Build a secure file server with cross-platform compatibility.
Samba Security Terms and Concepts

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.



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

SWAT on OpenSuSE 11.0

bhoel's picture

To get SWAT working on OpenSuSE 11.0 with xinetd, one has to edit


and delete (or comment out) the line:

  	disable         =  yes

Kind regards

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState