Samba Logging for Audit Trails
We at Northrop Grumman recently decided to replace the Microsoft Windows 2000 server on one of our networks with a Linux server running Samba. The primary motivations for replacing the Windows server with Linux were:
Common user names and passwords for both Windows and Linux users.
Export commonly shared directories and files using NFS and Samba.
Allow software developers the freedom to choose their development environment.
No additional licensing fees required for Windows 2000 server and clients.
Centralized and cleaner audit trails.
A more secure computing environment.
Software upgrades can be scheduled when necessary as opposed to being dictated by outside software vendors.
In addition to configuring Samba as a primary domain controller, modifications were made to the Samba source code to meet the security requirements of our network. This article briefly describes how to install and configure Samba and then explains in detail how to modify Samba source code to produce log entries required for audit trails.
Our networks must be configured to meet corporate and customer requirements regarding security. Among the various security requirements that must be met, administrators need to have the ability to audit activity on the network. The required information gathered and logged for these audits is referred to as an audit trail and include the following information: successful logins, logouts, failed logins and password changes.
Most operating systems generate log files with this information, but it may be scattered in a number of different files and contain more information than is necessary. We also wanted to centralize this information so network administrators do not have to examine the logs on every computer on the network. Configured properly, a Windows 2000 server logs the above information for all machines connected to the network, in addition to reporting a myriad of extraneous information. This additional information makes security audits longer, more error-prone and also occupies a lot of disk space when archived.
In order to use Linux and Samba as the primary domain server for Windows 2000 clients, Samba has to duplicate the logging capabilities of the Windows 2000 server. Once Samba was configured for the network, it seemed the only way to meet the logging requirements was to modify the Samba source code. An additional benefit of modifying the source code was the ability to have only the necessary information recorded in the log files. The replacement of the Windows 2000 server with Samba would not have been possible had Samba been a closed-source, proprietary product.
The Linux server initially arrived with Red Hat 8.0 and Samba already installed. The first step was to download the tarred and compressed version of Samba 2.2.8a from the Web site, www.samba.org. Once downloaded, Samba was installed by running the following commands as root:
tar cvfz samba-2.2.8a.tar.gz cd samba-2.2.8a/source ./configure make make install
The Samba executables, smbd and nmbd, were installed under the /usr/local/samba/bin directory. The Red Hat installation had placed these executables under the /sbin directory. Using the newly created Samba executables requires changing the Samba startup script /etc/init.d/samba. The current Samba dæmons should be stopped first by running the command /etc/init.d/samba stop.
The /etc/init.d/samba file then is edited such that the commands for starting smbd and nmbd are changed from /sbin/smbd -D to /usr/local/samba/bin/smbd -D and /sbin/nmbd -D to /usr/local/samba/bin/nmbd -D. The new dæmons are then started with the command /etc/init.d/samba start.
Once the new dæmons are installed successfully, Samba needs to be configured by setting parameters in the smb.conf file. For the 2.2.8a distribution, the default location of this file is /etc/samba. The smb.conf file consists of sections denoted by square brackets, and each section names a share or service. The following example shows some of the parameter values set under the global section to create a Primary Domain Controller for Windows clients:
[global] netbios name = SambaServer workgroup = NETDOMAIN domain master = yes local master = yes preferred master =yes os level = 65
For authenticating users on the network, the following parameters also need to be set under the global section:
encrypt passwords = yes security = user domain logons = yes
Finally, for Windows 2000 clients, the domain admin group and add user script global parameters need to be set as well:
domain admin group = root add user script = /usr/sbin/useradd -d /dev/null \ -g 100 -s /bin/false -M %u
Public and private shares for Window clients are created by adding new sections.
[share] path = /home/share read only = no browseable = yes guest ok = no create mode = 0770 comment = Shared Folder hide dot files = yes
[homes] path = /home/%u read only = no browseable = no guest ok = no map archive = yes create mode = 0750 comment = Home Directories hide dot files = yes
To verify that the parameters are correct in the smb.conf file or to debug configuration problems, use the testparm command. For debugging problems with Samba in general, the log files log.smbd and log.nmbd under the /var/log/samba directory are invaluable. The parameter log level in the global section of the smb.conf file determines the amount of detailed information Samba writes to the log files, with level 0 being the most general and 10 being the most detailed. Each logging level contains the messages from that level, in addition to the logging messages below it. For example, a logging level of 5 contains messages from level 5, plus those from levels 0 through 4.
Listing 1 is an example from the log.smbd file. The first line in a typical entry in the log file contains the date and time the event occurred, the source file name, the function name and the line number where the message was generated. The second line contains the action that occurred, the domain and client name and a short message describing the logging event. Later in this article, we examine how these messages are generated in the Samba source code.
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
- Peppermint 7 Released
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Sony Settles in Linux Battle
- Libarchive Security Flaw Discovered
- Maru OS Brings Debian to Your Phone
- Understanding Ceph and Its Place in the Market
- Profiles and RC Files
- Snappy Moves to New Platforms
- Git 2.9 Released
- The Giant Zero, Part 0.x