Samba Logging for Audit Trails

Audit trails are a network security requirement for both Northrop Grumman and its customers. A small modification to Samba enabled the company's sysadmins to create the needed audit trails.

Creating custom log messages requires inserting DEBUG macros into the appropriate section of code and filling in the correct parameters and messages. Once the DEBUG statements are inserted, the Samba executables need to be rebuilt by executing make install in the samba-2.2.a/source directory; the dæmons are restarted with the command /etc/init.d/samba restart. Any new log messages added to the Samba source files now should appear in the log files.

Determining where DEBUG statements should be placed in the code may require setting various log levels in the smb.conf file. The output of the log files can help narrow down which source files should be examined for particular information. Using printf statements also may help in determining which variables should be logged and in formulating the final log message. If you do plan on using printf statements, smbd and nmbd should be executed without the -D option by stopping the dæmons with the command /etc/init.d/samba stop and executing /usr/local/samba/bin/smbd and /usr/local/samba/bin/nmbd on the command line. The printf statements then are directed toward standard output and appear on the console.

Listings 2 through 4 show custom DEBUG statements added to the Samba source code. Listing 2 shows DEBUG statements added to the source/rpc_server/srv_netlog_nt.c file for reporting failed and successful network logons. The first DEBUG statement reports when an unknown user attempts to log on to the network, and the second DEBUG statement records incorrect passwords. An additional DEBUG statement was added for installations of Samba using PAM. The final DEBUG statement records a successful logon to the network. By examining the log output from Listing 1, you should see a direct correspondence between each of the DEBUG statements and the generated log entries.

Listing 3 shows a DEBUG statement added to the source/smbd/service.c file to capture when a user has logged off the system by checking when a share to the user has been closed. Unfortunately, this is an unreliable check because the user always is dropping shares during the course of a session. There also is a short delay between the time the user logs off the network and when the dropped share is recorded. Determining when a user has logged off the network requires checking any logons to the machine after the last user share was dropped or checking whether the machine still is locked by the user.

Once Samba is logging the required information, you may want to clean up the log file by removing unnecessary entries. This can be accomplished by setting the log level to 0 in required DEBUG statements and setting the log level to 1 or higher for other DEBUG statements. The log level parameter in the smb.conf file then should be set to 0. The logging features of Samba make it easy to track down unwanted log entries by providing the exact location of the DEBUG statement. Cleaning up log.smbd makes the audits easier and less error-prone than a cluttered log file, such as the log file generated by a Windows 2000 server.

Updating User Passwords

When updating passwords, system requirements state that passwords must be at least eight characters long and the password change must be logged. In addition, we also wanted the passwords to be synchronized between Windows and Linux so users have common logins for both systems.

For the first requirement, the define statement in source/include/local.h, on line 175, was changed to #define MINPASSWDLENGTH 8. To ensure this change is captured in all the necessary source files, make clean should be executed in the source directory before executing make install.

The source code for verifying and updating password changes is located in the file source/smbd/chgpasswd.c. Listing 4 shows the DEBUG statement that was added to the end of the chat_with_program function to log when users successfully change their passwords. In addition to adding the capability to record successful password changes, the failed password updates also are logged. Failed password changes are recorded because regardless of why the password update failed, the following message always is returned to the user:

The User name or old password is incorrect.
Letters in passwords must be typed using the
correct case. Make sure the Caps Lock is not
accidentally on.

These log messages can help frustrated users determine why they are unable to update their passwords. However, access to these log messages requires assistance from the system administrator. Log entries 5 and 6 in Listing 1 present two examples of user bill being unable to change his password successfully.

To synchronize passwords between Samba and the Linux system passwords, set the following fields in the smb.conf file under the global section:

[global]
unix password sync = yes
pam password change = yes
passwd program = /usr/bin/passwd
passwd chat =*New*password* %n\n *new*password*
↪%n\n *successfully*

For most systems, the passwd chat field does not need to be set, because the default setting works fine. If the passwd chat field does need to be set, the syntax should follow the passwd command's input and output closely. The syntax for password chat is * for any character and %n for the new password; spaces designate new lines, and \n is used when user input is required. For further help with debugging, set the log level to 101 and the field passwd chat debug to yes in the global section of the smb.conf file. As a last resort, printf and DEBUG statements can be used in the function chat_with_program in the chpasswd.c file to help debug the problem.

______________________

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