V-ID |
CCI |
CAT |
Title |
Description |
Check Procedures |
Fixtext |
V-756 |
CCE-4241-6 |
medium |
The system must require authentication upon booting into single-user and maintenance modes. |
If the system does not require valid root authentication before it boots into single-user or maintenance mode, anyone who invokes single-user or maintenance mode is granted privileged access to all files on the system. |
|
Edit /etc/inittab and set sulogin to run in single-user mode.
Example line in /etc/inittab:
~:S:wait:/sbin/sulogin |
V-763 |
CCI-000048 |
medium |
The Department of Defense (DoD) login banner must be displayed immediately prior to, or as part of, console login prompts. |
Failure to display the logon banner prior to a logon attempt will negate legal proceedings resulting from unauthorized access to system resources. |
|
Edit /etc/issue and add one of the DoD login banners (based on the character limitations imposed by the system).
DoD Login Banners:
You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.
By using this IS (which includes any device attached to this IS), you consent to the following conditions:
-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.
-At any time, the USG may inspect and seize data stored on this IS.
-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.
-This IS includes security measures (e.g., authentication and access controls) to protect USG interests- -not for your personal benefit or privacy.
-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details.
OR
I've read & consent to terms in IS user agreem't. |
V-770 |
CCI-000366 |
high |
The system must not have accounts configured with blank or null passwords. |
If an account is configured for password authentication but does not have an assigned password, it may be possible to log into the account without authentication. If the root user is configured without a password, the entire system may be compromised. For user accounts not using password authentication, the account must be configured with a password lock value instead of a blank or null value. |
|
Edit /etc/pam.d/system-auth and remove the "nullok" setting. |
V-773 |
CCI-000366 |
medium |
The root account must be the only account having a UID of 0. |
If an account has a UID of 0, it has root authority. Multiple accounts with a UID of 0 afford more opportunity for potential intruders to guess a password for a privileged account.
|
|
Remove or change the UID of accounts other than root that have UID 0. |
V-774 |
CCI-000366 |
low |
The root user's home directory must not be the root directory (/). |
Changing the root home directory to something other than / and assigning it a 0700 protection makes it more difficult for intruders to manipulate the system by reading the files root places in its default directory. It also gives root the same discretionary access control for root's home directory as for the other user home directories. |
|
The root home directory should be something other than / (such as /roothome).
Procedure:
# mkdir /rootdir
# chown root /rootdir
# chgrp root /rootdir
# chmod 700 /rootdir
# cp -r /.??* /rootdir/.
Then, edit the passwd file and change the root home directory to /rootdir. The cp -r /.??* command copies all files and subdirectories of file names beginning with "." into the new root directory, which preserves the previous root environment. Ensure you are in the "/" directory when executing the "cp" command. |
V-775 |
CCI-000225 |
medium |
The root account's home directory (other than /) must have mode 0700. |
Permissions greater than 0700 could allow unauthorized users access to the root home directory. |
|
The root home directory will have permissions of 0700. Do not change the protections of the / directory. Use the following command to change protections for the root home directory:
# chmod 0700 /rootdir. |
V-776 |
CCI-000366 |
medium |
The root account's executable search path must be the vendor default and must contain only absolute paths. |
The executable search path (typically the PATH environment variable) contains a list of directories for the shell to search to find executables. If this path includes the current working directory or other relative paths, executables in these directories may be executed instead of system commands. This variable is formatted as a colon-separated list of directories. If there is an empty entry, such as a leading or trailing colon or two consecutive colons, this is interpreted as the current working directory. Entries starting with a slash (/) are absolute paths.
|
|
Edit the root user's local initialization files ~/.profile,~/.bashrc (assuming root shell is bash). Change any found PATH variable settings to the vendor's default path for the root user. Remove any empty path entries or references to relative paths. |
V-777 |
CCI-000366 |
medium |
The root account must not have world-writable directories in its executable search path. |
If the root search path contains a world-writable directory, malicious software could be placed in the path by intruders and/or malicious users and inadvertently run by root with all of root's privileges.
|
|
For each world-writable path in root's executable search path, do one of the following:
1. Remove the world-writable permission on the directory.
Procedure:
# chmod o-w <path>
2. Remove the world-writable directory from the executable search path.
Procedure:
Identify and edit the initialization file referencing the world-writable directory and remove it from the PATH variable. |
V-781 |
CCI-000366 |
low |
All GIDs referenced in the /etc/passwd file must be defined in the /etc/group file. |
If a user is assigned the GID of a group not existing on the system, and a group with the GID is subsequently created, the user may have unintended rights to the group.
|
|
Add a group to the system for each GID referenced without a corresponding group. |
V-787 |
CCI-001314 |
medium |
System log files must have mode 0640 or less permissive. |
If the system log files are not protected, unauthorized users could change the logged data, eliminating its forensic value. |
|
Change the mode of the system log file(s) to 0640 or less permissive.
Procedure:
# chmod 0640 /path/to/system-log-file
Note: Do not confuse system log files with audit logs. |
V-788 |
CCI-000225 |
medium |
All skeleton files (typically those in /etc/skel) must have mode 0644 or less permissive. |
If the skeleton files are not protected, unauthorized personnel could change user startup parameters and possibly jeopardize user files.
|
|
Change the mode of skeleton files with incorrect mode:
# chmod 0644 <skeleton file> |
V-789 |
CCI-000225 |
medium |
NIS/NIS+/yp files must be owned by root, sys, or bin. |
NIS/NIS+/yp files are part of the system's identification and authentication processes and are critical to system security. Failure to give ownership of sensitive files or utilities to root or bin provides the designated owner and unauthorized users with the potential to access sensitive information or change the system configuration which could weaken the system's security posture. |
|
Change the ownership of NIS/NIS+/yp files to root, sys or bin.
Procedure (example):
# chown root <filename> |
V-791 |
CCI-000225 |
medium |
The NIS/NIS+/yp command files must have mode 0755 or less permissive. |
NIS/NIS+/yp files are part of the system's identification and authentication processes and are critical to system security. Unauthorized modification of these files could compromise these processes and the system. |
|
Change the mode of NIS/NIS+/yp command files to 0755 or less permissive.
Procedure (example):
# chmod 0755 <filename> |
V-793 |
CCI-001499 |
medium |
Library files must have mode 0755 or less permissive. |
Unauthorized access could destroy the integrity of the library files. |
|
Change the mode of library files to 0755 or less permissive.
Procedure (example):
# chmod go-w </path/to/library-file>
Note: Library files should have an extension of ".a" or a ".so" extension, possibly followed by a version number. |
V-794 |
CCI-001499 |
medium |
All system command files must have mode 0755 or less permissive. |
Restricting permissions will protect system command files from unauthorized modification. System command files include files present in directories used by the operating system for storing default system executables and files present in directories included in the system's default executable search paths. |
|
Change the mode for system command files to 0755 or less permissive taking into account necessary GIUD and SUID bits.
Procedure:
# chmod go-w <filename> |
V-795 |
CCI-001499 |
medium |
All system files, programs, and directories must be owned by a system account. |
Restricting permissions will protect the files from unauthorized modification. |
|
Change the owner of system files, programs, and directories to a system account.
Procedure:
# chown root /some/system/file
(A different system user may be used in place of root.) |
V-796 |
CCI-001499 |
medium |
System files, programs, and directories must be group-owned by a system group. |
Restricting permissions will protect the files from unauthorized modification. |
|
Change the group-owner of system files to a system group.
Procedure:
# chgrp root /path/to/system/file
(System groups other than root may be used.) |
V-797 |
CCE-3918-0 |
medium |
The /etc/shadow (or equivalent) file must be owned by root. |
The /etc/shadow file contains the list of local system accounts. It is vital to system security and must be protected from unauthorized modification. Failure to give ownership of sensitive files or utilities to root or bin provides the designated owner and unauthorized users with the potential to access sensitive information or change the system configuration which could weaken the system's security posture. |
|
Change the ownership of the /etc/shadow (or equivalent) file.
# chown root /etc/shadow |
V-798 |
CCE-3566-7 |
medium |
The /etc/passwd file must have mode 0644 or less permissive. |
If the passwd file is writable by a group-owner or the world, the risk of passwd file compromise is increased. The passwd file contains the list of accounts on the system and associated information. |
|
Change the mode of the passwd file to 0644.
Procedure:
# chmod 0644 /etc/passwd |
V-800 |
CCE-4130-1 |
medium |
The /etc/shadow (or equivalent) file must have mode 0400. |
The /etc/shadow file contains the list of local system accounts. It is vital to system security and must be protected from unauthorized modification. The file also contains password hashes which must not be accessible to users other than root. |
|
Change the mode of the /etc/shadow (or equivalent) file.
# chmod 0400 /etc/shadow |
V-808 |
CCI-000366 |
medium |
The system and user default umask must be 077. |
The umask controls the default access mode assigned to newly created files. An umask of 077 limits new files to mode 700 or less permissive. Although umask can be represented as a 4-digit number, the first digit representing special access modes is typically ignored or required to be 0. This requirement applies to the globally configured system defaults and the user defaults for each account on the system. |
|
Edit local and global initialization files that contain "umask" and change them to use 077 instead of the current value. |
V-812 |
CCI-000162 |
medium |
System audit logs must be owned by root. |
Failure to give ownership of system audit log files to root provides the designated owner and unauthorized users with the potential to access sensitive information. |
|
Change the ownership of the audit log file(s).
Procedure:
# chown root <audit log file> |
V-813 |
CCI-000163 |
medium |
System audit logs must have mode 0640 or less permissive. |
If a user can write to the audit logs, audit trails can be modified or destroyed and system intrusion may not be detected. System audit logs are those files generated from the audit system and do not include activity, error, or other log files created by application software. |
|
Change the mode of the audit log directories/files.
# chmod 0750 <audit directory>
# chmod 0640 <audit file> |
V-814 |
CCI-000126 |
medium |
The audit system must be configured to audit failed attempts to access files and programs. |
If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise. |
|
Edit the audit.rules file and add the following line(s) to enable auditing of failed attempts to access files and programs:
either:
-a exit,always -F arch=<ARCH> -S creat -F success=0
or both:
-a exit,always -F arch=<ARCH> -S creat -F exit=-EPERM
-a exit,always -F arch=<ARCH> -S creat -F exit=-EACCES
Restart the auditd service.
# service auditd restart |
V-815 |
CCI-000126 |
medium |
The audit system must be configured to audit files and programs deleted by the user. |
If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise. |
|
Edit the audit.rules file and add the following line to enable auditing of deletions:
-a exit,always -S unlink
Restart the auditd service.
# service auditd restart |
V-818 |
CCE-14904-7 |
medium |
The audit system must be configured to audit login, logout, and session initiation. |
If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise. |
|
Ensure logins
Procedure:
Modify /etc/audit/audit.rules to contain:
-w /var/log/faillog -p wa
-w /var/log/lastlog -p wa |
V-819 |
CCE-14058-2 |
medium |
The audit system must be configured to audit all discretionary access control permission modifications. |
If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise.
|
|
The "-F arch=<ARCH>" restriction is required on dual-architecture systems (such as x86_64). On dual-architecture systems, two separate rules must exist - one for each architecture supported. Use the generic architectures "b32" and "b64" for specifying these rules.
On single architecture systems, the "-F arch=<ARCH>" restriction may be omitted, but if present must match either the architecture of the system or its corresponding generic architecture. The architecture of the system may be determined by running "uname -m". See the auditctl(8) manpage for additional details.
Any restrictions (such as with "-F") beyond those provided in the example rules are not in strict compliance with this requirement, and are a finding unless justified and documented appropriately.
The use of audit keys consistent with the provided example is encouraged to provide for uniform audit logs, however omitting the audit key or using an alternate audit key is not a finding.
Procedure:
Edit the audit.rules file and add the following lines to enable auditing of discretionary access control permissions modifications.
-a exit,always -F arch=<ARCH> -S chmod
Restart the auditd service.
# service auditd restart |
V-821 |
CCI-000225 |
medium |
The inetd.conf file, xinetd.conf file, and the xinetd.d directory must be owned by root or bin. |
Failure to give ownership of sensitive files or utilities to root provides the designated owner and unauthorized users with the potential to access sensitive information or change the system configuration possibly weakening the system's security posture. |
|
Change the owner of the xinetd configuration files.
# chown root /etc/xinetd.conf /etc/xinetd.d/* |
V-822 |
CCI-000225 |
medium |
The inetd.conf and xinetd.conf files must have mode 0440 or less permissive. |
The Internet service daemon configuration files must be protected as malicious modification could cause Denial of Service or increase the attack surface of the system. |
|
Change the mode of the xinetd configuration files.
# chmod 0640 /etc/xinetd.conf /etc/xinetd.d/* |
V-823 |
CCI-000225 |
medium |
The services file must be owned by root or bin. |
Failure to give ownership of sensitive files or utilities to root or bin provides the designated owner and unauthorized users with the potential to access sensitive information or change the system configuration possibly weakening the system's security posture. |
|
Change the ownership of the services file to root or bin.
Procedure:
# chown root /etc/services |
V-824 |
CCI-000225 |
medium |
The services file must have mode 0644 or less permissive. |
The services file is critical to the proper operation of network services and must be protected from unauthorized modification. Unauthorized modification could result in the failure of network services. |
|
Change the mode of the services file to 0644 or less permissive.
Procedure:
# chmod 0644 /etc/services |
V-825 |
CCI-000366 |
low |
Global initialization files must contain the "mesg -n" or "mesg n" commands. |
If the "mesg -n" or "mesg n" command is not placed into the system profile, messaging can be used to cause a Denial of Service attack. |
|
Edit /etc/profile or another global initialization script, and add the "mesg -n" command. |
V-828 |
CCI-000225 |
medium |
The hosts.lpd (or equivalent) file must be owned by root, bin, sys, or lp. |
Failure to give ownership of the hosts.lpd file to root, bin, sys, or lp provides the designated owner, and possible unauthorized users, with the potential to modify the hosts.lpd file. Unauthorized modifications could disrupt access to local printers from authorized remote hosts or permit unauthorized remote access to local printers. |
|
Change the owner of the /etc/cups/printers.conf to root.
Procedure:
# chown root /etc/cups/printers.conf |
V-829 |
CCI-000225 |
medium |
The hosts.lpd (or equivalent) must have mode 0644 or less permissive. |
Excessive permissions on the hosts.lpd (or equivalent) file may permit unauthorized modification. Unauthorized modifications could disrupt access to local printers from authorized remote hosts or permit unauthorized remote access to local printers. |
|
Change the mode of the /etc/cups/printers.conf file to 0664 or less permissive.
Procedure:
# chmod 0664 /etc/cups/printers.conf |
V-831 |
CCI-000225 |
medium |
The alias file must be owned by root. |
If the alias file is not owned by root, an unauthorized user may modify the file adding aliases to run malicious code or redirect e-mail. |
|
Change the owner of the /etc/aliases file to root.
Procedure:
for sendmail:
# chown root /etc/aliases
# chown root /etc/aliases.db
for postfix
# chown root /etc/postfix/aliases
# chown root /etc/postfix/aliases.db |
V-832 |
CCI-000225 |
medium |
The alias file must have mode 0644 or less permissive. |
Excessive permissions on the aliases file may permit unauthorized modification. If the alias file is modified by an unauthorized user, they may modify the file to run malicious code or redirect e-mail. |
|
Change the mode of the alias files as needed to function. No higher than 0644.
Procedure:
for sendmail:
# chmod 0644 /etc/aliases /etc/aliases.db
for postfix (assuming the default postfix directory):
# chmod 0644 /etc/postfix/aliases /etc/postfix/aliases.db |
V-834 |
CCI-000225 |
medium |
Files executed through a mail aliases file must have mode 0755 or less permissive. |
If a file executed through a mail aliases file has permissions greater than 0755, it can be modified by an unauthorized user and may contain malicious code or instructions potentially compromising the system. |
|
Use the chmod command to change the access permissions for files executed from the alias file.
For example:
# chmod 0755 filename |
V-835 |
CCI-000366 |
low |
Sendmail logging must not be set to less than nine in the sendmail.cf file. |
If Sendmail is not configured to log at level 9, system logs may not contain the information necessary for tracking unauthorized use of the sendmail service. |
|
Edit the sendmail.conf file, locate the "O L" or "LogLevel" entry and change it to 9. |
V-837 |
CCI-000225 |
medium |
The SMTP service log file must be owned by root. |
If the SMTP service log file is not owned by root, then unauthorized personnel may modify or delete the file to hide a system compromise. |
|
Change the ownership of the sendmail log file.
Procedure:
The fix procedure is the same for both sendmail and Postfix.
# chown root <sendmail log file> |
V-838 |
CCI-000225 |
medium |
The SMTP service log file must have mode 0644 or less permissive. |
If the SMTP service log file is more permissive than 0644, unauthorized users may be allowed to change the log file. |
|
Change the mode of the SMTP service log file.
Procedure:
The fix procedure is the same for both sendmail and Postfix.
# chmod 0644 <sendmail log file> |
V-840 |
CCI-000225 |
medium |
The ftpusers file must exist. |
The ftpusers file contains a list of accounts not allowed to use FTP to transfer files. If this file does not exist, then unauthorized accounts can utilize FTP. |
|
Create an ftpusers file appropriate for the running FTP service.
For gssftp:
Create an /etc/ftpusers file containing a list of accounts not authorized for FTP.
For vsftp:
Create an /etc/vfsftpd.ftpusers or /etc/vfsftpd/ftpusers (as appropriate) file containing a list of accounts not authorized for FTP. |
V-842 |
CCI-000225 |
medium |
The ftpusers file must be owned by root. |
If the file ftpusers is not owned by root, an unauthorized user may modify the file to allow unauthorized accounts to use FTP. |
|
Change the owner of the ftpusers file to root.
For gssftp:
# chown root /etc/ftpusers
For vsftp:
# chown root /etc/vsftpd.ftpusers /etc/vsftpd/ftpusers |
V-843 |
CCI-000225 |
medium |
The ftpusers file must have mode 0640 or less permissive. |
Excessive permissions on the ftpusers file could permit unauthorized modification. Unauthorized modification could result in Denial of Service to authorized FTP users or permit unauthorized users to access the FTP service. |
|
Change the mode of the ftpusers file to 0640.
Procedure:
For gssftp:
# chmod 0640 /etc/ftpusers
For vsftp:
# chmod 0640 /etc/vsftpd.ftpusers /etc/vsftpd/ftpusers |
V-847 |
CCI-000366 |
high |
The TFTP daemon must operate in "secure mode" which provides access only to a single directory on the host file system. |
Secure mode limits TFTP requests to a specific directory. If TFTP is not running in secure mode, it may be able to write to any file or directory and may seriously impair system integrity, confidentiality, and availability. |
|
Edit /etc/xinetd.d/tftp file and specify the "-s" parameter in server_args. |
V-848 |
CCI-000225 |
high |
The TFTP daemon must have mode 0755 or less permissive. |
If TFTP runs with the setuid or setgid bit set, it may be able to write to any file or directory and may seriously impair system integrity, confidentiality, and availability. |
|
Change the mode of the TFTP daemon.
Procedure:
# chmod 0755 <in.tftpd binary> |
V-867 |
CCI-001435 |
medium |
The Network Information System (NIS) protocol must not be used. |
Due to numerous security vulnerabilities existing within NIS, it must not be used. Possible alternative directory services are NIS+ and LDAP. |
|
Disable the use of NIS/NIS+. Use as a replacement Kerberos or LDAP. |
V-899 |
CCI-000225 |
low |
All interactive users must be assigned a home directory in the /etc/passwd file. |
If users do not have a valid home directory, there is no place for the storage and control of files they own. |
|
Assign a home directory to any user without one. |
V-900 |
CCI-000225 |
low |
All interactive user home directories defined in the /etc/passwd file must exist. |
If a user has a home directory defined that does not exist, the user may be given the / directory, by default, as the current working directory upon logon. This could create a Denial of Service because the user would not be able to perform useful tasks in this location. |
|
If a user has no home directory, determine why. If possible, delete accounts without a home directory. If the account is valid, then create the home directory using the appropriate system administration utility or manually.
For instance: mkdir directoryname; copy the skeleton files into the directory; chown accountname for the new directory and the skeleton files. Document all changes. |
V-901 |
CCE-4090-7 |
medium |
All user home directories must have mode 0750 or less permissive. |
Excessive permissions on home directories allow unauthorized access to user files. |
|
Change the mode of user home directories to 0750 or less permissive.
Procedure (example):
# chmod 0750 <home directory>
Note: Application directories are allowed and may need 0755 permissions (or greater) for correct operation. |
V-906 |
CCI-000225 |
medium |
All run control scripts must have mode 0755 or less permissive. |
If the startup files are writable by other users, they could modify the startup files to insert malicious commands into the startup files. |
|
Ensure all system startup files have mode 0755 or less permissive. Examine the "rc" files, and all files in the rc1.d (rc2.d, and so on) directories, and in the /etc/init.d directory to ensure they are not world-writable. If they are world-writable, use the chmod command to correct the vulnerability and research why they are world-writable.
Procedure:
# chmod 755 <startup file> |
V-913 |
CCI-000196 |
medium |
There must be no .netrc files on the system. |
Unencrypted passwords for remote FTP servers may be stored in .netrc files. Policy requires passwords be encrypted in storage and not used in access scripts. |
|
Remove the .netrc file(s).
Procedure:
# find / -name .netrc
# rm <.netrc file> |
V-916 |
CCI-000366 |
medium |
The /etc/shells (or equivalent) file must exist. |
The shells file (or equivalent) lists approved default shells. It helps provide layered defense to the security approach by ensuring users cannot change their default shell to an unauthorized unsecure shell. |
|
Create a /etc/shells file containing a list of valid system shells. Consult vendor documentation for an appropriate list of system shells.
Procedure:
# echo "/bin/bash" >> /etc/shells
# echo "/bin/csh" >> /etc/shells
(Repeat as necessary for other shells.) |
V-921 |
CCI-000225 |
medium |
All shell files must be owned by root or bin. |
If shell files are owned by users other than root or bin, they could be modified by intruders or malicious users to perform unauthorized actions. |
|
Change the ownership of the shell with incorrect ownership.
# chown root <shell> |
V-922 |
CCI-000225 |
high |
All shell files must have mode 0755 or less permissive. |
Shells with world/group write permissions give the ability to maliciously modify the shell to obtain unauthorized access. |
|
Change the mode of the shell.
# chmod 0755 <shell> |
V-924 |
CCI-000225 |
medium |
Device files and directories must only be writable by users with a system account or as configured by the vendor. |
System device files in writable directories could be modified, removed, or used by an unprivileged user to control system hardware. |
|
Remove the world-writable permission from the device file(s).
Procedure:
# chmod o-w <device file>
Document all changes. |
V-928 |
CCI-000225 |
medium |
The Network File System (NFS) export configuration file must be owned by root. |
Failure to give ownership of the NFS export configuration file to root provides the designated owner and possible unauthorized users with the potential to change system configuration which could weaken the system's security posture. |
|
Change the owner of the exports file to root.
Example:
# chown root /etc/exports |
V-929 |
CCI-000225 |
low |
The Network File System (NFS) export configuration file must have mode 0644 or less permissive. |
Excessive permissions on the NFS export configuration file could allow unauthorized modification of the file, which could result in Denial of Service to authorized NFS exports and the creation of additional unauthorized exports. |
|
# chmod 0644 /etc/exports |
V-931 |
CCI-000225 |
medium |
All Network File System (NFS) exported system files and system directories must be owned by root. |
Failure to give ownership of sensitive files or directories to root provides the designated owner and possible unauthorized users with the potential to access sensitive information or change system configuration which could weaken the system's security posture. |
|
Change the ownership of exported file systems not owned by root.
Procedure:
# chown root <path> |
V-932 |
CCI-000062 |
medium |
The Network File System (NFS) anonymous UID and GID must be configured to values without permissions. |
When an NFS server is configured to deny remote root access, a selected UID and GID are used to handle requests from the remote root user. The UID and GID should be chosen from the system to provide the appropriate level of non-privileged access. |
|
Edit "/etc/exports" and set the "anonuid=-1" and "anongid=-1" options for exports lacking it. Re-export the filesystems. |
V-933 |
CCI-000366 |
medium |
The Network File System (NFS) server must be configured to restrict file system access to local hosts. |
The NFS access option limits user access to the specified level. This assists in protecting exported file systems. If access is not restricted, unauthorized hosts may be able to access the system's NFS exports. |
|
Edit /etc/exports and add ro and/or rw options (as appropriate) specifying a list of hosts or networks which are permitted access. Re-export the file systems. |
V-935 |
CCE-4544-3 |
medium |
The Network File System (NFS) server must not allow remote root access. |
If the NFS server allows root access to local file systems from remote hosts, this access could be used to compromise the system. |
|
Edit the "/etc/exports" file and add "root_squash" (or "all_squash") and remove "no_root_squash". |
V-936 |
CCE-4024-6 |
medium |
The "nosuid" option must be enabled on all Network File System (NFS) client mounts. |
Enabling the nosuid mount option prevents the system from granting owner or group-owner privileges to programs with the suid or sgid bit set. If the system does not restrict this access, users with unprivileged access to the local system may be able to acquire privileged access by executing suid or sgid files located on the mounted NFS file system. |
|
Edit "/etc/fstab" and add the "nosuid" option for all NFS file systems. Remount the NFS file systems to make the change take effect. |
V-940 |
CCI-000366 |
medium |
The system must use an access control program. |
Access control programs (such as TCP_WRAPPERS) provide the ability to enhance system security posture. |
|
Install and configure the tcp_wrappers package. |
V-941 |
CCI-000126 |
medium |
The system's access control program must log each system access attempt. |
If access attempts are not logged, then multiple attempts to log on to the system by an unauthorized user may go undetected. |
|
Configure the access restriction program to log every access attempt. Ensure the implementation instructions for tcp_wrappers are followed so system access attempts are recorded to the system log files. If an alternate application is used, it must support this function. |
V-974 |
CCI-000225 |
medium |
Access to the cron utility must be controlled using the cron.allow and/or cron.deny file(s). |
The cron facility allows users to execute recurring jobs on a regular and unattended basis. The cron.allow file designates accounts allowed to enter and execute jobs using the cron facility. If neither cron.allow nor cron.deny exists, then any account may use the cron facility. This may open the facility up for abuse by system intruders and malicious users. |
|
Create /etc/cron.allow and/or /etc/cron.deny with appropriate content. |
V-975 |
CCI-000225 |
medium |
The cron.allow file must have mode 0600 or less permissive. |
A readable and/or writable cron.allow file by users other than root could allow potential intruders and malicious users to use the file contents to help discern information, such as who is allowed to execute cron programs, which could be harmful to overall system and network security. |
|
Change the mode of the cron.allow file to 0600.
Procedure:
# chmod 0600 /etc/cron.allow |
V-978 |
CCI-000225 |
medium |
Crontab files must have mode 0600 or less permissive, and files in cron script directories must have mode 0700 or less permissive. |
To protect the integrity of scheduled system jobs and prevent malicious modification to these jobs, crontab files must be secured. |
|
Change the mode of the crontab files.
# chmod 0600 /var/spool/cron/* /etc/cron.d/* /etc/crontab |
V-979 |
CCI-000225 |
medium |
Cron and crontab directories must have mode 0755 or less permissive. |
To protect the integrity of scheduled system jobs and to prevent malicious modification to these jobs, crontab files must be secured. |
|
Change the mode of the crontab directories.
# chmod 0755 <crontab directory> |
V-980 |
CCI-000225 |
medium |
Cron and crontab directories must be owned by root or bin. |
Incorrect ownership of the cron or crontab directories could permit unauthorized users the ability to alter cron jobs and run automated jobs as privileged users. Failure to give ownership of cron or crontab directories to root or to bin provides the designated owner and unauthorized users with the potential to access sensitive information or change the system configuration which could weaken the system's security posture. |
|
Change the mode of the crontab directories.
# chown root <crontab directory> |
V-981 |
CCI-000225 |
medium |
Cron and crontab directories must be group-owned by root, sys, bin or cron. |
To protect the integrity of scheduled system jobs and to prevent malicious modification to these jobs, crontab files must be secured. Failure to give group-ownership of cron or crontab directories to a system group provides the designated group and unauthorized users with the potential to access sensitive information or change the system configuration which could weaken the system's security posture. |
|
Change the group owner of cron and crontab directories.
# chgrp root <crontab directory> |
V-982 |
CCI-000126 |
medium |
Cron logging must be implemented. |
Cron logging can be used to trace the successful or unsuccessful execution of cron jobs. It can also be used to spot intrusions into the use of the cron facility by unauthorized and malicious users.
|
|
Edit /etc/syslog.conf and setup cron logging. |
V-983 |
CCI-000225 |
medium |
The cronlog file must have mode 0600 or less permissive. |
Cron logs contain reports of scheduled system activities and must be protected from unauthorized access or manipulation.
|
|
Change the mode of the cron log file.
# chmod 0600 /var/log/cron |
V-984 |
CCI-000225 |
medium |
Access to the "at" utility must be controlled via the at.allow and/or at.deny file(s). |
The "at" facility selectively allows users to execute jobs at deferred times. It is usually used for one-time jobs. The at.allow file selectively allows access to the "at" facility. If there is no at.allow file, there is no ready documentation of who is allowed to submit "at" jobs. |
|
Create at.allow and/or at.deny files containing appropriate lists of users to be allowed or denied access to the "at" daemon. |
V-985 |
CCI-000225 |
medium |
The at.deny file must not be empty if it exists. |
On some systems, if there is no at.allow file and there is an empty at.deny file, then the system assumes everyone has permission to use the "at" facility. This could create an insecure setting in the case of malicious users or system intruders. |
|
Add appropriate users to the at.deny file, or remove the empty at.deny file if an at.allow file exists. |
V-986 |
CCI-000225 |
medium |
Default system accounts (with the exception of root) must not be listed in the at.allow file or must be included in the at.deny file if the at.allow file does not exist. |
Default accounts, such as bin, sys, adm, uucp, daemon, and others, should never have access to the "at" facility. This would create a possible vulnerability open to intruders or malicious users. |
|
Remove the default accounts (such as bin, sys, adm, and others, traditionally UID less than 500) from the at.allow file. |
V-987 |
CCI-000225 |
medium |
The at.allow file must have mode 0600 or less permissive. |
Permissions more permissive than 0600 (read, write and execute for the owner) may allow unauthorized or malicious access to the at.allow and/or at.deny files. |
|
Change the mode of the at.allow file.
# chmod 0600 /etc/at.allow |
V-994 |
CCI-000225 |
medium |
The snmpd.conf file must have mode 0600 or less permissive. |
The snmpd.conf file contains authenticators and must be protected from unauthorized access and modification. |
|
Change the mode of the SNMP daemon configuration file to 0600.
Procedure:
# chmod 0600 <snmpd.conf> |
V-995 |
CCI-000225 |
medium |
Management Information Base (MIB) files must have mode 0640 or less permissive. |
The ability to read the MIB file could impart special knowledge to an intruder or malicious user about the ability to extract compromising information about the system or network. |
|
Change the mode of MIB files to 0640.
Procedure:
# chmod 0640 <mib file> |
V-1011 |
CCI-000134 |
low |
Inetd or xinetd logging/tracing must be enabled. |
Inetd or xinetd logging and tracing allows the system administrators to observe the IP addresses connecting to their machines and what network services are being sought. This provides valuable information when trying to find the source of malicious users and potential malicious users. |
|
Edit each file in the /etc/xinetd.d directory and the /etc/xinetd.conf file to contain:
log_type = SYSLOG authpriv
log_on_success = HOST PID USERID EXIT
log_on_failure = HOST USERID
The /etc/xinetd.conf file contains default values that will hold true for all services unless individually modified in the service's xinetd.d file.
To make the new settings effective, restart the xinetd service:
# service xinetd restart |
V-1021 |
CCI-000032 |
medium |
The X server must have the correct options enabled. |
Without the correct options enabled, the Xwindows system would be less secure and there would be no screen timeout. |
|
Enable the following options: -audit (at level 4), -auth and -s with 15 minutes as the timeout value.
Procedure for gdm:
Edit /etc/gdm/custom.conf and add the following:
[server-Standard]
name=Standard server
command=/usr/bin/Xorg -br -audit 4 -s 15
chooser=false
handled=true
flexible=true
priority=0
Procedure for xinit:
Edit or create a .xserverrc file in the users home directory containing the startup script for xinit.
This script must have an exec line with at least these options:
exec /usr/bin/X -audit 4 -s 15 -auth <Xauth file> &
The <Xauth file> is created using the "xauth" command and is customarily located in the users home directory with the name ".Xauthority". |
V-1022 |
CCI-000032 |
medium |
An X server must have none of the following options enabled: -ac, -core (except for debugging purposes), or -nolock. |
These options will detract from the security of the Xwindows system. |
|
Disable the unwanted options:
Procedure:
For gdm:
Remove the -ac, -core and -nolock options by creating a "command" entry in the /etc/gdm/custom.conf file with the options removed.
For Xwindows started by xinit:
Create or modify the .xserverrc script in the users home directory to remove the -ac, -core and -nolock options from the exec /usr/bin/X command. |
V-1023 |
CCI-000381 |
medium |
The system must not run an Internet Network News (INN) server. |
INN servers access Usenet newsfeeds and store newsgroup articles. INN servers use the Network News Transfer Protocol (NNTP) to transfer information from the Usenet to the server and from the server to authorized remote hosts.
If this function is necessary to support a valid mission requirement, its use must be authorized and approved in the system accreditation package. |
|
Disable the INN server. |
V-1025 |
CCI-000225 |
medium |
The /etc/access.conf file must be owned by root. |
The /etc/access.conf file contains entries restricting access from the system console by authorized System Administrators. If the file is owned by a user other than root, it could compromise the system. |
|
Follow the correct configuration parameters for access configuration file. Use the chown command to configure it properly.
(for example:
# chown root /etc/security/access.conf
). |
V-1027 |
CCI-000225 |
medium |
The /etc/smb.conf file must be owned by root. |
The /etc/smb.conf file allows access to other machines on the network and grants permissions to certain users. If it is owned by another user, the file may be maliciously modified and the Samba configuration could be compromised. |
|
Change the ownership of the smb.conf file.
Procedure:
# chown root smb.conf |
V-1028 |
CCI-000225 |
medium |
The /etc/smb.conf file must have mode 0644 or less permissive. |
If the "smb.conf" file has excessive permissions, the file may be maliciously modified and the Samba configuration could be compromised. |
|
Change the mode of the smb.conf file to 0644 or less permissive.
Procedure:
# chmod 0644 smb.conf. |
V-1029 |
CCI-000225 |
medium |
The /etc/smbpasswd file must be owned by root. |
If the "smbpasswd" file is not owned by root, it may be maliciously accessed or modified, potentially resulting in the compromise of Samba accounts. |
|
Use the chown command to configure the files maintained by smbpasswd.
For instance:
# chown root /etc/samba/passdb.tdb /etc/samba/secrets.tdb |
V-1032 |
CCE-4180-6 |
medium |
Users must not be able to change passwords more than once every 24 hours. |
The ability to change passwords frequently facilitates users reusing the same password. This can result in users effectively never changing their passwords. This would be accomplished by users changing their passwords when required and then immediately changing it to the original value.
|
|
Change the minimum time period between password changes for each user account to 1 day.
# passwd -n 1 <user name> |
V-1047 |
CCE-4387-7 |
medium |
The system must not permit root logins using remote access programs such as ssh. |
Even though communications are encrypted, an additional layer of security may be gained by extending the policy of not logging directly on as root. In addition, logging in with a user-specific account preserves the audit trail. |
|
Edit the sshd_config file and set the PermitRootLogin option to "no". |
V-1048 |
CCI-000225 |
medium |
Audio devices must have mode 0660 or less permissive. |
Audio and video devices that are globally accessible have proven to be another security hazard. There is software that can activate system microphones and video devices connected to user workstations and/or X terminals. Once the microphone has been activated, it is possible to eavesdrop on otherwise private conversations without the victim being aware of it. This action effectively changes the user's microphone into a bugging device. |
|
Change the mode of audio devices.
# chmod 0660 <audio device> |
V-1049 |
CCI-000225 |
medium |
Audio devices must be owned by root. |
Audio and video devices globally accessible have proven to be another security hazard. There is software that can activate system microphones and video devices connected to user workstations and/or X terminals. Once the microphone has been activated, it is possible to eavesdrop on otherwise private conversations without the victim being aware of it. This action effectively changes the user's microphone into a bugging device. |
|
Change the owner of the audio device.
# chown root <audio device> |
V-1054 |
CCI-000225 |
medium |
The /etc/access.conf file must have a privileged group owner. |
Depending on the access restrictions of the /etc/access.conf file, if the group owner were not a privileged group, it could endanger system security. |
|
Use the chgrp command to ensure the group owner is root, sys, or bin.
(for example:
# chgrp root /etc/security/access.conf
). |
V-1055 |
CCI-000225 |
medium |
The /etc/access.conf file must have mode 0640 or less permissive. |
If the access permissions are more permissive than 0640, system security could be compromised. |
|
Use the chmod command to set the permissions to 0640.
(for example:
# chmod 0640 /etc/security/access.conf
). |
V-1056 |
CCI-000225 |
medium |
The /etc/smb.conf file must be group-owned by root, bin, sys, or system. |
If the group owner of the "smb.conf" file is not root or a system group, the file may be maliciously modified and the Samba configuration could be compromised. |
|
Change the group owner of the smb.conf file.
Procedure:
# chgrp root smb.conf |
V-1058 |
CCI-000225 |
medium |
The smbpasswd file must be group-owned by root. |
If the smbpasswd file is not group-owned by root, the smbpasswd file may be maliciously accessed or modified, potentially resulting in the compromise of Samba accounts. |
|
Use the chgrp command to ensure that the group owner of the smbpasswd file is root.
For instance:
# chgrp root /etc/samba/passdb.tdb /etc/samba/secrets.tdb |
V-1059 |
CCI-000225 |
medium |
The smbpasswd file must have mode 0600 or less permissive. |
If the smbpasswd file has a mode more permissive than 0600, the smbpasswd file may be maliciously accessed or modified, potentially resulting in the compromise of Samba accounts. |
|
Change the mode of the files maintained through smbpasswd to 0600.
Procedure:
# chmod 0600 /etc/samba/passdb.tdb /etc/samba/secrets.tdb |
V-1061 |
CCI-000225 |
medium |
Audio devices must be group-owned by root, sys, bin, or system. |
Without privileged group owners, audio devices will be vulnerable to being used as eaves-dropping devices by malicious users or intruders to possibly listen to conversations containing sensitive information. |
|
Change the group-owner of the audio device.
Procedure:
# chgrp root <audio device> |
V-1062 |
CCI-000366 |
low |
The root shell must be located in the / file system. |
To ensure the root shell is available in repair and administrative modes, the root shell must be located in the / file system. |
|
Change the root account's shell to one present on the / file system.
Procedure:
Edit /etc/passwd and change the shell for the root account to one present on the / file system (such as /bin/sh, assuming /bin is not on a separate file system). If the system does not store shell configuration in the /etc/passwd file, consult vendor documentation for the correct procedure for the system. |
V-4083 |
CCE-3315-9 |
medium |
Graphical desktop environments provided by the system must automatically lock after 15 minutes of inactivity and the system must require users to re-authenticate to unlock the environment.
Applications requiring continuous, real-time screen display (i.e., network management products) require the following and need to be documented with the IAO.
-The logon session does not have administrator rights.
-The display station (i.e., keyboard, monitor, etc.) is located in a controlled access area. |
If graphical desktop sessions do not lock the session after 15 minutes of inactivity, requiring re-authentication to resume operations, the system or individual data could be compromised by an alert intruder who could exploit the oversight. This requirement applies to graphical desktop environments provided by the system to locally attached displays and input devices as well as to graphical desktop environments provided to remote systems, including thin clients. |
|
For the Gnome screen saver, set the idle_activation_enabled flag.
Procedure:
# gconftool-2 --direct --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory --type bool --set /apps/gnome-screensaver/idle_activation_enabled true |
V-4084 |
CCE-14939-3 |
medium |
The system must prohibit the reuse of passwords within five iterations. |
If a user, or root, used the same password continuously or was allowed to change it back shortly after being forced to change it to something else, it would provide a potential intruder with the opportunity to keep guessing at one user's password until it was guessed correctly. |
|
Create the password history file.
# touch /etc/security/opasswd
# chown root:root /etc/security/opasswd
# chmod 0600 /etc/security/opasswd
Enable password history.
If /etc/pam.d/system-auth references /etc/pam.d/system-auth-ac refer to the man page for system-auth-ac for a description of how to add options not configurable with authconfig. Edit /etc/pam.d/system-auth to include the remember option on the "password pam_unix" lines set to at least 5. |
V-4089 |
CCI-000225 |
medium |
All system start-up files must be owned by root. |
System start-up files not owned by root could lead to system compromise by allowing malicious users or applications to modify them for unauthorized purposes. This could lead to system and network compromise. |
|
Change the ownership of the run control script(s) with incorrect ownership.
# find /etc -name "[SK][0-9]*"|xargs stat -L -c %U:%n|egrep -v "^root:"|cut -d: -f2|xargs chown root |
V-4090 |
CCI-000225 |
medium |
All system start-up files must be group-owned by root, sys, bin, other, or system. |
If system start-up files do not have a group owner of root or a system group, the files may be modified by malicious users or intruders. |
|
Change the group ownership of the run control script(s) with incorrect group ownership.
Procedure:
# chgrp root <run control script>
# find /etc -name "[SK][0-9]*"|xargs stat -L -c %G:%n|egrep -v "^(root|sys|bin|other):"|cut -d: -f2|xargs chgrp root |
V-4248 |
CCI-000366 |
high |
For systems capable of using GRUB, the system must be configured with GRUB as the default boot loader unless another boot loader has been authorized, justified, and documented using site-defined procedures. |
GRUB is a versatile boot loader used by several platforms that can provide authentication for access to the system or boot loader. |
|
Configure the system to use the GRUB bootloader or document, justify, and authorize the alternate bootloader. |
V-4249 |
CCE-3818-2 |
high |
The system boot loader must require authentication. |
If the system's boot loader does not require authentication, users with console access to the system may be able to alter the system boot configuration or boot the system into single user or maintenance mode, which could result in Denial of Service or unauthorized privileged access to the system. |
|
The GRUB console boot loader can be configured to use an MD5 encrypted password by adding password --md5 password-hash to the "/boot/grub/grub.conf" file. Use "/sbin/grub-md5-crypt" to generate MD5 passwords from the command line. |
V-4250 |
CCE-3923-0 |
medium |
The system's boot loader configuration file(s) must have mode 0600 or less permissive. |
File permissions greater than 0600 on boot loader configuration files could allow an unauthorized user to view or modify sensitive information pertaining to system boot instructions. |
|
Change the mode of the grub.conf file to 0600.
# chmod 0600 /boot/grub/grub.conf |
V-4268 |
CCI-000225 |
high |
The system must not have special privilege accounts, such as shutdown and halt. |
If special privilege accounts are compromised, the accounts could provide privileges to execute malicious commands on a system. |
|
Remove any special privilege accounts, such as shutdown and halt, from the /etc/passwd and /etc/shadow files using the "userdel" or "system-config-users" commands. |
V-4275 |
CCI-000225 |
medium |
The /etc/news/readers.conf (or equivalent) must have mode 0600 or less permissive. |
Excessive permissions on the readers.conf file may allow unauthorized modification which could lead to Denial of Service to authorized users or provide access to unauthorized users. |
|
Change the mode of the /etc/news/readers.conf file to 0600.
# chmod 0600 /etc/news/readers.conf |
V-4276 |
CCI-000225 |
medium |
The /etc/news/passwd.nntp file (or equivalent) must have mode 0600 or less permissive. |
File permissions more permissive than 0600 for "/etc/news/passwd.nntp" may allow access to privileged information by system intruders or malicious users. |
|
Change the mode of the "/etc/news/passwd.nntp" file.
# chmod 0600 /etc/news/passwd.nntp |
V-4278 |
CCI-000225 |
medium |
The files in /etc/news must be group-owned by root or news. |
If critical system files do not have a privileged group-owner, system integrity could be compromised. |
|
Change the group-owner of the files in "/etc/news" to root or news.
Procedure:
# chgrp root /etc/news/* |
V-4295 |
CCE-4325-7 |
high |
The SSH daemon must be configured to only use the SSHv2 protocol. |
SSHv1 is not a DoD-approved protocol and has many well-known vulnerability exploits. Exploits of the SSH daemon could provide immediate root access to the system. |
|
Edit the sshd_config file and set the "Protocol" setting to "2". If using the F-Secure SSH server, set the "Ssh1Compatibility" setting to "no". |
V-4321 |
CCI-001436 |
medium |
The system must not run Samba unless needed. |
Samba is a tool used for the sharing of files and printers between Windows and UNIX operating systems. It provides access to sensitive files and, therefore, poses a security risk if compromised. |
|
If there is no functional need for Samba and the daemon is running, disable the daemon by killing the process ID as noted from the output of ps -ef |grep smbd. The samba package should also be removed or not installed if there is no functional requirement.
Procedure:
rpm -qa |grep samba
This will show whether "samba" or "samba3x" is installed. To remove:
rpm --erase samba
or
rpm --erase samba3x |
V-4334 |
CCI-000225 |
medium |
The /etc/sysctl.conf file must be owned by root. |
The sysctl.conf file specifies the values for kernel parameters to be set on boot. These settings can affect the system's security. |
|
Use the chown command to change the owner of /etc/sysctl.conf to root:
# chown root /etc/sysctl.conf |
V-4335 |
CCI-000225 |
medium |
The /etc/sysctl.conf file must be group-owned by root. |
The sysctl.conf file specifies the values for kernel parameters to be set on boot. These settings can affect the system's security. |
|
Use the chgrp command to change the group owner of /etc/sysctl.conf to root:
# chgrp root /etc/sysctl.conf |
V-4336 |
CCI-000225 |
medium |
The /etc/sysctl.conf file must have mode 0600 or less permissive. |
The sysctl.conf file specifies the values for kernel parameters to be set on boot. These settings can affect the system's security. |
|
Use the chmod command to change the mode of the /etc/sysctl.conf file.
# chmod 0600 /etc/sysctl.conf |
V-4342 |
CCI-000366 |
high |
The x86 CTRL-ALT-DELETE key sequence must be disabled. |
Undesirable reboots can occur if the CTRL-ALT-DELETE key sequence is not disabled. Such reboots may cause a loss of data or loss of access to critical information. |
|
Ensure the CTRL-ALT-DELETE key sequence has been disabled and attempts to use the sequence are logged.
In the /etc/inittab file replace:
ca::ctrlaltdel:/sbin/shutdown -t3 -r now
with
ca:nil:ctrlaltdel:/usr/bin/logger -p security.info "Ctrl-Alt-Del was pressed" |
V-4358 |
CCI-000225 |
medium |
The cron.deny file must have mode 0600 or less permissive. |
If file permissions for cron.deny are more permissive than 0600, sensitive information could be viewed or edited by unauthorized users.
|
|
Change the mode of the cron.deny file.
# chmod 0600 /etc/cron.deny |
V-4361 |
CCI-000225 |
medium |
The cron.allow file must be owned by root, bin, or sys. |
If the owner of the cron.allow file is not set to root, bin, or sys, the possibility exists for an unauthorized user to view or to edit sensitive information. |
|
# chown root /etc/cron.allow |
V-4364 |
CCI-000225 |
medium |
The "at" directory must have mode 0755 or less permissive. |
If the "at" directory has a mode more permissive than 0755, unauthorized users could be allowed to view or to edit files containing sensitive information within the "at" directory. Unauthorized modifications could result in Denial of Service to authorized "at" jobs. |
|
Change the mode of the "at" directory to 0755.
Procedure:
# chmod 0755 <at directory> |
V-4367 |
CCI-000225 |
medium |
The at.allow file must be owned by root, bin, or sys. |
If the owner of the at.allow file is not set to root, bin, or sys, unauthorized users could be allowed to view or edit sensitive information contained within the file. |
|
Change the owner of the at.allow file.
# chown root /etc/at.allow |
V-4368 |
CCI-000225 |
medium |
The at.deny file must be owned by root, bin, or sys. |
If the owner of the at.deny file is not set to root, bin, or sys, unauthorized users could be allowed to view or edit sensitive information contained within the file. |
|
Change the owner of the at.deny file.
# chown root /etc/at.deny |
V-4369 |
CCI-000225 |
medium |
The traceroute command owner must be root. |
If the traceroute command owner has not been set to root, an unauthorized user could use this command to obtain knowledge of the network topology inside the firewall. This information may allow an attacker to determine trusted routers and other network information potentially leading to system and network compromise. |
|
Change the owner of the traceroute command to root.
Example:
# chown root /bin/traceroute |
V-4370 |
CCI-000225 |
medium |
The traceroute command must be group-owned by sys, bin, root, or system. |
If the group owner of the traceroute command has not been set to a system group, unauthorized users could have access to the command and use it to gain information regarding a network's topology inside of the firewall. This information may allow an attacker to determine trusted routers and other network information potentially leading to system and network compromise. |
|
Change the group-owner of the traceroute command to root.
Procedure:
# chgrp root /bin/traceroute |
V-4371 |
CCI-000225 |
medium |
The traceroute file must have mode 0700 or less permissive. |
If the mode of the traceroute executable is more permissive than 0700, malicious code could be inserted by an attacker and triggered whenever the traceroute command is executed by authorized users. Additionally, if an unauthorized user is granted executable permissions to the traceroute command, it could be used to gain information about the network topology behind the firewall. This information may allow an attacker to determine trusted routers and other network information potentially leading to system and network compromise. |
|
Change the mode of the traceroute command.
# chmod 0700 /bin/traceroute |
V-4384 |
CCI-000366 |
low |
The SMTP service's SMTP greeting must not provide version information. |
The version of the SMTP service can be used by attackers to plan an attack based on vulnerabilities present in the specific version. |
|
Ensure sendmail or Postfix has been configured to mask the version information.
Procedure
for sendmail:
Change the O SmtpGreetingMessage line in the /etc/mail/sendmail.cf file as noted below:
O SmtpGreetingMessage=$j Sendmail $v/$Z; $b
change it to:
O SmtpGreetingMessage= Mail Server Ready ; $b
for Postfix:
Examine the "smtpd_banner" line of /etc/postfix/main.conf and remove any "$mail_version" entry on it or comment the entire "smtpd_banner" line to use the default value which does not display the version information. |
V-4385 |
CCI-000366 |
medium |
The system must not use .forward files. |
The .forward file allows users to automatically forward mail to another system. Use of .forward files could allow the unauthorized forwarding of mail and could potentially create mail loops which could degrade system performance. |
|
Disable forwarding for sendmail and remove .forward files from the system
Procedure:
Edit the /etc/mail/sendmail.mc file to change the ForwardPath entry to a null path by adding the line
define(`confFORWARD_PATH`,`')
rebuild the sendmail.cf file.
Remove all .forward files on the system
# find / -name .forward -delete |
V-4387 |
CCI-000225 |
high |
Anonymous FTP accounts must not have a functional shell. |
If an anonymous FTP account has been configured to use a functional shell, attackers could gain access to the shell if the account is compromised. |
|
Configure anonymous FTP accounts to use a non-functional shell. If necessary, edit the /etc/passwd file to remove any functioning shells associated with the ftp account and replace them with non-functioning shells, such as /dev/null. |
V-4393 |
CCI-000225 |
medium |
The /etc/syslog.conf file must be owned by root. |
If the /etc/syslog.conf file is not owned by root, unauthorized users could be allowed to view, edit, or delete important system messages handled by the syslog facility. |
|
Use the chown command to set the owner to root.
# chown root /etc/syslog.conf |
V-4394 |
CCI-000225 |
medium |
The /etc/syslog.conf file must be group-owned by root, bin, sys, or system. |
If the group owner of /etc/syslog.conf is not root, bin, or sys, unauthorized users could be permitted to view, edit, or delete important system messages handled by the syslog facility. |
|
Procedure:
# chgrp root /etc/syslog.conf |
V-4428 |
CCI-000225 |
medium |
All .rhosts, .shosts, .netrc, or hosts.equiv files must be accessible by only root or the owner. |
If these files are accessible by users other than root or the owner, they could be used by a malicious user to set up a system compromise. |
|
Ensure the permission for these files is set to 600 or more restrictive and their owner is root or the same as the owner of the home directory in which they reside.
Procedure:
# chmod 600 /etc/hosts.equiv
# chmod 600 /etc/ssh/shosts.equiv
# chown root /etc/hosts.equiv
# chown root /etc/ssh/shosts.equiv
# find / -name .rhosts
# chmod 600 /<home directory>/.rhosts
# chown <home directory owner> <home directory>/.rhosts
# find / -name .shosts
# chmod 600 <directory location>/.shosts
# chown <home directory owner> <home directory>/.shosts
# find / -name .netrc
# chmod 600 <directory location>/.netrc
# chown <home directory owner> <home directory>/.netrc |
V-4430 |
CCI-000225 |
medium |
The cron.deny file must be owned by root, bin, or sys. |
Cron daemon control files restrict the scheduling of automated tasks and must be protected.
|
|
# chown root /etc/cron.deny |
V-4687 |
CCE-4141-8 |
high |
The rsh daemon must not be running. |
The rshd process provides a typically unencrypted, host-authenticated remote access service. SSH should be used in place of this service. |
|
Edit /etc/xinetd.d/rsh and set "disable=yes". |
V-4688 |
CCI-001435 |
high |
The rexec daemon must not be running. |
The rexecd process provides a typically unencrypted, host-authenticated remote access service. SSH should be used in place of this service. |
|
Edit /etc/xinetd.d/rexec and set "disable=yes" |
V-4692 |
CCI-000366 |
low |
The SMTP service must not have the EXPN feature active. |
The SMTP EXPN function allows an attacker to determine if an account exists on a system, providing significant assistance to a brute force attack on user accounts. EXPN may also provide additional information concerning users on the system, such as the full names of account owners. |
|
Rebuild /etc/mail/sendmail.cf with the "noexpn" Privacy Flag set.
Procedure:
Edit /etc/mail/sendmail.mc resetting the Privacy Flags to the default:
define('confPRIVACYFLAGS', 'authwarnings,novrfy,noexpn,restrictqrun')dnl
Rebuild the sendmail.cf file with:
# make -C /etc/mail
Restart the sendmail service.
# service sendmail restart |
V-4693 |
CCI-000366 |
low |
The SMTP service must not have the Verify (VRFY) feature active. |
The VRFY command allows an attacker to determine if an account exists on a system, providing significant assistance to a brute force attack on user accounts. VRFY may provide additional information about users on the system, such as the full names of account owners. |
|
Add the "novrfy" flag to your sendmail in /etc/mail/sendmail.cf.
Procedure:
Edit the definition of "confPRIVACY_FLAGS" in /etc/mail/sendmail.mc to include "novrfy".
Rebuild the sendmail.cf file with:
# make -C /etc/mail
Restart the sendmail service.
# service sendmail restart |
V-4696 |
CCI-001436 |
medium |
The system must not have the UUCP service active. |
The UUCP utility is designed to assist in transferring files, executing remote commands, and sending e-mail between UNIX systems over phone lines and direct connections between systems. The UUCP utility is a primitive and arcane system with many security issues. There are alternate data transfer utilities/products that can be configured to more securely transfer data by providing for authentication as well as encryption. |
|
# chkconfig uucp off
# service uucp stop
# service xinetd restart |
V-11940 |
CCI-001230 |
high |
The operating system must be a supported release. |
An operating system release is considered "supported" if the vendor continues to provide security patches for the product. With an unsupported release, it will not be possible to resolve security issues discovered in the system software. |
|
Upgrade to a supported version of the operating system. |
V-11947 |
CCE-4154-1 |
medium |
The system must require passwords contain a minimum of 14 characters. |
The use of longer passwords reduces the ability of attackers to successfully obtain valid passwords using guessing or exhaustive search techniques by increasing the password search space. |
|
Edit "/etc/pam.d/system-auth" to include the line:
password required pam_cracklib.so minlen=14
prior to the "password include system-auth-ac" line. |
V-11948 |
CCE-14672-0 |
medium |
The system must require passwords contain at least one uppercase alphabetic character. |
To enforce the use of complex passwords, minimum numbers of characters of different classes are mandated. The use of complex passwords reduces the ability of attackers to successfully obtain valid passwords using guessing or exhaustive search techniques. Complexity requirements increase the password search space by requiring users to construct passwords from a larger character set than they may otherwise use. |
|
Edit "/etc/pam.d/system-auth" to include the line:
password required pam_cracklib.so ucredit=-1
prior to the "password include system-auth-ac" line. |
V-11972 |
CCE-14113-5 |
medium |
The system must require passwords contain at least one numeric character. |
To enforce the use of complex passwords, minimum numbers of characters of different classes are mandated. The use of complex passwords reduces the ability of attackers to successfully obtain valid passwords using guessing or exhaustive search techniques. Complexity requirements increase the password search space by requiring users to construct passwords from a larger character set than they may otherwise use. |
|
Edit "/etc/pam.d/system-auth" to include the line:
password required pam_cracklib.so dcredit=-1
prior to the "password include system-auth-ac" line. |
V-11973 |
CCE-14122-6 |
medium |
The system must require passwords contain at least one special character. |
To enforce the use of complex passwords, minimum numbers of characters of different classes are mandated. The use of complex passwords reduces the ability of attackers to successfully obtain valid passwords using guessing or exhaustive search techniques. Complexity requirements increase the password search space by requiring users to construct passwords from a larger character set than they may otherwise use. |
|
Edit "/etc/pam.d/system-auth" to include the line:
password required pam_cracklib.so ocredit=-1
prior to the "password include system-auth-ac" line. |
V-11975 |
CCI-000366 |
medium |
The system must require passwords contain no more than three consecutive repeating characters. |
To enforce the use of complex passwords, the number of consecutive repeating characters is limited. Passwords with excessive repeated characters may be more vulnerable to password-guessing attacks. |
|
Edit "/etc/pam.d/system-auth" to include the line:
password required pam_cracklib.so maxrepeat=3
prior to the "password include system-auth-ac" line. |
V-11976 |
CCE-4092-3 |
medium |
User passwords must be changed at least every 60 days. |
Limiting the lifespan of authenticators limits the period of time an unauthorized user has access to the system while using compromised credentials and reduces the period of time available for password-guessing attacks to run against a single password. |
|
Set the max days field to 60 for all user accounts.
# passwd -x 60 <user> |
V-11981 |
CCI-000225 |
medium |
All global initialization files must have mode 0644 or less permissive. |
Global initialization files are used to configure the user's shell environment upon login. Malicious modification of these files could compromise accounts upon logon. |
|
Change the mode of the global initialization file(s) to 0644.
# chmod 0644 <global initialization file> |
V-11982 |
CCI-000225 |
medium |
All global initialization files must be owned by root. |
Global initialization files are used to configure the user's shell environment upon login. Malicious modification of these files could compromise accounts upon logon. Failure to give ownership of sensitive files or utilities to root or bin provides the designated owner and unauthorized users with the potential to access sensitive information or change the system configuration which could weaken the system's security posture. |
|
Change the ownership of global initialization files with incorrect ownership.
Procedure:
# chown root <global initialization files>
or:
# ls etc/bashrc /etc/csh.cshrc /etc/csh.login /etc/csh.logout /etc/environment /etc/ksh.kshrc /etc/profile /etc/suid_profile /etc/profile.d/* 2>null|xargs stat -L -c %U:%n|egrep -v "^root"|cut -d: -f2|xargs chown root
will set the owner of all files not currently owned by root to root. |
V-11983 |
CCI-000225 |
medium |
All global initialization files must be group-owned by root, sys, bin, other, system, or the system default. |
Global initialization files are used to configure the user's shell environment upon login. Malicious modification of these files could compromise accounts upon logon. Failure to give ownership of sensitive files or utilities to root or bin provides the designated owner and unauthorized users with the potential to access sensitive information or change the system configuration which could weaken the system's security posture. |
|
Change the group ownership of the global initialization file(s) with incorrect group ownership.
Procedure:
# chgrp root <global initialization file>
or:
# ls -lL /etc/bashrc /etc/csh.cshrc /etc/csh.login /etc/csh.logout /etc/environment /etc/ksh.kshrc /etc/profile /etc/suid_profile /etc/profile.d/* 2>null|sed "s/^[^\/]*//"|xargs stat -L -c %G:%n|egrep -v "^(root|sys|bin|other):"|cut -d: -f2|xargs chgrp root
will set the group of all files not currently owned by an approved group to root. |
V-11984 |
CCI-000225 |
medium |
All skeleton files and directories (typically in /etc/skel) must be owned by root or bin. |
If the skeleton files are not protected, unauthorized personnel could change user startup parameters and possibly jeopardize user files. Failure to give ownership of sensitive files or utilities to root or bin provides the designated owner and unauthorized users with the potential to access sensitive information or change the system configuration which could weaken the system's security posture. |
|
Change the ownership of skeleton files with incorrect mode:
# chown root <skeleton file>
or
# ls -L /etc/skel|xargs stat -L -c %U:%n|egrep -v "^(root|bin):"|cut -d: -f2|chown root
will change all files not owned by root or bin to root. |
V-11985 |
CCI-000366 |
medium |
All global initialization files' executable search paths must contain only absolute paths. |
The executable search path (typically the PATH environment variable) contains a list of directories for the shell to search to find executables. If this path includes the current working directory or other relative paths, executables in these directories may be executed instead of system commands. This variable is formatted as a colon-separated list of directories. If there is an empty entry, such as a leading or trailing colon, or two consecutive colons, this is interpreted as the current working directory. Paths starting with a slash (/) are absolute paths. |
|
Edit the global initialization file(s) with PATH variables containing relative paths. Edit the file and remove the relative path from the PATH variable. |
V-11986 |
CCI-000366 |
medium |
All local initialization files' executable search paths must contain only absolute paths. |
The executable search path (typically the PATH environment variable) contains a list of directories for the shell to search to find executables. If this path includes the current working directory or other relative paths, executables in these directories may be executed instead of system commands. This variable is formatted as a colon-separated list of directories. If there is an empty entry, such as a leading or trailing colon, or two consecutive colons, this is interpreted as the current working directory. Paths starting with a slash (/) are absolute paths. |
|
Edit the local initialization file and remove the relative path entry from the executable search path variable. If this is not feasable, justify and document the necessity of having the relative path for a specific application. |
V-11988 |
CCI-000366 |
high |
There must be no .rhosts, .shosts, hosts.equiv, or shosts.equiv files on the system. |
The .rhosts, .shosts, hosts.equiv, and shosts.equiv files are used to configure host-based authentication for individual users or the system. Host-based authentication is not sufficient for preventing unauthorized access to the system. |
|
Remove all the r-commands access control files.
Procedure:
# find / -name .rhosts -exec rm {} \;
# find / -name .shosts -exec rm {} \;
# find / -name hosts.equiv -exec rm {} \;
# find / -name shosts.equiv -exec rm {} \; |
V-11989 |
CCI-000366 |
medium |
The .rhosts file must not be supported in PAM. |
.rhosts files are used to specify a list of hosts permitted remote access to a particular account without authenticating. The use of such a mechanism defeats strong identification and authentication requirements. |
|
Edit the file(s) in /etc/pam.d referencing the rhosts_auth module, and remove the references to the rhosts_auth module. |
V-11995 |
CCI-000225 |
medium |
Default system accounts (with the exception of root) must not be listed in the cron.allow file or must be included in the cron.deny file, if cron.allow does not exist. |
To centralize the management of privileged account crontabs, of the default system accounts, only root may have a crontab. |
|
Remove default system accounts (such as bin, sys, adm, or others, traditionally UID less than 500) from the cron.allow file if it exists, or add those accounts to the cron.deny file. |
V-11996 |
CCE-4225-9 |
low |
Process core dumps must be disabled unless needed. |
Process core dumps contain the memory in use by the process when it crashed. Process core dump files can be of significant size and their use can result in file systems filling to capacity, which may result in Denial of Service. Process core dumps can be useful for software debugging. |
|
Edit /etc/security/limits.conf and set a hard limit for "core" to 0 for all users. |
V-11997 |
CCI-000225 |
low |
The kernel core dump data directory must be owned by root. |
Kernel core dumps may contain the full contents of system memory at the time of the crash. As the system memory may contain sensitive information, it must be protected accordingly. If the kernel core dump data directory is not owned by root, the core dumps contained in the directory may be subject to unauthorized access. |
|
Change the owner of the kernel core dump data directory to root.
# chown root /var/crash |
V-11999 |
CCI-000366 |
medium |
The system must implement non-executable program stacks. |
A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. |
|
Examine /etc/sysctl.conf for "kernel.exec-shield" and "kernel.randomize_va_space" entries and if found remove them. The system default of "1" enables these modules. |
V-12002 |
CCE-4236-6 |
medium |
The system must not forward IPv4 source-routed packets. |
Source-routed packets allow the source of the packet to suggest routers forward the packet along a different path than configured on the router, which can be used to bypass network security measures. This requirement applies only to the forwarding of source-routed traffic, such as when IPv4 forwarding is enabled and the system is functioning as a router. |
|
Configure the system to not accept source-routed IPv4 packets.
Edit /etc/sysctl.conf and add a setting for "net.ipv4.conf.all.accept_source_route=0" and "net.ipv4.conf.default.accept_source_route=0".
Reload the sysctls.
Procedure:
# sysctl -p |
V-12003 |
CCI-001208 |
low |
A separate file system must be used for user home directories (such as /home or an equivalent). |
The use of separate file systems for different paths can protect the system from failures resulting from a file system becoming full or failing. |
|
Migrate the /home (or equivalent) path onto a separate file system. |
V-12004 |
CCI-000126 |
medium |
The system must log informational authentication data. |
Monitoring and recording successful and unsuccessful logins assists in tracking unauthorized access to the system. |
|
Edit /etc/syslog.conf and add local log destinations for "authpriv.*", "authpriv.debug" or "authpriv.info". |
V-12005 |
CCI-000305 |
medium |
Inetd and xinetd must be disabled or removed if no network services utilizing them are enabled. |
Unnecessary services should be disabled to decrease the attack surface of the system. |
|
# service xinetd stop ; chkconfig xinetd off |
V-12006 |
CCI-000366 |
medium |
The SMTP service HELP command must not be enabled. |
The HELP command should be disabled to mask version information. The version of the SMTP service software could be used by attackers to target vulnerabilities present in specific software versions. |
|
To disable the SMTP HELP command, remove /etc/mail/helpfile. |
V-12011 |
CCI-000225 |
medium |
All FTP users must have a default umask of 077. |
The umask controls the default access mode assigned to newly created files. An umask of 077 limits new files to mode 700 or less permissive. Although umask is stored as a 4-digit number, the first digit representing special access modes is typically ignored or required to be zero (0). |
|
Edit the initialization files for the ftp user and set the umask to 077.
Procedure:
For gssftp:
Modify the /etc/xinetd.d/gssftp file adding "-u 077" to the server_args entry.
For vsftp:
Modify the "/etc/vsftpd/vsftpd.conf" setting "local_umask" and "anon_umask" to 077. |
V-12019 |
CCI-000225 |
medium |
The snmpd.conf file must be owned by root. |
The snmpd.conf file contains authenticators and must be protected from unauthorized access and modification. If the file is not owned by root, it may be subject to access and modification from unauthorized users. |
|
Change the owner of the snmpd.conf file to root.
Procedure:
# chown root <snmpd.conf file> |
V-12023 |
CCE-3561-8 |
medium |
IP forwarding for IPv4 must not be enabled, unless the system is a router. |
If the system is configured for IP forwarding and is not a designated router, it could be used to bypass network security by providing a path for communication not filtered by network devices. |
|
Edit "/etc/sysctl.conf" and set net.ipv4.ip_forward to "0". Restart the system or run "sysctl -p" to make the change take effect. |
V-12030 |
CCI-000366 |
medium |
The system's access control program must be configured to grant or deny system access to specific hosts. |
If the system's access control program is not configured with appropriate rules for allowing and denying access to system network resources, services may be accessible to unauthorized hosts. |
|
Edit the "/etc/hosts.all" and "/etc/hosts.deny" files to configure access restrictions. |
V-12039 |
CCI-000225 |
medium |
The /etc/securetty file must be owned by root. |
The securetty file contains the list of terminals permitting direct root logins. It must be protected from unauthorized modification. |
|
Change the owner of the /etc/securetty file to root.
Procedure:
# chown root /etc/securetty |
V-12040 |
CCI-000225 |
medium |
The /etc/securetty file must have mode 0640 or less permissive. |
The securetty file contains the list of terminals permitting direct root logins. It must be protected from unauthorized modification. |
|
Change the mode of the /etc/securetty file to 0600.
Procedure:
# chmod 0600 /etc/securetty |
V-22290 |
CCI-000366 |
medium |
The system clock must be synchronized continuously, or at least daily. |
A synchronized system clock is critical for the enforcement of time-based policies and the correlation of logs and audit records with other systems. Internal system clocks tend to drift and require periodic resynchronization to ensure their accuracy. Software, such as ntpd, can be used to continuously synchronize the system clock with authoritative sources. Alternatively, the system may be synchronized periodically, with a maximum of one day between synchronizations.
If the system is completely isolated (i.e., it has no connections to networks or other systems), time synchronization is not required as no correlation of events or operation of time-dependent protocols between systems will be necessary. If the system is completely isolated, this requirement is not applicable. |
|
Enable the NTP daemon for continuous synchronization.
# service ntpd start ; chkconfig ntpd on
OR
Add a daily or more frequent cronjob to perform synchronization using ntpdate. |
V-22294 |
CCI-000225 |
medium |
The time synchronization configuration file (such as /etc/ntp.conf) must be owned by root. |
A synchronized system clock is critical for the enforcement of time-based policies and the correlation of logs and audit records with other systems. If an illicit time source is used for synchronization, the integrity of system logs and the security of the system could be compromised. If the configuration files controlling time synchronization are not owned by a system account, unauthorized modifications could result in the failure of time synchronization. |
|
Change the owner of the NTP configuration file.
# chown root /etc/ntp.conf |
V-22296 |
CCI-000225 |
medium |
The time synchronization configuration file (such as /etc/ntp.conf) must have mode 0640 or less permissive. |
A synchronized system clock is critical for the enforcement of time-based policies and the correlation of logs and audit records with other systems. If an illicit time source is used for synchronization, the integrity of system logs and the security of the system could be compromised. If the configuration files controlling time synchronization are not protected, unauthorized modifications could result in the failure of time synchronization. |
|
Change the mode of the NTP configuration file to 0640 or more restrictive.
# chmod 0640 /etc/ntp.conf |
V-22298 |
CCI-000054 |
low |
The system must limit users to 10 simultaneous system logins, or a site-defined number, in accordance with operational requirements. |
Limiting simultaneous user logins can insulate the system from denial of service problems caused by excessive logins. Automated login processes operating improperly or maliciously may result in an exceptional number of simultaneous login sessions.
If the defined value of 10 logins does not meet operational requirements, the site may define the permitted number of simultaneous login sessions based on operational requirements.
This limit is for the number of simultaneous login sessions for EACH user account. This is NOT a limit on the total number of simultaneous login sessions on the system. |
|
Add a "maxlogins" line such as "* hard maxlogins 10" to /etc/security/limits.conf or a file in /etc/security/limits.d. The enforced maximum should be defined by site requirements and policy. |
V-22302 |
CCI-000205 |
medium |
The system must enforce compliance of the entire password during authentification. |
Some common password hashing schemes only process the first eight characters of a user's password, which reduces the effective strength of the password. |
|
Change the passwords for all accounts using non-compliant password hashes.
(This requires GEN000590 is already met.) |
V-22303 |
CCE-14063-2 |
medium |
The system must use a FIPS 140-2 approved cryptographic hashing algorithm for generating account password hashes. |
Systems must employ cryptographic hashes for passwords using the SHA-2 family of algorithms or FIPS 140-2 approved successors. The use of unapproved algorithms may result in weak password hashes more vulnerable to compromise. |
|
Change the default password algorithm.
# authconfig --passalgo=sha512 --update |
V-22304 |
CCI-000196 |
medium |
The password hashes stored on the system must have been generated using a FIPS 140-2 approved cryptographic hashing algorithm. |
Systems must employ cryptographic hashes for passwords using the SHA-2 family of algorithms or FIPS 140-2 approved successors. The use of unapproved algorithms may result in weak password hashes more vulnerable to compromise. |
|
Change the passwords for all accounts using non-compliant password hashes.
(This requires GEN000590 is already met.) |
V-22305 |
CCE-14712-4 |
medium |
The system must require passwords contain at least one lowercase alphabetic character. |
To enforce the use of complex passwords, minimum numbers of characters of different classes are mandated. The use of complex passwords reduces the ability of attackers to successfully obtain valid passwords using guessing or exhaustive search techniques. Complexity requirements increase the password search space by requiring users to construct passwords from a larger character set than they may otherwise use. |
|
Edit "/etc/pam.d/system-auth" to include the line:
password required pam_cracklib.so lcredit=-1
prior to the "password include system-auth-ac" line. |
V-22306 |
CCE-14701-7 |
medium |
The system must require at least four characters be changed between the old and new passwords during a password change. |
To ensure password changes are effective in their goals, the system must ensure that old and new passwords have significant differences. Without significant changes, new passwords may be easily guessed based on the value of a previously compromised password. |
|
If /etc/pam.d/system-auth references /etc/pam.d/system-auth-ac refer to the man page for system-auth-ac for a description of how to add options not configurable with authconfig. Edit /etc/pam.d/system-auth and add or edit a pam_cracklib entry with an difok parameter set equal to or greater than 4. |
V-22307 |
CCI-000189 |
medium |
The system must prevent the use of dictionary words for passwords. |
An easily guessable password provides an open door to any external or internal malicious intruder. Many computer compromises occur as the result of account name and password guessing. This is generally done by someone with an automated script that uses repeated logon attempts until the correct account and password pair is guessed. Utilities, such as cracklib, can be used to validate passwords are not dictionary words and meet other criteria during password changes. |
|
If /etc/pam.d/system-auth references /etc/pam.d/system-auth-ac refer to the man page for system-auth-ac for a description of how to add options not configurable with authconfig. Edit /etc/pam.d/system-auth and configure pam_cracklib by adding a line such as "password required pam_cracklib.so" |
V-22308 |
CCE-15047-4 |
low |
The system must restrict the ability to switch to the root user to members of a defined group. |
Configuring a supplemental group for users permitted to switch to the root user prevents unauthorized users from accessing the root account, even with knowledge of the root credentials. |
|
Edit /etc/pam.d/su and uncomment or add a line such as "auth required pam_wheel.so". If necessary, create a "wheel" group and add administrative users to the group. |
V-22310 |
CCI-000366 |
medium |
The root account's library search path must be the system default and must contain only absolute paths. |
The library search path environment variable(s) contain a list of directories for the dynamic linker to search to find libraries. If this path includes the current working directory or other relative paths, libraries in these directories may be loaded instead of system libraries. This variable is formatted as a colon-separated list of directories. If there is an empty entry, such as a leading or trailing colon or two consecutive colons, this is interpreted as the current working directory. Entries starting with a slash (/) are absolute paths. |
|
Edit the root user initialization files and remove any definition of LD_LIBRARY_PATH. |
V-22311 |
CCI-000366 |
medium |
The root account's list of preloaded libraries must be empty. |
The library preload list environment variable contains a list of libraries for the dynamic linker to load before loading the libraries required by the binary. If this list contains paths to libraries relative to the current working directory, unintended libraries may be preloaded. This variable is formatted as a space-separated list of libraries. Paths starting with (/) are absolute paths. |
|
Edit the root user initialization files and remove any definition of LD_PRELOAD. |
V-22319 |
CCI-000225 |
medium |
The /etc/resolv.conf file must be owned by root. |
The resolv.conf (or equivalent) file configures the system's DNS resolver. DNS is used to resolve host names to IP addresses. If DNS configuration is modified maliciously, host name resolution may fail or return incorrect information. DNS may be used by a variety of system security functions such as time synchronization, centralized authentication, and remote system logging.
|
|
Change the owner of the /etc/resolv.conf file to root.
# chown root /etc/resolv.conf |
V-22321 |
CCI-000225 |
medium |
The /etc/resolv.conf file must have mode 0644 or less permissive. |
The resolv.conf (or equivalent) file configures the system's DNS resolver. DNS is used to resolve host names to IP addresses. If DNS configuration is modified maliciously, host name resolution may fail or return incorrect information. DNS may be used by a variety of system security functions such as time synchronization, centralized authentication, and remote system logging. |
|
Change the mode of the /etc/resolv.conf file to 0644.
# chmod 0644 /etc/resolv.conf |
V-22323 |
CCI-000225 |
medium |
The /etc/hosts file must be owned by root. |
The /etc/hosts file (or equivalent) configures local host name to IP address mappings that typically take precedence over DNS resolution. If this file is maliciously modified, it could cause the failure or compromise of security functions requiring name resolution, which may include time synchronization, centralized authentication, and remote system logging. |
|
Change the owner of the /etc/hosts file to root.
# chown root /etc/hosts |
V-22325 |
CCI-000225 |
medium |
The /etc/hosts file must have mode 0644 or less permissive. |
The /etc/hosts file (or equivalent) configures local host name to IP address mappings that typically take precedence over DNS resolution. If this file is maliciously modified, it could cause the failure or compromise of security functions requiring name resolution, which may include time synchronization, centralized authentication, and remote system logging. |
|
Change the mode of the /etc/hosts file to 0644.
# chmod 0644 /etc/hosts |
V-22327 |
CCI-000225 |
medium |
The /etc/nsswitch.conf file must be owned by root. |
The nsswitch.conf file (or equivalent) configures the source of a variety of system security information including account, group, and host lookups. Malicious changes could prevent the system from functioning or compromise system security. |
|
Change the owner of the /etc/nsswitch.conf file to root.
# chown root /etc/nsswitch.conf |
V-22328 |
CCI-000225 |
medium |
The /etc/nsswitch.conf file must be group-owned by root, bin, or sys. |
The nsswitch.conf file (or equivalent) configures the source of a variety of system security information including account, group, and host lookups. Malicious changes could prevent the system from functioning or compromise system security. |
|
Change the group-owner of the /etc/nsswitch.conf file to root, bin or sys.
Procedure:
# chgrp root /etc/nsswitch.conf |
V-22329 |
CCI-000225 |
medium |
The /etc/nsswitch.conf file must have mode 0644 or less permissive. |
The nsswitch.conf file (or equivalent) configures the source of a variety of system security information including account, group, and host lookups. Malicious changes could prevent the system from functioning or compromise system security. |
|
Change the mode of the /etc/nsswitch.conf file to 0644 or less permissive.
# chmod 0644 /etc/nsswitch.conf |
V-22332 |
CCE-3958-6 |
medium |
The /etc/passwd file must be owned by root. |
The /etc/passwd file contains the list of local system accounts. It is vital to system security and must be protected from unauthorized modification. |
|
Change the owner of the /etc/passwd file to root.
# chown root /etc/passwd |
V-22333 |
CCI-000225 |
medium |
The /etc/passwd file must be group-owned by root, bin, or sys. |
The /etc/passwd file contains the list of local system accounts. It is vital to system security and must be protected from unauthorized modification. |
|
Change the group-owner of the /etc/passwd file to root, bin or sys.
Procedure:
# chgrp root /etc/passwd |
V-22335 |
CCE-3276-3 |
medium |
The /etc/group file must be owned by root. |
The /etc/group file is critical to system security and must be owned by a privileged user. The group file contains a list of system groups and associated information. |
|
Change the owner of the /etc/group file to root.
# chown root /etc/group |
V-22336 |
CCE-3495-9 |
medium |
The /etc/group file must be group-owned by root, bin, or sys. |
The /etc/group file is critical to system security and must be protected from unauthorized modification. The group file contains a list of system groups and associated information. |
|
Change the group-owner of the /etc/group file.
Procedure:
# chgrp root /etc/group |
V-22337 |
CCE-3967-7 |
medium |
The /etc/group file must have mode 0644 or less permissive. |
The /etc/group file is critical to system security and must be protected from unauthorized modification. The group file contains a list of system groups and associated information. |
|
Change the mode of the /etc/group file to 0644 or less permissive.
# chmod 0644 /etc/group |
V-22339 |
CCE-3988-3 |
medium |
The /etc/shadow file (or equivalent) must be group-owned by root, bin,or sys. |
The /etc/shadow file contains the list of local system accounts. It is vital to system security and must be protected from unauthorized modification. The file also contains password hashes which must not be accessible to users other than root. |
|
Change the group-owner of the /etc/shadow file.
Procedure:
# chgrp root /etc/shadow |
V-22341 |
CCE-4210-1 |
medium |
The /etc/gshadow file must be owned by root. |
The /etc/gshadow file is critical to system security and must be owned by a privileged user. The /etc/gshadow file contains a list of system groups and hashes for group passwords. |
|
Change the owner of the /etc/gshadow file to root.
# chown root /etc/gshadow |
V-22342 |
CCE-4064-2 |
medium |
The /etc/gshadow file must be group-owned by root. |
The /etc/gshadow file is critical to system security and must be protected from unauthorized modification. The /etc/gshadow file contains a list of system groups and hashes for group passwords. |
|
Change the group-owner of the /etc/gshadow file to root.
# chgrp root /etc/gshadow |
V-22343 |
CCE-3932-1 |
medium |
The /etc/gshadow file must have mode 0400. |
The /etc/gshadow file is critical to system security and must be protected from unauthorized modification. The /etc/gshadow file contains a list of system groups and hashes for group passwords. |
|
Change the mode of the /etc/gshadow file to 0400 or less permissive.
# chmod 0400 /etc/gshadow |
V-22347 |
CCI-000201 |
medium |
The /etc/passwd file must not contain password hashes. |
If password hashes are readable by non-administrators, the passwords are subject to attack through lookup tables or cryptographic weaknesses in the hashes. |
|
Migrate /etc/passwd password hashes to /etc/shadow.
# pwconv |
V-22348 |
CCI-000225 |
medium |
The /etc/group file must not contain any group password hashes. |
Group passwords are typically shared and should not be used. Additionally, if password hashes are readable by non-administrators, the passwords are subject to attack through lookup tables or cryptographic weaknesses in the hashes. |
|
Edit /etc/group and change the password field to an exclamation point (!) to lock the group password. |
V-22349 |
CCI-000366 |
medium |
The /etc/gshadow file must not contain any group password hashes. |
Group passwords are typically shared and should not be used. |
|
Edit /etc/gshadow and change the password field to an exclamation point (!) to lock the group password. |
V-22355 |
CCI-000366 |
medium |
Run control scripts' lists of preloaded libraries must contain only absolute paths. |
The library preload list environment variable contains a list of libraries for the dynamic linker to load before loading the libraries required by the binary. If this list contains paths to libraries relative to the current working directory, unintended libraries may be preloaded. This variable is formatted as a space-separated list of libraries. Paths starting with a slash (/) are absolute paths. |
|
Edit the run control script and remove the relative path entry from the library preload variable. |
V-22358 |
CCI-000225 |
medium |
All skeleton files (typically in /etc/skel) must be group-owned by root, bin, sys, system, or other. |
If the skeleton files are not protected, unauthorized personnel could change user startup parameters and possibly jeopardize user files. |
|
Change the group-owner of the skeleton file to root, bin, sys, system, or other.
Procedure:
# chgrp <group> /etc/skel/[skeleton file]
or:
# ls -L /etc/skel|xargs stat -L -c %G:%n|egrep -v "^(root|bin|sy|sytem|other):"|cut -d: -f2|chgrp root
will change the group of all files not already one of the approved group to root. |
V-22365 |
CCI-000225 |
medium |
All shell files must be group-owned by root, bin, sys, or system. |
If shell files are group-owned by users other than root or a system group, they could be modified by intruders or malicious users to perform unauthorized actions. |
|
Change the group-owner of the shell to root, bin, sys, or system.
Procedure:
# chgrp root <shell> |
V-22370 |
CCI-001493 |
low |
System audit tool executables must be owned by root. |
To prevent unauthorized access or manipulation of system audit logs, the tools for manipulating those logs must be protected. |
|
Change the owner of the audit tool executable to root.
# chown root [audit tool executable] |
V-22371 |
CCI-001493 |
low |
System audit tool executables must be group-owned by root, bin, sys, or system. |
To prevent unauthorized access or manipulation of system audit logs, the tools for manipulating those logs must be protected. |
|
Change the group-owner of the audit tool executable to root, bin, sys, or system.
Procedure:
# chgrp root <audit tool executable> |
V-22372 |
CCI-001493 |
low |
System audit tool executables must have mode 0750 or less permissive. |
To prevent unauthorized access or manipulation of system audit logs, the tools for manipulating those logs must be protected. |
|
Change the mode of the audit tool executable to 0750, or less permissive.
# chmod 0750 [audit tool executable] |
V-22374 |
CCI-000139 |
low |
The audit system must alert the SA in the event of an audit processing failure. |
An accurate and current audit trail is essential for maintaining a record of system activity. If the system fails, the SA must be notified and must take prompt action to correct the problem.
Minimally, the system must log this event and the SA will receive this notification during the daily system log review. If feasible, active alerting (such as e-mail or paging) should be employed consistent with the site’s established operations management systems and procedures. |
|
Edit /etc/audit/auditd.conf and set the disk_full_action and/or disk_error_action parameters to a valid setting of "syslog", "exec", "single" or "halt", adding the parameters if necessary. |
V-22375 |
CCI-000143 |
medium |
The audit system must alert the SA when the audit storage volume approaches its capacity. |
An accurate and current audit trail is essential for maintaining a record of system activity. If the system fails, the SA must be notified and must take prompt action to correct the problem.
Minimally, the system must log this event and the SA will receive this notification during the daily system log review. If feasible, active alerting (such as e-mail or paging) should be employed consistent with the site’s established operations management systems and procedures. |
|
Edit /etc/audit/auditd.conf and set the space_left_action parameter to a valid setting other than "ignore". If the space_left_action parameter is set to "email" set the action_mail_acct parameter to an e-mail address for the system administrator. |
V-22376 |
CCI-000018 |
low |
The audit system must be configured to audit account creation. |
If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises, and damages incurred during a system compromise. |
|
Configure execute auditing of the useradd and groupadd executables.
Add the following to audit.rules:
-w /usr/sbin/useradd -p x -k useradd
-w /usr/sbin/groupadd -p x -k groupadd
Configure append auditing of the passwd, shadow, group, and gshadow files. Add the following to audit.rules:
-w /etc/passwd -p a -k passwd
-w /etc/shadow -p a -k shadow
-w /etc/group -p a -k group
-w /etc/gshadow -p a -k gshadow
Restart the auditd service. |
V-22377 |
CCI-001403 |
low |
The audit system must be configured to audit account modification. |
If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise. |
|
Configure execute auditing of the usermod and groupmod executables. Add the following to the audit.rules file:
-w /usr/sbin/usermod -p x -k usermod
-w /usr/sbin/groupmod -p x -k groupmod
Configure append auditing of the passwd, shadow, group, and gshadow files. Add the following to the audit.rules file:
-w /etc/passwd -p w -k passwd
-w /etc/shadow -p w -k shadow
-w /etc/group -p w -k group
-w /etc/gshadow -p w -k gshadow
Restart the auditd service. |
V-22378 |
CCI-001404 |
low |
The audit system must be configured to audit account disabling. |
If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise. |
|
Configure execute auditing of the passwd executable. Add the following to the audit.rules file:
-w /usr/bin/passwd -p x -k passwd
Restart the auditd service. |
V-22382 |
CCI-001405 |
low |
The audit system must be configured to audit account termination. |
If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise. |
|
Configure execute auditing of the userdel and groupdel executables. Add the following to the audit.rules file:
-w /usr/sbin/userdel -p x
-w /usr/sbin/groupdel -p x
Restart the auditd service. |
V-22383 |
CCE-14688-6 |
medium |
The audit system must be configured to audit the loading and unloading of dynamic kernel modules. |
Actions concerning dynamic kernel modules must be recorded as they are substantial events. Dynamic kernel modules can increase the attack surface of a system. A malicious kernel module can be used to substantially alter the functioning of a system, often with the purpose of hiding a compromise from the SA. |
|
The "-F arch=<ARCH>" restriction is required on dual-architecture systems (such as x86_64). On dual-architecture systems, two separate rules must exist - one for each architecture supported. Use the generic architectures "b32" and "b64" for specifying these rules.
On single architecture systems, the "-F arch=<ARCH>" restriction may be omitted, but if present must match either the architecture of the system or its corresponding generic architecture. The architecture of the system may be determined by running "uname -m". See the auditctl(8) manpage for additional details.
Any restrictions (such as with "-F") beyond those provided in the example rules are not in strict compliance with this requirement, and are a finding unless justified and documented appropriately.
The use of audit keys consistent with the provided example is encouraged to provide for uniform audit logs, however omitting the audit key or using an alternate audit key is not a finding.
Procedure:
Configure auditing of the init_module syscalls.
Add the following to the "etc/audit/audit.rules" or "etc/audit.rules" file:
-a exit,always -S init_module
Restart the auditd service.
# service auditd restart |
V-22385 |
CCI-000225 |
medium |
Crontab files must be group-owned by root, cron, or the crontab creator's primary group. |
To protect the integrity of scheduled system jobs and prevent malicious modification to these jobs, crontab files must be secured. |
|
Change the group owner of the crontab file to root, cron, or the crontab's primary group.
Procedure:
# chgrp root [crontab file] |
V-22391 |
CCI-000225 |
medium |
The cron.allow file must be group-owned by root, bin, sys, or cron. |
If the group of the cron.allow is not set to root, bin, sys, or cron, the possibility exists for an unauthorized user to view or edit the list of users permitted to use cron. Unauthorized modification of this file could cause Denial of Service to authorized cron users or provide unauthorized users with the ability to run cron jobs. |
|
Change the group ownership of the file.
Procedure:
# chgrp root /etc/cron.allow |
V-22392 |
CCI-000225 |
medium |
The at.deny file must have mode 0600 or less permissive. |
The "at" daemon control files restrict access to scheduled job manipulation and must be protected. Unauthorized modification of the at.deny file could result in Denial of Service to authorized "at" users or provide unauthorized users with the ability to run "at" jobs. |
|
Change the mode of the file.
# chmod 0600 /etc/at.deny |
V-22396 |
CCI-000225 |
medium |
The "at" directory must be group-owned by root, bin, sys, or cron. |
If the group of the "at" directory is not root, bin, sys, or cron, unauthorized users could be allowed to view or edit files containing sensitive information within the directory. |
|
Change the group ownership of the file to root, bin, sys, daemon or cron.
Procedure:
# chgrp <root or other system group> <"at" directory> |
V-22404 |
CCE-3425-6 |
medium |
Kernel core dumps must be disabled unless needed. |
Kernel core dumps may contain the full contents of system memory at the time of the crash. Kernel core dumps may consume a considerable amount of disk space and may result in Denial of Service by exhausting the available space on the target file system. The kernel core dump process may increase the amount of time a system is unavailable due to a crash. Kernel core dumps can be useful for kernel debugging. |
|
Disable kdump.
# service kdump stop
# chkconfig kdump off |
V-22405 |
CCI-000225 |
low |
The kernel core dump data directory must be group-owned by root, bin, sys, or system. |
Kernel core dumps may contain the full contents of system memory at the time of the crash. As the system memory may contain sensitive information, it must be protected accordingly. If the kernel core dump data directory is not group-owned by a system group, the core dumps contained in the directory may be subject to unauthorized access. |
|
Change the group-owner of the kernel core dump data directory.
# chgrp root <kernel core dump data directory> |
V-22406 |
CCI-000225 |
low |
The kernel core dump data directory must have mode 0700 or less permissive. |
Kernel core dumps may contain the full contents of system memory at the time of the crash. As the system memory may contain sensitive information, it must be protected accordingly. If the mode of the kernel core dump data directory is more permissive than 0700, unauthorized users may be able to view or to modify kernel core dump data files. |
|
Change the group-owner of the kernel core dump data directory.
# chmod 0700 <kernel core dump data directory> |
V-22408 |
CCI-000225 |
medium |
Network interfaces must not be configured to allow user control. |
Configuration of network interfaces should be limited to privileged users. Manipulation of network interfaces may result in a Denial of Service or bypass of network security mechanisms. |
|
Edit the configuration for the user-controlled interface and remove the "USERCTL=yes" configuration line or set to "USERCTL=no". |
V-22410 |
CCE-3644-2 |
medium |
The system must not respond to Internet Control Message Protocol v4 (ICMPv4) echoes sent to a broadcast address. |
Responding to broadcast (ICMP) echoes facilitates network mapping and provides a vector for amplification attacks. |
|
Configure the system to not respond to ICMP ECHO_REQUESTs sent to broadcast addresses. Edit /etc/sysctl.conf and add a setting for "net.ipv4.icmp_echo_ignore_broadcasts=1" and reload the sysctls.
Procedure:
# echo "net.ipv4.icmp_echo_ignore_broadcasts=1" >> /etc/sysctl.conf
# sysctl -p |
V-22411 |
CCI-001551 |
medium |
The system must not respond to Internet Control Message Protocol (ICMP) timestamp requests sent to a broadcast address. |
The processing of (ICMP) timestamp requests increases the attack surface of the system. Responding to broadcast ICMP timestamp requests facilitates network mapping and provides a vector for amplification attacks. |
|
Configure the system to not respond to ICMP TIMESTAMP_REQUESTs sent to broadcast addresses. Edit /etc/sysctl.conf and add a setting for "net.ipv4.icmp_echo_ignore_broadcasts=1" and reload the sysctls.
Procedure:
# echo "net.ipv4.icmp_echo_ignore_broadcasts=1" >> /etc/sysctl.conf
# sysctl -p |
V-22414 |
CCI-001551 |
medium |
The system must not accept source-routed IPv4 packets. |
Source-routed packets allow the source of the packet to suggest routers forward the packet along a different path than configured on the router, which can be used to bypass network security measures. This requirement applies only to the handling of source-routed traffic destined to the system itself, not to traffic forwarded by the system to another system, such as when IPv4 forwarding is enabled and the system is functioning as a router. |
|
Configure the system to not accept source-routed IPv4 packets.
Edit /etc/sysctl.conf and add a setting for "net.ipv4.conf.all.accept_source_route=0" and "net.ipv4.conf.default.accept_source_route=0".
Reload the sysctls.
Procedure:
# sysctl -p |
V-22415 |
CCI-001551 |
medium |
Proxy Address Resolution Protocol (Proxy ARP) must not be enabled on the system. |
Proxy ARP allows a system to respond to ARP requests on one interface on behalf of hosts connected to another interface. If this function is enabled when not required, addressing information may be leaked between the attached network segments. |
|
Configure the system to not use proxy ARP.
Edit /etc/sysctl.conf and add a setting for "net.ipv4.conf.all.proxy_arp=0" and "net.ipv4.conf.default.proxy_arp=0".
# sysctl -p |
V-22416 |
CCE-4217-6 |
medium |
The system must ignore IPv4 Internet Control Message Protocol (ICMP) redirect messages. |
ICMP redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages modify the host's route table and are unauthenticated. An illicit ICMP redirect message could result in a man-in-the-middle attack. |
|
Configure the system to not accept IPv4 ICMP redirect messages.
Edit /etc/sysctl.conf and add a setting for "net.ipv4.conf.all.accept_redirects=0" and "net.ipv4.conf.default.accept_redirects=0".
# sysctl -p |
V-22417 |
CCE-4155-8 |
medium |
The system must not send IPv4 Internet Control Message Protocol (ICMP) redirects. |
ICMP redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages contain information from the system's route table possibly revealing portions of the network topology. |
|
Configure the system to not send IPv4 ICMP redirect messages.
Edit /etc/sysctl.conf and add a setting for "net.ipv4.conf.all.send_redirects=0" and "net.ipv4.conf.default.send_redirects=0".
# sysctl -p |
V-22418 |
CCE-4320-8 |
low |
The system must log martian packets. |
Martian packets are packets containing addresses known by the system to be invalid. Logging these messages allows the SA to identify misconfigurations or attacks in progress. |
|
Configure the system to log martian packets.
Edit /etc/sysctl.conf and add a setting for "net.ipv4.conf.all.log_martians=1" and "net.ipv4.conf.default.log_martians=1".
Reload the sysctls.
Procedure:
# sysctl -p |
V-22419 |
CCE-4265-5 |
medium |
The system must be configured to use TCP syncookies when experiencing a TCP SYN flood. |
A TCP SYN flood attack can cause Denial of Service by filling a system's TCP connection table with connections in the SYN_RCVD state. Syncookies are a mechanism used to only track a connection when a subsequent ACK is received, verifying the initiator is attempting a valid connection and is not a flood source. This technique does not operate in a fully standards-compliant manner, but is only activated when a flood condition is detected, and allows defense of the system while continuing to service valid requests. |
|
Configure the system to use TCP syncookies when experiencing a TCP SYN flood.
Edit /etc/sysctl.conf and add a setting for "net.ipv4.tcp_syncookies=1".
# sysctl -p |
V-22421 |
CCI-001551 |
medium |
The system must not be configured for network bridging. |
Some systems have the ability to bridge or switch frames (link-layer forwarding) between multiple interfaces. This can be useful in a variety of situations but, if enabled when not needed, has the potential to bypass network partitioning and security. |
|
Configure the system to not use bridging.
# rmmod bridge
Edit /etc/modprobe.conf and add a line such as "install bridge /bin/false" to prevent the loading of the bridge module. |
V-22422 |
CCI-000553 |
low |
All local file systems must employ journaling or another mechanism ensuring file system consistency. |
File system journaling, or logging, can allow reconstruction of file system data after a system crash preserving the integrity of data that may have otherwise been lost. Journaling file systems typically do not require consistency checks upon booting after a crash, which can improve system availability. Some file systems employ other mechanisms to ensure consistency also satisfying this requirement. |
|
Convert local file systems to use journaling or another mechanism ensuring file system consistency. |
V-22423 |
CCI-000225 |
medium |
The inetd.conf file, xinetd.conf file, and the xinetd.d directory must be group-owned by root, bin, sys, or system. |
Failure to give ownership of sensitive files or utilities to system groups may provide unauthorized users with the potential to access sensitive information or change the system configuration possibly weakening the system's security posture. |
|
Change the group-owner of the xinetd configuration files and directories.
Procedure:
# chgrp -R root /etc/xinetd.conf /etc/xinetd.d |
V-22425 |
CCI-000225 |
medium |
The xinetd.d directory must have mode 0755 or less permissive. |
The Internet service daemon configuration files must be protected as malicious modification could cause Denial of Service or increase the attack surface of the system. |
|
Change the mode of the directory.
# chmod 0755 /etc/xinetd.d |
V-22427 |
CCI-000225 |
medium |
The services file must be group-owned by root, bin, sys, or system. |
Failure to give ownership of system configuration files to root or a system group provides the designated owner and unauthorized users with the potential to change the system configuration possibly weakening the system's security posture. |
|
Change the group-owner of the services file.
Procedure:
# chgrp root /etc/services |
V-22429 |
CCI-001436 |
medium |
The portmap or rpcbind service must not be running unless needed. |
The portmap and rpcbind services increase the attack surface of the system and should only be used when needed. The portmap or rpcbind services are used by a variety of services using Remote Procedure Calls (RPCs). |
|
Shutdown and disable the portmap service.
# service portmap stop; chkconfig portmap off |
V-22430 |
CCI-000305 |
medium |
The portmap or rpcbind service must not be installed unless needed. |
The portmap and rpcbind services increase the attack surface of the system and should only be used when needed. The portmap or rpcbind services are used by a variety of services using Remote Procedure Calls (RPCs). |
|
Remove the portmap package.
# rpm -e portmap
or
# yum remove portmap |
V-22431 |
CCE-4308-3 |
medium |
The rshd service must not be installed. |
The rshd process provides a typically unencrypted, host-authenticated remote access service. SSH should be used in place of this service. |
|
Remove the rsh-server package.
Procedure:
# rpm -e rsh-server |
V-22432 |
CCE-3537-8 |
medium |
The rlogind service must not be running. |
The rlogind process provides a typically unencrypted, host-authenticated remote access service. SSH should be used in place of this service. |
|
Remove or disable the rlogin configuration and restart xinetd.
# rm /etc/xinetd.d/rlogin ; service xinetd restart |
V-22433 |
CCI-000305 |
medium |
The rlogind service must not be installed. |
The rlogind process provides a typically unencrypted, host-authenticated remote access service. SSH should be used in place of this service. |
|
Remove the rsh-server package.
Procedure:
# rpm -e rsh-server |
V-22434 |
CCI-000305 |
medium |
The rexecd service must not be installed. |
The rexecd process provides a typically unencrypted, host-authenticated remote access service. SSH should be used in place of this service. |
|
Remove the rsh-server package.
Procedure:
# rpm -e rsh-server |
V-22435 |
CCI-000225 |
medium |
The hosts.lpd (or equivalent) file must be group-owned by root, bin, sys, or system. |
Failure to give group-ownership of the hosts.lpd file to root, bin, sys, or system provides the members of the owning group and possible unauthorized users, with the potential to modify the hosts.lpd file. Unauthorized modifications could disrupt access to local printers from authorized remote hosts or permit unauthorized remote access to local printers. |
|
Change the group-owner of the printers.conf file.
Procedure:
# chgrp lp /etc/cups/printers.conf |
V-22438 |
CCI-000225 |
medium |
The aliases file must be group-owned by root, sys, bin, or system. |
If the alias file is not group-owned by root or a system group, an unauthorized user may modify the file adding aliases to run malicious code or redirect e-mail. |
|
Change the group-owner of the /etc/aliases file.
Procedure:
for sendmail:
# chgrp root /etc/aliases
# chgrp smmsp /etc/aliases.db
The aliases.db file must be owned by the same system group as sendmail, which is smmsp by default.
for postfix
# chgrp root /etc/postfix/aliases
# chgrp root /etc/postfix/aliases.db |
V-22444 |
CCI-000225 |
medium |
The ftpusers file must be group-owned by root, bin, sys, or system. |
If the ftpusers file is not group-owned by root or a system group, an unauthorized user may modify the file to allow unauthorized accounts to use FTP. |
|
Change the group owner of the ftpusers file.
Procedure:
# chgrp root /etc/ftpusers /etc/vsftpd.ftpusers /etc/vsftpd/ftpusers |
V-22447 |
CCI-001435 |
medium |
The SNMP service must use only SNMPv3 or its successors. |
SNMP Versions 1 and 2 are not considered secure. Without the strong authentication and privacy provided by the SNMP Version 3 User-based Security Model (USM), an attacker or other unauthorized users may gain access to detailed system management information and use the information to launch attacks against the system. |
|
Edit /etc/snmpd.conf and remove references to the "v1", "v2c", "community", or "com2sec".
Restart the SNMP service.
# service snmpd restart |
V-22451 |
CCI-000225 |
medium |
The snmpd.conf file must be group-owned by root, bin, sys, or system. |
The snmpd.conf file contains authenticators and must be protected from unauthorized access and modification. If the file is not group-owned by a system group, it may be subject to access and modification from unauthorized users. |
|
Change the group ownership of the SNMP configuration file.
Procedure:
# chgrp root <snmpd.conf> |
V-22453 |
CCI-000225 |
medium |
The /etc/syslog.conf file must have mode 0640 or less permissive. |
Unauthorized users must not be allowed to access or modify the /etc/syslog.conf file. |
|
Change the permissions of the syslog configuration file.
# chmod 0640 /etc/syslog.conf |
V-22455 |
CCE-4260-6 |
medium |
The system must use a remote syslog server (loghost). |
A syslog server (loghost) receives syslog messages from one or more systems. This data can be used as an authoritative log source in the event a system is compromised and its local logs are suspect. |
|
Edit the syslog configuration file and add an appropriate remote syslog server. |
V-22456 |
CCI-001436 |
medium |
The SSH client must be configured to only use the SSHv2 protocol. |
SSHv1 is not a DoD-approved protocol and has many well-known vulnerability exploits. Exploits of the SSH client could provide access to the system with the privileges of the user running the client. |
|
Edit the /etc/ssh/ssh_config file and add or edit a "Protocol" configuration line not allowing versions less than 2. |
V-22458 |
CCE-14491-5 |
medium |
The SSH daemon must be configured to only use FIPS 140-2 approved ciphers. |
DoD information systems are required to use FIPS 140-2 approved ciphers. SSHv2 ciphers meeting this requirement are 3DES and AES. |
|
Edit the SSH daemon configuration and remove any ciphers not starting with with "3des" or "aes" and remove any ciphers ending with "cbc". If necessary, add a "Ciphers" line. Â |
V-22460 |
CCI-001453 |
medium |
The SSH daemon must be configured to only use Message Authentication Codes (MACs) employing FIPS 140-2 approved cryptographic hash algorithms. |
DoD information systems are required to use FIPS 140-2 approved cryptographic hash functions. |
|
Edit the SSH daemon configuration and remove any MACs other than "hmac-sha1". If necessary, add a "MACs" line. |
V-22461 |
CCI-000068 |
medium |
The SSH client must be configured to only use FIPS 140-2 approved ciphers. |
DoD information systems are required to use FIPS 140-2 approved ciphers. SSHv2 ciphers meeting this requirement are 3DES and AES. |
|
Edit the SSH client configuration and remove any ciphers not starting with with "3des" or "aes" and remove any ciphers ending with "cbc". If necessary, add a "Ciphers" line. Â |
V-22462 |
CCI-000366 |
medium |
The SSH client must be configured to not use Cipher-Block Chaining (CBC)-based ciphers. |
The (CBC) mode of encryption as implemented in the SSHv2 protocol is vulnerable to chosen-plaintext attacks and must not be used.
|
|
Edit the SSH client configuration and remove any ciphers not starting with with "3des" or "aes" and remove any ciphers ending with "cbc". If necessary, add a "Ciphers" line. |
V-22463 |
CCI-001453 |
medium |
The SSH client must be configured to only use Message Authentication Codes (MACs) employing FIPS 140-2 approved cryptographic hash algorithms. |
DoD information systems are required to use FIPS 140-2 approved cryptographic hash functions. |
|
Edit the SSH client configuration and remove any MACs other than "hmac-sha1". If necessary, add a "MACs" line. |
V-22470 |
CCI-000225 |
medium |
The SSH daemon must restrict login ability to specific users and/or groups. |
Restricting SSH logins to a limited group of users, such as system administrators, prevents password-guessing and other SSH attacks from reaching system accounts and other accounts not authorized for SSH access. |
|
Edit the SSH daemon configuration and add an "AllowGroups" or "AllowUsers" directive specifying the groups and users allowed to have access.
Alternatively, modify the /etc/pam.d/sshd file to include the line
account required pam_access.so accessfile=<path to access.conf for sshd>
If the "accessfile" option is not specified the default "access.conf" file will be used. The "access.conf" file must contain the user restriction definitions. |
V-22471 |
CCI-000225 |
medium |
The SSH public host key files must have mode 0644 or less permissive. |
If a public host key file is modified by an unauthorized user, the SSH service may be compromised. |
|
Change the permissions for the SSH public host key files.
# chmod 0644 /etc/ssh/*key.pub |
V-22472 |
CCI-000225 |
medium |
The SSH private host key files must have mode 0600 or less permissive. |
If an unauthorized user obtains the private SSH host key file, the host could be impersonated. |
|
Change the permissions for the SSH private host key files.
# chmod 0600 /etc/ssh/*key |
V-22473 |
CCI-000366 |
low |
The SSH daemon must not permit GSSAPI authentication unless needed. |
GSSAPI authentication is used to provide additional authentication mechanisms to applications. Allowing GSSAPI authentication through SSH exposes the system’s GSSAPI to remote hosts, increasing the attack surface of the system. GSSAPI authentication must be disabled unless needed. |
|
Edit the SSH daemon configuration and set (add if necessary) a "GSSAPIAuthentication" directive set to "no". |
V-22474 |
CCI-000366 |
low |
The SSH client must not permit GSSAPI authentication unless needed. |
GSSAPI authentication is used to provide additional authentication mechanisms to applications. Allowing GSSAPI authentication through SSH exposes the system’s GSSAPI to remote hosts, increasing the attack surface of the system. GSSAPI authentication must be disabled unless needed. |
|
Edit the SSH client configuration and set the GSSAPIAuthentication" directive set to "no". Â |
V-22475 |
CCI-000366 |
low |
The SSH daemon must not permit Kerberos authentication unless needed. |
Kerberos authentication for SSH is often implemented using GSSAPI. If Kerberos is enabled through SSH, the SSH daemon provides a means of access to the system's Kerberos implementation. Vulnerabilities in the system's Kerberos implementation may then be subject to exploitation. To reduce the attack surface of the system, the Kerberos authentication mechanism within SSH must be disabled for systems not using this capability.
|
|
Edit the SSH daemon configuration and set (add if necessary) the "KerberosAuthentication" directive set to "no". |
V-22485 |
CCI-000225 |
medium |
The SSH daemon must perform strict mode checking of home directory configuration files. |
If other users have access to modify user-specific SSH configuration files, they may be able to log into the system as another user. |
|
Edit the SSH daemon configuration and add or edit the "StrictModes" setting value to "yes". |
V-22486 |
CCI-000225 |
medium |
The SSH daemon must use privilege separation. |
SSH daemon privilege separation causes the SSH process to drop root privileges when not needed, which would decrease the impact of software vulnerabilities in the unprivileged section. |
|
Edit the SSH daemon configuration and add or edit the "UsePrivilegeSeparation" setting value to "yes". |
V-22487 |
CCE-4370-3 |
medium |
The SSH daemon must not allow rhosts RSA authentication. |
If SSH permits rhosts RSA authentication, a user may be able to log in based on the keys of the host originating the request and not any user-specific authentication. |
|
Edit the SSH daemon configuration and add or edit the "RhostsRSAAuthentication" setting value to "no". |
V-22488 |
CCI-000366 |
medium |
The SSH daemon must not allow compression or must only allow compression after successful authentication. |
If compression is allowed in an SSH connection prior to authentication, vulnerabilities in the compression software could result in compromise of the system from an unauthenticated connection, potentially with root privileges. |
|
Edit the SSH daemon configuration and add or edit the "Compression" setting value to "no" or "delayed". |
V-22489 |
CCE-4431-3 |
medium |
The SSH daemon must be configured with the Department of Defense (DoD) logon banner. |
Failure to display the DoD logon banner prior to a logon attempt will negate legal proceedings resulting from unauthorized access to system resources.
The SSH service must be configured to display the DoD logon warning banner either through the SSH configuration or a wrapper program such as TCP_WRAPPERS.
The SSH daemon may also be used to provide SFTP service. The warning banner configuration for SSH will apply to SFTP. |
|
Edit /etc/issue and the DoD login banner.
DoD Login Banners:
You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.
By using this IS (which includes any device attached to this IS), you consent to the following conditions:
-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.
-At any time, the USG may inspect and seize data stored on this IS.
-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.
-This IS includes security measures (e.g., authentication and access controls) to protect USG interests- -not for your personal benefit or privacy.
-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details.
Find the location of the banner file for sshd and examine the content:
# grep -i banner /etc/ssh/sshd_config | grep -v '^#'
# cat
Edit the SSH daemon configuration and add or edit a "Banner" setting referencing a file containing a logon warning banner. |
V-22491 |
CCI-000366 |
medium |
The system must not have IP forwarding for IPv6 enabled, unless the system is an IPv6 router. |
If the system is configured for IP forwarding and is not a designated router, it could be used to bypass network security by providing a path for communication not filtered by network devices. |
|
Disable IPv6 forwarding.
Edit /etc/sysctl.conf and add a setting for "net.ipv6.conf.all.forwarding=0" and "net.ipv6.conf.default.forwarding=0".
Reload the sysctls.
Procedure:
# sysctl -p |
V-22492 |
CCI-000225 |
medium |
The Network File System (NFS) export configuration file must be group-owned by root, bin, sys, or system. |
Failure to give group-ownership of the NFS export configuration file to root or a system group provides the designated group-owner and possible unauthorized users with the potential to change system configuration which could weaken the system's security posture. |
|
Change the group ownership of the NFS export configuration file.
Procedure:
# chgrp root /etc/exports |
V-22496 |
CCI-000225 |
medium |
All Network File System (NFS) exported system files and system directories must be group-owned by root, bin, sys, or system. |
Failure to give group-ownership of sensitive files or directories to root provides the members of the owning group with the potential to access sensitive information or change system configuration which could weaken the system's security posture. |
|
Change the group owner of the export directory.
# chgrp root <export> |
V-22499 |
CCI-000366 |
medium |
Samba must be configured to use an authentication mechanism other than "share." |
Samba share authentication does not provide for individual user identification and must not be used. |
|
Edit the "/etc/samba/smb.conf" file and change the "security" setting to "user" or another valid setting other than "share". |
V-22500 |
CCI-000366 |
medium |
Samba must be configured to use encrypted passwords. |
Samba must be configured to protect authenticators. If Samba passwords are not encrypted for storage, plain-text user passwords may be read by those with access to the Samba password file. |
|
Edit the "/etc/samba/smb.conf" file and change the "encrypt passwords" setting to "yes". |
V-22501 |
CCI-000366 |
medium |
Samba must be configured to not allow guest access to shares. |
Guest access to shares permits anonymous access and is not permitted. |
|
Edit the "/etc/samba/smb.conf" file and change the "guest ok" setting to "no". |
V-22511 |
CCE-14132-5 |
medium |
The Stream Control Transmission Protocol (SCTP) must be disabled unless required. |
The Stream Control Transmission Protocol (SCTP) is an Internet Engineering Task Force (IETF)-standardized transport layer protocol. This protocol is not yet widely used. Binding this protocol to the network stack increases the attack surface of the host. Unprivileged local processes may be able to cause the system to dynamically load a protocol handler by opening a socket using the protocol. |
|
Prevent the SCTP protocol handler for dynamic loading.
# echo "install sctp /bin/true" >> /etc/modprobe.conf |
V-22514 |
CCE-14268-7 |
medium |
The Datagram Congestion Control Protocol (DCCP) must be disabled unless required. |
The DCCP is a proposed transport layer protocol. This protocol is not yet widely used. Binding this protocol to the network stack increases the attack surface of the host. Unprivileged local processes may be able to cause the system to dynamically load a protocol handler by opening a socket using the protocol. |
|
Prevent the DCCP protocol handler for dynamic loading.
# echo "install dccp /bin/true" >> /etc/modprobe.conf
# echo "install dccp_ipv4 /bin/true" >> /etc/modprobe.conf
# echo "install dccp_ipv6 /bin/true" >> /etc/modprobe.conf |
V-22524 |
CCI-000382 |
medium |
The AppleTalk protocol must be disabled or not installed. |
The AppleTalk suite of protocols is no longer in common use. Binding this protocol to the network stack increases the attack surface of the host. Unprivileged local processes may be able to cause the system to dynamically load a protocol handler by opening a socket using the protocol. |
|
Prevent the AppleTalk protocol handler for dynamic loading.
# echo "install appletalk /bin/true" >> /etc/modprobe.conf |
V-22530 |
CCE-14027-7 |
medium |
The Reliable Datagram Sockets (RDS) protocol must be disabled or not installed unless required. |
The RDS protocol is a relatively new protocol developed by Oracle for communication between the nodes of a cluster. Binding this protocol to the network stack increases the attack surface of the host. Unprivileged local processes may be able to cause the system to dynamically load a protocol handler by opening a socket using the protocol. |
|
Prevent the RDS protocol handler for dynamic loading.
# echo "install rds /bin/true" >> /etc/modprobe.conf |
V-22533 |
CCE-14911-2 |
medium |
The Transparent Inter-Process Communication (TIPC) protocol must be disabled or uninstalled. |
The TIPC protocol is a relatively new cluster communications protocol developed by Ericsson. Binding this protocol to the network stack increases the attack surface of the host. Unprivileged local processes may be able to cause the system to dynamically load a protocol handler by opening a socket using the protocol. |
|
Prevent the TIPC protocol handler for dynamic loading.
# echo "install tipc /bin/true" >> /etc/modprobe.conf |
V-22539 |
CCI-001551 |
medium |
The Bluetooth protocol handler must be disabled or not installed. |
Bluetooth is a Personal Area Network (PAN) technology. Binding this protocol to the network stack increases the attack surface of the host. Unprivileged local processes may be able to cause the kernel to dynamically load a protocol handler by opening a socket using the protocol. |
|
Prevent the Bluetooth protocol handler for dynamic loading.
# echo "install bluetooth /bin/true" >> /etc/modprobe.conf |
V-22541 |
CCI-001551 |
medium |
The IPv6 protocol handler must not be bound to the network stack unless needed. |
IPv6 is the next version of the Internet protocol. Binding this protocol to the network stack increases the attack surface of the host. |
|
Remove the capability to use IPv6 protocol handler.
Procedure:
Edit /etc/sysconfig/network and change
NETWORKING_IPV6=yes
to
NETWORKING_IPV6=no
Edit /etc/modprobe.conf and add these lines (if they are not in it):
alias net-pf-10 off
alias ipv6 off
Stop the ipv6tables service by typing:
service ip6tables stop
Disable the ipv6tables service by typing:
chkconfig ip6tables off
Remove the ipv6 kernel module
# rmmod ipv6
Reboot |
V-22542 |
CCE-3562-6 |
medium |
The IPv6 protocol handler must be prevented from dynamic loading unless needed. |
IPv6 is the next generation of the Internet protocol. Binding this protocol to the network stack increases the attack surface of the host. Unprivileged local processes may be able to cause the system to dynamically load a protocol handler by opening a socket using the protocol. |
|
Prevent the IPv6 protocol handler for dynamic loading.
# echo "install ipv6 /bin/true" >> /etc/modprobe.conf |
V-22546 |
CCI-001551 |
medium |
The system must not have Teredo enabled. |
Teredo is an IPv6 transition mechanism involving tunneling IPv6 packets encapsulated in IPv4 packets. Unauthorized tunneling may circumvent network security. |
|
Edit startup scripts to prevent the service from running on startup. |
V-22549 |
CCI-000366 |
medium |
The DHCP client must not send dynamic DNS updates. |
Dynamic DNS updates transmit unencrypted information about a system including its name and address and should not be used unless needed. |
|
Edit or add the "/etc/dhclient.conf" file and add or edit the "do-forward-updates" setting to false.
Procedure:
# echo "do-forward-updates false;" >> /etc/dhclient.conf |
V-22550 |
CCI-001551 |
medium |
The system must ignore IPv6 ICMP redirect messages. |
ICMP redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages modify the host's route table and are unauthenticated. An illicit ICMP redirect message could result in a man-in-the-middle attack. |
|
Configure the system to ignore IPv6 ICMP redirect messages.
Edit "/etc/sysctl.conf" and add a settings for "net.ipv6.conf.default.accept_redirects=0" and "net.ipv6.conf.all.accept_redirects=0".
Restart the system for the setting to take effect. |
V-22557 |
CCI-000185 |
medium |
If the system is using LDAP for authentication or account information, the LDAP TLS connection must require the server provide a certificate with a valid trust path to a trusted CA. |
The NSS LDAP service provides user mappings which are a vital component of system security. Communication between an LDAP server and a host using LDAP for NSS require authentication. |
|
Edit "/etc/ldap.conf" and add or set the "tls_checkpeer" setting to "yes". |
V-22558 |
CCI-000185 |
medium |
If the system is using LDAP for authentication or account information, the system must verify the LDAP server's certificate has not been revoked. |
LDAP can be used to provide user authentication and account information, which are vital to system security. Communication between an LDAP server and a host using LDAP requires authentication. |
|
Edit "/etc/ldap.conf" and add or set the "tls_crlcheck" setting to "all". |
V-22559 |
CCI-000225 |
medium |
If the system is using LDAP for authentication or account information the /etc/ldap.conf (or equivalent) file must have mode 0644 or less permissive. |
LDAP can be used to provide user authentication and account information, which are vital to system security. The LDAP client configuration must be protected from unauthorized modification. |
|
Change the permissions of the file.
# chmod 0644 /etc/ldap.conf |
V-22560 |
CCI-000225 |
medium |
If the system is using LDAP for authentication or account information, the /etc/ldap.conf (or equivalent) file must be owned by root. |
LDAP can be used to provide user authentication and account information, which are vital to system security. The LDAP client configuration must be protected from unauthorized modification. |
|
Change the owner of the file.
# chown root /etc/ldap.conf |
V-22561 |
CCI-000225 |
medium |
If the system is using LDAP for authentication or account information, the /etc/ldap.conf (or equivalent) file must be group-owned by root, bin, sys, or system. |
LDAP can be used to provide user authentication and account information, which are vital to system security. The LDAP client configuration must be protected from unauthorized modification. |
|
Change the group owner of the file to root, bin, sys, or system.
Procedure:
# chgrp root /etc/ldap.conf |
V-22563 |
CCI-000225 |
medium |
If the system is using LDAP for authentication or account information, the TLS certificate authority file and/or directory (as appropriate) must be owned by root. |
LDAP can be used to provide user authentication and account information, which are vital to system security. The LDAP client configuration must be protected from unauthorized modification. |
|
Change the ownership of the file or directory.
# chown root <certpath> |
V-22564 |
CCI-000225 |
medium |
If the system is using LDAP for authentication or account information, the TLS certificate authority file and/or directory (as appropriate) must be group-owned by root, bin, sys, or system. |
LDAP can be used to provide user authentication and account information, which are vital to system security. The LDAP client configuration must be protected from unauthorized modification |
|
Change the group ownership of the file or directory.
# chgrp root <certpath> |
V-22565 |
CCI-000225 |
medium |
If the system is using LDAP for authentication or account information, the TLS certificate authority file and/or directory (as appropriate) must have mode 0644 (0755 for directories) or less permissive. |
LDAP can be used to provide user authentication and account information, which are vital to system security. The LDAP client configuration must be protected from unauthorized modification. |
|
Change the mode of the file or directory.
File Procedure:
# chmod 0644 <certpath>
Directory Procedure:
# chmod 0755 <certpath> |
V-22567 |
CCI-000225 |
medium |
For systems using NSS LDAP, the TLS certificate file must be owned by root. |
The NSS LDAP service provides user mappings which are a vital component of system security. Its configuration must be protected from unauthorized modification. |
|
Change the ownership of the file.
# chown root <certpath> |
V-22568 |
CCI-000225 |
medium |
If the system is using LDAP for authentication or account information, the LDAP TLS certificate file must be group-owned by root, bin, sys, or system. |
LDAP can be used to provide user authentication and account information, which are vital to system security. The LDAP client configuration must be protected from unauthorized modification. |
|
Change the group ownership of the file.
Procedure:
# chgrp root <certpath> |
V-22569 |
CCI-000225 |
medium |
If the system is using LDAP for authentication or account information, the LDAP TLS certificate file must have mode 0644 or less permissive. |
LDAP can be used to provide user authentication and account information, which are vital to system security. The LDAP client configuration must be protected from unauthorized modification. |
|
Change the mode of the file.
# chmod 0644 <certpath> |
V-22571 |
CCI-000225 |
medium |
If the system is using LDAP for authentication or account information, the LDAP TLS key file must be owned by root. |
LDAP can be used to provide user authentication and account information, which are vital to system security. The LDAP client configuration must be protected from unauthorized modification. |
|
Change the ownership of the file.
# chown root <keypath> |
V-22572 |
CCI-000225 |
medium |
If the system is using LDAP for authentication or account information, the LDAP TLS key file must be group-owned by root, bin, or sys. |
LDAP can be used to provide user authentication and account information, which are vital to system security. The LDAP client configuration must be protected from unauthorized modification. |
|
Change the group ownership of the file.
# chgrp root <keypath> |
V-22573 |
CCI-000225 |
medium |
If the system is using LDAP for authentication or account information, the LDAP TLS key file must have mode 0600 or less permissive. |
LDAP can be used to provide user authentication and account information, which are vital to system security. The LDAP client configuration must be protected from unauthorized modification.
Note: Depending on the particular implementation, group and other read permission may be necessary for unprivileged users to successfully resolve account information using LDAP. This will still be a finding, as these permissions provide users with access to system authenticators. |
|
Change the mode of the file.
# chmod 0600 <keypath> |
V-22576 |
CCI-000366 |
low |
The system must use available memory address randomization techniques. |
Successful exploitation of buffer overflow vulnerabilities relies in some measure to having a predictable address structure of the executing program. Address randomization techniques reduce the probability of a successful exploit. |
|
Edit the kernel boot parameters, or "/etc/sysctl.conf", and set exec-shield to "1". Reboot the system. |
V-22577 |
CCE-4072-5 |
low |
Automated file system mounting tools must not be enabled unless needed. |
Automated file system mounting tools may provide unprivileged users with the ability to access local media and network shares. If this access is not necessary for the system’s operation, it must be disabled to reduce the risk of unauthorized access to these resources. |
|
Stop and disable the autofs service.
# service autofs stop
# chkconfig autofs off |
V-22579 |
CCI-000366 |
low |
The system must have USB Mass Storage disabled unless needed. |
USB is a common computer peripheral interface. USB devices may include storage devices with the potential to install malicious software on a system or exfiltrate data |
|
Prevent the usb-storage module from loading.
# echo 'install usb-storage /bin/true' >> /etc/modprobe.conf |
V-22580 |
CCI-000366 |
low |
The system must have IEEE 1394 (Firewire) disabled unless needed. |
Firewire is a common computer peripheral interface. Firewire devices may include storage devices with the potential to install malicious software on a system or exfiltrate data. |
|
Prevent the system from loading the firewire module.
# echo 'install ieee1394 /bin/true' >> /etc/modprobe.conf |
V-22582 |
CCE-4189-7 |
medium |
The system must employ a local firewall. |
A local firewall protects the system from exposing unnecessary or undocumented network services to the local enclave. If a system within the enclave is compromised, firewall protection on an individual system continues to protect it from attack. |
|
Enable the system's local firewall.
# chkconfig iptables on
# service iptables start |
V-22584 |
CCE-3977-6 |
low |
The system must use a Linux Security Module configured to limit the privileges of system services. |
Linux Security Modules such as SELinux and AppArmor can be used to provide protection from software exploits by explicitly defining the privileges permitted to each software package. |
|
Enable one of the SELinux prolicies.
Edit /etc/sysconfig/selinux and set the value of the SELINUX option to "enforcing" and SELINUXTYPE to "targeted" or "strict".
Restart the system. |
V-22586 |
CCE-4144-2 |
medium |
The system's boot loader configuration files must be owned by root. |
The system's boot loader configuration files are critical to the integrity of the system and must be protected. Unauthorized modification of these files resulting from improper ownership could compromise the system's boot loader configuration. |
|
Change the ownership of the file.
# chown root /boot/grub/grub.conf |
V-22587 |
CCE-4197-0 |
medium |
The system's boot loader configuration file(s) must be group-owned by root, bin, sys, or system. |
The system's boot loader configuration files are critical to the integrity of the system and must be protected. Unauthorized modifications resulting from improper group ownership may compromise the boot loader configuration. |
|
Change the group ownership of the file.
# chgrp root /boot/grub/grub.conf |
V-22598 |
CCE-15026-8 |
low |
Auditing must be enabled at boot by setting a kernel parameter. |
If auditing is enabled late in the boot process, the actions of startup scripts may not be audited. Some audit systems also maintain state information only available if auditing is enabled before a given process is created. |
|
Edit the grub bootloader file /boot/grub/grub.conf or /boot/grub/menu.lst by appending the "audit=1" parameter to the kernel boot line.
Reboot the system for the change to take effect. |
V-22665 |
CCI-000366 |
medium |
The system must not be running any routing protocol daemons, unless the system is a router. |
Routing protocol daemons are typically used on routers to exchange network topology information with other routers. If this software is used when not required, system network information may be unnecessarily transmitted across the network. |
|
Disable any routing protocol daemons. |
V-22702 |
CCI-000162 |
medium |
System audit logs must be group-owned by root, bin, sys, or system. |
Sensitive system and user information could provide a malicious user with enough information to penetrate further into the system. |
|
Change the group ownership of the audit log file(s).
Procedure:
# chgrp root <audit log file> |
V-23736 |
CCI-001208 |
low |
The system must use a separate file system for /var. |
The use of separate file systems for different paths can protect the system from failures resulting from a file system becoming full or failing. |
|
Migrate the /var path onto a separate file system. |
V-23738 |
CCI-001208 |
low |
The system must use a separate file system for the system audit data path. |
The use of separate file systems for different paths can protect the system from failures resulting from a file system becoming full or failing. |
|
Migrate the /var/log/audit path onto a separate filesystem. |
V-23739 |
CCI-001208 |
low |
The system must use a separate file system for /tmp (or equivalent). |
The use of separate file systems for different paths can protect the system from failures resulting from a file system becoming full or failing. |
|
Migrate the /tmp path onto a separate file system. |
V-23741 |
CCI-000366 |
medium |
TCP backlog queue sizes must be set appropriately. |
To provide some mitigation to TCP Denial of Service attacks, the TCP backlog queue sizes must be set to at least 1280 or in accordance with product-specific guidelines. |
|
Edit /etc/sysctl.conf and add a setting for "net.ipv4.tcp_max_syn_backlog=1280".
Procedure:
# sysctl -p |
V-23952 |
CCI-001305 |
medium |
Mail relaying must be restricted. |
If unrestricted mail relaying is permitted, unauthorized senders could use this host as a mail relay for the purpose of sending SPAM or other unauthorized activity. |
|
If the system uses sendmail, edit the sendmail.mc file and remove the "promiscuous_relay" configuration. Rebuild the sendmail.cf file from the modified sendmail.mc and restart the service. If the system does not need to receive mail from external hosts, add one or more DaemonPortOptions lines referencing system loopback addresses (such as "O DaemonPortOptions=Addr=127.0.0.1,Port=smtp,Name=MTA") and remove lines containing non-loopback addresses. Restart the service.
If the system uses Postfix, edit the main.cf file and add or edit the "smtpd_client_restrictions" line to have contents "permit mynetworks, reject" or a similarly restrictive rule. If the system does not need to receive mail from external hosts, add or edit the "inet_interfaces" line to have contents "loopback-only" or a set of loopback addresses for the system. Restart the service.
If the system is using other SMTP software, consult the software's documentation for procedures to restrict mail relaying. |
V-23953 |
CCI-000305 |
medium |
The 'ldd' command must be disabled unless it protects against the execution of untrusted files. |
The 'ldd' command provides a list of dependent libraries needed by a given binary, which is useful for troubleshooting software. Instead of parsing the binary file, some 'ldd' implementations invoke the program with a special environment variable set, which causes the system dynamic linker to display the list of libraries. Specially crafted binaries can specify an alternate dynamic linker which may cause a program to be executed instead of examined. If the program is from an untrusted source, such as in a user home directory, or a file suspected of involvement in a system compromise, unauthorized software may be executed with the rights of the user running 'ldd'.
Some 'ldd' implementations include protections that prevent the execution of untrusted files. If such protections exist, this requirement is not applicable.
An acceptable method of disabling 'ldd' is changing its mode to 0000. The SA may conduct troubleshooting by temporarily changing the mode to allow execution and running the 'ldd' command as an unprivileged user upon trusted system binaries. |
|
Remove the execute permissions from the 'ldd' executable.
Procedure:
# chmod a-x /usr/bin/ldd |
V-24357 |
CCI-000136 |
low |
The system must be configured to send audit records to a remote audit server. |
Audit records contain evidence that can be used in the investigation of compromised systems. To prevent this evidence from compromise, it must be sent to a separate system continuously. Methods for sending audit records include, but are not limited to, system audit tools used to send logs directly to another host or through the system's syslog service to another host.
|
|
Configure the system to send audit records to a remote server.
Procedure:
These instructions assume a known remote audit server is available to this system.
Modify /etc/syslog.conf to contain a line sending all audit records to a remote audit server. The server is specified by placing an "@" before the DNS name or IP address in the line.
*.* @<remote audit server>
Edit the "active" line in /etc/audisp/plugins.d/syslog.conf so it shows "active = yes".
Restart audit and syslog:
# service auditd restart
# service syslog restart |
V-24384 |
CCI-000196 |
medium |
If the system is using LDAP for authentication or account information, the /etc/ldap.conf file (or equivalent) must not contain passwords. |
The authentication of automated LDAP connections between systems must not use passwords since more secure methods are available, such as PKI and Kerberos. Additionally, the storage of unencrypted passwords on the system is not permitted. |
|
Edit the "/etc/ldap.conf" file to use anonymous binding by removing the "bindpw" option. |
V-24624 |
CCI-000213 |
medium |
The system boot loader must protect passwords using an MD5 or stronger cryptographic hash. |
If system boot loader passwords are compromised, users with console access to the system may be able to alter the system boot configuration or boot the system into single user or maintenance mode, which could result in Denial of Service or unauthorized privileged access to the system. |
|
Consult vendor documentation for procedures concerning the system's boot loader. Configure the boot loader to hash boot loader passwords using MD5 or a stronger hash. |
V-27275 |
CCI-000012 |
medium |
The system must not have the unnecessary "news" account. |
Accounts that provide no operational purpose provide additional opportunities for system compromise. Unnecessary accounts include user accounts for individuals not requiring access to the system and application accounts for applications not installed on the system. |
|
Remove the "news" account from the /etc/passwd file before connecting a system to the network. |
V-27276 |
CCI-000012 |
medium |
The system must not have the unnecessary "gopher" account. |
Accounts that provide no operational purpose provide additional opportunities for system compromise. Unnecessary accounts include user accounts for individuals not requiring access to the system and application accounts for applications not installed on the system. |
|
Remove the "gopher" account from the /etc/passwd file before connecting a system to the network. |
V-27279 |
CCI-000012 |
medium |
The system must not have the unnecessary "ftp" account. |
Accounts that provide no operational purpose provide additional opportunities for system compromise. Unnecessary accounts include user accounts for individuals not requiring access to the system and application accounts for applications not installed on the system. |
|
Remove the "ftp" account from the /etc/passwd file before connecting a system to the network. |
V-27283 |
CCI-000057 |
medium |
The graphical desktop environment must set the idle timeout to no more than 15 minutes. |
If graphical desktop sessions do not lock the session after 15 minutes of inactivity, requiring re-authentication to resume operations, the system or individual data could be compromised by an alert intruder who could exploit the oversight. This requirement applies to graphical desktop environments provided by the system to locally attached displays and input devices as well as to graphical desktop environments provided to remote systems, including thin clients. |
|
For the Gnome screen saver, set idle_delay to 15.
Procedure:
# gconftool-2 --direct --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory --type int --set /apps/gnome-screensaver/idle_delay 15 |
V-27284 |
CCI-000057 |
medium |
Graphical desktop environments provided by the system must have automatic lock enabled. |
If graphical desktop sessions do not lock the session after 15 minutes of inactivity, requiring re-authentication to resume operations, the system or individual data could be compromised by an alert intruder who could exploit the oversight. This requirement applies to graphical desktop environments provided by the system to locally attached displays and input devices as well as to graphical desktop environments provided to remote systems, including thin clients. |
|
For the Gnome screen saver, set the lock_enabled flag.
Procedure:
# gconftool-2 --direct --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory --type bool --set /apps/gnome-screensaver/lock_enabled true |
V-29236 |
CCI-000192 |
medium |
The audit system must be configured to audit failed attempts to access files and programs. |
If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise. |
|
Edit the audit.rules file and add the following line(s) to enable auditing of failed attempts to access files and programs:
either:
-a exit,always -F arch=<ARCH> -S open -F success=0
or both:
-a exit,always -F arch=<ARCH> -S open -F exit=-EPERM
-a exit,always -F arch=<ARCH> -S open -F exit=-EACCES
Restart the auditd service.
# service auditd restart |
V-29237 |
CCI-000192 |
medium |
The audit system must be configured to audit failed attempts to access files and programs. |
If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise. |
|
Edit the audit.rules file and add the following line(s) to enable auditing of failed attempts to access files and programs:
either:
-a exit,always -F arch=<ARCH> -S openat -F success=0
or both:
-a exit,always -F arch=<ARCH> -S openat -F exit=-EPERM
-a exit,always -F arch=<ARCH> -S openat -F exit=-EACCES
Restart the auditd service.
# service auditd restart |
V-29238 |
CCI-000192 |
medium |
The audit system must be configured to audit failed attempts to access files and programs. |
If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise. |
|
Edit the audit.rules file and add the following line(s) to enable auditing of failed attempts to access files and programs:
either:
-a exit,always -F arch=<ARCH> -S truncate -F success=0
or both:
-a exit,always -F arch=<ARCH> -S truncate -F exit=-EPERM
-a exit,always -F arch=<ARCH> -S truncate -F exit=-EACCES
Restart the auditd service.
# service auditd restart |
V-29239 |
CCI-000192 |
medium |
The audit system must be configured to audit failed attempts to access files and programs. |
If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise. |
|
Edit the audit.rules file and add the following line(s) to enable auditing of failed attempts to access files and programs:
either:
-a exit,always -F arch=<ARCH> -S ftruncate -F success=0
or both:
-a exit,always -F arch=<ARCH> -S ftruncate -F exit=-EPERM
-a exit,always -F arch=<ARCH> -S ftruncate -F exit=-EACCES
Restart the auditd service.
# service auditd restart |
V-29240 |
CCI-000126 |
medium |
The audit system must be configured to audit file deletions. |
If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise. |
|
Edit the audit.rules file and add the following line to enable auditing of deletions:
-a exit,always -S rmdir
Restart the auditd service.
# service auditd restart |
V-29241 |
CCE-14051-7 |
medium |
The audit system must be configured to audit all administrative, privileged, and security actions. |
If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise. |
|
The "-F arch=<ARCH>"restriction is required on dual-architecture systems (such as x86_64). On dual-architecture systems, two separate rules must exist - one for each architecture supported. Use the generic architectures "b32" and "b64" for specifying these rules.
On single architecture systems, the "-F arch=<ARCH>"restriction may be omitted, but if present must match either the architecture of the system or its corresponding generic architecture. The architecture of the system may be determined by running "uname -m". See the auditctl(8) manpage for additional details.
Any restrictions (such as with "-F") beyond those provided in the example rules are not in strict compliance with this requirement, and are a finding unless justified and documented appropriately.
The use of audit keys consistent with the provided example is encouraged to provide for uniform audit logs, however omitting the audit key or using an alternate audit key is not a finding.
Procedure:
Add the following lines to the audit.rules file to enable auditing of administrative, privileged, and security actions:
-w /etc/audit.rules
-w /etc/audit/audit.rules
Restart the auditd service.
# service auditd restart |
V-29242 |
CCE-14051-7 |
medium |
The audit system must be configured to audit all administrative, privileged, and security actions. |
If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise. |
|
The "-F arch=<ARCH>"restriction is required on dual-architecture systems (such as x86_64). On dual-architecture systems, two separate rules must exist - one for each architecture supported. Use the generic architectures "b32" and "b64" for specifying these rules.
On single architecture systems, the "-F arch=<ARCH>"restriction may be omitted, but if present must match either the architecture of the system or its corresponding generic architecture. The architecture of the system may be determined by running "uname -m". See the auditctl(8) manpage for additional details.
Any restrictions (such as with "-F") beyond those provided in the example rules are not in strict compliance with this requirement, and are a finding unless justified and documented appropriately.
The use of audit keys consistent with the provided example is encouraged to provide for uniform audit logs, however omitting the audit key or using an alternate audit key is not a finding.
Procedure:
Add the following lines to the audit.rules file to enable auditing of administrative, privileged, and security actions:
-a exit,always -F arch=<ARCH> -S adjtime
Restart the auditd service.
# service auditd restart |
V-29243 |
CCE-14051-7 |
medium |
The audit system must be configured to audit all administrative, privileged, and security actions. |
If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise. |
|
The "-F arch=<ARCH>"restriction is required on dual-architecture systems (such as x86_64). On dual-architecture systems, two separate rules must exist - one for each architecture supported. Use the generic architectures "b32" and "b64" for specifying these rules.
On single architecture systems, the "-F arch=<ARCH>"restriction may be omitted, but if present must match either the architecture of the system or its corresponding generic architecture. The architecture of the system may be determined by running "uname -m". See the auditctl(8) manpage for additional details.
Any restrictions (such as with "-F") beyond those provided in the example rules are not in strict compliance with this requirement, and are a finding unless justified and documented appropriately.
The use of audit keys consistent with the provided example is encouraged to provide for uniform audit logs, however omitting the audit key or using an alternate audit key is not a finding.
Procedure:
Add the following lines to the audit.rules file to enable auditing of administrative, privileged, and security actions:
-a exit,always -F arch=<ARCH> -S settimeofday
Restart the auditd service.
# service auditd restart |
V-29244 |
CCE-14051-7 |
medium |
The audit system must be configured to audit all administrative, privileged, and security actions. |
If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise. |
|
The "-F arch=<ARCH>"restriction is required on dual-architecture systems (such as x86_64). On dual-architecture systems, two separate rules must exist - one for each architecture supported. Use the generic architectures "b32" and "b64" for specifying these rules.
On single architecture systems, the "-F arch=<ARCH>"restriction may be omitted, but if present must match either the architecture of the system or its corresponding generic architecture. The architecture of the system may be determined by running "uname -m". See the auditctl(8) manpage for additional details.
Any restrictions (such as with "-F") beyond those provided in the example rules are not in strict compliance with this requirement, and are a finding unless justified and documented appropriately.
The use of audit keys consistent with the provided example is encouraged to provide for uniform audit logs, however omitting the audit key or using an alternate audit key is not a finding.
Procedure:
Add the following lines to the audit.rules file to enable auditing of administrative, privileged, and security actions:
-a exit,always -F arch=<ARCH> -S stime
Restart the auditd service.
# service auditd restart |
V-29245 |
CCE-14051-7 |
medium |
The audit system must be configured to audit all administrative, privileged, and security actions. |
If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise. |
|
The "-F arch=<ARCH>"restriction is required on dual-architecture systems (such as x86_64). On dual-architecture systems, two separate rules must exist - one for each architecture supported. Use the generic architectures "b32" and "b64" for specifying these rules.
On single architecture systems, the "-F arch=<ARCH>"restriction may be omitted, but if present must match either the architecture of the system or its corresponding generic architecture. The architecture of the system may be determined by running "uname -m". See the auditctl(8) manpage for additional details.
Any restrictions (such as with "-F") beyond those provided in the example rules are not in strict compliance with this requirement, and are a finding unless justified and documented appropriately.
The use of audit keys consistent with the provided example is encouraged to provide for uniform audit logs, however omitting the audit key or using an alternate audit key is not a finding.
Procedure:
Add the following lines to the audit.rules file to enable auditing of administrative, privileged, and security actions:
-a exit,always -F arch=<ARCH> -S clock_settime
Restart the auditd service.
# service auditd restart |
V-29246 |
CCE-14051-7 |
medium |
The audit system must be configured to audit all administrative, privileged, and security actions. |
If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise. |
|
The "-F arch=<ARCH>"restriction is required on dual-architecture systems (such as x86_64). On dual-architecture systems, two separate rules must exist - one for each architecture supported. Use the generic architectures "b32" and "b64" for specifying these rules.
On single architecture systems, the "-F arch=<ARCH>"restriction may be omitted, but if present must match either the architecture of the system or its corresponding generic architecture. The architecture of the system may be determined by running "uname -m". See the auditctl(8) manpage for additional details.
Any restrictions (such as with "-F") beyond those provided in the example rules are not in strict compliance with this requirement, and are a finding unless justified and documented appropriately.
The use of audit keys consistent with the provided example is encouraged to provide for uniform audit logs, however omitting the audit key or using an alternate audit key is not a finding.
Procedure:
Add the following lines to the audit.rules file to enable auditing of administrative, privileged, and security actions:
-a exit,always -F arch=<ARCH> -S sethostname
Restart the auditd service.
# service auditd restart |
V-29247 |
CCE-14051-7 |
medium |
The audit system must be configured to audit all administrative, privileged, and security actions. |
If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise. |
|
The "-F arch=<ARCH>"restriction is required on dual-architecture systems (such as x86_64). On dual-architecture systems, two separate rules must exist - one for each architecture supported. Use the generic architectures "b32" and "b64" for specifying these rules.
On single architecture systems, the "-F arch=<ARCH>"restriction may be omitted, but if present must match either the architecture of the system or its corresponding generic architecture. The architecture of the system may be determined by running "uname -m". See the auditctl(8) manpage for additional details.
Any restrictions (such as with "-F") beyond those provided in the example rules are not in strict compliance with this requirement, and are a finding unless justified and documented appropriately.
The use of audit keys consistent with the provided example is encouraged to provide for uniform audit logs, however omitting the audit key or using an alternate audit key is not a finding.
Procedure:
Add the following lines to the audit.rules file to enable auditing of administrative, privileged, and security actions:
-a exit,always -F arch=<ARCH> -S setdomainname
Restart the auditd service.
# service auditd restart |
V-29248 |
CCE-14051-7 |
medium |
The audit system must be configured to audit all administrative, privileged, and security actions. |
If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise. |
|
The "-F arch=<ARCH>"restriction is required on dual-architecture systems (such as x86_64). On dual-architecture systems, two separate rules must exist - one for each architecture supported. Use the generic architectures "b32" and "b64" for specifying these rules.
On single architecture systems, the "-F arch=<ARCH>"restriction may be omitted, but if present must match either the architecture of the system or its corresponding generic architecture. The architecture of the system may be determined by running "uname -m". See the auditctl(8) manpage for additional details.
Any restrictions (such as with "-F") beyond those provided in the example rules are not in strict compliance with this requirement, and are a finding unless justified and documented appropriately.
The use of audit keys consistent with the provided example is encouraged to provide for uniform audit logs, however omitting the audit key or using an alternate audit key is not a finding.
Procedure:
A Real Time Operating System (RTOS) provides specialized system scheduling which causes an inordinate number of messages to be produced when the sched_setparam and set_setscheduler are audited. This not only may degrade the system speed to an unusable level but obscures any forensic information which may otherwise have been useful.
Unless the operating system is a Red Hat 5 based RTOS (including MRG and AS5300) the following should also be present in /etc/audit/audit.rules
-a exit,always -F arch=<ARCH> -S sched_setparam
Restart the auditd service.
# service auditd restart |
V-29249 |
CCE-14051-7 |
medium |
The audit system must be configured to audit all administrative, privileged, and security actions. |
If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise. |
|
The "-F arch=<ARCH>"restriction is required on dual-architecture systems (such as x86_64). On dual-architecture systems, two separate rules must exist - one for each architecture supported. Use the generic architectures "b32" and "b64" for specifying these rules.
On single architecture systems, the "-F arch=<ARCH>"restriction may be omitted, but if present must match either the architecture of the system or its corresponding generic architecture. The architecture of the system may be determined by running "uname -m". See the auditctl(8) manpage for additional details.
Any restrictions (such as with "-F") beyond those provided in the example rules are not in strict compliance with this requirement, and are a finding unless justified and documented appropriately.
The use of audit keys consistent with the provided example is encouraged to provide for uniform audit logs, however omitting the audit key or using an alternate audit key is not a finding.
Procedure:
A Real Time Operating System (RTOS) provides specialized system scheduling which causes an inordinate number of messages to be produced when the sched_setparam and set_setscheduler are audited. This not only may degrade the system speed to an unusable level but obscures any forensic information which may otherwise have been useful.
Unless the operating system is a Red Hat 5 based RTOS (including MRG and AS5300) the following should also be present in /etc/audit/audit.rules
-a exit,always -F arch=<ARCH> -S sched_setscheduler
Restart the auditd service.
# service auditd restart |
V-29250 |
CCE-14058-2 |
medium |
The audit system must be configured to audit all discretionary access control permission modifications. |
If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise. |
|
The "-F arch=<ARCH>" restriction is required on dual-architecture systems (such as x86_64). On dual-architecture systems, two separate rules must exist - one for each architecture supported. Use the generic architectures "b32" and "b64" for specifying these rules.
On single architecture systems, the "-F arch=<ARCH>" restriction may be omitted, but if present must match either the architecture of the system or its corresponding generic architecture. The architecture of the system may be determined by running "uname -m". See the auditctl(8) manpage for additional details.
Any restrictions (such as with "-F") beyond those provided in the example rules are not in strict compliance with this requirement, and are a finding unless justified and documented appropriately.
The use of audit keys consistent with the provided example is encouraged to provide for uniform audit logs, however omitting the audit key or using an alternate audit key is not a finding.
Procedure:
Edit the audit.rules file and add the following lines to enable auditing of discretionary access control permissions modifications.
-a exit,always -F arch=<ARCH> -S fchmod
Restart the auditd service.
# service auditd restart |
V-29251 |
CCE-14058-2 |
medium |
The audit system must be configured to audit all discretionary access control permission modifications. |
If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise. |
|
The "-F arch=<ARCH>" restriction is required on dual-architecture systems (such as x86_64). On dual-architecture systems, two separate rules must exist - one for each architecture supported. Use the generic architectures "b32" and "b64" for specifying these rules.
On single architecture systems, the "-F arch=<ARCH>" restriction may be omitted, but if present must match either the architecture of the system or its corresponding generic architecture. The architecture of the system may be determined by running "uname -m". See the auditctl(8) manpage for additional details.
Any restrictions (such as with "-F") beyond those provided in the example rules are not in strict compliance with this requirement, and are a finding unless justified and documented appropriately.
The use of audit keys consistent with the provided example is encouraged to provide for uniform audit logs, however omitting the audit key or using an alternate audit key is not a finding.
Procedure:
Edit the audit.rules file and add the following lines to enable auditing of discretionary access control permissions modifications.
-a exit,always -F arch=<ARCH> -S fchmodat
Restart the auditd service.
# service auditd restart |
V-29252 |
CCE-14058-2 |
medium |
The audit system must be configured to audit all discretionary access control permission modifications. |
If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise. |
|
The "-F arch=<ARCH>" restriction is required on dual-architecture systems (such as x86_64). On dual-architecture systems, two separate rules must exist - one for each architecture supported. Use the generic architectures "b32" and "b64" for specifying these rules.
On single architecture systems, the "-F arch=<ARCH>" restriction may be omitted, but if present must match either the architecture of the system or its corresponding generic architecture. The architecture of the system may be determined by running "uname -m". See the auditctl(8) manpage for additional details.
Any restrictions (such as with "-F") beyond those provided in the example rules are not in strict compliance with this requirement, and are a finding unless justified and documented appropriately.
The use of audit keys consistent with the provided example is encouraged to provide for uniform audit logs, however omitting the audit key or using an alternate audit key is not a finding.
Procedure:
Edit the audit.rules file and add the following lines to enable auditing of discretionary access control permissions modifications.
-a exit,always -F arch=<ARCH> -S chown
Additionally, the following rule is required in systems supporting the 32-bit syscall table (such as i686 and x86_64):
-a exit,always -F arch=<ARCH> -S chown32
Restart the auditd service.
# service auditd restart |
V-29253 |
CCE-14058-2 |
medium |
The audit system must be configured to audit all discretionary access control permission modifications. |
If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise. |
|
The "-F arch=<ARCH>" restriction is required on dual-architecture systems (such as x86_64). On dual-architecture systems, two separate rules must exist - one for each architecture supported. Use the generic architectures "b32" and "b64" for specifying these rules.
On single architecture systems, the "-F arch=<ARCH>" restriction may be omitted, but if present must match either the architecture of the system or its corresponding generic architecture. The architecture of the system may be determined by running "uname -m". See the auditctl(8) manpage for additional details.
Any restrictions (such as with "-F") beyond those provided in the example rules are not in strict compliance with this requirement, and are a finding unless justified and documented appropriately.
The use of audit keys consistent with the provided example is encouraged to provide for uniform audit logs, however omitting the audit key or using an alternate audit key is not a finding.
Procedure:
Edit the audit.rules file and add the following lines to enable auditing of discretionary access control permissions modifications.
-a exit,always -F arch=<ARCH> -S fchown
Additionally, the following rule is required in systems supporting the 32-bit syscall table (such as i686 and x86_64):
-a exit,always -F arch=<ARCH> -S fchown32
Restart the auditd service.
# service auditd restart |
V-29255 |
CCE-14058-2 |
medium |
The audit system must be configured to audit all discretionary access control permission modifications. |
If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise. |
|
The "-F arch=<ARCH>" restriction is required on dual-architecture systems (such as x86_64). On dual-architecture systems, two separate rules must exist - one for each architecture supported. Use the generic architectures "b32" and "b64" for specifying these rules.
On single architecture systems, the "-F arch=<ARCH>" restriction may be omitted, but if present must match either the architecture of the system or its corresponding generic architecture. The architecture of the system may be determined by running "uname -m". See the auditctl(8) manpage for additional details.
Any restrictions (such as with "-F") beyond those provided in the example rules are not in strict compliance with this requirement, and are a finding unless justified and documented appropriately.
The use of audit keys consistent with the provided example is encouraged to provide for uniform audit logs, however omitting the audit key or using an alternate audit key is not a finding.
Procedure:
Edit the audit.rules file and add the following lines to enable auditing of discretionary access control permissions modifications.
-a exit,always -F arch=<ARCH> -S fchownat
Restart the auditd service.
# service auditd restart |
V-29257 |
CCE-14058-2 |
medium |
The audit system must be configured to audit all discretionary access control permission modifications. |
If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise. |
|
The "-F arch=<ARCH>" restriction is required on dual-architecture systems (such as x86_64). On dual-architecture systems, two separate rules must exist - one for each architecture supported. Use the generic architectures "b32" and "b64" for specifying these rules.
On single architecture systems, the "-F arch=<ARCH>" restriction may be omitted, but if present must match either the architecture of the system or its corresponding generic architecture. The architecture of the system may be determined by running "uname -m". See the auditctl(8) manpage for additional details.
Any restrictions (such as with "-F") beyond those provided in the example rules are not in strict compliance with this requirement, and are a finding unless justified and documented appropriately.
The use of audit keys consistent with the provided example is encouraged to provide for uniform audit logs, however omitting the audit key or using an alternate audit key is not a finding.
Procedure:
Edit the audit.rules file and add the following lines to enable auditing of discretionary access control permissions modifications.
-a exit,always -F arch=<ARCH> -S lchown
Additionally, the following rule is required in systems supporting the 32-bit syscall table (such as i686 and x86_64):
-a exit,always -F arch=<ARCH> -S lchown32
Restart the auditd service.
# service auditd restart |
V-29259 |
CCE-14058-2 |
medium |
The audit system must be configured to audit all discretionary access control permission modifications. |
If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise. |
|
The "-F arch=<ARCH>" restriction is required on dual-architecture systems (such as x86_64). On dual-architecture systems, two separate rules must exist - one for each architecture supported. Use the generic architectures "b32" and "b64" for specifying these rules.
On single architecture systems, the "-F arch=<ARCH>" restriction may be omitted, but if present must match either the architecture of the system or its corresponding generic architecture. The architecture of the system may be determined by running "uname -m". See the auditctl(8) manpage for additional details.
Any restrictions (such as with "-F") beyond those provided in the example rules are not in strict compliance with this requirement, and are a finding unless justified and documented appropriately.
The use of audit keys consistent with the provided example is encouraged to provide for uniform audit logs, however omitting the audit key or using an alternate audit key is not a finding.
Procedure:
Edit the audit.rules file and add the following lines to enable auditing of discretionary access control permissions modifications.
-a exit,always -F arch=<ARCH> -S setxattr
Restart the auditd service.
# service auditd restart |
V-29261 |
CCE-14058-2 |
medium |
The audit system must be configured to audit all discretionary access control permission modifications. |
If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise. |
|
The "-F arch=<ARCH>" restriction is required on dual-architecture systems (such as x86_64). On dual-architecture systems, two separate rules must exist - one for each architecture supported. Use the generic architectures "b32" and "b64" for specifying these rules.
On single architecture systems, the "-F arch=<ARCH>" restriction may be omitted, but if present must match either the architecture of the system or its corresponding generic architecture. The architecture of the system may be determined by running "uname -m". See the auditctl(8) manpage for additional details.
Any restrictions (such as with "-F") beyond those provided in the example rules are not in strict compliance with this requirement, and are a finding unless justified and documented appropriately.
The use of audit keys consistent with the provided example is encouraged to provide for uniform audit logs, however omitting the audit key or using an alternate audit key is not a finding.
Procedure:
Edit the audit.rules file and add the following lines to enable auditing of discretionary access control permissions modifications.
-a exit,always -F arch=<ARCH> -S lsetxattr
Restart the auditd service.
# service auditd restart |
V-29272 |
CCE-14058-2 |
medium |
The audit system must be configured to audit all discretionary access control permission modifications. |
If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise. |
|
The "-F arch=<ARCH>" restriction is required on dual-architecture systems (such as x86_64). On dual-architecture systems, two separate rules must exist - one for each architecture supported. Use the generic architectures "b32" and "b64" for specifying these rules.
On single architecture systems, the "-F arch=<ARCH>" restriction may be omitted, but if present must match either the architecture of the system or its corresponding generic architecture. The architecture of the system may be determined by running "uname -m". See the auditctl(8) manpage for additional details.
Any restrictions (such as with "-F") beyond those provided in the example rules are not in strict compliance with this requirement, and are a finding unless justified and documented appropriately.
The use of audit keys consistent with the provided example is encouraged to provide for uniform audit logs, however omitting the audit key or using an alternate audit key is not a finding.
Procedure:
Edit the audit.rules file and add the following lines to enable auditing of discretionary access control permissions modifications.
-a exit,always -F arch=<ARCH> -S fsetxattr
Restart the auditd service.
# service auditd restart |
V-29274 |
CCE-14058-2 |
medium |
The audit system must be configured to audit all discretionary access control permission modifications. |
If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise. |
|
The "-F arch=<ARCH>" restriction is required on dual-architecture systems (such as x86_64). On dual-architecture systems, two separate rules must exist - one for each architecture supported. Use the generic architectures "b32" and "b64" for specifying these rules.
On single architecture systems, the "-F arch=<ARCH>" restriction may be omitted, but if present must match either the architecture of the system or its corresponding generic architecture. The architecture of the system may be determined by running "uname -m". See the auditctl(8) manpage for additional details.
Any restrictions (such as with "-F") beyond those provided in the example rules are not in strict compliance with this requirement, and are a finding unless justified and documented appropriately.
The use of audit keys consistent with the provided example is encouraged to provide for uniform audit logs, however omitting the audit key or using an alternate audit key is not a finding.
Procedure:
Edit the audit.rules file and add the following lines to enable auditing of discretionary access control permissions modifications.
-a exit,always -F arch=<ARCH> -S removexattr
Restart the auditd service.
# service auditd restart |
V-29275 |
CCE-14058-2 |
medium |
The audit system must be configured to audit all discretionary access control permission modifications. |
If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise. |
|
The "-F arch=<ARCH>" restriction is required on dual-architecture systems (such as x86_64). On dual-architecture systems, two separate rules must exist - one for each architecture supported. Use the generic architectures "b32" and "b64" for specifying these rules.
On single architecture systems, the "-F arch=<ARCH>" restriction may be omitted, but if present must match either the architecture of the system or its corresponding generic architecture. The architecture of the system may be determined by running "uname -m". See the auditctl(8) manpage for additional details.
Any restrictions (such as with "-F") beyond those provided in the example rules are not in strict compliance with this requirement, and are a finding unless justified and documented appropriately.
The use of audit keys consistent with the provided example is encouraged to provide for uniform audit logs, however omitting the audit key or using an alternate audit key is not a finding.
Procedure:
Edit the audit.rules file and add the following lines to enable auditing of discretionary access control permissions modifications.
-a exit,always -F arch=<ARCH> -S lremovexattr
Restart the auditd service.
# service auditd restart |
V-29279 |
CCE-14058-2 |
medium |
The audit system must be configured to audit all discretionary access control permission modifications. |
If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise. |
|
The "-F arch=<ARCH>" restriction is required on dual-architecture systems (such as x86_64). On dual-architecture systems, two separate rules must exist - one for each architecture supported. Use the generic architectures "b32" and "b64" for specifying these rules.
On single architecture systems, the "-F arch=<ARCH>" restriction may be omitted, but if present must match either the architecture of the system or its corresponding generic architecture. The architecture of the system may be determined by running "uname -m". See the auditctl(8) manpage for additional details.
Any restrictions (such as with "-F") beyond those provided in the example rules are not in strict compliance with this requirement, and are a finding unless justified and documented appropriately.
The use of audit keys consistent with the provided example is encouraged to provide for uniform audit logs, however omitting the audit key or using an alternate audit key is not a finding.
Procedure:
Edit the audit.rules file and add the following lines to enable auditing of discretionary access control permissions modifications.
-a exit,always -F arch=<ARCH> -S fremovexattr
Restart the auditd service.
# service auditd restart |
V-29281 |
CCE-14688-6 |
medium |
The audit system must be configured to audit the loading and unloading of dynamic kernel modules - delete_module. |
Actions concerning dynamic kernel modules must be recorded as they are substantial events. Dynamic kernel modules can increase the attack surface of a system. A malicious kernel module can be used to substantially alter the functioning of a system, often with the purpose of hiding a compromise from the SA. |
|
The "-F arch=<ARCH>" restriction is required on dual-architecture systems (such as x86_64). On dual-architecture systems, two separate rules must exist - one for each architecture supported. Use the generic architectures "b32" and "b64" for specifying these rules.
On single architecture systems, the "-F arch=<ARCH>" restriction may be omitted, but if present must match either the architecture of the system or its corresponding generic architecture. The architecture of the system may be determined by running "uname -m". See the auditctl(8) manpage for additional details.
Any restrictions (such as with "-F") beyond those provided in the example rules are not in strict compliance with this requirement, and are a finding unless justified and documented appropriately.
The use of audit keys consistent with the provided example is encouraged to provide for uniform audit logs, however omitting the audit key or using an alternate audit key is not a finding.
Procedure:
Configure auditing of the delete_module syscalls.
Add the following to the "etc/audit/audit.rules" or "etc/audit.rules" file:
-a exit,always -S delete_module
Restart the auditd service.
# service auditd restart |
V-29284 |
CCE-14688-6 |
medium |
The audit system must be configured to audit the loading and unloading of dynamic kernel modules - /sbin/insmod. |
Actions concerning dynamic kernel modules must be recorded as they are substantial events. Dynamic kernel modules can increase the attack surface of a system. A malicious kernel module can be used to substantially alter the functioning of a system, often with the purpose of hiding a compromise from the SA. |
|
The "-F arch=<ARCH>" restriction is required on dual-architecture systems (such as x86_64). On dual-architecture systems, two separate rules must exist - one for each architecture supported. Use the generic architectures "b32" and "b64" for specifying these rules.
On single architecture systems, the "-F arch=<ARCH>" restriction may be omitted, but if present must match either the architecture of the system or its corresponding generic architecture. The architecture of the system may be determined by running "uname -m". See the auditctl(8) manpage for additional details.
Any restrictions (such as with "-F") beyond those provided in the example rules are not in strict compliance with this requirement, and are a finding unless justified and documented appropriately.
The use of audit keys consistent with the provided example is encouraged to provide for uniform audit logs, however omitting the audit key or using an alternate audit key is not a finding.
Procedure:
Configure auditing of the /sbin/insmod, files.
Add the following to the "etc/audit/audit.rules" or "etc/audit.rules" file:
-w /sbin/insmod -p x
Restart the auditd service.
# service auditd restart |
V-29286 |
CCE-14688-6 |
medium |
The audit system must be configured to audit the loading and unloading of dynamic kernel modules -/sbin/modprobe. |
Actions concerning dynamic kernel modules must be recorded as they are substantial events. Dynamic kernel modules can increase the attack surface of a system. A malicious kernel module can be used to substantially alter the functioning of a system, often with the purpose of hiding a compromise from the SA. |
|
The "-F arch=<ARCH>" restriction is required on dual-architecture systems (such as x86_64). On dual-architecture systems, two separate rules must exist - one for each architecture supported. Use the generic architectures "b32" and "b64" for specifying these rules.
On single architecture systems, the "-F arch=<ARCH>" restriction may be omitted, but if present must match either the architecture of the system or its corresponding generic architecture. The architecture of the system may be determined by running "uname -m". See the auditctl(8) manpage for additional details.
Any restrictions (such as with "-F") beyond those provided in the example rules are not in strict compliance with this requirement, and are a finding unless justified and documented appropriately.
The use of audit keys consistent with the provided example is encouraged to provide for uniform audit logs, however omitting the audit key or using an alternate audit key is not a finding.
Procedure:
-w /sbin/modprobe -p x
Restart the auditd service.
# service auditd restart |
V-29288 |
CCE-14688-6 |
medium |
The audit system must be configured to audit the loading and unloading of dynamic kernel modules - /sbin/rmmod |
Actions concerning dynamic kernel modules must be recorded as they are substantial events. Dynamic kernel modules can increase the attack surface of a system. A malicious kernel module can be used to substantially alter the functioning of a system, often with the purpose of hiding a compromise from the SA. |
|
The "-F arch=<ARCH>" restriction is required on dual-architecture systems (such as x86_64). On dual-architecture systems, two separate rules must exist - one for each architecture supported. Use the generic architectures "b32" and "b64" for specifying these rules.
On single architecture systems, the "-F arch=<ARCH>" restriction may be omitted, but if present must match either the architecture of the system or its corresponding generic architecture. The architecture of the system may be determined by running "uname -m". See the auditctl(8) manpage for additional details.
Any restrictions (such as with "-F") beyond those provided in the example rules are not in strict compliance with this requirement, and are a finding unless justified and documented appropriately.
The use of audit keys consistent with the provided example is encouraged to provide for uniform audit logs, however omitting the audit key or using an alternate audit key is not a finding.
Procedure:
Configure auditing of the /sbin/rmmod file.
Add the following to the "etc/audit/audit.rules" or "etc/audit.rules" file:
-w /sbin/rmmod -p x
Restart the auditd service.
# service auditd restart |
V-29289 |
CCI-000225 |
medium |
Files in cron script directories must have mode 0700 or less permissive. |
To protect the integrity of scheduled system jobs and prevent malicious modification to these jobs, crontab files must be secured. |
|
Change the mode of the cron scripts.
# chmod 0700 /etc/cron.daily/* /etc/cron.hourly/* /etc/cron.monthly/* /etc/cron.weekly/* |
V-766 |
CCE-3410-8 |
medium |
The system must disable accounts after three consecutive unsuccessful login attempts. |
Disabling accounts after a limited number of unsuccessful login attempts improves protection against password guessing attacks. |
|
By default link /etc/pam.d/system-auth points to /etc/pam.d/system-auth-ac which is the file maintained by the authconfig utility. In order to add pam options other than those available via the utility create /etc/pam.d/system-auth-local with the options and including system-auth-ac. In order to set the account lockout to three failed attempts the content should be similar to:
auth required pam_access.so
auth required pam_tally2.so deny=3
auth include system-auth-ac
account required pam_tally2.so
account include system-auth-ac
password include system-auth-ac
session include system-auth-ac
Once system-auth-local is written reset the /etc/pam.d/system-auth to point to system-auth-local. This is necessary because authconfig writes directly to system-auth-ac so any changes made by hand will be lost if authconfig is run. |
V-778 |
CCI-000770 |
medium |
The system must prevent the root account from directly logging in except from the system console. |
Limiting the root account direct logins to only system consoles protects the root account from direct unauthorized access from a non-console device. |
|
Create if needed and set the contents of /etc/securetty to a "console" or "tty" device.
# echo console > /etc/securetty
or
# echo tty1 > /etc/securetty |
V-811 |
CCE-4292-9 |
medium |
Auditing must be implemented. |
Without auditing, individual system accesses cannot be tracked and malicious activity cannot be detected and traced back to an individual account. |
|
Start the auditd service and set it to start on boot.
# service auditd start ; chkconfig auditd on |