Six easy ways to secure Samba

Learn how to take six important steps that will greatly increase the security of your Samba server.

Security is a balance between allowing the right people easy access to a resource and preventing unwanted interlopers from getting their hands on information you don’t want them to have. Samba has a long list of configuration options that allow you to fine-tune security to exactly what you need. Here are some of the important options which you can use to make Samba available to valid users and nearly impervious to everyone else.

Most security is based on passwords. A user name and password pair is still one of the best ways to authenticate a user, that is, as long as the password remains safe. This can be a difficult task with the proliferation of network monitoring tools that are both easy to get and easy to use. Sniffing a password off the wire has become a relatively trivial task.

Limiting password transmission on the network
Although transparent to the user, there are several ways in which Windows will transmit and receive a password. Up until Windows 2000 Service Pack 3, clear text was one of those options. Basically, the username and password were packaged and transmitted without protection across the network.

The first step is to set the Encrypted Passwords global option to Yes. This will cause Samba never to use clear-text passwords. However, Samba will, by default, start using an older LAN Manager format for hashed passwords. It's not clear text, but the hash is sufficiently easy to crack via brute force that it’s not recommended.

To turn off LAN Manager passwords, you can add the global option Lanman Auth and set it to No. This will break any non-Windows NT/2000/XP clients and servers since these are the only clients capable of communicating with NT’s authentication. The NT authentication is substantially more difficult to break than a LAN Manager password hash. In fact, there are two versions of NT authentication, but either is sufficiently secure for today’s processing capacities.

Where to get your passwords
Once you know that the passwords are securely transmitted, you can move on to policy issues. Samba is flexible enough to allow you to use the local UNIX server, a stand-alone Windows server, a Windows 2000 domain, or an LDAP server to tell it which clients should and should not be allowed to connect to the server. Whichever option you choose, your Samba server will only be as secure as the system you’re using to authenticate users. In short, be careful of which systems you allow your Samba server to trust.

If you want your users to remember their passwords instead of writing them down in obvious places, it’s important to work toward a single sign-on by limiting the number of unique user names and passwords that they must use to access corporate systems. By using an existing username and password infrastructure, you can make Samba play nice with existing infrastructure.

Blank passwords
Perhaps it goes without saying that allowing your users to use blank passwords opens you up to a whole host of potential problems, but many organizations still allow blank passwords. Samba lets you encourage users to select a password by allowing the administrator to prevent users with blank, or null, passwords from connecting. This is done by adding the Null Passwords global attribute and setting it to No.

Just say no to share-level security
Samba offers the ability to set up what is referred to as share level security. In this mechanism, a share is assigned a password rather than requiring an authenticated user with a username and password combination to be authorized to a share. Although share level security can sound appealing for small environments, it is substantially less secure because everyone shares the same password. Not only is it easier for someone to discover a single password, it’s more difficult logistically to change the password when you have to notify several users of the change.

Limiting hosts
Another way that Samba will allow you to control who has access is to control the hosts from which they can connect. In fact, Samba has two ways of controlling access at a host level.

Pick the interfaces
If your Samba system has more than one network card installed, you can limit where Samba will answer requests. If, for instance, you have a network card installed on a private network and one connected to the public Internet because you’re also using the server for NAT, you can tell Samba to only answer requests from the private network.

This is done by setting the Bind Interfaces Only global attribute to Yes. This will tell Samba to only respond to requests on the interfaces that you specify. The next step is to specify the acceptable interfaces by adding an interfaces global attribute and specifying the interfaces to support. The interfaces attribute will accept the UNIX interface name or the IP address of the interface.

Allow hosts
The second way within Samba to control which hosts can get through is to use the Hosts Allow global attribute. This allows you to specify which hosts you want to allow access. This list of addresses can be address/subnet masks so that you can allow access to entire subnets at a time. For instance, if your private networks used the reserved Class A address (10.x.x.x), you could specify either 10. or to allow any computer that is on the private network access to the Samba server.

If you’re using DHCP and IP addresses but you want to limit access to a few hosts, you can list their host names in the Hosts Allow attribute instead. In addition, there is a Hosts Deny global attribute that allows you to deny access to a host.

Of course, you can also block the ports that are necessary for Samba to operate at a firewall level. This would effectively limit access to Samba from a machine on the other side of the firewall. If you want to use your firewall to prevent Samba traffic, you need only close ports TCP/135, UDP/135, UDP/137, UDP/138, UDP/139, and TCP/139. This will effectively kill off access to the Samba server—and any other Windows server inside your network.

No browsing
One of the ways that you can help to secure your system is to prevent users from knowing it exists. By stopping users from being able to even browse your system, you dramatically reduce the chance that it will be a target for attack.

It’s easy enough to turn share browsing off. One way is to simply make the browseable option set to No in each share section. You can also name a share with a trailing $. This is a standard Windows convention that prevents shares from being visible.

Alternatively, you can break all browsing connections by manually setting up the IPC$ share with a set of restrictions that prevent people from connecting to it. The IPC$ share is a hidden inter-process communications share that SMB uses for things like browsing. To prevent browsing for all shares, you can just create the IPC$ share section and put a hosts deny = You should also put a hosts allow = so the local computer can use the IPC$ share.

Simple virus protection
In most environments, the file shares that users have access to should not have executable files on them. File shares are there so that users can store their documents, spreadsheets, presentations, etc. Samba can be configured so that it doesn’t allow certain types of files to be stored on a file share. This is done with the Veto Files attribute in each share. The Veto Files option separates file specifications with the slash character (/) and supports the standard wildcard characters, asterisk (*) and question mark (?). If you wanted to disallow EXE files, COM files, or DLL files, you could have a veto files attribute that looked like this:
Veto files = /*.exe/*.com/*.dll/

This would prevent access to or storage of these types of files and effectively prevent a Samba server from spreading most types of Windows worms and viruses. You may want to veto other file types to effectively exclude all of the file extensions that are used by viruses to propagate.

Editor's Picks