September 2006

Issues to Consider Before Auditing a Linux Environment

Daemon configurations, system logging controls, and use of up-to-date patches are key areas IT auditors need to keep in mind when reviewing Linux-based operating systems.

Nelson E. Gibbs, CISA, CISM, CISSP
Senior Manager, Audit & Enterprise Risk Services
Deloitte & Touche

Many organizations are incorporating Linux operating systems to perform critical business operations. A March 2005 survey by Gartner Inc. found that 39 percent of organizations surveyed used a Linux system. Although Linux use was primarily focused on support operations, more companies are beginning to use Linux for mission-critical functions due to its flexibility, openness, and ability for customization. In spite of its increasing popularity, understanding the best way to audit Linux operating systems remains a mystery for many internal auditors. Besides understanding Linux file structures and how to access critical system files and locations, auditors should learn about different Linux concerns, including daemon and system logging configurations, as well as understanding the best ways to patch and maintain Linux systems. Doing so will help auditors be better prepared for a Linux audit.

DAEMONS — BEHIND THE SCENES WORKERS

Most Linux-host services are independent processes that start at boot time and run on their own, listening for user requests. These services become active whenever a user request is received, initiating a new process thread to service the request. After the request is completed, the host service goes back to a listening state until another request is made. Known as daemons — a computer program that runs in the background rather than under the direct control of a user — these processes are what most end users recognize as services run on Web servers (httpd), mail servers (SMPTD), file transfer protocol servers (FTPD), and so on.

Daemons typically have names that end with the letter d (e.g., syslogd is the daemon that handles system logging) and perform functions such as responding to network requests, handling program activities, and configuring hardware. Operating systems often launch system daemons when the computer is turned on through the use of settings in the /etc/inetd.conf file. Other daemons are initiated by their own scripts, which typically are found in the /etc/rc.d directory, or its subdirectories, for each of the system runlevels — the different operating levels the system goes through during the boot up process, including the single-user and multi-user modes and graphical-user interface. All active daemons can be located by using the ps -aux command, which lists the names of all running processes in the last column.

Oftentimes, services are started by default in a distribution — compilations of software, commonly called distros — and should not be used in a deployed production server. Auditors should review the /etc/inetd.conf file to ensure any unnecessary services are commented out — a technical programming term that stands for the use of a pound or hash sign (i.e., #) at the beginning of the configuration line for each unused service to disable it. These unused daemons have associated user accounts that can be found in the /etc/passwd file, such as www for httpd, mail for SMPTD, FTP for FTPD, and so on. Other typical default accounts include nobody, gopher, bin, news, daemon, and ntp.

Because these accounts commonly are configured by default and never removed, they are a frequent target of malicious attacks. Therefore, if a service is not used on a host, the associated user account should be removed. If the service is used, auditors should check to see if the account can be protected by preventing a direct login through the use of a shell assignment to /bin/false, /bin/none, or /bin/nologin in the /etc/passwd file. A shell is a command interpreter that enables users to interact directly with the computer, analogous to a DOS prompt.

System Logging Considerations
Modern Linux systems have strong monitoring, logging, and accounting capabilities. As a result, it can be difficult for auditors to know just what to monitor and log. For example, most logging is configured in the /etc/syslog.conf file, which establishes the level of system messages to be captured, the types of activities to log, and where to store the various log files. For the typical auditor, the most important concerns regarding logging are what is being logged, where the logs are stored, how the logs are archived and retained, and how they are being used and reviewed.

On most systems, logs are stored in either the /var or /var/log directory. When conducting an audit of system logs, auditors need to confirm the permissions on log files and directories are highly restrictive. This setting helps to prevent tampering or alteration of log files. In sensitive environments, log data should not be stored on the host system. Rather, the server should be configured to send information to a centralized syslog server that acts as a secure repository for archiving and legal purposes. Some of the more important logs are the syslog, which captures critical system conditions, errors, and warnings; the messages log, which captures general operating system messages and others generated during the boot process; the sulog, which captures successful and unsuccessful use of the su command; and the faillog, which captures unsuccessful logins after three unsuccessful attempts.

System accounting can be enabled to capture information related to running processes, CPU and memory use, network input and output activities, user-access activities, commands being run, and other system-related concerns. A common package found on most Linux distros is the account package, which can be used to enable accounting through the accton command. This utility typically stores its data in the /var/log/pacct file. Because excessive system accounting can impose a performance penalty on a server, auditors should work closely with the system administrator to determine the appropriate level of captured detail to support business requirements.

Patching and Maintenance Procedures
According to an article published in Network Computing magazine ("Software With Security in Mind," April 2004), the single-most important thing a company can do to build a secure enterprise is stay current with software patches. Security vulnerabilities are found regularly in all environments, and Linux is no exception. Consequently, it is imperative for every organization to have a well-defined patching strategy that takes into account a clear and comprehensive approach to patching, while also considering the impact of patching on business operations. Documented procedures for patching should be aligned with corporate policies and should provide clear guidance that states which patches need to be applied and when.

Many of the larger vendors such as Red Hat, Novell/SUSE, Slackware, Debian, Gentoo, and Ubuntu provide tools to simplify the process of patching and updating system software. Some of the more common are rpm, up2date, YaST, pkgtool, apt-get, and Portage. Auditors will find the best place to check for current patches and security advisories is the vendor Web site of the Linux variant used. Auditors also can keep abreast of recently discovered security issues by obtaining information from organizations that publish online vulnerability databases, such as Security Focus, www.securityfocus.com/archive; the SANS Institute, www.sans.org; and the Computer Emergency Response Team (CERT) Coordination Center, www.cert.org.

Furthermore, auditors should recommend that system administrators subscribe to their vendors' security mailing lists and actively evaluate these e-mails on a regular basis. This will help organizations stay up-to-date in their patching activities. To simplify the task of staying informed, auditors can recommend system administrators use the Cassandra tool provided by Perdue University, https://cassandra.cerias.purdue.edu/main/index.html. This site allows users to create a profile list of software they wish to monitor and sends a daily e-mail when a security notification is published on any of the security tracking sites.

MOVING FORWARD

Daemons, system logging considerations, and patching of Linux systems are some key considerations auditors need to keep mind before conducting reviews of Linux operating systems. Other issues auditors should address include the system's intended purpose and criticality; the IT staff's familiarity, education, and comfort level with the system; the risk to the organization of using a Linux system; and the role Linux systems play throughout the IT structure. Learning about Linux will help auditors be on the road to a trouble-free Linux audit, as well as enable them to provide recommendations that make better use of corporate IT resources and protect the organization's IT infrastructure.

LINUX RESOURCES

Internal auditors who are planning on conducting a Linux security audit should download the Starter Linux Checklist (PDF, 5KB), available on The Institute of Internal Auditors' Web site. Although the checklist is not exhaustive, it provides information that can help auditors start thinking about the main areas to review during the Linux security audit. In addition, there are many Web sites with Linux reference information. An extensive collection of Linux reference materials is available at the Linux Documentation Project Web site, www.tldp.org; the CERT Web site, www.cert.org/tech_tips/usc20_full.html and www.cert.org./tech_tips/win-UNIX-system_compromise.html; About.com, http://linux.about.com; Wikipedia, http://en.wikipedia.org/wiki/Unix; and the ISACA Web site, www.isaca.org (the site's Internal Control Questionnaire and Audit Program for Unix is also applicable for Linux).

Two commonly used tools for auditing Linux security are the Security Auditor's Research Assistant available at www-arc.com/sara/, and Nessus, a vulnerability scanner available at www.nessus.org. Because both tools have the potential to inflict damage on the systems they are run against (e.g, these tools may cause the system to stop responding or interfer with the processing of data), auditors should recommend that system administrators research the tools before using them in a production environment.

One of the best ways to become familiar with Linux and the features of the version in use is to obtain a bootable compact disk (CD) based on the same distro. System administrators can then run the CD on a machine to learn where everything is and what the default configurations are. Also, some bootable CDs are focused on security testing and can be quite useful in performing technical audits in their own right. These include:

Some government audit guides and tools are also freely available to the public, as well as research by various industry groups and consortiums. One government agency that has quite a bit of guidance is the Computer Security Resource Center of the U.S. National Institute of Standards and Technology. The resource center makes available the Defense Information Systems Agency Security Technical Implementation Guides, including a Unix guide that addresses Linux. The guides are available at http://csrc.nist.gov/pcig/cig.html.

Furthermore, the U.S. National Security Agency features several useful checklists and publications through its System and Network Attack Center, found at www.nsa.gov/snac/. The Center for Internet Security, www.cisecurity.org, is a nonprofit organization focused on promoting secure computing and developing benchmarking and scoring tools, some of which are based on government research, including tools for Red Hat, Slackware, and SUSE.

Finally, a good Linux Quick Reference Guide is available from the Linuxsecurity.com Web site, www.linuxsecurity.com/docs/QuickRefCard.pdf. (PDF, 72KB)

Nelson Gibbs, CISA, CISM, CISSP, is a senior manager with Deloitte & Touche LLP in its Audit and Enterprise Risk Services function, where he works with control assurance for financial services industry clients. Gibbs has more than 14 years of experience in information systems operations and management and is a frequent presenter and instructor on IT audit, security, and risk management topics for several international industry organizations.


COMMENT ON THIS ARTICLE

Internal Auditor is pleased to provide you an opportunity to share your thoughts about the articles posted on this site. Some comments may be reprinted elsewhere, online, or offline. We encourage lively, open discussion and only ask that you refrain from personal comments and remarks that are off topic. Internal Auditor reserves the right to edit/remove comments.

Name:

Email:

Subject:

Comment:


To make something bold:
<strong>Text to bold</strong>

To make something italic:
<em>Text to italicize</em>

To make a hyperlink:
<a href="URL">Text to link</a>

 

April 2014IaCover 

 IPPF_Ap42014

IIA Academic_Nov 2013

IIA SmartBrief

 Write for FSA Times

 

 Twitter

facebook IAO 

IA APP