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.
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- The Firebird Project's Firebird Relational Database
- Stunnel Security for Oracle
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Google's SwiftShader Released
- SuperTuxKart 0.9.2 Released
- Doing for User Space What We Did for Kernel Space