contains 456 rules |
System Settings
[ref]groupContains rules that check correct system settings. |
contains 370 rules |
Installing and Maintaining Software
[ref]groupThe 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 Partitioning
[ref]groupTo 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
/ , /boot , and swap .
- If starting with any of the default layouts, check the box to
"Review and modify partitioning." This allows for the easy creation
of additional logical volumes inside the volume group already
created, though it may require making
/ 's logical volume smaller to
create space. In general, using logical volumes is preferable to
using partitions because they can be more easily adjusted
later. - If creating a custom layout, create the partitions mentioned in
the previous paragraph (which the installer will require anyway),
as well as separate ones described in the following sections.
If a system has already been installed, and the default
partitioning scheme was used, it is possible but nontrivial to
modify it to create separate logical volumes for the directories
listed above. The Logical Volume Manager (LVM) makes this possible.
See the LVM HOWTO at http://tldp.org/HOWTO/LVM-HOWTO/ for more
detailed information on LVM. |
contains 4 rules |
Ensure /tmp Located On Separate Partition
[ref]rule
The /tmp directory is a world-writable directory used
for temporary file storage. Ensure it has its own partition or
logical volume at installation time, or migrate it using LVM.
Rationale:
The /tmp partition is used as temporary storage by many programs.
Placing /tmp in its own partition enables the setting of more
restrictive mount options, which can help protect programs which use it.
|
Ensure /var Located On Separate Partition
[ref]ruleThe /var directory is used by daemons and other system
services to store frequently-changing data. Ensure that /var has its own partition
or logical volume at installation time, or migrate it using LVM.
Rationale:
Ensuring that /var is mounted on its own partition enables the
setting of more restrictive mount options. This helps protect
system services such as daemons or other programs which use it.
It is not uncommon for the /var directory to contain
world-writable directories, installed by other software packages.
|
Ensure /var/log/audit Located On Separate Partition
[ref]rule
Audit logs are stored in the /var/log/audit directory. Ensure that it
has its own partition or logical volume at installation time, or migrate it
later using LVM. Make absolutely certain that it is large enough to store all
audit logs that will be created by the auditing daemon.
Rationale:
Placing /var/log/audit in its own partition
enables better separation between audit files
and other files, and helps ensure that
auditing cannot be halted due to the partition running out
of space.
|
Ensure /home Located On Separate Partition
[ref]rule
If user home directories will be stored locally, create a separate partition
for /home at installation time (or migrate it later using LVM). If
/home will be mounted from another system such as an NFS server, then
creating a separate partition is not necessary at installation time, and the
mountpoint can instead be configured later.
Rationale:
Ensuring that /home is mounted on its own partition enables the
setting of more restrictive mount options, and also helps ensure that
users cannot trivially fill partitions used for log or audit data storage.
|
Updating Software
[ref]groupThe yum command line tool is used to install and
update software packages. The system also provides a graphical
software update tool in the System menu, in the Administration submenu,
called Software Update.
Red Hat Enterprise Linux systems contain an installed software catalog called
the RPM database, which records metadata of installed packages. Consistently using
yum or the graphical Software Update for all software installation
allows for insight into the current inventory of installed software on the system.
|
contains 1 rule |
Ensure gpgcheck Enabled For All Yum Package Repositories
[ref]ruleTo ensure signature checking is not disabled for
any repos, remove any lines from files in /etc/yum.repos.d of the form:
gpgcheck=0
Rationale:
Ensuring all packages' cryptographic signatures are valid prior to
installation ensures the authenticity of the software and
protects against malicious tampering.
Identifiers:
GEN008800 References:
ECSC-1, 351 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | disable |
---|
grep -R gpgcheck /etc/yum.repos.d/* /etc/yum.conf /root/rpmrc /usr/lib/rpm/redhat/rpmrc /usr/lib/rpm/rpmrc /etc/rpmrc 2>/dev/null | grep -v 'gpgcheck=1' | cut -d: -f1 | sort -u | while read YUM_FILE; do
sed -i 's/gpgcheck=.*/gpgcheck=1/g' ${YUM_FILE}
done
|
Software Integrity Checking
[ref]group
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.
Integrity checking cannot prevent intrusions,
but can detect that they have occurred. Requirements
for software integrity checking may be highly dependent on
the environment in which the system will be used. Snapshot-based
approaches such as AIDE may induce considerable overhead
in the presence of frequent software updates.
|
contains 7 rules |
Verify Integrity with AIDE
[ref]groupAIDE 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 /usr/share/doc/aide-VERSION .
|
contains 2 rules |
Build and Test AIDE Database
[ref]ruleRun the following command to generate a new database:
# /usr/sbin/aide --init
By 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.gz
To initiate a manual check, run the following command:
# /usr/sbin/aide --check
If 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.
Identifiers:
GEN000140-2 References:
DCSW-1, 293 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | disable |
---|
/usr/sbin/aide --init
/bin/cp -p /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
|
Configure Periodic Execution of AIDE
[ref]rule
To implement a daily execution of AIDE at 4:05am using cron, add the following line to /etc/crontab :
05 4 * * * root /usr/sbin/aide --check
AIDE 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 Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | disable |
---|
echo "/usr/sbin/aide --config=/etc/aide.conf --check" > /etc/cron.weekly/aide
chmod 700 /etc/cron.weekly/aide
|
Additional Security Software
[ref]group
Additional 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 Software
[ref]rule
The 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 Software
[ref]rule
Install 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 Files
[ref]rule
A 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 Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
# Generate a device file baseline
find / -type b -o -type c 2>/dev/null | sort > /var/log/device-file-list
chmod 640 /var/log/device-file-list
chown root:root /var/log/device-file-list
# Generate a weekly cron job to check the device file baseline and report differences
cat > /etc/cron.weekly/baseline_checker.sh <<'STOP_HERE'
#!/bin/sh
echo "Baseline check started on $(date +"%m-%d-%Y") at $(date +"%H:%M:%S")" | tee -a /var/log/baseline.log
echo -e \\n | tee -a /var/log/baseline.log
echo "Gathering current baseline." | tee -a /var/log/baseline.log
echo -e \\n | tee -a /var/log/baseline.log
rm -f /tmp/*BASELINE.tmp /tmp/*list.tmp
find / -perm -4000 2>/dev/null | sort > /tmp/suid-file-list.tmp
find / -perm -2000 2>/dev/null | sort > /tmp/sgid-file-list.tmp
find / -type b -o -type c 2>/dev/null | sort > /tmp/device-file-list.tmp
echo "Comparing the current baseline with the last known good configuration." | tee -a /var/log/baseline.log
echo -e \\n | tee -a /var/log/baseline.log
diff /var/log/suid-file-list /tmp/suid-file-list.tmp > /tmp/SUID_BASELINE.tmp
diff /var/log/sgid-file-list /tmp/sgid-file-list.tmp > /tmp/SGID_BASELINE.tmp
diff /var/log/device-file-list /tmp/device-file-list.tmp > /tmp/DEVICE_BASELINE.tmp
if [ -s /tmp/SUID_BASELINE.tmp ]; then
if [ $(grep -c "^>" /tmp/SUID_BASELINE.tmp) != 0 ]; then
echo "The following files were detected to have the suid bit added:" | tee -a /var/log/baseline.log
echo -e \\n | tee -a /var/log/baseline.log
grep "^>" /tmp/SUID_BASELINE.tmp | awk '{ print $2 }' | tee -a /var/log/baseline.log
echo -e \\n | tee -a /var/log/baseline.log
fi
if [ $(grep -c "^<" /tmp/SUID_BASELINE.tmp) != 0 ]; then
echo "The following files were detected to have the suid bit removed:" | tee -a /var/log/baseline.log
echo -e \\n | tee -a /var/log/baseline.log
grep "^<" /tmp/SUID_BASELINE.tmp | awk '{ print $2 }' | tee -a /var/log/baseline.log
echo -e \\n | tee -a /var/log/baseline.log
fi
fi
if [ -s /tmp/SGID_BASELINE.tmp ]; then
if [ $(grep -c "^>" /tmp/SGID_BASELINE.tmp) != 0 ]; then
echo "The following files were detected to have the sgid bit added:" | tee -a /var/log/baseline.log
echo -e \\n | tee -a /var/log/baseline.log
grep "^>" /tmp/SGID_BASELINE.tmp | awk '{ print $2 }' | tee -a /var/log/baseline.log
echo -e \\n | tee -a /var/log/baseline.log
fi
if [ $(grep -c "^<" /tmp/SGID_BASELINE.tmp) != 0 ]; then
echo "The following files were detected to have the sgid bit removed:" | tee -a /var/log/baseline.log
echo -e \\n | tee -a /var/log/baseline.log
grep "^<" /tmp/SGID_BASELINE.tmp | awk '{ print $2 }' | tee -a /var/log/baseline.log
echo -e \\n | tee -a /var/log/baseline.log
fi
fi
if [ -s /tmp/DEVICE_BASELINE.tmp ]; then
if [ $(grep -c "^>" /tmp/DEVICE_BASELINE.tmp) != 0 ]; then
echo "The following device files were detected to have been added:" | tee -a /var/log/baseline.log
echo -e \\n | tee -a /var/log/baseline.log
grep "^>" /tmp/DEVICE_BASELINE.tmp | awk '{ print $2 }' | tee -a /var/log/baseline.log
echo -e \\n | tee -a /var/log/baseline.log
fi
if [ $(grep -c "^<" /tmp/DEVICE_BASELINE.tmp) != 0 ]; then
echo "The following device files were detected to have removed:" | tee -a /var/log/baseline.log
echo -e \\n | tee -a /var/log/baseline.log
grep "^<" /tmp/DEVICE_BASELINE.tmp | awk '{ print $2 }' | tee -a /var/log/baseline.log
echo -e \\n | tee -a /var/log/baseline.log
fi
fi
rm -f /tmp/*BASELINE.tmp /tmp/*list.tmp
echo "Baseline check completed on $(date +"%m-%d-%Y") at $(date +"%H:%M:%S")" | tee -a /var/log/baseline.log
echo -e \\n | tee -a /var/log/baseline.log
echo "####################################################################" | tee -a /var/log/baseline.log
echo -e \\n | tee -a /var/log/baseline.log
chmod 640 /var/log/baseline.log
chown root:root /var/log/baseline.log
STOP_HERE
chmod 700 /etc/cron.weekly/baseline_checker.sh
chown root:root /etc/cron.weekly/baseline_checker.sh
|
Create a Baseline For SGID Files
[ref]rule
A 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.
Identifiers:
GEN002460 References:
DCSL-1, 318 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
# Generate a sgid file baseline
find / -perm -2000 -type f 2>/dev/null | sort > /var/log/sgid-file-list
chmod 640 /var/log/sgid-file-list
chown root:root /var/log/sgid-file-list
# Generate a weekly cron job to check the sgid file baseline and report differences
cat > /etc/cron.weekly/baseline_checker.sh <<'STOP_HERE'
#!/bin/sh
echo "Baseline check started on $(date +"%m-%d-%Y") at $(date +"%H:%M:%S")" | tee -a /var/log/baseline.log
echo -e \\n | tee -a /var/log/baseline.log
echo "Gathering current baseline." | tee -a /var/log/baseline.log
echo -e \\n | tee -a /var/log/baseline.log
rm -f /tmp/*BASELINE.tmp /tmp/*list.tmp
find / -perm -4000 2>/dev/null | sort > /tmp/suid-file-list.tmp
find / -perm -2000 2>/dev/null | sort > /tmp/sgid-file-list.tmp
find / -type b -o -type c 2>/dev/null | sort > /tmp/device-file-list.tmp
echo "Comparing the current baseline with the last known good configuration." | tee -a /var/log/baseline.log
echo -e \\n | tee -a /var/log/baseline.log
diff /var/log/suid-file-list /tmp/suid-file-list.tmp > /tmp/SUID_BASELINE.tmp
diff /var/log/sgid-file-list /tmp/sgid-file-list.tmp > /tmp/SGID_BASELINE.tmp
diff /var/log/device-file-list /tmp/device-file-list.tmp > /tmp/DEVICE_BASELINE.tmp
if [ -s /tmp/SUID_BASELINE.tmp ]; then
if [ $(grep -c "^>" /tmp/SUID_BASELINE.tmp) != 0 ]; then
echo "The following files were detected to have the suid bit added:" | tee -a /var/log/baseline.log
echo -e \\n | tee -a /var/log/baseline.log
grep "^>" /tmp/SUID_BASELINE.tmp | awk '{ print $2 }' | tee -a /var/log/baseline.log
echo -e \\n | tee -a /var/log/baseline.log
fi
if [ $(grep -c "^<" /tmp/SUID_BASELINE.tmp) != 0 ]; then
echo "The following files were detected to have the suid bit removed:" | tee -a /var/log/baseline.log
echo -e \\n | tee -a /var/log/baseline.log
grep "^<" /tmp/SUID_BASELINE.tmp | awk '{ print $2 }' | tee -a /var/log/baseline.log
echo -e \\n | tee -a /var/log/baseline.log
fi
fi
if [ -s /tmp/SGID_BASELINE.tmp ]; then
if [ $(grep -c "^>" /tmp/SGID_BASELINE.tmp) != 0 ]; then
echo "The following files were detected to have the sgid bit added:" | tee -a /var/log/baseline.log
echo -e \\n | tee -a /var/log/baseline.log
grep "^>" /tmp/SGID_BASELINE.tmp | awk '{ print $2 }' | tee -a /var/log/baseline.log
echo -e \\n | tee -a /var/log/baseline.log
fi
if [ $(grep -c "^<" /tmp/SGID_BASELINE.tmp) != 0 ]; then
echo "The following files were detected to have the sgid bit removed:" | tee -a /var/log/baseline.log
echo -e \\n | tee -a /var/log/baseline.log
grep "^<" /tmp/SGID_BASELINE.tmp | awk '{ print $2 }' | tee -a /var/log/baseline.log
echo -e \\n | tee -a /var/log/baseline.log
fi
fi
if [ -s /tmp/DEVICE_BASELINE.tmp ]; then
if [ $(grep -c "^>" /tmp/DEVICE_BASELINE.tmp) != 0 ]; then
echo "The following device files were detected to have been added:" | tee -a /var/log/baseline.log
echo -e \\n | tee -a /var/log/baseline.log
grep "^>" /tmp/DEVICE_BASELINE.tmp | awk '{ print $2 }' | tee -a /var/log/baseline.log
echo -e \\n | tee -a /var/log/baseline.log
fi
if [ $(grep -c "^<" /tmp/DEVICE_BASELINE.tmp) != 0 ]; then
echo "The following device files were detected to have removed:" | tee -a /var/log/baseline.log
echo -e \\n | tee -a /var/log/baseline.log
grep "^<" /tmp/DEVICE_BASELINE.tmp | awk '{ print $2 }' | tee -a /var/log/baseline.log
echo -e \\n | tee -a /var/log/baseline.log
fi
fi
rm -f /tmp/*BASELINE.tmp /tmp/*list.tmp
echo "Baseline check completed on $(date +"%m-%d-%Y") at $(date +"%H:%M:%S")" | tee -a /var/log/baseline.log
echo -e \\n | tee -a /var/log/baseline.log
echo "####################################################################" | tee -a /var/log/baseline.log
echo -e \\n | tee -a /var/log/baseline.log
chmod 640 /var/log/baseline.log
chown root:root /var/log/baseline.log
STOP_HERE
chmod 700 /etc/cron.weekly/baseline_checker.sh
chown root:root /etc/cron.weekly/baseline_checker.sh
|
Create a Baseline For SUID Files
[ref]rule
A 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.
Identifiers:
GEN002400 References:
DCSL-1, 318 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
# Generate a suid file baseline
find / -perm -4000 -type f 2>/dev/null | sort > /var/log/suid-file-list
chmod 640 /var/log/suid-file-list
chown root:root /var/log/suid-file-list
# Generate a weekly cron job to check the suid file baseline and report differences
cat > /etc/cron.weekly/baseline_checker.sh <<'STOP_HERE'
#!/bin/sh
echo "Baseline check started on $(date +"%m-%d-%Y") at $(date +"%H:%M:%S")" | tee -a /var/log/baseline.log
echo -e \\n | tee -a /var/log/baseline.log
echo "Gathering current baseline." | tee -a /var/log/baseline.log
echo -e \\n | tee -a /var/log/baseline.log
rm -f /tmp/*BASELINE.tmp /tmp/*list.tmp
find / -perm -4000 2>/dev/null | sort > /tmp/suid-file-list.tmp
find / -perm -2000 2>/dev/null | sort > /tmp/sgid-file-list.tmp
find / -type b -o -type c 2>/dev/null | sort > /tmp/device-file-list.tmp
echo "Comparing the current baseline with the last known good configuration." | tee -a /var/log/baseline.log
echo -e \\n | tee -a /var/log/baseline.log
diff /var/log/suid-file-list /tmp/suid-file-list.tmp > /tmp/SUID_BASELINE.tmp
diff /var/log/sgid-file-list /tmp/sgid-file-list.tmp > /tmp/SGID_BASELINE.tmp
diff /var/log/device-file-list /tmp/device-file-list.tmp > /tmp/DEVICE_BASELINE.tmp
if [ -s /tmp/SUID_BASELINE.tmp ]; then
if [ $(grep -c "^>" /tmp/SUID_BASELINE.tmp) != 0 ]; then
echo "The following files were detected to have the suid bit added:" | tee -a /var/log/baseline.log
echo -e \\n | tee -a /var/log/baseline.log
grep "^>" /tmp/SUID_BASELINE.tmp | awk '{ print $2 }' | tee -a /var/log/baseline.log
echo -e \\n | tee -a /var/log/baseline.log
fi
if [ $(grep -c "^<" /tmp/SUID_BASELINE.tmp) != 0 ]; then
echo "The following files were detected to have the suid bit removed:" | tee -a /var/log/baseline.log
echo -e \\n | tee -a /var/log/baseline.log
grep "^<" /tmp/SUID_BASELINE.tmp | awk '{ print $2 }' | tee -a /var/log/baseline.log
echo -e \\n | tee -a /var/log/baseline.log
fi
fi
if [ -s /tmp/SGID_BASELINE.tmp ]; then
if [ $(grep -c "^>" /tmp/SGID_BASELINE.tmp) != 0 ]; then
echo "The following files were detected to have the sgid bit added:" | tee -a /var/log/baseline.log
echo -e \\n | tee -a /var/log/baseline.log
grep "^>" /tmp/SGID_BASELINE.tmp | awk '{ print $2 }' | tee -a /var/log/baseline.log
echo -e \\n | tee -a /var/log/baseline.log
fi
if [ $(grep -c "^<" /tmp/SGID_BASELINE.tmp) != 0 ]; then
echo "The following files were detected to have the sgid bit removed:" | tee -a /var/log/baseline.log
echo -e \\n | tee -a /var/log/baseline.log
grep "^<" /tmp/SGID_BASELINE.tmp | awk '{ print $2 }' | tee -a /var/log/baseline.log
echo -e \\n | tee -a /var/log/baseline.log
fi
fi
if [ -s /tmp/DEVICE_BASELINE.tmp ]; then
if [ $(grep -c "^>" /tmp/DEVICE_BASELINE.tmp) != 0 ]; then
echo "The following device files were detected to have been added:" | tee -a /var/log/baseline.log
echo -e \\n | tee -a /var/log/baseline.log
grep "^>" /tmp/DEVICE_BASELINE.tmp | awk '{ print $2 }' | tee -a /var/log/baseline.log
echo -e \\n | tee -a /var/log/baseline.log
fi
if [ $(grep -c "^<" /tmp/DEVICE_BASELINE.tmp) != 0 ]; then
echo "The following device files were detected to have removed:" | tee -a /var/log/baseline.log
echo -e \\n | tee -a /var/log/baseline.log
grep "^<" /tmp/DEVICE_BASELINE.tmp | awk '{ print $2 }' | tee -a /var/log/baseline.log
echo -e \\n | tee -a /var/log/baseline.log
fi
fi
rm -f /tmp/*BASELINE.tmp /tmp/*list.tmp
echo "Baseline check completed on $(date +"%m-%d-%Y") at $(date +"%H:%M:%S")" | tee -a /var/log/baseline.log
echo -e \\n | tee -a /var/log/baseline.log
echo "####################################################################" | tee -a /var/log/baseline.log
echo -e \\n | tee -a /var/log/baseline.log
chmod 640 /var/log/baseline.log
chown root:root /var/log/baseline.log
STOP_HERE
chmod 700 /etc/cron.weekly/baseline_checker.sh
chown root:root /etc/cron.weekly/baseline_checker.sh
|
File Permissions and Masks
[ref]groupTraditional 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.
Several of the commands in this section search filesystems
for files or directories with certain characteristics, and are
intended to be run on every local partition on a given system.
When the variable PART appears in one of the commands below,
it means that the command is intended to be run repeatedly, with the
name of each local partition substituted for PART in turn.
The following command prints a list of all xfs partitions on the local
system, which is the default filesystem for Red Hat Enterprise Linux
7 installations:
$ 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 Options
[ref]groupSystem partitions can be mounted with certain options
that limit what files on those partitions can do. These options
are set in the /etc/fstab configuration file, and can be
used to make certain types of malicious behavior more difficult. |
contains 2 rules |
Add nodev Option to Removable Media Partitions
[ref]ruleThe nodev mount option prevents files from being
interpreted as character or block devices.
Legitimate character and block devices should exist only in
the /dev directory on the root partition or within chroot
jails built for system services.
Add the nodev option to the fourth column of
/etc/fstab for the line which controls mounting of
any removable media partitions.
Rationale: The only legitimate location for device files is the /dev directory
located on the root partition. An exception to this is chroot jails, and it is
not advised to set nodev on partitions which contain their root
filesystems. Identifiers:
GEN002430 References:
ECSC-1, 366 |
Add nosuid Option to Removable Media Partitions
[ref]ruleThe nosuid mount option prevents set-user-identifier (suid)
and set-group-identifier (sgid) permissions from taking effect. These permissions
allow users to execute binaries with the same permissions as the owner and group
of the file respectively. Users should not be allowed to introduce suid and guid
files into the system via partitions mounted from removeable media.
Add the nosuid option to the fourth column of
/etc/fstab for the line which controls mounting of
any removable media partitions.
Rationale: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. Identifiers:
GEN002420 References:
ECLP-1, 225 |
Restrict Dynamic Mounting and Unmounting of
Filesystems
[ref]groupLinux 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.
This command can be used to list the types of filesystems that are
available to the currently executing kernel:
# 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 Driver
[ref]rule
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 usb-storage
kernel module from being loaded, add the following line to a file in the directory /etc/modprobe.d :
install usb-storage /bin/true
This 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. Identifiers:
GEN008480 References:
ECSC-1, 366 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ -d /etc/modprobe.d/ ]; then
echo "install usb-storage /bin/true" >> /etc/modprobe.d/disabled_modules.conf
else
echo "install usb-storage /bin/true" >> /etc/modprobe.conf
fi
|
Disable Kernel Support for USB via Bootloader Configuration
[ref]rule
All USB support can be disabled by adding the nousb
argument to the kernel's boot loader configuration. To do so,
append "nousb" to the kernel line in /etc/grub.conf as shown:
kernel /vmlinuz-VERSION ro vga=ext root=/dev/VolGroup00/LogVol00 rhgb quiet nousb
WARNING: 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.
Identifiers:
GEN008460 References:
ECSC-1, 366 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
USB_KEYBOARD=$(grep 'Product=' /proc/bus/usb/devices 2>/dev/null| egrep -ic '(ps2 to usb adapter|keyboard|kvm|sc reader)')
if [ "${USB_KEYBOARD}" = "0" ]; then
sed -i '/^[ |\t]*kernel/s/$/ nousb/' /boot/grub/grub.conf
# else
# A USB keyboard was detected so this fix has been skipped.
fi
|
Disable the Automounter
[ref]ruleThe autofs daemon mounts and unmounts filesystems, such as user
home directories shared via NFS, on demand. In addition, autofs can be used to handle
removable media, and the default configuration provides the cdrom device as /misc/cd .
However, this method of providing access to removable media is not common, so autofs
can almost always be disabled if NFS is not in use. Even if NFS is required, it may be
possible to configure filesystem mounts statically by editing /etc/fstab
rather than relying on the automounter.
The autofs service can be disabled with the following command:
$ sudo chkconfig autofs off
Rationale:Disabling the automounter permits the administrator to
statically control filesystem mounting through /etc/fstab .
Identifiers:
GEN008440 References:
ECSC-1, 366 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | configure |
---|
#
# Disable autofs for all run levels
#
/sbin/chkconfig --level 0123456 autofs off
#
# Stop autofs if currently running
#
/sbin/service autofs stop 1>/dev/null
|
Verify Permissions on Important Files and
Directories
[ref]groupPermissions 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 Credentials
[ref]groupThe default restrictive permissions for files which act as
important security databases such as passwd , shadow ,
group , and gshadow files must be maintained. Many utilities
need read access to the passwd file in order to function properly, but
read access to the shadow file allows malicious attacks against system
passwords, and should never be enabled. |
contains 15 rules |
Verify User Who Owns shadow File
[ref]rule
To properly set the owner of /etc/shadow , run the command:
$ sudo chown root /etc/shadow
Rationale:The /etc/shadow file contains the list of local
system accounts and stores password hashes. Protection of this file is
critical for system security. Failure to give ownership of this file
to root provides the designated owner with access to sensitive information
which could weaken the system security posture. Identifiers:
GEN001400 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chown root /etc/shadow
|
Verify Permissions on shadow File
[ref]rule
To properly set the permissions of /etc/shadow , run the command:
$ sudo chmod 0400 /etc/shadow
Rationale:The /etc/shadow file contains the list of local
system accounts and stores password hashes. Protection of this file is
critical for system security. Failure to give ownership of this file
to root provides the designated owner with access to sensitive information
which could weaken the system security posture. Identifiers:
GEN001420 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | configure |
---|
chmod 0400 /etc/shadow
|
Verify Extended ACLs on shadow File
[ref]ruleNo extended ACLs should be applied. Rationale:The /etc/shadow file contains the list of local
system accounts and stores password hashes. Protection of this file is
critical for system security. Failure to give ownership of this file
to root provides the designated owner with access to sensitive information
which could weaken the system security posture. Identifiers:
GEN001430 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
setfacl --remove-all /etc/shadow
|
Verify User Who Owns group File
[ref]rule
To properly set the owner of /etc/group , run the command:
$ sudo chown root /etc/group
Rationale:The /etc/group file contains information regarding groups that are configured
on the system. Protection of this file is important for system security. Identifiers:
GEN001391 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | disable |
---|
chown root /etc/group
|
Verify Group Who Owns group File
[ref]rule
To properly set the group owner of /etc/group , run the command:
$ sudo chgrp root /etc/group
Rationale:The /etc/group file contains information regarding groups that are configured
on the system. Protection of this file is important for system security. Identifiers:
GEN001392 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | disable |
---|
chgrp root /etc/group
|
Verify Permissions on group File
[ref]rule
To properly set the permissions of /etc/group , run the command:
$ sudo chmod 644 /etc/group
Rationale:The /etc/group file contains information regarding groups that are configured
on the system. Protection of this file is important for system security. Identifiers:
GEN001393 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | disable |
---|
chmod 0644 /etc/group
|
Verify Extended ACLs on group File
[ref]ruleNo extended ACLs should be applied. Rationale:The /etc/group file contains the list of local
system accounts and stores password hashes. Protection of this file is
critical for system security. Failure to give ownership of this file
to root provides the designated owner with access to sensitive information
which could weaken the system security posture. Identifiers:
GEN001394 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
setfacl --remove-all /etc/group
|
Verify User Who Owns gshadow File
[ref]rule
To properly set the owner of /etc/gshadow , run the command:
$ sudo chown root /etc/gshadow
Rationale:The /etc/gshadow file contains group password hashes. Protection of this file
is critical for system security. Identifiers:
GEN000000-LNX001431 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | disable |
---|
chown root /etc/gshadow
|
Verify Group Who Owns gshadow File
[ref]rule
To properly set the group owner of /etc/gshadow , run the command:
$ sudo chgrp root /etc/gshadow
Rationale:The /etc/gshadow file contains group password hashes. Protection of this file
is critical for system security. Identifiers:
GEN000000-LNX001432 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | disable |
---|
chgrp root /etc/gshadow
|
Verify Permissions on gshadow File
[ref]rule
To properly set the permissions of /etc/gshadow , run the command:
$ sudo chmod 0400 /etc/gshadow
Rationale:The /etc/gshadow file contains group password hashes. Protection of this file
is critical for system security. Identifiers:
GEN000000-LNX001433 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | disable |
---|
chmod 0400 /etc/gshadow
|
Verify Extended ACLs on gshadow File
[ref]ruleNo extended ACLs should be applied. Rationale:The /etc/gshadow file contains the list of local
system accounts and stores password hashes. Protection of this file is
critical for system security. Failure to give ownership of this file
to root provides the designated owner with access to sensitive information
which could weaken the system security posture. Identifiers:
GEN000000-LNX001434 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
setfacl --remove-all /etc/gshadow
|
Verify User Who Owns passwd File
[ref]rule
To properly set the owner of /etc/passwd , run the command:
$ sudo chown root /etc/passwd
Rationale:The /etc/passwd file contains information about the users that are configured on
the system. Protection of this file is critical for system security. Identifiers:
GEN001378 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | disable |
---|
chown root /etc/passwd
|
Verify Group Who Owns passwd File
[ref]rule
To properly set the group owner of /etc/passwd , run the command:
$ sudo chgrp root /etc/passwd
Rationale:The /etc/passwd file contains information about the users that are configured on
the system. Protection of this file is critical for system security. Identifiers:
GEN001379 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | disable |
---|
chgrp root /etc/passwd
|
Verify Permissions on passwd File
[ref]rule
To properly set the permissions of /etc/passwd , run the command:
$ sudo chmod 0644 /etc/passwd
Rationale:If the /etc/passwd file is writable by a group-owner or the
world the risk of its compromise is increased. The file contains the list of
accounts on the system and associated information, and protection of this file
is critical for system security. Identifiers:
GEN001380 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | disable |
---|
chmod 0644 /etc/passwd
|
Verify Extended ACLs on passwd File
[ref]ruleNo extended ACLs should be applied. Rationale:The /etc/passwd file contains the list of local
system accounts and stores password hashes. Protection of this file is
critical for system security. Failure to give ownership of this file
to root provides the designated owner with access to sensitive information
which could weaken the system security posture. Identifiers:
GEN001390 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
setfacl --remove-all /etc/passwd
|
Verify File Permissions Within Some Important Directories
[ref]groupSome 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 Permissions
[ref]ruleSystem-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/lib64
Kernel 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 FILE
Rationale: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 Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
find /lib /usr/lib -follow -perm -20 -o -perm -2 2>/dev/null | xargs chmod go-w
|
Verify Extended ACLs on Shared Library Files
[ref]ruleNo extended ACLs should be applied. Rationale:Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
setfacl -RLb --remove-all /usr/lib/* /lib/*
|
Verify that System Executables Have Restrictive Permissions
[ref]rule
System executables are stored in the following directories by default:
/bin
/sbin
/usr/bin
/usr/libexec
/usr/local/bin
/usr/local/sbin
/usr/sbin
All 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 FILE
Rationale: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 Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | disable |
---|
find /etc /bin /usr/bin /usr/lbin /usr/usb /sbin /usr/sbin -follow -perm -20 -o -perm -2 2>/dev/null | xargs chmod go-w
|
Verify Extended ACLs on Shared Binary Files
[ref]ruleNo extended ACLs should be applied. Rationale:Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
setfacl -RLb /etc /bin /usr/bin /usr/lbin /usr/usb /sbin /usr/sbin 2>/dev/null
|
Verify that System Executables Have Root User Ownership
[ref]rule
System executables are stored in the following directories by default:
/bin
/sbin
/usr/bin
/usr/libexec
/usr/local/bin
/usr/local/sbin
/usr/sbin
All 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 FILE
Rationale: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 Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | disable |
---|
find /bin/ \
/usr/bin/ \
/usr/local/bin/ \
/sbin/ \
/usr/sbin/ \
/usr/local/sbin/ \
/usr/libexec \
\! -user root -execdir chown root {} \;
|
Verify that System Executables Have Root Group Ownership
[ref]rule
System executables are stored in the following directories by default:
/bin
/sbin
/usr/bin
/usr/libexec
/usr/local/bin
/usr/local/sbin
/usr/sbin
All 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 FILE
Rationale: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 Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
find /etc /bin /usr/bin /usr/lbin /usr/usb /sbin /usr/sbin -follow -gid +499 2>/dev/null | xargs chown :root
|
Verify User Who Owns aliases File
[ref]rule
To properly set the owner of /etc/aliases , run the command:
$ sudo chown root /etc/aliases
Rationale:Identifiers:
GEN004400 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chown root /etc/postfix/aliases /etc/postfix/aliases.db /etc/aliases /etc/aliases.db 2>/dev/null
|
Verify Group Who Owns aliases File
[ref]rule
To properly set the group owner of /etc/aliases , run the command:
$ sudo chgrp root /etc/aliases
Rationale:Identifiers:
GEN004410 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chown :root /etc/postfix/aliases /etc/postfix/aliases.db /etc/aliases /etc/aliases.db 2>/dev/null
|
Verify Permissions on aliases File
[ref]rule
To properly set the permissions of /etc/aliases , run the command:
$ sudo chmod 0644 /etc/aliases
Rationale:Identifiers:
GEN004420 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chmod 644 /etc/postfix/aliases /etc/postfix/aliases.db /etc/aliases /etc/aliases.db 2>/dev/null
|
Verify Extended ACLs on Aliases
[ref]ruleNo extended ACLs should be applied. Rationale:Identifiers:
GEN004430 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
setfacl --remove-all /etc/aliases /etc/aliases.db /etc/postfix/aliases /etc/postfix/aliases.db 2>/dev/null
|
Verify User Who Owns aliases File
[ref]rule
To properly set the owner of /etc/aliases , run the command:
$ sudo chown root /etc/aliases
Rationale:Identifiers:
GEN004360 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
grep "/" /etc/aliases /etc/aliases.db | grep -v "#" | grep ^/ | sed 's/.*[\s|\t]\//\//' | xargs chown root
|
Verify Group Who Owns aliases File
[ref]rule
To properly set the group owner of /etc/aliases , run the command:
$ sudo chgrp root /etc/aliases
Rationale:Identifiers:
GEN004370 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
grep "/" /etc/aliases /etc/aliases.db | grep -v "#" | grep ^/ | sed 's/.*[\s|\t]\//\//' | xargs chown :root
|
Verify Permissions on aliases File
[ref]rule
To properly set the permissions of /etc/aliases , run the command:
$ sudo chmod 0755 /etc/aliases
Rationale:Identifiers:
GEN004380 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
grep "/" /etc/aliases /etc/aliases.db | grep -v "#" | grep ^/ | sed 's/.*[\s|\t]\//\//' | xargs chmod 755
|
Verify Extended ACLs on Aliases Files
[ref]ruleNo extended ACLs should be applied. Rationale:Identifiers:
GEN004390 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
grep / /etc/aliases | grep -v "#" | sed s/^[^\/]*// | xargs setfacl --remove-all
|
Verify User Who Owns Audio Device Files
[ref]rule
To properly set the owner of /dev/audio , run the command:
$ sudo chown root /dev/audio
Rationale:Identifiers:
GEN002340 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chown root /dev/audio* /dev/snd/*
|
Verify Group Who Owns Audio Device Files
[ref]rule
To properly set the group owner of /dev/audio , run the command:
$ sudo chgrp root /dev/audio
Rationale:Identifiers:
GEN002360 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chown :root /dev/audio* /dev/snd/*
if [[ "`uname -r`" = "2.6.9"* ]]; then
sed -i 's/\(^audio\*:[a-z]*:\)[a-z]*:/\1sys:/' /etc/udev/permissions.d/50-udev.permissions
elif [[ "`uname -r`" = "2.6.18"* ]]; then
sed -i '/^<console> [0-9]* <sound>/s/<sound>.*/<sound> 0600 root.root/' /etc/security/console.perms.d/50-default.perms
fi
|
Verify Permissions on Audio Device Files
[ref]rule
To properly set the permissions of /dev/audio , run the command:
$ sudo chmod 0660 /dev/audio
Rationale:Identifiers:
GEN002320 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chmod 660 /dev/audio* /dev/snd/*
sed -i '/[audio|snd]/s/MODE="[0-9]*"/MODE="660"/' /etc/udev/rules.d/50-udev.rules
|
Verify Extended ACLs on Audio Device Files
[ref]ruleNo extended ACLs should be applied. Rationale:Identifiers:
GEN002330 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
setfacl --remove-all /dev/audio* /dev/snd/* 2>/dev/null
|
Verify User Who Owns Audit Log Files
[ref]rule
To properly set the owner of /var/log/audit/audit.log , run the command:
$ sudo chown root /var/log/audit/audit.log
Rationale:Identifiers:
GEN002680 References:
ECTP-1, 162 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ -e /etc/audit/auditd.conf ]; then
grep ^log_file /etc/audit/auditd.conf | awk '{ print $3 }' | xargs chown root
if [ -e /etc/auditd.conf ]; then
grep ^log_file /etc/auditd.conf | awk '{ print $3 }' | xargs chown root
fi
|
Verify Group Who Owns Audit Log Files
[ref]rule
To properly set the group owner of /var/log/audit/audit.log , run the command:
$ sudo chgrp root /var/log/audit/audit.log
Rationale:Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ -e /etc/audit/auditd.conf ]; then
grep ^log_file /etc/audit/auditd.conf | awk '{ print $3 }' | xargs chown :root
if [ -e /etc/auditd.conf ]; then
grep ^log_file /etc/auditd.conf | awk '{ print $3 }' | xargs chown :root
fi
|
Verify Permissions on Audit Log Files
[ref]rule
System 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_file
Rationale:
If users can write to audit logs, audit trails can be modified or destroyed.
Identifiers:
GEN002700 References:
ECTP-1, 163 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ -e /etc/audit/auditd.conf ]; then
grep ^log_file /etc/audit/auditd.conf | awk '{ print $3 }' | xargs chmod 640
elif [ -e /etc/auditd.conf ]; then
grep ^log_file /etc/auditd.conf | awk '{ print $3 }' | xargs chmod 640
fi
|
Verify Extended ACLs on Audit Log Files
[ref]ruleNo extended ACLs should be applied. Rationale:Identifiers:
GEN002710 References:
ECTP-1, 163 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ -e /etc/audit/auditd.conf ]; then
grep "^log_file" /etc/audit/auditd.conf | sed s/^[^\/]*// | xargs setfacl --remove-all
elif [ -e /etc/auditd.conf ]; then
grep "^log_file" /etc/auditd.conf | sed s/^[^\/]*// | xargs setfacl --remove-all
fi
|
Verify User Who Owns Audit Tool Files
[ref]rule
To properly set the owner of /sbin/au* , run the command:
$ sudo chown root /sbin/au*
Rationale:Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chown root /sbin/auditctl /sbin/auditd /sbin/ausearch /sbin/aureport /sbin/autrace /sbin/audispd
|
Verify Group Who Owns Audit Tool Files
[ref]rule
To properly set the group owner of /sbin/au* , run the command:
$ sudo chgrp root /sbin/au*
Rationale:Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chown :root /sbin/auditctl /sbin/auditd /sbin/ausearch /sbin/aureport /sbin/autrace /sbin/audispd
|
Verify Permissions on Audit Tool Files
[ref]rule
To properly set the permissions of /sbin/au* , run the command:
$ sudo chmod 0750 /sbin/au*
Rationale:Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chmod 750 /sbin/auditctl /sbin/auditd /sbin/ausearch /sbin/aureport /sbin/autrace /sbin/audispd
|
Verify Extended ACLs on Audit Tool Files
[ref]ruleNo extended ACLs should be applied. Rationale:Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
setfacl --remove-all /sbin/auditctl /sbin/auditd /sbin/ausearch /sbin/aureport /sbin/autrace /sbin/audispd
|
Verify User Who Owns Traceroute
[ref]rule
To properly set the owner of /bin/traceroute , run the command:
$ sudo chown root /bin/traceroute
Rationale:Identifiers:
GEN003960 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chown root /bin/traceroute
|
Verify Group Who Owns Traceroute
[ref]rule
To properly set the group owner of /bin/traceroute , run the command:
$ sudo chgrp root /bin/traceroute
Rationale:Identifiers:
GEN003980 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chown :root /bin/traceroute
|
Verify Permissions on Traceroute
[ref]rule
To properly set the permissions of /bin/traceroute , run the command:
$ sudo chmod 0700 /bin/traceroute
Rationale:Identifiers:
GEN004000 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | configure |
---|
chmod 700 /bin/traceroute
|
Verify Extended ACLs on Traceroute
[ref]ruleNo extended ACLs should be applied. Rationale:Identifiers:
GEN004010 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
setfacl --remove-all /bin/traceroute
|
Verify User Who Owns Core Dump Directory
[ref]rule
To properly set the owner of /var/crash , run the command:
$ sudo chown root /var/crash
Rationale:Identifiers:
GEN003520 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
grep path.*/ /etc/kdump.conf | awk '{ print $2 }' | chown root
|
Verify Group Who Owns Core Dump Directory
[ref]rule
To properly set the group owner of /var/crash , run the command:
$ sudo chgrp root /var/crash
Rationale:Identifiers:
GEN003521 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
grep path.*/ /etc/kdump.conf | awk '{ print $2 }' | xargs chown :root
|
Verify Permissions on Core Dump Directory
[ref]rule
To properly set the permissions of /var/crash , run the command:
$ sudo chmod 0700 /var/crash
Rationale:Identifiers:
GEN003522 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
grep path.*/ /etc/kdump.conf | awk '{ print $2 }' | xargs chmod 700
|
Verify Extended ACLs on Core Dump Directory
[ref]ruleNo extended ACLs should be applied. Rationale:Identifiers:
GEN003523 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
grep path /etc/kdump.conf | grep -v "#" | awk '{ print $2 }' | xargs setfacl --remove-all
|
Verify Permissions on Cron Log Files
[ref]rule
To properly set the permissions of /var/log/cron , run the command:
$ sudo chmod 0600 /var/log/cron
Rationale:Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
grep ^cron /etc/syslog.conf | awk '{ print $2 }' | xargs chmod 0600
|
Verify Extended ACLs on Cron Log Files
[ref]ruleNo extended ACLs should be applied. Rationale:Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
grep cron /etc/syslog.conf | grep -v "#" | awk '{ print $2 }' | xargs setfacl --remove-all
|
Verify User Who Owns Crontab Directories
[ref]rule
To properly set the owner of /var/spool/cron , run the command:
$ sudo chown root /var/spool/cron
Rationale:Identifiers:
GEN003120 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chown root /etc/cron.d /etc/cron.daily /etc/cron.hourly /etc/cron.monthly /etc/cron.weekly /var/spool/cron 2>/dev/null
|
Verify Group Who Owns Crontab Directories
[ref]rule
To properly set the group owner of /var/spool/cron , run the command:
$ sudo chgrp root /var/spool/cron
Rationale:Identifiers:
GEN003140 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chown :root /etc/cron.d /etc/cron.daily /etc/cron.hourly /etc/cron.monthly /etc/cron.weekly /var/spool/cron 2>/dev/null
|
Verify Permissions on Crontab Directories
[ref]rule
To properly set the permissions of /var/spool/cron , run the command:
$ sudo chmod 0755 /var/spool/cron
Rationale:Identifiers:
GEN003100 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chmod 755 /etc/cron.d /etc/cron.daily /etc/cron.hourly /etc/cron.monthly /etc/cron.weekly /var/spool/cron 2>/dev/null
|
Verify Extended ACLs on Crontab Directories
[ref]ruleNo extended ACLs should be applied. Rationale:Identifiers:
GEN003110 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
setfacl --remove-all /etc/cron.d /etc/crontab /etc/cron.daily /etc/cron.hourly /etc/cron.monthly /etc/cron.weekly /var/spool/cron 2>/dev/null
|
Verify User Who Owns Crontab Files
[ref]rule
To properly set the owner of /etc/cron* , run the command:
$ sudo chown root /etc/cron*
Rationale:Identifiers:
GEN003040 References:
DCSL-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chown root /etc/crontab /etc/cron.d/* /var/spool/cron/* 2>/dev/null
|
Verify Group Who Owns Crontab Files
[ref]rule
To properly set the group owner of /etc/cron* , run the command:
$ sudo chgrp root /etc/cron*
Rationale:Identifiers:
GEN003050 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chown :root /etc/crontab /etc/cron.d/* /var/spool/cron/* 2>/dev/null
|
Verify Permissions on Crontab Files
[ref]rule
To properly set the permissions of /etc/cron* , run the command:
$ sudo chmod 0600 /etc/cron*
Rationale:Identifiers:
GEN003080 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chmod 600 /etc/crontab /etc/cron.d/* /var/spool/cron/* 2>/dev/null
|
Verify Extended ACLs on Crontab Files
[ref]ruleNo extended ACLs should be applied. Rationale:Identifiers:
GEN003090 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
find /etc/cron.d /etc/crontab /etc/cron.daily /etc/cron.hourly /etc/cron.monthly /etc/cron.weekly /var/spool/cron -type f 2>/dev/null | xargs setfacl --remove-all
|
Verify Permissions on Cron Files
[ref]rule
To properly set the permissions of /etc/cron* , run the command:
$ sudo chmod 0700 /etc/cron*
Rationale:Identifiers:
GEN003080-2 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chmod 0700 /etc/cron.daily/* /etc/cron.hourly/* /etc/cron.monthly/* /etc/cron.weekly/* 2>/dev/null
|
Verify User Who Owns at.allow
[ref]rule
To properly set the owner of /etc/at.allow , run the command:
$ sudo chown root /etc/at.allow
Rationale:Identifiers:
GEN003460 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chown root /etc/at.allow
|
Verify Group Who Owns at.allow
[ref]rule
To properly set the group owner of /etc/at.allow , run the command:
$ sudo chgrp root /etc/at.allow
Rationale:Identifiers:
GEN003470 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chown :root /etc/at.allow
|
Verify Permissions on at.allow
[ref]rule
To properly set the permissions of /etc/at.allow , run the command:
$ sudo chmod 0600 /etc/at.allow
Rationale:Identifiers:
GEN003340 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | configure |
---|
chmod 0600 /etc/at.allow
|
Verify Extended ACLs on at.allow
[ref]ruleNo extended ACLs should be applied. Rationale:Identifiers:
GEN003245 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
setfacl --remove-all /etc/at.allow
|
Verify User Who Owns at.deny
[ref]rule
To properly set the owner of /etc/at.deny , run the command:
$ sudo chown root /etc/at.deny
Rationale:Identifiers:
GEN003480 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chown root /etc/at.deny
|
Verify Group Who Owns at.deny
[ref]rule
To properly set the group owner of /etc/at.deny , run the command:
$ sudo chgrp root /etc/at.deny
Rationale:Identifiers:
GEN003490 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chown :root /etc/at.deny
|
Verify Permissions on at.deny
[ref]rule
To properly set the permissions of /etc/at.deny , run the command:
$ sudo chmod 0600 /etc/at.deny
Rationale:Identifiers:
GEN003252 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | configure |
---|
chmod 0600 /etc/at.deny
|
Verify Extended ACLs on at.deny
[ref]ruleNo extended ACLs should be applied. Rationale:Identifiers:
GEN003255 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
setfacl --remove-all /etc/at.deny
|
Verify User Who Owns cron.allow
[ref]rule
To properly set the owner of /etc/cron.allow , run the command:
$ sudo chown root /etc/cron.allow
Rationale:Identifiers:
GEN003240 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chown root /etc/cron.allow
|
Verify Group Who Owns cron.allow
[ref]rule
To properly set the group owner of /etc/cron.allow , run the command:
$ sudo chgrp root /etc/cron.allow
Rationale:Identifiers:
GEN003250 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chown :root /etc/cron.allow
|
Verify Permissions on cron.allow
[ref]rule
To properly set the permissions of /etc/cron.allow , run the command:
$ sudo chmod 0600 /etc/cron.allow
Rationale:Identifiers:
GEN002980 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | configure |
---|
chmod 0600 /etc/cron.allow
|
Verify Extended ACLs on cron.allow
[ref]ruleNo extended ACLs should be applied. Rationale:Identifiers:
GEN002990 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
setfacl --remove-all /etc/cron.allow
|
Verify User Who Owns cron.deny
[ref]rule
To properly set the owner of /etc/cron.deny , run the command:
$ sudo chown root /etc/cron.deny
Rationale:Identifiers:
GEN003260 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chown root /etc/cron.deny
|
Verify Group Who Owns cron.deny
[ref]rule
To properly set the group owner of /etc/cron.deny , run the command:
$ sudo chgrp root /etc/cron.deny
Rationale:Identifiers:
GEN003270 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chown :root /etc/cron.deny
|
Verify Permissions on cron.deny
[ref]rule
To properly set the permissions of /etc/cron.deny , run the command:
$ sudo chmod 0600 /etc/cron.deny
Rationale:Identifiers:
GEN003200 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | configure |
---|
chmod 0600 /etc/cron.deny
|
Verify Extended ACLs on cron.deny
[ref]ruleNo extended ACLs should be applied. Rationale:Identifiers:
GEN003210 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
setfacl --remove-all /etc/cron.deny
|
Verify User Who Owns printers.conf
[ref]rule
To properly set the owner of /etc/cups/printers.conf , run the command:
$ sudo chown root /etc/cups/printers.conf
Rationale:Identifiers:
GEN003920 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chown root /etc/cups/printers.conf
|
Verify Group Who Owns printers.conf
[ref]rule
To properly set the group owner of /etc/cups/printers.conf , run the command:
$ sudo chgrp root /etc/cups/printers.conf
Rationale:Identifiers:
GEN003930 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chown :root /etc/cups/printers.conf
|
Verify Permissions on printers.conf
[ref]rule
To properly set the permissions of /etc/cups/printers.conf , run the command:
$ sudo chmod 0644 /etc/cups/printers.conf
Rationale:Identifiers:
GEN003940 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | configure |
---|
chmod 0644 /etc/cups/printers.conf
|
Verify Extended ACLs on printers.conf
[ref]ruleNo extended ACLs should be applied. Rationale:Identifiers:
GEN003950 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
setfacl --remove-all /etc/cups/printers.conf
|
Verify User Who Owns Exports
[ref]rule
To properly set the owner of /etc/exports , run the command:
$ sudo chown root /etc/exports
Rationale:Identifiers:
GEN005740 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chown root /etc/exports
|
Verify Group Who Owns Exports
[ref]rule
To properly set the group owner of /etc/exports , run the command:
$ sudo chgrp root /etc/exports
Rationale:Identifiers:
GEN005750 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chown :root /etc/exports
|
Verify Permissions on Exports
[ref]rule
To properly set the permissions of /etc/exports , run the command:
$ sudo chmod 0644 /etc/exports
Rationale:Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | configure |
---|
chmod 0644 /etc/exports
|
Verify Extended ACLs on Exports
[ref]ruleNo extended ACLs should be applied. Rationale:Identifiers:
GEN005770 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
setfacl --remove-all /etc/exports
|
Verify User Who Owns Hosts
[ref]rule
To properly set the owner of /etc/hosts , run the command:
$ sudo chown root /etc/hosts
Rationale:Identifiers:
GEN001366 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chown root /etc/hosts
|
Verify Group Who Owns Hosts
[ref]rule
To properly set the group owner of /etc/hosts , run the command:
$ sudo chgrp root /etc/hosts
Rationale:Identifiers:
GEN001367 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chown :root /etc/hosts
|
Verify Permissions on Hosts
[ref]rule
To properly set the permissions of /etc/hosts , run the command:
$ sudo chmod 0644 /etc/hosts
Rationale:Identifiers:
GEN001368 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | configure |
---|
chmod 0644 /etc/hosts
|
Verify Extended ACLs on Hosts
[ref]ruleNo extended ACLs should be applied. Rationale:Identifiers:
GEN001369 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
setfacl --remove-all /etc/hosts
|
Verify User Who Owns ldap.conf
[ref]rule
To properly set the owner of /etc/ldap.conf , run the command:
$ sudo chown root /etc/ldap.conf
Rationale:Identifiers:
GEN008080 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chown root /etc/ldap.conf
|
Verify Group Who Owns ldap.conf
[ref]rule
To properly set the group owner of /etc/ldap.conf , run the command:
$ sudo chgrp root /etc/ldap.conf
Rationale:Identifiers:
GEN008100 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chown :root /etc/ldap.conf
|
Verify Permissions on ldap.conf
[ref]rule
To properly set the permissions of /etc/ldap.conf , run the command:
$ sudo chmod 0644 /etc/ldap.conf
Rationale:Identifiers:
GEN008060 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | configure |
---|
chmod 0644 /etc/ldap.conf
|
Verify Extended ACLs on ldap.conf
[ref]ruleNo extended ACLs should be applied. Rationale:Identifiers:
GEN008120 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
setfacl --remove-all /etc/ldap.conf
|
Verify Permissions on infeed.conf
[ref]rule
To properly set the permissions of /etc/news/infeed.conf , run the command:
$ sudo chmod 0600 /etc/news/infeed.conf
Rationale:Identifiers:
GEN006280 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | configure |
---|
chmod 0600 /etc/news/infeed.conf
|
Verify Extended ACLs on infeed.conf
[ref]ruleNo extended ACLs should be applied. Rationale:Identifiers:
GEN006290 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
setfacl --remove-all /etc/news/infeed.conf
|
Verify Permissions on incoming.conf
[ref]rule
To properly set the permissions of /etc/news/incoming.conf , run the command:
$ sudo chmod 0600 /etc/news/incoming.conf
Rationale:Identifiers:
GEN006260 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | configure |
---|
chmod 0600 /etc/news/incoming.conf
|
Verify Extended ACLs on incoming.conf
[ref]ruleNo extended ACLs should be applied. Rationale:Identifiers:
GEN006270 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
setfacl --remove-all /etc/news/incoming.conf
|
Verify Extended ACLs on nnrp.access
[ref]ruleNo extended ACLs should be applied. Rationale:Identifiers:
GEN006310 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
setfacl --remove-all /etc/news/nnrp.access
|
Verify Permissions on passwd.nntp
[ref]rule
To properly set the permissions of /etc/news/passwd.nntp , run the command:
$ sudo chmod 0600 /etc/news/passwd.nntp
Rationale:Identifiers:
GEN006320 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | configure |
---|
chmod 0600 /etc/news/passwd.nntp
|
Verify Extended ACLs on passwd.nntp
[ref]ruleNo extended ACLs should be applied. Rationale:Identifiers:
GEN006330 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
setfacl --remove-all /etc/news/passwd.nntp
|
Verify User Who Owns nsswitch.conf
[ref]rule
To properly set the owner of /etc/nsswitch.conf , run the command:
$ sudo chown root /etc/nsswitch.conf
Rationale:Identifiers:
GEN001371 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chown root /etc/nsswitch.conf
|
Verify Group Who Owns nsswitch.conf
[ref]rule
To properly set the group owner of /etc/nsswitch.conf , run the command:
$ sudo chgrp root /etc/nsswitch.conf
Rationale:Identifiers:
GEN001372 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chown :root /etc/nsswitch.conf
|
Verify Permissions on nsswitch.conf
[ref]rule
To properly set the permissions of /etc/nsswitch.conf , run the command:
$ sudo chmod 0644 /etc/nsswitch.conf
Rationale:Identifiers:
GEN001373 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | configure |
---|
chmod 0644 /etc/nsswitch.conf
|
Verify Extended ACLs on nsswitch.conf
[ref]ruleNo extended ACLs should be applied. Rationale:Identifiers:
GEN001374 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
setfacl --remove-all /etc/nsswitch.conf
|
Verify User Who Owns ntp.conf
[ref]rule
To properly set the owner of /etc/ntp.conf , run the command:
$ sudo chown root /etc/ntp.conf
Rationale:Identifiers:
GEN000250 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chown root /etc/ntp.conf
|
Verify Group Who Owns ntp.conf
[ref]rule
To properly set the group owner of /etc/ntp.conf , run the command:
$ sudo chgrp root /etc/ntp.conf
Rationale:Identifiers:
GEN000251 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chown :root /etc/ntp.conf
|
Verify Permissions on ntp.conf
[ref]rule
To properly set the permissions of /etc/ntp.conf , run the command:
$ sudo chmod 0644 /etc/ntp.conf
Rationale:Identifiers:
GEN000252 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | configure |
---|
chmod 0640 /etc/ntp.conf
|
Verify Extended ACLs on ntp.conf
[ref]ruleNo extended ACLs should be applied. Rationale:Identifiers:
GEN000253 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
setfacl --remove-all /etc/ntp.conf
|
Verify User Who Owns resolv.conf
[ref]rule
To properly set the owner of /etc/resolv.conf , run the command:
$ sudo chown root /etc/resolv.conf
Rationale:Identifiers:
GEN001362 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chown root /etc/resolv.conf
|
Verify Group Who Owns resolv.conf
[ref]rule
To properly set the group owner of /etc/resolv.conf , run the command:
$ sudo chgrp root /etc/resolv.conf
Rationale:Identifiers:
GEN001363 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chown :root /etc/resolv.conf
|
Verify Permissions on resolv.conf
[ref]rule
To properly set the permissions of /etc/resolv.conf , run the command:
$ sudo chmod 0644 /etc/resolv.conf
Rationale:Identifiers:
GEN001364 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | configure |
---|
chmod 0644 /etc/resolv.conf
|
Verify Extended ACLs on resolv.conf
[ref]ruleNo extended ACLs should be applied. Rationale:Identifiers:
GEN001365 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
setfacl --remove-all /etc/resolv.conf
|
Verify User Who Owns smb.conf
[ref]rule
To properly set the owner of /etc/samba/smb.conf , run the command:
$ sudo chown root /etc/samba/smb.conf
Rationale:Identifiers:
GEN006100 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chown root /etc/samba/smb.conf
|
Verify Group Who Owns smb.conf
[ref]rule
To properly set the group owner of /etc/samba/smb.conf , run the command:
$ sudo chgrp root /etc/samba/smb.conf
Rationale:Identifiers:
GEN006120 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chown :root /etc/samba/smb.conf
|
Verify Permissions on smb.conf
[ref]rule
To properly set the permissions of /etc/samba/smb.conf , run the command:
$ sudo chmod 0644 /etc/samba/smb.conf
Rationale:Identifiers:
GEN006140 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chmod 0644 /etc/samba/smb.conf
|
Verify Extended ACLs on smb.conf
[ref]ruleNo extended ACLs should be applied. Rationale:Identifiers:
GEN006150 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
setfacl --remove-all /etc/samba/smb.conf
|
Verify User Who Owns Samba Password Files
[ref]rule
To properly set the owner of /etc/samba/passdb.tdb , run the command:
$ sudo chown root /etc/samba/passdb.tdb
Rationale:Identifiers:
GEN006160 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chown root /etc/samba/passdb.tdb /etc/samba/secrets.tdb
|
Verify Group Who Owns Samba Password Files
[ref]rule
To properly set the group owner of /etc/samba/passdb.tdb , run the command:
$ sudo chgrp root /etc/samba/passdb.tdb
Rationale:Identifiers:
GEN006180 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chown :root /etc/samba/passdb.tdb /etc/samba/secrets.tdb
|
Verify Permissions on Samba Password Files
[ref]rule
To properly set the permissions of /etc/samba/passdb.tdb , run the command:
$ sudo chmod 0600 /etc/samba/passdb.tdb
Rationale:Identifiers:
GEN006200 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chmod 0600 /etc/samba/passdb.tdb /etc/samba/secrets.tdb
|
Verify Extended ACLs on Samba Password Files
[ref]ruleNo extended ACLs should be applied. Rationale:Identifiers:
GEN006210 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
setfacl --remove-all /etc/samba/passdb.tdb /etc/samba/secrets.tdb
|
Verify User Who Owns securetty
[ref]rule
To properly set the owner of /etc/securetty , run the command:
$ sudo chown root /etc/securetty
Rationale:Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chown root /etc/securetty
|
Verify Group Who Owns securetty
[ref]rule
To properly set the group owner of /etc/securetty , run the command:
$ sudo chgrp root /etc/securetty
Rationale:Identifiers:
GEN000000-LNX00620 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chown :root /etc/securetty
|
Verify Permissions on securetty
[ref]rule
To properly set the permissions of /etc/securetty , run the command:
$ sudo chmod 0600 /etc/securetty
Rationale:Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | configure |
---|
chmod 0600 /etc/securetty
|
Verify User Who Owns access.conf
[ref]rule
To properly set the owner of /etc/access.conf , run the command:
$ sudo chown root /etc/access.conf
Rationale:Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chown root /etc/security/access.conf
|
Verify Group Who Owns access.conf
[ref]rule
To properly set the group owner of /etc/access.conf , run the command:
$ sudo chgrp root /etc/access.conf
Rationale:Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chown :root /etc/security/access.conf
|
Verify Permissions on access.conf
[ref]rule
To properly set the permissions of /etc/access.conf , run the command:
$ sudo chmod 0640 /etc/access.conf
Rationale:Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | configure |
---|
chmod 0640 /etc/security/access.conf
|
Verify Extended ACLs on access.conf
[ref]ruleNo extended ACLs should be applied. Rationale:Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
setfacl --remove-all /etc/security/access.conf
|
Verify User Who Owns services
[ref]rule
To properly set the owner of /etc/services , run the command:
$ sudo chown root /etc/services
Rationale:Identifiers:
GEN003760 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chown root /etc/services
|
Verify Group Who Owns services
[ref]rule
To properly set the group owner of /etc/services , run the command:
$ sudo chgrp root /etc/services
Rationale:Identifiers:
GEN003770 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chown :root /etc/services
|
Verify Permissions on services
[ref]rule
To properly set the permissions of /etc/services , run the command:
$ sudo chmod 0640 /etc/services
Rationale:Identifiers:
GEN003780 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | configure |
---|
chmod 0644 /etc/services
|
Verify Extended ACLs on services
[ref]ruleNo extended ACLs should be applied. Rationale:Identifiers:
GEN003790 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
setfacl --remove-all /etc/services
|
Verify User Who Owns Skeleton Files
[ref]rule
To properly set the owner of /etc/skel/* , run the command:
$ sudo chown root /etc/skel/*
Rationale:Identifiers:
GEN001820 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chown root /etc/skel/*
|
Verify Group Who Owns Skeleton Files
[ref]rule
To properly set the group owner of /etc/skel/* , run the command:
$ sudo chgrp root /etc/skel/*
Rationale:Identifiers:
GEN001830 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chown :root /etc/skel/*
|
Verify Permissions on Skeleton Files
[ref]rule
To properly set the permissions of /etc/skel/* , run the command:
$ sudo chmod 0640 /etc/skel/*
Rationale:Identifiers:
GEN001800 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chmod 0644 /etc/skel/*
|
Verify Extended ACLs on Skeleton Files
[ref]ruleNo extended ACLs should be applied. Rationale:Identifiers:
GEN001810 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
find /etc/skel 2>/dev/null | xargs setfacl --remove-all
|
Verify User Who Owns sysctl.conf
[ref]rule
To properly set the owner of /etc/sysctl.conf , run the command:
$ sudo chown root /etc/sysctl.conf
Rationale:Identifiers:
GEN000000-LNX00480 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chown root /etc/sysctl.conf
|
Verify Group Who Owns sysctl.conf
[ref]rule
To properly set the group owner of /etc/sysctl.conf , run the command:
$ sudo chgrp root /etc/sysctl.conf
Rationale:Identifiers:
GEN000000-LNX00500 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chown :root /etc/sysctl.conf
|
Verify Permissions on sysctl.conf
[ref]rule
To properly set the permissions of /etc/sysctl.conf , run the command:
$ sudo chmod 0600 /etc/sysctl.conf
Rationale:Identifiers:
GEN000000-LNX00520 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chmod 0600 /etc/sysctl.conf
|
Verify Extended ACLs on sysctl.conf
[ref]ruleNo extended ACLs should be applied. Rationale:Identifiers:
GEN000000-LNX00530 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
setfacl --remove-all /etc/sysctl.conf
|
Verify User Who Owns syslog.conf
[ref]rule
To properly set the owner of /etc/syslog.conf , run the command:
$ sudo chown root /etc/syslog.conf
Rationale:Identifiers:
GEN005400 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chown root /etc/syslog.conf
|
Verify Group Who Owns syslog.conf
[ref]rule
To properly set the group owner of /etc/syslog.conf , run the command:
$ sudo chgrp root /etc/syslog.conf
Rationale:Identifiers:
GEN005420 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chown :root /etc/syslog.conf
|
Verify Permissions on syslog.conf
[ref]rule
To properly set the permissions of /etc/syslog.conf , run the command:
$ sudo chmod 0640 /etc/syslog.conf
Rationale:Identifiers:
GEN005390 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | configure |
---|
chmod 0640 /etc/syslog.conf
|
Verify Extended ACLs on syslog.conf
[ref]ruleNo extended ACLs should be applied. Rationale:Identifiers:
GEN005395 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
setfacl --remove-all /etc/syslog.conf
|
Verify User Who Owns xinetd.conf
[ref]rule
To properly set the owner of /etc/xinetd.conf , run the command:
$ sudo chown root /etc/xinetd.conf
Rationale:Identifiers:
GEN003720 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chown root /etc/xinetd.conf
|
Verify Group Who Owns xinetd.conf
[ref]rule
To properly set the group owner of /etc/xinetd.conf , run the command:
$ sudo chgrp root /etc/xinetd.conf
Rationale:Identifiers:
GEN003730 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chown :root /etc/xinetd.conf
|
Verify Permissions on xinetd.conf
[ref]rule
To properly set the permissions of /etc/xinetd.conf , run the command:
$ sudo chmod 0640 /etc/xinetd.conf
Rationale:Identifiers:
GEN003740 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chmod 0640 /etc/xinetd.conf /etc/xinetd.d/*
|
Verify Extended ACLs on xinetd.conf
[ref]ruleNo extended ACLs should be applied. Rationale:Identifiers:
GEN003745 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
setfacl --remove-all /etc/xinetd.conf
|
Verify Permissions on xinet.d Directory
[ref]rule
To properly set the permissions of /etc/xinet.d/ , run the command:
$ sudo chmod 0640 /etc/xinet.d/
Rationale:Identifiers:
GEN003750 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chmod 0755 /etc/xinet.d/*
|
Verify Extended ACLs on xinet.d Directory
[ref]ruleNo extended ACLs should be applied. Rationale:Identifiers:
GEN003755 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
find /etc/xinetd.d -type f 2>/dev/null | xargs setfacl --remove-all
|
Verify User Who Owns Exports Directories
[ref]rule
To properly set the owner of /etc/exports , run the command:
$ sudo chown root /etc/exports
Rationale:Identifiers:
GEN005800 References:
ECSC-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
cat /etc/exports | awk '{ print $1 }' | xargs chown root
|
Verify Group Who Owns Exports Directories
[ref]rule
To properly set the group owner of /etc/exports , run the command:
$ sudo chgrp root /etc/exports
Rationale:Identifiers:
GEN005810 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
cat /etc/exports | awk '{ print $1 }' | xargs chown :root
|
Verify User Who Owns ftpusers
[ref]rule
To properly set the owner of /etc/ftpusers , run the command:
$ sudo chown root /etc/ftpusers
Rationale:Identifiers:
GEN004920 References:
ECLP-1, 225 |
Verify Group Who Owns ftpusers
[ref]rule
To properly set the group owner of /etc/ftpusers , run the command:
$ sudo chgrp root /etc/ftpusers
Rationale:Identifiers:
GEN004930 References:
ECLP-1, 225 |
Verify Permissions on ftpusers
[ref]rule
To properly set the permissions of /etc/ftpusers , run the command:
$ sudo chmod 0640 /etc/ftpusers
Rationale:Identifiers:
GEN004940 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chmod 0640 /etc/ftpusers /etc/vsftpd.ftpusers /etc/vsftpd/ftpusers 2>/dev/null
|
Verify Extended ACLs on ftpusers
[ref]ruleNo extended ACLs should be applied. Rationale:Identifiers:
GEN004950 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
setfacl --remove-all /etc/ftpusers /etc/vsftpd.ftpusers /etc/vsftpd/ftpusers
|
Verify User Who Owns Global Initialization Files
[ref]rule
To properly set the owner of /etc/profile , run the command:
$ sudo chown root /etc/profile
Rationale:Identifiers:
GEN001740 References:
ECLP-1, 225 |
Verify Group Who Owns Global Initialization Files
[ref]rule
To properly set the group owner of /etc/profile , run the command:
$ sudo chgrp root /etc/profile
Rationale:Identifiers:
GEN001760 References:
ECLP-1, 225 |
Verify Permissions on Global Initialization Files
[ref]rule
To properly set the permissions of /etc/profile , run the command:
$ sudo chmod 0644 /etc/profile
Rationale:Identifiers:
GEN001720 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chmod -R 0644 /etc/bashrc /etc/csh.cshrc /etc/csh.login /etc/csh.logout /etc/environment /etc/ksh.kshrc /etc/profile /etc/suid_profile /etc/profile.d 2>/dev/null
|
Verify Extended ACLs on Global Initialization Files
[ref]ruleNo extended ACLs should be applied. Rationale:Identifiers:
GEN001730 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
setfacl --remove-all /etc/bashrc /etc/csh.cshrc /etc/csh.login /etc/csh.logout /etc/environment /etc/ksh.kshrc /etc/profile /etc/suid_profile /etc/profile.d/*
|
Verify Messaging is Disabled in Global Initialization Files
[ref]ruleNo global messaging should be enabled. Rationale:Identifiers:
GEN001780 References:
ECSC-1, 366 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
echo mesg n | tee -a /etc/profile &>/dev/null
|
Verify User Who Owns Home Directories
[ref]rule
To properly set the owner of /home/* , run the command:
$ sudo chown root /home/*
Rationale:Identifiers:
GEN001500 References:
ECLP-1, 225 |
Verify Group Who Owns Home Directories
[ref]rule
To properly set the group owner of /home/* , run the command:
$ sudo chgrp root /home/*
Rationale:Identifiers:
GEN001520 References:
ECLP-1, 225 |
Ensure that User Home Directories are not Group-Writable or World-Readable
[ref]ruleFor each human user of the system, view the
permissions of the user's home directory:
# ls -ld /home/USER
Ensure 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. Rationale:
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.
Identifiers:
GEN001480 References:
ECLP-1, 225 |
Verify Extended ACLs on Home Directories
[ref]ruleNo extended ACLs should be applied. Rationale:Identifiers:
GEN001490 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
cut -d: -f6 /etc/passwd | sort -u | xargs setfacl --remove-all 2>/dev/null
|
Verify User Who Owns Home Files
[ref]rule
To properly set the owner of /home/*/* , run the command:
$ sudo chown root /home/*/*
Rationale: |
Verify Group Who Owns Home Files
[ref]rule
To properly set the group owner of /home/*/* , run the command:
$ sudo chgrp root /home/*/*
Rationale:Identifiers:
GEN001550 References:
ECLP-1, 225 |
Verify Permissions on Home Files
[ref]rule
To properly set the permissions of /home/*/* , run the command:
$ sudo chmod 0750 /home/*/*
Rationale:Identifiers:
GEN001560 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
find /root /home/* -perm -1 -o -perm -2 -o -perm -4 -o -perm -20 2>/dev/null | xargs -I entry chmod o-rwx,g-w "entry"
|
Verify Extended ACLs on Home Files
[ref]ruleNo extended ACLs should be applied. Rationale:Identifiers:
GEN001570 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
find /home -type f 2>/dev/null | xargs setfacl --remove-all
|
Verify User Who Owns LDAP CA Certificates
[ref]rule
To properly set the owner of tls_cacert , run the command:
$ sudo chown root tls_cacert
Rationale:Identifiers:
GEN008140 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
grep -i '^tls_cacert' /etc/ldap.conf | grep -v "#" | awk '{ print $2 }' | xargs chown -R root
|
Verify Group Who Owns LDAP CA Certificates
[ref]rule
To properly set the group owner of tls_cacert , run the command:
$ sudo chgrp root tls_cacert
Rationale:Identifiers:
GEN008160 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
grep -i '^tls_cacert' /etc/ldap.conf | grep -v "#" | awk '{ print $2 }' | xargs chown -R :root
|
Verify Permissions on LDAP CA Certificates
[ref]rule
To properly set the permissions of tls_cacert , run the command:
$ sudo chmod 0640 tls_cacert
Rationale:Identifiers:
GEN008180 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
KEY_PATH="`grep -i '^tls_cacert' /etc/ldap.conf | grep -v "#" | awk '{ print $2 }'`"
if [ -d "${KEY_PATH}" ]; then
chmod 755 "${KEY_PATH}"
chmod 644 "${KEY_PATH}"/*
elif [ -e "${KEY_PATH}" ]; then
chmod 644 "${KEY_PATH}"
fi
|
Verify Extended ACLs on LDAP CA Certificates
[ref]ruleNo extended ACLs should be applied. Rationale:Identifiers:
GEN008200 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
grep -i '^tls_cacert' /etc/ldap.conf | grep -v "#" | awk '{ print $2 }' | xargs setfacl --remove-all
|
Verify User Who Owns LDAP Certificates
[ref]rule
To properly set the owner of tls_cert , run the command:
$ sudo chown root tls_cert
Rationale:Identifiers:
GEN008220 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
grep -i '^tls_cert' /etc/ldap.conf | grep -v "#" | awk '{ print $2 }' | xargs chown -R root
|
Verify Group Who Owns LDAP Certificates
[ref]rule
To properly set the group owner of tls_cert , run the command:
$ sudo chgrp root tls_cert
Rationale:Identifiers:
GEN008240 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
grep -i '^tls_cert' /etc/ldap.conf | grep -v "#" | awk '{ print $2 }' | xargs chown -R :root
|
Verify Permissions on LDAP Certificates
[ref]rule
To properly set the permissions of tls_cert , run the command:
$ sudo chmod 0640 tls_cert
Rationale:Identifiers:
GEN008260 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
grep -i '^tls_cert' /etc/ldap.conf | grep -v "#" | awk '{ print $2 }' | xargs chmod -R 644
|
Verify Extended ACLs on LDAP Certificates
[ref]ruleNo extended ACLs should be applied. Rationale:Identifiers:
GEN008280 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
grep -i '^tls_cert' /etc/ldap.conf | grep -v "#" | awk '{ print $2 }' | xargs setfacl --remove-all
|
Verify User Who Owns LDAP Keys
[ref]rule
To properly set the owner of tls_key , run the command:
$ sudo chown root tls_key
Rationale:Identifiers:
GEN008300 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
grep -i '^tls_key' /etc/ldap.conf | grep -v "#" | awk '{ print $2 }' | xargs chown -R root
|
Verify Group Who Owns LDAP Keys
[ref]rule
To properly set the group owner of tls_key , run the command:
$ sudo chgrp root tls_key
Rationale:Identifiers:
GEN008320 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
grep -i '^tls_key' /etc/ldap.conf | grep -v "#" | awk '{ print $2 }' | xargs chown -R :root
|
Verify Permissions on LDAP Keys
[ref]rule
To properly set the permissions of tls_key , run the command:
$ sudo chmod 0600 tls_key
Rationale:Identifiers:
GEN008340 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
grep -i '^tls_key' /etc/ldap.conf | grep -v "#" | awk '{ print $2 }' | xargs chmod -R 600
|
Verify Extended ACLs on LDAP Keys
[ref]ruleNo extended ACLs should be applied. Rationale:Identifiers:
GEN008360 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
grep -i '^tls_key' /etc/ldap.conf | grep -v "#" | awk '{ print $2 }' | xargs setfacl --remove-all
|
Verify User Who Owns Local Initialization Files
[ref]rule
To properly set the owner of ~/.bashrc , run the command:
$ sudo chown root ~/.bashrc
Rationale:Identifiers:
GEN001860 References:
ECLP-1, 225 |
Verify Group Who Owns Local Initialization Files
[ref]rule
To properly set the group owner of ~/.bashrc , run the command:
$ sudo chgrp root ~/.bashrc
Rationale:Identifiers:
GEN001870 References:
ECLP-1, 225 |
Verify Permissions on Local Initialization Files
[ref]rule
To properly set the permissions of ~/.bashrc , run the command:
$ sudo chmod 0740 ~/.bashrc
Rationale:Identifiers:
GEN001880 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
find /root /home -maxdepth 2 -type f \( -perm -o+r -o -perm -o+w -o -perm -o+x -o -perm -g+w -o -perm -g+x \) -a \( -name \.bashrc -o -name \.bash_login -o -name \.bash_logout -o -name \.bash_profile -o -name \.cshrc -o -name \.kshrc -o -name \.login -o -name \.logout -o -name \.profile -o -name \.env -o -name \.dtprofile -o -name \.dispatch -o -name \.emacs -o -name \.exrc \) 2>/dev/null | xargs chmod o-rwx,g-wx
|
Verify Extended ACLs on Local Initialization Files
[ref]ruleNo extended ACLs should be applied. Rationale:Identifiers:
GEN001890 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
cut -d: -f6 /etc/passwd | sort -u | xargs -n1 -IDIR find DIR -maxdepth 1 -name .bashrc -o -name .bash_login -o -name .bash_logout -o -name .bash_profile -o -name .cshrc -o -name .kshrc -o -name .login -o -name .logout -o -name .profile -o -name .env -o -name .dtprofile -o -name .dispatch -o -name .emacs -o -name .exrc 2>/dev/null | xargs setfacl --remove-all
|
Verify Permissions on Man Pages
[ref]rule
To properly set the permissions of /usr/share/man , run the command:
$ sudo chmod 0644 /usr/share/man
Rationale: |
Verify Extended ACLs on Man Pages
[ref]ruleNo extended ACLs should be applied. Rationale:Identifiers:
GEN001290 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
setfacl -RLb /usr/share/man/* /usr/share/info/* /usr/share/infopage/*
|
Verify Permissions on .Mib Files
[ref]rule
To properly set the permissions of *.mib , run the command:
$ sudo chmod 0640 *.mib
Rationale:Identifiers:
GEN005340 References:
ECLP-1, 225 |
Verify Extended ACLs on .Mib Files
[ref]ruleNo extended ACLs should be applied. Rationale:Identifiers:
GEN005350 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
find / -name *.mib 2>/dev/null | xargs setfacl --remove-all
|
Verify Permissions on root Directory
[ref]rule
To properly set the permissions of /root , run the command:
$ sudo chmod 0700 /root
Rationale:Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
grep ^root: /etc/passwd | awk -F: ' { print $6 }' | xargs -I entry chmod g-rwx,o-rwx "entry"
|
Verify Extended ACLs on root Directory
[ref]ruleNo extended ACLs should be applied. Rationale:Identifiers:
GEN000930 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
setfacl -RLb /root/*
|
Verify User Who Owns Run Control Scripts
[ref]rule
To properly set the owner of /etc/rc* , run the command:
$ sudo chown root /etc/rc*
Rationale:Identifiers:
GEN001660 References:
ECLP-1, 225 |
Verify Group Who Owns Run Control Scripts
[ref]rule
To properly set the group owner of /etc/rc* , run the command:
$ sudo chgrp root /etc/rc*
Rationale:Identifiers:
GEN001680 References:
ECLP-1, 225 |
Verify Permissions on Run Control Scripts
[ref]rule
To properly set the permissions of /etc/rc* , run the command:
$ sudo chmod 0755 /etc/rc*
Rationale:Identifiers:
GEN001580 References:
ECLP-1, 225 |
Verify Extended ACLs on Run Control Scripts
[ref]ruleNo extended ACLs should be applied. Rationale:Identifiers:
GEN001590 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
find /etc/rc* /etc/init.d -type f 2>/dev/null | xargs setfacl --remove-all
|
Verify User Who Owns Shell Files
[ref]rule
To properly set the owner of /etc/shells , run the command:
$ sudo chown root /etc/shells
Rationale:Identifiers:
GEN002200 References:
ECLP-1, 225 |
Verify Group Who Owns Shell Files
[ref]rule
To properly set the group owner of /etc/shells , run the command:
$ sudo chgrp root /etc/shells
Rationale:Identifiers:
GEN002210 References:
ECLP-1, 225 |
Verify Permissions on Shell Files
[ref]rule
To properly set the permissions of /etc/shells , run the command:
$ sudo chmod 0755 /etc/shells
Rationale:Identifiers:
GEN002220 References:
ECLP-1, 225 |
Verify Extended ACLs on Shell Files
[ref]ruleNo extended ACLs should be applied. Rationale:Identifiers:
GEN002230 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
cat /etc/shells | xargs setfacl --remove-all
|
Verify User Who Owns SMTP Logs
[ref]rule
To properly set the owner of /var/log/mail.log , run the command:
$ sudo chown root /var/log/mail.log
Rationale:Identifiers:
GEN004480 References:
ECLP-1, 225 |
Verify Permissions on SMTP Logs
[ref]rule
To properly set the permissions of /var/log/mail.log , run the command:
$ sudo chmod 0644 /var/log/mail.log
Rationale:Identifiers:
GEN004500 References:
ECLP-1, 225 |
Verify Extended ACLs on SMTP Logs
[ref]ruleNo extended ACLs should be applied. Rationale:Identifiers:
GEN004510 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
egrep "(\*.crit|mail\.[^n][^/]*)" /etc/syslog.conf | sed 's/^[^/]*//' | xargs setfacl --remove-all
|
Verify User Who Owns snmpd.conf
[ref]rule
To properly set the owner of snmpd.conf , run the command:
$ sudo chown root snmpd.conf
Rationale:Identifiers:
GEN005360 References:
ECLP-1, 225 |
Verify Group Who Owns snmpd.conf
[ref]rule
To properly set the group owner of snmpd.conf , run the command:
$ sudo chgrp root snmpd.conf
Rationale:Identifiers:
GEN005365 References:
ECLP-1, 225 |
Verify Permissions on snmpd.conf
[ref]rule
To properly set the permissions of snmpd.conf , run the command:
$ sudo chmod 0644 snmpd.conf
Rationale:Identifiers:
GEN005320 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
find / -name snmpd.conf 2>/dev/null | xargs chmod ugo-x,go-wr
|
Verify Extended ACLs on snmpd.conf
[ref]ruleNo extended ACLs should be applied. Rationale:Identifiers:
GEN005375 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
find / -name snmpd.conf 2>/dev/null | xargs setfacl --remove-all
|
Verify Permissions on /etc/ssh/*key
[ref]rule
To properly set the permissions of /etc/ssh/*key , run the command:
$ sudo chmod 0600 /etc/ssh/*key
Rationale:Identifiers:
GEN005523 References:
ECLP-1, 225 |
Verify Permissions on /etc/ssh/*key.pub
[ref]rule
To properly set the permissions of /etc/ssh/*key.pub , run the command:
$ sudo chmod 0644 /etc/ssh/*key.pub
Rationale:Identifiers:
GEN005522 References:
ECLP-1, 225 |
Verify Permissions on TFTP Binary
[ref]rule
To properly set the permissions of /etc/xinetd.d/tftp , run the command:
$ sudo chmod 0755 /etc/xinetd.d/tftp
Rationale:Identifiers:
GEN005100 References:
ECPA-1, 225 |
Verify Permissions on /usr/bin/ldd
[ref]rule
To properly set the permissions of /usr/bin/ldd , run the command:
$ sudo chmod 0000 /usr/bin/ldd
Rationale:Identifiers:
GEN007960 References:
ECSC-1, 305 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chmod a-x /usr/bin/ldd
|
Verify Permissions on sbin Directory
[ref]rule
To properly set the permissions of /usr/sbin/ , run the command:
$ sudo chmod 0755 /usr/sbin/
Rationale:Identifiers:
GEN001180 References:
ECLP-1, 225 |
Verify Extended ACLs on sbin Directory
[ref]ruleNo extended ACLs should be applied. Rationale:Identifiers:
GEN001190 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
setfacl -RLb /usr/sbin/*
|
Verify Permissions on System Logs
[ref]rule
To properly set the permissions of /var/log/* , run the command:
$ sudo chmod 0640 /var/log/*
Rationale:Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
find /var/log -follow -type f ! -name wtmp 2>/dev/null | xargs chmod o-rwx,g-wx,u-x
# The following corrects the permission mask set for /var/log/rpmpkgs.
if [ -e /etc/cron.daily/rpm ]; then
sed -i '/rpmpkgs/s/0644/0640/' /etc/cron.daily/rpm
fi
|
Verify Extended ACLs on System Logs
[ref]ruleNo extended ACLs should be applied. Rationale:Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
setfacl -RLb /var/log/*
|
Verify User Who Owns At Directory
[ref]rule
To properly set the owner of /var/spool/at/ , run the command:
$ sudo chown root /var/spool/at/
Rationale:Identifiers:
GEN003420 References:
ECLP-1, 225 |
Verify Group Who Owns At Directory
[ref]rule
To properly set the group owner of /var/spool/at/ , run the command:
$ sudo chgrp root /var/spool/at/
Rationale:Identifiers:
GEN003430 References:
ECLP-1, 225 |
Verify Permissions on At Directory
[ref]rule
To properly set the permissions of /var/spool/at/ , run the command:
$ sudo chmod 0755 /var/spool/at/
Rationale:Identifiers:
GEN003400 References:
ECLP-1, 225 |
Verify Extended ACLs on At Directory
[ref]ruleNo extended ACLs should be applied. Rationale:Identifiers:
GEN003410 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
setfacl --remove-all /var/spool/at
|
Verify User Who Owns YP Files
[ref]rule
To properly set the owner of /var/yp/* , run the command:
$ sudo chown root /var/yp/*
Rationale:Identifiers:
GEN001320 References:
ECLP-1, 225 |
Verify Group Who Owns YP Files
[ref]rule
To properly set the group owner of /var/yp/* , run the command:
$ sudo chgrp root /var/yp/*
Rationale:Identifiers:
GEN001340 References:
ECLP-1, 225 |
Verify Permissions on YP Files
[ref]rule
To properly set the permissions of /var/yp/* , run the command:
$ sudo chmod 0755 /var/yp/*
Rationale:Identifiers:
GEN001360 References:
ECLP-1, 225 |
Verify Extended ACLs on YP Files
[ref]ruleNo extended ACLs should be applied. Rationale:Identifiers:
GEN001361 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
setfacl -RLb /var/yp/*
|
Verify Permissions on Xauthority Files
[ref]rule
To properly set the permissions of .Xauthority , run the command:
$ sudo chmod 0600 .Xauthority
Rationale:Identifiers:
GEN005180 References:
ECLP-1, 225 |
Verify Extended ACLs on Xauthority Files
[ref]ruleNo extended ACLs should be applied. Rationale:Identifiers:
GEN005190 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
cut -d: -f6 /etc/passwd | sort -u | xargs -n1 -IDIR find DIR -maxdepth 1 -name .Xauthority -o -name .xauth 2>/dev/null | xargs setfacl --remove-all
|
Verify that All World-Writable Directories Have Sticky Bits Set
[ref]ruleWhen 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.
To set the sticky bit on a world-writable directory DIR, run the
following command:
# chmod +t DIR
Rationale:
Failing to set the sticky bit on public directories allows unauthorized users to delete files in the directory structure.
The only authorized public directories are those temporary directories supplied with the system,
or those designed to be temporary file repositories. The setting is normally reserved for directories
used by the system, by users for temporary file storage (such as /tmp ), and for directories
requiring global read/write access.
Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
find / /home /var /var/log /var/log/audit -xdev -perm -2 ! -perm -1000 -type d 2>/dev/null | xargs chmod o-w
|
Ensure No World-Writable Files Exist
[ref]ruleIt 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. Identifiers:
GEN002480 References:
ECSC-1, 366 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
find / /var /home -xdev -follow -type f -perm -002 2>/dev/null | xargs chmod o-w
|
Ensure All Files Are Owned by a User
[ref]ruleIf 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 Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
find / /home /var /var/log /var/log/audit -xdev -nouser 2>/dev/null | xargs chown root
|
Ensure All Files Are Owned by a Group
[ref]ruleIf 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.
Identifiers:
GEN001170 References:
ECSC-1, 366 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
find / /home /var /var/log /var/log/audit -xdev -nogroup 2>/dev/null | xargs chown :root
|
Ensure All World-Writable Directories Are Owned by a System Account
[ref]ruleAll 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.
Identifiers:
GEN002520 References:
ECLP-1, 225 |
Restrict Programs from Dangerous Execution Patterns
[ref]groupThe 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 Dumps
[ref]groupA 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.
Once a hard limit is set in /etc/security/limits.conf , a
user cannot increase that limit within his or her own session. If access
to core dumps is required, consider restricting them to only
certain users or groups. See the limits.conf man page for more
information.
The core dumps of setuid programs are further protected. The
sysctl variable fs.suid_dumpable controls whether
the kernel allows core dumps from these programs at all. The default
value of 0 is recommended. |
contains 1 rule |
Disable Core Dumps for All Users
[ref]ruleTo disable core dumps for all users, add the following line to
/etc/security/limits.conf :
* hard core 0
Rationale: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 Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
echo "* hard core 0" >> /etc/security/limits.conf
|
Enable ExecShield
[ref]groupExecShield 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 sysctl variables kernel.exec-shield and
kernel.randomize_va_space .
|
contains 2 rules |
Enable ExecShield and Randomized Layout of Virtual Address Space
[ref]rule
To set the runtime status of the kernel.exec-shield kernel parameter,
run the following command:
$ sudo sysctl -w kernel.exec-shield=1
If this is not the system's default value, add the following line to /etc/sysctl.conf :
kernel.exec-shield = 1
To set the runtime status of the kernel.randomize_va_space kernel parameter,
run the following command:
$ sudo sysctl -w kernel.randomize_va_space=1
If this is not the system's default value, add the following line to /etc/sysctl.conf :
kernel.randomize_va_space = 1
Rationale: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 Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [[ "`uname -r`" != "2.6.9"* ]]; then
/sbin/sysctl -q -n -w kernel.randomize_va_space=1
if grep --silent ^kernel.randomize_va_space /etc/sysctl.conf ; then
sed -i 's/^kernel.randomize_va_space.*/kernel.randomize_va_space = 1/g' /etc/sysctl.conf
else
echo "" >> /etc/sysctl.conf
echo "# Set kernel.randomize_va_space to 1 per security requirements" >> /etc/sysctl.conf
echo "kernel.randomize_va_space = 1" >> /etc/sysctl.conf
fi
fi
/sbin/sysctl -q -n -w kernel.exec-shield=1
if grep --silent ^kernel.exec-shield /etc/sysctl.conf ; then
sed -i 's/^kernel.exec-shield.*/kernel.exec-shield = 1/g' /etc/sysctl.conf
else
echo "" >> /etc/sysctl.conf
echo "# Set kernel.exec-shield to 1 per security requirements" >> /etc/sysctl.conf
echo "kernel.exec-shield = 1" >> /etc/sysctl.conf
fi
|
Enable ExecShield
[ref]rule
To set the runtime status of the kernel.exec-shield kernel parameter,
run the following command:
$ sudo sysctl -w kernel.exec-shield=1
If this is not the system's default value, add the following line to /etc/sysctl.conf :
kernel.exec-shield = 1
Rationale: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.
Identifiers:
GEN008420 References:
ECSC-1, 366 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
/sbin/sysctl -q -n -w kernel.exec-shield=1
if grep --silent ^kernel.exec-shield /etc/sysctl.conf ; then
sed -i 's/^kernel.exec-shield.*/kernel.exec-shield = 1/g' /etc/sysctl.conf
else
echo "" >> /etc/sysctl.conf
echo "# Set kernel.exec-shield to 1 per security requirements" >> /etc/sysctl.conf
echo "kernel.exec-shield = 1" >> /etc/sysctl.conf
fi
|
SELinux
[ref]groupSELinux 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.
The default SELinux policy, as configured on Red Hat Enterprise Linux 6, has been
sufficiently developed and debugged that it should be usable on
almost any Red Hat machine with minimal configuration and a small
amount of system administrator training. This policy prevents
system services - including most of the common network-visible
services such as mail servers, FTP servers, and DNS servers - from
accessing files which those services have no valid reason to
access. This action alone prevents a huge amount of possible damage
from network attacks against services, from trojaned software, and
so forth.
This guide recommends that SELinux be enabled using the
default (targeted) policy on every Red Hat system, unless that
system has requirements which make a stronger policy
appropriate.
|
contains 1 rule |
Enable SELinux
[ref]groupEdit the file /etc/selinux/config . Add or correct the
following lines:
SELINUX=enforcing
SELINUXTYPE=targeted
Edit the file /etc/grub.conf . Ensure that the following
arguments DO NOT appear on any kernel command line in the file:
selinux=0
enforcing=0
The 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 Targeted
[ref]ruleThe SELinux state should be set to enforcing and the
SELinux policy should be set to targeted at
system boot time. In the file /etc/selinux/config , add or correct the
following lines to configure the system to boot into enforcing mode with the
targeted policy:
SELINUX=enforcing
SELINUXTYPE=targeted
Rationale:
Setting the SELinux state to enforcing ensures SELinux is able to confine
potentially compromised processes to the security policy, which is designed to
prevent them from causing damage to the system or further elevating their
privileges.
Setting the SELinux policy to targeted or a more specialized policy
ensures the system will confine processes that are likely to be
targeted for exploitation, such as network or system services.
Identifiers:
GEN000000-LNX00800 References:
ECSC-1, 366 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
var_selinux_policy_name="targeted"
if [ "`grep -c ^SELINUX= /etc/sysconfig/selinux`" = "0" ]; then
echo SELINUX=enforcing >> /etc/sysconfig/selinux
else
sed -i 's/^SELINUX=.*/SELINUX=enforcing/' /etc/sysconfig/selinux
fi
if [ "`grep -c ^SELINUX= /etc/selinux/config`" = "0" ]; then
echo SELINUX=enforcing >> /etc/selinux/config
else
sed -i 's/^SELINUX=.*/SELINUX=enforcing/' /etc/selinux/config
fi
if [ "`grep -c ^SELINUXTYPE= /etc/sysconfig/selinux`" = "0" ]; then
echo SELINUXTYPE=${var_selinux_policy_name} >> /etc/sysconfig/selinux
else
sed -i "s/^SELINUXTYPE=.*/SELINUXTYPE=${var_selinux_policy_name}/" /etc/sysconfig/selinux
fi
if [ "`grep -c ^SELINUXTYPE= /etc/selinux/config`" = "0" ]; then
echo SELINUXTYPE=${var_selinux_policy_name} >> /etc/selinux/config
else
sed -i "s/^SELINUXTYPE=.*/SELINUXTYPE=${var_selinux_policy_name}/" /etc/selinux/config
fi
|
Account and Access Control
[ref]groupIn 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 Exist
[ref]groupThe system must not have special
privilege accounts, such as shutdown ,
reboot , halt , ftp ,
games , gopher , and news . |
contains 5 rules |
Special Privileged Accounts
[ref]ruleRemove any special privilege accounts,
such as shutdown , reboot , and
halt , from the /etc/passwd and /etc/shadow
files using the userdel or
system-config-users commands. Rationale:
If special privilege accounts are compromised,
the accounts could provide privileges to execute
malicious commands on a system.
Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
/usr/bin/id shutdown &>/dev/null && /usr/sbin/userdel shutdown
/usr/bin/id halt &>/dev/null && /usr/sbin/userdel halt
/usr/bin/id reboot &>/dev/null && /usr/sbin/userdel reboot
|
Ftp Account
[ref]ruleRemove the ftp account from the /etc/passwd
and /etc/shadow files using the userdel or
system-config-users commands. Rationale:
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.
Identifiers:
GEN000290-4 References:
IAAC-1, 12 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
/usr/bin/id ftp &>/dev/null && /usr/sbin/userdel ftp
|
Games Account
[ref]ruleRemove the games account from the /etc/passwd
and /etc/shadow files using the userdel or
system-config-users commands. Rationale:
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.
Identifiers:
GEN000290-1 References:
IAAC-1, 12 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
/usr/bin/id games &>/dev/null && /usr/sbin/userdel games
|
Gopher Account
[ref]ruleRemove the gopher account from the /etc/passwd
and /etc/shadow files using the userdel or
system-config-users commands. Rationale:
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.
Identifiers:
GEN000290-3 References:
IAAC-1, 12 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
/usr/bin/id gopher &>/dev/null && /usr/sbin/userdel gopher
|
News Account
[ref]ruleRemove the news account from the /etc/passwd
and /etc/shadow files using the userdel or
system-config-users commands. Rationale:
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.
Identifiers:
GEN000290-2 References:
IAAC-1, 12 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
/usr/bin/id news &>/dev/null && /usr/sbin/userdel news
|
Protect Accounts by Restricting Password-Based Login
[ref]groupConventionally, Unix shell accounts are accessed by
providing a username and password to a login program, which tests
these values for correctness using the /etc/passwd and
/etc/shadow files. Password-based login is vulnerable to
guessing of weak passwords, and to sniffing and man-in-the-middle
attacks against passwords entered over a network or at an insecure
console. Therefore, mechanisms for accessing accounts by entering
usernames and passwords should be restricted to those which are
operationally necessary. |
contains 12 rules |
Restrict Root Logins
[ref]group
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 su or sudo to execute
privileged commands. Discouraging administrators from accessing the
root account directly ensures an audit trail in organizations with
multiple administrators. Locking down the channels through which
root can connect directly also reduces opportunities for
password-guessing against the root account. The login program
uses the file /etc/securetty to determine which interfaces
should allow root logins.
The virtual devices /dev/console
and /dev/tty* represent the system consoles (accessible via
the Ctrl-Alt-F1 through Ctrl-Alt-F6 keyboard sequences on a default
installation). The default securetty file also contains /dev/vc/* .
These are likely to be deprecated in most environments, but may be retained
for compatibility. Root should also be prohibited from connecting
via network protocols. Other sections of this document
include guidance describing how to prevent root from logging in via SSH.
|
contains 4 rules |
Restrict Virtual Console Root Logins
[ref]rule
To restrict root logins through the (deprecated) virtual console devices,
ensure lines of this form do not appear in /etc/securetty :
vc/1
vc/2
vc/3
vc/4
Rationale:
Preventing direct root login to virtual console devices
helps ensure accountability for actions taken on the system
using the root account.
Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | disable |
---|
echo tty1 > /etc/securetty
|
Restrict Web Browser Use for Administrative Accounts
[ref]rule
Enforce 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.
Identifiers:
GEN004220 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
rm -rf `grep ^root: /etc/passwd | awk -F: '{ print $6 }'`/.mozilla
|
Verify Only Root Has UID 0
[ref]rule
If 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 Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
for UID0_USER in `cat /etc/passwd | cut -d: -f1,3 | grep :0$ | grep -v ^root: | cut -d: -f1`; do
userdel -rf ${UID0_USER}
done
|
Switching To Root Account Must Require Wheel Membership
[ref]rule
Ensure 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.
Identifiers:
GEN000850 References:
ECLP-1, 9 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ "$(grep -c '#.*auth.*required.*pam_wheel.so' /etc/pam.d/su)" != "0" ]; then
sed -i '/auth.*required.*pam_wheel.so/s/#//g' /etc/pam.d/su
else
sed -i '/auth.*include/iauth\t\trequired\tpam_wheel.so use_uid' /etc/pam.d/su
fi
|
Verify Proper Storage and Existence of Password
Hashes
[ref]group
By default, password hashes for local accounts are stored
in the second field (colon-separated) in
/etc/shadow . This file should be readable only by
processes running with root credentials, preventing users from
casually accessing others' password hashes and attempting
to crack them.
However, it remains possible to misconfigure the system
and store password hashes
in world-readable files such as /etc/passwd , or
to even store passwords themselves in plaintext on the system.
Using system-provided tools for password change/creation
should allow administrators to avoid such misconfiguration.
|
contains 4 rules |
Prevent Log In to Accounts With Empty Password
[ref]ruleIf 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 nullok
option in /etc/pam.d/system-auth to
prevent logins with empty passwords.
Rationale:
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 Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | disable |
---|
sed --follow-symlinks -i 's/\<nullok\>//g' /etc/pam.d/system-auth
|
Verify All Account Password Hashes are Shadowed
[ref]rule
If any password hashes are stored in /etc/passwd (in the second field,
instead of an x ), the cause of this misconfiguration should be
investigated. The account should have its password reset and the hash should be
properly stored, or the account should be deleted entirely.
Rationale:
The hashes for all user account passwords should be stored in
the file /etc/shadow and never in /etc/passwd ,
which is readable by all users.
Identifiers:
GEN001470 References:
ECLP-1, 201 |
All GIDs referenced in /etc/passwd must be defined in /etc/group
[ref]rule
Add a group to the system for each GID referenced without a corresponding group.
Rationale:
Inconsistency in GIDs between /etc/passwd and /etc/group could lead to a user having unintended rights.
Identifiers:
GEN000380 References:
ECSC-1, 366 |
Verify No netrc Files Exist
[ref]ruleThe .netrc files contain login information
used to auto-login into FTP servers and reside in the user's home
directory. These files may contain unencrypted passwords to
remote FTP servers making them susceptible to access by unauthorized
users and should not be used. Any .netrc files should be removed.
Rationale:
Unencrypted passwords for remote FTP servers may be stored in .netrc
files. DoD policy requires passwords be encrypted in storage and not used
in access scripts.
|
Set Password Expiration Parameters
[ref]groupThe file /etc/login.defs controls several
password-related settings. Programs such as passwd ,
su , and
login consult /etc/login.defs to determine
behavior with regard to password aging, expiration warnings,
and length. See the man page login.defs(5) for more information.
Users should be forced to change their passwords, in order to
decrease the utility of compromised passwords. However, the need to
change passwords often should be balanced against the risk that
users will reuse or write down passwords if forced to change them
too often. Forcing password changes every 90-360 days, depending on
the environment, is recommended. Set the appropriate value as
PASS_MAX_DAYS and apply it to existing accounts with the
-M flag.
The PASS_MIN_DAYS (-m ) setting prevents password
changes for 7 days after the first change, to discourage password
cycling. If you use this setting, train users to contact an administrator
for an emergency password change in case a new password becomes
compromised. The PASS_WARN_AGE (-W ) setting gives
users 7 days of warnings at login time that their passwords are about to expire.
For example, for each existing human user USER, expiration parameters
could be adjusted to a 180 day maximum password age, 7 day minimum password
age, and 7 day warning period with the following command:
# chage -M 180 -m 7 -W 7 USER
|
contains 2 rules |
Set Password Minimum Age
[ref]ruleTo specify password minimum age for new accounts,
edit the file /etc/login.defs
and add or correct the following line, replacing DAYS appropriately:
PASS_MIN_DAYS DAYS
A 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.
Identifiers:
GEN000540 References:
ECSC-1, 198 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
var_accounts_minimum_age_login_defs="1"
grep -q ^PASS_MIN_DAYS /etc/login.defs && \
sed -i "s/PASS_MIN_DAYS.*/PASS_MIN_DAYS $var_accounts_minimum_age_login_defs/g" /etc/login.defs
if ! [ $? -eq 0 ]; then
echo "PASS_MIN_DAYS $var_accounts_minimum_age_login_defs" >> /etc/login.defs
fi
USERACCT=$(egrep -v "^\+|^#" /etc/passwd | cut -d":" -f1)
for SYS_USER in ${USERACCT}; do
if [ $(grep -c ${SYS_USER} /etc/shadow) != 0 ]; then
passwd -n $var_accounts_minimum_age_login_defs ${SYS_USER} &>/dev/null
fi
done
|
Set Password Maximum Age
[ref]ruleTo specify password maximum age for new accounts,
edit the file /etc/login.defs
and add or correct the following line, replacing DAYS appropriately:
PASS_MAX_DAYS DAYS
A 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 Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
var_accounts_maximum_age_login_defs="60"
grep -q ^PASS_MAX_DAYS /etc/login.defs && \
sed -i "s/PASS_MAX_DAYS.*/PASS_MAX_DAYS $var_accounts_maximum_age_login_defs/g" /etc/login.defs
if ! [ $? -eq 0 ]; then
echo "PASS_MAX_DAYS $var_accounts_maximum_age_login_defs" >> /etc/login.defs
fi
USERACCT=$(egrep -v "^\+|^#" /etc/passwd | cut -d":" -f1)
for SYS_USER in ${USERACCT}; do
if [ $(grep -c ${SYS_USER} /etc/shadow) != 0 ]; then
passwd -x $var_accounts_maximum_age_login_defs ${SYS_USER} &>/dev/null
fi
done
|
Set Account Expiration Parameters
[ref]groupAccounts 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 NUM_DAYS and USER appropriately:
# chage -I NUM_DAYS USER
Accounts, 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 Inactivity
[ref]ruleTo 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 /etc/default/useradd , substituting
NUM_DAYS appropriately:
INACTIVE=NUM_DAYS
A 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.
Identifiers:
GEN006660 References:
AC-2(3), 17 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
var_account_disable_post_pw_expiration="35"
if [ $(cat /etc/default/useradd | grep -c "^INACTIVE=") != 0 ]; then
sed -i "s/^INACTIVE=.*/INACTIVE=${var_account_disable_post_pw_expiration}/" /etc/default/useradd
else
echo INACTIVE=${var_account_disable_post_pw_expiration} >>/etc/default/useradd
fi
|
Ensure All Accounts on the System Have Unique Names
[ref]rule
Change usernames, or delete accounts, so each has a unique name.
Rationale:
Unique usernames allow for accountability on the system.
|
Protect Accounts by Configuring PAM
[ref]groupPAM, 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.
PAM is implemented as a set of shared objects which are
loaded and invoked whenever an application wishes to authenticate a
user. Typically, the application must be running as root in order
to take advantage of PAM, because PAM's modules often need to be able
to access sensitive stores of account information, such as /etc/shadow.
Traditional privileged network listeners
(e.g. sshd) or SUID programs (e.g. sudo) already meet this
requirement. An SUID root application, userhelper, is provided so
that programs which are not SUID or privileged themselves can still
take advantage of PAM.
PAM looks in the directory /etc/pam.d for
application-specific configuration information. For instance, if
the program login attempts to authenticate a user, then PAM's
libraries follow the instructions in the file /etc/pam.d/login
to determine what actions should be taken.
One very important file in /etc/pam.d is
/etc/pam.d/system-auth . This file, which is included by
many other PAM configuration files, defines 'default' system authentication
measures. Modifying this file is a good way to make far-reaching
authentication changes, for instance when implementing a
centralized authentication service. 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. |
contains 13 rules |
Set Password Quality Requirements
[ref]groupThe default pam_cracklib PAM module provides strength
checking for passwords. It performs a number of checks, such as
making sure passwords are not similar to dictionary words, are of
at least a certain length, are not the previous password reversed,
and are not simply a change of case from the previous password. It
can also require passwords to be in certain character classes.
The man page pam_cracklib(8) provides information on the
capabilities and configuration of each. |
contains 9 rules |
Set Password Quality Requirements, if using
pam_cracklib
[ref]groupThe pam_cracklib PAM module can be configured to meet
requirements for a variety of policies.
For example, to configure pam_cracklib to require at least one uppercase
character, lowercase character, digit, and other (special)
character, locate the following line in /etc/pam.d/system-auth :
password requisite pam_cracklib.so try_first_pass retry=3
and 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=4
If 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 Module
[ref]ruleTo 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 password include statement points to
system-auth and not system-auth-ac.
Rationale:
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 Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
authconfig --updateall
if [ -e /etc/pam.d/system-auth-ac ]; then
sed -i '/password.*include.*system-auth-ac/ipassword required pam_cracklib.so' /etc/pam.d/system-auth
else
sed -i '/password.*unix.so/ipassword required pam_cracklib.so' /etc/pam.d/system-auth
fi
|
Set Password Minimum Length
[ref]ruleTo specify password length requirements for new accounts,
edit the file /etc/login.defs and add or correct the following
lines:
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 Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
var_password_pam_cracklib_minlen="14"
if [ $(grep -c "minlen=" /etc/pam.d/system-auth) != 0 ]; then
sed -i "s/minlen=[0-9]*/minlen=$var_password_pam_cracklib_minlen/" /etc/pam.d/system-auth
else
sed -i "/password.*pam_cracklib.so/s/$/ minlen=$var_password_pam_cracklib_minlen/" /etc/pam.d/system-auth
fi
if [ -e /etc/pam.d/system-auth-ac ]; then
if [ $(grep -c "minlen=" /etc/pam.d/system-auth-ac) != 0 ]; then
sed -i "s/minlen=[0-9]*/minlen=$var_password_pam_cracklib_minlen/" /etc/pam.d/system-auth-ac
else
sed -i "/password.*pam_cracklib.so/s/$/ minlen=$var_password_pam_cracklib_minlen/" /etc/pam.d/system-auth-ac
fi
fi
|
Set Password to Maximum of Three Consecutive Repeating Characters
[ref]ruleThe pam_cracklib module's maxrepeat parameter controls requirements for
consecutive repeating characters. When set to a positive number, it will reject passwords
which contain more than that number of consecutive characters. Add maxrepeat=3
after pam_cracklib.so to prevent a run of four or more identical characters.
Rationale:
Passwords with excessive repeating characters may be more vulnerable to password-guessing attacks.
Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
var_password_pam_cracklib_maxrepeat="3"
if [ $(grep -c "maxrepeat=" /etc/pam.d/system-auth) != 0 ]; then
sed -i "s/maxrepeat=[0-9]*/maxrepeat=$var_password_pam_cracklib_maxrepeat/" /etc/pam.d/system-auth
else
sed -i "/password.*pam_cracklib.so/s/$/ maxrepeat=$var_password_pam_cracklib_maxrepeat/" /etc/pam.d/system-auth
fi
if [ -e /etc/pam.d/system-auth-ac ]; then
if [ $(grep -c "maxrepeat=" /etc/pam.d/system-auth-ac) != 0 ]; then
sed -i "s/maxrepeat=[0-9]*/maxrepeat=$var_password_pam_cracklib_maxrepeat/" /etc/pam.d/system-auth-ac
else
sed -i "/password.*pam_cracklib.so/s/$/ maxrepeat=$var_password_pam_cracklib_maxrepeat/" /etc/pam.d/system-auth-ac
fi
fi
|
Set Password Strength Minimum Digit Characters
[ref]ruleThe pam_cracklib module's dcredit parameter controls requirements for
usage of digits in a password. When set to a negative number, any password will be required to
contain that many digits. When set to a positive number, pam_cracklib will grant +1 additional
length credit for each digit.
Add dcredit=-1 after pam_cracklib.so to require use of a digit in passwords.
Rationale:
Requiring digits makes password guessing attacks more difficult by ensuring a larger
search space.
Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
var_password_pam_cracklib_dcredit="-1"
if [ $(grep -c "dcredit=" /etc/pam.d/system-auth) != 0 ]; then
sed -i "s/dcredit=[0-9]*/dcredit=$var_password_pam_cracklib_dcredit/" /etc/pam.d/system-auth
else
sed -i "/password.*pam_cracklib.so/s/$/ dcredit=$var_password_pam_cracklib_dcredit/" /etc/pam.d/system-auth
fi
if [ -e /etc/pam.d/system-auth-ac ]; then
if [ $(grep -c "dcredit=" /etc/pam.d/system-auth-ac) != 0 ]; then
sed -i "s/dcredit=[0-9]*/dcredit=$var_password_pam_cracklib_dcredit/" /etc/pam.d/system-auth-ac
else
sed -i "/password.*pam_cracklib.so/s/$/ dcredit=$var_password_pam_cracklib_dcredit/" /etc/pam.d/system-auth-ac
fi
fi
|
Set Password Strength Minimum Uppercase Characters
[ref]ruleThe pam_cracklib module's ucredit= parameter controls requirements for
usage of uppercase letters in a password. When set to a negative number, any password will be required to
contain that many uppercase characters. When set to a positive number, pam_cracklib will grant +1 additional
length credit for each uppercase character.
Add ucredit=-1 after pam_cracklib.so to require use of an upper case character in passwords.
Rationale:
Requiring a minimum number of uppercase characters makes password guessing attacks
more difficult by ensuring a larger search space.
Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
var_password_pam_cracklib_ucredit="-1"
if [ $(grep -c "ucredit=" /etc/pam.d/system-auth) != 0 ]; then
sed -i "s/ucredit=[0-9]*/ucredit=$var_password_pam_cracklib_ucredit/" /etc/pam.d/system-auth
else
sed -i "/password.*pam_cracklib.so/s/$/ ucredit=$var_password_pam_cracklib_ucredit/" /etc/pam.d/system-auth
fi
if [ -e /etc/pam.d/system-auth-ac ]; then
if [ $(grep -c "ucredit=" /etc/pam.d/system-auth-ac) != 0 ]; then
sed -i "s/ucredit=[0-9]*/ucredit=$var_password_pam_cracklib_ucredit/" /etc/pam.d/system-auth-ac
else
sed -i "/password.*pam_cracklib.so/s/$/ ucredit=$var_password_pam_cracklib_ucredit/" /etc/pam.d/system-auth-ac
fi
fi
|
Set Password Strength Minimum Special Characters
[ref]ruleThe pam_cracklib module's ocredit= parameter controls requirements for
usage of special (or ``other'') characters in a password. When set to a negative number, any password will be required to
contain that many special characters. When set to a positive number, pam_cracklib will grant +1 additional
length credit for each special character.
Add ocredit=-1 after pam_cracklib.so to require use of a special character in passwords.
Rationale:
Requiring a minimum number of special characters makes password guessing attacks
more difficult by ensuring a larger search space.
Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
var_password_pam_cracklib_ocredit="-1"
if [ $(grep -c "ocredit=" /etc/pam.d/system-auth) != 0 ]; then
sed -i "s/ocredit=[0-9]*/ucredit=$var_password_pam_cracklib_ocredit/" /etc/pam.d/system-auth
else
sed -i "/password.*pam_cracklib.so/s/$/ ocredit=$var_password_pam_cracklib_ocredit/" /etc/pam.d/system-auth
fi
if [ -e /etc/pam.d/system-auth-ac ]; then
if [ $(grep -c "ocredit=" /etc/pam.d/system-auth-ac) != 0 ]; then
sed -i "s/ocredit=[0-9]*/ucredit=$var_password_pam_cracklib_ocredit/" /etc/pam.d/system-auth-ac
else
sed -i "/password.*pam_cracklib.so/s/$/ ocredit=$var_password_pam_cracklib_ocredit/" /etc/pam.d/system-auth-ac
fi
fi
|
Set Password Strength Minimum Lowercase Characters
[ref]ruleThe pam_cracklib module's lcredit= parameter controls requirements for
usage of lowercase letters in a password. When set to a negative number, any password will be required to
contain that many lowercase characters. When set to a positive number, pam_cracklib will grant +1 additional
length credit for each lowercase character.
Add lcredit=-1 after pam_cracklib.so to require use of a lowercase character in passwords.
Rationale:
Requiring a minimum number of lowercase characters makes password guessing attacks
more difficult by ensuring a larger search space.
Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
var_password_pam_cracklib_lcredit="-1"
if [ $(grep -c "lcredit=" /etc/pam.d/system-auth) != 0 ]; then
sed -i "s/lcredit=[0-9]*/lcredit=$var_password_pam_cracklib_lcredit/" /etc/pam.d/system-auth
else
sed -i "/password.*pam_cracklib.so/s/$/ lcredit=$var_password_pam_cracklib_lcredit/" /etc/pam.d/system-auth
fi
if [ -e /etc/pam.d/system-auth-ac ]; then
if [ $(grep -c "lcredit=" /etc/pam.d/system-auth-ac) != 0 ]; then
sed -i "s/lcredit=[0-9]*/lcredit=$var_password_pam_cracklib_lcredit/" /etc/pam.d/system-auth-ac
else
sed -i "/password.*pam_cracklib.so/s/$/ lcredit=$var_password_pam_cracklib_lcredit/" /etc/pam.d/system-auth-ac
fi
fi
|
Set Password Strength Minimum Different Characters
[ref]ruleThe pam_cracklib module's difok parameter controls requirements for
usage of different characters during a password change.
Add difok=NUM after pam_cracklib.so to require differing
characters when changing passwords, substituting NUM appropriately.
The DoD requirement is 4 .
Rationale:
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 Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
var_password_pam_cracklib_difok="4"
if [ $(grep -c "difok=" /etc/pam.d/system-auth) != 0 ]; then
sed -i "s/difok=[0-9]*/difok=$var_password_pam_cracklib_difok/" /etc/pam.d/system-auth
else
sed -i "/password.*pam_cracklib.so/s/$/ difok=$var_password_pam_cracklib_difok/" /etc/pam.d/system-auth
fi
if [ -e /etc/pam.d/system-auth-ac ]; then
if [ $(grep -c "difok=" /etc/pam.d/system-auth-ac) != 0 ]; then
sed -i "s/difok=[0-9]*/difok=$var_password_pam_cracklib_difok/" /etc/pam.d/system-auth-ac
else
sed -i "/password.*pam_cracklib.so/s/$/ difok=$var_password_pam_cracklib_difok/" /etc/pam.d/system-auth-ac
fi
fi
|
Limit Password Reuse
[ref]ruleDo not allow users to reuse recent passwords. This can
be accomplished by using the remember option for the pam_unix PAM
module. In the file /etc/pam.d/system-auth , append remember=24 to the
line which refers to the pam_unix.so module, as shown:
password sufficient pam_unix.so existing_options remember=24
The 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 Actions
[ref]groupThe 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 Attempts
[ref]rule
To configure the system to lock out accounts after a number of incorrect login
attempts using pam_faillock.so :
Add the following lines immediately below the pam_unix.so statement in AUTH section of
/etc/pam.d/system-auth :
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=900
Rationale:
Locking out user accounts after a number of incorrect attempts
prevents direct password guessing attacks.
Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
var_accounts_password_pam_tally_deny="3"
if [ $(grep auth.*required.*pam_tally2 /etc/pam.d/system-auth | grep -c "deny=") != 0 ]; then
sed -i "/account.*required.*pam_tally/s/deny=[0-9]*/deny=${var_accounts_password_pam_tally_deny}/" /etc/pam.d/system-auth
elif [ $(grep -c "auth.*required.*pam_tally2" /etc/pam.d/system-auth) = 0 ]; then
if [ $(grep -c "pam_tally.so" /etc/pam.d/system-auth) != 0 ]; then
sed -i "s/pam_tally.so/pam_tally2.so/g" /etc/pam.d/system-auth
elif [ $(grep -c "auth.*include.*system-auth-ac" /etc/pam.d/system-auth) != 0 ]; then
sed -i 's/\(auth\s*include\s*system-auth-ac\)/auth required pam_tally2.so\n\1/' /etc/pam.d/system-auth
elif [ $(grep -c "auth.*pam_unix.so" /etc/pam.d/system-auth) != 0 ]; then
sed -i 's/\(auth.*pam_unix.so\)/auth required pam_tally2.so\n\1/' /etc/pam.d/system-auth
elif [ $(grep -c "auth.*pam_deny.so" /etc/pam.d/system-auth) != 0 ]; then
sed -i 's/\(auth.*pam_deny.so\)/auth required pam_tally2.so\n\1/' /etc/pam.d/system-auth
else
sed -i ':a;N;$!ba;s/\([\n]*[#]*[\s]*account\)/\nauth required pam_tally2.so\n\1/' /etc/pam.d/system-auth
fi
sed -i "/auth.*pam_tally/s/$/ deny=${var_accounts_password_pam_tally_deny}/" /etc/pam.d/system-auth
else
sed -i "/auth.*pam_tally/s/$/ deny=${var_accounts_password_pam_tally_deny}/" /etc/pam.d/system-auth
fi
if [ ! -e /var/log/tallylog ]; then
>/var/log/tallylog
fi
chmod 640 /var/log/tallylog
chown root:root /var/log/tallylog
|
Set Delay Between Failed Password Attempts
[ref]rule
Check 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 Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ $(grep -c ^FAIL_DELAY /etc/login.defs) != 0 ]; then
sed -i 's/^FAIL_DELAY.*[0-9]*/FAIL_DELAY 4/' /etc/login.defs
else
echo "FAIL_DELAY 4" | tee -a /etc/login.defs &>/dev/null
fi
if [ $(grep -c pam_faildelay.so /etc/pam.d/system-auth) != 0 ]; then
if [ $(grep -c pam_faildelay.so.*delay\= /etc/pam.d/system-auth) != 0 ]; then
sed -i '/pam_faildelay.so/s/\(delay=\)[0-9]*/\14000000/' /etc/pam.d/system-auth
else
sed -i '/pam_faildelay.so/s/$/ delay=4000000/' /etc/pam.d/system-auth
fi
else
sed -i '/auth.*include.*system-auth-ac/iauth optional pam_faildelay.so delay=4000000' /etc/pam.d/system-auth
fi
|
Set Password Hashing Algorithm
[ref]groupThe system's default algorithm for storing password hashes in
/etc/shadow is SHA-512. This can be configured in several
locations. |
contains 1 rule |
Set Password Hashing Algorithm in /etc/pam.d/system-auth
[ref]rule
In /etc/pam.d/system-auth , the password section of
the file controls which PAM modules execute during a password change.
Set the pam_unix.so module in the
password section to include the argument sha512 , as shown below:
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 Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | disable |
---|
if [ $(grep "password.*pam_unix.so" /etc/pam.d/system-auth | egrep -c '(descrypt|bigcrypt|md5|sha256)') != 0 ]; then
sed -i '/password.*pam_unix.so/s/\(descrypt\|bigcrypt\|md5\|sha256\)/sha512/' /etc/pam.d/system-auth
else
sed -i '/password.*pam_unix.so/s/$/ sha512/' /etc/pam.d/system-auth
fi
if [ -e /etc/pam.d/system-auth-ac ]; then
if [ $(grep "password.*pam_unix.so" /etc/pam.d/system-auth-ac | egrep -c '(descrypt|bigcrypt|md5|sha256)') != 0 ]; then
sed -i '/password.*pam_unix.so/s/\(descrypt\|bigcrypt\|md5\|sha256\)/sha512/' /etc/pam.d/system-auth-ac
else
sed -i '/password.*pam_unix.so/s/$/ sha512/' /etc/pam.d/system-auth-ac
fi
fi
|
Configure Global Account Settings
[ref]ruleThe /etc/pam.d/system-auth file must not be a symbolic link to
/etc/pam.d/system-auth-ac . The /etc/pam.d/system-auth file must instead
link to an alternate file, such as /etc/pam.d/system-auth-local , which incorporates
include statements for system-auth-ac. Specifically, the following include
statements should be present:
auth include system-auth-ac
account include system-auth-ac
password include system-auth-ac
session include system-auth-ac
Rationale:
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.
Identifiers:
GEN000600-2 References:
ECSC-1, 192 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
cat > /etc/pam.d/system-auth-local <<'STOP_HERE'
auth include system-auth-ac
account include system-auth-ac
password include system-auth-ac
session include system-auth-ac
STOP_HERE
ln -sf /etc/pam.d/system-auth-local /etc/pam.d/system-auth
|
Secure Session Configuration Files for Login Accounts
[ref]groupWhen 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 Path
[ref]groupThe active path of the root account can be obtained by
starting a new root shell and running:
# echo $PATH
This 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 Paths
[ref]rule
Ensure that none of the directories in root's executable path is equal to a single
. character, or
that it contains any instances that lead to relative path traversal, such as
.. or beginning a path without the slash (/ ) character.
Also ensure that there are no "empty" elements in the path, such as in these examples:
PATH=:/bin
PATH=/bin:
PATH=/bin::/sbin
These 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 Paths
[ref]rule
Ensure that none of the directories in root's library path is equal to a single
. character, or
that it contains any instances that lead to relative path traversal, such as
.. or beginning a path without the slash (/ ) character.
Also ensure that there are no "empty" elements in the path, such as in these examples:
LD_LIBRARY_PATH=:/lib
LD_LIBRARY_PATH=/lib:
LD_LIBRARY_PATH=/lib::/usr/lib
These 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.
Identifiers:
GEN000945 References:
ECSC-1, 366 |
Ensure that Root's Path Does Not Include World or Group-Writable Directories
[ref]rule
For each element in root's path, run:
# ls -ld DIR
and 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 Values
[ref]group
The umask setting controls the default permissions
for the creation of new files.
With a default umask setting of 077, files and directories
created by users will not be readable by any other user on the
system. Users who wish to make specific files group- or
world-readable can accomplish this by using the chmod command.
Additionally, users can make all their files readable to their
group by default by setting a umask of 027 in their shell
configuration files. If default per-user groups exist (that is, if
every user has a default group whose name is the same as that
user's username and whose only member is the user), then it may
even be safe for users to select a umask of 007, making it very
easy to intentionally share files with groups of which the user is
a member.
|
contains 1 rule |
Ensure the Default Umask is Set Correctly
[ref]rule
To ensure the default umask for users is set properly,
add or correct the umask setting in /etc/bashrc to read
as follows:
umask 077
Rationale: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 Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
var_accounts_user_umask="077"
egrep -li ^[[:blank:]]*umask `find /etc /root /home/* -maxdepth 1 -type f 2>/dev/null` | while read FILE; do
sed -i "s/\([uU][mM][aA][sS][kK]\s*[=]*\s*\)[0-9]*/\1${var_accounts_user_umask}/" "${FILE}"
done
|
Limit the Number of Concurrent Login Sessions Allowed Per User
[ref]rule
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 /etc/security/limits.conf :
* hard maxlogins 10
Rationale: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.
Identifiers:
GEN000450 References:
ECSC-1, 54 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | disable |
---|
max_concurrent_login_sessions_value="10"
if [ $(grep -v "#" /etc/security/limits.conf | grep -c "maxlogins") = "0" ]; then
echo "* hard maxlogins ${max_concurrent_login_sessions_value}" >>/etc/security/limits.conf
else
sed -i 's/.*maxlogins.*/* hard maxlogins ${max_concurrent_login_sessions_value}/' /etc/security/limits.conf
fi
|
Protect Physical Console Access
[ref]groupIt 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 Password
[ref]groupDuring 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 Exists
[ref]ruleThe file /boot/grub/grub.conf should exist.
Rationale:
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 Ownership
[ref]ruleThe file /etc/grub.conf should
be owned by the root user to prevent destruction
or modification of the file.
To properly set the owner of /etc/grub.conf , run the command:
$ sudo chown root /etc/grub.conf
Rationale:
Only root should be able to modify important boot parameters.
Identifiers:
GEN008760 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chown root /etc/grub.conf /boot/grub/grub.conf
|
Verify /etc/grub.conf Group Ownership
[ref]ruleThe file /etc/grub.conf should
be group-owned by the root group to prevent
destruction or modification of the file.
To properly set the group owner of /etc/grub.conf , run the command:
$ sudo chgrp root /etc/grub.conf
Rationale:
The root group is a highly-privileged group. Furthermore, the group-owner of this
file should not have any access privileges anyway.
Identifiers:
GEN008780 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chown :root /etc/grub.conf
|
Verify /boot/grub/grub.conf Permissions
[ref]ruleFile permissions for /boot/grub/grub.conf should be set to 600, which
is the default.
To properly set the permissions of /boot/grub/grub.conf , run the command:
$ sudo chmod 600 /boot/grub/grub.conf
Rationale:
Proper permissions ensure that only the root user can modify important boot
parameters.
Identifiers:
GEN008720 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
chmod 0600 /etc/grub.conf /boot/grub/grub.conf
|
Verify /boot/grub/grub.conf Extended ACLs
[ref]ruleThe 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.
Identifiers:
GEN008740 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
setfacl --remove-all /etc/grub.conf /boot/grub/grub.conf
|
Set Boot Loader Password
[ref]ruleThe 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-crypt
When 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-hash
NOTE: 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 Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ -e /tmp/GRUB.TMP ]; then
/sbin/grub-md5-crypt < /tmp/GRUB.TMP &> /tmp/GRUB.TMP.out
md5crypt=`tail -n1 /tmp/GRUB.TMP.out`
if [ -f /boot/grub/grub.conf ] && [ ! -h /boot/grub/grub.conf ]; then
if [ "$(grep -c '^password' /boot/grub/grub.conf)" = "0" ]; then
sed -i "/timeout/apassword --md5 ${md5crypt}" /boot/grub/grub.conf
else
sed -i "s/^password .*/password --md5 ${md5crypt}/" /boot/grub/grub.conf
fi
fi
if [ -f /etc/grub.conf ] && [ ! -h /etc/grub.conf ]; then
if [ "$(grep -c '^password' /etc/grub.conf)" = "0" ]; then
sed -i "/timeout/apassword --md5 ${md5crypt}" /etc/grub.conf
else
sed -i "s/^password .*/password --md5 ${md5crypt}/" /etc/grub.conf
fi
fi
rm -f /tmp/GRUB.TMP /tmp/GRUB.TMP.out
fi
|
Set Boot Loader Password Hash
[ref]ruleThe 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-crypt
When 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-hash
NOTE: 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 Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ -e /tmp/GRUB.TMP ]; then
/sbin/grub-md5-crypt < /tmp/GRUB.TMP &> /tmp/GRUB.TMP.out
md5crypt=`tail -n1 /tmp/GRUB.TMP.out`
if [ -f /boot/grub/grub.conf ] && [ ! -h /boot/grub/grub.conf ]; then
if [ "$(grep -c '^password' /boot/grub/grub.conf)" = "0" ]; then
sed -i "/timeout/apassword --md5 ${md5crypt}" /boot/grub/grub.conf
else
sed -i "s/^password .*/password --md5 ${md5crypt}/" /boot/grub/grub.conf
fi
fi
if [ -f /etc/grub.conf ] && [ ! -h /etc/grub.conf ]; then
if [ "$(grep -c '^password' /etc/grub.conf)" = "0" ]; then
sed -i "/timeout/apassword --md5 ${md5crypt}" /etc/grub.conf
else
sed -i "s/^password .*/password --md5 ${md5crypt}/" /etc/grub.conf
fi
fi
rm -f /tmp/GRUB.TMP /tmp/GRUB.TMP.out
fi
|
Configure Screen Locking
[ref]groupWhen 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.
Automatic screen locking is only meant as a safeguard for
those cases where a user forgot to lock the screen. |
contains 3 rules |
Configure GUI Screen Locking
[ref]groupIn the default GNOME desktop, the screen can be locked
by choosing Lock Screen from the System menu.
The gconftool-2 program can be used to enforce mandatory
screen locking settings for the default GNOME environment.
The
following sections detail commands to enforce idle activation of the screen saver,
screen locking, a blank-screen screensaver, and an idle
activation time.
Because users should be trained to lock the screen when they
step away from the computer, the automatic locking feature is only
meant as a backup. The Lock Screen icon from the System menu can
also be dragged to the taskbar in order to facilitate even more
convenient screen-locking.
The root account cannot be screen-locked, but this should
have no practical effect as the root account should never be used
to log into an X Windows environment, and should only be used to
for direct login via console in emergency circumstances.
For more information about configuring GNOME screensaver, see
http://live.gnome.org/GnomeScreensaver. For more information about
enforcing preferences in the GNOME environment using the GConf
configuration system, see http://projects.gnome.org/gconf and
the man page gconftool-2(1) . |
contains 3 rules |
Set GNOME Login Inactivity Timeout
[ref]rule
Run 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 15
Rationale:
Setting the idle delay controls when the
screensaver will start, and can be combined with
screen locking to prevent access from passersby.
Identifiers:
GEN000500-2 References:
PESL-1, 57 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
gconftool-2 --direct --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory --type int --set /apps/gnome-screensaver/idle_delay 15 &>/dev/null
|
GNOME Desktop Screensaver Mandatory Use
[ref]rule
Run 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 true
Rationale:
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.
Identifiers:
GEN000500 References:
PESL-1, 57 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
gconftool-2 --direct --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory --type bool --set /apps/gnome-screensaver/idle_activation_enabled true &>/dev/null
|
Enable Screen Lock Activation After Idle Period
[ref]rule
Run 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 true
Rationale:
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.
Identifiers:
GEN000500-3 References:
PESL-1, 57 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
gconftool-2 --direct --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory --type bool --set /apps/gnome-screensaver/lock_enabled true &>/dev/null
|
Require Authentication for Single User Mode
[ref]ruleSingle-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.
To require entry of the root password even if the system is
started in single-user mode, add or correct the following line in the
file /etc/inittab :
~:S:wait:/sbin/sulogin
Rationale:
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 Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
grep -q :S: /etc/inittab && \
sed -i "s/.*:S:.*/~:S:wait:\/sbin\/sulogin/g" /etc/inittab
if ! [ $? -eq 0 ]; then
echo "~:S:wait:/sbin/sulogin" >> /etc/inittab
fi
|
Disable Ctrl-Alt-Del Reboot Activation
[ref]rule
By default, the system includes the following line in
/etc/init/control-alt-delete.conf
to reboot the system when the Ctrl-Alt-Del key sequence is pressed:
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.
Identifiers:
GEN000000-LNX00580 References:
ECSC-1, 366 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
sed -i 's/^.*:ctrlaltdel:.*\(shutdown\|reboot\).*/ca:nil:ctrlaltdel:\/usr\/bin\/logger -p security.info "Ctrl-Alt-Del was pressed"/' /etc/inittab
|
Warning Banners for System Accesses
[ref]groupEach system should expose as little information about
itself as possible.
System banners, which are typically displayed just before a
login prompt, give out information about the service or the host's
operating system. This might include the distribution name and the
system kernel version, and the particular version of a network
service. This information can assist intruders in gaining access to
the system as it can reveal whether the system is running
vulnerable software. Most network services can be configured to
limit what information is displayed.
Many organizations implement security policies that require a
system banner provide notice of the system's ownership, provide
warning to unauthorized users, and remind authorized users of their
consent to monitoring. |
contains 3 rules |
Implement a GUI Warning Banner
[ref]groupIn 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 Text
[ref]rule
To 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 true
To 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.
Identifiers:
GEN000402 References:
ECWM-1, 48 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
gui_login_banner_text="You[\s\n]+are[\s\n]+accessing[\s\n]+a[\s\n]+U.S.[\s\n]+Government[\s\n]+\(USG\)[\s\n]+Information[\s\n]+System[\s\n]+\(IS\)[\s\n]+that[\s\n]+is[\s\n]+provided[\s\n]+for[\s\n]+USG-authorized[\s\n]+use[\s\n]+only.[\s\n]*By[\s\n]+using[\s\n]+this[\s\n]+IS[\s\n]+\(which[\s\n]+includes[\s\n]+any[\s\n]+device[\s\n]+attached[\s\n]+to[\s\n]+this[\s\n]+IS\),[\s\n]+you[\s\n]+consent[\s\n]+to[\s\n]+the[\s\n]+following[\s\n]+conditions\:[\s\n]*-[\s\n]*The[\s\n]+USG[\s\n]+routinely[\s\n]+intercepts[\s\n]+and[\s\n]+monitors[\s\n]+communications[\s\n]+on[\s\n]+this[\s\n]+IS[\s\n]+for[\s\n]+purposes[\s\n]+including,[\s\n]+but[\s\n]+not[\s\n]+limited[\s\n]+to,[\s\n]+penetration[\s\n]+testing,[\s\n]+COMSEC[\s\n]+monitoring,[\s\n]+network[\s\n]+operations[\s\n]+and[\s\n]+defense,[\s\n]+personnel[\s\n]+misconduct[\s\n]+\(PM\),[\s\n]+law[\s\n]+enforcement[\s\n]+\(LE\),[\s\n]+and[\s\n]+counterintelligence[\s\n]+\(CI\)[\s\n]+investigations.[\s\n]*-[\s\n]*At[\s\n]+any[\s\n]+time,[\s\n]+the[\s\n]+USG[\s\n]+may[\s\n]+inspect[\s\n]+and[\s\n]+seize[\s\n]+data[\s\n]+stored[\s\n]+on[\s\n]+this[\s\n]+IS.[\s\n]*-[\s\n]*Communications[\s\n]+using,[\s\n]+or[\s\n]+data[\s\n]+stored[\s\n]+on,[\s\n]+this[\s\n]+IS[\s\n]+are[\s\n]+not[\s\n]+private,[\s\n]+are[\s\n]+subject[\s\n]+to[\s\n]+routine[\s\n]+monitoring,[\s\n]+interception,[\s\n]+and[\s\n]+search,[\s\n]+and[\s\n]+may[\s\n]+be[\s\n]+disclosed[\s\n]+or[\s\n]+used[\s\n]+for[\s\n]+any[\s\n]+USG-authorized[\s\n]+purpose.[\s\n]*-[\s\n]*This[\s\n]+IS[\s\n]+includes[\s\n]+security[\s\n]+measures[\s\n]+\(e.g.,[\s\n]+authentication[\s\n]+and[\s\n]+access[\s\n]+controls\)[\s\n]+to[\s\n]+protect[\s\n]+USG[\s\n]+interests[\s\n]+--[\s\n]+not[\s\n]+for[\s\n]+your[\s\n]+personal[\s\n]+benefit[\s\n]+or[\s\n]+privacy.[\s\n]*-[\s\n]*Notwithstanding[\s\n]+the[\s\n]+above,[\s\n]+using[\s\n]+this[\s\n]+IS[\s\n]+does[\s\n]+not[\s\n]+constitute[\s\n]+consent[\s\n]+to[\s\n]+PM,[\s\n]+LE[\s\n]+or[\s\n]+CI[\s\n]+investigative[\s\n]+searching[\s\n]+or[\s\n]+monitoring[\s\n]+of[\s\n]+the[\s\n]+content[\s\n]+of[\s\n]+privileged[\s\n]+communications,[\s\n]+or[\s\n]+work[\s\n]+product,[\s\n]+related[\s\n]+to[\s\n]+personal[\s\n]+representation[\s\n]+or[\s\n]+services[\s\n]+by[\s\n]+attorneys,[\s\n]+psychotherapists,[\s\n]+or[\s\n]+clergy,[\s\n]+and[\s\n]+their[\s\n]+assistants.[\s\n]+Such[\s\n]+communications[\s\n]+and[\s\n]+work[\s\n]+product[\s\n]+are[\s\n]+private[\s\n]+and[\s\n]+confidential.[\s\n]+See[\s\n]+User[\s\n]+Agreement[\s\n]+for[\s\n]+details."
gconftool-2 --direct --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory --type bool --set /apps/gdm/simple-greeter/banner_message_enable true &>/dev/null
gconftool-2 --direct --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory --type string --set /apps/gdm/simple-greeter/banner_message_text "$(echo $gui_login_banner_text | sed -e 's/\[\\s\\n\][+|*]/ /g' -e 's/\&/\&/g' -e 's/\\//g' -e 's/ - /\n- /g')" &>/dev/null
|
Modify the System Login Banner
[ref]rule
To configure the system login banner:
Edit /etc/issue . Replace the default text with a message
compliant with the local site policy or a legal disclaimer.
The DoD required text is either:
You are accessing a U.S. Government (USG) Information System (IS) that is
provided for USG-authorized use only. By using this IS (which includes any
device attached to this IS), you consent to the following conditions:
-The USG routinely intercepts and monitors communications on this IS for purposes
including, but not limited to, penetration testing, COMSEC monitoring, network
operations and defense, personnel misconduct (PM), law enforcement (LE), and
counterintelligence (CI) investigations.
-At any time, the USG may inspect and seize data stored on this IS.
-Communications using, or data stored on, this IS are not private, are subject
to routine monitoring, interception, and search, and may be disclosed or used
for any USG-authorized purpose.
-This IS includes security measures (e.g., authentication and access controls)
to protect USG interests -- not for your personal benefit or privacy.
-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative
searching or monitoring of the content of privileged communications, or work
product, related to personal representation or services by attorneys,
psychotherapists, or clergy, and their assistants. Such communications and work
product are private and confidential. See User Agreement for details.
OR:
I've read & consent to terms in IS user agreem't.
Rationale:
An appropriate warning message reinforces policy awareness during the logon
process and facilitates possible legal action against attackers.
Identifiers:
GEN000400 References:
ECWM-1, 48 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
system_login_banner_text="You[\s\n]+are[\s\n]+accessing[\s\n]+a[\s\n]+U.S.[\s\n]+Government[\s\n]+\(USG\)[\s\n]+Information[\s\n]+System[\s\n]+\(IS\)[\s\n]+that[\s\n]+is[\s\n]+provided[\s\n]+for[\s\n]+USG-authorized[\s\n]+use[\s\n]+only.[\s\n]*By[\s\n]+using[\s\n]+this[\s\n]+IS[\s\n]+\(which[\s\n]+includes[\s\n]+any[\s\n]+device[\s\n]+attached[\s\n]+to[\s\n]+this[\s\n]+IS\),[\s\n]+you[\s\n]+consent[\s\n]+to[\s\n]+the[\s\n]+following[\s\n]+conditions\:[\s\n]*-[\s\n]*The[\s\n]+USG[\s\n]+routinely[\s\n]+intercepts[\s\n]+and[\s\n]+monitors[\s\n]+communications[\s\n]+on[\s\n]+this[\s\n]+IS[\s\n]+for[\s\n]+purposes[\s\n]+including,[\s\n]+but[\s\n]+not[\s\n]+limited[\s\n]+to,[\s\n]+penetration[\s\n]+testing,[\s\n]+COMSEC[\s\n]+monitoring,[\s\n]+network[\s\n]+operations[\s\n]+and[\s\n]+defense,[\s\n]+personnel[\s\n]+misconduct[\s\n]+\(PM\),[\s\n]+law[\s\n]+enforcement[\s\n]+\(LE\),[\s\n]+and[\s\n]+counterintelligence[\s\n]+\(CI\)[\s\n]+investigations.[\s\n]*-[\s\n]*At[\s\n]+any[\s\n]+time,[\s\n]+the[\s\n]+USG[\s\n]+may[\s\n]+inspect[\s\n]+and[\s\n]+seize[\s\n]+data[\s\n]+stored[\s\n]+on[\s\n]+this[\s\n]+IS.[\s\n]*-[\s\n]*Communications[\s\n]+using,[\s\n]+or[\s\n]+data[\s\n]+stored[\s\n]+on,[\s\n]+this[\s\n]+IS[\s\n]+are[\s\n]+not[\s\n]+private,[\s\n]+are[\s\n]+subject[\s\n]+to[\s\n]+routine[\s\n]+monitoring,[\s\n]+interception,[\s\n]+and[\s\n]+search,[\s\n]+and[\s\n]+may[\s\n]+be[\s\n]+disclosed[\s\n]+or[\s\n]+used[\s\n]+for[\s\n]+any[\s\n]+USG-authorized[\s\n]+purpose.[\s\n]*-[\s\n]*This[\s\n]+IS[\s\n]+includes[\s\n]+security[\s\n]+measures[\s\n]+\(e.g.,[\s\n]+authentication[\s\n]+and[\s\n]+access[\s\n]+controls\)[\s\n]+to[\s\n]+protect[\s\n]+USG[\s\n]+interests[\s\n]+--[\s\n]+not[\s\n]+for[\s\n]+your[\s\n]+personal[\s\n]+benefit[\s\n]+or[\s\n]+privacy.[\s\n]*-[\s\n]*Notwithstanding[\s\n]+the[\s\n]+above,[\s\n]+using[\s\n]+this[\s\n]+IS[\s\n]+does[\s\n]+not[\s\n]+constitute[\s\n]+consent[\s\n]+to[\s\n]+PM,[\s\n]+LE[\s\n]+or[\s\n]+CI[\s\n]+investigative[\s\n]+searching[\s\n]+or[\s\n]+monitoring[\s\n]+of[\s\n]+the[\s\n]+content[\s\n]+of[\s\n]+privileged[\s\n]+communications,[\s\n]+or[\s\n]+work[\s\n]+product,[\s\n]+related[\s\n]+to[\s\n]+personal[\s\n]+representation[\s\n]+or[\s\n]+services[\s\n]+by[\s\n]+attorneys,[\s\n]+psychotherapists,[\s\n]+or[\s\n]+clergy,[\s\n]+and[\s\n]+their[\s\n]+assistants.[\s\n]+Such[\s\n]+communications[\s\n]+and[\s\n]+work[\s\n]+product[\s\n]+are[\s\n]+private[\s\n]+and[\s\n]+confidential.[\s\n]+See[\s\n]+User[\s\n]+Agreement[\s\n]+for[\s\n]+details."
echo $system_login_banner_text | sed -e 's/\[\\s\\n\][+|*]/ /g' -e 's/\&/\&/g' -e 's/\\//g' -e 's/ - /\n- /g' >/etc/issue
|
Create Warning Banners for All FTP Users
[ref]ruleEdit the vsftpd configuration file, which resides at /etc/vsftpd/vsftpd.conf
by default. Add or correct the following configuration options:
banner_file=/etc/issue
Rationale:This setting will cause the system greeting banner to be used for FTP connections as well. Identifiers:
GEN000410 References:
ECWM-1, 48 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
ftp_login_banner_text="You[\s\n]+are[\s\n]+accessing[\s\n]+a[\s\n]+U.S.[\s\n]+Government[\s\n]+\(USG\)[\s\n]+Information[\s\n]+System[\s\n]+\(IS\)[\s\n]+that[\s\n]+is[\s\n]+provided[\s\n]+for[\s\n]+USG-authorized[\s\n]+use[\s\n]+only.[\s\n]*By[\s\n]+using[\s\n]+this[\s\n]+IS[\s\n]+\(which[\s\n]+includes[\s\n]+any[\s\n]+device[\s\n]+attached[\s\n]+to[\s\n]+this[\s\n]+IS\),[\s\n]+you[\s\n]+consent[\s\n]+to[\s\n]+the[\s\n]+following[\s\n]+conditions\:[\s\n]*-[\s\n]*The[\s\n]+USG[\s\n]+routinely[\s\n]+intercepts[\s\n]+and[\s\n]+monitors[\s\n]+communications[\s\n]+on[\s\n]+this[\s\n]+IS[\s\n]+for[\s\n]+purposes[\s\n]+including,[\s\n]+but[\s\n]+not[\s\n]+limited[\s\n]+to,[\s\n]+penetration[\s\n]+testing,[\s\n]+COMSEC[\s\n]+monitoring,[\s\n]+network[\s\n]+operations[\s\n]+and[\s\n]+defense,[\s\n]+personnel[\s\n]+misconduct[\s\n]+\(PM\),[\s\n]+law[\s\n]+enforcement[\s\n]+\(LE\),[\s\n]+and[\s\n]+counterintelligence[\s\n]+\(CI\)[\s\n]+investigations.[\s\n]*-[\s\n]*At[\s\n]+any[\s\n]+time,[\s\n]+the[\s\n]+USG[\s\n]+may[\s\n]+inspect[\s\n]+and[\s\n]+seize[\s\n]+data[\s\n]+stored[\s\n]+on[\s\n]+this[\s\n]+IS.[\s\n]*-[\s\n]*Communications[\s\n]+using,[\s\n]+or[\s\n]+data[\s\n]+stored[\s\n]+on,[\s\n]+this[\s\n]+IS[\s\n]+are[\s\n]+not[\s\n]+private,[\s\n]+are[\s\n]+subject[\s\n]+to[\s\n]+routine[\s\n]+monitoring,[\s\n]+interception,[\s\n]+and[\s\n]+search,[\s\n]+and[\s\n]+may[\s\n]+be[\s\n]+disclosed[\s\n]+or[\s\n]+used[\s\n]+for[\s\n]+any[\s\n]+USG-authorized[\s\n]+purpose.[\s\n]*-[\s\n]*This[\s\n]+IS[\s\n]+includes[\s\n]+security[\s\n]+measures[\s\n]+\(e.g.,[\s\n]+authentication[\s\n]+and[\s\n]+access[\s\n]+controls\)[\s\n]+to[\s\n]+protect[\s\n]+USG[\s\n]+interests[\s\n]+--[\s\n]+not[\s\n]+for[\s\n]+your[\s\n]+personal[\s\n]+benefit[\s\n]+or[\s\n]+privacy.[\s\n]*-[\s\n]*Notwithstanding[\s\n]+the[\s\n]+above,[\s\n]+using[\s\n]+this[\s\n]+IS[\s\n]+does[\s\n]+not[\s\n]+constitute[\s\n]+consent[\s\n]+to[\s\n]+PM,[\s\n]+LE[\s\n]+or[\s\n]+CI[\s\n]+investigative[\s\n]+searching[\s\n]+or[\s\n]+monitoring[\s\n]+of[\s\n]+the[\s\n]+content[\s\n]+of[\s\n]+privileged[\s\n]+communications,[\s\n]+or[\s\n]+work[\s\n]+product,[\s\n]+related[\s\n]+to[\s\n]+personal[\s\n]+representation[\s\n]+or[\s\n]+services[\s\n]+by[\s\n]+attorneys,[\s\n]+psychotherapists,[\s\n]+or[\s\n]+clergy,[\s\n]+and[\s\n]+their[\s\n]+assistants.[\s\n]+Such[\s\n]+communications[\s\n]+and[\s\n]+work[\s\n]+product[\s\n]+are[\s\n]+private[\s\n]+and[\s\n]+confidential.[\s\n]+See[\s\n]+User[\s\n]+Agreement[\s\n]+for[\s\n]+details."
if [ -e /etc/xinetd.d/gssftp ]; then
if [ "`egrep -c '^(\s|\t)banner' /etc/xinetd.d/gssftp`" = "0" ]; then
sed -i "/^}$/i\\\tbanner\t\t= /etc/issue" /etc/xinetd.d/gssftp
else
GSSFTP_BANNER_FILE="`egrep '^(\s|\t)banner' /etc/xinetd.d/gssftp | awk '{ print $3 }'`"
echo $ftp_login_banner_text | sed -e 's/\[\\s\\n\][+|*]/ /g' -e 's/\&/\&/g' -e 's/\\//g' -e 's/ - /\n- /g' >"${GSSFTP_BANNER_FILE}"
fi
fi
if [ -e /etc/vsftpd/vsftpd.conf ]; then
if [ "`egrep -c '^banner_file' /etc/vsftpd/vsftpd.conf`" = "0" ]; then
echo "banner_file=/etc/issue" >> /etc/vsftpd/vsftpd.conf
else
VSFTPD_BANNER_FILE="`egrep '^banner_file' /etc/vsftpd/vsftpd.conf | awk -F= '{ print $2 }'`"
echo $ftp_login_banner_text | sed -e 's/\[\\s\\n\][+|*]/ /g' -e 's/\&/\&/g' -e 's/\\//g' -e 's/ - /\n- /g' >"${VSFTPD_BANNER_FILE}"
fi
fi
|
Network Configuration and Firewalls
[ref]groupMost 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.
This section also discusses firewalls, network access
controls, and other network security frameworks, which allow
system-level rules to be written that can limit an attackers' ability
to connect to your system. These rules can specify that network
traffic should be allowed or denied from certain IP addresses,
hosts, and networks. The rules can also specify which of the
system's network services are available to particular hosts or
networks. |
contains 29 rules |
Kernel Parameters Which Affect Networking
[ref]groupThe sysctl utility is used to set
parameters which affect the operation of the Linux kernel. Kernel parameters
which affect networking and have security implications are described here.
|
contains 8 rules |
Network Parameters for Hosts Only
[ref]groupIf 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 Interfaces
[ref]rule
To set the runtime status of the net.ipv4.conf.all.send_redirects kernel parameter,
run the following command:
$ sudo sysctl -w net.ipv4.conf.all.send_redirects=0
If this is not the system's default value, add the following line to /etc/sysctl.conf :
net.ipv4.conf.all.send_redirects = 0
Rationale: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 Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
/sbin/sysctl -q -n -w net.ipv4.conf.all.send_redirects=0
/sbin/sysctl -q -n -w net.ipv4.conf.default.send_redirects=0
if grep --silent ^net.ipv4.conf.all.send_redirects /etc/sysctl.conf ; then
sed -i 's/^net.ipv4.conf.all.send_redirects.*/net.ipv4.conf.all.send_redirects = 0/g' /etc/sysctl.conf
else
echo "" >> /etc/sysctl.conf
echo "# Set net.ipv4.conf.all.send_redirects to 0 per security requirements" >> /etc/sysctl.conf
echo "net.ipv4.conf.all.send_redirects = 0" >> /etc/sysctl.conf
fi
if grep --silent ^net.ipv4.conf.default.send_redirects /etc/sysctl.conf ; then
sed -i 's/^net.ipv4.conf.default.send_redirects.*/net.ipv4.conf.default.send_redirects = 0/g' /etc/sysctl.conf
else
echo "" >> /etc/sysctl.conf
echo "# Set net.ipv4.conf.default.send_redirects to 0 per security requirements" >> /etc/sysctl.conf
echo "net.ipv4.conf.default.send_redirects = 0" >> /etc/sysctl.conf
fi
|
Disable Kernel Parameter for IP Forwarding
[ref]rule
To set the runtime status of the net.ipv4.ip_forward kernel parameter,
run the following command:
$ sudo sysctl -w net.ipv4.ip_forward=0
If this is not the system's default value, add the following line to /etc/sysctl.conf :
net.ipv4.ip_forward = 0
Rationale: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. Identifiers:
GEN005600 References:
ECSC-1, 366 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
#
# Set runtime for net.ipv4.ip_forward
#
/sbin/sysctl -q -n -w net.ipv4.ip_forward=0
#
# If net.ipv4.ip_forward present in /etc/sysctl.conf, change value to "0"
# else, add "net.ipv4.ip_forward = 0" to /etc/sysctl.conf
#
if grep --silent ^net.ipv4.ip_forward /etc/sysctl.conf ; then
sed -i 's/^net.ipv4.ip_forward.*/net.ipv4.ip_forward = 0/g' /etc/sysctl.conf
else
echo -e "\n# Set net.ipv4.ip_forward to 0 per security requirements" >> /etc/sysctl.conf
echo "net.ipv4.ip_forward = 0" >> /etc/sysctl.conf
fi
|
Network Related Kernel Runtime Parameters for Hosts and Routers
[ref]groupCertain 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 Interfaces
[ref]rule
To set the runtime status of the net.ipv4.conf.all.accept_source_route kernel parameter,
run the following command:
$ sudo sysctl -w net.ipv4.conf.all.accept_source_route=0
If this is not the system's default value, add the following line to /etc/sysctl.conf :
net.ipv4.conf.all.accept_source_route = 0
Rationale:Accepting source-routed packets in the IPv4 protocol has few legitimate
uses. It should be disabled unless it is absolutely required. Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
/sbin/sysctl -q -n -w net.ipv4.conf.all.accept_source_route=0
/sbin/sysctl -q -n -w net.ipv4.conf.default.accept_source_route=0
if grep --silent ^net.ipv4.conf.all.accept_source_route /etc/sysctl.conf ; then
sed -i 's/^net.ipv4.conf.all.accept_source_route.*/net.ipv4.conf.all.accept_source_route = 0/g' /etc/sysctl.conf
else
echo "" >> /etc/sysctl.conf
echo "# Set net.ipv4.conf.all.accept_source_route to 0 per security requirements" >> /etc/sysctl.conf
echo "net.ipv4.conf.all.accept_source_route = 0" >> /etc/sysctl.conf
fi
if grep --silent ^net.ipv4.conf.default.accept_source_route /etc/sysctl.conf ; then
sed -i 's/^net.ipv4.conf.default.accept_source_route.*/net.ipv4.conf.default.accept_source_route = 0/g' /etc/sysctl.conf
else
echo "" >> /etc/sysctl.conf
echo "# Set net.ipv4.conf.default.accept_source_route to 0 per security requirements" >> /etc/sysctl.conf
echo "net.ipv4.conf.default.accept_source_route = 0" >> /etc/sysctl.conf
fi
|
Disable Kernel Parameter for Accepting ICMP Redirects for All Interfaces
[ref]rule
To set the runtime status of the net.ipv4.conf.all.accept_redirects kernel parameter,
run the following command:
$ sudo sysctl -w net.ipv4.conf.all.accept_redirects=0
If this is not the system's default value, add the following line to /etc/sysctl.conf :
net.ipv4.conf.all.accept_redirects = 0
Rationale:Accepting ICMP redirects has few legitimate
uses. It should be disabled unless it is absolutely required. Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
/sbin/sysctl -q -n -w net.ipv4.conf.all.accept_redirects=0
/sbin/sysctl -q -n -w net.ipv4.conf.default.accept_redirects=0
if grep --silent ^net.ipv4.conf.all.accept_redirects /etc/sysctl.conf ; then
sed -i 's/^net.ipv4.conf.all.accept_redirects.*/net.ipv4.conf.all.accept_redirects = 0/g' /etc/sysctl.conf
else
echo "" >> /etc/sysctl.conf
echo "# Set net.ipv4.conf.all.accept_redirects to 0 per security requirements" >> /etc/sysctl.conf
echo "net.ipv4.conf.all.accept_redirects = 0" >> /etc/sysctl.conf
fi
if grep --silent ^net.ipv4.conf.default.accept_redirects /etc/sysctl.conf ; then
sed -i 's/^net.ipv4.conf.default.accept_redirects.*/net.ipv4.conf.default.accept_redirects = 0/g' /etc/sysctl.conf
else
echo "" >> /etc/sysctl.conf
echo "# Set net.ipv4.conf.default.accept_redirects to 0 per security requirements" >> /etc/sysctl.conf
echo "net.ipv4.conf.default.accept_redirects = 0" >> /etc/sysctl.conf
fi
|
Enable Kernel Parameter to Log Martian Packets
[ref]rule
To set the runtime status of the net.ipv4.conf.all.log_martians kernel parameter,
run the following command:
$ sudo sysctl -w net.ipv4.conf.all.log_martians=1
If this is not the system's default value, add the following line to /etc/sysctl.conf :
net.ipv4.conf.all.log_martians = 1
Rationale: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. Identifiers:
GEN003611 References:
ECAT-1, 126 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
/sbin/sysctl -q -n -w net.ipv4.conf.all.log_martians=1
/sbin/sysctl -q -n -w net.ipv4.conf.default.log_martians=1
if grep --silent ^net.ipv4.conf.all.log_martians /etc/sysctl.conf ; then
sed -i 's/^net.ipv4.conf.all.log_martians.*/net.ipv4.conf.all.log_martians = 1/g' /etc/sysctl.conf
else
echo "" >> /etc/sysctl.conf
echo "# Set net.ipv4.conf.all.log_martians to 1 per security requirements" >> /etc/sysctl.conf
echo "net.ipv4.conf.all.log_martians = 1" >> /etc/sysctl.conf
fi
if grep --silent ^net.ipv4.conf.default.log_martians /etc/sysctl.conf ; then
sed -i 's/^net.ipv4.conf.default.log_martians.*/net.ipv4.conf.default.log_martians = 1/g' /etc/sysctl.conf
else
echo "" >> /etc/sysctl.conf
echo "# Set net.ipv4.conf.default.log_martians to 1 per security requirements" >> /etc/sysctl.conf
echo "net.ipv4.conf.default.log_martians = 1" >> /etc/sysctl.conf
fi
|
Enable Kernel Parameter to Ignore ICMP Broadcast Echo Requests
[ref]rule
To set the runtime status of the net.ipv4.icmp_echo_ignore_broadcasts kernel parameter,
run the following command:
$ sudo sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=1
If this is not the system's default value, add the following line to /etc/sysctl.conf :
net.ipv4.icmp_echo_ignore_broadcasts = 1
Rationale:Ignoring ICMP echo requests (pings) sent to broadcast or multicast
addresses makes the system slightly more difficult to enumerate on the network.
Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
#
# Set runtime for net.ipv4.icmp_echo_ignore_broadcasts
#
/sbin/sysctl -q -n -w net.ipv4.icmp_echo_ignore_broadcasts=1
#
# If net.ipv4.icmp_echo_ignore_broadcasts present in /etc/sysctl.conf, change value to "1"
# else, add "net.ipv4.icmp_echo_ignore_broadcasts = 1" to /etc/sysctl.conf
#
if grep --silent ^net.ipv4.icmp_echo_ignore_broadcasts /etc/sysctl.conf ; then
sed -i 's/^net.ipv4.icmp_echo_ignore_broadcasts.*/net.ipv4.icmp_echo_ignore_broadcasts = 1/g' /etc/sysctl.conf
else
echo -e "\n# Set net.ipv4.icmp_echo_ignore_broadcasts to 1 per security requirements" >> /etc/sysctl.conf
echo "net.ipv4.icmp_echo_ignore_broadcasts = 1" >> /etc/sysctl.conf
fi
|
Enable Kernel Parameter to Use TCP Syncookies
[ref]rule
To set the runtime status of the net.ipv4.tcp_syncookies kernel parameter,
run the following command:
$ sudo sysctl -w net.ipv4.tcp_syncookies=1
If this is not the system's default value, add the following line to /etc/sysctl.conf :
net.ipv4.tcp_syncookies = 1
Rationale: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 Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
#
# Set runtime for net.ipv4.tcp_syncookies
#
/sbin/sysctl -q -n -w net.ipv4.tcp_syncookies=1
#
# If net.ipv4.tcp_syncookies present in /etc/sysctl.conf, change value to "1"
# else, add "net.ipv4.tcp_syncookies = 1" to /etc/sysctl.conf
#
if grep --silent ^net.ipv4.tcp_syncookies /etc/sysctl.conf ; then
sed -i 's/^net.ipv4.tcp_syncookies.*/net.ipv4.tcp_syncookies = 1/g' /etc/sysctl.conf
else
echo -e "\n# Set net.ipv4.tcp_syncookies to 1 per security requirements" >> /etc/sysctl.conf
echo "net.ipv4.tcp_syncookies = 1" >> /etc/sysctl.conf
fi
|
TCP backlog queue sizes must be set appropriately
[ref]rule
To set the runtime status of the net.ipv4.max_syn_backlog kernel parameter,
run the following command:
$ sudo sysctl -w net.ipv4.max_syn_backlog=1280
If this is not the system's default value, add the following line to /etc/sysctl.conf :
net.ipv4.max_syn_backlog = 1280
Rationale: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.
Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
#
# Set runtime for net.ipv4.tcp_max_syn_backlog
#
/sbin/sysctl -q -n -w net.ipv4.tcp_max_syn_backlog=1280
#
# If net.ipv4.tcp_max_syn_backlog present in /etc/sysctl.conf, change value to "1280"
# else, add "net.ipv4.tcp_max_syn_backlog = 1280" to /etc/sysctl.conf
#
if grep --silent ^net.ipv4.tcp_max_syn_backlog /etc/sysctl.conf ; then
sed -i 's/^net.ipv4.tcp_max_syn_backlog.*/net.ipv4.tcp_max_syn_backlog = 1280/g' /etc/sysctl.conf
else
echo -e "\n# Set net.ipv4.tcp_max_syn_backlog to 1280 per security requirements" >> /etc/sysctl.conf
echo "net.ipv4.tcp_max_syn_backlog = 1280" >> /etc/sysctl.conf
fi
|
Wireless Networking
[ref]groupWireless 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.
Removal of hardware provides the greatest assurance that the wireless
capability remains disabled. Acquisition policies often include provisions to
prevent the purchase of equipment that will be used in sensitive spaces and
includes wireless capabilities. If it is impractical to remove the wireless
hardware, and policy permits the device to enter sensitive spaces as long
as wireless is disabled, efforts should instead focus on disabling wireless capability
via software. |
contains 1 rule |
Disable Wireless Through Software Configuration
[ref]groupIf 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 Modules
[ref]ruleThe kernel's module loading system can be configured to prevent
loading of the Bluetooth module. Add the following to
the appropriate /etc/modprobe.d configuration file
to prevent the loading of the Bluetooth module:
install net-pf-31 /bin/true
install bluetooth /bin/true
Rationale:If Bluetooth functionality must be disabled, preventing the kernel
from loading the kernel module provides an additional safeguard against its
activation. Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ -d /etc/modprobe.d/ ]; then
echo "install bluetooth /bin/true" >> /etc/modprobe.d/disabled_modules.conf
else
echo "install bluetooth /bin/true" >> /etc/modprobe.conf
fi
|
The 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 Needed
[ref]group
Despite 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 Loading
[ref]ruleTo prevent the IPv6 kernel module (ipv6 ) from loading the
IPv6 networking stack, add the following line to
/etc/modprobe.d/disabled.conf (or another file in
/etc/modprobe.d ):
options ipv6 disable=1
This 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 Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ -d /etc/modprobe.d/ ]; then
echo "install ipv6 /bin/true" >> /etc/modprobe.d/disabled_modules.conf
else
echo "install ipv6 /bin/true" >> /etc/modprobe.conf
fi
chkconfig ip6tables off
|
Disable Interface Usage of IPv6
[ref]ruleTo disable interface usage of IPv6, add or correct the following lines in /etc/sysconfig/network :
NETWORKING_IPV6=no
Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ $(grep -c "^NETWORKING_IPV6" /etc/sysconfig/network) = 0 ]; then
echo "NETWORKING_IPV6=no" | tee -a /etc/sysconfig/network &>/dev/null
else
sed -i 's/NETWORKING_IPV6.*/NETWORKING_IPV6=no/' /etc/sysconfig/network
fi
chkconfig ip6tables off
|
Configure IPv6 Settings if Necessary
[ref]groupA 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 Configuration
[ref]groupDisable the system's acceptance of router
advertisements and redirects by adding or correcting the following
line in /etc/sysconfig/network (note that this does not disable
sending router solicitations):
IPV6_AUTOCONF=no
|
contains 2 rules |
Disable Accepting IPv6 Redirects
[ref]rule
To set the runtime status of the net.ipv6.conf.all.accept_redirects kernel parameter,
run the following command:
$ sudo sysctl -w net.ipv6.conf.all.accept_redirects=0
If this is not the system's default value, add the following line to /etc/sysctl.conf :
net.ipv6.conf.all.accept_redirects = 0
Rationale:
An illicit ICMP redirect message could result in a man-in-the-middle attack.
Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
#
# Set runtime for net.ipv6.conf.all.accept_redirects
#
if [ -e /proc/sys/net/ipv6/ ]; then
/sbin/sysctl -q -n -w net.ipv6.conf.all.accept_redirects=0
fi
#
# If net.ipv6.conf.all.accept_redirects present in /etc/sysctl.conf, change value to "0"
# else, add "net.ipv6.conf.all.accept_redirects = 0" to /etc/sysctl.conf
#
if grep --silent ^net.ipv6.conf.all.accept_redirects /etc/sysctl.conf ; then
sed -i 's/^net.ipv6.conf.all.accept_redirects.*/net.ipv6.conf.all.accept_redirects = 0/g' /etc/sysctl.conf
else
echo "" >> /etc/sysctl.conf
echo "# Set net.ipv6.conf.all.accept_redirects to 0 per security requirements" >> /etc/sysctl.conf
echo "net.ipv6.conf.all.accept_redirects = 0" >> /etc/sysctl.conf
fi
|
Disable Accepting IPv6 Forwarding
[ref]rule
To set the runtime status of the net.ipv6.conf.all.forwarding kernel parameter,
run the following command:
$ sudo sysctl -w net.ipv6.conf.all.forwarding=0
If this is not the system's default value, add the following line to /etc/sysctl.conf :
net.ipv6.conf.all.forwarding = 0
To 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=0
If this is not the system's default value, add the following line to /etc/sysctl.conf :
net.ipv6.conf.default.forwarding = 0
Rationale:
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 Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
#
# Set runtime for net.ipv6.conf.all.forwarding
#
if [ -e /proc/sys/net/ipv6/ ]; then
/sbin/sysctl -q -n -w net.ipv6.conf.all.forwarding=0
fi
#
# If net.ipv6.conf.all.forwarding present in /etc/sysctl.conf, change value to "0"
# else, add "net.ipv6.conf.all.forwarding = 0" to /etc/sysctl.conf
#
if grep --silent ^net.ipv6.conf.all.forwarding /etc/sysctl.conf ; then
sed -i 's/^net.ipv6.conf.all.forwarding.*/net.ipv6.conf.all.forwarding = 0/g' /etc/sysctl.conf
else
echo "" >> /etc/sysctl.conf
echo "# Set net.ipv6.conf.all.forwarding to 0 per security requirements" >> /etc/sysctl.conf
echo "net.ipv6.conf.all.forwarding = 0" >> /etc/sysctl.conf
fi
#
# Set runtime for net.ipv6.conf.default.forwarding
#
if [ -e /proc/sys/net/ipv6/ ]; then
/sbin/sysctl -q -n -w net.ipv6.conf.default.forwarding=0
fi
#
# If net.ipv6.conf.default.forwarding present in /etc/sysctl.conf, change value to "0"
# else, add "net.ipv6.conf.default.forwarding = 0" to /etc/sysctl.conf
#
if grep --silent ^net.ipv6.conf.default.forwarding /etc/sysctl.conf ; then
sed -i 's/^net.ipv6.conf.default.forwarding.*/net.ipv6.conf.default.forwarding = 0/g' /etc/sysctl.conf
else
echo "" >> /etc/sysctl.conf
echo "# Set net.ipv6.conf.default.forwarding to 0 per security requirements" >> /etc/sysctl.conf
echo "net.ipv6.conf.default.forwarding = 0" >> /etc/sysctl.conf
fi
|
Manually Assign IPv6 Router Address
[ref]ruleEdit the file
/etc/sysconfig/network-scripts/ifcfg-interface , and add or correct
the following line (substituting your gateway IP as appropriate):
IPV6_DEFAULTGW=2001:0DB8::0001
Router addresses should be manually set and not accepted via any
auto-configuration or router advertisement.
Identifiers:
GEN005570 References:
ECSC-1, 366 |
iptables and ip6tables
[ref]groupA 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.
Unlike TCP Wrappers, which depends on the network server
program to support and respect the rules written, Netfilter
filtering occurs at the kernel level, before a program can even
process the data from the network packet. As such, any program on
the system is affected by the rules written.
This section provides basic information about strengthening
the iptables and ip6tables configurations included with the system.
For more complete information that may allow the construction of a
sophisticated ruleset tailored to your environment, please consult
the references at the end of this section. |
contains 5 rules |
Inspect and Activate Default Rules
[ref]groupView the currently-enforced iptables rules by running
the command:
# iptables -nL --line-numbers
The 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 restart
The 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 destination
The ip6tables default rules are essentially the same. |
contains 1 rule |
Verify iptables Enabled
[ref]rule
The iptables service can be enabled with the following command:
$ sudo chkconfig --level 2345 iptables on
Rationale:
The iptables service provides the system's host-based firewalling
capability for IPv4 and ICMP.
Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | configure |
---|
#
# Enable iptables for all run levels
#
/sbin/chkconfig --level 0123456 iptables on
#
# Start iptables if not currently running
#
/sbin/service iptables start 1>/dev/null
|
Strengthen the Default Ruleset
[ref]groupThe 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
/etc/sysconfig . Many of the lines in these files are similar
to the command line arguments that would be provided to the programs
/sbin/iptables or /sbin/ip6tables - but some are quite
different.
The following recommendations describe how to strengthen the
default ruleset configuration file. An alternative to editing this
configuration file is to create a shell script that makes calls to
the iptables program to load in rules, and then invokes service
iptables save to write those loaded rules to
/etc/sysconfig/iptables.
The following alterations can be made directly to
/etc/sysconfig/iptables and /etc/sysconfig/ip6tables .
Instructions apply to both unless otherwise noted. Language and address
conventions for regular iptables are used throughout this section;
configuration for ip6tables will be either analogous or explicitly
covered. 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 Replies
[ref]ruleTo reject incoming timestamp requests and replies,
add or correct the following line in
/etc/sysconfig/iptables :
-I INPUT -p icmp -m icmp --icmp-type timestamp-request -j DROP
-I INPUT -p icmp -m icmp --icmp-type timestamp-reply -j DROP
Rationale:The processing of (ICMP) timestamp requests increases
the attack surface of the system. Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ "$(egrep -c '(--icmp-type 14|timestamp-reply) -j DROP')" = "0" ]; then
/sbin/iptables -I INPUT -p ICMP --icmp-type timestamp-reply -j DROP
fi
if [ "$(egrep -c '(--icmp-type 13|timestamp-request) -j DROP')" = "0" ]; then
/sbin/iptables -I INPUT -p ICMP --icmp-type timestamp-request -j DROP
fi
/sbin/iptables-save > /etc/sysconfig/iptables
if [ "$(grep -c 'icmp-type 13' /etc/sysconfig/iptables)" != "0" ]; then
sed -i 's/icmp-type 13/icmp-type timestamp-request/' /etc/sysconfig/iptables
fi
if [ "$(grep -c 'icmp-type 14' /etc/sysconfig/iptables)" != "0" ]; then
sed -i 's/icmp-type 14/icmp-type timestamp-reply/' /etc/sysconfig/iptables
fi
|
Add Reject Rule for INPUT Chain.
[ref]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
/etc/sysconfig/iptables :
:INPUT DROP [0:0]
Rationale:In iptables the default policy is applied only after all
the applicable rules in the table are examined for a match. Setting the
default policy to DROP implements proper design for a firewall, i.e.
any packets which are not explicitly permitted should not be
accepted. Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
/sbin/iptables -A INPUT -j REJECT --reject-with icmp-host-prohibited
/sbin/iptables-save > /etc/sysconfig/iptables
|
Ignore ICMPv6 Echo Requests On a Broadcast Address.
[ref]ruleTo configure the system to ignore ICMPv6 echo requests
on a broadcast address, add or correct the following line in
/etc/sysconfig/ip6tables :
-A INPUT -p icmpv6 -d ff02::1 --icmpv6-type 128 -j DROP
Rationale:Responding to broadcast ICMP echo requests facilitates
network mapping and provides a vector for amplification attacks. Identifiers:
GEN007950 References:
ECSC-1, 366 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ ! -e /etc/sysconfig/ip6tables ] || [ "$(grep -c ^ /etc/sysconfig/ip6tables)" -lt "5" ]; then
echo -e "*filter\n:INPUT DROP [0:0]\n:FORWARD DROP [0:0]\n:OUTPUT ACCEPT [0:0]\nCOMMIT" | tee /etc/sysconfig/ip6tables &>/dev/null
echo "-A INPUT -p icmpv6 -d ff02::1 --icmpv6-type 128 -j DROP" | tee -a /etc/sysconfig/ip6tables &>/dev/null
else
echo "-A INPUT -p icmpv6 -d ff02::1 --icmpv6-type 128 -j DROP" | tee -a /etc/sysconfig/ip6tables &>/dev/null
fi
|
TCP Wrappers Must Be Configured To Grant/Deny Access To Hosts.
[ref]ruleTo configure the system to grant/deny access to hosts, ensure
the following file exists:
/etc/hosts.allow :
In addition, make sure the following file is present and includes the following line:
/etc/hosts.deny :
ALL: ALL
Rationale: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 Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ ! -e /etc/hosts.allow ]; then
>/etc/hosts.allow
chmod 644 /etc/hosts.allow
chown root:root /etc/hosts.allow
fi
if [ ! -e /etc/hosts.deny ]; then
>/etc/hosts.deny
chmod 644 /etc/hosts.deny
chown root:root /etc/hosts.deny
fi
if [ ! -e /var/log/host.access ]; then
>/var/log/host.access
chmod 640 /var/log/host.access
chown root:root /var/log/host.access
fi
if [ $(grep -c "ALL: ALL" /etc/hosts.deny) = 0 ]; then
echo 'ALL: ALL: spawn /bin/echo Access denied on $(/bin/date) from %a for access to %d \(pid %p\)>>/var/log/host.access' | tee -a /etc/hosts.deny &>/dev/null
fi
|
IP Tunnelling Support
[ref]group
Support 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 Tunnels
[ref]ruleTo remove IP tunnels, perform the following command for each IP tunnel:
# ip tun del tunnel
Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
ip tunnel list | cut -d: -f1 | while read TUNNEL_INTERFACE; do ip tunnel del $TUNNEL_INTERFACE 2>/dev/null; done
|
Remove 6to4 IP Tunnels
[ref]ruleTo remove 6to4 IP tunnels, perform the following command for each IP tunnel:
# ip tun del tunnel
Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
ip tunnel list | cut -d: -f1 | while read TUNNEL_INTERFACE; do ip tunnel del $TUNNEL_INTERFACE 2>/dev/null; done
|
Disable Teredo Services
[ref]ruleTo disable teredo services, perform the following command:
# ps ax | grep -i miredo | grep -v grep | awk ' { print $1 }' | xargs kill
Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
ps ax | grep -i miredo | grep -v grep | awk ' { print $1 }' | xargs kill
|
Uncommon Network Protocols
[ref]groupThe 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 Support
[ref]rule
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 dccp
kernel module from being loaded, add the following line to a file in the directory /etc/modprobe.d :
install dccp /bin/true
Rationale:
Disabling DCCP protects
the system against exploitation of any flaws in its implementation.
Identifiers:
GEN007080 References:
ECSC-1, 382 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ -d /etc/modprobe.d/ ]; then
echo "install dccp /bin/true" >> /etc/modprobe.d/disabled_modules.conf
echo "install dccp_ipv4 /bin/true" >> /etc/modprobe.d/disabled_modules.conf
echo "install dccp_ipv6 /bin/true" >> /etc/modprobe.d/disabled_modules.conf
else
echo "install dccp /bin/true" >> /etc/modprobe.conf
echo "install dccp_ipv4 /bin/true" >> /etc/modprobe.conf
echo "install dccp_ipv6 /bin/true" >> /etc/modprobe.conf
fi
|
Disable SCTP Support
[ref]rule
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 sctp
kernel module from being loaded, add the following line to a file in the directory /etc/modprobe.d :
install sctp /bin/true
Rationale:
Disabling SCTP protects
the system against exploitation of any flaws in its implementation.
Identifiers:
GEN007020 References:
ECSC-1, 382 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | configure |
---|
if [ -d /etc/modprobe.d/ ]; then
echo "install sctp /bin/true" >> /etc/modprobe.d/disabled_modules.conf
else
echo "install sctp /bin/true" >> /etc/modprobe.conf
fi
|
Disable RDS Support
[ref]rule
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 rds
kernel module from being loaded, add the following line to a file in the directory /etc/modprobe.d :
install rds /bin/true
Rationale:
Disabling RDS protects
the system against exploitation of any flaws in its implementation.
Identifiers:
GEN007480 References:
ECSC-1, 382 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | configure |
---|
if [ -d /etc/modprobe.d/ ]; then
echo "install rds /bin/true" >> /etc/modprobe.d/disabled_modules.conf
else
echo "install rds /bin/true" >> /etc/modprobe.conf
fi
|
Disable TIPC Support
[ref]rule
The Transparent Inter-Process Communication (TIPC) protocol
is designed to provide communications between nodes in a
cluster.
To configure the system to prevent the tipc
kernel module from being loaded, add the following line to a file in the directory /etc/modprobe.d :
install tipc /bin/true
Rationale:
Disabling TIPC protects
the system against exploitation of any flaws in its implementation.
Identifiers:
GEN007540 References:
ECSC-1, 382 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | configure |
---|
if [ -d /etc/modprobe.d/ ]; then
echo "install tipc /bin/true" >> /etc/modprobe.d/disabled_modules.conf
else
echo "install tipc /bin/true" >> /etc/modprobe.conf
fi
|
Disable AppleTalk Support
[ref]rule
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 appletalk
kernel module from being loaded, add the following line to a file in the directory /etc/modprobe.d :
install appletalk /bin/true
Rationale:
Disabling AppleTalk protects
the system against exploitation of any flaws in its implementation.
Identifiers:
GEN007260 References:
ECSC-1, 382 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | configure |
---|
if [ -d /etc/modprobe.d/ ]; then
echo "install appletalk /bin/true" >> /etc/modprobe.d/disabled_modules.conf
else
echo "install appletalk /bin/true" >> /etc/modprobe.conf
fi
|
Disable Network Bridging Support
[ref]rule
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 bridge
kernel module from being loaded, add the following line to a file in the directory /etc/modprobe.d :
install bridge /bin/true
Rationale:
Disabling network bridging protects
the system against exploitation of any flaws in its implementation.
Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | configure |
---|
if [ -d /etc/modprobe.d/ ]; then
echo "install bridge /bin/true" >> /etc/modprobe.d/disabled_modules.conf
else
echo "install bridge /bin/true" >> /etc/modprobe.conf
fi
|
Disable IEEE1394 (Firewire) Support
[ref]rule
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 ieee1394
kernel module from being loaded, add the following line to a file in the directory /etc/modprobe.d :
install ieee1394 /bin/true
Rationale:
Disabling IEEE1394 (Firewire) protects
the system against exploitation of any flaws in its implementation.
Identifiers:
GEN008500 References:
ECSC-1, 366 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | configure |
---|
if [ -d /etc/modprobe.d/ ]; then
echo "install ieee1394 /bin/true" >> /etc/modprobe.d/disabled_modules.conf
else
echo "install ieee1394 /bin/true" >> /etc/modprobe.conf
fi
|
Configure Syslog
[ref]groupThe 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 |
Syslog Logs Sent To Remote Host
[ref]group
If system logs are to be useful in detecting malicious
activities, it is necessary to send logs to a remote server. An
intruder who has compromised the root account on a machine may
delete the log entries which indicate that the system was attacked
before they are seen by an administrator.
However, it is recommended that logs be stored on the local
host in addition to being sent to the loghost, especially if
syslog has been configured to use the UDP protocol to send
messages over a network. UDP does not guarantee reliable delivery,
and moderately busy sites will lose log messages occasionally,
especially in periods of high traffic which may be the result of an
attack. In addition, remote syslog messages are not
authenticated in any way by default, so it is easy for an attacker to
introduce spurious messages to the central log server. Also, some
problems cause loss of network connectivity, which will prevent the
sending of messages to the central server. For all of these reasons, it is
better to store log messages both centrally and on each host, so
that they can be correlated if necessary. |
contains 1 rule |
Ensure Logs Sent To Remote Host
[ref]rule
To configure syslog to send logs to a remote log server,
open /etc/syslog.conf and read and understand the last section of the file,
which describes the multiple directives necessary to activate remote
logging.
Along with these other directives, the system can be configured
to forward its logs to a particular log server by
adding or correcting one of the following lines,
substituting loghost.example.com appropriately.
The choice of protocol depends on the environment of the system;
although TCP and RELP provide more reliable message delivery,
they may not be supported in all environments.
To use UDP for log message delivery:
*.* @loghost.example.com
To use TCP for log message delivery:
*.* @@loghost.example.com
To use RELP for log message delivery:
*.* :omrelp:loghost.example.com
Rationale: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.
Identifiers:
GEN005460 References:
ECSC-1, 366 |
Configure syslogd to Accept Remote Messages If Acting as a Log Server
[ref]group
By default, syslog does not listen over the network
for log messages. If needed, modules can be enabled to allow
the syslog daemon to receive messages from other systems and for the system
thus to act as a log server.
If the machine is not a log server, then lines concerning these modules
should remain commented out.
|
contains 1 rule |
Ensure syslog Does Not Accept Remote Messages Unless Acting As Log Server
[ref]ruleThe syslog daemon should not accept remote messages
unless the system acts as a log server.
To ensure that it is not listening on the network, ensure the following lines are
not found in /etc/syslog.conf :
$ModLoad imtcp.so
$InputTCPServerRun port
$ModLoad imudp.so
$InputUDPServerRun port
$ModLoad imrelp.so
$InputRELPServerRun port
Rationale:
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.
Identifiers:
GEN005480 References:
ECSC-1, 366 |
Ensure All Logs are Rotated by logrotate
[ref]groupEdit the file /etc/logrotate.d/syslog . Find the first
line, which should look like this (wrapped for clarity):
/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 Periodically
[ref]ruleThe logrotate utility allows for the automatic rotation of
log files. The frequency of rotation is specified in /etc/logrotate.conf ,
which triggers a cron task. To configure logrotate to run daily, add or correct
the following line in /etc/logrotate.conf :
# rotate log files frequency
daily
Rationale: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. Identifiers:
GEN002860 References:
ECSC-1, 366 |
System Accounting with auditd
[ref]groupThe 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, auditd has modest disk space
requirements, and should not noticeably impact system performance.
Government networks often have substantial auditing
requirements and auditd can be configured to meet these
requirements.
Examining some example audit records demonstrates how the Linux audit system
satisfies common requirements.
The following example from Fedora Documentation available at
http://docs.fedoraproject.org/en-US/Fedora/13/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Fixing_Problems-Raw_Audit_Messages.html
shows the substantial amount of information captured in a
two typical "raw" audit messages, followed by a breakdown of the most important
fields. In this example the message is SELinux-related and reports an AVC
denial (and the associated system call) that occurred when the Apache HTTP
Server attempted to access the /var/www/html/file1 file (labeled with
the samba_share_t type):
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)
msg=audit(1226874073.147:96) - The number in parentheses is the unformatted time stamp (Epoch time)
for the event, which can be converted to standard time by using the
date command.
{ getattr } - The item in braces indicates the permission that was denied.
getattr
indicates the source process was trying to read the target file's status information.
This occurs before reading files. This action is denied due to the file being
accessed having the wrong label. Commonly seen permissions include getattr ,
read , and write .
comm="httpd" - The executable that launched the process. The full path of the executable is
found in the
exe= section of the system call (SYSCALL ) message,
which in this case, is exe="/usr/sbin/httpd" .
path="/var/www/html/file1" - The path to the object (target) the process attempted to access.
scontext="unconfined_u:system_r:httpd_t:s0" - The SELinux context of the process that attempted the denied action. In
this case, it is the SELinux context of the Apache HTTP Server, which is running
in the
httpd_t domain.
tcontext="unconfined_u:object_r:samba_share_t:s0" - The SELinux context of the object (target) the process attempted to access.
In this case, it is the SELinux context of
file1 . Note: the samba_share_t
type is not accessible to processes running in the httpd_t domain.
- From the system call (
SYSCALL ) message, two items are of interest:
success=no : indicates whether the denial (AVC) was enforced or not.
success=no indicates the system call was not successful (SELinux denied
access). success=yes indicates the system call was successful - this can
be seen for permissive domains or unconfined domains, such as initrc_t
and kernel_t .
exe="/usr/sbin/httpd" : the full path to the executable that launched
the process, which in this case, is exe="/usr/sbin/httpd" .
|
contains 40 rules |
Configure auditd Data Retention
[ref]group
The audit system writes data to /var/log/audit/audit.log . By default,
auditd rotates 5 logs by size (6MB), retaining a maximum of 30MB of
data in total, and refuses to write entries when the disk is too
full. This minimizes the risk of audit data filling its partition
and impacting other services. This also minimizes the risk of the audit
daemon temporarily disabling the system if it cannot write audit log (which
it can be configured to do).
For a busy
system or a system which is thoroughly auditing system activity, the default settings
for data retention may be
insufficient. The log file size needed will depend heavily on what types
of events are being audited. First configure auditing to log all the events of
interest. Then monitor the log size manually for awhile to determine what file
size will allow you to keep the required data for the correct time period.
Using a dedicated partition for /var/log/audit prevents the
auditd logs from disrupting system functionality if they fill, and,
more importantly, prevents other activity in /var from filling the
partition and stopping the audit trail. (The audit logs are size-limited and
therefore unlikely to grow without bound unless configured to do so.) Some
machines may have requirements that no actions occur which cannot be audited.
If this is the case, then auditd can be configured to halt the machine
if it runs out of space. Note: Since older logs are rotated,
configuring auditd this way does not prevent older logs from being
rotated away before they can be viewed.
If your system is configured to halt when logging cannot be performed, make
sure this can never happen under normal circumstances! Ensure that
/var/log/audit is on its own partition, and that this partition is
larger than the maximum amount of data auditd will retain
normally.
References:
AU-11, 138 |
contains 3 rules |
Configure auditd space_left Action on Low Disk Space
[ref]ruleThe auditd service can be configured to take an action
when disk space starts to run low.
Edit the file /etc/audit/auditd.conf . Modify the following line,
substituting ACTION appropriately:
space_left_action = ACTION
Possible values for ACTION are described in the auditd.conf man page.
These include:
ignore syslog email exec suspend single halt
Set this to 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. Identifiers:
GEN002730 References:
ECSC-1, 143 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ -e /etc/audit/auditd.conf ]; then
AUDITD_CONF_FILE="/etc/audit/auditd.conf"
elif [ -e /etc/auditd.conf ]; then
AUDITD_CONF_FILE="/etc/auditd.conf"
else
exit
fi
if [ "$(grep -v "#" ${AUDITD_CONF_FILE} | grep -c space_left_action)" != "0" ]; then
sed -i 's/space_left_action.*/space_left_action = syslog/' ${AUDITD_CONF_FILE}
else
echo "space_left_action = syslog">>${AUDITD_CONF_FILE}
fi
|
Configure auditd disk_error_action and disk_full_action on Storage Failures
[ref]ruleThe auditd service can be configured to take an action
when the disk errors or becomes full.
Edit the file /etc/audit/auditd.conf . Add or modify the following lines,
substituting ACTION appropriately:
disk_error_action = ACTION
disk_full_action = ACTION
Set 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.
Identifiers:
GEN002719 References:
ECAT-1, 139 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
var_auditd_disk_error_action="syslog"
if [ -e /etc/audit/auditd.conf ]; then
AUDITD_CONF_FILE="/etc/audit/auditd.conf"
elif [ -e /etc/auditd.conf ]; then
AUDITD_CONF_FILE="/etc/auditd.conf"
else
exit
fi
grep -q ^disk_error_action ${AUDITD_CONF_FILE} && \
sed -i "s/disk_error_action.*/disk_error_action = $var_auditd_disk_error_action/g" ${AUDITD_CONF_FILE}
if ! [ $? -eq 0 ]; then
echo "disk_error_action = $var_auditd_disk_error_action" >> ${AUDITD_CONF_FILE}
fi
grep -q ^disk_full_action ${AUDITD_CONF_FILE} && \
sed -i "s/disk_full_action.*/disk_full_action = $var_auditd_disk_error_action/g" ${AUDITD_CONF_FILE}
if ! [ $? -eq 0 ]; then
echo "disk_full_action = $var_auditd_disk_error_action" >> ${AUDITD_CONF_FILE}
fi
|
Configure auditd to use audispd's syslog plugin
[ref]ruleTo configure the auditd service to use the
syslog plug-in of the audispd audit event multiplexor, set
the active line in /etc/audisp/plugins.d/syslog.conf to
yes . Restart the auditd service:
# service auditd restart
Rationale: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 Identifiers:
GEN002870 References:
ECTB-1, 136 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | disable |
---|
grep -q ^active /etc/audisp/plugins.d/syslog.conf && \
sed -i "s/active.*/active = yes/g" /etc/audisp/plugins.d/syslog.conf
if ! [ $? -eq 0 ]; then
echo "active = yes" >> /etc/audisp/plugins.d/syslog.conf
fi
|
Configure auditd Rules for Comprehensive Auditing
[ref]groupThe auditd program can perform comprehensive
monitoring of system activity. This section describes recommended
configuration settings for comprehensive auditing, but a full
description of the auditing system's capabilities is beyond the
scope of this guide. The mailing list linux-audit@redhat.com exists
to facilitate community discussion of the auditing system.
The audit subsystem supports extensive collection of events, including:
- Tracing of arbitrary system calls (identified by name or number)
on entry or exit.
- Filtering by PID, UID, call success, system call argument (with
some limitations), etc.
- Monitoring of specific files for modifications to the file's
contents or metadata.
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 Information
[ref]groupArbitrary 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 adjtimex
[ref]ruleOn a 32-bit system, add the following to /etc/audit/audit.rules :
# audit_time_rules
-a exit,always -F arch=b32 -S adjtimex -k audit_time_rules
On 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_rules
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 exit,always -F arch=b64 -S adjtimex -S settimeofday -k audit_time_rules
Rationale: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 Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ -e /etc/audit/audit.rules ]; then
AUDIT_RULES_FILE="/etc/audit/audit.rules"
AUDIT_TAG="-k audit_time_rules"
elif [ -e /etc/audit.rules ]; then
AUDIT_RULES_FILE="/etc/audit.rules"
AUDIT_TAG=""
else
exit
fi
if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S adjtimex '`" = "0" ]; then
if [ "`uname -p`" != "x86_64" ]; then
echo "-a exit,always -F arch=b32 -S adjtimex ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
else
echo "-a exit,always -F arch=b64 -S adjtimex ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
fi
fi
service auditd restart 1>/dev/null
|
Record attempts to alter time through settimeofday
[ref]ruleOn a 32-bit system, add the following to /etc/audit/audit.rules :
# audit_time_rules
-a exit,always -F arch=b32 -S settimeofday -k audit_time_rules
On 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_rules
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 exit,always -F arch=b64 -S adjtimex -S settimeofday -k audit_time_rules
Rationale: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 Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ -e /etc/audit/audit.rules ]; then
AUDIT_RULES_FILE="/etc/audit/audit.rules"
AUDIT_TAG="-k audit_time_rules"
elif [ -e /etc/audit.rules ]; then
AUDIT_RULES_FILE="/etc/audit.rules"
AUDIT_TAG=""
else
exit
fi
if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S settimeofday '`" = "0" ]; then
if [ "`uname -p`" != "x86_64" ]; then
echo "-a exit,always -F arch=b32 -S settimeofday ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
else
echo "-a exit,always -F arch=b64 -S settimeofday ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
fi
fi
service auditd restart 1>/dev/null
|
Record Attempts to Alter Time Through stime
[ref]ruleAdd the following line to /etc/audit/audit.rules for both
32-bit and 64-bit systems:
# audit_time_rules
-a always,exit -F arch=b32 -S stime -k audit_time_rules
Since 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_rules
Rationale: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 Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ -e /etc/audit/audit.rules ]; then
AUDIT_RULES_FILE="/etc/audit/audit.rules"
AUDIT_TAG="-k audit_time_rules"
elif [ -e /etc/audit.rules ]; then
AUDIT_RULES_FILE="/etc/audit.rules"
AUDIT_TAG=""
else
exit
fi
if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S stime '`" = "0" ]; then
if [ "`uname -p`" != "x86_64" ]; then
echo "-a exit,always -F arch=b32 -S stime ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
# stime is not supported on 64-bit.
fi
fi
service auditd restart 1>/dev/null
|
Record Attempts to Alter Time Through clock_settime
[ref]ruleOn a 32-bit system, add the following to /etc/audit/audit.rules :
# time-change
-a always,exit -F arch=b32 -S clock_settime -F a0=0x0 -F key=time-change
On 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-change
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 exit,always -F arch=b64 -S adjtimex -S settimeofday -k audit_time_rules
Rationale: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 Controls
[ref]groupAt 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 /etc/audit/audit.rules :
-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 - chmod
[ref]ruleAt a minimum the audit system should collect file
permission changes for all users and root. Add the following to
/etc/audit/audit.rules :
-a exit,always -F arch=b32 -S chmod -F auid>=500 -F auid!=4294967295 -k perm_mod
If 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.
Rationale: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 Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ -e /etc/audit/audit.rules ]; then
AUDIT_RULES_FILE="/etc/audit/audit.rules"
AUDIT_TAG="-k perm_mod"
elif [ -e /etc/audit.rules ]; then
AUDIT_RULES_FILE="/etc/audit.rules"
AUDIT_TAG=""
else
exit
fi
if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S chmod '`" = "0" ]; then
if [ "`uname -p`" = "x86_64" ]; then
echo "-a exit,always -F arch=b64 -S chmod ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
else
echo "-a exit,always -F arch=b32 -S chmod ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
fi
fi
service auditd restart 1>/dev/null
|
Record Events that Modify the System's Discretionary Access Controls - chown
[ref]ruleAt a minimum the audit system should collect file
permission changes for all users and root. Add the following to
/etc/audit/audit.rules :
-a exit,always -F arch=b32 -S chown -F auid>=500 -F auid!=4294967295 -k perm_mod
If 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.
Rationale: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 Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ -e /etc/audit/audit.rules ]; then
AUDIT_RULES_FILE="/etc/audit/audit.rules"
AUDIT_TAG="-k perm_mod"
elif [ -e /etc/audit.rules ]; then
AUDIT_RULES_FILE="/etc/audit.rules"
AUDIT_TAG=""
else
exit
fi
if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S chown '`" = "0" ]; then
if [ "`uname -p`" = "x86_64" ]; then
echo "-a exit,always -F arch=b64 -S chown ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
else
echo "-a exit,always -F arch=b32 -S chown ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
fi
fi
if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S chown32 '`" = "0" ]; then
if [ "`uname -p`" = "x86_64" ]; then
echo "-a exit,always -F arch=b64 -S chown32 ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
else
echo "-a exit,always -F arch=b32 -S chown32 ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
fi
fi
service auditd restart 1>/dev/null
|
Record Events that Modify the System's Discretionary Access Controls - fchmod
[ref]ruleAt a minimum the audit system should collect file
permission changes for all users and root. Add the following to
/etc/audit/audit.rules :
-a exit,always -F arch=b32 -S fchmod -F auid>=500 -F auid!=4294967295 -k perm_mod
If 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.
Rationale: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 Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ -e /etc/audit/audit.rules ]; then
AUDIT_RULES_FILE="/etc/audit/audit.rules"
AUDIT_TAG="-k perm_mod"
elif [ -e /etc/audit.rules ]; then
AUDIT_RULES_FILE="/etc/audit.rules"
AUDIT_TAG=""
else
exit
fi
if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S fchmod '`" = "0" ]; then
if [ "`uname -p`" = "x86_64" ]; then
echo "-a exit,always -F arch=b64 -S fchmod ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
else
echo "-a exit,always -F arch=b32 -S fchmod ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
fi
fi
service auditd restart 1>/dev/null
|
Record Events that Modify the System's Discretionary Access Controls - fchmodat
[ref]ruleAt a minimum the audit system should collect file
permission changes for all users and root. Add the following to
/etc/audit/audit.rules :
-a exit,always -F arch=b32 -S fchmodat -F auid>=500 -F auid!=4294967295 -k perm_mod
If 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.
Rationale: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 Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ -e /etc/audit/audit.rules ]; then
AUDIT_RULES_FILE="/etc/audit/audit.rules"
AUDIT_TAG="-k perm_mod"
elif [ -e /etc/audit.rules ]; then
AUDIT_RULES_FILE="/etc/audit.rules"
AUDIT_TAG=""
else
exit
fi
if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S fchmodat '`" = "0" ]; then
if [ "`uname -p`" = "x86_64" ]; then
echo "-a exit,always -F arch=b64 -S fchmodat ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
else
echo "-a exit,always -F arch=b32 -S fchmodat ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
fi
fi
service auditd restart 1>/dev/null
|
Record Events that Modify the System's Discretionary Access Controls - fchown
[ref]ruleAt a minimum the audit system should collect file
permission changes for all users and root. Add the following to
/etc/audit/audit.rules :
-a exit,always -F arch=b32 -S fchown -F auid>=500 -F auid!=4294967295 -k perm_mod
If 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.
Rationale: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 Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ -e /etc/audit/audit.rules ]; then
AUDIT_RULES_FILE="/etc/audit/audit.rules"
AUDIT_TAG="-k perm_mod"
elif [ -e /etc/audit.rules ]; then
AUDIT_RULES_FILE="/etc/audit.rules"
AUDIT_TAG=""
else
exit
fi
if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S fchown '`" = "0" ]; then
if [ "`uname -p`" = "x86_64" ]; then
echo "-a exit,always -F arch=b64 -S fchown ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
else
echo "-a exit,always -F arch=b32 -S fchown ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
fi
fi
if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S fchown32 '`" = "0" ]; then
if [ "`uname -p`" = "x86_64" ]; then
echo "-a exit,always -F arch=b64 -S fchown32 ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
else
echo "-a exit,always -F arch=b32 -S fchown32 ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
fi
fi
service auditd restart 1>/dev/null
|
Record Events that Modify the System's Discretionary Access Controls - fchownat
[ref]ruleAt a minimum the audit system should collect file
permission changes for all users and root. Add the following to
/etc/audit/audit.rules :
-a exit,always -F arch=b32 -S fchownat -F auid>=500 -F auid!=4294967295 -k perm_mod
If 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.
Rationale: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 Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ -e /etc/audit/audit.rules ]; then
AUDIT_RULES_FILE="/etc/audit/audit.rules"
AUDIT_TAG="-k perm_mod"
elif [ -e /etc/audit.rules ]; then
AUDIT_RULES_FILE="/etc/audit.rules"
AUDIT_TAG=""
else
exit
fi
if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S fchownat '`" = "0" ]; then
if [ "`uname -p`" = "x86_64" ]; then
echo "-a exit,always -F arch=b64 -S fchownat ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
else
echo "-a exit,always -F arch=b32 -S fchownat ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
fi
fi
service auditd restart 1>/dev/null
|
Record Events that Modify the System's Discretionary Access Controls - fremovexattr
[ref]ruleAt a minimum the audit system should collect file
permission changes for all users and root. Add the following to
/etc/audit/audit.rules :
-a exit,always -F arch=b32 -S fremovexattr -F auid>=500 -F auid!=4294967295 -k perm_mod
If 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.
Rationale: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 Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ -e /etc/audit/audit.rules ]; then
AUDIT_RULES_FILE="/etc/audit/audit.rules"
AUDIT_TAG="-k perm_mod"
elif [ -e /etc/audit.rules ]; then
AUDIT_RULES_FILE="/etc/audit.rules"
AUDIT_TAG=""
else
exit
fi
if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S fremovexattr '`" = "0" ]; then
if [ "`uname -p`" = "x86_64" ]; then
echo "-a exit,always -F arch=b64 -S fremovexattr ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
else
echo "-a exit,always -F arch=b32 -S fremovexattr ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
fi
fi
service auditd restart 1>/dev/null
|
Record Events that Modify the System's Discretionary Access Controls - fsetxattr
[ref]ruleAt a minimum the audit system should collect file
permission changes for all users and root. Add the following to
/etc/audit/audit.rules :
-a exit,always -F arch=b32 -S fsetxattr -F auid>=500 -F auid!=4294967295 -k perm_mod
If 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.
Rationale: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 Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ -e /etc/audit/audit.rules ]; then
AUDIT_RULES_FILE="/etc/audit/audit.rules"
AUDIT_TAG="-k perm_mod"
elif [ -e /etc/audit.rules ]; then
AUDIT_RULES_FILE="/etc/audit.rules"
AUDIT_TAG=""
else
exit
fi
if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S fsetxattr '`" = "0" ]; then
if [ "`uname -p`" = "x86_64" ]; then
echo "-a exit,always -F arch=b64 -S fsetxattr ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
else
echo "-a exit,always -F arch=b32 -S fsetxattr ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
fi
fi
service auditd restart 1>/dev/null
|
Record Events that Modify the System's Discretionary Access Controls - lchown
[ref]ruleAt a minimum the audit system should collect file
permission changes for all users and root. Add the following to
/etc/audit/audit.rules :
-a exit,always -F arch=b32 -S lchown -F auid>=500 -F auid!=4294967295 -k perm_mod
If 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.
Rationale: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 Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ -e /etc/audit/audit.rules ]; then
AUDIT_RULES_FILE="/etc/audit/audit.rules"
AUDIT_TAG="-k perm_mod"
elif [ -e /etc/audit.rules ]; then
AUDIT_RULES_FILE="/etc/audit.rules"
AUDIT_TAG=""
else
exit
fi
if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S lchown '`" = "0" ]; then
if [ "`uname -p`" = "x86_64" ]; then
echo "-a exit,always -F arch=b64 -S lchown ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
else
echo "-a exit,always -F arch=b32 -S lchown ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
fi
fi
if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S lchown32 '`" = "0" ]; then
if [ "`uname -p`" = "x86_64" ]; then
echo "-a exit,always -F arch=b64 -S lchown32 ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
else
echo "-a exit,always -F arch=b32 -S lchown32 ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
fi
fi
service auditd restart 1>/dev/null
|
Record Events that Modify the System's Discretionary Access Controls - lremovexattr
[ref]ruleAt a minimum the audit system should collect file
permission changes for all users and root. Add the following to
/etc/audit/audit.rules :
-a exit,always -F arch=b32 -S lremovexattr -F auid>=500 -F auid!=4294967295 -k perm_mod
If 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.
Rationale: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 Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ -e /etc/audit/audit.rules ]; then
AUDIT_RULES_FILE="/etc/audit/audit.rules"
AUDIT_TAG="-k perm_mod"
elif [ -e /etc/audit.rules ]; then
AUDIT_RULES_FILE="/etc/audit.rules"
AUDIT_TAG=""
else
exit
fi
if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S lremovexattr '`" = "0" ]; then
if [ "`uname -p`" = "x86_64" ]; then
echo "-a exit,always -F arch=b64 -S lremovexattr ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
else
echo "-a exit,always -F arch=b32 -S lremovexattr ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
fi
fi
service auditd restart 1>/dev/null
|
Record Events that Modify the System's Discretionary Access Controls - lsetxattr
[ref]ruleAt a minimum the audit system should collect file
permission changes for all users and root. Add the following to
/etc/audit/audit.rules :
-a exit,always -F arch=b32 -S lsetxattr -F auid>=500 -F auid!=4294967295 -k perm_mod
If 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.
Rationale: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 Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ -e /etc/audit/audit.rules ]; then
AUDIT_RULES_FILE="/etc/audit/audit.rules"
AUDIT_TAG="-k perm_mod"
elif [ -e /etc/audit.rules ]; then
AUDIT_RULES_FILE="/etc/audit.rules"
AUDIT_TAG=""
else
exit
fi
if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S lsetxattr '`" = "0" ]; then
if [ "`uname -p`" = "x86_64" ]; then
echo "-a exit,always -F arch=b64 -S lsetxattr ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
else
echo "-a exit,always -F arch=b32 -S lsetxattr ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
fi
fi
service auditd restart 1>/dev/null
|
Record Events that Modify the System's Discretionary Access Controls - removexattr
[ref]ruleAt a minimum the audit system should collect file
permission changes for all users and root. Add the following to
/etc/audit/audit.rules :
-a exit,always -F arch=b32 -S removexattr -F auid>=500 -F auid!=4294967295 -k perm_mod
If 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.
Rationale: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 Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ -e /etc/audit/audit.rules ]; then
AUDIT_RULES_FILE="/etc/audit/audit.rules"
AUDIT_TAG="-k perm_mod"
elif [ -e /etc/audit.rules ]; then
AUDIT_RULES_FILE="/etc/audit.rules"
AUDIT_TAG=""
else
exit
fi
if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S removexattr '`" = "0" ]; then
if [ "`uname -p`" = "x86_64" ]; then
echo "-a exit,always -F arch=b64 -S removexattr ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
else
echo "-a exit,always -F arch=b32 -S removexattr ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
fi
fi
service auditd restart 1>/dev/null
|
Record Events that Modify the System's Discretionary Access Controls - setxattr
[ref]ruleAt a minimum the audit system should collect file
permission changes for all users and root. Add the following to
/etc/audit/audit.rules :
-a exit,always -F arch=b32 -S setxattr -F auid>=500 -F auid!=4294967295 -k perm_mod
If 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.
Rationale: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 Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ -e /etc/audit/audit.rules ]; then
AUDIT_RULES_FILE="/etc/audit/audit.rules"
AUDIT_TAG="-k perm_mod"
elif [ -e /etc/audit.rules ]; then
AUDIT_RULES_FILE="/etc/audit.rules"
AUDIT_TAG=""
else
exit
fi
if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S setxattr '`" = "0" ]; then
if [ "`uname -p`" = "x86_64" ]; then
echo "-a exit,always -F arch=b64 -S setxattr ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
else
echo "-a exit,always -F arch=b32 -S setxattr ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
fi
fi
service auditd restart 1>/dev/null
|
Record Events that Create User/Group Information
[ref]ruleAdd the following to /etc/audit/audit.rules , in order
to capture events that create accounts:
# 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_changes
Rationale: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. Identifiers:
GEN002750 References:
ECAT-1, 18 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ -e /etc/audit/audit.rules ]; then
AUDIT_RULES_FILE="/etc/audit/audit.rules"
elif [ -e /etc/audit.rules ]; then
AUDIT_RULES_FILE="/etc/audit.rules"
else
exit
fi
for FILE in /usr/sbin/useradd /usr/sbin/groupadd; do
if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE}"`" = "0" ]; then
echo "-w ${FILE} -p x -k audit_account_creation" >>${AUDIT_RULES_FILE}
elif [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE} -p [wa]*x"`" = "0" ]; then
SED_FILE="$(echo ${FILE} | sed 's/\//\\\//g')"
if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE} -p "`" = "0" ]; then
sed -i "s/\(-w ${SED_FILE}\)/\1 -p x/" ${AUDIT_RULES_FILE}
else
sed -i "s/\(-w ${SED_FILE} -p \)/\1x/" ${AUDIT_RULES_FILE}
fi
fi
done
for FILE in /etc/group /etc/passwd /etc/gshadow /etc/shadow; do
if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE}"`" = "0" ]; then
echo "-w ${FILE} -p a -k audit_account_creation" >>${AUDIT_RULES_FILE}
elif [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE} -p [wx]*a"`" = "0" ]; then
SED_FILE="$(echo ${FILE} | sed 's/\//\\\//g')"
if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE} -p "`" = "0" ]; then
sed -i "s/\(-w ${SED_FILE}\)/\1 -p a/" ${AUDIT_RULES_FILE}
else
sed -i "s/\(-w ${SED_FILE} -p \)/\1a/" ${AUDIT_RULES_FILE}
fi
fi
done
service auditd restart 1>/dev/null
|
Record Events that Disable User Accounts
[ref]ruleAdd the following to /etc/audit/audit.rules , in order
to capture events that disable accounts:
# audit_account_disabling
-w /usr/bin/passwd -p x -k audit_account_disabling
Rationale: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 Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ -e /etc/audit/audit.rules ]; then
AUDIT_RULES_FILE="/etc/audit/audit.rules"
elif [ -e /etc/audit.rules ]; then
AUDIT_RULES_FILE="/etc/audit.rules"
else
exit
fi
if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w /usr/bin/passwd"`" = "0" ]; then
echo "-w /usr/bin/passwd -p x -k audit_account_changes" >>${AUDIT_RULES_FILE}
elif [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w /usr/bin/passwd -p [wa]*x"`" = "0" ]; then
if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w /usr/bin/passwd -p "`" = "0" ]; then
sed -i "s/\(-w \/usr\/bin\/passwd\)/\1 -p x/" ${AUDIT_RULES_FILE}
else
sed -i "s/\(-w \/usr\/bin\/passwd -p \)/\1x/" ${AUDIT_RULES_FILE}
fi
fi
service auditd restart 1>/dev/null
|
Record Events that Modify User/Group Information
[ref]ruleAdd the following to /etc/audit/audit.rules , in order
to capture events that modify account changes:
# 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_changes
Rationale: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 Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ -e /etc/audit/audit.rules ]; then
AUDIT_RULES_FILE="/etc/audit/audit.rules"
elif [ -e /etc/audit.rules ]; then
AUDIT_RULES_FILE="/etc/audit.rules"
else
exit
fi
for FILE in /usr/sbin/usermod /usr/sbin/groupmod; do
if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE}"`" = "0" ]; then
echo "-w ${FILE} -p x -k audit_account_changes" >>${AUDIT_RULES_FILE}
elif [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE} -p [wa]*x"`" = "0" ]; then
SED_FILE="$(echo ${FILE} | sed 's/\//\\\//g')"
if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE} -p "`" = "0" ]; then
sed -i "s/\(-w ${SED_FILE}\)/\1 -p x/" ${AUDIT_RULES_FILE}
else
sed -i "s/\(-w ${SED_FILE} -p \)/\1x/" ${AUDIT_RULES_FILE}
fi
fi
done
for FILE in /etc/group /etc/passwd /etc/gshadow /etc/shadow; do
if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE}"`" = "0" ]; then
echo "-w ${FILE} -p w -k audit_account_changes" >>${AUDIT_RULES_FILE}
elif [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE} -p [xa]*w"`" = "0" ]; then
SED_FILE="$(echo ${FILE} | sed 's/\//\\\//g')"
if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE} -p "`" = "0" ]; then
sed -i "s/\(-w ${SED_FILE}\)/\1 -p w/" ${AUDIT_RULES_FILE}
else
sed -i "s/\(-w ${SED_FILE} -p \)/\1w/" ${AUDIT_RULES_FILE}
fi
fi
done
service auditd restart 1>/dev/null
|
Record Events that Terminate Users/Groups
[ref]ruleAdd the following to /etc/audit/audit.rules , in order
to capture events that terminate accounts:
# audit_account_termination
-w /usr/sbin/groupdel -p x -k audit_account_termination
-w /usr/sbin/userdel -p x -k audit_account_termination
Rationale: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 Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ -e /etc/audit/audit.rules ]; then
AUDIT_RULES_FILE="/etc/audit/audit.rules"
elif [ -e /etc/audit.rules ]; then
AUDIT_RULES_FILE="/etc/audit.rules"
else
exit
fi
for FILE in /usr/sbin/userdel /usr/sbin/groupdel; do
if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE}"`" = "0" ]; then
echo "-w ${FILE} -p x -k audit_account_changes" >>${AUDIT_RULES_FILE}
elif [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE} -p [wa]*x"`" = "0" ]; then
SED_FILE="$(echo ${FILE} | sed 's/\//\\\//g')"
if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE} -p "`" = "0" ]; then
sed -i "s/\(-w ${SED_FILE}\)/\1 -p x/" ${AUDIT_RULES_FILE}
else
sed -i "s/\(-w ${SED_FILE} -p \)/\1x/" ${AUDIT_RULES_FILE}
fi
fi
done
service auditd restart 1>/dev/null
|
Record Events that Modify the System's Host Name
[ref]ruleAdd the following to /etc/audit/audit.rules , setting
ARCH to either b32 or b64 as appropriate for your system:
# audit_network_sethostname
-a exit,always -F arch=ARCH -S sethostname -k audit_network_modifications
Rationale:The network environment should not be modified by anything other
than administrator action. Any change to network parameters should be
audited. Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ -e /etc/audit/audit.rules ]; then
AUDIT_RULES_FILE="/etc/audit/audit.rules"
AUDIT_TAG="-k set_hostname"
elif [ -e /etc/audit.rules ]; then
AUDIT_RULES_FILE="/etc/audit.rules"
AUDIT_TAG=""
else
exit
fi
if [ "`uname -p`" != "x86_64" ]; then
echo "-a exit,always -F arch=b32 -S sethostname ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
else
echo "-a exit,always -F arch=b64 -S sethostname ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
fi
service auditd restart 1>/dev/null
|
Record Events that Modify the System's Domain Name
[ref]ruleAdd the following to /etc/audit/audit.rules , setting
ARCH to either b32 or b64 as appropriate for your system:
# audit_network_setdomainname
-a exit,always -F arch=ARCH -S setdomainname -k audit_network_modifications
Rationale:The network environment should not be modified by anything other
than administrator action. Any change to network parameters should be
audited. Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ -e /etc/audit/audit.rules ]; then
AUDIT_RULES_FILE="/etc/audit/audit.rules"
AUDIT_TAG="-k set_domainname"
elif [ -e /etc/audit.rules ]; then
AUDIT_RULES_FILE="/etc/audit.rules"
AUDIT_TAG=""
else
exit
fi
if [ "`uname -p`" != "x86_64" ]; then
echo "-a exit,always -F arch=b32 -S setdomainname ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
else
echo "-a exit,always -F arch=b64 -S setdomainname ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
fi
service auditd restart 1>/dev/null
|
Record Events that Modify the System's Scheduler Parameters
[ref]ruleAdd the following to /etc/audit/audit.rules , setting
ARCH to either b32 or b64 as appropriate for your system:
# audit_network_sethostname
-a exit,always -F arch=ARCH -S sched_setparam -k scheduler
Rationale:The scheduler parameters should not be modified by anything other
than administrator action. Any change to network parameters should be
audited. Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ -e /etc/audit/audit.rules ]; then
AUDIT_RULES_FILE="/etc/audit/audit.rules"
AUDIT_TAG="-k set_scheduler_parameters"
elif [ -e /etc/audit.rules ]; then
AUDIT_RULES_FILE="/etc/audit.rules"
AUDIT_TAG=""
else
exit
fi
# check for realtime capabilities
if [ `lsmod | grep -ic jiffies` = 0 ]; then
if [ "`uname -p`" != "x86_64" ]; then
echo "-a exit,always -F arch=b32 -S sched_setparam ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
else
echo "-a exit,always -F arch=b64 -S sched_setparam ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
fi
fi
service auditd restart 1>/dev/null
|
Record Events that Modify the System's Scheduler Priorities
[ref]ruleAdd the following to /etc/audit/audit.rules , setting
ARCH to either b32 or b64 as appropriate for your system:
# audit_network_sethostname
-a exit,always -F arch=ARCH -S sched_setscheduler -k scheduler
Rationale:The scheduler priorities should not be modified by anything other
than administrator action. Any change to network parameters should be
audited. Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ -e /etc/audit/audit.rules ]; then
AUDIT_RULES_FILE="/etc/audit/audit.rules"
AUDIT_TAG="-k set_scheduler_setting"
elif [ -e /etc/audit.rules ]; then
AUDIT_RULES_FILE="/etc/audit.rules"
AUDIT_TAG=""
else
exit
fi
# check for realtime capabilities
if [ `lsmod | grep -ic jiffies` = 0 ]; then
if [ "`uname -p`" != "x86_64" ]; then
echo "-a exit,always -F arch=b32 -S sched_setscheduler ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
else
echo "-a exit,always -F arch=b64 -S sched_setscheduler ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
fi
fi
service auditd restart 1>/dev/null
|
Record Attempts to Alter Logon and Logout Events
[ref]rule
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 /etc/audit/audit.rules :
-w /var/log/faillog -p wa -k logins
-w /var/log/lastlog -p wa -k logins
Rationale:Manual editing of these files may indicate nefarious activity, such
as an attacker attempting to remove evidence of an intrusion. Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ -e /etc/audit/audit.rules ]; then
AUDIT_RULES_FILE="/etc/audit/audit.rules"
elif [ -e /etc/audit.rules ]; then
AUDIT_RULES_FILE="/etc/audit.rules"
else
exit
fi
for FILE in /var/log/faillog /var/log/lastlog; do
if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE}"`" = "0" ]; then
echo "-w ${FILE} -p wa -k audit_login_events" >>${AUDIT_RULES_FILE}
elif [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE} -p [x]*\(wa\|aw\)"`" = "0" ]; then
SED_FILE="$(echo ${FILE} | sed 's/\//\\\//g')"
if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE} -p "`" = "0" ]; then
sed -i "s/\(-w ${SED_FILE}\)/\1 -p wa/" ${AUDIT_RULES_FILE}
else
if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE} -p [xa]*w"`" = "0" ]; then
sed -i "s/\(-w ${SED_FILE} -p \)/\1w/" ${AUDIT_RULES_FILE}
fi
if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE} -p [xw]*a"`" = "0" ]; then
sed -i "s/\(-w ${SED_FILE} -p \)/\1a/" ${AUDIT_RULES_FILE}
fi
fi
fi
done
service auditd restart 1>/dev/null
|
Record Attempts to Alter Audit Rules
[ref]rule
To watch for attempted manual edits of audit rules, add the following to /etc/audit/audit.rules :
-w /etc/audit/audit.rules -p w -k audit_rules
Rationale:Manual editing of audit rules may indicate nefarious activity, such
as an attacker attempting to remove evidence of an intrusion. Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ -e /etc/audit/audit.rules ]; then
AUDIT_RULES_FILE="/etc/audit/audit.rules"
elif [ -e /etc/audit.rules ]; then
AUDIT_RULES_FILE="/etc/audit.rules"
else
exit
fi
if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${AUDIT_RULES_FILE}"`" = "0" ]; then
echo "-w ${AUDIT_RULES_FILE} -p wa -k audit_rules_changes" >>${AUDIT_RULES_FILE}
elif [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${AUDIT_RULES_FILE} -p [x]*\(wa\|aw\)"`" = "0" ]; then
if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${AUDIT_RULES_FILE} -p "`" = "0" ]; then
sed -i "s/\(-w ${AUDIT_RULES_FILE}\)/\1 -p wa/" ${AUDIT_RULES_FILE}
else
if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${AUDIT_RULES_FILE} -p [xa]*w"`" = "0" ]; then
sed -i "s/\(-w ${AUDIT_RULES_FILE} -p \)/\1w/" ${AUDIT_RULES_FILE}
fi
if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${AUDIT_RULES_FILE} -p [xw]*a"`" = "0" ]; then
sed -i "s/\(-w ${AUDIT_RULES_FILE} -p \)/\1a/" ${AUDIT_RULES_FILE}
fi
fi
fi
service auditd restart 1>/dev/null
|
Ensure auditd Collects Unauthorized Access Attempts to Files (unsuccessful) Via creat
[ref]ruleAt a minimum the audit system should collect
unauthorized file accesses for all users and root. Add the following
to /etc/audit/audit.rules , setting ARCH to either b32 or b64 as
appropriate for your system with either:
-a exit,always -F arch=ARCH -S creat -F success=0 -k access
or
-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 access
Rationale: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 Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ -e /etc/audit/audit.rules ]; then
if [ "`grep " -S creat " /etc/audit/audit.rules | grep -v '#' | grep -c '\-F exit=-EACCES'`" = "0" ]; then
if [ "`uname -p`" != "x86_64" ]; then
echo "-a exit,always -F arch=b32 -S creat -F exit=-EACCES -k access" >>/etc/audit/audit.rules
else
echo "-a exit,always -F arch=b64 -S creat -F exit=-EACCES -k access" >>/etc/audit/audit.rules
fi
fi
if [ "`grep " -S creat " /etc/audit/audit.rules | grep -v '#' | grep -c '\-F exit=-EPERM'`" = "0" ]; then
if [ "`uname -p`" != "x86_64" ]; then
echo "-a exit,always -F arch=b32 -S creat -F exit=-EPERM -k access" >>/etc/audit/audit.rules
else
echo "-a exit,always -F arch=b64 -S creat -F exit=-EPERM -k access" >>/etc/audit/audit.rules
fi
fi
elif [ -e /etc/audit.rules ]; then
if [ "`grep " -S creat " /etc/audit.rules | grep -v '#' | grep -c '\success=0'`" = "0" ]; then
if [ "`uname -p`" != "x86_64" ]; then
echo "-a exit,always -F arch=b32 -S creat -F success=0" >>/etc/audit.rules
else
echo "-a exit,always -F arch=b64 -S creat -F success=0" >>/etc/audit.rules
fi
fi
else
exit
fi
service auditd restart 1>/dev/null
|
Ensure auditd Collects Unauthorized Access Attempts to Files (unsuccessful) Via ftruncate
[ref]ruleAt a minimum the audit system should collect
unauthorized file accesses for all users and root. Add the following
to /etc/audit/audit.rules , setting ARCH to either b32 or b64 as
appropriate for your system with either:
-a exit,always -F arch=ARCH -S ftruncate -F success=0 -k access
or
-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 access
Rationale: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 Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ -e /etc/audit/audit.rules ]; then
if [ "`grep " -S ftruncate " /etc/audit/audit.rules | grep -v '#' | grep -c '\-F exit=-EACCES'`" = "0" ]; then
if [ "`uname -p`" != "x86_64" ]; then
echo "-a exit,always -F arch=b32 -S ftruncate -F exit=-EACCES -k access" >>/etc/audit/audit.rules
else
echo "-a exit,always -F arch=b64 -S ftruncate -F exit=-EACCES -k access" >>/etc/audit/audit.rules
fi
fi
if [ "`grep " -S ftruncate " /etc/audit/audit.rules | grep -v '#' | grep -c '\-F exit=-EPERM'`" = "0" ]; then
if [ "`uname -p`" != "x86_64" ]; then
echo "-a exit,always -F arch=b32 -S ftruncate -F exit=-EPERM -k access" >>/etc/audit/audit.rules
else
echo "-a exit,always -F arch=b64 -S ftruncate -F exit=-EPERM -k access" >>/etc/audit/audit.rules
fi
fi
elif [ -e /etc/audit.rules ]; then
if [ "`grep " -S ftruncate " /etc/audit.rules | grep -v '#' | grep -c '\success=0'`" = "0" ]; then
if [ "`uname -p`" != "x86_64" ]; then
echo "-a exit,always -F arch=b32 -S ftruncate -F success=0" >>/etc/audit.rules
else
echo "-a exit,always -F arch=b64 -S ftruncate -F success=0" >>/etc/audit.rules
fi
fi
else
exit
fi
service auditd restart 1>/dev/null
|
Ensure auditd Collects Unauthorized Access Attempts to Files (unsuccessful) Via open
[ref]ruleAt a minimum the audit system should collect
unauthorized file accesses for all users and root. Add the following
to /etc/audit/audit.rules , setting ARCH to either b32 or b64 as
appropriate for your system with either:
-a exit,always -F arch=ARCH -S open -F success=0 -k access
or
-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 access
Rationale: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 Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ -e /etc/audit/audit.rules ]; then
if [ "`grep " -S open " /etc/audit/audit.rules | grep -v '#' | grep -c '\-F exit=-EACCES'`" = "0" ]; then
if [ "`uname -p`" != "x86_64" ]; then
echo "-a exit,always -F arch=b32 -S open -F exit=-EACCES -k access" >>/etc/audit/audit.rules
else
echo "-a exit,always -F arch=b64 -S open -F exit=-EACCES -k access" >>/etc/audit/audit.rules
fi
fi
if [ "`grep " -S open " /etc/audit/audit.rules | grep -v '#' | grep -c '\-F exit=-EPERM'`" = "0" ]; then
if [ "`uname -p`" != "x86_64" ]; then
echo "-a exit,always -F arch=b32 -S open -F exit=-EPERM -k access" >>/etc/audit/audit.rules
else
echo "-a exit,always -F arch=b64 -S open -F exit=-EPERM -k access" >>/etc/audit/audit.rules
fi
fi
elif [ -e /etc/audit.rules ]; then
if [ "`grep " -S open " /etc/audit.rules | grep -v '#' | grep -c '\success=0'`" = "0" ]; then
if [ "`uname -p`" != "x86_64" ]; then
echo "-a exit,always -F arch=b32 -S open -F success=0" >>/etc/audit.rules
else
echo "-a exit,always -F arch=b64 -S open -F success=0" >>/etc/audit.rules
fi
fi
else
exit
fi
service auditd restart 1>/dev/null
|
Ensure auditd Collects Unauthorized Access Attempts to Files (unsuccessful) Via openat
[ref]ruleAt a minimum the audit system should collect
unauthorized file accesses for all users and root. Add the following
to /etc/audit/audit.rules , setting ARCH to either b32 or b64 as
appropriate for your system with either:
-a exit,always -F arch=ARCH -S openat -F success=0 -k access
or
-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 access
Rationale: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 Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ -e /etc/audit/audit.rules ]; then
if [ "`grep " -S openat " /etc/audit/audit.rules | grep -v '#' | grep -c '\-F exit=-EACCES'`" = "0" ]; then
if [ "`uname -p`" != "x86_64" ]; then
echo "-a exit,always -F arch=b32 -S openat -F exit=-EACCES -k access" >>/etc/audit/audit.rules
else
echo "-a exit,always -F arch=b64 -S openat -F exit=-EACCES -k access" >>/etc/audit/audit.rules
fi
fi
if [ "`grep " -S openat " /etc/audit/audit.rules | grep -v '#' | grep -c '\-F exit=-EPERM'`" = "0" ]; then
if [ "`uname -p`" != "x86_64" ]; then
echo "-a exit,always -F arch=b32 -S openat -F exit=-EPERM -k access" >>/etc/audit/audit.rules
else
echo "-a exit,always -F arch=b64 -S openat -F exit=-EPERM -k access" >>/etc/audit/audit.rules
fi
fi
elif [ -e /etc/audit.rules ]; then
if [ "`grep " -S openat " /etc/audit.rules | grep -v '#' | grep -c '\success=0'`" = "0" ]; then
if [ "`uname -p`" != "x86_64" ]; then
echo "-a exit,always -F arch=b32 -S openat -F success=0" >>/etc/audit.rules
else
echo "-a exit,always -F arch=b64 -S openat -F success=0" >>/etc/audit.rules
fi
fi
else
exit
fi
service auditd restart 1>/dev/null
|
Ensure auditd Collects Unauthorized Access Attempts to Files (unsuccessful) Via truncate
[ref]ruleAt a minimum the audit system should collect
unauthorized file accesses for all users and root. Add the following
to /etc/audit/audit.rules , setting ARCH to either b32 or b64 as
appropriate for your system with either:
-a exit,always -F arch=ARCH -S truncate -F success=0 -k access
or
-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 access
Rationale: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 Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ -e /etc/audit/audit.rules ]; then
if [ "`grep " -S truncate " /etc/audit/audit.rules | grep -v '#' | grep -c '\-F exit=-EACCES'`" = "0" ]; then
if [ "`uname -p`" != "x86_64" ]; then
echo "-a exit,always -F arch=b32 -S truncate -F exit=-EACCES -k access" >>/etc/audit/audit.rules
else
echo "-a exit,always -F arch=b64 -S truncate -F exit=-EACCES -k access" >>/etc/audit/audit.rules
fi
fi
if [ "`grep " -S truncate " /etc/audit/audit.rules | grep -v '#' | grep -c '\-F exit=-EPERM'`" = "0" ]; then
if [ "`uname -p`" != "x86_64" ]; then
echo "-a exit,always -F arch=b32 -S truncate -F exit=-EPERM -k access" >>/etc/audit/audit.rules
else
echo "-a exit,always -F arch=b64 -S truncate -F exit=-EPERM -k access" >>/etc/audit/audit.rules
fi
fi
elif [ -e /etc/audit.rules ]; then
if [ "`grep " -S truncate " /etc/audit.rules | grep -v '#' | grep -c '\success=0'`" = "0" ]; then
if [ "`uname -p`" != "x86_64" ]; then
echo "-a exit,always -F arch=b32 -S truncate -F success=0" >>/etc/audit.rules
else
echo "-a exit,always -F arch=b64 -S truncate -F success=0" >>/etc/audit.rules
fi
fi
else
exit
fi
service auditd restart 1>/dev/null
|
Ensure auditd Collects File Deletion Events by User
[ref]ruleAt a minimum the audit system should collect file
deletion events for all users and root. Add the following to
/etc/audit/audit.rules , setting ARCH to either b32 or b64 as
appropriate for your system:
-a exit,always -F arch=ARCH -S unlink -S unlinkat -S rename -S renameat -F auid>=500 -F auid!=4294967295 -k delete
Rationale: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 Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ -e /etc/audit/audit.rules ]; then
AUDIT_RULES_FILE="/etc/audit/audit.rules"
AUDIT_TAG="-k delete"
elif [ -e /etc/audit.rules ]; then
AUDIT_RULES_FILE="/etc/audit.rules"
AUDIT_TAG=""
else
exit
fi
if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S unlink '`" = "0" ]; then
if [ "`uname -p`" != "x86_64" ]; then
echo "-a exit,always -F arch=b32 -S unlink ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
else
echo "-a exit,always -F arch=b64 -S unlink ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
fi
fi
service auditd restart 1>/dev/null
|
Ensure auditd Collects Directory Deletion Events by User
[ref]ruleAt a minimum the audit system should collect directory
deletion events for all users and root. Add the following to
/etc/audit/audit.rules , setting ARCH to either b32 or b64 as
appropriate for your system:
-a exit,always -F arch=ARCH -S rmdir -k delete
Rationale: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 Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ -e /etc/audit/audit.rules ]; then
AUDIT_RULES_FILE="/etc/audit/audit.rules"
AUDIT_TAG="-k delete"
elif [ -e /etc/audit.rules ]; then
AUDIT_RULES_FILE="/etc/audit.rules"
AUDIT_TAG=""
else
exit
fi
if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S rmdir '`" = "0" ]; then
if [ "`uname -p`" != "x86_64" ]; then
echo "-a exit,always -F arch=b32 -S rmdir ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
else
echo "-a exit,always -F arch=b64 -S rmdir ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
fi
fi
service auditd restart 1>/dev/null
|
Ensure auditd Collects Information on Kernel Module Loading and Unloading
[ref]ruleAdd the following to /etc/audit/audit.rules in order
to capture kernel module loading and unloading events, setting ARCH to either b32 or b64 as appropriate for your system:
-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 modules
Rationale: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 Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ -e /etc/audit/audit.rules ]; then
AUDIT_RULES_FILE="/etc/audit/audit.rules"
AUDIT_TAG="-k modules"
elif [ -e /etc/audit.rules ]; then
AUDIT_RULES_FILE="/etc/audit.rules"
AUDIT_TAG=""
else
exit
fi
if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S init_module '`" = "0" ]; then
if [ "`uname -p`" != "x86_64" ]; then
echo "-a exit,always -F arch=b32 -S init_module ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
else
echo "-a exit,always -F arch=b64 -S init_module ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
fi
fi
if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S delete_module '`" = "0" ]; then
if [ "`uname -p`" != "x86_64" ]; then
echo "-a exit,always -F arch=b32 -S delete_module ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
else
echo "-a exit,always -F arch=b64 -S delete_module ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
fi
fi
for FILE in /sbin/insmod /sbin/rmmod /sbin/modprobe; do
if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE}"`" = "0" ]; then
echo "-w ${FILE} -p x -k modules" >>${AUDIT_RULES_FILE}
elif [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE} -p [wa]*x"`" = "0" ]; then
SED_FILE="$(echo ${FILE} | sed 's/\//\\\//g')"
if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE} -p "`" = "0" ]; then
sed -i "s/\(-w ${SED_FILE}\)/\1 -p x/" ${AUDIT_RULES_FILE}
else
sed -i "s/\(-w ${SED_FILE} -p \)/\1x/" ${AUDIT_RULES_FILE}
fi
fi
done
service auditd restart 1>/dev/null
|
Enable auditd Service
[ref]ruleThe auditd service is an essential userspace component of
the Linux Auditing System, as it is responsible for writing audit records to
disk.
The auditd service can be enabled with the following command:
$ sudo chkconfig --level 2345 auditd on
Rationale:Ensuring the auditd service is active ensures
audit records generated by the kernel can be written to disk, or that appropriate
actions will be taken if other obstacles exist.
Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | configure |
---|
#
# Enable auditd for all run levels
#
/sbin/chkconfig --level 0123456 auditd on
#
# Start auditd if not currently running
#
/sbin/service auditd start 1>/dev/null
|
Enable Auditing for Processes Which Start Prior to the Audit Daemon
[ref]ruleTo ensure all processes can be audited, even
those which start prior to the audit daemon, add the argument
audit=1 to the kernel line in /etc/grub.conf , in the manner below:
kernel /vmlinuz-version ro vga=ext root=/dev/VolGroup00/LogVol00 rhgb quiet audit=1
Rationale:
Each process on the system carries an "auditable" flag which
indicates whether its activities can be audited. Although auditd
takes care of enabling this for all processes which launch after it
does, adding the kernel argument ensures it is set for every
process during boot.
Identifiers:
GEN000000-LNX00720 References:
ECSC-1, 366 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ $(grep -v '#' /boot/grub/grub.conf | grep kernel | grep -c audit=) = 0 ]; then
sed -i '/^[ |\t]*kernel/s/$/ audit=1/' /boot/grub/grub.conf
else
sed -i '/^[ |\t]*kernel/s/audit=./audit=1/' /boot/grub/grub.conf
fi
|
Services
[ref]group
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.
Red Hat Enterprise Linux 5 provides a convenient minimal install option that essentially installs the bare necessities for a functional
system. When building Red Hat Enterprise Linux 5 systems, it is highly recommended to select the minimal packages and then build up
the system from there.
|
contains 86 rules |
Obsolete Services
[ref]groupThis 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.
Organizations which are running these services should
switch to more secure equivalents as soon as possible.
If it remains absolutely necessary to run one of
these services for legacy reasons, care should be taken to restrict
the service as much as possible, for instance by configuring host
firewall software such as iptables to restrict access to the
vulnerable service to only those remote hosts which have a known
need to use it. |
contains 11 rules |
Xinetd
[ref]groupThe xinetd service acts as a dedicated listener for some
network services (mostly, obsolete ones) and can be used to provide access
controls and perform some logging. It has been largely obsoleted by other
features, and it is not installed by default. The older Inetd service
is not even available as part of Red Hat Enterprise Linux 6. |
contains 1 rule |
Disable xinetd Service
[ref]rule
The xinetd service can be disabled with the following command:
$ sudo chkconfig xinetd off
Rationale:
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.
Identifiers:
GEN003700 References:
ECSC-1, 305 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | configure |
---|
#
# Disable xinetd for all run levels
#
/sbin/chkconfig --level 0123456 xinetd off
#
# Stop xinetd if currently running
#
/sbin/service xinetd stop 1>/dev/null
|
Telnet
[ref]groupThe 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 Service
[ref]rule
The telnet service can be disabled with the following command:
$ sudo chkconfig telnet off
Rationale:
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.
Identifiers:
GEN003850 References:
DCPP-1, 197 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | configure |
---|
#
# Disable telnetd for all run levels
#
/sbin/chkconfig --level 0123456 telnetd off
#
# Stop telnetd if currently running
#
/sbin/service telnetd stop 1>/dev/null
|
Rlogin, Rsh, and Rexec
[ref]groupThe Berkeley r-commands are legacy services which
allow cleartext remote access and have an insecure trust
model. |
contains 6 rules |
Uninstall rsh-server Package
[ref]ruleThe rsh-server package can be uninstalled with
the following command:
# yum erase rsh-server
Rationale:The rsh-server package provides several obsolete and insecure
network services. Removing it
decreases the risk of those services' accidental (or intentional)
activation.
Identifiers:
GEN003845 References:
ECSC-1, 305 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | disable |
---|
yum -y remove rsh-server --disablerepo=* 1>/dev/null
Remediation Puppet snippet: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | disable |
---|
include remove_rsh-server
class remove_rsh-server {
package { 'rsh-server':
ensure => 'purged',
}
}
Remediation Anaconda snippet: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | disable |
---|
package -remove=rsh-server
|
Disable rexec Service
[ref]ruleThe rexec service, which is available with
the rsh-server package and runs as a service through xinetd,
should be disabled.
The rexec service can be disabled with the following command:
$ sudo chkconfig rexec off
Rationale: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 Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | configure |
---|
#
# Disable rexec for all run levels
#
/sbin/chkconfig --level 0123456 rexec off
#
# Stop rexec if currently running
#
/sbin/service rexec stop 1>/dev/null
|
Disable rsh Service
[ref]ruleThe rsh service, which is available with
the rsh-server package and runs as a service through xinetd,
should be disabled.
The rsh service can be disabled with the following command:
$ sudo chkconfig rsh off
Rationale: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.
Identifiers:
GEN003820 References:
EBRU-1, 68 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | configure |
---|
#
# Disable rsh for all run levels
#
/sbin/chkconfig --level 0123456 rsh off
#
# Stop rsh if currently running
#
/sbin/service rsh stop 1>/dev/null
|
Disable rlogin Service
[ref]ruleThe rlogin service, which is available with
the rsh-server package and runs as a service through xinetd,
should be disabled.
The rlogin service can be disabled with the following command:
$ sudo chkconfig rlogin off
Rationale: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.
Identifiers:
GEN003830 References:
DCPP-1, 68 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | configure |
---|
#
# Disable rlogin for all run levels
#
/sbin/chkconfig --level 0123456 rlogin off
#
# Stop rlogin if currently running
#
/sbin/service rlogin stop 1>/dev/null
|
Remove Rsh Trust Files
[ref]ruleThe files /etc/hosts.equiv and ~/.rhosts (in
each user's home directory) list remote hosts and users that are trusted by the
local system when using the rshd daemon.
To remove these files, run the following command to delete them from any
location:
# rm /etc/hosts.equiv
$ rm ~/.rhosts
Rationale:Trust files are convenient, but when
used in conjunction with the R-services, they can allow
unauthenticated access to a system. Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | disable |
---|
find -type f -name .rhosts -exec rm -f '{}' \;
rm /etc/hosts.equiv
|
Remove rhosts_auth Entries
[ref]ruleAll 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 Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
sed -i '/.*rhosts_auth.*/d' /etc/pam.d/*
|
The 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 Service
[ref]ruleThe ypbind service, which allows the system to act as a client in
a NIS or NIS+ domain, should be disabled.
The ypbind service can be disabled with the following command:
$ sudo chkconfig ypbind off
Rationale:
Disabling the ypbind service ensures the system is not acting
as a client in a NIS or NIS+ domain.
Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | configure |
---|
#
# Disable ypbind for all run levels
#
/sbin/chkconfig --level 0123456 ypbind off
#
# Stop ypbind if currently running
#
/sbin/service ypbind stop 1>/dev/null
|
TFTP Server
[ref]group
TFTP 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 Service
[ref]ruleThe tftp service should be disabled.
The tftp service can be disabled with the following command:
$ sudo chkconfig tftp off
Rationale:
Disabling the tftp service ensures the system is not acting
as a TFTP server, which does not provide encryption or authentication.
Identifiers:
GEN005140 References:
DCSW-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | configure |
---|
#
# Disable tftp for all run levels
#
/sbin/chkconfig --level 0123456 tftp off
#
# Stop tftp if currently running
#
/sbin/service tftp stop 1>/dev/null
|
Ensure tftp Daemon Uses Secure Mode
[ref]ruleIf running the tftp service is necessary, it should be configured
to change its root directory at startup. To do so, ensure
/etc/xinetd.d/tftp includes -s as a command line argument, as shown in
the following example (which is also the default):
server_args = -s /var/lib/tftpboot
Rationale:Using the -s option causes the TFTP service to only serve files from the
given directory. Serving files from an intentionally-specified directory
reduces the risk of sharing files which should remain private.
Identifiers:
GEN005080 References:
ECSC-1, 366 |
Base Services
[ref]groupThis 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)
[ref]ruleThe kdump service provides a kernel crash dump analyzer. It uses the kexec
system call to boot a secondary kernel ("capture" kernel) following a system
crash, which can load information from the crashed kernel for analysis.
The kdump service can be disabled with the following command:
$ sudo chkconfig kdump off
Rationale:Unless the system is used for kernel development or testing, there
is little need to run the kdump service. Identifiers:
GEN003510 References:
ECSC-1, 366 |
Disable Automatic Updates
[ref]rule
The yum-updatesd service can be disabled with the following command:
$ sudo chkconfig yum-updatesd off
Rationale: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 Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | configure |
---|
#
# Disable yum-updatesd for all run levels
#
/sbin/chkconfig --level 0123456 yum-updatesd off
#
# Stop yum-updatesd if currently running
#
/sbin/service yum-updatesd stop 1>/dev/null
|
Cron and At Daemons
[ref]groupThe 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 Necessary
[ref]group
The /etc/cron.allow file contain lists of users who are allowed
to use cron to delay execution of processes. If this file exists and
if the corresponding file /etc/cron.deny does not exist,
then only users listed in the relevant allow files can run the crontab
commands to submit jobs to be run at scheduled intervals.
On many systems, only the system administrator needs the ability to schedule
jobs. Note that even if a given user is not listed in cron.allow , cron jobs can
still be run as that user.
To restrict cron to only authorized users:
- Remove the cron.deny file:
# rm /etc/cron.deny - Edit
/etc/cron.allow , adding one line for each user allowed to use the crontab command to create cron jobs.
|
contains 2 rules |
Cron Must Control Access
[ref]ruleThe 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.deny
The cron facility allows users to execute recurring jobs on a regular and unattended basis.
The cron.allow file designates accounts allowed to enter and execute jobs using the cron facility.
If neither cron.allow nor cron.deny exists, then any account may use the cron facility.
This may open the facility up for abuse by system intruders and malicious users.Identifiers:
GEN002960 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ ! -e [/etc/cron.allow ]; then
> /etc/cron.allow
chown root:root /etc/cron.allow
chmod 0600 /etc/cron.allow
fi
if [ ! -e [/etc/cron.deny ]; then
SYS_USER=$(cat /etc/passwd | while read entry; do if [ "$(echo ${entry} | cut -d: -f3)" -lt "500" ]; then echo ${entry} | cut -d: -f1 ; fi; done)
for USER in `echo $SYS_USER`; do
if [ $(grep -c "^${USER}$" /etc/cron.deny) = 0 ]; then
echo ${USER} | tee -a /etc/cron.deny &>/dev/null
fi
done
chown root:root /etc/cron.deny
chmod 0600 /etc/cron.deny
fi
|
Cron Must Deny System Accounts
[ref]ruleThe 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.Identifiers:
GEN003060 References:
ECPA-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
SYS_USER=$(cat /etc/passwd | while read entry; do if [ "$(echo ${entry} | cut -d: -f3)" -lt "500" ]; then echo ${entry} | cut -d: -f1 ; fi; done)
for USER in `echo $SYS_USER`; do
if [ $(grep -c "^${USER}$" /etc/cron.deny) = 0 ]; then
echo ${USER} | tee -a /etc/cron.deny &>/dev/null
fi
done
|
Restrict at to Authorized Users if Necessary
[ref]group
The /etc/at.allow file contain lists of users who are allowed
to use at to delay execution of processes. If this file exists and
if the corresponding file /etc/at.deny does not exist,
then only users listed in the relevant allow files can run the at
commands to submit jobs to be run at scheduled intervals.
On many systems, only the system administrator needs the ability to schedule
jobs. Note that even if a given user is not listed in cron.allow , cron jobs can
still be run as that user. The cron.allow file controls only administrative access
to the crontab command for scheduling and modifying cron jobs.
To restrict at to only authorized users:
- Remove the
at.deny file:# rm /etc/at.deny - Edit
/etc/at.allow , adding one line for each user allowed to use the at command to create at jobs.
|
contains 3 rules |
At Must Control Access
[ref]ruleThe 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.deny
The 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.Identifiers:
GEN003280 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ ! -e [/etc/at.allow ]; then
> /etc/at.allow
chown root:root /etc/at.allow
chmod 0600 /etc/at.allow
fi
if [ ! -e [/etc/at.deny ]; then
SYS_USER=$(cat /etc/passwd | while read entry; do if [ "$(echo ${entry} | cut -d: -f3)" -lt "500" ]; then echo ${entry} | cut -d: -f1 ; fi; done)
for USER in `echo $SYS_USER`; do
if [ $(grep -c "^${USER}$" /etc/at.deny) = 0 ]; then
echo ${USER} | tee -a /etc/at.deny &>/dev/null
fi
done
chown root:root /etc/at.deny
chmod 0600 /etc/at.deny
fi
|
At Must Deny System Accounts
[ref]ruleThe 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.Identifiers:
GEN003320 References:
ECPA-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
SYS_USER=$(cat /etc/passwd | while read entry; do if [ "$(echo ${entry} | cut -d: -f3)" -lt "500" ]; then echo ${entry} | cut -d: -f1 ; fi; done)
for USER in `echo $SYS_USER`; do
if [ $(grep -c "^${USER}$" /etc/at.deny) = 0 ]; then
echo ${USER} | tee -a /etc/at.deny &>/dev/null
fi
done
|
At.deny Must Either Not Exist Or Not Be Empty
[ref]ruleOn 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.deny
If the above command returns with details about /etc/at.deny, then it exists.
If it exists, then run the following command:
# cat /etc/at.deny
If no entries are returned, then configure the at.deny file with the default system accounts, excluding root.
Identifiers:
GEN003300 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
SYS_USER=$(cat /etc/passwd | while read entry; do if [ "$(echo ${entry} | cut -d: -f3)" -lt "500" ]; then echo ${entry} | cut -d: -f1 ; fi; done)
for USER in `echo $SYS_USER`; do
if [ $(grep -c "^${USER}$" /etc/at.deny) = 0 ]; then
echo ${USER} | tee -a /etc/at.deny &>/dev/null
fi
done
sed -i '/^$/d' /etc/at.deny
|
SSH Server
[ref]groupThe 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 sshd and
provided by the RPM package openssh-server . |
contains 21 rules |
Configure OpenSSH Server if Necessary
[ref]groupIf the system needs to act as an SSH server, then
certain changes should be made to the OpenSSH daemon configuration
file /etc/ssh/sshd_config . The following recommendations can be
applied to this file. See the sshd_config(5) man page for more
detailed information. |
contains 16 rules |
Strengthen Firewall Configuration if Possible
[ref]groupIf 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).
Determine an appropriate network block, netwk , and network mask, mask ,
representing the machines on your network which will be allowed to access this SSH server.
Edit the files etc/sysconfig/iptables and /etc/sysconfig/ip6tables
(if IPv6 is in use). In each file, locate the line:
-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
and replace it with:
-A INPUT -s netwk/mask -m state --state NEW -p tcp --dport 22 -j ACCEPT
|
contains 2 rules |
Assign Designated IP
[ref]ruleThe 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 /etc/ssh/sshd_config must be modified to include the specific IP address
that the SSH server should be managed from, for example:
ListenAddress 10.10.2.1
Rationale:
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.
Identifiers:
GEN005504 References:
ECSC-1, 69 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
MANAGEMENT_IP=$(/sbin/ifconfig | grep inet | grep -v 127.0.0.1 | cut -d: -f2 | awk '{ print $1}' | head -1)
if [ $(cat /etc/ssh/sshd_config | grep -ic "^ListenAddress") = "0" ]; then
echo "ListenAddress ${MANAGEMENT_IP}" | tee -a /etc/ssh/sshd_config &>/dev/null
else
sed -i "s/^ListenAddress.*/ListenAddress ${MANAGEMENT_IP}/" /etc/ssh/sshd_config
fi
service sshd restart 1>/dev/null
|
Enable SSH IP Filtering
[ref]ruleIP 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.access
Rationale:
The SSH daemon must be configured for IP filtering to provide a layered defence against connection
attempts from unauthorized addresses.
Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
MANAGEMENT_IP=$(/sbin/ifconfig | grep inet | grep -v 127.0.0.1 | cut -d: -f2 | awk '{ print $1}' | head -1 | cut -d. -f1-2)
sed -i '/sshd/d' /etc/hosts.allow
echo "sshd: ${MANAGEMENT_IP}.: spawn /bin/echo SSHD accessed on \$(/bin/date) from %h>>/var/log/host.access" | tee -a /etc/hosts.allow &>/dev/null
|
Allow Only SSH Protocol 2
[ref]ruleOnly SSH protocol version 2 connections should be
permitted. The default setting in
/etc/ssh/sshd_config is correct, and can be
verified by ensuring that the following
line appears:
Protocol 2
Rationale:
SSH protocol version 1 suffers from design flaws that
result in security vulnerabilities and
should not be used.
Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ $(cat /etc/ssh/sshd_config | grep -c "^Protocol") != "0" ]; then
sed -i 's/^Protocol.*/Protocol 2/' /etc/ssh/sshd_config
else
echo "Protocol 2">>/etc/ssh/sshd_config
fi
service sshd restart 1>/dev/null
|
Disable SSH Root Login
[ref]ruleThe 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 /etc/ssh/sshd_config :
PermitRootLogin no
Rationale:
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.
Identifiers:
GEN001120 References:
ECPA-1, 770 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | disable |
---|
grep -q ^PermitRootLogin /etc/ssh/sshd_config && \
sed -i "s/PermitRootLogin.*/PermitRootLogin no/g" /etc/ssh/sshd_config
if ! [ $? -eq 0 ]; then
echo "PermitRootLogin no" >> /etc/ssh/sshd_config
fi
service sshd restart 1>/dev/null
|
Enable SSH Warning Banner
[ref]rule
To enable the warning banner and ensure it is consistent
across the system, add or correct the following line in /etc/ssh/sshd_config :
Banner /etc/issue
Another 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.
Identifiers:
GEN005550 References:
ECWM-1, 48 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
grep -q ^Banner /etc/ssh/sshd_config && \
sed -i "s/Banner.*/Banner \/etc\/issue/g" /etc/ssh/sshd_config
if ! [ $? -eq 0 ]; then
echo "Banner /etc/issue" >> /etc/ssh/sshd_config
fi
service sshd restart 1>/dev/null
|
Use Only Approved Ciphers
[ref]ruleLimit the ciphers to those algorithms which are FIPS-approved.
The following line in /etc/ssh/sshd_config
demonstrates use of FIPS-approved ciphers:
Ciphers aes128-ctr,aes192-ctr,aes256-ctr
The 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.
Identifiers:
GEN005505 References:
DCNR-1, 68 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
grep -q ^Ciphers /etc/ssh/sshd_config && \
sed -i "s/Ciphers.*/Ciphers aes128-ctr,aes192-ctr,aes256-ctr/g" /etc/ssh/sshd_config
if ! [ $? -eq 0 ]; then
echo "Ciphers aes128-ctr,aes192-ctr,aes256-ctr" >> /etc/ssh/sshd_config
fi
service sshd restart 1>/dev/null
|
Do Not Use CBC Mode
[ref]ruleThe 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 /etc/ssh/sshd_config
demonstrates use of FIPS-approved ciphers:
Ciphers aes128-ctr,aes192-ctr,aes256-ctr
The 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.
Identifiers:
GEN005506 References:
ECSC-1, 366 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
grep -q ^Ciphers /etc/ssh/sshd_config && \
sed -i "s/Ciphers.*/Ciphers aes128-ctr,aes192-ctr,aes256-ctr/g" /etc/ssh/sshd_config
if ! [ $? -eq 0 ]; then
echo "Ciphers aes128-ctr,aes192-ctr,aes256-ctr" >> /etc/ssh/sshd_config
fi
/sbin/service sshd restart 1>/dev/null
|
Use Only Approved Macs
[ref]ruleLimit the MACs to those hash algorithms which are FIPS-approved.
The following line in /etc/ssh/sshd_config
demonstrates use of FIPS-approved MACs:
Macs hmac-sha1
The 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 Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | disable |
---|
if [ $(cat /etc/ssh/sshd_config | grep -c "^MACs") = "0" ]; then
echo "MACs hmac-sha1" | tee -a /etc/ssh/sshd_config &>/dev/null
else
sed -i 's/^MACs.*/MACs hmac-sha1/' /etc/ssh/sshd_config
fi
service sshd restart 1>/dev/null
|
Disable GSSAPIAuthentication
[ref]ruleGSSAPIAuthentication should not be
permitted. The default setting in
/etc/ssh/sshd_config is correct, and can be
verified by ensuring that the following
line appears:
GSSAPIAuthentication no
Rationale:
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.
Identifiers:
GEN005524 References:
ECSC-1, 366 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ $(cat /etc/ssh/sshd_config | grep -c "^GSSAPIAuthentication") = "0" ]; then
echo "GSSAPIAuthentication no" | tee -a /etc/ssh/sshd_config &>/dev/null
else
sed -i 's/^GSSAPIAuthentication.*/GSSAPIAuthentication no/' /etc/ssh/sshd_config
fi
service sshd restart 1>/dev/null
|
Display Login Details
[ref]ruleA user should be presented with details on the last attempted access
to their account, upon logging in. The default setting in
/etc/ssh/sshd_config is correct, and can be
verified by ensuring that the following
line appears:
PrintLastLog yes
Rationale:
Providing users with feedback on when account accesses last occurred
facilitates user recognition and reporting of unauthorized account use.
Identifiers:
GEN000452 References:
ECSC-1, 52 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ "$(grep -c '^session.*required.*pam_lastlog.so$' /etc/pam.d/sshd)" = "0" ]; then
echo -e "session required\tpam_lastlog.so" | tee -a /etc/pam.d/sshd &>/dev/null
elif [ "$(grep pam_lastlog /etc/pam.d/sshd | grep -c silent)" != "0" ]; then
sed -i '/pam_lastlog/s/silent//' /etc/pam.d/sshd
fi
if [ $(cat /etc/ssh/sshd_config | grep -ic "^PrintLastLog") = "0" ]; then
echo "PrintLastLog yes" | tee -a /etc/ssh/sshd_config &>/dev/null
else
sed -i 's/^PrintLastLog.*/PrintLastLog yes/' /etc/ssh/sshd_config
fi
service sshd restart 1>/dev/null
|
Restrict Users/Groups
[ref]ruleLogin access to the SSH server should be restricted to a
list of allowed users or groups. The default setting in
/etc/ssh/sshd_config is to allow all users and groups access to login.
The user/group restriction can be verified by ensuring that the following
line appears:
AllowedUsers or AllowedGroups
Rationale:
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.
Identifiers:
GEN005521 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
echo "AllowGroups wheel" | tee -a /etc/ssh/sshd_config &>/dev/null
service sshd restart 1>/dev/null
|
Disable KerberosAuthentication
[ref]ruleKerberosAuthentication should not be
permitted. The default setting in
/etc/ssh/sshd_config is correct, and can be
verified by ensuring that the following
line appears:
KerberosAuthentication no
Rationale:
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.
Identifiers:
GEN005526 References:
ECSC-1, 366 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ $(cat /etc/ssh/sshd_config | grep -ic "^KerberosAuthentication") = "0" ]; then
echo "KerberosAuthentication no" | tee -a /etc/ssh/sshd_config &>/dev/null
else
sed -i 's/^KerberosAuthentication.*/KerberosAuthentication no/' /etc/ssh/sshd_config
fi
service sshd restart 1>/dev/null
|
Enable StrictModes
[ref]ruleStrictModes must be enabled.
The default setting in
/etc/ssh/sshd_config is not correct, and can be
verified by ensuring that the following
line appears:
StrictModes yes
Rationale:
If other users have access to modify user-specific SSH configuration files,
they may be able to log into the system as another user.
Identifiers:
GEN005536 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ $(cat /etc/ssh/sshd_config | grep -c "^StrictModes") = "0" ]; then
echo "StrictModes yes" | tee -a /etc/ssh/sshd_config &>/dev/null
else
sed -i 's/^StrictModes.*/StrictModes yes/' /etc/ssh/sshd_config
fi
service sshd restart 1>/dev/null
|
Enable Privilege Separation
[ref]ruleUsePrivilegeSeparation must be enabled.
The default setting in
/etc/ssh/sshd_config is not correct, and can be
verified by ensuring that the following
line appears:
UsePrivilegeSeparation yes
Rationale:
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.
Identifiers:
GEN005537 References:
ECLP-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ $(cat /etc/ssh/sshd_config | grep -ic "^UsePrivilegeSeparation") = "0" ]; then
echo "UsePrivilegeSeparation yes" | tee -a /etc/ssh/sshd_config &>/dev/null
else
sed -i 's/^UsePrivilegeSeparation.*/UsePrivilegeSeparation yes/' /etc/ssh/sshd_config
fi
service sshd restart 1>/dev/null
|
Disable RhostsRSAAuthentication
[ref]ruleRhostsRSAAuthentication should not be
permitted. The default setting in
/etc/ssh/sshd_config is correct, and can be
verified by ensuring that the following
line appears:
RhostsRSAAuthentication no
Rationale:
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.
Identifiers:
GEN005538 References:
ECSC-1, 366 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ $(cat /etc/ssh/sshd_config | grep -ic "^RhostsRSAAuthentication") = "0" ]; then
echo "RhostsRSAAuthentication no" | tee -a /etc/ssh/sshd_config &>/dev/null
else
sed -i 's/^RhostsRSAAuthentication.*/RhostsRSAAuthentication no/' /etc/ssh/sshd_config
fi
service sshd restart 1>/dev/null
|
Disable Or Delay Compression
[ref]ruleCompression should not be
permitted prior to authentication. The default setting in
/etc/ssh/sshd_config is not correct, and can be
verified by ensuring that either of the following
lines appear:
Compression no
or
Compression delayed
Rationale:
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.
Identifiers:
GEN005539 References:
ECSC-1, 366 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ $(cat /etc/ssh/sshd_config | grep -ic "^Compression") = "0" ]; then
echo "Compression delayed" | tee -a /etc/ssh/sshd_config &>/dev/null
else
sed -i 's/^Compression.*/Compression delayed/' /etc/ssh/sshd_config
fi
service sshd restart 1>/dev/null
|
Configure OpenSSH Client if Necessary
[ref]groupIf the system needs to utilize the SSH client, then
certain changes should be made to the OpenSSH client configuration
file /etc/ssh/ssh_config . The following recommendations can be
applied to this file. See the ssh_config(5) man page for more
detailed information. |
contains 5 rules |
Allow Only SSH Protocol 2
[ref]ruleOnly SSH protocol version 2 connections should be
permitted. The default setting in
/etc/ssh/ssh_config is correct, and can be
verified by ensuring that the following
line appears:
Protocol 2
Rationale:
SSH protocol version 1 suffers from design flaws that
result in security vulnerabilities and
should not be used.
Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ $(cat /etc/ssh/ssh_config | grep -c "^Protocol") != "0" ]; then
sed -i 's/^Protocol.*/Protocol 2/' /etc/ssh/ssh_config
else
echo "Protocol 2">>/etc/ssh/ssh_config
fi
|
Use Only Approved Ciphers
[ref]ruleLimit the ciphers to those algorithms which are FIPS-approved.
The following line in /etc/ssh/ssh_config
demonstrates use of FIPS-approved ciphers:
Ciphers aes128-ctr,aes192-ctr,aes256-ctr
The 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.
Identifiers:
GEN005510 References:
DCNR-1, 68 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
grep -q ^Ciphers /etc/ssh/ssh_config && \
sed -i "s/Ciphers.*/Ciphers aes128-ctr,aes192-ctr,aes256-ctr/g" /etc/ssh/ssh_config
if ! [ $? -eq 0 ]; then
echo "Ciphers aes128-ctr,aes192-ctr,aes256-ctr" >> /etc/ssh/ssh_config
fi
|
Do Not Use CBC Mode
[ref]ruleThe 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 /etc/ssh/ssh_config
demonstrates use of FIPS-approved ciphers:
Ciphers aes128-ctr,aes192-ctr,aes256-ctr
The 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.
Identifiers:
GEN005511 References:
ECSC-1, 366 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
grep -q ^Ciphers /etc/ssh/ssh_config && \
sed -i "s/Ciphers.*/Ciphers aes128-ctr,aes192-ctr,aes256-ctr/g" /etc/ssh/ssh_config
if ! [ $? -eq 0 ]; then
echo "Ciphers aes128-ctr,aes192-ctr,aes256-ctr" >> /etc/ssh/ssh_config
fi
|
Use Only Approved Macs
[ref]ruleLimit the MACs to those hash algorithms which are FIPS-approved.
The following line in /etc/ssh/ssh_config
demonstrates use of FIPS-approved MACs:
Macs hmac-sha1
The 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 Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ $(cat /etc/ssh/ssh_config | grep -c "^MACs") = "0" ]; then
echo "MACs hmac-sha1" | tee -a /etc/ssh/ssh_config &>/dev/null
else
sed -i 's/^MACs.*/MACs hmac-sha1/' /etc/ssh/ssh_config
fi
|
Disable GSSAPIAuthentication
[ref]ruleGSSAPIAuthentication should not be
permitted. The default setting in
/etc/ssh/ssh_config is correct, and can be
verified by ensuring that the following
line appears:
GSSAPIAuthentication no
Rationale:
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.
Identifiers:
GEN005525 References:
ECSC-1, 366 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ $(cat /etc/ssh/ssh_config | grep -c "^GSSAPIAuthentication") = "0" ]; then
echo "GSSAPIAuthentication no" | tee -a /etc/ssh/ssh_config &>/dev/null
else
sed -i 's/^GSSAPIAuthentication.*/GSSAPIAuthentication no/' /etc/ssh/ssh_config
fi
|
X Window System
[ref]groupThe X Window System implementation included with the
system is called X.org. |
contains 1 rule |
Disable X Windows
[ref]groupUnless 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 Runlevel
[ref]ruleSetting the system's runlevel to 3 will prevent automatic startup
of the X server. To do so, ensure the following line in /etc/inittab
features a 3 as shown:
id:3:initdefault:
Rationale:Unnecessary services should be disabled to decrease the attack surface of the system. Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
sed -i 's/.*:initdefault:.*/id:3:initdefault:/' /etc/inittab
|
The Dynamic Host Configuration Protocol (DHCP) allows
systems to request and obtain an IP address and other configuration
parameters from a server.
This guide recommends configuring networking on clients by manually editing
the appropriate files under /etc/sysconfig . Use of DHCP can make client
systems vulnerable to compromise by rogue DHCP servers, and should be avoided
unless necessary. If using DHCP is necessary, however, there are best practices
that should be followed to minimize security risk.
|
contains 2 rules |
Disable DHCP Client
[ref]group
DHCP 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 Client
[ref]rule
For each interface on the system (e.g. eth0), edit
/etc/sysconfig/network-scripts/ifcfg-interface and make the
following changes:
Rationale:
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. Identifiers:
GEN007840 References:
ECSC-1, 366 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
sed -i 's/^BOOTPROTO=.*/BOOTPROTO="static"/' /etc/sysconfig/network-scripts/ifcfg-*
|
Configure DHCP Client if Necessary
[ref]groupIf 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
dhclient(8) and dhclient.conf(5) man pages. |
contains 1 rule |
Do Not Use Dynamic DNS
[ref]ruleTo prevent the DHCP client from transmitting system information,
edit /etc/dhclient.conf , and add or correct the following global
option: 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. Identifiers:
GEN007850 References:
ECSC-1, 366 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ -e /etc/dhclient.conf ]; then
if [ $(grep -c "do-forward-updates false;" /etc/dhclient.conf) = 0 ]; then
echo "do-forward-updates false;" | tee -a /etc/dhclient.conf &>/dev/null
fi
else
echo "do-forward-updates false;" | tee /etc/dhclient.conf &>/dev/null
fi
|
Network Time Protocol
[ref]groupThe 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.
If every system on a network reliably reports the same time, then it is much
easier to correlate log messages in case of an attack. In addition, a number of
cryptographic protocols (such as Kerberos) use timestamps to prevent certain
types of attacks. If your network does not have synchronized time, these
protocols may be unreliable or even unusable.
Depending on the specifics of the network, global time accuracy may be just as
important as local synchronization, or not very important at all. If your
network is connected to the Internet, using a
public timeserver (or one provided by your enterprise) provides globally
accurate timestamps which may be essential in investigating or responding to
an attack which originated outside of your network.
A typical network setup involves a small number of internal systems operating as NTP
servers, and the remainder obtaining time information from those
internal servers.
More information on how to configure the NTP server software,
including configuration of cryptographic authentication for
time data, is available at http://www.ntp.org.
|
contains 3 rules |
Enable the NTP Daemon
[ref]rule
The ntpd service can be enabled with the following command:
$ sudo chkconfig --level 2345 ntpd on
Rationale:Enabling the ntpd service ensures that the ntpd
service will be running and that the system will synchronize its time to
any servers specified. This is important whether the system is configured to be
a client (and synchronize only its own clock) or it is also acting as an NTP
server to other systems. Synchronizing time is essential for authentication
services such as Kerberos, but it is also important for maintaining accurate
logs and auditing possible security breaches.
The NTP daemon offers all of the functionality of ntpdate , which is now
deprecated. Additional information on this is available at
http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate Identifiers:
GEN000241 References:
ECSC-1, 366 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | configure |
---|
#
# Enable ntpd for all run levels
#
/sbin/chkconfig --level 0123456 ntpd on
#
# Start ntpd if not currently running
#
/sbin/service ntpd start 1>/dev/null
|
Specify a Remote NTP Server
[ref]ruleTo specify a remote NTP server for time synchronization, edit
the file /etc/ntp.conf . Add or correct the following lines,
substituting the IP or hostname of a remote NTP server for ntpserver:
server ntpserver
This 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 Servers
[ref]ruleAdditional NTP servers can be specified for time synchronization
in the file /etc/ntp.conf . To do so, add additional lines of the
following form, substituting the IP address or hostname of a remote NTP server for
ntpserver:
server ntpserver
Rationale: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.
Identifiers:
GEN000242 References:
ECSC-1, 160 |
Mail Server Software
[ref]group
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.
Very few systems at any site should be configured to directly receive email over the
network. Users should instead use mail client programs to retrieve email
from a central server that supports protocols such as IMAP or POP3.
However, it is normal for most systems to be independently capable of sending email,
for instance so that cron jobs can report output to an administrator.
Most MTAs, including Postfix, support a submission-only mode in which mail can be sent from
the local system to a central site MTA (or directly delivered to a local account),
but the system still cannot receive mail directly over a network.
The alternatives program in Red Hat Enterprise Linux permits selection of other mail server software
(such as Sendmail), but Postfix is the default and is preferred.
Postfix was coded with security in mind and can also be more effectively contained by
SELinux as its modular design has resulted in separate processes performing specific actions.
More information is available on its website, http://www.postfix.org.
|
contains 12 rules |
Mail Server Logging
[ref]group
It is important to ensure adequate logging of mail server connections so as to
support detecting any unauthorized activity.
|
contains 2 rules |
Enable Mail Server Logging
[ref]rule
To ensure logging is enabled, perform the following command:
grep "mail\." /etc/syslog.conf
The 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 Level
[ref]rule
If sendmail is installed, perform the following checks:
Edit the file /etc/mail/sendmail.cf and confirm that the following line appears:
O LogLevel=9
If 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 Features
[ref]group
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.
Very few systems at any site should be configured to directly receive email over the
network. Users should instead use mail client programs to retrieve email
from a central server that supports protocols such as IMAP or POP3.
However, it is normal for most systems to be independently capable of sending email,
for instance so that cron jobs can report output to an administrator.
Most MTAs, including Postfix, support a submission-only mode in which mail can be sent from
the local system to a central site MTA (or directly delivered to a local account),
but the system still cannot receive mail directly over a network.
The alternatives program in Red Hat Enterprise Linux permits selection of other mail server software
(such as Sendmail), but Postfix is the default and is preferred.
Postfix was coded with security in mind and can also be more effectively contained by
SELinux as its modular design has resulted in separate processes performing specific actions.
More information is available on its website, http://www.postfix.org.
|
contains 9 rules |
Disable Debug Command
[ref]rule
From a terminal, type the following commands:
# telnet localhost 25
# debug
If 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.
Identifiers:
GEN004620 References:
ECSC-1, 366 |
Disable Decode Command
[ref]rule
Edit the file(s) /etc/aliases and /usr/lib/aliases , if either exist,
to ensure that the decode: and uudecode: entries do NOT include
the file path to uudecode, such as the following:
decode: |/usr/bin/uudecode
uudecode: |/usr/bin/uuencode -d
Rationale:
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 Command
[ref]rule
If sendmail is installed, perform the following checks:
Edit the file /etc/mail/sendmail.cf to ensure that the following
PrivacyOptions line appears and includes noexpn :
O PrivacyOptions=authwarnings,novrfy,noexpn,restrictqrun
If 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.
Identifiers:
GEN004660 References:
ECSC-1, 366 |
Disable Help Command
[ref]rule
If sendmail is installed, perform the following checks:
Edit the file /etc/mail/helpfile to ensure that the file is empty.
If postfix is installed, this check is not applicable.
Rationale:
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.
Identifiers:
GEN004540 References:
ECSC-1, 366 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
>/etc/mail/helpfile
|
Disable VRFY Command
[ref]rule
If sendmail is installed, perform the following checks:
Edit the file /etc/mail/sendmail.cf to ensure that the following
PrivacyOptions line appears and includes novrfy :
O PrivacyOptions=authwarnings,novrfy,noexpn,restrictqrun
If 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.
Identifiers:
GEN004680 References:
ECSC-1, 366 |
Disable WIZ Command
[ref]rule
From a terminal, type the following commands:
# telnet localhost 25
# wiz
If 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.
Identifiers:
GEN004700 References:
ECSC-1, 366 |
Don't Display Version
[ref]rule
If sendmail is installed, perform the following checks:
Edit the file /etc/mail/sendmail.cf to ensure that the following
SmtpGreetingMessage line does not appear as:
O SmtpGreetingMessage=$j Sendmail $v/$Z; $b
If the above line appears, it should be changed to:
O SmtpGreetingMessage= Mail Server Ready ; $b
If 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.
Identifiers:
GEN004560 References:
ECSC-1, 366 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
SENDMAIL_CONFIG=$(rpm -ql sendmail | grep sendmail.cf)
SENDMAIL_MAINCONF=$(rpm -ql sendmail | grep sendmail.mc)
if [ "$(rpm -q sendmail-cf &>/dev/null; echo $?)" = "0" ]; then
if [ -e "${SENDMAIL_MAINCONF}" ]; then
if [ "$(grep -c "^define(\`confSMTP_LOGIN_MSG" "${SENDMAIL_MAINCONF}")" = "0" ]; then
sed -i "0,/^define/s/\(^define\)/define(\`confSMTP_LOGIN_MSG', \` Mail Server Ready ; $b')dnl\n\1/" "${SENDMAIL_MAINCONF}"
elif [ "$(grep -c "^define(\`confSMTP_LOGIN_MSG', \` Mail Server Ready ; \$b')dnl" "${SENDMAIL_MAINCONF}")" = "0" ]; then
sed -i "s/^define(\`confSMTP_LOGIN_MSG.*/define(\`confSMTP_LOGIN_MSG', \`Mail Server Ready ; \$b')dnl/" "${SENDMAIL_MAINCONF}"
fi
m4 "${SENDMAIL_MAINCONF}" > "${SENDMAIL_CONFIG}"
fi
else
sed -i 's/O SmtpGreetingMessage=.*/O SmtpGreetingMessage= Mail Server Ready ; $b/' "${SENDMAIL_CONFIG}"
fi
service sendmail restart 1>/dev/null
|
Restrict Mail Forwarding
[ref]rule
If sendmail is installed, perform the following checks:
Edit the file /etc/mail/sendmail.cf to ensure that the following
ForwardPath line appears without any file path specified:
0 ForwardPath
Perform a search on the system for any .forward files by issuing the following command:
# find / -name .forward
The 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.
Identifiers:
GEN004580 References:
ECSC-1, 366 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
SENDMAIL_CONFIG=$(rpm -ql sendmail | grep sendmail.cf)
SENDMAIL_MAINCONF=$(rpm -ql sendmail | grep sendmail.mc)
if [ "$(rpm -q sendmail-cf &>/dev/null; echo $?)" = "0" ]; then
if [ -e "${SENDMAIL_MAINCONF}" ]; then
if [ "$(grep -c 'confFORWARD_PATH' "${SENDMAIL_MAINCONF}")" = "0" ]; then
sed -i "0,/^define/s/\(^define\)/define(\`confFORWARD_PATH',\`')dnl\n\1/" "${SENDMAIL_MAINCONF}"
elif [ "$(grep -c "define(\`confFORWARD_PATH',\`')dnl" "${SENDMAIL_MAINCONF}")" = "0" ]; then
sed -i "s/define(\`confFORWARD.*/define(\`confFORWARD_PATH',\`')dnl/" "${SENDMAIL_MAINCONF}"
fi
m4 "${SENDMAIL_MAINCONF}" > "${SENDMAIL_CONFIG}"
fi
else
sed -i 's/O ForwardPath.*/O ForwardPath/' "${SENDMAIL_CONFIG}"
fi
service sendmail restart 1>/dev/null
for FILE in $(find /etc -name .forward -type f 2>/dev/null); do
rm -f ${FILE}
done
|
Restrict Mail Relaying
[ref]rule
If sendmail is installed, perform the following checks:
Edit the file /etc/mail/sendmail.cf to ensure that only the following
DaemonPortOptions line appears:
O DaemonPortOptions=Port=smtp,Addr=127.0.0.1, Name=MTA
Edit the file /etc/mail/sendmail.mc to ensure that the following
promiscuous_relay line does NOT appear:
promiscuous_relay
If 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 = localhost
Edit the file /etc/postfix/main.cf to ensure that only the following
smtpd_client_restrictions line appears:
smtpd_client_restrictions = reject
Rationale:
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 Updates
[ref]rule
If sendmail is installed, perform the following command:
# rpm -q sendmail
The version indicated should be equal to or greater than the following:
8.13.8-8
If postfix is installed, perform the following command:
# rpm -q postfix
The version indicated should be equal to or greater than the following:
2.3.3-6
Rationale:
The SMTP service version on the system must be current to avoid exposing
vulnerabilities present in unpatched versions.
|
LDAP 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 Clients
[ref]groupThis 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
system-config-authentication . However, these tools do not provide as
much control over configuration as manual editing of configuration files. The
authconfig tools do not allow you to specify locations of SSL certificate
files, which is useful when trying to use SSL cleanly across several protocols.
Installation and configuration of OpenLDAP on Red Hat Enterprise Linux 5 is available at
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Deployment_Guide/ch-ldap.html.
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 Transactions
[ref]ruleConfigure LDAP to enforce TLS use. First, edit the file
/etc/ldap.conf , and add or correct the following lines:
ssl start_tls
Then 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 Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ "$(cat /etc/ldap.conf | grep -c '^ssl ')" = "0" ]; then
echo "ssl start_tls" | tee -a /etc/ldap.conf &>/dev/null
else
sed -i 's/^ssl .*/ssl start_tls/' /etc/ldap.conf
fi
if [ "$(cat /etc/ldap.conf | grep -c '^tls_ciphers ')" = "0" ]; then
echo "tls_ciphers TLSv1" | tee -a /etc/ldap.conf &>/dev/null
else
sed -i 's/^tls_ciphers .*/tls_ciphers TLSv1/' /etc/ldap.conf
fi
|
Configure Certificate Directives for LDAP Use of TLS
[ref]ruleEnsure a copy of a trusted CA certificate has been placed in
the file /etc/pki/tls/CA/cacert.pem . Configure LDAP to enforce TLS
use and to trust certificates signed by that CA. First, edit the file
/etc/ldap.conf , and add or correct either of the following lines:
tls_cert /etc/pki/tls/CA
or
tls_cert /etc/pki/tls/CA/cacert.pem
Rationale: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. Identifiers:
GEN008000 References:
DCNR-1, 185 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
sed -i 's/ ldap//g' /etc/nsswitch.conf
|
Configure Certificate Trust Validation
[ref]ruleEnsure LDAP server connections have a valid trust path.
Configure LDAP to enforce validation of LDAP server certificates for trust.
First, edit the file /etc/ldap.conf , and add or correct the following line:
tls_checkpeer yes
Rationale: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. Identifiers:
GEN008020 References:
DCNR-1, 185 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ $(cat /etc/ldap.conf | grep -c "^tls_checkpeer") = "0" ]; then
echo "tls_checkpeer yes" | tee -a /etc/ldap.conf &>/dev/null
else
sed -i 's/^tls_checkpeer.*/tls_checkpeer yes/' /etc/ldap.conf
fi
|
Configure Certificate Revocation Validation
[ref]ruleEnsure 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 /etc/ldap.conf , and add or correct the following line:
tls_crlcheck all
Rationale: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. Identifiers:
GEN008040 References:
DCNR-1, 185 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ $(cat /etc/ldap.conf | grep -c "^tls_crlcheck") = "0" ]; then
echo "tls_crlcheck all" | tee -a /etc/ldap.conf &>/dev/null
else
sed -i 's/^tls_crlcheck.*/tls_crlcheck all/' /etc/ldap.conf
fi
|
LDAP Passwords Are Stored In Clear Text
[ref]ruleEnsure the LDAP configuration does not include any passwords stored in clear text.
Edit the file /etc/ldap.conf , and remove any lines that include the
bindpw directive.
Rationale: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 Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
sed -i '/bindpw/d' /etc/ldap.conf
|
NFS and RPC
[ref]groupThe 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 Possible
[ref]groupIf 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 NFS
[ref]groupIf NFS is not needed, remove the NFS client daemons portmap and rpcbind.
All of these daemons run with elevated privileges, and many listen for network
connections. If they are not needed, they should be disabled to improve system
security posture. |
contains 1 rule |
Remove portmap and rpcbind Packages
[ref]ruleThe portmap and rpcbind packages can be uninstalled with
the following command:
# yum erase portmap rpcbind
Identifiers:
GEN003815 References:
ECSC-1, 305 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
yum -y remove portmap rpcbind --disablerepo=* 1>/dev/null
|
Disable Services Used Only by NFS
[ref]groupIf NFS is not needed, disable the NFS client daemons nfslock, rpcgssd, and rpcidmapd.
All of these daemons run with elevated privileges, and many listen for network
connections. If they are not needed, they should be disabled to improve system
security posture. |
contains 1 rule |
Disable portmap and rpcbind Services
[ref]ruleThe 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 rpcbind service can be disabled with the following command:
$ sudo chkconfig rpcbind off
|
Configure All Machines which Use NFS
[ref]groupThe 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 Clients
[ref]groupThe steps in this section are appropriate for machines which operate as NFS clients. |
contains 1 rule |
Mount Remote Filesystems with nosuid
[ref]rule
Add the nosuid option to the fourth column of
/etc/fstab for the line which controls mounting of
any NFS mounts.
Rationale: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. Identifiers:
GEN005900 References:
ECPA-1, 225 |
Configure NFS Servers
[ref]groupThe steps in this section are appropriate for machines which operate as NFS servers. |
contains 4 rules |
Specify UID and GID for Anonymous NFS Connections
[ref]ruleTo specify the UID and GID for remote root users, edit the /etc/exports file and add the following for each export:
anonuid=-1
anongid=-1
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. |
All Exports Must Define Allowed Targets
[ref]ruleWhen configuring NFS exports, ensure that each export line in /etc/exports contains
a list of hosts which are allowed to access that export. If no hosts are specified on an export line,
then that export is available to any remote host which requests it. All lines of the exports file should
specify the hosts (or subnets, if needed) which are allowed to access the exported directory, so that
unknown or remote hosts will be denied.
Authorized hosts can be specified in several different formats:
- Name or alias that is recognized by the resolver
- Fully qualified domain name
- IP address
- IP subnets in the format
address/netmask or address/CIDR
Rationale: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.
Identifiers:
GEN005840 References:
ECSC-1, 366 |
Use Root-Squashing on All Exports
[ref]ruleIf 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.
Ensure that no line in /etc/exports contains the option no_root_squash .
Rationale:If the NFS server allows root access to local file systems from remote hosts, this
access could be used to compromise the system.
Identifiers:
GEN005880 References:
EBRP-1, 225 |
Ensure Insecure File Locking is Not Allowed
[ref]ruleBy 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
insecure_locks option can be used so these clients can access the
desired export. This poses a security risk by potentially allowing the client
access to data for which it does not have authorization.
Remove any instances of the
insecure_locks option from the file /etc/exports .
Rationale:Allowing insecure file locking could allow for sensitive data to be
viewed or edited by an unauthorized user.
|
FTP Server
[ref]groupFTP 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.
However, there are some FTP server configurations which may
be appropriate for some environments, particularly those which
allow only read-only anonymous access as a means of downloading
data available to the public. |
contains 7 rules |
Disable Unencrypted FTP Services
[ref]rule
The vsftpd service can be disabled with the following command:
$ sudo chkconfig vsftpd off
Rationale:
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.
Identifiers:
GEN004800 References:
ECSC-1, 366 |
Enable Logging of All FTP Transactions
[ref]ruleAdd or correct the following configuration options within the vsftpd
configuration file, located at /etc/vsftpd/vsftpd.conf :
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.log Rationale:To 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 /var/log/vsftpd.log . Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ -e /etc/xinetd.d/gssftp ]; then
if [ "$(grep server_args /etc/xinetd.d/gssftp | grep -c " -l")" = "0" ]; then
sed -i "/server_args/s/$/ -l/" /etc/xinetd.d/gssftp
fi
fi
if [ -e /etc/vsftpd/vsftpd.conf ]; then
if [ "$(grep -ic "^xferlog_enable=yes" /etc/vsftpd/vsftpd.conf)" = "0" ]; then
sed -i "s/xferlog_enable.*/xferlog_enable=yes/" /etc/xinetd.d/gssftp
fi
fi
|
FTP Umask Must Be 077.
[ref]rule
All 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 Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ "$(rpm -q krb5-workstation &>/dev/null; echo $?)" = "0" ]; then
if [ "$(grep server_args /etc/xinetd.d/gssftp | grep -v "#" | grep -c "\-u 077")" = "0" ]; then
sed -i '/server_args/s/$/ -u 077/' /etc/xinetd.d/gssftp
fi
fi
if [ "$(rpm -q vsftpd &>/dev/null; echo $?)" = "0" ]; then
if [ "$(grep -c local_umask /etc/vsftpd/vsftpd.conf)" = "0" ]; then
echo "local_umask=077" >> /etc/vsftpd/vsftpd.conf
else
sed -i '/local_umask/s/=.*/=077/' /etc/vsftpd/vsftpd.conf
fi
if [ "$(grep -c anon_umask /etc/vsftpd/vsftpd.conf)" = "0" ]; then
echo "anon_umask=077" >> /etc/vsftpd/vsftpd.conf
else
sed -i '/anon_umask/s/=.*/=077/' /etc/vsftpd/vsftpd.conf
fi
fi
|
Ftpusers File Contains Users
[ref]rule
The 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 Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
SYS_USER=$(cat /etc/passwd | while read entry; do if [ "$(echo ${entry} | cut -d: -f3)" -lt "500" ]; then echo ${entry} | cut -d: -f1 ; fi; done)
if [ "$(rpm -q krb5-workstation &>/dev/null; echo $?)" = "0" ]; then
if [ ! -e /etc/ftpusers ]; then
>/etc/ftpusers
chmod 0640 /etc/ftpusers
chown root:root /etc/ftpusers
fi
for USER in `echo $SYS_USER`; do
if [ $(grep -c "^${USER}$" /etc/ftpusers) = 0 ]; then
echo ${USER} | tee -a /etc/ftpusers &>/dev/null
fi
done
fi
if [ "$(rpm -q vsftpd &>/dev/null; echo $?)" = "0" ]; then
if [ ! -e /etc/vsftpd/ftpusers ]; then
>/etc/vsftpd/ftpusers
chmod 0640 /etc/vsftpd/ftpusers
chown root:root /etc/vsftpd/ftpusers
fi
for USER in `echo $SYS_USER`; do
if [ $(grep -c "^${USER}$" /etc/vsftpd/ftpusers) = 0 ]; then
echo ${USER} | tee -a /etc/vsftpd/ftpusers &>/dev/null
fi
done
fi
|
Ftpusers File Exists
[ref]rule
The 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 Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
SYS_USER=$(cat /etc/passwd | while read entry; do if [ "$(echo ${entry} | cut -d: -f3)" -lt "500" ]; then echo ${entry} | cut -d: -f1 ; fi; done)
if [ "$(rpm -q krb5-workstation &>/dev/null; echo $?)" = "0" ]; then
if [ ! -e /etc/ftpusers ]; then
>/etc/ftpusers
chmod 0640 /etc/ftpusers
chown root:root /etc/ftpusers
fi
for USER in `echo $SYS_USER`; do
if [ $(grep -c "^${USER}$" /etc/ftpusers) = 0 ]; then
echo ${USER} | tee -a /etc/ftpusers &>/dev/null
fi
done
fi
if [ "$(rpm -q vsftpd &>/dev/null; echo $?)" = "0" ]; then
if [ ! -e /etc/vsftpd/ftpusers ]; then
>/etc/vsftpd/ftpusers
chmod 0640 /etc/vsftpd/ftpusers
chown root:root /etc/vsftpd/ftpusers
fi
for USER in `echo $SYS_USER`; do
if [ $(grep -c "^${USER}$" /etc/vsftpd/ftpusers) = 0 ]; then
echo ${USER} | tee -a /etc/vsftpd/ftpusers &>/dev/null
fi
done
fi
|
FTP User Has Shell
[ref]rule
Anonymous 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 Shell
[ref]rule
The 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.
Identifiers:
GEN005120 References:
ECSC-1, 225 |
Samba(SMB) Microsoft Windows File Sharing Server
[ref]groupWhen 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, samba-client , provides a series of
command line tools that enable a client machine to access Samba
shares. The second, simply labeled samba , provides the Samba
service. It is this second package that allows a Linux machine to
act as an Active Directory server, a domain controller, or as a
domain member. Only the samba-client package is installed by
default. |
contains 6 rules |
Remove Samba if Possible
[ref]group
The Samba server must not be installed unless it provides an operational need.
|
contains 1 rule |
Remove samba and samba3x Packages
[ref]ruleThe samba and samba3x packages can be uninstalled with
the following command:
# yum erase samba samba3x
Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
yum -y remove samba-common --disablerepo=* 1>/dev/null
|
Configure Samba if Necessary
[ref]groupAll settings for the Samba daemon can be found in
/etc/samba/smb.conf . Settings are divided between a
[global] configuration section and a series of user
created share definition sections meant to describe file or print
shares on the system. By default, Samba will operate in user mode
and allow client machines to access local home directories and
printers. It is recommended that these settings be changed or that
additional limitations be set in place. |
contains 5 rules |
Samba Web Administration Tool Must Be Restricted
[ref]ruleThe 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 Option
[ref]rule
Samba 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. Identifiers:
GEN006220 References:
ECSC-1, 225 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
sed -i 's/\(^\[global\]$\)/\1\n\n\thosts allow = 127./' /etc/samba/smb.conf
|
Configure security Option
[ref]rule
Samba 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. Identifiers:
GEN006225 References:
ECSC-1, 366 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
sed -i '/^[#|;]/!s/\([ |\t]*security =\).*/\1 user/' /etc/samba/smb.conf
|
Configure encrypt passwords Option
[ref]rule
Rationale:
Samba must be configured to use encrypted passwords.
Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
if [ "$(grep -c '^[ |\t]*encrypt passwords' /etc/samba/smb.conf)" = "0" ]; then
sed -i 's/\(^\[global\]$\)/\1\n\n\tencrypt passwords = yes/' /etc/samba/smb.conf
else
sed -i '/^[#|;]/!s/\(encrypt passwords =\).*/\1 yes/g' /etc/samba/smb.conf
fi
|
Configure guest ok Option
[ref]rule
Rationale:
Guest access to shares permits anonymous access and is not permitted.
Identifiers:
GEN006235 References:
ECSC-1, 366 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
sed -i '/^[#|;]/!s/\(guest ok =\).*/\1 no/g' /etc/samba/smb.conf
|
SNMP Server
[ref]groupThe 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 Server
[ref]groupIf 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:
- use only SNMP version 3 security models and enable the use of authentication and encryption
- write access to the MIB (Management Information Base) should be allowed only if necessary
- all access to the MIB should be restricted following a principle of least privilege
- network access should be limited to the maximum extent possible including restricting to expected network
addresses both in the configuration files and in the system firewall rules
- ensure SNMP agents send traps only to, and accept SNMP queries only from, authorized management
stations
- ensure that permissions on the
snmpd.conf configuration file (by default, in /etc/snmp ) are 640 or more restrictive - ensure that any MIB files' permissions are also 640 or more restrictive
|
contains 4 rules |
Configure SNMP Service to Use Only SNMPv3 or Newer
[ref]rule
Edit /etc/snmp/snmpd.conf , removing any references to v1 , v2c , or com2sec .
Upon doing that, restart the SNMP service:
# service snmpd restart
Rationale:
Earlier versions of SNMP are considered insecure, as they potentially allow
unauthorized access to detailed system management information.
Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
find / -xdev -name snmpd.conf 2>/dev/null | xargs sed -i '/.*\(v1\|v2c\|community\|com2sec\).*/s/^/#/'
|
Ensure Default Password Is Not Used
[ref]rule
Edit /etc/snmp/snmpd.conf , remove default community strings public , private , snmp-trap , password .
Upon doing that, restart the SNMP service:
# service snmpd restart
Rationale:
Presence of the default SNMP password enables querying of different system
aspects and could result in unauthorized knowledge of the system.
Identifiers:
GEN005300 References:
IAAC-1, 178 |
Ensure Approved Hash Is Used
[ref]rule
Edit /etc/snmp/snmpd.conf , ensure every line beginning with createUser
includes SHA , similar to the following:
# createUser myuser SHA -l 0x0001020304050607080900010203040506070809 AES -l 0x00010203040506070809000102030405
Upon doing that, restart the SNMP service:
# service snmpd restart
Rationale:
The SNMP service must use SHA-1 or a FIPS 140-2 approved successor for
authentication and integrity.
|
Ensure Approved Encryption Is Used
[ref]rule
Edit /etc/snmp/snmpd.conf , ensure every line beginning with createUser
includes AES , similar to the following:
# createUser myuser SHA -l 0x0001020304050607080900010203040506070809 AES -l 0x00010203040506070809000102030405
Upon doing that, restart the SNMP service:
# service snmpd restart
Rationale:
The SNMP service must use AES or a FIPS 140-2 approved successor algorithm
for protecting the privacy of communications.
Identifiers:
GEN005307 References:
DCNR-1, 68 |