How To Harden An Hp Server For A Long Time

Transcription

1 Linux Security on HP Servers: General Security Topics Technical introduction This white paper discusses general security technologies available in Red Hat Enterprise Linux (RHEL) and SUSE Linux Enterprise Server (SLES). The methods, techniques, and technologies discussed in this white paper can be used to harden the security of HP servers running RHEL and SLES by helping you understand what can be done to better secure data, manage users, and audit system activity. Abstract You can use the power and flexibility of Linux to greatly enhance security in many ways. This series of white papers discusses how to take full advantage of the many security features available in the Red Hat Enterprise Linux and SUSE Linux Enterprise Server operating systems, to ensure your servers and data center are as secure as possible. This white paper, General Security Topics, covers how to secure files, file systems, and disk volumes. It also covers user account management and event auditing technologies. Intended Audience This white paper series is intended for administrators of HP servers deploying Linux-based operating systems and who need to better secure those environments. This white paper series will help you to do the following: Gain a greater understanding of the full arsenal of security tools that the Red Hat Enterprise Linux (RHEL) and SUSE Linux Enterprise Server (SLES) operating systems provide Evaluate Linux on HP servers to determine security capabilities Compare security technologies against what is available on other operating systems

2 Table of Contents Abstract... 1 Intended Audience... 1 Table of Contents... 2 Overview... 3 Introduction... 3 Secure System Configuration... 4 Basic System Configuration... 4 Partitioning Disks... 4 Configuration Hardening Tools... 5 File System Permissions... 5 Selecting System Services... 7 Installing and Updating Software Packages... 9 Software Updates and Patch Management... 9 System Integrity Verification Managing User Accounts Essential Password Strength Enforcing Password Policy Configuring PAM to Enforce Security Policies Securing the User Environment Setting the Default User Settings Protecting the Superuser Environment Protecting the Superuser s Execution Path Limit Network Access to Privileged Accounts Access Control Tools Securing Remote Logins Monitoring and Event Auditing Security Event Auditing Understanding the Linux Audit Subsystem Working with Audit Logs Writing Audit Rules HP Compliance Log Warehouse Summary For more information Additional Linux Security Resources... 21

3 Overview Introduction Unless your server is locked in a computer room and not connected to any network, it is potentially vulnerable to unauthorized access. Unless your information is properly secured, it might be retrieved, deleted, or altered by intruders. There are many technologies available to secure Red Hat Enterprise Linux and SUSE Linux Enterprise Server operating systems. Security needs are specific to every system. They are determined by many factors, including the following: The types of information stored on the system Who is using the system Whether users of the system log in, or use the system as a server on a network What types of networks the system is attached to The performance needs of the system Best Practice: Certain security configurations have the potential to impact performance. There is effectively a sliding scale with Absolute Performance on one end and Absolute Security on the other. To maximize performance, apply the appropriate amount of security by using only those technologies that are sufficient to meet your security needs. To maximize the security of an HP Linux based server, you must configure it properly. This white paper will guide you through the many options you have to configure your server securily. Recommendations covered in this white paper include: Regularly installing the latest available operating system and application software patches to ensure you are running the latest available security patches. Carefully controlling access to superuser accounts. You can delegate specific tasks to other users without sharing the superuser (root) password. Enforcing a good password policy to ensure that all of your user accounts have strong passwords that are changed regularly. Hardening your server file systems by ensuring permissions are properly set so that access to each file, directory, and file system is restricted to only those users who must have it. Encrypting sensitive data so that if your information is accessed without proper authorization, it will be difficult for the intruder to use it. Restricting the number of services your server provides to only those that are essential for its operation. Auditing and logging events on your server so that if intrusions do occur, you can determine what was compromised, when, and by whom. Using an intrusion detection system to regularly verify that your server s installed software packages and their associated configurations have not been altered. Other important security recommendations covered by the other white papers in this series include: Securing your server s network boundary by running a properly configured firewall. This and other important networking recommendations are discussed in the white paper, Linux Security on HP Servers: Securing the Network Boundary. 3

4 All these recommendations are important, but probably the most effective thing you can do to secure your server is to: Ensure that you are using a mandatory access control system (SELinux on Red Hat Enterprise Linux, or AppArmor on SUSE Linux Enterprise Server), configured and running in enforcing mode. For information about SELinux, see Linux Security on HP Servers: SELinux. In general, follow these rules: Do not run anything that is not essential. Tightly control network access. Isolate processes and users from each other so that they can access only those system resources that are necessary to function. Log all activity in case you need to reconstruct a chain of events. Encrypt sensitive information to limit its exposure if your system is compromised. While all systems, including workstations and PCs, can benefit from many of the recommendations in this white paper, this paper focuses primarily on servers found in large data centers. These servers frequently serve many users over large geographic areas, require nearly 100% uptime, often contain sensitive and personal data that must be protected (in many cases, by law), and are frequently targets of malicious attacks. Secure System Configuration Even before addressing the issues associated with network access to an HP Linux-based system (covered in Linux Security on HP Security on HP Servers: Securing the Network Boundary), there are many things you can do to make your system more secure. Basic System Configuration This section covers basic tasks you should perform to control access to your system resources and to minimize what an attacker (or an inadvertent accident) can damage. These tasks include partitioning disks to appropriate sizes, setting appropriate permissions on key files and file systems, and minimizing which services are running. Partitioning Disks A key technique of server security is that of compartmentalization: keeping users, files, and processes isolated (contained within the smallest possible space that enables them to accomplish what they legitimately need to do). This minimizes the amount of damage that can be done if something (or someone) goes awry. The Importance of Separate Partitions Because modern storage devices can contain very large amounts of data, an entire storage device is often too large a compartment for most needs. These devices (or pools of storage devices) can be divided into multiple virtual devices using a volume manager or the storage device itself. By partitioning large devices into smaller virtual devices, you isolate (and therefore protect) various functions on your system, minimizing the damage that might be done if one of the partitions fills up. For example, by isolating logging and spooling locations from the root partition, the system (which requires available space in the root partition to keep running) will not fail if the partition containing the log and spool files fills up. 4

5 However, too many partitions can become difficult to manage, so only create partitions for directories that you consider critical to isolate. At a minimum, use separate partitions for: / Root directory of the system (must have 10% space available for proper function) /boot Directory used to store kernel files that are used to boot the server /var Directory used for spooling, logging, and administration files (isolates logging and spooling functions) /home Directory used to store users home directories (if your system has interactive users that log in) Other directories that you might consider creating partitions for include: /tmp and /var/tmp Temporary directories for the system Directories requiring specific types of file systems or raw device access Directories containing data critical to your operation Partitions can fill up through normal usage, or because an intruder is deliberately trying to disable your system by intentionally filling a partition. Size your partitions appropriately to enable expansion over time due to normal usage and implement as much security as is appropriate for the system to minimize the chances that an intruder will deliberately fill a partition. HP managed installation tools, and most installers, will suggest appropriate and useful sizes for key partitions during the installation process. Though partitions can be resized if space exists on the associated devices, some (such as the root partition) cannot be resized without rebooting the system. You should create these partitions during the installation process using installer-based tools. You can use partitioning tools to create non-system partitions and make limited adjustments of the sizes of system partitions later. Configuration Hardening Tools There are many components to Linux security, and many things to configure. Configuration hardening tools facilitate the process and help ensure that you have not overlooked something important. Secure System Configuration with Bastille Security configuration can often be intimidating. Many administrators avoid doing all that they can to secure a system because they fear that doing so might prevent their systems from running properly. An open-source hardening tool called Bastille addresses many issues raised by security scanning tools (for example, file permissions, whether a system requires secure passwords, and whether insecure services like rlogin and telnet are running). Using a friendly and interactive process, Bastille guides you through the process of securing your system, editing many key configuration files based on your answers. You can run Bastille at any time, to verify your configuration and look for additional (current) opportunities for securing your server. If you have multiple systems to configure in a similar manner, you can answer Bastille s questions once and have it save the configuration choices to a file that enables you to replicate the configuration on another system without having to reenter the answers. File System Permissions You can protect file systems and their data in several ways. Individual file systems can be protected by mounting them with special options that limit what can be done with their contents, and by whom. You can protect files and directories on those file systems by properly configuring permissions, ownership, and group ownership, or by using other security mechanisms such as encryption and mandatory access control. 5

6 Protecting File systems with Mount Options It is important to control who can access the file systems on your server, and how. For example, a file system on an external USB drive or CD-ROM might contain executable code that could compromise the security of your server. You should restrict the ability to mount portable media like USB drives or set options in the /etc/fstab file to restrict what can be done with a file system on such devices once it is mounted. You can also protect file systems with AppArmor and other mechanisms. The Linux mount command has many options you can use to mount file systems. For a complete list of them, see the mount(8) manpage. The following options will be useful to you in securing your server. Use the appropriate combination of these (either in /etc/fstab entries or when manually mounting a file system using the mount command) to limit access to those who must have it. Option nodev noexec nouser ro nosuid context noauto Recommended usage Prevents the interpretation of device files located within the file system to be mounted. This option should be used for removable media. Prevents binaries located within the file system to be mounted from being executed. Depending on the purpose of your server, you should probably not allow files to be executed by unprivileged users from any of the following file systems: File systems located on USB thumb drives (a good source of unknown and potentially harmful software). System temporary directories (for example: /var/tmp, /tmp). These directories are primarily for temporary data files. Users home directories. Unless your server is used for experimental or development purposes you should carefully control what software is run on it. Allowing users on your server to download software into their home directories and run it provides an avenue for potential malware to cause your server harm. Prevents ordinary users from mounting a file system. Though this is the default, it is good practice to explicitly use this option, especially for file systems containing sensitive data. Mounts a file system as read-only. If you have file systems that do not require write access, use this option to ensure that files on those file systems are not altered. Prevents executable files on a file system from being run with the set-user-id and set-groupid bits in effect. This option should be used for removable media. Sets the SELinux context for directories and files on file systems that do not support the extended attributes required to fully implement SELinux. For additional information on SELinux, see the white paper Linux Security on HP Servers: SELinux. Prevents a file system from being automatically mounted when the mount a command is executed. This requires the explicit mounting of a file system, preventing inadvertent and unnecessary mounting of a file system. Setting Permissions on Important Files and Directories You can protect files and directories by carefully assigning ownership, group ownership, and permissions to restrict access to only those users and applications that require access. Certain permission bits can allow an application, while it is running, to assume the identity of another user. Known as the SETUID and SETGID bits, these can give dangerous and often unnecessary power to ordinary applications, especially if the running process is able to assume the identity of the root user. Unless an application must run under an identity other than that of the user who started it (for example with the power of the root user), do not allow the permissions for its executable file to include the SETUID (and SETGID) bits. 6

7 Checking the Status of the SETUID and SETGID bits on a file To check whether or not the SETUID and SETGID bits of a file are set, use the long form of ls (the l option): # ls -l -rwxr-xr-- 1 ali users 70 Sep 1 20:22 program1.a -rwsrwsr-x 1 root root 70 Sep 1 20:15 program2.a In the above ls output, program1.a does not have its SETUID and SETGID bits set. The execute bits in the file s mode are listed with the symbol x for the owner and group portions, and - for others. If user sally, a member of the group users, were to run program1.a, the running process will have Sally s user and group access permissions. This is because the file SETUID and SETGID bits are not set. This is represented by the first and second x in the first line of the above output, respectively. However, if user sally, a member of the group users, were to run program2.a, the running process will have root s user and group access permissions. This is because the SETUID and SETGID bits are set, and the ownership and group ownership are set to root. This is represented by the first and second s in the second line of the above output, respectively. Note: Although the SETUID and SETGID bits are often either both set or both cleared, they can be set independently. For complete details on permissions and ownership, see the chmod(1) manpage. Clearing and Setting the SETUID and SETGID bits From a security perspective, you will probably more frequently clear SETUID and SETGID bits from files that do not require them than you will set them. To clear the SETUID and SETGID bits from a file: # chmod u-s program2.a ( u-s tells chmod to subtract/remove the SETUID bit) # chmod g-s program2.a ( g-s tells chmod to subtract/remove the SETGID bit) # chmod ug-s program2.a (you can combine the two commands, see chmod(1) for details) To set the SETUID and SETGID bits, replace the minus signs in the above commands with plus signs: # chmod ug+s program2.a Selecting System Services Processes known as daemons are always running in the background on a Linux server, listening for service requests. The services these daemons provide represent potential points of attack. Because daemons provide services, the terms daemon and service are often used interchangeably. Depending on your server s purpose, many of these services might be unnecessary. For example, if your system does not have interactive users (users who log in), you do not need to run the network login daemon called sshd. 7

8 Best Practice: By eliminating unnecessary services you limit opportunities for attack. And, with fewer services running, the performance of your system should improve as well. Run only what is necessary. System services can be configured using several different tools, but it is best to pick one tool and stick with it to eliminate potential problems with tool interactions. Many services, when enabled, are always present in the background. Their daemons are always required to run when the service is enabled. Some daemons can be started and stopped by a master daemon called xinetd. They only run when needed, saving processor cycles and memory. For additional information about these services, see the xinetd(8) manpage. Services can be enabled or disabled using the following tools: System Services Configuration Tool Tool Information chkconfig Can show summary of all services and their status at each system run-level. Summary includes xinetd based services See the chkconfig(8) manpage for detailed information. system-config-services Available on Red Hat Enterprise Linux. Graphical user interface: a front-end to the chkconfig command. Provides short descriptions and current status of each service on request. See the system-config-services(8) manpage for detailed information. yast2 runlevel Available on SUSE Linux Enterprise Server. Graphical user interface provides the ability to manage standalone services. Provides short descriptions and current status of each service. See the built-in help for detailed information yast2 inetd Available on SUSE Linux Enterprise Server. Graphical user interface provides the ability to manage xinetd services. Provides short descriptions and current status of each service. See the built-in help for detailed information Removing Unneeded Services To prevent services (daemons) from running, do one of the following: For services that are started when the server is booted, use the Background Services tab in the system-config-services utility (or the chkconfig command) to reflect only the services you want to start at boot time. For services that are started by xinetd as your server is running, use the On Demand Services tab in the system-config-services. 8

9 Installing and Updating Software Packages Software (both operating system and application packages), no matter how well written, can contain defects that create security vulnerabilities. As vendors update their products, they fix known defects and eliminate vulnerabilities. For this reason, you should regularly update the software packages on your server. Software Updates and Patch Management There are ways to automate the process of checking for and (if you choose) installing updates. You can configure automatic updates using the Red Hat Network or using Novell s online software repositories and SUSE Linux Enterprise Server YaST tool, you can use the HP Insight Control Environment, or you can use a combination of the two. You can also manually check for and apply updates if you prefer more control over when and how often you perform updates. The important thing is to regularly search for, download, and install updates and patches for your operating system and application software. Configuring Automatic Updates Both Red Hat Enterprise Linux and SUSE Linux Enterprise Server provide mechanisms to help automate the process of keeping your system patched and current. On Red Hat systems, the Red Hat Network ( contains a module that you can use to schedule automatic updates for each of your HP Red Hat Enterprise Linux systems. You can set it up to automatically download and install patches that are issued by Red Hat so that you can ensure your systems are running the latest versions of all installed Red Hat Enterprise Linux packages. On systems running Novell SUSE Linux Enterprise Server, you can use the YaST management tool to automatically download and install updates from Novell online software repositories at regular intervals. From a security perspective, ensuring that your software is up-to-date is critical; and if completely automating that process (unattended updates) helps you to regularly do this important task, then you should schedule them. But, there is a disadvantage to completely automating this process. Even if you ensure your software updates are coming from a trustworthy source, sometimes problems can occur with an update that can negatively affect your server s operation (or security). It is better to schedule automatic reminders. Instead of automatically updating your server with the latest software, the Red Hat Network will notify you when critical updates are available. Then, you can determine when (and whether) to install them. If you have non-red Hat software packages installed, talk with the vendor to see if the vendor offers automatic updates and configure them, if possible. Best Practice: Keeping your OS and application software up to date is critical, to be sure that you have the latest security patches and bug fixes installed. Equally important is to know, with certainty, that all of your software came from the proper source and has not been modified between the source and your server. This is especially true if you configure your system for automatic updates. For information regarding how to ensure package integrity, see System Integrity Verification. 9

10 HP Insight Control Environment If you use the HP Insight Control Environment for Linux to manage your systems, you can receive proactive, automatic updates for the Insight Control software from HP. HP Insight Control Environment for Linux (ICE-Linux) is a software suite for managing multiple systems from a single location. It is an ideal tool to use to automatically update a series of HP Linux based systems. System Integrity Verification You must keep your server software up to date and know with certainty that each installed software package came from the proper source and has not been modified between the source and your server. Configuring automatic updates will help ensure that your software is current (so that you do not forget to regularly perform this important task), however, using automated updates increases the risk that something will get installed on your system from an unintended source (though this risk is probably lower than the risk of not performing regular updates). Performing unattended updates makes the verification of software package integrity even more important. Verifying Application Package Integrity The RPM package manager, one of the primary tools for installing software on a Red Hat Enterprise Linux or SUSE Linux Enterprise Server system, has a verification option that compares key attributes of the installed software against the contents of the original packages. Differences are flagged and might tampering. The following command verifies all of the installed packages on your server: rpm --all --verify NOTE: Even if you use a full-featured software manager (for example, yum on Red Hat Enterprise Linux, or zypper on SUSE Linux Enterprise Server) to manage the software on your server, you can use RPM to verify package integrity. Using Intrusion Detection Systems Intrusion detection systems monitor servers for signs of tampering. Both Red Hat Enterprise Linux and SUSE Linux Enterprise Server ship with an intrusion detection system called AIDE. Making an Initial System Snapshot You should use AIDE to take a snapshot of your server immediately after you install the operating system and after making any important changes. Ideally, this should be done before attaching your server to an untrusted network and before granting users access to the server for the first time. Also, if possible, store the snapshot on a different server for extra security. The snapshot consists of various types of checksums, digital signatures, permissions settings, timestamps, and other criteria that you specify. To create the snapshot: 1. Edit the AIDE configuration file /etc/aide/aide.conf as described in the aide.conf(5) manpage. 2. Initialize the database using the command: # aideinit aideinit builds the snapshot and stores this (by default) in the directory: /var/lib/aide. 10

11 Comparing the Current State Against a Previous Database After you have the initial snapshot, you can (at a later date/time) use AIDE to compare it against the, then current state of the system. AIDE will report what has changed so that you can investigate whether or not the changed files represent a problem. To perform the comparison, use the command: aide --check Managing User Accounts Regular account maintenance is critical to the security of your systems. You need to know at all times who can access your systems and ensure that they are authorized. Best Practice: Remove accounts that are no longer required (especially those of users no longer authorized to access your systems). Use password aging to require that authorized users of your system change their passwords on a regular basis. Ensure that all accounts on the system have passwords (or use a central authentication service such as LDAP). Essential Password Strength You need to be sure each user on your system has a password that cannot be easily cracked. This is important for all accounts on the system and absolutely essential for a superuser account. Strong passwords have the following characteristics: Are at least 12 characters long Have a mix of uppercase characters, lowercase characters, numbers, and symbols Are not based on dictionary words Longer passwords, with a mix of characters and not based on dictionary words are harder to crack. Enforcing Password Policy Often, the users on a system represent the weakest link. Unless forced to do otherwise, many people will chose a password that is easy to guess or hack, giving potential intruders an easy target to gain access to your server. Enforce good password practices by requiring users to choose strong passwords and requiring them to change their passwords on a regular basis. A technology called Pluggable Authentication Modules (PAM) can help you enforce a password policy on your server. 11

12 Configuring PAM to Enforce Security Policies PAM provides a mechanism for applications and services to consult to determine whether a user is authorized to take certain actions. There are four control stages (called module interfaces) that applications can use to determine authorization. The stages are listed in the following table: Module Interface auth account password session Description Requests and validates passwords or sets credentials based on other validation tools (group memberships, Kerberos tickets, biographic scans, and so on). This module interface validates user identity. Checks for permission to authorize based on expired accounts, time of day, and other similar items. Controls the setting/changing of user passwords. Configures session-related items such as the mounting of home directories, making user mailboxes available, and session recording session start and end times. You create authentication rules to configure authentication requirements for PAM-aware applications (applications that are written to interface with the PAM libraries). By using PAM, you can change and evolve your authentication methods and mechanisms for PAM-aware services as your needs change without having to recompile or rebuild the applications. A full description of how PAM works is beyond the scope of this white paper, but useful resources for PAM information include the PAM(8) manpage (note: upper case PAM), and the documents listed in Additional Linux Security Resources at the end of this paper. Best Practice: PAM (Pluggable Authentication Modules) is an extensible, flexible tool for configuring many aspects of Linux operation that require authentication (not just login permission). An application or service must be written to be PAM-aware in order to use this technology, but many utilities in Linux are. Refer to a directory listing of the directory /etc/pam.d to see which utilities are PAM-aware. Ensuring Strong Passwords You can use PAM authentication, or another password mechanism, to ensure users choose passwords that meet minimum requirements. The PAM module pam_cracklib.so contains the mechanism for password enforcement. This module is called from the system authentication module /etc/pam.d/system-auth using the following entry: password requisite pam_cracklib.so try_first_pass retry=3 This entry will try to obtain the password from previous entries in the PAM configuration stack, and will prompt the user to enter one if it is unsuccessful (try_first_pass). The user will have three tries to successfully enter a new password (retry=3). The default settings for pam_cracklib.so ensure a basic security level (ensuring that passwords are not dictionary words, that they are not palindromes, and that they are at least five characters long). For 12

13 security sensitive systems, the minimum acceptable password length should be increased. For example: to require a minimum length of 12 characters in a password (as recommended in the bullet list above), change the entry to read: password requisite pam_cracklib.so try_first_pass retry=3 minlen=13 The number 13 is used, instead of 12, to compensate for the crediting system used in pam_cracklib.so. Users receive length credits for passwords containing a mix of character types (UPPERCASE, lowercase, numbers, and symbols). For additional examples, and more details, see the pam_cracklib(8) manpage. Important: This PAM password entry is contained in the file /etc/pam.d/system-auth, which also contains the message: # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. If you directly edit the file at this location and someone runs the authconfig command, your changes will be lost. More accurately, /etc/pam.d/system-auth is a symbolic link that points to the file containing the actual system authentication entries: /etc/pam.d/systemauth-ac. If you point the symbolic link to a different file (for example, one you create), authconfig will not overwrite your file contents. To ensure that any changes you make to system-auth will be retained, do the following: 1. Make a copy of system-auth-ac to a new file in /etc/pam.d: # cp /etc/pam.d/system-auth-ac /etc/pam.d/system-auth-custom 2. Make your changes in your new file. 3. Point the symbolic link to the new file: # ln s /etc/pam.d/system-auth /etc/pam.d/system-auth-custom Limiting Password Lifetime You can use the utility system-config-users (select a user, then use the Password Info tab to set the information) or the command chage (see the chage(1) manpage for details) to limit how long a user s password can be used before requiring the user to change it. Securing the User Environment Beyond good password policies, there are other elements of users environments that you should control. Setting the Default User Settings When a user creates a new file or directory, the file is given access permissions based on a umask. The umask specifies which access bits should not be set. If possible, the default umask for users on your server should be 077, which makes files readable, writeable, and executable by the user who created them. No other user on the system is given any access permissions to the newly created files unless the user subsequently changes this. If a umask of 077 proves too restrictive, you could consider a umask of 022 which adds read and execute permissions (but not write permissions) for the other users of the system. For detailed information about umasks, see the manpage umask(1). 13

14 Protecting the Superuser Environment There are no limits to what a superuser (an account with a user ID of zero) can do. Anyone with superuser capabilities can read and modify files and directories anywhere on the server. If someone gains unauthorized access to the superuser account on your server, that person can: Change the superuser password (preventing authorized access by you) Reconfigure your system Install malware Gain access to any nonencrypted information on your system For these and other reasons, it is critical that you protect your server by carefully controlling who has access to superuser accounts. Define only one superuser account on a system (usually called root ). Protecting the Superuser s Execution Path When someone is logged into an account with superuser capabilities, it is important to control which applications the user runs, and from where the applications come. Ideally, superusers should be in the habit of specifying full pathnames to the commands they run, but this is often not practical. When full pathnames are not used, the shell will use the PATH environment variable to get a list of directories to search for the application or command the user is attempting to run. The shell searches the directories in the order they appear in the PATH variable and runs the first instance of a command or application that it finds. Depending on the value of the PATH environment variable, code might therefore be run from a place other than what is intended by the user, and this code might be malicious. Best Practice: Because the superuser is often in directories of other users (to fix problems, or administer local files), do not include the current working directory (represented by a single period. in a PATH directory list). Ensure that there are no empty elements in the PATH variable. They are also interpreted as use the current working directory. Empty elements will show up in PATH definitions as two consecutive colons :: or as a leading or trailing colon (PATH=/bin: or PATH=:/bin). To see the current path value, use the command: echo $PATH All directories in the superuser PATH should also be not group-writeable and not world-writeable. Important: Protecting the superuser s execution path applies to all users. Someone can plant nefarious versions of system commands in the /tmp directory (for example, an altered version of the sudo command that silently sends the password information your users enter to the person who planted the code and then proceeds as usual). If the /tmp directory appears in a normal user s execution path before /usr/bin (the location of the official sudo command), the altered version runs with all the consequences intended by its author. Limit Network Access to Privileged Accounts If possible, limit root access to only the system console (or the minimum number of devices required). Do this by editing the file /etc/securetty, removing any entries that are not required, ideally leaving only the entry for console. 14

15 To prevent network logins directly to the root (or other superuser) account if your server provides for ssh logins over a network, add the following line to the /etc/ssh/sshd_config file: DenyUsers root This forces users to log in using an ordinary user account and then gain access to root privileges through other means (like the su or sudo commands). Access Control Tools Minimize how many users have access to superuser capabilities by using one or more tools that enable you to delegate specific capabilities (for example rebooting the system, or restarting the line printer spooling system) without giving those users control of the entire server through the superuser password. The sudo tool enables system administrators to delegate specific duties to selected users that would not normally have the ability to perform those duties. Use the visudo command to configure sudo to delegate system administration duties. The Role Based Access Control (RBAC) feature of SELinux provides even greater control over which users can perform which tasks on your server. With RBAC, users are assigned roles with specific capabilities, for example restarting a web server or adding users to the system. To perform specific tasks users must be assigned a role that enables them to perform those tasks. For additional information on RBAC, see Linux Security on HP Servers: SELinux. Securing Remote Logins It is important to carefully control who can remotely log in to your server. Minimize remote logins so that only users who absolutely need remote access can have it. In addition to controlling which users can log in to your server, you must also control which protocols they use to log in. Utilities like rlogin, telnet, and ftp use unsecured communication. Unless you are using them inside a secure tunnel or using a Kerberized version of these tools, do not use them. They transmit data, including passwords, in the clear. To prevent their use, do not run the daemons associated with these unsecured protocols on your server. Instead, require your users to use secure protocols such as SSH (and its SFTP file transfer capabilities that mirror FTP, but in a secure way). For more information on securing remote network access, see the white paper Linux Security on HP Servers: Securing the Network Boundary. Do not use guest accounts (where a single account and its password are shared among multiple users) on your server. Authorized users of these accounts often share the passwords with unauthorized users and little or no accountability exists if caused a problem occurs. Monitoring and Event Auditing HP Linux servers have subsystems for monitoring and auditing many aspects of system activity, including security. Security Event Auditing A key part of maintaining a secure system is to regularly monitor the activity occurring on that system to be sure that the security measures you deployed during configuration are working and to determine if you need to make any changes, especially as your operational needs evolve. To do this, you need to examine the activity of the system s users and applications. The examination process is called auditing. By regularly auditing the user and application activity on your system, you can also detect intrusion attempts quickly and take appropriate defensive action to prevent or limit damage. 15

16 Understanding the Linux Audit Subsystem Linux is equipped with an auditing subsystem to help you observe the activity on your system. For performance and security, the auditing subsystem begins with a kernel component. The kernel component captures system events and generates audit event records using a set of audit rules supplied by the auditctl utility. At boot, auditctl reads a set of rules from the file /etc/audit/audit.rules and configures the audit kernel component based on these rules. The audit rules specified in audit.rules are persistent and used every time the system is booted. Administrators can also use the auditctl utility directly on the command line to add or remove audit rules while the system is running. However, the rule changes made from the command line are temporary and will not be restored when the system is restarted. Figure 1: Audit subsystem process flow An audit daemon, auditd, closely monitors the kernel auditing subsystem and the audit event records that it generates. When the kernel generates an audit event, the kernel communicates the information to auditd, which in turn writes the audit events to the audit log files. Two utilities, called ausearch and aureport, enable you to retrieve specific audit events from the audit log files or summarize audit data, respectively. For more sophisticated audit event handling, auditd can also supply audit data directly to applications that you develop using an audit multiplexer utility called audispd. NOTE: If you are running Novell s SUSE Linux Enterprise Server, you need to install and enable the plug-in called pwdutils-plugin-audit. Enable this plug-in by putting the string audit in the file /etc/pwdutils/logging. This plug-in is not needed with Red Hat Enterprise Server. 16

17 Comparison with Syslog In the normal course of operation, various Linux applications and subsystems need to relay general messages about what they are doing. The process of relaying these messages is known as logging whether it is used to report errors, record the arrival of or the printing of files, to identify significant work items completed, or for some other designated reason. To enable the capture and retention of log messages and to be able to sort the various types of log messages, Linux uses a logging subsystem called syslog. Syslog enables you to specify which log files will receive which types of messages. Typically, the files /var/log/messages and /var/log/secure contain the messages associated with security events, however the security messages logged to these files by syslog are not exhaustive or thorough, especially if you are using SELinux or AppArmor. Rather, they are basic operational messages related to Linux subsystems. Messages captured and recorded by syslog often originate in user-space and can be sent by any application regardless of privilege or intent; as a result, syslog messages are subject to tampering and false reports. However the mechanism used in auditing, where only the kernel and privileged applications can generate audit events, and all audit events are routed through the kernel to a daemon called auditd, is much more resistant to tampering and false reports. The audit subsystem is also designed to leverage the advanced security capabilities of SELinux and AppArmor; by isolating the audit logs to their own directory and only requiring write access for the audit daemon, it is much easier to ensure the integrity of the disk-based audit logs. What the Audit Subsystem Logs The audit subsystem is designed to log security related events. The types of events that can be logged include: SELinux and AppArmor policy violations User authentication System configuration changes Mounting and umounting file systems (especially from removable media) Opening, reading, and writing files key files Changing the permissions or ownership of key files Accessing the audit log files and other sensitive files related to security subsystems Changing the system time By using a set of rules to filter which events to audit, you can focus your auditing efforts on the specific types of events you are interested in. Working with Audit Logs The audit log files are usually stored in the directory /var/log/audit. In that directory, the currently active log file is called audit.log. Because audit log files can grow very large over time, you should rotate them. Configure the max_log_file_action setting in the auditd.conf file, as shown below, and force auditd to reread the file by either restarting it or sending the running auditd process a SIGHUP signal. max_log_file_action = ROTATE When logs are rotated, the current audit.log becomes audit.log.1. If it exists, the current audit.log.1 becomes audit.log.2, and so on up to the number of audit logs you specify (in auditd.conf) that you want to retain. A new audit.log file is then created and becomes the active log file until the next rotation. 17

18 Audit Log Format The audit logs written by auditd are comprised of entries of one or more lines. Each entry is the result of an auditable event (one that the audit rules require to be captured). For example, system calls are not single instructions; they are routines that execute in kernel space. Consequently, they have an entry, an exit and the potential for one or more recordable events in between. Each of the recordable events within the system call will result in a line of output in the audit file. A single line of output might not contain all of the information that is important to know about the system call being logged, but collectively all of the lines associated with a given system call should contain all the information you seek. The groups of lines pertaining to a single system call will all have a common event ID. Event IDs look like this: msg=audit( :1706) In addition to an event ID, each line of output in the log file has a number of fields. All output lines begin with a type field that determines the type of information that the rest of that line will contain. After the type and event ID, the remaining fields on each output line are a series of space-separated entries of the form: item=value Here is a typical output line in an audit log file: type=login msg=audit( :1691): login pid=19073 uid=0 \ old auid= new auid=0 old ses= new ses=205 Decoding Audit Logs and Report Generation Audit log files can contain thousands of lines like the output line shown in the previous section. This can make it difficult to identify the specific information you seek simply by looking directly at the logs. Some standard text filtering tools like grep can help, but there are better ways to sift through the data. A program called ausearch searches audit log files for events matching specific criteria. ausearch provides options to search for many types of records. Some of these include: Specific event IDs Specific event types File names (for example, if you placed a watch on a certain file see Watching Important Files ) SELinux contexts Date / time ranges User IDs / User names Specific words Executable names When ausearch reports its findings it reports all of the lines associated with each selected event (all of the lines having a common Event ID). By doing this, ausearch enables you to see all of the information associated with a given system call. Using a tool like grep might not yield all the information you need to evaluate (or discover) a problem. If you are interested in summary information, rather than entire record dumps, you can use aureport instead of ausearch. Like ausearch, aureport has many options. For example, you can summarize entries by: Files Users Terminals System calls There are many other options as well. See the aureport(8) manpage for complete details. 18

19 Writing Audit Rules Audit rules are supplied to auditd using the auditctl command. auditctl takes its input from two places: 1. The file /etc/audit/audit.rules. 2. auditctl commands issued from the command line by an administrator. For rules that you want to have active with every boot, or every run of auditd, edit the /etc/audit/audit.rules file with the rules. For rules you only want active temporarily, enter them from the command line. Here some example output lines from an aureport command: # aureport -s Syscall Report ======================================= # date time syscall pid comm auid event ======================================= 1. 02/19/ :48: setsebool /19/ :49: setsebool /13/ :14: vim /13/ :14: vim /13/ :14: vim /13/ :14: vim /13/ :14: vim /13/ :14: vim /13/ :14: vim The audit subsystem keeps a number of lists that you can add rules to. These lists are associated with: Task creation (whenever a fork() or clone() system call is executed) Entry into a system call Exit from a system call Events originating in user space associated with UID, AUID (the UID used at the original login), GID, and PID File system watches (you can watch specific files, directories, or file systems for activity) When you create a new rule, you specify which list you want each rule to be associated with and an action to perform. There are three possible actions: Never Never create an audit record (suppresses event logging for events you know you do not care about). Possible Prepares an audit record in case another rule or condition requires it to be written. Always Always create an audit record. When you write these rules, you use one of the following forms: -a list,action -A list,action The a option appends the rule to the end of the list, the A option adds the rule to the beginning of the list. In general, put rules with never actions at the beginning of each list because lists of rules are evaluated from start to finish until a matching rule is found. The first matching rule is the one used. 19

20 To further refine your rules, auditctl has many options (for example, to specify a particular system call name, calls made to a system call from a user-space process with a particular user-id, or process-id, or the name of a file to watch). For the complete list of all possible options, see the auditctl(8) manpage. Here is an example of a typical audit rule taken from the auditctl (8) manpage. It logs unsuccessful open() calls: Command Line: # auditctl -a exit,always -S open -F success!=0 Entry in the audit.rules file: -a exit,always -S open -F success!=0 Watching Important Files If you have specific files, directories, or file systems that you need to monitor for activity, you can use auditctl to create a watch rule to do this with the w option. For example: Command line: # auditctl -w /projects/timeline -k projectx_schedule -p rwxa Entry in the audit.rules file: -w /projects/timeline -k projectx_schedule -p rwxa The previous command specifies a rule that watches for system calls to read, write, execute, or change the attributes of the file /projects/timeline. When such calls occur, audit records are written that include the label string projectx_schedule for later identification with ausearch or other commands. HP Compliance Log Warehouse Many security technologies generate log data, often lots of it. Each technology logs data in its own format, and collectively the technologies record the log data in a variety of locations. Sometimes instructions require you to evaluate multiple types of logs collected over long periods of time in order to be detected. Depending on the type of data you are handling, many compliance mandates such as the Payment Card Industry Data Security Standard (PCI-DSS), and the Health Insurance Portability and Accountability Act (HIPAA) require you to log every data access. The logs required by these compliance mandates can grow extremely large, sometimes many gigabytes of log data per day. And, the various compliance mandates also require you to retain the log data, perhaps for years! With logging requirements like these, simple disk files and in-house developed programs to scan the logging data might not be sufficient to prove compliance with the various legal requirements. For truly serious logging and log analysis needs, HP sells a network based appliance called the HP Compliance Log Warehouse (CLW). The CLW is fully scaleable and out of the box comes with the ability to collect, analyze, and report on log data for many of the world s compliance mandates. It is extremely scaleable and can collect data from multiple sites and generate reports to assist you in proving that your operations comply with specific mandates. To adapt the CLW to comply with future mandates, new log agents are easy to write. Further information about the HP Compliance Log Warehouse can be found at: 20