Guide to the Secure Configuration of Red Hat Enterprise Linux 5
with profile Upstream STIG for Red Hat Enterprise Linux 5 ServerThis profile is being developed under the DoD consensus model to become a STIG in coordination with DISA FSO.
scap-security-guide package which is developed at
https://www.open-scap.org/security-policies/scap-security-guide.
Providing system administrators with such guidance informs them how to securely configure systems under their control in a variety of network roles. Policy makers and baseline creators can use this catalog of settings, with its associated references to higher-level security control catalogs, in order to assist them in security baseline creation. This guide is a catalog, not a checklist, and satisfaction of every item is not likely to be possible or sensible in many operational scenarios. However, the XCCDF format enables granular selection and adjustment of settings, and their association with OVAL and OCIL content provides an automated checking capability. Transformations of this document, and its associated automated checking content, are capable of providing baselines that meet a diverse set of policy objectives. Some example XCCDF Profiles, which are selections of items that form checklists and can be used as baselines, are available with this guide. They can be processed, in an automated fashion, with tools that support the Security Content Automation Protocol (SCAP). The DISA STIG for Red Hat Enterprise Linux 5, which provides required settings for US Department of Defense systems, is one example of a baseline created from this guidance.
This benchmark is a direct port of a SCAP Security Guide benchmark developed for Red Hat Enterprise Linux. It has been modified through an automated process to remove specific dependencies on Red Hat Enterprise Linux and to function with Scientifc Linux. The result is a generally useful SCAP Security Guide benchmark with the following caveats:
- Scientifc Linux is not an exact copy of Red Hat Enterprise Linux. Scientific Linux is a Linux distribution produced by Fermi National Accelerator Laboratory. It is a free and open source operating system based on Red Hat Enterprise Linux and aims to be "as close to the commercial enterprise distribution as we can get it." There may be configuration differences that produce false positives and/or false negatives. If this occurs please file a bug report.
- Scientifc Linux is derived from the free and open source software made available by Red Hat, but it is not produced, maintained or supported by Red Hat. Scientifc Linux has its own build system, compiler options, patchsets, and is a community supported, non-commercial operating system. Scientifc Linux does not inherit certifications or evaluations from Red Hat Enterprise Linux. As such, some configuration rules (such as those requiring FIPS 140-2 encryption) will continue to fail on Scientifc Linux.
Members of the Scientifc Linux community are invited to participate in OpenSCAP and SCAP Security Guide development. Bug reports and patches can be sent to GitHub: https://github.com/OpenSCAP/scap-security-guide. The mailing list is at https://fedorahosted.org/mailman/listinfo/scap-security-guide.
| Profile Title | Upstream STIG for Red Hat Enterprise Linux 5 Server |
|---|---|
| Profile ID | xccdf_org.ssgproject.content_profile_stig-rhel5-server-upstream |
Revision History
Current version: 0.1.31
- draft (as of 2017-04-20)
Platforms
- cpe:/o:redhat:enterprise_linux:4
- cpe:/o:scientificlinux:scientificlinux:4
- cpe:/o:redhat:enterprise_linux:5
- cpe:/o:scientificlinux:scientificlinux:5
Table of Contents
- System Settings
- Installing and Maintaining Software
- File Permissions and Masks
- SELinux
- Account and Access Control
- Network Configuration and Firewalls
- Configure Syslog
- System Accounting with auditd
- Services
Checklist
| contains 456 rules |
System SettingsgroupContains rules that check correct system settings. |
| contains 370 rules |
Installing and Maintaining SoftwaregroupThe following sections contain information on security-relevant choices during the initial operating system installation process and the setup of software updates. |
| contains 12 rules |
Disk PartitioninggroupTo ensure separation and protection of data, there
are top-level system directories which should be placed on their
own physical partition or logical volume. The installer's default
partitioning scheme creates separate logical volumes for
|
| contains 4 rules |
Ensure /tmp Located On Separate Partitionrule
The
The |
Ensure /var Located On Separate PartitionruleThe
Ensuring that |
Ensure /var/log/audit Located On Separate Partitionrule
Audit logs are stored in the
Placing |
Ensure /home Located On Separate Partitionrule
If user home directories will be stored locally, create a separate partition
for
Ensuring that |
Updating SoftwaregroupThe |
| contains 1 rule |
Ensure gpgcheck Enabled For All Yum Package RepositoriesruleTo ensure signature checking is not disabled for
any repos, remove any lines from files in gpgcheck=0Rationale: Ensuring all packages' cryptographic signatures are valid prior to installation ensures the authenticity of the software and protects against malicious tampering. Remediation script: |
Software Integrity Checkinggroup
Both the AIDE (Advanced Intrusion Detection Environment)
software and the RPM package management system provide
mechanisms for verifying the integrity of installed software.
AIDE uses snapshots of file metadata (such as hashes) and compares these
to current system files in order to detect changes.
The RPM package management system can conduct integrity
checks by comparing information in its metadata database with
files installed on the system.
|
| contains 7 rules |
Verify Integrity with AIDEgroupAIDE conducts integrity checks by comparing information about
files with previously-gathered information. Ideally, the AIDE database is
created immediately after initial system configuration, and then again after any
software update. AIDE is highly configurable, with further configuration
information located in |
| contains 2 rules |
Build and Test AIDE DatabaseruleRun the following command to generate a new database: # /usr/sbin/aide --initBy default, the database will be written to the file /var/lib/aide/aide.db.new.gz.
Storing the database, the configuration file /etc/aide.conf, and the binary
/usr/sbin/aide (or hashes of these files), in a secure location (such as on read-only media) provides additional assurance about their integrity.
The newly-generated database can be installed as follows:
# cp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gzTo initiate a manual check, run the following command: # /usr/sbin/aide --checkIf this check produces any unexpected output, investigate. Rationale: For AIDE to be effective, an initial database of "known-good" information about files must be captured and it should be able to be verified against the installed files. Remediation script: |
Configure Periodic Execution of AIDErule
To implement a daily execution of AIDE at 4:05am using cron, add the following line to 05 4 * * * root /usr/sbin/aide --checkAIDE can be executed periodically through other means; this is merely one example. Rationale: By default, AIDE does not install itself for periodic execution. Periodically running AIDE is necessary to reveal unexpected changes in installed files. Remediation script: |
Additional Security SoftwaregroupAdditional security software that is not provided or supported by Red Hat can be installed to provide complementary or duplicative security capabilities to those provided by the base platform. Add-on software may not be appropriate for some specialized systems. |
| contains 5 rules |
Install Intrusion Detection SoftwareruleThe Red Hat platform includes a sophisticated auditing system and SELinux, which provide host-based intrusion detection capabilities. Rationale:Host-based intrusion detection tools provide a system-level defense when an intruder gains access to a system or network. |
Install Virus Scanning SoftwareruleInstall virus scanning software, which uses signatures to search for the presence of viruses on the filesystem. The McAfee uvscan virus scanning tool is provided for DoD systems. Ensure virus definition files are no older than 7 days, or their last release. Configure the virus scanning software to perform scans dynamically on all accessed files. If this is not possible, configure the system to scan all altered files on the system on a daily basis. If the system processes inbound SMTP mail, configure the virus scanner to scan all received mail. Rationale:Virus scanning software can be used to detect if a system has been compromised by computer viruses, as well as to limit their spread to other systems. |
Create a Baseline For Device FilesruleA baseline of device files needs to be generated, and verified on at least a weekly basis. Rationale:If an unauthorized device is allowed to exist on the system, there is the possibility the system may perform unauthorized operations. Remediation script: |
Create a Baseline For SGID FilesruleA baseline of sgid files needs to be generated, and verified on at least a weekly basis. Rationale:Files with the setgid bit set will allow anyone running these files to be temporarily assigned the group id of the file. While many system files depend on these attributes for proper operation, security problems can result if setgid is assigned to programs allowing reading and writing of files, or shell escapes. Remediation script: |
Create a Baseline For SUID FilesruleA baseline of suid files needs to be generated, and verified on at least a weekly basis. Rationale:Files with the setuid bit set will allow anyone running these files to be temporarily assigned the UID of the file. While many system files depend on these attributes for proper operation, security problems can result if setuid is assigned to programs allowing reading and writing of files, or shell escapes. Remediation script: |
File Permissions and MasksgroupTraditional Unix security relies heavily on file and
directory permissions to prevent unauthorized users from reading or
modifying files to which they should not have access.
$ mount -t xfs | awk '{print $3}'
For any systems that use a different
local filesystem type, modify this command as appropriate.
|
| contains 235 rules |
Restrict Partition Mount OptionsgroupSystem partitions can be mounted with certain options
that limit what files on those partitions can do. These options
are set in the |
| contains 2 rules |
Add nodev Option to Removable Media PartitionsruleThe The only legitimate location for device files is the |
Add nosuid Option to Removable Media PartitionsruleThe The presence of suid and sgid executables should be tightly controlled. Allowing users to introduce suid or sgid binaries from partitions mounted off of removable media would allow them to introduce their own highly-privileged programs. |
Restrict Dynamic Mounting and Unmounting of FilesystemsgroupLinux includes a number of facilities for the automated addition
and removal of filesystems on a running system. These facilities may be
necessary in many environments, but this capability also carries some risk -- whether direct
risk from allowing users to introduce arbitrary filesystems,
or risk that software flaws in the automated mount facility itself could
allow an attacker to compromise the system.
# find /lib/modules/`uname -r`/kernel/fs -type f -name '*.ko'If these filesystems are not required then they can be explicitly disabled in a configuratio file in /etc/modprobe.d.
|
| contains 3 rules |
Disable Modprobe Loading of USB Storage Driverrule
To prevent USB storage devices from being used, configure the kernel module loading system
to prevent automatic loading of the USB storage driver.
To configure the system to prevent the install usb-storage /bin/trueThis will prevent the modprobe program from loading the usb-storage
module, but will not prevent an administrator (or another program) from using the
insmod program to load the module manually.Rationale:USB storage devices such as thumb drives can be used to introduce malicious software. Remediation script: |
Disable Kernel Support for USB via Bootloader Configurationrule
All USB support can be disabled by adding the kernel /vmlinuz-VERSION ro vga=ext root=/dev/VolGroup00/LogVol00 rhgb quiet nousbWARNING: Disabling all kernel support for USB will cause problems for systems with USB-based keyboards, mice, or printers. This configuration is infeasible for systems which require USB devices, which is common.Rationale: Disabling the USB subsystem within the Linux kernel at system boot will protect against potentially malicious USB devices, although it is only practical in specialized systems. Remediation script: |
Disable the AutomounterruleThe $ sudo chkconfig autofs offRationale: Disabling the automounter permits the administrator to
statically control filesystem mounting through |
Verify Permissions on Important Files and DirectoriesgroupPermissions for many files on a system must be set restrictively to ensure sensitive information is properly protected. This section discusses important permission restrictions which can be verified to ensure that no harmful discrepancies have arisen. |
| contains 227 rules |
Verify Permissions on Files with Local Account Information and CredentialsgroupThe default restrictive permissions for files which act as
important security databases such as |
| contains 15 rules |
Verify User Who Owns shadow Filerule
To properly set the owner of $ sudo chown root /etc/shadowRationale: The |
Verify Permissions on shadow Filerule
To properly set the permissions of $ sudo chmod 0400 /etc/shadowRationale: The |
Verify Extended ACLs on shadow FileruleNo extended ACLs should be applied. Rationale:The |
Verify User Who Owns group Filerule
To properly set the owner of $ sudo chown root /etc/groupRationale: The |
Verify Group Who Owns group Filerule
To properly set the group owner of $ sudo chgrp root /etc/groupRationale: The |
Verify Permissions on group Filerule
To properly set the permissions of $ sudo chmod 644 /etc/groupRationale: The |
Verify Extended ACLs on group FileruleNo extended ACLs should be applied. Rationale:The |
Verify User Who Owns gshadow Filerule
To properly set the owner of $ sudo chown root /etc/gshadowRationale: The |
Verify Group Who Owns gshadow Filerule
To properly set the group owner of $ sudo chgrp root /etc/gshadowRationale: The |
Verify Permissions on gshadow Filerule
To properly set the permissions of $ sudo chmod 0400 /etc/gshadowRationale: The |
Verify Extended ACLs on gshadow FileruleNo extended ACLs should be applied. Rationale:The |
Verify User Who Owns passwd Filerule
To properly set the owner of $ sudo chown root /etc/passwdRationale: The |
Verify Group Who Owns passwd Filerule
To properly set the group owner of $ sudo chgrp root /etc/passwdRationale: The |
Verify Permissions on passwd Filerule
To properly set the permissions of $ sudo chmod 0644 /etc/passwdRationale: If the |
Verify Extended ACLs on passwd FileruleNo extended ACLs should be applied. Rationale:The |
Verify File Permissions Within Some Important DirectoriesgroupSome directories contain files whose confidentiality or integrity is notably important and may also be susceptible to misconfiguration over time, particularly if unpackaged software is installed. As such, an argument exists to verify that files' permissions within these directories remain configured correctly and restrictively. |
| contains 6 rules |
Verify that Shared Library Files Have Restrictive PermissionsruleSystem-wide shared library files, which are linked to executables during process load time or run time, are stored in the following directories by default: /lib /lib64 /usr/lib /usr/lib64Kernel modules, which can be added to the kernel during runtime, are stored in /lib/modules. All files in these directories
should not be group-writable or world-writable. If any file in these
directories is found to be group-writable or world-writable, correct
its permission with the following command:
# chmod go-w FILERationale: Files from shared library directories are loaded into the address space of processes (including privileged ones) or of the kernel itself at runtime. Restrictive permissions are necessary to protect the integrity of the system. Remediation script: |
Verify Extended ACLs on Shared Library FilesruleNo extended ACLs should be applied. Rationale:Remediation script: |
Verify that System Executables Have Restrictive PermissionsruleSystem executables are stored in the following directories by default: /bin /sbin /usr/bin /usr/libexec /usr/local/bin /usr/local/sbin /usr/sbinAll files in these directories should not be group-writable or world-writable. If any file FILE in these directories is found to be group-writable or world-writable, correct its permission with the following command: # chmod go-w FILERationale: System binaries are executed by privileged users, as well as system services, and restrictive permissions are necessary to ensure execution of these programs cannot be co-opted. Remediation script: |
Verify Extended ACLs on Shared Binary FilesruleNo extended ACLs should be applied. Rationale:Remediation script: |
Verify that System Executables Have Root User OwnershipruleSystem executables are stored in the following directories by default: /bin /sbin /usr/bin /usr/libexec /usr/local/bin /usr/local/sbin /usr/sbinAll files in these directories should be owned by the root user.
If any file FILE in these directories is found
to be owned by a user other than root, correct its ownership with the
following command:
# chown root FILERationale: System binaries are executed by privileged users as well as system services, and restrictive permissions are necessary to ensure that their execution of these programs cannot be co-opted. Remediation script: |
Verify that System Executables Have Root Group OwnershipruleSystem executables are stored in the following directories by default: /bin /sbin /usr/bin /usr/libexec /usr/local/bin /usr/local/sbin /usr/sbinAll files in these directories should be owned by the root user.
If any file FILE in these directories is found
to be owned by a user other than root, correct its ownership with the
following command:
# chown root FILERationale: System binaries are executed by privileged users as well as system services, and restrictive permissions are necessary to ensure that their execution of these programs cannot be co-opted. Remediation script: |
Verify User Who Owns aliases Filerule
To properly set the owner of $ sudo chown root /etc/aliasesRationale:Remediation script: |
Verify Group Who Owns aliases Filerule
To properly set the group owner of $ sudo chgrp root /etc/aliasesRationale:Remediation script: |
Verify Permissions on aliases Filerule
To properly set the permissions of $ sudo chmod 0644 /etc/aliasesRationale:Remediation script: |
Verify Extended ACLs on AliasesruleNo extended ACLs should be applied. Rationale:Remediation script: |
Verify User Who Owns aliases Filerule
To properly set the owner of $ sudo chown root /etc/aliasesRationale:Remediation script: |
Verify Group Who Owns aliases Filerule
To properly set the group owner of $ sudo chgrp root /etc/aliasesRationale:Remediation script: |
Verify Permissions on aliases Filerule
To properly set the permissions of $ sudo chmod 0755 /etc/aliasesRationale:Remediation script: |
Verify Extended ACLs on Aliases FilesruleNo extended ACLs should be applied. Rationale:Remediation script: |
Verify User Who Owns Audio Device Filesrule
To properly set the owner of $ sudo chown root /dev/audioRationale:Remediation script: |
Verify Group Who Owns Audio Device Filesrule
To properly set the group owner of $ sudo chgrp root /dev/audioRationale:Remediation script: |
Verify Permissions on Audio Device Filesrule
To properly set the permissions of $ sudo chmod 0660 /dev/audioRationale:Remediation script: |
Verify Extended ACLs on Audio Device FilesruleNo extended ACLs should be applied. Rationale:Remediation script: |
Verify User Who Owns Audit Log Filesrule
To properly set the owner of $ sudo chown root /var/log/audit/audit.logRationale:Remediation script: |
Verify Group Who Owns Audit Log Filesrule
To properly set the group owner of $ sudo chgrp root /var/log/audit/audit.logRationale:Remediation script: |
Verify Permissions on Audit Log FilesruleSystem Audit Log Directory Must Have Mode 0755 or Less Permissive and System Audit Logs Must Have Mode 0640 or Less Permissive. Change the mode of the audit log directory with the following command: # chmod 0755 /var/log/audit/Change the mode of the audit log files with the following command: # chmod 0640 audit_fileRationale: If users can write to audit logs, audit trails can be modified or destroyed. Remediation script: |
Verify Extended ACLs on Audit Log FilesruleNo extended ACLs should be applied. Rationale:Remediation script: |
Verify User Who Owns Audit Tool Filesrule
To properly set the owner of $ sudo chown root /sbin/au*Rationale:Remediation script: |
Verify Group Who Owns Audit Tool Filesrule
To properly set the group owner of $ sudo chgrp root /sbin/au*Rationale:Remediation script: |
Verify Permissions on Audit Tool Filesrule
To properly set the permissions of $ sudo chmod 0750 /sbin/au*Rationale:Remediation script: |
Verify Extended ACLs on Audit Tool FilesruleNo extended ACLs should be applied. Rationale:Remediation script: |
Verify User Who Owns Tracerouterule
To properly set the owner of $ sudo chown root /bin/tracerouteRationale:Remediation script: |
Verify Group Who Owns Tracerouterule
To properly set the group owner of $ sudo chgrp root /bin/tracerouteRationale:Remediation script: |
Verify Permissions on Tracerouterule
To properly set the permissions of $ sudo chmod 0700 /bin/tracerouteRationale:Remediation script: |
Verify Extended ACLs on TracerouteruleNo extended ACLs should be applied. Rationale:Remediation script: |
Verify User Who Owns Core Dump Directoryrule
To properly set the owner of $ sudo chown root /var/crashRationale:Remediation script: |
Verify Group Who Owns Core Dump Directoryrule
To properly set the group owner of $ sudo chgrp root /var/crashRationale:Remediation script: |
Verify Permissions on Core Dump Directoryrule
To properly set the permissions of $ sudo chmod 0700 /var/crashRationale:Remediation script: |
Verify Extended ACLs on Core Dump DirectoryruleNo extended ACLs should be applied. Rationale:Remediation script: |
Verify Permissions on Cron Log Filesrule
To properly set the permissions of $ sudo chmod 0600 /var/log/cronRationale:Remediation script: |
Verify Extended ACLs on Cron Log FilesruleNo extended ACLs should be applied. Rationale:Remediation script: |
Verify User Who Owns Crontab Directoriesrule
To properly set the owner of $ sudo chown root /var/spool/cronRationale:Remediation script: |
Verify Group Who Owns Crontab Directoriesrule
To properly set the group owner of $ sudo chgrp root /var/spool/cronRationale:Remediation script: |
Verify Permissions on Crontab Directoriesrule
To properly set the permissions of $ sudo chmod 0755 /var/spool/cronRationale:Remediation script: |
Verify Extended ACLs on Crontab DirectoriesruleNo extended ACLs should be applied. Rationale:Remediation script: |
Verify User Who Owns Crontab Filesrule
To properly set the owner of $ sudo chown root /etc/cron*Rationale:Remediation script: |
Verify Group Who Owns Crontab Filesrule
To properly set the group owner of $ sudo chgrp root /etc/cron*Rationale:Remediation script: |
Verify Permissions on Crontab Filesrule
To properly set the permissions of $ sudo chmod 0600 /etc/cron*Rationale:Remediation script: |
Verify Extended ACLs on Crontab FilesruleNo extended ACLs should be applied. Rationale:Remediation script: |
Verify Permissions on Cron Filesrule
To properly set the permissions of $ sudo chmod 0700 /etc/cron*Rationale:Remediation script: |
Verify User Who Owns at.allowrule
To properly set the owner of $ sudo chown root /etc/at.allowRationale:Remediation script: |
Verify Group Who Owns at.allowrule
To properly set the group owner of $ sudo chgrp root /etc/at.allowRationale:Remediation script: |
Verify Permissions on at.allowrule
To properly set the permissions of $ sudo chmod 0600 /etc/at.allowRationale:Remediation script: |
Verify Extended ACLs on at.allowruleNo extended ACLs should be applied. Rationale:Remediation script: |
Verify User Who Owns at.denyrule
To properly set the owner of $ sudo chown root /etc/at.denyRationale:Remediation script: |
Verify Group Who Owns at.denyrule
To properly set the group owner of $ sudo chgrp root /etc/at.denyRationale:Remediation script: |
Verify Permissions on at.denyrule
To properly set the permissions of $ sudo chmod 0600 /etc/at.denyRationale:Remediation script: |
Verify Extended ACLs on at.denyruleNo extended ACLs should be applied. Rationale:Remediation script: |
Verify User Who Owns cron.allowrule
To properly set the owner of $ sudo chown root /etc/cron.allowRationale:Remediation script: |
Verify Group Who Owns cron.allowrule
To properly set the group owner of $ sudo chgrp root /etc/cron.allowRationale:Remediation script: |
Verify Permissions on cron.allowrule
To properly set the permissions of $ sudo chmod 0600 /etc/cron.allowRationale:Remediation script: |
Verify Extended ACLs on cron.allowruleNo extended ACLs should be applied. Rationale:Remediation script: |
Verify User Who Owns cron.denyrule
To properly set the owner of $ sudo chown root /etc/cron.denyRationale:Remediation script: |
Verify Group Who Owns cron.denyrule
To properly set the group owner of $ sudo chgrp root /etc/cron.denyRationale:Remediation script: |
Verify Permissions on cron.denyrule
To properly set the permissions of $ sudo chmod 0600 /etc/cron.denyRationale:Remediation script: |
Verify Extended ACLs on cron.denyruleNo extended ACLs should be applied. Rationale:Remediation script: |
Verify User Who Owns printers.confrule
To properly set the owner of $ sudo chown root /etc/cups/printers.confRationale:Remediation script: |
Verify Group Who Owns printers.confrule
To properly set the group owner of $ sudo chgrp root /etc/cups/printers.confRationale:Remediation script: |
Verify Permissions on printers.confrule
To properly set the permissions of $ sudo chmod 0644 /etc/cups/printers.confRationale:Remediation script: |
Verify Extended ACLs on printers.confruleNo extended ACLs should be applied. Rationale:Remediation script: |
Verify User Who Owns Exportsrule
To properly set the owner of $ sudo chown root /etc/exportsRationale:Remediation script: |
Verify Group Who Owns Exportsrule
To properly set the group owner of $ sudo chgrp root /etc/exportsRationale:Remediation script: |
Verify Permissions on Exportsrule
To properly set the permissions of $ sudo chmod 0644 /etc/exportsRationale:Remediation script: |
Verify Extended ACLs on ExportsruleNo extended ACLs should be applied. Rationale:Remediation script: |
Verify User Who Owns Hostsrule
To properly set the owner of $ sudo chown root /etc/hostsRationale:Remediation script: |
Verify Group Who Owns Hostsrule
To properly set the group owner of $ sudo chgrp root /etc/hostsRationale:Remediation script: |
Verify Permissions on Hostsrule
To properly set the permissions of $ sudo chmod 0644 /etc/hostsRationale:Remediation script: |
Verify Extended ACLs on HostsruleNo extended ACLs should be applied. Rationale:Remediation script: |
Verify User Who Owns ldap.confrule
To properly set the owner of $ sudo chown root /etc/ldap.confRationale:Remediation script: |
Verify Group Who Owns ldap.confrule
To properly set the group owner of $ sudo chgrp root /etc/ldap.confRationale:Remediation script: |
Verify Permissions on ldap.confrule
To properly set the permissions of $ sudo chmod 0644 /etc/ldap.confRationale:Remediation script: |
Verify Extended ACLs on ldap.confruleNo extended ACLs should be applied. Rationale:Remediation script: |
Verify Permissions on infeed.confrule
To properly set the permissions of $ sudo chmod 0600 /etc/news/infeed.confRationale:Remediation script: |
Verify Extended ACLs on infeed.confruleNo extended ACLs should be applied. Rationale:Remediation script: |
Verify Permissions on incoming.confrule
To properly set the permissions of $ sudo chmod 0600 /etc/news/incoming.confRationale:Remediation script: |
Verify Extended ACLs on incoming.confruleNo extended ACLs should be applied. Rationale:Remediation script: |
Verify Extended ACLs on nnrp.accessruleNo extended ACLs should be applied. Rationale:Remediation script: |
Verify Permissions on passwd.nntprule
To properly set the permissions of $ sudo chmod 0600 /etc/news/passwd.nntpRationale:Remediation script: |
Verify Extended ACLs on passwd.nntpruleNo extended ACLs should be applied. Rationale:Remediation script: |
Verify User Who Owns nsswitch.confrule
To properly set the owner of $ sudo chown root /etc/nsswitch.confRationale:Remediation script: |
Verify Group Who Owns nsswitch.confrule
To properly set the group owner of $ sudo chgrp root /etc/nsswitch.confRationale:Remediation script: |
Verify Permissions on nsswitch.confrule
To properly set the permissions of $ sudo chmod 0644 /etc/nsswitch.confRationale:Remediation script: |
Verify Extended ACLs on nsswitch.confruleNo extended ACLs should be applied. Rationale:Remediation script: |
Verify User Who Owns ntp.confrule
To properly set the owner of $ sudo chown root /etc/ntp.confRationale:Remediation script: |
Verify Group Who Owns ntp.confrule
To properly set the group owner of $ sudo chgrp root /etc/ntp.confRationale:Remediation script: |
Verify Permissions on ntp.confrule
To properly set the permissions of $ sudo chmod 0644 /etc/ntp.confRationale:Remediation script: |
Verify Extended ACLs on ntp.confruleNo extended ACLs should be applied. Rationale:Remediation script: |
Verify User Who Owns resolv.confrule
To properly set the owner of $ sudo chown root /etc/resolv.confRationale:Remediation script: |
Verify Group Who Owns resolv.confrule
To properly set the group owner of $ sudo chgrp root /etc/resolv.confRationale:Remediation script: |
Verify Permissions on resolv.confrule
To properly set the permissions of $ sudo chmod 0644 /etc/resolv.confRationale:Remediation script: |
Verify Extended ACLs on resolv.confruleNo extended ACLs should be applied. Rationale:Remediation script: |
Verify User Who Owns smb.confrule
To properly set the owner of $ sudo chown root /etc/samba/smb.confRationale:Remediation script: |
Verify Group Who Owns smb.confrule
To properly set the group owner of $ sudo chgrp root /etc/samba/smb.confRationale:Remediation script: |
Verify Permissions on smb.confrule
To properly set the permissions of $ sudo chmod 0644 /etc/samba/smb.confRationale:Remediation script: |
Verify Extended ACLs on smb.confruleNo extended ACLs should be applied. Rationale:Remediation script: |
Verify User Who Owns Samba Password Filesrule
To properly set the owner of $ sudo chown root /etc/samba/passdb.tdbRationale:Remediation script: |
Verify Group Who Owns Samba Password Filesrule
To properly set the group owner of $ sudo chgrp root /etc/samba/passdb.tdbRationale:Remediation script: |
Verify Permissions on Samba Password Filesrule
To properly set the permissions of $ sudo chmod 0600 /etc/samba/passdb.tdbRationale:Remediation script: |
Verify Extended ACLs on Samba Password FilesruleNo extended ACLs should be applied. Rationale:Remediation script: |
Verify User Who Owns securettyrule
To properly set the owner of $ sudo chown root /etc/securettyRationale:Remediation script: |
Verify Group Who Owns securettyrule
To properly set the group owner of $ sudo chgrp root /etc/securettyRationale:Remediation script: |
Verify Permissions on securettyrule
To properly set the permissions of $ sudo chmod 0600 /etc/securettyRationale:Remediation script: |
Verify User Who Owns access.confrule
To properly set the owner of $ sudo chown root /etc/access.confRationale:Remediation script: |
Verify Group Who Owns access.confrule
To properly set the group owner of $ sudo chgrp root /etc/access.confRationale:Remediation script: |
Verify Permissions on access.confrule
To properly set the permissions of $ sudo chmod 0640 /etc/access.confRationale:Remediation script: |
Verify Extended ACLs on access.confruleNo extended ACLs should be applied. Rationale:Remediation script: |
Verify User Who Owns servicesrule
To properly set the owner of $ sudo chown root /etc/servicesRationale:Remediation script: |
Verify Group Who Owns servicesrule
To properly set the group owner of $ sudo chgrp root /etc/servicesRationale:Remediation script: |
Verify Permissions on servicesrule
To properly set the permissions of $ sudo chmod 0640 /etc/servicesRationale:Remediation script: |
Verify Extended ACLs on servicesruleNo extended ACLs should be applied. Rationale:Remediation script: |
Verify User Who Owns Skeleton Filesrule
To properly set the owner of $ sudo chown root /etc/skel/*Rationale:Remediation script: |
Verify Group Who Owns Skeleton Filesrule
To properly set the group owner of $ sudo chgrp root /etc/skel/*Rationale:Remediation script: |
Verify Permissions on Skeleton Filesrule
To properly set the permissions of $ sudo chmod 0640 /etc/skel/*Rationale:Remediation script: |
Verify Extended ACLs on Skeleton FilesruleNo extended ACLs should be applied. Rationale:Remediation script: |
Verify User Who Owns sysctl.confrule
To properly set the owner of $ sudo chown root /etc/sysctl.confRationale:Remediation script: |
Verify Group Who Owns sysctl.confrule
To properly set the group owner of $ sudo chgrp root /etc/sysctl.confRationale:Remediation script: |
Verify Permissions on sysctl.confrule
To properly set the permissions of $ sudo chmod 0600 /etc/sysctl.confRationale:Remediation script: |
Verify Extended ACLs on sysctl.confruleNo extended ACLs should be applied. Rationale:Remediation script: |
Verify User Who Owns syslog.confrule
To properly set the owner of $ sudo chown root /etc/syslog.confRationale:Remediation script: |
Verify Group Who Owns syslog.confrule
To properly set the group owner of $ sudo chgrp root /etc/syslog.confRationale:Remediation script: |
Verify Permissions on syslog.confrule
To properly set the permissions of $ sudo chmod 0640 /etc/syslog.confRationale:Remediation script: |
Verify Extended ACLs on syslog.confruleNo extended ACLs should be applied. Rationale:Remediation script: |
Verify User Who Owns xinetd.confrule
To properly set the owner of $ sudo chown root /etc/xinetd.confRationale:Remediation script: |
Verify Group Who Owns xinetd.confrule
To properly set the group owner of $ sudo chgrp root /etc/xinetd.confRationale:Remediation script: |
Verify Permissions on xinetd.confrule
To properly set the permissions of $ sudo chmod 0640 /etc/xinetd.confRationale:Remediation script: |
Verify Extended ACLs on xinetd.confruleNo extended ACLs should be applied. Rationale:Remediation script: |
Verify Permissions on xinet.d Directoryrule
To properly set the permissions of $ sudo chmod 0640 /etc/xinet.d/Rationale:Remediation script: |
Verify Extended ACLs on xinet.d DirectoryruleNo extended ACLs should be applied. Rationale:Remediation script: |
Verify User Who Owns Exports Directoriesrule
To properly set the owner of $ sudo chown root /etc/exportsRationale:Remediation script: |
Verify Group Who Owns Exports Directoriesrule
To properly set the group owner of $ sudo chgrp root /etc/exportsRationale:Remediation script: |
Verify User Who Owns ftpusersrule
To properly set the owner of $ sudo chown root /etc/ftpusersRationale: |
Verify Group Who Owns ftpusersrule
To properly set the group owner of $ sudo chgrp root /etc/ftpusersRationale: |
Verify Permissions on ftpusersrule
To properly set the permissions of $ sudo chmod 0640 /etc/ftpusersRationale:Remediation script: |
Verify Extended ACLs on ftpusersruleNo extended ACLs should be applied. Rationale:Remediation script: |
Verify User Who Owns Global Initialization Filesrule
To properly set the owner of $ sudo chown root /etc/profileRationale: |
Verify Group Who Owns Global Initialization Filesrule
To properly set the group owner of $ sudo chgrp root /etc/profileRationale: |
Verify Permissions on Global Initialization Filesrule
To properly set the permissions of $ sudo chmod 0644 /etc/profileRationale:Remediation script: |
Verify Extended ACLs on Global Initialization FilesruleNo extended ACLs should be applied. Rationale:Remediation script: |
Verify Messaging is Disabled in Global Initialization FilesruleNo global messaging should be enabled. Rationale:Remediation script: |
Verify User Who Owns Home Directoriesrule
To properly set the owner of $ sudo chown root /home/*Rationale: |
Verify Group Who Owns Home Directoriesrule
To properly set the group owner of $ sudo chgrp root /home/*Rationale: |
Ensure that User Home Directories are not Group-Writable or World-ReadableruleFor each human user of the system, view the permissions of the user's home directory: # ls -ld /home/USEREnsure that the directory is not group-writable and that it is not world-readable. If necessary, repair the permissions: # chmod g-w /home/USER # chmod o-rwx /home/USER warning
This action may involve
modifying user home directories. Notify your user community, and
solicit input if appropriate, before making this type of
change. User home directories contain many configuration files which affect the behavior of a user's account. No user should ever have write permission to another user's home directory. Group shared directories can be configured in sub-directories or elsewhere in the filesystem if they are needed. Typically, user home directories should not be world-readable, as it would disclose file names to other users. If a subset of users need read access to one another's home directories, this can be provided using groups or ACLs. |
Verify Extended ACLs on Home DirectoriesruleNo extended ACLs should be applied. Rationale:Remediation script: |
Verify User Who Owns Home Filesrule
To properly set the owner of $ sudo chown root /home/*/*Rationale: |
Verify Group Who Owns Home Filesrule
To properly set the group owner of $ sudo chgrp root /home/*/*Rationale: |
Verify Permissions on Home Filesrule
To properly set the permissions of $ sudo chmod 0750 /home/*/*Rationale:Remediation script: |
Verify Extended ACLs on Home FilesruleNo extended ACLs should be applied. Rationale:Remediation script: |
Verify User Who Owns LDAP CA Certificatesrule
To properly set the owner of $ sudo chown root tls_cacertRationale:Remediation script: |
Verify Group Who Owns LDAP CA Certificatesrule
To properly set the group owner of $ sudo chgrp root tls_cacertRationale:Remediation script: |
Verify Permissions on LDAP CA Certificatesrule
To properly set the permissions of $ sudo chmod 0640 tls_cacertRationale:Remediation script: |
Verify Extended ACLs on LDAP CA CertificatesruleNo extended ACLs should be applied. Rationale:Remediation script: |
Verify User Who Owns LDAP Certificatesrule
To properly set the owner of $ sudo chown root tls_certRationale:Remediation script: |
Verify Group Who Owns LDAP Certificatesrule
To properly set the group owner of $ sudo chgrp root tls_certRationale:Remediation script: |
Verify Permissions on LDAP Certificatesrule
To properly set the permissions of $ sudo chmod 0640 tls_certRationale:Remediation script: |
Verify Extended ACLs on LDAP CertificatesruleNo extended ACLs should be applied. Rationale:Remediation script: |
Verify User Who Owns LDAP Keysrule
To properly set the owner of $ sudo chown root tls_keyRationale:Remediation script: |
Verify Group Who Owns LDAP Keysrule
To properly set the group owner of $ sudo chgrp root tls_keyRationale:Remediation script: |
Verify Permissions on LDAP Keysrule
To properly set the permissions of $ sudo chmod 0600 tls_keyRationale:Remediation script: |
Verify Extended ACLs on LDAP KeysruleNo extended ACLs should be applied. Rationale:Remediation script: |
Verify User Who Owns Local Initialization Filesrule
To properly set the owner of $ sudo chown root ~/.bashrcRationale: |
Verify Group Who Owns Local Initialization Filesrule
To properly set the group owner of $ sudo chgrp root ~/.bashrcRationale: |
Verify Permissions on Local Initialization Filesrule
To properly set the permissions of $ sudo chmod 0740 ~/.bashrcRationale:Remediation script: |
Verify Extended ACLs on Local Initialization FilesruleNo extended ACLs should be applied. Rationale:Remediation script: |
Verify Permissions on Man Pagesrule
To properly set the permissions of $ sudo chmod 0644 /usr/share/manRationale: |
Verify Extended ACLs on Man PagesruleNo extended ACLs should be applied. Rationale:Remediation script: |
Verify Permissions on .Mib Filesrule
To properly set the permissions of $ sudo chmod 0640 *.mibRationale: |
Verify Extended ACLs on .Mib FilesruleNo extended ACLs should be applied. Rationale:Remediation script: |
Verify Permissions on root Directoryrule
To properly set the permissions of $ sudo chmod 0700 /rootRationale:Remediation script: |
Verify Extended ACLs on root DirectoryruleNo extended ACLs should be applied. Rationale:Remediation script: |
Verify User Who Owns Run Control Scriptsrule
To properly set the owner of $ sudo chown root /etc/rc*Rationale: |
Verify Group Who Owns Run Control Scriptsrule
To properly set the group owner of $ sudo chgrp root /etc/rc*Rationale: |
Verify Permissions on Run Control Scriptsrule
To properly set the permissions of $ sudo chmod 0755 /etc/rc*Rationale: |
Verify Extended ACLs on Run Control ScriptsruleNo extended ACLs should be applied. Rationale:Remediation script: |
Verify User Who Owns Shell Filesrule
To properly set the owner of $ sudo chown root /etc/shellsRationale: |
Verify Group Who Owns Shell Filesrule
To properly set the group owner of $ sudo chgrp root /etc/shellsRationale: |
Verify Permissions on Shell Filesrule
To properly set the permissions of $ sudo chmod 0755 /etc/shellsRationale: |
Verify Extended ACLs on Shell FilesruleNo extended ACLs should be applied. Rationale:Remediation script: |
Verify User Who Owns SMTP Logsrule
To properly set the owner of $ sudo chown root /var/log/mail.logRationale: |
Verify Permissions on SMTP Logsrule
To properly set the permissions of $ sudo chmod 0644 /var/log/mail.logRationale: |
Verify Extended ACLs on SMTP LogsruleNo extended ACLs should be applied. Rationale:Remediation script: |
Verify User Who Owns snmpd.confrule
To properly set the owner of $ sudo chown root snmpd.confRationale: |
Verify Group Who Owns snmpd.confrule
To properly set the group owner of $ sudo chgrp root snmpd.confRationale: |
Verify Permissions on snmpd.confrule
To properly set the permissions of $ sudo chmod 0644 snmpd.confRationale:Remediation script: |
Verify Extended ACLs on snmpd.confruleNo extended ACLs should be applied. Rationale:Remediation script: |
Verify Permissions on /etc/ssh/*keyrule
To properly set the permissions of $ sudo chmod 0600 /etc/ssh/*keyRationale: |
Verify Permissions on /etc/ssh/*key.pubrule
To properly set the permissions of $ sudo chmod 0644 /etc/ssh/*key.pubRationale: |
Verify Permissions on TFTP Binaryrule
To properly set the permissions of $ sudo chmod 0755 /etc/xinetd.d/tftpRationale: |
Verify Permissions on /usr/bin/lddrule
To properly set the permissions of $ sudo chmod 0000 /usr/bin/lddRationale:Remediation script: |
Verify Permissions on sbin Directoryrule
To properly set the permissions of $ sudo chmod 0755 /usr/sbin/Rationale: |
Verify Extended ACLs on sbin DirectoryruleNo extended ACLs should be applied. Rationale:Remediation script: |
Verify Permissions on System Logsrule
To properly set the permissions of $ sudo chmod 0640 /var/log/*Rationale:Remediation script: |
Verify Extended ACLs on System LogsruleNo extended ACLs should be applied. Rationale:Remediation script: |
Verify User Who Owns At Directoryrule
To properly set the owner of $ sudo chown root /var/spool/at/Rationale: |
Verify Group Who Owns At Directoryrule
To properly set the group owner of $ sudo chgrp root /var/spool/at/Rationale: |
Verify Permissions on At Directoryrule
To properly set the permissions of $ sudo chmod 0755 /var/spool/at/Rationale: |
Verify Extended ACLs on At DirectoryruleNo extended ACLs should be applied. Rationale:Remediation script: |
Verify User Who Owns YP Filesrule
To properly set the owner of $ sudo chown root /var/yp/*Rationale: |
Verify Group Who Owns YP Filesrule
To properly set the group owner of $ sudo chgrp root /var/yp/*Rationale: |
Verify Permissions on YP Filesrule
To properly set the permissions of $ sudo chmod 0755 /var/yp/*Rationale: |
Verify Extended ACLs on YP FilesruleNo extended ACLs should be applied. Rationale:Remediation script: |
Verify Permissions on Xauthority Filesrule
To properly set the permissions of $ sudo chmod 0600 .XauthorityRationale: |
Verify Extended ACLs on Xauthority FilesruleNo extended ACLs should be applied. Rationale:Remediation script: |
Verify that All World-Writable Directories Have Sticky Bits SetruleWhen the so-called 'sticky bit' is set on a directory,
only the owner of a given file may remove that file from the
directory. Without the sticky bit, any user with write access to a
directory may remove any file in the directory. Setting the sticky
bit prevents users from removing each other's files. In cases where
there is no reason for a directory to be world-writable, a better
solution is to remove that permission rather than to set the sticky
bit. However, if a directory is used by a particular application,
consult that application's documentation instead of blindly
changing modes.
# chmod +t DIRRationale:
Failing to set the sticky bit on public directories allows unauthorized users to delete files in the directory structure.
|
Ensure No World-Writable Files ExistruleIt is generally a good idea to remove global (other) write access to a file when it is discovered. However, check with documentation for specific applications before making changes. Also, monitor for recurring world-writable files, as these may be symptoms of a misconfigured application or user account. Rationale:Data in world-writable files can be modified by any user on the system. In almost all circumstances, files can be configured using a combination of user and group permissions to support whatever legitimate access is needed without the risk caused by world-writable files. Remediation script: |
Ensure All Files Are Owned by a UserruleIf any files are not owned by a user, then the cause of their lack of ownership should be investigated. Following this, the files should be deleted or assigned to an appropriate user. Rationale:Unowned files do not directly imply a security problem, but they are generally a sign that something is amiss. They may be caused by an intruder, by incorrect software installation or draft software removal, or by failure to remove all files belonging to a deleted account. The files should be repaired so they will not cause problems when accounts are created in the future, and the cause should be discovered and addressed. Remediation script: |
Ensure All Files Are Owned by a GroupruleIf any files are not owned by a group, then the cause of their lack of group-ownership should be investigated. Following this, the files should be deleted or assigned to an appropriate group. Rationale:Unowned files do not directly imply a security problem, but they are generally a sign that something is amiss. They may be caused by an intruder, by incorrect software installation or draft software removal, or by failure to remove all files belonging to a deleted account. The files should be repaired so they will not cause problems when accounts are created in the future, and the cause should be discovered and addressed. Remediation script: |
Ensure All World-Writable Directories Are Owned by a System AccountruleAll directories in local partitions which are world-writable should be owned by root or another system account. If any world-writable directories are not owned by a system account, this should be investigated. Following this, the files should be deleted or assigned to an appropriate group. Rationale:Allowing a user account to own a world-writable directory is undesirable because it allows the owner of that directory to remove or replace any files that may be placed in the directory by other users. |
Restrict Programs from Dangerous Execution PatternsgroupThe recommendations in this section are designed to ensure that the system's features to protect against potentially dangerous program execution are activated. These protections are applied at the system initialization or kernel level, and defend against certain types of badly-configured or compromised programs. |
| contains 3 rules |
Disable Core DumpsgroupA core dump file is the memory image of an executable
program when it was terminated by the operating system due to
errant behavior. In most cases, only software developers
legitimately need to access these files. The core dump files may
also contain sensitive information, or unnecessarily occupy large
amounts of disk space.
|
| contains 1 rule |
Disable Core Dumps for All UsersruleTo disable core dumps for all users, add the following line to
* hard core 0Rationale: A core dump includes a memory image taken at the time the operating system terminates an application. The memory image could contain sensitive data and is generally useful only for developers trying to debug problems. Remediation script: |
Enable ExecShieldgroupExecShield describes kernel features that provide
protection against exploitation of memory corruption errors such as buffer
overflows. These features include random placement of the stack and other
memory regions, prevention of execution in memory that should only hold data,
and special handling of text buffers. These protections are enabled by default and
controlled through |
| contains 2 rules |
Enable ExecShield and Randomized Layout of Virtual Address Spacerule
To set the runtime status of the $ sudo sysctl -w kernel.exec-shield=1If this is not the system's default value, add the following line to /etc/sysctl.conf:
kernel.exec-shield = 1To set the runtime status of the kernel.randomize_va_space kernel parameter,
run the following command:
$ sudo sysctl -w kernel.randomize_va_space=1If this is not the system's default value, add the following line to /etc/sysctl.conf:
kernel.randomize_va_space = 1Rationale: ExecShield uses the segmentation feature on all x86 systems to prevent execution in memory higher than a certain address. It writes an address as a limit in the code segment descriptor, to control where code can be executed, on a per-process basis. When the kernel places a process's memory regions such as the stack and heap higher than this address, the hardware prevents execution in that address range. Address space layout randomization (ASLR) makes it more difficult for an attacker to predict the location of attack code they have introduced into a process's address space during an attempt at exploitation. Additionally, ASLR makes it more difficult for an attacker to know the location of existing code in order to re-purpose it using return oriented programming (ROP) techniques. Remediation script: |
Enable ExecShieldrule
To set the runtime status of the $ sudo sysctl -w kernel.exec-shield=1If this is not the system's default value, add the following line to /etc/sysctl.conf:
kernel.exec-shield = 1Rationale: ExecShield uses the segmentation feature on all x86 systems to prevent execution in memory higher than a certain address. It writes an address as a limit in the code segment descriptor, to control where code can be executed, on a per-process basis. When the kernel places a process's memory regions such as the stack and heap higher than this address, the hardware prevents execution in that address range. Remediation script: |
SELinuxgroupSELinux is a feature of the Linux kernel which can be
used to guard against misconfigured or compromised programs.
SELinux enforces the idea that programs should be limited in what
files they can access and what actions they can take.
|
| contains 1 rule |
Enable SELinuxgroupEdit the file SELINUX=enforcing SELINUXTYPE=targetedEdit the file /etc/grub.conf. Ensure that the following
arguments DO NOT appear on any kernel command line in the file:
selinux=0 enforcing=0The directive SELINUX=enforcing enables SELinux at boot time.
If SELinux is suspected of involvement with boot-time problems
(unlikely), it is possible to boot into the warning-only mode
SELINUX=permissive for debugging purposes. Make certain to change
the mode back to enforcing after debugging, set the filesystems to
be relabeled for consistency using the command touch
/.autorelabel, and reboot.
However, the Red Hat Enterprise Linux 6 default SELinux configuration should be sufficiently reasonable that most systems will boot without serious problems. Some applications that require deep or unusual system privileges, such as virtual machine software, may not be compatible with SELinux in its default configuration. However, this should be uncommon, and SELinux's application support continues to improve. In other cases, SELinux may reveal unusual or insecure program behavior by design. The directive SELINUXTYPE=targeted configures SELinux to use
the default targeted policy.
The SELinux boot mode specified in /etc/selinux/config can be
overridden by command-line arguments passed to the kernel. It is
necessary to check grub.conf to ensure that this has not been done
and to protect the boot process.
|
| contains 1 rule |
Ensure SELinux State is Enforcing and Policy is TargetedruleThe SELinux state should be set to SELINUX=enforcing SELINUXTYPE=targetedRationale:
Setting the SELinux state to |
Account and Access ControlgroupIn traditional Unix security, if an attacker gains shell access to a certain login account, they can perform any action or access any file to which that account has access. Therefore, making it more difficult for unauthorized people to gain shell access to accounts, particularly to privileged accounts, is a necessary part of securing a system. This section introduces mechanisms for restricting access to accounts under Red Hat Enterprise Linux 5. |
| contains 50 rules |
Special Privileged Accounts ExistgroupThe system must not have special
privilege accounts, such as |
| contains 5 rules |
Special Privileged AccountsruleRemove any special privilege accounts,
such as If special privilege accounts are compromised, the accounts could provide privileges to execute malicious commands on a system. Remediation script: |
Ftp AccountruleRemove the 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. Remediation script: |
Games AccountruleRemove the 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. Remediation script: |
Gopher AccountruleRemove the 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. Remediation script: |
News AccountruleRemove the 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. Remediation script: |
Protect Accounts by Restricting Password-Based LogingroupConventionally, Unix shell accounts are accessed by
providing a username and password to a login program, which tests
these values for correctness using the |
| contains 12 rules |
Restrict Root Loginsgroup
Direct root logins should be allowed only for emergency use.
In normal situations, the administrator should access the system
via a unique unprivileged account, and then use |
| contains 4 rules |
Restrict Virtual Console Root Loginsrule
To restrict root logins through the (deprecated) virtual console devices,
ensure lines of this form do not appear in vc/1 vc/2 vc/3 vc/4Rationale: Preventing direct root login to virtual console devices helps ensure accountability for actions taken on the system using the root account. Remediation script: |
Restrict Web Browser Use for Administrative AccountsruleEnforce policy requiring administrative accounts use web browsers only for local service administration. Rationale:If a browser vulnerability is exploited while running with administrative privileges, the entire system could be compromised. Specific exceptions for local service administration should be documented in site-defined policy. Remediation script: |
Verify Only Root Has UID 0ruleIf any account other than root has a UID of 0, this misconfiguration should be investigated and the accounts other than root should be removed or have their UID changed. Rationale:An account has root authority if it has a UID of 0. Multiple accounts with a UID of 0 afford more opportunity for potential intruders to guess a password for a privileged account. Proper configuration of sudo is recommended to afford multiple system administrators access to root privileges in an accountable manner. Remediation script: |
Switching To Root Account Must Require Wheel MembershipruleEnsure that only members of the wheel group are allowed to switch to the root account. Rationale: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. Remediation script: |
Verify Proper Storage and Existence of Password Hashesgroup
By default, password hashes for local accounts are stored
in the second field (colon-separated) in
|
| contains 4 rules |
Prevent Log In to Accounts With Empty PasswordruleIf 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. Remove any instances of the If an account has an empty password, anyone could log in and run commands with the privileges of that account. Accounts with empty passwords should never be used in operational environments. Remediation script: |
Verify All Account Password Hashes are Shadowedrule
If any password hashes are stored in
The hashes for all user account passwords should be stored in
the file |
All GIDs referenced in /etc/passwd must be defined in /etc/groupruleAdd a group to the system for each GID referenced without a corresponding group. Rationale:
Inconsistency in GIDs between |
Verify No netrc Files ExistruleThe
Unencrypted passwords for remote FTP servers may be stored in |
Set Password Expiration ParametersgroupThe file # chage -M 180 -m 7 -W 7 USER |
| contains 2 rules |
Set Password Minimum AgeruleTo specify password minimum age for new accounts,
edit the file PASS_MIN_DAYS DAYSA value of 1 day is considered for sufficient for many environments. The DoD requirement is 1. Rationale: Setting the minimum password age protects against users cycling back to a favorite password after satisfying the password reuse requirement. Remediation script: |
Set Password Maximum AgeruleTo specify password maximum age for new accounts,
edit the file PASS_MAX_DAYS DAYSA value of 180 days is sufficient for many environments. The DoD requirement is 60. Rationale: Setting the password maximum age ensures users are required to periodically change their passwords. This could possibly decrease the utility of a stolen password. Requiring shorter password lifetimes increases the risk of users writing down the password in a convenient location subject to physical compromise. Remediation script: |
Set Account Expiration ParametersgroupAccounts can be configured to be automatically disabled
after a certain time period,
meaning that they will require administrator interaction to become usable again.
Expiration of accounts after inactivity can be set for all accounts by default
and also on a per-account basis, such as for accounts that are known to be temporary.
To configure automatic expiration of an account following
the expiration of its password (that is, after the password has expired and not been changed),
run the following command, substituting # chage -I NUM_DAYS USERAccounts, such as temporary accounts, can also be configured to expire on an explicitly-set date with the -E option.
The file /etc/default/useradd controls
default settings for all newly-created accounts created with the system's
normal command line utilities.
|
| contains 2 rules |
Set Account Expiration Following InactivityruleTo specify the number of days after a password expires (which
signifies inactivity) until an account is permanently disabled, add or correct
the following lines in INACTIVE=NUM_DAYSA value of 35 is recommended. If a password is currently on the verge of expiration, then 35 days remain until the account is automatically disabled. However, if the password will not expire for another 60 days, then 95 days could elapse until the account would be automatically disabled. See the useradd man page for more information. Determining the inactivity
timeout must be done with careful consideration of the length of a "normal"
period of inactivity for users in the particular environment. Setting
the timeout too low incurs support costs and also has the potential to impact
availability of the system to legitimate users.
Rationale:Disabling inactive accounts ensures that accounts which may not have been responsibly removed are not available to attackers who may have compromised their credentials. Remediation script: |
Ensure All Accounts on the System Have Unique NamesruleChange usernames, or delete accounts, so each has a unique name. Rationale:Unique usernames allow for accountability on the system. |
Protect Accounts by Configuring PAMgroupPAM, or Pluggable Authentication Modules, is a system
which implements modular authentication for Linux programs. PAM provides
a flexible and configurable architecture for authentication, and it should be configured
to minimize exposure to unnecessary risk. This section contains
guidance on how to accomplish that.
warning
Be careful when making changes to PAM's
configuration files. The syntax for these files is complex, and
modifications can have unexpected consequences. The default
configurations shipped with applications should be sufficient for
most users. warning
Running authconfig or
system-config-authentication will re-write the PAM configuration
files, destroying any manually made changes and replacing them with
a series of system defaults. One reference to the configuration
file syntax can be found at
http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/sag-configuration-file.html. |
| contains 13 rules |
Set Password Quality RequirementsgroupThe default |
| contains 9 rules |
Set Password Quality Requirements, if using pam_cracklibgroupThe password requisite pam_cracklib.so try_first_pass retry=3and then alter it to read: password required pam_cracklib.so try_first_pass retry=3 maxrepeat=3 minlen=14 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1 difok=4If no such line exists, add one as the first line of the password section in /etc/pam.d/system-auth.
The arguments can be modified to ensure compliance with
your organization's security policy. Discussion of each parameter follows.
warning
Note that the password quality
requirements are not enforced for the root account for some
reason. |
| contains 9 rules |
Include Cracklib Password ModuleruleTo ensure the cracklib password module is being enforced and its configuration
is not being overwritten by authconfig, the cracklib module must be defined in /etc/pam.d/system-auth.
Additionally, the /etc/pam.d/passwd file must ensure the 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. Remediation script: |
Set Password Minimum LengthruleTo specify password length requirements for new accounts,
edit the file PASS_MIN_LEN 14 The DoD requirement is 14.
The FISMA requirement is 12.
If a program consults /etc/login.defs and also another PAM module
(such as pam_cracklib) during a password change operation,
then the most restrictive must be satisfied. See PAM section
for more information about enforcing password quality requirements.
Rationale:Requiring a minimum password length makes password cracking attacks more difficult by ensuring a larger search space. However, any security benefit from an onerous requirement must be carefully weighed against usability problems, support costs, or counterproductive behavior that may result. Remediation script: |
Set Password to Maximum of Three Consecutive Repeating CharactersruleThe pam_cracklib module's Passwords with excessive repeating characters may be more vulnerable to password-guessing attacks. Remediation script: |
Set Password Strength Minimum Digit CharactersruleThe pam_cracklib module's Requiring digits makes password guessing attacks more difficult by ensuring a larger search space. Remediation script: |
Set Password Strength Minimum Uppercase CharactersruleThe pam_cracklib module's Requiring a minimum number of uppercase characters makes password guessing attacks more difficult by ensuring a larger search space. Remediation script: |
Set Password Strength Minimum Special CharactersruleThe pam_cracklib module's Requiring a minimum number of special characters makes password guessing attacks more difficult by ensuring a larger search space. Remediation script: |
Set Password Strength Minimum Lowercase CharactersruleThe pam_cracklib module's Requiring a minimum number of lowercase characters makes password guessing attacks more difficult by ensuring a larger search space. Remediation script: |
Set Password Strength Minimum Different CharactersruleThe pam_cracklib module's Requiring a minimum number of different characters during password changes ensures that newly changed passwords should not resemble previously compromised ones. Note that passwords which are changed on compromised systems will still be compromised, however. Remediation script: |
Limit Password ReuseruleDo not allow users to reuse recent passwords. This can
be accomplished by using the password sufficient pam_unix.so existing_options remember=24The DoD and FISMA requirement is 24 passwords.Rationale: Preventing re-use of previous passwords helps ensure that a compromised password is not re-used by a user. |
Set Authentication Failure ActionsgroupThe system should be configured to handle authentication failures so that password cracking attempts are mitigated. warning
Locking out user accounts presents the
risk of a denial-of-service attack. The lockout policy
must weigh whether the risk of such a
denial-of-service attack outweighs the benefits of thwarting
password guessing attacks. |
| contains 2 rules |
Set Deny For Failed Password Attemptsrule
To configure the system to lock out accounts after a number of incorrect login
attempts using auth [default=die] pam_faillock.so authfail deny=3 unlock_time=604800 fail_interval=900 auth required pam_faillock.so authsucc deny=3 unlock_time=604800 fail_interval=900Rationale: Locking out user accounts after a number of incorrect attempts prevents direct password guessing attacks. Remediation script: |
Set Delay Between Failed Password AttemptsruleCheck the value of the FAIL_DELAY variable and the ability to use it. Rationale:Enforcing a delay between successive failed login attempts increases protection against automated password guessing attacks. Remediation script: |
Set Password Hashing AlgorithmgroupThe system's default algorithm for storing password hashes in
|
| contains 1 rule |
Set Password Hashing Algorithm in /etc/pam.d/system-authrule
In password sufficient pam_unix.so sha512 other arguments...This will help ensure when local users change their passwords, hashes for the new passwords will be generated using the SHA-512 algorithm. This is the default. Rationale: Using a stronger hashing algorithm makes password cracking attacks more difficult. Remediation script: |
Configure Global Account SettingsruleThe auth include system-auth-ac account include system-auth-ac password include system-auth-ac session include system-auth-acRationale: Pam global requirements are generally defined in the /etc/pam.d/system-auth or /etc/pam.d/system-auth-ac file. In order for the requirements to be applied the file containing them must be included directly or indirectly in each program's definition file in /etc/pam.d. Remediation script: |
Secure Session Configuration Files for Login AccountsgroupWhen a user logs into a Unix account, the system configures the user's session by reading a number of files. Many of these files are located in the user's home directory, and may have weak permissions as a result of user error or misconfiguration. If an attacker can modify or even read certain types of account configuration information, they can often gain full access to the affected user's account. Therefore, it is important to test and correct configuration file permissions for interactive accounts, particularly those of privileged users such as root or system administrators. |
| contains 5 rules |
Ensure that No Dangerous Directories Exist in Root's PathgroupThe active path of the root account can be obtained by starting a new root shell and running: # echo $PATHThis will produce a colon-separated list of directories in the path. Certain path elements could be considered dangerous, as they could lead to root executing unknown or untrusted programs, which could contain malicious code. Since root may sometimes work inside untrusted directories, the . character, which represents the
current directory, should never be in the root path, nor should any
directory which can be written to by an unprivileged or
semi-privileged (system) user.
It is a good practice for administrators to always execute privileged commands by typing the full path to the command. |
| contains 3 rules |
Ensure that Root's PATH Variable Only Includes Absolute Pathsrule
Ensure that none of the directories in root's executable path is equal to a single
PATH=:/bin PATH=/bin: PATH=/bin::/sbinThese empty elements have the same effect as a single . character.
Rationale:Including these entries increases the risk that root could execute code from an untrusted location. |
Ensure that Root's LD_LIBRARY_PATH Variable Only Includes Absolute Pathsrule
Ensure that none of the directories in root's library path is equal to a single
LD_LIBRARY_PATH=:/lib LD_LIBRARY_PATH=/lib: LD_LIBRARY_PATH=/lib::/usr/libThese empty elements have the same effect as a single . character.
Rationale:Including these entries increases the risk that root could execute code from an untrusted location. |
Ensure that Root's Path Does Not Include World or Group-Writable DirectoriesruleFor each element in root's path, run: # ls -ld DIRand ensure that write permissions are disabled for group and other. Rationale: Such entries increase the risk that root could execute code provided by unprivileged users, and potentially malicious code. |
Ensure that Users Have Sensible Umask Valuesgroup
The umask setting controls the default permissions
for the creation of new files.
With a default |
| contains 1 rule |
Ensure the Default Umask is Set Correctlyrule
To ensure the default umask for users is set properly,
add or correct the umask 077Rationale: The umask value influences the permissions assigned to files when they are created. A misconfigured umask value could result in files with excessive permissions that can be read or written to by unauthorized users. Remediation script: |
Limit the Number of Concurrent Login Sessions Allowed Per Userrule
Limiting the number of allowed users and sessions per user can limit risks related to Denial of
Service attacks. This addresses concurrent sessions for a single account and does not address
concurrent sessions by a single user via multiple accounts. The DoD requirement is 10. To set the number of concurrent
sessions per user add the following line in * hard maxlogins 10Rationale: 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. Remediation script: |
Protect Physical Console AccessgroupIt is impossible to fully protect a system from an attacker with physical access, so securing the space in which the system is located should be considered a necessary step. However, there are some steps which, if taken, make it more difficult for an attacker to quickly or undetectably modify a system from its console. |
| contains 12 rules |
Set Boot Loader PasswordgroupDuring the boot process, the boot loader is responsible for starting the execution of the kernel and passing options to it. The boot loader allows for the selection of different kernels - possibly on different partitions or media. The default Red Hat Enterprise Linux boot loader for x86 systems is called GRUB. Options it can pass to the kernel include single-user mode, which provides root access without any authentication, and the ability to disable SELinux. To prevent local users from modifying the boot parameters and endangering security, protect the boot loader configuration with a password and ensure its configuration file's permissions are set properly. |
| contains 7 rules |
Verify /boot/grub/grub.conf ExistsruleThe file GRUB is a versatile boot loader used by several platforms that can provide authentication for access to the system or boot loader. |
Verify /etc/grub.conf User OwnershipruleThe file $ sudo chown root /etc/grub.confRationale: Only root should be able to modify important boot parameters. Remediation script: |
Verify /etc/grub.conf Group OwnershipruleThe file $ sudo chgrp root /etc/grub.confRationale:
The |
Verify /boot/grub/grub.conf PermissionsruleFile permissions for $ sudo chmod 600 /boot/grub/grub.confRationale: Proper permissions ensure that only the root user can modify important boot parameters. Remediation script: |
Verify /boot/grub/grub.conf Extended ACLsruleThe system's boot loader configuration file(s) must not have extended ACLs. Rationale:Proper permissions ensure that only the root user can modify important boot parameters. Remediation script: |
Set Boot Loader PasswordruleThe grub boot loader should have password protection enabled to protect boot-time settings. To do so, select a password and then generate a hash from it by running the following command: # /sbin/grub-md5-cryptWhen prompted to enter a password, insert the following line into /etc/grub.conf
immediately after the header comments. (Use the output from grub-md5-crypt as the
value of password-hash):
password --md5 password-hashNOTE: To meet FISMA Moderate, the bootloader password MUST differ from the root password. Rationale: Password protection on the boot loader configuration ensures users with physical access cannot trivially alter important bootloader settings. These include which kernel to use, and whether to enter single-user mode. Remediation script: |
Set Boot Loader Password HashruleThe grub boot loader password should be protected by being hashed with an approved hash algorithm, such as md5. To do so, select a password and then generate a hash from it by running the following command: # /sbin/grub-md5-cryptWhen prompted to enter a password, insert the following line into /etc/grub.conf
immediately after the header comments. (Use the output from grub-md5-crypt as the
value of password-hash):
password --md5 password-hashNOTE: To meet FISMA Moderate, the bootloader password MUST differ from the root password. Rationale: Password protection on the boot loader configuration ensures users with physical access cannot trivially alter important bootloader settings. These include which kernel to use, and whether to enter single-user mode. Remediation script: |
Configure Screen LockinggroupWhen a user must temporarily leave an account
logged-in, screen locking should be employed to prevent passersby
from abusing the account. User education and training is
particularly important for screen locking to be effective, and policies
can be implemented to reinforce this.
|
| contains 3 rules |
Configure GUI Screen LockinggroupIn the default GNOME desktop, the screen can be locked
by choosing Lock Screen from the System menu.
|
| contains 3 rules |
Set GNOME Login Inactivity TimeoutruleRun the following command to set the idle time-out value for inactivity in the GNOME desktop to 15 minutes: # gconftool-2 \ --direct \ --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \ --type int \ --set /apps/gnome-screensaver/idle_delay 15Rationale: Setting the idle delay controls when the screensaver will start, and can be combined with screen locking to prevent access from passersby. Remediation script: |
GNOME Desktop Screensaver Mandatory UseruleRun the following command to activate the screensaver in the GNOME desktop after a period of inactivity: # gconftool-2 --direct \ --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \ --type bool \ --set /apps/gnome-screensaver/idle_activation_enabled trueRationale: Enabling idle activation of the screen saver ensures the screensaver will be activated after the idle delay. Applications requiring continuous, real-time screen display (such as network management products) require the login session does not have administrator rights and the display station is located in a controlled-access area. Remediation script: |
Enable Screen Lock Activation After Idle PeriodruleRun the following command to activate locking of the screensaver in the GNOME desktop when it is activated: # gconftool-2 --direct \ --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \ --type bool \ --set /apps/gnome-screensaver/lock_enabled trueRationale: Enabling the activation of the screen lock after an idle period ensures password entry will be required in order to access the system, preventing access by passersby. Remediation script: |
Require Authentication for Single User ModeruleSingle-user mode is intended as a system recovery
method, providing a single user root access to the system by
providing a boot option at startup. By default, no authentication
is performed if single-user mode is selected.
~:S:wait:/sbin/suloginRationale: This prevents attackers with physical access from trivially bypassing security on the machine and gaining root access. Such accesses are further prevented by configuring the bootloader password. Remediation script: |
Disable Ctrl-Alt-Del Reboot Activationrule
By default, the system includes the following line in
exec /sbin/shutdown -r now "Control-Alt-Delete pressed" To configure the system to log a message instead of rebooting the system, alter that line to read as follows: exec /usr/bin/logger -p security.info "Control-Alt-Delete pressed"Rationale: A locally logged-in user who presses Ctrl-Alt-Del, when at the console, can reboot the system. If accidentally pressed, as could happen in the case of mixed OS environment, this can create the risk of short-term loss of availability of systems due to unintentional reboot. In the GNOME graphical environment, risk of unintentional reboot from the Ctrl-Alt-Del sequence is reduced because the user will be prompted before any action is taken. Remediation script: |
Warning Banners for System AccessesgroupEach system should expose as little information about
itself as possible.
|
| contains 3 rules |
Implement a GUI Warning BannergroupIn the default graphical environment, users logging directly into the system are greeted with a login screen provided by the GNOME Display Manager (GDM). The warning banner should be displayed in this graphical environment for these users. The following sections describe how to configure the GDM login banner. |
| contains 1 rule |
Enable GUI Warning Banner With Proper TextruleTo enable displaying a login warning banner in the GNOME Display Manager's login screen, run the following command: sudo -u gdm gconftool-2 \ --type bool \ --set /apps/gdm/simple-greeter/banner_message_enable trueTo set the text shown by the GNOME Display Manager in the login screen, run the following command: sudo -u gdm gconftool-2 \ --type string \ --set /apps/gdm/simple-greeter/banner_message_text \ "Text of the warning banner here"When entering a warning banner that spans several lines, remember to begin and end the string with ". This command writes
directly to the file /var/lib/gdm/.gconf/apps/gdm/simple-greeter/%gconf.xml,
and this file can later be edited directly if necessary.
Rationale:An appropriate warning message reinforces policy awareness during the logon process and facilitates possible legal action against attackers. Remediation script: |
Modify the System Login Bannerrule
To configure the system login banner:
An appropriate warning message reinforces policy awareness during the logon process and facilitates possible legal action against attackers. Remediation script: |
Create Warning Banners for All FTP UsersruleEdit the vsftpd configuration file, which resides at banner_file=/etc/issueRationale: This setting will cause the system greeting banner to be used for FTP connections as well. Remediation script: |
Network Configuration and FirewallsgroupMost machines must be connected to a network of some
sort, and this brings with it the substantial risk of network
attack. This section discusses the security impact of decisions
about networking which must be made when configuring a system.
|
| contains 29 rules |
Kernel Parameters Which Affect NetworkinggroupThe |
| contains 8 rules |
Network Parameters for Hosts OnlygroupIf the system is not going to be used as a router, then setting certain kernel parameters ensure that the host will not perform routing of network traffic. |
| contains 2 rules |
Disable Kernel Parameter for Sending ICMP Redirects for All Interfacesrule
To set the runtime status of the $ sudo sysctl -w net.ipv4.conf.all.send_redirects=0If this is not the system's default value, add the following line to /etc/sysctl.conf:
net.ipv4.conf.all.send_redirects = 0Rationale: Sending ICMP redirects permits the system to instruct other systems to update their routing information. The ability to send ICMP redirects is only appropriate for systems acting as routers. Remediation script: |
Disable Kernel Parameter for IP Forwardingrule
To set the runtime status of the $ sudo sysctl -w net.ipv4.ip_forward=0If this is not the system's default value, add the following line to /etc/sysctl.conf:
net.ipv4.ip_forward = 0Rationale: IP forwarding permits the kernel to forward packets from one network interface to another. The ability to forward packets between two networks is only appropriate for systems acting as routers. Remediation script: |
Network Related Kernel Runtime Parameters for Hosts and RoutersgroupCertain kernel parameters should be set for systems which are acting as either hosts or routers to improve the system's ability defend against certain types of IPv4 protocol attacks. |
| contains 6 rules |
Disable Kernel Parameter for Accepting Source-Routed Packets for All Interfacesrule
To set the runtime status of the $ sudo sysctl -w net.ipv4.conf.all.accept_source_route=0If this is not the system's default value, add the following line to /etc/sysctl.conf:
net.ipv4.conf.all.accept_source_route = 0Rationale: Accepting source-routed packets in the IPv4 protocol has few legitimate uses. It should be disabled unless it is absolutely required. Remediation script: |
Disable Kernel Parameter for Accepting ICMP Redirects for All Interfacesrule
To set the runtime status of the $ sudo sysctl -w net.ipv4.conf.all.accept_redirects=0If this is not the system's default value, add the following line to /etc/sysctl.conf:
net.ipv4.conf.all.accept_redirects = 0Rationale: Accepting ICMP redirects has few legitimate uses. It should be disabled unless it is absolutely required. Remediation script: |
Enable Kernel Parameter to Log Martian Packetsrule
To set the runtime status of the $ sudo sysctl -w net.ipv4.conf.all.log_martians=1If this is not the system's default value, add the following line to /etc/sysctl.conf:
net.ipv4.conf.all.log_martians = 1Rationale: The presence of "martian" packets (which have impossible addresses) as well as spoofed packets, source-routed packets, and redirects could be a sign of nefarious network activity. Logging these packets enables this activity to be detected. Remediation script: |
Enable Kernel Parameter to Ignore ICMP Broadcast Echo Requestsrule
To set the runtime status of the $ sudo sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=1If this is not the system's default value, add the following line to /etc/sysctl.conf:
net.ipv4.icmp_echo_ignore_broadcasts = 1Rationale: Ignoring ICMP echo requests (pings) sent to broadcast or multicast addresses makes the system slightly more difficult to enumerate on the network. Remediation script: |
Enable Kernel Parameter to Use TCP Syncookiesrule
To set the runtime status of the $ sudo sysctl -w net.ipv4.tcp_syncookies=1If this is not the system's default value, add the following line to /etc/sysctl.conf:
net.ipv4.tcp_syncookies = 1Rationale: A TCP SYN flood attack can cause a denial of service by filling a system's TCP connection table with connections in the SYN_RCVD state. Syncookies can be used to track a connection when a subsequent ACK is received, verifying the initiator is attempting a valid connection and is not a flood source. This feature is activated when a flood condition is detected, and enables the system to continue servicing valid connection requests. Remediation script: |
TCP backlog queue sizes must be set appropriatelyrule
To set the runtime status of the $ sudo sysctl -w net.ipv4.max_syn_backlog=1280If this is not the system's default value, add the following line to /etc/sysctl.conf:
net.ipv4.max_syn_backlog = 1280Rationale: 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. identifiers: GEN003601 references: ECSC-1, http://iase.disa.mil/stigs/cci/Pages/index.aspx |
Wireless NetworkinggroupWireless networking, such as 802.11
(WiFi) and Bluetooth, can present a security risk to sensitive or
classified systems and networks. Wireless networking hardware is
much more likely to be included in laptop or portable systems than
desktops or servers.
|
| contains 1 rule |
Disable Wireless Through Software ConfigurationgroupIf it is impossible to remove the wireless hardware from the device in question, disable as much of it as possible through software. The following methods can disable software support for wireless networking, but note that these methods do not prevent malicious software or careless users from re-activating the devices. |
| contains 1 rule |
Disable Bluetooth Kernel ModulesruleThe kernel's module loading system can be configured to prevent
loading of the Bluetooth module. Add the following to
the appropriate install net-pf-31 /bin/true install bluetooth /bin/trueRationale: If Bluetooth functionality must be disabled, preventing the kernel from loading the kernel module provides an additional safeguard against its activation. Remediation script: |
IPv6groupThe system includes support for Internet Protocol version 6. A major and often-mentioned improvement over IPv4 is its enormous increase in the number of available addresses. Another important feature is its support for automatic configuration of many network settings. |
| contains 5 rules |
Disable Support for IPv6 Unless NeededgroupDespite configuration that suggests support for IPv6 has been disabled, link-local IPv6 address auto-configuration occurs even when only an IPv4 address is assigned. The only way to effectively prevent execution of the IPv6 networking stack is to instruct the system not to activate the IPv6 kernel module. |
| contains 2 rules |
Disable IPv6 Networking Support Automatic LoadingruleTo prevent the IPv6 kernel module ( options ipv6 disable=1This permits the IPv6 module to be loaded (and thus satisfy other modules that depend on it), while disabling support for the IPv6 protocol. Rationale: Any unnecessary network stacks - including IPv6 - should be disabled, to reduce the vulnerability to exploitation. Remediation script: |
Disable Interface Usage of IPv6ruleTo disable interface usage of IPv6, add or correct the following lines in NETWORKING_IPV6=noRemediation script: |
Configure IPv6 Settings if NecessarygroupA major feature of IPv6 is the extent to which systems implementing it can automatically configure their networking devices using information from the network. From a security perspective, manually configuring important configuration information is preferable to accepting it from the network in an unauthenticated fashion. |
| contains 3 rules |
Disable Automatic ConfigurationgroupDisable the system's acceptance of router
advertisements and redirects by adding or correcting the following
line in IPV6_AUTOCONF=no |
| contains 2 rules |
Disable Accepting IPv6 Redirectsrule
To set the runtime status of the $ sudo sysctl -w net.ipv6.conf.all.accept_redirects=0If this is not the system's default value, add the following line to /etc/sysctl.conf:
net.ipv6.conf.all.accept_redirects = 0Rationale: An illicit ICMP redirect message could result in a man-in-the-middle attack. Remediation script: |
Disable Accepting IPv6 Forwardingrule
To set the runtime status of the $ sudo sysctl -w net.ipv6.conf.all.forwarding=0If this is not the system's default value, add the following line to /etc/sysctl.conf:
net.ipv6.conf.all.forwarding = 0To set the runtime status of the net.ipv6.conf.default.forwarding kernel parameter,
run the following command:
$ sudo sysctl -w net.ipv6.conf.default.forwarding=0If this is not the system's default value, add the following line to /etc/sysctl.conf:
net.ipv6.conf.default.forwarding = 0Rationale: Source-routed packets allow the source of the packet to suggest that 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 IPv6 forwarding is enabled and the system is functioning as a router. Remediation script: |
Manually Assign IPv6 Router AddressruleEdit the file
IPV6_DEFAULTGW=2001:0DB8::0001Router addresses should be manually set and not accepted via any auto-configuration or router advertisement. |
iptables and ip6tablesgroupA host-based firewall called Netfilter is included as
part of the Linux kernel distributed with the system. It is
activated by default. This firewall is controlled by the program
iptables, and the entire capability is frequently referred to by
this name. An analogous program called ip6tables handles filtering
for IPv6.
|
| contains 5 rules |
Inspect and Activate Default RulesgroupView the currently-enforced iptables rules by running the command: # iptables -nL --line-numbersThe command is analogous for the ip6tables program. If the firewall does not appear to be active (i.e., no rules appear), activate it and ensure that it starts at boot by issuing the following commands (and analogously for ip6tables): # service iptables restartThe default iptables rules are: Chain INPUT (policy ACCEPT) num target prot opt source destination 1 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 2 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 3 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 4 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22 5 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited Chain FORWARD (policy ACCEPT) num target prot opt source destination 1 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited Chain OUTPUT (policy ACCEPT) num target prot opt source destinationThe ip6tables default rules are essentially the same. |
| contains 1 rule |
Verify iptables Enabledrule
The $ sudo chkconfig --level 2345 iptables onRationale:
The |
Strengthen the Default RulesetgroupThe default rules can be strengthened. The system
scripts that activate the firewall rules expect them to be defined
in the configuration files iptables and ip6tables in the directory
warning
The program system-config-securitylevel
allows additional services to penetrate the default firewall rules
and automatically adjusts /etc/sysconfig/iptables. This program
is only useful if the default ruleset meets your security
requirements. Otherwise, this program should not be used to make
changes to the firewall configuration because it re-writes the
saved configuration file. |
| contains 4 rules |
Reject Incoming Timestamp Requests and RepliesruleTo reject incoming timestamp requests and replies,
add or correct the following line in
-I INPUT -p icmp -m icmp --icmp-type timestamp-request -j DROP -I INPUT -p icmp -m icmp --icmp-type timestamp-reply -j DROPRationale: The processing of (ICMP) timestamp requests increases the attack surface of the system. Remediation script: |
Add Reject Rule for INPUT Chain.ruleTo set the default policy to DROP (instead of ACCEPT) for
the built-in INPUT chain which processes incoming packets,
add or correct the following line in
:INPUT DROP [0:0]Rationale: In |
Ignore ICMPv6 Echo Requests On a Broadcast Address.ruleTo configure the system to ignore ICMPv6 echo requests
on a broadcast address, add or correct the following line in
-A INPUT -p icmpv6 -d ff02::1 --icmpv6-type 128 -j DROPRationale: Responding to broadcast ICMP echo requests facilitates network mapping and provides a vector for amplification attacks. Remediation script: |
TCP Wrappers Must Be Configured To Grant/Deny Access To Hosts.ruleTo configure the system to grant/deny access to hosts, ensure
the following file exists:
ALL: ALLRationale: 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. Remediation script: |
IP Tunnelling SupportgroupSupport for creating IP encapsulated tunnels between a system and remote endpoints, to also include tunnelling ipv6 over ipv4, is available in Red Hat. |
| contains 3 rules |
Remove IP TunnelsruleTo remove IP tunnels, perform the following command for each IP tunnel: # ip tun del
Remediation script: |
Remove 6to4 IP TunnelsruleTo remove 6to4 IP tunnels, perform the following command for each IP tunnel: # ip tun del
Remediation script: |
Disable Teredo ServicesruleTo disable teredo services, perform the following command: # ps ax | grep -i miredo | grep -v grep | awk ' { print $1 }' | xargs kill
Remediation script: |
Uncommon Network ProtocolsgroupThe system includes support for several network protocols which are not commonly used. Although security vulnerabilities in kernel networking code are not frequently discovered, the consequences can be dramatic. Ensuring uncommon network protocols are disabled reduces the system's risk to attacks targeted at its implementation of those protocols. warning
Although these protocols are not commonly used, avoid disruption
in your network environment by ensuring they are not needed
prior to disabling them.
|
| contains 7 rules |
Disable DCCP Supportrule
The Datagram Congestion Control Protocol (DCCP) is a
relatively new transport layer protocol, designed to support
streaming media and telephony.
To configure the system to prevent the install dccp /bin/trueRationale: Disabling DCCP protects the system against exploitation of any flaws in its implementation. Remediation script: |
Disable SCTP Supportrule
The Stream Control Transmission Protocol (SCTP) is a
transport layer protocol, designed to support the idea of
message-oriented communication, with several streams of messages
within one connection.
To configure the system to prevent the install sctp /bin/trueRationale: Disabling SCTP protects the system against exploitation of any flaws in its implementation. Remediation script: |
Disable RDS Supportrule
The Reliable Datagram Sockets (RDS) protocol is a transport
layer protocol designed to provide reliable high- bandwidth,
low-latency communications between nodes in a cluster.
To configure the system to prevent the install rds /bin/trueRationale: Disabling RDS protects the system against exploitation of any flaws in its implementation. Remediation script: |
Disable TIPC Supportrule
The Transparent Inter-Process Communication (TIPC) protocol
is designed to provide communications between nodes in a
cluster.
To configure the system to prevent the install tipc /bin/trueRationale: Disabling TIPC protects the system against exploitation of any flaws in its implementation. Remediation script: |
Disable AppleTalk Supportrule
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.
To configure the system to prevent the install appletalk /bin/trueRationale: Disabling AppleTalk protects the system against exploitation of any flaws in its implementation. Remediation script: |
Disable Network Bridging Supportrule
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.
To configure the system to prevent the install bridge /bin/trueRationale: Disabling network bridging protects the system against exploitation of any flaws in its implementation. Remediation script: |
Disable IEEE1394 (Firewire) Supportrule
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.
To configure the system to prevent the install ieee1394 /bin/trueRationale: Disabling IEEE1394 (Firewire) protects the system against exploitation of any flaws in its implementation. Remediation script: |
Configure SysloggroupThe syslog service has been the default Unix logging mechanism for many years. It has a number of downsides, including inconsistent log format, lack of authentication for received messages, and lack of authentication, encryption, or reliable transport for messages sent over a network. However, due to its long history, syslog is a de facto standard which is supported by almost all Unix applications. |
| contains 3 rules |
| contains 1 rule |
Ensure Logs Sent To Remote Hostrule
To configure syslog to send logs to a remote log server,
open *.* @loghost.example.com To use TCP for log message delivery: *.* @@loghost.example.com To use RELP for log message delivery: *.* :omrelp:loghost.example.comRationale: A log server (loghost) receives syslog messages from one or more systems. This data can be used as an additional log source in the event a system is compromised and its local logs are suspect. Forwarding log messages to a remote loghost also provides system administrators with a centralized place to view the status of multiple hosts within the enterprise. |
| contains 1 rule |
Ensure syslog Does Not Accept Remote Messages Unless Acting As Log ServerruleThe $ModLoad imtcp.so $InputTCPServerRun port $ModLoad imudp.so $InputUDPServerRun port $ModLoad imrelp.so $InputRELPServerRun portRationale: Any process which receives messages from the network incurs some risk of receiving malicious messages. This risk can be eliminated for syslog by configuring it not to listen on the network. |
Ensure All Logs are Rotated by logrotategroupEdit the file /var/log/messages /var/log/secure /var/log/maillog /var/log/spooler \
/var/log/boot.log /var/log/cron {
Edit this line so that it contains a one-space-separated
listing of each log file referenced in /etc/syslog.conf.
All logs in use on a system must be rotated regularly, or the log files will consume disk space over time, eventually interfering with system operation. The file /etc/logrotate.d/syslog is the
configuration file used by the logrotate program to maintain all
log files written by syslog. By default, it rotates logs weekly and
stores four archival copies of each log. These settings can be
modified by editing /etc/logrotate.conf, but the defaults are
sufficient for purposes of this guide.
Note that logrotate is run nightly by the cron job
/etc/cron.daily/logrotate. If particularly active logs need to be
rotated more often than once a day, some other mechanism must be
used. |
| contains 1 rule |
Ensure Logrotate Runs PeriodicallyruleThe # rotate log files frequency dailyRationale: Log files that are not properly rotated run the risk of growing so large that they fill up the /var/log partition. Valuable logging information could be lost if the /var/log partition becomes full. |
System Accounting with auditdgroupThe audit service provides substantial capabilities
for recording system activities. By default, the service audits about
SELinux AVC denials and certain types of security-relevant events
such as system logins, account modifications, and authentication
events performed by programs such as sudo.
Under its default configuration, type=AVC msg=audit(1226874073.147:96): avc: denied { getattr } for pid=2465 comm="httpd"
path="/var/www/html/file1" dev=dm-0 ino=284133 scontext=unconfined_u:system_r:httpd_t:s0
tcontext=unconfined_u:object_r:samba_share_t:s0 tclass=file
type=SYSCALL msg=audit(1226874073.147:96): arch=40000003 syscall=196 success=no exit=-13
a0=b98df198 a1=bfec85dc a2=54dff4 a3=2008171 items=0 ppid=2463 pid=2465 auid=502 uid=48
gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=6 comm="httpd"
exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)
|
| contains 40 rules |
Configure auditd Data Retentiongroup
The audit system writes data to |
| contains 3 rules |
Configure auditd space_left Action on Low Disk SpaceruleThe space_left_action = ACTIONPossible values for ACTION are described in the auditd.conf man page.
These include:
email (instead of the default,
which is suspend) as it is more likely to get prompt attention. Acceptable values
also include suspend, single, and halt.
Rationale:Notifying administrators of an impending disk space problem may allow them to take corrective action prior to any disruption. Remediation script: |
Configure auditd disk_error_action and disk_full_action on Storage FailuresruleThe disk_error_action = ACTION disk_full_action = ACTIONSet this value to single to cause the system to switch to single user
mode for corrective action. Acceptable values also include syslog, exec, and
halt. For certain systems, the need for availability
outweighs the need to log all actions, and a different setting should be
determined. Details regarding all possible values for ACTION are described in the
auditd.conf man page.
Rationale:Administrators should be made aware of an inability to write to disk. Remediation script: |
Configure auditd to use audispd's syslog pluginruleTo configure the # service auditd restartRationale: The auditd service does not include the ability to send audit records to a centralized server for management directly. It does, however, include a plug-in for audit event multiplexor (audispd) to pass audit records to the local syslog server Remediation script: |
Configure auditd Rules for Comprehensive AuditinggroupThe
Auditing rules at startup are controlled by the file /etc/audit/audit.rules.
Add rules to it to meet the auditing requirements for your organization.
Each line in /etc/audit/audit.rules represents a series of arguments
that can be passed to auditctl and can be individually tested
during runtime. See documentation in /usr/share/doc/audit-VERSION and
in the related man pages for more details.
If copying any example audit rulesets from /usr/share/doc/audit-VERSION,
be sure to comment out the
lines containing arch= which are not appropriate for your system's
architecture. Then review and understand the following rules,
ensuring rules are activated as needed for the appropriate
architecture.
After reviewing all the rules, reading the following sections, and editing as needed, the new rules can be activated as follows: # service auditd restart |
| contains 35 rules |
Records Events that Modify Date and Time InformationgroupArbitrary changes to the system time can be used to obfuscate nefarious activities in log files, as well as to confuse network services that are highly dependent upon an accurate system time. All changes to the system time should be audited. |
| contains 4 rules |
Record attempts to alter time through adjtimexruleOn a 32-bit system, add the following to # audit_time_rules -a exit,always -F arch=b32 -S adjtimex -k audit_time_rulesOn a 64-bit system, add the following to /etc/audit/audit.rules:
# audit_time_rules -a exit,always -F arch=b64 -S adjtimex -k audit_time_rulesThe -k option allows for the specification of a key in string form that can be used for better reporting capability through ausearch and aureport. Multiple system calls can be defined on the same line to save space if desired, but is not required. See an example of multiple combined syscalls: -a exit,always -F arch=b64 -S adjtimex -S settimeofday -k audit_time_rulesRationale: Arbitrary changes to the system time can be used to obfuscate nefarious activities in log files, as well as to confuse network services that are highly dependent upon an accurate system time (such as sshd). All changes to the system time should be audited. Remediation script: |
Record attempts to alter time through settimeofdayruleOn a 32-bit system, add the following to # audit_time_rules -a exit,always -F arch=b32 -S settimeofday -k audit_time_rulesOn a 64-bit system, add the following to /etc/audit/audit.rules:
# audit_time_rules -a exit,always -F arch=b64 -S settimeofday -k audit_time_rulesThe -k option allows for the specification of a key in string form that can be used for better reporting capability through ausearch and aureport. Multiple system calls can be defined on the same line to save space if desired, but is not required. See an example of multiple combined syscalls: -a exit,always -F arch=b64 -S adjtimex -S settimeofday -k audit_time_rulesRationale: Arbitrary changes to the system time can be used to obfuscate nefarious activities in log files, as well as to confuse network services that are highly dependent upon an accurate system time (such as sshd). All changes to the system time should be audited. Remediation script: |
Record Attempts to Alter Time Through stimeruleAdd the following line to # audit_time_rules -a always,exit -F arch=b32 -S stime -k audit_time_rulesSince the 64-bit version of the "stime" system call is not defined in the audit lookup table, the corresponding "-F arch=b64" form of this rule is not expected to be defined on 64-bit systems (the aforementioned "-F arch=b32" stime rule form itself is sufficient for both 32-bit and 64-bit systems). The -k option allows for the specification of a key in string form that can be used for better reporting capability through ausearch and aureport. Multiple system calls can be defined on the same line to save space if desired, but is not required. See an example of multiple combined syscalls: -a always,exit -F arch=b64 -S adjtimex -S settimeofday -k audit_time_rulesRationale: Arbitrary changes to the system time can be used to obfuscate nefarious activities in log files, as well as to confuse network services that are highly dependent upon an accurate system time (such as sshd). All changes to the system time should be audited. Remediation script: |
Record Attempts to Alter Time Through clock_settimeruleOn a 32-bit system, add the following to # time-change -a always,exit -F arch=b32 -S clock_settime -F a0=0x0 -F key=time-changeOn a 64-bit system, add the following to /etc/audit/audit.rules:
# time-change -a always,exit -F arch=b64 -S clock_settime -F a0=0x0 -F key=time-changeThe -k option allows for the specification of a key in string form that can be used for better reporting capability through ausearch and aureport. Multiple system calls can be defined on the same line to save space if desired, but is not required. See an example of multiple combined syscalls: -a exit,always -F arch=b64 -S adjtimex -S settimeofday -k audit_time_rulesRationale: Arbitrary changes to the system time can be used to obfuscate nefarious activities in log files, as well as to confuse network services that are highly dependent upon an accurate system time (such as sshd). All changes to the system time should be audited. |
Record Events that Modify the System's Discretionary Access ControlsgroupAt a minimum the audit system should collect file permission
changes for all users and root. Note that the "-F arch=b32" lines should be
present even on a 64 bit system. These commands identify system calls for
auditing. Even if the system is 64 bit it can still execute 32 bit system
calls. Additionally, these rules can be configured in a number of ways while
still achieving the desired effect. An example of this is that the "-S" calls
could be split up and placed on separate lines, however, this is less efficient.
Add the following to -a exit,always -F arch=b32 -S chmod -S fchmod -S fchmodat -F auid>=500 -F auid!=4294967295 -k perm_mod
-a exit,always -F arch=b32 -S chown -S fchown -S fchownat -S lchown -F auid>=500 -F auid!=4294967295 -k perm_mod
-a exit,always -F arch=b32 -S setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr -F auid>=500 -F auid!=4294967295 -k perm_mod
If your system is 64 bit then these lines should be duplicated and the
arch=b32 replaced with arch=b64 as follows:
-a exit,always -F arch=b64 -S chmod -S fchmod -S fchmodat -F auid>=500 -F auid!=4294967295 -k perm_mod
-a exit,always -F arch=b64 -S chown -S fchown -S fchownat -S lchown -F auid>=500 -F auid!=4294967295 -k perm_mod
-a exit,always -F arch=b64 -S setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr -F auid>=500 -F auid!=4294967295 -k perm_mod
|
| contains 13 rules |
Record Events that Modify the System's Discretionary Access Controls - chmodruleAt a minimum the audit system should collect file
permission changes for all users and root. Add the following to
-a exit,always -F arch=b32 -S chmod -F auid>=500 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following: -a exit,always -F arch=b64 -S chmod -F auid>=500 -F auid!=4294967295 -k perm_mod warning
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. Remediation script: |
Record Events that Modify the System's Discretionary Access Controls - chownruleAt a minimum the audit system should collect file
permission changes for all users and root. Add the following to
-a exit,always -F arch=b32 -S chown -F auid>=500 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following: -a exit,always -F arch=b64 -S chown -F auid>=500 -F auid!=4294967295 -k perm_mod warning
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. Remediation script: |
Record Events that Modify the System's Discretionary Access Controls - fchmodruleAt a minimum the audit system should collect file
permission changes for all users and root. Add the following to
-a exit,always -F arch=b32 -S fchmod -F auid>=500 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following: -a exit,always -F arch=b64 -S fchmod -F auid>=500 -F auid!=4294967295 -k perm_mod warning
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. Remediation script: |
Record Events that Modify the System's Discretionary Access Controls - fchmodatruleAt a minimum the audit system should collect file
permission changes for all users and root. Add the following to
-a exit,always -F arch=b32 -S fchmodat -F auid>=500 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following: -a exit,always -F arch=b64 -S fchmodat -F auid>=500 -F auid!=4294967295 -k perm_mod warning
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. Remediation script: |
Record Events that Modify the System's Discretionary Access Controls - fchownruleAt a minimum the audit system should collect file
permission changes for all users and root. Add the following to
-a exit,always -F arch=b32 -S fchown -F auid>=500 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following: -a exit,always -F arch=b64 -S fchown -F auid>=500 -F auid!=4294967295 -k perm_mod warning
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. Remediation script: |
Record Events that Modify the System's Discretionary Access Controls - fchownatruleAt a minimum the audit system should collect file
permission changes for all users and root. Add the following to
-a exit,always -F arch=b32 -S fchownat -F auid>=500 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following: -a exit,always -F arch=b64 -S fchownat -F auid>=500 -F auid!=4294967295 -k perm_mod warning
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. Remediation script: |
Record Events that Modify the System's Discretionary Access Controls - fremovexattrruleAt a minimum the audit system should collect file
permission changes for all users and root. Add the following to
-a exit,always -F arch=b32 -S fremovexattr -F auid>=500 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following: -a exit,always -F arch=b64 -S fremovexattr -F auid>=500 -F auid!=4294967295 -k perm_mod warning
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. Remediation script: |
Record Events that Modify the System's Discretionary Access Controls - fsetxattrruleAt a minimum the audit system should collect file
permission changes for all users and root. Add the following to
-a exit,always -F arch=b32 -S fsetxattr -F auid>=500 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following: -a exit,always -F arch=b64 -S fsetxattr -F auid>=500 -F auid!=4294967295 -k perm_mod warning
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. Remediation script: |
Record Events that Modify the System's Discretionary Access Controls - lchownruleAt a minimum the audit system should collect file
permission changes for all users and root. Add the following to
-a exit,always -F arch=b32 -S lchown -F auid>=500 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following: -a exit,always -F arch=b64 -S lchown -F auid>=500 -F auid!=4294967295 -k perm_mod warning
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. Remediation script: |
Record Events that Modify the System's Discretionary Access Controls - lremovexattrruleAt a minimum the audit system should collect file
permission changes for all users and root. Add the following to
-a exit,always -F arch=b32 -S lremovexattr -F auid>=500 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following: -a exit,always -F arch=b64 -S lremovexattr -F auid>=500 -F auid!=4294967295 -k perm_mod warning
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. Remediation script: |
Record Events that Modify the System's Discretionary Access Controls - lsetxattrruleAt a minimum the audit system should collect file
permission changes for all users and root. Add the following to
-a exit,always -F arch=b32 -S lsetxattr -F auid>=500 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following: -a exit,always -F arch=b64 -S lsetxattr -F auid>=500 -F auid!=4294967295 -k perm_mod warning
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. identifiers: GEN002820-9 references: ECAR-1, ECAR-2, ECAR-3, http://iase.disa.mil/stigs/cci/Pages/index.aspx |
Record Events that Modify the System's Discretionary Access Controls - removexattrruleAt a minimum the audit system should collect file
permission changes for all users and root. Add the following to
-a exit,always -F arch=b32 -S removexattr -F auid>=500 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following: -a exit,always -F arch=b64 -S removexattr -F auid>=500 -F auid!=4294967295 -k perm_mod warning
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. Remediation script: |
Record Events that Modify the System's Discretionary Access Controls - setxattrruleAt a minimum the audit system should collect file
permission changes for all users and root. Add the following to
-a exit,always -F arch=b32 -S setxattr -F auid>=500 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following: -a exit,always -F arch=b64 -S setxattr -F auid>=500 -F auid!=4294967295 -k perm_mod warning
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. Remediation script: |
Record Events that Create User/Group InformationruleAdd the following to # audit_account_creation -w /usr/sbin/groupadd -p x -k audit_account_changes -w /usr/sbin/useradd -p x -k audit_account_changes -w /etc/group -p a -k audit_account_changes -w /etc/passwd -p a -k audit_account_changes -w /etc/gshadow -p a -k audit_account_changes -w /etc/shadow -p a -k audit_account_changesRationale: In addition to auditing new user and group accounts, these watches will alert the system administrator(s) to any modifications. Any unexpected users, groups, or modifications should be investigated for legitimacy. Remediation script: |
Record Events that Disable User AccountsruleAdd the following to # audit_account_disabling -w /usr/bin/passwd -p x -k audit_account_disablingRationale: In addition to auditing new user and group accounts, these watches will alert the system administrator(s) to any modifications. Any unexpected users, groups, or modifications should be investigated for legitimacy. Remediation script: |
Record Events that Modify User/Group InformationruleAdd the following to # audit_account_changes -w /usr/sbin/groupmod -p x -k audit_account_changes -w /usr/sbin/usermod -p x -k audit_account_changes -w /etc/group -p w -k audit_account_changes -w /etc/passwd -p w -k audit_account_changes -w /etc/gshadow -p w -k audit_account_changes -w /etc/shadow -p w -k audit_account_changesRationale: In addition to auditing new user and group accounts, these watches will alert the system administrator(s) to any modifications. Any unexpected users, groups, or modifications should be investigated for legitimacy. Remediation script: |
Record Events that Terminate Users/GroupsruleAdd the following to # audit_account_termination -w /usr/sbin/groupdel -p x -k audit_account_termination -w /usr/sbin/userdel -p x -k audit_account_terminationRationale: In addition to auditing new user and group accounts, these watches will alert the system administrator(s) to any modifications. Any unexpected users, groups, or modifications should be investigated for legitimacy. Remediation script: |
Record Events that Modify the System's Host NameruleAdd the following to # audit_network_sethostname -a exit,always -F arch=ARCH -S sethostname -k audit_network_modificationsRationale: The network environment should not be modified by anything other than administrator action. Any change to network parameters should be audited. Remediation script: |
Record Events that Modify the System's Domain NameruleAdd the following to # audit_network_setdomainname -a exit,always -F arch=ARCH -S setdomainname -k audit_network_modificationsRationale: The network environment should not be modified by anything other than administrator action. Any change to network parameters should be audited. Remediation script: |
Record Events that Modify the System's Scheduler ParametersruleAdd the following to # audit_network_sethostname -a exit,always -F arch=ARCH -S sched_setparam -k schedulerRationale: The scheduler parameters should not be modified by anything other than administrator action. Any change to network parameters should be audited. Remediation script: |
Record Events that Modify the System's Scheduler PrioritiesruleAdd the following to # audit_network_sethostname -a exit,always -F arch=ARCH -S sched_setscheduler -k schedulerRationale: The scheduler priorities should not be modified by anything other than administrator action. Any change to network parameters should be audited. Remediation script: |
Record Attempts to Alter Logon and Logout Eventsrule
The audit system already collects login info for all users and root. To watch for attempted manual edits of
files involved in storing logon events, add the following to -w /var/log/faillog -p wa -k logins -w /var/log/lastlog -p wa -k loginsRationale: Manual editing of these files may indicate nefarious activity, such as an attacker attempting to remove evidence of an intrusion. Remediation script: |
Record Attempts to Alter Audit Rulesrule
To watch for attempted manual edits of audit rules, add the following to -w /etc/audit/audit.rules -p w -k audit_rulesRationale: Manual editing of audit rules may indicate nefarious activity, such as an attacker attempting to remove evidence of an intrusion. Remediation script: |
Ensure auditd Collects Unauthorized Access Attempts to Files (unsuccessful) Via creatruleAt a minimum the audit system should collect
unauthorized file accesses for all users and root. Add the following
to -a exit,always -F arch=ARCH -S creat -F success=0 -k accessor -a exit,always -F arch=ARCH -S creat -F exit=-EPERM -k access -a exit,always -F arch=ARCH -S creat -F exit=-EACCES -k accessRationale: Unsuccessful attempts to access files could be an indicator of malicious activity on a system. Auditing these events could serve as evidence of potential system compromise. Remediation script: |
Ensure auditd Collects Unauthorized Access Attempts to Files (unsuccessful) Via ftruncateruleAt a minimum the audit system should collect
unauthorized file accesses for all users and root. Add the following
to -a exit,always -F arch=ARCH -S ftruncate -F success=0 -k accessor -a exit,always -F arch=ARCH -S ftruncate -F exit=-EPERM -k access -a exit,always -F arch=ARCH -S ftruncate -F exit=-EACCES -k accessRationale: Unsuccessful attempts to access files could be an indicator of malicious activity on a system. Auditing these events could serve as evidence of potential system compromise. Remediation script: |
Ensure auditd Collects Unauthorized Access Attempts to Files (unsuccessful) Via openruleAt a minimum the audit system should collect
unauthorized file accesses for all users and root. Add the following
to -a exit,always -F arch=ARCH -S open -F success=0 -k accessor -a exit,always -F arch=ARCH -S open -F exit=-EPERM -k access -a exit,always -F arch=ARCH -S open -F exit=-EACCES -k accessRationale: Unsuccessful attempts to access files could be an indicator of malicious activity on a system. Auditing these events could serve as evidence of potential system compromise. Remediation script: |
Ensure auditd Collects Unauthorized Access Attempts to Files (unsuccessful) Via openatruleAt a minimum the audit system should collect
unauthorized file accesses for all users and root. Add the following
to -a exit,always -F arch=ARCH -S openat -F success=0 -k accessor -a exit,always -F arch=ARCH -S openat -F exit=-EPERM -k access -a exit,always -F arch=ARCH -S openat -F exit=-EACCES -k accessRationale: Unsuccessful attempts to access files could be an indicator of malicious activity on a system. Auditing these events could serve as evidence of potential system compromise. Remediation script: |
Ensure auditd Collects Unauthorized Access Attempts to Files (unsuccessful) Via truncateruleAt a minimum the audit system should collect
unauthorized file accesses for all users and root. Add the following
to -a exit,always -F arch=ARCH -S truncate -F success=0 -k accessor -a exit,always -F arch=ARCH -S truncate -F exit=-EPERM -k access -a exit,always -F arch=ARCH -S truncate -F exit=-EACCES -k accessRationale: Unsuccessful attempts to access files could be an indicator of malicious activity on a system. Auditing these events could serve as evidence of potential system compromise. Remediation script: |
Ensure auditd Collects File Deletion Events by UserruleAt a minimum the audit system should collect file
deletion events for all users and root. Add the following to
-a exit,always -F arch=ARCH -S unlink -S unlinkat -S rename -S renameat -F auid>=500 -F auid!=4294967295 -k deleteRationale: Auditing file deletions will create an audit trail for files that are removed from the system. The audit trail could aid in system troubleshooting, as well as, detecting malicious processes that attempt to delete log files to conceal their presence. Remediation script: |
Ensure auditd Collects Directory Deletion Events by UserruleAt a minimum the audit system should collect directory
deletion events for all users and root. Add the following to
-a exit,always -F arch=ARCH -S rmdir -k deleteRationale: Auditing directory deletions will create an audit trail for directories that are removed from the system. The audit trail could aid in system troubleshooting, as well as, detecting malicious processes that attempt to delete log directories to conceal their presence. Remediation script: |
Ensure auditd Collects Information on Kernel Module Loading and UnloadingruleAdd the following to -w /sbin/insmod -p x -k modules -w /sbin/rmmod -p x -k modules -w /sbin/modprobe -p x -k modules -a exit,always -F arch=ARCH -S init_module -S delete_module -k modulesRationale: The addition/removal of kernel modules can be used to alter the behavior of the kernel and potentially introduce malicious code into kernel space. It is important to have an audit trail of modules that have been introduced into the kernel. Remediation script: |
Enable auditd ServiceruleThe $ sudo chkconfig --level 2345 auditd onRationale: Ensuring the |
Enable Auditing for Processes Which Start Prior to the Audit DaemonruleTo ensure all processes can be audited, even
those which start prior to the audit daemon, add the argument
kernel /vmlinuz-version ro vga=ext root=/dev/VolGroup00/LogVol00 rhgb quiet audit=1Rationale:
Each process on the system carries an "auditable" flag which
indicates whether its activities can be audited. Although |
Servicesgroup
The best protection against vulnerable software is running less software. This section describes how to review
the software which Red Hat Enterprise Linux 5 installs on a system and disable software which is not needed. It
then enumerates the software packages installed on a default Red Hat Enterprise Linux 5 system and provides guidance about which
ones can be safely disabled.
|
| contains 86 rules |
Obsolete ServicesgroupThis section discusses a number of network-visible
services which have historically caused problems for system
security, and for which disabling or severely limiting the service
has been the best available guidance for some time. As a result of
this, many of these services are not installed as part of Red Hat Enterprise Linux 6
by default.
|
| contains 11 rules |
XinetdgroupThe |
| contains 1 rule |
Disable xinetd Servicerule
The $ sudo chkconfig xinetd offRationale: The xinetd service provides a dedicated listener service for some programs, which is no longer necessary for commonly-used network services. Disabling it ensures that these uncommon services are not running, and also prevents attacks against xinetd itself. Remediation script: |
TelnetgroupThe telnet protocol does not provide confidentiality or integrity for information transmitted on the network. This includes authentication information such as passwords. Organizations which use telnet should be actively working to migrate to a more secure protocol. |
| contains 1 rule |
Disable telnet Servicerule
The $ sudo chkconfig telnet offRationale: The telnet protocol uses unencrypted network communication, which means that data from the login session, including passwords and all other information transmitted during the session, can be stolen by eavesdroppers on the network. The telnet protocol is also subject to man-in-the-middle attacks. Remediation script: |
Rlogin, Rsh, and RexecgroupThe Berkeley r-commands are legacy services which allow cleartext remote access and have an insecure trust model. |
| contains 6 rules |
Uninstall rsh-server PackageruleThe # yum erase rsh-serverRationale: The Remediation script:Remediation script: |
Disable rexec ServiceruleThe $ sudo chkconfig rexec offRationale: The rexec service uses unencrypted network communications, which means that data from the login session, including passwords and all other information transmitted during the session, can be stolen by eavesdroppers on the network. Remediation script: |
Disable rsh ServiceruleThe $ sudo chkconfig rsh offRationale: The rsh service uses unencrypted network communications, which means that data from the login session, including passwords and all other information transmitted during the session, can be stolen by eavesdroppers on the network. Remediation script: |
Disable rlogin ServiceruleThe $ sudo chkconfig rlogin offRationale: The rlogin service uses unencrypted network communications, which means that data from the login session, including passwords and all other information transmitted during the session, can be stolen by eavesdroppers on the network. Remediation script: |
Remove Rsh Trust FilesruleThe files # rm /etc/hosts.equiv $ rm ~/.rhostsRationale: Trust files are convenient, but when used in conjunction with the R-services, they can allow unauthenticated access to a system. Remediation script: |
Remove rhosts_auth EntriesruleAll pam files located within /etc/pam.d/ must not include rhosts_auth. To remove these entries, run the following command: # sed -i '/.*rhosts_auth.*/d' /etc/pam.d/*Rationale: .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. Remediation script: |
NISgroupThe Network Information Service (NIS), also known as 'Yellow Pages' (YP), and its successor NIS+ have been made obsolete by Kerberos, LDAP, and other modern centralized authentication services. NIS should not be used because it suffers from security problems inherent in its design, such as inadequate protection of important authentication information. |
| contains 1 rule |
Disable ypbind ServiceruleThe $ sudo chkconfig ypbind offRationale:
Disabling the |
TFTP ServergroupTFTP is a lightweight version of the FTP protocol which has traditionally been used to configure networking equipment. However, TFTP provides little security, and modern versions of networking operating systems frequently support configuration via SSH or other more secure protocols. A TFTP server should be run only if no more secure method of supporting existing equipment can be found. |
| contains 2 rules |
Disable tftp ServiceruleThe $ sudo chkconfig tftp offRationale:
Disabling the |
Ensure tftp Daemon Uses Secure ModeruleIf running the server_args = -s /var/lib/tftpbootRationale: Using the |
Base ServicesgroupThis section addresses the base services that are installed on a Red Hat Enterprise Linux 6 default installation which are not covered in other sections. Some of these services listen on the network and should be treated with particular discretion. Other services are local system utilities that may or may not be extraneous. In general, system services should be disabled if not required. |
| contains 2 rules |
Disable KDump Kernel Crash Analyzer (kdump)ruleThe $ sudo chkconfig kdump offRationale: Unless the system is used for kernel development or testing, there is little need to run the kdump service. |
Disable Automatic Updatesrule
The $ sudo chkconfig yum-updatesd offRationale: System package management tools can obtain a list of updates and patches from a package repository and make this information available to the SA for review and action. Using a package repository outside of the organization's control presents a risk of malicious packages being introduced. Remediation script: |
Cron and At DaemonsgroupThe cron and at services are used to allow commands to be executed at a later time. The cron service is required by almost all systems to perform necessary maintenance tasks, while at may or may not be required on a given system. Both daemons should be configured defensively. |
| contains 5 rules |
Restrict cron to Authorized Users if Necessarygroup
The
|
| contains 2 rules |
Cron Must Control AccessruleThe cron service must control access to the execution of cron jobs. This is accomplished defining the users allowed/denied in the cron.allow and cron.deny files. To confirm if these files exist, run the following commands: # ls -1l /etc/cron.allow # ls -1l /etc/cron.denyThe 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.Remediation script: |
Cron Must Deny System AccountsruleThe cron service must deny system accounts (except for root) access to the execution of cron jobs. This includes all accounts with a UID less than 500, except for 0. This is accomplished by listing all system users within the cron.deny file and ensuring that they are not listed in the cron.allow file. To confirm these conditions are met, run the following commands: # cat /etc/passwd | awk -F: '{ print $1"|"$3 }' | grep -v "^root|" | while read ENTRY; do
if [ $(echo $ENTRY | cut -d"|" -f2) -lt 500 ];then
if [ $(grep -c "$(echo $ENTRY | cut -d"|" -f1)" /etc/cron.deny) = 0 ] ||
[ $(grep -c "$(echo $ENTRY | cut -d"|" -f1)" /etc/cron.allow) != 0 ]; then
echo $ENTRY | cut -d"|" -f1; fi; fi; done
If any users are listed from the above command, then the listed user(s) does not meet the above requirements.
To centralize the management of privileged account crontabs, of the
default system accounts, only root may have a crontab.Remediation script: |
Restrict at to Authorized Users if Necessarygroup
The
|
| contains 3 rules |
At Must Control AccessruleThe at service must control access to the execution of at jobs. This is accomplished defining the users allowed/denied in the at.allow and at.deny files. To confirm if these files exist, run the following commands: # ls -1l /etc/at.allow # ls -1l /etc/at.denyThe at facility allows users to execute recurring jobs on a regular and unattended basis. The at.allow file designates accounts allowed to enter and execute jobs using the at facility. If neither at.allow nor at.deny exists, then any account may use the at facility. This may open the facility up for abuse by system intruders and malicious users.Remediation script: |
At Must Deny System AccountsruleThe at service must deny system accounts (except for root) access to the execution of at jobs. This includes all accounts with a UID less than 500, except for 0. This is accomplished by listing all system users within the at.deny file and ensuring that they are not listed in the at.allow file. To confirm these conditions are met, run the following commands: # cat /etc/passwd | awk -F: '{ print $1"|"$3 }' | grep -v "^root|" | while read ENTRY; do
if [ $(echo $ENTRY | cut -d"|" -f2) -lt 500 ];then
if [ $(grep -c "$(echo $ENTRY | cut -d"|" -f1)" /etc/at.deny) = 0 ] ||
[ $(grep -c "$(echo $ENTRY | cut -d"|" -f1)" /etc/at.allow) != 0 ]; then
echo $ENTRY | cut -d"|" -f1; fi; fi; done
If any users are listed from the above command, then the listed user(s) does not meet the above requirements.
To centralize the management of privileged account at jobs, of the
default system accounts, only root may have the ability to schedule at jobs.Remediation script: |
At.deny Must Either Not Exist Or Not Be EmptyruleOn 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. To confirm these conditions are met, run the following command: # ls -1l /etc/at.denyIf the above command returns with details about /etc/at.deny, then it exists. If it exists, then run the following command: # cat /etc/at.denyIf no entries are returned, then configure the at.deny file with the default system accounts, excluding root. Remediation script: |
SSH ServergroupThe SSH protocol is recommended for remote login and
remote file transfer. SSH provides confidentiality and integrity
for data exchanged between two systems, as well as server
authentication, through the use of public key cryptography. The
implementation included with the system is called OpenSSH, and more
detailed documentation is available from its website,
http://www.openssh.org. Its server program is called |
| contains 21 rules |
Configure OpenSSH Server if NecessarygroupIf the system needs to act as an SSH server, then
certain changes should be made to the OpenSSH daemon configuration
file |
| contains 16 rules |
Strengthen Firewall Configuration if PossiblegroupIf the SSH server is expected to only receive connections from
the local network, then strengthen the default firewall rule for the SSH service
to only accept connections from the appropriate network segment(s).
-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPTand replace it with: -A INPUT -s netwk/mask -m state --state NEW -p tcp --dport 22 -j ACCEPT |
| contains 2 rules |
Assign Designated IPruleThe SSH daemon must only listen on management network addresses
unless authorized for uses other than management. By default, all addresses are allowed.
The default setting in ListenAddress 10.10.2.1Rationale: The SSH daemon should only listen on network addresses designated for management traffic. If the system has multiple network interfaces and SSH listens on addresses not designated for management traffic, the SSH service could be subject to unauthorized access. If SSH is used for purposes other than management, such as providing an SFTP service, the list of approved listening addresses may be documented. Remediation script: |
Enable SSH IP FilteringruleIP filtering should be enabled for SSH in either /etc/hosts.allow or /etc/hosts.deny. By default, no IP filtering is configured. IP filtering for SSH can be verified by ensuring that a line similar to the following appears: sshd:10.10.:spawn /bin/echo SSHD accessed on $(/bin/date) from %h>>/var/log/host.accessRationale: The SSH daemon must be configured for IP filtering to provide a layered defence against connection attempts from unauthorized addresses. Remediation script: |
Allow Only SSH Protocol 2ruleOnly SSH protocol version 2 connections should be
permitted. The default setting in
Protocol 2Rationale: SSH protocol version 1 suffers from design flaws that result in security vulnerabilities and should not be used. Remediation script: |
Disable SSH Root LoginruleThe root user should never be allowed to login to a
system directly over a network.
To disable root login via SSH, add or correct the following line
in PermitRootLogin noRationale: Permitting direct root login reduces auditable information about who ran privileged commands on the system and also allows direct attack attempts on root's password. Remediation script: |
Enable SSH Warning Bannerrule
To enable the warning banner and ensure it is consistent
across the system, add or correct the following line in Banner /etc/issueAnother section contains information on how to create an appropriate system-wide warning banner. Rationale: The warning message reinforces policy awareness during the logon process and facilitates possible legal action against attackers. Alternatively, systems whose ownership should not be obvious should ensure usage of a banner that does not provide easy attribution. Remediation script: |
Use Only Approved CiphersruleLimit the ciphers to those algorithms which are FIPS-approved.
The following line in Ciphers aes128-ctr,aes192-ctr,aes256-ctrThe man page sshd_config(5) contains a list of supported ciphers.
Rationale:Approved algorithms should impart some level of confidence in their implementation. These are also required for compliance. Remediation script: |
Do Not Use CBC ModeruleThe Cipher-Block Chaining (CBC) mode of encryption as implemented
in the SSHv2 protocol is vulnerable to chosen plain text attacks.
Counter (CTR) mode is preferred over CBC mode.
The following line in Ciphers aes128-ctr,aes192-ctr,aes256-ctrThe man page sshd_config(5) contains a list of supported ciphers.
Rationale:Approved algorithms should impart some level of confidence in their implementation. These are also required for compliance. Remediation script: |
Use Only Approved MacsruleLimit the MACs to those hash algorithms which are FIPS-approved.
The following line in Macs hmac-sha1The man page sshd_config(5) contains a list of supported macs.
Rationale:DoD information systems are required to use FIPS 140-2 approved cryptographic hash functions. Remediation script: |
Disable GSSAPIAuthenticationruleGSSAPIAuthentication should not be
permitted. The default setting in
GSSAPIAuthentication noRationale: 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. Remediation script: |
Display Login DetailsruleA user should be presented with details on the last attempted access
to their account, upon logging in. The default setting in
PrintLastLog yesRationale: Providing users with feedback on when account accesses last occurred facilitates user recognition and reporting of unauthorized account use. Remediation script: |
Restrict Users/GroupsruleLogin access to the SSH server should be restricted to a
list of allowed users or groups. The default setting in
AllowedUsersor AllowedGroupsRationale: 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. Remediation script: |
Disable KerberosAuthenticationruleKerberosAuthentication should not be
permitted. The default setting in
KerberosAuthentication noRationale: 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. Remediation script: |
Enable StrictModesruleStrictModes must be enabled.
The default setting in
StrictModes yesRationale: If other users have access to modify user-specific SSH configuration files, they may be able to log into the system as another user. Remediation script: |
Enable Privilege SeparationruleUsePrivilegeSeparation must be enabled.
The default setting in
UsePrivilegeSeparation yesRationale: 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. Remediation script: |
Disable RhostsRSAAuthenticationruleRhostsRSAAuthentication should not be
permitted. The default setting in
RhostsRSAAuthentication noRationale: 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. Remediation script: |
Disable Or Delay CompressionruleCompression should not be
permitted prior to authentication. The default setting in
Compression noor Compression delayedRationale: 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. Remediation script: |
Configure OpenSSH Client if NecessarygroupIf the system needs to utilize the SSH client, then
certain changes should be made to the OpenSSH client configuration
file |
| contains 5 rules |
Allow Only SSH Protocol 2ruleOnly SSH protocol version 2 connections should be
permitted. The default setting in
Protocol 2Rationale: SSH protocol version 1 suffers from design flaws that result in security vulnerabilities and should not be used. Remediation script: |
Use Only Approved CiphersruleLimit the ciphers to those algorithms which are FIPS-approved.
The following line in Ciphers aes128-ctr,aes192-ctr,aes256-ctrThe man page ssh_config(5) contains a list of supported ciphers.
Rationale:Approved algorithms should impart some level of confidence in their implementation. These are also required for compliance. Remediation script: |
Do Not Use CBC ModeruleThe Cipher-Block Chaining (CBC) mode of encryption as implemented
in the SSHv2 protocol is vulnerable to chosen plain text attacks.
Counter (CTR) mode is preferred over CBC mode.
The following line in Ciphers aes128-ctr,aes192-ctr,aes256-ctrThe man page ssh_config(5) contains a list of supported ciphers.
Rationale:Approved algorithms should impart some level of confidence in their implementation. These are also required for compliance. Remediation script: |
Use Only Approved MacsruleLimit the MACs to those hash algorithms which are FIPS-approved.
The following line in Macs hmac-sha1The man page ssh_config(5) contains a list of supported macs.
Rationale:DoD information systems are required to use FIPS 140-2 approved cryptographic hash functions. Remediation script: |
Disable GSSAPIAuthenticationruleGSSAPIAuthentication should not be
permitted. The default setting in
GSSAPIAuthentication noRationale: 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. Remediation script: |
X Window SystemgroupThe X Window System implementation included with the system is called X.org. |
| contains 1 rule |
Disable X WindowsgroupUnless there is a mission-critical reason for the system to run a graphical user interface, ensure X is not set to start automatically at boot and remove the X Windows software packages. There is usually no reason to run X Windows on a dedicated server machine, as it increases the system's attack surface and consumes system resources. Administrators of server systems should instead login via SSH or on the text console. |
| contains 1 rule |
Disable X Windows Startup By Setting RunlevelruleSetting the system's runlevel to 3 will prevent automatic startup
of the X server. To do so, ensure the following line in id:3:initdefault:Rationale: Unnecessary services should be disabled to decrease the attack surface of the system. Remediation script: |
DHCPgroupThe Dynamic Host Configuration Protocol (DHCP) allows
systems to request and obtain an IP address and other configuration
parameters from a server.
|
| contains 2 rules |
Disable DHCP ClientgroupDHCP is the default network configuration method provided by the system installer, and common on many networks. Nevertheless, manual management of IP addresses for systems implies a greater degree of management and accountability for network activity. |
| contains 1 rule |
Disable DHCP Clientrule
For each interface on the system (e.g. eth0), edit
DHCP relies on trusting the local network. If the local network is not trusted, then it should not be used. However, the automatic configuration provided by DHCP is commonly used and the alternative, manual configuration, presents an unacceptable burden in many circumstances. Remediation script: |
Configure DHCP Client if NecessarygroupIf DHCP must be used, then certain configuration changes can
minimize the amount of information it receives and applies from the network,
and thus the amount of incorrect information a rogue DHCP server could
successfully distribute. For more information on configuring dhclient, see the
|
| contains 1 rule |
Do Not Use Dynamic DNSruleTo prevent the DHCP client from transmitting system information,
edit do-forward-updates false;Rationale: Dynamic DNS updates transmit unencrypted information about a system including its name and address and should not be used unless needed. Remediation script: |
Network Time ProtocolgroupThe Network Time Protocol is used to manage the system
clock over a network. Computer clocks are not very accurate, so
time will drift unpredictably on unmanaged systems. Central time
protocols can be used both to ensure that time is consistent among
a network of machines, and that their time is consistent with the
outside world.
|
| contains 3 rules |
Enable the NTP Daemonrule
The $ sudo chkconfig --level 2345 ntpd onRationale: Enabling the |
Specify a Remote NTP ServerruleTo specify a remote NTP server for time synchronization, edit
the file server ntpserverThis instructs the NTP software to contact that remote server to obtain time data. Rationale: Synchronizing with an NTP server makes it possible to collate system logs from multiple sources or correlate computer events with real time events. |
Specify Additional Remote NTP ServersruleAdditional NTP servers can be specified for time synchronization
in the file server ntpserverRationale: Specifying additional NTP servers increases the availability of accurate time data, in the event that one of the specified servers becomes unavailable. This is typical for a system acting as an NTP server for other systems. |
Mail Server Softwaregroup
Mail servers are used to send and receive email over the network.
Mail is a very common service, and Mail Transfer Agents (MTAs) are obvious
targets of network attack.
Ensure that machines are not running MTAs unnecessarily,
and configure needed MTAs as defensively as possible.
|
| contains 12 rules |
Mail Server LogginggroupIt is important to ensure adequate logging of mail server connections so as to support detecting any unauthorized activity. |
| contains 2 rules |
Enable Mail Server LoggingruleTo ensure logging is enabled, perform the following command: grep "mail\." /etc/syslog.confThe output received should indicate either mail.crit or mail.*.
Rationale:If informational and more severe SMTP service messages are not logged, malicious activity on the system may go unnoticed. |
Configure Mail Server Logging Levelrule
If sendmail is installed, perform the following checks:
Edit the file O LogLevel=9If postfix is installed, this check is not applicable. Rationale: 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. |
Mail Server Featuresgroup
Mail servers are used to send and receive email over the network.
Mail is a very common service, and Mail Transfer Agents (MTAs) are obvious
targets of network attack.
Ensure that machines are not running MTAs unnecessarily,
and configure needed MTAs as defensively as possible.
|
| contains 9 rules |
Disable Debug CommandruleFrom a terminal, type the following commands: # telnet localhost 25 # debugIf debug is disabled, one of the following errors should be returned: 500 error code of "command unrecognised" 550 error code of "access denied"Rationale: Debug mode is a feature present in older versions of sendmail which, if not disabled, may allow an attacker to gain access to a system through the sendmail service. |
Disable Decode Commandrule
Edit the file(s) decode: |/usr/bin/uudecode uudecode: |/usr/bin/uuencode -dRationale: A common configuration for older Mail Transfer Agents (MTAs) is to include an alias for the decode user. All mail sent to this user is sent to the uudecode program, which automatically converts and stores files. By sending mail to the decode or the uudecode aliases present on some systems, a remote attacker may be able to create or overwrite files on the remote host. This could possibly be used to gain remote access. |
Disable EXPN Commandrule
If sendmail is installed, perform the following checks:
Edit the file O PrivacyOptions=authwarnings,novrfy,noexpn,restrictqrunIf postfix is installed, this check is not applicable. Rationale: 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. |
Disable Help Commandrule
If sendmail is installed, perform the following checks:
Edit the file 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. Remediation script: |
Disable VRFY Commandrule
If sendmail is installed, perform the following checks:
Edit the file O PrivacyOptions=authwarnings,novrfy,noexpn,restrictqrunIf postfix is installed, this check is not applicable. Rationale: 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. |
Disable WIZ CommandruleFrom a terminal, type the following commands: # telnet localhost 25 # wizIf wiz is disabled, the following error should be returned: 500 error code of "command unrecognised"Rationale: Very old installations of the Sendmail mailing system contained a feature whereby a remote user connecting to the SMTP port can enter the WIZ command and be given an interactive shell with root privileges. |
Don't Display Versionrule
If sendmail is installed, perform the following checks:
Edit the file O SmtpGreetingMessage=$j Sendmail $v/$Z; $bIf the above line appears, it should be changed to: O SmtpGreetingMessage= Mail Server Ready ; $bIf postfix is installed, perform the following checks: Edit the file /etc/postfix/main.cf to ensure that the following
smtpd_banner line does not appear with $mail_version. If so,
remove the $mail_version entry or comment out the entire line to use
the default value.
Rationale:The version of the SMTP service can be used by attackers to plan an attack based on vulnerabilities present in the specific version. Remediation script: |
Restrict Mail Forwardingrule
If sendmail is installed, perform the following checks:
Edit the file 0 ForwardPathPerform a search on the system for any .forward files by issuing the following command:
# find / -name .forwardThe above command should not return any results. If so, delete each file returned. Rationale: 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. Remediation script: |
Restrict Mail Relayingrule
If sendmail is installed, perform the following checks:
Edit the file O DaemonPortOptions=Port=smtp,Addr=127.0.0.1, Name=MTAEdit the file /etc/mail/sendmail.mc to ensure that the following
promiscuous_relay line does NOT appear:
promiscuous_relayIf postfix is installed, perform the following checks: Edit the file /etc/postfix/main.cf to ensure that only the following
inet_interfaces line appears:
inet_interfaces = localhostEdit the file /etc/postfix/main.cf to ensure that only the following
smtpd_client_restrictions line appears:
smtpd_client_restrictions = rejectRationale: 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. |
Mail Server Software UpdatesruleIf sendmail is installed, perform the following command: # rpm -q sendmailThe version indicated should be equal to or greater than the following: 8.13.8-8If postfix is installed, perform the following command: # rpm -q postfixThe version indicated should be equal to or greater than the following: 2.3.3-6Rationale: The SMTP service version on the system must be current to avoid exposing vulnerabilities present in unpatched versions. |
LDAPgroupLDAP is a popular directory service, that is, a standardized way of looking up information from a central database. Red Hat Enterprise Linux 5 includes software that enables a system to act as both an LDAP client and server. |
| contains 5 rules |
Configure OpenLDAP ClientsgroupThis section provides information on which security settings are
important to configure in OpenLDAP clients by manually editing the appropriate
configuration files. Red Hat Enterprise Linux 5 provides an automated configuration tool called
authconfig and a graphical wrapper for authconfig called
warning
Before configuring any system to be an
LDAP client, ensure that a working LDAP server is present on the
network. |
| contains 5 rules |
Configure LDAP Client to Use TLS For All TransactionsruleConfigure LDAP to enforce TLS use. First, edit the file
ssl start_tlsThen review the LDAP server and ensure TLS has been configured. Rationale: The ssl directive specifies whether to use ssl or not. If not specified it will default to no. It should be set to start_tls rather than doing LDAP over SSL. Remediation script: |
Configure Certificate Directives for LDAP Use of TLSruleEnsure a copy of a trusted CA certificate has been placed in
the file tls_cert /etc/pki/tls/CAor tls_cert /etc/pki/tls/CA/cacert.pemRationale: 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. Remediation script: |
Configure Certificate Trust ValidationruleEnsure LDAP server connections have a valid trust path.
Configure LDAP to enforce validation of LDAP server certificates for trust.
First, edit the file tls_checkpeer yesRationale: 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. Remediation script: |
Configure Certificate Revocation ValidationruleEnsure LDAP server connections have a valid certificate that is not revoked.
Configure LDAP to enforce validation of LDAP server certificates for revocation.
First, edit the file tls_crlcheck allRationale: 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. Remediation script: |
LDAP Passwords Are Stored In Clear TextruleEnsure the LDAP configuration does not include any passwords stored in clear text.
Edit the file 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. Remediation script: |
NFS and RPCgroupThe Network File System is a popular distributed filesystem for the Unix environment, and is very widely deployed. This section discusses the circumstances under which it is possible to disable NFS and its dependencies, and then details steps which should be taken to secure NFS's configuration. This section is relevant to machines operating as NFS clients, as well as to those operating as NFS servers. |
| contains 7 rules |
Disable All NFS Services if PossiblegroupIf there is not a reason for the system to operate as either an NFS client or an NFS server, follow all instructions in this section to disable subsystems required by NFS. warning
The steps in this section will prevent a machine
from operating as either an NFS client or an NFS server. Only perform these
steps on machines which do not need NFS at all. |
| contains 2 rules |
Remove Services Used Only by NFSgroupIf NFS is not needed, remove the NFS client daemons portmap and rpcbind.
|
| contains 1 rule |
Remove portmap and rpcbind PackagesruleThe # yum erase portmap rpcbindRemediation script: |
Disable Services Used Only by NFSgroupIf NFS is not needed, disable the NFS client daemons nfslock, rpcgssd, and rpcidmapd.
|
| contains 1 rule |
Disable portmap and rpcbind ServicesruleThe rpcbind service increase the attack surface of
the system and should only be used when needed. The rpcbind service
are used by a variety of services using Remote Procedure Calls (RPCs).
The $ sudo chkconfig rpcbind off |
Configure All Machines which Use NFSgroupThe steps in this section are appropriate for all machines which run NFS, whether they operate as clients or as servers. |
| contains 5 rules |
Configure NFS ClientsgroupThe steps in this section are appropriate for machines which operate as NFS clients. |
| contains 1 rule |
Mount Remote Filesystems with nosuidrule
Add the NFS mounts should not present suid binaries to users. Only vendor-supplied suid executables should be installed to their default location on the local filesystem. |
Configure NFS ServersgroupThe steps in this section are appropriate for machines which operate as NFS servers. |
| contains 4 rules |
Specify UID and GID for Anonymous NFS ConnectionsruleTo specify the UID and GID for remote root users, edit the anonuid=-1 anongid=-1Rationale: Specifying the anonymous UID and GID as -1 ensures that the remote root user is mapped to a local account which has no permissions on the system. |
All Exports Must Define Allowed TargetsruleWhen configuring NFS exports, ensure that each export line in
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. |
Use Root-Squashing on All ExportsruleIf a filesystem is exported using root squashing, requests from root on the client
are considered to be unprivileged (mapped to a user such as nobody). This provides some mild
protection against remote abuse of an NFS server. Root squashing is enabled by default, and
should not be disabled.
If the NFS server allows root access to local file systems from remote hosts, this access could be used to compromise the system. |
Ensure Insecure File Locking is Not AllowedruleBy default the NFS server requires secure file-lock requests,
which require credentials from the client in order to lock a file. Most NFS
clients send credentials with file lock requests, however, there are a few
clients that do not send credentials when requesting a file-lock, allowing the
client to only be able to lock world-readable files. To get around this, the
Allowing insecure file locking could allow for sensitive data to be viewed or edited by an unauthorized user. |
FTP ServergroupFTP is a common method for allowing remote access to
files. Like telnet, the FTP protocol is unencrypted, which means
that passwords and other data transmitted during the session can be
captured and that the session is vulnerable to hijacking.
Therefore, running the FTP server software is not recommended.
|
| contains 7 rules |
Disable Unencrypted FTP Servicesrule
The $ sudo chkconfig vsftpd offRationale: Running unencrypted FTP server software provides a network-based avenue of attack, and should be disabled if not needed. Furthermore, the FTP protocol is unencrypted and creates a risk of compromising sensitive information. |
Enable Logging of All FTP TransactionsruleAdd or correct the following configuration options within the xferlog_enable=YES xferlog_std_format=NO log_ftp_protocol=YES warning
If verbose logging to vsftpd.log is done, sparse logging of downloads to /var/log/xferlog will not also occur. However, the information about what files were downloaded is included in the information logged to vsftpd.logTo trace malicious activity facilitated by the FTP service, it must be configured to ensure that all commands sent to
the FTP server are logged using the verbose vsftpd log
format. The default vsftpd log file is |
FTP Umask Must Be 077.ruleAll FTP users must have a default umask of 077. Rationale: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). Remediation script: |
Ftpusers File Contains UsersruleThe ftpusers file must contain account names not allowed to use FTP. Rationale:The ftpusers file contains a list of accounts not allowed to use FTP to transfer files. If the file does not contain the names of all accounts not authorized to use FTP, then unauthorized use of FTP may take place. Remediation script: |
Ftpusers File ExistsruleThe ftpusers file must exist. Rationale: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. Remediation script: |
FTP User Has ShellruleAnonymous FTP accounts must not have a functional shell. Rationale: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. |
TFTP User Has ShellruleThe TFTP daemon must be configured to vendor specifications, including a dedicated TFTP user account, a non-login shell such as /bin/false, and a home directory owned by the TFTP user. Rationale:If TFTP has a valid shell, it increases the likelihood someone could log on to the TFTP account and compromise the system. |
Samba(SMB) Microsoft Windows File Sharing ServergroupWhen properly configured, the Samba service allows
Linux machines to provide file and print sharing to Microsoft
Windows machines. There are two software packages that provide
Samba support. The first, |
| contains 6 rules |
Remove Samba if PossiblegroupThe Samba server must not be installed unless it provides an operational need. |
| contains 1 rule |
Remove samba and samba3x PackagesruleThe # yum erase samba samba3xRemediation script: |
Configure Samba if NecessarygroupAll settings for the Samba daemon can be found in
|
| contains 5 rules |
Samba Web Administration Tool Must Be RestrictedruleThe Samba Web Administration Tool (SWAT) must be restricted to the local host or require SSL. Rationale:SWAT is a tool used to configure Samba. It modifies Samba configuration, which can impact system security, and must be protected from unauthorized access. SWAT authentication may involve the root password, which must be protected by encryption when traversing the network. Restricting access to the local host allows for the use of SSH TCP forwarding, if configured, or administration by a web browser on the local system. |
Configure hosts OptionruleSamba increases the attack surface of the system and must be restricted to communicate only with systems requiring access. Rationale:Specifying the anonymous UID and GID as -1 ensures that the remote root user is mapped to a local account which has no permissions on the system. Remediation script: |
Configure security OptionruleSamba share authentication does not provide for individual user identification and must not be used. Rationale:Specifying the anonymous UID and GID as -1 ensures that the remote root user is mapped to a local account which has no permissions on the system. Remediation script: |
Configure encrypt passwords OptionruleRationale: Samba must be configured to use encrypted passwords. Remediation script: |
Configure guest ok OptionruleRationale: Guest access to shares permits anonymous access and is not permitted. Remediation script: |
SNMP ServergroupThe Simple Network Management Protocol allows administrators to monitor the state of network devices, including computers. Older versions of SNMP were well-known for weak security, such as plaintext transmission of the community string (used for authentication) and usage of easily-guessable choices for the community string. |
| contains 4 rules |
Configure SNMP ServergroupIf it is necessary to run the snmpd agent on the system, some best practices should be followed to minimize the security risk from the installation. The multiple security models implemented by SNMP cannot be fully covered here so only the following general configuration advice can be offered:
|
| contains 4 rules |
Configure SNMP Service to Use Only SNMPv3 or Newer rule
Edit # service snmpd restartRationale: Earlier versions of SNMP are considered insecure, as they potentially allow unauthorized access to detailed system management information. Remediation script: |
Ensure Default Password Is Not Usedrule
Edit # service snmpd restartRationale: Presence of the default SNMP password enables querying of different system aspects and could result in unauthorized knowledge of the system. |
Ensure Approved Hash Is Usedrule
Edit # createUser myuser SHA -l 0x0001020304050607080900010203040506070809 AES -l 0x00010203040506070809000102030405Upon doing that, restart the SNMP service: # service snmpd restartRationale: The SNMP service must use SHA-1 or a FIPS 140-2 approved successor for authentication and integrity. |
Ensure Approved Encryption Is Usedrule
Edit # createUser myuser SHA -l 0x0001020304050607080900010203040506070809 AES -l 0x00010203040506070809000102030405Upon doing that, restart the SNMP service: # service snmpd restartRationale: The SNMP service must use AES or a FIPS 140-2 approved successor algorithm for protecting the privacy of communications. |